Fix typos in comments and docs

Found via `codespell` https://bugzilla.gnome.org/show_bug.cgi?id=795610
2024-12-23 08:46:40 +00:00 · 2018-04-27 12:40:31 -04:00 · 2018-04-27 12:40:31 -04:00 · 4a402c1c7d
commit 4a402c1c7d
parent bad751b22f
130 changed files with 264 additions and 264 deletions
--- a/configure.ac
+++ b/configure.ac
@ -947,7 +947,7 @@ dnl *** finalize CFLAGS, LDFLAGS, LIBS
 dnl Overview:
 dnl GST_OPTION_CFLAGS:  common cflags for profiling, debugging, errors, ...
 dnl GST_ALL_*:          vars shared by all built objects
-dnl GST_LIB_LDFLAGS:    additional linker flags for all libaries
+dnl GST_LIB_LDFLAGS:    additional linker flags for all libraries
 dnl GST_OBJ_*:          additional vars to link to the core library
 dnl			include GST_ALL_*
 dnl GST_LT_LDFLAGS:	library versioning of our libraries
--- a/docs/libs/gstreamer-libs-docs.sgml
+++ b/docs/libs/gstreamer-libs-docs.sgml
@ -27,10 +27,10 @@
    </para>

    <chapter id="gstreamer-base">
-      <title>GStreamer Base and Utillity Classes</title>
+      <title>GStreamer Base and Utility Classes</title>
      <para>
        libgstbase-&GST_API_VERSION;.so provides some base classes to be extended
-        by elements and utillity classes that are most useful for plugin developers.
+        by elements and utility classes that are most useful for plugin developers.
      </para>

      <xi:include href="xml/gstaggregator.xml" />
--- a/docs/random/TODO-pre-0.9
+++ b/docs/random/TODO-pre-0.9
@ -4,23 +4,23 @@ TODO:
 short term core API stability
 -----------------------------

-Changes that probably impact the API, carefull discussion (IRC) + design doc is required
+Changes that probably impact the API, careful discussion (IRC) + design doc is required
 before changes are accepted.

 target release ! description
               !
  0.4.1        ! expose and API to query the supported seek formats/flags on
-  (done)       ! pads, somthing like an extra arg to gst_pad_set_convert_function
+  (done)       ! pads, something like an extra arg to gst_pad_set_convert_function
               ! and gst_pad_set_event_function with some function to query the 
               ! flags and formats. more ideas in docs/random/wtay/query_events
-	       !  (API: medium dificulty)
+	       !  (API: medium difficulty)
 	       !
  0.4.1        ! add event for segment playback/looping and seeking (docs/random/wtay/segments)
-  (done)       !  (API: medium dificulty, plugins: HARD to very HARD)
+  (done)       !  (API: medium difficulty, plugins: HARD to very HARD)
 	       !
    ?          ! add event to adjust rate (reverse playback, slow motion, frame skipping)
               ! (docs/random/wtay/rate_event)
-    	       !  (API: medium dificulty, plugins: HARD to very HARD)
+	       !  (API: medium difficulty, plugins: HARD to very HARD)
 	       ! 
    ?	       ! add method in the scheduler to set the entry point (frame stepping?)
 	       ! (docs/random/wtay/scheduler_entry)
--- a/docs/random/autoplug1
+++ b/docs/random/autoplug1
@ -154,7 +154,7 @@ ex.
     the same procedure happens for the audio part. We are now left with the
     following pipeline:

