Pipeline playing ... but no flow

[Peter Maersk-Moller]

Hi

It may be worth noting, that the 'not flowing pipeline' for the receiver
applies whether the receiver or the sender is started first. If the faac
encoder is replaced by the lamempenc encoder for the sender and the
receiver is started first, the pipeline starts flowing after 10 seconds. If
the sender uses the lamempenc instead of the faac encoder and if the sender
is started first, then the receiver will sometimes start flowing after
20-40 seconds, but usually it will flow, at least no flow is detected after
more than 60 seconds.

Is there a way to get the receiver start flowing every time and hopefully
starting flowing faster?

Best regards
Peter Maersk-Moller



On Mon, Aug 19, 2013 at 2:25 AM, Peter Maersk-Moller <pmaersk at gmail.com>wrote:

> Hi.
>
> I'm trying to send a combined audio and video stream hopefully synced
> using mpeg2 TS in RT in UDP and while my receiving pipeline says it is
> playing, it does not flow. Can you help me understand why. To demonstrate
> the problem i have these two pipelines:
>
> Sender:
>
>   gst-launch-0.10 -v videotestsrc ! x264enc tune=zerolatency ! queue !
> mpegtsmux name=muxer ! mpegtsparse ! rtpmp2tpay ! udpsink host=127.0.0.1
> port=8004 sync=true audiotestsrc ! faac ! queue ! muxer.
>
> Receiver:
>
>   gst-launch-0.10 -v udpsrc port=8004 caps='application/x-rtp,
> media=(string)video, clock-rate=(int)90000, encoding-name=(string)MP2T-ES,
> payload=(int)33' ! rtpmp2tdepay ! decodebin2 name=decoder ! queue !
> 'video/x-raw-yuv' ! fakesink decoder. ! 'audio/x-raw-int' ! queue ! fakesink
>
> Technically the rtmp2tdepay can be eliminated, but it shouldn't matter.
> The receiver IP is set to 127.0.0.1 to make it easy to test on same machine.
>
> The receiving end reports this:
>
>     Setting pipeline to PAUSED ...
>     Pipeline is live and does not need PREROLL ...
>     Setting pipeline to PLAYING ...
>     New clock: GstSystemClock
>
> plus a lot more.
>
> I assumed this meant the pipeline was flowing, however it does not.
> fakesinks would print a lot of text if it was.
>
> I assume the receiving end somehow is filling its queues perhaps waiting
> for PAT/PMT to arrive. Maybe?
>
> According to doc, the mpegtsmux should insert PAT/PMT every 9000 timer
> ticks and timerticks is set to 90000 per sec. In my book it should mean
> every 100ms ... or perhaps it means every 10 second or perhaps I
> misunderstand that part.
>
> Is there a parameter I miss to make the receive end start flowing?
>
> After 7-11 secs I see this in the receiver end
>
> /GstPipeline:pipeline0/GstDecodeBin2:decoder/GstMultiQueue:multiqueue0:
> max-size-buffers = 5
> /GstPipeline:pipeline0/GstDecodeBin2:decoder/GstMultiQueue:multiqueue0:
> max-size-time = 0
> /GstPipeline:pipeline0/GstDecodeBin2:decoder/GstMultiQueue:multiqueue0:
> max-size-bytes = 2097152
>
> Any suggesting to help getting the receiver end flowing would be really
> appreciated.
>
> Kind regards
> Peter Maersk-Moller
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130819/ce49a1e1/attachment-0001.html>