直播-PK連麥

單主播直播視頻流處理流程

如上圖，主播端向CDN服務器推流，推流地址假定為rtmp://xxx。觀眾端觀看該主播時，拿到該主播的觀看地址（假設地址為xxx.flv）直接拉流即可。

PK直播視頻流處理流程

PK直播比單主播復雜很多，以下有三種實現方案，分別展開討論，并分析優缺點。

一、視頻流不合并

視頻流不合并，觀眾端拉取兩路流同時播放。這種方案觀眾端承擔大部分工作。

優點： a. 實現簡單。只需在直播間多加一個播放器就能解決 b. 延遲低。推拉流過程無太多中轉，網絡等外部條件正常情況下，延遲率與單主播模式相近 c. 無需額外消耗服務端資源

缺點： a. 對觀眾端設備要求高。觀眾端需同時播放兩路視頻，流的解碼、音視頻同步等工作翻倍。主播端此時也是作為觀眾端，推流的同時還需拉取pk對方的流。 b. 觀眾端帶寬翻倍。同時拉取兩路流，要保證正常播放，需更高的網速 c. 無法保證兩路流同步。兩路流分開推，分開拉，相互獨立無同步操作。同步強依賴網絡 d. 設備處理強度大，發熱嚴重

二、主播端完成合流操作

主播端完成合流操作。主播端拉取到PK對方直播流后解碼與本地采集重新編碼構造RTMP包推流。此時觀眾端只需拉取合成后的一路流。

優點： a. 可保證兩路流的同步問題 b. 無需額外消耗服務端資源

缺點： a. 對主播端設備要求較高，短時間內需處理拉流、合流、推流工作，主播端設備需較高性能 b. 主播端與觀眾端存在明顯延遲。觀眾端拉取的流是主播端先拉pk對方流、合流、推流三個步驟完成后拉取的結果。延遲率受設備處理性能和網絡影響不可控 c. 設備處理強度大，發熱嚴重

三、服務端合流中轉分發

服務端合流中轉分發。主播端照常需要拉取PK對方的直播流，但合流過程放在了服務器端處理。另開服務器完成合流，完成后向CDN服務器推流，保證觀眾端不切換拉流地址。

優點： a. 可保證兩路流的同步問題 b. 減輕客戶端設備的處理壓力，規避不同性能設備帶來的處理延遲問題 c. 客戶端處理簡單，只需主播端多拉次流播放即可

缺點： a. 需服務端配合完成合流、中轉工作 b. 主播端與觀眾端存在延遲，但延遲比方案二低。主播端推流有一步先推流到合流服務器再推到CDN服務器，多一個中轉環節，多一層延遲

總結

方案一：不合流方案。基本不考慮使用，寫個直播PK Demo還行，稍微有點用戶量就無法保證觀眾端不同層次配置設備的處理能力以及網絡、設備發熱問題

方案二：主播端合流。該方案算一個折中方案，也具備一定的適用場景。該方案有兩個大缺陷：第一，要求主播端具備高性能設備；第二，主播端與觀眾端延遲稍大。對于第二點，PK玩法主要是保證PK主播雙方同步，個人覺得主播與觀眾間的延遲個人覺得還是可以接受。低于缺陷一，自營主播，可以很容易從源頭解決主播端設備性能問題

方案三：從各方面來說，方案三都是很好的方案，適合大播放量業務,因為復雜工作都在服務端。

總結

以上是生活随笔為你收集整理的直播-PK连麦的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。