CMAF Explained: One Format for HLS and DASH

For most of the 2010s, streaming companies stored every video twice: once as MPEG-TS segments for HLS, and again as fragmented MP4 segments for DASH. Two sets of files meant double the storage, half the CDN cache efficiency, and more packaging work. CMAF, the Common Media Application Format, was created to end that. Here is CMAF explained in plain terms. It is simpler than it sounds.

This guide explains what CMAF is, what problem it solves, how chunked CMAF enables low-latency streaming, and how to adopt it.

What CMAF is

CMAF is an MPEG standard (ISO/IEC 23000-19), first published in 2018. It was proposed by Apple and Microsoft in 2016 and developed with input from many streaming companies. It defines a common way to package media segments based on the ISO Base Media File Format (the same family as MP4), specifically fragmented MP4 (fMP4).

A CMAF stream is made of:

• A header (initialisation segment): information the decoder needs before playback, such as codec settings.
• Segments: the actual media, each one or more CMAF fragments.
• Chunks: optional smaller pieces inside a segment, used for low latency.

What CMAF does not define is the manifest. HLS playlists and DASH MPDs both point to the same CMAF files, each in their own format. That is the point: one set of media, two ways to describe it.

Why CMAF matters

1. One set of files instead of two

Before CMAF, a typical multi-platform service had:

• HLS with .ts segments for Apple devices.
• DASH with .m4s fMP4 segments for Android, browsers and TVs.

With CMAF, both HLS and DASH use the same fMP4 segments. You store them once, and only the small manifest files differ. For large libraries, that roughly halves the storage for packaged output.

2. Better CDN caching

When Apple and Android viewers request the same segment file, the CDN serves both from one cached copy. Higher cache hit ratios mean faster start times and lower origin costs, especially for live events where everyone watches the same segments at the same moment.

3. Simpler DRM

CMAF works with Common Encryption (CENC). With the cbcs encryption scheme, the same encrypted segments can be unlocked by FairPlay, Widevine and PlayReady. That is the foundation of practical multi-DRM. Before CMAF, many services encrypted content separately for FairPlay and for Widevine/PlayReady.

4. Low latency

CMAF defines chunks, which are small pieces of a segment that can be sent as soon as they are encoded, before the whole segment is finished. That is how LL-DASH and LL-HLS get latency down to a few seconds. More on that below.

How a CMAF file is structured

A CMAF track is built from standard MP4 “boxes”:

• ftyp and moov in the header, describing the track and codec.
• moof and mdat pairs for each fragment: moof holds timing and sample information, mdat holds the media data.
• styp optionally at the start of each segment.
• pssh and tenc boxes when the content is encrypted, carrying DRM information and default key IDs.

In an HLS playlist, you see the header referenced with #EXT-X-MAP:URI="init.mp4", followed by segment lines. In a DASH MPD, the header appears as the initialization attribute of a SegmentTemplate. Our M3U8 analyzer tells you whether a playlist uses fMP4 by looking for #EXT-X-MAP.

CMAF constraints

CMAF is stricter than “any fragmented MP4”. To be compliant, content must follow rules that make interoperability easier, including:

• One media track per file (video and audio in separate tracks).
• Segments must start with a keyframe (a random access point) for video.
• Consistent timescales and codec settings within a track.
• Defined profiles for codecs such as H.264 (cfhd, chdf), HEVC, AAC and others.

These rules sound technical, but modern packagers apply them automatically when you choose CMAF output.

Chunked CMAF and low latency

In classic streaming, a 6-second segment cannot be published until all 6 seconds are encoded. Add player buffering and you are 15 to 30 seconds behind live.

Chunked CMAF changes that. The encoder splits each segment into chunks, often 200 to 500 milliseconds long, each a small moof+mdat pair. The packager and CDN pass chunks to the player as soon as they exist, using HTTP chunked transfer encoding. The player can start decoding the beginning of a segment while the end is still being encoded.

