On Sat, 22 Jan 2011, Udo Richter wrote:

Thought of that too, for a longer perspective. However, what do you think where to add such a hook ideally?

My original idea was to hook in cDevice::Action() as it would bring most flexible setup to blacklist/rewrite pids. However, I forgot the current section mechanism and pat/pmt parsing.

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.

Wouldn't stripping NALU fill data help to reduce the required network bandwidth for streamdev, xineliboutput, and vnsi plugins? I do see many benefits using filtered streams everywhere. You could also transcode only certain video/audio pids as the device class know its' transponder/channel parameters.

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.

You could simply hook up into the ringbuffer methods used in cRecorder.

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

..and you already thought about it. :) Anyway, it's up to the plugin how big the overhead will be and it wouldn't hurt when recording. It's up to the user how many recording filters she's going to chain...

BR, -- rofa