云端使用原生 pipeline 进行视频合成

在讨论开始之前，需要明白一个问题——为什么 WebRTC 中记录流和推流是困难的？这是由于 WebRTC 的特性所决定的，那么当要记录视频流时，首要的问题是记录哪一个参与者的视角？在推流时，需要在何时何地对不同参与者的流进行处理？来自 Daily 公司的 Pauli Ojala 介绍了其团队使用云端原生 pipeline 进行视频合成。

来源：Kranky Geek WebRTC Fall 2022
内容整理：彭峰
Kranky Geek 是一个关于如何使用 WebRTC 构建实时通信应用的免费开发者大会，成立七年以来，该大会致力于帮助开发者将实时音视频纳入应用。本文介绍 Kranky Geek WebRTC 2022 秋季大会的第7节内容。

对于如何记录流，可以选择的方案有三种。假设一个 WebRTC 通话中有三个参与者，为了记录这一通话中的流（主要为视频流），那么第一方案如图 1 所示，即记录某一个参与者的视图，并且使用该参与者的设备完成编码并发送到服务器。第二个方案是假设有一个服务器作为参与者，其只接收其他参与者的流，完成渲染后编码记录保存，即在云端完成视频的合成。第三个方案为将每一个参与者的流单独保存，在后期进行后处理。这三个方案的主要区别在于是在服务器保存还是用户的客户端以及是实时处理还是后处理。如何选取方案的主要考虑在以下几个方面：

视觉设计的灵活性
规模性或者稳定性
兼容性
即时性
开销

综合考虑来说，在云端进行视频合成通常是最适合的解决方案，其典型的好处有：

不会对用户的设备造成额外的计算开销
软件层面的优越性，不依赖用户的操作系统、浏览器、视频设备等
带宽可用和稳定连接，记录的视频流可以直接传输到数据中心，并且该无需后处理，目前 Daily 上支持超过 10,000+ 的用户同时参与同一个通话，每个参与者的视角均可被记录。

为了在云端实现视频合成，可行的一个解决方案是如图 4 所示在服务器运行一个 web 服务，例如一个 Chromium 实例，然后编码其实时的输出。这种方案的问题主要体现在三个方面：

开销
- GPU 服务器并不适合这类工作
- 使用如此昂贵的以机器学习和 AI 为导向的 GPU 作为硬件是浪费的
复杂的协议，需要 X11、Nvidia 的相关驱动等
无法实现规模化

相比运行 web 实例，使用原生的 pipeline 在服务端进行视频合成的好处有：

YUV 的 CPU 渲染是可扩展的，并且很容易理解，当然也不用重现最花哨的浏览器功能(着色器，CSS效果等)
可以使用熟悉的操作系统和好用的服务器实例
可以利用流行的开源软件如 FFMPEG 和 Gstreamer 当然，没有浏览器，无法加载现有的 web 应用程序，那么如何在服务器上驱动视频合成呢?选项一为发送命令直接重新配置媒体管，例如脚本 FFMPEG/ Gstreamer，其缺点为带来用户 API 和后端实现之间不必要的硬耦合。选项二为使用有声明式抽象层的自定义引擎，例如 “Layers + Scenes over JSON” 的形式。选项三为在服务器端运行编写好的脚本。不管采取何种方案，一个合理的视频合成方案需要实现以下目标：
开发者友好
普适性，即相同代码可以在服务端和客户端都能运行
尽可能轻量化
沙盒化设计

2019 到 2021 年期间在 Facebook 设计的 React Media 是演讲者在云端视频合成上的第一个尝试，该项目为了实现快速视频合成重构了组件和调整了引擎，但其并非开源。来到 Daily 之后，演讲者参与了 VCS(video component system)的设计，其是基于 React Media 并且开源的。VCS 驱动了 Gstreamer 媒体管道，视频保持在 YUV 格式上，2D 图形保持在高质量的 RGBA 格式上，从而避免开销巨大的格式转换。

VCS 的设计有着许多优点，例如用户可以自定义界面的形式，其流程如图 5 所示，WebRTC + VCS 的架构在交互式是实时应用中具有很大的应用价值，如图 6 所示，可以利用 VCS 将不同用户的视角进行实时推流。