Lights, Camera, Action! Not So Fast...

The first live television production I was involved in was a local cable access call in show on the campus of Michigan State University in 1982. The production quality left a lot to be desired...but I'll never forget the sense of awe I had at seeing the technical director fade up from black on his little Grass Valley 400 production switcher...and then seeing video of me magically appear on monitors around the studio. A few moments later, the phone began to ring. The signal was beaming out...and we were garnering immediate feedback via inbound questions from viewers around campus.

This picture is often what corporate streamers have in mind as they ready for their first live webcasting experience. Ultimately though, streaming can be a bit more difficult than television. Here are a few reasons why:

1. Your video and audio must be converted to a digital format before it can be webcast. To make this happen, you have to employ an encoder at the venue where the camera and microphone are. There are software encoders. There are hardware encoders. They all do the same thing-turn your source media into a format that is appropriate for distribution on the Internet. Flash and Windows Media are the most popular streaming formats. Both companies offer free software encoders that you can use to properly "capture" your source media.

2. Feedback is generally not immediate. Because your "signal" is traveling as a series of packets of information...which must be viewed in order by your audience...latency is inherent in webcasting. That latency is the reason why live webcasting can be more challenging than broadcast television-because those packets don't all take the same amount of time to reach each viewer. In fact, it is possible that during a live webcast originating from New York City...a viewer in Richmond, Virginia could experience more latency than a viewer in San Jose, California. Of course, a CDN (Content Delivery Network) can circumvent much of this latency...but not all. Where latency is concerned, streaming is most different from television because an action occurring on camera during a live webcast may be witnessed by many viewers at completely different times. When Simon makes a snide remark on American Idol...all of America sees it happen at generally the same moment...that's because there is fairly consistent latency in broadcasting. Not so with streaming. Ultimately though, with a little planning...the impact of this phenomena can be reduced. Rather than using phones for that feedback from the audience for instance...it may be smart to employ a chat client adjacent to your video screen. To further reduce confusion among viewers...it might be smart to appoint a single "moderator" to receive questions via chat and in turn feed them to the speaker.

3. Simpler is better. All of those flashy motion graphics and visually explosive animation elements that are so prevalent on broadcast television today...won't improve your streaming program. They are what I like to call "high information elements"...elaborate motion graphics...camera movement (abrupt pans, tilts or zooms) are all things you should keep out of your live webcast. Simply put: The more motion you have...the more pixelated the result. Simple 15 frame dissolves are about the only effect I like to see in a webcast. Of course there are exceptions. If you're lucky enough to be propagating a 3 Megabit Windows Media stream to a limited number of board rooms around the country, and you're using a CDN...these television style visual elements will have little negative impact.

Finally, it's important to remind you to "measure twice...and cut once". Like any good live television program, a live webcast should be rehearsed multiple times prior to your scheduled day and time. Technical issues like "how bad is our latency among the different viewing locations"?, "does that 500K stream really look good enough"?, and "how long do those chat questions take to get back to our moderator"? can all be dealt with prior to the live webcast. In this regard, webcasting is not at all different than broadcast television. Break a leg!

Is It Unicast...or Multicast?

In the latter part of the last century (just feels kind of neat to say that-I'm actually referring to the year 1999), my company was involved in fairly extensive testing of live streaming via multicast distribution. I remember seeing the same 1.5 Megabit MPEG-1 stream playing off of an SGI server to dozens of PC screens simultaneously. Given that the intranet was a 10 Mbit LAN...this was impressive to say the least. The possibilities were exciting. Why? Well, to understand that, you need a primer on the inherent difference between Unicast and Multicast distribution of streaming media.

Unicast is the most common distribution method even today. It is a "one to one" method. For each PC accessing the stream, the bandwidth is compounded. As an example, if I were serving a 1.5 Megabit stream...and 10 PC's in an office sharing a T1 line tuned in simultaneously...well, the experience would certainly not be "like TV". Since every connection would require it's own individual 1.5 Mbit stream...all viewers would fall victim to simple math. The network would be choked.

Enter Multicast distribution. Multicast is a "one to many" distribution method wherein the source stream is simply replicated by routers on the network. Instead of compounding bandwidth for each viewer, the viewers simply "tune in" to the same 1.5 Mbit stream. Think of it as a broadcast on television. The difference is, that your viewers need to all be members of a "multicast group". Sounds simple and obviously desirable. But...there are security issues that have precluded the method becoming common place on the Internet. I'm certainly not qualified to explain in granular detail what those issues are. Just Google "multicast security issues" and you'll find many expert opinions.

Here's an analogy that might help: Imagine Unicast video of a corporate presentation being streamed to 20 viewers, each of whom have their own private TV screen and headphones on. Now, picture them in the middle of a room surrounded by passers by. Even though everyone in the room is in close proximity...they can't really see or hear the message well. Now, picture a video message streaming to a big screen in front of those same 20 viewers. No headphones this time, just big fat Bose surround-sound speakers. This time, everyone in the room can see and hear the message. While the video and audio are of a better quality...the message gets to anyone who happens to be in the room.

So, how do you take advantage of the network conservation benefit of IP Multicast while overcoming the obvious security risks that I have certainly over-simplified above? Well...

Fast forward to this century! It is my belief that there will be explosive growth and adoption of IP Multicast technology, especially by enterprise customers. There are a handful of companies who are making it possible to "multicast enable" your network so it provides the network benefits while reducing or eliminating the security risks.

You will still need publishing software, head-end capture hardware and many of the pieces and parts already used for Unicast streaming. But instead of your streams navigating a "contention based collision domain" to get to viewers...they will travel an easier, less congested path. Consider IP Multicast as an HOV lane on the information superhighway!