RTC 系统音频弱网对抗技术发展与实践
网易P229

1. RTC 系统中常用的 FEC 冗余算法包括： XOR、 Reed Solomon、喷泉码等介绍一下这几种算法？

在RTC（实时通信）中，为了防止网络拥塞或数据包丢失，FEC（前向纠错）是一种广泛使用的技术，它通过添加冗余数据来确保数据正确性。下面是一些常用的FEC冗余算法的介绍：

XOR（异或）：XOR的FEC算法利用两个数据包的异或和（XOR），作为冗余数据来补充传输，这个方法简单，计算速度较快，但有限的冗余信息不能有效地纠正过多的错误。

Reed-Solomon（里德-所罗门）：Reed-Solomon是最常用的FEC算法之一, 它会创建多个冗余数据块（也称为符号），这些符号可以有效地对丢失或损坏的数据包进行纠正，它被广泛应用于音频、视频、图像等需要高保真度的数据传输。

喷泉码：喷泉码也是一种有效的FEC算法，它生成无限的冗余数据，在数据被发送之前将其喂给随机数生成器，接收方可以使用任意数量的冗余数据及其生成的随机数来恢复任意多个数据包。喷泉码因其高效和快速的计算速度而逐渐流行。

这些FEC算法在实时通信系统中非常有用，它们可以防止重复传输、优化网络延迟，确保高质量的视频、音频等数据传输。

常见的FEC冗余算法包括Reed-Solomon码、Luby Transform码和Raptor码等，它们都采用不同的方式生成冗余数据，对数据包的保护效果和编解码复杂度也有所不同。

例如，Reed-Solomon码采用的是块编码方式，可以对一定大小的数据块进行编解码处理，生成一组冗余数据，可以在一定次数的数据包丢失或错误时，通过冗余数据进行恢复。而Luby Transform码和Raptor码采用的是流编码方式，可以实时生成冗余数据，并在适当的时间点对数据包进行修复。

Reed-Solomon码、Luby Transform码和Raptor码都是一类矩阵编码方式，但它们采用的是不同的编码方式：Reed-Solomon码采用的是块编码方式，Luby Transform码和Raptor码采用的是流编码方式。二者的区别在于编码数据的组织方式和冗余信息的添加方式。

块编码方式
块编码方式，是指将数据划分属于不同的块，并且将这些块视为整体进行编码。Reed-Solomon码采用的就是块编码方式，它把数据分为多个固定大小的块，然后对每个块进行独立的编码和修复。具体来说，每个块都会被分裂成多个相等大小的符号，对这些符号进行编码的时候，会添加一定数量的纠错码，并且在发送和接收端对丢失和损坏的符号进行修复。块编码方式的优点在于编码效率高，整个块可以进行并行计算，并且冗余信息可以直接嵌入到编码后的数据块中，无需额外传输。

流编码方式
流编码方式，是指将数据视为连续的流，并且在流中穿插着冗余信息。Luby Transform码和Raptor码采用的就是流编码方式，它们将数据分割成比较小的包，并且通过添加一定数量的冗余信息，将每个包转化为一系列的冗余包。这些冗余包与原始数据包可以混合在一起被传输，并在接收端被合并以恢复原始数据。流编码方式的优点在于编码效率高，对于丢失和损坏的数据包可以进行快速修复，并且可以根据需要调整冗余信息的数量。

总的来说，块编码方式适用于固定大小的数据块，可以提供高效的编码和修复方式。流编码方式则适用于可变大小的连续数据流，可以提供更高的效率和可靠性。两种编码方式都有其优缺点，需要根据具体的应用场景进行选择。

2. 用简单的语言介绍一下带内FEC和带外FEC

带内FEC（Forward Error Correction）是在数据传输时，数据中已经携带了一定数量的冗余纠错码。这样，如果数据发生了一些错误，接收端可以在一定程度上纠正这些错误，而不需要向发送端请求重发数据。

带外FEC也是一种纠错码技术，但它不是在数据中嵌入冗余信息。而是在数据传输通道外部添加一些冗余信息，用于纠正数据传输中的错误，在接收端进行解码处理，使数据恢复完整和准确。
带内FEC和带外FEC的区别主要在于纠错码的位置不同。

带内FEC是将冗余的纠错码添加到数据本身中，也就是将额外的冗余信息添加到数据包中，因此在传输带宽有限的情况下需要分配一定的带宽来传输这部分冗余信息。

而带外FEC的纠错码则是通过在数据传输通道外部添加额外的冗余信息来实现纠错，这部分冗余信息不占用数据包的传输带宽，因此在传输带宽有限的情况下，它可以更好地利用网络资源。

