目标

有时我们的应用并没有按照我们的预期来工作，并且在总线上获得的错误信息也没有足够的内容。这时我们该怎么办呢？幸运的时，GStreamer自身提供了大量的调试信息，通常这些信息会给出一些线索，指向出错的地方。本教程主要讲述：

如何在GStreamer里面获得更多地调试信息

如何把你自己的调试信息加入GStreamer的调试记录

如何获得图形化的pipeline

打印调试信息

调试记录

GStreamer和插件里面都有大量的调试信息，也就是说，在调试区域内可以给出所有的信息，包括时间戳，线程，种类，源文件名，函数名等等等等

调试输出的控制实在一个GST_DEBUG的环境变量控制的，这里给出一个例子，GST_DEBUG=2:

正如你所看到的，这些信息有点过于多了。事实上，GStreamer的调试日志实在太冗余了，如果统统打开的话，很快就会让这个日志文件变成以M为单位的文件。这会让应用的运行速度降下来，所以，记录会被分类，你很少需要打开所有的种类。

第一个分类是调试等级，这个可以指定输出内容的等级：

为了允许调试内容输出，把GST_DEBUG的环境变量设置到需要的层级。所有该层级以下的信息都会显示。（比如，设GST_DEBUG=2，那么可以看到ERROR和WARNING信息）。

而且，每一个插件或者部分的GStreamer可以定义自己的种类，所以你可以对每个不同的种类指定各自的层级。例如，GST_DEBUG=2,audiotestsrc:5，会对audiotestsrc使用第5级调试等级，其余的使用第2级。

这样GST_DEBUG变量就是一个由逗号来分割的一系列“种类:层级”对了，除了在开始时给出一个默认等级值。

'*'通配符也是可以使用的。例如，GST_DEBUG=2,audio*:5就是说明除了所有audio开头的种类用第5级之外，其余的都是用第2级。

使用gst-launch-0.10 --gst-debug-help来获得所有注册的种类。记住每个插件都注册自己的种类，所以，当安装或者删除一个插件时，这个列表会变化。

当GStreamer总线上传上来的错误信息已经不够让你定位分析问题的时候，使用GST_DEBUG这个变量。常见的做法是把输出重定向到一个调试日志里面去，这样可以晚一点来查看。

调试输出的每一行的内容应该是：

加入你自己的调试信息

在你和GStreamer交互的那部分代码里面，使用GStreamer调试工具是很有意思的。在这种方法下，你会在同一个文件得到所有调试输出并且当时不同消息之间的联系也会保留下来。

为了做到这一点，请使用GST_ERROR()，GST_WARNING()，GST_INFO()，GST_LOG()和GST_DEBUG()宏。它们就像printf一样可以接受一些参数并且它们是使用默认种类的。

为了切换到某个更加有意义的种类，在你的代码之前增加这样两行：

然后再用gst_init()初始化GStreamer之后加上：

这会注册一个新的种类（这是在你的应用中，并不在任何文件里面），并把该种类设置成默认的。具体请查阅文档的GST_DEBUG_CATEGORY_INIT()内容。

获得pipeline图像

在那些pipeline变得很庞大连接关系已经看不清的例子中，GStreamer可以输出描述pipeline拓扑结构以及每个连接的Caps的协商的图像，这个文件是.dot文件，用GraphViz之类的免费软件就可以看了。

在复合element情况下，比如playbin2或者uridecodebin之类，这方法也很方便。.dot文件也可以把这些元素内部的情形绘制出来。

为了得到.dat文件，需要把GST_DEBUG_DUMP_DOT_DIR环境变量设置成你需要输出内容的文件夹。gst-launch会在每次状态变化时创建一个.dot文件，这样你可以看见Caps协商的演变。清楚这个环境变量就可以关闭这项功能。在你的应用里面，你可以使用GST_DEBUG_BIN_TO_DOT_FILE()和GST_DEBUG_BIN_TO_DOT_FILE_WITH_TS()宏来在你方便的时候获得.dot文件。

这里你有一个用playbin2创建的pipeline的例子。因为playbin2可以处理各种各样的情形，所以它的内部十分复杂。你的手动创建的pipeline一般不会这么复杂。下面是playbin2的拓扑图：