Android5.1视频解码过程分析(三)

Android5.1视频解码过程分析(三)
接着上篇部分分析;

1,onOMXFillBufferDone中的处理,实际是解码组建完成了解码操作,并且将解码数据放入到送入的输出buffer中了,该方法被调用,通知ACodec继续相应的处理;

2,分析过程记录下MediaCodec和ACodec的消息机制,在ACodec中经常看到通过notify发送消息,如notify->post();
notify是什么呢,我们在这行代码可看到sp<AMessage> notify = mCodec->mNotify->dup();那mNotify又来自哪里呢,来自setNotificationMessage方法传入,该方法由MediaCodec调用,mCodec->setNotificationMessage(new AMessage(kWhatCodecNotify, id()));因此在ACodec中用notify发送的消息就在MediaCodec中接受到了。
    大家可以注意到在通过notify发送消息时设置了notify->setInt32("what", CodecBase::kWhatDrainThisBuffer);这个what实际不是msg.what只是一个携带数据,不过也会在接受数据是用于判断,实际的msg.what就是在setNotificationMessage时new AMessage时传入的kWhatCodecNotify

3,继续分析onOMXFillBufferDone函数,主要围绕outPut buffer做了一些工作,然后通过上面2提到的方法发送了消息给MediaCodec,设置waht:notify->setInt32("what", CodecBase::kWhatDrainThisBuffer);

4,这里大多分析是过程的分析,其中为了理清楚过程会分析下原理;因此在一个函数调用中先只分析主要的流程;接下来MediaCodec收到kWhatDrainThisBuffer消息后调用了onOutputBufferAvailable();在该方法中又出现一个对象sp<AMessage> msg = mCallback->dup();解码过程这样设计我认为主要解决高并发运行问题,但是这各种callback各种消息给分析带来了很多不便,不是好的设计,估计后面会该;这个mCallBack来自哪里呢,来自setCallback()函数,这个函数由MediaCodecSource调用且传入callcack对象;因此在MediaCodec中调用的该mCallback相关的都直接到MediaCodecSource找就可以;在onOutPutBufferAvaliable()方法中对mCallback发送消息时设置了msg->setInt32("callbackID", CB_OUTPUT_AVAILABLE);------mCallback实际是Amessage类型;在接受消息的时候筛选callcackID就可找到接受的处理过程。

5,在MediaCodecSource中找到else if (cbID == MediaCodec::CB_OUTPUT_AVAILABLE) {查看处理过程,在这里调用了mEncoder->releaseOutputBuffer(index);mEncoder是MediaCodec对象,这里我很困惑,看名字为什么是编码?不是在解码吗?还有他们接下来的调用不再同一个对象里?先留下;主要注意下参数index;

6,回到MediaCodec查看releaseOutputBuffer函数,一些消息调用等之后走到了onReleaseOutputBuffer()函数,这个函数同样得到刚才的index,根据index得到bufer数据,接下来就是送去渲染显示,
        if (mSoftRenderer != NULL) {
            mSoftRenderer->render(info->mData->data(), info->mData->size(),
                    timestampNs, NULL, info->mFormat);
        }
这是软件实现方式;
发布了6 篇原创文章 · 获赞 2 · 访问量 1万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览