[gstreamer-bugs] [Bug 350477] New: [Registry] Provide a way for plugins to delegate the 'changes' behaviour
GStreamer (bugzilla.gnome.org)
bugzilla-daemon at bugzilla.gnome.org
Tue Aug 8 12:26:55 PDT 2006
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=350477
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: gstreamer-bugs at lists.sourceforge.net
ReportedBy: bilboed at bilboed.com
QAContact: gstreamer-bugs at lists.sourceforge.net
CC: wingo at pobox.com, bilboed at bilboed.com
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 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.
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 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.
--
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the Gstreamer-bugs
mailing list