Bug 262298

Summary: [WebRTC] Video from safari is freezing and video quality is bad overall
Product: WebKit Reporter: ivan.zahrodskyi
Component: WebRTCAssignee: Nobody <webkit-unassigned>
Status: RESOLVED CONFIGURATION CHANGED    
Severity: Critical CC: kagh, karlcow, mike.beale, webkit-bug-importer, youennf
Priority: P2 Keywords: BrowserCompat, InRadar
Version: Safari 17   
Hardware: Mac (Apple Silicon)   
OS: macOS 14   
Attachments:
Description Flags
Wireshark dump(encrypted packets) of Safari video sender
none
RTP dump from Chrome video receiver(unencrypted packets) none

Description ivan.zahrodskyi 2023-09-28 04:31:23 PDT 
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)
Comment 1 Radar WebKit Bug Importer 2023-09-28 05:14:41 PDT 
<rdar://problem/116177254>
Comment 2 youenn fablet 2023-09-28 05:25:33 PDT 
@Ivan, are you able to check remote inbound rtp stats and see whether you see increasing packetsLost?
Comment 3 youenn fablet 2023-09-28 05:25:51 PDT 
This might be the same issue as rdar://112043387
Comment 4 ivan.zahrodskyi 2023-09-28 05:32:18 PDT 
(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.
Comment 5 Mike Beale 2023-12-22 03:51:04 PST 
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!
Comment 6 Kaustav 2024-01-18 03:44:42 PST 
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?
Comment 7 Kaustav 2024-01-18 03:46:27 PST 
Created attachment 469443 [details]
RTP dump from Chrome video receiver(unencrypted packets)

Also attaching the RTP dump of the Chrome video receiver side
Comment 8 Kaustav 2024-01-18 04:20:59 PST 
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.
Comment 9 youenn fablet 2024-01-18 04:34:15 PST 
This should be fixed in latest macOS Sonoma beta 14.3.
Could you have a try?
Comment 10 youenn fablet 2024-01-19 02:56:28 PST 
FWIW, this should be resolved by rdar://112043387.
Comment 11 Kaustav 2024-02-08 06:55:23 PST 
@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?