Open Streaming Architecture

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

---