From 4b88f6048a374e38567b794cd6ef20707007242c Mon Sep 17 00:00:00 2001 From: Vincent Penquerc'h Date: Wed, 19 Jan 2011 15:48:26 +0000 Subject: [PATCH] design docs: fix a few typos and a thinko --- docs/design/part-block.txt | 2 +- docs/design/part-bufferlist.txt | 2 +- docs/design/part-clocks.txt | 2 +- docs/design/part-element-sink.txt | 2 +- docs/design/part-overview.txt | 6 +++--- docs/design/part-preroll.txt | 2 +- docs/design/part-push-pull.txt | 2 +- docs/design/part-scheduling.txt | 6 +++--- docs/design/part-seeking.txt | 12 ++++++------ docs/design/part-segments.txt | 2 +- docs/design/part-states.txt | 8 ++++---- docs/design/part-streams.txt | 4 ++-- docs/design/part-synchronisation.txt | 2 +- 13 files changed, 26 insertions(+), 26 deletions(-) diff --git a/docs/design/part-block.txt b/docs/design/part-block.txt index 5a1cf80680..6a028b18f2 100644 --- a/docs/design/part-block.txt +++ b/docs/design/part-block.txt @@ -38,7 +38,7 @@ is called or the sync block returned) no data is flowing in elem2.sink. In this situation, the streaming thread is blocked on a GCond and is waiting to be unblocked. -When sending a flushing seek upstream on elem1.src, the FLUSH_START and +When sending a flushing seek upstream on elem1.src, the FLUSH_START event will temporary unblock the streaming thread and make all pad functions that triggers a block (_push/_alloc_buffer/_push_event/_pull_range) return GST_FLOW_WRONG_STATE. This will then eventually pause the streaming thread diff --git a/docs/design/part-bufferlist.txt b/docs/design/part-bufferlist.txt index 91674509ac..d8857814fc 100644 --- a/docs/design/part-bufferlist.txt +++ b/docs/design/part-bufferlist.txt @@ -14,7 +14,7 @@ organized in a list) to be treated as a multiple groups of GstBuffers. This allo for the following extra functionality: - A logical GstBuffer (called a group) can consist of disjoint memory each with - their own copy/free and metadata. Logicallty the group should be treated as + their own copy/free and metadata. Logically the group should be treated as one single GstBuffer. - Multiple groups can be put into one bufferlist. This allows for a single method call to pass multiple (logical) buffers downstream. diff --git a/docs/design/part-clocks.txt b/docs/design/part-clocks.txt index 5f080c5d9a..2345e4d616 100644 --- a/docs/design/part-clocks.txt +++ b/docs/design/part-clocks.txt @@ -5,7 +5,7 @@ The GstClock returns a monotonically increasing time with the method _get_time(). Its accuracy and base time depends on the specific clock implementation but time is always expessed in nanoseconds. Since the baseline of the clock is undefined, the clock time returned is not -meaningfull in itself, what matters are the deltas between two clock +meaningful in itself, what matters are the deltas between two clock times. The time reported by the clock is called the absolute_time. diff --git a/docs/design/part-element-sink.txt b/docs/design/part-element-sink.txt index edc8dd4d5b..b04f1419e7 100644 --- a/docs/design/part-element-sink.txt +++ b/docs/design/part-element-sink.txt @@ -3,7 +3,7 @@ Sink elements Sink elements consume data. They normally have no source pads. -typical sink elements include: +Typical sink elements include: - audio/video renderers - network sinks diff --git a/docs/design/part-overview.txt b/docs/design/part-overview.txt index d45e8b07a3..e292150972 100644 --- a/docs/design/part-overview.txt +++ b/docs/design/part-overview.txt @@ -53,7 +53,7 @@ The task of the application is to construct a pipeline as above using existing elements. This is further explained in the pipeline building topic. The application does not have to manage any of the complexities of the -actual dataflow/decoding/conversions/synchronsiation etc. but only calls high +actual dataflow/decoding/conversions/synchronisation etc. but only calls high level functions on the pipeline object such as PLAY/PAUSE/STOP. The application also receives messages and notifications from the pipeline such @@ -249,7 +249,7 @@ Dataflow and events Parallel to the dataflow is a flow of events. Unlike the buffers, events can pass both upstream and downstream. Some events only travel upstream others only downstream. -the events are used to denote special conditions in the dataflow such as EOS or +The events are used to denote special conditions in the dataflow such as EOS or to inform plugins of special events such as flushing or seeking. Some events must be serialized with the buffer flow, others don't. Serialized @@ -491,7 +491,7 @@ element performs the following steps. 5) send NEWSEGMENT event to inform all elements of the new position and to complete the seek. -In step 1) all dowstream elements have to return from any blocking operations +In step 1) all downstream elements have to return from any blocking operations and have to refuse any further buffers or events different from a FLUSH done. The first step ensures that the streaming thread eventually unblocks and that diff --git a/docs/design/part-preroll.txt b/docs/design/part-preroll.txt index 264492d0b9..4ecd78f1c2 100644 --- a/docs/design/part-preroll.txt +++ b/docs/design/part-preroll.txt @@ -6,7 +6,7 @@ has been queued on the input pad or pads. This process is called prerolling and is needed to fill the pipeline with buffers so that the transition to PLAYING goes as fast as possible with no visual delay for the user. -Preroll is also crucial in maintaining correct audio and video synchronsation +Preroll is also crucial in maintaining correct audio and video synchronisation and ensuring that no buffers are dropped in the sinks. After receiving a buffer (or EOS) on a pad the chain/event function should diff --git a/docs/design/part-push-pull.txt b/docs/design/part-push-pull.txt index 29e415d3ff..549f8d700b 100644 --- a/docs/design/part-push-pull.txt +++ b/docs/design/part-push-pull.txt @@ -8,7 +8,7 @@ driving force in the pipeline as it initiates data transport. It is also possible for an element to pull data from an upstream element. The downstream element does this by calling gst_pad_pull_range() on one -of its sinkpads. In this mode, the upstream element is the driving force +of its sinkpads. In this mode, the downstream element is the driving force in the pipeline as it initiates data transfer. It is important that the elements are in the correct state to handle a diff --git a/docs/design/part-scheduling.txt b/docs/design/part-scheduling.txt index 3b8a00928a..3e1734095f 100644 --- a/docs/design/part-scheduling.txt +++ b/docs/design/part-scheduling.txt @@ -33,7 +33,7 @@ push function to push the result to the peer sinkpad. Deciding the scheduling mode ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -When tha pad is activated, the _activate() function is called. The pad can then +When a pad is activated, the _activate() function is called. The pad can then choose to activate itself in push or pull mode depending on upstream capabilities. @@ -43,13 +43,13 @@ activate function for the pad. The chain function ~~~~~~~~~~~~~~~~~~ -The chain function will be called when a upstream element perform a _push() on the pad. +The chain function will be called when a upstream element performs a _push() on the pad. The upstream element can be another chain based element or a pushing source. The getrange function ~~~~~~~~~~~~~~~~~~~~~ -The getrange function is called when a peer pad perform a _pull_range() on the pad. This +The getrange function is called when a peer pad performs a _pull_range() on the pad. This downstream pad can be a pulling element or another _pull_range() based element. Plug-in techniques diff --git a/docs/design/part-seeking.txt b/docs/design/part-seeking.txt index 699a8212b7..8fddb91f3f 100644 --- a/docs/design/part-seeking.txt +++ b/docs/design/part-seeking.txt @@ -11,15 +11,15 @@ pipeline. Sending the seek event to a bin will by default forward the event to all sinks in the bin. When performing a seek, the start and stop values of the segment can be -specified as absoulte positions or relative to the currently configured +specified as absolute positions or relative to the currently configured playback segment. Note that it is not possible to seek relative to the current playback position. To seek relative to the current playback position, one must query the position first and then perform an absolute seek to the desired position. -Feedback of the seek operation can be immediatly using the GST_SEEK_FLAG_FLUSH +Feedback of the seek operation can be immediately using the GST_SEEK_FLAG_FLUSH flag. With this flag, all pending data in the pipeline is discarded and playback -starts from the new position immediatly. +starts from the new position immediately. When the FLUSH flag is not set, the seek will be queued and executed as soon as possible, which might be after all queues are emptied. @@ -47,7 +47,7 @@ application has some time to issue a new seek to make the transition seamless. Typically the allowed delay is defined by the buffer sizes of the sinks as well as the size of any queues in the pipeline. -The seek can also change the playback speed of the configured segment. +The seek can also change the playback speed of the configured segment. A speed of 1.0 is normal speed, 2.0 is double speed. Negative values mean backward playback. @@ -83,8 +83,8 @@ FLUSH seeking ^^^^^^^^^^^^^ This is the most common way of performing a seek in a playback application. -The application issues a seek on the pipeline and the new media is immediatly -played after the seek calls returns. +The application issues a seek on the pipeline and the new media is immediately +played after the seek call returns. seeking without FLUSH diff --git a/docs/design/part-segments.txt b/docs/design/part-segments.txt index 2dfbbb068f..d5b7e76826 100644 --- a/docs/design/part-segments.txt +++ b/docs/design/part-segments.txt @@ -80,7 +80,7 @@ Use case: FLUSHING seek synchronisation and position reporting. Since after a flushing seek the stream_time is reset to 0, the new buffer - will be rendered immediatly after the seek and the current_position will be + will be rendered immediately after the seek and the current_position will be the stream_time of the seek that was performed. The stop time is important when the video format contains B frames. The diff --git a/docs/design/part-states.txt b/docs/design/part-states.txt index ef1bbe5bc4..a4fec29406 100644 --- a/docs/design/part-states.txt +++ b/docs/design/part-states.txt @@ -48,7 +48,7 @@ the following state changes are possible: PAUSED -> PLAYING - Most elements ignore this state change. - The pipeline selects a clock and distributes this to all the children - before setting them to PLAYING. This means that it is only alowed to + before setting them to PLAYING. This means that it is only allowed to synchronize on the clock in the PLAYING state. - The pipeline uses the clock and the running_time to calculate the base_time. The base_time is distributed to all children when performing the state @@ -113,7 +113,7 @@ _set_state(), called the STATE_LOCK. Setting state on elements ~~~~~~~~~~~~~~~~~~~~~~~~~ -The state of an element can be changed with _element_set_state(). When chaning +The state of an element can be changed with _element_set_state(). When changing the state of an element all intermediate states will also be set on the element until the final desired state is set. @@ -125,7 +125,7 @@ The _set_state() function can return 3 possible values: GST_STATE_SUCCESS: The state change is completed successfully. GST_STATE_ASYNC: The state change will complete later on. This can happen - When the element needs a long time to perform the state + when the element needs a long time to perform the state change or for sinks that need to receive the first buffer before they can complete the state change (preroll). @@ -143,7 +143,7 @@ When setting the state of an element, the STATE_PENDING is set to the required state. Then the state change function of the element is called and the result of that function is used to update the STATE and STATE_RETURN fields, STATE_NEXT, STATE_PENDING and STATE_RETURN fields. If the function returned ASYNC, this result -is immediatly returned to the caller. +is immediately returned to the caller. Getting state of elements diff --git a/docs/design/part-streams.txt b/docs/design/part-streams.txt index 0a4fbb5a38..1274ae01cb 100644 --- a/docs/design/part-streams.txt +++ b/docs/design/part-streams.txt @@ -24,9 +24,9 @@ Typical stream ~~~~~~~~~~~~~~ A typical stream starts with a newsegment event that marks the - buffer timestamp range. After that buffers are send one after the + buffer timestamp range. After that buffers are sent one after the other. After the last buffer an EOS marks the end of the stream. No - more buffer are to be processed after the EOS event. + more buffers are to be processed after the EOS event. +--+ +-++-+ +-+ +---+ |NS| |B||B| ... |B| |EOS| diff --git a/docs/design/part-synchronisation.txt b/docs/design/part-synchronisation.txt index 2c3185b54e..07d87c8a10 100644 --- a/docs/design/part-synchronisation.txt +++ b/docs/design/part-synchronisation.txt @@ -55,7 +55,7 @@ to PAUSED and restores this time based on the current absolute_time when going back to PLAYING. This allows for both clocks that progress when in the PAUSED state (systemclock) and clocks that don't (audioclock). -The clock and pipeline now provides a running_time to all elements that want to +The clock and pipeline now provide a running_time to all elements that want to perform synchronisation. Indeed, the running time can be observed in each element (during the PLAYING state) as: