HLS vs. WebRTC: What to Know Before Choosing a Protocol

 

You’re dead set on low-latency streaming, but there’s just one problem: you don’t know where to begin choosing a streaming protocol. The truth is, not all protocols are created equal, and many cater to specific needs, not all of which apply to you. However, if low latency is your goal, that narrows the field considerably. 

Web Real-Time Communications (WebRTC) and HTTP Live Streaming (HLS) are both streaming protocols capable of providing a low-latency experience, but they do so in very different ways. WebRTC establishes two-way peer-to-peer connections without the need for an intermediary server, whereas HLS relies on a more traditional client-server model. In this article, we’ll break down the pros and cons of both HLS vs. WebRTC and how to determine which is best for you. 

   

What Is a Streaming Protocol?

In computer science, a protocol is quite simply a set of rules for transmitting data between electronic devices. The data in question can vary. A streaming protocol specifically dictates how streaming media is broken up and transmitted across a network. Different streaming protocols may require different codecs; work with different playback devices; and vary in flexibility, security, and speed. 

 

What Is HLS?

Apple initially developed HTTP Live Streaming (HLS) to resolve live stream playback issues for iPhone users. It has since become the most popular and among the most widely supported streaming protocols available, with playback capabilities on Apple, Windows, Android, Linux, and more. 

A typical HLS workflow starts with raw media files being encoded using the H.264 video codec, and AAC audio codec. The encoded data is packaged using the Real-Time Messaging Protocol (RTMP) and sent to a media server. The media server transmuxes the data, repackaging it with HLS instead of RTMP. It may also transcode the data, unencoding and re-encoding it with different bitrates and resolutions, a process conducive to adaptive bitrate streaming (ABR). 

From here, the data is likely sent first to a content delivery network (CDN) or directly for playback on user devices. HLS streams this data in chunks as opposed to a continuous stream. How these chunks are requested and which ones get sent to which devices depends on whether ABR is part of the workflow. 

HLS vs. Low-Latency HLS

At a latency of 6-30 seconds, HLS is not the fastest protocol out there. By its very design, it favors reliability over speed. However, with the advent of Common Media Application Format (CMAF) and WebRTC (more on this below), latency concerns have been a hot topic. The demand for low-latency streaming has grown considerably. 

