視頻會(huì)議場(chǎng)景一直被認(rèn)為是 RTC 最具挑戰(zhàn)性的場(chǎng)景，一方面，它對(duì)抗弱網(wǎng)、低端機(jī)適配、降噪、多人上麥等都有極高的要求，對(duì) Web 端的要求也遠(yuǎn)高于其他場(chǎng)景；另一方面，有很多孵化自會(huì)議場(chǎng)景的技術(shù)能力最終都被復(fù)制到了其他場(chǎng)景。

RTC 在會(huì)議場(chǎng)景的獨(dú)特挑戰(zhàn)

為什么說“視頻會(huì)議”場(chǎng)景對(duì)于 RTC 的技術(shù)挑戰(zhàn)最大？相比于其他行業(yè)和場(chǎng)景，“視頻會(huì)議”中的 RTC 到底獨(dú)特在哪？

首先，會(huì)議場(chǎng)景的需求是更為復(fù)雜的，這里舉 4 個(gè)例子。

「自由開麥」

在視頻會(huì)議中，每一個(gè)參會(huì)方都可以自由選擇是否打開自己的麥克風(fēng)和攝像頭，這是視頻會(huì)議非常基礎(chǔ)的功能，但隨著參會(huì)人數(shù)的增加，技術(shù)實(shí)現(xiàn)會(huì)越發(fā)復(fù)雜。行業(yè)內(nèi) RTC 一般可以實(shí)現(xiàn)五十到上百人的自由開麥，超過了這個(gè)人數(shù)之后就需要主持人來控制麥位。飛書會(huì)議要求我們支持 1000 個(gè)參會(huì)方，如果 RTC 支持自由上麥的人數(shù)低于 1000，飛書會(huì)議的用戶使用起來就會(huì)非常不方便（雖然所有參會(huì)人同時(shí)開麥的極端情況比較少見，但是業(yè)務(wù)的需求是希望主持人不要過多“干預(yù)”會(huì)議——不斷地控制參會(huì)人上麥、下麥，把發(fā)言能力分配給想發(fā)言的人）。假設(shè)一場(chǎng)會(huì)議里有 1000 個(gè)參會(huì)方，但只有 50 個(gè)麥位可以發(fā)言，主持人就要把想說話的參會(huì)人不停地“挪”到這 50 個(gè)麥位之中。為了讓主持人知道誰(shuí)想發(fā)言，還需要引入一些溝通機(jī)制，整體操作成本非常高。RTC 為什么會(huì)限制擁有上麥能力的用戶數(shù)量？如果不限制可以上麥用戶的數(shù)量，發(fā)布/訂閱流模型的算法復(fù)雜度就是 O（n^2），即，如果有 1000 人參會(huì)，就會(huì)產(chǎn)生 100 萬(wàn) 音視頻流發(fā)布/訂閱關(guān)系。短時(shí)間高頻的上下麥操作會(huì)造成服務(wù)端信令風(fēng)暴，所以上麥人數(shù)才需要加以限制。可是現(xiàn)實(shí)中，一些大型會(huì)議的規(guī)模往往會(huì)超過 1000 人，甚至達(dá)到幾千、上萬(wàn)，我們不該因?yàn)榧夹g(shù)的限制而犧牲用戶的體驗(yàn)。

「自由布局」

視頻會(huì)議一般會(huì)提供多種視圖布局類型供參會(huì)方選擇，從 11 全屏，到 22 四宮格，33 九宮格，到 77 四十九宮格……這還只是普通的宮格，還會(huì)有一些其他布局，比如演講者模式、側(cè)邊欄模式等。畫面布局類型的豐富讓每個(gè)參會(huì)者都可以自己選擇自己喜歡的布局，但這樣一來，同一個(gè)會(huì)上，有開四宮格的，有開九宮格的，有開演講者模式的，視頻發(fā)布者就需要決策到底發(fā)布什么樣的分辨率。如果發(fā)布的分辨率過大，對(duì)于選擇多宮格的訂閱方來說，分辨率就過剩了，同時(shí)還造成了極大的下行帶寬和設(shè)備性能壓力——試想一下，一個(gè)訂閱方同時(shí)拉了 49 路 1080P 的視頻，什么樣的神仙設(shè)備和帶寬都扛不住；如果發(fā)布的分辨率過小，對(duì)于全屏或者演講者模式這樣的大窗口來說，清晰度就會(huì)不足，用戶體驗(yàn)會(huì)受到影響。嚴(yán)格來說，每一種布局都應(yīng)該有一個(gè)最合適的分辨率。在多人會(huì)議中，如何在有限的帶寬與設(shè)備性能下，盡量提供靈活多樣的畫面布局，是一個(gè)很大的挑戰(zhàn)。

