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

fix up id's

Browse source 
Original commit message from CVS:
fix up id's
This commit is contained in:
Thomas Vander Stichele 2004-01-28 15:51:14 +00:00
parent 97cd7e6e5d
commit 5b00b55793
25 changed files with 133 additions and 105 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

28
ChangeLog
View file

@ -1,3 +1,31 @@
2004-01-28 Thomas Vander Stichele <thomas at apestaart dot org>
* docs/pwg/advanced-clock.xml:
* docs/pwg/advanced-dparams.xml:
* docs/pwg/advanced-events.xml:
* docs/pwg/advanced-interfaces.xml:
* docs/pwg/advanced-midi.xml:
* docs/pwg/advanced-request.xml:
* docs/pwg/advanced-scheduling.xml:
* docs/pwg/advanced-tagging.xml:
* docs/pwg/advanced-types.xml:
* docs/pwg/appendix-checklist.xml:
* docs/pwg/building-boiler.xml:
* docs/pwg/building-chainfn.xml:
* docs/pwg/building-filterfactory.xml:
* docs/pwg/building-pads.xml:
* docs/pwg/building-props.xml:
* docs/pwg/building-signals.xml:
* docs/pwg/building-state.xml:
* docs/pwg/building-testapp.xml:
* docs/pwg/intro-basics.xml:
* docs/pwg/intro-preface.xml:
* docs/pwg/other-autoplugger.xml:
* docs/pwg/other-sink.xml:
* docs/pwg/other-source.xml:
* docs/pwg/titlepage.xml:
fix up id's
2004-01-28 Thomas Vander Stichele <thomas at apestaart dot org>
* docs/95NonPath:

2
docs/pwg/advanced-clock.xml
View file

@ -1,4 +1,4 @@
<chapter id="cha-advanced-clock">
<chapter id="chapter-advanced-clock">
<title>Clocking</title>
<para>
WRITEME

20
docs/pwg/advanced-dparams.xml
View file

@ -1,7 +1,7 @@
<!-- ############ chapter ############# -->
<chapter id="cha-dparams">
<chapter id="chapter-dparams">
<title>Supporting Dynamic Parameters</title>
<para>
Sometimes object properties are not powerful enough to control the
@ -14,7 +14,7 @@
as an abbreviation for "Dynamic Parameters".
</para>
<sect1 id="sect-dparams-compare">
<sect1 id="section-dparams-compare">
<title>Comparing Dynamic Parameters with GObject Properties</title>
<para>
Your first exposure to dparams may be to convert an existing element from
@ -57,7 +57,7 @@
</informaltable>
</sect1>
<sect1 id="sect-dparam-start">
<sect1 id="section-dparam-start">
<title>Getting Started</title>
<para>
@ -123,7 +123,7 @@
</programlisting>
</sect1>
<sect1 id="sect-dparam-define">
<sect1 id="section-dparam-define">
<title>Defining Parameter Specificiations</title>
<para>
You can define the dparams you need anywhere within your element but will
@ -197,7 +197,7 @@
</listitem>
</itemizedlist>
</para>
<sect2 id="sect-dparam-direct">
<sect2 id="section-dparam-direct">
<title>Direct Method</title>
<para>
This method is the simplest and has the lowest overhead for parameters
@ -236,7 +236,7 @@
element knowing that it will always contain the correct value to use.
</para>
</sect2>
<sect2 id="sect-dparam-callback">
<sect2 id="section-dparam-callback">
<title>Callback Method</title>
<para>
This should be used if the you have other values to calculate whenever a
@ -305,7 +305,7 @@ gst_example_update_volume(GValue *value, gpointer data)
will always contain the correct value.
</para>
</sect2>
<sect2 id="sect-dparam-array">
<sect2 id="section-dparam-array">
<title>Array Method</title>
<para>
This method is quite different from the other two. It could be thought of
@ -340,7 +340,7 @@ gst_example_update_volume(GValue *value, gpointer data)
</sect2>
</sect1>
<sect1 id="cha-dparam-loop">
<sect1 id="chapter-dparam-loop">
<title>The Data Processing Loop</title>
<para>
This is the most critical aspect of the dparams subsystem as it relates to
@ -439,7 +439,7 @@ example_chain (GstPad *pad, GstBuffer *buf)
<filename>GST_DPMAN_PREPROCESS</filename> depending on the mode that the
dparam manager is running in (see below).
</para>
<sect2 id="sect-dparam-modes">
<sect2 id="section-dparam-modes">
<title>DParam Manager Modes</title>
<para>
A brief explanation of dparam manager modes might be useful here even
@ -490,7 +490,7 @@ example_chain (GstPad *pad, GstBuffer *buf)
parameter updates
</para>
</sect2>
<sect2 id="sect-dparam-audio-video">
<sect2 id="section-dparam-audio-video">
<title>DParam Manager Modes</title>
<para>
All of the explanation so far has presumed that the buffer contains audio

