From a3431f5d8ba4419366e5bc570e2a7dc5b75ba49b Mon Sep 17 00:00:00 2001 From: "Reynaldo H. Verdejo Pinochet" Date: Thu, 31 Oct 2013 16:16:48 -0700 Subject: [PATCH] docs: fix common typos emited/eachother/... --- docs/design/part-MT-refcounting.txt | 2 +- docs/design/part-element-transform.txt | 10 +++++----- docs/design/part-events.txt | 4 ++-- docs/design/part-framestep.txt | 8 ++++---- docs/design/part-messages.txt | 2 +- docs/design/part-probes.txt | 2 +- docs/design/part-relations.txt | 6 +++--- 7 files changed, 17 insertions(+), 17 deletions(-) diff --git a/docs/design/part-MT-refcounting.txt b/docs/design/part-MT-refcounting.txt index 16f3843..c4919b9 100644 --- a/docs/design/part-MT-refcounting.txt +++ b/docs/design/part-MT-refcounting.txt @@ -41,7 +41,7 @@ Shared data structures and writability: decrease the refcount. Each thread having a refcount to the object can safely read from the object. - but modifications made to the object should be preceeded with a + but modifications made to the object should be preceded with a _get_writable() function call. This function will check the refcount of the object and if the object is referenced by more than one instance, a copy is made of the object that is then by definition only referenced from the calling diff --git a/docs/design/part-element-transform.txt b/docs/design/part-element-transform.txt index 2afe8c1..5dfa9b1 100644 --- a/docs/design/part-element-transform.txt +++ b/docs/design/part-element-transform.txt @@ -4,17 +4,17 @@ Transform elements Transform elements transform input buffers to output buffers based on the sink and source caps. -An important requirement for a transform is that the ouput caps are completely +An important requirement for a transform is that the output caps are completely defined by the input caps and vice versa. This means that a typical decoder element can NOT be implemented with a transform element, this is because the -output caps like width and height of the decompessed video frame, for example, -are endcoded in the stream and thus not defined by the input caps. +output caps like width and height of the decompressed video frame, for example, +are encoded in the stream and thus not defined by the input caps. Typical transform elements include: - audio convertors (audioconvert, audioresample,...) - video convertors (colorspace, videoscale, ...) - - filters (capfilter, volume, colorbalance, ...) + - filters (capsfilter, volume, colorbalance, ...) The implementation of the transform element has to take care of the following things: @@ -299,7 +299,7 @@ retrieve the size. There are two functions: - get_unit_size() - When the input size and output size are always a multiple of eachother + When the input size and output size are always a multiple of each other (audio conversion, ..) we can define a more simple get_unit_size() function. The transform will use this function to get the same amount of units in the source and destination buffers. diff --git a/docs/design/part-events.txt b/docs/design/part-events.txt index 6e81b5a..e6b41f9 100644 --- a/docs/design/part-events.txt +++ b/docs/design/part-events.txt @@ -104,7 +104,7 @@ elements so that the running_time is reset to 0. EOS ~~~ -The EOS event can only be sent on a sinkpad. It is typically emited by the +The EOS event can only be sent on a sinkpad. It is typically emitted by the source element when it has finished sending data. This event is mainly sent in the streaming thread but can also be sent from the application thread. @@ -153,7 +153,7 @@ point for all next buffer's timestamps has to be propagated through the pipeline using the SEGMENT event. Before sending buffers, an element must send a SEGMENT event. An element is -free to refuse buffers if they were not preceeded by a SEGMENT event. +free to refuse buffers if they were not preceded by a SEGMENT event. Elements that sync to the clock should store the SEGMENT start and end values and subtract the start value from the buffer timestamp before comparing diff --git a/docs/design/part-framestep.txt b/docs/design/part-framestep.txt index 7e5ecb8..0e68e96 100644 --- a/docs/design/part-framestep.txt +++ b/docs/design/part-framestep.txt @@ -86,7 +86,7 @@ Use Cases consumed the amount of time. - sink posts STEP_DONE with amount of frames stepped and corresponding time interval. The sink will then wait for another step event. Since the - STEP_DONE message was emited by the sink when it handed off the buffer to + STEP_DONE message was emitted by the sink when it handed off the buffer to the device, there is usually sufficient time to queue a new STEP event so that one can seamlessly continue stepping. @@ -190,13 +190,13 @@ A GST_MESSAGE_STEP_START is created. It contains the following fields. "intermediate", G_TYPE_BOOLEAN If this is an intermediate step operation that queued/activated. -The STEP_START message is emited 2 times: +The STEP_START message is emitted 2 times: * first when an element received the STEP event and queued it. The "active" field will be FALSE in this case. * second when the step operation started in the streaming thread. The "active" - field is TRUE in this case. After this message is emited, the application + field is TRUE in this case. After this message is emitted, the application can queue a new step operation. The purpose of this message is to find out how many elements participate in the @@ -227,7 +227,7 @@ fields: "eos", G_TYPE_BOOLEAN The step ended because of EOS. -The message is emited by the element that performs the step operation. The +The message is emitted by the element that performs the step operation. The purpose is to return the duration in GST_FORMAT_TIME of the stepped media. This especially interesting to align other stream in case of stepping frames on the video sink element. diff --git a/docs/design/part-messages.txt b/docs/design/part-messages.txt index 023f7da..7c08dbb 100644 --- a/docs/design/part-messages.txt +++ b/docs/design/part-messages.txt @@ -46,7 +46,7 @@ GST_MESSAGE_TAG: GST_MESSAGE_BUFFERING: An element is buffering data and that could potentially take some time. This - message is typically emited by elements that perform some sort of network + message is typically emitted by elements that perform some sort of network buffering. While the pipeline is buffering it should remain in the PAUSED state. When the buffering is finished, it can resume PLAYING. diff --git a/docs/design/part-probes.txt b/docs/design/part-probes.txt index d6234ea..26ff826 100644 --- a/docs/design/part-probes.txt +++ b/docs/design/part-probes.txt @@ -309,7 +309,7 @@ any data. To do this, the source pads of the decoders is blocked so that no events or buffers can escape and we don't interrupt the stream. -When all of the dynamic pad are created (no-more-pads emited by the +When all of the dynamic pad are created (no-more-pads emitted by the branching point, ie, the demuxer or the queues filled) and the pads are blocked (blocked callback received) the pipeline is completely prerolled. diff --git a/docs/design/part-relations.txt b/docs/design/part-relations.txt index eb38296..08cc6d0 100644 --- a/docs/design/part-relations.txt +++ b/docs/design/part-relations.txt @@ -113,7 +113,7 @@ parent-child relation call _set_parent() on the children with the same parent, the parent can then add all those to its lists. - Note: that the signal is emited before the parent has added the + Note: that the signal is emitted before the parent has added the element to its internal data structures. This is not a problem since the parent usually has his own signal to inform the app that the child was reffed. One possible solution would be to update the @@ -350,7 +350,7 @@ unreffed relation - properties - - two objects have references to eachother + - two objects have references to each other - both objects can only have 1 reference to another object. - reference fields protected with LOCK - the references held by each object are NOT reflected in the @@ -475,7 +475,7 @@ double-reffed relation - properties - - two objects have references to eachother + - two objects have references to each other - reference fields protected with LOCK - the references held by each object are reflected in the refcount of the other object. -- 2.7.4