source: trunk/third/gstreamer/docs/manual/intro-motivation.xml @ 21448

<chapter id="chapter-motivation">
  <title>Motivation &amp; 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 technologies such as
        the <ulink url="http://developer.gnome.org/arch/component/bonobo.html"
        type="http">GNOME object embedding using Bonobo</ulink>.
      </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 slit 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>