Benefits of SRT for your stream explained

With the growing demand for live video streaming, CDN77's stack keeps evolving as well. After some initial testing, we are happy to announce that we now support the SRT ingress feed. Why should you care about this new feature?

Motivation

Since its introduction in 2005, RTMP has become a de facto standard for live streaming. Even today, it's supported by most platforms. Its role, however, has changed throughout the years and has become mostly transit protocol.

The list of cons regarding RTMP is pretty extensive. To name a few:

• The need to keep an active TCP connection means it scales poorly with an increasing number of client devices.
• Security issues have been somewhat addressed by RTMPS and RTMPE and problems with traversing tighter firewalls by RTMPT, but those are all workarounds that point out the need for a better solution.
• RTMP only allows for the H.264 video codec. While it's still actively developed and reasonably keeps up with current needs, with RTMP, you don't really have an option even to try anything else. Similarly, you are stuck with AAC.
• Latency with RTMP can range anywhere between 1-30s, with typical values around 5s.
• Due to low bandwidth or high RTTs, the stream may not even start at all.

What is SRT?

SRT stands for Secure Reliable Transport. The protocol itself has its roots in the UDT project and uses similar, more refined methods for connection, sequence numbers, acknowledgments, and re-transmission of lost packets.

According to the SRT Alliance website:

SRT is an open-source video transport protocol and technology stack that optimizes streaming performance across unpredictable networks with secure streams and easy firewall traversal, bringing the best quality live video over the worst networks. The SRT Open Source project, driven by the SRT Alliance, is a collaborative community of industry leaders and developers striving to achieve lower latency internet video transport by continuously improving open-source SRT.

In many ways, SRT is a game-changer since it addresses many problems everybody has. Let's break down what it actually solves.

Reliability

This is possibly the greatest selling point of all. SRT is designed to recover from a severe packet loss and adapt to an unstable network.

Generally speaking, packet recovery through TCP imposes a significant bandwidth overhead. SRT uses optimized re-transmission mechanisms to do so very efficiently at the application layer while utilizing UDP for transport. 

Source: https://github.com/Haivision/srt/blob/master/docs/why-srt-was-created.md

As you can see above, signal characteristics change due to network conditions such as packet loss, jitter, and so on, giving video decoders a hard time. SRT comes with an in-built reconstruction mechanism that recreates the signal characteristics on the receiver side. Normally this would be solved by buffering, but that would also increase latency.

Low latency

The low latency of SRT is tightly related to the previous point. UDP transmission is unreliable by default, but overall a much faster, simpler and more efficient protocol than TCP.

Since the unreliability problem has mostly been overcome, latency has hit a new low. It allowed for a reduced buffer size to reduce latency even further. This allows SRT to deliver the stream at consistent sub-second latencies!

In practice, most of the glass-to-glass latency arises from HLS/DASH packaging. But, even when used only as a "first-mile" protocol, SRT can cut a few seconds from overall latency.

Codec agnostic

With SRT, the payload doesn't matter. You are free to use newer formats such as H.265, VP9, or AV1 since SRT is purely a transport protocol.

As for container formats, MPEG-TS is currently the most common format sent using SRT.

Security

As mentioned above, RTMP is a bit lacking when it comes to security. SRT, on the other hand, comes with built-in end-to-end encryption. It uses a standard cryptographic algorithm (256-bit AES), but the whole encryption mechanism is unique to SRT.

Not to get too technical, it uses two sets of keys, a short-lived Stream Encrypting Key (SEK) to encrypt the media stream, which is encapsulated in a Key Encrypting Key (KEK). For connection-oriented transport such as SRT, there is no need to periodically transmit the SEK since no party can join the stream at any time.

To sum up

Here's a tl;dr summary of RTMP vs. SRT .

If you happened to stumble upon our article and are looking for a video delivery solution, you can find more information about our video-friendly CDN here.

Our clients are already making use of SRT. So far, the most used setup is with FFmpeg and OBS Studio encoders in a caller mode (push). If you would like to try to set up SRT for your stream, don't hesitate to get in touch with our support.