1、推流卡顿全景分析：卡顿现象分类、卡顿影响面评估、推流链路全景图
做流媒体这么多年，我见过最多的线上问题就是卡顿。说实话，卡顿这东西，你光看日志很难定位。用户说「卡」，但到底是画面不动、声音断断续续、还是音画不同步？这里面的门道可不少。
这一章，我们先从全局视角把卡顿这件事拆清楚。我个人习惯是：先分类，再评估影响面，最后画链路图。这样后面排查时，你心里就有谱了。
1.1 卡顿现象分类
卡顿不是一种病，是多种症状的集合。我把它分成三类，你对照着看：
| 分类 | 现象描述 | 用户感知 | 常见根因 |
|---|---|---|---|
| 画面冻结 | 视频画面卡住不动，但音频可能还在播放 | 画面像截图一样，几秒后突然跳帧 | 编码器过载、网络丢包、接收端解码跟不上 |
| 音频断续 | 声音出现杂音、断流、或者完全静音 | 说话像机器人，或者突然没声 | 音频采样率不匹配、网络抖动、缓冲区溢出 |
| 音画不同步 | 口型对不上，画面比声音快或慢 | 看直播像看译制片，非常出戏 | 时间戳错乱、音视频流分离、接收端缓冲策略问题 |
我的经验： 用户说「卡」，80% 是画面冻结。但如果你只盯着画面修，可能忽略了音频问题。我建议你让用户录屏，或者抓一段推流端的日志，先确认是哪一类。
1.2 卡顿影响面评估
卡顿的影响有多大？不能光凭感觉。我一般从三个维度来评估：
- 频率：每分钟卡几次？每次持续多久？
- 范围：是所有用户都卡，还是只有部分用户？是某个地区，还是某个运营商？
- 严重程度：是轻微卡顿（用户能忍），还是完全无法观看？
举个例子。我之前遇到一个项目，推流端在机房，接收端遍布全国。用户反馈卡顿，我一看监控：推流端 CPU 占用 95%，编码器频繁丢帧。但奇怪的是，只有南方地区的用户卡，北方用户正常。后来排查发现，是 CDN 节点在南方回源时，网络链路有 30% 的丢包。你看，影响面评估能帮你快速缩小范围。
影响面评估清单：
- 卡顿是偶发还是持续？
- 卡顿发生在推流端还是播放端？
- 卡顿是否与网络环境（WiFi/4G/5G）相关？
- 卡顿是否与设备型号或浏览器相关？
1.3 推流链路全景图
要排查卡顿，你得先知道数据是怎么走的。我画了一张推流链路全景图，你一看就明白。
这张图里，从采集到渲染，一共 7 个关键节点。每个节点都可能成为卡顿的瓶颈。我举个例子：
- 采集阶段：摄像头帧率不够，或者采集卡驱动有问题，导致原始数据就丢帧。
- 编码阶段：CPU 或 GPU 负载过高，编码器来不及处理，就会丢帧。嗯，这里要注意，软编比硬编更容易出现这个问题。
- 封装阶段：时间戳写错了，或者音视频交错不合理，接收端解码时就会出问题。
- 推流阶段：网络带宽不足、丢包率高、或者推流协议本身有缺陷（比如 RTMP 的 TCP 重传导致延迟）。
- 网络传输：CDN 节点故障、跨运营商链路拥堵、或者边缘节点缓存策略不当。
- 接收阶段：播放器缓冲策略太激进，或者解码器不支持某些编码参数。
- 渲染阶段：GPU 渲染能力不足，或者音频输出设备延迟过高。
避坑指南： 我曾经遇到一个案例，推流端一切正常，但播放端就是卡。排查了三天，最后发现是播放器的缓冲设置太小，只有 200ms。网络稍微抖动一下，缓冲区就空了。所以，卡顿不一定都是推流端的锅，接收端也要检查。
好了，这一章我们先把卡顿的分类、影响面评估和链路全景图理清了。后面每一章，我都会针对链路中的某个环节，深入讲解排查方法和优化技巧。你先把这张图记在脑子里，后面排查时，就知道该往哪个方向看了。