WebRTC录制的挑战和解决方案

WebRTC录制的挑战和解决方案

您的应用程序需要 WebRTC 录制吗？许多 WebRTC 应用程序的一个关键部分是录制本次会话（Session）的能力，这可能是需求中的可选部分，也可能是应用程序或者服务的关键点。让我们看一下与 WebRTC 录制相关的几个方面，确保在你实现的时候，你能够在自己的详细需求和设计中做出更好的选择。

“录制后上传”还是“边传边录”

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

本地录制使用 MediaRecorder API，而上传使用 HTTPS或 WebSocket。在服务器上录制使用 WebRTC PeerConnection，然后使用任何媒体服务器来将服务器上的媒体数据进行容器化。

以下是我如何将这两种替代方案相互比较：

	录制后上传	边录边传
技术	MediaRecorder API + HTTPS	WebRTC PeerConnection
客户端	实现上有些复杂，而且浏览器支持的格式不同	对客户端没有变化
服务端	简单文件服务器	录制实现较为复杂
主要优势	* 不会增加基础架构的复杂性 * 在较差的网络上质量更好（假设您有时间等待上传）	* 将录制要求与客户端设备特性和功能分离 * 具有对录制数据的完整控制权

我什么时候采用“录制后上传”？

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

1. 我的唯一目的就是录制，我是唯一的“参与者”。换一种说法——如果我不录制，就没有必要在任何地方发送录制下来的媒体数据

2. 用户意识到录制的重要性，并愿意为了更高的制作质量而“牺牲”一点灵活性

3. 对我来说，录制的直播比我进行的任何现场互动都更重要——尤其是在需要后期制作编辑的情况下。例如在和播客这样类似的应用场景。

我什么时候采用“边录边传”？

以下是我建议的使用传统 WebRTC 上传和录制架构的情形：

1. 我无法控制用户的设备和行为
2. 录制是大型服务中的一个小功能。例如用户可自行选择是否进行录制的网络会议场景，录制很有可能仅在少数情况下被使用。
3. 当会话较长时。一般来说，如果会话可以超过一个小时，我更加愿意推荐你使用边录边传的方式，没有什么特别原因，直觉让我觉得应该用这种方式。

两种方式结合的场景？

这里也许还存在一些场景，是同时需要用到这两种录制方式的，是否有点困惑怎么会有这样的情况？

我这里假设可能会有这样的使用场景：

• 一个专注于创建经过编辑的录制的类似播客的内容的应用程序
• 一种用于采访，其中两个或更多人在不同位置进行对话，因此他们必须通过媒体服务器连接才能进行实际对话
• 由于有媒体服务器，因此可以使用边传边录的方法在服务器中录制
• 由于您要在后期制作中对其进行编辑，因此您可能希望拥有更高质量的媒体源，因此您也可以边传边录
• 然后，您将这些多个结果录制内容提供给您的用户，以选择最适合他的录制内容

录多流还是单流

如果你要录制多个媒体源，比如说一群人互相交谈，那么你将面临这个难题需要解决：

您会使用WebRTC录制来获取交互中的单个混合流，还是多个流 - 每个流对应一个源或参与者？

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

对于每个源，您可以将其音频和视频打包到单个媒体文件（例如 .webm 或 .mp4）中，但是是否应该将所有音频和视频源混合在一起到单个流中？

使用这样的混流器意味着您将为此过程花费大量 CPU 和其他资源。下图展示了如何为两个用户完成此操作 - 您可以从中推断出更多媒体源的操作方式：

红色块是消耗 CPU 的部分。解码、混流和编码是成本高昂的操作，特别是当一个 SFU被设计和实施为了避免这些任务时。

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

	多流	混流
操作	保存到媒体文件	解码、混合并重新编码
资源占用	较小	较高的 CPU 和内存消耗
回放	可自定义，或者分别处理每个单独的流	简单
主要优势	* 会话不会丢失数据 * 可以创建多种播放体验 * 易于对转录进行日记化，因为没有混合任何内容 * 易于实施 * 如果需要，可以另外找时间再混合	* 在任何地方都可以容易地播放 * 需要更少的存储空间

何时应该使用多流录制？

多流可以看作是迈向混合流录制的一步，也可以看作是它自己的目标。我会在这些情况下选择这种方式来录制：

1. 当我需要能够在不同的回放会话中播放，且每个回放会话存在多个回放视图
2. 如果录制的会话被播放次数的百分比较低，例如 10% 或更低。为什么要增加和浪费更多资源？
3. 当我的客户可能想要从事后期制作编辑时。在这种情况下，给他更多的流和更多的选择将是有益的

何时应该使用混流录制？

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

1. 在大多数情况下，用户不想在播放过程中等待或处理各种麻烦的事务
2. 即使您为 WebRTC 录制选择多流，您最终也几乎总是需要给用户提供混合流
3. 播放多流内容需要编写一个专用播放器（尚未看到功能正常的播放器）

