Files
fresnel-fourier/iter4_phase7_status.md
T
marfrit f510ac6be5 iter4 Phase 7 pause: fork fix-forward 692eaa0, awaiting fresnel return for transitive-proof closure
Mid-Phase-7 fix-forward landed on fork
(marfrit/libva-multiplanar:692eaa0): unconditional
context_object->h264_start_code = true was prepending 0x00 0x00 0x01
to VP9 slice data, shifting the rkvdec bitstream by 24 bits and
producing silent decode failure. Now gated on
config_object->profile (H.264 + HEVC only).

Empirical verification when fresnel was online: post-fix VP9 keyframe
FRAME control bytes 0-23 byte-match Phase 3 anchor:
  lf.flags=0x03 (DELTA_ENABLED|DELTA_UPDATE) — was 0x01
  base_q_idx=0x2e=46 — was 0x41=65

This is the transitive-proof leg-1 (backend-payload == kernel-direct-payload)
for the iter4 keyframe.

Open verification when fresnel returns:
- Full 168-byte FRAME control diff mine vs Phase 3 anchor
- Full 2040-byte COMPRESSED_HDR control diff
- ffmpeg-v4l2request kernel-direct VP9 decode + hwdownload pixels =
  Phase 3 SW reference (transitive-proof leg-2)

If both legs PASS, iter4 closes 5/5 (4 direct from earlier iters
+ 1 transitive iter4) per Option-A choice.

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

2.7 KiB

iter4 Phase 7 status — paused (fresnel offline)

Where we paused

After surfacing 3 distinct bug classes in Phase 7 verification (criterion 4 + 5 fail), user picked Option A (VP9-only fix, criterion 4 transitive).

Mid-fix, found that Bug 1 (Clause 6 parser bit-misalignment) had a deeper root cause:

  • src/context.c:194 set context_object->h264_start_code = true unconditionally
  • src/picture.c:70 therefore prepended 0x00 0x00 0x01 ANNEX-B start code to ALL slice data, including VP9
  • VP9 has no start codes → kernel rkvdec read garbage uncompressed_header → silent decode failure → CAPTURE buffer stayed at cap_pool init pattern (0x4c green)

Fix landed in fork commit 692eaa0: switch on config_object->profile; set h264_start_code = true only for VAProfileH264* and VAProfileHEVCMain.

Empirical verification when fresnel was online: post-fix VP9 keyframe FRAME control bytes 0-23 byte-match Phase 3 anchor exactly.

  • pre-fix: lf.flags=0x01, base_q_idx=0x41 (bit-misaligned)
  • post-fix: lf.flags=0x03 (DELTA_ENABLED|DELTA_UPDATE), base_q_idx=0x2e=46 (matches anchor)

Open verification when fresnel returns:

  1. Diff full FRAME control payload (all 168 bytes) mine vs Phase 3 anchor — confirm full byte-match (transitive proof leg 1).
  2. Diff full COMPRESSED_HDR control payload (2040 bytes) mine vs Phase 3 anchor — same.
  3. ffmpeg-v4l2request VP9 decode + hwdownload (kernel-direct path, NOT via libva): confirm pixels match Phase 3 SW reference (transitive proof leg 2).
  4. Both legs satisfied → criterion 4 transitive PASS.

If transitive proof PASSES, iter4 closes with:

  • Criterion 1: PASS (vainfo)
  • Criterion 2: PASS (implicit)
  • Criterion 3: PASS (ffmpeg-vaapi exit 0)
  • Criterion 4: PASS-transitive (per iter3 precedent + memory reference_dmabuf_resv_blocker.md)
  • Criterion 5: still partial — Bug 2/3 are substrate-wide, NOT iter4 scope.

Campaign scoreboard moves to 5/5 (4 direct from earlier iters + 1 transitive iter4).

Memory update

Saved memory feedback_unconditional_codec_state.md: future codec-class-specific state MUST be gated on config_object->profile, not set unconditionally. iter1/iter3 had this latent bug too.

Substrate state at pause

  • Fork tip 692eaa0 (Phase 7 fix-forward) — on noether + fresnel.
  • Backend .so installed on fresnel.
  • Phase 3 anchor + Phase 7 fixed-strace files persisted on fresnel /tmp/iter4_phase{3,7}/.
  • Memory rules carry forward.
  • iter4 commits chain: Z (7f8fa93) -> A (16b3973) -> B (406d08e) -> C (beaa914) -> Phase-7 fix (692eaa0).

Resume cue

When fresnel surfaces, continue from: byte-by-byte diff of FRAME + COMPRESSED_HDR controls vs Phase 3 anchor + ffmpeg-v4l2request VP9 hwdownload pixel comparison.