Issue with frameRate constraint for getDisplayMedia
Categories
(Core :: WebRTC, defect, P3)
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.
Updated•3 years ago
|
Comment 1•3 years ago
|
||
Does it reproduce with https://jsfiddle.net/jib1/dnzse47x/ ? (click Start!
and share, then (reactivate page and) click the various buttons e.g. x5
)
Comment 2•3 years ago
|
||
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.
Comment 3•3 years ago
|
||
I updated my Nightly and now I can no longer reproduce. Jim are you able to repro with comment 1 or comment 2?
![]() |
Reporter | |
Comment 5•3 years ago
|
||
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.
![]() |
Reporter | |
Updated•3 years ago
|
Comment 6•3 years ago
|
||
I'm able to reproduce on Windows 10, not other platforms. Regression range says it's https://phabricator.services.mozilla.com/D129721
Updated•3 years ago
|
Comment 7•3 years ago
|
||
Set release status flags based on info from the regressing bug 1729367
Updated•2 years ago
|
Updated•2 years ago
|
Comment 8•2 years ago
|
||
(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
Updated•2 years ago
|
Comment 9•2 years ago
|
||
I have tested backing out bug 1729367, and the bug still persists. So it does look like it is regressed by bug 1654112.
Comment 10•2 years ago
|
||
This is too late for 99
:mjr can this be assigned, it has an S2 severity
![]() |
Reporter | |
Updated•2 years ago
|
![]() |
Reporter | |
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Description
•