Bug 312472 – Safari WebRTC screen sharing via getDisplayMedia starts at extremely low quality and takes ~30 seconds to become legible for remote participants

• Status: RESOLVED
• Resolution: FIXED
• Component: WebRTC

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.

[Radar WebKit Bug Importer]

<rdar://problem/175425085>

[youenn fablet]

I would recommend to use degradationPreference maintain-resolution until WebKit uses that by default for screenshare.
This should be anyway the preferred approach.

[youenn fablet]

Pull request: https://github.com/WebKit/WebKit/pull/64267

[EWS]

Committed 313072@main (469467e53afb): <https://commits.webkit.org/313072@main>

Reviewed commits have been landed. Closing PR #64267 and removing active labels.