docs/manual/intro-motivation.xml

   1 <chapter id="chapter-motivation">
   2   <title>Motivation &amp; Goals</title>
   3   <para>
   4     Linux has historically lagged behind other operating systems in the
   5     multimedia arena. Microsoft's <trademark>Windows</trademark> and
   6     Apple's <trademark>MacOS</trademark> both have strong support for
   7     multimedia devices, multimedia content creation, playback, and
   8     realtime processing. Linux, on the other hand, has a poorly integrated
   9     collection of multimedia utilities and applications available, which
  10     can hardly compete with the professional level of software available
  11     for MS Windows and MacOS.
  12   </para>
  13   <para>
  14     GStreamer was designed to provide a solution to the current Linux media
  15     problems.
  16   </para>
  17
  18   <sect1 id="section-motivation-problems">
  19     <title>Current problems</title>
  20     <para>
  21       We describe the typical problems in today's media handling on Linux.
  22     </para>
  23     <sect2 id="section-motivation-duplicate">
  24       <title>Multitude of duplicate code</title>
  25       <para>
  26         The Linux user who wishes to hear a sound file must hunt through
  27         their collection of sound file players in order to play the tens
  28         of sound file formats in wide use today. Most of these players
  29         basically reimplement the same code over and over again.
  30       </para>
  31       <para>
  32         The Linux developer who wishes to embed a video clip in their
  33         application must use crude hacks to run an external video player.
  34         There is no library available that a developer can use to create
  35         a custom media player.
  36       </para>
  37     </sect2>
  38
  39     <sect2 id="section-motivation-goal">
  40       <title>'One goal' media players/libraries</title>
  41       <para>
  42         Your typical MPEG player was designed to play MPEG video and audio.
  43         Most of these players have implemented a complete infrastructure
  44         focused on achieving their only goal: playback. No provisions were
  45         made to add filters or special effects to the video or audio data.
  46       </para>
  47       <para>
  48         If you want to convert an MPEG-2 video stream into an AVI file,
  49         your best option would be to take all of the MPEG-2 decoding
  50         algorithms out of the player and duplicate them into your own
  51         AVI encoder. These algorithms cannot easily be shared across
  52         applications.
  53       </para>
  54       <para>
  55         Attempts have been made to create libraries for handling various
  56         media types. Because they focus on a very specific media type
  57         (avifile, libmpeg2, ...), significant work is needed to integrate
  58         them due to a lack of a common API. &GStreamer; allows you to
  59         wrap these libraries with a common API, which significantly
  60         simplifies integration and reuse.
  61       </para>
  62     </sect2>
  63
  64     <sect2 id="section-motivation-plugin">
  65       <title>Non unified plugin mechanisms</title>
  66       <para>
  67         Your typical media player might have a plugin for different media
  68         types. Two media players will typically implement their own plugin
  69         mechanism so that the codecs cannot be easily exchanged. The plugin
  70         system of the typical media player is also very tailored to the
  71         specific needs of the application.
  72       </para>
  73       <para>
  74         The lack of a unified plugin mechanism also seriously hinders the
  75         creation of binary only codecs. No company is willing to port their
  76         code to all the different plugin mechanisms.
  77       </para>
  78       <para>
  79         While &GStreamer; also uses it own plugin system it offers a very rich
  80         framework for the plugin developper and ensures the plugin can be used
  81         in a wide range of applications, transparently interacting with other
  82         plugins. The framework that &GStreamer; provides for the plugins is
  83         flexible enough to host even the most demanding plugins.
  84       </para>
  85     </sect2>
  86
  87     <sect2 id="section-motivation-experience">
  88       <title>Poor user experience</title>
  89       <para>
  90         Because of the problems mentioned above, application authors have
  91         so far often been urged to spend a considerable amount of time in
  92         writing their own backends, plugin mechanisms and so on. The result
  93         has often been, unfortunately, that both the backend as well as the
  94         user interface were only half-finished. Demotivated, the application
  95         authors would start rewriting the whole thing and complete the circle.
  96         This leads to a <emphasis>poor end user experience</emphasis>.
  97       </para>
  98     </sect2>
  99
 100     <sect2 id="section-motivation-network">
 101       <title>Provision for network transparency</title>
 102       <para>
 103         No infrastructure is present to allow network transparent media
 104         handling. A distributed MPEG encoder will typically duplicate the
 105         same encoder algorithms found in a non-distributed encoder.
 106       </para>
 107       <para>
 108         No provisions have been made for technologies such as
 109         the <ulink url="http://developer.gnome.org/arch/component/bonobo.html"
 110         type="http">GNOME object embedding using Bonobo</ulink>.
 111       </para>
 112       <para>
 113         The &GStreamer; core does not use network transparent technologies
 114         at the lowest level as it only adds overhead for the local case.
 115         That said, it shouldn't be hard to create a wrapper around the
 116         core components. There are tcp plugins now that implement a
 117         &GStreamer; Data Protocol that allows pipelines to be slit over
 118         TCP. These are located in the gst-plugins module directory gst/tcp.
 119       </para>
 120     </sect2>
 121
 122     <sect2 id="section-motivation-catchup">
 123       <title>Catch up with the <trademark>Windows</trademark> world</title>
 124       <para>
 125         We need solid media handling if we want to see Linux succeed on
 126         the desktop.
 127       </para>
 128       <para>
 129         We must clear the road for commercially backed codecs and multimedia
 130         applications so that Linux can become an option for doing multimedia.
 131       </para>
 132     </sect2>
 133   </sect1>
 134
 135   <sect1 id="section-goals-design">
 136     <title>The design goals</title>
 137     <para>
 138       We describe what we try to achieve with &GStreamer;.
 139     </para>
 140     <sect2 id="section-goals-clean">
 141       <title>Clean and powerful</title>
 142       <para>
 143         &GStreamer; wants to provide a clean interface to:
 144       </para>
 145       <itemizedlist>
 146         <listitem>
 147           <para>
 148             The application programmer who wants to build a media pipeline.
 149             The programmer can use an extensive set of powerful tools to create
 150             media pipelines without writing a single line of code. Performing
 151             complex media manipulations becomes very easy.
 152           </para>
 153         </listitem>
 154         <listitem>
 155           <para>
 156             The plugin programmer. Plugin programmers are provided a clean and
 157             simple API to create self contained plugins. An extensive debugging
 158             and tracing mechanism has been integrated. GStreamer also comes with
 159             an extensive set of real-life plugins that serve as examples too.
 160           </para>
 161         </listitem>
 162       </itemizedlist>
 163
 164     </sect2>
 165     <sect2 id="section-goals-object">
 166       <title>Object oriented</title>
 167       <para>
 168         &GStreamer; adheres to the GLib 2.0 object model. A programmer
 169         familiar with GLib 2.0 or older versions of GTK+ will be
 170         comfortable with &GStreamer;.
 171       </para>
 172       <para>
 173         &GStreamer; uses the mechanism of signals and object properties.
 174       </para>
 175       <para>
 176         All objects can be queried at runtime for their various properties and
 177         capabilities.
 178       </para>
 179       <para>
 180         &GStreamer; intends to be similar in programming methodology to GTK+.
 181         This applies to the object model, ownership of objects, reference
 182         counting, ...
 183       </para>
 184     </sect2>
 185
 186     <sect2 id="section-goals-extensible">
 187       <title>Extensible</title>
 188       <para>
 189         All &GStreamer; Objects can be extended using the GObject
 190         inheritance methods.
 191       </para>
 192       <para>
 193         All plugins are loaded dynamically and can be extended and upgraded
 194         independently.
 195       </para>
 196     </sect2>
 197
 198     <sect2 id="section-goals-binary">
 199       <title>Allow binary only plugins</title>
 200       <para>
 201         Plugins are shared libraries that are loaded at runtime. Since all
 202         the properties of the plugin can be set using the GObject properties,
 203         there is no need (and in fact no way) to have any header files
 204         installed for the plugins.
 205       </para>
 206       <para>
 207         Special care has been taken to make plugins completely selfcontained.
 208         All relevant aspects of plugins can be queried at run-time.
 209       </para>
 210     </sect2>
 211
 212     <sect2 id="section-goals-performance">
 213       <title>High performance</title>
 214       <para>
 215         High performance is obtained by:
 216       </para>
 217       <itemizedlist>
 218         <listitem>
 219           <para>
 220             using GLib's <function>g_mem_chunk</function> and fast
 221             non-blocking allocation algorithms where possible to
 222             minimize dynamic memory allocation.
 223           </para>
 224         </listitem>
 225         <listitem>
 226           <para>
 227             extremely light-weight links between plugins. Data can travel
 228             the pipeline with minimal overhead. Data passing between
 229             plugins only involves a pointer dereference in a typical
 230             pipeline.
 231           </para>
 232         </listitem>
 233         <listitem>
 234           <para>
 235             providing a mechanism to directly work on the target memory.
 236             A plugin can for example directly write to the X server's
 237             shared memory space. Buffers can also point to arbitrary
 238             memory, such as a sound card's internal hardware buffer.
 239           </para>
 240         </listitem>
 241         <listitem>
 242           <para>
 243             refcounting and copy on write minimize usage of memcpy.
 244             Sub-buffers efficiently split buffers into manageable pieces.
 245           </para>
 246         </listitem>
 247         <listitem>
 248           <para>
 249             the use of cothreads to minimize the threading overhead.
 250             Cothreads are a simple and fast user-space method for
 251             switching between subtasks. Cothreads were measured to
 252             consume as little as 600 cpu cycles.
 253           </para>
 254         </listitem>
 255         <listitem>
 256           <para>
 257             allowing hardware acceleration by using specialized plugins.
 258           </para>
 259         </listitem>
 260         <listitem>
 261           <para>
 262             using a plugin registry with the specifications of the plugins so
 263             that the plugin loading can be delayed until the plugin is actually
 264             used.
 265           </para>
 266         </listitem>
 267         <listitem>
 268           <para>
 269             all critical data passing is free of locks and mutexes.
 270           </para>
 271         </listitem>
 272       </itemizedlist>
 273     </sect2>
 274
 275     <sect2 id="section-goals-separation">
 276       <title>Clean core/plugins separation</title>
 277       <para>
 278         The core of &GStreamer; is essentially media-agnostic. It only knows
 279         about bytes and blocks, and only contains basic elements.
 280         The core of &GStreamer; is functional enough to even implement
 281         low-level system tools, like cp.
 282       </para>
 283       <para>
 284         All of the media handling functionality is provided by plugins
 285         external to the core. These tell the core how to handle specific
 286         types of media.
 287       </para>
 288     </sect2>
 289
 290     <sect2 id="section-goals-testbed">
 291       <title>Provide a framework for codec experimentation</title>
 292       <para>
 293         &GStreamer; also wants to be an easy framework where codec
 294         developers can experiment with different algorithms, speeding up
 295         the development of open and free multimedia codecs like <ulink
 296         url="http://www.xiph.org/ogg/index.html" type="http">Theora and
 297         Vorbis</ulink>.
 298       </para>
 299     </sect2>
 300
 301   </sect1>
 302 </chapter>