在客户端进行混流录制怎样？

我见过一两次是尝试使用设备浏览器混合流以进行录制。这可能是可行的，但实时会话和录制会话中的实际用户的质量都会降低。我不会走这条路…

切换还是合成

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

这是啥意思？

音频很容易。您始终需要将源混合在一起。这里没有太多选择。

不过，对于视频来说，问题主要是你想给你未来的观众一个什么样的有利位置。切换意味着我们将一次显示一个人——喊得最响亮的人。合成意味着我们将视频流混合到一个复合布局中，以显示会话中的部分或全部参与者。

例如，Google Meet 在其录制中使用切换方法，在进行屏幕共享时采用简单的复合布局（并排显示演示者和他的屏幕，可能是因为它在混合 CPU 上不太难）。

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

	切换	合成
音频	混合所有音频源	混合所有音频源
视频	根据当前扬声器检测，一次选择一个视频	选择多个视频流并将其组合在一起
资源	适中	较高的 CPU 和内存需求
主要优势	高性价比	会议布局更灵活，更了解参与者以及会议期间他们的视觉行为。

我什么时候选择切换？

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

让我们面对现实吧——无论如何，大多数会议都很无聊。我们对他们所说的内容更感兴趣，即使这可能有点夸张（在某些情况下，人工智能被用于创建会议摘要和行动项目的原因之一）。

这里唯一的症结是，实现切换可能比合成花费的时间稍长一些。为了优化录制过程中的机器时间，我们需要首先投入更多的开发时间。请记住这一点。

什么时候选择合成？

视频体验很重要的场景，例如网络研讨会，现场活动，视频播客。

计划或想要后期对媒体数据进行编辑。

或者这里已经有一份很容易就能获取到的实现方案了。

我必须说，在我参与的许多案例中，不少都选择了切换的方式。我之所以更愿意选择合成，只是因为它被认为是更好/更完整的解决方案。这就引出了一个问题——Google Meet 如何在 2024 年摆脱切换的方式？（答案很简单——在很多用例中都不需要它）。

刚性布局或灵活布局

假设您决定在 WebRTC 录制中将多个视频流合成为单个流，那么现在是时候决定要使用的布局了。

您可以选择用于所有布局的单一刚性布局（例如磁贴或演示者模式）。您可以选择几种布局，并能够根据上下文或一些外部“干预”从一种布局切换到另一种布局。你也可以选择更灵活的东西。我想这完全取决于你想要实现的目标的背景：

	单一布局	刚性布局	灵活布局
概念	单一布局，统领一切	有 2、3 或 7 种特定布局可供选择	允许用户可能希望使用的几乎任何布局
主要优势	* 易于实施 * 它通常是免费的	* 为用户提供了一些选择 * 提前了解布局可以对它们进行代码优化	用户可以控制一切，因此您可以提供最佳的用户体验
主要挑战	如果单一布局对您的用户来说还不够怎么办？	* 如何选择要拥有的布局？ * 何时以及如何在这些布局之间切换？	* 如何定义和创建布局？ * 何时以及如何在布局之间切换？

下面是如何在 StreamYard 中完成此操作的一个很好的示例（译者注：StreamYard是加拿大的一家同名公司的视频直播平台）：
StreamYard 提供了 8 种预定义的不同布局，主机可以动态选择，以及编辑布局或添加新布局（屏幕右下角的按钮）的能力。

何时使用刚性布局？

以下是我将采用刚性布局的时间：

1. 录制主要是事后所需，而不是互动的“主菜”。在大多数情况下，小组会议不需要灵活的布局（反正没有人关心）
2. 我的用户本质上不是创意者，这让我们得出了同样的观点。WebRTC录制本身是必需的，但不是为了它的视觉美感——主要是因为它的内容
3. 当用户没有时间或精力自己挑选时

请确保找出最适合使用的布局，并想办法为用户自动做出决定（可能是基于预制的主要布局，或者基于会议的当前状态 - 屏幕共享与否，参与者数量等因素来综合考虑）。

何时适合使用灵活布局？

如果出现以下情况，灵活布局将是我的目标：

1. 我的用户非常关心最终结果（假设它具有生产价值，例如将其上传到 YouTube）
2. 这是一个通用平台 （CPaaS），我不确定我的用户是谁，所以有些人可能需要额外的灵活性

转码还是浏览器引擎

您决定使用复合视频流进行WebRTC录制吗？太棒了！那么，您究竟如何实现这一目标呢？

在大多数情况下，我看到供应商在这里选择了两种方法之一——要么构建自己的专有/自定义转码管道——要么使用无头浏览器作为他们的合成器：

	转码	浏览器引擎
