Reland [Mojo Video Capture] Simplify media::VideoCaptureDevice::Client:Buffer to a struct

Reland [Mojo Video Capture] Simplify media::VideoCaptureDevice::Client:Buffer to a struct

PatchSet#1 is the state as previously reviewed, landed, reverted, and merged 
with the fix from https://codereview.chromium.org/2621743002/.

PatchSet#2: Because the original CL introduced another new 
SharedMemoryHandle-not-getting-closed issue, this PatchSet has the fix for this.
Instead of fixing this by attaching ownership of the handle to a VideoFrame, I 
decided to instead add a method 
GetNonOwnedSharedMemoryHandleForLegacyIPC() to interface 
VideoCaptureDevice::Client::Buffer::HandleProvider. This allows us to avoid the 
otherwise introduced extra step of wrapping/unwrapping a new file handle copy.


Description of original CL:

In interface media::VideoCaptureDevice::Client, change interface Buffer to a 
move-only struct. The new struct separates the concerns of providing access 
handles (for in-process as well as for inter-process transit) from access 
permissions. This allows clients to explicitly obtain in-process memory-mapped 
handles when they need it. Clients who only want to pass along the buffer or 
move it across process boundaries do not need memory-mapped handles.

In interface media::VideoCaptureBufferPool, renamed 
 GetBufferHandle() -> GetHandleForInProcessAccess()
 GetHandleForTransit() -> GetHandleForInterProcessTransit().

Removed outdated implementation in video_capture Mojo service. We leave the 
implementation empty, until refactoring the interfaces has been completed. 

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

For a peek at the follow-up CLs, please see 
https://codereview.chromium.org/2607203002/
https://codereview.chromium.org/2602983002/

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

