Add limitations of number of frames that can be created in I420BufferPool::CreateBuffer.

webrtc/common_video/include/i420_buffer_pool.h

Index: webrtc/common_video/include/i420_buffer_pool.h
diff --git a/webrtc/common_video/include/i420_buffer_pool.h b/webrtc/common_video/include/i420_buffer_pool.h
index 5aabd756b7f83ac62fb5ab1c26d52b43d68db011..e67d82d0c4a1092d66645ad004932b753ca67a31 100644
--- a/webrtc/common_video/include/i420_buffer_pool.h
+++ b/webrtc/common_video/include/i420_buffer_pool.h
@@ -23,6 +23,8 @@ namespace webrtc {
 // When the I420Buffer is destructed, the memory is returned to the pool for use
 // by subsequent calls to CreateBuffer. If the resolution passed to CreateBuffer
 // changes, old buffers will be purged from the pool.
+// Note that CreateBuffer will crash if more than kMaxNumberOfFramesBeforeCrash
+// are created. This is to prevent memory leaks where frames are not returned.
 class I420BufferPool {
  public:
   I420BufferPool() : I420BufferPool(false) {}
@@ -36,6 +38,7 @@ class I420BufferPool {
   void Release();
 
  private:
+  static const int kMaxNumberOfFramesBeforeCrash = 60;

[mflodman, 2016/09/26 14:36:47]

I'd like to raise this limit a bit higher. Normally it shouldn't be this high,
but in the case of intentionally increasing the receive side delay this (= 2
second @ 30fps and 1s @ 60 fps) might be on the lower end.

WDYT of setting this to 300 (=10s @ 30fps, and 330MB mem usage in HD)?

[perkj_webrtc, 2016/09/27 07:41:41]

ok- set to 300.

   // Explicitly use a RefCountedObject to get access to HasOneRef,
   // needed by the pool to check exclusive access.
   using PooledI420Buffer = rtc::RefCountedObject<I420Buffer>;