HLS vs MPEG-DASH: how adaptive streaming protocols work
HLS vs MPEG-DASH: how both use segments, manifests and adaptive bitrate, how CMAF lets them share files, and which devices support which.
In this article
- The shared idea: segments, manifests and adaptive bitrate
- HLS in brief
- MPEG-DASH in brief
- CMAF: one set of files for both
- HLS vs MPEG-DASH at a glance
- Common misconceptions
- What this means when something goes wrong
- Questions people ask
- Glossary
- Where HLS and DASH are heading
- Key takeaways
- Which one should a service use?
Almost every stream you watch on a phone, smart TV or browser is delivered with one of two protocols: HLS (HTTP Live Streaming) or MPEG-DASH (Dynamic Adaptive Streaming over HTTP). Both solve the same problem: delivering video smoothly over unpredictable internet connections, using ordinary web servers and CDNs. This guide compares HLS vs MPEG-DASH in plain English.
The shared idea: segments, manifests and adaptive bitrate
HLS and DASH work in broadly the same way:
- Encode several versions of the video at different resolutions and bitrates. This set of versions is called a bitrate ladder.
- Cut each version into short segments, typically a few seconds long.
- Publish a manifest, a text file that lists the available versions and where their segments are.
- Let the player choose. The player downloads the manifest, measures how fast segments arrive and picks the best version the connection can sustain. It can switch at segment boundaries.
This approach is called adaptive bitrate streaming (ABR). Because segments are ordinary files fetched over HTTP, they can be cached by CDNs like any other web content. That is a big reason the approach scales to millions of viewers.
A closer look at the bitrate ladder
A bitrate ladder is the set of versions a service encodes for each video. A simplified ladder might look like this:
| Rung | Resolution | Approximate bitrate |
|---|---|---|
| 1 | 416×234 | under 0.5 Mbps |
| 2 | 640×360 | ~0.8 Mbps |
| 3 | 960×540 | ~1.5–2 Mbps |
| 4 | 1280×720 | ~3 Mbps |
| 5 | 1920×1080 | ~5–6 Mbps |
| 6 | 3840×2160 | ~15+ Mbps |
Illustrative values only. Real ladders vary by codec, content and service.
Modern services increasingly use per-title or content-aware encoding: an animated series with flat colours needs far less data than a grainy action film, so each title gets its own ladder. That's one reason two services can look different at the same resolution.
How the player decides
Adaptive players balance several signals:
- Measured throughput: how quickly recent segments arrived
- Buffer level: how many seconds of video are already downloaded
- Screen size and device capability: there's no point fetching 4K for a phone screen
- Stability: avoiding constant switching, which is more noticeable than a slightly lower steady quality
When your picture briefly turns soft at the start of a film and then sharpens, you're seeing the player start conservatively and climb the ladder as it confirms your connection can sustain more.
HLS in brief
- Created by Apple in 2009 and later published by the IETF as RFC 8216.
- Manifests are
.m3u8playlists. A main ("multivariant") playlist points to media playlists for each quality level. - Segments were originally MPEG transport stream (
.ts) files. Modern HLS also supports fragmented MP4 (fMP4). - Native on Apple devices and widely supported elsewhere, including smart TVs and Android through libraries.
- Low-Latency HLS (LL-HLS) adds partial segments and other features to cut live delay.
A simplified multivariant playlist looks like this:
#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=2500000,RESOLUTION=1280x720
720p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=6000000,RESOLUTION=1920x1080
1080p/index.m3u8
MPEG-DASH in brief
- An international standard (ISO/IEC 23009-1) developed through MPEG, with interoperability guidelines from the DASH Industry Forum.
- Manifests are XML Media Presentation Description (
.mpd) files, which can describe complex streams with multiple periods, audio languages and subtitles. - Codec-agnostic: DASH doesn't mandate a particular video codec. See video codecs explained.
- Widely used on Android, smart TVs and in browsers through the Media Source Extensions API.
Segments, playlists and live streams
For on-demand video, the media playlist lists every segment from start to finish. For live streams, the playlist is a sliding window: the server keeps adding new segments at the end and removing old ones from the start, and the player reloads the playlist to discover new segments. Some services keep a longer window to allow viewers to pause or rewind live TV, a feature often called "start-over" or "DVR window."
CMAF: one set of files for both
Historically, a service supporting both HLS and DASH had to store and cache two copies of every segment. The Common Media Application Format (CMAF) standardizes fragmented MP4 segments that both protocols can reference. A service can then publish one set of media files with two small manifests, an .m3u8 and an .mpd, which cuts storage and CDN costs.
CMAF also enables chunked transfer, where a segment is delivered in small pieces while it's still being encoded. That's a building block for low-latency live streaming.
Encryption and DRM in both formats
Both formats support encryption. Segments are encrypted during packaging, and the manifest tells the player which DRM systems can provide keys. With CMAF and the common encryption scheme, a single set of encrypted segments can be decrypted by Widevine, PlayReady or FairPlay, depending on the device. Our DRM explainer covers this in more detail.
Subtitles and audio tracks
Both formats can carry multiple audio languages, audio description tracks and subtitles as separate renditions. The player switches between them without restarting the video. In HLS, subtitles are often delivered as WebVTT files. In DASH, as WebVTT or TTML-based formats. If subtitles fail to appear in a particular app, the issue is more often the player's support for a format than the stream itself.
HLS vs MPEG-DASH at a glance
| HLS | MPEG-DASH | |
|---|---|---|
| Origin | Apple, IETF RFC 8216 | MPEG, ISO/IEC 23009-1 |
| Manifest | .m3u8 text playlists |
.mpd XML |
| Segments | TS or fMP4/CMAF | fMP4/CMAF (also others) |
| Apple device support | Native | Varies; HLS is the usual choice |
| DRM (explained) | FairPlay is native; others possible with fMP4 | Widevine, PlayReady and others |
| Low-latency mode | LL-HLS | Low-latency DASH |
Common misconceptions
- "HLS is only for Apple." HLS is widely supported on Android, smart TVs and the web through players and libraries. It's the most broadly compatible format.
- "DASH is higher quality." Neither protocol determines quality. Codec, bitrate and encoding do.
- "Segments make streams choppy." Players stitch segments seamlessly. Choppiness usually comes from network stalls or device decoding limits.
- "An
.m3u8link is always an IPTV channel." It's simply an HLS playlist. Any HLS video, from a news clip to a film, uses one.
What this means when something goes wrong
Knowing the basics helps with troubleshooting:
- Picture quality drops but playback continues: adaptive bitrate is working, and your connection dipped. Check your network.
- Playback stops and spins: the buffer ran dry. Segments arrived too slowly.
- Stream won't start at all: the manifest couldn't be loaded, often an authentication, network or outage problem.
Our buffering checklist and internet speed guide turn these clues into fixes.
Questions people ask
Can I open an .m3u8 link in a browser?
Safari plays HLS natively. Other browsers usually need a web player built with Media Source Extensions. Desktop players such as VLC open HLS and DASH links directly, unless they're DRM-protected.
Does segment length affect quality?
Not directly. Shorter segments allow faster quality switching and lower latency but add overhead. Longer segments are slightly more efficient but react more slowly.
Why do live streams sometimes restart at lower quality after buffering?
After a stall, players usually restart conservatively to rebuild the buffer, then climb back up the bitrate ladder.
Is RTMP still used?
RTMP is still used in some workflows to send video from encoders to streaming platforms, but it's rarely used for delivery to viewers today. HLS and DASH took over for playback.
What is server-side ad insertion?
Services can modify the manifest for each viewer to insert ad segments into the stream, which makes ads part of the stream itself. See FAST channels explained.
Glossary
| Term | Meaning |
|---|---|
| ABR | Adaptive bitrate: switching quality to match the connection |
| Manifest | The playlist or description file that tells the player what's available |
| Rendition | One version of a stream, such as 1080p or a particular audio language |
| Segment | A short chunk of media, typically a few seconds |
| CMAF | Common Media Application Format, shared by HLS and DASH |
| MSE | Media Source Extensions, the browser API web players use |
Where HLS and DASH are heading
Both formats continue to evolve. The main directions are lower latency for live events, wider use of CMAF so one set of files serves every device, more efficient codecs such as AV1 inside the same delivery formats, and smarter players that weigh quality, stability and data use together. For viewers, those changes are mostly invisible. Streams should simply start faster, look better at the same bandwidth and run closer to live.
Key takeaways
- HLS and DASH both deliver video as short segments listed in a manifest, letting players switch quality as conditions change.
- HLS is Apple's format, now an IETF standard, and the most widely compatible. DASH is an international standard popular on Android, smart TVs and the web.
- CMAF lets services use one set of media files for both formats, cutting costs.
- Neither protocol determines picture quality. Codecs, bitrates and encoding do.
- Low-latency versions of both reduce delay for live events.
Which one should a service use?
Most large services use both: HLS for Apple devices and DASH for many others, increasingly from shared CMAF segments. For viewers, it rarely matters which protocol a stream uses. What matters more is the codec, the bitrate ladder and the network between you and the CDN. Our buffering troubleshooting guide covers the parts you can control.


