CloverLHao的博客

已消耗该Buffer完成通知事件消息接收处理：NuPlayerDecoder接收的【kWhatRenderBuffer】已渲染Buffer完成事件应答消息备注：此时此处的已渲染Buffer指的是音频Buffer，而当该流程处理视频Buffer时视频帧却还未真正渲染，因此此流程就是处理视频帧渲染流程。因此看此处处理逻辑时，建议先看完上面音频处理流程和后面【4.2】小节的视频消耗渲染处理流程后，再来统一看此处处理。// [frameworks/av/media/libmediaplayerservice

承接上一章节分析：【六】Android MediaPlayer整体架构源码分析 -【start请求播放处理流程】【Part 12】【02】本系列文章分析的安卓源码版本：【Android 10.0 版本】推荐涉及到的知识点：Binder机制实现原理：Android C++底层Binder通信机制原理分析总结【通俗易懂】ALooper机制实现原理：Android native层媒体通信架构AHandler/ALooper机制实现源码分析Binder异常关闭监听：Android native层Death

承接上一章节分析：【六】Android MediaPlayer整体架构源码分析 -【start请求播放处理流程】【Part 12】【01】本系列文章分析的安卓源码版本：【Android 10.0 版本】推荐涉及到的知识点：Binder机制实现原理：Android C++底层Binder通信机制原理分析总结【通俗易懂】ALooper机制实现原理：Android native层媒体通信架构AHandler/ALooper机制实现源码分析Binder异常关闭监听：Android native层Death

承接上一章节分析：【六】Android MediaPlayer整体架构源码分析 -【start请求播放处理流程】【Part 10】本系列文章分析的安卓源码版本：【Android 10.0 版本】推荐涉及到的知识点：Binder机制实现原理：Android C++底层Binder通信机制原理分析总结【通俗易懂】ALooper机制实现原理：Android native层媒体通信架构AHandler/ALooper机制实现源码分析Binder异常关闭监听：Android native层DeathReci

onOutputFormatChanged()实现分析：回调输出数据格式改变通知处理流程，此处理过程比较重要，它将会在软音频解码器即非offload音频播放模式时触发AudioSink的open打开处理流程。它将会回调【CB_OUTPUT_FORMAT_CHANGED】事件消息给NuPlayerDecoder，最后发出【kWhatVideoSizeChanged】事件给NuPlayer通知上层APP。并可能也会更改AudioSink侧的audio配置// [frameworks/av/media/li

承接上一章节分析：【六】Android MediaPlayer整体架构源码分析 -【start请求播放处理流程】【Part 10】【01】本系列文章分析的安卓源码版本：【Android 10.0 版本】推荐涉及到的知识点：Binder机制实现原理：Android C++底层Binder通信机制原理分析总结【通俗易懂】ALooper机制实现原理：Android native层媒体通信架构AHandler/ALooper机制实现源码分析Binder异常关闭监听：Android native层Death

【六】Android MediaPlayer整体架构源码分析 -【start请求播放处理流程】【Part 8】推荐涉及到的知识点：Binder机制实现原理：Android C++底层Binder通信机制原理分析总结【通俗易懂】ALooper机制实现原理：Android native层媒体通信架构AHandler/ALooper机制实现源码分析Binder异常关闭监听：Android native层DeathRecipient对关联进程（如相关Service服务进程）异常关闭通知事件的监听实现源码分析

doRequestBuffers()实现分析：返回true时表示本次Buffer数据填充不足，因此必须请求填充更多数据备注：通过下面的分析可知，该方法会在fetchInputData执行时，若无解析数据Buffer时会进行线程wait，等待解析数据生产者端添加缓冲区队列后进行唤醒继续获取Buffer数据。也就是说对于NuPlayerDecoder中的线程可能会被此流程处理而阻塞。接下来关于GenericSource模块中的处理流程涉及早前流程已有分析时后续分析只会提醒一下，具体请参见前面prepare

承接上一章节分析：【六】Android MediaPlayer整体架构源码分析 -【start请求播放处理流程】【Part 8】【01】本系列文章分析的安卓源码版本：【Android 10.0 版本】推荐涉及到的知识点：Binder机制实现原理：Android C++底层Binder通信机制原理分析总结【通俗易懂】ALooper机制实现原理：Android native层媒体通信架构AHandler/ALooper机制实现源码分析Binder异常关闭监听：Android native层DeathR

onInputBufferFetched(msg)实现分析：输入Buffer获取请求// [frameworks/av/media/libmediaplayerservice/nuplayer/NuPlayerDecoder.cpp]bool NuPlayer::Decoder::onInputBufferFetched(const sp<AMessage> &msg) { if (mCodec == NULL) { ALOGE("[%s] onInputB

