summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTim-Philipp Müller <tim@centricular.com>2013-10-28 12:55:19 +0000
committerTim-Philipp Müller <tim@centricular.com>2013-10-28 12:55:19 +0000
commit40872f26aef6bb9dbee01fbe942faae5148eac45 (patch)
treea68c47e557b585d9127948569d886641e2c70139
parent20c2008ef8e75d7c4291f600532d3e7312738339 (diff)
docs: design: fix some fixes
-rw-r--r--docs/design/part-buffer.txt4
-rw-r--r--docs/design/part-caps.txt11
-rw-r--r--docs/design/part-context.txt2
-rw-r--r--docs/design/part-messages.txt8
4 files changed, 12 insertions, 13 deletions
diff --git a/docs/design/part-buffer.txt b/docs/design/part-buffer.txt
index 044d88da5..ca98fe51a 100644
--- a/docs/design/part-buffer.txt
+++ b/docs/design/part-buffer.txt
@@ -12,7 +12,7 @@ Requirements
- 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
@@ -125,7 +125,7 @@ Use cases
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.
diff --git a/docs/design/part-caps.txt b/docs/design/part-caps.txt
index bb1e6d1f4..489a84ffd 100644
--- a/docs/design/part-caps.txt
+++ b/docs/design/part-caps.txt
@@ -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. 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.
@@ -123,7 +123,7 @@ for a specific structure, and only structures with the same name _and_
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
@@ -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
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.
diff --git a/docs/design/part-context.txt b/docs/design/part-context.txt
index 02b2d91b4..e7a07dee4 100644
--- a/docs/design/part-context.txt
+++ b/docs/design/part-context.txt
@@ -62,4 +62,4 @@ to the element (or to the complete pipeline).
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.
diff --git a/docs/design/part-messages.txt b/docs/design/part-messages.txt
index 0cdded3e2..023f7da55 100644
--- a/docs/design/part-messages.txt
+++ b/docs/design/part-messages.txt
@@ -18,9 +18,9 @@ Message types
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:
@@ -81,7 +81,7 @@ GST_MESSAGE_NEW_CLOCK:
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: