作為一名在音視頻SaaS教育直播行業(yè)從業(yè)近3年的產(chǎn)品經(jīng)理，本文將結合個人理解與實際工作經(jīng)驗給大家講解——作為一名音視頻產(chǎn)品經(jīng)理，應該需要知道的音視頻基礎技術知識；本文結構大致如下三個方面：

廣告

膽小者勿入！五四三二一...恐怖的躲貓貓游戲現(xiàn)在開始！

×

一、教育直播業(yè)務的音視頻技術框架

關于直播業(yè)務中涉及到的音視頻技術框架，整體流程框架大差不差，熟悉如抖音、快手、B站此類C端直播平臺，亦或是直播SaaS廠商提供的直播產(chǎn)品，如百家云、保利威、微贊等等；這里我以我們公司教育直播業(yè)務梳理如下基礎框架：

從業(yè)務表現(xiàn)層來看，直播整體流程主要表現(xiàn)在主播端采集音視頻后，在觀眾端進行播放觀看（部分業(yè)務還涉及觀眾上麥）；從技術框架簡單來看即為：

主講端上采集、處理、編碼、封裝-》推流-》流媒體服務器處理/信令服務器處理-》拉流與音視頻解碼與播放

基于以上流程，我們即可拆分來看每個環(huán)節(jié)會具體做哪些事情，以及我們產(chǎn)品經(jīng)理在實際需求設計中每個環(huán)節(jié)我們應當注意的事項，并附上實際需求案例輔助說明。

二、直播流程拆分解讀

1. 端上音視頻采集、處理、編碼、封裝

音視頻，顧名思義即為音頻+畫面的統(tǒng)稱，端上采集、處理、編碼、封裝時同樣以2個方面進行。

**方面，關于音頻的采集、處理、編碼、封裝，主要是將聲音的模擬信號數(shù)字化的一個過程（也叫模數(shù)轉化，A/D轉換）。

廣告

從秘書起步，十年內(nèi)無人超越，以一己之力力挽狂瀾成就一段傳奇

×

如上圖所示，基于采集到的音頻聲波圖，我們?nèi)r間軸上特定的時間間隔T作為樣本周期，標記無數(shù)個點（取樣點越密越精準），這一步叫采樣；而后將每一個采樣點的縱向幅度量化，便能得到量化的模擬信號（可以理解為坐標值）。

因為計算機只能識別01的二進制字節(jié)序列，量化的模擬信號，我們無法進行直接傳輸，需要將樣本值（十進制）進行編碼，即轉化成二進制字節(jié)序列，如序號2中的樣本值3轉化為011，即可在數(shù)字信號圖中得到對應信號圖；實際應用中，往往還會使用其他編碼算法做進一步壓縮，這里我們不做過深討論，知曉原理即可；大家也可基于如下內(nèi)容要點自行查找相關內(nèi)容。

第二方面，關于圖像的采集過程，主要由攝像頭等設備拍攝得到原始數(shù)據(jù)，然后經(jīng)過編碼壓縮成 H.264 等格式的數(shù)據(jù)分發(fā)出去。在圖像采集階段，涉及的主要技術參數(shù)包括：圖像傳輸格式、圖像格式、傳輸通道、分辨率以及采樣率。

MPEG-4/H.264等編解碼算法的工作機制基本都是混合編碼，主要處理模塊包括：預測、變換、量化和熵編碼等。

預測：通過幀內(nèi)預測和幀間預測降低視頻圖像的空間冗余和時間冗余。變換：通過從時域到頻域的變換，去除相鄰數(shù)據(jù)之間的相關性，即去除空間冗余。量化：通過用更粗糙的數(shù)據(jù)表示精細的數(shù)據(jù)來降低編碼的數(shù)據(jù)量，或者通過去除人眼不敏感的信息來降低編碼數(shù)據(jù)量。掃描：將二維變換量化數(shù)據(jù)重新組織成一維的數(shù)據(jù)序列。熵編碼：根據(jù)待編碼數(shù)據(jù)的概率特性減少編碼冗余。

通常在這流程環(huán)節(jié)，產(chǎn)品層面涉及的業(yè)務需求主要圍繞在聲音與畫面的處理，如常見的需求有美顏、濾鏡、虛擬背景、音頻降噪等等；熟悉此流程可幫助我們在整理此類需求時，理解技術上的處理時機，降低我們與研發(fā)的溝通成本；（不熟悉的同學可能會誤認為美顏效果處理是流媒體服務端研發(fā)處理，造成需求評審會上的尷尬場面）

2. 推流