承接上一章节分析：【六】Android MediaPlayer整体架构源码分析 -【start请求播放处理流程】【Part 7】【02】本系列文章分析的安卓源码版本：【Android 10.0 版本】【此章节小节编号就接着上一章节排列】1.2.1、/* size_t index = */updateBuffers(kPortIndexInput, msg)实现分析：更新填充（输入或输出）Buffer// [frameworks/av/media/libstagefright/MediaCodec.

承接上一章节分析：【六】Android MediaPlayer整体架构源码分析 -【start请求播放处理流程】【Part 7】【01】本系列文章分析的安卓源码版本：【Android 10.0 版本】【此章节小节编号就接着上一章节排列】dequeueBufferFromNativeWindow()实现分析：// [frameworks/av/media/libstagefright/ACodec.cpp]ACodec::BufferInfo *ACodec::dequeueBufferFromNa

承接上一章节分析：【六】Android MediaPlayer整体架构源码分析 -【start请求播放处理流程】【Part 4】【03】本系列文章分析的安卓源码版本：【Android 10.0 版本】【此章节小节编号将重新排序】onOMXEvent()接收处理执行：前面小节已分析过该方法可以是BaseState父类状态的具体子类状态实现者进行重写，处理自身业务。但也会有默认父类该方法处理。而对于该方法的所有涉及到的该方法实现的状态实现，如下截图中从上面的实现可知，有这么多个状态实现了该方法，而目

承接上一章节分析：【六】Android MediaPlayer整体架构源码分析 -【start请求播放处理流程】【Part 3】【01】本系列文章分析的安卓源码版本：【Android 10.0 版本】【此章节小节编号就接着上一章节排列】10.1.1、new Decoder(notify, mSource, mPID, mUID, mRenderer, mSurface, mCCDecoder)实现分析：创建新的视频解码器。这几个参数前面章节已分析过。Decoder类声明：【省略其他代码】// [

承接上一章节分析：【六】Android MediaPlayer整体架构源码分析 -【start请求播放处理流程】【Part 6】【03】本系列文章分析的安卓源码版本：【Android 10.0 版本】【此章节小节编号就接着上一章节排列】6.1、setupRawAudioFormat(encoder ? kPortIndexInput : kPortIndexOutput, sampleRate, numChannels)实现分析：初始化原始音频格式（输入输出端口buffer格式）信息。备注：后续音

承接上一章节分析：【六】Android MediaPlayer整体架构源码分析 -【start请求播放处理流程】【Part 6】【02】本系列文章分析的安卓源码版本：【Android 10.0 版本】【此章节小节编号就接着上一章节排列】5.5.1.1、getColorConfigFromFormat(format, &range, &standard, &transfer)实现分析：其实就是获取视频原始格式中对应的配置信息// [frameworks/av/media/li

承接上一章节分析：【六】Android MediaPlayer整体架构源码分析 -【start请求播放处理流程】【Part 6】【01】本系列文章分析的安卓源码版本：【Android 10.0 版本】【此章节小节编号就接着上一章节排列】5.1、GetVideoCodingTypeFromMime(mime, &compressionFormat)实现分析：根据mime格式获取对应的OMX支持的视频编码类型枚举// [frameworks/av/media/libstagefright/AC

3、setPortMode(kPortIndexOutput, IOMX::kPortModeDynamicANWBuffer)实现分析：设置输出缓冲区buffer端口模式为 kPortModeDynamicANWBuffer 即会使用ANativeWindowBuffer来传递已解码输出数据。

承接上一章节分析：【六】Android MediaPlayer整体架构源码分析 -【start请求播放处理流程】【Part 5】【01】本系列文章分析的安卓源码版本：【Android 10.0 版本】【此章节小节编号就接着上一章节排列】1、setComponentRole(encoder /* isEncoder */, mime)实现分析：设置组件角色信息// [frameworks/av/media/libstagefright/ACodec.cpp]status_t ACodec::set

承接上一章节分析：【六】Android MediaPlayer整体架构源码分析 -【start请求播放处理流程】【Part 4】本系列文章分析的安卓源码版本：【Android 10.0 版本】【此章节小节编号将重新排序】mCodec->configureCodec(mime.c_str(), msg)实现分析：ACodec配置编解码器。【备注：该章节分析的该配置处理流程非常长】// [frameworks/av/media/libstagefright/ACodec.cpp]status_

