Revert of [Mojo Video Capture] Replace method OnIncomingCapturedVideoFrame with OnIncomingCapturedBufferExt

Revert of [Mojo Video Capture] Replace method OnIncomingCapturedVideoFrame with OnIncomingCapturedBufferExt (patchset #3 id:80001 of https://codereview.chromium.org/2566983007/ )

Reason for revert:
Broke a test in webrtc.peerconnection, see crbug.com/675020

Original issue's description:
> [Mojo Video Capture] Replace method OnIncomingCapturedVideoFrame() with OnIncomingCapturedBufferExt()
>
> In interface media:VideoCaptureDevice::Client, replaced the method
> OnIncomingCapturedVideoFrame() with OnIncomingCapturedBufferExt(). Compared to
> method OnIncomingCaptureBuffer(), the VideoFrame parameter in
> OnIncomingCapturedVideoFrame() was only used for passing along a bit of extra
> information, namely a custom |visible_rect| as well as some
> |additional_metadata|. The new method makes the intent clear and eliminates the
> need for passing a media::VideoFrame that is partly redundant with the also
> passed media::VideoCaptureDevice::Client::Buffer.
>
> This CL breaks the video_capture_unittests, because current implementation of
> the video_capture service wants to use VideoCaptureDeviceClient with buffers
> that are backed by MojoSharedMemoryBufferTracker instances instead of the "regular" shared memory buffers. With this CL, VideoCaptureDeviceClient is
> dropping support for this. We are working towards making the video_capture
> service work with the regular buffers. To keep CLs small, we defer changes
> to the service to after refactorings of VideoCaptureController and
> VideoCaptureManager are complete and deactive the video_capture_unittests
> temporarily. This is acceptable for the time being, since they are not run on
> the bots yet. The CL that re-enables them is currently labeled CL1.9.22 in the
> design doc.
>
> This CL is part of the Mojo Video Capture work. For the bigger picture,
> see [1] CL1.9.9
>
> 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/1Qw7rw1AJy0QHXjha36jZNiEuxsxWslJ_X-zpOhijvI8/edit?usp=sharing
>
> Committed: https://crrev.com/ae6dc27e5d3233ceeb8397debaa745577b3312da
> Cr-Commit-Position: refs/heads/master@{#438673}

TBR=miu@chromium.org,mcasas@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=584797
Committed: https://crrev.com/6d7035123762737c17d709f17791040bec4ec9b9
Cr-Commit-Position: refs/heads/master@{#439233}

[chfremer, 2016-12-16 21:59:23]

The CQ bit was checked by chfremer@chromium.org

[chfremer, 2016-12-16 21:59:23]

Created Revert of [Mojo Video Capture] Replace method
OnIncomingCapturedVideoFrame with OnIncomingCapturedBufferExt

[commit-bot: I haz the power, 2016-12-16 23:47:57]

Description was changed from

==========
Revert of [Mojo Video Capture] Replace method OnIncomingCapturedVideoFrame with
OnIncomingCapturedBufferExt (patchset #3 id:80001 of
https://codereview.chromium.org/2566983007/ )

Reason for revert:
Broke a test in webrtc.peerconnection, see crbug.com/675020

Original issue's description:
> [Mojo Video Capture] Replace method OnIncomingCapturedVideoFrame() with
OnIncomingCapturedBufferExt()
> 
> In interface media:VideoCaptureDevice::Client, replaced the method
> OnIncomingCapturedVideoFrame() with OnIncomingCapturedBufferExt(). Compared to
> method OnIncomingCaptureBuffer(), the VideoFrame parameter in
> OnIncomingCapturedVideoFrame() was only used for passing along a bit of extra
> information, namely a custom |visible_rect| as well as some
> |additional_metadata|. The new method makes the intent clear and eliminates
the
> need for passing a media::VideoFrame that is partly redundant with the also
> passed media::VideoCaptureDevice::Client::Buffer.
> 
> This CL breaks the video_capture_unittests, because current implementation of
> the video_capture service wants to use VideoCaptureDeviceClient with buffers
> that are backed by MojoSharedMemoryBufferTracker instances instead of the
"regular" shared memory buffers. With this CL, VideoCaptureDeviceClient is
> dropping support for this. We are working towards making the video_capture
> service work with the regular buffers. To keep CLs small, we defer changes
> to the service to after refactorings of VideoCaptureController and
> VideoCaptureManager are complete and deactive the video_capture_unittests
> temporarily. This is acceptable for the time being, since they are not run on
> the bots yet. The CL that re-enables them is currently labeled CL1.9.22 in the
> design doc.
> 
> This CL is part of the Mojo Video Capture work. For the bigger picture,
> see [1] CL1.9.9
> 
> 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...
> 
> Committed: https://crrev.com/ae6dc27e5d3233ceeb8397debaa745577b3312da
> Cr-Commit-Position: refs/heads/master@{#438673}

TBR=miu@chromium.org,mcasas@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=584797
==========

to

==========
Revert of [Mojo Video Capture] Replace method OnIncomingCapturedVideoFrame with
OnIncomingCapturedBufferExt (patchset #3 id:80001 of
https://codereview.chromium.org/2566983007/ )

Reason for revert:
Broke a test in webrtc.peerconnection, see crbug.com/675020

Original issue's description:
> [Mojo Video Capture] Replace method OnIncomingCapturedVideoFrame() with
OnIncomingCapturedBufferExt()
> 
> In interface media:VideoCaptureDevice::Client, replaced the method
> OnIncomingCapturedVideoFrame() with OnIncomingCapturedBufferExt(). Compared to
> method OnIncomingCaptureBuffer(), the VideoFrame parameter in
> OnIncomingCapturedVideoFrame() was only used for passing along a bit of extra
> information, namely a custom |visible_rect| as well as some
> |additional_metadata|. The new method makes the intent clear and eliminates
the
> need for passing a media::VideoFrame that is partly redundant with the also
> passed media::VideoCaptureDevice::Client::Buffer.
> 
> This CL breaks the video_capture_unittests, because current implementation of
> the video_capture service wants to use VideoCaptureDeviceClient with buffers
> that are backed by MojoSharedMemoryBufferTracker instances instead of the
"regular" shared memory buffers. With this CL, VideoCaptureDeviceClient is
> dropping support for this. We are working towards making the video_capture
> service work with the regular buffers. To keep CLs small, we defer changes
> to the service to after refactorings of VideoCaptureController and
> VideoCaptureManager are complete and deactive the video_capture_unittests
> temporarily. This is acceptable for the time being, since they are not run on
> the bots yet. The CL that re-enables them is currently labeled CL1.9.22 in the
> design doc.
> 
> This CL is part of the Mojo Video Capture work. For the bigger picture,
> see [1] CL1.9.9
> 
> 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...
> 
> Committed: https://crrev.com/ae6dc27e5d3233ceeb8397debaa745577b3312da
> Cr-Commit-Position: refs/heads/master@{#438673}

TBR=miu@chromium.org,mcasas@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=584797

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

[commit-bot: I haz the power, 2016-12-16 23:50:14]

Description was changed from

==========
Revert of [Mojo Video Capture] Replace method OnIncomingCapturedVideoFrame with
OnIncomingCapturedBufferExt (patchset #3 id:80001 of
https://codereview.chromium.org/2566983007/ )

Reason for revert:
Broke a test in webrtc.peerconnection, see crbug.com/675020

Original issue's description:
> [Mojo Video Capture] Replace method OnIncomingCapturedVideoFrame() with
OnIncomingCapturedBufferExt()
> 
> In interface media:VideoCaptureDevice::Client, replaced the method
> OnIncomingCapturedVideoFrame() with OnIncomingCapturedBufferExt(). Compared to
> method OnIncomingCaptureBuffer(), the VideoFrame parameter in
> OnIncomingCapturedVideoFrame() was only used for passing along a bit of extra
> information, namely a custom |visible_rect| as well as some
> |additional_metadata|. The new method makes the intent clear and eliminates
the
> need for passing a media::VideoFrame that is partly redundant with the also
> passed media::VideoCaptureDevice::Client::Buffer.
> 
> This CL breaks the video_capture_unittests, because current implementation of
> the video_capture service wants to use VideoCaptureDeviceClient with buffers
> that are backed by MojoSharedMemoryBufferTracker instances instead of the
"regular" shared memory buffers. With this CL, VideoCaptureDeviceClient is
> dropping support for this. We are working towards making the video_capture
> service work with the regular buffers. To keep CLs small, we defer changes
> to the service to after refactorings of VideoCaptureController and
> VideoCaptureManager are complete and deactive the video_capture_unittests
> temporarily. This is acceptable for the time being, since they are not run on
> the bots yet. The CL that re-enables them is currently labeled CL1.9.22 in the
> design doc.
> 
> This CL is part of the Mojo Video Capture work. For the bigger picture,
> see [1] CL1.9.9
> 
> 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...
> 
> Committed: https://crrev.com/ae6dc27e5d3233ceeb8397debaa745577b3312da
> Cr-Commit-Position: refs/heads/master@{#438673}

TBR=miu@chromium.org,mcasas@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=584797

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

to

==========
Revert of [Mojo Video Capture] Replace method OnIncomingCapturedVideoFrame with
OnIncomingCapturedBufferExt (patchset #3 id:80001 of
https://codereview.chromium.org/2566983007/ )

Reason for revert:
Broke a test in webrtc.peerconnection, see crbug.com/675020

Original issue's description:
> [Mojo Video Capture] Replace method OnIncomingCapturedVideoFrame() with
OnIncomingCapturedBufferExt()
>
> In interface media:VideoCaptureDevice::Client, replaced the method
> OnIncomingCapturedVideoFrame() with OnIncomingCapturedBufferExt(). Compared to
> method OnIncomingCaptureBuffer(), the VideoFrame parameter in
> OnIncomingCapturedVideoFrame() was only used for passing along a bit of extra
> information, namely a custom |visible_rect| as well as some
> |additional_metadata|. The new method makes the intent clear and eliminates
the
> need for passing a media::VideoFrame that is partly redundant with the also
> passed media::VideoCaptureDevice::Client::Buffer.
>
> This CL breaks the video_capture_unittests, because current implementation of
> the video_capture service wants to use VideoCaptureDeviceClient with buffers
> that are backed by MojoSharedMemoryBufferTracker instances instead of the
"regular" shared memory buffers. With this CL, VideoCaptureDeviceClient is
> dropping support for this. We are working towards making the video_capture
> service work with the regular buffers. To keep CLs small, we defer changes
> to the service to after refactorings of VideoCaptureController and
> VideoCaptureManager are complete and deactive the video_capture_unittests
> temporarily. This is acceptable for the time being, since they are not run on
> the bots yet. The CL that re-enables them is currently labeled CL1.9.22 in the
> design doc.
>
> This CL is part of the Mojo Video Capture work. For the bigger picture,
> see [1] CL1.9.9
>
> 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...
>
> Committed: https://crrev.com/ae6dc27e5d3233ceeb8397debaa745577b3312da
> Cr-Commit-Position: refs/heads/master@{#438673}

TBR=miu@chromium.org,mcasas@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=584797

Committed: https://crrev.com/6d7035123762737c17d709f17791040bec4ec9b9
Cr-Commit-Position: refs/heads/master@{#439233}
==========