GNOME Bugzilla – Bug 783169
Don't try to load vaapi and fail
Last modified: 2018-02-15 06:56:59 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.
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.
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.
A possible (partial?) fix: https://bugs.launchpad.net/totem/+bug/1698287/comments/5 I'll investigate more on Monday...
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.
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/
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).
(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).
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
(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.
(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?
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
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 on attachment 360795 [details] [review] pluigns: try to create test display in order Sorry, this patch doesn't belong strictly to this bug.
(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.
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 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
As user of Pitivi it seems that I also hit this bug from gstreamer-vaapi https://phabricator.freedesktop.org/T7842
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.
Agreed.