Low Overhead CMAF for Media over QUIC (LOCMAF)

6.1. Mandatory preconditions

A LOCMAF publisher MUST ensure that:¶

1. Single trak per moov. The CMAF Header contains exactly one trak box. Multi-track ISO BMFF files MUST be demuxed before LOCMAF encoding.¶

2. No key ID (KID) change within a CMAF chunk. Key-identifier transitions MUST align with fragment (and therefore chunk) boundaries. This removes the need for sgpd / sbgp boxes in the packaging.¶

If a source violates either of these, the publisher MUST NOT use LOCMAF packaging for that track and MUST instead use plain CMAF packaging. LOCMAF and plain CMAF tracks MAY coexist in the same catalog under the same namespace (see Section 4).¶

LOCMAF places no constraint on sample_flags: the full 32-bit ISO BMFF sample_flags value ([ISOBMFF] §8.8.3.1) round-trips through the packaging (see Section 9).¶

6.2. Recommended source properties

The following are recommendations whose violation costs bytes but does not break LOCMAF:¶

1. Commensurate media timescales. Choose a timescale so every frame has an exact integer duration (e.g. 48 000 for 48 kHz AAC, 60 000 for 60000/1001 fps video).¶

2. Stable trex defaults. Keeping trex consistent across the stream maximises what can be omitted from each chunk header.¶

6.3. Optional encoder modes

A LOCMAF encoder MAY operate in strict cmf2 mode, in which it always emits the four tfhd defaults (sample duration, size, flags, sample-description index) in the full chunk header even when they match trex. This costs a handful of bytes per group but produces reconstructed CMAF chunks in which each chunk is a self-decodable single-chunk fragment per [CMAF] §7.7.3. It need not be signalled, since it does not affect compatibility between encoders and decoders. Strict cmf2 mode is an opt-in encoder tweak and is not the canonical baseline used for conformance; the canonical reconstruction defined in Section 14 emits a tfhd default only when it differs from trex.¶

7.1. Element sequence and dispatch

A LOCMAF Object payload is an ordered sequence of elements followed by the raw mdat payload:¶

[ genBox ]*       zero or more pre-moof boxes, in reconstruction order
locmafHeader      exactly one: a full or delta moof header
mdat raw payload  length = MOQT-object-len minus the elements above

The locmafHeader marks where the moof sits in the reconstructed chunk: every genBox before it renders before the moof, and the mdat immediately follows the moof. The common case — no boxes outside the moof — is simply locmafHeader followed by mdat; genBox is purely additive.¶

Each element begins with an element_type vi64. Three element types are defined:¶

The mdat payload carries no element_type tag — it is whatever bytes remain after the locmafHeader.¶

A receiver parses elements in a loop, reading element_type vi64 values:¶

1. While the element_type is 1, it parses one genBox (delimited by its box_size, see Section 8) and continues.¶

2. When the element_type is 2 or 3, it parses exactly one locmafHeader, full or delta respectively (delimited by its properties_length, see Section 10 and Section 11). The bytes following that header's property block, to the end of the MOQT object, are the mdat payload.¶

Exactly one header element MUST appear in a LOCMAF Object, and it MUST be the last element before the mdat payload. A genBox that follows the header is malformed.¶

The full-vs-delta distinction is signalled exclusively by the header element_type (2 for full, 3 for delta), never by the MOQT object position within a group:¶

1. The first object of every MOQT group MUST carry a locmafFullHeader, so a subscriber tuning in at a group boundary has a complete reference.¶

2. The encoder MAY emit a locmafFullHeader at any object position within a group, not only at object index 0. A mid-group full chunk re-anchors the in-group reference for subsequent delta chunks.¶

3. After parsing a locmafFullHeader, the receiver MUST discard its in-group delta state and treat the new full chunk as the reference for any following locmafDeltaHeader objects in the group.¶

4. The receiver MUST dispatch on the header element_type alone. It MUST NOT infer "full" from object index 0 or "delta" from object index greater than 0.¶

An element_type other than 1, 2, or 3 is not self-delimiting, so a receiver cannot skip it. A receiver that reads an unrecognised leading element_type MUST treat the Object as malformed and reject it; there is no generic skip for unknown top-level elements. This hard failure is deliberate: an element one receiver silently skipped and another understood would make the two reconstruct different chunks, defeating canonical comparison (Section 14). Extension happens through new genBox box_name FourCCs and new header field IDs (see Section 7.3) — both of which are self-delimiting — not through new element types.¶

