"pipeline is prerolling" debug strategy?
Locked
"pipeline is prerolling" debug strategy?
 
|
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 [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: "pipeline is prerolling" debug strategy?
|
|
Have you read http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-checklist-debug.html
gst-inspect has an option that lists the plugin debugging name. On Thu, Aug 9, 2012 at 1:38 PM, Eric Montellese <[hidden email]> wrote: Folks, in development I've run into various malformed or buggy pipelines that give this output: _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: "pipeline is prerolling" debug strategy?
|
|
In reply to this post by Eric Montellese
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 <[hidden email]> wrote: Folks, in development I've run into various malformed or buggy pipelines that give this output: _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: "pipeline is prerolling" debug strategy?
|
|
On 08/09/2012 08:00 PM, Matt Pekar
wrote:
I run this in response to user input:FYI: you can also use xdg-open to open it with a suitable viewer. Also using svg is sometimes better when zooming.
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
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: "pipeline is prerolling" debug strategy?
|
|
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.
On Thu, Aug 9, 2012 at 3:02 PM, Stefan Sauer <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: "pipeline is prerolling" debug strategy?
|
|
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/ Stefan
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: "pipeline is prerolling" debug strategy?
|
|
In reply to this post by Eric Montellese
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 [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: "pipeline is prerolling" debug strategy?
|
|
Thank you everyone for your advice
On Fri, Aug 10, 2012 at 4:17 AM, Tim-Philipp Müller <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: "pipeline is prerolling" debug strategy?
|
|
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 <[hidden email]> wrote: Thank you everyone for your advice _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: "pipeline is prerolling" debug strategy?
|
|
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 <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: "pipeline is prerolling" debug strategy?
|
|
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 <[hidden email]> wrote: Here is a very useful link -> http://linux.die.net/man/1/gst-launch-0.10 _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: "pipeline is prerolling" debug strategy?
|
|
In reply to this post by Eric Montellese
On 08/14/2012 03:22 AM, Eric Montellese
wrote:
You should handle the return code of gst_element_link (+ related funtions) and if it fails at least log a warning. Stefan
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |