Darwin Streaming Server Relay Setting


Streaming relays and reflectors can be used to scale streaming infrastructure by distributing load between servers and making the most efficient use of network bandwidth. A streaming reflector “tunes in” on and incoming stream and relfects it to clients. The most common setup for a reflector is reflecting a live streams as (see the section on Live Webcasting). A streaming relay forwards an streams from a source to a destination server. One of the primary advantages of relays is segmentation of network traffic. Clients can tune in on relays that make most effective use of limited network resources instead of loading a single network segment with streaming traffic.

One of the easiest ways to distribute load between a group of servers is to reflect a multicast stream. This requires a multicast enabled network between the broadcaster/encoder and the streaming servers (see terminology below). The multicast .sdp file from the broadcaster/encoder simply needs to be placed on each streaming server. When clients open an rtsp stream to the multicast .sdp file from a server, they will receive a reflected unicast of the multicast stream. Using this method, a number of servers can reflect live webcasts. Combined with load balancing this technique can be used to distribute load for live streaming across a group of servers (a simple cgi for load balancing is presented in the Using CGI section of this site).


Network Bandwidth is the capacity of the network to move data. Bandwidth is measured in bits-per-second. Analog modems over telephone lines have a capacity of up to 56 kilobits per second. Because digital video files are large (read below), video streamed over 56 kilobit modems will be low quality. Higher quality video requires a broadband connection. Broadband generally refers to a network connection that can sustain at least 200 kilobits per second. The table below outlines the maximum bandwidth of dedicated Internet connections:

Connection Bandwidth (kbits/second)
T1 or DS-1 1,544,000
T2 or DS-2 6,000,300
T3 or DS-3 44,736,000
OC-3 155,000,000
T4 or DS-4 274,000,000
OC-12 600,000,000
OC-48 2,400,000,000
OC-192 10,000,000,000

Unicast packets on typical IP networks have a single source and destination. Most traffic on IP networks between clients and servers on today’s networks is unicast. Multicast packets have a single source and multiple destinations. Multicast packets can save network bandwidth when multiple clients need to view the same streaming media simultaneously. Instead of sending out individual unicast packets to each client, a single stream of multicast packets can be viewed by multiple clients.

Today’s commodity Internet does not support multicast (Internet 2 does). The capacity of a streaming server is frequently limited by the bandwidth of the network connection. The table below summarizes the maximum number of 500 kilobit Unicast streams supported by the dedicated Internet connections listed above:

Unicast Streams Minimum Connection
3 T1
12 T2 or DS-2
89 T3 or DS-3
310 OC-3
548 T4 or DS-4
1,200 OC-12
4,800 OC-48
20,000 OC-192

A single Xserve running QuickTime Streaming could saturate a T4/DS-4 connection. Faster connections would require additional servers set up as reflectors and relays to support more simultaneous Unicast streams.

A streaming relay server requests a stream from a broadcast or video on demand server and relays the stream to clients. Streaming relays can be used to relay live multicast streams as unicast streams or visa-versa. Relays can also be used to connect clients to streams on a local server, lowering streaming media traffic across IP Routers.

Note, content replication and content caching servers can also be used to reduce streaming network traffic. By replicating content files closer to clients, traffic across IP Routers can be minimized. Content caching servers intelligently replicate content based on client requests. This can be accomplished without relays or reflectors, which are more appropriate for live streams.

Sample Relay Deployment

The following diagram illustrates a network environment with streaming servers and relays. In this diagram:

  • Two primary servers are placed on the campus backbone (Internal Campus servers). One server is for production, the other is for testing/backup of the primary.
  • Each subnet has it’s own streaming server (subnet A shown). The primary servers are configured to relay live streams to the subnet servers. Clients on the subnet tune into the local subnet relay, reducing traffic across the subnet routers.
  • An external streaming server is placed in the network DMZ for publicly accessible content.
  • Each remote campus has a streaming server that replicates video on demand content from the primary campus servers, and function as relays to reduce traffic across the Internet router/firewalls.

Relaying from Server to Server

Relay Sources:

In the diagram above, the Primary Server will be configured to relay live/playlist streams to servers on each subnet and remote campus. Every relay has a source and a destination. Using Server Admin in Mac OS X Server, the Relay Source can be configured by creating a new Relay or in the web based administrative interface of QuickTime/Darwin Streaming Server:

Server Admin on Mac OS X Server/QuickTime Streaming Server

Web Administration on QuickTime/Darwin Streaming Server

The source for the relay can be:

  1. Request Incoming Stream:

    The stream will be requested from the source. If the source is a .sdp file on the local machine (, no username and password needs to be specified. If the source is another streaming server, you must specify the administrative username and password of that server.

  2. Unannounced UDP:

    The stream will be received on a specific IP address and port. The IP address of the live encoder and port numbers must be entered. Note: there is no GUI in the web administrative interface for this source type.

  3. Announced UDP:

    The server will start relaying when a new stream is announced on the source IP address. This source requires an encoder that supports “Automatic Unicast.”

It is very common for the local server ( to be the source of any of the relay source types above.

Relay Destinations:

Each relay can have one or more destinations. Incoming streams from the source will be sent to the destination. Each source can have one or more destinations. Using Server Admin in Mac OS X Server, the Destinations can be configured by adding them in the Destinations pane of a relay or in the web based administrative interface of QuickTime/Darwin Streaming Server:

Server Admin on Mac OS X Server/QuickTime Streaming Server

Web Administration on QuickTime/Darwin Streaming Server

The destination(s) for the relay can be:

  1. Announced UDP:

    The RTSP announce protocol will be used to automatically generate the .sdp file on the destination. This is a convenient way to automatically propagate .sdp files on the destination. Note: If your relay source and destination have firewall restrictions or network congestion, this technique is not recommended – this technique requires an active session between source and destination.

  2. Unannounced UDP:

    Packets will be sent to the specified IP address and port number. This method requires manual generation of the .sdp file on the destination. This technique does not require a session between the relays, and is a better choice when firewalls or network congestion may be factors. The source .sdp file can be used as a starting point for the manually generated .sdp file on the destination. The following lines must be edited in the .sdp file:

    • The line that begins with “c=IN IP4” should be edited with the destination server’s IP address.
    • The first line that begins with “m=” should use the port number specified in the destination relay.
    • The second line that begins with “m=” should use the port number + 2 specified in the destination relay.

Configuring a Unicast to Multicast Relay

It is possible to relay an incoming stream as a multicast stream. The following procedure outlines the steps required for this configuration:

  1. Set up a multicast relay on the streaming server. This relay will be configured with the IP address of your Broadcaster/Encoder as the “Source Hostname or IP Address:”, the <broadcastMountPoint> specified in step 2 below as the “Mount Point:”. Check “Wait for announced stream(s)” if you are using Automatic Unicast on the Broadcaster/Encoder. The “Hostname or IP Address:” for the destination must be a valid multicast address. Select “Relay via UDP” and set the base port to an even number (something in the 9000-9996 range works well). The multicast TTL is the number of router hops the multicast will work through. Set this for the topology of the network you are working on. The server must also be configured to accept an announced broadcast. This can now be done from QTSS Web Admin General Settings by clicking on “Change Movie Broadcast Password…”
    Note: If you are not using a Broadcaster/Encoder that supports RTSP Announce, you can set the source to, select “Request Incoming Stream” and set the mount point to the path to the Unicast sdp file. The unicast sdp file must be manually copied to the server from your encoding software or device. No username and password is necessary if you use the loopback address. The mount point is relative to whatever you specify as your Movies directory.
  2. Set up QT Broadcaster to send an “Automatic Unicast (Announce)” to the server. The “File:” you specify in broadcaster should include the “.sdp” extension – for example “webcast.sdp”. After you start the broadcast, test accessing it from the server by accessing the url rtsp://<serverIP>/<broadcastMountPoint> from QT Player. You will be tuning in on a Unicast relay of the stream.
    Note: If you are using a software/hardware encoder that does not support RTSP Announce, you must generate the Unicast sdp file and copy it to the Movies directory on the server.
  3. To tune in on the multicast relay, you have to make a copy and edit the .sdp file that is created by the announced broadcast and or copied manually as outlined above. After you complete step 2, you should see a file with the name you specified in your streaming server’s Movie directory. Copy this file (see step number 4 below for options on where you might want to place the copy). Edit the copy of the file. Look for the line beginning with “c=IN IP4” (at the top of the file). Change the IP address to the multicast IP address specified in step 1 above. Next look for the first line beginning with “m=”. Usually this is m=audio. Change the 0 to the base port you specified in 1 above (i.e. 9000). Look for the next line beginning with m=. Usually this is m=video. Change the 0 to the base port + 2 (i.e. 9002).
  4. The multicast sdp file can be accessed via ftp, http, from a file server, or e-mailed to clients. It cannot be accessed directly from the QTSS process. Save the file where it can be accessed via http or ftp, from a file server, or e-mail it to clients. I usually put it on a web server (see note below on mime types). If you place the file on a http or ftp server, you can access the multicast from QuickTime Player by using the url:




    If you put the multicast sdp file on a web server, or e-mail it to clients, they can just open up the sdp file with QuickTime Player. Note that sdp files are often associated with Real Player – you might have to drag and drop the file or use File-Open from QT Player.
    Alternatively you can open up the sdp file or URL with QT Player Pro, save the file as a self-contained .mov file, send this to clients, embed in a web page, etc.

Closing Notes:

If you keep the name of the broadcast sdp file the same, you can stop and start new broadcasts using the same name. However, you will have to do steps 3 and 4 above for each new broadcast if you change any broadcast parameters that are reflected in the .sdp file. The steps outlined in steps 3 and 4 could be automated by a cgi or other script.

If you place the multicast sdp file on a web server, the mime type needs to be configured properly on the web server:

mime type extension
application/sdp sdp

EasyDSS 安装使用手册 v1.0

EasyDSS安装使用手册 (v 1.1)



由于EasyDSS是Darwin Streaming Server的一个扩展,因此本说明文档将主要分两部分,第一部分讲是的Darwin Streaming Server的安装和配置;第二部分才是关于EasyDSS的安装、配置和使用。

一、Darwin Streaming Server安装

由于是安装在Windows上,我采用的是Darwin Streaming Server 5.5.5,若是您没有此版本,可到罗索工作室 – 流媒体开发论坛下载。

1. 下载

2. 安装
2.1 Perl 安装(可选)
由于Darwin Streaming Server安装Perl的支持,所以,若是您的电脑上原本没有安装Perl的话,在进行DSS安装前您还必须先安装Perl。但若是您的电脑上已经有安装Perl,则过跳过此环节。
ActivePerl的安装直接依据其安装向导,Next, Next, Next即可搞定。
2.2 DSS安装
a. 如果您的电脑上有安装一些所谓的“安全软件”,如:360,QQ电脑管家等等,请先将它们统统退出。
b. 若是在安装了Perl后仍无法安装DSS,请确保Perl的路径有被放在电脑的系统环境变量的路径下(环境变量的path项)。

a. 依据向导填入DSS管理员用户名.
b. 依据向导填入DSS管理员密码.


此时DSS已经被安装成功,并自动启动,其中DSS将被安装成Service(服务)模式,并随开机自动启动,您可以在控制面板 ? 管理工具 ? 服务那里对其可以管理。
安装的路径为: c:\Program Files\Darwin Streaming Server\

3. DSS管理

C:\> perlpath “C:\Program Files\Darwin Streaming Server\streamingadminserver.pl”


在此填入您刚才在安装阶段设定的用户名、密码,并Log In。




之后就是RTP over HTTP的设定,若是您的应用网络比较复杂的话,可能会用到(意思就是把这个Streaming on Port 80这个勾上);若是不复杂(如:单独的网络,或者是在特定的LAN或者类LAN网络的网络环境下)的话,可以不予理会。



2. 1 关于EasyDSS
EasyDSS是可以作为Darwin Streaming Server的一个扩展,同时由于EasyDSS支持transcode的功能,这样也使得您可以用一个连接地址来对N个媒体文件来进行拼接播放。

2.2 EasyDSS demo版下载

2.3 EasyDSS安装

3. 1. 服务器
3. 2. 管理客户端
3.2.1 启动与登录




3.2.2 按钮类功能介绍
? Refresh
? Playlist
? Reboot
? ReleaseNote
? About
? Contact

3.2.3 菜单功能介绍

? Start Playlist
? Stop Playlist
? Update Playlist
? Delete Playlist
? Maintain FileList

3.2.3 播放列表管理
其中前面提到的菜单项? Update Playlist,? Delete Playlist和按钮类的Playlist都会跳出类似下图的一个界面:

? Name
? Loop

3.2.4 媒体文件管理
要对媒体文件进行管理,您需要先保证服务器端已经存在至少一个播放列表,并在EzDSSMoc的主界面中选中的播放列表,然后右键,弹出菜单,并在菜单项的选择? Maintain FileList来进行管理。

a. 列表框
上面的列表框是指当前播放列表下存在的所有文件列表,若是您发现此中有任何不正确的值,您只要先退出本画面,然后在EzDSSMoc的主界面中点一下? Refresh这个按钮,即可得到当前服务器中最新的数据。
b. SDP
c. File

若您在使用EasyDSS中有碰到任何问题,或者有任何的意见或建议,您可以用以下方式跟我们取得联络:Mail: service@rg4.net



EasyDSS 视频点播系统 v2.1

EasyDSS 版本更新到v2.1.0.30


Easy DSS视频点播系统模块是流媒体服务平台解决方案的重要模块之一,可以独立运营,也可提供嵌入到各种对视频有要求的系统平台中(如:网络授课系统、视频点播系统、安防监控系统等等)。

整个模块基于C/S架构,采用业界最优秀的流媒体服务器之一的Darwin Streaming Server内核,除支持MPEG-1、MPEG-2、MPEG-4、H.264、VC-1等多种标准编码格式的众多主流媒体格式及avi、asf、 wmv、mp4、mov、rm、rmvb、flv、3GP等等全格式的文件Container容器外,还支持所有非媒体流格式(需订制),同时采用完整 Profile的转码技术,同一个视频源可同时转码成多种不同的Profile,以适应不同的客户端, 支持从1080P、720P等高清客户端(如:PC电脑、专门的高清流媒体播放终端),到QCIF、QQVGA的小型终端(如:手机、MCU等)。采用标 准RTP协议(包括RTP over UDP、RTP over TCP、RTP over HTTP),全面实现对多网卡、跨网段、跨路由、跨防火墙的支持。单服务器支持1000并发流(无缓冲)。


流媒体服务平台的一个关键技术,是其并发分发的性能,Easy DSS业界最优秀的流媒体服务器Darwin Streaming Server作为其分发的内核。使用 Easy DSS技术的单台服务器可以提供1000个并发流。

流媒体平台对比 EasyDSS
Microsoft MediaService REAL HelixServer
单服务器并发数 1000~1200 400~500 200~400

1、Media Service、Helix Server还包括所有用这两系统的SDK开发的流媒体系统。
2、采用EasyDSS的平台单机并发性能是Media Service、Helix Service以及采用两平台SDK进行二次开发系统的2~3倍。


通常许多流媒体服务器都会受限于媒体文件的格式,只能支持其中一种或者几种媒体文件,这样用户必将受限于媒体文件格式,当媒体文件源是不支持的格式 的时候,只能通过转换格式来实现,而这样对用户来说,无论在管理上,还是质量上都会带来许多的不便和不利。而EasyDSS平台模块可以支持全格式的媒体 文件,这无疑将对您的整个系统带来相当大的便利。




1. EasyDSS可以让您的大解析度的视频源,也可以转码成适合手机看的视频,且同时支持视频源解析度的流媒体分发和转码后的适合手机源的视频。

2. 由于一些终端(如:手机)或者播放器的限制,可能该终端只能支持特定编码格式的视频,那EasyDSS的转码技术将无缝的为您提供支持。

3. 您的视频源可能是来自其它应用平台的多种不同编码格式的视频,经过EasyDSS后,可以让所有接入到您的平台的视频都变成统一的、标准的格式,这样您只要使用一个单一的播放器,即可实现所有视频的支持。