This page is the extended test corpus for Phase 4 from-scratch §3 Step 1, surfaced by Phase 5 review Q4. Sonnet's Q4 argument: bbb_1080p30_h264.mp4 covers ~30 % of YouTube reality. The other ~70 % includes profile and scan-type combinations that hantro most likely fails on, with silent corruption being the worst-case failure mode (silent corruption on MBAFF in particular).

This corpus is the gate against which Step 1 is declared “complete”. A Step 1 build that passes bbb but silently corrupts MBAFF or long-GOP content is not a Step 1 done-state.

Download and inspect 5 representative clips spanning what an actual Brave / VS Code user encounters:

1. R1 (recent 1080p upload). Recent 30/60-fps user video, 1080p resolution. Default for most modern YouTube content.
2. R2 (older SD upload, mobile-source). YouTube clip from 2010-2014 at SD resolution, often Baseline Profile encoded for mobile devices of that era.
3. R3 (broadcast news). News clip from a major broadcaster (BBC, CNN, ARD, etc.) — frequently broadcast-sourced, possibly MBAFF / interlaced-flagged even when uploaded at “1080p”.
4. R4 (live gaming stream archive). Twitch-archive or YouTube-Gaming upload — typically high-bitrate, long-GOP, single-slice-per-frame.
5. R5 (4K downscale). User-uploaded 4K content downscaled by YouTube to 1080p — different rate-control behaviour, larger reference frames.

Inspection command per clip:

mediainfo --Inform="Video;%Format_Profile%,%Height%,%ScanType%,%Format_Settings_GOP%,%Format_Settings_RefFrames%,%BitRate%\n" R*.mp4

Expected output: format profile (Baseline / Main / High / High-10 / High-4:2:2), scan type (Progressive / MBAFF / Interlaced), GOP length, ref-frame depth, bitrate. The point is to surface at least two profile/scan-type combinations the campaign clip bbb does not exercise.

The Joint Video Team H.264 conformance bitstreams are publicly downloadable and cover exactly the edge cases YouTube can deliver. URL: https://www.itu.int/wftp3/av-arch/jvt-site/draft_standard/ (or mirrors) for the 14496-10 conformance test set. Typical filenames: AUD_MW_E.264 (access-unit delimiter), BA1_FT_C.264 (Baseline annex B), CAFR1_TOSHIBA_E.264 (CABAC field referencing), etc.

Pull a curated subset (5-8 clips) covering:

1. Baseline Profile — no CABAC, different slice-type handling. JVT clip e.g. BA1_FT_C.264.
2. Main Profile — CABAC, no FMO/ASO, different deblocking. JVT clip e.g. CAMP_MOT_MBAFF_L30.264.
3. MBAFF — macroblock-adaptive frame-field. The single most likely silent-corruption case for hantro because MBAFF changes the reference-frame addressing model. JVT clip e.g. CAMP_MOT_MBAFF_L30.264, CAMA1_VTC_C.264 or CAFR1_TOSHIBA_E.264.
4. Long GOP, no IDR for 10+ s — tests the reference picture list (dpb[] in V4L2_CID_STATELESS_H264_DECODE_PARAMS). Pull or generate. (ffmpeg -i input -c:v libx264 -g 240 -keyint_min 240 -bf 3 -refs 4 long_gop.264 produces a 240-frame GOP test clip from any source.)
5. Slices not aligned to tile boundaries — encoder-specific. Pull from JVT or generate via x264 with explicit slice-count.
6. Annex B start codes inside MP4 container — non-conformant but common. Pull from a real-world failure case if available; otherwise transmux a clean clip and remove the AVCC length-prefix to simulate.
7. Scaling-list-equipped clip — clip with explicit scaling_matrix4x4 / scaling_matrix8x8 in PPS. JVT clip e.g. SL1_SVA_B.264.
8. High 4:2:2 or High 4:4:4 — likely rejected at format-negotiation by hantro. The point is to characterise the failure mode (clean ENOTSUP vs. silent corruption).

A Step 1 build is “complete” when:

1. All 5 YouTube clips R1–R5 decode without silent corruption. Either the clip plays correctly, or libva returns an explicit failure (VA_STATUS_ERROR_UNSUPPORTED_PROFILE / VA_STATUS_ERROR_INVALID_VALUE). Silent black frames or visibly garbled output is a Step 1 failure.
2. vainfo LIBVA_DRIVER_NAME=v4l2_request LIBVA_V4L2_REQUEST_VIDEO_PATH=/dev/video1 enumerates at least Baseline + Main + High + ConstrainedBaseline H.264 profiles.
3. MBAFF clip: decode produces correct pixel output OR returns an explicit ENOTSUP-class error code. Silent MBAFF corruption blocks Step 1 completion.
4. Long-GOP clip: all frames in the GOP decode correctly; dpb[] entries don't drift. Visible drift after second 1 of the long-GOP indicates a reference-picture-list bug.
5. Annex B in MP4: either decodes or returns explicit parse error. Silent SPS/PPS extraction failure is a Step 1 failure.
6. High 4:2:2 / 4:4:4: rejected at VA_STATUS_ERROR_UNSUPPORTED_PROFILE. Silent acceptance with 4:2:0 fallback is a Step 1 failure.

The “silent corruption is a hard failure” principle: silent decoder failures disguise themselves as configuration / rendering bugs and waste days of the campaign's time. A clean, explicit unsupported-feature error is better than a graceful-but-wrong fallback.

Phase 7 verification (post-Step-1 plus optional Step 2) re-runs the strace + perf-stat instrumentation on Brave + each of the 5 YouTube clips R1–R5 plus the bbb reference clip, and writes a per-clip row to metrics.csv as phase7_verify_brave_<clip-tag>. Phase 1 revised C1-C4 must hold for all the in-corpus YouTube clips that the Step 1 gate also passes.

If the Step 1 gate passes a clip but Phase 7 verification fails C1-C4 on that clip, the path engages but is too slow — that is a Phase 7 → Phase 4 loopback (Phase 1 revised §5).

• Phase 4 from-scratch — §3 Step 1 references this corpus document for completion gate.
• Phase 5 review §Q4 — the source argument for extending the corpus beyond bbb.
• JVT H.264 conformance test set — https://www.itu.int/wftp3/av-arch/jvt-site/draft_standard/ (or community mirrors).
• fourier README L319-340 — original test-corpus pointer (referenced by Phase 4); Sonnet's Q4 critique noted the lines themselves are opaque outside fourier's own context. This corpus extends and supersedes them.

Test corpus ends here. Step 1 implementer pulls the JVT subset and the 5 YouTube clips at Step 1 start; runs each through the libva-v4l2-request-ohm-gl-fix build at Step 1 completion; documents per-clip pass/fail in a Phase 6 implementation log.