diff --git a/ChangeLog b/ChangeLog index 51cac73067..4afc9d508e 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2004-12-15 Ronald S. Bultje + + * 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 * docs/random/ds/0.9-suggested-changes: diff --git a/docs/manual/advanced-autoplugging.xml b/docs/manual/advanced-autoplugging.xml index 14480dc8d8..717c4ad17a 100644 --- a/docs/manual/advanced-autoplugging.xml +++ b/docs/manual/advanced-autoplugging.xml @@ -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. - - - - Another approach to autoplugging - - 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. - - - The spider element - - 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: - - $ gst-launch filesrc location=my.mp3 ! spider ! osssink - - The spider will detect the type of the stream, autoplug it to the osssink's caps, and play - the pipeline. It's neat. - - - - Spider features - - - - - Automatically typefinds the incoming stream. - - - - - 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 - - - $ gst-launch filesrc location=my.mpeg1 ! spider ! { queue ! osssink } spider.src_%d! - { queue ! xvideosink } - - - - - - - - diff --git a/docs/manual/highlevel-components.xml b/docs/manual/highlevel-components.xml index 28ff2c5241..fa4f446376 100644 --- a/docs/manual/highlevel-components.xml +++ b/docs/manual/highlevel-components.xml @@ -230,6 +230,23 @@ main (gint argc, } + + Decodebin, similar to playbin, supports the following features: + + + + + Can decode an unlimited number of contained streams to decoded + output pads. + + + + + Is handled as a GstElement in all ways, + including tag or error forwarding and state handling. + + + 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, + + Decodebin can be easily tested on the commandline, e.g. by using the + command gst-launch-0.8 filesrc location=file.ogg ! decodebin + ! audioconvert ! audioscale ! alsasink. + Spider - 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, + gst-launch-0.8 filesrc location=file.ogg ! spider ! + audioconvert ! audioscale ! alsasink. 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). + + + 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. + + + 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.