[linux-dvb] Re: Alternative v4 demux API

[Holger Waechtler <holger@convergence.de>]

Ralph Metzler wrote:
> 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.
There exists enough hardware out there with similiar limitations, we 
don't need to say any names.

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.

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.

But the remaining ideas of Michael's approach don't map the current 
hardware enough and are too specialized and high-level, so think it's 
better to stick to the dedicated flexible demux device which does both 
packet demultiplexing and routing.


>  > 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.
Hmm, the approach outlined above might fit this situation even better 
and would still be flexible enough, not?


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

Would it not be sufficient to add a output route into a file descriptor 
so that the kiobufs of the filesystem layers can get feeded using the 
demux DMA pointers directly (don't know whether 2.6 still uses kiobufs, 
maybe this has changed, but the underlying concepts are probably the same).

Or even simpler: Make the demux output ringbuffer double-buffered and 
allow to relocate the backbuffer from userspace using a demux-ioctl. A 
userspace program would now mmap() the destination file, then relocate 
the backbuffer. As soon front- and backbuffers get flipped the demux API 
faults this page in and then DMA's into this area. Maybe one needs more 
than 2 buffers, maybe a quad-buffered architecture is required to get 
fluent transfers.


>  > 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.
Has the approach of using a single dvb device per adapter been ever 
discussed? This would require adding a device id to every control 
struct, don't know whether this is a good idea...

Holger



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