Forward Error Correction for Media over QUIC

4.1. FEC Algorithms

FEC algorithm values are registered in the "MoQ FEC Algorithms" registry (Section 15.2); the catalog (Section 5.1) carries the corresponding string identifiers.¶

RaptorQ (0x01): RaptorQ fountain code per [RFC6330]. Can recover from loss of any symbols as long as SSB_length symbols (source or repair), plus a small decoding overhead (Section 6.3.2), are received. It is OPTIONAL (Section 4.3).¶

Reed-Solomon (0x02): The systematic Reed-Solomon erasure code over GF(2^8) of [ISO.23008-10] Clause 6, restated in Section 4.4. It recovers a block from any SSB_length of its distinct source and repair symbols. An FEC instance under it holds at most 255 source and repair symbols per block (Section 4.5). It is the mandatory-to-implement scheme (Section 4.3).¶

Both codes are systematic: the source symbols of a block are among its encoding symbols, so a receiver uses the source symbols it receives as they arrive. The two values correspond to the FEC code points 3 (the "6330 code") and 1 (the RS code) of [ISO.23008-10] Table 1, which an AL-FEC message carries in fec_code_id_for_repair_flow ([MOQ-MMT] Section 8.3).¶

4.2. RaptorQ Object Transmission Information

An RFC 6330 decoder is configured by the Object Transmission Information (OTI): the 8-byte Common FEC OTI (Section 3.3.2 of [RFC6330]) and the 4-byte Scheme-Specific FEC OTI (Section 3.3.3 of [RFC6330]), totaling 12 bytes:¶

RaptorQ OTI {
  Transfer Length (40),
  Reserved (8),
  Symbol Size (16),
  Number of Source Blocks (8),
  Number of Sub-Blocks (16),
  Symbol Alignment (8),
}

This specification does not carry the OTI on the wire. When a track's catalog fec.algorithm is "raptorq", receivers MUST construct the OTI of each FEC block from the catalog fields (Section 5.1) and the block's SSB_length, which every repair packet of the block carries (Section 7.1), under the source symbol construction of the track's block profile (Sections 7.3 and 7.6.1), as follows:¶

• Transfer Length: F = SSB_length x T, where SSB_length is the block's source symbol count (Section 7.1) and T is symbolSize, exact because every source symbol of either block profile is exactly T bytes. It is never computed from the cumulative size of source objects, which a receiver that has lost objects could not know, and never from sourceSymbols, which bounds SSB_length but is not the size of any particular block (Section 7.4). From this F an [RFC6330] decoder derives that document's K as SSB_length, and from K its own K' ([RFC6330] Section 5.3.1).¶
• Symbol Size: T = symbolSize.¶
• Number of Source Blocks: Z = 1. Each FEC block of this specification is decoded as an independent RFC 6330 object containing a single source block. Blocks are identified by the SS_Start of the Repair FEC Payload ID of repair objects (Section 7.1), and source symbols are placed in them by SS_ID (Section 8.3) -- not by the RFC 6330 Z partitioning.¶
• Number of Sub-Blocks: N = 1. Catalog-signaled sessions do not use sub-blocking (Section 7.3).¶
• Symbol Alignment: Al = 8. symbolSize MUST be a multiple of 8.¶

This derivation is normative and complete: a receiver that has a track's catalog fec object requires no additional signaling to configure its decoder (Section 5.2). Its one per-block input, SSB_length, travels in the Repair FEC Payload ID of every repair packet of the block, so a receiver holding any repair symbol of a block holds the block's SSB_length.¶

4.3. Algorithm Requirements

Reed-Solomon is the mandatory-to-implement FEC scheme: an implementation that performs FEC decoding under this specification MUST support "reed-solomon", which Sections 4.4 and 4.5 fully specify. "raptorq" is OPTIONAL.¶

The MMT AL-FEC framework on which the MMTP profile of this document rests ([ISO.23008-1] Annex C) requires no FEC code: it carries whichever code the AL-FEC message names by its [ISO.23008-10] code point, and ATSC 3.0, which applies AL-FEC to an MMTP session through that framework, requires none either ([ATSC-A331] Section 8.1.2.5; Section 12). This document therefore specifies the codes it uses. Reed-Solomon is the mandatory scheme because it is small to implement, recovers a block from exactly SSB_length of its symbols, and is a code of that framework ([ISO.23008-10] code point 1). RaptorQ stays specified, code point 3, for its block size: it serves every block size this document allows. A RaptorQ block holds up to 56403 source symbols (Section 6.3.4, rule 6), while a Reed-Solomon block holds at most 255 source and repair symbols (Section 4.5). At 8 Mb/s with symbols of 1200 bytes, such a block spans at most about 300 ms of media, so the multi-second interleave windows of Section 9 need RaptorQ at that rate. A code of [ISO.23008-10] other than these two is outside this document until the registry below lists it.¶

The algorithm registry (Section 15.2) provides an extension point for additional schemes. A registered value other than "none", "raptorq" and "reed-solomon" needs a specification of its own, giving its symbol construction, parameter derivation and repair object semantics, before it can be used interoperably.¶

A receiver that does not implement a track's signaled fec.algorithm simply forgoes FEC protection for that track: it consumes the source track normally and does not subscribe to the repair track. Repair-track subscription is optional (Section 6.2), so an unrecognized or unimplemented algorithm is not an error. A track under "raptorq" is therefore protected only for the receivers that implement it.¶

4.4. Reed-Solomon Code

The "reed-solomon" algorithm is the systematic Reed-Solomon erasure code over GF(2^8) of [ISO.23008-10] Clause 6, to which that document assigns FEC code point 1 (its Table 1). This section restates the code, because [ISO.23008-10] is not freely available. If this restatement and [ISO.23008-10] Clause 6 differ, [ISO.23008-10] governs. Appendix C gives test vectors.¶

Field. The code works in GF(2^8) defined by the primitive polynomial x^8 + x^4 + x^3 + x^2 + 1 (0x11D), the polynomial that [RFC5510] Section 8.1 gives for m = 8. alpha is a root of that polynomial and is represented by the byte 0x02. A byte with bits b_7 (the most significant) down to b_0 represents the element b_7 alpha^7 + b_6 alpha^6 + ... + b_1 alpha + b_0. Addition is the bitwise exclusive OR of bytes, and multiplication is the product of polynomials modulo 0x11D, so alpha^8 is 0x1D. This document defines the code over GF(2^8) only.¶

Generator matrix. The code is generated by G = [I | A], where I is an identity matrix and A is a Cauchy matrix ([ISO.23008-10] Clause 6.2 writes G = [I; A]). Row i of A belongs to the source symbol at ESI i, and column j to the repair symbol whose RS_ID is j. The entries of A are:¶

A_{i,j} = 1 / (x_i + y_j)
x_i     = alpha^(254 - i)
y_j     = alpha^j

A block that holds SSB_length source symbols and RSB_length repair symbols uses rows 0 to SSB_length - 1 and columns 0 to RSB_length - 1 of A. x_i and y_j differ whenever i + j < 254, so every entry the block uses is defined when SSB_length + RSB_length is at most 255, the bound of [ISO.23008-10] Clause 6.2. An entry depends on i and j alone: not on K, not on SSB_length and not on P.¶

Encoding. Every symbol of a block is T bytes long. Let s_i be the source symbol at ESI i (Section 8.3), for i from 0 to SSB_length - 1. The repair symbol r_j whose RS_ID is j is computed one byte position at a time, as [RFC5510] Section 8.4 applies its code to symbols: for each byte position u from 0 to T - 1,¶

r_j[u] = sum over i < SSB_length of A_{i,j} * s_i[u]

where the sum and the products are computed in GF(2^8). The source symbols themselves are sent unchanged.¶

Short blocks. A block whose SSB_length is less than K uses only the first SSB_length rows of A. Its repair symbols equal those of a block of K source symbols whose symbols at ESIs SSB_length to K - 1 are all zero, because a zero symbol adds nothing to any sum. No zero symbol is sent or counted in SSB_length (Section 7.4).¶

Decoding. Every square submatrix of a Cauchy matrix is invertible ([ISO.23008-10] Clause 6.2), so the code is maximum distance separable: a receiver that holds any SSB_length distinct symbols of a block, source and repair in any mix, recovers every source symbol of the block. Let M be the set of ESIs of the source symbols it lacks, and R a set of |M| RS_IDs of repair symbols that it holds. For each byte position u and each j in R:¶

sum over i in M of A_{i,j} * s_i[u]
    = r_j[u] + sum over i < SSB_length, i not in M,
               of A_{i,j} * s_i[u]

The square matrix of the entries A_{i,j} with i in M and j in R is a submatrix of A and is therefore invertible. The receiver inverts it once per block and applies the result at every byte position. Any decoding method that yields the same source symbols is acceptable.¶

The field is that of [RFC5510], but the generator matrix is not the Vandermonde-derived matrix of [RFC5510] Section 8.2, and this document uses neither the FEC Payload IDs nor the source block partitioning of [RFC5510]. Several systematic Reed-Solomon constructions over GF(2^8) are in use, and they produce different repair symbols from the same source symbols. Appendix C gives test vectors that tell this construction apart from the others.¶

4.5. Reed-Solomon Parameters

As for RaptorQ (Section 4.2), no decoder configuration is carried on the wire, and the code has no OTI to carry. When a track's catalog fec.algorithm is "reed-solomon", receivers MUST configure the decoder of each FEC block from the catalog fields (Section 5.1) and the block's Repair FEC Payload ID (Section 7.1), under the source symbol construction of the track's block profile (Sections 7.3 and 7.6.1), as follows:¶

• Symbol size: T = symbolSize. Every source and repair symbol is exactly T bytes. The RaptorQ rule that T is a multiple of 8 (Section 4.2) does not apply.¶
• Rows: SSB_length, the block's source symbol count. The source symbol whose SS_ID is x is row (x - SS_Start) mod 2^32 of A, which is its ESI (Section 8.3).¶
• Columns: the repair symbol whose RS_ID is j is column j of A. Its ESI, SSB_length + RS_ID (Section 7.2), still identifies it within its block, but the column depends on RS_ID alone.¶
• Column count: RSB_length, the instance's total repair count P (Section 7.1).¶

This derivation is normative and complete: a receiver that has a track's catalog fec object requires no additional signaling to configure its decoder (Section 5.2). As under RaptorQ, its per-block inputs travel in the Repair FEC Payload ID of every repair packet of the block.¶

The catalog keeps every FEC instance under "reed-solomon" within the bound of Section 4.4: K + P is at most 255, where K is the instance's sourceSymbols and P its total repair count over all its repair layers (Section 6.3.4, rule 12). SSB_length + RSB_length is then at most 255 in every block. In addition to the checks of Section 7.4, a receiver MUST discard a repair packet of such a track whose SSB_length + RSB_length exceeds 255, or whose RS_ID is not less than RSB_length, leaving the state of every block unchanged. Neither packet is a symbol of a code that Section 4.4 defines. A repair packet whose RSB_length is less than O_i + P_i for a layer i that the receiver holds, of that layer's own track where i is above 0 or of a block to which the check of Section 6.3.9 applies, is handled by that section, which fails closed, and not by this rule; on any other packet this rule applies to it, one of a block generated before an append, carrying no symbol of layer i, or one of layer 0's track generated under a previous total (Section 6.3.9).¶

Repair layers (Section 6.3) carry disjoint ranges of columns: layer i carries columns O_i to O_i + P_i - 1 (Section 6.3.2). A column depends on its RS_ID alone, so a repair symbol is the same whichever layer carries it and whatever other layers exist, and symbols from any subset of layers combine in one decode. A keyframe overlay (Section 6.4) is a separate FEC instance, with its own rows, numbered from its overlay SS_IDs, its own columns and its own bound: K_overlay + P_overlay is at most 255, whatever the base instance uses.¶

For example, this catalog protects an mmtp track under "reed-solomon":¶

{
  "version": "draft-01",
  "tracks": [
    {
      "name": "video",
      "packaging": "mmtp",
      "isLive": true,
      "mmtpMode": "mfu",
      "timescale": 90000,
      "presentationAnchorTicks": 0,
      "groupDurationMs": 1000,
      "codec": "avc1.64001f",
      "width": 1280,
      "height": 720,
      "framerate": 30,
      "bitrate": 2500000,
      "fec": {
        "algorithm": "reed-solomon",
        "blockProfile": "iso-ssbg1-v1",
        "sourceSymbols": 32,
        "repairSymbols": 8,
        "symbolSize": 1320,
        "interleaveDepthMs": 200,
        "reorderToleranceMs": 40,
        "repairTrack": "video/repair"
      }
    },
    {
      "name": "video/repair",
      "packaging": "fec-repair",
      "isLive": true,
      "depends": ["video"],
      "repairSymbols": 8,
      "priority": 240
    }
  ]
}

