Request frame for new sinks from MediaStreamVideoTrack

media/base/video_capturer_source.h

Index: media/base/video_capturer_source.h
diff --git a/media/base/video_capturer_source.h b/media/base/video_capturer_source.h
index a99faf8e394d00ef7612365be89d27207e14e960..8873de871d663ce59dab8b0ab2bb07f7213041d2 100644
--- a/media/base/video_capturer_source.h
+++ b/media/base/video_capturer_source.h
@@ -76,6 +76,11 @@ class MEDIA_EXPORT VideoCapturerSource {
       const VideoCaptureDeliverFrameCB& new_frame_callback,
       const RunningCallback& running_callback) = 0;
 
+  // If capturing is started successfully, then |new_frame_callback| should be
+  // called with a frame. Some implementations may hold onto the last frame and
+  // send it.
+  virtual void RequestFrame() {}

[miu, 2016/03/25 22:05:06]

1. Can we name this RequestRefreshFrame() here and in
MediaStreamVideoCapturerSource and MediaStreamVideoSource?  This would make it
consistent with the naming in the browser-side changes:
https://code.google.com/p/chromium/codesearch#chromium/src/media/capture/vide...

2. Also, this comment should probably describe the same semantics and usage
patterns as in the VideoCaptureDevice change (link above).  Meaning, the source
can decide whether to honor the request, depending on whether it will be sending
more frames soon or capture is halted due to unchanging content.

[emircan, 2016/03/25 23:18:41]

1) Done. I was trying to be consistent with RequestFrame() from the W3C spec[0],
but there are multiple users now :)

[0] http://w3c.github.io/mediacapture-fromelement/#dfn-requestframe

2) Done.

+
   // Stops capturing frames and clears all callbacks including the
   // SupportedFormatsCallback callback. Note that queued frame callbacks
   // may still occur after this call, so the caller must take care to