Safari, from version 11, on macOS and iOS is supported in twilio-video.js 1.2.1 and greater. Earlier versions of Safari are not compatible with twilio-video.js because they do not support WebRTC.
Safari, from version 12.1, includes support for VP8 and VP8 simulcast. twilio-video.js 1.2.1 will automatically offer VP8 when supported by Safari. However, if you are looking at adding VP8 simulcast on Safari 12.1+, twilio-video.js 1.17.0 or higher is required.
The rest of this document discusses best practices for Safari < 12.1 as those versions do not include VP8.
Programmable Video uses WebRTC, a standard set of browser APIs for real-time audio and video in the browser. Chrome, Firefox, Edge, and Safari web browsers all support WebRTC APIs, but each has its own nuances.
When it comes to video encoding, Chrome, Edge, and Firefox support two video codecs: VP8 and H.264. Safari only supports H.264 today. This means that other browsers and mobile apps must send H.264-encoded video if they want Safari users to see the video tracks they share.
Our goal is to make it so that you don't need to worry about codec selection, but there are a few things you'll want to know as you plan support for Safari < 12.1 in your application.
If your app uses Peer-to-Peer Rooms, the codec selection should be seamless: Chrome and Firefox both support H.264, and will automatically send and receive H.264 video tracks to any Safari < 12.1 users who join the Room.
If you ship a native mobile version of your app and use Peer-to-Peer Rooms, you'll need to use version 2.0.0-preview1 of our iOS or Android SDK to send and receive H.264 in a Peer-to-Peer Room. Earlier versions of our native SDKs will not be able to send or receive video to Safari < 12.1 devices, because they do not support H.264.
You can use the codec preferences API to force the browser to use a specific video codec.
If your app uses Group Rooms, you'll need to make a decision about how you want to support Safari < 12.1.
In most cases, you'll want Safari < 12.1 to be able to receive every video track shared in the Room. To do this, you can force all Participants to send only H.264-encoded video by creating the Room with the option VideoCodecs=H264:
1curl -XPOST 'https://video.twilio.com/v1/Rooms' \2-u 'SKXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:your_api_key_secret' \3-d 'UniqueName=MyH264Room' \4-d 'Type=group' \5-d 'VideoCodecs=H264'
When this option is set, all endpoints must use H.264 codec when participating in the Room. See the Rooms REST API for more information.
We've added support for H.264 codec in our Android and iOS SDKs starting at version 2.0.0-preview1. If you ship a native mobile version of your app, and you want it to be able to talk to Safari, you'll need to update to 2.0.0-preview1 or higher.
Keep in mind that if you create Rooms with only H.264 support as described above, apps running earlier versions of our mobile SDKs will not be able to connect.
Keep this in mind especially while you're developing your app and testing locally--you'll need to use a second browser if you want to test bi-directional video on your local machine.
Your site must be served over HTTPS in order to access the user's microphone and camera. This can make development difficult, so see the tips below for details.
If you're building a video app for Safari users, we recommend downloading the Safari Technology Preview. The Technology Preview release has some additional options that make development and debugging a bit easier-you can find the options under the menu Develop > WebRTC.
A couple of useful options:
Read more about developing WebRTC applications for Safari < 12.1 on the WebKit blog.