Internet-Draft MoQ FEC Catalog Binding November 2026
Ramadan Expires 6 May 2027 [Page]
Workgroup:
moq
Internet-Draft:
draft-ramadan-moq-fec-catalog-00
Published:
Intended Status:
Standards Track
Expires:
Author:
O. Ramadan
Blockcast

Catalog Binding for Forward Error Correction in Media over QUIC

Abstract

This document binds the Forward Error Correction (FEC) configuration data model of the MoQ FEC core mechanism to the catalog of the MOQT Streaming Format (MSF) and to its Common Media Application Format (CMAF) profile. It defines the track-level "fec" array of FEC instance objects, the fields with which a repair track or a symbol track describes its own role, the packaging values "fec-repair" and "fec-source", the validation rules that are specific to the catalog encoding, and the handling of unknown keys, so that a receiver that obtains a track's catalog entry can configure its decoder without in-session signaling.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 6 May 2027.

▲

Table of Contents

1. Introduction

Forward Error Correction (FEC) for Media over QUIC (MoQ) [I-D.ietf-moq-transport] is specified by [MOQ-FEC-CORE] as a mechanism that names no FEC code and no packaging. Its configuration is a data model ([MOQ-FEC-CORE] Section 10): the parameters that describe a source track's FEC instances and the tracks that serve them, and the rules a receiver applies to them. The core does not define their encoding.

This document is that encoding for the catalog of the MOQT Streaming Format (MSF) [I-D.ietf-moq-msf] and of its CMAF profile [I-D.ietf-moq-cmsf]. It adds one track-level field, the fec array of FEC instance objects, two packaging values, "fec-repair" and "fec-source", and the fields with which a repair track or a symbol track describes its own role. The catalog fec array is the authoritative FEC signaling for every receiver that obtains the track's catalog entry; no in-session signaling is required.

1.1. Relation to Other Documents

This document is a companion of [MOQ-FEC-CORE], which defines the mechanism, the configuration data model and the "moq-object-v1" block profile. The FEC schemes that an instance's scheme field names are defined by [MOQ-FEC-BLOCK], which registers "reed-solomon", mandatory to implement, and "raptorq", optional. The MMTP block profile "iso-ssbg1-v1" and its in-band signaling are defined by [MOQ-MMT], and FEC on multicast delivery paths by [MOQ-FEC-MULTICAST]. The multicast field that the worked catalog of Appendix A.2 carries uses the multicast endpoint format defined in [MOQ-MULTICAST]. Much of the text of this document is taken from [I-D.ramadan-moq-fec]; Appendix B lists what moved here and what changed.

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

This document uses the following terms of [MOQ-FEC-CORE], whose definitions are repeated here. Every other term, and the quantities K, T, P_i, O_i and RSB_length, have the meaning that [MOQ-FEC-CORE] Section 2 and Section 7.3.1 give them.

Source Track: A MoQ track whose objects carry media, for example video or audio, and which an FEC instance protects.

FEC Instance: One independent FEC encoding over a sequence of source symbols, with its own source symbol bound K, symbol size T, SS_ID space, block partition, repair symbols and repair tracks. A source track has one or more FEC instances ([MOQ-FEC-CORE] Section 5.1).

Source Symbol: A T-byte unit of source data that an FEC instance encodes. Source symbols are formed from source objects by the instance's block profile ([MOQ-FEC-CORE] Section 5.2).

Repair Symbol: A T-byte unit generated by the FEC scheme from the source symbols of one block.

SS_ID: The 32-bit sequence number of a source symbol within its FEC instance. It wraps modulo 2^32 ([MOQ-FEC-CORE] Section 7.6).

Source Block: A run of SSB_length consecutive source symbols, 1 <= SSB_length <= K, over which a block FEC scheme encodes. A block is the SS_ID range [SS_Start, SS_Start + SSB_length) and is identified by its SS_Start.

Encoding Symbol ID (ESI): The index of a symbol within its block: a source symbol's serial distance from SS_Start, and SSB_length + RS_ID for a repair symbol.

RS_ID: The zero-based index of a repair symbol among the repair symbols of its block.

Repair Track: A MoQ track whose objects each carry one repair symbol of one FEC instance ([MOQ-FEC-CORE] Section 7).

Repair Layer: One of possibly several repair tracks of one FEC instance, each carrying a disjoint range of RS_IDs for every block ([MOQ-FEC-CORE] Section 7.3). Layer 0 is the base layer.

Symbol Track: A MoQ track whose objects each carry exactly one source symbol of one FEC instance, grouped by block ([MOQ-FEC-CORE] Section 6.2).

