6.1 传输协议：RTMP、HLS、SRT 的取舍
6.1 传输协议：RTMP、HLS、SRT 的取舍
本节摘要：流媒体协议按「延迟 vs 兼容性」分成几派。本节讲清 RTMP、HLS、SRT、WebRTC 四类的出身、延迟量级与适用场景，给出一套「按场景选协议」的判断框架，并指出各协议在 FFmpeg 里的写法。
本节目标：阅读完本节，你应当能够：
- 说出四类协议的延迟量级与传输方式
- 解释 HLS 为什么延迟高、RTMP 为什么被用作推流入站
- 根据「延迟敏感 vs 兼容优先」场景选择协议
一、一段历史：每个协议都是时代的产物
流媒体协议不是设计竞赛，而是「网络条件 + 终端生态」逼出来的产物：
- RTMP：2002 年 Adobe 为 Flash 直播而造。直播需要「推流」这个动作——把画面实时送给服务器，RTMP 是当时最顺手的推流协议。Flash 死掉了，但「推流」的需求还活着，于是 RTMP 作为推流入站协议活到今天。
- HLS：2009 年苹果为点播而生，把视频切成 6–10 秒的 TS 小片，配一个 m3u8 索引文件。播放器一个个拉片，天然支持自适应码率。但「切片 + 分段拉取」注定延迟高（通常 10–30 秒）。
- SRT：2017 年前后为「公网直播」而来，基于 UDP 但自带丢包重传，专治跨公网丢包导致的直播卡顿。
- WebRTC：浏览器实时通信标准，目标是把延迟压到亚秒级，用于连麦、视频会议。
二、核心原理：四类协议的解剖
| 协议 | 传输 | 典型延迟 | 强项 | 弱点 | 典型场景 |
|---|---|---|---|---|---|
| RTMP | TCP 长连接 | 1–3 秒 | 推流成熟，生态完善 | 播放端浏览器不原生支持 | 直播推流入站 |
| HLS | HTTP（TCP） | 10–30 秒 | 兼容所有浏览器，天然 CDN 友好 | 延迟高 | 点播、大直播 |
| SRT | UDP + 重传 | 亚秒到 2 秒 | 抗丢包，穿越公网稳定 | 终端支持少 | 公网直播、传输 |
| WebRTC | UDP | <500ms | 极低延迟，浏览器原生 | 架构复杂 | 会议、连麦、低延迟直播 |
为什么 HLS 延迟高
HLS 的播放流程是「索引 → 拉片 → 缓冲 → 播」。服务端要等一个切片写完才能发布，播放器要攒够几个片才开始播，每层都是延迟。降低延迟的办法是缩短切片（如 2 秒）并用 LL-HLS（低延迟 HLS），但依然降不到 RTMP 的量级。要低延迟，就得换协议。
RTMP 的定位反转
RTMP 在「播放端」已经失势（浏览器不认），但「推流端」几乎还是它：直播平台普遍用 RTMP 接收入站流，再由服务器转成 HLS 或其他格式分发。所以 FFmpeg 里推流写 rtmp://，拉流播放反而少见直接用 RTMP。
三、工程实践要点
FFmpeg 里各协议长什么样
# 推流到 RTMP 服务器 ffmpeg -re -i input.mp4 -c copy -f flv rtmp://server/live/stream_key # 拉取 HLS 流 ffmpeg -i https://example.com/live/index.m3u8 -c copy output.mp4 # 拉取 RTSP（监控常用） ffmpeg -i rtsp://user:pass@camera_ip/stream -c copy output.mp4
注意：RTMP 在 FFmpeg 里封装器写 flv（因为 RTMP 承载的是 FLV 封装），地址才是 rtmp://。
选型判断框架
问三个问题：
- 延迟敏感吗？ 会议、连麦、体育直播 → 追求低延迟（SRT/WebRTC）；普通点播 → HLS 完全够
- 终端是什么？ 浏览器为主 → HLS（原生播放）；推流设备 → RTMP（生态成熟）
- 网络可靠吗？ 跨公网、易丢包 → SRT 的 UDP 重传更稳；机房内网 → 随便选
用一张图把「延迟 vs 兼容」的坐标画出来：
图说明：坐标定位
图上 RTMP 偏左（兼容性窄，但延迟不高）、HLS 靠右（兼容性无敌、延迟高）、SRT 在左上（低延迟抗丢包但终端支持有限）、WebRTC 在中上（延迟最低但架构复杂）。看需求落在哪个象限，协议就清楚了。
常见坑：浏览器里直接播 RTMP 是不行的；HLS 的分片大小决定延迟与启动速度的平衡，别为了「低延迟」把切片切得太碎，反而增加服务器压力；SRT 需要双方都支持，公网传输前先确认对端能不能接。
💡 关键直觉：协议是「延迟、兼容、成本」三者的交换。没有全能的协议，选型第一步永远是把需求量化——延迟容忍几秒、终端有哪些、网络靠不靠谱。
延迟的组成：为什么不是「一个数字」
协议标称的延迟是一个范围，因为端到端延迟由四段组成：采集延迟（摄像头/采集卡的处理时间）、编码延迟（编码器攒帧和 B 帧引入的延迟）、传输延迟（网络 RTT 加上缓冲）、播放缓冲延迟（播放器为了平滑故意攒的数据）。我们常说的「RTMP 延迟 1–3 秒」，其实大部分花在编码和播放缓冲上，而不是网络上。
# 用 ffmpeg 压测一下自己环境的基础延迟构成：编码端用 zerolatency ffmpeg -re -i input.mp4 -c:v libx264 -tune zerolatency -f flv rtmp://127.0.0.1:1935/live/t
-tune zerolatency 砍掉了 B 帧和编码缓冲，编码延迟立刻降下来。实测你会发现延迟改善明显——这证明编码延迟占比不小。同理，播放端 -fflags nobuffer 砍掉播放缓冲，又是一段延迟的消失。想优化延迟，先分清是「哪一段在拖后腿」，比盲目换协议高效得多。
本节要点回顾
- 四类协议：RTMP 推流入站、HLS 点播分发、SRT 公网抗丢包、WebRTC 亚秒级会议
- HLS 延迟成因：切片 + 分段拉取 + 缓冲，延迟天生高，低延迟要换协议
- RTMP 反转：播放端失势、推流端仍是事实标准，FFmpeg 里配合
-f flv - 选型三问：延迟敏感？终端是谁？网络可靠？答案组合决定协议
- RTSP 别忘：监控领域 RTSP 无处不在，第 9 章会大量用到
下一节把协议落地成命令——推流与拉流的完整实操。