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

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


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

webrtc-win-large-tests

r12087 == https://codereview.webrtc.org/1824763003

magjed@/holmer@, is this an acceptable decrease? At first glance, a 1% decrease doesn't seem like anything to worry about, but if you expand the graph timeline slightly [1], you'll see that PSNR had been trending slightly higher for the past couple weeks.

[1] https://chromeperf.appspot.com/report?sid=4cf7c4524aa32ec2a8957ace2d67cc15ece0ef0a86755467fdede5f714fb60fa&start_rev=11809&end_rev=12120

Note that I've just associated some improvements that are also associated with r12087, so it's possible we will just close this bug because the improvements outweigh the "regression."

Hmm, I don't understand how my CL could affect PSNR or media bitrate. holmer - any idea?

Both media_bitrate/screenshare_slides_scrolling and psnr/screenshare_slides_scrolling have been slightly better during the period 2016-03-14 to 2016-03-22, and now they are back to the same levels as they were before 2016-03-14. The PSNR improvement that appeared 2016-03-14 has a tracking bug: http://crbug/595275. They closed that one with WontFix without investigating the cause.

I think this i an expected change. You have changed the decode time estimate from max to 95th percentile, which means it will be smaller. That means we will compensate less for the decode time to achieve smooth rendering.

Oh, and I don't know about the PSNR change either. Probably a matter of timing in some way. I'd ignore that.