企业官网建设流程全解析

主播网络抖了 2 秒，一场两小时的带货直播回放被切成了 12 个互不连续的片段——这是录制模块配置不当最典型的一个痛点。很多团队在接入直播录制时只勾选了"开启录制"，却没理解断流拼接与切片周期的工作机制，等到要交付回放时才发现文件对不上、时长对不上、甚至部分片段丢失。本文从工程实现层面把录制模块拆开讲清楚，重点解决三个问题：为什么回放会被切碎、如何让断流重推合并成一段、停止推流后为什么还在计费。

网络抖了 2 秒，回放为什么会变成 12 段

录制模块底层在做什么：直播中心把收到的推流数据拉取下来，切成 TS 切片，再封装为 FLV / MP4 / M3U8 / CMAF 保存到对象存储（OSS）或点播系统（VOD）。这里有个关键认知——录制只是"换容器"，不做二次编码。如果源流本身存在花屏、音画不同步，录制文件会原样保留这些瑕疵。这条规则直接影响排查思路：回放画质问题先查推流端，而不是怪录制模块。

编码格式还有硬限制：视频仅支持 H.264(AVC)、H.265(HEVC)、MPEG-4，音频仅支持 AAC、MP3，不符合就可能黑屏、无声、甚至无法生成文件。录制模块在接入前必须校验推流编码，否则线上会静默失败。

存储路径只有两条，且绑定地域

录制文件存哪里，只有 OSS 与 VOD 两条路径，且同一路流不能同时配置两者。一个容易踩的坑是 Bucket 地域：存储桶必须与直播中心同地域，不支持跨地域写入。比如直播中心选在上海，OSS Bucket 也必须选上海，否则录制任务直接失败。这条约束在架构设计阶段就要定死，后期迁移成本极高。

从总管理中心的视角看，录制模板的配置粒度是"域名 + AppName + StreamName"三层，且有明确优先级：指定域名+指定 AppName+指定 StreamName 优先级最高（①），其次是域名+AppName+通配（②），最低是域名+全通配（③）。同一域名下只允许一个全通配模板。运营后台在排期新场次时，要确认它命中的是哪一层模板，否则会出现"我明明配了高清录制，为什么出来的是默认档"的错位。

三个周期参数，决定回放被切成几段

录制模板里有三个参数，直接决定回放文件的形态：

CycleDuration（单文件最大时长）默认 180 分钟，范围 15~360 分钟，到时强制切新文件。SliceDuration（单 TS 切片时长）默认 30 秒，范围 5~30 秒，仅对 M3U8/CMAF 生效。DelayTime（断流拼接时长）默认 180 秒，范围 15~21600 秒，是控制"断流重推算不算同一段"的核心开关。

回到开头的痛点：主播网络抖了 2 秒，回放被切成 12 段。原因就是 DelayTime 设得太小，断流超过阈值后系统判定"这是新的一场"，于是不断开新文件。把 DelayTime 调大到覆盖正常抖动（比如设为 300 秒或更大），断流在阈值内重推，内容会自动合并到同一文件；超过阈值才生成新文件。这是录制模块里性价比最高的一个调优点。

如果业务要求"立刻出文件"，可以用 RealTimeRecordCommand 的 cancel_delay 指令立即结束拼接等待；直播进行中想强制收尾当前文件并开启新一轮，发 restart 即可。这两个指令是直播运营后台做"精彩片段即时沉淀"时的常用手段。

模板三层匹配，录制的到底是不是你以为的那条规则

除了周期参数，录制模板还有一套三层匹配与优先级机制：①指定域名+指定 AppName+指定 StreamName 优先级最高；②指定域名+指定 AppName+*次之；③指定域名+*+*最低。同域名下仅允许一个全通配*模板。运营后台在给某场直播排期时，要确认它命中的是哪一层——否则会出现"明明配了高清录制，回放却是默认档"的错位。转码流的录制文件命名也会带上转码模板 ID，路径形如 transcodeRecord/{AppName}/{StreamName}_{转码模板ID}/…，排查录制失败时要按这个规则去定位文件，而不是在源流目录里空找。

4K 推流码率超 25 Mbps，单切片会撞上 100 MB 上限

