Secure Reliable Transport (SRT) Protocol

What is SRT?

Secure Reliable Transport (SRT) is a transport protocol for ultra low (sub-second) latency live video and audio streaming, as well as for generic bulk data transfer¹. SRT is available as an open-source technology with the code on GitHub, a published Internet Draft, and a growing community of SRT users.

SRT is applied to contribution and distribution endpoints as part of a video stream workflow to deliver the best quality and lowest latency video at all times.


Secure	Encrypts video streams
Reliable	Recovers from severe packet loss
Transport	Dynamically adapts to changing network conditions

In live streaming configurations, the SRT protocol maintains a constant end-to-end latency. This allows the live stream's signal characteristics to be recreated on the receiver side, reducing the need for buffering. As packets are streamed from source to destination, SRT detects and adapts to real-time network conditions between the two endpoints. It helps compensate for jitter and bandwidth fluctuations due to congestion over noisy networks.

SRT implements AES encryption to protect the payload of the media streams, and offers various error recovery mechanisms for minimizing the packet loss that is typical of Internet connections, of which Automatic Repeat reQuest (ARQ) is the primary method. With ARQ, when a receiver detects that a packet is missing it sends an alert to the sender requesting retransmission of this missing packet. Forward Error Correction (FEC) and Connection Bonding, which adds seamless stream protection and hitless failover, are also supported by the protocol.

To learn more about the protocol subscribe to the Innovation Labs Blog on

To ask a question join the conversation in the #development channel on

Features

👇 Click on the ► button to expand a feature description.

Pristine Quality and Reliability

No matter how unreliable your network, SRT can recover from severe packet loss and jitter, ensuring the integrity and quality of your video streams.

Low Latency

SRT’s stream error correction is configurable to accommodate a user’s deployment conditions. Leveraging real-time IP communications development to extend traditional network error recovery practices, SRT delivers media with significantly lower latency than TCP/IP, while offering the speed of UDP transmission with greatly improved reliability.

Content Agnostic

Unlike some other streaming protocols that only support specific video and audio formats, SRT is payload agnostic. Because SRT operates at the network transport level, acting as a wrapper around your content, it can transport any type of video format, codec, resolution, or frame rate.

Easy Firewall Traversal with Rendezvous Mode

The handshaking process used by SRT supports outbound connections without the potential risks and dangers of permanent exterior ports being opened in a firewall, thereby maintaining corporate LAN security policies and minimizing the need for IT intervention.

AES Encryption

Using 128/192/256-bit AES encryption trusted by governments and organizations around the world, SRT ensures that valuable content is protected end-to-end from contribution to distribution so that no unauthorized parties can listen.

Forward Error Correction (FEC) and Packet Filter API

SRT 1.4 sees the introduction of the packet filter API. This mechanism allows custom processing to be performed on network packets on the sender side before they are sent, and on the receiver side once received from the network. The API allows users to write their own plugin, thereby extending the SRT protocol's capabilities even further with all kinds of different packet filtering. Users can manipulate the resulting packet filter data in any way, such as for custom encryption, packet inspection, or accessing data before it is sent.

The first plugin created as an example of what can be achieved with the packet filter API is for Forward Error Correction (FEC) which, in certain use cases, can offer slightly lower latency than Automatic Repeat reQuest (ARQ). This plugin allows three different modes:

ARQ only – retransmits lost packets,
FEC only – provides the overhead needed for FEC recovery on the receiver side,
FEC and ARQ – retransmits lost packets that FEC fails to recover.

Connection Bonding

Similar to SMPTE-2022-7 over managed networks, Connection Bonding adds seamless stream protection and hitless failover to the SRT protocol. This technology relies on more than one IP network path to prevent disruption to live video streams in the event of network congestion or outages, maintaining continuity of service.

This is accomplished using the socket groups introduced in SRT v1.5. The general concept of socket groups means having a group that contains multiple sockets, where one operation for sending one data signal is applied to the group. Single sockets inside the group will take over this operation and do what is necessary to deliver the signal to the receiver.

Two modes are supported:

