RTC 技術的試金石:火山引擎視訊會議場景技術實踐

語言: CN / TW / HK

視訊會議場景一直被認為是 RTC 最具挑戰性的場景,一方面,它對抗弱網、低端機適配、降噪、多人上麥等都有極高的要求,對 Web 端的要求也遠高於其他場景;另一方面,有很多孵化自會議場景的技術能力最終都被複制到了其他場景。

RTC 在會議場景的獨特挑戰

為什麼說“視訊會議”場景對於 RTC 的技術挑戰最大?相比於其他行業和場景,“視訊會議”中的 RTC 到底獨特在哪?

首先,會議場景的需求是更為複雜的,這裡舉 4 個例子。

第一個是「自由開麥」。在視訊會議中,每一個參會方都可以自由選擇是否開啟自己的麥克風和攝像頭,這是視訊會議非常基礎的功能,但隨著參會人數的增加,技術實現會越發複雜。行業內 RTC 一般可以實現五十到上百人的自由開麥,超過了這個人數之後就需要主持人來控制麥位。飛書會議要求我們支援 1000 個參會方,如果 RTC 支援自由上麥的人數低於 1000,飛書會議的使用者使用起來就會非常不方便(雖然所有參會人同時開麥的極端情況比較少見,但是業務的需求是希望主持人不要過多“干預”會議——不斷地控制參會人上麥、下麥,把發言能力分配給想發言的人)。假設一場會議裡有 1000 個參會方,但只有 50 個麥位可以發言,主持人就要把想說話的參會人不停地“挪”到這 50 個麥位之中。為了讓主持人知道誰想發言,還需要引入一些溝通機制,整體操作成本非常高。RTC 為什麼會限制擁有上麥能力的使用者數量?如果不限制可以上麥使用者的數量,釋出/訂閱流模型的演算法複雜度就是 O(n^2),即,如果有 1000 人蔘會,就會產生 100 萬 音視訊流釋出/訂閱關係。短時間高頻的上下麥操作會造成服務端信令風暴,所以上麥人數才需要加以限制。可是現實中,一些大型會議的規模往往會超過 1000 人,甚至達到幾千、上萬,我們不該因為技術的限制而犧牲使用者的體驗。

第二個是「自由佈局」。視訊會議一般會提供多種檢視佈局型別供參會方選擇,從 1*1 全屏,到 2*2 四宮格,3*3 九宮格,到 7*7 四十九宮格……這還只是普通的宮格,還會有一些其他佈局,比如演講者模式、側邊欄模式等。畫面佈局型別的豐富讓每個參會者都可以自己選擇自己喜歡的佈局,但這樣一來,同一個會上,有開四宮格的,有開九宮格的,有開演講者模式的,視訊釋出者就需要決策到底釋出什麼樣的解析度。如果釋出的解析度過大,對於選擇多宮格的訂閱方來說,解析度就過剩了,同時還造成了極大的下行頻寬和裝置效能壓力——試想一下,一個訂閱方同時拉了 49 路 1080P 的視訊,什麼樣的神仙裝置和頻寬都扛不住;如果釋出的解析度過小,對於全屏或者演講者模式這樣的大視窗來說,清晰度就會不足,使用者體驗會受到影響。嚴格來說,每一種佈局都應該有一個最合適的解析度。在多人會議中,如何在有限的頻寬與裝置效能下,儘量提供靈活多樣的畫面佈局,是一個很大的挑戰。

第三個是「螢幕共享」。這個功能大家比較容易理解,它的挑戰在於,螢幕共享雖然也是視訊流,但是它的視訊畫面特點和我們攝像頭拍攝的視訊畫面特點是不一樣的。簡單來說,螢幕共享對畫面的要求更清晰,要能看清楚很小的文字,但是對於幀率的要求並不高。對於編碼器來說,需要決策什麼時候編高幀率的視訊,什麼時候編低幀率的視訊,這是關鍵。

最後是「Web 入會」。很多時候,視訊會議軟體的使用者是“臨時使用者”,比如用視訊會議去參加一場面試,或者是合作伙伴用你們公司的會議軟體來參加一場會議…這些“臨時使用者”可能並不希望去安裝一個會議 App,用 Web 入會就是一個非常好的選擇。但是 Web 對音視訊有很多限制,而對視訊會議的需求和體驗的要求一點都沒少,怎麼才能把 Web 入會的體驗儘量追上 Native 的體驗?

