WebRTC 录制挑战和解决方案

您的应用程序需要 WebRTC 录制功能吗？了解实施 WebRTC 时的各种要求和架构决策。

作者：Tsahi Levent-Levi
译自：https://bloggeek.me/webrtc-recording/

许多 WebRTC 应用程序的一个关键部分是会话记录功能。这可能是对可选功能的要求，也可能是应用程序的主要重点。

无论出于什么原因，WebRTC 录制都有不同的形式和规模，如今也有很多替代方案。

这次我要做的是回顾与 WebRTC 录制相关的几个方面，以确保在实施时，您能在自己的详细需求和设计中做出更好的选择。

录制并上传或上传并录制

您需要考虑的一个基本问题是，您计划在哪里进行 WebRTC 录制——在设备上还是在服务器上。您可以在设备上录制媒体，然后（选择性地）将其上传到服务器。或者将媒体上传到服务器（在 WebRTC 会话中实时进行），然后在服务器上进行录制操作。

本地录制使用 MediaRecorder API，上传使用 HTTPS 或 WebSocket。服务器上的录制使用 WebRTC 对等连接，然后使用任何媒体服务器在服务器上对媒体本身进行容器化。

以下是我对这两种替代方案的比较：

	录制并上传	上传并录制
技术	MediaRecorder API + HTTPS	WebRTC 对等连接
客户端	实现上有些复杂，而且浏览器支持的格式也不同	客户端没有变化
服务器端	简单的文件服务器	录音功能的复杂性
主要优点	– 不增加基础设施的复杂性 – 在网络不佳的情况下也能获得更好的质量（前提是您有时间等待上传录音）	– 将记录要求与客户端设备特性和功能解耦 – 完全控制合成结果

何时录制并上传？

在以下情况下，我会使用 MediaRecorder 进行客户端录制：

我的唯一目的就是录制，而且我是唯一的 “参与者”。换句话说——如果我不录制，就没有必要将媒体发送到任何地方
用户意识到录制的重要性，愿意 “牺牲 “一点灵活性来换取更高的制作质量
对我来说，录制的信息流比我正在进行的任何实时互动都更重要，尤其是在需要进行后期编辑的情况下。这通常意味着播客录制和类似的使用情况

什么时候需要上传和录制？

在这种情况下，我会使用经典的上传和录制 WebRTC 架构：

我无法控制用户的设备和行为
录音只是大型服务中的一个小功能。考虑到网络会议，用户可自行决定是否录制，而且使用的比例很小
会话时间较长时。一般来说，如果会话时间超过一小时，我更倾向于上传-录制，而不是录制-上传。没有很好的理由，这只是我的一种直觉

同时进行如何？

还可以同时进行录制和上传，以及上传和录制并行。不明白？

您将在这里看到这种情况：

专注于创建类似播客的录制内容并进行编辑的应用程序
用于访谈的应用程序，在访谈中，两个或更多人在不同的地点进行对话，因此他们必须通过媒体服务器连接，才能进行实际对话。
既然有媒体服务器，你就可以使用上传和录制的方法在服务器上进行录制
由于您将在后期制作中对其进行编辑，您可能希望获得更高质量的媒体源，因此您也可以采用上传并录制的方式。
然后，您就可以向用户提供多种录制结果，让他们选择最适合自己的内容

多流或单流录制

如果要录制的媒体源不止一个，比方说，一群人在互相讲话，那么就会遇到这样的难题：

是要使用 WebRTC 录制从交互中获得一个混合流，还是要获得多个流（每个源或参与者一个）？

假设使用 SFU 作为媒体服务器，并采用上传和录制的方法，那么手中的将是独立的媒体流，每个源一个媒体流。此外，如果打算录制单一媒体流，需要的是一种 MCU…

您可以将每个信号源的音频和视频合并为一个媒体文件（如 .webm 或 .mp4），但是否应该将所有音频和视频源合并为一个单一的流呢？

