大家都知道，音視頻雲服務降低了硬件接入音視頻的門檻，但是，在使用這一服務的過程中難免踩坑，這是音視頻雲服務提供商以及硬件團隊都格外重視的，但問題是具體有哪些坑以及如何避免呢?

冼牛，即構科技資深技術負責人，2002年北郵碩士期間開始專研視頻會議，現在即構科技深耕語音視頻雲服務，直播技術應用和直播行業研究，為您講解。

音視頻直播雲服務的硬件應用場景

實際上，音視頻直播雲服務的硬件應用場景並不少：車聯網，智能家居，遠程醫療和戶外活動等。這是正在發展的場景，還有很多潛在的場景，會在未來幾年逐漸展現。智能終端對音視頻雲直播服務的需求在不斷增加。舉個例子，目前在國外玩得比較熱的戶外直播、無人機直播，都是智能硬件的一些典型應用場景。

音視頻直播雲服務解決了什麽問題?

通俗點說，音視頻直播雲解決的最終極問題就是：讓你聽見，看見，就像在面前一樣。然而，這個簡簡單單的問題，在復雜的網絡環境，硬件平臺，操作系統，海量並發運維等等因素綜合加在一起，就變成了一個十分復雜的問題。

以即構科技為例，在做音視頻直播雲服務的過程中針對智能終端解決了以下問題：

1)延遲比較大，做不到連麥互動多人對講的效果。

2)無法全面兼容眾多安卓機型，長尾用戶群體無法全面覆蓋。

3)硬件場景聲音環境復雜，噪音抑制和回聲消除的效果不好。

4)視頻畫面卡頓不流暢，觀看效果不好。

5)如果使用基於udp的私有協議，無法被CDN網絡支持;如果使用基於RTMP的標準協議，無法獲得理想的低延遲。

6)無法支撐海量用戶並發，或者在海量並發情況下，效果不穩定。

7)多個人同時說話，甚至出現搶話(所謂雙講)的情況下，語音效果不好。

音視頻通信的原理以及技術難點是什麽?

上文提到，音視頻直播雲服務要做的事情就是讓用戶在任何一個地方任何一個時候可以聽見看見。由此可見，核心的問題就是對音視頻數據的處理和傳輸。

音視頻通信的整個流程包括：采集，編碼，推流，轉碼，存儲，拉流，解碼，渲染(播放)。每一個環節都會有很多的坑，都需要投入很多人力和時間去填平這些坑，都需要時間去試錯。因此，要做好音視頻，除了靠技術的積累還要靠多年的經驗。

采集和渲染：音視頻信息是從通話的發起端，進行語音和視頻的采集;在通話的接收端進行語音和視頻的渲染。而采集和渲染兩個環節會涉及到具體硬件的音視頻設備的性能。需要註意的是，采集和渲染都會用到具體硬件平臺的接口，這和具體硬件設備的接口、設計和性能等密不可分。因此，在系統設計階段，就要考慮硬件設備的兼容性和跨平臺。

編碼和解碼：編解碼環節會涉及到具體硬件芯片的處理能力。我們可以將其分為兩類：一類是采用硬編硬解，另一種是采用軟編軟解，二者各有各的優缺點。

硬編硬解要用到GPU的處理能力，優點是效率高，速度快，分擔CPU的壓力，減少CPU發熱;缺點就是不同的硬件平臺的芯片性能和接口參數不一樣，要進行適配。軟編軟解不使用GPU，而使用的是CPU的計算能力，優點是對各個硬件平臺的兼容性好，缺點就是計算的壓力都放在CPU上了，速度慢，效率低，而且CPU會發熱。需要註意的是，有些設備CPU和攝像頭離得比較近，CPU發熱可能會導致攝像頭采集的時候丟幀。

除了采集、渲染、編碼解碼這幾個終端環節以外，其它環節的和硬件平臺不相關，屬於後端的範疇，和目前在娛樂直播行業、在線教育行業、遊戲語音行業、大規模遊戲語音直播行業的方案都沒有差異。下面對後端的原理簡單闡述。

