androidpcmaac

『壹』 Android -- 音視頻基礎知識

幀，是視頻的一個基本概念，表示一張畫面，如上面的翻頁動畫書中的一頁，就是一幀。一個視頻就是由許許多多幀組成的。

幀率，即單位時間內幀的數量，單位為：幀/秒 或fps（frames per second）。一秒內包含多少張圖片，圖片越多，畫面越順滑，過渡越自然。 幀率的一般以下幾個典型值：

24/25 fps：1秒 24/25 幀，一般的電影幀率。

30/60 fps：1秒 30/60 幀，游戲的幀率，30幀可以接受，60幀會感覺更加流暢逼真。

85 fps以上人眼基本無法察覺出來了，所以更高的幀率在視頻里沒有太大意義。

這里我們只講常用到的兩種色彩空間。

RGB的顏色模式應該是我們最熟悉的一種，在現在的電子設備中應用廣泛。通過R G B三種基礎色，可以混合出所有的顏色。

這里著重講一下YUV，這種色彩空間並不是我們熟悉的。這是一種亮度與色度分離的色彩格式。

早期的電視都是黑白的，即只有亮度值，即Y。有了彩色電視以後，加入了UV兩種色度，形成現在的YUV，也叫YCbCr。

Y：亮度，就是灰度值。除了表示亮度信號外，還含有較多的綠色通道量。

U：藍色通道與亮度的差值。

V：紅色通道與亮度的差值。

音頻數據的承載方式最常用的是 脈沖編碼調制 ，即 PCM 。

在自然界中，聲音是連續不斷的，是一種模擬信號，那怎樣才能把聲音保存下來呢？那就是把聲音數字化，即轉換為數字信號。

我們知道聲音是一種波，有自己的振幅和頻率，那麼要保存聲音，就要保存聲音在各個時間點上的振幅。

而數字信號並不能連續保存所有時間點的振幅，事實上，並不需要保存連續的信號，就可以還原到人耳可接受的聲音。

根據奈奎斯特采樣定理：為了不失真地恢復模擬信號，采樣頻率應該不小於模擬信號頻譜中最高頻率的2倍。

根據以上分析，PCM的採集步驟分為以下步驟：

采樣率，即采樣的頻率。

上面提到，采樣率要大於原聲波頻率的2倍，人耳能聽到的最高頻率為20kHz，所以為了滿足人耳的聽覺要求，采樣率至少為40kHz，通常為44.1kHz，更高的通常為48kHz。

采樣位數，涉及到上面提到的振幅量化。波形振幅在模擬信號上也是連續的樣本值，而在數字信號中，信號一般是不連續的，所以模擬信號量化以後，只能取一個近似的整數值，為了記錄這些振幅值，采樣器會採用一個固定的位數來記錄這些振幅值，通常有8位、16位、32位。

位數越多，記錄的值越准確，還原度越高。

最後就是編碼了。由於數字信號是由0，1組成的，因此，需要將幅度值轉換為一系列0和1進行存儲，也就是編碼，最後得到的數據就是數字信號：一串0和1組成的數據。

整個過程如下：

聲道數，是指支持能不同發聲（注意是不同聲音）的音響的個數。 單聲道：1個聲道
雙聲道：2個聲道
立體聲道：默認為2個聲道
立體聲道（4聲道）：4個聲道

碼率，是指一個數據流中每秒鍾能通過的信息量，單位bps（bit per second）

碼率 = 采樣率 * 采樣位數 * 聲道數

這里的編碼和上面音頻中提到的編碼不是同個概念，而是指壓縮編碼。

我們知道，在計算機的世界中，一切都是0和1組成的，音頻和視頻數據也不例外。由於音視頻的數據量龐大，如果按照裸流數據存儲的話，那將需要耗費非常大的存儲空間，也不利於傳送。而音視頻中，其實包含了大量0和1的重復數據，因此可以通過一定的演算法來壓縮這些0和1的數據。

特別在視頻中，由於畫面是逐漸過渡的，因此整個視頻中，包含了大量畫面/像素的重復，這正好提供了非常大的壓縮空間。

因此，編碼可以大大減小音視頻數據的大小，讓音視頻更容易存儲和傳送。

視頻編碼格式有很多，比如H26x系列和MPEG系列的編碼，這些編碼格式都是為了適應時代發展而出現的。

其中，H26x（1/2/3/4/5）系列由ITU（International Telecommunication Union）國際電傳視訊聯盟主導

MPEG（1/2/3/4）系列由MPEG（Moving Picture Experts Group, ISO旗下的組織）主導。

當然，他們也有聯合制定的編碼標准，那就是現在主流的編碼格式H264，當然還有下一代更先進的壓縮編碼標准H265。

H264是目前最主流的視頻編碼標准，所以我們後續的文章中主要以該編碼格式為基準。

H264由ITU和MPEG共同定製，屬於MPEG-4第十部分內容。

我們已經知道，視頻是由一幀一幀畫面構成的，但是在視頻的數據中，並不是真正按照一幀一幀原始數據保存下來的（如果這樣，壓縮編碼就沒有意義了）。

H264會根據一段時間內，畫面的變化情況，選取一幀畫面作為完整編碼，下一幀只記錄與上一幀完整數據的差別，是一個動態壓縮的過程。

在H264中，三種類型的幀數據分別為

I幀：幀內編碼幀。就是一個完整幀。

P幀：前向預測編碼幀。是一個非完整幀，通過參考前面的I幀或P幀生成。

B幀：雙向預測內插編碼幀。參考前後圖像幀編碼生成。B幀依賴其前最近的一個I幀或P幀及其後最近的一個P幀。

全稱：Group of picture。指一組變化不大的視頻幀。

GOP的第一幀成為關鍵幀：IDR

IDR都是I幀，可以防止一幀解碼出錯，導致後面所有幀解碼出錯的問題。當解碼器在解碼到IDR的時候，會將之前的參考幀清空，重新開始一個新的序列，這樣，即便前面一幀解碼出現重大錯誤，也不會蔓延到後面的數據中。

DTS全稱：Decoding Time Stamp。標示讀入內存中數據流在什麼時候開始送入解碼器中進行解碼。也就是解碼順序的時間戳。