K + P is 32 + 8 = 40, within the bound. A full block uses rows 0 to 31 and columns 0 to 7 of A, and its repair packets carry SSB_length 32 and RSB_length 8. A short block of 20 source symbols uses rows 0 to 19 and the same columns, and its repair packets carry SSB_length 20. The repair symbol with RS_ID 3 is column 3 in both blocks, at ESI 35 in the first and ESI 23 in the second. The full block recovers once the receiver holds any 32 of its 40 symbols, and the short block once it holds any 20 of its 28. Rule 12 leaves room for repair layers (Section 6.3.9) of at most 215 more repair symbols in all, since 32 + 8 + 215 = 255, and Section 14.3 recommends far fewer.¶

5.1. Catalog Fields

The catalog (Section 5.2) is an MSF catalog [I-D.ietf-moq-msf], delivered on the track named catalog ([I-D.ietf-moq-msf] Section 5); for mmtp tracks it is extended by the documents of this suite as described in [MOQ-MMT] Section 12. This document adds one track-level field -- the fec object defined below -- and one packaging value (fec-repair, below). The FEC configuration is carried at the track level:¶

{
  "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": 4990000,
      "fec": {
        "algorithm": "raptorq",
        "blockProfile": "iso-ssbg1-v1",
        "sourceSymbols": 625,
        "repairSymbols": 125,
        "symbolSize": 1000,
        "interleaveDepthMs": 1000,
        "reorderToleranceMs": 40,
        "repairTrack": "video/repair"
      }
    },
    {
      "name": "video/repair",
      "packaging": "fec-repair",
      "isLive": true,
      "depends": ["video"],
      "repairSymbols": 125,
      "priority": 240
    }
  ]
}

(Appendix B works this parameter set through in full. Section 7.6.7 shows a loc track under moq-object-v1, and Section 4.5 a track under "reed-solomon".)¶

Field definitions:¶

algorithm (string, REQUIRED if fec present): FEC scheme identifier.¶

• "none": No FEC¶
• "raptorq": RaptorQ per RFC 6330 (OPTIONAL, Section 4.3)¶
• "reed-solomon": Reed-Solomon over GF(2^8) per Section 4.4 (mandatory to implement, Section 4.3)¶

blockProfile (string, REQUIRED when algorithm is not "none"): The block profile of the track's FEC: the rules that fix how source symbols are formed from a source packet or a source object, how many source symbols a block holds, how a block and the source symbols in it are identified, and how those identifiers wrap. It applies to every FEC instance of the source track, its repair layers (Section 6.3) and any keyframe overlay (Section 6.4) included, and a repair track carries no blockProfile of its own (Section 6.3.4, rule 8). A publisher MUST NOT change a published track's blockProfile; a different profile is a different rendition. A fec object whose algorithm is "none" declares no FEC instance and need not carry blockProfile. This document defines two values, which Section 15.4 registers. Each admits only the source track packaging values named with it:¶

• "iso-ssbg1-v1": the ISO/IEC 23008-1 Annex C profile of this document, all of whose rules a receiver applies together. It admits mmtp. A source symbol is the ssbg_mode1 framing of one FEC source packet (Section 7.3). A block holds SSB_length source symbols, with sourceSymbols as the upper bound on SSB_length (Section 7.4). SS_IDs advance by one per FEC source packet, blocks are consecutive, and a source symbol is placed in its block by range membership (Section 8.3). SS_ID arithmetic is modulo 2^32, and a block's repair objects are grouped under its 62-bit extended SS_Start (Section 7.5). An in-band AL-FEC message that describes such a track carries the coding byte 0x14 (Section 7.3).¶

• "moq-object-v1": the object profile of this document (Section 7.6), all of whose rules a receiver applies together. It admits loc and cmaf. The Protected Object Unit of a source object spans s(o) consecutive source symbols (Section 7.6.1). A block holds whole units, SSB_length source symbols in all, with sourceSymbols as the upper bound on SSB_length (Section 7.6.2). SS_IDs advance by s(o) per source object, blocks are consecutive, and a source symbol is placed in its block by range membership (Section 8.3). SS_ID arithmetic and repair Group IDs are those of Section 7.5. A repair object carries no MMTP header (Section 7.6.3). The profile defines no in-band signaling and no keyframe overlay (Section 7.6.6).¶

A receiver MUST NOT apply FEC to a track whose blockProfile is absent, names a profile the receiver does not implement, or names a profile that does not admit the track's packaging. It treats FEC as unavailable for that track, as for an unimplemented algorithm (Section 4.3): it consumes the source track without FEC and does not subscribe to or join the track's repair tracks, and it MUST NOT fail the session, or FEC for any other track, on that account. There is no default profile, and a receiver MUST NOT infer one from the wire, whether from the fields of an in-band AL-FEC message, from the length of the source packets it receives, or from any other observation.¶

sourceSymbols (integer, REQUIRED): K, the largest number of source symbols an FEC block may hold. MUST be >= 1. It is an upper bound, not the size of each block: a block holds SSB_length source symbols, 1 <= SSB_length <= K (Section 7.4). Under iso-ssbg1-v1 it is the value an in-band AL-FEC message carries as maximum_k_for_repair_flow ([ISO.23008-1] Clause C.6.3), which is likewise a maximum. K counts source symbols, not objects: under moq-object-v1 a source object contributes s(o) of them (Section 7.6.1). Under "reed-solomon", K plus the instance's total repair count is at most 255 (Section 6.3.4, rule 12).¶

repairSymbols (integer, REQUIRED): P value - repair symbols per FEC block. MUST be >= 1 when a repair track is published.¶

symbolSize (integer, REQUIRED): T value - bytes per symbol. T MUST be at least 1 under every block profile: a zero-length symbol carries nothing, and the symbol count of Section 7.6.1 divides by T. All symbols in a block have the same size; the byte layout of each source symbol is fixed by the track's blockProfile and is not otherwise carried in the catalog. Under "iso-ssbg1-v1" it is the ssbg_mode1 construction of Section 7.3, under which a source packet of up to T - 2 bytes is protected; under it T MUST be at least 14: a shorter symbol carries no protected packet of the 12-octet MMTP packet header ([MOQ-MMT] Section 3.1). Under "moq-object-v1" it is the construction of Section 7.6.1, under which an object whose Protected Object Unit is at most K x T bytes long is protected. For "raptorq", T is a multiple of 8, the fixed Symbol Alignment of the derived OTI (Section 4.2), so the least T is 8 under "moq-object-v1" and 16 under "iso-ssbg1-v1". For "reed-solomon", no such alignment applies (Section 4.5).¶

interleaveDepthMs (integer, OPTIONAL): When present, its value MUST be a non-negative integer. A value greater than zero is the complete FEC source/repair packet send span in milliseconds. It is the catalog form of protection_window_time in [ISO.23008-1] Sections 11.2 and C.6.3: the actual elapsed time from sending the first source or repair packet of a block to sending the last source or repair packet of that block MUST NOT exceed this value. For a positive value it is a duration, never a count of frames, groups, samples, or symbols, and never a per-symbol interval.¶

This field does not select FEC block boundaries, the number of source symbols in a block, the number of blocks in a MoQ Group, or the number of groups a block spans. Those are determined by the consecutive source SS_ID values and the (SS_Start, SSB_length) carried by the block's repair packets (Sections 7.4 and 8.3). A block MAY contain part of a Group, one Group, or several Groups, and a Group MAY contain more than one block.¶

Thus interleaveDepthMs and groupDurationMs are not inputs to block assignment; Section 8.3 specifies the source-symbol range and repair packet fields that assign a source symbol to a block.¶

When present with a value greater than zero, a publisher chooses this value to cover the actual source/repair send span of every block. An absent field supplies no catalog-signaled span. A value of zero has the ISO meaning of using protection_window_size instead of a time window [ISO.23008-1] Clause C.6.3 under iso-ssbg1-v1; this catalog profile carries no packet-count window. Under moq-object-v1, which has no in-band signaling (Section 5.2), a value of zero is equivalent to an absent field. A catalog-only receiver therefore MUST NOT treat zero as a zero-duration span or use it to derive a block count, and has no elapsed-time FEC deadline from this field. If an applicable ISO packet-count window is accepted in-band, it governs separate count-based processing; it does not supply a millisecond deadline, and the receiver MUST NOT assume a media cadence to convert it. Without an elapsed-time deadline, open-block state is bounded only by the local policy of Section 9, and on a multicast or AMT leg the receiver performs no block classification or unicast repair (Section 11.4) and keeps its repair-layer selection fixed (Section 6.3.6).¶

reorderToleranceMs (number, OPTIONAL): A receiver-local allowance for packet reordering, network jitter, and local processing variance, in milliseconds. When present, the value MUST be finite and MUST be greater than or equal to zero; fractional values are permitted. An explicit value of zero means that no additional allowance is required. An omitted field means that the publisher did not signal an allowance; receivers MUST preserve that distinction from an explicit zero.¶

For a receiver that uses a positive interleaveDepthMs, the FEC block deadline is the receiver-local timestamp of the first accepted packet plus the complete block span. When reorderToleranceMs is present, its catalog allowance is then added:¶

base_deadline = firstAcceptedAtMs + interleaveDepthMs
deadline = base_deadline + reorderToleranceMs  // when present

The catalog allowance is added exactly once when present. Its absence is not equivalent to an explicitly signaled zero; a receiver that applies an explicit local policy MUST keep that policy separate from the catalog value. When interleaveDepthMs is absent or zero, this formula supplies no elapsed-time FEC deadline; an applicable ISO packet-count window, if accepted in-band, remains separate count-based processing and is not converted to milliseconds. A receiver whose FEC deadline API requires a signaled allowance MUST reject or disable FEC for a track that omits reorderToleranceMs.¶

repairTrack (string, REQUIRED): The Track Name of the layer-0 repair track, which is in the source track's Track Namespace (Section 6.1).¶

Repair tracks themselves are identified in the catalog by the packaging value "fec-repair": a track with "packaging": "fec-repair" carries repair objects (Section 7) for the source track whose fec.repairTrack field names it, and carries no directly renderable media. The value extends the allowed packaging values of [I-D.ietf-moq-msf] Section 5.2.4 in the same manner as the cmaf value of [I-D.ietf-moq-cmsf]; see Section 15.3. Receivers that do not implement this specification do not recognize the value and ignore such tracks.¶

enhancementRepair: Not defined. Repair layers and keyframe overlays are declared on their own repair-track entries (Section 5.1.1), and a catalog carrying this member is rejected under the exceptions there.¶

{
  "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": 4990000,
      "fec": {
        "algorithm": "raptorq",
        "blockProfile": "iso-ssbg1-v1",
        "sourceSymbols": 64,
        "repairSymbols": 8,
        "symbolSize": 1200,
        "interleaveDepthMs": 200,
        "repairTrack": "video/repair"
      }
    },
    {
      "name": "video/repair",
      "packaging": "fec-repair",
      "isLive": true,
      "depends": ["video"],
      "repairLayer": 0,
      "repairSymbols": 8,
      "priority": 240
    },
    {
      "name": "video/repair/1",
      "packaging": "fec-repair",
      "isLive": true,
      "depends": ["video"],
      "repairLayer": 1,
      "repairSymbols": 16,
      "priority": 244
    },
    {
      "name": "video/repair/2",
      "packaging": "fec-repair",
      "isLive": true,
      "depends": ["video"],
      "repairLayer": 2,
      "repairSymbols": 32,
      "priority": 248
    },
    {
      "name": "video/repair/kf",
      "packaging": "fec-repair",
      "isLive": true,
      "depends": ["video"],
      "scope": "keyframe",
      "sourceSymbols": 256,
      "repairSymbols": 32,
      "priority": 242
    }
  ]
}

5.2. Signaling Model

The catalog fec object (Section 5.1) is the authoritative FEC signaling for MoQ receivers, that is for every receiver that obtains the track's catalog entry. Such a receiver has everything needed to discover and subscribe to the repair track (Section 6) and to configure its decoder from the derived parameters (Sections 4.2 and 4.5); no in-session signaling is required.¶

A packaging profile MAY also define in-band FEC signaling carried with the media, which serves a receiver that consumes a flow without the catalog. For the mmtp packaging this is the AL-FEC message of [ISO.23008-1] Clause C.6 ([MOQ-MMT] Sections 8 and 8.3). The loc and cmaf packagings define none, so for a track under moq-object-v1 the catalog is the only FEC signaling. In-band FEC signaling MUST NOT signal FEC parameters that contradict the track's catalog fec object. Where the two disagree the catalog governs for a MoQ receiver, and a MoQ receiver MUST NOT require in-band signaling in order to configure its decoder.¶

