GNOME Bugzilla – Bug 782867
gst-omx: plugin stays blacklisted even when modifying gstomx.conf or GST_OMX_CONFIG_DIR
Last modified: 2017-05-21 14:58:00 UTC
In practice it is only annoying at development time. But then I found this is also not consistent with other auto-generated plugins like gst-{ffmpeg,libav} and gstreamer-vaapi which always return TRUE from plugin_init. Let's do the same for gst-omx.
Created attachment 352224 [details] [review] omx: allow 0 feature
Comment on attachment 352224 [details] [review] omx: allow 0 feature Worksforme
Comment on attachment 352224 [details] [review] omx: allow 0 feature Author: Julien Isorce <jisorce@oblong.com> Date: Sat May 20 14:49:20 2017 +0100 omx: allow 0 feature Previously the omx plugin was blacklisted if GST_OMX_CONFIG_DIR points to an invalid path or if the gstomx.conf contains 0 valid component. Problem is that once the plugin is blacklisted, a rescan is not triggered upon changes of the env var or the gstomx.conf file despite being setup with gst_plugin_add_dependency. This also makes it more consistent with other plugins that auto generate features. For example gst-{ffmeg,libav}, gstreamer-vaapi, v4l2 video dec. To clarify the diff, the plugin_init func will return TRUE even if g_key_file_get_groups returns 0 element and even if g_key_file_load_from_dirs fails. https://bugzilla.gnome.org/show_bug.cgi?id=782867