Read FFmpeg's libavcodec/v4l2_request_h264.c (Kwiboo downstream
v4l2-request-n8.1 head b57fbbe, proven working on hantro hardware) and
Linux mainline drivers/media/platform/verisilicon/hantro_g1_h264_dec.c
(the actual register-write code).
Smoking gun: hantro G1 writes three DECODE_PARAMS fields directly into
hardware MMIO registers:
dec_ref_pic_marking_bit_size -> G1_REG_DEC_CTRL5_REFPIC_MK_LEN
idr_pic_id -> G1_REG_DEC_CTRL5_IDR_PIC_ID
pic_order_cnt_bit_size -> G1_REG_DEC_CTRL6_POC_LENGTH
When all three are zero (our current state — patch 0008 left them
uninitialized with the open question "does hantro tolerate?"), the
hardware bitstream parser advances by zero bits past slice_type,
lands on garbage, decodes zero pixels into the CAPTURE buffer.
This explains the all-zero CAPTURE output we see across mpv and
Firefox in the live-session real-VO tests. Patch 0008's "Empirical
question" was empirically answered today: NO, hantro does not
tolerate zeros in these fields.
Additional easy fixes identified:
- pps->num_ref_idx_l0_default_active_minus1 (uninitialized;
VAAPI provides; written to MMIO REFIDX0_ACTIVE)
- pps->num_ref_idx_l1_default_active_minus1 (same)
- pps->pic_parameter_set_id (uninitialized; for single-PPS BBB
accidentally correct at 0; written to MMIO PPS_ID)
- pps->flags |= V4L2_H264_PPS_FLAG_SCALING_MATRIX_PRESENT always
(FFmpeg comment: "FFmpeg always provide a scaling matrix")
- always send V4L2_CID_STATELESS_H264_SCALING_MATRIX in the request
(with default flat matrix when no VAIQMatrixBuffer arrives)
The load-bearing fix requires implementing a small slice_header()
bit-parser in libva-v4l2-request — VAAPI doesn't carry the
bit-position fields and hantro requires them. ~50-100 lines of C
in a new helper. This is real Phase 6 work, well-scoped.
Saved feedback memory:
- ../.claude/projects/-home-mfritsche-src/memory/
feedback_kernel_source_audit_for_uapi_contract.md
on the broader lesson: read kernel-side driver source for any
UAPI control fields userspace fills, especially when the kernel
writes them into hardware MMIO. "Empirical question -- does the
kernel tolerate?" is not an acceptable resolution; either read
the source or get a definitive empirical answer.
Reference sources gitignored — separate-repo discipline. Pull
recipes (ffmpeg-kwiboo + linux-mainline sparse clones) preserved
in shell history; can be reconstructed from diff_against_ffmpeg.md
URL/branch references.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
