視頻直播架構

1、視頻推流端（SDK軟件工具）

    1.用戶視頻採集

         AVFoundation架構：是用來播放和建立實時的視聽媒體數據的框架，同時提供Objective-C接口來操做這些視聽數據，好比編輯，旋轉，重編碼。

   2. 視頻處理框架 

        GPUImage架構：是一個基於OpenGL ES的一個強大的圖像/視頻處理框架,封裝好了各類濾鏡同時也能夠編寫自定義的濾鏡,其自己內置了多達120多種常見的濾鏡效果。

   3.視頻編碼解碼

    FFmpeg架構:是一個跨平臺的開源視頻框架,能實現如視頻編碼,解碼,轉碼,串流,播放等豐富的功能。其支持的視頻格式以及播放協議很是豐富,幾乎包含了全部音視頻編解碼、封裝格式以及播放協議。

      X264架構:把視頻原數據YUV編碼壓縮成H.264格式。

  4.視頻封裝格式

   TS : 一種流媒體封裝格式，流媒體封裝有一個好處，就是不須要加載索引再播放，大大減小了首次載入的延遲，若是片子比較長，mp4文件的索引至關大，影響用戶體驗爲何要用TS:這是由於兩個TS片斷能夠無縫拼接，播放器能連續播放。

 FLV: 一種流媒體封裝格式,因爲它造成的文件極小、加載速度極快，使得網絡觀看視頻文件成爲可能,所以FLV格式成爲了當今主流視頻格式。

5.視頻推流

 Librtmp:用來傳輸RTMP協議格式的數據。

RTMP:實時消息傳輸協議,Adobe Systems公司爲Flash播放器和服務器之間音頻、視頻和數據傳輸開發的開放協議。

 2、服務器架構

 1.數據分發（CDN）

 CDN：(Content Delivery Network)，即內容分發網絡,將網站的內容發佈到最接近用戶的網絡」邊緣」，使用戶能夠就近取得所需的內容，解決 Internet網絡擁擠的情況，提升用戶訪問網站的響應速度.

CDN工做原理：好比請求流媒體數據

• 1.上傳流媒體數據到服務器（源站）
• 2.源站存儲流媒體數據
• 3.客戶端播放流媒體，向CDN請求編碼後的流媒體數據
• 4.CDN的服務器響應請求，若節點上沒有該流媒體數據存在，則向源站繼續請求流媒體數據；若節點上已經緩存了該視頻文件，則跳到第6步。
• 5.源站響應CDN的請求，將流媒體分發到相應的CDN節點上
• 6.CDN將流媒體數據發送到客戶端
• 回源：當有用戶訪問某一個URL的時候，若是被解析到的那個CDN節點沒有緩存響應的內容，或者是緩存已經到期，就會回源站去獲取搜索。若是沒有人訪問，那麼CDN節點不會主動去源站拿.
• 帶寬:在固定的時間可傳輸的數據總量，好比64位、800MHz的前端總線，它的數據傳輸率就等於64bit×800MHz÷8(Byte)=6.4GB/s
• 負載均衡: 由多臺服務器以對稱的方式組成一個服務器集合，每臺服務器都具備等價的地位，均可以單獨對外提供服務而無須其餘服務器的輔助,經過某種負載分擔技術，將外部發送來的請求均勻分配到對稱結構中的某一臺服務器上，而接收到請求的服務器獨立地迴應客戶的請求。均衡負載可以平均分配客戶請求到服務器列陣，籍此提供快速獲取重要數據，解決大量併發訪問服務問題。這種羣集技術能夠用最少的投資得到接近於大型主機的性能。
• QoS（帶寬管理）:限制每個組羣的帶寬，讓有限的帶寬發揮最大的效用。

2.架構選型

          Web層：Nginx＋PHP-FPM，開發迅速，適合團隊技術現狀，但須要針對服務器，作必定的調優配置。

• 緩存層：Redis主從庫、SSDB大容量存儲，會在各個業務塊兒使用，增長系統性能。
• 存儲層：MySQL主從庫存儲重要業務數據，屬性變化不大。MongoDB數據庫存儲字段不固定變動較多的數值明細記錄。SSDB存儲觀看記錄關注等列表較長，且性能要求較高的數據。分表分庫上考慮用戶註冊量和主播播放頻率，用戶中心、主播播放時長採用了按用戶ID Sharding和 按年Sharding兩種策略。業務初期暫時沒有分庫需求。
• 消息隊列：實現業務解耦，使用當前較流行的Kafka隊列。
• 日誌收集：syslog-ng日誌收集系統。

