HTTP Live Streaming (HLS) is a widely used streaming protocol that delivers media files in small chunks over HTTP so that they can be continuously viewed. HTTP enables many modern devices that support and understand HTTP to access live-streaming media files.
Initially, Apple developed HLS as a replacement for its QuickTime streaming server. Before HLS, streaming media over the internet entailed user diagram protocols (UDP) and proprietary services such as QuickTime or Adobe Flash.
However, firewalls can easily block UDP and struggle with limited error checking. Similarly, because QuickTime used nonstandard ports for streaming content, it also encountered firewall obstacles. Flash incurred a different set of problems, as it required a plugin to be installed and contained numerous design flaws that compromised its security.
HLS overcame these issues because it was designed to work natively over HTTP and, therefore, more straightforward. As devices and browsers were already familiar with HTTP, HLS required neither a dedicated server nor a proprietary service to deliver content.
HLS works by breaking media files into small chunks so that a client device can stream them. The client can then continuously play these chunks and append new ones to the end to deliver an uninterrupted stream.
A crucial benefit of HLS is that it can respond to changes in transfer speeds and adjust the quality of the streamed media accordingly. This enables the stream to continue — albeit at a lower quality — if transfer speeds drop. Then, it can increase the quality once transfer speeds have recovered.
The architecture of HLS can be broken down into three sections: server, distributor, and client. This section will examine each part of the architecture and explore how it works.
The server prepares raw media files for distribution. This can involve one or two steps, depending on the media type. If a media file has already been created and stored digitally — such as a pre-recorded movie — the server needs to break that file up into smaller chunks to be distributed to the client.
For live media, an extra step is required. As the media is being recorded, the server must first digitally encode the data into a suitable format before breaking it into distributable parts.
The distributor is a webserver that takes the fragmented media files from the server and delivers them to a client over HTTP. The web server usually serves up a website or application that, when accessed over HTTP, can begin receiving the media files. These files are typically fragmented MPEG-4 files.
In addition to the media files, the webserver sends a playlist file that details the names of each of the file chunks and alternative versions with various qualities. We’ll explore this in greater detail later.
The client usually takes the form of a webpage or application that decides which media should be requested and when to start streaming. For example, selecting a movie using the Apple TV client sends a request to the webserver with details about the file we want to stream. The server then starts breaking the file up to prepare it for distribution.
The client is then responsible for downloading these chunks and stitching them together to deliver a continuous stream. The files are downloaded sequentially, and a few of them typically buffer before the stream begins. This ensures that the stream will continue without interruption.
HLS introduced several new features that previous streaming technologies could not deliver, leading to its rise in popularity. Perhaps its most significant feature is its adaptability.
HLS encodes video files in several bitrates. This means that there are multiple versions of the video chunks available in different qualities at any time.
The playlist file contains the filename of each chunk sequentially alongside different quality versions of that same chunk. Whether the end-user has a 2G connection, high-speed Wi-Fi, or anything in between, the client can choose an appropriate stream quality to enable continuous streaming.
The lower the bitrate, the smaller the file chunks, and the faster the client can download them.
Furthermore, the client can perform this process whenever the connection speed changes partway through a stream. It detects the speed decrease and requests the lower bitrate versions of upcoming chunks.
The playlist file that accompanies the media files provides an additional benefit. It allows advertisement insertion at any part of the stream by simply stating that the next chunk to fetch should be from an advertisement file instead of the primary content. The stream then resumes as normal once the advertisement finishes.
This becomes even more powerful for advertisers as the playlist file can be localized to the specific user or country of playback. Therefore, advertisements can be region- or user-specific.
Finally, HLS features extremely low latency. This may surprise those familiar with early versions of the technology because HLS was known to prioritize reliability over low latency. However, two versions of a newer low-latency HLS protocol have overcome the need to prioritize one over the other. Apple produced one of these new versions, while the second is a community-driven project.
The goal of this innovation was to reduce the latency between a client request for a live stream and the stream starting to play. For example, someone watching a live sporting event now sees the action closer to real-time.
Developers achieved this reduction via multiple optimization techniques. One method was to send only the differently rated chunks when changing files. Low latency HLS also added metadata to all bitrate renders, which increases the speed of alternating between different bitrate streams.
Due to these features, HLS is now implemented across multiple applications and clients. Naturally, all Apple products and applications support HLS. Most major web browsers like Chrome, Firefox, and Edge also support HLS.
Dynamic Adaptive Streaming over HTTP (DASH) is an adaptive bitrate streaming solution similar to HLS. DASH was developed as an official international standard by MPEG to enable high-quality and accessible streaming over HTTP. It works similarly to HLS in that it breaks files into chunks to allow dynamically swapping between bitrates based on connection speed.
The main benefit of DASH is that it is an international standard. Therefore, in contrast with a corporate, proprietary solution like Apple’s HLS, it is universally available. As a result of its design that favors open availability, it is codec agnostic. DASH can support it regardless of which codec was used to store the media.
DASH can take advantage of more efficient codecs, providing better quality streams at lower bitrates. However, HLS now supports the HVEC/H.265 codec, placing it on par with DASH. Both solutions can deliver 4K HDR content, making them optimally suitable for modern streaming solutions.
As HLS has adapted to decrease its latency and expanded support for more streamlined codecs, the speed and quality of both solutions are relatively comparable. HLS is usually preferred to DASH because Apple devices do not support DASH.
This demonstrates Apple’s influence over how technology is adopted. Apple’s refusal to support an international standard and its considerable market share means most new services will likely implement HLS first. The higher priority continues to be ensuring that these services work natively on Apple devices.
HTTP Live Streaming (HLS) is an adaptive bitrate streaming solution that breaks live or large media content into small chunks to enable continuous streaming. By providing multiple bitrate versions of the stream, client applications can shift between quality levels to ensure that the stream remains uninterrupted.
Dynamic Adaptive Streaming over HTTP (DASH) was built as an international standard to expand HTTP streaming outside of the confines of Apple’s HLS. It provides comparable functionality to that of HLS and works similarly. That said, its codec-agnostic structure is its principal advantage.
