4.1 录制方案选型：云端录制 vs 本地录制

直播课上完，最现实的问题是：录播从哪来？我们机构最早的做法特别原始——老师在自己电脑上开录屏软件，下课后把几十 GB 的视频传给运营，运营再传到网盘发给学生。一个月下来，丢文件、传错版本、画质参差不齐的投诉没断过。这时候我才意识到，录制方案必须在平台层面统一设计，而不是交给老师各自发挥。

TRTC 提供云端录制能力，客户端侧也能自己录，两条路都能走通，但成本结构和可靠性完全不同。选型时我主要对比了四个维度，结论先放前面：正课云端录制，公开课本地兜底。

另一个常见误区是觉得录制就是“开个录屏”那么简单。真正做过才知道，录制环节要决定的事情一大堆：录哪一路画面、录成什么格式、文件放哪、录坏了怎么办、超期了清理不清理。每一个决定都会影响后面三节的设计。所以这一节虽然标题是选型，实际上是在给整个回放体系定地基。

两套方案怎么比

一句话总结：云端录制贵一点但省人，本地录制省钱但费心。我们老师流动频繁，人比钱贵，付费课容不得半点闪失，所以正课必须上云端录制。这也印证了我读《腾讯云实战手记：从云服务器到短信推送的全栈上线》时记下的一句话：能在云上托管的能力，就别扛在自己的机器上。

录制费用值得单独说一句。云端录制的费用和排课时长线性相关，排课越满费用越高，这点在成本预估阶段就要算进去，而不是月底看账单才吃惊。我们最初的录制费占比不高，但环比一直在涨，因为课一直在加。意识到这点后，把答疑课改成云端录制只存 30 天，费用增速立刻降了下来。费用优化的思路和《1Panel 常见问题与排错实战》里讲资源监控的做法一样：先找到消耗大头，再分级处理，比无脑降配科学得多。

单流还是混流

云端录制还有个绕不开的选择：录每个人的单路画面，还是直接录合成后的画面。

我们选混流。小班直播的画面布局简单，也就是老师大窗加几个学生小窗，后期没有重新剪辑的需求，混流一步到位。如果你们的课需要后期精剪——比如公开课要剪成短视频投放引流——那单流录制更合适，每一路素材都在，交给剪辑发挥空间大。代价也明摆着：每路都要存、每路都要传，存储和带宽成本成倍上升，后期合成还要人工盯，对小型团队是额外负担。

混流还有个隐藏好处：回放画面就是学生上课时看到的画面，所见即所得，不会出现回放和直播对不上的情况。单流素材合成的画面是后期重新排版的，和直播布局可能不一致，学生群里讨论某个演示画面时容易对不上号。对以复习为主的场景，一致性比灵活性重要。

不同课型的选择

不是所有课都值得花云端录制的钱。我们把课型分成三类，录制策略各不相同，这是整个录播体系里最实用的一个分级。

公开课用本地录制，是因为它对完整性要求不高——中间断两分钟不耽误引流；但正课断了就是教学事故。这个分级策略跑了大半年，录制相关的投诉基本清零，每月录制成本也控制在一个可预期的范围内。

分级定下来后，还要让排课系统和录制配置联动：排课时带上课型字段，录制策略自动匹配，运营不需要手动选。手动选这件事本身就不可靠，人对重复性配置天然会出错，能自动化的就别留给人。

录制格式与画质

云端录制落下来的文件格式可以选，不同格式对应不同的播放和后期场景。

我们选 MP4 做录制主格式，HLS 作为 CDN 分发环节的转码输出，这两者的分工在 4.2 节会展开。一个常被忽略的点：直播码率决定了回放画质的上限——直播时 720P 录下来，回放不会因为转码就变成 1080P。所以前面弱网优化定的码率策略，其实同时决定了回放质量，两件事必须一起规划，不能各定各的。

再补充两个细节。其一，录制文件落盘后别急着删原始文件：转码完成后我们保留原画 7 天再清理，留给运营抽查画质。有一次转码参数出了问题，所有高清档画面发绿，多亏原文件还在，重新转码很快就恢复了，这 7 天余量就是最便宜的保险。其二，文件命名要人能读懂，包含课程、课节和日期信息，千万别让系统输出一串随机字符串——出问题排查时，你会对着几十个毫无意义的文件名抓狂。

