docs: fix common typos emited/eachother/...

7 files changed, 17 insertions, 17 deletions

diff --git a/docs/design/part-MT-refcounting.txt b/docs/design/part-MT-refcounting.txt
index 16f3843af..c4919b91b 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 2afe8c160..5dfa9b12c 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 6e81b5a6a..e6b41f90c 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 7e5ecb887..0e68e9697 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 023f7da55..7c08dbb95 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 d6234ea25..26ff826cf 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 eb38296cf..08cc6d089 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.