「屏幕共享」

這個(gè)功能大家比較容易理解，它的挑戰(zhàn)在于，屏幕共享雖然也是視頻流，但是它的視頻畫面特點(diǎn)和我們攝像頭拍攝的視頻畫面特點(diǎn)是不一樣的。簡(jiǎn)單來說，屏幕共享對(duì)畫面的要求更清晰，要能看清楚很小的文字，但是對(duì)于幀率的要求并不高。對(duì)于編碼器來說，需要決策什么時(shí)候編高幀率的視頻，什么時(shí)候編低幀率的視頻，這是關(guān)鍵。

「Web 入會(huì)」

很多時(shí)候，視頻會(huì)議軟件的用戶是“臨時(shí)用戶”，比如用視頻會(huì)議去參加一場(chǎng)面試，或者是合作伙伴用你們公司的會(huì)議軟件來參加一場(chǎng)會(huì)議…這些“臨時(shí)用戶”可能并不希望去安裝一個(gè)會(huì)議 App，用 Web 入會(huì)就是一個(gè)非常好的選擇。但是 Web 對(duì)音視頻有很多限制，而對(duì)視頻會(huì)議的需求和體驗(yàn)的要求一點(diǎn)都沒少，怎么才能把 Web 入會(huì)的體驗(yàn)盡量追上 Native 的體驗(yàn)？

除了業(yè)務(wù)需求更加復(fù)雜以外，視頻會(huì)議場(chǎng)景所面臨的環(huán)境也更為極端。

過去，開視頻會(huì)議都是在專業(yè)的會(huì)議室里開，有很多專業(yè)的會(huì)議硬件設(shè)備來支撐會(huì)議體驗(yàn)，環(huán)境是相對(duì)比較好的。但現(xiàn)在，開會(huì)環(huán)境早已不限于會(huì)議室了，會(huì)議環(huán)境的多樣性讓 RTC 面臨了很多新的挑戰(zhàn)。這幾年，疫情讓我們居家辦公的時(shí)間更多了，在家里開視頻會(huì)議成為了很普遍的場(chǎng)景；一些經(jīng)常出差的人——他們往往也是會(huì)比較多的人——在路上、車上、高鐵上甚至飛機(jī)上通過手機(jī)參加視頻會(huì)議也非常普遍。

會(huì)議環(huán)境多樣性為 RTC 帶來的挑戰(zhàn)主要可以分為以下四大類：

首先是極端弱網(wǎng)，俗稱“用戶網(wǎng)絡(luò)差”。這種情況非常常見，尤其是不在公司會(huì)議室里開會(huì)，弱網(wǎng)情況更常見；

其次是弱設(shè)備，也就是“設(shè)備性能不足”。如果參會(huì)設(shè)備不是專業(yè)視頻會(huì)議硬件，就會(huì)承擔(dān)更多的性能壓力，尤其當(dāng)參會(huì)人開啟美顏或者虛擬背景這樣高消耗的功能之后，原本可以開會(huì)的設(shè)備也會(huì)出現(xiàn)性能不足。現(xiàn)在在視頻會(huì)議中使用虛擬背景是一個(gè)非常高頻的功能，大家看我現(xiàn)在視頻的背景就是一個(gè)虛擬背景。

再者就是會(huì)議場(chǎng)景的噪聲類型會(huì)更多，除了會(huì)議場(chǎng)景常見的鍵盤聲之外，如果你不是在會(huì)議室開會(huì)，就會(huì)伴隨各種各樣的噪聲：空調(diào)的聲音、開關(guān)門的聲音、隔壁裝修的聲音、附近人說話的聲音、小孩的哭鬧聲，室外的喧囂聲……

最后一個(gè)挑戰(zhàn)是光線差。離開專業(yè)會(huì)議室的環(huán)境之后，可能會(huì)面臨嚴(yán)重的光線不足、背光等問題——本來家里的光線布局就不是為了居家開會(huì)所設(shè)計(jì)的，更不要說在戶外或者交通工具上開會(huì)了。

從技術(shù)角度看，RTC 技術(shù)最初就是從視頻會(huì)議中抽象剝離出來的，后來逐漸應(yīng)用到會(huì)議以外的領(lǐng)域，所以很多 RTC 的新場(chǎng)景其實(shí)就是從視頻會(huì)議中遷移出來的。換句話說，RTC 在視頻會(huì)議場(chǎng)景的「獨(dú)特性」，其實(shí)也可以認(rèn)為是一種「領(lǐng)先性」。

