CMAF (Common Media Application Format)
One way to package video segments that both HLS and DASH players understand — so a library is stored, cached and encrypted once instead of twice.
CMAF packages video as fragmented MP4 chunks that HLS and DASH can both reference, so you keep one copy of every segment instead of two — and, split into small chunks, it is what makes low-latency live possible.
What is CMAF?
CMAF (Common Media Application Format) is a standard container for streaming video, published as ISO/IEC 23000-19 in 2018. It defines how encoded audio and video are cut into fragmented MP4 (fMP4) segments that a streaming protocol can deliver. Apple and Microsoft proposed it together, and its point is simple: one set of media files that both HLSHLS (HTTP Live Streaming)Apple’s adaptive streaming protocol. Uses .m3u8 manifests and segmented delivery; supported on every browser, device and smart TV.Open definition → and DASHDASHDynamic Adaptive Streaming over HTTP — an open ISO standard using .mpd manifests, common for DRM-protected premium content.Open definition → players can play.
CMAF is not a streaming protocol and not a codecCodecThe algorithm that compresses and decompresses video — H.264, H.265 (HEVC) and AV1 are the most common in modern streaming.Open definition →. HLS and DASH still decide how a player finds and requests segments — through an .m3u8 or .mpd manifestManifestA small index file (.m3u8 or .mpd) that lists every available rendition and segment so the player knows what it can request.Open definition → — and H.264, HEVC or AV1 still compress the picture. CMAF sits in between: it is the shape of the segment files themselves.
Why CMAF exists
Before CMAF, the two dominant protocols wanted different containers. HLS traditionally used MPEG-2 Transport Stream (.ts) segments; DASH used fragmented MP4. A platform that wanted to reach Apple devices and everything else had to package, store and cache every video twice.
| Aspect | Before CMAF (TS + fMP4) | With CMAF |
|---|---|---|
| Segment sets per video | Two — one per protocol | One, shared |
| Storage at the origin | Roughly doubled | Single copy |
| CDN cache | Two objects compete for the same edge | One object, higher cache hit ratio |
| Encryption | Separate packaging per DRM family | Common encryption (cbcs) can serve several DRM systems |
| Low-latency live | Whole segments only | Small chunks inside a segment |
The cache point matters more than it looks: every duplicate copy halves how often an edge already holds the segment a viewer asks for — see origin shield and tiered cachingOrigin shield (tiered caching)A cache tier between CDN edges and the origin that collapses duplicate requests, so a traffic spike reaches your server once, not thousands of times.Open definition →.
How CMAF works
The source is transcodedTranscodingRe-encoding a source video into multiple resolutions and bitrates so a player can switch between quality levels on the fly.Open definition → into an adaptive ladder — several resolutions and bitratesBitrateThe amount of data used per second of video. Higher bitrate means more detail and a larger file; the core lever behind streaming quality.Open definition →.
Each rendition is cut into CMAF segments — typically a few seconds each — plus an initialisation segment with the codec settings.
For live, a segment can be divided into chunks of a fraction of a second, each playable on its own. This is what low-latency delivery builds on.
An HLS playlist and a DASH manifest both point at the same files. Apple devices read the .m3u8, other players read the .mpd — the bytes on the CDNCDN (Content Delivery Network)A global network of edge servers that caches video close to viewers, cutting latency and absorbing traffic spikes.Open definition → are identical.
CMAF and low-latency streaming
Standard streaming waits for a full segment to be encoded before anyone can download it, and players keep several segments in reserve — which is why ordinary HLS live runs 10–30 seconds behind real time (see latencyLatencyThe delay between a moment happening and a viewer seeing it. Critical for live — Low-Latency HLS brings it down to 2–5 seconds.Open definition →). CMAF chunks let the server publish the first part of a segment while the rest is still being encoded, and let the player start on it straight away.
Chunked CMAF is the container behind both Low-Latency HLSLow-Latency HLS (LL-HLS)Apple’s HLS extension that publishes partial segments and holds playlist requests, cutting live delay from 10–30 seconds to a few.Open definition → (as partial segments) and Low-Latency DASH (as chunked transfer). The format alone does not lower latency — the encoder, the CDN and the player all have to work in chunks too — but without it, sub-segment delivery over HTTP is not practical.
CMAF and DRM
CMAF uses Common Encryption (CENC). With the cbcs scheme, one encrypted set of segments can be unlocked by Widevine, FairPlay and PlayReady licences, instead of packaging a separate copy for each DRM system. That is the practical basis of multi-DRMMulti-DRMServing one encrypted library through Widevine, FairPlay and PlayReady at once — no single DRM system covers every browser and device.Open definition →: one library, several licence servers, every major browser and device.
Further reading
- Low latency streaming: LL-HLS vs WebRTC and CMAF’s role — how chunked delivery changes glass-to-glass latency.
- Common Media Application Format — Wikipedia — the standard and its history.
