1766007 - When using VP8 for WebRTC camera the resolution won't adjust to reduce bitrate on Windows

Status: RESOLVED DUPLICATE of bug 1766311

(Core :: WebRTC: Audio/Video, defect, P2)

Description

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

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):

1. Open https://jsfiddle.net/jib1/02j8q6h9/140/show (leave ☐h264 unchecked)
2. Hit the gUM! button (and allow camera)
3. Wait ~5 seconds
4. Change Max bitrate from 2000000 to 2000 (click number and delete 3 zeros)
5. 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

Comment 1

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

John, any idea what's causing this?

Comment 2

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

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

Comment 3

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

This problem goes away if I set media.webrtc.platformencoder.sw_mft to false in about:config.

Comment 4

[Jim Mathies [:jimm]]

We're going to disable platform encoding support for vp8.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

This should be resolved by bug 1766311. Jan-Ivar, can you confirm that it's fixed for you with the latest Nightly?

Comment 6

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

It's fixed 👍