CMAF: How One Set of Segments Serves Both HLS and DASH

Why streaming services used to store every video twice, and how the Common Media Application Format ended that.

For most of the last decade, any service that wanted to reach both Apple devices and everything else had to package every asset twice: once as MPEG-2 Transport Stream segments for HLS, once as fragmented MP4 for DASH. Same source, same encode settings, same bits going in, two entirely separate sets of files coming out.

The cost of that was not subtle. Storage doubled. Encoding time doubled. Worse, CDN cache efficiency halved, because a viewer on iOS and a viewer on Android requesting the same moment of the same video pulled two different objects, neither of which warmed the cache for the other.

CMAF (the Common Media Application Format, standardised as ISO/IEC 23000-19) exists to eliminate that duplication.

What CMAF Actually Is

The most common misconception is that CMAF is a new streaming protocol competing with HLS and DASH. It is not. CMAF specifies nothing about manifests, playlists, or how a player discovers content. It is purely a segment format, a constrained profile of fragmented MP4 that both protocols can reference.

The insight behind it is that HLS and DASH were never really incompatible in the way they appeared. They differ in how they describe media, not in what the media has to be. Once HLS added fragmented MP4 support in 2016, the container difference evaporated. What remained was the absence of an agreed profile, a specific set of constraints both ecosystems would reliably accept.

CMAF is that profile. A CMAF-packaged asset consists of:

• An initialization segment (init.mp4) carrying the ftyp and moov boxes, codec configuration, track metadata, timescale. Fetched once per representation.

• A series of media segments (.m4s) each carrying moof and mdat boxes, one fragment's metadata and its actual sample data.

Both an HLS media playlist and a DASH MPD can point at exactly these files. One set of bytes on disk, two manifests describing them.

The Encryption Problem

Deduplicating the container was the easy half. The harder problem was DRM, and it is why CMAF adoption took longer than the format itself suggests.

The Common Encryption specification (CENC, ISO/IEC 23001-7) defines two encryption schemes:

• `cenc`: AES-128 in counter mode (AES-CTR)

• `cbcs`: AES-128 in cipher block chaining mode with pattern encryption

These are not interchangeable. A decryptor built for one cannot handle the other. And historically the DRM systems split cleanly along that line: Apple FairPlay required cbcs, while Widevine and PlayReady used cenc. Which meant that even with an identical container, you still needed two encrypted copies, defeating the entire purpose.

The resolution came from the other side. Widevine and PlayReady both added cbcs support, and cbcs became the de facto choice for new CMAF deployments. A single cbcs-encrypted CMAF asset can now be decrypted by all three major DRM systems, with only the license acquisition differing per platform.

If you are packaging CMAF today, cbcs is almost always the right scheme. The main exception is legacy device support, some older smart TVs and set-top boxes shipped cenc-only implementations and will not play cbcs content.

Chunked CMAF and Low Latency

CMAF's second contribution is structural support for low-latency delivery.

A CMAF segment is not required to be a single monolithic fragment. It can be subdivided into CMAF chunks, each a valid moof+mdat pair, typically a few hundred milliseconds long. Because each chunk is independently parseable, a player can begin decoding it before the enclosing segment finishes.

This is the mechanism underneath both low-latency modes:

• LL-DASH serves the segment with HTTP chunked transfer encoding, streaming chunks to the player as the packager writes them.

• LL-HLS exposes chunks as addressable partial segments announced in the playlist with EXT-X-PART tags.

Different manifest mechanics, same underlying chunk structure. This is the clearest illustration of what CMAF is for: the two protocols solve low latency differently at the description layer while sharing the media layer entirely.

The caveat is that your CDN must cooperate. Many caching configurations buffer an entire origin response before forwarding it downstream, which turns chunked delivery back into whole-segment delivery and silently erases the latency benefit. This needs to be verified against real CDN behaviour rather than assumed from configuration.

What You Give Up

CMAF is not free of trade-offs.

Legacy device support. Devices predating 2016 HLS often require MPEG-TS segments. If your audience includes older smart TVs or long-lived set-top hardware, you may need a TS fallback ladder, which reintroduces the duplication CMAF removes, though now only for a shrinking minority of traffic rather than half of it.

Packager and toolchain maturity. Support is good in current tooling but the constraint set is stricter than plain fMP4, and non-compliant output tends to fail in ways that are awkward to diagnose, playing on one platform and failing on another with an unhelpful error.

Chunked mode operational complexity. Sub-second chunking multiplies request volume and demands more from every component in the path. It is worth it when low latency is a product requirement and unnecessary overhead when it is not.

Whether It Is Worth Adopting

For a new pipeline serving multiple platforms, CMAF is the default and there is little reason to package any other way. The storage saving is immediate, and the CDN cache-hit improvement is usually the larger financial effect, a single popular segment now serves every platform from one cached object.

For an existing dual-packaged pipeline, the migration is real work but bounded. The encoding stage does not change; only packaging and manifest generation do. The usual approach is to run CMAF alongside existing output, route a fraction of traffic to it, compare playback error rates by device class, and cut over once the tail of failures is understood.

The one thing not to do is treat CMAF as a protocol decision. You still choose HLS, DASH, or both based on your platform targets. CMAF just means that choice no longer costs you a second copy of everything.