mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-12-23 08:46:40 +00:00
Code Issues 1 Projects Releases Wiki Activity

Fix typos (#348000).

Browse source 
Original commit message from CVS:
* docs/pwg/advanced-scheduling.xml:
* gst/gstpad.c:
Fix typos (#348000).
This commit is contained in:
Tim-Philipp Müller 2006-07-19 12:40:54 +00:00
parent 815afde246
commit 5014b37cd3
3 changed files with 12 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
ChangeLog
View file

@ -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:

6
docs/pwg/advanced-scheduling.xml
View file

@ -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

6
gst/gstpad.c
View file

@ -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