GNOME Bugzilla – Bug 777115
vaapi: overload va logging mechanism
Last modified: 2017-01-12 09:57:06 UTC
In the context of using Beetbox/beets (a music library management system) to process music files using GStreamer as a back end, when beets encounters a .mp4 file, it causes the following messages to be issues to the command window, rendering any other work being done in that window impossible: error: XDG_RUNTIME_DIR not set in the environment. libva info: VA-API version 0.39.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_0_39 libva info: va_openDriver() returns 0 I've worked with the beets developers on this, and have determined through trial and error that this only occurs, or rather I can only recreate it, when beets is using GStreamer and encounters a .mp4 file. I surmise it's trying to use hardware acceleration to process the file and that is somehow causing these messages to be generated. Is there a fix or workaround for this? Or is there a way to silence the messages? The machine running the software is an Ubuntu 16.04.1 LTS, 4.4.0-57-generic kernel, 64 bit, server variant (so no X windows, no desktop and no desktop apps loaded), fully updated from Ubuntu repositories as of 01/02/17
Hi, (In reply to David Herring from comment #0) > In the context of using Beetbox/beets (a music library management system) to > process music files using GStreamer as a back end, when beets encounters a > .mp4 file, it causes the following messages to be issues to the command > window, rendering any other work being done in that window impossible: > > error: XDG_RUNTIME_DIR not set in the environment. That message is unrelated to gstreamer-vaapi and libva > libva info: VA-API version 0.39.0 > libva info: va_getDriverName() returns 0 > libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so > libva info: Found init function __vaDriverInit_0_39 > libva info: va_openDriver() returns 0 These messages are printed by libva (the library behind gstreamer-vaapi). The current development version of libva (0.39.4) has API to overload the logging mechanism, and in gstreamer-vaapi we could use to redirect the messages to gstreamer log system. Nonetheless, if the user uses versions before 0.39.4 (which is not released yet), there are no means to avoid those messages but modifying the libva sources. > I've worked with the beets developers on this, and have determined through > trial and error that this only occurs, or rather I can only recreate it, > when beets is using GStreamer and encounters a .mp4 file. I surmise it's > trying to use hardware acceleration to process the file and that is somehow > causing these messages to be generated. > > Is there a fix or workaround for this? Or is there a way to silence the > messages? Sketching a summary of the possible options 1\ use libva 0.39.4 and patch gstreamer-vaapi to overload the va logging options (we're going to that) 2\ patch yourself libva sources by removing those messages printf 3\ remove gstreamer-vaapi from you installation and don't use this hardware acceleration. > The machine running the software is an Ubuntu 16.04.1 LTS, 4.4.0-57-generic > kernel, 64 bit, server variant (so no X windows, no desktop and no desktop > apps loaded), fully updated from Ubuntu repositories as of 01/02/17
Option 4: the application (Beetbox/beets) could look up the vaapi element factories from the registry and set their rank to GST_RANK_NONE with gst_plugin_feature_set_rank() so they won't get autoplugged.
Created attachment 343311 [details] [review] libs: display: redirect logging at initialize Redirect libva's logs to GStreamer logging mechanism. This is particularly useful when VA is initialized, because it always logs out the drivers details. In order to achieve this a new helper function was added as a wrapper for the vaInitialize() function.
♥
The comments provided by the developers suggest reasonable workarounds and that the matter is addressed in an upcoming release. This is acceptable (and appreciated!) and thus for my purposes I consider the matter resolved. Thank you!
Comment on attachment 343311 [details] [review] libs: display: redirect logging at initialize Attachment 343311 [details] pushed as 1e0b3c2 - libs: display: redirect logging at initialize