1. H265推流卡顿问题排查与解决：课程导论与整体排查思路
各位同行，咱们直接进入正题。
H265推流卡顿，这问题我这些年没少头疼。你想想看，明明H265压缩率更高，码率更低，按理说应该比H264更流畅才对。可实际线上跑起来，卡顿、花屏、延迟飙升，一个都不少。
为什么会这样？说白了，H265的计算复杂度比H264高了4到5倍。编码器吃CPU，解码器也吃CPU。一旦设备性能跟不上，或者参数没调对，卡顿就来了。
1.1 卡顿的本质：生产与消费的失衡
我习惯把推流系统比作一条流水线。采集、编码、封装、发送、传输、接收、解码、渲染，每个环节都在干活。
卡顿的本质就一句话：上游生产数据的速度，超过了下游消费数据的速度。
举个例子。编码器每秒产出60帧，但网络只能发30帧。或者网络发了30帧，但解码器只能解20帧。帧在缓冲区里越堆越多，延迟越来越大，最终播放器只能丢帧——卡顿就出现了。
核心排查原则：找到整条链路中吞吐能力最弱的那个环节。它决定了系统的上限。
1.2 整体排查思路：分层定位法
遇到卡顿，别一上来就调编码参数。我踩过这个坑。先分层，再定位，最后解决。
我把排查路径分成四层：
- 采集层：摄像头/屏幕捕获的帧率是否稳定？分辨率是否过高？
- 编码层：编码器负载是否打满？预设、GOP、码率控制是否合理？
- 传输层：网络带宽够不够？丢包率、抖动、RTT是否在正常范围？
- 消费层：解码器是否支持H265硬解？渲染器是否丢帧？
每一层都有对应的排查工具和指标。下面这张图是我自己总结的排查框架，你可以照着它一步步走。
1.3 我的排查习惯：先看两端，再看中间
我个人习惯，遇到卡顿先做两件事：
- 看推流端CPU占用。如果编码器把CPU吃满了，那卡顿大概率是编码层的问题。
- 看播放端解码帧率。如果解码帧率远低于推流帧率，那问题在消费层。
这两步能帮你快速排除一半的可能性。剩下的，再深入传输层和采集层。
小技巧：在推流端用 ffmpeg -stats_period 1 实时观察编码帧率和丢帧数。如果丢帧数持续增长，说明编码器已经扛不住了。
1.4 常见卡顿类型速查表
我把这些年遇到的卡顿类型整理了一下。你可以对照症状，快速定位问题方向。
| 卡顿表现 | 可能原因 | 排查优先级 |
|---|---|---|
| 画面一卡一卡，但声音正常 | 编码器负载过高，帧率不稳定 | 高 |
| 画面突然花屏，然后恢复 | 网络丢包导致I帧丢失 | 高 |
| 延迟越来越大，最终卡死 | 发送缓冲区溢出，或接收端缓冲堆积 | 中 |
| 播放端CPU飙升，画面卡顿 | H265软解，设备不支持硬解 | 高 |
| 推流端CPU不高，但播放卡 | 网络带宽不足，或传输协议配置不当 | 中 |
1.5 避坑指南：我曾经踩过的坑
我曾经接手过一个项目，H265推流在手机上卡得不行。我调了三天编码参数，从preset ultrafast试到medium，码率从2M调到8M，都没用。
后来才发现，问题出在采集层。摄像头输出的分辨率是4K，编码器虽然能压，但手机的内存带宽根本扛不住4K的YUV数据搬运。把采集分辨率降到1080p，卡顿立刻消失。
注意：不要只盯着编码器。采集层的分辨率、帧率、像素格式，任何一个不匹配，都会导致整条链路出问题。尤其是H265，它对输入数据的质量更敏感。
1.6 本章小结
这一章我们理清了卡顿的本质——生产与消费的失衡。也建立了分层排查的思路：采集层、编码层、传输层、消费层，逐层定位。
后面的章节，我会带你深入每一层，讲具体的排查工具、参数调优和实战案例。嗯，咱们一步步来。