Darwin Streaming Server Relay Setting

Introduction

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

Terminology

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 (127.0.0.1), 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 (127.0.0.1) 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 127.0.0.1, 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:

    http://<webServerIP>/<pathAndFileNameOfsdpFile>

    or

    ftp://<ftpServerIP>/<pathAndFileNameOfsdpFile>

    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.User.Mannual

前言

由于EasyDSS是Darwin Streaming Server的一个扩展,因此本说明文档将主要分两部分,第一部分讲是的Darwin Streaming Server的安装和配置;第二部分才是关于EasyDSS的安装、配置和使用。
若您对本文档及本文档中所作的描述有任何的看法、意见或建议,希望您能不吝赐教。在此我表示万分感谢。

一、Darwin Streaming Server安装

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

1. 下载
下载地址:http://rg4.net/p/easydss/DarwinStreamingSrvr5.5.5-Windows.exe

2. 安装
2.1 Perl 安装(可选)
由于Darwin Streaming Server安装Perl的支持,所以,若是您的电脑上原本没有安装Perl的话,在进行DSS安装前您还必须先安装Perl。但若是您的电脑上已经有安装Perl,则过跳过此环节。
Perl的安装文件您可以到其官方网站下载,也可以直接从罗索工作室下载。罗索工作室下载地址:
http://rg4.net/p/easydss/ActivePerl-5.10.0.1004-MSWin32-x86-287188.msi
ActivePerl的安装直接依据其安装向导,Next, Next, Next即可搞定。
2.2 DSS安装
注意事项:
a. 如果您的电脑上有安装一些所谓的“安全软件”,如:360,QQ电脑管家等等,请先将它们统统退出。
b. 若是在安装了Perl后仍无法安装DSS,请确保Perl的路径有被放在电脑的系统环境变量的路径下(环境变量的path项)。

DSS在解压后,您可以直接到解压目录(默认为C:\DarwinStreamingSrvr5.5.5),点击其中的Install.bat,开始安装。
其实,这个安装很简单,一般来说,只要你预先把那些“安全软件”退出的话,那你需要做的只有两件事情:
a. 依据向导填入DSS管理员用户名.
b. 依据向导填入DSS管理员密码.

回车,跳出画面如下:

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

3. DSS管理
DSS除了DarwinStreamingServer.exe外,还提供了一个基于B/S架构的管理服务器,该服务器可通过以下方式在命令行里启动:

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

在启动管理服务器后,您可以透过浏览器来进行访问,地址:http://localhost:1220
打开后出现画面如下:

在此填入您刚才在安装阶段设定的用户名、密码,并Log In。
若是您有一天忘了自己设定的用户名、密码,没关系,重新安装一遍就可以了。

登录进去以后,会要求你设定MP3广播的密码,你可以不用理会直接Next,也可以随便给他设一个密码,该画面如下:

再下去就是设置管理服务器的安全模式,默认要求启用SSL,若是您没有SSL证书,也可完全不予理会,直接Next。

再下一步就是设定媒体文件的存放路径,根据您自己的需求来设定此目录。

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

点击Finish,搞定!

若要更多详情,可参考安装目录下,由官方提供的README,该文件位于解开目录下,如:C:\DarwinStreamingSrvr5.5.5\readme.rtf。

二、关于EasyDSS
2. 1 关于EasyDSS
EasyDSS是可以作为Darwin Streaming Server的一个扩展,同时由于EasyDSS支持transcode的功能,这样也使得您可以用一个连接地址来对N个媒体文件来进行拼接播放。
同时可指定transcode的各项参数,使一个本来用于在电脑播放的D1的文件transcode成比较小的适合手机播放视频,以实现各种不同的应用需求。

2.2 EasyDSS demo版下载
EasyDSS的demo版您可以从以下地址下载:
完整服务器安装包:http://rg4.net/p/easydss/EasyDSS.rar
单独的管理客户端安装包:http://rg4.net/p/easydss/EasyDSSMoc.rar

注:其中完整服务器安装包中已经包括管理客户端,因此若是您已经安装了完整服务器,就不需要再安装管理客户端。
2.3 EasyDSS安装
EasyDSS的安装非常简单,就是解压缩EasyDSS.rar,然后执行setup.exe,然后下一步,下一步,下一步,搞定。

