CMAF Explained: One Set of Segments for HLS and DASH

Supporting HLS and MPEG-DASH often leaves a media team storing, validating, caching, and invalidating two almost identical sets of video. CMAF removes much of that duplication by giving both protocols a common media format while keeping their separate manifests and player behavior.

The result can be a simpler origin and a more reusable CDN cache, but it is not automatic. The codec, segment timeline, encryption mode, URLs, packager, CDN, and players still have to agree. This guide explains the shared-media model, the low-latency path, the limits, and the checks that turn CMAF from a format choice into a reliable production workflow.

What is CMAF?

CMAF, or Common Media Application Format, is a standardized format for packaging segmented audio, video, and timed text. It lets an HLS playlist and a DASH MPD reference the same fragmented MP4 media objects, so the media can be encoded and stored once while each protocol keeps its own manifest.

The current published base standard is ISO/IEC 23000-19:2024. ISO describes CMAF as segmented media derived from the ISO Base Media File Format, with track, switching, and presentation constraints designed for adaptive delivery. The CMAF Industry Forum frames the practical goal as interoperability between HLS and DASH.

Three distinctions prevent most early design mistakes:

• CMAF is not a codec. A CMAF track contains encoded samples, but codec support still depends on the media profile and target device.
• CMAF is not a manifest. HLS still uses .m3u8 playlists and DASH still uses an XML .mpd file.
• CMAF is not a transport protocol. The media still moves over HTTP, and low-latency delivery requires protocol, server, CDN, and player behavior beyond the file structure.

Think of CMAF as the common media layer beneath two delivery languages. The HLS and DASH control planes remain different; the heavy audio and video objects underneath can be shared.

CMAF in 2026: a stable core with active profiles

The 2024 third edition remains the current published base standard. ISO now lists two amendments, including a 2026 amendment for an additional structural CMAF brand profile, and marks the base standard as due for revision. That is normal standards maintenance, not a reason to postpone a sound deployment.

For operators, the version label is less useful than the declared brand and media profile. Those signals tell a parser which structural and codec constraints the content claims to satisfy. A packager update can produce technically different output while keeping the same .m4s filename and application configuration, so treat packager upgrades like encoder changes: retain sample output, inspect the boxes and brands, and rerun the player matrix.

Do not assume a newer structural profile expands support on an older device. Your compatibility floor remains the intersection of container parsing, codec decoding, encryption, manifest behavior, and player implementation. Track the standard for new capabilities, but ship only the profile you have validated end to end.

CMAF vs HLS, DASH, fMP4, and MP4

These terms describe different layers, even though they often appear in the same workflow.

All CMAF media uses an ISO BMFF-derived fragmented structure, but not every arbitrary fMP4 file is a valid, interoperable CMAF track. CMAF narrows the larger format: it adds profiles, timing rules, switching constraints, brands, and a model for addressable media objects.

That difference matters in browsers. The W3C ISO BMFF byte-stream note defines an initialization segment around ftyp and moov boxes, then media around moof and mdat boxes. It also requires enough brand, codec, timing, and random-access information for a user agent to append and decode the stream. A file ending in .m4s can still fail if those requirements or the supported codec profile do not line up.

The same layering explains why “CMAF versus HLS” is the wrong comparison. HLS can carry MPEG-2 Transport Stream segments or fragmented MP4 segments. CMAF is one way to condition the fragmented MP4 media that HLS carries; DASH can reference that same conditioned media.

For a deeper look at their control planes, compare the HLS streaming guide with MPEG-DASH explained.

How CMAF serves HLS and DASH with one media set

A conventional dual-format workflow may produce one encoded ladder packaged as MPEG-TS for HLS and another fragmented MP4 ladder for DASH. Even when the underlying pictures and audio are equivalent, the origin sees different objects and the CDN sees different cache keys.

A converged workflow looks like this:

1. The encoder creates aligned video renditions and separate audio or text tracks.
2. The packager writes CMAF-compatible headers and fragmented media for each track.
3. It creates an HLS multivariant playlist plus HLS media playlists.
4. It creates a DASH MPD describing the same renditions and timeline.
5. Both manifest families resolve to the same media-object URLs.
6. HLS and DASH players request those objects and interpret them through their own protocol rules.

Apple's CMAF guidance for HLS explicitly describes HLS playlists and a DASH MPD sharing CMAF addressable objects. That last detail—sharing the resources, not merely producing byte-identical copies—is where much of the operational value appears.

Tracks, switching sets, headers, segments, and chunks

A CMAF track is one continuous encoded media stream: for example, one video rendition, one language-specific audio track, or one subtitle track. A track has initialization information and a sequence of fragments.

A switching set groups alternative tracks that a player can switch between, such as the rungs of one video ladder. Safe switching depends on equivalent content being aligned at permitted boundaries. Resolution and bitrate may differ; the media timeline must still make sense when a player moves from one track to another.

