Safari Compatibility (**Testing / Work In Progress**)

j1elo commented 6 years ago

Safari compatibility is a Work In Progress. Don't expect correct functionality until support is officially announced in the community forum and in the project's blog.

Safari compatibility testing & Demo application

I've just uploaded a new version of the test application for Safari. In this new version it's included all learned knowledge about what is needed for both Desktop Safari and especially iOS Safari. Access the test application here: https://apple.openvidu.io/

For developers, there is also a summary guide/troubleshoot document where the most important details about Safari support are explained. See here: https://docs.google.com/document/d/1gbhJxZEIzSQR5yHwWXgQw_UxCjhJSc8_BEmYgChP8DI/edit?usp=sharing

Demo application instructions

Open https://apple.openvidu.io/
Start the demo.
Grant access to the webcam.
The local stream should appear shortly.
The remote stream tends to take a while to appear in my test Macbook. Sometimes even 2 minutes!
If there are any issues, take note of your User Report ID and post a comment here to let us know. I'll use that Report ID to collect some system & browser information that get automatically generated in our application server (not publicly accessible).

I have implemented all the iOS video autoplay guidelines as explained in the linked article, and I hope those are enough to remove any video playback protection that could be triggered on iOS Safari; if there is still any autoplay restriction (such as an overlay with a big "Play" triangle over each one of the Local and Remote stream videos), please let me know.

Also, seems that there are serious video decoding compatibility issues, and one symptom of this is that the demo goes to the state CONNECTED, media is flowing but still no image appears in the remote video, and it never gets to the PLAYING state.

User Report details

The new version of this test application collects some interesting data points which allow to identify the exact device model and version numbers of Safari. It also collects all SDP Offer/Answer negotiations, and ICE candidates which could aid in analyzing why the WebRTC call failed during a test.

Other links and resources

Related forum threads:

Related bugtracker issues:

186

fishg commented 6 years ago

Safari is funny. I have do some test.

if receive a stream, just bundle to a video element, may not play, even set playsinline and autoplay and 'muted' attr.
base on 1, when receive a stream, we add a alert, video.srcObject = stream; video.play(); alert('ok') , stream will play soon.
alert is not friendly, so I test an other way, replace alert with request media device permission, looks like that a user click event will active video play.
if a video already played, not need alert or request permission again, remote stream can directly bundle to a video and play.

if (navigator && navigator.userAgent && navigator.userAgent.indexOf("Safari") > -1 && navigator.userAgent.indexOf("Chrome") < 0 ) {
            if (!this.permission) {
                //safari 如果没有请求过设备权限，连接收都不行，hack下
                this.permission = true;
                if (navigator.mediaDevices && navigator.mediaDevices.getUserMedia) {
                    navigator.mediaDevices.getUserMedia({ video: true })
                        .then(function (stream) {
                            setTimeout(() => {
                                stream.getTracks().forEach(track => {
                                    track.stop && track.stop()
                                });
                            }, 5000);
                        })
                        .catch(function (err) {
                            YMLogUtils.LOGI(err);
                        });
                }
            }
        }

haualan commented 6 years ago

I found something interesting too for safari 11, I can kind of understand why Apple did this, because they don't want a loophole to allow ads to start playing videos on their own:

ref: https://bitmovin.com/play-not-play-new-autoplay-policies-safari-11-chrome-64/ https://developer.apple.com/library/archive/documentation/AudioVideo/Conceptual/Using_HTML5_Audio_Video/AudioandVideoTagBasics/AudioandVideoTagBasics.html

There is an easier HTML5 change that can be used which will play the video when the user clicks the play button, just add the "controls" attribute to the video tag:

`

Otherwise, as the apple docs suggested, if you don't want to use the controls attribute then code a play button in JS to explicitly pass control to the user.

Kurento / bugtracker