GStreamer Video Streaming Pipelines

Follow us on:

Share This Page

Facebook Twitter LinkedIn WhatsApp Email Copy Link

Close

Send Email Using

Gmail (Web) Thunderbird (default mail app)

Close

NVIDIA's Yocto Project for Jetson

< >

NVIDIA's
Yocto Project for Jetson

Table of Contents [Sticky]

• Introduction
  • Official NVIDIA Yocto Layers
  • What You Will Learn?
  • Why Choose Yocto?
  • Why NVIDIA Jetson?
• Supported Platforms
• Inside the NVIDIA Yocto Layers
• Quick Setup
• Build and Deployment
  • Building Your First Image
  • Flashing Your Board
  • Jetson Flashing Scripts
• First Boot and Validation
• Setting Up Multimedia Support
  • Examples
    • Video Capture
    • Codecs
    • Video Streaming
• BSP Customization
  • Device Tree Customization
  • Device Tree Overlays
  • Custom Driver Integration
• Known Issues and FAQ
• Contact Us

Video Streaming

This section validates streaming pipelines using the NVIDIA accelerated multimedia stack on Jetson platforms.

To generate a synthetic video stream. This makes the section reproducible on Jetson systems accessed through a local display, serial console, SSH, or headless deployments.

The examples still exercise the NVIDIA accelerated streaming stack end to end, including:

• Hardware accelerated H.264 encoding
• RTP packetization
• RTP transport over UDP
• RTSP session validation
• NVIDIA accelerated decoding
• Buffer conversion through nvvidconv

Before continuing, make sure the multimedia environment described in Software Environment is already available on the target system.

Runtime Requirements

The examples in this section require the multimedia enabled image together with the NVIDIA accelerated plugins used by the Jetson multimedia stack.

The following plugins should already be available:

gst-inspect-1.0 videotestsrc
gst-inspect-1.0 nvvidconv
gst-inspect-1.0 nvv4l2h264enc
gst-inspect-1.0 nvv4l2decoder
gst-inspect-1.0 h264parse
gst-inspect-1.0 rtph264pay
gst-inspect-1.0 rtph264depay
gst-inspect-1.0 rtspsrc

What to expect:

• Each command should print plugin information.
• None of the commands should return:

No such element or plugin

If one or more plugins are missing, the multimedia image is incomplete and the remaining examples should not be used yet.

Streaming Overview

Streaming validation is typically divided into two layers:

• RTP over UDP transport validation
• RTSP session based streaming validation

RTP validates the media transport path itself.

RTSP adds:

• Session management
• Client negotiation
• Stream publication
• Remote consumption support

The media pipelines below use videotestsrc as the input source so that the complete streaming path can be tested without a camera.

RTP Transport Validation

This section validates the raw transport path using RTP over UDP.

The sender pipeline generates synthetic video, encodes it with the NVIDIA hardware accelerated H.264 encoder, packetizes the stream as RTP, and sends it to a receiver over UDP.

RTP Sender

gst-launch-1.0 -e -v videotestsrc is-live=true num-buffers=300 pattern=smpte \
  ! video/x-raw,width=1280,height=720,framerate=30/1,format=I420 \
  ! nvvidconv ! 'video/x-raw(memory:NVMM),format=NV12' \
  ! queue \
  ! nvv4l2h264enc maxperf-enable=1 bitrate=4000000 iframeinterval=30 insert-sps-pps=true \
  ! h264parse config-interval=-1 \
  ! rtph264pay config-interval=1 pt=96 \
  ! udpsink host=<receiver-ip> port=5000 sync=false async=false

What to expect:

• The pipeline should move from PAUSED to PLAYING.
• The encoder should initialize correctly.
• The sender should emit RTP packets continuously until the 300 buffers are processed.
• The terminal should end with:

Got EOS

RTP Receiver on Jetson

Use this receiver when the client system is another Jetson platform.

gst-launch-1.0 -e -v udpsrc port=5000 \
  caps="application/x-rtp, media=video, encoding-name=H264, payload=96" \
  ! rtph264depay ! h264parse ! nvv4l2decoder \
  ! queue ! fakesink

