[linux-dvb] Re: Alternative v4 demux API

[Johannes Stezenbach <js@convergence.de>]

Rob.McConnell@Zarlink.Com wrote:
> 
> I agree that in the field, you would only have a fixed input (parallel or
> serial), but because we are using development boards that test every aspect
> of the silicon, we do require this functionality (typical h/w bods).  Also,
> when providing software to 3rd parties or customers who develop their own
> hardware, then having the ease to choose the option makes things far more
> simpler than having them try and hack kernel/driver code or have "us" do it
> for them.

You can make it a compile time option or a module parameter.
Applications need not worry about it. If you really need to switch
at runtime you can add a private ioctl to the frontend.


> e.g. If you can't perform special A/V filtering on a specific demux device
> as there is no h/w channel for the decoders, then you don't have to worry
> about it. You wouldn't have a device file in the directory for that
> specific "demux" device.  If you stuck with the current V4 proposal, then
> you would have to query the capabilities to find out it a device can
> perform this function.

It's both just one function call, access() vs. ioctl().

Also note the difference between a "capability" and "resource
availability". Unless your application does some book keeping and you can
rule out that other apps are "stealing" resources you don't know if you
can set a A/V filter until you try it.


> This also gets a bit messy when dealing with
> "logical" demux devices that share pid filters but have separate input
> streams.  Which "logical" demux device do you assign the capability of
> performing A/V decoding if there is only 1 A/V path?

First come, first served ;-). Both demux devices have the capability,
but the second try to set an A/V filter will get EBUSY.


> Ok, it means establishing the correct /dev/dvb/adapter0/demux0/ .../demux1
> dir structure initially, but then that should be left up to the driver
> loader scripts that each hardware device would tailor for itself.  The user
> application wouldn't ever get in to a situation whereby you try to open an
> A/V channel on multiple demux devices when the h/w can't do it.  This seems
> a bit cleaner, don't you think?

Consider you have two A/V paths which you can use both
on the same demux channel. How would you model that without
destroying the cleanlyness of your design?


> Also, if we are clever, we can devise an architecture where you have each
> filter/"output" device as a separate module that gets loaded in on top of
> another module or layer that just expects a filtered output as its input.
> The beauty of this is that you can have a generic "output" device/filter
> that can be extended (OOD) to have specific characteristics.  Each filter
> device would filter the data differently.  It also means that you can
> easily extend the system for future h/w - which is one major problem that
> we have at the mo.
> 
> We definitely need to address "extensibility" as we don't want to sit down
> again and have all these debates about how pretty our own API looks or
> whatever. ;^) Designing it in a way that allows one to insert a new module
> that performs a specific filtering capability would be ideal.  The layer
> that gets passed the filtered data can be kept generic in that it passes
> the data up to user-space as required.
> 
> I probably have forgotten a few details, but I hope you get the idea - just
> trying to make it more future proof.  We would spend less time trying to
> agree on a global filter design with its many flags.  With flags, you get
> all the combinations that may/may not be required in a specific filter
> (ouch).
...
> Depends if you go for the one-for-all lump of code that does it all, or the
> more modular approach as quickly outlined above (each device has a specific
> function).

Extensibility and modularity are important goals. However, don't think
that we need a "modular API" but rather a modular and extensible
implementation. We haven't discussed the internal (dvb-core) demux API
yet, but it will of course change, too.

It will always be possible to add new or private demux ioctls,
which can handled by hardware drivers or dvb-core extensions. If necessary
we could also provide a "dvb-core plugin" API (but currently I don't see a
need for it). I don't think that it is a good idea to add a new device
for each new demux functionality.

Most of the flags cruft was a left-over from the V3 API and will be
removed.

> > No way. If you have 32 shared filters and you use them all on the first
> > logical demux, there will be none left for the second. Because that's
> > what the user wants. If you reserve filters you actually take away
> > capabilities that a user might need.
> 
> Just thought if you had 64 PID filters and 2 "logical" demux devices, then
> you would split it evenly.  If anyone wanted 32 PID filters in the 1st
> instance, then they are a bit greedy : )

Unfortunately, if you do MHP or the like you will find that some
Xlets (MHP applications) use more than 32 filters and will just
fail if they don't get what they want...

Ultimately the user must be able to decide, if he wants all filters
for one channel, so be it.


> > > Agreed, you may want to simply change the section filter spec without
> > > wanting to change the PID entry.  This is common practice when only
> wanting
> > > to receive section tables that have a different "version number" from
> the
> > > current one.
> 
> > I never felt the need to do that. E.g. if you want SDTs for some
> > services you don't care that all those filters are on the same PID,
> > and you don't want to manage the shared PID filter in your application.
> > Let the driver do this!
> 
> This is a requirement by the user app boyz - this is the way they currently
> do things.  Can't comment on their code ; )

One can view the PID as part of the section filter specification. If the
application needs to change the filter it doesn't matter if the PID
stays the same or changes. I know that it is customary in RTOS APIs
to deal with the PID filters explicitely, but I know no application
which can use this to its advantage -- it's just a burden for the
application progammer.

 
> > That's how I intended it. Output "channels" are managed by connecting
> > devices to the demux/filter fd, or (in case of recording) by opening
> > a second fd for the second recodring channel.
> 
> Ah, probably what I forgot to mention was that each stream coming out has a
> header prepended to the actual filtered data.  The header depicts which
> "output channel" the streams is emanating from.  I can't see us adding
> extra flags to the PID filter structure just to cater for this h/w, can
> you?  If we had "output" devices instead, then you wouldn't have to worry
> about modifying the pid filter code but could just add another filter
> device that extends the generic pid filter instead (me like OOD).

The hardware driver must deal with that internally, it's not an API issue.
Or is it?


> I think its time to come up with some real API header files again.  If we
> propose both ideas in different files and let people comment on them, then
> we may get more feedback.

OK, I will update the dvb-kernel-v4 header files on Monday according
to my liking.

I will also try to port szap etc. to the new (still hypothetical) API,
so we can see how it would be used. However, the more interesting API
features won't be visible until one tries to use it for a complex
application.


Regards,
Johannes


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