HLS, short for HTTP Live Streaming, is an adaptive bitrate streaming protocol that splits video into short media segments, describes them in text playlists, and delivers everything over ordinary HTTP. The player downloads the segments in sequence and switches between quality levels as network conditions change.
Introduced by Apple in 2009 and later published as RFC 8216, HLS became the most widely supported delivery format in streaming and broadcasting. It plays natively on iOS, macOS, tvOS, Safari and most smart TVs, and it plays in other browsers through Media Source Extensions. It serves both video on demand and live streams.
How HLS delivers video over HTTP
HLS works by turning a continuous stream into a sequence of small files that any web server or CDN can cache. An encoder or packager produces several renditions of the same content, cuts each one into segments, and writes playlists in the M3U8 format that point to those segments.
- The player requests the multivariant playlist (formerly called the master playlist), which lists every rendition with its bandwidth, resolution and codecs.
- It selects a rendition based on measured throughput and screen size, and requests that rendition’s media playlist.
- It downloads segments in order, keeps a buffer of several seconds, and decodes them.
- For live streams it reloads the media playlist periodically to discover new segments.
- When throughput rises or falls, it switches to another rendition at the next segment boundary.
Because switching happens only at segment boundaries, every rendition must have aligned keyframes: each segment starts with an IDR frame at the same timestamp in every rendition. Without alignment, switches cause visible glitches or decode errors.
Playlists, segments and key parameters
The behavior of an HLS stream is defined mainly by segment duration, rendition ladder and container format. The table lists the parameters engineers tune most often and what each one affects.
| Parameter | Typical value | What it affects |
|---|---|---|
| Target segment duration | 2-6 s (Apple recommends 6 s) | Latency, startup time, request overhead |
| Keyframe interval (GOP) | 1-2 s, dividing the segment evenly | Switching points and compression efficiency |
| Rendition ladder | 4-8 renditions, about 300 kbps to 15 Mbps | Quality range across networks and devices |
| Live playlist window | 3-10 segments or a longer DVR window | Rewind range and playlist size |
| Player start offset | About 3 target durations from the live edge | Live latency and stall resistance |
Segments were originally MPEG-2 Transport Stream (.ts) files. Current HLS also supports fragmented MP4 (fMP4 or CMAF), which allows HEVC, HDR and the same media files to be shared with MPEG-DASH. Codecs include H.264, HEVC and AV1 for video, and AAC, AC-3 and E-AC-3 for audio.
| Container | Strengths | Limitations |
|---|---|---|
| MPEG-2 TS | Maximum compatibility with older devices | Higher overhead, no single-file sharing with DASH |
| Fragmented MP4 (CMAF) | Lower overhead, HEVC and HDR, shared with DASH | Not supported by very old players |
| Packed audio | Lightweight audio-only streams | Audio only |
HLS compared with other streaming protocols
HLS is a delivery protocol for audiences, while several neighboring protocols in the Topic serve contribution or production. RTMP and SRT typically carry the feed from an encoder to the platform, which then repackages it as HLS for viewers. MPEG-DASH is the closest competitor, an ISO standard with similar adaptive behavior.
| Protocol | Main role | Typical latency | Transport |
|---|---|---|---|
| HLS | Delivery to viewers at scale | 6-30 s standard, about 2-5 s low latency | HTTP over TCP |
| MPEG-DASH | Delivery to viewers, open standard | Similar to HLS | HTTP over TCP |
| RTMP | Ingest from encoder to platform | About 2-5 s | TCP, persistent connection |
| SRT | Reliable contribution over the internet | Sub-second to a few seconds | UDP with retransmission |
| WebRTC | Interactive real-time video | Under 500 ms | UDP, peer or SFU based |
The main advantage of HLS is that it rides on standard web infrastructure: segments are cacheable files, so a CDN can serve millions of viewers without special streaming servers, and firewalls rarely block it.
Latency and low-latency HLS
Standard HLS latency is roughly three segment durations plus encoding and CDN delay, which commonly results in 15-30 seconds behind real time with 6-second segments. Shorter segments reduce latency but increase request overhead and reduce compression efficiency.
Low-Latency HLS (LL-HLS) addresses this without abandoning HTTP. It publishes partial segments of a few hundred milliseconds, uses blocking playlist reloads so the server answers only when new media exists, and adds preload hints so the player can request the next part early. Well-tuned LL-HLS deployments reach about 2-5 seconds of glass-to-glass latency.
Common HLS problems and their causes
Most HLS failures trace back to packaging inconsistencies or ladder design, not to the protocol itself. The table below pairs frequent symptoms with their causes.
| Symptom | Likely cause | Fix |
|---|---|---|
| Glitch at quality switches | Keyframes not aligned across renditions | Use fixed GOP and closed GOPs in every rendition |
| Frequent rebuffering | Ladder top too high, too few low renditions | Add lower rungs and cap bitrate per device |
| Live stream drifts far behind | Player starts too far from the live edge | Shorten segments or adopt LL-HLS |
| Playback fails on some devices | Unsupported codec or missing CODECS attribute | Declare codecs correctly, offer an H.264 fallback |
| Stale live playlist at the edge | CDN caches the playlist too long | Set short cache times for playlists only |
Content protection adds another layer: HLS supports AES-128 segment encryption and SAMPLE-AES with FairPlay DRM. Misconfigured key delivery is a common reason why a stream plays in testing but fails for real viewers.
A plain-language summary
HLS is a way to send video over the internet as many small pieces instead of one big file. Your phone or TV downloads a short piece, plays it, and fetches the next one, guided by a list that says where all the pieces are.
The clever part is that the same video exists in several qualities. When your connection is fast, the player picks sharp pieces; when it slows down, it switches to lighter ones so the picture keeps playing instead of freezing.
An example from practice
A regional broadcaster streams a live football match. The production truck sends a single SRT contribution feed at 20 Mbps to a cloud encoder, which produces six renditions from 1080p60 at 7.8 Mbps down to 360p at 600 kbps, with 2-second keyframe intervals aligned across all of them.
The packager writes LL-HLS with 4-second segments and 1-second partial segments in fragmented MP4, and a CDN serves around 180,000 concurrent viewers. Phones on mobile networks settle mostly on the 720p rungs, smart TVs on fixed broadband hold 1080p, and end-to-end latency stays near 4 seconds, close enough that viewers are not spoiled by score notifications arriving before the goal appears on screen.