另外，带内FEC一般需要更高的冗余码率，才能保证可靠地进行数据纠错，会导致传输时数据量增加。而带外FEC可以根据实际情况动态地调整纠错码率，以降低传输时数据量增加的影响。
带内FEC优势：
冗余信息直接与数据打包在一起，不需要额外的传输通道，可以比较快速地进行纠错。
对于变化较小的数据，可以预先计算冗余信息，减少传输时增加的数据量。
带内FEC劣势：
冗余码率较高，会导致传输时数据量增加，占用带宽较多。
对于高速和大量数据的传输，带内FEC可能无法及时识别和处理错误，导致丢失数据和时延增加。
带外FEC优势：
冗余码率较低，不会占用太多传输带宽。
可以更好地适应高速和大量数据的传输，减少丢包和时延。
带外FEC劣势：
在数据传输中需要另外的通道进行冗余信息传输，增加了通信的复杂度和成本。
大家通常在应用中根据具体需求选择带内FEC或带外FEC，一般来说，对于小数据量、低传输速度和网络稳定的场景，一般使用带内FEC；对于大数据量、高传输速度和不稳定网络的场景，则会更倾向于使用带外FEC。

Opus 编解码器内部支持的原生带内 FEC 在 Speech 场景下，可以处理大约 20% 以内的丢包，其原理是通过当前帧携带前一帧的缩小版压缩包信息来恢复丢失的信源。

3.什么是冗余码率？

冗余码率（Redundancy Ratio）是指在使用纠错编码时，为保证数据可靠性需要添加的冗余信息的大小与原始数据大小的比率。

例如，在进行 FEC 编码时，如果需要对数据进行 1/3 的纠错保护，那么就会在数据中添加等量的冗余信息，这时整个数据包的大小就会增加 33.3%。此时，冗余码率就是 1/3，即 33.3%。

通常来说，冗余码率的值越高，数据包的可靠性就越高，但同时也会导致传输带宽的浪费，因此需要在保证一定可靠性的前提下控制冗余码率的大小。在实际使用中，会根据数据的重要性和传输环境的可靠性来选择合适的冗余码率。
mediasoup使用的是带内FEC（Forward Error Correction，前向纠错码），它可以在数据传输过程中，通过添加冗余数据来更好地保护数据免受网络传输时的错误导致的数据包丢失。

相比于带外FEC，在网络传输质量较差的情况下，带内FEC可以更快地修复数据包丢失问题，减少数据重传的时间和带宽消耗。但是，带内FEC也会增加带宽的使用，并且需要处理一些冗余数据，因此需要在使用时进行权衡考虑。

4.mediasoup用的是什么FEC?

mediasoup使用的是FlexFEC冗余算法，它是Google提出的一种基于RTP的前向纠错方案。

FlexFEC采用的是基于Reed-Solomon码的FEC算法，其在生成冗余包时，采用了灵活的、可变的重构数据块大小的方式，可以根据网络传输的情况进行自适应调节，并可以使用不同级别的FEC数据进行传输。

与传统的FEC方案（如RFC 2733）不同，FlexFEC采用的是增量冗余，即可以在原始包中添加一定量的冗余数据，提高传输质量，同时不需要额外的冗余包头信息，节省带宽的使用。

FlexFEC广泛应用于WebRTC中，其在保证低延迟的同时，提高了视频和音频传输的稳定性和完整性。
FlexFEC（Flexible Forward Error Correction）是一种用于互联网实时通信（WebRTC）的冗余纠错算法。它旨在通过添加冗余信息来提高实时音视频传输的质量和可靠性，并避免重传（retransmission）造成的时延问题。

FlexFEC具有以下特点：

可扩展性：支持灵活的冗余纠错等级和数据包大小；

可定制化：可根据实际应用场景选择合适的纠错等级，平衡效果和性能；

高性能：无需等待任何确认信息（ACK），即可在一定程度上修复丢失的数据包。

FlexFEC的实现基于前向纠错（Forward Error Correction）的思想。它会在发送端计算出一定数量的冗余信息，并将其与原始数据一同发送给接收端。接收端则可以依据这些冗余信息对丢失的数据包进行修复，避免了重新传输的需要。

在FlexFEC中，有两个重要的参数：纠错等级和数据包大小。纠错等级决定了发送端计算冗余信息的数量，以及接收端修复丢失数据包的能力；数据包大小则决定了发送端计算冗余信息的区间大小。根据这两个参数不同的取值，可以得到不同的FlexFEC配置。