For event-only tracks (see Section 13) the mdat payload MAY be zero bytes; the receiver reconstructs an empty mdat box (8-byte header only).¶

7.2. Header element layout

A locmafHeader element (full or delta) is, in order:¶

element_type        vi64     = 2 (full) or 3 (delta)
properties_length   vi64     byte length of the property block
property block      properties_length bytes of (field_id, value) tuples

element_type and properties_length are vi64 values. The property block is the flat sequence of (field_id, value) tuples defined in Section 7.3 and is exactly properties_length bytes long, so the header element is self-delimited. When this is the Object's header element, the bytes following the property block, to the end of the MOQT object, are the mdat payload (see Section 7.1). A delta header with properties_length == 0 carries no field changes (see Section 11).¶

7.3. Property encoding (parity rule)

The property block inside a locmafHeader is a flat sequence of (field_id, value) tuples. Field IDs are vi64 values. This is the property scheme of [LOC] §2.3: the value encoding is determined by the parity of the field ID. LOCMAF reuses that parity scheme but governs its own field IDs in this document (see Section 9); they are not [LOC] properties and are not IANA-registered.¶

• Even ID — scalar. The value is a single vi64 with no length prefix. In a full header it is an absolute unsigned vi64; in a delta header it is a zigzag vi64 (see Section 7.4) of the signed delta against the in-group reference.¶

• Odd ID — length-prefixed bytes. The tuple is field_id | byte_length | bytes. The interpretation of the bytes is per-field. vi64-list fields concatenate their elements, each an absolute unsigned vi64 in full context and a per-element zigzag vi64 (see Section 7.4) in delta context. Raw-byte fields (sencInitializationVector, ID 9) carry opaque content verbatim in both contexts.¶

Parity governs framing: it tells a receiver how far every tuple extends, whether or not it recognises the field ID. The interpretation of the value bytes is per-field (Section 9). Three fields deviate from the absolute-in-full / delta-in-delta value encoding above:¶

• trunSampleCompositionTimeOffsets (ID 5): elements are zigzag vi64 values (see Section 7.4) in both full and delta context, because composition time offsets are signed in trun version 1 — the common video case, where B-frames make the composition/ decode-time relation non-monotonic.¶

• sencInitializationVector (ID 9): opaque raw bytes, carried verbatim in both contexts (overwrite, never a delta).¶

• deltaDeletedLocmafIDs (ID 27): delta-only control list whose elements are plain unsigned vi64 field IDs, never zigzag (see Section 9.4).¶

Two fields are additionally restricted to one header kind: tfdtBaseMediaDecodeTime (ID 10) appears only in full headers — a delta chunk's BMDT is always derived (see Section 11.2) — and deltaDeletedLocmafIDs (ID 27) appears only in delta headers.¶

A receiver that encounters a field ID not defined in this document MUST skip its value using the parity rule — one vi64 for an even ID, byte_length bytes for an odd ID — and MUST otherwise ignore it. New field IDs can therefore be added backward-compatibly, as long as a reconstruction that ignores them remains correct; an extension that cannot be safely ignored requires a new packaging value instead.¶

The ID space is structurally aligned with the parity rule: every scalar/default field has an even ID and every list or byte field has an odd ID. A field ID MUST NOT appear twice in one property block; a receiver MUST reject a property block that repeats one. Field IDs MAY appear in any order and receivers MUST tolerate any ordering; encoders SHOULD emit IDs in ascending order, and the canonical encoding (Section 14.9) requires it.¶

7.4. Zigzag vi64 encoding

A zigzag vi64 is a signed integer encoded as an unsigned vi64 by interleaving non-negative and negative values so that small-magnitude values of either sign occupy small unsigned values, and thus the shortest vi64 forms.¶

For a signed 64-bit integer n, the mapping to its unsigned zigzag representation z is:¶

encode:  z = (n << 1) ^ (n >> 63)  ; arithmetic right shift
                                   ; equivalently:
                                   ;   n >= 0:  z = 2 * n
                                   ;   n <  0:  z = -2 * n - 1