PTS全稱：Presentation Time Stamp。用於標示解碼後的視頻幀什麼時候被顯示出來。

前面我們介紹了RGB和YUV兩種圖像色彩空間。H264採用的是YUV。

YUV存儲方式分為兩大類：planar 和 packed。

planar如下：

packed如下：

上面說過，由於人眼對色度敏感度低，所以可以通過省略一些色度信息，即亮度共用一些色度信息，進而節省存儲空間。因此，planar又區分了以下幾種格式：YUV444、 YUV422、YUV420。

YUV 4:4:4采樣，每一個Y對應一組UV分量。

YUV 4:2:2采樣，每兩個Y共用一組UV分量。

YUV 4:2:0采樣，每四個Y共用一組UV分量。

其中，最常用的就是YUV420。

YUV420屬於planar存儲方式，但是又分兩種類型：

YUV420P：三平面存儲。數據組成為YYYYYYYYUUVV（如I420）或YYYYYYYYVVUU（如YV12）。

YUV420SP：兩平面存儲。分為兩種類型YYYYYYYYUVUV（如NV12）或YYYYYYYYVUVU（如NV21）

原始的PCM音頻數據也是非常大的數據量，因此也需要對其進行壓縮編碼。

和視頻編碼一樣，音頻也有許多的編碼格式，如：WAV、MP3、WMA、APE、FLAC等等，音樂發燒友應該對這些格式非常熟悉，特別是後兩種無損壓縮格式。

但是，我們今天的主角不是他們，而是另外一個叫AAC的壓縮格式。

AAC是新一代的音頻有損壓縮技術，一種高壓縮比的音頻壓縮演算法。在MP4視頻中的音頻數據，大多數時候都是採用AAC壓縮格式。

AAC格式主要分為兩種：ADIF、ADTS。

ADIF：Audio Data Interchange Format。音頻數據交換格式。這種格式的特徵是可以確定的找到這個音頻數據的開始，不需進行在音頻數據流中間開始的解碼，即它的解碼必須在明確定義的開始處進行。這種格式常用在磁碟文件中。

ADTS：Audio Data Transport Stream。音頻數據傳輸流。這種格式的特徵是它是一個有同步字的比特流，解碼可以在這個流中任何位置開始。它的特徵類似於mp3數據流格式。

ADIF數據格式：

ADTS 一幀 數據格式（中間部分，左右省略號為前後數據幀）：

AAC內部結構也不再贅述，可以參考AAC 文件解析及解碼流程

細心的讀者可能已經發現，前面我們介紹的各種音視頻的編碼格式，沒有一種是我們平時使用到的視頻格式，比如：mp4、rmvb、avi、mkv、mov...

沒錯，這些我們熟悉的視頻格式，其實是包裹了音視頻編碼數據的容器，用來把以特定編碼標准編碼的視頻流和音頻流混在一起，成為一個文件。

例如：mp4支持H264、H265等視頻編碼和AAC、MP3等音頻編碼。

我們在一些播放器中會看到，有硬解碼和軟解碼兩種播放形式給我們選擇，但是我們大部分時候並不能感覺出他們的區別，對於普通用戶來說，只要能播放就行了。

那麼他們內部究竟有什麼區別呢？

在手機或者PC上，都會有CPU、GPU或者解碼器等硬體。通常，我們的計算都是在CPU上進行的，也就是我們軟體的執行晶元，而GPU主要負責畫面的顯示（是一種硬體加速）。

所謂軟解碼，就是指利用CPU的計算能力來解碼，通常如果CPU的能力不是很強的時候，一則解碼速度會比較慢，二則手機可能出現發熱現象。但是，由於使用統一的演算法，兼容性會很好。

硬解碼，指的是利用手機上專門的解碼晶元來加速解碼。通常硬解碼的解碼速度會快很多，但是由於硬解碼由各個廠家實現，質量參差不齊，非常容易出現兼容性問題。

MediaCodec 是Android 4.1(api 16)版本引入的編解碼介面，是所有想在Android上開發音視頻的開發人員繞不開的坑。

由於Android碎片化嚴重，雖然經過多年的發展，Android硬解已經有了很大改觀，但實際上各個廠家實現不同， 還是會有一些意想不到的坑。

相對於FFmpeg，Android原生硬解碼還是相對容易入門一些，所以接下來，我將會從MediaCodec入手，講解如何實現視頻的編解碼，以及引入OpenGL實現對視頻的編輯，最後才引入FFmpeg來實現軟解，算是一個比較常規的音視頻開發入門流程吧。

『貳』 移動端短語音消息音頻格式選擇

1. 移動端原生音頻支持

1.1 android Supported media formats

https://developer.android.com/guide/topics/media/media-formats

Format / File Type(s) / Container Formats

AAC LC••Support for mono/stereo/5.0/5.1 content with standard sampling rates from 8 to 48 kHz.• 3GPP (.3gp)

• MPEG-4 (.mp4, .m4a)

• ADTS raw AAC (.aac, decode in Android 3.1+, encode in Android 4.0+, ADIF not supported)

• MPEG-TS (.ts, not seekable, Android 3.0+)

HE-AACv1 (AAC+)•

(Android 4.1+)

•

HE-AACv2 (enhanced AAC+)•Support for stereo/5.0/5.1 content with standard sampling rates from 8 to 48 kHz.

AAC ELD (enhanced low delay AAC)•

(Android 4.1+)

•

(Android 4.1+)

Support for mono/stereo content with standard sampling rates from 16 to 48 kHz

AMR-NB••4.75 to 12.2 kbps sampled @ 8kHz3GPP (.3gp)

AMR-WB••9 rates from 6.60 kbit/s to 23.85 kbit/s sampled @ 16kHz3GPP (.3gp)

FLAC•

(Android 4.1+)

•

(Android 3.1+)

Mono/Stereo (no multichannel). Sample rates up to 48 kHz (but up to 44.1 kHz is recommended on devices with 44.1 kHz output, as the 48 to 44.1 kHz downsampler does not include a low-pass filter). 16-bit recommended; no dither applied for 24-bit.FLAC (.flac) only

