音頻的編解碼（codec）根據(jù)應(yīng)用場(chǎng)景的不同主要由幾大技術(shù)組織制定，分別是ITU-T、3GPP、MPEG。當(dāng)然也有一些公司或者公司的聯(lián)合體等制定，如微軟的WMA。他們不僅制定了codec的規(guī)范，同時(shí)還提供軟件實(shí)現(xiàn)的reference code，這樣便于普及制定的codec的使用。本文先談?wù)勥@些codec，然后講怎么樣根據(jù)reference code去優(yōu)化codec（主要是減少CPU load）。

1）ITU-T

ITU-T制定的是有線語音的codec標(biāo)準(zhǔn)，即G系列，主要有G.711、G.722、G.726、G.728、G.729等。采樣率窄帶是8KHz，寬帶是16KHz。碼率從64kbps到8kbps不等。

下表列出了具體的采樣率和碼率。

2）3GPP

3GPP制定的是移動(dòng)語音的codec標(biāo)準(zhǔn)，主要是AMR（adapTIve mulTI-rate，自適應(yīng)多碼率）系列等，能根據(jù)網(wǎng)絡(luò)狀況自適應(yīng)的調(diào)整碼率。采樣率窄帶是8KHz，寬帶是16KHz。近年來為了應(yīng)對(duì)互聯(lián)網(wǎng)的競(jìng)爭(zhēng)（互聯(lián)網(wǎng)公司提出了涵蓋語音和音樂的OPUS codec），3GPP出臺(tái)了EVS（enhanced voice service）音頻編解碼規(guī)范。EVS也涵蓋了語音和音樂，能在兩者之間靈活切換，支持多種采樣率和碼率。具體如下表。

3）MPEG

MPEG制定的主要是音樂的編解碼規(guī)范，主要有MP3、AAC等。MP3大家都很熟悉，是近二十年來聽音樂的最主要的格式，AAC是MP3的繼承者，下一代的最主要的音樂編解碼規(guī)范。音樂中采樣率一般是44100HZ，也有的用48000HZ。碼率在一個(gè)范圍內(nèi)，碼率越大，音質(zhì)越好。

4）公司或公司聯(lián)合體

一些公司或者公司聯(lián)合體根據(jù)需要制定音頻的編解碼規(guī)范，比如微軟的WMA，Skype的SILK，GIPS（GIPS在2011年被谷歌收購(gòu)，谷歌基于GIPS的音視頻解決方案推出了webRTC并開源出來，影響巨大）的ILBC等。還有一個(gè)不得不提的就是OPUS，它是由非盈利的Xiph.org 基金會(huì)、Skype 和Mozilla 等共同主導(dǎo)開發(fā)的，全頻段（8kHZ到48kHZ）,支持語音和音樂（語音用SILK, 音樂用CELT），已被IETF接納成為網(wǎng)絡(luò)上的聲音編解碼標(biāo)準(zhǔn)（RFC6716）。

我用過的codec從語音到音樂分別有G.711/G.722/G.726/G.728/G.729/AMR-NB/AMR-WB/ILBC/OPUS/MP3/AAC/WMA/APE/Vorbis/ALAC/FLAC等。

這里講的優(yōu)化主要是指CPU load的優(yōu)化，即優(yōu)化后運(yùn)行codec占用更少的CPU，在具體的硬件平臺(tái)上運(yùn)行的更流暢。優(yōu)化到什么程度算結(jié)束這依賴需求而定。如果優(yōu)化后給所在項(xiàng)目用，就要看項(xiàng)目給你多長(zhǎng)時(shí)間優(yōu)化以及項(xiàng)目能接受的優(yōu)化后的CPU load，一般情況下項(xiàng)目用上優(yōu)化后的codec后在最復(fù)雜的場(chǎng)景下能流暢運(yùn)行又不影響其他功能就可以了，因?yàn)轫?xiàng)目上要騰出人手做其他事情，畢竟項(xiàng)目進(jìn)度和質(zhì)量是最重要的。如果優(yōu)化后作為庫賣給客戶用，就要盡量?jī)?yōu)化到極致，因?yàn)檫@是用戶選擇用哪家公司庫的重要指標(biāo)，是賣點(diǎn)，這種情況下就會(huì)有更多的優(yōu)化方法和技巧。我做過的優(yōu)化都是給項(xiàng)目用，沒有作為庫給客戶用，因而技巧不是特別多。

