From: Tim-Philipp Müller <tim@centricular.net>
Date: Wed, 19 Jul 2006 12:40:54 +0000 (+0000)
Subject: Fix typos (#348000).
X-Git-Tag: RELEASE-0_10_10~127
X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=5014b37cd388343f8d9039fefa4af770f4530a08;p=platform%2Fupstream%2Fgstreamer.git

Fix typos (#348000).

Original commit message from CVS:
* docs/pwg/advanced-scheduling.xml:
* gst/gstpad.c:
Fix typos (#348000).
---

diff --git a/ChangeLog b/ChangeLog
index f8ebcb1..a364935 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2006-07-19  Tim-Philipp Müller  <tim at centricular dot net>
+
+	* docs/pwg/advanced-scheduling.xml:
+	* gst/gstpad.c:
+	  Fix typos (#348000).
+
 2006-07-18  Tim-Philipp Müller  <tim at centricular dot net>
 
 	* docs/pwg/intro-basics.xml:
diff --git a/docs/pwg/advanced-scheduling.xml b/docs/pwg/advanced-scheduling.xml
index f24c492..bd3529a 100644
--- a/docs/pwg/advanced-scheduling.xml
+++ b/docs/pwg/advanced-scheduling.xml
@@ -3,7 +3,7 @@
   <para>
     Scheduling is, in short, a method for making sure that every element gets
     called once in a while to process data and prepare data for the next
-    element. Likewise, a kernel has a scheduler to for processes, and your
+    element. Likewise, a kernel has a scheduler for processes, and your
     brain is a very complex scheduler too in a way.
     Randomly calling elements' chain functions won't bring us far, however, so
     you'll understand that the schedulers in &GStreamer; are a bit more complex
@@ -11,8 +11,8 @@
   </para>
   <para>
     So far, we have only discussed <function>_chain ()</function>-operating
-    elements, i.e. elements that have a chain-function set on their sinkpad
-    and push buffers on their sinkpad. Pads (or elements) can also operate
+    elements, i.e. elements that have a chain-function set on their sink pad
+    and push buffers on their source pad(s). Pads (or elements) can also operate
     in two other scheduling modes, however. In this chapter, we will discuss
     what those scheduling modes are, how they can be enabled and in what
     cases they are useful. The other two scheduling modes are random access
diff --git a/gst/gstpad.c b/gst/gstpad.c
index 12e0306..ca4127e 100644
--- a/gst/gstpad.c
+++ b/gst/gstpad.c
@@ -1622,7 +1622,7 @@ was_empty:
  * This check is required so that we don't try to link
  * pads from elements in different bins without ghostpads.
  *
- * The LOCK should be helt on both pads
+ * The LOCK should be held on both pads
  */
 static gboolean
 gst_pad_link_check_hierarchy (GstPad * src, GstPad * sink)
@@ -3111,7 +3111,7 @@ gst_ghost_pad_save_thyself (GstPad * pad, xmlNodePtr parent)
 #endif /* GST_DISABLE_LOADSAVE */
 
 /*
- * should be called with pad OBJECT_LOCK and STREAM_LOCK helt. 
+ * should be called with pad OBJECT_LOCK and STREAM_LOCK held. 
  * GST_PAD_IS_BLOCK (pad) == TRUE when this function is
  * called.
  *
@@ -3125,7 +3125,7 @@ gst_ghost_pad_save_thyself (GstPad * pad, xmlNodePtr parent)
  * Two methods are available for notifying the application of the
  * block: 
  * - the callback method, which happens in the STREAMING thread with
- *   the STREAM_LOCK helt. With this method, the most usefull way of
+ *   the STREAM_LOCK held. With this method, the most usefull way of
  *   dealing with the callback is to post a message to the main thread
  *   where the pad block can then be handled outside of the streaming
  *   thread. With the last method one can perform all operations such