Bumps both Arch (PKGBUILD) and Debian (build-deb.sh) sides in one commit
this time — following the dual-pin lesson from PR #53.
77f9236 = libva PR #12 merge: src/av1.{c,h} implements av1_set_controls
mapping VAPictureParameterBufferAV1 onto struct v4l2_ctrl_av1_sequence,
queued via S_EXT_CTRLS as V4L2_CID_STATELESS_AV1_SEQUENCE. The
daedalus_v4l2 daemon track will consume the ctrl to synthesise an
OBU_SEQUENCE_HEADER and prepend it to the slice bitstream, so libdav1d
can parse the OUTPUT buffer that ffmpeg-vaapi delivers without the
sequence header.
Until the daemon-side OBU synth lands (issue #11 operator track), the
SEQUENCE ctrl is just sitting in the request unused. Harmless on the
RK3588 vpu981 hardware path (vpu981 parses OBU bytes directly, ignores
the ctrl payload).
pkgver: r382.c1bb444 -> r386.77f9236 (commit count 382 -> 386, two new
upstream commits: 9fa18f2 av1 + 77f9236 merge).
pkgrel: 1 (fresh pkgver, no rebuild-only iteration).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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>
Follow-up to libva PR #7 (merged as 9898331). Without that commit,
H.264/VP9/AV1 profiles never got advertised on Pi 5 mixed deploys
(rpi-hevc-dec primary + daedalus_v4l2 alt) because the profile-
enumeration probe in any_fd_supports_output_format only walked
rkvdec / hantro / rpi-hevc-dec / vpu981 fds. ffmpeg vaapi -i
h264_test.mp4 on higgs bailed with "No support for codec h264
profile 578" before the LIBVA-1 per-codec dispatch could even fire.
9898331 extends the fds[] from 5 to 6 with video_fd_daedalus as
the 6th slot (HAVE_DAEDALUS_V4L2-gated, -1 fallback otherwise).
Effect on higgs once this lands: vainfo lists VP9Profile0 +
AV1Profile0 + H264* alongside HEVCMain, and ffmpeg -hwaccel vaapi
-i h264_test.mp4 routes through the daedalus daemon (via 'd' kind
in request_switch_device_for_profile).
Both packages: pkgver 1.0.0.r380.9898331 (count from rev-list),
pkgrel reset to 1 (new upstream pin). Backward-compatible on
RK3399/3588 — the new fd slot is gated by HAVE_DAEDALUS_V4L2 *and*
video_fd_daedalus >= 0, both false in those deployments.
Companion to the prior LIBVA-{1,ABI} bumps that landed in marfrit-
packages PRs #43, #44. Together they close the Pi 5 stack: boot ->
modules-load.d loads daedalus_v4l2 -> daedalus-v4l2.service starts
daemon -> libva opens both decoders -> ffmpeg -hwaccel vaapi
enumerates all codecs from both -> routes per-codec.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Bumps both Arch (PKGBUILD) and Debian (build-deb.sh + changelog)
pins to upstream c332d34 — the merged LIBVA-1 PR.
Effect: Pi 5 / CM5 mixed deployment (higgs) now opens BOTH
rpi-hevc-dec and daedalus_v4l2 from one libva session and routes
per-codec — HEVC to rpi-hevc-dec ('p'), VP9 / AV1 / H.264 to the
daedalus daemon (new 'd' kind). Before c332d34, find_codec_device
picked rpi-hevc-dec by known_decoder_drivers[] order and the
daedalus slot stayed -1, so VP9/AV1/H.264 frames failed S_FMT.
Also closes a small fd leak in RequestTerminate (daedalus pair —
caught while reviewing the alt-driver expansion).
Both packages: pkgver bumped 1.0.0.r378.c332d34, pkgrel reset to 1
(new upstream pin). Backward-compatible on RK3399/3588 — new
branches gated by HAVE_DAEDALUS_V4L2 *and* video_fd_daedalus >= 0,
both false in those deployments.
Companion: daedalus-v4l2{,-dkms} bump 481279c landed in PR #39
(systemd unit + auto-enable). Together they close the Pi 5 stack:
boot → modules-load.d loads daedalus_v4l2 → daedalus-v4l2.service
starts daemon → libva opens both decoders → ffmpeg -hwaccel vaapi
routes by codec.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Installed systems carry 1:1.0.0.r361.cf8cd9d-1 from an earlier build
that had epoch=1. Current PKGBUILD ships 1.0.0.r376.de27e95-1 without
epoch, which pacman vercmp ranks BELOW the installed version, so
ohm refuses to upgrade with:
warning: libva-v4l2-request-fourier: local (1:1.0.0.r361.cf8cd9d-1) is
newer than marfrit (1.0.0.r376.de27e95-1)
Restoring epoch=1 fixes the monotonic version chain.
CI binary segfaulted on HEVC vaEndPicture even though
/etc/makepkg.conf has OPTIONS=(... !lto ...). Root cause: arch-meson's
wrapper hard-codes `-D b_lto=true` regardless of makepkg.conf, so
the binary still gets cross-function ICF (Identical Code Folding)
under -O2 + LTO.
HEVC is the only codec in the campaign that submits a per-frame chain
of 4 control structs (SPS + PPS + DECODE_PARAMS + SLICE_PARAMS); ICF
finds a near-duplicate per-codec helper across the codec dispatch and
merges them, then the wrong instance's local stack layout is invoked
on the HEVC path → SEGV. The other 4 codecs (H.264, VP8, VP9, MPEG-2)
submit fewer/simpler control structs and tolerate the folding by
accident.
Empirical confirmation from the issue body's binary bisection:
meson build (default debugoptimized) 485 KB HEVC ✓
arch-meson + --buildtype=release 145 KB HEVC ✓
arch-meson + release + -flto 76 KB HEVC SEGV
CI build (this package, 7ac934e-1) 133 KB HEVC SEGV
Fix: append `-Db_lto=false` to the arch-meson invocation.
pkgrel 1 -> 2.
Carries the fork from libva-multiplanar iter8 close (2026-05-06) to
fresnel-fourier iter38b (2026-05-14): multi-device probe so a single
libva session serves rkvdec (H.264 + HEVC + VP9) + hantro (MPEG-2 +
VP8) without LIBVA_V4L2_REQUEST_VIDEO_PATH overrides, plus the
MAX_PROFILES bounds-check fix from iter38b.
Required by the fresnel-fourier README's HW-decode stack (vainfo
exposes all 10 profiles in one session, byte-exact bench verified
across 5 codecs).
68 commits between the old pin (65969da3) and the new (7ac934e0).
pkgver() recomputes the rev count at build time; the static placeholder
is bumped from r280 to r348 to reflect the new pin.
Production-tip successor to the experimental libva-v4l2-request-ohm-gl-fix
(tarball + 18-patch stack, never published). Tracks the libva-multiplanar
campaign fork's git history directly via git+commit pin, so iteration
sweeps land in a clean linear log instead of a growing patch stack.
Pinned commit 65969da3 = libva-multiplanar iter8 close (last commit on
master before fresnel-fourier work began layering MPEG-2 rewrites on top
2026-05-08). Promote to a later pin only after a future iteration closes
cleanly.
Workflow job mirrors ffmpeg-v4l2-request-aarch64 (same fermi LXC runner,
same makepkg → sign → repo-add → rsync-to-nc.reauktion.de pattern), and
chains via needs: ffmpeg-v4l2-request-aarch64 to serialize marfrit.db
updates. nasm dropped from bootstrap (libva has no x264-style asm).
replaces=(libva-v4l2-request libva-v4l2-request-ohm-gl-fix) covers both
stock Arch and locally-installed predecessor copies; predecessor was
never published so no marfrit.db collision.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
claude-noether
marfrit
test0r
claude-noether