[Mojo Video Capture] Split OnIncomingCapturedVideoFrame() to OnNewBuffer() + OnFrameReadyInBuffer()

[Mojo Video Capture] Split OnIncomingCapturedVideoFrame() to OnNewBuffer() and OnFrameReadyInBuffer()

In interface media::VideoFrameReceiver, instead of method
OnIncomingCapturedVideoFrame() use two methods OnNewBufferHandle() and
OnFrameReadyInBuffer(). This matches the Mojo interface exposed to the Renderers
by VideoCaptureHost. Instead of requiring the VideoFrameReceiver implementation
(VideoCaptureController) to set and release a consumer hold, we pass in a
|buffer_read_permission| that encapsulates the hold using the RAII pattern.
This allows us to remove the |frame_buffer_pool_| member from
VideoCaptureController.

Replace OnBufferDestroyed(), which could only be called while a buffer
was not in use by the VideoFrameReceiver with OnBufferRetired(), which may be
called while a buffer is in use. This is a functional change that is required
for supporting the use case of Android Chromium shutting down the
VideoCaptureDevice and VideoCaptureDeviceClient
when going to the background. Before this CL, the shared buffers and the buffer
pool would be kept alive while in the bakground, and would be reused with newly
created VCDevice and VCDeviceClient when being restored to the foreground.

For the Mojofication, we want to move the VCDevice, VCDeviceClient, and
VCBufferPool behind an abstraction (let's refer to it as AbstractDevice) and run
them in a separate process. With that, shutting down VCDevice, VCDeviceClient
while keeping VCBufferPool and shared buffers alive would mean exposing this as
some new type of "suspended" mode for AbstractDevice (which is different from
the existing suspend/resume).
Instead of this, we opt for the alternative solution, which is to allow a
complete shutdown of AbstractDevice, including the buffer pool, while the app is
in the background. When AbstractDevice shuts down it tells the
VideoFrameReceiver that it is "retiring" the buffers. The VideoFrameReceiver may
keep consuming them as long as it needs, while holding |buffer_read_permission|.

Use struct mojom::VideoFrameInfo when receiving frames as
media::VideoFrameReceiver (e.g. VideoCaptureController). This will allow us to
have it receive frames from the Mojo service in a later step.

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

BUG=584797
TEST=
  content_unittests --gtest_filter="*Video*",
  video_capture_unittests,
  Apprtc loopback on Debug,
  Desktop Capture Example extension on Release
  On Android content_shell, run video capture sample from [2], put to
      background, then restore from background.

[1] https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxsxWslJ_X-zpOhijvI8/edit?usp=sharing
[2] https://webrtc.github.io/samples/src/content/getusermedia/gum/

[chfremer, 2016-12-15 19:24:35]

Description was changed from

==========
presubmit


Merge branch '1.9.10' into 1.9.11


Merge branch '1.9.10' into 1.9.11


Merge branch '1.9.10' into 1.9.11


Merge branch '1.9.10' into 1.9.11


fix after merge


Merge branch '1.9.10' into 1.9.11


Merge branch '1.9.10' into 1.9.11


Merge branch '1.9.10' into 1.9.11


Relax restriction to disallow concurrency.


fix merge error


Add thread checker to secure usage of buffer_ids_known_by_receiver


Merge branch '1.9.10' into 1.9.11


Merge branch '1.9.10' into 1.9.11


Merge branch '1.9.10' into 1.9.11


Merge branch '1.9.10' into 1.9.11


Merge branch '1.9.10' into 1.9.11


Move set consumer hold count out of constructor.


Merge branch '1.9.10' into 1.9.11


Apply patch to 1.9.11

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

to

==========
[Mojo Video Capture] Split OnIncomingCapturedVideoFrame() to OnNewBuffer() and
OnFrameReadyInBuffer()

In interface media::VideoFrameReceiver, instead of method 
OnIncomingCapturedVideoFrame() use two methods OnNewBuffer() and 
OnFrameReadyInBuffer(). OnIncomingCapturedVideoFrame() used to pass along a 
memory-mapped buffer plus a partly redundant media::VideoFrame that had to be 
backed by the same buffer and held metadata about the frame. The 
VideoFrameReceiver had to track and check the buffer's id() each time to find 
out if a given buffer was "new". Instead, OnNewBuffer() tells the 
VideoFrameReceiver that a new buffer is being shared, and OnFrameReadyInBuffer()
tells that new data is ready in a previously shared buffer. This makes it much 
more clear to the reader that the intended usage is that buffers are pre-shared 
and then reused to deliver frames. It also matches the Mojo interface exposed to
the Renderers by VideoCaptureHost.

Use struct mojom::VideoFrameInfo when receiving frames as 
media::VideoFrameReceiver (e.g. VideoCaptureController). This will allow us to 
have it receive frames from the Mojo service in a later step.

VideoCaptureDeviceClient now keeps track of which buffers (ids) have already 
been shared with its |receiver_|. This is in order to be able to correctly 
invoke OnNewBuffer() and OnBufferDestroyed() when needed.

VideoCaptureController now no longer needs to hold references to VideoFrame 
instances.

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

BUG=584797
TEST=
  content_unittests --gtest_filter="*Video*", 
  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 18:40:57]

