Bug 236870 – Apple Silicon: Black screen share on remote side of peerconnection

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: WebRTC

[Venkatesh Devale]

Created attachment 452597 [details]
remote-inbound-rtp-video-stats-graphs-screenshot

Hello Team,

Problem
The screen sharing over a peer connection with presenter being on M1 Safari 14, 14.1.1, 14.1.2 results into a black and grey screen on the remote side.
I tested on a tweaked WebRTC official sample to test getDisplayMedia with peer connection setup and could reproduce the issue. The problem prominently appears only when the presenter is on M1 mac with Safari 14 versions and the remote attendees are on any browsers. Issue not observed in intel macs with Safari latest versions 15+. Not tested the M1 with latest versions and I wont be able to go back to older software easily.

Reproduction Steps:
1. Open the codepen below in Safari Safari 14, 14.1.1, 14.1.2 on a M1 mac.
https://codepen.io/ldttmt/pen/mNrJqK
2. Click on "start", this should start sharing your entire screen once permitted. The local first video should show the screen share fine.
3. Now click "call" and see whether the second video element shows the shared screen.
4. In Safari, the screen share remains black.

Tested on FF and Chrome on the same sample and it works fine as expected. The screen sharing video appears on the second video after step 3 above.

Attaching few screenshots from our app built using Amazon Chime SDK for JavaScript which is also seeing similar behaviors. I could pull in the WebRTC dump and when checked the stats from the remote attendee side in chrome://webrtc-internals find that the stats and graphs are pretty much blank for the remote inbound RTP video stream coming from the screen share. Not sure if this codec issue or if we are missing something here.

Test Machine:
- M1 Mac Mini, macOS Big Sur 11.1, Safari 14.0.2
- Reported issues by others on M1 with Safari 14.1.1 or 14.1.2
- Open GitHub issue: https://github.com/aws/amazon-chime-sdk-js/issues/1209

I could not find any open or closed bug around M1 screen sharing issues so could you please help us if there is a workaround or if there is any existing bug that is fixed in latest versions?

Possible Related bugs:
1. https://bugs.webkit.org/show_bug.cgi?id=228776
2. https://bugs.webkit.org/show_bug.cgi?id=213481

[Alexey Proskuryakov]

This appears to reproduce on M1 on macOS 12.2.1, with both shipping Safari and Safari Technology Preview.

[Radar WebKit Bug Importer]

<rdar://problem/89253918>

[Chris Cooksey]

This only happens if the video format is H.264. If the format is VP8, it works.

[youenn fablet]

Is it working if getDisplayMedia resolution is lowered?
This might be related to https://bugs.webkit.org/show_bug.cgi?id=229071.

[Venkatesh Devale]

So we do not have any resolution in constraints while calling `getDisplayMedia`. Here are the constraints:

{audio: false, video: {frameRate: {max: 15}}}

Could you please help me understand which resolution you are talking here?

[youenn fablet]

(In reply to Venkatesh Devale from comment #5)
> So we do not have any resolution in constraints while calling
> `getDisplayMedia`. Here are the constraints:
> 
> {audio: false, video: {frameRate: {max: 15}}}
> 
> Could you please help me understand which resolution you are talking here?

The resolution of the display MediaStreamTrack.
If you do something like {audio: false, video: {width: {max:1280}, frameRate: {max: 15}}}, would it work?

[Venkatesh Devale]

SO I tested with above suggested constraints and it is working for me from Safari to other browser. I have not updated the Safari or macOS yet as well.

```
{audio: false, video: {frameRate: {max: 15}, width: {max: 1280}}}
```

Thanks for providing the constraints. Well, couple of questions:

1. Do you know if this is a problem only on specific Safari versions on M1 especially or is there a fixed Safari version landed? Checking as we have to handle this behavior for all those version it seems.

2. Is 1280 a value to be used generally or depends on the size of screen? (I tested on a wide 2k monitor and it works fine with above constraints. ) I do not have a M1 macbook rather a Mac Mini which needs external display.

[youenn fablet]

> 1. Do you know if this is a problem only on specific Safari versions on M1
> especially or is there a fixed Safari version landed? Checking as we have to
> handle this behavior for all those version it seems.

I would think latest MacOS betas contain the fix.
Please have a try.

> 2. Is 1280 a value to be used generally or depends on the size of screen? (I
> tested on a wide 2k monitor and it works fine with above constraints. ) I do
> not have a M1 macbook rather a Mac Mini which needs external display.

The issue is that the M1 encoder is more strict about the H264 selected profile and how much pixels it can supports. 720p should be fine.

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