This is a string describing a date and/or date/time in a simple subset of
the ISO-8601 format, namely either "YYYY-MM-DD" or "YYYY-MM-DDTHH:MMZ" (with
'T' the date/time separator and the 'Z' indicating UTC).
The main purpose of this field is to keep track of plugin and element versions
on an absolute timeline, so it's possible to determine which one is newer when
comparing two date time numbers. This will allow us to express 'replaces'-type
relationships betweeen plugins and element factories in future, even across
different modules and plugin merges or splits (source module version numbers
aren't particularly useful here, since they can only meaningfully be compared
within the same module). It also allows applications and libraries to reliably
check that a plugin is recent enough without making assumptions about modules
or module versions.
We use a string here to keep things simple and clear, esp. on the build system
side of things.
https://bugzilla.gnome.org/show_bug.cgi?id=623040
This feature is primarily intended for use in plugin modules' unit tests.
Consider the following situation: gst-plugins-good is built against an
installed GStreamer core. An older version of gst-plugins-good is also
installed in that prefix, along with random other plugin modules. Now,
when doing 'make check' in the just-built gst-plugins-good tree, we
want to only load plugins from GStreamer core, gst-plugins-base, and
gst-plugins-good, but not random other modules (we don't want any unit
tests to fail just because some module in gst-plugins-bad has a broken
plugin_init, for example). Also, we want to only load gst-plugins-good
modules from the locally-built source tree, but not any of the older
gst-plugins-good modules installed. This is usually assured by loading
the ones in the source tree first (by adding that path first to the
right environment variables), but it gets tricky when plugins are
moved, removed, merged, or renamed, or the plugin filename changes.
Note that 'make check' should really work right without doing
'make install' or uninstalling the old gst-plugins-good package (or
any other gst-plugins-foo package) first.
Enter GST_PLUGIN_LOADING_WHITELIST. This environment variable may
contain source-package@path-prefix pairs separated by the platform
search path separator (G_SEARCHPATH_SEPARATOR_S). The source package
and path prefix are separated by the '@' character. The path prefix is
entirely optional, as is the '@' separator if no path is given.
It is also possible to filter based on plugin names instead of the name
of the source-package by specifying one or more plugin names separated
by commas before the optional path prefix.
In short, the following match patterns are possible:
plugin1,plugin2@pathprefix or
plugin1,plugin2@* or just
plugin1,plugin2 or
source-package@pathprefix or
source-package@* or just
source-package
So for our gst-plugins-good unit test example above, we would set the
environment variable on *nix to something like this (will likely be a
relative path in practice):
gstreamer:gst-plugins-base:gst-plugins-good@/path/to/src/gst-plugins-good
Fixes#619815 and #619717.
This is what can happen in a plugin_init function:
- An element based on GstBaseSink is registered
- Other elements fail to register
- The plugin_init function returns FALSE
Now if this the plugin is the first plugin to link against
libgstbase.so, it will have caused libgstbase.so to be loaded and static
strings from that library will have been added to gobject while
registering GstBaseSink.
So unloading the plugin will cause those strings to go stale and the
next plugin using GstBaseSink will crash. So we must not unload modules
after calling into them ever.
https://bugzilla.redhat.com/show_bug.cgi?id=572800
This changes some APIs in compatible ways:
- Some functions now take "const char *" arguments, not "char *"
- Some structs now have "conts char *" members, not "char *"
The changes may cause warnings when compiling with the right warning
flags. You've been warned.
Also adds -Wwrite-strings as a warning flag in configure.ac.
https://bugzilla.gnome.org/show_bug.cgi?id=611692
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
For the reason outlined at the beginning of gst_private.h (inline
functions in glib may need the g_log_domain variable). Also include
gst_private.h before using any G_OS_* defines, esp. in plugin loader.
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.
The first time one calls gst_element_factory_make(), gst recreates the plugin
feature and the element factory. As a side effect we ref the class to fill
in detail we already have filled from the registry cache. This patch changes
the behaviour to just update the existing entries. The factory is now attached
to the type and set in gst_element_base_class_init().
Original commit message from CVS:
* gst/gstplugin.c:
* gst/gstregistry.c:
GstRegistryPool doesn't exist; don't refer to it in docs.
Don't refer to functions that don't exist in docs, it's
unhelpful.
Original commit message from CVS:
* gst/gstplugin.c: (CHECK_PLUGIN_DESC_FIELD), (gst_plugin_load_file):
Print error debug message if plugin description fields that should
be set are NULL.
* gst/gstregistrybinary.c: (gst_registry_binary_save_const_string):
Don't crash if the string to serialise is NULL (it really should
not be, but apparently this used to work with the xml registry ...).
Original commit message from CVS:
* gst/gstplugin.c: (_gst_plugin_initialize):
Fix old-style static plugins via GST_PLUGIN_DEFINE_STATIC
again, which I broke two commits ago when changing the API
of gst_plugin_register_static(): the g_list_foreach() in
_gst_plugin_register_static still assumed the old function
signature and would therefore fail (re-fixes #510187).
* gst/gstplugin.c: (_num_static_plugins), (_static_plugins),
(_gst_plugin_register_static), (gst_plugin_register_static):
Revert the (technically correct) change to call g_thread_init() from
the pre-main() constructor. This will break programs which call
g_thread_init() without an if (!g_thread_supported()) guard in their
main function. We could just blame it on GLib or the application, but
it's probably best to just avoid this altogether and simply not use
any GLib functions here and use plain old malloc() with a simple
array to store the plugins to register later when gst_init() is
finally called (re-fixes #510187).
* tests/check/gst/gstplugin.c: (GST_GNUC_CONSTRUCTOR_DEFINED),
(GST_GNUC_CONSTRUCTOR_DEFINED), (plugin_init_counter),
(plugin1_init), (plugin2_init), (plugin3_init), (GST_START_TEST),
(GST_START_TEST), (gst_plugin_suite):
Dumb unit test to make sure the old GST_PLUGIN_DEFINE_STATIC still
works.
Original commit message from CVS:
* gst/gst.c: (init_post):
* gst/gstplugin.c: (_gst_plugin_register_static),
(gst_plugin_register_static), (_gst_plugin_initialize):
* gst/gstplugin.h: (GstPluginFilter):
Change API of gst_plugin_register_static() to not take
a GstPluginDesc, but rather just take all the arguments
in a GstPluginDesc directly. This is more intuitive and
avoids certain mistakes when porting code from
GST_PLUGIN_DEFINE_STATIC to gst_plugin_register_static().
Fixes#510187.
* tests/check/gst/gstplugin.c:
Fix up for changed API.
Original commit message from CVS:
* docs/gst/gstreamer-sections.txt:
* gst/gst.c: (init_post):
* gst/gstplugin.c: (_gst_plugin_register_static),
(gst_plugin_register_static), (_gst_plugin_initialize),
(gst_plugin_register_func):
* gst/gstplugin.h: (GST_PLUGIN_DEFINE_STATIC):
API: add gst_plugin_register_static() and deprecate
GST_PLUGIN_DEFINE_STATIC, since it's not portable
(#498924).
Also, in _gst_plugin_register_static(), make sure to call
g_thread_init() before calling GLib functions such as
g_list_append() if we're not initialised yet, since that
may lead to random crashes with older GSlice/GLib versions.
* tests/check/gst/gstplugin.c:
Adapt unit test to above changes.
