You are not logged in.
Hey, I have an AMD Radeon RX 580 and want to decode some high bitrate HEVC-10-bit 4K videos (H.265). Shouldn't be a problem, AMDGPU exposes HEVC_MAIN_10 to vdpau:
$ vdpauinfo
display: :0 screen: 0
API version: 1
Information string: G3DVL VDPAU Driver Shared Library version 1.0
Video surface:
name width height types
-------------------------------------------
420 16384 16384 NV12 YV12
422 16384 16384 UYVY YUYV
444 16384 16384 Y8U8V8A8 V8U8Y8A8
Decoder capabilities:
name level macbs width height
----------------------------------------------------
MPEG1 --- not supported ---
MPEG2_SIMPLE 3 65536 4096 4096
MPEG2_MAIN 3 65536 4096 4096
H264_BASELINE 52 65536 4096 4096
H264_MAIN 52 65536 4096 4096
H264_HIGH 52 65536 4096 4096
VC1_SIMPLE 1 65536 4096 4096
VC1_MAIN 2 65536 4096 4096
VC1_ADVANCED 4 65536 4096 4096
MPEG4_PART2_SP 3 65536 4096 4096
MPEG4_PART2_ASP 5 65536 4096 4096
DIVX4_QMOBILE --- not supported ---
DIVX4_MOBILE --- not supported ---
DIVX4_HOME_THEATER --- not supported ---
DIVX4_HD_1080P --- not supported ---
DIVX5_QMOBILE --- not supported ---
DIVX5_MOBILE --- not supported ---
DIVX5_HOME_THEATER --- not supported ---
DIVX5_HD_1080P --- not supported ---
H264_CONSTRAINED_BASELINE 0 65536 4096 4096
H264_EXTENDED --- not supported ---
H264_PROGRESSIVE_HIGH --- not supported ---
H264_CONSTRAINED_HIGH --- not supported ---
H264_HIGH_444_PREDICTIVE --- not supported ---
HEVC_MAIN 186 65536 4096 4096
HEVC_MAIN_10 186 65536 4096 4096
HEVC_MAIN_STILL --- not supported ---
HEVC_MAIN_12 --- not supported ---
HEVC_MAIN_444 --- not supported ---
Output surface:
name width height nat types
----------------------------------------------------
B8G8R8A8 16384 16384 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 A8I8 I8A8
R8G8B8A8 16384 16384 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 A8I8 I8A8
R10G10B10A2 16384 16384 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 A8I8 I8A8
B10G10R10A2 16384 16384 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 A8I8 I8A8
Bitmap surface:
name width height
------------------------------
B8G8R8A8 16384 16384
R8G8B8A8 16384 16384
R10G10B10A2 16384 16384
B10G10R10A2 16384 16384
A8 16384 16384
Video mixer:
feature name sup
------------------------------------
DEINTERLACE_TEMPORAL y
DEINTERLACE_TEMPORAL_SPATIAL -
INVERSE_TELECINE -
NOISE_REDUCTION y
SHARPNESS y
LUMA_KEY y
HIGH QUALITY SCALING - L1 y
HIGH QUALITY SCALING - L2 -
HIGH QUALITY SCALING - L3 -
HIGH QUALITY SCALING - L4 -
HIGH QUALITY SCALING - L5 -
HIGH QUALITY SCALING - L6 -
HIGH QUALITY SCALING - L7 -
HIGH QUALITY SCALING - L8 -
HIGH QUALITY SCALING - L9 -
parameter name sup min max
-----------------------------------------------------
VIDEO_SURFACE_WIDTH y 48 4096
VIDEO_SURFACE_HEIGHT y 48 4096
CHROMA_TYPE y
LAYERS y 0 4
attribute name sup min max
-----------------------------------------------------
BACKGROUND_COLOR y
CSC_MATRIX y
NOISE_REDUCTION_LEVEL y 0.00 1.00
SHARPNESS_LEVEL y -1.00 1.00
LUMA_KEY_MIN_LUMA y
LUMA_KEY_MAX_LUMA y
Kodi doesnt’s use vdpau to decode this 10-bit videos. "mpv --hwdec vdpau -vo vdpau video.mkv" does fall back to the CPU too. You can try this yourself on this sample encodings. But Kodi and mpv do use vdpau on standard 8-bit HEVC files. So… How can I convince the players to use vdpau? Is there maybe another player that can play this?
Last edited by frumble (2017-07-18 10:29:28)
Offline
10bit support in VDPAU is... bad. VDPAU has been practically dead for a while, it's only very recently that Nvidia hired someone again to take care of it, but we have yet to see what will become of that.
However, try mpv with --vo=opengl. Also, try mpv with --hwdec=vaapi --vo=opengl (--vo=vaapi doesn't seem to have 10bit support)
Offline
Thank you, had to install libva-vdpau-driver and libva-utils, now "mpv --hwdec=vaapi --vo=opengl jellyfish-400-mbps-4k-uhd-hevc-10bit.mkv" plays smoothly with 3% CPU load!
AMDGPU somehow supports OpenMAX too but I can’t find any information on how to use this backend in popular players. Still no HEVC-10-bit decoding with Kodi though, even when I prefer the VA-API backend over VDPAU in the settings.
Last edited by frumble (2017-07-18 10:26:49)
Offline
archlinux mesa is build with openMAX support, and uses libomxil-bellagio to provide the OpenMAX Intermediate Layer.
No idea which programs can use openmax IL, but there's a gstreamer omx plugin in AUR .
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
There's no need to use libva-vdpau-driver, radeon has native vaapi support, the libva-mesa-driver package.
OpenMAX is a big giant mess, that's why you won't find support in popular players.
Offline
Wow, cool, didn’t know that radeon/AMDGPU has build-in VA-API support! Works without libva-vdpau-driver, thanks!
Just tried using VA-API within VLC. I can choose between "VA-API via X11 Video Decoder" or "VA-API via DRM Video Decoder", the later does use only the CPU, the former uses still more CPU than VDPAU (4% vs. 1%) with FHD BD-Rips. On 4K 8-bit H.264 it‘s 8% vs 2% (pure CPU: 30%), VLC still cannot accelerate any H.265.
Last edited by frumble (2017-07-18 13:03:18)
Offline
VLC only supports copy-back VAAPI (decoded video is copied back into system memory). This of course uses more resources than zero-copy playback. mpv supports both modes, --hwdec=vaapi (zero-copy) vs --hwdec=vaapi-copy (copy-back).
So when it comes to VLC, you're better off using VDPAU. But that means no 10bit video, because VDPAU simply doesn't support it.
Offline
So when it comes to VLC, you're better off using VDPAU. But that means no 10bit video, because VDPAU simply doesn't support it.
Well, actually, it does. Look at my vdpauinfo output. It might not for Nvidia drivers but AMDGPU on Polaris exposes HEVC_MAIN_10, just no H.264 10-bit (High 10). Ultimately, all 10-bit video are in HEVC anyways so this doesn’t make a difference and VLC 2.x cannot play HEVC using VDPAU at all up to this day.
Last edited by frumble (2017-07-18 15:11:37)
Offline
Well, actually, it does. Look at my vdpauinfo output.
I looked around a bit to refresh my knowledge about this. What is supported in the driver is decoding 10bit video by dithering down to 8bit. Native 10bit without dithering is not possible, because libvdpau lacks support for 10bit surfaces. However, this scenario is not supported by ffmpeg and consequently mpv. No idea about other players, but it seems Kodi is in the same boat as ffmpeg/mpv.
Offline
Hm, interesting, thanks!
Digged around with vlc-git from AUR (VLC 3, alpha, beta, who knows? Is there any hope this release ever gets to see the light?): It supports HEVC HW decoding, but not for 10-bit. Besides the VLC 2.x options there is a new "VA-API Direct Video Decoder" which probably should avoid the copying. But sadly, it causes the player to decode on the CPU.
Would be pretty nice to have HEVC-10-bit decoding with Kodi, it seems to work for Intel users, what am I missing…?
Edit: Nope, it’s not implemented in Kodi 17 yet.
Last edited by frumble (2017-07-18 16:22:55)
Offline
Would be pretty nice to have HEVC-10-bit decoding with Kodi, it seems to work for Intel users, what am I missing…?
No idea if Kodi still supports VAAPI/GLX interop or if they've switched exclusively to VAAPI/EGL. The latter is *much* better, there's just one thing with it, it only works on Intel. There will be a libva-2.0 sometime soon™ with a new interface that will allow VAAPI/EGL also on Radeon. So you'll need to wait for libva-2.0 and then wait some more for applications to switch to it
VLC 3, alpha, beta, who knows? Is there any hope this release ever gets to see the light?
Ha! Really good question though. 2.2 is basically ancient by now, they really should release 3, like, yesterday
Besides the VLC 2.x options there is a new "VA-API Direct Video Decoder" which probably should avoid the copying.
Whoa, seriously? I generally don't like VLC (don't need a fancy GUI, mpv is just perfect), but I do need to check this out... Edit: It's very new, last month: http://git.videolan.org/?p=vlc.git;a=co … 3beda07c13. Nice . Bad news for you though, it uses VAAPI/EGL, so Intel-only for now: http://git.videolan.org/?p=vlc.git;a=co … 6ec68f2656
Last edited by Gusar (2017-07-18 18:46:35)
Offline
I need to wake this thread. The newest version of mpv (0.26.0, arrived as Arch package on June 20) can’t use VA-API anymore on my system:
VO does not support requested hardware decoder, or loading it failed.
The release notes talk about ffmpeg 3.2 being required for VA-API and VDPAU with this release, but my system even has ffmpeg 3.3.2.2. Playing with --hwdec=vdpau works (as long as there is no 10-bit). Am I missing something or is mpv broken?
Offline
Works fine here with the h264 and hevc samples Of Tears of Steal taken from here: https://x265.com/hevc-video-files/
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Thanks, do you use AMDGPU too? Could someone else with AMDGPU please try this…? Definitely broken on my system.
Offline
The latest mpv removes the vaapi-glx fallback if vaapi-egl fails to load. Now you have to explicitly tell it to use vaapi-glx with --opengl-hwdec-interop=vaapi-glx. You may also need --opengl-backend=x11 if the interop option alone won't do.
Last edited by Gusar (2017-08-01 12:55:44)
Offline
I'm not using amdgpu, this is with an Intel iGPU (HD520) and I'm using:
hwdec = vaapi
vo = vaapi
in mpd's configuration file.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Ha! Thanks again @Gusar!
profile=opengl-hq
hwdec=vaapi
opengl-hwdec-interop=vaapi-glx
in ~./config/mpv/mpv.conf lets VA-API work again!
Offline
Just to inform any searcher about this in this thread: Starting with Mesa 18.x, AMDGPU users need to write "allow_rgb10_configs=false" into their /etc/environment until native VA-API-EGL support with zero-copy lands in mainline libva.
Offline
vaapi-egl is already in libva, version 2.1. It's mesa that doesn't have support yet. It's in git already, so it will be in mesa-18.1, currently scheduled for release on May 11th. But even when mesa-18.1 is released, you'll still need git versions of ffmpeg and mpv, unless those also make a release soon. Hopefully that does happen, so this mess will finally be over.
Offline
So, it is done! Finally, we have all ingredients for EGL playback. No Mesa 18.1 needed, 18.0.1 has got all what was missing.
My new render-specific config which works for me with mpv-git from AUR (because unreleased mpv 0.29 is needed):
profile=opengl-hq
vo=vaapi
hwdec=vaapi
cscale=ewa_lanczos
scale=ewa_lanczossharp
tone-mapping=reinhard
hdr-compute-peak=yes
Using the MPV version from AUR is the only way to get hardware acceleration on AMDGPU in MPV for now.
Last edited by frumble (2018-05-15 12:12:19)
Offline
Yeah, I was quite surprised that vaExportSurfaceHandle() made it into mesa 18.0.1
Your settings don't make sense BTW. There's no HDR support in vo=vaapi, so the tone-mapping and hdr-compute-peak settings don't do anything. The opengl-hq profile doesn't do anything with vo=vaapi either, and doesn't even exist anymore. vo=opengl has been replaced with vo=gpu, the profile has been renamed accordingly, it's now gpu-hq.
Basically, stop using vo=vaapi. Use vo=gpu, which doesn't even need to be set because it's the default. And set the profile correctly.
Offline
OK, thanks, but no: vo=gpu does not accelerate on my system, it falls back to CPU decoding. Changing my profile to profile=gpu-hq does not help.
Before, with 0.27 the HDR options worked fine. Just tested this with 0.28.0-567-ge5b2af0a80 and it’s true, no HDR, that’s a bummer. So, I have lost HDR playpack on my system again.
How the heck should I know and keep up about all this things? Seriously, I’m a poweruser but am I supposed to follow the git development of this project closely and do regular diffs of their wiki manual?! I just want to play videos hardware accelerated with the best rendering!
Offline
OK, thanks, but no: vo=gpu does not accelerate on my system, it falls back to CPU decoding.
Then that's the thing you should focus on. vo=vaapi is a completely separate thing, has nothing to do with EGL interop. vo=gpu (formerly vo=opengl) is the output that uses EGL interop. And provides high quality rendering and 10bit video support and HDR support and basically everything else (vo=vaapi is quite crappy actually, and it's *really* crappy on non-Intel GPUs).
Post a mpv log when using hwdec=vaapi with vo=gpu. Or should we continue this on the mpv issue tracker? https://github.com/mpv-player/mpv/issues/5711
Last edited by Gusar (2018-05-15 18:34:30)
Offline
So, apperantly the right mpv config seems to be.
vo=gpu
gpu-context=x11egl
hwdec=vaapi-copy
hdr-compute-peak=no
Im not sure what other programs like kodi need in order to gpu decode hevc 10 bit? Is this a Mesa problem?
It seems that right now, mpv is the only player providing a "workaround" for this problem, or am I reading the situation wrong?
EDIT: Good news everyone! Kodi version 18 (so in our case at the moment, kodi-git) seems to have fixed HEVC 10BIT support for 200GE, just like mpv with the right config.
Last edited by eggz (2018-10-22 15:41:39)
Offline
Drop the -copy from hwdec, there's no need to waste resources with copying. Use hwdec=vaapi. The other settings are correct, except won't disabling peak detection give you a crappy experience with HDR video? Though HDR is a big giant mess still anyway, and I doubt any of you are actually watching HDR stuff on a regular basis
Offline