WebRTC: One WebRTC Video can have both SW and HW VideoFrame.

WebRTC: One WebRTC Video can have both SW and HW VideoFrame.

SkCanvasVideoRenderer assumes that the VideoFrames belonging to one WebRTC
video are always either software VideoFrame or hardware VideoFrame.
However, it's not true. VideoFrame can be changed each frame.

TEST=content_browsertests WebRtcBrowserTest.CallAndVerify* on Nexus5
BUG=448014
Committed: https://crrev.com/8d78aa3cd5d34bb154aa7a832e0be8a6d7397af6
Cr-Commit-Position: refs/heads/master@{#311468}

[dshwang, 2015-01-12 13:48:25]

dongseong.hwang@intel.com changed reviewers:
+ dalecurtis@chromium.org, perkj@chromium.org, xhwang@chromium.org

[dshwang, 2015-01-12 13:50:25]

@dalecurtis or @xhwang, could you review?

@perkj, thx for reporting this bug. It comes out that I didn't fix all bugs in
https://codereview.chromium.org/812613003/
Just removing DCHECK can cause subtle skia bug.

[DaleCurtis, 2015-01-12 20:47:01]

https://codereview.chromium.org/848683003/diff/1/media/filters/skcanvas_video...
File media/filters/skcanvas_video_renderer.cc (right):

https://codereview.chromium.org/848683003/diff/1/media/filters/skcanvas_video...
media/filters/skcanvas_video_renderer.cc:449: accelerated_last_frame_.reset();
Can you explain why you need these conditionals? It seems like you could just
put:

  accelerated_last_frame_.reset();
  accelerated_generator_ = nullptr;

between line 430 and 431 and call it done?

[dshwang, 2015-01-13 08:38:22]

https://codereview.chromium.org/848683003/diff/1/media/filters/skcanvas_video...
File media/filters/skcanvas_video_renderer.cc (right):

https://codereview.chromium.org/848683003/diff/1/media/filters/skcanvas_video...
media/filters/skcanvas_video_renderer.cc:449: accelerated_last_frame_.reset();
On 2015/01/12 20:47:01, DaleCurtis wrote:
> Can you explain why you need these conditionals? It seems like you could just
> put:
> 
>   accelerated_last_frame_.reset();
>   accelerated_generator_ = nullptr;
> 
> between line 430 and 431 and call it done?

That's good question. It's because allocating accelerated_last_frame_is
expensive. We want to reuse texture or system memory belonging to
accelerated_last_frame instead of allocating every frame.

[DaleCurtis, 2015-01-13 17:38:29]

Thanks, looking at the conditionals again I see some may not always be null by
the end of this process. lgtm

[dshwang, 2015-01-14 13:07:47]

On 2015/01/13 17:38:29, DaleCurtis wrote:
> Thanks, looking at the conditionals again I see some may not always be null by
> the end of this process. lgtm

Thank you for reviewing!

[dshwang, 2015-01-14 13:07:50]

The CQ bit was checked by dongseong.hwang@intel.com

[commit-bot: I haz the power, 2015-01-14 13:08:04]

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

[commit-bot: I haz the power, 2015-01-14 13:42:40]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-01-14 13:43:26]

Patchset 1 (id:??) landed as
https://crrev.com/8d78aa3cd5d34bb154aa7a832e0be8a6d7397af6
Cr-Commit-Position: refs/heads/master@{#311468}