Significantly increased max_num_buffers_ of Vp9FrameBufferPool.
Changed from 10 to 68.
This is to avoid a flake where the limit is exceeded, see
crbug.com/638554. Our performance tests should flag performance
regressions, we shouldn't rely on crashing because the number of
referenced buffers is not tiny to detect this. However, if a really big
number of buffers (>68) are referenced without being dereferenced it is
likely that we have a bug and frames are leaking in which case we can
DCHECK-crash.
BUG=chromium:638554
Review-Url: https://codereview.webrtc.org/2280593002
Cr-Commit-Position: refs/heads/master@{#14084}
diff --git a/webrtc/modules/video_coding/codecs/vp9/vp9_frame_buffer_pool.h b/webrtc/modules/video_coding/codecs/vp9/vp9_frame_buffer_pool.h
index 8551689..af91c8c 100644
--- a/webrtc/modules/video_coding/codecs/vp9/vp9_frame_buffer_pool.h
+++ b/webrtc/modules/video_coding/codecs/vp9/vp9_frame_buffer_pool.h
@@ -107,9 +107,16 @@
// All buffers, in use or ready to be recycled.
std::vector<rtc::scoped_refptr<Vp9FrameBuffer>> allocated_buffers_
GUARDED_BY(buffers_lock_);
- // If more buffers than this are allocated we print warnings, and crash if
- // in debug mode.
- static const size_t max_num_buffers_ = 10;
+ // If more buffers than this are allocated we print warnings and crash if in
+ // debug mode. VP9 is defined to have 8 reference buffers, of which 3 can be
+ // referenced by any frame, see
+ // https://tools.ietf.org/html/draft-grange-vp9-bitstream-00#section-2.2.2.
+ // Assuming VP9 holds on to at most 8 buffers, any more buffers than that
+ // would have to be by application code. Decoded frames should not be
+ // referenced for longer than necessary. If we allow ~60 additional buffers
+ // then the application has ~1 second to e.g. render each frame of a 60 fps
+ // video.
+ static const size_t max_num_buffers_ = 68;
};
} // namespace webrtc