GST_DEBUG turned up, every element reports on every buffer, and the output quickly reaches thousands of lines per second. That is the right tool when debugging an element’s internals, and the wrong one when the question is simply did my pipeline link the way I intended.
The SDK therefore offers two ways to look at the same pipeline:
- Simplified logs — the SDK reads GStreamer’s log stream, keeps only what is meaningful at application level (state changes, errors, performance figures), and reprints it in a compact, uniform format alongside its own diagnostics. This is the default.
- Raw GStreamer logs — the SDK steps out of the way and lets GStreamer log exactly as it normally would, with
GST_DEBUGfully in control.
SetImsdkGstLogMode(); how much detail the SDK’s own diagnostics carry is decided independently by SetImsdkLogLevel().
Responsibilities
- Route GStreamer’s log stream either through the SDK’s parser or through GStreamer’s default handler.
- Filter the SDK’s own diagnostics by verbosity level.
- Recognize state changes, errors, and performance reports in GStreamer’s output and re-emit them in a uniform format.
- Restore GStreamer’s default log handler when the runtime shuts down.
APIs
Both functions live in theqti namespace and are declared in qti/imsdk-logging.h, which qti/imsdk.h includes.
Simplified logs — ImsdkGstLogMode::ImsdkLog
The default. The SDK installs itself as GStreamer’s log handler, replacing the default one, and does two things with what arrives:
- It lowers GStreamer’s global threshold to errors only, then re-enables the
LOGlevel for a specific set of categories it knows how to interpret —GST_STATE,GST_STATES, and the Qualcomm element categories (qtimlvconverter,qtimlpostprocess,qtimltflite,qtivcomposer,qtivoverlay, and the rest). Everything else GStreamer would have printed is dropped before it reaches the terminal. - Of what remains, it recognizes three things and reformats them: completed state changes, errors, and performance/HW-utilization reports from the plugins. Each is reprinted through the SDK’s own logger, in the same format as the SDK’s diagnostics.
ERROR, yellow for WARN, green for INFO — which is convenient interactively and unhelpful in a log file. Set IMSDK_LOG_COLOR to 0, false, or off to disable the escape codes.
Because this mode reconfigures GStreamer’s thresholds, a
GST_DEBUG value set in the environment does not have its usual effect: categories the SDK does not interpret are silenced regardless. If you set GST_DEBUG and see less than you expected, this is why — use raw mode instead.Raw GStreamer logs — ImsdkGstLogMode::GstLog
In this mode the SDK hands every record to gst_debug_log_default(), GStreamer’s own handler, without inspecting or reformatting it. GStreamer’s log configuration is left completely untouched: thresholds are not lowered, no categories are re-enabled, and GST_DEBUG behaves exactly as it does in any other GStreamer application.
SetImsdkLogLevel().
Choosing between them
Usage
Set the mode first, before any element, filter, or pipeline is constructed, and the level wherever it is convenient:Related
- SDK Architecture and API Reference — the
Pipeline,Element, and filter APIs whose behaviour these logs describe. - Quick start guide — installation and a first pipeline.

