bench+docs: re-pin the dead benchmark corpus and close the encoder compile gap - #48
Merged
Merged
Conversation
Two gaps that were documented rather than fixed at v0.2.0. Neither closes itself. 1. Encoder TUs are now compile-verified. The SDKs were in fact already installed (oneVPL 2.17 via libvpl, libaom 3.15.0, SVT-AV1 4.1.0) -- the earlier failure was only that configure had not enabled them, and that oneVPL's header is vpl/mfxvideo.h reached via --enable-libvpl, not the bare mfxvideo.h of the older libmfx path. With them enabled, all ELEVEN Pelorus-patched libavcodec translation units build with zero errors and zero warnings, the binary links, and the AVOptions register on exactly the intended encoders: pelorus_me_hints on H.264/HEVC NVENC only, pelorus_film_grain on av1_nvenc only, pelorus_roi across all ten steered encoders, and none on libx264/libvpx-vp9 -- so nothing leaked into a shared option table. 2. The bbb corpus is re-pinned, and this RESETS ITS BASELINE. The previous download.blender.org clip 404s and no mirror serves the same bytes, so fetch-corpus.sh could not run cold. The replacement deliberately preserves the workload SHAPE -- 640x360 yuv420p, 48 frames, an identical 16,588,800-byte decoded .yuv -- so the harness does the same work, but it is a different encode and segment of Big Buck Bunny. Absolute bbb numbers therefore do not carry across 2026-08-30; corpus.lock, benchmarking.md and bench-results.md all say so at the boundary. synth-banding is lavfi-generated and unaffected. Verified cold: fetch-corpus.sh downloads, the sha256 matches, extraction yields 16,588,800 bytes, and the frames carry real moving content (YMIN 23, YAVG ~98, YMAX 255, varying per frame) rather than a black or static title card. Co-Authored-By: Claude Opus 5 (1M context) <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.
The two gaps v0.2.0 shipped as documented rather than fixed. Neither was going to close itself.
1. Encoder TUs are now compile-verified
The SDKs turned out to be already installed — oneVPL 2.17 (via
libvpl), libaom 3.15.0, SVT-AV1 4.1.0. The earlier failure was that configure had not enabled them, and that oneVPL's header isvpl/mfxvideo.hreached through--enable-libvpl, not the baremfxvideo.hbelonging to the olderlibmfxpath.With
--enable-libvpl --enable-libaom --enable-libsvtav1 --enable-nvenc, all eleven Pelorus-patched libavcodec translation units compile with zero errors and zero warnings —qsvenc,qsvenc_h264,qsvenc_hevc,libaomenc,libsvtav1,nvenc,nvenc_h264,nvenc_hevc,nvenc_av1,vulkan_encode,bsf/pelorus_fgs— the binary links, and the AVOptions register on exactly the intended encoders:h264_nvenc,hevc_nvencpelorus_roi,pelorus_me_hintsav1_nvencpelorus_roi,pelorus_film_grainh264_qsv,hevc_qsvpelorus_roilibaom-av1,libsvtav1pelorus_roih264_vulkan,hevc_vulkan,av1_vulkanpelorus_roiThe asymmetry is correct by design —
pelorus_me_hintsis H.264/HEVC-only (AV1 uses a different per-superblock hint struct),pelorus_film_grainis AV1-only — and each lands on exactly those.libx264andlibvpx-vp9carry none, confirming nothing leaked into a shared option table.2. The
bbbcorpus is re-pinned — and this resets its baselinedownload.blender.org404s for the pinned clip (HEAD and ranged GET) and no mirror serves the same bytes, sofetch-corpus.shcould not run on a cold machine.The replacement deliberately preserves the workload shape: 640x360, yuv420p, 48 frames — an identical 16,588,800-byte decoded
.yuv, so the harness does exactly the same amount of work. What changes is the pixels: a different encode and segment of Big Buck Bunny.So absolute
bbbnumbers do not carry across 2026-08-30.corpus.lock,benchmarking.mdandbench-results.mdeach state that at the boundary.synth-bandingis lavfi-generated and unaffected.Verified cold, not assumed:
fetch-corpus.shdownloads, the sha256 matches, extraction yields 16,588,800 bytes, and the frames carry real moving content (YMIN 23, YAVG ~98, YMAX 255, varying frame to frame) rather than black or a static title card.Gates
21/21 fast, changelog in sync. ADR-0143, the rebase notes and the migration brief all updated to record the closed gap.
🤖 Generated with Claude Code