Review-Url: https://codereview.chromium.org/2573223002
Cr-Original-Commit-Position: refs/heads/master@{#442066}
Committed: https://chromium.googlesource.com/chromium/src/+/e1aac992b0399db7776661f4ac2c43094c265de7
Review-Url: https://codereview.chromium.org/2620763003
Cr-Commit-Position: refs/heads/master@{#444191}
Committed: https://chromium.googlesource.com/chromium/src/+/03c86be79f1ccae3c1923d1cff9106d15abdbf21

[chfremer, 2017-01-09 23:09:32]

Description was changed from

==========
As reviewed previously with fix from parent CL merged in

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

to

==========
Reland [Mojo Video Capture] Simplify media::VideoCaptureDevice::Client:Buffer to
a struct

PatchSet#1 is the state as previously reviewed, landed, reverted, and merged 
with the fix from https://codereview.chromium.org/2621743002/.

PatchSet#2 mitigates the same kind of issue (SharedMemoryHandle not closed) that
was introduced in the original CL. Instead of fixing this by attaching ownership
of the handle to a VideoFrame, I decided to instead add a method 
GetNonOwnedSharedMemoryHandleForLegacyIPC() to interface 
VideoCaptureDevice::Client::Buffer::HandleProvider. This allows us to avoid the 
otherwise introduced extra step of wrapping/unwrapping a new file handle copy.


Description of original CL:

In interface media::VideoCaptureDevice::Client, change interface Buffer to a 
move-only struct. The new struct separates the concerns of providing access 
handles (for in-process as well as for inter-process transit) from access 
permissions. This allows clients to explicitly obtain in-process memory-mapped 
handles when they need it. Clients who only want to pass along the buffer or 
move it across process boundaries do not need memory-mapped handles.

In interface media::VideoCaptureBufferPool, renamed 
 GetBufferHandle() -> GetHandleForInProcessAccess()
 GetHandleForTransit() -> GetHandleForInterProcessTransit().

Removed outdated implementation in video_capture Mojo service. We leave the 
implementation empty, until refactoring the interfaces has been completed. 

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

For a peek at the follow-up CLs, please see 
https://codereview.chromium.org/2607203002/
https://codereview.chromium.org/2602983002/

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...

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

[chfremer, 2017-01-09 23:10:54]

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

[commit-bot: I haz the power, 2017-01-09 23:11:54]

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-10 01:30:55]

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

[commit-bot: I haz the power, 2017-01-10 01:30:56]

Dry run: This issue passed the CQ dry run.

[chfremer, 2017-01-11 17:49:35]

Description was changed from

==========
Reland [Mojo Video Capture] Simplify media::VideoCaptureDevice::Client:Buffer to
a struct

PatchSet#1 is the state as previously reviewed, landed, reverted, and merged 
with the fix from https://codereview.chromium.org/2621743002/.

PatchSet#2 mitigates the same kind of issue (SharedMemoryHandle not closed) that
was introduced in the original CL. Instead of fixing this by attaching ownership
of the handle to a VideoFrame, I decided to instead add a method 
GetNonOwnedSharedMemoryHandleForLegacyIPC() to interface 
VideoCaptureDevice::Client::Buffer::HandleProvider. This allows us to avoid the 
otherwise introduced extra step of wrapping/unwrapping a new file handle copy.


Description of original CL:

In interface media::VideoCaptureDevice::Client, change interface Buffer to a 
move-only struct. The new struct separates the concerns of providing access 
handles (for in-process as well as for inter-process transit) from access 
permissions. This allows clients to explicitly obtain in-process memory-mapped 
handles when they need it. Clients who only want to pass along the buffer or 
move it across process boundaries do not need memory-mapped handles.

In interface media::VideoCaptureBufferPool, renamed 
 GetBufferHandle() -> GetHandleForInProcessAccess()
 GetHandleForTransit() -> GetHandleForInterProcessTransit().

Removed outdated implementation in video_capture Mojo service. We leave the 
implementation empty, until refactoring the interfaces has been completed. 

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

For a peek at the follow-up CLs, please see 
https://codereview.chromium.org/2607203002/
https://codereview.chromium.org/2602983002/

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...

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

to

==========
Reland [Mojo Video Capture] Simplify media::VideoCaptureDevice::Client:Buffer to
a struct

PatchSet#1 is the state as previously reviewed, landed, reverted, and merged 
with the fix from https://codereview.chromium.org/2621743002/.

PatchSet#2: Because the original CL introduced another new 
SharedMemoryHandle-not-getting-closed issue, this PatchSet has the fix for this.
Instead of fixing this by attaching ownership of the handle to a VideoFrame, I 
decided to instead add a method 
GetNonOwnedSharedMemoryHandleForLegacyIPC() to interface 
VideoCaptureDevice::Client::Buffer::HandleProvider. This allows us to avoid the 
otherwise introduced extra step of wrapping/unwrapping a new file handle copy.


Description of original CL:

In interface media::VideoCaptureDevice::Client, change interface Buffer to a 
move-only struct. The new struct separates the concerns of providing access 
handles (for in-process as well as for inter-process transit) from access 
permissions. This allows clients to explicitly obtain in-process memory-mapped 
handles when they need it. Clients who only want to pass along the buffer or 
move it across process boundaries do not need memory-mapped handles.

In interface media::VideoCaptureBufferPool, renamed 
 GetBufferHandle() -> GetHandleForInProcessAccess()
 GetHandleForTransit() -> GetHandleForInterProcessTransit().

Removed outdated implementation in video_capture Mojo service. We leave the 
implementation empty, until refactoring the interfaces has been completed. 

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

For a peek at the follow-up CLs, please see 
https://codereview.chromium.org/2607203002/
https://codereview.chromium.org/2602983002/

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...

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

[chfremer, 2017-01-11 17:50:34]

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

[chfremer, 2017-01-11 17:50:35]

miu@: PTAL
mcasas@: PTAL

This is a reland with a small fix added on top.

[mcasas, 2017-01-12 00:25:26]

lgtm and looking forward to removing all
this duplication mojo-ipc ASAP.

https://codereview.chromium.org/2620763003/diff/20001/media/capture/video/sha...
File media/capture/video/shared_memory_buffer_tracker.cc (right):

https://codereview.chromium.org/2620763003/diff/20001/media/capture/video/sha...
media/capture/video/shared_memory_buffer_tracker.cc:46: return
shared_memory_.handle();
I was surprised to see that here we don't need
base::SharedMemory::DuplicateHandle(shared_memory_.handle()
but then I recalled that IPC does it among its
black magics, plus the win bots are happy.

[chfremer, 2017-01-12 23:49:19]

ping

miu@: Please RS

[miu, 2017-01-13 20:34:38]

lgtm. Apologies for the delays (branch point coming up and all!).

https://codereview.chromium.org/2620763003/diff/20001/media/capture/video/vid...
File media/capture/video/video_capture_buffer_tracker.h (right):

https://codereview.chromium.org/2620763003/diff/20001/media/capture/video/vid...
media/capture/video/video_capture_buffer_tracker.h:56:
GetNonOwnedSharedMemoryHandleForLegacyIPC() = 0;
If you haven't, consider running `git cl format`. It seems like this second line
of the method declaration should be indented 4 spaces. (But I could be wrong.)

https://codereview.chromium.org/2620763003/diff/20001/media/capture/video/vid...
File media/capture/video/video_capture_device.h (right):

https://codereview.chromium.org/2620763003/diff/20001/media/capture/video/vid...
media/capture/video/video_capture_device.h:107:
GetNonOwnedSharedMemoryHandleForLegacyIPC() = 0;
ditto: Indentation?

[chfremer, 2017-01-13 23:22:54]

The CQ bit was checked by chfremer@chromium.org

[commit-bot: I haz the power, 2017-01-13 23:23:32]

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-14 03:38:08]

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

[commit-bot: I haz the power, 2017-01-14 03:38:11]

Failed to apply patch for media/capture/video/video_capture_device.h:
While running git apply --index -p1;
  error: patch failed: media/capture/video/video_capture_device.h:30
  error: media/capture/video/video_capture_device.h: patch does not apply

Patch:       media/capture/video/video_capture_device.h
Index: media/capture/video/video_capture_device.h
diff --git a/media/capture/video/video_capture_device.h
b/media/capture/video/video_capture_device.h
index
0ac1c3b94b25083d33e3013f4c738d7660979192..031abdd36420f6a476cce8c23393a7fb4c22b178
100644
--- a/media/capture/video/video_capture_device.h
+++ b/media/capture/video/video_capture_device.h
@@ -30,6 +30,7 @@
 #include "media/capture/capture_export.h"
 #include "media/capture/mojo/image_capture.mojom.h"
 #include "media/capture/video/scoped_result_callback.h"
+#include "media/capture/video/video_capture_buffer_handle.h"
 #include "media/capture/video/video_capture_device_descriptor.h"
 #include "media/capture/video_capture_types.h"
 #include "mojo/public/cpp/bindings/array.h"
@@ -47,7 +48,6 @@ class CAPTURE_EXPORT FrameBufferPool {
 
   virtual void SetBufferHold(int buffer_id) = 0;
   virtual void ReleaseBufferHold(int buffer_id) = 0;
-  virtual mojo::ScopedSharedBufferHandle GetHandleForTransit(int buffer_id) =
0;
 };
 
 class CAPTURE_EXPORT VideoFrameConsumerFeedbackObserver {
@@ -87,21 +87,49 @@ class CAPTURE_EXPORT VideoCaptureDevice
   // All clients must implement OnError().
   class CAPTURE_EXPORT Client {
    public:
-    // Memory buffer returned by Client::ReserveOutputBuffer().
+    // Move-only type representing access to a buffer handle as well as
+    // read-write permission to its contents.
     class CAPTURE_EXPORT Buffer {
      public:
-      virtual ~Buffer() = 0;
-      virtual int id() const = 0;
-      virtual int frame_feedback_id() const = 0;
-      virtual gfx::Size dimensions() const = 0;
-      virtual size_t mapped_size() const = 0;
-      virtual void* data(int plane) = 0;
-      void* data() { return data(0); }
-#if defined(OS_POSIX) && !(defined(OS_MACOSX) && !defined(OS_IOS))
-      virtual base::FileDescriptor AsPlatformFile() = 0;
-#endif
-      virtual bool IsBackedByVideoFrame() const = 0;
-      virtual scoped_refptr<VideoFrame> GetVideoFrame() = 0;
+      // Destructor-only interface for encapsulating scoped access permission
to
+      // a Buffer.
+      class CAPTURE_EXPORT ScopedAccessPermission {
+       public:
+        virtual ~ScopedAccessPermission() {}
+      };
+
+      class CAPTURE_EXPORT HandleProvider {
+       public:
+        virtual ~HandleProvider() {}
+        virtual mojo::ScopedSharedBufferHandle
+        GetHandleForInterProcessTransit() = 0;
+        virtual base::SharedMemoryHandle
+        GetNonOwnedSharedMemoryHandleForLegacyIPC() = 0;
+        virtual std::unique_ptr<VideoCaptureBufferHandle>
+        GetHandleForInProcessAccess() = 0;
+      };
+
+      Buffer();
+      Buffer(int buffer_id,
+             int frame_feedback_id,
+             std::unique_ptr<HandleProvider> handle_provider,
+             std::unique_ptr<ScopedAccessPermission> access_permission);
+      ~Buffer();
+      Buffer(Buffer&& other);
+      Buffer& operator=(Buffer&& other);
+
+      bool is_valid() const { return handle_provider_ != nullptr; }
+      int id() const { return id_; }
+      int frame_feedback_id() const { return frame_feedback_id_; }
+      HandleProvider* handle_provider() const { return handle_provider_.get();
}
+
+     private:
+      std::unique_ptr<HandleProvider> handle_provider_;
+      std::unique_ptr<ScopedAccessPermission> access_permission_;
+      int id_;
+      int frame_feedback_id_;
+
+      DISALLOW_COPY_AND_ASSIGN(Buffer);
     };
 
     virtual ~Client() {}
@@ -139,20 +167,19 @@ class CAPTURE_EXPORT VideoCaptureDevice
     // backing, but functions as a reservation for external input for the
     // purposes of buffer throttling.
     //
-    // The output buffer stays reserved and mapped for use until the Buffer
-    // object is destroyed or returned.
-    virtual std::unique_ptr<Buffer> ReserveOutputBuffer(
-        const gfx::Size& dimensions,
-        VideoPixelFormat format,
-        VideoPixelStorage storage,
-        int frame_feedback_id) = 0;
+    // The buffer stays reserved for use by the caller as long as it
+    // holds on to the contained |buffer_read_write_permission|.
+    virtual Buffer ReserveOutputBuffer(const gfx::Size& dimensions,
+                                       VideoPixelFormat format,
+                                       VideoPixelStorage storage,
+                                       int frame_feedback_id) = 0;
 
     // Provides VCD::Client with a populated Buffer containing the content of
     // the next video frame. The |buffer| must originate from an earlier call
to
     // ReserveOutputBuffer().
     // See OnIncomingCapturedData for details of |reference_time| and
     // |timestamp|.
-    virtual void OnIncomingCapturedBuffer(std::unique_ptr<Buffer> buffer,
+    virtual void OnIncomingCapturedBuffer(Buffer buffer,
                                           const VideoCaptureFormat& format,
                                           base::TimeTicks reference_time,
                                           base::TimeDelta timestamp) = 0;
@@ -160,7 +187,7 @@ class CAPTURE_EXPORT VideoCaptureDevice
     // Extended version of OnIncomingCapturedBuffer() allowing clients to
     // pass a custom |visible_rect| and |additional_metadata|.
     virtual void OnIncomingCapturedBufferExt(
-        std::unique_ptr<Buffer> buffer,
+        Buffer buffer,
         const VideoCaptureFormat& format,
         base::TimeTicks reference_time,
         base::TimeDelta timestamp,
@@ -172,11 +199,10 @@ class CAPTURE_EXPORT VideoCaptureDevice
     // of the Buffer has not been preserved, or if the |dimensions|, |format|,
     // or |storage| disagree with how it was reserved via
ReserveOutputBuffer().
     // When this operation fails, nullptr will be returned.
-    virtual std::unique_ptr<Buffer> ResurrectLastOutputBuffer(
-        const gfx::Size& dimensions,
-        VideoPixelFormat format,
-        VideoPixelStorage storage,
-        int new_frame_feedback_id) = 0;
+    virtual Buffer ResurrectLastOutputBuffer(const gfx::Size& dimensions,
+                                             VideoPixelFormat format,
+                                             VideoPixelStorage storage,
+                                             int new_frame_feedback_id) = 0;
 
     // An error has occurred that cannot be handled and VideoCaptureDevice must
     // be StopAndDeAllocate()-ed. |reason| is a text description of the error.

[chfremer, 2017-01-17 21:54:07]

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

[commit-bot: I haz the power, 2017-01-17 21:54:39]

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-17 23:34:24]

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

[commit-bot: I haz the power, 2017-01-17 23:34:24]

Dry run: This issue passed the CQ dry run.

[chfremer, 2017-01-17 23:35:58]

Thanks for the review!

https://codereview.chromium.org/2620763003/diff/20001/media/capture/video/vid...
File media/capture/video/video_capture_buffer_tracker.h (right):

https://codereview.chromium.org/2620763003/diff/20001/media/capture/video/vid...
media/capture/video/video_capture_buffer_tracker.h:56:
GetNonOwnedSharedMemoryHandleForLegacyIPC() = 0;
On 2017/01/13 20:34:38, miu wrote:
> If you haven't, consider running `git cl format`. It seems like this second
line
> of the method declaration should be indented 4 spaces. (But I could be wrong.)

Tried, but seems the auto-formatting tool wants it this way.

https://codereview.chromium.org/2620763003/diff/20001/media/capture/video/vid...
File media/capture/video/video_capture_device.h (right):

https://codereview.chromium.org/2620763003/diff/20001/media/capture/video/vid...
media/capture/video/video_capture_device.h:107:
GetNonOwnedSharedMemoryHandleForLegacyIPC() = 0;
On 2017/01/13 20:34:38, miu wrote:
> ditto: Indentation?

Same. Formatting tool already applied.

[chfremer, 2017-01-17 23:36:05]

The CQ bit was checked by chfremer@chromium.org

[chfremer, 2017-01-17 23:36:05]

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

[commit-bot: I haz the power, 2017-01-17 23:36:43]

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-17 23:46:24]

CQ is committing da patch.

Bot data: {"patchset_id": 40001, "attempt_start_ts": 1484696165066520,
"parent_rev": "0221e755063d12ff67e52e5e5adce946ce06d3c0", "commit_rev":
"03c86be79f1ccae3c1923d1cff9106d15abdbf21"}

[commit-bot: I haz the power, 2017-01-17 23:46:56]

Description was changed from

==========
Reland [Mojo Video Capture] Simplify media::VideoCaptureDevice::Client:Buffer to
a struct

PatchSet#1 is the state as previously reviewed, landed, reverted, and merged 
with the fix from https://codereview.chromium.org/2621743002/.

PatchSet#2: Because the original CL introduced another new 
SharedMemoryHandle-not-getting-closed issue, this PatchSet has the fix for this.
Instead of fixing this by attaching ownership of the handle to a VideoFrame, I 
decided to instead add a method 
GetNonOwnedSharedMemoryHandleForLegacyIPC() to interface 
VideoCaptureDevice::Client::Buffer::HandleProvider. This allows us to avoid the 
otherwise introduced extra step of wrapping/unwrapping a new file handle copy.


Description of original CL:

In interface media::VideoCaptureDevice::Client, change interface Buffer to a 
move-only struct. The new struct separates the concerns of providing access 
handles (for in-process as well as for inter-process transit) from access 
permissions. This allows clients to explicitly obtain in-process memory-mapped 
handles when they need it. Clients who only want to pass along the buffer or 
move it across process boundaries do not need memory-mapped handles.

In interface media::VideoCaptureBufferPool, renamed 
 GetBufferHandle() -> GetHandleForInProcessAccess()
 GetHandleForTransit() -> GetHandleForInterProcessTransit().

Removed outdated implementation in video_capture Mojo service. We leave the 
implementation empty, until refactoring the interfaces has been completed. 

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

For a peek at the follow-up CLs, please see 
https://codereview.chromium.org/2607203002/
https://codereview.chromium.org/2602983002/

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...

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

to

==========
Reland [Mojo Video Capture] Simplify media::VideoCaptureDevice::Client:Buffer to
a struct

PatchSet#1 is the state as previously reviewed, landed, reverted, and merged 
with the fix from https://codereview.chromium.org/2621743002/.

PatchSet#2: Because the original CL introduced another new 
SharedMemoryHandle-not-getting-closed issue, this PatchSet has the fix for this.
Instead of fixing this by attaching ownership of the handle to a VideoFrame, I 
decided to instead add a method 
GetNonOwnedSharedMemoryHandleForLegacyIPC() to interface 
VideoCaptureDevice::Client::Buffer::HandleProvider. This allows us to avoid the 
otherwise introduced extra step of wrapping/unwrapping a new file handle copy.


Description of original CL:

In interface media::VideoCaptureDevice::Client, change interface Buffer to a 
move-only struct. The new struct separates the concerns of providing access 
handles (for in-process as well as for inter-process transit) from access 
permissions. This allows clients to explicitly obtain in-process memory-mapped 
handles when they need it. Clients who only want to pass along the buffer or 
move it across process boundaries do not need memory-mapped handles.

In interface media::VideoCaptureBufferPool, renamed 
 GetBufferHandle() -> GetHandleForInProcessAccess()
 GetHandleForTransit() -> GetHandleForInterProcessTransit().

Removed outdated implementation in video_capture Mojo service. We leave the 
implementation empty, until refactoring the interfaces has been completed. 

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

For a peek at the follow-up CLs, please see 
https://codereview.chromium.org/2607203002/
https://codereview.chromium.org/2602983002/

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...

Review-Url: https://codereview.chromium.org/2573223002
Cr-Original-Commit-Position: refs/heads/master@{#442066}
Committed:
https://chromium.googlesource.com/chromium/src/+/e1aac992b0399db7776661f4ac2c...
Review-Url: https://codereview.chromium.org/2620763003
Cr-Commit-Position: refs/heads/master@{#444191}
Committed:
https://chromium.googlesource.com/chromium/src/+/03c86be79f1ccae3c1923d1cff91...
==========

[commit-bot: I haz the power, 2017-01-17 23:46:57]

Committed patchset #3 (id:40001) as
https://chromium.googlesource.com/chromium/src/+/03c86be79f1ccae3c1923d1cff91...