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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgz-akrgoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgz9SoswoM


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

chromium-rel-win7-x64-dual

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8993097934521563552

=== PERF REGRESSION ===


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

Hi dalecurtis@chromium.org, the bisect results pointed to your CL, please take a look at the
results.


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


===== SUSPECTED CL(s) =====
Subject : Fix underflow correction occurring during normal rendering.
Author  : dalecurtis
Commit description:
  
We should not be trying to expire frames during the normal
rendering process. This corrects a conditional which was
incorrectly allowing this behavior and fixes the test which
were relying on this behavior.

Testing the inverse (i.e. what was broken) is not in this
CL, since I ran out of time to add it for now.

Notably, I wasn't able to reproduce any issues arising from
this mistake. In practice, Render() occurs with such frequency
that it's rare for FrameReady() to occur fast enough to out
pace it in a meaningful manner relative to the frame duration.

BUG= 667704 
TEST=updated unittests.

Review-Url: https://codereview.chromium.org/2570013003
Cr-Commit-Position: refs/heads/master@{#438596}
Commit  : 8ac9ef71a561a281bd867e23fcd31e129373ab37
Date    : Wed Dec 14 19:42:13 2016


===== TESTED REVISIONS =====
Revision         Mean       Std Dev  N  Good?
chromium@438530  -0.817049  5.90938  6  good
chromium@438570  -2.84739   8.17256  6  good
chromium@438590  -4.23577   11.2667  6  good
chromium@438595  2.11989    8.1305   6  good
chromium@438596  23.2656    16.8743  6  bad    <--
chromium@438597  24.8913    12.026   6  bad
chromium@438598  25.0732    10.4969  6  bad
chromium@438600  22.892     8.89033  6  bad
chromium@438610  25.7396    12.2427  6  bad

Bisect job ran on: win_x64_perf_bisect
Bug ID: 674971

Test Command: .\src\out\Release_x64\performance_browser_tests.exe --test-launcher-print-test-stdio=always --enable-gpu
Test Metric: CastV2Performance_gpu_30fps_fast/av_sync
Relative Change: 3250.31%

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/win_x64_perf_bisect/builds/1555
Job details: https://chromeperf.appspot.com/buildbucket_job_status/8993097934521563552


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5236142302035968

| 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 component Tests>AutoBisect.  Thank you!

cc: miu@ for fyi. I believe this is working correctly. The fix prevents the code from incorrectly expiring frames that may have made presentation smoother; sometimes that means a frame which is within an acceptable distance of av-sync is used instead.

This regressed a long time ago when project butter landed and was marked as wontfix then. When the bug was introduced it caused this to fallback to zero, which is not the correct behavior for local presentation.

Probably if we want to make cast immune to this we should plumb a flag that Cast can use to inform the video renderer algorithm behavior (always drop up until current time).