MPEG Media Transport (MMT) Packaging for Media over QUIC

1.1. Relationship to Other MoQ Media Formats

This specification complements existing MoQ packaging formats. The MOQT Streaming Format (MSF) [I-D.ietf-moq-msf] carries media packaged with the Low Overhead Media Container (LOC) [I-D.ietf-moq-loc], and CMSF [I-D.ietf-moq-cmsf] carries media packaged in the Common Media Application Format (CMAF):¶

The last column names the block profile under which [MOQ-FEC] protects tracks of each packaging. Under "iso-ssbg1-v1" each FEC source packet (FEC Type 1) is one source symbol. Under "moq-object-v1" each loc or cmaf object whose Object Status is Normal occupies whole source symbols.¶

MMT packaging fits these cases:¶

• Ingesting ATSC 3.0 or ARIB STD-B60 broadcasts¶
• FEC protection is required for multicast delivery¶
• Hybrid broadcast/unicast architectures are deployed¶
• Interoperability with broadcast receivers is needed¶

CMAF packaging (CMSF) fits these cases:¶

• Content originates as DASH/HLS¶
• No multicast delivery is planned¶
• Interoperability with existing CDN infrastructure is needed¶

3.1. MMTP Header Format

MMTP Header (12 bytes minimum) {
  Version (2),
  Packet Counter Flag (C) (1),
  FEC_type (FEC) (2),
  Reserved (1),
  Extension Flag (X) (1),
  RAP Flag (R) (1),
  Reserved (2),
  type (6),
  Packet ID (16),
  Timestamp (32),
  Packet Sequence Number (32),
  [Packet Counter (32)],       // Present if C=1 (never: C=0)
  [Header Extension (..)]      // Present if X=1
}

The fixed fields sum to 96 bits (three 32-bit words). Byte 0 is version(2) | packet_counter_flag(1) | FEC_type(2) | reserved(1) | extension_flag(1) | RAP_flag(1); byte 1 is reserved(2) | type(6), i.e. the packet type occupies the low six bits of the second byte ([ISO.23008-1] Clause 9.2).¶

Senders MUST set all reserved bits in the MMTP packet header to zero. Receivers MUST ignore their values after validating the header; they MUST NOT assign private semantics to reserved bits.¶

Every packet of an MMTP packet flow -- media, repair, and signaling packets alike, on every delivery path -- MUST set the packet counter flag C to 0, so no packet carries the Packet Counter field. [ISO.23008-1] Clause 9.2.3 requires all packets of an MMTP flow to share one setting of C; this profile fixes that setting at 0. The MMTP packet header is therefore 12 bytes unless X = 1 adds a header extension.¶

This document profiles MMTP version 0 (V = 00) of ISO/IEC 23008-1:2023 as amended by Amd 1:2025. A packet whose version is not 00 MUST be rejected before its type field is parsed: version 1 uses a different type-field layout and is not defined by this profile. The C = 0 requirement above is also a conformance gate; packets with C = 1 MUST be rejected. An X = 1 header extension is parsed according to its declared length, but this document defines no additional version or packet-counter semantics.¶

Key fields for MoQ mapping:¶

• Packet ID: Maps to MoQ track within namespace. This document reserves packet_id 0 for the MMTP signaling flow: MMTP packets of packet type 0x02 carrying signaling messages, such as the PA message of a multicast endpoint flow ([MOQ-MULTICAST] Section 5) and the AL-FEC message of Section 8.3. No MoQ track is advertised for the signaling flow, but an mmtp source track MAY carry its AL-FEC message as an object (Section 8). An MMTP packet carrying media (packet type 0x00) or a repair symbol (packet type 0x03) MUST NOT use packet_id 0; a track's packet_id is in the range 1..65535, and on multicast delivery it is the packetId the endpoint advertises for the track ([MOQ-MULTICAST] Section 4.1). On every delivery path, a receiver MUST NOT deliver an MMTP packet on packet_id 0 to a media or repair decoder, including one received as the payload of an object of a media or repair track: a receiver that processes MMTP signaling reads it as a signaling message, and any other receiver discards it ([MOQ-MULTICAST] Section 5 states the same rule for every unlisted packet_id on multicast)¶
• Timestamp: UTC wallclock send time in the NTP short format of [RFC5905] Section 6 (32 bits: 16-bit seconds and 16-bit fraction, relative to the NTP epoch), carried inside the object payload. MoQ Transport defines no per-object timestamp field; receivers needing the send time read it from the preserved MMTP packet header. Because the seconds part is 16 bits, the value wraps every 65 536 seconds (about 18.2 hours): it identifies the send time modulo that period and MUST NOT be interpreted as an absolute wallclock time without an out-of-band era reference. It is used for packet delivery and jitter measurement and is never media time: not a decoding timestamp, presentation timestamp, duration, media-clock epoch, or movie-fragment identifier¶
• Packet Sequence Number: per-packet_id, incremented by one modulo 2^32 across the flow ([ISO.23008-1] Clause 9.2.3); carried inside the object payload for wrap-aware MMTP-layer loss/ordering detection. It is not the MoQ Object ID. Object IDs number the objects of a group in source order, starting at zero in each group (Section 4.6).¶
• FEC Type: 0=no AL-FEC, 1=AL-FEC source packet (exactly one 4-byte Source FEC Payload ID trails the packet, [MOQ-FEC] Section 8.5), 2=AL-FEC repair packet for FEC payload ID mode 0, 3=AL-FEC repair packet for FEC payload ID mode 1 (not used by this mapping) ([ISO.23008-1] Clause 9.2.3)¶
• RAP Flag: 1 indicates Random Access Point. On a track that the catalog protects with a keyframe overlay, a packet with RAP_flag 1 also carries the overlay's SS_ID in a header extension of type 0x8B01 ([MOQ-FEC] Section 8.5.1)¶

A signaling packet (packet type 0x02, on packet_id 0) MUST carry its messages in the signaling message mode of [ISO.23008-1] Clause 9.3.4: its MMTP payload begins with the 2-byte payload header of Clause 9.3.4.2:¶

Signaling Message Payload Header {
  f_i (2),                    // fragmentation indicator
  RES (4),                    // reserved, set to 0
  H (1),                      // 1: each MSG_length is 32 bits
  A (1),                      // aggregation_flag
  frag_count (8),             // fragmentation counter
}

When A = 1, a MSG_length field of 16 bits, or 32 bits when H = 1, precedes each aggregated message; when A = 0 no MSG_length field is present. The signaling message follows ([ISO.23008-1] Clause 10.2), beginning with its message_id. A packet that carries one complete signaling message without aggregation has f_i = 00, A = 0, and frag_count = 0, and its sender sets H = 0 (H has no effect when A = 0), so its payload header is the two bytes 0x00 0x00 and the message_id immediately follows them. A receiver ignores H when A = 0 and parses the header field by field, never by matching those two bytes.¶

4.1. Track Structure

An MMT stream maps to MoQ tracks as follows:¶

[I-D.ietf-moq-msf] Section 6 maps each object to a new stream. An mmtp track does not follow that rule. It maps each MPU data unit to one subgroup (Section 4.3), and the objects of a subgroup share one stream ([I-D.ietf-moq-transport] Section 2.2), so each data unit's fragments travel in order on one stream. An mmtp track keeps the Group and Object numbering of [I-D.ietf-moq-msf] Sections 6.1 and 6.2: Group numbers are unique and increase monotonically (Section 4.4.1), and Object IDs start at zero in each group and increase by one (Section 4.6).¶

