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

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


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

chromium-webrtc-rel-win8

emircan: I was suspecting the things we discussed in bug 649275 but this is older revisions. Did you do changes affecting Win8 around this time as well?

No, this range isn't related to H264 HW encode. The CL that enables it on the bots was on 09/21, see https://codereview.chromium.org/2353163002. Assigning back to you.

holmer: any clue?
The blame list is pretty small, but to be sure I included a few more builds earlier since it's possible the culprit is in there: 
https://chromium.googlesource.com/chromium/src/+log/e306a8069a38f5417f0e34dbb2e534f23cd4b03d..91fecd444ad3de36715f5f198133293c5dfedaf9

Not really. the only windows only change I could find was:

2016-09-11 kjellander@webrtc.org GN: Revert to default compiler optimizations for Win Release.

OK that can't explain it since it was only in for a week or so before reverted, and the perf metric has been stable much longer than that.
Since the average is still lower, although noisier, I'm closing this in lack of ideas on what caused it.