### Broadcast and streaming codecs — registered, licence-classified, never defaults

- SPEC §5 registers the elementary video and audio bitstreams distribution chains
  carry: `wai.video.{av2,vvc,hevc,avc,vp9,evc,evc.baseline,avs3,lcevc}` and
  `wai.audio.{mpegh,avs3,aac}`. Each names one payload framing, which §8 then
  fixes forever: the Annex B byte stream for AVC, HEVC, VVC and LCEVC (each
  standard also defines a bare NAL unit stream, which is not the capability),
  AV2's Annex B length-delimited bitstream, IVF for VP9, the Annex B raw
  bitstream file storage format for EVC, MHAS for MPEG-H 3D Audio and ADTS for
  AAC. The AVS3 video and audio rows name each standard's elementary
  bitstream; those texts were not read, so whether either defines a second
  form is unchecked. Each also carries a licence class with its recorded
  basis; two are classifications rather than verified statuses (AVS3: no
  published fee schedule; EVC Baseline: royalty-free by design, no formal
  guarantee). All are sink-supplied; none is in the floor or the recommended
  set. No decoder and no C dependency is added.
- AV2 is registered royalty-free but not recommended: the reference decoder
  exists, deployable decode is not yet confirmed. Promotion is a MINOR revision.
- LCEVC is an enhancement layer, carried embedded in its base bitstream or as a
  `WAI2` companion whose `companion_of` must name one of its base codecs (AVC,
  HEVC, VVC, EVC, VP9, AV1, under every capability naming those bitstreams;
  `codecs::enhancement_bases`) and resolve to exactly one selectable rendition
  of it; a base takes at most one enhancement layer. The base list is WAI's
  registration, not a restriction of ISO/IEC 23094-2, which leaves the base
  decoder unspecified; a later revision may add a base (a widening, §8).
- `wai.video.lcevc` and the HDR metadata descriptors (`wai.meta.hdr10plus`,
  `wai.meta.dovi`) are companion-only, now stated normatively: never a v1.0
  `capability` or `fallback`, never a v1.1 selectable rendition. `pick` /
  `primary` never return them; `Wai::check_component_roles` (v1.0) and
  `WaiMulti::check_component_roles` (v1.1) report envelopes that break the
  rules (`RoleError`, `#[non_exhaustive]`). A `WAI1` naming one only as its
  `fallback` does not conform and never takes dispatch step 5, but still decodes
  via its primary capability (§4 step 3); new `Wai::dispatch_capability` applies
  §4 with that rule, and `wai decode` and `wai inspect` both use it, so they
  agree on such a file. `wai wrap` refuses to write a non-conforming envelope
  and, with `--companion <cap> <payload>`, writes the `WAI2` companion form,
  whose intent follows the same rule as the `WAI1` form's (`--intent`, below),
  checked over the base payload's capability and each companion's. HDR
  metadata may bind to a neural video payload, and the base check is what
  refuses `wai wrap wai.neural.dcvc_rt … --companion wai.meta.hdr10plus …`
  (`NeuralFloat`, SPEC §7) unless another intent is given. Every companion-only
  capability is in a standard class, so the companion check refuses nothing
  yet. `wai unwrap --component <i>` extracts a `WAI2` component.
- SPEC §7.1 states the three rules a `WAI2` companion meets, and
  `WaiMulti::check_component_roles` enforces each: (1) its capability is
  companion-only or unregistered — a registered standalone capability marked
  companion is `RoleError::StandaloneAsCompanion`; (2) `companion_of` names a
  capability it applies to (`codecs::companion_applies_to`: for HDR dynamic
  metadata a registered capability in the `video` media class — new
  `codecs::is_video_class`: every `wai.video.*` capability that is not
  companion-only, the neural video codecs `wai.neural.{video_bmshj2018,dcvc_rt,
  dcvc_fm}` and the films `wai.film.{linear,reel}` — or an unregistered one,
  whose class is unknown; for LCEVC a base codec) —
  `RoleError::IncompatibleBase`; (3) that base is present, and unique for an
  enhancement layer. The check previously let an HDR descriptor bind to an audio
  rendition, LCEVC bind to any `wai.video.*` rendition (JPEG 2000 included), and
  any standalone codec ride as a companion; the reference test that carried an
  IAMF stream as a companion now carries ST 2094-10 dynamic metadata [name removed 2026-09-30] instead.
