alp*_*tis 5 audio networking voip audio-streaming jitter
我关心的是自适应抖动缓冲器的设计,该缓冲器随着抖动计算的增加和减少而增加和减少容量。
我认为没有理由对延迟或容量进行任何调整,除非存在缓冲区不足,然后可能会出现超出容量的传入数据包突发(假设缓冲区容量首先等于缓冲区深度/延迟)。例如,如果我接收 20 毫秒的数据包,我可能会实现一个 100 毫秒深的缓冲区,因此具有容纳 5 个数据包的容量。如果数据包之间经过 160 毫秒,那么我可能会期望看到几乎同时有多达 8 个数据包进入。此时我有两个选择:
假设选择 2,并且网络状况改善并且数据包传送再次变得正常(抖动值下降)。怎么办?再说一遍,我想我有两个选择:
使用自适应缓冲区,我认为我应该做出选择 4,但这似乎并不正确,因为它要求我人为/任意地丢弃在遇到较大抖动时选择选择 2 时专门保存的音频数据包。第一名。
在我看来,正确的做法是首先采取选择#1来维持延迟,同时丢弃数据包(如有必要),这些数据包由于抖动增加而延迟交付。
类似的情况可能是,在 160 毫秒的间隙后,我没有收到突发的 8 个数据包,而是只收到 5 个数据包(可能刚刚丢失了 3 个数据包)。在这种情况下,增加缓冲区容量并没有多大好处,但确实有助于减少以后溢出的可能性。但是,如果溢出的想法是要避免的(从网络端),那么我首先会将缓冲区容量设置为大于配置的“深度/延迟”的固定量。换句话说,如果溢出不是由于本地应用程序未能及时将数据包从缓冲区中取出而引起的,那么溢出只会因两个原因而发生:要么发送方撒谎并以比约定的速率更快的速率发送数据包(或从未来发送数据包),或者,数据包突发之间存在超出我的缓冲区深度的间隙。
显然,“自适应”缓冲区的全部意义在于识别后一种情况,增加缓冲区容量,并避免丢失任何数据包。但这让我直接面对上述问题:当网络抖动消除时,我如何“适应”回到理想设置,同时仍然执行相同的“不丢包”理念?
想法?
带压缩扩展。当抖动消除后,您可以合并数据包并“加速”缓冲区。合并当然需要适当的处理,但想法是从 ajb 中弹出 2 个 20ms 数据包并创建一个 30ms 数据包。继续这样做,直到缓冲水平恢复正常。
类似地,对于欠载运行,除了引入延迟之外,数据包还可以被“拉伸”。
归档时间: |
|
查看次数: |
2885 次 |
最近记录: |