MOQ Wiki

LOCMAF - Low Overhead CMAF for Media over QUIC

Updated

draft-einarsson-moq-locmaf-01 | Individual → WG adoption intended (announced interim-2026-moq-23, Sep-8; liaison to MPEG WG3 sent 2026-09-28, reply requested by 2026-10-30) | published 2026-07-05 (41 pp) | Datatracker draft-einarsson-moq-locmaf-00 | Submitted 2 June 2026

2026-09-08 — the WG intends to adopt LOCMAF, but gates the formal adoption call on MPEG. At interim-2026-moq-23 the chairs and authors agreed to adopt LOCMAF as a WG document; Magnus Westerlund (as chair) then announced on-list (permalink) that the WG will first send a Liaison Statement to MPEG Systems (ISO/IEC JTC1/SC29/WG3) — informing them of the intent to define a compression technology for their CMAF media format and confirming no significant objection — and hold the formal adoption call until MPEG replies. Victor Vasiliev had asked in the meeting whether a formal adoption call had been run; it has not. The chairs reaffirmed keeping LOCMAF separate from CMSF (independent draft + normative reference), not folded in. Objections invited “now, rather than later.” The interim-23 minutes (posted Sep-9) confirm this and record the rationale: Vasiliev’s skepticism was specifically about “adopting a third normative container format,” which Westerlund answered by framing LOCMAF as an optimization for CMSF requirements — “not a new format but … behaving similarly to a transfer-encoding”; Will Law noted CMAF has no normative dependency on LOCMAF yet (an open PR would introduce one), and Tobbe cited the concrete win — putting every audio frame in a MoQ object adds >100 bytes of repetitive overhead, which LOCMAF’s delta-encoding cuts to ~2 bytes. (The AI minutes repeatedly mislabel LOCMAF as draft-ietf-moq-loc; the draft is draft-einarsson-moq-locmaf.) The liaison went out on 2026-09-28 as liaison statement 2285 — see Status below — so the adoption call cannot open before 2026-10-30.

Authors

  • Torbjörn Einarsson (Eyevinn Technology) — wiki maintainer; author of moqlivemock + mlmtest interop client
  • Hugo Björs (KTH) — first IETF MoQ-side artifact

Abstract

LOCMAF defines a compact wire format that enables streaming low-latency CMAF media over MoQ Transport with significantly reduced per-object overhead. The format carries CMAF chunk metadata as tagged fields while preserving sample data unchanged, with the receiver reconstructing functionally equivalent CMAF chunks suitable for MSE/EME playback pipelines.

Position in the design space

FormatWire shapeMSE/EME compatibilityStandardization
CMSFFull CMAF chunks (init + chunks per CMAF spec)Direct passthrough to MSEWG (draft-ietf-moq-cmsf-00)
LOCMAFTagged fields + unchanged sample data; receiver reconstructs CMAF chunk (canonical, byte-identical)Reconstructed; MSE-compatible after receiver-side rebuildIndividual (draft-einarsson-moq-locmaf-01)
LOCCodec-aware compact frame formatNo (requires non-MSE pipeline)WG (draft-ietf-moq-loc-03)
compressed-mp4Varint-compressed fMP4 boxes (96 → ~21 bytes per fragment)After decompression: MSE-compatibleIndividual
moq-media-interopLOC wire format for H.264/Opus/AACNoIndividual, expired Apr 23

LOCMAF’s distinguishing choice: carry CMAF chunk metadata as tagged fields, preserve sample data unchanged, reconstruct the CMAF chunk receiver-side. This makes it transparent to MSE/EME consumers (the player still sees standard CMAF chunks) while removing redundant box headers from the wire. Two further properties frame it as a candidate CMSF packaging mode: it is end-to-end (relays forward the Object payload unchanged) and uses catalog-referenced init (relying on MSF -01’s initData type so cmaf and locmaf tracks can reference the same init).

