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

[Rob.McConnell@Zarlink.Com]

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

Ah, OK we will hide the actual implementation detail from the user.  The
fact that the ioctl "DVB_DMX_SET_TS_DECODER_FEED" sounds like it does a lot
more than what it will do in reality, doesn't matter.

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

Shouldn't the statement "If the decoder is already connected
DVB_XXX_SET_SOURCE will change the decoder filter settings." above be
referring to "DVB_DMX_SET_TS_DECODER_FEED" instead?

e.g.

1) Open fd on logical demux device #0.
2) Call DVB_DMX_SET_TS_DECODER_FEED with appropriate settings to internally
setup a state and remember what pid was required.
3) Call DVB_XXX_SET_SOURCE with the fd of this filter to do the real work
in providing a feed for the required A/V decoder.  The actual PID filter
hardware would be setup to provide a real feed for the decoder.
4) Issue DVB_DMX_SET_TS_DECODER_FEED with a new filter spec on the fd to
change the filtering spec.  The internal demux driver would know that a
feed was already "connected" and would then actually perform the required
filter changes rather than calling DVB_XXX_SET_SOURCE which doesn't make
sense from an API point of view.

I was assuming that you would allow the filter spec to be changed
on-the-fly without having to first close the fd down and then open up a new
fd and setup the filter spec.  If I was wrong and you did want to close
down the fd, reopen it and then assign a new filter spec, how would the
associate A/V decoder "know" that you had disconnected it's feed?  There
isn't an ioctl to disconnect the feed for an A/V decoder and as we are
working on the actual fd of a demux filter, this may leave us in a sticky
mess.

You could get the scenario where you closed down a demux feed fd and
reopened another one only to find it had the same fd handle and references
in the old decoder would still point to the old demux feed fd.  It might be
a good idea to have a DVB_XXX_SET_SOURCE and DVB_XXX_CLEAR_SOURCE ioctls to
prevent any old fds/etc. from lying around and to keep internal state
machines in check.  Just a thought to chew on...

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

> That's too V3'ish...

That's ok, just a thought.

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

I would prefer to have the section/recording/general purpose PID filters
all grouped together under one definition such as
DVB_DMX_CAP_NUM_PID_FILTERS.  Then, DVB_DMX_CAP_NUM_SECTION_FILTERS would
refer to the number of section blocks that the hardware/software could
provide.  It might be better to rename this definition to make it more
clear, such as DVB_DMX_CAP_NUM_SECTION_BLOCKS.

I would also add DVB_DMX_CAP_NUM_TELETEXT_FILTERS and
DVB_DMX_CAP_NUM_SUBTITLE_FILTERS for h/w that supported these to keep
things consistent.

Hope this helps ; )

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

Yup, that's OK.  What about the cases DVB_DMX_OUTPUT_DUPES and
DVB_DMX_OUTPUT_ERRPKTS - would it make sense to keep these global flags or
per pid flags or ignore them completely?

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

Yes, I noticed this when I did a cvs update with the -d flag ; )  Good
work!

Cheers,

Rob ;^)






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