Created attachment 321030 [details]
I have an amd64 system that has a GTX 460 NVidia GPU. I've been trying to get gpu accelerated decoding to work with vlc for the past week, and have finally found a solution.
If vlc is compiled with USE="vaapi" but ffmpeg *isn't* compiled with USE="vaapi", vlc will crash silently every time when playing any video while gpu accelerated decoding is enabled.
Compiling ffmpeg with USE="vaapi" solves this problem, but there's no indication from portage with either messages or dependencies that vlc's gpu decoding requires this.
A change in dependencies if vaapi is enabled with vlc or some sort of notification after vlc is emerged would be helpful.
+1 vlc crashes on nvidia when gpu encoding is enabled, also I haven't tested that, but when vaapi is enabled it doesn't mean that acceleration is working, because nvidia cards has their own vdpau which is not existing flag for vlc.
I checked and with ffmpeg compiled with vaapi support and the result is CPU usage is greater approximately 3 times. Console says that va-api is enabled. Also I tried with xv and opengl outputs with no lack
Maybe this has changed recently; but, USE="vaapi" appears to depend on libav.
Is this bug still valid? If so, I'll dig deeper...
USE="vaapi" for vlc depends on libva, not libav.
Using ffmpeg-1.2.4 and vlc-2.0.7, vaapi playback in vlc does not work if ffmpeg is compiled without the vaapi use flag. The video will still play, but hardware accelerated decoding won't be used.
With ffmpeg[vaapi] I get this output when playing a video with vlc and hardware decoding:
libva: VA-API version 0.32.0
Xlib: extension "XFree86-DRI" missing on display ":0".
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib64/va/drivers/nvidia_drv_video.so
libva: va_openDriver() returns 0
[0x7f1b28c0e3a8] avcodec decoder: Using VA API version 0.32 for hardware decoding.
This output is not present at all if you play a video in vlc with ffmpeg[-vaapi].
So, I'd say that virtual/ffmpeg[vaapi] should still be required for media-video/vlc[vaapi].
It could also be possible that hardware accelerated decoding is used in the case of virtual/ffmpeg[-vaapi] and that vlc just doesn't report it in the console output - I haven't done enough testing to determine whether or not this is the case.
Ah, wasn't awake yet; easy to swap those two letters.
Okay, I see now what you mean; however, I wonder why there is no warning / error output in the opposite case (ffmpeg[-vaapi]) and upon further thoughts, what if it is the case that something like libva[vdpau] needs a dependency on ffmpeg[vaapi]? And then another thing to wonder; why does libva not have a vaapi USE flag, but only a vdpau USE flag?
I agree this needs to be fixed; but well, I'd like to fix it in the right place, so additional communication and/or troubleshooting is needed.
As I don't know the details on how the libraries correspond to each others, I am CC-ing the libva maintainer to see if he has guidelines where this has to be applied. As aballier has (formerly) maintained vlc for the last 6 years, I am very sure his knowledge will come valuable.
I think you're confused on the issue :)
(In reply to Tom Wijsman (TomWij) from comment #6)
> Okay, I see now what you mean; however, I wonder why there is no warning /
> error output in the opposite case (ffmpeg[-vaapi])
likely because vlc uses the best decoder it finds and this is not vaapi in this case so doesnt print libva initialization sequence
> and upon further
> thoughts, what if it is the case that something like libva[vdpau] needs a
> dependency on ffmpeg[vaapi]?
hu ? this is not the case
libva useflags are for various underlying implementations/drivers for vaapi
> And then another thing to wonder; why does
> libva not have a vaapi USE flag, but only a vdpau USE flag?
libva provides vaapi
there are various drivers for libva, one is providing a vdpau->vaapi kind of wrapper (the only way to have vaapi on nvidia cards for ex.)
> I agree this needs to be fixed; but well, I'd like to fix it in the right
> place, so additional communication and/or troubleshooting is needed.
the original reporter is very likely right: vlc should have a usedep and things should fly; I don't know why I didn't add it when I added the flag; probably an oversight or because I was believing it was obvious that both need to be enabled.
+ 10 Nov 2013; Tom Wijsman <TomWij@gentoo.org> vlc-2.0.5.ebuild,
+ vlc-2.0.6.ebuild, vlc-2.0.7.ebuild, vlc-2.0.8.ebuild, vlc-2.0.8a.ebuild,
+ vlc-2.0.9.ebuild, vlc-2.0.9999.ebuild, vlc-2.1.0.ebuild, vlc-2.1.9999.ebuild,
+ Made USE="vaapi" depend on virtual/ffmpeg[vaapi] as that is needed for GPU
+ accelerated decoding; fixes bug #430960 reported by James and dolohow, with
+ the help of Alexis Ballier (aballier).
Thank you very much.