[linux-dvb] RFC: Multiple TS recordings

Klaus Schmidinger Klaus.Schmidinger at cadsoft.de
Tue Apr 11 12:12:17 CEST 2006


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

Well, VDR can record multiple programmes from the same
transponder, if that's what the OP meant. But it does this
by simply requesting all the necessary PIDs and putting the
TS packets together itself.

Klaus

> 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