2
docs/pwg/advanced-events.xml
View file

@ -1,4 +1,4 @@
<chapter id="cha-advanced-events">
<chapter id="chapter-advanced-events">
<title>Events: Seeking, Navigation and More</title>
<para>
WRITEME

24
docs/pwg/advanced-interfaces.xml
View file

@ -1,7 +1,7 @@
<chapter id="cha-advanced-interfaces">
<chapter id="chapter-advanced-interfaces">
<title>Interfaces</title>
<para>
Previously, in the chapter <xref linkend="cha-building-args"/>, we have
Previously, in the chapter <xref linkend="chapter-building-args"/>, we have
introduced the concept of GObject properties of controlling an element's
behaviour. This is a very powerful, but has two big disadvantage: firstly,
it is too generic, and secondly, it isn't dynamic.
@ -47,7 +47,7 @@
commandline (<filename>gst-launch</filename>).
</para>
<sect1 id="sect1-iface-general" xreflabel="How to Implement Interfaces">
<sect1 id="section-iface-general" xreflabel="How to Implement Interfaces">
<title>How to Implement Interfaces</title>
<para>
Implementing interfaces is intiated in the <function>_get_type ()</function>
@ -64,7 +64,7 @@
wanting to support. The example below explains how to add support for a
simple interface with no further dependencies. For a small explanation
on <classname>GstImplementsInterface</classname>, see the next section
about the mixer interface: <xref linkend="sect1-iface-mixer"/>.
about the mixer interface: <xref linkend="section-iface-mixer"/>.
</para>
<programlisting>
static void gst_my_filter_some_interface_init (GstSomeInterface *iface);
@ -112,7 +112,7 @@ gst_my_filter_some_interface_init (GstSomeInterface *iface)
</programlisting>
</sect1>
<sect1 id="sect1-iface-mixer" xreflabel="Mixer Interface">
<sect1 id="section-iface-mixer" xreflabel="Mixer Interface">
<title>Mixer Interface</title>
<para>
The goal of the mixer interface is to provide a simple yet powerful API
@ -269,26 +269,26 @@ gst_my_filter_mixer_interface_init (GstMixerClass *iface)
</programlisting>
</sect1>
<sect1 id="sect1-iface-tuner" xreflabel="Tuner Interface">
<sect1 id="section-iface-tuner" xreflabel="Tuner Interface">
<title>Tuner Interface</title>
<para>
WRITEME
</para>
</sect1>
<sect1 id="sect1-iface-colorbalance" xreflabel="Color Balance Interface">
<sect1 id="section-iface-colorbalance" xreflabel="Color Balance Interface">
<title>Color Balance Interface</title>
<para>
WRITEME
</para>
</sect1>
<sect1 id="sect1-iface-propprobe" xreflabel="Property Probe Interface">
<sect1 id="section-iface-propprobe" xreflabel="Property Probe Interface">
<title>Property Probe Interface</title>
<para>
Property probing is a generic solution to the problem that properties'
value lists in an enumeration are static. We've shown enumerations in
<xref linkend="cha-building-args"/>. Property probing tries to accomplish
<xref linkend="chapter-building-args"/>. Property probing tries to accomplish
a goal similar to enumeration lists: to have a limited, explicit list of
allowed values for a property. There are two differences between
enumeration lists and probing. Firstly, enumerations only allow strings
@ -447,21 +447,21 @@ gst_my_filter_probe_interface_init (GstPropertyProbeInterface *iface)
</para>
</sect1>
<sect1 id="sect1-iface-profile" xreflabel="Profile Interface">
<sect1 id="section-iface-profile" xreflabel="Profile Interface">
<title>Profile Interface</title>
<para>
WRITEME
</para>
</sect1>
<sect1 id="sect1-iface-xoverlay" xreflabel="X Overlay Interface">
<sect1 id="section-iface-xoverlay" xreflabel="X Overlay Interface">
<title>X Overlay Interface</title>
<para>
WRITEME
</para>
</sect1>
<sect1 id="sect1-iface-navigation" xreflabel="Navigation Interface">
<sect1 id="section-iface-navigation" xreflabel="Navigation Interface">
<title>Navigation Interface</title>
<para>
WRITEME

