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

[Johannes Stezenbach <js@convergence.de>]

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

The idea of having multiple section filters on the same fd was dropped
because the consensus on the list was that it isn't worth the trouble.
It's not difficult for applications to open a few more file descriptors
and use poll() on them.

> a)  The ability to add more than one section filter with the same PID to a
> single fd.
> b) The ability to add more than one section filter with the same PID to
> separate fds.
> c) The ability to dynamically add section filters to an already running
> filter.

IMHO a) is superflous and c) is solved the b) way.
The hw driver will use the same PID filter internally for all section
filters on the same PID, if the hw requires it.


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

Hm, I removed START/STOP to simplify things, but
a) since we have DVB_DMX_ONESHOT the driver must deal with stopped
filters internally anyway
b) it might be easier for porting, and might give you a warm, reassuring
feeling if you are able to set a filter for later use without starting it.

I'm not sure about this.

Regarding performance: There is some overhead for opening a new
file descriptor (dentry lookups in the VFS layer etc.), but IMHO it
is negligible compared to the latency inherent to the low repetition
rates of SI data or random access point in MPEG streams. Memory
allocation for filter buffers could be optimized by having fixed
buffers for standard SI data, and only pass a different buffer
size for high-bandwidth stuff. I was thinking of adding a
  #define DVB_DMX_DEFAULT_BUFFER_SIZE 0
to the API (it's up the the hw driver to determine an appropriate
standard buffer size).


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

The intention is to make DVB_DMX_SET_* to replace any previous filter
on the same fd, so it can be used to quickly change filter settings.


Regards,
Johannes


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