一瘦麸、Android MediaCodec簡單介紹
Android中可以使用MediaCodec來訪問底層的媒體編解碼器，可以對媒體進(jìn)行編/解碼饵蒂。
MediaCodec可以處理的數(shù)據(jù)有以下三種類型：壓縮數(shù)據(jù)、原始音頻數(shù)據(jù)树绩、原始視頻數(shù)據(jù)示惊。這三種類型的數(shù)據(jù)均可以利用ByteBuffers進(jìn)行處理备图，但是對于原始視頻數(shù)據(jù)應(yīng)提供一個(gè)Surface以提高編解碼器的性能垄琐。Surface直接使用native視頻數(shù)據(jù)緩存赠制，而沒有映射或復(fù)制它們到ByteBuffers赂摆，因
MediaCodec采用異步方式處理數(shù)據(jù)，并且使用了一組輸入輸出緩存（ByteBuffer）钟些。通過請求一個(gè)空的輸入緩存（ByteBuffer）烟号，向其中填充滿數(shù)據(jù)并將它傳遞給編解碼器處理。編解碼器處理完這些數(shù)據(jù)并將處理結(jié)果輸出至一個(gè)空的輸出緩存（ByteBuffer）中政恍。使用完輸出緩存的數(shù)據(jù)之后汪拥，將其釋放回編解碼器：
MediaCodec的生命周期有三種狀態(tài)：停止態(tài)-Stopped、執(zhí)行態(tài)-Executing篙耗、釋放態(tài)-Released迫筑，停止?fàn)顟B(tài)（Stopped）包括了三種子狀態(tài)：未初始化（Uninitialized）、配置（Configured）宗弯、錯(cuò)誤（Error）脯燃。執(zhí)行狀態(tài)（Executing）會經(jīng)歷三種子狀態(tài)：刷新（Flushed）、運(yùn)行（Running）罕伯、流結(jié)束（End-of-Stream）：
三曲伊、MediaCodec兼容問題
MediaCodec第一次可用是在 Android 4.1版本（API16 ），一開始是用來直接訪問設(shè)備的媒體編解碼器追他。它提供了一種極其原始的接口坟募。MediaCodec類同時(shí)存在 Java和C++層中，但是只有前者是公共訪問方法邑狸。在Android 4.3 （API18）中懈糯，MediaCodec被擴(kuò)展為包含一種通過 Surface 提供輸入的方法（通過createInputSurface方法），這允許輸入來自于相機(jī)的預(yù)覽或者是經(jīng)過OpenGL ES呈現(xiàn)单雾。而且Android4.3也是 MediaCodec 的第一個(gè)經(jīng)過CTS測試（Compatibility Test Suite赚哗，CTS是google推出的一種設(shè)備兼容性測試規(guī)范她紫，用來保證不同設(shè)備一致的用戶體驗(yàn)，同時(shí)Google也提供了一份兼容性標(biāo)準(zhǔn)文檔 CDD）的 release 版本屿储。而且Android4.3還引入了MediaMuxer贿讹，它允許將AVC編解碼器（原始H.264基本流）的輸出轉(zhuǎn)換為.MP4??格式，可以和音頻流一起轉(zhuǎn)碼也可以單獨(dú)轉(zhuǎn)換够掠。Android5.0（API21）引入了“異步模式”民褂，它允許應(yīng)用程序提供一個(gè)回調(diào)方法，在緩沖區(qū)可用時(shí)執(zhí)行疯潭。但是整個(gè)文章鏈接里的代碼都沒有用到這個(gè)赊堪，因?yàn)榧嫒菪员３值紸PI 18+。
三竖哩、MediaCodec的 使用
所有的同步模式的 MediaCodec API都遵循一個(gè)模式：
- 創(chuàng)建并配置一個(gè) MediaCodec 對象
- 循環(huán)直到完成:
如果輸入緩沖區(qū)就緒哭廉，讀取一個(gè)輸入塊，并復(fù)制到輸入緩沖區(qū)中
如果輸出緩沖區(qū)就緒相叁，復(fù)制輸出緩沖區(qū)的數(shù)據(jù) - 釋放 MediaCodec 對象
MediaCodec的一個(gè)實(shí)例會處理一種類型的數(shù)據(jù)遵绰，（比如，MP3音頻或H.264視頻）增淹，編碼或是解碼街立。它對原始數(shù)據(jù)操作，所有任何的文件頭埠通，比如ID3（一般是位于一個(gè)mp3文件的開頭或末尾的若干字節(jié)內(nèi)，附加了關(guān)于該mp3的歌手逛犹，標(biāo)題端辱，專輯名稱，年代虽画，風(fēng)格等信息舞蔽，該信息就被稱為ID3信息）這些信息會被擦除。它不與任何高級的系統(tǒng)組件通信码撰，也不會通過揚(yáng)聲器來播放音頻渗柿，或是通過網(wǎng)絡(luò)來獲取視頻流數(shù)據(jù)，它只是一個(gè)會從緩沖區(qū)取數(shù)據(jù)脖岛，并返回?cái)?shù)據(jù)的中間層朵栖。
一些編解碼器對于它們的緩沖區(qū)是比較特殊的，它們可能需要一些特殊的內(nèi)存對齊或是有特定的最小最大限制柴梆，為了適應(yīng)廣泛的可能性陨溅，buffer緩沖區(qū)分配是由編解碼器自己實(shí)現(xiàn)的，而不是應(yīng)用程序的層面绍在。你并不需要一個(gè)帶有數(shù)據(jù)的緩沖區(qū)給 MediaCodec门扇，而是直接向它申請一個(gè)緩沖區(qū)雹有，然后把你的數(shù)據(jù)拷貝進(jìn)去。
這看起來和“零拷貝”原則是相悖的臼寄，但大部分情況發(fā)生拷貝的幾率是比較小的霸奕，因?yàn)榫幗獯a器并不需要復(fù)制或調(diào)整這些數(shù)據(jù)來滿足要求，而且大多數(shù)我們可以直接使用緩沖區(qū)吉拳，比如直接從磁盤或網(wǎng)絡(luò)讀取數(shù)據(jù)到緩沖區(qū)中质帅，不需要復(fù)制。
MediaCodec的輸入必須在“access units”中完成合武，在編碼H.264視頻時(shí)意味著一幀临梗，在解碼時(shí)意味著是一個(gè)NAL單元，然而稼跳，它看起來感覺更像是流盟庞，你不能提交一個(gè)單塊，并期望不久后就出現(xiàn)汤善，實(shí)際上什猖，編解碼器可能會在輸出前入隊(duì)好幾個(gè)buffers。
這里強(qiáng)烈建議直接從下面的示例代碼中學(xué)習(xí)红淡，而不是直接從官方文檔上手不狮。
例子
EncodeAndMuxTest.java (requires 4.3, API 18)
使用OpenGL ES生成一個(gè)視頻，通過 MediaCodec 使用H.264進(jìn)行編碼在旱，而且通過 MediaMuxer 將流轉(zhuǎn)換成一個(gè).MP4文件摇零，這里通過CTS 測試編寫，也可以直接轉(zhuǎn)成其他環(huán)境的代碼桶蝎。
CameraToMpegTest.java (requires 4.3, API 18)
通過相機(jī)預(yù)覽錄制視頻并且編碼成一個(gè)MP4文件驻仅，同樣通過 MediaCodec 使用H.264進(jìn)行編碼，以及 MediaMuxer 將流轉(zhuǎn)換成一個(gè).MP4文件登渣，作為一個(gè)擴(kuò)展版噪服，還通過GLES片段著色器在錄制的時(shí)候改變視頻，同樣是一個(gè)CTS test胜茧，可以轉(zhuǎn)換成其他環(huán)境的代碼粘优。
Android Breakout game recorder patch (requires 4.3, API 18)
這是 Android Breakout v1.0.2版本的一個(gè)補(bǔ)丁，添加了游戲錄制功能呻顽，游戲是在60fps的全屏分辨率下雹顺，通過一個(gè)30fps 720p的配置使用AVC編解碼器來錄制視頻，錄制文件被保存在一個(gè)應(yīng)用的私有空間廊遍，比如 ./data/data/com.faddensoft.breakout/files/video.mp4无拗。這個(gè)本質(zhì)上和 EncodeAndMuxTest.java 是一樣的，不過這個(gè)是完全的真實(shí)環(huán)境不是CTS test昧碉，一個(gè)關(guān)鍵的區(qū)別在于EGL的創(chuàng)建英染，這里允許通過將顯示和視頻context以共享紋理的方式揽惹。
EncodeDecodeTest.java (requires 4.3, API 18)
CTS test，總共有三種test做著相同的事情四康，但是是不同的方式搪搏。每一個(gè)都是：生成video的幀，通過AVC進(jìn)行編碼闪金，生成解碼流疯溺，看看是否和原始數(shù)據(jù)一樣上面的生成，編碼哎垦，解碼囱嫩，檢測基本是同時(shí)的，幀被生成后漏设，傳遞給編碼器墨闲，編碼器拿到的數(shù)據(jù)會傳遞給解碼器，然后進(jìn)行校驗(yàn)郑口，三種方式分別是Buffer到Buffer鸳碧，buffers是軟件生成的YUV幀數(shù)據(jù)，這種方式是最慢的犬性，但是能夠允許應(yīng)用程序去檢測和修改YUV數(shù)據(jù)瞻离。Buffer到Surface，編碼是一樣的乒裆，但是解碼會在surface中套利，通過OpenGL ES的 getReadPixels()進(jìn)行校驗(yàn)Surface到Surface，通過OpenGL ES生成幀并解碼到Surface中鹤耍，這是最快的方式日裙，但是需要YUV和RGB數(shù)據(jù)的轉(zhuǎn)換。
DecodeEditEncodeTest.java (requires 4.3, API 18)
CTS test惰蜜，主要是生成一系列視頻幀，通過AVC進(jìn)行編碼受神，編碼數(shù)據(jù)流保存在內(nèi)存中抛猖，使用 MediaCodec解碼，通過OpenGL ES片段著色器編輯幀數(shù)據(jù)（交換綠/藍(lán)顏色信道）鼻听，解碼編輯后的視頻流财著，驗(yàn)證輸出。
ExtractMpegFramesTest.java (requires 4.1, API 16)
ExtractMpegFramesTest.java (requires 4.2, API 17)提取一個(gè).mp4視頻文件的開始10幀撑碴，并保持成一個(gè)PNG文件到sd卡中撑教，使用
MediaExtractor 提取 CSD 數(shù)據(jù)，并將單個(gè) access units給 MediaCodec 解碼器醉拓，幀被解碼到一個(gè)SurfaceTexture的surface中伟姐，離屏渲染收苏，并通過 glReadPixels() 拿到數(shù)據(jù)后使用 Bitmap#compress() 保存成一個(gè)PNG 文件。
常見問題
Q1:我怎么播放一個(gè)由MediaCodec創(chuàng)建的“video/avc”格式的視頻流愤兵？
A1.這個(gè)被創(chuàng)建的流是原始的H.264流數(shù)據(jù)鹿霸，Linux的Totem Movie Player可以播放，但大部分其他的都播放不了秆乳，你可以使用 MediaMuxer 將其轉(zhuǎn)換為MP4文件懦鼠，看前面的EncodeAndMuxTest例子。
Q2:當(dāng)我創(chuàng)建一個(gè)編碼器時(shí)屹堰，調(diào)用 MediaCodec的configure()方法會失敗并拋出一個(gè)IllegalStateException異常肛冶？
A2.這通常是因?yàn)槟銢]有指定所有編碼器需要的關(guān)鍵命令，可以看一個(gè)這個(gè)例子 this stackoverflow item扯键。
Q3:我的視頻解碼器配置好了但是不接收數(shù)據(jù)睦袖，這是為什么？
A3.一個(gè)比較常見的錯(cuò)誤就是忽略設(shè)置Codec-Specific Data（CSD）忧陪，這個(gè)在文檔中簡略的提到過扣泊，有兩個(gè)key，“csd-0”嘶摊，“csd-1”延蟹，這個(gè)相當(dāng)于是一系列元數(shù)據(jù)的序列參數(shù)集合，我們只需要直到這個(gè)會在MediaCodec 編碼的時(shí)候生成叶堆，并且在MediaCodec 解碼的時(shí)候需要它阱飘。如果你直接把編碼器輸出傳遞給解碼器，就會發(fā)現(xiàn)第一個(gè)包里面有BUFFER_FLAG_CODEC_CONFIG 的flag虱颗，這個(gè)參數(shù)需要確保傳遞給了解碼器沥匈，這樣解碼器才會開始接收數(shù)據(jù)，或者你可以直接設(shè)置CSD數(shù)據(jù)給MediaFormat忘渔，通過configure()
方法設(shè)置給解碼器高帖，這里可以參考 EncodeDecodeTest sample 這個(gè)例子。實(shí)在不行也可以使用 MediaExtractor 畦粮，它會幫你做好一切散址。
Q4:我可以直接將流數(shù)據(jù)給解碼器么？
A4.不一定宣赔，解碼器需要的是 "access units"格式的流预麸，不一定是字節(jié)流。對于視頻解碼器儒将，這意味著你需要保存通過編碼器（比如H.264的NAL單元）創(chuàng)建的“包邊界”吏祸，這里可以參考 DecodeEditEncodeTest sample 是如何操作的，一般不能讀任意的塊數(shù)據(jù)并傳遞給解碼器钩蚊。
Q5:我在編碼由相機(jī)預(yù)覽拿到的YUV數(shù)據(jù)時(shí)贡翘，為什么看起來顏色有問題蹈矮？
A5.相機(jī)輸出的顏色格式和MediaCodec 在編碼時(shí)的輸入格式是不一樣的，相機(jī)支持YV12（平面 YUV 4:2:0） 以及 NV21 （半平面 YUV 4:2:0）床估，MediaCodec支持以下一個(gè)或多個(gè)：.#19 COLOR_FormatYUV420Planar (I420).#20 COLOR_FormatYUV420PackedPlanar (also I420).#21 COLOR_FormatYUV420SemiPlanar (NV12).#39 COLOR_FormatYUV420PackedSemiPlanar (also NV12).#0x7f000100 COLOR_TI_FormatYUV420PackedSemiPlanar (also also NV12)I420的數(shù)據(jù)布局相當(dāng)于YV12含滴，但是Cr和Cb卻是顛倒的，就像NV12和NV21一樣丐巫。所以如果你想要去處理相機(jī)拿到的YV12數(shù)據(jù)谈况，可能會看到一些奇怪的顏色干擾，比如這樣 these images递胧。直到Android4.4版本碑韵，依然沒有統(tǒng)一的輸入格式，比如Nexus 7（2012）缎脾，Nexus 10使用的COLOR_FormatYUV420Planar祝闻，而Nexus 4, Nexus 5, and Nexus 7（2013）使用的是COLOR_FormatYUV420SemiPlanar，而Galaxy Nexus使用的COLOR_TI_FormatYUV420PackedSemiPlanar遗菠。一種可移植性更高联喘，更有效率的方式就是使用API18 的Surface input API，這個(gè)在 CameraToMpegTest sample 中已經(jīng)演示了辙纬，這樣做的缺點(diǎn)就是你必須去操作RGB而不是YUV數(shù)據(jù)豁遭，這是一個(gè)圖像處理的問題，如果你可以通過片段著色器來實(shí)現(xiàn)圖像操作贺拣，可以利用GPU來處理這些轉(zhuǎn)換和計(jì)算蓖谢。
Q6: EGL_RECORDABLE_ANDROID
flag是用來干什么的？
A6.這會告訴EGL譬涡，創(chuàng)建surface的行為必須是視頻編解碼器能兼容的闪幽，沒有這個(gè)flag，EGL可能使用 MediaCodec 不能理解的格式來操作涡匀。
Q7:我是不是必須要在編碼時(shí)設(shè)置 presentation time stamp （pts）盯腌？
A7.是的，一些設(shè)備如果沒有設(shè)置合理的值陨瘩，那么在編碼的時(shí)候就會采取丟棄幀和低質(zhì)量編碼的方式腕够。需要注意的一點(diǎn)就是MediaCodec所需要的time格式是微秒，大部分java代碼中的都是毫秒或者納秒拾酝。
Q8:為什么有時(shí)輸出混亂（比如都是零，或者太短等等）卡者？
A8.這常見的錯(cuò)誤就是沒有去適配ByteBuffer的position和limit蒿囤，這些東西MediaCodec并沒有自動(dòng)的去做，我們需要手動(dòng)的加上一些代碼：
int bufIndex = codec.dequeueOutputBuffer(info, TIMEOUT); ByteBuffer outputData = outputBuffers[bufIndex]; if (info.size != 0) { outputData.position(info.offset); outputData.limit(info.offset + info.size); }
在輸入端崇决，你需要在將數(shù)據(jù)復(fù)制到緩沖區(qū)之前調(diào)用clear()材诽。
Q9: 有時(shí)候會發(fā)現(xiàn)storeMetaDataInBuffers會打出一些錯(cuò)誤log底挫？
A9.是的，比如在Nexus 5上脸侥，看起來是這樣的
E OMXNodeInstance: OMX_SetParameter() failed for StoreMetaDataInBuffers: 0x8000101aE ACodec : [OMX.qcom.video.encoder.avc] storeMetaDataInBuffers (output) failed w/ err -2147483648
參考文章
http://www.reibang.com/p/1e298f993398
http://www.reibang.com/p/3c479c0f4876
