Open Source Streaming Platform

1. Introduction

Scalability and platform independence are, together with quality, most important goals of building Internet streaming capacities and architecture. The 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 _Live_Encoding_-_Mbone_Tools

Mbone tools are available, either as source or binaries for various platforms: Solaris, SunOS4, Irix 6.2, Linux, FreeBSD, Windows. OS X.

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 in section: _Darwin_Streaming_Server

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 (No Firewall)

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/stream/128-u.ram

http://www.location1.org/stream/56-u.ram

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.)

[1] http://www-mice.cs.ucl.ac.uk/multimedia/software

[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

Server_Side
_Darwin_Streaming_Server
_Icecast_Streaming_Server
_RTPTOOLS

Content_Production_Side
_Mbone_-_OpenMash_Tools
_Autostart_Script_VIC
_Live_Encoding_-_Mbone_Tools
_MPEG_4_IP
_MP3_Live_Streaming
_SMIL

Dynamic_Relaying_of_RTSP_Servers
_Dynamic_Relay_-_Flow
_Dynamic_Relay_-_Code
_Dynamic_Relay_&_MP3_alias

OSSA_Streaming_Protocol
_SDP_Exchange_&_Public_Keys
_Stream_Scanner

Logfile_Analyzer