[linux-dvb] Re: Alternative v4 demux API

[Ralph Metzler <rjkm@metzlerbros.de>]

Holger Waechtler writes:
 > I'm not aware of any chipset without a dedicated demultiplexer unit, are 
 > you?
 > (just to get the convention clear: The Demultiplexer seperates a 
 > multiplexed - a concatenated stream of packets with different packet IDs 
 > - and routes the packets to the destination devices.)
 > 
 > I like the idea of a source based routing in Michael's approach (we've 
 > been discussing this issue before in another thread some months ago), 
 > the idea not to specify input and output device of the demux but instead 
 > specify a stream source in the decoder. This removes some ambingiuties.

OK, I guess with the MPEG decoder using it this way is a little bit clearer.
With both methods the application has to be aware that
interdependencies with other PID filters exist.

 
 > If we want to remove even more ambinguities we should distinguish in the 
 > demux API between general purpose filter banks and decoder-attached 
 > filter banks.
 > 
 > Maybe this would even simplify using the API since the routing might get 
 > more straightforward.

True. Again this is the question wether to tell the application about all
capabilities (wether it be through "CAP-ioctls" or the mere existence
of devices) or to let the driver deal with it.
In the latter case suddenly telling the driver to "decrypt a PID" can
cause major headaches depending on the state of filter allocation ... 

And there are even more kinds of filter modes which cannot
always be done by all filter banks. And there can be restrictions on
which section filters can be used with which PID filters from which
banks, etc. 


 > > 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.)
 > 
 > Can you please specify the term 'special recording unit' a little more 
 > in detail? -- Are you simply talking about hardware that does just DMA's 
 > a demuxed stream into a dedicated memory area and allows simultanous DMA 
 > transfers from this area to the harddisk?

With the recording units I mean filters where you select several PIDs
and a sub-stream of the TS with just those PIDs is written by DMA into
the same buffer.
Other filters will just handle one PID at the same time and write in
different buffers. Of course you can combine several of those but you
will have to mix the packets together in software.


Ralph


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