Jump to content

Holoscan vs GStreamer

From RidgeRun Developer Wiki

🚧 Documentation is under development

The Holoscan SDK guide is currently under active development. Some sections may be incomplete or change without notice.

Questions? Contact RidgeRun or email to support@ridgerun.com.

Holoscan SDK logo
Holoscan SDK

Contents Pin






Application optimization and development
Camera capture, preprocessing and display choices affect the performance of the complete application. RidgeRun can compare these options on your target hardware and help optimize the pipeline for your requirements. Contact RidgeRun.


How to read the benchmark
Read each result with its execution context. The workload tables show the application, capture path, operators, display or sink, and measurement boundary for each graph and table.


Benchmark sections

Executive summary

This benchmark compares GStreamer/DeepStream, Holoscan 4.5, and Holoscan 5 on an NVIDIA Jetson AGX Orin using an IMX274 camera.

It looks at the practical differences between the frameworks for camera capture, display, and YOLO11n inference. It includes optical measurements and software measurements such as latency, processing time, CPU usage, GPU utilization, and memory consumption.

The Holoscan 5 applications and custom operators were ported and validated for this benchmark. They were evaluated alongside the Holoscan 4.5 and GStreamer/DeepStream pipelines.

Each result includes the capture path, the work performed by the operators, the display or sink, and the measurement method. The benchmark covers camera capture, display, YOLO11n inference, software timing, CPU utilization, GPU utilization, process memory, and optical Glass-to-Glass latency on an NVIDIA Jetson AGX Orin using an IMX274 camera.

It includes GStreamer and DeepStream, Holoscan 4.5, and Holoscan 5. The results apply to the tested configurations and measurement boundaries.

Finding What the measurement includes Practical reading
Lowest measured capture G2G latency Holoscan 5 Argus with exclusive DRM display: 35.05 ms Argus uses the Jetson ISP before the Holoscan graph and the exclusive display path changes the capture-to-display boundary.
Lowest capture process CPU Holoscan 5 Argus with exclusive DRM display: 0.60% The result applies to this capture, display, resolution, and measurement configuration.
Lowest capture process RSS Holoscan 5 V4L2 with exclusive DRM display: 82.0 MB The result is specific to the raw V4L2 USERPTR pipeline and its display path.
Lowest software interlatency Holoscan 5 YOLO11n path: 4.832 ± 0.697 ms This is a framework-specific software trace boundary, not optical Glass-to-Glass latency.
Lowest measured inference processing time Holoscan 4.5 YOLO11n path: 2.970 ± 0.481 ms The timing covers the instrumented processing scope. It does not determine complete-pipeline latency by itself.
Holoscan 4.5 and Holoscan 5 inference GPU utilization 34.38% and 34.95% The small difference should be examined with CUDA activity, kernel launches, and synchronization details before drawing a performance conclusion.
Argus and raw V4L2 GPU comparison Argus receives ISP-processed NV12; V4L2 receives raw Bayer and performs GPU image processing A higher GPU value on the raw V4L2 path can reflect additional Bayer correction and debayer work, not a framework-wide efficiency difference.

Choose the row that matches the product requirement. Check the capture interface, display mode, inference work, and measurement boundary together.

Overview

Evaluated Use Cases

The benchmark has two use cases:

Use Case Description
Capture + Display Capture, process and display a video stream without inference.
Capture + Inference Capture a video stream, preprocess the frame, execute YOLO11n inference and consume the result without displaying it.

For Capture + Display, Holoscan uses Argus or V4L2 capture with either X11 for non-exclusive display or DRM/KMS for exclusive display. GStreamer uses Argus with either NV3DSink or NVDRMVideoSink.

For Capture + Inference, DeepStream uses Argus capture, YOLO11n inference and fakesink. Holoscan 4.5 uses V4L2 USERPTR capture, while Holoscan 5 uses the custom v4l2_source_userptr operator. Both Holoscan pipelines use CUDA preprocessing, a serialized TensorRT engine and a terminal fakesink.

Workload Interpretation

GPU numbers depend on the work performed by each pipeline. The capture and inference configurations do different work, so a higher GPU value in one group does not by itself show that a framework is less efficient.

