[linux-dvb] Re: More V4 Demux API Q's

[Rob.McConnell@Zarlink.Com]

> The idea of having multiple section filters on the same fd was dropped
> because the consensus on the list was that it isn't worth the trouble.
> It's not difficult for applications to open a few more file descriptors
> and use poll() on them.

> > a)  The ability to add more than one section filter with the same PID
to a
> > single fd.
> > b) The ability to add more than one section filter with the same PID to
> > separate fds.
> > c) The ability to dynamically add section filters to an already running
> > filter.

> IMHO a) is superfluous and c) is solved the b) way.
> The hw driver will use the same PID filter internally for all section
> filters on the same PID, if the hw requires it.

From a technical point of view, is it harder to have functionality a) in
existence with b)?  For most h/w that I have seen, you cannot have the same
PID value assigned to more than one PID filter.  What this means is that
you get one PID filter providing a single feed to either a h/w section
filter bank(s) or to a s/w implementation of section filters.  For h/w
section filters, you get a complete section table popping out to the h/w
buffer - sweet and simple.  On h/w that I know, you can dynamically add/del
section filters to the PID filter feed to provide different section
filtering depth as well as trapping other section table IDs on the same
PID.  To provide functionality (b) you have to have a s/w filtering
algorithm that then scans the h/w buffer before copying the complete
section table to the corresponding process kernel buffer (like we do
currently I believe).

For s/w implemented section filtering, surely you could keep a linked list
of the different section filter specs and run through those building up a
section table as it arrived.  When you got a complete section table, you
could then do the copy to another buffer like we do at the moment.  A
process would then read the kernel buffer and would retrieve the different
section tables with the same PID.

This is currently how our s/w works at the moment (only implementation
(a)).  I would like (if possible) to have implementations (a) and (b) as it
provides the required functionality for our own software as well as other
customers.  We are currently porting other customers "well known" s/w that
has functionality (a) not (b).

> > I would particularly be interested to hear from our Toshiba friends to
see
> > whether they use the START/STOP ioctls as well or whether we can
discard
> > them.

> Hm, I removed START/STOP to simplify things, but
> a) since we have DVB_DMX_ONESHOT the driver must deal with stopped
> filters internally anyway
> b) it might be easier for porting, and might give you a warm, reassuring
> feeling if you are able to set a filter for later use without starting
it.

> I'm not sure about this.

OK, let's see what other people think.  I still think it would be good to
provide this required functionality.

> I was thinking of adding a #define DVB_DMX_DEFAULT_BUFFER_SIZE 0
> to the API (it's up the the hw driver to determine an appropriate
> standard buffer size).

Yes, I also thought that this would be good as well as one for
DVB_DMX_DEFAULT_THRESHOLD.
This could function similarly to the existing V3 implementation for
backward compat.

> The intention is to make DVB_DMX_SET_* to replace any previous filter
> on the same fd, so it can be used to quickly change filter settings.

That's great!

Thanks,

Rob ; )






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