04. 直播链路与协议
直播不是“把一个视频文件发出去”。摄像头持续产生帧，推流端编码后把媒体送到入口，源站负责鉴权、转协议、录制和分发，观众端再按自己的协议拉取并播放。CDN 可以把源站压力分散到边缘节点，但缓存和分片也会增加延迟。
端到端延迟从哪里来
一次画面从传感器到屏幕，可能经过曝光、ISP、颜色转换、编码队列、网络传输、服务端缓冲、解码队列和显示刷新。每一层都应记录时间戳或可关联的帧编号。只把播放器缓冲设置为 0，并不能消除编码和网络等待。
推流端需要观察编码耗时、关键帧间隔和发送队列；源站需要观察接入等待、转协议队列和观众连接；拉流端需要观察首帧时间、缓冲深度、丢包和解码耗时。延迟异常时，先确定增长发生在哪个队列。
协议怎样分工
| 协议或机制 | 方向与特点 | 常见场景 | 主要代价 |
|---|---|---|---|
| RTMP | 常用于推流，连接和服务端生态成熟 | 摄像头或编码器推到直播入口 | 浏览器不能直接播放，通常要由服务端转协议 |
| HTTP-FLV | HTTP 持续传输 FLV 数据 | 兼容现有直播播放器的低延迟拉流 | 依赖长连接和播放器支持，缓存策略较敏感 |
| HLS | m3u8 加 TS/fMP4 分片，主要用于拉流 | 公网分发、点播和 CDN | 分片与缓存带来额外延迟 |
| RTSP/RTP | RTSP 控制会话，RTP 承载媒体 | IP 摄像头、局域网监控 | 浏览器支持弱，RTP 可走 UDP 或交错 TCP |
| WebRTC | ICE、DTLS、SRTP 与 RTCP 组成的实时技术栈 | 浏览器低延迟双向互动 | 需要信令、STUN/TURN、带宽和 NAT 处理 |
协议名称不能直接推出传输方式。例如 RTSP 媒体可以用 RTP over UDP，也可以交错在 TCP 连接中；是否使用 UDP 要看会话协商和网络环境。
从局域网开始验证
先用一台摄像头和一个播放器建立局域网 RTSP 链路，确认编码器、时间戳和网络没有问题，再加入公网入口、鉴权和 CDN。文件模拟推流可以帮助复现服务端路径，但 -re 只是按输入时间戳限速，不等于真实摄像头采集。
bash
ffplay -rtsp_transport tcp rtsp://CAMERA_IP/stream公网方案要额外验收：断网重连、关键帧恢复、观众突增、源站切换、鉴权失败、CDN 缓存和播放器回退。监控系统应区分“推流连接还在”和“观众已经看到最新画面”。
协议选择的失败条件
- 追求低延迟却保留过长 GOP 和播放器缓存，换协议不会自动解决。
- 只验证服务器端口开放，没有验证浏览器、NAT、TURN 和实际 UDP 流量。
- 把 HLS 当成单文件上传，忽略 m3u8、分片、MIME、Range 和缓存一致性。
- 用 HTTP 200 证明 WebRTC 或 RTSP 可播放，却没有验证解码、首帧和持续播放。
下一篇用 FFmpeg 和 GStreamer 把文件、摄像头和硬件编码链路逐步验证出来。