Felix Domke wrote:
> 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*/
I'm a bit confused, but I guess this should be:
+ if (ts_pes != DMX_TAP_TS)
> + 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 ;)
I'm pondering if it would not be better to add the full
recording filter API from v4. OTOH, v4 rec filters are
somewhat overfeatured and complicated, and the public
PCI/USB drivers would not really benefit from the additional
features because of missing hardware, so maybe your propsal
is better. I need to sleep over this...
Opinions?
Johannes
