Reland [Mojo Video Capture] Decouple VCController from VCBufferPool and VCDeviceClient

Reland [Mojo Video Capture] Decouple VideoCaptureController from VideoCaptureBufferPool and VideoCaptureDeviceClient

PatchSet 1 is the state as reviewed and landed previously, see
https://codereview.chromium.org/2551193002/

This state caused a regression where video capture would be stuck in a loop of
old frames on Android when moving the browser to the background and bringing it
back to the foreground. This was caused by a new buffer pool instance being
created instead of the existing one being reused, while the renderer side would
still be pointing to buffers of the previous instance.

PatchSet 2 applies a fix for this issue.

Below is the CL description of the original CL:

Decouple VideoCaptureController from VideoCaptureBufferPool and
VideoCaptureDeviceClient. This is needed in order to prepare
VideoCaptureController for working with both the (legacy) in-process video
capture and the new video_capture Mojo service.

List of changes:
* Introduce an abstraction FrameBufferPool for the VideoCaptureController to
  talk to the VideoCaptureBufferPool.
* Move VideoFrameReceiverOnIOThread to separate file.
* Move factory logic for creating and connecting
  VideoCaptureBufferPoolImpl and VideoCaptureDeviceClient out of
  VideoCaptureController and into VideoCaptureManager as well as the tests.
* Update OWNERS to include new file and include chfremer as owner.
* In VideoCaptureDeviceClient: Rename |frame_format| to |foramt|.

This CL is part of the Mojo Video Capture work. For the bigger picture,
see [1] CL1.9.8

BUG=584797
TEST=
  content_unittests,
  video_capture_unittests,
  Apprtc loopback on Debug,
  Desktop Capture Example extension on Release

[1] https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxsxWslJ_X-zpOhijvI8/edit?usp=sharing

Committed: https://crrev.com/4f85f2f30f051cf961d28b17e3093dbd67c62661
Cr-Commit-Position: refs/heads/master@{#441261}

[chfremer, 2016-12-22 00:19:01]

Description was changed from

==========
Apply patch for 1.9.8

BUG=
==========

to

==========
Reland [Mojo Video Capture] Decouple VideoCaptureController from
VideoCaptureBufferPool and VideoCaptureDeviceClient

PatchSet 1 is the state as reviewed and landed previously, see 
https://codereview.chromium.org/2551193002/

This state caused a regression where video capture would be stuck in a loop of 
old frames on Android when moving the browser to the background and bringing it
back to the foreground. This was caused by a new buffer pool instance being 
created instead of the existing one being reused, while the renderer side would 
still be pointing to buffers of the previous instance.

PatchSet 2 applies a fix for this issue.


Below is the CL description of the original CL:

Decouple VideoCaptureController from VideoCaptureBufferPool and
VideoCaptureDeviceClient. This is needed in order to prepare
VideoCaptureController for working with both the (legacy) in-process video
capture and the new video_capture Mojo service.

List of changes:
* Introduce an abstraction FrameBufferPool for the VideoCaptureController to
  talk to the VideoCaptureBufferPool.
* Move VideoFrameReceiverOnIOThread to separate file.
* Move factory logic for creating and connecting
  VideoCaptureBufferPoolImpl and VideoCaptureDeviceClient out of
  VideoCaptureController and into VideoCaptureManager as well as the tests.
* Update OWNERS to include new file and include chfremer as owner.
* In VideoCaptureDeviceClient: Rename |frame_format| to |foramt|.

This CL is part of the Mojo Video Capture work. For the bigger picture,
see [1] CL1.9.8

BUG=584797
TEST=
  content_unittests,
  video_capture_unittests,
  Apprtc loopback on Debug,
  Desktop Capture Example extension on Release

[1]
https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxs...
==========

[chfremer, 2016-12-22 00:19:09]

The CQ bit was checked by chfremer@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-22 00:19:40]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[chfremer, 2016-12-22 00:21:09]

chfremer@chromium.org changed reviewers:
+ mcasas@chromium.org, miu@chromium.org

[chfremer, 2016-12-22 00:21:10]

mcasas@: Please RS
miu@: Please RS

[miu, 2016-12-22 00:51:32]

PS2 lgtm

[commit-bot: I haz the power, 2016-12-22 02:00:22]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-22 02:00:23]

Dry run: This issue passed the CQ dry run.

[mcasas, 2016-12-22 03:07:43]

lgtm

https://codereview.chromium.org/2597833002/diff/20001/content/browser/rendere...
File content/browser/renderer_host/media/video_capture_manager.cc (right):