三、EasyDSS使用
3. 1. 服务器
EasyDSS服务器程序包括两个exe,一个是EasyDSS.exe,另一个则是RsSvrDog.exe。正常您只需要从开始菜单或者快捷方式启动即可(成功安装EasyDSS后,会在桌面生成一个快捷方式:EasyDSS,点击执行)。
3. 2. 管理客户端
EasyDSS的管理客户端的程序员是EzDSSMoc.exe。
3.2.1 启动与登录
双击打开该程序

其中EasyDSS默认的用户名、密码为:
用户名:root
密码:rosoo.net

若您是从远程登录到EasyDSS服务器进行管理,请将此中的IP地址(127.0.0.1)改成您实际的服务器的IP地址。

点击OK登录进去:

下面详细介绍此画面中的功能:
3.2.2 按钮类功能介绍
? Refresh
Refresh按钮是用于刷新服务器中当前的播放列表,及每个播放列表中包含的文件等信息。
? Playlist
点击Playlist按钮可实时新增一个播放列表项。
注:单单新增播放列表并不能看视频。在新增了播放列表后,你还必须为此播放列表新增媒体文件,这样服务器才会开始工作。
? Reboot
强制重启服务器端。慎用!!!
? ReleaseNote
点击此按钮将会连接到EasyDSS的官方网站,您可以在那儿看到EasyDSS当前最新的信息,若您有任何问题也都可以在那儿进行提问。
? About
关于EzDSSMoc。
? Contact
通过mail方式与我们联络。

3.2.3 菜单功能介绍
若您的服务器中已经有一个或者若干个播放列表,您可以在此先选中一个您要进行操作的播放列表,然后按右键,系统会跳出一个菜单,如下图:

以下将逐项的对此菜单中的各个项目进行介绍:
? Start Playlist
强制服务器开始此播放列表,但若是此播放列表当前已经在播放中,系统不会重头开始,而是继续当前的运行状态。
? Stop Playlist
强制停止当前播放列表。
? Update Playlist
更新播放列表。
? Delete Playlist
删除播放列表,同时若该列表当前在运行中,也会强制令其停止。
? Maintain FileList
管理当前选中的播放列表下的文件列表。

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

这里边有几个栏位:
? SDP
SDP栏位是指服务器生成的RTSP的SDP名字。此栏位一旦输入后就不再允许更改。为避免混淆,在此特别举一个例子,以便您能更深刻的了解此栏位的意义。
假设您的服务器IP为192.168.1.100,然后,您为您的服务器新增了一个播放列表,其SDP栏位的值为abcd,同时也为此播放列表添加了若干个媒体文件,这样此播放列表就可以正式工作了。而若有客户端需要看此播放列表的视频,他/她就需要用以下这种方式来进行访问:
rtsp://192.168.1.100/abcd.sdp
? Name
此栏位仅仅是一个名称,用于自行记录,在系统运行中无实际意义。
? Loop
若是此栏位被选中,则代表当前播放列表中的媒体文件将会不断的、按顺序的、重复的进行播放;但若是未被选中,则在播放完当前播放列表下的所有媒体文件后,自动停止工作。

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

在这个画面中,
a. 列表框
上面的列表框是指当前播放列表下存在的所有文件列表,若是您发现此中有任何不正确的值,您只要先退出本画面,然后在EzDSSMoc的主界面中点一下? Refresh这个按钮,即可得到当前服务器中最新的数据。
b. SDP
SDP是指您选中的播放列表的SDP名称。此栏位是不允许更改的。
c. File
File是指您要新增的媒体文件全路径。
这里您必须要注意的是,此中的文件是指在服务器上的文件,并且路径必须是全路径。

四、如何与我们取得联络
若您在使用EasyDSS中有碰到任何问题,或者有任何的意见或建议,您可以用以下方式跟我们取得联络:Mail: service@rg4.net
或者您也可以直接到我们的网站进行留言:http://rg4.net/archives/13.html

我们会尽快与您联络。

感谢您的关注和使用。

EasyDSS 视频点播系统 v2.1

EasyDSS 版本更新到v2.1.0.30
EasyDSS

系统概述

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并发流(无缓冲)。

EasyDSS内核

流媒体服务平台的一个关键技术,是其并发分发的性能,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平台模块可以支持全格式的媒体 文件,这无疑将对您的整个系统带来相当大的便利。

转码技术

一般情况下,一个片源文件只能分发出一种格式的视频:如果这个格式是高清的,那手机就不能看;但是如果你提供的视频源是适合手机看的,那即使客户使用的支持大解析度的PC,效果也肯定只能到达视频源的效果。

而EasyDSS提供了一整套的转码技术,为您的各种困惑提供帮助:

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

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

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

相关下载: