Meta 在 RTC 领域取得的进展 | RTC of scale 2023

背景

非常激动能在此介绍 meta 在 RTC 领域取得的进展。在过去的一年刚刚经历了疫情，那时候没有人知道 RTC 在后疫情时代将会如何发展。而现在，我们有了一年的后疫情时期的数据，RTC领域的进展将由此产生。在 Messenger 上每天全球有三亿视频通话，如果加入 Instagram 和 WhatsApp 这一数据会更高。我们在 Meta 的目标一直是将彼此分离的人们带到一起。我们在 RTC 平台的投资在实现这一目标的过程中起到了重要作用。所以，如何将人们聚到一起，要让哪些人在RTC平台获得更好的体验？在过去的一年里，我们尝试让视频通话中的参与者在通话过程中能一起做一些事情来让通话更加充实，并且在2022年，我们实现了这一功能。我们还添加了屏幕共享和白板功能在我们的App里，所以人们可以远距离合作创作。我们还了解到，人们希望在通话中分享自己现在正在做的事情，我们上线了一些实时AR互动功能来实现这一点。

传统的RTC是由移动端的一对一和小组通话贡献主要体量。在2022年，我们将通话群组突破到32人。我们对未来的发展持积极态度，我们的技术将在未来支持更大群组的通话。我们还致力于将通话带到移动端之外的设备，我们更新了Messenger在MAc和Windows的桌面app。

Meta 在 RTC 领域取得的进展 | RTC of scale 2023 — 图1

Mac 端的 APP 目前支持更快速的多人通话。这提升了人们在生活中的通话体验，你可以在每页看到25个人，意味着你可以一次通话看到所有你想见到的人。共享、白板等功能都可以在通话中实现。现在我们致力于在元宇宙中将这些功能在3D世界中实现。所有的这些功能的投入使得2022年成为了Meta视频通话量最大的一年。

这一切是如何做到的，实现这些的技术是什么，我们是如何构建的？让我们来看一下技术概述。

技术概述

首先也是最重要的，我们建立在 web RTC 之上，并致力于 web RTC 生态系统。我们有自己的信令协议实现、媒体状态机和名为 RSYS 的客户端库，它为客户端应用程序集成 RTC 功能提供了一个干净的 SDK。这个名为 Meta RTC 的单一技术堆栈为公司的多个应用程序提供支持。Messenger, Instagram, Facebook, Workplace和元宇宙应用利用了这个 RTC 的统一堆栈。这里有一些统一堆栈的优点。

修复和优化渗透到构建在堆栈上的所有应用程序
它能提高开发效率。研发工程师不需要理解RTC堆栈点细节，他们可以有一个干净的API用于工作。他们无需担心示例的生态取消和代码检查优化。
它同样能提高操作效率。在Meta Scale运行一个RTC后台程序是复杂并且需要在每层堆栈优化的，从网络流到媒体再到整体容量管理，并且需要针对例如世界杯决赛和新年夜等高流量活动进行扩展。

RSYS

现在让我们深入了解一下RSYS。RSYS是我们起源于 Messenger的客户端库,为 Messenger 产品工程师提供干净的实例。最近几年，我们重写并优化了这个库，让他足够小可以在 rayband 智能类上运行，同时足够强大，可以支持我们桌面应用程序的大屏幕体验。使用C++语言写成，这个库支持跨平台，能在IOS、Android、macOS和Windows上运行。RSYS支持插件运行。整个库安装后不到10M。现在，RSYS支持了除WhatsApp外的所有Meta RTC 应用和设备。

现在让我们来看看去年的技术发展。在RSYS基础上，我们对优化进行了多项改进，以在智能手表、AR 眼镜和 Facebook Light 等应用程序上实现 RTC 体验，这些应用场景的 CPU、内存和二进制大小非常有限。此外，我们还提供虚拟化身共同观看和共同游戏等沉浸式体验。

这个坚实的基础将使我们能够引导丰富的经验，为跨多种形式的虚拟宇宙提供动力：网页、移动端、VR和AR之间。

大型通话

接下来，我们讲一下扩展到大型通话。网络状况波动、网络拥塞、设备资源使用情况都是已知的呼叫问题。但真正的挑战来自于试图大规模解决这个问题。扩展到大型通话不仅意味着推送更多视频和音频流，从而导致更高的带宽使用量，还会影响客户端站点处理，因为必须对这些视频流进行解码和渲染。此外，在客户端通过视频进行渲染时，用户体验必须流畅。在WhatsApp，每个通话都是端到端的，意味着像视频流的服务器端渲染和音频流的服务器端混合这样的技巧不起作用。meta 只能将这些音频和视频流路由到我们的基础设施,编码解码上采样和下采样全部由客户端完成。此外，我们的很大一部分用户仅使用移动设备，并且网络有限，这使得这成为一项有趣且具有挑战性的工作。我们必须从客户端到边缘进行堆叠，以支持我们的应用程序系列中的大量调用。例如，我们对音频流引入选择性转发和主扬声器优化，仅发送可带来最佳通话体验的音频流，并避免发送其余音频流以节省带宽。我们还投资于联播、时间分层和带宽估计器优化，以优化一系列可用用户带宽的视频质量体验。作为最后的手段，我们依靠客户端有选择地关闭最不重要的视频流，以便主要发言者始终能够在通话中显示。我们还调整了应用程序的用户体验，以更好地告知用户网络限制以及他们可以采取的措施来改善他们的体验。

服务可靠性

除了大规模呼叫的扩展之外，今年我们还投入巨资提高服务的整体可靠性。

在 Meta Scale 运营中，重要的是不仅要查看对我们的服务有良好体验的用户百分比，还要减少有不良体验的用户百分比。如果某一天 10% 的通话会话出现故障，则意味着数以千万计的用户当天将获得糟糕的体验。我们通过引入复合指标应用名称百分比来解决此问题，该指标可以端到端跟踪不良用户体验。这个单一指标涵盖了呼叫连接失败、最后一刻质量回归、网络中断、媒体流问题和应用程序崩溃等内容，每个指标都根据它们造成不良用户体验的程度进行加权。通过专注于单一综合指标，我们能够衡量并改善过去 6 个月内不良的用户体验。我们发布了修复程序，解决了连接故障、网络丢失、媒体流问题和崩溃问题，全球不良指标百分比改善了 7%，美国改善了 19.6%，使音频和视频通话对于遭受最严重影响的用户来说更加可靠。

客户端

最后让我们谈谈我们的客户端，任何 RTC 客户端最重要的一个方面是呼叫阶段，而阶段的主要功能是呼叫参与者的网格。

您希望在通话中看到所有朋友，它不仅需要根据纵横比以及参与者加入和离开通话来动态调整大小。它必须具有高性能，并避免可能因拉伸和溢出视频流而产生的 GPU 缓冲区副本。为了解决这个问题，我们创建了一个与平台无关的单一调用网格实现，并且可以从移动电话扩展到大屏幕显示器。我们使用C++实现并且集成到了所有平台。我们还利用 Web Assembly 来避免为 Web 创建自定义 Javascript 实现而的导致性能和代码重用问题。