Commit Graph

2 Commits

Author SHA1 Message Date
marfrit 299e376d51 iter2 phase0 update: upstream-consumer survey closes Q1 + Q2
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>
2026-05-16 08:38:52 +00:00
marfrit cd047a34de iter2 phase0: HEVC backend extension substrate
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>
2026-05-16 08:33:50 +00:00