"pipeline is prerolling" debug strategy?

[Stefan Sauer]

On 08/09/2012 10:23 PM, Matt Pekar wrote:
> Something relatively simple that may help is a "buffers_received"
> integer property that keeps track of how many buffers have passed
> through an element.  With that users could see which element the
> stream was halting on.  It could also help detect balance issues (say
> on a tee where one sink is too slow), or to see where frames are being
> dropped.

For that you can use gst-tracelib.
http://cgit.freedesktop.org/~ensonic/gst-tracelib/
<http://cgit.freedesktop.org/%7Eensonic/gst-tracelib/>

Stefan

>
> On Thu, Aug 9, 2012 at 3:02 PM, Stefan Sauer <ensonic at hora-obscura.de
> <mailto:ensonic at hora-obscura.de>> wrote:
>
>     On 08/09/2012 08:00 PM, Matt Pekar wrote:
>>     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);
>     FYI: you can also use xdg-open to open it with a suitable viewer.
>     Also using svg is sometimes better when zooming.
>
>>
>>     system(dot_command);
>>     system(chrome_command);
>>     }
>>
>>     It displays the whole pipeline as an image in Chrome, using the
>>     Gstreamer debug output from graphviz.
>
>     Thing worth looking for in the graph are:
>     * disconnected elements (obvious)
>     * pads with uppercase 'F' (= flushing) (missing flush stop or
>     activation)
>     * not negotiated elements (some elements have a long list of caps,
>     instead simple caps)
>
>     If there are good ideas how, the graphs can be improved to
>     highlight more issues, let us know.
>
>     Stefan
>
>>
>>     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
>>     <mailto: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
>>         <mailto:gstreamer-devel at lists.freedesktop.org>
>>         http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>>
>>
>>
>>     _______________________________________________
>>     gstreamer-devel mailing list
>>     gstreamer-devel at lists.freedesktop.org <mailto:gstreamer-devel at lists.freedesktop.org>
>>     http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
>     _______________________________________________
>     gstreamer-devel mailing list
>     gstreamer-devel at lists.freedesktop.org
>     <mailto: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/20120810/2d3d3d05/attachment.html>