How Much Latency Can Your Broadcast Handle? [Decision Tree]

Building a live streaming solution, but not sure how critical it is to reduce latency? For some use cases, video lag isn’t worth stressing about — but for others, it’s the most important factor. Follow this decision tree to determine the specific needs of your project and which delivery technology suits you best.

 

 

As fast as it can seem, no video you watch or interact with is truly real time. It takes time for anything to move from one place to another, even virtual packets of data flying through the air from a camera to a video CDN to a viewer’s device. In the video world, this time is known as “latency,” and it can cause as much as a 45-second delay in standard live streaming workflows.  

As a video producer or distributor, you obviously want your viewers’ experience to be the best possible. Latency is an integral component in this — for example, no one likes watching TV when there’s a lag that makes the dialogue come a few seconds after the actors’ lips have moved. That said, depending on the kind of content you create, you don’t necessarily need to bend over backward trying to acheive sub-second latency.  

How much can your broadcast handle? Do you need real time, or can you get away with a latency of 30 seconds? How much latency will your viewers tolerate, or even notice?  

You’ll inevitably use one or multiple streaming protocols in your video delivery, and each one affects how long it takes data to reach your audience. Follow the decision tree above to determine the right protocol(s) for your streaming needs and keep reading for a more in-depth explanation of what latency you need.  

   

Common HTTP Latencies 

Hypertext Transfer Protocol (HTTP) is the most common method for transmitting data from one place to another on the Internet. In the video world, the two most popular HTTP-based protocols for streaming are Apple HLS and MPEG-DASH. These protocols result in a latency of around 30 seconds on average (as much as 45 and as low as 18 seconds), making them the slowest.  

If they’re so slow, why are they so common? They’re scalable. Each is intended for one-way streams to large audiences and linear programming (the kind of TV you were familiar with before streaming platforms became so popular). For instance, a live concert streaming to viewers at home might use a basic HTTP protocol, or a Free Ad-Supported TV (FAST) channel that’s a streaming TV version similar to traditional cable and broadcast. The less pressing it is that your audience sees what’s happening immediately, the higher the latency you can get away with.  

 

Reduced Latency 

These protocols have “tuned” versions that make them much faster, closer to five to 10 seconds. Live streaming news and sports often use these protocols because distributors want audiences to know what’s happening as fast as possible while still streaming to many.  

Let’s say you were watching a high-stakes World Cup game while constantly chatting with other fans on social media. If there was a latency of 20 seconds, members in the live audience might tweet about the winning goal way before you see it on your screen, ruining the experience and the illusion that you’re seeing it for the first time. Broadcasters don’t want a discrepancy this high, so aiming for a five-second delay is more ideal.  

OTT providers use HLS Tuned and DASH Tuned, too. You’re not watching a Netflix or HBO Max movie live, so it’s not as important for the data packets to stream from each company’s servers to your screen immediately — you won’t even notice. However, these protocols can still afford to be faster because fewer people are watching the same title at any given moment.  

   

Low Latency  

Apple and the Motion Pictures Expert Group (the organization that developed DASH) created extensions that make HLS and DASH even faster: Low-Latency HLS (LL-HLS) and Low-Latency Common Media Application Format (LL-CMAF), respectively. These extensions bring HLS and DASH’s latency down to between one and five seconds.  

Low latency like this is opportune for user-generated content (UGC) live streams (think Instagram), game streams (think Twitch), and esports. These streams are not two-way but entail some sort of interactivity, like comment sections, which require data to reach viewers faster so there isn’t a lag between comments and specific in-stream moments.  

 

Near Real-Time  

If you’re streaming two-way, though, real-time communication is essential. It’s difficult to mimic a real in-person conversation through video if there is a delay between someone’s words and sounds, so two-way conferencing and telepresence often depend on the WebRTC protocol’s sub-second latency.  

Other devices that need real-time streaming use WebRTC, too. Remote device control like welding — in which case the smallest details make a world of difference — need to deliver video data to operators as fast as possible. Anything that requires some sort of interactivity, like online gambling, fitness, and live commerce, also demands sub-second latency.   

   

However, WebRTC isn’t ideal for large audiences, so Wowza offers a solution called Real-Time Streaming at Scale to account for this caveat with a custom CDN that enables real-time streaming to a million viewers. This way, you can reach as many people as you need to while still making your streams interactive.  

 

What Latency Do You Need?  

It’s tempting to think you need as close to real-time latency as possible regardless of your audience and content, but this isn’t the case. In our 2021 “Low-Latency Streaming Technology: The Key to Interactive Video” report, over 50% of survey respondents still used protocols with a latency in the 3-45 second range.  

 

How much latency are you currently experiencing?

 

You’re in good company if your use case doesn’t require sub-second latency. And if you still need real-time streaming for two-way communication and interactive live streams, Wowza has solutions for it all. Get started today with a free trial.