WAI Extension: Platform and Hardware Encoding

Mirrored from the canonical text at commit 260cbd09 (2026-11-08).

Status: Draft. Registers the record wai.video.encode. A sink or a packager that needs an AVC (ISO/IEC 14496-10) or HEVC (ISO/IEC 23008-2) rendition encodes it with an encoder the device already has: the operating system’s media framework and its hardware media engine, a GPU’s encode engine through the video acceleration API or through the GPU driver’s own encode interface, or a software AVC library the user obtains separately and names at run time. WAI writes no AVC or HEVC encoder. This extension fixes the shape the encoder’s output is held to (§4), what names the encoder (§5), and the encode record, a signed statement of who made an elementary stream, from what source, with which settings and at what measured cost, and, where its signer decoded the stream, the quality of the pictures it decodes to (§6 to §8). A verifier holds the stream to its digest and its shape; it never re-encodes. Decoding the stream itself and holding the source, it recomputes the quality; pictures handed to it show only that the figures are theirs (§7). An encode is never a deterministic step: no tier and no replicate claim covers the encoded pictures against the source or against a base. An encode made over a package’s pieces is framed as one floor object per piece, each naming its encoder in derived_from as packaging §7 requires in its paragraph 7.5 (§9). No new transport. The reference implementation is the platform_encode module of wai-rs (feature platform_encode), the wai encode avc|hevc, wai encoders and wai encode-record verify commands, and wai-pack encode-rung and wai-pack verify-rung; the corpus is encode-conformance/, and its second implementation is encode-conformance/encode_verify.py. Keywords MUST, MUST NOT, SHOULD, MAY are RFC 2119/8174.

1. Scope

In scope: what an encode is handed and how a ladder rung’s pictures are made (§4.1, §4.2); the shape of the elementary stream (§4.3); the encoder interfaces by role and the identity each reports (§3, §5); the encode record and its signature (§6); its verification (§7); the energy and the quality of an encode (§8); an encode over a package’s pieces (§9); conformance and measurement (§10).

Out of scope: choosing an encoder’s coding tools, which is the encoder’s; any claim about an encoder’s rate and distortion beyond the quality of one stream (§8.3), which a record states and never compares; any encoder written for WAI. The record states what the encoder made, and a verifier checks the bytes against it.

2. What WAI writes, and what it does not

2.1 WAI writes no AVC or HEVC encoder and ships none. The reference implementation links no encoder: it loads the operating system’s media framework, the video acceleration API’s library, the GPU driver’s encode library, or a software library at a path the user names, each at run time, and a build of it runs on a host without any of them and says which is missing.

2.2 Patent position, by mechanism. Both standards’ essential patents are licensed for royalties (SPEC §5, Broadcast and streaming codecs: patent-pool). An encoder an operating system or a GPU driver provides is supplied by the device’s maker with the device, under that maker’s terms. A software library the user names is obtained by the user from its distributor, separately from WAI, under the terms that distributor states, which may cover the royalties for some uses and not for others. This extension states which encoder made a stream (§5); it states nothing about whether a use of it is licensed. A deployer decides that from the encoder’s supplier’s terms and its own use.

2.3 Header syntax under the video acceleration API. That interface leaves the parameter sets and the slice headers to the application, and the drivers reached for this revision emit none unless the application hands them over. The reference adapter writes them (ISO/IEC 14496-10 §7.3.2.1, §7.3.2.2, §7.3.3; ISO/IEC 23008-2 §7.3.2.1 to §7.3.2.3, §7.3.6.1) from the values it gives the driver in its parameter buffers, and chooses each picture’s QP, which it writes in both the parameter buffer and the slice header so the two agree. No picture sample passes through it: the driver’s engine codes every slice’s data.

2.4 Not a deterministic step. An encoder is not a pure function of its input (packaging §11): a hardware engine’s output is fixed by no specification, and the media framework’s hardware encoder was measured making other bytes from the same pictures in each round (§10.3). So no step of a pack or a verify is an encode, no verdict depends on an encoder’s output beyond the digest a record states, and an encoded rendition promises only its capability’s decoder conformance (SPEC §7: wai.video.avc and wai.video.hevc are StandardDefined, so every conforming decoder outputs the same pictures from the stream).

3. Encoder interfaces

An encoder is reached through one of four interfaces. Each record names the one it used in encoder.api.

