mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-12-31 04:30:55 +00:00
Code Issues 1 Projects Releases Wiki Activity

docs/pwg/: Typo fixes.

Browse source 
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:
Ronald S. Bultje 2004-11-06 10:28:07 +00:00
parent df7f3e4161
commit 79b77446d8
14 changed files with 121 additions and 33 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
ChangeLog
View file

@ -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>
* gst/schedulers/gstoptimalscheduler.c: (add_to_group),

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

@ -98,8 +98,8 @@
Examples of elements that <emphasis>have</emphasis> to be loop-based are
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
get ascynronous data on both pads, which means that the data that arrives
on the first pad has a different display timestamp then the data arriving
get asynchronous data on both pads, which means that the data that arrives
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
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
@ -264,14 +264,34 @@ gst_my_filter_loopfunc (GstElement *element)
<para>
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
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,
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
use bytestream, which wraps this behaviour.
</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 &lt;gst/bytestream/bytestream.h&gt;
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
magic that will be dealt with later in this guide:
<xref linkend="chapter-advanced-request"/>. The goal of this parser will be

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

@ -2,7 +2,7 @@
<title>Tagging (Metadata and Streaminfo)</title>
<para>
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
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
@ -70,7 +70,7 @@
</para>
<para>
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
(title, author, ...) and value is the metadata value. The
<function>_getline ()</function> is the same as the one given in

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

@ -11,7 +11,7 @@
</para>
<para>
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
itself simply provides the ability to define types and parameters, but
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);
if (data &amp;&amp;
GUINT32_FROM_LE ((guint32 *) data)[0] == GST_MAKE_FOURCC ('R','I','F','F') &amp;&amp;
GUINT32_FROM_LE ((guint32 *) data)[2] == GST_MAKE_FOURCC ('A','V','I',' ')) {
GUINT32_FROM_LE (((guint32 *) data)[0]) == GST_MAKE_FOURCC ('R','I','F','F') &amp;&amp;
GUINT32_FROM_LE (((guint32 *) data)[2]) == GST_MAKE_FOURCC ('A','V','I',' ')) {
gst_type_find_suggest (tf, GST_TYPE_FIND_MAXIMUM,
gst_caps_new_simple ("video/x-msvideo", NULL));
}
@ -375,7 +375,7 @@ plugin_init (GstPlugin *plugin)
<entry>layout</entry>
<entry>string</entry>
<entry>
<quote>quicktime</quote>, <quote>wav</quote>,
<quote>quicktime</quote>, <quote>dvi</quote>,
<quote>microsoft</quote> or <quote>4xm</quote>.
</entry>
<entry>

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

@ -33,7 +33,7 @@
</para>
<screen>
<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>
<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>
<para>
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>
<programlisting>
static void
@ -270,15 +273,18 @@ GST_STATIC_PAD_TEMPLATE (
<function>gst_pad_new_from_template ()</function>. The template can be
retrieved from the element class using
<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>
<programlisting>
static GstStaticPadTemplate sink_factory = [..],
src_factory = [..];
static void
gst_my_filter_base_init (GstMyFilterClass *klass)
{
static GstStaticPadTemplate sink_factory =
[..]
, src_factory =
[..]
GstElementClass *element_class = GST_ELEMENT_CLASS (klass);

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

@ -6,7 +6,7 @@
<para>
The chain function is the function in which all data processing takes
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
a chain function:
</para>

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

@ -4,11 +4,13 @@
<chapter id="chapter-building-signals">
<title>Signals</title>
<para>
Signals can be used to notify applications of events specific to this
object. Note, however, that the application needs to be aware of signals
and their meaning, so if you're looking for a generic way for application-
element interaction, signals are probably not what you're looking for. In
many cases, however, signals can be very useful. See the GObject
documentation for all internals about signals.
GObject signals can be used to notify applications of events specific
to this object. Note, however, that the application needs to be aware
of signals and their meaning, so if you're looking for a generic way
for application-element interaction, signals are probably not what
you're looking for. In many cases, however, signals can be very useful.
See the <ulink type="http"
url="http://www.le-hacker.org/papers/gobject/index.html">GObject
documentation</ulink> for all internals about signals.
</para>
</chapter>

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

@ -56,7 +56,7 @@
<sect1 id="section-statemanage-filters">
<title>
Mangaging filter state
Managing filter state
</title>
<para>
An element can be notified of state changes through a virtual function

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

@ -4,7 +4,7 @@
<title>Building a Test Application</title>
<para>
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
testing features than gst-launch can provide, such as seeking, events,
interactivity and more. Writing your own small testing program is the

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

@ -42,7 +42,7 @@
One type of bin is responsible for scheduling the elements that they
contain so that data flows smoothly. Another type of bin, called
<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.
</para>
<para>

47
docs/pwg/other-manager.xml
View file

@ -4,6 +4,51 @@
<chapter id="chapter-other-manager" xreflabel="Writing a Manager">
<title>Writing a Manager</title>
<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>
<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>

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

@ -356,7 +356,7 @@ gst_my_source_init (GstMySource *src)
src->sync = FALSE;
}
static void
static GstData *
gst_my_source_get (GstPad *pad)
{
GstMySource *src = GST_MY_SOURCE (gst_pad_get_parent (pad));
@ -436,7 +436,7 @@ gst_my_source_buffer_free (GstBuffer *buf)
* flag. */
}
static void
static GstData *
gst_my_source_get (GstPad *pad)
{
GstMySource *src = GST_MY_SOURCE (gst_pad_get_parent (pad));

2
gst/elements/gstfilesink.c
View file

@ -343,13 +343,11 @@ gst_filesink_handle_event (GstPad * pad, GstEvent * event)
filesink = GST_FILESINK (gst_pad_get_parent (pad));
if (!(GST_FLAG_IS_SET (filesink, GST_FILESINK_OPEN))) {
gst_event_unref (event);
return FALSE;
}
type = event ? GST_EVENT_TYPE (event) : GST_EVENT_UNKNOWN;
switch (type) {

2
plugins/elements/gstfilesink.c
View file

@ -343,13 +343,11 @@ gst_filesink_handle_event (GstPad * pad, GstEvent * event)
filesink = GST_FILESINK (gst_pad_get_parent (pad));
if (!(GST_FLAG_IS_SET (filesink, GST_FILESINK_OPEN))) {
gst_event_unref (event);
return FALSE;
}
type = event ? GST_EVENT_TYPE (event) : GST_EVENT_UNKNOWN;
switch (type) {