本文是 《直播疑难杂症排查》系列的第五篇文章,我们重点来看看直播中常见的音画不同步问题。


1. 音画不同步的表现


很容易判断,就是画面和声音不匹配。


2. 音画同步的基础概念


首先我们要明白一个概念,虽然人的肉眼,很容易辨别音画是否同步的,但是机器则不然,对于播放器而言,它判断一帧视频和一帧音频是否要在同一个时间渲染和播放,依靠的完全是该数据携带的时间戳信息。


如果内容的生产端给音视频数据打的时间戳本身就有问题的话,播放器也往往无能为力了,因此,音画不同步问题,更多的时候,应该从生产端去排查原因。


3. 音画不同步的问题排查


3.1 采集源距离太远


如果音频源离麦克风距离太远,声音传播到麦克风的速度远小于画面(光速),那么,摄像头采集到画面后给出的时间戳,肯定要远小于麦克风采集到同一时刻音频给出的时间戳,因此会产生音画不同步问题。


解决方案:音频源尽可能离麦克风设备近一点。


3.2 采集设备内部问题


摄像头和麦克风采集音视频,在硬件上都会经过一些信号处理模块,如果处理延时不稳定的时候,则会导致输出数据的时间不稳定,从而导致应用层获取时间戳的时候产生误差,带来音画不同步问题。


解决方案:极少数硬件/机型才会有,需要根据采集参数(如采样率)做一些 Jitter 抖动的矫正。


3.3 时间戳没有在采集的时候获取 


如果音视频帧的时间戳不是在采集的时候获取,而是在后续的某个环节再获取,则非常大概率地会出现音视频不同步问题。


先举个简单的例子:


假设音频 A 和 视频 B 同时从设备中被采集出来,时间戳为:TA 和 TB,他们差值会很小,播放端收到后会认为是同一时刻的音视频数据,从而一起播放。


但是,当 音频 A 和 视频 B 分别经过某些算法处理模块后,我们 “不慎” 在处理后重新获取当前时间戳为了 TA2 和 TB2,那么,这个更新后的时间戳差值可能会非常大,导致音画不同步。


那么,一般大家会 “不慎” 在哪些地方更改了采集的时间戳呢 ?


- 音视频算法处理模块


比如:视频经过美颜、编码后,重新更新为了处理后的的时间戳。


- 缓冲区导致的不同步


多线程程序中,往往会在不同线程之间共享一些帧缓冲区,缓冲区会导致音视频对应关系发生变化,如果从缓冲区取数据后,抛弃掉了原有的时间戳,重新使用新的当前时间,那么,肯定会出现问题。


- 网络传输导致的不同步


由于网络的传输的延时、丢包等原因,同一时刻的音视频包不会正好同时准确到达,如果在接收到了数据后再打上当前的时间戳,则肯定也会出现不同步问题。


3.4 时间戳出现回退或者紊乱


曾经有遇到过一些音画不同步的流,我把它的音视频时间戳打印出来后显示如下的结果:


wKioL1ka_C6BW2NCAAIWJyjJMK0738.png

该码流的时间戳没有单调递增,而是频繁出现了回退,这样的流,会导致播放器出现频繁卡顿,因为播放器的 master 主时钟一般是单调递增的,当出现小于主时钟的视频帧后,一般会做丢弃处理,画面不更新但是音频还是在继续播放,从而导致看起来声音和画面并没有匹配上的问题。 


解决方案:排查推流端时间戳是否单调线性递增,或者排查服务端是否有对流的时间戳有过修改导致回退。


为了方便以后更好地定位该问题,大家可以修改 ffplay 源码,把读取到的每一帧音频、视频的时间戳打印出来看看,这里我给出我对 ffplay 的修改 commit 记录,大家可以参考一下:


https://github.com/Jhuster/pili-ffmpeg/commit/4d0476faba5016b291c2eed2c0a2cd6fe303bd50


3.5 播放端性能问题


比如低端机型软解 1080P 的高清码流,会存在解码不够及时的问题,导致部分视频解码完成后,已经远慢于当前的音频时钟,只能丢弃,从而导致画面更新不及时,与正在播放的音频无法匹配上,从而产生音画不同步的现象。


解决方案:使用硬解,选择较低清的码流,增大播放缓冲,等等。


4. 小结


关于播放出现音画不同步的问题排查大致就介绍道这里了,有任何疑问欢迎来信 lujun.hust@gmail.com 交流,另外,欢迎关注我的新浪微博 @卢_俊 或者 微信公众号 @Jhuster 获取最新的文章和资讯。

wKiom1ka_D_g737YAACb8XAe6Uo375.jpg