3、視頻拉流播放端

 

• 直播協議選擇：
  • 即時性要求較高或有互動需求的能夠採用RTMP,RTSP
  • 對於有回放或跨平臺需求的，推薦使用HLS
• 直播協議對比 :

 

直播協議對比.png

 

• HLS:由Apple公司定義的用於實時流傳輸的協議,HLS基於HTTP協議實現，傳輸內容包括兩部分，一是M3U8描述文件，二是TS媒體文件。可實現流媒體的直播和點播，主要應用在iOS系統
  • HLS是以點播的技術方式來實現直播
  • HLS是自適應碼率流播，客戶端會根據網絡情況自動選擇不一樣碼率的視頻流，條件容許的狀況下使用高碼率，網絡繁忙的時候使用低碼率，而且自動在兩者間隨意切
    換。這對移動設備網絡情況不穩定的狀況下保障流暢播放很是有幫助。
  • 實現方法是服務器端提供多碼率視頻流，而且在列表文件中註明，播放器根據播放進度和下載速度自動調整。
• HLS與RTMP對比:HLS主要是延時比較大，RTMP主要優點在於延時低
  • HLS協議的小切片方式會生成大量的文件，存儲或處理這些文件會形成大量資源浪費
  • 相比使用RTSP協議的好處在於，一旦切分完成，以後的分發過程徹底不須要額外使用任何專門軟件，普通的網絡服務器便可，大大下降了CDN邊緣服務器的配置要求，可使用任何現成的CDN,而通常服務器不多支持RTSP。
• HTTP-FLV:基於HTTP協議流式的傳輸媒體內容。
  • 相對於RTMP，HTTP更簡單和廣爲人知，內容延遲一樣能夠作到1~3秒，打開速度更快，由於HTTP自己沒有複雜的狀態交互。因此從延遲角度來看，HTTP-FLV要優於RTMP。
• RTSP:實時流傳輸協議,定義了一對多應用程序如何有效地經過IP網絡傳送多媒體數據.
• RTP:實時傳輸協議,RTP是創建在UDP協議上的，常與RTCP一塊兒使用，其自己並無提供按時發送機制或其它服務質量（QoS）保證，它依賴於低層服務去實現這一過程。
• RTCP:RTP的配套協議,主要功能是爲RTP所提供的服務質量（QoS）提供反饋，收集相關媒體鏈接的統計信息，例如傳輸字節數，傳輸分組數，丟失分組數，單向和雙向網絡延遲等等。

 

1.解碼

 * 1.1 解封裝 *

 

• demuxing（分離）：從視頻流、音頻流，字幕流合成的文件(容器格式（FLV，TS）)中， 分解出視頻、音頻或字幕，各自進行解碼。

 

* 1.2 音頻編碼框架 *

 

• fdk_aac:音頻編碼解碼框架，PCM音頻數據和AAC音頻數據互轉

 

  

 * 1.3 解碼介紹 *

       硬解碼：用GPU來解碼，減小CPU運算

• 　優勢：播放流暢、低功耗，解碼速度快，
  * 缺點：兼容很差

• 軟解碼：用CPU來解碼
  • 優勢：兼容好
    * 缺點：加大CPU負擔，耗電增長、沒有硬解碼流暢，解碼速度相對慢

 

2.播放

 

• ijkplayer:一個基於FFmpeg的開源Android/iOS視頻播放器
  • API易於集成；
  • 編譯配置可裁剪，方便控制安裝包大小；
  • 支持硬件加速解碼，更加省電
  • 簡單易用，指定拉流URL，自動解碼播放.

 

3.聊天互動

 

• IM:(InstantMessaging)即時通信:是一個實時通訊系統，容許兩人或多人使用網絡實時的傳遞文字消息、文件、語音與視頻交流.
  • IM在直播系統中的主要做用是實現觀衆與主播、觀衆與觀衆之間的文字互動.
    * 第三方SDK *

• 騰訊雲：騰訊提供的即時通信SDK，可做爲直播的聊天室

• 融雲：一個比較經常使用的即時通信SDK，可做爲直播的聊天室