[linux-dvb] Re: Alternative v4 demux API

[Michael Hunold <hunold@convergence.de>]

Hello Ralph,

>  > - 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?!).
Might be. ;-)

> 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.
If there is such a limitation, it's easy to get this straight with my 
approach. If you open a general purpose filter, connect it to the same 
input selector ("demux") where the mpeg demux is already filtering and 
then set the same PID as the mpeg demux for example for video needs, 
you'll get an error. There could be a DVB driver flag which indicates 
this, so the application knows the limitation.

>  > 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.
Yes, but these designs can be mapped to my approach, too.

> 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. 
Nevertheless the "mpeg demux" needs three PID filters, it does not 
matter if they are specizalied or not.

The device driver writer can easily reserve three PID filters for the 
mpeg demux, so the mpeg demux will never refuse to work. This fits into 
my design: mpeg demux with three PID filters.

> That's where the current approach comes from which is no surprise
> since NOKIA used the AV7110 which does it this way. 
Yes. I don't say that the design is generally bad, but as you already 
said, there's hardware out there that *really* does not work very well 
with it. The av7110 can be mapped very simple to my approach: AFAIK one
frontend device, one (stupid) input selector, then one mpeg demux and 
general PID and section filters.

> 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.
Ok.

> You will not find a perfect combination of devices which will fit all
> hardware.  The question is what is the best compromise.
I agree.

> 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).
.. which is currently the case.

> 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.)
For every hardware I know (besides Nova / budget cards) there will be at 
least one mpeg demux and general PID and section filters. The only 
devices that really depend on the actual hardware are recording filters 
and teletext filters.

Legacy application did not have access to these devices in the past, so 
they have emulated this stuff through general purpose PID filters 
anyway. If they are ported to the new API (or use the new API through a 
compatibility layer) then nothing will change.

If the driver authors care, however, they can improve their applications 
by checking for these special devices and use the (probably more 
reliable) special devices.

So I don't see the risk that my design leads to increased device 
checking. Legacy applications will simply run as before.

>  > 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.
I like my "what you see is what you get approach": if there is a special 
recording device, the user can be sure that there's specialized hardware 
behind it.

But I won't insist on it: because of the fact that general purpose PID 
filters and recording units might be nearly the same, it would suffice 
to be able to have a "DVB_RECORDING_FILTER" flag that tells the driver 
to use a recording unit if available. Same goes for teletext. 
("DVB_TELETEXT_FILTER").

>  > 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.
>
> 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.
There is a fundamental difference between
- x input selectors ("demuxes"), a number of general purpose PID 
filters/demuxes, a number of general purpose section filters/demuxes

and

- x demuxes *with* general purpose PID filters and a number of section 
filter.

The old API and the current v4 approach suggest to the user that there 
are x demuxes with independent filters for each demux. This isn't true
most of the hardware I know: these hardware have a number of filters 
shared for all "demuxes" (input selectors).
The current approach does not handle this correctly in my eyes: you can 
open one "demux", then set PID filters until they are exhausted. Now the 
user could think that he simply can open the next demux, connect it to 
the same input and go on with setting filters.

My approach presents the ressources as they are available by most 
hardware: shared PID filters, shared section filters, one or more mpeg 
demuxes, with some input selectors ("demuxes") in front of them.

And even if there is a hardware, that *really* has separated 
demuxes/input selectors with independent PID and section filters, this 
is no problem: you open a PID filter and connect it to the desired input 
selector ("demux"). If the filters are exhausted for this demux, then 
setting the filter fails. Otherwise the filter is set using the hardware 
filter for that demux.

> Ralph
My main concern regarding the new api is consistency. And so far it 
looks pretty consistent IMHO.

CU
Michael.



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