<div dir="ltr">Hi Timm-Phillipp<br><div><div class="gmail_extra"><br></div><div class="gmail_extra">Please see comments in-line.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 25, 2013 at 5:42 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 2013-08-22 at 21:33 +0200, Peter Maersk-Moller wrote:<br>
couple of drive-by comments:<br></blockquote><div><br></div><div>Understood.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I believe the problem is actually with the mpeg-ts muxer, it doesn't<br>

flag key frames properly. If you insert an<br>
<br>
  identity silent=false<br>
<br>
before the sink and pass -v to gst-launch you will notice how in 0.10<br>
only the first packet of a keyframe was marked, while in 1.0 it's<br>
clearly all very confused and wrong. Without that, the sink has no<br>
chance of working right.<br>
<br>
It shouldn't be too hard to fix hopefully. Could you file a bug in<br>
bugzilla about this, against mpegtsmux (gst-plugins-bad)?<br>
<br>
  <a href="http://gstreamer.freedesktop.org/bugs/" target="_blank">http://gstreamer.freedesktop.org/bugs/</a><br></blockquote><div><br></div><div>Done, however it may not be as good documented as you may want it to be.<br>
</div><div>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">https://bugzilla.gnome.org/show_bug.cgi?id=706872</a><br></div><div> <br><br>
</div><div>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.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">
>         (gst-launch-1.0:7266): GStreamer-CRITICAL **:<br>
>         gst_mini_object_ref: assertion `mini_object != NULL' failed<br>
><br>
>         (gst-launch-1.0:7266): GStreamer-CRITICAL **:<br>
>         gst_caps_get_structure: assertion `GST_IS_CAPS (caps)' failed<br>
><br>
>         (gst-launch-1.0:7266): GStreamer-CRITICAL **:<br>
>         gst_structure_has_field: assertion `structure != NULL' failed<br>
<br>
</div>These are pretty bad. Likely a refcount bug somewhere. Criticals like<br>
this usually mean that in other circumstances the code will just crash,<br>
but you got lucky this time.<br>
<div class="im"><br>
>         I tried to enable debug, but did not see anything extra (which<br>
>         is probably due to my lack of experience here)<br>
<br>
</div>Run gst-launch-1.0 in gdb with<br>
<br>
  G_DEBUG=fatal_warnings gdb --args /usr/bin/gst-launch-1.0 ....<br>
<br>
and reproduce it. It should then break at the first warning, and you can<br>
get a stack trace to see what buffer/caps/structure it complains about,<br>
and where in the code. You'll need debugging symbols in the binaries for<br>
that (there might be -dbg packages if you don't build from source).<br>
<br>
Please file a bug about this, ideally with way to reproduce and/or a<br>
stack trace).<br>
<br>
</blockquote></div><br></div></div></div>