[linux-dvb] Re: Linux DVB API 4 Q's

[Rob.McConnell@Zarlink.Com]

Hi Again,


Rob.McConnell@Zarlink.Com writes:
> > > Both, one section filter for several PIDs and several filters on one
> > > PID, would be useful to have on one file descriptor in some special
> > > cases. But both make the demuxer more complicated and only move
> > > complexity from user space into the kernel. It is not too hard to
> > > implement but I would really like to throw it out again ...
> >
> > As I understand the current API version 3 implementation allows you to
> > attach multiple section filters to a single fd, so I think we should
keep

> No, that is not possible. I am not sure if the documentation mentions
> it explicitely, but a DMX_SET_FILTER will overwrite previous settings
> and not add to them.

My mistake, sorry. ; ) I agree now that having multiple section filters on
a single fd is nonsense and just makes the driver too complicated.  Having
multiple section filters on a single PID is fine and having each of those
"attached" to a separate fd is what we want.  Having multiple PES filters
per fd would be useful for recording to a HDD.


> > this in V4.  Can I ask in what cases would you have one section filter
on
> > several PIDs?  I have never seen this requirement before, but maybe you
> > have come across this.

> You could set one filter e.g. for PMTs but on all PMT PIDs from the
> PAT. You can still keep them apart by reading the SID from the packet.
> But I do not think this is worth adding all the complexity to the
> driver.

Agreed.


> > OK, I just wanted to make sure that this was the correct method to use.
I
> > like the idea of having a separate logical demux device for each
> > simultaneous input source. : )

> It depends on how closely you want to stay to the actual hardware
> capabilities. The hardwares I know about have N demuxes and M inputs
> and each demux can choose one input. So, it makes sense to have separate
input
> and demux devices and then tell the demux which one to use.
> If each input has its own demux this would be a special case and if
> e.g. it is not possible to use input 1 with demux 2 you just return
> -EINVAL if the app tries to set that.

Agreed.


> > What about leaving the demux device alone and allowing it to choose say
> > front_end x = C/A module input.  Then we
> > need a C/A device that can set it's source to say external demod #1.
In
> > this case, h/w that does have the ability to route an input TS from say
an
> > external demod to a C/A module and then into the logical demux device
is
> > covered.  Also, h/w that does not have a C/A or C/I router will still
> > function the same i.e. demux selects the required front_end.

> That would be one possible way.
> Btw., I have a question regarding the new CI devices and how to
differentiate
> several CI adapters (not that I know receivers with more than one).
> If you have one CI device for each slot, you might want to call
> them ci0_0, ci0_1, ci1_1 etc. where the first number is the CI adapter
> unit and the second the slot. Your source setting calls to ciN_0 would
> be valid for all ciN_X and so on.

I have no problems with the adapter/slot method. Any more
comments/suggestions folks?

Rob : )







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