decode:  n = (z >> 1) ^ -(z & 1)   ; equivalently:
                                   ;   z even:  n =  z / 2
                                   ;   z odd:   n = -(z + 1) / 2

The first few mappings: 0↔0, -1↔1, 1↔2, -2↔3, 2↔4, -3↔5, 3↔6, ….¶

The encoded z is then serialised as an unsigned vi64; decoders read the vi64 and apply the decode rule above.¶

This zigzag mapping is widely used in compact binary serialisation formats; the description is included here for self-containment.¶

LOCMAF uses zigzag vi64 values wherever a signed value is written: for deltas against the in-group reference, and for the signed list trunSampleCompositionTimeOffsets (ID 5) in both contexts (see Section 7.3).¶

8.1. Byte layout

A genBox element is, in order:¶

element_type   vi64      = 1 (genBox)
box_size       vi64      length in bytes of `box_name` + `payload`
box_name       4 bytes   the ISO box type FourCC ('styp','emsg','prft','uuid', ...)
payload        box_size − 4 bytes   the box contents WITHOUT the 8-byte ISO box header

element_type and box_size are vi64 values. box_size covers the box_name and the payload — the entire remainder of the element — mirroring ISOBMFF, where a box's size covers its type and contents (the ISO size additionally counts its own 4 bytes). The element on the wire is therefore 1 | box_size | box_name(4) | payload(box_size − 4) and is fully self-delimited by box_size; a box_size less than 4 is malformed. Every element thus shares the same type | length | body shape, so the length field alone delimits any element.¶

The payload is the box contents that would follow the 8-byte ISO box header (size + type). For a uuid box, the 16-byte usertype is part of the box contents: the encoder MUST place the usertype as the first 16 bytes of payload, followed by the remaining box data.¶

8.2. Full bytes, no delta

genBoxes always carry full bytes; there is no cross-chunk genBox delta and no genBox deletion marker. Presence in the Object payload means the box is rendered in this chunk, in the position implied by element order; absence means the box is not rendered in this chunk. A delta locmafHeader MAY still be combined with full genBoxes in the same Object — for example a per-chunk prft genBox in front of a delta moof header.¶

8.3. Reconstruction

To reconstruct the ISO box from a genBox, the receiver wraps payload in a standard ISO box header:¶

1. Let L = 4 + box_size. L MUST fit in 32 bits: a box_size above 0xFFFFFFFB is malformed and the receiver MUST reject the Object.¶

2. Emit the box header uint32be(L) | box_name(4), then payload. The total box is L bytes.¶

3. For a uuid box (box_name == 'uuid'), the 16-byte usertype is the first 16 bytes of payload (see above) and is therefore emitted immediately after the box header as part of payload. The receiver performs no reordering; reconstruction is the standard byte-for-byte wrap.¶

The ISO size escape values 0 (box extends to end of file) and 1 (64-bit largesize follows, [ISOBMFF]) are never produced: a reconstructed genBox always carries its actual size in the 32-bit size field. An encoder MUST NOT emit a genBox that would require either escape.¶

8.4. Ordering

Every genBox in the Object payload renders, in payload order, before the moof; the mdat immediately follows the moof. The reconstructed chunk is genBox* (in payload order), then moof, then mdat.¶

8.5. Box carriage

The payload of every genBox is simply the box contents as defined by [ISOBMFF] (or the specification owning the box type), carried verbatim — LOCMAF re-encodes no fields.¶

The set of box types carried as genBoxes is open: any box outside the moof is carried under its ISO box_name FourCC, which is self-describing and needs no LOCMAF identifier allocation.¶

9.1. Sample flags carry the full 32-bit value

trunSampleFlags (ID 7), tfhdDefaultSampleFlags (ID 8), and trunFirstSampleFlags (ID 12) each carry the complete 32-bit ISO sample_flags value ([ISOBMFF] §8.8.3.1): the full value in a full header, and a difference in a delta header, both as vi64 (the difference signed, see Section 7.4).¶

9.2. Indexing and list lengths

The per-sample list fields (IDs 1, 3, 5, 7, 11) carry the sample[i].* values from their source box. The per-subsample list fields (IDs 13, 15) carry the senc.sample[i].subsample[j].* values flattened in chunk order, with a total length equal to the sum of sencSubsampleCount[i] over all samples. sencInitializationVector (ID 9) is the concatenation of per-sample IVs, each per_sample_IV_size bytes long (see Section 12).¶

