The original 0005 patch was generated from the pre-Phase-5-review source snapshot (phase5_review_input_2026-05-21.tgz), missing the four load-bearing review fixes that landed in the post-review snapshot: - probe_hantro gate on KHR_video_* extension advertisement - per-session ts_counter (was process-global static) - panvk_v4l2_session_finish full unwind (munmap + STREAMOFF + REQBUFS=0) - MIN2(rb.count, 18) clamp on num_*_buffers Run #162 (job 17032) failed in prepare() because the PKGBUILD sanity check 'grep -q "KHR_video_queue = PAN_ARCH < 9 && panvk_v4l2_probe_hantro()"' didn't match the actual patched output (which still had the pre-review 'KHR_video_queue = PAN_ARCH < 9,'). This patch (regenerated from phase5_post_review_2026-05-21.tgz) carries all four review fixes. Validated locally: vanilla mesa-26.0.6 + r1..r4 + this patch reproduces prepare()-OK byte-for-byte. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
mesa-panvk-bifrost-video
Patched Mesa libvulkan_panfrost.so that adds VK_KHR_video_decode_h264 on Mali Bifrost SBCs (PAN_ARCH 6/7, RK3566/RK3568 class hardware), backed by the SoC's V4L2-stateless hantro VPU.
This is a sibling of mesa-panvk-bifrost (the r4 package that exposes Bifrost to Chromium's Vulkan compositor). Pick this one when the consumer wants Vulkan video decode in addition; pick r4 for compositor-only.
Status
Phase 4 byte-exact validated 2026-05-21: 48/48 unique BBB display frames decoded by this package are byte-identical to ffmpeg+libva-v4l2-request-fourier running on the same hantro hardware. Phase 5 second-model review completed; all load-bearing findings addressed. First publish via marfrit-packages CI 2026-05-22 (PR #79 merge did not auto-fire Actions; this re-trigger restores the standard build/sign/publish path).
How to use
# Co-installs alongside r4 and stock mesa.
sudo pacman -S mesa-panvk-bifrost-video
# Opt in (not on the default loader search path).
export VK_ICD_FILENAMES=/usr/lib/panvk-bifrost-video/icd.json
export PAN_I_WANT_A_BROKEN_VULKAN_DRIVER=1 # mesa-upstream gate
# Run a Vulkan video consumer.
vulkan-video-dec-simple-test -i your.h264 --codec h264 --noPresent --maxFrameCount 50
# or
ffmpeg -hwaccel vulkan -i your.mp4 ...
Phase 1 limitations
Documented in source comments and worth knowing before relying on this in production:
- Single video session per device. Concurrent
VkVideoSessionKHRon the same device clobber each other (active_videosingleton). Sufficient for current single-stream consumers. - Synchronous decode at record time. The full V4L2 ioctl dance runs to completion inside
vkCmdDecodeVideoKHR. No pipelining. Throughput is bounded by hantro's ~1.16× realtime on 1080p H.264. - Hardcoded
/dev/video1+/dev/media0. Matches RK3566/68 but won't work on other SoCs without a topology-walk port (seelibva-v4l2-request-fourierfor the full version). - Bitstream source buffer assumed HOST_VISIBLE. True on panvk-bifrost (no DEVICE_LOCAL-only memory types exist), but the code silently skips decode if the app bound the buffer to non-host-visible memory.
Co-existence
- Installs to
/usr/lib/panvk-bifrost-video/— parallel to r4's/usr/lib/panvk-bifrost/and stock/usr/lib/. - Opt-in via
VK_ICD_FILENAMES; does NOT register itself in/usr/share/vulkan/icd.d/. - Three drivers coexist without conflict; the user picks at runtime which to use.