OpenTok version 2.15: What’s new and how you can use it

Last week, we released OpenTok v2.15, the latest version of our Client SDKs. We wanted to update you on some of the great new features included and how you can use them.

Audio Enhancements in Web and Windows SDKs

In opentok.js 2.14 we added the ability to switch cameras using the Publisher cycleVideo() method which was really well received. Version 2.15.0 of opentok.js and our Windows SDK add the ability to switch to a different audio source. In opentok.js you do with using the Publisher setAudioSource() method and in Windows you use the AudioDevice.SetInputAudioDevice method. The obvious use-case for this API is to allow your users to switch microphones without needing to create a whole new publisher. But it can also be used to switch to other supported audio sources, for example loading audio from an audio file, or creating custom audio. In opentok.js you do this using the setAudioSource() method and passing a custom audioTrack. In the Windows SDK you do this using the AudioDevice.setCustomAudioDevice method and passing a custom audio driver.

To get a better idea how to use cycleVideo(), setAudioSource() and the AudioLevelUpdatedEvent in your web application using opentok.js have a look at the new Publish Devices sample application

We also brought some other new audio features to our Windows SDK with v2.15.0 to bring it inline with our other SDKs. The Windows SDK now supports stereo audio through the stereo argument to the Publisher constructor. We have also added the AudioLevel event to the Publisher and Subscriber which lets you know the amount of audio activity.

Handling Multiple Video Codecs in Web and Android SDKs

With opentok.js v2.12 we added support for Safari and along with it support for the H.264 codec. When working with H.264 there are some cases where it is not going to work and as a developer you would like to know this in advance so that you can tell your customers to use a different browser or device. With 2.15.0 we have solved this with the getSupportedCodecs API. This API is available in opentok.js and in our Android SDK where there are cases that H.264 or VP8 might not be supported.

Publisher Stats on iOS, Android and Windows

In opentok.js v2.13 we added the Publisher Stats API. With v2.15 we have brought this API to our iOS, Android and Windows SDKs as well.

This API gives you information about network statistics for audio and video such as packets lost and packets received. It allows you as a developer to get an insight into the quality of the end users network connection so that you can provide them feedback. We already had a similar API available on the Subscriber side but the addition of this API on the Publisher side completes the picture so that you know what the upstream network looks like.

For more information have a look at our documentation for the feature:

Share your screen in Chrome without an extension

Chrome 70 allows screen sharing without an extension, using the MediaStream.getDisplayMedia() method. We are really excited about this feature. This is a huge step towards making screen-sharing even easier, both to implement and to use. This feature is still hidden behind a flag in Chrome so to try it out you will need to go to chrome://flags in Chrome 70+ and select the “Enable Experimental Web Platform Features” flag. We anticipate that this feature will be enabled by default in future stable versions of Chrome (and Opera).

Vulnerability in the Plugin for Internet Explorer

In opentok.js version 2.15.0 we fixed a vulnerability in the plugin for Internet Explorer. We recommend that all of our customers update to this latest version of opentok.js to fix this issue.

Other bug fixes and performance improvements

  • x86_64 architecture – Our Android SDK now supports the x86_64 architecture so that it can support wearables like the Vuzix M300.
  • IP Whitelist Flag – Enterprise partners that have IP white listing enabled for an OpenTok project should now set the new ipWhitelist parameter of the Session. This lets us know to make sure we are loading only from servers within that whitelist range. We have added this setting to all of our Client SDKs.
  • PreferredFramerate and PreferredResolution – We have brought our PreferredFramerate and PreferredResolution settings to the Windows SDK. The Subscriber.PreferredFramerate and Subscriber.PreferredResolution properties let you set the preferred frame rate and resolution for a subscriber’s stream. This setting only applies to subscribers in a routed session.

For a full list of the features and fixes in our client SDKs have a look at the release notes.