docs, gst: typo fixes

https://bugzilla.gnome.org/show_bug.cgi?id=658449

29 files changed, 39 insertions, 39 deletions

diff --git a/docs/random/autoplug2 b/docs/random/autoplug2
index 1c727973b..22df0ca7d 100644
--- a/docs/random/autoplug2
+++ b/docs/random/autoplug2
@@ -43,7 +43,7 @@ provided by various plugins.
 
 We will create a little pipeline to detect the media type by connecting
 a disksrc element to a typefind element. The typefind element will 
-repeadedly call all registered typefind functions with the buffer it 
+repeatedly call all registered typefind functions with the buffer it
 receives on its sink pad. when a typefind function returns a non NULL
 GstCaps*, that caps is set to the sink pad of the typefind element and
 a signal is emitted to notify the app.
@@ -195,7 +195,7 @@ for the second sink the following is needed:
 
 Note that for the audio connection the element list "mpeg1parse, mp3parse,
 mpg123" would also connect the srccaps to the audiosink caps. Since the
-"mpeg1parse, mad" list is shorter, it it always prefered by the autoplugger.
+"mpeg1parse, mad" list is shorter, it it always preferred by the autoplugger.
 
 We now have two lists of elementfactories.
 
diff --git a/docs/random/bbb/optional-properties b/docs/random/bbb/optional-properties
index f6471a045..e1220ad35 100644
--- a/docs/random/bbb/optional-properties
+++ b/docs/random/bbb/optional-properties
@@ -54,7 +54,7 @@ aligned video) and pixel-aspect-ratio (default value being 1/1). Adding p-a-r
 was in this case an example of 2bII, whereas stride is 2bI. The reason for
 this is simple: adding pixel-aspect-ratio to some element and not to others
 could lead to misunderstanding size. However, this is not a regression,
-because not adding it alltogether would lead to the same misunderstanding.
+because not adding it altogether would lead to the same misunderstanding.
 In both cases, the result would be wrongly sized video. Therefore, there
 is no regression and there is a bugfix, so this is fine. Obviously, the
 optional property is in this case very specifically a temporary solution.
diff --git a/docs/random/bbb/streamselection b/docs/random/bbb/streamselection
index 9c265499f..b89a5a55d 100644
--- a/docs/random/bbb/streamselection
+++ b/docs/random/bbb/streamselection
@@ -4,13 +4,13 @@ Stream selection
 1. Problem
 URIs (that being either a media stream or a media stream plus subtitle) can
 contain multiple streams of a type (audio, subtitle). A user has to be given
-the option of selecting one of those streams (or none alltogether).
+the option of selecting one of those streams (or none altogether).
 
 2. Implementation ideas
 Stream selection, in GStreamer, has to be integrated at the player plugging
 level, which is (in the case of Totem) playbin. Playbin offers a feature to
 'mute' a stream (which means that no processing is done on that stream
-alltogether, saving the decoding step). Currently, playbin will select the
+altogether, saving the decoding step). Currently, playbin will select the
 first occurrence of a stream type and mute all others. A queue is connected
 (for pre-roll) to the active stream. What is missing here is a way to change
 the active stream.
@@ -30,7 +30,7 @@ stream was linked. Alternatively, a switch-like element is used, which
 requires no replugging. Pad disabling/enabling is then enough. This also
 makes relinking less painful. The switch-like element needs to proxy the
 active pads' caps. However, since those caps are (in practice) always the
-same accross streams, caps setting will (inside the core) immediately
+same across streams, caps setting will (inside the core) immediately
 return success.
 The switch-like element simply works like this:
 =
diff --git a/docs/random/caps b/docs/random/caps
index bbcca9b7c..d994bcddf 100644
--- a/docs/random/caps
+++ b/docs/random/caps
@@ -162,7 +162,7 @@ As with option2, a global plan will be built. At runtime the src pads
 will actually specify the capabilities they need for any element that
 wants to be connected to its source pads.
 
