mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-12-04 15:36:35 +00:00
626cbdc8b2
Original commit message from CVS: cleanup of unused and forgoten sections fixed links from the manual and the pwg to the API docs added more notes to README
66 lines
2.4 KiB
XML
66 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>
|