Vainfo Download
Iris Lopez
Video Acceleration API (VA API) is a library ("libVA") and API specificationwhich enables and provides access to graphics hardware (GPU) acceleration forvideo processing on Linux and UNIX based operating systems. Acceleratedprocessing includes video decoding, video encoding, subpicture blending andrendering. The specification was originally designed by Intel for its GMA(Graphics Media Accelerator) series of GPU hardware, the API is however notlimited to GPUs or Intel specific hardware, as other hardware and manufacturerscan also freely use this API for hardware accelerated video decoding.This package provides the vainfo program. Tags: Implemented in: C, Role: Program
I also want to add a few details:
- I have 2 PCs running ArchLinux at the latest with upstream kernel. Both with NVIDIA graphics but different family. The old PC has GeForce 9400 and nouveau with the latest mesa-19.1-x work just great. GeForce 9400 no longer gets NVIDIA propriety binary driver support and the last version nvidia-341xxx is less polished than the open-source nouveau. It is missing RenderNode support in recent DRI2 implementation. On the other hand, nouveau supports DRI2/RenderNode for GeForce 9400, all the rightful video acceleraion (VAAPI/VDPAU) for the supported video formats by the hardware and OpenGL/GLES performance figures from glmark2 are very close to nvidia-341xx. The new PC has GeForce GT730 (GK208B) and this was the problem with nouveau. VAAPI/VDPAU simply segfault'ed and refused to function. Although GK208B also no longer gets NVIDIA propriety binary driver support, it has more recent nvidia-390xxx which provides proper DRI2/RenderNode support. All video acceleration (VAAPI/VDPAU) works with nvidia-390xxx. OpenGL/GLES performance figures are much better than nouveau (even after reclocking). So, it is very likely that people would simply use nvidia-390xxx and stop the hassle of reporting and get the issue fixed upstream.
- Even though VAAPI/VDPAU segfault'ed with nouveau, OpenGL/GLES are fine with glxgears and glmark2.
- I can confirm that the interim solution of downgrading the 3 mesa packages back to 19.0-x works.
- dmesg has the code byte stream upon segfault. Both vainfo and vdpauinfo showed the same code byte stream
This is not a solution. You simply removed the vaapi/vdpau drivers and the media players will be running without video acceleration. Please use vainfo and vdpauinfo to verify if video acceleration is actually available.
No I didn't file the bug yet. I think libva-mesa-driver has serious issues with vaapi. Even though vainfo reported things looked OK, Chromium-vaapi and totem (using gstreamer-vaapi) did not work as expected. On Geforce 9400, h.264 video played as junk and crashed both Chromium and totem. On Geforce GT730 (GK208B), totem refused to play the same h.264 video while Chromium fell back to FFmpegVideoDecoder from MojoVideoDecoder. I am investigating this on other GPUs at my disposal, Radeon HD 6290, Ryzen Mobile Vega 8 and Intel Haswell HD 4400.
Interestingly, the issue doesn't seem to happen when X isn't running. So running vainfo in a tty or DISPLAY= vainfo gives you a similar result as you would get on the second image, for both versions. But of course, you'd get warnings from vainfo complaining that it can't access the X server.
I've solved the above error by adding the testing repo to /etc/apt/sources.list but only the VAAPI inside jellyfin was working, I was using the linuxserver container and I've noticed an opened issue inside their github stating that QSV stopped working after an ffmpeg update. A user was proposing a fix by adding inside the container a script with the following content the script is working and I've noticed that is not necessary to add the user to video and render groups, and neither to install intel-media-va-driver and vainfo in the host machine, at least for linuxserver/jellyfin docker container, so finally QSV is working with far better fps compared to VAAPI
Check the transcoding log if ffmpeg it's using VAAPI, it can happen that VA driver is not being loaded. In that case I suggest you to install vainfo inside the container. I discovered it recently, it was not working and figured that you need the driver inside the container. Solved it installing another ffmpeg version which installs all required dependencies.
I understand that i915_drv_video.so is not provided by any Debian Buster package. I tried using i965_drv_video.so and iHD_drv_video.so, but vainfo reports "init failed", which is not surprising considering that I have i915.
Moreover I have just confirmed this bug while running vainfo on Ubuntu MATE 22.04 LTS on VAIO F13Z1 with Nvidia GT425M using 390.144 video driver. Can't play a video with VLC player (see attached log). It is unbelievable.
Fixed by using package from 18.04 LTS as follows: