mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-10-06 10:42:22 +00:00
118 lines
4.7 KiB
XML
118 lines
4.7 KiB
XML
<chapter id="chapter-elements">
|
|
<title>Elements</title>
|
|
<para>
|
|
The most important object in <application>GStreamer</application> for the
|
|
application programmer is the <classname>GstElement</classname> object.
|
|
</para>
|
|
|
|
<sect1 id="section-elements-design">
|
|
<title>What is an element ?</title>
|
|
<para>
|
|
An element is the basic building block for the media pipeline.
|
|
All the different high-level components you are going to use are
|
|
derived from <classname>GstElement</classname>. This means that a
|
|
lot of functions you are going to use operate on objects of this class.
|
|
</para>
|
|
<para>
|
|
Elements, from the perspective of GStreamer, are viewed as "black boxes"
|
|
with a number of different aspects. One of these aspects is the presence
|
|
of "pads" (see <xref linkend="chapter-pads"/>), or link points. This terminology arises from soldering;
|
|
pads are where wires can be attached.
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1 id="section-elements-types">
|
|
<title>Types of elements</title>
|
|
|
|
<sect2 id="section-elements-src">
|
|
<title>Source elements</title>
|
|
<para>
|
|
Source elements generate data for use by a pipeline, for example
|
|
reading from disk or from a sound card.
|
|
</para>
|
|
<para>
|
|
<xref linkend="section-element-srcimg"/> shows how we will visualise
|
|
a source element.
|
|
We always draw a source pad to the right of the element.
|
|
</para>
|
|
<figure float="1" id="section-element-srcimg">
|
|
<title>Visualisation of a source element</title>
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="images/src-element.ℑ" format="&IMAGE;" />
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
<para>
|
|
Source elements do not accept data, they only generate data. You can
|
|
see this in the figure because it only has a source pad. A source
|
|
pad can only generate data.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="section-elements-filter">
|
|
<title>Filters and codecs</title>
|
|
<para>
|
|
Filter elements have both input and output pads. They operate on
|
|
data they receive in their sink pads and produce data on their source
|
|
pads. For example, MPEG decoders and volume filters would fall into
|
|
this category.
|
|
</para>
|
|
<para>
|
|
Elements are not constrained as to the number of pads they might have;
|
|
for example, a video mixer might have two input pads (the images of
|
|
the two different video streams) and one output pad.
|
|
</para>
|
|
<figure float="1" id="section-element-filterimg">
|
|
<title>Visualisation of a filter element</title>
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="images/filter-element.ℑ" format="&IMAGE;" />
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
<para>
|
|
<xref linkend="section-element-filterimg"/> shows how we will visualise
|
|
a filter element.
|
|
This element has one sink (input) pad and one source (output) pad.
|
|
Sink pads are drawn on the left of the element.
|
|
</para>
|
|
<figure float="1" id="section-element-multifilterimg">
|
|
<title>Visualisation of a filter element with
|
|
more than one output pad</title>
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="images/filter-element-multi.ℑ"
|
|
format="&IMAGE;" />
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
<para>
|
|
<xref linkend="section-element-filterimg"/> shows the visualisation of a filter element with
|
|
more than one output pad. An example of such a filter is the AVI
|
|
demultiplexer. This element will parse the input data and
|
|
extract 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 link an arbitrary element to the newly created pad.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="section-elements-sink">
|
|
<title>Sink elements</title>
|
|
<para>
|
|
Sink elements are end points in a media pipeline. They accept
|
|
data but do not produce anything. Disk writing, soundcard playback,
|
|
and video output would all be implemented by sink elements.
|
|
<xref linkend="section-element-sinkimg"/> shows a sink element.
|
|
</para>
|
|
<figure float="1" id="section-element-sinkimg">
|
|
<title>Visualisation of a sink element</title>
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="images/sink-element.ℑ" format="&IMAGE;" />
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
</sect2>
|
|
</sect1>
|
|
</chapter>
|