（1）優(yōu)化前的準(zhǔn)備工作

a）通讀一下要優(yōu)化的codec的代碼，盡量讀懂，即使沒懂也要搞清楚函數(shù)是干什么的，這有利于后面優(yōu)化。

b）準(zhǔn)備好profiling工具，profiling工具就是測(cè)量運(yùn)行某個(gè)函數(shù)花了多少clock。有現(xiàn)成的profiling工具最好，如果沒有就根據(jù)具體OS和硬件平臺(tái)（ARM/MIPS等）自己做工具。

c）準(zhǔn)備好test vector，即測(cè)試的音源，一般codec制定的官方會(huì)提供，通常是多個(gè)vector, 對(duì)應(yīng)于不同的場(chǎng)景。優(yōu)化的原則是在減少CPU load的同時(shí)算法運(yùn)算結(jié)果不被改變，所以在做優(yōu)化時(shí)每?jī)?yōu)化一些就要用test vector跑一下，看結(jié)果有沒有改變，如果改變了，就要退回到上一個(gè)版本。我做優(yōu)化時(shí)每天至少保留一個(gè)版本，有時(shí)兩個(gè)或者三個(gè)，就是為了出問題時(shí)好回溯，盡快查出哪個(gè)地方的優(yōu)化出了問題。

（2）優(yōu)化步驟與方法

a）將編譯器的優(yōu)化選項(xiàng)從-o0改為-o3

b）給代碼中那些經(jīng)常被調(diào)用的又短小的函數(shù)加上inline

通常情況下做完a,b后load會(huì)下來一大截，如同擠泡沫一樣，會(huì)擠掉很大一部分。

c）ITU-T或者3GPP的codec reference code中有好多基本運(yùn)算（加減乘除）的函數(shù)，這些函數(shù)都寫的特別嚴(yán)謹(jǐn)，同時(shí)調(diào)用的頻次又非常高，因而加大了運(yùn)算復(fù)雜度。這些函數(shù)中有些在保證正確的前提下可以簡(jiǎn)化（如一些防飽和就可以不要），這樣處理后load會(huì)降下來一些。

d）用profiling工具一步步排查看到底哪個(gè)函數(shù)花的load多，明白這個(gè)函數(shù)是干什么的，然后具體問題具體分析，看怎么樣來優(yōu)化。

e）有些函數(shù)就是一個(gè)小算法，reference code中寫的比較復(fù)雜，調(diào)用頻次又比較高。要去找有沒有簡(jiǎn)單的實(shí)現(xiàn)可以替代，有的話替代了load就會(huì)降下來一些。比如codec中經(jīng)常有求平方根的計(jì)算，reference code中通常寫的比較復(fù)雜。我們知道用牛頓迭代法也可以求平方根，就可以用牛頓迭代法去替換將load降下來。

f）用匯編優(yōu)化。如果在C級(jí)別能解決問題就不要用匯編了。各個(gè)處理器都有自己的匯編指令集，需要去學(xué)并且掌握其中的思想和技巧。通常是用的頻次較高的又比較占load的函數(shù)用匯編去寫，即用C和匯編混合編程。匯編優(yōu)化花的時(shí)間會(huì)相對(duì)長(zhǎng)一些。

當(dāng)然還有一些小的技巧比如展開for循環(huán)、用指針替代數(shù)組等，這里就不一一說了。