总的来说，FlexFEC算法的流程如下：

在发送端，根据当前的纠错等级和数据包大小计算出一定数量的冗余信息，将其与原始数据一同发送出去；

在接收端，如果有某个数据包丢失，则可以使用收到的冗余信息来对其进行修复。具体来说，可以使用线性插值等技术对两个冗余区间中相应区间的数据包进行计算，得到故障数据包的内容；

如果冗余信息不足以修复数据包，则需要请求发送端进行重传。其中，需要注意的是，FlexFEC并没有完全替代重传机制，而是在其基础上增加了一定的纠错能力。

总的来说，FlexFEC可以在一定程度上提高实时音视频传输的质量和可靠性，缩短重传造成的时延，并且可以根据实际应用场景选择合适的纠错等级和数据包大小，灵活性较高。

5. FlexFEC中的两个重要参数

FlexFEC中的两个重要参数，纠错等级和数据包大小，是根据实际应用场景进行设置的。它们对于冗余信息的生成和修复都有重要的影响。

纠错等级
纠错等级是FlexFEC中控制纠错信息数量的参数，它代表着发送端计算出来的冗余信息的数量。通常情况下，一个更高的纠错等级可以提供更多的冗余信息，从而提高数据包丢失时的恢复率和可靠性。但是，一个更高的纠错等级也意味着发送端需要花费更多的资源来计算冗余信息，从而会增加网络带宽和计算成本。

在实际应用场景中，纠错等级的选择需要考虑到一些重要因素，比如带宽限制、网络延迟、应用特点等等。在延迟敏感的应用场景中，较低的纠错等级可能是更好的选择，因为它们可以在更短的时间内提供更好的实时性能。

数据包大小
数据包大小是FlexFEC中用于计算冗余信息的区间大小，也可以影响冗余信息的生成和修复的效果。

通常情况下，更大的数据包大小可以提供更多的数据冗余信息，从而提高数据包丢失时的恢复率和可靠性。但是，更大的数据包也会增加丢失一个数据包所需要重传的数据量，并且在网络中传输更大的数据包可能会增加网络拥塞的风险。

在实际应用场景中，数据包大小的选择通常需要考虑到一些影响因素，比如带宽限制、网络延迟、网络拥塞等等。通常来说，较小的数据包可以提供更低的时延、更好的实时性能和更少的重传延迟，但是也可能会影响冗余信息的生成和修复的效果。因此，选择适合的数据包大小需要根据实际情况进行评估和优化。

6. RED（Redundant Audio Data）

RED（Redundant Audio Data）方式是一种VoIP（Voice over IP）网络中使用的数据冗余技术。当语音数据通过网络传输时，它们可能会丢失或出现延迟，这会导致通话质量下降。为了解决这个问题，RED会在发送端发送冗余数据并在接收端进行处理，以确保发送方发送的数据在传输过程中被还原回原始的信息。

相对于FEC（Forward Error Correction）方式，RED的好处在于它可以在不增加数据流量的情况下提供更好的语音质量。FEC通过在发送过程中添加更多冗余数据包来纠正丢失的数据包，从而确保通话质量。但是，这会导致数据流量的增加，从而影响网络性能。 RED方式只有在识别到数据包有丢失或延迟时才使用冗余数据，因此可以避免资源的浪费，同时仍然能够确保通话质量的提高。

其原理是在音频数据传输时，会增加一定量的冗余数据，一旦出现数据丢失或损坏的情况，就用冗余数据中的某些部分来重新构建丢失的音频数据，使数据继续传递下去。如果原始音频数据发送成功，冗余数据将不会使用，也就是说在没有数据丢失或损坏的情况下，RED技术不会对音频数据进行任何更改。

如果某个数据包丢失或损坏了，RED技术会通过使用冗余数据中的信息来尝试重构音频数据，以便最终恢复原始数据。而如果数据包没有丢失或者损坏，那么冗余数据将不会被使用，这样就可避免纯冗余造成的额外数据传输。

具体地，RED技术会在原始音频数据的基础上增加一个偏移量（Offset）和一个长度值（Length），这两个值指定了冗余数据的位置和长度。同时，该技术还会根据网络环境的情况进行自适应调整，对于网络拥塞情况下的冗余数据，将会被优先删除，以减少带宽的占用。

冗余数据怎么产生的

冗余数据是通过加入相同数据内容的多个副本来实现的。这些副本中的每一个副本都具有唯一ID号码，这个ID号码是针对一个固定的数据块的，所以它们一般都具有相同的长度和数据类型等特点。

