Issue with registry.x86_64.bin

Jan Alexander Steffens jan.steffens at gmail.com
Tue May 2 07:55:23 UTC 2017


On Tue, May 2, 2017 at 9:44 AM Simon Michnowicz <simon.michnowicz at monash.edu>
wrote:

> Dear Gstreamer List,
>
> I am trying to debug a commercial application that uses Gstreamer. We are
> running on a Centos 7 cluster with a variety of graphics cards (i.e. K80)
> in an Openstack virtual environment.
>
>  When the program runs for the first time on a machine, a considerable
> time delay occurs (40+ minutes) before the program initializes, although
> subsequent runs start immediately.
>
> I have traced this delay to a file, ~/.gstreamer-0.10/registry.x86_64.bin
> If you delete the file, we can trigger the very long delay when running
> the program.
>
> I am not a Gsteamer developer, so would be very grateful if anybody could
> advise me on how this file is created. We are very interested into why it
> is taking so long to create. This could be a programming issue with the
> commercial application, but it could also point to some very strange
> interactions between Gstreamer and the virtual environment.
>

When GStreamer initializes, it loads metadata from all plugins. Internally,
it forks a gst-plugin-scanner process to actually load the plugins (this
shields the application process from crashes caused by bad plugins and/or
libraries). The result of this is cached in the registry file.

I would attempt to use fatrace (which observes filesystem accesses,
system-wide) to watch the plugin scanner load plugins, in order to discover
which plugin is causing a delay here.


> Are there any tools that we could use to generate this file to confirm
> that this is in fact the problem?
>

If the file is missing, just running gst-inspect-1.0 should be enough to
regenerate it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170502/d7885a30/attachment.html>


More information about the gstreamer-devel mailing list