3.1 A va or gpu-driver encode is a hardware encode. A software encode is not, and codes AVC only in this revision. A platform encode is either, and says which (§5).

3.2 The phone and TV operating system’s codec interface (informative). On the mobile and TV operating system whose media codec interface exposes hardware and software encoders by name, an adapter would: open an encoder for the codec’s MIME type by name, read the name, the canonical name and whether the interface reports it hardware-accelerated for encoder.name and encoder.hardware; configure the codec’s flexible 4:2:0 input, the target bit rate, no B-pictures and no periodic key frame; request a key frame for exactly the pictures the plan names; and read the device’s hardware and system-on-chip identifiers and the operating system’s release for encoder.device and encoder.driver. Its output (the codec’s configuration buffer, then one buffer per access unit) is an Annex B stream held to §4.3 like any other. This revision builds no adapter for it.

4. The encode

4.1 The source

A source is a YUV4MPEG2 stream: 8-bit 4:2:0 (C420, C420jpeg, C420paldv, C420mpeg2, or no C tag), progressive (Ip, I? or no I tag), each side even and at most 16384, its frame rate F<num>:<den> both non-zero, and at least one frame. XCOLORRANGE=FULL makes it full range; anything else is the video range. Each frame is its luma plane, then its Cb and Cr planes, each row-major with no padding. The source’s digest is SHA-256 (FIPS 180-4) over every frame’s three planes, one frame after another, with no frame header.

4.2 A ladder rung’s pictures

A rung asks for a size W × H (each even, from 16 to 8192), a frame rate (the source’s), a target average bit rate in kilobits per second (1 to 1000000) and a range (the source’s). Where the size is the source’s, the encoder is handed the source’s frames. Otherwise each plane is resampled by wai.resample.two-tap, chroma at half the luma size: for an axis of n_in samples resampled to n_out, output sample o reads the source at

p = ((2·o + 1) · n_in · 128) div n_out − 128

in 1/256ths of a sample, clamped to 0 ..= 256 · (n_in − 1); with x0 = p >> 8, f = p & 255 and x1 = min(x0 + 1, n_in − 1), the sample is (s[x0] · (256 − f) + s[x1] · f + 128) >> 8. Rows are resampled first, then columns, each pass rounding to 8 bits. The resampler is a pure function in integers: every host hands its encoder the same samples.

The IDR plan is the frame indices at which the stream has an IDR access unit: sorted, the first 0, each below the source’s frame count. A package’s plan is its pieces’ starts (§9).

4.3 The stream

An encoder’s output MUST be, and a producer MUST refuse to record one that is not:

1. an Annex B byte stream (ISO/IEC 14496-10 Annex B; ISO/IEC 23008-2 Annex B): it begins with zero bytes and a start code prefix; a NAL unit ends where the next three bytes are 00 00 00 or 00 00 01; no NAL unit is empty, holds 00 00 02, or has its forbidden bit set; an HEVC NAL unit’s nuh_temporal_id_plus1 is not 0; every sequence parameter set reads, an AVC one through its VUI (Annex E.1.1) where it has one and an HEVC one through its sub-layer ordering information (sps_max_latency_increase_plus1); and the start of every slice header this section reads (below) reads (encode-stream-malformed);
2. exactly one access unit per source frame, in presentation order (encode-frame-count). An access unit begins at the first of an access unit delimiter, a parameter set, a prefix SEI or the other non-VCL types the standard lists after the previous picture’s slices (ISO/IEC 14496-10 §7.4.1.2.3, its types 6 to 9 and 14 to 18; ISO/IEC 23008-2 §7.4.2.4.4, its types 32 to 35, 39, 41 to 44 and 48 to 55), or at a slice whose first_mb_in_slice is 0 (AVC; the first syntax element of its slice header) or whose first_slice_segment_in_pic_flag is 1 (HEVC; the first bit). NAL units after the last picture’s slices that begin an access unit holding no slice are encode-stream-malformed, checked with item 1;
3. an access unit’s slices all IDR or none (encode-stream-malformed); no random access point but an IDR (HEVC nal_unit_type 16 to 23 other than 19 and 20); and an IDR access unit (AVC nal_unit_type 5; HEVC 19 or 20) at exactly the plan’s frames (encode-keyframe-mismatch);
4. every IDR access unit carrying the sequence and picture parameter sets (and the video parameter set for HEVC), the same bytes in the same order as the first IDR access unit’s; no other access unit carrying parameter set bytes the first IDR’s do not; no access unit carrying a sequence parameter set other than the stream’s first; and no access unit before the first sequence parameter set (encode-parameter-sets);
5. 8-bit 4:2:0 in one colour plane; progressive, which for AVC is frame_mbs_only_flag 1 (this revision reads no HEVC field signalling); a single layer: no AVC NAL unit of type 14, 15, 20 or 21, and HEVC nuh_layer_id 0 throughout; and AVC pic_order_cnt_type 0 or 2, the types this revision reads (encode-stream-unsupported);
6. with no reordering: HEVC sps_max_num_reorder_pics of the highest sub-layer 0; AVC the VUI’s max_num_reorder_frames 0 where the SPS has one, and, for pic_order_cnt_type 0, each access unit’s top field order count (§8.2.1.1: PicOrderCntMsb + pic_order_cnt_lsb, from the first slice’s pic_order_cnt_lsb and the previous reference picture’s, both reset to 0 at each IDR) above the one before it since the last IDR (encode-stream-reordered). The slice header is read only as far as pic_order_cnt_lsb; this revision does not read dec_ref_pic_marking, so a stream whose pictures carry memory_management_control_operation 5 may be refused here;
7. of the rung’s size: the sequence parameter set’s cropped picture is W × H (AVC frame cropping, HEVC conformance window), and where an AVC VUI signals video_full_range_flag it is the rung’s range (encode-sps-mismatch).

