"pipeline is prerolling" debug strategy?
Tim-Philipp Müller
t.i.m at zen.co.uk
Fri Aug 10 01:17:25 PDT 2012
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
More information about the gstreamer-devel
mailing list