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