Как просмотреть вывод отладки gstreamer?
Как просмотреть вывод таких функций, как GST_CAT_INFO, GST_DEBUG и т.д.?
Нужно ли мне скомпилировать gstreamer с установленным уровнем отладки, или это можно сделать на уровне приложения?
Ответы
Ответ 1
Отладочные сообщения могут быть напечатаны в stderr с помощью переменной среды GST_DEBUG (если gstreamer скомпилирован с параметром --enable-gst-debug, который по умолчанию).
Например: GST_DEBUG=audiotestsrc:5 gst-launch audiotestsrc ! fakesink
будет записывать все (5) из элемента audiotestsrc.
Вы можете изменить вывод отладки программы во время выполнения с помощью setenv("GST_DEBUG","cat:level...", 1)
Когда-нибудь чтение отладки GStreamer может быть утомительным. Вы можете попробовать gst-debug-viewer попробовать.
Вы можете прочитать Документацию для получения дополнительной информации.
Ответ 2
Чтобы отобразить отладочную информацию для всех категорий, используйте что-то вроде
export GST_DEBUG="*:6"
перед запуском вашей команды.
Ответ 3
Я добавил уровень отладки:
gst-debug-level=4 {0->7}
Работает без сборки gstreamer снова
Ответ 4
Текущая документация здесь. Некоторые интересные выдержки, на мой взгляд:
Подстановочный знак '*'
также доступен. Например, GST_DEBUG=2,audio*:5
будет использовать уровень отладки 5 для всех категорий, начинающихся со слова audio
, и 2 для всех остальных.
Используйте gst-launch-1.0 --gst-debug-help
для получения списка всех зарегистрированных категорий.
GStreamer имеет возможность выводить графические файлы. Пример.
И уровни отладки:
| # | Name | Description |
|---|---------|----------------------------------------------------------------|
| 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. Those typically that a codepath that|
| | | is known to be incomplete has been triggered. It may work in |
| | | most cases, but may cause problems in specific instances. |
| 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 lifetime; these include setup, teardown, change of |
| | | parameters, etc. |
| 6 | LOG | Logs all log messages. These are messages for events that |
| | | happen repeatedly during an object lifetime; these include |
| | | streaming and steady-state conditions. This is used for log |
| | | messages that happen on every buffer in an element for example.|
| 7 | TRACE | Logs all trace messages. Those are message that happen very |
| | | very often. This is for example is each time the reference |
| | | count of a GstMiniObject, such as a GstBuffer or GstEvent, is |
| | | modified. |
| 8 | MEMDUMP | Logs all memory dump messages. This is the heaviest logging and|
| | | may include dumping the content of blocks of memory. |
+------------------------------------------------------------------------------+