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

[Ralph Metzler <rjkm@metzlerbros.de>]

Rob.McConnell@Zarlink.Com writes:
 > Could you run through the advantages of the SET ioctl over the add/del.
 > Personally I would still rather stick with ADD/DEL as user applications
 > would typically use these methods to set up PES filters when changing a
 > programme or as and when required.  I guess the SET ioctl would only
 > benefit if you had quite a few PIDs that you knew beforehand to setup, but
 > once you had set them up, would you still use the SET ioctl to add >1 PIDs
 > again? What about channel changes - are there many PIDs to be setup at once
 > or individually? Maybe having both interfaces would be best... what do
 > people think?


The only difference would be the number of system calls (not that
critical in this case).
The user program would probably use some kind of add/del functions
anyway to add/del PIDs to/from the argument of the set call.
So, you are right, just using ADD/DEL would be easier and circumvent
the problem with different flags. 


 > > I thought they are not needed for PID and SID filters (the PID/SID is the
 > id).
 > > For section and sid filters, I think *I* don't need multiple filters per
 > file
 > > descriptor. If you really want them, protest load enough ;-)
 > 
 > As long as we have the capability to add multiple PID filters to an fd for
 > a TS or PES output, then that should be OK (e.g. for recording to HDD).
 > For section filtering, I suppose it would make sense to have different fds
 > for the same PID but different table id.  Is this the intention here?

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

 
 > *** Now for the new Q's: ***
 > 
 > 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?


 > B. In s/w, I need a means to route a TS from say an external demod to an
 > external descrambler hanging off the common interface.  Also, I need to be
 > able to select the source type for a PID filter to be from this C/I.  Can
 > we add a source selection ioctl for the C/A or C/I?
 > 
 > e.g. DVB_CI_SET_SOURCE or DVB_DMX_SET_CI_SOURCE
 > 
 > This could use the "dvb_dmx_src_type" as the input source selection.
 > 
 > What about catering for multiple C/I or C/A modules? Should we have a
 > logical device for each C/A and a source selection ioctl as above?  For
 > example, C/A module #1 could have a feed from demod #1 and C/A module #2
 > could have a feed from demod #2.
 > 
 > Where conceptually does the C/I or C/A sit in the flow of data from a
 > front-end in terms of the API? Does it sit between the frontend and demux
 > like it should?

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, ...
 
 > C. Why have the filter types TELETEXT and SUBTITLE been removed?  If
 > someone has a dedicated piece of h/w to do SUBTITLE or TELETEXT decoding
 > then shouldn't we still have this option here?

I agree.

 
 > D. If h/w can generate an interrupt when we have received a full packet
 > (PES level filtering) or when a certain number of bytes have been
 > delivered, how does the API allow this threshold to be set?  For example,
[..]
 > Also, the filter type such as SUBTITLE or VIDEO would be useful to know how
 > to handle the data (buffer size, c/b function, etc.).
 > 
 > Any thoughts?

Somebody proposed such calls before here. They would be very useful for some hardware.


Ralph

 


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