[linux-dvb] Re: Alternative v4 demux API

[Rob.McConnell@Zarlink.Com]

Hi Johannes,

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

That's fine. We just need to provide this flexibility as all the h/w I've
seen does allow parallel/serial TS format selection.

> 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 is true of everything we have today.  Would it be better to have an
ioctl (as suggested in a previous email) to allocate and set a filter,
instead of opening an fd and then trying to get a filter allocated/set?

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

Ok, your back to either opening the dedicated A/V filter N times or
allocating another /dev/dvb/adapter0/demux0/mpgfilter1 device.  The latter
approach does mean you start to eat up minor numbers though.

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

If the problem is code bloat, then having a OOD on the "generic filter"
will mean you use the majority of code and only add new code to explicitly
define the new functionality of the extended filter.  Having flags for all
possible filters does mean you have to make sure that the user doesn't do
something stupid.

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

Cool. : )

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

Wow - good planning there - not!  Yet another case of people sitting around
a table and deciding on specs that don't match real h/w.  If MHP apps do
require > 32 PID filters, then that will mean the majority of h/w out there
won't be able to handle this.

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

I think we've got mixed up here.  I just mean the ability to do a change of
section filter without having to close the filter down, open it up again
and reassign a new filter spec.  Just 1 ioctl to do it is fine.  I don't
give a monkeys if the PID is passed again, neither do the User APP monkeys
: )  We cover this already in the DVB_DMX_SET_SECTION_FILTER ioctl.

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

The user app needs to specify which PIDs to setup for which output
channels, that's all.  This means ultimately passing in a output channel
descriptor to the pid filter.  We can either do this in one of the many
flags, or have another device that simply extends the PID filter, shares
the majority of its code and adds a little of its own to setup the h/w
correctly.

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

Cheers!!!  Maybe it would be good if Michael and/or I do a similar thing.

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

Ok.  Don't work to hard this weekend.

Have a good one..

Rob : )






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