Protected Object Unit: The bytes that one source object contributes to an FEC instance: its Location, its Immutable Properties and its payload, framed as [MOQ-FEC-CORE] Section 5.2 specifies.

Block Profile: The rules that fix how source symbols are formed from source objects and how blocks are delimited and identified ([MOQ-FEC-CORE] Section 5.2).

FEC Scheme: An FEC code together with the specification of its parameters, its symbol construction and its repair symbols, meeting [MOQ-FEC-CORE] Section 4.

3. Catalog Fields

The catalog is an MSF catalog [I-D.ietf-moq-msf], delivered on the track named catalog ([I-D.ietf-moq-msf] Section 5). This document adds one track-level field, the fec array defined in Section 3.1, the repair-track and symbol-track fields of Section 3.2, and the two packaging values of Section 3.3. The FEC configuration is carried at the track level:

{
  "version": 1,
  "tracks": [
    {
      "name": "video",
      "packaging": "loc",
      "isLive": true,
      "codec": "avc1.640028",
      "width": 1920,
      "height": 1080,
      "framerate": 30,
      "bitrate": 4990000,
      "fec": [
        {
          "instanceId": 0,
          "scheme": "reed-solomon",
          "blockProfile": "moq-object-v1",
          "sourceSymbols": 200,
          "symbolSize": 1100,
          "repairSymbols": 40,
          "interleaveDepthMs": 1000,
          "reorderToleranceMs": 40,
          "repairTrack": "video/repair"
        }
      ]
    },
    {
      "name": "video/repair",
      "packaging": "fec-repair",
      "isLive": true,
      "source": "video",
      "instanceId": 0,
      "repairLayer": 0,
      "repairSymbols": 40,
      "priority": 240
    }
  ]
}

A track declares FEC by carrying a fec array with at least one instance object. A track whose entry has no fec member, or whose fec array is empty, declares no FEC instance; there is no scheme identifier that means "no FEC". Appendix A works a layered configuration and a complete catalog through in full.

3.1. Instance Fields

The fec member of a source track entry is an array of FEC instance objects. Each object carries the instance parameters of [MOQ-FEC-CORE] Section 10.1 as the JSON members below. That section defines their meaning and the bounds a receiver checks; this section defines their encoding. Member names are case sensitive.

instanceId (integer, OPTIONAL, default 0): The Instance ID, 0 to 255, unique among the instance objects of the track.

scheme (string, REQUIRED): The FEC scheme identifier, a value registered in the "MoQ FEC Schemes" registry ([MOQ-FEC-CORE] Section 15.2). [MOQ-FEC-BLOCK] Section 3 registers "reed-solomon", which is mandatory to implement, and "raptorq", which is optional. A receiver that does not implement the scheme treats FEC as unavailable for the instance ([MOQ-FEC-CORE] Section 4.5); it consumes the source track without FEC and does not subscribe to or join the instance's repair or symbol tracks. An instance whose scheme member is absent names no scheme, and FEC for it is likewise unavailable.

blockProfile (string, REQUIRED): The block profile, a value registered in the "MoQ FEC Block Profiles" registry ([MOQ-FEC-CORE] Section 15.3). There is no default. Each profile admits only the source track packaging values its registration names ([MOQ-FEC-CORE] Section 15.3): "moq-object-v1" admits any packaging whose objects carry their media as whole MoQ objects, loc and cmaf included ([MOQ-FEC-CORE] Section 5.2), and "iso-ssbg1-v1" ([MOQ-MMT] Section 7.1) admits mmtp. An instance whose blockProfile names a profile the receiver does not implement, or one that does not admit the track's packaging, is one for which FEC is unavailable, as for an unimplemented scheme ([MOQ-FEC-CORE] Section 10.3, rule 1, and Section 4.5); this is not a validation failure. An instance whose blockProfile member is absent names no profile, and FEC for it is likewise unavailable. The prohibition on inferring a profile from the wire, and the rule that a publisher does not change the profile of a published instance, are those of [MOQ-FEC-CORE] Section 10.1 (the profile is part of the instance's geometry) and are not restated here; this document only encodes the value.

sourceSymbols (integer, REQUIRED): K, the largest number of source symbols a block of the instance 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. K counts source symbols, not objects: under "moq-object-v1" a source object contributes s(o) of them ([MOQ-FEC-CORE] Section 5.2).

repairSymbols (integer, REQUIRED): P_0, the repair symbols per block on layer 0. MUST be >= 1.