Apple answered the call with Low-Latency HLS (LL-HLS). This is not its own protocol but rather an extension to the existing HLS protocol. But what does it do that lowers latency? In a nutshell, it uses shorter media chunks and a tag (#EXT-X-PRELOAD-HINT). 

Short media chunks spell lower latency because they allow a playback device to start playing live streamed media sooner. Basically, the larger the chunk in chunked transfer encoding, the longer the device needs to wait before getting started. 

Typically, a playback device doesn’t “see” the next chunk before it’s done playing the first one. That’s where the #EXT-X-PRELOAD-HINT tag comes in. It basically requires the stream to hint at the most likely location of the next chunk in a given data segment. This helps maintain a smooth stream of media to the client device without the constant need for data requests. 

It’s worth noting that LL-HLS and HLS are now effectively one in the same. However, the industry still differentiates between them in terms of vendor support. As latency is a fundamental concern to WebRTC, we want to make sure we talk about both.

 

What Is WebRTC?

WebRTC is more than just a streaming protocol. It’s actually a collection of protocols, codecs, and JavaScript APIs that work together to provide an ultra-low latency peer-to-peer stream. Google released WebRTC as an open-source project back in 2011 and it has been gaining steam as the fastest available streaming protocol. 

What does a basic WebRTC stream look like? Imagine clicking a button and being able to stream sub-500 millisecond audio and visual data back and forth between you and your friend. The data does not pass through an intermediary server but rather goes directly from one device to the other. 

Of course, the reality of WebRTC is a tad more complicated. Typically, some sort of signaling or NAT traversalneeds to occur in order for the two devices to “find” each other. In other words, you need to know your friend’s exact IP address, which may be buried behind a NAT device. Additionally, the out-of-the-box version of the technology is not very scalable. If you want to stream to a larger audience, then you need to adjust your workflow, likely with a media server and CDN. 

The real catch is that evolving your WebRTC workflow to meet your various needs could also affect latency. Knowing whether WebRTC is right for you involves a balancing act between your low-latency needs and the other functions you require to achieve your streaming goals. In this way, an HLS or low-latency HLS option might be better. 

 

HLS vs. WebRTC

Now that we have a general sense of what each of these streaming protocols brings to the table, let’s dig down into each of the major considerations you might have as a prospective low-latency streamer and how they compare.  

Latency

Is HLS vs. WebRTC truly a battle of speed? Before the Apple Worldwide Developer Conference (WWDC) in 2019, the answer would have been a hard no. The HLS protocol has a lot of great attributes that contribute to its mass popularity, but low latency didn’t used to be one of them. At least not until Roger Panton announced LL-HLS during that 2019 conference. 

He would then go on to announce at a later point that HLS and LL-HLS were no longer two separate protocols but rather two parts of the same solution. Ever since, the LL-HLS extension has been baked into the HLS specification as a feature set. This makes it easy to take advantage of the sub-3-second latency that LL-HLS has to offer. 

Sub-3 seconds is undoubtedly plenty fast for most use cases. But there are times when even a few seconds could negatively impact a stream. Interactive live streaming, as with auctions and telehealth, may need a closer to real-time experience. When it comes to ultra-low latency streaming, WebRTC reigns supreme. But at a cost, as we’ll soon cover. 

Ask yourself: How important are a couple of additional seconds of latency to my streaming needs?

Delivery Method

WebRTC was built with bidirectional, real-time communication in mind. Unlike HLS, which is built with TCP, WebRTC is UDP-based. This means that WebRTC can start without requiring any handshake between the client and the server. As a result, WebRTC is speedier but also more susceptible to network fluctuations. Peek at the video below for a closer look at how streaming data delivery via WebRTC differentiates from HLS.

   

Flexibility And Compatibility

Which protocol is more flexible? Realistically, HLS is the most flexible and easily adapted. However, LL-HLS muddies the waters a bit. 

As the most widely used protocol for media streaming, HLS is supported by a wide range of devices and browsers, and it’s fully compatible with a CDN. Another perk of HLS is its support for closed captions and subtitling, metadata, digital rights management (DRM), and ad insertions. It’s no wonder that more than 70% of participants in our 2021 Video Streaming Latency Report indicated that they use HLS for delivery. 

Which streaming formats are you currently using for delivery?

That said, the LL-HLS extension isn’t quite there yet. These are capabilities that people will need, but it’ll take time for the industry to get them working within the ecosystem. However, no one can ignore Apple’s ecosystem for long. Their clout will push development work for LL-HLS. Our guess is that the availability of capabilities like these won’t lag too far behind.

Browser support for LL-HLS is par for the course and shouldn’t change from what you do with HLS. Player compatibility is another issue, though. Other than Apple’s native player, compatibility isn’t expected for other open-source native players such as Android’s ExoPlayer. Companies such as THEO and JW Player, however, have been developing their own proprietary players to help with playback on all major devices, platforms, and browsers. Moreover, any players that aren’t optimized for Low-Latency HLS can fall back to standard (higher-latency) HLS behavior.

So, it’s clear that HLS is more flexible and widely compatible than LL-HLS, but what about WebRTC? WebRTC is compatible with most browsers, requiring no additional software of plugins. It also can and has been adapted to a wide range of workflows, including WebRTC simulcasting and scalable video coding (SVC). However, these take a little work to implement. 

When it comes to flexibility and compatibility, there’s no clear winner between WebRTC and LL-HLS. Regular HLS is the friendliest in this regard, but that’s only if you don’t care about the additional latency.

Video Quality

For most video workflows, high-quality delivery is a product of adaptive bitrate (ABR) capabilities. It’s the secret sauce to professional streaming. ABR provides the best video quality and viewer experience possible — no matter the connection, software, or device.

As the standard in ABR video, HLS takes the cake when it comes to video quality, and that includes LL-HLS. Multiple renditions allow for playback on different bandwidths. The media server then sends the highest-quality stream possible for each viewer’s device and connection speed. A delivery method that automatically adjusts the quality of the video stream between multiple bitrates and/or resolutions is far better than one that only operates at a single bitrate.  

 

 

WebRTC, on the other hand, wasn’t built with quality in mind. WebRTC’s number one priority has always been real-time latency for peer-to-peer browser connections. As a result, quality takes a back seat.

WebRTC does not support ABR streaming. However, it does offer alternative methods. WebRTC simulcasting, not to be confused with typical simulcasting, involves preparing a few different bitrate options and funneling them through a selective forwarding unit (SFU) server for triaging. The SFU chooses the best bitrate option for each playback device to promote quality. 

WebRTC can also engage in selective video coding (SVC). The SVC extension allows WebRTC to prepare media files in layers. Think of an onion where the bitrate gets progressively lower the deeper you go. This method also uses an SFU whose job it is to peel away layers of the streaming onion to achieve the best bitrate option for a given playback device. 

So which protocol takes the quality cake? With ABR capabilities, HLS’s ability to balance quality and speed is more nuanced. It is the best option if quality is your ultimate priority. However, WebRTC has methods for improving quality and continues to evolve. 

Security

Privacy issues have long been a concern in the industry. Content protection throughout the workflow can take many forms, including encryption of incoming and outgoing streams, token authentication, and digital rights management (DRM) for premium content delivery. 

HLS specifically supports Common Encryption (CENC) and fmp4. It also uses Apple Fairplay for DRM and encryption. Because the LL-HLS spec has been merged into the HLS spec, it supports everything that the HLS spec does in theory. But as mentioned above, it’ll take time for providers to catch up. Capabilities such as DRM, token authentication, and key rotation will all be possible but not available until providers get them working within their ecosystems. LL-HLS isn’t completely unprotected, however. TLS 1.3 is recommended as part of the spec. It’s encrypted by nature, and it prevents hackers from intercepting data in transit. 

WebRTC also supports delivery over TLS to ensure the security of content in transit. The traffic between the two clients is encrypted, which enhances security. Although WebRTC lacks compatibility with DRM providers, if you’re looking for basic security measures, the encryption WebRTC offers will be enough. Things left out of the scope of WebRTC are authentication, authorization, and identity management. This doesn’t mean you can’t add them – you can, and you should. It just means that they’re not offered out of the box. 

When it comes to security, WebRTC and HLS are neck-and-neck provided you’re willing to adapt your out-of-the-box WebRTC solution. LL-HLS is well on its way to catching up. 

Scalability

HLS is easily scalable, and it undoubtedly comes out on top in this category. However, its LL-HLS alter ego is another story. 

Before integration with CDNs, scaling LL-HLS was merely aspirational and extremely limited. Vendors have spent the past couple of years developing for the ever-evolving spec, and they’ve recently begun announcing their support. Technology partners such as Fastly allow for global distribution and reduced latency, due to more cached content closer to the viewer. Although the delay is longer than that with WebRTC, CDNs make it possible to stream LL-HLS to thousands in less than 3 seconds. That said, development is still ongoing and large-scale implementations of LL-HLS remain few and far between. 

WebRTC’s scalability is another complicated topic. On its own, it is limited to small chat-based environments. However, many developers and streaming vendors have stepped up to create scalable solutions using the ultra-low latency protocol. So, with a little help, you can make it work for you.

Cost

WebRTC is an open-source protocol, and it’s free. Great! But while scaling WebRTC is totally doable even at sub-500 seconds, you’ll have to pay the price for a custom WebRTC CDN. 

HLS is more cost-effective – using affordable HTTP infrastructures and existing TCP-based network technology. That said, the original HLS comes with a much higher latency while LL-HLS is a less mature technology and support for some of the features that we take for granted with HLS is still a work in progress. 

 

HLS vs. WebRTC Summary Table

	HLS/LL-HLS	WebRTC
Latency	HLS alone is 6-30 seconds. With LL-HLS extension, it’s around 2 seconds.	Sub 500 milliseconds.
Delivery Method	TCP	UDP
Flexibility/Compatibility	Can be played back on almost all devices, apps, and browsers.	Can be played back on most browsers and devices without an additional plugin.
Video Quality	Prioritizes quality over speed.	Prioritizes speed over quality.
Security	Supports Common Encryption (CENC) and fmp4. Also uses Apple Fairplay for DRM and encryption.	Encryption is mandatory when using WebRTC. Other security features available with the help of a streaming service/platform.
Scalability	HLS is easily scalable as is the LL-HLS extension. However, the latter is still being accepted and not as widely supported.	Not intended for large audiences, reaching fewer than 50 viewers without a custom CDN or video platform like Wowza.
Cost	HLS is more cost-effective for most streaming needs.	WebRTC is free open-source software. However, you may need to invest in a streaming platform or service to help make the most of it.

 

Conclusion: How Wowza Can Help

HLS and WebRTC have come a long way in the last couple of years. Even though they’re both cutting-edge technologies and both driving the industry forward, each has its pros and cons. Neither option is perfect for everything, but one of the two could be the perfect solution for you. Ultimately, the best protocol will depend on the specifics of your project, the devices you plan to distribute to, and the size of your audience. 

Wowza and HLS

Even before Apple integrated LL-HLS into the overarching HLS protocol, Wowza had begun supporting the nascent protocol in our Wowza Streaming Engine software. We continue to support HLS with both our Streaming Engine and Wowza Video solutions, including the standard RTMP to HLS workflow described above.

   

Wowza and WebRTC

Wowza has a few options for taking advantage of the ultra-low latency of WebRTC on a greater scale:

• Real-Time Streaming at Scale for Wowza Video – Our Real-Time Streaming at Scale feature for Wowza Video deploys WebRTC across a custom CDN to provide near-limitless scale. Content distributors can stream to a million viewers in less than half a second, thus combining real-time delivery with large-scale broadcasting (see workflow).

• WebRTC Powered by Wowza Streaming Engine – By connecting all participants to a live streaming server like Wowza Streaming Engine, content distributors benefit from real-time streaming at a larger scale while optimizing bandwidth by minimizing the number of connections each client must establish and maintain. Additional infrastructure would be needed to scale beyond several hundreds of viewers. 
• Converting WebRTC to HLS or DASH – Finally, a live streaming server or cloud-based service can be used to transcode the WebRTC stream into a protocol like HLS for distribution to thousands. That way, content distributors can combine simple, browser-based publishing with large-scale broadcasting – albeit at a higher latency. When easy content acquisition (and not real-time delivery) is the key reason for incorporating WebRTC into your streaming workflow, then this solution is the way to go. Both Wowza Streaming Engine and Wowza Video can power WebRTC-to-HLS workflows.

Reach out for guidance in choosing a streaming protocol and selecting a streaming solution that best suits your needs.