Let clients interact with VideoCaptureDeviceClient instead of VideoCaptureDevice

Modify the Mojo interfaces so that clients interact with the VideoCaptureDeviceClient interface instead of VideoCaptureDevice.

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

* Instead of exposing the interface mojom::VideoCaptureDeviceClient
  (which is the mojo equivalent of media::VideoCaptureDevice::Client)
  to clients of the Mojo service, use the implementation
  media::VideoCaptureDeviceClient inside the service and expose its
  client interface (media::VideoFrameReceiver) as mojom::VideoFrameReceiver
  to clients of the service.
* Add class video_capture::BufferTrackerFactory, and use it as the Mojo
  service's implementation of media::VideoCaptureBufferTrackerFactory
  required to operate the media::VideoCaptureDeviceClient. The buffers
  it creates are backed by MojoSharedBufferVideoFrames.
* Add support to VideoCaptureDeviceClient for buffers that are backed
  by video frames in order to avoid wrapping the
  MojoSharedBufferVideoFrame-backed buffers in another VideoFrame.

BUG=584797
TEST=content_unittest, capture_unittest, video_capture_unittest

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

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

[chfremer, 2016-09-29 00:00:05]

Description was changed from

==========
Merge branch 'Part_0' into Part_1


fix presubmit


Merge branch 'Part_0' into Part_1


Merge branch 'Part_0' into Part_1


Fix build of content_unittest


Apply patch part1.diff

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

to

==========
Modify the Mojo interfaces so that clients interact with the
VideoCaptureDeviceClient interface instead of VideoCaptureDevice.

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

* Instead of exposing the interface mojom::VideoCaptureDeviceClient 
  (which is the mojo equivalent of media::VideoCaptureDevice::Client) 
  to clients of the Mojo service, use the implementation 
  media::VideoCaptureDeviceClient inside the service and expose its 
  client interface (media::VideoFrameReceiver) as mojom::VideoFrameReceiver 
  to clients of the service.
* Add class video_capture::BufferTrackerFactory, and use it as the Mojo 
  service's implementation of media::VideoCaptureBufferTrackerFactory 
  required to operate the media::VideoCaptureDeviceClient. The buffers 
  it creates are backed by MojoSharedBufferVideoFrames.
* Add support to VideoCaptureDeviceClient for buffers that are backed 
  by video frames in order to avoid wrapping the 
  MojoSharedBufferVideoFrame-backed buffers in another VideoFrame.

BUG=584797
TEST=content_unittest, capture_unittest, video_capture_unittest

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

[chfremer, 2016-09-29 00:11:58]

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

[chfremer, 2016-09-29 00:11:59]

mcasas@: PTAL
emircan@: FIY

Note: Lots of files touched, but most of them with canonical change.

[mcasas, 2016-10-05 02:43:48]

looking good, but it's so large that I
can't seem to have a long enough
timespan to comprehend its entirety.
Will come back to it, please try and
have smaller patches :)

[mcasas, 2016-10-05 17:24:00]

lgtm with comments, and
I'd like emircan@ to take
a look at it as well.

https://codereview.chromium.org/2378943002/diff/20001/services/video_capture/...
File services/video_capture/receiver_mojo_to_media_adapter.cc (right):

https://codereview.chromium.org/2378943002/diff/20001/services/video_capture/...
services/video_capture/receiver_mojo_to_media_adapter.cc:16: // TODO: remove
|params| if not needed
Not needed now, right? Remove.

https://codereview.chromium.org/2378943002/diff/20001/services/video_capture/...
services/video_capture/receiver_mojo_to_media_adapter.cc:41: // Q: How does
client tell service that it is finished with a buffer?
This Qs have to turn into TODOs or, if observations
 (l.24), then just write prose.

[chfremer, 2016-10-05 23:30:28]

https://codereview.chromium.org/2378943002/diff/20001/services/video_capture/...
File services/video_capture/receiver_mojo_to_media_adapter.cc (right):

