Over the last few months or so at ZDNet, we've been playing around with various IP-based videoconferencing options in hopes of finding some way to leverage the video capabilities for pumping content between locations for usage in the videos we produce on line. For example, we'd like to have a two-pane video version of the Dan and David Show. In the course of doing this, we've become painfully aware of the sensitivity of these systems to bandwidth constraints some of which are very corporate in nature.
For example, in an effort to pump video back and forth between my home office and our San Francisco studios (which are in behind CNET's corporate firewall), the bandwidth constraint wasn't on the home office end. It was on the corporate side where the people in charge of CNET's network connection were, for obvious reasons, not about to give an IP-based video conferencing system carte blanche access to the company's Internet connection. If they did, the videoconferencing system could easily overwhelm the connection, the net result of which could impact all the other traffic. It's a scenario that's probably repeated in corporations and businesses everywhere. So far, in the case of our experiments, the results have not been that good. Latency is a key issue and we've tried to the best of the abilities of the systems we're working with to throttle the audio and video quality in hopes of minimizing the latency but have had little luck.
The problem is that the systems we're working with can't do two things: they can't say "here's the most amount of bandwidth I'm going to get" and then automatically throttle the quality (or window size, or whatever) to eliminate latency. The other thing they can't do (or don't do well) is monitor the network for congestion. Even if a network administrator programs the system for some maximum bandwidth threshold, there will be times that the system can't get that due to other networking constraints. In our case, I'm just talking about a breakdown in point-to-point communications. The minute you start multi-streaming though, it might not be long before network issues have some impact on performance.
Here at Interop, I happened across a company called Avistar that, as far as I could tell, has three selling propositions that, when taken together, make the offering rather unique. First, it does multistreaming. OK, multistreaming isn't that unique. But, it appears to do it pretty well (and maybe that's unique). One reason it does it well is the second unique selling proposition. The client software automatically throttles the video quality to deal with whatever the current bandwidth constraints are. For example, when a second stream of video from another location gets brought into a videconference (for a total of a three-way), the quality of the video in the initial two windows is dynamically degraded so that the overall bandwidth consumption doesn't change. Video is also dynamically degraded based on network intelligence that the Avistar client is constantly developing. For example, if it sees unexpected latency between it and another system in the course of a videoconference, it will dynamically cut back the video quality in hopes of eliminating any latency.
The third interesting feature of the system is the way it can contextually operate out of existing IM clients (for example, Microsoft's, IBM's, etc.). In the video above, I interview Avistar's president Simon Moss and we show the product in operation from the Interop show floor where he connects to several other locations around the world via the Internet.