RTC @scale 2024 | 提升实时通信的视频质量

来源：https://atscaleconference.com/videos/improving-video-quality-for-rtc/ 题目：IMPROVING VIDEO QUALITY FOR RTC 演讲者：SHYAM SADHWANI 内容整理：王寒

简介

我（SHYAM SADHWANI）是meta的一名软件工程师，我和亿万用户一样使用视频通话app与家人朋友保持联系，音视频质量在这一场景中非常重要。我有一段时间非常好奇，这种视频质量为什么不如Netflix流，在我使用相同的设备和网络的情况下，我在Netflix中获得了非常高质量的流，但是在TRC通话中我认为质量应该更好。非常幸运的是我找到了视频通话app的工作，我们探索了很多该领域的挑战，并且在接下来的演讲中我将分析我们在这一过程中学到的和所做的。

首先我们来看视频质量和网络发展时间线（如图所示）。

图1

我们可以看到在过去的几十年中，视频流的质量快速发展，但是RTC却落后了。比如我的网络可以播放4K视频，但是我在实时通话时画质变差或者不流畅。下面我们分析一下。

图2

可以看到，RTC通常在移动设备上使用，这些设备大多需要电池供电，在这个前提下，实时通话app需要做很多事情：获取视频、编码视频、加密并发送到网络，同时他们还需要做解密、解码和实时渲染音视频。此外，还有其他服务在同一个网络带宽下运行。要获得不错的通话体验，所有这些都必须在低延迟（小于300ms）下完成。在电池供电的低消耗场景下做这些非常有挑战性。这些场景没有豪华的服务器处理和离线处理。除了上图展示的限制之外，我们深入挖掘了一些不易观测到的限制。这些问题的解决方案在高质量网络和低质量网络中都非常不同，在本次分享中，我们将这两种都纳入考虑范围。

图3

低质量网络环境下的高保真视频

我们从低质量网络开始，对高、低质量网络的定义如下。它取决于场景和用户的应用。

图4

接下来我们看一下在低质量网络下我们有什么选择。最直接的方法就是使用更加高效的编码，例如AV1。此外我们也关注了一些小的方面比如视频增强。如下图所示。

图5

我们认为编码时一个我们需要调研的领域。我们快速浏览一下视频编码的发展历史：

图6

下面我来解释一下为什么我们选择使用AV1编码方式作为下一步的编码器。H264甚至H265被大多数应用 使用，并且有硬件支持能使用很低的电量来实现4K，60fps实时编码，并且质量很高。但是当我们在RTC场景下比较这些编码方式，例如7fps或者180p或者200kbps编码，他们并不像软件里的编码器一样表现优秀。主要原因在于他们没有意识到RTC场景中的网络质量问题。我相信这会得到改善，但是需要依赖软件的编码，所以我们选择了AV1。下图展示了在25kbps条件下不同编码器的通话质量。

图7

可以看到AV1给出了更好的质量和更少的块效应，你可以很清晰的看到背景和人像，这在RTC场景下非常重要。此外我们还进行了系统的质量比较，如下图所示，横坐标时视频比特率，纵坐标是PSNR。

图8

数据表明AV1在几乎所有的预设场景下超过了H264。大致提供了2dB的质量提升，如果我们保持质量不变AV1节省了大约百分之三十的比特率。因此我们相信AV1是更适合RTC的选择。在进行公测的时候我们面临着一个问题，二进制大小的增长。AV1增加了600kb，这是一个很大的增长，它影响了下载和安装的体验，尤其是对低质量设备的用户而言。我们发现在量化过程中会产生10%的二进制编码，我们修复了这一问题，并且我们还和Google合作在今后的编码器中优化。我们遇到的另一个问题是电池消耗，基于我们的实验室测试数据，我们发现AV1造成大约4%的电池消耗，这是一个非常严重的问题，考虑到许多RTC通话因为人们的电量耗尽或者低电量提醒而终止。为了解决这一问题，我们将它分解成多个方面，首先是设备过滤，我们过滤了低质量电池、低质量CPU的设备。我们优化了编码器来提高CPU表现。最后一个问题是我们使用web RTC和sdp来进行编码协商，因此我们协调了许多编码器例如AV1和264，能够根据CPU和电池水平切换编码器。这甚至允许非对称的编码，一边可以发送AV1另一边可以发送264。对于缓存超过内存的情况，我们过滤了低内存的设备，当然这也是我们正在致力于解决的问题。

我们需要一个用来衡量视频质量的指标，过去的指标会因为AV1和264有不同的量化系数无法使用。PSNR是工业标准指标但是它需要参考视频，这在RTC中是不具备的。我们在探索无参考的指标但是它是源敏感的目前还不能使用。我们不得不依赖一些新的指标。我们提出了一个策略，这样我们就可以使用psnr来评价。如下图所示。

图9

具体来讲我们将视频经过scaler之后引入rate distortion，将它与编码后的视频进行比较，在我们的实验室测试中，我们发现这样处理后的PSNR已经非常接近真实情况了。在这种简单的迁移后，我们发现AV1替换264会有2dB的提升。我们最终将AV1部署在IOS和Android设备上。我们没有完全替代264，后续还会进行优化覆盖率。

高质量网络环境下的高保真视频

大部分人有很好的网络环境，例如5G和100mpbs。其定义如下图所示。

图10

我们运行了一些测试用例，我们希望在RTC场景下提供像本地录制一样质量的视频。我们发现码率3.5Mbps帧率30fps分辨率720p左右的视频能给出像本地录制一样的质量。60FPS给出了更高的质量，更丝滑，但是也面临一些挑战。1080p的视频看起来更好，尤其是在显示屏很大的时候，但是我们发现大部分情况下用户不会发现在手机上1080p和720p有什么不同。现在会有人提出疑问为什么不调整本地配置来改变编码码率、拍摄分辨率。这件事不是非常容易的，尤其是你运行百万级别数量设备的公测，并且要收集很多指标。

图11

所以在第一次迭代的过程中，我们运行测试发现了巨大的倒退，例如丢包率等（如上图所示）。并且我们发现机械化的音频和一星用户调研结果的上升。我们探索原因，我们发现视频质量的震荡是非常坏的，对大部分用户来说看到时好时坏的视频比平稳的低质量视频更糟糕。为了解决这个问题，我们必须改变带宽估计算法来建立启发式算法并且改变算法来避免震荡。

另一个问题是，在上图可以看到网络管道中更高的带宽会将网络调整、带宽估计暴露在一个更大的问题域中。如果你使用很低的带宽就不会遇到任何拥塞，如果你用高带宽会面临很多拥塞并且你的算法需要被更多的测试。我们必须实现的是ISP网络检测，虽然这并不是标准的基于延迟的评估。带宽评估是每一个app都想要明确的，他们有各自的针对不同网络和设备的个性化的实现。

另一个问题是音频质量比视频更加重要。用FEC我们能支持2倍、3倍音频复制来规避任何音频降质。我们发现在蜂窝网络，我们遇到了更多拥塞和音频降质。所以我们在蜂窝网络场景下关闭了高质量模式，而依靠基于机器学习的设备定位和HD定位，观测过去的通话记录并且能建立启发是否在通话开始的时候选择高质量模式。

图12

接下来我们进行了进一步的迭代来测试上述改进。现在我们有很多评价指标，我们收集表现指标例如CPU、电池、网络指标像是trr丢包、视频卡顿、机器人音频和视频质量分数。我们发现电池的消耗来源于拍摄帧率，大部分消耗不是由于比特率和分辨率而增长的而是来自相机拍摄帧率。因此我们不选择60fps而是继续根据电池情况选择30fps甚至更低的24fps。另一个问题在于我们发现许多设备并不能满足高质量模式的高内存需求，所以我们将这些设备过滤。

我们实现了高质量传输，但我们仍然认为有许多问题可以改进。

总结

低质量网络

图13

高质量网络

图14