Broadcast - In Broadcast mode, data is sent redundantly over all the member links in a group. If one of the links fails or experiences network jitter and/or packet loss, the missing data will be received over another link in the group. Redundant packets are simply discarded at the receiver side.
Main/Backup - In Main/Backup mode, only one (main) link at a time is used for data transmission while other (backup) connections are on standby to ensure the transmission will continue if the main link fails. The goal of Main/Backup mode is to identify a potential link break before it happens, thus providing a time window within which to seamlessly switch to one of the backup links.

Access Control (Stream ID)

Access Control enables the upstream application to assign a Stream ID to individual SRT streams. By using a unique Stream ID, either automatically generated or customized, the upstream application can send multiple SRT streams to a single IP address and UDP port. The Stream IDs can then be used by a receiver to identify and differentiate between ingest streams, apply user password access methods, and in some cases even apply automation based on the naming of the Stream ID. For example, contribution could be sent to a video production workflow and monitoring to a monitoring service.

For broadcasters, Stream ID is key to replacing RTMP for ingesting video streams, especially HEVC/H.265 content, into cloud service or CDNs that have a single IP socket (address + port) open for incoming video.

Getting Started with SRT


The SRT API	IETF Internet Draft	Sample Apps
Reference documentation for the SRT library API	The SRT Protocol Internet Draft	Instructions for using test apps (`srt-live-transmit`, `srt-file-transmit`, etc.)
SRT Technical Overview	SRT Deployment Guide	SRT CookBook
Early draft technical overview (precursor to the Internet Draft)	A comprehensive overview of the protocol with deployment guidelines	Development notes on the SRT protocol
Innovation Labs Blog	SRTLab YouTube Channel	Slack
The blog on Medium with SRT-related technical articles	Technical YouTube channel with useful videos	Slack channels to get the latest updates and ask questions Join SRT Alliance on Slack

Additional Documentation

Why SRT? - A brief history and rationale for SRT by Marc Cymontkowski.
RTMP vs. SRT: Comparing Latency and Maximum Bandwidth White Paper.
Documentation on GitHub with SRT API documents, features decsriptions, etc.
The SRT Protocol Internet Draft: Datatracker | Latest Version | Latest Working Copy | GitHub Repo

Build Instructions

Requirements

C++03 or above compliant compiler.
CMake 2.8.12 or above as a build system.
OpenSSL 1.1 to enable encryption, otherwise build with -DENABLE_ENCRYPTION=OFF.
Multithreading is provided by either of the following:
- C++11: standard library (std by -DENABLE_STDCXX_SYNC=ON CMake option),
- C++03: Pthreads (for POSIX systems it's built in, for Windows there is a ported library).
Tcl 8.5 is optional and is used by ./configure script. Otherwise, use CMake directly.

Build Options

For detailed descriptions of the build system and options, please read the SRT Build Options document.

Sample Applications and Tools

The current repo provides sample applications and code examples that demonstrate the usage of the SRT library API. Among them are srt-live-transmit, srt-file-transmit, and other applications. The respective documentation can be found here. Note that all samples are provided for instructional purposes, and should not be used in a production environment.

The srt-xtransmit utility is actively used for internal testing and performance evaluation. Among other features it supports dummy payload generation, traffic routings, and connection bonding. Additional details are available in the srt-xtransmit repo itself.

Python tools that might be useful during development are:

srt-stats-plotting - A script designed to plot graphs based on SRT .csv statistics.
lib-tcpdump-processing - A library designed to process .pcap(ng) tcpdump or Wireshark trace files and extract SRT packets of interest for further analysis.
lib-srt-utils - A Python library containing supporting code for running SRT tests based on an experiment configuration.

The term “live streaming” refers to continuous data transmission (MPEG-TS or equivalent) with latency management. Live streaming based on segmentation and transmission of files like in the HTTP Live Streaming (HLS) protocol (as described in RFC8216) is not part of this use case. File transmission in either message or buffer mode should be considered in this case. See Section 7. Best Practices and Configuration Tips for Data Transmission via SRT of the Internet Draft for details. Note that SRT is content agnostic, meaning that any type of data can be transmitted via its payload. ↩

mbakholdina/srt