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.