Patchset #1 (id:1) has been deleted

[chfremer, 2016-12-22 18:48:46]

Description was changed from

==========
[Mojo Video Capture] Split OnIncomingCapturedVideoFrame() to OnNewBuffer() and
OnFrameReadyInBuffer()

In interface media::VideoFrameReceiver, instead of method 
OnIncomingCapturedVideoFrame() use two methods OnNewBuffer() and 
OnFrameReadyInBuffer(). OnIncomingCapturedVideoFrame() used to pass along a 
memory-mapped buffer plus a partly redundant media::VideoFrame that had to be 
backed by the same buffer and held metadata about the frame. The 
VideoFrameReceiver had to track and check the buffer's id() each time to find 
out if a given buffer was "new". Instead, OnNewBuffer() tells the 
VideoFrameReceiver that a new buffer is being shared, and OnFrameReadyInBuffer()
tells that new data is ready in a previously shared buffer. This makes it much 
more clear to the reader that the intended usage is that buffers are pre-shared 
and then reused to deliver frames. It also matches the Mojo interface exposed to
the Renderers by VideoCaptureHost.

Use struct mojom::VideoFrameInfo when receiving frames as 
media::VideoFrameReceiver (e.g. VideoCaptureController). This will allow us to 
have it receive frames from the Mojo service in a later step.

VideoCaptureDeviceClient now keeps track of which buffers (ids) have already 
been shared with its |receiver_|. This is in order to be able to correctly 
invoke OnNewBuffer() and OnBufferDestroyed() when needed.

VideoCaptureController now no longer needs to hold references to VideoFrame 
instances.

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

BUG=584797
TEST=
  content_unittests --gtest_filter="*Video*", 
  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

==========
[Mojo Video Capture] Split OnIncomingCapturedVideoFrame() to OnNewBuffer() and
OnFrameReadyInBuffer()

In interface media::VideoFrameReceiver, instead of method 
OnIncomingCapturedVideoFrame() use two methods OnNewBuffer() and 
OnFrameReadyInBuffer(). OnIncomingCapturedVideoFrame() used to pass along a 
memory-mapped buffer plus a partly redundant media::VideoFrame that had to be 
backed by the same buffer and held metadata about the frame. The 
VideoFrameReceiver had to track and check the buffer's id() each time to find 
out if a given buffer was "new". Instead, OnNewBuffer() tells the 
VideoFrameReceiver that a new buffer is being shared, and OnFrameReadyInBuffer()
tells that new data is ready in a previously shared buffer. This makes it much 
more clear to the reader that the intended usage is that buffers are pre-shared 
and then reused to deliver frames. It also matches the Mojo interface exposed to
the Renderers by VideoCaptureHost.

In order to enable separation of access handles to buffers from
the usage reservation of the content inside the buffers, we split of the 
|reservation| aspect from the |access_provider| in the struct 
media::videoCaptureDevice::Client::Buffer. 

Use struct mojom::VideoFrameInfo when receiving frames as 
media::VideoFrameReceiver (e.g. VideoCaptureController). This will allow us to 
have it receive frames from the Mojo service in a later step.

VideoCaptureDeviceClient now keeps track of which buffers (ids) have already 
been shared with its |receiver_|. This is in order to be able to correctly 
invoke OnNewBuffer() and OnBufferDestroyed() when needed.

VideoCaptureController now no longer needs to hold references to VideoFrame 
instances.

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

BUG=584797
TEST=
  content_unittests --gtest_filter="*Video*", 
  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 18:53:01]

Patchset #1 (id:20001) has been deleted

[chfremer, 2016-12-22 20:49:29]

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

[commit-bot: I haz the power, 2016-12-22 20:49:57]

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, 2016-12-22 21:57:44]

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

[commit-bot: I haz the power, 2016-12-22 21:57:44]

Dry run: Try jobs failed on following builders:
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[chfremer, 2016-12-29 01:24:47]

