直播会在事件仍在进行时，将摄像机或制作编码器的视频传送给观众。 生产工作流不只是播放器和上传按钮，而是由采集、编码、接入、路由、转码或封装、分发、播放、监控和恢复组成的链路。
本指南说明这条链路如何运行、每个阶段适合哪些协议、需要测量哪些指标，以及如何避免小型接入问题演变为影响所有观众的中断。
直播的工作原理
- 采集： 摄像机、屏幕源和音频设备生成直播节目。
- 编码： 硬件或软件编码器将节目压缩为具有特定编解码器、码率、分辨率和帧率的配置。
- 接入： 编码器通过 SRT、RTMPS、RIST 或其他受支持的传输方式发布一路贡献信号。
- 路由与处理： 平台验证信号，在需要时创建不同清晰度，进行录制并分发到各个目标。
- 封装与分发： WebRTC、LL-HLS、HLS 或其他播放路径将节目直接或通过 CDN 送达观众。
- 播放与观察： 播放器缓冲并呈现 stream，操作人员同时监控接入状态、分发错误和观众体验。
每个阶段都会占用一部分延迟和可靠性预算。只优化编码器无法弥补播放器的大缓冲，低延迟播放器也无法修复不稳定的贡献链路。
分别选择贡献和分发方案
贡献是从制作源到平台的路径；分发是从平台到观众的路径。两者解决不同问题，不必使用相同协议。
| 需求 | 常见选择 | 需要验证的取舍 |
|---|---|---|
| 通过互联网进行可靠贡献 | SRT 或 RIST | 恢复延迟必须与 RTT、抖动和丢包相匹配。 |
| 广泛的编码器兼容性 | RTMPS | 简单接入不具备与 SRT 相同的丢包恢复控制。 |
| 交互式观看体验 | WebRTC | 亚秒级分发会增加信令、扩展和网络复杂度。 |
| 接近实时的大规模观众 | LL-HLS | 播放器、封装器和 CDN 必须一起测试。 |
| 最大的播放覆盖和缓存效率 | HLS | 对于非交互观众，更高的延迟可能可以接受。 |
如需针对延迟做出明确选择，请使用 低延迟直播架构指南。对于不稳定网络上的贡献，请查看 SRT 贡献工作流。
设定可衡量的服务目标
在选择协议或供应商之前先写明目标。至少定义：
- 端到端延迟以及可接受的尾部延迟；
- 按设备和地区划分的启动时间与重新缓冲率；
- 编码器丢帧、接入码率波动、丢包和 RTT；
- 允许的中断时间与恢复时间目标；
- 所需的分辨率、帧率和音频布局；
- 并发观众、目标数量和录制保留期；
- 访问、变现、审核与合规要求。
平均值会掩盖事件风险。请跟踪百分位和群组：健康的中位数可能与某个故障地区、设备系列或 ISP 同时存在。
根据真实场景设计编码配置
使用活动中的真实运动、图形、浏览器源和音频路由验证配置。静态人物测试无法证明体育画面或屏幕共享会保持稳定。
- 保留上传余量，不要占满可用连接。
- 让 GOP 和关键帧设置符合目标要求。
- 使用能够反映真实观众设备和带宽的码率阶梯。
- 在同时录制和直播时测量 CPU 或 GPU 余量。
- 对已验证配置进行版本管理，并在开播前冻结非必要改动。
使用 码率计算器 进行初始容量规划，然后通过持续测试验证结果。
在架构中加入恢复能力
可靠的 stream 应对信号源丢失、网络丢失、目标故障和播放器降级都有记录明确的响应方案。
- 准备一条不依赖同一网络故障域的备用贡献路径。
- 在活动前监控主路径和备用路径，而不是在事故中才发现备用链路失效。
- 明确故障切换是自动还是由操作员控制，并指定决策负责人。
- 为性能较弱的设备或不稳定的分发路径保留安全的 fallback 配置。
- 演练目标凭据过期和单个目标故障，确保不会停止所有输出。
对于长期频道，将配置视为发布产物：负责人、版本、测试证据、告警阈值和 rollback 说明应保持在一起。
监控完整的观众链路
接入健康是必要条件，但并不充分。编码器可能仍保持连接，而观众已经遇到 manifest 失败、分片加载缓慢、解码错误或过度缓冲。
- 源： 采集帧率、音频连续性和编码器负载。
- 贡献： 连接状态、输入码率、RTT、丢包、重传和迟到数据包。
- 处理： 队列深度、rendition 错误、时间戳连续性和录制状态。
- 分发： 源站错误、CDN 缓存行为、请求延迟和地区故障。
- 播放： 启动时间、重新缓冲、严重错误、与直播边缘的距离以及 A/V 同步。
运行独立的播放探测。绿色的接入面板绝不能成为节目正在直播的唯一证据。
生产前检查清单
- 从真实场地或网络以计划的码率和持续时间运行测试。
- 确认每个目标、token 过期时间和隐私状态。
- 在有代表性的手机、桌面设备和电视上验证播放器。
- 触发一次受控故障，并验证恢复和告警。
- 检查录制、字幕、图形、音频声道映射和同步。
- 记录发布负责人、rollback 负责人和升级渠道。
生成可重复的测试视频 并使用 直播质量检查 然后再向观众开放活动。
托管路由层何时有帮助
当一路经过测试的接入需要供给多个平台、录制或播放工作流，而又不希望制作编码器为每个目标分别上传时，路由层非常有用。它集中目标控制、可观测性和恢复能力，同时让信号源配置更简单。
使用 Callaba Multi-Streaming 将一路直播输入分发到多个目标并管理分发路径。若需要掌控基础设施， 自托管选项 是独立的部署选择，而不是重复的直播工作流。
常见问题
什么是直播？
直播是在事件进行期间持续采集、编码、传输和播放视频。生产系统还包括路由、监控、恢复和访问控制。
哪种协议最适合直播？
不存在适用于所有情况的最佳协议。SRT 或 RTMPS 可承载贡献信号，而 WebRTC、LL-HLS 或 HLS 可满足不同的观众延迟和扩展要求。
直播需要多少上传速度？
连接容量必须高于配置的视频和音频码率。请保留运行余量，并测试持续性能、抖动和丢包，而不是只依赖一次测速。
如何提高直播的可靠性？
使用经过验证的编码配置、独立的备用路径、端到端监控、演练过的故障切换，以及针对弱网络或设备测试过的 fallback。
一个编码器可以推送到多个平台吗？
可以。路由或多平台直播服务可接收一路贡献信号并分发到多个平台，从而减少本地上传和运维复杂度。
最终生产原则
优化整条链路，而不是单个协议。 定义观众结果，测量每个阶段，演练一次故障，然后再将工作流投入生产。
使用 Callaba 运行此工作流
使用 Callaba Multi-Streaming 当一路经过测试的输入需要到达多个目标时。添加 Callaba Live Video Failover 当生产路径需要自动或操作员控制的恢复时。API 自动化仍是第二层：使用 Restreams API 配方 执行服务器端分发，并使用 SRT Servers API 配方 控制贡献和故障切换。
