HLS: What It Is, Protocol and How It Works

What Is HLS?

HTTP Live Streaming (HLS) is a media streaming protocol developed by Apple in 2009 and first introduced in iOS 3.0 and Safari. In 2017, the protocol was proposed as an internet standard through RFC 8216, confirming its status as an open specification available for implementation on any platform.

The main idea of HLS is to split a continuous media stream into short segments lasting 2–10 seconds. Each segment is an independent file that can be downloaded via a regular HTTP request. Stream management is done through text playlists in M3U8 format, which contain references to segments and metadata for their correct playback.

Adaptivity is the key advantage of HLS. The server prepares multiple versions of the same content at different bitrates — from 200 Kbps for weak connections to 20+ Mbps for 4K video. The client automatically selects the appropriate bitrate based on current channel bandwidth. According to Apple research (WWDC 2024), LL-HLS reduces the time for switching between bitrates to 500 milliseconds, ensuring smooth quality changes without noticeable pauses.

History of HLS Development

The first version of HLS (2009) supported only MPEG-2 TS segments with AAC audio codec and H.264 video codec. iOS 8 (2014) added support for fMP4 (fragmented MP4) segments, enabling HLS to work with more modern codecs, including HEVC (H.265). iOS 11 (2017) introduced support for HDR10 and Dolby Vision. iOS 13 (2019) introduced Low-Latency HLS, reducing latency from the traditional 6–30 seconds to 2–6 seconds.

In 2023, Apple expanded HLS with support for AV1 and EVC (Essential Video Coding) codecs, and also introduced Content Steering — a mechanism for dynamically redirecting clients between CDN servers for optimal load balancing. Content Steering allows the server to change segment URLs on the fly, redirecting the client to the nearest or least loaded CDN node without interrupting playback.

How Does HLS Work?

The HLS architecture consists of three main components: the server side (origin server + encoder), the distribution network (CDN), and the client side (player with HLS support). The entire process — from video capture to playback on the user’s device — involves several sequential stages, each critical for streaming quality.

Encoding and Segmentation

The source video is first encoded into multiple variants at different bitrates and resolutions. Professional encoders, such as FFmpeg or AWS Elemental MediaConvert, simultaneously create 4–12 stream variants: from 240p (400 Kbps) to 4K (40 Mbps). Each variant is split into segments of equal duration, typically 2–6 seconds for LL-HLS or 6–10 seconds for traditional HLS.

For each variant, a variant playlist is created containing the URLs of all segments and their duration. Additionally, a master playlist is created that combines all variants and contains information about each one: resolution, bitrate, codec, and audio tracks. The client loads the master playlist first, then selects the appropriate variant based on connection speed analysis.

Delivery via CDN

Segments and playlists are cached on CDN servers located geographically close to users. Using standard HTTP protocol for delivery gives HLS a critical advantage: any CDN, load balancer, or proxy server that supports HTTP works with HLS without additional configuration. This distinguishes HLS from real-time protocols such as RTMP or WebRTC, which require specialized servers.

import subprocess

subprocess.run([
    "ffmpeg",
    "-i", "input.mp4",
    "-codec:v", "libx264",
    "-codec:a", "aac",
    "-hls_time", "6",
    "-hls_list_size", "0",
    "-var_stream_map", "v:0,a:0 v:1,a:1",
    "-map", "v:0", "-b:v:0", "5000k",
    "-map", "v:1", "-b:v:1", "1000k",
    "-f", "hls",
    "stream/output.m3u8"
])

The client side uses an adaptive bitrate algorithm (ABR). The HLS player loads the master playlist, analyzes available variants, and starts playback at the most suitable bitrate. During playback, the player constantly monitors segment download speed and buffer fill level, deciding whether to switch to a higher or lower bitrate. Modern ABR algorithms consider not only network speed but also buffer size, content type, and even device power consumption.

HLS Stream Structure: Playlists and Segments

Understanding the structure of an HLS stream is necessary for correctly configuring encoding, distribution, and debugging playback issues. Each HLS stream consists of two levels of playlists and numerous media segments organized in a strict hierarchy.

Master Playlist