推流：是發起音視頻通訊的智能終端設備把音視頻流推送到音視頻服務器集(註：音視頻服務器集群是一個統稱，裏面比較復雜，包括音視頻流服務器，信令調度服務器和混流服務器等，可以簡單的理解為雲端)。推流是能否做到低延遲的關鍵。智能終端所在的環境十分的復雜，要適應這些復雜的環境，要做很多工作。例如，一般情況下上下行的網絡不對稱，上行網絡遠遠小於下行網絡，而且用戶的設備質量參錯不齊，所在區域的接入點服務質量良莠不齊。推流可以分為兩步：1)選路，選擇一條最優的路徑;然後2)推流，在該路徑上做到最優。在服務器集群上的處理包括混流(如果需要)和存儲等，然後把音視頻流轉推到CDN網絡去。

拉流：是需要觀看的用戶拉去音視頻流到終端設備觀看。拉流的用戶分為兩類，一類是普通的觀眾，一類是參與到多人互動對講中的用戶。相對來說，普通的觀眾對低延遲要求不高，只要求流暢和高質量，所以可以使用CDN網絡來均衡質量和成本。觀眾端從就近的CDN網絡進行拉流，在智能終端進行解碼和播放。使用的協議是RTMP, HLS或者HTTP-FLV協議，多種協議可以適配不同的環境。有些智能硬件場景是沒有普通觀眾的，那麽就只有參與音視頻互動對講的用戶了。對於進行互動對講的核心的參與者，音視頻流是不經過CDN網絡的。各個參與者是直接從音視頻流媒體服務器上拉流來的播放。音視頻流媒體服務器的質量相對比較好，網絡資源也比較好，能夠提供低延遲和高質量的音視頻服務。

這是一個典型的音視頻直播雲服務的系統架構，同樣可以應用到智能硬件的場景中，比如說無人機航拍直播。舉個例子，即構科技有個客戶是做房地產銷售的，他們組織幾個房地產專家進行連麥互動談話，討論樓盤的各種情況，並對實況進行直播，場外有上萬的觀眾在線觀看直播。推流端包括幾個身處各地的房地產專家還有幾個在樓盤現場航拍的無人機上的攝像頭，拉流端就是觀看直播的觀眾和各位房地產專家。從系統架構的角度來說，房地產專家的音視頻通訊是在音視頻流媒體服務器集群上完成的，沒有轉推流到CDN;而觀看直播的觀眾，就會從CDN網絡上拉流。

關於開發上的難點，已經包含在上面我們所解決的問題列表裏。這裏重復了一下：

1)延遲比較大，做不到連麥互動多人對講的效果。

2)無法全面兼容眾多安卓機型，長尾用戶群體無法全面覆蓋。

3)硬件場景聲音環境復雜，噪音抑制和回聲消除的效果不好。除了開發上的難點，還有運維上的難點：

4)對系統內部運作可見度不高，不可管控，出現緊急問題的時候很難快速定位。

5)當緊急問題出在網絡運營商，基礎雲商，或者CDN網絡那邊的時候，無法及時得到事故通知，也無法得到及時而深度的配合。

6)在一些邊遠的地理區域，網絡覆蓋不足，用戶體驗比較差或者不穩定。

7)來自不同的網絡的用戶得到的體驗不一樣，造成某些網絡的用戶體驗比較差。運維上的難點更多的偏向於經驗的積累，只有踩過足夠多的坑，只有經歷過長時間的試錯，才能夠把系統打磨得比較順溜。

怎麽獲得低延遲、而保證高音質和高畫質?

低延遲是一個比較難的技術點，這也是即構科技解決得比較好的一個問題。目前，使用即構科技的音視頻直播SDK，參與連麥互動直播各方的延遲達到400毫秒，觀眾端的延遲達到1秒左右。這個低延遲指標在市場上是十分有競爭力的。舉個例子，花椒直播(奇虎360投資的企業，日活超過500萬)采用了即構科技的直播技術方案，原因是即構科技的視頻直播SDK延遲極低，能做到移動端六路連麥互動，能讓明星主播進行“同框”互動直播。

