WebRTC 之 FEC、RED、PLC、RTX和其他缩写所起的作用

WebRTC media resilience 如何工作？什么是FEC、RED、PLC、RTX，以及为什么需要它们来提高实时通信的媒体质量。

网络本质上是挑剔的，媒体编解码器更是如此。

在网络中，并不是所有发送的东西都能在另一端收到，这意味着在处理WebRTC媒体时，我们又多了一件需要处理和关注的事情。对我们来说，幸运的是，有相当多的内置工具可供我们使用。但是，我们应该在每个点上使用哪一个，它们能带来什么好处？

这就是我在这篇文章中要重点讨论的问题。

有损网络

通信网络本质上是有损的。这意味着，如果你通过网络发送一个数据包，就不能保证该数据包到达另一方。也不能保证数据包按照你发送的顺序或及时到达，但这是另一篇文章的内容。

这就是为什么你在互联网上所做的几乎所有事情都有这种很好的重传机制，作为一种假设隐藏在内部深处。这种重传机制是TCP工作方式的一部分–就这一点而言，几乎所有其他浏览器内实现的传输协议都是如此。

这里的假设是，如果东西丢失了，你只需再次发送就可以了。接收者可能要花一点时间来接收它，但它会到达那里。如果它没有，我们可以简单地宣布该连接被切断和关闭。

我们把网络中 “有东西丢失 “的情况称为丢包，并加以衡量。

剥离这种自动假设，即网络是可靠的，你在网络上发送的一切都会被另一方收到，这是理解WebRTC的第一个重要步骤，也是理解实时传输协议及其基本概念的第一步。

媒体编解码器有损（且敏感）

媒体编解码器也是有损的，但方式不同。当一个音频编解码器或视频编解码器需要对来自麦克风或摄像机的原始输入进行编码（=压缩）时，它们所做的是将数据从它们认为不必要的东西中剥离。这些东西是原始媒体的感知质量的水平。

我记得很多年前，坐在大学的宿舍里，谈论着专辑和CD。那里的一个室友是个发烧友。他总是解释黑胶唱片的音质比CD好，而MP3只是破坏了音质。我呢，我从来没有听说过有什么区别。

不同的人对质量的感知可能是不同的。编解码器实现得越好，越多的人就不会注意到质量的下降。

回到编解码器。

大多数媒体编解码器本质上都是有损的。有一些无损的，但它们很少用于实时通信并且根本不用于 WebRTC。我们使用有损编解码器的原因是为了获得更好的压缩率：

以每秒30帧的速度拍摄1080p（全高清）视频将导致大约1.5Gbps的数据。如果不对其进行压缩–它就无法工作。我们正试图通过网络挤压大量的原始数据，而且像往常一样，需要平衡我们的需求和我们可用的资源。

要压缩更多，我们需要：

• 将我们关心的事情减少到最低限度（我们使用的编解码器的有损方面）
• 更多的 CPU 和内存来执行压缩
• 使我们最终得到的每一个比特都很重要

最后一个是媒体编解码器变得非常敏感的地方。

如果每一个比特都很重要，那么失去一个比特就很重要。如果丢失一个比特很重要，那么丢失整个数据包就更重要了。

由于网络必然会丢失数据包，我们将需要处理媒体数据包丢失的问题，而我们的系统（在解码器或其他地方）需要以某种方式填补这一空白。

WebRTC 媒体校正的类型

媒体数据包会丢失。我们的媒体解码器，或整个WebRTC系统，需要处理这一事实。这是用不同的媒体校正机制完成的。下面是对我们面前的可用选择的一个快速说明：

每一种这样的媒体矫正技术都有其优势和挑战。让我们回顾一下它们，以便更好地了解它们。

PLC：丢包隐藏

每个 WebRTC 的实施都需要一个丢包隐蔽策略。为什么？因为在某些时候，在某些情况下，你不会有你需要的数据包来播放 NOW 。由于 WebRTC 是关于实时性的，所以不能让 NOW 等待太长时间。

丢包隐藏是什么意思？这意味着，如果我们丢失了一个或多个数据包，我们需要以某种方式克服这个问题，并继续以最佳状态运行。

在我们深入研究之前，重要的是要声明：不丢失数据包总是比需要隐藏丢失的数据包更好。

这在音频和视频之间是不同的：

音频PLC

