GNOME Bugzilla – Bug 761405
decodebin/vaapi: ranking vaapi breaks plugging
Last modified: 2018-11-03 15:07:36 UTC
Installing gstreamer-vaapi is enough to break auto plugging behaviour. Because vaapi modules require specific hardware (e.g. QuickSync) and a specific environment (DISPLAY set with running X Server); installing these modules break systems that depends on autoplugging. Consider a simple application that does transcoding in the background, while using vaapi to decode video if an X server is running. Due to the higher ranking (PRIMARY+2), the vaapi modules are always picked over the generic sofware based solution. See the att'd simple example. barco@EMS-005008087c8a:~$ gst-launch-1.0 uridecodebin uri=file:///home/barco/some-file.mkv ! fakesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Stream with high frequencies VQ coding libva info: VA-API version 0.38.0 libva info: va_getDriverName() returns -1 libva error: va_getDriverName() failed with unknown libva error,driver_name=(null) libva info: VA-API version 0.38.0 libva info: va_getDriverName() returns -1 libva error: va_getDriverName() failed with unknown libva error,driver_name=(null) libva info: VA-API version 0.38.0 libva info: va_getDriverName() returns 1 libva error: va_getDriverName() failed with operation failed,driver_name=i965 ERROR: from element /GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstVaapiDecodeBin:vaapidecodebin0/GstVaapiDecode:vaapidecode: Could not initialize supporting library. Additional debug info: gstvideodecoder.c(2571): gst_video_decoder_change_state (): /GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstVaapiDecodeBin:vaapidecodebin0/GstVaapiDecode:vaapidecode: Failed to open decoder ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... libva info: VA-API version 0.38.0 libva info: va_getDriverName() returns -1 libva error: va_getDriverName() failed with unknown libva error,driver_name=(null) libva info: VA-API version 0.38.0 libva info: va_getDriverName() returns -1 libva error: va_getDriverName() failed with unknown libva error,driver_name=(null) libva info: VA-API version 0.38.0 libva info: va_getDriverName() returns 1 libva error: va_getDriverName() failed with operation failed,driver_name=i965 Freeing pipeline ... The current workaround is lowering the ranking of the hardware based elements: We might need to resort to (in the app): GstPluginFeature *feature; GstRegistry *registry = gst_registry_get(); feature = gst_registry_lookup_feature (registry, "vaapidecodebin"); if (feature != NULL) { gst_plugin_feature_set_rank (feature, GST_RANK_NONE); gst_object_unref (feature); } and so forth :-( Though this is obviously not a viable solution when new modules are installed that were not yet considered.
I think it's supposed to check those things on NULL->READY. If NULL->READY fails, other elements down the priority list will be considered AFAIK.
I guess this is fixed in master of gstreamer-vaapi since it checks for the installed backend when registering the elements. If the backend fails, the elements are not registered, though the plugin is not blacklisted neither, since it is assumed that the problem with the backend is transient.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/255.