<div dir="ltr"><div><div><div><div><div><div><div><div>Hi Chuck.<br><br></div>Sending over the loopback interface and assuming the sender and receiving processes are not overloaded, sent and received packets ought to be identical .... most likely. Could do a tee and filesink in both ends and compare. Anyway, the following works largely flawlessly with 1.0<br>
<br><b>Sender: <br></b>gst-launch-1.0 -v videotestsrc is-live=true ! x264enc tune=zerolatency ! queue ! mpegtsmux ! rtpmp2tpay ! udpsink host=127.0.0.1 port=8004 sync=true audiotestsrc is-live=true ! lamemp3enc ! queue ! muxer.<br>
</div><b>Receiver:</b><br>gst-launch-1.0 udpsrc port=8004 timeout=1000000000 caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)MP2T-ES, payload=(int)33' ! queue ! decodebin name=decoder ! xvimagesink decoder. ! autoaudiosink<br>
<br></div>If the sender is started first, the receiver will flow and play after a few seconds every time. If the sender is suspended and resumed, the receiver syncs fast and continue. Nice work :) If the sender is terminated and a new one is started, the receiver syncs relatively fast. Nice. Thanks for the good work.<br>
<br></div>Now if the sender (only the sender) is replaced by its gstreamer-0.10 equivalent, it will work, if the receiver is started before the sender. If the sender is suspended and later resumed, the receiver will in most cases resync and play. If the sender is terminated and started again, the receiver will in most cases not resync and instead print this<br>
<br>gstbasesink.c(2791): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0:<br>There may be a timestamping problem, or this computer is too slow.<br>WARNING: from element /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0: A lot of buffers are being dropped.<br>
Additional debug info:<br>gstbasesink.c(2791): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0:<br><br></div>Now if the receiver is replaced by its 0.10 equivalent, it will only work if the sender is also 0.10 and the receiver is started first. It will not work if the sender is version 1.0. If the sender and receiver is 0.10 and the receiver is started first, it will also work most of the time if the sender is later suspended and resumed. But it will not work if the sender is terminated and restarted.<br>
<br></div>Anyway, thanks for your patience. As I assume, there is no fixes for 0.10 and quite likely all efforts are put into 1.0/1.1 and later 1.2, no fixes for 0.10 is going to become available. Assume migration to 1.0 is a must then.<br>
<br></div>Kind regards<br></div>Peter Maersk-Moller<br><div><div><div><div><br><div><div><div><br><br><br><br><br></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 19, 2013 at 5:04 PM, Chuck Crisler <span dir="ltr"><<a href="mailto:ccrisler@mutualink.net" target="_blank">ccrisler@mutualink.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">It might be worth a packet capture to see exactly what packets the client receives and compare to what packets the server sends.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Mon, Aug 19, 2013 at 6:26 AM, Peter Maersk-Moller <span dir="ltr"><<a href="mailto:pmaersk@gmail.com" target="_blank">pmaersk@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div><div><div><div>Hi<br><br></div>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.<br>
<br></div>Is there a way to get the receiver start flowing every time and hopefully starting flowing faster?<br><br></div>Best regards<span><font color="#888888"><br></font></span></div><span><font color="#888888">Peter Maersk-Moller</font></span><div>
<div><br><div><div><div><div><div><br><div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, Aug 19, 2013 at 2:25 AM, Peter Maersk-Moller <span dir="ltr"><<a href="mailto:pmaersk@gmail.com" target="_blank">pmaersk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div><div><div><div><div><div><div><div><div>Hi.<br><br></div>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:<br>
<br></div>Sender:<br><br> 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.<br>
<br></div>Receiver:<br><br> 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<br>
<br></div>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.<br><br></div><div>The receiving end reports this:<br><br>
Setting pipeline to PAUSED ...<br>
Pipeline is live and does not need PREROLL ...<br> Setting pipeline to PLAYING ...<br> New clock: GstSystemClock<br><br></div><div>plus a lot more.<br></div><div><br></div><div>I assumed this meant the pipeline was flowing, however it does not. fakesinks would print a lot of text if it was.<br>
</div><div><br></div>I assume the receiving end somehow is filling its queues perhaps waiting for PAT/PMT to arrive. Maybe?<br><br>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.<br>
<br></div>Is there a parameter I miss to make the receive end start flowing?<br><br></div>After 7-11 secs I see this in the receiver end<br><br>/GstPipeline:pipeline0/GstDecodeBin2:decoder/GstMultiQueue:multiqueue0: max-size-buffers = 5<br>
/GstPipeline:pipeline0/GstDecodeBin2:decoder/GstMultiQueue:multiqueue0: max-size-time = 0<br>/GstPipeline:pipeline0/GstDecodeBin2:decoder/GstMultiQueue:multiqueue0: max-size-bytes = 2097152<br><br></div>Any suggesting to help getting the receiver end flowing would be really appreciated.<br>
<br></div>Kind regards<span><font color="#888888"><br></font></span></div><span><font color="#888888">Peter Maersk-Moller<br></font></span></div>
</blockquote></div><br></div></div></div></div></div></div></div></div></div></div>
<br></div></div>_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br></blockquote></div><br></div>