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

[Ralph Metzler <rjkm@metzlerbros.de>]

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.


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


 > > > A. If we want to route a TS/PS/PES off a DVD or HDD through a PID
 > filter,
 > > > then I guess we would have to setup the source type of the filter to be
 > > > "DVB_DMX_SOURCE_FRONTEND" with the correct "frontend_num". The same
 > goes
 > > > for an input from an external C/A modules or LVDS, etc.  Is this the
 > > > intention?  Does the term "front-end" really make sense?
 > 
 > 
 > > See the discussion about general input devices. I do not care if they
 > > are all called input or frontend but they should be treated equally.
 > > Normally the demuxes can choose one of the inputs of the whole demux
 > > block as source and you cannot bypass this. So, data should be
 > > written to a frontend/input device and not to a demux. If you can
 > > bypass this, then one could always make writing directly into
 > > the demux device possible just for this hardware.
 > > Or how do you handle the case if two demuxes are supposed to process
 > > the same data from memory?
 > 
 > 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.

 
 > > Hmm, OK, so not all demods do directly hang on an input of the demux
 > > block. Either we use separate devices for demods (and other sources?)
 > > which can select targets and the input device sets sources, or we just
 > > let the input devices choose exactly one filter (i.e. CI).
 > > For anything more complicated you better invent a general Linux
 > multimedia
 > > device architecture with general sources, filters and targets and
 > > use it for sound, V4L, DVB, ...
 > 
 > 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. 


Ralph




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