直播推流

什麼叫推流？

• 推流是把採集階段封包好的內容傳輸到服務器的過程。其實就是將現場的視頻信號傳到網絡的過程。「推流」對網絡要求比較高，若是網絡不穩定，直播效果就會不好，觀衆觀看直播時就會發生卡頓等現象，觀看體驗非常糟糕。

• 要想用於推流還必須把音視頻數據使用傳輸協議進行封裝，變成流數據。經常使用的流傳輸協議有RTSP、RTMP、HLS等，使用RTMP傳輸的延時一般在1–3秒，對於手機直播這種實時性要求很是高的場景，RTMP也成爲手機直播中最經常使用的流傳輸協議。最後經過必定的Qos算法將音視頻流數據推送到網絡斷，經過CDN進行分發。

擴展資料：

直播中使用普遍的「推流協議」通常是RTMP（Real Time Messaging Protocol——實時消息傳輸協議）。該協議是一個基於TCP的協議族，是一種設計用來進行實時數據通訊的網絡協議，主要用來在Flash/AIR平臺和支持RTMP協議的流媒體/交互服務器之間進行音視頻和數據通訊。支持該協議的軟件包括Adobe Media Server/Ultrant Media Server/red5等。

在高精尖沙龍直播中，最初使用傳統設備進行「推流」。

具體過程就是：經過網線將EFP系統中的切換臺、網絡編碼器、筆記本按順序鏈接，鏈接完成後確保筆記本電腦的IP地址和網絡編碼器的地址在同一網段，而後在電腦頁面上對編碼器的各類「推流參數」進行調整，爲保證正常「推流」，還需設置網絡推流地址，輸入推流地址、直播地址、視頻模式、分辨率、碼率、播放域名、播放地址等內容。設置完畢後確認IP地址，再進行網絡測速，並確保網絡與網絡編碼器鏈接正常。此種「推流」所需設備過多，出現問題後十分麻煩，須要對設備進行逐一排查，極耗費時間。

後來，將直播系統改成Livestudio系統，「推流」內置在Livestudio的軟件之中，整個「推流」過程再也不須要額外的網絡編碼器和筆記本等設備，也無需再設置IP，只要網絡正常，聯網便可完成操做，還可根據網絡的實際狀況設置「推流」的質量以知足要求。此種操做十分便捷，有效避免了上述問題的出現。

推流

• 推流必須把音視頻數據使用傳輸協議進行封裝，變成流數據。
• 經常使用的流傳輸協議有RTSP、RTMP、HLS等，使用RTMP傳輸的延時一般在1–3秒，對於手機直播這種實時性要求很是高的場景，RTMP也成爲手機直播中最經常使用的流傳輸協議。最後經過必定的Qos算法將音視頻流數據推送到網絡斷，經過CDN進行分發。
• 在直播場景中，網絡不穩定是很是常見的，這時就須要Qos來保證網絡不穩狀況下的用戶觀看直播的體驗，一般是經過主播端和播放端設置緩存，讓碼率均勻。另外，針對實時變化的網絡情況，動態碼率和幀率也是最經常使用的策略

推流實現方案

• 網絡傳輸方面所有本身作花費較大（基本不現實）
• 國內提供推流服務的CND服務商雲視頻服務商
• 阿里雲是國內惟一能自研CDN緩存服務器的廠商，性能仍是很是優越
• 大多數直播平臺都會同時接入多個視頻雲服務提供商，這樣能夠作拉流線路互備，對推流後視頻集羣再進行優化也可提升直播的流暢性和穩定性。
• 趣拍直播SDK依託阿里雲的CDN和趣拍成熟的直播技術保障直播快速接入APP。

CDN

• 基本原理是普遍採用各類緩存服務器，將這些緩存服務器分佈到用戶訪問相對集中的地區或網絡中，在用戶訪問網站時，利用全局負載技術將用戶的訪問指向距離最近的工做正常的緩存服務器上，由緩存服務器直接響應用戶請求。
• 內容分發網絡(CDN)是一個經策略性部署的總體系統，包括分佈式存儲、負載均衡、網絡請求的重定向和內容管理4個要件。

內容分發技術

• 分段分發技術

  • 流媒體對邊緣內容的完整性沒有要求，節點只需存儲少許的節目或節目片斷便可實時推送內容，爲用戶提供完整的服務。當用戶點播的內容只有部分片斷或沒有時，系統將採用分發技術進行內容的快速分發。

• 部分分發技術

  • 部分分發技術可提高邊緣系統的命中率，若是對10%的內容採用全複製，20%的內容採用50%複製，50%的內容採用10%複製，那麼，系統能夠實現95%以上的命中率，大大下降骨幹網的負荷，具備優越的分發性能。

負載均衡技術編輯

• 負載均衡是整個CDN的核心，負載均衡的準確性和效率直接決定了整個CDN的效率和性能。 負載均衡技術將網絡的流量儘量均勻地分配到幾個能完成相同任務的服務器或網絡節點上進行處理，避免部分網絡節點過載而另外一部分節點空閒的不利情況，既能夠提升網絡流量，又能夠提升網絡的總體性能。