上述的冗余副本，可以在发送音频数据的同一UDP数据包中，也可以在一个单独的UDP数据包中发送。一些特殊的网络环境，可能需要更多的冗余数据，可以增加副本的数量，来增加RED技术的效果。

RED 技术会根据网络带宽和拥塞状况来自适应调整冗余数据的数量和比例，以达到最佳覆盖和利用网络带宽的效果。

总的来说，RED技术在实时音频传输中有着重要的应用，它可以减少音频数据丢包和误码的情况，从而提高音频传输的可靠性。

RED（Redundant Audio Data）技术产生冗余数据的方式是在音频数据的基础上增加一定量的冗余数据，这些冗余数据可以用来在数据丢失或损坏情况下尝试恢复原始的音频数据。

冗余数据一般是通过增加相同的数据内容的多个副本来实现的。这些副本与原始数据具有相同的类型、长度和格式等特性，唯一不同的是它们拥有不同的数据包ID。这个数据包ID指定了生成冗余数据的唯一数据块，如果这个数据块丢失或损坏，冗余数据就可以用来恢复数据。

RED技术可以在发送音频数据的同一UDP数据包中或者单独的UDP数据包中产生冗余数据，具体实现方式有如下两种：

1.每个音频数据包都会对应一个冗余数据包，这些数据包和音频数据包的格式相同，但是数据比率较低。因此，在发送数据包时，同时发送一些冗余数据包，以保证出现丢包的情况时，音频数据包可以通过冗余数据包来恢复。

2.将所有的冗余数据都打包成一个单独的UDP数据包，随后发送到接收端。由于UDP数据包不会经过任何确认和处理，这会增加数据的传输延迟。因此，这种方法通常只用于较为宽油的网络中，尤其是在的系统教孩子费艾的情况下，避免产生过多的网络数据包。

冗余数据怎么传输的

需要注意的是，在利用RED技术产生的冗余数据时，需要进行合理的配置和管理，以提高网络传输效率，减少不必要的带宽占用。
RED（Redundant Audio Data）技术产生的冗余数据可以通过不同的方式进行传输，通常有以下两种方法：

1.在音频数据包中包含冗余数据：此种方法将每个音频数据包和相应的冗余数据包都封装在同一个UDP数据包中进行传输。冗余数据通常和音频数据以一定的比例混合在一起，因此在真实数据包到达之前，接收方可能需要等一段时间的冗余数据后才能开始解码。这种方式可以提高传输的可靠性，减少网络丢包，但会增加一定的数据传输延迟。

2.单独使用UDP数据包来发送冗余数据：此种方法将所有的冗余数据打包成单独的UDP数据包进行传输，即使没有音频数据需要发送，也会不断传输冗余数据包。这种方式可以减少音频数据包的块大小，减小网络丢包的可能性，但是也会加重网络带宽的负担。同时，由于UDP数据包不保证可靠性，接收方可能需要特别处理，以避免冗余数据包影响音频数据包的传输质量。

为什么RED可以提高数据包 payload 的利用率，并降低性能开销?

payload（有效载荷）是指在通信中传输的有用信息部分，它是不包括头部和尾部等控制信息的数据部分。

RED可以在网络出现拥塞之前就开始减少数据包的发送，防止了网络拥塞的发生，从而提高了网络的利用率。

RED可以在拥塞发生时随机丢弃部分数据包，这样可以使得网络中的流量得到平衡，从而降低了网络的延迟和丢包率，提高了网络性能。

RED可以根据不同的流量情况调整自己的参数，从而适应不同的网络环境，提高了网络的适应性和灵活性。

RED可以避免TCP全速发送，从而避免了网络的拥塞，从而提高了TCP的性能。

7.相比于FEC，RED有什么区别，有什么好处，请用通俗易懂的话说出来

RED主要是通过在网络拥塞前就开始减少数据包的发送，以避免网络拥塞的发生，并随机丢弃部分数据包，以平衡网络中的流量，从而降低网络的延迟和丢包率，提高网络的性能。
FEC则是在数据包传输时添加一些冗余数据，以便在数据包丢失或损坏时，可以通过冗余数据进行恢复，从而减少数据重传的次数，提高数据传输的效率和可靠性。
RED的好处是可以在网络拥塞前就开始减少数据包的发送，避免了网络拥塞的发生，从而提高了网络的利用率和性能。同时，RED可以根据不同的流量情况调整自己的参数，适应不同的网络环境，提高了网络的适应性和灵活性。
而FEC的好处是可以在一定程度上减少数据重传的次数，提高数据传输的效率和可靠性。但是，FEC需要增加冗余数据的传输，会导致网络带宽的浪费，同时对于一些延迟要求较高的应用场景，FEC的效果并不是很好。

