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

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


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

mac-10_12_laptop_low_end-perf
mac-10_13_laptop_high_end-perf

media.desktop - Benchmark documentation link:
  None

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14fac4b9e40000

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

[media] Enable MojoVideoDecoder by default. by sandersd@chromium.org
https://chromium.googlesource.com/chromium/src/+/44323658c5cc4fff0a2d4a0bcd1d4aa9a7290c87
memory:chrome:all_processes:reported_by_chrome:cc:effective_size: 1.475e+07 → 2.304e+07 (+8.294e+06)

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

Benchmark documentation link:
  None

 Issue 902898  has been merged into this issue.

 Issue 902896  has been merged into this issue.

There do seem to be small (100KB-3MB) increases in |effective_size_avg| stats on Mac, but I can't find (statistically significant) UMA evidence that this is a problem in practice.

I am not sure how |effective_size_avg| is computed, and there are several kinds of memory involved. The most relevant are:
  - SHM for transferring encoded data. GpuVideoDecoder uses a pool of SHM segments, MojoVideoDecoder uses a fixed ring buffer.
  - VideoFrames backed by IOSurfaces. These are system resources that do not get counted unless the memory tracing infrastructure is used. GpuVideoDecoder and MojoVideoDecoder use different paths to release these resources that may have different latency profiles.

I'll continue to monitor as this rolls out to 

 Issue 903209  has been merged into this issue.

 Issue 903357  has been merged into this issue.

 Issue 902893  has been merged into this issue.