-In this case we specifiy the capabilities for all the sink pads of an
+In this case we specify the capabilities for all the sink pads of an
 element at create time. The capabilities of the src pads would only
 become available when data has been processed by the element.
 
diff --git a/docs/random/company/gvadec.txt b/docs/random/company/gvadec.txt
index c621361af..7f8cb87c3 100644
--- a/docs/random/company/gvadec.txt
+++ b/docs/random/company/gvadec.txt
@@ -209,7 +209,7 @@ for themselves - most of the time depending on caps on other pads in the
 element. The core then takes those, intersects them and if the intersection
 isn't empty fixates them. Fixation is a process that selects the best possible
 fixed caps from a caps. A fixed caps is a caps that describes only one format
-and cannot be reduced further. After both pads acdepted the fixed caps, its
+and cannot be reduced further. After both pads accepted the fixed caps, its
 format is then used to describe the contents of the buffers that are passed on
 this link. Caps can be serialized and deserialized to a string representation.
 [Add: a medium complex caps description (audioconvert?)]
diff --git a/docs/random/ensonic/draft-bufferpools.txt b/docs/random/ensonic/draft-bufferpools.txt
index e03669ba2..384c5ed4f 100644
--- a/docs/random/ensonic/draft-bufferpools.txt
+++ b/docs/random/ensonic/draft-bufferpools.txt
@@ -39,7 +39,7 @@ What is needed
 
 Elements that sink raw data buffers of usualy constant size would like to 
 maintain a bufferpool. These could be sinks or encoders. We need mechanims to
-select and dynamicaly update:
+select and dynamically update:
 
   - the bufferpool owners in a pipeline
   - the bufferpool sizes
diff --git a/docs/random/ensonic/embedded.txt b/docs/random/ensonic/embedded.txt
index 8011054fa..a3875cbe4 100644
--- a/docs/random/ensonic/embedded.txt
+++ b/docs/random/ensonic/embedded.txt
@@ -21,7 +21,7 @@ encapsulated in the indexer strategy.
 Autopluggers like playbin and decodebin use the element caps plus static ranks
 to create piplines.
 The rank of an elemnt right now refers to the quality/maturity of the element.
-Elements with higher rank should be functionaly more complete. If we have
+Elements with higher rank should be functionally more complete. If we have
 multiple elements that are feature complete there is a draw.
 
 There are more decission criteria thinkable:
diff --git a/docs/random/ensonic/media-device-daemon.txt b/docs/random/ensonic/media-device-daemon.txt
index ffbe081e3..d16ee0bb6 100644
--- a/docs/random/ensonic/media-device-daemon.txt
+++ b/docs/random/ensonic/media-device-daemon.txt
@@ -38,5 +38,5 @@ components
       channelstrip
   - state-control (play, pause/mute)
     - it would be useful if one app could pause/mute others
-    - think of a voip-client, if there is an incomming call, if pauses your
+    - think of a voip-client, if there is an incoming call, if pauses your
       media-player, or mutes the monitoring of your recording app
diff --git a/docs/random/ensonic/plugindocs.txt b/docs/random/ensonic/plugindocs.txt
index 3317eb70f..987fc6811 100644
--- a/docs/random/ensonic/plugindocs.txt
+++ b/docs/random/ensonic/plugindocs.txt
@@ -33,7 +33,7 @@ Details
 ------------------
 - read data from inspect/plugin-<pluginname>.xml
 - insert/overwrite "Short Description" and "Long Description" in tmpl/
-- the "Long Description" contains a <xi:inlcude> for xml/element-<name>-details.xml
+- the "Long Description" contains a <xi:include> for xml/element-<name>-details.xml
 
 3.) common/plugins.xsl
 ----------------------