Item 1 and item 2’s count are checked over the whole stream first; then items 3 to 6 access unit by access unit, in stream order, each access unit’s items in that order; then item 7. The first that fails is the reason. They hold the stream to what a piece of a package needs: each piece starts at an IDR access unit that carries its parameter sets, so it decodes with nothing outside it, and access unit i is the picture of frame i.

5. The encoder’s identity

5.1 An encode names its maker with six strings and one flag, each as the interface reports it at run time, read as the adapter documents:

5.2 A producer MUST NOT state an identity it did not read from the interface. Where an interface reports nothing for a member, the adapter writes what it read instead and says so in the string; no member is empty.

5.3 A runtime-loaded library is refused at load unless it is of the interface version the adapter was written for: its structures may differ between versions. The record names the file loaded by its SHA-256, so a relying party can hold it to the distributor’s published digest.

6. The encode record

6.1 Members

The record is a JSON object (RFC 8259) read as contribution §2 reads a record: strict JSON (no member named twice in one object, at most 32 levels), integers unsigned, decimal, with no sign, fraction, exponent or leading zero and at most 2^53 − 1, no other number, no boolean; byte strings in lowercase hexadecimal; a term 1 to 64 bytes of a–z, 0–9, -, _ and .; a date-time RFC 3339 in UTC, YYYY-MM-DDTHH:MM:SS, at most nine fraction digits, then Z, its day one its month has in the proleptic Gregorian calendar and its second at most 60; a decimal a string of 1 to 39 decimal digits with no leading zero but 0 itself, an integer below 2^128; a signed decimal a decimal, or - and a decimal other than 0, an integer from −2^32 to 2^32. It has exactly these members, at every level, none missing and none added, but quality: a record with no such member, as one written before the member was, reads as a record whose quality is null does, and neither states any figure (§8.3.2). A record that does not hold to this, or a member of another type or encoding (any quality that is neither null nor an object of §8.3’s members among them), or outside the fixed words the table gives kind, hardware, range and tier, is record_malformed. Every other set or range of values is a §7 step’s, and refused with that step’s reason.

6.2 Signature and digest

sig    = Ed25519(signer_key, "wai:video-encode\x01" || JCS(record without "sig"))
digest = SHA-256("wai:video-encode-record\x01" || JCS(record))

JCS is RFC 8785. The signature is verified strictly (SPEC §7 Signatures): a key that fails step 1 or 2 is bad_key, a signature that fails a later step bad_signature. The record’s text as the reference writes it is its JCS form. The signer is whoever ran the encode; the record is that signer’s statement of what the interface reported (§5.2).

7. Verification

A verifier checks, in order, and the first that fails is the reason:

