低延遲音視訊傳輸技術在直播領域的應用

本文來自陌陌視訊流媒體技術負責人吳濤在WebRTCon 2018上的分享，他詳解了陌陌從傳統直播過渡到1對1到多人互動模式的演進，架構的優化保證了使用者體驗與業務需求。另外，文末為WebRTCon 2018最後一波PPT分享，點選閱讀原文下載。

文 / 吳濤

整理 / LiveVideoStack

概覽

我有幸曾在網際網路、安防監控、廣電音視訊傳輸三大領域從事工作，感覺自己現在的水平應該僅夠滿足實戰需求了，所以今天在這裡不敢說為大家做分享，只能說為大家彙報一些自己在這三個領域工作的心得體會。

網際網路直播的話題已經是老生常談了，我們也很難再講出來一些新的東西。我最早來到陌陌的時候，陌陌做音視訊傳輸技術的只有四個人，一個做客戶端，一個做支付，一個做後臺，剩下一個由我來做音視訊。可以說我見證了陌陌直播從襁褓之中成長為現在這樣一個成熟直播平臺的全過程。2017年Q4財報顯示，陌陌現在月活躍使用者數9910萬人，收入是3.58億美元，而陌陌視訊收入約3.2億美元，也就是說陌陌90%多的收入都是視訊提供的，這是現在陌陌直播平臺的發展情況。

今天我向大家分享的主要內容有：

1. 基於CDN架構的直播應用

2. 基於CDN架構的低延遲直播的應用

3. CDN架構下非互動直播的問題

4. 帶有互動能力的直播

5. 直播技術未來的發展

1.基於CDN架構的直播應用

這張圖是陌陌APP直播介面去除禮物、動畫等元素的效果圖。一位主播在螢幕前為使用者表演。主播能做的事，對著螢幕表演，使用者除了給主播送禮物或發訊息外無法與主播進行其他互動。有時使用者會發現主播不會對自己傳送的訊息作出反饋，這是為什麼？第一種原因可能是這位主播受關注度比較高，訊息量比較大，無法一一進行回覆；第二種原因可能是此時端對端延遲過大，使得主播響應無法及時送達到觀眾端。

以上是其中一種基於CDN架構的直播架構圖。這個架構圖很簡單，主播把直播資料推到了一個CDN的邊緣節點，使用者再從CDN的另一端的邊緣節點獲取直播資料，這種架構在直播當中十分常見，為什麼使用這種簡單架構？

1.1優勢

顯而易見的是，其優勢就是簡單。使用這種架構意味著企業不需要開發者有多強的網路技術能力，只需要確定域名後把音視訊傳入即可完成。並且，簡單意味著這種架構的開發效率非常高，也許只需編寫幾行程式碼或者進行配置即可完成。對於一個應用型公司來講，這種方案的開發門檻很低，所需要的時間、人力資源成本都很低，這也是網際網路直播使用CDN的好處之一。

1.2 劣勢

當然這種方案也存在劣勢。第一我們知道CDN是建立在TCP協議上的，這就導致CDN會受到TCP協議本身的約束，實時音視訊資料傳輸TCP協議棧並不十分理想；第二是使用CDN質量差異較大；第三是使用CDN難以隨需求進行定製化，CDN面對很多使用者的需求都是非定製化的；第四是使用CDN架構端對端的延遲大，我特意使用虛線將主播與觀眾相連標記時間。雖然每家公司的CDN解決方案都號稱端對端延遲只有三秒，實際上如果從使用者良好體驗的角度出發，經過測算端對端的延遲控制在5秒比較理想，低於5秒就可能會出現卡頓等影響體驗的問題。

1.3 技術關鍵點

CDN架構是直播的基礎方案，我們必須把這個方案做得足夠完美才能在直播體驗上有優勢。除了以上敘述的關鍵點，在實際應用場景上CDN還會受到很多條件的約束：從使用者體驗的角度來講，觀眾使用手機觀看直播，無論是使用陌陌還是其他友商的APP，當使用這個應用進入感興趣的直播間首先體驗到的是能夠快速呈現直播內容。如果使用者點選某個直播間後需要等待一下或者獲取視訊失敗，無疑是一個非常糟糕的體驗；其次是畫面的清晰度與流暢程度；再次是與主播間的延遲這些都是從使用者體驗的角度出發遇到的問題，我們需要使用技術手段來解決使用者遇到的這些問題。

