<div dir="ltr"><div><div><div><div>Hi Tim-Philipp<br><br></div>This may be related to the problem with mpegtsmux. While testing gstreamer-1.1.4, I encounter a couple of warnings generating a simpel data stream. The warnings are mostly the type 'Got data flow before stream-start event' and 'Internal data flow problem.'. I'll paste the full messages below, but let me first show the pipeline used for creating the stream:<br>
<br>/usr/local/bin/gst-launch-1.0 -v audiotestsrc is-live=true !\<br>    queue !\<br>    'audio/x-raw, endianness=(int)1234, signed=(boolean)true, width=(int)16, depth=(int)16, rate=(int)44100, channels=(int)2' !\<br>
    audioconvert !\<br>    faac bitrate=128000 !<br>    'audio/mpeg,mpegversion=4, stream-format=raw' !\<br>    queue !\<br>    muxer. videotestsrc is-live=true !\<br>    'video/x-raw, width=(int)1280, height=(int)720, framerate=(fraction)25/1, pixel-aspect-ratio=(fraction)1/1' !\<br>
    queue !\<br>    x264enc tune=zerolatency bitrate=2000 !\<br>    'video/x-h264, alignment=au, stream-format=byte-stream, profile=(string)main' !\<br>    h264parse !\<br>    queue !\<br>    mpegtsmux name=muxer !\<br>
    tsparse !\<br>    queue !\<br>    tcpserversink host=0.0.0.0 port=5012 sync-method=2<br><br></div>As you can see, a rather standard pipeline, if there ever was such a thing. The warnings generated by gstreamer 1.1.4 are these:<br>
<br>(gst-launch-1.0:3341): GStreamer-WARNING **: gstpad.c:3911:gst_pad_push_data:<mpegtsparse2-0:src> Got data flow before stream-start event<br>(gst-launch-1.0:3341): GStreamer-WARNING **: gstpad.c:3916:gst_pad_push_data:<mpegtsparse2-0:src> Got data flow before segment event<br>
(gst-launch-1.0:3341): GStreamer-WARNING **: gstpad.c:3680:gst_pad_chain_data_unchecked:<queue4:sink> Got data flow before stream-start event<br>(gst-launch-1.0:3341): GStreamer-WARNING **: gstpad.c:3685:gst_pad_chain_data_unchecked:<queue4:sink> Got data flow before segment event<br>
(gst-launch-1.0:3341): GStreamer-WARNING **: gstpad.c:3911:gst_pad_push_data:<queue4:src> Got data flow before stream-start event<br>(gst-launch-1.0:3341): GStreamer-WARNING **: gstpad.c:3916:gst_pad_push_data:<queue4:src> Got data flow before segment event<br>
(gst-launch-1.0:3341): GStreamer-WARNING **: gstpad.c:3680:gst_pad_chain_data_unchecked:<tcpserversink0:sink> Got data flow before stream-start event<br>(gst-launch-1.0:3341): GStreamer-WARNING **: gstpad.c:3685:gst_pad_chain_data_unchecked:<tcpserversink0:sink> Got data flow before segment event<br>
WARNING: from element /GstPipeline:pipeline0/GstTCPServerSink:tcpserversink0: Internal data flow problem.<br>Additional debug info:<br>gstbasesink.c(3264): gst_base_sink_chain_unlocked (): /GstPipeline:pipeline0/GstTCPServerSink:tcpserversink0:<br>
Received buffer without a new-segment. Assuming timestamps start from 0.<br><br></div>Despite the warnings the following pipeline appear to play and display the stream rather instantly, also if sync-method is set to '0'. But fine with me. Perhaps moving around the mpegts part as described in the release mail for 1.1.4 cured some of the problem ... maybe.<br>
<br></div><div><br></div>best regards<br><div><div><br><br><div><br><br></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 27, 2013 at 12:29 PM, Tim-Philipp Müller <span dir="ltr"><<a href="mailto:t.i.m@zen.co.uk" target="_blank">t.i.m@zen.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, 2013-08-27 at 11:51 +0200, Peter Maersk-Moller wrote:<br>
<br>
Hi Peter,<br>
<br>
<br>
</div><div class="im">> Done, however it may not be as good documented as you may want it to<br>
> be.<br>
><br>
> It's my first and there is a learning curve. Feel free to comment at<br>
> <a href="https://bugzilla.gnome.org/show_bug.cgi?id=706872" target="_blank">https://bugzilla.gnome.org/show_bug.cgi?id=706872</a><br>
<br>
</div>That's great, thanks.<br>
<div class="im"><br>
<br>
> For the request to debug and file a bug as described under here, I'm<br>
> not quite there to do that yet. Thanks for explaining anyway.<br>
<br>
</div>It sounds like you can describe how to reproduce the issue (sender like<br>
mpegtsmux ! tcpserversink, and then it happens when a client connects?).<br>
<br>
That should be enough for someone to go and investigate. If you could<br>
file another bug about that, that'd be great. If you can't debug it<br>
yourself like I described, that's not a problem, it was just in case you<br>
wanted to look into it some more yourself.<br>
<br>
Cheers<br>
<span class="HOEnZb"><font color="#888888"> -Tim<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
>         >         (gst-launch-1.0:7266): GStreamer-CRITICAL **:<br>
>         >         gst_mini_object_ref: assertion `mini_object != NULL'<br>
>         failed<br>
>         ><br>
>         >         (gst-launch-1.0:7266): GStreamer-CRITICAL **:<br>
>         >         gst_caps_get_structure: assertion `GST_IS_CAPS<br>
>         (caps)' failed<br>
>         ><br>
>         >         (gst-launch-1.0:7266): GStreamer-CRITICAL **:<br>
>         >         gst_structure_has_field: assertion `structure !=<br>
>         NULL' failed<br>
><br>
><br>
>         These are pretty bad. Likely a refcount bug somewhere.<br>
>         Criticals like<br>
>         this usually mean that in other circumstances the code will<br>
>         just crash,<br>
>         but you got lucky this time.<br>
><br>
>         >         I tried to enable debug, but did not see anything<br>
>         extra (which<br>
>         >         is probably due to my lack of experience here)<br>
><br>
><br>
>         Run gst-launch-1.0 in gdb with<br>
><br>
>           G_DEBUG=fatal_warnings gdb<br>
>         --args /usr/bin/gst-launch-1.0 ....<br>
><br>
>         and reproduce it. It should then break at the first warning,<br>
>         and you can<br>
>         get a stack trace to see what buffer/caps/structure it<br>
>         complains about,<br>
>         and where in the code. You'll need debugging symbols in the<br>
>         binaries for<br>
>         that (there might be -dbg packages if you don't build from<br>
>         source).<br>
><br>
>         Please file a bug about this, ideally with way to reproduce<br>
>         and/or a<br>
>         stack trace).<br>
<br>
<br>
<br>
</div></div><div class="HOEnZb"><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br></div>