Android多媒體開發-stagefright及AwesomePlayer相關知識梳理

android的多媒體框架中， stagefright其實是AwesomePlayer的代理，就是個皮包公司。

status_t StagefrightPlayer::setDataSource( const char *url, const KeyedVector<String8, String8> *headers) { return mPlayer->setDataSource(url, headers); } status_t StagefrightPlayer::prepare() { return mPlayer->prepare(); } status_t StagefrightPlayer::start() { ALOGV("start"); return mPlayer->play(); } status_t StagefrightPlayer::stop() { ALOGV("stop"); return pause();  // what's the difference? 
} status_t StagefrightPlayer::pause() { ALOGV("pause"); return mPlayer->pause(); } 

功能幾乎都是通過調用  

AwesomePlayer *mPlayer;  

成員變量來實現的，看來真正實現播放器功能的原來是 AwesomePlayer。Stagefright只是做了一層淺淺的封裝。

AwesomePlayer 不管他有多神秘，說到底還是個多媒體播放器。在播放器的基本模型上，他與VCL、mplayer、ffmpeg等開源的結構是一致的。只是組織實現的方式不同。

深入了解AwesomePlayer 之前，把播放器的基本模型總結一下，然后按照模型的各個部分來深入研究AwesomePlayer 的實現方式。

說白了播放器大致分為4大部分：source、demux、decoder、output。

1.source：數據源，數據的來源不一定都是本地file，也有可能是網路上的各種協議例如：http、rtsp、HLS等。source的任務就是把數據源抽象出來，為下一個demux模塊提供它需要的穩定的數據流。demux不用關信數據到底是從什么地方來的。

2.demux解復用：視頻文件一般情況下都是把音視頻的ES流交織的通過某種規則放在一起。這種規則就是容器規則。現在有很多不同的容器格式。如ts、mp4、flv、mkv、avi、rmvb等等。demux的功能就是把音視頻的ES流從容器中剝離出來，然后分別送到不同的解碼器中。其實音頻和視頻本身就是2個獨立的系統。容器把它們包在了一起。但是他們都是獨立解碼的，所以解碼之前，需要把它分別 獨立出來。demux就是干這活的，他為下一步decoder解碼提供了數據流。

3.decoder解碼：解碼器--播放器的核心模塊。分為音頻和視頻解碼器。影像在錄制后, 原始的音視頻都是占用大量空間, 而且是冗余度較高的數據. 因此, 通常會在制作的時候就會進行某種壓縮 ( 壓縮技術就是將數據中的冗余信息去除數據之間的相關性 ). 這就是我們熟知的音視頻編碼格式, 包括MPEG1（VCD）\ MPEG2（DVD）\ MPEG4 \ H.264 等等. 音視頻解碼器的作用就是把這些壓縮了的數據還原成原始的音視頻數據. 當然, 編碼解碼過程基本上都是有損的 .解碼器的作用就是把編碼后的數據還原成原始數據。

4.output輸出：輸出部分分為音頻和視頻輸出。解碼后的音頻（pcm）和視頻（yuv）的原始數據需要得到音視頻的output模塊的支持才能真正的讓人的感官系統（眼和耳）辨識到。

所以，播放器大致分成上述4部分。怎么抽象的實現這4大部分、以及找到一種合理的方式將這幾部分組織並運動起來。是每個播放器不同的實現方式而已。

接下來就圍繞這4大部分做深入分析。

 

上文已經大概介紹了播放器的幾大主要部分，但是有了這些功能組件也不能叫做播放器。需要某種方式將這些單獨的功能組件驅動起來，形成一個整體的功能。

視頻處理過程中有很多都是十分耗時的，如果都放在一個大的線程空間中。用戶體驗的效果可想而知。所以通常都是做異步操作。

AwesomePlayer是通過event事件調度來實現這些功能之間的驅動和調用的。

AwesomePlayer中的內部變量

TimedEventQueue mQueue;

這個mQueue就是AwesomePlayer的事件隊列，也是事件調度器。從他類型的名字上就能很清楚的看出他是以時間為基礎事件隊列。接下來看看它是怎么玩轉的。

1.先來看TimedEventQueue的內部結構，TimedEventQueue內部有一個 List<QueueItem>，每個QueueItem包含enent和時間

struct QueueItem { sp<Event> event; int64_t realtime_us; }; 

有一個獨立線程threadEntry是在TimedEventQueue::start被創建，TimedEventQueue::stop被銷毀的。

