gstreamer/docs/libs/architecture.xml

<?xml version="1.0"?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
          "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
	  <!ENTITY % version-entities SYSTEM "version.entities">
	  %version-entities;
	  <!ENTITY % local.common.attrib "xmlns:xi  CDATA  #FIXED 'http://www.w3.org/2003/XInclude'">
	  ]>
<refentry id="ges-architecture" revision="25 mar 2009">
  <refmeta>
    <refentrytitle>Overview and architecture</refentrytitle>
    <manvolnum>1</manvolnum>
    <refmiscinfo>GStreamer Editing Services</refmiscinfo>
  </refmeta>

  <!-- <refnamediv> -->
  <!-- <refname>Overview</refname> -->
  <!-- <refpurpose> -->
  <!-- Goals of the GStreamer Editing Services. -->
  <!-- </refpurpose> -->
  <!-- </refnamediv> -->

  <refsect1>
    <title>Goals of GStreamer Editing Services</title>
    
    <para>
      The GStreamer multimedia framework and the accompanying GNonLin set
      of plugins for non-linear editing offer all the building blocks for:
      <itemizedlist>
	<listitem>
	  Decoding and encoding to a wide variety of formats, through
	  all the available GStreamer plugins.
	</listitem>
	<listitem>
	  Easily choosing segments of streams and arranging them through
	  time through the GNonLin set of plugins.
	</listitem>
      </itemizedlist>
    </para>

    <para>
      But all those building blocks only offer stream-level access,
      which results in developers who want to write non-linear editors
      to write a consequent amount of code to get to the level of
      <emphasis>non-linear editing</emphasis> notions which are closer
      and more meaningful for the end-user (and therefore the
      application).
    </para>

    <para>
      The GStreamer Editing Services <remark>(hereafter GES)</remark>
      aims to fill the gap between GStreamer/GNonLin and the
      application developer by offering a series of classes to
      simplify the creation of many kind of editing-related
      applications. 
    </para>

  </refsect1>

  <refsect1>
    <title>Architecture</title>

    <refsect2>
      <title>Timeline and TimelinePipeline</title>

      <para>
	The most top-level object encapsulating every other object is
	the <link linkend="GESTimeline">GESTimeline</link>. It is the
	central object for any editing project. 
      </para>

      <para>
	The <classname>GESTimeline</classname> is
	a <classname>GstElement</classname>. It can therefore be used in
	any GStreamer pipeline like any other object.
      </para>

      <para>
	The GESTimeline can contain two types of objects:
	<itemizedlist>
	  <listitem>
	    <emphasis>Layers</emphasis> - Corresponds to the user-visible
	    layout of non-overlapping objects. A minimalistic would
	    only have one layer. A more complex editing application
	    could use as many as needed.
	  </listitem>
	  <listitem>
	    <emphasis>Tracks</emphasis> - Corresponds to the output
	    stream formats. A typical GESTimeline would have a audio
	    track and a video track. A audio editor would only require
	    one single audio Track.
	  </listitem>
	</itemizedlist>
      </para>

      <para>
	FIXME : INSERT DIAGRAM
      </para>

      <para>
	In order to reduce even more the amount of GStreamer
	interaction the application developer has to deal with , a
	convenience GstPipeline has been made available specifically
	for Timelines
	:  <link linkend="GESTimelinePipeline">GESTimelinePipeline</link>.
      </para>
    </refsect2>


    <refsect2>
      <title>Timeline layers</title>

      <para>
	The layers are the end-user visible part of GES.
      </para>
    </refsect2>

    <refsect2>
      <title>Timeline Tracks</title>

      <para>
	The tracks are the GStreamer-level components of a
	Timeline. They are a 1-to-1 relationship to the output
	streams. 
      </para>
    </refsect2>
  </refsect1>

</refentry>