April 25, 2019
GStreamer's logging system is an incredibly powerful ally when debugging but it can sometimes be a bit daunting to dig through the massive amount of generated logs. I often find myself writing small scripts processing gst logs when debugging. Their goal is generally to automatically extract some specific information or metrics from the generated logs. Such scripts are usually quickly written and quickly disposed once I'm done with my debugging but I've been wondering how I could make them easier to write and to re-use.
gst-log-parser is an attempt to solve these two problems by providing a library parsing GStreamer logs and enabling users to easily build such tools. It's written in Rust and is shipped with a few tools that I wrote to track actual bugs in GStreamer elements and applications.
One of those tool is a buffer flow analyzer which can be used to provide various information regarding the buffers exchanged through your pipeline. It relies on logs generated by the upstream stats tracer, so no modification in GStreamer core or in plugins is required.
First step is to generate the logs, this is easily done by defining these env variables:
GST_DEBUG="GST_TRACER:7" GST_DEBUG_FILE=gst.log GST_TRACERS=stats
We can then use flow for example to detect decreasing pts or dts:
cargo run --release --bin flow gst.log check-decreasing-pts Decreasing pts tsdemux0:audio_0_0042 00:00:02.550852023 < 00:00:02.555653845
Or to detect gaps of at least 100ms in the buffers flow:
cargo run --release --bin flow gst.log gap 100 gap from udpsrc0:src : 00:00:00.100142318 since previous buffer (received: 00:00:02.924532910 previous: 00:00:02.824390592)
It can also be used to draw graphs of the pts/dts produced by each src pad over time:
cargo run --release --bin flow gst.log plot-pts
These are just a few examples of the kind of information we can extract from stats logs. I'll likely add more tools in the future and I'm happy to hear suggestions about other features that would make your life easier when debugging GStreamer.
Visit Guillaume's blog.
Until now, no Valhall devices (Mali-G57, Mali-G78) ran mainline Linux - whilst this made driver development obviously difficult, there’s…
My work on Wayland and Weston color management and HDR support has been full of learning new concepts and terms. Many of them are crucial…
It has been just over a year since we first announced our effort to implement a Wayland driver for Wine. Here's a recap of what has been…
A step-by-step guide on how to enable 3D acceleration of Vulkan applications in QEMU through the new Venus experimental Vulkan driver for…
Maintaining a non-trivial set of GStreamer patches can be tricky. Thanks to the recent move to a single, unified git repo, you can now easily…
Earlier this year, I joined Collabora as an intern to work on improving testing in libcamera and automating it through KernelCI. Having…