It went very well. We treated it like a "normal" gig, and in a lot of ways it felt like a "normal" gig. We advertised it (a little modestly, I'll admit), prepped, stuck to a start time, and played hard (as it can sometimes be easier to do when people are watching). It was strange not being able to see the audience.
I would recommend this to any band that can handle it technically (I'll talk about that more below). It seems like a great way to get/stay in shape, build, maintain, and connect with your fan base - all without lugging equipment, dealing with tentative venue/entertainment managers, etc.
I do think it was a lot more fun having someone who could produce the show - tasks including monitoring and switching cameras, responding to people in the chat room, etc. Thanks go to Ian Sears, of CentralVermontLive.com for that.
There were some technical problems, but nothing that stopped the show. We used ustream.tv to do the broadcast, and there were a few things that, for all the popularity this site has, frankly disappointed us.
- Commercials and ads - The broadcast was frequently interrupted with a commercial (and I mean something that "replaced" our video and audio which the user had to close in order to continue watching us). The ads were annoying, and there was even some kind of popup ad window that had popped under. wtf
- Latency- We had some issues with latency, which we later traced to the fact that we were using Wirecast (basically the same as Ustream producer pro). It uses a LOT of CPU, and I think we've pretty much decided is not worth it. A better product is VH Multi Camera Studio, which we managed to download before the pulled it off the web. I'm looking forward to their commercial release.
- Long wait times, heavy CPU utilization, whether you're a server or a viewer.
The other issues we had were mostly to do with levels. As it turns out, there are a variety of places that that levels need to be adjusted, and we needed to learn where they all were (board output, the Windows mixer line-in level, Wirecast, and finally Flash has its own level adjustment).
After we were done, we decided to play around with Justin.tv for comparison.
Our new input chain looks like this:
Board audio/Line in----------->Flash Media Encoder -----> Justin.tv
Cameras ---->VHMultiCam-->Flash Media Encoder -----> Justin.tv
First observation is that Justin.tv seems easier to use than Ustream. In particular, the controls seem more intuitive, and there are fewer pages to navigate in order to get where you want to go. It seems to automatically record when you broadcast. You have to delete the video after, if you don't want it to stay up.
Some other things, again- this was only a first look, so forgive me if there are some minor inaccuracies.
- justin.tv had lower latency: 2 seconds, compared to 4 seconds for Ustream. Both tests were performed with VHMultiCam going directly into Flash (no full FME). The full FME seemed to add 4 seconds of latency, which would be presumably common on both services.
- justin.tv seemed a little more reliable on both the sending and viewing end. Noticeably less stream startup time, and seemed to run without breaking up or stopping. justin.tv seems a lot nicer on the viewer's CPU.
- justin.tv might have fewer interactive bells and whistles (does chat, not sure if it does polling).
And here's the big one: Unlike ustream, it didn't keep interrupting the broadcast with a commercial, poorly implemented ads on the page, or weird popup windows.
All in all, it seems like Justin.tv is worth checking out. We'll probably be using it for our next broadcast.