技术解码丨使⽤云函数和 Headless Chrome 进行实时渲染录制合流

Chrome 不只是⼀个浏览器，还可以是⼀个渲染引擎和混流器，而 Headless  Chrome 更是打开了浏览器在服务器中使⽤的场景，让我们不仅可以把多个 WebRTC 的视频画⾯录制下来，还可以把⽩板，各种动画⼀起同步的录制下来，完成⼀个所见即所得的页面录制合流⽅案。 

在线教育场景中录制的痛点

在线教育场景的录制往往比较复杂，像上图中，我们录制的时候往往不是单纯的只录制⽼师和学⽣的音视频，还有⽩板互动，动画课件，PPT，以及聊天内容， 有的还会有家⻓旁听功能，需要专⻔给家⻓旁听录制⼀路流。在线教育场景中的录制有很多痛点：

1、多路音视频同步困难，以及学⽣上下⻨导致的录制布局不断变化

⽐如⼩班课场景，连⻨场景，UI布局是不断变化的，⽬前的mcu的录制⽅案要么是固定布局要么需要⼀个⼀个⽤户指定布局，灵活性被⼤⼤限制。

2、音视频和PPT录制比较难同步

由于⾳视频是通过 UDP 传输， PPT 的同步往往是通过 TCP 信令来控制，这就导致音视频和PPT 难以同步， 为了解决这个问题⼜引⼊了各种 SEI 插⼊时间戳的⽅案。 

3、课件⽩板中的动画不易还原

在⼀些K12的教课过程中会有比较复杂的动画效果，比如演示⼀个物理实验，⼀些动画效果来激励学⽣，这些动画过程也⽐较难在服务端渲染。

4， 真实上课过程中的互动效果难以还原

真实的上课过程中可能还会有弹幕，聊天，声⾳特效等等，要把这些整个还原下来难度也比较高。

行业中现有的解决方案

⾏业中各家解决上述痛点的⽅案各不相同，⼤致可以分为两个⽅案：

1、在老师端完整录制下来 

这么做确实能很好的还原上课过程，但带来的问题是⽼师端除了要进行上课过程中的功能外还要再额外录制⼀路流，对⽼师设备的硬件性能和⽹络都带来了更多的挑战。还有可能的情况是⽼师端的⻚⾯中可能有⼀些没法完全录制下来给学⽣看的内容。

2、视频和课件分别录制，交互通过信令来异步还原

开发成本⾼，没法做到回放的实时生成。

所以我们探索了一个新⽅案—“页面录制”

我们使⽤ Headless Chrome 加载⼀个⽤户要录制的页面，并跑在云函数的 docker镜像中，通过 HTTP API 的⽅式来触发录制，把该页面中的内容进⾏完整录制下来。云函数帮助我们做好了资源调度和资源隔离，不需要额外部署服务，免去了⼤量运维的⼯作。而且该录制的页面可以是以⼀个学⽣的身份进⾏进入， 或者特制的⼀个专⻔⽤于录制的⻚⾯。这样录制的⽅案有很多好处：

1、极优的录制效果 

所见即所得的录制，页面中的⾳视频，课件内容，⽩板交互，动画特效，甚⾄聊天都可以录制下来。可以控制要录制的 FPS，以及编码质量。

2、集成成本低

基于页面录制，免去了设置各种布局参数的成本。通过云端 API 控制控制何时开始录制，何时结束录制， 录制完成之后可以设置回调。 

3、定制容易

通过调整录制⻚⾯的布局即可完成录制布局的调整，甚至可以复⽤现有的课堂页面，作为⼀个旁观者加⼊房间。 

4、运维开发成本低

基于云函数开发，云函数提供了完备的资源调度，隔离⽅案。完备的⽇志监控⼯具，可以做到即⽤即开，毫秒级别的计费颗粒度。减少了⼤量的开发运维的成本。

使用 Headless Chrome 录制的几种方案 

1、通过getDisplayMedia⽅法来采集当前⻚⾯Tab 

使⽤ MediaDevices.getDisplayMedia 可以获取当前⻚⾯的 Tab，此⽅案实现起来比较简单。问题是我们在测试此⽅法的时候只能采集当前mic的声⾳。另外此⽅法需要运⾏在录制⻚⾯中，对⻚⾯会有侵⼊，如果录制⻚⾯完全受我们控制该⽅案没有问题，但我们的⽬标是要做到对录制⻚⾯没有侵⼊，所以该⽅法并不特别满⾜我们的需求。

2、Chrome渲染到虚拟X-server，并通过FFmpeg 抓取系统桌⾯

通过启动xvfb启动虚拟 X-server，Chrome 进⾏全屏显示渲染到到虚拟 X-server 上，并通过 FFmpeg 抓取系统屏幕以及采集系统声⾳并进⾏编码写⽂件。这种⽅式的适配性⾮常好， 不仅可以录制 Chrome，理论上也可以录制其他的应⽤。缺点是占⽤的内存和 CPU 较多。

3、通过 Chrome 插件的⽅式采集当前 Tab

Chrome 的拓展提供了录制了当前Tab的能力， 并通过 MediaRecorder 或者WebCodecs 进⾏编码。这种⽅式的适配性比较好， 对页面没有侵⼊。缺点是引入 Chrome 的插件，部署的时候引⼊了⼀定的复杂度。

还有哪些问题？

当然任何⽅案都不可能是完美的， 如果你只是想进⾏⾳视频的录制以及合流，相应的录制云方案早就是完备且⾮常成熟的， ⻚⾯录制的⽅案⽐较适合复杂的录制场景，常⻅的就是教育场景的录制。我们在测试的过程中还发现了页面加载不全录制样式错乱的问题，另外为了能对 Chrome 做更多深度的定制我们采⽤了开源版本的 Chromium。还有其他的很多⼯程问题，⽐如录制任务的保活，录制的故障转移，录制完成后的异步通知等等。我们把此⽅案包装成了⼀个基于云函数的解决⽅案，让⽤户只简单的 API 调⽤就能拥有此能⼒，⽬前已经有内部产品在使⽤，如果你也想参与此⽅案的测试可以填写以下问卷申请测试。