mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-25 03:01:03 +00:00
First draft of Chapter 1 (introduction) and Chapter 2 (basic concepts) of the GStreamer manual.
Original commit message from CVS: First draft of Chapter 1 (introduction) and Chapter 2 (basic concepts) of the GStreamer manual.
This commit is contained in:
Wim Taymans
parent
d21bcc5e44
commit
018a6f381b
21 changed files with 1084 additions and 0 deletions
4
docs/manual/.gitignore
vendored
Normal file
4
docs/manual/.gitignore
vendored
Normal file
|
|
@ -0,0 +1,4 @@
|
|||
Makefile
|
||||
Makefile.in
|
||||
*.bak
|
||||
.deps
|
||||
19
docs/manual/BUILD
Normal file
19
docs/manual/BUILD
Normal file
|
|
@ -0,0 +1,19 @@
|
|||
For now use:
|
||||
|
||||
db2html gstreamer-manual
|
||||
|
||||
You will need the png support for docbook (see GNOME documentation project)
|
||||
|
||||
convert the fig images to png with:
|
||||
|
||||
fig2dev -L png -s 16 fig/<input file>.fig images/<input file>.png
|
||||
|
||||
Put a link in the gstreamer-manual directory with
|
||||
|
||||
ln -s ../images gstreamer-manual/images
|
||||
|
||||
point your browser to gstreamer-manual/gstreamer.html
|
||||
|
||||
Fix typing errors and correct bad english.
|
||||
Let me know about the stuff that needs some more explanation.
|
||||
Let me know about the structure of the document.
|
||||
19
docs/manual/README
Normal file
19
docs/manual/README
Normal file
|
|
@ -0,0 +1,19 @@
|
|||
For now use:
|
||||
|
||||
db2html gstreamer-manual
|
||||
|
||||
You will need the png support for docbook (see GNOME documentation project)
|
||||
|
||||
convert the fig images to png with:
|
||||
|
||||
fig2dev -L png -s 16 fig/<input file>.fig images/<input file>.png
|
||||
|
||||
Put a link in the gstreamer-manual directory with
|
||||
|
||||
ln -s ../images gstreamer-manual/images
|
||||
|
||||
point your browser to gstreamer-manual/gstreamer.html
|
||||
|
||||
Fix typing errors and correct bad english.
|
||||
Let me know about the stuff that needs some more explanation.
|
||||
Let me know about the structure of the document.
|
||||
66
docs/manual/bins.sgml
Normal file
66
docs/manual/bins.sgml
Normal file
|
|
@ -0,0 +1,66 @@
|
|||
<chapter id="cha-bins">
|
||||
<title>Bins</title>
|
||||
<para>
|
||||
A Bin is a container element. You can add elements to a bin. Since a bin is
|
||||
an element itself, it can also be added to another bin.
|
||||
</para>
|
||||
<para>
|
||||
Bins allow you to combine connected elements into one logical element. You do
|
||||
not deal with the individual elements anymore but with just one element, the bin.
|
||||
We will see that this is extremely powerfull when you are going to construct
|
||||
complex pipelines since it allows you to break up the pipeline in smaller chunks.
|
||||
</para>
|
||||
<para>
|
||||
The bin will also manage the elements contained in it. It will figure out how
|
||||
the data will flow in the bin and generate an optimal plan for that data flow.
|
||||
</para>
|
||||
|
||||
<figure float="1" id="sec-bin-img">
|
||||
<title>Visualisation of a <classname>GstBin</classname> element with some elements in it</title>
|
||||
<graphic fileref="images/bin-element" format="png"></graphic>
|
||||
</figure>
|
||||
|
||||
<para>
|
||||
There are two standard bins available to the GStreamer programmer:
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
A pipeline (<classname>GstPipeline</classname>). Which is a generic container you will
|
||||
use most of the time.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
A thread (<classname>GstThread</classname>). All the elements in the thread bin will
|
||||
run in a separate thread. You will haver to use this bin if you carfully have to
|
||||
synchronize audio and video for example. You will learn more about threads in.. <!-- FIXME -->
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The application programmer can create custom bins packed with elements to perform a
|
||||
specific task. This allow you to write an MPEG audio decoder with just the follwing lines
|
||||
of code:
|
||||
|
||||
<programlisting>
|
||||
|
||||
// create the mp3player element
|
||||
GstElement *mp3player = gst_elementfactory_make("mp3player","mp3player");
|
||||
// set the source mp3 audio file
|
||||
gtk_object_set(GTK_OBJECT(mp3player), "location", "helloworld.mp3", NULL);
|
||||
// tell the mp3player to prepare itself
|
||||
gst_element_set_state(GST_ELEMENT(mp3player),GST_STATE_READY);
|
||||
// start playback
|
||||
gst_element_set_state(GST_ELEMENT(mp3player),GST_STATE_PLAYING);
|
||||
...
|
||||
// pause playback
|
||||
gst_element_set_state(GST_ELEMENT(mp3player),GST_STATE_PAUSED);
|
||||
...
|
||||
// stop
|
||||
gst_element_set_state(GST_ELEMENT(mp3player),GST_STATE_NULL);
|
||||
</programlisting>
|
||||
</para>
|
||||
</chapter>
|
||||
77
docs/manual/buffers.sgml
Normal file
77
docs/manual/buffers.sgml
Normal file
|
|
@ -0,0 +1,77 @@
|
|||
<chapter id="cha-buffers">
|
||||
<title>Buffers</title>
|
||||
<para>
|
||||
Buffers contain the data that will flow through the pipeline you have created. A source
|
||||
element will typically create a new buffer and pass it through the pad to the next
|
||||
element in the chain.
|
||||
When using the GStreamer infrastructure to create a media pipeline you will not have
|
||||
to deal with buffers yourself; the elements will do that for you.
|
||||
</para>
|
||||
<para>
|
||||
The most important information in the buffer is:
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
A pointer to a piece of memory.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The size of the memory.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
A refcount that indicates how many elements are using this buffer. This refcount
|
||||
will be used to destroy the buffer when no element is having a reference to it.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
A list of metadata that describes the context of the buffers memory. In the case
|
||||
of audio data, for example, it would provide the samplerate, depth and channel
|
||||
count.
|
||||
</para>
|
||||
<para>
|
||||
GStreamer provides a registry where different metadata types can be registered
|
||||
so that everybody is talking about the same data.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
GStreamer provides functions to create custom buffer create/destroy algorithms, called
|
||||
a <classname>GstBufferPool</classname>. This makes it possible to efficiently
|
||||
allocate and destroy buffer memory. It also makes it possible to exchange memory between
|
||||
elements by passing the <classname>GstBufferPool</classname>. A video element can,
|
||||
for example, create a custom buffer allocation algorithm that creates buffers with XSHM
|
||||
as the buffer memory. An element can use this algorithm to create and fill the buffer
|
||||
with data.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The simple case is that a buffer is created, memory allocated, data put
|
||||
in it, and passed to the next filter. That filter reads the data, does
|
||||
something (like creating a new buffer and decoding into it), and
|
||||
unreferences the buffer. This causes the data to be freed and the buffer
|
||||
to be destroyed. A typical MPEG audio decoder works like this.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A more complex case is when the filter modifies the data in place. It
|
||||
does so and simply passes on the buffer to the next element. This is just
|
||||
as easy to deal with. An element that works in place has to be carefull when
|
||||
the buffer is used in more than one element; a copy on write has to made in this
|
||||
situation.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Before an element can operate on the buffers memory, is has to check the metadata
|
||||
attached to it (if any). An MPEG audio decoder has to ignore a buffer with video
|
||||
metadata (in which case the pipeline is probably constructed by connecting the
|
||||
wrong elements, anyway).
|
||||
</para>
|
||||
|
||||
</chapter>
|
||||
24
docs/manual/connections.sgml
Normal file
24
docs/manual/connections.sgml
Normal file
|
|
@ -0,0 +1,24 @@
|
|||
<chapter id="cha-connections">
|
||||
<title>Connecting elements</title>
|
||||
<para>
|
||||
You can connect the different pads of elements together so that the elements
|
||||
form a chain.
|
||||
</para>
|
||||
|
||||
<figure float="1" id="sec-connection">
|
||||
<title>Visualisation of three connected elements</title>
|
||||
<graphic fileref="images/connected-elements" format="png"></graphic>
|
||||
</figure>
|
||||
<para>
|
||||
By connecting these three elements, we have created a very simple pipeline. The effect
|
||||
of this will be that the output of the source element (element1) will be used as input
|
||||
for the filter element (element2). The filter element will do something with the data and
|
||||
send the result to the final sink element (element3).
|
||||
</para>
|
||||
<para>
|
||||
Imagine the above graph as a simple mpeg audio decoder. The source element is a
|
||||
disk source, the filter element is the mpeg decoder and the sink element is your
|
||||
audiocard. We will use this simple graph to construct an mpeg player later
|
||||
in this manual.
|
||||
</para>
|
||||
</chapter>
|
||||
95
docs/manual/elements.sgml
Normal file
95
docs/manual/elements.sgml
Normal file
|
|
@ -0,0 +1,95 @@
|
|||
<chapter id="cha-elements">
|
||||
<title>GstElement</title>
|
||||
<para>
|
||||
The most important object in GStreamer for the application programmer is
|
||||
the GstElement object.
|
||||
</para>
|
||||
|
||||
<sect1 id="sec-elements-design">
|
||||
<title>What is a GstElement</title>
|
||||
<para>
|
||||
The GstElement is the basic building block for the media pipeline. All the
|
||||
different components you are going to use are derived from this GstElement.
|
||||
This means that a lot of functions you are going to use operate on this object.
|
||||
</para>
|
||||
<para>
|
||||
We will first describe the three most important types of elements that you are
|
||||
going to use. They are the Source, Filter and Sink elements.
|
||||
</para>
|
||||
<para>
|
||||
You will also see that those elements have pads. These are the elements
|
||||
connections with the 'outside' world.
|
||||
</para>
|
||||
<sect2 id="sec-elements-src">
|
||||
<title>GStreamer source elements (<classname>GstSrc</classname>)</title>
|
||||
<para>
|
||||
This element will generate data that will be used by the pipeline. It is
|
||||
typically a file or an audio source.
|
||||
</para>
|
||||
<para>
|
||||
Below you see how we will visualize the <classname>GstSrc</classname> element.
|
||||
We always draw a src pad to the right of the element.
|
||||
</para>
|
||||
<figure float="1" id="sec-element-srcimg">
|
||||
<title>Visualisation of a <classname>GstSrc</classname> element</title>
|
||||
<graphic fileref="images/src-element" format="png"></graphic>
|
||||
</figure>
|
||||
<para>
|
||||
Source elements do not accept data, they only generate data. You can see
|
||||
this in the figure because it only has a src pad. A src pad can only
|
||||
generate buffers.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
<sect2 id="sec-elements-filter">
|
||||
<title>GStreamer filter elements (<classname>GstFilter</classname>)</title>
|
||||
<para>
|
||||
Filter elements both have an input and an output pad. They operate on data
|
||||
they receive in the sink pad and send the result to the src pad.
|
||||
</para>
|
||||
<para>
|
||||
Examples of a filter element might include: an MPEG decoder, volume filter,...
|
||||
</para>
|
||||
<para>
|
||||
Filters may also contain any number of input pads and output pads. For example,
|
||||
a video mixer might have to input pads (the images of the two different video
|
||||
streams) and one output pad.
|
||||
</para>
|
||||
<figure float="1" id="sec-element-filterimg">
|
||||
<title>Visualisation of a <classname>GstFilter</classname> element</title>
|
||||
<graphic fileref="images/filter-element" format="png"></graphic>
|
||||
</figure>
|
||||
<para>
|
||||
The above figure shows the visualisation of a filter element. This element has
|
||||
one sink pad (input) and one src (output) pad. Sink pads are drawn on the left
|
||||
of the element.
|
||||
</para>
|
||||
<figure float="1" id="sec-element-multifilterimg">
|
||||
<title>Visualisation of a <classname>GstFilter</classname> element with
|
||||
more than one output pad</title>
|
||||
<graphic fileref="images/filter-element-multi" format="png"></graphic>
|
||||
</figure>
|
||||
<para>
|
||||
The above figure shows the visualisation of a filter element with more than one
|
||||
output pad. An example of such a filter is the AVI splitter. This element will
|
||||
parse the input data and extracts the audio and video data. Most of these filters
|
||||
dynamically send out a signal when a new pad is created so that the application
|
||||
programmer can connect an arbitrary element to the newly created pad.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="sec-elements-sink">
|
||||
<title>GStreamer sink elements (<classname>GstSink</classname>)</title>
|
||||
<para>
|
||||
This element accepts data but will not generate any new data. A sink element
|
||||
is typically a file on disk, a soundcard, a display,... It is presented as
|
||||
below:
|
||||
</para>
|
||||
<figure float="1" id="sec-element-sinkimg">
|
||||
<title>Visualisation of a <classname>GstSink</classname> element</title>
|
||||
<graphic fileref="images/sink-element" format="png"></graphic>
|
||||
</figure>
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
2
docs/manual/fig/.gitignore
vendored
Normal file
2
docs/manual/fig/.gitignore
vendored
Normal file
|
|
@ -0,0 +1,2 @@
|
|||
*.bak
|
||||
.deps
|
||||
39
docs/manual/fig/bin-element.fig
Normal file
39
docs/manual/fig/bin-element.fig
Normal file
|
|
@ -0,0 +1,39 @@
|
|||
#FIG 3.2
|
||||
Landscape
|
||||
Center
|
||||
Inches
|
||||
Letter
|
||||
100.00
|
||||
Single
|
||||
-2
|
||||
1200 2
|
||||
2 2 0 1 0 6 50 0 20 0.000 0 0 -1 0 0 5
|
||||
3975 3600 4725 3600 4725 4125 3975 4125 3975 3600
|
||||
2 2 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 5
|
||||
2775 2775 4725 2775 4725 4425 2775 4425 2775 2775
|
||||
2 2 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 5
|
||||
5400 2775 7350 2775 7350 4425 5400 4425 5400 2775
|
||||
2 2 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 5
|
||||
8025 2775 9975 2775 9975 4425 8025 4425 8025 2775
|
||||
2 2 0 1 0 6 50 0 20 0.000 0 0 -1 0 0 5
|
||||
5400 3600 6150 3600 6150 4125 5400 4125 5400 3600
|
||||
2 2 0 1 0 6 50 0 20 0.000 0 0 -1 0 0 5
|
||||
8025 3600 8775 3600 8775 4125 8025 4125 8025 3600
|
||||
2 2 0 1 0 6 50 0 20 0.000 0 0 -1 0 0 5
|
||||
6600 3600 7350 3600 7350 4125 6600 4125 6600 3600
|
||||
2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
|
||||
1 1 1.00 90.00 120.00
|
||||
4575 3750 5400 3750
|
||||
2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
|
||||
1 1 1.00 90.00 120.00
|
||||
7200 3750 8025 3750
|
||||
2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5
|
||||
1950 1950 10575 1950 10575 4800 1950 4800 1950 1950
|
||||
4 0 0 50 0 16 12 0.0000 4 105 255 4200 3975 src\001
|
||||
4 0 0 50 0 16 12 0.0000 4 135 330 5550 3975 sink\001
|
||||
4 0 0 50 0 16 12 0.0000 4 135 330 8175 3975 sink\001
|
||||
4 0 0 50 0 16 12 0.0000 4 105 255 6825 3975 src\001
|
||||
4 0 0 50 0 16 12 0.0000 4 135 750 5625 3075 element2\001
|
||||
4 0 0 50 0 16 12 0.0000 4 135 750 8250 3075 element3\001
|
||||
4 0 0 50 0 16 12 0.0000 4 135 750 3000 3075 element1\001
|
||||
4 0 0 50 0 16 12 0.0000 4 135 255 2175 2250 bin\001
|
||||
36
docs/manual/fig/connected-elements.fig
Normal file
36
docs/manual/fig/connected-elements.fig
Normal file
|
|
@ -0,0 +1,36 @@
|
|||
#FIG 3.2
|
||||
Landscape
|
||||
Center
|
||||
Inches
|
||||
Letter
|
||||
100.00
|
||||
Single
|
||||
-2
|
||||
1200 2
|
||||
2 2 0 1 0 6 50 0 20 0.000 0 0 -1 0 0 5
|
||||
3975 3600 4725 3600 4725 4125 3975 4125 3975 3600
|
||||
2 2 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 5
|
||||
2775 2775 4725 2775 4725 4425 2775 4425 2775 2775
|
||||
2 2 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 5
|
||||
5400 2775 7350 2775 7350 4425 5400 4425 5400 2775
|
||||
2 2 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 5
|
||||
8025 2775 9975 2775 9975 4425 8025 4425 8025 2775
|
||||
2 2 0 1 0 6 50 0 20 0.000 0 0 -1 0 0 5
|
||||
5400 3600 6150 3600 6150 4125 5400 4125 5400 3600
|
||||
2 2 0 1 0 6 50 0 20 0.000 0 0 -1 0 0 5
|
||||
8025 3600 8775 3600 8775 4125 8025 4125 8025 3600
|
||||
2 2 0 1 0 6 50 0 20 0.000 0 0 -1 0 0 5
|
||||
6600 3600 7350 3600 7350 4125 6600 4125 6600 3600
|
||||
2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
|
||||
1 1 1.00 90.00 120.00
|
||||
4575 3750 5400 3750
|
||||
2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
|
||||
1 1 1.00 90.00 120.00
|
||||
7200 3750 8025 3750
|
||||
4 0 0 50 0 16 12 0.0000 4 105 255 4200 3975 src\001
|
||||
4 0 0 50 0 16 12 0.0000 4 135 330 5550 3975 sink\001
|
||||
4 0 0 50 0 16 12 0.0000 4 135 330 8175 3975 sink\001
|
||||
4 0 0 50 0 16 12 0.0000 4 105 255 6825 3975 src\001
|
||||
4 0 0 50 0 16 12 0.0000 4 135 750 5625 3075 element2\001
|
||||
4 0 0 50 0 16 12 0.0000 4 135 750 8250 3075 element3\001
|
||||
4 0 0 50 0 16 12 0.0000 4 135 750 3000 3075 element1\001
|
||||
21
docs/manual/fig/filter-element-multi.fig
Normal file
21
docs/manual/fig/filter-element-multi.fig
Normal file
|
|
@ -0,0 +1,21 @@
|
|||
#FIG 3.2
|
||||
Landscape
|
||||
Center
|
||||
Inches
|
||||
Letter
|
||||
100.00
|
||||
Single
|
||||
-2
|
||||
1200 2
|
||||
2 2 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 5
|
||||
5625 2775 7575 2775 7575 4425 5625 4425 5625 2775
|
||||
2 2 0 1 0 6 50 0 20 0.000 0 0 -1 0 0 5
|
||||
5625 3600 6375 3600 6375 4125 5625 4125 5625 3600
|
||||
2 2 0 1 0 6 50 0 20 0.000 0 0 -1 0 0 5
|
||||
6825 3225 7575 3225 7575 3750 6825 3750 6825 3225
|
||||
2 2 0 1 0 6 50 0 20 0.000 0 0 -1 0 0 5
|
||||
6825 3825 7575 3825 7575 4350 6825 4350 6825 3825
|
||||
4 0 0 50 0 16 12 0.0000 4 165 1200 5775 3150 element_name\001
|
||||
4 0 0 50 0 16 12 0.0000 4 135 330 5850 3975 sink\001
|
||||
4 0 0 50 0 16 12 0.0000 4 135 465 6975 3600 video\001
|
||||
4 0 0 50 0 16 12 0.0000 4 135 465 6975 4200 audio\001
|
||||
18
docs/manual/fig/filter-element.fig
Normal file
18
docs/manual/fig/filter-element.fig
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
#FIG 3.2
|
||||
Landscape
|
||||
Center
|
||||
Inches
|
||||
Letter
|
||||
100.00
|
||||
Single
|
||||
-2
|
||||
1200 2
|
||||
2 2 0 1 0 6 50 0 20 0.000 0 0 -1 0 0 5
|
||||
6825 3600 7575 3600 7575 4125 6825 4125 6825 3600
|
||||
2 2 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 5
|
||||
5625 2775 7575 2775 7575 4425 5625 4425 5625 2775
|
||||
2 2 0 1 0 6 50 0 20 0.000 0 0 -1 0 0 5
|
||||
5625 3600 6375 3600 6375 4125 5625 4125 5625 3600
|
||||
4 0 0 50 0 16 12 0.0000 4 105 255 7050 3975 src\001
|
||||
4 0 0 50 0 16 12 0.0000 4 165 1200 5775 3150 element_name\001
|
||||
4 0 0 50 0 16 12 0.0000 4 135 330 5850 3975 sink\001
|
||||
15
docs/manual/fig/sink-element.fig
Normal file
15
docs/manual/fig/sink-element.fig
Normal file
|
|
@ -0,0 +1,15 @@
|
|||
#FIG 3.2
|
||||
Landscape
|
||||
Center
|
||||
Inches
|
||||
Letter
|
||||
100.00
|
||||
Single
|
||||
-2
|
||||
1200 2
|
||||
2 2 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 5
|
||||
5625 2775 7575 2775 7575 4425 5625 4425 5625 2775
|
||||
2 2 0 1 0 6 50 0 20 0.000 0 0 -1 0 0 5
|
||||
5625 3600 6375 3600 6375 4125 5625 4125 5625 3600
|
||||
4 0 0 50 0 16 12 0.0000 4 165 1200 5775 3150 element_name\001
|
||||
4 0 0 50 0 16 12 0.0000 4 135 330 5850 3975 sink\001
|
||||
15
docs/manual/fig/src-element.fig
Normal file
15
docs/manual/fig/src-element.fig
Normal file
|
|
@ -0,0 +1,15 @@
|
|||
#FIG 3.2
|
||||
Landscape
|
||||
Center
|
||||
Inches
|
||||
Letter
|
||||
100.00
|
||||
Single
|
||||
-2
|
||||
1200 2
|
||||
2 2 0 1 0 6 50 0 20 0.000 0 0 -1 0 0 5
|
||||
6825 3600 7575 3600 7575 4125 6825 4125 6825 3600
|
||||
2 2 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 5
|
||||
5625 2775 7575 2775 7575 4425 5625 4425 5625 2775
|
||||
4 0 0 50 0 16 12 0.0000 4 105 255 7050 3975 src\001
|
||||
4 0 0 50 0 16 12 0.0000 4 165 1200 5775 3150 element_name\001
|
||||
46
docs/manual/fig/state-diagram.fig
Normal file
46
docs/manual/fig/state-diagram.fig
Normal file
|
|
@ -0,0 +1,46 @@
|
|||
#FIG 3.2
|
||||
Landscape
|
||||
Center
|
||||
Inches
|
||||
Letter
|
||||
100.00
|
||||
Single
|
||||
-2
|
||||
1200 2
|
||||
1 3 0 1 0 7 50 0 -1 0.000 1 0.0000 3600 1950 480 480 3600 1950 3975 2250
|
||||
1 3 0 1 0 7 50 0 -1 0.000 1 0.0000 3600 3150 480 480 3600 3150 3975 3450
|
||||
1 3 0 1 0 7 50 0 -1 0.000 1 0.0000 3600 4350 480 480 3600 4350 3975 4650
|
||||
1 3 0 1 0 7 50 0 -1 0.000 1 0.0000 4875 4350 480 480 4875 4350 5250 4650
|
||||
2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
|
||||
1 1 1.00 60.00 120.00
|
||||
3600 900 3600 1500
|
||||
2 2 0 1 7 7 50 0 -1 0.000 0 0 -1 0 0 5
|
||||
1350 750 5550 750 5550 5100 1350 5100 1350 750
|
||||
3 2 0 1 0 7 50 0 -1 0.000 0 1 0 3
|
||||
1 1 1.00 60.00 120.00
|
||||
3150 1875 2700 2400 3150 2925
|
||||
0.000 -1.000 0.000
|
||||
3 2 0 1 0 7 50 0 -1 0.000 0 1 0 3
|
||||
1 1 1.00 60.00 120.00
|
||||
3150 3150 2700 3675 3150 4200
|
||||
0.000 -1.000 0.000
|
||||
3 2 0 1 0 7 50 0 -1 0.000 0 1 0 3
|
||||
1 1 1.00 60.00 120.00
|
||||
3750 3900 4275 3675 4800 3900
|
||||
0.000 -1.000 0.000
|
||||
3 2 0 1 0 7 50 0 -1 0.000 0 1 0 3
|
||||
1 1 1.00 60.00 120.00
|
||||
4800 4800 4275 5025 3750 4800
|
||||
0.000 -1.000 0.000
|
||||
3 2 0 1 0 7 50 0 -1 0.000 0 1 0 3
|
||||
1 1 1.00 60.00 120.00
|
||||
5175 3975 5175 2475 4050 1725
|
||||
0.000 -1.000 0.000
|
||||
3 2 0 1 0 7 50 0 -1 0.000 0 1 0 3
|
||||
1 1 1.00 60.00 120.00
|
||||
3225 4650 1575 3300 3150 1725
|
||||
0.000 -1.000 0.000
|
||||
4 0 0 50 0 0 12 0.0000 4 135 480 3375 2025 NULL\001
|
||||
4 0 0 50 0 0 12 0.0000 4 135 645 3300 3225 READY\001
|
||||
4 0 0 50 0 0 12 0.0000 4 135 810 3225 4425 PLAYING\001
|
||||
4 0 0 50 0 0 12 0.0000 4 135 735 4500 4425 PAUSED\001
|
||||
109
docs/manual/goals.sgml
Normal file
109
docs/manual/goals.sgml
Normal file
|
|
@ -0,0 +1,109 @@
|
|||
<chapter id="cha-goals">
|
||||
<title>Goals</title>
|
||||
<para>
|
||||
GStreamer was designed to provide a solution to the current Linux media
|
||||
problems.
|
||||
</para>
|
||||
|
||||
<sect1 id="sec-goals-design">
|
||||
<title>The design goals</title>
|
||||
<para>
|
||||
We descibe what we try to achieve with GStreamer.
|
||||
</para>
|
||||
<sect2 id="sec-goals-clean">
|
||||
<title>Clean and powerfull</title>
|
||||
<para>
|
||||
GStreamer wants to provide a clean interface to:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
The application programmer who wants to build a media pipeline.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The plugin programmer.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
</sect2>
|
||||
<sect2 id="sec-goals-object">
|
||||
<title>Object oriented</title>
|
||||
<para>
|
||||
Adhere as much as possible to the GTK+ object model. A programmer familiar
|
||||
with GTK+ will be confortable with GStreamer.
|
||||
</para>
|
||||
<para>
|
||||
GStreamer uses the mechanisems of signals and object arguments.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="sec-goals-extensible">
|
||||
<title>Extensible</title>
|
||||
<para>
|
||||
All GStreamer Objects can be extended using the GTK+ inheritance methods.
|
||||
</para>
|
||||
<para>
|
||||
All plugins are loaded dynamically and can be extended and upgraded
|
||||
independently.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="sec-goals-binary">
|
||||
<title>Allow binary only plugins</title>
|
||||
<para>
|
||||
plugins are shared libraries that are loaded at runtime. since all the
|
||||
properties of the plugin can be set using the GtkObject arguments, there
|
||||
is no need to have any header files installed for the plugins.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="sec-goals-performance">
|
||||
<title>High performance</title>
|
||||
<para>
|
||||
High performance is obtained by:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Using glib g_mem_chunk where possible to minimize dynamic memory
|
||||
allocation.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Connections between plugins are extremely light-weight. Data can travel
|
||||
the pipeline with minimal overhead.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Provide a mechanism to directly work on the target memory. A
|
||||
plugin can for example directly write to the X servers shared mem.
|
||||
Buffers can also point to arbitrary memory like kernel memory.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Refcounting and copy on write to minimize the amount of memcpy.
|
||||
Subbufers to efficiently split the data in a buffer.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Pipelines can be constructed using cothreads to minimize the
|
||||
threading overhead. Cothreads are a simple user-space method for
|
||||
switching between subtasks.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
HW acceleration is possible by writing a specialized plugin.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
173
docs/manual/gstreamer-manual.sgml
Normal file
173
docs/manual/gstreamer-manual.sgml
Normal file
|
|
@ -0,0 +1,173 @@
|
|||
<!doctype book PUBLIC "-//GNOME//DTD DocBook PNG Variant V1.0//EN" [
|
||||
<!ENTITY INTRO SYSTEM "intro.sgml">
|
||||
<!ENTITY MOTIVATION SYSTEM "motivation.sgml">
|
||||
<!ENTITY GOALS SYSTEM "goals.sgml">
|
||||
|
||||
<!ENTITY ELEMENTS SYSTEM "elements.sgml">
|
||||
<!ENTITY CONNECTIONS SYSTEM "connections.sgml">
|
||||
<!ENTITY BINS SYSTEM "bins.sgml">
|
||||
<!ENTITY BUFFERS SYSTEM "buffers.sgml">
|
||||
<!ENTITY STATES SYSTEM "states.sgml">
|
||||
]>
|
||||
|
||||
|
||||
<book id="GStreamer">
|
||||
<bookinfo>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Wim</firstname>
|
||||
<surname>Taymans</surname>
|
||||
<authorblurb>
|
||||
<para>
|
||||
<email>wim.taymans@chello.be</email>
|
||||
</para>
|
||||
</authorblurb>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<edition>First Release</edition>
|
||||
<pubdate>2000</pubdate>
|
||||
<copyright>
|
||||
<year>2000</year>
|
||||
<holder>New Riders Publishing</holder>
|
||||
</copyright>
|
||||
|
||||
<legalnotice>
|
||||
<para>
|
||||
This material may be distributed only subject to the terms and
|
||||
conditions set forth in the Open Publication License, v1.0 or later (the
|
||||
latest version is presently available at <ulink url="
|
||||
http://www.opencontent.org/openpub/"
|
||||
type="http">http://www.opencontent.org/openpub/</ulink> )
|
||||
</para>
|
||||
</legalnotice>
|
||||
|
||||
<title>GStreamer Application Development Manual</title>
|
||||
|
||||
</bookinfo>
|
||||
|
||||
<!-- ############# Overview - part ############### -->
|
||||
|
||||
<part id="overview"><title>Overview</title>
|
||||
<partintro>
|
||||
<para>
|
||||
The first chapter of the book gives you an overview of GStreamer
|
||||
design goals. Chapter 2 rapidly covers the basics of GStreamer
|
||||
programming. In chapter 3 we will move on to the examples.
|
||||
Since GStreamer adheres to the GTK+ programming model, the reader is
|
||||
assumed to understand the basics of GTK+.
|
||||
For a gentle introduction to GTK+, you may wish to read the <emphasis>GTK+
|
||||
Tutorial</emphasis> or Eric Harlow's book <emphasis>Developing Linux
|
||||
Applications with GTK+ and GDK</emphasis>.
|
||||
</para>
|
||||
</partintro>
|
||||
|
||||
<!-- ############ Introduction - chapter ############# -->
|
||||
&INTRO;
|
||||
|
||||
&MOTIVATION;
|
||||
|
||||
&GOALS;
|
||||
</part>
|
||||
|
||||
<!-- ############ Basic concepts - part ############# -->
|
||||
|
||||
<part id="basic-concepts"><title>Basic concepts</title>
|
||||
<partintro>
|
||||
<para>
|
||||
We will first describe the basics of the GStreamer programming by
|
||||
introducing the different objects needed to create a media pipeline.
|
||||
</para>
|
||||
<para>
|
||||
We will use a visual representation of these objects so that we can
|
||||
visualize the more complex pipelines you will learn to build later on.
|
||||
</para>
|
||||
</partintro>
|
||||
|
||||
<!-- ############ Basic concepts - chapter ############# -->
|
||||
&ELEMENTS;
|
||||
|
||||
&CONNECTIONS;
|
||||
|
||||
&BINS;
|
||||
|
||||
&BUFFERS;
|
||||
|
||||
&STATES;
|
||||
</part>
|
||||
<!-- ############ Building Apps - part ############# -->
|
||||
|
||||
<part id="build-app"><title>Building an application</title>
|
||||
|
||||
<partintro>
|
||||
<para>
|
||||
With the basic concepts out of the way, you're ready to start building a
|
||||
full-scale GStreamer application. This part of the book walks you through the
|
||||
creation of a generic application skeleton: a source tree using
|
||||
<application>automake</application> and
|
||||
<application>autoconf</application>, argument parsing, session
|
||||
management, internationalization, the main window, dialogs, toolbars, and
|
||||
menubars. Many examples in Part 2 come from a simple application called
|
||||
"GnomeHello"; the source code for this application is included in the
|
||||
back of the book. </para> <para> Of course the "meat" of the application
|
||||
is up to you; but in Part 3 of the book we'll cover a range of library
|
||||
features you can use to develop it.
|
||||
</para>
|
||||
</partintro>
|
||||
|
||||
</part>
|
||||
|
||||
<!-- ############ Advanced GStreamer - part ############# -->
|
||||
|
||||
<part id="advanced"><title>Advanced GStreamer concepts</title>
|
||||
|
||||
<partintro>
|
||||
<para>
|
||||
Wanna know more?
|
||||
</para>
|
||||
</partintro>
|
||||
|
||||
</part>
|
||||
|
||||
<!-- ############ XML in GStreamer - part ############# -->
|
||||
|
||||
<part id="xml-gstreamer"><title>XML in GStreamer</title>
|
||||
|
||||
<partintro>
|
||||
<para>
|
||||
Just say how we use it...
|
||||
</para>
|
||||
</partintro>
|
||||
|
||||
</part>
|
||||
|
||||
<!-- ############ XML in GStreamer - part ############# -->
|
||||
|
||||
<part id="plugins"><title>plugin development in GStreamer</title>
|
||||
|
||||
<partintro>
|
||||
<para>
|
||||
A lot of text will follow...
|
||||
</para>
|
||||
</partintro>
|
||||
|
||||
</part>
|
||||
|
||||
<!-- ############ Appendices - part ############# -->
|
||||
|
||||
<part id="appendices">
|
||||
<title>Appendices</title>
|
||||
|
||||
<partintro>
|
||||
<para>
|
||||
</para>
|
||||
</partintro>
|
||||
</part>
|
||||
</book>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
35
docs/manual/intro.sgml
Normal file
35
docs/manual/intro.sgml
Normal file
|
|
@ -0,0 +1,35 @@
|
|||
<chapter id="cha-intro">
|
||||
<title>Introduction</title>
|
||||
<para>
|
||||
This chapter gives you an overview of the technologies described in this
|
||||
book.
|
||||
</para>
|
||||
|
||||
<sect1 id="sec-intro-what">
|
||||
<title>What is GStreamer?</title>
|
||||
<para>
|
||||
GStreamer is a framework for creating streaming media applications.
|
||||
The fundamental design comes from the video pipeline at Oregon Graduate
|
||||
Institute, as well as some ideas from DirectShow.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
GStreamer's development framework makes it possible to write any
|
||||
streaming multimedia application. The framework includes several
|
||||
components to build a full featured media player capable of playing
|
||||
MPEG1, MPEG2, AVI, MP3, WAV, AU, ...
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The framework is based on plug-ins that will provide the various codec
|
||||
and other functionality. The plugins can be connected and arranged in
|
||||
a pipeline. This pipeline defines the flow of the data.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This book is about GStreamer from a developer's point of view; it describes
|
||||
how to write a GStreamer application using the GStreamer libraries and tools.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
86
docs/manual/motivation.sgml
Normal file
86
docs/manual/motivation.sgml
Normal file
|
|
@ -0,0 +1,86 @@
|
|||
<chapter id="cha-motivation">
|
||||
<title>Motivation</title>
|
||||
<para>
|
||||
Linux has historically lagged behind other operating systems in the multimedia
|
||||
arena. Microsoft's Windows[tm] and Apple's MacOS[tm] both have strong support
|
||||
for multimedia devices, multimedia content creation,
|
||||
playback, and realtime processing. Linux, on the other hand, has a poorly integrated
|
||||
collection of multimedia utilities and applications available, which can hardly compete
|
||||
with the professional level of software available for MS Windows and MacOS.
|
||||
</para>
|
||||
|
||||
<sect1 id="sec-motivation-problems">
|
||||
<title>Current problems</title>
|
||||
<para>
|
||||
We descibe the typical problems in todays media handling on Linux.
|
||||
</para>
|
||||
<sect2 id="sec-motivation-duplicate">
|
||||
<title>Multitude of duplicate code</title>
|
||||
<para>
|
||||
The Linux user who wishes to hear a sound file must hunt through their collection of
|
||||
sound file players in order to play the tens of sound file formats in wide use today.
|
||||
Most of these players basically reimplement the same code over and over again.
|
||||
</para>
|
||||
<para>
|
||||
The Linux developer who wishes to embed a video clip in their application must use
|
||||
crude hacks to run an external video player. There is no library available that a
|
||||
developer can use to create a custom media player.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
<sect2 id="sec-motivation-goal">
|
||||
<title>'One goal' media players</title>
|
||||
<para>
|
||||
Your typical MPEG player was designed to play MPEG video and audio. Most of
|
||||
these players have implemented a complete infrastructure focused on
|
||||
achieving their only goal: playback. No provisions were made to add
|
||||
filters or special effects to the video or audio data.
|
||||
</para>
|
||||
<para>
|
||||
If I wanted to convert an MPEG2 video stream into an AVI file, my best
|
||||
option would be to take all of the MPEG2 decoding algorithms out
|
||||
of the player and duplicate them into my own AVI encoder. These
|
||||
algorithms cannot easily be shared accross applications.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="sec-motivation-plugin">
|
||||
<title>Non unified plugin mechanisms</title>
|
||||
<para>
|
||||
Your typical media player might have a plugin for different media
|
||||
types. Two media players will typically implement their own plugin
|
||||
mechanism so that the codecs cannot be easily exchanged.
|
||||
</para>
|
||||
<para>
|
||||
The lack of a unified plugin mechanism also seriously hinders the
|
||||
creation of binary only codecs. No company is willing to port their
|
||||
code to all the different plugin mechanisms.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="sec-motivation-network">
|
||||
<title>Provision for network transparency</title>
|
||||
<para>
|
||||
No infrastructure is present to allow network transparent media
|
||||
handling. A distributed MPEG encoder will typically duplicate the
|
||||
same encoder algorithms found in a non-distributed encoder.
|
||||
</para>
|
||||
<para>
|
||||
No provisions have been made for emerging technologies such as
|
||||
the GNOME object embedding using BONOBO.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="sec-motivation-catchup">
|
||||
<title>Catch up with the Windows(tm) world</title>
|
||||
<para>
|
||||
We need solid media handling if we want to see Linux succeed on
|
||||
the desktop.
|
||||
</para>
|
||||
<para>
|
||||
We must clear the road for commercially backed codecs and multimedia
|
||||
applications so that Linux can become an option for doing multimedia.
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
81
docs/manual/outline.txt
Normal file
81
docs/manual/outline.txt
Normal file
|
|
@ -0,0 +1,81 @@
|
|||
Overview
|
||||
Introduction
|
||||
(creating multimedia apps)
|
||||
(pipeline/plugin based)
|
||||
|
||||
Motivation
|
||||
(multitude of duplicate code)
|
||||
(mostly focused on one goal)
|
||||
(reinvent plugin mechanisms)
|
||||
(network transparency?)
|
||||
(catch up with Windows(tm) world)
|
||||
|
||||
Goals
|
||||
(clean and powerfull)
|
||||
(building graphs)
|
||||
(building plugins)
|
||||
(object oriented)
|
||||
(using GTK+ object model)
|
||||
(extensible)
|
||||
(alow binary only plugins)
|
||||
(alow high performance)
|
||||
(HW acceleration)
|
||||
(efficient memory use)
|
||||
(kernel buffers etc..)
|
||||
|
||||
Basic concepts
|
||||
elements
|
||||
(what is it)
|
||||
(types) sink, src, filter
|
||||
(have pads)
|
||||
connecting elements
|
||||
bin
|
||||
(can contain elements)
|
||||
pipeline
|
||||
(a complete graph)
|
||||
buffers
|
||||
(pass between elements)
|
||||
(contains data)
|
||||
(can cary metadata)
|
||||
(use refcounting)
|
||||
element states
|
||||
(null)
|
||||
(ready)
|
||||
(paused)
|
||||
(playing)
|
||||
|
||||
Building apps
|
||||
helloworld
|
||||
(fdsrc->mp3decoder->audiosink)
|
||||
(step by step explanation)
|
||||
|
||||
advanced concepts
|
||||
threads
|
||||
queues
|
||||
cothreads
|
||||
dynamic pipeline construction
|
||||
ghost pads
|
||||
types
|
||||
type detection
|
||||
plugin registry
|
||||
bufferpools
|
||||
Quality of service
|
||||
utility functions
|
||||
|
||||
|
||||
XML in GStreamer
|
||||
(saving)
|
||||
(loading a pipeline)
|
||||
|
||||
Plugin development
|
||||
buffers
|
||||
metadata
|
||||
subbufers
|
||||
adding pads
|
||||
libraries
|
||||
|
||||
GStreamer programs
|
||||
editor
|
||||
gstplay
|
||||
|
||||
|
||||
104
docs/manual/states.sgml
Normal file
104
docs/manual/states.sgml
Normal file
|
|
@ -0,0 +1,104 @@
|
|||
<chapter id="cha-states">
|
||||
<title>Element states</title>
|
||||
<para>
|
||||
One you have created a pipeline packed with elements, nothing will happen yet.
|
||||
This is where the different states come into play.
|
||||
</para>
|
||||
|
||||
<sect1 id="sec-states">
|
||||
<title>The different element states</title>
|
||||
<para>
|
||||
All elements can be in one of the following four states:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
NULL: this is the default state all elements are in when they are created
|
||||
and are doing nothing.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
READY: An element is ready to start doing something.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
PLAYING: The element is doing something.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
PAUSED: The element is paused for a period of time.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
All elements start with the NULL state. The elements will go throught the following state changes:
|
||||
<figure float="1" id="sec-state-img">
|
||||
<title>The different states of a <classname>GstElement</classname> and the state transitions</title>
|
||||
<graphic fileref="images/state-diagram" format="png"></graphic>
|
||||
</figure>
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="sec-states-null">
|
||||
<title>The NULL state</title>
|
||||
<para>
|
||||
When you created the pipeline all of the elements will be in the NULL state. There is
|
||||
nothing spectacular about the NULL state.
|
||||
</para>
|
||||
<note>
|
||||
<para>
|
||||
Don't forget to reset the pipeline to the NULL state when you are not going to use it
|
||||
anymore. This will allow the elements to free the resources they might use.
|
||||
</para>
|
||||
</note>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="sec-states-ready">
|
||||
<title>The READY state</title>
|
||||
<para>
|
||||
You will start the pipeline by first setting it to the READY state. This will allow the
|
||||
pipeline and all the elements contained in it to prepare themselves for the actions
|
||||
they are about to perform.
|
||||
</para>
|
||||
<para>
|
||||
The typical actions that an element will perform in the READY state might be to open a file or
|
||||
an audio device. Some more complex elements might have a non trivial action to perform in
|
||||
the READY state such as connecting to a media server using a CORBA connection.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="sec-states-playing">
|
||||
<title>The PLAYING state</title>
|
||||
<para>
|
||||
A Pipeline that is in the READY state can be started by setting it to the PLAYING state. At
|
||||
that time data will start to flow all the way through the pipeline.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="sec-states-paused">
|
||||
<title>The PAUSED state</title>
|
||||
<para>
|
||||
A pipeline that is playing can be set to the PAUSED state. This will temporarily stop all
|
||||
data flowing through the pipeline.
|
||||
</para>
|
||||
<para>
|
||||
You can resume the data flow by setting the pipeline back to the PLAYING state.
|
||||
</para>
|
||||
<note>
|
||||
<para>
|
||||
The PAUSED state is build for temporarily freezing the pipeline. Elements will typically
|
||||
do not free their resources in the PAUSED state. Use the NULL state if you want to stop
|
||||
the data flow permanantly.
|
||||
</para>
|
||||
</note>
|
||||
<para>
|
||||
The pipeline has to be in the PAUSED or NULL state if you want to insert or modify an element
|
||||
in the pipeline. We will cover dynamic pipeline behaviour in ... <!-- fixme -->
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
</chapter>
|
||||
Loading…
Reference in a new issue