https://codereview.chromium.org/2378943002/diff/20001/services/video_capture/...
services/video_capture/receiver_mojo_to_media_adapter.cc:16: // TODO: remove
|params| if not needed
On 2016/10/05 17:24:00, mcasas wrote:
> Not needed now, right? Remove.

Done.

https://codereview.chromium.org/2378943002/diff/20001/services/video_capture/...
services/video_capture/receiver_mojo_to_media_adapter.cc:41: // Q: How does
client tell service that it is finished with a buffer?
On 2016/10/05 17:24:00, mcasas wrote:
> This Qs have to turn into TODOs or, if observations
>  (l.24), then just write prose.

Done.

[chfremer, 2016-10-10 16:40:50]

On 2016/10/05 23:30:28, chfremer wrote:
>
https://codereview.chromium.org/2378943002/diff/20001/services/video_capture/...
> File services/video_capture/receiver_mojo_to_media_adapter.cc (right):
> 
>
https://codereview.chromium.org/2378943002/diff/20001/services/video_capture/...
> services/video_capture/receiver_mojo_to_media_adapter.cc:16: // TODO: remove
> |params| if not needed
> On 2016/10/05 17:24:00, mcasas wrote:
> > Not needed now, right? Remove.
> 
> Done.
> 
>
https://codereview.chromium.org/2378943002/diff/20001/services/video_capture/...
> services/video_capture/receiver_mojo_to_media_adapter.cc:41: // Q: How does
> client tell service that it is finished with a buffer?
> On 2016/10/05 17:24:00, mcasas wrote:
> > This Qs have to turn into TODOs or, if observations
> >  (l.24), then just write prose.
> 
> Done.

ping, emircan@ PTAL

[emircan, 2016-10-10 18:46:13]

lgtm % nits.

https://codereview.chromium.org/2378943002/diff/40001/media/capture/video/vid...
File media/capture/video/video_capture_buffer_handle.h (right):

https://codereview.chromium.org/2378943002/diff/40001/media/capture/video/vid...
media/capture/video/video_capture_buffer_handle.h:23: virtual ClientBuffer
AsClientBuffer(int plane) = 0;
Can you remove this method AsClientBuffer()? I missed it in my cleanup.

https://codereview.chromium.org/2378943002/diff/40001/media/capture/video/vid...
File media/capture/video/video_capture_device_client.cc (right):

https://codereview.chromium.org/2378943002/diff/40001/media/capture/video/vid...
media/capture/video/video_capture_device_client.cc:334: void
VideoCaptureDeviceClient::OnIncomingCapturedVideoFrame(
As we discussed, lets add a TODO to remove this class. If we can send a metadata
to OnIncomingCapturedBuffer(), this wouldn't be necessary.

https://codereview.chromium.org/2378943002/diff/40001/services/video_capture/...
File services/video_capture/mojo_shared_memory_buffer_tracker.cc (right):

https://codereview.chromium.org/2378943002/diff/40001/services/video_capture/...
services/video_capture/mojo_shared_memory_buffer_tracker.cc:36: dimensions,
base::TimeDelta());
As I explained offline, sending these buffers might result in an extra copy
compared to the current case when using HW encoders. In order to share the
buffers from renderer to gpu process, we need a shmem handle as it is still via
IPC. MojoSharedBufferVideoFrame will be copied in RTCVideoEncoder currently.

https://cs.chromium.org/chromium/src/content/renderer/media/gpu/rtc_video_enc...
https://cs.chromium.org/chromium/src/media/gpu/ipc/client/gpu_video_encode_ac...

[chfremer, 2016-10-11 19:09:06]

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

[chfremer, 2016-10-11 19:09:07]

tsepez@: PTAL *.mojom
avi@: Please RS web_contents_video_capture_device_unittest.cc

https://codereview.chromium.org/2378943002/diff/40001/media/capture/video/vid...
File media/capture/video/video_capture_buffer_handle.h (right):

https://codereview.chromium.org/2378943002/diff/40001/media/capture/video/vid...
media/capture/video/video_capture_buffer_handle.h:23: virtual ClientBuffer
AsClientBuffer(int plane) = 0;
On 2016/10/10 18:46:13, emircan wrote:
> Can you remove this method AsClientBuffer()? I missed it in my cleanup.

Done.

https://codereview.chromium.org/2378943002/diff/40001/media/capture/video/vid...
File media/capture/video/video_capture_device_client.cc (right):

https://codereview.chromium.org/2378943002/diff/40001/media/capture/video/vid...
media/capture/video/video_capture_device_client.cc:334: void
VideoCaptureDeviceClient::OnIncomingCapturedVideoFrame(
On 2016/10/10 18:46:13, emircan wrote:
> As we discussed, lets add a TODO to remove this class. If we can send a
metadata
> to OnIncomingCapturedBuffer(), this wouldn't be necessary.

Done. Added the TODO to the interface.

https://codereview.chromium.org/2378943002/diff/40001/services/video_capture/...
File services/video_capture/mojo_shared_memory_buffer_tracker.cc (right):

https://codereview.chromium.org/2378943002/diff/40001/services/video_capture/...
services/video_capture/mojo_shared_memory_buffer_tracker.cc:36: dimensions,
base::TimeDelta());
On 2016/10/10 18:46:13, emircan wrote:
> As I explained offline, sending these buffers might result in an extra copy
> compared to the current case when using HW encoders. In order to share the
> buffers from renderer to gpu process, we need a shmem handle as it is still
via
> IPC. MojoSharedBufferVideoFrame will be copied in RTCVideoEncoder currently.
> 
>
https://cs.chromium.org/chromium/src/content/renderer/media/gpu/rtc_video_enc...
>
https://cs.chromium.org/chromium/src/media/gpu/ipc/client/gpu_video_encode_ac...

Thanks. I have added a task to the design doc for dealing with this.

[chfremer, 2016-10-11 19:09:16]

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

[commit-bot: I haz the power, 2016-10-11 19:09:57]

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

[Avi (use Gerrit), 2016-10-11 19:37:54]

lgtm

content/browser/media/capture/web_contents_video_capture_device_unittest.cc
stamp

[Tom Sepez, 2016-10-11 20:32:25]

.mojom LGTM

[commit-bot: I haz the power, 2016-10-11 21:05:53]

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

[commit-bot: I haz the power, 2016-10-11 21:05:54]

Dry run: This issue passed the CQ dry run.

[chfremer, 2016-10-11 21:15:34]

The CQ bit was checked by chfremer@chromium.org

[chfremer, 2016-10-11 21:15:34]

The patchset sent to the CQ was uploaded after l-g-t-m from mcasas@chromium.org,
emircan@chromium.org
Link to the patchset: https://codereview.chromium.org/2378943002/#ps80001
(title: "Remove method AsClientBuffer()")

[commit-bot: I haz the power, 2016-10-11 21:15:49]

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, 2016-10-11 21:34:31]

Description was changed from

==========
Modify the Mojo interfaces so that clients interact with the
VideoCaptureDeviceClient interface instead of VideoCaptureDevice.

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

* Instead of exposing the interface mojom::VideoCaptureDeviceClient 
  (which is the mojo equivalent of media::VideoCaptureDevice::Client) 
  to clients of the Mojo service, use the implementation 
  media::VideoCaptureDeviceClient inside the service and expose its 
  client interface (media::VideoFrameReceiver) as mojom::VideoFrameReceiver 
  to clients of the service.
* Add class video_capture::BufferTrackerFactory, and use it as the Mojo 
  service's implementation of media::VideoCaptureBufferTrackerFactory 
  required to operate the media::VideoCaptureDeviceClient. The buffers 
  it creates are backed by MojoSharedBufferVideoFrames.
