編者按：8月5日上午，LiveVideoStackCon 2022 音視頻技術(shù)大會上海站邀請到了火山引擎RTC負責(zé)人宋慎義老師，為我們從實時性、沉浸式、跨地區(qū)和開發(fā)者等四個方向，來看從抖音到火山引擎，流媒體技術(shù)演進過程和機會。在宋慎義老師的演講中，我們看到了火山引擎一路走來的歷程，也了解到通過結(jié)合不同的場景，火山引擎對外來探索的堅持。
文/宋慎義
整理/LiveVideoStack
LiveVideoStack是2017年開始創(chuàng)辦的，我也恰好在那一年加入字節(jié)跳動，與字節(jié)跳動一同高速成長，從抖音到飛書，再到現(xiàn)在把這些成熟能力通過火山引擎對外輸出，為更多的開發(fā)者與企業(yè)客戶提供服務(wù)。
首先介紹一下過去幾年，在流媒體技術(shù)上，我們遇到了哪些場景，解決了哪些難題以及從長遠來看，未來幾年我們需要持續(xù)關(guān)注的未來的方向和機會。
字節(jié)跳動大約是在2016年開始做流媒體相關(guān)的技術(shù)，之前只有點播。一開始我們是做單向的直播，后來有了實時互動。2020年年初疫情爆發(fā)，更復(fù)雜的互動模式開始產(chǎn)生。我們在2020年推出了火山引擎，整個公司包括云基礎(chǔ)、視頻云以及大數(shù)據(jù)都開始向火山引擎上遷移。從那之后，字節(jié)跳動的技術(shù)能力開始慢慢成為火山引擎上的一些服務(wù)對外輸出。之后，我們又利用火山引擎支撐游戲、沉浸式音視頻等多種應(yīng)用，火山引擎也幫助這些應(yīng)用獲得更好實現(xiàn)增長。
我們在做直播連麥業(yè)務(wù)的時候，遇到第一個問題是：如何在高清、實時和流暢這三個維度上做好平衡。想完全兼顧這三個維度是不可能的，雖然不能完全100%的實現(xiàn)高清、流暢和實時，但是可以90%實現(xiàn)，隨著技術(shù)的演進，90%可以提升到99%，甚至更高。我們更多技術(shù)的發(fā)展也在不斷地提高我們在高清、流暢和實時上的能力，不斷提升用戶體驗。
疫情爆發(fā)以后，在線教育和視頻會議也大爆發(fā)，誕生了很多非常復(fù)雜、有挑戰(zhàn)的新場景，比如大班小組課、網(wǎng)絡(luò)研討會以及游戲的對戰(zhàn)語音等，它需要一些新的突破，同時要解決全球化、多地區(qū)的問題，還要解決人和設(shè)備的問題。現(xiàn)在，除了人會加入互動，設(shè)備也會加入互動，所以通過架構(gòu)的優(yōu)化，我們提出多中心的分布式的信令的架構(gòu)，能夠支撐超大規(guī)模的互動。
近兩年，沉浸式音視頻忽然火爆起來，迎來音視頻技術(shù)的新增長曲線，產(chǎn)生新的潮流，包括VR的視頻、直播互動以及超低延時的直播和云端的渲染等，給技術(shù)方案提出了新的挑戰(zhàn)。
今天，我從四個維度給大家介紹一下，我們在流媒體技術(shù)演進上重點關(guān)注的幾個方向。第一個是實時性。實時性是流媒體技術(shù)發(fā)展最大的限制條件，如果沒有實時性的限制，音視頻技術(shù)復(fù)雜度至少能降低一半；第二個是沉浸式，這是現(xiàn)在需求比較大的一個演進的方向，近幾年的技術(shù)進步也要開始沉浸式地、慢慢地走入千家萬戶，走入每個人的生活；第三個是全球化，目前是中國流量紅利見頂?shù)囊粋€階段，在這個前提下，不得不面臨的一個問題是，我們既想繼續(xù)發(fā)展技術(shù)，又想獲得更多的用戶，獲得更多的增長，那就必須去面對全球化的問題；最后我講一下我們在開發(fā)者生態(tài)上的思考，廣義上的開發(fā)者不僅僅是開發(fā)者，還包括內(nèi)容創(chuàng)作者。我們看看，通過技術(shù)進步能夠提供給開發(fā)者，怎樣的工具，怎樣的服務(wù)。
1、實時性
提到實時互動，我發(fā)現(xiàn)同行們在信道傳輸上的討論比較多，但怎樣把信源跟信道結(jié)合起來，一起去做優(yōu)化，是實時互動的一個關(guān)鍵的技術(shù)點。
實時性的核心理念就是信源分級與信道分級，用有限的信道去傳輸最重要的信息。展開來講，我們可以把信源或者說要傳輸?shù)男畔ⅲ凑諏崟r性和可靠性這兩個維度進行拆分。有些信息非常重要，它對實時性和可靠性的要求非常高，比如說信令消息；有些信息它對實時性要求高，對可靠性的要求也許能低一些，例如音頻；對于視頻而言，可靠性要求就更低了；同時也有一些信息，它對可靠性要求很高，對實時性要求沒有那么高，比如說文件的傳輸、直播等；也有一些信息對可靠性和實時性要求都不高，比如說日志。那么信源可以分級，信道其實也是可以分級的。信道看起來是一個單一的信道，但是畢竟這么多的信源是要在統(tǒng)一的一個信道里去傳輸?shù)模晕覀円研诺绖澐殖珊芏鄠€不同的能力，要把一些重要的信道、傳輸方式、傳輸容量預(yù)留出來，給信源來使用。調(diào)節(jié)的方法就是通過調(diào)優(yōu)先級、FEC或者是調(diào)重傳來實現(xiàn)這個信道的劃分和信道的隔離。
前面的偏理論，現(xiàn)在講一下如何落地。首先是信源分級的落地。實際場景中，音頻跟視頻這些信源會按照重要性繼續(xù)進行拆分。常見的是低頻的信號或低清的信號肯定更重要一些，高清的信號關(guān)鍵時刻是可以舍棄的。在視頻的信源分級上相對是比較成熟的，我們常見的有Simulcast這樣的技術(shù)，包括在直播上經(jīng)常使用的HLS、CMAF,本質(zhì)上都是做視頻的信源分級。不同清晰度之間也可以互相參考，比如SVC的技術(shù)，它有時域跟空域上的機制的劃分以及長期參考幀的技術(shù)，可以讓我們在一定程度上降低一些帶寬。高清的部分實在傳不過去也沒關(guān)系，現(xiàn)在也有很多超分辨率重建的技術(shù)，短時間內(nèi)頂一下還是可以的。
我們在音頻上的關(guān)注更多一些，因為在真正信道變化的時候，音頻產(chǎn)生的問題對感官的影響更大。這里介紹一下我們使用的一個性價比比較高的技術(shù)是MDC多描述編碼。簡單來講，就是可以把一個音頻的序列拆成多個子序列，讓它們「1、2、3，1、2、3」地報數(shù)，所有報1的站一隊，所有報2的站一隊，所有報3的站一隊。這樣的好處就是這三段編碼、三段序列可以分開地去編碼、傳輸，只要有任何一個序列能夠到達對面，相當(dāng)于音頻的低頻部分、低頻信號就可以到達對面了。到達對面的分片越多，音頻的清晰度就會越高。如果只到達一兩個，它的清晰度會有一些影響，但是基本不會影響溝通，這是一種性價比比較高的方式，它是一種原生的抗丟包的Codec。再把這種技術(shù)和FEC、AI-Codec結(jié)合起來，基本就可以實現(xiàn)：只要網(wǎng)是通的，只要有一點數(shù)據(jù)能夠傳到對面去，就能達到比較流暢的效果。實在傳不過去，還有一?.NETEQ、PLC的方式可以作補充。
經(jīng)常有人問我，什么傳輸協(xié)議最好？
其實傳輸協(xié)議沒有好與不好之分，只有合適與不合適的區(qū)別。
什么樣的傳輸協(xié)議是合適的？
主要看應(yīng)用場景、現(xiàn)實條件里有沒有實時性的要求。如果沒有實時性的要求，那一個能夠有效利用信道與帶寬的傳輸協(xié)議，就是最合適的。比如沒有實時性要求，那TCP就是一個非常優(yōu)秀的傳輸協(xié)議。如果有實時性要求，在傳輸協(xié)議的設(shè)計上就必須要實現(xiàn)三個目的：首先要能夠調(diào)節(jié)重傳實現(xiàn)可靠；有了一定可靠性之后，還要通過調(diào)節(jié)FEC讓它實現(xiàn)一定的實時性；高優(yōu)先級保證重要數(shù)據(jù)，丟棄/暫緩不重要數(shù)據(jù)。
一個很重要的傳輸協(xié)議的設(shè)計功能就是優(yōu)先級。一個優(yōu)秀的傳輸協(xié)議，實時傳輸協(xié)議一定要具備優(yōu)先級的區(qū)別，這樣能保證重要的數(shù)據(jù)優(yōu)先傳過去，不重要的數(shù)據(jù)就果斷放棄。比如，一些非常重要的數(shù)據(jù)對實時性和可靠性的要求非常高，那就可以加很高倍的冗余，并且用很快速的重傳方法，然后能高優(yōu)先級地傳輸。雖然這樣子的數(shù)據(jù)可能帶寬浪費比較嚴重，沒有辦法傳大量高碼率的數(shù)據(jù)，但這樣的數(shù)據(jù)用這樣的傳輸協(xié)議就能實現(xiàn)很好的可靠性與實時性。對可靠性要求不是很高的數(shù)據(jù)，就可以進行低倍冗余，也可以進行有限重傳，比如只重傳關(guān)鍵幀，對于非關(guān)鍵幀不重傳，這種情況下就可以實現(xiàn)信道的分級。這幾個能力可以組合起來使用，但也可以是相對的，對于一些長肥網(wǎng)絡(luò)可能最理智的方式就是關(guān)掉所有重傳，讓FEC去起作用。
信道分級以后一個重要的工作就是如何對信道進行建模。信道建模簡單來講就是要準(zhǔn)確的表述網(wǎng)絡(luò)狀態(tài)。以前，信道建模的方式比較簡單，都是用單一的變量，比如用丟包、帶寬來描述一個信道，后來大家發(fā)現(xiàn)這些還是有一定的缺陷的，于是就有了相對組合的一些模型，比如延時帶寬積。現(xiàn)在，隨著算力的增加，信道建模的復(fù)雜度也相對越來越高，有的模型會有很多變量加進來參考。但是信道建模去描述網(wǎng)絡(luò)狀態(tài)是一方面，一個更重要的方式是，如何快速地感知網(wǎng)絡(luò)的變化。有的模型其實是用統(tǒng)計類的指標(biāo)，再加上濾波的方法來實現(xiàn)網(wǎng)絡(luò)變化的感知。它可能會比較準(zhǔn)，但是有一個很大的問題，它沒有辦法實現(xiàn)快速。有時候，我們的網(wǎng)絡(luò)環(huán)境已經(jīng)變了，但幾秒鐘之后它才感知出來。這樣的話，對實時性的要求就會比較高，所以在實踐中除了統(tǒng)計類的指標(biāo)，比如丟包率、帶寬這種需要好幾秒才能統(tǒng)計出來指標(biāo)，我們往往會加入一些瞬時指標(biāo)去做修正，比如亂序、延時這些指標(biāo)，就能夠很快地去檢測出來。
那么能夠描述網(wǎng)絡(luò)狀態(tài)，感知網(wǎng)絡(luò)的變化之后，剩下的就是如何快速地兼容弱網(wǎng)。大家很喜歡用這個弱網(wǎng)對抗這個詞，但我不是很喜歡用弱網(wǎng)對抗，因為很多時候弱網(wǎng)是沒有辦法對抗的，只能去兼容。有些時候，動態(tài)變化是網(wǎng)絡(luò)自身固有條件的、固有屬性的動態(tài)變化。有些時候，是因為我們的信息傳輸發(fā)生了擁塞，那么這種時候需要改變的是信源自己。我們前面講到信源分級，信源分級以后，通過快速地感知網(wǎng)絡(luò)的變化，調(diào)整信源，然后果斷舍棄不重要的數(shù)據(jù)，才能夠?qū)崿F(xiàn)更好的實時性。所以最終怎么去評價一個信道建模是否好，就看當(dāng)網(wǎng)絡(luò)快速變化的時候，我們緩沖區(qū)能不能快速地排空，快速地跟著變，然后把最重要的信息傳到對面去。
2、沉浸式
可能會有人問，我們研究得那么細致到底有什么用？
隨著我們現(xiàn)在需求越來越豐富、越來越膨脹，很多沉浸式的場景，它對實時性的要求也非常高。如果沒有前面那么細致的信道分級、信源分級的技術(shù)，經(jīng)常就會產(chǎn)生一些很大的擁塞，比如我們的實時性經(jīng)常有幾十兆甚至上百兆這樣的碼率，如果我們不去做很好的擁塞控制的話，可能一下就會擁塞幾十秒。
我們在沉浸式音視頻方面，也做了一些探索。下面給大家介紹一下，一個是自由視角，它整體的挑戰(zhàn)還是很多的，比如實時視角的差值。我們在流媒體方面遇到了更多、更難的技術(shù)，就是如何快速的頻道切換 、快速的視角切換。簡單的方式是可以用一個低清的流進行預(yù)加載，但是這樣依然無法解決快速視角切換時，應(yīng)該怎樣去進行預(yù)加載？有人提出全I幀的方案，也有人提出低GOP的方案，但是它對清晰度的損傷是非常大的。我們實踐下來相對靠譜一點的方案，是用Simulcast加長期參考幀的方式。視角切換時，只需傳一個I幀加一個長期參考幀和少量幾個P幀，就可以實現(xiàn)快速的頻道切換。這樣的話GOP可以做得比較大，也可以實現(xiàn)在實時性和清晰度上達到相對不錯的平衡。
另外一個廣泛使用的是全景視頻，這個方案大家也都研究過。全景視頻的核心理念就是信源分級。首先會有一個低清的540p的全景圖來進行兜底，這個我們就不細講了。在高清部分，怎樣把一個8K的視頻傳到對面去？我們的做法是分片去編碼，這樣可以實現(xiàn)一次編碼，很多個人同時超低延時地觀看。我們可以用一個六面體的投影，分成640×640的分片，這樣就可以用高端顯卡進行并行編碼，一塊8K的顯卡大約能編出來60幀，需要編120幀的話，可以用兩塊顯卡并行地編。在這個demo上，如果我們的頭動視角是往右上方移動的話，就可以很快地把右上方的幾個新的分片挪下來，然后把左邊幾個分片排除掉，實現(xiàn)快速的頭動延時。當(dāng)然還有一些合并編碼和合并解碼的問題，比如264、265都是有相關(guān)的能力的，264有Slice，265有Tile。編碼標(biāo)準(zhǔn)的定義是比較完善的，但在實踐上還是有很多工程問題需要解決，對碼流格式的要求也是比較高。最終這個方案可以實現(xiàn)上行能壓到大約100兆，下行能做到10兆以內(nèi)，并且在這種場景下我們依然可以達到400毫秒的延時，也可以做到150毫秒的頭動延時。如果想要更快的話，還可以用邊緣云和私有云的方式去加速。
再講一下點云傳輸，就是體積視頻。點云傳輸相比于全景傳輸是一個體驗性更好、更終極的方案，但目前大家的通用做法還是偽3D的方式，就是用2D的背景加前面的3D對象，其實也是在2D的環(huán)境下進行了投影，最后疊加上去了，然后重新貼到一個二維平面上，用二維技術(shù)把投影和深度數(shù)據(jù)進行重新編碼，復(fù)用二維視頻的編碼和傳輸通道。我希望未來幾年大家能夠有真正的3D壓縮能力，把它做出來。
前面講的都是視頻，接下來介紹音頻。一個比較常用的音頻沉浸式的方式就是雙聲道的空間音效，它可以基本復(fù)用現(xiàn)有的音頻編碼和傳輸鏈路，只在渲染端做一些模擬處理，但是這樣的效果肯定不是最好的，更好的方式就是我們正在關(guān)注的這個方式——多聲道的采集。用多個麥克風(fēng)去采集，然后經(jīng)過變換抽離出多個音源，把多個音源分別進行編碼然后傳輸。這里也用到了高精度采樣技術(shù)，我們也可以把16bit的采樣數(shù)據(jù)提升到24bit，然后采樣頻率一并提升。
不過這樣就帶來一個問題，它的碼率會膨脹，音頻碼率有時也能到好幾百K甚至好幾兆，那這種情況下如何實現(xiàn)實時性的全景聲？一個是我們剛剛提到MDC多描述編碼，另一個就是在音樂中經(jīng)常用到的高低頻段，分段編碼的SBR技術(shù)以及參數(shù)立體聲的技術(shù)，也可以跟現(xiàn)在的音頻編碼傳輸結(jié)合起來，保證重要的數(shù)據(jù)能夠傳過去，來保證實時性。
3、跨地區(qū)
另一個重點關(guān)注的問題就是全球化了，全球化的問題分為幾塊，一個比較重要的就是音視頻的基礎(chǔ)設(shè)施的能力，然后就是全球化的數(shù)據(jù)一致性的問題。
全球的節(jié)點是非常多的，面對成千上萬的節(jié)點，難免會遇到節(jié)點與鏈路壞掉的情況，每天有幾十次上百次的鏈路劣化。公網(wǎng)的路由檢測往往只能檢測通和斷兩種情況，它并不能檢測質(zhì)量下降的情況，而且缺少對路徑綜合能力的判斷，畢竟檢測的時效性較差，檢測切換的速度也比較慢，還有一個缺點就是DSCP在廣域網(wǎng)上是失效的，所以我們的做法就是把SDN技術(shù)搬到廣域網(wǎng)上，建一層overlay的網(wǎng)絡(luò)。在傳輸面就完全使用SDN的傳輸能力，在控制面上我們又重寫了控制層，可以讓廣域網(wǎng)上實現(xiàn)SDN的能力。
這樣有幾點好處：一個是DSCP可以兼容，如果我們?nèi)ジ腄SCP，它在這個傳輸網(wǎng)絡(luò)上還是可以生效的，能夠?qū)崿F(xiàn)包級別的QS控制，而且能夠?qū)崿F(xiàn)秒級的檢測和切換，最終我們大概就能實現(xiàn)在公網(wǎng)上電信級的可能性。所以音視頻已經(jīng)慢慢地成為了基礎(chǔ)設(shè)施，我們開發(fā)者就不用太關(guān)注體驗、成本、穩(wěn)定性這些東西，可以把精力放在自己的產(chǎn)品開發(fā)上。
另外講一下，分布式場景下的數(shù)據(jù)一致性的問題。因為我們的實際用戶是遍布在全球各地的，用中心的房間控制器和中心的信令是不合適的。如果你有一個中心信令的話，地球另一端的用戶加入房間和推拉流的首幀延時就會非常長，有時候能到將近一秒。所以我們這里就不能做強一致性的保證，至少這個房間與用戶的關(guān)系，這個是不能夠做強一致性保證的，只能是做最終一致性的保證。
在真正人數(shù)多，也不能做強一致性保證的時候，如何保證大規(guī)模的互動呢？
我們最大的挑戰(zhàn)，就是來自于大房間的架構(gòu)上的挑戰(zhàn)，比如說這個大班課、網(wǎng)絡(luò)研討會還有多人的游戲?qū)?zhàn)，需要非常多的人上臺互動，并且有很多的用戶來觀看，有幾十萬甚至好幾十萬的用戶要同時觀看，有幾百上千的用戶在臺上互動。這種情況下，信令跟傳輸層都需要做特定的優(yōu)化。首先信令要做分布式信令，要去中心化，一定不能做單一的信令，因為它扛不住這么多用戶的沖擊。這種時候信令就要盡量地下沉，分散到全球的多個數(shù)據(jù)中心里，甚至是下沉到離用戶最近的地方，我們只需要把活躍用戶的狀態(tài)一步步更新到其他的信令，而不需要把所有的用戶狀態(tài)分布出去。這樣的話，理論上才能夠?qū)崿F(xiàn)無限的擴展，最終就可以實現(xiàn)一個RTT的進房，一個RTT的推拉流。
另外就是整個傳輸拓撲圖的分發(fā)問題。在全球化的時候，傳輸拓撲圖是并行去進行計算和更新的。因為串行的計算速度比較慢，會面臨很多問題。這個傳輸拓撲需要一個大致平衡的分發(fā)樹，它整體的樹的高度應(yīng)該是比較統(tǒng)一的，這樣才能實現(xiàn)比較低的延時。并行計算的時候還要應(yīng)對海量的用戶快速進房、快速出房的問題，所以還需要進行節(jié)點的動態(tài)分裂與合并。有時候做一些容災(zāi)的和緊急修復(fù)的時候，它的QPS也非常高，同時在這種情況下就很容易引發(fā)回環(huán)的問題，所以還要做回環(huán)的檢測與解除，這里面的限制也很多。
4、開發(fā)者
講完全球化，我最后再講一下開發(fā)者生態(tài)。整體上，我們隨著全球化的業(yè)務(wù)越來越多，開發(fā)者生態(tài)的建設(shè)，包括全球的開發(fā)者一起參與進來，也是我們需要去探索的問題。我們以前覺得的流媒體技術(shù)商業(yè)化，最大的成本來自于資源、帶寬，現(xiàn)在我漸漸發(fā)現(xiàn)流媒體技術(shù)商業(yè)化，最大的成本來自于開發(fā)者的開發(fā)成本，這里的開發(fā)者不僅僅包括代碼的開發(fā)者，也包括內(nèi)容的創(chuàng)作者。創(chuàng)作者實在是太難了，他們要想做出一個優(yōu)秀的應(yīng)用，想做出一些酷炫的內(nèi)容，是需要非常高的學(xué)習(xí)成本的，如果我們能想辦法一起能給他們提供一些非常方便的工具、非常方便的能力，這就是很大的價值，也是火山引擎持續(xù)關(guān)注的方向。
我們關(guān)注的開發(fā)者的工具，就是平民化的創(chuàng)作工具。現(xiàn)在，很多創(chuàng)作者是被很專業(yè)、復(fù)雜、昂貴的創(chuàng)作工具所限制想象力。一個新的機會，一個平民化的創(chuàng)作工具，一個好的技術(shù)要想走進千家萬戶，它的創(chuàng)作工具一定是非常簡單的。比如說，我們最早的時候修圖都用Photoshop，但是真正把修圖帶進千家萬戶的其實是美圖秀秀。我們最早去做視頻、剪輯用Premiere和Final Cut，但是真正把視頻制作帶進千家萬戶的其實是剪映。抖音這么火，推薦系統(tǒng)是肯定很重要的，但源源不斷的內(nèi)容供給也是最重要的因素之一，源源不斷內(nèi)容供給靠的是平民化、簡單化的創(chuàng)作工具。我們現(xiàn)在有很多新技術(shù)，比如特效技術(shù)、流媒體技術(shù)，還有動作捕捉、數(shù)字人以及實時自由視角，但是真的要使用起來難度很大。如果我們大家一起去做出很多能讓自己用手機就能做出來的工具、就能使用的一些場景，我相信將給整個行業(yè)帶來更多的想象力。
過去幾年，開發(fā)者的工具變化也很大。最早我們有SaaS，SaaS的應(yīng)用形態(tài)相對比較單一，所以大家都覺得不夠靈活。過了幾年，出現(xiàn)了PaaS。PaaS是靈活了，但對開發(fā)者的使用門檻也越來越高。于是又出來了新的aPaaS。我覺得很難講，哪一個是未來的趨勢，但是有這么多可能性，我們給開發(fā)者提供更多的選擇，總歸是更好的。
最后提一下，我們最近在重點思考和關(guān)注的一個事情就是多模塊之間的協(xié)同。所有的方案都會涉及到多個模塊的協(xié)同，大家往往喜歡做一個大而全的一個App，把所有的功能都裝進去，安裝包一下子就100多兆，直播、點播、RTC、網(wǎng)頁、消息、小程序全都在里面，很多時候他們是一起工作的。所有的模塊包括這個APP是共用帶寬、共用所有的采集和播放的設(shè)備，并且也共用CPU、GPU的內(nèi)存。但是很多模塊在設(shè)計時不會去考慮，其他的模塊是怎么去使用資源、帶寬的。希望我們以后在設(shè)計這些模塊時要考慮一下，如何去共享資源，甚至是出讓資源而不是搶占資源。大家在設(shè)計的時候應(yīng)該去思考如何去共享、協(xié)同，把更多的選擇權(quán)留給開發(fā)者。
火山引擎在這方面也做了一些探索：一是我們所有模塊都支持動態(tài)的性能的降級、動態(tài)的帶寬降級。不但支持我們自己的降級，還支持自定義的降級。比如用我們的SDK的時候，可以把我們的SDK限制在最高的一個帶寬使用量上，例如：500K上，這樣SDK就不會使用更高的帶寬，也可以支持把目前你所能探索到的帶寬預(yù)留出來100K給別的模塊用。無論現(xiàn)在探測出來多少帶寬，就只用現(xiàn)在的已有的帶寬減100K，剩下的預(yù)留給其他的模塊，這樣能夠?qū)崿F(xiàn)更好的協(xié)同。同時火山引擎也可以支持讓不同的SDK之間設(shè)置優(yōu)先級，讓這個SDK比其他SDK更重要，這在很多場景下是有用的。比如在直播做互動的時候，雖然直播很重要，音視頻很重要，但是消息更重要，有時用戶送的特效禮物可能是一個點播文件，但有些時候這些東西甚至?xí)戎辈ズ蚏TC更重要。在教育、會議的場景下，這種現(xiàn)象就更多，比如我們的音視頻共享，可能就比音頻信號更重要，這種時候就要求我們的每個模塊都能具備自定義的升降級以及自定義的優(yōu)先級的能力，同樣除了對帶寬，對性能也可以做這樣的上限和預(yù)留的操作。這個目的就是把更多的選擇權(quán)留給開發(fā)者。
基于以上的設(shè)計理念，火山引擎推出了音視頻云端一體解決方案veVOS，這個方案有很多的優(yōu)點，歡迎大家去火山引擎的官網(wǎng)上去看。這里專注講一下協(xié)同，因為我覺得其他的優(yōu)點大家之前能夠關(guān)注到，但是協(xié)同這一點也是希望所有人、所有業(yè)內(nèi)伙伴未來一起去關(guān)注的點。要做云和端的協(xié)同，要做模塊與模塊之間的協(xié)同，甚至要做我們自己的模塊和宿主的APP應(yīng)用之間的協(xié)同，防止這些模塊之間的資源沖突，我們光把它們打成同一個包，打成一個SDK直接給客戶和開發(fā)者是遠遠不夠的，要提供更多的能力，讓不同的模塊之間、不同公司的SDK之間和應(yīng)用之間，防止資源沖突，做到更好的協(xié)同。
流媒體行業(yè)已經(jīng)發(fā)展幾十年了，大家對互動性、沉浸式、全球化還有開發(fā)者生態(tài)方面的要求越來越高，所以我覺得未來還是有很多機會的。
從抖音到火山引擎，我們持續(xù)關(guān)注的流媒體行業(yè)中的幾個重要的機會：一是沉浸式的實時音視頻，希望不久之后能有真正的沉浸式實時音視頻的產(chǎn)生，并且能夠真正地融入到我們的生活。我們在科幻片里看到的那些實時互動，那種沉浸式的場景，我相信很快就會變成現(xiàn)實；另一個是平民化的創(chuàng)作工具，能夠帶給我們豐富的內(nèi)容。我覺得平民化的創(chuàng)作工具其實是這個行業(yè)持續(xù)的發(fā)展、持續(xù)產(chǎn)生新動力的動力源泉；最后一個是音視頻的基礎(chǔ)設(shè)施，它讓我們能夠幫開發(fā)者做好很多事情，讓開發(fā)者聚焦到做更多的、更好的產(chǎn)品，能促進這個行業(yè)更快的進步。所以希望在座的各位一起去關(guān)注這些機會，通過技術(shù)的進步和工具的建設(shè)，給流媒體行業(yè)帶來更加豐富的可能性。
謝謝大家，謝謝LiveVideoStack，歡迎大家持續(xù)關(guān)注火山引擎！
