There Is A Synchronisation Problem In Livestreaming

Livestreaming is a combination of two knotty engineering problems. First, you want to get the same pictures to a very large audience without anything exploding on the server side. Second, you want to let that audience take part in what they are watching – crucially, while it is still happening. The first has been solved for years, but the latency challenge of the second is what makes for some of the interesting work in video delivery these days.

Here’s what’s going on with the technology.

We’re Using A Protocol That Is Built To Be Late

HTTP Live Streaming, which is the format Apple created in May 2009. It was first supported on iPhone OS 3.0; these days, it is one of the dominant ways video reaches browsers and phones. It was originally designed to survive bad networks. Apple says so directly: historically, HLS has favoured stream reliability over latency.

The specification, published as RFC 8216, tells players not to begin within three target durations of the live edge, because starting any closer can trigger stalls. At the six-second segments that Apple uses in its own worked examples, this places a well-behaved player at least eighteen seconds behind – and that is before encoding or delivery have added anything. For today’s livestreaming needs, this would nominally be unacceptable for any interactive entertainment product.

Fun fact: there is no reason to argue what “interactive” really means, because the Internet Engineering Task Force (IETF) has a precise definition. In its overview of the protocols underpinning browser real-time communication, interactive means that “an action by one party can cause a reaction by another, which the first party then observes, with the whole loop taking no more than hundreds of milliseconds”. A video call meets that bar routinely, but a standard livestream misses it by design.

The Gap (and Closing It)

Most live formats can absorb the eighteen-second lag – but when the host and the audience have to share one timeline, this is not the case. A clean example is online live bingo clubs: Buzz Bingo streams sessions from a studio with live hosts, and its own launch material describes players and hosts interacting as the numbers are called. Every participant has to see the same call at the same moment, and the host has to be reacting to current chat messages rather than ones arriving from a quarter of a minute ago.

Fixes exist, but they are not free – at least technologically. Apple's low-latency extension splits each segment into much smaller parts – two hundred milliseconds in its example against the usual six seconds – and lets the server hold a player's request open until new media exists rather than having the player poll for it. That brings delivery into the range of broadcast television while keeping the scale that HTTP delivery was built for.

Going further, to the hundreds of milliseconds the IETF describes, generally means moving to WebRTC-style transport, which was built for conversation rather than broadcast and gives up the easy caching that made HTTP delivery cheap at scale.

None of that is exotic any more, and livestreaming was able to become a key portion of entertainment off the back of it. Nevertheless, it’s fascinating to know just how poor a fit the protocol it’s all built upon nominally is for some of its most intensive tasks.