When using VP8 for WebRTC camera the resolution won't adjust to reduce bitrate on Windows
Categories
(Core :: WebRTC: Audio/Video, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr91 | --- | unaffected |
firefox99 | --- | unaffected |
firefox100 | --- | wontfix |
firefox101 | --- | fixed |
People
(Reporter: jib, Unassigned)
References
(Regression)
Details
(Keywords: regression)
This is a recent regression that threw me for a loop trying to debug related stuff. Unsure how a patch about H264 could regress VP8 but that's what I'm observing and ran a mozregression on the STRs below to confim.
STRs (I used a Logitech camera which gave me a 1920x1080 camera source. YMMV):
- Open https://jsfiddle.net/jib1/02j8q6h9/140/show (leave ☐h264 unchecked)
- Hit the
gUM!
button (and allow camera) - Wait ~5 seconds
- Change
Max bitrate
from 2000000 to 2000 (click number and delete 3 zeros) - wait ~10 seconds
Expected result:
- Receiver resolution drops to less than sender resolution
Actual result:
- Receiver resolution never drops
Does not repro on macOS, so marking Windows only for now.
Regression range
2022-04-22T10:12:37.923000: INFO : Narrowed integration regression window from [24ac67f1, 5286475a] (4 builds) to [e3198ee2, 5286475a] (2 builds) (~1 steps left)
2022-04-22T10:12:37.935000: DEBUG : Starting merge handling...
2022-04-22T10:12:37.935000: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=5286475acad3841f2ad9e1a837b202af9701fab2&full=1
2022-04-22T10:12:37.935000: DEBUG : redo: attempt 1/3
2022-04-22T10:12:37.936000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/integration/autoland/json-pushes?changeset=5286475acad3841f2ad9e1a837b202af9701fab2&full=1',), kwargs: {}, attempt #1
2022-04-22T10:12:37.940000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg.mozilla.org
2022-04-22T10:12:38.683000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=5286475acad3841f2ad9e1a837b202af9701fab2&full=1 HTTP/1.1" 200 None
2022-04-22T10:12:38.711000: DEBUG : Found commit message:
Bug 1741244 - p6: wait for frame encoded in capture throttle test. r=jib
Initializing platform encoders often takes some time and the frame
rate measured is lower than actual number when the counting starts as
soon as connection established. Delaying the measurement until there
is at least some frame encoded makes it more accurate.
Differential Revision: https://phabricator.services.mozilla.com/D141513
2022-04-22T10:12:38.711000: DEBUG : Did not find a branch, checking all integration branches
2022-04-22T10:12:38.715000: INFO : The bisection is done.
2022-04-22T10:12:38.717000: INFO : Stopped
Updated•3 years ago
|
Comment 2•3 years ago
|
||
Set release status flags based on info from the regressing bug 1741244
Updated•3 years ago
|
Reporter | ||
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Reporter | ||
Comment 3•3 years ago
|
||
This problem goes away if I set media.webrtc.platformencoder.sw_mft
to false
in about:config.
Updated•3 years ago
|
Comment 4•3 years ago
|
||
We're going to disable platform encoding support for vp8.
Comment 5•3 years ago
|
||
This should be resolved by bug 1766311. Jan-Ivar, can you confirm that it's fixed for you with the latest Nightly?
Reporter | ||
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Description
•