HLS (Apple) and DASH (MPEG) are the two dominant adaptive bitrate streaming protocols. Both chunk video into short segments, both adapt bitrate to bandwidth, but they differ in playlist format, codec support, and ecosystem inertia. Most large platforms (Netflix, YouTube) serve both because no single one is supported everywhere.
Architecture parallels
Both protocols split the source video into 2-10 second segments at multiple bitrates (e.g., 240p, 480p, 720p, 1080p, 4K). A manifest file (.m3u8 for HLS, .mpd for DASH) tells the client what's available. The client monitors throughput and picks segments at the highest bitrate it can sustain.
Where they differ
| Aspect | HLS | DASH |
|---|---|---|
| Playlist format | M3U8 text | MPD XML |
| Container | TS or fMP4 | fMP4 only |
| Native iOS/Safari | Yes | No |
| Native Chrome/FF | Via JS | Via JS (dash.js) |
| DRM support | FairPlay | Widevine + PlayReady |
| Codec lock-in | H.264/HEVC mostly | Codec-agnostic |
The fMP4 unification
Since 2016 both HLS and DASH support fragmented MP4 (fMP4) as the container. This means you can encode and store ONE set of segment files and serve them under either manifest — packaging only differs in the manifest. Saves 50% on storage.
Latency profiles
Standard HLS/DASH: 20-30 seconds end-to-end (3 segments × ~6 sec + buffer). Low-latency variants (LL-HLS, LL-DASH) reduce this to 2-5 sec by serving partial segments. For sub-second latency you need WebRTC or a custom protocol — not these.
Which to use in production?
If your audience is iOS-heavy: HLS first. If your audience is global and you need DRM flexibility (Widevine + PlayReady + FairPlay): both. If you're starting fresh: package fMP4 once, generate both manifests, ship both. The storage cost is negligible vs the support cost of missing a platform.