symbolSize (integer, REQUIRED): T, bytes per symbol. T MUST be at least 1 under every block profile: a zero-length symbol carries nothing. All symbols of an instance have the same size; the byte layout of each source symbol is fixed by the instance's blockProfile and is not otherwise carried in the catalog. Any alignment constraint on T is the scheme's ([MOQ-FEC-BLOCK] Section 7), and any lower bound beyond 1 is the block profile's.

repairTrack (string, REQUIRED): The Track Name of the layer-0 repair track, which is in the source track's Track Namespace ([MOQ-FEC-CORE] Section 7.1).

symbolTrack (string, OPTIONAL): The Track Name of the instance's symbol track ([MOQ-FEC-CORE] Section 6.2), which is in the source track's Track Namespace.

interleaveDepthMs (integer, OPTIONAL): When present, its value MUST be a non-negative integer. A positive value is the largest send span of a block of the instance in milliseconds ([MOQ-FEC-CORE] Section 9.3); for a positive value it is a duration, never a count of frames, groups, samples, or symbols, and never a per-symbol interval. An absent member supplies no catalog-signaled span. A value of zero is a violation unless the instance's block profile gives it a meaning of its own ([MOQ-FEC-CORE] Section 10.1); "moq-object-v1" does not, and [MOQ-MMT] does for "iso-ssbg1-v1".

reorderToleranceMs (number, OPTIONAL): A receiver-local allowance for packet reordering, network jitter, and local processing variance, in milliseconds ([MOQ-FEC-CORE] Section 9.3). It is a finite number greater than or equal to zero, fractional values included. That section states what an explicit value of zero and an omitted member each mean, and that a receiver keeps the two distinct.

label (string, OPTIONAL): A description for people, for example "key frames". A receiver MUST NOT derive behaviour from it.

The geometry of an instance, which a publisher does not change for the lifetime of the source encoding, is defined by [MOQ-FEC-CORE] Section 10.1. The loss tolerance of an instance's layer set is derived from K and the layer counts ([MOQ-FEC-CORE] Section 7.3.1); it MUST NOT be signaled as a separate catalog field.

3.2. Repair and Symbol Track Fields

A track with "packaging": "fec-repair" or "packaging": "fec-source" describes its own role. It carries the flat MSF track fields plus the members below, which encode the parameters of [MOQ-FEC-CORE] Section 10.2. Layer 0 of an instance is the track named by the instance's repairTrack; its entry MAY also carry source, instanceId, "repairLayer": 0 and repairSymbols, which MUST agree with the instance's corresponding field when present ([MOQ-FEC-CORE] Section 10.3). The symbol track named by an instance's symbolTrack MAY likewise carry source and instanceId.