Workload Capture path Pipeline work represented Terminal output
Capture + Display: Argus Argus and the Jetson ISP provide an NV12 stream. The application does not run a separate GPU Bayer-debayer stage. Holoscan converts NV12 to BGRA on the GPU before display; GStreamer/DeepStream use their Argus display path. X11, DRM/KMS or the corresponding GStreamer sink
Capture + Display: V4L2 The IMX274 delivers 10-bit raw Bayer (RG10/RAW10) at the 60 FPS target through V4L2. The pipeline accesses the raw frame, performs the required correction and Bayer-to-color conversion/debayer on the GPU, and prepares a displayable BGRA image. X11, DRM/KMS or Holoviz
Capture + Inference: DeepStream Argus and the Jetson ISP provide the camera stream. The application runs the DeepStream inference path and consumes the result; it does not include display work. fakesink
Capture + Inference: Holoscan The IMX274 delivers 10-bit raw Bayer (RG10/RAW10) at the 60 FPS target through V4L2 USERPTR. A fused CUDA preprocessing stage performs Bayer debayer, resize, letterbox, gain adjustment and normalization before TensorRT inference. This work is included in the inference configuration. fakesink

Keep this difference in mind: Argus still performs camera processing through the Jetson ISP, but the application does not perform the same explicit GPU debayer stage as the raw V4L2 examples. An Argus capture-and-display value and a raw V4L2 capture-and-display value therefore include different processing paths. The Holoscan inference values also include raw capture and GPU preprocessing before TensorRT, while the inference configurations do not include display.

For application commands and operator links, open the Implemented Applications section. The Holoscan RidgeRun operators section has the operator contracts.

Evaluated Metrics

The benchmark reports these metrics for each use case:

Metric Capture + Display Capture + Inference
Glass to Glass (G2G) Latency Optical capture and display comparison Not applicable
Software Interlatency Not applicable Primary software path comparison
Inference Processing Time Not applicable Duration of the instrumented inference operator
Process CPU Utilization Available for all tested capture paths Available for all tested capture paths
GPU Utilization Available for all tested capture paths Available for all tested inference paths
Process RAM (RSS) Available for all tested capture paths Available for all tested capture paths

How to read the results: CPU is the monitored process tree's utilization as a percentage of total CPU capacity, not system CPU usage. RAM is the process tree's resident memory (RSS). CPU and RAM use five baseline run means; their chart error bars show the sample standard deviation between those five means. Software timing charts use the mean and standard deviation of the traced observations. G2G is a separate optical measurement. Do not infer it from software timings.

Test Environment

These settings describe the Orin benchmark configuration. The optical G2G measurements and the process/software measurements are separate test sets.

Parameter Configuration
Platform NVIDIA Jetson AGX Orin
Jetson Linux R39.2.1
Power Mode MAXN (nvpmodel mode 0)
Jetson Clocks Enabled (jetson_clocks) during the Orin benchmark measurements
Framework Versions Holoscan 4.5.0; Holoscan 5.0; GStreamer 1.24.2; DeepStream 9.1.0
Camera IMX274; Argus capture cases and V4L2 capture varying from case to case
Resolution 1920 × 1080
Frame Rate 60 FPS target
Pixel Format RAW10 (RG10) on the Holoscan V4L2 path; NV12/NVMM on the GStreamer/DeepStream Argus pipelines
Display DisplayPort monitor, nominal 144 Hz; X11 metadata reports 1920 × 1080 at 143.85 Hz. Exclusive display paths are identified separately.
Inference Model YOLO11n
Inference Engine TensorRT 10.16.2 (package version 10.16.2.10)
Benchmark Protocol Five runs per configuration; 600 frames per run; 8 ms telemetry sampling interval; baseline, Flow and Nsight profiles

Benchmark Protocol note: The baseline profile measures the application without instrumentation, Flow collects Holoscan graph timing data, and Nsight collects CUDA and system profiling data.

Use Implemented applications to trace each result to its command and operator chain. The Holoscan RidgeRun operators section has the operator details.

Capture + Display

This use case captures and displays the camera stream without inference.

The measurements are Glass to Glass (G2G) latency, process CPU utilization, GPU utilization, and process RAM (RSS).

Execution context

Open the application name to see its command and complete operator chain.

