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'
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...
vdr mailing list