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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgzsSEowoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgjrepqgsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgzoOgtgoM


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

webrtc-android-tests-nexus5

kjellander: please take a look, and close if the change seems reasonable with your roll of Chromium into WebRTC.

Yeah, since it's including a libvpx roll I would assume smaller variations like this are to be expected. 

marpan: can you confirm and close if it seems reasonable? It's a bit weird it's only hitting one device.

What other devices are tested? We did remove some armv6 code, but added new optimizations a short time later:
https://chromium.googlesource.com/chromium/src/+/3b352b0e6ff7180e8ce9f4bd79069a34220bd705
2016-08-12 linfengz NEON asm of vpx_lpf_{horizontal,vertical}_8_dual_neon()

https://chromium.googlesource.com/chromium/src/+/db041e863ac318d054f13a16885a557c7cc93b5e
2016-08-03 linfengz NEON intrinsics for 4 loopfilter functions

I didn't expect a regression this high, but I am working on replacing 3 other functions:
https://bugs.chromium.org/p/webm/issues/detail?id=1273

Jacky will take a look and try to reproduce with standalone libvpx.

Ran the same test on my nexus 5 using webrtc_perf test (conference_hd clip)
and found that the removal of armv6 code (as mentioned in comment#5) in the Aug 11 roll
causes ~8-10% regression in encode_time.

The gain is mostly retrieved back with this CL https://chromium-review.googlesource.com/#/c/374664/
that was rolled into chromium yesterday (https://codereview.chromium.org/2295893002/)

Will monitor the graphs in next few days to see if regression goes away.

The regression is mostly recovered in the latest graphs, so I'll close (mark as fixed) the issue for now.