Some clarity is emerging from the fog of overlapping bodies and different protocols, with the Streaming Video Alliance (SVA) setting the agenda for the OTT ecosystem as a whole. The SVA can be compared to the Ultra HD Forum and its close sibling the UHD Alliance for UHD services in so far that it does not set standards itself, instead aiming to influence the course of their development through established bodies in the TV and online worlds, such as the DVB and Consumer Technology Association (CTA). The SVA has risen to a dominant role spanning the whole streaming ecosystem by attracting a very strong and representative membership, with Amazon Web Services among the latest recruits in November 2017. Like similar alliances in other sectors the SVA has split its activities into working groups, of which there are currently six: Advertising, Open Caching, Privacy and Protection, Measurement/Quality of Experience (QoE), Scaling and significantly because it acknowledges the rise of mobile, Geographical to support location based services.

One omission from the SVA’s list of working groups so far is surprisingly the streaming protocol itself. However, that is being addressed by the Secure Reliable Transport (SRT) Alliance, whose membership has grown rapidly in recognition that robust video streaming optimizing quality against latency is too important to be left to proprietary technologies as it has been so far, even if these alternatives support standard mechanisms such as the adaptive bitrate streaming technique MPEG DASH. New York based OTT platform developer Kaltura is the latest to join, but the list now includes many of the major players, with prominent members including Harmonic, CDN (Content Delivery Network) provider Limelight and cloud video specialist Brightcove. The SRT Alliance was formed in April 2017 by Haivision, the architect of the protocol itself, and streaming software provider Wowza Media Systems.

This surge in membership reflects fast growing consensus that the SRT protocol represents the most efficient and robust standards technology likely to unify low latency communications. But it is not purely about technology, for the cause is being aided by the decline in popularity of RTMP (Real Time Messaging Protocol), which was initially designed by Macromedia to build on the Internet TCP protocol. Macromedia was taken over by Adobe, which then introduced a version of RTMP for its Flash player, gaining wide adoption for play back of online video content.

Although it is possible to achieve reasonably low latency and high-quality streaming with Flash the industry tide is now flowing against it as the major players in different relevant sectors including providers of browsers and CDNs discourage its use. Google now stops loading of Flash content unless users intervene, while Akamai and Amazon have been encouraging customers to move to later HTTP-based streaming protocols, rather than those based on RTMP. Comcast has stated that it sees little requirement now for RTMP except for live mezzanine streams which are then transcoded into HTTP-based formats.

So now the SRT protocol, having been developed by Havision largely for video contribution in the first instance, is being promoted as a natural successor to RTMP, as well as other proprietary transmission mechanisms, having been made available open source. It set out to solve the same problems as RTMP, essentially to enable reliable, high quality and low latency delivery of real time services over IP networks and the public Internet. However, it has been designed for the higher bandwidths and more demanding requirements of modern services including OTT video.

There are two original packet delivery mechanisms for IP networks, UDP (User Datagram Protocol) and TCP. UDP is connectionless in the sense that packets are transmitted form a source without first establishing an end to end path via successive router nodes in the network. It is flexible in use of network capacity but lacks error detection, flow control or re-transmission of lost packets, so there is no guarantee of delivery. TCP on the other hand is connection-oriented in that it establishes an end to end path for a session and then performs error correction and flow control with guaranteed delivery of IP packets, which are reassembled at the destination in the order they were sent. TCP therefore was preferred for some video download and on demand services because it guaranteed all the content would arrive without any deterioration in quality as a result of dropped packets. But there is no guarantee over latency, which indeed tends to be higher because of the processing overhead incurred in the error correction and especially delays caused by having to retransmit dropped or corrupted packets. It is therefore less suitable for live video services, which have tended towards UDP instead. However, RTMP is based on TCP, with some mechanisms to overcome deficiencies but still suffering from some performance constraints as a result.

TCP does not guarantee any given level of capacity because although it can set up an end to end path it cannot dictate what other traffic might contend for a given link on that path, so it is subject to congestion. It does not claim exclusive use of the path it sets up. It therefore needs mechanisms for responding to and recovering from congestion, but these are not sufficiently fast to deliver the best experience over high bandwidth networks.

SRT represents an attempt to combine the advantages of UDP and TCP while eliminating the weaknesses. SRT is based on an earlier protocol called UDP-based Data Transfer Protocol (UDT), which was designed initially for transferring large datasets over IP networks for which again TCP was inefficient. SRT then incorporates enhancements over UDT for live video transmission, including encryption and reduction of latency.

UDT had added error correction and reliable two-way communication to UDP, making it work more like TCP, but without the delays and processing overheads. For example, it uses periodic acknowledgements to confirm packet delivery and is able to report packet loss. SRT then adds encryption, essential for premium live services, and a mechanism to balance retransmission with controlled dropping of packets at times of congestion. A key innovation is the ability to recover the characteristic waveform of the signal at the destination to filter out the impacts on the stream of delay, jitter or variation in delay and packet loss – in other words to compensate very quickly for a “dirty” network.

SRT does this by first detecting real-time network conditions between the two endpoints and then adapting to them. This enables it to compensate for jitter and bandwidth fluctuations due to congestion over noisy networks. It also has more efficient error recovery mechanisms that minimize the packet loss typical of Internet connections, even though they cannot eliminate it entirely. In this way SRT enables improved quality over earlier protocols, while reducing latency and avoiding costly over provisioning of network capacity.