Bug 281737 – getDisplayMedia() returns stream of a low resolution ignoring constraints

• Component: WebRTC
• Status: RESOLVED DUPLICATE

[Anastasiya Sarmant]

Created attachment 472981 [details]
Short video with a bug demonstration

Calls to getDisplayMedia() returns stream of a low resolution ignoring constraints.
 
for example:

       const displayMediaOptions = { "video": { "resizeMode": "none", "width": 1728, "height": 1080, "frameRate": 15 } };

        captureStream = await navigator.mediaDevices.getDisplayMedia(displayMediaOptions);
        document.getElementById("screenshare").srcObject = captureStream;
        const settings = JSON.stringify(captureStream.getVideoTracks()[0].getSettings());

Here 'settings' will be {"deviceId":"3E6AA6C93D8F10DF341CC4DE45F958D06218CE3D","displaySurface":"window","frameRate":15,"height":480,"width":640}

Interesting enough, putting a break point around the screen acquisition is working, the returned stream would be of a bit better quality.

There is no repro of Chrome or Edge.

This issue affects all the MS TEAMS web users on Safari who would ever try to share their screen.

I'm attaching a recording with and a code snippet https://jsfiddle.net/xd73t2s5/

[Anastasiya Sarmant]

It's an issue with track settings being unavailable right away.
The problem here that it doesn't even return the requested w/h, but some random numbers that are probably hardcoded. This messes up the stream scaling and encoding.

[youenn fablet]

I believe this is fixed in bug 280058.
The workaround is indeed to wait for the first video frame to reach the video track to get proper settings (rvfc or await video.play().

*** This bug has been marked as a duplicate of bug 280058 ***

[Madara Freimane]

This bug is still reproducible with Safari v18.1 (macOS 15.1).
- There is a 100% reproducibility for a bug when a Safari User joins a new call or re-joins an existing call and shares their screen for the first time: other desktop users see the incoming screen share as blurry, with poor quality first 10 seconds. If the Safari user re-shares their screen during the call, the issue might not reoccur.
- Bug is not reproducible for screen share preview (therefore, the issue cannot be reproduced with the Google WebRTC sample, as we can see the screen share preview with it, https://webrtc.github.io/samples/src/content/getusermedia/getdisplaymedia/).
- Bug is reproducible, if macOS/Safari User shares the screen and other call participants observe the incoming screen share from macOS/Safari User.

Tested devices and browsers:
- MacBook Air (M1, 2020, macOS 14.6 (23G80)) and Safari (Version 17.6 (19618.3.11.11.5))
- Macbook Pro (M1, 2020, macOS 15.1 (24B83)) and Safari (Version 18.1 (20619.2.8.11.10))
- Macbook Pro (M1, 2020, macOS 15.1 (24B83)) and Safari Technology Preview (Release 206 (Safari 18.0, WebKit 20621.1.3.21.1))

A new sysdiagnostics file available (recorded at 11:00 am, EET | Oct 30, 2024):
https://drive.google.com/file/d/181PGTAHXqOITdNUg7d0Gvy3LhqrnPkeH/view?usp=sharing

[Madara Freimane]

This bug is still reproducible with Safari v18.1.1 (macOS 15.1.1). See the previous comment, which contains more information about the issue.

Tested devices and browsers:
- MacBook Pro (M1, 2020, macOS 15.1.1 (24B91)) and Safari (Version 18.1.1 (20619.2.8.11.12))