Android_ICS_OMX_In_Stagefright------>2开始解码（软解）

最新推荐文章于 2022-04-26 19:12:18 发布
最新推荐文章于 2022-04-26 19:12:18 发布
阅读量1.6k 收藏 1
点赞数
分类专栏： android multimedia

当应用层调用mediaplayer.start()的时候，在framework层对应的是在awesomeplayer中post一个mVideoEvent到TimedEventQueue中等待被调度。

        当其被调度到的时候，会激活回调函数onVideoEvent。
        在这个回调函数中，会做音视频的同步处理。代码很长捡关键的贴。
        void AwesomePlayer::onVideoEvent() {

        for (;;) {
	...
            status_t err = mVideoSource->read(&mVideoBuffer, &options);
 	...
            initRenderer_l();
	...
             mVideoRenderer->render(mVideoBuffer); 
    }
	
在这个回调函数中可以看到这样一句话，status_t err = mVideoSource->read(&mVideoBuffer, &options);其中，mVideoBuffer 是一个MediaBuffer类型的成员变量。还记得mVideoSource是什么类型吗？这里的mVideoSource，就是前面返回的OMXCodec，那么实际调用是的:
        status_t OMXCodec::read(MediaBuffer **buffer, const ReadOptions *options)，这个read函数会填充MediaBuffer *mVideoBuffer这个成员变量，然后交给Renderer来渲染输出。看看read函数的实现：
         
        status_t OMXCodec::read(MediaBuffer **buffer, const ReadOptions *options) {
        …...
        drainInputBuffers();
        if (mState == EXECUTING) {
            fillOutputBuffers();
        }
    }
        …...

    while (mState != ERROR && !mNoMoreOutputData && mFilledBuffers.empty()) {
        if ((err = waitForBufferFilled_l()) != OK) {
            return err;
        }
    }

    if (mState == ERROR) {
        return UNKNOWN_ERROR;
    }
    if(seeking) {
        CHECK_EQ((int)mState, (int)FLUSHING);
        setState(EXECUTING);
    }

    if (mFilledBuffers.empty()) {
        return mSignalledEOS ? mFinalStatus : ERROR_END_OF_STREAM;
    }

    if (mOutputPortSettingsHaveChanged) {
        mOutputPortSettingsHaveChanged = false;

        return INFO_FORMAT_CHANGED;
    }

    size_t index = *mFilledBuffers.begin();
    mFilledBuffers.erase(mFilledBuffers.begin());

    BufferInfo *info = &mPortBuffers[kPortIndexOutput].editItemAt(index);
    CHECK_EQ((int)info->mStatus, (int)OWNED_BY_US);
    info->mStatus = OWNED_BY_CLIENT;

    info->mMediaBuffer->add_ref();
    *buffer = info->mMediaBuffer;

    return OK;
}