Why this matters

  • Eyevinn’s MoQ adoption path: Eyevinn’s existing CMAF-based pipeline (HLS/DASH origins + low-latency CMAF chunked encoding) needs a MoQ wire shape that doesn’t force re-architecting the player-side MSE/EME glue. LOCMAF preserves that.
  • MSE/EME compatibility constraint: Safari (notably for FairPlay DRM) requires avc1/hvc1 sample entries with parameter sets in the decoder configuration record, not avc3/hev1 with inline parameter sets (see Tobbe’s moq-wg/msf Issue #153 Point 4). LOC’s self-initializing segments break this. LOCMAF can carry the parameter sets out-of-band as tagged fields and reconstruct an MSE-compatible CMAF chunk.
  • Streaming Tech Sweden + IETF prior work: presented as a low-overhead extension to CMAF in pre-IETF venues; the -00 submission formalizes the proposal.

Status

  • -01 published: 2026-07-05 (41 pp) — a major consistency rewrite; -00 submitted 2026-06-02
  • MPEG liaison sent — adoption call waits on it until at least 2026-10-30: liaison statement 2285, “IETF MOQ WG intention to adopt work on a low-overhead packaging (LOCMAF) for CMAF media carried over Media Over QUIC Transport”. It is from MOQ (Westerlund) to ISO/IEC JTC1/SC29/WG3, purpose For action, deadline 2026-10-30. Response contacts are the chairs; technical contact is Torbjörn Einarsson. Westerlund submitted it on Sep-17; AD Mike Bishop approved and posted it on Sep-28 (list copy). The body gives the WG’s framing: LOCMAF targets the case where “CMAF chunk headers (~100 bytes and up) can be as large as or larger than the coded frame itself”; “Critically, LOCMAF does not alter or redefine CMAF”; reconstruction is decode-equivalent including CENC per-sample metadata, with a canonical byte-identical form for conformance; LOCMAF normatively references CMAF, ISOBMFF and CENC and is itself referenced from CMSF’s locmaf packaging value. The WG “plan[s] to await your response before proceeding to a formal WG adoption call.”
  • Relationship to CMSF: CMSF registers LOCMAF as a locmaf packaging by normative reference (moq-wg/cmsf PR #27), so LOCMAF keeps its independent standalone-draft path rather than being folded into CMSF
  • Implementation reports — three independent families, all at format version 0.3:
    • Eyevinn (reference): LOCMAF v0.3 in moqlivemock v0.12.0, with the codec extracted into the standalone Eyevinn/locmaf module and warp-player on the MSE/EME playback side.
    • Shaka Player (Google project, written by Ateme’s avelad) — merged to main 2026-09-17 (PR #10538, +3,027/−1). MSE path including EME: the reconstructed chunk carries senc/saiz/saio, so the demo plays a multi-DRM LOCMAF variant against moqlivemock. Unreleased (queued for v5.3.0).
    • moq-playa (Red5 Pro / OpenMOQ, Paul Gregoire) — PR #15 merged to main 2026-09-19 (+9,801/−67, 242 files; opened Sep-14). The most complete reading of the draft so far: a new @moqt/locmaf package with both decoder and encoder, an MSE path and an optional WebCodecs frame path, §14 event-only tracks (emsg v0/v1) and the §16 frame interface — neither of which the other implementations touch — plus §18 bounds hardening. CENC/EME playback was the stated gap. moq-playa then merged generic EME/Widevine support in its MSE adapter on Sep-28 (PR #18). Nobody has reported protected LOCMAF playing through it yet.

Recent Highlights

Day-by-day activity lives in the wiki log; this section keeps only durable milestones.

  • Third implementation merged — moq-playa (Red5 Pro), and the conformance vectors are doing their job (PR opened 2026-09-14, merged 2026-09-19; LOC-04 support followed Sep-20): Paul Gregoire’s PR #15 “play LOCMAF tracks (draft-einarsson-moq-locmaf-01)” (merged at +9,801/−67 across 242 files) adds a standalone @moqt/locmaf package — vi64/zigzag codec, deserializer and encoder, CMAF Header track context, delta application and effective values (§11/§12/§15.1), canonical chunk reconstruction (§15.2–15.8 incl. saiz/saio/senc), §18 bounds hardening — behind a player that can take a LOCMAF track down either the MSE path or a WebCodecs frame path (locmafDecoding: 'mse' | 'frame'). It is the first implementation to exercise §16 (frame interface) and §14 (event-only tracks, emsg v0/v1). Two things make it notable beyond being a third implementation: it validates against Eyevinn/locmaf’s golden vectors, vendored and pinned by SHA-256 (@177e798, MIT; the vector manifests carry locmafVersion 0.3 and draftCommit 6a2439a) with all 38 objects reconstructing and re-encoding byte-exact — a cross-implementation conformance artifact actually being consumed by an outside party — and Red5’s relay validated the format in the relay itself (red5-moq-relay e2e in TRANSPARENT and FULL mode, the latter reconstructing and checking every object, zero rejections). CENC/EME playback is the declared gap on both paths. Gregoire asked the draft author for review on the PR (Sep-17); Tobbe agreed and flagged moqlivemock v0.15.0’s move to proper namespace arrays (away from slash-joined strings) for anyone using that server as the reference publisher.
  • Second independent implementation — Shaka Player (2026-09-17): Google’s production browser player merged a locmaf packaging to main (PR #10538, +3,027/−1) — a 1,345-line parser plus a packaging shim, implementing locmafVersion 0.3 exactly (a track declaring any other version is skipped rather than guessed at) and requiring catalog-referenced init via MSF-01 initRef. Its demo plays both a clear and a multi-DRM LOCMAF variant against moqlivemock. This is the first implementation outside Eyevinn, and the first to reach LOCMAF through an independent, production MSE/EME pipeline — the compatibility argument the draft is built on. Shaka also hit the practical wrinkle the format creates: a catalog offering one rendition as both cmaf and locmaf doubles the variant list, with nothing in the catalog marking either as preferred (Shaka leaves the choice to an application-supplied catalog preprocessor). Ships in Shaka’s experimental build; queued for v5.3.0.
  • WG adoption intended (interim-2026-moq-23, 2026-09-08); liaison sent 2026-09-28: the chairs and authors agreed to adopt LOCMAF as a WG document. Per Magnus Westerlund’s on-list announcement, the WG will first send a Liaison Statement to MPEG Systems (ISO/IEC JTC1/SC29/WG3) about defining a compression technology for CMAF, then run the formal adoption call once MPEG responds. The statement (liaison 2285) went out Sep-28 with a 2026-10-30 reply deadline and Tobbe as technical contact — and will keep LOCMAF a standalone draft (normative reference from CMSF), not fold it in. See interim-meetings, discussions-2026-09.
  • draft-einarsson-moq-locmaf-01 cut 2026-07-05 (41 pp, a major consistency rewrite) — the individual draft “Low Overhead CMAF for Media over QUIC” by Torbjörn Einarsson (Eyevinn) and Hugo Björs (KTH), the first IETF artifact from the wiki maintainer.
  • First implementation: LOCMAF v0.3 shipped in moqlivemock v0.12.0 with the codec extracted into the standalone Eyevinn/locmaf module, paired with warp-player for MSE/EME playback; the redesign drops initData compression in favor of catalog-referenced init via MSF -01’s initData type.
  • Adopted into CMSF by reference (not folded in): CMSF PR #27 registers a locmaf packaging that points at the standalone LOCMAF draft (the approach Will Law suggested on CMSF Issue #24), so LOCMAF stays sovereign over the format while CMSF gains the mode — reversing the earlier “fold in and retire the standalone” plan.

Related drafts and concepts

  • moq-loc — Low Overhead Media Container (WG, draft-02) — the LOC-family WG draft from which LOCMAF differentiates
  • moq-cmsf — CMAF-compliant MSF (WG, draft-00) — the CMAF-equivalent reference point
  • compressed-mp4 — Varint compression of fMP4 boxes (Mo Zanaty individual)
  • moq-media-interop — LOC media wire format for H.264/Opus/AAC
  • moq-transport — base wire protocol
  • moq-msf — MSF packaging umbrella draft

Authors and stakeholders

  • Torbjörn Einarsson — Eyevinn Technology, wiki maintainer
  • Hugo Björs — KTH (Royal Institute of Technology), Stockholm

References

Graph View

DraftsConceptsPeopleImplDiscInteropOtherTags
DraftsConceptsPeopleImplDiscInteropOtherTags

Backlinks