直播-PK連麥

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

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

PK直播視頻流處理流程

PK直播比單主播復(fù)雜很多，以下有三種實現(xiàn)方案，分別展開討論，并分析優(yōu)缺點。

一、視頻流不合并

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

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

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

二、主播端完成合流操作

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

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

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

三、服務(wù)端合流中轉(zhuǎn)分發(fā)

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

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

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

總結(jié)

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

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。