DMX_ADD_PID allows to add multiple PIDs to a transport stream filter
previously set up with DMX_SET_PES_FILTER and output=DMX_OUT_TSDEMUX_TAP.
DMX_REMOVE_PID is used to drop a PID from a filter.
These ioctls are to be used by readers of /dev/dvb/adapterX/demuxY. They
may be called at any time, i.e. before or after the first filter on the
shared file descriptor was started.
They make it possible to record multiple services without the need to de-
or re-multiplex TS packets.
To accomplish this, dmxdev_filter->feed.ts has been converted to a list
of struct dmxdev_feeds, each containing a PID value and a pointer to a
struct dmx_ts_feed.
Signed-off-by: Andreas Oberritter <obi@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
fix the following 'make headers_check' warnings:
usr/include/linux/dvb/dmx.h:27: include of <linux/types.h> is preferred over <asm/types.h>
usr/include/linux/dvb/dmx.h:90: found __[us]{8,16,32,64} type without #include <linux/types.h>
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
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>
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>
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!
