fresnel-fourier/phase8_iteration25_close.md

Iteration 25 — Phase 8 (close)

Closes 2026-05-14. iter25 = α-25 synthetic-SPS injection before cap_pool_init. MAJOR WIN. PARTIAL close — frame 1 byte-identical to kdirect for HEVC libva; frames 2+ have separate wire-byte issue (decode_params).

α-25 implementation

src/context.c::RequestCreateContext — after S_FMT(OUTPUT) + S_FMT(CAPTURE) + G_FMT(CAPTURE) sanity, BEFORE cap_pool_init:

switch (config_object->profile) {
case VAProfileHEVCMain: {
    struct v4l2_ctrl_hevc_sps dummy_sps;
    memset(&dummy_sps, 0, sizeof(dummy_sps));
    dummy_sps.chroma_format_idc = 1;          /* 4:2:0 */
    dummy_sps.bit_depth_luma_minus8 = 0;       /* 8-bit */
    dummy_sps.bit_depth_chroma_minus8 = 0;
    dummy_sps.pic_width_in_luma_samples = picture_width;
    dummy_sps.pic_height_in_luma_samples = picture_height;
    /* ... v4l2_set_controls(video_fd, request_fd=-1, &SPS, 1) ... */
}
case VAProfileH264*: similar with V4L2_CID_STATELESS_H264_SPS
default: skip
}

Forks db0b7f9 — single commit.

Result — definitive

Frame 1: libva CAPTURE bytes = kdirect CAPTURE bytes (cmp identical for first 1382400 bytes, the entire frame 1 NV12 payload of 1280×720).

Frame 2+: diverge starting at byte 1382401.

Kernel printk evidence (post-α-25)

iter24_req_to_new: id=0xa40a90 ret=0 p_req_valid=1 p_req_elems=1
iter24_try_or_set: master_id=0xa40a90 ret=0     ← was -16 (EBUSY) before
iter24_req_to_new: id=0xa40a91 ret=0
iter24_try_or_set: master_id=0xa40a91 ret=0
iter24_req_to_new: id=0xa40a92 ret=0
iter24_try_or_set: master_id=0xa40a92 ret=0
iter24_req_to_new: id=0xa40a93 ret=0
iter24_try_or_set: master_id=0xa40a93 ret=0
iter24_req_to_new: id=0xa40a94 ret=0
iter24_try_or_set: master_id=0xa40a94 ret=0
rkvdec_iter20: sps[0..16]=00 00 00 05 d0 02 00 00 04 04 04 00 01 01 00 03
                ← non-zero, w=1280, h=720
rkvdec_hevc_run: w=1280 h=720 chroma=1 nal_unit_type=20 slice_type=2 decode_flags=0x3
                ← rkvdec sees CORRECT SPS for the first time

iter24_loop_break-count = 0 — the setup loop NEVER breaks. All 5 staged HEVC controls commit to ctx->ctrl_hdl successfully.

Bug 5 root cause: FIXED

The -EBUSY block from rkvdec_s_ctrl's vb2_is_busy check is gone. ctx->image_fmt is pre-seeded to RKVDEC_IMG_FMT_420_8BIT by the synthetic SPS injection before any CAPTURE buffer is allocated. Per-frame SPS submissions find image_fmt_changed=false → skip reset → commit succeeds.

Frame 2+ divergence (separate Bug)

decode_params.short_term_ref_pic_set_size:

• libva frame 2: bytes 4-5 = 00 00 → 0
• kdirect frame 2: bytes 4-5 = 0a 00 → 10

libva's h265_fill_decode_params doesn't populate short_term_ref_pic_set_size (VAAPI doesn't expose it). kdirect parses it from the HEVC NAL directly. This affects DPB reference resolution for P/B frames. iter26 candidate.

Mechanism status

#	Mechanism	Status
9	rkvdec_s_ctrl -EBUSY on first SPS	FIXED iter25 α-25
10	decode_params.short_term_ref_pic_set_size = 0	NEW iter26 candidate

Substrate state at iter25 close

• Backend SHA on fresnel: post-α-25 build (commit db0b7f9).
• Fork tip db0b7f9 (α-25).
• Kernel linux-fresnel-fourier 7.0-8 (diagnostic printks; should eventually revert to clean 7.0-1 + RFC v2 + iter12 baseline).
• HEVC libva frame 1 = kdirect frame 1 byte-identical. ✓✓✓
• HEVC libva frame 2+: differs.

Anchors check pending

Need to re-run 5-codec anchors to verify α-25 didn't regress VP9/MPEG-2/VP8 (it shouldn't — guard is case VAProfileHEVCMain / case VAProfileH264* only).

Lesson

After 15 iterations chasing wire-byte hypotheses (iter11-iter18), 5 iterations of kernel printk (iter17-iter24), the actual bug was an interaction between libva's CAPTURE-pre-allocate design and rkvdec's lazy image_fmt determination. The fix is 90 LOC in libva. The kernel was correct all along — it just needed a way to commit the image_fmt before buffers were locked in.

This validates feedback-libva-byte-correct-kernel-bug only partially: libva WAS byte-correct in its ioctl content, but it had a CAPTURE-pool-allocation TIMING bug that interacted with kernel state. The bug is in libva, not the kernel, but the symptom only manifested because of kernel-side -EBUSY semantics that aren't well documented.

iter26 candidate

Fix h265_fill_decode_params to populate short_term_ref_pic_set_size. VAAPI doesn't expose this directly, but it can be derived from surface_object->params.h265.slices[0].short_term_ref_pic_set_size (if VAAPI provides it) or parsed from the slice header.