void TimedEventQueue::start() { if (mRunning) { return; } mStopped = false; pthread_attr_t attr; pthread_attr_init(&attr); pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_JOINABLE); pthread_create(&mThread, &attr, ThreadWrapper, this); pthread_attr_destroy(&attr); mRunning = true; } void TimedEventQueue::stop(bool flush) { if (!mRunning) { return; } if (flush) { postEventToBack(new StopEvent); } else { postTimedEvent(new StopEvent, INT64_MIN); } void *dummy; pthread_join(mThread, &dummy); mQueue.clear(); mRunning = false; } 

2.List<QueueItem>目的就是按照延時時間維護一個event事件隊列，threadEntry線程就是不斷的從隊列的頭取出一個event，然后通過  event->fire(this, now_us); 回調到這個event事件提前注冊好的相對應功能函數。 

3.然后看看AwesomePlayer是怎么用TimedEventQueue，AwesomePlayer會定義很多類型的event事件，並把和這些事件相關的功能函數一定綁定起來。

mVideoEvent = new AwesomeEvent(this, &AwesomePlayer::onVideoEvent); mVideoEventPending = false; mStreamDoneEvent = new AwesomeEvent(this, &AwesomePlayer::onStreamDone); mStreamDoneEventPending = false; mBufferingEvent = new AwesomeEvent(this, &AwesomePlayer::onBufferingUpdate); mBufferingEventPending = false; mVideoLagEvent = new AwesomeEvent(this, &AwesomePlayer::onVideoLagUpdate); mVideoEventPending = false; mCheckAudioStatusEvent = new AwesomeEvent(this, &AwesomePlayer::onCheckAudioStatus);  

  原因之前也說了，因為好多音視頻處理的功能是十分耗時間的，假如AwesomePlayer 想用某個功能，他並不是直線去調用它，而是抽象成一種AwesomeEvent，將想要調用的功能函數與事件捆綁。通過TimedEventQueue::postTimedEvent(),按照延時的優先順序把它放到TimedEventQueue的隊列之中。然后AwesomePlayer就不管了。TimedEventQueue start之后，自己內部的線程會從隊列中依次取出這些事件，然后通過event->fire回調事件的功能函數。這樣就達到了AwesomePlayer的目的。

4.之前也介紹過mediaPlayer大致流程就是

mediaPlayer.setDataSource(path);  
mediaPlayer.prepare();  
mediaPlayer.start(); 

在AwesomePlayer 也是這種流程，在AwesomePlayer prepare（）相關函數中。

status_t AwesomePlayer::prepareAsync_l() { if (mFlags & PREPARING) { return UNKNOWN_ERROR;  // async prepare already pending 
 } if (!mQueueStarted) { mQueue.start(); mQueueStarted = true; } modifyFlags(PREPARING, SET); mAsyncPrepareEvent = new AwesomeEvent( this, &AwesomePlayer::onPrepareAsyncEvent); mQueue.postEvent(mAsyncPrepareEvent); return OK; } 

並沒有實際的調用onPrepareAsyncEvent（）真正的功能函數，他只是把mQueue start之后，然后創建個mAsyncPrepareEvent事件，把它插入到mQueue之中就不管了，具體調用是由mQueue中的threadEntry線程來做。

 

 

1.通過setDataSource 指定播放器的數據源。可以是URI或者fd.可以是http:// 、rtsp://、本地地址或者本地文件描述符fd。其最終調用是將上層傳遞來的參數轉化為DataSource，為下一步的demux提供數據支持。

2.在真正Prepare功能函數onPrepareAsyncEvent()會調用finishSetDataSource_l。通過第一步產生的DataSource來生成extractor，因為封裝的格式很多，所以需要通過DataSource的信息，去創建不同的extractor。

extractor = MediaExtractor::Create( dataSource, sniffedMIME.empty() ? NULL : sniffedMIME.c_str());  

