GitLab

http://crrev.com/493874 changed the low delay case to wait for two
frames since we need to be sure we don't resume until we actually
have valid frames since the first frame was valid forever without
duration information.

It turns out we actually do have duration infromation hanging off
the DecoderStream, so use this information and set it as the
FRAME_DURATION metadata key for each VideoFrame.

We can then have the algorithm use this information for the
estimated end time of frames when only a single frame is present
in the queue.

Note: The video-canvas layout test was showing the wrong frame;
I manually extracted the frames and verified that before we were
showing the "7" frame when pts=2.0s == "6" frame. I've updated
the test expectations appropriately.

BUG=786576,767878,709302
TEST=new unittest, old unittests pass w/o modification, manual
test of 4k60 vp9 low latency content doesn't exhibit multiple
stalls after returning to the foreground when the video track
has been disabled, manual test with https://jsfiddle.net/u3enjLzz/

Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I963903d6a173038a2d534db4e040c8f4774825b5
Reviewed-on: https://chromium-review.googlesource.com/780267
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#519961}