在當今的移動網際網路時代，直播類產品我們再熟悉不過了，比如看遊戲直播、給美女主播打賞、聽直播課程等。此外，伴隨著抖音、快手等短視頻類應用的爆發，視頻類產品更是時刻充斥著我們的生活。那麼，直播類或者視頻的產品背後涉及到的音視頻技術知識都有哪些呢？本文將從直播類產品的基礎架構出發，闡述一些基礎的音視頻技術知識。
（音視頻領域博大精深，本文僅從一個PM的角度出發，總結一些最基本的內容）
一、直播的基礎架構
一個直播功能通用的基礎架構涉及三個部分，即音視頻採集端、雲服務端和音視頻播放端。
如下圖，是一個APP直播功能的架構：
從上圖中我們可以看到，每一個部分都有各自要處理的一些工作。
總體來說，視頻直播類功能的整體流程包括以下內容：
音視頻採集音視頻處理音視頻編碼和封裝推流流媒體伺服器處理拉流音視頻解碼音視頻播放在具體了解每個流程之前，我們先從音視頻的基本知識入手。
二、音視頻技術基礎
1. 音頻
聲音：
我們平時在手機或電腦裡聽到的音頻，是已經數位化了的音頻模擬信號。最初，這些音頻都是始於物理的聲音。
中學物理都學過，聲音是波，是通過物體的振動產生的。
聲波具有三要素：
音調：也叫音頻，頻率越高，波長就會越短，而低頻聲響的波長則較長。所以這樣的聲音更容易繞過障礙物。能量衰減就越小，聲音就會傳播的越遠；音量：就是振動的幅度。用不同的力度敲打桌面，聲音的大小勢必發生變換。在生活中，我們用分貝描述聲音的響度；音色：在同樣的頻率和響度下，不同的物體發出的聲音不一樣。波形的形狀決定了聲音的音色。因為不同的介質所產生的波形不同，就會產生不一樣的音色。模擬信號的數位化過程：
模擬信號的數位化過程，就是將模擬信號轉換為數位訊號的過程，包括採樣、量化和編碼。
我們可以通過下圖理解這一過程：
採樣：可以理解為在時間軸上對信號進行數位化。通常用採樣率來保證一定頻率範圍內的聲音可以被數位化成功，比如：採樣頻率一般是44.1KHZ，指的就是1秒會採樣44100次。量化：指的是在幅度軸上對信號進行數位化，就是聲音波形的數據是多少位的二進位數據，單位是bit。比如：常用16bit的二進位信號來存放一個採樣，這又叫做量化級。量化級是數字聲音質量的重要指標，通常將聲音描述為24bit（量化級）、48KHZ（採樣率）。編碼：按照一定的格式記錄採樣和量化後的數據。音頻編碼的格式有很多種，通常所說的音頻裸數據指的是脈衝編碼調製(PCM)數據。PCM音頻流的碼率可以用來描述PCM數據，它的計算公式是：採樣頻率*採樣大小（量化級）*聲道數（單聲道、雙聲道和多聲道）。通過上述的流程，就實現了音頻信號的數位化過程。轉為數位訊號之後，就可以對這些數據進行存儲、播放、複製獲取等其他操作了。
音頻編碼：
上面我們說到了，編碼就是按照一定的格式記錄採樣和量化後的數據，那麼到底為什麼需要編碼呢？
採集和量化後的數據是非常大的，從存儲或者網絡實時傳播的角度來說，這個數據量都太大了。對於存儲和傳輸都是非常具有挑戰的，所以我們需要通過編碼來進行壓縮。
壓縮編碼的指標是壓縮比，壓縮比通常是小於1的。
壓縮編碼算法分為2種：有損壓縮和無損壓縮。
無損壓縮：解壓後的數據可以完全復原。在常用的壓縮格式。用的較多的都是有損壓縮。有損壓縮：解壓後的數據不能完全復原，會丟失一部分信息。壓縮比越小，丟失的信息就會越多，信號還原的失真就會越大。壓縮編碼的實質就是壓縮冗餘的信號，冗餘信號就是指不能被人耳感知的信號，包括：人耳聽覺範圍之外的音頻信號以及被掩蓋掉的音頻信號。信號的掩蔽可以分為頻域掩蔽和時域掩蔽，關於信號的掩蔽大家可以自行百度一下，這裡就不做過多闡述了。
那麼，音頻壓縮編碼的常用格式都有哪些呢？
主要包括：WMA編碼；MP3編碼；AAC編碼，這個是現在比較熱門的有損壓縮編碼技術，也是目前在直播或小視頻中常用的編碼格式；OGG編碼等。
2. 視頻
數字視頻：
我們平時在手機或PC上看到的視頻，是由內容元素、編碼格式和封裝容器構成的。
內容元素：包括圖像（Image）、音頻（Audio）和元信息（Metadata）。編碼格式：包括視頻常用編碼格式H264，和音頻常用編碼格式AAC。封裝容器：這就是常見的文件格式，如MP4、MOV、FLV、RMVB、AVI等等。圖像：
圖像是人對視覺感知的物質重現。三維圖像的對象包括：深度、紋理和亮度信息，二維圖像包括紋理和亮度信息，我們可以簡單的把紋理就理解為圖像。
說了圖像的概念，現在來說下視頻：視頻是由多幅圖像構成的，是一組連續的圖像。一個基本的數字視頻，基本是通過「採集——處理——顯示」形成的。
編碼格式：
上面我們說到了音頻的編碼，視頻同樣是存在編碼的過程的。視頻編解碼的過程是指對數字視頻進行壓縮或解壓縮的過程。
在進行視頻的編解碼時，需要考慮以下因素的平衡：視頻的質量、用來表示視頻所需要的數據量（通常稱之為碼率）、編碼算法和解碼算法的複雜度、針對數據丟失和錯誤的魯棒性、編輯的方便性、隨機訪問、編碼算法設計的完美性、端到端的延時以及其它一些因素。
常用的視頻編解碼方式有H.26X系列和MPEG系列，而目前最常用的視頻編碼格式是H.264，它的優點是低碼率、圖像質量高、容錯能力強、網絡適應性更強，並且已被廣泛應用於實時視頻應用中。
再介紹一些關於H.264的知識：
在H.264中，圖像是包括幀、頂場和底場的，一副完整的圖像就是一幀。
當採集視頻信號時，如果採用逐行掃描，則每次掃描得到的信號就是一副圖像，也就是一幀。如果採用隔行掃描（奇、偶數行），則掃描下來的一幀圖像就被分為了兩個部分，這每一部分就稱為場，根據次序分為：頂場（也成為偶數場）和底場（也成為奇數場）。
幀和場的概念又帶來了不同的編碼方式：幀編碼和場編碼。逐行掃描適合於運動圖像，所以對於運動圖像採用幀編碼更好；而隔行掃描適合於非運動圖像，所以對於非運動圖像採用場編碼更理想。
此外，每一幀圖像可以分為多個片，每一個片由宏塊構成，而每個宏塊又是由子塊所構成的。
封裝格式：
視頻的封裝格式可以看成是一個裝載著視頻、音頻、視頻編解碼方式等信息的容器。一種視頻封裝格式可以支持多種的視頻編解碼方式，比如：QuickTime（.MOV）支持幾乎所有的編解碼方式，MPEG（.MP4）也支持大部分的編解碼方式。
在PC上，我們經常會使用.MOV的視頻文件。通過以上的介紹，我們就知道了，這個視頻的文件格式是.MOV，封裝格式是QuickTime File Format，但是我們無法知道它的視頻編解碼方式。如果我們想要專業的去描述一個視頻，可以描述成：H.264/MOV的視頻文件，這就是說它的封裝方式是QuickTime File Format，文件格式是.MOV，編碼方式是H.264。
H.264：
H.264是一種高性能的視頻編解碼技術，是由「國際電聯」和「國際標準化組織ISO」聯合組建的聯合視頻組共同制定的新的數字視頻編碼標準。
我們在上面已經說到了H.264編碼技術的優勢，我們接下來看一下H.264所涉及的關鍵技術：
我們首先要知道，無論是視頻或音頻編碼，其目的都是壓縮。視頻編碼的目的，是抽取出冗餘信息，這些冗餘信息包括：空間冗餘、時間冗餘、編碼冗餘、視覺冗餘和知識冗餘。
基於此，H.264的壓縮技術涉及：
a）幀內預測壓縮，解決的就是空間數據冗餘問題。空間冗餘數據就是圖裡數據在寬高空間內包含了很多顏色和光亮，人的肉眼很難察覺的數據。對於這些數據，我們是可以直接壓縮掉的。
幀內壓縮對應的是I幀——即關鍵幀。那麼什麼是I幀呢？網上教程中有一個經典的例子，如果攝像頭對著你拍攝，1秒之內實際你發生的變化是非常少的。攝像機一般1秒鐘會抓取幾十幀的數據，比如像動畫，就是25幀/s，一般視頻文件都是在30幀/s左右。那些對於一組幀來說變化很小的，為了便於壓縮數據，就將第一幀完整的保存下來。如果沒有這個關鍵幀後面解碼數據是完成不了的，所以I幀是特別關鍵的。
b）幀間預測壓縮，解決的是時間數據冗餘問題。在上面的例子中，攝像頭在一段時間內所捕捉的數據沒有較大的變化，我們針對這一時間內的相同的數據壓縮掉，這就是時間數據壓縮。
幀間壓縮對應的是P幀和B幀。P幀是向前參考幀，壓縮時只參考前一個幀。而B幀是雙向參考幀，壓縮時即參考前一幀也參考後一幀。
c）整數離散餘弦變換（DCT），將空間上的相關性變為頻域上無關的數據然後進行量化。
d）CABAC壓縮：無損壓縮。
H.264除了上述的關鍵技術，還有幾個重要的概念需要了解：
GOF：一組幀，就是一個I幀到下一個I幀，這一組的數據。包括B幀/P幀，我們稱為GOF。SPS和PPS：SPS和PPS是GOF的參數，SPS是存放幀數，參考幀數目，解碼圖像尺寸，幀場編碼模式選擇標識等。而PPS是存放熵編碼模式選擇標識，片組數目，初始量化參數和去方塊濾波係數調整標識等。在進行視頻解碼的時候，接收到一組幀GOF之前，我們首先收到的是SPS/PPS數據，如果沒有這組參數的話，是無法進行解碼的。
因此，如果在解碼時發生錯誤，首先要檢查是否有SPS/PPS。如果沒有，就要檢查是因為對端沒有發送過來還是因為對端在發送過程中丟失了。
更加詳細的H.264編碼原理這裡就不做介紹了，大家感興趣的可以上網查閱一下資料，比如：宏塊分組劃分、宏塊查找、幀內預測、DCT壓縮以及H.264的碼流結構等知識。
三、直播流程詳述
通過上面的介紹，我們已經了解音視頻一些基本的知識。接下來，我們一起再描述一遍直播類應用的整體流程。
1. 音視頻採集
在音視頻採集階段會包括：音頻採集和圖像採集。
在音頻採集時，除了上面我們說到的採樣率、量化級數和聲道數參數外，還需要音頻幀。
音頻跟視頻很不一樣，視頻每一幀就是一張圖像，而從聲音的正玄波可以看出：音頻數據是流式的，沒有明確的一幀幀的概念。在實際的應用中，為了音頻算法處理/傳輸的方便，一般約定俗成取 2.5ms~60ms 為單位的數據量為一幀音頻。
這個時間被稱之為「採樣時間」，其長度沒有特別的標準，它是根據編解碼器和具體應用的需求來決定的。
如果某音頻信號是採樣率為 8kHz、雙通道、量化級數是16bit，採樣時間是20ms，則一幀音頻數據的大小為：8000 * 2 * 16bit * 0.02s = 5120 bit = 640 byte
在圖像採集中，採集的圖片結果會組合成一組連續播放的動畫，即構成視頻中可肉眼觀看的內容。
圖像的採集過程主要由攝像頭等設備拍攝成 YUV 編碼的原始數據，然後經過編碼壓縮成 H.264 等格式的數據分發出去。在圖像採集階段，涉及的主要技術參數包括：圖像傳輸格式、圖像格式、傳輸通道、解析度以及採樣率。
在音視頻的採集階段，常用的採集源包括攝像頭，比如手機的前後置攝像頭；遊戲直播中使用的屏幕錄製；和電視節目中視頻文件的直接推流。
2. 音視頻處理
音視頻處理會分為：視頻處理和音頻處理。
視頻處理包括：美顏、濾鏡、面部識別、水印、剪輯拼接等。音頻處理包括：混音、降噪、聲音特效等。
下面我們簡要描述一下美顏和視頻水印的基本原理：
美顏的主要原理是通過【磨皮】+【美白】來達到整體美顏效果的。磨皮的技術術語是去噪，也就是對圖像中的噪點進行去除或者模糊化處理，常見的去噪算法有均值模糊、高斯模糊和中值濾波等。這個環節中也涉及到人臉和皮膚檢測技術。
視頻水印包括播放器水印和視頻內嵌水印兩種方式。對於播放器水印來說，如果沒有有效的防盜措施，對於沒有播放鑑權的推流，客戶端拿到直播流之後可以在任何一個不帶水印的播放器裡面播放，因此也就失去了視頻保護的能力。所以，一般來說會選擇視頻內嵌水印的方式打水印，這樣，水印就會內嵌到視頻之內，在視頻播放的過程中持續顯示。
再多聊一些，視頻內嵌水印也會應用在軟體中，軟體中播出企業內部版權保護的動畫段視頻時，會應用到內嵌水印的技術。
3. 音視頻編碼和封裝
音視頻的編碼以及視頻的封裝在上述基礎知識部分已經介紹過了，這裡不再贅述。
在這裡說一下編碼器的知識。上文中我們了解了H.264的編碼技術，編碼流程是要基於編碼器進行的。
編碼器的主要流程是：幀內預測（去除空間冗餘）/幀間預測（去除時間冗餘）——變換（去除空間冗餘）——量化（去除視覺冗餘）——熵編碼（去除編碼冗餘）。通過該流程，即可完成音視頻的編碼步驟。
4. 推流
推流就是將處理過的音頻和視頻數據通過流媒體協議發送到流媒體伺服器。
推流協議：
推流所遵循的協議有RTMP、WebRTC和基於UDP的私有協議。
RTMP協議是基於TCP協議的，RTMP 是目前主流的流媒體傳輸協議，廣泛用於直播領域，市面上絕大多數的直播產品都採用了這個協議。但是，由於基於TCP協議，傳輸成本高，在弱網環境下丟包率高，不支持瀏覽器推送。WebRTC是一個支持網頁瀏覽器進行實時語音對話或視頻對話的 API，主要應用於視頻會議。它的主流瀏覽器支持度高，並且底層基於SRTP和UDP，弱網情況優化空間大。基於UDP的私有協議。有些直播應用會使用 UDP 做為底層協議開發自己的私有協議，因為 UDP在弱網環境下的優勢通過一些定製化的調優可以達到比較好的弱網優化效果，但是開發成過高。CDN：
推出去的流媒體要給各個地理位置的觀眾看，那麼這裡就需要CDN網絡了。CDN就是為了解決用戶訪問網絡資源慢而產生的技術。
CDN包括邊緣節點、二級節點和源站。內容提供方可以將內容放到源站上，用戶從邊緣節點獲取數據，而CDN的二級節點則用於緩存，減輕源站壓力。
在直播領域中，CDN要支持的服務如下：
流媒體協議的支持。比如RTMP等；首屏秒開。從用戶點擊到播放控制在秒級以內；1~3 延遲控制。從推流端到播放端，延遲控制在 1~3 秒之間；全球全網智能路由。可以利用整個CDN網絡內的所有節點為某一單一用戶服務，不受地域限制。
5. 流媒體伺服器處理
流媒體伺服器要做的事情包括：數據分發（CDN）、支持上述CDN的一些服務、實時轉碼以及內容的檢測（鑑黃）等。
6. 拉流
拉流就是客戶端從流媒體伺服器上拉取獲得上述步驟中的音視頻數據。同理，這個過程也是要基於上述的協議和CDN。
7. 音視頻解碼
在上述H.264編碼的介紹中，說到了SPS/PPS是解碼必備的數據。此步驟就是需要對拉流下來已編碼的音視頻數據進行解碼。
解碼過程就是編碼的逆過程，這個過程包括：熵解碼、變換解碼、預測解碼。
H.264規範規定了解碼器的結構，解碼的過程大體如下：以宏塊為單位，依次進行熵解碼、反量化、反變換，得到殘差數據。再結合宏塊裡面的預測信息，找到已解碼的被參考塊，進而結合已解碼被參考塊和本塊殘差數據，得到本塊的實際數據。宏塊解碼後，組合出片，片再進而組合出圖像。
這裡要說明的是：如果H264碼流中I幀錯誤或丟失，就會導致錯誤傳遞，單獨的P幀或B幀是完成不了解碼工作的。I幀所保留的是一張完整的視頻幀，是解碼的關鍵所在。
8. 音視頻播放
在完成了音視頻數據的解碼後，就可以通過硬體設備（手機或PC）上的播放器對音視頻文件進行渲染播放了。
那麼，上述架構圖中的信令伺服器是幹什麼的呢？
——信令伺服器是用來處理主播端和用戶端的一些信令指令的。
在網絡中傳輸著各種信號，其中一部分是我們需要的（例如：打電話的語音，上網的數據包等等），而另外一部分是我們不需要的（只能說不是直接需要）它用來專門控制電路的，這一類型的信號我們就稱之為信令（摘自百度百科）。也就是說，信令是指通信系統中的控制指令。
我們基於此，再來描述一下這整個的流程：
主播共享端發起一個信令，比如：創建房間（或聊天、發送禮物等），到達信令伺服器；信令伺服器處理並且創建一個房間，同時返回給主播共享端一個流媒體雲的地址。接下來，主播共享端採集數據（音視頻的採集、處理以及編碼封裝流程）形成RTMP流推送到CDN網絡（推流）。觀眾要進行觀看時，客戶端會發送信令到信令伺服器，信令伺服器將該觀眾加入到主播的房間中，同時也會返回一個流媒體雲的地址（該地址就是之前主播端的流媒體雲地址）。客戶端拿到此流媒體雲地址後，就會到流媒體雲伺服器拉取到該媒體流（拉流和解碼），從而看到要觀看的直播節目（播放器播放）。好了，以上就是直播類應用的一個最基本的架構和流程了。
四、總結
本文通過直播類應用的架構，介紹了一些音視頻技術方面的知識，並且詳述了直播類功能的整體流程。
音視頻技術是一個高深的領域，本文只是做了一些基礎知識的總結，如果大家想要深入了解更多的音視頻技術，我推薦大家可以學習一下雷神（雷霄驊）的博客。
#專欄作家#
流年，人人都是產品經理專欄作家。網際網路產品設計師，4年網際網路產品設計經驗。擅長用戶體驗設計，喜歡鑽研需求功能背後的技術實現方式；在成為綜合型產品設計師的道路上不斷努力前進！
本文原創發布於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議