秀場直播的四種實現方式
阿新 • • 發佈：2020-10-23
秀場互動直播是 RTC 技術應用的常見場景，雖然主播PK 的業務邏輯不算複雜，但由於在標準直播模式和主播PK 模式的切換過程中容易產生卡頓、黑屏等現象，為了在優雅實現業務邏輯的同時，最大程度緩解類似的音視訊體驗問題，工程師們八仙過海各顯神通，提出了很多種秀場直播的實現架構，下面我們介紹其中最典型的四種架構
方案A：
概要說明：
- 最常見的實現方式，標準直播使用推流SDK，切換成PK模式的話，走的是連麥及合流轉碼服務；
- 算是個基準方案，其他方案的優缺點主要都基於跟方案A進行比較
方案風險：
- 客戶端會整合兩個SDK，現實中，採用該方案的客戶多會有兩個供應商，一個提供連麥，一個負責直播，這會存在產生產品間相容性問題的隱患
- 由於推流SDK和RTC SDK 是分開的兩個SDK，由於涉及到資源的申請和釋放，因此，在模式切換時，是比較容易產生卡頓、黑屏等現象的，優化難度較大
方案B：
概要說明：
- 該方案也可以稱之為雙流方案，所謂雙流，指的是觀眾端會拉兩個主播的流，而非其他方案的一個流；
- 除了雙流以外，該方案還沒有使用連麥服務中的合流轉碼功能
方案優點：
- 使用單路轉推功能，替代掉合流轉碼功能，由於合流轉碼一般的單價較高，因此，連麥的消費費用會有較明顯的降低
方案風險：
- 雖然連麥的消費會顯著下降，但由於觀眾端直播流需要拉兩路，因此直播雲消費可能會顯著上升，如果觀眾主播比較大的話，連麥+直播的總消費會較明顯增大
- 跟標準直播一樣，客戶端集成了兩個SDK，導致模式間切換的體驗優化比較困難，產品間的相容性隱患依舊存在
- 雙流方案，觀眾端的體驗比單流方案是可能有所下滑的，一方面對觀眾端的頻寬要求更高(*2)，另一方面，還存在一定概率的兩個主播的rtmp流時間不太同步的隱患
- 方案的擴充套件性相對也差些，比如如果未來要做主播觀眾連麥的玩法，終究還是會回到合流轉碼的方式上去
方案C：
概要說明：
- 該方案我們也稱之為客戶端合流方案，他的主要特點就是主播pk畫面的合流由客戶端完成；
方案優點：
- 把合流放到客戶端做，那就完全節省了這部分消費，因此，這是個成本最低的方案；
- 由於始終保持著客戶端跟直播雲的上行推流線路，在模式切換時不存在所謂進入搶流模式（兩個不同的上行推流裝置，同時往一個直播通道推流，後推的裝置會頂掉前面的上行裝置，該模式稱之為直播搶流模式），所以理論上模式間切換的體驗優化會稍稍好做些
方案風險：
- 這個方案缺點也比較顯著，把合流放到客戶端，對主播的網路和手機效能要求都明顯提高，尤其是網路，現在多了一路推流，等於上行頻寬*2，對直播而言，主播端的推流情況對觀眾體驗的影響是最重要的，主播頻寬要求*2，直播體驗下降的風險必然增加很大；
方案D：
概要說明：
- 該方案我們稱之為七牛方案，方案中的實時音視訊雲即為七牛QRTC產品，直播雲即為七牛PILI產品
- 技術上說，我們可以稱該方案為 純RTC 秀場直播方案，他拋棄了相對落後的RTMP推流模組，在技術上具備一定先進性
方案優點：
- 客戶端只用了一個 RTC SDK，客戶接入成本相對較低，且因為少個SDK，最終APP的包體會略有下降
- 標準直播模式，使用的是先進的 RTC 推流，相比 RTMP推流，RTC 推流抗弱網的表現更好，我們自己的測試，RTMP 推流在丟包10%情況下卡頓、延時往往就比較顯著了，而RTC 往往可以到30%丟包甚至更大的情況下，依然能有比較流暢的聲畫體驗，這是因為從技術上說，RTC 是比 RTMP 更先進的音視訊傳輸技術，是當前人類在音視訊傳輸領域進步的典型成果展示
- 推流抗弱網對絕大多數的秀場直播而言，其實意義不是很大，因為專業的主播往往網路條件比較好，但在戶外等場景，RTC推流的意義還是非常顯著的
- 由於使用的是一個RTC SDK，模式切換時，不存在SDK資源申請和釋放的問題，模式切換的體驗優化相對更容易些
- 該方案除了實時音視訊雲和直播雲，七牛秀場直播方案在RTC SDK上還深度融合了商湯和位元組跳動的美顏濾鏡SDK，這一方面幫助客戶規避了產品間相容性問題，另一方面又可以讓客戶享受到完整的閉環服務，且整個方案程式碼已全部開源
方案風險：
- 方案相比標準方案，唯一的隱患在於在標準直播模式下，會增加一個單路轉推的費用風險，但由於該服務單價極低，因此新增費用相對可控