libva-v4l2-request-fourier: 9898331 -> c1bb444 (PR #9 / issue #8 fix)

Bumps the libva backend pin to include marfrit/libva-v4l2-request-fourier
PR #9 — h264_set_controls fix for the bitstream-vs-session value drift
that breaks the daedalus_v4l2 strict-consumer path (issue #8):

  * max_num_ref_frames fallback when VAAPI client left it 0 (count
    valid DPB entries, then per-profile spec minimum)
  * one-line request_log at h264_set_controls entry dumping raw
    VAAPI bitfields for disambiguating remaining PPS-flag-zero
    portion of #8

The PR explicitly defers the deeper "profile_idc / level_idc from
bitstream" portion of #8 — VAAPI's VAPictureParameterBufferH264 omits
both fields, so a real fix needs SPS-NAL parsing or daedalus
wire-protocol pass-through. Not in this bump.

pkgver: 1.0.0.r380.9898331 -> 1.0.0.r382.c1bb444 (commit count 380->382)
pkgrel: 1 (fresh pkgver, no rebuild-only iteration)

Verified on higgs (Debian 13 trixie, gcc 14.2.0, libva 2.22.0):
clean meson build, vainfo enumerates all 8 codec profiles, multi-device
probe still wires rkvdec / rpi-hevc-dec / daedalus_v4l2.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

arch/libva-v4l2-request-fourier/PKGBUILD

@@ -24,31 +24,29 @@ pkgname=libva-v4l2-request-fourier
 epoch=1
 _upstreampkg=libva-v4l2-request
 
-# Pin the fork tip. de27e95 = "v4l2: log error_idx + failing ctrl id
+# Pin the fork tip. c1bb444 = PR #9 merge "h264: max_num_ref_frames
-# on S_EXT_CTRLS failure" — Phase 8.13 diagnostic that surfaced the
+# fallback + libva-boundary instrumentation (#8)" — addresses the
-# real root cause of the libva→daedalus_v4l2 request-completion
+# libva-side portion of marfrit/libva-v4l2-request-fourier#8: the
-# timeout (turned out the EINVAL libva was logging was a harmless
+# daedalus_v4l2-via-libavcodec strict consumer rejected frames whose
-# H264/HEVC probe; actual VP9 stateless control SET worked all along).
+# sps.max_num_ref_frames was 0 (older ffmpeg-vaapi paths leave the
+# field unset and HW decoders tolerated it). Adds a per-profile spec
+# minimum fallback (counts valid DPB entries first; 1 for baseline /
+# 4 for main+high if even that is 0) and a one-line request_log at
+# h264_set_controls entry dumping raw VAAPI bitfields (seq_fields,
+# pic_fields, num_ref_frames, bit_depth_*) for disambiguating where
+# the still-open PPS-flag-zero portion of issue #8 originates.
 #
-# Prior pin (7ac934e) was iter38b — fresnel-fourier multi-device probe
+# Prior pin (9898331) was the LIBVA-2 close — config-side video_fd_daedalus
-# + MAX_PROFILES bounds-check fix. de27e95 added the daedalus_v4l2
+# added to the profile enumeration probe array.  c332d34 (LIBVA-1) added
-# probe slot (b5b3acf), the meson option gate (2146341), and the
+# the per-codec dispatch.  Earlier de27e95 (Phase 8.13 diagnostic),
-# S_EXT_CTRLS diagnostic (de27e95 itself).  c332d34 (LIBVA-1) added
+# 7ac934e (iter38b multi-device probe + MAX_PROFILES bounds-check fix).
-# the per-codec dispatch: rpi-hevc-dec + daedalus_v4l2 both probe each
+_commit=c1bb444d0731ca7ca831c7e01ec4b52ed736ca8e
-# other as alts, VP9/AV1/H.264 route to daedalus via new 'd' kind,
-# HEVC stays on 'p' (rpi-hevc-dec).  9898331 (LIBVA-2) completes that
-# by adding video_fd_daedalus to any_fd_supports_output_format's probe
-# array — without it, H.264/VP9/AV1 profiles never got advertised on
-# Pi 5 mixed deployments (rpi-hevc-dec primary, daedalus alt) and
-# ffmpeg bailed with "No support for codec h264 profile 578" before
-# the per-codec dispatch could fire.
-_commit=989833114a7708ad999dc68309cbc181d9913bdb
 
 # Project version from meson.build (1.0.0) + commit count + short sha,
 # matching the ffmpeg-v4l2-request-fourier convention. Recomputed at
 # build time by pkgver() below; the static value here is a placeholder
 # so AUR-style consumers see something coherent before src/ exists.
-pkgver=1.0.0.r380.9898331
+pkgver=1.0.0.r382.c1bb444
 pkgrel=1
 pkgdesc="VA-API backend for V4L2 stateless decoders (multiplanar fork — fourier umbrella)"
 arch=('aarch64')