- It must be fast
* allocation, free, low fragmentation
- Must be able to attach multiple memory blocks to the buffer
- - Must be able to attach artbitrary metadata to buffers
+ - Must be able to attach arbitrary metadata to buffers
- efficient handling of subbuffer, copy, span, trim
Lifecycle
Generating RTP packets from h264 video
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-We receive a GstBuffer as input with an encoded h264 image and we need to
+We receive as input a GstBuffer with an encoded h264 image and we need to
create RTP packets containing this h264 data as the payload. We typically need
to fragment the h264 data into multiple packets, each with their own RTP and
payload specific header.
structures is meant to express the preferences for the different
structures. Afterwards, each unfixed field of this structure is set
to the value that makes most sense for the media format by the element
-or pad implementation and then every remaining unfixed fields are set to
-an arbitrary value that is a subset of the unfixed field possible values.
+or pad implementation and then every remaining unfixed field is set to
+an arbitrary value that is a subset of the unfixed field's values.
EMPTY caps are fixed caps and ANY caps are not. Caps with ANY caps features
are not fixed.
equal caps features are considered compatible.
Caps features can be used to require a specific memory representation
or a specific meta to be set on buffers, for example a pad could require
-for a specific structure that includes EGLImage memory or buffers with
+for a specific structure that it is passed EGLImage memory or buffers with
the video meta.
If no caps features are provided for a structure, it is assumed that
system memory is required unless later negotiation steps (e.g. the
pad's caps but pads can introduce additional constraints which would be
checked in the ACCEPT_CAPS query handler.
-Data flow can only happen after pads have decided on a common and fixed
-set of caps. These caps are then distributed to both pads with the CAPS
-event.
+Data flow can only happen after pads have decided on common fixed caps.
+These caps are distributed to both pads with the CAPS event.
Whenever an element creates a context internally it will post a
GST_MESSAGE_HAVE_CONTEXT message on the bus. Bins will cache these
-contexts and pass them to any future elements that requests them.
+contexts and pass them to any future element that requests them.
GST_MESSAGE_EOS:
- Posted by sink elements. This message is posted when all the sinks in a
- pipeline have posted an EOS message. When performing a flushing seek, the
- EOS state of the pipeline (and hence, its sinks) is resetted.
+ Posted by sink elements. This message is posted to the application when all
+ the sinks in a pipeline have posted an EOS message. When performing a
+ flushing seek, the EOS state of the pipeline and sinks is reset.
GST_MESSAGE_ERROR:
GST_MESSAGE_STRUCTURE_CHANGE:
The pipeline changed its structure, This means elements were added or removed or
- pads were linked or unlinked. This messages is not yet used.
+ pads were linked or unlinked. This message is not yet used.
GST_MESSAGE_STREAM_STATUS: