视频是一帧一帧播放的，音频也是一帧一帧(20ms)播放的。播放器都是按照它们的每一帧的PTS来作为参考进行同步的。可以参考FFmpeg Tutorial

前置声明:当前代码分析版本为ijkplayer V0.7.5

---

本文需要3小节来描述清楚是如何同步的

• 第一节是 描述清楚ijkplayer 整个线程模型 这个可以提供给大家一个高度的俯瞰效果。知道什么与什么进行同步
• 第二节是 具体描述是怎么样进行同步的
• 第三节是 描述 MediaCodec configure Surface 的时候进行渲染的时候
  程序获取不到解码后的数据是如何做到进行同步的。前一篇博文有一些描述MediaCodec API 运用的知识点。

---

第一节

先来理清一下ijkplayer 的线程模型

JAVA 端调用 prepareAsync 开启了

• 消息队列线程 ijkmp_msg_loop(ff_msg_loop)
• 视频渲染线程 video_refresh_thread(ff_vout)
• 数据解复用线程 read_thread(ff_read)

解复用线程里 read_thread 开启：

• 音频渲染线程 aout_thread(ff_aout_android)
• 音频解码线程 audio_thread(ff_audio_dec)
• 视频解码线程 video_thread(ff_video_dec)

ijkplayer是如果硬件解码器打开失败，则会自动切换至软解。大家需要注意的一点不是硬解失败就自动转到软解，是硬解解码器打开失败，才会自动切换至软解且只有一次机会。
如果配置为硬解解码则 视频解码线程video_thread 中将会在创建一个辅助 MediaCodec input线程用于向MediaCodec 中输入数据。

• 硬解数据输入线程 enqueue_thread_func(amediacodec_input_thread)

备注:

ijkplayer V0.7.9.1+ 版本中已经添加单线程选项mediacodec decode by single thread

---

第二节

线程模型已经整理清楚了，接下来就是分析是如何同步的。
音视频同步基本是所有的播放器都是以音频PTS为参考时间。原因如下：

• 音频是由硬件驱动按照采样率播放，相对来说比较简单，不需要程序做额外调整且漂移误差较小。
• 如果音频参考其它时间进行同步的话，进行加速或者减慢或者等待都会立刻反应到人的感知中。视频帧影响就非常小了，一帧图片丢弃或者重复都不会造成影响。

不错播放器一般可以自主选择以哪一个时间做为参考基准

• 外部时间
• 音频时间
• 视频时间

我们这里只分析以音频为基准进行同步。一般首先想到就是：
比较时间戳然后视频太慢了就立刻播放，视频太快了就延时播放
看起来是不是很简单呢，事实上实际同步算法确实如上所述那样简单。只不过由于其它影响的因子没有如此的理想化

其实音视频同步里面需要用到的是3个时间线
1、音频播放的时间线
2、视频播放的时间线
3、本地单调增长的时间线 用于记录2次到达同一个代码点流逝的时间

• av_gettime_relative 获取当前时间，以微妙为单位。这个函数获取的当前时间是从系统（电脑/手机）启动算起的，而不是1970年1月1日0点0分。
• av_gettime 获取的时间是从1970年1月1日0点0分开始的。也是以微妙为单位。

理论上我有参考音频时间戳不就行了吗，为何还需要一个。其实因为视频播放线程不是高优先级,很容易出现 Sleep 唤醒误差或者因cpu资源卡顿一下，统计这个时间为了在同步的时候计入这个时间。

这里提醒一下音频播放线程一定要设置高优先级，不然很容易出现卡顿的声音的现象，大家可以试一试。

现在已经很清楚明了，可以阅读一下音视频同步核心实现函数:

• static void video_refresh(FFPlayer *opaque, double *remaining_time)
• static double compute_target_delay(FFPlayer *ffp, double delay, VideoState *is)

同步音视频算法大致以下3步
1、首先计算当前将要显示视频帧的 duration 如下：

last_duration = vp_duration(is, lastvp, vp);

2、然后根据参照音频时间戳计算当前将要显示帧需要多少delay时间然后显示
delay = compute_target_delay(ffp, last_duration, is);

3、最后引用本地单调增长的时间线来计算真正需要av_usleep多长时间再来显示

是不是过程很简单呢。我们再来探索一下每一步的具体实现。

我们看一下下面这个字段：

is->frame_timer

每当视频开始播放或者seek 后都重现初始化为 就是将要显示第一帧时间

is->frame_timer = av_gettime_relative() / 1000000.0;

经过 compute_target_delay 计算得到当前帧需要delay的时间是多少，然后进行累加

is->frame_timer += delay;

到此软解情况下音视频同步算法描述完毕。接下来介绍一下硬解情况下的同步机制

第三节

描述 MediaCodec configure Surface 进行渲染时同步机制实现。
ijkplayer 有2种类型的队列，一个是av_packet queue 一个是av_frame queue.前者保存解码前的数据，后者保存解码后的数据。问题出现了，MediaCodec 拿不到解码后的数据。那岂不是av_frame queue 队列里没有视频数据。怎么进行同步呢？其实想到聪明的人这里肯定想到一个相关的问题是
软解的时候就算后台播放音频但实际上视频还是进行解码的，av_frame queue队列还是有真实的视频帧数据的。如果硬解时后台播放是需要销毁MediaCodec 的 这样更不可能有视频数据且什么都没有了怎么同步？硬解前后台切换一些问题可以参考（Android 播放器硬解前后台切换黑屏问题）

其实大家只要抓住一个关键点就是我们是用时间戳同步的,并不是视频帧数据与音频帧数据来进行同步的。不过硬解驱动播放音频自己是按照音频帧数据来自我同步的。

首先直接告诉大家大致的实现机制是：
ijkplayer 播放器硬解的时候是用不包含解码后的视频帧数据的 av_frame queue.只不过保存的时候mediacodec 解码后的缓冲区索引ID和时间PTS。

硬解的时候后台的时候是如何同步的呢？

其实ijkplayer 内部创建了一个MediaCodecDummy 虚拟硬件解码器 用来模拟。只不过这个时候没有任何解码数据，只有PTS 等基本数据用于音视频同步。