{"id":6659,"date":"2026-07-03T09:50:57","date_gmt":"2026-07-03T09:50:57","guid":{"rendered":"https:\/\/www.5centscdn.net\/blog\/?p=6659"},"modified":"2026-07-03T09:51:01","modified_gmt":"2026-07-03T09:51:01","slug":"what-is-cmaf","status":"publish","type":"post","link":"https:\/\/www.5centscdn.net\/blog\/what-is-cmaf\/","title":{"rendered":"What Is CMAF? Common Media Application Format Explained"},"content":{"rendered":"
<\/div>\n

Every streaming engineer eventually runs into the same hidden tax: to reach viewers on Apple devices and everywhere else, the same video often had to be packaged twice \u2014 once for HLS, once for DASH. Two sets of files, double the storage, and two copies competing for room in every CDN cache. CMAF was designed to end that tax.<\/p>\n\n\n\n

This guide explains what CMAF is, how it works, and why it has quietly become the default packaging layer for modern HTTP streaming pipelines \u2014 with particular attention to what it means for delivery cost and CDN efficiency, the part most explanations skip. We will cover the double-packaging problem it solves, the segment-fragment-chunk structure that makes low latency possible, how it relates to HLS, DASH, MP4, and MPEG-TS, and where it fits in a modern streaming stack in 2026.<\/p>\n\n\n\n

What Is CMAF?<\/strong><\/h2>\n\n\n\n

CMAF (Common Media Application Format) is a standardized, fragmented-MP4 media format that packages streaming video and audio into a single set of segments that both HLS and DASH<\/a> can deliver. Standardized as ISO\/IEC 23000-19<\/a>, it lets you encode and store content once instead of maintaining separate MPEG-TS and fMP4 copies for each protocol.<\/p>\n\n\n\n

A key clarification up front: CMAF is not a streaming protocol and not a codec. It is a container format \u2014 a set of rules for how media segments are structured and packaged. Protocols like HLS<\/a> and DASH still handle how a player requests and plays those segments; CMAF just standardizes the segments themselves so both protocols can share them.<\/p>\n\n\n\n

What Does CMAF Stand For?<\/strong><\/h2>\n\n\n\n

CMAF stands for Common Media Application Format. The name captures its purpose precisely: a common format, shared across applications and playback platforms, so the industry can stop maintaining parallel packaging workflows. It was jointly proposed to MPEG by Apple and Microsoft in 2016 and published as an international standard in 2018.<\/p>\n\n\n\n

Why CMAF Exists: The Double-Packaging Problem<\/strong><\/h2>\n\n\n\n

To understand why CMAF matters, it helps to know the problem it solves. When the industry moved away from Flash and RTMP toward HTTP-based adaptive bitrate streaming, two protocols came to dominate: Apple’s HLS and the open MPEG-DASH standard.<\/p>\n\n\n\n

\"Legacy
The double-packaging problem<\/strong><\/figcaption><\/figure>\n\n\n\n

The catch was that they used different container formats. HLS historically required MPEG-2 Transport Stream (.ts) segments, while DASH used fragmented MP4 (fMP4). Reaching both audiences meant encoding and storing the same audio and video twice \u2014 in two different wrappers holding essentially identical media.<\/p>\n\n\n\n

That duplication is expensive in three compounding ways: double the packaging work, double the origin storage, and \u2014 critically \u2014 two separate objects competing for space in every CDN edge cache. CMAF collapses those two sets into one, which is where its cost story really lives (more on that below).<\/p>\n\n\n\n

It helps to make the duplication concrete. Suppose you offer a single video in four bitrate renditions (say 240p, 480p, 720p, and 1080p) with one audio track. Under the old model you would package each rendition twice \u2014 once as MPEG-TS for HLS and once as fMP4 for DASH \u2014 producing two parallel sets of segment files that hold the same underlying media. Add DRM to the mix and it gets worse: because HLS FairPlay historically used one encryption mode and DASH Widevine\/PlayReady used another, you could end up encrypting and storing several distinct encrypted copies of identical content. Every one of those copies has to be transcoded, stored on origin, and cached at the edge independently.<\/p>\n\n\n\n

This was not a minor annoyance. As streaming scaled to millions of concurrent viewers across iPhones, Android phones, smart TVs, game consoles, and browsers, the cost of maintaining parallel workflows became a real line item \u2014 in storage bills, in origin egress, and in the engineering overhead of keeping two packaging pipelines in sync. The industry needed one container that every HTTP protocol could agree on. That is the problem CMAF was created to solve.<\/p>\n\n\n\n

A Short History of CMAF<\/strong><\/h2>\n\n\n\n

CMAF is often described as a technical achievement, but its bigger accomplishment was diplomatic \u2014 getting competing platform owners to standardize on one container. The timeline is worth knowing because it explains why CMAF looks the way it does.<\/p>\n\n\n\n

The story starts with the decline of Flash and RTMP around 2016\u20132020. As browsers dropped Flash, the industry moved to HTTP-based adaptive bitrate streaming, and two approaches took hold: Apple’s HLS<\/a> (built on MPEG-TS) and MPEG-DASH (built on fragmented MP4). In February 2016, Apple and Microsoft jointly proposed a common format to the Moving Picture Experts Group (MPEG). In June 2016, Apple announced HLS support for fragmented MP4 \u2014 the same container Microsoft already favored \u2014 which was the pivotal concession that made a shared format possible. Specifications were finalized in July 2017, and CMAF was published as ISO\/IEC 23000-19 in 2018. Subsequent editions refined the specification, and the third edition (2024) is the reference production deployments target today.<\/p>\n\n\n\n

The takeaway: CMAF did not invent a new file format from scratch. It standardized fragmented MP4 into a single, portable profile that both HLS and DASH could consume \u2014 turning a two-container world into a one-container one.<\/p>\n\n\n\n

How CMAF Works<\/strong><\/h2>\n\n\n\n

CMAF achieves this unification through a small number of well-defined building blocks.<\/p>\n\n\n\n

\"CMAF
Segment \/ fragment \/ chunk hierarchy<\/strong><\/figcaption><\/figure>\n\n\n\n

Fragmented MP4 and ISOBMFF<\/strong><\/h3>\n\n\n\n

CMAF is built on the ISO Base Media File Format (ISOBMFF)<\/a>, the same foundation as MP4. A regular MP4 stores its indexing information (the ‘moov’ box) describing the whole file, which means a player generally needs the complete file before it can play smoothly \u2014 fine for downloads, awkward for live streaming.<\/p>\n\n\n\n

Instead of one continuous file, CMAF writes content as fragmented MP4 (fMP4) \u2014 small, independently decodable pieces with a .m4s extension, each carrying its own moof\/mdat box pair (movie fragment metadata plus the media data). Because each fragment is self-describing, a player can fetch and decode it without the whole file. And because both modern HLS and DASH can consume fMP4, a single CMAF-packaged segment can be referenced by an HLS playlist (.m3u8) and a DASH manifest (.mpd) at the same time. The manifests differ; the media segments they point at are identical.<\/p>\n\n\n\n

Segments, Fragments, and Chunks<\/strong><\/h3>\n\n\n\n

CMAF defines a clear hierarchy, and understanding it is the key to understanding CMAF’s latency story. A CMAF track (video, audio, or subtitles) is divided into segments \u2014 the addressable unit a player requests over HTTP. Segments are made up of one or more fragments, and fragments can be further subdivided into chunks. A chunk is the smallest unit and can contain as little as a single frame’s worth of data.<\/p>\n\n\n\n

This nesting is what makes low latency possible. With traditional segment-based streaming, a player has to wait for an entire segment \u2014 often two to ten seconds long \u2014 to be fully encoded and downloaded before playback of that segment can begin. That waiting is a major source of the multi-second delay in older HTTP streaming. CMAF’s chunk structure removes that constraint.<\/p>\n\n\n\n

Chunked Encoding and Chunked Transfer<\/strong><\/h3>\n\n\n\n

With chunked encoding and chunked transfer encoding, each small chunk can be published and delivered the moment it is encoded, while later chunks in the same segment are still being produced. The encoder emits chunks continuously, and HTTP chunked transfer encoding streams them to the player as they arrive rather than waiting for the whole segment file to close.<\/p>\n\n\n\n

The classic analogy is a meal served in courses rather than all at once \u2014 you start the appetizer while the kitchen finishes the main. In streaming terms, the player starts decoding the opening chunks of a segment while its final chunks are still being encoded upstream. This is how CMAF brings glass-to-glass latency down from the 30\u201345 seconds typical of early HTTP streaming to the low-single-digit-second range, without abandoning the HTTP delivery model that makes CDN scaling possible in the first place.<\/p>\n\n\n\n

Common Encryption (CENC)<\/strong><\/h3>\n\n\n\n

CMAF pairs naturally with Common Encryption (CENC), which lets a single set of segments be protected once and decrypted by multiple DRM systems<\/a> \u2014 Widevine, PlayReady, and FairPlay. Historically this was another source of duplication: FairPlay used the ‘cbcs’ scheme (AES-CBC with pattern encryption) while Widevine and PlayReady commonly used ‘cenc’ (AES-CTR), so protecting content for all three meant encrypting separate copies.<\/p>\n\n\n\n

The alignment of the industry around the ‘cbcs’ scheme changed that. With cbcs Common Encryption, the same encrypted CMAF segments can be decrypted by every major DRM, so you encrypt once and serve everyone. Combined with the single-container packaging, this removes one of the last places where the old workflow forced you to store multiple copies of identical content \u2014 which is exactly why CMAF plus CENC is treated as the modern default for protected streaming.<\/p>\n\n\n\n

CMAF and CDN Delivery: Cache Efficiency and Cost<\/strong><\/h2>\n\n\n\n

This is where CMAF pays off in infrastructure terms, and it is the part most explanations underplay. A CDN accelerates delivery by caching content at edge locations close to viewers. The more often a requested object is already sitting in the edge cache, the higher your cache hit ratio \u2014 and the less traffic has to travel back to origin.<\/p>\n\n\n\n

\"CDN
CDN cache efficiency<\/strong><\/figcaption><\/figure>\n\n\n\n

Before CMAF, HLS (.ts) and DASH (fMP4) versions of the same video were two distinct objects. Each edge cache had to store both, and each competed for the same finite cache space \u2014 effectively halving efficiency for that content. With CMAF, both the HLS and DASH manifests point at the same<\/em> .m4s segments. The edge caches one object, not two, so the same footprint covers both protocols and the effective cache hit ratio<\/a> roughly doubles for that content.<\/p>\n\n\n\n

Stacked together, the operational wins are substantial: encoding and storage overhead drops by up to around 75% when you stop maintaining parallel .ts and fMP4 renditions, origin storage is halved, and edge cache efficiency improves because there is a single shared object to serve. For anyone paying for storage and delivery at scale, that is a direct line to lower cost.<\/p>\n\n\n\n

A simplified worked example makes the cache effect concrete. Imagine a popular live event with a full bitrate ladder cached at an edge node. Under the old model, that edge stored the HLS (.ts) copy and the DASH (fMP4) copy of every rendition \u2014 two objects per rendition, splitting requests and cache space between them. A viewer on an Apple device pulled the .ts version; a viewer on Android pulled the fMP4 version; the edge had to keep both warm. Under CMAF, both devices request the same .m4s objects. The edge keeps one warm copy that satisfies everyone, so a larger share of requests are served from cache instead of falling through to origin.<\/p>\n\n\n\n

Two things follow directly. First, origin offload improves \u2014 fewer cache misses mean fewer trips back to origin, which lowers origin egress and load during traffic spikes. Second, more of your cache budget goes to breadth of content rather than duplicate copies of the same content, so a given edge footprint effectively covers more of your catalog. For a live-sports or FAST operator serving unpredictable, spiky demand, that headroom is exactly what protects the viewer experience at peak.<\/p>\n\n\n\n

CMAF vs fMP4 vs MP4<\/strong><\/h2>\n\n\n\n

These three terms are often confused. MP4 is a traditional container designed to hold a complete video file for download or progressive playback \u2014 great for local files, poor for adaptive streaming. Fragmented MP4 (fMP4) breaks that container into smaller independently decodable pieces suited to streaming. CMAF is a standardized profile of fMP4: it specifies exactly how those fragments are structured so they are interoperable across HLS and DASH rather than packaged in slightly different, incompatible ways.<\/p>\n\n\n\n

Put simply: all CMAF segments are fMP4, but not all fMP4 is CMAF-compliant. CMAF is the agreed-upon, portable way to do fMP4.<\/p>\n\n\n\n

CMAF vs MPEG-TS<\/strong><\/h2>\n\n\n\n

MPEG-TS (MPEG-2 Transport Stream, the .ts container) is the format HLS used from its 2009 launch. It was designed decades ago for broadcast transport \u2014 satellite and cable \u2014 where resilience to transmission errors mattered more than storage efficiency. Apple chose it originally because early iOS devices decoded MPEG-TS natively in hardware.<\/p>\n\n\n\n

The trade-off is overhead and duplication. MPEG-TS carries extra packet structure that adds bytes relative to fMP4, and because the rest of the streaming world (browsers, Android, smart TVs, DASH) standardized on fragmented MP4, sticking with MPEG-TS meant maintaining a container almost nobody else used. CMAF’s move to fMP4 for HLS is what finally let HLS and DASH share one set of files.<\/p>\n\n\n\n

MPEG-TS has not disappeared \u2014 it still appears in legacy device support, some contribution\/ingest workflows, and older set-top environments \u2014 so a small MPEG-TS fallback is sometimes retained for backward compatibility. But for new HTTP delivery, CMAF (fMP4) is the default, and MPEG-TS is the legacy path you keep only where you must.<\/p>\n\n\n\n

CMAF, HLS, and DASH: How They Fit Together<\/strong><\/h2>\n\n\n\n

It is a common misconception that CMAF competes with HLS or DASH. It does not. HLS and DASH are delivery protocols \u2014 they define the manifest and how a player fetches and sequences segments. CMAF is the container the segments are packaged in. They operate at different layers and are designed to work together.<\/p>\n\n\n\n

Attribute<\/strong><\/th>HLS \/ DASH<\/strong><\/th>CMAF<\/strong><\/th><\/tr><\/thead>
Type<\/td>Streaming protocol<\/td>Container format<\/td><\/tr>
Role<\/td>Defines how segments are requested and played<\/td>Defines how segments are packaged and stored<\/td><\/tr>
Manifest<\/td>.m3u8 (HLS) \/ .mpd (DASH)<\/td>None \u2014 CMAF is the segment, not the manifest<\/td><\/tr>
Segment file<\/td>References the segment<\/td>.m4s (fragmented MP4)<\/td><\/tr>
Relationship<\/td>Deliver CMAF segments<\/td>Packaged once, served by both<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

The modern best practice is CMAF packaging delivered over both HLS and DASH: one shared set of .m4s segments, two lightweight manifests. Choosing a protocol without CMAF means accepting legacy double-packaging overhead.<\/p>\n\n\n\n

CMAF for Low-Latency Streaming<\/strong><\/h2>\n\n\n\n
\"Streaming
Latency ladder<\/strong><\/figcaption><\/figure>\n\n\n\n

Chunked CMAF is one of the main tools behind modern low-latency streaming<\/a>. By delivering chunks as they are produced, CMAF typically achieves 2\u20135 seconds of glass-to-glass latency \u2014 close to broadcast television and a dramatic improvement over the 30\u201345 seconds of early HTTP streaming.<\/p>\n\n\n\n

Where does that sit relative to other options? Low-Latency HLS (LL-HLS) lands in a similar 2\u20138 second band and is often implemented using CMAF-style partial segments anyway. WebRTC goes further, to sub-second latency, but is harder to scale to large audiences and less CDN-friendly. CMAF hits the sweet spot for most one-to-many use cases: low latency, broad device support, and cost-efficient CDN delivery. That makes it a strong fit for live sports, live commerce, betting, news, and FAST channels<\/a>.<\/p>\n\n\n\n

Where CMAF Is Used<\/strong><\/h2>\n\n\n\n