diff --git a/docs/random/ensonic/profiling.txt b/docs/random/ensonic/profiling.txt
index cb11475fd..207f3ba68 100644
--- a/docs/random/ensonic/profiling.txt
+++ b/docs/random/ensonic/profiling.txt
@@ -89,7 +89,7 @@ $Id$
 
 = PerformanceMonitor =
 Write a ld-preload lib that can gather data from gstreamer and logs it to files.
-The idea is not avoid adding API for performance meassurement to gstreamer.
+The idea is not avoid adding API for performance measurement to gstreamer.
 
 == Services ==
 library provides some common services used by the sensor modules.
@@ -97,7 +97,7 @@ library provides some common services used by the sensor modules.
 * timestamps
 
 == Sensors ==
-Sensors do meassurements and deliver timestampe performance data.
+Sensors do measurements and deliver timestampe performance data.
 * bitrates and latency via gst_pad_push/pull per link
 * qos ratio via gst_event_new_qos(), gst_pad_send_event()
 * cpu/mem via get_rusage
@@ -125,7 +125,7 @@ timestamp [qos-ratio] [cpu-load={sum,17284,17285}]
 ** should we have the log config in the header or in some separate config?
    - if config, we just specify the config when capturing put that
      in the first log line
-   - otheriwse the analyzer ui has to parse it from the first line
+   - otherwise the analyzer ui has to parse it from the first line
 
 == Running ==
 LD_PRELOAD=libgstperfmon.so GST_PERFMON_DETAILS="qos-ratio,cpu-load=all" <application>
diff --git a/docs/random/eos b/docs/random/eos
index a5517270f..b4d259f6a 100644
--- a/docs/random/eos
+++ b/docs/random/eos
@@ -82,12 +82,12 @@ case 3)
   the eos handler returns false because both queues return false on the
   eos request. the parent removes fakesrc as an EOS provider.
 
-  queue1 and queue2 were responisble for the EOS delay and so they get
+  queue1 and queue2 were responsible for the EOS delay and so they get
   added to the bin as possible EOS providers.
 
   after the queues have sent out their last buffer, they calls eos on their
   src pads.
-  the parent allready has the two queues in the EOS provider list so they dont
+  the parent already has the two queues in the EOS provider list so they dont
   get added twice.
   the two queues perform gst_pad_eos () on their pads when the queue is empty,
   the parent removes the EOS providers from its list, when the list is empty,
@@ -122,12 +122,12 @@ case 4)
   the eos handler returns false because queue2 returns false on the
   eos request. the parent removes fakesrc as an EOS provider.
 
-  queue2 was responisble for the EOS delay and so it gets added to the bin 
+  queue2 was responsible for the EOS delay and so it gets added to the bin
   as a possible EOS provider.
 
   after the queue2 has sent its last buffer, it performs gst_pad_eos on its
   src pad.
-  the parent allready has the queue2 in the list of EOS providers so it does not
+  the parent already has the queue2 in the list of EOS providers so it does not
   get added twice.
   queue2 finally fires the EOS signal and the parent removes the EOS provider 
   from its list, when the list is empty, the parent fires EOS.
diff --git a/docs/random/hierarchy b/docs/random/hierarchy
index c4e03ba40..a07f8b867 100644
--- a/docs/random/hierarchy
+++ b/docs/random/hierarchy
@@ -12,7 +12,7 @@ better layout for it now. Some things to consider:
  - The plugins can be grouped together by the media type they
    operate on or by the way they work (decoder/encoder)
    
-In GStreamer all plugins are techically filters, the only way they
+In GStreamer all plugins are technically filters, the only way they
 can be considered sources or sinks (input/output) elements is
 by the absence of src/sink pads. At first sight the source/filter/
 sink distinction is quite useless because most of the plugins
diff --git a/docs/random/i18n b/docs/random/i18n
index cca722e72..fb5e7c6fa 100644
--- a/docs/random/i18n
+++ b/docs/random/i18n
@@ -10,7 +10,7 @@ Internationalization notes
   - should only use bindtextdomain to tie a domain to a locale dir
   - use dgettext (possibly disguised as _) to translate from a set domain
 
-- How to make your plug-in code translateable:
+- How to make your plug-in code translatable:
   - include <gst/gst-i18n-plugin.h> in all files that mark strings for
     translation, or do the bindtextdomain call
   - in plugin_init, add a block like this:
diff --git a/docs/random/interfaces b/docs/random/interfaces
index 7d6515fa4..d4d473b42 100644
--- a/docs/random/interfaces
+++ b/docs/random/interfaces
@@ -311,7 +311,7 @@ That's all! It would look similar for FB & co.
 4c) user input
 --------------
 And yes, user input could be an interface too. Even better, it
-should definately be. And wasn't this one of our key issues for
+should definitely be. And wasn't this one of our key issues for
 0.8.0?
 
 No code here. Go implement it, lazy ass!
diff --git a/docs/random/negotiation b/docs/random/negotiation
index 54bfa3136..5d3decad8 100644
--- a/docs/random/negotiation
+++ b/docs/random/negotiation
@@ -155,7 +155,7 @@ Notes for converters:
      structure, perform whatever other setup is necessary for your
      element, and return GST_PAD_LINK_OK.
 
-   - Otherwise, you're not not using passthrough, and may need to
+   - Otherwise, you're not using passthrough, and may need to
      change the caps on the otherpad to match the given format.
 
    - If the otherpad is not negotiated (!gst_pad_is_negotiated()),
diff --git a/docs/random/omega/sched/chains b/docs/random/omega/sched/chains
index 0ecee297f..69af945fe 100644
--- a/docs/random/omega/sched/chains
+++ b/docs/random/omega/sched/chains
@@ -71,7 +71,7 @@ both entries is hard, because the idea at this point is that there's only a sing
 Does this mean that we should make mix a DECOUPLED element?  That would fix it to some extent, giving us three chains 
 in the above case.  Each eq chain would be driven by the eq element, pulling from the queue and pushing into the mixer.  
 The mixer -> queue chain is problematic, because there is no possibly entry.  The mixer side has no _get function 
-(since the push always happens upon the receipt of a buffer from the second sink pad), which means that that those two 
+(since the push always happens upon the receipt of a buffer from the second sink pad), which means that those two
 pads have no possible entrance.
 
 Cothreads make this case much easier, since the mix element would drive things, forcing the eq elements to pull and 
diff --git a/docs/random/omega/testing/framework b/docs/random/omega/testing/framework
index b6c7a42f3..4ef4519fc 100644
--- a/docs/random/omega/testing/framework
+++ b/docs/random/omega/testing/framework
@@ -26,7 +26,7 @@ preconditions:
 	nothing
 action:
 	curparent = gst_element_get_parent(object);
-validaton:
+validation:
 	curparent == object->parent
 	curparent == parent
 cleanup:
diff --git a/docs/random/plugins b/docs/random/plugins
index 2bf695a3c..ed1630ba1 100644
--- a/docs/random/plugins
+++ b/docs/random/plugins
@@ -65,7 +65,7 @@ We will have the following methods for (implicitly) loading plugins:
 
  gst_plugin_load (name)
 
-  The plugin will be located in the tree and if it allready loaded, the
+  The plugin will be located in the tree and if it already loaded, the
   function returns. If it is not loaded, the XML entry is removed and
   the plugin is loaded. The plugin_init is called so that the XML tree
   is reconstructed.
@@ -73,7 +73,7 @@ We will have the following methods for (implicitly) loading plugins:
  gst_elementfactory_create (factory, name);
 
   The plugin providing the element will be located, if the plugin is
-  allready loaded, an element with the given name is created.
+  already loaded, an element with the given name is created.
   if the plugin is not loaded, gst_plugin_load is called.
   the loaded factory is located again and the element is created.
 