從最近幾年的行業(yè)發(fā)展來看，不斷有從會(huì)議場(chǎng)景技術(shù)溢出到其他行業(yè)的案例。之前特別熱門的「大班小組課」，其實(shí)就是會(huì)議中的「分組會(huì)議 Breakout Room」。再比如現(xiàn)在很火的 「3D 空間音效」，其實(shí)最初的應(yīng)用是高級(jí)視頻會(huì)議產(chǎn)品中的「聽聲辨位」，HP 2005 年發(fā)布的 Halo 就支持這個(gè)功能。

最后說說「千方會(huì)議」。我們?cè)谌ツ?6 月已經(jīng)對(duì)外介紹了我們做的“千人上麥”能力，在今年 2 月份正式對(duì)外發(fā)布了這個(gè)功能。當(dāng)時(shí)很多朋友不理解我們?yōu)槭裁匆瞿敲创蟮纳消湶l(fā)，實(shí)際上是因?yàn)?#xff0c;我們看到不僅視頻會(huì)議有這個(gè)需求，其他場(chǎng)景也陸續(xù)出現(xiàn)了這個(gè)需求，像在線教育大班課中的齊聲朗讀或者搶答，大型吃雞游戲中的世界語(yǔ)音，還有現(xiàn)在正在發(fā)生的大型 VR 社交，這些場(chǎng)景需要自由上麥的人數(shù)很容易突破幾百甚至上千。既然「千方會(huì)議」可以支持大型視頻會(huì)議，何不做成 RTC 的標(biāo)準(zhǔn)能力，來解鎖各行各業(yè)中“自由上麥”人數(shù)的瓶頸，發(fā)揮更大的價(jià)值呢？順便提一句，目前我們還在進(jìn)一步突破上麥人數(shù)上限，實(shí)現(xiàn)「萬(wàn)方會(huì)議」甚至更多。

「千方會(huì)議」過去已經(jīng)和大家介紹過了，今天不再重點(diǎn)展開。接下來和大家分享視頻會(huì)議對(duì) RTC 的幾個(gè)新的挑戰(zhàn)和我們的思考實(shí)踐。

復(fù)雜光線下的視頻體驗(yàn)

前面提到，很多用戶入會(huì)時(shí)所處的位置可能并沒有很好的光照條件，比如晚間的戶外，光線會(huì)嚴(yán)重不足；比如在室內(nèi)，如果光源的位置不佳，會(huì)形成逆光或者側(cè)光。惡劣的光照條件會(huì)嚴(yán)重影響視頻體驗(yàn)，但我們一般人開會(huì)也不會(huì)像專業(yè)主播一樣準(zhǔn)備專用的打光設(shè)備，因此，一旦光線不好，拍攝效果就會(huì)差，而一旦拍攝基礎(chǔ)效果差，僅僅靠視頻后處理技術(shù)是沒有辦法很好地解決視頻體驗(yàn)問題的。

為了解決這些問題，我們引入了一系列的相機(jī)技術(shù)，包括自動(dòng)對(duì)焦、自動(dòng)曝光這些比較基本的相機(jī)技術(shù)。RTC 場(chǎng)景和其他場(chǎng)景有個(gè)不一樣的地方，畫面中一般都是人像占據(jù)主體，而當(dāng)畫面中人像占據(jù)主體時(shí)，如果不做特別處理，由于攝像頭本身是“平均測(cè)光”的，當(dāng)人像處于逆光環(huán)境時(shí)，由于背景很亮，會(huì)導(dǎo)致曝光不足，人臉會(huì)顯得過暗。因此，我們?cè)?AE 的基礎(chǔ)上又增加了人臉檢測(cè)算法，即 FaceAE，當(dāng)檢測(cè)到人臉時(shí)，把“平均測(cè)光”優(yōu)化為“根據(jù)人臉檢測(cè)結(jié)果”來做曝光處理，解決畫面過曝、欠曝的問題。為了實(shí)現(xiàn)最佳效果，我們與國(guó)內(nèi)外很多手機(jī)和芯片廠商保持良好的合作，把硬件的相機(jī)功能和我們自研的算法進(jìn)行深度結(jié)合，讓每一款設(shè)備都達(dá)到最佳性能。目前我們已經(jīng)對(duì)線上 18000+ 款機(jī)型進(jìn)行了適配，覆蓋低中端各類機(jī)型。

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

