"pipeline is prerolling" debug strategy?

[Eric Montellese]

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> 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
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20120813/70a6168f/attachment-0001.html>