第 7 章
基础
建议 13 分钟直播如何到达观众:编码与传输全链路
26 / 42 节
本节学习目标
- 梳理从 PGM 信号到观众手机播放的完整技术链路
- 理解编码、推流、转码、CDN 分发各环节的作用
- 区分直播延迟、卡顿、清晰度问题分别出在哪个环节
导播台 PGM 输出的是体积巨大的原始视频,不可能直接通过网络传给成千上万观众。它要经过“压缩—上传—再分发—解码播放”一条流水线。看懂这条链路,你才知道出了问题该查哪一段。
一条直播流的旅程
- PGM 信号:导播台 / 软件输出的最终画面和声音
- 编码:压缩成 H.264/H.265 等格式并打包(编码 + 封装)
- 推流:通过 RTMP/SRT 等协议上传到直播平台入口
- 平台转码:云端生成多种清晰度(蓝光/高清/标清)
- CDN 分发:通过内容分发网络就近送到各地观众
- 解码播放:观众手机 / 电脑解码并缓冲播放
关键概念逐个讲
- 编码(Encode):用 H.264(AVC)/H.265(HEVC)等标准把视频大幅压缩。当前直播推流兼容性最好的是 H.264 + AAC(音频)。
- 封装(Container):把视频、音频打包在一起,直播常见 FLV(RTMP)、MPEG-TS(SRT)。
- 推流(Push):把本地编码好的流主动推送到平台“推流地址”。
- 转码(Transcode):平台在云端把你推的一路码率转成多路清晰度,适配不同网速的观众。
- CDN:把流缓存 / 分发到离观众最近的节点,解决大量并发观看和跨地域卡顿。
问题定位:卡、糊、延迟各查哪一段
| 观众反馈 | 可能环节 | 排查方向 |
|---|---|---|
| 所有人都卡 / 频繁缓冲 | 推流上行不足或不稳 | 查现场上行带宽、码率、推流编码器状态 |
| 部分地区 / 部分人卡 | CDN 节点或观众网络 | 平台侧分发或观众本地网络,换网络 / 设备验证 |
| 画面马赛克、运动糊 | 推流码率不足 / 编码参数 | 提高码率、降低分辨率帧率、检查关键帧设置 |
| 延迟很大 | 平台 / 播放器缓冲、协议 | 属正常网络延迟;需要低延迟选 SRT / 低延迟方案 |
| 所有人都看不到 | 推流中断或地址密钥错误 | 查编码器是否在线、推流地址密钥、平台状态 |
你能掌控的是“推上去之前”
转码、CDN、观众网络你控制不了,你能 100% 掌控的是:编码参数合理、上行带宽充足、推流稳定、本地有录制。把这段做到极致,剩下的交给平台,并提前与平台技术 / 网络确认。
开播前的链路验证
提前 15–30 分钟推流后,除了在后台看“正在直播”,一定要用真实手机用 4G/5G(不连现场 WiFi)打开直播地址验证画面和声音——这能同时检验上行、平台转码和最终播放全链路。
上线链路自查
已完成 0 / 50%
新手最容易踩的坑
!
只看编码器“推流中”就放心
编码器在推不代表观众能看。地址、密钥、平台转码任一环节出错都可能“假推流”,必须端到端用手机验证。
!
把观众端卡顿都怪平台
大面积卡顿先查自己的上行。现场上行带宽不足是直播卡顿的首要原因。
本节要点
- 链路:PGM → 编码封装 → 推流 → 平台转码 → CDN → 观众解码。
- 推流端主流用 H.264 + AAC;你真正能掌控的是“推上去之前”的质量。
- 卡顿分清“全卡查上行、部分卡查分发、马赛克查码率、看不到查推流连接”。
课后动手 / 思考
- 下次直播记录下编码器显示的推流码率、丢帧 / 丢包数据和平台后台状态,建立自己的“推流健康记录”。