[linux-dvb] More V4 Demux API Q's

[Rob.McConnell@Zarlink.Com]

Hi Again,

Here are some more thoughts/concerns that I have with the V4 API.

1)   What is the functionality of the "DVB_DMX_SET_SECTION_FILTER" ioctl?
When you open an fd on a demux device and then issue this ioctl, can you
then call this same ioctl again to allocate more than one section filter on
the same pid and same fd?  If you issue this ioctl on an already
instantiated section filter, does the existing filter get closed down and
then reopened with the new section filter spec?

Requirements:   After discussion with application developers internally and
externally it has been understood that there are 3 requirements for adding
section filters.

a)  The ability to add more than one section filter with the same PID to a
single fd.  In this case, the middleware software will have to perform the
actual separation of the tables by looking at the table id.  This is
straightforward from some h/w perspectives where you cannot physically
setup more than one feed with the same PID value.  In this case, you would
have a single feed with multiple section filter specs attached and all
matches would be dumped into an internal hardware buffer and copied to a
kernel buffer which a user process would read.

b) The ability to add more than one section filter with the same PID to
separate fds.  In this case, the middleware will be able to setup separate
"threads" for each fd to monitor whether that section filter was available.
This is equivalent to the V3 API.

To answer point 1) with these requirements would mean that you could add
more than one section filter with the same PID on the same fd.  If you
wanted more than one section filter with the same PID but separate fds, you
would simply open the demux device that number of times to obtain the
separate fds (same as V3 API).

c) The ability to dynamically add section filters to an already running
filter.  This would follow on from a) where you could add more section
filter specs with the same PID to an existing fd.  Complicated I agree, but
we are having to implement this anyway on our current project : (


2) The issue of STARTING and STOPPING a filter has cropped up again.  It
would definitely be easier to discard these ioctls as you wouldn't have to
worry about the state of a filter.  However, current thinking is it would
be beneficial to have these ioctls anyway as it is used in software that we
have today and other customer's software.  We have found on our h/w that it
is quicker to stop a running filter, change the filter spec and start it
again compare with closing the fd down, opening a new fd and setting it up
with the filter spec.  The actual setting up the filter for the first time
is time consuming in terms of allocating memory, setting up h/w registers,
irq's etc.   I am having to implement these horrible ioctl's in my current
demux implementation for backward compatibility as well as satisfying
customers needs.

I would particularly be interested to hear from our Toshiba friends to see
whether they use the START/STOP ioctls as well or whether we can discard
them.

3) Are we allowed to use the ioctl "DVB_DMX_SET_TS_DECODER_FEED" on an
already instantiated/running decoder filter/feed to change the filter spec?
In this case, the conception would be for the filter to be stopped
internally, registers reset and the new filter spec. applied before the
filter is restarted.  If not, does it simply return -EBUSY?  The same
question also goes for the ioctl "DVB_DMX_SET_PID_FILTER".

That's all 4 now,

Rob : )





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