在这个read函数中最重要的两个方法是drainInputBuffers()和fillOutputBuffers()，可以看到这两个函数是先后执行的。先来看看drainInputBuffers()方法中，做了哪些操作。

        void OMXCodec::drainInputBuffers() {
        …...
        Vector<BufferInfo> *buffers = &mPortBuffers[kPortIndexInput];
        for (size_t i = 0; i < buffers->size(); ++i) {
            BufferInfo *info = &buffers->editItemAt(i);
         …...
           
            if (!drainInputBuffer(info)) {
                break;
            }
         …...
}
这个 drainInputBuffers函数从输入端口的buffers中取出之前分配好的BufferInfo，然后交给drainInputBuffer(info)函数来处理，函数实现如下：

bool OMXCodec::drainInputBuffer(BufferInfo *info) {
    
        //comment by Alan, this buffer has only codec config informations
        status_t err = mOMX->emptyBuffer(
                mNode, info->mBuffer, 0, size,
                OMX_BUFFERFLAG_ENDOFFRAME | OMX_BUFFERFLAG_CODECCONFIG,
                0);
       
    for (;;) {
        ….... 
        MediaBuffer *srcBuffer;
        …...
        err = mSource->read(&srcBuffer);
        …...
        memcpy((uint8_t *)info->mData + offset,
                        (const uint8_t *)srcBuffer->data()
                            + srcBuffer->range_offset(),
                        srcBuffer->range_length());
        ….....	
        err = mOMX->emptyBuffer(
            mNode, info->mBuffer, 0, offset,
            flags, timestampUs);
        …....
}

这个函数比较复杂，主要的关键代码如上，在这个函数中，首先会把一些和编解码组件相关的specific data送给omx框架来调用一次emptybuffer，然后会进入一个for(;;)循环，在这个for循环内，会通过mSource->read(&srcBuffer)网srcBuffer中填充一些原始的流数据（从XXXExtractor解析出来未解码的数据），这里mSource就是前面XXXExtractor在文件解析的过程中new 的XXXSource这里假定是MPEG4Source。函数的大致实现如下：

       status_t MPEG4Source::read(MediaBuffer **out, const ReadOptions *options) {
        …...
        err = mGroup->acquire_buffer(&mBuffer);

        
        if (usesDRM) {
            num_bytes_read =
                mDataSource->readAt(offset, (uint8_t*)mBuffer->data(), size);
        } else {
            num_bytes_read = mDataSource->readAt(offset, mSrcBuffer, size);
        }

        …...
        *out = mBuffer;
        mBuffer = NULL;
        return OK;
}
这个函数的实现很复杂，在read的时候不但考虑了seek的问题，而且还涉及到了不少多媒体容器格式方面的一些问题。但是关于数据流向的函数就是两个，首先acquire_buffer，这个acquire_buffer和前面的add_buffer对应，在MPEG4Source::start中会被调用到。获得一个mBuffer后就可以通过mDataSource->readAt来往这个buffer上填充数据了。这里的mDataSource实际上可以对应到一个FileSource或者来之网络的CacheSource。mBuffer数据填充完后赋值给调用函数的 srcBuffer，这样就相当于给 drainInputBuffer(BufferInfo *info)中的info填充了数据，然后回到drainInputBuffer函数，接着emptyBuffer。实际上这里的BufferInfo *info的数据填充过程还有一些细节需要弄清楚，BufferInfo的结构体各个字段的意义还有待进一步弄明白。

        到了mOMX->emptyBuffer()基本就进入OMX框架了，无非是OMX那一套消息机制，之前已经说过，这里就不在赘述了。如果还有不清楚的话，其在openMax文档的时候我画的一张时序图。还有一点需要明确，在emptyBuffer的时候会将App Data  copyToOMX，将来之Appcation的数据copy到OMX框架中，而在OMXNodeInstance::onMessage  FILL_BUFFER_DONE的时候，会将数据从OMX框架中copy到Appcation空间，即copyFromOMX。Appcation<--  data --->OMX
       来看看其中一个函数的实现，
       void CopyToOMX(const OMX_BUFFERHEADERTYPE *header) {
        if (!mIsBackup) {
            return;
        }

        memcpy(header->pBuffer + header->nOffset,
               (const OMX_U8 *)mMem->pointer() + header->nOffset,
               header->nFilledLen);
    }
注意以下，mMem这个成员变量具体指什么，我们看看emptyBuffer这个函数的实现：

       status_t OMXNodeInstance::emptyBuffer(
        OMX::buffer_id buffer,
        OMX_U32 rangeOffset, OMX_U32 rangeLength,
        OMX_U32 flags, OMX_TICKS timestamp) {
    Mutex::Autolock autoLock(mLock);

    OMX_BUFFERHEADERTYPE *header = (OMX_BUFFERHEADERTYPE *)buffer;
    header->nFilledLen = rangeLength;
    header->nOffset = rangeOffset;
    header->nFlags = flags;
    header->nTimeStamp = timestamp;

    BufferMeta *buffer_meta =
        static_cast<BufferMeta *>(header->pAppPrivate);
    buffer_meta->CopyToOMX(header);

    OMX_ERRORTYPE err = OMX_EmptyThisBuffer(mHandle, header);

    return StatusFromOMXError(err);
}

去看一下BufferMeta的构造函数就可以发现，上面mMem实际上指的是head->pAppPrivate。

那么具体的解码过程什么时候开始呢？
        在OMX框架中所有的软解部分，最终都会通过OMX的消息机制走到SimpleSoftOMXComponent::onMessageReceived，函数的实现如下：

 void SimpleSoftOMXComponent::onMessageReceived(const sp<AMessage> &msg) {
    Mutex::Autolock autoLock(mLock);

    switch (msg->what()) {
        case kWhatSendCommand:
        {
            int32_t cmd, param;
            CHECK(msg->findInt32("cmd", &cmd));
            CHECK(msg->findInt32("param", &param));

            onSendCommand((OMX_COMMANDTYPE)cmd, (OMX_U32)param);
            break;
        }

        case kWhatEmptyThisBuffer:
        case kWhatFillThisBuffer:
        {
            OMX_BUFFERHEADERTYPE *header;
            CHECK(msg->findPointer("header", (void **)&header));

            CHECK(mState == OMX_StateExecuting && mTargetState == mState);

            bool found = false;
            for (size_t i = 0; i < mPorts.size(); ++i) {
                PortInfo *port = &mPorts.editItemAt(i);

                for (size_t j = 0; j < port->mBuffers.size(); ++j) {
                    BufferInfo *buffer = &port->mBuffers.editItemAt(j);

                    if (buffer->mHeader == header) {
                        CHECK(!buffer->mOwnedByUs);

                        buffer->mOwnedByUs = true;

                        CHECK((msg->what() == kWhatEmptyThisBuffer
                                    && port->mDef.eDir == OMX_DirInput)
                                || (port->mDef.eDir == OMX_DirOutput));

                        port->mQueue.push_back(buffer);
                        onQueueFilled(i);

                        found = true;
                        break;
                    }
                }
            }

            CHECK(found);
            break;
        }

        default:
            TRESPASS();
            break;
    }
}
显然这是一个消息的处理函数，对于 kWhatEmptyThisBuffer， kWhatFillThisBuffer这类消息都会进入到 onQueueFilled(i)函数，这个 onQueueFilled函数相当于是OMX软件编解码组件的一个入口，函数显示如下：

void SoftMPEG4::onQueueFilled(OMX_U32 portIndex) {
            …...
            Bool success = PVInitVideoDecoder(
                    mHandle, vol_data, &vol_size, 1, mWidth, mHeight, mode);

           …...
            MP4DecodingMode actualMode = PVGetDecBitstreamMode(mHandle);
           
            PVSetPostProcType((VideoDecControls *) mHandle, 0);
                notifyEmptyBufferDone(inHeader);
            …...
            PVSetReferenceYUV(mHandle, outHeader->pBuffer);

        if (PVDecodeVideoFrame(mHandle, &bitstream, &timestamp, &tmp,
            &useExtTimestamp,
            outHeader->pBuffer) != PV_TRUE) {

            notify(OMX_EventError, OMX_ErrorUndefined, 0, NULL);
            mSignalledError = true;
            return;
        }
        …...
        notifyFillBufferDone(outHeader);

}

上面的函数只保留了几个关键的函数调用，可以看到在这个onQueueFilled函数中会通过一些类似与 PVDecodeVideoFrame进入到OMX 框架中软件编解码的部分。可以看到通过 PVDecodeVideoFrame之后的yuv数据会保存在outHeader->pBuffer字段中。然后通过notifyEmptyBufferDone(inHeader); 或者notifyFillBufferDone(outHeader);来向组件OMX外部通知已经从inPutPort消费了一个buffer或者已经向outPutPort填充了一个buffer。
        简单说来，当notifyEmptyBufferDone的时候，OMX会记录已经被消费的buffer的索引，然后继续在该索引对应的buffer上 drainInputBuffer，当notifyFillBufferDone时候最终会通过OMX的消息机制走到OMXCodec::on_message中进入case omx_message::FILL_BUFFER_DONE:主要工作是，记录这个已经填充的buffer的索引号，然后将这个索引号保存在

                mFilledBuffers.push_back(i);
                mBufferFilled.signal();
看到mBufferFilled这个Condition被signal了，那么谁wait在这个Condition上呢？看上OMXCodec：：read函数中我红色标注的部分。原来在OMXCodec::read函数的后半段中会一直
while (mState != ERROR && !mNoMoreOutputData && mFilledBuffers.empty()) {
        if ((err = waitForBufferFilled_l()) != OK) {
            return err;
        }
    }
       那么FILL_BUFFER_DONE之后，在OMXCodec::read函数中被返回给AwesomePlayer的mVideoBuffer就是在OMX框架中outPutPort上的buffer。


通过上面的分析可以看到，虽然在OMX框架中 Input/OutPutPort上的buffer的生产和消费是异步，但是还是通过了一个Condition mBufferFilled来做同步。这个生产者消费者的问题，来用一个信号量做同步，还是比较好的。
sadamoo
关注
专栏目录
android ACodec MediaCodec NuPlayer flow
husanlim 的专栏
04-22 4220
MediaCodec/ACodec流程i. 初始化（从java层开始）：1、 java层中调用MediaCodec.createEncoder/DecoderByType(…)或MediaCodec.createByCodecName(…)创建编码器或者解码器2、 根据不同的参数new MediaCodec，然后其中会调用native_setup(…)3、 Native层android_media...
向android stagefright增加软解码库
flyingqr的专栏
12-19 3238
在stagefright中，加入了可增加软解码库的plugin：SoftOMXPlugin，可以自己加入软解码。 看文件SoftOMXPlugin.cpp 首先要增加kComponents[]，标示自己的软解码库。 在这个文件中，最关键的是 SoftOMXPlugin::makeComponentInstance() 根据提供的component name在kCompone
OMX中的回调机制分析
coolcary的博客
09-21 4636
OMX中的回调，目的：给组件用来回调OMX,OMXNodeInstance的相应处理。
OpenMAX介绍（总括）
热门推荐
qq69696698的专栏
03-12 1万+
一、OpenMax简介     OpenMAX是一个多媒体应用程序的标准。由NVIDIA公司和Khronos™在2006年推出。     它是无授权费的、跨平台的C语言程序接口序列，这些接口对音频、视频、静态图片的常用操作进行封装。     它包括三层，分别是应用层（AI）、集成层（IL）和开发层（DL）。其中IL层已经成为了事实上的多媒体框架标准。嵌入式处理器或者多媒体编解码模块的硬件生产
OpenMAX IL框架
keen_zuxwang的博客
06-28 1484
OpenMAX IL框架 OpenMAX 是一个多媒体应用程序的标准。由NVIDIA公司和Khronos™在2006年推出。 它是无授权费的、跨平台的C语言程序接口序列，这些接口对音频、视频、静态图片的常用操作进行封装。它包括三层，分别： 应用层（AI）、集成层（IL）和开发层（DL） 其中IL层已经成为了事实上的多媒体框架标准。嵌入式处理器或者多媒体编解码模块的硬件生产者，通常提供标
libomxil-bellagio-0.9.1.tar.gz_Bellagio_libomxil_lim-omx-1.0.tar
09-19
《OpenMAX IL实现详解——基于libomxil-bellagio-0.9.1与lim-omx-1.0.tar》 OpenMAX（Open Media Acceleration）IL（Interface Layer）是Khronos Group推出的一套开放标准，旨在提供跨平台的多媒体处理接口，用于...
omx_core_integration_guide.rar_omx guide
09-24
OMX（OpenMAX）核心整合指南是一份针对OpenCore环境下集成第三方核心的详细指导文档，主要面向开发者和系统集成人员。OpenMAX，全称为Open Multimedia eXtensions，是由Khronos Group制定的一系列API标准，旨在提供...
FFmpeg-master.zip_FFMPEG编码_ffmpeg_ffmpeg 264 mp4_ffmpeg mkv_ffmp
09-24
ffmpeg纯净的视频解码流程 ? 压缩编码数据->像素数据。 ? 例如解码H.264， 就是“H.264码流->YUV”。 ? 一般的视频解码流程 ? 视频码流一般存储在一定的封装格式（例如MP4、 AVI等）中。封装 格式中通常还包含...
peephole-surveillance-camera:使用基于Orange Pi Zero的h264硬编码的猫眼监控摄像机
05-11
描述 该项目提供了一个使用Orange Pi Zero的简单的窥Kong监控摄像头应用程序。 具有以下特点： 使用Allwinner的SOC H / W H.264编码器进行H264编码 RTMP流：您可以将视频流推送到rtmp服务器 移动侦测：侦测到移动...
OpenMAX/IL: OMX IL 学习笔记【1】- 结构框架
houxiaoni01的博客
06-15 3649
一、OpenMax简介 OpenMAX（Open Media Acceleration的缩写，开放多媒体加速层）是一个多媒体应用程序的标准。由NVIDIA公司和Khronos™在2006年推出。 它是无授权费的、跨平台的C语言程序接口序列，这些接口对音频、视频、静态图片的常用操作进行封装。 它包括三层，自上而下分别是应用层（AL）、集成层（IL）和开发层（DL）。 OpenMAX AL：Application Layer，应用和多媒体中间层的标准接口，使得应用在多媒体接口上具有了可移植性。 OpenMAX
12. Android MultiMedia框架完全解析 - 从NuPlayer到MediaCodec到ACodec到OMX的整体流程与状态转换
吾皇的博客
04-01 9671
之前的文章中，讲了那么多细节的东西，已经对概况没有一个大致的了解，所以这里缕一下整体的流程，同时也分析MediaCodec，ACodec与OMX Plugin之间的状态切换关系。 （一）初始化过程（从NuPlayer开始）： 1. NuPlayer::start()时产生一个kWhatStart，在消息处理函数中如果是暂停后的开始就调用NuPlayer::onResume()【只需m...
ACodec和OMXCodec的比较
cathuzi的专栏
11-09 6028
要掌握的内容： 1. ACodec中omx组件的创建过程 2. buffer的操作 3. 和OMXCodec的区别 组件的创建基本上和OMXCodec的相同。 1. 在ACodec::ExecutingState::resume()中，有：    void ACodec::ExecutingState::resume() {        ....
Android_ics_stagefright框架数据流向分析
xww810319的专栏
01-03 3545
原文： Android_ics_stagefright框架数据流向分析——1，待解码的原始数据从何而来 链接：http://blog.csdn.net/mci2004/article/details/7629146 先明确一点，stagefright框架是典型的事件驱动型，数据的流向也受到事件驱动（driven by event）的影响，在awesomePlaye
Android OMX详解
03-18 8119
OMX是Android解码器组件，懂得OMX就明白MediaPlayer的生命周期，对理解整个MultiMedia的工作机制有关键性作用。 下面会结合MediaPlayer的生命周期来介绍OMX。 OMX库调用过程 OMX库加载过程 OMX参数设置过程 setParameter在Component初始化的时候，需要执行6次，每次设置的阶段和目的如下： 整体如下：...
【学习】从零开发的Android音视频开发(13)——MediaCodec到OMX框架过程及其硬解码
PanicLin的博客
04-26 4141
学习于《Android音视频开发》，本文讲解了MediaCodec到OMX框架过程以及MediaCodec硬解码
海思OMX代码分析---技术片段
achina2011jy的博客
11-08 661
一、引言： 海思stb产品omx框架中使用的一些不错的代码技术，这个博客分析这些代码片段。 二、具体分析： 1.字符串衔接： 海思在通过组件名加载动态库的时候，将组件名与前后缀衔接使用的是strncat函数： strncpy(buf, prefix, sizeof(prefix)); strncat(buf, cComponentName, strlen(cComponentNam...
Android7.1 怎么将Audio硬解码改为软解码
zhuyong006的博客
04-08 1521
frameworks\av\media\libmediaplayerservice\nuplayer\NuPlayer.cpp void NuPlayer::determineAudioModeChange(const sp<AMessage> &audioFormat) { { ... bool canOffload = canOffloadStream( ...
Bellagio项目中libomxil库的实现分析
资源摘要信息: "libomxil-bellagio-0.9.1.tar.gz_Bellagio_libomxil_lim-omx-1.0.tar" 在IT行业，特别是涉及到媒体处理与播放的领域，OpenMAX IL（Integration Layer）是一个非常重要的标准。OpenMAX IL是OpenMAX...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值