CMAF (Common Media Application Format)

CMAF (Common Media Application Format) is an MPEG standard. It is ISO/IEC 23000-19, Part 19 of the MPEG-A multimedia application format family. It specifies how segmented media is packaged and encrypted, so that HLS and DASH players can stream the same files. One set of fragmented-MP4 segments serves both protocols. You encode, package, store and cache once. Each protocol’s manifest then points at the same objects. CMAF is not a protocol. It specifies no manifest, no player and no delivery protocol of its own. It is not a codec either; it constrains how coded media is packaged. It also defines the chunk, the sub-segment unit that low-latency live streaming is built on.

How it works

Three editions have been published: ISO/IEC 23000-19:2018, :2020 and :2024. The current one is edition 3, published February 2024. It carries two amendments. Amd 1:2024 added Low Complexity Enhancement Video Coding (LCEVC) and other technologies. Amd 2:2026 added a further structural CMAF brand profile. ISO lists the standard as due for revision, and MPEG has a fourth edition in progress. So treat brand and profile lists as living, not fixed. The object model itself has been stable throughout. CMAF derives its container from the ISO Base Media File Format (ISOBMFF), the fragmented-MP4 family. It defines two layers of objects.

The first layer describes how content is structured:

• CMAF Track: one media component (audio, video or subtitles). It is a CMAF Header followed by one or more CMAF Fragments. Media samples may optionally be protected with MPEG Common Encryption.
• CMAF Fragment: a movie fragment of media samples. Combined with its CMAF Header, it is independently decodable and decryptable. Fragments are the boundary at which playback switches quality.
• CMAF Switching Set: alternative tracks of the same content at different bit rates and resolutions. They switch and splice at fragment boundaries, so adaptive-bitrate switching stays seamless.
• CMAF Selection Set: alternative switching sets. Examples: a different language, a different camera angle, or the same content in a different codec.
• CMAF Presentation: presentation-time-synchronised selection sets. This is the first point at which different media types are combined.

The second layer is the addressable media objects: what a URL actually points at.

• CMAF Header: the initialisation data for a track. HLS references it with an EXT-X-MAP tag.
• CMAF Segment: a sequence of one or more consecutive fragments from the same track. This is the object that HLS and DASH manifests address. In an HLS Media Playlist, a CMAF Segment is used directly as an HLS Segment.
• CMAF Chunk: a sequential subset of the samples in a fragment, so smaller than a fragment. A segment carrying chunks contains several moof/mdat box pairs instead of one. That is what lets a player read media before the segment is finished.
• CMAF Track File: a complete track in a single ISOBMFF file.

The pipeline works like this. Encode each rendition once into CMAF fragments, package them into segments, then write two lightweight manifests: an .m3u8 for HLS and an .mpd for DASH. Both reference the same objects. No second container is produced. The two protocols just describe the same files differently. CMAF media profiles make that interoperable. Each profile fixes the codec and encoding constraints and is identified by a registered ISOBMFF brand. A device can then tell from the brand whether it can play the content. See Apple’s CMAF with HLS for the mapping of these objects onto playlists.

Here is how both protocols point at the same files:

# HLS manifest (playlist.m3u8)
#EXTM3U
#EXT-X-VERSION:7
#EXT-X-TARGETDURATION:4
#EXT-X-MAP:URI="init.mp4"
#EXTINF:4.0,
segment_001.m4s
#EXTINF:4.0,
segment_002.m4s

<!-- DASH manifest (manifest.mpd) -->
<SegmentTemplate
  initialization="init.mp4"
  media="segment_$Number%03d$.m4s"
  startNumber="1"
  duration="4" />

Chunks are what make low-latency live delivery possible. The packager can publish each chunk as soon as it is encoded, instead of waiting to encode and package every sample in the fragment. The two protocols then move those chunks over HTTP in different ways. That difference lands on the CDN.

• LL-DASH streams the still-growing segment with HTTP/1.1 chunked transfer encoding. It signals this in the MPD with @availabilityTimeComplete set to false, plus @availabilityTimeOffset. That field tells the client how much earlier a segment is available than its computed availability start time. DASH-IF’s low-latency guidance requires the server to support chunked transfer encoding.
• LL-HLS does not use chunked transfer encoding. Each piece is published as a separately addressable Partial Segment: its own URI, or a BYTERANGE of the parent segment. It is advertised with an EXT-X-PART tag. Clients discover updates with blocking playlist reloads, driven by _HLS_msn and _HLS_part query parameters on the playlist URI, per HTTP Live Streaming 2nd Edition (still an Internet-Draft). A CMAF chunk is the usual payload of a Partial Segment, but the spec does not require one.

Encryption is part of the format, not bolted on. CMAF uses MPEG Common Encryption, so one encrypted copy can be decrypted by different DRM systems on different devices. The standard defines three presentation profiles: unencrypted, encrypted with ‘cbcs’, and encrypted with ‘cenc’.

Why it matters for a CDN

Before CMAF, reaching both protocol camps meant packaging the same programme twice. HLS specified TS containers, while DASH in practice used ISOBMFF. So the same audio and video had to be stored twice. As Akamai puts it, those were files that “cost twice as much to package, twice as much to store on origin and compete on Akamai edge caches for space, thus reducing the delivery efficiency.” CMAF collapses that to one set of files.