Configuration Application details Capture and processing stages Display path
GStreamer Argus, NV3DSink External GStreamer pipeline Argus and the Jetson ISP provide the camera stream. NV3DSink
GStreamer Argus, NVDRMVideoSink External GStreamer pipeline Argus and the Jetson ISP provide the camera stream. NVDRMVideoSink
Holoscan 4.5 Argus, windowed argus_camera ArgusCameraOp, FlowTracePassOp, and HolovizOp. Holoviz window
Holoscan 4.5 Argus, exclusive argus_camera Same Argus capture and GPU image-processing path as the windowed configuration. Holoviz exclusive display
Holoscan 4.5 V4L2, windowed v4l2_imx274 V4L2MmapCaptureOp, RawImageProcessorOp, BayerDemosaicOp, Rgba16GainOp, and HolovizOp. Holoviz window
Holoscan 4.5 V4L2, exclusive v4l2_imx274 Same raw Bayer processing path as the windowed configuration. Holoviz exclusive display
Holoscan 5 Argus, windowed argus_camera_x11 ArgusCameraOp reads the Argus stream and emits a BGRA CUDA tensor. X11DisplayOp
Holoscan 5 Argus, exclusive argus_camera_drm Same Argus capture and NV12-to-BGRA processing path as the windowed configuration. DrmBgraDisplayOp
Holoscan 5 V4L2, windowed v4l2_userptr_x11 V4L2UserPtrSourceOp and RawBayerToBgraOp. X11DisplayOp
Holoscan 5 V4L2, exclusive v4l2_userptr_drm Same raw Bayer capture and CUDA processing path as the windowed configuration. DrmBgraDisplayOp

Resource and optical measurements

The execution context identifies the application, operators, and display path for each configuration.

CPU Utilization

Capture and display process CPU utilization is normalized to total CPU capacity.

Process CPU utilization for the ten capture and display configurations. Bars are ordered from highest to lowest mean; error bars and labels show the available standard deviation. CPU percentages are normalized to total CPU capacity.

GPU Utilization

Capture and display GPU utilization uses application-period samples from dedicated GPU measurements. The workload interpretation explains the Argus and raw V4L2 differences.

Application-period GPU utilization for the ten capture and display configurations. Bars are ordered from highest to lowest mean; error bars and labels show the available standard deviation. Argus and raw V4L2 processing differences are explained in the workload interpretation.

Process Memory (RSS)

Capture and display RSS is the resident memory of the monitored process tree, including shared pages.

Process RSS for the ten capture and display configurations, shown in MB. Bars are ordered from highest to lowest mean; error bars and labels show the available standard deviation. Values represent the resident memory of the monitored process tree, not total system memory.

G2G Latency

G2G latency is an optical measurement of the capture and display path. The sample-level scope and numeric summary are in the capture results table.

Average capture and display G2G latency with standard deviation for the configurations with available optical measurements. Configurations are ordered from highest to lowest mean latency. G2G is an optical measurement and is not inferred from software timings.
Capture and display G2G latency for each optical sample and configuration. The numeric summary and measurement scope are in the capture results table.

Results

G2G latency is the arithmetic mean of 20 optical samples per configuration. The G2G values are retained from the existing measurements; CPU and RSS come from the five baseline runs for each corresponding configuration. GPU values are populated from the measurements that best match each capture path.

Framework / Configuration Average G2G Latency (ms) Average Process CPU (%) Average GPU Utilization (%) Average Process RSS (MB)
GStreamer Argus: NV3DSink 76.54 2.56 29.89 154.0
GStreamer Argus: NVDRMVideoSink 53.06 2.80 0.00 173.7
Holoscan 4.5 Argus Capture and Display: No Exclusive Display 46.45 1.72 34.00 228.0
Holoscan 4.5 Argus Capture and Display: Exclusive Display 38.45 1.58 20.33 232.5
Holoscan 4.5 V4L2 Direct Capture: No Exclusive Display 46.65 4.78 37.55 176.4
Holoscan 4.5 V4L2 Direct Capture: Exclusive Display 40.25 4.56 37.41 232.5
Holoscan 5 Argus Capture and Display: No Exclusive Display 46.40 1.20 28.16 144.8
Holoscan 5 Argus Capture and Display: Exclusive Display 35.05 0.60 8.17 136.6
Holoscan 5 V4L2 Direct Capture: No Exclusive Display 42.80 2.53 34.23 92.7
Holoscan 5 V4L2 Direct Capture: Exclusive Display 39.00 1.55 18.95 82.0