4.2. Object Payload

Each MoQ object carries one complete MMTP packet:¶

MoQ Object Payload {
  MMTP Packet Header (12+ bytes),
  MMTP Payload (MPU-mode payload header,
                then an FT=0, FT=1, or FT=2 data-unit fragment),
  [Source FEC Payload ID (32)],   // trails FEC Type=1 packets
}

The object payload begins at byte zero of the preserved MMTP packet header. It has no MoQ-private envelope, length prefix, harness prefix, or other undocumented bytes before that header. For an FEC Type 1 packet, the Source FEC Payload ID and any profile-defined MMTP header extensions remain in their specified wire locations. No object-layer prefix, suffix, or private replacement for those fields is permitted. When [MOQ-FEC] requires the FEC Source Info Object Property (type 0x11), its value remains the four-byte, network-byte-order SS_ID defined by that document; the property is object metadata and is not inserted into this payload.¶

The one exception is the OPTIONAL AL-FEC signaling object of Section 8: its payload is a complete MMTP signaling packet (packet type 0x02) on packet_id 0 with FEC Type 0. Its MMTP payload is the signaling message payload header of Section 3.1 followed by one complete AL-FEC message (f_i = 00, A = 0), rather than an MPU-mode payload header and data-unit fragment, and it carries no Source FEC Payload ID. No other object on an mmtp source track uses packet type 0x02 or packet_id 0.¶

Throughout this document, "MMTP packet" means the header-included wire unit and "MMTP payload" means the bytes that follow the packet header, per [ISO.23008-1]. Both MMTP header layers are always preserved: the packet header carries the FEC Type, RAP Flag, and timestamp, and the MPU-mode payload header (the first bytes of the MMTP payload) carries the Fragmentation Indicator and MPU sequence number that receivers and the FEC layer depend on. A publisher that wishes to deliver raw ISOBMFF fragments without MMTP encapsulation publishes the track with CMAF packaging [I-D.ietf-moq-cmsf] instead. In this profile an MPU can contain one or more ISOBMFF movie fragments: FT=1 carries one movie fragment's metadata and each FT=2 data unit carries one whole sample or one producer-authored subsample of a sample (Section 5.2.1).¶

4.3. Group Boundaries

This section defines the object layout of mfu mode (mmtpMode: "mfu", Section 12.1).¶

Group boundaries align with MPU boundaries, and subgroup boundaries align with MPU data-unit boundaries:¶

• Each group contains all objects of exactly one MPU: a change of MPU sequence number starts a new group, numbered per Section 4.4.1.¶
• Subgroup 0 of each group carries exactly one complete FT=0 MPU metadata packet. Its data unit contains the authored initialization boxes, including ftyp, mmpu, and moov, and uses FI=0. When the publisher carries the OPTIONAL AL-FEC signaling object of Section 8, that object is in Subgroup 0 of the same group and is the object immediately before the FT=0 object; Subgroup 0 then carries exactly these two objects. No other object precedes FT=0, and a group carries at most one signaling object.¶
• Subgroups 1..M each carry exactly one subsequent MPU data unit in authored order. An FT=1 movie-fragment-metadata data unit is one complete FI=0 object. An FT=2 timed sample is either one FI=0 object or an FI=1, zero-or-more FI=2, FI=3 object chain. A timed sample whose media exceeds one data unit's capacity is carried as a contiguous run of producer-authored subsample data units (Section 5.2.1), one subgroup per subsample data unit, in ascending offset order. Section 5.2 defines the only permitted fragmentation state machine.¶
• A timed MPU MUST publish its single FT=0 metadata data unit before any FT=1 or FT=2 data unit; only the OPTIONAL signaling object of Section 8 may precede FT=0. It then MUST publish each FT=1 data unit before every FT=2 sample or subsample that references that movie fragment. If an MPU contains multiple movie fragments, the sequence repeats as FT=1 followed by its FT=2 samples. A receiver MUST validate and process subgroups in ascending Subgroup ID, not network arrival order, and MUST NOT admit an FT=2 sample before its FT=1 metadata: concurrently delivered subgroups MAY arrive in any order and are buffered until their turn. A missing or duplicate FT=0 invalidates the group; a gap, duplicate data-unit identity, or invalid FT=1/FT=2 sequence in that logical order invalidates the affected movie fragment. A receiver MUST NOT infer the missing structure. The signaling object is not a data unit: its presence or absence does not affect this validation, and a signaling object anywhere other than immediately before FT=0 in Subgroup 0, or a second one in a group, invalidates the group.¶
• The FI=0 or FI=1 object that begins the first FT=2 sample of each timed group -- for a subsample-partitioned sample, the object that begins its offset-0 data unit -- MUST have RAP Flag = 1.¶

The MPU sequence number remains present in-band (in the MMTP payload header of every MPU fragment) and delimits which packets belong to the same group, but it is not the MoQ Group number. Publishers MUST NOT copy the MPU sequence number into the Group number, and subscribers MUST NOT derive media time or switching decisions from it. (The MPU sequence number is a per-Asset counter. It starts at zero for the first MPU in an Asset and increments by one for every following MPU ([ISO.23008-1] Clause 7.3.3), but it is Asset-local: independently packetized renditions need not assign the same MPU number to the same media instant. Counter-based group numbering therefore cannot satisfy the switching-set alignment requirements of Section 4.4.)¶

For an ISOBMFF source, the publisher MUST preserve initialization in FT=0, MUST copy the authored moof and the original mdat prefix through the byte before the first media sample byte-for-byte into FT=1, and MUST copy the referenced sample bytes byte-for-byte and without transformation into FT=2. A receiver can therefore reconstruct the authored movie fragment without synthesizing box fields, sample timing, or media bytes (Section 5.1).¶

Mapping each data unit to its own subgroup makes a complete metadata unit or sample the unit of in-order delivery, loss, and FEC. A publisher MUST send the objects of an mmtp track in subgroups, not as datagrams: a datagram object belongs to no subgroup ([I-D.ietf-moq-transport] Section 2.2) and cannot carry this mapping. Subgroups can be delivered concurrently, and a subgroup can still be lost, for example when its stream is reset on a delivery timeout ([I-D.ietf-moq-transport] Sections 5.2 and 11.3.2); the resulting gap invalidates the affected movie fragment rather than authorizing inferred metadata, timing, or cadence.¶

4.4. Switching Sets

When multiple tracks represent alternative renditions of the same media (e.g., an adaptive bitrate (ABR) ladder), they form a switching set: a set of alternate tracks that MUST be time-aligned per [I-D.ietf-moq-msf] Section 4.2 (the same construct that [I-D.ietf-moq-cmsf] Section 3.2 applies to CMAF tracks). MoQ Group boundaries MUST be media-time-aligned across all tracks of a switching set so that subscribers can switch at group boundaries. Tracks with equal group durations MUST carry the same Group number for the same media interval. Only an intra-only mmtp track can have a shorter group duration than the other tracks, under the exception of Section 4.4.2, which also defines its Group number mapping. A cmaf member keeps equal group durations and the Group number alignment that [I-D.ietf-moq-cmsf] Section 3.2 requires. The switch is without discontinuity when the MPUs are closed groups of pictures (GOPs). On a join or switch at a Group boundary, leading pictures (Section 4.4.1) that reference the preceding Group are not decodable, and presentation of the new track begins at its RAP. If the old track's next MPU has leading pictures, neither track has decodable pictures for their presentation interval, and the receiver conceals that gap.¶

