Low Overhead CMAF for Media over QUIC (LOCMAF)

1.1. Relationship to prior work

A reason that CMAF headers are big is that they have a history in the multi-sample MP4 file format. Furthermore, each individual box starts with an 8-byte header using a fixed 4-byte size and a 4-byte identifier. This is in contrast to MOQT and QUIC that use varint.¶

A general MP4/CMAF box can be compressed by reducing the header size by using varints and shorter ids as proposed in the Compressed MP4 draft [COMPRESSED-MP4]. LOCMAF takes a more specific approach:¶

• LOCMAF does not compress the CMAF Header (initialisation segment). The CMAF Header is carried verbatim in the catalog (see Section 5). Init compression is a one-time-per-track cost; LOCMAF's wire-byte target is the per-chunk overhead, which an init codec cannot reduce. Carrying the CMAF Header verbatim has a second, deployment-driven benefit: a locmaf packaging track uses the same MSF initialisation-data mechanism as a cmaf packaging track, and when both wrap the same source they MAY refer to the same init entry (see Section 5), as being proposed for the next draft of [CMSF]. Publishers can therefore introduce LOCMAF as a more efficient wire format for clients that support it without duplicating the initialisation bytes for legacy CMAF clients — both audiences consume the same init from the same catalog entry, and the publisher only adds the LOCMAF-encoded media track alongside the CMAF one.¶

• LOCMAF's goal for the per-chunk path is functionally equivalent reconstruction, not byte-exact reconstruction: the reconstructed CMAF chunk carries the same samples, sample metadata, and CENC metadata as the source, but byte-level details that do not affect a CMAF reader are not preserved (Section 15 lists what may differ). Given that the typical target is to feed an MSE/EME player instance, this is not a disadvantage.¶

A reference implementation is available [MOQLIVEMOCK]. Worked examples and diagrams are published at [LOCMAF-SITE].¶

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 wire format.¶

3. Restricted sample_flags populations. Per-sample, default, and first-sample sample_flags MUST populate only is_leading, sample_depends_on, sample_is_depended_on, and sample_is_non_sync_sample; the fields sample_has_redundancy, sample_padding_value, and sample_degradation_priority MUST be zero in the source. See Section 11.¶

4. emsg version 1 only. Any emsg boxes in the source MUST be version 1 per CMAF §7.4.5. See Section 12.¶

If a source violates any of these, the publisher MUST NOT use LOCMAF packaging for that track and MUST instead use plain CMAF or an alternative packaging (e.g. an MSF eventtimeline companion track for events). LOCMAF and plain CMAF tracks MAY coexist in the same catalog under the same namespace.¶

6.2. Recommended source properties

The following are recommendations whose violation costs wire 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. tfdt.baseMediaDecodeTime contiguity

CMAF (§7.5.18) requires that each fragment's BMDT equal the previous fragment's BMDT plus the sum of its sample durations. The delta-chunk BMDT derivation defined in Section 10 relies on this property. Re-anchoring is signalled in-band by emitting an absolute BMDT override (see Section 10).¶

6.4. 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 ~6 B per group but produces reconstructed CMAF chunks that satisfy CMAF §7.7.3 fragment self- decodability (each chunk is a single-chunk fragment in the LOCMAF mapping). It does not need to be signaled since it does not affect wire compatibility between encoders and decoders.¶

7.1. Top-level header IDs

LOCMAF defines two top-level header IDs:¶

Receivers MUST skip (and SHOULD log) unrecognised header_id values rather than abort. The MOQT object length terminates the unknown object cleanly.¶

Future extensions adding new top-level object kinds use any unassigned ID, allocated via the IANA registry defined in Section 17.¶

7.2. Object layout

+-----------------------------+
| header_id        (varint)   |   top-level object kind
+-----------------------------+
| properties_length (varint)  |   byte length of the properties block
+-----------------------------+
| properties      (variable)  |   sequence of (field_id, value) tuples
+-----------------------------+
| mdat raw payload (rest)     |   length = MOQT-object-len - (above)
+-----------------------------+

header_id and properties_length are variable-length integers using the encoding defined by MoQ Transport [MOQT] for the session's MOQT version.¶

The mdat payload is the contents of the CMAF mdat box — the sample data, without the surrounding 8-byte size + 'mdat' box header. The receiver reconstructs a standard mdat box by wrapping these bytes in an 8-byte ISO BMFF header.¶

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

