__registry_reuse_plugin_scanner is only defined when
GST_DISABLE_REGISTRY is not defined.
gstregistry.c: In function 'gst_registry_scan_plugin_file':
gstregistry.c:1131:8: error: '__registry_reuse_plugin_scanner' undeclared (first use in this function)
https://bugzilla.gnome.org/show_bug.cgi?id=667284
It's only used internally anyway and the helper struct
has namespace issues.
API: deprecated gst_plugin_feature_type_name_filter()
API: deprecated GstTypeNameData
This will make sure we spawn a new plugin scanner helper for each plugin
to be introspected, which helps with making sure we don't load too many
shared objects (libs, plugins) at the same time on systems where there
is a hard limit like on Android.
A better version might re-use the scanner for up to N times, though
it's not clear whether that would actually improve things dramatically.
https://bugzilla.gnome.org/show_bug.cgi?id=662091
The feature name is not supposed to change over time anyway. In order to enforce
this parentize features to the registry and make the feature->name pointing to
GstObject:name. In 0.11 we could consider of removing the feature->name variable
(FIXME comment added).
Fixes: #459466
When a plugin file no longer exists, e.g. because it's been removed or
renamed, don't remove all features in the registry based on the *name*
of the plugin they belong to, but only remove those who actually belong
to that particular plugin (object/pointer).
This fixes issues of plugin features disappearing when a plugin .so file
is renamed.
https://bugzilla.gnome.org/show_bug.cgi?id=604094
Only replace existing plugins by blacklisted ones if they correspond
to the exact same plugin. If they're not the same, keep the existing
valid one.
Fixes#638941
Ignore plugins which have been moved into coreelements, so it's
still possible to just upgrade GStreamer core without having to
upgrade the whole stack.
Adds that warning to configure.ac
Includes a tiny change of the GST_BOILERPLATE_FULL() macro:
The get_type() function is no longer declared before being defined.
https://bugzilla.gnome.org/show_bug.cgi?id=611692
This returns the internal feature list cookie, which changes every
time a feature is added or removed. This can be used by elements
to check if they should update their cached feature lists.
This avoids:
* triple-checking for the GType when type-checking is enabled (see #597260)
* Avoids going through an expensive no-argument checking which landed in
glib-2.22
* Avoids going through 2 extrac functions (g_object_new -> g_object_new_valist)
There's not much point in using GST_DEBUG_FUNCPTR with GObject
virtual functions such as get_property, set_propery, finalize and
dispose, since they'll never be used by anyone anyway. Saves a
few bytes and possibly a tenth of a polar bear.
This avoids having to do the sorting everytime we use typefind
The behaviour of gst_type_find_factory_get_list has subtlely changed
in the sense that the order was previously undefined, whereas now
it returns them sorted by rank and then by name.
Maintain a hashtable of the plugin basename. We can then use this
hashtable to speedup the search for an existing plugin and avoid
a whole lot of strcmp calls.
When the plugin-scanner load fails (because the helper can't be
spawned), make sure to load the plugin that failed in-process, so
that all plugins do get loaded.
Everyone running an uninstalled git setup is going to wonder about
this failure next time they update, so let's mention the solution
in the error message.
When updating the registry, we don't need to re-read the registry cache
and waste time replacing all our existing, hopefully identical, plugins
and features that we're about to re-scan anyway.
phase 2 - make the plugin loader receive the list of plugins to load and
send back the results asynchronously, so we don't context switch back
and forth so much.
