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

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


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/2633673002. Could you please take a look?

Seems likely it's my change. But I think it can be considered an improvement, since measurements get less noisy. I don't think my cl changes the actual encoder performance, only the way it's measured.

Was this visible on mac only?

I think so. But there has been some recent other regressions that have been related to H264. Do you know anything about recent changes in that code?

No, I haven't worked with anything h.264 specific.

hta@: You had a CL regarding H264 code updates recently. Do you know of any recent H264 code changes that could have caused this regression?

hta@: You had a CL regarding H264 code updates recently. Do you know of any recent H264 code changes that could have caused this regression?

None of the recent H.264 changes touched Mac (it's explicitly excluded from the H.264 assembly fixes). Assigning back to nisse@.

Closing. I think this actually is an improvement in the measurement of encode time, with slightly less noise.