A CMAF header, commonly delivered as an initialization segment, carries the information required to initialize the track and decoder. If the playlist or MPD fails to reference it correctly, a media fragment can download successfully and still be undecodable.

A CMAF segment is an addressable sequence of one or more consecutive fragments from a track. A chunk is a smaller sequential subset of samples that can become available before a complete segment has been produced. The word “segment” is overloaded across CMAF, HLS, DASH, packagers, and storage systems, so production documentation should name both the standards-level object and the actual HTTP resource.

The manifests are still different

Sharing media does not merge HLS and DASH metadata. HLS expresses variants, renditions, initialization maps, encryption, partial availability, and timing through playlist tags. DASH expresses corresponding concepts through MPD elements and attributes.

The two manifests can describe the same bytes while differing in:

• rendition grouping and client selection;
• live-window and update behavior;
• low-latency availability signals;
• DRM signaling and license acquisition paths;
• captions, alternate audio, and timed metadata;
• ad insertion and discontinuity semantics;
• base URLs, templates, and request construction.

Treat the shared media as a common data plane with two independently validated control planes. A correct HLS playlist does not prove the MPD is correct, and a successful DASH player test does not prove native HLS playback.

Where CMAF reduces work—and where it does not

The strongest CMAF business case is not “50% off everything.” It is removing a duplicated class of media objects and the work attached to those objects.

Storage and packaging

If HLS and DASH currently store separate full media ladders, converging on one set can remove substantial duplicate audio and video bytes. The exact saving depends on the existing containers, codec ladders, language tracks, DRM copies, legacy outputs, thumbnails, manifests, and retention rules. Manifests are small; encoded media dominates the byte count.

Model the saving from your inventory instead of multiplying the total bill by a marketing percentage:

removable bytes = duplicated segment bytes
                - media that must remain for legacy clients
                - protocol-specific or encryption-specific copies still required

Packaging also becomes easier to reason about. One timeline and one media namespace can replace two segment production paths. You still generate and validate two manifests, but fewer large outputs need to be written, replicated, lifecycle-managed, and recovered.

CDN cache reuse

The biggest delivery gain comes when both manifests point to the exact same cacheable URLs. An HLS request for /video/720p/segment-1042.m4s can then warm the object later requested by a DASH viewer.

Byte equality alone is not enough. Different hostnames, paths, query strings, authorization tokens, range behavior, or cache-key policies can create separate entries. If the HLS packager emits /hls/... and the DASH packager emits /dash/..., the origin may store one physical file while the CDN still caches two logical objects.

Measure this directly. Segment cache-hit ratio, origin-fetch rate, shield misses, and bytes fetched from origin should improve across the combined HLS and DASH audience. A global cache-hit average can hide protocol-specific fragmentation, so retain protocol and cache-key dimensions in the logs.

Encoding and DRM

CMAF packaging does not remove the need for an adaptive bitrate ladder. Each resolution, bitrate, codec, audio language, and accessibility track still has to be encoded and aligned. The adaptive bitrate streaming guide explains why ladder design remains a separate quality decision.

CMAF can carry media protected with MPEG Common Encryption, but “encrypt once” requires an encryption scheme supported by the complete device and DRM matrix. For example, Microsoft documents that cbcs support begins with PlayReady 4.0, while older PlayReady generations have narrower mode support. CMAF does not merge FairPlay, Widevine, and PlayReady license services or make their client signaling identical.

Test encrypted output as a different product surface from clear output. Key rotation, initialization data, protection-system signaling, offline playback, ad insertion, and license renewal can expose compatibility gaps that a clear stream never touches.

How CMAF enables low-latency streaming

CMAF makes low-latency HTTP streaming practical by allowing a player to receive useful media chunks before the full parent segment is complete. It does not reduce latency merely because a file carries a CMAF brand.

In a traditional segment workflow, a packager may wait until several seconds of media are complete before publishing the object. The player then waits for manifest discovery, download, and buffer. Shortening every full segment reduces some delay but increases request and playlist overhead and can force encoding tradeoffs.

With chunked CMAF, the packager emits smaller independently processable portions as it produces the segment. The origin begins serving the growing object or addressable partial resources, and the player can append media near the live edge instead of waiting for the full segment.

The IETF's operational guidance for streaming media explains that LL-HLS and LL-DASH use CMAF units smaller than segments to decouple delivery latency from full segment duration. It also notes a wire-level difference: LL-HLS commonly requests partial resources separately, while LL-DASH can receive chunks from one still-open segment response.

Chunked media is not just the HTTP header

“Chunk” has two meanings in this area:

• A CMAF chunk is a media-level unit containing a sequential subset of samples.
• HTTP/1.1 chunked transfer encoding is a transport mechanism for sending a response whose complete length is not known at the start.

