Files
fresnel-fourier/phase5_iter11_review.md
marfrit 7a1bd8ec0a iter11 Phase 5: α-13 inert; pivot to α-14 num_entry_point_offsets
Reviewer empirically read rkvdec-hevc.c on boltzmann kernel-agent
tree. sps_max_num_reorder_pics is NOT read by rkvdec. α-13 would
match kdirect's wire bytes but produce no behavioural change.

CRIT-2: num_entry_point_offsets (libva hardcoded 0 at h265.c:356,
kdirect 22 from slice header parse) + PPS UNIFORM_SPACING flag are
the live candidates. BBB HEVC uses WPP (ENTROPY_CODING_SYNC flag
set in PPS) not tiles; 22 entry points = 23 CTB rows for 720p with
32-pixel CTBs.

Decision: land α-13 as wire-correctness hygiene (matches kdirect,
no regression risk), then α-14 for the actual fix.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-14 02:06:37 +00:00

4.5 KiB
Raw Permalink Blame History

Iteration 11 — Phase 5 Review

Reviewed 2026-05-14. Empirical anchor: Phase 3 strace, rkvdec-hevc.c on boltzmann (build/marfrit-packages/arch/linux-fresnel-fourier/src/linux-7.0), h265.c in libva-v4l2-request-fourier/src/.


CRIT-1 — rkvdec does not read sps_max_num_reorder_pics at all

Invalidates the primary mechanism.

Exhaustive grep of rkvdec-hevc.c: the field sps_max_num_reorder_pics is never read. The SPS fields rkvdec actually maps to hardware registers are geometry, bitdepth, CTB sizes, PCM config, short/long-term ref counts, temporal-MVP, and flags — not the buffering/reorder hints. The field is present in v4l2_ctrl_hevc_sps for spec completeness but rkvdec ignores it entirely.

Consequence: α-13 will change wire bytes 10 and produce no behavioural difference in rkvdec. Phase 7 YUV hash will remain all-zero.

Required Phase 6b amendment A: α-13 must be deprioritised to IMP (harmless wire-correctness improvement). Bug 5 investigation must shift to the two fields rkvdec does act on that differ between libva and kdirect.


CRIT-2 — num_entry_point_offsets is the live suspect and needs a Phase 4b plan

rkvdec-hevc.c at line 272-284 writes num_tile_columns_minus1 and num_tile_rows_minus1 from the PPS to hardware. kdirect submits num_entry_point_offsets = 22; libva submits 0. BBB HEVC is a tiled stream (confirmed by 22 entry points from kdirect). Libva's hardcoded 0 tells the kernel the bitstream has no tile boundaries, which is false. rkvdec writes tile geometry into hardware from PPS fields — if those fields are also wrong, or if the driver validates entry-point-offsets count against tile geometry internally, the zero produces either a wrong decode or a silent error.

Additionally, the PPS UNIFORM_SPACING flag (bit 20) is missing from libva. For tiled streams this flag controls whether rkvdec computes uniform column/row widths or reads them from per-column/row arrays. BBB being tiled makes this non-don't-care.

Required Phase 6b amendment B: Add Phase 4b scope covering:

  1. num_entry_point_offsets — derive from slice->num_entry_point_offsets if VAAPI exposes it, else from tile geometry (num_columns × num_rows per slice).
  2. PPS UNIFORM_SPACING — set flag when pic_fields.bits.uniform_spacing_flag is set (VAAPI does expose this field in VAPictureParameterBufferHEVC.pic_fields).

IMP-1 — slice_qp_delta byte 22 is NOT a hardcoded parallel bug

Phase 4 plan raises this as a concern. Empirical check: h265.c line 368 reads slice_params->slice_qp_delta = slice->slice_qp_delta directly from the VAAPI buffer — it is not hardcoded. The -1 value (0xff) observed in Phase 3 strace is what VAAPI delivered for frame 1 of BBB. kdirect's 0x00 (0) comes from its own SPS NAL parse. This divergence is real but secondary; slice_qp_delta miscalculation shifts luma values, it does not suppress entire frame output. Not a parallel hardcoded-zero bug.


IMP-2 — Phase 7 hash check must not be skipped if wire bytes match kdirect's

Per feedback_wire_vs_behavior.md and the Phase 4 plan's own §Phase 7: matching wire bytes alone is insufficient. Phase 7 must SHA the raw NV12 CAPTURE output against kdirect's 9340b832… hash, not just strace-diff the control payloads. The plan states this correctly; reviewer flags it to ensure it survives any "close enough" shortcut in execution.


MIN-1 — Comment accuracy in α-13 patch

The proposed α-13 comment says "blocked B-frame decode." If CRIT-1 stands and rkvdec ignores the field, this causal claim is wrong. The comment should be scoped to "wire-level conformance fix; not confirmed to unblock rkvdec output." Amend before commit to avoid misleading future readers.


Summary

# Severity Finding Blocks Phase 6?
CRIT-1 CRIT rkvdec never reads sps_max_num_reorder_pics; α-13 is wire-only Yes — replan required
CRIT-2 CRIT num_entry_point_offsets=0 + missing UNIFORM_SPACING are the live suspects for tiled BBB Yes — Phase 4b needed
IMP-1 IMP slice_qp_delta is not hardcoded; 0xff is VAAPI-supplied, not a parallel bug No
IMP-2 IMP Phase 7 must hash YUV not just strace No
MIN-1 MIN α-13 comment overclaims causation No

Recommended Phase 6b scope: Land α-13 as a wire-correctness commit with corrected comment (MIN-1). Open Phase 4b for num_entry_point_offsets + UNIFORM_SPACING as the primary Bug 5 fix path (CRIT-2). Do not gate Phase 6 on α-13 unblocking Bug 5 — it won't.