312472 2026-04-16 07:05:19 -0700 Safari WebRTC screen sharing via getDisplayMedia starts at extremely low quality and takes ~30 seconds to become legible for remote participants 2026-05-12 04:46:42 -0700 1 1 1 Unclassified WebKit WebRTC Safari 26 Mac (Apple Silicon) macOS 26 RESOLVED FIXED InRadar P2 Normal --- 1 the youennf webkit-bug-importer youennf oldest_to_newest 2201050 0 the 2026-04-16 07:05:19 -0700 Environment: macOS 26.4 (fresh install) Safari (latest shipping version) MacBook Pro 14-inch, November 2023, Apple M3 Pro, 18 GB RAM Steps to reproduce: Open Google Meet in Safari on the above hardware Join a meeting with at least one remote participant Share your screen (full screen or window) Have the remote participant observe the shared screen quality Expected result: Screen share should be legible to remote participants within 1–2 seconds, as it is when using any Chromium-based browser on the same machine. Actual result: The shared screen appears extremely blurry/pixelated to all remote participants and takes approximately 30 seconds to become legible. This occurs regardless of the remote participant's OS, browser, or device. Isolation testing performed: Tested on Ethernet (1 Gbps upload), Wi-Fi 6 GHz, 5 GHz, and 2.4 GHz — no difference Tested with upload bandwidth ranging from 40 Mbps to 1 Gbps — no difference Tested with all other applications closed — no difference Tested across multiple remote participants on macOS, Windows, and ChromeOS using various browsers — all observe the same blurry output Tested on the same machine, same network, same meeting using Google Chrome, Ungoogled Chromium, and Brave — screen share is instantly clear and legible in all three Assumption: The issue appears to be in WebKit's WebRTC encoding path for screen capture content. Chromium-based browsers aggressively allocate bitrate for screen share tracks and leverage content-type hinting to prioritize sharpness over framerate. Safari's implementation appears to use a much more conservative bitrate ramp-up, and may not be optimizing the H.264 encoding for static/text-heavy screen content the way Chromium optimizes VP8/VP9 with screen-content mode. This effectively makes Safari unusable for professional screen sharing in browser-based conferencing. Related: bug 235030. 2203678 1 webkit-bug-importer 2026-04-23 07:06:13 -0700 <rdar://problem/175425085> 2207642 2 youennf 2026-05-05 06:27:54 -0700 I would recommend to use degradationPreference maintain-resolution until WebKit uses that by default for screenshare. This should be anyway the preferred approach. 2207649 3 youennf 2026-05-05 06:55:29 -0700 Pull request: https://github.com/WebKit/WebKit/pull/64267 2210093 4 ews-feeder 2026-05-12 04:46:40 -0700 Committed 313072@main (469467e53afb): <https://commits.webkit.org/313072@main> Reviewed commits have been landed. Closing PR #64267 and removing active labels.