trunSampleCount (ID 14) — always present in a full header, and carried in a delta header only when it changes — anchors every list length: the per-sample lists have trunSampleCount elements, with the single exception of trunSampleSizes (ID 1), which carries trunSampleCount − 1 entries because the last sample size is derived from the mdat-payload length (see Section 10.2). The receiver therefore knows the length of every list field before parsing its bytes.¶

9.3. CENC fields stay inside the header

sencInitializationVector (9), sencSubsampleCount (11), sencBytesOfClearData (13), sencBytesOfProtectedData (15), and sencPerSampleIVSize (16) are drawn from the senc box inside moof.traf. They are therefore locmafHeader fields, not genBox. Only boxes outside moof are carried as generic boxes (see Section 8). The saio and saiz boxes are not carried at all; the receiver recomputes them during canonical reconstruction (see Section 12 and Section 14).¶

9.4. Delta deletion marker

deltaDeletedLocmafIDs (ID 27) is a control field used only in a delta header. It carries the list of field IDs that were present in the previous chunk of the same group but are absent in the current one. Its elements are plain unsigned vi64 values — not zigzag, and not deltas against any prior deletion list. The list length is determined by the field's byte-length prefix: the receiver reads unsigned vi64 values until the prefix is exhausted. This field MUST NOT appear in a full header. Its application is specified in Section 11.¶

10.1. Emission rules

The encoder first derives each sample's effective duration, flags, and composition-time offset from the source moof — the per-sample trun value when present, else the tfhd default when present, else the trex default (offsets default to 0) — and emits fields from those effective values. The encoding is therefore independent of how the source moof happened to distribute values between per-sample entries and defaults: two decode-equivalent source moofs yield the same emitted fields.¶

trunSampleCount (14)

always.¶

tfdtBaseMediaDecodeTime (10)

always.¶

tfhdSampleDescriptionIndex (2)

emit iff the effective sample-description index ≠ trex.default_sample_description_index.¶

trunSampleDurations (3)

emit iff the effective sample durations are not all equal.¶

tfhdDefaultSampleDuration (4)

emit iff the effective sample durations are all equal AND that value ≠ trex.default_sample_duration.¶

trunSampleSizes (1)

emit iff sample sizes are not all equal AND sample_count > 1; the list carries sample_count − 1 values (the first n − 1 in chunk order).¶

tfhdDefaultSampleSize (6)

emit iff all samples in the chunk share one size AND that size ≠ trex.default_sample_size AND sample_count > 1 (see Section 10.2).¶

trunSampleFlags (7)

emit iff the effective sample flags are neither all equal, nor equal on all samples but the first.¶

trunFirstSampleFlags (12)

emit iff sample_count > 1 AND the first sample's effective flags differ from the (equal) effective flags of all other samples.¶

tfhdDefaultSampleFlags (8)

emit iff the effective flags shared by the samples it covers (all samples, or all but the first when trunFirstSampleFlags is emitted) ≠ trex.default_sample_flags; never emitted together with trunSampleFlags.¶

trunSampleCompositionTimeOffsets (5)

emit iff any effective composition-time offset ≠ 0.¶

sencPerSampleIVSize (16)

emit iff senc is present AND per_sample_IV_size ≠ tenc.default_Per_Sample_IV_Size.¶

sencInitializationVector (9)

emit iff senc is present AND per_sample_IV_size > 0.¶

sencSubsampleCount (11), sencBytesOfClearData (13), sencBytesOfProtectedData (15)

emit iff senc is present AND the samples carry subsample maps.¶

These rules produce the minimal encoding and are part of the canonical encoding (Section 14.9). An encoder MAY additionally emit a field whose value matches the applicable default — strict cmf2 mode (Section 6) does exactly that for the four tfhd defaults — without affecting the decoded effective values or the canonical reconstruction (Section 14).¶

10.2. Sample-size derivation

Let n = trunSampleCount and let P be the chunk's mdat-payload length (the MOQT object length minus the bytes consumed by all elements). The receiver MUST derive sample sizes as follows:¶