1. the record reads (§6.1) (record_malformed);
2. its signature (§6.2) (bad_key, bad_signature);
3. capability is wai.video.avc or wai.video.hevc (encode-capability);
4. the identity: name, version, device and driver each hold a character other than Unicode White_Space (encode-identity-incomplete); api is one of §3’s; library_sha256 is present exactly for software; a software encode is hardware "no" and of wai.video.avc; a va or gpu-driver encode is hardware "yes" (encode-identity-inconsistent);
5. the settings and the source: the rung’s width and height even and from 16 to 8192, the source’s even and from 2 to 16384; both rate members non-zero and at most 2^32 − 1; kbps from 1 to 1000000; at least one source frame; and resample none exactly where the rung’s size is the source’s, wai.resample.two-tap otherwise (encode-settings-invalid);
6. the IDR plan: its first entry 0, each above the one before, the last below source.frames; and, where package is not null, its pieces’ starts equal to the plan, each piece of at least one frame and starting where the one before it ended, their frames summing to source.frames (encode-plan-invalid);
7. the energy, where it is not null (§8.1) (encode-energy-invalid, encode-energy-coverage);
8. with the stream held: its SHA-256 and length are stream.sha256 and stream.bytes (encode-stream-mismatch); it holds to §4.3 for source.frames pictures and the plan, its reasons as there; its access units number stream.units (encode-frame-count); its SPS’s cropped size is the settings’ width × height, its profile, level and tier stream’s, and an AVC VUI’s signalled range the settings’ (encode-sps-mismatch);
9. with the source held: it reads as §4.1 says, its digest is source.sha256, its width, height and frame count are source’s, its frame rate’s numerator and denominator, as its header writes them, are the settings’ fps_num and fps_den, and its range is the settings’ (encode-source-mismatch);
10. with the package and the floor objects held, §9.3 (encode-package-mismatch);
11. with the source and pictures held, where quality is not null: the pictures are source.frames pictures of the settings’ width × height, their SHA-256 is quality.decoded_sha256, and each of sse_y, sse_cb, sse_cr and ssim_y_q32 is the figure §8.3 computes from them and the pictures the encoder was handed (encode-quality-mismatch).

Steps 8 to 11 are made only where the verifier holds what they read; a verdict names which it made. Nothing in them re-encodes: the source is held to its digest, the stream to its digest and its shape, and the pictures to their digest.

Step 11 reads pictures, and only a decode ties pictures to a stream: quality.decoded_sha256 is the signer’s statement of what the stream decodes to, and a signer can state any figures and supply pictures that give them. So a verdict on a record stating figures also names what they rest on:

A relying party MUST NOT read a figure as the stream’s on a verdict other than decoded. A record stating no figures has no step 11 and no such word, whatever pictures are held.

8. Energy and quality

8.1 The figure

energy restates a measured figure with the members jwp-receipts §2.4.5 gives an energy claim, and three of this extension’s own:

It is held to jwp-receipts §2.4.5’s rules 1 to 3, read as written there: a non-zero figure; a class of energy-measurement §2 other than HwShunt; the class’s evidence whole, including the resolution floor joules_micro × relative_ppm ≥ 288 676, an OnChipCounter’s filtering state of On, Off or Unknown, and a CalibratedInstrument’s non-blank calibration reference; and to a coverage of Whole or Partial, an attribution of the three, and fabrics as the table says (encode-energy-invalid). A hardware encode’s figure whose fabrics names neither gpu nor media counts none of the engine that coded the pictures, so it MUST be Partial (encode-energy-coverage). A relying party MUST NOT report a Partial figure as the whole cost of the encode.

8.2 How the reference measures it

The figure is the median of an odd number of rounds (at least three) of the same encode, after one unmetered round that loads and warms the encoder. A round’s figure is a counter’s advance over the encode (task), or energy-measurement §3’s marginal: the advance over the encode less the mean power over an idle window just before it, times the encode’s length (bracket); a round whose marginal is not above zero, or whose counter fails a read, makes the whole figure absent rather than estimated. The declared uncertainty is the rounds’ spread read as rectangular, (max − min) / (2·√3) relative to the median, rounded up, or energy-measurement §2.3’s rounding floor if that is larger; its window is the median round’s. The class is OnChipCounter with filtering Unknown, and the coverage Partial: no counter the reference reads sees all of a host’s energy.

The table is the reference’s practice, not a rule a verifier applies: §8.1 is. No counter is divided among its users by busy time. A task figure counts none of a hardware engine’s draw, since the operating system gives an unprivileged process no account of it; a bracket figure on a host other work shares is machine-wide, and its rounds’ spread says how much that work moved it.

8.3 Quality

