Reland: VideoCapture: migrate VideoCapture renderer-->host messages to mojo, part 1

content/common/video_capture.mojom

+// Copyright 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+module content.mojom;
+
+interface VideoCaptureRendererToBrowser

[Ken Rockot(use gerrit already), 2016/10/04 23:35:36]

So actually, conventionally we've been using the message filter name for the
mojom interface when using BrowserAssociatedInterface. It signifies that the
interface still needs to be refactored and was just a rote conversion of legacy
IPC. So, maybe VideoCaptureHost would be a good name for this? (i.e.
content::mojom::VideoCaptureHost).

[mcasas, 2016/10/05 18:32:59]

Yeah, totally my bad. I misunderstood the
migration I thought I could do "one side" (the
service implementation) at once. After offline
discussion, things are much clearer, and I did
the client side as well.

+{
+  // TODO(mcasas): Migrate the rest of the messages, https://crbug.com/651897.
+
+  // Closes the video capture specified by |device_id|.
+  Stop(int32 device_id);

[miu, 2016/10/05 07:49:29]

In the Mojo world, we're supposed to stop using IDs like this. Instead, passing
handles to objects is preferred. Also, this is a great opportunity to eliminate
the old crufty IPC messaging, and replace it with a cleaner structure. (So,
let's not just 1:1 map IPC messages into Mojo interfaces.)

For example, how about something like:

interface VideoCaptureHost {
  // Starts a VCD. If fails, it does not bind |device| but does call
|client->StateChanged(<some error>)|.
  Start(...params..., VideoCaptureDevice& device, VideoCaptureDeviceClient
client);
};

// Control interface for a started VCD.
interface VideoCaptureDevice {
  Stop();
  Pause();
  Resume();
  RequestRefreshFrame();
};

// Delivery destination for frames and state changes.
interface VideoCaptureDeviceClient {
  StateChanged(...enum value...);

  // Called to deliver next video frame. VCDClient replies once it has finished
with the frame.
  FrameReady(params, shmem handle) => (sync_token,
consumer_resource_utilization);
};

[mcasas, 2016/10/05 18:33:00]

I do agree, and in fact starting migrating the whole
shebang, but... it turned out to be too much, since
it depended in typemaps (e.g. VideoCaptureParams)
and other stuff (e.g. in //services/).  So I decided to
a) migrate all these messages as they are:  in my 
 experience all this legacy is full of hidden
 contracts and expectations, which makes migration
 look approachable only to mire the developer.
b) work in // with chfremer@ on the video capture
 service API, which will eventually replace this code:
 if you take a look at his CLs, you'll see that his API
 looks more mojo, just like yours.

So the plan is : migrate this IPC to mojo, see that
things don't break, prepare the new API, launch a 
Finch experiment with the new one. Makes sense?

+
+  // Pauses the video capture specified by |device_id|.
+  Pause(int32 device_id);
+
+  // Requests that the video capturer send a frame "soon" (e.g., to resolve
+  // picture loss or quality issues).
+  RequestRefreshFrame(int32 device_id);
+};