Uncategorized

WebRTC on Blackberry 10

Our friends at Hookflash kicked off the week by announcing support for WebRTC on Blackberry 10. Erik Lagerway followed up on webrtc-discuss:

Just thought I would let everyone know that we have finished porting Google’s WebRTC media stack in entirety to QNX / Blackberry 10. Currently in our Open Peer github repo, we plan on getting this back upstream, if Google will have it.

WebRTC Tech Lead Justin Uberti, welcomed the news and laid down the ground rules for contributed ports:

Erik, thanks for letting us know. Always good to see someone expanding the WebRTC ecosystem!

Assuming the porting adheres to our style guidelines and our practices for platform-specific code, we can help land this. The only caveat is that we will not be able to fully support it through our trybots and tests. When the build breaks, you will need to fix.

Firefox 22 Hits Beta

On Tuesday, Firefox 21 was released, which leaves only one more version before WebRTC is enabled by default. Firefox 22 is currently scheduled for release on June 24. If you’re impatient, you can get a preview in Firefox Beta, Aurora, or if you’re really brave, Nightly.

Jon Fingas, writing for Engadget, has more on Firefox 22:

Though Mozilla has long been a proponent of WebRTC for plugin-free video and voice chat, it hasn’t been ready to enable the full protocol in Firefox as a matter of course. It’s more confident as of this week…

Google IO

Justin Uberti and Sam Dutton wrapped up the week with a presentation on WebRTC at Google IO. Both the slides and the video are now available for your viewing pleasure.

Janko Roetgers covered the session highlights for GigaOm:

WebRTC, the new technology that enables plugin-free voice and video chat within the browser, should be available on more than one billion unique endpoints (think: desktop browsers and mobile devices) “within a week,” according to Google’s WebRTC engineering lead Justin Uberti.

Endpoints++

Last but not least, Tsahi Levent-Levi has a few suggestions for UC vendors and customers in our favorite post of the week:

All of the room systems and endpoints you are installing? Make them pure WebRTC capable – have them run an HTML5 browser and let Java Script do the rest. Have your own solution use that type of a deployment. All of your legacy products? Have a gateway for them to access the system.

+1 to that.

Here at vLine HQ, we have an internal mailing list that we use to share links to articles, mailing list posts, code checkins, and other interesting tidbits related to WebRTC.

Now that we finally have a blog, we thought it might be nice to share these links with you, dear reader (Hi Mom!). So, watch this space each Monday for a new, carefully-curated batch of week-old WebRTC news (how’s that for real-time?). With no further ado, here’s our first edition:

Exploding Endpoints and Spiders

Kelly Teal, writing for Channel Partners asks What in the World is WebRTC? and polls a few analysts for answers:

When it comes to video collaboration, everyone is talking about WebRTC. But what is WebRTC and what does it mean for partners?

 …

“What WebRTC does do is create the potential for an explosion of browser-based video endpoints, which will only connect to other endpoints running the same standard,” Wainhouse Research analyst Bill Haskins told Channel Partners.

We certainly agree about the explosion of browser-based endpoints. Genband, however, disagreed that they will only talk to others running the same standard by announcing SPiDR, a new legacy-to-WebRTC gateway. Gary Audin, writing for NoJitter has the story:

SPiDR sits at the edge of the operator’s network. It provides open, web-centric APIs that allow application developers to produce rich communications services through the network including voice, video, presence, shared address book, call history, instant messaging, and collaboration. 

Google IO 411

Google’s annual developer shindig is coming to town later this week, and WebRTC Tech Lead Justin Uberti will be returning to the stage with another sure-to-be-packed-to-the-rafters session on our favorite real-time stack (in case you missed his session last year, you can check out the video here).

This year he’ll be co-presenting with Chrome Developer Advocate and HTML5 Rocks contributor Sam Dutton. The two will also be running a  hands-on Code Lab to help lucky ticket-holders translate the alphabet soup of WebRTC APIs and protocols into tasty web apps.

In this codelab, we’ll help you get to grips with the core APIs and technologies of WebRTC: – MediaStream (aka getUserMedia): what is it and how can I use it? – RTCPeerConnection: what is important about WebRTC’s most powerful API? – RTCDataChannel: how can I set up real-time communication of arbitrary data? – signalling: what is it and how do I set it up? – servers: what do I need for signalling, STUN, and TURN?

Bird Food

Speaking of tasty treats, Justin warmed up for IO by dishing out a trio of long-awaited morsels destined for Chrome Canary on the discuss-webrtc mailing list. On Wednesday, he hinted that reliable data channels are landing soon (if you want to be the first to know when they alight, you can star Issue 1493).

Then on Friday, he made our week by announcing that you’ll soon be able to use the getStats() API to discover which ICE candidates the browser selected. No more tcpdump or verbose logging to figure out if you’re using a relay server!!! Are you as excited as we are?

And last, but not least, he confirmed that Canary has gained the ability to load-balance across multiple TURN servers. Full thread here.

Richard Mentor Johnson?

Finally, we have a couple of codec-related tidbits. WebM Product Manager and former interim On2 CEO Matt Frost posted that VP9 is nearing completion. We don’t know what we’re more excited about, the support for depth channels (3D webcams + depth maps + WebGL = ???) or the VP9 vs H.265 codec wars.

Since it’s not seeming especially likely that the browser vendors are going to agree on a common built-in codec this decade, Mozilla’s push for an all-javascript codec is starting to sound more and more reasonable. Following up on Brendan Eich’s Today I Saw the Future post about ORBX.js , Peter Bright, wrote a nice piece for Ars Technica with more technical detail:

For browsers including Internet Explorer 10 and Safari on iOS, ORBX is used in I-frame-only mode. For other browsers, including Firefox and Chrome, it uses a more conventional mixed mode. That’s because the mixed mode depends on WebGL for part of its decoding. I-frames can be encoded entirely in JavaScript, but P-frames require the use of shader programs due to their greater complexity. Internet Explorer 10 and Safari on iOS don’t support WebGL, and so can’t be used to run shader programs. As a result, they use about twice as much bandwidth for the same level of video quality.

Sadly, no public demo yet. But we can’t wait to try it on our iPhone 12s.