"pipeline is prerolling" debug strategy?

[Chuck Crisler]

Here is a very useful link -> http://linux.die.net/man/1/gst-launch-0.10

Check out the --gst-debug-help option.

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.

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.

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.

Good luck!

On Mon, Aug 13, 2012 at 9:22 PM, Eric Montellese <
eric.montellese at videon-central.com> 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.
>
>
> 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
>>>
>>
>>
>
> _______________________________________________
> 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/20120814/964a4a00/attachment.html>