+2008-06-24 Tim-Philipp Müller <tim.muller at collabora co uk>
+
+ Patch by: Luc Pionchon <luc.pionchon@nokia.com>
+
+ * docs/manual/appendix-integration.xml:
+ * docs/manual/appendix-licensing.xml:
+ * docs/manual/basics-elements.xml:
+ * docs/manual/basics-helloworld.xml:
+ * docs/manual/basics-pads.xml:
+ * docs/manual/highlevel-components.xml:
+ * docs/manual/highlevel-xml.xml:
+ * docs/manual/intro-basics.xml:
+ * docs/manual/intro-preface.xml:
+ Typo and formatting fixes (#538594).
+
2008-06-24 Sebastian Dröge <sebastian.droege@collabora.co.uk>
* tests/check/gst/gstghostpad.c: (GST_START_TEST):
* example of how to add your own command line options here */
/* at the end we have a special option that collects all remaining
- * command line arguments (like filenames) for us. If you don'
+ * command line arguments (like filenames) for us. If you don't
* need this, you can safely remove it */
{ G_OPTION_REMAINING, 0, 0, G_OPTION_ARG_FILENAME_ARRAY, &cmd_filenames,
"Special option that collects any remaining arguments for us" },
If you do decide that you want to allow for non-free plugins to be used
with your application you have a variety of choices. One of the simplest
is using licenses like LGPL, MPL or BSD for your application instead of
-the GPL. Or you can add a exceptions clause to your GPL license stating
+the GPL. Or you can add an exception clause to your GPL license stating
that you except GStreamer plugins from the obligations of the GPL.
</para>
<para>
</para>
<para>
I have above outlined the practical reasons for why the GStreamer
-community suggest you allow non-free plugins to be used with your
+community suggests you allow non-free plugins to be used with your
applications. We feel that in the multimedia arena, the free software
community is still not strong enough to set the agenda and that blocking
non-free plugins to be used in our infrastructure hurts us more than it
For the application programmer, elements are best visualized as black
boxes. On the one end, you might put something in, the element does
something with it and something else comes out at the other side. For
- a decoder element, ifor example, you'd put in encoded data, and the
+ a decoder element, for example, you'd put in encoded data, and the
element would output decoded data. In the next chapter (see <xref
linkend="chapter-pads"/>), you will learn more about data input and
output in elements, and how you can set that up in your application.
<classname>GstElement</classname></ulink> also provides various
<classname>GObject</classname> signals that can be used as a flexible
callback mechanism. Here, too, you can use <command>gst-inspect</command>
- to see which signals a specific elements supports. Together, signals
+ to see which signals a specific element supports. Together, signals
and properties are the most basic way in which elements and
applications interact.
</para>
audio player, we'll need a source element that reads files from a
disk. &GStreamer; includes this element under the name
<quote>filesrc</quote>. Next, we'll need something to parse the
- file and decoder it into raw audio. &GStreamer; has two elements
+ file and decode it into raw audio. &GStreamer; has two elements
for this: the first parses Ogg streams into elementary streams (video,
audio) and is called <quote>oggdemux</quote>. The second is a Vorbis
audio decoder, it's conveniently called <quote>vorbisdec</quote>.
source, parser, decoder, conv, sink, NULL);
/* link together - note that we cannot link the parser and
- * decoder yet, becuse the parser uses dynamic pads. For that,
+ * decoder yet, because the parser uses dynamic pads. For that,
* we set a pad-added signal handler. */
gst_element_link (source, parser);
gst_element_link_many (decoder, conv, sink, NULL);
return link_ok;
}
</programlisting>
- This will force the data flow between those two elements to a
+ This will force the data flow between those two elements to
a certain video format, width, height and framerate (or the linking
will fail if that cannot be achieved in the context of the elments
involved). Keep in mind that when you use <function>
<title>Components</title>
<para>
- &GStreamer; includes several higher-level components to simplify your
- applications life. All of the components discussed here (for now) are
+ &GStreamer; includes several higher-level components to simplify an
+ application developer's life. All of the components discussed here (for now) are
targetted at media playback. The idea of each of these components is
to integrate as closely as possible with a &GStreamer; pipeline, but
to hide the complexity of media type detection and several other
linkend="section-components-decodebin"/>), depending on their needs.
Playbin is the recommended solution for everything related to simple
playback of media that should just work. Decodebin is a more flexible
- autoplugger that could be used to add more advanced featuers, such
+ autoplugger that could be used to add more advanced features, such
as playlist support, crossfading of audio tracks and so on. Its
programming interface is more low-level than that of playbin, though.
</para>
<para>
Setting up a playbin pipeline is as simple as creating an instance of
- the playbin element, setting a file location (this has to be a valid
- URI, so <quote><protocol>://<location></quote>, e.g.
- file:///tmp/my.ogg or http://www.example.org/stream.ogg) using the
+ the playbin element, setting a file location using the
<quote>uri</quote> property on playbin, and then setting the element
- to the <classname>GST_STATE_PLAYING</classname> state. Internally,
+ to the <classname>GST_STATE_PLAYING</classname> state (the location has to be a valid
+ URI, so <quote><protocol>://<location></quote>, e.g.
+ file:///tmp/my.ogg or http://www.example.org/stream.ogg). Internally,
playbin will set up a pipeline to playback the media location.
</para>
in the XML file.
</para>
<para>
- In addition to loading a file, you can also load a from a xmlDocPtr and
- an in memory buffer using gst_xml_parse_doc and gst_xml_parse_memory
+ In addition to loading a file, you can also load from a xmlDocPtr and
+ an in-memory buffer using gst_xml_parse_doc and gst_xml_parse_memory
respectively. Both of these methods return a gboolean indicating
success or failure of the requested action.
</para>
A <emphasis>bin</emphasis> is a container for a collection of elements.
A pipeline is a special subtype of a bin that allows execution of all
of its contained child elements. Since bins are subclasses of elements
- themselves, you can mostly control a bin as if it where an element,
+ themselves, you can mostly control a bin as if it were an element,
thereby abstracting away a lot of complexity for your application. You
can, for example change state on all elements in a bin by changing the
state of that bin itself. Bins also forward bus messages from their
<!-- ############ sect1 ############# -->
<sect1 id="section-intro-who" xreflabel="Who Should Read This Manual?">
- <title>Who Should Read This Manual?</title>
+ <title>Who should read this manual?</title>
<para>
- This book is about &GStreamer; from a developer's point of view; it
+ This book is about &GStreamer; from an application developer's point of view; it
describes how to write a &GStreamer; application using the &GStreamer;
libraries and tools. For an explanation about writing plugins, we
suggest the <ulink type="http"
<!-- ############ sect1 ############# -->
<sect1 id="section-intro-reading" xreflabel="Preliminary Reading">
- <title>Preliminary Reading</title>
+ <title>Preliminary reading</title>
<para><!-- synchronize with PWG -->
In order to understand this manual, you will need to have a basic
understanding of the C language.
<!-- ############ sect1 ############# -->
<sect1 id="section-intro-structure">
- <title>Structure of this Manual</title>
+ <title>Structure of this manual</title>
<para>
To help you navigate through this guide, it is divided into several large
parts. Each part addresses a particular broad topic concerning &GStreamer;
</para>
<para>
- In <xref linkend="part-advanced"/>, we will move on to complicated
+ In <xref linkend="part-advanced"/>, we will move on to advanced
subjects which make &GStreamer; stand out of its competitors. We
will discuss application-pipeline interaction using dynamic parameters
and interfaces, we will discuss threading and threaded pipelines,
projects / platform / upstream / gstreamer.git / commitdiff