Difference between revisions of "GStreamer Daemon - Enabling the Debug Subsystem"

From RidgeRun Developer Connection
Jump to: navigation, search
(Added description of GStreamer debug levels - taken from https://developer.ridgerun.com/wiki/index.php?title=GStreamer_Debugging#The_GStreamer_debugging_levels_include:)
m (Debug Level)
Line 11: Line 11:
 
== Debug Level ==
 
== Debug Level ==
  
Once the Enable debug is on true, the debug level can be set, that more level shows more debug. The Debug Level takes a keyword and the debug level in the argument.
+
Once Enable debug is set to true, the debug level can be set.  Debug Level is a horrid name, as you can do much more than just specify a single level.  You can provide a list of comma separated category:level pairs, such as <tt>v4l2src:3,GST_EVENT:5</tt> to monitor both what is going on with v4l2src element and the GStreamer events that are occurring. The Debug Level takes a keyword and the debug level in the argument.
 
  <b>debug_threshold <i>threshold</i> </b>
 
  <b>debug_threshold <i>threshold</i> </b>
 
         Debug Level of the <i>pipeline</i>.
 
         Debug Level of the <i>pipeline</i>.
 +
 +
To see all the possible debug categories, run:
 +
 +
gst-launch-1.0 --gst-debug-help
  
 
The GStreamer debugging levels include:
 
The GStreamer debugging levels include:
Line 24: Line 28:
 
| 2 || style="text-align:center; background:black; color:yellow" | WARNING || Logs all warnings. Typically these are non-fatal, but user-visible problems are expected to happen.
 
| 2 || style="text-align:center; background:black; color:yellow" | WARNING || Logs all warnings. Typically these are non-fatal, but user-visible problems are expected to happen.
 
|-
 
|-
| 3 || style="text-align:center; background:black; color:green" | INFO || Logs all informational messages. These are typically used for events in the system that only happen once, or are important and rare enough to be logged at this level.
+
| 3 || style="text-align:center" |FIXME || Logs all fixme messages. Fixme messages are messages that indicate that something in the executed code path is not fully implemented or handled yet. The purpose of this message is to make it easier to spot incomplete/unfinished pieces of code when reading the debug log.
 +
|-
 +
| 4 || style="text-align:center; background:black; color:green" | INFO || Logs all informational messages. These are typically used for events in the system that only happen once, or are important and rare enough to be logged at this level.
 +
|-
 +
| 5 || style="text-align:center; background:black; color:aqua" | DEBUG || Logs all debug messages. These are general debug messages for events that happen only a limited number of times during an object's lifetime; these include setup, teardown, change of parameters, ...
 
|-
 
|-
| 4 || style="text-align:center; background:black; color:aqua" | DEBUG || Logs all debug messages. These are general debug messages for events that happen only a limited number of times during an object's lifetime; these include setup, teardown, change of parameters, ...
+
| 6 || style="text-align:center; background:black; color:gray" | LOG || Logs all log messages. These are messages for events that happen repeatedly during an object's lifetime; these include streaming and steady-state conditions.
 
|-
 
|-
| 5 || style="text-align:center; background:black; color:gray" | LOG || Logs all log messages. These are messages for events that happen repeatedly during an object's lifetime; these include streaming and steady-state conditions.
+
| 7 || style="text-align:center" | TRACE || Logs all trace messages. These messages for events that happen repeatedly during an object's lifetime such as the ref/unref cycles.
 
|-
 
|-
 
| 9 || style="text-align:center" | buffer<br>dump || Hex dump of buffer contents.
 
| 9 || style="text-align:center" | buffer<br>dump || Hex dump of buffer contents.

Revision as of 15:49, 22 July 2020


Previous: Receiving Signals Index Next: Low-level Implementation for Applications




This wiki shows how to enable the debug to a given pipeline. Sometimes the errors in a pipeline can be hard to debug, however that tool can enable and modify the level of the debug as your needed and debug a pipeline easier.

Enable Debug

Enable debug using the command shown below. The Debug takes the argument true or false.

debug_enable true/false 
       Enable debug of the pipeline.

Debug Level

Once Enable debug is set to true, the debug level can be set. Debug Level is a horrid name, as you can do much more than just specify a single level. You can provide a list of comma separated category:level pairs, such as v4l2src:3,GST_EVENT:5 to monitor both what is going on with v4l2src element and the GStreamer events that are occurring. The Debug Level takes a keyword and the debug level in the argument.

debug_threshold threshold 
       Debug Level of the pipeline.

To see all the possible debug categories, run:

gst-launch-1.0 --gst-debug-help

The GStreamer debugging levels include:

0 none No debug information is output.
1 ERROR Logs all fatal errors. These are errors that do not allow the core or elements to perform the requested action. The application can still recover if programmed to handle the conditions that triggered the error.
2 WARNING Logs all warnings. Typically these are non-fatal, but user-visible problems are expected to happen.
3 FIXME Logs all fixme messages. Fixme messages are messages that indicate that something in the executed code path is not fully implemented or handled yet. The purpose of this message is to make it easier to spot incomplete/unfinished pieces of code when reading the debug log.
4 INFO Logs all informational messages. These are typically used for events in the system that only happen once, or are important and rare enough to be logged at this level.
5 DEBUG Logs all debug messages. These are general debug messages for events that happen only a limited number of times during an object's lifetime; these include setup, teardown, change of parameters, ...
6 LOG Logs all log messages. These are messages for events that happen repeatedly during an object's lifetime; these include streaming and steady-state conditions.
7 TRACE Logs all trace messages. These messages for events that happen repeatedly during an object's lifetime such as the ref/unref cycles.
9 buffer
dump
Hex dump of buffer contents.

Enable Debug Colors

Sometimes analyze a log can be heavy or maybe bored, the debug color can be that task easier to search and found the error. Debug color takes true/false in the argument.

debug_color true/false 
       Debug Color of the pipeline.

For example:
Gstd Commands:

1 pipeline_create p1 videotestsrc ! autovideosink
2 pipeline_play p1
3 debug_enable true 
4 debug_threshold *sink*:6
5 debug_color true

will respectively

  1. Create a pipeline p1
  2. Put it to playing
  3. Enable debug
  4. Set the debug level on 6
  5. Enable the debug color

The debug command will typically fail for any of the following:

  • No pipeline was given
  • Wrong debug property

Alternatively, the debug can be enable using the low level CRUD syntax:
Gstd Commands:

1 update /debug/enable <true/false>
2 update /debug/threshold/ <value>
3 update /debug/color/ <true/false>

API Summary

High Level Command Low Level CRUD Description
debug_enable <true/false> update /debug/enable <true/false> Enable debug of the pipeline
debug_threshold <threshold> update /debug/threshold <threshold> Set the level of debug
debug_color <true/false> update /debug/color <true/false> Enable the color in debug


Previous: Receiving Signals Index Next: Low-level Implementation for Applications