• If trunSampleSizes (ID 1) is present, it carries exactly n − 1 values. sample_size[i] = listed[i] for i in [0, n−1), and sample_size[n−1] = P − sum(listed). The receiver MUST NOT consult tfhdDefaultSampleSize, trex.default_sample_size, or any other source for sample sizes in this chunk.¶

• Else if tfhdDefaultSampleSize (ID 6) is present, all n samples have that size.¶

• Else if trex.default_sample_size is non-zero, all n samples have that size.¶

• Else, when n == 1, the lone sample's size is P. When n > 1 and no size information is available, the chunk is malformed and the receiver MUST reject it.¶

Correspondingly, when sample_count == 1 both trunSampleSizes and tfhdDefaultSampleSize MUST be omitted — the single sample's size is always P. When sample_count > 1 with uniform sizes the encoder MUST emit tfhdDefaultSampleSize (subject to the trex.default_sample_size equality rule) and MUST NOT emit trunSampleSizes; when sizes vary the encoder MUST emit trunSampleSizes with exactly n − 1 entries and MUST NOT emit tfhdDefaultSampleSize. The receiver MUST reject a chunk in which sum(listed) > P, a chunk whose default-derived sizes do not satisfy n × size = P, and a chunk with n == 0 whose mdat payload is not empty. Omitting the last sample size shaves one vi64 per chunk; using the default for uniform-size tracks (common for fixed-bitrate audio, e.g. AC-3) collapses n − 1 vi64 values into one.¶

11.1. Field value encoding

Each emitted field's value is interpreted relative to its kind:¶

The "previous value" for each field is the effective value used in the reconstruction of the previous LOCMAF chunk in the same group (or, after a mid-group full header, the previous chunk starting from that re-anchor).¶

11.2. tfdt BMDT derivation

The receiver derives a delta chunk's BMDT as previous_bmdt plus the sum of the previous chunk's effective sample durations (the per-sample values when present, else sample_count times the applicable default). tfdtBaseMediaDecodeTime (ID 10) is a full-header field: it MUST NOT appear in a delta header, and a receiver MUST reject a delta header that carries it. The derivation is safe because CMAF ([CMAF]) requires the decode timeline to be contiguous: each fragment's baseMediaDecodeTime equals the previous fragment's plus the sum of its sample durations.¶

When the source BMDT diverges from this derivation (a splice, a capture gap, a stream re-anchor), the encoder MUST emit a full LOCMAF chunk (Section 10): a timeline discontinuity re-anchors the entire in-group reference, which is also what a recovering or late-joining receiver needs at exactly that point.¶

11.3. Deletions

Because delta encoding is additive, a field that was present in the previous chunk but is genuinely gone from the current chunk cannot be signalled by mere absence — absence means "unchanged." The deletion marker deltaDeletedLocmafIDs (ID 27, see Section 9.4) provides that signal: it lists the field IDs present in the previous chunk that no longer apply. The receiver MUST apply deletions before applying deltas, removing each listed field from the previous-chunk state so the current chunk falls back to the appropriate default (trex-derived or absent).¶

The motivating case is trunFirstSampleFlags (ID 12). A SAP-1 random-access chunk emits this field to flag its first sample as a sync sample; the immediately following non-sync chunk must say "this override no longer applies" so the receiver falls back to trex.default_sample_flags for the first sample. The second chunk emits ID 27 with a one-element list containing the value 12. The typical cost is two bytes — one length-prefixed list of one field ID — versus the tens to hundreds of bytes of re-anchoring with a full header. In a one-sample-per-chunk stream the same pattern rides tfhdDefaultSampleFlags (ID 8) instead: the sync chunk emits ID 8 and the next chunk deletes it, falling back to trex.default_sample_flags.¶

11.4. Empty delta

An empty delta property block (properties_length == 0) is valid and means "no field changed since the previous chunk." This is the steady-state case for sample-level fragmented streams. The on-wire object reduces to the delta header element plus the mdat payload.¶

12.1. Protection schemes

