Johannes Stezenbach wrote:
> To me it looks like v3 will not be obsoleted by v4 anytime soon
> (I think it's a pity, but it's not up to me). So it make very
> much sense do do some enhancements for v3.
I know it's a pity :/, so let's make the best out of it.
Maybe it would be easier if there would be a wrapper/layer which makes
v4 device drivers compatible to v3 (or v3 userspace). (i have to admit
that i never looked at the v4 core implementation - but i guess they
differ a lot).
That would allow us to port the device drivers to v4 *and* still
maintain them with a large userbase.
Anyway - we have v3, and have to keep it for a while.
ok, my simple proposal is:
- make dmx_pes_type_t union with another enum:
struct dmx_pes_filter_params
{
...
union {
dmx_pes_type_t pes_type;
dmx_tap_type_t tap_type;
};
..
};
- and add, backward compatible, the different TAP types.
typedef enum
{
DMX_TAP_PES = DMX_PES_OTHER, /* for backward binary compat. */
DMX_TAP_TS
} dmx_tap_type_t;
implementation of this in the core would be probably as easy as
linux/drivers/media/dvb/dvb-core/dmxdev.c:
@@ -643,7 +643,11 @@ static int dvb_dmxdev_filter_start(struc
ts_type |= TS_PACKET;
if (otype == DMX_OUT_TAP)
- ts_type |= TS_PAYLOAD_ONLY|TS_PACKET;
+ {
+ ts_type |= TS_PACKET;
+ if (ts_pes == DMX_TAP_PES)/*i.e. DMX_PES_OTHER*/
+ ts_type |= TS_PAYLOAD_ONLY;
+ }
(untested)
this would solve the first problem, getting the TS data.
(I know the naming of "pes filters" sucks, but that's comes from the
very old "napi" legacy. this one at least cleans up the "pes_type" mess
and makes this field useful again. :)
thoughts?
for the second one (only one DVR device), i'd like to completely stop
using DVR devices for reading data, it just doesn't belong there. (of
course it must be kept for backward compatibility).
so my proposal is to add a DMX_ADD_PES_FILTER, which, as the name says,
adds a filter. it could be used instead of DMX_SET_PES_FILTER, just that
it doesn't reset other filters. to reset the filter, you have to close
the fd or use DMX_SET_PES_FILTER. implementation of this isn't so easy,
as currently exactly one filter is associated with each fd (or am i
wrong here? i'm not soo familiar with the core), and a dvr buffer must
be allocated (as some hardware devices can't do multi pid filtering into
one queue - well, most hardware devices can't ;)
Felix
