gstreamer/docs/manual/advanced-interfaces.xml
Wim Taymans 7c24fc7450 manual: fix up the manual
MIME-type -> media types
Fix up the manual in various places with the 1.0 way of doing things
such as probes, static elements, scheduling, ...
Add porting from 0.10 to 1.0 chapter.
Add probe example to build.
Remove some docs for remove components such as GstMixer and
GstPropertyProbe, XML...
2012-09-25 14:45:15 +02:00

82 lines
3.6 KiB
XML

<chapter id="chapter-interfaces">
<title>Interfaces</title>
<para>
In <xref linkend="section-elements-properties"/>, you have learned how
to use <classname>GObject</classname> properties as a simple way to do
interaction between applications and elements. This method suffices for
the simple'n'straight settings, but fails for anything more complicated
than a getter and setter. For the more complicated use cases, &GStreamer;
uses interfaces based on the GObject <ulink type="http"
url="http://library.gnome.org/devel/gobject/stable/gtype-non-instantiable-classed.html"><classname>GTypeInterface</classname></ulink>
type.
</para>
<para>
Most of the interfaces handled here will not contain any example code.
See the API references for details. Here, we will just describe the
scope and purpose of each interface.
</para>
<sect1 id="section-interfaces-uri">
<title>The URI interface</title>
<para>
In all examples so far, we have only supported local files through the
<quote>filesrc</quote> element. &GStreamer;, obviously, supports many
more location sources. However, we don't want applications to need to
know any particular element implementation details, such as element
names for particular network source types and so on. Therefore, there
is a URI interface, which can be used to get the source element that
supports a particular URI type. There is no strict rule for URI naming,
but in general we follow naming conventions that others use, too. For
example, assuming you have the correct plugins installed, &GStreamer;
supports <quote>file:///&lt;path&gt;/&lt;file&gt;</quote>,
<quote>http://&lt;host&gt;/&lt;path&gt;/&lt;file&gt;</quote>,
<quote>mms://&lt;host&gt;/&lt;path&gt;/&lt;file&gt;</quote>, and so on.
</para>
<para>
In order to get the source or sink element supporting a particular URI,
use <function>gst_element_make_from_uri ()</function>, with the URI
type being either <classname>GST_URI_SRC</classname> for a source
element, or <classname>GST_URI_SINK</classname> for a sink element.
</para>
<para>
You can convert filenames to and from URIs using GLib's
<function>g_filename_to_uri ()</function> and
<function>g_uri_to_filename ()</function>.
</para>
</sect1>
<sect1 id="section-interfaces-colorbalance">
<title>The Color Balance interface</title>
<para>
The colorbalance interface is a way to control video-related properties
on an element, such as brightness, contrast and so on. It's sole
reason for existence is that, as far as its authors know, there's no
way to dynamically register properties using
<classname>GObject</classname>.
</para>
<para>
The colorbalance interface is implemented by several plugins, including
xvimagesink and the Video4linux2 elements.
</para>
</sect1>
<sect1 id="section-interfaces-videooverlay">
<title>The Video Overlay interface</title>
<para>
The Video Overlay interface was created to solve the problem of embedding
video streams in an application window. The application provides an
window handle to the element implementing this interface to draw on, and
the element will then use this window handle to draw on rather than creating
a new toplevel window. This is useful to embed video in video players.
</para>
<para>
This interface is implemented by, amongst others, the Video4linux2
elements and by ximagesink, xvimagesink and sdlvideosink.
</para>
</sect1>
</chapter>