commit 72194da5429d370bc29f63b405f88035609358a6
author Dale Curtis <dalecurtis@chromium.org> Mon Mar 04 23:37:56 2019
committer Commit Bot <commit-bot@chromium.org> Mon Mar 04 23:37:56 2019
tree 83744d21374f3b279895989e1f1a5d017439f180
parent e6ee37be755ab205f0700bf951f62010b6fbd5d7

Improve duration data and usage for video rendering.

We've generally just relied on the average duration for determining
when the ended event should be fired. Twitter has begun to use clips
that have a different duration for the last frame to improve looping.

To improve our performance here, I've updated VideoDecoderStream to
always attach the actual frame duration if we're able to map the
DecoderBuffer which generated a given frame timestamp upon output.

The algorithm will now use this information for the last frame in
the rendering queue (updating with the actual timestamp of the
next frame once received). If there's no more frames, ended will
be fired once the frame is determined to no longer be effective.

As a small optimization VideoRendererImpl will now also fire the
ended event early if we determine that the last frame will stop
being effective within the current rendering interval. Which at
most will improve ended delivery by 1 vsync interval.

BUG=935451
TEST=updated unittests. Visually the the video in that bug looks
much better with the loop attribute set.

R=tguilbert

Change-Id: I7f2891a28538d2591ba2fecb1ef87ae4894edfa6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1497369
Reviewed-by: Thomas Guilbert <tguilbert@chromium.org>
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Auto-Submit: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#637477}