編者按： 8 月 5 日上午，LiveVideoStackCon 2022 音視頻技術大會上海站邀請到了火山引擎 RTC 負責人宋慎義老師，為我們從實時性、沉浸式、跨地區和開發者等四個方向，來看從抖音到火山引擎，流媒體技術演進過程和機會。在宋慎義老師的演講中，我們看到了火山引擎一路走來的歷程，也了解到通過結合不同的場景，火山引擎對外來探索的堅持。

文 / 宋慎義

整理 / LiveVideoStack

LiveVideoStack 是 2017 年開始創辦的，我也恰好在那一年加入字節跳動，與字節跳動一同高速成長，從抖音到飛書，再到現在把這些成熟能力通過火山引擎對外輸出，為更多的開發者與企業客戶提供服務。

首先介紹一下過去幾年，在流媒體技術上，我們遇到了哪些場景，解決了哪些難題以及從長遠來看，未來幾年我們需要持續關注的未來的方向和機會。

字節跳動大約是在 2016 年開始做流媒體相關的技術，之前只有點播。一開始我們是做單向的直播，后來有了實時互動。2020 年年初疫情爆發，更復雜的互動模式開始產生。我們在 2020 年推出了火山引擎，整個公司包括云基礎、視頻云以及大數據都開始向火山引擎上遷移。從那之后，字節跳動的技術能力開始慢慢成為火山引擎上的一些服務對外輸出。之后，我們又利用火山引擎支撐游戲、沉浸式音視頻等多種應用，火山引擎也幫助這些應用獲得更好實現增長。

我們在做直播連麥業務的時候，遇到第一個問題是：如何在高清、實時和流暢這三個維度上做好平衡。想完全兼顧這三個維度是不可能的，雖然不能完全 100% 的實現高清、流暢和實時，但是可以 90% 實現，隨著技術的演進，90% 可以提升到 99%，甚至更高。我們更多技術的發展也在不斷地提高我們在高清、流暢和實時上的能力，不斷提升用戶體驗。

疫情爆發以后，在線教育和視頻會議也大爆發，誕生了很多非常復雜、有挑戰的新場景，比如大班小組課、網絡研討會以及游戲的對戰語音等，它需要一些新的突破，同時要解決全球化、多地區的問題，還要解決人和設備的問題。現在，除了人會加入互動，設備也會加入互動，所以通過架構的優化，我們提出多中心的分布式的信令的架構，能夠支撐超大規模的互動。

近兩年，沉浸式音視頻忽然火爆起來，迎來音視頻技術的新增長曲線，產生新的潮流，包括 VR 的視頻、直播互動以及超低延時的直播和云端的渲染等，給技術方案提出了新的挑戰。

今天，我從四個維度給大家介紹一下，我們在流媒體技術演進上重點關注的幾個方向。第一個是實時性。實時性是流媒體技術發展最大的限制條件，如果沒有實時性的限制，音視頻技術復雜度至少能降低一半；第二個是沉浸式，這是現在需求比較大的一個演進的方向，近幾年的技術進步也要開始沉浸式地、慢慢地走入千家萬戶，走入每個人的生活；第三個是全球化，目前是中國流量紅利見頂的一個階段，在這個前提下，不得不面臨的一個問題是，我們既想繼續發展技術，又想獲得更多的用戶，獲得更多的增長，那就必須去面對全球化的問題；最后我講一下我們在開發者生態上的思考，廣義上的開發者不僅僅是開發者，還包括內容創作者。我們看看，通過技術進步能夠提供給開發者，怎樣的工具，怎樣的服務。

1、實時性

提到實時互動，我發現同行們在信道傳輸上的討論比較多，但怎樣把信源跟信道結合起來，一起去做優化，是實時互動的一個關鍵的技術點。

