About SRT | Features | Getting Started | Build Instructions | Sample Apps and Tools | Contribute | License | Releases
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 transfer1. 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 
👇 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.
| 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 |
- 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
Linux (Ubuntu/CentOS) | Windows | macOS | iOS | Android | Package Managers
- 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 (
stdby-DENABLE_STDCXX_SYNC=ONCMake option), - C++03: Pthreads (for POSIX systems it's built in, for Windows there is a ported library).
- C++11: standard library (
- Tcl 8.5 is optional and is used by
./configurescript. Otherwise, use CMake directly.
For detailed descriptions of the build system and options, please read the SRT Build Options document.
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.csvstatistics.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.
Anyone is welcome to contribute. If you decide to get involved, please take a moment to review the guidelines:
For information on contributing to the Internet Draft or to submit issues please go to the following repo. The repo for contributing in SRT CookBook can be found here.
By contributing code to the SRT project, you agree to license your contribution under the MPLv2.0 License.
Footnotes
-
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. ↩