source (string, REQUIRED except on a track that an instance's repairTrack or symbolTrack names): The Track Name of the source track this track serves. The name MUST identify a track in the same catalog that carries a fec array declaring the instance this track serves (Section 5).

instanceId (integer, OPTIONAL): The Instance ID, 0 to 255, of the instance this track serves. On a track that an instance's repairTrack or symbolTrack names it defaults to that instance and, if present, MUST equal it; otherwise it defaults to 0 ([MOQ-FEC-CORE] Section 10.2).

repairLayer (integer, REQUIRED on enhancement layers, OPTIONAL on layer 0, MUST NOT appear on a symbol track): The layer index ([MOQ-FEC-CORE] Section 7.3).

repairSymbols (integer, REQUIRED except on layer 0, MUST NOT appear on a symbol track; MUST be >= 1): The repair symbols per block that this track carries, P_i. For layer 0 the instance's repairSymbols is the authoritative P_0.

priority (integer, OPTIONAL): The Publisher Priority ([I-D.ietf-moq-transport] Section 5.1.1) of this track's objects: 192 to 255 on a repair track, non-decreasing with repairLayer within an instance, and 240 on a layer-0 repair track that omits it; 0 to 255 on a symbol track ([MOQ-FEC-CORE] Section 10.3, rule 10, and Section 10.2). A publisher that declares it MUST give every object of the track this Publisher Priority, for example through the track's DEFAULT_PUBLISHER_PRIORITY Track Property ([I-D.ietf-moq-transport] Section 10.4). A subscriber chooses its SUBSCRIBER_PRIORITY for the track as [MOQ-FEC-CORE] Section 11 states, and MAY use this value as that SUBSCRIBER_PRIORITY.

A repair or symbol track carries no geometry field, whether as a flat field or inside a fec array of its own: scheme, blockProfile, mmtpMode, timescale, any groupDuration field, symbolSize, interleaveDepthMs, reorderToleranceMs and sourceSymbols ([MOQ-FEC-CORE] Section 10.2).

The repairTrack, symbolTrack and source fields carry only a Track Name ([I-D.ietf-moq-transport] Section 2.4.1), and a receiver resolves each in the source track's Track Namespace, as [I-D.ietf-moq-msf] Section 5.2.14 does for depends. Track names carry no meaning in any of this. A receiver resolves every relationship from repairTrack, symbolTrack, source, instanceId and repairLayer; it does not infer one by parsing a track name or a name suffix, and a publisher does not rely on a receiver doing so ([MOQ-FEC-CORE] Section 7.1).

3.3. Packaging Values

Repair tracks and symbol tracks are identified in the catalog by the packaging value. A track with "packaging": "fec-repair" carries repair objects ([MOQ-FEC-CORE] Section 7.5) for the instance that Section 3.2 resolves, and a track with "packaging": "fec-source" carries that instance's source symbols, one per object ([MOQ-FEC-CORE] Section 6.2). Neither carries directly renderable media. The values extend 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 9. Receivers that do not implement this specification do not recognize the values and ignore such tracks.

3.4. Unknown Keys

A receiver MUST ignore a track-level key, or a key of an instance object, that it does not recognize, and MUST NOT treat its presence as an error, so that this suite can add fields without a flag day. Two keys defined by this document are exceptions, because ignoring either would change how the receiver must interpret the symbols it receives, which [MOQ-FEC-CORE] Section 10.3 requires a binding to prevent:

  • enhancementRepair, at track level or inside an instance object: a receiver MUST reject a catalog carrying it. The member is not defined. Repair layers are declared on their own repair-track entries (Section 3.2).
  • blockProfile: FEC is unavailable for an instance whose blockProfile names a profile the receiver does not implement ([MOQ-FEC-CORE] Section 10.3, rule 1), so the key is never ignored.

A block profile's document can define further keys for the tracks it admits, and further exceptions among them.

4. Signaling Model

The catalog fec array (Section 3) 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 tracks ([MOQ-FEC-CORE] Section 7) and to configure its decoder from the instance parameters and the scheme's parameter derivation ([MOQ-FEC-BLOCK]); no in-session signaling is required.

A block profile may also define in-band FEC signaling carried with the media, which serves a receiver that consumes a flow without the catalog; [MOQ-MMT] defines one for "iso-ssbg1-v1". "moq-object-v1" defines none, so for a track under it the catalog is the only FEC signaling. The precedence between in-band signaling and the catalog is that of [MOQ-FEC-CORE] Section 10: in-band signaling does not contradict the catalog, the catalog governs for a MoQ receiver, and a MoQ receiver needs no in-band signaling to configure its decoder.

5. Validation

A receiver validates each instance of a catalog as [MOQ-FEC-CORE] Section 10.3 requires before starting FEC for it, and on any violation fails closed for that instance as that section states. The rules of that section are not restated here. The bounds on K, T, K + P and the largest RS_ID that it defers to the instance's scheme are, for the schemes of [MOQ-FEC-BLOCK], those of [MOQ-FEC-BLOCK] Section 7: under "reed-solomon", K plus the total repair count of the instance is at most 255.

This document adds the rules of the encoding. A receiver MUST validate all of them for an instance before starting FEC for it, and on any violation MUST fail closed for the instance as above.

  1. Types and ranges: every member of Section 3.1 and Section 3.2 that is present has the JSON type, and is within the range, given there. A member of another JSON type, or outside its range, is a violation. A member that those sections mark REQUIRED and that is absent is a violation, except scheme and blockProfile: an instance that lacks either names no scheme or no profile, and FEC for it is unavailable rather than invalid (Section 3.1).
  2. Naming: repairTrack, symbolTrack and source each name a track in the same catalog, resolved as Section 3.2 states, and source names a track that carries a fec array declaring the instance that the track's instanceId selects. Because every repair or symbol track serves exactly one instance ([MOQ-FEC-CORE] Section 10.3), a Track Name appears in at most one repairTrack or symbolTrack member of a catalog.
  3. Resolution of source and instanceId: on a track that an instance's repairTrack or symbolTrack names, source and instanceId, where present, equal that track and that instance; a track with "packaging": "fec-repair" or "fec-source" that no instance names carries source, and otherwise is an orphan (rule 6).
  4. Unknown keys: the catalog carries no enhancementRepair member (Section 3.4).
  5. Republished subsets: an entity that republishes a subset of a catalog MUST NOT list a fec-repair or fec-source track whose source track it omits.
  6. No orphan repair or symbol track: every track whose packaging is fec-repair or fec-source is reachable from a source track, either by being named in an instance's repairTrack or symbolTrack or by naming that source in source ([MOQ-FEC-CORE] Section 10.3). This rule binds once the catalog declares any FEC instance; a catalog that declares no FEC instance at all MAY carry an unreferenced fec-repair or fec-source track that nothing joins. This rule is the one exception to the per-instance remedy: an orphan track is by definition associated with no instance, so there is no instance to stop. The receiver does not join the orphan track and reports it without stopping FEC for any instance, as that section states; the report names the track's catalog path.

[MOQ-FEC-CORE] Section 7.3.2 adds one check that can only be made on received repair objects.

The following are the fail-closed cases, written against the layered catalog of Appendix A.1 (instance 0: K = 64, P_0 = 8, P_1 = 16, P_2 = 32; instance 1: K = 128, P = 32) so that each defect is one edit away from a valid catalog. Each row violates the rule shown, and none of them is detectable from the wire.

Table 1
Catalog defect Rule Why the wire cannot catch it
video/repair declares repairSymbols 16 while instance 0 declares repairSymbols 8 Layer-0 agreement, [MOQ-FEC-CORE] Section 10.3 Both readings are self-consistent: one derives O_1 = 8 and total 56, the other O_1 = 16 and total 64. A repair symbol is identified by ESI alone, so a receiver that resolved P_0 the other way decodes with a shifted mapping and reports a corrupt block, not a catalog error.
Two tracks declare "repairLayer": 1 for instance 0 of video Contiguous layers, [MOQ-FEC-CORE] Section 10.3 Both claim RS_ID 8 to 23. Symbols from the two tracks are distinct on the wire but collide in ESI, so a decode fed from both sees duplicate encoding symbols and stalls short of K.
video/repair/2 is present but no track declares layer 1 Contiguous layers, [MOQ-FEC-CORE] Section 10.3 O_2 is a function of P_1, which is absent, so the receiver has no offset for layer 2 at all.
video/repair/kf carries "instanceId": 0 while instance 1's repairTrack names it Rule 3 Its repair objects would be read as instance 0's and placed in instance 0's ESI range, although they were encoded over instance 1's blocks of up to 128 symbols; a repair object carries its instance only through the catalog.
A second instance object of video carries "instanceId": 1 Unique Instance IDs, [MOQ-FEC-CORE] Section 10.3 A source object's FEC Source Info Property carries one SS_ID per instance ([MOQ-FEC-CORE] Section 5.6), so a second instance 1 has no SS_ID on the wire.
video/repair/1 carries symbolSize or a fec array of its own No geometry on a repair track, [MOQ-FEC-CORE] Section 10.3 A repair track carrying its own geometry would declare an instance of its own, naming itself as layer 0, and bypass rule 6's reachability check.

A receiver MAY report several violations at once.

6. Naming Convention

This section is informative.

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

Table 2
Track Namespace Source Track Name Repair Track Name
("live") "video" "video/repair"
("broadcast", "video") "1080p" "1080p/repair"
("stream") "audio/en" "audio/en/repair"

The name is a convention and not a resolution mechanism: a receiver resolves every repair track from the fields of Section 3.2, so the name serves only human readers, in logs and configuration. Enhancement layers, symbol tracks and further instances have no conventional name. Names such as "video/repair/1" appear in the examples of this document for readability only.

7. CMSF

This section is informative.

A cmaf track [I-D.ietf-moq-cmsf] carries the fec array of Section 3.1 exactly as any other track, and its repair and symbol tracks carry the fields of Section 3.2; the CMAF profile of the MSF catalog adds no member of its own to any of them, and this document adds none to the fields of [I-D.ietf-moq-cmsf].

Under "moq-object-v1", which admits cmaf ([MOQ-FEC-CORE] Section 15.3), a repair track protects a cmaf track directly. Each object of the cmaf track holds one or more CMAF chunks ([I-D.ietf-moq-cmsf] Section 3.3) and forms one Protected Object Unit, and each Group begins with an object that contains a Stream Access Point (SAP) ([I-D.ietf-moq-cmsf] Section 3.4):

+-------------------------------------------------+
|              MoQ Track Namespace                |
+-------------------------------------------------+
|                                                 |
|  Source Track (packaging "cmaf")                |
|  +-----------------------------------------+    |
|  | Object {G, 0}: CMAF chunk with a SAP    |    |
|  | Object {G, 1}: CMAF chunk               |    |
|  | ...                                     |    |
|  +-----------------------------------------+    |
|                                                 |
|  Repair Track (packaging "fec-repair")          |
|  +-----------------------------------------+    |
|  | Group ext(S0): repair for block at S0   |    |
|  | Group ext(S1): repair for block at S1   |    |
|  | ...                                     |    |
|  +-----------------------------------------+    |
|                                                 |
+-------------------------------------------------+

[MOQ-FEC-CORE] Section 13.2 states how a publisher chooses K and T for CMAF objects and how segment boundaries relate to blocks; the mmtp rendition of CMAF content is described by [MOQ-MMT].

8. Security Considerations

This document defines an encoding of the configuration data model of [MOQ-FEC-CORE] and introduces no mechanism beyond it. The security considerations of [MOQ-FEC-CORE] Section 14 apply, as do those of [I-D.ietf-moq-msf] for the catalog that carries the encoding. The catalog is the receiver's authoritative FEC signaling (Section 4), so an entity that can alter it can direct a receiver to join repair tracks that it would not otherwise join; the fail-closed validation of Section 5 and the limits of [MOQ-FEC-CORE] Section 14.4 bound what such a catalog can cause.

9. IANA Considerations

This document defines the catalog packaging values "fec-repair" and "fec-source" (Section 3.3) for repair tracks and symbol 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:

Table 3
Value Description Reference
"fec-repair" Repair objects of an FEC instance This document
"fec-source" Source symbols of an FEC instance, one per object This document

10. References

10.1. Normative References

[I-D.ietf-moq-msf]
Law, W. and S. Nandakumar, "MOQT Streaming Format", Work in Progress, Internet-Draft, draft-ietf-moq-msf-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-moq-msf-01>.
[I-D.ietf-moq-transport]
Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell, "Media over QUIC Transport", Work in Progress, Internet-Draft, draft-ietf-moq-transport-22, , <https://datatracker.ietf.org/doc/html/draft-ietf-moq-transport-22>.
[MOQ-FEC-BLOCK]
Ramadan, O., "Block FEC Schemes for Media over QUIC: Reed-Solomon and RaptorQ", Work in Progress, Internet-Draft, draft-ramadan-moq-fec-block-codes-00, , <https://datatracker.ietf.org/doc/html/draft-ramadan-moq-fec-block-codes-00>.
[MOQ-FEC-CORE]
Ramadan, O. and M. E. Fiuczynski, "Forward Error Correction for Media over QUIC: Core Mechanism", Work in Progress, Internet-Draft, draft-ramadan-moq-fec-core-00, , <https://datatracker.ietf.org/doc/html/draft-ramadan-moq-fec-core-00>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

10.2. Informative References

[I-D.ietf-moq-cmsf]
Law, W., "CMSF- a CMAF compliant implementation of MOQT Streaming Format", Work in Progress, Internet-Draft, draft-ietf-moq-cmsf-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-moq-cmsf-01>.
[I-D.ramadan-moq-fec]
Ramadan, O., "Forward Error Correction for Media over QUIC", Work in Progress, Internet-Draft, draft-ramadan-moq-fec-01, , <https://datatracker.ietf.org/doc/html/draft-ramadan-moq-fec-01>.
[MOQ-FEC-MULTICAST]
Ramadan, O., "Forward Error Correction for Multicast Delivery of Media over QUIC", Work in Progress, Internet-Draft, draft-ramadan-moq-fec-multicast-00, , <https://datatracker.ietf.org/doc/html/draft-ramadan-moq-fec-multicast-00>.
[MOQ-MMT]
Ramadan, O., "MPEG Media Transport (MMT) Packaging for Media over QUIC", Work in Progress, Internet-Draft, draft-ramadan-moq-mmt-02, , <https://datatracker.ietf.org/doc/html/draft-ramadan-moq-mmt-02>.
[MOQ-MULTICAST]
Ramadan, O., "Multicast Delivery and Endpoint Discovery for Media over QUIC", Work in Progress, Internet-Draft, draft-ramadan-moq-multicast-02, , <https://datatracker.ietf.org/doc/html/draft-ramadan-moq-multicast-02>.

Appendix A. Worked Catalog

This appendix is informative.

A.1. Layered Instances

Two FEC instances on one loc source track: instance 0 over every object, with three repair layers and a symbol track, and instance 1 over the key frames only, with a longer span ([MOQ-FEC-CORE] Section 8.4). Which objects belong to instance 1 is declared by each object's FEC Source Info Property ([MOQ-FEC-CORE] Section 5.6), not by the catalog:

{
  "version": 1,
  "tracks": [
    {
      "name": "video",
      "packaging": "loc",
      "isLive": true,
      "codec": "avc1.640028",
      "width": 1920,
      "height": 1080,
      "framerate": 30,
      "bitrate": 4990000,
      "fec": [
        {
          "instanceId": 0,
          "scheme": "reed-solomon",
          "blockProfile": "moq-object-v1",
          "sourceSymbols": 64,
          "symbolSize": 1200,
          "repairSymbols": 8,
          "interleaveDepthMs": 200,
          "repairTrack": "video/repair",
          "symbolTrack": "video/symbols",
          "label": "all frames"
        },
        {
          "instanceId": 1,
          "scheme": "reed-solomon",
          "blockProfile": "moq-object-v1",
          "sourceSymbols": 128,
          "symbolSize": 1200,
          "repairSymbols": 32,
          "interleaveDepthMs": 1000,
          "repairTrack": "video/repair/kf",
          "label": "key frames"
        }
      ]
    },
    {
      "name": "video/symbols",
      "packaging": "fec-source",
      "isLive": true,
      "source": "video",
      "instanceId": 0,
      "priority": 128
    },
    {
      "name": "video/repair",
      "packaging": "fec-repair",
      "isLive": true,
      "source": "video",
      "instanceId": 0,
      "repairLayer": 0,
      "repairSymbols": 8,
      "priority": 240
    },
    {
      "name": "video/repair/1",
      "packaging": "fec-repair",
      "isLive": true,
      "source": "video",
      "instanceId": 0,
      "repairLayer": 1,
      "repairSymbols": 16,
      "priority": 244
    },
    {
      "name": "video/repair/2",
      "packaging": "fec-repair",
      "isLive": true,
      "source": "video",
      "instanceId": 0,
      "repairLayer": 2,
      "repairSymbols": 32,
      "priority": 248
    },
    {
      "name": "video/repair/kf",
      "packaging": "fec-repair",
      "isLive": true,
      "source": "video",
      "instanceId": 1,
      "priority": 242
    }
  ]
}

A receiver derives the following for instance 0 from that catalog, the ESI column for a full block; none of it is carried on the wire:

Table 4
Layer P_i O_i RS_ID range ESI range (full block, SSB_length = 64)
0 8 0 0 to 7 64 to 71
1 16 8 8 to 23 72 to 87
2 32 24 24 to 55 88 to 119

The RS_ID ranges are fixed by the catalog. The ESI ranges are those of a full block: a repair symbol's ESI is the block's SSB_length plus its RS_ID ([MOQ-FEC-CORE] Section 7.3.1), so in a short block every ESI range moves down by 64 - SSB_length while the RS_ID ranges do not move.

The total repair count is 8 + 16 + 32 = 56, so RSB_length is 56 on every repair object of layers 0, 1 and 2 ([MOQ-FEC-CORE] Section 7.5). Instance 1 is a separate FEC instance and is not in that table: its own K is 128, its own P is 32, its RS_ID range is 0 to 31, its ESI range in a full block is 128 to 159, and its repair objects carry RSB_length 32. Both instances are valid under "reed-solomon": 64 + 56 = 120 and 128 + 32 = 160 are at most 255 ([MOQ-FEC-BLOCK] Section 7). The two instances share T, so the key-frame symbols a receiver takes on "video/symbols" can also count toward instance 1, as [MOQ-FEC-CORE] Section 8.4 describes.

The layer arithmetic is the same under every block profile.

A.2. Complete Catalog

Complete catalog with FEC and multicast configuration for two mmtp tracks under "iso-ssbg1-v1" ([MOQ-MMT] Section 7.1):

{
  "version": 1,
  "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": [
        {
          "instanceId": 0,
          "scheme": "reed-solomon",
          "blockProfile": "iso-ssbg1-v1",
          "sourceSymbols": 200,
          "repairSymbols": 40,
          "symbolSize": 1400,
          "interleaveDepthMs": 1000,
          "reorderToleranceMs": 40,
          "repairTrack": "video/repair"
        }
      ]
    },
    {
      "name": "video/repair",
      "packaging": "fec-repair",
      "isLive": true,
      "source": "video",
      "instanceId": 0,
      "repairLayer": 0,
      "repairSymbols": 40,
      "priority": 240
    },
    {
      "name": "audio",
      "packaging": "mmtp",
      "isLive": true,
      "mmtpMode": "mfu",
      "timescale": 48000,
      "presentationAnchorTicks": 0,
      "groupDurationMs": 1000,
      "codec": "mp4a.40.2",
      "samplerate": 48000,
      "channelConfig": "2",
      "bitrate": 128000,
      "fec": [
        {
          "instanceId": 0,
          "scheme": "reed-solomon",
          "blockProfile": "iso-ssbg1-v1",
          "sourceSymbols": 32,
          "repairSymbols": 8,
          "symbolSize": 512,
          "interleaveDepthMs": 1000,
          "reorderToleranceMs": 40,
          "repairTrack": "audio/repair"
        }
      ]
    },
    {
      "name": "audio/repair",
      "packaging": "fec-repair",
      "isLive": true,
      "source": "audio",
      "instanceId": 0,
      "repairLayer": 0,
      "repairSymbols": 8,
      "priority": 240
    }
  ],
  "multicast": {
    "endpoints": [{
      "sourceAddress": "198.51.100.100",
      "groupAddress": "232.1.1.50",
      "port": 5000,
      "tracks": [
        { "name": "video",        "packetId": 1 },
        { "name": "video/repair", "packetId": 2 },
        { "name": "audio",        "packetId": 3 },
        { "name": "audio/repair", "packetId": 4 }
      ]
    }]
  }
}