承接上一章节分析：【六】Android MediaPlayer整体架构源码分析 -【start请求播放处理流程】【Part 4】【05】本系列文章分析的安卓源码版本：【Android 10.0 版本】【此章节小节编号就接着上一章节排列】8.3.2.4.2、useGraphicBuffer_l(portIndex, omxBuffer.mGraphicBuffer, buffer)实现分析：使用图形Buffer从下面方法上英文注释非常明确该方法的使用提示，它只是个向后兼容方法，一旦OMX实现改变，该

承接上一章节分析：【六】Android MediaPlayer整体架构源码分析 -【start请求播放处理流程】【Part 4】【04】本系列文章分析的安卓源码版本：【Android 10.0 版本】【此章节小节编号就接着上一章节排列】8.3.2.2、BufferInfo结构定义：缓冲区buffer信息结构定义，该结构非常重要，它将是编解码器工作时传递数据的载体。ACodec内部定义// [frameworks/av/media/libstagefright/include/media/stag

承接上一章节分析：【六】Android MediaPlayer整体架构源码分析 -【start请求播放处理流程】【Part 4】【03】本系列文章分析的安卓源码版本：【Android 10.0 版本】【此章节小节编号就接着上一章节排列】8.3、mCodec->changeState(mCodec->mLoadedToIdleState)实现分析：扭转状态机状态为IDLE状态机实现者，根据最开始状态机实现分析可知，将会执行该状态实现的进入方法备注：该流程和前面的8.2流程将会在8.2流程

承接上一章节分析：【六】Android MediaPlayer整体架构源码分析 -【start请求播放处理流程】【Part 4】【02】本系列文章分析的安卓源码版本：【Android 10.0 版本】【此章节小节编号就接着上一章节排列】8.2.1、handleMessage(*it)处理消息实现分析：OMXNodeInstance的该方法返回true才表明自身处理该事件类型备注：FILL_BUFFER_DONE该事件其实就是编解码器将指定buffer id的buffer（已编码或已解码）数据填充完

承接上一章节分析：【六】Android MediaPlayer整体架构源码分析 -【start请求播放处理流程】【Part 4】【01】本系列文章分析的安卓源码版本：【Android 10.0 版本】【此章节小节编号就接着上一章节排列】4、rememberCodecSpecificData(format)实现分析：读取缓存编解码器特殊数据，CSD其实对应Codec Specific Data的缩写。对于H.264来说，"csd-0"和"csd-1"分别对应sps和pps；对于AAC来说，"csd-

承接上一章节分析：【六】Android MediaPlayer整体架构源码分析 -【start请求播放处理流程】【Part 3】本系列文章分析的安卓源码版本：【Android 10.0 版本】【此章节小节编号将重新排列】onConfigure(format)实现分析：解码器配置工作，创建MediaCodec处理流程。// [frameworks/av/media/libmediaplayerservice/nuplayer/NuPlayerDecoder.cpp]...

承接上一章节分析：Android MediaPlayer整体架构源码分析 -【MediaCodec编解码器插件模块化注册和创建处理流程】【Part 7】【01】本系列文章分析的安卓源码版本：【Android 10.0 版本】推荐涉及到的知识点：Binder机制实现原理：Android C++底层Binder通信机制原理分析总结【通俗易懂】ALooper机制实现原理：Android native层媒体通信架构AHandler/ALooper机制实现源码分析Binder异常关闭监听：Android n

承接上一章节分析：Android MediaPlayer整体架构源码分析 -【MediaCodec编解码器插件模块化注册和创建处理流程】【Part 7】本系列文章分析的安卓源码版本：【Android 10.0 版本】推荐涉及到的知识点：Binder机制实现原理：Android C++底层Binder通信机制原理分析总结【通俗易懂】ALooper机制实现原理：Android native层媒体通信架构AHandler/ALooper机制实现源码分析Binder异常关闭监听：Android nativ

承接上一章节分析：Android MediaPlayer整体架构源码分析 -【MediaCodec编解码器插件模块化注册和创建处理流程】【Part 6】本系列文章分析的安卓源码版本：【Android 10.0 版本】推荐涉及到的知识点：Binder机制实现原理：Android C++底层Binder通信机制原理分析总结【通俗易懂】ALooper机制实现原理：Android native层媒体通信架构AHandler/ALooper机制实现源码分析Binder异常关闭监听：Android nativ

承接上一章节分析：Android MediaPlayer整体架构源码分析 -【MediaCodec编解码器插件模块化注册和创建处理流程】【Part 1】本系列文章分析的安卓源码版本：【Android 10.0 版本】推荐涉及到的知识点：Binder机制实现原理：Android C++底层Binder通信机制原理分析总结【通俗易懂】ALooper机制实现原理：Android native层媒体通信架构AHandler/ALooper机制实现源码分析Binder异常关闭监听：Android nativ

