RTC实时通信提高音质方法QOS(一)

类似于webrtc这种基于IP网络实时通信中音质好坏受多方面因素的影响,一类为回声,噪声抑制等必须解决的问题,否则无法实现双向通话,另一类是网络丢包延迟等导致的音质变差。本文主要讨论第二类情况。

由于弱网引起的语音通话质量差通常是丢包,乱序,延迟等因素导致,针对这几种情况需要引入自适应 jitter buffer, PLC(丢包补偿),FEC(丢包恢复),NACK(重传)技术。

1.jitter buffer

jitter buffer 自适应抖动缓冲是实时音频通信中处理乱序,延迟,平滑播放的基础,一个好的jiiter buffer实现会基于网络延迟抖动情况自适应缓存大小,能在网络环境好的情况下延迟降到最低,也能在网络情况差的情况下实现平滑播放,这部分已知的实现有speex 开源的jitter buffer,不过效果一般,webrtc里的neteq 是已知开源里实现最好的,可以参考,如果单独拿neteq出来使用还是有一定工作量,因为里面融合了解码,重传,red,dtmf等内容。

 

2.PLC

plc是在丢包无法恢复情况下的一种语音补偿技术,有的语音编码内置了plc,比如opus,在丢包情况下,如果没有fec包的情况下,调用opus解码器,传空数据即可产生plc补偿包。如果codec不支持plc,则需要通过plc算法实现,这部分在webrtc 的neteq里也有实现。

 

3.FEC

前项纠错技术在视频丢包恢复里用的比较多,包括in-band fec和outband fec, inband fec是指codec 内部支持的fec机制,silk, opus这种语音编码内置支持,不过opus的fec只支持前一个包的fec 恢复,实测 opus 的fec在 30%以内效果还好,如果丢包率更高,需要配合其他技术,下面会说。

ouband fec是指codec无关的算法,其基本原理是发送端对原始数据包进行 FEC 编码,生成冗余数据包,接收端收到后,通过冗余数据包和原始数据包来恢复出丢失或者出错的数据包。这种方式的好处是能根据丢包率调节冗余包个数,快速恢复丢失的数据包,不过由于要等待冗余包,则需要引入额外的延迟,实际应用当中需要动态实现fec冗余度的计算。

4.rfc 2198

 这个是rfc 是RTP Payload for Redundant Audio Data,这个rfc 定义了当前语音包可用于承载前面的几个包的语音数据,这个设计的好处能处理大量丢包的情况,小鱼易联的方式采用了这种方式。

5.重传

NACK重传技术是接收端检测到丢包后请求发送端重发的机制,这种做法实际当中用的很少,重传需要多个RTT 时间才能收到丢失的包,引入了延迟,不适合实时通话。

6.重复发送

 这是一种在丢包率高,带宽又够用情况下的一种粗暴方式,好处是能处理连续丢包情况,坏处是浪费额外带宽。

总结:实际当中需要上面多个方案的组合,在不同丢包率情况下用不同方法,实际当中,使用outband fec/rfc 2198 其一,再结合codec内置的fec 和plc可处理80%丢包率。

 

 

 

 

 

你可能感兴趣的:(WebRTC)