1. 推流卡顿与音频同步排查指南：课程介绍与整体排查思路
大家好，我是你们这趟排查之旅的向导。做流媒体这行十几年了，我见过太多因为卡顿和音画不同步被用户骂到崩溃的案例。说实话，这两个问题就像流媒体世界的「牛皮癣」——看着不大，但特别顽固。
这门课，就是要把这些「牛皮癣」一个个抠干净。咱们不扯虚的，直接上干货。
这门课到底讲什么？
说白了，就是两件事：推流卡顿和音频同步。但你别小看这两件事，它们背后牵扯的东西可多了。
- 推流卡顿：画面一帧一帧地跳，声音断断续续，用户直接关掉直播。
- 音频同步：嘴型和声音对不上，看个视频像看译制片，体验极差。
我个人习惯把这两个问题放在一起讲，因为它们经常「狼狈为奸」。卡顿往往会导致音画不同步，而音画不同步又会让卡顿显得更明显。你想想看，是不是这个理？
我的排查「三板斧」
遇到问题别慌，先稳住。我总结了一套排查思路，咱们叫它「三板斧」吧。
- 先看现象，再定范围：是全局卡顿还是局部卡顿？是所有用户都不同步，还是只有特定设备出问题？
- 从端到端，逐段排查：从采集、编码、推流、传输到播放，每一段都可能出问题。别一上来就怀疑服务器，先看看自己家的网。
- 抓关键指标，用数据说话：别靠感觉。丢包率、抖动、延迟、帧率、码率，这些数字会告诉你真相。
核心原则：先定位，后优化。不要在没有定位清楚问题之前，盲目调整参数。我曾经见过一个团队，因为卡顿把编码码率从 4Mbps 降到 1Mbps，结果画面糊成马赛克，卡顿反而更严重了——因为解码器在低码率下反而更容易出错。
一张图看懂排查流程
下面这张图，是我自己画的排查总纲。每次遇到问题，我都会先过一遍这张图，心里就有底了。
一个小技巧：当你拿到一个卡顿反馈时，先问自己三个问题：
- 是推流端卡，还是播放端卡？
- 是持续卡顿，还是周期性卡顿？
- 是只有音频卡，还是只有视频卡？
这三个问题问完，排查范围至少缩小一半。
排查工具包：我常用的几样东西
工欲善其事，必先利其器。下面这些工具，是我排查时的「老伙计」。
| 工具/命令 | 用途 | 我常用的场景 |
|---|---|---|
ffprobe |
分析媒体文件/流的详细信息 | 检查时间戳、编码参数、流信息 |
tcpdump / Wireshark |
抓包分析网络传输 | 看丢包、重传、RTT 抖动 |
ffplay |
快速播放测试 | 验证本地播放是否正常，排除播放器问题 |
stats (推流端 SDK 内部) |
获取编码、推流实时指标 | 看编码帧率、发送缓冲区水位 |
Chrome DevTools (WebRTC) |
查看 WebRTC 内部统计 | 看 ICE、丢包、jitter buffer 状态 |
注意：千万不要在线上环境直接抓包，尤其是高并发场景。我曾经有一次在高峰期抓包，结果 tcpdump 把磁盘写满了，导致推流中断。血的教训啊！
排查前的准备工作
在开始动手之前，先把这几样东西准备好，能省你不少时间。
- 日志系统：推流端和播放端的日志必须能对应上。我习惯在每条日志里加一个
session_id，这样能快速关联两端。 - 指标监控：至少要有 CPU、内存、网络 IO、磁盘 IO 的实时曲线。很多卡顿其实是机器资源不够导致的。
- 复现环境：如果可能，尽量在测试环境复现。线上环境变量太多，容易干扰判断。
嗯，准备工作做足了，后面排查起来才会顺手。这门课接下来的 29 章，我会带着大家把每一个环节都拆开揉碎了讲。从网络传输到编码器配置，从时间戳管理到播放器缓冲策略，咱们一个一个过。
准备好了吗？咱们开始吧。