webrtc音频QOS方法一(NetEQ之音频缓存延时BufferLevelFilter计算)

一、整体思路

上一篇《NetEQ之音频延时DelayManager计算》介绍了如何计算音频报文的网络延时,给系统需要缓存多长时间的音频数据,提供了数据支撑。webrtc会根据当前系统已经缓存包数和网络延时情况,决定给音频解码器发送播放方式,进行平滑处理。下面来介绍计算系统已经缓存包数的方法。

二、实现原理

1)计算公式

系统已经缓存包数有三块组成:1、RTP数据包缓存;2、音频解码后PCM数据缓存包数(解码后数据尚未进行音频渲染);3、对音频数据进行stretched包数。获取这三块数据后,使用如下公式计算系统音频缓存包数。

                        filtered current level = f * filtered current level + ( 1 - f ) * buffer size packets

  1. filtered_current_level:平滑后系统缓存包数。单位是报文个数。
  2. buffersizepackets:当前系统缓存包数。单位是报文个数。
  3. f:遗忘因子。根据《NetEQ之音频延时DelayManager计算》计算的网络延时动态调整。

2)代码实现

  • BufferLevelFilter::Update

        filtered_current_level_变量计算的核心函数。这里可以看出filtered_current_level还需要根据time_stretched_samples参数进行微调。因为之前对音频数据进行快进或者快退,播放时间不完全等于缓存时间。

       time_stretched_samples表示加速或减速播放后数据长度的伸缩变化。若为加速,time_stretched_samples为正值,filtered_current_level减小;若为减速,time_stretched_samples为负值,filtered_current_level变大。这体现了抖动消除技术的核心思想,即通过加速减速来实现自适应抖动缓冲区的物理设计。并且次处的filtered_current_level不会长期持续减速或者减速,确保音频质量的舒适度。

  • BufferLevelFilter::SetTargetBufferLevel

        使用《NetEQ之音频延时DelayManager计算》计算的网络延时target_buffer_level,动态调整遗忘因子系数。

  • DecisionLogic::GetDecision

       计算系统当前实际音频缓存包数,可以看出这里计算了RTP报文、PCM数据、stretched三大块

  • DecisionLogicNormal::ExpectedPacketAvailable

         最后,根据网络延时、系统缓存包数及上一帧的处理方式,决定当前解码器的处理方式。

三、附录

NetEqImpl类里面使用SyncBuffer类,整理该类结构定义如下,便于后续代码走读。

四、参考

《WebRTC语音引擎中NetEQ技术的研究_吴江锐》

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值