MIDI•MIDI Type 0 and 1. DLS Version 1 and 2. XMF and Mobile XMF. Support for ringtone formats RTTTL/RTX, OTA, and iMelody• Type 0 and 1 (.mid, .xmf, .mxmf)

• RTTTL/RTX (.rtttl, .rtx)

• OTA (.ota)

• iMelody (.imy)

MP3•Mono/Stereo 8-320Kbps constant (CBR) or variable bit-rate (VBR)MP3 (.mp3)

Opus•

(Android 5.0+)

Matroska (.mkv)

PCM/WAVE•

(Android 4.1+)

•8- and 16-bit linear PCM (rates up to limit of hardware). Sampling rates for raw PCM recordings at 8000, 16000 and 44100 Hz.WAVE (.wav)

Vorbis•• Ogg (.ogg)

• Matroska (.mkv, Android 4.0+)

1.2 Supported Audio File and Data Formats in OS X

https://developer.apple.com/library/content/documentation/MusicAudio/Conceptual/CoreAudioOverview/SupportedAudioFormatsMacOSX/SupportedAudioFormatsMacOSX.html

Allowable data formats for each file format.

File FormatData Formats

AAC (.aac, .adts)'aac '

AC3 (.ac3)'ac-3'

AIFC (.aif, .aiff,.aifc)BEI8, BEI16, BEI24, BEI32, BEF32, BEF64, 'ulaw', 'alaw', 'MAC3', 'MAC6', 'ima4' , 'QDMC', 'QDM2', 'Qclp', 'agsm'

AIFF (.aiff)BEI8, BEI16, BEI24, BEI32

Apple Core Audio Format (.caf)'.mp3', 'MAC3', 'MAC6', 'QDM2', 'QDMC', 'Qclp', 'Qclq', 'aac ', 'agsm', 'alac', 'alaw', 'drms', 'dvi ', 'ima4', 'lpc ', BEI8, BEI16, BEI24,BEI32, BEF32, BEF64, LEI16, LEI24, LEI32, LEF32, LEF64, 'ms\x00\x02', 'ms\x00\x11', 'ms\x001', 'ms\x00U', 'ms \x00', 'samr', 'ulaw'

MPEG Layer 3 (.mp3)'.mp3'

MPEG 4 Audio (.mp4)'aac '

MPEG 4 Audio (.m4a)'aac ', alac'

NeXT/Sun Audio (.snd, .au)BEI8, BEI16, BEI24, BEI32, BEF32, BEF64, 'ulaw'

Sound Designer II (.sd2)BEI8, BEI16, BEI24, BEI32

WAVE (.wav)LEUI8, LEI16, LEI24, LEI32, LEF32, LEF64, 'ulaw', 'alaw'

Core Audio includes a number of audio codecs that translate audio data to and from Linear PCM. Codecs for the following audio data type are available in OS X v10.4. Audio applications may install additional encoders and decoders.

Audio data typeEncode from linear PCM?Decode to linear PCM?

MPEG Layer 3 ('.mp3')NoYes

MACE 3:1 ('MAC3')YesYes

MACE 6:1 ('MAC6')YesYes

QDesign Music 2 ('QDM2')YesYes

QDesign ('QDMC')NoYes

Qualcomm PureVoice ('Qclp')YesYes

Qualcomm QCELP ('qclq')NoYes

AAC ('aac ')YesYes

Apple Lossless ('alac')YesYes

Apple GSM 10:1 ('agsm')NoYes

ALaw 2:1 'alaw')YesYes

Apple DRM Audio Decoder ('drms')NoYes

AC-3NoNo

DVI 4:1 ('dvi ')NoYes

Apple IMA 4:1 ('ima4')YesYes

LPC 23:1 ('lpc ')NoYes

Microsoft ADPCMNoYes

DVI ADPCMYesYes

GSM610NoYes

AMR Narrowband ('samr')YesYes

µLaw 2:1 ('ulaw')YesYes

1.3 總結:

android/ios都可以對mp3解碼,但不能編碼,編碼依賴lame;

android/ios支持對aac進行編解碼;

mp3,aac均是音樂編碼器,android支持對amr窄帶與寬頻編解碼,ios文檔顯示對窄帶支持編解碼,但有人說ios4.3.x版本之後不再支持AMR，剔除了AMR的硬解,如需使用依賴libopencore庫;

結論:

h5 audio標簽對mp3支持最好(audio標簽除了firefox與opera都支持mp3,ogg,wav;flash播放器可以支持到mp3,aac,speex,nellymoser),考慮對純web的兼容性,使用mp3;

android,ios硬體對aac支持最好,考慮硬編碼的性能與效率,使用aac;

amr是語音編碼器,考慮使用場景,推薦amr.

對比微信,微信短語音,6.0之前用的amr,6.0之後用的silk_v3.

2.音頻基礎概念

2.1聲音三要素

聲音的特性可由三個要素來描述，即響度、音調和音色。

響度：人耳對聲音強弱的主觀感覺稱為響度。響度和聲波振動的幅度有關。一般說來，聲波振動幅度越大則響度也越大。當我們用較大的力量敲鼓時，鼓膜振動的幅度大，發出的聲音響；輕輕敲鼓時，鼓膜振動的幅度小，發出的聲音弱。音叉振動時發出的聲波為單音，即只有一個頻率成分。若設法將音叉的振動規律記錄下來，可發現其振動波形為一正弦波。當用不同力量敲擊某個音叉時，音叉發出的聲波幅度不同，這意味著聲音的響度不同。給出了兩個聲音波形，其幅度一大一小，幅度大的波形其聲音響度大，幅度小的波形其聲音響度小。另外，人們對響度的感覺還和聲波的頻率有關，同樣強度的聲波，如果其頻率不同，人耳感覺到的響度也不同。

