## Iteration 27/28 — Phase 8 (close)

Closes 2026-05-14. iter27 = extend kernel printk to dpb/slice bytes; iter28 = α-27/α-28 attempts to fix HEVC frame 2+. PARTIAL close, frame 2+ NOT fixed via libva-backend changes.

### α-27 (no-op): num_entry_point_offsets from VAAPI

VAAPI's `slice->num_entry_point_offsets` is 0 for all slices (ffmpeg-vaapi front-end does NOT parse this field). Even though kdirect (ffmpeg-v4l2request) writes 22 (=BBB's actual WPP entry-point count), rkvdec's source has NO reference to `num_entry_point_offsets` at all — the field is unused by the kernel driver.

Cannot fix from libva-side (need ffmpeg-vaapi parser upstream patch), and not needed for decode correctness on rkvdec.

### α-28 (no-op output): bit_size formula

Changed from `slice_data_size * 8` to `(slice_data_size - slice_data_byte_offset) * 8`. Kernel printk verifies bit_size now matches kdirect's 44096 for BBB frame 2. **But output hash unchanged** (`700aa52d…`). rkvdec's source has NO reference to `bit_size` either.

bit_size in the V4L2 stateless HEVC API spec is for HW consumers that use it; rkvdec doesn't.

### Remaining HEVC frame 2+ divergence

Per kernel iter20 + iter27 printks, with α-25/26/27/28 all in place:

| Field | libva frame 2 | kdirect frame 2 | rkvdec uses? |
|---|---|---|---|
| `bit_size` | 44096 (α-28) | 44096 | No |
| `data_byte_offset` | 40 | 40 | Yes (likely) |
| `num_entry_point_offsets` | 0 | 22 | No |
| `decode_params dp[0..16]` | same | same | Yes |
| `sps[0..16]` | same | same | Yes |
| `nal_unit_type`, `slice_type` | same | same | Yes |
| `slice_pic_order_cnt`, qp_delta | same | same | Yes |

All inspected fields match. Yet libva output diverges at byte 1382401 (frame 2 boundary), 12.2M bytes total differ across 10 frames.

### iter28b DIAG: universal 40-byte trim breaks IDR (tested, reverted)

`LIBVA_HEVC_TRIM_TRAILING=40` was tested as a quick refute/confirm of the 40-byte-inflation hypothesis. Result:
- libva HEVC 10-frame hash diverged at byte 899745 (INSIDE frame 1, not at frame-2 boundary).
- Trimming 40 bytes off IDR slice (96890→96850) corrupted frame 1.

Conclusion: the 40-byte inflation is NOT uniform per slice. The IDR (frame 1) slice has correct size from VAAPI. Only P/B slices have the inflation. A real fix requires dynamic detection — scan for rbsp_stop_one_bit, or per-slice-type logic.

Iter28b code reverted: `6646b16`.

### Likely root cause for frame 2+ (deferred)

The libva OUTPUT buffer for frame 2 = 5552 bytes (= 3 Annex-B start + 5549 from `slice->slice_data_size`). ffmpeg-v4l2request's OUTPUT for the SAME frame appears to be ~5512 bytes (= 3 + 5509, based on its `bit_size = (size+extra_size)*8` formula).

Difference: libva's slice_data_buffer from VAAPI is **40 bytes larger** than what ffmpeg-v4l2request's libavcodec dispatch gives. The trailing 40 bytes get appended to libva's OUTPUT buffer per slice.

Hypothesis: ffmpeg-vaapi's slice_data buffer concatenates trailing bytes (RBSP trailing alignment / between-NAL zeros) that ffmpeg-v4l2request strips. rkvdec reads past the actual slice payload into these trailing bytes → entropy decoder corrupts state → frame 2+ decoded with wrong reference content.

Both libavcodec dispatches share `FF_HW_CALL(s->avctx, decode_slice, nal->raw_data, nal->raw_size)` at hevcdec.c:2989, so same `size` parameter should reach both. The 40-byte inflation happens INSIDE ffmpeg-vaapi or libva (between hwaccel-init and slice-buffer-make).

### Mechanism status (post-iter27/28)

| # | Mechanism | Status |
|---|---|---|
| iter24 #9 | rkvdec_s_ctrl -EBUSY | FIXED iter25 α-25 (Bug 4 fully; Bug 5 frame 1 ok) |
| iter26 #10 | decode_params.short_term_ref_pic_set_size | FIXED iter26 α-26 (cosmetic; rkvdec doesn't use this field either) |
| iter27 #11 | num_entry_point_offsets | NO-OP (rkvdec doesn't use) |
| iter28 #12 | bit_size formula | NO-OP (rkvdec doesn't use) |
| iter28 #13 | **slice_data buffer 40-byte inflation in VAAPI vs libavcodec** | **LEADING — fix in ffmpeg-vaapi or libva-internal slice buffer; outside campaign scope this iter** |

### Substrate state at iter27/28 close

- Backend fork tip `cd286d9` (α-25 + H264-flag-fix + α-26 + α-27 + α-28).
- Kernel `7.0-9` with iter17 + iter20 + iter21 + iter22 + iter23 + iter27 printks.
- 5-codec status:
  - **H.264**: byte-equal to kdirect on 3 frames (Bug 4 FIXED).
  - **HEVC**: frame 1 byte-equal to kdirect (Bug 5 frame 1 FIXED). Frames 2+ diverge (separate root cause).
  - **VP9**: unchanged (HW=SW byte-equal).
  - **MPEG-2 / VP8**: untestable on this kernel boot — libva backend's single-device auto-probe lands on rkvdec which doesn't expose these profiles. Pre-existing libva backend limitation.

### Campaign-wide milestone

In one day:
- 8 wire-byte hypotheses eliminated iter11-iter18.
- 5 kernel-printk iterations (iter17, iter20-iter23) walking down the kernel-side localization.
- 1 root cause identification (iter24): rkvdec_s_ctrl returns -EBUSY when SPS triggers image_fmt reset on a busy CAPTURE queue.
- 1 fix iteration (iter25): synthetic SPS injection pre-allocates ctx->image_fmt → Bug 4 fully fixed, Bug 5 frame 1 fixed.
- 3 followup iterations (iter26-28): VAAPI field propagation discrepancies between vaapi front-end and v4l2request front-end identified but partially un-fixable from libva-side alone.

The campaign has gone from 0/5 PASS (initial) → 4/5 PARTIAL/PASS (Bug 4+5 root-caused, H264 fully fixed, HEVC frame 1 fixed, VP9 unchanged), with the remaining frame 2+ issue localized to an ffmpeg-vaapi serialization quirk.