本文引用自公眾號“開發的貓”，本次收錄時有改動，感謝原作者“開發的貓”的分享。
1、引言
隨著移動網絡速度越來越快、質量越來越來，實時音視頻技術已經在各種應用場景下全面開花，語音通話、視頻通話、視頻會議、遠程白板、遠程監控等等。
實時音視頻技術的開發也越來越受到重視，但是由于音視頻開發涉及知識面比較廣，入門門檻相對較高，讓許許多多開發者望而生畏。
雖然網上有很多的博文總結了實時音視頻技術的學習路線，但是相關的知識都相對獨立，有講“音視頻解碼相關”的、有講“OpenGL相關”的、也有講“FFmpeg相關的”、還有講“RTP/RTCP、RTMP、HLS、QUIC等通信相關的”，但是對于新手來說，把所有的知識銜接串聯起來，并很好的理解所有的知識，卻是非常困難的。
本人在學習音視頻開發的過程中，深刻體會到了由于知識的分散、過渡斷層帶來的種種困惑和痛苦，因此希望通過自己的理解，可以把音視頻開發相關的知識總結出來，并形成系列文章，循序漸進，剖析各個環節，一則對自己所學做一個總結和鞏固，二則希望可以幫助想入門音視頻開發的開發者小伙伴們。
本文是作者自已根據入門實時音視頻的親身經歷，對于基礎知識點的認知總結。雖然很淺顯，但相對小白來說，能稍微系統的了解這些概念就已經是很好的起點了。
學習交流：
- 即時通訊/推送技術開發交流5群：215477170[推薦]
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
本文已同步發布于“即時通訊技術圈”公眾號，歡迎關注：
▲ 本文在公眾號上的鏈接是：https://mp.weixin.qq.com/s/DsoEYydjmoWiEruZYQKCgQ，原文鏈接是：http://www.52im.net/thread-3079-1-1.html
2、相關文章
《即時通訊音視頻開發（一）：視頻編解碼之理論概述》
《即時通訊音視頻開發（六）：如何開始音頻編解碼技術的學習》
《即時通訊音視頻開發（七）：音頻基礎及編碼原理入門》
《即時通訊音視頻開發（十四）：實時音視頻數據傳輸協議介紹》
《即時通訊音視頻開發（十九）：零基礎，史上最通俗視頻編碼技術入門》（* 必讀）
《實時語音聊天中的音頻處理與編碼壓縮技術簡述》
《移動端實時音視頻直播技術詳解（一）：開篇》
《移動端實時音視頻直播技術詳解（二）：采集》
《移動端實時音視頻直播技術詳解（三）：處理》
《移動端實時音視頻直播技術詳解（四）：編碼和封裝》
《移動端實時音視頻直播技術詳解（五）：推流和傳輸》
《移動端實時音視頻直播技術詳解（六）：延遲優化》
《福利貼：最全實時音視頻開發要用到的開源工程匯總》（* 必讀）
《寫給小白的實時音視頻技術入門提綱》（* 必讀）
《愛奇藝技術分享：輕松詼諧，講解視頻編解碼技術的過去、現在和將來》
3、視頻是什么？
3.1 動畫書
不知道大家小時候是否玩過一種動畫小人書，連續翻動的時候，小人書的畫面就會變成一個動畫，類似現在的gif格式圖片。
本來是一本靜態的小人書，通過翻動以后，就會變成一個有趣的小動畫，如果畫面夠多，翻動速度夠快的話，這其實就是一個小視頻。
而視頻的原理正是如此，由于人類眼睛的特殊結構，畫面快速切換時，畫面會有殘留，感覺起來就是連貫的動作。所以，視頻就是由一系列圖片構成的。
3.2 視頻幀
幀，是視頻的一個基本概念，表示一張畫面，如上面的翻頁動畫書中的一頁，就是一幀。一個視頻就是由許許多多幀組成的。
3.3 幀率
幀率，即單位時間內幀的數量，單位為：幀/秒 或fps（frames per second）。如動畫書中，一秒內包含多少張圖片，圖片越多，畫面越順滑，過渡越自然。
幀率的一般以下幾個典型值：
- 1）24/25 fps：1秒 24/25 幀，一般的電影幀率；
- 2）30/60 fps：1秒 30/60 幀，游戲的幀率，30幀可以接受，60幀會感覺更加流暢逼真。
85 fps以上人眼基本無法察覺出來了，所以更高的幀率在視頻里沒有太大意義。
3.4 色彩空間
這里我們只講常用到的兩種色彩空間。
- 1）RGB：RGB的顏色模式應該是我們最熟悉的一種，在現在的電子設備中應用廣泛。通過R G B三種基礎色，可以混合出所有的顏色；
- 2）YUV：這里著重講一下YUV，這種色彩空間并不是我們熟悉的。這是一種亮度與色度分離的色彩格式。
早期的電視都是黑白的，即只有亮度值，即Y。有了彩色電視以后，加入了UV兩種色度，形成現在的YUV，也叫YCbCr。
- 1）Y：亮度，就是灰度值。除了表示亮度信號外，還含有較多的綠色通道量；
- 2）U：藍色通道與亮度的差值；
- 3）V：紅色通道與亮度的差值。
如下圖，可以看到Y、V、U 3個分量的效果差值：
采用YUV有什么優勢呢？
人眼對亮度敏感，對色度不敏感，因此減少部分UV的數據量，人眼卻無法感知出來，這樣可以通過壓縮UV的分辨率，在不影響觀感的前提下，減小視頻的體積。
RGB和YUV的換算：
Y = 0.299R ＋ 0.587G ＋ 0.114B
U = －0.147R － 0.289G ＋ 0.436B
V = 0.615R － 0.515G － 0.100B
——————————————————
R = Y ＋ 1.14V
G = Y － 0.39U － 0.58V
B = Y ＋ 2.03U
3.5 進一步學習
如果你認為上面的文字還是有點專業，則強烈建議閱讀下文：《即時通訊音視頻開發（十九）：零基礎，史上最通俗視頻編碼技術入門》，絕對史上最通俗！
4、音頻是什么？
4.1 基本知識
音頻數據的承載方式最常用的是脈沖編碼調制，即 PCM。
在自然界中，聲音是連續不斷的，是一種模擬信號，那怎樣才能把聲音保存下來呢？那就是把聲音數字化，即轉換為數字信號。
我們知道聲音是一種波，有自己的振幅和頻率，那么要保存聲音，就要保存聲音在各個時間點上的振幅。
而數字信號并不能連續保存所有時間點的振幅，事實上，并不需要保存連續的信號，就可以還原到人耳可接受的聲音。
根據奈奎斯特采樣定理：為了不失真地恢復模擬信號，采樣頻率應該不小于模擬信號頻譜中最高頻率的2倍。
根據以上分析，PCM的采集步驟分為以下步驟：
模擬信號 -> 采樣 -> 量化 -> 編碼 -> 數字信號
4.2 采樣率和采樣位數
采樣率，即采樣的頻率。
上面提到，采樣率要大于原聲波頻率的2倍，人耳能聽到的最高頻率為20kHz，所以為了滿足人耳的聽覺要求，采樣率至少為40kHz，通常為44.1kHz，更高的通常為48kHz。
采樣位數，涉及到上面提到的振幅量化。波形振幅在模擬信號上也是連續的樣本值，而在數字信號中，信號一般是不連續的，所以模擬信號量化以后，只能取一個近似的整數值，為了記錄這些振幅值，采樣器會采用一個固定的位數來記錄這些振幅值，通常有8位、16位、32位。
位數越多，記錄的值越準確，還原度越高。
4.3 編碼
最后就是編碼了。由于數字信號是由0，1組成的，因此，需要將幅度值轉換為一系列0和1進行存儲，也就是編碼，最后得到的數據就是數字信號：一串0和1組成的數據。
整個過程如下：
4.4 聲道數
聲道數，是指支持能不同發聲（注意是不同聲音）的音響的個數。
單聲道：1個聲道
雙聲道：2個聲道
立體聲道：默認為2個聲道
立體聲道（4聲道）：4個聲道
4.5 碼率
碼率，是指一個數據流中每秒鐘能通過的信息量，單位bps（bit per second）。
碼率 = 采樣率 * 采樣位數 * 聲道數
4.6 深入地學習
讀完上面的文字后，如果覺得不夠深入，可以繼續系統的學習以下資料：
《即時通訊音視頻開發（六）：如何開始音頻編解碼技術的學習》
《即時通訊音視頻開發（七）：音頻基礎及編碼原理入門》
《即時通訊音視頻開發（八）：常見的實時語音通訊編碼標準》
《即時通訊音視頻開發（九）：實時語音通訊的回音及回音消除概述》
《即時通訊音視頻開發（十）：實時語音通訊的回音消除技術詳解》
《即時通訊音視頻開發（十一）：實時語音通訊丟包補償技術詳解》
《即時通訊音視頻開發（十八）：詳解音頻編解碼的原理、演進和應用選型》
《實時語音聊天中的音頻處理與編碼壓縮技術簡述》
《網易視頻云技術分享：音頻處理與壓縮技術快速入門》
如果你認為還需要更淺的文章，則強烈建議閱讀下文（絕對史上最通俗）：
《即時通訊音視頻開發（十九）：零基礎，史上最通俗視頻編碼技術入門》
5、為什么要編碼
這里的編碼和上面音頻中提到的編碼不是同個概念，而是指壓縮編碼。
我們知道，在計算機的世界中，一切都是0和1組成的，音頻和視頻數據也不例外。由于音視頻的數據量龐大，如果按照裸流數據存儲的話，那將需要耗費非常大的存儲空間，也不利于傳送。而音視頻中，其實包含了大量0和1的重復數據，因此可以通過一定的算法來壓縮這些0和1的數據。
特別在視頻中，由于畫面是逐漸過渡的，因此整個視頻中，包含了大量畫面/像素的重復，這正好提供了非常大的壓縮空間。
因此，編碼可以大大減小音視頻數據的大小，讓音視頻更容易存儲和傳送。
那么，未經編碼的原始音視頻，數據量至底有多大？
以一個分辨率1920×1280，幀率30的視頻為例：
共：1920×1280=2,073,600（Pixels 像素），每個像素點是24bit（前面算過的哦）；
也就是：每幅圖片2073600×24=49766400 bit，8 bit（位）=1 byte（字節）；
所以：49766400bit=6220800byte≈6.22MB。
這是一幅1920×1280圖片的原始大小，再乘以幀率30。
也就是說：每秒視頻的大小是186.6MB，每分鐘大約是11GB，一部90分鐘的電影，約是1000GB。。。
（以上舉例引用自：《即時通訊音視頻開發（十九）：零基礎，史上最通俗視頻編碼技術入門》）
6、視頻編碼
視頻編碼格式有很多，比如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。
視頻編碼知識比較專業，限于篇幅，我就不在此展開討論了。
如果想系統地了解視頻編碼技術，可以讀以下資料：
《即時通訊音視頻開發（一）：視頻編解碼之理論概述》
《即時通訊音視頻開發（二）：視頻編解碼之數字視頻介紹》
《即時通訊音視頻開發（三）：視頻編解碼之編碼基礎》
《即時通訊音視頻開發（四）：視頻編解碼之預測技術介紹》
《即時通訊音視頻開發（五）：認識主流視頻編碼技術H.264》
《即時通訊音視頻開發（十二）：多人實時音視頻聊天架構探討》
《即時通訊音視頻開發（十三）：實時視頻編碼H.264的特點與優勢》
《即時通訊音視頻開發（十四）：實時音視頻數據傳輸協議介紹》
《即時通訊音視頻開發（十五）：聊聊P2P與實時音視頻的應用情況》
《即時通訊音視頻開發（十六）：移動端實時音視頻開發的幾個建議》
《即時通訊音視頻開發（十七）：視頻編碼H.264、VP8的前世今生》
7、音頻編碼
原始的PCM音頻數據也是非常大的數據量，因此也需要對其進行壓縮編碼。
和視頻編碼一樣，音頻也有許多的編碼格式，如：WAV、MP3、WMA、APE、FLAC等等，音樂發燒友應該對這些格式非常熟悉，特別是后兩種無損壓縮格式。
但是，我們今天的主角不是他們，而是另外一個叫AAC的壓縮格式。本節以AAC格式為例，直觀的了解音頻壓縮格式。
AAC是新一代的音頻有損壓縮技術，一種高壓縮比的音頻壓縮算法。在MP4視頻中的音頻數據，大多數時候都是采用AAC壓縮格式。
AAC格式主要分為兩種：ADIF、ADTS。
1）ADIF：Audio Data Interchange Format。音頻數據交換格式。這種格式的特征是可以確定的找到這個音頻數據的開始，不需進行在音頻數據流中間開始的解碼，即它的解碼必須在明確定義的開始處進行。這種格式常用在磁盤文件中。
2）ADTS：Audio Data Transport Stream。音頻數據傳輸流。這種格式的特征是它是一個有同步字的比特流，解碼可以在這個流中任何位置開始。它的特征類似于mp3數據流格式。
ADTS可以在任意幀解碼，它每一幀都有頭信息。ADIF只有一個統一的頭，所以必須得到所有的數據后解碼。且這兩種的header的格式也是不同的，目前一般編碼后的都是ADTS格式的音頻流。
ADIF數據格式：
header | raw_data
ADTS 一幀 數據格式（中間部分，左右省略號為前后數據幀）：
AAC內部結構也不再贅述，如果有興趣，可以參考《AAC 文件解析及解碼流程》。
如果需要更深入地學習音頻編碼知識，可以看看以下資料：
《即時通訊音視頻開發（六）：如何開始音頻編解碼技術的學習》
《即時通訊音視頻開發（七）：音頻基礎及編碼原理入門》
《即時通訊音視頻開發（八）：常見的實時語音通訊編碼標準》
《即時通訊音視頻開發（十八）：詳解音頻編解碼的原理、演進和應用選型》
8、音視頻容器
細心的讀者可能已經發現，前面我們介紹的各種音視頻的編碼格式，沒有一種是我們平時使用到的視頻格式，比如：mp4、rmvb、avi、mkv、mov...
沒錯，這些我們熟悉的視頻格式，其實是包裹了音視頻編碼數據的容器，用來把以特定編碼標準編碼的視頻流和音頻流混在一起，成為一個文件。
例如：mp4支持H264、H265等視頻編碼和AAC、MP3等音頻編碼。
mp4是目前最流行的視頻格式，在移動端，一般將視頻封裝為mp4格式。
對于音視頻編碼格式和容器之間的關系，可以詳細讀《即時通訊音視頻開發（十九）：零基礎，史上最通俗視頻編碼技術入門》一文中的“6、視頻編碼的國際標準”一節。
9、硬解碼和軟解碼
我們在一些播放器中會看到，有硬解碼和軟解碼兩種播放形式給我們選擇，但是我們大部分時候并不能感覺出他們的區別，對于普通用戶來說，只要能播放就行了。
那么他們內部究竟有什么區別呢？
在手機或者PC上，都會有CPU、GPU或者解碼器等硬件。通常，我們的計算都是在CPU上進行的，也就是我們軟件的執行芯片，而GPU主要負責畫面的顯示（是一種硬件加速）。
所謂軟解碼：就是指利用CPU的計算能力來解碼，通常如果CPU的能力不是很強的時候，一則解碼速度會比較慢，二則手機可能出現發熱現象。但是，由于使用統一的算法，兼容性會很好。
所謂硬解碼：指的是利用手機上專門的解碼芯片來加速解碼。通常硬解碼的解碼速度會快很多，但是由于硬解碼由各個廠家實現，質量參差不齊，非常容易出現兼容性問題。
10、參考資料
[1] 音視頻開發基礎知識
[2] YUV顏色編碼解析
[3] YUV數據格式
[4] 音頻基礎知識
[5] AAC 文件解析及解碼流程
[6] 入門理解H264編碼
附錄：更多音視頻技術文章匯總
[1] 開源實時音視頻技術WebRTC的文章：
《開源實時音視頻技術WebRTC的現狀》
《簡述開源實時音視頻技術WebRTC的優缺點》
《訪談WebRTC標準之父：WebRTC的過去、現在和未來》
《良心分享：WebRTC 零基礎開發者教程（中文）[附件下載]》
《WebRTC實時音視頻技術的整體架構介紹》
《新手入門：到底什么是WebRTC服務器，以及它是如何聯接通話的？》
《WebRTC實時音視頻技術基礎：基本架構和協議棧》
《淺談開發實時視頻直播平臺的技術要點》
《[觀點] WebRTC應該選擇H.264視頻編碼的四大理由》
《基于開源WebRTC開發實時音視頻靠譜嗎？第3方SDK有哪些？》
《開源實時音視頻技術WebRTC中RTP/RTCP數據傳輸協議的應用》
《簡述實時音視頻聊天中端到端加密（E2EE）的工作原理》
《實時通信RTC技術棧之：視頻編解碼》
《開源實時音視頻技術WebRTC在Windows下的簡明編譯教程》
《網頁端實時音視頻技術WebRTC：看起來很美，但離生產應用還有多少坑要填？》
《了不起的WebRTC：生態日趨完善，或將實時音視頻技術白菜化》
《騰訊技術分享：微信小程序音視頻與WebRTC互通的技術思路和實踐》
>> 更多同類文章 ……
[2] 實時音視頻開發的其它精華資料：
《即時通訊音視頻開發（一）：視頻編解碼之理論概述》
《即時通訊音視頻開發（二）：視頻編解碼之數字視頻介紹》
《即時通訊音視頻開發（三）：視頻編解碼之編碼基礎》
《即時通訊音視頻開發（四）：視頻編解碼之預測技術介紹》
《即時通訊音視頻開發（五）：認識主流視頻編碼技術H.264》
《即時通訊音視頻開發（六）：如何開始音頻編解碼技術的學習》
《即時通訊音視頻開發（七）：音頻基礎及編碼原理入門》
《即時通訊音視頻開發（八）：常見的實時語音通訊編碼標準》
《即時通訊音視頻開發（九）：實時語音通訊的回音及回音消除概述》
《即時通訊音視頻開發（十）：實時語音通訊的回音消除技術詳解》
《即時通訊音視頻開發（十一）：實時語音通訊丟包補償技術詳解》
《即時通訊音視頻開發（十二）：多人實時音視頻聊天架構探討》
《即時通訊音視頻開發（十三）：實時視頻編碼H.264的特點與優勢》
《即時通訊音視頻開發（十四）：實時音視頻數據傳輸協議介紹》
《即時通訊音視頻開發（十五）：聊聊P2P與實時音視頻的應用情況》
《即時通訊音視頻開發（十六）：移動端實時音視頻開發的幾個建議》
《即時通訊音視頻開發（十七）：視頻編碼H.264、VP8的前世今生》
《即時通訊音視頻開發（十八）：詳解音頻編解碼的原理、演進和應用選型》
《即時通訊音視頻開發（十九）：零基礎，史上最通俗視頻編碼技術入門》
《實時語音聊天中的音頻處理與編碼壓縮技術簡述》
《網易視頻云技術分享：音頻處理與壓縮技術快速入門》
《學習RFC3550：RTP/RTCP實時傳輸協議基礎知識》
《基于RTMP數據傳輸協議的實時流媒體技術研究（論文全文）》
《聲網架構師談實時音視頻云的實現難點(視頻采訪)》
《淺談開發實時視頻直播平臺的技術要點》
《還在靠“喂喂喂”測試實時語音通話質量？本文教你科學的評測方法！》
《實現延遲低于500毫秒的1080P實時音視頻直播的實踐分享》
《移動端實時視頻直播技術實踐：如何做到實時秒開、流暢不卡》
《如何用最簡單的方法測試你的實時音視頻方案》
《技術揭秘：支持百萬級粉絲互動的Facebook實時視頻直播》
《簡述實時音視頻聊天中端到端加密（E2EE）的工作原理》
《移動端實時音視頻直播技術詳解（一）：開篇》
《移動端實時音視頻直播技術詳解（二）：采集》
《移動端實時音視頻直播技術詳解（三）：處理》
《移動端實時音視頻直播技術詳解（四）：編碼和封裝》
《移動端實時音視頻直播技術詳解（五）：推流和傳輸》
《移動端實時音視頻直播技術詳解（六）：延遲優化》
《理論聯系實際：實現一個簡單地基于HTML5的實時視頻直播》
《IM實時音視頻聊天時的回聲消除技術詳解》
《淺談實時音視頻直播中直接影響用戶體驗的幾項關鍵技術指標》
《如何優化傳輸機制來實現實時音視頻的超低延遲？》
《首次披露：快手是如何做到百萬觀眾同場看直播仍能秒開且不卡頓的？》
《Android直播入門實踐：動手搭建一套簡單的直播系統》
《網易云信實時視頻直播在TCP數據傳輸層的一些優化思路》
《實時音視頻聊天技術分享：面向不可靠網絡的抗丟包編解碼器》
《P2P技術如何將實時視頻直播帶寬降低75%？》
《專訪微信視頻技術負責人：微信實時視頻聊天技術的演進》
《騰訊音視頻實驗室：使用AI黑科技實現超低碼率的高清實時視頻聊天》
《微信團隊分享：微信每日億次實時音視頻聊天背后的技術解密》
《近期大熱的實時直播答題系統的實現思路與技術難點分享》
《福利貼：最全實時音視頻開發要用到的開源工程匯總》
《七牛云技術分享：使用QUIC協議實現實時視頻直播0卡頓！》
《實時音視頻聊天中超低延遲架構的思考與技術實踐》
《理解實時音視頻聊天中的延時問題一篇就夠》
《實時視頻直播客戶端技術盤點：Native、HTML5、WebRTC、微信小程序》
《寫給小白的實時音視頻技術入門提綱》
《微信多媒體團隊訪談：音視頻開發的學習、微信的音視頻技術和挑戰等》
《騰訊技術分享：微信小程序音視頻技術背后的故事》
《微信多媒體團隊梁俊斌訪談：聊一聊我所了解的音視頻技術》
《新浪微博技術分享：微博短視頻服務的優化實踐之路》
《實時音頻的混音在視頻直播應用中的技術原理和實踐總結》
《以網游服務端的網絡接入層設計為例，理解實時通信的技術挑戰》
《騰訊技術分享：微信小程序音視頻與WebRTC互通的技術思路和實踐》
《新浪微博技術分享：微博實時直播答題的百萬高并發架構實踐》
《技術干貨：實時視頻直播首屏耗時400ms內的優化實踐》
《愛奇藝技術分享：輕松詼諧，講解視頻編解碼技術的過去、現在和將來》
《零基礎入門：實時音視頻技術基礎知識全面盤點》
>> 更多同類文章 ……
（本文同步發布于：http://www.52im.net/thread-3079-1-1.html）