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