What is CMAF? Common Media Application Format Explained

CMAF (Common Media Application Format) is a standardized media segment format—published as ISO/IEC 23000-19 in 2016 after a joint effort by Apple and Microsoft—that lets one set of video files serve both HLS and DASH players. This distinction matters: CMAF is not a streaming protocol. It defines how segments are structured (fragmented MP4 broken into small chunks), while HLS and DASH remain the protocols that describe and deliver them. Before CMAF, serving both ecosystems meant encoding, packaging, encrypting, and caching everything twice; after CMAF, one encode serves everyone—and its chunked structure is what makes modern low-latency streaming practical.

CMAF is the quiet foundation of delivery at Videospan: it's what lets us package a rendered video once and serve every device on earth from a single set of files—an efficiency that matters a great deal when a platform renders every title in multiple aspect ratios and variants.

The problem CMAF solves was an expensive accident of history. Because Apple devices required HLS (originally with MPEG-TS segments) while the rest of the industry standardized on DASH (with fragmented MP4), large services had to package, encrypt, and cache two copies of every video—roughly doubling storage and CDN footprint for big catalogs. Apple and Microsoft jointly proposed CMAF to MPEG in 2016, and it was standardized as ISO/IEC 23000-19, with the first edition published in 2018. Apple simultaneously added fMP4 support to HLS, making a single shared segment library technically possible for the first time. The format's second, arguably bigger, contribution arrived in 2019, when both LL-HLS and low-latency DASH standardized on CMAF chunks delivered over chunked transfer encoding—turning what began as a cost-saving consolidation format into the foundation of modern low-latency streaming.

How CMAF works

CMAF sits between the encoder and the protocols:

1. Encode once. The source is encoded into renditions using any codec (H.264, HEVC, AV1), exactly as before.
2. Package as CMAF tracks. Each rendition is muxed into fragmented MP4: an initialization segment (header and codec config) followed by media segments made of moof (metadata) + mdat (media data) boxes.
3. Fragment segments into chunks. Each segment is further divided into CMAF chunks (CMFs)—individual moof/mdat pairs that are independently decodable as they arrive.
4. Publish two manifests. The exact same segment files are referenced by both an HLS .m3u8 playlist and a DASH MPD. Apple players take the HLS path; everything else can take DASH.
5. Cache once, deliver to all. Because both manifests point at identical URLs, the CDN stores a single copy of every segment regardless of which protocol the viewer uses.

For low-latency live delivery, one more ingredient completes the picture: chunked transfer encoding. Instead of waiting for a full 6-second segment to be written, the packager streams each CMAF chunk over an open HTTP connection as it's produced—so players can start decoding video that is less than a second old.

Anatomy of a CMAF stream

A CMAF segment on disk is a standard fMP4 file. Its internal structure—a chain of chunk-sized moof/mdat pairs—is what enables progressive delivery:

init.mp4                     segment_1042.m4s
┌──────────────────┐         ┌──────────────────────────────┐
│ ftyp │ styp │ moov │         │ styp                         │
└──────────────────┘         │ ┌──────────┐ ← CMAF chunk 1 │
  File type, segment type,   │ │moof│mdat │   (~500 ms)    │
  track & codec config       │ ├──────────┤ ← CMAF chunk 2 │
  (sent once per rendition)  │ │moof│mdat │   (~500 ms)    │
                             │ ├──────────┤ ← CMAF chunk 3 │
                             │ │moof│mdat │                │
                             │ └──────────┘                │
                             │        ...                   │
                             └──────────────────────────────┘

• ftyp / moov live only in the initialization segment—the player fetches it once when joining a rendition.
• Each moof (movie fragment) carries timestamps and sample metadata; the following mdat carries the actual compressed frames.
• Because every chunk is self-describing, a player can begin decoding as soon as the first moof/mdat pair arrives over the wire—no need to wait for the whole segment.

Both manifests then reference the same files:

#EXTM3U
#EXT-X-VERSION:7
#EXT-X-TARGETDURATION:6
#EXT-X-MAP:URI="init.mp4"
#EXTINF:6.006,
segment_1042.m4s

<SegmentTemplate timescale="90000" duration="540000"
                 media="segment_$Number$.m4s" initialization="init.mp4"/>

Same bytes, two protocols, one cache.

How Videospan uses CMAF

Our rendering infrastructure produces a lot of video: every remote recording, AI-assisted edit, and repurposed clip ships in multiple aspect ratios and variants, each with its own rendition ladder. CMAF is what keeps that efficient. Each rendition is packaged once as fragmented MP4, and both the HLS playlist and the DASH MPD point at the identical segment files—so a single encode serves iPhones, Androids, browsers, and smart TVs, and the CDN caches each segment exactly once no matter which protocol asks for it.

