| <chapter id="cha-goals"> |
| <title>Goals</title> |
| <para> |
| GStreamer was designed to provide a solution to the current Linux media |
| problems. |
| </para> |
| |
| <sect1 id="sec-goals-design"> |
| <title>The design goals</title> |
| <para> |
| We descibe what we try to achieve with GStreamer. |
| </para> |
| <sect2 id="sec-goals-clean"> |
| <title>Clean and powerfull</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 powerfull 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 an example too. |
| </para> |
| </listitem> |
| </itemizedlist> |
| |
| </sect2> |
| <sect2 id="sec-goals-object"> |
| <title>Object oriented</title> |
| <para> |
| Adhere 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> |
| </sect2> |
| |
| <sect2 id="sec-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="sec-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 taking into making the plugin completely self |
| contained. All relevant aspects of plugins can be queried at run-time. |
| </para> |
| </sect2> |
| |
| <sect2 id="sec-goals-performance"> |
| <title>High performance</title> |
| <para> |
| High performance is obtained by: |
| </para> |
| <itemizedlist> |
| <listitem> |
| <para> |
| Using GLib g_mem_chunk where possible to minimize dynamic memory |
| allocation. |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| Extremely light-weight connections between plugins. Data can travel |
| the pipeline with minimal overhead. |
| </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(3). |
| 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. |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| Allowing HW acceleration by the use of 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> |
| </itemizedlist> |
| </sect2> |
| </sect1> |
| </chapter> |