"pipeline is prerolling" debug strategy?

[Stefan Sauer]

On 08/14/2012 03:22 AM, Eric Montellese wrote:
> Chuck, you said:
> > gst-inspect has an option that lists the plugin debugging name. 
>
> 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).
>
>
> Second question:
> 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.
You should handle the return code of gst_element_link (+ related
funtions) and if it fails at least log a warning.

Stefan

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