[linux-dvb] V4 Demux API Q's

[Rob.McConnell@Zarlink.Com]

Hi Folks,

It's been a while since we had some conversations regarding the V4 api.
I've been doing other work for the past few months, but now I should
"hopefully" be back on the case. : )

I've had a look at the most recent V4 api demux stuff in CVS and have a few
Q's to ask.

Q1:   I'm not entirely clear how the source routing stuff will actually be
implemented for setting up an A/V decoder PID feed/filter on a logical
demux device and then routing that to an audio/video decoder(s).  Does the
DVB_DMX_SET_TS_DECODER_FEED ioctl setup the PID filter slot and begin
filtering immediately?  What does the DVB_VIDEO_SET_SOURCE ioctl then do
when you pass the fd of this PID filter?

My main concern is for h/w that I know that has the PID filters closely
associated with the A/V decoders.  For example, you may have preassigned
slots in the PID filter bank that provide a known video/audio stream to a
specific A/V decoder.  You may have slot 0 always assigned to provide a
video stream to video decoder #0, slot 1 to provide a video stream to video
decoder #1 and so on.  In this case, when we allocate a PID filter for a
decoder, we should specify for which decoder the stream will be directed
to.  The API currently doesn't support this, but I believe it should.  In
this case, the DVB_VIDEO_SET_SOURCE ioctl is redundant in that when you
allocate a PID filter for slot 0 on the demux device, the video decoder #0
will have the stream being input to it.

Another point worth mentioning is that the A/V stream output of say logical
demux device #0 does not necessarily imply that A/V decoder #0 will be fed
with this stream.   Consider a system with more than one audio/video
decoder pair in the system and you have say 2 input streams to the demux
hardware (i.e. 2 logical demux devices).  Now there are reserved PID filter
slots for the audio/video decoder feeds but each PID filter can choose the
input stream.  In this scenario, we cannot assume that the inputs to
audio/video decoders #0 will be from stream #0 that enters demux #0.  You
could easily have both A/V decoders fed from the same input stream or even
swapped over.

In this scenario the user would want to say, allocate me a video PID filter
for providing a feed to video decoder #0.  However, to do this would
require the knowledge of which decoder to provide the feed to when the
filter was initially allocated/setup.  Unfortunately, the API doesn't
provide this information.  It just says provide me a feed so I can get an
fd and then later issue a DVB_XXX_SET_SOURCE ioctl on the appropriate
decoder with the fd of the already initialised filter.  When we allocate
the decoder feed/filter, we need to know then whether we have any filters
left to do the job.  It's too late to setup a filter and then when we come
to issue the DVB_XXX_SET_SOURCE ioctl on the video/audio decoder to have it
return an error that we can't allocate more than one feed on the same A/V
decoder.

I recommend that we extend the "dvb_dmx_decoder_type" enums to have more
than one type of decoder in the system.

e.g. enum dvb_dmx_decoder_type {
                        DVB_DMX_DECODER_TYPE_PCR0,
            DVB_DMX_DECODER_TYPE_AUDIO0,
            DVB_DMX_DECODER_TYPE_VIDEO0,
            DVB_DMX_DECODER_TYPE_TELETEXT0,
            DVB_DMX_DECODER_TYPE_SUBTITLES0,

                        DVB_DMX_DECODER_TYPE_PCR1,
            DVB_DMX_DECODER_TYPE_AUDIO1,
            DVB_DMX_DECODER_TYPE_VIDEO1,
            DVB_DMX_DECODER_TYPE_TELETEXT1,
            DVB_DMX_DECODER_TYPE_SUBTITLES1,

etc.

In this way, we can specify which decoder will be assigned the feed along
with the PID.  The DVB_XXX_SET_SOURCE ioctl on the video and audio decoder
devices can simply do nothing for h/w where the stream is automatically
passed directly to them from the filters.

Q2:  In the "dvb_dmx_capability" enum definitions shouldn't we have a
definition for the number of PID filters available for general PID
filtering?  e.g. DVB_DMX_CAP_PID_FILTERS.  I guess we would have to
distinguish between the total number of PID filters available including
AUDIO/VIDEO/PCR/SECTION and the actual number of general purpose PID
filters.

Is the DVB_DMX_CAP_SECTION_FILTERS the number of actual PID filters
available for section filtering, or the actual number of section filter
blocks available?

Q3:  For setting up recording PIDs, I would have thought we would have
wanted the DVB_DMX_PAYLOAD_ONLY flag as an option.  The problem is, if we
have it as a flag per PID, then one could be clumsy and have this flag set
for some recording PIDs and not for others on the same fd.  This would
probably cause havoc!   Would it be better to also have a global flag field
for the "dvb_dmx_recording_filter" for such flags as this one and
DVB_DMX_OUTPUT_DUPES and DVB_DMX_OUTPUT_ERRPKTS?


That's all the comments I have at the moment on the demux side of things
for V4.  I think it is probably best to keep with this API for the moment
rather than the alternative one, as it keeps things relatively
straightforward and is not too distant from the current V3 API.  What do
other people think?

Cheers,

Rob : )





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