以上是我們僅僅靠相機(jī)采集優(yōu)化的效果，在沒有開啟任何美顏算法的情況下，就能達(dá)到比較理想的畫質(zhì)效果。而且，由于 FaceAE 調(diào)用的都是系統(tǒng)底層的能力，沒有使用算法，不會(huì)引入額外的性能開銷。當(dāng)然，開啟美顏之后，還能再錦上添花。

前面提到會(huì)議場(chǎng)景的技術(shù)溢出，「相機(jī)采集優(yōu)化」也是如此，它對(duì)于其他非會(huì)議場(chǎng)景也有非常廣泛的應(yīng)用。在視頻社交場(chǎng)景中，參與平權(quán)聊天的大部分用戶都是非專業(yè)主播，大家就是臨時(shí)上線聊天，不會(huì)特別準(zhǔn)備好的光源或打光設(shè)備；在直播連麥場(chǎng)景，主播是專業(yè)武裝的，但連麥的觀眾或場(chǎng)外嘉賓往往是非專業(yè)主播，也不大會(huì)考慮光線的問題；在互動(dòng)課堂場(chǎng)景，老師端一般有較好的開播條件，但學(xué)生端的條件就會(huì)差一些；還有一個(gè)是我們最近發(fā)現(xiàn)的很有趣的場(chǎng)景，也是我們遇到的一個(gè)真實(shí)場(chǎng)景——健身小班課，它和普通的“互動(dòng)課堂”場(chǎng)景有點(diǎn)像又有些不一樣，雖然健身老師可以算得上是“專業(yè)主播”，但傳統(tǒng)主播用的打光設(shè)備沒辦法照顧到整體授課的場(chǎng)景，圖上的瑜伽老師在客廳開播，客廳連著陽(yáng)臺(tái)，形成了一個(gè)大逆光場(chǎng)景，導(dǎo)致瑜伽老師的臉完全是黑的，影響與學(xué)員的互動(dòng)效果。

屏幕共享的優(yōu)化

屏幕共享是視頻會(huì)議場(chǎng)景最常用的功能之一，用戶對(duì)于共享文字/PPT 的要求一般是高清晰度，對(duì)于共享視頻內(nèi)容的要求一般是高流暢。我們比較容易做到根據(jù)共享內(nèi)容的文件屬性來決定是“清晰度優(yōu)先”還是“流暢度優(yōu)先”的編碼策略，比如共享 PPT 時(shí)自動(dòng)切換為“清晰模式”，共享視頻時(shí)自動(dòng)切換為“流暢模式”，但這樣設(shè)計(jì)會(huì)遇到一些問題：如果用戶的 PPT 里嵌入了一段視頻，在播放這段視頻時(shí)理應(yīng)追求“流暢模式”；如果用戶視頻其實(shí)是一段 PPT 的教學(xué)錄屏，里面有大量的時(shí)間在播放靜止的文字和畫面，這時(shí)候理應(yīng)是“清晰模式”。也就是說，我們共享的內(nèi)容，它是是靜止的還是運(yùn)動(dòng)的，是由用戶決定的，而不是程序可以決定的；我們也不可能要求用戶在共享的過程中手動(dòng)地去不停選擇切換當(dāng)前的編碼模式，這樣會(huì)嚴(yán)重影響用戶體驗(yàn)，而且用戶很可能會(huì)忘記切換。

業(yè)務(wù)層面不能通過用戶的輸入來解決問題，這個(gè)挑戰(zhàn)就落到了 RTC 上，RTC 要如何幫助用戶及時(shí)調(diào)整最佳模式呢？

我們研究出了一個(gè)“智能編碼模式”，在屏幕共享的過程中，讓 RTC 自動(dòng)識(shí)別用戶傳入的視頻內(nèi)容類型，并且不斷自動(dòng)調(diào)整最佳的策略。

我們來看一段視頻。視頻里的一個(gè)參會(huì)人在共享屏幕，一開始，他在瀏覽網(wǎng)頁(yè)，共享畫面是靜止的圖片和文字，所以分辨率非常高，幀率和碼率非常低；然后參會(huì)人打開了一個(gè)視頻網(wǎng)站，共享內(nèi)容變成了一段視頻，對(duì)應(yīng)的幀率和碼率慢慢地爬升，為了平衡性能，對(duì)應(yīng)的分辨率也在慢慢地下降，幀率最后爬升到了 30 幀；然后他又換了一段視頻播放，這段視頻只有中間部分在動(dòng)，運(yùn)動(dòng)部分占據(jù)畫面比較小，所以幀率沒降，但碼率慢慢降低了；最后，他又回到了最初的網(wǎng)頁(yè)，幀率和碼率逐漸下降，而分辨率又慢慢地回升到了高清模式。這段視頻演示了在共享內(nèi)容類型切換時(shí)“智能編碼模式”的自動(dòng)調(diào)整策略。

