关于服务器:WebRTC-音频抗弱网技术上

46次阅读

共计 8726 个字符，预计需要花费 22 分钟才能阅读完成。

人均社恐，钟爱语聊。以语聊房为代表的语音社交产品解锁陌生人社交新形式，也一直讲述着新的出圈故事。关注【融云寰球互联网通信云】理解更多

而声音卡顿、断断续续、快进、慢放等景象会重大影响用户体验，间接导致用户来到，这些都是弱网引起的常见问题。
本文次要从音频利用的角度来剖析罕用的弱网反抗技术，次要有如下几种：

  • 前向纠错技术（FEC、RED 等）
  • 后向纠错技术（ARQ、PLC 等）
  • 编码器抗弱网个性（本文重点关注 OPUS 编码器的个性）
  • 抗抖动技术（JitterBuffer）

咱们将用上、下两篇文章，联合 WebRTC 中应用或反对的音频抗弱网技术，对以上几类技术做剖析，以实现音频通信服务在弱网环境下高可用。

上篇次要分享前向纠错技术、后向纠错技术及 OPUS 编解码抗弱网个性；下篇专题分享 WebRTC 应用的抗抖动模块 NetEQ。

前向纠错技术

FEC

前向纠错技术，最典型的就是 FEC 技术了。
发送端：生成冗余包来反抗传输过程中丢包的问题；
接收端：对收到的冗余包和失常包来从新复原传输过程中失落的包。

FEC 分带内和带外两种，WebRTC 中视频是通过带外 FEC（ULPFEC[1]、FLEXFEC[2]）来产生冗余包，音频则是通过 OPUS 带内 FEC 来生成冗余包。

带内 FEC 因为会占用一部分编码码率，所以对音频的音质会有所升高。带外 FEC 不会影响音质，但会额定占用网络带宽，各有优缺点。

FEC 典型的编码方式有 XOR 和 Reed Solomon[3]。WebRTC 的带外 FEC 应用的是 XOR 编码方式（ULPFEC 和 FLEXFEC），其特点是计算量绝对少，但其抗丢包能力无限。

在 WebRTC 中，带外 FEC，不论是 ULPFEC，还是 FLEXFEC 都是依据 MASK 掩码来确定 FEC 包和被爱护的源 RTP 包的映射关系，其中定义了两种类型的掩码，RandMask 和 BurstMask，前者在随机丢包中爱护成果要好些；后者则是对突发导致间断丢包成果会好些，然而不管哪种，都有其毛病；这里以 7-4 掩码（即 7 个原始包，将生成 4 个冗余包）举例：

#define kMaskBursty7_4 \
0x38, 0x00, \
0x8a, 0x00, \
0xc4, 0x00, \
0x62, 0x00

将下面十六进制依照二进制开展如下：

包序号: S1 S2 S3 S4 S5 S6 S7
R1: 0 0 1 1 1 0 0 原始包 S3,S4,S5 被冗余包 R1 爱护
R2: 1 0 0 0 1 0 1 ==> 原始包 S1,S5,S7 被冗余包 R2 爱护
R3: 1 1 0 0 0 1 0 原始包 S1,S2,S6 被冗余包 R3 爱护
R4: 0 1 1 0 0 0 1 原始包 S2,S3,S7 被冗余包 R4 爱护

下面的掩码示意依据 S1-S7 共 7 个原始包，发送端将生成 4 个冗余包 R1-R4，其中：

R1 包爱护 S3,S4,S5 三个原始包
R2 包爱护 S1,S5,S7 三个原始包
R3 包爱护 S1,S2,S6 三个原始包
R4 包爱护 S2,S3,S7 三个原始包

从上也能够看出，每个原始包都有被冗余包爱护；当包失落了，个别能够通过冗余包和收到的原始包来进行复原，比方发送端发送了 S1-S7、R1-R4 共 11 个包，接收端收到了 S1、S3、S5、S7、R1、R2、R3、R4 共 8 个包，失落了 S2、S4、S6 三个包；则 S2、S4、S6 修复过程如下：

