|
From: GStreamer (bugzilla.gnome.org) <bug...@bu...> - 2006-08-08 19:26:43
|
Do not reply to this via email (we are currently unable to handle email responses and they get discarded). You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=3D350477 GStreamer | gstreamer (core) | Ver: HEAD CVS Summary: [Registry] Provide a way for plugins to delegate the 'changes' behaviour Product: GStreamer Version: HEAD CVS Platform: Other OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: Normal Component: gstreamer (core) AssignedTo: gst...@li... ReportedBy: bi...@bi... QAContact: gst...@li... CC: wi...@po..., bi...@bi... OtherBugsDependingO 304361 nThis: GNOME version: Unspecified GNOME milestone: Unspecified +++ This bug was initially created as a clone of Bug #304361 +++ Comment #4 from Edward Hervey (developer, points: 16) 2006-04-29 16:50 UTC [reply] A couple of ideas on this, since creating elements with gst-python is get= ting 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 t= o 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 supervi= ses 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. Comment #5 from Benjamin Otte (Company) (reporter, points: 17) 2006-04-30 11:20 UTC [reply] This is a problem that is not unique to the Python loader - nor to loader= s for other languages. The LADSPA plugin for example can have new plugins witho= ut 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 i= f 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. --=20 Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=3Demail ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |