[gst-devel] autoplugging

[Wim Taymans]

The changes to the type system call for another way of doing auto-
plugging. With autoplugging we mean a procedure for automatically
inserting and connecting elements in a pipeline. The main use for
autoplugging will be gstplay, the universal media player for gstreamer.

first let's take a look at the situation before the typechanges.
plugins only had one way to describe the media types they were going to
sink (input) and src (output): mimtypes. In no time we had a pletora of 
non-sense mimetypes like video/mpeg-system, video/mpeg-frame, 
video/mpeg1-system etc... to describe the media types. The mimetypes were
kept in a directed graph were the mimetypes were the vetices and the 
plugins the edges that connect two vertices.

part of the graphs is like:

                 video/mpeg1-system           audio/raw
                      !            \          /
                      ! mpeg1parse  \        / lame, mpegaudio
                      !              \      /
                      V               V    V
            video/mpeg1-video      audio/mp3
                !                     !
                !mp1videoparse        !mp3parse
                V                     v
          video/mpeg1-frame         audio/mp3-frame
              !                           !
              !mpeg_play                  ! mpg123
              V                           V
           video/raw                   audio/raw


autoplugging would then proceed as follows:

   take the type of the src element (video/mpeg1-system)
   take the types of the sink elements (video/raw, audio/raw)

The shortest path between the src type and the first sink type
was found and a list of elementfactories was returned. In out
mpeg1 case we would have a list of the following mime-types that
are part of the video/mpeg1-system to video/raw conversion:

 video/mpeg1-system -> video/mpeg1-video -> video/mpeg1-frame -> video/raw

for video/mpeg1-system to audio/raw:

 video/mpeg1-system -> audio/mp3 -> audio/mp3-frame -> audio/raw

the elements that converted those types were added to the pipeline and
it sorta worked.


With the new type system we do not have all the semantics in the mime-types
so we cannot proceed as we did before. We need to look at the properties
added
to the capabilities of the pads in order to be able to connect the right 
elements. moreso: we cannot use the properties to generate a directed
graph.

We will first define some constraints for autoplugging with the new
type system:

 1. only one conversion (video/mpeg -> video/raw) is allowed. we are not
going
    to autoplug video/mpeg -> video/avi -> video/raw even it there is an  
    element that can input video/mpeg and convert it to avi and we have an
    element that can decoder avi. This also means that the type detected
    during typefind is the src type and the type of the sink element is the
    sink type.

 2. autoplugging will not be able to do everything (neither was the
previous
    implementation). We state that the more complicated cases (mpeg2) will
need
    a specialized bin. Note that the pipeline with this special bin will
still
    be constructed using autoplugging.

A new autoplugging proposal (1):

 1. typefind the srcpad of the source element of the pipeline (srctype).
 2. for each sink in the pipeline:
  a.  find sinktype (easy)
  b.  find a list of elements that connect srctype to sinktype
  c.  for each element
        find elements needed to connect this elements to the src
        find elements needed to connect this elements to the sink
 3. take shortest lists and create pipeline

Note that for step 2c we need to be carefull not to create a loop like
mpg123->lame->mpg123->... may this could be avoided with a shortest path
algorithm.

meanwhile I'm going to create a gstautoplugger.c in gst/ for testing 
purposes. All future autoplugging logic should go in here. 

Wim
   
-- 
	"Mach was the greatest intellectual fraud in the last ten years."
	"What about X?"
	"I said `intellectual'."
		;login, 9/1990