一个常被忽视的技术边界：当 4K/8K 推流码率超过 25 Mbps 时，单个 TS 切片可能超过 100 MB 上限，直接导致录制失败、文件压根生成不出来。这不是模板配错了，而是切片尺寸的硬约束。做超高清直播时，要么把 SliceDuration 调小让单切片体积可控，要么提前评估推流码率，避免录制静默失败却无人察觉。

录制索引剪辑，回放之外的二创入口

录制下来的 TS 切片还能通过"录制索引剪辑"或 CreateLiveStreamRecordIndexFiles 接口合并提取为独立文件，前提是必须包含 M3U8 格式。这正是直播与短视频联动的技术基础——一场直播自动流转为点播素材，供二次剪辑与分发。从架构上看，录制模块不只是"存回放"，它还是内容二创流水线的第一道工序，录制策略会直接影响下游二创的效率与成本。

按需录制：把录不录的决定权交还给业务

并不是所有推流都要录。录制模块支持按需录制：推流开始时，直播服务向预设回调地址发一次 HTTP 请求询问是否录制，业务系统返回指令决定录不录。注意，这个请求只在推流开始时发一次，断流重连不会重发。返回体里的 Interval 会覆盖录制周期，Format 与模板格式取交集，无交集则不录。响应 Body 上限 2048 字节。

这里就涉及角色与权限的划分：超级管理员掌握录制模板与密钥的最高权限；运营管理员负责场次排期与模板下发；主播只能获取推流地址、查看自己的场次数据，没有录制配置权限；运维则通过回调日志排查录制失败原因。权限错配会导致运营改了模板但主播端无感知，或主播误触发录制消耗成本。

三类录制回调，构成可观测的监控闭环

录制状态回调（record_started / record_paused）、文件生成回调（含 uri、record_id、file_url、duration、start_time、stop_time、push_args）、录制错误回调（record_error / transformat_error，含 code 与 message，如 BucketNotFound、AccessDenied、StreamFormatError、UserDisable）——这三类回调是录制模块的监控与风控抓手。错误回调里的 code 直接指向故障类型，运维把它们接入日志系统后，就能在录制失败时第一时间告警，而不是等用户投诉回放打不开。

命名规则与时效：回放索引也有保质期

OSS 命名规则：源流为 record/{AppName}/{StreamName}/{EscapedStartTime}{EscapedEndTime}，转码流为 transcodeRecord/{AppName}/{StreamName}{转码模板ID}/…。存 VOD 的文件名默认就是 StreamName，不支持自定义。更重要的是时效——TS 切片信息仅保存 3 个月，索引文件保存 6 个月。做直播回放与内容二创的系统，必须在 3 个月内把切片合并或转存，否则原始切片会被清理，回放无法播放。

录制文件还是内容审核与申诉驳回的关键证据。当主播对处置结果提起申诉，客服需要调出对应时间段的录制回放，核对违规画面是否属实，再决定驳回还是维持。没有录制归档，审核工单的驳回就缺少事实依据，容易引发纠纷。所以录制模块不仅要能录，还要保证回放可追溯、可定位。

停止推流不等于停止计费，这是最隐蔽的成本陷阱

录制模块的成本构成有四项：月录制服务费（按并发峰值路数）、录制转封装费（非默认格式按时长）、录制视频处理费（存 VOD）、存储费。最容易被忽略的一条是：必须删除录制模板或关闭域名录制功能，才停止计费；仅仅停止推流，录制服务费仍可能产生。很多团队在活动结束后忘了清理模板，月底账单上多出一截录制费用，回头查才发现是模板还在跑。

一个常被问到的问题：小程序、PC 运营后台、移动端 App 三端怎么看回放？三端的回放播放都指向同一份录制文件，差异在播放协议适配——小程序端受限于平台能力多用 HLS，PC 运营后台可直接拉 M3U8 检索，移动端 App 用播放器 SDK 做清晰度切换。录制模块产出的文件是统一的，三端同步的一致性由播放层而非录制层保证。

活动型直播可在活动结束后立即删模板，常驻型直播则按 AppName 精细匹配，避免全通配模板把低价值场次也拉进高成本录制。录制方案在落地时，建议把模板按"域名级通用 + AppName 级定制"两层规划，通用档保底、定制档按需覆盖，既能控制成本又能满足不同场次的分辨率要求。