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

115 lines
3.8 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.
*/
#ifndef MODULES_AUDIO_CODING_NETEQ_DELAY_MANAGER_H_
#define MODULES_AUDIO_CODING_NETEQ_DELAY_MANAGER_H_
#include <string.h> // Provide access to size_t.
#include <deque>
#include <memory>
#include "absl/types/optional.h"
#include "api/neteq/tick_timer.h"
#include "modules/audio_coding/neteq/histogram.h"
#include "modules/audio_coding/neteq/reorder_optimizer.h"
#include "modules/audio_coding/neteq/underrun_optimizer.h"
namespace webrtc {
class DelayManager {
public:
struct Config {
Config();
void Log();
// Options that can be configured via field trial.
double quantile = 0.95;
double forget_factor = 0.983;
absl::optional<double> start_forget_weight = 2;
absl::optional<int> resample_interval_ms = 500;
bool use_reorder_optimizer = true;
double reorder_forget_factor = 0.9993;
int ms_per_loss_percent = 20;
// Options that are externally populated.
int max_packets_in_buffer = 200;
int base_minimum_delay_ms = 0;
};
DelayManager(const Config& config, const TickTimer* tick_timer);
virtual ~DelayManager();
DelayManager(const DelayManager&) = delete;
DelayManager& operator=(const DelayManager&) = delete;
// Updates the delay manager that a new packet arrived with delay
// `arrival_delay_ms`. This updates the statistics and a new target buffer
// level is calculated. The `reordered` flag indicates if the packet was
// reordered.
virtual void Update(int arrival_delay_ms, bool reordered);
2020-10-09 13:41:06 +02:00
// Resets all state.
virtual void Reset();
2020-10-09 13:41:06 +02:00
// Gets the target buffer level in milliseconds.
virtual int TargetDelayMs() const;
Revert "Reland "Refactor NetEq delay manager logic."" This reverts commit 2a7c57c34f323ee1977f6e7809ee23bfcf9a7459. Reason for revert: unexpected big changes in behavior. Original change's description: > Reland "Refactor NetEq delay manager logic." > > This is a reland of f8e62fcb14e37a5be4f1e4f599d34c8483fea8e9 > > Original change's description: > > Refactor NetEq delay manager logic. > > > > - Removes dependence on sequence number for calculating target delay. > > - Changes target delay unit to milliseconds instead of number of > > packets. > > - Moves acceleration/preemptive expand thresholds to decision logic. > > Tests for this will be added in a follow up cl. > > > > Bug: webrtc:10333 > > Change-Id: If690aae4abf41ef1d9353f0ff01fb7d121cf8a26 > > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/186265 > > Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org> > > Reviewed-by: Ivo Creusen <ivoc@webrtc.org> > > Cr-Commit-Position: refs/heads/master@{#32326} > > Bug: webrtc:10333 > Change-Id: Iad5e7063f63b84762959ee5b412f5f14a7b2cd06 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/186943 > Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org> > Reviewed-by: Ivo Creusen <ivoc@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#32332} TBR=ivoc@webrtc.org,jakobi@webrtc.org Change-Id: Iffda0e8a7b647392d8dfc6724d49439fa13d71b2 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: webrtc:10333 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/187100 Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org> Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#32341}
2020-10-07 12:46:42 +00:00
2020-10-09 13:41:06 +02:00
// Notifies the DelayManager of how much audio data is carried in each packet.
virtual int SetPacketAudioLength(int length_ms);
// Accessors and mutators.
// Assuming `delay` is in valid range.
virtual bool SetMinimumDelay(int delay_ms);
virtual bool SetMaximumDelay(int delay_ms);
virtual bool SetBaseMinimumDelay(int delay_ms);
virtual int GetBaseMinimumDelay() const;
2020-10-09 13:41:06 +02:00
// These accessors are only intended for testing purposes.
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
int effective_minimum_delay_ms_for_test() const {
return effective_minimum_delay_ms_;
}
private:
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
// Provides value which minimum delay can't exceed based on current buffer
// size and given `maximum_delay_ms_`. Lower bound is a constant 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
int MinimumDelayUpperBound() const;
// Updates `effective_minimum_delay_ms_` delay based on current
// `minimum_delay_ms_`, `base_minimum_delay_ms_` and `maximum_delay_ms_`
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
// and buffer size.
void UpdateEffectiveMinimumDelay();
// Makes sure that `delay_ms` is less than maximum delay, if any maximum
// is set. Also, if possible check `delay_ms` to be less than 75% of
// `max_packets_in_buffer_`.
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
bool IsValidMinimumDelay(int delay_ms) const;
bool IsValidBaseMinimumDelay(int delay_ms) const;
2020-10-09 13:41:06 +02:00
// TODO(jakobi): set maximum buffer delay instead of number of packets.
const int max_packets_in_buffer_;
UnderrunOptimizer underrun_optimizer_;
std::unique_ptr<ReorderOptimizer> reorder_optimizer_;
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
int base_minimum_delay_ms_;
2020-10-09 13:41:06 +02:00
int effective_minimum_delay_ms_; // Used as lower bound for target delay.
int minimum_delay_ms_; // Externally set minimum delay.
int maximum_delay_ms_; // Externally set maximum allowed delay.
int packet_len_ms_ = 0;
int target_level_ms_; // Currently preferred buffer level.
};
} // namespace webrtc
#endif // MODULES_AUDIO_CODING_NETEQ_DELAY_MANAGER_H_