Advantages of HLS Over Other Streaming Protocols

In a rapidly evolving digital landscape, a significant change was taking shape. As the internet flourished, so did the appetite for immersive multimedia experiences. People everywhere craved the ability to watch videos, listen to music, and dive into captivating stories, all accessible at their fingertips. However, this enthusiasm brought a challenge: Delivering smooth content across an ever-expanding range of devices.

In 2009, deep within the creative halls of Apple, a team of visionary engineers gathered to tackle this very issue. They understood that the future of entertainment relied on the ability to stream high-quality video and audio smoothly across different devices.

Inspired by this need, the engineers set out on a journey to create a new streaming protocol that could adapt to various network conditions and device capabilities. After months of collaboration and relentless brainstorming, in 2009 the team unveiled their groundbreaking creation: HTTP Live Streaming, or HLS. This revolutionary protocol was designed to deliver high-quality video, audio, and multimedia content over the internet, catering especially to devices running iOS, macOS, tvOS, and beyond.

Here is the diagram that illustrates how HLS works:

Comprehensive HLS block Diagram

To bring their vision to life, the engineers devised a clever method: they would break media content into smaller, manageable segments, each lasting between six to ten seconds. They decided that these segments would be saved in specific formats, choosing the robust .ts (MPEG-2 Transport Stream). Each of these files contained a portion of the media, waiting to be requested by eager viewers who craved entertainment.

Read More: Adaptive Video Streaming and HLS file structure

The master playlist includes the location of each specific media playlist in the stream. This relationship is illustrated in the image. Additionally, the master playlist offers key information like bandwidth, resolution, and codec. The player relies on this data to select the most suitable variant for the device and the currently available bandwidth.

To guide the audience through this segmented journey, the engineers created a special playlist file with the .m3u8 extension. This playlist acted as an index, listing all the media segments available for viewing. Within its lines lay the URLs that pointed to each segment, carefully categorized by different video qualities.

But that wasn’t all—the engineers crafted a master playlist that served as a grand map for the entire streaming adventure. This master playlist provided the addresses for each media playlist, ensuring that viewers could effortlessly navigate through the myriad of options available to them.

There are various streaming protocols like RTMP(Real-Time Messaging Protocol), RTSP (Real-Time Streaming Protocol), WebRTC (Web Real-Time Communication) and SRT (Secure Reliable Transport). Now, let’s explore why developers often choose to use HLS (HTTP Live Streaming).

Edge of HLS over other streaming protocols:

Apple uses HLS over other streaming protocols due to its native compatibility with Apple devices, adaptive bitrate streaming for smoother playback in varying network conditions, support for encryption and DRM, and simplicity of implementation through the .m3u8 format. Additionally, HLS is HTTP-based, making it firewall-friendly and easily scalable through existing content delivery networks (CDNs).

Control Over User Experience

HLS had a humble yet elegant guide known as the .m3u8 file. It was simple—a text-based extension of the traditional m3u format. Every line in the .m3u8 file told a clear story, representing a media segment or a different quality stream. Creators loved it because it was easy to read, modify, and debug. If something went wrong, they could quickly scan the file, adjust a few lines, and send it back on its way.

DASH, on the other hand, used a more complex map called the MPD file, written in the intricate language of XML. While powerful, the MPD was verbose and full of extra details that required special tools and extra effort to decode. For creators, manually editing or debugging DASH’s XML-based MPD files felt like navigating a dense forest—slower and more challenging compared to HLS’s straightforward path.

Read More: How to Play HLS Live Stream using ExoPlayer

Focus on HTTP-based Streaming

One of the most magical aspects of HLS was that it worked over HTTP, the same protocol used for browsing websites. This made it firewall-friendly, allowing streams to pass through networks without being blocked, and easily scalable using Content Delivery Networks (CDNs). No matter where users were, HLS ensured the content reached them quickly and reliably. Unlike protocols such as Real-Time Messaging Protocol (RTMP), which required dedicated infrastructure and lacked flexibility, HLS enabled Apple to streamline performance and reduce complexity, making content delivery more efficient and accessible.

Adaptive Bitrate Streaming

