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

[Johannes Stezenbach <js@convergence.de>]

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

One can still add/remove filters dynamically on the same PID,
it's just that the driver won't combine the output of those
filters on one fd, you have to open one fd per filter. It's
just how the hardware works.


Johannes


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