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

[Peter Maersk-Moller]

Hi Tim-Philipp

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:

/usr/local/bin/gst-launch-1.0 -v audiotestsrc is-live=true !\
    queue !\
    'audio/x-raw, endianness=(int)1234, signed=(boolean)true,
width=(int)16, depth=(int)16, rate=(int)44100, channels=(int)2' !\
    audioconvert !\
    faac bitrate=128000 !
    'audio/mpeg,mpegversion=4, stream-format=raw' !\
    queue !\
    muxer. videotestsrc is-live=true !\
    'video/x-raw, width=(int)1280, height=(int)720,
framerate=(fraction)25/1, pixel-aspect-ratio=(fraction)1/1' !\
    queue !\
    x264enc tune=zerolatency bitrate=2000 !\
    'video/x-h264, alignment=au, stream-format=byte-stream,
profile=(string)main' !\
    h264parse !\
    queue !\
    mpegtsmux name=muxer !\
    tsparse !\
    queue !\
    tcpserversink host=0.0.0.0 port=5012 sync-method=2

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:

(gst-launch-1.0:3341): GStreamer-WARNING **:
gstpad.c:3911:gst_pad_push_data:<mpegtsparse2-0:src> Got data flow before
stream-start event
(gst-launch-1.0:3341): GStreamer-WARNING **:
gstpad.c:3916:gst_pad_push_data:<mpegtsparse2-0:src> Got data flow before
segment event
(gst-launch-1.0:3341): GStreamer-WARNING **:
gstpad.c:3680:gst_pad_chain_data_unchecked:<queue4:sink> Got data flow
before stream-start event
(gst-launch-1.0:3341): GStreamer-WARNING **:
gstpad.c:3685:gst_pad_chain_data_unchecked:<queue4:sink> Got data flow
before segment event
(gst-launch-1.0:3341): GStreamer-WARNING **:
gstpad.c:3911:gst_pad_push_data:<queue4:src> Got data flow before
stream-start event
(gst-launch-1.0:3341): GStreamer-WARNING **:
gstpad.c:3916:gst_pad_push_data:<queue4:src> Got data flow before segment
event
(gst-launch-1.0:3341): GStreamer-WARNING **:
gstpad.c:3680:gst_pad_chain_data_unchecked:<tcpserversink0:sink> Got data
flow before stream-start event
(gst-launch-1.0:3341): GStreamer-WARNING **:
gstpad.c:3685:gst_pad_chain_data_unchecked:<tcpserversink0:sink> Got data
flow before segment event
WARNING: from element
/GstPipeline:pipeline0/GstTCPServerSink:tcpserversink0: Internal data flow
problem.
Additional debug info:
gstbasesink.c(3264): gst_base_sink_chain_unlocked ():
/GstPipeline:pipeline0/GstTCPServerSink:tcpserversink0:
Received buffer without a new-segment. Assuming timestamps start from 0.

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.


best regards






On Tue, Aug 27, 2013 at 12:29 PM, Tim-Philipp Müller <t.i.m at zen.co.uk>wrote:

> On Tue, 2013-08-27 at 11:51 +0200, Peter Maersk-Moller wrote:
>
> Hi Peter,
>
>
> > Done, however it may not be as good documented as you may want it to
> > be.
> >
> > It's my first and there is a learning curve. Feel free to comment at
> > https://bugzilla.gnome.org/show_bug.cgi?id=706872
>
> That's great, thanks.
>
>
> > For the request to debug and file a bug as described under here, I'm
> > not quite there to do that yet. Thanks for explaining anyway.
>
> It sounds like you can describe how to reproduce the issue (sender like
> mpegtsmux ! tcpserversink, and then it happens when a client connects?).
>
> That should be enough for someone to go and investigate. If you could
> file another bug about that, that'd be great. If you can't debug it
> yourself like I described, that's not a problem, it was just in case you
> wanted to look into it some more yourself.
>
> Cheers
>  -Tim
>
> >
> >         >         (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
> >
> >
> >         These are pretty bad. Likely a refcount bug somewhere.
> >         Criticals like
> >         this usually mean that in other circumstances the code will
> >         just crash,
> >         but you got lucky this time.
> >
> >         >         I tried to enable debug, but did not see anything
> >         extra (which
> >         >         is probably due to my lack of experience here)
> >
> >
> >         Run gst-launch-1.0 in gdb with
> >
> >           G_DEBUG=fatal_warnings gdb
> >         --args /usr/bin/gst-launch-1.0 ....
> >
> >         and reproduce it. It should then break at the first warning,
> >         and you can
> >         get a stack trace to see what buffer/caps/structure it
> >         complains about,
> >         and where in the code. You'll need debugging symbols in the
> >         binaries for
> >         that (there might be -dbg packages if you don't build from
> >         source).
> >
> >         Please file a bug about this, ideally with way to reproduce
> >         and/or a
> >         stack trace).
>
>
>
> _______________________________________________
> 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/20130916/ea5c3999/attachment.html>