音視頻直播–技術架構

• 2020 年 4 月 2 日
• 筆記

前言

今天和大家講一下音視頻直播技術架構。之前的關注點主要放在客戶端如何採集音頻數據上，經過這兩天的思考，我覺得應該先給大家講一下音視頻直播技術架構，這樣更容易從整體上理解視頻直播技術是如何運轉的，之後再逐步的介紹每一個主題。

簡單的音視頻直播架構

直播架構

這種架構非常的簡單，利用已經有的CDN網絡如阿里，帝聯，藍訊等，自己再搭建一個信令服務器，這樣就將服務層搭建好了。

共享者首先向信令服務器發送共享音視頻指令，之後通過 Camera 或 攝像頭採集數據，數據經編碼後通過RTMP協議將流推送給CDN網絡。

接收端向信令服務器髮指令，獲取共享者共享的流名稱，然後通過流名稱從CDN網絡拉取音視頻流，再經過解碼後渲染在屏幕上。

實時交互的音視頻直播架構

直播架構

這種架構與上一種比要複雜不少，其中最主要的差別是增加了自有網絡。客戶端通過 UDP 進行數據傳輸，這樣可以大大減少由於網絡及CDN結構導致的音視頻延遲問題。

共享者共享音視頻時，都是通過UDP協議上傳到自有網絡服務器上。如果有其它參與人要與共享者進行實時互動，那麼參與者也是通過UDP連接到自有網絡，這樣才能達到實時互動的效果。

共享者的音視頻數據上傳到自有網絡後，還要通過專門的服務將數據流轉成RTMP流推到CDN網絡，這樣對於大多數不參與時實互動的用戶就可以從CDN獲取數音視頻數據了。

這種架構既可以滿足實時互動的需求，也可以滿足大批用戶只觀看不互動的需求。

解決高負載大並發問題

直播架構

為了解決實時互動大負載，高並發的問題，需要增加資源管理服務器，實時監測各服務的資源。第次當用戶共享音視頻時，資源管理器都可以分配最佳的服務器給共享用戶使用，並且服務器資源可以根據需要橫向擴容。

注意 為了增加執行效率，服務端基本都是用 C/C++ 程序編寫。

小結

實時互動直播是未來的直播趨勢，大看可以看一下我另一篇文章音視頻直播漫談中的介紹。有了這個架構我們後面就可以逐步的給大家講解每個主題。如 Android、IOS、windows、mac下如何進行音視頻數據採集，如何進行編碼，是採用硬編還是使用軟編?它們各自有什麼優勢，如何使用 opengl 進行渲染，如何進行網絡優化等等。