Three Tier-2C/1B fixes from diff_against_ffmpeg.md (campaign repo):
1. Submit V4L2_CID_STATELESS_H264_SCALING_MATRIX every frame, with
the H.264 spec flat default (every entry = 16) when the consumer
didn't send a VAIQMatrixBufferH264. New helper:
h264_default_flat_scaling_matrix(). Mirrors FFmpeg's
v4l2_request_h264.c which always provides a scaling matrix.
Replaces patch 0012's VAIQMatrixBuffer-conditional submission —
that was corpus-correct (bbb has no explicit scaling lists) but
inconsistent with what hantro G1 expects.
2. Set pps->flags |= V4L2_H264_PPS_FLAG_SCALING_MATRIX_PRESENT
unconditionally. Hantro G1's set_params reads this flag to gate
G1_REG_DEC_CTRL2_TYPE1_QUANT_E.
3. Populate pps->num_ref_idx_l0/l1_default_active_minus1 from
VASliceParameterBufferH264.num_ref_idx_l*_active_minus1. Hantro
G1 writes both into G1_REG_DEC_CTRL6_REFIDX0_ACTIVE / REFIDX1_ACTIVE.
VAAPI doesn't expose the parsed-PPS default fields; the per-slice
override is the closest available source (matches PPS default
except on streams with explicit per-slice override).
Why now: 2026-05-04 Phase 0 kernel-side audit (kernel source
drivers/media/platform/verisilicon/hantro_g1_h264_dec.c) showed
hantro G1 writes these fields directly into hardware MMIO
registers. Prior assumption that they're "informational" or
that "VAAPI handles defaults" was wrong — the hardware uses them
to bit-walk the slice header and to size reference lists. See
~/src/libva-multiplanar/diff_against_ffmpeg.md.
This is the easy half of the fix. The load-bearing half — adding
a slice-header bit-parser to populate dec_param->dec_ref_pic_
marking_bit_size, idr_pic_id, pic_order_cnt_bit_size — comes in
the next commit.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
test0r
d41a4b96b3