Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 430960 - media-video/vlc[vaapi] should depend on virtual/ffmpeg[vaapi]
Summary: media-video/vlc[vaapi] should depend on virtual/ffmpeg[vaapi]
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Tom Wijsman (TomWij) (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-11 17:07 UTC by James
Modified: 2013-11-10 15:42 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info (emerge-info.txt,5.44 KB, text/plain)
2012-08-11 17:07 UTC, James
Details

Note You need to log in before you can comment on or make changes to this bug.
Description James 2012-08-11 17:07:37 UTC
Created attachment 321030 [details]
emerge --info

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.
Comment 1 dolohow 2013-01-25 23:31:17 UTC
+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.
Comment 2 dolohow 2013-01-26 17:56:56 UTC
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
Comment 3 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-10-26 08:31:28 UTC
Maybe this has changed recently; but, USE="vaapi" appears to depend on libav.

Is this bug still valid? If so, I'll dig deeper...
Comment 4 James 2013-10-26 16:29:47 UTC
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].
Comment 5 James 2013-10-26 16:35:08 UTC
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.
Comment 6 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-10-26 18:00:48 UTC
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.
Comment 7 Alexis Ballier gentoo-dev 2013-10-27 19:39:17 UTC
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.
Comment 8 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-11-10 15:42:09 UTC
+  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,
+  vlc-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.