This post was co-authored by Gustavo Garcia Bernardo, Philipp Hancke and Charley Robinson.
When WebRTC stuff is really broken, it gets fixed very quickly.
Early in December 2015, shortly after the release of Chrome 47 to the general public, we started to notice a subtle and strange behavior in the Audio/Video of streams during our many daily meetings using WebRTC: the video occasionally wouldn’t stay caught up with the corresponding audio. As with many bugs noticed internally by developers, it took a while for any of us to believe that what we were seeing was a real issue. We call this the inverse of productive dogfooding: rather than assume we are just like our users, we can just as easily decide we are nothing like them.
Have you ever had to support a WebRTC application and needed to get packet dumps from the user? Wireshark is a great tool for this, but asking a user to install it and make a dump rarely works. It’s just too complicated. So I was pretty excited when I read the Chrome 49 release notes which described (not in much detail) a new feature called the ‘RTC event log’. This is described as follows:
We now provide a new debug option in chrome://webrtc-internals for tracing internal details (e.g., BWE, jitter buffer state) for audio and video sessions. This option creates a log containing the timing and headers of packets as well as the timing of various internal events. We hope this will help resolve issues related to media transport and jitter buffers; attaching this log when reporting such issues will help us tremendously.
Set to be the largest hackathon in history , TokBox is proud to be sponsoring the Koding & Hacksummit hackathon, February 20-21. More than 25,000 teams will participate in the hackathon for a chance to win some amazing prizes.
Participants can use any publicly available API to create something that fits into the theme of data visualization, productivity or gaming.
When I’m working on developing an OpenTok application, I want to move fast. As a software engineer, I have loads of little workflow shortcuts, scripts, tricks, and favorite tools. When I started to build optk, I wanted to shave off just a couple seconds off of something that I had to do dozens of times a day.
2015 is notable in the number of sites that have been compromised by hackers, and the outlook continues to look grim. Companies have been rushing headlong into putting services online, prioritizing functionality above all. Up-time and scale, which has plagued early the early internet, while still a challenge, has improved significantly; however, security failures continue to get worse. This calls for a new approach. Application Security has been focused on vulnerability prevention, and static controls. In a world of continuous delivery, security needs to be continuous. In a world where hackers act faster than companies can patch, security needs to be adaptive, and responsive. What’s missing is defending the Application in production. This is Application Security’s Last Mile, and will be the focus of this talk.
Over the last 5 years, we’ve helped hundreds of companies create rich and engaging applications with OpenTok powered live video and voice. Now, we’re bringing broadcasters and brands (who are now broadcasters too) unprecedented audience engagement with the launch of our new Interactive Broadcast Solution.
Until now live broadcasting applications have focused on one-way streaming. This works well for conferences or events. But now, Interactive Broadcast is the first solution to enable multi-party panels, video-based audience participation, and an on-brand experience for website and application owners. The Interactive Broadcast Solution gives broadcasters the tools they need to bring user-generated content and viewer-participation content to both online and TV audiences.
Early December saw the roll-out of Chrome 47. When doing anything with WebRTC, this is always an interesting time. A release brings new features or may break things, like removing the getUserMedia functionality for insecure origins.
Our metrics clearly track such roll outs as seen below:
Today we’re excited to introduce the first WebRTC SDK for the AppleTV to support the next generation of endpoints – the television.
The rise of mobile, open sourced software and social networks has democratized content in every field from journalism to photography and video production. However, the last remaining battleground is the television, and Apple, with the new Apple TV, is blurring the lines between online and television, opening up all new possibilities for content creation and engagement. This marks not just another endpoint supported by TokBox, but the start of a new era of content creation that happens in the living room, which is why we’re prioritizing TV together with the web and mobile.
// < ![CDATA[
// ]]>GUEST POST: WebRTC.ventures is a custom design & development agency focused on building WebRTC applications. They are part of AgilityFeat, which is one of our development partners at TokBox. Jean Lescure from their team wanted to share their experiences using our new API for detecting call quality.
Back in August TokBox announced their new Pre-Call API, for testing out bandwidth conditions, and posted a repository on github with a proof of concept. At WebRTC.ventures we saw a great opportunity to build upon that project and got working on creating a demo app out of it, including a server implementation in NodeJS which is compatible with Heroku.
At our September TechTok WebRTC consultant and analyst, Tsahi Levent-Levi, came along to discuss the power plays of the video coding industry.
Just when we thought we were done with the video codec wars in WebRTC – we found out we’re only just beginning. Tsahi was here to talk us through some important questions – how is this WebRTC codec war going to play out? Where do the alliances lie? And where are we headed?
Watch the full video here: