Internal data flow problem for tcpserversink and sync-method=2 failing

[Peter Maersk-Moller]

Hi.

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 :)

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.

The 0.10 version is an unspecified 0.10 version from Ubuntu 12.04 and the
1.0 version is 1.0.6.

The two scripts for mp3 are:

/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

/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

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@://192.168.1.2:5010/ in case
somebody wonder.

The gstreamer pipeline used to test is this:

gst-launch-1.0 -v -e tcpclientsrc host=192.168.1.2 port=5010 ! queue !
decodebin name=decoder ! queue ! xvimagesink decoder. ! queue !
autoaudiosink

For the 0.10 based server both VLC and GStreamer plays audio and display
video within 1-2 second. That is excellent.

Now for the 1.0 version of the server. When the server is started, it is
noticed that the following messages are printed:

WARNING: from element
/GstPipeline:pipeline0/GstTCPServerSink:tcpserversink0: Internal data flow
problem.
Additional debug info:
gstbasesink.c(3141): gst_base_sink_chain_unlocked ():
/GstPipeline:pipeline0/GstTCPServerSink:tcpserversink0:
Received buffer without a new-segment. Assuming timestamps start from 0.

When a player connects to the server the following messages is outputtet
from the server for as long as the server gives out data:

(gst-launch-1.0:7266): GStreamer-CRITICAL **: gst_mini_object_ref:
assertion `mini_object != NULL' failed

(gst-launch-1.0:7266): GStreamer-CRITICAL **: gst_caps_get_structure:
assertion `GST_IS_CAPS (caps)' failed

(gst-launch-1.0:7266): GStreamer-CRITICAL **: gst_structure_has_field:
assertion `structure != NULL' failed

I tried to enable debug, but did not see anything extra (which is probably
due to my lack of experience here)

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.

To me the described suggests that the tcpserversink for gstreamer-1.0 does
not honour the sync-method=2 parameter.

Is this a known error for gstreamer-1.0?

And does there exist a known workaround?


Kind regards
Peter Maersk-Moller
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130822/a200b6ba/attachment.html>