All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=682611

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg4JzjoAsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg4PuToAkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg4NjwsgoM


Bot(s) for this bug's original alert(s):

webrtc-android-tests-nexus5-kitkat

This looks like a regression in ramp-up tests on Android. I could need some help with triaging. Change appears around commit #16136, neighboring changes include

Move congestion controller processing to the pacer thread.

Add experimental simulcast screen content mode.

Fix race in EndToEndTest.ReceivesFlexfecAndSendsCorrespondingRtcp.

Improve computational performance of BWE by switching list to deque.

Refactor OveruseFrameDetector to use timing in us units

(all by our team or close neighbors). Nothing obviously related to rampup or android in particular.

I can imagine that it could be related to one of the following:
https://chromium.googlesource.com/external/webrtc/+/6dbbd89f1876df167cbd4c6eb8b4ade488de1fc1
https://chromium.googlesource.com/external/webrtc/+/7fa4a729245a401209310400e7a4df4e416e96a2
https://chromium.googlesource.com/external/webrtc/+/b3dc2b7b1e02970c49064a61a4bd0fc941249c93

The others seem unlikely. Maybe we should try to revert one of them and see if it makes a difference?

The reason I suspect one of those is:

- the first changes bitrate probing, and the issue is that we send more while ramping up than before.

- the second one changes the Android encoder, shouldn't affect this since we're using a fake encoder, so please ignore this one!

- the third one changes threads related to probing. Could perhaps be that what we're now doing on the pacer thread affects pacing negatively so that probing breaks on this device.

I'd suggest rolling back 1 and/or 3 to start with.

cl 1 caused lots of other changes (which may be improvements rather than regressions?). See https://bugs.chromium.org/p/chromium/issues/detail?id=682640

I suspect these android changes are something different. I'll start with reverting my pacer thread cl.

Graphs are now back to normal. It looks like they returned to old values with the revert of new jitterbuffer, https://codereview.webrtc.org/2638423003, commit #16159. My revert of the threading change landed a few hours later, as #16163, so it's hard to draw any solid conclusion.

Tricky. Maybe we should reland your change and see if it starts reproducing again or not.

Removing R-V-G label (was set upon bug filing because the bot was incorrectly configured as internal)