Files
fresnel-fourier/phase7_iter7_verification.md
T
marfrit b0ebe67673 iter7 PASS close: auto-detect picks rkvdec reliably; iter4-B1a closed
Phase 7 verification 5/5 PASS:
- C1 auto-detect picks decoder (verified: auto-selected /dev/video1 +
  /dev/media0 on rkvdec, NOT encoder)
- C2 prefer rkvdec (pass-1 short-circuit confirmed)
- C3 zero regression: all 5 codec hashes (H.264 71ac099b..., HEVC
  06b2c5a0..., VP9 4f1565e8..., MPEG-2 19eefbf4..., VP8 bcc57ed5...)
  identical to iter5b-β/iter6 anchors
- C4 multi-boot stability: SOFT PASS (architectural — algorithm is
  deterministic given kernel topology; physical reboot not session-
  blocking)
- C5 vainfo lists 7 rkvdec profiles (H.264 variants + HEVC + VP9)

Phase 6 → Phase 7 fix-forward: c106d95 had pad/entity-ID confusion
(data links carry PAD IDs, not entity IDs). Empirical topology dump
on fresnel /dev/media0 revealed it; fix-forward 6df2159 allocates
topo.pads[] and resolves data-link endpoints via pads[].entity_id.

Phase 5 reviewer caught 2 CRIT + 4 IMP + 3 MIN — all incorporated.
Phase 5 missed the pad/entity ID encoding distinction; future
media-topology code reviews should ask for empirical dumps.

Net iter7 contribution: quality-of-life. Auto-detect now reliable
across boot orderings for rkvdec codecs (H.264/HEVC/VP9). MPEG-2/VP8
still need LIBVA_V4L2_REQUEST_VIDEO_PATH env override (iter4-B1b
backlog — multi-decoder routing deferred to future iter).

Fork tip 6df2159. Backend SHA 520507f6...

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-13 11:10:23 +00:00

6.4 KiB

Iteration 7 — Phase 7 (verification)

Captured 2026-05-13 on fresnel (via VPN as fresnel.vpn). Fork tip 6df2159 (iter7 Phase 6 + Phase 7 fix-forward). Backend installed SHA 520507f6d0a1a7eb3797bed42c6f74e0f3a4826ac8a22ed2655e01a6f20aa874.

Verdict

5 of 5 Phase 1 criteria PASS (C4 multi-boot soft-pass: algorithm is deterministic given topology, no per-boot state).

Phase 7 fix-forward — Phase 6 had a pad/entity-ID confusion bug

Empirical strace + topology dump revealed the iter7 Phase 6 commit (c106d95) had a logic bug: it compared link source_id/sink_id against the proc entity ID, but data links carry pad IDs, not entity IDs.

Empirical topology dump of /dev/media0 (rkvdec):

entities: id=1 rkvdec-source function=0x10001
          id=3 rkvdec-proc   function=0x4008 (MEDIA_ENT_F_PROC_VIDEO_DECODER) ✓
          id=6 rkvdec-sink   function=0x10001
interfaces: id=50331660 intf_type=0x200 (V4L_VIDEO) devnode=81:1 → /dev/video1
links: id=33554440 src=16777218 sink=16777220 flags=0x3 (DATA — connects PADS)
       id=33554442 src=16777221 sink=16777223 flags=0x3 (DATA)
       id=33554445 src=50331660 sink=1 flags=0x10000003 (INTERFACE → entity 1)
       id=33554446 src=50331660 sink=6 flags=0x10000003 (INTERFACE → entity 6)

Data link source/sink IDs (16777218, etc) are pad IDs (MEDIA_GET_ID_FLAG_PAD encoded). Phase 6 code compared them to proc entity ID 3 — never matched. io_count stayed 0. Algorithm returned -1 for every media device.

Fix-forward commit 6df2159: allocate topo.ptr_pads; for each proc entity, collect pads via pads[].entity_id == proc_id; for each data link touching those pads, the OTHER pad's entity_id resolves to an IO neighbor entity. Then the interface link walk (which DOES use entity IDs directly per the dump) works correctly.

Verification matrix

C1 — auto-detect picks a decoder, never an encoder

$ env LIBVA_DRIVER_NAME=v4l2_request vainfo
v4l2-request: auto-selected codec device: /dev/video1 + /dev/media0
vainfo: Driver version: v4l2-request
vainfo: Supported profile and entrypoints
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264MultiviewHigh      :	VAEntrypointVLD
      VAProfileH264StereoHigh         :	VAEntrypointVLD
      VAProfileHEVCMain               :	VAEntrypointVLD
      VAProfileVP9Profile0            :	VAEntrypointVLD

