What is HLS? HTTP Live Streaming Explained

HTTP Live Streaming (HLS) is an adaptive bitrate streaming protocol developed by Apple that delivers video over ordinary HTTP as a sequence of small, cacheable file segments. Introduced in 2009 alongside the iPhone 3GS, HLS was designed so video could survive flaky mobile networks by breaking streams into short pieces and letting the player adjust quality on the fly. Today it is the most widely supported streaming protocol in the world—native in Safari and iOS, and supported by every major browser, smart TV platform, and player SDK through libraries like hls.js.

That universal reach is why HLS sits at the core of delivery at Videospan: every video our platform renders is published as an adaptive HLS stream, because it's the one protocol guaranteed to play on whatever device a viewer picks up—no installs, no exceptions.

A brief history explains HLS's design choices. Apple shipped it in 2009 as part of iPhone OS 3, when mobile connections were slow and unreliable and single-bitrate progressive download was the norm. The company submitted the specification to the IETF, where it circulated for years as an Internet-Draft before publication as the informational RFC 8216 in 2017. Two later milestones shaped the modern protocol: at WWDC 2016 Apple added support for fragmented MP4 segments alongside the original MPEG-TS—laying the groundwork for CMAF—and in 2019 it announced Low-Latency HLS, a set of extensions (partial segments, blocking playlist reloads, preload hints) that cut live latency from tens of seconds down to roughly two or three. The LL-HLS extensions were folded into the second edition of the specification in 2020, and every Apple device shipped since supports them.

How HLS works

HLS follows the standard HTTP adaptive streaming pattern, with two levels of playlists coordinating everything:

1. Encode and segment. The source video is encoded into multiple renditions (say 240p up to 4K), and each rendition is split into short segments—classically 6 seconds, often 2–4 seconds today. Segments were originally MPEG-TS files; since 2016, fragmented MP4 (fMP4) is also supported.
2. Publish a media playlist per rendition. Each rendition gets its own .m3u8 media playlist listing its segment URLs in order.
3. Publish a master playlist. A master .m3u8 lists all the renditions with their bandwidth, resolution, and codec requirements, so the player knows its options before downloading a single frame of video.
4. The player picks and adapts. On startup the player reads the master playlist, picks a rendition it can handle, and starts fetching segments. It continuously measures download speed and buffer depth, switching renditions at segment boundaries when conditions change.
5. For live streams, the playlist updates. A live media playlist is a moving window: new segments appear at the end, old ones scroll off, and the player re-fetches the playlist every few seconds to stay near the live edge.

Because every segment is a plain HTTP object, CDNs cache them like any static file—which is why a single HLS origin can serve millions of viewers.

Anatomy of an HLS stream

An HLS stream is just text playlists pointing at media files. A master playlist looks like this:

#EXTM3U
#EXT-X-VERSION:7

# 1080p, ~5 Mbps
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080,CODECS="avc1.640028,mp4a.40.2"
hd/playlist.m3u8

# 720p, ~2.8 Mbps
#EXT-X-STREAM-INF:BANDWIDTH=2800000,RESOLUTION=1280x720,CODECS="avc1.64001f,mp4a.40.2"
sd/playlist.m3u8

# 360p, ~800 Kbps
#EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360,CODECS="avc1.4d401e,mp4a.40.2"
low/playlist.m3u8

Each #EXT-X-STREAM-INF line advertises one rung of the bitrate ladder. The CODECS attribute lets players reject renditions they can't decode before wasting bandwidth.

The media playlist each entry points to lists the actual segments:

#EXTM3U
#EXT-X-VERSION:7
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:1042
#EXT-X-PLAYLIST-TYPE:VOD
#EXTINF:6.006,
seg-1042.ts
#EXTINF:6.006,
seg-1043.ts
#EXTINF:4.170,
seg-1044.ts
#EXT-X-ENDLIST

#EXT-X-TARGETDURATION declares the maximum segment length, #EXT-X-MEDIA-SEQUENCE anchors the sliding window for live, and #EXTINF gives each segment's exact duration. #EXT-X-ENDLIST marks a finished (VOD) stream; live playlists omit it and keep growing.

How Videospan uses HLS

Every video that leaves our rendering pipeline—a branded executive recording, an AI-assisted edit, a repurposed short clip—gets packaged into an HLS bitrate ladder. Renditions run from low-bandwidth profiles suited to a phone on a weak connection up to high-quality HD for large screens, and the player moves between them automatically as network conditions change. A viewer doesn't stall because the office Wi-Fi got busy; the stream simply steps down a rung and climbs back up.

