Michael Hunold wrote:
No. Take a closer look on demux devices. The decision whether to pass or skip a particular packet depends on matching the filter and mask bits (imagine the 13 PID bits as 'always-on, no-inverted filter bits'). The PID is just part of the generalized filter, section filters just have more bits which get tested.Hello Holger,Different demux devices with included filter capabilities suggest to the user that there's hardware behind it. This is currently not the case for any hardware out there.
It is. Whenever we implemented multiple demux devices for an adapter each of them stands for an independent demux channel for which you can select stream source and ouput independently from the other ones.
So these "demuxes" are basically "routers" and the PID filters are not *part* of these routers. They can be *attached* to these routers individually.
I don't want to get rid of the "demux" devices, I just think that the filters shouldn't be a part of them. Again: if the user has multiple demuxes and can set multiple PID filters, he might think that these filters are part of the demux. And this isn't the case for any hardware I know. These filters can be attached to demuxes.
The "demuxes" are input selectors and filters are shared.no. If you have an second or third demux device (which means that you have 2 or 3 seperate demux channels) it's input selector and filters are independent from the first one.
But filters are a shared resoource. If demux 1 eats up all filters, then demux 2 is out of luck. So why not have a "filter device" that you can open as many times as there are filters available?
Not always, this depends on the architecture you are talking about.
For example, currently you need to specify which mpeg decoder to use via dmx_pes_type_t, ie. you munge output destination and filter type into one thing.that's evil, this would vanish with source-based routing or with output enums like DMX_OUT_DECODER_VIDEO0...DMX_OUT_DECODER_VIDEOX.