zqz/platform-external-webrtc
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Significantly increased max_num_buffers_ of Vp9FrameBufferPool.

Browse Source 
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}
This commit is contained in:
hbos
2016-09-06 01:38:28 -07:00
committed by Commit bot
parent d4ec970a79
commit c928453fd0
1 changed files with 10 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
webrtc/modules/video_coding/codecs/vp9/vp9_frame_buffer_pool.h
View File

@ -107,9 +107,16 @@ class Vp9FrameBufferPool {
// 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