网站换域名有没有影响吗,网站建设属于什么开票类目,招工最新招聘信息,信息查询系统前面几节我们了解了OMXNodeInstance是如何处理setPortMode、allocateBuffer、useBuffer的#xff0c;这一节我们再回到ACodec#xff0c;来看看 ACodec start 的其他部分。 我们首先来回顾一下#xff0c;ACodec start 的状态切换以及处理的事务#xff0c;我们用一张不太准… 前面几节我们了解了OMXNodeInstance是如何处理setPortMode、allocateBuffer、useBuffer的这一节我们再回到ACodec来看看 ACodec start 的其他部分。 我们首先来回顾一下ACodec start 的状态切换以及处理的事务我们用一张不太准确的图来表示 可以看到将 OMX 组件设置为 OMX_StateIdle 之后OMX 组件会等待所有的 buffer 都分配完成然后将状态设置完成的消息返回给ACodec层。我们之前说OMX再处理这个状态时会处在阻塞的情况现在看来每次接收到buffer都去判断一下有没有收到所有buffer应该就好了可以不需要阻塞等待 buffer 到来。
ACodec 收到 OMX 组件 OMX_StateIdle 状态设置完成的事件后会继续将 OMX 组件的状态设置为 OMX_StateExecuting同时将 ACodec 自身的状态切换到 IdleToExecutingState到这里组件就开始正式运转起来了同时会将状态设置完成的事件通知到上层。
ACodec 接收到事件后会正式切换到 ExecutingState开始运行。
这里会有一个问题OMX 组件和 ACodec 都正式开始运行了它们是如何运行起来的所有的buffer是如何被驱动的
答案就是在 IdleToExecutingState 的 onOMXEvent 中在切换到 ExecutingState 之前会先调用 resume 方法把 input buffer 交给上层把output buffer都送给 OMX 组件这样buffer就开始流转了。
正式看 resume 方法之前我原先有一个疑惑LoadedState 状态里将 OMX 组件状态设置为 OMX_StateExecuting万一 这个状态设定特别快ACodec 还没有进入到 IdleToExecutingState ACodec 就收到 OMX_StateExecuting 设定完成的事件怎么办呢是不是 ACodec 就无法执行到 resume 方法了呢答案是杞人忧天了ACodec 所有的消息是在一个线程中处理的sendCommand 和 changeState 方法在同一个函数中执行属于同一条消息的处理过程在收到OMX_StateExecuting设定完成时ACodec 状态时一定进入到 IdleToExecutingState 的。
1、resume
void ACodec::ExecutingState::resume() {// 首先判断是否要驱动提交 buffer只有在 未启动flush之后才会真正提交if (mActive) {ALOGV([%s] Were already active, no need to resume., mCodec-mComponentName.c_str());return;}submitOutputBuffers();// Post all available input buffersif (mCodec-mBuffers[kPortIndexInput].size() 0u) {ALOGW([%s] we dont have any input buffers to resume, mCodec-mComponentName.c_str());}for (size_t i 0; i mCodec-mBuffers[kPortIndexInput].size(); i) {BufferInfo *info mCodec-mBuffers[kPortIndexInput].editItemAt(i);if (info-mStatus BufferInfo::OWNED_BY_US) {postFillThisBuffer(info);}}mActive true;
}我们在上文中已经讲过了ACodec 通过调用 resume 来驱动 buffer 流转调用postFillThisBuffer 将 input buffer 传递给 MediaCodec调用 submitOutputBuffers 将 output buffer 传递给 OMX 组件。
1.1、 submitOutputBuffers
void ACodec::ExecutingState::submitOutputBuffers() {submitRegularOutputBuffers();if (mCodec-storingMetadataInDecodedBuffers()) {submitOutputMetaBuffers();}
}submitOutputBuffers 分为两个步骤首先会调用 submitRegularOutputBuffers翻译过来就是 提交常规的 output buffer这里有个问题什么是常规 output buffer呢来看代码
void ACodec::ExecutingState::submitRegularOutputBuffers() {bool failed false;for (size_t i 0; i mCodec-mBuffers[kPortIndexOutput].size(); i) {BufferInfo *info mCodec-mBuffers[kPortIndexOutput].editItemAt(i);// 有 surfacenative windowif (mCodec-mNativeWindow ! NULL) {// output buffer必须归属于 ACodec 或者是 native windowif (info-mStatus ! BufferInfo::OWNED_BY_US info-mStatus ! BufferInfo::OWNED_BY_NATIVE_WINDOW) {ALOGE(buffers should be owned by us or the surface);failed true;break;}// 如果归属于 native window 则直接退出if (info-mStatus BufferInfo::OWNED_BY_NATIVE_WINDOW) {continue;}} else {// 没有 surface 的情况下output buffer应该归属于 ACodecif (info-mStatus ! BufferInfo::OWNED_BY_US) {ALOGE(buffers should be owned by us);failed true;break;}}ALOGV([%s] calling fillBuffer %u, mCodec-mComponentName.c_str(), info-mBufferID);// 打印 log 检查 fenceinfo-checkWriteFence(submitRegularOutputBuffers);// 提交 output buffer 给 OMX 组件status_t err mCodec-fillBuffer(info);if (err ! OK) {failed true;break;}}// 如果以上过程出现异常则直接报错if (failed) {mCodec-signalError(OMX_ErrorUndefined, FAILED_TRANSACTION);}
}首先 output buffer 分为有 Surface 和 无Surface 两种情况这两种情况下buffer 分别来自于
Surface在 native window 中分配归属于 OWNED_BY_NATIVE_WINDOWno Surface在 ACodec 中分配共享内存 归属于 OWNED_BY_US
有 surface 的情况下会检查BufferInfo的归属如果有buffer归属于组件直接报错如果有 buffer 归属于 nativewindow说明graphic buffer还未分配不需要进行传递。执行到最后我们会发现BufferInfo 归属于 ACodec 时该buffer会被传递给 OMX 组件。
没有 surface 的情况下会检查 BufferInfo 是否归属于 ACodec如果不是则直接报错。执行到最后会把属于 ACodec 的output buffer 全部传递给 OMX 组件。
综上我们可以得知BufferInfo 中的 graphic buffer已经被分配和普通的 output buffer 被认为是 RegularOutput这两种buffer在一开始就会直接被传递给 OMX 组件。
还有两个问题要注意初始状态下为什么有surface时output buffer可能有两个归属呢这是因为使用有两种情况我们这里只要求了解 dynamic native window buffer也就是 BufferInfo 一开始归属于 native window的情况。
这里出现的 fence 我们后面再了解。
1.2、 submitOutputBuffers
上面讲了 regular buffer 是如何提交的接下来要讲其他buffer是如何提交的。这里的其他指的就是 BufferInfo 中的 graphic buffer 还未分配的情况之所以要单独拎出来是因为在提交之前还需要获取 graphic buffer。
调用 submitOutputMetaBuffers 之前要先判断是不是 metadata modekPortModeDynamicANWBuffer我们之前也讲过了这种模式下output buffer是动态分配的一开始是归属于native window的如果不是这种情况就可以跳过了。
void ACodec::ExecutingState::submitOutputMetaBuffers() {// submit as many buffers as there are input buffers with the codec// in case we are in port reconfiguringfor (size_t i 0; i mCodec-mBuffers[kPortIndexInput].size(); i) {BufferInfo *info mCodec-mBuffers[kPortIndexInput].editItemAt(i);if (info-mStatus BufferInfo::OWNED_BY_COMPONENT) {if (mCodec-submitOutputMetadataBuffer() ! OK)break;}}if (mCodec-mIsLowLatency) {maybePostExtraOutputMetadataBufferRequest();}// *** NOTE: THE FOLLOWING WORKAROUND WILL BE REMOVED ***mCodec-signalSubmitOutputMetadataBufferIfEOS_workaround();
}看完这段我们要直呼好家伙了在调用 submitOutputMetadataBuffer 之前会判断 BufferInfo 是否归属于 OWNED_BY_COMPONENT我们之前刚说过初始状态下BufferInfo 是归属于 OWNED_BY_NATIVE_WINDOW也就是说启动一开始OMX组件是不会获得真正的output buffer的是不是和我们预期的不一样了呢…
output buffer如何被送给 OMX 组件我们后面会了解到的。
1.3、 postFillThisBuffer
初始状态下把input buffer送给MediaCodec之前会检查BufferInfo 是否归属于 ACodec如果是则调用postFillThisBuffer
void ACodec::BaseState::postFillThisBuffer(BufferInfo *info) {// 检查端口是否已经收到eosif (mCodec-mPortEOS[kPortIndexInput]) {return;}CHECK_EQ((int)info-mStatus, (int)BufferInfo::OWNED_BY_US);// 给 input buffer 设置初始formatinfo-mData-setFormat(mCodec-mInputFormat);// 提交给 ACodecmCodec-mBufferChannel-fillThisBuffer(info-mBufferID);// 解除 BufferInfo 对 MediaCodecBuffer 的引用info-mData.clear();// 设置bufferinfo 状态info-mStatus BufferInfo::OWNED_BY_UPSTREAM;
}检查端口是否已经收到eos如果是则不会把input buffer回传给上层将默认的input format 设置给 mediaCodecBuffer将 MediaCodecBuffer 传递给 MediaCodec解除 BufferInfo 对 MediaCodecBuffer 的引用填充数据期间ACodec无法使用该buffer将 BufferInfo 状态设置为 OWNED_BY_UPSTREAM表示input buffer送给上层填充
