GNOME Bugzilla – Bug 304361
Python plugin loader
Last modified: 2009-02-09 13:03:56 UTC
Attached is a patch that implements a loader for GstElements written in Python. It autoloads all .py files stored in $LIBDIR/gstreamer-0.8/python. It has been tested to work and even garbage collect correctly. Unfortunately it depends on some bugs in pygtk before it is really usable.
Created attachment 46491 [details] [review] proposed patch I copied the libpython detection in configure.ac verbatim from nautilus-python, so comments about that should go to those people. :) Works fine for me though.
I'll make this depend on bug 303266, since writing new elements would trigger that problem unless special care was taken.
This is really neat! We should definitely push this in for 0.10. The patch probably doesn't require any changes at all. It probably doesn't *depend* on 303266; just that having #303266 solved would help python plugins quite a bit.
A couple of ideas on this, since creating elements with gst-python is getting easy and interests a lot of people. With the current way the registry works, we need a few additions to it. Currently the registry will check if the size/time of the .so has changed before trying to re-read the information contained in it. This is going to be problematic, since the python plugin .so will not change, but the python files might have. We therefore need a way to indicate that some GstPlugin handle that 'file/time has changed' feature. How the plugin informs that (none/some/all of the python files it supervises has changed) to the registry is still uncertain. Maybe it could compute a hash that would be stored in the registry and compared on successive runs. On another side, it might make more sense having this plugin code in the gst-python module since you will need gst-python anyway, and you are sure to have Python. This would keep core/-base lightweight.
This is a problem that is not unique to the Python loader - nor to loaders for other languages. The LADSPA plugin for example can have new plugins without its .so changing. An ffmpeg plugin that depended on an external ffmpeg would be another example. The easiest solution I had in mind was having a flag that marked plugins as "must-load". Another possibility would be to have a special dir (say $(plugindir)/autostart ;)) where you put (preferrably small) plugins. Then all you need to do is put a libgstcheckpython.so there that checks if new python stuff is available and if so, makes the registry load libgstpython.so. That way you'd get around loading the Python interpreter in every program but would still be sure you didn't miss anything.
Created attachment 70816 [details] [review] patch for autotools
Created attachment 70817 [details] tarball of the plugin directory This is the plugin directory containing the plugin loader and Makefile.am
Created attachment 70818 [details] Test plugin Sample plugin. Put this in ~/.gstreamer-0.10/plugins/python/
Above is the first trial for 0.10 . The only problem is that the registry won't reload the plugin when new .py files are available.
yet another problem is that signals emitted from python can't be used from C since there's no c_marshaller registered with signals created in pygobject.
the generic marshalling was added in pygobject 2.13.1
Created attachment 126740 [details] [review] New version using latest core API addition
Comment on attachment 126740 [details] [review] New version using latest core API addition >+ gst_plugin_add_dependency_simple (plugin, >+ "HOME/.gstreamer-0.10/plugins:GST_PYTHON_PLUGIN_PATH", >+ NULL, "py", GST_PLUGIN_DEPENDENCY_FLAG_NONE); The filename argument will by default not be interpreted as suffix, you'll have to pass the right flag to get it interpreted as suffix (fwiw, it's best/most efficient to just specify directories and provide no filename/suffix at all here, otherwise the directory has to be opened and all the filenames have to be parsed and stat'ed one-by-one). Btw, maybe I'm missing something, but it looks like at least comment #1 in gst_python_plugin_load() doesn't match the behaviour of the code: is it $FOO/python or $FOO?
I'm still uncertain as to where the python plugins should go ($FOO/python or $FOO). It made more sense for me to just have it in $FOO and match against the suffixes, so I was just toying around with it. Considering your comments, I guess it'll end in $FOO/python with no specified suffixes. This is not commit-ready (and I've in fact got a newer one with more fixes).
Created attachment 127047 [details] [review] Fix env variables and indentation
commit 9a5a1e8e7e7a43be837f2dd386af73f72fb78622 Author: Edward Hervey <bilboed@bilboed.com> Date: Mon Jan 19 08:38:10 2009 +0100 Python plugin loader implementation. Fixes #304361.