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

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=e0eb7f71060602e3915846c308d984de85509477f1d0588fb072522953afb7ae


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

webrtc-android-tests-nexus4-lollipop
webrtc-android-tests-nexus5
webrtc-android-tests-nexus6-lollipop
webrtc-android-tests-nexus6-nougat
webrtc-android-tests-nexus72
webrtc-linux-large-tests

Added ~400 more graphs to the bug. Be advised, that opening the graphs link might hang your browser for several minutes.

Here's a smaller example set of graphs:
https://chromeperf.appspot.com/group_report?sid=cde73afd758e2ee2f2e80ca61c89fd022b052ac54221b4adb09c5e40d62773e8

The warnings are -2..+3 positions on the graphs, and some bots have separate set of CLs at the point, but all of them point to Erik's CL:
https://webrtc.googlesource.com/src/+/cfe36ca3b3aa1341744f16398e88f733dae4a8e6

Note, some screenshare tests have slightly decreased PSNR: 
https://chromeperf.appspot.com/report?sid=71234e572627595e17a2c58d30200d8dab97f464c35c7ca65f899a667f646923

Issue 912035 has been merged into this issue.

Fix has been merged, now allowing probing up to 2x max allocated bitrate (instead of 1x).
Most send_bandwidth graphs (indicating estimated available bitrate, rather than actual sent by the way) are down, but that is the point of the change.
The first CL however set the ceiling too low and did not have sufficient room to handle overshoot so some tests saw decrease in psnr and/or increase in total delay.

With the latest fix, most delay and psnr values are back to normal.
There is still some decrease in psnr for screenshare tests as they might overshoot at more than 2x, but this regression is not large and only affects tests with unrestricted networks. Likely it will be a net positive for remote clients on poor networks as we are more strict.

The one thing I'm still investigating is a slight decrease in fec and media rate for tests using ulpfec. Will investigate that properly before closing and
merging fixes to M72.

Two fixes are now landed, and the changes are now in expected ranges.
See https://bugs.chromium.org/p/webrtc/issues/detail?id=10070

There's still a low of send_bitrate lower than before, that's because this metric is actually an estimated available send rate, and we now don't probe ridiculously high like we used to.

Regressions to end-to-end delay and psnr are now essentially fixed. It is still down a little bit for screenshare where we have unrestricted networks and very large overshoots. As the bandwidth isn't ramped up as far as before, we don't send as aggressively. This is probably a good thing as it might save some clients that couldn't actually handle the high rate we used to send.

Closing this as fixed.

Actually, we should merge the fixes to M72 branch. Reopening.
This should be safe, especially as the behavior can be disabled using a field trial.

Approving merge to M72 branch 3626 based on comment #8. Please merge ASAP.

Pls merge you change to M72 branch 3626 ASAP so we can pick it up for next  Dev/Beta release, RC cut on Monday, 12/10 @ 1:00 PM PT. Thank you.

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

We are investigating some issues potentially related to the fix for this, removing merge request until we know more.