<div dir="ltr"><div><div>Repeated the test with gstreamer 1.0.9. The warning about internal data flow problem has gone, but the rest stays the same indicating that it does not honour the sync-method=2 parameter.<br><br></div>
Best regards<br></div>Peter<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 22, 2013 at 4:35 PM, 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><div>Hi.<br><br></div>Upgrading from gstreamer-0.10 to gstreamer-1.0, I experience a couple of problems that I hope some here can suggest paths to find solutions for. Of course turnkey solutiuons are welcome too :)<br>
<br>For verifying the problems, I have two scripts, one using mp3 as audio and the other using aac. I'll post the aac findings in another mail.<br>
<br></div><div>The 0.10 version is an unspecified 0.10 version from Ubuntu 12.04 and the 1.0 version is 1.0.6.<br><br></div>The two scripts for mp3 are:<br><br>/usr/bin/gst-launch-1.0 -v videotestsrc is-live=true ! queue leaky=2 ! x264enc tune=zerolatency ! queue ! tsmuxer. audiotestsrc is-live=true ! queue leaky=2 ! audio/x-raw, format=(string)S16LE, endianness=(int)1234, signed=(boolean)true, width=(int)16, depth=(int)16, rate=(int)44100, channels=(int)2 ! lamemp3enc bitrate=128 ! audio/mpeg,mpegversion=1 ! queue ! mpegtsmux name=tsmuxer ! tsparse ! queue ! tcpserversink host=0.0.0.0 port=5010 sync-method=2<br>
<br>/usr/bin/gst-launch-0.10 -v videotestsrc is-live=true ! queue leaky=2 ! x264enc tune=zerolatency ! queue ! tsmuxer. audiotestsrc is-live=true ! queue leaky=2 ! audio/x-raw-int, endianness=(int)1234, signed=(boolean)true, width=(int)16, depth=(int)16, rate=(int)44100, channels=(int)2 ! lamemp3enc bitrate=128 ! audio/mpeg,mpegversion=1 ! queue ! mpegtsmux name=tsmuxer ! mpegtsparse ! queue ! tcpserversink host=0.0.0.0 port=5010 sync-method=2<br>
<br></div>The 0.10 version works flawlessly and has been tested using both VLC and gstramer-1.0. The URL to use for VLC is tcp@://<a href="http://192.168.1.2:5010/" target="_blank">192.168.1.2:5010/</a> in case somebody wonder.<br>
<br></div>The gstreamer pipeline used to test is this:<br>
<br>gst-launch-1.0 -v -e tcpclientsrc host=192.168.1.2 port=5010 ! queue ! decodebin name=decoder ! queue ! xvimagesink decoder. ! queue ! autoaudiosink<br><br></div>For the 0.10 based server both VLC and GStreamer plays audio and display video within 1-2 second. That is excellent.<br>
<br></div>Now for the 1.0 version of the server. When the server is started, it is noticed that the following messages are printed:<br><br>WARNING: from element /GstPipeline:pipeline0/GstTCPServerSink:tcpserversink0: Internal data flow problem.<br>
Additional debug info:<br>gstbasesink.c(3141): gst_base_sink_chain_unlocked (): /GstPipeline:pipeline0/GstTCPServerSink:tcpserversink0:<br>Received buffer without a new-segment. Assuming timestamps start from 0.<br><br></div>
When a player connects to the server the following messages is outputtet from the server for as long as the server gives out data:<br><br>(gst-launch-1.0:7266): GStreamer-CRITICAL **: gst_mini_object_ref: assertion `mini_object != NULL' failed<br>
<br>(gst-launch-1.0:7266): GStreamer-CRITICAL **: gst_caps_get_structure: assertion `GST_IS_CAPS (caps)' failed<br><br>(gst-launch-1.0:7266): GStreamer-CRITICAL **: gst_structure_has_field: assertion `structure != NULL' failed<br>
<br></div>I tried to enable debug, but did not see anything extra (which is probably due to my lack of experience here)<br><br></div>Now despite the warnings and the critical messages, both VLC and the gstreamer test pipeline can play the stream. However there is one important difference. While VLC start playing the audio within a second or two, the video takes between 2-11 seconds to appear. The same applies for the gstreamer test pipeline although the audio does not appear until the video appear.<br>
<br></div>To me the described suggests that the tcpserversink for gstreamer-1.0 does not honour the sync-method=2 parameter.<br><br></div>Is this a known error for gstreamer-1.0?<br><br>And does there exist a known workaround?<br>
<div><div><div><div><div><br><br></div><div>Kind regards<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>Peter Maersk-Moller<br></div></font></span></div>
</div></div></div></div>
</blockquote></div><br></div>