open-standards/wai/encode-conformance

encode-conformance/: the corpus of wai.video.encode

The corpus of platform-encode §10.1.

path	what	how it is made
streams/	AVC and HEVC elementary streams made through each encoder interface (§3): platform-* by the media framework's hardware engine, va-1-* and va-2-* by two GPUs' encode engines through the video acceleration API, gpu-driver-* by a GPU driver's encode interface, software-* by the runtime-loaded software library	fixtures: made once by `wai encode avc
streams.json	each fixture's SHA-256	wai_encode_vectors gen
decoded/	the pictures a conforming decoder made from a fixture stream (software-avc-128x72.yuv, from streams/software-avc-128x72.h264): each picture's luma, Cb and Cr planes, one picture after another (§8.3)	a fixture: decoded once by the platform's decoder (wai_encode_measure quality --decoded-out); every conforming decoder outputs these pictures from that stream, so they are kept, not decoded again
decoded.json	each decoded fixture's SHA-256	wai_encode_vectors gen
handed/	for each decoded fixture, the pictures its stream's encoder was handed (the source resampled to the rung), in the same layout: a perfect score no decode of the stream gives, for the case that hands them over (§7)	generated
source.y4m, plan.txt	the source every fixture was made from (256×144, 12 frames, 30 fps) and its IDR plan	generated
mutated/	streams derived from a fixture by one edit, each breaking one rule of §4.3	generated
records/, cases.json	a record per case, signed with the corpus key (32 bytes of 0x45), and every case's files and outcome; the quality cases state their figures over the source resampled to the 128×72 rung, hold pictures too (decoded, the file; pictures, how the verifier came by them, decoded or handed), and, where accepted, give §7's verdict (quality: decoded, handed or stated)	generated
rendition/	encoded renditions (§9) of the packaging golden pack-conformance/packs/video-base-01: streams/ fixtures made from its source with its plan, cases/ and cases.json, accepted and mutated	wai-pack rendition-vectors gen (key: 32 bytes of 0x46)
encode_verify.py	the second implementation, written from the extension's text	—

Provenance. Generated here, as the table states: source.y4m and plan.txt are generated; each fixture under streams/ and rendition/streams/ was made once from that source by wai encode through the encoder interface its name gives, and is kept, not regenerated; the pictures under decoded/ were decoded once from their fixture stream by the platform's decoder, and are kept; streams.json, decoded.json, mutated/, records/ and cases.json are written by wai_encode_vectors gen, as is handed/, and rendition/'s cases by wai-pack rendition-vectors gen. Every input is generated in this repository.

A case's decoded pictures stand in for a verifier's own decode, because every conforming decoder outputs them from that stream (§10.2): neither wai-rs on a host with no platform decoder nor encode_verify.py decodes anything, and a verifier with a decoder may decode the stream instead. On accept-quality-own-pictures-* the figures hold over pictures handed over and say nothing of the stream, which quality-own-pictures-decoded-* shows. On accept-quality-null-* nothing was measured, so the pictures held have no figures to hold to and the case gives no verdict; a record with no quality member reads the same.

The identities in the records are the corpus's, not the encoders' that made the streams. The software library made the same bytes on three hosts of two architectures; nothing here relies on that.

Check:

cd wai/wai-rs && cargo run --locked -q --no-default-features --features platform_encode --bin wai_encode_vectors -- verify ../encode-conformance
cd wai/wai-pack && cargo run --locked -q --bin wai-pack -- rendition-vectors check ../encode-conformance/rendition
python3 -I wai/encode-conformance/encode_verify.py wai/encode-conformance