NetEq: Fix a bug in expand_rate and speech_expand_rate calculation
After a Merge operation, the statistics for number of samples
generated using Expand must be corrected, and the correction can in
fact be negative. However, a bug was introduced in
https://codereview.webrtc.org/1230503003 which uses a size_t to
represent the correction, which leads to wrap-around of the negative
value. This is not a problem in itself, since this value is added to
another size_t, with the effect that the desired subtraction happens
anyway.
The actual problem arises if the statistics are polled/reset before a
subtraction happens -- that is, between an Expand and a Merge
operation. This will lead to an actual wrap-around of the stats value,
and large expand_rate (16384) is reported.
BUG=webrtc:7554
Review-Url: https://codereview.webrtc.org/2859483005
Cr-Commit-Position: refs/heads/master@{#18029}
diff --git a/webrtc/modules/audio_coding/neteq/neteq_impl.cc b/webrtc/modules/audio_coding/neteq/neteq_impl.cc
index e119d94..2d91b8c 100644
--- a/webrtc/modules/audio_coding/neteq/neteq_impl.cc
+++ b/webrtc/modules/audio_coding/neteq/neteq_impl.cc
@@ -1600,16 +1600,18 @@
size_t new_length = merge_->Process(decoded_buffer, decoded_length,
mute_factor_array_.get(),
algorithm_buffer_.get());
- size_t expand_length_correction = new_length -
- decoded_length / algorithm_buffer_->Channels();
+ // Correction can be negative.
+ int expand_length_correction =
+ rtc::dchecked_cast<int>(new_length) -
+ rtc::dchecked_cast<int>(decoded_length / algorithm_buffer_->Channels());
// Update in-call and post-call statistics.
if (expand_->MuteFactor(0) == 0) {
// Expand generates only noise.
- stats_.ExpandedNoiseSamples(expand_length_correction);
+ stats_.ExpandedNoiseSamplesCorrection(expand_length_correction);
} else {
// Expansion generates more than only noise.
- stats_.ExpandedVoiceSamples(expand_length_correction);
+ stats_.ExpandedVoiceSamplesCorrection(expand_length_correction);
}
last_mode_ = kModeMerge;