They can work together, but they are not synonyms. HTTP/2 and HTTP/3 frame response data differently and do not use the HTTP/1.1 Transfer-Encoding: chunked wire format. The operational requirement is progressive forwarding: the origin and CDN must pass media bytes as they arrive instead of buffering the whole object.

The dash.js low-latency documentation illustrates the complete dependency. The content needs multiple chunks; the MPD needs availability signals; the server must stream the incomplete response; and the player needs a low-latency buffer, throughput, and catch-up strategy. Lowering the buffer target also reduces the margin for network variation, so latency and rebuffering must be evaluated together.

How to implement CMAF without breaking playback

Treat CMAF adoption as a compatibility and delivery change, not a file-extension change. The safe path starts with an explicit playback contract and ends with measured viewer sessions.

1. Define the audience and legacy floor

Inventory browsers, mobile operating systems, connected TVs, set-top boxes, app versions, player libraries, codecs, audio layouts, captions, HDR formats, and DRM generations. Weight the matrix by real watch time and revenue rather than giving an obsolete lab device the same priority as the current audience.

Decide whether older clients can remain on MPEG-TS HLS while modern HLS and DASH share CMAF. A temporary fallback is often safer than forcing a flag-day conversion. Record the retirement threshold—such as a supported app-version floor or a measured share of sessions—so the legacy path does not become permanent by accident.

2. Align the encoded ladder before packaging

Create equivalent switching boundaries across every video rendition. Keyframes, decode times, presentation times, segment boundaries, and discontinuities must form one coherent timeline. Align audio closely enough for the protocol and player requirements, and preserve language, role, channel, and accessibility metadata.

Inspect peak bitrate as well as target bitrate. A playlist can declare an average-looking number while one difficult scene produces segments that overflow a player's buffer. The same shared media means the same defect reaches both protocol audiences, so convergence increases the value of pre-publication quality control.

3. Generate two manifests over one namespace

Confirm that the HLS and DASH outputs reference the same initialization and media resources wherever sharing is intended. Normalize base URLs, path templates, sequence numbering, and MIME types. Make versioned VOD media immutable, and avoid overwriting an object at a stable URL with different bytes.

For live streams, publish media before a manifest announces it. A few hundred milliseconds of ordering error can create a burst of 404 responses at the live edge. Validate the moving window repeatedly rather than checking one saved manifest after the event.

4. Make the CDN preserve the media model

Configure cache keys deliberately. Preserve only query parameters that change authorization or representation; avoid letting protocol-specific noise split otherwise shared objects. Verify byte-range behavior if manifests use ranges, and confirm that CORS and content types are correct for browser players.

For low latency, test whether every hop forwards partial data without full-response buffering. Observe time to first byte and the cadence of bytes during the response, not only total request duration. Make manifest freshness, segment caching, and initialization-segment caching separate policies.

ZeroBuffer supports HLS with CMAF segments and MPEG-DASH on a CDN with origin shielding, instant purge, and 100+ edge locations. Its multi-rendition encoding is included at no extra charge, which makes the shared-media design useful beyond storage: one encoding and delivery workflow can be tested without adding a separate transcoding bill.

5. Design content protection against the device matrix

Choose encryption schemes, key IDs, initialization data, and manifest signaling together. Confirm license URLs and authorization on every platform. If one DRM generation requires a separate encrypted copy, keep that exception explicit instead of pretending the whole catalog is converged.

Test startup, seeking, quality changes, key rotation, renewal during long playback, offline cases if supported, and transitions into and out of ads. Capture license and media request traces from failures; a generic player error rarely identifies whether the first problem was the manifest, key, decoder, or segment.

6. Validate files, manifests, delivery, and playback

Use four layers of validation:

1. Container: inspect brands, boxes, tracks, timestamps, random-access points, and initialization references.
2. Protocol: validate the HLS playlists and DASH MPD independently, including live updates.
3. HTTP/CDN: check status, MIME types, CORS, cache behavior, ranges, authorization, and progressive delivery.
4. Player: test real native and JavaScript players across the supported device matrix under shaped networks.

Apple recommends mediastreamvalidator and hlsreport in its HLS authoring guidance, while DASH-IF publishes reference tools and player material for DASH testing. Validators catch structural defects; they do not replace visual inspection, network impairment, long-session playback, or operational telemetry.

Track time to first frame, rebuffer ratio, fatal errors, selected rendition, quality switches, live-edge distance, segment throughput, DRM failures, cache status, and origin-fetch rate. Break results down by protocol, device, geography, network, player version, and content profile.

Common CMAF failures and the first place to look

One shared media set reduces duplicate infrastructure, but it also increases the blast radius of a bad segment. Debug from the first divergent timestamp or request.