Patchset #2 (id:60001) has been deleted

[chfremer, 2016-12-29 01:31:03]

Description was changed from

==========
[Mojo Video Capture] Split OnIncomingCapturedVideoFrame() to OnNewBuffer() and
OnFrameReadyInBuffer()

In interface media::VideoFrameReceiver, instead of method 
OnIncomingCapturedVideoFrame() use two methods OnNewBuffer() and 
OnFrameReadyInBuffer(). OnIncomingCapturedVideoFrame() used to pass along a 
memory-mapped buffer plus a partly redundant media::VideoFrame that had to be 
backed by the same buffer and held metadata about the frame. The 
VideoFrameReceiver had to track and check the buffer's id() each time to find 
out if a given buffer was "new". Instead, OnNewBuffer() tells the 
VideoFrameReceiver that a new buffer is being shared, and OnFrameReadyInBuffer()
tells that new data is ready in a previously shared buffer. This makes it much 
more clear to the reader that the intended usage is that buffers are pre-shared 
and then reused to deliver frames. It also matches the Mojo interface exposed to
the Renderers by VideoCaptureHost.

In order to enable separation of access handles to buffers from
the usage reservation of the content inside the buffers, we split of the 
|reservation| aspect from the |access_provider| in the struct 
media::videoCaptureDevice::Client::Buffer. 

Use struct mojom::VideoFrameInfo when receiving frames as 
media::VideoFrameReceiver (e.g. VideoCaptureController). This will allow us to 
have it receive frames from the Mojo service in a later step.

VideoCaptureDeviceClient now keeps track of which buffers (ids) have already 
been shared with its |receiver_|. This is in order to be able to correctly 
invoke OnNewBuffer() and OnBufferDestroyed() when needed.

VideoCaptureController now no longer needs to hold references to VideoFrame 
instances.

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

BUG=584797
TEST=
  content_unittests --gtest_filter="*Video*", 
  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

==========
[Mojo Video Capture] Split OnIncomingCapturedVideoFrame() to OnNewBuffer() and
OnFrameReadyInBuffer()

In interface media::VideoFrameReceiver, instead of method
OnIncomingCapturedVideoFrame() use two methods OnNewBufferHandle() and
OnFrameReadyInBuffer(). This matches the Mojo interface exposed to the Renderers
by VideoCaptureHost. Instead of requiring the VideoFrameReceiver implementation
(VideoCaptureController) to set and release a consumer hold, we pass in a
|buffer_read_permission| that encapsulates the hold using the RAII pattern.
This allows us to remove the |frame_buffer_pool_| member from
VideoCaptureController.

Replace OnBufferDestroyed(), which could only be called while a buffer
was not in use by the VideoFrameReceiver with OnBufferRetired(), which may be
called while a buffer is in use. This is a functional change that is required
for supporting the use case of Android Chromium shutting down the
VideoCaptureDevice and VideoCaptureDeviceClient
when going to the background. Before this CL, the shared buffers and the buffer
pool would be kept alive while in the bakground, and would be reused with newly
created VCDevice and VCDeviceClient when being restored to the foreground.

For the Mojofication, we want to move the VCDevice, VCDeviceClient, and
VCBufferPool behind an abstraction (let's refer to it as AbstractDevice) and run
them in a separate process. With that, shutting down VCDevice, VCDeviceClient
while keeping VCBufferPool and shared buffers alive would mean exposing this as
some new type of "suspended" mode for AbstractDevice (which is different from
the existing suspend/resume).
Instead of this, we opt for the alternative solution, which is to allow a
complete shutdown of AbstractDevice, including the buffer pool, while the app is
in the background. When AbstractDevice shuts down it tells the
VideoFrameReceiver that it is "retiring" the buffers. The VideoFrameReceiver may
keep consuming them as long as it needs, while holding |buffer_read_permission|.

Use struct mojom::VideoFrameInfo when receiving frames as
media::VideoFrameReceiver (e.g. VideoCaptureController). This will allow us to
have it receive frames from the Mojo service in a later step.

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

BUG=584797
TEST=
  content_unittests --gtest_filter="*Video*",
  video_capture_unittests,
  Apprtc loopback on Debug,
  Desktop Capture Example extension on Release
  On Android content_shell, run video capture sample from [2], put to
      background, then restore from background.

[1]
https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxs...
[2] https://webrtc.github.io/samples/src/content/getusermedia/gum/
==========

[chfremer, 2016-12-29 20:02:08]

Closing this, because it has been split into two CLs:
https://codereview.chromium.org/2607203002/
https://codereview.chromium.org/2602983002/