Mesa 18 breaks mpv output when VA-API does the decoding

[frumble]

mpv 0.27.2, Arch Linux

Reproduction steps: Play a H.264 or H.265 file using hardware-accelerated decoding via libva-mesa-driver. Minimal mpv config to reproduce it: hwdec=vaapi opengl-hwdec-interop=vaapi-glx (I need this because I’m using a Radeon RX 580 with AMDGPU driver).

This occurred after upgrading from libva-mesa-driver 17.3.7-1 → 18.0.0-2.

Expected behavior: It should play the video correctly, obviously.

Actual behavior: Blocky red rendering.

Log file: https://0x0.st/susj.txt

[lanzorg]

Did you try a more recent mpv version? https://aur.archlinux.org/packages/mpv-build-git/

[Gusar321]

Note that vaapi-glx is gone from mpv, 0.27 is the last version that still has it. Ideally, you should switch to mesa-git and mpv-git, which will give you vaapi-egl.

That said, try this: allow_rgb10_configs=false mpv somefile.mp4

[frumble]

I have tried mpv-build-git, same problem. There wasn’t a MPV update recently, just the Mesa 18 update which broke screen rendering.

Thanks, allow_rgb10_configs=false does the trick (put it in my /etc/environment). Other applications seem to be affected by this rendering issue with Mesa 18 too. Does mesa-git already have the vaapi-egl patches mainlined? I would rather not want to use a development release of my central graphics library… Well, it works for now and I could just suppress further MPV updates above 0.27.x if this situation does not get ironed out in time. Else, removing vaapi-glx ahead of time would basically cut off all AMDGPU users from accelerated decoding.

[sjnewbury]

libva-egl has been removed from libva. libva-glx support has been removed from mpv. So now what? Is there a new interop option I'm missing?

[ghost]

Please complain to Mesa and libav about dragging their feet, not mpv.

[Gusar321]

libva-egl is a completely separate thing, wasn't used anywhere, so its removal from libva is of no consequence.