diff --git a/docs/random/rtp b/docs/random/rtp
index 2d3b6a59d..d7b6098c3 100644
--- a/docs/random/rtp
+++ b/docs/random/rtp
@@ -5,7 +5,7 @@ A brief description of the RTP protocol.
 
 The RTP protocol uses two connections: one for passing data and another for control. The control connection is used for starting, finishing, and passing statistics of lost packets. On the data connection, packets are transmitted containing the media. These packets have a 7 bit field that says what codec is the data transmitted with. This codec is variable. However data cannot change from audio to video in packets of the same connection. All the packets belong to the same logical stream, that is, for instanace, to the same speech, or to the same song. Different codecs in the same stream is used, for instance, to insert comfort noise.
 
-Each codec is packeted in a specific way in RTP packets. This is necessary to minimize the damage produced by lost packets. Therefore, packets should be arranged so that each packet can be decoded independently. If a packet is lost, that shoudn't preclude the decoding of following packets.
+Each codec is packeted in a specific way in RTP packets. This is necessary to minimize the damage produced by lost packets. Therefore, packets should be arranged so that each packet can be decoded independently. If a packet is lost, that shouldn't preclude the decoding of following packets.
 
 
 Suggested implementation:
@@ -38,7 +38,7 @@ Ronald suggested to use inheritance. Thus the user should insert a codec specifi
 
 udpsrc ! rtp-mp3 ! mp3decode ! osssink
 
-Reuse of RTP logic would be achived through inhertiance. 
+Reuse of RTP logic would be achieved through inheritance.
 
 This looks more logical, because inheritance reflects the fact that rtp-mp3 "is an" specialization of rtp. However, there are several issues. As stated above, it is posible in RTP to switch the encoding of the media at any time. If this happens, some state must be kept, such as statistics of packets received and sent. 
 
diff --git a/docs/random/slomo/controller.txt b/docs/random/slomo/controller.txt
index 68c2c0ca5..d814a916a 100644
--- a/docs/random/slomo/controller.txt
+++ b/docs/random/slomo/controller.txt
@@ -6,7 +6,7 @@ Implementation:
 
 Ideas and plans:
   - Deprecate control-rate property and add a control-period property
-    that does the same and is named appropiately. Damn confusing names.
+    that does the same and is named appropriately. Damn confusing names.
 
   - gst_object_suggest_next_sync() will not be used at all anymore.
     Note this in the docs and explain correct usage in elements.
diff --git a/docs/random/sources b/docs/random/sources
index 2876c5826..3e5c46622 100644
--- a/docs/random/sources
+++ b/docs/random/sources
@@ -266,7 +266,7 @@ Chained:
        -
 
 As usual, is likely to be an entry into a Bin.  The Bin iterate code must
-explicitely pull a buffer and pass it on to the peer. 
+explicitly pull a buffer and pass it on to the peer.
 
 Cothreaded: 
 
diff --git a/docs/random/streamheader b/docs/random/streamheader
index 6d4b3d3aa..612780d42 100644
--- a/docs/random/streamheader
+++ b/docs/random/streamheader
@@ -2,7 +2,7 @@ A lot of data streams need a few initial buffers to make sense of the
 data stream.  With these initial buffers, it can pick up at any point in
 the rest of the data stream.
 
-Exampes:
+Examples:
 - Vorbis and Theora have three initial Ogg packets
 - MPEG4 has codec data
 - GDP protocol serializes the initial new_segment event and the initial caps
diff --git a/docs/random/testing/syntax b/docs/random/testing/syntax
index 3e6c6f734..f66c12631 100644
--- a/docs/random/testing/syntax
+++ b/docs/random/testing/syntax
@@ -22,7 +22,7 @@ tcS: id2, element, signalname
 ...
 tcI: the number of iterations on the top bin 
 tcT: a timeout value in mSecs