Switching-set membership is declared in the catalog via the per-track field:¶

altGroup (OPTIONAL, unsigned integer)

defined by [I-D.ietf-moq-msf] Section 5.2.12: an integer identifying a group of tracks that are alternate versions of one another. Two tracks are members of the same switching set if and only if both carry the altGroup field and the values are equal. A track that omits altGroup is a member of no switching set, and the switching-set requirements of this section do not bind it. A repair track (Section 8.2) carries no altGroup. It is not an alternate rendition, and its Groups are FEC blocks ([MOQ-FEC] Section 7.5), not media-time-aligned Groups. A subscriber finds the repair tracks of the rendition it selects through that rendition's fec.repairTrack and the depends fields of [MOQ-FEC] Section 5.1.1.¶

relative_ticks = ticks - presentationAnchorTicks
group_number = floor(relative_ticks / groupDurationTicks)

presentation_time = (ticks - presentationAnchorTicks) / timescale

(ticksA - presentationAnchorTicksA) * timescaleB ==
    (ticksB - presentationAnchorTicksB) * timescaleA

A: groupDurationTicks = 2000 * 90000 / 1000 = 180000
B: groupDurationTicks = 2000 * 44100 / 1000 =  88200

Same media instant, t = 10.5 s on the shared timeline:
A: relative_ticks = 945000 -> floor(945000 / 180000) = 5
B: relative_ticks = 463050 -> floor(463050 /  88200) = 5

MPU 0 ticks = -90000: relative_ticks =  90000 -> group 0
MPU 1 ticks =  90000: relative_ticks = 270000 -> group 1

{
  "timescale": 90000,
  "presentationAnchorTicks": 0,
  "groupDurationTicks": 180000,
  "mpuSamplePtsInDecodeOrder": [
    [0, 6000, 3000],
    [180000, 174000, 177000]
  ],
  "ticks": [0, 180000],
  "groupNumbers": [0, 1]
}

groupDurationMs (REQUIRED unless groupDurationTicks is present,
                positive unsigned integer, milliseconds)

groupDurationTicks (OPTIONAL, positive unsigned integer)

{
  "version": "draft-01",
  "tracks": [{
    "name": "video-30fps",
    "packaging": "mmtp",
    "isLive": true,
    "mmtpMode": "mfu",
    "timescale": 44100,
    "presentationAnchorTicks": 0,
    "groupDurationTicks": 1470,
    "codec": "avc1.64001f",
    "framerate": 30,
    "bitrate": 2000000
  }]
}

A.groupDurationTicks * B.timescale ==
    B.groupDurationTicks * A.timescale

groupDurationTicks * framerate == timescale

(G.groupDurationTicks * I.timescale) %
    (I.groupDurationTicks * G.timescale) == 0

keyframeIntervalMs (OPTIONAL, unsigned integer, milliseconds)

keyframeIntervalTicks (OPTIONAL, unsigned integer)

4.5. Init Segment Signaling

Publishers signal MPU metadata inline as the complete FT=0 object in Subgroup 0 of every group (Section 4.3), preceded in that subgroup only by the OPTIONAL AL-FEC signaling object of Section 8. Its data unit contains the authored initialization boxes, including ftyp, mmpu, and moov.¶

In addition, publishers SHOULD carry decoder initialization data in the catalog, using the mechanism of the base catalog that [I-D.ietf-moq-cmsf] Section 3.1 also uses for CMAF headers. The data is an entry of the root initDataList array ([I-D.ietf-moq-msf] Section 5.1.7) whose type is "inline" and whose data is the base64 encoding of an ISOBMFF initialization segment (ftyp + moov) sufficient to initialize the decoder for the track (including the codec configuration record, e.g. avcC or hvcC). The track's initRef field ([I-D.ietf-moq-msf] Section 5.2.13) holds that entry's id. This lets a subscriber initialize its decoder at catalog load, before the first FT=0 MPU metadata object arrives, removing one delivery round trip from the join path (Section 6.1). A receiver ignores an initRef that names no entry, or names an entry whose type is not "inline", and joins without catalog initialization data.¶

Catalog initialization data is a join optimization, not a replacement for in-band metadata: the per-group FT=0 MPU metadata remains authoritative, and a receiver MUST adopt in-band metadata when it differs from the catalog's initialization data. Catalog content is untrusted input; a receiver MUST validate that the decoded data is a well-formed ftyp + moov sequence before passing it to a decoder, and MUST discard it otherwise.¶

Some implementations carry the same bytes in a per-track string field, initData, which [I-D.ietf-moq-msf] does not define. A receiver MAY accept initData on an mmtp track and validates it in the same way. When a track carries both initRef and initData, the receiver uses initRef.¶

4.6. Object Identifier Assignment and Reconstruction

The publisher numbers the objects of each group in source order, as [I-D.ietf-moq-msf] Section 6.2 requires. The first object of the group has Object ID 0. It is the AL-FEC signaling object when the group carries one (Section 8), and the FT=0 object otherwise. Each later object, in whichever subgroup, has the Object ID of the object before it plus one. An Object ID therefore identifies one object of its group, as [I-D.ietf-moq-transport] Section 2.1 requires, and the Subgroup ID still identifies the data unit (Section 4.3). The packetizer emits each data unit's packets contiguously (Section 5.2.2), and Subgroup IDs follow source order (Section 5.3.2), so ascending Object ID order within a group is also ascending Subgroup ID order. A FETCH or fill fetch stream, which sends a group's objects in Object ID order ([I-D.ietf-moq-transport] Section 3.2.1), therefore delivers them in the order that Section 4.3 requires.¶

MoQ Transport carries Object IDs as deltas on the wire ([I-D.ietf-moq-transport] Sections 11.3.1 and 11.4.1.1), and the objects of every subgroup other than Subgroup 0 have Object IDs greater than zero. A receiver MUST reconstruct each object's absolute Object ID from that encoding. It MUST NOT assume that a subgroup's first Object ID is zero, that successive objects differ by a fixed step, or that an absolute Object ID is carried explicitly.¶

Object IDs identify preserved source objects within a group; they do not replace the MMTP packet sequence, FI countdown, or active-data-unit association required by Sections 5.2 and 5.3.¶

5.1. Authored Movie-Fragment Timing

For timed media, receivers MUST derive sample timing and layout only from the authored ISOBMFF metadata carried by FT=0 and FT=1:¶

1. FT=0 supplies the one media track's mdhd timescale and trex defaults. It MUST contain a usable mvex/trex for that track.¶
2. FT=1 begins with a byte-for-byte copy of the authored moof and carries a byte-for-byte copy of the original mdat prefix through the byte before the first media sample. This includes the original mdat header and any auxiliary sample information. The mfhd.sequence_number identifies the movie fragment referenced by subsequent timed-MFU DU headers.¶
3. For the traf whose tfhd.track_ID matches the independent media track's tkhd.track_ID, tfdt supplies the first decode time. Each sample duration and size is resolved using the ISOBMFF precedence rules across trun, tfhd, and trex; composition time is decode time plus the authored trun composition-time offset. Signed offsets MUST remain signed. Sample byte positions are resolved from the authored base-data-offset and trun.data_offset rules, not from a fixed mdat-header guess.¶
4. Each FT=2 timed DU identifies one sample -- or one producer-authored subsample of it -- by (MPU_sequence_number, movie_fragment_sequence_number, sample_number, offset). A whole-sample data unit carries offset zero; a subsample data unit (Section 5.2.1) carries the authored byte position of its first media byte within the sample. Section 5.3.3 defines sample completion.¶