我們把遇到的這些問題大致分成兩個方面並加以解決：一個是傳輸的前端，一個是傳輸的後端。

1.3.1 傳輸前端·推流器問題

首先需要解決的是傳輸的前端也就是主播端，在主播端需要解決的是推流器問題。

1）抗擁塞

對使用者而言在直播體驗上最糟糕的無疑是卡頓。使用者希望能夠看到流暢的直播，但是如果使用TCP協議就會出現擁塞問題，那麼我們如何來抗擁塞呢？抗擁塞本質是是降低TCP協議擁塞構成的干擾，其原理比較簡單，一種方案是減少在推流器上傳送的資料，降低幀率、位元速率、解析度等各種資料的傳輸量，資料的傳輸效率降低，擁塞對直播畫面的影響就會減弱；另一種方案則更加簡單粗暴，也就是一旦出現擁塞我們就丟棄資料或者重新建立連結，這樣也會有效減弱擁塞對直播畫面的影響。

2）秒開問題

第二點就是秒開問題，也許會有人認為使用CDN架構並不存在秒開問題，只要緩衝第一幀是關鍵幀就可解決。這個觀點沒錯但是不全面，需要緩衝多少資料？是緩衝一個關鍵幀還是關鍵幀所在的一個完整的GOP？還是一個關鍵幀與一些P幀（對於直播而言很少有B幀，因為B幀的編解碼耗時多，所以直播視訊儘量不使用B幀）？具體緩衝多少？這便牽扯到如何對GOP進行設定，而GOP的設定必須由編碼器決定，因為對於直播視訊流而言，一個GOP中I幀的佔比是非常大的，與同等引數下的體育直播不一樣。體育直播P幀與I幀的大小實際上是近似的，因為體育直播受到場景畫面變化劇烈的影響，也就是說GOP的具體引數需要根據直播場景與視訊畫面進行設定，並不能簡單理解為在CDN邊緣只快取一個關鍵幀或者只快取幾個資料就能解決。也許一個GOP值設定的非常龐大導致一個GOP需要三秒鐘，當使用者開啟直播畫面時一個關鍵幀後畫面出現一個跳轉，這種的體驗是非常糟糕的。我們根據直播的場景在編碼器上設定GOP能夠妥善處理秒開問題。

3）清晰度

使用者需要能夠快速開啟視訊並且流暢觀看，也需要看到清晰的畫面。以家庭影院為例，從最早的錄影帶，進化成VCD再進化到DVD，再進化到現在的藍光4K等等，畫面清晰度始終是使用者所追求的一項重要指標。這裡我有一份資料統計：陌陌在每年1月7號都會有一個盛典，直播舞臺上進行的一些表演。我把直播畫面清晰度進行了簡單分類，第一個是960×540的標清解析度，第二個是1280×720的高清解析度，第三個是1080P的全高清解析度。解析度為960×540時傳輸需要1M的頻寬，這時如果通過正常的網際網路傳輸直播畫面是很少卡頓的；而當解析度提高到1280×720時就需要2.5M到3M左右的頻寬進行傳輸，這時如果使用者是在家裡拿手機看直播畫面便會出現一些卡頓；當解析度提高到1080P時穩定傳輸需要5M以上頻寬，在這種情況下除非使用者家裡寬頻的網路質量非常好或者手機4G訊號特別強，否則就會出現多次直播畫面的卡頓。但根據使用者反饋的資料來看：解析度為720P的觀看使用者是最多的，使用1080P觀看直播畫面的使用者佔到了總使用者量的10%，其中觀看畫面模糊但流暢的使用者只佔不到25%，也就是說清晰度對於使用者而言非常重要。如何在推流器端優化清晰度呢？解決此問題不只依賴某個技術點，我們可以通過場景渲染、色彩增強等技術，也可根據直播環境背景色調整主播的著裝、環境光照等等，這些都會決定畫面的清晰度；我們可以將一路畫面設定成不同的解析度，對於兩個不同的解析度的視訊我們可以使用光照去彌補，使得使用者在不同的解析度上看到近似清晰的效果。總而言之，我們可以對不同的場景進行調整與匹配，優化畫面的清晰度。