“智能編碼模式”帶來的一個(gè)重要收益就是線上平均分辨率的提升。一些共享內(nèi)容原來被系統(tǒng)認(rèn)為是“視頻”而采用了“流暢模式”，現(xiàn)在被算法糾正成了“高清模式”（實(shí)際上視頻會(huì)議場(chǎng)景共享靜態(tài)內(nèi)容的概率更大），線上平均分辨率有了翻倍的提升。同時(shí)，因?yàn)橄到y(tǒng)永遠(yuǎn)選擇最合適的編碼策略，因此線上屏幕共享場(chǎng)景下的整體 CPU 消耗降低了 20%。

我們來看看「屏幕共享」在非會(huì)議場(chǎng)景的應(yīng)用。過去我們認(rèn)為「屏幕共享」只應(yīng)用在會(huì)議場(chǎng)景，隨著著“線下活動(dòng)線上化”的趨勢(shì)，「屏幕共享」在會(huì)議以外的應(yīng)用也越來越多了。在線教育就不多說了，它本來就是視頻會(huì)議場(chǎng)景的一個(gè)子類，除了普通的“屏幕共享”以外，在線教育還有一個(gè)“云端錄屏”的需求——把軟件的 UI 一起錄下來回看或作為直播對(duì)外分享，本質(zhì)上這也是一種特殊的“屏幕共享”——通過在云端模擬一個(gè)虛擬學(xué)生上課，在云端打開應(yīng)用軟件的界面來進(jìn)行「屏幕共享」。在遠(yuǎn)程協(xié)助場(chǎng)景，通過「屏幕共享」，子女可以告訴不會(huì)使用手機(jī)或智能電視的父母如何操作，甚至直接遠(yuǎn)程操作；在 VR 直播教學(xué)場(chǎng)景中，老師通過 VR 設(shè)備在虛擬空間進(jìn)行操作，學(xué)生通過 VR 設(shè)備跟隨老師的視角觀看和學(xué)習(xí)，沉浸式、實(shí)時(shí)互動(dòng)式的屏幕共享可以極大地提升教學(xué)效果。

多宮格視圖體驗(yàn)的提升

多宮格視圖也是視頻會(huì)議中的基本需求，它讓盡可能多參會(huì)者的視頻被播放出來，可以提升參會(huì)互動(dòng)性，但也非常容易引起客戶端性能和帶寬的不足，因?yàn)槟阋嗛喌囊曨l流變多了。對(duì)此，RTC 一般會(huì)提供動(dòng)態(tài)“弱網(wǎng)降級(jí)“和“性能降級(jí)”，但在視頻會(huì)議中，一般的弱網(wǎng)降級(jí)和性能降級(jí)是不夠的。

這個(gè)場(chǎng)景主要有三個(gè)特點(diǎn)：

一是每個(gè)用戶都可以自由選擇自己喜歡的視圖布局；

二是不同布局對(duì)應(yīng)不同階梯的分辨率；

三是任何一路流都可能會(huì)面臨從高到低各種檔位的分辨率的訂閱請(qǐng)求。

目前行業(yè)里 RTC 普遍支持「大小流」，也就是兩檔分辨率，但兩檔分辨率在視頻會(huì)議中遠(yuǎn)不夠用，而增加檔位又會(huì)大大增加性能開銷，如何既能靈活支撐用戶自定義會(huì)議視圖布局，又能兼顧設(shè)備和帶寬性能？

針對(duì)這個(gè)場(chǎng)景，我們?cè)O(shè)計(jì)了「10 級(jí)檔位的 Simulcast」。既然兩檔分辨率不夠，我們就來增加檔位嘛。

這里的主要難點(diǎn)在于，對(duì)于發(fā)布者來說，他相當(dāng)于要做 10 路視頻流的編碼，這對(duì)于發(fā)布者的性能消耗是巨大的，絕大部分設(shè)備的性能是不夠的。所以在實(shí)現(xiàn)的時(shí)候，我們會(huì)對(duì)檔位進(jìn)行聚合分組，最后分成四檔，分組的原則是“按分辨率訂閱人數(shù)的權(quán)重排序，盡量照顧更多人的體驗(yàn)需求”。也就是說，我們優(yōu)先選擇訂閱人數(shù)多的分辨率進(jìn)行編碼，訂閱人數(shù)少的排在后面。如果設(shè)備性能跑滿了，檔位不夠分，就歸并到最接近的已編碼的分辨率檔位。