录制异常怎么办

云端录制也会出问题，而且一旦出问题往往是安静的——没人会立刻发现，直到学生投诉看不到回放。我遇到过两次：一次是老师临时调课到没开录制的时段，系统按原排课走了录制但那节课根本没上；另一次是录制文件落盘成功但时长只有几十秒，实际是一段黑屏。从此我们定了一条规矩：每节课后自动跑一遍录制体检，比对排课时长和录制时长，偏差超过 10% 就告警通知运营，当天人工确认。这套体检脚本不复杂，但救过我们好几次。

体检脚本还有个兄弟功能：开课前十分钟自动检查本节课的录制配置是否就绪，没就绪就在运营群里报警。这个检查抓到过两次真问题——一次是排课改了时间但录制任务没同步，另一次是新老师的课堂没开录制权限。都是提前发现提前修，要是等下课才发现，一节正课的回放就没了。

上线前的确认清单

录制方案敲定后，真正上线前还有几件事必须逐项确认。

• 每个课型的录制方式在后台配好，新排的课自动继承，不用每周手工选。
• 混流模板提前预演过，老师画面、学生头像、白板的位置在回放里显示正常。
• 老师本地录制的兜底流程写了文档，新老师入职第一天就培训，不只靠口口相传。
• 存储目录、转码参数、清理周期这些和 4.2 节联动的设计先定稿，录制输出严格按规范落盘。

这份清单看着琐碎，每一条背后都是事故。我们最早没做混流模板预演，结果第一次正式课的回放里老师画面被学生头像挤到角落，家长投诉说一整节课只看到半张脸。这种低级错误一旦发生，补救成本远高于提前演练的成本。还有一个容易被漏掉的检查：录制的音频轨道。有次家长反馈回放只有画面没有声音，排查发现是新老师上课用了外接麦克风但系统默认录的是内置麦克风。从那以后混流模板的预演必须连同音频设备一起测，老师换设备必须重新跑一次预演。

过渡方案：先本地兜底，再上云端

说实话，我们不是一开始就全量云端录制。第一学期只有 4 个班，预算卡得紧，我用的是过渡方案：本地录制兜底，只在两类场景开云端录制——付费正课，以及有家长旁听的示范课。

过渡方案的关键是流程要先跑顺：老师本地录制后统一传到一台文件服务器上，按课程和日期归档，再手动转码上传。这套手工流程虽然笨，但它逼着我们把目录结构、命名规范和转码参数都提前定好了。那台归档服务器是怎么搭的，可以看《轻量应用服务器建站实战：从选购到网站上线》，一台最便宜的轻量机器就够用。等第二学期预算到位切换到云端录制时，这些规范直接复用，几乎没有阵痛。如果一开始就上云端，很多规范反而会被自动化的便利掩盖，等数据量大了再改就晚了。

选混流还有一层考虑：录制文件的大小和清晰度可控。混流输出的就是一路合成流，码率由我们在直播侧的推流参数决定，录制文件的大小直接可预估，存储规划简单。单流录制意味着多路独立编码，总码率不可控，一期课存下来存储量可能翻几倍，对成本预估很不友好。

还有一点经验：过渡期别省太久。我们原计划一个学期后切云端，实际拖到了第二个学期末，中间出过一次本地录制文件传输损坏、无法恢复的事故，一节收费课的回放永久丢失。事后算账，过渡期省下的钱远不够赔一节正课的信任。所以兜底方案可以有，但要有明确的切换时间表，团队里谁都知道什么时候彻底过去。这套先手工后自动的思路，和《AI 语音转写实战：搭建会议纪要工具》里的做法一致：先用最笨的方式把链路验证通，再逐步上自动化。录制方案选型没有标准答案，关键是想清楚你的课型愿意为回放兜底付多少钱、多少人力。

延伸阅读

• 《腾讯云实战手记：从云服务器到短信推送的全栈上线》
• 《轻量应用服务器建站实战：从选购到网站上线》
• 《AI 语音转写实战：搭建会议纪要工具》