I just finished helping out a nonprofit client of mine to broadcast live streaming video of a concert, and in the process am stumbling into some video expertise. Since it’s the season for sharing… here goes.
First, some background: Every year, The Angel City Chorale takes its holiday concert on the road — to homeless shelters, soup kitchens, hospitals, and other places that serve people who otherwise wouldn’t be able to attend a holiday concert. (In addition, they raise funds and supplies throughout the year to bring with them to the places they visit. It’s a long day, but a really rewarding one. This year, they wanted to do a live video stream from one concert location to a women’s shelter — allowing them to reach another isolated audience with a little bit of holiday cheer.
And they asked me to help with the technical issues of a live stream. It’s been much harder than it should be, but in the end, it worked.
It’s important to note that live streaming video is not the same as plain ol’ streaming video, such as the clips you see on YouTube (or any of the dozens of video clips I’ve posted online for several of my clients). Plain ol’ streaming video is fairly easy, and most Web servers can handle clips of reasonable size and with average Web traffic. Live video, however, requires a specialized Web server (thus, in this case, a specific Web hosting company) and some pretty high-speed connections.
To help everybody understand what we were doing, I whipped up this chart.
Test #1
We started by testing WebEx, an excellent service for live meetings. The system is really easy, and I recommend it for business presentations. Since WebEx provides the hosting and all the technical assistance, setup is simple. However, in tests the audio (Voice Over IP) was not rich enough to do a vocal ensemble justice.
Test #2
So… we moved on to Flash Video (FYI, we could have also used Windows Video, I suppose. I just happen to like Flash more than Windows). The setup would be nearly the same, except that the church laptop would have Flash Media Encoder2 running to encode and simultaneously upload the video stream to UVault; and the remote computer would view the video in a Flash player rather than through WebEx’s Java client.
First problem: finding a host. See, dedicated hosting for streaming video is more expensive than your average GoDaddy account, and many hosts don’t even offer live video streaming (“because it’s too server intensive” is the common explanation). After some research, I landed on a Florida company, UVault. They seemed on top of things, and I spoke to their VP of sales, who seemed nice and helpful. Their Web site claims they offer 24×7 tech support.
But there were a few things I didn’t calculate, such as quality and availability of customer service, and quality of documentation.
Oops.
In any event, I signed up for one month of Flash Media Server hosting for $60. (Note again: this is not Web site hosting; you can only put live Flash streams up on the FMS. So you’ve still got to have other Web hosting to place the Flash file that will be the viewer.)
Here’s where things get ugly, and I grow progressively older…
Turns out, UVault offers very poor documentation on live video streaming (there’s an inscrutable welcome email, and a link to Adobe’s FMS documentation, which is technical and voluminous). In order to play the video stream, you need a custom Flash player. UVault had promised to send one, but it hadn’t arrived… So, armed with a decent Adobe tutorial, I made my own. Great — but on UVault, it didn’t work. Went back to the tutorial and rechecked everything. Looks good, but still doesn’t work. So, time to put UVault’s 24×7 tech support to work.
Good luck. UVault tech support can only be reached via e-mail, and replies take 12 to 24 hours. (In my experience, the replies only came during EST business hours. Since I’m testing in the evening (PST), I’d send a request, wait until morning for a reply — which was often pasted boilerplate text that didn’t address my request). I tried to supply as much information as possible in my messages to tech support, since I wasn’t sure what exactly they’d need, and didn’t want to lose a week clarifying things. Hah! I lost the week. Some of the replies asked for information I’d already provided, and none of them solved any of my original problems.
But I did finally get the player they promised, so I started using that (still don’t know why mine didn’t work). It’s ugly but functional…
So we should be good, right? Wrong!
My first live streaming test was badly buffering at the remote site — up to 30 second gaps in the middle of the stream. (For a live concert? That’ll never do…)
Finally, I call their sales guy back and he tells me that my upload speed is not high enough. I guess I should have known that, but I hadn’t considered it. I was testing on a DSL line which had about 312Kb/s upload (same as the concert location). [BTW, SpeedTest.net is great for testing upload speeds.]
Naturally, the entire process is only as good as the slowest component, and for a live show, that means from the camera to the encoding computer to the media server to the end client. In almost all cases, the upload speed at the encoding site will be the slowest… So, in setting up your live feed, getting the fastest possible upload speed is crucial. Also, there’s always network traffic overhead, so the upload stream needs to be less than 80% of the total available bandwidth.
The guys at UVault know all this, and yet I couldn’t get anyone to say it until I called the poor sales guy and chewed him out. Yikes. There’s a customer service lesson in there…
Final Solution
I’m a big believer that if you’re unhappy with the service, take your business elsewhere. So, we started looking for another company. We eventually found UpStream Networks, who specializes in Windows Media, and as it turns out their prices are lower and their customer service is much better. (For starters, they’ve produced a getting-started guide that walks you through the simple setup options. Also, since the Windows Player is already set up to play live streams, you don’t have to create a custom player to connect to the video stream.)
That’s the service we used, and for that part of it, everything worked out great. For the other side of the story, see Part 2: The Client Experience.