使用这种混合器意味着在此过程中需要耗费大量的 CPU 和其他资源。下面的插图（来自我的高级 WebRTC 架构课程）展示了如何为两个用户完成这一过程，可以从中推导出更多的媒体源：

红色区块会占用 CPU 预算。解码、混合和编码都是非常昂贵的操作，尤其是当 SFU 的设计和实施正是为了避免这些任务时。

下面是这两种方案的比较：

	多流	混合流
操作	保存到媒体文件中	解码、混合和重新编码
资源	最小	CPU 和内存占用率较高
回放	定制，或单独的每个流	简单的
主要优点	– 不会丢失会话数据 – 可创建多种回放体验 – 由于不会混合任何内容，因此易于记录转录日记实施简单 – 如有需要，可在稍后进行混合	– 随时随地播放 – 所需存储空间更少

何时使用多流录制？

多流可以被视为实现混合码流录制的一个步骤，也可以被视为其本身的目的。以下是我的选择：

当我需要在不同的回放会话中回放多个单一视图的会话时
如果回放录制会话的比例很低，比如 10% 或更低。为什么要浪费增加的资源？(在这里，我会将其视为一个可选的混合流 “目的地”）。
当我的客户可能想进行后期编辑时。在这种情况下，为他提供更多的流和更多的选项将是有益的

什么时候会决定混合流录制？

混合录制几乎总是我的首选解决方案。通常是因为这些原因：

大多数情况下，用户不想在播放部分等待或处理麻烦
即使您为 WebRTC 录制选择多流，几乎总是最终需要提供混合流体验
播放多流内容需要编写一个专用的播放器（尚未见过功能正常的播放器）

混合流客户端录制怎么样？

我见过一两次的一件事是尝试使用设备浏览器来混合流以进行录制。这可能是可行的，但对于实时会话和录制会话中的实际用户来说，质量都会下降。

我不会走这条路…

切换或合成

如果目标是单流录制，那么需要解决的下一个难题就是切换和合成之间的问题。切换是穷人的选择，而合成则能提供更丰富的 “体验”。

什么意思呢？

音频很简单。您总是需要将音源混合在一起。这里没有太多选择。

但对于视频来说，问题主要在于你想给未来的观众一个什么样的视角。切换意味着我们要一次显示一个人–喊得最大声的那个人。合成意味着我们要将视频流混合成一个合成布局，显示会议中的部分或全部与会者。

例如，Google Meet 在录制过程中使用了切换方法，在屏幕共享时使用简单的合成布局（并排显示主持人和他的屏幕，这可能是因为对混合 CPU 的要求不高）。

在某种程度上，切换功能使我们能够 “绕过 “从多个视频源创建单一视频流的复杂性：

	切换	合成
声音	混合所有音频源	混合所有音频源
视频	根据主动扬声器检测，一次选择单个视频	选择多个视频流并将其组合在一起
资源	缓和	高 CPU 和内存需求
主要优点	成本效益	布局更加灵活，更能理解参与者以及他们在会议期间视觉上所做的事情

什么时候会选择切换？

当重点是音频而不是视频时。

面对现实吧——反正大多数会议都很无聊。我们更感兴趣的是会议中的发言，甚至这可能是夸大其词（这也是为什么在某些情况下使用人工智能创建会议摘要和行动项目的原因之一）。

问题的关键在于，实现切换所需的时间可能比合成稍长。为了优化记录过程中的机器时间，我们首先需要投入更多的开发时间。请牢记这一点。

什么时候选择合成？

视频体验非常重要的时候。网络研讨会、现场活动，视频播客。

计划或希望进行后期编辑的媒体。

或者只是在实施过程中更容易完成。

我必须说，在我参与的许多案例中，本来可以选择切换。选择合成只是因为它被认为是更好/更完整的解决方案。这就引出了一个问题：Google Meet 如何能在 2024 年摆脱切换技术？答案很简单，在很多使用案例中并不需要切换技术）。

固定布局还是灵活布局

假设决定在 WebRTC 录制中将多个视频流合成为一个流，那么现在就该决定使用哪种布局了。

可以选择所有视频都使用的单一固定布局（例如平铺式或主持人模式）。也可以使用几种布局，并能根据上下文或一些外部 “干预 “从一种切换到另一种。也可以采用更灵活的方式。我想这完全取决于你想要实现的目标：

	单一的	固定的	灵活的
概念	单一布局统治一切	有 2、3 或 7 种特定布局可供选择	允许用户使用几乎任何布局
主要优点	实施简单；一旦实施，无需动手	为用户提供多种选择；提前了解布局，可以优化代码	用户可以控制一切，因此可以提供最佳的用户体验
主要挑战	如果单一布局无法满足用户的需求怎么办？	如何选择布局？何时以及如何在这些布局之间切换？	如何定义和创建布局？何时以及如何在布局之间切换？

下面是一个在 StreamYard 中实现这一功能的好例子：

StreamYard 提供 8 种预定义的不同布局，主持人可以动态选择，还可以编辑布局或添加新布局（屏幕右下角的按钮）。

何时采用固定布局？

以下是我使用固定布局的时机：

录制主要是事后效果，而不是互动的 “主菜”。在大多数情况下，小组会议不需要灵活的布局（反正也没人在乎）
我的用户本质上不是创意者，这也是同样的道理。WebRTC 录制本身是需要的，但不是为了视觉美感–主要是为了内容
当用户没有时间或精力自行挑选时

在这种情况下，一定要弄清楚哪些布局最适合使用，以及如何自动为用户做出决定（可能是主机布局是什么，你就录制什么，也可能是基于会议的当前状态–有屏幕共享、无屏幕共享、与会者人数等）。

何时采用灵活布局？

如果出现以下情况，灵活性将成为我的目标：

我的用户非常关心最终结果（假设它具有制作价值，例如上传到 YouTube 上）
这是一个通用平台（CPaaS），我不确定我的用户是谁，因此有些用户可能需要额外的灵活性

转码管道(Transcoding pipeline)或浏览器引擎

您决定使用复合视频流录制 WebRTC？很好！现在具体该如何实现呢？

在大多数情况下，我看到供应商会选择两种方法中的一种，要么建立自己的专有/定制转码管道，要么使用无头浏览器作为合成器：

	转码管道	浏览器引擎
底层技术	通常是 ffmpeg 或 gstreamer	Chrome（和 ffmpeg）
概念	从头开始自己缝合管道	在云中添加无头浏览器作为会议用户并捕获该浏览器的屏幕
资源	高	高，内存要求更高（由于 Chrome）
主要优点	– 移动部件更少，意味着解决方案更坚固耐用； – 成本效益高，扩展性更好	– 更易于实施 – 视图可轻松包含任何您想要的 HTML/CSS 元素

在这里，我不会就使用哪种转码器发表意见，因为我不确定是否有简单的指导原则。

实时或 “离线”

最后但并非最不重要的一点是，要决定录制过程是在线进行还是事后进行—— 是实时还是 “离线”。

当您想从正在录制的会话中获得一个复合的单一媒体流时，这一点就很重要。通过 WebRTC 录制，您可以决定一开始只保存 SFU 接收到的媒体，并在其周围加上一些元数据，然后再处理实际的合成：

	实时	“离线”
概念	在录制过程中按需处理。通常会增加 0-5 秒的延迟	使用作业队列处理录制过程本身，使录制的媒体文件可在会话结束几分钟或几小时后重放
主要优点	– 可用于将媒体流传输到直播平台（YouTube Live、Twitch、LinkedIn Live、Facebook Live 等）； – 更好的用户体验（可用速度更快）	– 更好地利用媒体处理资源； – 可延迟到提出回放会话的请求时再进行处理

何时上线？

答案很简单，就是在您需要的时候：