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

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=d4419a69f3c9b44872974e8d7d9e313b49c32d7753ded6711e832f1fba59f955


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

chromium-rel-mac11-air
chromium-rel-mac11-pro
chromium-rel-win10

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/1629408d440000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/1629408d440000

Move GpuMemoryBuffer upload stage to VideoFrameStream via preparation. by dalecurtis@chromium.org
https://chromium.googlesource.com/chromium/src/+/60c45746804d93ccfdaead7ae92b2acd46391698

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

These all look as expected; many of them have previous peaks around the new value. E.g., depending on speed, load we were reaching these levels before. The improved pipelining will mean we are more likely to hit the max levels in more circumstances. But this is effectively +/- one frame and not +/- 10 frames like the previous performance regressions.

I'll leave this open for a while longer, but this is as expected.

These are as expected. Faster processing sometimes ends up picking up another frame.