-     We will also have set a signal "new_pad" on the mpeg1parse element bacause
+     We will also have set a signal "new_pad" on the mpeg1parse element because
     the element mp1videoparse could not be connected to the element just yet.

                                                 (------------------------------------)         (----------
@ -180,7 +180,7 @@ Problems:
 ---------

 this is obviously a very naive solution. the creation of the elements actually happens
-beforehand. MPEG2, for one, fails bacause there are multiple possibilities to go
+beforehand. MPEG2, for one, fails because there are multiple possibilities to go
 from the mpeg demuxer to audio/raw (ac3, mp3)

 Also any intermedia elements like mixers (subtitles) are not possible because we 
--- a/docs/random/autoplug2
+++ b/docs/random/autoplug2
@ -236,7 +236,7 @@ now we loop over all the list and try to add the remaining elements
 (HACK) we always use a new thread for the elements when there is a common
 element found.

-if a new thread is needed (either becuase the previous element is a common
+if a new thread is needed (either because the previous element is a common
 element or the object flag of the next element is set to GST_SUGGEST_THREAD)
 we add a queue to the bin and we add a new thread. We add the elements to
 the bin and connect them using gst_pipeline_pads_autoplug. 
--- a/docs/random/bbb/streamselection
+++ b/docs/random/bbb/streamselection
@ -61,7 +61,7 @@ extremely useful here, and requires little code in the switch-like
 element itself. Note that there is a slight bit of duplication in the
 playbin interface and the switch-like element interface, but that's "just
 the way it is".
-The implemention of the switch-like element could initially be local to
+The implementation of the switch-like element could initially be local to
 playbin, until it has been cleaned up and confirmed to be useful to a
 wider audience. This allows a lot of experimenting with interfaces because
 we won't be forced to maintain a stable interface.
--- a/docs/random/caps
+++ b/docs/random/caps
@ -75,7 +75,7 @@ pad capabilities.
 We call this the static case because the capabilities of the pads
 are supposed to stay the same after creating the element.

-While the ability to completly setup the pipeline before actually 
+While the ability to completely setup the pipeline before actually
 starting playback is an advantage regarding performance, one obvious
 problem with this setup is that the static case may be too static in
 some cases. We can illustrate this with the following setup:
@ -101,7 +101,7 @@ factory:
    NULL
  };

-The static autoplugger has to be carefull when connecting the mpg123
+The static autoplugger has to be careful when connecting the mpg123
 element with the audiosink because it is theoretically possible that
 the mpg123 element outputs raw audio with a rate that cannot be
 handled by the audiosink (ex. 4000KHz). In the absence of another
@ -128,7 +128,7 @@ An element would still list its mime type using:
  gst_pad_add_type_id(mpg123->sinkpad, mp3type);

 The idea would then be that a rough draft of the pipeline would be
-built afer the media type of the stream has been detected with the
+built after the media type of the stream has been detected with the
 typefind functions. The rough draft would consist of laying out a
 global plan to reach the renderer(s). this plan would basically list
 the set of conversions that have to be performed. (mime-type to
@ -138,7 +138,7 @@ Elements that accept the src mime-type are tried by giving it a buffer.
 If the element accepts the buffer, it will set its capabilities for
 both the sink pad and the src pad. At that time other elements can be
 tried and added to the src pad, until we reach the renderer. As usual
-one has to be carefull to add just the minimum amount of elements to
+one has to be careful to add just the minimum amount of elements to
 reach the renderer. The global plan will help with that.

 Since we basically do not use the capabilities of the sink pad one has 
--- a/docs/random/caps2
+++ b/docs/random/caps2
@ -130,7 +130,7 @@ The pad template caps should be the union of caps a pad supports
 in any potential situation.  Simultaneously, these caps should be
 as specific as possible, since it is used to decide which elements
 to attempt for autoplugging, without having to load the element.
-The pad template caps are generally detemined at compile time, but
+The pad template caps are generally determined at compile time, but
 might be actually computed at run-time from other information.

 The getcaps() function returns the caps supported by a given pad,
--- a/docs/random/company/clocks
+++ b/docs/random/company/clocks
@ -60,7 +60,7 @@ Providers are elements that can provide timing information and therefore provide
 a clock to other elements. These elements have to update the clock, when it is
 used. When a clock is used (state != NULL - FIXME: or other states?), the 
 provider is guaranteed to use this clock. (FIXME: necessary?). The element is
-however required to synchronize to the clock it was assigned to, wether it is
+however required to synchronize to the clock it was assigned to, whether it is
 its own clock or not.

 SYNC POINTS
@ -77,7 +77,7 @@ GstClockTime	gst_clock_get_time	(GstClock *clock);
 GstElementState	gst_clock_get_state 	(GstClock *clock); /* setting works internally */
 GstClockReturn	gst_clock_wait		(GstClock *clock, GstClockTime until, GstClockTimeDiff *jitter);

-GST_FLAG	GST_ELEMENT_NEEDS_CLOCK; /* wether we want a clock or not */
+GST_FLAG	GST_ELEMENT_NEEDS_CLOCK; /* whether we want a clock or not */
 GstClockTime	gst_element_get_time	(GstElement *element);
 void		gst_element_(clock_)seek (GstElement *element, GstClockTimeDiff diff);
 GstClock *	gst_element_get_clock	(GstElement *element);
--- a/docs/random/company/gstdata
+++ b/docs/random/company/gstdata
@ -64,7 +64,7 @@ struct _GstMyData {

 You can even enhance the class struct, if you want to. This works just like inheritance in GLib.

-If it can be a parent class, it should implement these three functions publically:
+If it can be a parent class, it should implement these three functions publicly:
 void gst_my_data_init (GstMyData *data) {
  /* call the parent's init function, eg: */
  gst_data_init (GST_DATA (data));
@ -206,7 +206,7 @@ FIXME: Write more, when sure how to do this.

 Upstream events
 ===============
-These will be discussed in a seperate doc.
+These will be discussed in a separate doc.



--- a/docs/random/company/gstparse
+++ b/docs/random/company/gstparse
@ -93,7 +93,7 @@ automatically means the element directly in front of / after the link is used
 to create the link to save you some typing work and that not specifying a pad
 name will automatically create 1 connection between the two elements. If more
 than one connection was possible you might end up surprised.
-You may even specify pad lists to connect elements. They are seperated by
+You may even specify pad lists to connect elements. They are separated by
 commas.
  example:#> gst-launch fakesrc ! tee name=tee1 .src0,src1 ! .sink0, sink1 aggregator ! fakesink
  example:#> gst-launch fakesrc ! tee name=tee  aggregator name=aggregator ! fakesink   tee.src0,src1 ! aggregator.sink0, sink1
--- a/docs/random/company/gvadec.txt
+++ b/docs/random/company/gvadec.txt
@ -36,7 +36,7 @@ Although the GStreamer framework's focus is multimedia processing, the core
 has been used outside the real of multimedia, for example in the gst-sci
 package[8] that provides statistical data analysis.

-This paper focusses on the GStreamer core and explains the goals of the
+This paper focuses on the GStreamer core and explains the goals of the
 framework and how the core tries to achieve these by following a simple
 mp3 playback example. 

@ -45,7 +45,7 @@ Plugins

 To allow easy extensibility, the complete media processing functionality
 inside GStreamer is provided via plugins. Upon initialization a plugin
-registeres its different capabilities with the GStreamer library. These
+registers its different capabilities with the GStreamer library. These
 capabilities are schedulers, typefind functions or - most common - elements.
 The capabilities of plugins are recorded inside the registry.

@ -53,7 +53,7 @@ The capabilities of plugins are recorded inside the registry.
 The registry

 The registry is a cache file that is used to inspect certain plugin capabilities
-without the need to load the plugin. As an example those stored capabilites
+without the need to load the plugin. As an example those stored capabilities
 enabled automatically determining which plugins must be loaded in order to
 decode a certain media file.
 The gst-register(1) command updates the registry file. The gst-inspect(1)
@ -146,7 +146,7 @@ elements implementing them.
 The last step in creating a pipeline is linking pads. When attempting to link
 two pads, GStreamer checks that a link is possible and if so, links them. After
 they are linked data may pass through this link. Most of the time (just like
-in this example) convenience funtions are used that automatically select the
+in this example) convenience functions are used that automatically select the
 right elements to connect inside a GStreamer pipeline.


@ -166,7 +166,7 @@ GST_STATE_NULL to GST_STATE_READY
 GST_STATE_NULL is the 'uninitialized' state. Since it is always possible to
 create an element, nothing that might require interaction or can fail is done
 while creating the element. During the state transition elements are supposed
-to initialize external ressources. A file source opens its file, X elements
+to initialize external resource. A file source opens its file, X elements
 open connections to the X server etc. This ensures that all elements can
 provide the best possible information about their capabilities during future
 interactions. The GStreamer core essentially does nothing. After this
@ -177,7 +177,7 @@ the element is ready to start.
 GST_STATE_READY to GST_STATE_PAUSED

 During this state change all internal dependencies are resolved. The GStreamer 
-core tries to resolve links between pads by negotiating capabilites of pads.
+core tries to resolve links between pads by negotiating capabilities of pads.
 (See below for an explanation.) The schedulers will prepare the elements for
 playback and the elements will prepare their internal data structures. After
 this state change is successful, nearly all elements are done with their setup.
--- a/docs/random/company/tagging
+++ b/docs/random/company/tagging
@ -1,7 +1,7 @@
 Quoting iain <iain@prettypeople.org>:

 > If you could write a small thing about how to use the tagging, it'd be
-> appreciated. I think MArlin is going to be using it pretty extensivly,
+> appreciated. I think MArlin is going to be using it pretty extensively,
 > and so it'd be nice to get it in there and tested quickly.
 > 
 Ok. A short writeup.
--- a/docs/random/company/time
+++ b/docs/random/company/time
@ -1,7 +1,7 @@
 Time in Gstreamer

 When talking about time in streams (or "clocking"), people often confuse 3 
-different things that need to be treated seperately. Older designs in GStreamer
+different things that need to be treated separately. Older designs in GStreamer
 confused those and this made it difficult to design solutions for time 
 management.

--- a/docs/random/ds/0.9-planning2
+++ b/docs/random/ds/0.9-planning2
@ -69,7 +69,7 @@ plans:
 - The concept of GstBuffer from 0.8 will be split into two types.
   One type will focus solely on holding information pertaining to
   ownership of a memory area (call this GstMemBuffer), and the
-   other type will focus solely in transfering information between
+   other type will focus solely in transferring information between
   elements (call this GstPipeBuffer).  In case you get confused,
   GstMemBuffers _are not_ transferred between elements, and
   GstPipeBuffers _do not_ own the memory they point to.
--- a/docs/random/dynpads
+++ b/docs/random/dynpads
@ -2,7 +2,7 @@ Dynamic pads are pads that are created while the element is playing.
 This means that the element will create a new pas depending on the 
 media type it is handling. For example, the mpeg1pdemuxer element will
 create one or more video pads and one or more audio pads depending
-on the number of elementtary streams found in the media stream.
+on the number of elementary streams found in the media stream.

 The element will present its dynamic pads with the padtemplate list
 attached to the elementfactory. both the MIME type, direction, presence
@ -33,7 +33,7 @@ padtemplate provided by the compressor src pad and connect the
 compressor element to this pad.

 An element that can be requested for a new pad has to implement the
-gst_element_request_new_pad method and perform the nessesary steps 
+gst_element_request_new_pad method and perform the necessary steps
 to create a pad from that template. 

 This interesting behaviour can be extended to ghostpads too. A 
--- a/docs/random/ensonic/distributed.txt
+++ b/docs/random/ensonic/distributed.txt
@ -9,7 +9,7 @@ respective machine.

 At runtime when the proxy-element receives data it sends it to the remote
 element and after processing it gets it back and forwards it to the element.
-The challenge is to optimize links when multiple conected elements are on the
+The challenge is to optimize links when multiple connected elements are on the
 same remote machine so that the data gets passed directly there.

 == proxy creation ==
--- a/docs/random/ensonic/dparams.txt
+++ b/docs/random/ensonic/dparams.txt
@ -10,5 +10,5 @@ $Id$
  * functions in  gst-controller.c could try the key,
    if no handler is registered the try the type_parent and so on

-* implement quadric/qubic interpolation
+* implement quadric/cubic interpolation

--- a/docs/random/ensonic/draft-bufferpools.txt
+++ b/docs/random/ensonic/draft-bufferpools.txt
@ -1,7 +1,7 @@
 BufferPools
 -----------

-This document proposes a mechnism to build pools of reusable buffers. The
+This document proposes a mechanism to build pools of reusable buffers. The
 proposal should improve performance and help to implement zero-copy usecases.

 Last edited: 2009-09-01 Stefan Kost
@ -20,24 +20,24 @@ Problems

  - hardware based elements like to reuse buffers as they e.g.
    - mlock them (dsp)
-    - establish a index<->adress relation (v4l2)
+    - establish a index<->address relation (v4l2)
  - not reusing buffers has overhead and makes run time behaviour
    non-deterministic:
-    - malloc (which usualy becomes an mmap for bigger buffers and thus a
+    - malloc (which usually becomes an mmap for bigger buffers and thus a
      syscall) and free (can trigger compression of freelists in the allocator)
    - shm alloc/attach, detach/free (xvideo)
  - some usecases cause memcpys
    - not having the right amount of buffers (e.g. too few buffers in v4l2src)
    - receiving buffers of wrong type (e.g. plain buffers in xvimagesink)
-    - receving buffers with wrong alignment (dsp)
-  - some usecases cause unneded cacheflushes when buffers are passed between
+    - receiving buffers with wrong alignment (dsp)
+  - some usecases cause unneeded cacheflushes when buffers are passed between
    user and kernel-space


 What is needed
 --------------

-Elements that sink raw data buffers of usualy constant size would like to 
+Elements that sink raw data buffers of usually constant size would like to
 maintain a bufferpool. These could be sinks or encoders. We need mechanims to
 select and dynamically update:

@ -48,12 +48,12 @@ select and dynamically update:

 Proposal
 --------
-Querying the bufferpool size and buffer alignments can work simillar to latency
+Querying the bufferpool size and buffer alignments can work similar to latency
 queries (gst/gstbin.c:{gst_bin_query,bin_query_latency_fold}. Aggregation is
 quite straight forward : number-of-buffers is summed up and for alignment we
 gather the MAX value.

-Bins need to track which elemnts have been selected as bufferpools owners and
+Bins need to track which elements have been selected as bufferpools owners and
 update if those are removed (FIXME: in which states?).

 Bins would also need to track if elements that replied to the query are removed
@ -65,7 +65,7 @@ Bufferpools owners need to handle caps changes to keep the queued buffers valid
 for the negotiated format.

 The bufferpool could be a helper GObject (like we use GstAdapter). If would
-manage a collection of GstBuffers. For each buffer t tracks wheter its in use or
+manage a collection of GstBuffers. For each buffer t tracks whether its in use or
 available. The bufferpool in gst-plugin-good/sys/v4l2/gstv4l2bufferpool might be
 a starting point.

@ -106,7 +106,7 @@ There are more attributes on buffers needed to reduce the overhead even more:
    the end to a specific alignment
  - mlock: hardware that uses DMA needs buffers memory locked, if a buffer is
    already memory locked, it can be used by other hardware based elements as is
-  - cache flushes: hardware based elements usualy need to flush cpu caches when
+  - cache flushes: hardware based elements usually need to flush cpu caches when
    sending results as the dma based memory writes do no update eventually
    cached values on the cpu. now if there is no element next in the pipeline
    that actually reads from this memory area we could avoid the flushes. All
--- a/docs/random/ensonic/draft-registry-change-hooks.txt
+++ b/docs/random/ensonic/draft-registry-change-hooks.txt
@ -1,7 +1,7 @@
 Registry Change Hooks
 ----------------------

-This document proposes a mechnism to register on registry updates.
+This document proposes a mechanism to register on registry updates.

 Last edited: 2009-11-09 Stefan Kost

--- a/docs/random/ensonic/dynlink.txt
+++ b/docs/random/ensonic/dynlink.txt
@ -73,13 +73,13 @@ gst_pads_insert_link (e1.src, e4.sink, e5.src, e6.sink);
 = ideas =
 == dynlinkpoint ==
 * use cases
-  * its ment to be used with one side disconnected to allow to connect elements
+  * its meant to be used with one side disconnected to allow to connect elements
    at runtime
  * it can be used in a pipeline to remove/insert elements at runtime
 * element with 1 source- and 1 sinkpad
 * when both connected it passes data thru
 * if src is not connected it drops received buffers
-* if sink is not conected
+* if sink is not connected
  * it does not push
  * it creates silence on pull
 * events
--- a/docs/random/ensonic/embedded.txt
+++ b/docs/random/ensonic/embedded.txt
@ -7,8 +7,8 @@ For avidemux I currently have a big patch doing memory optimized index handling.
 It basically thins out the index to save memory. Right now it only keeps index
 entries marked with the avi keyframe flag.

-In gstreamer core we have some indexing objects. They are curently used nowhere.
-The idea is to use them and to make the index strategy plugable or configurable
+In gstreamer core we have some indexing objects. They are currently used nowhere.
+The idea is to use them and to make the index strategy pluggable or configurable
 at run time.

 The challenge is then to rewrite muxers and demuxers to use them instead of the
@ -20,13 +20,13 @@ encapsulated in the indexer strategy.
 == ranking ==
 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.
+The rank of an element right now refers to the quality/maturity of the element.
 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:
+There are more decision criteria thinkable:
 * target processor (CPU,DSP,GPU)
-* ressource usage (CPU, memory)
+* resource usage (CPU, memory)
 * license (proprietary, open source)
 * quality (in terms of the audio/image quality)

--- a/docs/random/ensonic/interfaces.txt
+++ b/docs/random/ensonic/interfaces.txt
@ -45,7 +45,7 @@ $Id$
  * GST_TYPE_QUALITY_VS_SPEED
    - get the name of a property that can be used to switch between
      - a fast version for e.g. realtime usage
-      - a slower version with higher precission that can be used for off-line
+      - a slower version with higher precision that can be used for off-line
        rendering
 * new interfaces for audio applications
  * GST_TYPE_MULTI_VOICE
--- a/docs/random/ensonic/lazycaps.txt
+++ b/docs/random/ensonic/lazycaps.txt
@ -54,7 +54,7 @@ void gst_caps_merge_structure (GstCaps *caps,
 - fully evaluate caps?

 GstCaps * gst_caps_copy_nth (const GstCaps *caps, guint nth);
- eval stucture and copy
+- eval structure and copy

 void gst_caps_truncate (GstCaps *caps);
 - eval first structure as needed and remove GST_CAPS_FLAGS_LAZY + call free_func
--- a/docs/random/ensonic/logging.txt
+++ b/docs/random/ensonic/logging.txt
@ -2,7 +2,7 @@ $Id$

 rethink log format. current format:
 * is not easy to parse/process by commandline tools
-* cannnot be easily diffed (timestamps, pid)
+* cannot be easily diffed (timestamps, pid)

 gst_debug_log_default() is default gst-log handler.
 try new via:
--- a/docs/random/ensonic/media-device-daemon.txt
+++ b/docs/random/ensonic/media-device-daemon.txt
@ -4,7 +4,7 @@ components
 ================================================================================

 - daemon process
-  - is a gstreamer appliation
+  - is a gstreamer application
  - open physical sink, src elements
  - prepends an adder to sinks
  - appends an tee to sources
--- a/docs/random/ensonic/profiling.txt
+++ b/docs/random/ensonic/profiling.txt
@ -13,7 +13,7 @@ $Id$

 = qos profiling =
 * what data is needed ?
-  * (streamtime,propotion) pairs from sinks
+  * (streamtime,proportion) pairs from sinks
    draw a graph with gnuplot or similar
  * number of frames in total
  * number of audio/video frames dropped from each element that support QOS
@ -23,7 +23,7 @@ $Id$
  * add -r, --report option to gst-launch
  * during playing we capture QOS-events to record 'streamtime,proportion' pairs
    gst_pad_add_event_probe(video_sink->sink_pad,handler,data)
-  * during playback we like to know when an elemnt drops frames
+  * during playback we like to know when an element drops frames
    what about elements sending a qos_action message?
  * after EOS, send qos-queries to each element in the pipeline
    * qos-query will return:
@ -66,7 +66,7 @@ $Id$
  * 1:1 elements are easy to handle
  * 0:1 elements need a start timer
  * 1:0 elements need a end timer
-  * n:1, 1:m and n:m type elemnts are tricky
+  * n:1, 1:m and n:m type elements are tricky
    adapter based elements might have a fluctuating usage in addition
  
  // result data
--- a/docs/random/error
+++ b/docs/random/error
@ -55,5 +55,5 @@ Some notes on the error handling introduced after 0.7.3
      The plugin asked to read on the underlying resource (using bytestream),
      but failed.  The user will get a generic read error.  The debug info
      will contain the exact position in the stream at which the read error
-      occured.
+      occurred.

--- a/docs/random/events
+++ b/docs/random/events
@ -56,7 +56,7 @@ There are 3 different directions an event can be processed.

 * vertical events
  
-  Vertical events travel from elements to their parents. They are targetted at
+  Vertical events travel from elements to their parents. They are targeted at
  the application. Vertical events should be used for information that an 
  application cannot receive in an easy way by using callbacks or properties.
  Vertical events are send to the application by the pipeline that collects those
@ -142,7 +142,7 @@ from these infos. (eg converting stream length in bytes to song length in
 microseconds).
 Props consist of key / value pairs, where the key is a string identifier and the value
 is a GstPropEntry. Many key strings are predefined to allow consistency between elements.
-Elements should try to suppy any information they can as soon as possible.
+Elements should try to supply any information they can as soon as possible.

 GST_EVENT_HAS_INFO
 direction(s): upstream
@ -177,7 +177,7 @@ References to events are handled similar to buffers. An element receives an even
 a single reference. If it forwards the event, this reference is lost.
 Events own a reference to the element that created them. They take care of all of all
 data inside them too (strings, props). So elements and applications that want to keep
-this informations need to copy or add a reference them.
+this information need to copy or add a reference them.


 Changing Events
@ -215,7 +215,7 @@ Use Cases
 ---------

 Following are some simple use cases describing how events are generated. The pipeline
-decriptions use gst-launch syntax. "..." indicates that something follows there but is 
+descriptions use gst-launch syntax. "..." indicates that something follows there but is
 not important for the example.

 * filesrc ! fakesink
@ -245,7 +245,7 @@ not important for the example.
    will not be forwarded by mad.
  - When playing starts, mad is able to compute bitrate and other information including playing
    time with the help of the previous length information supplied by the filesrc. It will then
-    issue another INFO event with that informations. This one will be send downstream and vertical.
+    issue another INFO event with that information. This one will be send downstream and vertical.
    
 * ... ! avimux ! filesink

@ -253,7 +253,7 @@ not important for the example.
  files have a limited filesize. Only 4 GB are allowed. We now show what happens when the avimux
  encoder hits that limit.
  - When the internal counter of avimux shows that it is approaching the filesize limit, the 
-    avimux element pushes a buffer containig the footer to the filesink.
+    avimux element pushes a buffer containing the footer to the filesink.
  - After that it issues a DISCONTINUOUS event of the type DISCONT_NEW indicating a new stream.
    The filesink will close the file and reopen a new one.
  - The avimux plugin resets its internal size counter and restarts sending data to the new file.
@ -271,7 +271,7 @@ not important for the example.
  - The gunzip element has already decoded the whole data so it knows the size of the stream. It
    calls the callback for "length_size" and forwards the event.
  - The filesrc supplies the "URI" and the "length_size" for a second time. It is now up to the
-    application's callback function to handle this second occurence of "length_size" information.
+    application's callback function to handle this second occurrence of "length_size" information.
    The filesrc does not forward the event and dereferences it.
  - During disposal of the event, the callback function is called again with name=NULL. The
    application now knows that no "title" can be supplied.  
--- a/docs/random/gdp
+++ b/docs/random/gdp
@ -1,8 +1,8 @@
 GStreamer data protocol
    Intended to wrap GstData objects in a line protocol for use with
    pipe / network elements.
-    IDEAS-- -- -*for transporting buffers, have a function that creates a header for a given buffer to be written before the buffer.This way, you don 't lose
-  time creating a GDP buffer from the buffer
+    IDEAS-- -- -*for transporting buffers, have a function that creates a header for a given buffer to be written before the buffer.
+    This way, you don't lose time creating a GDP buffer from the buffer
 * allow for CRC' ing of the GstBuffer, optionally * have a version number of the protocol * optimizing the header for size is not useful since the GstData structure
    already contains more than 32 bytes anyway, making up half the header size PROTOCOL-- -- ----*1 byte GDP major
 version (0)
--- a/docs/random/matth/scheduling.txt
+++ b/docs/random/matth/scheduling.txt
@ -5,8 +5,8 @@
 These notes describe deadlock scenarios and proposed solutions for
 GStreamer.  This will be implemented in the INCSCHED1 branch.

-I.   Miscelaneous proposals
-II.  Liveness problems (sometimes deadlock ;) and propsed solutions
+I.   Miscellaneous proposals
+II.  Liveness problems (sometimes deadlock ;) and proposed solutions
 III. State transition approach and responsibility

 MattH.
--- a/docs/random/negotiation
+++ b/docs/random/negotiation
@ -270,7 +270,7 @@ Other junk:
   circumstance, the getcaps function can be omitted.
   
 - If you use gst_pad_use_explicit_caps(), the getcaps function must
-   be ommitted.
+   be omitted.

 - fixate functions are a method for applications to exert influence
   on how a format is chosen from a caps.  It's also used as a hack to
--- a/docs/random/old/ChangeLog.gstreamer
+++ b/docs/random/old/ChangeLog.gstreamer
@ -14060,7 +14060,7 @@
 	gstpad. Modified the videosink to implement the pull. This function
 	allows a source element to request a buffer from the destination.
 	This is much more efficient because the videosink can then pass a
-	buffer with SHM to the element, which does not require an aditional
+	buffer with SHM to the element, which does not require an additional
 	memcpy.  removed scaling from the videosink. I need something
 	better.

--- a/docs/random/omega/TODO-0.1.0
+++ b/docs/random/omega/TODO-0.1.0
@ -40,7 +40,7 @@ Finish LADSPA plugin to data-moving stage



-things to remember for the anouncement:
+things to remember for the announcement:
 ---------------------------------------

 Build requirements list:
--- a/docs/random/omega/caps2
+++ b/docs/random/omega/caps2
@ -57,7 +57,7 @@ Again from the plugin registry we find an element audiosink that has appropriate
  };

 A copy of the audiosink is instantiated and attached, negotiation goes smoothly, and we're done.  No
-dataflow has occured, no failure found, etc.  An ideal autoplug.
+dataflow has occurred, no failure found, etc.  An ideal autoplug.


 Now, a slightly more convoluted example:
@ -106,10 +106,10 @@ changed:

 Whoops.  It seems that the sound card we've got in this machine (FIXME how on earth to deal with
 multiple sound cards???) doesn't support mono output *at all*.  This is a problem.  We now find that we
-hae no options as far as directly matching the mpg123 to the audiosink.
+have no options as far as directly matching the mpg123 to the audiosink.

-A look through our (ficticious) plugin registry shows at least one element that at least has audio/raw
-on both input and ouput (since both mpg123 and audiosink have open pads with this mime type).  A closerlook shows that its caps are:
+A look through our (fictitious) plugin registry shows at least one element that at least has audio/raw
+on both input and output (since both mpg123 and audiosink have open pads with this mime type).  A closerlook shows that its caps are:

  static GstCapsFactory mono2stereo_sink_caps = {
    "audio/raw",
@ -231,7 +231,7 @@ following caps:
  };

 This seems to be a task for typefind again.  But since data is flowing, we have to be careful with the
-buffers.  (This is the case in any typefind maneuver, but moreso when one really can't rewind the
+buffers.  (This is the case in any typefind maneuver, but more so when one really can't rewind the
 source without consequences)  The autoplug system attaches a special pseudo-element to mpeg2parse's new
 output pad, and attaches the typefind element to the end of that.  The pseudo-element takes the buffer,
 stores it, and passes a copy off to the attached element, in this case typefind.  This repeats until
--- a/docs/random/omega/plan-generation
+++ b/docs/random/omega/plan-generation
@ -5,7 +5,7 @@ Plan generation happens at transition from NULL to READY (and PLAYING to READY r
 that).  By way of some logic in gst_bin_change_state(), gst_bin_create_plan() is only called for the
 outer Bin, usually a Pipeline.  This keeps things from getting nasty later on.

-A major new concept in plan generation is that of the 'manager'.  This is the element that is reponsible
+A major new concept in plan generation is that of the 'manager'.  This is the element that is responsible
 for running a given element.  In general, Pipelines and Threads are the only managing-capable elements
 (have the MANAGER flag set), since they are the only ones with real scheduling authority (because they
 have a process context to play with, basically).
@ -33,7 +33,7 @@ furtuer down the hierarchy, until everything is covered.

 For all MANAGER Bins, the last step is to actually create the scheduling plan.  This is still one of the
 nastiest chunks of code in the whole project, and probably will do nothing but get worse from now on (it
-got better recently, but only because I took a chainsaw to the code and broke everthing...).  It will
+got better recently, but only because I took a chainsaw to the code and broke everything...).  It will
 remain similar to what it is now, but with some definite differences.

 First task is now to find all the elements that we're responsible for.  This is normally a recursive
--- a/docs/random/omega/sched-commit1
+++ b/docs/random/omega/sched-commit1
@ -25,7 +25,7 @@ now have:

 loopfunc_wrapper: used for loop-based elements, it simply calls the
 	loopfunc in a loop, paying attention to COTHREAD_STOPPING (see
-	below).  It currently does other, soon to be depracated, stuff.
+	below).  It currently does other, soon to be deprecated, stuff.

 pullsrc_wrapper: wraps a Src that's not loop-based (since your options
 	are now loop- or pull-based)
--- a/docs/random/omega/sched2
+++ b/docs/random/omega/sched2
@ -4,7 +4,7 @@ header stuff to do various checking of flags.  Unfortunately, because of the sel
 the pad, there is at least one case where scheduling has to be tricked, by providing a pointer to a
 function with no body.

-What I propse is that these functionos be replaced with macros that call a function pointer directly.
+What I propose is that these functions be replaced with macros that call a function pointer directly.
 The default functions (provided by GstPad) would be capable of chaining, that's about it.  When a
 schedule is formed, these get replaced with more specific functions, provided by GstBin or a subclass.

--- a/docs/random/phonon-gst
+++ b/docs/random/phonon-gst
@ -97,14 +97,14 @@ Questions

 2) Threading:

-   - Can signals be emited from any thread?
+   - Can signals be emitted from any thread?
   - what operations are permited from a signal handler?

 3) Error reporting

   - How does error reporting work?
     * an audio/video device/port is busy.
-     * a fatal decoding error occured.
+     * a fatal decoding error occurred.
     * a media type is not supported


@ -189,7 +189,7 @@ Phonon::AudioEffect/Phonon::VideoEffect

 Phonon::VolumeFaderEffect

-  Alows fade-in and fade-out with a configurable curve and time. Needs
+  Allows fade-in and fade-out with a configurable curve and time. Needs
  GstController.

 Phonon::BrightnessControl
@ -239,7 +239,7 @@ Phonon::ByteStream
   - If called after starting ByteStream, the Phonon::ByteStream::seekStream
     signal can be called for push-based seekable streams.

-  * Can the signals be emited from a streaming thread?
+  * Can the signals be emitted from a streaming thread?
   

 Phonon::AudioDataOutput/Phonon::VideoDataOutput/
@ -254,12 +254,12 @@ Phonon::AudioDataOutput/Phonon::VideoDataOutput/
 Notes :

  * Phonon::AudioDataOutput::dataReady
-    - can this be emited from the streaming threads?
+    - can this be emitted from the streaming threads?

  * Phonon::AudioDataOutput::endOfMedia 
-    - can this be emited from the streaming threads?
+    - can this be emitted from the streaming threads?
    - We need to grab this EOS message synchronously from the bus.
-    - should be emited _before_ sending the last dataReady. This means we need
+    - should be emitted _before_ sending the last dataReady. This means we need
      to cache at least one dataReady.

  * Phonon::AudioDataOutput::setDataSize
