getUserMeida: report device starting states

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 a716db8665967b41a6af20cf42600324457ff978..c6599e63b57588618ea56f911d9b5122ec6f3ddc 100644
--- a/media/capture/video/video_capture_device.h
+++ b/media/capture/video/video_capture_device.h
@@ -83,7 +83,11 @@ class CAPTURE_EXPORT VideoCaptureDevice
   // Interface defining the methods that clients of VideoCapture must have. It
   // is actually two-in-one: clients may implement OnIncomingCapturedData() or
   // ReserveOutputBuffer() + OnIncomingCapturedVideoFrame(), or all of them.
-  // All clients must implement OnError().
+  // All methods may be called as soon as AllocateAndStart() of the
+  // corresponding VideoCaptureDevice is invoked. The methods for buffer
+  // reservation and frame delivery may be called from arbitrary threads but
+  // are guaranteed to be called non-concurrently. The status reporting methods
+  // (OnStarted, OnLog, OnError) may be called concurrently.

[miu, 2017/02/24 22:16:45]

FWICT, this is incorrect: The current implementation,
media::VideoCaptureDeviceClient blindly calls into its
media::VideoFrameReceiver. However, content::VideoCaptureController (the main
impl of VideoFrameReceiver) assumes the status-reporting methods are *only*
called on the IO thread.

Also, we then have examples where the VCD's do not call these methods on the IO
thread, such as DesktopCaptureDevice: It calls OnError() from its own task
runner:
https://cs.chromium.org/chromium/src/content/browser/media/capture/desktop_ca...

So, we need to fix this. As it is right now, DCHECKs() will trigger under normal
conditions. Please make sure, when you are testing this change on your desktop,
that you are using "dcheck_always_on = true" in your GN args.

[chfremer, 2017/02/24 22:25:35]

Thanks for raising this concern. I think we may actually be fine, because the
VideoFrameReceiver implementation that the VideoCaptureDeviceClient talks to is
not VideoCaptureController but VideoFrameReceiverOnIOThread, which is a
decorator that posts all incoming calls to the IO thread.

[braveyao, 2017/02/24 22:53:36]

Thanks chfremer@ for replying.
Yes, they are all posted to IO thread here,
https://cs.chromium.org/chromium/src/content/browser/renderer_host/media/vide...,
before going into VideoCaptureController.

[miu, 2017/02/24 23:02:21]

Ah, yes, I forgot about that.

   class CAPTURE_EXPORT Client {
    public:
     // Move-only type representing access to a buffer handle as well as
@@ -214,6 +218,9 @@ class CAPTURE_EXPORT VideoCaptureDevice
     // Returns the current buffer pool utilization, in the range 0.0 (no buffers
     // are in use by producers or consumers) to 1.0 (all buffers are in use).
     virtual double GetBufferPoolUtilization() const = 0;
+
+    // VideoCaptureDevice reports it's successfully started.
+    virtual void OnStarted() = 0;
   };
 
   ~VideoCaptureDevice() override;