mpegtsmux with ximagesrc

Cahill, Ben M ben.m.cahill at
Tue Jul 26 12:28:28 PDT 2011


>-----Original Message-----
> at lists.freedesktop
>[ at lists.fre
>] On Behalf Of Tim-Philipp Müller
>Sent: Tuesday, July 26, 2011 4:50 AM
>To: gstreamer-devel at
>Subject: Re: mpegtsmux with ximagesrc
>On Mon, 2011-07-25 at 10:19 -0700, Cahill, Ben M wrote:
>> I'm trying to capture desktop display (via H264) and system 
>audio (via
>> AAC) to send via TS->RTP->udp to another computer.
>> The pipeline below works as long as something is moving within the
>> desktop display.  But, if display doesn't change, ximagesrc stops
>> delivering frames (which saves needless thrash), and mpegtsmux output
>> stops dead; mpegtsmux's collectpads won't do anything until 
>*all* input
>> pads (i.e. both audio *and* video) have data queued.
>> Is this "sporadic", non-periodic video a valid usage case for TS?
>> If so, any suggestions for an alternative/workaround?  I've tried
>> videorate in front of the H264 encoder, but that swamps the 
>system with
>> needless thrash.  I'm also trying to hack mpegtsmux to allow it to
>> package/forward audio frames even when video stops, but 
>having problems
>> getting things started (non-negotiated caps?? for the stream that
>> starts second).
>There are known issues with GstCollectPads and handling of sparse
>streams, see for example [1], but there are probably ways this could be
>hacked around until something better comes along.

Thanks for the bugzilla reference.  In my tarball source code (couple months old now) I see gstcollectpads2 is in gst-plugins-good-0.10.29/gst/videomixer, and is used only by videomixer2.c.

Is anyone planning to port mpegtsmux to use gstcollectpads2?  I could try it as an experiment.

Last night I got something "working" here by hacking gstcollectpads.c to use a g_cond_timed_wait() instead of g_cond_wait() (in GST_COLLECT_PADS_WAIT()), and some other hacks to both gstcollectpads.c and mpegtsmux.c.  A 100 msec timeout got things working afaict, but I wouldn't be surprised if there are some undesired side effects that I wouldn't understand yet (kind of newbie here).

I'll guess gstcollectpads2.c provides a more well-thought-out solution.

>Some random ideas: does ximagesrc send newsegment updates, to move time
>along when it doesn't output repeat frames? (Then the muxer/collectpads
>know when not to wait, but see above). Or maybe there's a way to tell
>x264enc that we want a repeat frame and/or that the frame being passed
>is identical to the previous frame? Then videorate could flag 
>it creates and x264enc could pick up on the flag.


-- Ben --

> Cheers
>  -Tim
>gstreamer-devel mailing list
>gstreamer-devel at

More information about the gstreamer-devel mailing list