Exploring Low-Latency Technology Options in the Wowza EcosystemJuly 23, 2019
If you’re a live producer, glass-to-glass streaming latency is always a concern. Anyone currently streaming with the Wowza Streaming Engine™ software or the Wowza Streaming Cloud™ service has several options to reduce latency, with some requiring a change in technology and some involving a simple change in settings. In this article, I’ll review those alternatives using the features shown in Table 1.
Note that this document only discusses Wowza implementations of the technologies discussed. Other implementations of the same technology, like WebRTC, may have a completely different feature set.
As a starting point, if you’re using Streaming Cloud or Streaming Engine at the default setting, you’ll have a ten-second segment size. What’s more, most players buffer three segments before starting playback. This translates to at least 30 seconds of latency between what’s live and what your viewers are seeing. Let’s explore your options and see how low each technology can go.
|Streaming Cloud/Engine||WebRTC||HTTP Low Latency|
|Latency||8-12 seconds||1-2 seconds||3 seconds (but headed lower)|
|Scale||Yes||Not as efficiently||Yes|
|Adaptive bitrate||Yes||No||No (coming)|
|DVR||Yes in Engine (not in Cloud)||No||Possibly|
|Development cost||None||1-2 weeks||None|
|Application||Traditional live streaming||Conferencing/webinars||Interactive low-latency apps like auction and betting|
Tweaking Settings in Streaming Cloud/Streaming Engine
The simplest, cheapest, and safest way to reduce latency within Streaming Cloud or Streaming Engine is to simply reduce the segment size. Note that Apple recommends a minimum setting of six seconds per segment, which should reduce your latency down to 18–20 seconds. You can go lower, as described in the blog post, HLS Latency Sucks, But Here’s How to Fix It. Some producers have successfully reduced segment length to under half a second.
While this should cut latency to around 2-4 seconds, it also reduces the video buffered by the player from a very safe 30 seconds to a scary 1.5 seconds, which could translate to interrupted viewing. In addition, shorter segment lengths require shorter keyframe intervals, which can cut quality. So, if you’re broadcasting a live sporting event that will compete with social media for timeliness, exploring a segment size in the 2-3 second range may be worth it. For church services or town council meetings, not so much.
So long as your new segment size is fairly conservative — say 4-6 seconds — you can cut latency significantly without impacting pricing, infrastructure, or incurring development costs. You’ll also retain the same quality and feature set as you currently have. For most producers, this will be the best short-term approach.
For a tutorial detailing how to reduce the segment size of Apple HLS streams in the Wowza Streaming Engine, check out the post Changing Default Segment Size to Decrease Streaming Latency.
WebRTC is a streaming protocol that you can access in Wowza Streaming Engine to reduce latency down to 1-2 seconds. For many streaming producers, however, there may be a mismatch between WebRTC’s strengths and their requirements.
To explain, WebRTC is designed for browser-to-browser real-time communications and Wowza’s implementation enables several unique workflows. For example, you can use Wowza’s toolkits to enable browser or mobile-based encoding/streaming to Wowza Streaming Engine that can be distributed at low latency via WebRTC. Alternatively, these streams can be transcoded and broadcast as HLS or DASH streams at normal latency. Wowza Streaming Engine also reduces the bandwidth requirements for peer-to-peer conferencing compared to out-of-the-box WebRTC solutions.
However, in Wowza’s current implementation, WebRTC comes with multiple development costs and other limitations that make it unsuitable for most traditional live-streaming broadcasters. For example, to enable your users to broadcast from their browsers or mobile devices, you’ll have to create applications to do so. Wowza supplies the necessary toolkits but it still requires a week or so of development time and you’ll need an additional SSL certificate. WebRTC also doesn’t scale very effectively because all participants require server-based peer connections.
You’ll also lose the quality and features available with HLS/DASH-based streaming, as Wowza Streaming Engine currently supports WebRTC connections consisting of a single stream rendition (no adaptive bitrate within a single connection) without captions and DVR functionality. Browser-based encoders tend to produce lower quality than hardware or application-based encoders, particularly on lower-powered computers. Finally, relying on the browser for encoding and playback, as opposed to your own player, can cause minor compatibility issues as browsers update.
WebRTC is an ideal tool for those creating applications that leverage its browser-based functionality. But as currently implemented in Wowza Streaming Engine, it’s a poor candidate for traditional broadcasters simply seeking a low-latency technology.
HTTP Low Latency
HTTP Low Latency describes technologies that distribute streams to HLS and DASH players over HTTP. This includes Apple’s new Low-Latency HLS spec and low-latency CMAF for DASH. Wowza is currently working on a program to support both technologies. Latency is projected to be in the 3-second range, though this should drop as the technology matures.
As described in an earlier post, HTTP Low Latency solutions work by sending less than a full segment of video from the encoder to the player, though Apple uses HTTP/2 PUSH to accomplish these transfers while DASH uses an HTTP 1.1 specification known as chunked transfer encoding. Since the video transferred can be as short as a single frame, this reduces latency significantly. That said, lower latencies mean lower buffer sizes, which means lower resiliency.
In both DASH and HLS flavors, Wowza’s HTTP Low Latency will be standards-based, so you should be able to use your existing encoder, player, and CDN infrastructure, with scalability similar to HLS/DASH streams on Wowza Streaming Engine or Wowza Streaming Cloud. While standards-based, it will also deploy many controls to help balance latency and stream resiliency. The management of issues critical to low-latency applications — like catching up when a stream falls behind and maintaining synchronization on all streams on all platforms — will also be baked into this technology.
Both HTTP Low Latency technologies will eventually be adaptive, support captions, and potentially have DVR capabilities, so quality should be similar to existing HLS/DASH services. Implementation will be simple in both Wowza Streaming Engine and Wowza Streaming Cloud, though pricing isn’t set so it’s unclear if this reduced latency and increased control will cost more than standard streaming.
A Final Consideration When Weighing Low-Latency Technology
While low-latency technology is often beneficial, it’s critical to realize that it always comes at some risk to playback resiliency. Simply put: the lower the latency, the less resilient the stream. If your application functions well with a latency in the 8-12 second range, then a few tweaks to segment size in Wowza Streaming Engine and Wowza Streaming Cloud may be all that you need. On the other hand, if you really do need latency in the 3 seconds and lower range, you’ve got the additional options detailed above.