Am 22.01.2011 14:18, schrieb Rolf Ahrenberg:
> On Fri, 21 Jan 2011, Udo Richter wrote:
>> I had some issues integrating it properly into the recording function of
>> VDR, and then ran out of time. But I think I'll find some time this
> Howabout just adding a filter API and do the actual job in a plugin - I
> have some ideas where I could reuse such a mechanism.
Thought of that too, for a longer perspective. However, what do you
think where to add such a hook ideally?
For reference: What happens on recording:
- cDevice::Action() receives TS packets, does very little scrambling
detection, and passes data to attached receivers based on PID.
- cRecorder::Receive() stores all incoming packets into a ring buffer.
- cRecorder::Action() reads the ring buffer, does frame detection,
generates the index, adds PAT/PMT info and writes the stream to a file.
Adding a hook to cDevice::Action would affect all streams, including
transfer mode and streaming etc., but has no known relation between PID
and stream type. Also, there may be several video streams in parallel
here. And I wouldn't consider it good style to provide just filtered
streams for all in any case.
Adding a hook to cRecorder::Receive() would be nice, as (although not
explicitly specified) the data is received as single TS packets, which
would allow packet dropping easily. Also, the packets can easily be
checked for the (one and only) video PID and video type. However,
Receive() is supposed to return immediately, esp. since its called
within a Lock() of the device.
Adding the hook to cRecorder::Action() is not time critical, but here
the data stream is continuous and requires TS packet syncing. Hooked
before frame detection, a hook must be aware that the frame detector may
or may not use all or parts of the current buffer chunk or even nothing
of it (waiting for more), which is difficult to handle for dropping
data. After the frame detector, the buffer chunk will only be handled
once, which is way easier, but the hook must always process all of the
data, without a real guarantee that the buffer ends with a complete TS
A more flexible way would be to add yet another ring buffer between the
receiving buffer and the frame detector, and do the hook between the
buffers. But another buffer will be additional overhead...
I'm still unsure where to implement the naludumper within this.
vdr mailing list