推流：將直播的內(nèi)容推送至服務器的過程。即指的是把采集階段封包好的內(nèi)容傳輸?shù)椒掌鞯倪^程。其實就是將現(xiàn)場的視頻信號傳到網(wǎng)絡的過程。可以簡單理解為音視頻編碼封裝之后需上傳到流媒體服務器，類似快遞打包好之后要推到物流點。

常用的流傳輸協(xié)議有WebRTC、RTSP、RTMP、HLS等，使用RTMP傳輸?shù)难訒r通常在1–3秒，對于手機直播這種實時性要求非常高的場景，RTMP也成為手機直播中最常用的流傳輸協(xié)議。最后通過一定的Qos算法將音視頻流數(shù)據(jù)推送到網(wǎng)絡斷，通過CDN進行分發(fā)。

而CDN的作用在于推出去的流媒體要給各個地理位置的觀眾看。從而解決用戶訪問網(wǎng)絡資源慢的問題。

3. 流媒體服務器處理/信令服務器處理

流媒體服務器能夠在一定的主機配置條件和網(wǎng)絡帶寬條件下提供流暢的、高并發(fā)的視頻播出能力；流媒體服務器要做的事情包括：數(shù)據(jù)分發(fā)（CDN）、實時轉碼、內(nèi)容檢測等等；

隨著技術的發(fā)展，流媒體服務器的技術和產(chǎn)品也一直在不斷的發(fā)展和演進，視頻播出技術發(fā)展的趨勢包括：

1）高清視頻為主（1080p、4K），高碼率播出（>2Mbps）；

2）H264依然是主要視頻編碼格式，VP9/H265在有些應用中也開始采用；

3）視頻傳輸更多的采用http協(xié)議，F(xiàn)lash播放器逐步被淘汰；

4）采用WebRTC、Websocket協(xié)議進行視頻播出的應用越來越多。

5）雙向視頻應用越來越多，在在線教學、會議直播等直播應用中成為標配。

信令服務器承擔著消息傳輸和交換的工作，簡單來說前端/客戶端向流媒體服務端傳輸消息，或者流媒體服務端向前端/客戶端傳輸消息，都是依靠的信令；比如用戶創(chuàng)建房間，加入房間，退出房間等，確定何時初始化、關閉和修改通話；類似前端與后端以接口進行數(shù)據(jù)請求與返回，而前端/客戶端與流媒體服務端以信令形式；

通常在這流程環(huán)節(jié)，產(chǎn)品層面要理解流媒體服務器工作原理與信令服務器工作原理的好處在于，如底層服務商有多家時，可能需考慮多CDN切換或者海外服務的海外CDN切換功能；

另外對于信令服務器的理解更為重要，因涉及客戶端與流媒體服務端之間的數(shù)據(jù)交互，某些更深入的場景業(yè)務在此理解基礎上更易推進，如企業(yè)直播場景中的打賞功能，端上可直接以廣播信令形式廣播至全直播間成員；如教育場景中的畫筆筆跡，老師端上以信令文件傳輸至服務端后再處理傳出至學生端。

4、拉流與音視頻解碼與播放

拉流是指服務器已有直播內(nèi)容，根據(jù)協(xié)議類型（如RTMP、RTP、RTSP、HTTP等），與服務器建立連接并接收數(shù)據(jù)，進行拉取的過程；拉流端的核心處理在播放器端的解碼和渲染，因音視頻再推流至流媒體服務器之前已被編碼和封裝，如需在端上直接播放是行不通的，故需進行解碼和渲染處理，處理之后即可通過播放器對音視頻文件進行播放。

上述內(nèi)容即為整個直播業(yè)務涉及的基礎技術流程，當然還有部分特殊業(yè)務流程，如觀眾連麥/嘉賓連麥PK，其實原理類似，也是基于觀眾/嘉賓采集音視頻數(shù)據(jù)后進行處理編碼封裝后傳輸推流，流媒體服務端處理后以合流或多路流形式臺下觀眾拉流（具體看產(chǎn)品形態(tài)與成本評估）。

三、整體總結

作為一名音視頻行業(yè)的產(chǎn)品經(jīng)理，因音視頻技術涉及技術語言與復雜方案較多，了解整體的業(yè)務流程結構是有必要的；對于內(nèi)部需求評審而言，可以快速定位需求相關方（前端/流媒體端/后端）組會與任務落實；對于外部溝通評估需求而言，快速給予客戶解決方案以及分析需求，也能更好體現(xiàn)自身專業(yè)性。

以上為我個人從業(yè)直播行業(yè)的一些經(jīng)驗分享以及收集的相關資料解讀，歡迎大家探討與糾正~

本文由@偽文青???? 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協(xié)議。

該文觀點僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務。