[ torbica @ 14.06.2001. 01:26 ] @
Open Streaming Architecture 1. Introduction Scalability and platform independence are, together with quality, most important goals of building Internet streaming capacities and architecture. The usual goal is to establish procedure of encoding / compressing of the audio & video source for streaming and server distribution that could be delivered across various players, operating systems and use available bandwidth of any possible connection quality. Open Source multicast video-conferencing tools (Mbone, [1]) coupled with open source and open architecture Darwin Streaming Server (DSS) have shown incredible scalability and flexibility, and found to be able to produce open platform streams, that could be played using both QuickTime and Real media players, as well as by native Mbone programs themselves. 2. Procedure 2.1. Encoding Mbone tools (vic/rat), installed on a computer with video capture and sound card connected to video and audio source, are able to unicast video/audio streams to DSS, using open source codecs (H.261, H.263 for video and muLaw, DV, GSM for audio). The procedure is described in [2] and links therein. Mbone tools are available, either as source or binaries for various platforms: Solaris, SunOS4, Irix 6.2, Linux, FreeBSD, Windows. Macintosh uses can use Coolstream, [3]. 2.2. Servers and Relaying Darwin streaming server (DSS), is available as open source / free software for all major operating systems: Mac OS X, FreeBSD, Linux, Solaris and Windows NT/2000, [4]. DSS is able to receive the streams from encoding tools and to relay them either to other DSS servers or to itself, for unicast or multicast delivery. Explanation of how to set up a relay is available on [5]. In the specific approach, DSS receives: - two (one for audio and one for video) unicast streams from Mbone tools (VIC for video and RAT for audio); and sends: - two (one for audio and one for video) unicast relay streams to unicast entry points (UDP ports) onto itself; - two (again one for audio and one for video) multicast relay streams multicast entry points (multicast IP addresses and corresponding UDP ports) onto itself. 2.3. Players and Delivery Real Time Streaming Protocol (RTSP) streams are described by Session Descriptor Protocol (SDP) files. Each of those streams corresponds to a SDP file that resides in the home directory of the streaming server, and specifies entry points (ports) and encoding protocols for audio and video streams. Syntax and parameters of SDP files are explained in Internet Engineering Task Force Request for Comments 2327, [6]. 2.3.1. QuickTime Player SDP file in the DSS home directory points to the unicast relays on DSS server, with appropriate description of audio/video standards, as described in RFC2327. This stream could be played using QuickTime player via address of the type: rtsp://<name_of_the_server>:<DSS_port>/<name_of_SDP_file> Working examples: rtsp://location1.org:7071/rage128 rtsp://location1.org:7071/rage56 Prerequisites: QuickTIme player, Internet connection without a firewall. 2.3.2. Real Player / Multicast Connection Computer that is connected to the same multicast network with DSS can directly access stream using Real player through scalable multicast protocol, [9]. Web server delivers file with appropriate MIME type for Real player (.RAM or .RPM), pointing towards SDP file that describes multicast stream. Such a SDP file specifies multicast entry points and stream descriptors for the stream. Once delivered via HTTP to Real player, direct multicast communication with DSS is established and content is delivered. Working examples: http://location1.org/stream/128.ram http://location1.org/stream/56.ram Prerequisites: Real Media player, multicast connectivity to DSS server (in this example on location1.org). 2.3.3. Real Player / Unicast Connection Computers that are not on the same multicast network, could not directly receive scalable multicast streams, what is the most common situation... Client and computer carrying DSS have to be connected to the same multicast network. This could be done establishing multicast tunnel from server to the client machine. More information on mulicast tunnels is available in [7] or [8]. We are using program RTPTRANS, from [7], to map multicast entry points from the DSS server to the corresponding points on the client machine, and then proceed as in 2.3.2. sending SDP file to the Real player through HTTP, as in the following scheme: DSS (multicast ports) HTTP | | v v (RTPTRANS) (SDP file) | | v v client (UDP ports) <--> Real player Working examples: http://www.location1.org/cgi-bin/rm.128 http://www.location1.org/cgi-bin/rm.56 Prerequisites: Real player, Internet connection to the same multicast network as the serving DSS, with Real H.261 and scalable multicast plug-ins installed. (Important note: Examples would not work if the client machine is behind the firewall! If so, direct access to UDP ports 6900-7000 should be enabled.) 2.3.4. Mbone Tools (vic/rat) Once multicast tunnel has been established between DSS and the client machine, audio and video streams could be received directly using VIC and RAT, via commands vic <muticast_address>/<multicast_port> (video) rat <muticast_address>/<multicast_port> (audio). 3. Open (Source) Streaming Alliance Described procedure, enables free and open source tools for encoding and serving QuickTime, Real Media and Mbone streams, producing streaming content in one run, through just one encoding process, what obviously saves time, equipment and resources in any way. The same architecture has already been employed in building Open Streaming Alliance (OSA), with the basic idea and existing functionality of local delivery of streams. Servers exchange relays, while individual users visit the closest server and receive the least bandwidth congested streams. It is clear that the greater the density of servers is worldwide, the better and more local the delivery is. At the moment four centers: in NY. Amsterdam, Pal Alto and Adelaide have established mutual streaming relaying links. Any other candidates? 4. Next Step: P2P Service for Streaming It is quite technically and conceptually feasible to establish service that will offer streaming on P2P basis, so that any individual and/or organization can tap into the OSA, and using free encoding software send one stream that is then to be redistributed and multiplicated within the network. [1] http://www-mice.cs.ucl.ac.uk/multimedia/software [2] http://homepages.nyu.edu/~dp51/qt/streaming.html [3] http://www.evological.com/coolstream.html [4] http://www.opensource.apple.com/projects/streaming [5] http://www.apple.com/quicktime/authoring/qtss/pgs/qt08a.htm [6] http://www.ietf.org/rfc/rfc2327.txt [7] http://www.cs.columbia.edu/IRT/software/rtptools [8] http://www.cdt.luth.se/~peppar/progs/mTunnel [9] http://www.ietf.org/rfc/rfc1949.txt |