直播業務知識整理

直播相關

整理的一些直播業務下相關基礎知識點。

參考鏈接

1採集

音頻

• 麥克風是否可用
• 檢測手機對某個音頻採樣率的支持
• 音頻採集時設置正確的緩衝區大小
• 特殊場景如連麥進行回聲消除

視頻

• 攝像頭是否可用
• 攝像頭採集到的圖像是橫屏，需要進行旋轉處理後進行展示
• 各種手機屏幕大小比例特殊處理

2處理

處理內容

將視頻幀進行加工，然後一幀一幀的渲染到屏幕上。

• 美顏
• 水印

處理框架技術

• GPUImage

  基於 OpenGL ES 的一個強大的圖像、視頻處理框架，支持各種預定義以及自定義濾鏡效果。

• OpenGL

  Open Graphics Library 定義了一個跨編程語言、跨平臺的編程接口的標準，是一個功能強大的，調用方便的底層圖形庫。

• OpenGL ES

  OpenGL for Embedded Systems 是 OpenGL 的三維圖形 API 的子集，針對手機，PDA 和遊戲主機等嵌入式設備而設計。

3編解碼

編碼：將視頻流，音頻流等數據以特定的容器格式封裝成文件

解碼：將視頻流、音頻流字幕等合成的文件中（容器格式 FLV，TS）分解出視頻，音頻或者字幕，各自進行解碼。

框架

• FFMpeg

  一個跨平臺的開原視頻框架，能實現視頻編碼，解碼，轉碼，串流，播放等豐富的功能。支持的視頻格式以及播放協議非常豐富，幾乎包含了所有的音視頻編解碼、封裝格式以及播放協議。

• libxxx

視頻編碼技術

對食品進行壓縮（視頻編碼）或者解壓縮（視頻解碼）。

主要目標是將視頻像素數據壓縮成視頻碼流，降低視頻的數據量。

P-B-I 幀分別是什麼：
I幀（關鍵幀）保留一幅完整的畫面，解碼時只需要本真數據就可以完成。

P 幀（差別幀）保留這一幀和之前幀的差別，解碼的時候需要用之前緩存的畫面疊加本幀的差別，來生成最終的畫面，所以可以看出 P 幀沒有完整的畫面數據，只有與前一幀的畫面差別的數據，

B 幀（雙向差別幀）保留的是本幀與前後幀的差別，解碼 B 幀，不僅要取得之前的緩存畫面，還需要解碼之後的畫面，通過前後畫面與本幀的數據疊加來輸出最終的畫面。因爲 B 真壓縮率搞，所以幾碼的時候會比較消耗 CPU。

• MPEG

  採用幀間壓縮，僅僅存儲連續幀之間有差別的地方，從而達到比較大的壓縮比。

• H.264/AVC

  採用實現預測（和 MPEG 中的 P-B 幀一樣的幀預測壓縮算法），可以根據需要產生網絡情況傳輸的視頻流，擁有更高的壓縮比和更好的圖像質量。

• H.265/HEVC

  基於 H.264，屬於增強版

• 合成muxing

  將視頻流音頻流甚至是字幕流封裝到一個文件中（比如文件格式爲 FLV，TS 等）作爲一個信號進行傳輸。

音頻編碼技術

• AAC

  音頻編碼技術，壓縮音頻用。

碼率控制

視頻播放軟件中的 1024.720 高清標清流暢等，指的就是各種碼率

視頻封裝格式

• TS

  流媒體封裝格式，不需要加載索引之後再播放，減少了首屏延遲

  兩個 TS 片段可以無縫拼接，播放器得以連續播放

• FLV

  流媒體文件封裝格式，文件極小，加載速度很快。

解碼

• 硬解碼

  用 GPU 來解碼，減少了 CPU 運算。

  優點：播放流暢，功耗低，解碼速度快。
  缺點：兼容性不好，廠商有關。

• 軟解碼

  用 CPU 來解碼

  優點：兼容性好
  缺點：耗CPU、功耗高，沒有硬解碼流暢，解碼速度相對較慢。

傳輸

傳輸協議

• RTMP

  實時消息傳輸協議，爲播放器和服務器之間，音頻視頻以及數據傳輸開發的一套開放協議。

  建立在 TCP 協議之上

  RTMP 協議就像是一個用來封裝數據包的容器，這些數據可以是 FLV 中的音視頻數據，一個單一的鏈接可以通過不同的通道傳輸多路網絡流（這些通道中的包都是按照固定的大小來進行傳輸的）

流媒體服務器

• SRS
• BMS
• NGINX

數據分發

• CDN

  • 推流地址
  • 拉流地址

