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 weekend.

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 packet.

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.

Cheers,

Udo