除了業務需求更加複雜以外,視訊會議場景所面臨的環境也更為極端。

過去,開視訊會議都是在專業的會議室裡開,有很多專業的會議硬體裝置來支撐會議體驗,環境是相對比較好的。但現在,開會環境早已不限於會議室了,會議環境的多樣性讓 RTC 面臨了很多新的挑戰。這幾年,疫情讓我們居家辦公的時間更多了,在家裡開視訊會議成為了很普遍的場景;一些經常出差的人——他們往往也是會比較多的人——在路上、車上、高鐵上甚至飛機上通過手機參加視訊會議也非常普遍。

會議環境多樣性為 RTC 帶來的挑戰主要可以分為以下四大類:首先是極端弱網,俗稱“使用者網路差”。這種情況非常常見,尤其是不在公司會議室裡開會,弱網情況更常見;其次是弱裝置,也就是“裝置效能不足”。如果參會裝置不是專業視訊會議硬體,就會承擔更多的效能壓力,尤其當參會人開啟美顏或者虛擬背景這樣高消耗的功能之後,原本可以開會的裝置也會出現效能不足。現在在視訊會議中使用虛擬背景是一個非常高頻的功能,大家看我現在視訊的背景就是一個虛擬背景。再者就是會議場景的噪聲型別會更多,除了會議場景常見的鍵盤聲之外,如果你不是在會議室開會,就會伴隨各種各樣的噪聲:空調的聲音、開關門的聲音、隔壁裝修的聲音、附近人說話的聲音、小孩的哭鬧聲,室外的喧囂聲……最後一個挑戰是光線差。離開專業會議室的環境之後,可能會面臨嚴重的光線不足、背光等問題——本來家裡的光線佈局就不是為了居家開會所設計的,更不要說在戶外或者交通工具上開會了。

從技術角度看,RTC 技術最初就是從視訊會議中抽象剝離出來的,後來逐漸應用到會議以外的領域,所以很多 RTC 的新場景其實就是從視訊會議中遷移出來的。換句話說,RTC 在視訊會議場景的「獨特性」,其實也可以認為是一種「領先性」。

從最近幾年的行業發展來看,不斷有從會議場景技術溢位到其他行業的案例。之前特別熱門的「大班小組課」,其實就是會議中的「分組會議 Breakout Room」。再比如現在很火的 「3D 空間音效」,其實最初的應用是高階視訊會議產品中的「聽聲辨位」,HP 2005 年釋出的 Halo 就支援這個功能。最後說說「千方會議」。我們在去年 6 月已經對外介紹了我們做的“千人上麥”能力,在今年 2 月份正式對外發布了這個功能。當時很多朋友不理解我們為什麼要做那麼大的上麥併發,實際上是因為,我們看到不僅視訊會議有這個需求,其他場景也陸續出現了這個需求,像線上教育大班課中的齊聲朗讀或者搶答,大型吃雞遊戲中的世界語音,還有現在正在發生的大型 VR 社交,這些場景需要自由上麥的人數很容易突破幾百甚至上千。既然「千方會議」可以支援大型視訊會議,何不做成 RTC 的標準能力,來解鎖各行各業中“自由上麥”人數的瓶頸,發揮更大的價值呢?順便提一句,目前我們還在進一步突破上麥人數上限,實現「萬方會議」甚至更多。

「千方會議」過去已經和大家介紹過了,今天不再重點展開。接下來和大家分享視訊會議對 RTC 的幾個新的挑戰和我們的思考實踐。

複雜光線下的視訊體驗

第一個話題是「複雜光線下的視訊體驗」。

前面提到,很多使用者入會時所處的位置可能並沒有很好的光照條件,比如晚間的戶外,光線會嚴重不足;比如在室內,如果光源的位置不佳,會形成逆光或者側光。惡劣的光照條件會嚴重影響視訊體驗,但我們一般人開會也不會像專業主播一樣準備專用的打光裝置,因此,一旦光線不好,拍攝效果就會差,而一旦拍攝基礎效果差,僅僅靠視訊後處理技術是沒有辦法很好地解決視訊體驗問題的。