Keep the smallest reproducible artifact: both manifests, the initialization segment, media around the failure, HTTP headers, player logs, and expected timeline. “The .m4s file is valid” is not enough if its initialization data, manifest reference, or client capability is wrong.

When CMAF is the wrong fit

CMAF is a strong default when one service must reach both HLS and DASH clients, especially when shared storage, cache reuse, multi-DRM, or low-latency HTTP delivery matters. It is not mandatory for every video product.

Keep a simpler or additional path when:

• the audience is HLS-only and legacy MPEG-TS clients still matter;
• the product uses progressive downloads rather than adaptive streaming;
• the required codec, DRM, captions, ads, or device profile does not share a reliable intersection;
• real-time two-way interaction needs subsecond behavior better served by WebRTC or another interactive protocol;
• the packager, CDN, or player cannot progressively forward and consume low-latency chunks;
• operational savings do not justify a migration of stable, already amortized assets.

Do not choose CMAF solely because it is newer. Choose it when the measured reduction in duplicated media and origin work exceeds the compatibility and migration cost.

A safe CMAF migration plan

Start with a representative corpus, not the entire catalog. Include long and short VOD, high motion, animation, multiple frame rates, every important audio layout, captions, HDR if supported, encryption, ads, and a live channel that crosses discontinuities or key changes.

Run the migration in five gates:

1. Package and inspect: produce CMAF output and prove container, timeline, and manifest conformance.
2. Test players: run HLS and DASH across the weighted device matrix, including protected content.
3. Test delivery: compare cache reuse, origin fetches, startup, stalls, and live latency under cold and warm caches.
4. Canary traffic: route a small, sticky cohort to CMAF while retaining the current output as a control and rollback path.
5. Expand and retire: increase traffic only when viewer and infrastructure metrics hold, then remove duplicate outputs after the longest relevant playback and cache windows clear.

Keep content identifiers and analytics dimensions stable enough to compare old and new paths. A migration that changes the player, codec, ladder, DRM, CDN, and packaging simultaneously may succeed, but it will be hard to explain—and harder to roll back safely.

Frequently asked questions

What does CMAF stand for?

CMAF stands for Common Media Application Format. It is the ISO/IEC 23000-19 family of constraints for segmented media used in adaptive streaming presentations.

Is CMAF the same as HLS?

No. HLS is a playlist and delivery protocol, while CMAF is a media packaging format. HLS playlists can reference CMAF fragmented MP4 media, and a DASH MPD can reference the same media objects.

What is the difference between CMAF and fMP4?

Fragmented MP4 is the broader container structure built around initialization information and movie fragments. CMAF is a constrained, profiled use of that structure designed for interoperable segmented delivery, switching, and presentation. An arbitrary fMP4 file is not automatically CMAF-compliant.

Can HLS and DASH use the exact same CMAF segments?

Yes, when the codecs, timeline, track layout, encryption, addressing, packager, and clients are compatible. The HLS and DASH manifests remain separate, but they can resolve to the same initialization and media URLs.

Does CMAF reduce video storage by 50%?

Not universally. It can remove one duplicated media set when a service previously stored separate HLS and DASH packages, but legacy outputs, extra codecs, DRM modes, audio tracks, and other derivatives may remain. Calculate savings from removable segment bytes in the actual catalog.

Does CMAF automatically make a stream low latency?

No. CMAF provides media chunks that can be consumed before a full segment is complete. Low latency also requires appropriate HLS or DASH signaling, progressive origin and CDN delivery, compatible players, and a smaller buffer target.

Does CMAF support DRM?

Yes. CMAF can carry media protected with MPEG Common Encryption. A shared encrypted media set still depends on an encryption mode, manifest signaling, license workflow, and client versions that all supported DRM systems can handle.

What file extension does CMAF use?

There is no single extension that proves CMAF compliance. Media segments commonly use .m4s, while initialization data may use .mp4 or another convention. The brands, box structure, timing, media profile, and manifest references matter more than the filename.

Make CMAF a measured infrastructure change

CMAF is most valuable when HLS and DASH genuinely share the same media objects. That can reduce duplicate storage and packaging, improve cache reuse, and provide the media substrate for low-latency delivery without erasing protocol-specific manifests or compatibility work.

Start with the audience matrix, align one ladder, preserve one media namespace, and validate the two control planes separately. Then compare viewer playback, cache reuse, origin load, and operating cost against the current path.

If delivery is the bottleneck, run the same CMAF output through ZeroBuffer and judge it with those production metrics. It serves HLS with CMAF segments and MPEG-DASH from one media namespace across 100+ edge locations, with origin shielding, instant purge, HTTP3 over QUIC, and multi-rendition encoding included at no extra charge—so the shared-media design can be tested without adding a separate transcoding bill. Delivery is a flat $0.0049/GB priced by volume rather than geography, with no contracts or minimums. See the full rate card.