8 PLC丢包补偿技术

PLC（Packet Loss Concealment）是一种丢包补偿技术，它可以在音频或视频数据传输中丢失数据包时，通过一定的算法对丢失的数据进行预测和估算，从而使接收端可以继续播放音频或视频数据，避免了音视频的中断和播放效果的降低。
在Opus编解码器中，PLC是一个可选项，它可以在数据包丢失时实现丢包补偿。Opus的PLC算法采用了基于时域的算法和基于频域的算法相结合的方法，通过音频信号的预测和估算，来填补数据包丢失的空白，从而实现了音频数据的连续播放。
Opus的PLC算法主要包括两种方法：基于Pitch的算法和基于Spectral的算法。基于Pitch的算法主要是通过对音频信号的周期性进行分析，来估算丢失的数据包的内容。而基于Spectral的算法主要是通过对音频信号的频域特征进行分析，来估算丢失的数据包的内容。
需要注意的是，PLC只是一种临时的丢包补偿技术，它不能完全替代丢包重传和前向纠错等技术，而且PLC的效果也受到丢失数据包的数量和丢失时机等因素的影响。因此，在实际应用中需要综合考虑PLC和其他丢包补偿技术的优缺点，选择合适的丢包补偿方案。

【音视频第2天】RTC 系统音频弱网对抗技术发展与实践相关推荐

云信技术系列课 | RTC 系统音频弱网对抗技术发展与实践
导读:本文整理自线上直播[MCtalk Live#2 :RTC 系统音频弱网对抗技术发展与实践]网易云信资深音视频引擎开发专家崔承宗分享内容,文末也可查看直播回顾视频. 文|崔承宗网易云信资深音视频 ...
LiveVideoStack线上分享第四季（三）：在线教育的音视频架构设计及弱网对抗技术...
今晚 7:30,LiveVideoStack线上分享第四季,第三期,我们邀请到了VIPKID 服务端架构师,陈劲松老师详细介绍在线教育场景下,如何搭建分布式和高可用的音视频平台,并重点分析在弱网对抗中 ...
RTC 系统音视频传输弱网对抗技术
Hi~这里是25万+社交,泛娱乐,出海开发者青睐的全球互联网通信云·融云若你对国产化,协同办公解决方案感兴趣,欢迎关注本号的[兄弟号]关注[融云 RongCloud],了解协同办公平台更多干货. 今天 ...
在线教育音视频质量评价与感知系统
为了探讨用一套客观,完备的评价系统对在线教育的音视频通信质量做出评价,力求做到定量,准确,横向可对比,并基于线上运行的大数据系统,发掘端到端通信平台存在的问题,找到优化方向,提升在线教育的用户体验,V ...
音视频开发（四）——编码音频
基于QT+FFMPEG的音视频开发(四)--编码音频一.编码一般步骤二.编码 2.1 创建编码器(本文创建AAC) 2.2 核心编码三.源码我的大部分学习都来自雷神,没有基础去雷神博客转转,每 ...
Android音视频开发，详说PCM音频重采样、PCM编码
直播伴音,两种数据能否合在一起?不能叠加在一起会有噪音合并以后再去编码推流直播的例子客户端播放器,可以开启多个播放器对于我们重采样很多时候就是为了统一格式,就是为了要合并这个流,去推送, ...
音视频开发入门基础知识（音频入门篇）
RTSP实时音视频开发实战课程:<RTSP实时音视频开发实战> 音视频开发入门基础知识(音频入门篇) 目录前言音频的采集和播放音频常见的格式音频的编码前言在音视频开发入门基础知 ...
实时音视频聊天中超低延迟架构的思考与技术实践
1.前言从直播在线上抓娃娃,不断变化的是玩法的创新,始终不变的是对超低延迟的苛求.实时架构是超低延迟的基石,如何在信源编码.信道编码和实时传输整个链条来构建实时架构?在实时架构的基础之上,如果通过优 ...
阿里云 RTC QoS 弱网对抗之变分辨率编码
简介:本文为 QoS 弱网优化系列的第二篇作者|安基程.田伟峰审校| 泰一视频编码中的变分辨率问题及解决变分辨率在弱网场景的实际应用中非常常见,网络状况不好的时候降低分辨率可以降低码率,减少块 ...

【音视频第2天】RTC 系统音频弱网对抗技术发展与实践