Parameter consistency: both tracks use one-second MMTP groups (one MPU per MoQ Group), and each has a 1000 ms source/repair send-span budget. The group duration does not determine the FEC partition. A worked capacity check must include the MMTP and MPU-mode headers, not only the media bitrate. With no MMTP header extension, a timed FT=2 packet has the following media capacity, depending on whether it starts a data unit ([MOQ-MMT]):

FI=0 or FI=1: T - 2 (length) - 12 (MMTP) - 8 (MPU) - 14 (DU) = T - 36
FI=2 or FI=3: T - 2 (length) - 12 (MMTP) - 8 (MPU)           = T - 22

The source packet also carries a 4-byte Source FEC Payload ID on the wire, outside the protected packet and therefore outside these symbol budgets. FT=0/FT=1 metadata consumes source packets but does not carry sample bytes, and any MMTP extension consumes additional space. Every protected MMTP packet still has to fit within T - 2. Using the larger continuation capacity gives a media ceiling, not a packetization plan:

  • Video: 4,990,000 bit/s x 1.0 s / 8 = 623,750 bytes of media per one-second group. K x (T - 22) = 200 x 1378 = 275,600 bytes is an upper bound on the media capacity of one full block. The media therefore needs at least ceil(623,750 / 1378) = 453 source packets and at least three K=200 blocks; MMTP metadata, fragmentation, and authored packet boundaries can require more. Repair overhead is P / K = 40 / 200 = 20%, and K + P = 240 is within the "reed-solomon" bound of 255.
  • Audio: 128,000 bit/s x 1.0 s / 8 = 16,000 bytes of media per group; the upper-bound capacity of one full block is K x (T - 22) = 32 x 490 = 15,680 bytes. The media therefore needs at least ceil(16,000 / 490) = 33 source packets and at least two K=32 blocks; packetization and metadata can require more. Repair overhead is P / K = 8 / 32 = 25%.