HLS had a natural compatibility with Apple’s devices, effortlessly blending into the ecosystem. But what truly enchanted the engineers was its ability to adjust on the fly. HLS used adaptive bitrate streaming, which meant that no matter how strong or weak the internet connection, the playback remained smooth. While non-adaptive protocols like Real-Time Messaging Protocol (RTMP) didn’t offer the same level of flexibility.

Security and DRM Integration

Security was another concern, and HLS came with built-in encryption and Digital Rights Management (DRM) to protect precious digital content. It was like placing a protective shield over every video, music file, and live stream, keeping them safe from unauthorized access. Even better, HLS was simple to implement, thanks to the .m3u8 format—a straightforward way to organize and deliver media files.

Compatibility with Modern Web Standards

As the digital world evolved, older protocols like Flash, RTMP, and RTSP became outdated. Recognizing this, Apple embraced HLS, optimized for the modern web and seamlessly integrated with HTML5 and open standards.

Seamless Integration with Apple’s Ecosystem

HLS seamlessly integrates across Apple’s devices, ensuring consistent media performance and optimization for proprietary hardware like A-series and M-series chips. This standardization prevents fragmentation from multiple streaming protocols, simplifying development and enhancing reliability across Apple’s ecosystem.

HLS supports Low-Latency Streaming

To meet the demand for real-time content, Apple introduced Low Latency HLS (HLS LL), shrinking the delay between broadcast and playback. This made HLS a perfect fit for live sports, events, and real-time interactions. With this enhancement, Apple kept HLS competitive against other low-latency protocols like WebRTC, reinforcing its commitment to delivering cutting-edge, real-time streaming experiences for its users.

Read More: Load Testing HLS Stream Using JMeter

How the HLS-MasterPlaylist (.m3u8) does look likes

For sample HLS URL “http://qthttp.apple.com.edgesuite.net/1010qwoeiuryfg/sl.m3u8”, below is the available “media playlist”. You can see that this “master playlist“ had 8 different “media playlists” references.

Media Manifest File (.m3u8)

In the above image, the “#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=688301”is part of an HLS playlist (.m3u8) and provides metadata about a specific variant stream in an adaptive bitrate streaming setup. Here’s a breakdown of its components:

• #EXT-X-STREAM-INF: This tag indicates that the following URL in the playlist points to a variant stream with specific attributes.
• PROGRAM-ID=1: This parameter identifies the program to which this stream belongs. If multiple programs are present in the playlist, this ID helps distinguish them.
• BANDWIDTH=688301: This parameter specifies the average bitrate of the stream in bits per second. In this case, the stream has a bandwidth of approximately 688 kbps. This value is crucial for adaptive bitrate streaming, allowing the player to select the appropriate stream based on the user’s available bandwidth.

If we examine the initial playlist file, it would appear as follows:

transport streams (.ts) for a specific bandwidth

In the above image:

• #EXTM3U: indicates the start of the file.
• #EXTINF: provides information such as track duration and channel name.
• #EXT-X-TARGETDURATION: defines the maximum duration (in seconds) of any media segment in the playlist.
• #EXT-X-MEDIA-SEQUENCE: specifies the sequence number of the first media segment in the playlist. This sequence number increases as new segments are added, especially in live-streaming scenarios.
• #EXTINF: This tag typically includes metadata about a track, such as its duration and title.
• #EXT-X-ENDLIST: It indicates the end of a playlist. When a player encounters this tag, It knows that there are no more segments to be played, which is especially relevant for “on-demand” playlists.

In the above image, there are 535 transport Streams (.ts) for the first media playlist. these 535 .ts files are 10 seconds longer, So the content length would be (535*10) / 60 = 89.16 min = 1 hour 29 seconds (in duration)

Conclusion

HLS is favored for its wide device compatibility, adaptive bitrate streaming, scalability, and ability to handle fluctuating network conditions while offering strong security features. While its initial higher latency was a drawback, the advent of low-latency HLS (LL-HLS) has made it competitive even for real-time live streaming.

Depending on the use case, such as live events, global-scale streaming, or on-demand video, HLS often outperforms or is more practical than other streaming technologies like RTSP, RTMP, or even WebRTC.