S2 能够被 R4、S3、S7 修复，即 S2 = R4 XOR S3 XOR S7 

S4 能够被 R1、S3、S5 修复，即 S4 = R1 XOR S3 XOR S5 

S6 能够被 R3、S1、S2 修复，即 S6 = R3 XOR S1 XOR S2

然而也有些包无奈修复，比方失落了 S1、S2、S7，则无奈复原，起因如下：

依据掩码爱护关系可知，S1 的复原能够通过 R2、S5、S7 或者 R3、S2、S6；但因为 S7 和 S2 失落，要复原 S1，须要先复原 S2 或 S7

同样，S2 能够通过 R3、S1、S6 复原，但因为 S1 失落，则须要先复原 S1 

同理，S6 能够通过 R3、S1、S2 复原，然而须要先复原 S1、S2 

所以，通过下面的剖析可知 S1、S2、S7 均⽆法复原

同理，要是失落了 S3、S5、S7，也无奈复原，这是 WebRTC 中采纳掩码来确定冗余包和原始包之间的爱护关系的技术毛病。

即对于（M 个原始包 + N 个冗余包）一组包，有小于等于 N 个包失落时，可能无奈复原失落包的状况。

Reed Solomon 编码则能够做到对于（M 个原始包 + N 个冗余包）一组包，有小于等于 N 个包失落，都能够将失落的包复原。

RS FEC 次要是应用范德蒙矩阵或者柯西矩阵来进行编解码 [4]，柯西矩阵成果比范德蒙矩阵计算量少，性能更优；但不管下面何种矩阵，它们都 具备⼀个个性就是可逆，且任意子矩阵可逆，这就保障了在失落小于等于 N 个包时，RS 能将其复原。

上面以范德蒙矩阵做简要阐明。以（7，4）为例，即 7 个原始包产生 4 个冗余包，原始包为 S1、S2、S3、S4、S5、S6、S7，冗余包为（R1、R2、R3、R4）。原始包和冗余包的关系如下：

图说

其中下面的范德蒙矩阵为 A，如下所示：

图说

单位矩阵示意如下：

图说

假如 S2、S4 两数据包失落了，则将公式 1 中的单位矩阵对应的行删除，则有如下：

图说

公式 2 左侧的矩阵记为 B，如下：

图说

依据范德蒙矩阵可逆特点, 所以 B 也是一个可逆矩阵，记为 B，则复原包过程其实次要就是求解 B’ 矩阵的过程，对公式 2 做如下推导，即可求解原始包，如下所示：

图说

即（S1、S2、S3、S4、S5、S6、S7）中任何一个包都能够通过矩阵 B’ 和收到的包进行复原。所以 RS 的爱护能力更强。

RED[5]

RED 也是前向纠错的⼀种形式，发送端通过被动发送冗余码，来在⼀定水平上抵制包在传输网络失落的问题。解码端能够通过冗余包复原失落的包，RED 的标准规范在 RFC2198 中定义，可用在视频和音频冗余包生成，WebRTC 音频在 m96 上开启了 RED 形式。

RED 的 payload 中岂但蕴含以后包，还蕴含了历史包，这样 payload 在⼀定水平上具备冗余信息，起到抗丢包的作用。

上面简要介绍下 RED 的封装格局：RED block head

0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |F| block PT | timestamp offset | block length | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  
   F: 1 表⽰以后 block 后还有其它 block, 0 表⽰以后 block 为最初⼀个 block 
   block PT: 表⽰以后 block 的 payload type 
   timestamp offset: 表⽰以后包工夫戳绝对于 rtp head 的工夫戳的偏移 
   block length: 表⽰以后 block 的⻓度，不包含以后 block header ⻓度 
  
   0 1 2 3 4 5 6 7 
   +-+-+-+-+-+-+-+-+ 
   |0| Block PT | 
   +-+-+-+-+-+-+-+-+ 
   表⽰最初⼀个 block

