Pipeline playing ... but no flow

[Chuck Crisler]

It might be worth a packet capture to see exactly what packets the client
receives and compare to what packets the server sends.


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

> 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
>>
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130819/17639385/attachment-0001.html>