7.3. Property encoding (parity rule)

The properties block is a flat sequence of (field_id, value) tuples. Field IDs are MOQT varints. The value encoding is determined by the parity of the ID:¶

• Even ID: scalar varint. The value is a single MOQT varint. No length prefix. In delta chunks, the encoded value is a zigzag varint (see Section 7.4) of the signed delta against the in-group reference; in full chunks it is an absolute unsigned MOQT varint.¶

• Odd ID: length-prefixed bytes. The tuple is field_id | value_length | value_bytes. The interpretation of the bytes is per-field; varint-list fields concatenate elements (each element is a zigzag varint (see Section 7.4) in delta context, an absolute MOQT varint in full context), raw-bytes fields carry opaque content. The one exception is the signed list trunSampleCompositionTimeOffsets (ID 5): its elements are zigzag varints (see Section 7.4) in BOTH full and delta context, because composition time offsets are signed in trun version 1 (see Section 8.1).¶

Field IDs MAY appear in any order; receivers MUST tolerate any ordering. Encoders SHOULD emit IDs in ascending order to produce deterministic wire bytes.¶

7.4. Zigzag varint encoding

A zigzag varint is a signed integer encoded as an unsigned MOQT varint by interleaving non-negative and negative values so that small-magnitude values of either sign occupy small unsigned values, and thus the shortest varint 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 MOQT varint ([MOQT]); decoders read the MOQT varint 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 of the LOCMAF wire format.¶

LOCMAF uses zigzag varints wherever a signed delta against the in-group reference is written, namely in scalar even-ID fields (see above) and per-element in varint-list odd-ID fields. Absolute values in LocmafFullHeader are encoded as plain unsigned MOQT varints, not zigzag — with one exception: the signed list trunSampleCompositionTimeOffsets (ID 5) carries zigzag varints even in a full chunk, because composition time offsets are signed in trun version 1 (the common CMAF case: B-frames make the composition/decode-time relation non-monotonic).¶

7.5. Full vs delta dispatch

The full-vs-delta distinction is signalled exclusively by the top-level header_id, never by the MOQT object position within a group.¶

1. The first object of every MOQT group MUST be a LocmafFullHeader.¶

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 receiving a LocmafFullHeader, the decoder 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 header_id alone. It MUST NOT infer "full" from object index 0 or "delta" from object index > 0.¶

8.1. Fields from moof child boxes

Fields drawn from boxes inside moof.traf (i.e. from trun, tfhd, tfdt, or senc). The symbol prefix names the containing box, and the field IDs are the same across both Full and Delta chunks.¶

† Sample-flag fields (IDs 7, 8, 12) carry the 5-bit packed encoding defined in Section 11.¶

‡ The signed list (ID 5) carries zigzag varints (see Section 7.4) per element in BOTH full and delta chunks, because composition time offsets are signed in trun version 1. This is the sole odd-ID list whose full-chunk elements are not plain unsigned varints.¶

The remaining name components map field-for-field onto the source box (e.g. tfhdDefaultSampleDuration ↔ tfhd.default_sample_duration, trunFirstSampleFlags ↔ trun.first_sample_flags). Indexing rules: per-sample lists (IDs 1, 3, 5, 7, 11) carry the samples[i].* values from their box; the per-subsample lists (IDs 13, 15) carry senc.samples[i].subsamples[j].* flattened in chunk order; and sencInitializationVector (9) is the concatenation of per-sample IVs, each sencPerSampleIVSize bytes long.¶

The ID space is structurally aligned with the parity rule: every default/scalar field has an even ID and every per-sample list field has an odd ID, with sencInitializationVector (9) as the documented exception (raw bytes rather than a list).¶

8.2. prft fields

The ProducerReferenceTimeBox (prft, [CMAF] §6.6.8, §7.3.2.4) carries an NTP-style wall-clock anchor tied to a media time. In CMAF it MAY precede any moof inside a CMAF chunk and applies to the addressable media object whose moof it precedes. LOCMAF carries it per-chunk through the following fields:¶

prftNtpTimestamp (ID 18) and prftMediaTime (ID 20) have no default value, so a full LOCMAF chunk that carries prft MUST include both; prftVersion (ID 22) and prftFlags (ID 24) default as given above and MAY be omitted when they match their defaults. The receiver reconstructs a prft box in the output chunk iff IDs 18 and 20 are present.¶

