After being created, an element will not actually perform any actions yet. You need to change elements state to make it do something. GStreamer knows four element states, each with a very specific meaning. Those four states are:
GST_STATE_NULL: this is the default state.
No resources are allocated in this state, so, transitioning to it
will free all resources. The element must be in this state when
its refcount reaches 0 and it is freed.
GST_STATE_READY: in the ready state, an
element has allocated all of its global resources, that is,
resources that can be kept within streams. You can think about
opening devices, allocating buffers and so on. However, the
stream is not opened in this state, so the stream positions is
automatically zero. If a stream was previously opened, it should
be closed in this state, and position, properties and such should
GST_STATE_PAUSED: in this state, an
element has opened the stream, but is not actively processing
it. An element is allowed to modify a stream's position, read
and process data and such to prepare for playback as soon as
state is changed to PLAYING, but it is not
allowed to play the data which would make the clock run.
In summary, PAUSED is the same as PLAYING but without a running
Elements going into the PAUSED state should prepare themselves for moving over to the PLAYING state as soon as possible. Video or audio outputs would, for example, wait for data to arrive and queue it so they can play it right after the state change. Also, video sinks can already play the first frame (since this does not affect the clock yet). Autopluggers could use this same state transition to already plug together a pipeline. Most other elements, such as codecs or filters, do not need to explicitly do anything in this state, however.
GST_STATE_PLAYING: in the PLAYING state,
an element does exactly the same as in the PAUSED state, except
that the clock now runs.
You can change the state of an element using the function
gst_element_set_state (). If you set an element
to another state, GStreamer will internally traverse all intermediate
states. So if you set an element from NULL to PLAYING, GStreamer
will internally set the element to READY and PAUSED in between.
When moved to
will process data automatically. They do not need to be iterated in
any form. Internally, GStreamer will start threads that take this
task on to them. GStreamer will also take care of switching
messages from the pipeline's thread into the application's own
thread, by using a
Chapter 7 for details.
When you set a bin or pipeline to a certain target state, it will usually
propagate the state change to all elements within the bin or pipeline
automatically, so it's usually only necessary to set the state of the
top-level pipeline to start up the pipeline or shut it down. However,
when adding elements dynamically to an already-running pipeline, e.g.
from within a "pad-added" signal callback, you
need to set it to the desired target state yourself using
gst_element_set_state () or