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}
This commit is contained in:
@ -107,9 +107,16 @@ class Vp9FrameBufferPool {
|
|||||||
// All buffers, in use or ready to be recycled.
|
// All buffers, in use or ready to be recycled.
|
||||||
std::vector<rtc::scoped_refptr<Vp9FrameBuffer>> allocated_buffers_
|
std::vector<rtc::scoped_refptr<Vp9FrameBuffer>> allocated_buffers_
|
||||||
GUARDED_BY(buffers_lock_);
|
GUARDED_BY(buffers_lock_);
|
||||||
// If more buffers than this are allocated we print warnings, and crash if
|
// If more buffers than this are allocated we print warnings and crash if in
|
||||||
// in debug mode.
|
// debug mode. VP9 is defined to have 8 reference buffers, of which 3 can be
|
||||||
static const size_t max_num_buffers_ = 10;
|
// 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
|
} // namespace webrtc
|
||||||
|
|||||||
Reference in New Issue
Block a user