[linux-dvb] Re: V4 Demux API Q's

[Johannes Stezenbach <js@convergence.de>]

Hi Rob,

nice to read you ;-)

Rob.McConnell@Zarlink.Com wrote:
> 
> 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?

Well, obviously one cannot allocate the filter before the connections
are set up. Maybe it's possible to check if any of those special-purpose
filters are available at all, but essentially DVB_DMX_SET_TS_DECODER_FEED
would just set some state in the driver, and the real work happens in
DVB_XXX_SET_SOURCE (unless the hardware has no special decoder-filters).

[snip]
> 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.

If the decoder is not currently connected the associated decoder-filters
cannot be in use, thus DVB_XXX_SET_SOURCE will always succeed (at least
wrt filter allocation). If the decoder is already connected
DVB_XXX_SET_SOURCE will just change the decoder filter settings.

Or did I miss something?

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

That's too V3'ish...


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

Capabilities are not clearly defined yet. Maybe you could just tell me
which way you'd like it best?


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

DVB_DMX_PAYLOAD_ONLY works only for simple PID filters. It doesn't make
sense to mash data from multiple PIDs together when dropping the packet
header with the PID. Except for the case where one would record PES
only, but because video PES packets are unbound in size the driver does
not support PES packet reassembly. That's left for applications.

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

I've ported szap to the new API, and it was considerable work because
of all the renamed ioctls and types/enums (mostly adding the DVB_ prefix).
Otherwise I think the new API is quite simple to use (at least for
simple things ;-).


Regards,
Johannes


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