New issue
Advanced search Search tips

Issue 636002 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Aug 2016
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug

Blocking:
issue 631199



Sign in to add a comment

Add a repaint option to VideoRendererSink's PaintSingleFrame

Project Member Reported by tguilbert@chromium.org, Aug 9 2016

Issue description

The StreamTextureWrapper wraps the native texture once, and returns the same frame over and over again.

The VideoFrameCompositor has a small optimization that prevents the same frame from being repainted.

This change tracks adding a "repaint_duplicate_frames" to the PaintSingleFrame interface, to allow the MediaPlayerRendererClient to use StreamTextureWrapper and VideoFrameCompositor in a straightforward way.

 
Blocking: 631199
Components: Internals>Media
Labels: -Pri-3 Pri-1
Owner: tguilbert@chromium.org
Status: Started (was: stat)
Summary: Add a repaint option to VideoRendererSink's PaintSingleFrame (was: Add a "allow_duplicate_frame" parameter to PaintSingleFrame)
Project Member

Comment 2 by bugdroid1@chromium.org, Aug 12 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3a03dae98226541c80bceff2ee8fd97e2cde8fcc

commit 3a03dae98226541c80bceff2ee8fd97e2cde8fcc
Author: tguilbert <tguilbert@chromium.org>
Date: Fri Aug 12 21:18:22 2016

Add "repaint" option to PaintSingleFrame

The VideoFrameCompositor currently ignores calls to PaintSingleFrame()
if the passed frame is the same as the last frame.

StreamTextureWrapper's (STW) GetCurrentFrame() always returns the same
frame, whilst the underlying texture information has been updated. This
means that it is impossible to use STW's frame with the
PaintSingleFrame() method.

This change adds a "repaint_duplicate_frame" boolean to the
PaintSingleFrame() method, allowing the MediaPlayerRendererClient to
pass the STW's frame directly.

Instead of using the VideoRendererSink interface:
It would have been possible to have STW implement the
VideoFrameProvider interface. This meant that WMPI would have had to
own a STW and create a different VideoLayer, which would have been
more complex to understand, and likely harder to maintain.

Instead of using the PaintSingleFrame method:
It would have also been possible to have STW implement the
RenderCallback interface. However, this would lead to issues due the
different rate at which Render() is called, versus the rate at which
MediaPlayer actuall outputs frames (and would probably degrade
performance).

BUG= 636002 

Review-Url: https://codereview.chromium.org/2239163002
Cr-Commit-Position: refs/heads/master@{#411773}

[modify] https://crrev.com/3a03dae98226541c80bceff2ee8fd97e2cde8fcc/content/renderer/media/android/media_player_renderer_client.cc
[modify] https://crrev.com/3a03dae98226541c80bceff2ee8fd97e2cde8fcc/media/base/null_video_sink.cc
[modify] https://crrev.com/3a03dae98226541c80bceff2ee8fd97e2cde8fcc/media/base/null_video_sink.h
[modify] https://crrev.com/3a03dae98226541c80bceff2ee8fd97e2cde8fcc/media/base/null_video_sink_unittest.cc
[modify] https://crrev.com/3a03dae98226541c80bceff2ee8fd97e2cde8fcc/media/base/video_renderer_sink.h
[modify] https://crrev.com/3a03dae98226541c80bceff2ee8fd97e2cde8fcc/media/blink/video_frame_compositor.cc
[modify] https://crrev.com/3a03dae98226541c80bceff2ee8fd97e2cde8fcc/media/blink/video_frame_compositor.h

Status: Fixed (was: Started)

Sign in to add a comment