Analysis

  • Latency: Holoscan 5 with Argus and Exclusive DRM Display achieves the lowest overall G2G latency (35.05 ms), approximately 9% lower than Holoscan 4.5 with the equivalent configuration and 34% lower than GStreamer NVDRMVideoSink.
  • Resource efficiency: Holoscan 5 Argus configurations show significant improvements in CPU and memory usage compared to Holoscan 4.5. With Exclusive DRM Display, CPU utilization decreases from 1.58% to 0.60%, while memory consumption drops from 232.5 MB to 136.6 MB.
  • Capture method: Argus consistently outperforms direct V4L2 capture in Holoscan 5, particularly in latency. However, V4L2 configurations generally consume less memory. GPU utilization should be interpreted considering that V4L2 performs additional Bayer processing on the GPU, while Argus benefits from the Jetson ISP.
  • Display method: Exclusive DRM Display reduces G2G latency across all Holoscan configurations. However, its impact on CPU, GPU, and memory utilization varies depending on the capture method and framework version.

Capture + Inference

This use case captures video and runs YOLO11n detection without displaying the result. The goal is to measure inference only. DeepStream uses Argus and fakesink; Holoscan uses V4L2 and its own version of the fakesinkOp.

Execution context

Open the application name to see the command and complete operator chain.

Configuration Application details Operators and processing Output
DeepStream YOLO11n, Argus, fakesink External DeepStream pipeline Argus capture, DeepStream inference path, and fakesink. fakesink
Holoscan 4.5 YOLO11n, V4L2 USERPTR, fakesink yolo_model_deployment V4L2UserPtrSourceOp, FusedBayerPreprocessorOp, InferenceOp, and FakesinkOp. fakesink
Holoscan 5 YOLO11n, V4L2 USERPTR, fakesink yolo11_userptr_inference V4L2UserPtrSourceOp, RawBayerToYoloTensorOp, TensorRtInferenceOp, and FakesinkOp. fakesink

Inference measurements

Software Interlatency

Interlatency measures the software path between the source and sink element/operator.

  • DeepStream: nvarguscamerasrc0_src → fakesink0_sink.
  • Holoscan 4.5: V4L2 USERPTR pipeline → fakesink.
  • Holoscan 5: v4l2_source_userptr → fakesink.

The trace boundaries are framework-specific, so interlatency represents software-path timing, not Glass-to-Glass latency.

Software interlatency and inference processing time for DeepStream, Holoscan 4.5, and Holoscan 5. The trace boundaries and processing scope are described in the sections below.

Inference Processing Time

Inference processing time measures the processing work performed by the inference element/operator.

  • DeepStream uses Argus capture, the DeepStream inference path, and fakesink.
  • Holoscan 4.5 uses V4L2 USERPTR capture, preprocessing, inference, and fakesink.
  • Holoscan 5 uses v4l2_source_userptr, CUDA preprocessing, TensorRT inference, and fakesink.

CPU Utilization

CPU usage is process-tree utilization normalized to total CPU capacity.

Process CPU utilization for the three inference-without-display configurations. Bars are ordered from highest to lowest mean; error bars and labels show the available standard deviation.

GPU Utilization

GPU usage is measured during the application period. It includes capture, raw-frame preprocessing where applicable, and inference, but no display. The workload interpretation explains the difference between the Argus and raw V4L2 paths.

Application-period GPU utilization for the three inference-without-display configurations. Bars are ordered from highest to lowest mean; error bars and labels show the available standard deviation.

Process Memory (RSS)

RSS is the resident memory of the monitored process tree, including shared pages.

Process RSS for the three inference-without-display configurations, shown in MB. Bars are ordered from highest to lowest mean; error bars and labels show the available standard deviation.

Results

Timing columns report mean ± standard deviation in milliseconds. GPU utilization is the application-period average from the dedicated GPU measurements, not utilization attributed exclusively to the process.

Framework / Configuration Software Interlatency (ms) Inference Processing Time (ms) Average Process CPU (%) Average GPU Utilization (%) Average Process RSS (MB)
DeepStream YOLO11n: Argus: fakesink 13.000 ± 5.151 10.693 ± 2.779 4.97 32.12 668.6
Holoscan 4.5 YOLO11n: V4L2 USERPTR: fakesink 5.734 ± 1.416 2.970 ± 0.481 3.07 34.38 703.3
Holoscan 5 YOLO11n: V4L2 USERPTR: fakesink 4.832 ± 0.697 3.718 ± 0.648 2.45 34.95 543.4

