Bug 262298 – [WebRTC] Video from safari is freezing and video quality is bad overall

• Component: WebRTC
• Status: RESOLVED CONFIGURATION CHANGED

We noticed webrtc issues from safari 17 (only on MacOs 14)
Video from safari is freezing (sometimes is pixelating or fps drops to 1-2 frames or very big delay).
The interesting thing that it is only reproducing when peer connection established is between 2 pc (e.q. in local network) or connection goes through SFU.
Also when look to statistics "inbound-rtp" from safari in remote client (I've used chrome) I noticed that nackCount is constantly grows (or freezeCount and totalFreezesDuration as well)

There are few ways to try this:

1) 
Open https://janus.conf.meetecho.com/videocalltest.html?simulcast=true  
sometimes it is not reproduces right after joining so u need to rejаoin or/and play with selecting spatial layers

(I'm using "simulcast=true" link here only to increase chance for reproducing the issue but it is reproducible with https://janus.conf.meetecho.com/videocalltest.html as well)

2)
use jitsi meet (https://meet.jit.si/)

I've used 2 participant 
- safari from macos 14
- chrome from another pc

so in this case when open chrome://webrtc-internals/ I noticed that connection is p2p between two devices inside local network "ICE Candidate pair: 192.168.3.96:60545 <=> 192.168.3.89:52498"
but still I see nackCount and freezeCount are constantly grows and video quality from safari is not good at all.

3) 
use https://v3demo.mediasoup.org/ 
from different devices - same symptoms

4)

https://web.skype.com

just call someone - same symptoms


Some notes about this issue:
- if I connect macbook via wired network issue almost disappears sometimes (or it becomes harder to reproduce), so network connection somehow affect this
- if I try chrome on the same machine I don't see any problem

Devices I tried (where I can reproduce this issue):
- Macbook Pro 16, 2019 (Intel) MacOs 14.1 beta Safari 17.1
- Macbook Pro 14, 2022 (M1 Pro) MacOs 14.0 Safari 17 (not beta, release version)
- Macbook Pro 14, 2023 (M2 Max) MacOs 14.1 beta Safari 17.1
- Macbook Air M1, 2021 MacOs 14.0 Safari 17 (not beta, release version)


Issue is not reproducible on MacOs Ventura (13.6) Safari 17 (so I dare to assume that it is only on MacOs Sonoma 14)

[Radar WebKit Bug Importer]

<rdar://problem/116177254>

[youenn fablet]

@Ivan, are you able to check remote inbound rtp stats and see whether you see increasing packetsLost?

[youenn fablet]

This might be the same issue as rdar://112043387

(In reply to youenn fablet from comment #2)
> @Ivan, are you able to check remote inbound rtp stats and see whether you
> see increasing packetsLost?

Yes, packetsLost is increasing in remote inbound rtp stats.

[Mike Beale]

Hi,
does anyone have any further information on this? We are experiencing similar with our webrtc solution, only with Safari 17. 

We are using a media proxy, and see this generating a series of NACKs back to Safari 17 when possibly network conditions aren't ideal. We are wondering if there's some issue with the way that Safari 17 is handling NACKs? (We don't see the same sort of video freezing in Chrome, Safari 16 etc.)

Any information greatly received!

[Kaustav]

Created attachment 469442 [details]
Wireshark dump(encrypted packets) of Safari video sender

We have seen this problem a lot recently while running Microsoft Teams call on Safari.

For example, we ran a P2P call between Safari and Chrome. Here the Safari client is the video sender and Chrome client is the video receiver. I have attached a wireshark dump captured on the Mac (Safari video sender). In the pcap, payload type 116 is for video and payload type 117 is for RTX. There you can see a lot of video packets are missing, i.e., packets are dropped by Safari before they reach the network. Due to this, a lot of NACKs are received/RTX are sent. If the round-trip time is small enough the resends from the NACKs arrive just a bit late. For higher latencies, this may cause video freezes. 

It might be caused by too small send buffer in Safari. @youenn could you please take a look?

[Kaustav]

Created attachment 469443 [details]
RTP dump from Chrome video receiver(unencrypted packets)

Also attaching the RTP dump of the Chrome video receiver side

[Kaustav]

To be more explicit, in the RTP dump of Chrome video receiver, it has the first NACK in packet 3. The NACK pid is for RTP packet with seq 4134. The RTP packet with seq 4134 is not there in the RTP dump of Safari video sender, i.e., dropped by Safari before sending it out to network.

This missing packet should have the RTP timestamp 1049679440. Filtering for that in receiver's pcap, shows a couple of PT=117 (rtx). The first one is packet 11 which has a payload starting with 0x1026 or 4134.

[youenn fablet]

This should be fixed in latest macOS Sonoma beta 14.3.
Could you have a try?

[youenn fablet]

FWIW, this should be resolved by rdar://112043387.

[Kaustav]

@youenn We have tested this on Safari v17.4/MacOS v14.4 and we still see the problem in some calls. Could you please take a look?