if (!strcasecmp(mime, MEDIA_MIMETYPE_CONTAINER_MPEG4) || !strcasecmp(mime, "audio/mp4")) { ret = new MPEG4Extractor(source); } else if (!strcasecmp(mime, MEDIA_MIMETYPE_AUDIO_MPEG)) { ret = new MP3Extractor(source, meta); } else if (!strcasecmp(mime, MEDIA_MIMETYPE_AUDIO_AMR_NB) || !strcasecmp(mime, MEDIA_MIMETYPE_AUDIO_AMR_WB)) { ret = new AMRExtractor(source); } else if (!strcasecmp(mime, MEDIA_MIMETYPE_AUDIO_FLAC)) { ret = new FLACExtractor(source); } else if (!strcasecmp(mime, MEDIA_MIMETYPE_CONTAINER_WAV)) { ret = new WAVExtractor(source); } else if (!strcasecmp(mime, MEDIA_MIMETYPE_CONTAINER_OGG)) { ret = new OggExtractor(source); } else if (!strcasecmp(mime, MEDIA_MIMETYPE_CONTAINER_MATROSKA)) { ret = new MatroskaExtractor(source); } else if (!strcasecmp(mime, MEDIA_MIMETYPE_CONTAINER_MPEG2TS)) { ret = new MPEG2TSExtractor(source); } else if (!strcasecmp(mime, MEDIA_MIMETYPE_CONTAINER_WVM)) { // Return now. WVExtractor should not have the DrmFlag set in the block below. 
    return new WVMExtractor(source); } else if (!strcasecmp(mime, MEDIA_MIMETYPE_AUDIO_AAC_ADTS)) { ret = new AACExtractor(source, meta); } else if (!strcasecmp(mime, MEDIA_MIMETYPE_CONTAINER_MPEG2PS)) { ret = new MPEG2PSExtractor(source); } 

3.得到extractor之后，通過setVideoSource() setAudioSource()產生獨立的mVideoTrack(視頻)、mAudioTrack(音頻)數據流，分別為音視頻解碼器提供有各自需要的數據流。

其實extractor和mVideoTrack、mAudioTrack就組成了播放器模型中的demuxer部分。把封裝格式里面的音視頻流拆分出來，分別的送給音視頻解碼器。

 

4.接下來就是initVideoDecoder() initAudioDecoder().依賴上面產生的mVideoTrack(視頻)、mAudioTrack(音頻)數據流。生成了mVideoSource和mAudioSource這兩個音視頻解碼器。不同類型匹配不同的解碼器。

mVideoSource = OMXCodec::Create( mClient.interface(), mVideoTrack->getFormat(), false, // createEncoder 
 mVideoTrack, NULL, flags, USE_SURFACE_ALLOC ? mNativeWindow : NULL); mAudioSource = OMXCodec::Create( mClient.interface(), mAudioTrack->getFormat(), false, // createEncoder 
 mAudioTrack); } 

mVideoSource、mAudioSource組成了播放器模型中的decoder部分。

 

android系統中的編解碼器部分用的是openmax，以后會深入了解。openma x是一套標准接口，各家硬件廠商都可以遵循這個標准來做自己的實現，發揮自己芯片特性。然后提供給android系統來用。因為大部分的機頂盒芯片產品硬件的編解碼是它的優勢，可以把這種優勢完全融入到android平台中。以后手機高清視頻硬解碼也會是個趨勢。

5.解碼完之后的數據就要輸出了。AwesomePlayer分別用了mVideoRenderer做視頻輸出、mAudioPlayer做音頻輸出。他們分別調用android圖像和音頻的相關服務。這倆部分是android平台中十分重要的2塊，以后會深入了解。

mVideoRenderer和mAudioPlayer就組成了播放器中output的部分。

 

綜上AwesomePlayer的整體框架和流程就清晰了，其實也脫離不了DataSource、demux、decoder、output這4大部分。接下來會分別了解每個部分是怎么實現的。

1.openmax 簡介

http://www.khronos.org/openmax/

OpenMax是一個多媒體應用程序的框架標准，由NVIDIA公司和Khronos在2006年推出。

OpenMAX分為3層：

第一層：OpenMax DL（Development Layer，開發層）

第二層：OpenMax IL（Integration Layer，集成層）

第三層：OpenMax AL（Appliction Layer，應用層）

2.OpenMax IL簡介

OpenMax IL 處在中間層的位置，OpenMAX IL 作為音頻，視頻和圖像編解碼器 能與多媒體編解碼器交互，並以統一的行為支持組件（例如資源和皮膚）。這些編解碼器或許是軟硬件的混合體，對用戶是 的底層接口應用於嵌入式或 / 和移動設備。它提供了應用程序和媒體框架， 透明的。本質上不存在這種標准化的接口，編解碼器供 應商必須寫私有的或者封閉的接口，集成進移動設備。 IL 的主要目的 是使用特征集合為編解碼器提供一個系統抽象，為解決多個不同媒體系統之間輕便性的問題。

