Revert of Reland [Mojo Video Capture] Replace method OnIncomingCapturedVideoFrame() with OnIncomingCapturedBuf

Revert of Reland [Mojo Video Capture] Replace method OnIncomingCapturedVideoFrame() with OnIncomingCapturedBuf (patchset #2 id:20001 of https://codereview.chromium.org/2592303002/ )

Reason for revert:
This caused a crash during video capture, see 
https://bugs.chromium.org/p/chromium/issues/detail?id=678766

Original issue's description:
> Reland [Mojo Video Capture] Replace method OnIncomingCapturedVideoFrame() with OnIncomingCapturedBufferExt()
> 
> This is exactly the same as reviewed previously
> https://codereview.chromium.org/2592303002/
> 
> The reason for the revert was a crash in a performance test on Android, which
> pointed to a bad file handle while Mojo-unwrapping a shared buffer. This was
> most likely caused by the same bug 675528 that was just fixed for the previous
> CL1.9.8. I ran the test on a local Android device an confirmed that it is no
> longer crashing.
> 
> Description of original CL:
> 
> 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/fc2e2a6f6597cf6582673572bbf22268e445dac0
> Cr-Commit-Position: refs/heads/master@{#441391}

TBR=mcasas@chromium.org,miu@chromium.org,chfremer@google.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=584797
Review-Url: https://codereview.chromium.org/2618173002
Cr-Commit-Position: refs/heads/master@{#442148}
Committed: https://chromium.googlesource.com/chromium/src/+/ce807707f40a88316d193941c31b196f15e138ba

[chfremer, 2017-01-07 01:24:22]

The CQ bit was checked by chfremer@chromium.org

[chfremer, 2017-01-07 01:24:22]

Created Revert of Reland [Mojo Video Capture] Replace method
OnIncomingCapturedVideoFrame() with OnIncomingCapturedBuf

[commit-bot: I haz the power, 2017-01-07 03:18:10]

Description was changed from

==========
Revert of Reland [Mojo Video Capture] Replace method
OnIncomingCapturedVideoFrame() with OnIncomingCapturedBuf (patchset #2 id:20001
of https://codereview.chromium.org/2592303002/ )

Reason for revert:
This caused a crash during video capture, see 
https://bugs.chromium.org/p/chromium/issues/detail?id=678766

Original issue's description:
> Reland [Mojo Video Capture] Replace method OnIncomingCapturedVideoFrame() with
OnIncomingCapturedBufferExt()
> 
> This is exactly the same as reviewed previously
> https://codereview.chromium.org/2592303002/
> 
> The reason for the revert was a crash in a performance test on Android, which
> pointed to a bad file handle while Mojo-unwrapping a shared buffer. This was
> most likely caused by the same bug 675528 that was just fixed for the previous
> CL1.9.8. I ran the test on a local Android device an confirmed that it is no
> longer crashing.
> 
> Description of original CL:
> 
> 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/fc2e2a6f6597cf6582673572bbf22268e445dac0
> Cr-Commit-Position: refs/heads/master@{#441391}

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

to

==========
Revert of Reland [Mojo Video Capture] Replace method
OnIncomingCapturedVideoFrame() with OnIncomingCapturedBuf (patchset #2 id:20001
of https://codereview.chromium.org/2592303002/ )

Reason for revert:
This caused a crash during video capture, see 
https://bugs.chromium.org/p/chromium/issues/detail?id=678766

Original issue's description:
> Reland [Mojo Video Capture] Replace method OnIncomingCapturedVideoFrame() with
OnIncomingCapturedBufferExt()
> 
> This is exactly the same as reviewed previously
> https://codereview.chromium.org/2592303002/
> 
> The reason for the revert was a crash in a performance test on Android, which
> pointed to a bad file handle while Mojo-unwrapping a shared buffer. This was
> most likely caused by the same bug 675528 that was just fixed for the previous
> CL1.9.8. I ran the test on a local Android device an confirmed that it is no
> longer crashing.
> 
> Description of original CL:
> 
> 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/fc2e2a6f6597cf6582673572bbf22268e445dac0
> Cr-Commit-Position: refs/heads/master@{#441391}

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

Review-Url: https://codereview.chromium.org/2618173002
Cr-Commit-Position: refs/heads/master@{#442148}
Committed:
https://chromium.googlesource.com/chromium/src/+/ce807707f40a88316d193941c31b...
==========