Providing random access

In the previous section, we have talked about how elements (or pads)
that are activated to drive the pipeline using their own task, must use
pull-mode scheduling on their sinkpads. This means that all pads linked
to those pads need to be activated in pull-mode.
Source pads activated in pull-mode must implement a
_get_range ()-function set using
gst_pad_set_getrange_function (), and
that function will be called when the peer pad requests some data with
gst_pad_pull_range ().
The element is then responsible for seeking to the right offset and
providing the requested data. Several elements can implement random
access:

Data sources, such as a file source, that can provide data from any
offset with reasonable low latency.

Filters that would like to provide a pull-mode scheduling
over the whole pipeline.

Parsers who can easily provide this by skipping a small part of
their input and are thus essentially "forwarding" getrange
requests literally without any own processing involved. Examples
include tag readers (e.g. ID3) or single output parsers, such as
a WAVE parser.

The following example will show how a _get_range
()-function can be implemented in a source element:

In practice, many elements that could theoretically do random access,
may in practice often be activated in push-mode scheduling anyway,
since there is no downstream element able to start its own task.
Therefore, in practice, those elements should implement both a
_get_range ()-function and a _chain
()-function (for filters and parsers) or a _get_range
()-function and be prepared to start their own task by
providing _activate_* ()-functions (for
source elements).