In a delta chunk, the scalar fields are zigzag-encoded deltas against the most recent full chunk in the same group that itself carried prft fields; a field left absent is unchanged from that reference. Deltas are signed because both quantities can decrease in valid CMAF streams: producer NTP clocks can be corrected backward, and composition-time reordering with B-frames can place a chunk's presentation anchor before the previous chunk's. If the previous full chunk had no prft, an encoder that begins emitting prft mid-group MUST use absolute encodings (i.e. re-anchor).¶

This presence-signalling supports three producer patterns with no further wire-format support:¶

1. None: no prft field is ever emitted.¶

2. Per-group: absolute prft fields on the LocmafFullHeader only, absent from subsequent LocmafDeltaHeader objects in the group.¶

3. Per-chunk: absolute prft fields on the LocmafFullHeader, delta prft fields on subsequent LocmafDeltaHeader objects.¶

encoder: delta_i64 = (int64)(current_ntp64 - previous_ntp64)
         wire      = MOQT-varint(zigzag(delta_i64))

receiver: delta_i64 = unzigzag(MOQT-varint-decode(wire))
          current_ntp64 = previous_ntp64 + (uint64)delta_i64

8.3. styp fields

Fields whose source is the FileTypeBox payload of a styp box ([ISOBMFF], §4.3) at the top of a CMAF chunk:¶

LOCMAF does not carry styp.minor_version on the wire. Per [CMAF] §7.2, minor_version is 0 for any structural CMAF brand used as major_brand, so the reconstructed styp.minor_version is always 0.¶

styp fields MAY appear only in LocmafFullHeader; encoders MUST NOT emit them in LocmafDeltaHeader. Per [CMAF] §7.3.3.1, a styp inside an addressable media object is ignored by players, so the delta path has no use for it.¶

If a LocmafFullHeader carries no stypBrandList, the receiver emits no styp box in the reconstructed CMAF chunk. CMAF ([CMAF] §7.3.3.1) does not require a styp for decoding or playback; players that need brand information consult the CMAF Header's ftyp. Per [CMAF] §7.2, when an encoder does emit stypBrandList, the reconstructed styp.minor_version is 0.¶

8.4. emsg field

The presence of emsgList is independent of LocmafFullHeader vs LocmafDeltaHeader. Both kinds carry the full list when present; there is no delta encoding for emsg.¶

8.5. Delta deletion marker

9.1. Emission rules for moof child-box fields

The encoder walks the source moof (paired with the catalog's moov) and emits each moof field only when the value cannot be derived from the moov's trex defaults:¶

tfhdSampleDescriptionIndex

tfhd.HasSampleDescriptionIndex() AND value ≠ trex.default_sample_description_index¶

tfhdDefaultSampleDuration

tfhd.HasDefaultSampleDuration() AND value ≠ trex.default_sample_duration¶

tfhdDefaultSampleSize

all samples in the chunk have the same size AND that size ≠ trex.default_sample_size AND sample_count > 1¶

tfhdDefaultSampleFlags

tfhd.HasDefaultSampleFlags() AND value ≠ trex.default_sample_flags¶

tfdtBaseMediaDecodeTime

always¶

trunSampleCount

always¶

trunFirstSampleFlags

trun.HasFirstSampleFlags()¶

trunSampleSizes

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

trunSampleDurations

trun.HasSampleDuration()¶

trunSampleCompositionTimeOffsets

trun.HasSampleCompositionTimeOffset()¶

trunSampleFlags

trun.HasSampleFlags()¶

sencPerSampleIVSize

senc present AND per_sample_iv_size ≠ tenc.default_per_sample_iv_size¶

sencInitializationVector

senc present AND per_sample_iv_size > 0 AND samples carry IVs (see also Section 13.4)¶

sencSubsampleCount

senc present AND samples carry subsample maps¶

sencBytesOfClearData

same as sencSubsampleCount¶

sencBytesOfProtectedData

same as sencSubsampleCount¶

In strict cmf2 mode (see Section 6), tfhdDefaultSampleDuration, tfhdDefaultSampleSize, tfhdDefaultSampleFlags, and tfhdSampleDescriptionIndex are emitted unconditionally on the full chunk, even when they match trex.¶

9.2. Emission rules for prft / styp / emsg fields

stypBrandList is emitted iff the source CMAF chunk preceded its moof with a styp box. When omitted, the receiver produces no styp in the reconstructed chunk.¶

prft fields (18, 20, 22, 24) are emitted iff the source CMAF chunk preceded its moof with a prft box, subject to the per-field defaults described in Section 8.2 (encoders MAY omit prftVersion when it is 1 and prftFlags when it is 0). All emitted values are absolute.¶

emsgList is emitted iff the source CMAF chunk preceded its moof with one or more v1 emsg boxes. See Section 12 for the record format.¶

10.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 LocmafFullHeader, the previous chunk starting from that re-anchor).¶

