Secure Reliable Transport (SRT) has been gaining recruits almost on a weekly basis as conviction grows that it represents the best way of streaming live video over the internet reliably with the lowest possible latency. The SRT Alliance promoting the protocol now has over 200 members having just celebrated its second birthday, including big – if not the very biggest – names in Microsoft, Harmonic, Mediakind, Synamedia and Kudelski, alongside the two founders Haivision and Wowza. It has some way still to go attracting the greatest technology companies and establishing itself across the video ecosystem rather than just for contribution or the “first mile” where it has won most traction so far.
SRT has brought a radically different approach to low latency streaming than existing methods operating over the various ABR (Adaptive Bit Rate) options, especially HTTP Live Streaming (HLS) developed by Apple and MPEG-DASH. This itself is attracting resistance at the distribution level from existing players, even though SRT will work with any ABR format. However, it is building successfully on proprietary predecessors in the first mile, notably Google’s Quick UDP Internet Connections (QUIC), which was approved in October 2018 by the IETF as its “HTTP/3” in anticipation of becoming a global streaming standard. QUIC then can be construed as an alternative to SRT as well as one or two other protocols like WebRTC.
The first point to consider though is that protocols such as SRT operate at the network transport level, not the application level. They therefore provide secure transport and as low latency as possible only between transport stacks within an IP network, and it is then up to the application to ensure security, reliability and low latency all the way to the viewer or from the source to the network ingest. This comes down to software developers and SRT is popular with them partly because it is open source with no royalties to pay.
The second point is that ever since live video streaming began in earnest around 2015, the goal has been to combine the reliability of the connection-oriented TCP transport protocol, with its built-in retransmission of lost or corrupted IP packets, with the broadcast qualities and lower latency of the connectionless UDP protocol. Connection-oriented transmission involves establishment of a dedicated path between source and destination stacks for the duration of a session while connectionless protocols fire packets out with no determination of their destination, being therefore suitable for broadcast and multicast where the end points are unknown at that time anyway.
Both TCP and UDP have been widely used for video streaming services with TCP favoured for on demand content where latency is less of an issue. TCP has been preferred because it not only corrects errors but also reorders packets so that they arrive in the correct sequence for assembly and playout.
QUIC and then SRT were designed to overcome the packet-loss and sequencing issues of UDP while eliminating those buffering delays directly attributable to TCP. SRT then goes further by addressing delays associated with ABR protocols such as HLS and DASH transmitted over HTTP. Before QUIC and SRT came along, broadcasters for example could only overcome these problems by using high-cost reserved links typically employing MPLS (Multi-Protocol Label Swapping) over the internet, or satellite networks, providing dedicated links in either case.
The other goal for SRT was to support end to end encryption using AES, along with mechanisms to simplify traversal through firewalls, aiming to facilitate operation over almost any network. The main aim though was to square that circle between latency and quality as effectively as possible.
QUIC and SRT built on earlier protocols such as UDP-Based Protocol (UDT), a connection-oriented version of UDP for large data sets with origins dating back to 2001. There were also some protocols optimized for interactive real time applications with generally lower volumes of data, notably Voice over IP, such as Adobe’s Real-Time Messaging Protocol (RTMP). These were either too slow or failed to address high quality video, or were not properly compatible with ABR, which is why they have been superseded.
Much of the groundwork for SRT was laid in QUIC, with algorithms that encapsulate streams in HTTP such that they can be output as multiple ABR streams at the receiving end. This enables QUIC to employ a variety of techniques during transmission that are quite independent of ABR, such as pacing of packets such as to minimize congestion. Another trick is to proactively retransmit the most important packets relating to error correction or initiation of encryption for example, without waiting for requests.
QUIC also cuts latency by reducing the number of roundtrips required to set up a connection and generally consolidating the various steps involved in the initial handshake and encryption setup into a single process. SRT runs with these techniques and enhances some of them further while adding some tweaks of its own. For example, it handles packet loss not just by low-latency retransmission techniques as in QUIC but also being prepared to drop less critical packets when congestion is high. Then rather than relying on HTTP or ABR to perform the actual alteration of bit rates at the sources and destinations it analyzes network conditions in real time and tries to minimize impact of jitter, noise and congestion along the full transmission path.
It is important not to get too bogged down in these niceties and remember the critical point that, whether we are talking about SRT, QUIC or some other new low latency streaming protocol, some form of enhanced UDP will depose TCP as the mechanism of choice for streaming latency-sensitive live or linear video content over the next few years. Observers of the IP scene will see that this brings the evolution of video streaming full circle back in a sense to where it began. After all the Real Time Streaming Protocol developed by Real Networks was the first to be widely deployed and that was UDP-based, as were the HTTP-based streaming modes that followed. TCP then ousted UDP in both environments and became the dominant streaming transport foundation for HTTP-based ABR because of its robustness. Finally, the growth of live streaming then tilted the dial back to UDP, but this time with more attention to error correction, aiming to have the best of both worlds.
Meanwhile, various proprietary approaches have come along with claims to have solved the latency problem when all they have really done is synchronise streaming more closely with broadcast. In some cases that has been achieved by slowing down the broadcast signal rather than bearing down on streaming latency, so that is hardly a solution. Now SRT at least offers to level the field and enable streaming latency to converge with broadcast as closely as possible.
In this regard, an important step just being taken by the SRT Alliance given the ambition to cover the whole video path from creation to consumption is to enable efficient routing of streams within the cloud. Inevitably given its membership, this has meant collaborating with Microsoft Azure rather than other major cloud providers like Amazon, through its emerging platform called SRTHub. The initial focus is again on the first mile to ensure that first hop to the cloud is always as short as possible, irrespective of traffic conditions. The SRT Alliance has promised significant announcements relating to SRTHub at IBC 2019 in September.