Merge pull request 'libva-v4l2-request-fourier (deb): catch build-deb.sh up to c1bb444 (follow-up to #52)' (#53) from claude-noether/marfrit-packages:noether/libva-deb-bump-c1bb444 into main

Reviewed-on: marfrit/marfrit-packages#53

debian/libva-v4l2-request-fourier/build-deb.sh

@@ -10,15 +10,21 @@
 # Upstream fork: https://git.reauktion.de/marfrit/libva-v4l2-request-fourier
 set -euo pipefail
 
-# Same pin as the Arch PKGBUILD.  9898331 = LIBVA-2 close — completes
+# Same pin as the Arch PKGBUILD.  c1bb444 = PR #9 merge "h264:
-# the per-codec dispatch from c332d34 (LIBVA-1) by adding video_fd_
+# max_num_ref_frames fallback + libva-boundary instrumentation (#8)" —
-# daedalus to any_fd_supports_output_format's probe array.  Without
+# addresses the libva-side portion of marfrit/libva-v4l2-request-fourier#8.
-# it, H.264/VP9/AV1 profiles never got advertised on Pi 5 mixed
+# The daedalus_v4l2-via-libavcodec strict consumer rejected frames whose
-# deployments (rpi-hevc-dec primary, daedalus_v4l2 alt) — ffmpeg
+# sps.max_num_ref_frames was 0 (older ffmpeg-vaapi paths leave the field
-# bailed with "No support for codec h264 profile 578" before the
+# unset and HW decoders tolerated it).  PR adds a per-profile spec
-# per-codec dispatch could even fire.
+# minimum fallback (counts valid DPB entries first; 1 for baseline / 4
-UPSTREAM_COMMIT=989833114a7708ad999dc68309cbc181d9913bdb
+# for main+high if even that is 0) and a one-line request_log at
-PKGVER=1.0.0+r380+g9898331
+# h264_set_controls entry dumping raw VAAPI bitfields for diagnosing
+# the still-open PPS-flag-zero portion of issue #8.
+#
+# Prior pin (9898331) was the LIBVA-2 close — config-side
+# video_fd_daedalus added to the profile enumeration probe array.
+UPSTREAM_COMMIT=c1bb444d0731ca7ca831c7e01ec4b52ed736ca8e
+PKGVER=1.0.0+r382+gc1bb444
 PKGREL=1
 
 HERE=$(dirname "$(readlink -f "$0")")