Chapter 5. Elements

Table of Contents

What are elements?
Source elements
Filters, convertors, demuxers, muxers and codecs
Sink elements
Creating a GstElement
Using an element as a GObject
More about element factories
Getting information about an element using a factory
Finding out what pads an element can contain
Linking elements
Element States

The most important object in GStreamer for the application programmer is the GstElement object. An element is the basic building block for a media pipeline. All the different high-level components you will use are derived from GstElement. Every decoder, encoder, demuxer, video or audio output is in fact a GstElement

What are elements?

For the application programmer, elements are best visualized as black boxes. On the one end, you might put something in, the element does something with it and something else comes out at the other side. For a decoder element, for example, you'd put in encoded data, and the element would output decoded data. In the next chapter (see Pads and capabilities), you will learn more about data input and output in elements, and how you can set that up in your application.

Source elements

Source elements generate data for use by a pipeline, for example reading from disk or from a sound card. Figure 5.1, “Visualisation of a source element” shows how we will visualise a source element. We always draw a source pad to the right of the element.

Figure 5.1. Visualisation of a source element

Visualisation of a source element

Source elements do not accept data, they only generate data. You can see this in the figure because it only has a source pad (on the right). A source pad can only generate data.

Filters, convertors, demuxers, muxers and codecs

Filters and filter-like elements have both input and outputs pads. They operate on data that they receive on their input (sink) pads, and will provide data on their output (source) pads. Examples of such elements are a volume element (filter), a video scaler (convertor), an Ogg demuxer or a Vorbis decoder.

Filter-like elements can have any number of source or sink pads. A video demuxer, for example, would have one sink pad and several (1-N) source pads, one for each elementary stream contained in the container format. Decoders, on the other hand, will only have one source and sink pads.

Figure 5.2. Visualisation of a filter element

Visualisation of a filter element

Figure 5.2, “Visualisation of a filter element” shows how we will visualise a filter-like element. This specific element has one source and one sink element. Sink pads, receiving input data, are depicted at the left of the element; source pads are still on the right.

Figure 5.3. Visualisation of a filter element with more than one output pad

Visualisation of a filter element with more than one output pad

Figure 5.3, “Visualisation of a filter element with more than one output pad” shows another filter-like element, this one having more than one output (source) pad. An example of one such element could, for example, be an Ogg demuxer for an Ogg stream containing both audio and video. One source pad will contain the elementary video stream, another will contain the elementary audio stream. Demuxers will generally fire signals when a new pad is created. The application programmer can then handle the new elementary stream in the signal handler.

Sink elements

Sink elements are end points in a media pipeline. They accept data but do not produce anything. Disk writing, soundcard playback, and video output would all be implemented by sink elements. Figure 5.4, “Visualisation of a sink element” shows a sink element.

Figure 5.4. Visualisation of a sink element

Visualisation of a sink element