[linux-dvb] Re: Alternative v4 demux API

[Ralph Metzler <rjkm@metzlerbros.de>]

Michael Hunold writes:
 > > Therefore they don't know what a PID is. So why should the
 > > A/V PIDs be given to the mpeg decoder device? The Transport Demux has to
 > > know them, so it can deliver the demultiplexed data to the decoder.
 > 
 > The more advanced hardware I know has a design like this:
 > - multiple "demux" to select from the input sources (so there are more 
 > like "input selectors" than demuxes)
 > - general purpose PID filters shared between all demux/input selectors
 > - general purpose section filters sharded between all demux/input selectors

 > - specialized APID/VPID/PCR filters for each mpeg decoder (so they 
 > technically belong to the mpeg demux/decoder, not to the other demux 
 > devices)

But they do (I guess you are talking about NEC hardware?!).
They have to be assigned to one of the demuxes and the PIDs they use
cannot be used by other PID filters assigned to the same demux.


 > In practise, only the first call would succeed (and this demux would 
 > have been connected to the mpeg decoder), and the other calls would have 
 > been refused.
 > 
 > This is implicit behaviour and therefore bad design. There is only one 
 > mpeg decoder, so there is only one set of PIDs that can be set. Because 
 > of this, there should be one specialized "mpeg demux".

While I do not agree that the AV filters belong directly to the
decoder it is true that they are linked closely to it.
Fact is, that while a special "mpeg demux" would fit closely to this
hardware (although the PID allocation dependency already hurts this a little bit) 
on other hardware this can look very different.
Some does not have special filters but any general purpose PID filter
can be assigned to video/audio/pcr. If one filter is assigned to one
of those requests on other filters have to be denied. 
That's where the current approach comes from which is no surprise
since NOKIA used the AV7110 which does it this way. 
So, I think neither approach is perfect for all hardware and I
basically do not care if those PIDs are set in the demux device or the
decoder device.
  
 > >>The idea behind this approach is to separate all the different stuff 
 > >>away from the demux device, which does not belong there.
 > 
 > > why?
 > 
 > Please refer to my explanation about advanced hardware. General purpose 
 > PID filters are general purpose, while the MPEG demux/decoder is 
 > specialized. If you have recording units, they are specialized, too. All 
 > these should not be available through one common device IMHO, that's bad 
 > design.

You will not find a perfect combination of devices which will fit all
hardware.  The question is what is the best compromise.
If you make the device API too simple the drivers will have to do a
lot of patchworking (e.g. automatically using recording units instead
of normal filters when possible/necessary). If the API supports too
many special devices the user application will have to do a lot of 
checking (what devices are there, how can I use them, etc.)

 
 > You can open the demux device and control the mpeg decoder(s), PID and 
 > section filters all at once, although they are independent from an 
 > outside view.

Not completely, see above.

 
 > Take PID filters with the new proposed API for example:
 > You can specify filters that simply don't make sense. You can set the 
 > filter type to DVB_DMX_FILTER_TYPE_VIDEO (mpeg decoder stuff), but 
 > specify DVB_DMX_FULL_TS (general purpose PID filter stuff).
 > 
 > Please explain, why it makes sense to put this into one structure 
 > instead of clearly separating this?

Again, this depends on the hardware.
The current API V4 proposition basically treats each filter as if it
is a streaming device. For software filters this is no problem except
that DMA is probably out of the question. Some hardware only has two 
recording devices which can do direct DMA of multiplexed sub-streams.
Here, it could make sense to have extra devices. Or you also use
the demux device and let special requests fail.


 > > that's because PIDs may vary.
 > 
 > Yes, but section filtering is bound to PIDs. So if you want to have 
 > section filters on different PIDs, you need to have different logical 
 > instances of a "section filter", right?
 > 
 > The user is aware of this, so there is no need to hide this from him. If 
 > he wants section filtering on another PID, he needs to open the device 
 > again.

Does the current proposal allow setting section filters with different
PIDs on the same handle?

Regarding the special PID and section filter devices I do not see a
real difference compared to having them all in the demux device besides
inflating the number of devices.


Ralph



-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.