Class Registry

java.lang.Object
All Implemented Interfaces:
Proxy

@Generated("io.github.jwharm.JavaGI") public class Registry extends GstObject
One registry holds the metadata of a set of plugins.

<emphasis role="bold">Design:</emphasis>

The GstRegistry object is a list of plugins and some functions for dealing with them. Each GstPlugin is matched 1-1 with a file on disk, and may or may not be loaded at a given time.

The primary source, at all times, of plugin information is each plugin file itself. Thus, if an application wants information about a particular plugin, or wants to search for a feature that satisfies given criteria, the primary means of doing so is to load every plugin and look at the resulting information that is gathered in the default registry. Clearly, this is a time consuming process, so we cache information in the registry file. The format and location of the cache file is internal to gstreamer.

On startup, plugins are searched for in the plugin search path. The following locations are checked in this order:

  • location from --gst-plugin-path commandline option.
  • the GST_PLUGIN_PATH environment variable.
  • the GST_PLUGIN_SYSTEM_PATH environment variable.
  • default locations (if GST_PLUGIN_SYSTEM_PATH is not set). Those default locations are: $XDG_DATA_HOME/gstreamer-$GST_API_VERSION/plugins/ and $prefix/libs/gstreamer-$GST_API_VERSION/. $XDG_DATA_HOME defaults to $HOME/.local/share.

The registry cache file is loaded from $XDG_CACHE_HOME/gstreamer-$GST_API_VERSION/registry-$ARCH.bin (where $XDG_CACHE_HOME defaults to $HOME/.cache) or the file listed in the GST_REGISTRY env var. One reason to change the registry location is for testing.

For each plugin that is found in the plugin search path, there could be 3 possibilities for cached information:

  • the cache may not contain information about a given file.
  • the cache may have stale information.
  • the cache may have current information.

In the first two cases, the plugin is loaded and the cache updated. In addition to these cases, the cache may have entries for plugins that are not relevant to the current process. These are marked as not available to the current process. If the cache is updated for whatever reason, it is marked dirty.

A dirty cache is written out at the end of initialization. Each entry is checked to make sure the information is minimally valid. If not, the entry is simply dropped.

Implementation notes:
The "cache" and "registry" are different concepts and can represent different sets of plugins. For various reasons, at init time, the cache is stored in the default registry, and plugins not relevant to the current process are marked with the PluginFlags.CACHED bit. These plugins are removed at the end of initialization.