• LL-DASH uses chunked CMAF directly, with the player requesting segments that are still being produced.
• LL-HLS uses the same idea but describes the pieces as partial segments (#EXT-X-PART) in the playlist, with preload hints and blocking playlist reloads.

Both routes get to roughly 2 to 5 seconds of latency at scale. See our guide to low-latency streaming for the full comparison.

Codecs supported

CMAF includes profiles for the main codecs in use today:

• Video: H.264/AVC, H.265/HEVC, AV1 (added in later editions), VP9 in some ecosystems.
• Audio: AAC, AC-3, E-AC-3 (Dolby Digital Plus), AC-4, Opus in some profiles.
• Subtitles: WebVTT and IMSC1 (TTML) text tracks.

The codec you pick still has to be supported by the viewer’s device. Check with our codec support checker and read H.264 vs H.265 vs AV1.

Device compatibility

Most devices made in the last several years play fMP4 segments in both HLS and DASH. Apple added fMP4 support to HLS in iOS 10 and macOS Sierra (2016). Android’s ExoPlayer, smart TV platforms and browser players all support it.

The exceptions are older HLS-only devices, some legacy set-top boxes and a few older smart TVs that only understand MPEG-TS. If your analytics show a significant audience on those, keep a TS fallback for them. For most new services, CMAF alone is enough.

How to package CMAF

Popular tools:

• Shaka Packager (open source): produces CMAF with HLS and DASH manifests, including DRM.
• Bento4 (open source): mp4fragment, mp4dash and related tools.
• GPAC / MP4Box (open source): extensive DASH and CMAF support.
• FFmpeg: can write fMP4 HLS (-hls_segment_type fmp4) and DASH, though dedicated packagers offer more control.
• Cloud and commercial packagers: AWS Elemental MediaPackage and MediaConvert, Unified Streaming, Wowza, and most online video platforms.

A Shaka Packager example that creates CMAF with both manifests from pre-encoded renditions:

packager \
  in=video_1080.mp4,stream=video,init_segment=1080/init.mp4,segment_template=1080/$Number$.m4s \
  in=video_720.mp4,stream=video,init_segment=720/init.mp4,segment_template=720/$Number$.m4s \
  in=audio.mp4,stream=audio,init_segment=audio/init.mp4,segment_template=audio/$Number$.m4s \
  --segment_duration 4 \
  --hls_master_playlist_output master.m3u8 \
  --mpd_output manifest.mpd

Encode your renditions first with aligned keyframes. Our encoding settings guide shows how.

Migrating from TS to CMAF

If you already serve HLS with .ts segments:

1. Check your player. hls.js, Video.js, Shaka Player, native Safari, ExoPlayer and major commercial players all support fMP4 HLS.
2. Repackage, do not re-encode. You can usually remux existing renditions to fMP4 without touching video quality.
3. Run both in parallel for a while, serving CMAF to modern devices and TS to legacy ones.
4. Add DASH manifests pointing to the same CMAF files.
5. Move DRM to cbcs if you use FairPlay, so all DRMs share one encrypted copy.
6. Retire TS once legacy traffic is negligible.

Test each step with our HLS player and DASH player.

CMAF and subtitles

Text tracks often get forgotten in packaging plans. CMAF supports two main subtitle formats, each carried as its own track:

• WebVTT, the simple text format most web players understand, packaged in fMP4 as wvtt samples, or delivered as separate .vtt files referenced from HLS and DASH manifests.
• IMSC1, a profile of TTML used by broadcasters, packaged as stpp samples. It supports richer styling and positioning.

For most web and app projects, WebVTT is the easiest route. Broadcasters that already produce TTML often keep IMSC1 so captions look identical across TV and online.

CMAF and storage in numbers

To see why CMAF matters for budgets, take a library of 5,000 hours with a five-rung ladder averaging 2.5 Mbps across rungs. One packaged copy is roughly 5,000 × 3,600 × 2.5 × 5 ÷ 8 megabytes, or about 28 TB. Keeping separate TS and fMP4 copies doubles that to around 56 TB. At typical object storage prices of about $0.015 to $0.023 per GB-month, the second copy costs several hundred dollars every month, before counting the lower CDN cache efficiency. Moving everything to one CMAF copy removes that cost entirely.

Frequently seen CMAF mistakes

• Mixing audio into video tracks. CMAF expects separate tracks. Muxed audio and video in one fMP4 file works in some players but breaks others.
• Unaligned segment boundaries between renditions, which causes glitches when the player switches quality.
• Different encryption keys or schemes between HLS and DASH manifests for the same files. Both manifests must describe the same cbcs or cenc scheme and key IDs.
• Missing #EXT-X-MAP in HLS playlists, so players cannot find the initialisation segment.

How to tell whether a stream already uses CMAF

You do not need special tools. Open the stream’s HLS playlist and look for #EXT-X-MAP. If it is there and the segments end in .m4s or .mp4, the stream uses fragmented MP4, which is almost always CMAF-compatible. If segments end in .ts and there is no map line, it is MPEG-TS. Our M3U8 analyzer reports this for you.

For DASH, open the MPD and check the profiles attribute and the mimeType of each adaptation set. A video/mp4 mime type with a cmaf profile, or isoff-live with separate audio and video adaptation sets, is a good sign. Load the manifest in the DASH player to confirm it plays.

It is common to find a half-way state: fMP4 segments that are not strictly CMAF, for example with audio muxed into video. They often still work, but they will not share cleanly between HLS and DASH. Repackaging with a CMAF-aware packager fixes that without touching the encoded video.

Three questions teams ask before switching

Will it break old devices? Sometimes. Keep a TS fallback if your analytics show real traffic from pre-2017 hardware.

Does it cost more? No. It usually costs less.

Is it hard? No. Most packagers need one flag changed.

And the video? Untouched. Your encoded renditions stay exactly as they are.

Summary

CMAF is a standard fMP4 packaging format that lets HLS and DASH share one set of media segments. It cuts storage, improves CDN caching, makes multi-DRM practical with cbcs encryption, and enables low-latency streaming through chunks. It is not a protocol, and it does not replace HLS or DASH. It makes supporting both almost free. For any new streaming project, CMAF should be the default.