Transaction-Science/open-standards
Watch
1
0
Fork
You've already forked open-standards
 0
Code Issues Pull requests Projects Releases 17 Packages Wiki Activity Actions 186
open-standards/.github/wai-conformance
History
Exact
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Transaction Science b19e078cc3 wai: capability attributes in a WHEP offer, so the gateway forwards each player the rendition its sink dispatches first 
live-ingest §9.5: a WAI-aware WHEP player writes, per media section of its offer, the WAI
capabilities its sink dispatches, in its dispatch order, as SDP media capabilities
(RFC 6871) under capability negotiation (RFC 5939): a=csup:med-v0, then for each capability
§5.1 carries over WebRTC (wai.video.avc, vp8, vp9, av1, wai.audio.opus.packet) that the
section offers, an a=rmcap, an a=mfcap of its fmtp, and an a=pcfg whose number gives the
order. The egress gateway reads them back, refuses with 422 an offer whose capability
attributes do not parse or do not hold together (caps_malformed, caps_number_reused,
caps_config_reused, caps_unknown_capability, caps_payload_type, caps_option_missing,
caps_unsupported, caps_too_many; §9.5 and §14), forwards for each section the rendition the
first advertised capability names at or below the grant's max_layer, answered with a=acfg,
and the floor where nothing advertised is published. §17 records that joule-moq-ingest does
not read them yet.

wai::sdp_caps: read, Offer::advertised, pick and Pick::acfg, write. Its tests replay
live-conformance/sdp-caps/vectors.json (offers read and refused with every reason, picks,
offers written byte for byte and read back), write and read back every order of the video
capabilities, and hold §9.5's table and reasons and §14's to the module.
live-conformance/sdp_caps_verify.py, written from §9.5 and the RFCs' grammars and sharing no
code with wai-rs, recomputes every case and requires every mutated copy to fail.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-11-09 16:08:15 -05:00
..
corpora wai conform relay --suite moqt holds a relay to the MOQT interop cases, pq joins the verifier suites, and wai conformance gen writes a corpus by its generator 2026-11-08 14:44:52 -05:00
verifiers wai: capability attributes in a WHEP offer, so the gateway forwards each player the rendition its sink dispatches first 2026-11-09 16:08:15 -05:00
baseline.json wai-conformance starts on a change to joule-ui-catalogue, the crate wai-app now links 2026-11-07 03:10:33 -05:00
README.md wai conform relay --suite moqt holds a relay to the MOQT interop cases, pq joins the verifier suites, and wai conformance gen writes a corpus by its generator 2026-11-08 14:44:52 -05:00

README.md

What wai-conformance.yml runs, one file a step

wai-conformance.yml keeps no hand list of its verifier steps, corpora or kernel tests. Its lists are derived, when it runs, from the files here and from tags in the test files, by scripts/wai-conformance-lists.py, whose docstring states every key; its gate reads the steps' paths: through scripts/pr-touches-paths.py. A change that adds a verifier, a corpus or a kernel test adds a file, or a line to a file of its own, and edits no line of the workflow, unless a step's paths: names a file under none of the trigger's paths (check names it). Its features and [[test]] entries in wai/wai-rs/Cargo.toml stay shared (wai/CONTRIBUTING.md).

  • verifiers/<name>.sh: one step of the independent-verifiers job. Its body is the step's shell, run in wai/ (or working-directory:) with bash -eo pipefail, as a workflow step runs. Its header, the leading # key: value lines, gives step: (its name), order: (steps run in ascending order, a tie by file name), features: (each list compiles alone in features-alone, and every feature joins WAI_FEATURES), and where it needs them alone:, build: pq, release-features:, bins:, pq-bins:, paths: (the extension texts it reads, which the workflow's gate then runs on) and working-directory:. Its corpus's independent verifier is an independent: line, <name> <area> [needs=<packages>] [verdicts=<file>] [dir=<dir>] python3 [-I] <script> <args>, the command line its README gives, run in wai/ by the job's one step wai conform --independent and never by the body; wai-rs/build.rs reads the binary's table of independent verifiers from these lines. A file with such lines and no body is a declaration: its verifiers run in that step alone. Prose comments follow the header, after a # line.
  • corpora/<name>.txt: one cargo-class corpus, verified by its own tool on every leg of cargo-classes (corpus:, order:, bin:, dir:), and written by it through wai conformance gen --suite <corpus>: its gen mode, or the modes gen: names in order (none where the tool writes nothing and the corpus's README says what does). wai-rs/build.rs reads these files for that command's table, and a dir: that names no corpus fails the build.
  • A test file of wai/wai-rs/tests/ whose first line is // wai-conformance: int-kernels runs in the fast integer kernels' steps of both profiles (int-kernels-release: the release step only; int-kernels-amd: the AVX-512 host too). The steps' features are the tagged tests' required-features.
  • baseline.json: the lists the workflow kept by hand before they were derived. The repository checks require every derived list to hold every entry of it, and every step it names to run.

To see what the workflow runs: python3 scripts/wai-conformance-lists.py dry-run (of another commit: --ref <commit>; two of them diff line by line). To run one step as CI does: python3 scripts/wai-conformance-lists.py run --only <name>. To check the files: python3 scripts/wai-conformance-lists.py check.