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

May 2013: Biggest exam in a decade


In the last weekend, I attended one biggest exam in a decade, the post-graduate entrance exam of USTC.

To assure that I can pass the exam, I attended a training course earlier this month, and put myself busy preparing the exams for weeks.

Everything went great.  For both the two phases of the exam (First one was pure a exam, including English, Mathematics, and Specialty course; Then was an interview held by Prefessors from USTC).

And now I believe that I can pass, only need to wait the result to be revealed at July.


I, per myself, am a modest man, and I’m a man values honesty as a great virtue.

But it seems that I’m act too modest in some specific time. I just joined a new company last month, now surrounding by lots of unfamiliar faces. My previous title in my previous employer, UniSVR, was R&D manager of China mainland, in charge of both Shanghai & Beijing offices’ R&D teams, but that was once upon a time. Now I’m nobody but an ordinary SDE, and people here don’t know me, yet. There once I was given a chance to introduce myself. I said nothing about the titles and the track records I once retrieved or archived, because I didn’t think this could be any help. Now I start to think it was a big mistake, just like another big mistake I’v made earlier in a conference interview thru WebEx.

In that interview, I must say, for the record, I completely meet with the requirements of that position.

However, I failed to pass the interview. After reviewed the interview myself, there were two key points affected and led to the failure. Video codec & Streaming QoS, which I’m both experienced and capable of. But when I was asked about these skills or questions, I was too modest, I only said that I didn’t get myself involved into those skills because:

  • Video codec

In fact, earlier when I was working on the WinCE/Windows Mobile client for 3GVAU project and UMA project, I once researched into x264(encoder) and ffmpeg(decoder) for over a year (not full time, because there are other proejct to work out), but only for porting purpose and bit rate control purpose. I’m not saying here that I’m an expert in H.264 codec algorithm topic. At least I knew and familiar with it, although it was a thing of 5 or 6 years ago.  When I was asked about video codec, I said nothing about these experiences, instead, I said I had not worked on the detail codec algorithms, what I master at are how to use the codecs, and parseing some header informations. For example, when we streaming videos, we need to parse H.264 SPS/PPS, MPEG-4 VOL/VOP info.

And I put an end of this question with a saying, There are things you didn’t get yourself involved into, but it doesn’t mean you are not capable of it. And more, I told them that I can do the video codec algorithm work if it is necessary.

  • Streaming QoS

I was once researching on this topic for monthes to improve the streaming quality of UniArgus series of products, including but not limits to standard protocol like RTCP, private protocol of UniArgus. However these implementations did not work as so good as what we wished it to be,  when the networking bandwith is really suck, especially when you are using a smartphone to view a live video through 3G connections.

Besides, UniArgus series products are designed to stream limited sources of stream to hundreds or thousands of different clients, including clients connecting by LAN, by WIFI, by WAN, or by 3G. That means its impossible for the server to encode/transcode too much different streams with different profiles. For example, one stream in server, two clients. One client is in LAN, another is connecting thru 3G(which sucks).  If server can only produce a profile of stream, then we can  not take take into consideration of both of the clients’ QoS requirements like frame rate, bitrate adjustment. What we can do is only if one client encountered package loss issue, we can re-send the lossed packages or skip some usless video packages(like drop all the rest B/P frames untill next I frame).

However I never mentioned all these staffs, maybe it’s because the I was nervous, or just don’t want to say things I not 100% confident in its outcome if I was about to do this in the next minute…

A conclusion for this:

I failed that interview, not because I’m not qualified, but only because I did not show them what I capable of in the short time conversation, or what I expressed/showed to peoples was some things can not completely stand for my expierencs or backgrounds.

My one biggest problem is just that. I’m a modest man, I never like to talk big. Years of experenes in Project Schedule planning made me even more cautious in talking about some specific staffs. And in the past over ten years, I was always be the man who sit on the master side of interviews, I’d never been interviewed, so I do lack of skills in presenting myself.

Now, here I am, in Kedacom. Wish I can do better from now on.


My father resigned from his job in the beginning of 2013. And earlier in the month, May 10, he left Shanghai for his new start in Hangzhou. Wish he perfect in his new position.

Catherine’s kindergarten education is about to over, and she recieved the letter of admission from the 1st junior school of DAHUA, after Lucy’s efforts through her boss.

Little uncle went to Hangzhou to have a surgical operation on his leg. It was a really big operation, after it was done, no one can stand the extremely pain, so Mom went Hangzhou to look after her little brother for two days. Now he’s already checked out, and back to Dongyang for later recuperation.  Wish he healthy, and will not be lame in his leg any more.