[linux-dvb] Re: [RFC] Limitations of current filtering

[Roberto Ragusa <r.ragusa@libero.it>]

On Fri, 05 Dec 2003 15:45:09 +0100
Holger Waechtler <holger@convergence.de> wrote:

> > a) is very easily solved; I just tried to comment the
> > TS_PAYLOAD_ONLY flag around line 657 of dmxdev.c and
> > the packets are not modified anymore. A new flag
> > will be enough (sadly, the obvious name "DMX_OUT_TS_TAP" is
> > already taken by dvrY and renaming it to "DMX_OUT_TS_TAP_DVR"
> > would break source code compatibility).
> 
> If you invent a good flag name I think this change would be ok as 
> extension in V3, it can easily get checked by applications - they just 
> need to look whether the new flag is defined.

Is DMX_OUT_TAP_188 good enough?


> > b) needs a deeper change, because we have to remove the
> > assumption that "one filter (pid) per open file". I think
> > it can be done with the introduction of a list of filters
> > and ioctls to add/remove filters (instead of just "set").
> 
> We should postpone this, such a change is hard to implement when we need 
> to maintain API compatibility.

Hard but not impossible.
We currently have DMX_SET_FILTER and DMX_SET_PES_FILTER (hmm, another
case of data recording implemented in a second time).
The current behaviour is that one of those will set the filter
of the involved file descriptor, replacing an existing filter.

I would extend it by introducing a new flag for dmx_pes_filter_params,
called, let's say, DMX_OVERLOAD or, maybe, DMX_APPEND or DMX_STACK.

If this bit is set the existing filter (well, existing filters) are
not replaced. Simply a new PID is added.
For simplicity, dmx_input_t input and dmx_output_t output are checked
to be the same as in the first filter and (not sure about it)
dms_pes_type_t pes_type is checked to be DMX_PES_OTHER. If some
condition is not verified then the operation fails, and with failure I
refer to the replacement taking place despite of the flag.

This extension would be perfectly compatible to old apps.

API issues solved, a good implementation is doable IMHO.

> > At that point dvrY is totally useless and it could be theorically
> > removed (but it's better to not break existing apps, of course).
> 
> We should keep it in v3, in v4 it will vanish anyways. The DVR device is 
> still required for MultiPID-TS filters when we don't implement b).

I saw that v4 has "recordind filters" that are more or less what I'm
trying to do.
Is dvr totally redundant in v4? (read about what I said in a previous
reply about one program setting pids, another reading packets).

> > I could try to hack the code myself, but maybe someone else
> > with more knowledge of the dmx_core internals can do it more
> > easily than me.
> 
> :) no - code should always get implemented by the one who needs it...

Hehe :-) I tried.

I'd continue with

 ...under the guide of the ones who know the environment better than him

-- 
   Roberto Ragusa    r.ragusa at libero.it


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