DMX_OUT_TSDEMUX_TAP: record two streams from same mux

Hi there,

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
too: open dvr0. But for capturing multiple video streams, it's surely 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).

The attached patch adds a new value for dmx_output_t:
DMX_OUT_TSDEMUX_TAP, which sends TS to the demux0 device. The main question I have, is, seeing as this was such a simple change, why didn't it already work like that? Does everyone else who wants to capture multiple video streams, take the whole multiplex into userspace and demux it themselves? Or do they take PES from each demux0 device and re-multiplex that into PS, not TS?

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.

Peter

@@ -39,9 +39,10 @@ typedef enum
 	DMX_OUT_DECODER, /* Streaming directly to decoder. */
 	DMX_OUT_TAP,     /* Output going to a memory buffer */
 			 /* (to be retrieved via the read command).*/
-	DMX_OUT_TS_TAP   /* Output multiplexed into a new TS  */
+	DMX_OUT_TS_TAP,  /* Output multiplexed into a new TS  */
 			 /* (to be retrieved by reading from the */
 			 /* logical DVR device).                 */
+	DMX_OUT_TSDEMUX_TAP /* Like TS_TAP but retrieved from the DMX device */
 } dmx_output_t;
 
 

@@ -374,7 +374,8 @@ static int dvb_dmxdev_ts_callback(const 
 		return 0;
 	}
 
-	if (dmxdevfilter->params.pes.output == DMX_OUT_TAP)
+	if (dmxdevfilter->params.pes.output == DMX_OUT_TAP
+	    || dmxdevfilter->params.pes.output == DMX_OUT_TSDEMUX_TAP)
 		buffer = &dmxdevfilter->buffer;
 	else
 		buffer = &dmxdevfilter->dev->dvr_buffer;

@@ -618,7 +619,7 @@ static int dvb_dmxdev_filter_start(struc
 		else
 			ts_type = 0;
 
-		if (otype == DMX_OUT_TS_TAP)
+		if (otype == DMX_OUT_TS_TAP || otype == DMX_OUT_TSDEMUX_TAP)
 			ts_type |= TS_PACKET;
 
 		if (otype == DMX_OUT_TAP)

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

I like your patch and would like to ask Mauro to integrate it if no one objects, mainly because it serves as a basis for a DMX_ADD_PID ioctl suggested by Felix Domke some months ago.

Regards,
Andreas

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Yes, they all demux in userspace themselves. If you search the archives, I've pointed out this same problem.

One thing you do lose with the kernel demuxing system is the relationship between the different streams. For instance, a PMT change takes effect for all packets that follow it, but with the demuxed streams, you don't know where that is.

Of course if you want to work with existing systems, you have to demux in userspace since no one will have this new feature yet. And if you're doing that anyway, it's more work to add additional support for demuxed TS streams to your software. That probably why no one has bothered to add this feature.

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

2008/2/26 Peter Hartley <[email protected]>:

With GStreamer, what we do is userspace demuxing and only on dvr and not the demux device and start by only filtering the PAT pid, then when the first PAT comes and has been parsed, add to the filter the PMT pids for the programs that we want and then as each PMT comes add to the filter the es pids. We provide different ts's for each of the programs on different src (output) pads in the mpegtsparse element. Programs can be selected, added, removed on the fly. We have a compound gstreamer element that basically encompasses the dvbsrc which reads from the device and the mpegtsparse that does the ts parsing called dvbbasebin. And an example that would record multiple programs is as follows:

gst-launch-0.10 dvbbasebin adapter=0 frequency=10773000 polarity=h symbol-rate=22000 program-numbers=6301:6302:6304 name=d .program_6301 ! queue ! filesink location=bbc1lon.ts d.program_6302 ! queue ! filesink location=bbc2eng.ts d.program_6304 ! queue ! filesink location=bbcnews24.ts

So we don't take the whole multiplex into userspace, just the pids we need on an as needed basis.

Regards

Zaheer

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Though this will work for FTA streams, it won't work for scrambled streams.

Regards,
Manu

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Maybe I gave a simplistic description fo what we do, but I can confirm we have encrypted streams decrypted also with dvbbasebin in gstreamer talking to the cam. It was done in last year's Summer of Code by Alessandro Decina.

Zaheer

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

With getstream a little toy project of mine i basically just fetch the whole stream with pid 0x2000 for budget cards, or join individual pids on non-budget cards and do the whole remuxing stuff in userspace.

It is okay to have a MpegTS demux in kernel space as its a "unify the interface" thingy for all different cards, but the section reassembly is just a little featured moved to the kernel where it IMHO does not belong to.

RFC1925 - The twelve networking thruths:

(12) In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.

Flo

Florian Lohoff                  [email protected]             +49-171-2280134
	Those who would give up a little freedom to get a little 
          security shall soon have neither - Benjamin Franklin

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Hello Peter,

one thing I forgot to mention is that your patch misses a "Signed-off-by" line.

Please take a look at
http://www.linuxtv.org/v4lwiki/index.php/SubmittingPatches#Sign_your_work
and resend your patch accordingly.

You should also send a copy of it to [email protected] and include the following line:

Thanks,
Andreas

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb