On Tue, Jul 23, 2002 at 10:01:28AM -0700, Ned Konz wrote:
> On Tuesday 23 July 2002 09:36 am, Kevin Fisher wrote:
> > Thanks Ned, I'll look into this.
> >
> > Basically I'm just playing around, but the idea of using multicast
> > for audio/video broadcasting is intreguing.  It's the way it Should
> > Be (TM) done, although unicast seems to rule the day right now.
> 
> One of the advantages of Spread is that you can specify various 
> different service classes w/r/t ordering and delivery guarantees.
> 
> For instance, for typical audio or video streaming, you'd use the FIFO 
> service type, which guarantees that all messages will be received by 
> group members, and that the messages will be ordered (among messages 
> from that sender).

Interesting...I'm attempting to get an RTP/RTSP-based mp3 jukebox/server
up and running.  Does Spread use RTP/RTSP over multicast, or something
else?

> 
> I envision a system where clients can "tap into" an ongoing stream; 
> there are issues with re-synchronizing compression, etc., but I've 
> noticed that mp3 and mpeg video usually seems to re-synch fairly soon 
> (from a human perspective).
> 
> Think of this:
> 
> program A receives a request from program B (via a separate request 
> group subscription) for a video stream. It then begins sending this 
> stream via FIFO messages to another group (either a pre-defined one, 
> or a specific one requested).
> 
> Now, another program C comes along, and queries the current status 
> ("available channels") by sending a different request for video 
> stream status to another group. It gets a response from all currently 
> sending video sources, telling it what groups are currently being 
> sent video.
> 
> It sees that stream coming from A, subscribes to the group, and 
> immediately starts receiving messages. These messages are chunks of 
> video; perhaps they could be marked every so often as a 
> re-synchronizable point in the stream.
> 
> Note that A does not have to know anything about any of its 
> recipients; they can come and go without affecting A (though it can 
> get membership messages so that it can, if it wishes, stop sending 
> when there are no more listeners).

Have you seen VideoLAN at all?  (www.videolan.org)
I don't know if it uses Spread, but it seems to do some of what you
describe.  One of these days I'd like to get it working...I only had
a small amount of success with it the last time I tried, but I didn't
really spend enough time playing with it.