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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9tyiogoM


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

webrtc-win-large-tests

It looks like encode time in this test is increasing from commit #16839 (a chromium roll), and keeps increasing gradually for later commits which also look unrelated. Rasmus, can you have a look (you're listed as one of the owners for this test)?

This should be caused by https://chromium.googlesource.com/webm/libvpx.git/+/b6e1bdfc76a1d5017116aa3148cdb626feb3eb26.

Over to Marco to verify if it's expected that the encode time goes up or not.

That change can make dropping due to overshoot (and encoding next frame at higher QP) more likely, but didn't expect an overall increase in encode time. And not sure why it would only happen on windows. Since the increase is small, i think we can close the issue, as this change is needed for vp8-screenshare. Eric what do you think?

Yeah, it's strange that this happens only on Windows, and the increased encode time also correlates with an increased media bitrate (?!) and total delay. Maybe preventing an overshoot allows it to better meet its target on subsequent frames?
In any case, the change quite small and overall a positive thing. Let's close it.