OpenMax IL 的目的就是為硬件平台的圖形及音視頻提供一個抽象層，可以為上層的應用提供一個可跨平台的支撐。這一點對於跨平台的媒體應用來說十分重要。本人也接觸過幾家高清解碼芯片，這些芯片底層的音視頻接口雖然功能上大致相同，但是接口設計及用法上各有不同，而且相差很多。你要想讓自己開發的媒體應用完美的運行在不同的硬件廠商平台上，就得適應不同芯片的底層解碼接口。這個對於應用開發來說十分繁瑣。所以就需要類似於OpenMax IL 這種接口規范。應用假如涉及到音視頻相關功能時，只需調用這些標准的接口，而不需要關心接口下方硬件相關的實現。假如換了硬件平台時，只需要把接口層與硬件適配好了就行了。上層應用不需要頻繁改動。

你可以把OpenMax IL 看作是中間件中的porting層接口，但是現在中間件大部分都是自家定義自己的。

OpenMax 想做的就是定義一個這樣的行業標准，這樣媒體應用、硬件廠商都遵循這種標准。硬件廠商將OpenMax 與處理器一並提供，上層的多媒體框架想要用到硬件音視頻加速功能時，只需遵循openmax的接口就可以擴平台運行。

可喜的，現在越來越多的多媒體框架及多媒體應用正在遵循openmax標准，包括各種知名的媒體開源軟件。越來越多的芯片廠商也在遵循openmax的標准。對於現在的音視頻編解碼來說，分辨率越來越高，需要芯片提供硬件加速功能是個大的趨勢。我相信 接口的標准化是一定要走的。

3.OpenMax IL結構

OpenMax IL主要內容如下所示。

 客戶端（Client）：OpenMax IL的調用者

 組件（Component）：OpenMax IL的單元，每一個組件實現一種功能

 端口（Port）：組件的輸入輸出接口

 隧道化（Tunneled）：讓兩個組件直接連接的方式

組件、端口、隧道化思想和GStreamer 中的 pipeline 十分類似。

Component實現單一功能、或是Source、Host、Accelerator和Sink。

Port 是 Component對外的輸入輸出口。

通過Tunneled 將單一Component串聯起來形成一個完整功能。

OpenMax Core是輔助各個組件運行的部分

        

4.Component內部結構

 

Component 的基本模型如上圖，可以把它想象成一個加工車間：

輸入端口輸入材料

輸出端口輸出加工完成品

通過handle 來給車間發送指令或者或者狀態

將事件及時發送給車間外部管理者

1.android中用openmax來干啥？

有了上一篇AwesomePlayer基本框架及播放流程已經很清楚的看到了，android中的 AwesomePlayer就是用openmax來做(code)編解碼,其實在openmax接口設計中，他不光能用來當編解碼。通過他的組件可以組成一個完整的播放器，包括sourc、demux、decode、output。但是為什么android只用他來做code呢？我認為有以下幾方面：

 

1.在整個播放器中，解碼器不得不說是最重要的一部分，而且也是最耗資源的一塊。如果全靠軟解，直接通過cpu來運算，特別是高清視頻。別的事你就可以啥都不干了。所以解碼器是最需要硬件提供加速的部分。現在的高清解碼芯片都是主芯片+DSP結構，解碼的工作都是通過DSP來做，不會在過多的占用主芯片。所有將芯片中DSP硬件編解碼的能力通過openmax標准接口呈現出來，提供上層播放器來用。我認為這塊是openmax最重要的意義。

 

2.source 主要是和協議打交道，demux 分解容器部分，大多數的容器格式的分解是不需要通過硬件來支持。只是ts流這種格式最可能用到硬件的支持。因為ts格式比較特殊，單包的大小太小了，只有188字節。所以也是為什么現在常見的解碼芯片都會提供硬件ts demux 的支持。

 

3.音視頻輸出部分video\audio output 這塊和操作系統關系十分緊密。可以看看著名開源播放器vlc。vlc 在mac、linux、Windows都有，功能上差別也不大。所以說他是跨平台的，他跨平台跨在哪？主要的工作量還是在音視頻解碼完之后的輸出模塊。因為各個系統的圖像渲染和音頻輸出實現方法不同，所以vlc需要針對每個平台實現不同的output。這部分內容放在openmax來顯然不合適。

 

所以openmax 中硬件抽象的編解碼是最為常用的，也是為什么android中只用它來抽象code。

2.android中openmax實現框架

 

