Package video capture skeleton as Mojo Shell Service

services/video_capture/public/interfaces/video_capture_device_factory.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 video_capture.mojom;
 
 import "services/video_capture/public/interfaces/video_capture_device.mojom";
 import "services/video_capture/public/interfaces/video_capture_format.mojom";
 
 enum VideoCaptureApi {
   LINUX_V4L2_SINGLE_PLANE,
   WIN_MEDIA_FOUNDATION,
   WIN_DIRECT_SHOW,
   MACOSX_AVFOUNDATION,
   MACOSX_DECKLINK,
   ANDROID_API1,
   ANDROID_API2_LEGACY,
   ANDROID_API2_FULL,
   ANDROID_API2_LIMITED,
   ANDROID_TANGO,
   UNKNOWN
 };
 
 enum VideoCaptureTransportType {
-  // For AVFoundation Api, identify devices that are built-in or USB.
+  // For MACOSX_AVFOUNDATION Api, identifies devices that are built-in or USB.
   MACOSX_USB_OR_BUILT_IN,
   OTHER_TRANSPORT
 };
 
 struct VideoCaptureDeviceDescriptor {
   string display_name;
   string device_id;
   string model_id;
   VideoCaptureApi capture_api;
   VideoCaptureTransportType transport_type;
 };
 
+// Entry point for accessing video capture devices available on the machine.
+// Typical operation is to first call EnumerateDeviceDescriptors() to obtain
+// information about available devices. The obtained descriptors can then be
+// used to either obtain the supported formats of a device using
+// GetSupportedFormats(), or to create an instance of VideoCaptureDevice for
+// the device using CreateDevice().
 interface VideoCaptureDeviceFactory {
   EnumerateDeviceDescriptors()
       => (array<VideoCaptureDeviceDescriptor> descriptors);
 
   GetSupportedFormats(VideoCaptureDeviceDescriptor device_descriptor)

[yzshen1, 2016/08/12 17:46:50]

I wonder why we need to send a VideoCaptureDeviceDescriptor structure. To me
some fields in that structure are not necessary to identify the device. WDYT?

[chfremer, 2016/08/12 18:32:27]

Good observation. This is a weakness in the design. In the refactoring before
this Mojofication, I was about to change the interface such that it would use
unique string identifiers instead of the device descriptor structs, but then I
ended up not doing it. I think it was because of the extra complexity involved
in having to generate ids and build and manage a map from ids to descriptors.

How strongly do you feel about this? Would you be okay with leaving it as is or
do you prefer a design with unique ids?

[yzshen1, 2016/08/12 20:05:53]

It seems nice to do that. But you or other experts of this code may know better
whether it is a must or it could be done later.

[mcasas, 2016/08/12 21:49:41]

On ToT, VideoCaptureManager has to keep all this information
between the enumeration and individual VideoCaptureDevices,
so it's needed in a first step, to keep the VCDFactory separated
from the VCDevice, and to avoid having to reenumerate to 
pull up those details again, but we can contemplate 
simplification-refactorings down the line. TODO+bug, I'd say.

       => (array<VideoCaptureFormat> supported_formats);
 
   CreateDevice(VideoCaptureDeviceDescriptor device_descriptor,
                VideoCaptureDevice& device_request);
 };