The `resizeMode: "none"` together with `width`, `height` and `frameRate` constraints makes us ignore the `width`, `height` and `frameRate` ones, which seems to be the culprit. I assume we exceed some threshold in the SFU which then cuts us out. Chrome appears to ignore `resizeMode: "none"` for `getDisplayMedia` which explains a bit. We could do an intervention to set `media.navigator.video.resize_mode.enabled` to `false` for teams.microsoft.com (and teams.live.com ?), but -- We do have a slight bug 1286945 regression for when the `media.navigator.video.resize_mode.enabled` pref is `false` where we used to default to 30fps capture but now do 60fps. That could have an impact on bitrate for instance, because we did see some cases while testing that led to a frozen screen capture remotely, with the pref flipped in Nightly.
Bug 2000906 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
The `resizeMode: "none"` together with `width`, `height` and `frameRate` constraints makes us ignore the `width`, `height` and `frameRate` ones, which seems to be the culprit. I assume we exceed some threshold in the SFU which then cuts us out. Chrome appears to ignore `resizeMode: "none"` for `getDisplayMedia` which explains a bit. We could do an intervention to set `media.navigator.video.resize_mode.enabled` to `false` for teams.microsoft.com (and teams.live.com ?), but -- We do have a slight bug 1286945 regression for when the `media.navigator.video.resize_mode.enabled` pref is `false` where we used to default to 30fps capture and allow framerate decimation but now do 60fps always. That could have an impact on bitrate for instance, because we did see some cases while testing that led to a frozen screen capture remotely, with the pref flipped in Nightly.