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.
> I don't know if we could slot ffmpeg I've been looking into how some other distributions are solving this problem. Fedora (and presumably its derivatives too) have dropped support for vlc with vaapi[1] (which is not ideal). But Arch provides ffmpeg-4 as a separate package[2], so slotting is I think at least a theoretical possibility. The question then becomes how much work this is going to be, and how sustainable that solution is. Apart from vlc there are several other packages that still have no version compatible with ffmpeg 5+: - dev-games/openscenegraph - app-misc/qcma - sci-libs/opencascade - net-p2p/retroshare - media-sound/moc These ebuilds would need some adjustments so they can still find a slotted/separated ffmpeg-4. And additionally, several packages have older versions which still require ffmpeg<5, those will have to be cleaned up. What do you think? Would this be a feasible path forward? This issue is becoming more problematic as more packages are starting to require ffmpeg>=6 (e.g. calibre in Bug 941926). [1] https://discussion.fedoraproject.org/t/vlc-not-exposing-va-api-as-a-hardware-acceleration-option/101133 [2] https://archlinux.org/packages/extra/x86_64/ffmpeg4.4/
I'm glad to see this is getting some eyes on it, but I haven't been a dev (without git privs) officially since 2008-2009... Whatever decision is made by media-video, I'll go with it, but I really think slotting would be the right way forward despite the work that would be needed to make it happen. Thanks
Slotting is easily said, harder to do. It would only be possible for applications which only use ffmpeg directly and obviously no help for libraries. The fact that vlc also has libvlc complicates things a bit too.
Created attachment 906608 [details] kludgetastic ebuilds for local overlay I've actually created my own SLOTted ffmpeg ebuilds and have been using them for the past year+. They're admittedly massive kludges and completely unfit for general consumption, but they work *totally fine* for me - so they ought to at least serve as proof of concept. Hopefully I've managed to include everything they depend on within ${FILESDIR}, so that one could just unpack this tarball to a local overlay. (There are also kludges in there to hook NPP (e.g. the scale_npp filter) up to USE=npp, but those can safely be ignored in this context. You'll also notice an in-house patchset that is otherwise irrelevant and therefore commented out in these copies. I'm trying to avoid hacking up known-working prototype ebuilds /too/ much before posting them here, but I'm also trying to ensure that the ebuilds I post have some chance of being usable by others) tl;dr: These ebuilds are intended as prototypes / proof-of-concept only. MASSIVE HORRIFIC DISGUSTING KLUDGES INSIDE! YOU HAVE BEEN WARNED! Anyone who would like to try to turn these into something more fit for general consumption is more than welcome to take my abominations^Wideas & run with them :-)
Created attachment 906611 [details] /etc/portage/bashrc.d/60-vlc.sh ... and here's the *disgusting* hack I use to get vlc to actually build against my kludge ebuilds. I can personally confirm that it works with at least media-video/vlc-3.0.20-r5 and media-video/vlc-3.0.21. Same caveats apply, of course - I am entirely aware of how "wrong" this implementation is, and am only really posting it here as a proof-of-concept. (For starters, this hack does not even try to properly adjust $DEPEND/$RDEPEND...)
At one point I tried to make a slotted ffmpeg:4 as well, but I have vague memories that it somehow didn't work due to vlc's build system refusing to pick it up even when I overrode PKG_CONFIG.
