Thanks Chuck! <div><br></div><div>--gst-debug-help -- big help! definitely missed that one.<div><br></div><div>For the pipeline:</div><div>In this case, it doesn't seem to be a problem of upstream filters, since the changes are downstream. </div>
<div><br></div><div>My original pipeline looks something like (simplified, and line breaks added, for clarity):</div><div><br></div><div> gst-launch</div><div> videnc name=e ! mux.video_%d muxer name=mux ! filesink location=output.ts </div>
<div> filesrc location=inputfile.mpg ! demux name=d1 ! mux.audio_%d d1. ! viddec ! e.sink_1</div><div><br></div><div>this pipeline works -- but to debug an issue with one of the components, I tried various alternatives, such as pulling out the decode/reencode, or doing the decode/reencode twice. In both cases, the gst-launch graph shows that the demux src pads don't get connected to the next elements. That's the part that doesn't seem to make sense -- since there is nothing upstream that has changed, and in the case of the extra reencode, there's nothing immediately downstream that has changed either.</div>
<div><br></div><div>For reference, here are the two (again, simplified) pipelines I'm referring to:</div><div><br></div><div>no decode/reencode, just demux/remux:</div><div><div> gst-launch</div><div> muxer name=mux ! filesink location=output.ts </div>
<div> filesrc location=inputfile.mpg ! demux name=d1 ! mux.audio_%d d1. ! mux.video_%d</div><br class="Apple-interchange-newline"></div><div>add an extra decode/reencode:</div><div><div> gst-launch</div><div> videnc name=e ! viddec ! videnc ! mux.video_%d muxer name=mux ! filesink location=output.ts </div>
<div> filesrc location=inputfile.mpg ! demux name=d1 ! mux.audio_%d d1. ! viddec ! e.sink_1</div><br class="Apple-interchange-newline"></div><div><br></div><div>Thanks,</div><div>Eric</div><div><br></div>
<div><br></div><div><br><br><div class="gmail_quote">On Tue, Aug 14, 2012 at 10:12 AM, Chuck Crisler <span dir="ltr"><<a href="mailto:ccrisler@mutualink.net" target="_blank">ccrisler@mutualink.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Here is a very useful link -> <a href="http://linux.die.net/man/1/gst-launch-0.10" target="_blank">http://linux.die.net/man/1/gst-launch-0.10</a><br>
<br>Check out the --gst-debug-help option.<br><br>Reading the source code is a drag and you should exhaust all other avenues first. I am not an expert but I would suggest these 2 options. There are likely more.<br>
<br>1. Insure that the caps are compatible. If they normally connect then it seems like you expect them to be good, but make sure that they are in that case. It may be unlikely, but it is possible that something is causing them to change.<br>
<br>2. Make sure that upstream filters are working. It is also possible that something failed upstream and gstreamer simply hasn't make that connection yet.<br><br>Good luck!<div><div><br><br>
<div class="gmail_quote">On Mon, Aug 13, 2012 at 9:22 PM, 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"><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>
<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>
<br></blockquote></div><br>
</div></div><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>
<br></blockquote></div><br></div>
</div>