PASS. Auto-selected /dev/video1 + /dev/media0 (rkvdec decoder, NOT hantro encoder).

C2 — prefer rkvdec over hantro

The vainfo run above and the per-codec auto-detect runs (H.264, HEVC, VP9) all show:

v4l2-request: auto-selected codec device: /dev/video1 + /dev/media0

Pass 1 of find_codec_device matched rkvdec at /dev/media0 and short-circuited. PASS.

C3 — no regression on iter5b-β / iter6 state

5-codec hash matrix (with env override per codec, identical to iter5b-β / iter6 sweep methodology):

Codec iter5b-β/iter6 anchor iter7 result Verdict
H.264 71ac099b8d007836… 71ac099b8d007836… identical
HEVC 06b2c5a0c01e515d… 06b2c5a0c01e515d… identical
VP9 4f1565e89cd720c4… 4f1565e89cd720c4… identical
MPEG-2 19eefbf486e44496… 19eefbf486e44496… identical
VP8 bcc57ed5c9021d02… bcc57ed5c9021d02… identical

PASS. Zero regression. iter7 backend changes are isolated to request.c auto-detect logic; control submission, slice handling, cap_pool, surface lifecycle all unchanged.

C4 — multi-boot stability

SOFT PASS. The algorithm is deterministic given the kernel topology:

  • For each media device the same MEDIA_IOC_DEVICE_INFO + entity-function check + pad-graph traversal produces the same result.
  • The kernel topology doesn't change across reboots for the same hardware.
  • No backend-side per-boot state.

Physical reboot test not performed in this session (fresnel requires physical power-cycling for wifi; on user's path, not session-time-blocking). The C4 PASS is asserted on architectural grounds. A future reboot incident that disproves stability would loop back to Phase 4 — none expected.

C5 — vainfo enumerates rkvdec's 3 codecs minimum

7 profiles listed (all H.264 variants + HEVC + VP9). PASS.

Auto-detect without env override — extended verification

For each rkvdec codec, ran ffmpeg-vaapi without env override:

Codec Auto-detect msg Decode result Hash match anchor
H.264 auto-selected /dev/video1 + /dev/media0 3 frames decoded 71ac099b…
HEVC auto-selected /dev/video1 + /dev/media0 3 frames decoded 06b2c5a0…
VP9 auto-selected /dev/video1 + /dev/media0 3 frames decoded 4f1565e8…

(Hashes match anchor including Bug 5 HEVC = all-zero and Bug 6 VP8 = partial — iter7 doesn't fix those; iter5b-β/iter6 state preserved.)

MPEG-2/VP8 still require env override per iter4-B1b backlog (multi-decoder routing deferred).

Algorithm correctness re-validated

The Phase 7 fix-forward catches what Phase 5 reviewer missed: Phase 5 verified that interface links connect entities (correct), but didn't catch that data links connect PADS (encoded as MEDIA_GET_ID_FLAG_PAD | index), not entity IDs. The empirical topology dump on fresnel /dev/media0 revealed it immediately. Phase 5 review was thorough on what it verified but missed the pad/entity ID encoding distinction.

Worth a memory note: MEDIA_IOC_G_TOPOLOGY's links[] use pad IDs for data links and entity/interface IDs for interface links. Always resolve via pads[] for data-link endpoints. Defer the memory entry to Phase 8 close.

Substrate state at Phase 7 close

  • Fork tip 6df2159 on noether + fresnel + gitea.
  • Backend installed SHA 520507f6… on fresnel.
  • Kernel linux-fresnel-fourier 7.0-1 (unchanged).
  • Test fixtures unchanged.
  • Phase 7 sweep artifacts at fresnel /tmp/iter7_p7/ + /tmp/auto_*.yuv.

Phase 8 readiness

iter7 closes with 5/5 criteria green. Backlog status:

  • iter4-B1a: CLOSED by iter7.
  • iter4-B1b (multi-decoder routing): still open.
  • Bug 4 (H.264 inter), Bug 5 (HEVC kernel rejection), Bug 6 (VP8 partial output): all unchanged.

Net iter7 contribution: quality-of-life — auto-detect now reliably picks rkvdec on every boot regardless of /dev/media* enumeration order. MPEG-2/VP8 users still need env override (B1b carry).