The catalog's authority holds uniformly across a MoQ receiver's delivery paths, its multicast and AMT legs included. MoQ control messages cannot reach multicast or sessionless receivers at all (Section 11), so no control-message mechanism could serve as the common signaling path; the catalog can, because it is delivered as track data or out of band.¶

5.3. FEC Source Info Object Property

A publisher that carries FEC source symbols as MoQ objects MUST tag each object that carries one or more source symbols with a FEC Source Info Object Property, whose type is the odd value 0x11 (Section 15.1). Under moq-object-v1 that is every source object (Section 7.6.2).¶

0x11 is the value this document requests, and the registration policy for the range it lies in is not reachable by an individual draft (Section 15.1). Until that request is resolved, 0x11 is to be read as provisional. If it is not obtainable, Section 15.1 names an odd value in the range 0x80 to 0x37FF as the fallback. That value can take a 2-byte Delta Type ([I-D.ietf-moq-transport] Section 8.3), so adopting it can change the length of an object's Properties on the wire and not only the constant in this paragraph.¶

[I-D.ietf-moq-transport] calls these Object Properties; drafts before draft-17 called them object extension headers, and the two terms name the same wire construct. It encodes a Property as a key-value pair whose type parity selects the value encoding: an even type carries a single variable-length integer, an odd type carries a length-prefixed sequence of bytes. FEC Source Info is byte-valued, so its type is odd, and a receiver or relay that knows nothing of this document still steps over the Property correctly by its length prefix. A relay that does not implement this document forwards the Property unmodified and caches it with the object, as [I-D.ietf-moq-transport] Section 8.4 requires of any Property that a relay does not support.¶

Deployed implementations have used the even value 0x10 for this purpose. That value is not available: [I-D.ietf-moq-transport] already lists 0x10 as the TIMESTAMP Object Property of draft-ietf-moq-loc, in the same Property Type space and at the same Object scope. A 0x10-tagged FEC object is therefore not merely unparseable under the parity rule; it is a semantic collision with an unrelated Property. A receiver that implements TIMESTAMP parses the FEC Source Info value as a variable-length integer, yields a garbage timestamp, and then reads the next Property type out of the middle of the FEC Source Info bytes. The key-value sequence may be desynchronized from that point on. Depending on the bytes, the parse ends in a session closure ([I-D.ietf-moq-transport] Section 8.3), in a malformed track ([I-D.ietf-moq-transport] Sections 10.7 and 12.1), or in silently wrong Property values. A Delta Type read out of the FEC Source Info bytes that overflows 2^64-1, or a Length that exceeds 2^16-1, is a PROTOCOL_VIOLATION; a type that is understood but whose value does not match its serialization is a KEY_VALUE_FORMATTING_ERROR. This is why implementations that use 0x10 must special-case the type ahead of the parity rule to interoperate at all. An implementation of this document MUST NOT send 0x10. The defence is necessarily publisher-side: a receiver cannot detect a 0x10-tagged FEC object as such, because by construction it is indistinguishable from a well-formed TIMESTAMP. A receiver cannot reject a 0x10 Property and carry on either, because by the time it has mis-parsed the value the sequence may already be desynchronized.¶

The Property value is:¶

FEC Source Info {
  SS_ID (32),
}

SS_ID is an unsigned integer in network byte order. Under iso-ssbg1-v1 it is the sequence number of the source symbol the object carries (Section 2), the same value and the same definition that the Source FEC Payload ID trailer of a FEC source packet carries on the MMTP path (Section 8.5). This Property is that trailer's MoQ-layer carrier: one identifier, one definition, whichever path the symbol travels. Under moq-object-v1 it is the SS_ID of the first of the s(o) source symbols that the object's Protected Object Unit occupies (Section 7.6.2), and the Property is the only carrier of that value: the profile has no trailer.¶

Where the packaging also delivers the trailer, both carry the same value and a publisher MUST make them identical. On the mmtp packaging of [MOQ-MMT] that is every source object, because the object payload is the whole FEC source packet, trailer included. The Property is wanted there as well: it places the symbol at the MoQ layer, reachable by a relay and by a receiver that does not parse MMTP, whereas the trailer is the field the FEC encoder emitted and the one Section 8.3 locates the symbol by. Where the two disagree the trailer prevails (Section 8.5). A packet the decoder recovers carries neither (Section 7.3): the Property is not recovered with the object, and the trailer is appended after FEC encoding, so a receiver that recovers a packet determines its SS_ID from the block coordinate that recovered it, within that FEC instance's SS_ID space (Section 6.4.1); an overlay coordinate does not yield a base SS_ID (Section 7.3). Under moq-object-v1 a Property carried inside Immutable Properties is part of the Protected Object Unit and is recovered with the object, but a receiver still takes a recovered object's SS_ID from the block coordinate at which it found the unit, and checks the Property against it (Section 7.6.4).¶

Where a keyframe overlay applies (Section 6.4), an object carrying a Random Access Point fragment is a source symbol of two FEC instances, whose SS_ID spaces are disjoint (Section 6.4.1), so "the source symbol the object carries" names two SS_IDs rather than one. This Property carries the base instance's SS_ID -- the value the Source FEC Payload ID trailer carries on the MMTP path (Section 8.5.1) -- and a publisher MUST NOT place an overlay SS_ID in it. No second Property conveys the overlay SS_ID: it travels in the 0x8B01 MMTP header extension, which lies inside the MMTP packet header and is therefore part of the protected packet of both instances (Section 8.5.1), so it rides inside the object's payload on this path as on any other. A receiver takes an overlay SS_ID from that extension and from nothing else, and in particular MUST NOT infer one from this Property (Section 8.5.1).¶

A receiver places the symbol in a block by SS_ID (Section 8.3) and learns the block's extent from the (SS_Start, SSB_length) of a repair object (Section 7.1), exactly as on the MMTP path. The Property carries no block coordinate, and a receiver MUST NOT infer one from it: the constraints of Section 7.4 on delimiting a block apply unchanged to a MoQ receiver, so it MUST NOT infer a block boundary, or SSB_length, from a gap in SS_IDs, from a group or MPU boundary -- which for a MoQ receiver includes a Group boundary -- from elapsed time, or from sourceSymbols. Until it has accepted a repair object of the block it holds the symbol without placing it, as Section 8.3 describes.¶

FEC Source Info is single-valued. An object carries at most one FEC Source Info Property, counting its mutable Properties and its Immutable Properties together ([I-D.ietf-moq-transport] Section 10.7). A receiver treats an object that carries more than one as an object that carries none (below).¶

An object that carries a source symbol but no FEC Source Info Property violates the publisher requirement that opens this section. A receiver that does not parse the FEC source packet has no SS_ID for it -- at the MoQ layer the Property is the only carrier -- so it MUST NOT feed such an object to the base decoder and MUST NOT count it in K or in any base block, and MAY still deliver it as media. Where the packaging delivers the trailer, a receiver that parses the packet MAY take the SS_ID from there instead (Section 8.3). An overlay SS_ID is unaffected either way: it travels in the 0x8B01 MMTP header extension (Section 8.5.1), which this Property does not carry, and Section 8.5.1 alone governs when the overlay decoder may be fed.¶

The value is exactly 4 bytes. A value of any other length does not match the serialization defined for this type, so a receiver that implements this document MUST close the session with KEY_VALUE_FORMATTING_ERROR, as [I-D.ietf-moq-transport] requires of any Property whose type is understood and whose value does not match.¶

SS_ID is a fixed 32-bit field rather than a variable-length integer for two reasons. First, [I-D.ietf-moq-transport] does not require its variable-length integers to be encoded in the minimum number of bytes, so one numeric value has several valid encodings that differ in length; a varint field inside the Property value would therefore vary the Property's own length without varying its meaning. Second, the encoding is a property of the session: [I-D.ietf-moq-transport] replaced it at draft-17 (transport issue 1016) with a leading-1-bits scheme that is not the QUIC variable-length integer encoding of earlier drafts and does not decode the same bytes to the same values, so a varint field following the session encoding would decode differently on two drafts. A fixed width removes both. A publisher and a receiver that negotiated different session versions, and a relay that re-encodes between them, decode this field identically.¶

This Property carries no object length. A receiver that recovers an object by FEC decoding does not recover its mutable Properties, and under iso-ssbg1-v1 it recovers no Properties at all, so a length carried here could be absent in exactly the case a recovered length is wanted. The recoverable length is inside the source symbols themselves, and is recovered with them: the Length field of Section 7.3, or the Immutable Properties Length and Payload Length of the Protected Object Unit (Section 7.6.1). Under both source symbol constructions the padding that completes a symbol is applied by the encoder and decoder and is not transmitted, so there is no transmitted padding for a receiver to strip.¶

6.1. Track Naming

A repair track MUST be in the Track Namespace of the source track it repairs. The fec.repairTrack and depends fields carry only a Track Name ([I-D.ietf-moq-transport] Section 2.4.1), and a receiver resolves each in that namespace, as [I-D.ietf-moq-msf] Section 5.2.14 does for depends.¶

By convention, the layer-0 repair track's Track Name is the source track's Track Name followed by the seven bytes "/repair":¶

The name is a convention and not a resolution mechanism: a receiver resolves every repair track from fec.repairTrack, depends, repairLayer and scope (Section 5.1.1), so the name serves only human readers, in logs and configuration. Enhancement layers (Section 6.3) and a keyframe overlay (Section 6.4) have no conventional name. A receiver MUST NOT infer that a track is a repair track, which source it repairs, or which layer it is, by parsing a track name or a name suffix, and a publisher MUST NOT rely on a receiver doing so. Names such as "video/repair/1" appear in the examples of this document for readability only.¶

6.2. Subscription Model

Subscribers SHOULD subscribe to the source track first, then subscribe to the repair track if:¶

1. The track's catalog entry signals FEC (a fec object naming a repairTrack, Section 5.1), AND¶
2. The subscriber desires FEC protection¶

Repair-track subscription is selective and per-need: a subscriber chooses whether to consume repair data based on its own path conditions, and MAY start or stop its repair-track subscription at any time during the session -- for example, subscribing only after observing loss, or not subscribing at all on a reliable path.¶

Publishers and relays MUST NOT require subscription to repair tracks and MUST NOT condition delivery of a source track on a repair-track subscription. Repair tracks are optional; subscribers MAY choose to rely solely on QUIC retransmission or to accept unrecovered loss.¶

6.3. Layered Repair Tracks

A source track MAY be protected by more than one repair track. Each such track is a repair layer: an independently subscribable set of repair symbols for the same source blocks. Layer 0 is the repair track named by repairTrack, carrying the source's repairSymbols symbols per block. Layers 1..n are the tracks that name this source in depends and carry a repairLayer (Section 5.1.1), one track per layer index.¶

Under iso-ssbg1-v1, layered repair is an extension of [ISO.23008-1] that an ISO AL-FEC message cannot express: each FEC source flow has one FEC encoded flow, whose one-stage coding structure carries a single repair_flow_id ([ISO.23008-1] Clause C.6.3), so only layer 0 maps to an ISO repair flow. An in-band AL-FEC message names layer 0 and no other layer ([MOQ-MMT] Section 8.3). A repair layer is also unrelated to the layers of ISO layer-aware FEC (LA-FEC, Clause C.2.3).¶

Layering separates the two costs of FEC: the repair count P buys tolerance to random loss at a cost in bandwidth, and the interleave window buys tolerance to burst loss at a cost in recovery latency (Section 9). Layers let a receiver on a lossier path add repair without changing the source encoding. A source track names only layer 0; each further layer declares itself on its own tracks entry, so the layer set is validated as a whole (Section 6.3.4) and changed only as Section 6.3.9 allows. An entity that republishes a subset of a catalog MUST NOT list a fec-repair track whose source track it omits (Section 6.3.4, rule 9).¶

O_i   = sum(P_j for j < i)
RS_ID = O_i + j, for the j-th symbol of layer i
ESI   = SSB_length + RS_ID

{
  "multicast": {
    "endpoints": [
      {
        "sourceAddress": "198.51.100.100",
        "groupAddress": "232.1.1.50",
        "port": 5000,
        "tracks": [
          { "name": "video",          "packetId": 1 },
          { "name": "video/repair",   "packetId": 2 }
        ]
      },
      {
        "sourceAddress": "198.51.100.100",
        "groupAddress": "232.1.1.51",
        "port": 5000,
        "tracks": [
          { "name": "video/repair/1", "packetId": 3 },
          { "name": "video/repair/2", "packetId": 4 }
        ]
      }
    ]
  }
}

