25.2. Debugging

• Elements should never use their standard output for debugging (using functions such as printf () or g_print ()). Instead, elements should use the logging functions provided by GStreamer, named GST_DEBUG (), GST_LOG (), GST_INFO (), GST_WARNING () and GST_ERROR (). The various logging levels can be turned on and off at runtime and can thus be used for solving issues as they turn up. Instead of GST_LOG () (as an example), you can also use GST_LOG_OBJECT () to print the object that you're logging output for.

• Ideally, elements should use their own debugging category. Most elements use the following code to do that:

  GST_DEBUG_CATEGORY_STATIC (myelement_debug);
  #define GST_CAT_DEFAULT myelement_debug
  
  [..]
  
  static void
  gst_myelement_class_init (GstMyelementClass *klass)
  {
  [..]
    GST_DEBUG_CATEGORY_INIT (myelement_debug, "myelement",
  			   0, "My own element");
  }
          

  At runtime, you can turn on debugging using the commandline option --gst-debug=myelement:5.

• Elements should use GST_DEBUG_FUNCPTR when setting pad functions or overriding element class methods, for example:

  gst_pad_set_event_func (myelement->srcpad,
      GST_DEBUG_FUNCPTR (my_element_src_event));
            

  This makes debug output much easier to read later on.

• Elements that are aimed for inclusion into one of the GStreamer modules should ensure consistent naming of the element name, structures and function names. For example, if the element type is GstYellowFooDec, functions should be prefixed with gst_yellow_foo_dec_ and the element should be registered as 'yellowfoodec'. Separate words should be separate in this scheme, so it should be GstFooDec and gst_foo_dec, and not GstFoodec and gst_foodec.