Transloadit

What is the Common Media Application Format (CMAF)?

Common Media Application Format (CMAF) is an MPEG standard, ISO/IEC 23000-19, for encoding and packaging segmented media as fragmented MP4. It specifies track structure, encryption, and media profiles so that HLS and DASH can reference the same media objects.

How the Common Media Application Format (CMAF) works

CMAF defines media objects, not a manifest or a delivery protocol; presentation is left to an abstract application model that HLS and DASH both implement. A CMAF track holds one kind of media (video, audio, or subtitles) and consists of a CMAF header, which initializes a decoder, followed by fragments. Alternative encodings of the same content that a player may switch between at fragment boundaries form a switching set. Switching sets of the same media type, for example different languages or codecs, form a selection set, and a presentation combines synchronized selection sets. For delivery, fragments are grouped into segments or divided into chunks. An HLS media playlist lists the segments of one track and points to its header with EXT-X-MAP, and a DASH MPD can address the same files.

Key facts

  1. CMAF tracks carry one media type each, so audio and video are packaged and requested separately. Apple’s HLS guidance says CMAF segments cannot, in general, contain multiple media types, that there should be one media playlist per CMAF track, and that every segment needs an EXT-X-MAP tag pointing to the track’s CMAF header. Multiplexed transport-stream segments therefore have to be repackaged, not renamed, and a player needs the matching header before it can decode any segment.
  2. A segment is one or more whole fragments; a chunk is a consecutive subset of one fragment’s samples. Fragments are independently decodable, and players switch renditions at fragment boundaries. Chunks exist to cut latency: they can be published before the fragment is complete, but DASH-IF notes they are generated for neither bitrate switching nor random access. The delivery chain and the player have to cooperate as well: DASH-IF’s low-latency guidance requires HTTP chunked transfer encoding from packager ingest to the CDN edge and sets separate requirements for low-latency clients. HLS exposes chunks as Partial Segments listed in the playlist and defines its Low-Latency Mode as the combined use of Partial Segments, Blocking Playlist Reload, and preload hinting.
  3. CMAF does not give you one encrypted copy for every device. It defines presentation profiles for unencrypted content, cbcs encryption, and cenc encryption, and Apple states that HLS supports only unencrypted and cbcs. Microsoft documents cbcs support in PlayReady from client version 4.0 onward, as an optional feature, with earlier clients limited to cenc. A cbcs copy therefore excludes pre-4.0 PlayReady devices and a cenc copy excludes Apple’s HLS players. Check the DRM client versions in your device population before planning single-copy encrypted delivery.
  4. CMAF over HLS needs players that accept fragmented MP4. Apple dates fMP4 segment support in the HLS specification to September 2016, says clients based on earlier revisions will likely not handle CMAF content, and names iOS 10, macOS 10.12, and tvOS 10 as the first Apple releases expected to. On protocol versions, the HLS draft requires compatibility version 6 or greater for EXT-X-MAP in a media playlist that is not I-frame-only, while FFmpeg’s HLS muxer documentation says fMP4 segments may be used in HLS version 7 and above and describes transport-stream segments as compatible with all HLS versions. Apple’s list covers only its own platforms, so test fMP4 playback on other devices you have to keep; HLS clients that cannot play it still need a transport-stream rendition alongside the CMAF one.

When the Common Media Application Format (CMAF) matters

Use CMAF when the same content must reach both HLS and DASH players and you want one set of segments in storage and CDN cache instead of two. It pays off only where the target players overlap: every client has to play fragmented MP4, decode the chosen codecs, and, for protected content, support the same encryption scheme. CMAF does not supply manifests, so you still publish an HLS playlist and a DASH MPD that point at the shared segments.

How Transloadit helps with the Common Media Application Format (CMAF)

Transloadit’s /video/adaptive Robot has a technique parameter with a cmaf value, documented as FFmpeg-based CMAF output with both MPEG-DASH and HLS manifests that reference the same fMP4 segments. With that technique, playlist_name names the DASH manifest and hls_playlist_name the HLS master playlist. The Robot is normally used after /video/encode, which produces the renditions.

With cmaf, the documentation says all audio goes into one adaptation set labeled with the first audio language, and inputs with more than one known audio language add an Assembly warning; for multi-language audio it recommends technique: "hls" with audio_group: true. The Robot page describes no content-encryption or low-latency chunk options.

Explore Transloadit’s file formats & compression capabilities

Sources

Turn media knowledge into a working pipeline

Connect uploads, processing, AI, storage, and delivery through one declarative API — with the encoding stack, scaling, and format churn handled for you.

Try Transloadit for free