1.上面已經說過了，android系統中只用openmax來做code，所以android向上抽象了一層OMXCodec，提供給上層播放器用。

播放器中音視頻解碼器mVideosource、mAudiosource都是OMXCodec的實例。

 

2.OMXCodec通過IOMX 依賴binder機制 獲得 OMX服務，OMX服務 才是openmax 在android中 實現。

 

3. OMX把軟編解碼和硬件編解碼統一看作插件的形式管理起來。

 

AwesomePlayer 中有個變量 

OMXClient mClient;

讓我們看看   OMXClient 

class OMXClient {  
public:  
    OMXClient();  
  
    status_t connect();  
    void disconnect();  
  
    sp<IOMX> interface() {  
        return mOMX;  
    }  
  
private:  
    sp<IOMX> mOMX;  
  
    OMXClient(const OMXClient &);  
    OMXClient &operator=(const OMXClient &);  
};  

OMXClient 有個IOMX 的變量 mOMX ，這個就是和OMX服務進行binder通訊的。

在 AwesomePlayer 的構造函數中會調用 

CHECK_EQ(mClient.connect(), (status_t)OK);  

status_t OMXClient::connect() {  
    sp<IServiceManager> sm = defaultServiceManager();  
    sp<IBinder> binder = sm->getService(String16("media.player"));  
    sp<IMediaPlayerService> service = interface_cast<IMediaPlayerService>(binder);  
  
    CHECK(service.get() != NULL);  
  
    mOMX = service->getOMX();  
    CHECK(mOMX.get() != NULL);  
  
    if (!mOMX->livesLocally(NULL /* node */, getpid())) {  
        ALOGI("Using client-side OMX mux.");  
        mOMX = new MuxOMX(mOMX);  
    }  
  
    return OK;  
}  

sp<IOMX> MediaPlayerService::getOMX() {  
    Mutex::Autolock autoLock(mLock);  
  
    if (mOMX.get() == NULL) {  
        mOMX = new OMX;  
    }  
  
    return mOMX;  
}  

OMXClient::connect函數是通過binder機制 獲得到MediaPlayerService，然后通過MediaPlayerService來創建OMX的實例。這樣OMXClient就獲得到了OMX的入口，接下來就可以通過binder機制來獲得OMX提供的服務。

也就是說OMXClient 是android中 openmax 的入口。

 

在創建音視頻解碼mVideoSource、mAudioSource的時候會把OMXClient中的sp<IOMX> mOMX的實例 傳給mVideoSource、mAudioSource來共享使用這個OMX的入口。

也就是說一個AwesomePlayer對應着 一個IOMX 變量，AwesomePlayer中的音視頻解碼器共用這個IOMX變量來獲得OMX服務。

sp<IOMX> interface() {  
      return mOMX;  
  }  

mAudioSource = OMXCodec::Create(  
                mClient.interface(), mAudioTrack->getFormat(),  
                false, // createEncoder  
                mAudioTrack);   

mVideoSource = OMXCodec::Create(  
            mClient.interface(), mVideoTrack->getFormat(),  
            false, // createEncoder  
            mVideoTrack,  
            NULL, flags, USE_SURFACE_ALLOC ? mNativeWindow : NULL); 

通過上文知道了，每個AwesomePlayer 只有一個OMX服務的入口，但是AwesomePlayer不一定就只需要1種解碼器。有可能音視頻都有，或者有很多種。這個時候這些解碼器都需要OMX的服務，也就是OMX那頭需要建立不同的解碼器的組件來對應着AwesomePlayer中不同的code。OMX中非常重要的2個成員就是 OMXMaster 和 OMXNodeInstance。OMX通過這倆個成員來創建和維護不同的openmax 解碼器組件，為AwesomePlayer中不同解碼提供服務。讓我們看看他們是怎么實現這些工作的。

 

1. OMX中 OMXNodeInstance 負責創建並維護不同的實例，這些實例是根據上面需求創建的，以node作為唯一標識。這樣播放器中每個OMXCodec在OMX服務端都對應有了自己的OMXNodeInstance實例。

2.OMXMaster 維護底層軟硬件解碼庫，根據OMXNodeInstance中想要的解碼器來創建解碼實體組件。

接下來我們假設視頻解碼器需要的是AVC，來看看解碼器創建的流程。

(默認走軟解碼)

1.准備工作初始化OMXMaster

OMX構造函數中會進行初始化。

OMXMaster *mMaster;

