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

[Rob.McConnell@Zarlink.Com]

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

We should definitely allow multiple section filters to be attached to a
single PID.  I need it for my design and I will end up implementing anyway
(nobody else will on our team). A simple linked list of section filters
attached to a feed is all that is required, plus the ability of the
user-space to call the DVB_DMX_SET_SECTION_FILTER more than once with the
same pid but different filter spec.

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

I agree that setting up more than one PID filter for recording would be
easier, but hey - how many pids are you really gonna need?  1 for the
video, 2 for the audio, 3 for subtitles.  You would already have setup the
SI/PSI PIDs in previous call(s) so I don't see a problem with having the
ADD ioctl here.  Let's see if we can have both SET and ADD/DEL ioctls.

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

Let's see if we can just implement the several filters on a single PID/fd.
That would be useful.

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

OK.

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

Having the C/A device choose the front-end and allowing the demux device to
choose a front-end including the output from the C/A would be the easiest
implementation.  I think you will find more devices on the market which
offer this flexibility and hey you never know who may copy our design : )

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

Yes I agree, but if we have the generic OTHER type then that has to cover
the general case of PES data, say.  We have subtitle data, MHEG, MHP,
private, etc. but we may need different ways to demux the data.  Going back
to the buffer/threshold point I made earlier, it would be nice to
distinguish the type of data to demux so that we can setup the required
buffer size/thresholds or other characteristics.

> >  > 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 ;-)

Please add this, for example.

#define DVB_DMX_SET_BUFFER_THRESH   _IO(DVB_IOCTL_BASE, 0x??)

#define DVB_DMX_BUFFER_THRESH_NONE        0     /* No threshold interrupt
generated */
#define DVB_DMX_BUFFER_THRESH_TS_PKT      1     /* Threshold interrupt
generated after receiving a TS packet */
#define DVB_DMX_BUFFER_THRESH_PES_PKT     2     /* Threshold int generated
after receiving a full PES packet */
#define DVB_DMX_BUFFER_THRESH_1QTR        3     /* Buffer 25% full
generates a threshold interrupt */
#define_DVB_DMX_BUFFER_THRESH_1HALF       4     /* Buffer 50% full
generates a threshold interrupt */
#define DVB_DMX_BUFFER_THRESH_3QTR        5     /* Buffer 75% full
generates a threshold interrupt */

Numbers greater than say 100 would actually mean the number of bytes to
receive before generating a threshold interrupt.  e.g. If the value of 256
is passed to the ioctl, then each time 256 bytes are received by the h/w
you will get a threshold interrupt and this number of bytes would then be
gobbled by the callback function.

Hope this clarifies the situation : )

Cheers,

Rob ; )






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