GitLab

This allows the video renderer to grow its frame queue beyond the minimum value of
four frames that we use today. This provides additional headroom to avoid glitches
when the system comes under load.

Nominally this should improve the rebuffering rates seen by Chrome and YouTube by
giving less capable systems more headroom for issues during decoding. This will
be enabled by experiment so we can compare and contrast how modifying buffering
levels affects rebuffering.

Capacity size is chosen based on the time to decode a frame and the expected playout
time of the minimum buffer. In a perfect world with absolute future knowledge we want
to have a buffer of (sum(decode_duration) - sum(frame_duration)) / frame_duration. We
don't know the duration though, so the best we can do is make an estimate based
on how long it would take to play out our minimum buffer; 4 frames normally.

In order to avoid wasting memory, we do not grow capacity if it's impossible for the
decoder to keep up in real time (average decode duration > frame duration), if
there's any memory pressure, if the playback has been ongoing for < 7s, or if the
video is not in the foreground.

BUG=648710, 734813
TEST=new unittests added.

Change-Id: If6c84dd8e77fd9d043037434926e452286e50429
Reviewed-on: https://chromium-review.googlesource.com/525135
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Xiaohan Wang (OOO June 21-22) <xhwang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#481647}