[gst-devel] Re: Distributed pipelines and modular synthesis ramble

[Owen Fraser-Green]

Hi,

> Yeah, we haven't played much with the network yet, since we've been
> focusing on the core and some of the plugins.  There is a httpsrc, as well
> as a shoutcast sender (untested), but we do need someone to give some more
> network plugins (like a shoutcast receiver with some clue) a try.

I've been thinking a little about some of the issues in distributing a 
gstreamer network and I believe there are two ways of doing this. First 
imagine a pipeling of four elements:

    P===P===P===P

now:

1) P===P===S . . . S===P===P

The pipeline has been split in two and connected by an extra source-sink 
pair which handles the connection over a network. I believe this would be 
the type of topology which would be implemented by httpsrc and shortcast. I 
guess you could call this a bridge.

2) P===P= . . . =P===P

This time the pipeline has also been split in two but this time at a lower 
level. The middle arc is handled by gstreamer (or something even lower-
level) and the network connection is spanned without any additional nodes.

Now 1) is much easier to implement than 2) because it just needs someone to 
write the bridge source-sink pair and instant distribution. However I see a 
big problem here. Consider this situation (sorry for all the ASCII art!):

   P1===S1  . . S3=
                    ==P3
   P2===S2  . . S4=/

This time the network is spread accross three diferent machines. My concern 
is that since the S's don't really know anything about the P's there will 
be a serious synchronisation problem. Supposing P1 and P2 are two audio 
sources which are to be mixed by P3. I can't see how S3 and S4 will be able 
to synchronise their inputs so that the P1 and P2 signals are aligned 
properly in the mix. The same would apply to the render farm example.

Also, I feel that neither http nor shortcast would make a suitable 
transport mechanism for distributing gstreamer pipelines because they are 
too unreliable and won't really facilitate passing synchronization 
information.

I think the 2nd approach above is better and offers more flexibility as it 
doesn't require adding extra elements in the pipeline, however, I think it 
will be much harder to implement. CORBA/bonobo would provide a suitable 
means of integrating the the distinct sections of pipeline but I doubt it 
would be very suitable for the actual data stream as it slaps on quite a 
big payload. I'm wondering if a specialised streaming protocol over RTP 
would be more suitable.

Another thing I've been wondering about is whether there should be another 
meta data type for application control data such as MIDI and the states of 
switches and sliders. This could, for example, carry the positions of the 
sliders on a mixer to the gain pads of the mixing elements.

> Meds are good, but yes, this stuff has been on our minds for a long time.
> If you're interested in helping out, we could use all the help we can get
> to bring GStreamer into these areas.
 
I'm getting really interested in this project and will gladly lend all the 
help I can.

Regards,
Owen

---------------------------------------------------------------------------
     Owen  Fraser-Green             "Hard work never killed anyone,
     owen at discobabe.net              but why give it a chance?"
---------------------------------------------------------------------------