推流

拉流

• 直播協議對比

  • *RTMP

    比較全能，即可以用來推送，又可以用來直播。

    核心理念：將大塊的視頻幀和音頻幀剁碎，然後以小數據包的形式在互聯網上進行傳輸，支持加密。拆包組包比較複雜，海量併發時容易出現一些不可預測的穩定性問題。

  • *FLV

    只是在大塊的視頻幀和音頻幀頭部加入一些標記頭信息，所以處理起來很方便。

    缺點：手機瀏覽器上的支持有限，但是手機端 APP 的直播協議卻異常成熟，可以很好的使用。

  • *HLS

    基於 HTTP 協議實現，傳輸內容包括兩部分：M3u8 描述文件➕TS 媒體文件
    可以實現流媒體的直播和點播
    （HLS 其實是以點播的形式來實現的直播，所以會有延遲，而且可以根據網絡狀態選擇不同碼率的視頻流，實現的方法是服務器端提供多碼率視頻流清單）

    對比 RTMP。HLS 時延較大，RTMP 時延低；HLS 會產生大量文件，造成資源浪費。但好處是這些文件的存在讓低端設備也能很好的處理。

  • HTTP-FLV

    基於 HTTP 協議實現的流式媒體傳輸。

    因爲HTTP 本身沒有很複雜的狀態交互，所以從延遲角度看，HTTP-FLV 要優於 RTMP

  • RTSP

    實時流傳輸協議：定義了一對多應用程序如何有效地通過 IP 網絡傳輸多媒體內容。

  • RTP

    基於 UDP 實現，本身沒有按時發送和其他 Qos(服務質量保證)，時延小，誤差稍大。

    服務質量保證由 RTP 的配套協議 RTCP 來收集媒體連接的統計信息，如串數字結束，傳輸分組數，丟失分組數，單向和雙向網絡延遲等

• 直播協議選擇

  即時性要求較高，或者有互動需求的可以採用 RTMP，RTSP

  對有回放或者跨平臺需求的，推薦使用 HLS。

互動

交互本身是個多模塊互相配合的場景。先來大致描述下一個直播業務的場景。

打開 APP 一個熱門頁面（從打開 APP 開始就會和 PHP 接口層交互）
點擊某一個房間（PHP 進行權限校驗，返回合法用戶需要的一些信息給 APP）
連 websocket，進行聊天直接交互
送禮，元數據中房間信息，主播信息等都可以拿得到。
送禮消息要展示給房間內其他用戶，但是送禮本身走的是 PHP，而非 ws。所以需要藉助 Redis 進行 pub/sub 做一次“透傳”行爲，讓 ws 將對應的數據轉發到房間內，讓其他人看得到。

關於“透傳”模型，這裏有一個比較通俗的參考

聊天

• websocket 服務器

  • netty-java 框架

  • 1協議升級，客戶端參數傳遞鏈接

    第一步是客戶端用 HTTP 來申請 upgrade，並傳遞過來一些服務器認證身份的參數，來避免外界干擾
    進行握手：
    Sec-WebSocket-Key1和Sec-WebSocket-Key2在舊的WEBSOCKET協議中是沒有的，因爲判斷當前請求是否WEBSOCKET，主要還是通過請求頭中的Connection是不是等於Upgrade以及Upgrade是否等於WebSocket，也就是說判斷一個請求是否WEBSOCKET請求，只需要判斷請求頭中的Connection及Upgrade，判斷新舊版本可以通過是否包含“Sec-WebSocket-Key1”和“Sec-WebSocket-Key2”。
    客戶端請求
    Upgrade:websocket
    Connection:Upgrade
    服務器響應 101 狀態碼 切換協議，連接爲 websocket連接

  • 2消息互聯

業務交互

• PHP 服務器

  • 業務機

    火星這邊一般叫 get 機，也就是常說的業務機器，真正負責更新用戶信息，房間信息以及CRUD等操作的執行。

    GET 機原則上來講可以快速擴容，前提是代碼環境準備好，因此一般爲了避免雪崩，get 機羣最好是有一兩臺隨時準備上線的機器，一旦某些 get 機出問題，可以立即修改前端機 Nginx 配置來頂上去，減少業務損失。

  • 前端機

    負責業務請求轉發與負載均衡。

    一般可以作爲彙總請求日誌來使用，但是要注意單點問題，一旦宕機，需要拿到 Nginx 配置然後迅速重啓服務，

推拉流

推流

主播將本地視頻源和音頻源推送到雲端服務器，有時也稱爲“RTMP 發佈”

拉流

XMind: ZEN - Trial Version