[linux-dvb] Re: Alternative v4 demux API

[Rob.McConnell@Zarlink.Com]

Hi All,

> Rob.McConnell@Zarlink.Com wrote:
> >
> > Having the ability to select the delivery format (parallel or serial)
of
> > the TS/PS to a potential input/selector device would be useful. I guess
> > this would be an ioctl on the front-end device. That's one ioctl for
the
> > front-end device API.... : )

> Why would this be useful? I think the board designer decides if he wants
> to use serial or parallel FE output and would not connect both?

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.

> > I like the idea of the "output" devices.  However, I think we can
> > implicitly route the output from a demux device/input selector to the
input
> > of an "output" device as follows:

> > We get:
> >
> > /dev/dvb/adapter0/demux0/router
> > /dev/dvb/adapter0/demux0/mpgfilter
> > /dev/dvb/adapter0/demux0/pidfilter
> > /dev/dvb/adapter0/demux0/secfilter
> >
> > /dev/dvb/adapter0/demux1/router
> > /dev/dvb/adapter0/demux1/pidfilter
> > /dev/dvb/adapter0/demux1/secfilter

> I still fail to see the real advantage over having just a single "demux"
> device per input channel. For a human who looks at the /dev/dvb tree
> it might look nicer, but in software it doesn't matter, IMHO.

Having a single demux device per input channel is not a problem.  It is
when you start looking at the outputs, that's when you start to find "what
if" or "Oh bugger I forgot to support this flag/feature/new bit of crazy
hardware".  Having a group of "output" devices/filters that are connected
to a "demux" device would be logically more sane (each one performing a
different function).

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

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?

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

> > We can implicitly connect these "output" filter devices to the required
> > input selector "demux" device by just looking at the minor number.

> Minor number encoding will get more difficult because there are other
> types of DVB devices besides demux stuff, just look at dvbdev.c.
> An easy way out would be a second major number, but we should avoid
> this if we can.

I agree, it's not that straight forward, but with 2.6 and the larger 32
bits for the device type this would be easier.  What about devfs, would
that help out?

> > In this way, we can group the filtering capabilities of a demux device
> > together quite nicely and there is also room for adding new device
types if
> > and when required in the future. Some hardware that I have seen also
has
> > "string" filtering capabilities where the filtered data is scanned for
a
> > string to match before outputting to memory.

> It will always be possible to add DVB_DMX_SET_FOOBAR_FILTER. It will
> be even easier to do if you don not have to add a new device.

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

> > What about "logical" demux devices that share a pool of filters?  In
this
> > case, we would have to ensure that there is a minimum amount of filters
per
> > "logical" demux device to get the job done.  From what I have seen, the
> > hardware usually has more than just 32 PID filters in this case. Just
> > divide up the filters evenly amongst the "logical" demux devices.

> 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 : )

> > > Something like this goes for the "General purpose section filter",
too.
> > >   You can open the device as many times as you want, unless the PID
> > > filters and/or section filters are exhausted.
> >
> > > - SET_PID: set the associated PID for this open
> > > - ADD_FILTER: this allocates an array(!) of section filters from the
> > > hardware pool with the usual parameters: filter, mask, mode
> > > - DEL_FILTER: delete an array(!) of section filters
> > > - START_FILTERING: start filtering
> > > - STOP_FILTERING: stop filtering
> >
> > Good.

> No, bad!

Why "bad!" ?  It does the job - you can attach multiple section filters per
fd and then say "go".

> > 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 ; )

> > I also have another scenario where your proposal would fit the hardware
> > better than the current V4 one.
> >
> > Take a demux unit where each PID filter can choose one of 2 input
streams
> > and each PID filter can output to one of 2 output channels.  In this
case,
> > you have 4 output channels coming from the different sources:
> >
> >            |--------| Stream #1  |----------|
> > TS #1 ---> | Router |----------->|          |-------> From stream #1 to
> > channel #1
> >            |        |            | PID      |-------> From stream #1 to
> > channel #2
> > TS #2 ---> |        |            | Filters  |
> > ...                              |          |
> >                       Stream #2  |          |-------> From stream #2 to
> > channel #3
> > TS #N ---> |        |----------->|          |-------> From stream #2 to
> > channel #4
> >            ----------            |----------|
> >
> > In the current V4 API, we would have to create either:
> >
> > 1) Create 2 "logical" demux devices with each one having a dedicated
stream
> > input.  All PID filters associated with this logical demux device
(shared
> > PID filters between devices) would share the same input.  However, you
> > would have to specify an output channel somehow when setting up a PID
> > filter.  This would have to be an additional parameter to pass in the
pid
> > filter structure. Not nice and only suits specific h/w.

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

> > I have also run this over other h/w that I know and it seems to fit the
> > bill.  Please make any constructive comments...

> I hope I did. Even if I just teared Your and Michaels proposals to
> shreds ;-}

No probs - that's what we are here for - bouncing ideas back and forth of
the chunnel : )

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.

TTFN,

Rob :^)






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