After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 783169 - Don't try to load vaapi and fail
Don't try to load vaapi and fail
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer-vaapi
unspecified
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 748634
 
 
Reported: 2017-05-28 12:09 UTC by Christian Stadelmann
Modified: 2018-02-15 06:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Output of $ GST_DEBUG=LOG totem (816.20 KB, application/x-xz)
2017-05-30 08:45 UTC, Christian Stadelmann
  Details
Patch to gstreamer-vaapi to fix bug 783169 (2.28 KB, patch)
2017-07-04 03:56 UTC, Daniel van Vugt
needs-work Details | Review
pluigns: try to create test display in order (1.80 KB, patch)
2017-10-02 17:16 UTC, Víctor Manuel Jáquez Leal
rejected Details | Review
libs: utils: log warn if display fail (1.86 KB, patch)
2017-10-03 11:00 UTC, Víctor Manuel Jáquez Leal
committed Details | Review

Description Christian Stadelmann 2017-05-28 12:09:41 UTC
Steps to reproduce:
1. make sure that GStreamer vaapi (Fedora package: gstreamer1-vaapi) is installed
2. run totem or anything else which triggers running the video thumbnailer
3. watch output

What happens:
I get these lines printed to command line:

VA error: wayland: failed to identify /dev/dri/card0: Permission denied (errno 13)
libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)
libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)

Additional info:
As far as I understand this issue, totem-video-thumbnailer drops privileges before initializing vaapi. As a result, vaapi cannot stat("/dev/dri/card0") any more.

Software versions installed:
gstreamer1-vaapi-1.12.0-1.fc26.x86_64
libva-1.8.2-1.fc26.x86_64
libva-intel-driver-1.8.2-1.fc26.x86_64
totem-3.24.0-1.fc26.x86_64
glib2-2.52.2-2.fc26.x86_64
gstreamer1-plugins-base-1.12.0-1.fc26.x86_64

Suggested solution:
Either blacklist the vaapi stuff completely or make sure it gets initialized before dropping privileges.
Comment 1 Bastien Nocera 2017-05-28 13:15:38 UTC
1) It should already be blacklisted by:
https://git.gnome.org//browse/totem/tree/src/totem-video-thumbnailer.c#n389
unless it changed names again. You'll want to check whether it's called something else by enabling GST_DEBUG.

2) We don't drop privileges, SELinux does for us, without ever asking application developers. They don't know better, they just think they do.
Comment 2 Christian Stadelmann 2017-05-30 08:45:24 UTC
Created attachment 352855 [details]
Output of $ GST_DEBUG=LOG totem

(In reply to Bastien Nocera from comment #1)
> 1) It should already be blacklisted by:
> https://git.gnome.org//browse/totem/tree/src/totem-video-thumbnailer.c#n389
> unless it changed names again. You'll want to check whether it's called
> something else by enabling GST_DEBUG.

According to the inspector, I have these:
$ gst-inspect-1.0
vaapi:  vaapimpeg2dec: VA-API MPEG2 decoder
vaapi:  vaapih264dec: VA-API H264 decoder
vaapi:  vaapipostproc: VA-API video postprocessing
vaapi:  vaapidecodebin: VA-API Decode Bin
vaapi:  vaapisink: VA-API sink
[…]

So the vaapisink is missing in the source file, but it shouldn't be loaded anyway, because totem uses a fake sink.
The vaapipostrproc is missing in the source file too, I don't know whether that matters.

As soon as I redirect totem's stdout/stderr, the issue is gone and totem-video-thumbnailer does not try to initialize vaapi any more. This is weird to me.

Manually copy-pasting the terminal output to GEdit worked fine though, I'll attach that as a file. The relevant stuff happens around line 56070 in PID 32458.

> 2) We don't drop privileges, SELinux does for us, without ever asking
> application developers. They don't know better, they just think they do.

If I should report this issue downstream, please tell me.
Comment 3 Daniel van Vugt 2017-06-30 10:07:40 UTC
A possible (partial?) fix: https://bugs.launchpad.net/totem/+bug/1698287/comments/5

