"pipeline is prerolling" debug strategy?

[Eric Montellese]

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.


Thanks,
Eric


On Mon, Aug 13, 2012 at 11:33 AM, Eric Montellese <
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>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/7ff5e296/attachment.html>