LOCMAF is scheme-agnostic. The packaging carries the per-sample senc metadata — initialization vectors and subsample maps — for any CENC [CENC] protection scheme; the scheme itself is identified by tenc.default_isProtected = 1 and the four-character scheme_type of the surrounding schm box, both carried in the CMAF Header, and the reconstruction of Section 14.8 does not depend on it. Schemes with per-sample initialization vectors (cenc, cbc1, cens) carry them explicitly in sencInitializationVector (ID 9) on every chunk; LOCMAF defines no IV derivation or prediction rule.¶

One scheme has scheme-specific behaviour. Under cbcs (AES-128-CBC subsample pattern encryption), the constant initialization vector (tenc.default_constant_IV) and the pattern (default_crypt_byte_block / default_skip_byte_block) travel in the CMAF Header ([CENC] §10.4). No per-sample IV appears in senc: per_sample_IV_size is 0, sencInitializationVector (ID 9) is empty and sencPerSampleIVSize (ID 16) is 0 or omitted; the reconstructed senc still sets flags = 0x000002 and carries the subsample map.¶

In practice, CMAF presentation profiles ([CMAF] Annex A) and the deployed DRM ecosystem [DASHIF-ECCP] use cenc and cbcs.¶

12.2. Box handling

The following DRM boxes are not supported. Sources that require them MUST use plain CMAF packaging:¶

14.1. Effective values

Decoding a chunk — applying deltas and deletions to the in-group reference, then the derivations of Section 10.2 and Section 11.2 — yields the chunk's effective values:¶

• n = trunSampleCount and the BMDT;¶

• the effective sample-description index: field 2 when present, else trex.default_sample_description_index;¶

• for each sample i in [0, n):¶

  • duration[i]: field 3's element i when present, else field 4 when present, else trex.default_sample_duration;¶

  • size[i]: per Section 10.2;¶

  • flags[i]: field 7's element i when present; else field 12 when present and i == 0; else field 8 when present; else trex.default_sample_flags;¶

  • cto[i]: field 5's element i when present, else 0;¶

  • when CENC is in use: IV[i] (field 9) and the subsample map (fields 11, 13, 15);¶

• the ordered genBox list (see Section 8) and the mdat payload P, whose length is the MOQT object length minus the bytes consumed by all preceding elements.¶

The effective values are the chunk's meaning: they are what a frame interface consumes directly (Section 15), and the only chunk-derived input to the canonical reconstruction below. The remaining inputs come from the CMAF Header moov: the single trak's track_ID, the trex defaults, mdhd.timescale, and (when CENC is in use) the tenc defaults.¶

14.2. Chunk box order

The reconstructed chunk is the concatenation, in this order:¶

1. each genBox, wrapped per Section 8, in payload order;¶

2. the moof box;¶

3. the mdat box.¶

Inside moof, the order is mfhd then traf. Inside traf the order is tfhd, tfdt, trun, and — when CENC metadata is present — saiz, saio, senc appended in that order. This saiz/saio/ senc order is fixed by this section (see Section 14.8).¶

14.3. mfhd

version=0, flags=0. LOCMAF does not carry mfhd.sequence_number and it is not reconstructable from the LOCMAF object alone; mfhd.sequence_number is not load-bearing for CMAF chunk decode in playback pipelines. The canonical rule is therefore mfhd.sequence_number = 0. (An implementation that needs the real sequence number can derive it from the MOQT object identity, but canonical comparison uses 0.)¶

14.4. tfhd

version=0. The canonical tf_flags:¶

• MUST set default-base-is-moof (0x020000);¶

• MUST NOT set base-data-offset-present (0x000001);¶

so sample-data offsets are relative to the start of the containing moof ([ISOBMFF]). Each optional default sets its flag and emits its value iff the effective values call for it — wire presence is irrelevant, so a strict-cmf2 encoding (Section 6) canonicalises identically to its minimal counterpart:¶

• sample-description-index-present (0x000002) iff the effective sample-description index ≠ trex.default_sample_description_index;¶

• default-sample-duration-present (0x000008) iff the effective durations are all equal AND that value ≠ trex.default_sample_duration;¶

• default-sample-size-present (0x000010) iff the uniform-size case of Section 14.6.1 places a size here;¶

• default-sample-flags-present (0x000020) iff the effective flags covered by the default (all samples, or all but the first when first-sample-flags is used, see Section 14.6) are equal AND ≠ trex.default_sample_flags.¶