Analysis

  • Interlatency: Holoscan 5 achieves the lowest interlatency (4.832 ± 0.697 ms), approximately 16% lower than Holoscan 4.5. It also shows reduced timing variability, indicating more consistent frame processing.
  • Inference performance: Holoscan 4.5 reports the lowest inference processing time (2.970 ± 0.481 ms), while Holoscan 5 increases to 3.718 ± 0.648 ms (approximately 25% higher). Despite this increase, Holoscan 5 achieves better overall software interlatency, suggesting improvements elsewhere in the pipeline.
  • Resource efficiency: Holoscan 5 reduces process CPU utilization by approximately 20% and memory consumption by 23% compared to Holoscan 4.5, while maintaining similar average GPU utilization (34.95% vs. 34.38%).
  • Framework comparison: Both Holoscan versions report substantially lower software interlatency and inference processing times than the tested DeepStream configuration. However, differences in capture paths and pipeline implementations mean these results should not be interpreted as an isolated comparison of inference engine performance.

Compare the workloads

Compare configurations that do the same work and use the same measurement.

Category GStreamer / DeepStream Holoscan 4.5 Holoscan 5
Capture + Display NVDRMVideoSink has lower G2G latency than NV3DSink: 53.06 ms versus 76.54 ms. NV3DSink has the lowest GStreamer capture RSS at 154.0 MB. Argus with Exclusive Display has the lowest Holoscan 4.5 capture G2G latency at 38.45 ms and the lowest Holoscan 4.5 capture CPU utilization at 1.58%. Argus with Exclusive DRM has the lowest Holoscan 5 capture G2G latency at 35.05 ms. Holoscan 5 V4L2 reports 72.20 ms with X11 Display and 66.15 ms with DRM Display. Argus Exclusive has the lowest Holoscan 5 capture CPU utilization at 0.60%, while V4L2 Exclusive has the lowest Holoscan 5 capture RSS at 82.0 MB.
Capture + Inference DeepStream with fakesink has a software interlatency of 13.000 ± 5.151 ms and an inference processing time of 10.693 ± 2.779 ms. Holoscan 4.5 reports a software interlatency of 5.734 ± 1.416 ms and an inference processing time of 2.970 ± 0.481 ms. Holoscan 5 reports the lowest software interlatency at 4.832 ± 0.697 ms. Its inference processing time is 3.718 ± 0.648 ms.
Process Resources NV3DSink has the lowest capture RSS at 154.0 MB. DeepStream fakesink reports 4.97% CPU and 668.6 MB RSS for inference. The lowest capture CPU utilization is 1.58% with Argus Exclusive Display. The Holoscan 4.5 YOLO11n path reports 3.07% CPU and 703.3 MB RSS. The lowest Holoscan 5 capture RSS is 82.0 MB with V4L2 Exclusive DRM. The Holoscan 5 YOLO11n path reports 2.45% CPU and 543.4 MB RSS.
GPU Utilization NV3DSink reports 29.89%, NVDRMVideoSink reports 0.00%, and DeepStream fakesink reports 32.12%. Argus reports 34.00% without Exclusive Display and 20.33% with Exclusive Display. V4L2 reports 37.55% without Exclusive Display and 37.41% with Exclusive Display. The YOLO11n path reports 34.38%. Argus reports 28.16% with X11 Display and 8.17% with Exclusive DRM. V4L2 reports 18.95% with X11 Display and 34.23% with Exclusive DRM. The YOLO11n path reports 34.95%.
Display Mode Trade-off NVDRMVideoSink provides lower direct-capture G2G latency than NV3DSink. The DeepStream fakesink measurement does not include display processing. Exclusive Display reduces the measured capture G2G latency for both Argus and V4L2 configurations. Exclusive DRM reduces CPU and RSS for the Holoscan 5 capture configurations. Holoscan 5 Argus improves from 46.40 ms with X11 to 35.05 ms with DRM. Holoscan 5 V4L2 improves from 72.20 ms with X11 to 66.15 ms with DRM.

Framework Selection

These choices use only the configurations and measurements reported above.