The master playlist is the entry point for the HLS player. The file with the .m3u8 extension contains references to all stream variants and their characteristics. The player loads this file first and, based on information about bitrates and resolutions, makes the initial decision about which variant to select. The master playlist may also contain references to alternative audio tracks, subtitles, and I-Frame playlists for fast seeking.

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080
1080p/video.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1000000,RESOLUTION=640x360
360p/video.m3u8

Media Playlist

The media playlist contains the actual list of segments for one stream variant. Each segment is specified with its duration and URI. The media playlist can be static (for VOD — a complete list of all segments) or dynamically updated (for live broadcasts — old segments are removed, new ones are added).

#EXTM3U
#EXT-X-TARGETDURATION:6
#EXTINF:6.000,
segment001.ts
#EXTINF:6.000,
segment002.ts
#EXT-X-ENDLIST

Segment Formats

HLS supports two main media segment formats: MPEG-2 Transport Stream (.ts) and Fragmented MP4 (.m4s or .mp4). MPEG-2 TS is the original HLS format, providing maximum compatibility. fMP4 is a more modern format supporting HDR, HEVC, and more efficient compression. Apple recommends fMP4 for all new projects starting from iOS 10 and macOS Sierra.

Additional HLS stream elements include I-Frame playlists for fast seeking, ID3 metadata for synchronizing subtitles and ad markers, and Session Data for transmitting viewing information to analytics servers. All these elements are optional, but their use improves the quality of the user experience.

Advantages and Disadvantages of HLS

HLS dominates the video streaming market thanks to several architectural advantages, but it also has limitations that must be considered when choosing a protocol for a specific project. Let’s compare HLS with alternative video delivery protocols.

The main advantage of HLS is native support on all Apple devices (iPhone, iPad, Apple TV, Mac) through the built-in AVPlayer. This makes HLS the de facto standard for iOS/macOS applications. Additionally, using standard HTTP for delivery allows content to be cached on any CDN and proxy servers without additional configuration, which significantly simplifies the delivery infrastructure.

Disadvantages of HLS include higher latency compared to RTMP or WebRTC for live broadcasts. Even with LL-HLS, the minimum latency is 2–6 seconds, which is unacceptable for real-time interactive scenarios. Also, HLS generates more files on the server (each segment is a separate file), which can create load on the file system with a large number of simultaneous streams.

HLS in Mobile Applications

Integration of HLS into mobile applications differs depending on the platform. On iOS and macOS, HLS is supported at the operating system level through AVFoundation and AVPlayer, providing hardware-accelerated decoding and minimal power consumption. On Android, HLS is not supported by the built-in MediaPlayer but is available through ExoPlayer — Google’s official media player.

HLS on iOS via AVPlayer

On the Apple platform, HLS playback is as simple as possible thanks to built-in support in AVPlayer. Simply create an AVPlayer with the master playlist URL, and the system automatically handles adaptive bitrate switching, audio track selection, and subtitle processing. The developer also gets full control over playback through AVPlayerItem and AVAssetResourceLoader.

import AVFoundation

let url = URL(string: "https://example.com/stream.m3u8")!
let player = AVPlayer(url: url)
let controller = AVPlayerViewController()
controller.player = player
present(controller, animated: true) {
    player.play()
}

HLS on Android via ExoPlayer

For Android, ExoPlayer is used, which supports HLS through a separate extension module. ExoPlayer provides finer control over the HLS stream: you can manage bitrate selection, configure buffering, and handle segment loading errors individually. LL-HLS requires ExoPlayer version 2.14.0 or higher.

val player = ExoPlayer.Builder(this).build()

val uri = Uri.parse("https://example.com/stream.m3u8")
val mediaItem = MediaItem.fromUri(uri)

player.setMediaItem(mediaItem)
player.prepare()
player.play()

Optimizing HLS for Mobile Networks

Mobile applications require a special approach to HLS configuration due to the instability of cellular networks and traffic limitations. Key recommendations include: configuring the initial bitrate based on network type (Wi-Fi or cellular), using shorter segment durations (2–4 seconds) for faster adaptation, pre-loading the buffer when switching to Wi-Fi, and prioritizing the audio track on weak signals.

Apple in the HLS Authoring Specification for Apple Devices (2024) recommends using a segment size of no more than 6 seconds for mobile devices and at least 4 bitrate variants. To save traffic on mobile networks, the server should deliver segments with the Cache-Control HTTP header, allowing content to be cached on intermediate proxy servers of telecom operators.