除此以外，動(dòng)態(tài)弱網(wǎng)降級(jí)和動(dòng)態(tài)性能降級(jí)也會(huì)與 Simulcast 結(jié)合，如果訂閱端訂閱太多流或者性能不足了，那么就自動(dòng)降到下一個(gè)檔位。相比大小流兩個(gè)檔位， 多檔位的 Simulcast 降級(jí)會(huì)比較平滑，即不是直接從 1080P 降到 90P 這樣的低分辨率，而是一檔一檔地逐檔降級(jí)，直到降到一個(gè)最合適的檔位。

我們來看「Simulcast」的線上數(shù)據(jù)表現(xiàn)。「Simulcast」的主要作用是提升實(shí)時(shí)畫面的清晰度，尤其是多宮格視圖的清晰度。

我們看到，22 宮格的清晰度從 360P 提升到了 540P，33 宮格的清晰度從 180P 提升到了 270P，一些中高端手機(jī)全屏模式下的清晰度從 360P 提升到了 720P，線上平均分辨率提升了 16%。

在提升清晰度的同時(shí)，我們也要平衡一些其他的指標(biāo)。在實(shí)時(shí)性方面，端到端延時(shí)與原先水平保持持平；在流暢性方面，視頻百秒卡頓率也沒有下降。「Simulcast」的最大挑戰(zhàn)是給發(fā)布端帶來的性能開銷，但我們看到性能開銷的上漲是非常輕微的，基本不影響發(fā)布端的性能。

我們?cè)倏匆幌隆窼imulcast」在會(huì)議以外場(chǎng)景的應(yīng)用。比如連麥場(chǎng)景，隨著連麥的人數(shù)越來越多，“多視圖布局”的需求也應(yīng)運(yùn)而生，在社交場(chǎng)景，我們叫它“動(dòng)態(tài)麥位”。在“萬(wàn)物互聯(lián)”的物聯(lián)網(wǎng)生態(tài)中，各種類型的設(shè)備都在使用 RTC，小到手表，大到智慧電視，中間還有手機(jī)、Pad、電腦，電視機(jī)也有各種尺寸，想象一下，如果我們用手機(jī)和父母、小孩通話，父母使用電視，小孩使用手表，如果讓電視和手表訂閱相同分辨率的同一路視頻是極不合適的，這個(gè)場(chǎng)景也適合「Simulcast」方案。

實(shí)現(xiàn)會(huì)控的關(guān)鍵技術(shù)

第四個(gè)話題是關(guān)于「如何做好會(huì)控」，對(duì)于 RTC 來說，做好會(huì)控的關(guān)鍵是什么？

在會(huì)控中，和 RTC 相關(guān)的一個(gè)難點(diǎn)是“音視頻狀態(tài)和用戶狀態(tài)的一致性”的問題。比如一個(gè)用戶在系統(tǒng)上顯示是麥克風(fēng)開啟的狀態(tài)，如果狀態(tài)是錯(cuò)誤的，實(shí)際上他是無法上麥的。反過來，系統(tǒng)上顯示他已經(jīng)閉麥了，但實(shí)際上他還在上麥，如果他說了一些不希望被會(huì)上其他參會(huì)者聽到的話或者聲音，就會(huì)涉及到嚴(yán)重的隱私泄漏問題。還有一個(gè)難點(diǎn)是“用戶狀態(tài)變化的及時(shí)性”，比如主持人要讓某個(gè)人閉麥，當(dāng)他操作閉麥該人的動(dòng)作之后，需要能夠馬上、真正地把麥閉掉，一旦及時(shí)性做得不好，不僅讓參會(huì)人的體驗(yàn)不好，還可能造成主持人無法及時(shí)控場(chǎng)的問題。

這兩個(gè)問題的關(guān)鍵在于“信令的可靠性”，我們?nèi)绾伪ＷC信令必達(dá)的同時(shí)，還擁有極低的延時(shí)，并且與音視頻狀態(tài)同步？

我們的解決方案是，讓信令復(fù)用 RTC 音視頻流的傳輸鏈路與弱網(wǎng)對(duì)抗策略，確保音視頻和信令的到達(dá)率相同，保證音視頻狀態(tài)的一致。