A record whose signer decoded the stream states the quality of the decoded pictures against the pictures the encoder was handed (§4.2) in quality, an object of exactly:

The decoded pictures are source.frames pictures of settings.width × settings.height, 8-bit 4:2:0. The handed pictures are the source’s frames where resample is none, and their wai.resample.two-tap resampling to the rung’s size (§4.2) otherwise.

8.3.1 A figure of the stream. Every conforming decoder outputs the same pictures from the stream (§2.4: StandardDefined), and the figures are integers computed from those pictures and the handed ones alone. So the figures a stream gives are the same whichever conforming decoder made the pictures, and a verifier that decodes the stream itself recomputes them exactly (§7, the verdict decoded). A record signs them for that reason. Pictures handed to a verifier show only that the record’s figures are theirs: nothing but a decode ties them to the stream (§7, the verdict handed). The time and the energy of an encode are figures of the encoder, the host, its load and its counter, and §8.1, §8.2 and §10.3 state them as such.

8.3.2 A record whose signer did not measure the stream’s pictures, because it did not decode the stream or its decode gave no pictures to measure, states quality null: the encode stands, and the record says nothing of its quality. The reference’s wai_encode_measure writes the figures from the pictures the platform’s decoder makes, or from pictures another conforming decoder made, which it is handed (§10.3). PSNR, 10·log10(255²·N / sse) over a plane’s N samples, is derived from the sums for display only, as staged-measurement §4 derives it in its paragraph 4.7, and a sum of 0 has no finite PSNR and shows as exact; a record carries the integers. The figures state the distortion of one stream against the pictures it was made from; this extension compares no figure with another.

8.3.3 A record given figures after it was signed is a new statement: its signer signs it again, and its issued_at is when (§6.1). Another key does not add to a record: the record is its signer’s (§6.2).

9. An encode over a package’s pieces

9.1 The rendition

An encoded rendition of a package (packaging §11) is one encode of a video component’s source whose IDR plan is the component’s pieces’ starts, as its stage index lists them (§6.2 there), and whose rung is named by a term, its rung id. Each piece is framed as one floor object (packaging §5.2, §7.2): a WAI1 envelope (SPEC §2) whose manifest is the JSON text, with no whitespace and its members in this order,

{"wai":"1.0","media":"video","intent":"replicate","model_requirement":{"capability":C},
 "conditioning":{"kind":K},"derived_from":{"motif":M,"motif_capability":MC,
 "renderer":R,"settings":D},"target":{"frames":F,"h":H,"w":W}}

with C the capability, K avc or hevc, F the piece’s frames, H and W the rung’s height and width, each string written as JCS writes it (RFC 8785 §3.2.2.2), and the derived_from members:

• motif: the piece’s base object’s content hash, the stage index’s entry of role base and layer 0 for that piece, as 64 lowercase hexadecimal digits; motif_capability: its capability;
• renderer: <encoder.name>@<encoder.version>;
• settings: BLAKE3("wai:render-settings\x01" ‖ JCS(S)), with S the object {"source": "encoded", "api", "hardware", "device", "driver", "library_sha256", "stream_sha256"}, each member but source the record’s encoder member of that name, and stream_sha256 the record’s stream.sha256; the digest written as 64 lowercase hexadecimal digits.

So each object names the encoder and its version in renderer (packaging §7.5) and binds its device and driver through settings, which any verifier holding the record recomputes. Its payload is its piece’s access units as NAL units each after the four bytes 00 00 00 01, in the order the stream holds them: the stream’s own NAL units, re-framed with one start code length, beginning with the piece’s IDR access unit and its parameter sets.

9.2 The record’s package

The objects are written objects/<object>.wai, the stream <rung id>.h264 or <rung id>.h265, and the record <rung id>.encode.json, beside the package and not inside it: the package receipt does not list them, and a package made before them is unchanged.

9.3 Verification against the package

With the package receipt’s file, the component’s stage index and the floor objects held, a verifier checks, in order, every failure encode-package-mismatch: the receipt file’s SHA-256 is receipt_sha256; the stage index’s pieces, in order, have the record’s starts and frame counts (a video component’s timebase unit is one frame, packaging §2), and each piece’s one entry of role base and layer 0 has the record’s motif; and each piece’s object is present, its content hash is object, it is a WAI1 envelope with exactly §9.1’s manifest for this record and piece, and its payload is §9.1’s bytes from the held stream.