實時性的核心理念就是信源分級與信道分級，用有限的信道去傳輸最重要的信息。展開來講，我們可以把信源或者說要傳輸的信息，按照實時性和可靠性這兩個維度進行拆分。有些信息非常重要，它對實時性和可靠性的要求非常高，比如說信令消息；有些信息它對實時性要求高，對可靠性的要求也許能低一些，例如音頻；對于視頻而言，可靠性要求就更低了；同時也有一些信息，它對可靠性要求很高，對實時性要求沒有那么高，比如說文件的傳輸、直播等；也有一些信息對可靠性和實時性要求都不高，比如說日志。那么信源可以分級，信道其實也是可以分級的。信道看起來是一個單一的信道，但是畢竟這么多的信源是要在統一的一個信道里去傳輸的，所以我們要把信道劃分成很多個不同的能力，要把一些重要的信道、傳輸方式、傳輸容量預留出來，給信源來使用。調節的方法就是通過調優先級、FEC 或者是調重傳來實現這個信道的劃分和信道的隔離。

前面的偏理論，現在講一下如何落地。首先是信源分級的落地。實際場景中，音頻跟視頻這些信源會按照重要性繼續進行拆分。常見的是低頻的信號或低清的信號肯定更重要一些，高清的信號關鍵時刻是可以舍棄的。在視頻的信源分級上相對是比較成熟的，我們常見的有 Simulcast 這樣的技術，包括在直播上經常使用的 HLS、CMAF, 本質上都是做視頻的信源分級。不同清晰度之間也可以互相參考，比如 SVC 的技術，它有時域跟空域上的機制的劃分以及長期參考幀的技術，可以讓我們在一定程度上降低一些帶寬。高清的部分實在傳不過去也沒關系，現在也有很多超分辨率重建的技術，短時間內頂一下還是可以的。

我們在音頻上的關注更多一些，因為在真正信道變化的時候，音頻產生的問題對感官的影響更大。這里介紹一下我們使用的一個性價比比較高的技術是 MDC 多描述編碼。簡單來講，就是可以把一個音頻的序列拆成多個子序列，讓它們「1、2、3，1、2、3」地報數，所有報 1 的站一隊，所有報 2 的站一隊，所有報 3 的站一隊。這樣的好處就是這三段編碼、三段序列可以分開地去編碼、傳輸，只要有任何一個序列能夠到達對面，相當于音頻的低頻部分、低頻信號就可以到達對面了。到達對面的分片越多，音頻的清晰度就會越高。如果只到達一兩個，它的清晰度會有一些影響，但是基本不會影響溝通，這是一種性價比比較高的方式，它是一種原生的抗丟包的 Codec。再把這種技術和 FEC、AI-Codec 結合起來，基本就可以實現：只要網是通的，只要有一點數據能夠傳到對面去，就能達到比較流暢的效果。實在傳不過去，還有一些 NetEQ、PLC 的方式可以作補充。

經常有人問我，什么傳輸協議最好？

其實傳輸協議沒有好與不好之分，只有合適與不合適的區別。

什么樣的傳輸協議是合適的？

主要看應用場景、現實條件里有沒有實時性的要求。如果沒有實時性的要求，那一個能夠有效利用信道與帶寬的傳輸協議，就是最合適的。比如沒有實時性要求，那 TCP 就是一個非常優秀的傳輸協議。如果有實時性要求，在傳輸協議的設計上就必須要實現三個目的：首先要能夠調節重傳實現可靠；有了一定可靠性之后，還要通過調節 FEC 讓它實現一定的實時性；高優先級保證重要數據，丟棄 / 暫緩不重要數據。

一個很重要的傳輸協議的設計功能就是優先級。一個優秀的傳輸協議，實時傳輸協議一定要具備優先級的區別，這樣能保證重要的數據優先傳過去，不重要的數據就果斷放棄。比如，一些非常重要的數據對實時性和可靠性的要求非常高，那就可以加很高倍的冗余，并且用很快速的重傳方法，然后能高優先級地傳輸。雖然這樣子的數據可能帶寬浪費比較嚴重，沒有辦法傳大量高碼率的數據，但這樣的數據用這樣的傳輸協議就能實現很好的可靠性與實時性。對可靠性要求不是很高的數據，就可以進行低倍冗余，也可以進行有限重傳，比如只重傳關鍵幀，對于非關鍵幀不重傳，這種情況下就可以實現信道的分級。這幾個能力可以組合起來使用，但也可以是相對的，對于一些長肥網絡可能最理智的方式就是關掉所有重傳，讓 FEC 去起作用。