CND技術點

• 內容發佈：它藉助於創建索引、緩存、流分裂、組播（Multicast）等技術，將內容發佈或投遞到距離用戶最近的遠程服務點（POP）處；
• 內容路由：它是總體性的網絡負載均衡技術，經過內容路由器中的重定向（DNS）機制，在多個遠程POP上均衡用戶的請求，以使用戶請求獲得最近內容源的響應；
• 內容交換：它根據內容的可用性、服務器的可用性以及用戶的背景，在POP的緩存服務器上，利用應用層交換、流分裂、重定向（ICP、WCCP）等技術，智能地平衡負載流量；
• 性能管理：它經過內部和外部監控系統，獲取網絡部件的情況信息，測量內容發佈的端到端性能（如包丟失、延時、平均帶寬、啓動時間、幀速率等），保證網絡處於最佳的運行狀態。

1. 需求背景

• 看寶寶與明日之星是貝聊的視頻直播產品，目前只是使用七牛一家的直播雲服務。基本業務是經過攝像頭設備或老師的手機直播，推流到七牛，家長經過H5的頁面觀看。業務流程圖以下：

• 能夠明顯發現：貝聊服務端和客戶端都徹底依賴七牛雲的服務，萬一七牛雲出現故障，整個視頻直播產品就癱瘓了！因而咱們的需求就誕生了：接入另外一家直播雲服務商，提升服務可用性。如此一來，既可作爲容災，也可作流量切換。

2. 直播雲服務商選擇

• 通過調研，咱們鎖定的備選服務商有騰訊雲、阿里雲、金山雲、網易雲。新的直播雲服務商選擇，不能拍腦殼決定。須要考慮各服務商的優缺點、成本以及是否能知足咱們的功能要求等。總結主要有如下幾點：
• 客戶端的限制：咱們的貝聊老師版APP，安卓系統要求最低是版本4.0，而阿里雲和網易雲要求最低版本是4.3
• 現有功能點的限制：產品已經上線，新的服務商應與七牛的功能類似，包括推拉流、鑑權、定時截圖、狀態回調通知、保存回放等
• 成本的問題：騰訊雲成本最高，阿里雲和金山雲相對較低
  • 因爲客戶端的限制，備選服務商基本鎖定在騰訊雲和金山雲。既然是做爲備用，成本就是次要因素了，穩定可靠纔是咱們的核心關注點。所以，咱們最終選擇了騰訊雲做爲備選直播服務商。

3. 實現過程

• 接入一家新的直播雲服務商，業務流程圖調整以下：

  

3.1 業務變化

• 後臺增長操做功能，可切換服務商和客戶端使用的SDK。目前只有人工切換服務商，後續能夠加入系統檢測報警機制，並自動進行切換。但若徹底靠系統自動切換，會有誤報風險。

• 直播是以節目爲單位，在建立節目時增長一個字段標識使用哪一個服務商。後續一切操做，例如：生成推流地址、拉流地址、截圖、保存回放都調用這個服務商的接口。

• 推流地址是服務器生成並簽名後返回給客戶端，客戶端無需關心使用的服務商，只需關心使用哪一個SDK。優先使用騰訊雲SDK，因爲沒法保證其穩定性，因此前期同時接入七牛雲和騰訊雲的SDK，由後臺配置各自使用比例。

• 增長對騰訊雲回調通知的處理

• 包括推流狀態回調、截圖回調、生成錄製文件回調。一個節目有一個流空間，七牛雲和騰訊雲的流空間是全局惟一的，因此不論是七牛雲仍是騰訊雲的每一個回調都能準確的找到對應的節目。

• 生成回放的方式徹底不一樣。七牛雲是在直播結束時調用接口生成的，而騰訊雲是在推流地址後加參數&record=mp4&record_interval=5400，而後接收回調。騰訊雲還能夠配置全局的推流自動保存。

• 騰訊雲區分生產環境和測試環境。騰訊雲的回調通知是全局配置的，沒法區分環境，使用多個帳號又增長成本，因而把回調通知都配置成生產環境的，調用異步處理接口時把taskId存到數據庫，生產環境找不到則轉發到測試環境。 3.2 代碼結構變化

  

• 最初只接入一家服務商，代碼結構比較簡單。現在，爲了不有重複代碼，過多使用if、else，因此使用了簡單工廠模式。業務代碼統一調用工廠類VideoTV3rdLiveServiceFactory，七牛雲和騰訊雲各寫了一套業務代碼，分別是VideoTVQcloudLiveService和VideoTVQiniuLiveService，實現生成推流地址、獲取拉流地址、保存回放等與業務相關的邏輯代碼。QcloudService是對騰訊雲API和SDK的封裝，PiliService和StorageService是對七牛雲SDK的封裝。

4. 後續工做

• 實現系統故障檢測報警。系統定時嘗試推流，若是失敗累計達到n次後發送郵件、短信報警。
• 有新的業務需求須要實現兩套，分別對接七牛雲和騰訊雲。