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 [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.