[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