要降低延遲也是要從采集，編碼，推流，拉流，解碼和渲染整個鏈接來解決的，可以從下面幾個點進行探索：

1)采集、視頻處理和編碼盡量減少內存多處拷貝，減少CPU和GPU處理多次切換;

2)解碼、視頻後處理和渲染也是類似的方式;

3)另外就是推拉流的鏈路上的優化，包括就近接入，和減少多層級server的轉發等。這些都要根據實際用戶策略來做。

關於高音質和高畫質怎麽保證，可以從以下幾點來探索：

1)音頻的數據量比較小，對帶寬的要求比較低，一般不會限制音頻，要優先保證音頻數據可以發送。畢竟，在極端差網的情況下，即使視頻不好，只要音頻清晰流暢，互動溝通還是可以繼續的。

2)為了獲得低延遲同時保證視頻的質量，要平衡流暢和清晰度，現在通常采用VBR或者CBR來處理。在保證畫面質量不至於太差的情況下，可以選擇性性地丟幀。這樣可以避免推流端因為TCP擁塞導致於推流質量越來越差，否則除了引起卡頓也會引起畫面質量下降嚴重。在網絡確實太差的情況下，通常為了保證視頻流暢，可以適當地降低推流碼率，這樣畫面質量會有不可避免的下降。通常的做法是設置一個極限值，避免視頻質量太低無法觀看。

怎麽優化音視頻雲服務對CPU和帶寬資源耗費?

CPU資源

使用智能硬件設備的芯片進行音視頻的編碼解碼的時候會面臨兩個選擇：硬編硬解，還是軟編軟解。要降低對CPU的消耗，就要充分的利用GPU的能力。使用GPU就要進行硬編硬解，優點是速度快，效率高，CPU的占用低，缺點對兼容性有要求，需要對具體硬件平臺進行深度兼容，才能做好硬編硬解。

帶寬資源

要解決帶寬資源消耗的問題，可以從兩個角度入手：碼率自適應，和雲端混流。

碼率自適應，就是讓音視頻流的碼率能夠自動適應復雜的網絡環境，比如說網絡抖動。我們都知道，在中國，用戶端的上下行網絡帶寬是不對稱的。比如說，下行如果是100Mbps，那麽對應的上行就是1Mbps, 這樣上行就成了瓶頸，下行反而問題不大。因此，要確保推流成功而且質量好，那麽就要利用好上行的網絡帶寬。推流端要能夠做到根據各種維度的因素，包括個體歷史數據，群體歷史數據，網絡探測數據等等，去分析和預測網絡的情況，從而決定推流應該采用多大的碼率。關鍵點就是要找出在目前上行帶寬的情況下小於上行帶寬的最大碼率。

雲端混流，就是把多路的音視頻流在服務器集群裏面混合成一路流，然後轉推到CDN去，讓觀眾拉單流來觀看。這樣可以節省一部分帶寬成本。拉流端拉流的時候有兩個選擇，一個是把所有推流端的音視頻流單獨拉下來播放，另一個就是把在雲端混合好的單一一路流拉下來播放。如果采用不混流的方案，優點是拉流端可以靈活地操控多路流，比如說讓畫中畫中的畫面靈活對調， 缺點就是多占用了網絡帶寬。如果采用混流的方案，優點就是拉流端只需要拉一路流，可以大大的節省從流媒體服務器到CDN網絡和CDN網絡到拉流端所占的網絡帶寬，缺點就是多路音視頻經過混流以後，畫面的布局就固定了，在拉流端無法再進行靈活操控了。

評價音視頻通信質量好壞的標準

評判一個音視頻雲服務質量好不好，要看技術指標，也要看非技術指標。畢竟這是技術服務，是技術也是服務。

