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:

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

#include "filter.h"
static GstFlowReturn
		gst_my_filter_get_range	(GstPad     * pad,
					 GstObject  * parent,
					 guint64      offset,
					 guint        length,
					 GstBuffer ** buf);

G_DEFINE_TYPE (GstMyFilter, gst_my_filter, GST_TYPE_ELEMENT);



static void
gst_my_filter_init (GstMyFilter * filter)
{

[..]

  gst_pad_set_getrange_function (filter->srcpad,
      gst_my_filter_get_range);

[..]
}

static GstFlowReturn
gst_my_filter_get_range (GstPad     * pad,
			 GstObject  * parent,
			 guint64      offset,
			 guint        length,
			 GstBuffer ** buf)
{

  GstMyFilter *filter = GST_MY_FILTER (parent);

  [.. here, you would fill *buf ..]

  return GST_FLOW_OK;
}

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).