mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-12-24 09:10:36 +00:00
docs: fix some typos and add some missing links in the app dev manual
Fixes #624164.
This commit is contained in:
parent
6df8250d01
commit
a646c9b2ca
11 changed files with 56 additions and 43 deletions
|
@ -29,7 +29,7 @@
|
|||
</para>
|
||||
|
||||
<sect1 id="section-mime">
|
||||
<title>MIME-types as a way to identity streams</title>
|
||||
<title>MIME-types as a way to identify streams</title>
|
||||
<para>
|
||||
We have previously introduced the concept of capabilities as a way
|
||||
for elements (or, rather, pads) to agree on a media type when
|
||||
|
@ -513,7 +513,7 @@ cb_typefound (GstElement *typefind,
|
|||
<para>
|
||||
By doing all this, we will be able to make a simple autoplugger that
|
||||
can automatically setup a pipeline for any media type. In the example
|
||||
below, we will do this for audio only. However, we can also do this
|
||||
above, we did this for audio only. However, we can also do this
|
||||
for video to create a player that plays both audio and video.
|
||||
</para>
|
||||
<!-- example-begin dynamic.c d --><!--
|
||||
|
@ -615,7 +615,8 @@ main (gint argc,
|
|||
shortest-path-finding to make sure the most optimal pipeline is chosen,
|
||||
and so on. Basically, the features that you implement in an autoplugger
|
||||
depend on what you want to use it for. For full-blown implementations,
|
||||
see the <quote>playbin</quote> and <quote>decodebin</quote> elements.
|
||||
see the <quote>playbin</quote> and <quote>decodebin</quote> elements in
|
||||
<xref linkend="chapter-components"/>.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
|
|
@ -52,7 +52,7 @@
|
|||
need to start at 0. The pipeline, which contains the global clock that
|
||||
all elements in the pipeline will use, in addition has a <quote>base
|
||||
time</quote>, which is the clock time at the the point where media time
|
||||
is starting from zero. This timestamp is subctracted from the clock
|
||||
is starting from zero. This timestamp is subtracted from the clock
|
||||
time, and that value is returned by <function>_get_time ()</function>.
|
||||
</para>
|
||||
<para>
|
||||
|
|
|
@ -193,11 +193,13 @@ main (gint argc,
|
|||
in your application.
|
||||
</para>
|
||||
<note><para>
|
||||
New API is being developed at the moment to make data insertion and
|
||||
extraction less painful for applications. It can be found as GstAppSrc
|
||||
and GstAppSink in the gst-plugins-bad module. At the time of writing
|
||||
(October 2007), this API is not quite stable and ready yet, even though
|
||||
it may work fine for your purposes.
|
||||
<ulink type="http"
|
||||
url="http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gstreamer-app.html">New
|
||||
API</ulink> was developed to make data insertion and extraction easy
|
||||
for applications. It can be found as GstAppSrc and GstAppSink in the
|
||||
<ulink type="http"
|
||||
url="http://gstreamer.freedesktop.org/modules/gst-plugins-base.html">
|
||||
gst-plugins-base</ulink> module.
|
||||
</para></note>
|
||||
<para>
|
||||
After all those disclaimers, let's start. There's three possible
|
||||
|
@ -210,7 +212,7 @@ main (gint argc,
|
|||
pipeline, and how to set negotiation.
|
||||
</para>
|
||||
<para>
|
||||
Those who're paying close attention, will notice that the purpose
|
||||
Those who're paying close attention will notice that the purpose
|
||||
of identity is almost identical to that of probes. Indeed, this is
|
||||
true. Probes allow for the same purpose, and a bunch more, and
|
||||
with less overhead plus dynamic removing/adding of handlers, but
|
||||
|
@ -254,7 +256,7 @@ main (gint argc,
|
|||
specifying a <classname>GstCaps</classname> as
|
||||
<quote>caps</quote> property on this element. It will then
|
||||
only allow types matching that specified capability set for
|
||||
negotiation.
|
||||
negotiation. See also <xref linkend="section-caps-filter"/>.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
|
|
|
@ -1,16 +1,16 @@
|
|||
<chapter id="chapter-dparams">
|
||||
<title>Dynamic Controllable Parameters</title>
|
||||
|
||||
<sect1 id="section-dparams-getting-started">
|
||||
<title>Getting Started</title>
|
||||
<para>
|
||||
<para>
|
||||
The controller subsystem offers a lightweight way to adjust gobject
|
||||
properties over stream-time.
|
||||
It works by using time-stamped value pairs that are queued for
|
||||
element-properties.
|
||||
At run-time the elements continously pull values changes for the
|
||||
At run-time the elements continously pull value changes for the
|
||||
current stream-time.
|
||||
</para>
|
||||
</para>
|
||||
|
||||
<sect1 id="section-dparams-getting-started">
|
||||
<title>Getting Started</title>
|
||||
<para>
|
||||
This subsystem is contained within the
|
||||
<filename>gstcontroller</filename> library.
|
||||
|
|
|
@ -7,7 +7,9 @@
|
|||
interaction between applications and elements. This method suffices for
|
||||
the simple'n'straight settings, but fails for anything more complicated
|
||||
than a getter and setter. For the more complicated use cases, &GStreamer;
|
||||
uses interfaces based on the Glib <classname>GInterface</classname> type.
|
||||
uses interfaces based on the GObject <ulink type="http"
|
||||
url="http://library.gnome.org/devel/gobject/stable/gtype-non-instantiable-classed.html"><classname>GTypeInterface</classname></ulink>
|
||||
type.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -70,11 +72,13 @@
|
|||
You should not use this interface for volume control in a playback
|
||||
application. Either use a <classname>volume</classname> element or use
|
||||
<classname>playbin</classname>'s <quote>volume</quote> property, or use
|
||||
the audiosink's <quote>volume</quote> property (if it has one).
|
||||
the <classname>audiosink</classname>'s <quote>volume</quote> property (if it has one).
|
||||
</para>
|
||||
<note>
|
||||
<para>
|
||||
In order for the <classname>GstMixer</classname> interface to be
|
||||
In order for the <ulink type="http"
|
||||
url="http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-gstmixer.html"><classname>GstMixer</classname></ulink>
|
||||
interface to be
|
||||
usable, the element implementing it needs to be in the right state,
|
||||
so that the underlying mixer device is open. This usually means the
|
||||
element needs to be at least in <classname>GST_STATE_READY</classname>
|
||||
|
@ -94,7 +98,7 @@
|
|||
</para>
|
||||
<para>
|
||||
Using this interface, it is possible to select one track from a list
|
||||
of tracks supported by that tuner-element. The tuner will than select
|
||||
of tracks supported by that tuner-element. The tuner will then select
|
||||
that track for media-processing internally. This can, for example, be
|
||||
used to switch inputs on a TV-card (e.g. from Composite to S-video).
|
||||
</para>
|
||||
|
@ -104,7 +108,9 @@
|
|||
</para>
|
||||
<note>
|
||||
<para>
|
||||
In order for the <classname>GstTuner</classname> interface to be
|
||||
In order for the <ulink type="http"
|
||||
url="http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-gsttuner.html"><classname>GstTuner</classname></ulink>
|
||||
interface to be
|
||||
usable, the element implementing it needs to be in the right state,
|
||||
so that the underlying device is open. This usually means the
|
||||
element needs to be at least in <classname>GST_STATE_READY</classname>
|
||||
|
@ -120,7 +126,7 @@
|
|||
<para>
|
||||
The colorbalance interface is a way to control video-related properties
|
||||
on an element, such as brightness, contrast and so on. It's sole
|
||||
reason for existance is that, as far as its authors know, there's no
|
||||
reason for existence is that, as far as its authors know, there's no
|
||||
way to dynamically register properties using
|
||||
<classname>GObject</classname>.
|
||||
</para>
|
||||
|
|
|
@ -17,7 +17,7 @@
|
|||
<title>Metadata reading</title>
|
||||
|
||||
<para>
|
||||
Stream information can most easily be read by reading them from a
|
||||
Stream information can most easily be read by reading it from a
|
||||
<classname>GstPad</classname>. This has already been discussed before
|
||||
in <xref linkend="section-caps-metadata"/>. Therefore, we will skip
|
||||
it here. Note that this requires access to all pads of which you
|
||||
|
@ -155,7 +155,8 @@ main (int argc, char ** argv)
|
|||
<title>Tag writing</title>
|
||||
|
||||
<para>
|
||||
Tag writing is done using the <classname>GstTagSetter</classname>
|
||||
Tag writing is done using the <ulink type="http"
|
||||
url="&URLAPI;GstTagSetter.html"><classname>GstTagSetter</classname></ulink>
|
||||
interface. All that's required is a tag-set-supporting element in
|
||||
your pipeline. In order to see if any of the elements in your
|
||||
pipeline supports tag writing, you can use the function
|
||||
|
|
|
@ -69,7 +69,7 @@
|
|||
(if configured to do so) drop data.
|
||||
</para>
|
||||
<para>
|
||||
To use a queues (and therefore force the use of two distinct threads
|
||||
To use a queue (and therefore force the use of two distinct threads
|
||||
in the pipeline), one can simply create a <quote>queue</quote> element
|
||||
and put this in as part of the pipeline. &GStreamer; will take care of
|
||||
all threading details internally.
|
||||
|
|
|
@ -270,16 +270,17 @@ main (int argc,
|
|||
return 0;
|
||||
}
|
||||
]]><!-- example-end elementget.c --></programlisting>
|
||||
<para>
|
||||
<para>
|
||||
Most plugins provide additional properties to provide more information
|
||||
about their configuration or to configure the element.
|
||||
about their configuration or to configure the element.
|
||||
<command>gst-inspect</command> is a useful tool to query the properties
|
||||
of a particular element, it will also use property introspection to give
|
||||
a short explanation about the function of the property and about the
|
||||
parameter types and ranges it supports. See the appendix for details
|
||||
about <command>gst-inspect</command>.
|
||||
</para>
|
||||
<para>
|
||||
parameter types and ranges it supports. See
|
||||
<xref linkend="section-applications-inspect"/>
|
||||
in the appendix for details about <command>gst-inspect</command>.
|
||||
</para>
|
||||
<para>
|
||||
For more information about <classname>GObject</classname>
|
||||
properties we recommend you read the <ulink
|
||||
url="http://developer.gnome.org/doc/API/2.0/gobject/index.html"
|
||||
|
@ -288,7 +289,7 @@ main (int argc,
|
|||
The Glib Object system</ulink>.
|
||||
</para>
|
||||
<para>
|
||||
A <ulink type="http" url="&URLAPI;gstreamer/html/GstElementFactory.html">
|
||||
A <ulink type="http" url="&URLAPI;GstElementFactory.html">
|
||||
<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>
|
||||
|
|
|
@ -216,7 +216,7 @@ link_to_multiplexer (GstPad *tolink_pad,
|
|||
<sect2 id="section-caps-structure">
|
||||
<title>Dissecting capabilities</title>
|
||||
<para>
|
||||
A pads capabilities are described in a <classname>GstCaps</classname>
|
||||
A pad's capabilities are described in a <classname>GstCaps</classname>
|
||||
object. Internally, a <ulink type="http"
|
||||
url="../../gstreamer/html/gstreamer-GstCaps.html"><classname>GstCaps</classname></ulink>
|
||||
will contain one or more <ulink type="http"
|
||||
|
@ -236,8 +236,8 @@ link_to_multiplexer (GstPad *tolink_pad,
|
|||
accept vorbis-encoded audio data, with the mime-type
|
||||
<quote>audio/x-vorbis</quote>. The source pad will be used
|
||||
to send raw (decoded) audio samples to the next element, with
|
||||
a raw audio mime-type (in this case,
|
||||
<quote>audio/x-raw-int</quote>) The source pad will also
|
||||
a raw audio mime-type (in this case,
|
||||
<quote>audio/x-raw-float</quote>). The source pad will also
|
||||
contain properties for the audio samplerate and the amount of
|
||||
channels, plus some more that you don't need to worry about
|
||||
for now.
|
||||
|
@ -539,7 +539,7 @@ link_elements_with_filter (GstElement *element1, GstElement *element2)
|
|||
</programlisting>
|
||||
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
|
||||
will fail if that cannot be achieved in the context of the elements
|
||||
involved). Keep in mind that when you use <function>
|
||||
gst_element_link_filtered ()</function> it will automatically create
|
||||
a <classname>capsfilter</classname> element for you and insert it into
|
||||
|
@ -585,8 +585,10 @@ link_elements_with_filter (GstElement *element1, GstElement *element2)
|
|||
</programlisting>
|
||||
<para>
|
||||
See the API references for the full API of
|
||||
<classname>GstStructure</classname> and
|
||||
<classname>GstCaps</classname>.
|
||||
<ulink type="http"
|
||||
url="&URLAPI;GstStructure.html"><classname>GstStructure</classname></ulink>
|
||||
and <ulink type="http"
|
||||
url="&URLAPI;GstCaps.html"><classname>GstCaps</classname></ulink>.
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
|
|
@ -59,9 +59,9 @@
|
|||
through one or more <emphasis>sink pads</emphasis>. Source and sink
|
||||
elements have only source and sink pads, respectively. Data usually
|
||||
means buffers (described by the <ulink type="http"
|
||||
url="&URLAPI;/gstreamer-GstBuffer.html"><classname>GstBuffer
|
||||
url="&URLAPI;gstreamer-GstBuffer.html"><classname>GstBuffer
|
||||
</classname></ulink> object) and events (described by the <ulink
|
||||
type="http" url="&URLAPI;/gstreamer-GstEvent.html"><classname>
|
||||
type="http" url="&URLAPI;gstreamer-GstEvent.html"><classname>
|
||||
GstEvent</classname></ulink> object).
|
||||
</para>
|
||||
</sect1>
|
||||
|
|
|
@ -158,14 +158,14 @@
|
|||
<para>
|
||||
Some parts of this part will serve mostly as an explanation of
|
||||
how &GStreamer; works internally; they are not actually needed for
|
||||
actual application development. This includes chapter such as the
|
||||
actual application development. This includes chapters such as the
|
||||
ones covering scheduling, autoplugging and synchronization. Other
|
||||
chapters, however, discuss more advanced ways of
|
||||
pipeline-application interaction, and can turn out to be very useful
|
||||
for certain applications. This includes the chapters on metadata,
|
||||
querying and events, interfaces, dynamic parameters and pipeline
|
||||
data manipulation.
|
||||
</para>
|
||||
</para>
|
||||
</partintro>
|
||||
|
||||
&QUERYEVENTS;
|
||||
|
|
Loading…
Reference in a new issue