<div><span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">Chuck, you said:</span></div><span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">> gst-inspect has an option that lists the plugin debugging name.</span> <br>


<br>It does?  I can't find it (perhaps in a newer version?).  So far, I've had to figure out the debugging name through messy alternative means (reading source code, or dumping everything with level 5 and grepping for likely names).<div>

<br></div><div><br></div><div>Second question:</div><div>If, when I create the dot-image of a pipeline I see that two components are not connected (two components which usually connect to each other fine), and no errors are printed; what path would you take for debugging?  (of course I can work through the code path, but wondering if there is a simpler way to determine why two parts of a pipeline are not being connected when using gst-launch.</div>

<div><br></div><div><br></div><div>Thanks,</div><div>Eric<br><br><br><div class="gmail_quote">
On Mon, Aug 13, 2012 at 11:33 AM, Eric Montellese <span dir="ltr"><<a href="mailto:eric.montellese@videon-central.com" target="_blank">eric.montellese@videon-central.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Thank you everyone for your advice<div><div><br><br><div class="gmail_quote">On Fri, Aug 10, 2012 at 4:17 AM, 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><div>On Thu, 2012-08-09 at 13:38 -0400, Eric Montellese wrote:<br>
<br>
> Folks, in development I've run into various malformed or buggy<br>
> pipelines that give this output:<br>
><br>
> gst-launch  launch ! a ! pipeline<br>
> Setting pipeline to PAUSED ...<br>
> Pipeline is PREROLLING ...<br>
><br>
><br>
> Generally I have debugged these issues through a mixture of brute<br>
> force and intuition (looking for common sorts of problems, etc).<br>
><br>
> But perhaps there is a better way to determine which element has held<br>
> up the pipeline?  Some swanky debug command I'm totally unaware of<br>
> that shows the buffers in-flight perhaps?<br>
<br>
</div></div>If a pipeline fails to preroll, that usually means that one of the sink<br>
elements doesn't receive any buffers.<br>
<br>
So the first step would be to figure out which of the sinks involved<br>
doesn't receive any buffers (e.g. via GST_DEBUG=*sink:5), then you work<br>
your way backwards - if there's a muxer, you might not be getting data<br>
on one of the pads - otherwise perhaps one of the parsers or decoders<br>
doesn't output anything.<br>
<br>
If you pass -v to gst-launch you can see the caps as they're being set<br>
on pads. This is linked to buffer flow in 0.10, so in the output there<br>
you should look for pads / branches where no caps are set on any pads -<br>
that should give you a clue where the problem is already without looking<br>
at the debug log.<br>
<br>
Cheers<br>
<span><font color="#888888">-Tim<br>
</font></span><div><div><br>
<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">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></div></blockquote></div><br>
</div>