scrubbed cameron patches

Original commit message from CVS:
scrubbed cameron patches
This commit is contained in:
Thomas Vander Stichele 2002-09-06 16:10:31 +00:00
parent 08ff42a0c3
commit 8dab65f0ac
9 changed files with 85 additions and 47 deletions

View file

@ -81,7 +81,7 @@
/* eos will be called when the src element has an end of stream */
void
eos (GstSrc *src, gpointer data)
eos (GstElement *src, gpointer data)
{
GstThread *thread = GST_THREAD (data);
g_print ("have eos, quitting\n");

View file

@ -1,23 +1,25 @@
<chapter id="cha-plugins">
<title>What are Plugins</title>
<title>Plugins</title>
<!-- FIXME: introduce type definitions before this chapter -->
<para>
A plugin is a shared library that contains at least one of the following items:
A plugin is a shared library that contains at least one of the following
items:
</para>
<itemizedlist>
<listitem>
<para>
one or more elementfactories
one or more element factories
</para>
</listitem>
<listitem>
<para>
one or more typedefinitions
one or more type definitions
</para>
</listitem>
<listitem>
<para>
one or more autopluggers
one or more auto-pluggers
</para>
</listitem>
<listitem>
@ -27,19 +29,24 @@
</listitem>
</itemizedlist>
<para>
The plugins have one simple method: plugin_init () where all the elementfactories are
created and the typedefinitions are registered.
All plugins should implement one function, <function>plugin_init</function>,
that creates all the element factories and registers all the type
definitions contained in the plugin.
Without this function, a plugin cannot be registered.
</para>
<para>
the plugins are maintained in the plugin system. Optionally, the typedefinitions and
the elementfactories can be saved into an XML representation so that the plugin system
does not have to load all available plugins in order to know their definition.
The plugins are maintained in the plugin system. Optionally, the
type definitions and the element factories can be saved into an XML
representation so that the plugin system does not have to load all
available plugins in order to know their definition.
</para>
<para>
The basic plugin structure has the following fields:
</para>
<programlisting>
typedef struct _GstPlugin GstPlugin;
struct _GstPlugin {
gchar *name; /* name of the plugin */
gchar *longname; /* long name of plugin */
@ -57,7 +64,8 @@ struct _GstPlugin {
</programlisting>
<para>
You can query a GList of available plugins with:
You can query a <classname>GList</classname> of available plugins with the
function <function>gst_plugin_get_list</function> as this example shows:
</para>
<programlisting>
GList *plugins;

View file

@ -2,13 +2,14 @@
<title>Initializing <application>GStreamer</application></title>
<para>
When writing a <application>GStreamer</application> application, you can
simply include gst/gst.h to get access to the library functions.
simply include <filename class='headerfile'>gst/gst.h</filename> to get
access to the library functions.
</para>
<para>
Before the <application>GStreamer</application> libraries can be used
gst_init () has to be performed from the main app. this call will perform
first initialisation and will parse the GStreamer specific command line
options.
<function>gst_init</function> has to be called from the main application.
This call will perform the necessary initialization of the library as
well as parse the GStreamer-specific command line options.
</para>
<para>
A typical program would start like this:
@ -28,7 +29,17 @@ main (int argc, char *argv[])
}
</programlisting>
<para>
It is also possible to call the gst_init method with two NULL arguments.
Use the <symbol>GST_VERSION_MAJOR</symbol>,
<symbol>GST_VERSION_MINOR</symbol> and <symbol>GST_VERSION_MICRO</symbol>
macros to get the <application>GStreamer</application> version you are
building against, or use the function <function>gst_version</function>
to get the version your application is linked against.
<!-- FIXME: include an automatically generated list of these options. -->
</para>
<para>
It is also possible to call the <function>gst_init</function> function
with two <symbol>NULL</symbol> arguments, in which case no command line
options will parsed by <application>GStreamer</application>.
</para>
<para>
Use the GST_VERSION_MAJOR, GST_VERSION_MINOR and GST_VERSION_MICRO macros to
@ -58,6 +69,15 @@ main(int argc, char *argv[])
...
</programlisting>
<para>
As shown in this fragment, you can use a <ulink
url="http://developer.gnome.org/doc/guides/popt/"
type="http">popt</ulink> table to define your application-specific
command line options, and pass this table to the
function <function>gst_init_with_popt_table</function>. Your
application options will be parsed in addition to the standard
<application>GStreamer</application> options.
</sect1>
</chapter>

View file

@ -83,7 +83,8 @@
</para>
<para>
No provisions have been made for emerging technologies such as
the GNOME object embedding using Bonobo.
the <ulink url="http://developer.gnome.org/arch/component/bonobo.html"
type="http">GNOME object embedding using Bonobo</ulink>.
</para>
<para>
The GStreamer cores does not use network transparent technologies at the

View file

@ -22,14 +22,14 @@
</para>
<para>
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, however, is much more than just another media player. Its
main advantages are that the pluggable components can be mixed and matched into
abitrary pipelines so that it's possible
to write a full fledged video or audio editing application.
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,
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
editing application.
</para>
<para>

View file

@ -22,14 +22,14 @@
</para>
<para>
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, however, is much more than just another media player. Its
main advantages are that the pluggable components can be mixed and matched into
abitrary pipelines so that it's possible
to write a full fledged video or audio editing application.
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,
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
editing application.
</para>
<para>

View file

@ -83,7 +83,8 @@
</para>
<para>
No provisions have been made for emerging technologies such as
the GNOME object embedding using Bonobo.
the <ulink url="http://developer.gnome.org/arch/component/bonobo.html"
type="http">GNOME object embedding using Bonobo</ulink>.
</para>
<para>
The GStreamer cores does not use network transparent technologies at the

View file

@ -1,23 +1,25 @@
<chapter id="cha-plugins">
<title>What are Plugins</title>
<title>Plugins</title>
<!-- FIXME: introduce type definitions before this chapter -->
<para>
A plugin is a shared library that contains at least one of the following items:
A plugin is a shared library that contains at least one of the following
items:
</para>
<itemizedlist>
<listitem>
<para>
one or more elementfactories
one or more element factories
</para>
</listitem>
<listitem>
<para>
one or more typedefinitions
one or more type definitions
</para>
</listitem>
<listitem>
<para>
one or more autopluggers
one or more auto-pluggers
</para>
</listitem>
<listitem>
@ -27,19 +29,24 @@
</listitem>
</itemizedlist>
<para>
The plugins have one simple method: plugin_init () where all the elementfactories are
created and the typedefinitions are registered.
All plugins should implement one function, <function>plugin_init</function>,
that creates all the element factories and registers all the type
definitions contained in the plugin.
Without this function, a plugin cannot be registered.
</para>
<para>
the plugins are maintained in the plugin system. Optionally, the typedefinitions and
the elementfactories can be saved into an XML representation so that the plugin system
does not have to load all available plugins in order to know their definition.
The plugins are maintained in the plugin system. Optionally, the
type definitions and the element factories can be saved into an XML
representation so that the plugin system does not have to load all
available plugins in order to know their definition.
</para>
<para>
The basic plugin structure has the following fields:
</para>
<programlisting>
typedef struct _GstPlugin GstPlugin;
struct _GstPlugin {
gchar *name; /* name of the plugin */
gchar *longname; /* long name of plugin */
@ -57,7 +64,8 @@ struct _GstPlugin {
</programlisting>
<para>
You can query a GList of available plugins with:
You can query a <classname>GList</classname> of available plugins with the
function <function>gst_plugin_get_list</function> as this example shows:
</para>
<programlisting>
GList *plugins;

View file

@ -81,7 +81,7 @@
/* eos will be called when the src element has an end of stream */
void
eos (GstSrc *src, gpointer data)
eos (GstElement *src, gpointer data)
{
GstThread *thread = GST_THREAD (data);
g_print ("have eos, quitting\n");