10.2. tfdtBaseMediaDecodeTime is normally derived

The receiver derives the new BMDT as previous_bmdt + sum(previous_sample_durations). This is safe because CMAF requires the decode timeline to be contiguous — each fragment's baseMediaDecodeTime equals the previous fragment's plus the sum of its sample durations (see Section 6.3, which carries the CMAF reference and its normative keyword). When the source BMDT nevertheless diverges from this derivation (audio pre-roll, splicing, stream re-anchor), the encoder MUST emit tfdtBaseMediaDecodeTime (ID 10) in the delta chunk as an absolute unsigned varint (i.e. the same encoding as in a full chunk, not a zigzag delta). The receiver checks for the field first and uses its value when present.¶

10.3. Deletions

Delta encoding in LOCMAF is additive: a field absent from a LocmafDeltaHeader is treated as unchanged from the previous chunk. This compresses the common case (most moof fields stay stable from chunk to chunk) but on its own gives an encoder no way to signal that a field which was present in the previous chunk is genuinely gone in the current one. The deletion marker provides that signal.¶

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 deltaDeletedLocmafIDs field (ID 27) carries a varint list of field IDs that were present in the previous chunk but are no longer present. The decoder applies deletions before applying deltas. Example: when the first chunk of a group carried trunFirstSampleFlags (a SAP-1 sync sample) and the second chunk does not, the second chunk emits ID 27 with a one-element list containing ID 12. The typical cost is two bytes — one length-prefixed list with one field ID — versus the tens to hundreds of bytes of re-anchoring.¶

10.4. Empty delta

