"pipeline is prerolling" debug strategy?

[Matt Pekar]

I run this in response to user input:

void display_pipeline_in_chrome(GstElement *pipeline) {
const char* temp_filename = "gst_bin_graph_tmp";

char dot_command[1024];
char chrome_command[1024];

const char* DIR = getenv("GST_DEBUG_DUMP_DOT_DIR");
//GstDebugGraphDetails output_flags =
GstDebugGraphDetails(GST_DEBUG_GRAPH_SHOW_MEDIA_TYPE |
GST_DEBUG_GRAPH_SHOW_STATES | GST_DEBUG_GRAPH_SHOW_NON_DEFAULT_PARAMS);
GstDebugGraphDetails output_flags =
GstDebugGraphDetails(GST_DEBUG_GRAPH_SHOW_ALL);
GST_DEBUG_BIN_TO_DOT_FILE(GST_BIN(pipeline), output_flags, temp_filename);

snprintf(dot_command, sizeof(dot_command), "dot -Tpng %s/%s.dot -o
%s/%s.png", DIR, temp_filename, DIR, temp_filename);
snprintf(chrome_command, sizeof(chrome_command), "google-chrome %s/%s.png",
DIR, temp_filename);

system(dot_command);
system(chrome_command);
}

It displays the whole pipeline as an image in Chrome, using the Gstreamer
debug output from graphviz.

However, that usually isn't enough to tell what's wrong.  For example, I
recently had a pipeline along these lines:

appsrc ! ffmpegcolorspace ! theoraenc ! rtptheorapay ! udpsink

This pipeline looked fine in the graph output, so to debug it I used the
GST_DEBUG environment variable on each element in the pipeline, starting at
the top:

GST_DEBUG=appsrc:5
--kill and restart
GST_DEBUG=ffmpegcolorspace:5
--kill and restart
GST_DEBUG=theoraenc:5
--ahhh theoraenc is dropping buffers...

Doing this one step at a time let me discover which element was blocking.
 It turns out the problem was I wasn't timestamping the appsrc buffers, and
therefore theoraenc was just dropping them.

On Thu, Aug 9, 2012 at 12:38 PM, Eric Montellese <
eric.montellese at videon-central.com> 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?
>
> Any advice?
>
> Thanks,
> Eric
>
> _______________________________________________
> 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/20120809/2cc435cc/attachment.html>