VP9 video vulkan decoding is not functional (VK_ERROR_DEVICE_LOST with ffmpeg n8.0.1)

mpv Information

mpv v0.41.0 Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
 built on Dec 22 2025 14:58:51
libplacebo version: v7.351.0
FFmpeg version: n8.0.1
FFmpeg library versions:
   libavcodec      62.11.100
   libavdevice     62.1.100
   libavfilter     11.4.100
   libavformat     62.3.100
   libavutil       60.8.100
   libswresample   6.1.100
   libswscale      9.1.100

Other Information

- Linux version: Arch Linux
- Kernel Version: 6.18.2-bczhc-dirty
- GPU Model: Intel TigerLake-H GT1 [UHD Graphics]
- Mesa/GPU Driver Version: Mesa 25.3.4
- Window Manager and Version: Wayland 1.24.0, Hyprland 0.53.3
- Source of mpv: The latest git `master` db22a452.
- Latest known working version: Unknown
- Issue started after the following happened: Unknown

Reproduction Steps

1. Run ANV_DEBUG=video-decode build/mpv --hwdec=vulkan --vulkan-device=Intel\(R\)\ UHD\ Graphics\ \(TGL\ GT1\) --no-config --log-file=~/mpv.log scene.mkv.
2. Run ANV_DEBUG=video-decode build/mpv --hwdec=vulkan --vulkan-device=Intel\(R\)\ UHD\ Graphics\ \(TGL\ GT1\) --no-config --log-file=~/mpv.log profile2.mkv
3. Observe the result.

Expected Behavior

mpv starts playback normally.

Actual Behavior

For 1., mpv refuses to start and VK_ERROR_DEVICE_LOST is emitted; for 2., the playback is very glitching.

Glitch screen for profile2.mkv:

Log File

scene.mkv.mpv.log
profile2.mkv.mpv.log

Sample Files

https://drive.google.com/drive/folders/1fMbQlRI7uAnMVIkJFrVwCngIqqf5k64T?usp=sharing

Additional information

Info of the two sample videos:

~ ❯ ffprobe -hide_banner scene.mkv                                             22:44:03
Input #0, matroska,webm, from 'scene.mkv':
  Metadata:
    ENCODER         : Lavf62.3.100
  Duration: 00:00:10.01, start: 0.007000, bitrate: 2037 kb/s
  Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv, bt709), 1920x1080, SAR 1:1 DAR 16:9, 30 fps, 30 tbr, 1k tbn, start 0.007000 (default)
    Metadata:
      DURATION        : 00:00:10.007000000
~ ❯ ffprobe -hide_banner profile2.mkv                                          22:44:08
Input #0, matroska,webm, from 'profile2.mkv':
  Metadata:
    ENCODER         : Lavf62.3.100
  Duration: 00:00:10.01, start: 0.000000, bitrate: 28991 kb/s
  Stream #0:0(eng): Video: vp9 (Profile 2), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160, SAR 1:1 DAR 16:9, 59.94 fps, 59.94 tbr, 1k tbn (default)
    Metadata:
      DURATION        : 00:00:10.009000000
    Side data:
      Content light level metadata: MaxCLL=1000, MaxFALL=400
      Mastering display metadata: has_primaries:1 has_luminance:1 r(0.6800,0.3200) g(0.2650,0.6900) b(0.1500 0.0600) wp(0.3127, 0.3290) min_luminance=0.000100, max_luminance=1000.000000

---

When I switched to the latest FFmpeg master branch (both via manually compiling+installing ffmpeg source and running mpv with LD_LIBRARY_PATH=/usr/local/lib, or just via installing ffmpeg-git from AUR), situations changed:

For scene.mkv, mpv is able to play, but the video is glitching in the same pattern as profile2.mkv exhibits above. At ~5th (at which the new keyframe starts) second, it recovers to normal. When I seek it, it will begin glitching again. Glitch screenshot:

For profile2.mkv, playback is normal. No glitches.

I carefully read all instruction and confirm that I did the following:

• I tested with the latest mpv version to validate that the issue is not already fixed.
• I provided all required information including system and mpv version.
• I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
• I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• I attached the full, untruncated log file.
• I attached the backtrace in the case of a crash.

Start by reproducing the issue with the two commands, sample files, and attached logs, then compare behavior with FFmpeg n8.0.1 and the latest FFmpeg master as described. The issue names no mpv source file or test; done means both VP9 samples play without VK_ERROR_DEVICE_LOST or visible glitches on the reported setup.