mpegtsmux with ximagesrc
Cahill, Ben M
ben.m.cahill at intel.com
Tue Jul 26 12:28:28 PDT 2011
>gstreamer-devel-bounces+bmcahill=alum.rpi.edu at lists.freedesktop
>[mailto:gstreamer-devel-bounces+bmcahill=alum.rpi.edu at lists.fre
>edesktop.org] On Behalf Of Tim-Philipp Müller
>Sent: Tuesday, July 26, 2011 4:50 AM
>To: gstreamer-devel at lists.freedesktop.org
>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
>> 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
>> 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
>> needless thrash. I'm also trying to hack mpegtsmux to allow it to
>> package/forward audio frames even when video stops, but
>> 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 , 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 --
>gstreamer-devel mailing list
>gstreamer-devel at lists.freedesktop.org
More information about the gstreamer-devel