gstreamer/docs/libs/architecture.xml

116 lines
4 KiB
XML
Raw Normal View History

2009-11-15 17:23:33 +00:00
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
2009-11-15 17:23:33 +00:00
"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
<!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>
2009-11-15 17:23:33 +00:00
<manvolnum>1</manvolnum>
2009-11-15 17:23:33 +00:00
<refmiscinfo>GStreamer Editing Services</refmiscinfo>
</refmeta>
<!-- <refnamediv> -->
2009-11-15 17:23:33 +00:00
<!-- <refname>Overview</refname> -->
2009-11-15 17:23:33 +00:00
<!-- <refpurpose> -->
2009-11-15 17:23:33 +00:00
<!-- Goals of the GStreamer Editing Services. -->
2009-11-15 17:23:33 +00:00
<!-- </refpurpose> -->
2009-11-15 17:23:33 +00:00
<!-- </refnamediv> -->
<refsect1>
<title>Goals of GStreamer Editing Services</title>
2009-11-15 17:23:33 +00:00
<para>The GStreamer multimedia framework and the accompanying GNonLin set
of plugins for non-linear editing offer all the building blocks for:
<itemizedlist>
<listitem>
<para>Decoding and encoding to a wide variety of formats, through
all the available GStreamer plugins.</para>
</listitem>
<listitem>
<para>Easily choosing segments of streams and arranging them through
time through the GNonLin set of plugins.</para>
</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>
2009-11-15 17:23:33 +00:00
<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 (seen in <xref
linkend="layer_tracks_diagram" />): <itemizedlist>
<listitem>
<para>Layers - Corresponds to the user-visible layout of
non-overlapping objects. A minimalistic timeline would only have
one layer. A more complex editing application could use as many as
needed.</para>
</listitem>
<listitem>
<para>Tracks - Corresponds to the output stream formats. A typical
GESTimeline would have a audio track and a video track. An audio
editor would only require one single audio Track.</para>
</listitem>
</itemizedlist></para>
<figure float="0" id="layer_tracks_diagram">
<title>Layers and Tracks</title>
<mediaobject>
<imageobject>
<imagedata fileref="layer_track_overview.png" scale="75" />
</imageobject>
</mediaobject>
</figure>
<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>
2009-11-15 17:23:33 +00:00
<para>The layers are the end-user visible part of GES.</para>
</refsect2>
<refsect2>
<title>Timeline Tracks</title>
2009-11-15 17:23:33 +00:00
<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>