webrtc_m130/modules/audio_coding/neteq/delay_manager_unittest.cc

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

250 lines
8.4 KiB
C++
Raw Normal View History

/*
* Copyright (c) 2012 The WebRTC project authors. All Rights Reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
* tree. An additional intellectual property rights grant can be found
* in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
// Unit tests for DelayManager class.
#include "modules/audio_coding/neteq/delay_manager.h"
#include <math.h>
Use std::make_unique instead of absl::make_unique. WebRTC is now using C++14 so there is no need to use the Abseil version of std::make_unique. This CL has been created with the following steps: git grep -l absl::make_unique | sort | uniq > /tmp/make_unique.txt git grep -l absl::WrapUnique | sort | uniq > /tmp/wrap_unique.txt git grep -l "#include <memory>" | sort | uniq > /tmp/memory.txt diff --new-line-format="" --unchanged-line-format="" \ /tmp/make_unique.txt /tmp/wrap_unique.txt | sort | \ uniq > /tmp/only_make_unique.txt diff --new-line-format="" --unchanged-line-format="" \ /tmp/only_make_unique.txt /tmp/memory.txt | \ xargs grep -l "absl/memory" > /tmp/add-memory.txt git grep -l "\babsl::make_unique\b" | \ xargs sed -i "s/\babsl::make_unique\b/std::make_unique/g" git checkout PRESUBMIT.py abseil-in-webrtc.md cat /tmp/add-memory.txt | \ xargs sed -i \ 's/#include "absl\/memory\/memory.h"/#include <memory>/g' git cl format # Manual fix order of the new inserted #include <memory> cat /tmp/only_make_unique | xargs grep -l "#include <memory>" | \ xargs sed -i '/#include "absl\/memory\/memory.h"/d' git ls-files | grep BUILD.gn | \ xargs sed -i '/\/\/third_party\/abseil-cpp\/absl\/memory/d' python tools_webrtc/gn_check_autofix.py \ -m tryserver.webrtc -b linux_rel # Repead the gn_check_autofix step for other platforms git ls-files | grep BUILD.gn | \ xargs sed -i 's/absl\/memory:memory/absl\/memory/g' git cl format Bug: webrtc:10945 Change-Id: I3fe28ea80f4dd3ba3cf28effd151d5e1f19aff89 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/153221 Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org> Reviewed-by: Alessio Bazzica <alessiob@webrtc.org> Reviewed-by: Karl Wiberg <kwiberg@webrtc.org> Cr-Commit-Position: refs/heads/master@{#29209}
2019-09-17 17:06:18 +02:00
#include <memory>
#include <optional>
Use std::make_unique instead of absl::make_unique. WebRTC is now using C++14 so there is no need to use the Abseil version of std::make_unique. This CL has been created with the following steps: git grep -l absl::make_unique | sort | uniq > /tmp/make_unique.txt git grep -l absl::WrapUnique | sort | uniq > /tmp/wrap_unique.txt git grep -l "#include <memory>" | sort | uniq > /tmp/memory.txt diff --new-line-format="" --unchanged-line-format="" \ /tmp/make_unique.txt /tmp/wrap_unique.txt | sort | \ uniq > /tmp/only_make_unique.txt diff --new-line-format="" --unchanged-line-format="" \ /tmp/only_make_unique.txt /tmp/memory.txt | \ xargs grep -l "absl/memory" > /tmp/add-memory.txt git grep -l "\babsl::make_unique\b" | \ xargs sed -i "s/\babsl::make_unique\b/std::make_unique/g" git checkout PRESUBMIT.py abseil-in-webrtc.md cat /tmp/add-memory.txt | \ xargs sed -i \ 's/#include "absl\/memory\/memory.h"/#include <memory>/g' git cl format # Manual fix order of the new inserted #include <memory> cat /tmp/only_make_unique | xargs grep -l "#include <memory>" | \ xargs sed -i '/#include "absl\/memory\/memory.h"/d' git ls-files | grep BUILD.gn | \ xargs sed -i '/\/\/third_party\/abseil-cpp\/absl\/memory/d' python tools_webrtc/gn_check_autofix.py \ -m tryserver.webrtc -b linux_rel # Repead the gn_check_autofix step for other platforms git ls-files | grep BUILD.gn | \ xargs sed -i 's/absl\/memory:memory/absl\/memory/g' git cl format Bug: webrtc:10945 Change-Id: I3fe28ea80f4dd3ba3cf28effd151d5e1f19aff89 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/153221 Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org> Reviewed-by: Alessio Bazzica <alessiob@webrtc.org> Reviewed-by: Karl Wiberg <kwiberg@webrtc.org> Cr-Commit-Position: refs/heads/master@{#29209}
2019-09-17 17:06:18 +02:00
#include "modules/audio_coding/neteq/histogram.h"
#include "modules/audio_coding/neteq/mock/mock_histogram.h"
#include "modules/audio_coding/neteq/mock/mock_statistics_calculator.h"
Separate base minimum delay and minimum delay. On NetEq level latency corresponds to delay and two terms can be used interchangeably here. In order to implement latency constraint we need to provide a range of possible values which should be constant. See getCapabilities() here: https://www.w3.org/TR/mediacapture-streams/#dfn-applyconstraints-algorithm Lowest possible value accepted value is constant and equals 0. But because |packet_len_ms_| and |maximum_delay_ms_| may be updated during live of DelayManager upper bound is not constant. Moreover, due to change in |packet_len_ms_| the |minimum_delay_ms_| which was valid when its was set may be considered invalid later on. To circumvent that and provide constant range for capabilities we separate base minimum delay and minimum delay. ApplyConstraints algorithm will set base minimum delay. Base minimum delay will act as recommendation for lower bound of minimum delay and will be used to limit target delay. If user sets base minimum delay through ApplyConstraints which is bigger than currently possible maximum (e.g. bigger than NetEq maximum buffer size in milliseconds) then base minimum delay will be clamped to currently possible maximum to match user's intentions as best as possible. Note, that we keep original behavior when minimum_delay_ms_ (effective_minimum_delay_ms after this CL) in LimitTargetLevel method may be above upper bound due to changing packet audio length. Bug: webrtc:10287 Change-Id: I06b8f5cd3fd1bc36800af0447f91f7c4dc21a766 Reviewed-on: https://webrtc-review.googlesource.com/c/121700 Commit-Queue: Ruslan Burakov <kuddai@google.com> Reviewed-by: Minyue Li <minyue@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26666}
2019-02-13 14:25:39 +01:00
#include "rtc_base/checks.h"
#include "test/explicit_key_value_config.h"
#include "test/gmock.h"
#include "test/gtest.h"
namespace webrtc {
namespace {
using test::ExplicitKeyValueConfig;
constexpr int kMaxNumberOfPackets = 200;
constexpr int kTimeStepMs = 10;
constexpr int kFrameSizeMs = 20;
constexpr int kMaxBufferSizeMs = kMaxNumberOfPackets * kFrameSizeMs;
} // namespace
class DelayManagerTest : public ::testing::Test {
protected:
DelayManagerTest();
virtual void SetUp();
void Update(int delay);
void IncreaseTime(int inc_ms);
Revert "Remove legacy delay manger field trial and update default config." This reverts commit 93849d4b2a976b0a46059d6f74d9efd8f12eab92. Reason for revert: AcmReceiverBitExactnessOldApi tests failing on MacARM64; first failing build https://ci.chromium.org/ui/p/webrtc/builders/ci/MacARM64%20M1%20Release/1038/overview Example faliure [ RUN ] AcmReceiverBitExactnessOldApi.8kHzOutput ... (rtp_file_reader.cc:165): Failed to read ../../modules/audio_coding/acm2/audio_coding_module_unittest.cc:912: Failure Expected equality of these values: checksum_ref Which is: "636efe6d0a148f22c5383f356da3deac" checksum_string Which is: "6a288942d67e82076b38b17777cdaee4" Original change's description: > Remove legacy delay manger field trial and update default config. > > Bug: webrtc:10333 > Change-Id: I20e55d8d111d93657d1afe556fe3a325337c074c > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232820 > Reviewed-by: Ivo Creusen <ivoc@webrtc.org> > Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org> > Cr-Commit-Position: refs/heads/main@{#35321} TBR=ivoc@webrtc.org,jakobi@webrtc.org,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com Change-Id: I0bd3832aacba8dcd8e836650786cea20b4c083be No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: webrtc:10333 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/237441 Reviewed-by: Olga Sharonova <olka@webrtc.org> Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org> Commit-Queue: Olga Sharonova <olka@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35324}
2021-11-08 19:09:28 +00:00
TickTimer tick_timer_;
DelayManager dm_;
};
DelayManagerTest::DelayManagerTest()
: dm_(DelayManager::Config(ExplicitKeyValueConfig("")), &tick_timer_) {}
void DelayManagerTest::SetUp() {
dm_.SetPacketAudioLength(kFrameSizeMs);
}
void DelayManagerTest::Update(int delay) {
dm_.Update(delay, false);
}
void DelayManagerTest::IncreaseTime(int inc_ms) {
for (int t = 0; t < inc_ms; t += kTimeStepMs) {
tick_timer_.Increment();
}
}
TEST_F(DelayManagerTest, CreateAndDestroy) {
// Nothing to do here. The test fixture creates and destroys the DelayManager
// object.
}
TEST_F(DelayManagerTest, UpdateNormal) {
for (int i = 0; i < 50; ++i) {
Update(0);
IncreaseTime(kFrameSizeMs);
}
EXPECT_EQ(20, dm_.TargetDelayMs());
}
TEST_F(DelayManagerTest, MaxDelay) {
Update(0);
const int kMaxDelayMs = 60;
EXPECT_GT(dm_.TargetDelayMs(), kMaxDelayMs);
EXPECT_TRUE(dm_.SetMaximumDelay(kMaxDelayMs));
Update(0);
EXPECT_EQ(kMaxDelayMs, dm_.TargetDelayMs());
}
TEST_F(DelayManagerTest, MinDelay) {
Update(0);
2020-10-09 13:41:06 +02:00
int kMinDelayMs = 7 * kFrameSizeMs;
EXPECT_LT(dm_.TargetDelayMs(), kMinDelayMs);
dm_.SetMinimumDelay(kMinDelayMs);
IncreaseTime(kFrameSizeMs);
Update(0);
EXPECT_EQ(kMinDelayMs, dm_.TargetDelayMs());
}
Separate base minimum delay and minimum delay. On NetEq level latency corresponds to delay and two terms can be used interchangeably here. In order to implement latency constraint we need to provide a range of possible values which should be constant. See getCapabilities() here: https://www.w3.org/TR/mediacapture-streams/#dfn-applyconstraints-algorithm Lowest possible value accepted value is constant and equals 0. But because |packet_len_ms_| and |maximum_delay_ms_| may be updated during live of DelayManager upper bound is not constant. Moreover, due to change in |packet_len_ms_| the |minimum_delay_ms_| which was valid when its was set may be considered invalid later on. To circumvent that and provide constant range for capabilities we separate base minimum delay and minimum delay. ApplyConstraints algorithm will set base minimum delay. Base minimum delay will act as recommendation for lower bound of minimum delay and will be used to limit target delay. If user sets base minimum delay through ApplyConstraints which is bigger than currently possible maximum (e.g. bigger than NetEq maximum buffer size in milliseconds) then base minimum delay will be clamped to currently possible maximum to match user's intentions as best as possible. Note, that we keep original behavior when minimum_delay_ms_ (effective_minimum_delay_ms after this CL) in LimitTargetLevel method may be above upper bound due to changing packet audio length. Bug: webrtc:10287 Change-Id: I06b8f5cd3fd1bc36800af0447f91f7c4dc21a766 Reviewed-on: https://webrtc-review.googlesource.com/c/121700 Commit-Queue: Ruslan Burakov <kuddai@google.com> Reviewed-by: Minyue Li <minyue@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26666}
2019-02-13 14:25:39 +01:00
TEST_F(DelayManagerTest, BaseMinimumDelayCheckValidRange) {
// Base minimum delay should be between [0, 10000] milliseconds.
EXPECT_FALSE(dm_.SetBaseMinimumDelay(-1));
EXPECT_FALSE(dm_.SetBaseMinimumDelay(10001));
EXPECT_EQ(dm_.GetBaseMinimumDelay(), 0);
Separate base minimum delay and minimum delay. On NetEq level latency corresponds to delay and two terms can be used interchangeably here. In order to implement latency constraint we need to provide a range of possible values which should be constant. See getCapabilities() here: https://www.w3.org/TR/mediacapture-streams/#dfn-applyconstraints-algorithm Lowest possible value accepted value is constant and equals 0. But because |packet_len_ms_| and |maximum_delay_ms_| may be updated during live of DelayManager upper bound is not constant. Moreover, due to change in |packet_len_ms_| the |minimum_delay_ms_| which was valid when its was set may be considered invalid later on. To circumvent that and provide constant range for capabilities we separate base minimum delay and minimum delay. ApplyConstraints algorithm will set base minimum delay. Base minimum delay will act as recommendation for lower bound of minimum delay and will be used to limit target delay. If user sets base minimum delay through ApplyConstraints which is bigger than currently possible maximum (e.g. bigger than NetEq maximum buffer size in milliseconds) then base minimum delay will be clamped to currently possible maximum to match user's intentions as best as possible. Note, that we keep original behavior when minimum_delay_ms_ (effective_minimum_delay_ms after this CL) in LimitTargetLevel method may be above upper bound due to changing packet audio length. Bug: webrtc:10287 Change-Id: I06b8f5cd3fd1bc36800af0447f91f7c4dc21a766 Reviewed-on: https://webrtc-review.googlesource.com/c/121700 Commit-Queue: Ruslan Burakov <kuddai@google.com> Reviewed-by: Minyue Li <minyue@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26666}
2019-02-13 14:25:39 +01:00
EXPECT_TRUE(dm_.SetBaseMinimumDelay(7999));
EXPECT_EQ(dm_.GetBaseMinimumDelay(), 7999);
Separate base minimum delay and minimum delay. On NetEq level latency corresponds to delay and two terms can be used interchangeably here. In order to implement latency constraint we need to provide a range of possible values which should be constant. See getCapabilities() here: https://www.w3.org/TR/mediacapture-streams/#dfn-applyconstraints-algorithm Lowest possible value accepted value is constant and equals 0. But because |packet_len_ms_| and |maximum_delay_ms_| may be updated during live of DelayManager upper bound is not constant. Moreover, due to change in |packet_len_ms_| the |minimum_delay_ms_| which was valid when its was set may be considered invalid later on. To circumvent that and provide constant range for capabilities we separate base minimum delay and minimum delay. ApplyConstraints algorithm will set base minimum delay. Base minimum delay will act as recommendation for lower bound of minimum delay and will be used to limit target delay. If user sets base minimum delay through ApplyConstraints which is bigger than currently possible maximum (e.g. bigger than NetEq maximum buffer size in milliseconds) then base minimum delay will be clamped to currently possible maximum to match user's intentions as best as possible. Note, that we keep original behavior when minimum_delay_ms_ (effective_minimum_delay_ms after this CL) in LimitTargetLevel method may be above upper bound due to changing packet audio length. Bug: webrtc:10287 Change-Id: I06b8f5cd3fd1bc36800af0447f91f7c4dc21a766 Reviewed-on: https://webrtc-review.googlesource.com/c/121700 Commit-Queue: Ruslan Burakov <kuddai@google.com> Reviewed-by: Minyue Li <minyue@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26666}
2019-02-13 14:25:39 +01:00
}
TEST_F(DelayManagerTest, BaseMinimumDelayLowerThanMinimumDelay) {
constexpr int kBaseMinimumDelayMs = 100;
constexpr int kMinimumDelayMs = 200;
// Base minimum delay sets lower bound on minimum. That is why when base
// minimum delay is lower than minimum delay we use minimum delay.
RTC_DCHECK_LT(kBaseMinimumDelayMs, kMinimumDelayMs);
EXPECT_TRUE(dm_.SetBaseMinimumDelay(kBaseMinimumDelayMs));
EXPECT_TRUE(dm_.SetMinimumDelay(kMinimumDelayMs));
EXPECT_EQ(dm_.effective_minimum_delay_ms_for_test(), kMinimumDelayMs);
Separate base minimum delay and minimum delay. On NetEq level latency corresponds to delay and two terms can be used interchangeably here. In order to implement latency constraint we need to provide a range of possible values which should be constant. See getCapabilities() here: https://www.w3.org/TR/mediacapture-streams/#dfn-applyconstraints-algorithm Lowest possible value accepted value is constant and equals 0. But because |packet_len_ms_| and |maximum_delay_ms_| may be updated during live of DelayManager upper bound is not constant. Moreover, due to change in |packet_len_ms_| the |minimum_delay_ms_| which was valid when its was set may be considered invalid later on. To circumvent that and provide constant range for capabilities we separate base minimum delay and minimum delay. ApplyConstraints algorithm will set base minimum delay. Base minimum delay will act as recommendation for lower bound of minimum delay and will be used to limit target delay. If user sets base minimum delay through ApplyConstraints which is bigger than currently possible maximum (e.g. bigger than NetEq maximum buffer size in milliseconds) then base minimum delay will be clamped to currently possible maximum to match user's intentions as best as possible. Note, that we keep original behavior when minimum_delay_ms_ (effective_minimum_delay_ms after this CL) in LimitTargetLevel method may be above upper bound due to changing packet audio length. Bug: webrtc:10287 Change-Id: I06b8f5cd3fd1bc36800af0447f91f7c4dc21a766 Reviewed-on: https://webrtc-review.googlesource.com/c/121700 Commit-Queue: Ruslan Burakov <kuddai@google.com> Reviewed-by: Minyue Li <minyue@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26666}
2019-02-13 14:25:39 +01:00
}
TEST_F(DelayManagerTest, BaseMinimumDelayGreaterThanMinimumDelay) {
constexpr int kBaseMinimumDelayMs = 70;
constexpr int kMinimumDelayMs = 30;
// Base minimum delay sets lower bound on minimum. That is why when base
// minimum delay is greater than minimum delay we use base minimum delay.
RTC_DCHECK_GT(kBaseMinimumDelayMs, kMinimumDelayMs);
EXPECT_TRUE(dm_.SetBaseMinimumDelay(kBaseMinimumDelayMs));
EXPECT_TRUE(dm_.SetMinimumDelay(kMinimumDelayMs));
EXPECT_EQ(dm_.effective_minimum_delay_ms_for_test(), kBaseMinimumDelayMs);
Separate base minimum delay and minimum delay. On NetEq level latency corresponds to delay and two terms can be used interchangeably here. In order to implement latency constraint we need to provide a range of possible values which should be constant. See getCapabilities() here: https://www.w3.org/TR/mediacapture-streams/#dfn-applyconstraints-algorithm Lowest possible value accepted value is constant and equals 0. But because |packet_len_ms_| and |maximum_delay_ms_| may be updated during live of DelayManager upper bound is not constant. Moreover, due to change in |packet_len_ms_| the |minimum_delay_ms_| which was valid when its was set may be considered invalid later on. To circumvent that and provide constant range for capabilities we separate base minimum delay and minimum delay. ApplyConstraints algorithm will set base minimum delay. Base minimum delay will act as recommendation for lower bound of minimum delay and will be used to limit target delay. If user sets base minimum delay through ApplyConstraints which is bigger than currently possible maximum (e.g. bigger than NetEq maximum buffer size in milliseconds) then base minimum delay will be clamped to currently possible maximum to match user's intentions as best as possible. Note, that we keep original behavior when minimum_delay_ms_ (effective_minimum_delay_ms after this CL) in LimitTargetLevel method may be above upper bound due to changing packet audio length. Bug: webrtc:10287 Change-Id: I06b8f5cd3fd1bc36800af0447f91f7c4dc21a766 Reviewed-on: https://webrtc-review.googlesource.com/c/121700 Commit-Queue: Ruslan Burakov <kuddai@google.com> Reviewed-by: Minyue Li <minyue@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26666}
2019-02-13 14:25:39 +01:00
}
TEST_F(DelayManagerTest, BaseMinimumDelayGreaterThanBufferSize) {
constexpr int kBaseMinimumDelayMs = kMaxBufferSizeMs + 1;
constexpr int kMinimumDelayMs = 12;
constexpr int kMaximumDelayMs = 20;
Separate base minimum delay and minimum delay. On NetEq level latency corresponds to delay and two terms can be used interchangeably here. In order to implement latency constraint we need to provide a range of possible values which should be constant. See getCapabilities() here: https://www.w3.org/TR/mediacapture-streams/#dfn-applyconstraints-algorithm Lowest possible value accepted value is constant and equals 0. But because |packet_len_ms_| and |maximum_delay_ms_| may be updated during live of DelayManager upper bound is not constant. Moreover, due to change in |packet_len_ms_| the |minimum_delay_ms_| which was valid when its was set may be considered invalid later on. To circumvent that and provide constant range for capabilities we separate base minimum delay and minimum delay. ApplyConstraints algorithm will set base minimum delay. Base minimum delay will act as recommendation for lower bound of minimum delay and will be used to limit target delay. If user sets base minimum delay through ApplyConstraints which is bigger than currently possible maximum (e.g. bigger than NetEq maximum buffer size in milliseconds) then base minimum delay will be clamped to currently possible maximum to match user's intentions as best as possible. Note, that we keep original behavior when minimum_delay_ms_ (effective_minimum_delay_ms after this CL) in LimitTargetLevel method may be above upper bound due to changing packet audio length. Bug: webrtc:10287 Change-Id: I06b8f5cd3fd1bc36800af0447f91f7c4dc21a766 Reviewed-on: https://webrtc-review.googlesource.com/c/121700 Commit-Queue: Ruslan Burakov <kuddai@google.com> Reviewed-by: Minyue Li <minyue@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26666}
2019-02-13 14:25:39 +01:00
constexpr int kMaxBufferSizeMsQ75 = 3 * kMaxBufferSizeMs / 4;
EXPECT_TRUE(dm_.SetMaximumDelay(kMaximumDelayMs));
Separate base minimum delay and minimum delay. On NetEq level latency corresponds to delay and two terms can be used interchangeably here. In order to implement latency constraint we need to provide a range of possible values which should be constant. See getCapabilities() here: https://www.w3.org/TR/mediacapture-streams/#dfn-applyconstraints-algorithm Lowest possible value accepted value is constant and equals 0. But because |packet_len_ms_| and |maximum_delay_ms_| may be updated during live of DelayManager upper bound is not constant. Moreover, due to change in |packet_len_ms_| the |minimum_delay_ms_| which was valid when its was set may be considered invalid later on. To circumvent that and provide constant range for capabilities we separate base minimum delay and minimum delay. ApplyConstraints algorithm will set base minimum delay. Base minimum delay will act as recommendation for lower bound of minimum delay and will be used to limit target delay. If user sets base minimum delay through ApplyConstraints which is bigger than currently possible maximum (e.g. bigger than NetEq maximum buffer size in milliseconds) then base minimum delay will be clamped to currently possible maximum to match user's intentions as best as possible. Note, that we keep original behavior when minimum_delay_ms_ (effective_minimum_delay_ms after this CL) in LimitTargetLevel method may be above upper bound due to changing packet audio length. Bug: webrtc:10287 Change-Id: I06b8f5cd3fd1bc36800af0447f91f7c4dc21a766 Reviewed-on: https://webrtc-review.googlesource.com/c/121700 Commit-Queue: Ruslan Burakov <kuddai@google.com> Reviewed-by: Minyue Li <minyue@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26666}
2019-02-13 14:25:39 +01:00
// Base minimum delay is greater than minimum delay, that is why we clamp
// it to current the highest possible value which is maximum delay.
RTC_DCHECK_GT(kBaseMinimumDelayMs, kMinimumDelayMs);
RTC_DCHECK_GT(kBaseMinimumDelayMs, kMaxBufferSizeMs);
RTC_DCHECK_GT(kBaseMinimumDelayMs, kMaximumDelayMs);
RTC_DCHECK_LT(kMaximumDelayMs, kMaxBufferSizeMsQ75);
Separate base minimum delay and minimum delay. On NetEq level latency corresponds to delay and two terms can be used interchangeably here. In order to implement latency constraint we need to provide a range of possible values which should be constant. See getCapabilities() here: https://www.w3.org/TR/mediacapture-streams/#dfn-applyconstraints-algorithm Lowest possible value accepted value is constant and equals 0. But because |packet_len_ms_| and |maximum_delay_ms_| may be updated during live of DelayManager upper bound is not constant. Moreover, due to change in |packet_len_ms_| the |minimum_delay_ms_| which was valid when its was set may be considered invalid later on. To circumvent that and provide constant range for capabilities we separate base minimum delay and minimum delay. ApplyConstraints algorithm will set base minimum delay. Base minimum delay will act as recommendation for lower bound of minimum delay and will be used to limit target delay. If user sets base minimum delay through ApplyConstraints which is bigger than currently possible maximum (e.g. bigger than NetEq maximum buffer size in milliseconds) then base minimum delay will be clamped to currently possible maximum to match user's intentions as best as possible. Note, that we keep original behavior when minimum_delay_ms_ (effective_minimum_delay_ms after this CL) in LimitTargetLevel method may be above upper bound due to changing packet audio length. Bug: webrtc:10287 Change-Id: I06b8f5cd3fd1bc36800af0447f91f7c4dc21a766 Reviewed-on: https://webrtc-review.googlesource.com/c/121700 Commit-Queue: Ruslan Burakov <kuddai@google.com> Reviewed-by: Minyue Li <minyue@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26666}
2019-02-13 14:25:39 +01:00
EXPECT_TRUE(dm_.SetMinimumDelay(kMinimumDelayMs));
EXPECT_TRUE(dm_.SetBaseMinimumDelay(kBaseMinimumDelayMs));
Separate base minimum delay and minimum delay. On NetEq level latency corresponds to delay and two terms can be used interchangeably here. In order to implement latency constraint we need to provide a range of possible values which should be constant. See getCapabilities() here: https://www.w3.org/TR/mediacapture-streams/#dfn-applyconstraints-algorithm Lowest possible value accepted value is constant and equals 0. But because |packet_len_ms_| and |maximum_delay_ms_| may be updated during live of DelayManager upper bound is not constant. Moreover, due to change in |packet_len_ms_| the |minimum_delay_ms_| which was valid when its was set may be considered invalid later on. To circumvent that and provide constant range for capabilities we separate base minimum delay and minimum delay. ApplyConstraints algorithm will set base minimum delay. Base minimum delay will act as recommendation for lower bound of minimum delay and will be used to limit target delay. If user sets base minimum delay through ApplyConstraints which is bigger than currently possible maximum (e.g. bigger than NetEq maximum buffer size in milliseconds) then base minimum delay will be clamped to currently possible maximum to match user's intentions as best as possible. Note, that we keep original behavior when minimum_delay_ms_ (effective_minimum_delay_ms after this CL) in LimitTargetLevel method may be above upper bound due to changing packet audio length. Bug: webrtc:10287 Change-Id: I06b8f5cd3fd1bc36800af0447f91f7c4dc21a766 Reviewed-on: https://webrtc-review.googlesource.com/c/121700 Commit-Queue: Ruslan Burakov <kuddai@google.com> Reviewed-by: Minyue Li <minyue@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26666}
2019-02-13 14:25:39 +01:00
// Unset maximum value.
EXPECT_TRUE(dm_.SetMaximumDelay(0));
Separate base minimum delay and minimum delay. On NetEq level latency corresponds to delay and two terms can be used interchangeably here. In order to implement latency constraint we need to provide a range of possible values which should be constant. See getCapabilities() here: https://www.w3.org/TR/mediacapture-streams/#dfn-applyconstraints-algorithm Lowest possible value accepted value is constant and equals 0. But because |packet_len_ms_| and |maximum_delay_ms_| may be updated during live of DelayManager upper bound is not constant. Moreover, due to change in |packet_len_ms_| the |minimum_delay_ms_| which was valid when its was set may be considered invalid later on. To circumvent that and provide constant range for capabilities we separate base minimum delay and minimum delay. ApplyConstraints algorithm will set base minimum delay. Base minimum delay will act as recommendation for lower bound of minimum delay and will be used to limit target delay. If user sets base minimum delay through ApplyConstraints which is bigger than currently possible maximum (e.g. bigger than NetEq maximum buffer size in milliseconds) then base minimum delay will be clamped to currently possible maximum to match user's intentions as best as possible. Note, that we keep original behavior when minimum_delay_ms_ (effective_minimum_delay_ms after this CL) in LimitTargetLevel method may be above upper bound due to changing packet audio length. Bug: webrtc:10287 Change-Id: I06b8f5cd3fd1bc36800af0447f91f7c4dc21a766 Reviewed-on: https://webrtc-review.googlesource.com/c/121700 Commit-Queue: Ruslan Burakov <kuddai@google.com> Reviewed-by: Minyue Li <minyue@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26666}
2019-02-13 14:25:39 +01:00
// With maximum value unset, the highest possible value now is 75% of
// currently possible maximum buffer size.
EXPECT_EQ(dm_.effective_minimum_delay_ms_for_test(), kMaxBufferSizeMsQ75);
Separate base minimum delay and minimum delay. On NetEq level latency corresponds to delay and two terms can be used interchangeably here. In order to implement latency constraint we need to provide a range of possible values which should be constant. See getCapabilities() here: https://www.w3.org/TR/mediacapture-streams/#dfn-applyconstraints-algorithm Lowest possible value accepted value is constant and equals 0. But because |packet_len_ms_| and |maximum_delay_ms_| may be updated during live of DelayManager upper bound is not constant. Moreover, due to change in |packet_len_ms_| the |minimum_delay_ms_| which was valid when its was set may be considered invalid later on. To circumvent that and provide constant range for capabilities we separate base minimum delay and minimum delay. ApplyConstraints algorithm will set base minimum delay. Base minimum delay will act as recommendation for lower bound of minimum delay and will be used to limit target delay. If user sets base minimum delay through ApplyConstraints which is bigger than currently possible maximum (e.g. bigger than NetEq maximum buffer size in milliseconds) then base minimum delay will be clamped to currently possible maximum to match user's intentions as best as possible. Note, that we keep original behavior when minimum_delay_ms_ (effective_minimum_delay_ms after this CL) in LimitTargetLevel method may be above upper bound due to changing packet audio length. Bug: webrtc:10287 Change-Id: I06b8f5cd3fd1bc36800af0447f91f7c4dc21a766 Reviewed-on: https://webrtc-review.googlesource.com/c/121700 Commit-Queue: Ruslan Burakov <kuddai@google.com> Reviewed-by: Minyue Li <minyue@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26666}
2019-02-13 14:25:39 +01:00
}
TEST_F(DelayManagerTest, BaseMinimumDelayGreaterThanMaximumDelay) {
constexpr int kMaximumDelayMs = 400;
constexpr int kBaseMinimumDelayMs = kMaximumDelayMs + 1;
constexpr int kMinimumDelayMs = 20;
// Base minimum delay is greater than minimum delay, that is why we clamp
// it to current the highest possible value which is kMaximumDelayMs.
RTC_DCHECK_GT(kBaseMinimumDelayMs, kMinimumDelayMs);
RTC_DCHECK_GT(kBaseMinimumDelayMs, kMaximumDelayMs);
RTC_DCHECK_LT(kMaximumDelayMs, kMaxBufferSizeMs);
EXPECT_TRUE(dm_.SetMaximumDelay(kMaximumDelayMs));
EXPECT_TRUE(dm_.SetMinimumDelay(kMinimumDelayMs));
EXPECT_TRUE(dm_.SetBaseMinimumDelay(kBaseMinimumDelayMs));
EXPECT_EQ(dm_.effective_minimum_delay_ms_for_test(), kMaximumDelayMs);
Separate base minimum delay and minimum delay. On NetEq level latency corresponds to delay and two terms can be used interchangeably here. In order to implement latency constraint we need to provide a range of possible values which should be constant. See getCapabilities() here: https://www.w3.org/TR/mediacapture-streams/#dfn-applyconstraints-algorithm Lowest possible value accepted value is constant and equals 0. But because |packet_len_ms_| and |maximum_delay_ms_| may be updated during live of DelayManager upper bound is not constant. Moreover, due to change in |packet_len_ms_| the |minimum_delay_ms_| which was valid when its was set may be considered invalid later on. To circumvent that and provide constant range for capabilities we separate base minimum delay and minimum delay. ApplyConstraints algorithm will set base minimum delay. Base minimum delay will act as recommendation for lower bound of minimum delay and will be used to limit target delay. If user sets base minimum delay through ApplyConstraints which is bigger than currently possible maximum (e.g. bigger than NetEq maximum buffer size in milliseconds) then base minimum delay will be clamped to currently possible maximum to match user's intentions as best as possible. Note, that we keep original behavior when minimum_delay_ms_ (effective_minimum_delay_ms after this CL) in LimitTargetLevel method may be above upper bound due to changing packet audio length. Bug: webrtc:10287 Change-Id: I06b8f5cd3fd1bc36800af0447f91f7c4dc21a766 Reviewed-on: https://webrtc-review.googlesource.com/c/121700 Commit-Queue: Ruslan Burakov <kuddai@google.com> Reviewed-by: Minyue Li <minyue@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26666}
2019-02-13 14:25:39 +01:00
}
TEST_F(DelayManagerTest, BaseMinimumDelayLowerThanMaxSize) {
constexpr int kMaximumDelayMs = 400;
constexpr int kBaseMinimumDelayMs = kMaximumDelayMs - 1;
constexpr int kMinimumDelayMs = 20;
// Base minimum delay is greater than minimum delay, and lower than maximum
// delays that is why it is used.
RTC_DCHECK_GT(kBaseMinimumDelayMs, kMinimumDelayMs);
RTC_DCHECK_LT(kBaseMinimumDelayMs, kMaximumDelayMs);
EXPECT_TRUE(dm_.SetMaximumDelay(kMaximumDelayMs));
EXPECT_TRUE(dm_.SetMinimumDelay(kMinimumDelayMs));
EXPECT_TRUE(dm_.SetBaseMinimumDelay(kBaseMinimumDelayMs));
EXPECT_EQ(dm_.effective_minimum_delay_ms_for_test(), kBaseMinimumDelayMs);
Separate base minimum delay and minimum delay. On NetEq level latency corresponds to delay and two terms can be used interchangeably here. In order to implement latency constraint we need to provide a range of possible values which should be constant. See getCapabilities() here: https://www.w3.org/TR/mediacapture-streams/#dfn-applyconstraints-algorithm Lowest possible value accepted value is constant and equals 0. But because |packet_len_ms_| and |maximum_delay_ms_| may be updated during live of DelayManager upper bound is not constant. Moreover, due to change in |packet_len_ms_| the |minimum_delay_ms_| which was valid when its was set may be considered invalid later on. To circumvent that and provide constant range for capabilities we separate base minimum delay and minimum delay. ApplyConstraints algorithm will set base minimum delay. Base minimum delay will act as recommendation for lower bound of minimum delay and will be used to limit target delay. If user sets base minimum delay through ApplyConstraints which is bigger than currently possible maximum (e.g. bigger than NetEq maximum buffer size in milliseconds) then base minimum delay will be clamped to currently possible maximum to match user's intentions as best as possible. Note, that we keep original behavior when minimum_delay_ms_ (effective_minimum_delay_ms after this CL) in LimitTargetLevel method may be above upper bound due to changing packet audio length. Bug: webrtc:10287 Change-Id: I06b8f5cd3fd1bc36800af0447f91f7c4dc21a766 Reviewed-on: https://webrtc-review.googlesource.com/c/121700 Commit-Queue: Ruslan Burakov <kuddai@google.com> Reviewed-by: Minyue Li <minyue@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26666}
2019-02-13 14:25:39 +01:00
}
TEST_F(DelayManagerTest, MinimumDelayMemorization) {
// Check that when we increase base minimum delay to value higher than
// minimum delay then minimum delay is still memorized. This allows to
// restore effective minimum delay to memorized minimum delay value when we
// decrease base minimum delay.
constexpr int kBaseMinimumDelayMsLow = 10;
constexpr int kMinimumDelayMs = 20;
constexpr int kBaseMinimumDelayMsHigh = 30;
EXPECT_TRUE(dm_.SetBaseMinimumDelay(kBaseMinimumDelayMsLow));
EXPECT_TRUE(dm_.SetMinimumDelay(kMinimumDelayMs));
Separate base minimum delay and minimum delay. On NetEq level latency corresponds to delay and two terms can be used interchangeably here. In order to implement latency constraint we need to provide a range of possible values which should be constant. See getCapabilities() here: https://www.w3.org/TR/mediacapture-streams/#dfn-applyconstraints-algorithm Lowest possible value accepted value is constant and equals 0. But because |packet_len_ms_| and |maximum_delay_ms_| may be updated during live of DelayManager upper bound is not constant. Moreover, due to change in |packet_len_ms_| the |minimum_delay_ms_| which was valid when its was set may be considered invalid later on. To circumvent that and provide constant range for capabilities we separate base minimum delay and minimum delay. ApplyConstraints algorithm will set base minimum delay. Base minimum delay will act as recommendation for lower bound of minimum delay and will be used to limit target delay. If user sets base minimum delay through ApplyConstraints which is bigger than currently possible maximum (e.g. bigger than NetEq maximum buffer size in milliseconds) then base minimum delay will be clamped to currently possible maximum to match user's intentions as best as possible. Note, that we keep original behavior when minimum_delay_ms_ (effective_minimum_delay_ms after this CL) in LimitTargetLevel method may be above upper bound due to changing packet audio length. Bug: webrtc:10287 Change-Id: I06b8f5cd3fd1bc36800af0447f91f7c4dc21a766 Reviewed-on: https://webrtc-review.googlesource.com/c/121700 Commit-Queue: Ruslan Burakov <kuddai@google.com> Reviewed-by: Minyue Li <minyue@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26666}
2019-02-13 14:25:39 +01:00
// Minimum delay is used as it is higher than base minimum delay.
EXPECT_EQ(dm_.effective_minimum_delay_ms_for_test(), kMinimumDelayMs);
Separate base minimum delay and minimum delay. On NetEq level latency corresponds to delay and two terms can be used interchangeably here. In order to implement latency constraint we need to provide a range of possible values which should be constant. See getCapabilities() here: https://www.w3.org/TR/mediacapture-streams/#dfn-applyconstraints-algorithm Lowest possible value accepted value is constant and equals 0. But because |packet_len_ms_| and |maximum_delay_ms_| may be updated during live of DelayManager upper bound is not constant. Moreover, due to change in |packet_len_ms_| the |minimum_delay_ms_| which was valid when its was set may be considered invalid later on. To circumvent that and provide constant range for capabilities we separate base minimum delay and minimum delay. ApplyConstraints algorithm will set base minimum delay. Base minimum delay will act as recommendation for lower bound of minimum delay and will be used to limit target delay. If user sets base minimum delay through ApplyConstraints which is bigger than currently possible maximum (e.g. bigger than NetEq maximum buffer size in milliseconds) then base minimum delay will be clamped to currently possible maximum to match user's intentions as best as possible. Note, that we keep original behavior when minimum_delay_ms_ (effective_minimum_delay_ms after this CL) in LimitTargetLevel method may be above upper bound due to changing packet audio length. Bug: webrtc:10287 Change-Id: I06b8f5cd3fd1bc36800af0447f91f7c4dc21a766 Reviewed-on: https://webrtc-review.googlesource.com/c/121700 Commit-Queue: Ruslan Burakov <kuddai@google.com> Reviewed-by: Minyue Li <minyue@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26666}
2019-02-13 14:25:39 +01:00
EXPECT_TRUE(dm_.SetBaseMinimumDelay(kBaseMinimumDelayMsHigh));
Separate base minimum delay and minimum delay. On NetEq level latency corresponds to delay and two terms can be used interchangeably here. In order to implement latency constraint we need to provide a range of possible values which should be constant. See getCapabilities() here: https://www.w3.org/TR/mediacapture-streams/#dfn-applyconstraints-algorithm Lowest possible value accepted value is constant and equals 0. But because |packet_len_ms_| and |maximum_delay_ms_| may be updated during live of DelayManager upper bound is not constant. Moreover, due to change in |packet_len_ms_| the |minimum_delay_ms_| which was valid when its was set may be considered invalid later on. To circumvent that and provide constant range for capabilities we separate base minimum delay and minimum delay. ApplyConstraints algorithm will set base minimum delay. Base minimum delay will act as recommendation for lower bound of minimum delay and will be used to limit target delay. If user sets base minimum delay through ApplyConstraints which is bigger than currently possible maximum (e.g. bigger than NetEq maximum buffer size in milliseconds) then base minimum delay will be clamped to currently possible maximum to match user's intentions as best as possible. Note, that we keep original behavior when minimum_delay_ms_ (effective_minimum_delay_ms after this CL) in LimitTargetLevel method may be above upper bound due to changing packet audio length. Bug: webrtc:10287 Change-Id: I06b8f5cd3fd1bc36800af0447f91f7c4dc21a766 Reviewed-on: https://webrtc-review.googlesource.com/c/121700 Commit-Queue: Ruslan Burakov <kuddai@google.com> Reviewed-by: Minyue Li <minyue@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26666}
2019-02-13 14:25:39 +01:00
// Base minimum delay is used as it is now higher than minimum delay.
EXPECT_EQ(dm_.effective_minimum_delay_ms_for_test(), kBaseMinimumDelayMsHigh);
Separate base minimum delay and minimum delay. On NetEq level latency corresponds to delay and two terms can be used interchangeably here. In order to implement latency constraint we need to provide a range of possible values which should be constant. See getCapabilities() here: https://www.w3.org/TR/mediacapture-streams/#dfn-applyconstraints-algorithm Lowest possible value accepted value is constant and equals 0. But because |packet_len_ms_| and |maximum_delay_ms_| may be updated during live of DelayManager upper bound is not constant. Moreover, due to change in |packet_len_ms_| the |minimum_delay_ms_| which was valid when its was set may be considered invalid later on. To circumvent that and provide constant range for capabilities we separate base minimum delay and minimum delay. ApplyConstraints algorithm will set base minimum delay. Base minimum delay will act as recommendation for lower bound of minimum delay and will be used to limit target delay. If user sets base minimum delay through ApplyConstraints which is bigger than currently possible maximum (e.g. bigger than NetEq maximum buffer size in milliseconds) then base minimum delay will be clamped to currently possible maximum to match user's intentions as best as possible. Note, that we keep original behavior when minimum_delay_ms_ (effective_minimum_delay_ms after this CL) in LimitTargetLevel method may be above upper bound due to changing packet audio length. Bug: webrtc:10287 Change-Id: I06b8f5cd3fd1bc36800af0447f91f7c4dc21a766 Reviewed-on: https://webrtc-review.googlesource.com/c/121700 Commit-Queue: Ruslan Burakov <kuddai@google.com> Reviewed-by: Minyue Li <minyue@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26666}
2019-02-13 14:25:39 +01:00
EXPECT_TRUE(dm_.SetBaseMinimumDelay(kBaseMinimumDelayMsLow));
Separate base minimum delay and minimum delay. On NetEq level latency corresponds to delay and two terms can be used interchangeably here. In order to implement latency constraint we need to provide a range of possible values which should be constant. See getCapabilities() here: https://www.w3.org/TR/mediacapture-streams/#dfn-applyconstraints-algorithm Lowest possible value accepted value is constant and equals 0. But because |packet_len_ms_| and |maximum_delay_ms_| may be updated during live of DelayManager upper bound is not constant. Moreover, due to change in |packet_len_ms_| the |minimum_delay_ms_| which was valid when its was set may be considered invalid later on. To circumvent that and provide constant range for capabilities we separate base minimum delay and minimum delay. ApplyConstraints algorithm will set base minimum delay. Base minimum delay will act as recommendation for lower bound of minimum delay and will be used to limit target delay. If user sets base minimum delay through ApplyConstraints which is bigger than currently possible maximum (e.g. bigger than NetEq maximum buffer size in milliseconds) then base minimum delay will be clamped to currently possible maximum to match user's intentions as best as possible. Note, that we keep original behavior when minimum_delay_ms_ (effective_minimum_delay_ms after this CL) in LimitTargetLevel method may be above upper bound due to changing packet audio length. Bug: webrtc:10287 Change-Id: I06b8f5cd3fd1bc36800af0447f91f7c4dc21a766 Reviewed-on: https://webrtc-review.googlesource.com/c/121700 Commit-Queue: Ruslan Burakov <kuddai@google.com> Reviewed-by: Minyue Li <minyue@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26666}
2019-02-13 14:25:39 +01:00
// Check that minimum delay is memorized and is used again.
EXPECT_EQ(dm_.effective_minimum_delay_ms_for_test(), kMinimumDelayMs);
Separate base minimum delay and minimum delay. On NetEq level latency corresponds to delay and two terms can be used interchangeably here. In order to implement latency constraint we need to provide a range of possible values which should be constant. See getCapabilities() here: https://www.w3.org/TR/mediacapture-streams/#dfn-applyconstraints-algorithm Lowest possible value accepted value is constant and equals 0. But because |packet_len_ms_| and |maximum_delay_ms_| may be updated during live of DelayManager upper bound is not constant. Moreover, due to change in |packet_len_ms_| the |minimum_delay_ms_| which was valid when its was set may be considered invalid later on. To circumvent that and provide constant range for capabilities we separate base minimum delay and minimum delay. ApplyConstraints algorithm will set base minimum delay. Base minimum delay will act as recommendation for lower bound of minimum delay and will be used to limit target delay. If user sets base minimum delay through ApplyConstraints which is bigger than currently possible maximum (e.g. bigger than NetEq maximum buffer size in milliseconds) then base minimum delay will be clamped to currently possible maximum to match user's intentions as best as possible. Note, that we keep original behavior when minimum_delay_ms_ (effective_minimum_delay_ms after this CL) in LimitTargetLevel method may be above upper bound due to changing packet audio length. Bug: webrtc:10287 Change-Id: I06b8f5cd3fd1bc36800af0447f91f7c4dc21a766 Reviewed-on: https://webrtc-review.googlesource.com/c/121700 Commit-Queue: Ruslan Burakov <kuddai@google.com> Reviewed-by: Minyue Li <minyue@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26666}
2019-02-13 14:25:39 +01:00
}
TEST_F(DelayManagerTest, BaseMinimumDelay) {
// First packet arrival.
Update(0);
2020-10-09 13:41:06 +02:00
constexpr int kBaseMinimumDelayMs = 7 * kFrameSizeMs;
EXPECT_LT(dm_.TargetDelayMs(), kBaseMinimumDelayMs);
EXPECT_TRUE(dm_.SetBaseMinimumDelay(kBaseMinimumDelayMs));
EXPECT_EQ(dm_.GetBaseMinimumDelay(), kBaseMinimumDelayMs);
Separate base minimum delay and minimum delay. On NetEq level latency corresponds to delay and two terms can be used interchangeably here. In order to implement latency constraint we need to provide a range of possible values which should be constant. See getCapabilities() here: https://www.w3.org/TR/mediacapture-streams/#dfn-applyconstraints-algorithm Lowest possible value accepted value is constant and equals 0. But because |packet_len_ms_| and |maximum_delay_ms_| may be updated during live of DelayManager upper bound is not constant. Moreover, due to change in |packet_len_ms_| the |minimum_delay_ms_| which was valid when its was set may be considered invalid later on. To circumvent that and provide constant range for capabilities we separate base minimum delay and minimum delay. ApplyConstraints algorithm will set base minimum delay. Base minimum delay will act as recommendation for lower bound of minimum delay and will be used to limit target delay. If user sets base minimum delay through ApplyConstraints which is bigger than currently possible maximum (e.g. bigger than NetEq maximum buffer size in milliseconds) then base minimum delay will be clamped to currently possible maximum to match user's intentions as best as possible. Note, that we keep original behavior when minimum_delay_ms_ (effective_minimum_delay_ms after this CL) in LimitTargetLevel method may be above upper bound due to changing packet audio length. Bug: webrtc:10287 Change-Id: I06b8f5cd3fd1bc36800af0447f91f7c4dc21a766 Reviewed-on: https://webrtc-review.googlesource.com/c/121700 Commit-Queue: Ruslan Burakov <kuddai@google.com> Reviewed-by: Minyue Li <minyue@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26666}
2019-02-13 14:25:39 +01:00
IncreaseTime(kFrameSizeMs);
Update(0);
EXPECT_EQ(dm_.GetBaseMinimumDelay(), kBaseMinimumDelayMs);
EXPECT_EQ(kBaseMinimumDelayMs, dm_.TargetDelayMs());
}
TEST_F(DelayManagerTest, Failures) {
// Wrong packet size.
EXPECT_EQ(-1, dm_.SetPacketAudioLength(0));
EXPECT_EQ(-1, dm_.SetPacketAudioLength(-1));
// Minimum delay higher than a maximum delay is not accepted.
EXPECT_TRUE(dm_.SetMaximumDelay(20));
EXPECT_FALSE(dm_.SetMinimumDelay(40));
// Maximum delay less than minimum delay is not accepted.
EXPECT_TRUE(dm_.SetMaximumDelay(100));
EXPECT_TRUE(dm_.SetMinimumDelay(80));
EXPECT_FALSE(dm_.SetMaximumDelay(60));
}
} // namespace webrtc