gstreamer/docs/manual/goals.xml
Andy Wingo d2c3b2087d conversion to docbook-xml. i don't have to ask that this be testing, because not ionly is it perfect, but i'm sure yo...
Original commit message from CVS:
conversion to docbook-xml. i don't have to ask that this be testing, because
not ionly is it perfect, but i'm sure you folks will learn that on your own :-)
2001-12-15 23:13:04 +00:00

131 lines
4 KiB
XML

<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.
The programmer can use an extensive set of powerfull tools to create
media pipelines without writing a single line of code. Performing
complex media manipulations becomes very easy.
</para>
</listitem>
<listitem>
<para>
The plugin programmer. Plugin programmers are provided a clean and
simple API to create self contained plugins. An extensive debugging
and tracing mechanism has been integrated. GStreamer also comes with
an extensive set of real-life plugins that serve as an example too.
</para>
</listitem>
</itemizedlist>
</sect2>
<sect2 id="sec-goals-object">
<title>Object oriented</title>
<para>
Adhere as much as possible to the glib2.0 object model. A programmer familiar
with glib2 and GTK+ will be confortable with GStreamer.
</para>
<para>
GStreamer uses the mechanism of signals and object arguments.
</para>
<para>
All objects can be queried at runtime for their various properties and
capabilities.
</para>
</sect2>
<sect2 id="sec-goals-extensible">
<title>Extensible</title>
<para>
All GStreamer Objects can be extended using the glib2 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 GObject properties, there
is no need to have any header files installed for the plugins.
</para>
<para>
Special care has been taking into making the plugin completely self
contained. This is in the operations, specification of the capabilities
of the plugin and properties.
</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>
<listitem>
<para>
Uses a plugin registry with the specifications of the plugins so
that the plugin loading can be delayed until the plugin is actually
used.
</para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
</chapter>