The video technology business has a long record of confusing the field by duplicating efforts, or packaging essentially the same technology under different hats. We have had the Ultra HD Forum and UHD Alliance seemingly expending as much effort explaining why they both need to exist and how they are different, as they do promulgating their respective technological contributions to ultra HD evolution.
Now we have two rival protocols pitched for ultra-low latency streaming, leaving many pundits struggling to establish clear water between them. These are SRT (Secure Reliable Transport) and RIST (Reliable Internet Stream Transport), both of which are pitching for default position in the mobile video market, among others.
Omission of the word ‘secure’ in RIST gives away one of the differences so far, given that SRT supports end-to-end encryption while RIST does not. That oversight is now being rectified in the emerging RIST Main Profile, the second version of the protocol after the Simple Profile first unveiled in 2018, which adds encryption as well as the multiplexing support also lacking but present in SRT.
The main benefit of multiplexing in this context is that it allows multiple streams to be concentrated within a single workflow and post, which simplifies firewall configuration. After those additions to RIST there will be even less technical distinction between the two protocols, making it look like our prediction (made over a year back) that they would converge in form – if not in name – is coming true.
There is a certain degree of’ ‘not invented here’ syndrome behind the emergence of RIST, but also a suspicion that the two founders of SRT, Haivision and Wowza, would somehow gain an advantage from widespread adoption of their technology, even after it has been donated to the community and made available open source. Similar sentiments have been levelled against bigger fish, such as Google, and in those cases there is some truth in the accusations because of the power those great technology players can leverage over data.
But in the case of SRT, players far larger than Haivision, like Microsoft and Comcast, along with Chinese giants Tencent and Alibaba, have weighed in behind a still expanding consensus, which makes it hard to believe the protocol will fade away any time soon.
Indeed, as we reported only last week, SRT has become popular with software developers precisely because it is open source with no royalties to pay. They do not care whether Haivision obtains some indirect advantage out of it. Incidentally, we were reporting that Haivision, in conjunction with its SRT founding partner Wowz,a had decided to infiltrate the inhouse mobile video player targeted at developers, streamers and broadcasters. This gives them the means to view and monitor SRT video streams on mobile devices, with Sky News and video engineering firm Cinegy among early adopters.
Closer followers of the low latency streaming story may chip in at this point and cite WebRTC as a third major protocol breaking waves and so argue that it is a three-way rather than two-way battle. That is not quite correct because WebRTC is a different beast, being uncompromisingly focused on low latency rather than quality.
WebRTC differs from other low latency streaming protocols including RIST and SRT by avoiding packet re-transmission altogether and instead using the alternative approach to redundancy of Forward Error Correction (FEC). This was designed for situations where data re-transmission is impossible, as in one-way systems like DTH and digital terrestrial (DTT) TV. It is also preferred when there is no time for re-transmission, as when low latency trumps quality completely. It works by adding extra redundant data bits in such a way that packets that are lost or corrupted can be reconstructed at the receiving end, up to a certain level of loss.
This requires additional data, adding to network bandwidth required, and it can only cope with a degree of data bit loss depending on how much redundancy has been built in, with no scope for winding up error correction by increasing latency when network conditions deteriorate too greatly. WebRTC therefore depends on relatively reliable transmission and even then, at present, relies on H.264 baseline encoding, which restricts content to 1080p HD quality and is not capable of transmitting 4K.
In-sports betting is one application where low latency is most critical of all, because punters experiencing any differential delay in viewing associated online video or audio will be behind others in being able respond almost instantaneously to emerging events in the field, such as a point being won at tennis. Online betting firms therefore have been moving to deploy WebRTC for their live coverage of events.
For SRT and RIST, a balance has to be struck between low latency and quality and so the protocols both incorporate versions of ARQ (Automatic Repeat request). This is really no more than an optimized version of the error control and packet recovery method originally employed in TCP for the internet and widely used for on-demand video transmissions.
ARQ incorporates several improvements over TCP’s error correction both to reduce latency and bandwidth consumed. Firstly, it avoids the blanket acknowledgement of every package sent that TCP employs, which consumes bandwidth unnecessarily and imposes a toll on latency in situations where capacity is limited. Instead, ARQ sends messages back to the source end of a transport link only when a packet is missing, reducing the communication that made TCP extremely latent and profligate with bandwidth.
This still consumes some bandwidth and that increases with the rate of packet loss, but does so in a scalable and linear way without falling off the cliff as FEC does, when data loss suddenly escalates and video quality would plummet. While FEC exerts a constant toll on bandwidth, the overhead is minimal with ARQ in the event there is little packet loss.
ARQ still does suffer compared with FEC over larger geographical distances, whatever its proponents say. The greater the geographical distance between the nodes of a transport link, the higher the round-trip delay. Since data is still arriving at the same rate, higher round trip delays require bigger buffers to hold enough data to wait for a single round of re-transmissions to fill in for packets that have been lost. The buffer filling time therefore increases almost linearly with round trip delay, so distance imposes a double whammy on latency under ARQ, which is not the case with FEC because there is no re-transmission.
For that reason, we are not surprised to see that Haivision supports an FEC-based mechanism alongside SRT, catering for those applications, primarily online gaming and sports betting, where low latency is almost paramount and users do not care so much if quality is patchy.
We should note, however, that the impact of long distances on latency for most use cases is manageable. Considering that the round-trip time from, say, London to New York is about 100 milliseconds, the additional latency imposed of perhaps 200 milliseconds will rarely be very significant.
When it comes to RIST and SRT, it is getting to the point of spot the difference. Surely merging the two efforts would streamline resources and do the industry a favor.