mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-14 13:21:28 +00:00
0734eb921c
Original commit message from CVS: * docs/README: * docs/images/gdp-header.svg: add a gdp image * docs/libs/Makefile.am: * docs/libs/gdp-header.png: * libs/gst/dataprotocol/dataprotocol.c: add it to the API docs * docs/manual/intro-motivation.xml: fix typo
304 lines
12 KiB
XML
304 lines
12 KiB
XML
<chapter id="chapter-motivation">
|
|
<title>Motivation & Goals</title>
|
|
<para>
|
|
Linux has historically lagged behind other operating systems in the
|
|
multimedia arena. Microsoft's <trademark>Windows</trademark> and
|
|
Apple's <trademark>MacOS</trademark> 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>
|
|
<para>
|
|
GStreamer was designed to provide a solution to the current Linux media
|
|
problems.
|
|
</para>
|
|
|
|
<sect1 id="section-motivation-problems">
|
|
<title>Current problems</title>
|
|
<para>
|
|
We describe the typical problems in today's media handling on Linux.
|
|
</para>
|
|
<sect2 id="section-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="section-motivation-goal">
|
|
<title>'One goal' media players/libraries</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 you want to convert an MPEG-2 video stream into an AVI file,
|
|
your best option would be to take all of the MPEG-2 decoding
|
|
algorithms out of the player and duplicate them into your own
|
|
AVI encoder. These algorithms cannot easily be shared across
|
|
applications.
|
|
</para>
|
|
<para>
|
|
Attempts have been made to create libraries for handling various
|
|
media types. Because they focus on a very specific media type
|
|
(avifile, libmpeg2, ...), significant work is needed to integrate
|
|
them due to a lack of a common API. &GStreamer; allows you to
|
|
wrap these libraries with a common API, which significantly
|
|
simplifies integration and reuse.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="section-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. The plugin
|
|
system of the typical media player is also very tailored to the
|
|
specific needs of the application.
|
|
</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>
|
|
<para>
|
|
While &GStreamer; also uses it own plugin system it offers a very rich
|
|
framework for the plugin developer and ensures the plugin can be used
|
|
in a wide range of applications, transparently interacting with other
|
|
plugins. The framework that &GStreamer; provides for the plugins is
|
|
flexible enough to host even the most demanding plugins.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="section-motivation-experience">
|
|
<title>Poor user experience</title>
|
|
<para>
|
|
Because of the problems mentioned above, application authors have
|
|
so far often been urged to spend a considerable amount of time in
|
|
writing their own backends, plugin mechanisms and so on. The result
|
|
has often been, unfortunately, that both the backend as well as the
|
|
user interface were only half-finished. Demotivated, the application
|
|
authors would start rewriting the whole thing and complete the circle.
|
|
This leads to a <emphasis>poor end user experience</emphasis>.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="section-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 use by and use of technologies such
|
|
as the <ulink url="http://gnome.org/" type="http">GNOME</ulink>
|
|
desktop platform. Because the wheel is re-invented all the time,
|
|
it's hard to properly integrate multimedia into the bigger whole of
|
|
user's environment.
|
|
</para>
|
|
<para>
|
|
The &GStreamer; core does not use network transparent technologies
|
|
at the lowest level as it only adds overhead for the local case.
|
|
That said, it shouldn't be hard to create a wrapper around the
|
|
core components. There are tcp plugins now that implement a
|
|
&GStreamer; Data Protocol that allows pipelines to be split over
|
|
TCP. These are located in the gst-plugins module directory gst/tcp.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="section-motivation-catchup">
|
|
<title>Catch up with the <trademark>Windows</trademark> 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>
|
|
|
|
<sect1 id="section-goals-design">
|
|
<title>The design goals</title>
|
|
<para>
|
|
We describe what we try to achieve with &GStreamer;.
|
|
</para>
|
|
<sect2 id="section-goals-clean">
|
|
<title>Clean and powerful</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 powerful 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 examples too.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
</sect2>
|
|
<sect2 id="section-goals-object">
|
|
<title>Object oriented</title>
|
|
<para>
|
|
&GStreamer; adheres to the GLib 2.0 object model. A programmer
|
|
familiar with GLib 2.0 or older versions of GTK+ will be
|
|
comfortable with &GStreamer;.
|
|
</para>
|
|
<para>
|
|
&GStreamer; uses the mechanism of signals and object properties.
|
|
</para>
|
|
<para>
|
|
All objects can be queried at runtime for their various properties and
|
|
capabilities.
|
|
</para>
|
|
<para>
|
|
&GStreamer; intends to be similar in programming methodology to GTK+.
|
|
This applies to the object model, ownership of objects, reference
|
|
counting, ...
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="section-goals-extensible">
|
|
<title>Extensible</title>
|
|
<para>
|
|
All &GStreamer; Objects can be extended using the GObject
|
|
inheritance methods.
|
|
</para>
|
|
<para>
|
|
All plugins are loaded dynamically and can be extended and upgraded
|
|
independently.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="section-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 (and in fact no way) to have any header files
|
|
installed for the plugins.
|
|
</para>
|
|
<para>
|
|
Special care has been taken to make plugins completely self-contained.
|
|
All relevant aspects of plugins can be queried at run-time.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="section-goals-performance">
|
|
<title>High performance</title>
|
|
<para>
|
|
High performance is obtained by:
|
|
</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
using GLib's <function>g_mem_chunk</function> and fast
|
|
non-blocking allocation algorithms where possible to
|
|
minimize dynamic memory allocation.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
extremely light-weight links between plugins. Data can travel
|
|
the pipeline with minimal overhead. Data passing between
|
|
plugins only involves a pointer dereference in a typical
|
|
pipeline.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
providing a mechanism to directly work on the target memory.
|
|
A plugin can for example directly write to the X server's
|
|
shared memory space. Buffers can also point to arbitrary
|
|
memory, such as a sound card's internal hardware buffer.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
refcounting and copy on write minimize usage of memcpy.
|
|
Sub-buffers efficiently split buffers into manageable pieces.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
the use of cothreads to minimize the threading overhead.
|
|
Cothreads are a simple and fast user-space method for
|
|
switching between subtasks. Cothreads were measured to
|
|
consume as little as 600 cpu cycles.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
allowing hardware acceleration by using specialized plugins.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
using 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>
|
|
<listitem>
|
|
<para>
|
|
all critical data passing is free of locks and mutexes.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect2>
|
|
|
|
<sect2 id="section-goals-separation">
|
|
<title>Clean core/plugins separation</title>
|
|
<para>
|
|
The core of &GStreamer; is essentially media-agnostic. It only knows
|
|
about bytes and blocks, and only contains basic elements.
|
|
The core of &GStreamer; is functional enough to even implement
|
|
low-level system tools, like cp.
|
|
</para>
|
|
<para>
|
|
All of the media handling functionality is provided by plugins
|
|
external to the core. These tell the core how to handle specific
|
|
types of media.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="section-goals-testbed">
|
|
<title>Provide a framework for codec experimentation</title>
|
|
<para>
|
|
&GStreamer; also wants to be an easy framework where codec
|
|
developers can experiment with different algorithms, speeding up
|
|
the development of open and free multimedia codecs like <ulink
|
|
url="http://www.xiph.org/ogg/index.html" type="http">Theora and
|
|
Vorbis</ulink>.
|
|
</para>
|
|
</sect2>
|
|
|
|
</sect1>
|
|
</chapter>
|