Firepad provides true collaborative editing, complete with intelligent OT-based merging and conflict resolution. It’s full-featured and has support for both rich text and code editing. Some of its features include cursor position synchronization, undo / redo, text highlighting, user attribution, presence detection, and version checkpointing.
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
- Avoids crash in WebRTC audio clients for unsupported capture sample rates.
- Avoids crash in WebRTC audio clients for 96kHz render rate on Mac OSX.
- Enable webrtc build on android.
Set WebMediaPlayerMS network state to loading instead of loaded
This indirectly fixes the problem where WebRTC audio is muted upon refresh. The HTMLMediaElement will try to cache fully Loaded videos when the element is destructed. This will signal to the HTMLMediaElement that the player was destroyed when loading, so it needs to recreate WebMediaPlayerMS upon destruction of the media tag.
- Allowing multiple MediaPlayers to connect to WebRtcAudioDeviceImpl by sharing one WebRtcAudioRenderer.
The audio is gone when new PeerConnection is connecting to a media stream. What is happening is that the stream will pause the existing MediaPlayer and create new MediaPlayers to associated to it. But since we only allow one WebRtcAudioRenderer to connect to WebRtcAudioDeviceImpl, the new MediaPlayers audio won’t be able to associate to stream.
SXSW is here again and we are ready!
This year we are giving out TokBox WristBands. They are motion activated and light up with a brilliant flare whenever you shake hands or fist bump someone. Make a visual connection! Here’s how it works:
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
This weekend we hosted 175 hackers for Music Hack Day San Francisco in our office for the third consecutive year. Music Hack Day is a unique event—it doesn’t use huge prizes or big name judges to draw a crowd. It’s one of the rare Bay Area hackathons where (seemingly) most attendees actually aren’t local—giving it a fresh vibe, with new faces and ideas every year.
Last week I wrote a post that called for more hackathons to be purpose driven—Music Hack Day is not one of those of events. Instead, Music Hack Day is an event driven by a desire to learn and a shared passion for music. These types of events are, without question, very good for the hacker ecosystem, and Music Hack Day is a shining example of how they should be run.
There is a new breed of Ninjas taking over. Instead of covert agents wielding nunchucks and wearing ninja-yoroi, you’ll find gentler individuals donned in yoga pants, weaponed with guitars and Adobe CSS. LiveNinja, our App of the Week, is responsible. They’ve created a searchable marketplace of experts (Certified Ninjas) in the topics you care about, using the OpenTok API to facilitate live video consultations.
Last Thursday, I had the pleasure of being a part of the Mobile + Web developer conference held at the Hilton Hotel in San Francisco. I spoke on a panel about where development was headed in a world where Web + Mobile are the two predominant platforms. There were four of us total, and we had a great time talking about how each of us lived in, and viewed the future of development in this two platform world. The panel was composed of (beyond myself) John Hammink, a QA engineer from Mozilla, Jonathan Smiley, a partner at Zurb building their own HTML5 framework, and Ted Drake, a senior accessibility engineer from Intuit.
It’s fashionable to be cynical towards hackathons. There’s too many of them. They exploit developers. They rarely have useful products come out of them.
Even if you’re not a cynic, at some point you have to wonder—why do the overwhelming majority of hackathon projects die succinctly and unquestionably following the event? It’s often a foregone conclusion for the hacker—go to the event, try to win the prize, and then go back to your job the next day.
And there’s nothing wrong with that. Most of the time people go for fun. It’s a good learning exercise. As a first timer, the sheer novelty of it all gives you enough energy to power through an entire weekend.
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.