底层技术	通常是 ffmpeg 或 gstreamer	Chrome （以及 ffmpeg）
概念	从头开始自行完善转码管道	在云上启动一个无头浏览器，然后模拟出一个用户来捕获浏览器内容
资源	高	高，对内存的要求更高（因为用了Chrome）
主要优势	* 方案更加成熟稳定 * 性价比高，扩展性好	* 更易于实施 * 视图中可以轻松包含您想要的任何 HTML/CSS 元素

在这里，我不会就使用哪一个发表意见，因为我不确定是否有一个简单的指南。为了确保我不会让您满意，我将分享 Daily 在 2022 年在 Kranky Geek 所做的一次会议，谈论他们的原生转码管道（译者：下方是一个 iframe 内嵌视频，如无法正常显示，请手动打开： https://player.bilibili.com/player.html?bvid=BV1M2421N78v&page=1 ）

既然这是他们采取的替代方案，那就批判性地看待它，试图弄清楚他们的挑战是什么，创建你自己的方案比较表，并决定采取哪条路。

实时还是“离线”

最后让我们来说一下决定录制过程是在线进行还是事后进行 - 实时或“离线”。

当您尝试从正在录制的会话中获取复合单媒体流时，这一点很重要。使用 WebRTC 录制，您可以选择先仅保存由您的 SFU 接收的媒体以及一些相关元数据，之后再处理实际的合成过程。

	实时	离线
概念	按需处理正在发生的录制。通常，增加 0-5 秒的延迟	使用作业队列来处理录制过程本身，使录制的媒体文件在会话结束后几分钟或几小时即可播放
主要优势	* 可用于将媒体流式传输到直播平台（YouTube Live，Twitch，LinkedIn Live，Facebook Live等） * 更好的用户体验（更快可用）	* 更好地利用媒体处理资源 * 可以延迟，直到发出播放会话的请求

何时使用实时方式？

1. 如果您计划将合成媒体流式传输到实时流式处理平台

2. 当所有（或大多数）会话最终被播放时

何时使用“离线”方式？

这种方式有一系列的优势：

1. 成本效益
   1. 与您的云服务提供商承诺使用计算资源，然后排队这些作业，以获得更好的机器利用率。
   2. 您可以在云中使用 Spot 实例来降低成本（当它们被拿走时，您可能需要重试）—— 译者注：Spot是 Amazon Web Services 提供的一种容器管理服务类型
2. 如果您不会马上就需要拿到录制流
3. 假设录制内容很少被查看，最好是按需来合成，并假设存储成本要低于计算成本（取决于您需要存储这些媒体文件多长时间）

两种方式共同使用的场景？

这里有一点建议，这些方法可能很有效：

• 混合音频立刻进行，但视频合成需要等待（或者可能根本不需要）
• 离线使用，但可以选择根据会话特征或用户似乎想要立即播放文件来提高优先级并“上线”

提前规划您的 WebRTC 录制架构

这篇文章写的太长了，抱歉。

一旦你深入研究了上述的这些细节以后，你就会发现设计一个 WebRTC 录制架构是多么复杂。认真考虑下这些需求，并理解它们对你所做架构决策的影响。

写在最后

本文是《WebRTC recording challenges and solutions》 的翻译，个别内容进行了合并简化。从文中可以看出，设计一个完善的音视频录制系统架构，需要考虑的细节非常多，也十分复杂。在实施过程中，由于应用场景的不同，客户需求的复杂性，也会产生各种各样的问题。因此，如果您比较倾向于采购一套低成本、高可用性的成熟录制系统，而非自己从零开始开发，那么允许我这里向您推荐一下 百家云 的 BRTC 产品。其中的 BMCU作为该产品的核心组成部分，提供了完整、可靠、灵活的实时流录制方案。本文提到的每一方面内容，几乎在 BMCU中都进行过专研和优化。目前，BMCU时时刻刻都在为百家云的全部实时音视频产品提供着录制、转码、合流、推流等各种复杂的服务。并且需要特别说明的是，支持私有化部署！如果感兴趣的话，欢迎通过官网与我们取的联系。或者在本文章下方给我留言。

百家云成立于2017年，是一家为企业解决视频技术应用领域各类痛点与需求的 ToB 视频云技术服务商。自成立以来，一直致力于通过音视频技术为企业数字化发展持续供能，目前已经向金融、教育、汽车、医疗等多个领域的知名企业及政府机构提供一站式视频技术服务。

作为一家创新驱动型科技公司，百家云打造了视频SaaS/PaaS业务、视频云产品和软件、视频系统解决方案”三大类产品服务，引领着全球实时互动云服务的发展。

目前，百家云已在全国十余个城市成立了多个研发中心、分公司及办事处，能有效让视频技术创造产业价值，用服务推动实体经济发展。公司的产品及服务广受各界好评，因此斩获多项行业大奖，2022年被工信部认证评定为“北京市专精特新小巨人”。2022年12月，百家云正式登陆纳斯达克，股票代码：RTC。成为中国音视频SaaS第一股。