為了解決這些問題,我們引入了一系列的相機技術,包括自動對焦、自動曝光這些比較基本的相機技術。RTC 場景和其他場景有個不一樣的地方,畫面中一般都是人像佔據主體,而當畫面中人像佔據主體時,如果不做特別處理,由於攝像頭本身是“平均測光”的,當人像處於逆光環境時,由於背景很亮,會導致曝光不足,人臉會顯得過暗。因此,我們在 AE 的基礎上又增加了人臉檢測演算法,即 FaceAE,當檢測到人臉時,把“平均測光”優化為“根據人臉檢測結果”來做曝光處理,解決畫面過曝、欠曝的問題。為了實現最佳效果,我們與國內外很多手機和晶片廠商保持良好的合作,把硬體的相機功能和我們自研的演算法進行深度結合,讓每一款裝置都達到最佳效能。目前我們已經對線上 18000+ 款機型進行了適配,覆蓋低中端各類機型。

我們使用了一些知名會議或社交 App 來和我們的拍攝效果做對比,大家可以感受一下基於 FaceAE 演算法優化過的相機效果。第一組對比圖是一個戶外傍晚背景,畫面中有一盞路燈,可以看到右邊使用 FaceAE 演算法優化過的採集效果,人臉更亮,天也更藍,畫面整體感覺更舒服。第二組是室內暗光場景,左邊是個黑臉,右邊人臉的亮度就比較正常;第三組是白天逆光場景,這種場景的背景很亮,普通 AE 給的曝光就會不足,人臉會顯得非常黑,而使用 FaceAE 優化過的相機效果就會比較亮,五官也能看清晰;第四組是室內側光場景,這種場景照出來很容易陰陽臉,可以看到左邊圖上一半的臉都是黑的,眼睛都看不見在哪兒,而右邊雖然不可避免還是存在陰陽臉,但畫面更亮,五官都能看清了。

以上是我們僅僅靠相機採集優化的效果,在沒有開啟任何美顏演算法的情況下,就能達到比較理想的畫質效果。而且,由於 FaceAE 呼叫的都是系統底層的能力,沒有使用演算法,不會引入額外的效能開銷。當然,開啟美顏之後,還能再錦上添花。

前面提到會議場景的技術溢位,「相機採集優化」也是如此,它對於其他非會議場景也有非常廣泛的應用。在視訊社交場景中,參與平權聊天的大部分使用者都是非專業主播,大家就是臨時上線聊天,不會特別準備好的光源或打光裝置;在直播連麥場景,主播是專業武裝的,但連麥的觀眾或場外嘉賓往往是非專業主播,也不大會考慮光線的問題;在互動課堂場景,老師端一般有較好的開播條件,但學生端的條件就會差一些;還有一個是我們最近發現的很有趣的場景,也是我們遇到的一個真實場景——健身小班課,它和普通的“互動課堂”場景有點像又有些不一樣,雖然健身老師可以算得上是“專業主播”,但傳統主播用的打光裝置沒辦法照顧到整體授課的場景,圖上的瑜伽老師在客廳開播,客廳連著陽臺,形成了一個大逆光場景,導致瑜伽老師的臉完全是黑的,影響與學員的互動效果。

螢幕共享的優化

第二個話題是「螢幕共享的優化」。

螢幕共享是視訊會議場景最常用的功能之一,使用者對於共享文字/PPT 的要求一般是高清晰度,對於共享視訊內容的要求一般是高流暢。我們比較容易做到根據共享內容的檔案屬性來決定是“清晰度優先”還是“流暢度優先”的編碼策略,比如共享 PPT 時自動切換為“清晰模式”,共享視訊時自動切換為“流暢模式”,但這樣設計會遇到一些問題:如果使用者的 PPT 裡嵌入了一段視訊,在播放這段視訊時理應追求“流暢模式”;如果使用者視訊其實是一段 PPT 的教學錄屏,裡面有大量的時間在播放靜止的文字和畫面,這時候理應是“清晰模式”。也就是說,我們共享的內容,它是是靜止的還是運動的,是由使用者決定的,而不是程式可以決定的;我們也不可能要求使用者在共享的過程中手動地去不停選擇切換當前的編碼模式,這樣會嚴重影響使用者體驗,而且使用者很可能會忘記切換。

業務層面不能通過使用者的輸入來解決問題,這個挑戰就落到了 RTC 上,RTC 要如何幫助使用者及時調整最佳模式呢?

我們研究出了一個“智慧編碼模式”,在螢幕共享的過程中,讓 RTC 自動識別使用者傳入的視訊內容型別,並且不斷自動調整最佳的策略。