Three consequences follow. All of them are cache economics.

• One copy per rendition. Each fragment is stored and cached only once. A single cached object then serves HLS and DASH viewers alike: cache hit ratio rises, and origin storage and egress fall.
• Late binding of single-track segments. CMAF stores each media component in its own track. So one audio segment set serves every video rendition. Multiplexing audio into video instead produces a segment per combination. In MPEG’s words, that “greatly reduces cache efficiency by increasing the number of alternative segments.”
• Live scales on cache, not backbone. CMAF segments are delivered once to edge servers. From there they are served from cache to thousands of players, without extra backbone traffic or transmission delay.

Low-latency CMAF adds two concrete CDN requirements. For LL-DASH, the edge must forward a chunked response as it arrives, rather than buffer the whole segment. For LL-HLS, the edge must treat the _HLS_msn, _HLS_part and _HLS_skip query parameters as part of the cache key. It must also hold blocking playlist requests open, instead of answering them from a stale playlist. And it must serve byte-range requests against parent segments that are still growing.

What CDNs do

• Akamai (opt-in). Media Services Live offers CMAF ingest. You point your encoder at the CMAF entrypoints. The ingested stream is then played back from the same path as either HLS (master.m3u8) or DASH (file.mpd). Akamai credits CMAF with ending the double-packaging cost above. Akamai: CMAF
• AWS (opt-in). MediaPackage lets you choose CMAF or TS as the container for HLS and LL-HLS endpoints. MediaConvert offers CMAF as an ABR output group. AWS notes that a single CMAF package can replace separate DASH ISO and Apple HLS packages, “because you must store and distribute only one set of video and audio files.” AWS MediaPackage: HLS and LL-HLS · AWS MediaConvert: ABR output groups
• Cloudflare (automatic, with a caveat). On 13 April 2026, Stream switched on-demand HLS manifests from MPEG-TS (.ts) to fragmented MP4 (.mp4) segments. That is the container family CMAF constrains, though Cloudflare does not document CMAF conformance. Manifest URLs did not change. The switch was transparent for most customers. But anyone caching HLS manifests outside Stream had to refresh them: stale segment references return 404 after 13 May 2026. Cloudflare Stream changelog

Watch out for

• There is a client floor. HLS only defined support for fragmented MPEG-4 segments in September 2016. Apple states that clients based on earlier revisions will likely not handle CMAF content. Apple hardware from iOS 10.0, macOS 10.12 and tvOS 10.0 onward should. To reach anything older, you still need an MPEG-TS set. That brings the second copy back.
• Valid CMAF is not just any fMP4. “Encode once” only holds if the packager emits a conforming media profile: codec and encoding constraints, plus a registered brand. A generic fragmented-MP4 stream is not necessarily CMAF. A device that identifies content by brand may refuse it.
• CMAF forces demuxed audio and video. A CMAF Segment cannot, in general, carry multiple media types. So audio and subtitles need their own playlists, associated with the video tier through EXT-X-MEDIA group IDs in HLS. That is the price of the cache win above: more manifest plumbing, more requests per viewer, and no single muxed A/V object.
• The encryption profile is a one-way door. HLS supports only the unencrypted and ‘cbcs’ presentation profiles. So an encrypted set that must also play over HLS cannot use ‘cenc’. In HLS, ‘cbcs’ is signalled by an EXT-X-KEY tag with METHOD=SAMPLE-AES, per ISO/IEC 23001-7. Choose before you package. Re-encrypting means re-packaging and a cold cache.
• Low latency is a tuning problem, not a switch. AWS documents standard HLS at typically 18 to 30 seconds, and LL-HLS as reaching as low as 3 to 5 seconds: a range, not a guarantee. The HLS specification is blunt about the trade-off. A shorter target duration reduces latency, but it also reduces available buffer, handicaps adaptation and increases delivery overhead. That raises the likelihood of a playback stall. Nothing here is sub-second video.
• Extensions and players still bite. MediaConvert writes CMAF video segments as .cmfv. AWS notes that a few uncommon DASH players require the .mp4 video segmentation extension. For those, you must keep a DASH ISO output. Conversely, delivering HDR or HEVC to Apple devices from MediaConvert requires a CMAF output group.
• Switching sets have to be encoded to the constraints. CMAF constrains a switching set so that one buffer and one decoder can serve the whole set, and switches splice at fragment boundaries. Renditions produced outside those constraints will not switch seamlessly on deployed devices and browsers, however tidy the manifest looks.

Best practice

• Verify the brand your packager emits, so that “encode once” is genuinely CMAF rather than lookalike fMP4.
• Serve one CMAF segment set behind both an .m3u8 and an .mpd. Keep an MPEG-TS set only for the pre-2016 clients you are contractually obliged to reach.
• Pick the encryption profile against the DRM systems and protocols you must support, before packaging. Use ‘cbcs’ if HLS is in scope. Test playback on real devices, not just in a browser.
• Treat low latency as a system property. Choose segment and chunk durations and hold-back values deliberately. Then confirm the CDN forwards chunked responses for LL-DASH, and honours the _HLS_ delivery directives for LL-HLS.
• Keep every rendition in a switching set encoded to CMAF’s switching constraints. Keep audio in its own tracks, so one audio set can serve all video renditions.