信道分級以后一個重要的工作就是如何對信道進行建模。信道建模簡單來講就是要準確的表述網絡狀態。以前，信道建模的方式比較簡單，都是用單一的變量，比如用丟包、帶寬來描述一個信道，后來大家發現這些還是有一定的缺陷的，于是就有了相對組合的一些模型，比如延時帶寬積。現在，隨著算力的增加，信道建模的復雜度也相對越來越高，有的模型會有很多變量加進來參考。但是信道建模去描述網絡狀態是一方面，一個更重要的方式是，如何快速地感知網絡的變化。有的模型其實是用統計類的指標，再加上濾波的方法來實現網絡變化的感知。它可能會比較準，但是有一個很大的問題，它沒有辦法實現快速。有時候，我們的網絡環境已經變了，但幾秒鐘之后它才感知出來。這樣的話，對實時性的要求就會比較高，所以在實踐中除了統計類的指標，比如丟包率、帶寬這種需要好幾秒才能統計出來指標，我們往往會加入一些瞬時指標去做修正，比如亂序、延時這些指標，就能夠很快地去檢測出來。

那么能夠描述網絡狀態，感知網絡的變化之后，剩下的就是如何快速地兼容弱網。大家很喜歡用這個弱網對抗這個詞，但我不是很喜歡用弱網對抗，因為很多時候弱網是沒有辦法對抗的，只能去兼容。有些時候，動態變化是網絡自身固有條件的、固有屬性的動態變化。有些時候，是因為我們的信息傳輸發生了擁塞，那么這種時候需要改變的是信源自己。我們前面講到信源分級，信源分級以后，通過快速地感知網絡的變化，調整信源，然后果斷舍棄不重要的數據，才能夠實現更好的實時性。所以最終怎么去評價一個信道建模是否好，就看當網絡快速變化的時候，我們緩沖區能不能快速地排空，快速地跟著變，然后把最重要的信息傳到對面去。

2、沉浸式

可能會有人問，我們研究得那么細致到底有什么用？

隨著我們現在需求越來越豐富、越來越膨脹，很多沉浸式的場景，它對實時性的要求也非常高。如果沒有前面那么細致的信道分級、信源分級的技術，經常就會產生一些很大的擁塞，比如我們的實時性經常有幾十兆甚至上百兆這樣的碼率，如果我們不去做很好的擁塞控制的話，可能一下就會擁塞幾十秒。

我們在沉浸式音視頻方面，也做了一些探索。下面給大家介紹一下，一個是自由視角，它整體的挑戰還是很多的，比如實時視角的差值。我們在流媒體方面遇到了更多、更難的技術，就是如何快速的頻道切換 、快速的視角切換。簡單的方式是可以用一個低清的流進行預加載，但是這樣依然無法解決快速視角切換時，應該怎樣去進行預加載？有人提出全 I 幀的方案，也有人提出低 GOP 的方案，但是它對清晰度的損傷是非常大的。我們實踐下來相對靠譜一點的方案，是用 Simulcast 加長期參考幀的方式。視角切換時，只需傳一個 I 幀加一個長期參考幀和少量幾個 P 幀，就可以實現快速的頻道切換。這樣的話 GOP 可以做得比較大，也可以實現在實時性和清晰度上達到相對不錯的平衡。

