HLS vs DASH: how the formats compare, and where CMAF fits
HLS and MPEG-DASH compared: playlists vs manifests, iPhone and Android support, encryption and DRM, low latency, and how CMAF lets one set of segments serve both formats.
On this page 9 sections
HLS and MPEG-DASH do the same job: both cut video into short segments at several bitrates and describe them in a manifest, so a player can stream adaptively over ordinary HTTP servers and CDNs. The differences that matter in practice are device support (Apple devices play HLS natively, while DASH needs a player library), the manifest format, and which encryption and DRM systems each works with. With CMAF, one set of fragmented MP4 segments can serve both.
How HLS works
HTTP Live Streaming was created by Apple and published as RFC 8216 in August 2017. A second edition, which adds features such as low-latency streaming and content steering, has been submitted to the RFC Editor. HLS uses plain-text playlists with the .m3u8 extension, in two levels:
- A multivariant playlist (older documents call it the master playlist) lists each rendition with its bitrate, resolution and codecs.
- A media playlist for each rendition lists its segments in order, with their durations.
A short on-demand media playlist looks like this:
#EXTM3U
#EXT-X-VERSION:7
#EXT-X-TARGETDURATION:6
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-MAP:URI="init.mp4"
#EXTINF:6.000,
seg_00001.m4s
#EXTINF:6.000,
seg_00002.m4s
#EXT-X-ENDLIST
Segments can be MPEG-2 transport streams (.ts) or fragmented MP4; EXT-X-MAP points to the initialisation section that fragmented MP4 needs. For a live stream, the playlist has no end tag and the player reloads it to find new segments. The specification tells players not to start within three target durations of the live edge, which is one reason standard HLS runs well behind real time.
How DASH works
MPEG-DASH (Dynamic Adaptive Streaming over HTTP) is an international standard, ISO/IEC 23009-1. Its manifest is an XML file called the Media Presentation Description (MPD), organised as a hierarchy: a Period holds Adaptation Sets (one for video, one per audio language, one per subtitle track), and each Adaptation Set holds Representations, the individual renditions. A trimmed example:
<MPD type="static" mediaPresentationDuration="PT1H30M" minBufferTime="PT2S">
<Period>
<AdaptationSet mimeType="video/mp4" segmentAlignment="true">
<SegmentTemplate timescale="1000" duration="6000" startNumber="1"
initialization="$RepresentationID$/init.mp4"
media="$RepresentationID$/seg_$Number%05d$.m4s"/>
<Representation id="360p" bandwidth="350000" width="640" height="360" codecs="avc1.64001e"/>
<Representation id="720p" bandwidth="1200000" width="1280" height="720" codecs="avc1.64001f"/>
</AdaptationSet>
</Period>
</MPD>
Instead of listing every segment, the template tells the player how to build segment URLs, and audio sits in its own Adaptation Set, so these bandwidths are for video alone. DASH is codec-agnostic and allows more than one segment container, though in practice almost everyone uses fragmented MP4.
HLS vs DASH at a glance
| Aspect | HLS | MPEG-DASH |
|---|---|---|
| Defined by | Apple; RFC 8216 | MPEG; ISO/IEC 23009-1 |
| Manifest | Text playlists (.m3u8), two levels | One XML file (.mpd) |
| Segment formats | MPEG-TS or fragmented MP4 (plus packed audio and WebVTT) | Usually fragmented MP4; codec-agnostic by design |
| Native playback | Safari and Apple's native players | None built into mainstream browsers; needs a player library |
| Typical encryption | AES-128 whole-segment encryption, SAMPLE-AES, FairPlay | Common Encryption with Widevine or PlayReady |
| Low latency | Low-Latency HLS with partial segments | Low-latency DASH with chunked CMAF |
On adaptation itself, the two are equivalent: both give the player a ladder and let it choose. Our guide to adaptive bitrate streaming explains how players choose.
Device and browser support: why iOS decides
- iPhone and iPad: Safari plays HLS natively, and Apple's native players are built around HLS. Safari on iPhone doesn't support standard Media Source Extensions (iPads do, from iPadOS 13), which long kept JavaScript DASH players off iPhones. Safari 17.1 brought the Managed Media Source API to iPhone, which newer player libraries can use, but HLS remains the dependable path on Apple devices.
- Android apps: ExoPlayer, now part of Android's Media3 library, plays both HLS and DASH.
- Desktop and Android browsers: JavaScript players built on Media Source Extensions, such as hls.js, dash.js and Shaka Player, handle either format.
- Smart TVs and set-top boxes: support varies by platform and model year, so test the specific devices your students use.
The practical result: if you choose only one format, HLS reaches every device a coaching institute's students are likely to use. DASH becomes worth adding mainly for DRM, as covered below.
CMAF: one set of segments for both
For years, serving both formats meant packaging twice: MPEG-TS segments for HLS and fragmented MP4 for DASH. The Common Media Application Format (CMAF, ISO/IEC 23000-19, first published in 2018) standardises fragmented MP4 segments that an HLS playlist and a DASH MPD can both reference. You encode and store one set of media files and publish two small manifests.
A worked example shows why this matters. Take an illustrative library of 1,000 hours of lectures and a five-rung ladder totalling about 4.4 Mbps. That is roughly 2 TB of segments. Packaging separately for HLS and DASH doubles it to about 4 TB, and it splits your CDN cache in two, because the same lecture now exists as two sets of objects that are fetched and cached separately. With CMAF, a popular lecture's segments are cached once and serve every student, whichever manifest their player read.
One detail can still force two copies: the encryption scheme. Common Encryption defines two main modes, cenc (AES counter mode) and cbcs (AES-CBC with a pattern that encrypts only part of the data). FairPlay requires cbcs; Apple's specification sets the pattern at one encrypted block in ten. PlayReady supports cbcs from version 4.0, and Widevine supports it on current devices, so a single cbcs set can serve all three on modern hardware. Some older devices only handle cenc, and supporting them means a second encrypted copy.
Encryption and DRM support
HLS has its own simple encryption: with METHOD=AES-128, each segment is encrypted whole with AES-128 in CBC mode, and the playlist tells the player where to fetch the key. SAMPLE-AES encrypts individual media samples instead, and it's the method FairPlay uses. DASH relies on Common Encryption, with the browser's Encrypted Media Extensions talking to a DRM system such as Widevine or PlayReady to get the keys.
The encryption itself is standard AES either way. What differs is how keys reach the player and what the device promises to do with them. Our guides to HLS encryption and multi-DRM packaging go deeper, and how DRM works explains licence servers in plain terms.
Which should you choose?
| Your situation | A sensible choice |
|---|---|
| Recorded lectures in your own Android and iOS apps, plus a website | HLS alone; use fragmented MP4 segments so you can add DASH later without repackaging |
| You need Widevine on Android and Chrome, and FairPlay on Apple devices | CMAF segments encrypted with cbcs, published with both an HLS playlist and a DASH MPD |
| Very old Android devices or TVs are a large share of viewers | Test first; you may need MPEG-TS HLS or a cenc copy for them |
| Live classes that need a few seconds of delay or less | Low-Latency HLS or low-latency DASH, or WebRTC for real interaction |
For live classes where students talk back to the teacher, neither HTTP format is fast enough on its own; our comparison of WebRTC vs HLS covers that trade-off.
Key takeaways
- HLS and DASH both deliver adaptive, segmented video over HTTP; the differences are the manifest, device support and DRM pairing.
- HLS plays natively on Apple devices and through libraries everywhere else, so it's the safer single choice.
- CMAF lets one set of fragmented MP4 segments serve both formats, halving storage and avoiding duplicate copies in the CDN cache.
- The encryption scheme (cenc or cbcs) can still split your library; cbcs covers FairPlay, current Widevine and PlayReady 4.0 and later.
Frequently asked questions
How does HLS streaming work?
HLS splits a video into short segments, usually around six seconds each, at several quality levels. A multivariant playlist lists the quality levels, and a media playlist for each level lists its segments. The player downloads the playlists, then fetches segments one after another over ordinary HTTP, switching quality between segments as the connection changes. For live streams, it keeps reloading the playlist to find new segments.
Is HLS or MPEG-TS better?
They aren't alternatives. MPEG-TS is a container format, while HLS is a streaming protocol that can carry MPEG-TS segments or fragmented MP4 segments. For new work, fragmented MP4 is usually the better segment format: Apple requires it for HEVC and AV1, and it lets DASH players share the same files. MPEG-TS remains useful for very old devices and some broadcast workflows.
What is HLS and DASH?
HLS (HTTP Live Streaming) and DASH (Dynamic Adaptive Streaming over HTTP) are the two main formats for adaptive video streaming. Both split video into short segments at several bitrates and describe them in a manifest, so players can switch quality as networks change. HLS comes from Apple and plays natively on its devices; DASH is an international MPEG standard used widely with Android and web players.
Is DASH better than HLS?
Neither is better in general. DASH is codec-agnostic and pairs naturally with Widevine and PlayReady, while HLS plays natively on iPhones and is supported by almost every player library. Many platforms use HLS alone; those that need multi-DRM often publish both, sharing CMAF segments so the extra format costs only a second manifest.