media: VideoRenderImpl: display last available frame

media: VideoRenderImpl: display last available frame

With a few webgl aquarium demo windows open and a 1080p video playing
at the same time, you can notice the video dropping a lot frames. From
time to time being stuck on a same frame for a second or more.

This is due to the VideoRendererImpl dropping frames. It takes too
much time for the compositor to paint its content, keeping the GPU
busy and delaying decoded video frames too long. Decoded frames arrive
too late and are never presented and we stick to an old frame.

This changes the behavior of VideoRendererImpl to a best effort
strategy where we might start displaying images past their display
time, but at least we're not stuck on a same image for too long.

BUG=chrome-os-partner:37786
TEST=run the test as explained on the bug

Committed: https://crrev.com/f509661231fbb02b6ed35a772622a3d87c26a565
Cr-Commit-Position: refs/heads/master@{#322100}

[llandwerlin-old, 2015-03-24 15:58:05]

lionel.g.landwerlin@intel.com changed reviewers:
+ dalecurtis@chromium.org

[llandwerlin-old, 2015-03-24 15:58:05]

PTAL, Thanks.

[DaleCurtis, 2015-03-24 17:25:23]

I'm in the process of replacing this entire algorithm, but this seems like a
small reasonable change.

https://codereview.chromium.org/1005303004/diff/1/media/renderers/video_rende...
File media/renderers/video_renderer_impl.cc (right):

https://codereview.chromium.org/1005303004/diff/1/media/renderers/video_rende...
media/renderers/video_renderer_impl.cc:249:
UpdateStatsAndWait_Locked(target_paint_timestamp - now);
std::max(target_paint_timestamp - now, kIdleTimeDelta); ?

[llandwerlin-old, 2015-03-24 17:45:01]

On 2015/03/24 17:25:23, DaleCurtis wrote:
> I'm in the process of replacing this entire algorithm, but this seems like a
> small reasonable change.
> 
>
https://codereview.chromium.org/1005303004/diff/1/media/renderers/video_rende...
> File media/renderers/video_renderer_impl.cc (right):
> 
>
https://codereview.chromium.org/1005303004/diff/1/media/renderers/video_rende...
> media/renderers/video_renderer_impl.cc:249:
> UpdateStatsAndWait_Locked(target_paint_timestamp - now);
> std::max(target_paint_timestamp - now, kIdleTimeDelta); ?

std::min surely?

[DaleCurtis, 2015-03-24 17:47:57]

https://codereview.chromium.org/1005303004/diff/1/media/renderers/video_rende...
File media/renderers/video_renderer_impl.cc (right):

https://codereview.chromium.org/1005303004/diff/1/media/renderers/video_rende...
media/renderers/video_renderer_impl.cc:249:
UpdateStatsAndWait_Locked(target_paint_timestamp - now);
On 2015/03/24 17:25:23, DaleCurtis wrote:
> std::max(target_paint_timestamp - now, kIdleTimeDelta); ?

Whoops, yes.

[llandwerlin-old, 2015-03-24 17:52:01]

https://codereview.chromium.org/1005303004/diff/1/media/renderers/video_rende...
File media/renderers/video_renderer_impl.cc (right):

https://codereview.chromium.org/1005303004/diff/1/media/renderers/video_rende...
media/renderers/video_renderer_impl.cc:249:
UpdateStatsAndWait_Locked(target_paint_timestamp - now);
On 2015/03/24 17:47:57, DaleCurtis wrote:
> On 2015/03/24 17:25:23, DaleCurtis wrote:
> > std::max(target_paint_timestamp - now, kIdleTimeDelta); ?
> 
> Whoops, yes.

Done.

[DaleCurtis, 2015-03-24 20:30:48]

lgtm

[llandwerlin-old, 2015-03-24 23:45:54]

The CQ bit was checked by lionel.g.landwerlin@intel.com

[commit-bot: I haz the power, 2015-03-24 23:47:14]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1005303004/20001

[commit-bot: I haz the power, 2015-03-25 00:10:11]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-03-25 00:10:47]

Patchset 2 (id:??) landed as
https://crrev.com/f509661231fbb02b6ed35a772622a3d87c26a565
Cr-Commit-Position: refs/heads/master@{#322100}