音調：人耳對聲音高低的感覺稱為音調。音調主要與聲波的頻率有關。聲波的頻率高，則音調也高。當我們分別敲擊一個小鼓和一個大鼓時，會感覺它們所發出的聲音不同。小鼓被敲擊後振動頻率快，發出的聲音比較清脆，即音調較高；而大鼓被敲擊後振動頻率較慢，發出的聲音比較低沉，即音調較低。如果分別敲擊一個小音叉和一個大音叉時，同樣會感覺到小音叉所發聲音的音調較高，大音叉所發聲音音調較低。如果設法把大、小音叉所發出的聲波記錄下來，可發現小音叉在單位時間內振動的次數多，即頻率高，大音叉在單位時間內振動的次數少，即頻率低。給出了兩個頻率不同的聲音波形，從聲音可聽出，頻率高的聲音波形聽起來音調較高，而頻率低的聲音波形聽起來則音調較低。

音色：音色是人們區別具有同樣響度、同樣音調的兩個聲音之所以不同的特性，或者說是人耳對各種頻率、各種強度的聲波的綜合反應。音色與聲波的振動波形有關，或者說與聲音的頻譜結構有關。前面說過，音叉可產生一個單一頻率的聲波，其波形為正弦波。但實際上人們在自然界中聽到的絕大部分聲音都具有非常復雜的波形，這些波形由基波和多種諧波構成。諧波的多少和強弱構成了不同的音色。各種發聲物體在發出同一音調聲音時，其基波成分相同。但由於諧波的多少不同，並且各次諧波的幅度各異，因而產生了不同的音色。例如當我們聽胡琴和揚琴等樂器同奏一個曲子時，雖然它們的音調相同，但我們卻能把不同樂器的聲音區別開來。這是因為，各種樂器的發音材料和結構不同，它們發出同一個音調的聲音時，雖然基波相同，但諧波構成不同，因此產生的波形不同，從而造成音色不同。給出了小提琴和鋼琴的波形和聲音，這兩個聲音的響度和音調都是相同的，但聽起來卻不一樣，這就是因為這兩個聲音的音色不同（波形不同）。

2.2采樣率和采樣大小

聲音其實是一種能量波，因此也有頻率和振幅的特徵，頻率對應於時間軸線，振幅對應於電平軸線。波是無限光滑的，弦線可以看成由無數點組成，由於存儲空間是相對有限的，數字編碼過程中，必須對弦線的點進行采樣。采樣的過程就是抽取某點的頻率值，很顯然，在一秒中內抽取的點越多，獲取得頻率信息更豐富，**為了復原波形，一次振動中，必須有2個點的采樣**，人耳能夠感覺到的最高頻率為20kHz，因此要滿足人耳的聽覺要求，則需要至少每秒進行40k次采樣，用40kHz表達，這個40kHz就是采樣率。我們常見的CD，采樣率為44.1kHz。光有頻率信息是不夠的，我們還必須獲得該頻率的能量值並量化，用於表示信號強度。量化電平數為2的整數次冪，我們常見的CD位16bit的采樣大小，即2的16次方。采樣大小相對采樣率更難理解，因為要顯得抽象點，舉個簡單例子：假設對一個波進行8次采樣，采樣點分別對應的能量值分別為A1-A8，但我們只使用2bit的采樣大小，結果我們只能保留A1-A8中4個點的值而舍棄另外4個。如果我們進行3bit的采樣大小，則剛好記錄下8個點的所有信息。采樣率和采樣大小的值越大，記錄的波形更接近原始信號。

2.3有損和無損

根據采樣率和采樣大小可以得知，相對自然界的信號，音頻編碼最多隻能做到無限接近，至少目前的技術只能這樣了，相對自然界的信號，任何數字音頻編碼方案都是有損的，因為無法完全還原。在計算機應用中，能夠達到最高保真水平的就是PCM編碼，被廣泛用於素材保存及音樂欣賞，CD、DVD以及我們常見的WAV文件中均有應用。因此，PCM約定俗成了無損編碼，因為PCM代表了數字音頻中最佳的保真水準，並不意味著PCM就能夠確保信號絕對保真，PCM也只能做到最大程度的無限接近。我們而習慣性的把MP3列入有損音頻編碼范疇，是相對PCM編碼的。強調編碼的相對性的有損和無損，是為了告訴大家，要做到真正的無損是困難的，就像用數字去表達圓周率，不管精度多高，也只是無限接近，而不是真正等於圓周率的值。

2.4頻率與采樣率的關系

采樣率表示了每秒對原始信號采樣的次數，我們常見到的音頻文件采樣率多為44.1KHz，這意味著什麼呢？假設我們有2段正弦波信號，分別為20Hz和20KHz，長度均為一秒鍾，以對應我們能聽到的最低頻和最高頻，分別對這兩段信號進行40KHz的采樣，我們可以得到一個什麼樣的結果呢？結果是：20Hz的信號每次振動被采樣了40K/20=2000次，而20K的信號每次振動只有2次采樣。顯然，在相同的采樣率下，記錄低頻的信息遠比高頻的詳細。這也是為什麼有些音響發燒友指責CD有數碼聲不夠真實的原因，CD的44.1KHz采樣也無法保證高頻信號被較好記錄。要較好的記錄高頻信號，看來需要更高的采樣率，於是有些朋友在捕捉CD音軌的時候使用48KHz的采樣率，這是不可取的！這其實對音質沒有任何好處，對抓軌軟體來說，保持和CD提供的44.1KHz一樣的采樣率才是最佳音質的保證之一，而不是去提高它。較高的采樣率只有相對模擬信號的時候才有用，如果被采樣的信號是數字的，請不要去嘗試提高采樣率。

亨利·奈奎斯特(Harry Nyquist)采樣定理:當對連續變化的信號波形進行采樣時,若采樣率fs高於該信號所含最高頻率的兩倍,那麼可以由采樣值通過插補技術正確的回復原信號中的波形,否則將會引起頻譜混疊(Aliasing),產生混疊噪音(Aliasing Noise),而重疊的部分是不能恢復的.(同樣適用於模擬視頻信號的采樣)

根據人聲語音的特點,人類的聽力感知范圍是從20Hz到20kHz。這個頻寬范圍被劃分成四個頻寬類別：窄帶、寬頻、超寬頻和全帶。

窄帶（narrowband）普通電話所覆蓋的頻寬，從300Hz到3.4kHz，對應采樣率6.8kHz。普通電話的采樣率是8kHz，對應頻寬4kHz，對於人聲語音是足夠的。

