原文地址
這篇文章是關(guān)于 MediaCodec 這一系列類，它主要是用來編碼和解碼音視頻數(shù)據(jù)。并且包含了一些源碼示例的集合以及常見問題的解答。
在API23之后，官方的文檔 official 就已經(jīng)十分的詳細(xì)了。這里的一些信息可以幫你了解一些編解碼方面的知識，為了考慮兼容性，這里的代碼大部分都是運行在API18及以上的環(huán)境中，當(dāng)然如果你的目標(biāo)是Lollipop 以上的用戶，你可以有更多的選擇，這些都沒有在這里提及。
概述
MediaCodec 第一次可用是在 Android 4.1版本（API16 ），一開始是用來直接訪問設(shè)備的媒體編解碼器。它提供了一種極其原始的接口。MediaCodec類同時存在 Java和C++層中，但是只有前者是公共訪問方法。
在Android 4.3 （API18）中，MediaCodec被擴(kuò)展為包含一種通過 Surface 提供輸入的方法（通過 createInputSurface 方法），這允許輸入來自于相機(jī)的預(yù)覽或者是經(jīng)過OpenGL ES呈現(xiàn)。而且Android4.3也是 MediaCodec 的第一個經(jīng)過CTS測試（Compatibility Test Suite，CTS是google推出的一種設(shè)備兼容性測試規(guī)范，用來保證不同設(shè)備一致的用戶體驗，同時Google也提供了一份兼容性標(biāo)準(zhǔn)文檔 CDD）的 release 版本。
而且Android4.3還引入了 MediaMuxer，它允許將AVC編解碼器（原始H.264基本流）的輸出轉(zhuǎn)換為.MP4??格式，可以和音頻流一起轉(zhuǎn)碼也可以單獨轉(zhuǎn)換。
Android5.0（API21）引入了“異步模式”，它允許應(yīng)用程序提供一個回調(diào)方法，在緩沖區(qū)可用時執(zhí)行。但是整個文章鏈接里的代碼都沒有用到這個，因為兼容性保持到API 18+。
基本使用
所有的同步模式的 MediaCodec API都遵循一個模式：
- 創(chuàng)建并配置一個
MediaCodec對象 - 循環(huán)直到完成:
如果輸入緩沖區(qū)就緒，讀取一個輸入塊，并復(fù)制到輸入緩沖區(qū)中
如果輸出緩沖區(qū)就緒，復(fù)制輸出緩沖區(qū)的數(shù)據(jù) - 釋放
MediaCodec對象
MediaCodec的一個實例會處理一種類型的數(shù)據(jù)，（比如，MP3音頻或H.264視頻），編碼或是解碼。它對原始數(shù)據(jù)操作，所有任何的文件頭，比如ID3（一般是位于一個mp3文件的開頭或末尾的若干字節(jié)內(nèi)，附加了關(guān)于該mp3的歌手，標(biāo)題，專輯名稱，年代，風(fēng)格等信息，該信息就被稱為ID3信息）這些信息會被擦除。它不與任何高級的系統(tǒng)組件通信，也不會通過揚聲器來播放音頻，或是通過網(wǎng)絡(luò)來獲取視頻流數(shù)據(jù)，它只是一個會從緩沖區(qū)取數(shù)據(jù)，并返回數(shù)據(jù)的中間層。
一些編解碼器對于它們的緩沖區(qū)是比較特殊的，它們可能需要一些特殊的內(nèi)存對齊或是有特定的最小最大限制，為了適應(yīng)廣泛的可能性，buffer緩沖區(qū)分配是由編解碼器自己實現(xiàn)的，而不是應(yīng)用程序的層面。你并不需要一個帶有數(shù)據(jù)的緩沖區(qū)給 MediaCodec，而是直接向它申請一個緩沖區(qū)，然后把你的數(shù)據(jù)拷貝進(jìn)去。
這看起來和“零拷貝”原則是相悖的，但大部分情況發(fā)生拷貝的幾率是比較小的，因為編解碼器并不需要復(fù)制或調(diào)整這些數(shù)據(jù)來滿足要求，而且大多數(shù)我們可以直接使用緩沖區(qū)，比如直接從磁盤或網(wǎng)絡(luò)讀取數(shù)據(jù)到緩沖區(qū)中，不需要復(fù)制。
MediaCodec的輸入必須在“access units”中完成，在編碼H.264視頻時意味著一幀，在解碼時意味著是一個NAL單元，然而，它看起來感覺更像是流，你不能提交一個單塊，并期望不久后就出現(xiàn)，實際上，編解碼器可能會在輸出前入隊好幾個buffers。
這里強(qiáng)烈建議直接從下面的示例代碼中學(xué)習(xí)，而不是直接從官方文檔上手。
例子
EncodeAndMuxTest.java (requires 4.3, API 18)
使用OpenGL ES生成一個視頻，通過 MediaCodec 使用H.264進(jìn)行編碼，而且通過 MediaMuxer 將流轉(zhuǎn)換成一個.MP4文件，這里通過CTS 測試編寫，也可以直接轉(zhuǎn)成其他環(huán)境的代碼。
CameraToMpegTest.java (requires 4.3, API 18)
通過相機(jī)預(yù)覽錄制視頻并且編碼成一個MP4文件，同樣通過 MediaCodec 使用H.264進(jìn)行編碼，以及 MediaMuxer 將流轉(zhuǎn)換成一個.MP4文件，作為一個擴(kuò)展版，還通過GLES片段著色器在錄制的時候改變視頻，同樣是一個CTS test，可以轉(zhuǎn)換成其他環(huán)境的代碼。
Android Breakout game recorder patch (requires 4.3, API 18)
這是 Android Breakout v1.0.2版本的一個補丁，添加了游戲錄制功能，游戲是在60fps的全屏分辨率下，通過一個30fps 720p的配置使用AVC編解碼器來錄制視頻，錄制文件被保存在一個應(yīng)用的私有空間，比如 ./data/data/com.faddensoft.breakout/files/video.mp4。這個本質(zhì)上和 EncodeAndMuxTest.java 是一樣的，不過這個是完全的真實環(huán)境不是CTS test，一個關(guān)鍵的區(qū)別在于EGL的創(chuàng)建，這里允許通過將顯示和視頻context以共享紋理的方式。
EncodeDecodeTest.java (requires 4.3, API 18)
CTS test，總共有三種test做著相同的事情，但是是不同的方式。每一個都是：
生成video的幀，通過AVC進(jìn)行編碼，生成解碼流，看看是否和原始數(shù)據(jù)一樣
上面的生成，編碼，解碼，檢測基本是同時的，幀被生成后，傳遞給編碼器，編碼器拿到的數(shù)據(jù)會傳遞給解碼器，然后進(jìn)行校驗，三種方式分別是
Buffer到Buffer，buffers是軟件生成的YUV幀數(shù)據(jù)，這種方式是最慢的，但是能夠允許應(yīng)用程序去檢測和修改YUV數(shù)據(jù)。
Buffer到Surface，編碼是一樣的，但是解碼會在surface中，通過OpenGL ES的 getReadPixels()進(jì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)顏色信道），解碼編輯后的視頻流，驗證輸出。
ExtractMpegFramesTest.java (requires 4.1, API 16)
ExtractMpegFramesTest.java (requires 4.2, API 17)
提取一個.mp4視頻文件的開始10幀，并保持成一個PNG文件到sd卡中，使用 MediaExtractor 提取 CSD 數(shù)據(jù)，并將單個 access units給 MediaCodec 解碼器，幀被解碼到一個SurfaceTexture的surface中，離屏渲染，并通過 glReadPixels() 拿到數(shù)據(jù)后使用 Bitmap#compress() 保存成一個PNG 文件。
常見問題
Q1:我怎么播放一個由MediaCodec創(chuàng)建的“video/avc”格式的視頻流？
A1.這個被創(chuàng)建的流是原始的H.264流數(shù)據(jù)，Linux的Totem Movie Player可以播放，但大部分其他的都播放不了，你可以使用 MediaMuxer 將其轉(zhuǎn)換為MP4文件，看前面的EncodeAndMuxTest例子。
Q2:當(dāng)我創(chuàng)建一個編碼器時，調(diào)用 MediaCodec的configure()方法會失敗并拋出一個IllegalStateException異常？
A2.這通常是因為你沒有指定所有編碼器需要的關(guān)鍵命令，可以看一個這個例子 this stackoverflow item。
Q3:我的視頻解碼器配置好了但是不接收數(shù)據(jù)，這是為什么？
A3.一個比較常見的錯誤就是忽略設(shè)置Codec-Specific Data（CSD），這個在文檔中簡略的提到過，有兩個key，“csd-0”，“csd-1”，這個相當(dāng)于是一系列元數(shù)據(jù)的序列參數(shù)集合，我們只需要直到這個會在MediaCodec 編碼的時候生成，并且在MediaCodec 解碼的時候需要它。
如果你直接把編碼器輸出傳遞給解碼器，就會發(fā)現(xiàn)第一個包里面有BUFFER_FLAG_CODEC_CONFIG 的flag，這個參數(shù)需要確保傳遞給了解碼器，這樣解碼器才會開始接收數(shù)據(jù)，或者你可以直接設(shè)置CSD數(shù)據(jù)給MediaFormat，通過 configure() 方法設(shè)置給解碼器，這里可以參考 EncodeDecodeTest sample 這個例子。
實在不行也可以使用 MediaExtractor ，它會幫你做好一切。
Q4:我可以直接將流數(shù)據(jù)給解碼器么？
A4.不一定，解碼器需要的是 "access units"格式的流，不一定是字節(jié)流。對于視頻解碼器，這意味著你需要保存通過編碼器（比如H.264的NAL單元）創(chuàng)建的“包邊界”，這里可以參考 DecodeEditEncodeTest sample 是如何操作的，一般不能讀任意的塊數(shù)據(jù)并傳遞給解碼器。
Q5:我在編碼由相機(jī)預(yù)覽拿到的YUV數(shù)據(jù)時，為什么看起來顏色有問題？
A5.相機(jī)輸出的顏色格式和MediaCodec 在編碼時的輸入格式是不一樣的，相機(jī)支持YV12（平面 YUV 4:2:0） 以及 NV21 （半平面 YUV 4:2:0），MediaCodec支持以下一個或多個：
.#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，這個在 CameraToMpegTest sample 中已經(jīng)演示了，這樣做的缺點就是你必須去操作RGB而不是YUV數(shù)據(jù)，這是一個圖像處理的問題，如果你可以通過片段著色器來實現(xiàn)圖像操作，可以利用GPU來處理這些轉(zhuǎn)換和計算。
Q6: EGL_RECORDABLE_ANDROID flag是用來干什么的？
A6.這會告訴EGL，創(chuàng)建surface的行為必須是視頻編解碼器能兼容的，沒有這個flag，EGL可能使用 MediaCodec 不能理解的格式來操作。
Q7:我是不是必須要在編碼時設(shè)置 presentation time stamp （pts）？
A7.是的，一些設(shè)備如果沒有設(shè)置合理的值，那么在編碼的時候就會采取丟棄幀和低質(zhì)量編碼的方式。
需要注意的一點就是MediaCodec所需要的time格式是微秒，大部分java代碼中的都是毫秒或者納秒。
Q8:為什么有時輸出混亂（比如都是零，或者太短等等）？
A8.這常見的錯誤就是沒有去適配ByteBuffer的position和limit，這些東西MediaCodec并沒有自動的去做，
我們需要手動的加上一些代碼：
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: 有時候會發(fā)現(xiàn) storeMetaDataInBuffers 會打出一些錯誤log？
A9.是的，比如在Nexus 5上，看起來是這樣的
E OMXNodeInstance: OMX_SetParameter() failed for StoreMetaDataInBuffers: 0x8000101a
E ACodec : [OMX.qcom.video.encoder.avc] storeMetaDataInBuffers (output) failed w/ err -2147483648
不過可以忽略這些，不會出現(xiàn)什么問題。
