Open Bug 1759734 Opened 7 months ago Updated 4 months ago

Issue with frameRate constraint for getDisplayMedia

Categories

(Core :: WebRTC, defect, P3)

Desktop
Windows 10
defect

Tracking

()

Tracking Status
firefox-esr91 --- unaffected
firefox98 --- wontfix
firefox99 --- wontfix
firefox100 --- wontfix
firefox101 --- wontfix

People

(Reporter: jimm, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

When sending display stream frameRate in stats seems always 30.

STR:
I used this sample for repro https://webrtc.github.io/samples/src/content/peerconnection/old-new-stats/

I overwrote in console 'navigator.mediaDevices.getUserMedia = navigator.mediaDevices.getDisplayMedia'

Set all width/height params as 0 and max frameRate as 15.

From outbound-rtp stats I see that encoded frameRate is 30, but in track settings/constraints fps is 15.

Severity: -- → S2
Priority: -- → P1

Does it reproduce with https://jsfiddle.net/jib1/dnzse47x/ ? (click Start! and share, then (reactivate page and) click the various buttons e.g. x5)

Flags: needinfo?(jmathies)

I think I've reproduced it in Nightly with https://jsfiddle.net/jib1/dnzse47x/30/ - I see the Initial frameRate setting = 2 set in the getDisplayMedia call itself being ignored in the output, whereas it works fine in subsequent track.applyConstraints() (when I click the xN buttons).

I tried running MozRegression, but it doesn't fail then, so this may be intermittent or Nightly only.

Flags: needinfo?(jmathies)

I updated my Nightly and now I can no longer reproduce. Jim are you able to repro with comment 1 or comment 2?

Flags: needinfo?(jmathies)

Also what platform was comment 0 observed on?

I'm not sure what I'm looking for here. No matter what button I click, outbound stats hovers around a value of 12-16.

Flags: needinfo?(jmathies) → needinfo?(jib)

I'm able to reproduce on Windows 10, not other platforms. Regression range says it's https://phabricator.services.mozilla.com/D129721

Flags: needinfo?(jib) → needinfo?(na-g)
OS: All → Windows 10
Regressed by: 1729367
Hardware: All → Desktop

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

Has Regression Range: --- → yes

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

I'm able to reproduce on Windows 10, not other platforms. Regression range says it's https://phabricator.services.mozilla.com/D129721

I ran the regression range and the output is misleading. If one looks at the start of the range it is at c8fdcf75317d40a3ead539a959f748c940d0a5c9 which is the parent of bug 1654112, the WebRTC merge.

 9:51.49 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c8fdcf75317d40a3ead539a959f748c940d0a5c9&tochange=1495ca5ef535f8ad692a3a579ca42eddc14f39a8

 9:53.19 INFO: ************* Switching to autoland by process of elimination (no branch detected in commit message)
 9:53.72 ERROR: Unable to exploit the merge commit. Origin branch is mozilla-central, and the commit message for 1495ca5e was:
Bug 1729367 - P7 - restore mac PID tracking using new API;r=mjf a=webrtc-update

Differential Revision: https://phabricator.services.mozilla.com/D129721

See https://hg.mozilla.org/mozilla-central/rev/18a58105941b085b2ef14d0d6d8178d2a3e8a81b

Flags: needinfo?(na-g)
Regressed by: 1654112
No longer regressed by: 1729367

I have tested backing out bug 1729367, and the bug still persists. So it does look like it is regressed by bug 1654112.

Blocks: teams

This is too late for 99
:mjr can this be assigned, it has an S2 severity

Flags: needinfo?(mfroman)
No longer blocks: webrtc-triage
Severity: S2 → S4
Priority: P1 → P3
Flags: needinfo?(mfroman)
You need to log in before you can comment on or make changes to this bug.