-tcR: id1,1,id2,1,.. (the pattern of signals trigered)
+tcR: id1,1,id2,1,.. (the pattern of signals triggered)
 or 
 tcR: id1==id2,... (denote an equal number of signals)
 /n
diff --git a/docs/random/types2 b/docs/random/types2
index b9b8c5a0e..4801707c2 100644
--- a/docs/random/types2
+++ b/docs/random/types2
@@ -97,7 +97,7 @@ the equivalence of both types, even it they have a different mime type.
 5. type hierarchy
 -----------------
 
-some plugins can ouput a specific subset of an allready existing type.
+some plugins can ouput a specific subset of an already existing type.
 
 example:
 
diff --git a/docs/random/uraeus/gstreamer_and_midi.txt b/docs/random/uraeus/gstreamer_and_midi.txt
index 4631d58ef..51f4b066f 100644
--- a/docs/random/uraeus/gstreamer_and_midi.txt
+++ b/docs/random/uraeus/gstreamer_and_midi.txt
@@ -234,7 +234,7 @@ otherwise it can stay in individial projects.
 On using dparams for MIDI
 -------------------------
 
-You might might want to look into using dparams if:
+You might want to look into using dparams if:
 
 - you wanted your control parameters to change at a higher rate thanyour buffer
   rate (think zipper noise and sample-granularity-interpolation)
diff --git a/docs/random/vis-transform b/docs/random/vis-transform
index a83e7c01d..aa80a535b 100644
--- a/docs/random/vis-transform
+++ b/docs/random/vis-transform
@@ -26,7 +26,7 @@ unless they're 1/2^n, and even then it's significantly heavier (you'd have
 to mask the top n bits of each color out).
 
 This SCREAMS for MMX, in case you haven't figured it out yet.
-Unfortunatley, MMX is only directly useful for the scalar matrix, unless
+Unfortunately, MMX is only directly useful for the scalar matrix, unless
 you do a trick where all the pixels in that fit in 64 bits (8 8bit, 4
 16bit, or 2 32bit) are always moved in a group.  This is very possible,
 and might be a significant perf increase by being able to use MMX all the
diff --git a/docs/random/wtay/caps-negociation b/docs/random/wtay/caps-negociation
index c4df59970..b3122b10c 100644
--- a/docs/random/wtay/caps-negociation
+++ b/docs/random/wtay/caps-negociation
@@ -193,7 +193,7 @@ of the pads negotiation functions returns the caps unmodified.
 
 The element can also return a NULL pointer if it has run out of
 options for the caps structure. When this happens, both pads are set
-the the NULL caps again and the pad connnection is broken.
+the NULL caps again and the pad connnection is broken.
 
 The negotiation process is stopped after a fixed number of tries,
 when the counter has reached some limit. This limit is typically
diff --git a/docs/random/wtay/threading b/docs/random/wtay/threading
index c30f895cf..114be3955 100644
--- a/docs/random/wtay/threading
+++ b/docs/random/wtay/threading
@@ -323,7 +323,7 @@ Fixing Threading
      
      When performing a state change on an element that returns ASYNC on one of
      the state changes, ASYNC is returned and you can only proceed to the next
-     state change change when this ASYNC state change completed. Use the
+     state change when this ASYNC state change completed. Use the
      gst_element_get_state function to know when the state change completed.
      An example of this behaviour is setting a videosink to PLAYING, it will
      return ASYNC in the state change from READY->PAUSED. You can only set
diff --git a/docs/random/wtay/threads_hilevel b/docs/random/wtay/threads_hilevel
index f8eb9e35a..5a38eeea7 100644
--- a/docs/random/wtay/threads_hilevel
+++ b/docs/random/wtay/threads_hilevel
@@ -168,5 +168,5 @@ TODO
 ----
 
 - review
-- figure all all state change scenarios occuring in code marked with (*)
+- figure all state change scenarios occuring in code marked with (*)