DL Streamer turns a GStreamer pipeline into a video analytics deployment

What DL Streamer adds on top of GStreamer

DL Streamer is an open-source media analytics framework built on GStreamer, and the README's summary is that it lets you build video and audio intelligence pipelines, from a simple object detection command line to a multi-stream, multi-sensor production deployment, with minimal code.

The description calls it the Deep Learning Streamer Pipeline Framework, and the project page sits under the Intel Open Edge Platform. The primary language is C++, the licence is MIT, and the repository is part of the open-edge-platform organisation.

What the framework adds over raw GStreamer is the inference layer and the surrounding plumbing. The list in the README is specific. Inference is powered by OpenVINO for optimised execution on Intel CPU, GPU and NPU. Pipelines are described as simple strings, or as Python or C++ code, and executed with full hardware acceleration. The project ships 30 or more ready-to-run samples covering detection, classification, tracking, vision language models, LiDAR and more.

The samples matter more than the headline, because they are the documentation of what a pipeline actually looks like. The samples directory is split into a gstreamer folder, a windows folder, an auto_generated_samples folder, a labels folder, and a shared_utils.py module, with a README and labels files alongside.

The repository itself is a full source tree rather than a wrapper: a CMakeLists.txt, cmake and dependencies directories, include, src, python, girs, docker, docs, samples, scripts, tests, thirdparty and vcpkg configuration files. There is a SPECS directory, a .clang-format, a CODESTYLE.md, a SECURITY.md and a pylintrc for the Python side.

The benefit table, and the parts that are genuinely different

The README's why section is a table, and most rows are ordinary. One-line pipelines mean a working detection pipeline in a single gst-launch-1.0 command. Hardware acceleration targets CPU, GPU and NPU on Intel platforms from a single codebase. VLM and GenAI readiness means running vision language models such as MiniCPM-V, CLIP and Whisper inside a GStreamer pipeline.

Three rows are worth more attention.

The first is GstAnalytics compliance, which means supporting the GStreamer industry metadata standard so that results interoperate with other GStreamer-based tools. That is a small sentence with a large consequence: it means DL Streamer's output is not a private format, and a downstream consumer that speaks GstAnalytics can read it without a bespoke adapter.

The second is messaging integration. Results can be published directly to MQTT or Kafka with built-in elements and no extra code. For a deployment that has many cameras feeding an operational system, that is the difference between a demo and a product, because the analytics pipeline and the message bus meet without a hand-written bridge.

The third is Python-first extensibility. Custom logic is added as Python callbacks or as full Python GStreamer elements, with no C++ required. Combined with the repository shipping girs directories and a python directory, that tells you the Python surface is a first-class part of the project rather than an afterthought. The requirements file also pins gstreamer-python at 1.28.2 for Windows and PyGObject at 3.50.0 elsewhere, with the comment that gstreamer-python provides PyGObject and the GStreamer Python bindings and is not available on Linux.

Multi-stream and multi-sensor is the fourth row worth reading twice. The claim is that you can mux and demux dozens of RTSP streams, LiDAR frames and radar point clouds in one process, which is the actual architecture question behind any real deployment.

Installing the drivers before the framework

The installation order is deliberate and the README puts the drivers first, because a native install and a Docker run both need them.

Step one is a prerequisites script that detects your Intel GPU or NPU, installs the correct drivers for Ubuntu 22.04 or 24.04, and adds your user to the required groups:

cd ~
wget https://raw.githubusercontent.com/open-edge-platform/dlstreamer/main/scripts/DLS_install_prerequisites.sh
chmod +x DLS_install_prerequisites.sh
./DLS_install_prerequisites.sh

The note explains the options: use --reinstall-npu-driver=yes to force a reinstall of the NPU driver, and run the script with --help for all of them.

Step two is the framework, and there are two options. Docker is described as recommended with zero setup, and the command is a good example of what a hardware pipeline container needs:

# Run once on the host to allow X11 forwarding from containers
xhost +local:docker

docker run -it --rm \
  --device /dev/dri \
  --group-add $(stat -c "%g" /dev/dri/render*) \
  -e DISPLAY=$DISPLAY \
  -e XDG_RUNTIME_DIR=/tmp \
  -v /tmp/.X11-unix:/tmp/.X11-unix \
  intel/dlstreamer:latest

The device passthrough, the group addition for the render device and the X11 forwarding are all there because the pipeline needs real GPU access and a display surface. The NPU case adds a second device and group: --device /dev/accel with a group-add for /dev/accel/accel*.

The native install on Ubuntu 24.04 is a longer block that adds Intel's apt repository and keyring and then installs the package:

sudo apt update && sudo apt-get install -y intel-dlstreamer

The full block also registers the OpenVINO repository, so a native install pulls in the inference runtime as well as the framework. The supported platforms, as the badges show, are Ubuntu 22.04, Ubuntu 24.04 and Windows 11, and the Docker image is on Docker Hub as intel/dlstreamer.

A pipeline is a string, and the device is a parameter

The running example is the part that makes the framework concrete, because it is a single gst-launch-1.0 command with a source, a decoder, a detector, a watermark and a frame counter.

gst-launch-1.0 \
  urisourcebin buffer-size=4096 uri=https://videos.pexels.com/video-files/1192116/1192116-sd_640_360_30fps.mp4 ! \
  decodebin3 ! \
  gvadetect model=~/models/yolo11n/yolo11n.xml device=GPU ! \
  queue ! \
  gvawatermark ! \
  gvafpscounter ! \
  videoconvert