That "cache once" property compounds at enterprise scale. When a global company publishes a leadership update to employees across every region, cache efficiency is the difference between a smooth morning and a flooded origin. Shared CMAF segments deliver the best possible cache hit ratios by construction, not by tuning—and they keep the storage footprint of a large video library proportional to what was actually created, not to the number of protocols it plays on.

CMAF's chunked structure also provides a low-latency path on the same pipeline. For live and time-sensitive communications, chunked transfer encoding over CMF chunks delivers latency of a few seconds using plain HTTP—no proprietary protocols and no separate live stack to build or maintain.

CMAF vs HLS and DASH

Advantages

• One encode, every device. The headline benefit: a single set of segments serves HLS and DASH audiences, cutting packaging, storage, and compute costs roughly in half for dual-protocol services.
• Single CDN cache. Identical URLs for both protocols mean far better cache hit ratios—especially valuable for long-tail VOD libraries.
• Enables practical low latency. CMAF chunks plus chunked transfer encoding deliver 2–4 second glass-to-glass latency using plain HTTP infrastructure, with no proprietary protocols.
• Multi-DRM friendly. With CENC for Widevine/PlayReady and cbcs for FairPlay, a single encrypted asset can serve all major DRM systems.
• Codec-agnostic. Works with H.264, HEVC, and AV1, so it doesn't constrain future codec migration.

Limitations

• It's still not a protocol. CMAF does nothing without HLS and/or DASH manifests on top; "switching to CMAF" means re-packaging, not replacing your delivery stack.
• Low latency requires the whole chain to cooperate. Encoder, packager, CDN, and player must all support chunked delivery; one legacy hop (an intermediate proxy that buffers, for example) silently reverts you to segment-level latency.
• Older devices may not play fMP4 HLS. Pre-2016 Apple devices expect MPEG-TS segments, so truly universal legacy support may still require a TS fallback ladder.
• Not real-time. Like LL-HLS and LL-DASH, chunked CMAF bottoms out around 2 seconds. Interactive use cases still need WebRTC.

When to use CMAF

Use CMAF any time you're building or modernizing an HTTP streaming pipeline. There is effectively no reason in 2026 to package separate TS-for-HLS and fMP4-for-DASH libraries: CMAF gives you both audiences from one encode, with better caching and a low-latency upgrade path.

For enterprise and branded-video platforms—think a global company streaming a product launch to employees and customers on every conceivable device—CMAF is the default architecture: one packaging step feeds the HLS playlist that iPhones require and the DASH MPD that Androids and smart TVs prefer. Add chunked transfer encoding when the same pipeline needs to handle live town halls or interactive events at a few seconds of latency.

The main case against CMAF is legacy: if your audience includes a meaningful share of pre-2016 devices (old set-top boxes, early smart TVs), you may need to keep an MPEG-TS rendition set alongside it.

When you're evaluating a video platform, CMAF is a question worth asking directly: does the platform package once for all devices, or maintain parallel HLS-TS and DASH libraries? The answer reveals how modern the pipeline is—and it has practical consequences. Single-encode platforms adopt new codecs and low-latency features faster, scale large libraries more cheaply, and get better CDN cache performance for the global workforces enterprise video usually targets.

Glossary

CMAF chunk— CMF

A small, independently decodable piece of a segment—a single moof/mdat pair—typically a few hundred milliseconds of media. Chunks are the unit of low-latency delivery.

fMP4— Fragmented MP4

An MP4 file organized into movie fragments rather than one monolithic index, allowing playback and delivery to begin before the file is complete.

moof / mdat— Movie fragment / Media data

The paired boxes inside a fragment: moof carries sample timing and metadata, mdat carries the compressed audio/video samples.

Initialization segment

The header portion of a CMAF track (ftyp + moov) containing codec configuration. Players fetch it once per rendition before any media segment.

Chunked transfer encoding

An HTTP/1.1 mechanism for streaming a response body in pieces as it's produced, so players receive CMAF chunks in near-real time instead of waiting for a complete segment.

CENC— Common Encryption

The standardized encryption scheme (ISO/IEC 23001-7) that lets one encrypted CMAF asset be licensed by Widevine and PlayReady; the cbcs mode extends this to FairPlay.

cbcs— Cipher Block Chaining with pattern encryption

The encryption mode Apple adopted for FairPlay over fMP4, completing CMAF's single-asset multi-DRM story.

Glass-to-glass latency

The end-to-end delay from light hitting the camera sensor to pixels appearing on a viewer's screen.

Frequently asked questions

Related

• Video Streaming Protocols: HLS, DASH & CMAF Explained
• What is HLS?
• What is MPEG-DASH?