本文是 《直播疑难杂症排查》系列的第五篇文章，我们重点来看看直播中常见的音画不同步问题。
1. 音画不同步的表现
很容易判断，就是画面和声音不匹配。
2. 音画同步的基础概念
首先我们要明白一个概念，虽然人的肉眼，很容易辨别音画是否同步的，但是机器则不然，对于播放器而言，它判断一帧视频和一帧音频是否要在同一个时间渲染和播放，依靠的完全是该数据携带的时间戳信息。
如果内容的生产端给音视频数据打的时间戳本身就有问题的话，播放器也往往无能为力了，因此，音画不同步问题，更多的时候，应该从生产端去排查原因。
3. 音画不同步的问题排查
3.1 采集源距离太远
如果音频源离麦克风距离太远，声音传播到麦克风的速度远小于画面（光速），那么，摄像头采集到画面后给出的时间戳，肯定要远小于麦克风采集到同一时刻音频给出的时间戳，因此会产生音画不同步问题。
解决方案：音频源尽可能离麦克风设备近一点。
3.2 采集设备内部问题
摄像头和麦克风采集音视频，在硬件上都会经过一些信号处理模块，如果处理延时不稳定的时候，则会导致输出数据的时间不稳定，从而导致应用层获取时间戳的时候产生误差，带来音画不同步问题。
解决方案：极少数硬件/机型才会有，需要根据采集参数（如采样率）做一些 Jitter 抖动的矫正。
3.3 时间戳没有在采集的时候获取
如果音视频帧的时间戳不是在采集的时候获取，而是在后续的某个环节再获取，则非常大概率地会出现音视频不同步问题。
先举个简单的例子：
假设音频 A 和 视频 B 同时从设备中被采集出来，时间戳为：TA 和 TB，他们差值会很小，播放端收到后会认为是同一时刻的音视频数据，从而一起播放。
但是，当 音频 A 和 视频 B 分别经过某些算法处理模块后，我们 “不慎” 在处理后重新获取当前时间戳为了 TA2 和 TB2，那么，这个更新后的时间戳差值可能会非常大，导致音画不同步。
那么，一般大家会 “不慎” 在哪些地方更改了采集的时间戳呢 ？
- 音视频算法处理模块
比如：视频经过美颜、编码后，重新更新为了处理后的的时间戳。
- 缓冲区导致的不同步
多线程程序中，往往会在不同线程之间共享一些帧缓冲区，缓冲区会导致音视频对应关系发生变化，如果从缓冲区取数据后，抛弃掉了原有的时间戳，重新使用新的当前时间，那么，肯定会出现问题。
- 网络传输导致的不同步
由于网络的传输的延时、丢包等原因，同一时刻的音视频包不会正好同时准确到达，如果在接收到了数据后再打上当前的时间戳，则肯定也会出现不同步问题。
3.4 时间戳出现回退或者紊乱
曾经有遇到过一些音画不同步的流，我把它的音视频时间戳打印出来后显示如下的结果：
该码流的时间戳没有单调递增，而是频繁出现了回退，这样的流，会导致播放器出现频繁卡顿，因为播放器的 master 主时钟一般是单调递增的，当出现小于主时钟的视频帧后，一般会做丢弃处理，画面不更新但是音频还是在继续播放，从而导致看起来声音和画面并没有匹配上的问题。
解决方案：排查推流端时间戳是否单调线性递增，或者排查服务端是否有对流的时间戳有过修改导致回退。
为了方便以后更好地定位该问题，大家可以修改 ffplay 源码，把读取到的每一帧音频、视频的时间戳打印出来看看，这里我给出我对 ffplay 的修改 commit 记录，大家可以参考一下：
https://github.com/Jhuster/pili-ffmpeg/commit/4d0476faba5016b291c2eed2c0a2cd6fe303bd50
3.5 播放端性能问题
比如低端机型软解 1080P 的高清码流，会存在解码不够及时的问题，导致部分视频解码完成后，已经远慢于当前的音频时钟，只能丢弃，从而导致画面更新不及时，与正在播放的音频无法匹配上，从而产生音画不同步的现象。
解决方案：使用硬解，选择较低清的码流，增大播放缓冲，等等。
4. 小结
关于播放出现音画不同步的问题排查大致就介绍道这里了，有任何疑问欢迎来信 lujun.hust@gmail.com 交流，另外，欢迎关注我的新浪微博 @卢_俊 或者 微信公众号 @Jhuster 获取最新的文章和资讯。
本文出自 “Jhuster的专栏” 博客，请务必保留此出处http://ticktick.blog.51cto.com/823160/1926436
原文地址：http://ticktick.blog.51cto.com/823160/1926436