A receiver MUST reject a missing or ambiguous media track, timescale, movie-fragment sequence, tfdt, or sample identity. It MUST also reject any sample duration, sample size, byte position, or composition offset that remains unresolved or invalid after applying all authored trun, tfhd, trex, and implicit ISOBMFF rules. An absent per-sample trun composition-time-offset resolves to zero, and an absent trun.data_offset is not by itself an error when the ISOBMFF base-data-offset and run-continuation rules resolve the byte position. The receiver MUST reject overlapping sample byte ranges, undeclared bytes, duplicate samples, duplicate or overlapping subsample data units (Section 5.2.1), and FT=2 media for which the governing FT=0 or FT=1 has not been accepted. It MUST NOT synthesize timing from the MMTP Timestamp, packet or MPU counters, MoQ Object IDs, arrival time, catalog cadence, codec frame-rate guesses, or previously observed samples.¶

The MMTP Timestamp is a send time, not media time (Section 3.1). Any absolute MMT presentation anchor and edit-list offset are applied as specified by PI/MPU presentation signalling and ISOBMFF; a receiver without the required anchor MUST reject that timeline rather than silently omit the authored adjustment.¶

5.2. Fragmentation and Strict Active-DU Reassembly

A single MFU can exceed the path MTU, but the ISO MPU-mode payload header does not permit an unbounded number of fragments. The 8-bit fragment_counter is the number of MMTP payloads containing fragments of the same data unit that succeed the current payload; it is not a modulo sequence number. A complete FI=0 data unit MUST carry zero. For a fragmented data unit carried in N payloads, where 2 <= N <= 256, the FI=1 payload MUST carry N - 1, every succeeding payload MUST decrement the value by one, and the FI=3 payload MUST carry zero. The counter MUST NOT wrap or repeat within a data unit.¶

The mfu mapping defined here carries exactly one data unit per MMTP payload, so aggregation_flag MUST be zero. The upstream MMTP packetizer produces conformant data units, and an input MMTP flow used by this mapping MUST already satisfy the 256-payload bound for every data unit. In this profile an FT=2 timed data unit carries one whole sample, or exactly one producer-authored subsample of it (Section 5.2.1). A sample whose media exceeds one data unit's capacity MUST be partitioned into subsample data units by the origin packetizer per Section 5.2.1, before this mapping applies -- never by a relay and never by this mapping, which does not repacketize or subdivide an input data unit. Such a sample MUST NOT be carried by wrapping or extending the counter, silently truncated, or split into a second MPU, and an access unit MUST NOT be split across multiple MPUs ([ISO.23008-1] Section 6.4). A publisher MUST reject a purported data unit that exceeds the bound, has an invalid countdown, or uses aggregation. It MUST NOT wrap or extend the counter, divide one data unit's overflow between subgroups, or synthesize MoQ Object IDs to make a non-conformant MMTP data unit appear valid.¶

Each MMTP packet maps to exactly one MoQ object, and the publisher MUST NOT reassemble MFU fragments:¶

1. The publisher MUST publish each MMTP packet of a data unit as a separate object within that data unit's subgroup (Section 4.3), preserving the MMTP packet header and the MPU-mode payload header. Those headers carry the Fragmentation Indicator and MPU sequence number. Object IDs identify the preserved source packets within the group (Section 4.6) but are not MFU identities or media timestamps.¶
2. The publisher MUST NOT reassemble or reorder fragments based on the Fragmentation Indicator. It routes each packet to (track, group, subgroup) by packet_id, MPU boundary, data-unit type, and the strict active-DU state of Section 5.3: a change of MPU sequence number starts the next group (Section 4.3), and each distinct data unit within the group maps to its own subgroup as defined in Section 5.3.¶

3. The receiver MUST reassemble each data unit from the objects of its subgroup before media processing. After restoring serial packet order (Section 5.3.3), it applies the FI/counter state machine of Section 5.3:¶

   • A single object with FI=0 is a complete, unfragmented data unit; for FT=2 that data unit is one MFU.¶
   • FT=2 objects with FI=1 (first), FI=2 (zero or more middle), and FI=3 (last) reassemble, in that restored MMTP order, into one MFU by concatenating each fragment's media bytes, delimited as defined below.¶
   • The receiver MUST validate the fragment_counter countdown with the state machine of Section 5.3.2. Any missing, repeated, wrapped, or non-decrementing count invalidates the entire MFU.¶
   • The reassembled MFU's RAP flag is taken from its FI=1 (or FI=0) object.¶

The bytes concatenated are each fragment's media (data unit) bytes only -- not everything after the MMTP packet header. Every fragment begins with a 12-or-more-byte MMTP packet header. The receiver MUST parse the C and X flags, packet-counter presence, and header-extension length to locate the following 8-byte MPU-mode payload header; it MUST NOT assume a fixed offset of 12 bytes. The MPU-mode payload header contains, by [ISO.23008-1] Clause 9.3.2.3 name with this document's alias in parentheses, length (payload_length, 16), FT (fragment_type, 4), T (timed_flag, 1), f_i (fragmentation_indicator, 2), aggregation_flag (1), fragment_counter (8), and MPU_sequence_number (32); both headers are stripped from every fragment.¶

The 16-bit payload_length field MUST be encoded and interpreted as the number of bytes following that field within the MPU payload, as defined by [ISO.23008-1]. It therefore includes the remaining six bytes of the 8-byte MPU-mode payload header. For FT=2 packets, the declared lengths are:¶

   FI=0 or FI=1: payload_length = 6 + DU_header_octets + media_octets
   FI=2 or FI=3: payload_length = 6 + media_octets

DU_header_octets is 14 for timed media and 4 for non-timed media, and the right-hand side MUST NOT exceed the 16-bit maximum of 65535. A trailing Source FEC Payload ID is outside the declared MPU payload and MUST NOT be counted. A publisher MUST NOT encode a media-only or DU-plus-media length convention. A receiver MUST require the declared MPU payload to end exactly at the protected MPU boundary before the Source FEC Payload ID, when present. It MUST reject a declaration that is too short, cannot contain the required header bytes, extends beyond the available MPU payload bytes, leaves undeclared bytes before the outer trailer, or consumes that trailer.¶

The DU header ([ISO.23008-1] Figures 12 and 13: 14 bytes for timed media -- movie_fragment_sequence_number (32), sample_number (32), offset (32), priority (8), dep_counter (8) -- or 4 bytes for non-timed media) follows the payload header on an FI=0 object and on the FI=1 first fragment; it is likewise stripped rather than concatenated into the media stream. When the packet's FEC Type is 1, the trailing 4-byte Source FEC Payload ID ([MOQ-FEC] Section 8.5) is excluded as well. 4. FT=0 and FT=1 MUST each be unaggregated, complete FI=0 data units with fragment_counter zero. Their payload length is six plus the metadata octets; they have no DU header. Fragmented or empty metadata is rejected by this profile. 5. The receiver MUST bound both in-flight data-unit memory and pending FT=1 sample records. At either bound it MUST reclaim a slot by evicting the least recently admitted incomplete record (an open data unit or a parked continuation run) and admit the new one; it rejects only when no such record exists. A record that has already completed is never a candidate. An incomplete data unit is discarded on declared discontinuity or unrecoverable loss and is never emitted.¶

