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

[Rob.McConnell@Zarlink.Com]

                      Johannes                                                                                                   
                      Stezenbach               To:       linux-dvb@linuxtv.org                                                   
                      <js@convergence.d        cc:                                                                               
                      e>                       Subject:  [linux-dvb] Re: More V4 Demux API Q's                                   
                      Sent by:                                                                                                   
                      linux-dvb-bounce@                                                                                          
                      linuxtv.org                                                                                                
                                                                                                                                 
                                                                                                                                 
                      13-Apr-2004 02:03                                                                                          
                      PM                                                                                                         
                                                                                                                                 
                                                                                                                                 











> On Tue, Apr 13, 2004 at 11:42:07AM +0100, Rob.McConnell@Zarlink.Com
wrote:
> > Hi Johannes,
> >
> > Thanks for getting back to me on this ; )
> >
> > > - one section filter per fd
> > > - multiple section filters for the same PID (on different fds)
> > > - section data is copied from hw DMA buffer of the PID filter
> > >   to the output buffer of the corresponding section filter fd
> >
> > This certainly is more s/w + CPU overhead for h/w that has a single
buffer
> > for all section filters associated with a common PID to drop into.

What a load of bolx I am talking ; )  Please read on to see what I mean...

> >
> > > Note: The (non-av7110) hw I know puts tags into the section
ringbuffer
> > > of the PID filter, so software can determine which section filter
> > > matched.
> >
> > The h/w that I am familiar with also performs tagging.  Is there any
h/w
> > out there that actually has multiple section filters attached to a
single
> > PID with a single h/w output buffer *WITHOUT* tagging?  If this were
the
> > case, then it would make the task of demuxing the h/w circular buffer
much
> > more CPU intensive/a nightmare.  I wonder if there is more h/w out
there
> > that matches what I am used to rather than the AV7110?  If this were
the
> > case, wouldn't it make more sense to support the majority of h/w rather
> > than legacy h/w such as the AV7110?

> If you have tags mixed with section data in your hw ringbuffer, then
> the driver will have to copy section data anyway to an output
> buffer to remove the tags. Or, if you want to pass the tags to
> userspace, you would have to convert the tags to a hw independent
> format so userspace software would be portable.

> And since we have the requirement of supporting multiple section filters
> for the same PID on different fds, we need to do the copy anyway.
> (Assuming hw does not support multiple "feeds" for the same PID.)

Yup.  We currently allow the option (using an ioctl) to either strip off
the tagging or pass it up to userspace with a little translation.  In both
cases, we do a copy from the h/w buffer to a kernel buffer upon which a
process can read.  So in short, yes there is no performance gain/loss using
either method - you are quite right ; )  Incidentally, we do the stripping
or translation in the callback from the interrupt (tasklet).

> > Incidentally, it looks as though I will have to diverge from the V4 API
to
> > support customers who insist on having a single fd to read back all the
> > section tables associated with a single PID :(

> That does not help to convince me.
> One can use poll/select to process multiple section filters in
> userspace. So I don't see a real need for multiple section filters
> per fd, it is just a "nice to have" thing. Am I wrong?

Nope, your right again. We will have to provide a wrapper for these
existing customers which insist on using a crapulant api.

I have had some good discussions with a colleague of mine and we have both
agreed that the new V4 api is much cleaner and provides finer granularity
in terms of section filter control/buffer management.  Having a linkage
between the fd, section filter id, and kernel buffer makes more sense than
fd, multiple section filter ids and single common kernel/hw buffers.  So
let's put this one to bed once and for all!

Cheers,

Rob : )

P.S. Sorry if I have given you a headache on this one ;^)



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