Reading it left to right tells you the element vocabulary. urisourcebin pulls in the media, decodebin3 decodes it, gvadetect runs the object detection model, the queue decouples the branches, gvawatermark draws the results over the frames, gvafpscounter counts frames per second, and videoconvert closes the chain.

The gva prefix is the DL Streamer element family, and the gvadetect element takes a model path in the OpenVINO IR form, the .xml, and a device property. That device property is the point the README emphasises: change device=GPU to device=CPU or device=NPU and no other code changes are needed. That is what the single codebase claim means in practice.

The model preparation is separate from the pipeline, and it uses Python. The setup step creates a virtual environment with uv, installs the download requirements for Ultralytics models, and runs the download script with a model name, an output directory and an int8 flag:

uv venv .dls-venv && source .dls-venv/bin/activate
uv pip install -r /opt/intel/dlstreamer/scripts/download_models/requirements_download_ultralytics_models.txt
python3 /opt/intel/dlstreamer/scripts/download_models/download_ultralytics_models.py \
  --model yolo11n.pt \
  --outdir ~/models/yolo11n \
  --int8

So a YOLO11 nano model is converted into an OpenVINO IR, optionally int8 quantised, and the pipeline then references the .xml.

What the build system reveals about the dependency surface

The Makefile in the repository root is the clearest statement of what the project actually is, and it is worth reading because the packaging is unusual.

The install prefix defaults to /opt/intel/dlstreamer and the OpenVINO directory to /opt/intel/openvino_2026, and the dependency directory is build/deps. The Makefile then exports PATH, GST_PLUGIN_PATH, LIBRARY_PATH and PKG_CONFIG_PATH so that the locally built plugins and the vendored dependencies take precedence over anything installed system wide. That is what makes a from-source build usable: your GST_PLUGIN_PATH points at the build output, so gst-launch-1.0 finds the gva elements.

The feature switches are explicit. ENABLE_GENAI defaults to OFF but is turned on automatically when the distribution is Ubuntu and the OpenVINOGenAI_DIR environment variable is set, which is how the GenAI and vision language model samples are gated. ENABLE_TESTS is OFF by default. ENABLE_LIDAR_ROBOSENSE is OFF by default, and it exists to compile the Robosense LiDAR support, which is consistent with the README's mention of LiDAR frames and radar point clouds as first class inputs.

The compiler handling is a good sign of a project that meets a range of toolchains. The Makefile reads the GCC major version and, on version 15 or later, adds the -Wno-free-nonheap-object flag, which is the kind of targeted accommodation that saves every user of a new compiler a debugging session.

The Python side is pinned in requirements.txt, with numpy at 2.2.0, opencv-python at 4.11.0.86, setuptools at 84.0.0, typing-extensions, defusedxml, and a group of optimizer specific dependencies including sshkeyboard, prometheus-client and requests. The Prometheus client in particular is a clue that there is a metrics path into whatever monitoring stack the deployment uses, which fits the message bus integration story.

Where DL Streamer is the wrong tool

Three limits, and the first is a hardware one that the design makes unavoidable.

The first is that the acceleration path is Intel-specific. Inference is powered by OpenVINO for optimised execution on Intel CPU, GPU and NPU, and the whole sample set, the element vocabulary and the download scripts are built around that stack. If your target hardware is an NVIDIA GPU, an Arm NPU or a discrete accelerator from another vendor, this framework is the wrong layer, and the fact that the pipelines are GStreamer strings does not save you, because the gvadetect element itself is what binds the model to the device.

The second is that the framework is a heavy dependency for a simple job. A native install adds Intel apt repositories, the OpenVINO runtime and a set of GStreamer plugins, and the Docker path needs device passthrough and X11 forwarding configured on the host. If all you need is object detection on a video file, an ONNX Runtime or OpenCV DNN pipeline with a handful of lines of Python is a smaller thing to own, and it runs on whatever hardware you have.

The third is the branch policy, and here the README is explicit at the very top: the main branch is under active development and may be unstable, and for production use you should pick a stable version from the Releases page. That is a sensible warning, but it means the interesting recent work is on a branch you are not supposed to deploy.

The alternative approach is to use GStreamer directly with a plain inference element, which gives you the same element model, the same hardware acceleration on the same Intel devices, and no DL Streamer layer at all. The difference in approach is that DL Streamer gives you the gva element family, the prebuilt samples, the GstAnalytics compliance and the MQTT and Kafka elements as ready-made pieces, and in exchange you take a framework that is Intel-shaped, releases on a schedule tied to the Open Edge Platform, and whose most recent tag is v2026.2.0 from 2026-09-04.

Editorial conclusion

Adopt DL Streamer if you are building a video or audio analytics pipeline on Intel hardware and want GStreamer's element model combined with OpenVINO inference, because a pipeline is a string you can run and debug with gst-launch-1.0, and the device is a parameter rather than a rewrite. Do not adopt it if you need a non-Intel target, since the acceleration path is OpenVINO on Intel CPU, GPU and NPU, and do not build on the main branch, because the README states it is under active development and may be unstable, and production users are pointed at a tagged release. Verify first that your OS is in the supported set of Ubuntu 22.04, Ubuntu 24.04 or Windows 11, that the drivers are installed for your device before you install the framework, and that the GstAnalytics metadata element is available in your GStreamer build if you plan to publish results to another GStreamer-based tool.

Frequently asked questions

Official sources

1. License: MIT
2. open-edge-platform/dlstreamer on GitHub
3. Project website
4. README
5. Releases