VA-API 1.0 Video Acceleration Is Approved For Fedora 28

[lu_tze]

To be precise and honest. For years I use libva (vaapi from 1.X branch) on AMD hardware and work well. Now I have installed in system libva2 and looks like it work also well. Just trying it with VLC3 and not see issue.

libva 1.x works fine under X11, but not Wayland. I had to use vdpau with mpv under Wayland. Make sure your VLC is really accelerated and doesn't fall back on non-accelerated code path.

[xpris]

libva 1.x works fine under X11, but not Wayland. I had to use vdpau with mpv under Wayland. Make sure your VLC is really accelerated and doesn't fall back on non-accelerated code path.

I use x11, not wayland. My Plasma 5 distro not want work well with wayland yet :/ And yes, VLC work. I see it in cpu usage. When HW is disabled CPU usage is huge and video stutters a lot but when enable HW, my cpu usage drop to minimum and not see stutters. Also no issue in console.

[lu_tze]

I use x11, not wayland. My Plasma 5 distro not want work well with wayland yet :/ And yes, VLC work. I see it in cpu usage. When HW is disabled CPU usage is huge and video stutters a lot but when enable HW, my cpu usage drop to minimum and not see stutters. Also no issue in console.

In X11, vlc has several options: accelerate via vdpau, or use glx-interop (obviously available only under X11). That's why I used mpv, in verbose mode it will tell you exactly what it uses. I actually haven't seen stuttering video when CPU decoding for years, except for low-end devices like Atom and Raspi.

[Gusar]

The thing about libva 2.0 is, that it break API with previous versions. Not only it breaks API, the new API was designed with Intel hardware in mind, i.e. makes assumptions that may be not valid for other hardware. You can get the story here: https://github.com/intel/libva/pull/125

You have that a bit wrong, it's the *old* API that makes assumptions about hardware and so only works on Intel. And this old API is _really_ old, it didn't appear in 2.0, but years earlier already. Version 2.1 now has a new API that works also on AMD.

To be precise and honest. For years I use libva (vaapi from 1.X branch) on AMD hardware and work well. Now I have installed in system libva2 and looks like it work also well. Just trying it with VLC3 and not see issue.

VLC 3 uses the old API for opengl interop, so it works only on Intel. And opengl interop is the only way VLC 3 does zero-copy VAAPI, otherwise you're getting copy-back VAAPI, which does reduce CPU usage, but not as much as zero-copy mode. Copy-back also stresses the GPU a lot. Until VLC switches to the new API, using it on AMD graphics is not a good choice, you're better off using VDPAU.

[Vistaus]

Libva2/vaapi 1 is available also in OpenMandriva LX3.03. This cool distro is build with Clang and not like many other distros with gcc.

libva2 is also available in Solus. This cool distro is built with a lot Clear Linux optimization stuff and lots of other good ideas, unlike many other distros.

[Stebs]

So will AMD switch from VDPAU to VAAPI, or is there no real preference and one can use both at will? (speaking of the open-source Radeon driver).

What about the new way/api for hardware decoding/encoding: v4l2 mem2mem that has become the new defacto standard for (new) SOCs?
Gstreamer, ffmpeg and Kodi do have support for it.
It sounds like that would/could be the perfect solution for the future?

[agd5f]

So will AMD switch from VDPAU to VAAPI, or is there no real preference and one can use both at will? (speaking of the open-source Radeon driver).

We support both (and also OpenMax). Use whichever one you like. We opted to support existing APIs rather than inventing yet another. There is no closed source multi-media driver for amdgpu. Our packaged drivers use mesa as well.

What about the new way/api for hardware decoding/encoding: v4l2 mem2mem that has become the new defacto standard for (new) SOCs?
Gstreamer, ffmpeg and Kodi do have support for it.
It sounds like that would/could be the perfect solution for the future?

I think the v4l2 mem2mem API is targeting fixed function video hardware handled in the kernel. There are a lot of things you may want to do with the the buffers that don't make sense in the kernel (e.g., anything involving shaders) because you'd end up dragging most of the userspace 3D stack into the kernel in one way or another.

[RussianNeuroMancer]

So... maybe Hi10P could be exposed on AMD via VA-API too? Since it's already works via OpenMax, for some reason.

[Gusar]

So will AMD switch from VDPAU to VAAPI, or is there no real preference and one can use both at will? (speaking of the open-source Radeon driver).

There's no real preference. However, VDPAU is dead, so it will not be receiving new features. If you want 10bit video, VP9 decoding or Wayland support, you won't find these in VDPAU.

What about the new way/api for hardware decoding/encoding: v4l2 mem2mem that has become the new defacto standard for (new) SOCs?
Gstreamer, ffmpeg and Kodi do have support for it.
It sounds like that would/could be the perfect solution for the future?

I have the feeling the desktop will stick with VAAPI. But SoCs now having a sort of standard in v4l2-m2m is waaaaay better than each vendor having their own proprietary thing.

So... maybe Hi10P could be exposed on AMD via VA-API too?

That should already be available.

[fritsch]

That should already be available.

Don't mix it with hevc-10 bit. Hi10p is the 10 bit h264, mainly used for Anime to make 100% sure it's unwatchable on 99% of the devices out there :-) - only true anime if combined with 8 channel flac audio, obviously.