wearable/docs/manual/advanced-interfaces.xml

   1 <chapter id="chapter-interfaces">
   2   <title>Interfaces</title>
   3
   4   <para>
   5     In <xref linkend="section-elements-properties"/>, you have learned how
   6     to use <classname>GObject</classname> properties as a simple way to do
   7     interaction between applications and elements. This method suffices for
   8     the simple'n'straight settings, but fails for anything more complicated
   9     than a getter and setter. For the more complicated use cases, &GStreamer;
  10     uses interfaces based on the GObject <ulink type="http"
  11       url="http://library.gnome.org/devel/gobject/stable/gtype-non-instantiable-classed.html"><classname>GTypeInterface</classname></ulink>
  12     type.
  13   </para>
  14
  15   <para>
  16     Most of the interfaces handled here will not contain any example code.
  17     See the API references for details. Here, we will just describe the
  18     scope and purpose of each interface.
  19   </para>
  20
  21   <sect1 id="section-interfaces-uri">
  22     <title>The URI interface</title>
  23
  24     <para>
  25       In all examples so far, we have only supported local files through the
  26       <quote>filesrc</quote> element. &GStreamer;, obviously, supports many
  27       more location sources. However, we don't want applications to need to
  28       know any particular element implementation details, such as element
  29       names for particular network source types and so on. Therefore, there
  30       is a URI interface, which can be used to get the source element that
  31       supports a particular URI type. There is no strict rule for URI naming,
  32       but in general we follow naming conventions that others use, too. For
  33       example, assuming you have the correct plugins installed, &GStreamer;
  34       supports <quote>file:///&lt;path&gt;/&lt;file&gt;</quote>,
  35       <quote>http://&lt;host&gt;/&lt;path&gt;/&lt;file&gt;</quote>,
  36       <quote>mms://&lt;host&gt;/&lt;path&gt;/&lt;file&gt;</quote>, and so on.
  37     </para>
  38     <para>
  39       In order to get the source or sink element supporting a particular URI,
  40       use <function>gst_element_make_from_uri ()</function>, with the URI
  41       type being either <classname>GST_URI_SRC</classname> for a source
  42       element, or <classname>GST_URI_SINK</classname> for a sink element.
  43     </para>
  44     <para>
  45       You can convert filenames to and from URIs using GLib's
  46       <function>g_filename_to_uri ()</function> and
  47       <function>g_uri_to_filename ()</function>.
  48     </para>
  49   </sect1>
  50
  51   <sect1 id="section-interfaces-mixer">
  52     <title>The Mixer interface</title>
  53
  54     <para>
  55       The mixer interface provides a uniform way to control the volume on a
  56       hardware (or software) mixer. The interface is primarily intended to
  57       be implemented by elements for audio inputs and outputs that talk
  58       directly to the hardware (e.g. OSS or ALSA plugins).
  59     </para>
  60     <para>
  61       Using this interface, it is possible to control a list of tracks
  62       (such as Line-in, Microphone, etc.) from a mixer element. They can
  63       be muted, their volume can be changed and, for input tracks, their
  64       record flag can be set as well.
  65     </para>
  66     <para>
  67       Example plugins implementing this interface include the OSS elements
  68       (osssrc, osssink, ossmixer) and the ALSA plugins (alsasrc, alsasink
  69       and alsamixer).
  70     </para>
  71     <para>
  72       You should not use this interface for volume control in a playback
  73       application. Either use a <classname>volume</classname> element or use
  74       <classname>playbin</classname>'s <quote>volume</quote> property, or use
  75       the <classname>audiosink</classname>'s <quote>volume</quote> property (if it has one).
  76     </para>
  77     <note>
  78       <para>
  79         In order for the <ulink type="http"
  80           url="http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-gstmixer.html"><classname>GstMixer</classname></ulink>
  81         interface to be
  82         usable, the element implementing it needs to be in the right state,
  83         so that the underlying mixer device is open. This usually means the
  84         element needs to be at least in <classname>GST_STATE_READY</classname>
  85         before you can use this interface. You will get confusing warnings
  86         if the element is not in the right state when the interface is used.
  87       </para>
  88     </note>
  89   </sect1>
  90
  91   <sect1 id="section-interfaces-tuner">
  92     <title>The Tuner interface</title>
  93
  94     <para>
  95       The tuner interface is a uniform way to control inputs and outputs
  96       on a multi-input selection device. This is primarily used for input
  97       selection on elements for TV- and capture-cards.
  98     </para>
  99     <para>
 100       Using this interface, it is possible to select one track from a list
 101       of tracks supported by that tuner-element. The tuner will then select
 102       that track for media-processing internally. This can, for example, be
 103       used to switch inputs on a TV-card (e.g. from Composite to S-video).
 104     </para>
 105     <para>
 106       This interface is currently only implemented by the Video4linux and
 107       Video4linux2 elements.
 108     </para>
 109     <note>
 110       <para>
 111         In order for the <ulink type="http"
 112           url="http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-gsttuner.html"><classname>GstTuner</classname></ulink>
 113         interface to be
 114         usable, the element implementing it needs to be in the right state,
 115         so that the underlying device is open. This usually means the
 116         element needs to be at least in <classname>GST_STATE_READY</classname>
 117         before you can use this interface. You will get confusing warnings
 118         if the element is not in the right state when the interface is used.
 119       </para>
 120     </note>
 121   </sect1>
 122
 123   <sect1 id="section-interfaces-colorbalance">
 124     <title>The Color Balance interface</title>
 125
 126     <para>
 127       The colorbalance interface is a way to control video-related properties
 128       on an element, such as brightness, contrast and so on. It's sole
 129       reason for existence is that, as far as its authors know, there's no
 130       way to dynamically register properties using
 131       <classname>GObject</classname>.
 132     </para>
 133     <para>
 134       The colorbalance interface is implemented by several plugins, including
 135       xvimagesink and the Video4linux and Video4linux2 elements.
 136     </para>
 137   </sect1>
 138
 139   <sect1 id="section-interfaces-proprobe">
 140     <title>The Property Probe interface</title>
 141
 142     <para>
 143       The property probe is a way to autodetect allowed values for a
 144       <classname>GObject</classname> property. It's primary use is to autodetect
 145       devices in several elements. For example, the OSS elements use this
 146       interface to detect all OSS devices on a system. Applications can then
 147       <quote>probe</quote> this property and get a list of detected devices.
 148     </para>
 149     <note>
 150       <para>
 151         Given the overlap between HAL and the practical implementations of this
 152         interface, this might in time be deprecated in favour of HAL.
 153       </para>
 154     </note>
 155     <para>
 156       This interface is currently implemented by many elements, including
 157       the ALSA, OSS, XVideo, Video4linux and Video4linux2 elements.
 158     </para>
 159   </sect1>
 160
 161   <sect1 id="section-interfaces-xoverlay">
 162     <title>The X Overlay interface</title>
 163
 164     <para>
 165       The X Overlay interface was created to solve the problem of embedding
 166       video streams in an application window. The application provides an
 167       X-window to the element implementing this interface to draw on, and
 168       the element will then use this X-window to draw on rather than creating
 169       a new toplevel window. This is useful to embed video in video players.
 170     </para>
 171     <para>
 172       This interface is implemented by, amongst others, the Video4linux and
 173       Video4linux2 elements and by ximagesink, xvimagesink and sdlvideosink.
 174     </para>
 175   </sect1>
 176 </chapter>