Following Mozilla’s announcement of the release of Firefox Hello in beta in October, the company has now announced the roll out of the service into the general release version of Firefox 34. This post relates to the release of “Hello” into version 35 of the Firefox Beta browser.
The result of a partnership between Mozilla and Telefónica, and leveraging the OpenTok Platform, Firefox Hello allows people to make video calls directly within the browser, with or without an account.
“Real life is, to most men, a long second-best, a perpetual compromise between the ideal and the possible.” – Bertrand Russell
The world has indeed changed in the last year as WebRTC has made massive strides both from a standardization and from a market adoption point of view. A whole host of innovative applications are succeeding on mobile and desktop end-points.
But despite another 12 months of progress, one of the key points of contention that remained stubbornly unresolved was the great video codec debate: Should VP8 or H.264 be the Mandatory-to-Implement Video Codec for WebRTC? It was a welcome and surprising move that led the IETF Working Group to finally arrive at the following consensus just last week:
Mozilla has today released some additional capabilities into the WebRTC communications feature beta it first released a couple months ago and unveiled its name for the first time – Firefox Hello. As always, we’re delighted that OpenTok is the platform of choice for companies building innovative services such as this that are able to scale up to hundreds of thousands of users.
New features of Firefox Hello being released in Firefox Beta today include:
As Mozilla rolls out Firefox Beta to users over the next few weeks, they will be able to connect with anyone using a WebRTC-enabled browser (such as Firefox, Chrome or Opera) with no need to download software or plugins (credit fayeun). These are just a few of the improvements that have been made since the last release.
Signaling between client end points has always been an important facet for most interactive web applications. The use cases range from text chatting to multiplayer games to driving a robot remotely. In the world of HTML5, most developers establish signaling through websockets, long polling and server side events. However with the advent of WebRTC, data channels joined the ranks and the question posed by many developers is “Where do data channels fit in the equation?”
Data Channels provide a way to send binary / text data to another peer over the browser. The data channel api is very similar to web sockets when it comes to sending different types of data. It works peer to peer without the need of a centralized server or an additional hop in most cases.
We know readers of this blog are enthusiasts and thought leaders when it comes to WebRTC implementations. Three months ago Mozilla launched its own experimental WebRTC feature powered by OpenTok into its Firefox Nightly channel. Now they’re calling on you to get involved and test it out as they release it into Firefox Beta.
Since launching this experimental feature it has evolved, and will continue to evolve, but the goal remains the same, to make audio and video communications simple and connect everyone with a WebRTC enabled browser.
**July 25 UPDATE Since launching their experimental service powered by OpenTok over a month ago, Mozilla has received a lot of positive feedback. As of today, they are making the WebRTC feature available through Aurora so that they can gather feedback from even more users. It’s important to note that they are still in the testing and experimental phase and are keen to get your feedback as always. We’ll keep you posted as the feature develops.**
TokBox has always believed in the power of WebRTC to change the way that people communicate in the digital world. Not just in browsers, but also on phones and other connected devices as well as the amazing devices of the future that we know are coming.
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 [1]. 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.
