mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2025-01-24 16:18:16 +00:00
Code Issues 1 Projects Releases Wiki Activity

docs: design: fix some fixes

Browse source
This commit is contained in:
Tim-Philipp Müller 2013-10-28 12:55:19 +00:00
parent 20c2008ef8
commit 40872f26ae
4 changed files with 12 additions and 13 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
docs/design/part-buffer.txt
View file

@ -12,7 +12,7 @@ Requirements
- It must be fast - It must be fast
* allocation, free, low fragmentation * allocation, free, low fragmentation
- Must be able to attach multiple memory blocks to the buffer - 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 - efficient handling of subbuffer, copy, span, trim
Lifecycle Lifecycle
@ -125,7 +125,7 @@ Use cases
Generating RTP packets from h264 video 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 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 to fragment the h264 data into multiple packets, each with their own RTP and
payload specific header. payload specific header.

11
docs/design/part-caps.txt
View file

@ -29,8 +29,8 @@ For fixating caps only the first structure is kept as the order of
structures is meant to express the preferences for the different structures is meant to express the preferences for the different
structures. Afterwards, each unfixed field of this structure is set structures. Afterwards, each unfixed field of this structure is set
to the value that makes most sense for the media format by the element 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 or pad implementation and then every remaining unfixed field is set to
an arbitrary value that is a subset of the unfixed field possible values. 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 EMPTY caps are fixed caps and ANY caps are not. Caps with ANY caps features
are not fixed. are not fixed.
@ -123,7 +123,7 @@ for a specific structure, and only structures with the same name _and_
equal caps features are considered compatible. equal caps features are considered compatible.
Caps features can be used to require a specific memory representation 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 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. the video meta.
If no caps features are provided for a structure, it is assumed that If no caps features are provided for a structure, it is assumed that
system memory is required unless later negotiation steps (e.g. the system memory is required unless later negotiation steps (e.g. the
@ -142,7 +142,6 @@ not enough. Instead the fixed caps must be at least a subset of the
pad's caps but pads can introduce additional constraints which would be pad's caps but pads can introduce additional constraints which would be
checked in the ACCEPT_CAPS query handler. checked in the ACCEPT_CAPS query handler.
Data flow can only happen after pads have decided on a common and fixed Data flow can only happen after pads have decided on common fixed caps.
set of caps. These caps are then distributed to both pads with the CAPS These caps are distributed to both pads with the CAPS event.
event.

2
docs/design/part-context.txt
View file

@ -62,4 +62,4 @@ to the element (or to the complete pipeline).
Whenever an element creates a context internally it will post a Whenever an element creates a context internally it will post a
GST_MESSAGE_HAVE_CONTEXT message on the bus. Bins will cache these 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.

8
docs/design/part-messages.txt
View file

@ -18,9 +18,9 @@ Message types
GST_MESSAGE_EOS: GST_MESSAGE_EOS:
Posted by sink elements. This message is posted when all the sinks in a Posted by sink elements. This message is posted to the application when all
pipeline have posted an EOS message. When performing a flushing seek, the the sinks in a pipeline have posted an EOS message. When performing a
EOS state of the pipeline (and hence, its sinks) is resetted. flushing seek, the EOS state of the pipeline and sinks is reset.
GST_MESSAGE_ERROR: GST_MESSAGE_ERROR:
@ -81,7 +81,7 @@ GST_MESSAGE_NEW_CLOCK:
GST_MESSAGE_STRUCTURE_CHANGE: GST_MESSAGE_STRUCTURE_CHANGE:
The pipeline changed its structure, This means elements were added or removed or 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: GST_MESSAGE_STREAM_STATUS: