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
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