寬頻（wideband）從50Hz到7kH的頻寬，對應采樣率14khz，可以很好地捕捉和還原人聲，然而對於音樂聲還是不夠的。這是在人聲語音通話場景下的所謂高清語音。

超寬頻（super-wideband）從50Hz到14kHz，對應采樣率28kHz，基本可以覆蓋人聲和音樂聲，對於非專業音樂人的用戶來說，不管是人聲通話還是音樂直播，這樣的頻寬都是足夠的。

全帶（fullband）從20Hz到20kHz，對應40kHz采樣率，全面覆蓋人類的聽覺范圍，能夠滿足音樂發燒友或者專業音樂人的需求。超過40Hz都可以稱作全帶語音。CD的采樣率就是44.1kHz。

因此，窄帶(narrowband)的音質是能滿足人聲錄制回放的。

從四個角度衡量音頻編碼:

成本:開發成本,伺服器流量成本

音質:

系統影響:對系統資源的暫用,軟編解碼器比硬編解碼器佔用更多cpu

兼容性:對移動端以及web端的兼容

適合產品場景的編碼器具備以下四個特點

碼率相對低，滿足成本可控的要求，一般不要超過16kbps。一個sample用1bit就能編好，那麼8kHz采樣率（narrowband）對應8kbps的碼率，16kHz采樣率（wideband）對應16kbps的碼率。碼率的本質就是成本。

演算法復雜度要比較低，對系統CPU、內存和電量消耗少，對系統影響要盡量低。

音質可以適當作出犧牲，以保障上面三個因素，8kHz采樣率對人聲場景是夠用的，16kHz采樣率可以提供高清語音。

兼顧兼容性

3.主流音頻編碼器

音頻編碼格式的比較: https://zh.wikipedia.org/wiki/%E9%9F%B3%E9%A2%91%E7%BC%96%E7%A0%81%E6%A0%BC%E5%BC%8F%E7%9A%84%E6%AF%94%E8%BE%83

下圖列舉一組主流的音頻編解碼器，展示了隨著碼率變化，音質相應變化的情況。這是基於編解碼器聽音測試的結果繪畫出來的，對選取音頻編解碼器有參考意義。根據上面的分析並且參照下圖，發現碼率低於16kbps的低碼率人聲編解碼器（speech codecs）包含：Opus（SILK）,Speex，AMR-NB，AMR-WB，和iLBC。

下圖是另外一組主流的音頻編解碼器，展示了隨著碼率的變化，演算法延遲時間相應變化的情況。根據上面的分析並且參照下圖，發現演算法延遲時間低於60毫秒，碼率低於16kbps的人聲編解碼器（speech codecs）包含：Opus（SILK）、Speex(NB,WB)、G.729、和G.729.1。

從圖中我們可以獲得如下幾方面信息：

對於固定碼率的編碼標准：如G.711或者G.722，圖中採用單點表示，說明這兩個編碼標準是固定碼率編碼標准。其他如Opus、Speex，它們的曲線是連續的，說明這類編碼標準是可變碼率的編碼標准。

從頻帶方面看：G.711、G.722、AMR和iLBC等標准適用於narrowband（8khz采樣率）和wideband（16khz采樣率）范圍，針對普通的語音通話場景。AAC和MP3適用於fullband（48khz采樣率）范圍，針對特殊的音樂場景。而Opus適用於整個頻帶，可以進行最大范圍的動態調節，適用范圍最廣。

從標準的收費情況看：適用於互聯網傳輸的iLBC、Speex和Opus都是免費且開源的；適用於音樂場景的MP3和AAC，需要license授權，而且不開源。

綜合上面的兩個圖，我們可以大致總結，比較適合人聲短語音的音頻編解碼器包含Opus（SILK）、Speex（NB,WB）、AMR-NB、AMR-WB、iLBC、G.729、和G.729.1。

碼率采樣率演算法延遲

OPUS(SILK)6-12,7-25，

8-30,12-40kbps

8，12，

16，24kHz

25ms

Speex2.15–24.6 kbps (NB)

4–44.2 kbps (WB)

8, 16,

32, 48kHz

30 ms(NB)

34 ms (WB)

AMR-NB4.75, 5.15, 5.90,

6.70, 7.40, 7.95,

10.20, 12.20 kbps

8kHz25ms (20ms per frame

plus 5ms look-ahead,

20ms for 12.2 kbps)

AMR-WB6.60, 8.85, 12.65,14.25, 15.85, 18.25, 19.85, 23.05, 23.85 kbps16kHz25ms (20ms per frame

plus 5ms look-ahead)

iLBC13.33 kbps

15.20 kbps

8kHz25 ms

40 ms

G.7298kbps8kHz15 ms

G.729.18 kbps,

12–32 kbps

8kHz

16kHz

48.94ms

Codec20.7, 1.2, 1.3, 1.4,

1.6, 2.4, 3.2 kbps

8kHz20–40 ms

（額外增加的，超低碼率）

短語音不同於實時語音,可以忽略延遲

上面都是為人聲場景設計的低碼率音頻編解碼器，具有碼率低（16kbps以下），演算法延遲低（大部分在40ms以下），和采樣率在8kHz和16kHz之間的特點，都可供短語音編碼方案選擇。其中，有幾個語音編解碼器值得在這里稍作介紹：

Opus（SILK）

https://en.wikipedia.org/wiki/Opus_(audio_format)

完全開源而且免費，包含了SILK、CELT、以及兩者的混合模式，是目前最為兼容並包的音頻編解碼器。在處理窄帶和寬頻人聲語音（speech）的時候，採用SILK; 在處理超寬頻和全帶音樂聲音（music）的時候，採用CELT。在人聲和音樂聲混合的場景中，甚至可以智能切換兩個編解碼器。WebRTC就採用了Opus作為語音編解碼器。而SILK是Skype網路電話所用的語音編解碼器。Opus真可謂是久經考驗的名門精品。根據即構科技的測試結果，Opus雖然在音樂場景中表現並非首選，但是在人聲場景中表現十分出色。

