"Buttery Smooth" Tab Capture.

content/browser/renderer_host/media/video_capture_controller.cc

Index: content/browser/renderer_host/media/video_capture_controller.cc
diff --git a/content/browser/renderer_host/media/video_capture_controller.cc b/content/browser/renderer_host/media/video_capture_controller.cc
index 617b556f32119d3f9a025bb6df62dc94d73ef5b6..d09aff14452773d5609e39cccd03e5ffcc372bbf 100644
--- a/content/browser/renderer_host/media/video_capture_controller.cc
+++ b/content/browser/renderer_host/media/video_capture_controller.cc
@@ -42,7 +42,7 @@ static const int kInfiniteRatio = 99999;
         (height) ? ((width) * 100) / (height) : kInfiniteRatio);
 
 // The number of buffers that VideoCaptureBufferPool should allocate.
-const int kNoOfBuffers = 3;
+const int kNoOfBuffers = 5;

[ncarter (slow), 2014/07/26 00:57:58]

This carries some risk, as it seems like there's some danger of this increasing
the latency for non-tabcapture uses of the pipeline. You should probably give a
heads up to the potentially affected parties. If the encoders are set up to drop
(and not queue up) frames, then it might not be as big a deal.

If the other teams do have worries about this, it would not be hard to vary the
kNoOfBuffers depending on the MediaStreamType.

[miu, 2014/07/31 01:25:32]

Done.  I've eliminated the risk by implementing the
buffer-pool-size-per-MediaStreamType solution you mentioned.

 
 class PoolBuffer : public media::VideoCaptureDevice::Client::Buffer {
  public: