[gst-devel] autoplug...

[Wim Taymans]

Richard Boulton wrote:
> 
> On Sat, Aug 19, 2000 at 06:35:41PM +0200, Wim Taymans wrote:
> > 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.
> 
> Wow!  That sounds like an incredibly cool thing to be able to do.
> Lovely simple concept too.  The ability to do this (once it is
> written) should be a major bragging point to say how cool GStreamer
> is.
> 

Basically yes. You add a source and a sink to a pipeline, call
pipeline_autoplug, hit play and off you go... This is all possible with
the mime types we use to type the input and output pads of the plugins.

> What exactly do you mean by "shortest" path though?  Are you going
> to assume that all filters have the same cost, or allow them to
> specify a cost in some manner?  For example, there might be a naive
> filter to fiddle something which has a high cost; and some very
> efficient alternative path via an FFT, something weird, and then an
> inverse FFT - three elements, but it could be quicker...
> 

exactly. Currently all plugins say what type of data they accept and
emit. We maintain a graph of all the different transformations we 
support. For example:

type 1 audio/raw
type 2 audio/mpeg
type 3 audio/mpeg-frame
type 4 none
type 5 video/mpeg-system
type 6 video/mpeg1-video

we would have a graph like:


                 4
                 |
                 | disksrc (after type detection)
                 |
     mpeg1parse  v
   5------------>2 ----------> 3
                 ^  mp3parse  / 
       mpegaudio |           /
       bladeenc  |          /  mpg123
                 |         /   xing
                 |        /    xa
                 1 <------

and so on... 

Now when we say, convert audio/mpeg to audio/raw, we find the
shortest path, using a modified Dijkstra algorithm, from audio/mpeg
to audio/raw to retrieve a list of plugins like:

mp3parse -> mpg123

Since we have multiple plugins able to convert audio/mpeg-frame to
audio/raw, we have to make a choice. This is where the priorities
come into play. We can say that we prefer for example mpg123 before
xing. the algorithm with which the element is chosen can be
anything you want, based on performance for example or user
preference, I have not yet decided. You should probably have a 
setting too that indicates the criteria you want to use for autoplug,
like performance, correctness, hw accelerated...

support for path caches, graph caches, type caches etc. would make
this very fast and configurable.

We need to externalize the graph so that we don't need to load all
the plugins to construct the graph.
We also need to externalize the type detection code in some form of
script language.

We could also add flags to the pads to suggest the use of a thread.
This way, we could also autoplug with threads and all.

Oh, the beauty... I'm beginning to see the vision Erik has ;-)

> Also, the quality of the trasformed data might be a useful thing
> to be able to maximise.  You might have a quick'n'dirty filter for
> compressing mp3s and a slow but good filter: selecting whether to
> maximise for speed or quality could affect which of these gets used.

Yes, that is the idea. This is also where the capplet comes into play
to configure you plugins. It can be a confusing thing to configure 
if you have a lot of parameters, though.

> 
> A first implementation could ignore this, but they might be useful
> things for later.

Yup.

Wim

> 
> --
> Richard
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/gstreamer-devel

-- 
When I came back to Dublin I was courtmartialed in my absence and sentenced
to death in my absence, so I said they could shoot me in my absence.
		-- Brendan Behan