大多数情况下，音频包是逐帧解码的，通常也是逐包解码的。如果丢失了，我们可以尝试各种方法来解决。有最常见的方法：

• 什么都不播放，导致音频出现丑陋的机器人/金属色调
• 复制先前的音频帧，有时会降低其音量
• 试图预测失去的那一帧的声音是什么样的。今天，使用机器学习，也许有像谷歌专有的WaveNetEQ算法的东西

视频PLC

视频流上的数据包丢失有其自身的难题和挑战。

在视频中，大多数帧都依赖于之前的帧，从而创建依赖链：

I 帧或关键帧（根据所使用的视频编解码器而定）打破这些依赖链，然后人们可以使用像时间可扩展性这样的技术来减少对后面一些帧的依赖。

当你丢失一个数据包时，问题不仅仅是如何处理当前的视频帧以及如何显示它，而是取决于丢失数据包的帧，未来的帧会发生什么。

在过去，重点是显示被解码的每一个比特，结果是播放的视频有污点以及绿色和粉色。

今天，我们大多不显示帧，直到我们有足够干净的比特流，选择稍微冻结视频或跳过视频帧，而不是显示不够准确的内容。随着机器学习的进步，它们可能会在未来发生变化。

PLC 很棒，但是要找回丢失的数据包还有很多工作要做，而不是试图用我们现有的东西凑合。接下来，我们将看到可用的其他技术。

RTX：重传

这里有一个简单的机制（无处不在）来处理丢包——重传。

在你使用的任何协议中，确保在没有收到你应该收到的东西时，要么确认收到发给你的东西，要么确认NACKing（发送否定确认）。这样一来，发送方就可以重新传输丢失的东西，而你也可以随时得到它。

如果有足够的时间进行另一次数据往返，直到你必须回放它，那么这种方式就很有效。或者当数据可以在未来的解码中帮助你（想想视频编解码器中的跨帧依赖）。这就是为什么重传在WebRTC媒体校正中并不总是那么好用——我们处理的是实时和低延迟。

视频流中的另一种变体是要求新的 I 帧。通过这种方式，接收方可以向发送方发出信号以“重置”视频流并从头开始对其进行编码，这实质上意味着请求打破旧帧与应该在丢包后发送的新帧之间的依赖关系。

RED：冗余编码

重传意味着我们在事后克服了数据包损失。但是，如果我们可以不通过重传来解决事情呢？我们可以通过多次发送相同的数据包来做到这一点，然后就可以了。

通过用相同的信息淹没它来增加比特流的两倍或三倍，以增加整个事物的鲁棒性。

RED 正是如此。它将旧的音频帧串联到正在发送的新鲜数据包中，有效地将数据包的大小增加一倍或两倍。

如果一个数据包丢失了，它要传送的新帧将在以下应该接收的数据包之一中找到。

是的。它耗尽了我们的带宽预算，但在我们发送 1Mbps 或更多视频数据的视频通话中，将音频大小从 40kbps 增加三倍到 90kbps 可能是值得为更清晰的音频做出的牺牲。

FEC：前向纠错

冗余编码需要额外的 100% 或更多比特率。我们可以使用其他方法做得更好，通常称为前向纠错。

👉 请注意，冗余编码只是另一种前向纠错机制

使用 FEC，我们将添加更多可用于恢复丢失的其他数据包的数据包。FEC 最常见的方法是获取多个数据包，对它们进行异或运算，然后将异或运算结果作为附加数据包发送。

如果其中一个数据包丢失，我们可以使用 XORed 重新创建丢失的数据包。

还有其他的纠正算法手段，在数学上要复杂一些（如果您有兴趣，请谷歌一下Reed-Solomon ），但 WebRTC 中用于此目的的方法是 XOR。

FEC 仍然是一件昂贵的事情，因为它大大增加了比特率。这就是为什么它很少使用的原因：

• 当你知道网络上会有数据包丢失时
• 仅保护许多其他帧将依赖的重要视频帧

理解 WebRTC 媒体校正

PLC、RTX、FEC、RED、……

每个人如何通过网络发出信号？什么时候使用它才有意义？WebRTC 如何在浏览器中实现它，你到底能从它身上得到什么？

所有这些大多是神秘的知识。似乎是在一代又一代的WebRTC开发者之间传递的东西。

原文：https://bloggeek.me/webrtc-media-resilience/