ADR-1880: Format envelope and device-targeted scoring in the 1.0.0 candidates¶
- Status: Accepted
- Date: 2026-10-05
- Deciders: maintainer
- Tags: release, rc, roadmap, process, gpu, simd
Context¶
ADR-1868 folded the 2026-10-05 scope into the candidates RC4 to RC9. Two questions were still open the same day. First, how large and how varied an input the first release promises to score correctly: the exactness evidence of RC3 stops at 4K, nothing audits the integer accumulators of the extractors for overflow at 8K or 16K with 16-bit samples, and no table says which resolutions, bit depths, chroma layouts and odd or portrait sizes each backend and device supports. Second, whether device-targeted scoring belongs in 1.0.0: scoring one decoded distorted stream for several viewing conditions (a phone, a tablet, a laptop, a TV, each eye of a VR headset, portrait included), with the target resolution, the scaling and the viewing distance per display height expressed through the options the vmaf_v1.0.16 models already read (the ADM options nvd, normalised viewing distance, and rdh, reference display height).
Decision¶
The candidate numbers stay; their scope grows:
| Candidate | Adds |
|---|---|
| RC3 | An integer-overflow audit of every extractor and twin at 8K and 16K frame sizes with 16-bit samples; 8K cells in the exactness matrix |
| RC5 | Device-targeted scoring: device profiles (phone, tablet, laptop, TV, VR per eye, portrait included), each a target resolution, a scaling and a viewing distance per display height mapped onto nvd / rdh; one decode scored for many targets. A short research pass comes first; the profile table is generated by the RC6 / RC7 table machinery |
| RC6 / RC7 | The GPU (RC6) and CPU (RC7) capability tables also declare the format envelope per backend and device: maximum resolution up to 16K with measured memory limits and tiling where it is needed, bit depths 8 to 16, chroma layouts, odd and portrait sizes. Every row is backed by a test, and the drift check covers the envelope |
| RC8 | Throughput per resolution, 16K included; RC8 measures speed only, the envelope is RC6 / RC7 evidence |
The phase rules of ADR-1341 and ADR-1490 stand: no performance claim before RC8, so the 16K rows of RC6 / RC7 state correctness and memory limits, not speed. This ADR refines ADR-1868 and ADR-1490; it supersedes neither.
Alternatives considered¶
| Option | Pros | Cons | Outcome |
|---|---|---|---|
| Overflow audit and 8K exactness in RC3, the envelope in the RC6 / RC7 tables, 16K throughput in RC8 (chosen) | An overflow is a correctness defect and is fixed with the exactness work; the envelope sits next to the capability facts it depends on and is drift-checked like them | RC3 grows; RC6 / RC7 need large fixtures and measured memory limits per device | Chosen |
| Everything about 8K and 16K in RC8 | Smaller RC3 | An overflow found during benchmarking would reopen exactness after RC3 closed | Not chosen |
| The envelope as prose in the backend guides | No generator work | Not checked against the code; drifts like the hand-kept tables RC6 / RC7 replace | Not chosen |
| Device-targeted scoring after 1.0.0 | Smaller 1.0.0 | The RC9 retrain could not use the device profiles, and the profile table would not reuse the RC6 / RC7 machinery | Not chosen |
Consequences¶
- Positive: 1.0.0 states, per backend and device, which inputs it scores correctly, with a test behind each row; one decode serves every viewing target.
- Negative: RC3, RC5, RC6 and RC7 carry more work; 16K fixtures and per-device memory measurements are needed.
- Neutral / follow-ups: the RC issues (#1721, #1724, #1725, #1885) were updated on 2026-10-05;
AGENTS.md§11,docs/roadmap.mdanddocs/development/release.mdfollow this ADR. Device profiles enter the new API as data (profile name and options), not as new functions (ADR-1852).