OMX::OMX()
    : mMaster(new OMXMaster),
      mNodeCounter(0) {
}

OMXMaster::OMXMaster()
    : mVendorLibHandle(NULL) {
    addVendorPlugin();
    addPlugin(new SoftOMXPlugin);
}

OMXMaster 負責OMX中編解碼器插件管理，軟件解碼和硬件解碼都是使用OMX標准，掛載plugins的方式來進行管理。

軟解通過 addPlugin(new SoftOMXPlugin);會把這些編解碼器的名字都放在mPluginByComponentName中。

android 默認會提供一系列的軟件解碼器。目前支持這些格式的軟編解碼。

kComponents[] = {  
    { "OMX.google.aac.decoder", "aacdec", "audio_decoder.aac" },  
    { "OMX.google.aac.encoder", "aacenc", "audio_encoder.aac" },  
    { "OMX.google.amrnb.decoder", "amrdec", "audio_decoder.amrnb" },  
    { "OMX.google.amrnb.encoder", "amrnbenc", "audio_encoder.amrnb" },  
    { "OMX.google.amrwb.decoder", "amrdec", "audio_decoder.amrwb" },  
    { "OMX.google.amrwb.encoder", "amrwbenc", "audio_encoder.amrwb" },  
    { "OMX.google.h264.decoder", "h264dec", "video_decoder.avc" },  
    { "OMX.google.h264.encoder", "h264enc", "video_encoder.avc" },  
    { "OMX.google.g711.alaw.decoder", "g711dec", "audio_decoder.g711alaw" },  
    { "OMX.google.g711.mlaw.decoder", "g711dec", "audio_decoder.g711mlaw" },  
    { "OMX.google.h263.decoder", "mpeg4dec", "video_decoder.h263" },  
    { "OMX.google.h263.encoder", "mpeg4enc", "video_encoder.h263" },  
    { "OMX.google.mpeg4.decoder", "mpeg4dec", "video_decoder.mpeg4" },  
    { "OMX.google.mpeg4.encoder", "mpeg4enc", "video_encoder.mpeg4" },  
    { "OMX.google.mp3.decoder", "mp3dec", "audio_decoder.mp3" },  
    { "OMX.google.vorbis.decoder", "vorbisdec", "audio_decoder.vorbis" },  
    { "OMX.google.vpx.decoder", "vpxdec", "video_decoder.vpx" },  
    { "OMX.google.raw.decoder", "rawdec", "audio_decoder.raw" },  
    { "OMX.google.flac.encoder", "flacenc", "audio_encoder.flac" },  
};  

 

硬件編解碼是通過 addVendorPlugin();加載libstagefrighthw.so.各個芯片平台可以遵循openmax 標准,生成libstagefrighthw.so的庫來提供android應用。

 
void OMXMaster::addVendorPlugin() {  
    addPlugin("libstagefrighthw.so");  
}  

 

然后通過dlopen、dlsym來調用庫中的函數。

這部分准備工作是在AwesomePlayer的構造函數中

CHECK_EQ(mClient.connect(), (status_t)OK); 已經完成了。

2.創建mVideoSource

有了上面的OMX，接下來會在AwesomePlayer::initVideoDecoder中創建mVideoSource 實例，下面代碼只保留的主要部分：

status_t AwesomePlayer::initVideoDecoder(uint32_t flags) {  
    ATRACE_CALL();  
    mVideoSource = OMXCodec::Create(  
            mClient.interface(), mVideoTrack->getFormat(),  
            false, // createEncoder  
            mVideoTrack,  
            NULL, flags, USE_SURFACE_ALLOC ? mNativeWindow : NULL);  
    status_t err = mVideoSource->start();  
    return mVideoSource != NULL ? OK : UNKNOWN_ERROR;  
}  

保留主要部分，去除編碼相關

