[gst-devel] autoplug2 roundup

[Wim Taymans]

hi folks,

just a quick roundup on what's going on with the development of the
new autoplugger. since we live and talk a lot in IRC lately the mailing
lists are a bit underused I fear. I plan to send out a roundup like this
every few days/weeks, whenever something usefull has been discused.


the purpose
-----------

the autoplugger is an algortihm in the  gstreamer core to automagically
construct a pipeline. this feature is mainly used in the media player,
where you let the typedetect functions detect the media stream type
and you let the autoplugger figure out how to play it.

Another important feature of the autoplugger is to provide an API to
construct meta elements, based on the functionality you want. This, for
example, will allow you to say: "I want media type X converted to Y, give
me an element that does this". In order to convert from X to Y it is
possible that you'll have to pick several plugins and connect them. The
autoplugger provides a clean interface to handle this complexity.

Another important thing to note is that a different set of autopluggers
can be constructed:

 - a static autoplugger: The autoplugger constructs the pipeline *before*
         it is actually set to the playing state. This is done by
         conservativily selecting elements that can always connect at 
         runtime (the src caps are less general than the sink caps).
         At runtime, no elements are added/removed from the bin.

 - a dynamic autoplugger: The autoplugger adds elements to the pipeline at
         runtime. This autoplugger can addapt itself much better to the
         runtime behaviour of the pipeline and is consequently much more
         difficult and needs dynamic scheduling in order to work.

Another thing to note is that the autoplugger might construct a threaded
pipeline or a non threaded one. The way the pipeline is constructed is
important for the user app using the autoplugger bacause the user app has
to take care of the different threads contexts in the src and sink pads
provided by the meta element.


The way things are (were)
-------------------------

The autoplugger in the HEAD branch was a first attempt at providing such
an API. It was tied to the GstPipeline element with the following API:

 - you'd add a src element to the pipeline
 - you'd add several sink elements to the pipeline
 - you'd call gst_pipeline_autoplug on the pipeline

the pipeline then ran the typedetect function on the src element and 
constructed a complete pipeline to all the sinks (if possible). The 
procedure to do this is described in docs/random/autoplug1.

while this procudere works for the mediaplayer, it has some serious
drawbacks:

 - a lot of complexity is hidden inside the pipeline element. 
 - the pipeline is conceptually the wrong place to do this.
 - only one autoplugger was implemented: the static autoplugger. There is
   no scalability in the way it was implemented.
 - no usable meta element creation API.
 - it only created threaded meta elements
 - the autoplugger was compiled into libgst which adds bloat for apps that
   don't use the autoplugger.

The new Autoplugger
-------------------

A new autoplugging framework is being build in the AUTOPLUG2 branch to 
solve the problems we had. The changes are:

 - an abstract GstAutoplug class has been constructed that provides the
   API to the autopluggers.
 - a plugin can add an autoplugger to the core system. this means that
   autopluggers can now be implemented in separate plugins.
 - both an API to construct a non threaded meta element and an API to
   construct a rendering pipeline have been added.

A short introduction to the proposed API:

1. creating the autoplugger

   GstAutoplug *autoplug = gst_autoplugfactory_make ("staticrender");

2. finding the provided API of the autoplugger

  you can find out if the autoplugger supports the renderer or the
  meta element API by querying its flags.

3. creating meta elements for use in a pipeline

  if the autoplugger supports the meta element API you'd call:

  element = gst_autoplug_to_caps (autoplug,
                  g_list_append (NULL, gst_caps_new(
                          "testcaps7",
                          "video/avi")),
                  g_list_append (NULL, gst_caps_new("testcaps8", "video/raw")),
                  g_list_append (NULL, gst_caps_new("testcaps9", "audio/raw")),
                  NULL);

  to get an element that can convert video/avi to video/raw and audio/raw.
  the meta element will have a sink pad with the provided caps and one or
  more src caps. The element will not have any threads so that you can
  easily use it in your pipelines.

4. creating a renderer element

  if the autoplugger supports the renderer API you can call:

  sink1 = gst_elementfactory_make ("videosink", "videosink");
  sink2 = gst_elementfactory_make ("audiosink", "audiosink");

  element = gst_autoplug_to_renderers (autoplug,
                  g_list_append (NULL, gst_caps_new_with_props(
                          "testcaps10",
                          "video/mpeg",
                          gst_props_new (
                              "mpegversion",  GST_PROPS_INT (1),
                              "systemstream", GST_PROPS_BOOLEAN (TRUE),
                              NULL))),
                  sink1,
                  sink2,
                  NULL);

  the meta element would not have any src pads, just a src pad with the
  provided caps. This meta element has threads and can be used in a 
  mediaplayer.

Comments?

Wim