Requirement Best Measured Configuration Result
Lowest capture G2G latency Holoscan 5 Argus: Exclusive DRM Display 35.05 ms
Lowest capture process CPU Holoscan 5 Argus: Exclusive DRM Display 0.60%
Lowest capture process RSS Holoscan 5 V4L2: Exclusive DRM Display 82.0 MB
Lowest interlatency Holoscan 5 YOLO11n: V4L2 USERPTR: fakesink 4.832 ± 0.697 ms
Lowest measured inference processing time Holoscan 4.5 YOLO11n: V4L2 USERPTR: fakesink 2.970 ± 0.481 ms
Lowest inference process CPU Holoscan 5 YOLO11n: V4L2 USERPTR: fakesink 2.45%
Lowest inference process RSS Holoscan 5 YOLO11n: V4L2 USERPTR: fakesink 543.4 MB
Lowest inference GPU utilization DeepStream YOLO11n: Argus: fakesink 32.12%

Implemented Applications

These applications produced the measurements. Open an application to see its command, capture path, operators, and output. The Holoscan RidgeRun operators section has the operator details. The --no-local-build flag uses an existing compiled build. Remove it when the application has not been built yet.

Holoscan 4.5

For the Holoscan 4.5 SDK, the display applications use one implementation for both windowed and exclusive-display execution. The display mode is selected at runtime with the --use-exclusive-display CLI argument. In the Holoscan 5 ports, the corresponding configurations use separate applications for exclusive and non-exclusive modes.

  • argus_camera
  • v4l2_imx274
  • yolo_model_deployment

The first two applications support graphical output and exclusive display. yolo_model_deployment is a headless inference application that ends in a fakesink and therefore does not have the --use-exclusive-display argument.

argus_camera

This app captures frames from the camera using libArgus through the Jetson's ISP, outputting NV12 images. It selects the device and sensor-mode and receives the buffers through EGLStream. Then, the image is processed and converted into a BGRA image directly on the GPU to then be displayed by Holoviz. The implemented operators are the following:

You may run the application with this command: 

./holohub run argus_camera_x11 live \
  --local \
  --language cpp \
  --no-local-build \
  --run-args='--camera 1 --sensor-mode 0 --width 1920 --height 1080 --fps 59 --frame-limit 600'

An important limitation to mention is that the desired sensor mode for this camera does not explicitly declare 60 FPS capability, but rather it is declared as 59.99 FPS. That is the reasoning behind the fps argument value in the holohub command.

v4l2_imx274

This application captures raw Bayer images directly from the IMX274 through V4L2, bypassing both libArgus and the Jetson ISP. The camera is configured for RG10 capture and uses V4L2 MMAP buffers.

After dequeuing a frame, the application copies the image from the V4L2 MMAP buffer into a CUDA tensor using cudaMemcpy2D. This copy also removes any row padding introduced by the V4L2 driver. The raw image is then corrected, demosaiced into RGBA16, adjusted with a configurable display gain, and sent to Holoviz. The implemented operators are the following:

The application can be executed with: 

./holohub run v4l2_imx274 \
  --local \
  --language cpp \
  --no-local-build

To use exclusive display, append: 

--fullscreen --use-exclusive-display --display-framerate 144

yolo_model_deployment

This application implements a minimal YOLO11 inference pipeline for Holoscan 4.5. It captures RG10 Bayer frames directly from the IMX274 using V4L2 USERPTR buffers backed by CUDA-mapped pinned memory. The application performs Bayer demosaic, resize, letterbox, gain adjustment, and normalization in a single CUDA kernel. The resulting FP32 tensor is passed directly to the Holoscan inference operator, which executes the YOLO11 TensorRT engine. This application does not perform detection postprocessing, bounding box generation, overlay, or display. The raw inference output is consumed by a fakesink.

The implemented operators are the following:

The application can be executed with: 

export YOLO_MODEL=<yolo-model-path>

./holohub run yolo_model_deployment \
  --local \
  --language python \
  --no-local-build \
  --run-args="--model $YOLO_MODEL --width 1920 --height 1080 --fps 60"

Because the pipeline terminates in a fakesink, this application does not open a display window and does not provide the --use-exclusive-display argument.

Holoscan 5