For very large frames where FEC cannot recover the loss, receivers SHOULD support resolution-tier fallback (subscribe to a lower-resolution track of the switching set and upscale) rather than stalling.¶

5.3. Active Data-Unit Association and Subgroup Derivation

Object IDs are transport coordinates, not an MMTP continuation key. A fragment recovered below the MoQ object layer has no Object ID, and Object IDs from two delivery paths are not comparable. The MMTP DU header is also not a per-fragment coordinate: this profile carries it only in the FI=0 or FI=1 payload ([ISO.23008-1] Clause 9.3.2 does not specify whether FI=2 and FI=3 fragments repeat it). FI=2 and FI=3 continuations carry media bytes but no movie-fragment sequence, sample number, or sample offset.¶

Consequently a receiver MUST associate continuations through the ordered, bounded active-data-unit state defined here. It MUST NOT use an MMTP Timestamp, MoQ Object ID, signaling identifier, packet arrival time or order, inferred byte offset, recently completed identity, or a (stream, MPU sequence number) pair or fragment counter alone as a fallback association.¶

6.1. Subscriber Join Procedure

A subscriber joins a live mmtp-packaged track as follows:¶

1. Catalog. Subscribe to the catalog track (the track named catalog, Section 12) as [I-D.ietf-moq-msf] Section 5 requires, joining at the start of its current group ([I-D.ietf-moq-transport] Section 3.5), and validate the catalog. Validation includes the per-track REQUIRED fields of Section 12.1. A subscriber MUST NOT issue SUBSCRIBE for a track whose catalog entry fails validation. It also applies the switching-set agreement check of Section 4.4.2 and handles a disagreement as that section specifies.¶

2. Decoder initialization. If the catalog provides initialization data for the track (Section 4.5) and that data validates, initialize the decoder from it immediately. In all cases the subscriber MUST accept the authoritative FT=0 object in Subgroup 0 before admitting this group's FT=1 or FT=2 data units. An AL-FEC signaling object that precedes FT=0 in Subgroup 0 (Section 8) is not decoder initialization and does not satisfy this step.¶

3. Subscribe at a group boundary. Join at the start of the current group, as [I-D.ietf-moq-transport] Section 3.5 describes. Send SUBSCRIBE with a LOCATION_FILTER of type 0x05 (Next Object) and a FILL_PARAMETERS parameter whose LOCATION_FILTER has type 0x01 (Relative Start) and StartGroup = 1 ([I-D.ietf-moq-transport] Sections 3.4, 9.20.9, and 9.20.15). The publisher sends the current group, from its start up to the Largest Object, on a fill fetch stream, and every later object on the subscription, so each object arrives once. The group start carries FT=0 initialization (Subgroup 0), the FT=1 metadata governing the first samples, and the RAP-bearing first FT=2 subgroup (Section 4.3); a subscription that starts mid-group without a fill yields objects that cannot be decoded until the next group. A data unit that was still open at the join arrives partly on the fill fetch stream and partly on its subgroup stream, and the receiver combines the two before reassembly (Section 5.2). If the fill fails or leaves a gap, the subscriber waits for the next group, which the subscription delivers from its start. A subscriber that does not want the current group sends SUBSCRIBE with a LOCATION_FILTER of type 0x01 and StartGroup = 0 instead. A NEW_GROUP_REQUEST ([I-D.ietf-moq-transport] Section 9.20.19) cannot shorten that wait (Section 4.4.1).¶

4. Repair track. If the subscriber wants FEC protection and the catalog signals FEC for the track, it SHOULD subscribe to the repair track (Section 8.2) at the same time as the source track, so that the first FEC block spanning the join point is repairable. Repair-track subscription is selective and optional ([MOQ-FEC] Section 6.2).¶

5. Presentation gate. A subscriber MUST NOT submit media to the decoder until it has (a) accepted the authoritative FT=0 and FT=1 data units and (b) a completely reassembled FT=2 sample whose RAP flag is set (Section 5.2). Objects received before that point are buffered or discarded according to the receiver's reassembly bounds.¶

6. Loss and discontinuity. If a RAP MFU is discarded under unrepairable loss (Section 5.2), the subscriber MUST treat the track as discontinuous and MUST NOT resume presentation before the next completely reassembled RAP MFU (normally the start of the next group). The same holds when the group's FT=0 data unit, or the FT=1 data unit governing its RAP, is lost, since the RAP then cannot be admitted (Section 4.3). On a multicast or AMT leg, loss that spares those three data units does not make the track discontinuous; [MOQ-FEC] Section 11.4 specifies its handling.¶

6.2. Relay Retention for Late Joiners

This section is informative. A relay serves the fill fetch stream of Section 6.1 from its cache, and fetches from upstream the objects it does not hold ([I-D.ietf-moq-transport] Sections 3.2.3 and 3.4). A relay that caches the current group of each track it serves can therefore start a late joiner without an upstream round trip. The join needs no mmtp-specific relay behavior. A fill fetch stream sends a group's objects in Object ID order, which is source order on an mmtp track (Section 4.6), so it delivers Subgroup 0 and each metadata subgroup before the FT=2 subgroups that depend on them, and the relay does not parse MMTP.¶

Retention of groups older than the current group (for example to serve FETCH-based catch-up) is permitted but out of scope for this document.¶

7.1. Interleaving

Interleaving and typical interleave windows (interleaveDepthMs) follow [MOQ-FEC] Section 9. A positive interleaveDepthMs is the elapsed source/repair send-span bound for each actual FEC block; it does not select FEC block boundaries, derive a number of groups per block, or require a fixed relationship between an FEC block and a media Group. Absent and zero values follow [MOQ-FEC] Section 5.1 and do not supply an elapsed-time deadline. A typical window for ARIB STD-B60 content is 2000 ms.¶

7.2. OTI Signaling

MoQ carries no RaptorQ Object Transmission Information (OTI, [RFC6330] Section 3.3) in-session: receivers derive it per block from the catalog fec fields and the block's SSB_length per [MOQ-FEC] Section 4.2. The AL-FEC message of an MMTP session (Section 8.3) carries none either ([MOQ-FEC] Section 7.3).¶

8.1. MMT-Specific FEC Parameters

When used with MMT packaging, the catalog fec fields map as follows:¶

• algorithm: the value whose code point the MMTP AL-FEC message carries in fec_code_id_for_repair_flow (Section 8.3)¶
• blockProfile: "iso-ssbg1-v1" ([MOQ-FEC] Section 5.1), the ISO 23008-1 Annex C block profile, for which an AL-FEC message carries the coding byte 0x14 (Section 8.3); REQUIRED when algorithm is not "none"¶
• sourceSymbols: The largest number of MMTP packets (source symbols) that an FEC block may hold; each block holds SSB_length of them ([MOQ-FEC] Section 7.4). On the MMT path the canonical FEC source symbol is one whole MMTP packet, before its Source FEC Payload ID, framed with its length ([MOQ-FEC] Section 7.3)¶
• interleaveDepthMs: When positive, the elapsed source/repair send span bound of each actual FEC block, as defined by [MOQ-FEC] Section 5.1; that section also defines absent and zero values. It is independent of groupDurationMs and does not imply a block count or block boundary from MoQ Groups. When ingesting broadcast content, use the ISO protection-window signaling or a known source/repair send-span bound. A source-frame count alone does not bound the actual packet send span.¶

See [MOQ-FEC] for the complete catalog field definitions, the algorithm registry, and the OTI derivation.¶

8.2. Repair Tracks

A source track's repair tracks are the track its fec.repairTrack names and the tracks that name it in depends ([MOQ-FEC] Section 5.1.1); [MOQ-FEC] Section 6.1 gives their conventional names. Subscription to them follows [MOQ-FEC] Section 6.2, and their priorities [MOQ-FEC] Section 10.¶

8.3. FEC Signaling for Multicast Delivery

For SSM and Any-Source Multicast (ASM) delivery there is no bidirectional signaling channel. FEC parameters reach multicast receivers via:¶

1. MoQ Catalog Extension (authoritative for MoQ receivers, [MOQ-FEC] Section 5.2): out-of-band delivery in the catalog fec object (see the worked catalog of [MOQ-FEC] Section 5.1.2).¶

2. MMTP AL-FEC Signaling (message_id=0x0203): in-band delivery of the AL-FEC message of [ISO.23008-1] Clause C.6, with Table C.3 as replaced by [ISO.23008-1.AMD1], for ISO/IEC 23008-1 receivers that consume the flow without the catalog, such as native broadcast (ATSC 3.0, ARIB STD-B60) receivers. A publisher that sends this message MUST carry it in an MMTP signaling packet (packet type 0x02) on packet_id 0, the MMTP signaling flow, after the signaling message payload header of [ISO.23008-1] Clause 9.3.4.2 (Section 3.1); on multicast delivery it shares the multicast group of the media it describes, and on MoQ delivery it MAY be carried as an object of an mmtp source track under the rules of Section 8. No track is advertised on packet_id 0 ([MOQ-MULTICAST] Section 4.1), and a receiver does not deliver these packets to a media or repair decoder (Section 3.1; [MOQ-MULTICAST] Section 5)¶

Each FEC source flow has one FEC encoded flow ([ISO.23008-1] Clause C.6.3), so the message describes a source track's flow as one entry of the message's fec_flow_descriptor naming exactly one repair flow, the track's layer-0 repair track ([MOQ-FEC] Section 6.3). For a track whose fec.blockProfile is "iso-ssbg1-v1", that entry carries:¶

• a number_of_assets of 1, the one Asset it lists being the source track's, the Asset whose packet_id is the track's: an FEC source flow of [ISO.23008-1] may carry the packets of several Assets (its Clause C.1), where an FEC instance of [MOQ-FEC] protects one source track (its Section 6.3);¶
• the coding byte 0x14, that is fec_coding_structure 0001 (one-stage), ssbg_mode 01, ffsrpts_flag 0 and fec_payload_id_mode 0 ([MOQ-FEC] Section 7.3);¶
• as its fec_code_id_for_repair_flow, the code point that [ISO.23008-10] Table 1 assigns to the code that the track's fec.algorithm names: 3, the "6330 code" (RaptorQ), for "raptorq", and 1, the Reed-Solomon code, for "reed-solomon";¶
• as its repair_flow_id, the packet_id of the layer-0 repair packets. [ISO.23008-1.AMD1] makes this field 16 bits in the one-stage branch, where the 2023 edition of Table C.3 gives it 8 bits and so cannot name a repair packet_id above 255;¶
• as its length_of_repair_symbol, the track's fec.symbolSize (T), the byte length of every repair symbol and, under ssbg_mode1, of every source symbol ([MOQ-FEC] Sections 5.1, 7.1 and 7.3), and as its num_of_repair_symbol_per_packet 1, the one repair symbol each repair packet carries ([MOQ-FEC] Section 7.1), a field whose semantics [ISO.23008-1] Clause C.6.3 gives for ssbg_mode2 alone;¶
• as its maximum_k_for_repair_flow, the track's fec.sourceSymbols: like that field, it bounds each block's SSB_length and is not the size of any particular block ([MOQ-FEC] Section 7.4); and¶
• as its maximum_p_for_repair_flow, the RSB_length that every repair packet of the track's FEC instance carries: the total repair count over the published layers, which is the track's fec.repairSymbols while layer 0 is the only published layer ([MOQ-FEC] Section 6.3.2). A publisher that appends a layer ([MOQ-FEC] Section 6.3.9) raises that total and sends a new version of the message carrying it only after the last repair packet generated under the previous total, of whichever block: a block's RSB_length is the total in force when its repair symbols were generated ([MOQ-FEC] Section 7.1), so every repair packet sent after the new version carries a value no lower than the field it names. The path keeps no order between the message, on packet_id 0, and the repair flow (Section 5.2.2), so a receiver of both can take a packet generated under the previous total after the new version; the blocks generated under the raised total follow every block generated under the previous one in the serial order of their SS_Start ([MOQ-FEC] Section 7.5), as its Section 6.3.9 requires of the publisher, which the conversion rule of Section 12.2 relies on instead.¶

A publisher MUST NOT describe a repair layer above layer 0, or a keyframe overlay, in the message, whether in that entry or in an entry of its own: the one-stage coding structure names one repair flow per FEC encoded flow, the overlay protects a RAP subset that no packet_id identifies, and only the catalog declares either ([MOQ-FEC] Sections 6.3, 6.4 and 8.5.1).¶

10.1. Clock Reference

ARIB STD-B60 uses the MMTP Timestamp of Section 3.1: the UTC send time of the packet in NTP short format.¶

12.1. Packaging Value and Track Fields

This document defines a single packaging value:¶

packaging: "mmtp"

carried in the per-track packaging field of the catalog ([I-D.ietf-moq-msf] Section 5.2.4). The value extends the allowed packaging values of that specification in the same manner as the cmaf value of [I-D.ietf-moq-cmsf] Section 3.5.1; see Section 14 for the registry request. Object payloads of an mmtp-packaged track are whole MMTP packets per Section 4.2.¶

Per-track catalog fields for mmtp packaging:¶

All other base track fields of [I-D.ietf-moq-msf] Section 5.2 apply unchanged. In particular name and the rendition parameters -- codec ([I-D.ietf-moq-msf] Section 5.2.18; required for media tracks per that section), framerate, width, height, samplerate, channelConfig, bitrate, and lang -- are flat, top-level fields of the track object.¶

mmtpMode selects the object layout and MUST be "mfu". It delivers one subgroup per FT=0, FT=1, or FT=2 data unit as defined in Sections 4.3 and 5. A subscriber MUST reject a track whose mmtpMode is absent or has any other value; the object layout cannot be inferred safely from received objects.¶

Example, with the data value shortened:¶

{
  "version": "draft-01",
  "tracks": [{
    "name": "video",
    "packaging": "mmtp",
    "isLive": true,
    "mmtpMode": "mfu",
    "timescale": 90000,
    "presentationAnchorTicks": 0,
    "groupDurationMs": 1000,
    "codec": "avc1.640028",
    "width": 1920,
    "height": 1080,
    "framerate": 30,
    "bitrate": 6000000,
    "initRef": "video-init"
  }],
  "initDataList": [{
    "id": "video-init",
    "type": "inline",
    "data": "AAAAIGZ0eXBpc29t..."
  }]
}

