How Both Protocols Work
HLS and DASH share the same fundamental architecture:
- Video is encoded at multiple bitrate levels (renditions).
- Each rendition is split into segments (2–10 seconds each).
- A manifest file lists all available renditions and the URLs for each segment.
- The player downloads the manifest, selects a rendition, and fetches segments sequentially via HTTP GET requests.
- The ABR algorithm adjusts rendition selection after each segment based on download speed and buffer level.
Because segments are fetched via standard HTTP, they traverse any CDN, cache, or proxy without special infrastructure.
HLS vs DASH: Key Differences
| Feature | HLS | DASH |
|---|---|---|
| Origin | Apple (2009) | MPEG standard (ISO/IEC 23009, 2012) |
| Manifest format | M3U8 (plain text playlist) | MPD (XML-based Media Presentation Description) |
| Segment container | MPEG-TS or fMP4 (CMAF) | fMP4 / ISOBMFF (CMAF) |
| Codec flexibility | H.264, H.265, AV1 (newer) | Any codec — H.264, H.265, AV1, VP9 |
| iOS/Safari support | Native | Not natively supported |
| Android/Chrome support | Via MSE (Media Source Extensions) | Native via MSE |
| Low-latency live | LL-HLS (Apple spec) | LL-DASH (CTA-5006) |
| DRM integration | FairPlay (Apple) | Widevine (Google), PlayReady (Microsoft) |
Segment Containers and CMAF
Historically HLS used MPEG-TS segments while DASH used fMP4 (fragmented MP4). CMAF (Common Media Application Format) standardizes on fMP4 segments usable by both HLS and DASH. A service can encode once to CMAF segments and serve them with either an M3U8 or MPD manifest — reducing encoding and storage costs. Netflix, Disney+, and Apple TV+ all use CMAF-based delivery.
Low-Latency Streaming
Standard HLS and DASH have 6–30 second end-to-end latency due to segment lengths and playlist update intervals. For live sports, this is too long — viewers may see social media spoilers before the play occurs on their stream.
LL-HLS (Low-Latency HLS) reduces latency to 2–4 seconds by using partial segments (0.3–1 second chunks) while the full segment is still being produced, plus HTTP/2 server push for manifest delivery.
LL-DASH achieves similar latency using chunked transfer encoding within segments — the player fetches a segment while it is still being written to the CDN.
Both approaches increase CDN request rates significantly (more frequent requests for smaller chunks), which raises CDN costs and requires HTTP/2 support throughout the delivery chain.
DRM Landscape
HLS is paired with Apple FairPlay DRM — mandatory for protected content on iOS and macOS Safari. DASH is paired with Widevine (Chrome, Android, Firefox) and PlayReady (Edge, Windows). Services delivering premium content must support all three DRM systems, which is one driver of the parallel HLS + DASH pipeline.
Frequently Asked Questions
Does using HLS or DASH affect streaming quality?
No — the protocol is a delivery mechanism. Quality is determined by the encoded bitrates available at the CDN. The same 4K HDR content delivered via HLS or DASH at identical bitrates looks identical. What differs is latency, DRM compatibility, and device support, not picture quality.
Why do some services use both HLS and DASH?
iOS and Safari require HLS — Apple does not support DASH natively. Android, Chrome, Firefox, and most smart TVs support DASH. Rather than exclude a platform, major services run parallel HLS and DASH delivery using CMAF segments with different manifests. The content is encoded once; the manifests differ by protocol.