1.3.2 傳輸後端·播放器問題

解決完推流器問題，接下來需要解決的是播放器問題。

1）抗卡頓

關於播放器首先需要解決的還是卡頓問題。抗卡頓是保證使用者體驗中最重要的方面，尤其是對於直播而言。那麼如何在播放器端妥善解決卡頓問題？較為簡單的方案是加緩衝，緩衝區的存在可以有效減少卡頓的次數與機率。

2）抗延遲

為什麼使用者給主播發訊息給主播，隔了好廠一段時間才有反饋？因為直播畫面存在延遲。卡頓與延遲是互相矛盾的條件，畫面流暢意味著可能延遲增大，延遲減小畫面又可能會因為網路不穩定等原因出現卡頓。關於這一點我們只能針對不同使用場景和業務環境進行動態調整，在減少延遲的同時儘量保證畫面的流暢。

3）拉流成功率

關於這一點的問題比較少見，理論上CDN模式能夠全球覆蓋、全網覆蓋，拉流肯定會成功，實際並非如此。舉個極端的例子，西部偏遠地區會經常出現拉流失敗；而在在流量高峰時段，資料採集拉流成功率只有90%左右，這就會導致使用者無法成功開啟直播畫面，直播清晰度流暢度也無從談起了，所以拉流成功率也需要我們關注。關於拉流成功率還需要說明的一點是，因為一些規模較小的寬頻運營商會做一些網帶緩衝，也可以說是域名劫持。一旦出現域名劫持自然無法成功拉流或者拉到非線上直播的流，這比較麻煩。為解決這一問題，在陌陌我們可能不一定下發IP而是一個302的排程點。通過這些措施來保證客戶端成功獲取正確的視訊流，確保拉流成功率。

2.基於CDN架構的低延遲直播的應用

講完了CDN架構的簡單應用，接下來講一講年初最火的直播答題。這張圖是陌陌的一個直播答題介面，直播答題實際上有什麼難點呢？

3.CDN架構下非互動直播的問題

延遲高、互動性差、表演內容相似度高、觀眾無法簡單參與

為什麼會有這些問題？因為此方案只是把播放器和CDN上的邊緣緩衝全部去除，這種模式是最簡單的。我們沒有對現有的CDN架構進行重大調整而是將主播推到CDN變成將主播推到三體雲，只需要調整SDK上的幾行程式碼即可實現。

4.帶有互動能力的直播

模式一：普通連線

雖然普通連線解決了最簡單的問題，但在實際應用場景中基本已經沒有廠商使用這種模式，因為通過這種模式達成的直播效果十分單調。

模式二：主播間連線

主播與主播之間的連線實際上是現在最受直播平臺與主播歡迎的一種直播答題模式。對於平臺而言可以通過這種模式讓一些不知名的主播與知名主播進行PK，能夠為提升主播知名度同時給直播平臺帶來流量；對於主播而言通過與別的主播進行PK可以推出新玩法，進一步的互動避免直播內容的同質化。這種模式的架構是資料從兩位主播所在的手機編碼器兩端推到CDN，觀眾從CDN邊緣獲取直播資料；與此同時資料也由主播端推到中間的互動雲伺服器，主播與主播之間通過互動雲進行連線。這種架構是最初搭建的一種，因為簡單到不需要大的改動就能實現。但實際上這種架構也存在問題：也就是這需要雙推主播端的直播資料，一路資料被推到CDN一路資料推到互動雲。兩路資料意味著兩路編碼，這對CPU、對頻寬的消耗很大。根據簡單測試在正常的環境或者在Wi-Fi的環境下，手機推流超過1.2M的時出現抖動的機率就會顯著提高。兩路編碼會帶來較高的CPU效能損耗，進而導致手機的發熱問題。如果我們對這種架構進行優化：