- SPEC §8 now says what these rules are, so they do not read as a redefinition
  inside `1.x`: a registration fixes a capability's payload format **and its
  role** (standalone media, or companion-only); changing either, or narrowing
  what a companion-only capability applies to, needs a new MAJOR. A MINOR
  revision may add a rule that enforces a registration, or a manifest field's
  definition, as it was made, if it lists every kind of envelope it makes
  non-conforming. The companion rules are such rules: the HDR descriptors were
  registered as companion descriptors to a video payload, not standalone media;
  `wai.video.lcevc` was registered companion-only with these rules; and
  `role = "companion"` was defined as naming, in `companion_of`, the component
  it binds to. SPEC §7.1 lists the envelopes they make non-conforming: an HDR
  descriptor as a `WAI1` `capability` or `fallback`, an HDR descriptor as a
  `WAI2` selectable rendition (which `pick` / `primary` no longer select), an
  HDR descriptor bound to a registered capability outside the `video` media
  class, a registered standalone capability marked companion, and a companion
  of any capability with no `companion_of` or none that names a selectable
  rendition in the envelope. Such envelopes still parse. The list also records
  that the earlier §7.1 named immersive-audio metadata as a companion use and a
  reference test carried `wai.audio.iamf` that way, which rule 1 now rejects,
  since `wai.audio.iamf` was registered as standalone media.
- SPEC §8 also says what registering a capability does to an envelope that used
  its string while no revision registered it. §7.1 leaves such a use unchecked
  (an HDR descriptor's unregistered base is not constrained; an unregistered
  companion needs only a present base), so the registering revision may make the envelope
  non-conforming where it uses the string against the new registration: a
  companion whose capability is registered standalone, an HDR descriptor bound
  to a capability registered outside the `video` class, a companion-only
  capability carried as a payload or bound to a base it does not admit. §8
  lists these kinds once for every registration; they still parse. This covers
  `wai.video.lcevc`, which no earlier revision registered.
- `WaiMulti::companions_of` no longer says every companion it returns is meant
  to be applied: the role check accepts an unregistered companion with a
  present base, and SPEC §7.1 forbids a sink to apply a companion whose
  capability it does not recognise.
- The broadcast-codec dispatch guidance asks for a recommended-set `WAI2`
  rendition, not a bare v1.0 `fallback`: step 5 decodes the same payload with
  the fallback's codec, which cannot read an HEVC, VVC or AV2 bitstream.
- `codecs::capability_license` is now exhaustive with no default class, so a
  registered capability can no longer become royalty-free by omission. New
  `codecs::mandatory_floor()` / `recommended_set()`; tests hold that every
  default is royalty-free. `wai capabilities` gains a `role` column.
- **Replicate classes: exhaustive, and the exact class needs recorded evidence.**
  `codecs::capability_replicate_class` no longer has a default arm (the
  determinism-tiers change below still ended it in a `StandardDefined`
  fall-through). Every registered capability is listed under one class; one
  listed nowhere returns `None`, which the tests reject. `StandardDefined`, which
  promises the same bytes on every conforming sink, is admitted only on a recorded
  basis — a conformance clause that requires identical output, or the WAI
  extension whose equivalence pins the reconstruction — pinned one row per
  capability in the tests (`standard_defined_rests_on_recorded_evidence`). The
  broadcast codecs enter with:
  - `StandardDefined`: AVC, HEVC and VVC (ITU-T H.264 §C.4, H.265 and H.266
    §C.5.1: every sample a conforming decoder outputs equals the specified
    decoding process's) and VP9 (VP9 specification v0.6 §8.1);
  - `StandardTolerance`: AV2 (AV2 v1.0.0 §7.1: film grain, as AV1);
  - `StandardUnclassified`: EVC (both entries), AVS3 video and audio, LCEVC,
    MPEG-H 3D Audio and AAC, whose conformance documents were not read.

  `wai.audio.ivas` moves from `StandardUnclassified` to `StandardTolerance` on
  3GPP TS 26.252 V19.2.0 §7.2.1: implementations based on the floating-point
  reference are tested by non-bit-exact procedures. New
  `codecs::is_cross_decoder_exact(cap)` is true where the class's
  `replicate_promise` is `ByteExact`, except for a capability whose output is
  computed from other envelopes' decoded output (new
  `codecs::composes_decoded_sources`: `wai.audio.scene`). A scene's mixdown is
  exact given its sources' PCM, and a source decoded through `wai.audio.opus` may
  decode differently on two conforming sinks, so the capability alone does not
  make it portable; new `codecs::is_cross_decoder_exact_with_sources(cap,
  sources)` is true once every source's capability is known and exact, and
  false when it cannot tell (no source given, or a source outside
  `wai.audio.*`). The class's `ByteExact` promise for a scene holds given its
  sources' PCM, so SPEC §7 names `is_cross_decoder_exact`, not the promise, as
  the audit for the same bytes on every sink. The
  promise covers the output the standard or extension specifies, not a
  conversion a sink applies afterwards. New
  `tools/wai_replicate_probe.sh` decodes each format with every independent
  decoder on the host and fails if a `StandardDefined` capability's decoders
  disagree — a falsification check, not the basis of any class.

