kernel/linux.git/include/linux/dvb/dmx.h, branch v2.6.26.3

V4L/DVB (7293): DMX_OUT_TSDEMUX_TAP: record two streams from same mux, resend

2008-04-24T17:07:46+00:00

Currently (in linux-2.6.24, but linux-dvb hg looks similar), the dmx_output_t in the dmx_pes_filter_params decides two things: whether output is sent to demux0 or dvr0 (in dmxdev.c:dvb_dmxdev_ts_callback), *and* whether to depacketise TS (in dmxdev.c:dvb_dmxdev_filter_start). As it stands, those two things can't be set independently: output destined for demux0 is depacketised, output for dvr0 isn't. This is what you want for capturing multiple audio streams from the same multiplex simultaneously: open demux0 several times and send depacketised output there. And capturing a single video stream is fine not what you want: you want multi-open (so demux0, not dvr0), but you want the TS nature preserved (because that's what you want on output, as you're going to re-multiplex it with the audio). At least one existing solution -- GStreamer -- sends all its streams simultaneously via dvr0 and demuxes again in userland, but it seems a bit of a shame to pick out all the PIDs in kernel, stick them back together in kernel, and send them to userland only to get unpicked again, when the alternative is such a small API addition. The attached patch adds a new value for dmx_output_t: DMX_OUT_TSDEMUX_TAP, which sends TS to the demux0 device. With this patch and a dvb-usb-dib0700 (and UK Freeview from Sandy Heath), I can successfully capture an audio/video PID pair into a TS file that mplayer can play back. Signed-off-by: Peter Hartley Acked-by: Andreas Oberritter Signed-off-by: Mauro Carvalho Chehab

V4L/DVB (3727): Remove DMX_GET_EVENT and associated data structures

2006-06-25T04:57:47+00:00

The ioctl DMX_GET_EVENT has never been implemented. I guess no software is using it because of its lack of implementation. Future software won't use it, too, because this API doesn't make much sense the way it is: Frontend events have their own different API. Scrambling events can't be generated in a useful way by the hardware I know of. Signed-off-by: Andreas Oberritter Signed-off-by: Mauro Carvalho Chehab

[PATCH] V4L/DVB: (3086c) Whitespaces cleanups part 4

2005-12-12T16:57:44+00:00

Clean up whitespaces at v4l/dvb files Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] V4L/DVB: (3086c) Whitespaces cleanups part 3

2005-12-12T16:57:44+00:00

Clean up whitespaces at v4l/dvb files Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Linux-2.6.12-rc2

2005-04-16T22:20:36+00:00

Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!