Fails in configure phase: checking for libavcodec/vaapi.h... no configure: error: libva is present but libavcodec/vaapi.h is missing Works fine if I add -vaapi to USE flags. Reproducible: Always > emerge -pqv media-video/vlc [ebuild R ] media-video/vlc-3.0.17.4 USE="X a52 alsa -aom -archive -aribsub -bidi -bluray -cddb -chromaprint -chromecast -dav1d dbus -dc1394 -debug (-directx) dts dvbpsi dvd encode -faad -fdk ffmpeg flac -fluidsynth fontconfig gcrypt -gme gnome-keyring -gstreamer gui -ieee1394 -jack jpeg -kate -libass -libcaca libnotify libsamplerate -libtar -libtiger -linsys -lirc -live lua -macosx-notifications mad -matroska -modplug mp3 mpeg -mtp -musepack ncurses -nfs ogg -omxil -optimisememory -opus png -projectm pulseaudio -rdp -run-as-root samba -sdl-image -sftp -shout -sid -skins -soxr -speex -srt ssl svg -taglib -test -theora -tremor truetype -twolame udev upnp -v4l vaapi* vdpau -vnc -vpx wayland x264 -x265 xml -zeroconf -zvbi" CPU_FLAGS_X86="mmx sse" LUA_SINGLE_TARGET="lua5-1"
Created attachment 799043 [details] emerge --info
Created attachment 799045 [details] build.log
I don't think this is a huge surprise, tbh. https://code.videolan.org/videolan/vlc/-/merge_requests/1245 https://code.videolan.org/videolan/vlc/-/merge_requests/1238 Upstream are already not thrilled about fixing various dep issues like this, but given they need to overhaul a fair bit to make master build w/ ffmpeg 5.0(+), I suspect this won't be backported. What would be interesting is if it builds with ffmpeg-5.0 or not? I'm guessing no, but that would be more of a problem for us.
I saw another bug with ffmpeg-5.0, I'll try it too and let you know.
Exact same problem with ffmpeg-5.0.1, as you suspected.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3d1263e7486432859276f19e2341c4fcfd5b98f5 commit 3d1263e7486432859276f19e2341c4fcfd5b98f5 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-02-15 06:22:36 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-02-15 06:22:36 +0000 media-video/vlc: depend on <ffmpeg-5 for USE='ffmpeg vaapi' for 3.x Bug: https://bugs.gentoo.org/864721 Signed-off-by: Sam James <sam@gentoo.org> media-video/vlc/vlc-3.0.18.ebuild | 8 ++++++-- media-video/vlc/vlc-3.0.9999.ebuild | 10 +++++++--- 2 files changed, 13 insertions(+), 5 deletions(-)
*** Bug 914627 has been marked as a duplicate of this bug. ***
*** Bug 927365 has been marked as a duplicate of this bug. ***
There's a new development in this. For the longest time I was not able to update to FFMPEG 6 until today, when I disabled the vaapi useflag for VLC and recompiled. After that I was able to update to FFMPEG 6. If you still haven't upgraded to FFMPEG 6, check if your vaapi useflag is enabled, and disable it.
But without vaapi I loose HW acceleration, right? So that is only a weak work-around.
Yes, you would lose HW accel. I've looked through VLC's issue list for a while, and someone correct me if I'm wrong, but they seem to think that ffmpeg removed vaapi support. Although it looks like what actually happened was ffmpeg changed the calls for vaapi, and VLC don't seem interested in updating their code. VLC has a snap, but the snap's vaapi also seems broken since tigerlake (issue 28212). I don't know if we could slot ffmpeg, that could be a lot of work since the majority of AV apps use ffmpeg in some way or another. If you use KDE or Gnome, you might want to try the players they ship, although I'm not sure they are as configurable as VLC is.
> If you use KDE or Gnome, you might want to try the players they ship That is where I initially started. I use KDE and was happy with KDragonPlayer. KDragonPlayer offloads all playback to Phonon. Until recently, I have been using GStreamer as the Phonon backend, because that had been the recommended backend some years ago. However, GStreamer as a Phonon is deprecated as it has not been ported to Qt6 and VLC is the only Phonon-backend left. I learned that the hard way, as I lost playback functionality in KDE, because I had disabled VLC trough use flags and GStreamer was removed (see https://bugs.gentoo.org/935033#c8). So, any "native" KDE player which is built around Phonon uses VLC one way or another under the hood. I would actually like to get rid of VLC again, but that does not seem to be easy for KDE users. (At least if you want to have some kind of playback functionality.) So removing HW acceleration is a little bit harsh.
(In reply to Chris Henhawke from comment #11) I have to second what you wrote here, as I was about to write something similar. VLC's 4.0 branch seems to be the only one getting compatibility patches for dependencies now. Although it's been in a pre-alpha state for years. I get the impression that all of the proxying/repackaging that VLC did for libavcodec (and family) into their home grown libvlc has finally come back to bite them, because every time upstream changes now, they can't keep up anymore and their public API just makes the developers' lives harder. Regarding recommendations for alternatives, there's one player in portage by the name of: __ media-video/mpv __. I strongly believe that this particular player's development philosophy for making the most architecturally thin, minimal UI, and "hardware-literate" player is the way to go. And that's only because they've managed to pull off some of the most impressive hardware accelerated performance for video on Windows and Linux. It's not as feature-rich as VLC with all their optional filters, playlists, and 3rd party APIs; and it's a very simplistic UI in comparison. But the codec and library support is absolutely stellar everywhere I've used it to play the most demanding videos that VLC just can't keep up with. It does appear that there is a shake up going on in the video player space, where everyone is being forced to reevaluate and realign themselves with the direction of the libraries, to get access to get the most access to their hardware, especially because of all the innovation in HDR and frame-time accuracy.
(In reply to Matthias Nagel from comment #10) > But without vaapi I loose HW acceleration, right? So that is only a weak > work-around. When digging into this a while ago it seemed rather that VAAPI is an ancient method for getting HW acceleration which has been supplanted by newer things like VDPAU, AMF (for AMD), NVENC (for nVidia), QSV (for Intel), and the 'soc' use flag for a bunch of random stuff on small boards. Since removing 'vaapi' use flag ('vdpau' and 'amf' are still set) VLC happily plays complicated codecs like X265 with no apparent affect on CPU usage, while amdgputop and radeontop both show some effect, though it's relatively small since video decode is highly accelerated.
> QSV (for Intel) AFAIK VLC does not support QSV for video decode, and even if it did then QSV is sort off built on top of vaapi and does not really replace it. So at least for Intel platforms USE=vaapi is required for HW acceleration.
This is inaccurate. VA-API is an open source, generic and unified API for hardware accelerated decoding/encoding that's supported by (ideally) all vendors, while VDPAU/NVDEC/NVENC, AMF/UVD/VCE and QSV are the vendor-specific, proprietary solutions. Neither is VA-API "ancient", nor is it "supplanted", just as OpenCL is not "supplanted" by CUDA.
