2、推流链路拆解：从采集到播放的完整链路
做流媒体诊断这么多年，我见过太多人一卡顿就盯着「网络」猛查。其实很多时候，问题出在链路里的某个不起眼环节。你想想看，一个视频从摄像头到你手机屏幕，中间要经过多少道工序？
我习惯把这条链路拆成九个节点：采集 → 编码 → 封装 → 推流 → 转码 → 分发 → 拉流 → 解码 → 渲染。任何一个节点出问题，用户看到的就是转圈、花屏、音画不同步。
核心认知：卡顿不是单一原因造成的。链路越长，排查范围越大。但只要你把每个节点的「输入」和「输出」搞清楚，定位问题就是时间问题。
2.1 采集：一切从这里开始
采集是源头。摄像头、麦克风、屏幕录制、甚至是一个本地文件，都是采集的输入。我见过最离谱的卡顿，居然是采集端的USB带宽不够——摄像头帧率设了60fps，但USB 2.0只能跑到30fps。
采集阶段的核心参数就三个：
- 分辨率：1080p、4K、8K。越高越吃带宽和算力。
- 帧率：24fps、30fps、60fps。帧率越高，运动画面越流畅。
- 像素格式：NV12、I420、RGB24。直接影响编码器输入。
我的习惯：采集分辨率不要超过编码器支持的最大输入。比如有些硬件编码器只支持到1080p，你硬上4K采集，编码器会降采样，反而增加延迟。
2.2 编码：压缩的艺术
原始视频数据量巨大。一帧1080p的NV12图像大约3MB，30fps就是90MB/s。不压缩，网络根本扛不住。
编码器把原始图像压缩成H.264、H.265、AV1等码流。压缩比通常在50:1到200:1之间。但压缩是有代价的——计算开销和画质损失。
编码阶段最容易出问题的点：
- 码率控制：CBR（恒定码率）还是VBR（可变码率）？直播场景我建议CBR，码率波动小，不容易卡顿。
- GOP结构：关键帧间隔。太长会导致开播慢、seek慢；太短会浪费码率。
- 编码预设：ultrafast、fast、medium、slow。越快CPU开销越低，但压缩率也低。
我曾经踩过的坑：有一次线上直播卡顿严重，查了半天发现是编码器预设设成了"placebo"。编码器把CPU吃满了，帧率直接掉到10fps。直播场景用"veryfast"或"faster"就够了，别追求极致压缩。
2.3 封装：把视频和音频装进容器
编码后的视频流和音频流是分开的。封装就是把它们打包成一个文件或流。常见的封装格式有FLV、MP4、TS、MKV。
直播场景最常用的是FLV和TS。为什么？
| 封装格式 | 优点 | 缺点 | 典型场景 |
|---|---|---|---|
| FLV | 结构简单，延迟低，支持RTMP | 不支持索引，seek困难 | RTMP推流、HTTP-FLV播放 |
| TS | 抗丢包，支持HLS分片 | 头部开销大 | HLS直播、广电传输 |
| MP4 | 兼容性好，支持seek | moov box在尾部，不适合直播 | 点播、录播 |
封装阶段要注意音视频时间戳的对齐。如果音频和视频的PTS（显示时间戳）不同步，播放端就会出现音画不同步。我见过一个案例，采集端音频采样率设了44100Hz，但封装时写成了48000Hz，结果播放器按错误速率解码，声音越跑越偏。
2.4 推流：把数据送上网络
推流是推流端最关键的环节。封装好的数据通过传输协议（RTMP、SRT、RIST、WebRTC）发送到服务器。
推流阶段的核心指标：
- 推流码率：不能超过上行带宽的70%。否则会丢包、重传、卡顿。
- 推流协议：RTMP延迟高但兼容性好；SRT抗丢包；WebRTC延迟最低。
- 推流缓冲区：缓冲区越大，抗网络抖动能力越强，但延迟也越大。
避坑指南：推流端不要用TCP长连接裸推。网络抖动时TCP会重传，导致累积延迟。我建议用SRT或WebRTC，它们有内置的丢包重传和拥塞控制。
2.5 转码：服务端的重头戏
服务器收到推流后，通常不会直接分发。因为用户设备千差万别——有人用4K电视，有人用手机2G网络。转码就是把原始流转换成多种码率、分辨率、编码格式的版本。
转码阶段常见的卡顿原因：
- 转码集群负载过高：CPU/GPU打满，转码速度跟不上推流速度。
- 转码参数不匹配：比如源流是60fps，转码输出设了30fps，但帧率转换算法太糙，导致画面卡顿感。
- GOP对齐问题：多码率输出时，关键帧不对齐，播放器切换码率时会花屏。
我的建议：转码集群一定要做监控。我习惯监控三个指标：转码延迟（从输入到输出）、转码队列深度、CPU/GPU利用率。任何一个指标异常，都要立刻告警。
2.6 分发：CDN的使命
转码后的流通过CDN分发到全球各地。CDN的核心能力是就近服务——用户从最近的边缘节点拉流，减少跨网延迟。
分发阶段的卡顿原因：
- CDN节点回源带宽不足：边缘节点从源站拉流时，源站带宽被打满。
- CDN节点间缓存不一致：用户在不同节点间切换时，出现断流或重复数据。
- 跨运营商问题：电信用户拉联通CDN节点，延迟和丢包率都会上升。
2.7 拉流：播放端的第一步
播放器从CDN拉取流数据。拉流协议决定了延迟和兼容性：
| 拉流协议 | 延迟 | 兼容性 | 适用场景 |
|---|---|---|---|
| HTTP-FLV | 2-5秒 | 好（浏览器+播放器） | Web直播 |
| HLS | 6-30秒 | 极好（几乎所有设备） | 移动端、OTT |
| WebRTC | 0.2-1秒 | 一般（需浏览器支持） | 实时互动 |
| RTMP | 1-3秒 | 差（Flash已淘汰） | 推流为主 |
拉流阶段最容易出问题的是缓冲区策略。缓冲区太小，网络抖动就卡；缓冲区太大，延迟就高。我见过一个播放器把缓冲区设了10秒，用户看体育直播，进球了10秒后才看到——这体验谁受得了？
2.8 解码：把压缩数据还原成图像
拉流拿到的是压缩后的码流。解码器把它还原成YUV或RGB图像。解码阶段对设备性能要求很高——4K 60fps的H.265解码，手机解码器如果没硬件加速，CPU直接拉满。
解码卡顿的典型原因：
- 解码器不支持：比如设备只支持H.264硬解，但流是H.265，只能用软解，帧率暴跌。
- 解码器缓冲区溢出：码流到达速度超过解码速度，缓冲区满后丢帧。
- 参考帧丢失：B帧和P帧依赖前面的I帧或P帧。如果I帧丢了，后面的帧都解不出来。
我曾经遇到的情况：某款低端手机播放H.265 1080p流时，解码器频繁丢帧。后来发现是解码器固件有bug，对高码率H.265支持不完善。解决方案是服务端转码时降级到H.264。
2.9 渲染：最后一公里
解码后的图像数据送到渲染器，最终显示在屏幕上。渲染阶段的问题往往被忽略，但它直接影响用户体验。
渲染卡顿的原因：
- 渲染帧率与显示刷新率不匹配：比如视频是24fps，屏幕是60Hz，渲染器需要做帧率转换，转换算法不好就会卡。
- 渲染线程被阻塞：UI线程在做其他耗时操作，导致渲染掉帧。
- SurfaceView/TextureView问题：Android上SurfaceView的渲染效率高于TextureView，但生命周期管理复杂。
我的经验：渲染阶段一定要做掉帧监控。我习惯在播放器SDK里埋点，统计每秒钟实际渲染的帧数。如果渲染帧率低于视频帧率的80%，就要告警。
2.10 链路总结：卡顿排查的黄金法则
整条链路走下来，你会发现每个节点都有独立的延迟和丢帧风险。卡顿排查的黄金法则是：逐段隔离，分段验证。
具体怎么做？
- 推流端自测：本地推流到本地服务器，看采集和编码是否正常。
- 服务端自测：用测试工具模拟推流，看转码和分发是否正常。
- 播放端自测：拉取本地文件或测试流，看解码和渲染是否正常。
- 端到端联测：全链路跑通，逐段打日志，对比每个节点的输入输出时间戳。