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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgoP_eoAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg4PCJtAkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg4MaI9QoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgoMPCqwoM


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

webrtc-android-tests-nexus9

brandtr@: Could these regressions have been caused by your CL https://codereview.webrtc.org/2621573002?

I don't think so, that CL only changes around a bit in the FlexFEC config structs. Further, this test doesn't enable FlexFEC.

This regression only happens on Android VP9, see e.g. https://chromeperf.appspot.com/report?sid=39d4cb4b2d714559c53f6b61f3db0693ef62ba20ae0f7854f3073cd19e7da321&start_rev=15975&end_rev=16104

In "WebRTCPerf/webrtc-android-tests-nexus72/webrtc_perf_tests / encode_frame_rate /", it can be seen that the metric starts dipping on the CL before mine however: https://codereview.webrtc.org/2616393003

sprang@: Would you mind having a look at this alert? Do you think it could be related to your change?

As discussed offline, this might be a timing thing. Comparing the same test, with and without packet loss and delay, shows some differences: https://chromeperf.appspot.com/report?sid=31b275396034fe2523bbba31a332c41b5f297c55d02d9ab960e7e632af2cf6fb&start_rev=15276&end_rev=16413

There might be a very small timing change involved here. Previously, the measured input framerate (from the "camera") would be updated whenever we got a new bitrate estimate AND once per second.

After this change, it is updated whenever we get a new bitrate estimate OR if more than one second has passed since the last update.

Not sure why that would result in these stats changes though. It looks like media bitrate went up, dropped frames went up, and quality went down?!
The media bitrate is around 730kbps, which is slightly above the target of 700kbps.

+marpan@ can you have a quick look? Did we just add the final straw?

Don't see how this could be caused by libvpx, and i don't think there is a libvpx roll in that range. The graphs do seem to have recovered though. Erik, take a look and close if you think graphs are recovered.

Yeah, this looks fine now. Closing as wai.