Despite the fact that filters are used a lot in non-WebRTC video applications like Photo Booth and SnapChat, we haven’t seen many WebRTC applications using these types of filters. This is probably because it hasn’t really been possible… until now.
It has always been possible to apply filters to video streams locally using the OpenTok platform by rendering the video into a Canvas element. The problem with this approach has always been that the person on the other end does not see the filter unless you apply the same filter on both the publisher and subscriber video. This would mean significant CPU load if you are subscribing to multiple participants. It also means that you don’t get to see the filters in the Archives.
I was talking with our old friend Philipp Hancke and discussing how it could be possible that 12% of the WebRTC calls were failing. This number came as a surprise to us as, based on our reports, the number of failures is significantly lower when it comes to OpenTok calls, even though the exact numbers depend on the specific use case you have.
So, we decided to grab some data and try to prove that WebRTC, at least in our platform, is doing a much better job.
When evaluating a new product or service, we know how important it is to be able to test out the technology first. Stakeholders in different areas of the business, both developers and non developers, need to see and understand how the technology works.
We’ve noticed that for customers evaluating the OpenTok platform, without using the API, it can be challenging to visualise your use case. Even when a developer works through our Quick Start Guide, there can be a need for additional implementation to build a custom proof of concept. All of this translates into time invested during the business’ evaluation phase of the product; worse yet, it can lead to an incomplete or inaccurate evaluation.
Web Application Developers are used to being able to write automated tests for their applications and have them run with every PR and before deploying to production to give a level of confidence that things are not broken. OpenTok and real-time applications in general present new challenges when it comes to writing and running automated tests. There are challenges when it comes to getting access to microphones and cameras, testing multiple participants and installing the plugin for Internet Explorer among others.
There has been lots of work around WebRTC testing automation and our friends at rtc.io and &yet have written some great articles on the subject. However these articles don’t cover some of the specifics of testing OpenTok applications for example testing Internet Explorer and installing the OpenTok plugin for Internet Explorer. If you haven’t already I would recommend taking some time to read the articles by the folks at rtc.io and &yet before coming back to this. Also if you’re not familiar with Travis and Selenium WebDriver you might want to check those out too.
Since we launched the new version of our platform back in 2012, one of our goals has always been to make it very easy to manage and understand how your applications are performing. In addition to simplifying how to build applications, we believe that those are the key elements for a great experience.
Over the last year we have been working on a completely new way to interact with your TokBox account. As our user-base grew and diversified, it was obvious that our previous dashboard was not enough and needed to be extended. With the number of new tools and services that are in the works, we realized that it was a good opportunity to future proof our stack and give you, our users, a much better experience.