视频是一帧一帧播放的，音频也是一帧一帧(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 等基本数据用于音视频同步。