An empty delta payload (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 LOCMAF object reduces to LocmafDeltaHeader | properties_length=0 | mdat, which is two bytes plus the mdat.¶

10.5. prft and emsg in delta chunks

prft fields use the encoding above (scalar values become zigzag deltas against the in-group reference). emsgList carries the full new event list, with no delta encoding — see Section 12.¶

stypBrandList (ID 23) MUST NOT appear in a LocmafDeltaHeader.¶

11.1. Wire encoding

The 5-bit packed value (LSB first):¶

trunSampleFlags (ID 7) carries this 5-bit value (range 0–31) per sample. tfhdDefaultSampleFlags (ID 8) and trunFirstSampleFlags (ID 12) carry the same 5-bit transport.¶

In a full chunk the field is an unsigned varint scalar (or list). In a delta chunk it is a signed zigzag varint (or list of zigzag deltas).¶

11.2. Reconstruction

The receiver expands the 5-bit transport into a 32-bit sample_flags:¶

sample_flags = (is_depended_on << 22)
             | (depends_on     << 24)
             | (non_sync       << 16)

is_leading, sample_has_redundancy, sample_padding_value, and sample_degradation_priority are reconstructed as zero.¶

11.3. Encoder constraint

The encoder MUST validate that the source's sample_flags populates only the five bits listed above (see Section 6). Source content that uses other bits MUST be carried via plain CMAF packaging instead.¶

12.1. Relationship to MSF eventtimeline

New MOQT deployments SHOULD use a companion MSF eventtimeline track [MSF] for event metadata rather than inline emsg. LOCMAF's emsg support exists primarily to preserve inline events in sources transcoded from DASH or CMAF Ingest [DASH-IF-INGEST].¶

12.2. Record format

Each record inside emsgList is a compact encoding of a v1 emsg payload:¶

record = scheme_id_uri          (varint length + UTF-8 bytes)
       | value                  (varint length + UTF-8 bytes)
       | timescale              (varint; 0 = "use track mdhd.timescale")
       | presentation_time      (encoding depends on timescale; below)
       | event_duration         (varint, `timescale` ticks; 0 = unknown)
       | id                     (varint)
       | message_data           (varint length + opaque bytes)

reference_track_id and version are implicit (the track this chunk belongs to, and 1 respectively).¶

13.1. Supported schemes

LOCMAF v0.2 supports the following CENC [CENC] protection schemes, identified by the tenc.default_isProtected = 1 track defaults and the four-character scheme_type in the surrounding schm box:¶

• cenc: AES-128-CTR full-sample encryption. Per-sample initialization vectors are big-endian counters advanced by the per-sample encrypted-byte total ([CENC], §10.1); LOCMAF carries these IVs via sencInitializationVector and permits omission under the counter rule of Section 13.4.¶

• cbcs: AES-128-CBC subsample pattern encryption with a constant initialization vector taken from tenc.default_constant_iv ([CENC], §10.4); no per-sample IV appears in senc, and the pattern (default_crypt_byte_block / default_skip_byte_block) is carried verbatim with the CMAF Header.¶

The cbc1 and cens schemes are out of scope; sources using them MUST fall back to plain CMAF packaging.¶

13.2. Supported boxes

13.3. Unsupported boxes

The following CMAF DRM boxes are not supported by LOCMAF v0.2. Sources that require them MUST use plain CMAF packaging instead:¶

13.4. CENC IV counter prediction (optional)

For the cenc scheme, ISO/IEC 23001-7 §9.6 specifies that the per-sample initialization vector is a big-endian counter advanced sample-by-sample by exactly ceil(total_encrypted_bytes_in_sample / 16) AES blocks. Both endpoints already see the per-sample encrypted-byte totals (sencBytesOfProtectedData) and the IV anchor (carried on the first full chunk of the track), so the receiver can derive every subsequent per-sample IV deterministically.¶

LOCMAF v0.2 permits encoders to omit sencInitializationVector (ID 9) when the source follows this counter rule, and requires receivers to support derivation:¶

• An encoder MAY omit sencInitializationVector on full and delta chunks when every per-sample IV in the chunk matches the value derived by the CENC counter rule from the previous chunk's IVs and sencBytesOfProtectedData totals.¶

• A receiver MUST be able to derive per-sample IVs from the counter rule. When sencInitializationVector is absent and the scheme is cenc, the receiver advances the running IV counter and uses the derived value.¶

• When the source diverges from the counter rule (random IVs, mid-track counter restart, or any non-conformant strategy), the encoder MUST emit sencInitializationVector absolutely on every affected sample.¶

The cbcs scheme uses a constant IV from tenc.default_constant_iv carried once via the CMAF Header. There is no per-sample IV in the moof in the first place, so counter prediction does not apply to cbcs.¶

17.1. Catalog packaging value and locmafVersion

Following the precedent of [CMSF] — whose IANA Considerations record no IANA actions for its "cmaf" packaging value or its added catalog fields — this document registers neither of the following with IANA:¶

• packaging: "locmaf" extends the [MSF] packaging-values table (see Section 4). [MSF] defines no IANA registry for packaging values; new values are introduced by the documents that define them.¶

• locmafVersion is a track-level catalog field defined by this document (see Section 4). [MSF] permits documents and producers to define additional catalog fields and maintains no IANA registry of them.¶

The set of valid locmafVersion values — "0.2" for this document — is governed by this specification and its successors; no IANA action is required. Should a future [MSF] revision introduce an IANA packaging-value registry, the "locmaf" value SHOULD be registered there, while locmafVersion and its values remain document-governed.¶

17.2. LOCMAF Top-Level Header IDs

This document defines a new registry for LOCMAF top-level header IDs.¶

All other IDs in the unsigned varint range are available for assignment via Specification Required ([RFC8126]).¶

LOCMAF property field IDs are part of this document's wire format and are not registered with IANA. New field IDs are introduced through revisions of this specification, signalled by a bump of the locmafVersion catalog value (see Section 4). The full field-ID assignment for this version is given in Section 8.¶

18.1. Normative References

[CMSF]

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

[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>.

18.2. Informative References

[CENC]

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

[CMAF]

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

[COMPRESSED-MP4]

Curley, L., "Compressed MP4", Work in Progress, Internet-Draft, draft-lcurley-compressed-mp4-00, 16 March 2026, <https://datatracker.ietf.org/doc/html/draft-lcurley-compressed-mp4-00>.

[DASH]

"Information technology — Dynamic adaptive streaming over HTTP (DASH) — Part 1: Media presentation description and segment formats", ISO/IEC 23009-1:2026, 2026.

[DASH-IF-INGEST]

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

[ISOBMFF]

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

[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>.

[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>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.