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