This is not how Cisco and Polycom do it. These vendors use the approach to take the encoded source, decode it at a central network device, and then re-encode the video stream for the various endpoints--a process called transcoding. Transcoding is done in real time, so it takes a lot of horsepower at that central device, and can add some latency to the video stream. Incumbent videoconferencing vendors do this partially for historical reasons and partially for protection of their own revenue streams. If they got rid of their MCUs in favor of a system that simply sent out portions of an already encoded video stream, they'd no longer need most of the proprietary hardware that makes MCUs a high cost, high margin product.
Another thing that's prohibited the ideal encode-once architecture described above was the lack of an encoding standard that actually did what we've described. Here some of Vidyo's principals and others have worked with ITU and MPEG to build such a standard: H.264 SVC. H.264 is the high def encoding standard that's been in use for years. It's used for everything from satellite and cable TV decoders to video surveillance systems to videoconferencing. The SVC part is comparatively new, and specifically seeks to do exactly what we'd want.
SVC stands for Scalable Video Codec. It starts by creating a "base layer"--which is a low resolution, low frame rate (and therefore low bandwidth) version of the video scream, and then adds "enhancement layers" to increase resolution, frame rate and quality. Once the video stream is encoded, distribution to end points just requires sending the base layer along with the appropriate enhancement layers. Using SVC, there's no need for transcoding, so the job of that central box moves to managing the network connection--something that only it can do, and something it's well suited to do.
This brings up another failing of the typical MCU-based system. If network connections degrade or improve in quality, the "video router" (as Vidyo calls it) can either predictively drop packets or move the connection to different levels within the SVC standard. Flexibly changing resolution and frame rate isn't something that most legacy MCU systems can do. As a result, they're often implemented on top of very expensive private networks. The network costs for a fairly complex videoconferencing system can be just as prohibitive as the cost of MCU hardware and fancy telepresence rooms.
With its new announcement of a virtualized video router, Vidyo believes that service providers will be able to use the company's technology pervasively across their networks. Ideally, the video router sits fairly close to the video sources so that smart routing decisions can be made without incurring too many hops. For service providers, the virtualized version of the video router can be implemented throughout their networks without buying Vidyo hardware. The virtualized instance of the video router would also be an interesting addition to multiservice edge routers in enterprise networks of any size. One can imagine use of centralized control with distributed processing as a good way to reduce wide area network demands.
There's no doubt that Moore's Law is on Vidyo's side in the debate about architecture. Encoding and decoding at the end points can be CPU intensive, but most of today's devices can handle it. Even phones and tablets with dual core ARM processors can do the job. But the Vidyo system isn't without some challenges. As with other videoconferencing systems, a major impediment revolves around bringing third-party users into Vidyo-based environment for impromptu conferences. The Vidyo system requires software to be installed at the end point, which can be a problem on locked down corporate laptops. That problem certainly isn't unique to Vidyo, but it's a limitation on making videoconferencing as pervasive as audio conferencing.
Polycom, for its part, made a number of announcements about its intent to support SVC last year, saying that it intended to support SVC in clients such as phones and tablets, though it wasn't clear that the company would use the technology beyond those applications. At the time, Microsoft seemed set to support Polycom's version of SVC (that there are "versions" among vendors is a problem all in itself).
Microsoft supports SVC in Lync, but while H.264 SVC is a ratified standard, implementations aren't necessarily compatible through the entire networking stack. In order for the technology to take off, it'll take multiple vendors embracing the technology and deciding that compatibility between systems is a worthwhile goal. The Unified Communications Interoperability Forum is probably the best bet for that. It was founded by HP, Microsoft, Polycom, and LifeSize, and includes Vidyo, AMD, Broadcom, and others--notably absent however, is Cisco. For a look at what interoperability will require, take a look at this nojitter story.
Art Wittmann is director of InformationWeek Reports, a portfolio of decision-support tools and research reports. You can write to him at [email protected].
To find out more about Art Wittmann, please visit his page.
More than 100 major reports will be released this year, all free with registration. Sign up for InformationWeek Reports now!/a>.
Subsea cable alternatives can provide a level of comfort for those concerned about disruptions. Realistically, they will continue to play a small, but critical role in the short term.
Maintaining existing network infrastructures often incurs huge technical debt before newer technologies are adopted over time.
Amid ongoing regional uncertainties, telecom infrastructure in the Middle East has expand to include terrestrial low-latency network infrastructure, which offers resilience and agility in navigating political complexities without relying solely on undersea networks.
