Streaming Media

Streaming Media on Facebook Streaming Media on Twitter Streaming Media on LinkedIn
 

Producing My First Webcast

Jan Ozer produced his first live webcast on May 8, 2010. As with anything else, he learned some huge lessons that didn't become obvious until he was there in the chair, broadcasting live. If you've got your first live webcast coming up, perhaps you'll find them useful.

Choosing Encoding Parameters

After getting connected, my thoughts turned to the streaming configuration I would use for the event. First, understand that in most instances, the encoding configuration set in your encoding tool (WireCast, in my case) is the one that will be streamed to your viewers; it won't be re-encoded by the service provider. You have multiple factors to consider when setting your encoding configuration, the two critical factors being the upload bandwidth from your event site, and the bandwidth of your viewers.

Before the event, I measured on-site upload bandwidth using www.speedtest.net, and it averaged 700Kbps. This meant that my stream configuration would have to be well under this figure-otherwise, I would have trouble getting data to the server, which obviously stops the show for remote viewers.
Also, I knew that some viewers would watch from Australia, Indonesia, and other far-flung locales. Optimally, I could have offered multiple streams via the ViewCast box, a large stream for U.S. consumption and smaller one for overseas, but I didn't have the outgoing bandwidth for both. To be safe, I went with 320x240 resolution, 15 frames per second (fps), with video at 250Kbps and audio at 32Kbps. As shown in Figure 5 (below), I used the H.264 codec configured to the Main profile.

Encoding configuration
Figure 5. The encoding configuration that I used for the webcast.
If you're operating in a bandwidth-constricted environment, like I was, be sure to choose constant bit rate encoding rather than variable, because data rate spikes associated with variable bit rate encoding can overwhelm the outgoing bandwidth and stop the outgoing stream, which can also pause the show at the receiving end (and ultimately did).

In Figure 5 (above), the "Limit peak bit rate" checkbox performs this function, a detail that I missed during setup, which forced me to make some fast adjustments after I went live. More on this later.

At the Show

That Saturday, I arrived at the Courthouse at about 8:30 AM, an hour before the show, and first set up the XH A1 and wireless microphone. For those who care about such things, I was using the AKG MicroPen MP40, discreetly taped to the auditorium microphone, transmitting wirelessly to the SR 40 receiver that I connected to an XH A1 XLR ports. Lighting (of course) would be totally au naturale-I couldn't very well fire up the tungstens for a green event. Fortunately, the auditorium was flanked with large windows both left and right, and Mother Nature cooperated with a sunny day that provided lots of beautiful indirect light. I set the zebras at 75, configured exposure manually, and had no trouble painting the subject's faces with zebras all day long.

Next, I booted up the MacBook Pro, ran www.speedtest.net to confirm my earlier bandwidth findings, and ran WireCast, which immediately found the XH A1 and connected to the Multicast Server. Then I logged into the server in a browser to check the test stream, which was also good. I opened up another browser window, and surfed to the Grayson Landcare page with the embedded video so I could monitor the live stream at the event.

Everything looked grand as the countdown clock counted backwards: «3 ... 2 ... 1 ... live.» Playing the director, I cued the first speaker, but as I zoomed out of my initial wide establishing shot to a medium closeup, the video I was monitoring on the Grayson Landcare website stopped as dead as Ogg Theora after Google's VP8 launch. I quickly checked WireCast's outgoing-bandwidth monitor, and noticed that it was up in the low four figures, somewhere north of 1100Kbps. So much for 250Kbps video and 32Kbps audio, eh?

I flashed back to the bandwidth testing I had performed in my office, which was static camera only, and realized that the data rate was spiking with the camera motion. I checked the encoding preset, noticed the "Limit peak bit rate" checkbox, cursed myself for not seeing it beforehand, and clicked the checkbox. The data rate had already stablized with the static camera, so I couldn't tell if I had fixed the problem or not.