mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2025-01-10 01:15:39 +00:00
67 lines
2.4 KiB
XML
67 lines
2.4 KiB
XML
|
<chapter id="chapter-buffers">
|
||
|
<title>Buffers</title>
|
||
|
<para>
|
||
|
Buffers contain the data that will flow through the pipeline you have
|
||
|
created. A source element will typically create a new buffer and pass
|
||
|
it through a pad to the next element in the chain. When using the
|
||
|
GStreamer infrastructure to create a media pipeline you will not have
|
||
|
to deal with buffers yourself; the elements will do that for you.
|
||
|
</para>
|
||
|
<para>
|
||
|
A buffer consists of:
|
||
|
|
||
|
<itemizedlist>
|
||
|
<listitem>
|
||
|
<para>
|
||
|
a pointer to a piece of memory.
|
||
|
</para>
|
||
|
</listitem>
|
||
|
<listitem>
|
||
|
<para>
|
||
|
the size of the memory.
|
||
|
</para>
|
||
|
</listitem>
|
||
|
<listitem>
|
||
|
<para>
|
||
|
a timestamp for the buffer.
|
||
|
</para>
|
||
|
</listitem>
|
||
|
<listitem>
|
||
|
<para>
|
||
|
A refcount that indicates how many elements are using this
|
||
|
buffer. This refcount will be used to destroy the buffer when no
|
||
|
element has a reference to it.
|
||
|
</para>
|
||
|
</listitem>
|
||
|
</itemizedlist>
|
||
|
</para>
|
||
|
|
||
|
<para>
|
||
|
<!-- FIXME: this is outdated, there is no GstBufferPool in gst-0.8.X -->
|
||
|
GStreamer provides functions to create custom buffer create/destroy algorithms, called
|
||
|
a <classname>GstBufferPool</classname>. This makes it possible to efficiently
|
||
|
allocate and destroy buffer memory. It also makes it possible to exchange memory between
|
||
|
elements by passing the <classname>GstBufferPool</classname>. A video element can,
|
||
|
for example, create a custom buffer allocation algorithm that creates buffers with XSHM
|
||
|
as the buffer memory. An element can use this algorithm to create and fill the buffer
|
||
|
with data.
|
||
|
</para>
|
||
|
|
||
|
<para>
|
||
|
The simple case is that a buffer is created, memory allocated, data put
|
||
|
in it, and passed to the next element. That element reads the data, does
|
||
|
something (like creating a new buffer and decoding into it), and
|
||
|
unreferences the buffer. This causes the data to be freed and the buffer
|
||
|
to be destroyed. A typical MPEG audio decoder works like this.
|
||
|
</para>
|
||
|
|
||
|
<para>
|
||
|
A more complex case is when the filter modifies the data in place. It
|
||
|
does so and simply passes on the buffer to the next element. This is just
|
||
|
as easy to deal with. An element that works in place has to be careful when
|
||
|
the buffer is used in more than one element; a copy on write has to made in this
|
||
|
situation.
|
||
|
</para>
|
||
|
|
||
|
</chapter>
|