somethin got broken between in webrtc Chrome => Safari

[sulphur]

Hi,

I've encountered a strange issue that I have never seen before. Yesterday I've noticed that when I publish my webrtc stream from Chrome it plays OK everywhere except for Safari iOS. I tried reverting to old code and old WCS / SDK versions from 3 months ago where all was good but it didn't help. When I try the basic Player/Streamer example Chrome to Safari works ok. However, when I try the "Media Devices" examples there I can reproduce the exact issue which is webrtc Chrom published stream in iOS Safari that plays at 1 FPS. By the way, the same stream on HLS works fine, only webrtc payback is affected and only when publishing from chrome. I've done a little GIF to illustrate the frameskip in safari ios.

Gyazo Screen Video

gyazo.com

For more info last week apple released ios critical fix in ios 14.4.2 where they fixed a critical security issue in safari iOS so maybe that broke something I don't know. It has been a while since I have tested ios safari and I don't have access to the previous versions anymore.

best regards
Piotr

 

[sulphur]

oh and I forgot to add that audio is ok only video is affected

 

[sulphur]

I've found a way around. It would seem that it happens when Chrome is sending h264 to Safari. Stripping h264 and using vp8 is a way around to fix the issue. However, it is normal? Or is it something that needs to be fixed? I already streamed h264 via webrtc from Chrome to Safari in the past( i was required to do some sdp munging).

 

[Max]

Good day.
We cannot reproduce the issue using WCS build 5.2.926 and WebSDK build 2.0.166. A stream publihed in Chrome 89 (Wndows 10, Mac OS 11.1) using Media Devices example (H264, 640x480, 30 fps) is successfully playing in iOS Safari (iOS 14.3) using Media Devices.
It may be iOS 14.4.2 issue. We updating test device to check this.

Stripping h264 and using vp8 is a way around to fix the issue.

Please clarify: do you strip H264 on publishers side or on players side? The first means you're publishing VP8, the second means you're transcoding H264 to VP8 on server.
Also, please confirm: is Two Way Streaming example works both for publisher and player? If yes, please try to set publishing resolution to 320x240 (this is default for Two Way Streaming) in Media Devices example and check again. If stream is playing successfully with lower resolution, it may be player channel issue.

 

[Max]

We cannot reproduce the issue in our test environment witn iOS 14.4.2 too. So it seems like player channel issue, for example H264 publishing bitrate is too high. Please check Nack Count and Packets Lost video metrics on players side. If they grows, it is definitely channel bandwidth/quality. Please try to switch to TCP transport, it may help in this case.

 

[sulphur]

I strip h264 on the publisher side. So yes publishing with vp8 works fine.

For info, I'm testing on the local network at home and I'm on Mac os with the latest Chrome, Safari, MacOs, WCS, WCS Web SDK etc. WCS is running on a linux machine under the docker container on my secondary PC(4-core intel i7).
I have also WCS running on my staging on digital Ocean and I have the same issue there.

As for Packet loss and Nack Count both are at 0 in player and publisher. (TCP player on my local network doesn't work i don't know why)

So I did a check with the resolution and indeed when I use 320x240 the video is "smooth" however on 640x480 is laggy. I don't think it is a transcoding issue because in Safari it pays h264 as well ( and anyways CPU on WCS machine is at 5%) so for me, there is no transcoding happening there. That is why I'm thinking that it might be the issue with h264 profile levels between Chrome and Safari. If I recall I had to force the "42e01f" which is the Base profile on other projects because in safari in sdp for some strange reasons profiles were set to high (64c029 fo ex.) and there was no base profile in sdp.

 

[sulphur]

And I forgot to mention that the publishing from Safari or Firefox on 640x480 via h264 plays perfectly fin on ios Safari.
And Chromium on linux is also fine

 

[sulphur]

Ok, It might be something wrong with my Chome, I just tester on my wife's mac ( it was High Sierra, however ) and there I didn't have the issue with h264.

 

[sulphur]

Ok, so i've narrowed it down to 1 option. If in my Chorme i disable the "Use hardware acceleration when available" then it all works fine. however with hardware acceleration enabled it lags... so purly issue with my chorme.

Anyways now it is all good. Thanks for your help

 

[Max]

Please try to add the following setting

h264_strict_kframe_detect=true

This should work with hardware acceleration in theory.
Also you can exclude high and main profiles from SDP:

webrtc_sdp_h264_exclude_profiles=4d,64

If nothing of those tweaks help, disable hardware acceleration.

 

[sulphur]

I've tried but none of them helped with HA on. For now, it seems that only my MacBook is affected so I will test more configurations and in a worst-case scenario, I will publish vp8 when in chrome. Or even vp8 all the time. It uses more CPU since it lacks HA but It has temporal scalability so it can be a good trade-off.

Thank you for your help