2
docs/pwg/advanced-midi.xml
View file

@ -1,4 +1,4 @@
<chapter id="cha-advanced-midi">
<chapter id="chapter-advanced-midi">
<title>MIDI</title>
<para>
WRITEME

8
docs/pwg/advanced-request.xml
View file

@ -1,4 +1,4 @@
<chapter id="cha-advanced-request">
<chapter id="chapter-advanced-request">
<title>Request and Sometimes pads</title>
<para>
Until now, we've only dealt with pads that are always available. However,
@ -11,7 +11,7 @@
they should be disposed.
</para>
<sect1 id="sect1-reqpad-sometimes" xreflabel="Sometimes pads">
<sect1 id="section-reqpad-sometimes" xreflabel="Sometimes pads">
<title>Sometimes pads</title>
<para>
A <quote>sometimes</quote> pad is a pad that is created under certain
@ -196,7 +196,7 @@ gst_my_filter_loopfunc (GstElement *element)
</para>
</sect1>
<sect1 id="sect1-reqpad-request" xreflabel="Request pads">
<sect1 id="section-reqpad-request" xreflabel="Request pads">
<title>Request pads</title>
<para>
<quote>Request</quote> pads are similar to sometimes pads, except that
@ -261,7 +261,7 @@ gst_my_filter_request_new_pad (GstElement *element,
</programlisting>
<para>
The <function>_loop ()</function> function is the same as the one given
previously in <xref linkend="sect1-loopfn-multiinput"/>.
previously in <xref linkend="section-loopfn-multiinput"/>.
</para>
</sect1>
</chapter>

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

@ -1,4 +1,4 @@
<chapter id="cha-loopbased-sched">
<chapter id="chapter-loopbased-sched">
<title>How scheduling works</title>
<para>
Scheduling is, in short, a method for making sure that every element gets
@ -22,7 +22,7 @@
element (a <classname>DECOUPLED</classname> element) in between them.
</para>
<sect1 id="sect1-sched-basic" xreflabel="The Basic Scheduler">
<sect1 id="section-sched-basic" xreflabel="The Basic Scheduler">
<title>The Basic Scheduler</title>
<para>
The <emphasis>basic</emphasis> scheduler assumes that each element is its
@ -55,7 +55,7 @@
</para>
</sect1>
<sect1 id="sect1-sched-opt" xreflabel="The Optimal Scheduler">
<sect1 id="section-sched-opt" xreflabel="The Optimal Scheduler">
<title>The Optimal Scheduler</title>
<para>
The <emphasis>optimal</emphasis> scheduler takes advantage of the fact that
@ -86,7 +86,7 @@
</sect1>
</chapter>
<chapter id="cha-loopbased-loopfn">
<chapter id="chapter-loopbased-loopfn">
<title>How a loopfunc works</title>
<para>
A <function>_loop ()</function> function is a function that is called by
@ -139,7 +139,7 @@ gst_my_filter_loopfunc (GstElement *element)
introduction to the concept.
</para>
<sect1 id="sect1-loopfn-multiinput" xreflabel="Multi-Input Elements">
<sect1 id="section-loopfn-multiinput" xreflabel="Multi-Input Elements">
<title>Multi-Input Elements</title>
<para>
Elements with multiple sink pads need to take manual control over their
@ -256,7 +256,7 @@ gst_my_filter_loopfunc (GstElement *element)
</para>
</sect1>
<sect1 id="sect1-loopfn-bytestream" xreflabel="The Bytestream Object">
<sect1 id="section-loopfn-bytestream" xreflabel="The Bytestream Object">
<title>The Bytestream Object</title>
<para>
A second type of elements that wants to be loop-based, are the so-called
@ -271,7 +271,7 @@ gst_my_filter_loopfunc (GstElement *element)
Bytestream-using elements are ususally stream parsers or demuxers. For
now, we will take a parser as an example. Demuxers require some more
magic that will be dealt with later in this guide:
<xref linkend="cha-advanced-request"/>. The goal of this parser will be
<xref linkend="chapter-advanced-request"/>. The goal of this parser will be
to parse a text-file and to push each line of text as a separate buffer
over its source pad.
</para>
@ -357,14 +357,14 @@ gst_my_filter_change_state (GstElement *element)
</para>
</sect1>
<sect1 id="sect-loopbased-secnd">
<sect1 id="section-loopbased-secnd">
<title>Adding a second output</title>
<para>
Identity is now a tee
</para>
</sect1>
<sect1 id="sect-loopbased-modappl">
<sect1 id="section-loopbased-modappl">
<title>Modifying the test application</title>
<para>
WRITEME

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

@ -1,4 +1,4 @@
<chapter id="cha-advanced-tagging">
<chapter id="chapter-advanced-tagging">
<title>Tagging (Metadata and Streaminfo)</title>
<para>
Tags are pieces of information stored in a stream that are not the content
@ -37,14 +37,14 @@
element supporting both can be used in a tag editor for quick tag changing.
</para>
<sect1 id="sect-tagging-read" xreflabel="Reading Tags from Streams">
<sect1 id="section-tagging-read" xreflabel="Reading Tags from Streams">
<title>Reading Tags from Streams</title>
<para>
WRITEME
</para>
</sect1>
<sect1 id="sect-tagging-write" xreflabel="Writing Tags to Streams">
<sect1 id="section-tagging-write" xreflabel="Writing Tags to Streams">
<title>Writing Tags to Streams</title>
<para>
WRITEME

10
docs/pwg/advanced-types.xml
View file

@ -1,6 +1,6 @@
<!-- ############ chapter ############# -->
<chapter id="cha-building-types">
<chapter id="chapter-building-types">
<title>Types and Properties</title>
<para>
There is a very large set of possible types that may be used to pass data
@ -56,11 +56,11 @@
<!-- ############ sect1 ############# -->
<sect1 id="sect1-types-test" xreflabel="Building a Simple Format for Testing">
<sect1 id="section-types-test" xreflabel="Building a Simple Format for Testing">
<title>Building a Simple Format for Testing</title>
<para>
If you need a new format that has not yet been defined in our <xref
linkend="sect1-types-definitions"/>, you will want to have some general
linkend="section-types-definitions"/>, you will want to have some general
guidelines on mimetype naming, properties and such. A mimetype would
ideally be one defined by IANA; else, it should be in the form
type/x-name, where type is the sort of data this mimetype handles (audio,
@ -83,7 +83,7 @@
<!-- ############ sect1 ############# -->
<sect1 id="sect1-types-typefind" xreflabel="Typefind Functions and Autoplugging">
<sect1 id="section-types-typefind" xreflabel="Typefind Functions and Autoplugging">
<title>Typefind Functions and Autoplugging</title>
<para>
WRITEME
@ -92,7 +92,7 @@
<!-- ############ sect1 ############# -->
<sect1 id="sect1-types-definitions" xreflabel="List of Defined Types">
<sect1 id="section-types-definitions" xreflabel="List of Defined Types">
<title>List of Defined Types</title>
<para>
Below is a list of all the defined types in &GStreamer;. They are split

6
docs/pwg/appendix-checklist.xml
View file

@ -1,4 +1,4 @@
<chapter id="cha-checklist-element">
<chapter id="chapter-checklist-element">
<title>
Things to check when writing an element
</title>
@ -8,14 +8,14 @@
This function should also be called from _init.
</para>
</chapter>
<chapter id="cha-checklist-filter">
<chapter id="chapter-checklist-filter">
<title>
Things to check when writing a filter
</title>
<para>
</para>
</chapter>
<chapter id="cha-checklist-srcsink">
<chapter id="chapter-checklist-srcsink">
<title>
Things to check when writing a source or sink
</title>

18
docs/pwg/building-boiler.xml
View file

@ -1,6 +1,6 @@
<!-- ############ chapter ############# -->
<chapter id="cha-building-boiler" xreflabel="Constructing the Boilerplate">
<chapter id="chapter-building-boiler" xreflabel="Constructing the Boilerplate">
<title>Constructing the Boilerplate</title>
<para>
In this chapter you will learn how to construct the bare minimum code for a
@ -14,7 +14,7 @@
<!-- ############ sect1 ############# -->
<sect1 id="sect1-boiler-source" xreflabel="Getting the GStreamer Plugin Templates">
<sect1 id="section-boiler-source" xreflabel="Getting the GStreamer Plugin Templates">
<title>Getting the GStreamer Plugin Templates</title>
<para>
There are currently two ways to develop a new plugin for &GStreamer;: You
@ -62,7 +62,7 @@ U gst-template/gst-app/src/Makefile.am
<!-- ############ sect1 ############# -->
<sect1 id="sect1-boiler-project-stamp" xreflabel="Using the Project Stamp">
<sect1 id="section-boiler-project-stamp" xreflabel="Using the Project Stamp">
<title>Using the Project Stamp</title>
<para>
The first thing to do when making a new element is to specify some basic
@ -115,7 +115,7 @@ U gst-template/gst-app/src/Makefile.am
<!-- ############ sect1 ############# -->
<sect1 id="sect1-boiler-examine">
<sect1 id="section-boiler-examine">
<title>Examining the Basic Code</title>
<para>
First we will examine the code you would be likely to place in a header
@ -167,7 +167,7 @@ U gst-template/gst-app/src/Makefile.am
<!-- ############ sect1 ############# -->
<sect1 id="sect1-boiler-details">
<sect1 id="section-boiler-details">
<title>GstElementDetails</title>
<para>
The GstElementDetails structure gives a heirarchical type for the element,
@ -222,7 +222,7 @@ gst_my_filter_base_init (GstMyFilterClass *klass)
<!-- ############ sect1 ############# -->
<sect1 id="sect1-boiler-padtemplates">
<sect1 id="section-boiler-padtemplates">
<title>GstStaticPadTemplate</title>
<para>
A GstStaticPadTemplate is a description of a pad that the element will
@ -317,13 +317,13 @@ GST_STATIC_PAD_TEMPLATE (
Multiple sets of types are supported too, and should be separated by
a semicolon (<quote>;</quote>). Later, in the chapter on pads, we will
see how to use types to know the exact format of a stream:
<xref linkend="cha-building-pads"/>.
<xref linkend="chapter-building-pads"/>.
</para>
</sect1>
<!-- ############ sect1 ############# -->
<sect1 id="sect1-boiler-constructors">
<sect1 id="section-boiler-constructors">
<title>Constructor Functions</title>
<para>
Each element has three functions which are used for construction of an
@ -339,7 +339,7 @@ GST_STATIC_PAD_TEMPLATE (
<!-- ############ sect1 ############# -->
<sect1 id="sect1-boiler-plugininit">
<sect1 id="section-boiler-plugininit">
<title>The plugin_init function</title>
<para>
Once we have written code defining all the parts of the plugin, we need to

2
docs/pwg/building-chainfn.xml
View file

@ -1,7 +1,7 @@
<!-- ############ chapter ############# -->
<chapter id="cha-building-chainfn">
<chapter id="chapter-building-chainfn">
<title>The chain function</title>
<para>
The chain function is the function in which all data processing takes

2
docs/pwg/building-filterfactory.xml
View file

@ -1,4 +1,4 @@
<chapter id="cha-building-filterfactory">
<chapter id="chapter-building-filterfactory">
<title>Creating a Filter with a Filter Factory</title>
<para>
A plan for the future is to create a FilterFactory, to make the process of making a new filter a simple process of specifying a few details, and

10
docs/pwg/building-pads.xml
View file

@ -1,7 +1,7 @@
<!-- ############ chapter ############# -->
<chapter id="cha-building-pads">
<chapter id="chapter-building-pads">
<title>Specifying the pads</title>
<para>
As explained before, pads are the port through which data goes in and out
@ -56,13 +56,13 @@ gst_my_filter_init (GstMyFilter *filter)
}
</programlisting>
<sect1 id="sect-pads-linkfn" xreflabel="The link function">
<sect1 id="section-pads-linkfn" xreflabel="The link function">
<title>The link function</title>
<para>
The <function>_link ()</function> is called during caps negotiation. This
is the process where the linked pads decide on the streamtype that will
transfer between them. A full list of type-definitions can be found in
<xref linkend="cha-building-types"/>. A <function>_link ()</function>
<xref linkend="chapter-building-types"/>. A <function>_link ()</function>
receives a pointer to a <classname>GstCaps</classname> struct that
defines the proposed streamtype, and can respond with either
<quote>yes</quote> (<classname>GST_PAD_LINK_OK</classname>),
@ -130,7 +130,7 @@ gst_my_filter_link (GstPad *pad,
</para>
</sect1>
<sect1 id="sect-pads-getcapsfn" xreflabel="The getcaps function">
<sect1 id="section-pads-getcapsfn" xreflabel="The getcaps function">
<title>The getcaps function</title>
<para>
The <function>_getcaps ()</function> funtion is used to request the list
@ -177,7 +177,7 @@ gst_my_filter_getcaps (GstPad *pad)
</programlisting>
</sect1>
<sect1 id="sect-pads-explicitcaps" xreflabel="Explicit caps">
<sect1 id="section-pads-explicitcaps" xreflabel="Explicit caps">
<title>Explicit caps</title>
<para>
Obviously, many elements will not need this complex mechanism, because they

2
docs/pwg/building-props.xml
View file

@ -1,6 +1,6 @@
<!-- ############ chapter ############# -->
<chapter id="cha-building-args" xreflabel="Adding Arguments">
<chapter id="chapter-building-args" xreflabel="Adding Arguments">
<title>Adding Arguments</title>
<para>
The primary and most important way of controlling how an element behaves,

2
docs/pwg/building-signals.xml
View file

@ -1,7 +1,7 @@
<!-- ############ chapter ############# -->
<chapter id="cha-building-signals">
<chapter id="chapter-building-signals">
<title>Signals</title>
<para>
Signals can be used to notify applications of events specific to this

4
docs/pwg/building-state.xml
View file

@ -1,4 +1,4 @@
<chapter id="cha-statemanage-states">
<chapter id="chapter-statemanage-states">
<title>
What are states?
</title>
@ -54,7 +54,7 @@
reverse transition (<classname>GST_STATE_PLAYING_TO_PAUSED</classname>).
</para>
<sect1 id="sect1-statemanage-filters">
<sect1 id="section-statemanage-filters">
<title>
Mangaging filter state
</title>

2
docs/pwg/building-testapp.xml
View file

@ -1,6 +1,6 @@
<!-- ############ chapter ############# -->
<chapter id="cha-building-testapp">
<chapter id="chapter-building-testapp">
<title>Building a Test Application</title>
<para>
Often, you will want to test your newly written plugin in an as small

12
docs/pwg/intro-basics.xml
View file

@ -1,6 +1,6 @@
<!-- ############ chapter ############# -->
<chapter id="cha-intro-basics" xreflabel="Basic Concepts">
<chapter id="chapter-intro-basics" xreflabel="Basic Concepts">
<title>Basic Concepts</title>
<para>
This chapter of the guide introduces the basic concepts of &GStreamer;.
@ -12,7 +12,7 @@
<!-- ############ sect1 ############# -->
<sect1 id="sect1-basics-elements" xreflabel="Elements and Plugins">
<sect1 id="section-basics-elements" xreflabel="Elements and Plugins">
<title>Elements and Plugins</title>
<para>
Elements are at the core of &GStreamer;. In the context of plugin
@ -64,7 +64,7 @@
<!-- ############ sect1 ############# -->
<sect1 id="sect1-basics-pads" xreflabel="Pads">
<sect1 id="section-basics-pads" xreflabel="Pads">
<title>Pads</title>
<para>
<emphasis>Pads</emphasis> are used to negotiate links and data flow
@ -103,7 +103,7 @@
<!-- ############ sect1 ############# -->
<sect1 id="sect1-basics-data" xreflabel="Data, Buffers and Events">
<sect1 id="section-basics-data" xreflabel="Data, Buffers and Events">
<title>Data, Buffers and Events</title>
<para>
All streams of data in &GStreamer; are chopped up into chunks that are
@ -230,7 +230,7 @@
<!-- ############ sect1 ############# -->
<sect1 id="sect1-basics-types" xreflabel="Types and Properties">
<sect1 id="section-basics-types" xreflabel="Types and Properties">
<title>Mimetypes and Properties</title>
<para>
&GStreamer; uses a type system to ensure that the data passed between
@ -251,7 +251,7 @@
&GStreamer;. The table contains the name ("mime type") and a
description of the type, the properties associated with the type, and
the meaning of each property. A full list of supported types is
included in <xref linkend="sect1-types-definitions"/>.
included in <xref linkend="section-types-definitions"/>.
</para>
<table frame="all" id="table-basictypes" xreflabel="Table of Basic Types">

50
docs/pwg/intro-preface.xml
View file

@ -1,12 +1,12 @@
<!-- ############ chapter ############# -->
<chapter id="cha-intro-preface" xreflabel="Preface">
<chapter id="chapter-intro-preface" xreflabel="Preface">
<title>Preface</title>
<!-- ############ sect1 ############# -->
<sect1 id="sect1-preface-who" xreflabel="Who Should Read This Guide?">
<sect1 id="section-preface-who" xreflabel="Who Should Read This Guide?">
<title>Who Should Read This Guide?</title>
<para>
This guide explains how to write new modules for &GStreamer;. The guide is
@ -52,7 +52,7 @@
<!-- ############ sect1 ############# -->
<sect1 id="sect1-preface-reading" xreflabel="Preliminary Reading">
<sect1 id="section-preface-reading" xreflabel="Preliminary Reading">
<title>Preliminary Reading</title>
<para>
This guide assumes that you are somewhat familiar with the basic workings
@ -75,7 +75,7 @@
<!-- ############ sect1 ############# -->
<sect1 id="sect1-preface-structure" xreflabel="Structure of This Guide">
<sect1 id="section-preface-structure" xreflabel="Structure of This Guide">
<title>Structure of This Guide</title>
<para>
To help you navigate through this guide, it is divided into several large
@ -93,12 +93,12 @@
<para>
This part covers all the basic steps you generally need to perform to
build a plugin. The discussion begins by giving examples of generating
the basic structures with <xref linkend="cha-building-boiler"/>. Then
the basic structures with <xref linkend="chapter-building-boiler"/>. Then
you will learn how to write the code to get a basic filter plugin
working: These steps include chapters on <xref
linkend="cha-building-types"/>, <xref linkend="cha-building-pads"/>,
<xref linkend="cha-building-chainfn"/>, and <!-- <xref
linkend="cha-building-state"/>--> (WRITEME: building state).
linkend="chapter-building-types"/>, <xref linkend="chapter-building-pads"/>,
<xref linkend="chapter-building-chainfn"/>, and <!-- <xref
linkend="chapter-building-state"/>--> (WRITEME: building state).
</para>
<para>
After you have finished the first steps, you will be able to create a
@ -106,10 +106,10 @@
functionality you need. To provide some standard functionality, you
will learn how to add more features to a new plugin. These features
are described in the chapters on
<!--FIXME: WRITEME <xref linkend="cha-building-props"/> -->
<!--FIXME: WRITEME <xref linkend="chapter-building-props"/> -->
(WRITEME)
and <xref linkend="cha-building-signals"/>. Finally, you will see in
<!--<xref linkend="cha-building-testapp"/>-->(WRITEME)
and <xref linkend="chapter-building-signals"/>. Finally, you will see in
<!--<xref linkend="chapter-building-testapp"/>-->(WRITEME)
how to write a short test
application to try out your new plugin.
</para>
@ -124,11 +124,11 @@
functional audio or video filter plugin with some nice features.
However, &GStreamer; offers more for plugin writers. This part of the
guide includes chapters on more advanced topics, such as <xref
linkend="cha-advanced-request"/>, <!-- <xref
linkend="cha-advanced-clock"/>, <xref
linkend="cha-advanced-scheduling"/>, <xref
linkend="cha-advanced-dparams"/>, and <xref
linkend="cha-advanced-midi"/>-->. Since these features are more advanced,
linkend="chapter-advanced-request"/>, <!-- <xref
linkend="chapter-advanced-clock"/>, <xref
linkend="chapter-advanced-scheduling"/>, <xref
linkend="chapter-advanced-dparams"/>, and <xref
linkend="chapter-advanced-midi"/>-->. Since these features are more advanced,
the chapters can basically be read in any order, as you find that your
plugins require these features.
</para>
@ -144,10 +144,10 @@
the concepts apply equally to other plugin types, including sources,
sinks, and autopluggers. This part of the guide presents the issues
that arise when working on these more specialized plugin types. The
part includes chapters on <xref linkend="cha-other-source"/>, <xref
linkend="cha-other-sink"/>, <!-- FIXME: WRITEME
<xref linkend="cha-other-scheduler"/>,--> and
<xref linkend="cha-other-autoplugger"/>.
part includes chapters on <xref linkend="chapter-other-source"/>, <xref
linkend="chapter-other-sink"/>, <!-- FIXME: WRITEME
<xref linkend="chapter-other-scheduler"/>,--> and
<xref linkend="chapter-other-autoplugger"/>.
</para>
</listitem>
<listitem>
@ -159,9 +159,9 @@
The appendices contain some information that stubbornly refuses to fit
cleanly in other sections of the guide. This information includes
<!-- FIXME: WRITEME
<xref linkend="cha-appendix-checklist"/>--> (WRITEME) and
<xref linkend="chapter-appendix-checklist"/>--> (WRITEME) and
<!-- <xref
linkend="cha-appendix-python"/>.--> FIXME: organize better.
linkend="chapter-appendix-python"/>.--> FIXME: organize better.
</para>
</listitem>
</itemizedlist>
@ -169,9 +169,9 @@
<para>
The remainder of this introductory part of the guide presents a short
overview of the basic concepts involved in &GStreamer; plugin development.
Topics covered include <xref linkend="sect1-basics-elements"/>, <xref
linkend="sect1-basics-pads"/>, <xref linkend="sect1-basics-data"/> and
<xref linkend="sect1-basics-types"/>. If you are already familiar with
Topics covered include <xref linkend="section-basics-elements"/>, <xref
linkend="section-basics-pads"/>, <xref linkend="section-basics-data"/> and
<xref linkend="section-basics-types"/>. If you are already familiar with
this information, you can use this short overview to refresh your memory,
or you can skip to <xref linkend="part-building"/>.
</para>

2
docs/pwg/other-autoplugger.xml
View file

@ -1,7 +1,7 @@
<!-- ############ chapter ############# -->
<chapter id="cha-other-autoplugger" xreflabel="Writing an Autoplugger">
<chapter id="chapter-other-autoplugger" xreflabel="Writing an Autoplugger">
<title>Writing an Autoplugger</title>
<para>
FIXME: write.

2
docs/pwg/other-sink.xml
View file

@ -1,7 +1,7 @@
<!-- ############ chapter ############# -->
<chapter id="cha-other-sink" xreflabel="Writing a Sink">
<chapter id="chapter-other-sink" xreflabel="Writing a Sink">
<title>Writing a Sink</title>
<para>
FIXME: write.

2
docs/pwg/other-source.xml
View file

@ -1,7 +1,7 @@
<!-- ############ chapter ############# -->
<chapter id="cha-other-source" xreflabel="Writing a Source">
<chapter id="chapter-other-source" xreflabel="Writing a Source">
<title>Writing a Source</title>
<para>
FIXME: write.

2
docs/pwg/titlepage.xml
View file

@ -54,7 +54,7 @@
</author>
</authorgroup>
<legalnotice id="legalnotice">
<legalnotice id="misc-legalnotice">
<para>
This material may be distributed only subject to the terms and
conditions set forth in the Open Publication License, v1.0 or later (the