sp<MediaSource> OMXCodec::Create(  
        const sp<IOMX> &omx,  
        const sp<MetaData> &meta, bool createEncoder,  
        const sp<MediaSource> &source,  
        const char *matchComponentName,  
        uint32_t flags,  
        const sp<ANativeWindow> &nativeWindow) {  
    int32_t requiresSecureBuffers;  
      
    const char *mime;  
    bool success = meta->findCString(kKeyMIMEType, &mime);  
    CHECK(success);  
  
    Vector<String8> matchingCodecs;  
    Vector<uint32_t> matchingCodecQuirks;  
    findMatchingCodecs(  
            mime, createEncoder, matchComponentName, flags,  
            &matchingCodecs, &matchingCodecQuirks);  
  
    sp<OMXCodecObserver> observer = new OMXCodecObserver;  
    IOMX::node_id node = 0;  
  
    for (size_t i = 0; i < matchingCodecs.size(); ++i) {  
        const char *componentNameBase = matchingCodecs[i].string();  
        uint32_t quirks = matchingCodecQuirks[i];  
        const char *componentName = componentNameBase;  
  
        AString tmp;  
     
        status_t err = omx->allocateNode(componentName, observer, &node);  
        if (err == OK) {  
            ALOGV("Successfully allocated OMX node '%s'", componentName);  
  
            sp<OMXCodec> codec = new OMXCodec(  
                    omx, node, quirks, flags,  
                    createEncoder, mime, componentName,  
                    source, nativeWindow);  
  
            observer->setCodec(codec);  
  
            err = codec->configureCodec(meta);  
  
            if (err == OK) {  
                if (!strcmp("OMX.Nvidia.mpeg2v.decode", componentName)) {  
                    codec->mFlags |= kOnlySubmitOneInputBufferAtOneTime;  
                }  
  
                return codec;  
            }  
  
            ALOGV("Failed to configure codec '%s'", componentName);  
        }  
    }  
  
    return NULL;  
}  

1.根據mVideoTrack傳進來的視頻信息，查找相匹配的解碼器。

 

bool success = meta->findCString(kKeyMIMEType, &mime);
findMatchingCodecs(
           mime, createEncoder, matchComponentName, flags,
           &matchingCodecs, &matchingCodecQuirks);

2. 創建OMXCodecObserver 實例，OMXCodecObserver功能后續會詳細介紹。創建一個node 並初始化為0.

 

 

sp<OMXCodecObserver> observer = new OMXCodecObserver;
    IOMX::node_id node = 0;

3. 通過omx入口 依靠binder 機制調用OMX服務中的allocateNode()，這一步把匹配得到的解碼器組件名、OMXCodecObserver實例和初始化為0的node一並傳入。

 

status_t err = omx->allocateNode(componentName, observer, &node);

這個allocateNode 就是文章最開始講的，在OMX那頭創建一個和mVideoSource相匹配的解碼實例。用node值作為唯一標識。
讓我們來看看真正的omx中allocateNode做了啥？

status_t OMX::allocateNode(
        const char *name, const sp<IOMXObserver> &observer, node_id *node) {
    Mutex::Autolock autoLock(mLock);

    *node = 0;

    OMXNodeInstance *instance = new OMXNodeInstance(this, observer);

    OMX_COMPONENTTYPE *handle;
    OMX_ERRORTYPE err = mMaster->makeComponentInstance(
            name, &OMXNodeInstance::kCallbacks,
            instance, &handle);

    if (err != OMX_ErrorNone) {
        ALOGV("FAILED to allocate omx component '%s'", name);

        instance->onGetHandleFailed();

        return UNKNOWN_ERROR;
    }

    *node = makeNodeID(instance);
    mDispatchers.add(*node, new CallbackDispatcher(instance));

    instance->setHandle(*node, handle);

    mLiveNodes.add(observer->asBinder(), instance);
    observer->asBinder()->linkToDeath(this);

    return OK;
}

創建一個OMXNodeInstance實例。

通過mMaster->makeComponentInstance創建真正解碼器的組件，並通過handle與OMXNodeInstance關聯。

所以說mMaster->makeComponentInstance這里是建立解碼器組件的核心。會把mVideoSource需要的解碼器name一直傳遞下去。

OMX_ERRORTYPE OMXMaster::makeComponentInstance(  
        const char *name,  
        const OMX_CALLBACKTYPE *callbacks,  
        OMX_PTR appData,  
        OMX_COMPONENTTYPE **component) {  
    Mutex::Autolock autoLock(mLock);  
  
    *component = NULL;  
  
    ssize_t index = mPluginByComponentName.indexOfKey(String8(name));  
  
    if (index < 0) {  
        return OMX_ErrorInvalidComponentName;  
    }  
  
    OMXPluginBase *plugin = mPluginByComponentName.valueAt(index);  
    OMX_ERRORTYPE err =  
        plugin->makeComponentInstance(name, callbacks, appData, component);  
  
    if (err != OMX_ErrorNone) {  
        return err;  
    }  
  
    mPluginByInstance.add(*component, plugin);  
  
    return err;  
}  

