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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgwOifrQkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgwPiTvwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICggOeWtAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICggJqupAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICggP_upAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICggIDBpAsM


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

android-galaxy-s5
android-nexus5
android-nexus6
android-nexus7v2
android-nexus9
android-one

I kicked off a few more bisects.

=== Auto-CCing suspected CL author tommi@chromium.org ===

Hi tommi@chromium.org, the bisect results pointed to your CL below as possibly
causing a regression. Please have a look at this info and see whether
your CL be related.


===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : Roll WebRTC 11897:11965, Libjingle 11893:11936
Author  : tommi
Commit description:
  
WebRTC 11897:11965

Changes: https://chromium.googlesource.com/external/webrtc/trunk/webrtc.git/+log/4b88ad3..2fae8b3

Libjingle 11893:11936

Changes: https://chromium.googlesource.com/external/webrtc/trunk/talk.git/+log/f608241..fedf409

TBR=
BUG=

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

Cr-Commit-Position: refs/heads/master@{#380840}
Commit  : b3ce6bc49c7238ab7f162ba8dd230df14a75a867
Date    : Sat Mar 12 04:42:14 2016


===== TESTED REVISIONS =====
Revision                Mean Value  Std. Dev.   Num Values  Good?
chromium@380836         19228.0     437.593419  5           good
chromium@380838         19276.0     481.447816  5           good
chromium@380839         19415.2     503.407588  5           good
chromium@380840         31496.0     582.98542   5           bad
chromium@380844         31585.6     649.181639  5           bad

Bisect job ran on: android_nexus7_perf_bisect
Bug ID: 594434

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --also-run-disabled-tests webrtc.peerconnection
Test Metric: vm_private_dirty_final_renderer/vm_private_dirty_final_renderer
Relative Change: 64.27%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus7_perf_bisect/builds/2861
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9017188680416756080


| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with label Cr-Tests-AutoBisect.  Thank you!

===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : Roll WebRTC 11897:11965, Libjingle 11893:11936
Author  : tommi
Commit description:
  
WebRTC 11897:11965

Changes: https://chromium.googlesource.com/external/webrtc/trunk/webrtc.git/+log/4b88ad3..2fae8b3

Libjingle 11893:11936

Changes: https://chromium.googlesource.com/external/webrtc/trunk/talk.git/+log/f608241..fedf409

TBR=
BUG=

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

Cr-Commit-Position: refs/heads/master@{#380840}
Commit  : b3ce6bc49c7238ab7f162ba8dd230df14a75a867
Date    : Sat Mar 12 04:42:14 2016


===== TESTED REVISIONS =====
Revision                Mean Value  Std. Dev.   Num Values  Good?
chromium@380836         18614.0     409.946338  6           good
chromium@380839         18673.6     304.796325  5           good
chromium@380840         30956.8     404.013861  5           bad
chromium@380841         31479.2     309.624288  5           bad
chromium@380842         31111.2     380.056838  5           bad
chromium@380848         30889.6     210.762425  5           bad
chromium@380860         30879.2     288.047218  5           bad

Bisect job ran on: android_nexus5_perf_bisect
Bug ID: 594434

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --also-run-disabled-tests webrtc.peerconnection
Test Metric: vm_private_dirty_final_renderer/vm_private_dirty_final_renderer
Relative Change: 65.21%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus5_perf_bisect/builds/3525
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9017188671619417472


| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with label Cr-Tests-AutoBisect.  Thank you!

I'll try taking a look, I believe I have a plausible culprit in there.

Turned out to be a red herring, no idea so far right now. :(

Per's CL in https://codereview.webrtc.org/1773993002 turned off denoising by default for VP8, for now that's our best guess (and it still needs to be fixed). Assigning to him.

This patch removes the regression (default != set to false, which was the case after the patch):

diff --git a/api/rtpsender.cc b/api/rtpsender.cc
index 9c6dfb8..b82e751 100644
--- a/api/rtpsender.cc
+++ b/api/rtpsender.cc
@@ -324,8 +324,7 @@ void VideoRtpSender::SetVideoSend() {
   VideoTrackSourceInterface* source = track_->GetSource();
   if (source) {
     options.is_screencast = rtc::Optional<bool>(source->is_screencast());
-    options.video_noise_reduction =
-        rtc::Optional<bool>(source->needs_denoising());
+    options.video_noise_reduction = rtc::Optional<bool>();
   }
   provider_->SetVideoSend(ssrc_, track_->enabled(), &options);
 }

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/c0d31e915ca6d730c3d7a8219c229ad53a453201

commit c0d31e915ca6d730c3d7a8219c229ad53a453201
Author: Per <perkj@chromium.org>
Date: Thu Mar 31 15:23:39 2016

Change 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-Commit-Position: refs/heads/master@{#12181}

[modify] https://crrev.com/c0d31e915ca6d730c3d7a8219c229ad53a453201/webrtc/api/mediastreaminterface.h
[modify] https://crrev.com/c0d31e915ca6d730c3d7a8219c229ad53a453201/webrtc/api/rtpsender.cc
[modify] https://crrev.com/c0d31e915ca6d730c3d7a8219c229ad53a453201/webrtc/api/videocapturertracksource.cc
[modify] https://crrev.com/c0d31e915ca6d730c3d7a8219c229ad53a453201/webrtc/api/videocapturertracksource.h
[modify] https://crrev.com/c0d31e915ca6d730c3d7a8219c229ad53a453201/webrtc/api/videocapturertracksource_unittest.cc
[modify] https://crrev.com/c0d31e915ca6d730c3d7a8219c229ad53a453201/webrtc/api/videosourceproxy.h
[modify] https://crrev.com/c0d31e915ca6d730c3d7a8219c229ad53a453201/webrtc/api/videotracksource.h

Fix has hopefully been rolled in here: https://codereview.chromium.org/1850673003/

I wonder if the there is something else going on here. After the last roll- it looks even worse. 

https://chromeperf.appspot.com/group_report?bug_id=594434

It turns out that these tests does not work at all on Android at the moment since the bots always run in flight mode which means that a call is never setup properly.

Running these tests manually on a N6 shows:

Rev #380838 with Wifi enabled:
I can see the remote side beeing rendered:

RESULT vm_private_dirty_final_renderer: 720p_call_45s= 51304 kb
RESULT vm_private_dirty_final_renderer: vm_private_dirty_final_renderer= 51304 kb

Attempt 2:
RESULT vm_private_dirty_final_renderer: 720p_call_45s= 51392 kb
RESULT vm_private_dirty_final_renderer: vm_private_dirty_final_renderer= 51392 kb

In flight mode- without wifi....
Remote side never renderes.
RESULT vm_private_dirty_final_renderer: 720p_call_45s= 20732 kb
RESULT vm_private_dirty_final_renderer: vm_private_dirty_final_renderer= 20732 kb

Attemp 2:
RESULT vm_private_dirty_final_renderer: 720p_call_45s= 20152 kb
RESULT vm_private_dirty_final_renderer: vm_private_dirty_final_renderer= 20152 kb


Rev #380840
Flight mode:
RESULT vm_private_dirty_final_renderer: 720p_call_45s= 32180 kb
RESULT vm_private_dirty_final_renderer: vm_private_dirty_final_renderer= 32180 kb

No flight mode:
RESULT vm_private_dirty_final_renderer: 720p_call_45s= 41996 kb
RESULT vm_private_dirty_final_renderer: vm_private_dirty_final_renderer= 41996 kb


So -actually - pbos change do increase the memory footprint when the call is not setup successfully.  However - when it is setup successfully - the memory usage decrease compared to before the roll. That in turn- is most likely due tot the bug that video denoising was disabled per default that is fixed in #10.

Reassignig to phoglund to try to get these tests to work as they should on Android.

(this diff does not seem to be enough.....)

--- a/tools/perf/benchmarks/webrtc.py
+++ b/tools/perf/benchmarks/webrtc.py
@@ -72,6 +72,8 @@ class WebrtcRendering(perf_benchmark.PerfBenchmark):
   def SetExtraBrowserOptions(self, options):
     options.AppendExtraBrowserArgs('--use-fake-device-for-media-stream')
     options.AppendExtraBrowserArgs('--use-fake-ui-for-media-stream')
+    options.AppendExtraBrowserArgs('--allow-loopback-in-peer-connection')
+    options.AppendExtraBrowserArgs('--enforce-webrtc-ip-permission-check')
 

Yeah, unless we think it's a bug to consume more memory when a call doesn't get up, the only remaining bug is with the test.

I think it's reasonable that it's preparing to send the input given to it, so I think my change is fine (and also necessary for time-to-first-frame reductions).

 Issue 600264  has been merged into this issue.

I've been trying to add the same flags as the content browsertest, but it doesn't work. I don't know why unfortunately.

I don't feel I have time to fix this either, now that it turns out it wasn't an easy fix, so I'll spin off a new bug and hopefully someone can look at it later. For now the tests at least measure getUserMedia stuff correctly.

Spun off https://bugs.chromium.org/p/chromium/issues/detail?id=603852, marking fixed since this bug has been dealt with appropriately.