"pipeline is prerolling" debug strategy?

[Eric Montellese]

Thanks Chuck!

--gst-debug-help -- big help!  definitely missed that one.

For the pipeline:
In this case, it doesn't seem to be a problem of upstream filters, since
the changes are downstream.

My original pipeline looks something like (simplified, and line breaks
added, for clarity):

  gst-launch
  videnc name=e ! mux.video_%d muxer name=mux ! filesink location=output.ts
  filesrc location=inputfile.mpg ! demux name=d1 ! mux.audio_%d d1. !
viddec ! e.sink_1

this pipeline works -- but to debug an issue with one of the components, I
tried various alternatives, such as pulling out the decode/reencode, or
doing the decode/reencode twice.  In both cases, the gst-launch graph shows
that the demux src pads don't get connected to the next elements.  That's
the part that doesn't seem to make sense -- since there is nothing upstream
that has changed, and in the case of the extra reencode, there's nothing
immediately downstream that has changed either.

For reference, here are the two (again, simplified) pipelines I'm referring
to:

no decode/reencode, just demux/remux:
  gst-launch
  muxer name=mux ! filesink location=output.ts
  filesrc location=inputfile.mpg ! demux name=d1 ! mux.audio_%d d1. !
mux.video_%d

add an extra decode/reencode:
  gst-launch
  videnc name=e ! viddec ! videnc ! mux.video_%d muxer name=mux ! filesink
location=output.ts
  filesrc location=inputfile.mpg ! demux name=d1 ! mux.audio_%d d1. !
viddec ! e.sink_1


Thanks,
Eric




On Tue, Aug 14, 2012 at 10:12 AM, Chuck Crisler <ccrisler at mutualink.net>wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/3b2faee5/attachment.html>