https://codereview.chromium.org/2597833002/diff/20001/content/browser/rendere...
content/browser/renderer_host/media/video_capture_manager.cc:182: //
|buffer_pool| get reused instead of creating a new one.
s/get/gets/

https://codereview.chromium.org/2597833002/diff/20001/content/browser/rendere...
content/browser/renderer_host/media/video_capture_manager.cc:285: buffer_pool =
new media::VideoCaptureBufferPoolImpl(
If this is only a special use case for Android, use
#if defined(OS_ANDROID)
here

[chfremer, 2016-12-22 03:16:44]

chfremer@chromium.org changed reviewers:
+ avi@chromium.org

[chfremer, 2016-12-22 03:16:45]

avi@: Please RS

[chfremer, 2017-01-03 20:46:52]

On 2016/12/22 03:16:45, chfremer wrote:
> avi@: Please RS

ping
avi@: Please RS

[Avi (use Gerrit), 2017-01-03 20:49:43]

lgtm

rs; good luck

[chfremer, 2017-01-03 22:41:01]

The CQ bit was checked by chfremer@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-03 22:41:19]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-04 00:11:07]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-04 00:11:08]

Dry run: This issue passed the CQ dry run.

[chfremer, 2017-01-04 00:15:17]

The CQ bit was checked by chfremer@chromium.org

[chfremer, 2017-01-04 00:15:18]

The patchset sent to the CQ was uploaded after l-g-t-m from avi@chromium.org,
mcasas@chromium.org, miu@chromium.org
Link to the patchset: https://codereview.chromium.org/2597833002/#ps40001
(title: "Rebase")

[commit-bot: I haz the power, 2017-01-04 00:15:46]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-04 00:21:29]

CQ is committing da patch.

Bot data: {"patchset_id": 40001, "attempt_start_ts": 1483488917816340,
"parent_rev": "dcfca594f51026a5939bf0f41c6ff43fecca604d", "commit_rev":
"5aba9e35d54af35bac568cc8e7d2e4e88866d8bc"}

[commit-bot: I haz the power, 2017-01-04 00:21:57]

Description was changed from

==========
Reland [Mojo Video Capture] Decouple VideoCaptureController from
VideoCaptureBufferPool and VideoCaptureDeviceClient

PatchSet 1 is the state as reviewed and landed previously, see 
https://codereview.chromium.org/2551193002/

This state caused a regression where video capture would be stuck in a loop of 
old frames on Android when moving the browser to the background and bringing it
back to the foreground. This was caused by a new buffer pool instance being 
created instead of the existing one being reused, while the renderer side would 
still be pointing to buffers of the previous instance.

PatchSet 2 applies a fix for this issue.


Below is the CL description of the original CL:

Decouple VideoCaptureController from VideoCaptureBufferPool and
VideoCaptureDeviceClient. This is needed in order to prepare
VideoCaptureController for working with both the (legacy) in-process video
capture and the new video_capture Mojo service.

List of changes:
* Introduce an abstraction FrameBufferPool for the VideoCaptureController to
  talk to the VideoCaptureBufferPool.
* Move VideoFrameReceiverOnIOThread to separate file.
* Move factory logic for creating and connecting
  VideoCaptureBufferPoolImpl and VideoCaptureDeviceClient out of
  VideoCaptureController and into VideoCaptureManager as well as the tests.
* Update OWNERS to include new file and include chfremer as owner.
* In VideoCaptureDeviceClient: Rename |frame_format| to |foramt|.

This CL is part of the Mojo Video Capture work. For the bigger picture,
see [1] CL1.9.8

BUG=584797
TEST=
  content_unittests,
  video_capture_unittests,
  Apprtc loopback on Debug,
  Desktop Capture Example extension on Release

[1]
https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxs...
==========

to

==========
Reland [Mojo Video Capture] Decouple VideoCaptureController from
VideoCaptureBufferPool and VideoCaptureDeviceClient

PatchSet 1 is the state as reviewed and landed previously, see 
https://codereview.chromium.org/2551193002/

This state caused a regression where video capture would be stuck in a loop of 
old frames on Android when moving the browser to the background and bringing it
back to the foreground. This was caused by a new buffer pool instance being 
created instead of the existing one being reused, while the renderer side would 
still be pointing to buffers of the previous instance.

PatchSet 2 applies a fix for this issue.


Below is the CL description of the original CL:

Decouple VideoCaptureController from VideoCaptureBufferPool and
VideoCaptureDeviceClient. This is needed in order to prepare
VideoCaptureController for working with both the (legacy) in-process video
capture and the new video_capture Mojo service.

List of changes:
* Introduce an abstraction FrameBufferPool for the VideoCaptureController to
  talk to the VideoCaptureBufferPool.
* Move VideoFrameReceiverOnIOThread to separate file.
* Move factory logic for creating and connecting
  VideoCaptureBufferPoolImpl and VideoCaptureDeviceClient out of
  VideoCaptureController and into VideoCaptureManager as well as the tests.
* Update OWNERS to include new file and include chfremer as owner.
* In VideoCaptureDeviceClient: Rename |frame_format| to |foramt|.

This CL is part of the Mojo Video Capture work. For the bigger picture,
see [1] CL1.9.8

BUG=584797
TEST=
  content_unittests,
  video_capture_unittests,
  Apprtc loopback on Debug,
  Desktop Capture Example extension on Release

[1]
https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxs...

Review-Url: https://codereview.chromium.org/2597833002
==========

[commit-bot: I haz the power, 2017-01-04 00:21:58]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2017-01-04 00:24:43]

Description was changed from

==========
Reland [Mojo Video Capture] Decouple VideoCaptureController from
VideoCaptureBufferPool and VideoCaptureDeviceClient

PatchSet 1 is the state as reviewed and landed previously, see 
https://codereview.chromium.org/2551193002/

This state caused a regression where video capture would be stuck in a loop of 
old frames on Android when moving the browser to the background and bringing it
back to the foreground. This was caused by a new buffer pool instance being 
created instead of the existing one being reused, while the renderer side would 
still be pointing to buffers of the previous instance.

PatchSet 2 applies a fix for this issue.


Below is the CL description of the original CL:

Decouple VideoCaptureController from VideoCaptureBufferPool and
VideoCaptureDeviceClient. This is needed in order to prepare
VideoCaptureController for working with both the (legacy) in-process video
capture and the new video_capture Mojo service.

List of changes:
* Introduce an abstraction FrameBufferPool for the VideoCaptureController to
  talk to the VideoCaptureBufferPool.
* Move VideoFrameReceiverOnIOThread to separate file.
* Move factory logic for creating and connecting
  VideoCaptureBufferPoolImpl and VideoCaptureDeviceClient out of
  VideoCaptureController and into VideoCaptureManager as well as the tests.
* Update OWNERS to include new file and include chfremer as owner.
* In VideoCaptureDeviceClient: Rename |frame_format| to |foramt|.

This CL is part of the Mojo Video Capture work. For the bigger picture,
see [1] CL1.9.8

BUG=584797
TEST=
  content_unittests,
  video_capture_unittests,
  Apprtc loopback on Debug,
  Desktop Capture Example extension on Release

[1]
https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxs...

Review-Url: https://codereview.chromium.org/2597833002
==========

to

==========
Reland [Mojo Video Capture] Decouple VideoCaptureController from
VideoCaptureBufferPool and VideoCaptureDeviceClient

PatchSet 1 is the state as reviewed and landed previously, see
https://codereview.chromium.org/2551193002/

This state caused a regression where video capture would be stuck in a loop of
old frames on Android when moving the browser to the background and bringing it
back to the foreground. This was caused by a new buffer pool instance being
created instead of the existing one being reused, while the renderer side would
still be pointing to buffers of the previous instance.

PatchSet 2 applies a fix for this issue.

Below is the CL description of the original CL:

Decouple VideoCaptureController from VideoCaptureBufferPool and
VideoCaptureDeviceClient. This is needed in order to prepare
VideoCaptureController for working with both the (legacy) in-process video
capture and the new video_capture Mojo service.

List of changes:
* Introduce an abstraction FrameBufferPool for the VideoCaptureController to
  talk to the VideoCaptureBufferPool.
* Move VideoFrameReceiverOnIOThread to separate file.
* Move factory logic for creating and connecting
  VideoCaptureBufferPoolImpl and VideoCaptureDeviceClient out of
  VideoCaptureController and into VideoCaptureManager as well as the tests.
* Update OWNERS to include new file and include chfremer as owner.
* In VideoCaptureDeviceClient: Rename |frame_format| to |foramt|.

This CL is part of the Mojo Video Capture work. For the bigger picture,
see [1] CL1.9.8

BUG=584797
TEST=
  content_unittests,
  video_capture_unittests,
  Apprtc loopback on Debug,
  Desktop Capture Example extension on Release

[1]
https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxs...

Committed: https://crrev.com/4f85f2f30f051cf961d28b17e3093dbd67c62661
Cr-Commit-Position: refs/heads/master@{#441261}
==========

[commit-bot: I haz the power, 2017-01-04 00:24:45]

Patchset 3 (id:??) landed as
https://crrev.com/4f85f2f30f051cf961d28b17e3093dbd67c62661
Cr-Commit-Position: refs/heads/master@{#441261}