另外一個廣泛使用的是全景視頻，這個方案大家也都研究過。全景視頻的核心理念就是信源分級。首先會有一個低清的 540p 的全景圖來進行兜底，這個我們就不細講了。在高清部分，怎樣把一個 8K 的視頻傳到對面去？我們的做法是分片去編碼，這樣可以實現一次編碼，很多個人同時超低延時地觀看。我們可以用一個六面體的投影，分成 640×640 的分片，這樣就可以用高端顯卡進行并行編碼，一塊 8K 的顯卡大約能編出來 60 幀，需要編 120 幀的話，可以用兩塊顯卡并行地編。在這個 demo 上，如果我們的頭動視角是往右上方移動的話，就可以很快地把右上方的幾個新的分片挪下來，然后把左邊幾個分片排除掉，實現快速的頭動延時。當然還有一些合并編碼和合并解碼的問題，比如 264、265 都是有相關的能力的，264 有 Slice，265 有 Tile。編碼標準的定義是比較完善的，但在實踐上還是有很多工程問題需要解決，對碼流格式的要求也是比較高。最終這個方案可以實現上行能壓到大約 100 兆，下行能做到 10 兆以內，并且在這種場景下我們依然可以達到 400 毫秒的延時，也可以做到 150 毫秒的頭動延時。如果想要更快的話，還可以用邊緣云和私有云的方式去加速。

再講一下點云傳輸，就是體積視頻。點云傳輸相比于全景傳輸是一個體驗性更好、更終極的方案，但目前大家的通用做法還是偽 3D 的方式，就是用 2D 的背景加前面的 3D 對象，其實也是在 2D 的環境下進行了投影，最后疊加上去了，然后重新貼到一個二維平面上，用二維技術把投影和深度數據進行重新編碼，復用二維視頻的編碼和傳輸通道。我希望未來幾年大家能夠有真正的 3D 壓縮能力，把它做出來。

前面講的都是視頻，接下來介紹音頻。一個比較常用的音頻沉浸式的方式就是雙聲道的空間音效，它可以基本復用現有的音頻編碼和傳輸鏈路，只在渲染端做一些模擬處理，但是這樣的效果肯定不是最好的，更好的方式就是我們正在關注的這個方式 —— 多聲道的采集。用多個麥克風去采集，然后經過變換抽離出多個音源，把多個音源分別進行編碼然后傳輸。這里也用到了高精度采樣技術，我們也可以把 16bit 的采樣數據提升到 24bit，然后采樣頻率一并提升。

不過這樣就帶來一個問題，它的碼率會膨脹，音頻碼率有時也能到好幾百 K 甚至好幾兆，那這種情況下如何實現實時性的全景聲？一個是我們剛剛提到 MDC 多描述編碼，另一個就是在音樂中經常用到的高低頻段，分段編碼的 SBR 技術以及參數立體聲的技術，也可以跟現在的音頻編碼傳輸結合起來，保證重要的數據能夠傳過去，來保證實時性。

3、跨地區

另一個重點關注的問題就是全球化了，全球化的問題分為幾塊，一個比較重要的就是音視頻的基礎設施的能力，然后就是全球化的數據一致性的問題。

全球的節點是非常多的，面對成千上萬的節點，難免會遇到節點與鏈路壞掉的情況，每天有幾十次上百次的鏈路劣化。公網的路由檢測往往只能檢測通和斷兩種情況，它并不能檢測質量下降的情況，而且缺少對路徑綜合能力的判斷，畢竟檢測的時效性較差，檢測切換的速度也比較慢，還有一個缺點就是 DSCP 在廣域網上是失效的，所以我們的做法就是把 SDN 技術搬到廣域網上，建一層 overlay 的網絡。在傳輸面就完全使用 SDN 的傳輸能力，在控制面上我們又重寫了控制層，可以讓廣域網上實現 SDN 的能力。

這樣有幾點好處：一個是 DSCP 可以兼容，如果我們去改 DSCP，它在這個傳輸網絡上還是可以生效的，能夠實現包級別的 QS 控制，而且能夠實現秒級的檢測和切換，最終我們大概就能實現在公網上電信級的可能性。所以音視頻已經慢慢地成為了基礎設施，我們開發者就不用太關注體驗、成本、穩定性這些東西，可以把精力放在自己的產品開發上。

