Hello there! After so much work and testing we are glad to finally announce Apple support for OpenVidu. This is a big step in our range of client supported platforms. How have we achieved this?
Safari
This was basically a matter of adapting our openvidu-browser library to the many specificities of Apple’s browser. In fact, no server-side changes were needed at all. Simply lots of testing involving Macs, iPhones and iPads in cross-platform video sessions with other supported platforms.
iOS
First of all, Safari on iOS works as well as Safari on Mac OS, so your users will also be able to connect to your OpenVidu web app through their browser on iPhones and iPads. Secondly, we have brought iOS native support through Ioinc.
Last 2.6.0 release added OpenVidu support for Ionic apps in Android, but due to limitations on Apple’s WebView (for some reason Apple decided to make WebRTC stack not available), we couldn’t get our Ionic tutorial working in iOS devices. This has changed thanks to a iosrtc plugin. Getting it to work is a little bit tricky, but we have everything explained in our updated openvidu-ionic tutorial. Check it out here!
Some clarifications about Safari
There are two things to consider when adding Safari support to your OpenVidu applications:
- Safari has a special autoplay policy that in some cases will cause some videos to not start playing automatically. This is an issue easy to handle and you can learn how in Troubleshooting section of OpenVidu docs.
- If there are gonna be other types of clients rather than Safari connecting to the same session, then transcoding will be necessary in OpenVidu Server. This may bring up CPU load significantly. This behavior is due to Safari not supporting any other codec than H264, when rest of platforms usually prefer VP8. Good news is this is a problem that will soon fix on its own: Safari will support VP8 in the near future (see Release 68 Notes)
Other improvements
We have added a brand new event for openvidu-browser called streamAudioVolumeChange. It allows you to listen to volume changes in your local or remote videos. Learn more here.
And finally of course we have taken care of many issues to increase the platform stability, both in our server side and our client side:
- OpenVidu 2.7.0 incorporates latest Kurento release, which brings many patches that should improve overall video sessions performance.
- Recording layout now internally hides cursor (no need of styling the layout with
cursor:none). Issue #138 - Recording stopping process reinforced to terminate and gracefully generate video files for failed recording containers (those that do not receive any video from the session caused by a misconfiguration or a wrong custom recording layout). This will help getting rid off dead containers and keeping OpenVidu Server clean. Issue #148
- Mirroring local video fix: when changing to screen-share, local video is now un-mirrored, and viceversa. Issue #13
- Sessions configured with
Recording.MANUALnow automatically stop their recording if last participant left the session and no user published to the same session in 2 minutes. Issue #149 Publisher.publishAudioandPublisher.publishVideomay be called without having initialized a Session or having calledSession.publish(Publisher)
And what’s next?
Past months we have reached in our platform the level of maturity necessary to face the development of the environment and cloud-infrastructure that will allow us to take OpenVidu to the limit in terms of number of users and network conditions. These load test scenarios will help us deal with real world conditions and simulate really large video conferences, that in the end will guide us in our way to achive 100% automated scalability and fault tolerance.
The development of this kind of set up for OpenVidu has been (and is being) so wonderfully interesting and instructive that a future post will surely address the entire process and our preliminary results when taking the platform to its limits.