6.4. Keyframe Overlay

A source track MAY additionally be protected by a keyframe overlay: a second, independent FEC instance whose source symbols are only the fragments of Random Access Points of that source track. The overlay is defined only for a source track under iso-ssbg1-v1, because its membership and its overlay SS_ID rely on the MMTP RAP_flag and header extension (Sections 6.4.2 and 8.5.1).¶

Losing part of a Random Access Point makes every dependent frame undecodable until the next one; the overlay protects RAP fragments across a block of its own, which can be wider than the base window, without changing the base instance's latency.¶

7.1. Repair Object Header

Under iso-ssbg1-v1, each object on a repair track is one complete MMTP repair packet (packet type 0x03, FEC Type 2) carrying exactly one repair symbol. Its layout is the ISO 23008-1 AL-FEC repair packet form -- the MMTP packet header followed by the 13-byte Repair FEC Payload ID and the repair symbol data ([ISO.23008-1] Sections C.4.3 and C.5.3; ssbg_mode1, one-stage FEC with N = 1, and ffsrpts_flag = 0, so no FFSRP_TS, Section C.5.1) -- so the same repair packet is valid on MoQ, multicast UDP, and native broadcast paths without translation, and matches the repair-object depiction of [MOQ-MMT] Section 7. The layout below reproduces [ISO.23008-1] Section C.5.3 for convenience. Under moq-object-v1 a repair object is the Repair FEC Payload ID and the repair symbol alone, with no MMTP header (Section 7.6.3); every field below except the MMTP Packet Header applies under both profiles:¶

Repair Object {
  MMTP Packet Header (96),      # packet type 0x03, FEC Type 2
  Repair FEC Payload ID {
    SS_Start (32),
    RSB_length (24),
    RS_ID (24),
    SSB_length (24),
  },
  Repair Symbol Data (..),      # exactly one symbol, T bytes
}

MMTP Packet Header: The standard 12-byte MMTP packet header ([MOQ-MMT] Section 3.1) with packet type 0x03 (repair) and FEC Type 2; its packet_id routes the repair flow. Like every packet of its MMTP packet flow, source and signaling packets included, a repair packet has the packet counter flag C = 0 ([MOQ-MMT] Section 3.1; [ISO.23008-1] Clause 9.2.3). A repair packet MUST NOT carry a header extension (X = 0). Because C = 0 and X = 0, the Repair FEC Payload ID always begins at byte offset 12.¶

SS_Start (32 bits): The SS_ID of the first source symbol of the protected source block ([ISO.23008-1] Section C.5.3). The blocks of an FEC instance are consecutive: the block after this one starts at SS_Start + SSB_length, modulo 2^32 (Section 7.4), so this block is the SS_ID range [SS_Start, SS_Start + SSB_length) and is identified by its SS_Start. Extended to 62 bits, SS_Start is also the MoQ Group ID of the block's repair objects (Section 7.5). Every field below is that of the packet's FEC instance (Section 6.4.1).¶

RSB_length (24 bits): The number of repair symbols generated for the block: the instance's total repair count P when the block's repair symbols are generated, identical on every repair packet of the block. A layer does not carry its own P_i. The value rises when a layer is appended, from a block onward in the serial order of Section 7.5 (Section 6.3.9).¶

RS_ID (24 bits): The zero-based index of this repair symbol among the block's P repair symbols. The Encoding Symbol ID is derived as ESI = SSB_length + RS_ID (Section 7.2): under raptorq it is the RFC 6330 Encoding Symbol ID, and under reed-solomon the code takes the symbol's column of A from RS_ID alone (Section 4.5). Layer i of the base instance carries RS_ID in [O_i, O_i + P_i) (Section 6.3.2).¶

Every repair symbol of a block, on whichever layer it travels, is a symbol of the one code over that block: the symbol at RS_ID r is the repair symbol that the instance's algorithm defines for r (Section 7.2). The encoder generates the instance's total repair count for each source block and assigns the disjoint RS_ID ranges to the layer tracks according to O_i. It MUST NOT encode a layer as if it were the block's only repair, for example by generating the first P_i repair symbols of the block and labeling them from O_i: those are not the block's symbols at the RS_IDs they carry, so a receiver holding more than one layer could not combine them, which is the property Section 6.3.2 depends on.¶

SSB_length (24 bits): The number of source symbols in the protected source block ([ISO.23008-1] Section C.5.3), from 1 to K, where K is the instance's sourceSymbols (Section 5.1); it is K for a full block. It is authoritative for the block: its repair ESIs start at SSB_length (Section 7.2). Under raptorq the block is a RaptorQ source block of SSB_length source symbols, whose decoder is configured with F = SSB_length x T (Section 4.2), and under reed-solomon it is the number of rows of A that the block uses (Section 4.5). A value below K marks a short source block, to which this document's framing adds no padding symbols (Section 7.4). A publisher MUST NOT send 0 or a value above K; a receiver discards a repair packet carrying either (Section 7.4).¶

Repair Symbol Data: Exactly one repair symbol of Symbol Size (T) bytes, generated per Section 7.2. Carrying one symbol per object aligns the loss unit with the FEC symbol (Section 11.3) and requires no symbol-count field.¶

7.2. Repair Symbols

For RaptorQ, repair symbols are generated per [RFC6330] Section 5.3. The source symbols of a block occupy ESIs 0 to SSB_length - 1 in SS_ID order, and the Encoding Symbol ID (ESI) of a repair symbol starts at SSB_length, the block's K in the notation of [RFC6330] ([RFC6330] Section 5.3.1): ESI = SSB_length + RS_ID, both fields taken from the Repair FEC Payload ID (Section 7.1). The Internal Symbol IDs of [RFC6330], which start the repair symbols at that document's K', are internal to its encoder and decoder and never appear on the wire.¶

For Reed-Solomon, repair symbols are generated per Section 4.4. Source and repair symbols carry the same ESIs as under RaptorQ, so ESI = SSB_length + RS_ID still identifies a repair symbol within its block, but the code takes the symbol's column of A from its RS_ID alone (Section 4.5).¶

Repair symbol generation for other registered algorithms (Section 4.3) is not specified by this document.¶

7.3. Sub-Blocks and ssbg_mode

Per ISO 23008-1 [ISO.23008-1] Section C.3.3 (signalled per C.6.3, Table C.5), the FEC block structure is described by the source symbol block generation (SSBG) mode (ssbg_mode). The iso-ssbg1-v1 block profile (Section 5.1) uses ssbg_mode1, with the one-stage FEC coding structure and FEC payload ID mode 0 ([ISO.23008-1] Clause C.1). This subsection specifies the source symbols of iso-ssbg1-v1; Section 7.6 specifies those of moq-object-v1.¶

ssbg_mode1: One MMTP source packet = one source symbol, which records the packet's length. Each MoQ object or multicast UDP datagram carries exactly one FEC symbol. Repair symbols are exactly T bytes on the wire; a SOURCE packet MAY be shorter than T on the wire -- the length field and the zero padding that complete its T-byte source symbol are applied by the encoder and decoder as part of the source symbol construction below and are NOT transmitted. This is the natural model for MMTP because packets are sized to fit in UDP datagrams and no fragmentation or reassembly is needed at the FEC layer. Every source symbol is exactly T bytes, so a block of SSB_length source symbols is exactly SSB_length x T bytes -- the property the derived Transfer Length of Section 4.2 relies on. This is ssbg_mode1 of [ISO.23008-1], not ssbg_mode0, which carries no length and requires every packet of the flow to be exactly one symbol long.¶

Source symbol construction: The protected packet of an FEC source packet is the complete MMTP packet -- the MMTP packet header, including any header extension, followed by the MMTP payload -- before its 4-byte Source FEC Payload ID is appended ([ISO.23008-1] Section C.4.2; Section 8.5). Its T-byte source symbol is ([ISO.23008-1] Section C.3.3):¶

Source Symbol {
  Length (16),                  # protected packet length, octets
  Protected Packet (..),        # Length octets
  Padding (..),                 # zero octets, up to T in total
}

The Length field is in network byte order and every Padding octet is zero, so the largest protected packet a symbol can carry is T - 2 octets. A publisher MUST size every FEC source packet so that its protected packet does not exceed T - 2 octets. A receiver that observes a source packet whose protected packet exceeds T - 2 octets MUST NOT feed it to the decoder -- a truncated symbol would corrupt recovery for the entire block -- but MAY still deliver the packet as media. On a RAP packet under a keyframe overlay (Section 6.4), the base and the overlay instance form the symbol from the same protected packet, so the two protect one identical T-byte symbol.¶

Recovery yields the block's SSB_length source symbols. From each, the receiver takes the Length octets that follow the Length field as the recovered protected packet, and delivers that packet to the MMTP parser. A receiver MUST NOT deliver a recovered symbol whose Length is less than 12, the size in bytes of the MMTP packet header ([MOQ-MMT] Section 3.1), or points past the end of the symbol, or whose Padding octets are not all zero: each means that the symbol is not the one the publisher encoded.¶

A recovered packet carries no Source FEC Payload ID, of either instance: the trailer is appended after FEC encoding and is not part of the protected packet. A receiver MUST NOT re-append a trailer before delivering the recovered packet to the MMTP parser, and MUST NOT expect the recovered bytes to end in a block coordinate. This holds identically for a symbol recovered by a keyframe overlay, which the receiver delivers as media on the strength of the overlay recovery alone. The 0x8B01 header extension of a RAP packet under an overlay (Section 8.5.1) is part of the protected packet, by contrast, and is recovered with it.¶

The packet's base SS_ID was in the trailer, and this document defines no mapping from an overlay coordinate to a base one: a receiver MUST NOT place an overlay-recovered symbol into a base source block unless it has determined that packet's base SS_ID independently. Absent that, an overlay recovery is usable as media but MUST NOT be counted toward base block recovery, and in particular MUST NOT be treated as reducing the number of erasures the base decoder still has to solve. The other direction needs no such determination, because a RAP packet recovered by the base instance still carries its overlay SS_ID (Section 8.5.1).¶

In-band signaling: An AL-FEC message ([MOQ-MMT] Section 8.3) that describes a track under iso-ssbg1-v1 carries the coding byte 0x14: fec_coding_structure 0001 (one-stage), ssbg_mode 01, ffsrpts_flag 0 (no FFSRP_TS) and fec_payload_id_mode 0 (a Source FEC Payload ID is appended to every FEC source packet), in that bit order, per Table C.3 of [ISO.23008-1] as replaced by [ISO.23008-1.AMD1]. A message carrying any other value for such a track contradicts the catalog (Section 5.2).¶

Sub-blocks: When a source block is too large to decode in the decoder's working memory, RFC 6330 permits dividing each block into N sub-blocks (the Number of Sub-Blocks field of the OTI). The derived OTI of Section 4.2 fixes N = 1, so catalog-signaled sessions do not use sub-blocks; the AL-FEC message of [ISO.23008-1] carries no OTI, and the split source blocks of its Clause C.2.2 are the two-stage coding structure, which this document does not use. A publisher using MMTP packaging under iso-ssbg1-v1 therefore uses ssbg_mode1 without sub-blocks, and never ssbg_mode2.¶

7.4. Short Source Blocks

A publisher MUST close a source block when it has assigned K source symbols to it. Under moq-object-v1 a block holds whole objects, so the publisher also closes it before an object that does not fit (Section 7.6.2). It MAY close a source block earlier, for example at an access-unit, media-unit, or MoQ Group boundary, or to keep the actual source/repair send span within a positive interleaveDepthMs when that field is present (Section 5.1). Such a block is a short source block, and it is a block with a smaller source symbol count: every block holds SSB_length source symbols, 1 <= SSB_length <= K ([ISO.23008-1] Section C.5.3), and K -- the catalog sourceSymbols, carried in band as maximum_k_for_repair_flow under iso-ssbg1-v1 -- is an upper bound on SSB_length, not the size of any particular block. A short block differs from a full one only in SSB_length:¶

1. The publisher encodes the block as a block of its SSB_length source symbols, at ESIs 0 to SSB_length - 1 in SS_ID order: under raptorq a RaptorQ source block with F = SSB_length x T (Section 4.2), and under reed-solomon the first SSB_length rows of A (Section 4.4). It MUST carry that count in the SSB_length field of every repair packet of the block, on every repair track of the instance. This document's framing adds no padding symbols to the block: none is transmitted, and none is counted in SSB_length or F. The padding of the block to K' symbols in the notation of [RFC6330] ([RFC6330] Section 5.3.1) is part of RaptorQ encoding and decoding, performed inside the encoder and the decoder.¶

