Blockcast

omar@blockcast.net

wit moq FEC MoQ catalog MSF CMSF 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.

Introduction Forward Error Correction (FEC) for Media over QUIC (MoQ) is specified by as a mechanism that names no FEC code and no packaging. Its configuration is a data model ( 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) and of its CMAF profile . 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.

Relation to Other Documents This document is a companion of , 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 , 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 , and FEC on multicast delivery paths by . The multicast field that the worked catalog of carries uses the multicast endpoint format defined in . Much of the text of this document is taken from ; lists what moved here and what changed.

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 when, and only when, they appear in all capitals, as shown here. This document uses the following terms of , whose definitions are repeated here. Every other term, and the quantities K, T, P_i, O_i and RSB_length, have the meaning that 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 ( 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 ( 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 ( 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 ( 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 ( 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 ( 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 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 ( Section 5.2). FEC Scheme: An FEC code together with the specification of its parameters, its symbol construction and its repair symbols, meeting Section 4.

Catalog Fields The catalog is an MSF catalog , delivered on the track named catalog ( Section 5). This document adds one track-level field, the fec array defined in , the repair-track and symbol-track fields of , and the two packaging values of . The FEC configuration is carried at the track level: 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". works a layered configuration and a complete catalog through in full.

Instance Fields The fec member of a source track entry is an array of FEC instance objects. Each object carries the instance parameters of 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 ( Section 15.2). 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 ( 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 ( Section 15.3). There is no default. Each profile admits only the source track packaging values its registration names ( Section 15.3): "moq-object-v1" admits any packaging whose objects carry their media as whole MoQ objects, loc and cmaf included ( Section 5.2), and "iso-ssbg1-v1" ( 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 ( 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 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 ( 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 ( 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 ( Section 7.1). symbolTrack (string, OPTIONAL): The Track Name of the instance's symbol track ( 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 ( 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 ( Section 10.1); "moq-object-v1" does not, and does for "iso-ssbg1-v1". reorderToleranceMs (number, OPTIONAL): A receiver-local allowance for packet reordering, network jitter, and local processing variance, in milliseconds ( 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 Section 10.1. The loss tolerance of an instance's layer set is derived from K and the layer counts ( Section 7.3.1); it MUST NOT be signaled as a separate catalog field.

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 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 ( 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 (). 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 ( Section 10.2). repairLayer (integer, REQUIRED on enhancement layers, OPTIONAL on layer 0, MUST NOT appear on a symbol track): The layer index ( 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 ( 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 ( 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 ( Section 10.4). A subscriber chooses its SUBSCRIBER_PRIORITY for the track as 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 ( Section 10.2). The repairTrack, symbolTrack and source fields carry only a Track Name ( Section 2.4.1), and a receiver resolves each in the source track's Track Namespace, as 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 ( Section 7.1).

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 ( Section 7.5) for the instance that resolves, and a track with "packaging": "fec-source" carries that instance's source symbols, one per object ( Section 6.2). Neither carries directly renderable media. The values extend the allowed packaging values of Section 5.2.4 in the same manner as the cmaf value of ; see . Receivers that do not implement this specification do not recognize the values and ignore such tracks.

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 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 ().
• blockProfile: FEC is unavailable for an instance whose blockProfile names a profile the receiver does not implement ( 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.

Signaling Model The catalog fec array () 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 ( Section 7) and to configure its decoder from the instance parameters and the scheme's parameter derivation (); 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; 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 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.

Validation A receiver validates each instance of a catalog as 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 , those of 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 and 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 ().
2. Naming: repairTrack, symbolTrack and source each name a track in the same catalog, resolved as 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 ( 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 ().
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 ( 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.

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

Catalog defect	Rule	Why the wire cannot catch it
video/repair declares repairSymbols 16 while instance 0 declares repairSymbols 8	Layer-0 agreement, 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, 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, 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, Section 10.3	A source object's FEC Source Info Property carries one SS_ID per instance ( 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, 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.

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":

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

CMSF This section is informative. A cmaf track carries the fec array of exactly as any other track, and its repair and symbol tracks carry the fields of ; 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 . Under "moq-object-v1", which admits cmaf ( Section 15.3), a repair track protects a cmaf track directly. Each object of the cmaf track holds one or more CMAF chunks ( Section 3.3) and forms one Protected Object Unit, and each Group begins with an object that contains a Stream Access Point (SAP) ( Section 3.4): 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 .

Security Considerations This document defines an encoding of the configuration data model of and introduces no mechanism beyond it. The security considerations of Section 14 apply, as do those of for the catalog that carries the encoding. The catalog is the receiver's authoritative FEC signaling (), 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 and the limits of Section 14.4 bound what such a catalog can cause.

IANA Considerations This document defines the catalog packaging values "fec-repair" and "fec-source" () for repair tracks and symbol tracks, extending the allowed packaging values of the MOQT Streaming Format Section 5.2.4. If a registry of packaging values is established for that format, this document requests registration of:

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

References Normative References Blockcast Blockcast Rutgers University Informative References Blockcast Blockcast Blockcast

Worked Catalog This appendix is informative.

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 ( Section 8.4). Which objects belong to instance 1 is declared by each object's FEC Source Info Property ( Section 5.6), not by the catalog: 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:

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 ( 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 ( 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 ( 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 Section 8.4 describes. The layer arithmetic is the same under every block profile.

Complete Catalog Complete catalog with FEC and multicast configuration for two mmtp tracks under "iso-ssbg1-v1" ( Section 7.1): 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 (): 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 ( Section 5.1); track entries carry the flat base track fields of Section 5.2 (codec, width, samplerate, ...) alongside the fec array this document defines, and inherit the namespace of the catalog track ( Section 5.2.2). The multicast field uses the multicast endpoint format defined in Section 4.1: a one-element endpoints array. Per 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 ( 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 gives a loc track under "moq-object-v1", whose capacity is counted in Protected Object Units rather than MMTP packets.

Changes from draft-ramadan-moq-fec-01 This appendix is informative. Section numbers in it are those of . What moved here:

• -01 Section 5.1 (Catalog Fields): the catalog shape and the field definitions, to and ; the "fec-repair" packaging text, to ; the unknown-key rules and the enhancementRepair tombstone, to . The parameter semantics (the meaning of sourceSymbols, interleaveDepthMs, the deadline formula, the block-profile admission check and the absent-profile case of -01 Section 5.1, the prohibition on inferring a profile, the rule that a publisher does not change a published profile, and the reorderToleranceMs range and omitted-versus-zero rule) are now stated by and cited, not restated. The iso-ssbg1-v1 bullet, the symbolSize lower bound of 14, the ISO meaning of a zero interleaveDepthMs and the AL-FEC text went to ; the RaptorQ alignment of T went to . The clause that the catalog of an mmtp track is extended as describes is not carried; states that extension itself.
• -01 Section 5.1.1 (Repair Track Fields), to ; the scope and overlay sourceSymbols members went to .
• -01 Section 5.1.2 (Worked Catalog) and Appendix B (Catalog Example), re-rendered in the data model of , to .
• -01 Section 5.2 (Signaling Model), lines on catalog authority, to ; the AL-FEC paragraph went to and the sessionless-receiver paragraph to .
• -01 Section 6.1 (Track Naming): the "/repair" convention and its table, to ; the Track Name resolution sentence, to .
• -01 Section 6.3: the republished-subset rule, to .
• -01 Section 6.3.2: the sentence that loss tolerance is not a catalog field, to .
• -01 Section 6.3.4 (Catalog Rules and Fail-Closed Validation): the binding-specific rules and the defect table, to ; the scheme-neutral rules are now 's and the scheme bounds 's.
• -01 Section 13 (Interaction with CMAF Packaging): the direct protection of a cmaf track and its diagram, to ; the mmtp rendition went to and the segment-boundary paragraph to .
• -01 Section 15.3 (Catalog Packaging Value), to , now with "fec-source".

What changed in the carried text:

• fec is an array of FEC instance objects, each with an instanceId, instead of one object; algorithm is renamed scheme; depends (an array of one name) is replaced by source (one Track Name); symbolTrack, the instance member label, the track member instanceId and the packaging value "fec-source" are new, from .
• The scheme value "none" is retired: a track without instance objects declares no FEC.
• The keyframe overlay ("scope": "keyframe") is no longer a catalog construct of this document; the layered example declares the key-frame protection as a second instance.
• In , repairLayer and repairSymbols are each forbidden on a symbol track, encoding the repair-only scope of Section 10.2; -01 forbade repairLayer on an overlay only and placed no such limit on repairSymbols.
• priority keeps the range 192 to 255 of -01 Section 5.1.1 on a repair track and is 0 to 255 on a symbol track, the type of ; its entry now also states in brief the monotonicity rule and the layer-0 default of 240 of -01 rule 3, which Section 10.3, rule 10, carries and this document cites.
• The rule of -01 Section 5.1.1 that a subscriber should not subscribe to a repair track with a subscriber priority numerically lower than that of its source subscription is not restated; Section 11 states it, and cites that section instead.
• The -01 Section 5.1 receiver rule on a blockProfile that the receiver does not implement or that does not admit the track's packaging, the ban on inferring a profile from the wire and the ban on changing a published blockProfile are stated by (Section 10.3, rule 1, Section 4.5 and Section 10.1) and are cited from and instead of being restated; the -01 rule for an omitted blockProfile keeps its outcome, that FEC is unavailable for the instance, without its keyword.
• A zero interleaveDepthMs is a violation unless the block profile gives it a meaning; under -01 it was equivalent to an absent field under "moq-object-v1".
• "moq-object-v1" admits every packaging whose objects carry their media as whole MoQ objects, not only loc and cmaf, following Section 15.3; the signaling-model sentence that the loc and cmaf packagings define no in-band signaling now says that "moq-object-v1" defines none.
• The reorderToleranceMs requirements of -01 Section 5.1 (finite and non-negative, explicit zero distinct from absent) are not restated; Section 9.3 states them and is cited.
• The examples use "reed-solomon" and satisfy K + P <= 255: the complete catalog's video instance is K = 200, P = 40, T = 1400 (was K = 625, P = 125, T = 1000 under "raptorq"), and the packet-budget arithmetic is recomputed for it; the layered example's second instance is K = 128, P = 32 (was an overlay with K = 256, P = 32). The catalog version is 1.
• The republished-subset rule and the orphan rule cover "fec-source" tracks as well as "fec-repair" tracks.
• The unimplemented-scheme sentence of now reads "does not subscribe to or join the instance's repair or symbol tracks", as Section 4.5 states; -01 named only repair tracks.
• The orphan rule's remedy of -01 rule 9 (refuse the orphan track, report its catalog path, stop FEC for nothing) is stated by Section 10.3 and not restated; rule 6 carries the exception that the rule binds once the catalog declares any instance, and names the catalog path as what the report carries.
• The defect table is rewritten against : the two overlay rows become an instanceId row and a duplicate-instance row.
• The capacity notes of use no BCP 14 keywords, because the appendix is informative; their "has to fit" and "The publisher chooses" are kept as plain description.
• The name-parsing rule of -01 Section 5.1.1 (a receiver resolves every relationship from the catalog fields, never from a track name) is now stated by Section 7.1, which also binds the publisher; restates it without keywords and cites it.

New sentences, not carried from -01:

• The sentences of the Abstract, of and of .
• In : "This document uses the following terms of , whose definitions are repeated here. Every other term, and the quantities K, T, P_i, O_i and RSB_length, have the meaning that Section 2 and Section 7.3.1 give them."
• In : "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"."
• In , under scheme: "An instance whose scheme member is absent names no scheme, and FEC for it is likewise unavailable."
• In : "That section defines their meaning and the bounds a receiver checks; this section defines their encoding. Member names are case sensitive."; "Any alignment constraint on T is the scheme's ( Section 7), and any lower bound beyond 1 is the block profile's."; "A value of zero is a violation unless the instance's block profile gives it a meaning of its own ( Section 10.1); "moq-object-v1" does not, and does for "iso-ssbg1-v1"."; "The geometry of an instance, which a publisher does not change for the lifetime of the source encoding, is defined by Section 10.1."; "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 ( 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 Section 10.1 (the profile is part of the instance's geometry) and are not restated here; this document only encodes the value."; "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."
• In : the last sentence of the first paragraph, which lets the symbol track named by an instance's symbolTrack carry source and instanceId.
• In : the sentence that a subscriber chooses its SUBSCRIBER_PRIORITY for the track as Section 11 states and may use this value as that SUBSCRIBER_PRIORITY.
• In : "A block profile's document can define further keys for the tracks it admits, and further exceptions among them."
• In : the blockProfile bullet now cites Section 10.3, rule 1, instead of restating the rule.
• In : "The rules of that section are not restated here."; the second paragraph in full (the binding's own rules and their fail-closed remedy); rule 1 in full; in rule 2, "Because every repair or symbol track serves exactly one instance ( Section 10.3), a Track Name appears in at most one repairTrack or symbolTrack member of a catalog."; rule 3 in full; rule 4 in full; and the two rewritten defect-table rows.
• In : "Enhancement layers, symbol tracks and further instances have no conventional name."
• In : the first paragraph, and " 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 ."
• The sentences of .
• In : the introductory paragraph, "Both instances are valid under "reed-solomon": 64 + 56 = 120 and 128 + 32 = 160 are at most 255 ( Section 7)." (replacing -01's raptorq/overlay sentence), "The two instances share T, so the key-frame symbols a receiver takes on "video/symbols" can also count toward instance 1, as Section 8.4 describes." and "The layer arithmetic is the same under every block profile."
• In : "symbol tracks are not listed on a multicast endpoint ( Section 3.3)" and ", and K + P = 240 is within the "reed-solomon" bound of 255".

Acknowledgements Much of the text of this document is taken from . The division of that document into 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.