iLBC

完全開源而且免費的，由GIPS開發並被IETF標准化，曾經被QQ和Skype使用過，現在被WebRTC使用，是被世界頂級產品證明過的窄帶實時語音編解碼器。iLBC能夠通過平滑降低語音質量的方式來處理IP網路丟包。由於iLBC的語音幀塊之間是相互獨立的，在丟幀出現的時候也不會導致錯誤蔓延，因此具有較強的抗丟包能力。在窄帶應用環境中，iLBC具有延遲低，無斷續或雜音的特點，通話效果可以和行動電話媲美。

Speex

免費的人聲音頻編解碼器。因為Speex是為VoIP專門設計的，所以Speex對IP網路有很強的抗丟包能力。為了達到這個目的，Speex採用了CELP演算法。市場上狼人殺產品的游戲實時語音技術，廠商自研的方案採用了Speex。

Codec2

開源並且專利免費，碼率超低的人聲語音編解碼器。碼率在0.7 kbps至3.2 kbps。Codec2填補了開源編碼器在5 kbps碼率以下的空白。

評估音頻編碼指標,除碼率、采樣率、和演算法延遲以外，還要參考MOS、VBR/CBR、和基礎演算法等。其中，MOS （Mean Opinion Score）是語音編解碼器的主觀評估指標。MOS是一個廣為接受的有統計意義的主觀聽音指標。上面音視頻編解碼器的列表沒有把它包含進去，是因為同一個編解碼器，在不同碼率下，表現出來的MOS值是會變化的。對一個音頻編解碼器給出一個固定的MOS值，反而會起誤導的作用。另外，雖然MOS值已經是主觀的聽覺測試評估結果，但是音頻工程師在選用音頻編解碼器的時候，還要以自己親身的聽感作為最終的依據。

下圖是Nokia在2011年的時候對Opus、AMR、和G.722.1C等音頻編解碼器在無噪音和有噪音的環境里做的MOS語音測試的結果。我們可以從語音測試的結果看出：

1）MOS值會隨著碼率變化。固定的MOS值並沒有絕對的參考意義。

2）在低碼率情況下，AMR-NB和AMR-WB都表現相對出色。

參考:

1.Getting Started with Audio & Video: https://developer.apple.com/library/content/referencelibrary/GettingStarted/GS_MusicAudio/_index.html

2.Opus ios: https://github.com/chrisballinger/Opus-iOS

3.android opus: https://gitlab.com/axet/android-opus

4.opus_android: https://github.com/louisyonge/opus_android

5.opuscodec: https://github.com/martoreto/opuscodec

6.與大家討論如何用opencore amr在iOS上decode: https://blog.csdn.net/devday/article/details/6804553

7. ios支持 https://developer.apple.com/library/archive/documentation/MusicAudio/Conceptual/CoreAudioOverview/CoreAudioEssentials/CoreAudioEssentials.html#//apple_ref/doc/uid/TP40003577-CH10-SW13

『叄』 android中播放音頻有哪幾種方式

哪幾種格式吧？音頻格式：MP1，MP2，MP3，OGG，FLAC（8,16,24,32位），WMA，AC3，AAC，M4A，M4B，M4R，MP4，3GP，3G2，MOV，APE（猴子的音頻）ALAC，西弗吉尼亞州（WavPack），MPC（MusePack），WAV（PCM {8,16,24,32-位樂}，ima4，MS -ADPCM，U -法律，法律），AU（PCM {8， 16,24,32,64位}，U -法律，法），MPEG（音頻），AVI（音頻），

『肆』 android音視頻開發一安卓常用API

Android SDK 提供了兩套音頻採集的API，分別是：MediaRecorder 和 AudioRecord，前者是一個更加上層一點的API，它可以直接把手機麥克風錄入的音頻數據進行編碼壓縮（如AMR、MP3等）並存成文件，而後者則更接近底層，能夠更加自由靈活地控制，可以得到原始的一幀幀PCM音頻數據。如果想簡單地做一個錄音機，錄製成音頻文件，則推薦使用 MediaRecorder，而如果需要對音頻做進一步的演算法處理、或者採用第三方的編碼庫進行壓縮、以及網路傳輸等應用，則建議使用 AudioRecord，其實 MediaRecorder 底層也是調用了 AudioRecord 與 Android Framework 層的 AudioFlinger 進行交互的。直播中實時採集音頻自然是要用AudioRecord了。

2.1 播放聲音可以用MediaPlayer和AudioTrack，兩者都提供了java API供應用開發者使用。雖然都可以播放聲音，但兩者還是有很大的區別的。

2.2 其中最大的區別是MediaPlayer可以播放多種格式的聲音文件，例如MP3，AAC，WAV，OGG，MIDI等。MediaPlayer會在framework層創建對應的音頻解碼器。而AudioTrack只能播放已經解碼的PCM流，如果對比支持的文件格式的話則是AudioTrack只支持wav格式的音頻文件，因為wav格式的音頻文件大部分都是PCM流。AudioTrack不創建解碼器，所以只能播放不需要解碼的wav文件。

2.3 MediaPlayer在framework層還是會創建AudioTrack，把解碼後的PCM數流傳遞給AudioTrack，AudioTrack再傳遞給AudioFlinger進行混音，然後才傳遞給硬體播放,所以是MediaPlayer包含了AudioTrack。

2.4 在接觸Android音頻播放API的時候，發現SoundPool也可以用於播放音頻。下面是三者的使用場景：MediaPlayer 更加適合在後台長時間播放本地音樂文件或者在線的流式資源; SoundPool 則適合播放比較短的音頻片段，比如游戲聲音、按鍵聲、鈴聲片段等等，它可以同時播放多個音頻; 而 AudioTrack 則更接近底層，提供了非常強大的控制能力，支持低延遲播放，適合流媒體和VoIP語音電話等場景。

使用 Camera API 採集視頻數據並保存到文件，分別使用 SurfaceView、TextureView 來預覽 Camera 數據，取到 NV21 的數據回調。

4.1 一個音視頻文件是由音頻和視頻組成的，我們可以通過MediaExtractor、MediaMuxer把音頻或視頻給單獨抽取出來，抽取出來的音頻和視頻能單獨播放； 

4.2 MediaMuxer的作用是生成音頻或視頻文件；還可以把音頻與視頻混合成一個音視頻文件。

文獻資料  https://www.cnblogs.com/renhui/p/7452572.html

『伍』 Android音頻開發：音頻相關知識

現在是數字時代，在音頻處理時要先把音頻的模擬信號變成數字信號，這叫A/D轉換。要把音頻的模擬信號變成數字信號，就需要采樣。一秒鍾內采樣的次數稱為采樣頻率

數字信號是用0和1來表示的。采樣位數就是采樣值用多少位0和1來表示，也叫采樣精度，用的位數越多就越接近真實聲音。如用8位表示，采樣值取值范圍就是-128 ~ 127，如用16位表示，采樣值取值范圍就是-32768 ~ 32767

通常語音只用一個聲道。而對於音樂來說，既可以是單聲道（mono），也可以是雙聲道（即左聲道右聲道，叫立體聲stereo），還可以是多聲道，叫環繞立體聲。

通常把音頻采樣過程也叫做脈沖編碼調制編碼，即PCM（Pulse Code Molation）編碼，采樣值也叫PCM值。 如果把采樣值直接保存或者發送，會佔用很大的存儲空間。以16kHz采樣率16位采樣位數單聲道為例，一秒鍾就有16/8*16000 = 32000位元組。為了節省保存空間或者發送流量，會對PCM值壓縮。
目前主要有三大技術標准組織制定壓縮標准：

對於自然界中的音頻信號，如果轉換成數字信號，進行音頻編碼，那麼只能無限接近，不可能百分百還原。所以說實際上任何信號轉換成數字信號都會「有損」。但是在計算機應用中，能夠達到最高保真水平的就是PCM編碼。因此，PCM約定俗成了無損編碼
。我們而習慣性的把MP3列入有損音頻編碼范疇，是相對PCM編碼的。強調編碼的相對性的有損和無損

碼率 = 采樣頻率 * 采樣位數 * 聲道個數； 例：采樣頻率44.1KHz，量化位數16bit，立體聲(雙聲道)，未壓縮時的碼率 = 44.1KHz * 16 * 2 = 1411.2Kbps = 176.4KBps，即每秒要錄制的資源大小,理論上碼率和質量成正比

1.WAV 格式：音質高 無損格式 體積較大
2.AAC（Advanced Audio Coding） 格式：相對於 mp3，AAC 格式的音質更佳，文件更小，有損壓縮，一般蘋果或者Android SDK4.1.2（API 16）及以上版本支持播放,性價比高
3.AMR 格式：壓縮比比較大，但相對其他的壓縮格式質量比較差，多用於人聲，通話錄音

4.mp3 格式：特點 使用廣泛， 有損壓縮，犧牲了12KHz到16KHz高音頻的音質

延時敏感、卡頓敏感、雜訊抑制（Denoise）、回聲消除（AEC）、靜音檢測（VAD）、混音演算法，等等。

參考：
Android音頻開發（1）：音頻基礎知識

『陸』 怎樣用AACLib V1.0在Android上音頻編碼解碼

這幾天在 android上的音頻項目，順便把用到的aac編解碼庫封裝了一下，有需要的可以從上面下載。當然是沒有本事自己寫編解碼器的，還是用FFmpeg + FDK_aac來做。下面介紹一下其java介面的使用。java庫見libaac.jar文件，把libaac.jar加到 libs目錄下，把libaac.so加到 libs/armeabi目錄即可使用。

AAC編碼：
(1) 創建一個Encoder對象作為成員變數
aac.Encoder encoder;

(2) 初始化它

encoder = new aac.Encoder();
if(! encoder.open(11025, 1))
{
Log.d("mylog", "failed to open encoder !\n");
encoder = null;
}

這里要指定輸入音頻源(PCM格式）的sampe_rate和channel個數，如果為CHANNEL_OUT_MONO，則channel=1，否則為2。 sample_rate一般設置為11025，因為手機性能有限，設置太高的話也處理不過來，而且處理人聲的話11025也是足夠了。


(3) 編碼

把接收到PCM數據交給encoder來處理即可，要求輸入源為ENCODING_PCM_16BIT，即每個sample是16BIT的。這個encoder對象內有2個緩沖區：inbuf, outbuf。顯然，在編碼時，inbuf就是用於存儲接收到的PCM數據，outbuf就是存編碼後得到的數據。

int out_size = encoder.encode(in_size);
其返回值out_size，表示在outbuf里的有效數據長度。此時可以把outbuf里的aac數據通過網路發送或其他用途。

其中，用戶需要知道encoder每次處理多長的數據，即一個frame的大小。對於單聲道MONO來說，每次應該輸入2048byte的數據。對於雙聲道STEREO來說，應該輸入4096byte的數據。下面這一行可以根據聲道數來計算輸入的frame的大小:

int in_size = aac.Encoder.frameSize(1);

AAC解碼：
(1) 創建一個Decoder對象作為成員變數

aac.Decoder decoder;

(2) 初始化

decoder = new aac.Decoder();
if( ! decoder.open())
{
Log.d("mylog", "failed to open decoder !\n");
decoder = null;
}

(3) 解碼
Decoder對象也有inbuf和outbuf，把待解碼的aac frame放到inbuf里

int pcm_size = decoder.decode(aac_size);

解得到數據在outbuf里，其有效長度為上述函數的返回值pcm_size，此時可以把outbuf里的PCM數據取出來播放或其他用途。

『柒』 android如何使用fdk-aac編碼庫來把aac轉成pcm

線性PCM就是WAV。
AAC-LC是AAC的一個規格，你下載到或者轉換的這些高碼率的AAC都是AAC-LC的。
擴展名是.m4a。

.aac 是aac的音頻數據流，m4a是aac的一個封裝方式。其內容本身是一樣的。
我用s754，和e453功能是一樣的。m4a和wav的我都放了，沒問題，只是.aac的我還沒試過。
但我相信lz沒有.aac的。。因為這年頭你下載到的或者轉換出來的都是m4a的

『捌』 小米5c參數

『玖』 Android音頻開發（三）——音頻編解碼

上一節中我們講了怎麼採集音頻並播放，由於AudioRecord採集的是PCM數據，沒有經過處理，所有播放的時候會有雜音，嘯叫等現象出現。因此處理掉這些不需要的數據就是本節的內容，編碼與解碼。

Android官方提供給我們的用於編解碼的類是 MediaCodec ,它是android 4.1（API 16）才引入的，所以只能工作於andorid4.1以上的手機，如果想兼容4.1以下版本的手機，只能使用第三方庫，如大名鼎鼎的 ffmpeg ,B站的 ijkplayer 等。

（1）提供了一套訪問 Android 底層多媒體模塊的介面，主要是音視頻的編解碼介面

（2）在Android上，預設的多媒體框架是基於第三方PacketVideo公司的OpenCORE來實現，OpenCORE的優點是兼顧了跨平台的移植性，而且已經過多方驗證，所以相對來說較為穩定；缺點是國語龐大復雜，需要耗費相當多的時間去維護。因此從Android 2.0開始，Google引進了較為簡潔的StageFright。Android 底層多媒體模塊採用的是 StageFright 框架，它是基於OpenMax標准實現的，任何 Android 底層編解碼模塊的實現，都必須遵循 OpenMax 標准。值得一提的是，OpenMAX是Khronos制定的API，Khronos也是OpenGL的制定者。Google 官方默認提供了一系列的軟體編解碼器：包括：OMX.google.h264.encoder，OMX.google.h264.encoder， OMX.google.aac.encoder， OMX.google.aac.decoder 等等，而硬體編解碼功能，則需要由晶元廠商依照 OpenMax 框架標准來完成，所以，一般採用不同晶元型號的手機，硬體編解碼的實現和性能是不同的

（3）Android 應用層統一由 MediaCodec API 來提供各種音視頻編解碼功能，由參數配置來決定採用何種編解碼演算法、是否採用硬體編解碼加速等等

根據android官方文檔的描述，MediaCodec的核心就是使用緩沖區隊列來操作數據，使用流程如下：

//name既是媒體文件的類型，如audio/3gpp，詳情參考MediaFormat的MIMETYPE常量
MediaCodec codec = MediaCodec.createByCodecName(name);
codec.configure(format, …);
MediaFormat outputFormat = codec.getOutputFormat(); // option B
codec.start();
for (;;) {
////獲取可用的inputBuffer -1代表一直等待，0表示不等待 建議-1,避免丟幀
int inputBufferId = codec.dequeueInputBuffer(-1);
if (inputBufferId >= 0) {
ByteBuffer inputBuffer = codec.getInputBuffer(…);
// fill inputBuffer with valid data
…
codec.queueInputBuffer(inputBufferId, …);
}
//執行上面的操作後就把待編解碼的數據存入了輸入緩沖區，然後下一步就是操作然後把編解碼的數據存入輸出緩沖區
int outputBufferId = codec.dequeueOutputBuffer(…);
if (outputBufferId >= 0) {
ByteBuffer outputBuffer = codec.getOutputBuffer(outputBufferId);
MediaFormat bufferFormat = codec.getOutputFormat(outputBufferId); // option A
// bufferFormat is identical to outputFormat
// outputBuffer is ready to be processed or rendered.
…
codec.releaseOutputBuffer(outputBufferId, …);
} else if (outputBufferId == MediaCodec.INFO_OUTPUT_FORMAT_CHANGED) {
// Subsequent data will conform to new format.
// Can ignore if using getOutputFormat(outputBufferId)
outputFormat = codec.getOutputFormat(); // option B
}
}
codec.stop();
codec.release();

MediaCodec codec = MediaCodec.createByCodecName(name);
MediaFormat mOutputFormat; // member variable
codec.setCallback(new MediaCodec.Callback() {
@Override
void onInputBufferAvailable(MediaCodec mc, int inputBufferId) {
ByteBuffer inputBuffer = codec.getInputBuffer(inputBufferId);
// fill inputBuffer with valid data
…
codec.queueInputBuffer(inputBufferId, …);
}

@Override
void onOutputBufferAvailable(MediaCodec mc, int outputBufferId, …) {
ByteBuffer outputBuffer = codec.getOutputBuffer(outputBufferId);
MediaFormat bufferFormat = codec.getOutputFormat(outputBufferId); // option A
// bufferFormat is equivalent to mOutputFormat
// outputBuffer is ready to be processed or rendered.
…
codec.releaseOutputBuffer(outputBufferId, …);
}

@Override
void onOutputFormatChanged(MediaCodec mc, MediaFormat format) {
// Subsequent data will conform to new format.
// Can ignore if using getOutputFormat(outputBufferId)
mOutputFormat = format; // option B
}

@Override
void onError(…) {
…
}
});
codec.configure(format, …);
mOutputFormat = codec.getOutputFormat(); // option B
codec.start();
// wait for processing to complete
codec.stop();
codec.release();

MediaCodec codec = MediaCodec.createByCodecName(name);
codec.configure(format, …);
codec.start();
//API的區別在這里
ByteBuffer[] inputBuffers = codec.getInputBuffers();
ByteBuffer[] outputBuffers = codec.getOutputBuffers();
for (;;) {
int inputBufferId = codec.dequeueInputBuffer(…);
if (inputBufferId >= 0) {
// fill inputBuffers[inputBufferId] with valid data
…
codec.queueInputBuffer(inputBufferId, …);
}
int outputBufferId = codec.dequeueOutputBuffer(…);
if (outputBufferId >= 0) {
// outputBuffers[outputBufferId] is ready to be processed or rendered.
…
codec.releaseOutputBuffer(outputBufferId, …);
} else if (outputBufferId == MediaCodec.INFO_OUTPUT_BUFFERS_CHANGED) {
outputBuffers = codec.getOutputBuffers();
} else if (outputBufferId == MediaCodec.INFO_OUTPUT_FORMAT_CHANGED) {
// Subsequent data will conform to new format.
MediaFormat format = codec.getOutputFormat();
}
}
codec.stop();
codec.release();