Quicktime Streaming Server is not often talked about as one of the big features of OS X Server, but if you need to stream audio or video content it’s hard to beat. We’re going to take a look at setting up QTSS, the options available for broadcasting your live or pre-recorded content, and how to deploy a highly scalable, redundant solution using a load balancer to ensure performance levels.Setting up QTSS is pretty straightforward.
General:
– Specify the media directory: by default this is /Library/QuickTimeStreaming/movies, feel free to move onto a shiny new Xserve RAID
– Specify the connections and throughput cap. It’s pretty easy to work out some figures here – you’ll know the bandwidth required to play the movie on one client and you’ll know the bandwidth of the network you’ll be using to stream it across…so if you’re planning on streaming a 300kbps movie across the web to 500 users, you’re gonna need ~18.3MB to do it. The speed of your network/Internet connection is almost always going to be the limiting factor, rather than your Xserve, and it’s an easy calculation to make. Of course, it’s easy to scale out if your needs dictate – more on this later. You want to plan to use no more than 75% of the available bandwidth for streaming. It’s worth noting that both these settings return the same error to the user if they’re exceeded (error 453).
Access:
-If you’ll be broadcasting from live sources, you need to enable incoming broadcasts and set a username and password that the boadcasting application will need to supply in order to send live feeds to your server.
-Enabling home directory streaming will allow your users to put content into their ~/Sites/Streaming folder. This content would then be available from rtsp://yourserverfqdn/~username/theirmoviename.mov, for example.
– You probably want to enable web-based administration to make your life easier. With this enabled and password protected you can mange your streaming server from your browser by pointing it to http://yourserverfqdn:1220
IP bindings
-If you have a multi-homed server or it’s doing other jobs such as web serving or mail (which, if you’ll be using QTSS heavily I wouldn’t recommend) you can specify which IP address you want it to use for streaming.
-If you can’t open up the ports for rtsp (554) or you are operating under some other restrictions, you can stream over port 80, but if you’re running a web server too, that makes things a little difficult 🙂
Relays:
So, maybe you have multiple office locations round the world…no? How about multiple offices without a huge link between them then? Say you want to stream company speeches to every employee, but you don’t want 30 users from a remote site using up their tiny T1 (1.5mb) line. QTSS lets you easily add remote servers that let you send only 1 stream out to other locations and let those servers handle the local demands across the LAN.
Did everything go to plan?
Start the service and check it’s working:
Open up QuickTime and hit cmd+u and type in:
rtsp://yourserverfqdn/sample_300kbit.mov
Apple provides a number of sample movies in the default media directory for testing purposes – you should see it playing. If it isn’t check that DNS resolves to the right IP address or tell QTSS to stream on all addresses.
So now you have a stream. Any hinted movie dropped into the QTSS media directory (/Library/QuickTimeStreaming/Movies by default) will be instantly available.
How do I know which bitrate and codec to use when exporting?
You don’t…well, not without some practice. The codec should largely be determined by your client base. Will they be using a cell phone, a computer or some other device? Will they be using the QuickTime player client or some other RTP/RTSP capable media player?
The bit rate is similarly narrowed down – do you know the audience? How will they be connecting? LAN/WAN/Broadband/Dial-up? Quicktime comes with a whole bunch useful presets for just such environments which you can see when you export a movie.
Once you’ve exported it, you’ll need to make it a hinted movie so that it can be streamed – that is, unless you’re using QTSS Publisher in which case it does that for you when it uploads the move to your server – very useful for energetically challenged (read: lazy) among us. Anyway, if you need to hint your movie, that’s done from the Export screen within Quicktime.
The best thing you can do here is try some different settings and see how the movie looks and plays. Is the picture clear enough? Is the stream reliable enough? I tend to err on the side of making sure the stream plays without constant rebuffering and sacrificing picture quality if need be. I’d rather have a solid, reliable stream with a slightly blurred picture than be sat around waiting every 30 seconds for the connection to pick up again.
Obviously a good option is to put the same movie on your server in different bitrates and let your viewers choose (from a webpage that offers links to the movies in simple terms such as ‘Broadband’ or ‘Dial-up’).
This brings us to another important issue – making sure your content fits your clients. If you are pre-encoding your content and putting finished clips onto your QTSS it’s easy enough to put differently encoded clips up.
However, if you’re planning on streaming live content, things get a little more challenging…
Quicktime Broadcaster
Using the free-with-every-Mac Quicktime Broadcaster is one option. It works really well, is easy to use and has a vast array of preset encoding options. It also allows Unicast and Multicast broadcasts. Multicast will work on the LAN only and saves bandwidth by only sending one stream out for all clients. Unicast will be necessary if you’re going out over the Internet.
So, there’s a lot going for QT Broadcaster, however it falls down on two fronts:
1. It can only take one video feed. So, if you want to stream a live event with 2 cameras, you would need two Macs each running Broadcaster – one for each camera.
2. It can only encode the stream in one format – so if you need to stream to LAN clients, WAN clients and cell phone users, you’d have to find some other way.
Some Other Way
There are 3rd party alternatives to Quicktime Broadcaster. They’re not free, but they do solve the limitations above. We’ll take a look at Wirecast, but there are others.
Wirecast will allow multiple video feeds in and let you choose multiple format types for the stream. So you’d be able to Multicast it out to LAN clients in hi-res H.264, send it out to Internet clients over DSL/Cable as well as a much reduced resolution 3G format for viewing on mobile devices. All from the same machine, all to the same QTSS. Wirecast simply sends an .sdp file to QTSS and your users hit that file. The .sdp file simply contains all the details of the stream – you can open it in a text editor if you’re curious.
Scaling it out
So, now you have multiple feeds and multiple streams, how do you maintain the streams and ensure all your clients aren’t stuck buffering? Well, there are two main ways: Relays and Load Balancing. Relays are built-in to the QTSS GUI and are great for geographical diversity. Setting up a QTSS on the West coast and one on the East coast will let your clients hit the server closest to them, for example.
Balancing the load
What about if you only have one location, or your server at each location is getting overloaded? That’s where load balancing comes in handy. Adding a hardware load balancer between your servers and your clients allows you to seamlessly scale your servers out on demand. During a quiet period your servers can be used for other purposes, but during periods of high activity you can add extra boxes into your cluster to handle the extra load. Be sure that the network/Internet connection has the bandwidth to support these extra servers or you won’t notice any difference.
Of course, load balancing also provides you with redundancy, so if one server dies the load balancer just directs your clients to one of the other servers. Setting up your load balancer should be failry straightforward. QTSS uses rtsp to stream, and that runs over port 554 on both TCP and UDP. Both Quicktime Broadcaster and Wirecast enable streaming over TCP, so setting up your load balancer to cluster Layer 4 TCP on port 554 should do the job.
Happy streaming!
Right now, there’s no easy way…actually I don’t even know of a difficult
way 🙂
However, hope is around the corner, as it’s listed as one of the features in Leopard
server…
~Ian