[linux-dvb] Several TS streams from DVR device?

[Johannes Stezenbach]

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