A sink that decodes an encoded rendition decodes each object’s payload as its capability’s stream; the record tells it who made the bytes, and nothing more.

10. Conformance and measurement

10.1 The corpus. encode-conformance/ holds small elementary streams made by encoders through each interface (fixtures, pinned by their SHA-256 in the corpus’s manifest and never regenerated, since no encoder is a pure function), the source they were made from, the pictures a conforming decoder made from one of them (a fixture too, pinned in decoded.json), and records generated reproducibly over them from a fixed-seed key with a fixed issued_at: accepted cases, among them a record with quality over a resampled rung, one stating null, and records with no such member, and negative controls each refused with its reason, among them that record with each figure one away from the pictures’ and with another’s pictures; and an encoded rendition of a packaging golden with its objects, accepted and mutated. A case with pictures states how the verifier came by them, decoded or handed, and an accepted record stating figures states §7’s verdict. The pinned pictures stand in for a verifier’s own decode in a case of decoded, since §10.2 holds them to what a conforming decoder makes of the stream, and a verifier with a decoder may decode the stream instead. The corpus records what pictures handed over cannot show: a record stating the perfect score of the encoder’s own input, which its stream does not give, is accepted as handed with that input (handed/, generated) and refused as decoded. wai-rs tests/platform_encode.rs requires the generator to reproduce the corpus byte for byte and every case to get its outcome and its verdict; wai-pack tests/encode_rung.rs does the same for the rendition. The second implementation, encode-conformance/encode_verify.py, is written from this text: it shares no code with wai-rs or wai-pack, reads the Annex B stream, its access units and its parameter sets itself, decodes nothing, resamples the source and recomputes every quality figure itself, verifies signatures with WAI’s strict Ed25519 (claim-conformance/_ed25519.py) and content hashes with BLAKE3 (claim-conformance/_blake3.py), and mutates copies of the corpus and requires every copy to fail.

10.2 Decoder conformance. Each corpus stream, and each stream the reference encoders made for §10.3, decodes in two independent conforming decoders, a hardware decoder and a software one, to the same pictures byte for byte, as StandardDefined requires.

10.3 Measurement. wai_encode_measure encodes a source through one interface at a rung, rounds as §8.2, and decodes the result with the platform’s decoder, or reads the pictures another conforming decoder made, to write the record’s quality (§8.3), from which it prints PSNR for display (luma, each chroma plane, and the 6:1:1 weighted mean of their squared errors) and which pictures it read. With no pictures to measure it writes the record with quality null and says why (§8.3.2). Its time and energy figures are informative: each is of the encoder, the host, its load and its counter at the time it was taken, and none is compared with a figure taken under another counter.

11. Relationship to other extensions

• packaging §7, in its paragraph 7.5, requires a floor made by an encoder that is not a pure function of its input to name the encoder and its version; §9 here is how an AVC or HEVC rendition over a package’s pieces does it. Packaging §7.1’s floor remains a capability of SPEC §5’s mandatory floor or recommended set: an encoded rendition is beside it, not in its place.
• energy-measurement gives the acquisition classes, the declared uncertainty and the bracketed marginal (§2, §3); jwp-receipts §2.4.5 gives the members and rules §8.1 restates.
• SPEC §5, Broadcast and streaming codecs, registers wai.video.avc and wai.video.hevc, their payload (the Annex B byte stream) and their licence class.

12. Reasons

13. Security considerations

• A record is its signer’s statement. It names what the interface reported; a signer can name an encoder that did not run. The stream is checked, not the claim of who made it: a relying party that must know the maker trusts the signer, or runs the encode itself.
• A runtime-loaded library is code the user chose. The adapter refuses a library of another interface version and states the digest of the file it loaded; it does not check the file against any list. A deployer that must hold the library to its distributor’s published digest compares library_sha256 with it.
• Quality is the signer’s statement until a verifier decodes the stream. A verifier that decodes the stream it holds with a conforming decoder recomputes every figure from what it decoded and the source, and its verdict is decoded (§7). Pictures handed to it, whose digest is decoded_sha256 and which give every figure, show only that the figures are theirs: a signer can state any figures and supply such pictures, so that verdict is handed, and of the stream the figures stay their signer’s.
• A stream is checked before it is recorded. §4.3 is applied by the producer before it signs, and again by every verifier holding the stream, so a record never names a stream whose pieces do not each start at a self-contained IDR access unit.