From: "Drazen Pantic" <drazen.pantic@xxxxxxx>
Date: Mon, 11 Jun 2001 22:49:54 -0400
Subject: [mediafest] 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





To unsubscribe from this group, send an email to:
mediafest-unsubscribe@xxxxxxxxxxx

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 




 |   |   |   |   |   |   |   |   |   |   |   |   |   |
(a) (c) (o) (u) (s) (t) (i) (c) ( ) (s) (p) (a) (c) (e)
 |   |   |   |   |   |   |   |   |   |   |   |   |   |
information&comunication channel | for net.broadcasters
http://xchange.re-lab.net  (Xchange)  net.audio network
xchange search/webarchive: http://xchange.re-lab.net/a/