前言
2020上半年，直播再次成為中文互聯網世界的新風口，甚至到了無達人不直播，無名人不帶貨的地步；從2016年直播元年開始，直播的內容越來越多元，從秀場直播，游戲直播，到短視頻直播普濟眾生，再到電商直播的“帶貨”，“眼球經濟”成長為互聯網上的主流。本文介紹愛奇藝在奇秀直播的技術探索。
奇秀直播的兩種直播場景簡介
第一、普通直播：有一個主播和很多觀眾，該場景下主播一個人表演，其他觀眾通過平臺IM系統跟主播進行文字互動，類似于單口相聲；這種場景大部分使用RTMP協議，然后通過CDN的方式去做分發，從而實現大規模高并發的數據分發。
第二、連麥直播：該模式下主播跟觀眾除了基于IM系統溝通外，還可以進行和其他一個，或者多個主播實時音視頻互動，普通觀眾可以同時觀看多個主播的畫面，效果直觀，更能有效吸引用戶，類似于對口相聲和群口相聲。
在連麥直播有很多有價值的業務場景，比如PK場景，此時每個主播頭像上面會顯示一個血條，當觀眾給某個主播送禮時，她的血條則會增長，結束時哪方觀眾送的禮物多就會勝利，失敗了會被懲罰，這樣一來，就能讓觀眾更多地參與到直播的過程中，而且是通過送禮物。
直播場景使用的技術介紹
在技術上，普通主播一般是基于TCP的RTMP協議來推流的，而連麥直播一般是使用基于UDP的RTP協議來推流的。由于連麥直播是基于UDP的，還需要考慮應用層的丟包重傳問題。在實現復雜度上，普通主播是相對較低的，而連麥直播實現復雜度相對較高。
對于連麥直播可以使用多種技術實現，比如對RTMP改進，傳統的視頻會議系統，WebRTC改進等。奇秀直播采用的woogeen，一種WebRTC改進實現的,對客戶端SDK和后臺MCU服務器進行重新設計,專門針對直播推流，直播連麥等應用場景，整體架構如下：
主要模塊及功能：
第一、客戶端SDK：主要包含信令功能和將WebRTC流推送到MCU；
第二、MCU節點：socketio信令接入，WebRTC流接入，音視頻轉碼和混流，并負責把RTMP流推送出去；
第三、MCU_DNS：為用戶提供最佳MCU節點。MCU_DNS負責節點管理，包括MCU單點負載收集，MCU申請調度， 黑名單機制， MCU集群上線/下線處理；
第四、MCU_API：提供業務操作API，比如HTTP信令接入，控制推流和混流等復雜操作，簡化業務方的接入工作量；
第五、業務后臺：負責推流所需的資源（例如，MCU房間號，RTMP地址）和收集MCU_API的反饋信息，控制整個直播和連麥的過程；
系統架構拓撲
這里介紹一下奇秀直播系統的拓撲結構，從上圖可以看出，主播是把音視頻流通過RTP推流到MCU服務器；在普通直播時，MCU服務器只需要把收到的音視頻流轉發到RTMP，當前切換到連麥直播場景時，MCU服務器會在不中斷流的情況下進行合成，然后把合成流再轉發到RTMP，連麥開始和結束畫面實現平滑切換；
從觀眾端來看，都是使用HTTP-FLV/RTMP來進行拉流播放，且都是基于TCP的，并且普通和連麥場景切換時不會斷流或卡頓；其次，每臺MCU服務器都是一個獨立的服務提供者，各臺服務器可獨立上線和升級，服務器之間無相互依賴，如服務器異常，只影響當前服務器，做到去中心化;
連麥問題和優化
（一）、WebRTC的優化
奇秀連麥基于WebRTC，但由于WebRTC一個針對面向通話的解決方案，所以需要對WebRTC進行調整和優化。
- WebRTC采集的音頻是8K或16K的，因為人在通話過程中信號的頻率是不超過4KHz的，而直播主要是主播唱歌等一些音樂場景，所以必須要求是高采樣率的，現在使用是48K的采樣率。
- 為了延時更低，WebRTC使用10~32Kbps的低碼率音頻編碼，這樣音質很差，而音視頻直播里要用到64~320Kbps的高碼率的音頻編碼，但還要考慮設備和網絡情況，現在通過界面選擇編碼碼率，默認128Kbps的音頻編碼；
- 視頻編碼采用的是VP8和VP9，但VP8和VP9不適合在CDN上進行分發，現在使用的是H.264這種比較通用的視頻編碼；
- 在傳輸方式上，WebRTC使用P2P方式來進行媒體中轉，它只是解決端到端的問題，而對于連麥直播來說，并不僅僅解決主播端的音視頻互通問題，還要把主播的數據推送到連麥服務器、CDN，且要保證到達我們的觀眾端，所以在連麥系統上是Relay的方式，很好處理推流和混流的問題。
（二）、連麥問題解決
另外和普通直播相比，連麥直播還需要重點解決下面幾個問題：
1、混流問題：在連麥直播里有兩個或多個主播的音視頻流，首先要解決的就是進行混流。對于混流的技術，可以選擇在服務器合流、多流播放和在客戶端合流播放等，奇秀連麥采用的服務器合流技術，可以減少下行網絡帶寬和播放設備的壓力等；在服務器上有一個單獨服務進程處理拉流、混流、和推流，它維護所有有關的信息，外部只需要通過API和它交互，避免了上層處理這些事務。
2、推流延時問題：試想一下，如果連麥過程中主播說一句話，對方要等三四秒才能聽到，連麥的體驗就會非常差，而普通直播無這個要求，這個問題從以下幾個個方面進行解決：
- 開播前的網絡優選。當主播在發起直播時會根據她所在地理位置，網絡運營商以及服務器的負載等條件，然后從所有的節點里面選出一個比較好的節點和MCU服務器進行推流。
- 是碼率動態調整。在連麥直播里，必須保障音視頻的實時性，另外不花屏、不卡頓，所以在傳輸的過程中，采用了碼率自適應策略。由于主播的網絡是非常復雜，所以采用根據網絡情況動態調整碼率的情況，并不是實時地隨著網絡去變化，而是有一個快降慢升的邏輯，如果碼率上調太快，則會導致網絡出現一個很不穩定的狀態。快降慢升的方式就是當出現丟包的時候，馬上下調碼率，并且只有當保持了幾秒以上的穩定狀態后，才允許碼率上調。碼率動態調整使用了WebRTC的擁塞控制算法，共有兩種：
（1）、基于延遲（delay-based）的擁塞控制算法，由收端進行帶寬估算，接收方需要每個數據包到達的時間和大小，并計算每個數據分組之間（inter-group）的延遲的變化，由此判斷當前網絡的擁塞情況，并最終輸出碼率估計值由RTCP feedback（TMMBR或 REMB）反饋給發送方；在估算時，利用卡爾曼濾波，對每一幀的發送時間和接收時間進行分析，修正估出的帶寬。 （2）、基于丟包（loss-based）的擁塞控制算法，發端帶寬控制，發送方通過從接收方周期性發來的RTCP RR（Receiver Report）中獲取丟包信息以及計算RTT，進行丟包統計，并結合TMMBR或REMB中攜帶的碼率信息算得最終的碼率值，來動態的增加或減少帶寬，在減少帶寬時使用TFRC算法來增加平滑度。然后由媒體引擎根據碼率來配置編碼器，從而實現碼率的自適應調整。
- 是性能優化。在直播過程中經常遇到設備發熱的問題，設備發熱會導致系統降頻，以及對攝像頭的采集掉幀嚴重。首先，美顏和特效的功能是可開關的，如果發現性能不行，可以選擇不開；其次，特效在不同的機型都有不同的展示。再者，除了個別機型不能支持音視頻硬編解外，實現了音視頻的硬編硬解。
3、房間管理問題：
房間管理會涉及到一些業務層面的邏輯，比如說房間的狀態、房間里有多少人、大小主播之間怎么溝通，這些都需要通過房間管理來做好的。為了保持獨立，在服務器上有一個單獨服務進程進行房間的管理，它維護了所有的的信息。另外為了同時支持普通和連麥直播，現在為每個主播端單獨創建一個房間；當連麥時，會相互拉取對方房間的流進行合成，而不是加入同一個房間。
4、回聲問題：普通直播里面回聲基本上不會存在，因為它是單向的，但是在連麥里面回聲是必須要解決的。一般產生回聲的原因是近端的聲音被自己的麥克風采集后通過網絡傳到遠端，而遠端揚聲器播放出來的聲音被麥克風采集后通過網絡又重新發回近端，使得近端通話者能夠從揚聲器中聽到自己的剛才說的話，產生回聲。
采取回音分端進行優化：
- 在PC端，一般通過機架軟件和兼容的聲卡，配置不同的通道，比如伴奏，系統，麥克風，混響等，避免連麥聲音被采集再次推流進行回音處理；
- 在移動端，通過動態切換混音消除進行回音消除，連麥時開啟回音消除，不連麥時不進行回音消除，提高聲音質量。采用的是webRTC的混音消除算法(AEC,AECM)，采用自適應濾波算法實現回聲消除。該算法以輸出到揚聲器的音頻數據為依據,根據現場的回聲路徑特征,模擬出回聲信號。以模擬回聲信號為依據,從麥克風采集到的音頻數據中濾除模擬回聲信號，使用的算法包括 a.回聲時延估計 b.NLMS(歸一化最小均方自適應算法) c.NLP（非線性濾波） d.CNG(舒適噪聲產生等；
繼續優化的方向
第一、是連麥服務器是允許實時切換,前文提到當主播在發起直播時，會根據她所在地理位置，網絡運營商，以及服務器的負載等條件，然后從所有的節點里面選出一個比較好的節點進行主播推流網絡的優選，但是如果在推流過程中發生問題，只能重新開播；如果這時主播在PK，會影響主播的榜單和成績，所以在推流過程中發生問題可以實時切換服務器，是一個值得優化的方向。
第二，在移動開播過程中，如果發生網絡切換時，在推流過程響應網絡的實時切換是一個值得優化的方向。第三，移動端現在回音消除通過webRTC的混音消除算法進行處理，但是處理后音質一般，需要進一步根據娛樂場景進行優化。
