wearable/docs/manual/intro-motivation.xml

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