mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2025-04-03 22:59:56 +00:00
Wrote a little more text, and did more of the work on making the sections.
Original commit message from CVS: Wrote a little more text, and did more of the work on making the sections. When this manual has text in all these sections its going to be pretty impressive...
This commit is contained in:
Richard Boulton
parent
085b22ac1f
commit
b27f8d7c31
6 changed files with 111 additions and 18 deletions
|
|
@ -5,7 +5,10 @@ sgml_files = gst-plugin-writers-guide.sgml \
|
|||
titlepage.sgml \
|
||||
intro.sgml \
|
||||
concepts.sgml \
|
||||
firstplugin.sgml
|
||||
firstplugin.sgml \
|
||||
testapp.sgml \
|
||||
loopbased.sgml \
|
||||
typesnprops.sgml
|
||||
|
||||
fig_files =
|
||||
eps_files =
|
||||
|
|
|
|||
|
|
@ -74,6 +74,34 @@
|
|||
available by writing the boilerplate yourself, so some plugins will
|
||||
always need to be manually registered.
|
||||
</para>
|
||||
<para>
|
||||
As a rough outline of what is planned: the FilterFactory will take a
|
||||
list of appropriate function pointers, and data structures to define
|
||||
a filter. With a reasonable measure of preprocessor magic, the
|
||||
plugin writer will then simply need to provide definitions of the
|
||||
functions and data structures desired, and a name for the filter, and
|
||||
then call a macro from within plugin_init() which will register the
|
||||
new filter. All the fluff that goes into the definition of a filter
|
||||
will thus be hidden from view.
|
||||
</para>
|
||||
<para>
|
||||
Ideally, we will come up with a way for various FilterFactory-provided
|
||||
functions to be overridden, to the point where you can construct
|
||||
almost the most complex stuff with it, it just saves typing.
|
||||
</para>
|
||||
<para>
|
||||
Of course, the filter factory can be used to create sources and sinks
|
||||
too: simply create a filter with only source or sink pads.
|
||||
</para>
|
||||
<para>
|
||||
You may be thinking that this should really be called an
|
||||
ElementFactory. Well, we agree, but there is already something else
|
||||
justifiably ealled an ElementFactory (this is the thing which actually
|
||||
makes instances of elements). There is also already something called
|
||||
a PluginFactory. We just have too many factories and not enough words.
|
||||
And since this isn't yet written, it doesn't get priority for claiming
|
||||
a name.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
|
|
|
|||
|
|
@ -7,11 +7,11 @@
|
|||
|
||||
<!ENTITY FIRSTPLUGIN SYSTEM "firstplugin.sgml">
|
||||
|
||||
<!ENTITY TESTAPP SYSTEM ".sgml">
|
||||
<!ENTITY TESTAPP SYSTEM "testapp.sgml">
|
||||
|
||||
<!ENTITY LOOPBASED SYSTEM ".sgml">
|
||||
<!ENTITY LOOPBASED SYSTEM "loopbased.sgml">
|
||||
|
||||
<!ENTITY TYPESNPROPS SYSTEM ".sgml">
|
||||
<!ENTITY TYPESNPROPS SYSTEM "typesnprops.sgml">
|
||||
|
||||
<!ENTITY BUFFERS SYSTEM ".sgml">
|
||||
|
||||
|
|
@ -99,11 +99,6 @@
|
|||
</partintro>
|
||||
|
||||
&TESTAPP;
|
||||
Initialization
|
||||
Instantiating the plugins
|
||||
(NOTE: we really should have a debugging Sink)
|
||||
Connecting them
|
||||
Running the pipeline
|
||||
</part>
|
||||
|
||||
<!-- ############ part ############# -->
|
||||
|
|
@ -115,11 +110,6 @@
|
|||
</partintro>
|
||||
|
||||
&LOOPBASED;
|
||||
How scheduling works, aka pushing and pulling
|
||||
How a loopfunc works, aka pulling and pushing
|
||||
Adding a second output
|
||||
Identity is now a tee
|
||||
Modifying the test application
|
||||
</part>
|
||||
|
||||
<!-- ############ part ############# -->
|
||||
|
|
@ -131,10 +121,6 @@
|
|||
</partintro>
|
||||
|
||||
&TYPESNPROPS;
|
||||
Building a simple format for testing
|
||||
A simple MIME type
|
||||
Type properties
|
||||
Typefind functions and autoplugging
|
||||
</part>
|
||||
|
||||
<!-- ############ part ############# -->
|
||||
|
|
|
|||
27
docs/fwg/loopbased.sgml
Normal file
27
docs/fwg/loopbased.sgml
Normal file
|
|
@ -0,0 +1,27 @@
|
|||
<chapter id="cha-loopbased-sched">
|
||||
<title>How scheduling works</title>
|
||||
<para>
|
||||
aka pushing and pulling
|
||||
</para>
|
||||
</chapter>
|
||||
|
||||
<chapter id="cha-loopbased-loopfn">
|
||||
<title>How a loopfunc works</title>
|
||||
<para>
|
||||
aka pulling and pushing
|
||||
</para>
|
||||
</chapter>
|
||||
|
||||
<chapter id="cha-loopbased-secnd">
|
||||
<title>Adding a second output</title>
|
||||
<para>
|
||||
Identity is now a tee
|
||||
</para>
|
||||
</chapter>
|
||||
|
||||
<chapter id="cha-loopbased-modappl">
|
||||
<title>Modifying the test application</title>
|
||||
<para>
|
||||
</para>
|
||||
</chapter>
|
||||
|
||||
25
docs/fwg/testapp.sgml
Normal file
25
docs/fwg/testapp.sgml
Normal file
|
|
@ -0,0 +1,25 @@
|
|||
<chapter id="cha-testapp-init">
|
||||
<title>Initialization</title>
|
||||
<para>
|
||||
</para>
|
||||
</chapter>
|
||||
|
||||
<chapter id="cha-testapp-inst">
|
||||
<title>Instantiating the plugins</title>
|
||||
<para>
|
||||
(NOTE: we really should have a debugging Sink)
|
||||
</para>
|
||||
</chapter>
|
||||
|
||||
<chapter id="cha-testapp-connect">
|
||||
<title>Connecting the plugins</title>
|
||||
<para>
|
||||
</para>
|
||||
</chapter>
|
||||
|
||||
<chapter id="cha-testapp-connect">
|
||||
<title>Running the pipeline</title>
|
||||
<para>
|
||||
</para>
|
||||
</chapter>
|
||||
|
||||
24
docs/fwg/typesnprops.sgml
Normal file
24
docs/fwg/typesnprops.sgml
Normal file
|
|
@ -0,0 +1,24 @@
|
|||
<chapter id="cha-types-test">
|
||||
<title>Building a simple format for testing</title>
|
||||
<para>
|
||||
</para>
|
||||
</chapter>
|
||||
|
||||
<chapter id="cha-types-simplemime">
|
||||
<title>A simple MIME type</title>
|
||||
<para>
|
||||
</para>
|
||||
</chapter>
|
||||
|
||||
<chapter id="cha-types-props">
|
||||
<title>Type properties</title>
|
||||
<para>
|
||||
</para>
|
||||
</chapter>
|
||||
|
||||
<chapter id="cha-types-typefind">
|
||||
<title>Typefind functions and autoplugging</title>
|
||||
<para>
|
||||
</para>
|
||||
</chapter>
|
||||
|
||||
Loading…
Reference in a new issue