[linux-dvb] Re: Alternative v4 demux API

[Michael Hunold <hunold@convergence.de>]

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?

> > So it should be possible to open a *filter* as many times as there are 
> > h/w filters available, not a "demux" device, where the filters are 
> > shared betwenn all "demuxes".
> Isn't this the case?
I admit that this is a matter of (design) taste.

> Basically the API right now was intended like this:
>
> Imagine you have 2 frontends, 3 demux channels and 2 MPEG decoders on 
> your DVB chipset. This means that you have the following DVB devices:
>
> /dev/dvb/adapter0/frontend0
> /dev/dvb/adapter0/frontend1
> /dev/dvb/adapter0/demux0
> /dev/dvb/adapter0/demux1
> /dev/dvb/adapter0/demux2
> /dev/dvb/adapter0/video0
> /dev/dvb/adapter0/video1
> /dev/dvb/adapter0/audio0
> /dev/dvb/adapter0/audio1
>
> Now you could use the first channel connected to the first frontend and 
> the first MPEG decoder to watch Live-TV.
>
> The second one is connected to the second frontend and outputs packets 
> to memory or indirectly to disk for recording.
>
> The Third one is feeded from disk/memory and outputs the stream to the 
> second MPEG decoder.
Yes, sure it can be done with the old API. But as you have already said 
in another mail, there are ambiguities, inconsistent behaviour and 
unspecified behaviour all over the place.

Currently, drivers use many assumptions about what the user is really 
trying to do.

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.

If you have an "mpeg demux", the behaviour is clear: connect it to one 
input selector and be done.

> So you can implement recording/timeshifting with simultanous 
> picture-in-picture control of the program received from the first 
> frontend. Or implement MHP applets which use one of the MPEG decoders to 
> decode I-frames or Streamlets for background images while you still 
> decode the TV picture into a small PiP on the right upper corner. And 
> record a third program to the disk while you're doing all this.
>
> You can do so since you can route streams of the 3 demux channels 
> independently and can select input/output for each independently.
My approach is to try to get rid of these inconsistencies and to reflect 
the most common hardware out there. This is why I like the idea of an 
"mpeg demux", even if one hardware does not have a *dedicated* mpeg demux.

I think I'm going to write a "dmx.h" file in order to manifest my ideas.

> Holger
CU
Michael.



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