[gst-devel] autoplug...

[Wim Taymans]

Hi,

While writing the manual, I came across one of the main problems
with the typedetect and autoplug stuff.

I first explained the method we are using now: creating the elements
*by name*. Now I'm explaining the method of creating the elements
by MIME type, which is the way to go if we want to have multiple
decoders for the same MIME types.

Some functions exist to search for an element with a given MIME type.
What I don't want to explain in the manual is how you are going to
construct a pipeline like this:

  dirsksrc->mp3parse->mpg123->audiosink

with only the gst_type_get_by_id() function.

I would like to have something like

  GList *gst_type_get_src_to_sink(src_id, sink_id)

to retrive a list of elements that will form a pad from
audio/mpeg to audio/raw. The algorithm would try to find the 
shortest pad between the two types which can be a very
generic operation.

The programmer does not need to know that there are several
elements involved to create this pipeline.

Erik, this is closely related to autoplugging you mentioned
in several documents. Where would
a function like this fit in best? We should probably also
preconnect the pads, in which case we should better have 
something like:

  GstBin *gst_bin_autoplug(src_id, sink_id);

or

  GstBin *gst_bin_autoplug(GstElement src, GstElement sink);

The point is that for the common case the app programmer
would only have to do:

  create src
  create parser (or have it autodetected)
  create sink with gst_type_get_sinks(type)
  add above elements to main_pipeline
  get a bin that connnects the parser to the sink
  add bin to pipeline
  run pipeline

instead of:

  create src
  create parser (or autodetect)
  create sink
  (some logic to find out that the MIME type
   of the parser is not audio/raw) {
    (some more logic to find an element to convert
     the type of the parser to audio/raw)
    (find out that such an element does not exist or
     that there a five of them)
    (take an element that sinks the type of the
     parser) {
      (find an element that sinks this type)
      (find out that this element does not src audio/raw)
      more horror...
    }
  }

very hard to explain...

When I come to think of it... We could even add a flag to
the pad like:

  GST_PAD_SUGGEST_THREAD

so that the bin returned from the autoplug call would be a
thread with a queue if some element suggests it.

This would make creating a five threaded MPEG player trivial:

  create src
  create parser (or autodetect)
  create videosink
  create audiosink
  get bin to connect parser to videosink
  get bin to connect parser to audiosink
  run

internally all the elements would be resolved using MIME types
so that the user can switch MPEG decoders on the fly...
*very* cool if that would work out...

If you hav no objections, I would try to implement this idea.

Wim


-- 
QOTD:
	"What women and psychologists call `dropping your armor', we call
	"baring your neck."