詳解音頻編解碼的原理、演進和應用選型等
本文來自網易雲音樂音視頻實驗室負責人劉華平在LiveVideoStackCon 2017大會上的分享，並由LiveVideoStack根據演講內容整理而成（本次演講PPT文稿，請從文末附件下載）。php
一、引言
你們好，我是劉華平，從畢業到如今我一直在從事音視頻領域相關工做，也有一些本身的創業項目，曾爲早期Google Android SDK多媒體架構的構建做出貢獻。html
就音頻而言，不管是算法多樣性，Codec種類仍是音頻編解碼複雜程度都遠遠比視頻要高。視頻的Codec目前還主要是以宏塊爲處理單元，預測加變換的混合編碼框架，例如H.264和H.265都是在這一框架下。而音頻則至關複雜，且不一樣的場景必需要選擇不一樣的音頻編解碼器。如下就是本次爲你們分享的主要內容，但願經過這次分享可使你們對音頻編解碼有一個總體的認識，並在實際應用中有參考的依據。算法
本次分享的內容提綱：小程序
1）語音／音頻編碼總表；後端
2）數字語音基本要素；微信小程序
3）爲何要壓縮；緩存
4）編碼器考慮的因素；安全
5）語音經典編碼模型；服務器
6）ISO；微信
7）編碼模型；
8）USAC；
9）編碼；
10）使用選型考慮的因素。
* 本次演講PPT文稿，請從文末附件下載！
（本文同步發佈於：http://www.52im.net/thread-2230-1-1.html）
二、分享者
劉華平：
- 現爲網易雲音樂音視頻實驗室負責人，上海大學通訊學院在職博士；
- 曾任掌門集團（WIFI萬能鑰匙）音視頻技術研發總監，資深研究員；
- 行者悟空聲學技術有限公司首席技術官(聯合創始人)；
- 阿里巴巴前高級技術專家(P8)， 阿里音樂音視頻部門總監；
- Visualon音頻部門經理、盛大創新院研究員、Freescale 上海研發中心多媒體部門；
- 早期 Google Android SDK多媒體架構的貢獻者，開源 AMR_WB 編碼器工程開發者。
劉華平擁有5項技術發明專利、二十餘篇專業論文和多項軟件著做權，參與過浙江省杭州重大專項項目，浙江省金華科委項目，上海市科委項目(球諧域全景音頻關鍵技術研究)。
三、系列文章
本文是系列文章中的第18篇，本系列文章的大綱以下：
《即時通信音視頻開發（五）：認識主流視頻編碼技術H.264》
《即時通信音視頻開發（九）：實時語音通信的迴音及迴音消除概述》
《即時通信音視頻開發（十）：實時語音通信的迴音消除技術詳解》
《即時通信音視頻開發（十一）：實時語音通信丟包補償技術詳解》
《即時通信音視頻開發（十三）：實時視頻編碼H.264的特色與優點》
《即時通信音視頻開發（十五）：聊聊P2P與實時音視頻的應用狀況》
《即時通信音視頻開發（十六）：移動端實時音視頻開發的幾個建議》
四、語言/音頻編碼總表
▲ 語言/音頻編碼總表
上圖展現的是語言/音頻編碼總表，能夠看到其比視頻編碼要複雜得多，單純的算法也遠遠比視頻要更加複雜。
五、數字語言基本要素
數字聲音具備三個要素：
1）採樣率；
2）通道數；
3）量化位數。
▲ 聲音數字化的過程
如上圖所示，聲音數字化的過程爲：
1）採樣：在時間軸上對信號數字化；
2）量化：在幅度軸上對信號數字化；
3）編碼：按必定格式記錄採樣和量化後的數字數據。
六、爲何要壓縮
壓縮音頻，主要是爲了在下降帶寬負擔的同時爲視頻騰出更多帶寬空間。存儲和帶寬二大因素決定了語音壓縮的必要性。
咱們看看下面的例子。
長度爲4分鐘，採樣頻率爲44100Hz,採樣深度爲16bits,雙聲音Wav文件大小：
44100Hz*16bits*4minutes*2=(44100/1second)*16bits*(4minutes*(60seconds/1minutes)*2=705600bits/second*240seconds=169344000bits=169344000/(8bits/1byte)*2=42336000bytes=42336000/(1048576/1M)bytes=40.37MB
MP3，128kbps壓縮後文件大小：
128kbps*4minutes=(128kbits/1second)*(4minutes*(60seconds/1minutes))=(128kbits/1second)*240seconds=30720kbits=30720kbits/(8bits/1byte)=3840kbytes=3840k/(1024k/1M)bytes=3.75Mbytes=3.75MB
正如上面的例子，聲音壓縮後，存儲大小爲原大小的十分之一，壓縮率十分可觀！
七、編碼器考慮因素
7.1 基本概念
編碼器考慮的因素：
1）最佳壓縮比；
2）算法的複雜度；
3）算法延時；
4）針對特殊場景下的特定設計；
5）兼容性。
經過一些特定的壓縮算法，能夠壓縮音頻文件至原來的1/10，同時人耳也沒法分辨壓縮先後的聲音質量差別，須要知足多種條件才能實現這種效果；而對於編碼器，不管是設計階段仍是使用階段，咱們都須要考慮最佳壓縮效果、算法的複雜度與算法的延時，結合特殊場景進行特定的設計；而兼容性也是咱們不能不考慮的重點。
7.2 語音經典編碼模型：發音模型
▲ 發音模型（原圖點擊查看）
咱們的不少編解碼器都是基於綜合人的發音模型與一些和聽覺相關的理論支持研究提出的特定編解碼算法。初期咱們經過研究人的發音原理來設計音頻編解碼的算法，包括端到端的濾波或輕濁音等，只有充分理解人的發聲原理咱們才能在編解碼端作出有價值的優化。
【7.2.1】語音編碼模型——LPC：
▲ 經典語音編碼模型：LPC（原圖點擊查看）
▲ LPC 數學表達
LPC做爲經典語音編碼模式，其本質是一個線性預測的過程。早期的G.7系列編碼模型即是經過此模型對整個語音進行編碼，上圖展現的過程可與以前的人發聲過程進行匹配，每一個環節都有一個相應的模塊用來支撐人發聲的過程。其中使用了AR數學模型進行線性預測，此算法也是如今不少語音編碼的重要組成模塊。
【7.2.2】語音編碼模型——G.729：
▲經典語音編碼模型: G.729(CELP)
G.729一樣是經典的語音編碼模型之一，也是咱們學習語音編碼的一個入門級Codec。G.729的文檔十分完善，包括每一個模塊的源代碼在內均可直接下載。G.729能夠說是在早期發聲模型基礎上的改進，須要關注的性能指標是幀長與算法上的延時，包括語音質量的MOS分。G.729也有不少變種，因爲語音須要考慮系統兼容性，不一樣的系統指定攜帶的Codec也不一樣，音頻編碼的複雜程度要遠高於視頻編碼。
G.729 建議了共軛結構的算術碼本激勵線性預測(CS-ACELP)編碼方案。G.729算法的幀長爲10ms, 編碼器含5ms 前瞻，算法時延15ms，語音質量MOS分可達4.0。
7.3 語音經典編碼模型——聽覺模型
▲ ISO編碼模型：心理聲學模型
除了研究人發聲的原理，咱們還須要研究人聽聲的原理，從而更好實現聲音的收集與處理。一個聲音信號是否能被人耳聽見主要取決於聲音信號的頻率、強度與其餘音的干擾。心理聲學模型即是用來找出音頻信號中存在的冗餘信息從而實如今壓縮聲音信號的同時不影響聽覺的目的。心理聲學理論的成熟爲感知編碼系統奠基了理論基礎，這裏的感知編碼主要是ISO編碼模型，主要覆蓋的聲學原理有臨界頻帶、絕對聽覺閾值、頻域掩蔽、時域掩蔽等。
▲ 聽覺模型
不管是MP3仍是AAC以致於到後面的杜比音效都是基於聽覺模型進行的探索與創新。
【7.3.1】臨界頻帶：
因爲聲音頻率與掩蔽曲線不是線性關係，爲從感知上來統一度量聲音頻率，引入了「臨界頻帶」的概念。一般認爲，在20Hz到16kHz範圍內有24個監界頻帶。臨界頻帶的單位叫Bark(巴克)。
▲ 臨界頻帶
臨界頻帶主要用於心理聲學模型。因爲聲音頻率與掩蔽曲線並不是線性關係，爲從感知上來統一度量聲音頻率，咱們引入了「臨界頻帶」的概念。人耳對每段的某個頻率的靈敏度不一樣，兩者關係是非線性的。一般咱們會將人能夠聽到的整個頻率也就是從20Hz到16KHz分爲24個頻帶，可在其中進行時域或頻域類的掩蔽，將一些冗餘信息從編碼中去除從而有效提高壓縮率。
【7.3.2】絕對聽覺閾值：
▲ 絕對聽覺閾值
絕對聽覺閾值也可有效提高壓縮率，基於心理聲學模型，可去除編碼中的冗餘部分。
7.4 經典音頻編碼：ISO
▲ 經典音頻編碼：ISO
咱們可將最先的MP3 Layer1理解爲第一代的ISO感知編碼，隨後的一些純量化內容更多的是在壓縮上進行改進而核心一直未改變。從MP3 Layer1到Layer2與Layer3，主要的改變是心理聲學模型的迭代。
▲ MPEG1 LayerI Codec
▲ MPEG1 LayerIII Codec
上圖展現的是Encode與Decode的迴路。輸入的PCM首先會通過多子帶分析與頻域中的心理聲學模型冗餘處理，然後進行量化編碼；Layer III中的是咱們如今常說的MP3的Codec：Encode與Decode之間的總體迴路，相比於Layer1多了幾個處理環節以及霍夫曼編碼。
7.5 AAC協議族
▲ AAC家族
AAC與G.719同樣包括不少系列，但AAC的巧妙之處在於向下兼容的特性。開始時咱們就強調，全部Codec在設計時都須要考慮兼容性，瑞典的Coding Technology公司曾提出在兼容性上特別優化的方案。AAC Plus V1包括AAC與SBR，AAC Plus V2包括AAC+SBR+PS，如今常見的不少音樂類或直播音頻編碼都是基於AAC Plus協議族進行的。
德國的霍朗浦學院曾在AAC低延時協議擴展方面作出一些探索並獲得了AAC LD協議族，其原理仍基於傳統的AAC模塊，但在後端會對處理長度進行調整，例如以前是以1024bit爲一個處理單位，那改進後則以960bit爲一個處理單位。除此以外AAC LD加入了LD-SBR與LD-MPS等，從而造成一個規模較大的AAC-ELD V2模塊，能夠說是十分巧妙。
【7.5.1】AACPlus核心模塊——SBR（Spectral Band Replication）：
▲ SBR(Spectral Band Replication)
咱們能夠看到，AAC能夠說充分利用了頻域擴展，用很小的代價實現諸多功能優化。AAC的核心之一是SBR，這是一種使用極少位數就可描述高頻部分並在解碼時進行特殊優化從而實現頻域擴展的模塊。上圖展現的是不一樣壓縮率模塊所覆蓋的頻率取值範圍，而使用AAC時須要注意一個被稱爲「甜點碼率」的指標。不管是採樣率仍是碼率都是變化的，在應用時選擇何種碼率十分關鍵。例如直播時採用64Kbps便可在覆蓋整個頻段的同時保持良好音質。
【7.5.2】AACPlus核心模塊——PS（Parametric Stereo）：
▲ ：PS(Parametric Stereo)
PS 描述參數：IID(Inter-channel Intensity Difference),，ICC(Inter-channel Cross-Correlation)，IPD(Inter-channel Phase Difference)。
▲ AACPlus v2編碼框圖
▲ AACPlus v2解碼框圖
PS模塊也是AAC的核心模塊之一，主要用於分析左右聲道屬性並使用很是少的位數表示左右聲道相關性，然後在解碼端將左右聲道分離。這裏比較巧妙的是PS的向下兼容特性，總體數據打包是分開進行的。若是獲取到AAC、SBR、PS三者的基本數據包後，在解碼階段咱們就只需AAC—LC。上圖展現的就是AAC的解碼框架，若是你們讀過3GPP的代碼就可發現其每個模塊都至關清楚。咱們可根據文檔讀取代碼並對應到每個環節。
【7.5.3】甜點碼率：
▲ AAC 甜點碼率
甜點碼率是一項很關鍵的指標。例如在手機直播應用場景中，通常的視頻分辨率爲640×360，音頻碼率大約在800K左右。若是音頻碼率過大則會直接影響視頻質量，於是咱們須要控制音頻碼率在一個較爲合適的範圍內從而實現最佳的音畫效果。在不少應用場景中可能須要系統根據不一樣的網絡環境下載不一樣音質的文件，例如在2G環境中下載較小的文件，這樣作主要是爲了節省帶寬並提升音頻文件的播放流暢程度。
7.6 AAC-ELD家族
AAC-ELD家族產生背景：aacplus v2 已經在壓縮和音質方面作到了近似於極致，但因爲算法實現上的長達100ms左右的延時極大的阻礙aacplus v2在實時通信領域的應用。Fraunhofer IIS 爲了解決這個問題，對AAC進行相關改進，造成了AAC-ELD協議族。
▲ AAC-ELD家族
AAC-ELD家族帶來的主要改進是低延遲。若是Codec的延遲太長便沒法在一些特定場景中被使用。例如早期AAC Plus V2的總體延遲可達100ms，如此高的延遲確定沒法被應用於語音通話等對實時性要求極高的應用場景。霍朗普學院推出的AAC-ELD可在保持音質的前提下將延遲下降至15ms，相對於MP3最高長達200ms的延遲而言提高巨大。
7.7 應用中端到端的延遲
▲ 端到端的延時
編解碼過程也存在延時問題，這也是咱們選擇編解碼器時須要考慮的最主要因素之一，編解碼的延時主要由處理延時與算法延時組成，例如G.729的算法延時爲15ms，而AAC-LC可達到一百毫秒以上。另外，播放端或採集端的長幀數量太多，播放時緩存太多等也會直接影響延時，咱們在選擇編解碼器時須要考慮延時帶來的影響。
編解碼器已經歷了兩個發展方向：
1）一個是以G.7（G.729）爲例，根據發聲模型設計的一套主要集中於語音方面的編解碼算法；
2）另外一個是以ISO的MP3和AAC爲例，根據心理聲學模型設計的一套感知編碼。
最近的趨勢是編碼的統一：原來在語音場景下咱們使用8K或16K進行採樣，音樂場景下則需使用覆蓋到全頻帶的44.1K進行採樣，每一個Codec都有一個頻域覆蓋的範圍。在以前的開發中，若是應用場景僅針對壓縮語音那麼須要選擇語音編碼方案，若是應用場景針對壓縮音樂則須要選擇音樂編碼方案，而如今的發展方向是經過一套編碼從容應對語音與音樂兩個應用場景，這就是接下來將要被提到的USAC。
這裏介紹兩個比較典型的Codec：
1）一個是Opus，經過其中集成的模塊可實現根據傳入音頻文件的採樣率等屬性自動選擇語音編碼或音樂編碼；
2）另外一個是EVS這也是霍朗普等組織推行的方案，已經嘗試用於4G或5G之中。
EVS (Enhanced Voice Services)：主要是VoiceAge, Dolby, Fraunhofer, 華爲聯合開發的USAC編碼器，低速率音樂編碼質量很好。
▲ USAC
由框圖咱們能夠了解到USAC向下兼容的特性。
編解碼器可總結爲經歷了三個時代：
1）發聲模型；
2）聽覺感知；
3）融合方案。
接下來我將展現目前全部的Codec狀況並整理爲表格以方便你們檢索查閱。
八、解碼器（Codec）總結
8.1 IETF系列
IETF做爲標準協議聯盟組織之一推出了以上Codec：Opus包括採樣率爲8kHz、甜點碼率爲11kbps的窄帶單聲語音（SILK），採樣率爲16kHz、甜點碼率爲20kbps的寬帶單聲語音與採樣率爲48kHz、甜點碼率爲32kbps的全帶單聲語音（CELT），採用甜點碼率意味着將壓縮率和音質保持在一個良好的平衡狀態。在一些窄帶單聲語音應用場景例如常見的微信語音聊天，其壓縮率可達到原來的8.5%。Opus沒有技術專利和源代碼的門檻，使得其受到如今不少流媒體廠商的歡迎，Opus支持更廣的碼率範圍，具有豐富採樣率選擇，可實現極低延遲與可變幀大小，也具有以往一些Codec的許多特性如CBR、VBR、動態調整等，支持的通道數量也更多。除此以外，Opus一樣具有許多從SILK移植而來的特性或功能。如在VUIB傳輸上集成了扛丟包模式等。
iLBC早在SILK未出現時就被提出一樣具有抗丟包。的特性，高達15.2kbps的甜點碼率與4.14的Mos使其音質較爲良好，超過G.729的相關指標；GSM就是最先手機網絡仍停留在2G時代時流行的編碼形式，主要用於蜂窩電話的編碼任務。
8.2 AMR系列
AMR早在3G時期就被普遍應用，AMR-NB是最流行的語音編碼器，具備壓縮效果好，支持多種碼率形式的特色；與此同時，這也是GSM與3G時期Android平臺最先支持的窄帶語音編碼方案。AMR-WB做爲AMR-NB向寬帶的擴展版，主要用於3G和4G通話標準協議中，其甜點碼率爲12.65kbps。在實踐中咱們將碼率參數調整爲此值便可實現壓縮率與質量的平衡。AMR-WB+則是上述二者的融合，三者共同構成AMR系列。
8.3 ITU-T G系列
ITU-T G系列包括最先的波形編碼G711到如今你們熟悉的G.729這裏我想強調的是G722.1 Siren七、G722.1c Siren14與G719 Siren22，例如G.719可覆蓋整個前頻帶且支持立體聲。即便都屬於老協議，但因爲其優秀的兼容性，不該被咱們忽略。
將Opus與其餘一些Codec進行對比咱們能夠看到，不管是質量仍是延時控制，Opus的優點十分明顯；加之Opus做爲開源的免費方案，不存在專利限制，受到業界追捧也不足爲奇。
8.4 ISO系列
ISO裏我想強調的是MP3與AAC，兩者一樣支持不少碼率。MP3的甜點碼率爲128kbps，MP3 Pro的碼率可達到MP3的一半；AAC支持8～96khz的採樣率，AAC-LC的甜點碼率爲96kbps，HE-AAC的甜點碼率爲32kbps，AAC-LD與ELD作到了AAC的低延時，實現了延時與壓縮比的最佳平衡。
8.5 3GPP系列：EVRC
EVRC 是CDMA 中使用的語音編解碼器，由高通公司1995年提出目標是取代QCELP。
高通公司主推的3GPP是CDMA中使用的語音編解碼器，在將來選擇編解碼器類型時咱們須要特別考慮延時與幀長。因爲語音編碼種類不少，幀長也是複雜多變的，其背後的算法複雜程度，RAM、ROM佔用等都是在實踐當中須要着重考慮的。
8.6 極低碼率
極低碼率主要的應用場景是對講機、衛星通信、軍工等。
上圖圖表中的MELP最先由美國軍方開發，如今絕大多數的對講機都基於此模型進行擴展開發，壓縮後的碼率可達到2.4kbps而目前最極端的極低碼率可實現300bps，至關於壓縮爲原數據的0.2%，此時的音頻文件僅能被用於傳達語音內容而丟失了不少聲色。
8.7 全頻帶
全頻帶中的組合也是多種多樣。
九、編解碼使用注意
9.1 License
▲ 開源項目經常使用的Lisence
國內大部分企業在開發時容易忽視包括專利安全性在內的與License相關的內容。若是企業計劃得比較長遠，須要長期使用某項技術或企業規模不斷擴大時則不能不考慮專利問題。專利費用包括Open Source與算法專利，兩者徹底獨立互不干涉，若是咱們從某家專利公司購買了AAC的專利算法，並不能得到此AAC專利的源代碼，僅能得到與此技術相關的專利使用受權。專利公司會給予須要下載的文件列表，經過這種方式實現技術的受權使用。
▲ 一張圖看懂Lisence（來自：阮一峯的博客）
上面的二叉樹圖比較清晰地展現了代碼受權的具體流程，隨着企業的規模化發展日趨成熟，企業應當規範自身的技術使用行爲，儘量避免專利糾紛帶來的不利影響。
9.2 專利
▲ 2個著名的多媒體技術專利池
主流語音編解碼技術擁有兩個專利池：
1）MPEG-LA；
2）Via Licensing。
不少很是複雜的Codec涉及高達上千個專利，與之相關的企業或組織多達幾十個，爲專利受權而與每個企業或組織進行洽談顯然是不現實的，於是專利池的出現使得技術受權更加規範清晰，方便企業統一處理技術受權問題。
9.3 常見Codec Patent License
但願你們在使用技術的同時尊重知識產權，助力技術創新可持續發展。
十、講稿PPT下載
（因沒法上傳附件，請從原文附件下載：http://www.52im.net/thread-2230-1-1.html）
附錄：更多音視頻技術資料
[1] 實時音視頻開發的其它精華資料：
《學習RFC3550：RTP/RTCP實時傳輸協議基礎知識》
《基於RTMP數據傳輸協議的實時流媒體技術研究（論文全文）》
《還在靠「喂喂喂」測試實時語音通話質量？本文教你科學的評測方法！》
《實現延遲低於500毫秒的1080P實時音視頻直播的實踐分享》
《技術揭祕：支持百萬級粉絲互動的Facebook實時視頻直播》
《理論聯繫實際：實現一個簡單地基於HTML5的實時視頻直播》
《首次披露：快手是如何作到百萬觀衆同場看直播仍能秒開且不卡頓的？》
《騰訊音視頻實驗室：使用AI黑科技實現超低碼率的高清實時視頻聊天》
《七牛雲技術分享：使用QUIC協議實現實時視頻直播0卡頓！》
《實時視頻直播客戶端技術盤點：Native、HTML五、WebRTC、微信小程序》
《微信多媒體團隊訪談：音視頻開發的學習、微信的音視頻技術和挑戰等》
《以網遊服務端的網絡接入層設計爲例，理解實時通訊的技術挑戰》
《騰訊技術分享：微信小程序音視頻與WebRTC互通的技術思路和實踐》
>> 更多同類文章 ……
[2] 開源實時音視頻技術WebRTC的文章：
《訪談WebRTC標準之父：WebRTC的過去、如今和將來》
《良心分享：WebRTC 零基礎開發者教程（中文）[附件下載]》
《新手入門：到底什麼是WebRTC服務器，以及它是如何聯接通話的？》
《[觀點] WebRTC應該選擇H.264視頻編碼的四大理由》
《基於開源WebRTC開發實時音視頻靠譜嗎？第3方SDK有哪些？》
《開源實時音視頻技術WebRTC中RTP/RTCP數據傳輸協議的應用》
《開源實時音視頻技術WebRTC在Windows下的簡明編譯教程》
《網頁端實時音視頻技術WebRTC：看起來很美，但離生產應用還有多少坑要填？》
《了不得的WebRTC：生態日趨完善，或將實時音視頻技術白菜化》
《騰訊技術分享：微信小程序音視頻與WebRTC互通的技術思路和實踐》
>> 更多同類文章 ……
（本文同步發佈於：http://www.52im.net/thread-2230-1-1.html）
- 1. 詳解音頻編解碼的原理、演進和應用選型等
- 2. 視頻技術詳解：語音編解碼技術演進和應用選型
- 3. 音頻編碼和解碼原理
- 4. 音頻編解碼原理
- 5. 音視頻同步原理解析；音頻編碼和解碼原理
- 6. 音視頻編解碼之yuv詳解
- 7. 音視頻編解碼詳解
- 8. 音視頻編解碼學習詳解
- 9. 【音頻】G711編碼原理
- 10. 各類音視頻編解碼學習詳解（2）--codec類型
- 更多相關文章...
- • 免費ARP詳解 - TCP/IP教程
- • MySQL常用運算符詳解 - MySQL教程
- • 爲了進字節跳動，我精選了29道Java經典算法題，帶詳細講解
- • TiDB 在摩拜單車在線數據業務的應用和實踐
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. No provider available from registry 127.0.0.1:2181 for service com.ddbuy.ser 解決方法
- 2. Qt5.7以上調用虛擬鍵盤(支持中文)，以及源碼修改(可拖動，水平縮放)
- 3. 軟件測試面試- 購物車功能測試用例設計
- 4. ElasticSearch（概念篇）：你知道的, 爲了搜索…
- 5. redux理解
- 6. gitee創建第一個項目
- 7. 支持向量機之硬間隔（一步步推導，通俗易懂）
- 8. Mysql 異步複製延遲的原因及解決方案
- 9. 如何在運行SEPM配置嚮導時將不可認的複雜數據庫密碼改爲簡單密碼
- 10. windows系統下tftp服務器使用
- 1. 詳解音頻編解碼的原理、演進和應用選型等
- 2. 視頻技術詳解：語音編解碼技術演進和應用選型
- 3. 音頻編碼和解碼原理
- 4. 音頻編解碼原理
- 5. 音視頻同步原理解析；音頻編碼和解碼原理
- 6. 音視頻編解碼之yuv詳解
- 7. 音視頻編解碼詳解
- 8. 音視頻編解碼學習詳解
- 9. 【音頻】G711編碼原理
- 10. 各類音視頻編解碼學習詳解（2）--codec類型