aboutsummaryrefslogtreecommitdiff
path: root/include/linux/dvb/dmx.h
AgeCommit message (Collapse)Author
2008-04-24V4L/DVB (7293): DMX_OUT_TSDEMUX_TAP: record two streams from same mux, resendPeter Hartley
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 <pdh@utter.chaos.org.uk> Acked-by: Andreas Oberritter <obi@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-25V4L/DVB (3727): Remove DMX_GET_EVENT and associated data structuresAndreas Oberritter
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 <obi@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2005-12-12[PATCH] V4L/DVB: (3086c) Whitespaces cleanups part 4Mauro Carvalho Chehab
Clean up whitespaces at v4l/dvb files Signed-off-by: Mauro Carvalho Chehab <mchehab@brturbo.com.br> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-12-12[PATCH] V4L/DVB: (3086c) Whitespaces cleanups part 3Mauro Carvalho Chehab
Clean up whitespaces at v4l/dvb files Signed-off-by: Mauro Carvalho Chehab <mchehab@brturbo.com.br> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
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!