另外講一下，分布式場景下的數據一致性的問題。因為我們的實際用戶是遍布在全球各地的，用中心的房間控制器和中心的信令是不合適的。如果你有一個中心信令的話，地球另一端的用戶加入房間和推拉流的首幀延時就會非常長，有時候能到將近一秒。所以我們這里就不能做強一致性的保證，至少這個房間與用戶的關系，這個是不能夠做強一致性保證的，只能是做最終一致性的保證。

在真正人數多，也不能做強一致性保證的時候，如何保證大規模的互動呢？

我們最大的挑戰，就是來自于大房間的架構上的挑戰，比如說這個大班課、網絡研討會還有多人的游戲對戰，需要非常多的人上臺互動，并且有很多的用戶來觀看，有幾十萬甚至好幾十萬的用戶要同時觀看，有幾百上千的用戶在臺上互動。這種情況下，信令跟傳輸層都需要做特定的優化。首先信令要做分布式信令，要去中心化，一定不能做單一的信令，因為它扛不住這么多用戶的沖擊。這種時候信令就要盡量地下沉，分散到全球的多個數據中心里，甚至是下沉到離用戶最近的地方，我們只需要把活躍用戶的狀態一步步更新到其他的信令，而不需要把所有的用戶狀態分布出去。這樣的話，理論上才能夠實現無限的擴展，最終就可以實現一個 RTT 的進房，一個 RTT 的推拉流。

另外就是整個傳輸拓撲圖的分發問題。在全球化的時候，傳輸拓撲圖是并行去進行計算和更新的。因為串行的計算速度比較慢，會面臨很多問題。這個傳輸拓撲需要一個大致平衡的分發樹，它整體的樹的高度應該是比較統一的，這樣才能實現比較低的延時。并行計算的時候還要應對海量的用戶快速進房、快速出房的問題，所以還需要進行節點的動態分裂與合并。有時候做一些容災的和緊急修復的時候，它的 QPS 也非常高，同時在這種情況下就很容易引發回環的問題，所以還要做回環的檢測與解除，這里面的限制也很多。

4、開發者

講完全球化，我最后再講一下開發者生態。整體上，我們隨著全球化的業務越來越多，開發者生態的建設，包括全球的開發者一起參與進來，也是我們需要去探索的問題。我們以前覺得的流媒體技術商業化，最大的成本來自于資源、帶寬，現在我漸漸發現流媒體技術商業化，最大的成本來自于開發者的開發成本，這里的開發者不僅僅包括代碼的開發者，也包括內容的創作者。創作者實在是太難了，他們要想做出一個優秀的應用，想做出一些酷炫的內容，是需要非常高的學習成本的，如果我們能想辦法一起能給他們提供一些非常方便的工具、非常方便的能力，這就是很大的價值，也是火山引擎持續關注的方向。

我們關注的開發者的工具，就是平民化的創作工具。現在，很多創作者是被很專業、復雜、昂貴的創作工具所限制想象力。一個新的機會，一個平民化的創作工具，一個好的技術要想走進千家萬戶，它的創作工具一定是非常簡單的。比如說，我們最早的時候修圖都用 Photoshop，但是真正把修圖帶進千家萬戶的其實是美圖秀秀。我們最早去做視頻、剪輯用 Premiere 和 Final Cut，但是真正把視頻制作帶進千家萬戶的其實是剪映。抖音這么火，推薦系統是肯定很重要的，但源源不斷的內容供給也是最重要的因素之一，源源不斷內容供給靠的是平民化、簡單化的創作工具。我們現在有很多新技術，比如特效技術、流媒體技術，還有動作捕捉、數字人以及實時自由視角，但是真的要使用起來難度很大。如果我們大家一起去做出很多能讓自己用手機就能做出來的工具、就能使用的一些場景，我相信將給整個行業帶來更多的想象力。

過去幾年，開發者的工具變化也很大。最早我們有 SaaS，SaaS 的應用形態相對比較單一，所以大家都覺得不夠靈活。過了幾年，出現了 PaaS。PaaS 是靈活了，但對開發者的使用門檻也越來越高。于是又出來了新的 aPaaS。我覺得很難講，哪一個是未來的趨勢，但是有這么多可能性，我們給開發者提供更多的選擇，總歸是更好的。

