%20(1).webp)
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.
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.
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.
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.
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:
LL-HLS makes some major changes to the existing HLS specification. These changes include:
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).
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.
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.
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.
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.
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:
As we've seen, the biggest difference between LL-HLS and HLS is latency. With LL-HLS, Apple has managed to reduce it significantly (to sub-5 seconds) as compared to regular HLS (which has a latency of around 30 seconds. This latency is even lower than the latency in HD cable TV streaming. As a result, LL-HLS gives users a near-real-time viewing experience and should be prioritized if latency is important for a given use case.
There is no noticeable difference in quality between LL-HLS and HLS streams. Both provide high-quality video streaming at scale. However, LL-HLS is not the best for low network bandwidth conditions.
One of the best things about both HLS and LL-HLS is their compatibility with all major browsers and devices. Some of the popular browsers that support LL-HLS include AVPlayer (iOS), Exoplayer (Android), THEOPlayer, JWPlayer, HLS.js, VideoJS, and AgnoPlay. So, unlike other protocols, you don't have to worry about whether your viewers will be able to watch your stream or not.
The deployment of a regular HLS is cheaper than LL-HLS.
Implementing LL-HLS is more complex than HLS because of its additional features (like preload hints and rendition reports). So, you'll need to have a good understanding of how it works before you can implement it.
Now, let's look at some advantages and disadvantages of using LL-HLS for low latency streaming:
The advantages of using LL-HLS for low latency streaming include:
As it is clear from its name, LL-HLS was designed with latency in mind. The streaming protocol delivers a near-real-time, glass-to-glass viewing experience. In certain scenarios, using LL-HLS, a latency of <2 seconds can also be achieved. This makes it ideal for live streams, such as live sports, news, game streaming, etc. where every second matters.
Another advantage of using LL-HLS is that it doesn't sacrifice quality for latency. It uses the same codecs (like H.264 and H.265) as regular HLS and provides a high-quality video streaming experience under the desired network conditions.
The challenge with most streaming protocols, especially the ones involving low latency, is that they are hard to scale. This is not the case with LL-HLS. It builds upon HLS and uses standard HLS packaging, which makes it considerably easy to implement and scale. As a result, you can engage thousands of concurrent users without any hassle.
One of the best things about LL-HLS is that it is compatible with all major browsers and devices, including iOS, Android, macOS, Windows, tvOS, and so on. This compatibility makes it possible to reach a larger audience with your live streams without having to worry about whether they will be able to watch it or not.
LL-HLS is a new streaming protocol and hence, doesn't enjoy as extensive support as its predecessor. This can make it difficult to find certain information or troubleshoot problems that you might face during deploying the protocol.
Another disadvantage of using LL-HLS is that its implementation is more complex as compared to regular HLS because of its additional features. Apart from major workarounds that are already mentioned, LL-HLS has several optimizations that can at times become quite overwhelming.
The cost involved in implementing LL-HLS is also higher than regular HLS because of the extra infrastructure required for low latency streaming. However, this cost is worth it if your use case demands real-time content delivery.
Although LL-HLS is often also compared with WebRTC, its only fair comparison is with LL-DASH.
Here's a quick comparison of the two streaming protocols:
LL-HLS uses HTTP Live Streaming (HLS) which is a proprietary Apple protocol, while LL-DASH uses the open standard Dynamic Adaptive Streaming over HTTP (DASH).
LL-HLS is designed specifically for Apple devices. However, since it's backward compatible with HLS players, it enjoys cross-platform and cross-device support as well. LL-DASH is not supported by Apple devices.
The latency of LL-HLS and LL-DASH is comparable. However, depending on the use case and computation required, either of them can have higher or lower latency.
While LL-HLS "parts" are individually addressable (as tiny files or byte ranges in the entire segment), LL-DASH "chunks" (or "fragments") are not. This means that in LL-DASH, the client doesn't have to wait for the server to completely encode the segment before sending the preceding chunks across.
In HLS as well as DASH protocol, the client polls the server at regular intervals (say 10 seconds) to check for updates in order to fetch new content. However, it is possible to achieve playlist update without any polling from clients in both LL-HLS and LL-DASH. While LL-HLS does so with its Delivery Directives (_HLS_msn=<M>, _HLS_part=<N>, & _HLS_skip=YES|v2), LL-DASH does not depend on manifest update for a player to make sense of a new chunk.
.webp)
In both LL-HLS and LL-DASH protocols, content protection uses MPEG-CENC (Common Encryption) standards. Both of these protocols also have support for Common Media Application Format (CMAF.) In terms of codecs, while LL-DASH is codec-agnostic, LL-HLS only allows specific codecs for encoding.
Both protocols offer adaptive bitrate streaming. They help players automatically switch between multiple renditions based on changing network conditions without interrupting playback experience for viewers. However, LL-HLS is different in that it has multiple streams for different bitrates and resolutions. LL-DASH only has one stream for a particular bitrate and resolution.
One more advantage that LL-HLS has over LL-DASH is related to content protection mechanism i.e., how do you know if your encoder produced an encrypted file with valid signatures? In order to check this, HLS protocol uses EXT–X–KEY tags whereas DASH relies on PSSH boxes inside MP4 files or separate init segments outside of MP4s called xlinks – both methods require extra network roundtrips which can introduce significant delays during live streaming events. To address this issue and make things simpler & efficient, Apple came up with a solution where it included KEY ID & IV values directly into m3u8 playlist so that players could validate those before downloading any segment – no extra request/response needed!
LL-HLS is a great choice for low-latency streaming if you are looking for a protocol that is compatible with all major browsers and devices. However, it is important to keep in mind that its implementation is more complex as compared to regular HLS.
In case you need any help, feel free to reach out to us.
Enjoyed this read?