信道QoS

信道的保障即网络传输的保障。音视频实验室互动直播SDK从几个方面对音视频码流进行保护。

首先是信道码流的FEC（前向纠错），它包括普通的逻辑运算FEC和RS码FEC（RS码原理请问度娘谷哥）：

FEC抗丢包能力和冗余率成正比：冗余越高，抗性越好。它的优点是延迟低（单帧内FEC引入的延迟可以忽略），但它的最大缺点是需要占用网络带宽，这样会导致音视频编码的有效码率的降低，从而导致音视频质量的下降。

因此UDT协议引入了丢包重传技术。在上行和下行端，SDK会通过探测算法，实时监测网络情况，根据当前网络的上行、下行的延迟、抖动、丢包和可用带宽等情况，自适应地调制重传BUF大小、重传延迟、重传次数、重传间隔、一次重传包数等。下行端还加入了智能jitterbuf，根据网络的丢包和抖动情况，它能够自动调整抗抖能力和延迟大小，从多方面保证最优的重传效率，减少无效的重传，避免带宽的浪费。

其次，音频还有PLC机制，通过前后帧插值、复制pitch、带内冗余编码参数、基于混响滤波器等手段，在解码端进行纠错。

信源QoS

信源QoS保障机制主要应用于视频中。我们知道，视频的端到端传输需要经过采集-前处理-编码-传输-解码-显示，其中关键点在于发送端的编码和接收端的解码。

视频的编码是把一帧一帧的采集图像数据用一定的压缩算法压缩为比原来小几百几千倍的码流。在编码压缩图像帧时，需要用到空间上的邻域参考和时间上的前后域参考关系。如果被参考的数据丢失或者损坏，那么参考了这些数据的图像帧在解码端就无法解码，视频就会出现卡顿、花屏等现象，导致用户体验很差。

在视频的H264/H265编码中，一般的帧类型有I帧、P帧、B帧（各种帧类型的详细情况请问度娘谷哥，参考H264/H265协议）。I帧是帧内自参考、P帧是帧间前向参考、B帧可以前向后向参考。一帧I帧和若干帧P帧或B帧，组成了一个编码GOP。解码器解码一组GOP，必须先解码出为首的I帧。

实时视频通讯一般采用IPPPPPP的GOP模式。

原因：B帧有后向参考，需要等待后面的帧到来才能解码，这样会引入延时；I帧也不能刷太频繁，因为I帧码率大、占带宽，且容易出现图像发虚现象。

小科普：
I帧一般质量较好，P帧质量相对较差。I帧过密时，会察觉到I帧和P帧替换时的图像质量的明显差异，这种现象又叫做呼吸效应。

网络良好的实时视频会议，一般采用GOP无限大的模式。但该模式有个缺点：如果其中某一帧因为丢包或其他原因导致有损，那么同一个GOP内它后面所有的帧都无法解码。所以该模式下每一帧都同样重要，做QoS保护时也需要同等对待。由于该模式过分依赖信道QoS的保护，导致QoS机制的灵活性不够、网络适应性不好。

鉴于此，我们利用H264/H265编码的多参考帧机制，对编码GOP模式进行了针对性的优化，使得视频帧的抗网络丢包能力大大提高，同时有利于对不同的帧类型划分不同的重要程度，以此来进行不对等的信道抗丢包保护。

流控QoS

音视频实验室互动直播SDK还在流控层面上保证音视频的质量，客户端分析统计当前接收和发送的媒体流信息和网络状态，上报给流控服务器，流控服务器根据当前上行和下行的网络状态（丢包大小、抖动大小、延迟大小、可用带宽大小等）自动调节当前编码和传输参数，比如配置合适的编码帧率、码率、分辨率、GOP类型、GOP大小、编码QP等等；配置合适的UDT重传参数和延迟参数；配置合适的FEC参数（冗余率、FEC方法、分组策略等），从多方面避免网络丢包和拥塞恶化，主动调节网络的带宽负担。

需要强调的是，上述三个层面的QoS机制并不是独立运行的，而是通过流控服务器和客户端的交互有机地结合在一起，形成一个统一的音视频媒体QoS保障机制。

比如，流控服务器根据网络状态，配置编码的各种参数的同时，会配置当前的抗丢包方式，可能只用信道保护或者信源保护，也可能信道和信源同时使用；也可能根据不同的帧类型和不同的GOP类型对视频帧使用不同的FEC方法、不同的FEC冗余率；客户端也会根据当前接收到的码流情况，来决定当前丢包用丢包重传，还是用FEC恢复；可能还会配置当前是否需要主动FEC等等。三个层面的QoS是个比较复杂的关系。

通过三层QoS机制，音视频实验室互动直播SDK能够获得高达65%的下行丢包、35%的上行丢包的网络抗性。

本文转载自腾讯多媒体实验室公众号。
原文链接：https://mp.weixin.qq.com/s/BmLeVbM5wsZUKVcCH1skbw

创作场景

高网络抗性技术与低延迟连麦技术