Why architecture matters here
The reason to care is cost and reach multiplied together. A streaming service must reach iPhones and Apple TVs (HLS-only, historically) and Android, smart TVs, browsers, and set-top boxes (DASH or HLS). Before CMAF, satisfying both meant maintaining two packaging pipelines producing two segment formats from the same encodes. That is not just double the storage — it is double the origin footprint, and critically it fragments the CDN cache: the HLS copy of a segment and the DASH copy are different files with different URLs, so a popular title is cached twice and every cache miss hits origin for a format that may be identical byte-for-byte to one already cached. At the scale of a large catalog with a multi-rendition bitrate ladder, this waste is enormous.
CMAF matters because it collapses the duplication at exactly the layer where it hurts most. One media set, shared caching: identical fMP4 segments referenced by both manifests means one cache entry serves both player populations, roughly doubling effective cache capacity and hit rate and cutting origin egress. One encryption: common encryption with the 'cbcs' scheme lets the same encrypted files be unlocked by different DRM systems, so you protect content once instead of maintaining separate encrypted copies per DRM. One low-latency mechanism: chunked CMAF gives HLS (via LL-HLS) and DASH (via LL-DASH) a common sub-segment delivery primitive, so a single origin behavior supports low latency across protocols.
The constraint is that CMAF is a convergence standard, and convergence is never perfectly clean. Older devices, specific codec/DRM combinations, and manifest quirks mean the promise of one media set for all players comes with a real compatibility matrix you must test. The architecture's value is high, but 'encode once' in practice means 'encode once, then verify across a matrix of players' — and knowing where the seams are is the operational core.
There is a second-order benefit that is easy to miss: CMAF simplifies the operational surface of a large streaming platform, not just its storage bill. Two packaging pipelines means two sets of bugs, two encryption workflows, two low-latency configurations, and two places where a title can be mis-packaged and fail on release night. Collapsing to one media set means one pipeline to monitor, one encryption path to audit, and one artifact whose integrity you validate. When something goes wrong at 2 a.m., the on-call engineer debugs a single packaging system rather than guessing which of two divergent copies a given player population received. For a catalog measured in tens of thousands of titles, that reduction in operational entropy is often worth as much as the CDN savings, because it directly lowers the rate of format-specific incidents that are notoriously hard to reproduce.
The architecture: every piece explained
The CMAF track is fragmented MP4. It begins with an initialization segment — the moov/movie box carrying codec configuration, track metadata, and no media — followed by a series of media fragments, each a moof (movie fragment) box plus an mdat (media data) box containing a few seconds of samples. Because every fragment is self-describing enough to be decoded after the init segment, a player can start at any fragment boundary, which is what makes adaptive switching and seek work. Fragment boundaries are aligned to IDR frames (clean random-access points) so a player can begin decoding a segment without the previous one.
The packager takes the encoder's rendition ladder — the same video at multiple bitrates and resolutions, possibly multiple codecs — and emits CMAF segments plus both a HLS .m3u8 playlist and a DASH .mpd manifest that reference those identical segment files. The manifests differ in syntax but point at the same media URLs; the player picks its native format and fetches the shared segments. Chunked CMAF subdivides each segment into smaller chunks (each a moof+mdat covering a fraction of the segment) that can be produced and sent before the full segment exists, using HTTP chunked transfer encoding to stream them as they are encoded.
Common encryption (cbcs) encrypts the media once with a content key using the AES-CBC pattern scheme that all major DRMs support; the manifests carry per-DRM signaling (PSSH boxes / key IDs) so FairPlay, Widevine, and PlayReady clients each obtain the key from their license server and decrypt the same files. The CDN cache is the beneficiary — shared segment URLs mean one cached object serves both protocols. IDR alignment across renditions is the quiet requirement that ties it together: every bitrate must place its segment boundaries at the same presentation times, or a player switching bitrates mid-stream would land on a non-aligned boundary and glitch.
Two practical constraints shape how these pieces are actually configured. First, audio and video are usually separate CMAF tracks with their own init and media segments, muxed at playback rather than pre-combined; this lets a player mix one video rendition with any of several audio languages or bitrates without duplicating video, but it means audio and video segment timelines must stay consistent or A/V sync drifts. Second, the encryption choice is not free: the 'cbcs' pattern scheme (AES-CBC with a repeating encrypt/skip pattern) is the one all three major DRMs converge on, which is why CMAF deployments standardize on it rather than the older 'cenc' full-sample counter mode — picking the wrong scheme is a common way to lose the single-encryption benefit and end up re-encrypting per DRM after all. These are the kinds of low-level decisions that determine whether the elegant one-media-set diagram survives contact with a real device fleet.
End-to-end flow
Follow a title from encode to playback. The encoder produces the bitrate ladder with aligned IDR frames — the GOP structure is configured so every rendition has a keyframe at the same cadence (say every 2 or 4 seconds), guaranteeing that segment boundaries line up across the ladder. The CMAF packager slices each rendition at those boundaries into fMP4 segments, writes an init segment per track, applies common encryption with the content key, and generates both the HLS playlist and the DASH manifest referencing the shared segment files. All of this lands on origin as one media set plus two small manifests.
At playback an Apple client fetches the .m3u8, reads the init segment, and begins requesting media fragments; an Android or browser client fetches the .mpd and requests the same fragment files. The CDN, seeing identical URLs, serves both from one cache entry — the second protocol's requests are cache hits paid for by the first. As network conditions change, each player switches renditions at segment boundaries; because IDR frames are aligned, the switch lands on a clean random-access point and the viewer sees no glitch. Each client's DRM module fetches the content key from its own license server and decrypts the shared encrypted samples.
For low latency, the origin runs in chunked mode: as the encoder emits each sub-segment chunk, the packager writes it and the CDN forwards it via chunked transfer encoding before the full segment is complete. A LL-HLS or LL-DASH player requests the in-progress segment and receives chunks as they arrive, cutting glass-to-glass latency from the traditional many-seconds (waiting for whole segments) down to a few seconds or less. The same chunked media serves both low-latency protocols, so the origin does not maintain separate low-latency pipelines per format — the CMAF convergence extends all the way into the latency-sensitive path.
Trace the encryption path through the same flow to see why common encryption is load-bearing. When the packager applies 'cbcs' encryption, it encrypts the media samples once with a content key and records, in each manifest, the key identifier plus the DRM-specific initialization data (PSSH boxes for Widevine and PlayReady, and the equivalent signaling for FairPlay). At playback the Apple client extracts the FairPlay signaling from the HLS playlist and requests a license from Apple's key server; an Android client extracts the Widevine signaling from the DASH manifest and requests a license from Widevine's server. Both receive the same content key by different routes and decrypt the byte-identical encrypted segments. Nothing about the media on disk differs between the two — only the small per-DRM signaling in the manifests and the license exchange differ. This is the detail that makes 'encrypt once, unlock with any DRM' real, and it is why getting the encryption scheme and key signaling right is as important to the shared-cache benefit as the segment format itself.