docs(bench): v0.13 — per-shot CRF steering is an honest negative on the CRF axis#34
Merged
Merged
Conversation
…he CRF axis Tested the ADR-0132 per-shot complexity-budget lever as a simple hand-tuned mapping: extract per-frame complexity via the lavfi.pelorus.* metadata (ADR-0136), aggregate per shot, bias x265 rate-control per shot via --zones. Real ffmpeg + libx265, 3-shot BBB clip (~2x complexity spread), RD curve, BD-rate vs flat CRF. (First attempt used zones=...,crf= which is invalid — x265 zones support only q= and b=; corrected to b= bitrate factors.) Result: per-shot redistribution LOSES — VMAF BD-rate +8.81%, SSIMULACRA2 +7.35% (~5% more bits AND slightly lower quality at every CRF). Root cause: CRF is already a constant-quality target, so x265 allocates more bits to complex shots on its own; pushing beyond that leaves the quality/bitrate convex hull. The per-shot win in the literature is for budget/VBR or per-shot resolution, not pure CRF. 4th measured negative in the "compete with the encoder's mature rate-control" space (after fp16, subgroup, perceptual-AQ) — Pelorus's edge is preprocessing, not out-guessing CRF/2-pass/mbtree. ADR-0132 stays Proposed; the lever now depends on the autotune (ADR-0106) beating flat CRF against a low ceiling. The shipped ADR-0136 metadata path is the durable enabler that made this measurable. No code change (orchestration experiment, scripts only). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Documents an honest negative: per-shot CRF steering (the ADR-0132 lever), tested as a simple complexity→
b=-zone mapping, loses vs flat CRF. No code change — this is the measurement (bench-results.mdv0.13).Method
lavfi.pelorus.*frame metadata (ADR-0136), aggregate per shot (a 3-shot BBB clip, real ~2× complexity spread: 0.065 / 0.052 / 0.032).--zonesb=factors (complex shotb=1.16, simpleb=0.82).(First attempt used
zones=…,crf=— invalid; x265 zones support onlyq=/b=. Corrected.)Result
Per-shot redistribution spent ~5 % more bits and scored slightly lower at every CRF.
Why
CRF is already a constant-quality target — x265 allocates more bits to complex shots on its own. Pushing beyond constant-quality leaves the quality/bitrate convex hull. The per-shot win in the literature is for budget/VBR allocation or per-shot resolution, not pure CRF.
This is the 4th measured negative in the "compete with the encoder's mature rate-control" space (after fp16, subgroup, perceptual-AQ): Pelorus's edge is preprocessing the source, not out-guessing CRF / 2-pass / mbtree. ADR-0132 stays Proposed; the lever now hinges on the autotune (ADR-0106) beating flat CRF against a low ceiling. The durable result is the shipped ADR-0136 metadata path, which made this measurable from the shell.
🤖 Generated with Claude Code