Mobile Webcastingby Jon Udell
When I began the investigation I'm documenting in this series of columns, one of my aims was to learn how to work with live audio or video streams. Since I'm particularly interested in solutions that anyone can use, I started with a pair of free products from Apple: Darwin Streaming Server (DSS) and QuickTime Broadcaster. Using this combination, I was able to take an audio/video stream from the iSight camera on my TiBook, bounce it off DSS, and receive it in the QuickTime player. When I moved DSS to an internet-visible server, my TiBook became a mobile webcam. From any WiFi-connected location, even behind a NAT or firewall, I could broadcast live to the world. My upstream bandwidth limits this capability to a handful of streams, but it works. Sure, webcams have been around forever, but if you've never set one up for yourself--and I hadn't--you'll still be amazed that it's possible to create global telepresence in this way. The mobile aspect adds a new and, to be honest, slightly scary dimension. Pointed inward, the iSight camera I use while sitting in Starbucks is a videochat tool. Pointed outward, it can produce live television.
From DSS, I moved on to the Helix DNA Server, the open source version of RealNetworks' commercial media server. Helix handles QuickTime streams in the same way that DSS does and also--naturally--supports Real streams, so it multiplied my mobile webcasting options. I could stream from the iSight on my Mac or from my Logitech camera attached to a Windows or Linux laptop.
Although using Helix in both of these ways is fairly easy, it did take me a while to get the hang of it. Here's an overview of the process.
In order to download the server (currently at version 10.1), you'll need to first register with Helix Community. Then visit the download page and choose your server. Binary installers are available for non-commercial use on a number of platforms; I had a Windows box available, so I picked the Win32 flavor.
For QuickTime streaming, you'll also need to install QuickTime Broadcaster. In fact, even if you never do any live streaming, you'll still want to have this tool around--it's also useful for recording from the iSight to disk.
To get started, hook up your camera and launch QT Broadcaster. The settings I've used successfully are as follows:
Audio: Source: iSight. Compressor: QualComm PureVoice, 22kHz.
Video: Source: iSight. Compressor: Sorenson Video 3, width 240, height 180, 10 frames per second, data rate limited to 200 kbits/sec.
Network: Transmission: manual unicast. Address: IP address of your server. Audio port: 5432 (the default). Video port: 5434 (the default).
Use File->Export->SDP to save these settings to an SDP (session description protocol) file--for example, broadcast.sdp. Then copy the file to your Helix server, placing it in the subdirectory HELIX_HOME/Content/rtpencodersdp/.
In a world of open pipes, that would be pretty much it. But since my server is firewalled, I had to make some adjustments. On the firewall, I opened TCP ports 80 (HTTP) and 554 (RTSP), plus the UDP ports 5432 and 5434, which are the audio and video components of the broadcast. Then, in the SDP file, I changed the public IP address of the server to its private unregistered address.
With these changes in effect, I clicked the Broadcast button in QuickTime Broadcaster, walked over to another machine, and fired up QuickTime. In the default Helix configuration, the mountpoint that corresponds to HELIX_HOME/Content/rtpencodersdp/ is /rtpencoder. So if your SDP file is broadcast.sdp, the URL you need in QuickTime is rtsp://HELIX_SERVER_PUBLIC_ADDRESS/rtpencoder/broadcast.sdp. In a couple of seconds, if all goes well, you'll be watching and hearing your live stream.
So much for Mac users, with our snobby silver gear. Now what about Windows or Linux users with our commmodity laptops and cameras? In that case, you'll need a different free encoder: Helix DNA Producer. I installed the program on a Windows laptop with a USB-attached Logitech QuickCam and typed the following command:
producer -ad 256 -vc 0 -ac 0 -sp PASSWORD@HELIX_SERVER:30001/live.rm
Here's the breakdown:
- -ad 256 is shorthand for an "audience definition" of 256kbits/sec
- -vc 0 specifies the video device
- -ac 0 specifies the audio device device
- PASSWORD is defined in the server's config file
- HELIX_SERVER is the fully-qualified domain name of the server
- 30001 is the port on which to receive the encoded stream
- live.rm is the name of the stream
In the server's home directory, the default config file contains this XML fragment:
<List Name="BroadcastReceiver"> <List Name="Receivers"> <!-- Uncomment the "Anyone" Receiver to begin listening for encoder feeds on port 30001, adjust settings to suite. --> <!-- DELETE THIS LINE ... <List Name="Anyone"> <Var FECLevel="20"/> <Var UseTCPForPullBackchannel="0"/> <Var OriginSpec="0.0.0.0/0"/> <Var AcquisitionDataInterval="30"/> <List Name="Security"> <Var Password="PASSWORD"/> <Var Type="Basic"/> </List> <Var Protocol="udp/unicast"/> <Var PullSplitEnabled="0"/> <Var PortRange="30001-30020"/> <Var ResendSupported="0"/> </List> ...AND THIS LINE TO UNCOMMENT THE "Anoyne" RECEIVER--> </List>
After deleting the two indicated lines and opening up some firewall ports in the indicated range, the server's Java-based monitor showed an encoder connection from the Windows client. To view the stream, I opened this URL in an instance of RealPlayer on another machine:
And once again, voila! I'd transformed my laptop into a mobile webcasting station.
It's great fun to be able to project a live feed from a seat in a conference room, or a bench in a public park, to distant viewers. But once the novelty faded, I have to admit I've rarely used this technique. That's partly because my scarce upstream bandwidth limits the number of streams I can serve. But mainly, I think, it's because the more we time-shift our consumption of media, the less we expect or demand live feeds. If I record a lecture at a conference, do you want to watch it as it happens, subject to multi-second latency? Or would you rather watch it at your leisure? In most cases, I suspect, you'll prefer the latter TiVo-like option.
The choice gets even easier now that media players have blurred the distinction between streaming and downloading. Suppose I record that lecture as a one-hour, 100MB QuickTime file. You don't need to download the whole thing in order to watch it. Media downloads tend to be progressive nowadays. You can start watching as soon as the player can load its buffers. And I, as the publisher of that movie, needn't bother setting up the specialized servers described here, or twiddling with firewalls. I can just post the file onto a standard web server
What you can't do this way, at least not to my knowledge, is enjoy the kind of random access I discussed in MP3 Sound Bites. Until that changes--and I hope it will--you still need a specialized server on the back end in order to support linking into video content. But despite all my evangelism on that topic, that's something not many people want to do yet. So the lack of random access isn't a compelling reason to stream files rather than merely post them.
What would be a compelling reason? Imagine the following scenario. It's 2007, and a major political rally is happening in Philadelphia. The downtown has been a WiFi zone for over a year. Bloggers are walking around with camcorders that do what my camera-equipped laptops can do today: encode video and send it via WiFi to a streaming server. Not everyone's blog server also runs a streaming media server, but there are enough of them to spread the load.
Here's the payoff: bloggers will democratize video reporting of the live event in the same way they've already leveled the playing field for conventional reporting. The TV networks will still score most of the big interviews, but the collective eyes and ears of the videobloggers will supply a wealth of otherwise missing viewpoints. And their archived videoblog posts will be stirred in to the blogosphere's bubbling cauldron of links, commentary, and aggregation.
It's a bit far-fetched, I'll admit. If you search Google today for "wi-fi camcorder" you'll only turn up a few tantalizing hints. But the scenario is entirely plausible. Meanwhile, unless I think up a killer application for the streaming techniques illustrated here, I'll likely focus mainly on videos that play from standard web servers.
Jon Udell is an author, information architect, software developer, and new media innovator.
Read more Primetime Hypermedia columns.
Return to the O'Reilly Network.