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

[Rob.McConnell@Zarlink.Com]

> Rob.McConnell@Zarlink.Com wrote:
> > Johannes Stezenbach wrote:
> >
> > > 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).
> >

> I think usually there is one DMA buffer per section filter, whether
> they are on the same PID, same fd or not. (The av7110 driver uses
> software section filtering now, but usually one would use hardware
> section filters if they are available.) The common PID filter for
> multiple section filters on the same PID is handled within the
> driver and not visible in the API. The V3 implementation has
> a layer of additional buffers for the "kernel demux API" thing,
> but I try to get rid of that in V4. But if one would allow
> the output of multiple filters on the same fd, one would need an
> additional output ringbuffer, plus copying.

OK, so the AV7110 functions differently to the h/w that I am familiar with.
In fact, on this h/w there isn't one DMA buffer per section filter but
rather the output of all section filters attached to a single PID feed get
DMAed to a single h/w buffer.  In this case, the s/w would have to do the
additional work of separating the tables by their ID and copying the data
to separate circular kernel buffers each associated with a process on a
different fd.  There is certainly more s/w overhead in the driver to
implement this, rather than allowing the complete section tables to be
allowed up to user space and the middleware to perform the filtering on the
single fd.

I think we shouldn't be too blinded with h/w that we are familiar with on
cards, but rather look at what is out there on real STBs as well.  Having
both methodologies would allow one to have optimum performance wrt the
actual h/w (less time spent in kernel mode doing copies/etc.) and would
also provide a flexible interface to the mad user-app folk out there ; )

TTFN,

Rob : )






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