方案a：
概要說明：
最常見的實現方式，標準直播使用推流sdk，切換成pk模式的話，走的是連麥及合流轉碼服務；
算是個基準方案，其他方案的優缺點主要都基於跟方案a進行比較
方案風險：
客戶端會整合兩個sdk，現實中，採用該方案的客戶多會有兩個**商，乙個提供連麥，乙個負責直播，這會存在產生產品間相容性問題的隱患
由於推流sdk和rtc sdk 是分開的兩個sdk，由於涉及到資源的申請和釋放，因此，在模式切換時，是比較容易產生卡頓、黑屏等現象的，優化難度較大
方案b：
概要說明：
該方案也可以稱之為雙流方案，所謂雙流，指的是觀眾端會拉兩個主播的流，而非其他方案的乙個流；
除了雙流以外，該方案還沒有使用連麥服務中的合流轉碼功能
方案優點：
使用單路轉推功能，替代掉合流轉碼功能，由於合流轉碼一般的單價較高，因此，連麥的消費費用會有較明顯的降低
方案風險：
雖然連麥的消費會顯著下降，但由於觀眾端直播流需要拉兩路，因此直播雲消費可能會顯著上公升，如果觀眾主播比較大的話，連麥+直播的總消費會較明顯增大
跟標準直播一樣，客戶端整合了兩個sdk，導致模式間切換的體驗優化比較困難，產品間的相容性隱患依舊存在
雙流方案，觀眾端的體驗比單流方案是可能有所下滑的，一方面對觀眾端的頻寬要求更高(*2)，另一方面，還存在一定概率的兩個主播的rtmp流時間不太同步的隱患
方案的擴充套件性相對也差些，比如如果未來要做主播觀眾連麥的玩法，終究還是會回到合流轉碼的方式上去
方案c：
概要說明：
該方案我們也稱之為客戶端合流方案，他的主要特點就是主播pk畫面的合流由客戶端完成；
方案優點：
把合流放到客戶端做，那就完全節省了這部分消費，因此，這是個成本最低的方案；
由於始終保持著客戶端跟直播雲的上行推流線路，在模式切換時不存在所謂進入搶流模式（兩個不同的上行推流裝置，同時往乙個直播通道推流，後推的裝置會頂掉前面的上行裝置，該模式稱之為直播搶流模式），所以理論上模式間切換的體驗優化會稍稍好做些
方案風險：
這個方案缺點也比較顯著，把合流放到客戶端，對主播的網路和手機效能要求都明顯提高，尤其是網路，現在多了一路推流，等於上行頻寬*2，對直播而言，主播端的推流情況對觀眾體驗的影響是最重要的，主播頻寬要求*2，直播體驗下降的風險必然增加很大；
方案d：
概要說明：
技術上說，我們可以稱該方案為 純rtc 秀場直播方案，他拋棄了相對落後的rtmp推流模組，在技術上具備一定先進性
方案優點：
推流抗弱網對絕大多數的秀場直播而言，其實意義不是很大，因為專業的主播往往網路條件比較好，但在戶外等場景，rtc推流的意義還是非常顯著的
由於使用的是乙個rtc sdk，模式切換時，不存在sdk資源申請和釋放的問題，模式切換的體驗優化相對更容易些
方案風險：
方案相比標準方案，唯一的隱患在於在標準直播模式下，會增加乙個單路轉推的費用風險，但由於該服務單價極低，因此新增費用相對可控
搭建直播平台中主播pk，如何實現無縫切換？
搭建直播平台中主播pk，如何實現無縫切換？今天要介紹的就是主播連麥pk方案，通過這篇文章，我們將一起來了解什麼是主播連麥pk？以及怎麼快速實現主播間的連麥pk？我們先從最初的需求入手，看看最簡單的實現方案是什麼。從前面一張圖我們就可以看出，要想實現連麥pk，最簡答的辦法就是兩個主播各自把兩路畫面混在...
移動APP 秀場 直播動畫效果實現方案
專案名稱 flashanimationtomobile 原始碼。使用方法點這裡。對於flash軟體，則支援flash cs3及以上版本及最新的animate cc。實際效果如下 最開始有把flash關鍵幀動畫匯出的想法是當初做cocos2dx開發遊戲的時候。當時開發的乙個遊戲專案，模仿 刀塔傳奇 的...
電商直播I對主播直播帶貨翻車的思考
2019年，直播帶貨興起，2020年，因疫情電商直播帶貨直接起飛。這是因為直播能夠讓商品資訊更加透明，讓消費者看得著商品的品質，不用擔心買到 買家秀 而其中一些主播也在這股東風中聲名鵲起，而李佳琦，薇婭等頂級流量主播的崛起，也讓很多人直接加入了直播帶貨的大軍。這些直播翻車事件，無疑說明了，在直播帶貨...