<mark id="oztn4"></mark>
1
說到音視頻云服務，大多數人可能聯想到的是網絡直播應用場景，實際上，硬件對音視頻云服務的需求也在逐漸提升。而這樣的市場需求也推動了整個行業的發展，目前，阿里云、騰訊云和網易云等巨頭都已入局，除此之外還有即構科技這樣的新興企業加入了這一競爭行列。毫無疑問，音視頻云服務將會是云服務市場的下一個熱點。
大家都知道，音視頻云服務降低了硬件接入音視頻的門檻，但是，在使用這一服務的過程中難免踩坑，這是音視頻云服務提供商以及硬件團隊都格外重視的，但問題是具體有哪些坑以及如何避免呢？本期硬創公開課將為您一一解答。
冼牛，即構科技市場運營總監，資深技術人，市場營銷新兵，客串投資顧問，骨灰級游泳者。北京郵電大學計算機碩士，香港大學工商管理碩士，一直秉承人丑應該多讀書的理念，讀書不斷。2008年起旅居香港至今，2015年回流深圳南山創業，服務過愛立信香港，摩根大通香港，和分期樂集團等老東家。
2002年北郵碩士期間開始專研視頻會議，現深耕語音視頻云服務，直播技術應用和直播行業研究。
以下內容整理自本期公開課：
實際上，音視頻直播云服務的硬件應用場景并不少：車聯網，智能家居，遠程醫療和戶外活動等。這是正在發展的場景，還有很多潛在的場景，會在未來幾年逐漸展現。智能終端對音視頻云直播服務的需求在不斷增加。舉個栗子，目前在國外玩得比較熱的戶外直播、無人機直播，都是智能硬件的一些典型應用場景。
通俗點說，音視頻直播云解決的最終極問題就是：讓你聽見，看見，就像在面前一樣。然而，這個簡簡單單的問題，在復雜的網絡環境，硬件平臺，操作系統，海量并發運維等等因素綜合加在一起，就變成了一個十分復雜的問題。
以即構科技為例，在做音視頻直播云服務的過程中針對智能終端解決了以下問題：
1）延遲比較大，做不到連麥互動多人對講的效果。
2）無法全面兼容眾多安卓機型，長尾用戶群體無法全面覆蓋。
3）硬件場景聲音環境復雜，噪音抑制和回聲消除的效果不好。
4）視頻畫面卡頓不流暢，觀看效果不好。
5）如果使用基于udp的私有協議，無法被CDN網絡支持；如果使用基于RTMP的標準協議，無法獲得理想的低延遲。
6）無法支撐海量用戶并發，或者在海量并發情況下，效果不穩定。
7）多個人同時說話，甚至出現搶話（所謂雙講）的情況下，語音效果不好。
8）對系統內部運作可見度不高，不可管控，出現緊急問題的時候很難快速定位。
上文提到，音視頻直播云服務要做的事情就是讓用戶在任何一個地方任何一個時候可以聽見看見。由此可見，核心的問題就是對音視頻數據的處理和傳輸。
音視頻通信的整個流程包括：采集，編碼，推流，轉碼，存儲，拉流，解碼，渲染（播放）。每一個環節都會有很多的坑，都需要投入很多人力和時間去填平這些坑，都需要時間去試錯。因此，要做好音視頻，除了靠技術的積累還要靠多年的經驗。
采集和渲染：音視頻信息是從通話的發起端，進行語音和視頻的采集；在通話的接收端進行語音和視頻的渲染。而采集和渲染兩個環節會涉及到具體硬件的音視頻設備的性能。需要注意的是，采集和渲染都會用到具體硬件平臺的接口，這和具體硬件設備的接口、設計和性能等密不可分。因此，在系統設計階段，就要考慮硬件設備的兼容性和跨平臺。
編碼和解碼：編解碼環節會涉及到具體硬件芯片的處理能力。我們可以將其分為兩類：一類是采用硬編硬解，另一種是采用軟編軟解，二者各有各的優缺點。
硬編硬解要用到GPU的處理能力，優點是效率高，速度快，分擔CPU的壓力，減少CPU發熱；缺點就是不同的硬件平臺的芯片性能和接口參數不一樣，要進行適配。軟編軟解不使用GPU，而使用的是CPU的計算能力，優點是對各個硬件平臺的兼容性好，缺點就是計算的壓力都放在CPU上了，速度慢，效率低，而且CPU會發熱。需要注意的是，有些設備CPU和攝像頭離得比較近，CPU發熱可能會導致攝像頭采集的時候丟幀。
除了采集、渲染、編碼解碼這幾個終端環節以外，其它環節的和硬件平臺不相關，屬于后端的范疇，和目前在娛樂直播行業、在線教育行業、游戲語音行業、大規模游戲語音直播行業的方案都沒有差異。下面對后端的原理簡單闡述。
推流是發起音視頻通訊的智能終端設備把音視頻流推送到音視頻服務器集（注：音視頻服務器集群是一個統稱，里面比較復雜，包括音視頻流服務器，信令調度服務器和混流服務器等，可以簡單的理解為云端）。推流是能否做到低延遲的關鍵。智能終端所在的環境十分的復雜，要適應這些復雜的環境，要做很多工作。例如，一般情況下上下行的網絡不對稱，上行網絡遠遠小于下行網絡，而且用戶的設備質量參錯不齊，所在區域的接入點服務質量良莠不齊。推流可以分為兩步：1）選路，選擇一條最優的路徑；然后2）推流，在該路徑上做到最優。在服務器集群上的處理包括混流（如果需要）和存儲等，然后把音視頻流轉推到CDN網絡去。
拉流的用戶分為兩類，一類是普通的觀眾，一類是參與到多人互動對講中的用戶。相對來說，普通的觀眾對低延遲要求不高，只要求流暢和高質量，所以可以使用CDN網絡來均衡質量和成本。觀眾端從就近的CDN網絡進行拉流，在智能終端進行解碼和播放。使用的協議是RTMP, HLS或者HTTP-FLV協議，多種協議可以適配不同的環境。有些智能硬件場景是沒有普通觀眾的，那么就只有參與音視頻互動對講的用戶了。對于進行互動對講的核心的參與者，音視頻流是不經過CDN網絡的。各個參與者是直接從音視頻流媒體服務器上拉流來的播放。音視頻流媒體服務器的質量相對比較好，網絡資源也比較好，能夠提供低延遲和高質量的音視頻服務。
這是一個典型的音視頻直播云服務的系統架構，同樣可以應用到智能硬件的場景中。比如說無人機航拍直播。舉個例子，即構科技有個客戶是做房地產銷售的，他們組織幾個房地產專家進行連麥互動談話，討論樓盤的各種情況，并對實況進行直播，場外有上萬的觀眾在線觀看直播。推流端包括幾個身處各地的房地產專家還有幾個在樓盤現場航拍的無人機上的攝像頭，拉流端就是觀看直播的觀眾和各位房地產專家。從系統架構的角度來說，房地產專家的音視頻通訊是在音視頻流媒體服務器集群上完成的，沒有轉推流到CDN；而觀看直播的觀眾，就會從CDN網絡上拉流。
關于開發上的難點，已經包含在上面我們所解決的問題列表里。這里重復了一下：
1）延遲比較大，做不到連麥互動多人對講的效果。
2）無法全面兼容眾多安卓機型，長尾用戶群體無法全面覆蓋。
3）硬件場景聲音環境復雜，噪音抑制和回聲消除的效果不好。
除了開發上的難點，還有運維上的難點：
1） 對系統內部運作可見度不高，不可管控，出現緊急問題的時候很難快速定位。
2）當緊急問題出在網絡運營商，基礎云商，或者CDN網絡那邊的時候，無法及時得到事故通知，也無法得到及時而深度的配合。
3）在一些邊遠的地理區域，網絡覆蓋不足，用戶體驗比較差或者不穩定。
4）來自不同的網絡的用戶得到的體驗不一樣，造成某些網絡的用戶體驗比較差。
運維上的難點更多的偏向于經驗的積累，只有踩過足夠多的坑，只有經歷過長時間的試錯，才能夠把系統打磨得比較順溜。
低延遲是一個比較難的技術點，這也是即構科技解決得比較好的一個問題。目前，使用即構科技的音視頻直播SDK，參與連麥互動直播各方的延遲達到400毫秒，觀眾端的延遲達到1秒左右。這個低延遲指標在市場上是十分有競爭力的。舉個例子，花椒直播（奇虎360投資的企業，日活超過500萬）采用了即構科技的直播技術方案，原因是即構科技的視頻直播SDK延遲極低，能做到移動端六路連麥互動，能讓明星主播進行“同框”互動直播。
要降低延遲也是要從采集，編碼，推流，拉流，解碼和渲染整個鏈接來解決的，可以從下面幾個點進行探索：
采集、視頻處理和編碼盡量減少內存多處拷貝，減少CPU和GPU處理多次切換；
解碼、視頻后處理和渲染也是類似的方式；
另外就是推拉流的鏈路上的優化，包括就近接入，和減少多層級server的轉發等。這些都要根據實際用戶策略來做。
關于高音質和高畫質怎么保證，可以從以下幾點來探索：
1） 音頻的數據量比較小，對帶寬的要求比較低，一般不會限制音頻，要優先保證音頻數據可以發送。畢竟，在極端差網的情況下，即使視頻不好，只要音頻清晰流暢，互動溝通還是可以繼續的。
2） 為了獲得低延遲同時保證視頻的質量，要平衡流暢和清晰度，現在通常采用VBR或者CBR來處理。在保證畫面質量不至于太差的情況下，可以選擇性性地丟幀。這樣可以避免推流端因為TCP擁塞導致于推流質量越來越差，否則除了引起卡頓也會引起畫面質量下降嚴重。在網絡確實太差的情況下，通常為了保證視頻流暢，可以適當地降低推流碼率，這樣畫面質量會有不可避免的下降。通常的做法是設置一個極限值，避免視頻質量太低無法觀看。
使用智能硬件設備的芯片進行音視頻的編碼解碼的時候會面臨兩個選擇：硬編硬解，還是軟編軟解。要降低對CPU的消耗，就要充分的利用GPU的能力。使用GPU就要進行硬編硬解，優點是速度快，效率高，CPU的占用低，缺點對兼容性有要求，需要對具體硬件平臺進行深度兼容，才能做好硬編硬解。
要解決帶寬資源消耗的問題，可以從兩個角度入手：碼率自適應，和云端混流。
碼率自適應，就是讓音視頻流的碼率能夠自動適應復雜的網絡環境，比如說網絡抖動。我們都知道，在中國，用戶端的上下行網絡帶寬是不對稱的。比如說，下行如果是100Mbps，那么對應的上行就是1Mbps, 這樣上行就成了瓶頸，下行反而問題不大。因此，要確保推流成功而且質量好，那么就要利用好上行的網絡帶寬。推流端要能夠做到根據各種維度的因素，包括個體歷史數據，群體歷史數據，網絡探測數據等等，去分析和預測網絡的情況，從而決定推流應該采用多大的碼率。關鍵點就是要找出在目前上行帶寬的情況下小于上行帶寬的最大碼率。
云端混流，就是把多路的音視頻流在服務器集群里面混合成一路流，然后轉推到CDN去，讓觀眾拉單流來觀看。這樣可以節省一部分帶寬成本。拉流端拉流的時候有兩個選擇，一個是把所有推流端的音視頻流單獨拉下來播放，另一個就是把在云端混合好的單一一路流拉下來播放。如果采用不混流的方案，優點是拉流端可以靈活地操控多路流，比如說讓畫中畫中的畫面靈活對調， 缺點就是多占用了網絡帶寬。如果采用混流的方案，優點就是拉流端只需要拉一路流，可以大大的節省從流媒體服務器到CDN網絡和CDN網絡到拉流端所占的網絡帶寬，缺點就是多路音視頻經過混流以后，畫面的布局就固定了，在拉流端無法再進行靈活操控了。
目前智能終端主流的操作系統包括iOS和安卓。iOS是蘋果的智能終端操作系統，蘋果的機型數目有限，而且設計和質量都比較好，要適配蘋果的設備和iOS問題不大。比較難的是如何適配安卓操作系統。安卓是谷歌的開源智能終端操作系統，正因為是開源的，所以各個廠商可以做各種大尺度的裁剪和修改。特別是在中國國內市場，安卓機型十分繁多，而且架構設計，硬件質量良莠不齊；安卓操作系統也做了很多的裁剪和修改。我這里舉的安卓智能手機的例子，其實也適用于采用了安卓操作系統的其它智能終端，比如說無人機或者智能電視。因此，我們說要全面兼容各種智能終端，其實說的就是如何全面兼容安卓操作系統和各種各樣的智能終端硬件平臺。
眾所周知，安卓是開源的操作系統，底層提供c接口，上層提供java接口。國內的廠商在對安卓系統進行裁剪和修改的時候，為了提高效率和降低成本，大部分都是直接調用java接口進行修改的。
在即構科技創業初期，我們也考慮過調用java接口進行優化，來開發音視頻引擎和其它各種適配工作，后來發現行不通。這條路雖然看起來節省成本而且提高效率，但是損失的是兼容性和穩定性。一套代碼無法在各種各樣的安卓平臺上穩定運行，反而是提高了成本和降低了效率。于是我們采用比較笨，也是最基礎的方法，從最底層做起，盡量地調用c接口，去做深層優化，去實現音視頻終端引擎。這個過程雖然十分痛苦十分的累，但是最終一套代碼可以在各種各樣的平臺上使用，終端音視頻引擎的穩定性和兼容性也是真心的好，因此我們認為十分值得。所以，在兼容全終端、做到跨平臺這一點上面，建議大家用比較笨的基礎的方法，從最底層進行優化，這樣才能保證兼容性和穩定性。
由于即構科技的音視頻SDK是進行端對端集成的，而后端是完全解耦的，所以只要智能終端實現了全面的兼容性，后端就完全沒有兼容性問題了。現在，即構科技的音視頻直播方案，能夠跨越iOS、安卓、WP和H5四個平臺，能夠兼容PC、各種手機和PAD三種終端類型，用的就是直接從底層深度優化這個笨辦法。
另外一點也值得提一下，在拉流端，為了兼容和適配觀眾端各種各樣的平臺，我們提供了多種協議進行拉流：RTMP, HLS, HTTP-FLV。用RTMP或者HTTP-FLV拉流可以用即構的SDK（APP）或者Adobe Flash Player上觀看，用HLS拉流可以在H5上觀看。這樣可以確保全面覆蓋各種各樣的終端用戶。
評判一個音視頻云服務質量好不好，要看技術指標，也要看非技術指標。畢竟這是技術服務，是技術也是服務。
技術上的指標包括但是不限于：1）低延遲；2）流暢性；3）回聲消除；4）噪音抑制；5）跨平臺；6）全終端兼容；7）海量用戶并發；8）無感知擴容能力。
低延遲，這個很重要，但是到了一定臨界值以后，就不是最重要的指標了。一般來說低于800毫秒的延遲，就能夠做到多人實時連麥互動，做到比較好的對講，比較好的高頻互動；高于800毫秒的延遲，就只能做監控，只能做單向直播了，這樣的效果和點播的差別不是很大，是做不到連麥互動或者多人實時對講的。
流暢性，這個影響用戶體驗的關鍵指標。但低延遲和流暢性實際上是矛盾的，要獲得最低的延遲，最好就是讓緩沖隊列盡量地短；但是要做到流暢，緩沖隊列就要有一定的長度，才能夠抹平網絡抖動帶來的影響。所以，我們要在低延遲和流暢性這對矛盾的指標上找到一個平衡點。
回聲消除和噪音抑制能力，這兩項最能考驗音視頻技術能力的水平，這也是一流的音視頻直播云服務區分其它競品的利器。在選擇方案的時候，要看能否做到沒有回聲，沒有嘯叫（不帶耳機的哦）。還要看能否有效抑制環境噪音，聲音清晰而且通透。有創業團隊找到我說，他們團隊的技術很厲害，自己花了大半年就把音視頻通訊系統做出來的，就是這兩項怎么做都效果不理想。其實音頻比視頻要難，音頻里面這兩個點是最難的，不是那么容易做得好的。
跨平臺和終端兼容性，上文有介紹，就不再贅述了。
海量用戶并發，這個十分考驗海量并發運維能力。C端的業務，靠的是海量的用戶取勝。音視頻技術很多團隊自己就能做出來，demo跑的時候挺好，一對一效果不錯，但是用戶量一上來就開始不穩定，就要不斷地進行重構和迭代，就要不斷地經歷服務中斷。
無感知擴容能力，這對創業團隊來說很重要。創業團隊處于業務的快速擴展期，往往幾個月用戶就要成倍增長。為了擴容可能要進行版本迭代升級，甚至重構，這樣很可能會終端服務，極其影響用戶體驗。能否做到無感知擴容十分考驗一個音視頻云服務商的運營經驗和網絡資源。這里就不僅僅是技術了，更多的是要考驗是能和網絡運營商，技術云商，CDN網絡合作深度。這些運營經驗都要靠不斷試錯，靠多年運營積累總結出來的。
看完上述技術指標后，讓我們看看非技術指標：
技術服務的深度，要看知道技術支持的是核心技術團隊還是普通客服團隊。如果核心技術團隊能夠主導SDK集成接入和后期的運維支持，他們能夠幫你解決深度的技術問題，幫你提供經驗和建議。如果只是客服團隊經過簡單培訓上崗，對著FAQ文檔回答你的問題，那樣的服務是遠遠不夠的。
運維支持的能力和反應速度，這方面要看一手硬的和一手軟的。所謂硬的，就是看有沒有健全而強大的后臺監控系統，能否全面的看到每一路流，每個節點的各項技術指標，實時監控狀態，一出問題就可以快速定位。所謂軟的，就是要看這個音視頻云服務團隊的市場口碑和自我定位，看它是不是能夠對大小客戶都一視同仁，能夠積極快速反應，積極處理問題，能夠踏實地提供服務。
和網絡運營商以及基礎云商合作的深度，這要看和基礎云商，CDN網絡的關系，能否讓對方配合做一些深度的適配，能否及時地得到事故通知，能否讓對方幫忙解決問題等。
這是都是企業在接入音視頻云服務的時候該十分注意的問題。畢竟，選擇一個云服務可能因為它技術指標好，拋棄一個云服務往往可能因為它非技術指標不好。
實際上，這是很多創業企業的痛點。這些創業型的團隊直接面對C端的用戶。剛剛啟動的時候，用戶很少，可能只有幾百個； 但是后面幾個月可能會成倍的增長，達到數十萬甚至上百萬個用戶。面向C端的用戶系統在擴容來跟上用戶量增長的過程中，可能會出現擴容周期過長，系統不穩定，甚至服務中斷等問題。
即構科技從兩個方面來解決這個問題：
1）服務端架構能夠進行靈活水平擴容。在信令層面，在架構設計的時候，我們就按照用戶的預期增長，做好了相應的設計，允許水平擴展。在保證多媒體服務器集群業務側無狀態的前提下，結合我們的智能調度系統，保證調度給用戶的資源是足夠的。這個架構支持我們能夠根據客戶的容量需求，水平的把網絡資源十分靈活地鋪開，能夠做到讓C端的用戶感覺不到任何中斷 。
2）有豐富網絡節點資源來做到無感知的擴容。網絡節點資源的支持也十分的重要，即構科技和一線的網絡運營商進行深度對接，儲備足夠的網絡節點資源來滿足創業企業客戶群不斷擴容的需求。
智能終端的創業公司也是面對C端用戶，用戶量發展特別快，靠速度取勝。 C端用戶并發的用戶數到穩定階段會十分龐大。舉個例子，智能終端應用于汽車，也就是所謂的車聯網，具體的應用是音頻直播，也就是現在廣播電臺的替代產品。這一類的產品，最后能存活下來并且發展壯大的靠的是速度和用戶規模。
因此，為了支持創業企業快速發展，音視頻直播云服務要能夠做到以下三點：
1) 在創業早期，要能夠以較低成本，較快的速度，讓早期的產品集成音視頻直播SDK。因為早期團隊缺乏資金，但是又要求快。因此音視頻直播SDK必須是簡單易用的，而且是端對端集成的。
2) 在創業中期，要能夠快速而且無感知的擴容，不能影響到生產環境，不能對用戶體驗造成損害。因此，音視頻直播云服務必須要能夠做到無感知地水平擴容，在云端通過配置增加網絡，基礎云和CDN等資源。
3）在創業后期，要能夠支持海量用戶并發，確保服務持續而且穩定。因此音視頻云服務的架構要能夠支持千萬級別的海量用戶并發，技術團隊要有多年海量運營的經驗，和運營商的基建要能夠深度的結合才行。
請允許我斗膽判斷一下未來，未來音視頻直播云服務可能有兩個趨勢：
1）公共事業服務化：未來會更加趨向于接受由專業的人做專業的事情，音視頻直播云服務會成為像自來水一樣廣泛而且中立的公共事業服務，就像今天的基礎云服務一樣，誰都可以很便利很放心地使用，沒有人擔心安全性，也沒有必要重復發明輪子。
2）成為互聯網主流互動方式： 音視頻的流量占網絡流量的比例越來越大，VR/AR音視頻的信息量還會有數倍的提升，可以預測音視頻通訊成為網絡流量的主要貢獻者。從用戶的角度來說，要能聽見看見，音視頻互動是最直觀最自然的互動方式。從商業的角度來說，網絡運營商，基礎云商還有CDN網絡，都會特別喜歡這個趨勢，畢竟音視頻的流量比文本的流量大的多，流量多起來了，就意味著更大規模的基建，更大規模的收入流水。因此，網絡運營商、基礎云商、CDN網絡和音視頻直播云服務商都會把音視頻技術作為標配能力。畢竟，控制主要流量的來源，就控制了未來發展的命脈。
當我們在展望未來，未來已經變成了現在。要能聽見看見，這個自然而簡單的需求，會讓音視頻直播云服務在未來跟隨著智能終端深入到互聯網生活的每一個環節中去，深刻地改變人們互動溝通的方式。
雷峰網原創文章，未經授權禁止轉載。詳情見轉載須知。
專題
