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

[Johannes Stezenbach <js@convergence.de>]

On Tue, Apr 13, 2004 at 06:14:11PM +0100, Rob.McConnell@Zarlink.Com wrote:
> 
> > Well, I think if you write a simple zapping application you would
> > statically allocate filters for audio, video, pcr, and allocate
> > and set filters for PAT, PMT, EIT-p/f. Then for zapping you just
> > set some PIDs and stop/start the filters.
> 
> A zapping app would indeed setup the A/V/PCR pids and start providing
> streams to the decoders.  As for SI/PSI then I don't see the difference
> between setting a filter and it starting immediately or setting a filter
> and starting/stopping it later.  Yes, PSI/SI filters would have to be
> dynamically allocated/set, but why would you want to start/stop them at a
> later time rather than just have them start immediately or simply
> remove/stop them (close the fd)?

I mean one does not have to release filters before tuning, and then
allocate, set and start a new filter. One could just stop, tune, start
(for PAT, SDT, EIT).

There is some overhead involved with open() (lookup the device node by
name etc.), so one could argue that separate DMX_STOP and DMX_START
ioctls would be valuable. But currently I don't think that the
overhead is significant, so I left START/STOP out of the API
to simplify driver-internal state handling.

> > Linux, however, is a multitasking system, and allocation needs to
> > be more dynamic. Especially with MHP which can take over control
> > of zapping completely. Linux DVB software should release unneeded
> > resources, and must be prepared that setting a filter can fail
> > anytime.
> 
> I haven't looked at MHP, so do MHP apps make the distinction between
> allocation, setting and start/stopping of filters/feeds?

Not really. There is a separated resource management API though,
but applications must be aware that resources can be withdrawn
anytime, and setting/starting an allocated filter can also fail
for various reasons...

> One of the main arguments I have for providing this distinction in the V4
> API is to allow compatibility for existing STB API's that have been ported
> to Linux.  However, I do understand that this will mean extra complexity in
> terms of handling the state of a filter/feed, but this would at least
> provide the flexibility that a DVB API should have.

Well:
- we allow more than one section filter with the same filter data
  on the same PID in the API (e.g. two apps getting the PAT)
- but hw does not allow that -> the driver must use the same hw
  filter and duplicate the data to both fds

-> filter allocation depends on data for filter setting

Do you see the problem?


Regards,
Johannes


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