Installation type
Flatpak (.flatpak)
Version
1.0.3
Platform
Fedora 43
Desktop Environment
GNOME
Windowing System
Wayland
GPU
Intel Arc Graphics (Meteor Lake, Core Ultra 9 185H) — i915, Mesa 26.1.4 in the runtime
Describe the bug
Follow-up to #63 — the Vulkan path that fixed Intel there is fragile on Meteor Lake, and there is no working VAAPI fallback behind it, so playback silently ends up in software decoding.
Playing 4K HEVC 10-bit (Dolby Vision, p010) content. Playback starts hardware-decoded via hevc-vulkan-copy, but seeking kills the Vulkan decoder with VK_ERROR_DEVICE_LOST. mpv then walks the remaining copy hwdecs and hevc-vaapi-copy fails with "Could not create device" (no AVHWDeviceContext output at all, so it never reaches ffmpeg device creation), and the rest of the session runs on software decode: ~2.5 cores CPU, laptop at 75°C for a full episode. Nothing in the UI indicates the fallback.
Two distinct problems:
1- hevc-vulkan-copy dies on seek with VK_ERROR_DEVICE_LOST (Mesa ANV / Meteor Lake — likely a driver bug, I may report it to Mesa separately). Practical impact: the only hwdec the shell can use on this hardware is one seek away from silent software fallback.
2- hevc-vaapi-copy can never create a device in the flatpak build, so there is no fallback. This also happens on a fresh start, tested by hiding Vulkan (VK_DRIVER_FILES pointed at a nonexistent file) so the auto-copy probe gets past vulkan-copy: vaapi-copy still fails instantly.
The non-copy vaapi interop works fine. If I intercept the hwdec property and replace the "auto-copy" coming from stremio-video (ShellVideo.js hardcodes it on Linux) with "vaapi" via a small LD_PRELOAD shim around mpv_set_property, decoding runs on the VAAPI/iHD path and survives 20+ consecutive seeks with zero decode errors at ~0.3–0.5 cores CPU.
Suggestion: send/allow hwdec=auto so the already-working EGL dmabuf vaapi interop can be picked, and/or fix the libmpv build so a standalone VAAPI device can be created and -copy works. Full RUST_LOG=debug logs available on request.
Logs
Session A — normal playback, crash on seek (RUST_LOG=debug):
[vd] Decoder format: 3840x1920 p010 dolbyvision/bt.2020/pq/limited/auto CL=mpeg2/4/h264 Using hardware decoding (vulkan-copy). ... [cplayer] hr-seek, skipping to 2271.009000 [ffmpeg/video] hevc: Decoding frame, 301153 bytes, 1 slices [ffmpeg/video] hevc: Unable to perform query: VK_ERROR_DEVICE_LOST! [ffmpeg/video] hevc: hardware accelerator failed to decode picture Error while decoding frame (hardware decoding)! (same error two more times on the next frames) [ffmpeg] vk: Unable to submit command buffer: VK_ERROR_DEVICE_LOST Attempting next decoding method after failure of hevc-vulkan-copy. [vd] Looking at hwdec hevc-nvdec-copy... [ffmpeg] AVHWDeviceContext: Cannot load libcuda.so.1 [vd] Could not create device. [vd] Looking at hwdec hevc-vaapi-copy... [vd] Could not create device. [vd] Looking at hwdec hevc-vdpau-copy... [ffmpeg] AVHWDeviceContext: Cannot open the X11 display . [vd] Could not create device. [vd] Using software decoding.
Session B — fresh start with Vulkan hidden, to isolate the vaapi-copy failure:
[vd] Looking at hwdec hevc-vulkan-copy... [ffmpeg] AVHWDeviceContext: Instance creation failure: VK_ERROR_INCOMPATIBLE_DRIVER [vd] Could not create device. [vd] Looking at hwdec hevc-vaapi-copy... [vd] Could not create device. [vd] Using software decoding.
Session C — hwdec forced to "vaapi" (non-copy) via LD_PRELOAD shim:
[cplayer] Set property: hwdec="vaapi" -> 1 [vd] Trying hardware decoding via hevc-vaapi. Using hardware decoding (vaapi). (20+ hr-seeks follow in the same session, zero decode errors, no fallback)
Versions from the same logs: mpv v0.41.0, FFmpeg 7.1.3, Mesa 26.1.4, VA-API 1.22 (iHD 26.2.2 via org.freedesktop.Platform.VAAPI.Intel 25.08).
Installation type
Flatpak (.flatpak)
Version
1.0.3
Platform
Fedora 43
Desktop Environment
GNOME
Windowing System
Wayland
GPU
Intel Arc Graphics (Meteor Lake, Core Ultra 9 185H) — i915, Mesa 26.1.4 in the runtime
Describe the bug
Follow-up to #63 — the Vulkan path that fixed Intel there is fragile on Meteor Lake, and there is no working VAAPI fallback behind it, so playback silently ends up in software decoding.
Playing 4K HEVC 10-bit (Dolby Vision, p010) content. Playback starts hardware-decoded via hevc-vulkan-copy, but seeking kills the Vulkan decoder with VK_ERROR_DEVICE_LOST. mpv then walks the remaining copy hwdecs and hevc-vaapi-copy fails with "Could not create device" (no AVHWDeviceContext output at all, so it never reaches ffmpeg device creation), and the rest of the session runs on software decode: ~2.5 cores CPU, laptop at 75°C for a full episode. Nothing in the UI indicates the fallback.
Two distinct problems:
1- hevc-vulkan-copy dies on seek with VK_ERROR_DEVICE_LOST (Mesa ANV / Meteor Lake — likely a driver bug, I may report it to Mesa separately). Practical impact: the only hwdec the shell can use on this hardware is one seek away from silent software fallback.
2- hevc-vaapi-copy can never create a device in the flatpak build, so there is no fallback. This also happens on a fresh start, tested by hiding Vulkan (VK_DRIVER_FILES pointed at a nonexistent file) so the auto-copy probe gets past vulkan-copy: vaapi-copy still fails instantly.
The non-copy vaapi interop works fine. If I intercept the hwdec property and replace the "auto-copy" coming from stremio-video (ShellVideo.js hardcodes it on Linux) with "vaapi" via a small LD_PRELOAD shim around mpv_set_property, decoding runs on the VAAPI/iHD path and survives 20+ consecutive seeks with zero decode errors at ~0.3–0.5 cores CPU.
Suggestion: send/allow hwdec=auto so the already-working EGL dmabuf vaapi interop can be picked, and/or fix the libmpv build so a standalone VAAPI device can be created and -copy works. Full RUST_LOG=debug logs available on request.
Logs
Session A — normal playback, crash on seek (RUST_LOG=debug):
[vd] Decoder format: 3840x1920 p010 dolbyvision/bt.2020/pq/limited/auto CL=mpeg2/4/h264 Using hardware decoding (vulkan-copy). ... [cplayer] hr-seek, skipping to 2271.009000 [ffmpeg/video] hevc: Decoding frame, 301153 bytes, 1 slices [ffmpeg/video] hevc: Unable to perform query: VK_ERROR_DEVICE_LOST! [ffmpeg/video] hevc: hardware accelerator failed to decode picture Error while decoding frame (hardware decoding)! (same error two more times on the next frames) [ffmpeg] vk: Unable to submit command buffer: VK_ERROR_DEVICE_LOST Attempting next decoding method after failure of hevc-vulkan-copy. [vd] Looking at hwdec hevc-nvdec-copy... [ffmpeg] AVHWDeviceContext: Cannot load libcuda.so.1 [vd] Could not create device. [vd] Looking at hwdec hevc-vaapi-copy... [vd] Could not create device. [vd] Looking at hwdec hevc-vdpau-copy... [ffmpeg] AVHWDeviceContext: Cannot open the X11 display . [vd] Could not create device. [vd] Using software decoding.
Session B — fresh start with Vulkan hidden, to isolate the vaapi-copy failure:
[vd] Looking at hwdec hevc-vulkan-copy... [ffmpeg] AVHWDeviceContext: Instance creation failure: VK_ERROR_INCOMPATIBLE_DRIVER [vd] Could not create device. [vd] Looking at hwdec hevc-vaapi-copy... [vd] Could not create device. [vd] Using software decoding.
Session C — hwdec forced to "vaapi" (non-copy) via LD_PRELOAD shim:
[cplayer] Set property: hwdec="vaapi" -> 1 [vd] Trying hardware decoding via hevc-vaapi. Using hardware decoding (vaapi). (20+ hr-seeks follow in the same session, zero decode errors, no fallback)
Versions from the same logs: mpv v0.41.0, FFmpeg 7.1.3, Mesa 26.1.4, VA-API 1.22 (iHD 26.2.2 via org.freedesktop.Platform.VAAPI.Intel 25.08).