In , you have learned how to use GObject 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 Glib GInterface type. 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. In all examples so far, we have only supported local files through the filesrc 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 file:///<path>/<file>, http://<host>/<path>/<file>, mms://<host>/<path>/<file>, and so on. In order to get the source or sink element supporting a particular URI, use gst_element_make_from_uri (), with the URI type being either GST_URI_SRC for a source element, or GST_URI_SINK for a sink element. You can convert filenames to and from URIs using GLib's g_filename_to_uri () and g_uri_to_filename (). The mixer interface provides a uniform way to control the volume on a hardware (or software) mixer. The interface is primarily intended to be implemented by elements for audio inputs and outputs that talk directly to the hardware (e.g. OSS or ALSA plugins). Using this interface, it is possible to control a list of tracks (such as Line-in, Microphone, etc.) from a mixer element. They can be muted, their volume can be changed and, for input tracks, their record flag can be set as well. Example plugins implementing this interface include the OSS elements (osssrc, osssink, ossmixer) and the ALSA plugins (alsasrc, alsasink and alsamixer). You should not use this interface for volume control in a playback application. Either use a volume element or use playbin's volume property, or use the audiosink's volume property (if it has one). In order for the GstMixer interface to be usable, the element implementing it needs to be in the right state, so that the underlying mixer device is open. This usually means the element needs to be at least in GST_STATE_READY before you can use this interface. You will get confusing warnings if the element is not in the right state when the interface is used. The tuner interface is a uniform way to control inputs and outputs on a multi-input selection device. This is primarily used for input selection on elements for TV- and capture-cards. Using this interface, it is possible to select one track from a list of tracks supported by that tuner-element. The tuner will than select that track for media-processing internally. This can, for example, be used to switch inputs on a TV-card (e.g. from Composite to S-video). This interface is currently only implemented by the Video4linux and Video4linux2 elements. In order for the GstTuner interface to be usable, the element implementing it needs to be in the right state, so that the underlying device is open. This usually means the element needs to be at least in GST_STATE_READY before you can use this interface. You will get confusing warnings if the element is not in the right state when the interface is used. 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 existance is that, as far as its authors know, there's no way to dynamically register properties using GObject. The colorbalance interface is implemented by several plugins, including xvimagesink and the Video4linux and Video4linux2 elements. The property probe is a way to autodetect allowed values for a GObject property. It's primary use is to autodetect devices in several elements. For example, the OSS elements use this interface to detect all OSS devices on a system. Applications can then probe this property and get a list of detected devices. Given the overlap between HAL and the practical implementations of this interface, this might in time be deprecated in favour of HAL. This interface is currently implemented by many elements, including the ALSA, OSS, XVImageSink, Video4linux and Video4linux2 elements. The X Overlay interface was created to solve the problem of embedding video streams in an application window. The application provides an X-window to the element implementing this interface to draw on, and the element will then use this X-window to draw on rather than creating a new toplevel window. This is useful to embed video in video players. This interface is implemented by, amongst others, the Video4linux and Video4linux2 elements and by ximagesink, xvimagesink and sdlvideosink.