GStreamer registry cache

[Víctor M. Jáquez L.]

On 03/23/15 at 04:25pm, Cosimo Cecchi wrote:
> Hi all,
> 
> While investigating why some applications on our deployed OS were taking a
> long time to start, but only the first time one among a set was started on
> a clean user, we determined that GstRegistry was the cause of the delay, as
> it's generated in the home directory the first time a GStreamer application
> runs. (We were hitting this through a WebKit dependency, which initializes
> GStreamer.)

I guess the environment variable GST_REGISTRY_UPDATE would help you:

GST_REGISTRY_UPDATE.  Set this environment variable to "no" to prevent
GStreamer from updating the plugin registry. This is useful for embedded
device which is not updating the plugins frequently, it will save time when
doing gst_init().


> 
> Would it be possible to ship a static registry together with the OS (i.e.
> in /usr) instead? My understanding from reading this [1] is that the
> current implementation will only read from $XDG_CACHE_HOME.
> Of course, when the information in the system cache is out of date (e.g.
> because a new plugin was installed), another one would be generated in the
> home directory and that would take precedence when reading it back.
> Finally, it would be possible to add a command to update the system cache
> from a process that drives the installation of a new plugin (e.g. a package
> manager), similarly to how the GTK icon cache or fontconfig cache work.

I guess that simply running a gst-inspect-1.0 "at factory" and always setting
the GST_REGISTRY_UPDATE system-wide, would be the answer.

vmjl