I'll investigate more on Monday...
Comment 4 Daniel van Vugt 2017-07-04 03:56:45 UTC
Created attachment 354863 [details] [review]
Patch to gstreamer-vaapi to fix bug 783169

gstreamer-vaapi prefers wayland over x11, and the opengl plugin blindly prefers x11 over wayland. So they end up with incompatible defaults. The opengl plugin's choice of x11 (when Xwayland is present) results in libva getting reinitialized for X11. And libva only supporting DRI2 doesn't work, because Xwayland only supports DRI3.

Admittedly this could also be fixed by changing the opengl plugin to prefer wayland over x11, but that would be less robust than this patch which forcefully makes the opengl plugin agree with what the vaapi plugin is using.
Comment 5 Víctor Manuel Jáquez Leal 2017-07-27 09:41:34 UTC
Review of attachment 354863 [details] [review]:

Thanks for the patch, but the fix is not acceptable as is, because it can lead to crashes. Though, your explanation of the issue seems correct, we should look for another fix :)

::: gstreamer-vaapi-1.12.1/gst/vaapi/gstvaapipluginutil.c
@@ +126,3 @@
+      }
+    } else {
+      g_setenv ("GST_GL_WINDOW", required, 1);

You shouldn't call setenv in mutithreaded code:

http://rachelbythebay.com/w/2017/01/30/env/
Comment 6 Daniel van Vugt 2017-07-27 09:46:52 UTC
Yeah I suspected as much. It was at least a proof of concept.

From memory a simpler fix is possible: Just modify the opengl plugin to prioritize wayland over x11. So under Gnome Shell Wayland it finds native Wayland before it finds X11 (Xwayland).
Comment 7 Christian Stadelmann 2017-07-27 10:14:59 UTC
(In reply to Daniel van Vugt from comment #6)
> Yeah I suspected as much. It was at least a proof of concept.
> 
> From memory a simpler fix is possible: Just modify the opengl plugin to
> prioritize wayland over x11. So under Gnome Shell Wayland it finds native
> Wayland before it finds X11 (Xwayland).

This seems error-prone to me. What if an application is started with GDK_BACKEND=x11, forcing Gdk/Gtk to use Xorg? For example, firefox does override its gdk backend in this (or a similar) way. Either way, whenever gstreamer makes a choice, the application embedding gstreamer might have made a different choice, so it will break.

So if there is any other code which already chose wayland or x11, gstreamer must follow this choice.

For example, if GStreamer is being used in a Gtk+ application, and GST_GL_WINDOW is not set, the application might have chosen a backend from the GDK_BACKEND environment variable or gdk_set_allowed_backends(). Similarly, a Qt5 application might have chosen a different backend by using QT_QPA_PLATFORM environment variable or through API (if that is possible).
Comment 8 Víctor Manuel Jáquez Leal 2017-08-03 08:25:36 UTC
This is the first time I heard of EMGD. Are you using this VA driver?

Is it's strange: trying with emgd_drv_video.so fails, but gstreamer-vaapi finally works at registering when it uses i965_drv_video.so
Comment 9 Christian Stadelmann 2017-08-04 21:48:00 UTC
(In reply to Víctor Manuel Jáquez Leal from comment #8)
> This is the first time I heard of EMGD. Are you using this VA driver?

I don't understand. What is EMGD? As written above, I'm using the libva-intel-driver.
Comment 10 Víctor Manuel Jáquez Leal 2017-10-02 17:08:08 UTC
(In reply to Christian Stadelmann from comment #9)
> (In reply to Víctor Manuel Jáquez Leal from comment #8)
> > This is the first time I heard of EMGD. Are you using this VA driver?
> 
> I don't understand. What is EMGD? As written above, I'm using the
> libva-intel-driver.

From attachment 352855 [details]

0:00:00.013642317 32458 0x55fd9e453000 INFO                   vaapi gstvaapiutils.c:58:gst_vaapi_log: VA-API version 0.40.0
0:00:00.013655613 32458 0x55fd9e453000 INFO                   vaapi gstvaapiutils.c:58:gst_vaapi_log: va_getDriverName() returns 0
0:00:00.013668098 32458 0x55fd9e453000 INFO                   vaapi gstvaapiutils.c:58:gst_vaapi_log: Trying to open /usr/lib64/dri/emgd_drv_video.so
0:00:00.013693853 32458 0x55fd9e453000 INFO                   vaapi gstvaapiutils.c:58:gst_vaapi_log: va_openDriver() returns -1
0:00:00.013704634 32458 0x55fd9e453000 DEBUG                  vaapi gstvaapiutils.c:86:vaapi_check_status: vaInitialize(): unknown libva error

Isn't it from Intel's MediaSDK?
Comment 11 Víctor Manuel Jáquez Leal 2017-10-02 17:16:34 UTC
Created attachment 360795 [details] [review]
pluigns: try to create test display in order

When creating the test display for querying capabilites, it try in
certain order: DRM, Wayland and finally X11. GLX nor EGL are tried
since they are either composited with X11 or Wayland.

The reason for this is to reduce the posibility of failure that could
blacklist the plugin.

https://bugzilla.gnome.org/show_bug.cgi?id=782212
Comment 12 Christian Stadelmann 2017-10-03 10:24:36 UTC
To make it perfect, one would probably need additional API to say "get capabilities for backend X with Y" where X is one of DRM, Wayland, X11 and Y is one of GLX, EGL.
I'm not sure whether you want to have this API though.
Comment 13 Víctor Manuel Jáquez Leal 2017-10-03 10:49:05 UTC
Comment on attachment 360795 [details] [review]
pluigns: try to create test display in order

Sorry, this patch doesn't belong strictly to this bug.
Comment 14 Víctor Manuel Jáquez Leal 2017-10-03 10:51:31 UTC
(In reply to Christian Stadelmann from comment #12)
> To make it perfect, one would probably need additional API to say "get
> capabilities for backend X with Y" where X is one of DRM, Wayland, X11 and Y
> is one of GLX, EGL.
> I'm not sure whether you want to have this API though.

the gstreamer-vaapi api has different GstVaapiDisplay subclass for each one of rendering mechanism (drm, x11, x11-glx, wayland, x11-egl and wayland-egl). Not ideal, but they there are.
Comment 15 Víctor Manuel Jáquez Leal 2017-10-03 11:00:18 UTC
Created attachment 360824 [details] [review]
libs: utils: log warn if display fail

gstreamer-vaapi initializes the display by trial-and-error, thus
logging an error message if the display initialisation fails the user
may be weary of the error message in the screen, if using VA-API 1.0

This commit set the VA error log handler to GStreamer warning level
while calling vaInitialize() and set it to error after that.

https://bugzilla.gnome.org/show_bug.cgi?id=83169
Comment 16 Víctor Manuel Jáquez Leal 2017-10-03 11:47:56 UTC
Comment on attachment 360824 [details] [review]
libs: utils: log warn if display fail

Attachment 360824 [details] pushed as c7d712a - libs: utils: log warn if display fail
Comment 17 Ángel Guzmán Maeso (shakaran) 2017-10-27 16:24:31 UTC
As user of Pitivi it seems that I also hit this bug from gstreamer-vaapi

https://phabricator.freedesktop.org/T7842
Comment 18 Víctor Manuel Jáquez Leal 2018-02-15 06:55:13 UTC
Ok. Just realized that this bug report has turned into a potpurri of different failures of different backends: EMGD (a libva backend for embedded, afaik), mesa backends, etc.

The patch to attachment 354863 [details] [review] is not required anymore since commit https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=472b8a3736d54c07196a21384f442f57a6a62737

I'm going to close this bug as obsolete and open a new bug with the specific problem that are you facing.
Comment 19 Daniel van Vugt 2018-02-15 06:56:59 UTC
Agreed.