Gstreamer registry

[Nicolas Dufresne]

Le vendredi 21 octobre 2016 à 07:02 +0000, Thornton, Keith a écrit :
> I currently have gstreamer pipelines (1.8.3) running on a windows
> machine. This machine is subject to hard power downs. For this
> reason, the OS and some other stuff are on a read-only disk.
> Recently we have been having problems with the Gstreamer registry. I
> am thinking of generating a copy of the registry and then placing it
> on this read only disk.
> Is this a good idea?

It should work, if not, let us know, we'll fix it.

> Where can I find documentation as to when the registry is written to
> and what is stored there?

Generating the registry is as simple as calling gst_init() in a C
application. Of course you can simply run gst-inspect-1.0. The
difficulty is that you need to run this on the target, or at least
inside the target rootfs. These days, most people uses build systems
that matches the target CPU (ARM for ARM, X86 for X86, etc.).

To make this to work, you need to be aware of two environment variable.
GST_REGISTRY will point to the location of the registry file. As the
registry is system wide (and not per user), you'll want to set this
environment to where you have installed your generated cache. You also
set that to choose where to put the cache you want to generate (for the
build). Second important environment is GST_REGISTRY_UPDATE. Without
this, you would have to be really careful about modification time of
the cache and the plugins. Setting this environment to 1 will skip the
check to update the cache, and simply use it. Of course, you'll get
strange bugs if your cache get out of sync, don't let that happen.

The registry contains a list of all plugins, and features inside those
plugins. For each features (element, typefinder etc.) all the metadata
is stored including the information about pads and their template
capabilities. This way, you can dynamically select elements in playbin
or other dynamic systems without having to open all of the plugin
shared object files.

Nicolas