[linux-dvb] RFC: Multiple TS recordings

Johannes Stezenbach js at linuxtv.org
Tue Apr 11 12:02:06 CEST 2006


Funny that no one seems to be interested in this. Maybe
PVRs are already out of fashion ;-/

On Mon, Apr 03, 2006, Felix Domke wrote:
> a.) can be fixed easily with the proposal i've once posted:
> 
> We redefine the "pes_type" element in the dmx_pes_filter_params into a
> new meaning.
> 
> Currently, dmx_pes_filter_params is used for 3 things:
> 
>  - sending a PES stream to a hardware decoder with
> .output = DMX_OUT_DECODER,
> .pes_type = DMX_PES_AUDIO0 / DMX_PES_VIDEO0 / ...
> 
>  - getting PES data into userspace with
> .output = DMX_OUT_TAP,
> .pes_type = DMX_PES_OTHER
> 
>  - getting TS data into dvr0 with
> .output = DMX_OUT_TS_TAP,
> .pes_type = DMX_PES_OTHER
> 
> 
> the "pes_type" field is totally unused in the DMX_OUT_TAP-case (which we
> are interested in) - it's always DMX_PES_OTHER. We could redefine it a
> bit, in a backward compatible way:

That is not entirely true. If you want teletext packets for
decoding *and* send them out via VBI within the driver at
the same time, you'd use DMX_OUT_TAP with DMX_PES_TELETEXT0.
At least that's how interpreted the API, but maybe it was
just a hack...

Also, it would be interesting to know how Werner uses the
API to do his VDR AC3 audio stuff.


> +typedef enum {
> +       DMX_TAP_TS,
> +       DMX_TAP_PES = DMX_PES_OTHER, /* for backward binary compat. */
> +} dmx_tap_type_t;
> 
> struct dmx_pes_filter_params
> {
>         __u16          pid;
>         dmx_input_t    input;
>         dmx_output_t   output;
> +       union {
>         dmx_pes_type_t pes_type;
> +       dmx_tap_type_t tap_type;
> +       };
>         __u32          flags;
>  };
> 
> now, we define
>  - getting TS data into userspace with:
> .output = DMX_OUT_TAP,
> .tap_type = DMX_TAP_TS
>  - getting PES data into userspace with:
> .output = DMX_OUT_TAP,
> .tap_type = DMX_TAP_PES

How about just adding the slightly inconsistently named
DMX_PES_OTHER_TS to the dmx_pes_type_t enum?

> for b.), i propose the following API extension:
> 
> +#define DMX_ADD_PID              _IO('o', 51)
> +#define DMX_REMOVE_PID           _IO('o', 52)
> 
> The semantic is that you first open a demux0, then setup all your
> parameters with DMX_SET_PES_FILTER (including TS filtering, if you want
> - in fact, it doesn't make sense for PES-filtering unless we have
> hardware mux support, i.e. copy full PES packets). You don't specify
> DMX_IMMEDIATE_START (normally).
...
> (In fact, a different thing to talk about would be hardware-DVR support
> (and i would could O(1)-software-demux-support into that...) - putting
> multiple 'TS'-type streams into a queue can often be hardware
> accelerated, by sharing one big queue. (This would also leave the timing
> intact, which is currently impossible, unless you get an interrupt on
> every packet)

Sounds good for a hack. But the bad thing about APIs is, that once
you've got them, you're stuck with them...
(this is neither a NACK nor an ACK)


Johannes



More information about the linux-dvb mailing list