--- a/docs/random/plan-0.11.txt
+++ b/docs/random/plan-0.11.txt
@ -112,7 +112,7 @@ First attempt at making a list of tasks in roughly chronological order.
  are possible somewhere downstream.

  gst_pad_alloc_buffer() would take a GstBuffer as an input argument to make the
-  API easier, we can then use metadata to specify additional contraints for the
+  API easier, we can then use metadata to specify additional constraints for the
  new buffer (such as strides, etc)
  

--- a/docs/random/plugins
+++ b/docs/random/plugins
@ -25,7 +25,7 @@ element factories provide the core library with elements (duh)
 an element factory has the following information:

  - a unique name for the element factory
-  - strings describing the element (name, desciption, copyright,...)
+  - strings describing the element (name, description, copyright,...)
  - a description of the media types it accepts (as capabilities) 
  - a description of the media types it outputs (as capabilities)

--- a/docs/random/porting-to-1.0.txt
+++ b/docs/random/porting-to-1.0.txt
@ -409,7 +409,7 @@ CHANGES
    Also segment accumulation was removed from the segment event. This means
    that now the source/demuxer/parser needs to add the elapsed time of the
    previous segment themselves (this must be added to segment->base). If this
-    is not done, looped playback wont work.
+    is not done, looped playback won't work.

    accum was renamed to base. last_stop was renamed to position.

--- a/docs/random/queue
+++ b/docs/random/queue
@ -9,7 +9,7 @@
  // in the queue

  // thread1 has put the last buffer on the queue
-  // here. A signal is going to be emited
+  // here. A signal is going to be emitted

  tosignal = (queue->level_buffers >= 0);
  queue->level_buffers++;
--- a/docs/random/rtp
+++ b/docs/random/rtp
@ -12,11 +12,11 @@ Suggested implementation:

 Tbe implementation that I suggest contains an rtpdec element. This element has one sink pad for the data, one src pad for the decoded data, and a pair of src and sink pads for control messages. The decoded data that comes from rtpdec has no RTP dependency. It is in the format expected by the codec that it decodes it. Therefore, rtpdec must do codec specific processing of data to take into account that different codecs are stored differently in RTP.

-A posible pipeline is:
+A possible pipeline is:

 udpcon name="data" udpcon name="control" data.src!rtpdec.datasrc  control.src!rtpdec.controlin control.sink!rtpdec.controlout rtpdec name="rtpdec" ! mp3decode ! osssink

-udpcon is an element (not yet written) that provides a src and a sink pad to read and write to a socket. There are two udpcon, one for reading the data socket and another for reading and writting to the control socket.
+udpcon is an element (not yet written) that provides a src and a sink pad to read and write to a socket. There are two udpcon, one for reading the data socket and another for reading and writing to the control socket.

 To handle variable types, the following would work (the UDP part left out for clarity is identical to the one above):

