mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-15 22:01:27 +00:00
docs/pwg/: Typo fixes.
Original commit message from CVS: * docs/pwg/advanced-scheduling.xml: * docs/pwg/advanced-tagging.xml: * docs/pwg/advanced-types.xml: * docs/pwg/building-boiler.xml: * docs/pwg/building-chainfn.xml: * docs/pwg/building-signals.xml: * docs/pwg/building-state.xml: * docs/pwg/building-testapp.xml: * docs/pwg/intro-basics.xml: * docs/pwg/other-manager.xml: * docs/pwg/other-source.xml: Typo fixes. * docs/pwg/other-manager.xml: Add some first content. No example code yet. * gst/elements/gstfilesink.c: (gst_filesink_handle_event): Remove double newlines.
This commit is contained in:
parent
df7f3e4161
commit
79b77446d8
14 changed files with 121 additions and 33 deletions
19
ChangeLog
19
ChangeLog
|
@ -1,3 +1,22 @@
|
||||||
|
2004-11-06 Ronald S. Bultje <rbultje@ronald.bitfreak.net>
|
||||||
|
|
||||||
|
* docs/pwg/advanced-scheduling.xml:
|
||||||
|
* docs/pwg/advanced-tagging.xml:
|
||||||
|
* docs/pwg/advanced-types.xml:
|
||||||
|
* docs/pwg/building-boiler.xml:
|
||||||
|
* docs/pwg/building-chainfn.xml:
|
||||||
|
* docs/pwg/building-signals.xml:
|
||||||
|
* docs/pwg/building-state.xml:
|
||||||
|
* docs/pwg/building-testapp.xml:
|
||||||
|
* docs/pwg/intro-basics.xml:
|
||||||
|
* docs/pwg/other-manager.xml:
|
||||||
|
* docs/pwg/other-source.xml:
|
||||||
|
Typo fixes.
|
||||||
|
* docs/pwg/other-manager.xml:
|
||||||
|
Add some first content. No example code yet.
|
||||||
|
* gst/elements/gstfilesink.c: (gst_filesink_handle_event):
|
||||||
|
Remove double newlines.
|
||||||
|
|
||||||
2004-11-04 Wim Taymans <wim@fluendo.com>
|
2004-11-04 Wim Taymans <wim@fluendo.com>
|
||||||
|
|
||||||
* gst/schedulers/gstoptimalscheduler.c: (add_to_group),
|
* gst/schedulers/gstoptimalscheduler.c: (add_to_group),
|
||||||
|
|
|
@ -98,8 +98,8 @@
|
||||||
Examples of elements that <emphasis>have</emphasis> to be loop-based are
|
Examples of elements that <emphasis>have</emphasis> to be loop-based are
|
||||||
elements with multiple sink pads. Since the scheduler will push data into
|
elements with multiple sink pads. Since the scheduler will push data into
|
||||||
the pads as it comes (and this might not be synchronous), you will easily
|
the pads as it comes (and this might not be synchronous), you will easily
|
||||||
get ascynronous data on both pads, which means that the data that arrives
|
get asynchronous data on both pads, which means that the data that arrives
|
||||||
on the first pad has a different display timestamp then the data arriving
|
on the first pad has a different display timestamp than the data arriving
|
||||||
on the second pad at the same time. To get over these issues, you should
|
on the second pad at the same time. To get over these issues, you should
|
||||||
write such elements in a loop-based form. Other elements that are
|
write such elements in a loop-based form. Other elements that are
|
||||||
<emphasis>easier</emphasis> to write in a loop-based form than in a
|
<emphasis>easier</emphasis> to write in a loop-based form than in a
|
||||||
|
@ -264,14 +264,34 @@ gst_my_filter_loopfunc (GstElement *element)
|
||||||
<para>
|
<para>
|
||||||
A second type of elements that wants to be loop-based, are the so-called
|
A second type of elements that wants to be loop-based, are the so-called
|
||||||
bytestream-elements. Until now, we've only dealt with elements that
|
bytestream-elements. Until now, we've only dealt with elements that
|
||||||
receive of pull full buffers of a random size from other elements. Often,
|
receive or pull full buffers of a random size from other elements. Often,
|
||||||
however, it is wanted to have control over the stream at a byte-level,
|
however, it is wanted to have control over the stream at a byte-level,
|
||||||
such as in stream parsers or demuxers. It is possible to manually pull
|
such as in stream parsers or demuxers. It is possible to manually pull
|
||||||
buffers and merge them until a certain size; it is easier, however, to
|
buffers and merge them until a certain size; it is easier, however, to
|
||||||
use bytestream, which wraps this behaviour.
|
use bytestream, which wraps this behaviour.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
Bytestream-using elements are ususally stream parsers or demuxers. For
|
To use bytestream, you need to load the bytestream when your plugin is
|
||||||
|
loaded; you should do this before registering the element, which you
|
||||||
|
learned previously in <xref linkend="section-boiler-plugininit"/>.
|
||||||
|
After that, all functions of the bytestream plugin are available in
|
||||||
|
your plugin as well.
|
||||||
|
</para>
|
||||||
|
<programlisting>
|
||||||
|
#include <gst/bytestream/bytestream.h>
|
||||||
|
|
||||||
|
static gboolean
|
||||||
|
plugin_init (GstPlugin *plugin)
|
||||||
|
{
|
||||||
|
if (!gst_library_load ("gstbytestream"))
|
||||||
|
return FALSE;
|
||||||
|
|
||||||
|
/* and now, actually register the element */
|
||||||
|
[..]
|
||||||
|
}
|
||||||
|
</programlisting>
|
||||||
|
<para>
|
||||||
|
Bytestream-using elements are usually stream parsers or demuxers. For
|
||||||
now, we will take a parser as an example. Demuxers require some more
|
now, we will take a parser as an example. Demuxers require some more
|
||||||
magic that will be dealt with later in this guide:
|
magic that will be dealt with later in this guide:
|
||||||
<xref linkend="chapter-advanced-request"/>. The goal of this parser will be
|
<xref linkend="chapter-advanced-request"/>. The goal of this parser will be
|
||||||
|
|
|
@ -2,7 +2,7 @@
|
||||||
<title>Tagging (Metadata and Streaminfo)</title>
|
<title>Tagging (Metadata and Streaminfo)</title>
|
||||||
<para>
|
<para>
|
||||||
Tags are pieces of information stored in a stream that are not the content
|
Tags are pieces of information stored in a stream that are not the content
|
||||||
itself, butthey rather <emphasis>describe</emphasis> the content. Most
|
itself, but they rather <emphasis>describe</emphasis> the content. Most
|
||||||
media container formats support tagging in one way or another. Ogg uses
|
media container formats support tagging in one way or another. Ogg uses
|
||||||
VorbisComment for this, MP3 uses ID3, AVI and WAV use RIFF's INFO list
|
VorbisComment for this, MP3 uses ID3, AVI and WAV use RIFF's INFO list
|
||||||
chunk, etc. GStreamer provides a general way for elements to read tags from
|
chunk, etc. GStreamer provides a general way for elements to read tags from
|
||||||
|
@ -70,7 +70,7 @@
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
The following example program will parse a file and parse the data as
|
The following example program will parse a file and parse the data as
|
||||||
metadata/tags rathen than as actual content-data. It will parse each
|
metadata/tags rather than as actual content-data. It will parse each
|
||||||
line as <quote>name:value</quote>, where name is the type of metadata
|
line as <quote>name:value</quote>, where name is the type of metadata
|
||||||
(title, author, ...) and value is the metadata value. The
|
(title, author, ...) and value is the metadata value. The
|
||||||
<function>_getline ()</function> is the same as the one given in
|
<function>_getline ()</function> is the same as the one given in
|
||||||
|
|
|
@ -11,7 +11,7 @@
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
In order for types to be useful, and for systems like autopluggers to
|
In order for types to be useful, and for systems like autopluggers to
|
||||||
work, it is neccessary that all elements agree on the type definitions,
|
work, it is necessary that all elements agree on the type definitions,
|
||||||
and which properties are required for each type. The &GStreamer; framework
|
and which properties are required for each type. The &GStreamer; framework
|
||||||
itself simply provides the ability to define types and parameters, but
|
itself simply provides the ability to define types and parameters, but
|
||||||
does not fix the meaning of types and parameters, and does not enforce
|
does not fix the meaning of types and parameters, and does not enforce
|
||||||
|
@ -117,8 +117,8 @@ gst_my_typefind_function (GstTypeFind *tf,
|
||||||
guint8 *data = gst_type_find_peek (tf, 0, 12);
|
guint8 *data = gst_type_find_peek (tf, 0, 12);
|
||||||
|
|
||||||
if (data &&
|
if (data &&
|
||||||
GUINT32_FROM_LE ((guint32 *) data)[0] == GST_MAKE_FOURCC ('R','I','F','F') &&
|
GUINT32_FROM_LE (((guint32 *) data)[0]) == GST_MAKE_FOURCC ('R','I','F','F') &&
|
||||||
GUINT32_FROM_LE ((guint32 *) data)[2] == GST_MAKE_FOURCC ('A','V','I',' ')) {
|
GUINT32_FROM_LE (((guint32 *) data)[2]) == GST_MAKE_FOURCC ('A','V','I',' ')) {
|
||||||
gst_type_find_suggest (tf, GST_TYPE_FIND_MAXIMUM,
|
gst_type_find_suggest (tf, GST_TYPE_FIND_MAXIMUM,
|
||||||
gst_caps_new_simple ("video/x-msvideo", NULL));
|
gst_caps_new_simple ("video/x-msvideo", NULL));
|
||||||
}
|
}
|
||||||
|
@ -375,7 +375,7 @@ plugin_init (GstPlugin *plugin)
|
||||||
<entry>layout</entry>
|
<entry>layout</entry>
|
||||||
<entry>string</entry>
|
<entry>string</entry>
|
||||||
<entry>
|
<entry>
|
||||||
<quote>quicktime</quote>, <quote>wav</quote>,
|
<quote>quicktime</quote>, <quote>dvi</quote>,
|
||||||
<quote>microsoft</quote> or <quote>4xm</quote>.
|
<quote>microsoft</quote> or <quote>4xm</quote>.
|
||||||
</entry>
|
</entry>
|
||||||
<entry>
|
<entry>
|
||||||
|
|
|
@ -33,7 +33,7 @@
|
||||||
</para>
|
</para>
|
||||||
<screen>
|
<screen>
|
||||||
<prompt>shell $ </prompt><userinput>cvs -d:pserver:anoncvs@cvs.freedesktop.org/cvs/gstreamer co login</userinput>
|
<prompt>shell $ </prompt><userinput>cvs -d:pserver:anoncvs@cvs.freedesktop.org/cvs/gstreamer co login</userinput>
|
||||||
Logging in to :pserver:anoncvs@cvs.freedesktop.org:2401/cvs/gstreamer
|
Logging in to :pserver:anoncvs@cvs.freedesktop.org:/cvs/gstreamer
|
||||||
CVS password: <keycap>[ENTER]</keycap>
|
CVS password: <keycap>[ENTER]</keycap>
|
||||||
|
|
||||||
<prompt>shell $ </prompt><userinput>cvs -z3 -d:pserver:anoncvs@cvs.freedesktop.org:/cvs/gstreamer co gst-template</userinput>
|
<prompt>shell $ </prompt><userinput>cvs -z3 -d:pserver:anoncvs@cvs.freedesktop.org:/cvs/gstreamer co gst-template</userinput>
|
||||||
|
@ -207,7 +207,10 @@ static GstElementDetails example_details = {
|
||||||
</programlisting>
|
</programlisting>
|
||||||
<para>
|
<para>
|
||||||
The element details are registered with the plugin during
|
The element details are registered with the plugin during
|
||||||
<function>_base_init ()</function>.
|
the <function>_base_init ()</function> function, which is part of
|
||||||
|
the GObject system. The <function>_base_init ()</function> function
|
||||||
|
should be set for this GObject in the function where you register
|
||||||
|
the type with Glib.
|
||||||
</para>
|
</para>
|
||||||
<programlisting>
|
<programlisting>
|
||||||
static void
|
static void
|
||||||
|
@ -270,15 +273,18 @@ GST_STATIC_PAD_TEMPLATE (
|
||||||
<function>gst_pad_new_from_template ()</function>. The template can be
|
<function>gst_pad_new_from_template ()</function>. The template can be
|
||||||
retrieved from the element class using
|
retrieved from the element class using
|
||||||
<function>gst_element_class_get_pad_template ()</function>. See below
|
<function>gst_element_class_get_pad_template ()</function>. See below
|
||||||
for more details on this.
|
for more details on this. In order to create a new pad from this
|
||||||
|
template using <function>gst_pad_new_from_template ()</function>, you
|
||||||
|
will need to declare the pad template as a global variable. More on
|
||||||
|
this subject in <xref linkend="chapter-building-pads"/>.
|
||||||
</para>
|
</para>
|
||||||
<programlisting>
|
<programlisting>
|
||||||
|
static GstStaticPadTemplate sink_factory = [..],
|
||||||
|
src_factory = [..];
|
||||||
|
|
||||||
static void
|
static void
|
||||||
gst_my_filter_base_init (GstMyFilterClass *klass)
|
gst_my_filter_base_init (GstMyFilterClass *klass)
|
||||||
{
|
{
|
||||||
static GstStaticPadTemplate sink_factory =
|
|
||||||
[..]
|
|
||||||
, src_factory =
|
|
||||||
[..]
|
[..]
|
||||||
GstElementClass *element_class = GST_ELEMENT_CLASS (klass);
|
GstElementClass *element_class = GST_ELEMENT_CLASS (klass);
|
||||||
|
|
||||||
|
|
|
@ -6,7 +6,7 @@
|
||||||
<para>
|
<para>
|
||||||
The chain function is the function in which all data processing takes
|
The chain function is the function in which all data processing takes
|
||||||
place. In the case of a simple filter, <function>_chain ()</function>
|
place. In the case of a simple filter, <function>_chain ()</function>
|
||||||
functions are mostly lineair functions - so for each incoming buffer,
|
functions are mostly linear functions - so for each incoming buffer,
|
||||||
one buffer will go out, too. Below is a very simple implementation of
|
one buffer will go out, too. Below is a very simple implementation of
|
||||||
a chain function:
|
a chain function:
|
||||||
</para>
|
</para>
|
||||||
|
|
|
@ -4,11 +4,13 @@
|
||||||
<chapter id="chapter-building-signals">
|
<chapter id="chapter-building-signals">
|
||||||
<title>Signals</title>
|
<title>Signals</title>
|
||||||
<para>
|
<para>
|
||||||
Signals can be used to notify applications of events specific to this
|
GObject signals can be used to notify applications of events specific
|
||||||
object. Note, however, that the application needs to be aware of signals
|
to this object. Note, however, that the application needs to be aware
|
||||||
and their meaning, so if you're looking for a generic way for application-
|
of signals and their meaning, so if you're looking for a generic way
|
||||||
element interaction, signals are probably not what you're looking for. In
|
for application-element interaction, signals are probably not what
|
||||||
many cases, however, signals can be very useful. See the GObject
|
you're looking for. In many cases, however, signals can be very useful.
|
||||||
documentation for all internals about signals.
|
See the <ulink type="http"
|
||||||
|
url="http://www.le-hacker.org/papers/gobject/index.html">GObject
|
||||||
|
documentation</ulink> for all internals about signals.
|
||||||
</para>
|
</para>
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|
|
@ -56,7 +56,7 @@
|
||||||
|
|
||||||
<sect1 id="section-statemanage-filters">
|
<sect1 id="section-statemanage-filters">
|
||||||
<title>
|
<title>
|
||||||
Mangaging filter state
|
Managing filter state
|
||||||
</title>
|
</title>
|
||||||
<para>
|
<para>
|
||||||
An element can be notified of state changes through a virtual function
|
An element can be notified of state changes through a virtual function
|
||||||
|
|
|
@ -4,7 +4,7 @@
|
||||||
<title>Building a Test Application</title>
|
<title>Building a Test Application</title>
|
||||||
<para>
|
<para>
|
||||||
Often, you will want to test your newly written plugin in an as small
|
Often, you will want to test your newly written plugin in an as small
|
||||||
setting as possible. Ususally, <filename>gst-launch</filename> is a
|
setting as possible. Usually, <filename>gst-launch</filename> is a
|
||||||
good first step at testing a plugin. However, you will often need more
|
good first step at testing a plugin. However, you will often need more
|
||||||
testing features than gst-launch can provide, such as seeking, events,
|
testing features than gst-launch can provide, such as seeking, events,
|
||||||
interactivity and more. Writing your own small testing program is the
|
interactivity and more. Writing your own small testing program is the
|
||||||
|
|
|
@ -42,7 +42,7 @@
|
||||||
One type of bin is responsible for scheduling the elements that they
|
One type of bin is responsible for scheduling the elements that they
|
||||||
contain so that data flows smoothly. Another type of bin, called
|
contain so that data flows smoothly. Another type of bin, called
|
||||||
<emphasis>autoplugger</emphasis> elements, automatically add other
|
<emphasis>autoplugger</emphasis> elements, automatically add other
|
||||||
elements to the bin and link them together so that they act as a
|
elements to the bin and links them together so that they act as a
|
||||||
filter between two arbitary stream types.
|
filter between two arbitary stream types.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
|
|
|
@ -4,6 +4,51 @@
|
||||||
<chapter id="chapter-other-manager" xreflabel="Writing a Manager">
|
<chapter id="chapter-other-manager" xreflabel="Writing a Manager">
|
||||||
<title>Writing a Manager</title>
|
<title>Writing a Manager</title>
|
||||||
<para>
|
<para>
|
||||||
FIXME: write.
|
Managers are elements that add a function or unify the function of
|
||||||
|
another (series of) element(s). Managers are generally a
|
||||||
|
<classname>GstBin</classname> with one or more ghostpads. Inside them
|
||||||
|
is/are the actual element(s) that matters. There is several cases where
|
||||||
|
this is useful. For example:
|
||||||
</para>
|
</para>
|
||||||
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
To add support for private events with custom event handling to
|
||||||
|
another element.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
To add support for custom pad <function>_query ()</function>
|
||||||
|
or <function>_convert ()</function> handling to another element.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
To add custom data handling before or after another element's data
|
||||||
|
handler function (generally its <function>_chain ()</function>
|
||||||
|
function).
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
<para>
|
||||||
|
This chapter will explain the setup of managers. As a specific example,
|
||||||
|
we will try to add EOS event support to source elements. This can be
|
||||||
|
used to finish capturing an audio stream to a file. Source elements
|
||||||
|
normally don't do any EOS handling at all, so a manager is perfect to
|
||||||
|
extend those element's functionalities.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
Specifically, this element will contain two child elements: the actual
|
||||||
|
source element and a <quote>helper element</quote> that implement an
|
||||||
|
event handler on its source pad. This event handler will respond to
|
||||||
|
EOS events by storing them internally and returning the event (rather
|
||||||
|
than data) on the next call to the <function>_get ()</function>
|
||||||
|
function. After that, it will go into EOS and set the parent (and
|
||||||
|
thereby the contained source element) to EOS as well. Other events will
|
||||||
|
be forwarded to the source element, which will handle them as usual.
|
||||||
|
</para>
|
||||||
|
<programlisting>
|
||||||
|
..
|
||||||
|
</programlisting>
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|
|
@ -356,7 +356,7 @@ gst_my_source_init (GstMySource *src)
|
||||||
src->sync = FALSE;
|
src->sync = FALSE;
|
||||||
}
|
}
|
||||||
|
|
||||||
static void
|
static GstData *
|
||||||
gst_my_source_get (GstPad *pad)
|
gst_my_source_get (GstPad *pad)
|
||||||
{
|
{
|
||||||
GstMySource *src = GST_MY_SOURCE (gst_pad_get_parent (pad));
|
GstMySource *src = GST_MY_SOURCE (gst_pad_get_parent (pad));
|
||||||
|
@ -436,7 +436,7 @@ gst_my_source_buffer_free (GstBuffer *buf)
|
||||||
* flag. */
|
* flag. */
|
||||||
}
|
}
|
||||||
|
|
||||||
static void
|
static GstData *
|
||||||
gst_my_source_get (GstPad *pad)
|
gst_my_source_get (GstPad *pad)
|
||||||
{
|
{
|
||||||
GstMySource *src = GST_MY_SOURCE (gst_pad_get_parent (pad));
|
GstMySource *src = GST_MY_SOURCE (gst_pad_get_parent (pad));
|
||||||
|
|
|
@ -343,13 +343,11 @@ gst_filesink_handle_event (GstPad * pad, GstEvent * event)
|
||||||
|
|
||||||
filesink = GST_FILESINK (gst_pad_get_parent (pad));
|
filesink = GST_FILESINK (gst_pad_get_parent (pad));
|
||||||
|
|
||||||
|
|
||||||
if (!(GST_FLAG_IS_SET (filesink, GST_FILESINK_OPEN))) {
|
if (!(GST_FLAG_IS_SET (filesink, GST_FILESINK_OPEN))) {
|
||||||
gst_event_unref (event);
|
gst_event_unref (event);
|
||||||
return FALSE;
|
return FALSE;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
||||||
type = event ? GST_EVENT_TYPE (event) : GST_EVENT_UNKNOWN;
|
type = event ? GST_EVENT_TYPE (event) : GST_EVENT_UNKNOWN;
|
||||||
|
|
||||||
switch (type) {
|
switch (type) {
|
||||||
|
|
|
@ -343,13 +343,11 @@ gst_filesink_handle_event (GstPad * pad, GstEvent * event)
|
||||||
|
|
||||||
filesink = GST_FILESINK (gst_pad_get_parent (pad));
|
filesink = GST_FILESINK (gst_pad_get_parent (pad));
|
||||||
|
|
||||||
|
|
||||||
if (!(GST_FLAG_IS_SET (filesink, GST_FILESINK_OPEN))) {
|
if (!(GST_FLAG_IS_SET (filesink, GST_FILESINK_OPEN))) {
|
||||||
gst_event_unref (event);
|
gst_event_unref (event);
|
||||||
return FALSE;
|
return FALSE;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
||||||
type = event ? GST_EVENT_TYPE (event) : GST_EVENT_UNKNOWN;
|
type = event ? GST_EVENT_TYPE (event) : GST_EVENT_UNKNOWN;
|
||||||
|
|
||||||
switch (type) {
|
switch (type) {
|
||||||
|
|
Loading…
Reference in a new issue