What's needed for vaapi-egl on AMD is support for vaExportSurfaceHandle(). The good news is that mesa-18.0.1 has it! Arch already ships that, if your distro doesn't, complain to them :). You also need libva-2.1, ffmpeg-4.0 and mpv-git (until there's a 0.29 release).

[sjnewbury]

@Gusar321 I'm on intel, using git libva/libva-intel-driver, git mesa, but mpv-0.27.2.20171027 from Gentoo. For me hwaccel=vaapi used to work perfectly with the gl/gpu vo backend, but now only vaapi-copy works. This is since updating to libva-2 where libva-egl was dropped so I (mistakenly?) associated the failure to the lack of interop between the X11 gl backend and vaapi. I will recheck, but I think it's working under wayland fwiw.

[frumble]

@Gusar321 Are you sure it’s already in Mesa 18.0.1? In the Arch forum you have said that it will come with Mesa 18.1: https://bbs.archlinux.org/viewtopic.php?pid=1778658#p1778658

[Gusar321]

@frumble It wasn't in 18.0, and I didn't expect them to activate it in a point release. But they did, check the changelog for 18.0.1

[frumble]

So, we are finally here now: mesa 18.0.3 mpv 0.28.0-567-ge5b2af0a80 built on Tue May 15 (mesa-git) ffmpeg library versions: libavutil 56.14.100 libavcodec 58.18.100 libavformat 58.12.100 libswscale 5.1.100 libavfilter 7.16.100 libswresample 3.1.100 ffmpeg version: 4.0 libva 2.1

And I still can’t get it to work. Neither "hwdec=vaapi" nor "hwdec=vaapi-egl" does activate hardware decoding. Do I use the wrong option or is this just not ready yet? Even more pressing as Arch has rolled out mpv 0.28 over 0.27 and now the glx interop is gone but I also can’t downgrade to 0.27 because it depends on old ffmpeg libs ("libavdevice.so.57").

[Jj0YzL5nvJ]

Works fine for me: https://0x0.st/sePW.txt

$ vainfo

libva info: VA-API version 0.40.1
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_0_40
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.40 (libva 1.8.4.pre1)
vainfo: Driver version: Mesa Gallium driver 18.2.0-devel - padoka PPA for Radeon RX 560 Series (POLARIS11, DRM 3.18.0, 4.13.0-41-generic, LLVM 7.0.0)
vainfo: Supported profile and entrypoints
EE ../../../../../../src/gallium/drivers/radeonsi/si_get.c:648 si_get_video_param UVD - No MJPEG support for the kernel version
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain10             : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc

[frumble]

Cool, thanks! vo=vaapi was missing in my config. Works for me now! Just an annoyance: Overlays are blurred (position bar, font, and "stats" script font) when the material is upscaled (anything beneath UHD). Is this supposed to be so or a bug? Further, when I’m hovering over the position bar in fullsceen, it disappears. Hope this is just a bug?

[ghost]

This is the quality Intel wants you to have. Don't annoy us with this shit.

[ArchangeGabriel]

@frumble Have you tried vo=gpu instead? Or even vo=gpu-hq?

[frumble]

@ArchangeGabriel They are both falling back to CPU decoding.

[Gusar321]

Overlays are blurred (position bar, font, and "stats" script font) when the material is upscaled (anything beneath UHD). Is this supposed to be so or a bug?

That's mesa's fault, it doesn't support VA_SUBPICTURE_DESTINATION_IS_SCREEN_COORD, so subpictures (osd/subtitles) are rendered in video resolution instead of screen resolution.

Don't use vo=vaapi, especially on non-Intel. Even on Intel you're better off with vo=gpu.

[frumble]

First of all, @Jj0YzL5nvJ’s log was mentioning vo=vaapi and hwdec=vaapi too. So, this was my source to begin with. I would like to use vo=gpu, but like I was explaining before, vo=gpu does fall back to CPU decoding. Here is a log.

[Jj0YzL5nvJ]

On ATI/AMD GPUs, hwdec=vaapi only works with vo=vaapi. Using hwdec=vaapi-copy and vo=gpu is possible, but cause frame drops in some cases... 4K HEVC 10-bit videos, at least for me (Old PC?). So vo=vaapi + hwdec=vaapi is faster, but breaks the OSC in resized windows, the OSC works fine in fullscreen and in not resized videos.

I prefer VDPAU over VAAPI, but for HEVC 10-bit videos, mpv simply fall back. AMD+VDPAU is broken with vo=gpu not matter what gpu-context you use with HEVC 8-bit videos (works with vo=vdpau + hwdec=vdpau too). VAAPI is the only working option to archive general hardware acceleration on H.265/HEVC codecs for AMD GPU owners.

[Gusar321]

On ATI/AMD GPUs, hwdec=vaapi only works with vo=vaapi.

That's not true anymore, see a few comments above. vaapi-egl (and so hwdec=vaapi with vo=gpu) works on AMD, provided you have the necessary software components.

@frumble: Your mpv doesn't load x11egl. Check your settings, maybe you're forcing the glx context somewhere. Or try forcing the egl context with --gpu-context=x11egl

[Jj0YzL5nvJ]

Nope...

$ mpv --no-config --fs --vo=gpu --gpu-context=x11egl --hwdec=vaapi --log-file=/tmp/va1.txt jellyfish-400-mbps-4k-uhd-hevc-10bit.mkv
Playing: jellyfish-400-mbps-4k-uhd-hevc-10bit.mkv
 (+) Video --vid=1 (*) (hevc 3840x2160 29.970fps)
mesa: for the -simplifycfg-sink-common option: may only occur zero or one times!
[vo/gpu/vaapi-egl] vaDeriveImage() failed (invalid VASurfaceID)
[vo/gpu/vaapi-egl] vaDeriveImage() failed (invalid VAImageFormat)
[vo/gpu/vaapi-egl] vaDeriveImage() failed (invalid VAImageFormat)
[vo/gpu/drmprime-drm] Failed to retrieve DRM fd from native display.
VO: [gpu] 3840x2160 yuv420p10
V: 00:00:30 / 00:00:30 (99%) Dropped: 314

Exiting... (End of file)

https://0x0.st/seav.txt

$ mpv --no-config --fs --vo=gpu --gpu-context=x11egl --hwdec=vaapi-copy --log-file=/tmp/va2.txt jellyfish-400-mbps-4k-uhd-hevc-10bit.mkv
Playing: jellyfish-400-mbps-4k-uhd-hevc-10bit.mkv
 (+) Video --vid=1 (*) (hevc 3840x2160 29.970fps)
mesa: for the -simplifycfg-sink-common option: may only occur zero or one times!
EE ../../../../../../src/gallium/drivers/radeonsi/si_get.c:648 si_get_video_param UVD - No MJPEG support for the kernel version
EE ../../../../../../src/gallium/drivers/radeonsi/si_get.c:648 si_get_video_param UVD - No MJPEG support for the kernel version
Using hardware decoding (vaapi-copy).
VO: [gpu] 3840x2160 p010
V: 00:00:30 / 00:00:30 (99%) Dropped: 577

Exiting... (End of file)

https://0x0.st/seaw.txt

Compare this to the first one

[frumble]

Works for me! mpv --no-config --vo=gpu --hwdec=vaapi --gpu-context=x11egl movie.mkv HDR seems to render fine too but I’m experiencing way more brightness flickering than with 0.27, it makes it almost impossible to enjoy a flick, hdr-compute-peak=yes does not seem to help. Edit: Does only seem to affect usage with my config file. Here it is. Tested with and without hdr-compute-peak=yes and with and without the scaling parameters.

[Gusar321]

@Jj0YzL5nvJ: Your libva is too old. The API version needs to be 1.1.0, yours is 0.40.1. libva-2.1.0 provides the necessary API. Once you have the correct libva, you need to recompile all of mesa, ffmpeg and mpv.

[laichiaheng]

@frumble hdr-compute-peak=yes is horrible, and it is enabled by default, try hdr-compute-peak=no, it will be much better.

[avalonwilliams]

Has anybody opened a bug ticket for mesa yet? Because this sounds like an upstream problem. I've been having this problem for days and was able to reproduce this behavior as well, but it seems that this is not mpv's fault, as I'm able to reproduce the same behavior in gnome videos (totem), and gst-launch, so opening a bug report upstream seems to be the most logical thing to do.

[Akemi]

stale issue.

[seadra]

I bumped into this issue on Manjaro Linux, using nouveau. Seeing scrambled weird coloring, and makes the computer almost completely non-responsive.

[ghost]

What makes you think this is the same issue?

[seadra]

emacs bot?

Because it fits the same description with the only difference being nouveau. Uninstalling libva-mesa-driver "fixes" the issue.