New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
frumble opened this Issue Apr 6, 2018 · 24 comments

Comments

Projects
None yet
9 participants
@frumble

frumble commented Apr 6, 2018

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

This comment has been minimized.

lanzorg commented Apr 6, 2018

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

@Gusar321

This comment has been minimized.

Contributor

Gusar321 commented Apr 6, 2018

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

This comment has been minimized.

frumble commented Apr 6, 2018

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.

@frumble frumble closed this Apr 6, 2018

@frumble frumble reopened this Apr 6, 2018

@sjnewbury

This comment has been minimized.

sjnewbury commented Apr 30, 2018

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?

@wm4

This comment has been minimized.

Contributor

wm4 commented Apr 30, 2018

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

@Gusar321

This comment has been minimized.

Contributor

Gusar321 commented Apr 30, 2018

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

This comment has been minimized.

sjnewbury commented May 1, 2018

@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

This comment has been minimized.

frumble commented May 1, 2018

@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

This comment has been minimized.

Contributor

Gusar321 commented May 1, 2018

@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

This comment has been minimized.

frumble commented May 14, 2018

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

This comment has been minimized.

Jj0YzL5nvJ commented May 15, 2018

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

This comment has been minimized.

frumble commented May 15, 2018

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?

@wm4

This comment has been minimized.

Contributor

wm4 commented May 15, 2018

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

@ArchangeGabriel

This comment has been minimized.

ArchangeGabriel commented May 15, 2018

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

@frumble

This comment has been minimized.

frumble commented May 15, 2018

@ArchangeGabriel They are both falling back to CPU decoding.

@Gusar321

This comment has been minimized.

Contributor

Gusar321 commented May 15, 2018

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

This comment has been minimized.

frumble commented May 15, 2018

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

This comment has been minimized.

Jj0YzL5nvJ commented May 15, 2018

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

This comment has been minimized.

Contributor

Gusar321 commented May 16, 2018

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

This comment has been minimized.

Jj0YzL5nvJ commented May 16, 2018

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

This comment has been minimized.

frumble commented May 16, 2018

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

This comment has been minimized.

Contributor

Gusar321 commented May 16, 2018

@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

This comment has been minimized.

laichiaheng commented May 22, 2018

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

@AGitBoy

This comment has been minimized.

AGitBoy commented Oct 11, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment