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

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


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

android-nexus5
android-nexus6
android-nexus7v2
chromium-rel-win7-dual
chromium-rel-win7-gpu-ati
chromium-rel-win7-gpu-intel
chromium-rel-win8-dual

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/15d00e5b440000

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

Attempt to parallelize offloaded video decoding again... by dalecurtis@chromium.org
https://chromium.googlesource.com/chromium/src/+/00eda06906b09bb0b001207e29ed8ebb8c0e03e1

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

This is effectively increasing the max decoded frames by 1 for 720p+ playbacks, which seems reasonable given the issues with even 720p content seeing 1% drop rates. Will keep an eye on this though.

 Issue 826789  has been merged into this issue.

One way we could reduce the memory impact here to only when necessary is to apply this optimization to > 30fps content only; this could be determined based on the duration of the buffers provided. It would be sticky to avoid flipping between parallel and non-parallel decoding modes. 

WDYT xhwang?

Generally I don't like this level of micro adjustment. It makes the code more complex, and it's hard to measure the effect because there's always a trade-of between memory usage and performance). 

For now, can we just accept the memory cost as part of performance improvement?

Now brainstorming... 

For the future, I think we should record the actual decoding speed, e.g. the average time to get a video frame decoded, including actual decoding time, plus IPC or thread hopping overhead. This would provide us the ultimate insight of how much head room we have for smooth playback. Then we can compare the decoding speed with fps to decide whether we should favor performance at the cost of more memory usage. Ideally this decision should also be tied to memory pressure level.

The actual decoding speed could also be useful for calculating the "smoothness" for media capabilities.

It might also be worth to report the average decoding speed to UKM for each playback instance.

I'm going to run some experiments today with 30fps and below content to see how practical it is to disable for non-HFR, but yes otherwise we can probably just live with it.

As for your brainstorming... that's roughly what complexity based buffering did and unfortunately experimentation hasn't revealed any benefits; just increased memory usage :(

https://giphy.com/gifs/election2016-debate-presidential-2016-26uf2JHNV0Tq3ugkE

sgtm about the plan.

For the complexity based buffering, any details on how it works and why it doesn't work?

You reviewed it long ago now :) -- but here's the core function:

https://cs.chromium.org/chromium/src/media/renderers/video_renderer_impl.cc?l=869

Why it doesn't work is less clear. I was expecting at least a small improvement in MTBR, but data is inconclusive. It's possible that just using more memory is problematic (in which case this issue will also cause an MTBR regression again). There's no statistically significant change over time in watch time, smoothness, rebuffers or errors... just increased memory usage.

For 720p30 and 1080p30 there is a 9% and 15% reduction in read times respectively, so allowing parallel decode still provides improved decoding. Aside from the extra frame I can't find any other performance improvements or regression son our bots. We'll have to wait longer to see if YouTube or our MTBR/RebufferCount metrics show anything, dashboard links for the future:

https://uma.googleplex.com/p/chrome/timeline_v2/?sid=c0a5b24db1295a6b4aa586f1acd19097

That was for dev, this is for canary:
https://uma.googleplex.com/p/chrome/timeline_v2/?sid=9a7e32678c11294fb94f52578b48d958

Seems to be no issues, so going to close this as WontFix.