Bug 312472
| Summary: | Safari WebRTC screen sharing via getDisplayMedia starts at extremely low quality and takes ~30 seconds to become legible for remote participants | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | the |
| Component: | WebRTC | Assignee: | youenn fablet <youennf> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | webkit-bug-importer, youennf |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari 26 | ||
| Hardware: | Mac (Apple Silicon) | ||
| OS: | macOS 26 | ||
the
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
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.