技術上的指標包括但是不限於：1)低延遲;2)流暢性;3)回聲消除;4)噪音抑制;5)跨平臺;6)全終端兼容;7)海量用戶並發;8)無感知擴容能力。

低延遲：這個很重要，但是到了一定臨界值以後，就不是最重要的指標了。一般來說低於800毫秒的延遲，就能夠做到多人實時連麥互動，做到比較好的對講，比較好的高頻互動;高於800毫秒的延遲，就只能做監控，只能做單向直播了，這樣的效果和點播的差別不是很大，是做不到連麥互動或者多人實時對講的。

流暢性：這個影響用戶體驗的關鍵指標。但低延遲和流暢性實際上是矛盾的，要獲得最低的延遲，最好就是讓緩沖隊列盡量地短;但是要做到流暢，緩沖隊列就要有一定的長度，才能夠抹平網絡抖動帶來的影響。所以，我們要在低延遲和流暢性這對矛盾的指標上找到一個平衡點。

回聲消除和噪音抑制能力：這兩項最能考驗音視頻技術能力的水平，這也是一流的音視頻直播雲服務區分其它競品的利器。在選擇方案的時候，要看能否做到沒有回聲，沒有嘯叫(不帶耳機的哦)。還要看能否有效抑制環境噪音，聲音清晰而且通透。有創業團隊找到我說，他們團隊的技術很厲害，自己花了大半年就把音視頻通訊系統做出來的，就是這兩項怎麽做都效果不理想。其實音頻比視頻要難，音頻裏面這兩個點是最難的，不是那麽容易做得好的。

為了支持創業企業快速發展，音視頻直播雲服務要能夠做到以下三點：

1) 在創業早期，要能夠以較低成本，較快的速度，讓早期的產品集成音視頻直播SDK。因為早期團隊缺乏資金，但是又要求快。因此音視頻直播SDK必須是簡單易用的，而且是端對端集成的。

2) 在創業中期，要能夠快速而且無感知的擴容，不能影響到生產環境，不能對用戶體驗造成損害。因此，音視頻直播雲服務必須要能夠做到無感知地水平擴容，在雲端通過配置增加網絡，基礎雲和CDN等資源。

3)在創業後期，要能夠支持海量用戶並發，確保服務持續而且穩定。因此音視頻雲服務的架構要能夠支持千萬級別的海量用戶並發，技術團隊要有多年海量運營的經驗，和運營商的基建要能夠深度的結合才行。關於未來

請允許我鬥膽判斷一下未來，未來音視頻直播雲服務可能有兩個趨勢：

1)公共事業服務化：未來會更加趨向於接受由專業的人做專業的事情，音視頻直播雲服務會成為像自來水一樣廣泛而且中立的公共事業服務，就像今天的基礎雲服務一樣，誰都可以很便利很放心地使用，沒有人擔心安全性，也沒有必要重復發明輪子。

2)成為互聯網主流互動方式： 音視頻的流量占網絡流量的比例越來越大，VR/AR音視頻的信息量還會有數倍的提升，可以預測音視頻通訊成為網絡流量的主要貢獻者。從用戶的角度來說，要能聽見看見，音視頻互動是最直觀最自然的互動方式。從商業的角度來說，網絡運營商，基礎雲商還有CDN網絡，都會特別喜歡這個趨勢，畢竟音視頻的流量比文本的流量大的多，流量多起來了，就意味著更大規模的基建，更大規模的收入流水。因此，網絡運營商、基礎雲商、CDN網絡和音視頻直播雲服務商都會把音視頻技術作為標配能力。畢竟，控制主要流量的來源，就控制了未來發展的命脈。

當我們在展望未來，未來已經變成了現在。要能聽見看見，這個自然而簡單的需求，會讓音視頻直播雲服務在未來跟隨著智能終端深入到互聯網生活的每一個環節中去，深刻地改變人們互動溝通的方式。

什麽是音視頻直播雲服務 ？ 一文讀懂