Yesterday on stage at Cisco Collaboration Summit, I demonstrated an industry first – the first non-transcoded video call between a webRTC application and an existing video endpoint.
Why is this significant? WebRTC is an exciting new technology, enabling real-time voice and video calling natively in the browser. Up until now WebRTC-enabled applications have not been able to connect to existing video collaboration gear that companies may own, from room systems to desktop video endpoints.
Today, Cisco has broken the barriers that previously prevented browser-based collaboration from connecting with existing video hardware. Companies that have invested in video collaboration can now extend that collaboration to the browser, enabling their users to collaborate from anywhere, at any time.
Yesterday, Andreas Gal, the CTO of Mozilla, joined me on stage. He called a simple SIP URI on a Cisco video endpoint, which instantly rang my Project Squared client running in Firefox. By leveraging WebRTC and Cisco’s OpenH264 binary module integrated into Firefox, we had a great voice and video call, without plugins, complex and cumbersome browser downloads, or expensive transcoding gear in the cloud. Check out a demo of what we did onstage here:
Voice and video communications over IP have become ubiquitous over the last decade, pervasive across desktop apps, mobile apps, IP phones, video conferencing endpoints, and more. One big barrier remains: users can’t collaborate directly from their web browser without downloading cumbersome plugins for different applications. WebRTC – a set of extensions to HTML5 – can change that and enable collaboration from any browser. However, one of the major stumbling blocks in adoption of this technology is a common codec for real-time video.
The Internet Engineering Task Force (IETF) and World Wide Web Consortium (W3C) have been working jointly to standardize on the right video codec for WebRTC. Cisco and many others have been strong proponents of the H.264 industry standard codec. In support of this, almost a year ago Cisco announced that we would be open sourcing our H.264 codec and providing the source code, as well as a binary module that can be downloaded for free from the Internet. Perhaps most importantly, we announced that we would not pass on our MPEG-LA licensing costs for this binary module, making it effectively free for applications to download the module and communicate with the millions of other H.264 devices. At that time, Mozilla announced its plans to add H.264 support to Firefox using OpenH264.
Since then, we’ve made enormous progress in delivering on that promise. We open sourced the code, set up a community and website to maintain it, delivered improvements and fixes, published the binary module, and have made it available to all. This code has attracted a community of developers that helped improve Read More »
Recently Cisco made significant efforts around open sourcing our H.264 implementation, including covering the MPEG-LA licensing costs for distribution and working with Mozilla to add support for H.264. However, in this attempt to unstick the logjam that has occurred in the standards bodies, the Internet Engineering Task Force (IETF) failed to reach consensus on the selection of a common video codec.
Cisco’s Jonathan Rosenberg explored this topic more in a recent Collaboration blog post. Read on to find out how we’re planning to move forward and why this conversation is definitely not over!
Cisco recently announced that we would open source our H.264 implementation under favorable open source terms, and more importantly, provide a binary distribution of that implementation that could be downloaded and integrated into browsers and other applications. We said we’d cover the MPEG-LA licensing costs for this distribution as well. Mozilla responded by saying that, based on this, they would add H.264 to Firefox, using our technology.
Part of our motivation for making this announcement was to unstick the logjam that has occurred in the standards bodies. The Internet Engineering Task Force (IETF) is defining the standards for how real-time voice and video will work natively in the browser. Selection of a common video codec is part of that process. The group has been highly divided on this topic, with two camps – one (including Cisco), in favor of industry standard H.264, and others in favor of Google’s VP8 technology.
We hoped that our announcement, and Mozilla’s agreement to support H.264 as a common codec, would provide enough impetus to sway the standards to a concrete decision so that the industry could move forward. Alas, that was not the case. Despite what we felt was a fairly objective analysis on the reasons why H.264 was a better choice for the overall success of real-time communications on the web (click here for a recording), the IETF failed to reach consensus.
Obviously, we’re very disappointed by this. Read More »
Cisco has been a champion of video communications for a very long time. We are committed to seeing video communications from board room to cubicle, and from CEO to intern. To achieve this vision, we’ve been investing in video solutions from top-end immersive telepresence to video capable soft clients like Jabber. Unfortunately, the one place we haven’t been able to fully go is the web. Video communications is not possible natively in the browser – yet. Work has been progressing on addressing this through an extension to HTML5 called WebRTC. However, this activity has hit a speed bump due to disagreements on choosing a video codec for the browser. Cisco and many others support H.264, which is the foundation of our products and those of most of our competitors.
Today, Cisco has taken a bold step to bringing video to the web. We plan to open-source our H.264 codec, and to provide it as a binary module that can be downloaded for free from the Internet. Cisco will not pass on our MPEG LA licensing costs for this module, and based on the current licensing environment, this will effectively make H.264 free for use in WebRTC. Furthermore, Mozilla has announced it will enable Firefox to utilize this module, Read More »