Commit Graph

1 Commits

Author SHA1 Message Date
claude-noether df787a6cc2 iter2 Phase 8 close: 3/5 codecs passing, lesson L1 extended (BOTH directions)
Iteration 2 closes with all 5 Phase 1 boolean-correctness criteria
green. Third codec passes — campaign scoreboard 2/5 → 3/5 (H.264
in T4, MPEG-2 in iter1, HEVC in iter2). Loop terminates per
feedback_dev_process.md Phase 8.

Notable: ZERO Phase 7 → Phase 4 loopbacks needed. Phase 5 review
caught all 3 would-be loopback triggers in advance (data_byte_offset
rename, dpb.rps→index-arrays semantics, pic_order_cnt_val rename).
This is the dev-process ideal: review catches bugs before
implementation lands; verification confirms contract.

What landed:

  Code (libva-v4l2-request-fourier master 229d6d1 → 8d71e20):
    cca539d iter2 Phase 6 commit A: config.c break for HEVCMain case
    8d71e20 iter2 Phase 6 commit B: rewrite h265.c against new V4L2
            stateless HEVC API (6 files, 463 ins, 236 del)

  Both authored as Claude (noether) per feedback_gitea_as_claude_noether.md.

  Campaign docs (fresnel-fourier):
    6e8c970 iter2 Phase 0 + Phase 1 lock
    b3ba157 iter2 Phase 2 situation analysis (6 bugs)
    d35a247 iter2 Phase 3 baselines (substrate post-pacman-Syu + HEVC anchor)
    348736e iter2 Phase 4 plan (10 contract clauses)
    9eae068 iter2 Phase 5 sonnet review (3 Critical UAPI errors caught)
    05b4bd5 iter2 Phase 7 verification (5/5 GREEN)
    [this commit] iter2 Phase 8 close

Lesson L1 distilled to memory (extension of iter1 entry):

  feedback_review_empirical_over_theoretical.md updated with
  Direction 2 corollary. Original iter1 lesson covered
  author-rebuttal-of-reviewer-finding (lean empirical, defer to
  Phase 7 byte-compare). iter2 surfaced opposite direction:
  author-too-credulously-adopting-reviewer-amendment.

  Concrete iter2 instance: Phase 5 S1 suggested
  picture->pic_fields.bits.uniform_spacing_flag exists in VAAPI as
  source for V4L2_HEVC_PPS_FLAG_UNIFORM_SPACING. I adopted into
  amended plan without verifying. Phase 6 build failed:
    error: struct has no member named 'uniform_spacing_flag'
  VAAPI's VAPictureParameterBufferHEVC doesn't expose either bit
  19 or bit 20. Reviewer-cited mapping was wrong; cheap gcc
  test-compile would have caught it.

  Memory updated with Direction 2 protocol: when reviewer
  suggests a field mapping, verify empirically (test-compile,
  struct dump, kernel UAPI grep) BEFORE incorporating into the
  amended plan. Generalized rule: empirical evidence trumps
  source-read theory in BOTH directions of Phase 5 review.

Backlog items deferred (campaign-internal, not durable memory):

  B6 — VAAPI ↔ V4L2 SPS field-fidelity gaps:
    sps_max_num_reorder_pics (post-fix=0, baseline=2),
    sps_max_latency_increase_plus1 (post-fix=0, baseline=4),
    possibly PPS bit 12 ENTROPY_CODING_SYNC_ENABLED.
    VAAPI doesn't expose; FFmpeg parses from bitstream directly.
    Operational impact NIL (Phase 7 Criterion 4 byte-identical
    pixel pass). Phase 8 polish-backlog candidate: add SPS
    bitstream parsing to h265_fill_sps when VAAPI doesn't supply
    the fields. Probably low ROI — kernel HEVC handler tolerates
    0 values for the BBB fixture. Defer until a real-world consumer
    surfaces a fixture that breaks on this.

  B7 — Phase 4 plan body sizeof typo:
    Plan claimed sizeof(scaling_matrix) = 1296. Empirical = 1000
    bytes. Code uses sizeof() symbolically so produces correct
    bytes; only plan body's expected-value comment was wrong.
    Phase 7 byte-compare structural check caught it. Future polish:
    state struct sizes via sizeof() references in plan bodies, not
    hand-computed values.

iter1 carryover backlog (still deferred):

  B3 latent surface-reuse bug — picture.c:287 h264.matrix_set=false
      hits union byte 240. For HEVC: byte 240 lands in h265.picture.
      RenderPicture's per-frame VAPictureParameterBufferType
      overwrite masks the corruption (verified Phase 5 Q3 — mpv-vaapi
      sends VAPictureParameterBufferType per frame for HEVC, no
      MPEG-2-style filtering). Iter2+ Phase 4 cross-cutting candidate.

  B4 context.c H.264 device-init log noise (rkvdec accepts both
      H.264 + HEVC controls cleanly; on hantro both EINVAL with
      cosmetic log). Iter2 added a 2nd batched call for HEVC; same
      (void) swallow pattern. Cosmetic.

  B5 vbv_buffer_size 1MB vs 1.31MB (MPEG-2-only; not exercised by
      HEVC).

Phase 4 cross-cutting work items collected:
  - VIDIOC_EXPBUF + DMA_BUF_IOCTL_SYNC for vaDeriveImage cache-stale
    fix (still applies to all codecs)
  - V4L2 device-discovery probe (still applies)
  - picture.c BeginPicture profile-aware reset (B3)
  - context.c H.264+HEVC device-init log suppression (B4)
  - mpeg2 vbv_buffer_size negotiation polish (B5)
  - h265 SPS bitstream-parse fidelity polish (B6)

Campaign roadmap (codec iterations remaining):
  iter3: VP8 on hantro — implement vp8.c. Smaller scope than iter2;
         predicting closer to iter1 MPEG-2 in size. No slice_params
         dynamic-array; single v4l2_ctrl_vp8_frame struct per kernel
         UAPI.
  iter4: VP9 on rkvdec — implement vp9.c. Largest control surface
         remaining.

Phase 5 review value confirmed empirically AGAIN: 3 Critical findings
caught (data_byte_offset rename, dpb.rps→index-arrays semantics,
pic_order_cnt_val rename) — would have been Phase 6 compile failures
or silent semantic bugs. Without that review pass, iter2 would have
required at least 1-2 Phase 7 → Phase 4 loopback cycles. Reviews
are never skippable per global ~/.claude/CLAUDE.md rule; iter2
exemplifies why.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-08 15:16:55 +00:00