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

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


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

webrtc-mac-large-tests

nisse@: This regression seems to possibly be related to your CL https://codereview.webrtc.org/2511103002

Could you please have a look!

I don't think it's my cl; if that breaks anything, that would show up as compilation or link errors.

brandtr@: Any idea if this regression could also be related to the updated tests?

I think this is a false positive. This test is very new (about a week), and perhaps the detector thresholds in the performance dashboard tool haven't converged yet?

Compared to VP8/VP9 (which are older tests), we can however see that the H264 tests have significantly higher number of dropped frames: https://chromeperf.appspot.com/report?sid=040e324ff285437d1518f2d6cfbaa1e81c7fe5d9fb5c3cac3b0e8048ff9bf182

sprang@: Any idea if the higher dropped frame counts for H264 are reasonable?

Not sure. Rate control in openh264 seem to be worse than libvpx generally though.

Looking at the graphs with more data, it seems that is alert is just a false positive because the alert thresholds haven't converged yet.