承接上一章节分析：Android MediaPlayer整体架构源码分析 -【MediaCodec编解码器插件模块化注册和创建处理流程】【Part 2-A】本系列文章分析的安卓源码版本：【Android 10.0 版本】推荐涉及到的知识点：Binder机制实现原理：Android C++底层Binder通信机制原理分析总结【通俗易懂】ALooper机制实现原理：Android native层媒体通信架构AHandler/ALooper机制实现源码分析Binder异常关闭监听：Android nat

分析sCodec2InfoBuilder的buildMediaCodecList(&writer)实现分析：读取编解码器配置信息并存入writer中返回。根据前面流程中的分析可知，它的实现是在Codec2InfoBuilder.cpp中，如下其实根据下面的实现，可以看到它的实现和前面已分析的另一个Builder实现类似的处理。// [frameworks/av/media/codec2/sfplugin/Codec2InfoBuilder.cpp]status_t Codec2InfoBu

OMX框架层插件化创建、注册和实现处理流程源码分析承接上一章节分析：Android MediaPlayer整体架构源码分析 -【MediaCodec编解码器插件模块化注册和创建处理流程】【Part 2】 TODO本系列文章分析的安卓源码版本：【Android 10.0 版本】推荐涉及到的知识点：Binder机制实现原理：Android C++底层Binder通信机制原理分析总结【通俗易懂】ALooper机制实现原理：Android native层媒体通信架构AHandler/ALooper机制实现

承接上一章节分析：Android MediaPlayer整体架构源码分析 -【MediaCodec编解码器插件模块化注册和创建处理流程】【Part 1】 TODO本系列文章分析的安卓源码版本：【Android 10.0 版本】推荐涉及到的知识点：Binder机制实现原理：Android C++底层Binder通信机制原理分析总结【通俗易懂】ALooper机制实现原理：Android native层媒体通信架构AHandler/ALooper机制实现源码分析Binder异常关闭监听：Android

Android native MediaCodec编解码器模块化注册和创建处理流程本系列文章分析的安卓源码版本：【Android 10.0 版本】从【六】Android MediaPlayer整体架构源码分析 -【start请求播放处理流程】【Part 4】章节分析中涉及到了MediaCodec编解码器创建处理流程，因此有必要此章节单独分析编解码器创建流程，主要会涉及到OpenMAX框架的实现和交互。推荐涉及到的知识点：Binder机制实现原理：Android C++底层Binder通信机制原理分析

承接上一章节分析：[【六】Android MediaPlayer整体架构源码分析 -【start请求播放处理流程】【Part 2】](https://blog.csdn.net/u012430727/article/details/115700060)本系列文章分析的安卓源码版本：【Android 10.0 版本】【此章节小节编号就接着上一章节排列】6.2、mMediaClock->setPlaybackRate(mPlaybackRate)实现分析：设置播放速率（默认为1）给MediaClock

承接上一章节分析：【六】Android MediaPlayer整体架构源码分析 -【start请求播放处理流程】【Part 1】本系列文章分析的安卓源码版本：【Android 10.0 版本】【TODO 未完成】【此章节小节编号就接着上一章节排列】5、canOffloadStream(audioMeta, hasVideo, mSource->isStreaming(), streamType)实现分析：先分析mSource->isStreaming()实现：其实返回是 mIsStr

承接上一章节分析：【五】Android MediaPlayer整体架构源码分析 -【prepareAsync/prepare数据准备处理流程】【Part 3】本系列文章分析的安卓源码版本：【Android 10.0 版本】【此章节小节编号就接着上一章节排列】readBuffer(trackType)方法定义实现：// [frameworks/av/media/libmediaplayerservice/nuplayer/GenericSource.cpp]void NuPlayer::Generi

**start请求播放处理流程**示例代码：```cppmMediaPlayer.start();```该方法推荐在前面prepare处理流程分析中，使用异步prepareAsync执行监听prepared完成事件，然后该事件中执行start()方法即可请求开始播放。start()方法实现：由方法英文注释可知，该方法其实会执行开始播放和恢复播放两个流程，即若此前已经stopped或从未start过，那么将会从头开始播放，而若此前是paused状态，那么将会恢复上次暂停位置开始播放。

承接上一章节分析：【五】Android MediaPlayer整体架构源码分析 -【prepareAsync/prepare数据准备处理流程】【Part 2】本系列文章分析的安卓源码版本：【Android 10.0 版本】【此章节小节编号就接着上一章节排列】3.5、getFormatMeta_l(false /* audio */)实现分析：获取video track信息的元数据。其实也就是通过video track对象（source）的getFormat()方法来获取video track信息的