2. The next block starts at the SS_ID that follows the block's last source symbol: its SS_Start is SS_Start + SSB_length, modulo 2^32. No SS_ID is skipped, so every SS_ID belongs to exactly one block.¶

3. The block's repair ESIs start at SSB_length: ESI = SSB_length + RS_ID (Section 7.2).¶

4. The block is complete, and needs no repair, once the receiver holds all SSB_length of its source symbols. It is recoverable once the source and repair symbols the receiver holds together number at least SSB_length, plus the decoding overhead of Section 6.3.2, which is zero under reed-solomon.¶

5. Recovery yields the SSB_length source symbols, SSB_length x T bytes, each consumed per the track's block profile (Sections 7.3 and 7.6.4).¶

Source packets and source objects carry only SS_ID, so the (SS_Start, SSB_length) of a repair packet is the only wire signal of a block's extent. Until a receiver has accepted a repair packet of a block it knows neither: it holds the source packets or objects of that block without placing them in any block (Section 8.3), and a run of SS_IDs that it does not hold is a run of lost source packets or objects of one or more blocks it cannot yet delimit. It MUST NOT infer a block boundary, or SSB_length, from a gap in SS_IDs, from a group or MPU boundary, from elapsed time, or from sourceSymbols. A block all of whose repair packets are lost therefore remains undelimited until a repair packet of the block arrives, including one obtained by unicast repair (Section 11.4), which conveys (SS_Start, SSB_length) in the same way. When the receiver accepts a repair packet of a block that starts after the end of the blocks it has delimited, the SS_IDs between the two belong to one or more blocks of which it holds no repair packet.¶

A receiver MUST fail closed on inconsistent block signaling. It MUST discard a repair packet whose SSB_length is 0 or exceeds K. It MUST discard a repair packet whose SSB_length differs from the value it has already accepted for the block with the same SS_Start, and one whose range [SS_Start, SS_Start + SSB_length) overlaps a different block that it has already accepted, in each case leaving the state of every block unchanged. Under reed-solomon it also discards a repair packet that fails the checks of Section 4.5.¶

Within a consumer that the bc-provenance profile of [MOQ-MULTICAST] Section 7.2 governs for its blocks, one protected under a flow whose endpoint lists its source track (step 2 of its Section 7.2.7; a consumer protected under no such flow, as one a repair-only endpoint feeds while the receiver takes the source track over MoQ unicast alone, is for this paragraph, Section 9 and Section 11.4 a consumer outside that profile, while the scoping of the check of Section 6.3.9 to admitted packets reaches it where it is protected under any flow of the profile, as it reaches every consumer so protected), a block that only symbols of an unlisted track have delimited (a track that no endpoint of a flow the consumer is protected under lists, as that step defines it: one no multicast endpoint the receiver holds lists, holding being joined to its group, reading its manifest track or receiving the broadcast that carries the flow, or one a held endpoint lists while the consumer is not yet protected under its flow; Section 6.3.6) is provisional: it yields to a repair packet the profile has admitted whose (SS_Start, SSB_length) conflicts with it, as that step specifies, and the rules of the previous paragraph then apply among admitted packets. A provisional block is held for decoding only: it has no ts and no FEC deadline (Section 9), and the SS_IDs in its range that the receiver lacks belong, for Section 11.4, to blocks the receiver holds no repair packet of, as if the block were not delimited; such a symbol reveals no run of lost SS_IDs, which a packet the profile admits above them alone reveals.¶

7.5. SS_ID Wrap and Repair Group IDs

SS_ID and SS_Start are 32-bit values that start from an arbitrary value and wrap to 0 after their maximum ([ISO.23008-1] Section C.5.2). Every comparison, distance and range test on them in this document, block membership (Section 8.3) included, uses serial number arithmetic [RFC1982] with SERIAL_BITS = 32. A block can span the wrap: a block with SS_Start 2^32 - 3 and SSB_length 4 holds the SS_IDs 2^32 - 3, 2^32 - 2, 2^32 - 1 and 0, and the next block starts at SS_ID 1.¶

The groups of a track are ordered by Group ID [I-D.ietf-moq-transport], so the repair objects of a block are grouped not under its 32-bit SS_Start, which wraps, but under its 62-bit extended SS_Start:¶

ext(SS_Start) = (wrap_epoch << 32) | SS_Start

wrap_epoch, from 0 to 2^30 - 1, counts the times that SS_Start has wrapped in the FEC instance before this block: it is 0 for the first block of the FEC instance's source encoding, and increases by one at each block whose SS_Start is numerically below its predecessor's. Equivalently, the ext(SS_Start) of a block is that of its predecessor plus the predecessor's SSB_length. On every repair track of the instance, the repair objects of a block form the MoQ Group whose Group ID is the block's ext(SS_Start) (Section 6.3.2). Repair Group IDs are therefore sparse, one per block at the block's first SS_ID, and strictly increasing.¶

MoQ Transport Group IDs range up to 2^64 - 1 ([I-D.ietf-moq-transport] Section 8.1). This document deliberately uses only [0, 2^62), the Group ID range of the MoQ Transport versions before draft-17, whose variable-length integers were those of QUIC (Section 5.3), so that a repair Group ID is representable in the Group ID encoding of every MoQ Transport version. The bound is not reached in practice: at one million source symbols per second, an FEC instance takes more than 100,000 years to use 2^62 SS_IDs.¶

Sparse Group IDs depart from the recommendation of [I-D.ietf-moq-msf] Section 6.1 that each subsequent Group ID of a track increase by 1. The departure is deliberate: a Group ID that names its block's first SS_ID is what lets a receiver that has lost source packets request the block's repair by Group (below) before it knows the block partition. Within one source encoding the Group IDs still increase monotonically, as that section requires. A publisher MAY carry the PRIOR_GROUP_ID_GAP Object Property ([I-D.ietf-moq-transport] Section 10.8) on the repair objects of a block, set to the SSB_length of the preceding block of the instance minus 1. Relays and receivers that do not parse repair objects can then tell the Group IDs that will never exist from groups that have not arrived.¶

That section also requires a track's Group IDs to keep increasing across a publisher restart. A publisher that keeps its FEC state across a restart, for example after a loss of connectivity, continues the source encoding, with the SS_ID sequence and wrap_epoch of each FEC instance, so its repair Group IDs keep increasing. A publisher that starts a new source encoding of a track, including after a restart that loses its FEC state, retires the previous encoding and publishes a separate rendition, as Section 6.3.9 requires for retiring a layer. It MUST publish the source track and every repair track of its FEC instances under Full Track Names that it has not used before in the scope ([I-D.ietf-moq-transport] Section 2.5), and MUST NOT resume a previously used repair Track Name with wrap_epoch reset to 0. A resumed name would reissue Group IDs below 2^32. Repair objects of the new encoding could then take the Locations of repair objects already published, which [I-D.ietf-moq-transport] Section 2.1 does not allow, and a receiver could feed a cached repair object of the old encoding to the decoder of a block of the new one.¶

A repair object received over MoQ thus carries its block's start twice: in the SS_Start of its Repair FEC Payload ID and in its Group ID. The SS_Start is authoritative. A receiver MUST discard a repair object whose Group ID modulo 2^32 differs from its SS_Start and, once it has established the wrap epoch, one whose Group ID differs from ext(SS_Start) or whose SS_Start it cannot extend (below), in each case leaving the state of every block unchanged. The Group ID of a discarded repair object is not a reference value r.¶

A receiver establishes the wrap epoch of an FEC instance in one of the following ways, and MUST NOT assume a wrap epoch that it has not established in one of them:¶

1. From the Group ID of a repair object of the instance that it has received over MoQ and not discarded (above). That Group ID is the reference value r. The publisher assigns it and MoQ delivers it unaltered, so it stands on the same footing as the Largest Object of way 2: the modulo 2^32 test above screens out an object to discard, and does not verify the epoch.¶

2. From the Largest Object ([I-D.ietf-moq-transport] Section 3.1.4) that a TRACK_STATUS request for a repair track of the instance reports ([I-D.ietf-moq-transport] Section 9.13). The publisher answers TRACK_STATUS with a REQUEST_OK, which that document calls TRACK_STATUS_OK, carrying the parameters that it would set in a SUBSCRIBE_OK, among them the LARGEST_OBJECT parameter ([I-D.ietf-moq-transport] Section 9.20.17). The receiver reads the Group of the Location that LARGEST_OBJECT carries, whichever name the reply bears, and that Group is the reference value r. A reply without LARGEST_OBJECT reports a repair track on which no object has been published, and establishes no epoch.¶

3. As epoch 0, when the receiver has observed the instance from its first block, whose wrap_epoch is 0 (above). The reference value r is then that block's SS_Start.¶

A reference value r is an extended SS_Start, and the epoch is r shifted right by 32 bits. The receiver relates its own SS_IDs to it with serial arithmetic: it extends a later 32-bit SS_Start or SS_ID x relative to an extended value r that it already holds -- its reference value, or a value it extended before -- to the 62-bit value congruent to x modulo 2^32 that is nearest r in serial order: r advanced by the serial distance from the low 32 bits of r to x when x follows them, r moved back by the serial distance from x to them when x precedes them, and r itself when the two are equal. A receiver MUST NOT extend an x that lies exactly 2^31 from the low 32 bits of r, a pair that [RFC1982] leaves unordered, or one whose extension falls outside [0, 2^62).¶

Serial arithmetic cannot detect an x that lies more than 2^31 SS_IDs from r: it extends such an x into the wrong epoch without error. A receiver therefore extends values relative to an r only while it can bound the number of SS_IDs between them below 2^31, and MUST re-establish the wrap epoch, in one of the ways above, after any gap that it cannot so bound, such as one that spans a rejoin of a multicast group or a reconnection of its MoQ session.¶

A receiver that has lost the source symbol with SS_ID x, and holds no repair packet of the block that contains x, requests that block's repair by a FETCH [I-D.ietf-moq-transport] of the absolute, inclusive Group range¶

[ max(ext(S_prev) + 1, ext(x) - (K - 1)), ext(x) ]

on each repair track it requests from, where:¶

• K is the instance's sourceSymbols (Section 5.1), the largest SSB_length that a block can have (Section 7.4), so the block that contains x starts at most K - 1 SS_IDs before x;¶
• S_prev is the SS_Start of the last block that the receiver has delimited that ends before x. Within a consumer that the bc-provenance profile of [MOQ-MULTICAST] Section 7.2 governs for its blocks (Section 7.4), only a block that a repair packet the profile has admitted delimits counts here: a provisional block, one that only symbols of an unlisted track (Section 7.4) have delimited, is no such block, as its (SS_Start, SSB_length) is unverified and the block that contains x may start within its range. When the receiver has delimited no such block, the first term is absent and the range is [ max(ext(x) - (K - 1), 0), ext(x) ];¶
• ext(x) is x extended relative to ext(S_prev) when S_prev exists, and otherwise relative to the reference value r of the receiver's wrap epoch.¶

Repair Group IDs sit at block starts, so the range returns the repair of every block that starts within it, up to and including the block that contains x, and the last Group it returns is that block. The range is never empty: it always contains ext(x). A receiver that has not established the wrap epoch, or that may not extend x, has no range to request until it establishes one. A receiver that holds a repair packet of the block requests the one Group ext(SS_Start) instead.¶

Each such FETCH carries a LOCATION_FILTER parameter ([I-D.ietf-moq-transport] Section 9.20.9). For the range [lo, hi] above, it has type 0x03 (Absolute Start, Group End), StartGroup lo, StartObject 0 and EndGroupDelta hi - lo. For the one Group ext(SS_Start), it has type 0x03 with StartGroup ext(SS_Start), StartObject 0 and EndGroupDelta 0, or, when it requests only some of the Group's objects (Section 11.4.2), type 0x04 (Absolute Range) with StartGroup ext(SS_Start), StartObject the first and EndObject the last Object ID that it requests (an inclusive range, [I-D.ietf-moq-transport] Section 3.3.1), and EndGroupDelta 0.¶

Either form is answered only by a relay that caches the repair objects it receives, datagram-delivered ones included, and serves them by FETCH. At the time of writing not every relay does: some decline a FETCH of objects delivered as datagrams, and some serve no FETCH at all. A block's repair objects share one Group (above), so a hop that carries no Object IDs for datagram-delivered objects delivers only the first repair object of each Group, one repair symbol per block, however many the publisher sent. A publisher whose receivers sit behind such a hop can send repair objects on streams, which carry every object's Object ID.¶

