GStreamer's MERGED v4l2_codec_h265_dec_fill_ext_sps_rps in
gst-plugins-bad (GStreamer 1.28, MR !10820) is the primary upstream
reference. Walks its own gst_h265_parser_'s GstH265SPS.short_term_
ref_pic_set[] array, field names match the H.265 spec, one-to-one
mapping to the V4L2 control struct. Header strategy: runtime-optional
control probe, NO #ifndef shim.
Casanova's FFmpeg WIP branch (v4l2-request-ext-sps-rps-n8.0.1 at
gitlab.collabora.com) is the secondary reference — walks libavcodec
internal HEVCSPS->st_rps[] with different field names. Useful as
cross-check but not the primary template (renaming gymnastics).
cros-codecs has no support yet (would follow GStreamer's shape if
added). Casanova's kernel-test framework uses fluster through these
two upstream consumers; no other reference exists.
Q1 (architecture): resolved — implement H.265 SPS parser in backend,
mirror GStreamer pattern with spec-compliant field names.
Q2 (UAPI shim): resolved — runtime-optional control probe per
GStreamer pattern, NOT #ifndef shim.
Remaining sub-question for Phase 1: parser SOURCE (vendor GStreamer's
gsth265parser.c, adapt to backend idioms, or implement minimal fresh
from H.265 §7.3.7).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
5 existing HEVC controls in backend (SPS/PPS/SLICE_PARAMS/SCALING_
MATRIX/DECODE_PARAMS at h265.c:660-688) + DECODE_MODE/START_CODE in
context.c. No H.265 bitstream parser in backend (h264_slice_header.c
is the only such precedent — for H.264).
CRITICAL substrate finding: VAAPI VAPictureParameterBufferHEVC
exposes RPS COUNTS (num_short_term_ref_pic_sets,
num_long_term_ref_pic_sps) but NOT the per-RPS array contents
(delta_poc_s0_minus1[], delta_idx_minus1, etc.). So the backend
can't just copy from VAAPI — needs another data source.
5 open questions tabled for iter2 Phase 1, with Q1 = architecture
for RPS data sourcing being load-bearing:
A. Implement H.265 SPS parser in backend (~800-1500 LOC)
B. Stage-A test minimal-patch hypothesis (zero-init RPS) first
C. Link libavcodec's H265RawSPS (adds FFmpeg build dep)
D. Some other channel TBD (e.g. VAAPI extension buffer)
Plus Q2 (linux-api-headers shim vs bump), Q3 (mechanism depth),
Q4 (test clip — BBB iter1 carries), Q5 (Phase 7 anchor).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Meta-iter1 was a scoping iteration — deliverable is the campaign
umbrella + sub-iter ledger, not a code change. Phases 2-8 are
either rolled into Phase 0+1 (situation, plan) or deliberately N/A
(no meta-level measurements or verification beyond 'issues filed +
ledger exists').
Phase 5 review is the documented deviation from 'reviews are never
skippable': justified because Phase 0's prior-art survey +
verification against kernel source IS the review-equivalent rigor
(per feedback_review_empirical_over_theoretical), and there's no
separate Phase 4 plan to review beyond the ledger. iter2 + iter3
each get a full Phase 5 review on their own.
No new memory entry — lessons fall under existing
feedback_dev_process (Phase 1 loopback when scoping was wrong) and
feedback_characterize_before_change (meta-iter1 = scope + ledger
extends naturally).
Next: start iter2 Phase 0 (HEVC backend extension via
V4L2_CID_STATELESS_HEVC_EXT_SPS_ST_RPS / _LT_RPS).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Operator picked option 2: meta-campaign coordinating an HEVC backend
iteration (iter2 against libva-v4l2-request-fourier#3) and a VP9
kernel iteration (iter3 against kernel-agent#12) as parallel children
under one umbrella.
Iteration order: HEVC first because (a) smaller blast radius / faster
feedback loop, (b) the survey's mechanism reconstruction is a
hypothesis not yet test-verified — cheapest way to confirm is a
minimal backend patch, (c) VP9 has unresolved upstream-tree selection
that benefits from absorbing iter2 findings first. Operator may
overrule for parallel execution.
Meta-success: iter2 + iter3 both close with HEVC + VP9 added to
ampere-fourier Phase 3 instrumentation (C1-C6 against per-codec
floors); no regression to iter1 3-codec baseline; patches in right
repos (libva for HEVC, kernel-agent experiment branch for VP9, NOT
linux-ampere-fourier baseline per operator policy).
Falsifiers: iter2 patch doesn't fix HEVC -> re-open kernel-agent#11
with new evidence; iter3 tree doesn't rebase cleanly -> pick another;
Phase 7 regression to iter1 baseline -> Phase 5 review missed shared-
code interaction.
iter1 of the meta-campaign is mostly Phase 0+1+8: scoping + ledger +
close. Real engineering happens inside iter2 and iter3.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Phase 0 ran the operator-mandated upstream prior-art survey FIRST,
before any source-read or hypothesis. Headline finding: the HEVC
OOPS is fundamentally re-scoped from 'kernel bug' to 'userspace UAPI
gap' against the new 7.0 controls
V4L2_CID_STATELESS_HEVC_EXT_SPS_ST_RPS / _LT_RPS.
Survey + verification:
- Casanova/Collabora v8 series merged in Linux 7.0 added the two
new V4L2 controls for VDPU381 HEVC; backend 7ac934e (June pre-iter38)
predates the UAPI and grep returns zero hits for these CIDs.
- ampere linux-api-headers is still 6.19-1, doesn't define the
constants — the backend literally cannot reference them without a
headers bump.
- ampere kernel source rkvdec-hevc-common.c:500-509 looks up the new
CIDs; if backend never set them, rkvdec_hevc_prepare_hw_st_rps
reads invalid memory via memcmp — exactly the __pi_memcmp OOPS
symptom.
VP9 still kernel-side per the v4 cover ('This patch only adds support
for H264 and H265 in both variants'). Multiple competing out-of-tree
starting trees: Sarma's android tree (working but Android-flavored),
dongioia/rock5bplus-rkvdec2 (mainline-style claims), Kwiboo (no VP9
on RK3588 yet). RKVDEC2 separate-driver path is dead — future VP9
extends the existing rkvdec driver's VDPU381 variant_ops.
Five open questions tabled for Phase 1 — most important being campaign
re-scope (HEVC moves to backend campaign; this stays VP9 kernel-only
OR becomes a meta-campaign coordinating both).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Sister to ampere-fourier (userspace consumer) and fresnel-fourier
(RK3399 peer). Tracks the 2 kernel-side blockers from ampere-fourier
iter1: HEVC OOPS in rkvdec_hevc_prepare_hw_st_rps (kernel-agent#11)
and VP9 enablement on VDPU381/383 (kernel-agent#12). AV1 stays
userspace (libva-v4l2-request-fourier#2), not in this campaign.
Process notes: Phase 0 includes a non-optional upstream prior-art
survey (linux-rockchip / linux-media / linux-mm / Kwiboo / Bootlin)
before any code; per operator policy, patches go to kernel-agent
experiment branches, NOT into the linux-ampere-fourier baseline
package.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
marfrit