我們?yōu)樾帕疃x了幾個(gè)指標(biāo)，一個(gè)是 200ms 到達(dá)率，一個(gè)是總到達(dá)率。總到達(dá)率我們做到了 100%——要確保“消息必達(dá)”，這也是信令的基本要求。而且，我們還要做到“低延遲”的“消息必達(dá)”，這就要求信令是在一定的時(shí)間范圍內(nèi)到達(dá)的，否則即使信令到達(dá)了，也會(huì)失去一部分的意義。我們選擇了「200ms 到達(dá)率」這個(gè)指標(biāo)，目前這個(gè)指標(biāo)的線上數(shù)據(jù)表現(xiàn)是 98.6%，也就是說，在 98.6% 的情況下，信令可以在 200ms 之內(nèi)到達(dá)目的地。

我們?cè)倏匆幌卵訒r(shí)方面的指標(biāo)。

目前，「端到端平均延時(shí)」指標(biāo)表現(xiàn)是 51 ms，但「平均延時(shí)」這個(gè)這個(gè)指標(biāo)其實(shí)比較寬松，我們會(huì)看一個(gè)更嚴(yán)格的指標(biāo)，就是「端到端延時(shí)九十分位值」，簡(jiǎn)稱「PCT 90」，我們線上 PCT 90 的指標(biāo)表現(xiàn)是 117ms，也就是說，線上 90% 的用戶的端到端消息能夠在 117ms 以內(nèi)到達(dá)。能夠做到這樣的到達(dá)率和延時(shí)，主要就是因?yàn)槲覀兊男帕顝?fù)用了 RTC 的傳輸鏈路。

復(fù)用 RTC 傳輸鏈路還有一個(gè)很重要的好處 ，就是保證音視頻數(shù)據(jù)和信令數(shù)據(jù)的延時(shí)和到達(dá)率是一致的，這樣，用 RTC 信令來實(shí)現(xiàn)會(huì)控就不會(huì)出現(xiàn)狀態(tài)不一致的問題，因?yàn)闃O端弱網(wǎng)是不可避免的，最極端的弱網(wǎng)就是斷網(wǎng)，我們現(xiàn)在說到達(dá)率是 100%，前提是網(wǎng)絡(luò)還是通的，如果斷網(wǎng)了，任何信令都不可能傳輸了，而且數(shù)據(jù)上還無法統(tǒng)計(jì)到。但是，如果音視頻和信令采用同一條鏈路，假設(shè)真的斷網(wǎng)了，音視頻傳輸和信令傳輸都無法到達(dá)，要斷一起斷。這樣的話，不管是什么樣的網(wǎng)絡(luò)情況，音視頻狀態(tài)和用戶狀態(tài)永遠(yuǎn)都是一致的，我們做會(huì)控的目的也就達(dá)到了。

我們打磨的「實(shí)時(shí)信令」在其他領(lǐng)域也有廣泛的應(yīng)用。

我們剛剛說到會(huì)控，其實(shí)在很多 RTC 領(lǐng)域中，多多少少都存在一些會(huì)控的邏輯，像互娛社交場(chǎng)景中也會(huì)存在房間管理，如果一些主播、連麥嘉賓、上麥觀眾說了一些不合適的話，或者做了一些不合適的行為，管理員就需要制止，簡(jiǎn)單點(diǎn)就是禁言或踢人，如果制止不成功或不夠及時(shí)，可能會(huì)引起更嚴(yán)重的問題。

除了會(huì)控以外，「實(shí)時(shí)信令」也可以用到一些新的玩法中。這里舉一個(gè)「一起看抖音」的場(chǎng)景，抖音上就有這個(gè)功能，兩個(gè)朋友之間可以連麥一起刷視頻，“主態(tài)”刷到哪兒“客態(tài)”的視頻進(jìn)度就跟到哪兒，兩邊的視頻延時(shí)低于 100ms，而實(shí)現(xiàn)視頻滑動(dòng)狀態(tài)主客態(tài)同步業(yè)務(wù)邏輯的技術(shù)就是「實(shí)時(shí)信令」。

Web 端實(shí)現(xiàn)復(fù)雜算法的新解

最后一個(gè)話題是關(guān)于「Web 端實(shí)現(xiàn)復(fù)雜算法的新解」。我們先看一下 Web 端有哪些性能消耗的“殺手”。我們知道，RTC 的編碼是很耗性能的，但和美顏、特效、虛擬背景比起來還是小巫見大巫。這些功能在視頻會(huì)議場(chǎng)景中已經(jīng)成為“剛需”，幾乎每個(gè)居家辦公的參會(huì)人都會(huì)使用，我們要如何既保證客戶端設(shè)備性能，又達(dá)到媲美 Native 的效果呢？

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

