Closed Bug 1766007 Opened 3 years ago Closed 3 years ago

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

Categories

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

All
Windows 10
defect

Tracking

()

RESOLVED DUPLICATE of bug 1766311
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):

  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

John, any idea what's causing this?

Flags: needinfo?(jlin)

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

Severity: -- → S2
Priority: -- → P2
Flags: needinfo?(jlin) → needinfo?(jolin)
Has Regression Range: --- → yes

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

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

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

Flags: needinfo?(jib)

It's fixed 👍

Flags: needinfo?(jib)
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Flags: needinfo?(jolin)
No longer blocks: webrtc-triage
You need to log in before you can comment on or make changes to this bug.