Object Hierarchy:

Gst.Base.Adapter Gst.Base.Adapter Gst.Base.Adapter GLib.Object GLib.Object GLib.Object->Gst.Base.Adapter


[ CCode ( cname = "GstAdapter" , lower_case_cprefix = "gst_adapter_" , type_id = "gst_adapter_get_type ()" ) ]
[ GIR ( name = "Adapter" ) ]
public sealed class Adapter : Object

This class is for elements that receive buffers in an undesired size.

While for example raw video contains one image per buffer, the same is not true for a lot of other formats, especially those that come directly from a file. So if you have undefined buffer sizes and require a specific size, this object is for you.

An adapter is created with Adapter. It can be freed again with unref.

The theory of operation is like this: All buffers received are put into the adapter using push and the data is then read back in chunks of the desired size using map/gst_adapter_unmap() and/or copy. After the data has been processed, it is freed using unmap.

Other methods such as take and take_buffer combine map and unmap in one method and are potentially more convenient for some use cases.

For example, a sink pad's chain function that needs to pass data to a library in 512-byte chunks could be implemented like this:

static GstFlowReturn
sink_pad_chain (GstPad *pad, GstObject *parent, GstBuffer *buffer)
MyElement *this;
GstAdapter *adapter;
GstFlowReturn ret = GST_FLOW_OK;

this = MY_ELEMENT (parent);

adapter = this->adapter;

// put buffer into adapter
gst_adapter_push (adapter, buffer);

// while we can read out 512 bytes, process them
while (gst_adapter_available (adapter) >= 512 && ret == GST_FLOW_OK) {
const guint8 *data = gst_adapter_map (adapter, 512);
// use flowreturn as an error value
ret = my_library_foo (data);
gst_adapter_unmap (adapter);
gst_adapter_flush (adapter, 512);
return ret;

For another example, a simple element inside GStreamer that uses Adapter is the libvisual element.

An element using Adapter in its sink pad chain function should ensure that when the FLUSH_STOP event is received, that any queued data is cleared using clear. Data should also be cleared or processed on EOS and when changing state from PAUSED to READY.

Also check the GST_BUFFER_FLAG_DISCONT flag on the buffer. Some elements might need to clear the adapter after a discontinuity.

The adapter will keep track of the timestamps of the buffers that were pushed. The last seen timestamp before the current position can be queried with prev_pts. This function can optionally return the number of bytes between the start of the buffer that carried the timestamp and the current adapter position. The distance is useful when dealing with, for example, raw audio samples because it allows you to calculate the timestamp of the current adapter position by using the last seen timestamp and the amount of bytes since. Additionally, the prev_pts_at_offset can be used to determine the last seen timestamp at a particular offset in the adapter.

The adapter will also keep track of the offset of the buffers (#GST_BUFFER_OFFSET) that were pushed. The last seen offset before the current position can be queried with prev_offset. This function can optionally return the number of bytes between the start of the buffer that carried the offset and the current adapter position.

Additionally the adapter also keeps track of the PTS, DTS and buffer offset at the last discontinuity, which can be retrieved with pts_at_discont, dts_at_discont and offset_at_discont. The number of bytes that were consumed since then can be queried with distance_from_discont.

A last thing to note is that while Adapter is pretty optimized, merging buffers still might be an operation that requires a `malloc()` and `memcpy()` operation, and these operations are not the fastest. Because of this, some functions like available_fast are provided to help speed up such cases should you want to. To avoid repeated memory allocations, copy can be used to copy data into a (statically allocated) user provided buffer.

Adapter is not MT safe. All operations on an adapter must be serialized by the caller. This is not normally a problem, however, as the normal use case of Adapter is inside one pad's chain function, in which case access is serialized via the pad's STREAM_LOCK.

Note that push takes ownership of the buffer passed. Use gst_buffer_ref before pushing it into the adapter if you still want to access the buffer later. The adapter will never modify the data in the buffer pushed in it.

Namespace: Gst.Base


Creation methods:


Inherited Members: