【移動應用開發(fā)技術】Android音頻開發(fā)（5）：音頻數據的編解碼

【移動應用開發(fā)技術】Android音頻開發(fā)（5）：音頻數據的編解碼

前面四篇文章分別介紹了音頻開發(fā)必備的基礎知識、如何采集一幀音頻、如何播放一幀音頻、如何存儲和解析wav格式的文件，建議有興趣的小伙伴們先讀一讀，本文則重點關注如何對一幀音頻數據進行編碼和解碼。1.Android官方的MediaCodecAPI首先，我們了解一下Android官方提供的音頻編解碼的API，即MediaCodec類，該API是在Andorid4.1（API16）版本引入的，因此只能工作于Android4.1以上的手機上。1.1MediaCodec基本介紹（1）提供了一套訪問Android底層多媒體模塊的接口，主要是音視頻的編解碼接口（2）Android底層多媒體模塊采用的是OpenMax框架，任何Android底層編解碼模塊的實現，都必須遵循OpenMax標準。Google官方默認提供了一系列的軟件編×××：包括：OMX.google.h364.encoder，OMX.google.h364.encoder，OMX.google.aac.encoder，OMX.google.aac.decoder等等，而硬件編解碼功能，則需要由芯片廠商依照OpenMax框架標準來完成，所以，一般采用不同芯片型號的手機，硬件編解碼的實現和性能是不同的（3）Android應用層統(tǒng)一由MediaCodecAPI來提供各種音視頻編解碼功能，由參數配置來決定采用何種編解碼算法、是否采用硬件編解碼加速等等1.2MediaCodec核心原理我不準備詳細介紹MediaCodecAPI的每個函數是怎么用，示例代碼大家可以在后面給出的資源鏈接中查看和學習。這里我準備重點介紹一下MediaCodec的核心工作原理，因為只有搞清楚了這一點，你才會明白為什么MediaCodecAPI提供的接口是這個樣子的。MediaCodec使用的基本流程是：-

createEncoderByType/createDecoderByType

-

configure

-

start

-

while(1)

{

-

dequeueInputBuffer

-

queueInputBuffer

-

dequeueOutputBuffer

-

releaseOutputBuffer

}

-

stop

-

release由此可以看到，Buffer隊列的操作是其最核心的部分之一，關于MediaCodec的Buffer隊列，示意圖如下：MediaCodec架構上采用了2個緩沖區(qū)隊列，異步處理數據，下面描述的Client和MediaCodec模塊是并行工作的（注：這里的Client就是指“開發(fā)者，API的使用者”）：（1）Client從input緩沖區(qū)隊列申請emptybuffer[dequeueInputBuffer]（2）Client把需要編解碼的數據拷貝到emptybuffer，然后放入

input

緩沖區(qū)隊列[queueInputBuffer]

（3）MediaCodec模塊從input

緩沖區(qū)隊列取一幀數據進行編解碼處理（4）編解碼處理結束后，MediaCodec將原始數據buffer置為empty后放回input緩沖區(qū)隊列，將編解碼后的數據放入到output緩沖區(qū)隊列（5）Client從output緩沖區(qū)隊列申請編解碼后的buffer

[dequeueOutputBuffer]（6）Client對編解碼后的buffer進行渲染/播放（7）渲染/播放完成后，Client再將該buffer放回output緩沖區(qū)隊列[releaseOutputBuffer]MediaCodec在架構上，其實是采用了一種基于“環(huán)形緩沖區(qū)”的“生產者-消費者”模式，它設計了2個基于idx序號的“環(huán)形緩沖區(qū)”，注意，是2個，一個在input端，一個在output端。我曾經在Github上分享過一段LinuxC代碼，名叫：“rw_queue”，就是這種環(huán)形緩沖區(qū)的簡化版，大家有興趣可以看看，地址：/Jhuster/clib/tree/master/rw_queue基于idx的環(huán)形緩沖區(qū)的總體示意圖如下，圖中，wp代表“寫指針”，指向的是“emptybuffer”，而rp代表“讀指針”，指向的是“filledbuffer”：“生產者”和“消費者”其實是共用這一個緩沖區(qū)隊列，“生產者”負責從隊列中取出未使用的Buffer，填入數據，然后放回隊列，“消費者”則負責取出填入數據后的Buffer，進行處理，處理結束后，再把Buffer標記為“空”，退回到隊列中去以供“生產者”繼續(xù)填充數據。在input端，“Client”是這個環(huán)形緩沖區(qū)“生產者”，“MediaoCodec模塊”是“消費者”。在output端，“MediaoCodec模塊”是這個環(huán)形緩沖區(qū)“生產者”，而“Client”則變成了“消費者”。這就是其核心的工作原理，其實并不復雜，大家靜下心來，很快就能理解其中的奧妙。1.3

參考資源關于MediaCodec的示例代碼，網上其實也很多了，我就直接給出一些個人覺得不錯的鏈接，有興趣的小伙伴們可以去研究一下。（1）Android官方文檔：《MediaCodec》（2）《AndroidMediaCodecstuff》（3）《HWEncoderExperiments》（4）一些開源的播放器Android源碼，如VLC、ijkplayer2.第三方音頻編解碼的庫官方的MediaCodecAPI雖然支持硬件編解碼加速，但是問題和局限還是很多的，一方面是只能在Android4.1以上機型上才能使用，另一方面，由于Android手機種類繁多，廠商對底層源碼的修改各不相同，導致MediaCodecAPI在實際使用中，會遇到很多坑，有很多兼容性的問題，因此，我們也可以考慮采用第三方的編解碼庫。這里，我簡單推薦幾款第三方音頻編解碼庫（可以移植到Android平臺的），大家可以直接去官網或者項目主頁了解其詳細信息。（1）opus編解碼庫很喜歡opus，低碼率下opus完勝曾經優(yōu)勢明顯的HEAAC，我曾經用它實現了一款Android局域網的VoIP網絡電話應用：“飛鴿電話”，效果很不錯。opus官網地址：注：如今Android5.0已經官方支持opus格式了，關于Android支持的多媒體格式列表可以查看Androiddeveloperguide：《SupportedMediaFormats》（2）Speex編解碼庫老牌的音頻處理庫，不僅是編解碼，還提供了包括音頻去噪、回聲消除、靜音檢測等功能，官網地址：（3）ffmpeg大名鼎鼎的ffmpeg肯定不能錯過，官網：（4）AndroidAACEncoder一款輕量級的Androidaac編碼庫：/timsu/android-aac-enc（5）opencore-amr-android從opencore抽取出來的amr編解碼庫，地址：/kevinho/opencore-amr-android（6）iLBC-AndroidiLBC是著名的WebRTC項目的音頻編解碼模塊，iLBC-Android是從中抽取iLBC模塊移植到Android平臺的個人項目，地址：/lukeweber/iLBC-Android關于第三方編解碼庫就簡單介紹到這里了，