我关注自适应抖动缓冲器的设计，通过增加和减少抖动计算来增加和减少容量。
我认为没有理由对延迟或容量进行任何调整，除非存在缓冲区欠载，然后可能会出现超出容量的突发传输数据包（假设缓冲区容量等于缓冲区深度/延迟）。例如，如果我收到20ms的数据包，我可能会实现一个100ms深的缓冲区，因此可以容纳5个数据包。如果160ms在数据包之间传递，那么我可能期望看到多达8个数据包几乎全部进入。我现在有两个选择：
假设选择2并且网络状况改善并且数据包传递再次变得规则（抖动值下降）。怎么办？我想我有两个选择：
使用自适应缓冲区，我认为我应该做出选择4，但这似乎并不正确，因为它要求我人为地/任意地丢弃当我遇到选择2时专门保存的音频数据包首先是更大的抖动。
在我看来，正确的行动方案是最初选择＃1以保持延迟，同时在必要时丢弃由于抖动增加而延迟发送的数据包。
类似的情况可能是，在160ms间隙之后不再获得8个数据包的突发，我只得到5个（可能只丢失了3个数据包）。在这种情况下，增加缓冲容量并没有带来任何好处，但确实可以减少以后溢出的可能性。但是如果要避免溢出的想法（从网络方面），那么我只是将缓冲容量设置为比配置的“深度/延迟”更大的固定量。换句话说，如果溢出不是由于本地应用程序未能及时从缓冲区中获取数据包而引起的，那么溢出只会出现两个原因：发送方是否以比协议更快的速率发送数据包。 （或者从未来发送数据包），或者，数据包突发之间的差距超过了我的缓冲区深度。
显然，'自适应'缓冲区的重点是识别后一种情况，增加缓冲区容量，并避免丢弃任何数据包。但是这让我理解了所述的问题：当网络抖动清除时，我如何“适应”回到理想的设置，同时仍然执行相同的'drop no packets'理念？
思想？
答案 0 :(得分：1)
通过压缩扩展。 当抖动清除时，您合并数据包并加速＆＃39;缓冲区。 Merge offcourse需要适当的处理，但想法是从ajb弹出2个20ms的数据包并创建一个30ms的数据包。你一直这样做，直到你的缓冲水平正常。
同样对于欠载，数据包可以被拉伸＆＃39;除了引入延迟。