Gstreamer registry

[Thornton, Keith]

Hi,

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?

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

Regards Keith

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-4]

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
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Thornton, Keith]

Thank you Nicolas,
I will try it out. I can generate a new version each time I build gstreamer using cerbero. We are not using dynamic stuff like playbin or typefinders. We know exactly which plugins are being used in our pipelines.
Regards Keith


-----Ursprüngliche Nachricht-----
Von: gstreamer-devel [mailto:[hidden email]] Im Auftrag von Nicolas Dufresne
Gesendet: Freitag, 21. Oktober 2016 16:37
An: Discussion of the development of and with GStreamer <[hidden email]>
Betreff: Re: Gstreamer registry

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
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel