Back at the end of 2020 while the pandemic was still at its peak, I delivered an online talk at the Mile High Video conference (now ACM MMSys) titled "Traversing the first mile is harder than traversing the last mile".
In this talk I discussed how the world was experiencing a boom in live video driven by COVID, and how while we have lots of tools for increasing the reliability of the video we were delivering, we didn't have great options for increasing the reliability of the source video that was being sent to us - the "first mile". During the pandemic, the "first mile" and "last mile" internet connections were rapidly becoming the same networks.
While the explosive growth in live streaming we saw in the first year of the pandemic has slowed back to pre-pandemic levels, some things were changed permanently during the COVID. Live streaming is more accessible than ever, and the live content you're consuming is more and more often generated by other users - your gym instructor, your professor, or even your barista are all live content creators, and they've all got one thing in common: They create that live content on unreliable networks.
Sometimes that unreliability is easy to diagnose, like the flat I once lived in with a cheap WiFi router sat neatly on top of a microwave in the kitchen. Sometimes they are more subtle, like strangely configured corporate networks that hate long-running TCP connections. A customer recently recalled to me a story where their live stream kept dropping every time the streamer walked away from the encoder, and recovered every time they walked back towards it. The encoder was, of course, using the streamer's mobile hotspot, and their phone was in their pocket.
There were a couple of emerging protocols back in late 2020, including SRT and RIST, which are both open source and designed with the intention to make live ingest more reliable. Frustratingly, however, none of them were a great fit for Mux, where we run a massively multi-tenanted environment, with a single entry point. At the time, they both lacked simple stream routing features like the Stream Key on an RTMP stream. Thankfully the world of reliable ingest protocols has moved forward in the last couple of years. SRT is the clear leader in terms of support in the video encoders we see customers using, as well as now having a great multiplexing and security story through the wide adoption of the stream_id field, which was introduced just around the time I was writing my talk.
So with all the stars aligned, we built it. And we’re excited to announce that Mux Video’s support for SRT is in GA.
What's SRT again?
Secure Reliable Transport (SRT) is a modern, reliable open source contribution protocol developed by Haivision. It allows more reliable transmission of video over less reliable networks when compared to protocols like RTMP.
SRT works differently from RTMP at the core. SRT is a UDP-based protocol (so no more worries about dropped TCP connections). It instead relies on protocol-level acknowledgment to handle data loss or re-ordering. SRT implements this reliability by keeping a buffer of frames on each end of the connection to allow time for the protocol to compensate for lost or delayed data. Depending on how you use it, this can mean that SRT has higher point-to-point latencies than RTMP generally has today, however, SRT allows you to configure this buffer to make sure you're making the right tradeoffs of latency and increased reliability for your use case.
If you want to learn more about ingest protocols, my wonderful colleague Bobby just posted a great blog post that gets right into the technical weeds of several ingest protocols, you should check it out!
(And no, Secure Reliable Transport isn't related to the SubRip Text format, but we support that too!)
So when should I be using SRT?
We keep saying that SRT is great when you're live streaming from an unreliable network, but what does that actually mean? There are three main key factors that can make a network connection unreliable for live streaming.
First is the most well-understood factor — Insufficient bandwidth. You need to have enough upload bandwidth (Mbps) to get your stream off your local network, and out to the internet. We generally recommend having at least twice as much outbound bandwidth as the bitrate you have your encoder configured at. For example, if you're sending a stream at 5Mbps, you should be able to handle at least 10 Mbps sustained upload speeds. With SRT you can also configure the burstable bandwidth on the encoder, which lets you configure how much bandwidth to use when recovering from connectivity issues.
Second, inconsistent latency. While obviously, you want the latency of your network and internet connection to be as low as possible (the time it takes for data to reach Mux), it's actually much more important that the latency of your connection is consistent — the variability of your network connection is referred to as jitter.
High packet loss is the third important area. This one is pretty easy – it’s the proportion of the packets that you send that actually reach their destination. When we say high here, anything above 1% would be classified as too much. 1% may not sound like a lot, but when you take into account that any packets lost have to be scheduled for retransmission, and then be retransmitted, (which may consequently also then be lost), a low packet loss % can heavily impact live stream stability.
As a general rule of thumb, unless you have a dedicated physical link for your video encoder, you should probably consider your connection to be "unreliable". That includes not only the WiFi networks we use every day but also any form of 4G or 5G cellular networks.
SRT is designed to handle these less-than-perfectly-reliable networks by using the buffer on each end of the connection to allow time to compensate for variability in available bandwidth, jitter, and packet loss. Realistically, If you've got an encoder that supports SRT, then you probably should be using SRT. There aren't really any meaningful downsides and the reliability improvements can be substantial.
Let's take a look at a quick demo of SRT and RTMP dealing with significant packet loss on an unreliable network.
Now that we have SRT support, we also took the opportunity to add support for live streams being sent over HEVC. HEVC (or H.265) is a modern video codec, which has better compression performance in comparison to H.264, which is the only codec we support over RTMP. Using HEVC to send a stream over SRT allows you to reduce the bitrate of the stream that you send to Mux, or to increase the visual quality without increasing the bitrate, all enabling a better experience for your viewers. SRT over HEVC isn't supported in every encoder, but if your encoder supports it, like OBS, you should give it a try.
Of course, no protocol will ever magically solve all the connectivity issues you'll encounter in the real world - someone will always trip over that network cable. That's why we have features like reconnect windows and slates, which can be used to minimize the impact of interruptions to your end viewers,
Sold! So how do I use it?
Using SRT is just as easy as using RTMP - you just need to configure your encoder with the correct SRT Stream ID (this is actually the stream key you use for RTMP), and the SRT Passphrase. We've got a full guide to using SRT in our documentation, including configuration guides for OBS, Videon, Larix Broadcaster, FFmpeg, and Gstreamer - check it out to get started. SRT is available for every existing live stream on Mux and can be used for no extra cost. You don't have to use SRT for every stream either - you can slowly roll it out, using RTMP for some streams, and SRT for others to make sure it works well for you. As always we'd love to hear your feedback, drop us a line if you get stuck, or need help getting your encoder up and running with SRT.
So what are you waiting for? Stream more reliably with SRT today.
