一条直播流从摄像头到千万观众的完整链路
更新: 5/30/2026 字数: 0 字 时长: 0 分钟
适合读者：前端想补全链路认知、后端想了解直播全貌、新人入门。一条直播流从采集摄像头到千万观众的完整链路。
如果是 WebRTC 全链路低延迟方案，总延迟可以压到 800ms–1.5s，代价是 CDN 成本模型完全换一套（见第七节）。
一、采集：数据从哪里来
采集是把光信号和声信号变成数字流的过程。主要有三种路径：
1.1 PC 端：OBS 系
- 典型工具：OBS Studio、vMix、XSplit。
- 核心能力：多路输入合成（摄像头 + 屏幕 + 游戏窗口 + 图片/视频素材）、场景切换、音频混音。
- 输出形式：直接编码后推流（RTMP/SRT/WHIP），或输出 NDI/虚拟摄像头给其它软件。
- 工程关注点：GPU 占用（NVENC/AMF/QSV 硬编）、音画同步、帧率锁定。
1.2 手机端：SDK 集成
- 主流 SDK：字节 VELive、声网、腾讯云 TRTC、即构 ZEGO 等。
- 采集链路：Camera API（Android Camera2 / iOS AVCaptureSession）+ AudioUnit → 美颜滤镜 → 编码器。
- 关键差异：手机 SDK 一般把采集/美颜/编码/推流打包成一个闭环，开发者只接业务 API。
- 踩坑点：各厂商摄像头硬件差异大，HDR/超广角/变焦的适配工作量大。
1.3 Web 端：getUserMedia / getDisplayMedia
- 能力边界：浏览器只能拿到原始
MediaStream，编码与推流要自己接 WebRTC。 - 典型场景：轻量主播、云导播、远程连麦，不追求极致画质。
- 限制：无法直接输出 RTMP（浏览器不支持 TCP 原始流），必须走 WebRTC → 服务端转 RTMP。
量化参考：1080p30 采集的原始 YUV420 数据率约 744 Mbps（1920×1080×1.5 字节×30 帧×8 bit）。不编码根本没法传，这就引出了下一环。
二、编码：压缩率的艺术
编码器的任务：把 744 Mbps 的原始流压到几 Mbps，同时让人眼看起来尽量没差别。
2.1 三大主流编码对比
| 编码 | 1080p30 典型码率 | 压缩比 | 硬件支持 | 专利/授权 |
|---|---|---|---|---|
| H.264 / AVC | 3–5 Mbps | 基准 | 全平台全硬解 | 成熟但有专利池（MPEG-LA） |
| H.265 / HEVC | 1.5–3 Mbps | 比 H.264 省 40–50% | 移动端普及、浏览器逐步跟上 | 专利复杂、Web 端采用慢 |
| AV1 | 1–2 Mbps | 比 H.265 再省 20–30% | 新机型硬解、编码器仍慢 | 免版税，开放联盟主推 |
| VP9 | 1.5–3 Mbps | ≈ H.265 | 浏览器生态好、移动端弱 | 免版税，YouTube 主用 |
2.2 几个关键参数
- GOP（Group of Pictures）：两个 I 帧的间隔。直播推荐 1–2 秒，太长首屏慢、断流恢复慢；太短压缩效率低。
- B 帧：双向预测帧，压缩率高但增加延迟（编码器要等后续帧）。低延迟直播一般关 B 帧。
- CBR vs VBR：CBR 恒定码率，CDN 友好；VBR 质量稳定但带宽抖动。直播主用 CBR。
- Profile / Level：H.264 的
baseline/main/high，越高压缩率越好但老设备可能不解。移动端兼容首选high profile level 4.0。
2.3 硬编 vs 软编
| 软编（x264/x265/SVT-AV1） | 硬编（NVENC/QSV/Android MediaCodec） | |
|---|---|---|
| 画质 | 同码率画质更好 | 略差（尤其是老一代硬编器） |
| CPU/GPU 占用 | CPU 高 | 几乎不占 CPU |
| 灵活性 | 参数多、可精调 | 固定档位 |
| 场景 | 服务端转码、OBS 高画质 | 手机/摄像头/低功耗 |
工程共识：采集端硬编（省电）+ 服务端转码软编（保质） 是大多数直播公司的配置。
2.4 延迟账单
- 采集 buffer：1–2 帧（≈ 33–66ms）；
- 编码 pipeline：2–5 帧（66–166ms，关 B 帧能降到 1 帧）；
- GOP 对齐（等下一个关键帧能被推出）：0–1s。
编码这一段典型 50–200ms。
三、推流：从主播到第一跳
编码器吐出 H.264/H.265/AV1 字节流，要通过推流协议把它打到机房。
3.1 四大推流协议对比
| 协议 | 传输层 | 延迟 | 抗弱网 | 成熟度 | 未来 |
|---|---|---|---|---|---|
| RTMP | TCP | 1–3s | 差（TCP 重传拖累） | 最成熟，Adobe 遗产 | 在被替代 |
| SRT | UDP + ARQ | 0.5–2s | 强（FEC + 自适应） | 广电/赛事主流 | 稳定增长 |
| RTP / WebRTC | UDP + SRTP | 200–800ms | 最强 | 互动场景主流 | 标准化中 |
| WHIP | HTTP + WebRTC | 200–800ms | 强 | 2022+ 落地 | RTMP 的接班人 |
3.2 为什么 RTMP 撑了这么多年
- 生态无敌：OBS、FFmpeg、FMS/Wowza/SRS/nginx-rtmp 全支持，几乎所有 CDN 都原生接 RTMP 推流；
- 简单可调：基于 TCP，NAT 友好，防火墙穿透成本低；
- 代价：TCP 在丢包场景退化严重，弱网下码率全靠推流端主动降。
3.3 SRT：赛事级替代
- 由 Haivision 开源，IETF 在标准化；
- 自带加密（AES）、ARQ（智能重传）、带宽估计；
- 广电/体育赛事远程制作（REMI）已经大面积切 SRT；
- OBS 原生支持，FFmpeg 也支持，生态在补齐。
3.4 WHIP：RTMP 的真正继任者
- 前文介绍过（见 WebRTC 文档第五节）：一次 HTTP POST 交换 SDP，之后走 WebRTC；
- 优势：延迟 1s 以内、UDP 原生、自带拥塞控制、复用 WebRTC 全套生态；
- 进度：OBS 30+、FFmpeg 7+、xgplayer、主流 CDN 都已支持或在支持路上；
- 预测：未来 3–5 年新建直播系统基本不会再选 RTMP。
3.5 延迟账单
- 三次握手 + TCP 慢启动（仅 RTMP）：100–500ms；
- 推流端 buffer（应对网络抖动）：500ms–2s；
- 传输到边缘机房：10–50ms（国内同区域）。
推流段典型 1–3s，SRT/WHIP 可压到 300ms 以内。
四、边缘接入：流的第一个港口
推流包到达云厂商/自建机房后，第一个处理节点叫 源站（Origin） 或 边缘接入节点（Edge Ingest）。这一层要做的事：
- 协议解析：识别 RTMP/SRT/WHIP，提取音视频 ES；
- 鉴权：检查推流 key、防盗链、黑名单；
- 录制 DVR：写一份到对象存储，供回看和合规审计；
- 审核：音视频抽帧送 AI 审核模型（涉黄涉暴涉政）；
- 分发触发：通知转码集群和 CDN 回源。
4.1 主流开源组件
| 组件 | 定位 | 擅长 | 语言 |
|---|---|---|---|
| SRS（Simple Realtime Server） | 全能直播服务器 | RTMP/HLS/WebRTC/SRT 全协议，国内主流自建方案 | C++ |
| ZLMediaKit | 低延迟流媒体服务器 | 轻量、多协议、嵌入式友好 | C++ |
| nginx-rtmp-module | nginx 扩展 | 经典老将，维护较少 | C |
| MediaMTX（原 rtsp-simple-server） | 多协议网关 | RTSP/RTMP/HLS/WebRTC/SRT/WHIP 全通吃 | Go |
| LiveKit | WebRTC SFU 平台 | WebRTC-first、K8s 原生、WHIP/WHEP 内置 | Go |
| Janus / mediasoup | WebRTC SFU | 会议/连麦场景，灵活性高 | C / Node.js |
选型心法：
- 传统直播（秀场/电商/游戏）→ SRS 或 ZLMediaKit：RTMP 接入 + HLS/FLV 分发，生态最全；
- 互动直播 / 会议 → LiveKit / mediasoup：WebRTC 原生；
- 多协议网关 / 小团队 → MediaMTX：Go 单二进制，部署极简；
- 云厂商托管 → 阿里云 VEStream、腾讯云 LVB、AWS IVS、火山引擎视频直播：省运维但贵。
4.2 成本量化
自建 SRS 集群（单机 16 核 32G，100Gbps 上行网卡）：
- 接入能力：单机 ~1000 路 1080p 推流；
- 成本：机器 ~2 万元/月，上行带宽成本另算（国内约 0.3–1 元/Mbps/月，按 95 计费）。
五、转码集群：一源多出
一路 1080p 原始推流，往往要转出多个版本：
1080p / 5Mbps ──► 高清画质
原始推流 (1080p) ──► 720p / 2.5Mbps ──► 标清（主力码率）
480p / 1Mbps ──► 流畅
360p / 500Kbps ──► 弱网兜底
音频单独抽一路 ──► 纯音频/省流5.1 转码要做什么
- 分辨率/码率阶梯（ABR 自适应码率源素材）；
- 封装转换：RTMP/FLV → HLS（TS/fMP4）→ DASH → LL-HLS 等；
- 编码转换：H.264 → H.265/AV1（按需）；
- 水印/贴图/字幕叠加；
- DRM 加密（版权内容）。
5.2 成本是大头
转码是整个链路里最烧 CPU/GPU 的环节。
- 软编 1080p 实时 H.264：单核 x86 吃满约 1 路；一台 32 核机器最多跑 20-30 路（留点冗余）；
- GPU 转码（NVIDIA T4/A10）：单卡能跑 20–40 路 1080p H.264；
- H.265 / AV1 编码成本分别是 H.264 的 2–5 倍、5–20 倍。
成本拍脑袋算账（自建）：
- 1 路 1080p + 3 档转码（720/480/360）：约需 4 路软编 = 0.2 核·小时；
- 100 万路并发直播：20 万核 转码算力 → 一个大机房；
- 云厂商转码一般 0.02–0.05 元/分钟/档，百万路级别一个月能花掉千万级。
优化方向：
- 按需转码：没人看的档位不转；
- 同源复用：同一条流被多个观众请求时只转一次；
- 智能 ABR：根据观看设备分布决定转哪些档位；
- 硬件加速：GPU / 专用编码卡（如 NETINT Quadra）。
5.3 延迟账单
转码器本身延迟 200ms–1s，主要看 GOP 对齐和 pipeline 深度。切片封装额外增加 1 个切片时长（标准 HLS 6s、LL-HLS 200ms）。
六、CDN 分发：规模化的根本
1 个源站对不了 100 万观众。CDN 的本质：把流缓存到离用户最近的节点。
6.1 CDN 的层级
源站（1 份）
│
▼
父层节点（几十个，回源源站）
│
▼
边缘节点（几千个，离用户最近）
│
▼
用户- 边缘节点命中：90% 以上请求，延迟 10–50ms；
- 回父层：几 %，延迟 50–200ms；
- 回源站：千分之几，延迟 100ms–1s。
6.2 HLS / FLV 分发
- HLS 对 CDN 最友好：m3u8 + ts/fmp4 本质就是 HTTP 静态文件，缓存命中率极高；
- FLV 是长连接：不能像 HLS 那样直接缓存，但 SRS 等可以用 GOP 缓存（缓存最近一个 GOP 用于新接入用户秒开）；
- LL-HLS：切片小（200ms），回源频次高，CDN 必须支持 HTTP/2 Push + Blocking Playlist Reload，老 CDN 跑不动。
6.3 WebRTC 的 "CDN"
WebRTC 没有传统 CDN，只能用 SFU 级联：
主播 ──► SFU-A（源）
│
┌────────┼────────┐
▼ ▼ ▼
SFU-B SFU-C SFU-D （边缘 SFU）
│ │ │
观众 观众 观众每个 SFU 都要解密 → 决策转发 → 再加密，单机成本远高于 HTTP CDN，因此 WebRTC 百万级直播价格是 HLS 的 5–10 倍。这是"低延迟 vs 成本"的终极权衡。
6.4 带宽成本量化
- 1 路 1080p HLS 观众：约 3 Mbps 下行；
- 100 万并发观众：3 Tbps；
- 国内 CDN 约 0.15–0.3 元/GB 或 20–50 元/Mbps/月（95 计费）；
- 100 万人看 1 小时：100 万 × 3 Mbps × 3600s / 8 = 1350 TB ≈ 20–40 万元。
这就是为什么直播公司的财报里"带宽成本"永远是前三大支出之一。
6.5 延迟账单
- CDN 缓存逻辑：HLS 一个切片时长（标准 6s，LL-HLS 1s 内）；
- 网络传输到用户：20–100ms；
- 客户端 Jitter Buffer：500ms–2s；
- 整个下行段 2–6s（HLS），< 1s（WebRTC）。
七、用户端：最后一公里
观众拉流的形态取决于终端：
| 终端 | 主流协议 | 播放器 |
|---|---|---|
| Web | HLS / LL-HLS / FLV / WebRTC | xgplayer、hls.js、flv.js、自研 |
| iOS | HLS 原生、WebRTC | AVPlayer、IJKPlayer、自研 SDK |
| Android | FLV / HLS / WebRTC | ExoPlayer、IJKPlayer、自研 SDK |
| 智能电视 / 机顶盒 | HLS / DASH | 原生、ExoPlayer |
| OTT / 海外 | DASH + HLS（DRM） | Shaka、ExoPlayer |
7.1 客户端做了什么
- 拉流：HTTP/UDP 请求；
- Demux：FLV/TS/fMP4 解封装；
- Decode：调用硬解或软解；
- AV Sync：音画同步，以音频时钟为基准；
- 渲染：视频上 GPU，音频交声卡；
- ABR：根据网络切换码率档位；
- QoS 上报：首屏耗时、卡顿率、码率切换事件。
7.2 体验关键指标
- 首屏耗时：<1s 顶级，1–2s 良好，>3s 差；
- 卡顿率：<0.5% 优秀，>2% 差；
- 百秒卡顿次数、延迟、分辨率切换频率。
八、端到端延迟账单（一张表）
| 环节 | 标准 HLS 直播 | HTTP-FLV 直播 | LL-HLS 直播 | WebRTC 直播 |
|---|---|---|---|---|
| 采集 + 编码 | 100ms | 100ms | 100ms | 100ms |
| 推流（RTMP/SRT/WHIP） | 1–2s | 1–2s | 1–2s | 300ms |
| 边缘接入 | 50ms | 50ms | 50ms | 50ms |
| 转码 + 切片 | 2–6s（6s 切片） | 500ms（不切片） | 500ms（CMAF） | 无切片 |
| CDN 分发 | 50ms | 50ms | 50ms | — |
| 客户端 buffer | 2–4s | 1–2s | 1–2s | 100–300ms |
| 端到端总延迟 | 10–30s | 2–5s | 2–4s | < 1s |
九、成本量化（以 100 万并发、1080p、1 小时直播为例）
| 成本项 | HLS 方案 | FLV+HLS 方案 | WebRTC 方案 |
|---|---|---|---|
| 源站/SFU 机器 | ~1 万元 | ~1.5 万元 | ~10–20 万元（SFU 集群） |
| 转码 | ~2 万元 | ~2 万元 | ~2 万元 |
| CDN 带宽 | 20–40 万元 | 25–45 万元（FLV 长连接命中率略低） | 150–300 万元（SFU 级联） |
| 存储（录制 DVR） | ~1 万元 | ~1 万元 | ~1 万元 |
| 合计 | 约 25–45 万元 | 约 30–50 万元 | 约 160–320 万元 |
结论：
- 延迟每降 1 个数量级，成本上升 5–10 倍；
- 真实业务都是混合架构：连麦互动走 WebRTC（少量人），观众走 HLS/FLV（海量人），综合成本最优。
十、关键组件一览
10.1 开源服务端
- SRS：国产全能王，RTMP/HLS/WebRTC/SRT 通吃，文档中文友好，适合从零自建；
- ZLMediaKit：低延迟、低资源占用，适合嵌入式和 CDN 边缘；
- MediaMTX：Go 单二进制，多协议网关，小团队救星；
- LiveKit：WebRTC SFU，K8s 原生，WHIP/WHEP 标准化；
- mediasoup：Node.js 驱动的 SFU 库，非整机方案，灵活集成；
- nginx-rtmp：老牌，维护一般，不建议新项目用；
- Janus：老牌 WebRTC 网关，C 实现，插件化。
10.2 客户端播放器
- Web：xgplayer（字节）、hls.js、flv.js、mpegts.js、shaka-player；
- Android/iOS：ExoPlayer、AVPlayer、ijkplayer（B 站开源，已停维护）、各云厂商 SDK；
- 跨端：VLC、mpv（偏桌面）。
10.3 云厂商托管
- 字节：视频直播、VELive、实时音视频 RTC；
- 阿里云：视频直播 Live、实时音视频 ARTC；
- 腾讯云：云直播 CSS、实时音视频 TRTC；
- AWS：IVS（Interactive Video Service）、Kinesis Video Streams；
- Cloudflare：Stream Live（WHIP/WHEP 原生）。
选型建议：
- 从 0 到 1 → 云厂商托管，最快；
- 规模起来了（月带宽成本 > 100 万）→ 自建 + 多云 CDN 混跑；
- 对延迟极端敏感（< 500ms）→ 必自建 WebRTC SFU 或深度合作。
十一、一条流的完整旅程（复盘）
时间 t=0s 主播摄像头采到一帧画面
时间 t=0.05s 编码器把它压成 H.264 NALU
时间 t=0.1s RTMP 包抵达字节机房边缘节点
时间 t=0.15s 鉴权通过，流入转码集群
时间 t=1s 转码出 720p/480p/360p 多档
时间 t=1.5s 切出第一个 LL-HLS 片段（200ms），推入 CDN
时间 t=2s 深圳边缘节点缓存命中
时间 t=2.1s 观众手机收到 http 响应，开始 demux
时间 t=2.5s 第一帧渲染到屏幕
——总计端到端延迟 ~2.5s（LL-HLS）
同一时刻：
杭州观众走 HLS 标准切片，看到的是 t=0s 的画面，延迟 ~10s
东南亚观众跨境 CDN，延迟 ~15s
坐在主播对面的连麦嘉宾走 WebRTC，延迟 200ms同一条直播流，不同观众看到的"现在"完全不同——这就是直播链路的残酷真实。
十二、给新人的 5 条经验
- 端到端思考：只懂前端或只懂后端都会被卡住，踩坑位置经常跨 3 个环节。
- 延迟是设计出来的，不是优化出来的：选错协议再怎么调参也压不下去。
- 成本是业务决策，不是技术问题：延迟从 10s 到 1s 成本翻 5 倍，老板要的到底是什么？
- 监控比优化重要：首屏、卡顿、RTT、丢包、码率切换，没数据就是黑盒。
- 拥抱标准：WHIP/WHEP、CMAF、LL-HLS 都在统一分裂的生态，早布局早受益。
结语
一条直播流从摄像头到千万观众，要跨越 7 个系统、5 个协议、3 层网络、2 种编码。每一环都有独立的优化空间，也有互相牵制的权衡。
把这张大图印在脑子里，下次遇到"直播卡了""延迟高了""成本超了"这类问题时，你能立刻知道：应该去哪一环打开抓包、看哪个组件的监控、找谁协作。
这就是全链路认知的价值——不一定让你成为某一环的专家，但能让你在复杂系统里不迷路。