我們來看一段視訊。視訊裡的一個參會人在共享螢幕,一開始,他在瀏覽網頁,共享畫面是靜止的圖片和文字,所以解析度非常高,幀率和位元速率非常低;然後參會人打開了一個視訊網站,共享內容變成了一段視訊,對應的幀率和位元速率慢慢地爬升,為了平衡效能,對應的解析度也在慢慢地下降,幀率最後爬升到了 30 幀;然後他又換了一段視訊播放,這段視訊只有中間部分在動,運動部分佔據畫面比較小,所以幀率沒降,但位元速率慢慢降低了;最後,他又回到了最初的網頁,幀率和位元速率逐漸下降,而解析度又慢慢地回升到了高清模式。這段視訊演示了在共享內容型別切換時“智慧編碼模式”的自動調整策略。

“智慧編碼模式”帶來的一個重要收益就是線上平均解析度的提升。一些共享內容原來被系統認為是“視訊”而採用了“流暢模式”,現在被演算法糾正成了“高清模式”(實際上視訊會議場景共享靜態內容的概率更大),線上平均解析度有了翻倍的提升。同時,因為系統永遠選擇最合適的編碼策略,因此線上螢幕共享場景下的整體 CPU 消耗降低了 20%。

我們來看看「螢幕共享」在非會議場景的應用。過去我們認為「螢幕共享」只應用在會議場景,隨著著“線下活動線上化”的趨勢,「螢幕共享」在會議以外的應用也越來越多了。線上教育就不多說了,它本來就是視訊會議場景的一個子類,除了普通的“螢幕共享”以外,線上教育還有一個“雲端錄屏”的需求——把軟體的 UI 一起錄下來回看或作為直播對外分享,本質上這也是一種特殊的“螢幕共享”——通過在雲端模擬一個虛擬學生上課,在雲端開啟應用軟體的介面來進行「螢幕共享」。在遠端協助場景,通過「螢幕共享」,子女可以告訴不會使用手機或智慧電視的父母如何操作,甚至直接遠端操作;在 VR 直播教學場景中,老師通過 VR 裝置在虛擬空間進行操作,學生通過 VR 裝置跟隨老師的視角觀看和學習,沉浸式、實時互動式的螢幕共享可以極大地提升教學效果。

多宮格檢視體驗的提升

第三個話題是「如何提升多宮格檢視的體驗」。

多宮格檢視也是視訊會議中的基本需求,它讓儘可能多參會者的視訊被播放出來,可以提升參會互動性,但也非常容易引起客戶端效能和頻寬的不足,因為你要訂閱的視訊流變多了。對此,RTC 一般會提供動態“弱網降級“和“效能降級”,但在視訊會議中,一般的弱網降級和效能降級是不夠的。

這個場景主要有三個特點:一是每個使用者都可以自由選擇自己喜歡的檢視佈局;二是不同佈局對應不同階梯的解析度;三是任何一路流都可能會面臨從高到低各種檔位的解析度的訂閱請求。目前行業裡 RTC 普遍支援「大小流」,也就是兩檔解析度,但兩檔解析度在視訊會議中遠不夠用,而增加檔位又會大大增加效能開銷,如何既能靈活支撐使用者自定義會議檢視佈局,又能兼顧裝置和頻寬效能?

針對這個場景,我們設計了「10 級檔位的 Simulcast」。既然兩檔解析度不夠,我們就來增加檔位嘛。這裡的主要難點在於,對於釋出者來說,他相當於要做 10 路視訊流的編碼,這對於釋出者的效能消耗是巨大的,絕大部分裝置的效能是不夠的。所以在實現的時候,我們會對檔位進行聚合分組,最後分成四檔,分組的原則是“按解析度訂閱人數的權重排序,儘量照顧更多人的體驗需求”。也就是說,我們優先選擇訂閱人數多的解析度進行編碼,訂閱人數少的排在後面。如果裝置效能跑滿了,檔位不夠分,就歸併到最接近的已編碼的解析度檔位。除此以外,動態弱網降級和動態效能降級也會與 Simulcast 結合,如果訂閱端訂閱太多流或者效能不足了,那麼就自動降到下一個檔位。相比大小流兩個檔位, 多檔位的 Simulcast 降級會比較平滑,即不是直接從 1080P 降到 90P 這樣的低解析度,而是一檔一檔地逐檔降級,直到降到一個最合適的檔位。

