mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-26 19:51:11 +00:00
language updates from cameron
Original commit message from CVS: language updates from cameron
This commit is contained in:
parent
121c19e9f4
commit
ef63411dc8
32 changed files with 246 additions and 236 deletions
|
@ -4,7 +4,7 @@
|
|||
The small application we created in the previous chapter used the
|
||||
concept of a factory to create the elements. In this chapter we will
|
||||
show you how to use the factory concepts to create elements based
|
||||
on what they do instead of how they are called.
|
||||
on what they do instead of what they are called.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -28,9 +28,9 @@
|
|||
<para>
|
||||
While this mechanism is quite effective it also has some big problems:
|
||||
The elements are created based on their name. Indeed, we create an
|
||||
element mad by explicitly stating the mad element's name. Our little
|
||||
element, mad, by explicitly stating the mad element's name. Our little
|
||||
program therefore always uses the mad decoder element to decode
|
||||
the MP3 audio stream, even if there are 3 other MP3 decoders in the
|
||||
the MP3 audio stream, even if there are three other MP3 decoders in the
|
||||
system. We will see how we can use a more general way to create an
|
||||
MP3 decoder element.
|
||||
</para>
|
||||
|
@ -43,14 +43,14 @@
|
|||
<sect1>
|
||||
<title>More on MIME Types</title>
|
||||
<para>
|
||||
GStreamer uses MIME types to indentify the different types of data
|
||||
GStreamer uses MIME types to identify the different types of data
|
||||
that can be handled by the elements. They are the high level
|
||||
mechanisms to make sure that everyone is talking about the right
|
||||
kind of data.
|
||||
</para>
|
||||
<para>
|
||||
A MIME (Multipurpose Internet Mail Extension) types are a set of
|
||||
string that denote a certain type of data. examples include:
|
||||
A MIME (Multipurpose Internet Mail Extension) type is a pair of
|
||||
strings that denote a certain type of data. Examples include:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
|
@ -59,12 +59,12 @@
|
|||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
audio/mpeg : mpeg audio
|
||||
audio/mpeg : MPEG audio
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
video/mpeg : mpeg video
|
||||
video/mpeg : MPEG video
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
@ -77,7 +77,7 @@
|
|||
will see.
|
||||
</para>
|
||||
<para>
|
||||
As we have seen in the previous chapter, the MIME types are added
|
||||
As we have seen in the previous chapter, MIME types are added
|
||||
to the Capability structure of a pad.
|
||||
</para>
|
||||
|
||||
|
@ -125,7 +125,7 @@
|
|||
</para>
|
||||
<para>
|
||||
There is also an association between a MIME type and a file extension,
|
||||
but the use of typefind functions (similar to file(1)) is preferred..
|
||||
but the use of typefind functions (similar to file(1)) is preferred.
|
||||
</para>
|
||||
<para>
|
||||
The type information is maintained in a list of
|
||||
|
@ -149,7 +149,7 @@ struct _GstType {
|
|||
<para>
|
||||
All operations on <classname>GstType</classname> occur
|
||||
via their <classname>guint16 id</classname> numbers, with
|
||||
<classname>GstType</classname> structure private to the GStreamer
|
||||
the <classname>GstType</classname> structure private to the GStreamer
|
||||
library.
|
||||
</para>
|
||||
|
||||
|
@ -182,7 +182,7 @@ struct _GstType {
|
|||
type = gst_type_find_by_id (id);
|
||||
</programlisting>
|
||||
<para>
|
||||
This function will return NULL if the id was associated with
|
||||
This function will return NULL if the id was not associated with
|
||||
any known <classname>GstType</classname>
|
||||
</para>
|
||||
</sect2>
|
||||
|
@ -208,7 +208,7 @@ struct _GstType {
|
|||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>creating elements with the factory</title>
|
||||
<title>Creating elements with the factory</title>
|
||||
<para>
|
||||
In the previous section we described how you could obtain
|
||||
an element factory using MIME types. One the factory has been
|
||||
|
|
|
@ -4,10 +4,10 @@
|
|||
<sect1>
|
||||
<title>Getting Started</title>
|
||||
<para>
|
||||
The dparams subsystem is contained within the
|
||||
The Dynamic Parameters subsystem is contained within the
|
||||
<filename>gstcontrol</filename> library.
|
||||
|
||||
You need to include the header in your applications's source file:
|
||||
You need to include the header in your application's source file:
|
||||
</para>
|
||||
<programlisting>
|
||||
...
|
||||
|
@ -19,9 +19,9 @@
|
|||
Your application should link to the shared library <filename>gstcontrol</filename>.
|
||||
</para>
|
||||
<para>
|
||||
The <filename>gstcontrol</filename> library needs to be initialised
|
||||
The <filename>gstcontrol</filename> library needs to be initialized
|
||||
when your application is run. This can be done after the the GStreamer
|
||||
library has been initialised.
|
||||
library has been initialized.
|
||||
</para>
|
||||
<programlisting>
|
||||
...
|
||||
|
|
|
@ -1,8 +1,8 @@
|
|||
<chapter id="cha-scheduler">
|
||||
<title>Understanding schedulers</title>
|
||||
<para>
|
||||
The scheduler is responsible for managing the plugins at runtime. The
|
||||
main responsabilities are:
|
||||
The scheduler is responsible for managing the plugins at runtime. Its
|
||||
main responsibilities are:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
|
@ -28,14 +28,14 @@
|
|||
</itemizedlist>
|
||||
</para>
|
||||
<para>
|
||||
The scheduler is a plugable component, this means that alternative
|
||||
The scheduler is a plugable component; this means that alternative
|
||||
schedulers can be written and plugged into GStreamer. The default scheduler
|
||||
uses cothreads to schedule the plugins in a pipeline. Cothreads are fast
|
||||
and lightweight user-space threads.
|
||||
</para>
|
||||
<para>
|
||||
There is usually no need to interact with the scheduler directly, however
|
||||
it some cases it is feasable to set a specific clock or force a specific
|
||||
in some cases it is feasible to set a specific clock or force a specific
|
||||
plugin as the entry point in the pipeline.
|
||||
</para>
|
||||
|
||||
|
|
|
@ -33,7 +33,7 @@
|
|||
<para>
|
||||
The above program will create a thread with two elements in it. As soon
|
||||
as it is set to the PLAYING state, the thread will start to iterate
|
||||
itself. You never need to manually iterate a thread.
|
||||
itself. You never need to explicitly iterate a thread.
|
||||
</para>
|
||||
|
||||
<sect2>
|
||||
|
@ -47,7 +47,7 @@
|
|||
between the threads, in a thread-safe fashion. This element is the
|
||||
queue, described more fully in <xref linkend="cha-queues"/>. It doesn't
|
||||
matter if the queue is placed in the containing bin or in the thread
|
||||
itself, but it needs to be present on one side of the other to enable
|
||||
itself, but it needs to be present on one side or the other to enable
|
||||
inter-thread communication.
|
||||
</para>
|
||||
</sect2>
|
||||
|
|
|
@ -35,10 +35,10 @@ gst-launch filesrc location=redpill.vob ! mpegdemux name=demux \
|
|||
|
||||
</para>
|
||||
<para>
|
||||
You can also use the the parser in you own
|
||||
You can also use the parser in you own
|
||||
code. <application>GStreamer</application> provides a function
|
||||
gst_parse_launch () that you can use to construt a pipeline.
|
||||
The following programs lets you create an mp3 pipeline using the
|
||||
gst_parse_launch () that you can use to construct a pipeline.
|
||||
The following program lets you create an MP3 pipeline using the
|
||||
gst_parse_launch () function:
|
||||
</para>
|
||||
<programlisting>
|
||||
|
@ -95,8 +95,8 @@ main (int argc, char *argv[])
|
|||
<para>
|
||||
A bare identifier (a string beginning with a letter and containing
|
||||
only letters, numbers, dashes, underscores, percent signs, or colons)
|
||||
will create an element from a given elementfactory. In this example,
|
||||
an instance of the "mad" mp3 decoding plugin will be created.
|
||||
will create an element from a given element factory. In this example,
|
||||
an instance of the "mad" MP3 decoding plugin will be created.
|
||||
</para>
|
||||
</sect3>
|
||||
<sect3>
|
||||
|
|
|
@ -12,8 +12,8 @@
|
|||
The autoplugger API is implemented in an abstract class. Autoplugger
|
||||
implementations reside in plugins and are therefore optional and can be
|
||||
optimized for a specific task. Two types of autopluggers exist: renderer
|
||||
ones and non renderer ones. the renderer autopluggers will not have any
|
||||
src pads while the non renderer ones do. The renderer autopluggers are
|
||||
ones and non-renderer ones. The renderer autopluggers will not have any
|
||||
source pads while the non-renderer ones do. The renderer autopluggers are
|
||||
mainly used for media playback while the non renderer ones are used for
|
||||
arbitrary format conversion.
|
||||
</para>
|
||||
|
@ -28,10 +28,10 @@
|
|||
A list of all available autopluggers can be obtained with gst_autoplug_factory_get_list().
|
||||
</para>
|
||||
<para>
|
||||
If the autoplugger supports the RENDERER API, use
|
||||
gst_autoplug_to_renderers() call to create a bin that connects the
|
||||
src caps to the specified render elements. You can then add the bin
|
||||
to a pipeline and run it.
|
||||
If the autoplugger supports the RENDERER API, use the
|
||||
gst_autoplug_to_renderers() function to create a bin that connects
|
||||
the source caps to the specified render elements. You can then add
|
||||
the bin to a pipeline and run it.
|
||||
|
||||
<programlisting>
|
||||
|
||||
|
@ -61,8 +61,8 @@
|
|||
</para>
|
||||
<para>
|
||||
If the autoplugger supports the CAPS API, use the gst_autoplug_to_caps()
|
||||
function to connect the src caps to the destination caps. The created
|
||||
bin will have src and sink pads compatible with the provided caps.
|
||||
function to connect the source caps to the destination caps. The created
|
||||
bin will have source and sink pads compatible with the provided caps.
|
||||
|
||||
<programlisting>
|
||||
|
||||
|
@ -108,24 +108,24 @@
|
|||
<listitem>
|
||||
<para>
|
||||
Add the autoplugcache element to a bin and connect the sink pad
|
||||
to the src pad of an element with unknown caps.
|
||||
to the source pad of an element with unknown caps.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Connect the src pad of the autoplugcache to the sink pad of the
|
||||
typefind element.
|
||||
Connect the source pad of the autoplugcache to the sink pad of
|
||||
the typefind element.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Loop the pipeline until the typefind element has found a type.
|
||||
Iterate the pipeline until the typefind element has found a type.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Remove the typefind element and add the plugins needed to play
|
||||
back the discovered media type to the autoplugcache src pad.
|
||||
back the discovered media type to the autoplugcache source pad.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
|
@ -151,9 +151,9 @@
|
|||
<title>Another approach to autoplugging</title>
|
||||
<para>
|
||||
The autoplug API is interesting, but often impractical. It is static;
|
||||
it cannot deal with dynamic pipelines (insert ref here). What one
|
||||
often wants is just an element to stick into a pipeline that will DWIM
|
||||
(ref). Enter the spider.
|
||||
it cannot deal with dynamic pipelines (insert ref here). What you
|
||||
often want is just an element to stick into a pipeline that will DWIM
|
||||
(Do What I Mean)(ref). Enter the spider.
|
||||
</para>
|
||||
<sect2>
|
||||
<title>The spider element</title>
|
||||
|
@ -179,10 +179,10 @@
|
|||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Has request pads on the src side. This means that it can autoplug
|
||||
one source stream into many sink streams. For example, a MPEG1
|
||||
system stream can have audio as well as video; that pipeline
|
||||
would be represented in gst-launch syntax as
|
||||
Has request pads on the source side. This means that it can
|
||||
autoplug one source stream into many sink streams. For example,
|
||||
an MPEG1 system stream can have audio as well as video; that
|
||||
pipeline would be represented in gst-launch syntax as
|
||||
|
||||
<programlisting>
|
||||
$ gst-launch filesrc location=my.mpeg1 ! spider ! { queue ! osssink } spider.src_%d!
|
||||
|
|
|
@ -49,8 +49,8 @@
|
|||
<sect1 id="sec-bin-create">
|
||||
<title>Creating a bin</title>
|
||||
<para>
|
||||
Bins register themselves in the GStreamer registry, so they can be
|
||||
created in the normal way:
|
||||
Bins are created in the same way that other elements are created. ie.
|
||||
using an element factory, or any of the associated convenience functions:
|
||||
</para>
|
||||
<programlisting>
|
||||
GstElement *bin, *thread, *pipeline;
|
||||
|
@ -99,7 +99,7 @@
|
|||
</programlisting>
|
||||
<para>
|
||||
You can see that the name of the element becomes very handy
|
||||
for retrieving the element from an bin by using the element's
|
||||
for retrieving the element from a bin by using the element's
|
||||
name. gst_bin_get_by_name () will recursively search nested bins.
|
||||
</para>
|
||||
<para>
|
||||
|
@ -120,7 +120,7 @@
|
|||
...
|
||||
</programlisting>
|
||||
<para>
|
||||
To remove an element from a bin use:
|
||||
To remove an element from a bin, use:
|
||||
</para>
|
||||
<programlisting>
|
||||
GstElement *element;
|
||||
|
@ -129,8 +129,8 @@
|
|||
...
|
||||
</programlisting>
|
||||
<para>
|
||||
To add many elements to a bin at the same time, try the gst_bin_add_many
|
||||
() API. Remember to pass NULL as the last argument.
|
||||
To add many elements to a bin at the same time, use the gst_bin_add_many
|
||||
() function. Remember to pass NULL as the last argument.
|
||||
</para>
|
||||
<programlisting>
|
||||
GstElement *filesrc, *decoder, *audiosink;
|
||||
|
@ -146,8 +146,8 @@
|
|||
<title>Custom bins</title>
|
||||
<para>
|
||||
The application programmer can create custom bins packed with elements
|
||||
to perform a specific task. This allow you to write an MPEG audio
|
||||
decoder with just the follwing lines of code:
|
||||
to perform a specific task. This allows you to write an MPEG audio
|
||||
decoder with just the following lines of code:
|
||||
</para>
|
||||
<programlisting>
|
||||
|
||||
|
@ -169,7 +169,8 @@
|
|||
from a <classname>GstThread</classname>, which begins to play as soon
|
||||
as its state is set to PLAYING. Other bin types may need explicit
|
||||
iteration. For more information, see <xref linkend="cha-threads"/>.
|
||||
|
||||
</para>
|
||||
<para>
|
||||
Custom bins can be created with a plugin or an XML description. You
|
||||
will find more information about creating custom bin in the Plugin
|
||||
Writers Guide (FIXME ref).
|
||||
|
@ -227,8 +228,11 @@
|
|||
</programlisting>
|
||||
<para>
|
||||
In the above example, the bin now also has a pad: the pad called 'sink'
|
||||
of the given element. We can now, for example, connect the srcpad of
|
||||
a filesrc to the bin with:
|
||||
of the given element.
|
||||
</para>
|
||||
<para>
|
||||
We can now, for example, connect the source pad of a filesrc element
|
||||
to the bin with:
|
||||
</para>
|
||||
<programlisting>
|
||||
GstElement *filesrc;
|
||||
|
|
|
@ -3,7 +3,7 @@
|
|||
<para>
|
||||
Buffers contain the data that will flow through the pipeline you have
|
||||
created. A source element will typically create a new buffer and pass
|
||||
it through the pad to the next element in the chain. When using the
|
||||
it through a pad to the next element in the chain. When using the
|
||||
GStreamer infrastructure to create a media pipeline you will not have
|
||||
to deal with buffers yourself; the elements will do that for you.
|
||||
</para>
|
||||
|
@ -43,7 +43,7 @@
|
|||
|
||||
<para>
|
||||
The simple case is that a buffer is created, memory allocated, data put
|
||||
in it, and passed to the next filter. That filter reads the data, does
|
||||
in it, and passed to the next element. That element reads the data, does
|
||||
something (like creating a new buffer and decoding into it), and
|
||||
unreferences the buffer. This causes the data to be freed and the buffer
|
||||
to be destroyed. A typical MPEG audio decoder works like this.
|
||||
|
|
|
@ -28,7 +28,7 @@
|
|||
</para>
|
||||
<para>
|
||||
Below you see how we will visualize the element.
|
||||
We always draw a src pad to the right of the element.
|
||||
We always draw a source pad to the right of the element.
|
||||
</para>
|
||||
<figure float="1" id="sec-element-srcimg">
|
||||
<title>Visualisation of a source element</title>
|
||||
|
@ -40,8 +40,8 @@
|
|||
</figure>
|
||||
<para>
|
||||
Source elements do not accept data, they only generate data. You can
|
||||
see this in the figure because it only has a src pad. A src pad can
|
||||
only generate data.
|
||||
see this in the figure because it only has a source pad. A source
|
||||
pad can only generate data.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
|
@ -49,7 +49,7 @@
|
|||
<title>Filters and codecs</title>
|
||||
<para>
|
||||
Filter elements both have input and output pads. They operate on
|
||||
data they receive in their sink pads and produce data on their src
|
||||
data they receive in their sink pads and produce data on their source
|
||||
pads. For example, MPEG decoders and volume filters would fall into
|
||||
this category.
|
||||
</para>
|
||||
|
@ -68,7 +68,7 @@
|
|||
</figure>
|
||||
<para>
|
||||
The above figure shows the visualisation of a filter element.
|
||||
This element has one sink (input) pad and one src (output) pad.
|
||||
This element has one sink (input) pad and one source (output) pad.
|
||||
Sink pads are drawn on the left of the element.
|
||||
</para>
|
||||
<figure float="1" id="sec-element-multifilterimg">
|
||||
|
|
|
@ -4,7 +4,7 @@
|
|||
This chapter describes the most rudimentary aspects of a
|
||||
<application>GStreamer</application> application, including initializing
|
||||
the libraries, creating elements, packing them into a pipeline and playing,
|
||||
pause and stop the pipeline.
|
||||
pausing and stopping the pipeline.
|
||||
</para>
|
||||
|
||||
<sect1>
|
||||
|
@ -12,7 +12,7 @@
|
|||
<para>
|
||||
We will create a simple first application, a complete MP3 player, using
|
||||
standard <application>GStreamer</application> components. The player
|
||||
will read from a file that is given as the first argument of the program.
|
||||
will read from a file that is given as the first argument to the program.
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
|
@ -91,9 +91,9 @@ main (int argc, char *argv[])
|
|||
</programlisting>
|
||||
|
||||
<para>
|
||||
We are going to create 3 elements and one pipeline. Since all elements
|
||||
share the same base type, <classname>GstElement</classname>, we can
|
||||
define them as:
|
||||
We are going to create three elements and one pipeline. Since all
|
||||
elements share the same base type, <classname>GstElement</classname>,
|
||||
we can define them as:
|
||||
</para>
|
||||
<programlisting>
|
||||
...
|
||||
|
@ -104,14 +104,14 @@ main (int argc, char *argv[])
|
|||
<para>
|
||||
Next, we are going to create an empty pipeline. As you have seen in
|
||||
the basic introduction, this pipeline will hold and manage all the
|
||||
elements we are going to stuff into it.
|
||||
elements we are going to pack into it.
|
||||
</para>
|
||||
<programlisting>
|
||||
/* create a new pipeline to hold the elements */
|
||||
pipeline = gst_pipeline_new ("pipeline");
|
||||
</programlisting>
|
||||
<para>
|
||||
We use the standard constructor for a pipeline: gst_pipeline_new ("name").
|
||||
We use the standard constructor for a pipeline: gst_pipeline_new ().
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -149,7 +149,7 @@ main (int argc, char *argv[])
|
|||
|
||||
<para>
|
||||
Finally we create our audio sink element. This element will be able
|
||||
to playback the audio using OSS.
|
||||
to play back the audio using OSS.
|
||||
</para>
|
||||
<programlisting>
|
||||
/* and an audio sink */
|
||||
|
@ -203,7 +203,7 @@ main (int argc, char *argv[])
|
|||
</note>
|
||||
|
||||
<para>
|
||||
Since we do not use threads, nothing will happen yet. We manually have to
|
||||
Since we do not use threads, nothing will happen yet. We have to
|
||||
call gst_bin_iterate() to execute one iteration of the pipeline.
|
||||
</para>
|
||||
<programlisting>
|
||||
|
@ -211,7 +211,7 @@ main (int argc, char *argv[])
|
|||
</programlisting>
|
||||
<para>
|
||||
The gst_bin_iterate() function will return TRUE as long as something
|
||||
interesting happended inside the pipeline. When the end-of-file has been
|
||||
interesting happened inside the pipeline. When the end-of-file has been
|
||||
reached the _iterate function will return FALSE and we can end the loop.
|
||||
</para>
|
||||
<programlisting>
|
||||
|
@ -257,13 +257,14 @@ main (int argc, char *argv[])
|
|||
<title>Conclusion</title>
|
||||
<para>
|
||||
This concludes our first example. As you see, setting up a pipeline
|
||||
is very lowlevel but powerful. You will later in this manual how
|
||||
you can create a custom MP3 element with a more high level API.
|
||||
is very low-level but powerful. You will see later in this manual how
|
||||
you can create a custom MP3 element with a higher-level API.
|
||||
</para>
|
||||
<para>
|
||||
It should be clear from the example that we can very easily replace the
|
||||
filesrc element with an httpsrc, giving you instant network streaming.
|
||||
An element could be build to handle icecast connections, for example.
|
||||
filesrc element with an httpsrc element, giving you instant network
|
||||
streaming. An element could be built to handle icecast connections,
|
||||
for example.
|
||||
</para>
|
||||
<para>
|
||||
We can also choose to use another type of sink instead of the audiosink.
|
||||
|
|
|
@ -24,7 +24,7 @@
|
|||
This function will get the pad named "src" from the given element.
|
||||
</para>
|
||||
<para>
|
||||
Alternatively, you can also request a GList of pads from the element. The
|
||||
Alternatively, you can request a GList of pads from the element. The
|
||||
following code example will print the names of all the pads of an
|
||||
element.
|
||||
</para>
|
||||
|
@ -49,8 +49,8 @@
|
|||
</para>
|
||||
<para>
|
||||
gst_pad_get_direction (GstPad *pad) can be used to query if the pad
|
||||
is a sink or a src pad. Remember a src pad is a pad that can output
|
||||
data and a sink pad is one that accepts data.
|
||||
is a sink or a source pad. Remember that a source pad is a pad that
|
||||
can output data and a sink pad is one that accepts data.
|
||||
</para>
|
||||
<para>
|
||||
You can get the parent of the pad, this is the element that this pad belongs to,
|
||||
|
@ -62,9 +62,9 @@
|
|||
<title>Dynamic pads</title>
|
||||
<para>
|
||||
Some elements might not have their pads when they are created. This
|
||||
can, for example, happen with an MPEG2 system demuxer. The demuxer will
|
||||
create its pads at runtime when it detects the different elementary
|
||||
streams in the MPEG2 system stream.
|
||||
can happen, for example, with an MPEG2 system demultiplexer. The
|
||||
demultiplexer will create its pads at runtime when it detects the
|
||||
different elementary streams in the MPEG2 system stream.
|
||||
</para>
|
||||
<para>
|
||||
Running <application>gst-inspect mpegdemux</application> will show that
|
||||
|
@ -102,7 +102,7 @@ main(int argc, char *argv[])
|
|||
GstElement *pipeline;
|
||||
GstElement *mpeg2parser;
|
||||
|
||||
// create pipeline and do something usefull
|
||||
// create pipeline and do something useful
|
||||
...
|
||||
|
||||
mpeg2parser = gst_element_factory_make ("mpegdemux", "mpegdemux");
|
||||
|
@ -124,8 +124,8 @@ main(int argc, char *argv[])
|
|||
<title>Request pads</title>
|
||||
<para>
|
||||
An element can also have request pads. These pads are not created
|
||||
automatically but are only created on demand. This is very usefull
|
||||
for muxers, aggregators and tee elements.
|
||||
automatically but are only created on demand. This is very useful
|
||||
for multiplexers, aggregators and tee elements.
|
||||
</para>
|
||||
<para>
|
||||
The tee element, for example, has one input pad and a request padtemplate for the
|
||||
|
@ -152,10 +152,10 @@ main(int argc, char *argv[])
|
|||
</para>
|
||||
<para>
|
||||
It is also possible to request a pad that is compatible with another
|
||||
padtemplate. This is very usefull if you want to connect an element to
|
||||
a muxer element and you need to request a pad that is compatible. The
|
||||
gst_element_get_compatible_pad is used to request a compatible pad,
|
||||
as is shown in the next example.
|
||||
pad template. This is very useful if you want to connect an element
|
||||
to a multiplexer element and you need to request a pad that is
|
||||
compatible. The gst_element_get_compatible_pad is used to request
|
||||
a compatible pad, as is shown in the next example.
|
||||
</para>
|
||||
<programlisting>
|
||||
...
|
||||
|
@ -217,9 +217,9 @@ struct _GstCaps {
|
|||
three properties: layer, bitrate and framed.
|
||||
</para>
|
||||
<para>
|
||||
The src pad (output pad) is called 'src' and outputs data of MIME
|
||||
type 'audio/raw'. It also has four properties: format, depth, rate
|
||||
and channels.
|
||||
The source pad (output pad) is called 'src' and outputs data of
|
||||
MIME type 'audio/raw'. It also has four properties: format, depth,
|
||||
rate and channels.
|
||||
</para>
|
||||
<programlisting>
|
||||
Pads:
|
||||
|
@ -247,8 +247,8 @@ Pads:
|
|||
<sect2 id="sec-pads-props">
|
||||
<title>What are properties</title>
|
||||
<para>
|
||||
Properties are used to describe extra information for the
|
||||
capabilities. The properties basically exist of a key (a string) and
|
||||
Properties are used to describe extra information for
|
||||
capabilities. The properties basically consist of a key (a string) and
|
||||
a value. There are different possibile value types that can be used:
|
||||
</para>
|
||||
|
||||
|
@ -261,8 +261,8 @@ Pads:
|
|||
<listitem>
|
||||
<para>
|
||||
An integer range value. The property denotes a range of possible
|
||||
values. In the case of the mad element: the src pad has a property
|
||||
rate that can go from 11025 to 48000.
|
||||
values. In the case of the mad element, the source pad has a
|
||||
property rate that can go from 11025 to 48000.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
|
@ -273,7 +273,7 @@ Pads:
|
|||
<listitem>
|
||||
<para>
|
||||
a fourcc value: this is a value that is commonly used to describe an encoding for video,
|
||||
as used be the AVI specification.
|
||||
as used by the AVI specification.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
|
@ -300,7 +300,7 @@ Pads:
|
|||
|
||||
</sect2>
|
||||
<sect2 id="sec-pads-caps-use">
|
||||
<title>What are the capabilities used for?</title>
|
||||
<title>What capabilities are used for</title>
|
||||
<para>
|
||||
Capabilities describe in great detail the type of media that is handled by the pads.
|
||||
They are mostly used for:
|
||||
|
@ -343,17 +343,17 @@ Pads:
|
|||
</programlisting>
|
||||
</sect2>
|
||||
<sect2 id="sec-pads-caps-create">
|
||||
<title>Creating capabilities structures</title>
|
||||
<title>Creating capability structures</title>
|
||||
<para>
|
||||
While the capabilities are mainly used inside the plugin to describe
|
||||
the media type of the pads, the application programmer also has
|
||||
to have basic understanding of caps in order to interface with the
|
||||
While capabilities are mainly used inside a plugin to describe the
|
||||
media type of the pads, the application programmer also has to have
|
||||
basic understanding of capabilities in order to interface with the
|
||||
plugins, specially when using the autopluggers.
|
||||
</para>
|
||||
<para>
|
||||
As we said, a capability has a name, a mime-type and some
|
||||
properties. The signature of the function to create a new
|
||||
<classname>GstCaps</classname> structure is like:
|
||||
<classname>GstCaps</classname> structure is:
|
||||
|
||||
<programlisting>
|
||||
GstCaps* gst_caps_new (const gchar *name, const gchar *mime, GstProps *props);
|
||||
|
@ -442,7 +442,7 @@ GstProps* gst_props_new (const gchar *firstname, ...);
|
|||
NULL
|
||||
);
|
||||
</programlisting>
|
||||
Optionally the convenient shortcut macro can be used. The above complex
|
||||
Optionally, the convenient shortcut macro can be used. The above complex
|
||||
capability can be created with:
|
||||
<programlisting>
|
||||
GstCaps *newcaps;
|
||||
|
|
|
@ -49,8 +49,8 @@
|
|||
<sect1 id="sec-bin-create">
|
||||
<title>Creating a bin</title>
|
||||
<para>
|
||||
Bins register themselves in the GStreamer registry, so they can be
|
||||
created in the normal way:
|
||||
Bins are created in the same way that other elements are created. ie.
|
||||
using an element factory, or any of the associated convenience functions:
|
||||
</para>
|
||||
<programlisting>
|
||||
GstElement *bin, *thread, *pipeline;
|
||||
|
@ -99,7 +99,7 @@
|
|||
</programlisting>
|
||||
<para>
|
||||
You can see that the name of the element becomes very handy
|
||||
for retrieving the element from an bin by using the element's
|
||||
for retrieving the element from a bin by using the element's
|
||||
name. gst_bin_get_by_name () will recursively search nested bins.
|
||||
</para>
|
||||
<para>
|
||||
|
@ -120,7 +120,7 @@
|
|||
...
|
||||
</programlisting>
|
||||
<para>
|
||||
To remove an element from a bin use:
|
||||
To remove an element from a bin, use:
|
||||
</para>
|
||||
<programlisting>
|
||||
GstElement *element;
|
||||
|
@ -129,8 +129,8 @@
|
|||
...
|
||||
</programlisting>
|
||||
<para>
|
||||
To add many elements to a bin at the same time, try the gst_bin_add_many
|
||||
() API. Remember to pass NULL as the last argument.
|
||||
To add many elements to a bin at the same time, use the gst_bin_add_many
|
||||
() function. Remember to pass NULL as the last argument.
|
||||
</para>
|
||||
<programlisting>
|
||||
GstElement *filesrc, *decoder, *audiosink;
|
||||
|
@ -146,8 +146,8 @@
|
|||
<title>Custom bins</title>
|
||||
<para>
|
||||
The application programmer can create custom bins packed with elements
|
||||
to perform a specific task. This allow you to write an MPEG audio
|
||||
decoder with just the follwing lines of code:
|
||||
to perform a specific task. This allows you to write an MPEG audio
|
||||
decoder with just the following lines of code:
|
||||
</para>
|
||||
<programlisting>
|
||||
|
||||
|
@ -169,7 +169,8 @@
|
|||
from a <classname>GstThread</classname>, which begins to play as soon
|
||||
as its state is set to PLAYING. Other bin types may need explicit
|
||||
iteration. For more information, see <xref linkend="cha-threads"/>.
|
||||
|
||||
</para>
|
||||
<para>
|
||||
Custom bins can be created with a plugin or an XML description. You
|
||||
will find more information about creating custom bin in the Plugin
|
||||
Writers Guide (FIXME ref).
|
||||
|
@ -227,8 +228,11 @@
|
|||
</programlisting>
|
||||
<para>
|
||||
In the above example, the bin now also has a pad: the pad called 'sink'
|
||||
of the given element. We can now, for example, connect the srcpad of
|
||||
a filesrc to the bin with:
|
||||
of the given element.
|
||||
</para>
|
||||
<para>
|
||||
We can now, for example, connect the source pad of a filesrc element
|
||||
to the bin with:
|
||||
</para>
|
||||
<programlisting>
|
||||
GstElement *filesrc;
|
||||
|
|
|
@ -3,7 +3,7 @@
|
|||
<para>
|
||||
Buffers contain the data that will flow through the pipeline you have
|
||||
created. A source element will typically create a new buffer and pass
|
||||
it through the pad to the next element in the chain. When using the
|
||||
it through a pad to the next element in the chain. When using the
|
||||
GStreamer infrastructure to create a media pipeline you will not have
|
||||
to deal with buffers yourself; the elements will do that for you.
|
||||
</para>
|
||||
|
@ -43,7 +43,7 @@
|
|||
|
||||
<para>
|
||||
The simple case is that a buffer is created, memory allocated, data put
|
||||
in it, and passed to the next filter. That filter reads the data, does
|
||||
in it, and passed to the next element. That element reads the data, does
|
||||
something (like creating a new buffer and decoding into it), and
|
||||
unreferences the buffer. This causes the data to be freed and the buffer
|
||||
to be destroyed. A typical MPEG audio decoder works like this.
|
||||
|
|
|
@ -15,16 +15,16 @@
|
|||
</figure>
|
||||
<para>
|
||||
By connecting these three elements, we have created a very simple
|
||||
pipeline. The effect of this will be that the output of the source element
|
||||
chain. The effect of this will be that the output of the source element
|
||||
(element1) will be used as input for the filter element (element2). The
|
||||
filter element will do something with the data and send the result to
|
||||
the final sink element (element3).
|
||||
</para>
|
||||
<para>
|
||||
Imagine the above graph as a simple mpeg audio decoder. The source
|
||||
element is a disk source, the filter element is the mpeg decoder and
|
||||
Imagine the above graph as a simple MPEG audio decoder. The source
|
||||
element is a disk source, the filter element is the MPEG decoder and
|
||||
the sink element is your audiocard. We will use this simple graph to
|
||||
construct an mpeg player later in this manual.
|
||||
construct an MPEG player later in this manual.
|
||||
</para>
|
||||
|
||||
<sect1 id="sec-conn-basic">
|
||||
|
@ -88,8 +88,8 @@
|
|||
You can query if a pad is connected with GST_PAD_IS_CONNECTED (pad).
|
||||
</para>
|
||||
<para>
|
||||
To query for the <classname>GstPad</classname> this srcpad is connected
|
||||
to, use gst_pad_get_peer (srcpad).
|
||||
To query for the <classname>GstPad</classname> a pad is connected to, use
|
||||
gst_pad_get_peer (pad).
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
|
|
|
@ -31,7 +31,7 @@
|
|||
</para>
|
||||
<para>
|
||||
Before proceding to the concept of loop-based elements we will first
|
||||
explain the chain-based elements
|
||||
explain the chain-based elements.
|
||||
</para>
|
||||
|
||||
<sect1 id="sec-chain-based">
|
||||
|
@ -100,7 +100,7 @@ chain_function (GstPad *pad, GstBuffer *buffer)
|
|||
When the request for a buffer cannot immediatly satisfied, the control
|
||||
will be given to the source element of the loop-based element until it
|
||||
performs a push on its source pad. At that time the control is handed
|
||||
back to the loop-based element, etc... The the execution trace can get
|
||||
back to the loop-based element, etc... The execution trace can get
|
||||
fairly complex using cothreads when there are multiple input/output
|
||||
pads for the loop-based element. Cothread switches are performed within
|
||||
the call to gst_pad_pull and gst_pad_push; from the perspective of
|
||||
|
@ -110,10 +110,10 @@ chain_function (GstPad *pad, GstBuffer *buffer)
|
|||
<para>
|
||||
Loop based elements are mainly used for the more complex elements
|
||||
that need a specific amount of data before they can start to produce
|
||||
output. An example of such an element is the mpeg video decoder. the
|
||||
element will pull a buffer, performs some decoding on it and optionally
|
||||
requests more buffers to decode, when a complete video frame has
|
||||
been decoded, a buffer is send out. For example, any plugin using the
|
||||
output. An example of such an element is the MPEG video decoder. The
|
||||
element will pull a buffer, perform some decoding on it and optionally
|
||||
request more buffers to decode, and when a complete video frame has
|
||||
been decoded, a buffer is sent out. For example, any plugin using the
|
||||
bytestream library will need to be loop-based.
|
||||
</para>
|
||||
<para>
|
||||
|
|
|
@ -4,10 +4,10 @@
|
|||
<sect1>
|
||||
<title>Getting Started</title>
|
||||
<para>
|
||||
The dparams subsystem is contained within the
|
||||
The Dynamic Parameters subsystem is contained within the
|
||||
<filename>gstcontrol</filename> library.
|
||||
|
||||
You need to include the header in your applications's source file:
|
||||
You need to include the header in your application's source file:
|
||||
</para>
|
||||
<programlisting>
|
||||
...
|
||||
|
@ -19,9 +19,9 @@
|
|||
Your application should link to the shared library <filename>gstcontrol</filename>.
|
||||
</para>
|
||||
<para>
|
||||
The <filename>gstcontrol</filename> library needs to be initialised
|
||||
The <filename>gstcontrol</filename> library needs to be initialized
|
||||
when your application is run. This can be done after the the GStreamer
|
||||
library has been initialised.
|
||||
library has been initialized.
|
||||
</para>
|
||||
<programlisting>
|
||||
...
|
||||
|
|
|
@ -2,14 +2,14 @@
|
|||
<title>Dynamic pipelines</title>
|
||||
<para>
|
||||
In this chapter we will see how you can create a dynamic pipeline. A
|
||||
dynamic pipeline is a pipeline that is updated or created while media
|
||||
dynamic pipeline is a pipeline that is updated or created while data
|
||||
is flowing through it. We will create a partial pipeline first and add
|
||||
more elements while the pipeline is playing. Dynamic pipelines cause
|
||||
all sorts of scheduling issues and will remain a topic of research for
|
||||
a long time in GStreamer.
|
||||
</para>
|
||||
<para>
|
||||
We will show how to create an mpeg1 video player using dynamic pipelines.
|
||||
We will show how to create an MPEG1 video player using dynamic pipelines.
|
||||
As you have seen in the pad section, we can attach a signal to an element
|
||||
when a pad is created. We will use this to create our MPEG1 player.
|
||||
</para>
|
||||
|
|
|
@ -28,7 +28,7 @@
|
|||
</para>
|
||||
<para>
|
||||
Below you see how we will visualize the element.
|
||||
We always draw a src pad to the right of the element.
|
||||
We always draw a source pad to the right of the element.
|
||||
</para>
|
||||
<figure float="1" id="sec-element-srcimg">
|
||||
<title>Visualisation of a source element</title>
|
||||
|
@ -40,8 +40,8 @@
|
|||
</figure>
|
||||
<para>
|
||||
Source elements do not accept data, they only generate data. You can
|
||||
see this in the figure because it only has a src pad. A src pad can
|
||||
only generate data.
|
||||
see this in the figure because it only has a source pad. A source
|
||||
pad can only generate data.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
|
@ -49,7 +49,7 @@
|
|||
<title>Filters and codecs</title>
|
||||
<para>
|
||||
Filter elements both have input and output pads. They operate on
|
||||
data they receive in their sink pads and produce data on their src
|
||||
data they receive in their sink pads and produce data on their source
|
||||
pads. For example, MPEG decoders and volume filters would fall into
|
||||
this category.
|
||||
</para>
|
||||
|
@ -68,7 +68,7 @@
|
|||
</figure>
|
||||
<para>
|
||||
The above figure shows the visualisation of a filter element.
|
||||
This element has one sink (input) pad and one src (output) pad.
|
||||
This element has one sink (input) pad and one source (output) pad.
|
||||
Sink pads are drawn on the left of the element.
|
||||
</para>
|
||||
<figure float="1" id="sec-element-multifilterimg">
|
||||
|
|
|
@ -4,7 +4,7 @@
|
|||
The small application we created in the previous chapter used the
|
||||
concept of a factory to create the elements. In this chapter we will
|
||||
show you how to use the factory concepts to create elements based
|
||||
on what they do instead of how they are called.
|
||||
on what they do instead of what they are called.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -28,9 +28,9 @@
|
|||
<para>
|
||||
While this mechanism is quite effective it also has some big problems:
|
||||
The elements are created based on their name. Indeed, we create an
|
||||
element mad by explicitly stating the mad element's name. Our little
|
||||
element, mad, by explicitly stating the mad element's name. Our little
|
||||
program therefore always uses the mad decoder element to decode
|
||||
the MP3 audio stream, even if there are 3 other MP3 decoders in the
|
||||
the MP3 audio stream, even if there are three other MP3 decoders in the
|
||||
system. We will see how we can use a more general way to create an
|
||||
MP3 decoder element.
|
||||
</para>
|
||||
|
@ -43,14 +43,14 @@
|
|||
<sect1>
|
||||
<title>More on MIME Types</title>
|
||||
<para>
|
||||
GStreamer uses MIME types to indentify the different types of data
|
||||
GStreamer uses MIME types to identify the different types of data
|
||||
that can be handled by the elements. They are the high level
|
||||
mechanisms to make sure that everyone is talking about the right
|
||||
kind of data.
|
||||
</para>
|
||||
<para>
|
||||
A MIME (Multipurpose Internet Mail Extension) types are a set of
|
||||
string that denote a certain type of data. examples include:
|
||||
A MIME (Multipurpose Internet Mail Extension) type is a pair of
|
||||
strings that denote a certain type of data. Examples include:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
|
@ -59,12 +59,12 @@
|
|||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
audio/mpeg : mpeg audio
|
||||
audio/mpeg : MPEG audio
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
video/mpeg : mpeg video
|
||||
video/mpeg : MPEG video
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
@ -77,7 +77,7 @@
|
|||
will see.
|
||||
</para>
|
||||
<para>
|
||||
As we have seen in the previous chapter, the MIME types are added
|
||||
As we have seen in the previous chapter, MIME types are added
|
||||
to the Capability structure of a pad.
|
||||
</para>
|
||||
|
||||
|
@ -125,7 +125,7 @@
|
|||
</para>
|
||||
<para>
|
||||
There is also an association between a MIME type and a file extension,
|
||||
but the use of typefind functions (similar to file(1)) is preferred..
|
||||
but the use of typefind functions (similar to file(1)) is preferred.
|
||||
</para>
|
||||
<para>
|
||||
The type information is maintained in a list of
|
||||
|
@ -149,7 +149,7 @@ struct _GstType {
|
|||
<para>
|
||||
All operations on <classname>GstType</classname> occur
|
||||
via their <classname>guint16 id</classname> numbers, with
|
||||
<classname>GstType</classname> structure private to the GStreamer
|
||||
the <classname>GstType</classname> structure private to the GStreamer
|
||||
library.
|
||||
</para>
|
||||
|
||||
|
@ -182,7 +182,7 @@ struct _GstType {
|
|||
type = gst_type_find_by_id (id);
|
||||
</programlisting>
|
||||
<para>
|
||||
This function will return NULL if the id was associated with
|
||||
This function will return NULL if the id was not associated with
|
||||
any known <classname>GstType</classname>
|
||||
</para>
|
||||
</sect2>
|
||||
|
@ -208,7 +208,7 @@ struct _GstType {
|
|||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>creating elements with the factory</title>
|
||||
<title>Creating elements with the factory</title>
|
||||
<para>
|
||||
In the previous section we described how you could obtain
|
||||
an element factory using MIME types. One the factory has been
|
||||
|
|
|
@ -233,7 +233,7 @@
|
|||
<partintro>
|
||||
<para>
|
||||
<application>GStreamer</application> comes prepackaged with a few
|
||||
programs. and some usefull debugging options.
|
||||
programs, and some useful debugging options.
|
||||
</para>
|
||||
</partintro>
|
||||
|
||||
|
|
|
@ -4,7 +4,7 @@
|
|||
This chapter describes the most rudimentary aspects of a
|
||||
<application>GStreamer</application> application, including initializing
|
||||
the libraries, creating elements, packing them into a pipeline and playing,
|
||||
pause and stop the pipeline.
|
||||
pausing and stopping the pipeline.
|
||||
</para>
|
||||
|
||||
<sect1>
|
||||
|
@ -12,7 +12,7 @@
|
|||
<para>
|
||||
We will create a simple first application, a complete MP3 player, using
|
||||
standard <application>GStreamer</application> components. The player
|
||||
will read from a file that is given as the first argument of the program.
|
||||
will read from a file that is given as the first argument to the program.
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
|
@ -91,9 +91,9 @@ main (int argc, char *argv[])
|
|||
</programlisting>
|
||||
|
||||
<para>
|
||||
We are going to create 3 elements and one pipeline. Since all elements
|
||||
share the same base type, <classname>GstElement</classname>, we can
|
||||
define them as:
|
||||
We are going to create three elements and one pipeline. Since all
|
||||
elements share the same base type, <classname>GstElement</classname>,
|
||||
we can define them as:
|
||||
</para>
|
||||
<programlisting>
|
||||
...
|
||||
|
@ -104,14 +104,14 @@ main (int argc, char *argv[])
|
|||
<para>
|
||||
Next, we are going to create an empty pipeline. As you have seen in
|
||||
the basic introduction, this pipeline will hold and manage all the
|
||||
elements we are going to stuff into it.
|
||||
elements we are going to pack into it.
|
||||
</para>
|
||||
<programlisting>
|
||||
/* create a new pipeline to hold the elements */
|
||||
pipeline = gst_pipeline_new ("pipeline");
|
||||
</programlisting>
|
||||
<para>
|
||||
We use the standard constructor for a pipeline: gst_pipeline_new ("name").
|
||||
We use the standard constructor for a pipeline: gst_pipeline_new ().
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -149,7 +149,7 @@ main (int argc, char *argv[])
|
|||
|
||||
<para>
|
||||
Finally we create our audio sink element. This element will be able
|
||||
to playback the audio using OSS.
|
||||
to play back the audio using OSS.
|
||||
</para>
|
||||
<programlisting>
|
||||
/* and an audio sink */
|
||||
|
@ -203,7 +203,7 @@ main (int argc, char *argv[])
|
|||
</note>
|
||||
|
||||
<para>
|
||||
Since we do not use threads, nothing will happen yet. We manually have to
|
||||
Since we do not use threads, nothing will happen yet. We have to
|
||||
call gst_bin_iterate() to execute one iteration of the pipeline.
|
||||
</para>
|
||||
<programlisting>
|
||||
|
@ -211,7 +211,7 @@ main (int argc, char *argv[])
|
|||
</programlisting>
|
||||
<para>
|
||||
The gst_bin_iterate() function will return TRUE as long as something
|
||||
interesting happended inside the pipeline. When the end-of-file has been
|
||||
interesting happened inside the pipeline. When the end-of-file has been
|
||||
reached the _iterate function will return FALSE and we can end the loop.
|
||||
</para>
|
||||
<programlisting>
|
||||
|
@ -257,13 +257,14 @@ main (int argc, char *argv[])
|
|||
<title>Conclusion</title>
|
||||
<para>
|
||||
This concludes our first example. As you see, setting up a pipeline
|
||||
is very lowlevel but powerful. You will later in this manual how
|
||||
you can create a custom MP3 element with a more high level API.
|
||||
is very low-level but powerful. You will see later in this manual how
|
||||
you can create a custom MP3 element with a higher-level API.
|
||||
</para>
|
||||
<para>
|
||||
It should be clear from the example that we can very easily replace the
|
||||
filesrc element with an httpsrc, giving you instant network streaming.
|
||||
An element could be build to handle icecast connections, for example.
|
||||
filesrc element with an httpsrc element, giving you instant network
|
||||
streaming. An element could be built to handle icecast connections,
|
||||
for example.
|
||||
</para>
|
||||
<para>
|
||||
We can also choose to use another type of sink instead of the audiosink.
|
||||
|
|
|
@ -18,9 +18,9 @@
|
|||
|
||||
<para>
|
||||
We create a simple pipeline and write it to stdout with
|
||||
gst_xml_write_file (). The following code constructs an mp3 player
|
||||
gst_xml_write_file (). The following code constructs an MP3 player
|
||||
pipeline with two threads and then writes out the XML both to stdout
|
||||
and to a file. Use this program with one argument: the mp3 file on disk.
|
||||
and to a file. Use this program with one argument: the MP3 file on disk.
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
|
@ -170,7 +170,7 @@ main(int argc, char *argv[])
|
|||
<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
|
||||
respectivily. both of these methods return a gboolean indicating
|
||||
respectively. Both of these methods return a gboolean indicating
|
||||
success or failure of the requested action.
|
||||
</para>
|
||||
</sect1>
|
||||
|
@ -180,7 +180,7 @@ main(int argc, char *argv[])
|
|||
<para>
|
||||
It is possible to add custom XML tags to the core XML created with
|
||||
gst_xml_write. This feature can be used by an application to add more
|
||||
information to the save plugins. the editor will for example insert
|
||||
information to the save plugins. The editor will for example insert
|
||||
the position of the elements on the screen using the custom XML tags.
|
||||
</para>
|
||||
<para>
|
||||
|
@ -258,7 +258,7 @@ object_saved (GstObject *object, xmlNodePtr parent, gpointer data)
|
|||
|
||||
<para>
|
||||
Whenever a new object has been loaded, the xml_loaded function will
|
||||
be called. this function looks like:
|
||||
be called. This function looks like:
|
||||
</para>
|
||||
<programlisting>
|
||||
static void
|
||||
|
|
|
@ -25,7 +25,7 @@
|
|||
One of the the most obvious uses of GStreamer is using it to build
|
||||
a media player. GStreamer already includes components for building a
|
||||
media player that can support a very wide variety of formats, including
|
||||
mp3, Ogg Vorbis, MPEG1, MPEG2, AVI, Quicktime, mod and so on. GStreamer,
|
||||
MP3, Ogg Vorbis, MPEG1, MPEG2, AVI, Quicktime, mod and so on. GStreamer,
|
||||
however, is much more than just another media player. Its main advantages
|
||||
are that the pluggable components can be mixed and matched into arbitrary
|
||||
pipelines so that it's possible to write a full-fledged video or audio
|
||||
|
|
|
@ -25,7 +25,7 @@
|
|||
One of the the most obvious uses of GStreamer is using it to build
|
||||
a media player. GStreamer already includes components for building a
|
||||
media player that can support a very wide variety of formats, including
|
||||
mp3, Ogg Vorbis, MPEG1, MPEG2, AVI, Quicktime, mod and so on. GStreamer,
|
||||
MP3, Ogg Vorbis, MPEG1, MPEG2, AVI, Quicktime, mod and so on. GStreamer,
|
||||
however, is much more than just another media player. Its main advantages
|
||||
are that the pluggable components can be mixed and matched into arbitrary
|
||||
pipelines so that it's possible to write a full-fledged video or audio
|
||||
|
|
|
@ -24,7 +24,7 @@
|
|||
This function will get the pad named "src" from the given element.
|
||||
</para>
|
||||
<para>
|
||||
Alternatively, you can also request a GList of pads from the element. The
|
||||
Alternatively, you can request a GList of pads from the element. The
|
||||
following code example will print the names of all the pads of an
|
||||
element.
|
||||
</para>
|
||||
|
@ -49,8 +49,8 @@
|
|||
</para>
|
||||
<para>
|
||||
gst_pad_get_direction (GstPad *pad) can be used to query if the pad
|
||||
is a sink or a src pad. Remember a src pad is a pad that can output
|
||||
data and a sink pad is one that accepts data.
|
||||
is a sink or a source pad. Remember that a source pad is a pad that
|
||||
can output data and a sink pad is one that accepts data.
|
||||
</para>
|
||||
<para>
|
||||
You can get the parent of the pad, this is the element that this pad belongs to,
|
||||
|
@ -62,9 +62,9 @@
|
|||
<title>Dynamic pads</title>
|
||||
<para>
|
||||
Some elements might not have their pads when they are created. This
|
||||
can, for example, happen with an MPEG2 system demuxer. The demuxer will
|
||||
create its pads at runtime when it detects the different elementary
|
||||
streams in the MPEG2 system stream.
|
||||
can happen, for example, with an MPEG2 system demultiplexer. The
|
||||
demultiplexer will create its pads at runtime when it detects the
|
||||
different elementary streams in the MPEG2 system stream.
|
||||
</para>
|
||||
<para>
|
||||
Running <application>gst-inspect mpegdemux</application> will show that
|
||||
|
@ -102,7 +102,7 @@ main(int argc, char *argv[])
|
|||
GstElement *pipeline;
|
||||
GstElement *mpeg2parser;
|
||||
|
||||
// create pipeline and do something usefull
|
||||
// create pipeline and do something useful
|
||||
...
|
||||
|
||||
mpeg2parser = gst_element_factory_make ("mpegdemux", "mpegdemux");
|
||||
|
@ -124,8 +124,8 @@ main(int argc, char *argv[])
|
|||
<title>Request pads</title>
|
||||
<para>
|
||||
An element can also have request pads. These pads are not created
|
||||
automatically but are only created on demand. This is very usefull
|
||||
for muxers, aggregators and tee elements.
|
||||
automatically but are only created on demand. This is very useful
|
||||
for multiplexers, aggregators and tee elements.
|
||||
</para>
|
||||
<para>
|
||||
The tee element, for example, has one input pad and a request padtemplate for the
|
||||
|
@ -152,10 +152,10 @@ main(int argc, char *argv[])
|
|||
</para>
|
||||
<para>
|
||||
It is also possible to request a pad that is compatible with another
|
||||
padtemplate. This is very usefull if you want to connect an element to
|
||||
a muxer element and you need to request a pad that is compatible. The
|
||||
gst_element_get_compatible_pad is used to request a compatible pad,
|
||||
as is shown in the next example.
|
||||
pad template. This is very useful if you want to connect an element
|
||||
to a multiplexer element and you need to request a pad that is
|
||||
compatible. The gst_element_get_compatible_pad is used to request
|
||||
a compatible pad, as is shown in the next example.
|
||||
</para>
|
||||
<programlisting>
|
||||
...
|
||||
|
@ -217,9 +217,9 @@ struct _GstCaps {
|
|||
three properties: layer, bitrate and framed.
|
||||
</para>
|
||||
<para>
|
||||
The src pad (output pad) is called 'src' and outputs data of MIME
|
||||
type 'audio/raw'. It also has four properties: format, depth, rate
|
||||
and channels.
|
||||
The source pad (output pad) is called 'src' and outputs data of
|
||||
MIME type 'audio/raw'. It also has four properties: format, depth,
|
||||
rate and channels.
|
||||
</para>
|
||||
<programlisting>
|
||||
Pads:
|
||||
|
@ -247,8 +247,8 @@ Pads:
|
|||
<sect2 id="sec-pads-props">
|
||||
<title>What are properties</title>
|
||||
<para>
|
||||
Properties are used to describe extra information for the
|
||||
capabilities. The properties basically exist of a key (a string) and
|
||||
Properties are used to describe extra information for
|
||||
capabilities. The properties basically consist of a key (a string) and
|
||||
a value. There are different possibile value types that can be used:
|
||||
</para>
|
||||
|
||||
|
@ -261,8 +261,8 @@ Pads:
|
|||
<listitem>
|
||||
<para>
|
||||
An integer range value. The property denotes a range of possible
|
||||
values. In the case of the mad element: the src pad has a property
|
||||
rate that can go from 11025 to 48000.
|
||||
values. In the case of the mad element, the source pad has a
|
||||
property rate that can go from 11025 to 48000.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
|
@ -273,7 +273,7 @@ Pads:
|
|||
<listitem>
|
||||
<para>
|
||||
a fourcc value: this is a value that is commonly used to describe an encoding for video,
|
||||
as used be the AVI specification.
|
||||
as used by the AVI specification.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
|
@ -300,7 +300,7 @@ Pads:
|
|||
|
||||
</sect2>
|
||||
<sect2 id="sec-pads-caps-use">
|
||||
<title>What are the capabilities used for?</title>
|
||||
<title>What capabilities are used for</title>
|
||||
<para>
|
||||
Capabilities describe in great detail the type of media that is handled by the pads.
|
||||
They are mostly used for:
|
||||
|
@ -343,17 +343,17 @@ Pads:
|
|||
</programlisting>
|
||||
</sect2>
|
||||
<sect2 id="sec-pads-caps-create">
|
||||
<title>Creating capabilities structures</title>
|
||||
<title>Creating capability structures</title>
|
||||
<para>
|
||||
While the capabilities are mainly used inside the plugin to describe
|
||||
the media type of the pads, the application programmer also has
|
||||
to have basic understanding of caps in order to interface with the
|
||||
While capabilities are mainly used inside a plugin to describe the
|
||||
media type of the pads, the application programmer also has to have
|
||||
basic understanding of capabilities in order to interface with the
|
||||
plugins, specially when using the autopluggers.
|
||||
</para>
|
||||
<para>
|
||||
As we said, a capability has a name, a mime-type and some
|
||||
properties. The signature of the function to create a new
|
||||
<classname>GstCaps</classname> structure is like:
|
||||
<classname>GstCaps</classname> structure is:
|
||||
|
||||
<programlisting>
|
||||
GstCaps* gst_caps_new (const gchar *name, const gchar *mime, GstProps *props);
|
||||
|
@ -442,7 +442,7 @@ GstProps* gst_props_new (const gchar *firstname, ...);
|
|||
NULL
|
||||
);
|
||||
</programlisting>
|
||||
Optionally the convenient shortcut macro can be used. The above complex
|
||||
Optionally, the convenient shortcut macro can be used. The above complex
|
||||
capability can be created with:
|
||||
<programlisting>
|
||||
GstCaps *newcaps;
|
||||
|
|
|
@ -35,10 +35,10 @@ gst-launch filesrc location=redpill.vob ! mpegdemux name=demux \
|
|||
|
||||
</para>
|
||||
<para>
|
||||
You can also use the the parser in you own
|
||||
You can also use the parser in you own
|
||||
code. <application>GStreamer</application> provides a function
|
||||
gst_parse_launch () that you can use to construt a pipeline.
|
||||
The following programs lets you create an mp3 pipeline using the
|
||||
gst_parse_launch () that you can use to construct a pipeline.
|
||||
The following program lets you create an MP3 pipeline using the
|
||||
gst_parse_launch () function:
|
||||
</para>
|
||||
<programlisting>
|
||||
|
@ -95,8 +95,8 @@ main (int argc, char *argv[])
|
|||
<para>
|
||||
A bare identifier (a string beginning with a letter and containing
|
||||
only letters, numbers, dashes, underscores, percent signs, or colons)
|
||||
will create an element from a given elementfactory. In this example,
|
||||
an instance of the "mad" mp3 decoding plugin will be created.
|
||||
will create an element from a given element factory. In this example,
|
||||
an instance of the "mad" MP3 decoding plugin will be created.
|
||||
</para>
|
||||
</sect3>
|
||||
<sect3>
|
||||
|
|
|
@ -8,7 +8,7 @@
|
|||
<para>
|
||||
A buffer that is sinked to a Queue will not automatically be pushed to the
|
||||
next connected element but will be buffered. It will be pushed to the next
|
||||
element as soon as a gst_pad_pull () is called on the queues srcpad.
|
||||
element as soon as a gst_pad_pull () is called on the queue's source pad.
|
||||
</para>
|
||||
<para>
|
||||
Queues are mostly used in conjunction with a <classname>GstThread</classname> to
|
||||
|
@ -41,7 +41,7 @@
|
|||
</programlisting>
|
||||
|
||||
<para>
|
||||
The following mp3 player shows you how to create the above pipeline
|
||||
The following MP3 player shows you how to create the above pipeline
|
||||
using a thread and a queue.
|
||||
</para>
|
||||
|
||||
|
|
|
@ -1,8 +1,8 @@
|
|||
<chapter id="cha-scheduler">
|
||||
<title>Understanding schedulers</title>
|
||||
<para>
|
||||
The scheduler is responsible for managing the plugins at runtime. The
|
||||
main responsabilities are:
|
||||
The scheduler is responsible for managing the plugins at runtime. Its
|
||||
main responsibilities are:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
|
@ -28,14 +28,14 @@
|
|||
</itemizedlist>
|
||||
</para>
|
||||
<para>
|
||||
The scheduler is a plugable component, this means that alternative
|
||||
The scheduler is a plugable component; this means that alternative
|
||||
schedulers can be written and plugged into GStreamer. The default scheduler
|
||||
uses cothreads to schedule the plugins in a pipeline. Cothreads are fast
|
||||
and lightweight user-space threads.
|
||||
</para>
|
||||
<para>
|
||||
There is usually no need to interact with the scheduler directly, however
|
||||
it some cases it is feasable to set a specific clock or force a specific
|
||||
in some cases it is feasible to set a specific clock or force a specific
|
||||
plugin as the entry point in the pipeline.
|
||||
</para>
|
||||
|
||||
|
|
|
@ -1,8 +1,8 @@
|
|||
<chapter id="cha-states">
|
||||
<title>Element states</title>
|
||||
<para>
|
||||
One you have created a pipeline packed with elements, nothing will
|
||||
happen yet. This is where the different states come into play.
|
||||
Once you have created a pipeline packed with elements, nothing will happen
|
||||
right away. This is where the different states come into play.
|
||||
</para>
|
||||
|
||||
<sect1 id="sec-states">
|
||||
|
@ -37,7 +37,7 @@
|
|||
<para>
|
||||
All elements start with the NULL state. The elements will go throught
|
||||
the following state changes: NULL -> READY -> PAUSED ->
|
||||
PLAYING. Remember when going from PLAYING to READY GStreamer will
|
||||
PLAYING. Remember when going from PLAYING to READY, GStreamer will
|
||||
internally go throught the intermediate states.
|
||||
</para>
|
||||
<para>
|
||||
|
@ -113,7 +113,7 @@
|
|||
<note>
|
||||
<para>
|
||||
You can also go from the NULL to PLAYING state directly without
|
||||
going through the READY state. this is a shortcut, the framework
|
||||
going through the READY state. This is a shortcut; the framework
|
||||
will internally go through the READY and the PAUSED state for you.
|
||||
</para>
|
||||
</note>
|
||||
|
@ -140,7 +140,7 @@
|
|||
<para>
|
||||
The PAUSED state is available for temporarily freezing the pipeline.
|
||||
Elements will typically not free their resources in the PAUSED state.
|
||||
Use the NULL state if you want to stop the data flow permanantly.
|
||||
Use the NULL state if you want to stop the data flow permanently.
|
||||
</para>
|
||||
</note>
|
||||
<para>
|
||||
|
|
|
@ -33,7 +33,7 @@
|
|||
<para>
|
||||
The above program will create a thread with two elements in it. As soon
|
||||
as it is set to the PLAYING state, the thread will start to iterate
|
||||
itself. You never need to manually iterate a thread.
|
||||
itself. You never need to explicitly iterate a thread.
|
||||
</para>
|
||||
|
||||
<sect2>
|
||||
|
@ -47,7 +47,7 @@
|
|||
between the threads, in a thread-safe fashion. This element is the
|
||||
queue, described more fully in <xref linkend="cha-queues"/>. It doesn't
|
||||
matter if the queue is placed in the containing bin or in the thread
|
||||
itself, but it needs to be present on one side of the other to enable
|
||||
itself, but it needs to be present on one side or the other to enable
|
||||
inter-thread communication.
|
||||
</para>
|
||||
</sect2>
|
||||
|
|
|
@ -1,9 +1,9 @@
|
|||
<chapter id="cha-typedetection">
|
||||
<title>Typedetection</title>
|
||||
<para>
|
||||
Sometimes the capabilities of a pad are not specificied. The filesrc,
|
||||
for example, does not know what type of file it is reading. Before you
|
||||
can attach an element to the pad of the filesrc, you need to determine
|
||||
Sometimes the capabilities of a pad are not specificied. The filesrc
|
||||
element, for example, does not know what type of file it is reading. Before
|
||||
you can attach an element to the pad of the filesrc, you need to determine
|
||||
the media type in order to be able to choose a compatible element.
|
||||
</para>
|
||||
<para>
|
||||
|
@ -104,14 +104,14 @@ main(int argc, char *argv[])
|
|||
<para>
|
||||
We create a very simple pipeline with only a filesrc and the typefind
|
||||
element in it. The sinkpad of the typefind element has been connected
|
||||
to the src pad of the filesrc.
|
||||
to the source pad of the filesrc.
|
||||
</para>
|
||||
<para>
|
||||
We attached a signal 'have_type' to the typefind element which will be called
|
||||
when the type of the media stream as been detected.
|
||||
</para>
|
||||
<para>
|
||||
the typefind function will loop over all the registered types and will
|
||||
The typefind function will loop over all the registered types and will
|
||||
execute each of the typefind functions. As soon as a function returns
|
||||
a GstCaps pointer, the type_found function will be called:
|
||||
</para>
|
||||
|
@ -138,7 +138,7 @@ type_found (GstElement *typefind, GstCaps* caps)
|
|||
XML representation of the caps structure to stdout.
|
||||
</para>
|
||||
<para>
|
||||
A more usefull option would be to use the registry to look up an element
|
||||
A more useful option would be to use the registry to look up an element
|
||||
that can handle this particular caps structure, or we can also use the
|
||||
autoplugger to connect this caps structure to, for example, a videosink.
|
||||
</para>
|
||||
|
|
|
@ -18,9 +18,9 @@
|
|||
|
||||
<para>
|
||||
We create a simple pipeline and write it to stdout with
|
||||
gst_xml_write_file (). The following code constructs an mp3 player
|
||||
gst_xml_write_file (). The following code constructs an MP3 player
|
||||
pipeline with two threads and then writes out the XML both to stdout
|
||||
and to a file. Use this program with one argument: the mp3 file on disk.
|
||||
and to a file. Use this program with one argument: the MP3 file on disk.
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
|
@ -170,7 +170,7 @@ main(int argc, char *argv[])
|
|||
<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
|
||||
respectivily. both of these methods return a gboolean indicating
|
||||
respectively. Both of these methods return a gboolean indicating
|
||||
success or failure of the requested action.
|
||||
</para>
|
||||
</sect1>
|
||||
|
@ -180,7 +180,7 @@ main(int argc, char *argv[])
|
|||
<para>
|
||||
It is possible to add custom XML tags to the core XML created with
|
||||
gst_xml_write. This feature can be used by an application to add more
|
||||
information to the save plugins. the editor will for example insert
|
||||
information to the save plugins. The editor will for example insert
|
||||
the position of the elements on the screen using the custom XML tags.
|
||||
</para>
|
||||
<para>
|
||||
|
@ -258,7 +258,7 @@ object_saved (GstObject *object, xmlNodePtr parent, gpointer data)
|
|||
|
||||
<para>
|
||||
Whenever a new object has been loaded, the xml_loaded function will
|
||||
be called. this function looks like:
|
||||
be called. This function looks like:
|
||||
</para>
|
||||
<programlisting>
|
||||
static void
|
||||
|
|
Loading…
Reference in a new issue