The natural mapping. Each MoQ group starts at a random-access point (IDR for video). Inside a group, objects are delivered in order, and that ordering is what makes the delta stream possible. Audio groups are aligned to video groups so a tune-in operation can deliver both clocks at once.

Measured against assets/test10s/video_400kbps_avc.mp4 — a 250-fragment AVC group with one sample per fragment.

Per-track wire bitrate

The CMSF catalog reports the wire bitrate including framing. The moof saving per object is essentially constant (~100 B → 2 B ≈ 99.6 B/object), so the percentage saving grows as the track's bitrate shrinks — audio gains the most.

The 128 kbps AAC track lands within ~3% of the raw sample bitrate — the remaining LOCMAF overhead is ~2 B/object × ~47 obj/s ≈ 0.75 kbps plus the MoQ object framing. Full per-track table (Opus, AC-3, HEVC, 600 / 900 kbps video) is in docs/LOCMAF.md.

LOCMAF's primary use case is low-latency DRM-protected streaming over MoQ. The encrypted mdat bytes, per-sample IVs, subsample byte ranges, and the tenc defaults (including default_KID) are carried verbatim — so the standard CDM / MSE / EME path on the receiver works as if the content had arrived as plain CMAF. LOCMAF is invisible to the player.

Catalog DRM signalling

CMSF carries the DRM description at the catalog level; LOCMAF doesn't replace it. A contentProtections array is referenced by per-track contentProtectionRefIDs, mirroring DASH-IF IOP 6.

{
  "contentProtections": [{
    "refID": "widevine",
    "defaultKID": ["abcdef0123456789abcdef0123456789"],
    "scheme": "cbcs",
    "drmSystem": {
      "systemID": "edef8ba9-79d6-4ace-a3c8-27dcd51d21ed",
      "laURL": { "url": "https://lic.example.com/widevine", "type": "POST" },
      "pssh": "base64-pssh-box"
    }
  }],
  "tracks": [{
    "name": "video_400kbps_avc_drm",
    "packaging": "locmaf",
    "locmafVersion": "0.1",
    "contentProtectionRefIDs": ["widevine", "playready", "fairplay"],
    "initData": "..."
  }]
}

The receiver picks the first refID whose drmSystem.systemID matches a CDM it can talk to, then uses the named pssh / laURL to set up the MediaKeySession exactly as for a plain CMSF stream.

cenc vs cbcs on the wire

Audio uses full-sample encryption under both schemes, so audio under cbcs costs the same on the LOCMAF wire as clear audio — the constant IV lives once in the moov and no per-fragment encryption signalling is needed. Video carries the subsample map under both schemes.

Bitrate impact under DRM

LOCMAF saves more relative to CMAF on DRM-protected content than on clear content — the CMAF moof grows under encryption (extra senc / saio / saiz) while LOCMAF only emits what it actually needs. Full per-track tables (Opus, AC-3, HEVC, 600 / 900 kbps) are in docs/LOCMAF.md.

CMAF (ISO/IEC 23000-19) tightens ISOBMFF: each CMAF Track carries exactly one media track, each CMAF Chunk is one moof followed by exactly one mdat (§7.3.3.2), and each traf contains exactly one trun (Table 4). These restrictions are what make LOCMAF's "one MoQ object = one moof + one mdat" mapping unambiguous — a varint header_id, a properties block, and the rest of the object is mdat payload.

General fragmented MP4 may contain multiple traf / trun boxes per moof, multiple mdat boxes per fragment, or multiple tracks multiplexed into one file. LOCMAF does not address those layouts directly. Source content must be CMAF-conformant (or trivially repackaged into CMAF) before LOCMAF encoding.