第一種是業(yè)內(nèi)的普遍做法——在 Web 本地加載這些算法。Web 本地運(yùn)行算法對(duì)于設(shè)備 CPU 的消耗都非常大，而且由于 Web 瀏覽器本身存在性能瓶頸，哪怕設(shè)備再好，在 Web 端做特效的效果都可能打折扣，一些復(fù)雜的特效甚至可能無法運(yùn)行。瀏覽器的兼容性也是一個(gè)問題。還有一個(gè)問題是比較容易被忽略的，由于 Web 會(huì)把代碼和模塊下載到本地運(yùn)行，如果在本地加載特效算法就會(huì)增加包體，支持的算法越多，包體就越大，它會(huì)影響頁(yè)面加載速度，算法的豐富性也會(huì)受到限制。

我們也研究了業(yè)務(wù)端是如何解決這個(gè)問題的。行業(yè)里，業(yè)務(wù)端會(huì)使用虛擬攝像頭的方案。虛擬攝像頭自帶美顏功能，Web 通過虛擬攝像頭來采集視頻，這個(gè)采集的視頻已經(jīng)經(jīng)過了特效處理，因此瀏覽器不再需要有額外的性能消耗。但這種操作有個(gè)問題——用戶必須安裝虛擬攝像頭，這和 Web 端追求“免安裝即用”的便捷性理念是違背的。一般會(huì)采取這種方案的用戶是專業(yè)主播，他們本來就在電腦中安裝了很多美顏、虛擬攝像頭的軟件，可能是因?yàn)榕R時(shí)換一個(gè)網(wǎng)頁(yè)開播的平臺(tái)做直播所以使用虛擬攝像頭，像參加面試、臨時(shí)會(huì)議這種場(chǎng)景，普通人可能都不知道有“虛擬攝像頭”，因此這種方案的適用性是比較局限的。

通過結(jié)合 RTC 的優(yōu)勢(shì)，我們探索出一種新的解法——邊緣渲染。邊緣渲染的原理是，當(dāng)發(fā)布者在本地采集了視頻之后，不是直接向訂閱端發(fā)送流，而是先發(fā)送到 RTC 邊緣，在邊緣進(jìn)行云端美顏和渲染，再發(fā)送給對(duì)端，同時(shí)也發(fā)回給發(fā)布端用于本地預(yù)覽。這對(duì)“邊緣”的要求很高，邊緣要盡可能多，才能在邊緣就快速把特效解決了。「邊緣渲染」的好處是對(duì)本端幾乎沒有額外的性能消耗，完全不依賴本地設(shè)備算力，可以運(yùn)行更酷炫、更復(fù)雜的算法。大家可能會(huì)擔(dān)心「邊緣渲染」會(huì)增加發(fā)布者本地預(yù)覽以及發(fā)送到對(duì)端的延時(shí)，我們統(tǒng)計(jì)了一下線上數(shù)據(jù)，開啟邊緣渲染只比普通音視頻通話增加了 30ms 的延時(shí)，本地預(yù)覽延遲低于 200 ms，實(shí)時(shí)幀率可以達(dá)到 30+ fps。

我們來看一下實(shí)際效果。視頻左邊是未渲染的預(yù)覽畫面，右邊是經(jīng)邊緣渲染之后再返回本地的預(yù)覽效果，延遲控制在了 200ms 以內(nèi)，輕微的延遲基本不會(huì)影響正常的發(fā)言和交流。同時(shí)，像這樣的虛擬頭套是一個(gè)比較消耗性能的算法，「邊緣渲染」的方案突破了 Web 運(yùn)行精細(xì)特效算法的性能瓶頸。

從視頻會(huì)議場(chǎng)景孵化出的「邊緣渲染」能力也可以用到其他應(yīng)用場(chǎng)景。比如在一些美妝、電商場(chǎng)景，可以支持用戶免下載軟件，通過云渲染的方式即可體驗(yàn)試妝、試戴效果。像圖上的一些萬(wàn)圣節(jié)特效、魔法變身特效、老年特效都是一些比較耗算力的特效算法，通過云端渲染，在低端機(jī)上也可以方便地實(shí)現(xiàn)。

作者：楊若揚(yáng)，火山引擎 RTC 產(chǎn)品負(fù)責(zé)人

總結(jié)

以上是生活随笔為你收集整理的RTC 技术的试金石：火山引擎视频会议场景技术实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。