We lean on HLS's universal reach for a simple reason: enterprise audiences are device-heterogeneous. The same town hall replay has to play in Safari on an iPhone, Chrome on a Windows laptop, and a conference-room display—without anyone installing anything. HLS is the only protocol that makes that guarantee, and because its segments are plain HTTP objects, they cache on standard CDNs, so a video published once is immediately close to viewers in every region.

For live and time-sensitive communications, LL-HLS's partial segments and blocking playlist reloads bring latency down to a few seconds—close enough for interactive all-hands meetings and launches—while staying on the same standards-based HTTP infrastructure as on-demand delivery. One stack serves both, which is exactly how we run it.

HLS vs DASH and CMAF

In practice, most platforms ship both: HLS for Apple devices, DASH for Android and the open web, and CMAF segments so the two share one encode and one CDN cache.

Advantages

• Universal reach. HLS is the only protocol with native support in Safari and iOS, and it plays everywhere else via mature libraries.
• CDN-friendly by design. Segments are ordinary HTTP files—no special server software required, trivial to cache and scale.
• Proven resilience. Two decades of production hardening; edge cases (ad insertion, DVR windows, DRM rotation, failover) are well understood.
• LL-HLS is a real upgrade. Apple's 2019 low-latency extension—partial segments (#EXT-X-PART), preload hints, and blocking playlist reloads—brings live latency down to roughly 2–3 seconds while staying plain HTTP.
• CMAF-compatible. fMP4 segments let one encode serve HLS and DASH audiences simultaneously.

Limitations

• Classic latency is high. With 6-second segments and a buffer of a few segments, 18–30 seconds of glass-to-glass delay is common—unacceptable for auctions, betting, or interactive events without LL-HLS.
• LL-HLS has server and CDN requirements. Blocking playlist reloads and HTTP/2 push-style delivery need explicit CDN support, and not every vendor's implementation is complete.
• MPEG-TS legacy. Older HLS deployments still ship TS segments, which don't interop with DASH and carry slightly more overhead than fMP4.
• Not truly real-time. Even at its best, LL-HLS won't hit the sub-second latency of WebRTC.

When to use HLS

Use HLS whenever reach matters more than anything else—which, for most organizations, is always. If you're delivering executive town halls, product launches, marketing videos, or training content to a mixed audience of iPhones, laptops, and conference-room TVs, HLS is the one format guaranteed to play everywhere. Enterprise branded-video platforms typically originate in HLS (often with CMAF segments) for exactly this reason: no viewer ever needs to install anything.

Reach for LL-HLS when you need live interaction at scale—Q&A sessions, live shopping, sports—where 2–3 seconds is close enough and audience size rules out WebRTC. If your application genuinely needs sub-second latency (video conferencing, remote production), HLS is the wrong tool entirely; that's WebRTC territory.

If you're evaluating a video platform, HLS makes a useful litmus test. Ask how the platform delivers video to your lowest-bandwidth offices and to your executives' iPhones—if the answer involves a plugin, a mandatory app, or a single fixed-quality file, the delivery layer isn't adaptive. Ask whether live events run on LL-HLS or a proprietary protocol, and whether the same infrastructure serves both on-demand and live, or two stacks you'll end up paying for separately.

Glossary

Master playlist

The top-level .m3u8 file that lists every available rendition with its bandwidth, resolution, and codec requirements.

Media playlist

The .m3u8 file for a single rendition, listing that rendition's segments in playback order.

Segment

A short, self-contained chunk of media—typically 2 to 6 seconds—that players download sequentially over HTTP.

MPEG-TS— MPEG Transport Stream

The original HLS segment container, inherited from broadcast. Still common, though fMP4 has largely replaced it in modern workflows.

fMP4— Fragmented MP4

An MP4 variant split into movie fragments, allowing playback to start before the whole file downloads and enabling CMAF sharing with DASH.

LL-HLS— Low-Latency HLS

Apple's 2019 extension to HLS that delivers ~2–3 second live latency using partial segments and blocking playlist reloads.

Partial segment

A fraction of a full segment (as short as ~200 ms) announced via #EXT-X-PART, letting players start downloading before a segment is complete.

Blocking playlist reload

An LL-HLS mechanism where the player asks the server to hold a playlist request until a specific segment or part is available, eliminating polling delay.

Live edge

The most recently published point in a live stream. Players aim to stay a few segments behind it to keep a healthy buffer.

Frequently asked questions

Related

• Video Streaming Protocols: HLS, DASH & CMAF Explained
• What is MPEG-DASH?
• What is CMAF?