GNOME Bugzilla – Bug 359777
Make gst-inspect's default output more precise when it encounters a problem with a plug-in
Last modified: 2006-12-16 16:45:42 UTC
When running gst-inspect with its default output level, it doesn't necessarily give the most helpful information if errors occur. By this I mean I've found that if I happen to have a plug-in that has a problem, gst-inspect will suggest it wasn't found, when in fact it did find it (as I can see at the highest debug level), it's just it can't actually work with it properly. My specific example is that one of the core plugins (videoscale) had problems when it was compiled on my machine. Because of this, it's blocking totem from being compiled, as totem's configure script uses gst-inspect and finds it's "absent". But it isn't absent: [disciple@arcusv:disciple]$ locate videoscale /usr/pkg/lib/gstreamer-0.10/libgstvideoscale.a /usr/pkg/lib/gstreamer-0.10/libgstvideoscale.la /usr/pkg/lib/gstreamer-0.10/libgstvideoscale.so [disciple@arcusv:disciple]$ gst-inspect-0.10 videoscale No such element or plugin 'videoscale' This is what I get when I run gst-inspect with more verbose output: WARN (0x1824580 - 0:00:01.379554000) GST_PLUGIN_LOADING( 2638) gstplugin.c(410):gst_plugin_load_file: module_open failed: /usr/pkg/lib/liboil-0.3.so.0: Unsupported relocation type 10 in non-PLT relocations So it'd be helpful if gst-inspect said "error with <plug-in name>" or something in this case instead of "no such element or plugin".
This is not really solvable. gst_plugin_load_file indeed gives a detailed error... but look at who is the caller here, it is performed by the (implicit) update of the registry. Basically this is what happens: All files *.so on the search path are tried to be loaded as a module; if it succeeds on loading a file and the module is actually a compatible gstreamer plugin, obtain information about all contained element factories and other features and store the data in the registry. Errors occurring during these steps are intentionally ignored at this point and just mentioned in the debug output. This is correct, not all files on the search path strictly need to be compatible modules. You might think that since you are requesting the videoscale element explicitly, it should treat failure for the videoscale plugin with special care or even try to gst_plugin_load_file it manually in order to get the correct error, but this approach is incompatible with the current design: It is considered an implementation detail in which plugin a particular element resides. If you request the element "textoverlay", there is no way to know that it is provided by the plugin "pango" until you load the module "libpango.so" and find the element there. Likewise, if you cannot load "gstvideoscale.so" there is no way to know that it should contain the element "videoscale" you asked for.
The .so names I bring up as examples are rather "libgstpango.so" and "libgstvideoscale.so" of course.