採用單推也就是把兩個主播端的資料先推到互動雲，資料在互動雲進行混合轉碼後推到CDN邊緣結點，這樣在主播的編碼器端只有一路資料需要推至雲，剩下處理過程的由伺服器代勞，便可解決雙推帶來的問題。 

模式三：多人連線（狼人殺模式）

第三種模式是多人聯線，我們內部稱其為“狼人殺模式”。為什麼叫狼人殺模式？多人連線這個模式其實是由“狼人殺”演變而來的。最早我們只是考慮觀眾和主播或主播和主播互動，從來沒考慮到觀眾之間也能實現互動。其實我們發現普通人有時更想參與互動，但是面對主播又無法去有效表達，遠沒有觀眾之間互動的參與熱情高。這種模式也非常受平臺青睞，因為在這種模式下使用者停留的時間就會變長。讓使用者以較低成本參與其中，不需要使用者具有特別的才藝就能展現自我。這也使得直播軟體成為一種社交方式，一個全民級應用。這種架構相對之前的更為簡單，也就是將所有參與使用者的音視訊資料傳到互動雲上就行了；互動雲再將資料推給CDN，對於不想看或者不想參與的使用者可以從CDN拉流，對於想觀看或者想參與的使用者可以連線到互動雲。當然這種模式也存在問題：我們知道普通人面對鏡頭的壓力還是非常大的，就像美顏、濾鏡是現在自拍的標配一樣，在直播中露臉這件事對普通使用者而言往往帶來較大壓力。

模式四：電臺模式

模式三的問題使其演變成了第四種模式——電臺模式，也就是隻直播使用者的音訊，這樣雖然不存在畫面但是業務模式並未改變。在這裡我有一個問題：模式四能否直接套用模式三的架構？其真實模式四用模式三是不行的，因為在實時互動雲模式下，主播之間的延遲是不足1秒的，但主播與觀眾之間的延遲是5秒左右。對於視訊畫面我們可以用轉場動畫處理使使用者不易察覺到這5秒延遲的存在，而在純音訊模式下無法用這種措施進行處理優化，因為使用者聽到的音訊是連續的，一旦少了一部分就會使使用者體驗大打折扣。所以對於第四種模式我們使用更加簡單的方式處理，也就是不經過CDN而直接用互動雲處理資料。使用者如果想參與直播互動就開啟麥克風，如果只想聽直播就關閉麥克風。對我們而言這種全新模式能夠以更低的開發成本為使用者帶來更好的互動直播體驗。

網際網路直播是否能改變直播行業？既然網際網路直播能夠實現互動，那麼電視直播能否實現互動？當然我們無法在家看電視直播時通過APP和電視臺主持人聊天。第一是因為電視直播從採集到播出需要層層的安全稽核。第二是因為缺乏更先進的資料傳輸技術，現有技術無法將電視直播的資料高效傳輸至互動雲。關於這一點在陌陌6月推出的世界盃直播業務時已經可以實現互動直播，也就是在世界盃現場用攝像機，導播臺，編碼器等一系列硬體裝置搭建起一個直播環境。使用者通過APP就能在觀看直播時和主持人互動，為什麼說這和電視直播的不一樣？因為在傳統演播室環境下，電視臺對直播的安全與穩定性要求很高；但對於各網際網路直播平臺，雖然應用做得都很穩定，但在極端情況下也會有直播異常甚至崩潰的情況發生，這對於電視臺而言是無法想象的直播事故。大家可以想象如果《新聞聯播》在直播時出現花屏綠屏卡頓等問題會造成多麼重大的影響。而對於陌陌來說，陌陌現場就是陌陌的《新聞聯播》，我們需要保證不會出現任何直播事故。對此我們會使用一些傳統廣電的解決方案，例如所有的直播訊號都是多路訊號，從來不會出現一路訊號異常影響整場直播的問題。那麼我們如何在如此嚴苛條件下實現這種互動直播呢？其實做法很簡單，也就是在多分路的前提下引入OBS這樣一個開源的編碼環境。我們在其中整合了OBS的互動SDK，也就是硬體編碼器推一路訊號給陌陌原站的同時OBS也推一路訊號給陌陌的原站。當然這兩路流在原站會區分優先順序，如果原站只收到編碼器推出的一路訊號，那麼把資料轉出推給CDN，使用者就可以收看到直播畫面；如果原站收到OBS推出的一路訊號，便會將來自OBS的資料流直接傳輸至記憶體裡並通過通道傳輸出去，而編碼器的流只會被掛起，當OBS出現穩定性故障時，編碼器的流便會恢復，此時使用者可能感覺畫面變成連屏、混屏。同時在OBS上也可實現最常見的PC端連麥，以上就是在演播間如何進行互動直播的全新應用。

