The libva-vdpau-driver is a VA-API implementation providing an interface to VDPAU, which allows the possibility to offload video encoding and decoding tasks to the graphics card, in this case, Nvidia.
If it’s not present, then this offloading will not take place with the VDPAU output selected; the result is the blackness described. At least, this is how I understand it; unless I’ve been blindsided by using the comparatively trouble-free AMD graphics.
To enable VLC’s GPU encoding/decoding through vaapi (the VA-API), then the libva-vdpau-driver must be available, if no other facility is in place. Is it the only option? I don’t know, with any great certainty.
Another VA-API implementation, for example, is the nvidia-vaapi-driver (using NVDEC as a backend) which is specifically designed for use by Firefox for accelerated decode of web content, and [disclaimer] may not operate correctly in other applications.
This, as far as I can determine, is the functional equivilent of libva-nvidia-driver mentioned by the OP in post #1, which you advised to replace the libva-vdpau-driver with.
You also alluded to a new implementation of vaapi for Nvidia:
Would you kindly provide specifics?
If use of this new vaapi is now leveraged via nvidia-utils, for example, or should just happen, perhaps libva-vdpau-driver creates a conflict; with the VLC experience being one of the symptoms.
In my system, an AV1 file will play as expected in VLC (with VDPAU output selected), either with or without the libva-vdpau-driver package being installed; however, this is hardly conclusive, as I use AMD and not Nvidia graphics.
According to the ArchWiki, the Nvidia proprietary driver (via nvidia-utils) should support VDPAU on the GeForce GTX 970 (GM204) ref.
I’d be interested to know whether uninstalling the libva-nvidia-driver (without reinstalling libva-vdpau-driver), and then selecting the VDPAU output in VLC, will allow you to play the AV1 video.
libvdpau-va-gl (VDPAU driver with OpenGL/VAAPI backend. H.264 only) is a translation layer, just like libva-vdpau-driver (A VDPAU-based backend for VA-API). How is this wrong?
Its a backend for vaapi … it does not control vdpau.
(it would impact the output of the “VAAPI” option)
If, especially until recently because of nvdec etc, you did not have VAAPI capabilites (only VDPAU) this would allow you to use a hardware-accelerated application that only provided a way to do so with VAAPI because you would be using VDPAU as the backend.
So … 3 years ago on nvidia you would only have vdpau … firefox only gives acceleration with vaapi … so … you use this package to get ‘vaapi’ by using VDPAU as a backend.
Newer nvidias can have vaapi through nvdec. Hence the new package and the conflict.
$ pacman -Si libva-nvidia-driver
Repository : extra
Name : libva-nvidia-driver
Version : 0.0.11-1
Description : VA-API implementation that uses NVDEC as a backend
Architecture : x86_64
URL : https://github.com/elFarto/nvidia-vaapi-driver/
Licenses : MIT
Groups : None
Provides : None
Depends On : gst-plugins-bad-libs libegl
Optional Deps : None
Conflicts With : libva-vdpau-driver
[...]
The very same that’s described as only being for use by Firefox; without any further clarification. So, it’s the libva-nvidia-driver / nvidia-vaapi-driver that the following description refers to:
NVIDIA proprietary driver supports via nvidia-utils:
Yes, that is what is listed on the Arch wiki page …
But I dont see how that its referring to those packages.
The archwiki is defining the ‘native’ videos APIs for hardware accel on nvidia (vdpau, nvdec) …
The packages you list are VAAPI using NVDEC as a backend … the second one is just old?
(There is no package by that name any longer in the repos or the aur)