我們來看「Simulcast」的線上資料表現。「Simulcast」的主要作用是提升實時畫面的清晰度,尤其是多宮格檢視的清晰度。我們看到,2*2 宮格的清晰度從 360P 提升到了 540P,3*3 宮格的清晰度從 180P 提升到了 270P,一些中高階手機全屏模式下的清晰度從 360P 提升到了 720P,線上平均解析度提升了 16%。在提升清晰度的同時,我們也要平衡一些其他的指標。在實時性方面,端到端延時與原先水平保持持平;在流暢性方面,視訊百秒卡頓率也沒有下降。「Simulcast」的最大挑戰是給釋出端帶來的效能開銷,但我們看到效能開銷的上漲是非常輕微的,基本不影響釋出端的效能。

我們再看一下「Simulcast」在會議以外場景的應用。比如連麥場景,隨著連麥的人數越來越多,“多檢視佈局”的需求也應運而生,在社交場景,我們叫它“動態麥位”。在“萬物互聯”的物聯網生態中,各種型別的裝置都在使用 RTC,小到手錶,大到智慧電視,中間還有手機、Pad、電腦,電視機也有各種尺寸,想象一下,如果我們用手機和父母、小孩通話,父母使用電視,小孩使用手錶,如果讓電視和手錶訂閱相同解析度的同一路視訊是極不合適的,這個場景也適合「Simulcast」方案。

實現會控的關鍵技術

第四個話題是關於「如何做好會控」,對於 RTC 來說,做好會控的關鍵是什麼?

在會控中,和 RTC 相關的一個難點是“音視訊狀態和使用者狀態的一致性”的問題。比如一個使用者在系統上顯示是麥克風開啟的狀態,如果狀態是錯誤的,實際上他是無法上麥的。反過來,系統上顯示他已經閉麥了,但實際上他還在上麥,如果他說了一些不希望被會上其他參會者聽到的話或者聲音,就會涉及到嚴重的隱私洩漏問題。還有一個難點是“使用者狀態變化的及時性”,比如主持人要讓某個人閉麥,當他操作閉麥該人的動作之後,需要能夠馬上、真正地把麥閉掉,一旦及時性做得不好,不僅讓參會人的體驗不好,還可能造成主持人無法及時控場的問題。

這兩個問題的關鍵在於“信令的可靠性”,我們如何保證信令必達的同時,還擁有極低的延時,並且與音視訊狀態同步?

我們的解決方案是,讓信令複用 RTC 音視訊流的傳輸鏈路與弱網對抗策略,確保音視訊和信令的到達率相同,保證音視訊狀態的一致。

我們為信令定義了幾個指標,一個是 200ms 到達率,一個是總到達率。總到達率我們做到了 100%——要確保“訊息必達”,這也是信令的基本要求。而且,我們還要做到“低延遲”的“訊息必達”,這就要求信令是在一定的時間範圍內到達的,否則即使信令到達了,也會失去一部分的意義。我們選擇了「200ms 到達率」這個指標,目前這個指標的線上資料表現是 98.6%,也就是說,在 98.6% 的情況下,信令可以在 200ms 之內到達目的地。

我們再看一下延時方面的指標。目前,「端到端平均延時」指標表現是 51 ms,但「平均延時」這個這個指標其實比較寬鬆,我們會看一個更嚴格的指標,就是「端到端延時九十分位值」,簡稱「PCT 90」,我們線上 PCT 90 的指標表現是 117ms,也就是說,線上 90% 的使用者的端到端訊息能夠在 117ms 以內到達。能夠做到這樣的到達率和延時,主要就是因為我們的信令複用了 RTC 的傳輸鏈路。複用 RTC 傳輸鏈路還有一個很重要的好處 ,就是保證音視訊資料和信令資料的延時和到達率是一致的,這樣,用 RTC 信令來實現會控就不會出現狀態不一致的問題,因為極端弱網是不可避免的,最極端的弱網就是斷網,我們現在說到達率是 100%,前提是網路還是通的,如果斷網了,任何信令都不可能傳輸了,而且資料上還無法統計到。但是,如果音視訊和信令採用同一條鏈路,假設真的斷網了,音視訊傳輸和信令傳輸都無法到達,要斷一起斷。這樣的話,不管是什麼樣的網路情況,音視訊狀態和使用者狀態永遠都是一致的,我們做會控的目的也就達到了。

