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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgiN-MpgoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgiNn2uAsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgyPLDuQoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgiNGQpwkM


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

chromium-webrtc-trunk-tot-rel-linux

CL range:
http://test-results.appspot.com/revision_range?start=384284&end=384290

The range includes this WebRTC roll:
https://codereview.chromium.org/1845863002

The good news is that the roll only has 3 CLs:
https://chromium.googlesource.com/external/webrtc/trunk/webrtc.git/+log/892e6df..83147bf

The bad news is that none of those changes look related to what the encode perf tests cover.
https://codereview.webrtc.org/1844313002 - SSL changes
https://codereview.webrtc.org/1848483002 - change to api/java/android/org/webrtc code
https://codereview.webrtc.org/1836083003 - webrtc/api/peerconnectioninterface.h and unit test

Anyone have any ideas?

Issue 600511 has been merged into this issue.

Summary from duped bug (which is view restricted):
I see similar encode perf alerts on Windows, but with a slightly different CL range (384269:384315). However, I still duped that Windows bug here because both ranges include the WebRTC roll mentioned in #2.

I agree the CL range CLs can't be guilty (at least not on Linux), but this is on the FYI bots, so the affecting change is likely coming from WebRTC.

Hmm, but the before and after builds are on the same WebRTC and libjingle revision, so that can't be it...

I do see an increase in the regular bots at a later stage; presumably the FYI bots detected an increase, and the offending CL later rolled into Chrome and caused a regression on the regular bots: https://chromeperf.appspot.com/report?sid=75f32c4aaf046dbc20b241f2b28a18ff4e0b4d43f7ac065deddafc2247bdd2b9

This WebRTC roll is implicated on the regular bots:

Roll WebRTC 12179:12196, Libjingle 12115:12188

WebRTC 12179:12196

Changes: https://chromium.googlesource.com/external/webrtc/trunk/webrtc.git/+log/83147bf..f97e5d7

Libjingle 12115:12188

Changes: https://chromium.googlesource.com/external/webrtc/trunk/talk.git/+log/2688852..c5d109d

TBR=
BUG=

Review URL: https://codereview.chromium.org/1850673003

Cr-Commit-Position: refs/heads/master@{#384572}

https://chromeperf.appspot.com/group_report?bug_id=600503 implies the rise happens close to WebRTC 12181, which is https://chromium.googlesource.com/external/webrtc/trunk/webrtc.git/+/3c4cb59cfac84264bb90d824883f454529cc8117:

hange VideoSourceInterface::needs_denoising() to return rtc::Optional<bool>

It turns out that it is used as if it has three states: on/off default.
This reverts back to the behaviour prior to https://codereview.webrtc.org/1773993002

BUG= chromium:594434 
R=pbos@webrtc.org, pthatcher@webrtc.org

Review URL: https://codereview.webrtc.org/1842073002 .

Cr-Original-Commit-Position: refs/heads/master@{#12181}
Cr-Mirrored-From: https://chromium.googlesource.com/external/webrtc
Cr-Mirrored-Commit: c0d31e915ca6d730c3d7a8219c229ad53a453201

perkj@, does the decrease here: https://chromeperf.appspot.com/group_report?bug_id=600503 match when your accidentally-turn-off-denoiser CL landed? Appears it was on the 8th of March. In that case it explains this in full; the tests detected that the denoiser was turned off, and now it's on again, leading to an increase in CPU usage.

Seems the denoiser costs ~5% CPU, ~1ms encode time and ~10 megs or RAM then?

 Issue 600497  has been merged into this issue.

Spoke to perkj@ and the times appear to match up when the accidentally-turn-off-denoiser CL landed and when it was reverted. That should be that for this bug.