commit 4a68fb9ab43d8f12a70319a30d601436a354535a
author Ruslan Burakov <kuddai@google.com> Wed Feb 13 13:25:39 2019
committer Commit Bot <commit-bot@chromium.org> Wed Feb 13 15:54:43 2019
tree 755dd0ca159c5d9be433f18df2af4c796df93f9f
parent 69bb3afd53d8a32c1678ec8ed484d3f7e6b132d0

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}