我們打磨的「實時信令」在其他領域也有廣泛的應用。我們剛剛說到會控,其實在很多 RTC 領域中,多多少少都存在一些會控的邏輯,像互娛社交場景中也會存在房間管理,如果一些主播、連麥嘉賓、上麥觀眾說了一些不合適的話,或者做了一些不合適的行為,管理員就需要制止,簡單點就是禁言或踢人,如果制止不成功或不夠及時,可能會引起更嚴重的問題。除了會控以外,「實時信令」也可以用到一些新的玩法中。這裡舉一個「一起看抖音」的場景,抖音上就有這個功能,兩個朋友之間可以連麥一起刷視訊,“主態”刷到哪兒“客態”的視訊進度就跟到哪兒,兩邊的視訊延時低於 100ms,而實現視訊滑動狀態主客態同步業務邏輯的技術就是「實時信令」。

Web 端實現複雜演算法的新解

最後一個話題是關於「Web 端實現複雜演算法的新解」。我們先看一下 Web 端有哪些效能消耗的“殺手”。我們知道,RTC 的編碼是很耗效能的,但和美顏、特效、虛擬背景比起來還是小巫見大巫。這些功能在視訊會議場景中已經成為“剛需”,幾乎每個居家辦公的參會人都會使用,我們要如何既保證客戶端裝置效能,又達到媲美 Native 的效果呢?

我們做了一系列的思考和嘗試。

第一種是業內的普遍做法——在 Web 本地載入這些演算法。Web 本地執行演算法對於裝置 CPU 的消耗都非常大,而且由於 Web 瀏覽器本身存在效能瓶頸,哪怕裝置再好,在 Web 端做特效的效果都可能打折扣,一些複雜的特效甚至可能無法執行。瀏覽器的相容性也是一個問題。還有一個問題是比較容易被忽略的,由於 Web 會把程式碼和模組下載到本地執行,如果在本地載入特效演算法就會增加包體,支援的演算法越多,包體就越大,它會影響頁面載入速度,演算法的豐富性也會受到限制。

我們也研究了業務端是如何解決這個問題的。行業裡,業務端會使用虛擬攝像頭的方案。虛擬攝像頭自帶美顏功能,Web 通過虛擬攝像頭來採集視訊,這個採集的視訊已經經過了特效處理,因此瀏覽器不再需要有額外的效能消耗。但這種操作有個問題——使用者必須安裝虛擬攝像頭,這和 Web 端追求“免安裝即用”的便捷性理念是違背的。一般會採取這種方案的使用者是專業主播,他們本來就在電腦中安裝了很多美顏、虛擬攝像頭的軟體,可能是因為臨時換一個網頁開播的平臺做直播所以使用虛擬攝像頭,像參加面試、臨時會議這種場景,普通人可能都不知道有“虛擬攝像頭”,因此這種方案的適用性是比較侷限的。

通過結合 RTC 的優勢,我們探索出一種新的解法——邊緣渲染。邊緣渲染的原理是,當釋出者在本地採集了視訊之後,不是直接向訂閱端傳送流,而是先發送到 RTC 邊緣,在邊緣進行雲端美顏和渲染,再發送給對端,同時也發回給釋出端用於本地預覽。這對“邊緣”的要求很高,邊緣要儘可能多,才能在邊緣就快速把特效解決了。「邊緣渲染」的好處是對本端幾乎沒有額外的效能消耗,完全不依賴本地裝置算力,可以執行更酷炫、更復雜的演算法。大家可能會擔心「邊緣渲染」會增加發布者本地預覽以及傳送到對端的延時,我們統計了一下線上資料,開啟邊緣渲染只比普通音視訊通話增加了 30ms 的延時,本地預覽延遲低於 200 ms,實時幀率可以達到 30+ fps。

我們來看一下實際效果。視訊左邊是未渲染的預覽畫面,右邊是經邊緣渲染之後再返回本地的預覽效果,延遲控制在了 200ms 以內,輕微的延遲基本不會影響正常的發言和交流。同時,像這樣的虛擬頭套是一個比較消耗效能的演算法,「邊緣渲染」的方案突破了 Web 執行精細特效演算法的效能瓶頸。

從視訊會議場景孵化出的「邊緣渲染」能力也可以用到其他應用場景。比如在一些美妝、電商場景,可以支援使用者免下載軟體,通過雲渲染的方式即可體驗試妝、試戴效果。像圖上的一些萬聖節特效、魔法變身特效、老年特效都是一些比較耗算力的特效演算法,通過雲端渲染,在低端機上也可以方便地實現。