tfhd.track_ID is set to the track_ID of the single trak in the CMAF Header's moov. The field order in the box is the standard ISO order: track_ID, then each present optional in flag-bit order.¶

14.5. tfdt

version=1 always (64-bit baseMediaDecodeTime), flags=0. The value is the absolute BMDT — carried in a full header, or derived per Section 11.2 for a delta chunk. A fixed version avoids a magnitude-dependent conditional in the canonical form, and live decode timelines routinely exceed 32 bits anyway (2^32 ticks is under 14 hours at a 90 kHz timescale, and wallclock-anchored timelines are past it from the start); the 4 extra bytes exist only in the reconstructed chunk, not on the wire.¶

14.6. trun

trun.version = 1 iff any effective composition-time offset is negative, otherwise 0.¶

The canonical tr_flags, set and emitted in this order:¶

• data-offset-present (0x000001) — always set;¶

• first-sample-flags-present (0x000004) — set iff n > 1 and the first sample's effective flags differ from the (equal) effective flags of all other samples;¶

• sample-duration-present (0x000100) — set iff the effective durations are not all equal;¶

• sample-size-present (0x000200) — set iff per-sample sizes are used (see Section 14.6.1);¶

• sample-flags-present (0x000400) — set iff the effective flags are neither all equal nor covered by the first-sample-flags case above;¶

• sample-composition-time-offsets-present (0x000800) — set iff any effective composition-time offset ≠ 0.¶

The trun field layout is sample_count, then data_offset, then (if first-sample-flags-present) first_sample_flags (which is flags[0]), then the per-sample records populated from the effective vectors, each carrying its present fields in ISO order: sample_duration, sample_size, sample_flags, sample_composition_time_offset. When trun.version == 1 the composition-time offset is a signed 32-bit value; when trun.version == 0 it is unsigned (reached only when every offset is ≥ 0).¶

14.7. data_offset and the mdat header

trun.data_offset = moof_size + 8: it points at the first byte of the mdat sample data, just past the 8-byte mdat header, with default-base-is-moof making offsets relative to the moof start. The mdat header is always 8 bytes: uint32be(8 + len(P)) | 'mdat'. The ISO size escapes 0 and 1 are not allowed here either: an mdat payload that does not fit the 32-bit size (len(P) > 0xFFFFFFF7) cannot be packaged as LOCMAF, and a receiver MUST reject a chunk that would require it.¶

14.8. CENC senc / saiz / saio reconstruction

This section applies when the track is protected (tenc.default_isProtected = 1) and the chunk's effective values (Section 14.1) include per-sample auxiliary information: a non-zero per_sample_IV_size, an effective subsample map, or both. Wire presence in the current header is irrelevant — under delta encoding every CENC field may be inherited from the in-group reference. The receiver reconstructs senc, saiz, and saio with the following pinned layouts; saiz and saio are never carried on the wire (see Section 12) and are recomputed here.¶

When a protected chunk has no per-sample auxiliary information — per_sample_IV_size is 0 and there is no subsample map, as under cbcs full-sample encryption with a constant IV — none of the three boxes is emitted.¶

senc. version=0. flags = 0x000002 (senc_use_subsamples) iff the effective subsample map is present, otherwise flags = 0. Layout: sample_count = n, then for each sample i:¶

• the InitializationVector, per_sample_IV_size bytes, taken from sencInitializationVector (field 9);¶

• when flags = 0x000002: subsample_count[i] as uint16 (from field 11; 0 for a sample without subsamples), followed by subsample_count[i] pairs of (BytesOfClearData as uint16, BytesOfProtectedData as uint32) drawn from fields 13 and 15, flattened in chunk order. Every sample carries the subsample_count field when the flag is set.¶

saiz. version=0, flags=0; with flags=0 the optional aux_info_type and aux_info_type_parameter fields are omitted — their defaults per [CENC] §7.1 are the track's protection scheme and 0. For each sample, the auxiliary information size is:¶

aux_size[i] = per_sample_IV_size               ; flags = 0
aux_size[i] = per_sample_IV_size
            + 2 + 6 * subsample_count[i]       ; flags = 0x000002