@ -24,13 +24,13 @@ To handle variable types, the following would work (the UDP part left out for cl

 rtpdec has a property that tells it the mapping of the payload bits to mime type. This is necessary, because that mapping is not fixed. It has to be obtained at runtime through other mechanisms, such as a SDP file obtained by http or rtsp.

-A posible implementation of rtpdec is a bin that contains two elements: a media independent _rtpparse and a media dependent rtp-dec-mp3. Thus the pipeline would be
+A possible implementation of rtpdec is a bin that contains two elements: a media independent _rtpparse and a media dependent rtp-dec-mp3. Thus the pipeline would be

 udpsrc ! _rtpparse ! rtp-dec-mp3 ! mp3decode ! osssink
       \________________________/
             rtpdec bin

-Another posible implementation is, that rtpdec opens a plugin that contains the code to convert the codec specific packets into the input that the normal decoder for that codec expects.
+Another possible implementation is, that rtpdec opens a plugin that contains the code to convert the codec specific packets into the input that the normal decoder for that codec expects.

 Ronald said that this mechanism would be complicated because it would require to duplicate the functionality of the plugin loader. It shouldn't be like that because it should use the normal plugin loader. However, this is an issue that I do not fully understand.

@ -40,5 +40,5 @@ udpsrc ! rtp-mp3 ! mp3decode ! osssink

 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. 
+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 possible 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.

--- a/docs/random/thomasvs/0.10
+++ b/docs/random/thomasvs/0.10
@ -47,7 +47,7 @@ gst-plugins-base
    - need possible porting to GNet (later)
  - typefind:
    - works
-    - need tests - this definately could use it
+    - need tests - this definitely could use it
    - is there any way they can be documented ?
    - should the plugin docs show a list of them ?
  - videorate:
@ -58,7 +58,7 @@ gst-plugins-base
      - par conversion
      - different scale algorithms
    - needs docs
-      - negotation with five out of six free variables (src/sink w/h/par)
+      - negotiation with five out of six free variables (src/sink w/h/par)
  - videotestsrc:
    - could use tests for all possible caps
  - volume: OK
--- a/docs/random/thomasvs/packaging
+++ b/docs/random/thomasvs/packaging
@ -24,7 +24,7 @@ to a lot of projects, including GLib and the kernel.
 The second version is an "interface" version, used in versioning tools, the
 library name, packages, GConf install paths, registry locations, and so on.
 It is of the form x.y
-Commonly, it is refered to as the "major/minor" number of GStreamer.
+Commonly, it is referred to as the "major/minor" number of GStreamer.
 In most cases it is the same as the one used in the source version; only
 when we are doing release candidates for a new major/minor source version do
 we manually force the major/minor to be the same as the one for the next
--- a/docs/random/types
+++ b/docs/random/types
@ -19,11 +19,11 @@ A plugin init function would take this typefactory and hand it to the
 gst_type_new() (FIXME: badly named) function, which would first search for
 that same MIME type in the current list.  If it found one, it would
 compare the two to see if the new one is "better".  Better is defined as
-having more extentions (to be merged) or a typefind function verses none.
+having more extensions (to be merged) or a typefind function verses none.

 The point of returning an existing MIME type is a result of the goal of
 unifying types enough to guarantee that, for instance, all MP3 decoders
-will work interchangably.  If MP3 decoder A says "MIME type 'audio/mpeg'
+will work interchangeably.  If MP3 decoder A says "MIME type 'audio/mpeg'
 with extensions 'mpeg3'" and decoder B says "MIME type 'audio/mpeg' with
 extensions 'mp3'", we don't want to have two types defined, possibly with
 two typefind functions. If we did, it's not obvious which of the two would
--- 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 already existing type.
+some plugins can output a specific subset of an already existing type.

 example:

@ -223,7 +223,7 @@ that it can handle all sorts of video/mpeg data.

 example 2:

-   suppose the typefind functions finds an mp3 stream, fillowing elments
+   suppose the typefind functions finds an mp3 stream, following elements
   are selected:

       libmpg123              mp3parse:
--- a/docs/random/types3
+++ b/docs/random/types3
@ -79,7 +79,7 @@ mpg123: an mpeg audio decoder.
  // a factory for the major type we use
  static GstTypeFactory mp3factory = {
    "audio/mp3",		// major type
-    ".mp3 .mp2 .mp1 .mpga",	// extenstions
+    ".mp3 .mp2 .mp1 .mpga",	// extensions
    NULL,			// typefind function
  };

@ -128,7 +128,7 @@ mpeg2dec: an mpeg video decoder that can do mpeg1 and mpeg2.

  static GstTypeFactory mpegfactory = {
    "video/mpeg",		// major type
-    ".mpg .mpeg",		// extenstions
+    ".mpg .mpeg",		// extensions
    NULL,			// typefind function
  };

--- a/docs/random/uraeus/gstreamer_and_midi.txt
+++ b/docs/random/uraeus/gstreamer_and_midi.txt
@ -319,7 +319,7 @@ KAR files are standard MIDI files that also contain a stream with lyrics, for ka
 synchronised on music. MIDI players play them without any problem, ignoring the
 additional data.

-It is the more widespread karaoke file format. (one other beeing .kok files, for mp3)
+It is the more widespread karaoke file format. (one other being .kok files, for mp3)

 KAR files are based on standard MIDI files with the following additional events:
 
--- a/docs/random/wtay/CORBA
+++ b/docs/random/wtay/CORBA
@ -19,7 +19,7 @@ of allowing objects to live in other contexts, languages and
 even on other machines over the network.

 Wrapping the GStreamer objects in CORBA objects doesn't look
-like a problem. It will immediatly allow us to create objects
+like a problem. It will immediately allow us to create objects
 accros the network and use the framework in a distributed
 environment.

@ -48,7 +48,7 @@ you to, for example, merge a pipeline with a document in one
 single stream. 

 I see bonobo as a high level service provider, you create a
-mediaplayer component that can be embeded into a document and
+mediaplayer component that can be embedded into a document and
 stuff like that.  The point here is that you use bonobo to 
 create services out of user apps build with GStreamer.

--- a/docs/random/wtay/autoplug2
+++ b/docs/random/wtay/autoplug2
@ -15,7 +15,7 @@ serious shortcommings:
 1) definition
 -------------

-We want to define a plugable framework for autoplugging this 
+We want to define a pluggable framework for autoplugging this
 includes: 

  - autoplugging algorithms can be added and removed at run time.
--- 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 NULL caps again and the pad connnection is broken.
+the NULL caps again and the pad connection is broken.

 The negotiation process is stopped after a fixed number of tries,
 when the counter has reached some limit. This limit is typically
--- a/docs/random/wtay/capsnego2
+++ b/docs/random/wtay/capsnego2
@ -199,7 +199,7 @@ in this case, mad can both send "int" audio samples and "float" samples.
  function. osssink can try this list (or whatever remains of it) and whatever
  works is sent back as the return value of the request_caps function.
 - mad receives the caps list, takes the top caps and does a pad_set_caps
- osssink recieves the final caps on its new_caps function and configures the
+- osssink receives the final caps on its new_caps function and configures the
  oss driver.


--- a/docs/random/wtay/capsnego2-docs
+++ b/docs/random/wtay/capsnego2-docs
@ -31,7 +31,7 @@ a key, which is always a string constant (internally converted to a GQuark)
 and a value, which can be one of the following:

 - an integer constant (ex. 5)
- - a float contant (ex. 1.0)
+ - a float constant (ex. 1.0)
 - a string constant (ex. "int")
 - a boolean constant (ex. FALSE)
 - a fourcc constant (ex. I420) 
@ -186,7 +186,7 @@ If the intersection is a fixed caps, this means there is only one possible media
 that can be used for this connection.

 For all not NULL intersections the pad connect functions are called with the 
-intersection. Depending on the result of the connect funtion the connection is
+intersection. Depending on the result of the connect function the connection is
 allowed or refused.

 If the intersection is fixed and the pad connect functions agreed to the caps, 
@ -275,7 +275,7 @@ Pad connect functions
 A Pad can be notified when another pad is connected or reconnected to it with
 fixed or variable caps. This notification will be done with the optional 
 GstPadConnectFunction callback that an element can provide for a pad.
-Remember that this connection is _always_ called, not only whith fixed caps
+Remember that this connection is _always_ called, not only with fixed caps
 but also with variable caps (if any).

 We will explain some of the common situations with some examples.
--- a/docs/random/wtay/clocking
+++ b/docs/random/wtay/clocking
@ -18,7 +18,7 @@ Clocks
 A clock extends the abstract GstClock class.

 gst_clock_get_time should always report an equal or increasing
-value with each succesive call.
+value with each successive call.



@ -150,7 +150,7 @@ if no Src elements exist with a clock, select a random clock from the
 Sink elements.
 else use a default System Clock.

-Src elements with a clock are prefered because they usualy provide
+Src elements with a clock are preferred because they usually provide
 live audio/video.

 Issues
--- a/docs/random/wtay/eos2
+++ b/docs/random/wtay/eos2
@ -96,12 +96,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,
@ -136,12 +136,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.
--- a/docs/random/wtay/events
+++ b/docs/random/wtay/events
@ -28,7 +28,7 @@ only travel in one direction.
    as close to the buffers are possible.

  - plugins should check the type of the GstData passed in the _chain
-    or _loop function and act appropriatly. This can be done by either 
+    or _loop function and act appropriately. This can be done by either
    doing their own stuff or by calling the default handler.

  - are handled on the sink pad.
@ -73,7 +73,7 @@ Possible candidates for events
 application generated events 
 ----------------------------

-The application can insert events into the pipeline at arbirary
+The application can insert events into the pipeline at arbitrary
 places. This will be done by calling gst_pad_event() on a pad.

 A first implementation will only cover inserting events on src pads
--- a/docs/random/wtay/events3
+++ b/docs/random/wtay/events3
@ -28,7 +28,7 @@ only travel in one direction.
    as close to the buffers are possible.

  - plugins should check the type of the GstData passed in the _chain
-    or _loop function and act appropriatly. This can be done by either 
+    or _loop function and act appropriately. This can be done by either
    doing their own stuff or by calling the default handler.

  - are handled on the sink pad.
@ -145,7 +145,7 @@ are supposed to handle them.
 application generated events 
 ----------------------------

-The application can insert events into the pipeline at arbirary
+The application can insert events into the pipeline at arbitrary
 places. This is done by calling gst_pad_send_event() on a pad.

 An application can also insert events on any element. The element
--- a/docs/random/wtay/interactivity
+++ b/docs/random/wtay/interactivity
@ -6,7 +6,7 @@ Possible application: DVD navigation, flash,...
 Requirements
 ------------

- capture mouse clicks, mouse position, movement occuring on
+- capture mouse clicks, mouse position, movement occurring on
  a video display plugin
 - transport these events to the interested plugins
 - allow for automation (ie, the technique should work without
@ -75,7 +75,7 @@ GST_CAPS_NEW (
 do we need a library for this?

 do we use custom events and use the mime type to detect the 
-type? do we creat a GST_EVENT_NAVIGATION?
+type? do we create a GST_EVENT_NAVIGATION?

 can we encapsulate all events into a GstCaps? I would think so

--- a/docs/random/wtay/messages
+++ b/docs/random/wtay/messages
@ -12,13 +12,13 @@ interesting information for the user app or for its parent.
 Consider the mp3parse element that could detect id3 tags in the stream.
 One way to let the app know about those tags is by emitting a signal. The
 problem with this signal is that the app has to perform a g_signal_connect
-on this element. This might not always be possible/feasable because
+on this element. This might not always be possible/feasible because
 the APP might not know about the mp3parse element (eg. an autoplugged
 pipeline or a compound object). The app could instrospect each element
 in the pipeline and look for known properties/signals to connect to,
 but that looks a bit ugly IMO.

-Signal proxying is also not very feasable because signals are tied to
+Signal proxying is also not very feasible because signals are tied to
 class instances.

 let's take the following use case:
@ -42,7 +42,7 @@ every signal in each element this would work somewhat.
 Requirements 
 ------------

-The application can listen to an abritrary bin in the pipeline to collect
+The application can listen to an arbitrary bin in the pipeline to collect
 information about that bins children. The app can listen on the top
 level bin to collect all of the elements messages.

--- a/docs/random/wtay/namespaces
+++ b/docs/random/wtay/namespaces
@ -28,7 +28,7 @@ or soon with the proposed 'new' standard of the W3C; Schemas.
 We can see obvious problems when a user app (unaware of the
 core tags) is also trying to use the 'element' tag for its 
 own purposes. The core might try to load the 'element' tag
-desscribing the user app data and the user app might get fed
+describing the user app data and the user app might get fed
 with XML data of the GStreamer core.

 In this document we try to describe how we will solve this problem
@ -53,7 +53,7 @@ Were a typical XML document without namespaces would look like:
 </element>
 </GST-Pipeline>

-Tha same document with namespaces look like this:
+The same document with namespaces look like this:

 <?xml version="1.0"?>
 <gst:GST-Pipeline xmlns:gst="http://gstreamer.net/gst-core/1.0/">
@ -98,7 +98,7 @@ editor as an example.  The editor will insert XML tags inside each
 element that describes the position and size of the element as it was
 laid out in the editor.

-For the examples sake, the tags that are used to descibe this meta data
+For the examples sake, the tags that are used to describe this meta data
 will also be names 'element' in order to demonstrate the namespaces.

 The editor will use its own namespace, being: 
@ -154,7 +154,7 @@ The XML save procedure on a GstObject is performed with:

  gst_object_save_thyself (GstObject *object, xmlNodePtr parent)

-Wich will call the elements implementation of the save_thyself function.
+Which will call the elements implementation of the save_thyself function.

 An app that wants to insert its XML tags has to connect to a signal of
 the GstObject object called xml_saved. The object and the parent
@ -174,7 +174,7 @@ freshly loaded objects.

 One obvious solution would be to attach a class signal to the 
 GstObject class that would be fired whenever an object is created from
-an XML document. Unfortunatly Gtk+ (or glib2.0) doesn't have class
+an XML document. Unfortunately Gtk+ (or glib2.0) doesn't have class
 signals so we need something else. Another problem with the class 
 signals would be that the user app would also be notified of object
 creation outside its context. For example, if two threads perform an 
--- a/docs/random/wtay/negotiation3
+++ b/docs/random/wtay/negotiation3
@ -224,7 +224,7 @@ Default implementations

 gst_pad_iterate_caps returns caps in the following order:

- 1) prefered caps (if any)
+ 1) preferred caps (if any)
 2) negotiated caps (if any)
 3) profile caps (if any, filtered against caps of current media type)
 4) padtemplate caps (filtered against caps of current media type)