The 32-bit wrap of SS_ID and SS_Start is that of [ISO.23008-1]. The extended SS_Start, and its use as a MoQ Group ID, are defined by this document, outside [ISO.23008-1].¶

7.6. Object Block Profile

The moq-object-v1 block profile (Section 5.1) protects source tracks whose packaging is loc [I-D.ietf-moq-loc] or cmaf [I-D.ietf-moq-cmsf]. Its unit of protection is a whole MoQ object, not an MMTP packet. Each source object becomes one Protected Object Unit, which occupies one or more consecutive source symbols. The construction follows the application data unit framing of [RFC6681] Section 5, with fields sized for MoQ objects.¶

This section defines what differs from iso-ssbg1-v1: how source symbols are formed from objects, how SS_IDs are assigned to them, how blocks are delimited around them, the form of a repair object, and how a receiver rebuilds objects from recovered symbols. The rest applies unchanged: the catalog fields (Section 5.1), the FEC Source Info Property (Section 5.3), repair layers (Section 6.3), the Repair FEC Payload ID (Section 7.1), repair symbol generation (Section 7.2), short blocks (Section 7.4), SS_ID wrap, repair Group IDs and repair FETCH (Section 7.5), and source symbol location and deduplication (Section 8.3). The profile fixes only the source symbols and their identifiers, so it does not depend on fec.algorithm: the algorithm encodes a block of this profile as it encodes any other block of SSB_length T-byte source symbols.¶

Protected Object Unit {
  Group ID (64),
  Object ID (64),
  Immutable Properties Length (16),
  Immutable Properties (..),
  Payload Length (32),
  Payload (..),
}

s(o) = ceil(len(o) / T)

