mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-27 04:01:08 +00:00
70cfc6cb4d
Original commit message from CVS: * new parser that uses flex and bison - doesn't do dynamic pipelines yet... * added GErrors to the gst_parse_launch[v] api * added --gst-mask-help command line option * fixed -o option for gst-launch * GstElement api change: - gst_element_get_pad - gst_element_get_request_pad, gst_element_get_static_pad - gst_element_get_compatible_pad - gst_element_get_compatible_static_pad, gst_element_get_compatible_request_pad - gst_element_[dis]connect -> gst_element_[dis]connect_pads - gst_element_[dis]connect_elements -> gst_element_[dis]connect * manual update * example, tool, and doc updates for the api changes - no more plugin docs in the core docs, plugins require a more extensive doc system
59 lines
2.3 KiB
XML
59 lines
2.3 KiB
XML
<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 careful when
|
|
the buffer is used in more than one element; a copy on write has to made in this
|
|
situation.
|
|
</para>
|
|
|
|
</chapter>
|