12.2. MMTP Signaling to MoQ Catalog Conversion

This section is informative: it documents how a converter that ingests an MMTP broadcast service, an ATSC 3.0 MMTP session ([ATSC-A331] Section 8.1.2.1) or an ARIB STD-B60 service, derives a MoQ catalog from the MMT signaling, and imposes no interoperability requirements on MoQ publishers or subscribers. A converter's output catalog is subject to the normative catalog requirements of Section 12.1 like any other catalog. The MP table gives the location of each Asset ([ISO.23008-1] Clause 10.3.9) and the AL-FEC message the FEC parameters of each protected flow ([ISO.23008-1] Annex C.6; Section 8.3 gives the fields a MoQ publisher sets, which a converter reads back).¶

The multicast field in the output uses the multicast endpoint format of [MOQ-MULTICAST] Section 4.1. Conversion rules:¶

• each MMTP session the MP table locates by its source address, destination address and destination port -> one multicast.endpoints[] entry (sourceAddress, groupAddress, port), and the Assets it carries -> that endpoint's tracks[]¶
• each Asset -> a track whose packetId is the Asset's packet_id, unique within the session ([ATSC-A331] Section 8.1.2.1.1) and carried by every packet of the flow, so a converter cannot renumber it. [MOQ-MULTICAST] Section 4.1 requires each packetId value to denote one sub-flow across all endpoints of a sending entity and reserves 0 for the signaling flow, so a converter publishes sessions whose packet_ids collide under different namespaces, and never advertises a track on packet_id 0¶
• the AL-FEC message's entry for a flow -> the track's fec object: algorithm from fec_code_id_for_repair_flow, "reed-solomon" for code point 1 and "raptorq" for 3, symbolSize (T) from length_of_repair_symbol, sourceSymbols (K) from maximum_k_for_repair_flow, repairSymbols (P) from maximum_p_for_repair_flow, and a repair track, named in fec.repairTrack, whose packetId is the packet_id that repair_flow_id names (Section 8.3). The converter accepts an entry whose number_of_assets is 1, whose coding byte is 0x14 and whose fec_code_id_for_repair_flow is 1 or 3: a source flow of several Assets ([ISO.23008-1] Clause C.1) is one block sequence over the packets of several packet_ids, which no FEC instance of [MOQ-FEC] protects (its Section 6.3 protects one source track), a flow under any other coding structure, ssbg_mode, FFSRP_TS or FEC payload ID mode is not one that "iso-ssbg1-v1" describes ([MOQ-FEC] Section 7.3), a session whose message names any other code is outside [MOQ-FEC] until its registry lists that code (its Section 12), and the conversion of such a flow fails. The one repair flow the one-stage entry names is the track's layer 0, and maximum_p_for_repair_flow is its P while layer 0 is the only published layer, as in a one-stage session of [ISO.23008-1], whose one repair flow carries the block's whole repair count. That field bounds the repair count of a block ([ISO.23008-1] Clause C.6.3: the maximum allowed number of repair symbols in a repair symbol block) where "iso-ssbg1-v1" carries P as the RSB_length of every repair packet ([MOQ-FEC] Section 7.1), on which every receiver holding the highest layer the converter lists (below) fails closed when a packet of that layer, where it is above 0, or of a block at or after (in the serial order of [MOQ-FEC] Section 7.5) one of which it has received a repair packet carrying at least the value, carries less than the O_i + P_i its catalog derives for that layer, the field itself (its Section 6.3.9), so the converter, which receives the flow's repair packets before it lists the repair track (below), lists it only once it has received a repair packet of the flow carrying an RSB_length of at least the field of the version it holds, and fails the conversion of a flow whose repair packets carry an RSB_length below that field on a block at or after, in the serial order of their SS_Start ([MOQ-FEC] Section 7.5), one of which it has received a repair packet carrying at least the field: such a flow is not one "iso-ssbg1-v1" describes. A block before that one whose repair packets carry less was generated under the previous total, after whose last repair packet a publisher that appends a layer sends the raised field (Section 8.3) but which the path, keeping no order between the message and the repair flow (Section 5.2.2), can deliver after it; and a flow no block of which carries at least the field is one the converter never lists. Such a packet of an earlier block, below the repairSymbols the catalog gives layer 0 (below) where the layers the converter lists above 0 count less than the appended one, fails a receiver of the catalog closed on nothing: the clause of [MOQ-FEC] Section 6.3.9 for a packet of a layer's own track applies to layers above 0 alone, layer 0's coordinates depending on no count, and its anchored clause, which anchors a held layer on a block of which the receiver has received a repair packet carrying at least that layer's O_i + P_i, for layer 0 its repairSymbols (the field where the converter lists none above 0), treats such a packet as the conforming packet it is, every block generated under a total below a layer's O_i + P_i preceding, in the serial order of its Section 7.5, every block generated under one at or above it (its Section 6.3.9, which has a publisher apply a raised total from a block onward in that order and lower none), on the repair track the converter publishes as on the session's own endpoint, which carries the sender's packets and from which the converter withholds nothing. An RSB_length above the field is the append case of the next sentence. A MoQ publisher that appended a layer ([MOQ-FEC] Section 6.3.9) sends the raised total in that field (Section 8.3) while the named flow carries only the P_0 symbols of each block ([MOQ-FEC] Section 6.3.2), and neither the message nor the MP table describes the layers above, so the converter sets repairSymbols to maximum_p_for_repair_flow less the repairSymbols of every layer above 0 that it lists, and lists a layer it learns from provisioning only where provisioning places it, with every other layer it lists, above every layer it does not list, the topmost layers of the publisher's set: layer 0's repairSymbols is then the publisher's total below the lowest layer it lists above 0 (the whole field where it lists none) and each listed layer's O_i ([MOQ-FEC] Section 6.3.2) is the publisher's, while listing a layer above which lies one the converter does not list would give it an O_i that is not the publisher's, which no check detects, and an O_i + P_i that its own-track packets generated before the append of the layer it does not list fall below (its Section 6.3.9). One that lists none publishes the whole field, which overstates layer 0's count, and the loss tolerance a receiver derives from it, by the layers it does not list. The converter keeps the repairSymbols it first published for a track, and those of every layer it has listed, for as long as it publishes the track: a later version of the message that raises maximum_p_for_repair_flow changes nothing in its catalog by itself, since [MOQ-FEC] Section 6.3.9 forbids changing the repairSymbols of a published layer while any receiver may still be consuming the source track, and says that a receiver reading the smaller bound excludes only symbols of layers it has not joined. A layer above 0 that the converter learns from provisioning after it published the track, one that provisioning places next above the highest layer the converter lists, the publisher having appended it after the converter read the field with no layer the converter has not learned below it, so that its O_i, the total of every layer below it ([MOQ-FEC] Section 6.3.2), is the total the catalog derives for the highest layer listed before it, layer 0's repairSymbols plus those of every layer above 0 listed before it, and the field of the version it holds has risen by at least that layer's repairSymbols, it appends at the next index (its Section 6.3.9): its symbols' RS_IDs run upward from that total, and its O_i + P_i is at most the field, which every block generated under the raised total carries. The field's rise alone places no layer, a field risen by more than a layer's repairSymbols counting a layer the converter has not learned, which can lie below the learned one. A layer that provisioning does not so place, or whose symbols the field the converter first read already counted, it lists only by retiring the source encoding and publishing the source track and its repair tracks as a separate rendition that lists it, since appending it would give it an O_i that is not the publisher's, which no check detects, or an O_i + P_i above the wire RSB_length, on which every receiver joining it fails closed (that section), while lowering layer 0's repairSymbols to fit it is the change that section forbids. A later version that lowers maximum_p_for_repair_flow below the total its catalog derives for the highest layer it lists, layer 0's repairSymbols plus those of every layer above 0 it lists, is a change that section lets no publisher make, on which a receiver holding the highest layer it lists fails closed on the first packet of that layer, where it is above 0, or of a block at or after, in that serial order, one of which it has received a repair packet carrying at least that total, whose RSB_length falls below the O_i + P_i its catalog derives for that layer, which is that total, and one that no such packet reaches, the check anchored on no block it received or, holding that layer alone, reached by no repair packet after the change, learns of the change only at the next catalog refresh (that section), so the converter retires the source encoding and publishes the source track and its repair tracks as a separate rendition carrying the lowered value, as that section has a publisher that must retire a layer do; a repair packet whose RSB_length falls below that total once the track is published, on a block at or after, in that serial order, one of which it has received a repair packet carrying at least that total, is the same violation and has the converter retire the source encoding in the same way, the separate rendition listing the repair track as the first listing did, once a repair packet of the flow received after that one carries at least the field of the version it then holds, as the violating packet, below the field of the version held when it arrived, did not. The conversion of a flow fails where the fec object it would yield fails a catalog rule of [MOQ-FEC] Sections 5.1 and 6.3.4, on which a receiver fails closed: a maximum_p_for_repair_flow of 0 names no repair flow a catalog can publish ([MOQ-FEC] Section 5.1 requires a repairSymbols of at least 1 when a repair track is published), a maximum_k_for_repair_flow of 0 names no block (a sourceSymbols of at least 1), and a length_of_repair_symbol below 14 names a symbol that protects no MMTP packet under the T - 2 construction of [MOQ-FEC] Section 7.3, whose protected packet begins with the 12-octet MMTP packet header of Section 3.1 (a symbolSize of at least 14 under "iso-ssbg1-v1"); an entry that names code point 3 with a length_of_repair_symbol that is not a multiple of 8 names a T no "raptorq" track can carry ([MOQ-FEC] Section 4.2 fixes the Symbol Alignment at 8, which an MMTP session, carrying no OTI, does not impose on its symbol length), one with maximum_k_for_repair_flow above 56403 fails rule 6 of [MOQ-FEC] Section 6.3.4, and one with maximum_k_for_repair_flow plus maximum_p_for_repair_flow above 2^24 names an ESI no instance can produce (rule 5, which bounds K + totalP - 1 by 2^24 - 1, a sum the two 24-bit fields can exceed); and an entry that names code point 1 with maximum_k_for_repair_flow plus maximum_p_for_repair_flow above 255 names a block no "reed-solomon" instance can hold (rule 12, which bounds K plus the repair count of every layer). The conversion also fails for a flow whose repair_flow_id is 0, the signaling flow (Section 3.1), the flow's own packet_id, or the packet_id of another track of the session, a value that [MOQ-MULTICAST] Section 4.1 requires to denote one sub-flow (a repair flow carries a packet_id of its own, [ISO.23008-1] Clause C.6.3), and for the flows of any two entries that name one repair_flow_id or list one Asset: two source tracks naming one repair track, or two fec objects for one track, are shapes no FEC instance of [MOQ-FEC] has, a repair packet belonging to the instance of the track it arrived on (its Section 6.4.1). The message names the repair flow by packet_id without a location, and the MP table does not list it ([MOQ-MULTICAST] Section 5), so the converter lists the repair track in the tracks[] of each endpoint on whose session it receives packets of that packet_id, which is where a receiver without the catalog finds them; a repair-only endpoint ([MOQ-FEC] Section 6.3.6) is one the converter learns from provisioning, not from the signaling¶
• fec.interleaveDepthMs, the ISO protection-window send span from the first source or repair packet to the last: set only when the AL-FEC message's protection_window_time or an independently known source/repair send schedule supplies that span, as a positive integer millisecond upper bound that covers the complete span, never rounded down; when the span is unknown, or the message signals zero (the size-based case), the converter omits it¶
• a live service -> isLive = true ([I-D.ietf-moq-msf] Section 5.2.7) on each media track and on its repair track, which the converter publishes while it ingests the service¶
• the source composition/edit-list origin for each synchronized media track -> presentationAnchorTicks; a converter preserves one common presentation origin across audio and video, and does not emit zero merely because the source offset was unavailable¶
• bitrate ([I-D.ietf-moq-msf] Section 5.2.22) from whatever signaling carries it, or from another source, or the conversion of that track fails¶