The Holoscan 5 applications use the typed Graph API. Operators expose typed input and output ports, and the graph is compiled into an ExecutionPlan before execution. Display pipelines are available through two different output paths:

  • X11, for windowed execution through the desktop display server.
  • DRM/KMS, for exclusive display.

The X11 and DRM paths use separate applications and executables. They share the same capture and image-processing operators, but instantiate a different terminal display operator.

The applications described in this section are:

  • yolo11_userptr_inference
  • argus_camera_x11 and argus_camera_drm
  • v4l2_userptr_x11 and v4l2_userptr_drm

All graph connections use bounded queues with a depth of one and QueuePolicy::kDropOldest. This prevents old camera frames from accumulating when a downstream operator cannot keep up with the capture rate.

argus_camera

The Argus camera pipeline captures frames from a camera through libArgus and the Jetson ISP. Argus produces NV12 images through an EGLStream backed by CUDA arrays. The camera operator reads those arrays directly and converts the NV12 image into a BGRA CUDA tensor. That tensor can then be presented through either an X11 window or an exclusive DRM/KMS output.

The two display paths are implemented as separate applications:

  • argus_camera_x11
  • argus_camera_drm

The common capture operator is:

The display endpoint is X11DisplayOp for X11 or DrmBgraDisplayOp for DRM/KMS.

The X11 application can be executed with: 

./holohub run argus_camera_x11 live \
  --local \
  --language cpp \
  --no-local-build \
  --run-args='--sensor-mode 1 --width 1920 --height 1080 --fps 59'

The DRM/KMS application can be executed with: 


./holohub run argus_camera_drm live \
  --local \
  --language cpp \
  --no-local-build \
  --run-args='--sensor-mode 1 --width 1920 --height 1080 --fps 59 --drm-device /dev/dri/card2 --mode 1920x1080'

v4l2_userptr

The V4L2 USERPTR pipeline captures raw RG10 Bayer frames directly from the IMX274. It uses CUDA-mapped pinned buffers as V4L2 USERPTR capture buffers, allowing the CUDA processing operator to access the same memory written by the camera. The raw Bayer frame is corrected and converted into a BGRA tensor on the GPU. The BGRA tensor is then displayed through either X11 or exclusive DRM/KMS.

The two display paths are implemented as separate applications:

  • v4l2_userptr_x11
  • v4l2_userptr_drm

The common operators are:

The display endpoint is X11DisplayOp for X11 or DrmBgraDisplayOp for DRM/KMS.

The X11 application can be executed with: 

./holohub run v4l2_userptr_x11 live \
  --local \
  --language cpp \
  --no-local-build \
  --run-args='--width 1920 --height 1080 --fps 60'

The DRM/KMS application can be executed with: 

./holohub run v4l2_userptr_drm live \
  --local \
  --language cpp \
  --no-local-build \
  --run-args='--width 1920 --height 1080 --fps 60 --drm-device /dev/dri/card2 --mode 1920x1080'

yolo11_userptr_inference

This application implements a minimal headless YOLO11 inference pipeline using the Holoscan 5 typed Graph API. It captures RG10 Bayer frames directly from the IMX274 using V4L2 USERPTR buffers backed by CUDA-mapped pinned memory. The application performs Bayer demosaic, resize, letterbox, gain adjustment, and normalization in a fused CUDA operator. The resulting FP32 tensor is passed to a TensorRT inference operator. The raw inference output is finally consumed by a fakesink. The application does not perform detection postprocessing, bounding-box generation, overlay, image enhancement, or display.

The implemented operators are the following:

The application can be executed with: 

export YOLO_MODEL=<yolo-model-path>

./holohub run yolo11_userptr_inference live \
  --local \
  --language cpp \
  --no-local-build \
  --run-args="--model $YOLO_MODEL --width 1920 --height 1080 --fps 60"

This application is headless and does not have X11 or DRM output variants.


Related concepts and sources


Operators

For operator contracts, see Holoscan RidgeRun Operators. The pipeline and application sections above contain the benchmark commands, topology, and measured results.


Holoscan SDK logo
Holoscan SDK
Back to top ↑

Retrieved from "https://developer.ridgerun.com/wiki/index.php?title=Holoscan_SDK/Benchmark_and_Use_Cases/Holoscan_vs_GStreamer&oldid=91299"
Cookies help us deliver our services. By using our services, you agree to our use of cookies.