作為一名音視頻產品經理，需要對相關音視頻基礎技術知識有所了解，因為在教育音視頻中，每個環節都會涉及到很多相關的基礎知識。本文就教育直播業務的音視頻技術框架以及直播流程拆分進行解讀，希望對你有所幫助。

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

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

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

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

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

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

二、直播流程拆分解讀

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

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

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

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

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

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

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

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

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

2. 推流

推流：將直播的內容推送至服務器的過程。即指的是把采集階段封包好的內容傳輸到服務器的過程。其實就是將現場的視頻信號傳到網絡的過程?？梢院唵卫斫鉃橐粢曨l編碼封裝之后需上傳到流媒體服務器，類似快遞打包好之后要推到物流點。

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

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

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

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

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

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

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

3）視頻傳輸更多的采用http協議，Flash播放器逐步被淘汰；

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

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

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

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

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

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

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

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

三、整體總結

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

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