--- a/docs/random/wtay/padprobes
+++ b/docs/random/wtay/padprobes
@ -4,8 +4,8 @@ PadProbes
 Required functionality

 - get notification of data passing on arbitrary pad
- - posibility to drop data
- - posibility to change/inspect data
+ - possibility to drop data
+ - possibility to change/inspect data
 - single shot probe
 - filter on events/buffers?
 - filter on timestamp?
--- a/docs/random/wtay/pipelineinfo
+++ b/docs/random/wtay/pipelineinfo
@ -205,7 +205,7 @@ always performed relative to 0, so if we convert track2 to bytes, we
 always get the number of bytes from track0->track2.

 If we want to get the number of bytes of one particular track, we have
-to substract two convert values. Look at the folowing figure to understand
+to substract two convert values. Look at the following figure to understand
 this. The --- defines the region we want to convert.


@ -260,7 +260,7 @@ Several reasons:
 - stuff like length an position depend on the pads of the element, you cannot
   sanely expose a property for each pad to describe this.
 - element properties can only report stuff with one type. If your property
-   exposes somthing like "total_length", you cannot make it both report this
+   exposes something like "total_length", you cannot make it both report this
   in time/bytes/samples/frames...
 - impossible to sanely implement convert with element properties.

--- a/docs/random/wtay/plugin_guidelines
+++ b/docs/random/wtay/plugin_guidelines
@ -253,7 +253,7 @@ complicated case

 * You can fix this by:

- - inserting gst_element_yield () in sane places, don't exagerate because
+ - inserting gst_element_yield () in sane places, don't exaggerate because
   every yield can potentially never return so you need to keep track of
   allocations (see the NOTES below).
 
@ -267,8 +267,8 @@ NOTES:
   and free it in the state change function.


-IMPLEMENATION DETAILS
-=====================
+IMPLEMENTATION DETAILS
+======================

 The infinite loops are only problematic if the scheduler chooses to select
 the plugin as an entry point in the chain. _yield() will be a nop if this is
@ -284,7 +284,7 @@ Calling yield, pulling, pushing can potentially never return because a state cha
 might have happened, killing off execution of the plugin. pulling/pushing buffers
 will cause no leaks in this case because the core will free pending buffers in a
 state change to READY. The plugin must free allocated data/buffers itself in the state
-change function if the yield didn't retrun. 
+change function if the yield didn't return.



--- a/docs/random/wtay/registry
+++ b/docs/random/wtay/registry
@ -1,7 +1,7 @@
 Requirements
 ------------

- plugable backends:
+- pluggable backends:

  - XML
  - flat file
--- a/docs/random/wtay/scheduling_ideas
+++ b/docs/random/wtay/scheduling_ideas
@ -254,7 +254,7 @@ Grouping
 * a group has at most one loop based element
 * elements in a group are sorted, src elements first (not mandatory)
 * a group has one cothread
- * a group is created immediatly for loop based elements, all other elements
+ * a group is created immediately for loop based elements, all other elements
   are added to a group when a pad connection is made
 * get-based plugins are put in the same group as a peer loop based element
 * chain based elements are put in the same group as sink peer elements
--- a/docs/random/wtay/threading
+++ b/docs/random/wtay/threading
@ -46,7 +46,7 @@ Fixing Threading
 - negotiation is not designed to work over multithread boundaries.

   negotiation over a queue is not possible. There is no method or policy of
-   discovering a media type and then commiting it. It is also not possible to
+   discovering a media type and then committing it. It is also not possible to
   tie the negotiated media to the relevant buffer. 

   ex1:
@ -213,7 +213,7 @@ Fixing Threading
       +---------+     +-----------------------+

   This requirement is important when we need to sort the elements in the
-   bin to perfrom the state change.
+   bin to perform the state change.
     

   testcases:
@ -250,7 +250,7 @@ Fixing Threading
     GST_STATE_FAILURE is returned when the element failed to go to the 
     required state. When dealing with a bin, this is returned when one
     of the elements failed to go to the required state. The other elements 
-     in the bin might have changed their states succesfully. This return
+     in the bin might have changed their states successfully. This return
     value means that the element did _not_ change state, for bins this
     means that not all children have changed their state.

@ -345,7 +345,7 @@ Fixing Threading
     This function will block while the state change function is running inside
     the element because it grabs the element lock. 
     When the element did not perform an async state change, this function returns 
-     TRUE immediatly with the state updated to reflect the current state of the 
+     TRUE immediately with the state updated to reflect the current state of the
     element and pending set to None. 
     When the element performed an async state change, this function will block 
     for the value of timeout and will return TRUE if the element completed the
@ -405,7 +405,7 @@ Fixing Threading
     the elements. To make this easier we require that elements are connected to
     bins using ghostpads on the bin.

-     The algoritm goes like this:
+     The algorithm goes like this:

       d = [ ]                            # list of delayed elements
       p = [ ]                            # list of pending async elements
@ -478,7 +478,7 @@ Fixing Threading
     reply and will only commit the state change after receiving the first
     buffer. This will implement the preroll phase.

-     The following pseudo code shows an algorithm for commiting the state
+     The following pseudo code shows an algorithm for committing the state
     change in the streaming method.

 	  GST_OBJECT_LOCK (element);
@ -529,7 +529,7 @@ Fixing Threading
        Data transport was successful

      GST_ERROR
-        An error occured during transport, such as a fatal decoding error,
+        An error occurred during transport, such as a fatal decoding error,
        the pad should not be used again.

      GST_NOT_CONNECTED
@ -580,7 +580,7 @@ Fixing Threading
     pipeline when an error occurs.

     Whenever an element posts a message on the event queue, a signal is also
-     fired that can be catched by the application. When dealing with those
+     fired that can be caught by the application. When dealing with those
     signals the application has to be aware that they come from the streaming
     threads and need to make sure they use proper locking to protect their
     own data structures.
--- a/docs/random/wtay/threads_hilevel
+++ b/docs/random/wtay/threads_hilevel
@ -168,5 +168,5 @@ TODO
 ----

 - review
- figure all state change scenarios occuring in code marked with (*)
+- figure all state change scenarios occurring in code marked with (*)

--- a/docs/random/wtay/timecache
+++ b/docs/random/wtay/timecache
@ -7,7 +7,7 @@ an index of possible seek positions (in time, bytes, samples, ...).
 The purpose of GstTimecache is to provide an infrastructure for
 plugins to maintain such an index.