Flows sharing one (sourceAddress, groupAddress, port) tuple collapse into a single endpoint whose tracks[] array lists them all. MMT signaling carries no networkSource ([MOQ-MULTICAST] Section 4.2). A converter that adds an AMT network source advertises "driad" discovery only for a source address whose reverse DNS zone carries an AMT relay record, and otherwise names a relay service hostname in relay with "dns" discovery ([MOQ-MULTICAST] Section 4.2.1).¶

timescale, the group-duration field and mmtpMode are required fields (Section 12.1). The converter takes timescale from asset_timescale in the MP table when asset_timescale_flag is 1, and uses 90 000 Hz when that flag is 0, as specified by [ISO.23008-1] Clause 10.3.9.3. For each timed Asset, it obtains the presentation time of each MPU's first AU in presentation order from the PI document when PI is present; ISO/IEC 23008-1 Clause 10.5.2.1 says that the MPU timestamp descriptor is ignored in that case. Otherwise it decodes each descriptor's 64-bit NTP mpu_presentation_time value ([ISO.23008-1] Clause 10.5.2) and does not treat the encoded NTP integer as a media tick count. It converts those presentation instants through the selected asset/media clock, retaining the authored media timing when NTP fractional quantization does not land on an integer media tick. That instant is not ticks (Section 4.4.1) when the MPU has leading pictures: ticks is that instant plus the difference between the authored composition times (Section 5.1) of the MPU's first AU in decode order and its earliest-presented AU, converted to the selected timescale as Section 4.4.1 requires.¶

The converter derives the group duration from the authored MPU/media cadence and validates it against those ticks values. It may emit groupDurationMs only when the conversion to the selected timescale is an exact positive integer tick count; when the cadence is exact only in ticks it emits groupDurationTicks. The fixed-cadence profile cannot represent a source whose MPU cadence is not one constant positive duration, so conversion fails rather than rounding or inventing a cadence. It sets mmtpMode itself. The AL-FEC message does not name fec.blockProfile, which is required for a track whose fec.algorithm is not "none" ([MOQ-FEC] Section 5.1); for such a track the converter sets it to "iso-ssbg1-v1", the profile whose entry carries the coding byte 0x14 that the converter accepts (Section 8.3; [MOQ-FEC] Section 7.3).¶

13.1. Multicast Security

Multicast-specific security considerations (source authentication, replay protection, AMT relay trust) are defined in [MOQ-MULTICAST] Section 7.¶