so when the subsample flag is set, a sample with subsample_count = 0 still counts its 2-byte subsample_count field, matching the senc layout above. An aux_size[i] above 255 does not fit the 8-bit sample_info_size of [ISOBMFF] and the receiver MUST reject the chunk. If all aux_size[i] are equal, set default_sample_info_size to that common value, sample_count = n, and emit an empty per-sample array. Otherwise set default_sample_info_size = 0, sample_count = n, and emit the n-entry sample_info_size array.¶

saio. version=0, flags=0, entry_count=1, with a single offset locating the first byte of the first sample's auxiliary information in senc (the first per-sample IV when per_sample_IV_size > 0). Per [ISOBMFF], saio offsets in a movie fragment are relative to the same base as trun.data_offset — with default-base-is-moof (Section 14.4), the first byte of the moof. genBoxes preceding the moof therefore do not enter into the offset:¶

saio.offset = offset_of_senc_within_moof + 16

where offset_of_senc_within_moof is the byte offset of the senc box from the start of the moof, and the 16 bytes skip the senc box header (8 bytes), the FullBox version and flags (4 bytes), and the sample_count field (4 bytes). The 32-bit offset of version=0 always suffices, since the offset points within the moof, whose size is bounded by its own 32-bit box size.¶

14.9. Canonical encoding

The encode side has an equally deterministic reference form. A LOCMAF encoding is canonical when:¶

• every full and delta header emits exactly the fields required by the emission rules of Section 10, with no redundant fields;¶

• every delta header carries exactly the fields whose effective values changed from the in-group reference state, plus deltaDeletedLocmafIDs listing exactly the fields that leave that state (Section 11.3);¶

• a full header appears only as the first Object of each group or where Section 11.2 requires one;¶

• field IDs appear in ascending order; and¶

• every vi64 uses its shortest form.¶

Two canonical encoders given the same CMAF input therefore produce byte-identical LOCMAF Objects, enabling golden vectors on the encode side as well as the decode side. Canonical encoding is not required for interoperability: any conformant encoding decodes to the same effective values and thus the same canonical CMAF.¶

14.10. Implementation note

Canonical reconstruction requires a normalisation pass: an implementation MUST NOT rely on incidental serialiser output (e.g. box order or tr_flags packing produced by a general-purpose ISO BMFF writer) to match the canonical bytes. Golden vectors compare the reconstructed genBox and moof bytes exactly; the mdat payload is passed through unchanged.¶

19.1. Normative References

[CENC]

"Information technology — MPEG systems technologies — Part 7: Common encryption in ISO base media file format files", ISO/IEC 23001-7:2024, 2024.

[CMAF]

"Information technology — Multimedia application format (MPEG-A) — Part 19: Common media application format (CMAF) for segmented media", ISO/IEC 23000-19:2024, 2024.

[CMSF]

Law, W., "CMSF- a CMAF compliant implementation of MOQT Streaming Format", Work in Progress, Internet-Draft, draft-ietf-moq-cmsf-01, 3 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-moq-cmsf-01>.

[ISOBMFF]

"Information technology — Coding of audio-visual objects — Part 12: ISO base media file format", ISO/IEC 14496-12:2024, 2024.

[LOC]

Zanaty, M., Nandakumar, S., and P. Thatcher, "Low Overhead Media Container", Work in Progress, Internet-Draft, draft-ietf-moq-loc-02, 15 March 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-moq-loc-02>.

[MOQT]

Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell, "Media over QUIC Transport", Work in Progress, Internet-Draft, draft-ietf-moq-transport-18, 12 May 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-moq-transport-18>.

[MSF]

Law, W. and S. Nandakumar, "MOQT Streaming Format", Work in Progress, Internet-Draft, draft-ietf-moq-msf-01, 2 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-moq-msf-01>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

19.2. Informative References

[DASH-IF-INGEST]

"DASH-IF Live Media Ingest Protocol", n.d., <https://dashif.org/Ingest/>.

[DASHIF-ECCP]

"DASH-IF Implementation Guidelines: Encryption and Content Protection (ECCP)", 2023, <https://dashif.org/docs/DASH-IF-ECCP-v1.0.0.pdf>.

[LOCMAF-SITE]

"LOCMAF — Low Overhead CMAF for MoQ", n.d., <https://locmaf.dev>.

[MOQLIVEMOCK]

"moqlivemock — Reference LOCMAF server and tooling", n.d., <https://github.com/Eyevinn/moqlivemock>.