All streams of data in GStreamer are chopped up into chunks that are passed from a source pad on one element to a sink pad on another element. Buffers are structures used to hold these chunks of data. Buffers can be of any size, theoretically, and they may contain any sort of data that the two linked pads know how to handle. Normally, a buffer contains a chunk of some sort of audio or video data that flows from one element to another.
Buffers also contain metadata describing the buffer's contents. Some of the important types of metadata are:
A pointer to the buffer's data.
An integer indicating the size of the buffer's data.
A GstData object describing the type of the buffer's data.
A reference count indicating the number of elements currently holding a reference to the buffer. When the buffer reference count falls to zero, the buffer will be unlinked, and its memory will be freed in some sense (see below for more details).
See the GStreamer Library Reference for the current implementation details of a GstBuffer.
Buffers can be allocated using various schemes, and they may either be passed on by an element or unreferenced, thus freeing the memory used by the buffer. Buffer allocation and unlinking are important concepts when dealing with real time media processing, since memory allocation is relatively slow on most systems.
To improve the latency in a media pipeline, many GStreamer elements use a buffer pool to handle buffer allocation and unlinking. A buffer pool is a relatively large chunk of memory that is the GStreamer process requests early on from the operating system. Later, when elements request memory for a new buffer, the buffer pool can serve the request quickly by giving out a piece of the allocated memory. This saves a call to the operating system and lowers latency. [If it seems at this point like GStreamer is acting like an operating system (doing memory management, etc.), don't worry: GStreamerOS isn't due out for quite a few years!]
Normally in a media pipeline, most filter elements in GStreamer deal with a buffer in place, meaning that they do not create or destroy buffers. Sometimes, however, elements might need to alter the reference count of a buffer, either by copying or destroying the buffer, or by creating a new buffer. These topics are generally reserved for non-filter elements, so they will be addressed at that point.