Examples - Sample Pipelines
Sample Pipelines
This page provides sample GStreamer pipelines for processing Bayer RAW images with RidgeRun's PVA ISP.
Unlike the Sample Applications, which demonstrate how to integrate the PVA ISP through its C++ API, this page focuses on using the PVA ISP as part of a GStreamer pipeline.
The examples cover:
- Capturing Bayer RAW images with different bit depths
- Using zero-copy capture with V4L2 USERPTR buffers
- Processing Bayer RAW images from files
- Capturing with V4L2 MMAP buffers and transferring them to PVA-compatible memory
Prerequisites
Before running the pipelines on this page, verify that the following GStreamer elements are available:
gst-inspect-1.0 rrv4l2src gst-inspect-1.0 pvaisp gst-inspect-1.0 pvacudaupload
Each command should display the corresponding element information without reporting plugin loading errors. The purpose of each of this elements is describe bellow:
rrv4l2src:- This element is not part of the PVA ISP itself. It is an extended version of the standard GStreamer
v4l2srcelement used to capture frames directly from a V4L2 camera and provide them in a memory layout that can be consumed by the ISP.
- This element is not part of the PVA ISP itself. It is an extended version of the standard GStreamer
pvacudaupload:- This element is an auxiliary memory-transfer element used when an upstream element cannot write directly into the buffer pool provided by
pvaisp. It copies data from system memory into PVA-compatible CUDA memory so that the ISP can process it. This is required in cases such as processing input from a file or using standard capture paths that do not support the ISP buffer pool directly.
- This element is an auxiliary memory-transfer element used when an upstream element cannot write directly into the buffer pool provided by
pvaisp:- This element performs the actual image processing on the PVA. It contains the ISP pipeline, executes the configured processing stages, and produces the selected output format.
Configuring the PVA ISP Element
The PVA ISP is exposed in GStreamer through the pvaisp element.
The ISP configuration can be provided in two ways:
- Through individual GStreamer element properties
- Through a YAML parameter file
YAML Configuration
Using a YAML configuration file is recommended for most applications because it keeps the complete ISP configuration in a single reproducible file.
pvaisp params=/path/to/parameters.yaml
The same parameter file can be reused across applications, test pipelines, and deployments.
Overriding Properties
Individual ISP settings can also be provided or overwritten through GStreamer properties.
pvaisp params=/path/to/parameters.yaml \
auto-exposure-reference-mean=50
This allows applications to use a common YAML configuration while modifying specific settings directly from the pipeline.
Check the full list of available properties with gst-inspect-1.0 pvaisp
Sample Pipelines
The following sections demonstrate common methods for delivering Bayer RAW buffers to the PVA ISP.
Replace the placeholder values with the camera format, resolution, frame rate, and parameter file appropriate for the target system.
Once processed by pvaisp, the output can use standard GStreamer elements for display, recording, encoding, streaming, and other multimedia workflows.
Processing Bayer RAW Data from a File
The PVA ISP can process Bayer RAW frames stored in a file by using filesrc.
gst-launch-1.0 filesrc location=capture.raw num-buffers=1 blocksize=4147200 ! \
'video/x-bayer, format=rggb, bpp=12, width=1920, height=1080, framerate=30/1' ! \
pvacudaupload ! pvaisp params=params-reference.yaml ! filesink location=capture.nv12
The input file must contain Bayer RAW data matching the resolution, Bayer pattern, bit depth, and memory layout declared by the pipeline. The pvacudaupload element transfers the raw buffers loaded from filesrc into compatible memory before ISP processing.
Important: The blocksize property is required to read the full frame and it must match the frame size, to process multiple frames extend the num-buffers property.
Zero-Copy Capture with USERPTR
The following pipeline uses V4L2 USERPTR buffers to avoid an additional copy between camera capture and ISP processing.
gst-launch-1.0 rrv4l2src device=/dev/video0 io-mode=userptr num-buffers=1 ! \
'video/x-bayer, format=rggb, bpp=12, width=1920, height=1080, framerate=30/1' ! \
pvaisp params=params-reference.yaml ! filesink location=/tmp/capture.nv12
Capturing with MMAP and pvacudaupload
Standard V4L2 MMAP buffers are not directly allocated in the memory required by the PVA ISP.
The pvacudaupload element transfers the captured buffers into compatible memory before ISP processing.
gst-launch-1.0 rrv4l2src device=/dev/video0 io-mode=mmap num-buffers=1 ! \
'video/x-bayer, format=rggb, bpp=12, width=1920, height=1080, framerate=30/1' ! \
pvacudaupload ! pvaisp params=params-reference.yaml ! filesink location=/tmp/capture.nv12
This method provides compatibility with conventional V4L2 capture but introduces an additional memory transfer compared with the USERPTR zero-copy pipeline.
Video Encoding Pipeline
The NV12 output generated by PVA ISP can be sent directly to NVIDIA hardware encoders.
gst-launch-1.0 rrv4l2src device=/dev/video0 io-mode=userptr ! \
'video/x-bayer, format=rggb, bpp=12, width=1920, height=1080, framerate=30/1' ! \
pvaisp params=params-reference.yaml ! nvvidconv ! nvv4l2h264enc ! \
h264parse ! mp4mux ! filesink location=recording.mp4
Display Pipeline
gst-launch-1.0 rrv4l2src device=/dev/video0 io-mode=userptr ! \
'video/x-bayer, format=rggb, bpp=12, width=1920, height=1080, framerate=30/1' ! \
pvaisp params=params-reference.yaml ! nvvidconv ! autovideosink
Streaming Pipeline
gst-launch-1.0 rrv4l2src device=/dev/video0 io-mode=userptr ! \
'video/x-bayer, format=rggb, bpp=12, width=1920, height=1080, framerate=30/1' ! \
pvaisp params=params-reference.yaml ! nvvidconv ! nvv4l2h264enc ! \
h264parse ! rtph264pay pt=96 ! udpsink host=192.168.1.100 port=5000
Troubleshooting
Verify that:
- The selected
rrv4l2srcbranch matches the Bayer bit depth - The resolution matches a format exposed by the camera driver
- The Bayer caps match the camera output
- The selected V4L2 I/O mode is supported by the driver
- The expected buffer size matches the format reported by V4L2
List the camera formats with:
v4l2-ctl --device=/dev/video0 --list-formats-ext
Validate capture alone with pipelines like the following;
10-bit Bayer Input
gst-launch-1.0 rrv4l2src device=/dev/video0 io-mode=mmap ! 'video/x bayer, format=bggr, bpp=10, width=3840, height=2160, framerate=30/1' ! fakesink silent=false -v
12-bit Bayer Input
gst-launch-1.0 rrv4l2src device=/dev/video0 io-mode=mmap ! 'video/x bayer, format=rggb, bpp=12, width=1920, height=1080, framerate=30/1' ! fakesink silent=false -v
