Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linux-dvb] Re: [RFC] Limitations of current filtering
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.
Home |
Main Index |
Thread Index