RidgeRun Metadata/RidgeRun Metadata Catalog/SRT
 | The RidgeRun Metadata documentation from RidgeRun is presently being developed. |
Definition
Secure Reliable Transport (SRT) is an open-source video transport protocol developed by Haivision. It is designed to deliver high-quality, low-latency streaming over unreliable networks by handling jitter, packet loss, and fluctuating bandwidth without compromising video integrity. Unlike legacy protocols such as RTMP (TCP-based), SRT leverages UDP for transport, enabling faster delivery with real-time adaptation to network conditions.
While SRT does not define its own media format, it acts as a transport layer for encapsulated containers. Metadata is not handled natively by SRT itself — instead, it must be embedded inside a media container (e.g., MPEG-TS, MKV, or FLV) that travels over the SRT connection. Applications are responsible for injecting and extracting metadata before/after transport, while SRT ensures reliable delivery of the entire payload.
Supported Protocols and Containers
Since SRT only transports binary payloads, metadata is carried within the encapsulated media container, not by the protocol itself. Common containers and metadata mechanisms include:
- MPEG-TS – supports ID3 tags (titles, artist info, etc.) and SCTE-35 markers (ad insertion, signaling events).
- Matroska (MKV) – supports extensible metadata blocks, commonly used for structured or custom metadata.
- FLV (less common with SRT) – allows metadata through AMF messages if paired with FLV encapsulation.
Typical tools to insert/extract metadata include:
- GStreamer (
taginject,mpegtsmux,srtsink) - FFmpeg (
-metadataoption, ID3 insertion) - Wowza/Nimble Streamer (server-side injection and parsing)
- OBS Studio (supports SRT transport, limited metadata features)
Benefits and Limitations
Benefits
- Low latency: typically ~150 ms end-to-end, ideal for live sports, news, and interactive applications.
- Error resilience: built-in error correction recovers lost packets, maintaining quality even on poor networks.
- Security: supports end-to-end AES-256 encryption with authentication.
- Interoperability: works across most encoders, decoders, CDNs, and media servers.
- Open source: free to use, supported by an active community.
- Flexible metadata transport: can carry standard (ID3, SCTE-35) or custom metadata embedded in containers.
Limitations
- No native metadata support: SRT only transports binary streams; metadata must be wrapped in the container.
- Extra pipeline complexity: requires muxers/demuxers (e.g., MPEG-TS) to carry metadata.
- Error correction overhead: while it improves reliability, FEC can introduce slight additional latency.
- Server compatibility: requires SRT-enabled servers/players, less ubiquitous than HLS/DASH.
Examples
All the examples shown use the receiver IP as the same machine (localhost).
If the receiver runs on a different machine, you must replace the IP address with the actual receiver’s IP address.
1. Low-latency contribution (point-to-point streaming)
Transmit a live camera feed from one site to another with minimal delay.
Sender
gst-launch-1.0 v4l2src ! videoconvert ! x264enc tune=zerolatency bitrate=2000 speed-preset=superfast ! \
mpegtsmux ! srtsink uri="srt://127.0.0.1:9000?mode=caller"
Receiver
gst-launch-1.0 srtserversrc uri="srt://:9000?mode=listener" ! tsdemux ! h264parse ! avdec_h264 ! autovideosink
Advantage: End-to-end latency below 200 ms, robust even on unstable networks. Ideal for remote interviews, live sports, or concerts.
2. Secure transmission with encryption
SRT supports AES-128/192/256 encryption to protect sensitive video feeds.
Sender
gst-launch-1.0 videotestsrc is-live=true ! x264enc bitrate=1500 ! mpegtsmux ! \
srtsink uri="srt://127.0.0.1:9001?mode=caller&pbkeylen=16&passphrase=RidgeRun2025"
Receiver
gst-launch-1.0 srtserversrc uri="srt://:9001?mode=listener&pbkeylen=16&passphrase=RidgeRun2025" ! \
tsdemux ! h264parse ! avdec_h264 ! autovideosink
Advantage: Perfect for private events, enterprise broadcasting, and government/security applications.
Parameters
- mode= Defines the role of this side of the connection:
- caller: initiates the connection (like a TCP client).
- listener: waits for connections (like a TCP server).
- rendezvous: both sides try to connect (useful behind NAT).
- pbkeylen= Key length in bytes for AES encryption:
- 16 → AES-128
- 24 → AES-192
- 32 → AES-256
passphrase=RidgeRun2025
- This is the shared password used to generate the encryption key. It must be identical on both the sender and the receiver; otherwise, they won’t be able to decrypt the stream.
3. Metadata transport in MPEG-TS over SRT
Send video + telemetry together. Metadata is injected into the TS container and carried transparently by SRT.
Sender
gst-launch-1.0 videotestsrc is-live=true ! x264enc ! \
taginject tags="location=CostaRica,unit=Drone01" ! \
mpegtsmux name=mux ! srtsink uri="srt://127.0.0.1:9002?mode=caller" \
audiotestsrc is-live=true ! voaacenc ! mux.
Receiver
gst-launch-1.0 srtserversrc uri="srt://:9002?mode=listener" ! tsdemux name=demux \
demux. ! h264parse ! avdec_h264 ! autovideosink \
demux. ! fakesink silent=false
Advantage: Useful for drones, remote monitoring, and mission-critical telemetry where metadata (GPS, sensor values) must remain frame-synchronized with video.
4. Multi-destination streaming (one-to-many distribution)
A single sender feeds multiple receivers, each establishing an SRT session.
Sender (one stream, multiple listeners connect independently)
gst-launch-1.0 videotestsrc is-live=true ! x264enc ! mpegtsmux ! srtsink uri="srt://0.0.0.0:9004?mode=listener"
Receiver (each one runs separately):
gst-launch-1.0 srtclientsrc uri="srt://sender-ip:9004" ! tsdemux ! h264parse ! avdec_h264 ! autovideosink
Advantage: Efficient for live event broadcasting, where many endpoints consume the same stream reliably.