- Archiving—You can record audio-video streams in a session and download the recording as an MP4 file (with H.264 video and AAC audio).
- Dynamic frame rate control—This feature lets you reduce bandwidth usage of a Subscriber’s video stream. This reduces CPU usage and the network bandwidth consumed, and it lets you subscribe to more streams simultaneously.
These are just a couple of the new features to be included in version 2.2.
Today we’re announcing new Intelligent Quality Controls in the OpenTok platform. To catch everyone up, Intelligent Quality Controls are the features and enhancements we’re developing to make sure that each participant in a video call has the best possible experience.
Update (Nov 25): Developers, check out our new blog post that provides details on using dynamic frame rate controls.
You may recall that over the summer we launched traffic shaping for the audio-only fallback feature. This feature drops video in low bandwidth situations to prevent a participant with poor QOS from dragging down the video quality for everyone else. Essentially, we built the automatic (video) mute button for “that guy on his cell phone in a convertible!”
Connectivity, we at TokBox believe, is one of the cornerstones of real-time communication applications. So we are happy to announce that we now support TURN over TCP.
There are several technologies which are used to help establish connectivity in WebRTC. The first mechanism is using a protocol called STUN. STUN uses a ping-pong mechanism to find the public IP of a client end-point so that a peer-to-peer session can be established and one can traverse a firewall. While this is useful in a number of scenarios, there are cases where one could be behind symmetric NATs, where STUN does not suffice. TURN helps in these cases. TURN is a mechanism by which real-time media can be relayed through a TURN server to punch through firewalls. OpenTok seamlessly supports STUN and TURN so a developer doesn’t have to worry about how to setup up these servers, scale them, establish connectivity etc.
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.
As we announced on August 29, today TokBox introduced new pricing for the OpenTok platform. Please take a moment to check out the new pricing section of our website: http://www.tokbox.com/pricing.
Our new pricing starts with a 30 day free trial during which we hope developers check out everything the OpenTok platform has to offer.
Customer who wish to continue working with the OpenTok platform after the trial period can do so by entering credit card info in the account’s dashboard – or by contacting business development (firstname.lastname@example.org) for invoicing information.
In April we announced our new Mantis multi-party infrastructure for Web RTC was available for pre-production trials. Since that time, hundreds of customers have logged minutes against our new infrastructure, powering multi-party OpenTok calls around the world.
We’re seeing customers connect foreign language students from across the world, build classrooms of sizes well past what off the shelf WebRTC could support, and experience more stability and quality in their multi-party conversations.
You could consider Mantis to be a media router, but in reality it is so much more than that. As the OpenTok platform grows and evolves to better solve the use cases our customers are building, the Mantis infrastructure is going to allow us to deliver a level of quality (starting with our traffic shaping algorithms that we released in June), product enhancements (such as archiving), and other capabilities that will take WebRTC to a new level.
At TokBox, we aim to push boundaries and deliver the best possible WebRTC-enabled experience for application developers building face-to-face video applications. One of our guiding architectural philosophies has been to provide the right primitives for developers to build rich and powerful applications. In addition, we want to make sure we abstract the underlying nuts and bolts and enable the cloud service to dynamically react to changing environmental conditions (bandwidth, packet-loss, etc.) in order to deliver the best possible experience.
The multiparty stream routing component of the OpenTok platform is also capable of shaping traffic in real time. Let’s take a look at how this this capability delivers a significantly improved quality of experience for users.
A few weeks ago on September 6, 2013, a thousand students congregated at UPenn from all over the world, laptops out and ready to code. It was one of the largest student run hackathon in history. Out of the thousand, 4 sophomore students from Carnegie Mellon University (CMU) rose up to the top to win the “Best Hack That Makes Life So Easy” prize by Venmo, “Best Cloud-Connected Hack” prize by Microsoft, and our prize, “Best Use of TokBox API”.
There’s a new digital version of an old analog joke that starts something like this: “Two WebRTC engineers walk into a bar to have a beer while they talk about signaling.” The problem is that it’s the hotel bar at the Hotel California, and the punchline is that the engineers never get to leave.
Hardly a day goes by without another blog post about signaling and WebRTC.
Some people think signaling should be standardized; others think we already have the answer in SIP or REST. Some think that the lack of a signaling specification (beyond the need to support SDP offer/answer) is a huge gap in the WebRTC standard.
We think that leaving signaling out was the smartest thing that the key drivers of the standard could have done, for three reasons: