Please enable JavaScript to view the comments powered by Disqus.

Latency Sucks! So Which Companies Are Creating a Solution?

What is latency? In a word, it means delay. Why is latency important? That’s a much longer—and, for streaming, a much more costly—answer. Because, when it comes to streaming, latency sucks.

To put latency in the context of streaming media, let’s first consider which of two latencies we are referring to. That’s a question that needs to be asked, whether you’re a live content producer looking to hire a streaming company to acquire a broadcast feed, or you’re planning to do it yourself.

The first type of latency is player startup time. At the request of numerous companies in the industry, I’ve had the chance to perform extensive tests around this type of latency, measuring the time difference between a user request to start a stream and the player’s actual response time.

It’s become a more rigorous and scientific endeavor in recent years, as time-to-start average rates have dropped from multiple seconds to less than 1 second. Gone are the days of the stopwatch—they’re replaced now by reams of data from logging capture tools. The methodology we employ is to run a series of tests, using our impartial test bed with standardized content, and then average out the results for each tested player.

These days, industry averages range in the 900–1,200 millisecond (ms) range from request to playback-ready state, but some customized apps are showing averages down around the 500–650 ms range. These time-to-play tests, which occur in two controlled environments using two types of internet service provider to filter out any single-location anomalies, only tell half the story, though.

The other latency issue is what occurs both before and after the user clicks on a link to request a live stream. This latency could be referred to as a lag time, meaning the time the stream itself lags behind the actual event or live broadcast.

Maxim Erstein, an engineer at Unreal Streaming Technologies, offers a good reason why we need to differentiate between the two types of latencies.

"Stream startup time is the amount of time between the moment [when] a user clicks on the Play button and the moment the stream starts playing,” says Erstein. “So you can achieve very low stream startup time with chunk-based protocols like HLS and MPEG-DASH, but only if the segments are large and already reside on the server. The player will download them instantly and will start playing immediately.”

You can achieve very low stream startup time with chunk-based protocols such as HLS and MPEG-DASH, says Erstein.

The problem, as Erstein told me, is that pre-existing chunks inherently mean significant lag times (aka high latencies). The reverse is also true.

“So when the latency is low, the startup time can be higher,” says Erstein, adding startup times are also affected by the minimal amount of video frames the browser needs before an HTML5 player begins playback. “It depends on how many frames the MSE [media source extensions] player needs to buffer before it can start playing. In Chrome it’s just few frames, but in Internet Explorer it’s like 20–30 frames.”

Using over-the-air (OTA) broadcast as a measurement, most cable television delivery adds about half a second of delay, which equates to an average of 500 ms or 15 frames. The lag time itself is only noticeable in digital cable delivery, and it is such a short lag time that it often represents itself in a multitelevision household as an annoying echo between two rooms watching the same live linear content.

Streaming lag times, though, can be well in excess of 30 seconds and often in excess of a full minute, depending on which type of streaming protocol is used.

Protocols and Latency

What do protocols have to do with latency? The illustration below may best illustrate the answer. Developed by Wowza Media Systems in conjunction with feedback from the author, the graphic shows a continuum of streaming late...