VideoCapture: more migration IPC-->mojo, part 5

content/common/video_capture.mojom

Index: content/common/video_capture.mojom
diff --git a/content/common/video_capture.mojom b/content/common/video_capture.mojom
index 7179248dacf494420bf73d79a3757f0a555946d5..6848ff6f25b044b7ccfc9dfd4bdbeec3a03869b7 100644
--- a/content/common/video_capture.mojom
+++ b/content/common/video_capture.mojom
@@ -5,8 +5,11 @@
 module content.mojom;
 
 import "gpu/ipc/common/sync_token.mojom";
+import "media/mojo/interfaces/media_types.mojom";
+import "mojo/common/common_custom_types.mojom";
 import "services/video_capture/public/interfaces/video_capture_device_proxy.mojom";
 import "services/video_capture/public/interfaces/video_capture_format.mojom";
+import "ui/gfx/geometry/mojo/geometry.mojom";
 
 struct VideoCaptureParams {
   video_capture.mojom.VideoCaptureFormat requested_format;
@@ -14,6 +17,15 @@ struct VideoCaptureParams {
   video_capture.mojom.PowerLineFrequency power_line_frequency;
 };
 
+struct VideoFrameInfo{
+  mojo.common.mojom.TimeDelta timestamp;
+  mojo.common.mojom.DictionaryValue metadata;
+  media.mojom.VideoFormat pixel_format;
+  video_capture.mojom.VideoPixelStorage storage_type;
+  gfx.mojom.Size coded_size;
+  gfx.mojom.Rect visible_rect;
+};

[chfremer, 2016/10/11 16:59:38]

For some of our Mojo struct, we now already have type mapping to equivalent C++
structs in place. I am wondering if we should try to consistently always provide
equivalent C++ structs and type mapping, or if it is okay to sometimes do it and
sometimes use the Mojo types directly. If we want to go for consistency, we
should add the type mapping immediately when we introduce a new Mojo struct. 

[mcasas, 2016/10/11 17:39:37]

I was discussing something similar yesterday, and
my understanding is that:
- if there is a C++ struct:
-- it's OK to use [Native] and use C++-in-mojo
-- it's even better to have a mojo type + typemappings
- but if there isn't a C++ equivalent, I would go
ahead and use mojom everywhere, which is what
I'm kind of doing here.
In this particular case, VideoFrameInfo is only
used in this particular interface, so it doesn't
matter much.

+
 enum VideoCaptureState {
   STARTED,
   PAUSED,
@@ -26,10 +38,17 @@ enum VideoCaptureState {
 // Interface for notifications from Browser/Host back to Renderer/Client. This
 // interface is used between VideoCaptureHost.Start() and Stop().
 interface VideoCaptureObserver {
-  // Gets notigied about a VideoCaptureState update.
+  // Gets notified about a VideoCaptureState update.
   OnStateChanged(VideoCaptureState state);
 
-// TODO(mcasas): Migrate the rest of the messages, https://crbug.com/651897.
+  // |buffer_id| has video capture data with |info| containing the associated
+  // VideoFrame constituent parts.
+  OnBufferReady(int32 buffer_id, VideoFrameInfo info);
+
+  // |buffer_id| has been released by VideoCaptureHost and must not be used.
+  OnBufferDestroyed(int32 buffer_id);
+
+  // TODO(mcasas): Migrate the rest of the messages, https://crbug.com/651897.
 };
 
 interface VideoCaptureHost {