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

[Holger Waechtler <holger@convergence.de>]

Roberto Ragusa wrote:
> Hi all,
>
> this posts is about discussions started in a different thread
> ("[linux-dvb] Re: [PATCH?] proposed rewrite of skystar2 filters",
> Wed, 03 Dec 2003 20:24:42 +0100)
>
> There are currently two ways to get data from a TS (I'm
> considering DMX_TYPE_PES only):
>
> 1) DMX_OUT_TAP
> 2) DMX_OUT_TS_TAP
>
> With DMX_OUT_TAP:
> - we setup the filter trough /dev/dvb/adapterX/dmxY
> - we get data from /dev/dvb/adapterX/dmxY
> - we get payload only
> - we get one pid for each opened /dev/dvb/adapterX/dmxY
>
> With DMX_OUT_TS_TAP:
> - we setup the filter trough /dev/dvb/adapterX/dmxY
> - we get data from /dev/dvb/adapterX/dvrY
> - we get transport stream (first byte is 0x47)
> - we get a multiplexed stream of all the requested pids
>
> The TS_TAP method has a big limitation; there is only
> one /dev/dvb/adapter/dvrY device, so it's not possible
> to read two sets of pids (as it's necessary when one wants
> to separately record two television channels with
> identical frontend settings).
>
> Introducing additional dvrY (for example dvrY0, dvrY1, ...) is not
> enough because a way to ask for a specific dvrYZ is needed when
> setting the filter. There is also a problem with dvrXY
> allocation (choosing the first Z available).
>
> TAP instead has everything we need, if we remove two limitations:
> a) it can give unmodified ts packets
> b) it accepts a multipid filtering
>
> 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.

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

> 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'm open to suggestions on the matter.
>
> 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...

Holger



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