mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-26 03:31:05 +00:00
Added a document about how we handle plugins and dynamic loading.
Original commit message from CVS: Added a document about how we handle plugins and dynamic loading.
This commit is contained in:
parent
d78215be9d
commit
97fc2e9f07
1 changed files with 89 additions and 0 deletions
89
docs/random/plugins
Normal file
89
docs/random/plugins
Normal file
|
@ -0,0 +1,89 @@
|
|||
We describe how the plugin system works.
|
||||
|
||||
Plugins
|
||||
-------
|
||||
|
||||
plugins are basically shared libraries with a plugin_init
|
||||
function.
|
||||
|
||||
they provide the GStreamer core library with the folowing
|
||||
information:
|
||||
|
||||
- elementfactories
|
||||
- typefactories
|
||||
- metadatafactories?
|
||||
|
||||
ElementFactory
|
||||
--------------
|
||||
|
||||
elementfactories provide the core library with elements (duh)
|
||||
|
||||
an elementfactory has the following information:
|
||||
|
||||
- a unique name for the element
|
||||
- strings describing the element (name, desciption, copyright,...)
|
||||
- a description of the media types it accepts (as capabilities)
|
||||
- a description of the media types it outputs (as capabilities)
|
||||
|
||||
|
||||
TypeFactory
|
||||
-----------
|
||||
|
||||
has the following properties:
|
||||
|
||||
- a mime type
|
||||
- file extensions that may provide a hint for this type
|
||||
- a function to detect this type
|
||||
- a string to detect this type (file(1) like)
|
||||
|
||||
|
||||
XML registry
|
||||
------------
|
||||
|
||||
The complete plugin tree will be exported into an XML desciption so
|
||||
that the definitions of the factories can be obtained without having
|
||||
to load and plugin_init the plugins.
|
||||
|
||||
Loading of plugins
|
||||
------------------
|
||||
|
||||
at some point, the plugin will need to be read into memory before
|
||||
any elements it provides can be used. the XML description of the
|
||||
loaded plugin will need to be updated.
|
||||
|
||||
We will have the following methods for (implicitly) loading plugins:
|
||||
|
||||
gst_plugin_load_all()
|
||||
|
||||
remove the complete XML tree and read all the plugins in the
|
||||
paths. The plugin_init method will be called and the XML tree
|
||||
will be rebuild in memory.
|
||||
|
||||
gst_plugin_load (name)
|
||||
|
||||
The plugin will be located in the tree and if it allready loaded, the
|
||||
function returns. If it is not loaded, the XML entry is removed and
|
||||
the plugin is loaded. The plugin_init is called so that the XML tree
|
||||
is reconstructed.
|
||||
|
||||
gst_elementfactory_create (factory, name);
|
||||
|
||||
The plugin providing the element will be located, if the plugin is
|
||||
allready loaded, an element with the given name is created.
|
||||
if the plugin is not loaded, gst_plugin_load is called.
|
||||
the loaded factory is located again and the element is created.
|
||||
|
||||
The typefind function is called
|
||||
|
||||
When the plugin description is read from the XML file, the typefind
|
||||
function is hooked up to a dummy typefind function. The dummy typefind
|
||||
function will locate the plugin it belongs to and call gst_plugin_load.
|
||||
after the loading of the plugin, the real typefind function is called.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
Loading…
Reference in a new issue