mpv
mpv copied to clipboard
gpu-next screenshot fails with ewa filter functions on SDR and Dolby Vision
Important Information
$ mpv --version
mpv v0.37.0-484-g665a472098 Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
libplacebo version: v6.338.2
FFmpeg version: N-113989-gd34e9a81b1
FFmpeg library versions:
libavutil 58.40.100
libavcodec 60.41.100
libavformat 60.24.100
libswscale 7.6.100
libavfilter 9.17.100
libswresample 4.14.100
Arch Linux BSPWM 0.9.10-51-gaf3bd8b Locally compiled with mpv-full-gitAUR NVIDIA 3070 Ti, 550.54.14
Reproduction steps
- Choose an SDR or Dolby Vision
$VIDEO -
mpv --no-config --vo=gpu-next --scale=ewa_lanczos $VIDEO mpv --no-config --vo=gpu-next --scale=ewa_lanczossharp $VIDEO mpv --no-config --vo=gpu-next --scale=ewa_lanczos4sharpest $VIDEO - Use
screenshotorscreenshot videoinput mode commands. - Observe blank screenshots taken
📝 Note: Any non-EWA filter function works fine, but scale=ewa_lanczossharp is used by both --profile=gpu-hq & --profile=high-quality which is how I first noticed the issue.
Expected behavior
Take a screenshot with gpu-next when using --scale=ewa_lanczossharp.
Actual behavior
When viewing an SDR or Dolby Vision video with --vo=gpu-next and taking a screenshot with any ewa_* filter function set as --scale results in screenshots with the correct resolution, but completely black-filled.
Does not seem to occur with HDR10 video (common on YouTube).
The same result is seen with every --hwdec option available to me, including --hwdec=no.
I tried compiling without zimg (-Dzimg=disabled), but got the same result.
📝 NOTE: The screenshot window input mode command does work as expected, but screenshot video has the same broken behavior as screenshot.
| Input Command | Format | chk |
|---|---|---|
screenshot |
SDR | ❌ |
screenshot |
DV | ❌ |
screenshot |
HDR10 | ✅ |
screenshot video |
SDR | ❌ |
screenshot video |
DV | ❌ |
screenshot video |
HDR10 | ✅ |
screenshot window |
SDR | ✅ |
screenshot window |
DV | ✅ |
screenshot window |
HDR10 | ✅ |
Log file
Logs show an example of taking a screenshot of an SDR video.
With zimg disabled:
Workaround
Using --screenshot-sw=yes allows screenshot input mode command to work with SDR and Dolby Vision video, however the screenshot window result is stretched and distorted when using vo=gpu-next with screen-shot-sw=yes.
I did not do testing to see if the colors were accurate with this workaround and HDR video.
Looks like it may be an issue with --gpu-api=opengl which is the default. If you use --gpu-api=vulkan, I can't reproduce it. Can you?
I can also only reproduce this on Nvidia+OpenGL.
I cannot reproduce the issue with --gpu-api=vulkan. All three screenshot input mode commands works as expected with all three tested formats: SDR, HDR10, and Dolby Vision.
mpv --no-config --vo=gpu-next --gpu-api=vulkan --scale=ewa_lanczos $VIDEO
This is a good enough a fix for my use case. I do not require opengl.
This is also reproducible on Windows with Nvidia+OpenGL. Using ewa scaler also causes black frame after resizing and sometimes after toggling stats, on both Windows and Linux.
I would debug that, but I don't have NVIDIA gpu and seem to does not happen on AMD in any platform I tested. It is probably fixable if we understand what exactly causes screenshot render to fail.
This is caused by --cscale=ewa_lanczossharp specifically instead of --scale. Also when taking png, webp or jxl screenshots with a transparent background, the screenshots are transparent instead of black.
This is also reproducible on Windows with Nvidia+OpenGL. Using ewa scaler also causes black frame after resizing and sometimes after toggling stats, on both Windows and Linux.
If you resize while paused the video actually disappears until you play again. Also with --video-sync=display-resample it shows a black frame after every seek. With --background-color=0/0 in mpv.conf it shows the wallpaper instead when zooming out and seeking, but not if you set --background-color at runtime or zoom in, and it doesn't show background colors other than black otherwise.
https://github.com/mpv-player/mpv/issues/11499#issuecomment-2380425327 prevents the bug.