The long-running video codec debate has, without a doubt, been the biggest open issue in the WebRTC standards effort.
In a surprise announcement last week, Cisco introduced a mechanism through which H.264 could be used in WebRTC browser implementations free from MPEG-LA’s licensing burden.
Cisco’s maneuver was a master stroke from the playbook of open standards strategy. The licensing deal they announced with MPEG-LA appears to cut the legs out from under the main pragmatic argument opposing H.264 (ie. the royalty problem). Mozilla’s support lent Cisco’s approach instant credibility from the ideological wing (ie. the open source camp). And by keeping this under wraps until a week before the upcoming IETF 88 meeting, at which the video codec debate is to be revisited, Cisco left no time for any coordinated response from the VP8 camp.
In the last year we’ve witnessed VP8 proponents and H.264 proponents debate which codec should become “official” for WebRTC. The main points of contention? Licensing fees associated with H.264 make it unaffordable for a non-profits like Mozilla to support. In addition, VP8 isn’t compatible with existing and legacy video conferencing platforms which are typically built to support H.264.
We saw Google draw a line in the sand early on by announcing the “perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable” licensing of VP8. In addition, they recently moved their flagship video conferencing product, Google Hangouts, on to VP8.
Yesterday, Cisco unexpectedly announced that they will release an open-source version of the H.264 codec. The open-source version will include a free downloadable binary module that can be integrated into any application. All without the cost of licensing the codec . This is a strategic precursor to the IETF #88 next week where a vote will take place about the MTI (mandatory to implement) video codec for WebRTC, with the dominant front-runners being VP8 and H264.
WebRTC is clearly a hot topic. But in an effort to discover just how hot we conducted what we think is one of the largest global surveys of its kind. Today, we are pleased to share the results with all of you in the TokBox and greater WebRTC community.
The study, which analyzed responses from 1,161 people across 11 countries, found rapidly emerging interest amongst larger organisations (1,000+ employees), and also found rapid WebRTC adoption amongst smaller companies (fewer than 500 employees) where more than one in four (27.1%) developers say WebRTC is already critical to their work.
Some of the other key findings:
We’re incredibly pleased to announce that OpenTok on WebRTC supports Google’s just-released Chrome 29 for Android. This brings Android support formally into the OpenTok on WebRTC family, and is a big step forward in increasing the number of WebRTC-ready endpoints in market.
We’ve been working with the Chrome for Android beta builds over the last few months, making sure that OpenTok on WebRTC works properly – and transparently – in that environment. In fact, attendees at WebRTC Expo in Atlanta saw us demonstrating OpenTok applications running in Chrome on Nexus tablets at the beginning of the summer.
Hello TokBox Community,
We have a small favor to ask of you. We’ve pulled together a brief survey about WebRTC that aims to measure the current level of awareness, interest, and activity around the standard and we need your input:
The results will be made public and will reveal:
- The depth of WebRTC knowledge in the tech community
- Which features/functionality are considered most important to you
- How the tech community would like to see the standard develop over time
Added bonus? We’re raffling off five $100 Amazon gift cards to people that have completed the survey (you’re only eligible to win one). So take a few minutes, ponder what WebRTC means to you, and answer our survey. Thanks!
We’re incredibly pleased to see Mozilla launch Firefox with WebRTC enabled by default. With Mozilla’s Firefox joining the WebRTC family, millions of people will have the opportunity to experience high-quality plugin-free face-to-face video within web applications.
Today we’re proud to announce our latest WebRTC innovation: Mantis, a cloud-scaling infrastructure for our OpenTok on WebRTC platform.
This is another big step forward for the TokBox team as we continue to pursue our goal of providing application developers with simple yet powerful APIs. APIs that not only leverage the latest standards to deliver the best possible experience, but that are backed by a scalable, smart cloud which supports interoperability across a variety of end-points.
A new version of Chrome is out, and with it changes in the WebRTC stack. We dug through the commit logs for Chrome 26, and found the following list of WebRTC bug fixes, enhancements, and updates that we thought were relevant to the OpenTok community:
- A lot of audio bugs in WebRTC were fixed dealing with crashes and non-standard audio bitrates
- Chrome on Android can now be WebRTC-enabled by enabling a flag
- Improvements to the connectivity stack in WebRTC
- Ability to set media constraints for audio
On February 4th Mozilla and Google announced that their respective browsers could now talk to each other via WebRTC. This is another big milestone in WebRTC’s path towards becoming available in all modern web browsers, albeit, today only in an early development build of Firefox, version 21+ (currently Nightly and soon to be Aurora).
We’ve also been working hard on making OpenTok on WebRTC work with both Firefox and Chrome so you too can enjoy all this cross-browser goodness!
Off to the races
The first thing that you need is version 21 or higher of Firefox, currently available through the Aurora FTP site and Nightly site.
About six months ago, Microsoft released an alternative proposal to the W3C WebRTC 1.0 Working Draft, dubbed CU-RTC-Web. Like all W3C groups, the WebRTC Working Group enlists membership from a majority of the industry, including names like Nokia, Cisco, Google, and Mozilla. The most important question raised by the Microsoft proposal is how the Working Group would react to criticism of its draft proposal, and whether Microsoft would accept the published APIs of the Working Group, even if CU-RTC-Web is not adopted. So what exactly does this mean for the development community?
The Microsoft draft outlines a low-level API that allows developers more direct access to the underlying network and media delivery components. It exposes objects representing network sockets and gives explicit application control over the media transport. In contrast, the WebRTC API abstracts these details with a text-based interface that passes encoded strings between the two participants in the call. With the WebRTC draft, developers are responsible for passing the strings between communicating browsers, but not explicitly configuring media transport for a video chat.