The publisher chooses the actual source-packet count and block boundaries so that every packet, including FT=0 and FT=1 metadata, fits the selected symbol size and every block's repair fields describe the actual (SS_Start, SSB_length) partition. These calculations are capacity examples, not a rule that one FEC block equals one Group.

The catalog envelope is the MSF root ([I-D.ietf-moq-msf] Section 5.1); track entries carry the flat base track fields of [I-D.ietf-moq-msf] Section 5.2 (codec, width, samplerate, ...) alongside the fec array this document defines, and inherit the namespace of the catalog track ([I-D.ietf-moq-msf] Section 5.2.2). The multicast field uses the multicast endpoint format defined in [MOQ-MULTICAST] Section 4.1: a one-element endpoints array. Per [MOQ-MULTICAST] Sections 4.1 and 5, a multicast endpoint lists only mmtp tracks and their repair tracks, and a loc or cmaf track reaches multicast through an mmtp rendition track; symbol tracks are not listed on a multicast endpoint ([MOQ-FEC-MULTICAST] Section 3.3). Each track listed on the endpoint carries a packetId that routes its MMTP packets on the multicast UDP path. Appendix D of [MOQ-FEC-CORE] gives a loc track under "moq-object-v1", whose capacity is counted in Protected Object Units rather than MMTP packets.

Appendix B. Changes from draft-ramadan-moq-fec-01

This appendix is informative. Section numbers in it are those of [I-D.ramadan-moq-fec].

What moved here:

What changed in the carried text:

New sentences, not carried from -01:

Acknowledgements

Much of the text of this document is taken from [I-D.ramadan-moq-fec]. The division of that document into [MOQ-FEC-CORE] and its companions follows a proposal by Marc E. Fiuczynski.

Portions of this document were drafted with the assistance of AI tools. The author reviewed, edited and takes responsibility for all of its content.

Author's Address

Omar Ramadan
Blockcast