上面是一个 RED 包的示例：

0 1 2 3 
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |V=2|P|X| CC=0 |M| PT | sequence number of primary | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 | timestamp of primary encoding | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 | synchronization source (SSRC) identifier | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |1| block PT=7 | timestamp offset | block length | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |0| block PT=5 | | 
 +-+-+-+-+-+-+-+-+ + 
 | | 
 + LPC encoded redundant data (PT=7) + 
 | (14 bytes) | 
 + +---------------+ 
 | | | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 
 | | 
 + + 
 | | 
 + + 
 | | 
 + + 
 | DVI4 encoded primary data (PT=5) | 
 + (84 bytes, not to scale) + 
 / / 
 + + 
 | | 
 + + 
 | | 
 + +---------------+ 
 | | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

 该 rtp 包是⼀个 RED 封装，蕴含两个 block, ⼀个 block type 为 7，⼀个 block type 为 5；即该 rtp 包蕴含了两中类型的数据包。

WebRTC 中应用 RED 包来生成 audio 冗余包，其原理大抵如下：

图说

上图中，发送端除了发送以后包，还会携带之前一个包做为冗余包，当上图的 RED4 包失落，即 4,3 包丢掉时，后续的 RED5 包达到，蕴含了 5,4 包，联合之前 RED3 包（蕴含了 3, 2 包），能够复原失落的包。

后向纠错技术

ARQ

ARQ 为丢包重传技术，接收端通过向发送端申请重发失落的包来复原失落的包。

这个绝对于前向纠错技术来讲，延时偏高，在延时小的状况下，是个比拟适合的抉择。

原理如下所示：

图

数据包 3 第⼀次发送时，接收端没有收到，便向发送端发动 3 的重传申请（WebRTC 中使⽤ NACK RTCP 包），发送端收到了接管的重传申请后，则再次重发报文 3。

上面是对 WebRTC 中应用的 NACK[6] RTCP 格局的简略介绍，NACK RTCP 在 RFC4585 中有介绍，NACK 属于反馈音讯，即 Feedback Message，格局如下：

 0                  1                   2                   3 
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |V=2|P| FMT | PT | length | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | SSRC of packet sender | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | SSRC of media source | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   : Feedback Control Information (FCI) : 
   : : 
  
   Figure 3: Common Packet Format for Feedback Messages

PT 有两种大类型：‍

Name | Value | Brief Description 
 ----------+-------+------------------------------------ 
 RTPFB | 205 | Transport layer FB message 
 PSFB | 206 | Payload-specific FB message

NACK 对应的 FCI 音讯格局如下：

0                 1                   2                   3 
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| PID | BLP | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

            Figure 4: Syntax for the Generic NACK message 

NACK 的 PT=RTPFB 且 FMT=1 
PID 表⽰以后重传申请的第⼀个 seqnum 
BLP 为 16 位，代表 PID 所指的 seqnum 后间断的 16 个 seqnum 的重传申请状况, 1 表⽰以后位对应的 se qnum 失落，接收端对其进⾏了重传申请, 0 表⽰未对该位对应的 seqnum 做重传申请 
NACK 中能够携带多个 FCI 端

PLC

PLC 称之为丢包暗藏技术，位于接收端，也即解码端；解码端依据历史语音帧，对其进行信号剖析，通过线性预测系数进行 LPC 建模，来预测失落的语音帧，这项技术的可行性是基于语音的短时语音相似性。其长处是，不占用额定带宽；PLC 技术能够解决较小的丢包率（<15%）。

NetEQ 中的丢包暗藏是依据上一语音帧的线性预测系数 PLC 来建模，依据历史语音信号重建语音信号而后加载肯定的随机噪声；

间断丢包暗藏时，均应用同一个线性预测系数 LPC 重建语音信号，留神这⾥须要缩小间断重建信号间的相关性，因而丢包暗藏产生的数据包能量递加；

最初为了语音间断，须要做平滑解决。当须要进行丢包弥补时，从存储最近 70ms 的语音缓冲区中取出最新的一帧数据并计算该帧的 LPC 系数即可

WebRTC 的 NetEQ 模块和 OPUS 解码器都具备 PLC 的性能，要是 Decoder 反对 PLC，优先应用解码器的 PLC 性能，否则应用 NetEQ 的 PLC 性能，下一篇文章在介绍 NetEQ 模块时，会进行较具体阐明。

编码器 OPUS 抗弱网个性[7]

OPUS 不然而开源且无专利的编解码器, 而且相比其它编解码器来说，性能非常优越。这也是 WebRTC 音频通常应用它的起因。

上面对 OPUS 的一些个性进行阐明，这些个性在反抗弱网上都有十分大的帮忙。

⽀持全频带带宽

OPUS 反对的码率能够从窄带 6kbps 到⾼品质立体声 510kbps，上面这幅图阐明 OPUS 从窄带到高品质宽带都能笼罩，且雷同码率下，品质更高。

图说

OPUS 反对动态码率调准

能够无缝调节码高下，等同码率下，OPUS 的音效品质更高；同时在丢包状况下，当丢包率大于肯定范畴时，会将编码模式转换成为 SILK 模式，即低码率模式，以适应网络状况。

> // 设置码率接⼝，能够通过该接⼝动静调整码率 
> WebRTCOPUS_SetBitRate 
>  
> /* When FEC is enabled and there's enough packet loss, use SILK */ 
> if (st->silk_mode.useInBandFEC && st->silk_mode.packetLossPercentage > (128-vo ice_est)>>4) 
>       st->mode = MODE_SILK_ONLY;

OPUS 延时更低

OPUS 联合了两种编解码技术，SILK（用于语音）和 CELT（用于音乐），具备低提早劣势。

这对于用作低提早音频通信链路的一部分是必不可少的, OPUS 能够以就义语音品质为代价将算法提早缩小到 5 毫秒。

现有的音乐编解码器（例如 MP3、Vorbis 和 HE-AAC）具备 100 毫秒或更多的提早，而 OPUS 的提早要低得多，但在品质上与比特率相当，如下图所示：

图说

OPUS 反对带内 FEC

OPUS 反对带内 FEC 性能，在应用 FEC 后，能够依据丢包率来生成冗余包，进步音频的抗丢包能力。

OPUS 的带内 FEC 性能应用形式相似 RED 办法，即发送以后包时，会携带上一个包的内容，只不过是上一个包是应用低码率编码来产生冗余包的，相似上面的形式：

|1| | -> |2|1| -> |3|2| -> |4|3| -> |5|4| -> |6|5|

上面是 OPUS 和 FEC 相干的几个接口：


// 使能内置 FEC
WebRTCOPUS_EnableFec
// 向 OPUS 传递丢包率 
WebRTCOPUS_SetPacketLossRate 

// 依据丢包率及 useInBandFEC 来判断是否开启低码率编码，即利⽤低码率编码来上⼀帧语⾳帧，⽣成 冗余包 
st->silk_mode.LBRR_coded = decide_fec(st->silk_mode.useInBandFEC, 
             st- >silk_mode.packetLossPercentage, st->silk_mode.LBRR_coded, st->mode, &st->bandwidth, equiv_rate); 
             
// 依据是否⽀持 FEC，来调配 SILK rate 
static int compute_silk_rate_for_hybrid(int rate, int bandwidth, int frame20ms, int vbr, int fec) 


/* Low-Bitrate Redundancy (LBRR) encoding. 
Reuse all parameters but encode excitation at lower bitrate */ 
static OPUS_INLINE void silk_LBRR_encode_FLP( 
    silk_encoder_state_FLP *psEnc, /* I/O Encoder state FLP */ 
    silk_encoder_control_FLP *psEncCtrl, /* I/O Encoder control FLP */ 
    const silk_float xfw[], /* I Input signal */ 
    OPUS_int condCoding /* I The type of conditional coding used so far for this frame */ 
)

