mpv-player
Fullscreen video playback corrupted with vo=gpu, gpu-api=vulkan, RADV on Mesa 25.0.2
-> Upstream issue on drm/amd#4057 <-
mpv Information
mpv v0.40.0 Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
built on Mar 25 2025 17:58:20
libplacebo version: v7.349.0
FFmpeg version: n7.1
FFmpeg library versions:
libavcodec 61.19.100
libavdevice 61.3.100
libavfilter 10.4.100
libavformat 61.7.100
libavutil 59.39.100
libswresample 5.3.100
libswscale 8.3.100
Other Information
- Linux version: Arch Linux
- Kernel Version: 6.13.8-zen1-1-zen
- GPU Model: AMD Radeon RX 9070 XT [1002:7550]
- Mesa/GPU Driver Version: Mesa 25.0.2-arch1.2
- Window Manager and Version: kwin 6.3.3.1-1
- Source of mpv: [Arch repos](https://archive.archlinux.org/packages/m/mpv/mpv-1%3A0.40.0-1-x86_64.pkg.tar.zst)
- Latest known working version: None
- Issue started after the following happened: Upgraded mpv to 0.40.0-1
- Note: Tested with 0.39.0-5, same thing :(
Reproduction Steps
Play any video with --no-config --gpu-api=vulkan, then enter fullscreen. (Setting --hwdec does not change the result.)
Expected Behavior
The video plays normally.
Actual Behavior
Video playback is corrupted, but can temporarily show the correct image if the mouse cursor moves around the focused mpv window (or an unfocused one if the movement triggers an OSD redraw).
Attempts to record the corruption with OBS Studio + PipeWire capture are not successful, so I tried to record what happens with a phone.
Setting --gpu-api=opengl resolves this issue, but something's very wrong with Vulkan. The same corruption occurs on 0.39.0.
Log File
- vulkan.txt - corrupted output
- opengl.txt - good output
- vulkaninfo.txt - extra, extra
- System fully up-to-date and rebooted before testing. Everything works normally, hardware acceleration in the browser and games works fine.
Sample Files
Any video file triggers this, but the demo was recorded with this YouTube video downloaded with yt-dlp. The video codec does not appear to matter.
I carefully read all instruction and confirm that I did the following:
- [x] I tested with the latest mpv version to validate that the issue is not already fixed.
- [x] I provided all required information including system and mpv version.
- [x] 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. - [x] I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
- [x] I attached the full, untruncated log file.
- [x] I attached the backtrace in the case of a crash.
Tested it on a RDNA3.5 laptop (Ryzen 8845HS) and the issue is not reproducible there. Maybe it's just an undercooked RDNA4 Vulkan driver?
Fullscreen corruption sounds like a driver bug yes. Probably worth seeing if you can reproduce with something else (fullscreen game that uses vulkan or something) and reporting to mesa.
Not yet, I did not find any other repro case since yesterday. I'll try this again with mesa-git and report upstream if it's still a thing.
Is there upstream issue reported?
https://gitlab.freedesktop.org/mesa/mesa/-/issues/12890
Ah, thanks - I submitted testing notes for latest mesa-git in that issue.
I have a HAINAN and I get this after 0.40 arrived, even in windowed mode.
[vo/gpu/libplacebo] vkQueueSubmit2: VK_ERROR_DEVICE_LOST (../src/vulkan/command.c:504)
[vo/gpu/libplacebo] Retrieving query pool results: VK_ERROR_DEVICE_LOST (../src/vulkan/gpu.c:105)
[vo/gpu/libplacebo] Retrieving query pool results: VK_ERROR_DEVICE_LOST (../src/vulkan/gpu.c:105)
[vo/gpu/libplacebo] Retrieving query pool results: VK_ERROR_DEVICE_LOST (../src/vulkan/gpu.c:105)
[vo/gpu/libplacebo] vkQueueSubmit2: VK_ERROR_DEVICE_LOST (../src/vulkan/command.c:504)
[vo/gpu/libplacebo] vkQueueSubmit2: VK_ERROR_DEVICE_LOST (../src/vulkan/command.c:504)
[vo/gpu/libplacebo] Retrieving query pool results: VK_ERROR_DEVICE_LOST (../src/vulkan/gpu.c:105)
[vo/gpu/libplacebo] vkQueueSubmit2: VK_ERROR_DEVICE_LOST (../src/vulkan/command.c:504)
[vo/gpu/libplacebo] Retrieving query pool results: VK_ERROR_DEVICE_LOST (../src/vulkan/gpu.c:105)
[vo/gpu/libplacebo] vkQueueSubmit2: VK_ERROR_DEVICE_LOST (../src/vulkan/command.c:504)
[vo/gpu/libplacebo] Retrieving query pool results: VK_ERROR_DEVICE_LOST (../src/vulkan/gpu.c:105)
[vo/gpu/libplacebo] vkQueueSubmit2: VK_ERROR_DEVICE_LOST (../src/vulkan/command.c:504)
[vo/gpu/libplacebo] Retrieving query pool results: VK_ERROR_DEVICE_LOST (../src/vulkan/gpu.c:105)
[vo/gpu/libplacebo] vkQueueSubmit2: VK_ERROR_DEVICE_LOST (../src/vulkan/command.c:504)
[vo/gpu/libplacebo] Retrieving query pool results: VK_ERROR_DEVICE_LOST (../src/vulkan/gpu.c:105)
[vo/gpu/libplacebo] vkQueueSubmit2: VK_ERROR_DEVICE_LOST (../src/vulkan/command.c:504)
[vo/gpu/libplacebo] Failed holding swapchain image for presentation
[vo/gpu] Failed presenting frame
Does this also happen with vo=gpu-next? And recent libplacebo-git?
EDIT: I'm asking about playback corruption issue. EDIT2: But it looks like corruption happens when direct scanout happens, see that showing OSC "fixes" it.
vo=gpu-next doesn't seem to work. I have an up to date Arch installation. I'll install libplacebo-git from AUR and report back.
vo=gpu-next doesn't seem to work. I have an up to date Arch installation. I'll install libplacebo-git from AUR and report back.
No. Not you, your post if off-topic in this thread. And duplicate of https://github.com/mpv-player/mpv/issues/16124 . This is different issue, about playback corruption that we are looking at in this issue.
Create your own ticket, if you like this fixed, probably for mesa again.
Does this also happen with
vo=gpu-next? And recent libplacebo-git?
Yes, this happens with both vo=gpu and vo=gpu-next, on both libplacebo 7.349.0-4 and latest mpv 38439dd + libplacebo 16ef0a26 (with up-to-date Arch, downloaded and built libplacebo, then entered meson devenv into the built libplacebo, cloned latest mpv, patched out meson.build:1285 -> libplacebo.pl_has_vulkan == 1 because it kept insisting it did not have Vulkan support even though it did, and finally rebuilt mpv). Here's the gpu-debug log for vo=gpu and vo=gpu-next.
In the upstream issue, someone noticed that enabling higher color accuracy in kwin (sets maxBpc to 16 instead of 10) on a given display causes the same display corruption. So it sounds like it might not even be a Mesa issue, but rather something between drm/amdgpu, etc...
In the upstream issue, someone noticed that enabling higher color accuracy in kwin (sets maxBpc to 16 instead of 10) on a given display causes the same display corruption. So it sounds like it might not even be a Mesa issue, but rather something between drm/amdgpu, etc...
This is probably correct. Does upgrading to 6.14 help? You might also want to report it here https://gitlab.freedesktop.org/drm/amd/-/issues
This is probably correct. Does upgrading to 6.14 help? You might also want to report it here gitlab.freedesktop.org/drm/amd/-/issues
Nope, still broken on 6.14, and I don't have balls to run master on my daily box right after the merge window opens. Running kwin with KWIN_DRM_NO_DIRECT_SCANOUT=1 fixes the issue, but setting higher color accuracy in kwin still glitches the display output, so there's that.
Turns out someone found and reported the kwin issue a week ago, so I'll submit extra details there.
I'm having the same issue using sway (no kwin), so I guess it must be the drm/amdgpu driver?
Popping by to note that vo=dmabuf-wayland seems to be another working option (EDIT: though under KDE this has the downside of not preventing monitors from going to sleep due to inactivity). Incidentally, is vo strictly a command-line option? I can't get it to work setting it in mpv.conf.
https://gitlab.freedesktop.org/drm/amd/-/issues/4057#note_2944710
It looks like Linux kernel 6.16 will have the AMD/mpv playback corruption fix merged. Otherwise you can compile a kernel with the patch.
Edit: Linux 6.12.36 and 6.15.5 now have the patch backported.
I can confirm this is no longer a problem with kernel 6.15.6. Closing, thanks all!