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

[Peter Maersk-Moller]

Hi Timm-Phillipp

Please see comments in-line.

On Sun, Aug 25, 2013 at 5:42 PM, Tim-Philipp Müller <t.i.m at zen.co.uk> wrote:

> On Thu, 2013-08-22 at 21:33 +0200, Peter Maersk-Moller wrote:
> couple of drive-by comments:
>

Understood.


> I believe the problem is actually with the mpeg-ts muxer, it doesn't
> flag key frames properly. If you insert an
>
>   identity silent=false
>
> before the sink and pass -v to gst-launch you will notice how in 0.10
> only the first packet of a keyframe was marked, while in 1.0 it's
> clearly all very confused and wrong. Without that, the sink has no
> chance of working right.
>
> It shouldn't be too hard to fix hopefully. Could you file a bug in
> bugzilla about this, against mpegtsmux (gst-plugins-bad)?
>
>   http://gstreamer.freedesktop.org/bugs/
>

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


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.

>         (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).
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130827/d81bd35e/attachment-0001.html>