Streaming video has become an integral part of our daily lives, from watching our favorite shows on Netflix to live concerts on Amazon Prime to shoppable videos and watching the ponies run in real-time.
When it comes to streaming video content, there are a variety of protocols and technologies available. Two popular options are HLS (HTTP Live Streaming) and WebRTC (Web Real-Time Communication). Both have their own strengths and weaknesses, and understanding the differences between them can help you determine which is the best fit for your streaming needs.
In this article, we'll compare HLS and WebRTC streaming, looking at their features, use cases, history and performance to help you make an informed decision.
HLS, the pioneer in the streaming world, made its debut in 2009, followed by the release of WebRTC in 2011. Despite their frequent comparison, these two technologies were created for entirely different purposes. And to this day, the trade-off between scale and low-latency remains a crucial consideration in the streaming industry.
Considering their unique origins and initial purposes, it comes as no surprise that HLS and WebRTC deliver audio, video, and data in fundamentally different ways.
HLS is an adaptive streaming protocol developed by Apple for delivering live and on-demand video content over the internet. It uses HTTP to deliver video segments, making it compatible with most web servers and content delivery networks (CDNs).
HLS boasts a robust infrastructure that ensures quality for every viewer, but this comes at the expense of latency. Latencies for HLS streams typically range from 15 to 90 seconds, which was acceptable in the past when there was no alternative, but becomes increasingly problematic as technology advances.
HLS works by breaking video content into small segments, typically between 2-10 seconds in length. These segments are then delivered to the viewer's device via HTTP requests. The video player on the device then reassembles the segments to play the video seamlessly.
HLS also uses a manifest file, called a “m3u8” file, which contains information about the video segments and their URLs. This allows the player to request the appropriate segments and switch between different quality levels based on the viewer's internet connection.
WebRTC, on the other hand, was designed as a real-time, ultra low latency video streaming solution for web-based video conferencing, and data sharing, without the need for additional downloads. It is an open project that developers can customize to their needs. However, when WebRTC ventures into the realm of HLS, scale and quality become challenging to achieve.
WebRTC is an open-source technology that enables real-time communication between browsers and mobile applications. It was developed by Google and is now supported by all major browsers, including Chrome, Firefox, and Safari.
WebRTC allows for both client to server and client to client (aka peer to peer, or P2P) connections between the viewer's device and the streaming server or video conferencing peer. This allows for low latency and real-time communication, making it ideal for applications where interactivity is required such as video conferencing and online gaming.
Recognizing the power of WebRTC to revolutionize interactive viewing experiences that drive engagement, Phenix has designed a cutting-edge video streaming architecture that guarantees broadcast quality and scalability without compromising on latency.
Phenix's Interactive Transport Protocol (Phenix ITP) is Phenix's implementation of WebRTC and was designed from the ground-up to handle a scale that historically evaded WebRTC, while maintaining W3C WebRTC standard compliance. Unlike the open source project spearheaded by Google for video conferencing applications, Phenix ITP was intentionally designed for broadcast media use cases at scale and has been optimized for quality, throughput, latency, and synchronization.
Phenix ITP offers a variety of features that extend beyond the boundaries of standard WebRTC, such as: Geoblocking, Token Authentication, Multi-Angle Sync, Global Audience Synchronization, Server Side Ad Insertion (SSAI), and Digital Rights Management (DRM).
Phenix manages complete audience synchronization through its patented Phenix SyncWatch™ technology; supports adaptive bitrate (ABR) streaming to broadcast-quality streams to the player, without latency or caching; and employs dynamic forward-error correction (FEC) when communicating with compatible endpoints.
As Phenix continues to innovate, the company's newest feature includes the industry's first available server side ad insertion (SSAI) delivered in real-time without sacrificing latency.
Phenix ITP, HLS and WebRTC have different strengths and are better suited for different use cases. Let's take a look at some common scenarios where each protocol excels.
When it comes to video streaming, performance is a crucial factor to consider. Let's compare the performance of Phenix ITP, HLS and WebRTC in terms of latency, scalability, and adaptability.
Latency refers to the delay between when a video is captured and when it is displayed on the viewer's device. Lower latency means a shorter delay, resulting in a more real-time viewing experience.
Scalability refers to a streaming protocol's ability to handle high traffic and scale to a large number of viewers. This is an important factor to consider for popular live events or large-scale streaming services.
Phenix's ITP is WebRTC compliant, but was designed and built for broadcast scale. Rather than using open source components, Phenix built something designed for broadcast scale. Fully autonomous scalable infrastructure with 34 points of presence (PoPs) can reach millions of concurrent viewers globally and brings proven experience delivering video to 500,000 concurrent viewers.
HLS is highly scalable, thanks to its use of CDNs. This allows for efficient distribution of video segments to a large number of viewers, making it suitable for high traffic events.
Conventional WebRTC using open-source libraries and media servers are typically not as scalable as HLS. The open source projects are mostly built for small scale video conferencing use cases and don't scale up well to broadcast scale interactive media use cases because they rely heavily on peer-to-peer (P2P) networking.
Adaptability refers to a streaming protocol's ability to adjust video quality based on the viewer's internet connection. This is important for a smooth viewing experience, especially for viewers with slower internet speeds.
Phenix has a patented approach to real-time adaptive bitrate transcoding that continuously monitors network conditions and dynamically inserts keyframes as needed for faster and more intelligent switching between resolutions and bitrates to maintain broadcast quality video on a global scale.
HLS supports adaptive streaming, allowing for seamless switching between different quality levels based on the viewer's internet connection. This ensures a better viewing experience for all viewers, regardless of their internet speed. Switching layers in the multi-bitrate ladder can only happen on fragment boundaries, typically every 2-10 seconds. However, with a large local buffer and 10-90 seconds of end-to-end latency this granularity is not a problem.
WebRTC doesn't have any built-in mechanism for adaptive bitrate video streaming.
In industries like Media and Entertainment, the ability to generate revenue through advertising is table stakes. With its extensive viewership, loyal audience, and potential for profitable advertising income, the distribution rights for live sports and entertainment have become a valuable asset within the media and entertainment sector. Let's compare the monetization strategies available when using Phenix ITP, HLS and WebRTC.
Phenix ITP is able to insert server-side ads while maintaining video streaming latency of less than ½ second. Their patent protected approach supports the industry-standard VAST protocol to deliver personalized ad content decisions and ad reporting information.
HLS is able to insert server side ads with the typical video streaming latency for HLS.
Conventional WebRTC implementations do not have the ability to insert ads.
HLS divides streaming data into "chunks," typically ranging from 2 to 10 seconds, which are then transmitted to and received by the end user. This enables an HLS stream to have varying qualities for each individual chunk: your first 10 seconds may come in 720p HD, but your connection gets worse so your second chunk may get delivered in 360p.
Each chunk can change based on different variables, often leading to a better viewing experience for the end user. However, viewers are starting to find the latency of HLS streams to be increasingly unacceptable.
|
Feature |
HLS |
WebRTC |
|
Chunk or Packet duration |
2 to 10 sec. |
1 frame, typically about 1/30 second. |
|
Bitrate adaptation time |
2 to 10 sec. |
Less than 100ms. |
On the other hand, WebRTC takes a different approach by sending packets instead of chunks. These packets can be thought of as very tiny chunks, with each packet having a maximum size of 1200 bytes.
A smaller client-side buffer allows for a much faster stream startup time and requires an ABR algorithm that can operate at a much higher frequency that traditional ABR algorithms. The use of packets and frame-based video delivery rather than small video files is a crucial aspect of what enables WebRTC to deliver real-time communication.
In conclusion, both HLS and WebRTC have their own strengths and are better suited for different use cases. HLS is ideal for on-demand video streaming, while WebRTC is better suited for real-time communication and interactive streaming. Phenix ITP is best suited for use cases where interactivity and a fully-synchronized viewing experience are important.
When it comes to performance, HLS has higher latency but is highly scalable and supports adaptive streaming. Traditional WebRTC, on the other hand, has lower latency but is less scalable and may require additional infrastructure for large-scale streaming.
Phenix ITP was developed to maximize the advantages of both HLS and WebRTC. It offers real-time video streaming with less than ½ second latency to broadcast-sized audiences and was designed as part of an overall architecture intentionally designed and built for real-time video streaming at broadcast scale.
Ultimately, the best choice for your streaming needs will depend on your specific use case and requirements. By understanding the differences between Phenix ITP, HLS and WebRTC, you can make an informed decision and choose the best streaming protocol for your needs.