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