SS_ID(o') = (SS_ID(o) + s(o)) mod 2^32

Repair Object {
  Repair FEC Payload ID {
    SS_Start (32),
    RSB_length (24),
    RS_ID (24),
    SSB_length (24),
  },
  Repair Symbol Data (..),      # exactly one symbol, T bytes
}

{
  "version": "draft-01",
  "tracks": [
    {
      "name": "video",
      "packaging": "loc",
      "isLive": true,
      "role": "video",
      "codec": "avc3.640028",
      "width": 1920,
      "height": 1080,
      "framerate": 30,
      "bitrate": 2500000,
      "fec": {
        "algorithm": "raptorq",
        "blockProfile": "moq-object-v1",
        "sourceSymbols": 256,
        "repairSymbols": 32,
        "symbolSize": 1200,
        "interleaveDepthMs": 1200,
        "reorderToleranceMs": 40,
        "repairTrack": "video/repair"
      }
    },
    {
      "name": "video/repair",
      "packaging": "fec-repair",
      "isLive": true,
      "depends": ["video"],
      "repairSymbols": 32,
      "priority": 240
    }
  ]
}

8.1. Blocks Within a Group

For example, a source Group can contain two consecutive blocks:¶

Group G:    SS_ID s   .. s+a-1      -> block A, SS_Start = s
            SS_ID s+a .. s+a+b-1    -> block B, SS_Start = s+a
Group G+1:  SS_ID s+a+b ..          -> next block or continuation
...

8.2. Blocks Across Groups

A block can also span a Group boundary:¶

Group G:    SS_ID s   .. s+a-1      -> block A, still open
Group G+1:  SS_ID s+a .. s+L-1     -> block A completes
            SS_ID s+L ..            -> next block
...

A block's repair objects form the repair-track Group whose Group ID is the block's extended SS_Start (Section 7.5), a number space unrelated to the source track's Group IDs. No fixed number of MoQ Groups is required for a block, and no Group boundary can be used to infer SSB_length.¶

8.3. Source Symbol Location

Under iso-ssbg1-v1, every FEC source packet carries a Source FEC Payload ID (Section 8.5), and a receiver that parses the packet takes each source symbol's SS_ID from that field on every path that delivers the packet with its trailer. The SS_ID is also carried alongside the packet where the packaging says so: on the MoQ path every object carrying a source symbol carries it in the FEC Source Info Object Property (Section 5.3), under the same value and the same definition, whether or not that object also delivers the trailer. A receiver that does not parse the FEC source packet -- a relay, or a MoQ receiver with no MMTP parser -- takes the SS_ID from there. The SS_ID advances by one per FEC source packet, modulo 2^32, in the order the publisher emits the packets ([ISO.23008-1] Section C.5.2), and the blocks of an FEC instance are consecutive: each starts at the SS_ID that follows the last source symbol of its predecessor (Section 7.4).¶

Under moq-object-v1, a source object carries no Source FEC Payload ID. On every MoQ path its FEC Source Info Property is the only carrier of its SS_ID, which is the SS_ID of the first source symbol of its Protected Object Unit. The SS_ID advances by s(o) per source object, modulo 2^32, in the order the publisher emits the objects (Section 7.6.2), and blocks are consecutive as under iso-ssbg1-v1.¶

A source symbol is located by range membership. It belongs to the block whose Repair FEC Payload ID (Section 7.1) carries an (SS_Start, SSB_length) such that the symbol's SS_ID lies in [SS_Start, SS_Start + SSB_length) under the serial arithmetic of Section 7.5, and its ESI is its serial distance from SS_Start:¶

ESI = (SS_ID - SS_Start) mod 2^32,   0 <= ESI < SSB_length

Under moq-object-v1, an object o whose first SS_ID has ESI ESI(o) occupies ESIs ESI(o) to ESI(o) + s(o) - 1 of the same block (Section 7.6.2).¶

No source symbol's block can be computed from its SS_ID alone, because blocks differ in length (Section 7.4), and this document defines no block number. A receiver holds a source symbol whose block it has not yet delimited, and places it when it accepts a repair packet of that block. Because SS_IDs are consecutive, a lost source packet or object is visible as missing SS_IDs even before its block is delimited, and a run of SS_IDs that a receiver holds in full needs no repair, whatever its block boundaries.¶

An object that a packaging profile defines as carrying no source symbol -- for example, the in-band AL-FEC signaling object of [MOQ-MMT] Section 8 -- carries no SS_ID, has no ESI, and is not counted in K or in any block. Under moq-object-v1 the objects that carry no source symbol are those whose Object Status is not Normal (Section 7.6.1). This document defines no derivation of a source symbol's position from MoQ Group or Object IDs, under either profile: Object IDs are not positions in the FEC block, and a packaging profile that defines source objects carrying neither a Source FEC Payload ID nor a FEC Source Info Object Property (Section 5.3) needs a block profile of its own (Section 5.1).¶

Under iso-ssbg1-v1, every transport path yields the same SS_ID for the same packet, because each path carries the same MMTP packet, so receivers MAY combine symbols from any transport path toward the same FEC block recovery. Under moq-object-v1, every MoQ path delivers the same object with the same FEC Source Info Property, so receivers MAY likewise combine symbols received over any MoQ path, FETCH included. A loc or cmaf track reaches multicast only through a separate mmtp rendition track ([MOQ-MULTICAST] Section 4.1), whose symbols belong to another FEC instance. Within one FEC instance (Section 6.4.1), a receiver deduplicates source symbols by SS_ID and repair symbols by (SS_Start, RS_ID).¶

8.4. Encoder Constraints

For FEC block alignment and timing to be deterministic, encoders MUST:¶

1. Assign consecutive SS_ID values in the order the publisher emits source packets, or under moq-object-v1 source objects (Section 7.6.2), close a block at K source symbols or earlier as permitted by Section 7.4, and publish the resulting (SS_Start, SSB_length) in every repair packet for that block. A publisher MAY close at an access-unit, media-unit, or Group boundary, but MUST NOT use any boundary or elapsed-time observation as a substitute for that wire signaling.¶

2. For mmtp-packaged tracks, signal the catalog-authored group duration and frame rate in the MoQ catalog: publish a positive duration as groupDurationMs when its integer-millisecond form is exact, or as the exact positive groupDurationTicks; when both are present, groupDurationTicks wins and groupDurationMs is informational. Signal the keyframe cadence in keyframeIntervalMs (or keyframeIntervalTicks), and the frame rate in the framerate field ([MOQ-MMT] Sections 4.4.2, 4.4.3 and 12.1). The ISO 23008-1 AL-FEC message has no field for either value ([ISO.23008-1] Table C.3), so an encoder signals neither there, and a receiver takes neither from it.¶

3. If frame rate or GOP size changes mid-session, update the MoQ catalog and signal a manifest discontinuity for DASH/HLS.¶

4. When interleaveDepthMs is positive, choose it so that the actual elapsed send span from the first source or repair packet of every block to its last does not exceed the signaled value. Under iso-ssbg1-v1, a zero value is usable only with the ISO protection_window_size alternative described in Section 5.1; under moq-object-v1 it is equivalent to an absent field. The value is not derived from a group count, frame count, or per-symbol interval.¶

8.5. Source FEC Payload ID and ATSC 3.0 Signed Region

This subsection and Section 8.5.1 apply under iso-ssbg1-v1. A source object under moq-object-v1 carries no trailer, and its FEC Source Info Property is the only carrier of its SS_ID (Section 7.6.2); Section 14.6 covers how that Property can be authenticated.¶

Exactly one 4-byte Source FEC Payload ID (SS_ID; ffsrpts_flag = 0, so no FFSRP_TS, [ISO.23008-1] Section C.5.1) is appended at the END of each MMTP FEC source packet -- following the MMTP payload, outside the MMTP packet header -- with or without a keyframe overlay (Section 8.5.1). Per [ATSC-A360] Section 5.2.2.5, the ATSC 3.0 signing mechanism, whose certificates the ATSC 3.0 Security Authority (A3SA) administers, covers signaling messages and MA3 messages (packet type 0x2) but excludes asset packets (type 0x00 MPU and type 0x03 repair).¶

Neither [ISO.23008-1] nor [ATSC-A331] carries the SS_ID inside the A3SA signed region. In particular the MMT hint sample does not: neither its ISO syntax ([ISO.23008-1] Clause 8.3.2) nor the ATSC MMTHSampleATSC3 syntax ([ATSC-A331] Section 7.2.4.2.2.3) has a Source FEC Payload ID field, and hint samples travel as MPU-mode data units on the Asset's own packet_id ([ATSC-A331] Section 7.2.4.2.3), that is in asset packets, which A3SA does not sign. This document therefore defines no A3SA-authenticated FEC block assignment: block assignment taken from the trailing Source FEC Payload ID of an A3SA verified packet is unauthenticated. A receiver that requires authenticated FEC block assignment MUST obtain it from an integrity mechanism, other than A3SA signing, whose coverage includes the complete MMTP packet, the trailer included. Version 2 of the bc-provenance profile ([MOQ-MULTICAST] Section 7.2) is such a mechanism: its digest covers the whole UDP payload as transmitted, the Source FEC Payload ID included.¶

For MoQ-only receivers (no A3SA verification), the trailing 4-byte Source FEC Payload ID remains the canonical identifier by which a source packet is placed in its block (Section 8.3). QUIC transport encryption provides equivalent integrity protection.¶

Whatever the receiver's verification posture, the FEC Source Info Object Property of Section 5.3 carries the same value for a receiver that does not parse the packet; where an object delivers both and they disagree, the trailer is the one that is canonical, because it is the field the FEC encoder emitted and the one Section 8.3 locates the symbol by. The Property restates it at the MoQ layer.¶

Source Packet with Overlay {
  MMTP Packet Header {
    ...,                          # X = 1, RAP_flag = 1
    Header Extension {
      Type (16) = 0x8B01,
      Length (16) = 4,
      Overlay SS_ID (32),
    },
  },
  MMTP Payload (..),
  Source FEC Payload ID (32),     # base instance SS_ID
}

11.1. Multicast and AMT Delivery

IP multicast (including Source-Specific Multicast per [RFC4607]) and Automatic Multicast Tunneling (AMT per [RFC7450]) provide efficient one-to-many delivery but are inherently unreliable. FEC enables receivers to recover from packet loss without retransmission:¶

• Native SSM: Receivers join multicast group directly¶
• AMT Tunneling: Receivers without native multicast connect via AMT relays discovered through DRIAD ([RFC8777])¶
• TreeDN ([RFC9706]): native SSM where a network supports multicast, and AMT relays, found through DRIAD, for receivers on unicast-only networks. The publisher generates FEC repair end to end, and the repair is the same on every leg.¶

For an mmtp track, the same MoQ objects (source and repair) can be transmitted over both unicast (QUIC/WebTransport) and multicast (UDP/SSM/AMT) paths. Receivers on reliable unicast paths can skip FEC decoding (Section 3), while receivers on lossy multicast paths use FEC for recovery and apply the receiver repair policy of Section 11.4 to any block that FEC does not recover. A multicast endpoint carries only mmtp tracks, so a loc or cmaf track under moq-object-v1 reaches multicast through an mmtp rendition track, which is a separate FEC instance ([MOQ-MULTICAST] Section 4.1).¶

Publisher
    |
    v
+----------------+
|   MoQ Relay    |
| (Origin/Root)  |
+-------+--------+
        |
   +----+----+--------------------+
   |         |                    |
   v         v                    v
Unicast   SSM Multicast      AMT Tunnel
(QUIC)    (Native)           (Encapsulated)
   |         |                    |
   v         v                    v
[Web     [Native SSM         [Mobile/
Client]   Clients]            Remote]

FEC:      FEC:                FEC:
Optional  Expected            Expected

11.2. Deployment Applicability

The repair overhead this mechanism adds is justified only where the delivery path actually loses packets, and multicast loss characteristics differ by orders of magnitude across access technologies. FEC strength (P and Interleave Depth) is a per-path deployment choice, expressed by which tracks each endpoint carries, not a protocol constant.¶

• Engineered low-loss segments. On managed PON or DOCSIS delivered over a provisioned VLAN, steady-state loss is typically far below 10^-6. Disabling FEC for such a path is signaled by omitting the repair track from the tracks that path's endpoints carry. Adding repair symbols on such a path spends bandwidth to recover losses that do not occur.¶

• FEC-capable broadcast PHYs. ATSC 3.0, DVB-S2/S2X, and 5G broadcast already apply bit-error correction on their own radio link (e.g., LDPC/BCH in ATSC 3.0 and DVB-S2/S2X). Application-layer FEC is NOT a duplicate of that correction: it recovers packet erasures the PHY cannot address -- bursts when reception falls below the PHY threshold (rain fade, mobility, indoor reception), and losses on upstream aggregation or backbone hops that the last-hop PHY never sees. Its value on these paths comes primarily from Interleave Depth spreading a burst across the time domain, not from the code rate. On a one-way broadcast downlink with no return path, application-layer FEC is the only available erasure-recovery mechanism -- which is why ATSC 3.0 (see Section 12) specifies it above the PHY.¶

• Public Internet and AMT tunnels. Loss is real and bursty; a non-trivial repair count with interleaving is RECOMMENDED.¶

A track under moq-object-v1 travels on MoQ paths only, where the erasure unit is a whole object; Section 7.6.6 states where that profile helps.¶

11.3. Interaction with Multicast QUIC

This subsection is informative.¶

[QUIC-MULTICAST] lets a server send QUIC packets on one-way multicast channels. A channel is an alternate path of the unicast QUIC connections whose clients have joined it, and its packets can carry STREAM and DATAGRAM frames. Clients acknowledge channel packets with MC_ACK frames on their unicast connections ([QUIC-MULTICAST] Section 4.4). The server of each connection remains responsible for any necessary frame data that a channel loses, and Section 8 of [QUIC-MULTICAST] recommends that it send FEC repair packets on the channel instead of retransmitting the lost frames. That repair is a transport mechanism below this scheme, and this document does not depend on it. This scheme can serve as the application-layer FEC on such a channel, and suits broadcast-scale audiences better than unicast repair, because per-receiver retransmission does not scale.¶

When this scheme is carried over a multicast QUIC channel:¶

1. Symbol-to-datagram mapping. Each source or repair symbol (one MMTP packet, per [MOQ-MMT]) is best carried in exactly one QUIC DATAGRAM frame. This aligns the erasure unit (a lost QUIC packet) with the FEC symbol, so one lost packet erases exactly one source symbol. STREAM framing defeats symbol-aligned recovery of FEC-protected media on a multicast channel: a lost packet then spans a byte range crossing symbol boundaries.¶

2. Crypto boundary. FEC encoding operates on application-layer objects, ABOVE the QUIC packet protection of [QUIC-MULTICAST]. Unlike bare multicast UDP -- which lacks QUIC's integrity guarantees (see Section 14.4) -- the multicast QUIC binding applies a shared-key AEAD per packet. A sender computes source and repair symbols over the unencrypted objects; the channel then applies its AEAD; a receiver decrypts each surviving packet and recovers erased objects from the decrypted source and repair symbols. A lost packet cannot be decrypted, but its object is reconstructed from other verified symbols, so recovery does not depend on possessing it.¶

3. Integrity of recovered objects. The MC_INTEGRITY frames of [QUIC-MULTICAST] carry hashes of channel packets, and a client decodes a channel packet only after a matching hash has arrived over another integrity-protected path ([QUIC-MULTICAST] Section 4.5). A FEC-reconstructed object was never carried in a single packet and is therefore not individually covered by a packet hash; it inherits trust transitively from the verified surviving symbols used to reconstruct it. Deployments requiring per-object authentication of recovered data can additionally apply a scheme that authenticates every multicast symbol before it enters the decoder, repair symbols included, and, whenever a symbol of its decode was not so authenticated, checks a recovered packet against its own digest or, where it can derive no coordinate to hash with, withholds it (for example version 2 of the manifest-based bc-provenance profile of [MOQ-MULTICAST] Section 7.2, whose receiver procedure is its Section 7.2.7).¶

4. Repair channel versus unicast repair. A publisher using this scheme broadcasts repair symbols on the multicast channel (the repair track) rather than relying on unicast retransmission. Receivers covered by the repair flow have no need to drive unicast repair for losses the FEC recovers, which preserves the O(1) sender cost that motivates broadcast FEC. Unicast repair remains a last resort for losses exceeding the repair budget, and Section 11.4 specifies it.¶

Item 1 assumes iso-ssbg1-v1, under which one MMTP packet is one source symbol. This document defines no multicast carriage for moq-object-v1 (Section 7.6.6).¶

A receiver deduplicates the symbols it receives on a multicast QUIC channel as on any other path, within one FEC instance: source symbols by SS_ID and repair symbols by (SS_Start, RS_ID). Section 8.3 states that requirement; [QUIC-MULTICAST] states none for application symbols. Section 8.3 also permits combining them with symbols received from other paths.¶

11.4. Receiver Repair Policy

This section specifies what a receiver of a multicast or AMT leg does with a base-instance block of a source track that in-band FEC has not recovered by the block's FEC deadline (Section 9). A receiver on a reliable MoQ/QUIC leg relies on transport retransmission (Section 3) and does not need it, and nothing in this section adds a deadline or a timer to such a leg. Multicast and AMT legs carry only mmtp tracks ([MOQ-MULTICAST] Section 5), so this section, which classifies blocks from MMTP fields, concerns tracks under iso-ssbg1-v1.¶

Every step of this section is keyed on a block's FEC deadline, which exists only when the track's catalog carries a positive interleaveDepthMs (Section 9). On a multicast or AMT leg, this section therefore requires a positive interleaveDepthMs: a receiver of a track whose catalog omits it or sets it to zero MUST disable the block classification and unicast repair of this section for that track. The receiver still decodes in-band FEC from the symbols that arrive (Section 8.3), with open-block state bounded by the local policy of Section 9. Media still missing at its presentation time is lost: the loss of a RAP, or of a data unit that governs one, is handled as for an unrecoverable keyframe-bearing block (Section 11.4.2), and other loss is concealed as in Sections 11.4.3 and 11.4.4.¶

Every block receives in-band FEC processing. A receiver MUST attempt to recover every block, whatever its class, from the source and repair symbols received on its multicast and AMT paths, together with any it receives on other paths (Section 8.3), up to the block's FEC deadline. Within a consumer that the bc-provenance profile of [MOQ-MULTICAST] Section 7.2 governs for its blocks (Section 7.4), a symbol of an unlisted track (Section 7.4) enters a decode only as step 2 of [MOQ-MULTICAST] Section 7.2.7 allows, which takes none into a decode of a block that two decodes with such symbols' help have left unrecovered; the attempt continues from the symbols the profile admits. The rest of this section governs only a block that is still unrecovered at that deadline: the receiver does not hold all of its SSB_length source symbols (Section 7.4), and decoding from the symbols it holds has not recovered them. Within such a consumer, a source symbol the profile has not admitted, received or recovered, is not held for this purpose (step 2 of [MOQ-MULTICAST] Section 7.2.7).¶

A run of SS_IDs that the receiver lacks and that lies in no block it has delimited belongs to one or more blocks of which it holds no repair packet (Section 7.4). For this section the receiver treats such a run as one block of the instance (within a consumer that the bc-provenance profile of [MOQ-MULTICAST] Section 7.2 governs for its blocks, Section 7.4, a block only symbols of an unlisted track have delimited being no block the receiver has delimited, and the run one only once a packet the profile has admitted lies above it, step 2 of [MOQ-MULTICAST] Section 7.2.7): Section 11.4.1 classifies it from the source packets the receiver holds on either side of it, and its repair is requested by the Group range of Section 7.5, whose response also delimits the blocks it covers.¶

The policy distinguishes keyframe-bearing blocks, whose loss can stop video decoding until the next Random Access Point (RAP), from other blocks, whose loss damages only frames up to the next RAP. Keyframe-bearing blocks are protected by priority unicast repair and are the only blocks whose loss may stall video. Other blocks are repaired on a best-effort basis and, when repair fails, concealed. Every frame and audio sample a receiver presents MUST be presented at its authored time on the presentation clock shared by its tracks, and a receiver MUST NOT stall video or pause that clock except for a keyframe-bearing block (Section 11.4.2).¶

14.1. FEC Does Not Provide Confidentiality

FEC repair symbols are derived from source data. If source data is encrypted, repair symbols will also be encrypted by virtue of operating on ciphertext. However, FEC itself provides no confidentiality guarantees.¶

14.2. Repair Symbol Manipulation

An attacker who can modify repair symbols could cause receivers to reconstruct incorrect source data. Integrity protection of repair tracks is RECOMMENDED, using the same mechanisms as source tracks (e.g., QUIC packet protection).¶

14.3. Amplification

FEC repair symbols represent additional bandwidth. Publishers MUST NOT generate excessive repair symbols that could be used for bandwidth amplification attacks. The repair overhead (P/K) SHOULD be limited to reasonable values (e.g., <= 50%). The bound applies per FEC instance (Section 6.4.1), and for the base instance to P_0/K, the repair that a receiver gets by default: further repair layers are added on demand (Sections 6.3.5 and 6.3.6), and the next paragraph covers them.¶

Layering changes the shape of the amplification exposure, because the attacker's lever is now which layers a victim can be made to receive rather than only whether it receives repair at all. Each layer i adds P_i x T bytes per source block, so a receiver induced to hold more layers receives proportionally more repair traffic. Deployments SHOULD bound the number of layers any single receiver may hold, and SHOULD apply the same join authorization to repair-layer endpoints as to media endpoints; a repair-only endpoint (Section 6.3.6) is not less sensitive than a media one merely because it carries no media.¶

A receiver MUST NOT be made to receive a repair layer it did not join. A publisher or relay MUST NOT push a repair-layer endpoint to a receiver that has not joined it, and MUST NOT add a layer to an endpoint a receiver has already joined as a way of raising that receiver's protection.¶

14.4. Multicast FEC Security

When FEC is used over multicast (SSM/AMT), which carries only mmtp tracks under iso-ssbg1-v1 ([MOQ-MULTICAST] Section 4.1), additional considerations apply:¶

1. No QUIC Protection: Multicast UDP has neither the confidentiality nor the integrity of QUIC. A publisher that needs confidentiality SHOULD encrypt the media samples, for example with Common Encryption [ISO.23001-7] and its 'cbcs' scheme, as [MOQ-MMT] Section 13 describes for mmtp tracks. All receivers of the flow share the content keys, which reach each receiver over its unicast MoQ session or from a Digital Rights Management (DRM) system. Sample encryption leaves the MMTP headers and the Source FEC Payload ID in the clear and leaves every packet identical across paths, so FEC encodes the ciphertext (Section 14.1) and symbols still combine across paths (Section 8.3). Encrypting each MoQ object payload instead, as MoQ Secure Objects [I-D.ietf-moq-secure-objects] does, would make the MoQ copy of a packet differ from its multicast copy. A keying handshake per receiver, such as DTLS-SRTP, needs a return path and cannot key a one-to-many flow. A key that every receiver holds does not authenticate the publisher; item 3 covers authentication.¶

2. Repair Injection: Attackers could inject malicious repair symbols on multicast networks. Receivers SHOULD verify FEC block consistency by checking that decoded data matches expected patterns (e.g., valid media container structure).¶

3. Source Authentication: SSM limits which sources reach a receiver ([MOQ-MULTICAST] Section 7.1), and version 2 of the bc-provenance profile ([MOQ-MULTICAST] Section 7.2) authenticates the datagrams themselves, repair symbols included, with a digest that covers the whole UDP payload, the Source FEC Payload ID included (Section 8.5).¶

4. Block Integrity: Receivers MAY implement block-level checksums to detect corrupted recovery. A block whose decoded source data fails such a check, or, within a consumer that the bc-provenance profile of [MOQ-MULTICAST] Section 7.2 governs for its blocks (Section 7.4), whose recovered packets step 2 of its Section 7.2.7 does not admit, is unrecovered: Section 11.4 governs it from its FEC deadline, and the receiver requests unicast repair for it only as that section directs, never by the multicast-to-unicast failover of [MOQ-MULTICAST], which replaces the multicast path.¶

5. Repair Policy Inputs: The in-band evidence that Section 11.4.1 classifies blocks from, and the SSB_length by which Section 7.4 completes a short block, are unauthenticated on bare multicast. An injected packet that marks a block keyframe-bearing costs at most the unicast repair that block's own credit covers (Section 11.4.5). An injected source packet inside a block's gap can instead narrow the bounds of Section 11.4.1 until a keyframe-bearing block is classified otherwise, and an injected repair packet carrying a false SS_Start or SSB_length, accepted before the genuine ones, can mis-delimit a block, mark it complete early, or cause its genuine repair packets to be discarded as inconsistent (Section 7.4). Deployments exposed to injection SHOULD authenticate source and repair packets with an integrity mechanism whose coverage includes the complete packet, the Source FEC Payload ID and the Repair FEC Payload ID included (Section 8.5). Version 2 of the bc-provenance profile ([MOQ-MULTICAST] Section 7.2) is such a mechanism: its digest covers the whole UDP payload of source and repair packets, both Payload IDs included.¶

14.5. ATSC 3.0 Signed Region (A3SA) Considerations

Under iso-ssbg1-v1, the Source FEC Payload ID falls outside the A3SA signed region, and neither [ISO.23008-1] nor [ATSC-A331] provides a carriage of the SS_ID inside it (Section 8.5). An attacker who can modify it without detection could redirect source symbols to incorrect FEC blocks, causing recovery failures or corrupted output. A receiver that requires authenticated FEC block assignment therefore treats the trailer as Section 8.5 requires. On multicast networks without A3SA verification, receivers SHOULD cross-check the SS_ID against the MMTP packet_sequence_number to detect obvious tampering (e.g., an SS_ID that advances further than the packet_sequence_number of the same packet_id, whereas SS_ID advances by one per FEC source packet, Section 8.3).¶

14.6. Object Block Profile Considerations

Under moq-object-v1 a receiver takes the lengths of a rebuilt object from decoded bytes (Section 7.6.4). A corrupt decode, from damaged or injected repair symbols, can put any value there. A receiver MUST NOT read, copy or allocate beyond the end of the run it walks on the strength of the Immutable Properties Length or the Payload Length. The checks of Section 7.6.4 discard a run whose units do not tile it exactly or whose padding is not zero. They detect many corrupt decodes, but not all.¶

A block of this profile holds K x T bytes of source data at most, and no unit is longer (Section 7.6.2), so sourceSymbols and symbolSize bound the memory one open block needs. A receiver MAY decline FEC for a track whose K x T exceeds its local limits, and it bounds the number of open blocks by the policy of Section 9.¶

A unit includes the object's Immutable Properties exactly as serialized. A relay that alters them, which [I-D.ietf-moq-transport] Section 10.7 forbids, changes the unit a receiver builds from the object, and silently corrupts the recovery of the other objects of its block. A relay that adds, changes or removes mutable Properties does not affect FEC, because they are not in the unit.¶

MoQ Secure Objects authenticates the Group ID, Object ID, Publisher Priority and serialized Immutable Properties of an object, along with its payload ([I-D.ietf-moq-secure-objects] Section 3.5). The unit carries all of these except the Publisher Priority, which Section 7.6.5 asks publishers to make known. A receiver can then verify a rebuilt object as it verifies a received one, and discards one that fails. With the FEC Source Info Property inside Immutable Properties, the same verification authenticates the SS_ID of each object it accepts.¶

14.7. Reed-Solomon Considerations

The catalog bounds the cost of reed-solomon decoding. A block has at most 255 source and repair symbols (Section 4.5), so the number of source symbols a receiver recovers in it, E, is at most min(SSB_length, RSB_length), which is at most 127. The receiver inverts one E x E matrix per block and performs about E x SSB_length x T multiplications in GF(2^8) to form and apply the result (Section 4.4). One open block holds at most 255 x T bytes of symbols.¶

The code provides no integrity protection, as RaptorQ provides none (Section 14.2). A decoder that is given a corrupted or injected symbol yields wrong source symbols and reports no error, and when it decodes from exactly SSB_length symbols the code itself cannot reveal the error. The checks of Sections 7.3 and 7.6.4 reject some wrong results. A receiver that holds more than SSB_length symbols of a block can also re-encode the recovered block and compare the result with the symbols it did not use: a mismatch shows that some symbol it holds is not what the publisher encoded.¶

15.1. MoQ Registrations

This document requests one registration in the "MOQ Properties" registry of [I-D.ietf-moq-transport] (Section 8.4 of that document):¶

The type is odd, so under the key-value parity rule of [I-D.ietf-moq-transport] the Property is length-prefixed and byte-valued (Section 5.3). The scope is Object: FEC Source Info describes the individual object it tags, and carries no track-wide meaning.¶

0x11 lies in the range 0x00 to 0x77, for which [I-D.ietf-moq-transport] states a registration policy of Standards Action or IESG Approval. That policy is not reachable by an individual draft, so this document asks for 0x11 as a provisional registration in the table [I-D.ietf-moq-transport] maintains for other active drafts in the MoQ working group, on the same terms as the existing entries for draft-ietf-moq-loc and draft-ietf-moq-secure-objects. That ask is contingent on this document being adopted. If 0x11 is not available on those terms, an odd value in the range 0x80 to 0x37FF, whose policy is Specification Required, is obtainable by this document on its own. It costs at most one additional byte per tagged object, because Property types are delta-coded ([I-D.ietf-moq-transport] Section 8.3) and the extra byte appears only when the encoded Delta Type exceeds 127. It changes nothing else in this specification.¶

The even value 0x10, used by deployed implementations for this purpose, is deliberately not requested, and this document could not reserve it in any case: [I-D.ietf-moq-transport] already lists 0x10 as the TIMESTAMP Object Property of draft-ietf-moq-loc, at Object scope in the same Property Type space. Section 5.3 gives the resulting collision and its consequences.¶

This document requests no registration in any MoQ message type registry. FEC signaling uses no MoQ control message (Section 5.2); no document in this suite requests a control-message codepoint. The header extension type 0x8B01 of Section 8.5.1 is an MMTP value, not a MoQ one; [ISO.23008-1] Clause 9.2.3 defines no registry of MMTP header extension types, so its use requires no IANA action.¶

15.2. FEC Algorithm Registry

This document requests creation of a "MoQ FEC Algorithms" registry, in a new "Media over QUIC (MoQ) Forward Error Correction" registry group, with the following initial values:¶

The Identifier is the string that the catalog fec.algorithm field carries (Section 5.1). The Value is a one-byte code for the same algorithm; no message or field that this document defines carries it. New registrations require Specification Required policy ([RFC8126] Section 4.6). A registration supplies an unassigned Value, an Identifier that no other entry uses, the algorithm's name, and a reference to its specification. The designated expert checks that the specification gives the algorithm's symbol construction, the derivation of its decoder parameters from the catalog and the Repair FEC Payload ID, and the semantics of its repair objects (Section 4.3), and that it states whether the algorithm admits repair layers and the keyframe overlay (Section 6.3.3).¶

This document specifies "None" (0x00), RaptorQ (0x01) and Reed-Solomon (0x02) for interoperation. Other registered values are extension points whose interoperable use requires their own specifications (Section 4.3).¶

15.3. Catalog Packaging Value

This document defines the catalog packaging value "fec-repair" (Section 5.1) for repair tracks, extending the allowed packaging values of the MOQT Streaming Format [I-D.ietf-moq-msf] Section 5.2.4. If a registry of packaging values is established for that format, this document requests registration of:¶

15.4. FEC Block Profile Registry

This document requests creation of a "MoQ FEC Block Profiles" registry, in the registry group of Section 15.2, with the following initial values:¶

The Block Profile is the string that the catalog fec.blockProfile field carries (Section 5.1). New registrations require Specification Required policy ([RFC8126] Section 4.6). A registration supplies a Block Profile string that no other entry uses, the source track packaging values that it admits, and a reference to its specification. The designated expert checks that the specification fixes what Section 5.1 requires of a block profile: how source symbols are formed from a source packet or a source object, how many source symbols a block holds, how a block and the source symbols in it are identified, and how those identifiers wrap.¶

A.1. Catalog-Driven FEC

The subscriber learns the complete FEC configuration from the track's catalog entry before subscribing:¶

"fec": {
  "algorithm": "raptorq",
  "blockProfile": "iso-ssbg1-v1",
  "sourceSymbols": 32,
  "repairSymbols": 8,
  "symbolSize": 1312,
  "interleaveDepthMs": 1000,
  "reorderToleranceMs": 40,
  "repairTrack": "video/repair"
}

Publisher                                    Subscriber
    |                                          |
    |  (catalog obtained by SUBSCRIBE with     |
    |   request_id=0; fec field read)          |
    |                                          |
    |  SUBSCRIBE(request_id=2, track=video,    |
    |    LOCATION_FILTER=0x05 (Next Object),   |
    |    FILL_PARAMETERS(LOCATION_FILTER=      |
    |      0x01, StartGroup=1))                |
    |<-----------------------------------------|
    |                                          |
    |  SUBSCRIBE_OK(LARGEST_OBJECT={G, n})     |
    |----------------------------------------->|
    |                                          |
    |  SUBSCRIBE(request_id=4,                 |
    |    track=video/repair,                   |
    |    LOCATION_FILTER=0x05 (Next Object))   |
    |<-----------------------------------------|
    |                                          |
    |  SUBSCRIBE_OK                            |
    |----------------------------------------->|
    |                                          |
    |  [Fill fetch stream: source objects      |
    |   {G, 0} to {G, n}]                      |
    |----------------------------------------->|
    |                                          |
    |  [Source objects from {G, n+1} on]       |
    |----------------------------------------->|
    |                                          |
    |  [Repair objects, group=ext(SS_Start),   |
    |   obj=0..7]                              |
    |----------------------------------------->|
    |                                          |

Each SUBSCRIBE carries a Request ID ([I-D.ietf-moq-transport] Section 6.4.2.1). A client uses even Request IDs, starting at 0 and rising by 2 per request, so the catalog SUBSCRIBE ([I-D.ietf-moq-msf] Section 5) takes 0 and the source and repair SUBSCRIBEs take 2 and 4. Each response travels on the bidirectional stream of its request, so SUBSCRIBE_OK carries no Request ID. The source subscription joins at the start of the current Group G ([I-D.ietf-moq-transport] Section 3.5; [MOQ-MMT] Section 6.1). Its Next Object filter starts subscription delivery at {G, n+1}, where {G, n} is the Largest Object that SUBSCRIBE_OK reports, and its fill range, from {G, 0} to that Largest Object, arrives on a fill fetch stream. The repair subscription starts at the Next Object; repair objects published before it can be requested by FETCH (Section 7.5).¶

In this flow the track is mmtp-packaged with a one-second group duration (one MPU per MoQ Group, [MOQ-MMT] Section 4.3). That group duration describes the MoQ grouping; it does not derive an FEC block. For example, if the first block starts at SS_ID 0 and is full, its repair Group is its extended SS_Start, 0 (Section 7.5), the next block starts at SS_ID 32, and its repair Group is 32. A publisher MAY choose shorter blocks inside a Group or a block that crosses the Group boundary; each repair packet carries the actual SSB_length. The subscriber's decoder configuration is derived from the catalog fields and each block's SSB_length (Section 4.2): for a full block (SSB_length = K = 32), Transfer Length F = SSB_length x T = 32 x 1312 = 41,984 bytes, Symbol Size T = 1312, Z = 1, N = 1, Al = 8. No in-session message is required, and this track carries no AL-FEC signaling object ([MOQ-MMT] Section 8).¶

A loc or cmaf track under moq-object-v1 follows the same flow. Its source objects carry the FEC Source Info Property as Section 7.6.2 specifies, and its repair objects are those of Section 7.6.3.¶