转载请把头部出处链接和尾部二维码一起转载，本文出自逆流的鱼yuiop：http://blog.csdn.net/hejjunlin/article/details/52560012
前言：上篇文中最后介绍了数据解码放到Buffer过程，今天分析的是stagefright框架中音视频输出过程：
先看下今天的Agenda:
- 一张图回顾数据处理过程
- 视频渲染器构建过程
- 音频数据到Buffer过程
- AudioPlayer在AwesomePlayer运行过程
- 音视频同步
- 音视频输出
- 一张图看音视频输出
一张图回顾数据处理过程
视频渲染器构建过程
在构造时，new AweSomeEvent时，就开始把AwesomePlayer把onVideoEvent注入进去。
以上代码最会调用initRenderer_l函数
从上面代码来看：AwesomeRemoteRenderer的本质由OMX::createRenderer会先建立一个hardware renderer就是：mVideoRenderer =
new AwesomeNativeWindowRenderer(mNativeWindow, rotationDegrees);若失败，则建立new AwesomeLocalRenderer(mNativeWindow, format);
接下来看下：
而另一个AwesomeLocalRenderer在构造时new SoftwareRenderer(nativeWindow)
AwesomeLocalRender的本质上是由OMX:createRenderer，createRenderer会建立一个渲染器。如果video decoder是software component，则建立一个AwesomeLocalRenderer作为mVideoRenderer
AwesomeLocalRenderer的constructor会呼叫本身的init函数，其所做的事和OMX::createRenderer一模一样。可以理解为把read的数据显示在渲染器中。
渲染器渲染出画面后，我们可能会想，MediaExtractor把音视频进行分开，那音频呢？谁来让他们保持同步的呢？
音频数据到Buffer过程
无论是音频也好，还是视频，都是bufferdata,音频或视频总有一个来维持时间线的流。举个例子：我们看过双簧，一个人说话，一个人演示动作，动作快了不行，话说快，动作跟不上也不行。中间在联系台词时，自然有一些停顿或暗号。在OpenCore中，设置了一个主clock，而audio和video就分别以此作为输出的依据。而在Stagefright中，audio的输出是透过callback函式来驱动，video则根据audio的timestamp来做同步。在这之前，我们得了解下音频相关playback过程：
Stagefright框架中，audio的部分是交由AudioPlayer来处理，它是在AwesomePlayer::play_l中被建立的。贴一段以前分析过的代码：只不过当时没有向AudioPlayer方向向下看
创建AudioPlayer
再接着看下startAudioPlayer_l函数，
接下来看下音频mAudioPlayer->start(true)的操作，上面的过程都是在AwesomePlayer中，接下来变到AudioPlayer.cpp类中：
这里首先要介绍一下mAudioSink ，当mAudioSink不为NULL的时候，AudioPlayer会将其传入构造函数。
而且AudioPlayer中的播放操作都会依考mAudioSink来完成。
此处mAudioSink是从MediaPlayerService注册而来的AudioOut对象。具体代码在MediaPlayerservice中
间接地调用到stagefrightplayer->setAudioSink，最终到awesomeplayer中，如下:
而构造AudioPlayer时用到的就是mAudioSink成员，因此后面分析传入的mAudioSink的操作时，记住实际的对象为AudioOut对象，在MediaPlayerService定义。
本文出自逆流的鱼yuiop：http://blog.csdn.net/hejjunlin/article/details/52560012
AudioPlayer在AwesomePlayer运行过程
下面看AudioPlayer构造函数
主要是进行初始化，并将传入的mAudioSink存在成员mAudioSink中
再回到上面的start函数中
总结如下：
- 调用mSource->read 启动解码，解码第一帧相当于启动了解码循环
- 获取音频参数：采样率、声道数、以及量化位数（这里只支持PCM_16_BIT）
- 启动输出：这里若mAudioSink非空，则启动mAudioSink进行输出，否则构造一个AudioTrack进行音频输出，这里AudioTrack是比较底层的接口 AudioOut是AudioTrack的封装。
- 在start方法中主要是调用mAudioSink进行工作，主要代码如下:
刚介绍过mAudioSink是AudioOut对象，看下实际的实现（代码在mediaplayerservice.cpp中）
首先mAudioSink->open 需要注意的是传入的参数中有个函数指针 AudioPlayer::AudioSinkCallback ，其主要作用就是audioout播放pcm的时候会定期调用此回调函数填充数据，具体实现如下
以上代码总结为：
- 1、处理传入的参数，回调函数保存在mCallback中， cookie代表的是AudioPlayer对象指针类型，接下来是根据采样率声道数等计算 frameCount。
- 2、构造AudioTrack对象，并且赋值给t
- 3、将audiotrack对象存储在mTrack成员中
当以上过程完成后，继续分析AudioPlayer.start函数时，最后都会实例化一个AudioTrack对象，然后获取帧大小，比特等信息，然后调用mAudioTrack.start，最后到达mediaplayerservice音频输出start函数。
调用mTrack->start，audiotrack启动后就会周期性的调用 回调函数从解码器获取数据.
本文出自逆流的鱼yuiop：http://blog.csdn.net/hejjunlin/article/details/52560012
音视频同步
回到我们前面的问题：音视频如何同步？通过fillBuffer，不断填充buffer。
代码如下：
以上代码总结为：当callback函数回调AudioPlayer读取解码后的数据时，AudioPlayer会取得两个时间戳：mPositionTimeMediaUs和mPositionTimeRealUs,mPositionTimeMediaUs是数据里面所持有的时间戳(timestamp)；mPositionTimeRealUs则是播放此数据的实际时间(依据frame number及sample rate得出)。
以上代码总结为：
- 在构造audioplayer的时候会执行mTimeSource = mAudioPlayer,
即将AudioPlayer作为参考时钟， - 上述代码中成员变量mSeekTimeUs是由如下语句获得：CHECK(mVideoBuffer->meta_data()->findInt64(kKeyTime, &timeUs));
- realTimeOffset = getRealTimeUsLocked() - mPositionTimeRealUs; 当显示画面是第一帧时，表示当前的audio的播放时间与第一帧video的时间差值
- 其中变量是通过mAudioPlayer->getMediaTimeMapping( int64_t *realtime_us, int64_t *mediatime_us) {
Mutex::Autolock autoLock(mLock)得到
二者的差值表示这一包pcm数据已经播放了多少。Stagefright中的video便依据从AudioPlayer得出来之两个时间戳的差值，作为播放的依据
音视频输出
最后回到本文开头的onVideoEvent方法中，
这样最终音视频数据通过渲染器就到Surface显示画面，就可看到视频和听到声音了。
本文出自逆流的鱼yuiop：http://blog.csdn.net/hejjunlin/article/details/52560012
一张图看音视频输出
第一时间获得博客更新提醒，以及更多android干货，源码分析，欢迎关注我的微信公众号，扫一扫下方二维码或者长按识别二维码，即可关注。
如果你觉得好，随手点赞，也是对笔者的肯定，也可以分享此公众号给你更多的人，原创不易