調試記錄
GStreamer和插件裡面都有大量的調試資訊，也就是說，在調試區域内可以給出所有的資訊，包括時間戳，線程，種類，源檔案名，函數名等等。
調試輸出的控制是在一個GST_DEBUG的環境變量控制的，這裡給出一個例子，GST_DEBUG=2:
0:00:00.868050000 1592 09F62420 WARN filesrc gstfilesrc.c:1044:gst_file_src_start:<filesrc0> error: No such file "non-existing-file.webm" 正如你所看到的，這些資訊有點過于多了。事實上，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這個變量。常見的做法是把輸出重定向到一個調試日志裡面去，這樣可以晚一點來檢視。
調試輸出的每一行的内容應該是：
0:00:00.868050000 1592 09F62420 WARN filesrc gstfilesrc.c:1044:gst_file_src_start:<filesrc0> error: No such file "non-existing-file.webm" | 0:00:00.868050000 | 時間戳，HH:MM:SS:sssssssss，記錄自從應用開始之後的時間 |
| 1592 | 程序ID |
| 09F62420 | 線程ID |
| WARN | 調試資訊等級 |
| filesrc | 調試資訊種類 |
| gstfilesrc.c:10444 | 檔案名，行号 |
| gst_file_src_start | 函數名 |
| <filesrc0> | |
加入你自己的調試資訊
在你和GStreamer互動的那部分代碼裡面，使用GStreamer調試工具是很有意思的。在這種方法下，你會在同一個檔案得到所有調試輸出并且當時不同消息之間的聯系也會保留下來。
為了做到這一點，請使用GST_ERROR()，GST_WARNING()，GST_INFO()，GST_LOG()和GST_DEBUG()宏。它們就像printf一樣可以接受一些參數并且它們是使用預設種類的。
為了切換到某個更加有意義的種類，在你的代碼之前增加這樣兩行：
GST_DEBUG_CATEGORY_STATIC (my_category);
#define GST_CAT_DEFAULT my_category 然後再用gst_init()初始化GStreamer之後加上：
GST_DEBUG_CATEGORY_INIT (my_category, "my category", 0, "This is my very own"); 這會注冊一個新的種類（這是在你的應用中，并不在任何檔案裡面），并把該種類設定成預設的。具體請查閱文檔的GST_DEBUG_CATEGORY_INIT()内容。
獲得pipeline圖像
在那些pipeline變得很龐大連接配接關系已經看不清的例子中，GStreamer可以輸出描述pipeline拓撲結構以及每個連接配接的Caps的協商的圖像，這個檔案是.dot檔案，用GraphViz之類的免費軟體就可以看了。
在複合element情況下，比如playbin或者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檔案。
這裡你有一個用playbin建立的pipeline的例子。因為playbin2可以處理各種各樣的情形，是以它的内部十分複雜。你的手動建立的pipeline一般不會這麼複雜。下面是playbin的拓撲圖：