5.直播技術未來的發展

5.1 低卡頓

為什麼說是“低卡頓”而不是說“無卡頓”？因為現有的技術還無法實現完全沒有卡頓、緩衝。這不單單取決於技術，更包括基礎設施的建設，我們只是希望把卡頓率降到最低。根據陌陌的PV統計資料，使用者每觀看15分鐘以上直播必然會出現一次卡頓，這個值是根據資料收集而並非理論計算。我們也是不斷嘗試儘可能優化，但實際上現在業內沒有徹底解決卡頓問題的有效方案。

5.2 低延遲

實現低延遲可以通過使用更好的傳輸協議，因為多媒體本身是適用於UDP協議而非TCP協議的。Google曾推出一個QUIC協議並已經存在了幾年，我們也做過一個簡單的測試：在網路良好的實驗室環境下QUIC協議的傳輸能力弱於TCP協議，實驗結果與谷歌的標稱不相符；而當網路丟包率達到5%時，QUIC協議的優勢已經開始顯現了；當網路丟包率達到30%時TCP協議傳輸基本上不可用，而QUIC協議可正常的執行。但在真正的網路環境中，這種測試的結果都是不完全正確的。那我們怎麼測呢？因為在實際網路中使用者遇到更多的是突然間卡頓，出現的大部分丟包現象是突發網路抖動，也就是突發的丟包，如果在突發10%，丟包5%的情況下會是什麼結果呢？ QUIC協議在突發為5%，丟包為10%的情況下不如TCP，但當突發變為30%，丟包變為10%的情況下就比TCP強很多了，也就是說我們無法簡單地在QUIC協議、UDP協議和TCP協議中做出選擇。TCP協議相對於UDP協議的優勢是能夠保證資料的有效到達，而UDP需要FEC等來保證資料的有效到達；QUIC雖介於兩者之間，但我們也不能將其簡單應用，而應當根據實際環境檢測結果來進行選擇。

5.3 高清晰度

高清晰度是現如今音視訊領域的發展趨勢

5.4 富效果

如何理解富效果？首先是在畫面上使用AR技術進行增強，使直播更加酷炫好玩；其次是類似於裸眼3D、全景視訊等技術的運用，大大增加直播的可玩性。相信以上這些都是直播技術未來的發展趨勢。

WebRTCon 2018 PPT 最後一波

由於需要確認的資訊較多，我們不得不分若干次放出本次大會的PPT。在大家的理解與支援下，最後一波PPT已經確認完畢，點選『閱讀原文』即可進行下載。

LiveVideoStack Meet 廣州：多媒體技術創新與應用難點探索

LiveVideoStack音視訊技術社群聯合領先的多媒體技術專家——三體雲聯推出“多媒體技術創新與應用難點探索”技術沙龍，在多人連麥、海量直播教室、高併發視訊會議、Codec與降低頻寬成本等話題展開討論，分享最新的實踐與思考，旨在幫助多媒體開發技術人提升能力，解決行業應用難點。

 講師與話題：

• 《低延遲音視訊傳輸技術在直播領域的應用》 

    陌陌 視訊流媒體技術負責人 吳濤

• 《視訊直播體驗優化》  

    YY音視訊演算法中心負責人 林緒虹

• 《實時音視訊技術賦能傳統行業》 

    三體雲聯產品副總裁 崔文秀

• 《低延遲直播互動方案探索——WebRTC與Kurento配合使用》    

    搜狐千帆直播組高階Android開發工程師 劉海濤

瞭解更多詳細資訊，請掃描圖中二維碼，快來報名參與吧！