HLS vs DASH
Two protocols that solve the same problem in almost the same way. Where they still diverge: device support, DRM, low latency, manifests and the CMAF packaging that lets one set of segments serve both.
HLS and MPEG-DASH both send video as short files over HTTP, and both let the player switch quality. HLS plays natively on Apple devices and is the safe default. DASH is an open ISO standard with a more flexible XML manifest. With CMAF segments, most platforms can serve both from one encode.
For most of the 2010s, choosing between HLS and MPEG-DASH was a real fork in the road. Each needed its own segments, packaging and storage. Picking one meant leaving out some devices or doubling costs. That fork has narrowed to a footpath. A shared segment format now lets one encode feed both. The choice is now about manifests, DRM and latency, not about compatibility.
This comparison explains where the two protocols came from and how their manifests differ. It covers which devices play each one natively. It also covers encryption, low latency and what the Common Media Application Format changed. If segmented streaming is new to you, start with the HLS guide. The video streaming hub gives the wider picture, from transcoding to delivery.
Origins
HLS was created by Apple for the iPhone in 2009, documented for years as an IETF Internet-Draft, and published as RFC 8216 in 2017. It began with MPEG-2 transport stream segments because that was a format Apple's hardware already decoded. MPEG-DASH (Dynamic Adaptive Streaming over HTTP) became ISO/IEC 23009-1 in 2012. MPEG wrote it with help from a wide industry group. It was meant as an alternative that works with any codec and any container, and that no single vendor controlled. The DASH Industry Forum publishes the guidelines that make real deployments work together.
The two designs share the same shape. There is a top-level description of the renditions, a list of segments for each rendition, and segments served as plain files. Both switch quality the same way, as the adaptive bitrate guide explains. They differ in the details of that description and in who supports what.
Side by side
| Aspect | HLS | MPEG-DASH |
|---|---|---|
| Specification | RFC 8216 and the rfc8216bis draft (Apple) | ISO/IEC 23009-1 (MPEG) |
| Top-level description | Multivariant playlist, extended M3U text | Media Presentation Description (MPD), XML |
| Segment formats | MPEG-2 TS, fragmented MP4, packed audio, WebVTT | Fragmented MP4 (ISO BMFF) or WebM; codec-agnostic |
| Segment addressing | Explicit list in the media playlist | Explicit list, or a SegmentTemplate with numbering or timing |
| Native browser playback | Safari on macOS and iOS | None; always via Media Source Extensions |
| Native device playback | Apple TV, iOS, most smart TVs and consoles | Android ExoPlayer, most smart TVs, consoles |
| Encryption and DRM | AES-128, SAMPLE-AES, FairPlay | Common Encryption (CENC) with Widevine, PlayReady and others |
| Ad and content boundaries | EXT-X-DISCONTINUITY | Multiple Periods in the MPD |
| Low latency | Low-Latency HLS: partial segments and blocking playlist reload | LL-DASH: chunked CMAF with chunked transfer encoding |
| Subtitles | WebVTT segments; IMSC in fMP4 | WebVTT, TTML and IMSC |
Manifests: text playlist versus XML
An HLS media playlist lists every segment by URL with its duration. That makes it simple to read and simple to write. But it gets long for a multi-hour video with short segments. The DASH MPD can do the same. Or it can use a SegmentTemplate, which describes segment URLs as a pattern with a number or timestamp. Then a single line covers thousands of segments. The MPD also carries explicit Periods, which is how DASH marks a change of content such as an inserted advert. HLS uses a discontinuity tag within a single playlist.
For live streams the two behave alike: the player re-fetches the playlist or MPD to learn about new segments. DASH also lets the MPD declare availability times. A player can then work out segment URLs without re-fetching. That is one reason DASH reached low latency slightly earlier than HLS did.
Device support: the deciding factor for years
The practical reason HLS became the default was iPhone. Safari on iOS did not support Media Source Extensions, so no JavaScript player could feed DASH segments to the decoder. Native HLS was the only way to stream to the most valuable mobile audience. Everywhere else, DASH and HLS were equally reachable through MSE-based players such as dash.js, Shaka Player and hls.js. Apple later added a Managed Media Source API to iOS Safari, which narrows the gap, but HLS remains the path that needs no library on Apple hardware.
Android and most smart TV platforms play both. Games consoles and set-top boxes vary. The safe rule of thumb: a platform that offers only one protocol offers HLS. That is why VideoBB delivers its renditions as HLS with automatic quality switching. It is also why the embeddable player works in any browser without a plugin.
When each protocol is the natural choice
HLS fits when
- Apple devices are a significant share of the audience and you want native playback.
- You want one protocol that reaches every screen without a JavaScript player on some of them.
- DRM, if needed, is FairPlay on Apple platforms.
- The operations team is more comfortable with text playlists than XML manifests.
DASH fits when
- You need Widevine or PlayReady DRM on Android, Chrome or Edge with Common Encryption.
- Multi-period presentations, such as stitched programmes with distinct ad breaks, are central.
- You want a vendor-neutral ISO standard and codec-agnostic packaging.
- Your player is already dash.js, Shaka or ExoPlayer and the audience is not Apple-heavy.
CMAF: one set of segments for both
The Common Media Application Format, ISO/IEC 23000-19, was published in 2018. It defines a strict form of fragmented MP4 segment that both HLS and DASH can point to. A packager writes the segments once. Then it writes an m3u8 playlist and an MPD that point at the same files. If the words container and codec blur together here, the container vs codec explainer separates them. The last obstacle was encryption. FairPlay required the cbcs encryption mode, while Widevine and PlayReady used cenc, so encrypted segments had to be stored twice. Both now support cbcs on current devices, which lets a single encrypted set serve every DRM. Unencrypted content never had a duplication problem. CMAF simply made the shared packaging official.
Low latency, briefly
Both protocols reduce live latency by letting the player fetch a segment before it is complete.
- LL-DASH relies on chunked CMAF segments and HTTP chunked transfer encoding. The packager streams each segment's chunks as they are encoded, and the player starts decoding before the segment closes.
- Low-Latency HLS came from Apple in 2019 and is now part of the rfc8216bis draft. It adds partial segments listed in the playlist and blocking playlist requests that wait for the next part. It also adds rendition reports for fast switching.
- Both usually reach a few seconds of latency, against tens of seconds for classic segmented delivery. Both need packager, CDN and player support end to end.
- For on-demand video, none of this applies. The CDN guide covers what matters for cached playback instead.
Frequently asked questions
Which is better for a small site embedding video?
Neither, in the sense that a hosting platform makes the choice for you. If you self-host, HLS is the practical answer. It plays natively on iPhones and through hls.js everywhere else, so one package covers every viewer. DASH only becomes necessary when you need Widevine or PlayReady DRM or complex multi-period stitching. Small sites rarely do.
Can the same segments really serve HLS and DASH?
Yes, when they are CMAF-conformant fragmented MP4. The packager writes the segments once and produces both an m3u8 playlist and an MPD pointing at them. MPEG-2 transport stream segments cannot be shared, since DASH does not use them. Encrypted content needs the cbcs mode for the shared set to work with FairPlay as well as Widevine and PlayReady on current devices.
Is DASH faster or lower latency than HLS?
Not inherently. Classic HLS and classic DASH have similar latency, dominated by segment length and the number of segments a player buffers before starting. Their low-latency extensions use different methods: chunked transfer for DASH and partial segments for HLS. Both reach a few seconds of latency in practice when the packager, CDN and player all support them.
Does VideoBB use HLS or DASH?
HLS. Every upload is transcoded into HLS renditions from 144p to 1080p. When the source is large enough, 1440p and 2160p are made too, for Premium members to watch. The embeddable player switches between them automatically. HLS was chosen because it plays natively on Apple devices and through Media Source Extensions in every other browser. So one package reaches every viewer with no extra setup.
Sources
- RFC 8216: HTTP Live Streaming — The HLS specification
- DASH Industry Forum — MPEG-DASH guidelines and reference player
- ISO/IEC 23009-1: Dynamic adaptive streaming over HTTP (DASH) — The DASH standard at ISO
- Apple: HTTP Live Streaming — Including Low-Latency HLS documentation
- MDN: Media Source API — The API that DASH and non-Safari HLS players rely on
Related guides
What is HLS streaming?
HTTP Live Streaming is a text playlist, a pile of short media files and a set of rules for a player. Here is how those pieces fit together and why it became the default way to deliver video.
Adaptive bitrate streaming, explained
A player that changes quality mid-stream is making a prediction every few seconds. How the rendition ladder is built, how the player chooses a rung, and what makes the choice hard.
CDN for video delivery
Video is the most cache-friendly traffic on the internet and the most punishing when caching fails. How content delivery networks serve segments, what to cache for how long, and where the costs hide.
How to embed a video on a website
Copy one iframe, understand the six attributes it carries, and add the query parameters that control autoplay, mute, start time and looping.