[gst-devel] Autoplugging with multiple sinks

[Wim Taymans]

Richard Boulton wrote:
> 
> On Wed, Sep 13, 2000 at 12:19:48PM -0400, Myers W. Carpenter wrote:
> >       Here's one idea: you don't have gst_type_get_sink_to_src (or you do
> > have it but not as implemented), but a gst_type_get_point_to_point,
> > where you can attempt to connect two points.  As it comes up with a new
> > path it checks for other connections from the first point and sees if it
> > can also us those.
> >
> >       You could still have a gst_type_get_sink_to_src but it's only for
> > simple cases.
> 
> Yes, I think that's the right kind of way to go.  A full scheme might be:
> 
>   Users build a pipeline out of various elements, and also specify
>   connections between them.  These connections are allowed to be between
>   incompatible pad types (the connections get modified later to be valid).
> 
>   The user then calls an autoplug function on the pipeline:
> 
>     As a special case, if there is one and only one sink node, or one and
>     only one source node, the system will now automatically put a link from
>     the sink to the sources, or the sinks to the source.
> 
>     We now have a network describing what the user wants to happen, but
>     with some connections needing to have intermediate nodes added to make
>     them valid.

Hmm..

You also have to consider the case where an element does not yet have all of
the needed pads because they will be created at runtime. The mpeg demuxer
for example has no src pads until the stream is playing and audio and video
streams are detected.

The current autoplugging algorithms operate on the mime types of the *possible*
pads that can be created in the element. I don't see how we can link those
without having something like

gst_pad_connect_mime(element1, element2, mime)

This would tell the autoplugger that pads created in element1 of a given
mime type should be connected to element2.

This would be a quite difficult API because the app programmer has to loop
over the mime types that can be sourced/sinked in the element.

or something fuzzy like:

 gst_pad_connect_fuzzy(element1, element2)

because you would need to connect a disksrc to a videosink and an audiosink.

Still I'm not convinced that it is needed to explicitly connect elements.
I think it must be possible to only use gst_pipeline_add_src/sink(). the
intermediate elements would be src and sink of two different pipelines.

A pipeline would remain quite simple: it connects its src elements to the
sink elements. consider an mpeg player that uses one specific decoder:


   pipeline1          pipeline2
  ------------     --------------
  !          !     !            !
disksrc     mpeg_play         videosink
            audiosink

(both pipelines have elements added to it as a src and a sink)

both pipeline1 and pipeline2 would be trivial to autoconnect. The app
programmer would place any intermediate elements as source and sink
in different pipelines making the connecting between them implicit.

We could even force to only have one src element in a pipeline.

> 
>     The system then loops over each connection in the network, checking
>     whether the types are compatible.  If not, it calculates a valid path
>     from one node to the next (using a gst_type_get_point_to_point()
>     function), and replaces the connection with the path calculated.
> 
>     As an improvement, probably to be implemented once the above is
>     working, the system could try and calculate paths from each node to
>     the next nodes which share as much of the pathway as possible.  A naive
>     algorithm would be to calculate all the paths possible and pick the
>     "cheapest" one.
> 
> Calling the autoplug function could even be made implicit - if the network
> has no invalid connections, nothing will happen.

I prefer the implicit case. After that maybe the fuzzy case.
> 
> What do you think?  Should I try and code it? ;-)

Sure, go ahead.

Wim

> (Not that I think I'd be able to get it going in a short period of time,
> but...)
> 
> --
> Richard
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/gstreamer-devel

-- 
You recoil from the crude; you tend naturally toward the exquisite.