* Add support to VideoCaptureDeviceClient for buffers that are backed 
  by video frames in order to avoid wrapping the 
  MojoSharedBufferVideoFrame-backed buffers in another VideoFrame.

BUG=584797
TEST=content_unittest, capture_unittest, video_capture_unittest

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

to

==========
Modify the Mojo interfaces so that clients interact with the
VideoCaptureDeviceClient interface instead of VideoCaptureDevice.

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

* Instead of exposing the interface mojom::VideoCaptureDeviceClient 
  (which is the mojo equivalent of media::VideoCaptureDevice::Client) 
  to clients of the Mojo service, use the implementation 
  media::VideoCaptureDeviceClient inside the service and expose its 
  client interface (media::VideoFrameReceiver) as mojom::VideoFrameReceiver 
  to clients of the service.
* Add class video_capture::BufferTrackerFactory, and use it as the Mojo 
  service's implementation of media::VideoCaptureBufferTrackerFactory 
  required to operate the media::VideoCaptureDeviceClient. The buffers 
  it creates are backed by MojoSharedBufferVideoFrames.
* Add support to VideoCaptureDeviceClient for buffers that are backed 
  by video frames in order to avoid wrapping the 
  MojoSharedBufferVideoFrame-backed buffers in another VideoFrame.

BUG=584797
TEST=content_unittest, capture_unittest, video_capture_unittest

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

[commit-bot: I haz the power, 2016-10-11 21:34:38]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-10-11 21:39:33]

Description was changed from

==========
Modify the Mojo interfaces so that clients interact with the
VideoCaptureDeviceClient interface instead of VideoCaptureDevice.

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

* Instead of exposing the interface mojom::VideoCaptureDeviceClient 
  (which is the mojo equivalent of media::VideoCaptureDevice::Client) 
  to clients of the Mojo service, use the implementation 
  media::VideoCaptureDeviceClient inside the service and expose its 
  client interface (media::VideoFrameReceiver) as mojom::VideoFrameReceiver 
  to clients of the service.
* Add class video_capture::BufferTrackerFactory, and use it as the Mojo 
  service's implementation of media::VideoCaptureBufferTrackerFactory 
  required to operate the media::VideoCaptureDeviceClient. The buffers 
  it creates are backed by MojoSharedBufferVideoFrames.
* Add support to VideoCaptureDeviceClient for buffers that are backed 
  by video frames in order to avoid wrapping the 
  MojoSharedBufferVideoFrame-backed buffers in another VideoFrame.

BUG=584797
TEST=content_unittest, capture_unittest, video_capture_unittest

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

to

==========
Modify the Mojo interfaces so that clients interact with the
VideoCaptureDeviceClient interface instead of VideoCaptureDevice.

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

* Instead of exposing the interface mojom::VideoCaptureDeviceClient
  (which is the mojo equivalent of media::VideoCaptureDevice::Client)
  to clients of the Mojo service, use the implementation
  media::VideoCaptureDeviceClient inside the service and expose its
  client interface (media::VideoFrameReceiver) as mojom::VideoFrameReceiver
  to clients of the service.
* Add class video_capture::BufferTrackerFactory, and use it as the Mojo
  service's implementation of media::VideoCaptureBufferTrackerFactory
  required to operate the media::VideoCaptureDeviceClient. The buffers
  it creates are backed by MojoSharedBufferVideoFrames.
* Add support to VideoCaptureDeviceClient for buffers that are backed
  by video frames in order to avoid wrapping the
  MojoSharedBufferVideoFrame-backed buffers in another VideoFrame.

BUG=584797
TEST=content_unittest, capture_unittest, video_capture_unittest

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

Committed: https://crrev.com/a15bab53286e1800eed33dbc3619ccd957e9bf0d
Cr-Commit-Position: refs/heads/master@{#424550}
==========

[commit-bot: I haz the power, 2016-10-11 21:39:34]

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