iter40b: SPS-parse fix lands but bit-exact still blocked upstream
Per-driver gate added: when rpi-hevc-dec active, parse SPS NAL from surface_object->source_data via the iter2 vendored GStreamer parser and override the VAAPI-omitted v4l2_ctrl_hevc_sps fields (sps_max_num_reorder_pics, sps_max_latency_increase_plus1, sps_max_sub_layers_minus1, max_dec_pic_buffering_minus1[HighestTid]). Cached at driver_data->hevc_sps_field_cache. Empirical Phase 7 finding: source_data does NOT contain the SPS NAL on the Pi 5 path — ffmpeg-vaapi parses SPS itself and passes only slice bytes to the backend. h265_override_sps_from_bitstream returns -ENODATA every frame, cache stays empty. Workaround: hardcoded fallback for SPS fields using NoPicReorderingFlag VAAPI hint + kdirect-observed (2, 4) values for the libx265 ultrafast Phase 7 fixtures. Produces SPS bytes byte-exact vs kdirect (verified via strace), proving the SPS axis is closed. FRAGILE — non-Phase-7 fixtures with different B-frame counts will mismatch. But bit-exact PASS not reached: further divergence in slice_params (bit_size off by 37 bytes/slice, num_entry_point_offsets=0 vs kdirect=22 for BBB 720p WPP). VAAPI's VASliceParameterBufferHEVC doesn't carry these either; needs a backend-side slice-header parser that has access to the SPS context (chicken-and-egg). Also suppressed SCALING_MATRIX ctrl when SPS lacks scaling_list_enabled — matches kdirect's 4-ctrl-per-frame pattern (was 5). Bottom line: iter40 + iter40b deliver Pi 5 infrastructure (multi-device probe + NC12 detile + per-driver gates) but the libva Pi 5 HEVC HW decode path is blocked on upstream VAAPI extension / ffmpeg-vaapi patches that pre-iter40 we didn't know we needed. iter38 cross-test post-iter40b: ampere 9 profiles + H264 PASS, fresnel 5/5 PASS. No sibling regression. Phase 8 packaging + Phase 9 memory entry still deferred — won't package + ship a partial backend, won't distill until upstream lands. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
@@ -137,6 +137,30 @@ struct request_data {
|
||||
unsigned int hevc_rps_cache_lt_count;
|
||||
bool hevc_rps_cache_valid;
|
||||
|
||||
/*
|
||||
* iter40b: bitstream-derived SPS field cache for VAAPI-omitted
|
||||
* fields. rpi-hevc-dec validates these against bitstream-true
|
||||
* values; the rkvdec/hantro fallback (sps_max_dec_pic_buffering_minus1,
|
||||
* 0) that satisfies §A.4.2 isn't enough for rpi.
|
||||
*
|
||||
* Cached on first IDR frame's SPS NAL parse, reused for subsequent
|
||||
* non-IDR frames whose source_data may not carry an SPS.
|
||||
*
|
||||
* sps_max_sub_layers_minus1 is the index into max_*[] arrays. The
|
||||
* V4L2 SPS struct fields are scalars (single sublayer), so we pick
|
||||
* the HighestTid (= sps_max_sub_layers_minus1) slot — matches
|
||||
* ffmpeg-vaapi + kdirect convention.
|
||||
*/
|
||||
struct {
|
||||
bool valid;
|
||||
uint8_t sps_max_sub_layers_minus1;
|
||||
uint8_t max_dec_pic_buffering_minus1;
|
||||
uint8_t max_num_reorder_pics;
|
||||
uint8_t max_latency_increase_plus1;
|
||||
bool scaling_list_enabled;
|
||||
bool scaling_list_data_present;
|
||||
} hevc_sps_field_cache;
|
||||
|
||||
struct video_format *video_format;
|
||||
|
||||
/*
|
||||
|
||||
Reference in New Issue
Block a user