GNOME Bugzilla – Bug 571604
registry feature are replaced during first use
Last modified: 2009-06-07 18:46:33 UTC
Its just a performance issue, try this: > GST_DEBUG="GST_REGISTRY:4" GST_DEBUG_NO_COLOR=1 gst-launch-0.10 2>debug.log fakesrc num-buffers=10 ! fakesink fakesinkk > grep "replacing" debug.log 0:00:01.053512375 4560 0x804f050 DEBUG GST_REGISTRY gstregistry.c:448:gst_registry_add_feature:<registry0> replacing existing feature 0x80f1da0 (capsfilter) 0:00:01.053904446 4560 0x804f050 DEBUG GST_REGISTRY gstregistry.c:448:gst_registry_add_feature:<registry0> replacing existing feature 0x80f1d10 (fakesrc) ... Problem is that when a plugin is used, gstreamer calls plugin_init() and this calls gst_element_register(). Now gst_element_register() should be a bit smarter and just return, if the plugin feature is already registerd (or if we are not updating the registry. Ideally we could query that in plugin_init() and skip registering the features (e.g. having a gst_registry_is_updating()).
Makes sense to me. When a plugin is loaded, the pluginfeatures that point to the unloaded plugin are replaced with pluginfeatures that point to the loaded plugin. Otherwise, the second use of fakesrc would attempt to reload the plugin.
Okay, I see what you mean. There are subtle differences of gstelementfactory.c::gst_element_register() and gstregistrybonary.c:gst_registry_binary_load_feature(). gst_element_register() sets factory->type = type; GST_PLUGIN_FEATURE (factory)->loaded = TRUE; Maybe gst_element_register() can lookup the feature and update it, instead of creating a new gobject instance, copying the element details, removing and inserting a list entry ...
Please look at my branch in http://cgit.freedesktop.org/~thaytan/gstreamer/ - I've made a lot of changes to the way the registry handles stuff. It preserves this piece of functionality though, because: a) At the moment, the registry doesn't know whether someone has a reference to the feature (from a registry lookup). If someone else is using the PluginFeature, we can't go replacing it. b) More importantly, the plugin details that were loaded from the registry cache might not match the details from the actual plugin file when we go to load it (it *might* have been replaced between the initial scan and the load request). Hence, even if we checked that the only reference was the one the registry has, we couldn't ensure it was up to date without replacing each entry of the feature details anyway. Nevertheless, making this stuff faster is the next thing I want to do, after merging my WIP registry-rewrite branch...
Irks, I forgot about this and made a patch for it in #584389. It works fine for me and I like to get feedback now that we have some time until we freeze again. Regarding Jans comments: a) I don't replace it in he patch, I update the fields. When the feature is loaded from the cache all non-serializable info is missing (e.g. GType). This is added there on first use. b) The detail will match, as if the plugin is outdated the registry will be rescanned. In that case the plugin feature are removed so that when the code is getting there it won't find an existing feature.
*** This bug has been marked as a duplicate of 584389 ***