WebRTC vs HLS

It wasn’t too long ago that RTMP (and flash) ruled the internet streaming kingdom. As the number of viewers grew, it became clear that newer technologies were in a better place to serve the needs of content providers. RTMP is still used today, mainly to push audio/video content from one application or system into another. However for the most part when streaming to viewers, it has been replaced by WebRTC and HLS. This article aims to educate users on the differences between the two and why a prospective client might choose WebRTC over HLS. 

HLS

HLS (Http Live Streaming) can be characterized as video chopped up, cached and delivered on the fly by CDNs to users in chunks as requested. The protocol uses TCP and TLS for transport and security, plus has support for automatic bitrate (DRM, metadata and captions in non low latency mode). Because clients can request different chunks, HLS supports rewinding, selecting different areas of the video for playback and true pausing.  It is supported by most video streaming CDNs and is often an inexpensive way to stream to a large audiences. 

When considering HLS, you should be aware of the two main drawbacks; longer delays and poor browser support. HLS has typically shown to delay up to 20 seconds, although with newer technologies it can be reduced as low as two to five seconds. The other major issue is browser compatibility. HLS is primarily done with a third party library such as HLS.js. This means HLS is not a premiere browser and playback is subject to the quality of the player you import into your web application. 

Since its formation, HLS has seen some improvements including the inception of DASH and LL-DASH (Low Latency DASH). As a result delays have improved from over 20 seconds down to around 2 to 8 seconds. With the adoption of CMAF (Common Media Application Format) you no longer need to create multiple versions of the same video in different formats, reducing streaming costs and storage requirements. 

WebRTC

Web Real Time Communication or WebRTC started out as a way to deliver real time communication between peers. Since then it has evolved to offer not only the ability for clients to mesh together, but also a way for clients to communicate with servers (Single Forwarding Unit - SFU and Multipoint Control Unit - MCU), almost mimicking HTTP Streaming but with more advanced technology. 

WebRTC is still a new technology in a lot of ways and it continues to evolve. WebRTC has started closing the gap in broadcasting functionality with HLS, offering automated variable bitrates and recordings. WebRTC has also drafted a specification WHIP (WebRTC over HTTP) which illustrates the adoption of the client / server model for WebRTC. This makes it easier for origin servers to ingest WebRTC from other applications and services. The last major difference between HLS and WebRTC is all viewers will always see the same content. You can guarantee that what one user sees is the same as what another user is also seeing which is not generally the case for HLS.

When considering WebRTC, you should be aware of the two main drawbacks; cost and scale. WebRTC is a sub-second streaming protocol while in HLS has cached files on edge servers. WebRTC allows you to create a connection to the server and stream videos directly to the desired audience live. This is both more costly and a much bigger challenge to scale properly, especially as the number of streaming participants increases.

Conclusion

Both WebRTC and HLS have changed significantly since their initial release into the market. Both are interchangeable in a variety of situations and can even be adopted in the same architecture. In many cases though, entire architectures that were dominated by HLS can be replaced by WebRTC offering improved latency which drives better interactivity and engagement. Use cases where interactivity is driven by users seeing the same content at the same time (live chat, polling, Q&A) or multiple camera angles showing the same live event are all made easier by WebRTC. While WebRTC hasn’t replaced HLS, it does provide a new avenue for application developers to achieve sub-second latency.