比较职责与播放器要求
可沟通 HLS、HTTP-FLV、RTMP 与 WebRTC 交付，实际格式、编解码器、鉴权和运行限制需要与项目方案一致。下表描述常见协议特性，不是服务等级保证。
| 协议 | 常见用途 | 接入前检查 |
|---|---|---|
| HLS | 基于 HTTP 的观众播放与 CDN 分发 | 原生支持或兼容播放器、编解码器、分片、签名链接及缓存行为 |
| HTTP-FLV | 向兼容播放系统提供 HTTP 流 | 适用播放器或封装转换、浏览器媒体能力、编解码器及跨域策略 |
| RTMP | 将直播源推送到接收服务器 | 接收凭据和后续转换；不是现代浏览器的直接播放方式 |
| WebRTC | 交互或低延迟播放链路 | 信令、ICE 连通性、STUN/TURN 需求及分发容量 |
测量延迟，不凭协议名称判断
端到端延迟包括采集、编码、封装、网络交付和播放器缓冲。HLS 分片时长与低延迟扩展影响其中一部分。WebRTC 可在合适条件下降低延迟，但仅凭名称不能证明具体结果。
使用已知源时间参考，在目标设备观察实际画面，记录网络、地区、设备、播放器版本、观察时长、典型延迟与高分位延迟。约定可以测量的验收指标，而不是承诺零延迟。
从终端与编解码器出发
列出实际支持的浏览器、移动系统、内嵌 WebView 和原生 App。支持某个容器格式不等于支持其中的编解码器。音频和视频都需要测试，并覆盖过期、重连和前后台切换。
不要将 RTMP 地址放入 HTML video 元素就期待其工作。HTTP-FLV 通常也需要兼容的播放实现。确定接入路径前应选择维护中的播放器并进行验证。
区分信号接收与观众分发
一路信号可能只向你的服务器交付一次，再由你的 CDN 服务众多观众。明确由谁负责封装、源站、转码、分发和出口费用，分别估算同时交付的流与同时观看的人数。
除正常播放外，还应检查接收地址不可用、分片请求被拒绝、WebRTC 连接失败或 URL 过期等故障路径。确认备用方案、是否保持同一赛事，以及播放器如何取得新凭据。