LL-HLS vs HLS vs LL-DASH: Low-Latency Streaming Compared in 2024
In 2009, Apple introduced HTTP Live Streaming (HLS) as a way to stream live and on-demand audio and video content over the internet. It is now the most widely used video streaming protocol across the globe, with support for all major browsers and devices.
In this blog, we will dive into why LL-HLS was created, what it is, how it differs from ll hls vs hls, what are its salient features, how it fares against LL-DASH, and a few things to keep in mind while implementing it.
LL HLS vs HLS: What is the difference?
As discussed above, HLS is a streaming media delivery protocol that uses HTTP to deliver video and audio content over the Internet. It is quite a popular protocol used by OTT service providers and other major browser and devices.
On the other hand, ll hls is a variant of HLS that is optimized for low-latency streaming. It reduces the time between when a user initiates playback and when they see or hear the content (known as "latency"). This can be especially important for live streams, where even a few seconds of delay can make the experience less enjoyable for viewers.
What are the technical differences between hls and hls low latency streaming?
Buffering Protocols
The main technical difference between hls and hls low latency is the protocol both use to handle streaming. HTTP live streaming uses a unique buffering mechanism that waits for the entire segment to be downloaded before streaming. This can impact the latency, because the viewers have to wait for the entire segment to download before they can enjoy video content.
hls low latency streaming uses server push which contributes in reducing latency. This means that the server pushes the segments of the video to the receiving end. It starts playing back the video as soon as the first segments of the video download. It ultimately reduces latency because the viewers can watch the video while the other segments are being downloaded.
Latency
Since low latency hls uses chunked transfer encoding, it reduces latency. Therefore, hls low latency is typically around 2-5 seconds, compared to 6-30 seconds for HLS. This makes hls low latency streaming a better choice for live streaming applications where latency is critical.
Now, let's get down to the business.
Why Low-Latency HLS?
HLS, the predecessor of LL-HLS, was launched to stream high-quality content at scale across devices and platforms. However, its scale-oriented streaming architecture came at a price, i.e., latency. For the uninitiated, latency is the time it takes from the video creation (on a camera) to its final playback (on a user's device), also called "glass-to-glass latency". In between, this video stream has to be encoded (both audio and video), segmented, packaged, listed, downloaded, delivered, decoded, lip-synced, and buffered before its playback. The streaming protocol (like HLS) handles all of this heavy lifting.
While HLS did a great job in terms of quality and compatibility, over the years, its development consistently compromised on latency. And, it made sense. Back then, latency wasn't a problem. However, it is no longer the case. With the advent of social media and live streaming, people now want content in real time. They don't want to wait much longer. Here, a delay of 30-50 seconds is simply unbearable.
It only makes sense that Apple (which maintains HLS) would eventually come up with an optimized solution for low latency streaming. So, they did! In 2019, at WWDC, Apple announced Low-Latency HLS or LL-HLS. It was built on top of existing HLS specifications with some modifications to achieve low latency (<5s). Let's take a look at how LL-HLS does this without compromising quality or compatibility:
How Does Low Latency HTTP Live Streaming (LL-HLS) Work?
LL-HLS makes some major changes to the existing HLS specification. These changes include:
1. HLS Partial Segments
In LL-HLS, segments are further divided into parts (HLS partial segments), which decrease individual file sizes. This makes it possible to start playback even before the entire segment is downloaded (as opposed to HLS where you have to wait for the complete segment).
2. Delta Playlist Update
The playlist is updated in LL-HLS with less transfer cost as compared to HLS. This is done by requesting the server to provide delta updates, which update the relevant portions of the playlist already available with the client.
3. Update Blocking
The HTTP GET request of a player can contain "Delivery Directives" in LL-HLS. These are special query parameters requesting a future segment in the playlist response. The server then blocks this request until the specified segment is available. It eliminates playlist polling and, as a result, frees up the server and network bandwidth.
4. Preload Hints
To further reduce latency, LL-HLS introduces preload hints. They are special tags in the playlist that tell the player to start fetching a segment even before it is required for playback. So, the segment can be played immediately without any delay when needed.
5. Rendition Reports
LL-HLS minimizes the number of roundtrips during bit-rate adaptation. This is done by adding EXT-X-RENDITION-REPORT tags for all media playlists in a multivariant playlist. These tags provide information, such as the last Media Sequence Number and Part currently in the Media Playlist. This way, the client can request required parts from the server without having to fetch an entirely new Media Playlist.
LL-HLS vs HLS: What's The Difference?
There are some key differences between them that you should know about before deciding which one is better for your use case.
Here are some differences and similarities between LL-HLS and HLS: