Hakari

What is CMAF?

CMAF (Common Media Application Format, ISO/IEC 23000-19) is a specification that lets HLS and DASH share the exact same segment files. Before CMAF, you had to package a stream twice — once as MPEG-TS for HLS, once as fMP4 for DASH — doubling your storage and CDN bill.

With CMAF, both manifests reference the same .m4s segments. Same bytes, two manifests. Storage and caching cost halved.

The one thing CMAF is

A profile of fMP4 (fragmented MP4) with specific constraints that make the segments legal for both HLS (≥ iOS 10, macOS 10.12) and DASH.

Key constraints:

  • Each segment starts with a styp box (segment type).
  • Fragments use moof + mdat pairs (movie fragment header + media data).
  • Single-track per segment (video-only, audio-only — not muxed).
  • Specific codec profiles allowed (H.264 baseline/main/high, H.265 main/main-10, AAC-LC, AC-3, AC-4).

If you've seen init.m4s and seg_<n>.m4s files, you've seen CMAF.

Why CMAF enabled low-latency streaming

Classic segments were atomic: a 6-second segment couldn't be transmitted until the full 6 seconds had been encoded. CMAF chunks break a segment into chunks (~200–500ms each) that can be flushed over HTTP as they're encoded.

Both LLHLS and LL-DASH use CMAF chunks. The manifest still references whole segments, but the HTTP response for that segment streams in via chunked transfer encoding. The player can start decoding as soon as the first chunk arrives — ~500ms instead of 6s.

That's the entire trick behind sub-second-ish HTTP streaming.

CMAF on Hakari

Every Hakari output uses CMAF:

  • Live LLHLS — segment URIs like seg_<variant>_<seq>.m4s, init segments like init_<variant>.m4s.
  • Live HLS — optional, uses the same CMAF segments wrapped in an HLS-v7+ manifest.
  • VOD (HLS or DASH) — master manifest + CMAF segments. Same files work for both formats when both are enabled.

This means:

  • Half the S3 storage for VODs that serve both HLS + DASH (vs packaging twice).
  • Edge cache hits transfer between manifests — a viewer on HLS and a viewer on DASH asking for "720p segment 245" get the same cached bytes.
  • DRM-ready — CMAF is the standard for multi-DRM (FairPlay + Widevine + PlayReady with one set of files using cbcs encryption).

Session boundaries in a live CMAF stream

When a broadcaster disconnects and resumes, their new push may come with different encoder settings — different resolution, different codec profile, different PTS origin. A CMAF playlist handles this with #EXT-X-DISCONTINUITY + a fresh #EXT-X-MAP pointing at a new init segment:

#EXTINF:6.000,
seg_0_44.m4s
#EXTINF:6.000,
seg_0_45.m4s
#EXT-X-DISCONTINUITY
#EXT-X-MAP:URI="init_0_v1.m4s"
#EXTINF:6.000,
seg_0_46.m4s

Hakari's live-recording pipeline detects session boundaries automatically and emits the right tags so playback is seamless across pauses and resumes.

  • HLS / LLHLS — consume CMAF via M3U8 manifests.
  • DASH — consume CMAF via MPD manifests.
  • Streams / VOD — both use CMAF under the hood.