1、推流卡顿全景：什么是推流卡顿？卡顿的几种典型表现

做直播推流这么多年，我见过太多“画面卡成PPT”的现场了。说实话，推流卡顿这个问题，几乎每个做直播的团队都会遇到。你想想看，观众点进来，结果画面不动了，或者声音对不上嘴，那体验感直接归零。

那到底什么是推流卡顿？我个人习惯把它定义为：推流端采集、编码、传输过程中，数据流出现异常中断或延迟，导致播放端无法连续、同步地还原音视频内容的现象。说白了，就是数据没按时到达，或者到了但没法正常解码。

1.1 卡顿的几种典型表现

卡顿不是只有一种样子。我在项目中遇到过各种各样的“翻车现场”，总结下来，主要有四种典型表现。嗯，这里我列个表，方便你对照排查。

表现类型	现象描述	用户感知	常见根因
花屏	画面出现马赛克、色块、绿屏、撕裂	画面局部或整体无法辨认	编码参数错误、丢包导致参考帧损坏、解码器不兼容
音画不同步	声音和画面错位，嘴型对不上	听觉与视觉信息冲突，极度不适	时间戳错乱、音频/视频编码延迟不一致、缓冲策略差异
缓冲（加载中）	播放器频繁显示“加载中”或转圈	观看中断，等待时间不可控	推流端码率过高、网络带宽不足、播放器缓冲水位设置不合理
断流	直播突然中断，画面黑屏或停止	完全无法观看，需要重新连接	推流端崩溃、网络断开、CDN回源失败、推流认证过期

1.2 花屏：画面“碎”了

花屏是最直观的卡顿表现。我记得有一次帮一个游戏直播团队排查问题，主播那边画面正常，但观众看到的全是绿色马赛克。当时我第一反应就是——编码器或者传输链路出问题了。

花屏的成因主要有几个：

• 编码参数设置不当：比如关键帧间隔（GOP）太大，或者码率控制模式选错了，导致编码器在某些场景下“算不过来”。
• 网络丢包导致参考帧损坏：H.264/H.265这类编码依赖帧间预测。如果I帧或P帧的参考数据丢了，后续的B帧解码就会出错，画面直接花掉。
• 解码器兼容性问题：推流端用了高编码档次（如High Profile），但播放端解码器只支持Baseline，强行解码就会花屏。

1.3 音画不同步：嘴型对不上

音画不同步，说白了就是音频和视频的时间戳（PTS/DTS）没对齐。观众看到主播张嘴了，声音却隔了半秒才出来，或者声音先到画面后到。这种体验非常糟糕。

我个人的排查习惯是：先看推流端的日志，检查音视频时间戳的基准是否一致。很多推流SDK默认音频用麦克风时钟，视频用摄像头时钟，两个时钟源不同步，时间戳自然就歪了。

常见原因包括：

• 时间戳生成逻辑错误：音频和视频使用了不同的时钟源，或者时间戳计算时没有考虑起始偏移。
• 编码延迟差异：视频编码通常比音频编码耗时更长（尤其是B帧多的场景），如果不对音频做延迟补偿，音频就会比视频先到。
• 播放器缓冲策略：播放器对音视频分别缓冲，如果缓冲水位不一致，也会导致不同步。

1.4 缓冲：一直在“转圈”

缓冲是观众最常遇到的卡顿形式。画面突然停住，播放器开始转圈，几秒后恢复。为什么会这样？因为播放器接收数据的速度跟不上解码渲染的速度，缓冲区空了。

从推流端角度看，缓冲的根因通常是：

• 推流码率超过上行带宽：比如你设置了8Mbps的码率，但上行带宽只有4Mbps，数据自然发不出去。
• 网络抖动导致瞬时丢包：TCP重传会引入额外延迟，播放端收不到数据就只能缓冲。
• CDN节点回源延迟：如果用了CDN分发，边缘节点从源站拉流时网络不稳定，也会导致播放端缓冲。

1.5 断流：直播“断了”

断流是最严重的卡顿形式。直播突然中断，观众端黑屏，需要重新连接才能继续观看。断流的原因往往比较“硬”：

• 推流端进程崩溃：编码器或推流程序异常退出，RTMP连接断开。
• 网络物理断开：网线被踢了、Wi-Fi信号丢失、4G/5G信号切换。
• 推流认证或超时：RTMP推流时，如果一段时间内没有发送数据，服务器会主动断开连接。
• CDN回源失败：源站挂了，或者回源链路中断，CDN节点拿不到流。

1.6 推流卡顿全景图

下面这张图，我把推流卡顿的四种表现、它们的根因以及排查方向串在了一起。你可以在实际工作中把它当作一个快速参考。

这张图把四种卡顿表现、它们的根因以及排查方向串在了一起。你可以在实际工作中把它当作一个快速参考。遇到卡顿问题，先看现象属于哪一类，然后顺着对应的根因去排查，效率会高很多。