From 40872f26aef6bb9dbee01fbe942faae5148eac45 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Tim-Philipp=20M=C3=BCller?= Date: Mon, 28 Oct 2013 12:55:19 +0000 Subject: [PATCH] docs: design: fix some fixes --- docs/design/part-buffer.txt | 4 ++-- docs/design/part-caps.txt | 11 +++++------ docs/design/part-context.txt | 2 +- docs/design/part-messages.txt | 8 ++++---- 4 files changed, 12 insertions(+), 13 deletions(-) diff --git a/docs/design/part-buffer.txt b/docs/design/part-buffer.txt index 044d88d..ca98fe5 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 bb1e6d1..489a84f 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 02b2d91..e7a07de 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 0cdded3..023f7da 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: -- 2.7.4