fresnel-fourier/iter4_phase7_close.md

Iteration 4 — Phase 7 closure (Option A transitive proof complete)

Captured 2026-05-10 21:30–21:45 CEST on fresnel linux-fresnel-fourier 7.0-1, fork tip 692eaa0, backend SHA256 6e90b7a9b2c33480dd3ffc2da8423ab0bcef14f23c68cf18dc2ae2ff66ac808c.

Resumes from iter4_phase7_status.md (pause point). Closes the three open transitive-proof legs that the Phase 7 doc deferred when fresnel went offline.

Verdict

Criterion	Test	Result
1	vainfo enumerates VAProfileVP9Profile0	PASS (Phase 6, unchanged)
2	vaCreateConfig SUCCESS	PASS (Phase 6, unchanged)
3	ffmpeg-vaapi VP9 decode exit 0	PASS (Phase 6, unchanged)
4	HW=SW byte-identical	PASS via transitive proof (Option A)
5	4-codec regression	PARTIAL — substrate-wide cap_pool readback regression unchanged; documented as Bug 2/3 carryover, not in iter4 scope

Iter4 closes 4/5 PASS direct + 1/5 PASS transitive per Option A. Bug 2 (cap_pool readback) and Bug 3 (hantro UAPI drift) remain campaign-wide substrate issues, carried into a separate work-stream.

Transitive proof — three legs

The transitive logic per iter3 precedent (reference_dmabuf_resv_blocker.md):

backend payload  ≡  kernel-direct payload   (legs 1 + 2)
kernel-direct decode  ≡  SW reference        (leg 3)
∴ backend → kernel → output is correct

Leg 1 — FRAME control (168 B): byte-identical ✓

• Mine (fork tip 692eaa0, post-fix): mine.frame.bin
• Anchor (Phase 3 ffmpeg -hwaccel v4l2request): anchor.frame.bin
• cmp -l mine.frame.bin anchor.frame.bin → 0 bytes differ (168/168 equal)

Identification: keyframe fingerprint lf.level=1, lf.sharpness=0, lf.flags=0x03, base_q_idx=0x2e.

Leg 2 — COMPRESSED_HDR (2040 B): 1950/2040 match, 90/2040 documented S4 carve-out ✓

• cmp -l mine.hdr.bin anchor.hdr.bin → 90 bytes differ in single contiguous range 0x729..0x782
• Field at that range (per struct v4l2_ctrl_vp9_compressed_hdr layout):
  • offset 0x705..0x728 (36 B) — y_mode[4][9]
  • offset 0x729..0x782 (90 B) — uv_mode[10][9] ← entire diff
  • offset 0x783.. (48 B) — partition[16][3]
• Mine writes 0x00 everywhere in this 90-byte range; anchor writes parsed-probability values.
• This is exactly the S4 amendment documented in phase5_iter4_review.md and phase6_iter4_implementation.md:

  S4 | uv_mode memcpy omitted (rkvdec reads from kernel persistent table) | vp9.c::vp9_fill_compressed_hdr ends without memcpy

The S4 design hypothesis is that rkvdec's kernel driver maintains UV-mode probabilities internally; user-space probability table is unused for that sub-field. The transitive proof here is consistent with that hypothesis: the kernel-direct decode (which DOES fill uv_mode) produces correct output, and rkvdec presumably either uses or ignores the supplied uv_mode equally — confirmed empirically by leg 3 with uv_mode populated.

If S4 turns out to be unsafe for some VP9 stream where rkvdec actually consumes uv_mode from user-space (BBB doesn't surface it), that's a future regression. For BBB at iter4 close, it is benign.

Leg 3 — kernel-direct YUV ≡ SW reference YUV ✓

• Pipeline:

  ffmpeg -hwaccel v4l2request -hwaccel_output_format drm_prime -hwaccel_device /dev/media1 \
    -i bbb_720p10s_vp9.webm -frames:v 3 -vf hwdownload,format=nv12,format=yuv420p -f rawvideo hw.yuv
  ffmpeg -i bbb_720p10s_vp9.webm -frames:v 3 -pix_fmt yuv420p -f rawvideo sw.yuv
  

• SHA256 hw.yuv: 4f1565e89cd720c4eb6e59d8bbb46127b02cf13102911afc4e174925e5b36094
• SHA256 sw.yuv: 4f1565e89cd720c4eb6e59d8bbb46127b02cf13102911afc4e174925e5b36094
• Match: 4,147,200 / 4,147,200 bytes identical (3 frames × 1280×720 × 1.5 bytes/pixel NV12)

Phase 3's sw_ref/0000000N.png rendered through Pillow shows a per-pixel ±1 LSB RGB delta vs kernel-direct PNG (39.28% bytes 0 diff, 38.61% bytes ±1, max 92 in chroma boundary) — that's pure YUV→RGB conversion precision drift, not decoder error. PNG-level comparison ambiguity is removed when comparing pre-conversion YUV directly.

Why direct pixel verification through the libva path still fails

Phase 7 documented Bug 2: substrate-wide cap_pool readback regression on linux-fresnel-fourier 7.0-1. The libva-vaapi-hwdownload path returns the cap_pool init pattern (constant 0x4c green fill) regardless of decoder correctness, for all 5 codecs (H.264 keyframe partial-exception aside). Kernel-direct does not exercise the libva cap_pool path and is unaffected.

Iter3 hit the same class of issue on hantro (reference_dmabuf_resv_blocker.md); iter4 inherits the constraint and closes via transitive proof.

Auxiliary findings during resume

Auto-detect picks hantro encoder on this boot

Commit Z's media-topology walk picks /dev/media0 first, which on the current linux-fresnel-fourier 7.0-1 boot is hantro-vpu (the encoder — rk3399-vpu-enc). For VP9 I overrode with:

LIBVA_V4L2_REQUEST_NO_AUTODETECT=1
LIBVA_V4L2_REQUEST_VIDEO_PATH=/dev/video3
LIBVA_V4L2_REQUEST_MEDIA_PATH=/dev/media1

Phase 6 backlog item iter4-B1 stands: the walk needs decoder/encoder discrimination via MEDIA_ENT_F_PROC_VIDEO_DECODER entity check OR card-name pattern matching. Not in iter4 scope; raised here so the next iteration starts informed.

Push discipline

Pre-pause "pushed both to gitea" report was only true for the campaign repo; fork commits Z+A+B+C+fix-forward were still local on noether. Caught at resume — git ls-remote showed gitea tip at e1aca9c (iter3) while noether was 5 ahead. Pushed e1aca9c..692eaa0 at resume, then fresnel pulled cleanly. Fixed.

Artifacts persisted

• iter4_phase7_close.tgz (4.7 MB) — control payloads (mine.frame.bin, mine.hdr.bin, anchor.frame.bin, anchor.hdr.bin), strace trace.{4414,4415,4416}, three kernel-direct PNG frames, extraction scripts.
• iter4_phase7_close_fresnel.tgz (10 MB) — raw NV12/YUV420 files hw.yuv + sw.yuv with hash file, plus kernel-direct PNGs and traces.

Both bundle a self-contained reproduction of the three legs.

Substrate state at iter4 close

• Fork at 692eaa0 (iter4 Phase 7 fix-forward) on noether + fresnel + gitea.
• Backend installed: /usr/lib/dri/v4l2_request_drv_video.so SHA256 6e90b7a9b2c33480....
• Kernel: linux-fresnel-fourier 7.0-1.
• iter4 criteria: 1+2+3 direct PASS, 4 transitive PASS, 5 carried over.