getUserMeida: report device starting states

media/capture/content/thread_safe_capture_oracle.cc

Index: media/capture/content/thread_safe_capture_oracle.cc
diff --git a/media/capture/content/thread_safe_capture_oracle.cc b/media/capture/content/thread_safe_capture_oracle.cc
index 7e368f597451e0e190f53ec139a79d4a41ba58f7..909b5b11bd4365a5e277f423a04b67ac6a9d8130 100644
--- a/media/capture/content/thread_safe_capture_oracle.cc
+++ b/media/capture/content/thread_safe_capture_oracle.cc
@@ -45,7 +45,8 @@ ThreadSafeCaptureOracle::ThreadSafeCaptureOracle(
               params.requested_format.frame_size,
               params.resolution_change_policy,
               enable_auto_throttling),
-      params_(params) {}
+      params_(params),
+      capture_(false) {}
 
 ThreadSafeCaptureOracle::~ThreadSafeCaptureOracle() {
 }
@@ -187,6 +188,7 @@ void ThreadSafeCaptureOracle::UpdateCaptureSize(const gfx::Size& source_size) {
 
 void ThreadSafeCaptureOracle::Stop() {
   base::AutoLock guard(lock_);
+  capture_ = false;
   client_.reset();
 }
 
@@ -198,6 +200,13 @@ void ThreadSafeCaptureOracle::ReportError(
     client_->OnError(from_here, reason);
 }
 
+void ThreadSafeCaptureOracle::ReportStarted() {
+  base::AutoLock guard(lock_);
+  if (client_)
+    client_->OnStarted();
+  capture_ = true;
+}
+
 void ThreadSafeCaptureOracle::DidCaptureFrame(
     int frame_number,
     VideoCaptureDevice::Client::Buffer buffer,
@@ -218,7 +227,7 @@ void ThreadSafeCaptureOracle::DidCaptureFrame(
   TRACE_EVENT_INSTANT0("gpu.capture", "CaptureSucceeded",
                        TRACE_EVENT_SCOPE_THREAD);
 
-  if (!client_)
+  if (!client_ || !capture_)

[miu, 2017/02/18 01:18:45]

Dropping frames at this stage could break things (there were several similar
bugs in the past related to dropping frames).

I thought about this whole change a bit more, and I'm not convinced this is the
right overall approach to solving the problem (as I understand it).

I think you should remove this logic (and in all the other VCD impls). We
shouldn't require that OnStarted() be called before any frames can be delivered.
This requirement was never necessary before. Instead, the API contract was that
frames could be delivered at any point once AllocateAndStart() is called.

If it is a requirement for gUM, then gUM should drop frames at the consumer end.
But, that might be a very bad idea: dropping *any* frames can break things
because not all VCD's continuously produce frames. In other words, there are
start-up scenarios where a producer will send only one frame and then no others
for a long period of time, and if that first frame is dropped, consumers will
never see a first frame. (again, there were bugs relating to this)

Stepping back, I wonder if it'd be simpler to just scrap all the browser-side
changes. Remove OnStarted() altogether. Instead, in the render process, could
gUM simply infer that receiving a first frame means the capture device
successfully started? The web platform event for "started capture" could be
dispatched at the time the first frame arrives at the consumer.

[braveyao, 2017/02/22 18:06:44]

Acknowledged.

     return;  // Capture is stopped.
 
   frame->metadata()->SetDouble(VideoFrameMetadata::FRAME_RATE,