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

[Johannes Stezenbach <js@convergence.de>]

Ralph Metzler wrote:
> 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. 

SET vs. ADD/DEL is simpler in that it implicitly prevents
inconsistent flag settings, e.g. one filter with
DVB_DMX_OUT_MEMORY and the ADD one without DVB_DMX_OUT_MEMORY.

The current API only allows one filter per fd, so when converting
old sw to the new API it doesn't matter.

For recording, IMHO one wants to set all PIDs at the same time; OTOH
if one wants to smoothly adjust the recorded PIDs during the recording
(e.g. recording two movies in succession and a second audio channel
exists in the second movie), the ADD/DEL stuff might come in handy.

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

ACK


> Or how do you handle the case if two demuxes are supposed to process
> the same data from memory?

Good point. Not that I think that this case will be used much in
practise, but we shouldn't prevent it from in the API design.

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

The point is, that all hardwares I know about use a fixed routing from
frontend through CI the demux. Zarlink hw seems to be different, but
a general model for arbitrary input routings would complicate the API
too much. It's easier for you to have a proprietary API extension to
switch inputs according to your hw's capabilities.

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

The focus is demuxing, not decoding. The demux hw that I know has special
audio/video/pcr filters, but teletext/subtitles is handled by general
purpose filters. For decoding one would have a teletext/subtitle
decoder device and connect it to the demux filter fd similar to
audio/video.
 
>  > 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.

Yes, they are one my TODO list. If you post a detailed suggestions it
will be easier for me to add them ;-)


Johannes


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