[gst-devel] Re: debug

Benjamin Otte in7y118 at public.uni-hamburg.de
Wed Jun 25 17:34:22 CEST 2003

On 25 Jun 2003, Thomas Vander Stichele wrote:

> a) I find GST_DEBUG_DEBUG a bad name, and I also think
> For the second, maybe COLOR_FG_RED and COLOR_BG_RED would be a solution.
I'm gonna change that to GST_LEVEL_* and use the FG/BG suggestion. That
sounds good.

> b) It looks like this will break compatibility between 0.7 and 0.6
> completely.  Some people might think this is not a big deal, but I
> happen to think it is.  Some reasons for that are:
> - it is getting increasingly harder to backport fixes from HEAD to 0.6;
> when this is hard because of actual functional changes between the code,
> it is OK to me.  When this is hard because of (very much needed but
> still) cosmetical changes, this is slightly more painful.
There are two solutions.
For people who want the old debugging because they develop aghainst 0.6 is
to define GST_DEBUG_USE_DEPRECATED before including <gst/gst.h>.
In that case the new debugging is nearly 100% compatible
(GST_DEBUG_ENTER/LEAVE are gone). However you're still limited by the old
This option is undocumented, because I intend to remove it once 0.8 hits
the streets and 0.6 becomes unsupported. We don't want to be backwards
compatible before hitting 1.0
When backporting code in the plugins, just remove the category initialization
(3 lines per category, that is doable) and do "s/GST_DEBUG[ ]*(/GST_DEBUG
(0,/" and the same for GST_INFO. But since we're not doing big backports
anymore, all the stuff should be fixable by hand anyway.

As for the compatibility we will be pretty much done with it anyway when
Ronalds mime type changes land.

> Other than that, nice work.  Maybe you should put online a sample of
> debug info so we can see the effect.  I'm guessing especially Wim has
> opininions about the result since he's the one that's best at actually
> reading the damned logs and fixing bugs because of it :)
Well the output hasn't changed very much. It's still the same messages and
they're still in the same category. And I haven't cleaned up the
DEBUG/INFO mess just yet (I don't want to do that, I expect that to happen
as stuff gets rewritten, checked or whatever). The benefits are in being
able to use finer control about what is output, especially when writing
plugins, apps or libs for GStreamer.
The only benefit I know right now: Playing an mp3 with ALL messages enabled
(formerly --gst-mask=-1 now --gst-debug-level=5) is 4.8MB. If you just
remove the 60 most coomon always repeating messages by disabling the LOG
messages, you get down to 60kB. That log is as useful but easier to send
somewhere :)


More information about the gstreamer-devel mailing list