mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-15 22:01:27 +00:00
59 lines
2.3 KiB
Text
59 lines
2.3 KiB
Text
<chapter id="cha-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 the 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>
|
|
The most important information in the buffer is:
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
A pointer to a piece of memory.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
The size of the memory.
|
|
</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 is having a reference to it.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
<para>
|
|
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 filter. That filter 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 carefull when
|
|
the buffer is used in more than one element; a copy on write has to made in this
|
|
situation.
|
|
</para>
|
|
|
|
</chapter>
|