-By creating a generic interace to this functionality, it is also
+By creating a generic interface to this functionality, it is also
 possible for the application to make use of the generated index.
 possible use cases are: saving/loading of indexes, obtain an 
 overview of the indexed stream (where is sample N, where is
--- a/gst/gst.c
+++ b/gst/gst.c
@ -633,7 +633,7 @@ gst_register_core_elements (GstPlugin * plugin)

 /*
 * this bit handles:
- * - initalization of threads if we use them
+ * - initialization of threads if we use them
 * - log handler
 * - initial output
 * - initializes gst_format
--- a/gst/gstbin.c
+++ b/gst/gstbin.c
@ -2573,7 +2573,7 @@ gst_bin_element_set_state (GstBin * bin, GstElement * element,
 do_state:
  GST_OBJECT_LOCK (bin);
  /* the element was busy with an upwards async state change, we must wait for
-   * an ASYNC_DONE message before we attemp to change the state. */
+   * an ASYNC_DONE message before we attempt to change the state. */
  if ((found =
          find_message (bin, GST_OBJECT_CAST (element),
              GST_MESSAGE_ASYNC_START))) {
@ -3058,12 +3058,12 @@ done:
  /* check if all elements managed to commit their state already */
  if (!find_message (bin, NULL, GST_MESSAGE_ASYNC_START)) {
    /* nothing found, remove all old ASYNC_DONE messages. This can happen when
-     * all the elements commited their state while we were doing the state
+     * all the elements committed their state while we were doing the state
     * change. We will still return ASYNC for consistency but we commit the
     * state already so that a _get_state() will return immediately. */
    bin_remove_messages (bin, NULL, GST_MESSAGE_ASYNC_DONE);

-    GST_DEBUG_OBJECT (bin, "async elements commited");
+    GST_DEBUG_OBJECT (bin, "async elements committed");
    bin_handle_async_done (bin, GST_STATE_CHANGE_SUCCESS, FALSE,
        GST_CLOCK_TIME_NONE);
  }
@ -3518,7 +3518,7 @@ bin_do_eos (GstBin * bin)

  GST_OBJECT_LOCK (bin);
  /* If all sinks are EOS, we're in PLAYING and no state change is pending
-   * (or we're doing playing to playing and noone else will trigger posting
+   * (or we're doing playing to playing and no one else will trigger posting
   * EOS for us) we forward the EOS message to the parent bin or application
   */
  eos = GST_STATE (bin) == GST_STATE_PLAYING
@ -3952,7 +3952,7 @@ gst_bin_handle_message_func (GstBin * bin, GstMessage * message)
        /* nothing found, remove all old ASYNC_DONE messages */
        bin_remove_messages (bin, NULL, GST_MESSAGE_ASYNC_DONE);

-        GST_DEBUG_OBJECT (bin, "async elements commited");
+        GST_DEBUG_OBJECT (bin, "async elements committed");
        /* when we get an async done message when a state change was busy, we
         * need to set the pending_done flag so that at the end of the state
         * change we can see if we need to verify pending async elements, hence
--- a/gst/gstcapsfeatures.c
+++ b/gst/gstcapsfeatures.c
@ -801,7 +801,7 @@ gst_caps_features_add_id (GstCapsFeatures * features, GQuark feature)
  }

  /* If features is empty it will contain sysmem, however
-   * we want to add it explicitely if it is tried to be
+   * we want to add it explicitly if it is attempted to be
   * added as first features
   */
  if (features->array->len > 0
--- a/gst/gstdebugutils.c
+++ b/gst/gstdebugutils.c
@ -1,7 +1,7 @@
 /* GStreamer
 * Copyright (C) 2007 Stefan Kost <ensonic@users.sf.net>
 *
- * gstdebugutils.c: debugging and analysis utillities
+ * gstdebugutils.c: debugging and analysis utilities
 *
 * This library is free software; you can redistribute it and/or
 * modify it under the terms of the GNU Library General Public
@ -21,7 +21,7 @@
 /* TODO:
 * edge [ constraint=false ];
 *   this creates strange graphs ("minlen=0" is better)
- * try puting src/sink ghostpads for each bin into invisible clusters
+ * try putting src/sink ghostpads for each bin into invisible clusters
 *
 * for more compact nodes, try
 * - changing node-shape from box into record
--- a/gst/gstdebugutils.h
+++ b/gst/gstdebugutils.h
@ -1,7 +1,7 @@
 /* GStreamer
 * Copyright (C) 2007 Stefan Kost <ensonic@users.sf.net>
 *
- * gstdebugutils.h: debugging and analysis utillities
+ * gstdebugutils.h: debugging and analysis utilities
 *
 * This library is free software; you can redistribute it and/or
 * modify it under the terms of the GNU Library General Public
--- a/gst/gstdevice.h
+++ b/gst/gstdevice.h
@ -44,7 +44,7 @@ typedef struct _GstDevicePrivate GstDevicePrivate;

 /**
 * GstDevice:
- * @parent: The parent #GstObject strucuture.
+ * @parent: The parent #GstObject structure.
 *
 * A device object.
 *
@ -62,7 +62,7 @@ struct _GstDevice {

 /**
 * GstDeviceClass:
- * @parent_class: The parent #GstObjectClass strucuture.
+ * @parent_class: The parent #GstObjectClass structure.
 * @create_element: Creates the fully configured element to access this device.
 *  Subclasses need to override this and return a new element.
 * @reconfigure_element: This only needs to be implemented by subclasses if the
--- a/gst/gstdeviceprovider.c
+++ b/gst/gstdeviceprovider.c
@ -26,7 +26,7 @@
 * @see_also: #GstDevice, #GstDeviceMonitor
 *
 * A #GstDeviceProvider subclass is provided by a plugin that handles devices
- * if there is a way to programatically list connected devices. It can also
+ * if there is a way to programmatically list connected devices. It can also
 * optionally provide updates to the list of connected devices.
 *
 * Each #GstDeviceProvider subclass is a singleton, a plugin should
--- a/gst/gstelement.c
+++ b/gst/gstelement.c
@ -1734,7 +1734,7 @@ gst_element_class_get_request_pad_template (GstElementClass *
 }

 /* get a random pad on element of the given direction.
- * The pad is random in a sense that it is the first pad that is (optionaly) linked.
+ * The pad is random in a sense that it is the first pad that is (optionally) linked.
 */
 static GstPad *
 gst_element_get_random_pad (GstElement * element,
@ -2986,14 +2986,14 @@ gst_element_change_state (GstElement * element, GstStateChange transition)
    case GST_STATE_CHANGE_SUCCESS:
      GST_CAT_DEBUG_OBJECT (GST_CAT_STATES, element,
          "element changed state SUCCESS");
-      /* we can commit the state now which will proceeed to
+      /* we can commit the state now which will proceed to
       * the next state */
      ret = gst_element_continue_state (element, ret);
      break;
    case GST_STATE_CHANGE_NO_PREROLL:
      GST_CAT_DEBUG_OBJECT (GST_CAT_STATES, element,
          "element changed state NO_PREROLL");
-      /* we can commit the state now which will proceeed to
+      /* we can commit the state now which will proceed to
       * the next state */
      ret = gst_element_continue_state (element, ret);
      break;
--- a/gst/gstelement.h
+++ b/gst/gstelement.h
@ -28,7 +28,7 @@

 G_BEGIN_DECLS

-/* gstelement.h and gstelementfactory.h include eachother */
+/* gstelement.h and gstelementfactory.h include each other */
 typedef struct _GstElement GstElement;
 typedef struct _GstElementClass GstElementClass;

--- a/gst/gstevent.c
+++ b/gst/gstevent.c
@ -1665,7 +1665,7 @@ gst_event_set_stream (GstEvent * event, GstStream * stream)
 /**
 * gst_event_parse_stream:
 * @event: a stream-start event
- * @stream: (out) (transfer full): adress of variable to store the stream
+ * @stream: (out) (transfer full): address of variable to store the stream
 *
 * Parse a stream-start @event and extract the #GstStream from it.
 *
--- a/gst/gstinfo.h
+++ b/gst/gstinfo.h
@ -253,7 +253,7 @@ struct _GstDebugCategory {
 * GST_FUNCTION:
 *
 * This macro should evaluate to the name of the current function and be should
- * be defined when configuring your project, as it is compiler dependant. If it
+ * be defined when configuring your project, as it is compiler dependent. If it
 * is not defined, some default value is used. It is used to provide debugging
 * output with the function name of the message.
 *
--- a/gst/gstmemory.c
+++ b/gst/gstmemory.c
@ -321,7 +321,7 @@ lock_failed:
  }
 error:
  {
-    /* something went wrong, restore the orginal state again
+    /* something went wrong, restore the original state again
     * it is up to the subclass to log an error if needed. */
    GST_CAT_INFO (GST_CAT_MEMORY, "mem %p: subclass map failed", mem);
    gst_memory_unlock (mem, (GstLockFlags) flags);
--- a/gst/gstmessage.h
+++ b/gst/gstmessage.h
@ -193,7 +193,7 @@ GST_API GType _gst_message_type;
 #define GST_MESSAGE(obj)                         (GST_MESSAGE_CAST(obj))

 /* the lock is used to handle the synchronous handling of messages,
- * the emiting thread is block until the handling thread processed
+ * the emitting thread is blocked until the handling thread processed
 * the message using this mutex/cond pair */
 #define GST_MESSAGE_GET_LOCK(message)   (&GST_MESSAGE_CAST(message)->lock)
 #define GST_MESSAGE_LOCK(message)       g_mutex_lock(GST_MESSAGE_GET_LOCK(message))
--- a/gst/gstminiobject.c
+++ b/gst/gstminiobject.c
@ -343,7 +343,7 @@ gst_mini_object_ref (GstMiniObject * mini_object)

  g_return_val_if_fail (mini_object != NULL, NULL);
  /* we can't assert that the refcount > 0 since the _free functions
-   * increments the refcount from 0 to 1 again to allow resurecting
+   * increments the refcount from 0 to 1 again to allow resurrecting
   * the object
   g_return_val_if_fail (mini_object->refcount > 0, NULL);
   */
--- a/gst/gstobject.c
+++ b/gst/gstobject.c
@ -1424,7 +1424,7 @@ gst_object_get_g_value_array (GstObject * object, const gchar * property_name,
 *
 * Obtain the control-rate for this @object. Audio processing #GstElement
 * objects will use this rate to sub-divide their processing loop and call
- * gst_object_sync_values() inbetween. The length of the processing segment
+ * gst_object_sync_values() in between. The length of the processing segment
 * should be up to @control-rate nanoseconds.
 *
 * If the @object is not under property control, this will return
@ -1450,7 +1450,7 @@ gst_object_get_control_rate (GstObject * object)
 *
 * Change the control-rate for this @object. Audio processing #GstElement
 * objects will use this rate to sub-divide their processing loop and call
- * gst_object_sync_values() inbetween. The length of the processing segment
+ * gst_object_sync_values() in between. The length of the processing segment
 * should be up to @control-rate nanoseconds.
 *
 * The control-rate should not change if the element is in %GST_STATE_PAUSED or
--- a/gst/gstpad.c
+++ b/gst/gstpad.c
@ -604,7 +604,7 @@ restart:
    if (G_UNLIKELY (ev->event == NULL))
      goto next;

-    /* take aditional ref, func might release the lock */
+    /* take additional ref, func might release the lock */
    ev_ret.event = gst_event_ref (ev->event);
    ev_ret.received = ev->received;

@ -1444,7 +1444,7 @@ gst_pad_add_probe (GstPad * pad, GstPadProbeType mask,
  GST_CAT_LOG_OBJECT (GST_CAT_SCHEDULING, pad, "adding probe for mask 0x%08x",
      mask);

-  /* when no contraints are given for the types, assume all types are
+  /* when no constraints are given for the types, assume all types are
   * acceptable */
  if ((mask & _PAD_PROBE_TYPE_ALL_BOTH_AND_FLUSH) == 0)
    mask |= GST_PAD_PROBE_TYPE_ALL_BOTH;
@ -1461,7 +1461,7 @@ gst_pad_add_probe (GstPad * pad, GstPadProbeType mask,
  /* add the probe */
  g_hook_append (&pad->probes, hook);
  pad->num_probes++;
-  /* incremenent cookie so that the new hook get's called */
+  /* incremenent cookie so that the new hook gets called */
  pad->priv->probe_list_cookie++;

  /* get the id of the hook, we return this and it can be used to remove the
--- a/gst/gstpreset.c
+++ b/gst/gstpreset.c
@ -45,7 +45,7 @@
 * 2) application and 3) user order. Whenever an earlier entry is newer, the
 * later entries will be updated. Since 1.8 you can also provide extra paths
 * where to find presets through the GST_PRESET_PATH environment variable.
- * Presets found in those paths will be concidered as "app presets".
+ * Presets found in those paths will be considered as "app presets".
 */
 /* FIXME:
 * - non racyness
--- a/gst/gstregistrybinary.c
+++ b/gst/gstregistrybinary.c
@ -302,7 +302,7 @@ gst_registry_binary_write_chunk (BinaryRegistryCache * cache,
  gchar padder[ALIGNMENT] = { 0, };
  int padsize = 0;

-  /* Padding to insert the struct that requiere word alignment */
+  /* Padding to insert the struct that require word alignment */
  if ((chunk->align) && (alignment (*file_position) != 0)) {
    padsize = ALIGNMENT - alignment (*file_position);
    if (gst_registry_binary_cache_write (cache, *file_position,
--- a/gst/gstregistrychunks.c
+++ b/gst/gstregistrychunks.c
@ -236,7 +236,7 @@ gst_registry_chunks_save_feature (GList ** list, GstPluginFeature * feature)
    GstElementFactory *factory = GST_ELEMENT_FACTORY (feature);

    /* Initialize with zeroes because of struct padding and
-     * valgrind complaining about copying unitialized memory
+     * valgrind complaining about copying uninitialized memory
     */
    ef = g_slice_new0 (GstRegistryChunkElementFactory);
    pf_size = sizeof (GstRegistryChunkElementFactory);
@ -296,7 +296,7 @@ gst_registry_chunks_save_feature (GList ** list, GstPluginFeature * feature)
    gchar *str;

    /* Initialize with zeroes because of struct padding and
-     * valgrind complaining about copying unitialized memory
+     * valgrind complaining about copying uninitialized memory
     */
    tff = g_slice_new0 (GstRegistryChunkTypeFindFactory);
    pf_size = sizeof (GstRegistryChunkTypeFindFactory);
@ -330,7 +330,7 @@ gst_registry_chunks_save_feature (GList ** list, GstPluginFeature * feature)
    GstDeviceProviderFactory *factory = GST_DEVICE_PROVIDER_FACTORY (feature);

    /* Initialize with zeroes because of struct padding and
-     * valgrind complaining about copying unitialized memory
+     * valgrind complaining about copying uninitialized memory
     */
    tff = g_slice_new0 (GstRegistryChunkDeviceProviderFactory);
    chk =
@ -344,7 +344,7 @@ gst_registry_chunks_save_feature (GList ** list, GstPluginFeature * feature)
        gst_structure_to_string (factory->metadata));
  } else if (GST_IS_TRACER_FACTORY (feature)) {
    /* Initialize with zeroes because of struct padding and
-     * valgrind complaining about copying unitialized memory
+     * valgrind complaining about copying uninitialized memory
     */
    pf = g_slice_new0 (GstRegistryChunkPluginFeature);
    pf_size = sizeof (GstRegistryChunkPluginFeature);
--- a/gst/gstsegment.c
+++ b/gst/gstsegment.c
@ -392,7 +392,7 @@ gst_segment_do_seek (GstSegment * segment, gdouble rate,
 * negative stream-time.
 *
 * This function is typically used by elements that need to synchronize buffers
- * against the clock or eachother.
+ * against the clock or each other.
 *
 * @position can be any value and the result of this function for values outside
 * of the segment is extrapolated.
@ -709,7 +709,7 @@ gst_segment_position_from_stream_time (const GstSegment * segment,
 * negative running-time.
 *
 * This function is typically used by elements that need to synchronize buffers
- * against the clock or eachother.
+ * against the clock or each other.
 *
 * @position can be any value and the result of this function for values outside
 * of the segment is extrapolated.
--- a/gst/gststreams.c
+++ b/gst/gststreams.c
@ -237,7 +237,7 @@ gst_stream_set_stream_id (GstStream * stream, const gchar * stream_id)
  if (stream_id)
    stream->stream_id = g_strdup (stream_id);
  else {
-    /* Create a randoom stream_id if NULL */
+    /* Create a random stream_id if NULL */
    GST_FIXME_OBJECT (stream, "Creating random stream-id, consider "
        "implementing a deterministic way of creating a stream-id");
    stream->stream_id =
--- a/gst/gsttaglist.c
+++ b/gst/gsttaglist.c
@ -614,7 +614,7 @@ gst_tag_get_nick (const gchar * tag)
  g_return_val_if_fail (tag != NULL, NULL);
  info = gst_tag_lookup (tag);
  if (!info) {
-    GST_WARNING ("Uknown tag: %s", tag);
+    GST_WARNING ("Unknown tag: %s", tag);

    return tag;
  }
@ -1299,7 +1299,7 @@ gst_tag_list_add_valist (GstTagList * list, GstTagMergeMode mode,
      g_warning ("%s: %s", G_STRLOC, error);
      g_free (error);
      /* we purposely leak the value here, it might not be
-       * in a sane state if an error condition occoured
+       * in a sane state if an error condition occurred
       */
      return;
    }
--- a/gst/gsttracerrecord.h
+++ b/gst/gsttracerrecord.h
@ -51,7 +51,7 @@ G_DEFINE_AUTOPTR_CLEANUP_FUNC(GstTracerRecord, gst_object_unref)
 * @GST_TRACER_VALUE_SCOPE_ELEMENT: the value is related to an #GstElement
 * @GST_TRACER_VALUE_SCOPE_PAD: the value is related to a #GstPad
 *
- * Tracing record will contain fields that contain a meassured value or extra
+ * Tracing record will contain fields that contain a measured value or extra
 * meta-data. One such meta data are values that tell where a measurement was
 * taken. This enumerating declares to which scope such a meta data field
 * relates to. If it is e.g. %GST_TRACER_VALUE_SCOPE_PAD, then each of the log
--- a/gst/gsttracerutils.c
+++ b/gst/gsttracerutils.c
@ -27,7 +27,7 @@
 * The user can activate tracers by setting the environment variable GST_TRACE
 * to a ';' separated list of tracers.
 *
- * Note that instanciating tracers at runtime is possible but is not thread safe
+ * Note that instantiating tracers at runtime is possible but is not thread safe
 * and needs to be done before any pipeline state is set to PAUSED.
 */

--- a/gst/gsttypefindfactory.c
+++ b/gst/gsttypefindfactory.c
@ -24,7 +24,7 @@
 * @title: GstTypeFindFactory
 * @short_description: Information about registered typefind functions
 *
- * These functions allow querying informations about registered typefind
+ * These functions allow querying information about registered typefind
 * functions. How to create and register these functions is described in
 * the section <link linkend="gstreamer-Writing-typefind-functions">
 * "Writing typefind functions"</link>.
--- a/gst/gsturi.c
+++ b/gst/gsturi.c
@ -957,7 +957,7 @@ beach:
 * @short_description: URI parsing and manipulation.
 *
 * A #GstUri object can be used to parse and split a URI string into its
- * constituant parts. Two #GstUri objects can be joined to make a new #GstUri
+ * constituent parts. Two #GstUri objects can be joined to make a new #GstUri
 * using the algorithm described in RFC3986.
 */

@ -2596,7 +2596,7 @@ gst_uri_get_query_table (const GstUri * uri)
 * reference to the new one is used instead. A value if %NULL for @query_table
 * will remove the query string from the URI.
 *
- * Returns: %TRUE if the new table was sucessfully used for the query table.
+ * Returns: %TRUE if the new table was successfully used for the query table.
 *
 * Since: 1.6
 */
@ -2630,7 +2630,7 @@ gst_uri_set_query_table (GstUri * uri, GHashTable * query_table)
 * indicates that the key has no associated value, but will still be present in
 * the query string.
 *
- * Returns: %TRUE if the query table was sucessfully updated.
+ * Returns: %TRUE if the query table was successfully updated.
 *
 * Since: 1.6
 */
@ -2805,7 +2805,7 @@ gst_uri_set_fragment (GstUri * uri, const gchar * fragment)
 * Get the media fragment table from the URI, as defined by "Media Fragments URI 1.0".
 * Hash table returned by this API is a list of "key-value" pairs, and the each
 * pair is generated by splitting "URI fragment" per "&" sub-delims, then "key"
- * and "value" are splitted by "=" sub-delims. The "key" returned by this API may
+ * and "value" are split by "=" sub-delims. The "key" returned by this API may
 * be undefined keyword by standard.
 * A value may be %NULL to indicate that the key should appear in the fragment
 * string in the URI, but does not have a value. Free the returned #GHashTable
--- a/gst/gstutils.c
+++ b/gst/gstutils.c
@ -1984,7 +1984,7 @@ gst_element_link_pads_full (GstElement * src, const gchar * srcpadname,
    return FALSE;
  } else {
    /* no need to release any request pad as the case of unset destpatname and
-     * destpad being a requst pad has already been taken care of when looking
+     * destpad being a request pad has already been taken care of when looking
     * though the destination pads above */
    if (destpad) {
      gst_object_unref (destpad);
@ -2613,7 +2613,7 @@ gst_pad_get_parent_element (GstPad * pad)
 * @debug: (in) (allow-none): an additional debug information string, or %NULL
 *
 * A default error function that uses g_printerr() to display the error message
- * and the optional debug sting..
+ * and the optional debug string..
 *
 * The default handler will simply print the error string using g_print.
 */
--- a/gst/gstvalue.c
+++ b/gst/gstvalue.c
@ -5495,7 +5495,7 @@ gst_value_list_equals_range (const GValue * list, const GValue * value)
 }

 /* "Pure" variant of gst_value_compare which is guaranteed to
- * not have list arguments and therefore does basic comparisions
+ * not have list arguments and therefore does basic comparisons
 */
 static inline gint
 _gst_value_compare_nolist (const GValue * value1, const GValue * value2)
--- a/gst/parse/grammar.y
+++ b/gst/parse/grammar.y
@ -845,7 +845,7 @@ elementary:

 /*************************************************************
 * Grammar explanation: (cont'd)
-*   a _chain_ is a list of _elementary_s that have _link_s inbetween
+*   a _chain_ is a list of _elementary_s that have _link_s in between
 *   which are represented through infix-notation.
 *
 *	fakesrc ! sometransformation ! fakesink
--- a/Show more
+++ b/Show more