多是全网最全的移动直播 trouble shooting 手册（5）——音画不一样步

时间 2019-11-30

原文原文链接

在七牛作直播 SDK 一年多了，帮助客户解决过各类形形色色的问题，如直播卡顿、马赛克、花屏、黑屏、杂音、音画不一样步等等等等，这其中，有一些是网络缘由，有一些是客户的使用姿式问题，有一些是参数配置错误，固然，也有一些是 SDK 自己的问题。git

总结下来，若是开发者可以对直播领域的一些基础知识有更深刻的了解，掌握一些基本的排障手段，不少问题是可以很快自行解决的，甚至也可以更好地防患于未然。github

所以，有了这个系列，我想把这一年多以来，帮助咱们的直播客户排查问题的实战经验逐步分享出来，同时也会穿插一些音视频开发的基础知识和优化经验，真心但愿可以帮助到直播领域的开发者们。算法

本系列会涵盖的内容包括但不限于以下一些主题：微信

本文是 《直播疑难杂症排查》系列的第五篇文章，咱们重点看下直播中常见的音画不一样步问题。网络

音画不一样步的表现

很容易判断，就是画面和声音不匹配。多线程

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

若是内容的生产端给音视频数据打的时间戳自己就有问题的话，播放器也每每无能为力了，所以，音画不一样步问题，更多的时候，应该从生产端去排查缘由。优化

致使音画不一样步的因素有不少，如下是直播实战中常常遇到的问题的整理。编码

若是音频源离麦克风距离太远，声音传播到麦克风的速度远小于画面（光速），那么，摄像头采集到画面后给出的时间戳，确定要远小于麦克风采集到同一时刻音频给出的时间戳，所以会产生音画不一样步问题。线程

解决方案：音频源尽量离麦克风设备近一点。

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

解决方案：极少数硬件/机型才会有，须要根据采集参数（如采样率）作一些 Jitter 抖动的矫正。

若是音视频帧的时间戳不是在采集的时候获取，而是在后续的某个环节再获取，则很是大几率地会出现音视频不一样步问题。

先举个简单的例子：
假设音频 A 和视频 B 同时从设备中被采集出来，时间戳为：TA 和 TB，他们差值会很小，播放端收到后会认为是同一时刻的音视频数据，从而一块儿播放。

可是，当音频 A 和视频 B 分别通过某些算法处理模块后，咱们不慎在处理后从新获取当前时间戳为了 TA2 和 TB2，那么，这个更新后的时间戳差值可能会很是大，致使音画不一样步。

那么，通常你们会「不慎」在哪些地方更改了采集的时间戳呢？

1.视频算法处理模块

好比：视频通过美颜、编码后，从新更新为了处理后的的时间戳。

2.缓冲区致使的不一样步

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

3.网络传输致使的不一样步

因为网络的传输的延时、丢包等缘由，同一时刻的音视频包不会正好同时准确到达，若是在接收到了数据后再打上当前的时间戳，确定也会出现不一样步问题。

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

该码流的时间戳没有单调递增，而是频繁出现了回退，这样的流，会致使播放器出现频繁卡顿，由于播放器的 master 主时钟通常是单调递增的，当出现小于主时钟的视频帧后，通常会作丢弃处理，画面不更新可是音频仍是在继续播放，从而致使看起来声音和画面并无匹配上的问题。

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

为了方便之后更好地定位该问题，你们能够修改 ffplay 源码，把读取到的每一帧音频、视频的时间戳打印出来看看，这里我给出我对 ffplay 的修改 commit 记录，你们能够参考一下：github.com/Jhuster/pil…

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

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

关于播放出现音画不一样步的问题排查大体就介绍到这里了，下篇咱们将对马赛克严重这个话题进行探讨。