Video Capture: Allow suspension of individual devices.

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 cbdc8adde4c6e44dd2d764957a6873c267d02109..18cbc3be448e6699478894f3fc8fff0cb3022ac8 100644
--- a/media/capture/video/video_capture_device.h
+++ b/media/capture/video/video_capture_device.h
@@ -167,6 +167,14 @@ class CAPTURE_EXPORT VideoCaptureDevice {
   // reasonable attempts to honor these requests.
   virtual void RequestRefreshFrame() {}
 
+  // Optionally suspends frame delivery. The video capturer may or may not honor

[chfremer, 2016/09/27 00:54:59]

nit: "video capturer" -> "VideoCaptureDevice" or "implementation".

[miu, 2016/09/27 23:42:23]

Done.

+  // this request. The purpose of this is to allow minimizing resource usage
+  // while there are no frame consumers present.

[chfremer, 2016/09/27 00:54:59]

nit: The names "Suspend" and "Resume" already somewhat imply this, but we could
state more explicitly that suspending and resuming is supposed to be
significantly faster than stopping and starting. Or is it legal for
implementations to internally use stop and start as long as that is "fast
enough"?

[miu, 2016/09/27 23:42:23]

Done.
Generally, no, we always assume Start() and Stop() are not fast (i.e., could
take on the order of seconds to execute!).

+  virtual void MaybeSuspend() {}
+
+  // Resumes frame delivery, if it was suspended.
+  virtual void Resume() {}
+
   // Deallocates the video capturer, possibly asynchronously.
   //
   // This call requires the device to do the following things, eventually: put