gstreamer/docs/manual/intro-basics.xml
Stefan Kost 523041b533 docs/: describe dparams (controller) for plugins unify docs a little more
Original commit message from CVS:
* docs/README:
* docs/manual/intro-basics.xml:
* docs/manual/intro-preface.xml:
* docs/manual/manual.xml:
* docs/pwg/advanced-dparams.xml:
* docs/pwg/intro-basics.xml:
* docs/pwg/intro-preface.xml:
* docs/pwg/pwg.xml:
describe dparams (controller) for plugins
unify docs a little more
2006-02-02 11:24:19 +00:00

87 lines
4.4 KiB
XML

<chapter id="chapter-intro-basics">
<title>Foundations</title>
<para><!-- synchronize with PWG -->
This chapter of the guide introduces the basic concepts of &GStreamer;.
Understanding these concepts will be important in reading any of the
rest of this guide, all of them assume understanding of these basic
concepts.
</para>
<sect1 id="section-intro-basics-elements">
<title>Elements</title>
<para>
An <emphasis>element</emphasis> is the most important class of objects
in &GStreamer;. You will usually create a chain of elements linked
together and let data flow through this chain of elements. An element
has one specific function, which can be the reading of data from a
file, decoding of this data or outputting this data to your sound
card (or anything else). By chaining together several such elements,
you create a <emphasis>pipeline</emphasis> that can do a specific task,
for example media playback or capture. &GStreamer; ships with a large
collection of elements by default, making the development of a large
variety of media applications possible. If needed, you can also write
new elements. That topic is explained in great deal in the &GstPWG;.
</para>
</sect1>
<sect1 id="section-intro-basics-bins">
<title>Bins and pipelines</title>
<para>
A <emphasis>bin</emphasis> is a container for a collection of elements.
A pipeline is a special subtype of a bin that allows execution of all
of its contained child elements. Since bins are subclasses of elements
themselves, you can mostly control a bin as if it where an element,
thereby abstracting away a lot of complexity for your application. You
can, for example change state on all elements in a bin by changing the
state of that bin itself. Bins also forward bus messages from their
contained children (such as error messages, tag messages or EOS messages).
</para>
<para>
A pipeline is a top-level bin. As you set it to PAUSED or PLAYING state,
data flow will start and media processing will take place. Once started,
pipelines will run in a separate thread until you stop them or the end
of the data stream is reached.
</para>
</sect1>
<sect1 id="section-intro-basics-pads">
<title>Pads</title>
<para>
<emphasis>Pads</emphasis> are used to negotiate links and data flow
between elements in &GStreamer;. A pad can be viewed as a
<quote>plug</quote> or <quote>port</quote> on an element where
links may be made with other elements, and through which data can
flow to or from those elements. Pads have specific data handling
capabilities: A pad can restrict the type of data that flows
through it. Links are only allowed between two pads when the
allowed data types of the two pads are compatible. Data types are
negotiated between pads using a process called <emphasis>caps
negotiation</emphasis>. Data types are described as a
<classname>GstCaps</classname>.
</para>
<para>
An analogy may be helpful here. A pad is similar to a plug or jack on a
physical device. Consider, for example, a home theater system consisting
of an amplifier, a DVD player, and a (silent) video projector. Linking
the DVD player to the amplifier is allowed because both devices have audio
jacks, and linking the projector to the DVD player is allowed because
both devices have compatible video jacks. Links between the
projector and the amplifier may not be made because the projector and
amplifier have different types of jacks. Pads in &GStreamer; serve the
same purpose as the jacks in the home theater system.
</para>
<para>
For the most part, all data in &GStreamer; flows one way through a link
between elements. Data flows out of one element through one or more
<emphasis>source pads</emphasis>, and elements accept incoming data
through one or more <emphasis>sink pads</emphasis>. Source and sink
elements have only source and sink pads, respectively. Data usually
means buffers (described by the <ulink type="http"
url="&URLAPI;/gstreamer-GstBuffer.html"><classname>GstBuffer
</classname></ulink> object) and events (described by the <ulink
type="http" url="&URLAPI;/gstreamer-GstEvent.html"><classname>
GstEvent</classname></ulink> object).
</para>
</sect1>
</chapter>