1760843 - Frame rate produced by getDisplayMedia went up unexpectedly on Windows

Status: RESOLVED FIXED

(Core :: WebRTC, defect, P1)

Description

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

+++ This bug was initially created as a clone of Bug #1759734 +++

(note I cloned the above bug about Firefox no longer respecting the frameRate constraint when passed by an application, to report a related symptom)

What appears to have "regressed" at the same time is that the unconstrained frame rate produced by getDisplayMedia went up, from around ~22 fps of a youtube window on Windows 10 to ~30 fps.

This is faster than Chrome (which is at around 17 fps). While this might sound good (whoo speed!) this discrepancy might have bad side effects, like use of more bandwidth, which could lead poorer degradation when available network bandwidth is low (causing symptoms like poor resolution compared to Chrome) since frame rate can't be curbed anymore apparently.

STRs are in bug 1760050 comment 3.

Comment 1

[Nico Grunbaum [:ng, @chew:mozilla.org]]

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #0)

+++ This bug was initially created as a clone of Bug #1759734 +++

(note I cloned the above bug about Firefox no longer respecting the frameRate constraint when passed by an application, to report a related symptom)

What appears to have "regressed" at the same time is that the unconstrained frame rate produced by getDisplayMedia went up, from around ~22 fps of a youtube window on Windows 10 to ~30 fps.

This is faster than Chrome (which is at around 17 fps). While this might sound good (whoo speed!) this discrepancy might have bad side effects, like use of more bandwidth, which could lead poorer degradation when available network bandwidth is low (causing symptoms like poor resolution compared to Chrome) since frame rate can't be curbed anymore apparently.

STRs are in bug 1760050 comment 3.

This can cause a drop in perceived quality in low motion scenarios.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1729367

Comment 3

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Attachment: Bug 1760843 - P0 - fix desktop capture frame timing;r?jib

Comment 4

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Attachment: Bug 1760843 - P1 - add WPT for gDM frameRate:max;r?jib

Depends on D141937

Comment 5

[Dianna Smith [:diannaS]]

:ng is this something that can land or are we waiting on the dependent bug?

Comment 6

[Nico Grunbaum [:ng, @chew:mozilla.org]]

diannaS, this fix uncovers a threading deadlock issue. Further work is being done here.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d4b6bfda83c5
P0 - fix desktop capture frame timing;r=jib
https://hg.mozilla.org/integration/autoland/rev/198b1e078f7e
P1 - add WPT for gDM frameRate:max;r=jib

Comment 8

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/34078 for changes under testing/web-platform/tests

Comment 9

[Sandor Molnar[:smolnar]]

Backed out 2 changesets (bug 1760843) for causing wpt failures in /screen-capture/getdisplaymedia.https.html

Backout link: https://hg.mozilla.org/integration/autoland/rev/9d4ff58359c27c213153f1cc9e9d523212d0d888

Push with failures

Failure log

INFO - TEST-PASS | /screen-capture/getdisplaymedia.https.html | getDisplayMedia() must require user activation 
[task 2022-05-16T21:09:59.776Z] 21:09:59     INFO - TEST-UNEXPECTED-FAIL | /screen-capture/getdisplaymedia.https.html | getDisplayMedia() must adhere to frameRate if set - assert_less_than_equal: expected a number less than or equal to 7.5 but got 8.359253499222396
[task 2022-05-16T21:09:59.776Z] 21:09:59     INFO - @https://web-platform.test:8443/screen-capture/getdisplaymedia.https.html:55:25

Comment 10

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Upstream PR was closed without merging

Comment 11

[Nico Grunbaum [:ng, @chew:mozilla.org]]

I am investigating this. The fix in this bug was specifically for Windows. The failing test was added in this patch. It may have been that macOS will require its own fix, and this test may need to be disabled for macOS in the mean time.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1e5c9e81a56e
P0 - fix desktop capture frame timing;r=jib
https://hg.mozilla.org/integration/autoland/rev/285d75d53b7a
P1 - add WPT for gDM frameRate:max;r=jib

Comment 13

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/1e5c9e81a56e
https://hg.mozilla.org/mozilla-central/rev/285d75d53b7a

Comment 14

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.

Comment 16

[Ryan VanderMeulen [:RyanVM]]

Is this something we should consider for uplift to 101 still this cycle (RC week is next week) or can this ride the 102 train?