mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-11-23 02:01:12 +00:00
Code Issues 1 Projects Releases Wiki Activity

docs/manual/: Move spider from autoplugging to components. Autoplugging is for internals, not for solutions. ;-).

Browse source 
Original commit message from CVS:
* docs/manual/advanced-autoplugging.xml:
* docs/manual/highlevel-components.xml:
Move spider from autoplugging to components. Autoplugging is for
internals, not for solutions. ;-).
This commit is contained in:
Ronald S. Bultje 2004-12-15 21:45:55 +00:00
parent 70960c018b
commit bff4d602e6
3 changed files with 52 additions and 51 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
ChangeLog
View file

@ -1,3 +1,10 @@
2004-12-15 Ronald S. Bultje <rbultje@ronald.bitfreak.net>
* docs/manual/advanced-autoplugging.xml:
* docs/manual/highlevel-components.xml:
Move spider from autoplugging to components. Autoplugging is for
internals, not for solutions. ;-).
2004-12-15 Ronald S. Bultje <rbultje@ronald.bitfreak.net>
* docs/random/ds/0.9-suggested-changes:

50
docs/manual/advanced-autoplugging.xml
View file

@ -587,55 +587,5 @@ type_found (GstElement *typefind, GstCaps* caps)
that can handle this particular caps structure, or we can also use the
autoplugger to link this caps structure to, for example, a videosink.
</para>
</sect1>
<sect1 id="section-autoplugging-spider">
<title>Another approach to autoplugging</title>
<para>
The autoplug API is interesting, but often impractical. It is static;
it cannot deal with dynamic pipelines. An element that will
automatically figure out and decode the type is more useful.
Enter the spider.
</para>
<sect2>
<title>The spider element</title>
<para>
The spider element is a generalized autoplugging element. At this point (April 2002), it's
the best we've got; it can be inserted anywhere within a pipeline to perform caps
conversion, if possible. Consider the following gst-launch line:
<programlisting>
$ gst-launch filesrc location=my.mp3 ! spider ! osssink
</programlisting>
The spider will detect the type of the stream, autoplug it to the osssink's caps, and play
the pipeline. It's neat.
</para>
</sect2>
<sect2>
<title>Spider features</title>
<para>
<orderedlist>
<listitem>
<para>
Automatically typefinds the incoming stream.
</para>
</listitem>
<listitem>
<para>
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!
{ queue ! xvideosink }
</programlisting>
</para>
</listitem>
</orderedlist>
</para>
</sect2>
</sect1>
</chapter>

46
docs/manual/highlevel-components.xml
View file

@ -230,6 +230,23 @@ main (gint argc,
}
<!-- example-end decodebin.c --></programlisting>
<para>
Decodebin, similar to playbin, supports the following features:
</para>
<itemizedlist>
<listitem>
<para>
Can decode an unlimited number of contained streams to decoded
output pads.
</para>
</listitem>
<listitem>
<para>
Is handled as a <classname>GstElement</classname> in all ways,
including tag or error forwarding and state handling.
</para>
</listitem>
</itemizedlist>
<para>
Although decodebin is a good autoplugger, there's a whole lot of
things that it does not do and is not intended to do:
@ -253,13 +270,40 @@ main (gint argc,
</para>
</listitem>
</itemizedlist>
<para>
Decodebin can be easily tested on the commandline, e.g. by using the
command <command>gst-launch-0.8 filesrc location=file.ogg ! decodebin
! audioconvert ! audioscale ! alsasink</command>.
</para>
</sect1>
<sect1 id="section-components-spider">
<title>Spider</title>
<para>
Bla
Spider is an autoplugger that looks and feels very much like decodebin.
On the commandline, you can literally switch between spider and
decodebin and it'll mostly just work. Try, for example,
<command>gst-launch-0.8 filesrc location=file.ogg ! spider !
audioconvert ! audioscale ! alsasink</command>. Although the two may
seem very much alike from the outside, they are very different from
the inside. Those internal differences are the main reason why spider
is currently considered deprecated (along with the fact that it was
hard to maintain).
</para>
<para>
As opposed to decodebin, spider does not decode pads and emit signals
for each detected stream. Instead, you have to add output sinks to
spider by create source request pads and connecting those to sink
elements. This means that streams decoded by spider cannot be dynamic.
Also, spider uses many loop-based elements internally, which is rather
heavy scheduler-wise.
</para>
<para>
Code for using spider would look almost identical to the code of
decodebin, and is therefore omitted. Also, featureset and limitations
are very much alike, except for the above-mentioned extra limitations
for spider with respect to decodebin.
</para>
</sect1>