User Tools

Site Tools


claude:dev_process

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
claude:dev_process [2026/05/02 15:50] – add Phase 3 'measurements describe what the system does' + Phase 6 'contract before code' subsections markus_fritscheclaude:dev_process [2026/05/02 15:57] (current) – Phase 6: add worked example for 'state the contract explicitly' (patch 0012, h264 SCALING_MATRIX) markus_fritsche
Line 49: Line 49:
  
 **Copying from baseline measurements is not implementation. It is transcription of potentially broken behaviour.** A deliverable that matches baseline bytes but violates the API contract is not a deliverable — it is a deferred bug. **Copying from baseline measurements is not implementation. It is transcription of potentially broken behaviour.** A deliverable that matches baseline bytes but violates the API contract is not a deliverable — it is a deferred bug.
 +
 +==== What "state the contract explicitly" looks like ====
 +
 +Worked example: ''0012-h264-omit-scaling-matrix-frame-based.patch'' in ''~/src/ohm_gl_fix/phase6/step1/''. The commit message opens with the contract before any code:
 +
 +<code>
 +VAAPI signals "explicit scaling lists are present in the bitstream"
 +implicitly: the consumer (ffmpeg-vaapi, mpv, etc.) sends a
 +VAIQMatrixBufferH264 alongside RenderPicture iff
 +sps_scaling_matrix_present_flag || pps_scaling_matrix_present_flag.
 +When the bitstream uses default (flat) scaling, no IQMatrixBuffer
 +arrives [...]
 +
 +Earlier draft of this patch unconditionally omitted SCALING_MATRIX in
 +FRAME_BASED. That's corpus-correct (bbb has no explicit scaling
 +lists) but the wrong predicate: the kernel-side gating is by
 +"matrix-supplied vs. not," not by decode mode. Streams that signal
 +explicit scaling lists must submit SCALING_MATRIX in either mode.
 +
 +Contract verification (audit_0008_decode_params_2026-05-01.md +
 +hantro_h264.c::assemble_scaling_list): the kernel uses the supplied
 +matrix when SCALING_MATRIX is in the control batch and falls back
 +to spec-defined defaults when absent. Mode-independent.
 +</code>
 +
 +What this gets right:
 +
 +  * **Contract first** — per-control rules cited from kernel doc (''ext-ctrls-codec-stateless.rst:752''), kernel driver (''hantro_h264.c::assemble_scaling_list''), and sibling implementation (gst-plugins-bad commit 9e3e775) //before// any patch hunks.
 +  * **Corpus-correct ≠ spec-correct, called out by name** — the rejected predicate ("omit SCALING_MATRIX in FRAME_BASED") //did// match the BBB baseline. It still got rejected, because the contract said the gate is "matrix-supplied vs. not," not "decode mode." This is exactly the Phase 3-derived-implementation trap.
 +  * **Then** the diff implements one branch per contract clause: SPS/PPS/DECODE_PARAMS always, SCALING_MATRIX iff ''matrix_set'', SLICE_PARAMS iff SLICE_BASED, PRED_WEIGHTS iff SLICE_BASED + ''V4L2_H264_CTRL_PRED_WEIGHTS_REQUIRED''.
 +
 +Mirror format anywhere reviewable: PR description, commit message body, plan section, or a header comment block. The shape is //contract clauses with citations → code that maps 1:1 to those clauses//.
  
 ===== Phase 7 — Verification Measurements ===== ===== Phase 7 — Verification Measurements =====
claude/dev_process.1777737041.txt.gz · Last modified: by markus_fritsche