这里须要指出的是，OPUS 内置的 FEC 包只在 SILK 模式下生成，CELT 编码模式下是不生成冗余包的。

if (st->mode == MODE_CELT_ONLY) 
   redundancy = 0; 

 if (redundancy) 
 {redundancy_bytes = compute_redundancy_bytes(max_data_bytes, st- >bitrate_bps, frame_rate, st->stream_channels); 
     if (redundancy_bytes == 0) 
        redundancy = 0; 
 }

WebRTC 中 FEC 的性能开启是通过 SDP 协商来实现的，如下所示：

a=rtpmap:111 OPUS/48000/2 
a=fmtp:111 minptime=10;useinbandfec=1

下图是 OPUS 开启 FEC 和没开启 FEC 的成果比照图 [8]

图说

从图中能够看出，FEC 开启后，在 20% 丢包状况下，音频 MOS 值晋升还是非常明显的。

OPUS 解码端反对 PLC

OPUS 解码端反对丢包暗藏，其原理是依据语音信号具备短时相似性的特点，利用上一帧失常或复原的语音信号，对其进行信号剖析，重建和预测以后失落的语音帧。

int WebRTCOPUS_Decode(OPUSDecInst* inst, const uint8_t* encoded, 
                      size_t encoded_bytes, int16_t* decoded, 
                      int16_t* audio_type) { 
  int decoded_samples; 

  if (encoded_bytes == 0) {*audio_type = DetermineAudioType(inst, encoded_bytes); 
    decoded_samples = WebRTCOPUS_DecodePlc(inst, decoded, 1); 
  } else {...}

OPUS 语音性能反对 DTX

当不是音乐模式时，即在 VoIP 模式下，当检测到某个工夫期间内没有说话声时，为了节俭带宽，能够将开启 DTX。

这个时候，在没有检测到通话声音时，OPUS 会定期 400ms 发送静音包，达到升高带宽的目标，WebRTC 默认没有开启这个个性，要开启 DTX，只须要 SDP 协商时，在 a=ftmp 这一行中退出 usedtx=1 即可开启。

WebRTCOPUS_EnableDtx  
WebRTCOPUS_

OPUS 本⾝具备很多抗弱网的个性，这些个性再配合丢包重传，能够使音频具备很强的抗弱网能力。

本文次要结合实际弱网解决工作教训，从前向纠错、后向纠错及 OPUS 编码器自身个性等方面，对音频弱网一些罕用技术做简要阐明和总结。

弱网解决还有一个要害的抗抖动技术，将在该系列的下一篇文章中具体介绍。

参考资料：

[1]: https://datatracker.ietf.org/doc/html/rfc5109

[2]: https://datatracker.ietf.org/doc/html/draft-ietf-payload-flexible-fec-scheme-03

[3]:‍https://tex2e.github.io/rfctranslater/html/rfc5510.html‍

[4]:https://www.scirp.org/pdf/6-2.16.pdf

[5]:https://datatracker.ietf.org/doc/html/rfc2198

[6]https://tex2e.github.io/rfc-translater/html/rfc4585.html

[7]:https://ja.wikipedia.org/wiki/OPUS_(%E9%9F%B3%E5%A3%B0%E5%9C%A7%E7%B8%AE)

[8]:https://www.OPUScodec.org/static/presentations/OPUS_voice_aes135.pdf

正文完
服务器
发表至： 服务器
2022-07-06
 0
关于服务器:及时规避企业钓鱼短信邮件网络钓鱼诈骗有助于企业正常运营
关于服务器:高防云服务器服务器的价值会随着时间而扩展从成本效率扩展到新服务和技术
关于服务器:云服务器在网络安全方面你的五项操作措施
关于服务器:远程集群开发环境