最開始OMXMaster通過 addPlugin(new SoftOMXPlugin);把支持的軟解碼放在mPluginByComponentName中，在makeComponentInstance中通過上面傳下來的解碼器的name值從mPluginByComponentName找到相對應的plugin，然后調用  plugin->makeComponentInstance(name, callbacks, appData, component);

這里的plugin 值得就是軟解SoftOMXPlugin 也就是調用了

OMX_ERRORTYPE SoftOMXPlugin::makeComponentInstance(  
        const char *name,  
        const OMX_CALLBACKTYPE *callbacks,  
        OMX_PTR appData,  
        OMX_COMPONENTTYPE **component) {  
    ALOGV("makeComponentInstance '%s'", name);  
  
    for (size_t i = 0; i < kNumComponents; ++i) {  
        if (strcmp(name, kComponents[i].mName)) {  
            continue;  
        }  
  
        AString libName = "libstagefright_soft_";  
        libName.append(kComponents[i].mLibNameSuffix);  
        libName.append(".so");  
  
        void *libHandle = dlopen(libName.c_str(), RTLD_NOW);  
  
        if (libHandle == NULL) {  
            ALOGE("unable to dlopen %s", libName.c_str());  
  
            return OMX_ErrorComponentNotFound;  
        }  
  
        typedef SoftOMXComponent *(*CreateSoftOMXComponentFunc)(  
                const char *, const OMX_CALLBACKTYPE *,  
                OMX_PTR, OMX_COMPONENTTYPE **);  
  
        CreateSoftOMXComponentFunc createSoftOMXComponent =  
            (CreateSoftOMXComponentFunc)dlsym(  
                    libHandle,  
                    "_Z22createSoftOMXComponentPKcPK16OMX_CALLBACKTYPE"  
                    "PvPP17OMX_COMPONENTTYPE");  
  
        if (createSoftOMXComponent == NULL) {  
            dlclose(libHandle);  
            libHandle = NULL;  
  
            return OMX_ErrorComponentNotFound;  
        }  
  
        sp<SoftOMXComponent> codec =  
            (*createSoftOMXComponent)(name, callbacks, appData, component);  
  
        if (codec == NULL) {  
            dlclose(libHandle);  
            libHandle = NULL;  
  
            return OMX_ErrorInsufficientResources;  
        }  
  
        OMX_ERRORTYPE err = codec->initCheck();  
        if (err != OMX_ErrorNone) {  
            dlclose(libHandle);  
            libHandle = NULL;  
  
            return err;  
        }  
  
        codec->incStrong(this);  
        codec->setLibHandle(libHandle);  
  
        return OMX_ErrorNone;  
    }  
  
    return OMX_ErrorInvalidComponentName;  
}  

 

通過上面傳下來的解碼器的name，找到對應庫的名字。假如是264的話，要加載的庫就是 libstagefright_soft_h264dec.so,也就是對應上層264解碼的話，omx解碼組件會加載對應的 libstagefright_soft_h264dec.so庫。相對應的軟解代碼在 Android4.1.1\frameworks\av\media\libstagefright\codecs\on2\h264dec 中。

加載完264解碼庫后 通過dlopen、dlsym來調用庫中函數。

通過調用 SoftAVC 中的 createSoftOMXComponent 來創建真正264解碼器實例SoftOMXComponent。以后真正視頻解碼的工作都是通過avc 這個SoftAVC實例完成的

android::SoftOMXComponent *createSoftOMXComponent(  
        const char *name, const OMX_CALLBACKTYPE *callbacks,  
        OMX_PTR appData, OMX_COMPONENTTYPE **component) {  
    return new android::SoftAVC(name, callbacks, appData, component);  
}  

經過這一路下來，終於完成了解碼器的創建工作。簡單總結一下。

1.AwesomePlayer中通過initVideoDecoder 來創建video解碼器mVideoSource

2.mVideoSource 中通過上部分demux后的視頻流 mVideoTrack來獲得解碼器的類型，通過類型調用omx->allocateNode 創建omx node實例與自己對應。以后都是通過node實例來操作解碼器。

3.在 omx->allocateNode中 通過mMaster->makeComponentInstance 來創建真正對應的解碼器組件。這個解碼器組件是完成之后解碼實際工作的。

4.在創建mMaster->makeComponentInstance過程中，也是通過上面mVideoTrack 過來的解碼器類型名，找到相對應的解碼器的庫，然后實例化。