mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-26 19:51:11 +00:00
docs/manual/: Move spider from autoplugging to components. Autoplugging is for internals, not for solutions. ;-).
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:
parent
70960c018b
commit
bff4d602e6
3 changed files with 52 additions and 51 deletions
|
@ -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:
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
||||
|
|
Loading…
Reference in a new issue