Simplify ScreenCapturer interface.

remoting/host/video_scheduler.cc

Index: remoting/host/video_scheduler.cc
diff --git a/remoting/host/video_scheduler.cc b/remoting/host/video_scheduler.cc
index c927b3cbe2b5892b5db0fef4e754f4c3f007228c..42c85c676f527c539e9557c0459bdb4f431a31ef 100644
--- a/remoting/host/video_scheduler.cc
+++ b/remoting/host/video_scheduler.cc
@@ -178,7 +178,7 @@ void VideoScheduler::StopOnCaptureThread() {
   DCHECK(capture_task_runner_->BelongsToCurrentThread());
 
   // Stop |capturer_| and clear it to prevent pending tasks from using it.
-  capturer_->Stop();
+  capturer_.reset();

[alexeypa (please no reviews), 2013/04/22 16:23:19]

|capturer_| can only be deleted only after the encoding thread stopped reading
the frames. Note that |capturer_| is passed to StopOnEncodeThread() and then to
StopOnNetworkThread().


This could be avoided if we move frames allocation (and frame queue management)
out of the capturer to the caller. The capturer can still provide code for
allocating frames (as a separate class most likely) but the caller would decide
when to allocate them. CaptureFrame() would check if the frame is compatible
with the current resolution and return an error if it is not.

This is out of scope for this CL I guess but it is something to consider.

[Sergey Ulanov, 2013/04/22 18:18:56]

Oh, right. Do we need to call Stop() here at all?

With the refactoring I'm working on I'm going to fix this problem: it will be
safe to delete capturer while the frames still being processed (will upload it
for review today).
As I mentioned in previous response I think it's the captured who should be
allocating frames - only it has all details needed to allocated it properly.

[alexeypa (please no reviews), 2013/04/22 18:36:37]

Yes. It clears |delegate_| preventing the capturer from using 
It is true that frame allocation is capturer specific. What I don't like about
it is that the capturer has to manage the queue of frames. One issue that you
mentioned elsewhere - "what if InvalidateRegion() is called in between
CaptureFrame() and OnCaptureCompleted()?" is directly related to the frame queue
management. We "solve" it by making the capturer single-threaded. We, probably,
should express this arrangement in the capturer interface. 

 
   // |capture_timer_| must be destroyed on the thread on which it is used.
   capture_timer_.reset();