
Gst-Audit: The instrumentation tool for your pipelines

Written by
Jorge ZapataMarch 10, 2026
During the 2025 Innovation Days at Fluendo, similar to what happened on past editions, we had time to prototype crazy and innovative ideas we had in mind. One of those ideas was to build an instrumentation tool almost everyone who starts working with GStreamer wants. A visual editor. An application where you can move and link boxes and you can define your new pipeline. This is what is now called Gst-Audit

State-of-the-art
Building a visual editor for GStreamer is not a new idea, it has had different attemps in time and remains being a very useful tool, especially for newcomers and not CLI enthusiasts.
Since GStreamer’s inception, a DirectShow visual application already existed, GraphEdit; nowadays, in tools like NVIDIA’s Deepstream, a visual editor also exists, check the Deepstream composer tool. Sadly, for GStreamer, there is no open-source tool that has consolidated as the main visual editor for pipelines.
Here is a list of similar projects, being GstPipelineStudio actively developed:
In general, these tools make sense for toying with a pipeline and prototyping, but what if you already have a pipeline in production? How do you know its structure? What about the logs it is emitting? Or the messages, signals, etc…
That’s the purpose of Gst-Audit, to instrument also your running pipeline.
Architecture
The idea for this application was to use a web-based interface, mainly because of the large number of modern tools in the web development ecosystem that can make the application look nice. Also, the need to work similarly to what you will do locally, that is, using the same GStreamer/GLib API but in an idiomatic way. And finally, the possibility to change in runtime what is going on with a GStreamer-based application, without having to launch, debug, and kill the debugging iteration.

Gst-Audit is composed of several components:
- GIRest: The bindings for GObject Introspection (GI) and exposed as a REST API
- GstAudit Sever: The server of the GStreamer/GLib REST API, plus some specific endpoints for pipeline managing
- GstAudit: The client of the
GstAudit Server, a TypeScript based React/Next.js application
GIRest
GIRest is itself having several tools, all made in Python, that allows you to generate a REST API based on a GI Namespace, to serve such API and resolve the API calls, and finally to generate TypeScript bindings. The most important part is how the API calls are resolved. GIRest is based on connexion, therefore, once the OpenAPI spec (the REST API) is defined, we need serve that and be compliant to what is expected API wise. We currently support one main resolver which is based on Frida, that basically converts the received endpoint call into a C function call that is injected into the binary process to debug, in runtime. You have a swagger available too so you can play with your running process and see how it behaves.
This way, we can call any C function as if we were working locally, but it will be injected into the actual process. Of course, this can bring multiple headaches, especially in the memory management.
GstAuditServer
This is just a thin wrapper on top of the GIRest server but adding support for inspecting the GstPipelines available in the process and exposing that as a REST endpoint. With that, any application can easily search for all the pipelines available in the process and start the debugging session.
GstAudit
This is the main front-end. It is currently a client-only React application, but it will soon become a client and server application. The purpose of this application is to interact with the pipeline graph visualization, control the timeline and states, change the debugging logs, and modify element properties, etc. I think there are plenty of potential use cases you can come up with, and we’ll be happy to implement them. Take a look at Gst-Audit, give it a try, and send us your feedback!