最后提一下，我們最近在重點思考和關注的一個事情就是多模塊之間的協同。所有的方案都會涉及到多個模塊的協同，大家往往喜歡做一個大而全的一個 APP，把所有的功能都裝進去，安裝包一下子就 100 多兆，直播、點播、RTC、網頁、消息、小程序全都在里面，很多時候他們是一起工作的。所有的模塊包括這個 APP 是共用帶寬、共用所有的采集和播放的設備，并且也共用 CPU、GPU 的內存。但是很多模塊在設計時不會去考慮，其他的模塊是怎么去使用資源、帶寬的。希望我們以后在設計這些模塊時要考慮一下，如何去共享資源，甚至是出讓資源而不是搶占資源。大家在設計的時候應該去思考如何去共享、協同，把更多的選擇權留給開發者。

火山引擎在這方面也做了一些探索：一是我們所有模塊都支持動態的性能的降級、動態的帶寬降級。不但支持我們自己的降級，還支持自定義的降級。比如用我們的 SDK 的時候，可以把我們的 SDK 限制在最高的一個帶寬使用量上，例如：500K 上，這樣 SDK 就不會使用更高的帶寬，也可以支持把目前你所能探索到的帶寬預留出來 100K 給別的模塊用。無論現在探測出來多少帶寬，就只用現在的已有的帶寬減 100K，剩下的預留給其他的模塊，這樣能夠實現更好的協同。同時火山引擎也可以支持讓不同的 SDK 之間設置優先級，讓這個 SDK 比其他 SDK 更重要，這在很多場景下是有用的。比如在直播做互動的時候，雖然直播很重要，音視頻很重要，但是消息更重要，有時用戶送的特效禮物可能是一個點播文件，但有些時候這些東西甚至會比直播和 RTC 更重要。在教育、會議的場景下，這種現象就更多，比如我們的音視頻共享，可能就比音頻信號更重要，這種時候就要求我們的每個模塊都能具備自定義的升降級以及自定義的優先級的能力，同樣除了對帶寬，對性能也可以做這樣的上限和預留的操作。這個目的就是把更多的選擇權留給開發者。

基于以上的設計理念，火山引擎推出了音視頻云端一體解決方案 veVOS，這個方案有很多的優點，歡迎大家去火山引擎的官網上去看。這里專注講一下協同，因為我覺得其他的優點大家之前能夠關注到，但是協同這一點也是希望所有人、所有業內伙伴未來一起去關注的點。要做云和端的協同，要做模塊與模塊之間的協同，甚至要做我們自己的模塊和宿主的 APP 應用之間的協同，防止這些模塊之間的資源沖突，我們光把它們打成同一個包，打成一個 SDK 直接給客戶和開發者是遠遠不夠的，要提供更多的能力，讓不同的模塊之間、不同公司的 SDK 之間和應用之間，防止資源沖突，做到更好的協同。

流媒體行業已經發展幾十年了，大家對互動性、沉浸式、全球化還有開發者生態方面的要求越來越高，所以我覺得未來還是有很多機會的。

從抖音到火山引擎，我們持續關注的流媒體行業中的幾個重要的機會：一是沉浸式的實時音視頻，希望不久之后能有真正的沉浸式實時音視頻的產生，并且能夠真正地融入到我們的生活。我們在科幻片里看到的那些實時互動，那種沉浸式的場景，我相信很快就會變成現實；另一個是平民化的創作工具，能夠帶給我們豐富的內容。我覺得平民化的創作工具其實是這個行業持續的發展、持續產生新動力的動力源泉；最后一個是音視頻的基礎設施，它讓我們能夠幫開發者做好很多事情，讓開發者聚焦到做更多的、更好的產品，能促進這個行業更快的進步。所以希望在座的各位一起去關注這些機會，通過技術的進步和工具的建設，給流媒體行業帶來更加豐富的可能性。

謝謝大家，謝謝 LiveVideoStack，歡迎大家持續關注火山引擎！