共计 2455 个字符，预计需要花费 7 分钟才能阅读完成。
Chrome 不只是⼀个浏览器，还能够是⼀个渲染引擎和混流器，而 Headless Chrome 更是关上了浏览器在服务器中使⽤的场景，让咱们不仅能够把多个 WebRTC 的视频画⾯录制下来，还能够把⽩板，各种动画⼀起同步的录制下来，实现⼀个所见即所得的页面录制合流⽅案。
01. 在线教育场景中录制的痛点
<img src=”https://main.qcloudimg.com/raw/d42ddd03c9b192899a0f6788dd18e01d.png” width=”700″/>
在线教育场景的录制往往比较复杂，像上图中，咱们录制的时候往往不是单纯的只录制⽼师和学⽣的音视频，还有⽩板互动、动画课件、PPT、以及聊天内容，有的还会有家⻓旁听性能，须要专⻔给家⻓旁听录制⼀路流。在线教育场景中的录制有很多痛点：
1. 多路音视频同步艰难，以及学⽣高低⻨导致的录制布局一直变动
⽐如⼩班课场景，连⻨场景，UI 布局是一直变动的，⽬前的 mcu 的录制⽅案要么是固定布局要么须要⼀个⼀个⽤户指定布局，灵活性被⼤⼤限度。
2. 音视频和 PPT 录制比拟难同步
因为⾳视频是通过 UDP 传输，PPT 的同步往往是通过 TCP 信令来管制，这就导致音视频和 PPT 难以同步，为了解决这个问题⼜引⼊了各种 SEI 插⼊工夫戳的⽅案。
3. 课件⽩板中的动画不易还原
在⼀些 K12 的教课过程中会有比较复杂的动画成果，比方演示⼀个物理试验，⼀些动画成果来激励学⽣，这些动画过程也⽐较难在服务端渲染。
4. 实在上课过程中的互动成果难以还原
实在的上课过程中可能还会有弹幕，聊天，声⾳特效等等，要把这些整个还原下来难度也比拟高。
02. 行业中现有的解决方案
⾏业中各家解决上述痛点的⽅案各不相同，⼤致能够分为两个⽅案：
1. 在老师端残缺录制下来
这么做的确能很好的还原上课过程，但带来的问题是⽼师端除了要进行上课过程中的性能外还要再额定录制⼀路流，对⽼师设施的硬件性能和⽹络都带来了更多的挑战。还有可能的状况是⽼师端的⻚⾯中可能有⼀些没法齐全录制下来给学⽣看的内容。
2. 视频和课件别离录制，交互通过信令来异步还原
开发成本⾼，没法做到回放的实时生成。
03. 咱们摸索了一个新⽅案：「页面录制」
<img src=”https://main.qcloudimg.com/raw/f681b818b9c405bd7d4ecc369c72b0af.png” width=”700″/>
咱们使⽤ Headless Chrome 加载⼀个⽤户要录制的页面，并跑在云函数的 Docker 镜像中，通过 HTTP API 的⽅式来触发录制，把该页面中的内容进⾏残缺录制下来。云函数 SCF 帮忙咱们做好了资源调度和资源隔离，不须要额定部署服务，免去了⼤量运维的⼯作。而且该录制的页面能够是以⼀个学⽣的身份进⾏进入，或者特制的⼀个专⻔⽤于录制的⻚⾯。这样录制的⽅案有很多益处：
1. 极优的录制成果
所见即所得的录制，页面中的⾳视频，课件内容，⽩板交互，动画特效，甚⾄聊天都能够录制下来。能够管制要录制的 FPS，以及编码品质。
2. 集成成本低
基于页面录制，免去了设置各种布局参数的老本。通过云端 API 管制管制何时开始录制，何时完结录制，录制实现之后能够设置回调。
3. 定制容易
通过调整录制⻚⾯的布局即可实现录制布局的调整，甚至能够复⽤现有的课堂页面，作为⼀个旁观者加⼊房间。
4. 运维开发成本低
基于云函数开发，云函数提供了齐备的资源调度，隔离⽅案。齐备的⽇志监控⼯具，能够做到即⽤即开，毫秒级别的计费颗粒度。缩小了⼤量的开发运维的老本。
04. 应用 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 的插件，部署的时候引⼊了⼀定的复杂度。
05. 还存在哪些问题？
当然任何⽅案都不可能是完满的，如果只是想进⾏⾳视频的录制以及合流，相应的录制云计划早就是齐备且⾮常成熟的，⻚⾯录制的⽅案⽐较适宜简单的录制场景，常⻅的就是教育场景的录制。咱们在测试的过程中还发现了页面加载不全录制款式错乱的问题，另外为了能对 Chrome 做更多深度的定制咱们采⽤了开源版本的 Chromium。还有其余的很多⼯程问题，⽐如录制工作的保活，录制的故障转移，录制实现后的异步告诉等等。咱们把此⽅案包装成了⼀个基于云函数的解决⽅案，让⽤户只简略的 API 调⽤就能领有此能⼒。
⽬前曾经有外部团队在使⽤，如果您也想参加此⽅案的测试， 点此实现内测表单填写 ，咱们将在 1-3 个工作日与分割，感谢您的关注与反对。
腾讯实时音视频 TRTC（Tencent Real-Time Communication）是腾讯云面向开发者对外售卖的 PaaS 服务，次要提供音视频的通信能力，笼罩全平台的 SDK，不论是手机、PC、Web、小程序等。
One More Thing
立刻体验腾讯云 Serverless Demo，支付 Serverless 新用户礼包 👉 腾讯云 Serverless 老手体验。
