质量服务(QOS/Quality of Service)是指利用各种技术方案提高网络通信质量的技术,网络通信质量需要解决下面两个问题:
拥塞控制是各种技术方案的数据基础,丢包恢复解决丢包问题,抗乱序抖动解决网络乱序抖动问题,流量控制解决平滑发送数据/数据超带宽负载/延时问题。
实现算法:基于发送端的带宽估算算法(Sender Side BWE)
实现模块:YangTwcc/YangAckEstimate/YangSendEstimate/YangBandWidth等模块
经过多年实践证明基于发送端的带宽估算优于基于接收端的带宽估算,metaRTC选用基于发送端的带宽估算算法。在发送端依靠丢包、延迟、抖动等网络参数来预估当前的带宽。
实现模块:YangNack/YangFec/YangProtection/YangPLC/YangRtcp等模块
Nack作用是丢包重传,谷歌libwebrtc因有等待发送和网络等延时导致重传时间为1.5RTT+10或20ms,metaRTC为收到及发送重传时间不超过1.0RTT+5,当RTT较大网络延迟大的时候Nack还会多次发送同一包,效率较低,就不适合使用了。
Fec是通过冗余数据解决丢包,webRTC采用了ULP Fec/FLex Fec/In-bind Fec,在高延迟网络传输时有较大优势。
In-bind Fec是opus编码器自带的,ULP Fec只支持VP系列视频编码,不支持H264/H265等视频编码,Flex Fec支持H264/H265等编码,metaRTC选用Flex Fec为Fec技术方案。
Flex Fec标准参考RFC 8627 - RTP Payload Format for Flexible Forward Error Correction (FEC)
Flex Fec有三种保护策略
metaRTC实现了上面三种保护策略,谷歌libwebrtc只支持1D列异或 FEC(1-D Interleaved (Column) FEC Protection),为兼容chrome内核浏览器metaRTC只启用1D列异或 FEC。
Flex Fec 最新版本是scheme 20,谷歌libwebrtc默认支持的是scheme 03,从scheme 04起fec的rtp包格式发生了变化,metaRTC既支持谷歌默认支持的scheme 03,也支持最新的scheme 20,为兼容chrome内核浏览器只启用scheme 03版本。
关键帧请求PLI(Picture Loss Indication)是发送方重传I帧的一种技术方案,是在Nack/Fec恢复视频包失败情况下最有效的一种补救措施。
丢包补偿PLC(Packet Loss Concealment)是对丢包进行丢包补偿以便隐藏丢失包而使人不察觉的音频帧恢复的技术方案,是在Nack和Fec都恢复音频包失败情况下的最有效的一种补救措施。
实现模块:YangJitter/YangNetEQ等模块
由于网络传输延迟和不可预测的网络抖动,会导致数据包在拉流端的播放速度不一致,从而影响音视频质量和连续性,JitterBuffer是保障音视频乱序抖动最有效技术方案,NetEQ是保障音频播放质量的最有效技术方案。
实现模块:YangPacer/YangCodec等模块
流量控制是解决网络拥塞和延时最有效的技术解决方案,Pacer和编码控制流量控制最重要的两个模块,Pacer模块解决平滑发送问题但会增加延时,编码控制可以降低流量和延时。
Pacer是按照带宽可以承载的码率在各个时间片均匀的发送出去,解决平滑发送问题。由于I帧/P帧/B帧之间数据大小差异非常大,发送时网络波动非常大,会增大丢包率,尤其是wifi网络,wifi网络机制下能否平滑发送对丢包的影响非常大。
编码控制是动态调整帧率/码率/分辨率以及大小流只能适配等策略降低码流,使发送数据量在带宽负载范围内,这是降低延时和丢包最有效的技术方案。