What to expect:

• The receiver should connect and start consuming RTP packets.
• The H.264 depayloader should negotiate correctly.
• The NVIDIA decoder should initialize correctly.
• The pipeline should remain stable until the sender finishes.

For graphical playback on Jetson, replace the final branch with:

! nvegltransform ! nveglglessink sync=0

RTP Receiver on x86 Host

If you are validating from a non-Jetson host, use software decode instead of nvv4l2decoder:

gst-launch-1.0 -e -v udpsrc port=5000 \
  caps="application/x-rtp, media=video, encoding-name=H264, payload=96" \
  ! rtph264depay ! h264parse ! avdec_h264 \
  ! videoconvert ! fakesink

What to expect:

• The RTP stream should decode successfully on the host.
• If avdec_h264 is missing, install the GStreamer libav plugin set on the host.
• This is useful when the receiver is not a Jetson device.

RTSP Session Validation

This section validates RTSP session setup together with the same synthetic media pipeline.

The RTSP media chain still uses the NVIDIA accelerated encoder, but the actual RTSP server is provided by a helper application such as test-launch or another RTSP server implementation.

If your image does not include an RTSP server helper, use the RTP transport validation section first.

RTSP Media Pipeline

This is the media branch that a server exposes to RTSP clients:

videotestsrc is-live=true pattern=smpte \
  ! video/x-raw,width=1280,height=720,framerate=30/1,format=I420 \
  ! nvvidconv ! 'video/x-raw(memory:NVMM),format=NV12' \
  ! nvv4l2h264enc maxperf-enable=1 bitrate=4000000 iframeinterval=30 insert-sps-pps=true \
  ! h264parse config-interval=1 \
  ! rtph264pay name=pay0 pt=96

What to expect:

• The encoder should negotiate correctly.
• RTP packets should begin flowing once the RTSP server starts.
• The RTSP server should remain active while clients connect.

RTSP Client Validation

Use a second system or a second terminal session to validate the RTSP stream:

gst-launch-1.0 -e -v rtspsrc location=rtsp://<server-ip>:8554/test protocols=tcp latency=0 \
  ! rtph264depay ! h264parse ! nvv4l2decoder \
  ! queue ! fakesink

What to expect:

• The client should connect successfully.
• The RTSP session should negotiate without errors.
• RTP packets should begin arriving immediately after the PLAY request.
• The decoder should initialize correctly.

For graphical playback on Jetson:

gst-launch-1.0 -e -v rtspsrc location=rtsp://<server-ip>:8554/test protocols=tcp latency=0 \
  ! rtph264depay ! h264parse ! nvv4l2decoder \
  ! nvegltransform ! nveglglessink sync=0

If the receiver is an x86 host, replace nvv4l2decoder with avdec_h264.

Common Streaming Issues

Client Cannot Connect

Typical causes include:

• Incorrect RTSP URL
• RTSP server not running
• Firewall restrictions
• Incorrect network configuration

Receiver Decoder Missing

If the receiver is a non-Jetson host, nvv4l2decoder will not exist.

Use:

avdec_h264

instead.

No Video Output

If graphical playback fails:

• Verify that a local X11 or Wayland session is running
• Confirm display initialization
• Use fakesink for headless validation

No RTSP Server Helper

If test-launch or another RTSP server helper is not installed, RTSP client validation cannot start by itself.

In that case:

• Validate the media chain with RTP transport first
• Add an RTSP server helper to the image if RTSP testing is required

Negotiation Failures

Verify the relevant plugins:

gst-inspect-1.0 nvv4l2h264enc
gst-inspect-1.0 rtph264pay
gst-inspect-1.0 rtph264depay
gst-inspect-1.0 rtspsrc
gst-inspect-1.0 nvv4l2decoder

Additional Resources

• Software Environment
• Codecs
• GStreamer rtspsrc Documentation
• GStreamer RTSP Server Documentation
• NVIDIA Accelerated GStreamer Documentation
• Need support for custom multimedia protocols or streaming integrations? RidgeRun Multimedia Services for embedded platforms.

NVIDIA's Yocto Project for Jetson

Back to top ↑ < >