mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2025-02-04 05:22:30 +00:00
docs/manual/: Typo and formatting fixes (#538594).
Original commit message from CVS: 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).
This commit is contained in:
parent
7c0bd009ce
commit
7dd35f98f7
10 changed files with 38 additions and 23 deletions
15
ChangeLog
15
ChangeLog
|
@ -1,3 +1,18 @@
|
|||
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):
|
||||
|
|
|
@ -86,7 +86,7 @@ static GOptionEntries cmd_options[] = {
|
|||
* 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" },
|
||||
|
|
|
@ -55,7 +55,7 @@ for wider use of free formats like the Xiph.org formats.
|
|||
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>
|
||||
|
@ -77,7 +77,7 @@ exception clause and thus code can be shared more freely.
|
|||
</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
|
||||
|
|
|
@ -16,7 +16,7 @@
|
|||
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.
|
||||
|
@ -292,7 +292,7 @@ main (int argc,
|
|||
<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>
|
||||
|
|
|
@ -30,7 +30,7 @@
|
|||
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>.
|
||||
|
@ -156,7 +156,7 @@ main (int argc,
|
|||
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);
|
||||
|
|
|
@ -537,7 +537,7 @@ link_elements_with_filter (GstElement *element1, GstElement *element2)
|
|||
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>
|
||||
|
|
|
@ -2,8 +2,8 @@
|
|||
<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
|
||||
|
@ -17,7 +17,7 @@
|
|||
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>
|
||||
|
@ -37,11 +37,11 @@
|
|||
|
||||
<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>
|
||||
|
||||
|
|
|
@ -137,8 +137,8 @@ main(int argc, char *argv[])
|
|||
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>
|
||||
|
|
|
@ -31,7 +31,7 @@
|
|||
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
|
||||
|
|
|
@ -56,9 +56,9 @@
|
|||
<!-- ############ 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"
|
||||
|
@ -70,7 +70,7 @@
|
|||
<!-- ############ 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.
|
||||
|
@ -92,7 +92,7 @@
|
|||
<!-- ############ 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;
|
||||
|
@ -112,7 +112,7 @@
|
|||
</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,
|
||||
|
|
Loading…
Reference in a new issue