1. 背景及技術(shù)挑戰(zhàn)

從電視看直播到手機(jī)電腦看直播，直播技術(shù)的發(fā)展讓觀眾可以隨時(shí)、隨地觀看自己喜歡的比賽，并且在看比賽時(shí)通過(guò)發(fā)送表情、發(fā)文字進(jìn)行互動(dòng)。但表情、文字承載的信息量較小、溝通效率低，我們無(wú)法像線下一起看比賽那樣和好友邊看邊聊、一起為精彩的比賽吶喊，觀賽體驗(yàn)大打折扣。

為了讓觀眾獲得更好的觀賽體驗(yàn)，抖音在 2022 世界杯比賽直播中推出了“邊看邊聊”的玩法：每個(gè)觀眾都可以邀請(qǐng)好友（或分享聊天頻道信息邀請(qǐng)）一起觀看世界杯比賽；在頻道中，好友既可以發(fā)送文字、表情聊天，還可以上麥進(jìn)行語(yǔ)音聊天，一起為精彩進(jìn)球歡呼，大大提升“異地好友線上觀賽”的體驗(yàn)。

進(jìn)入“抖音體育”直播間，邀請(qǐng)好友加入個(gè)人聊天頻道，即可以和好友“邊看邊聊”

我們使用 RTC 來(lái)實(shí)現(xiàn)“邊看邊聊”的功能——觀眾可以隨時(shí)上麥進(jìn)行語(yǔ)音聊天，同時(shí)頻道中的普通觀眾也可以聽(tīng)到麥上用戶的精彩評(píng)論。但在抖音“邊看邊聊世界杯”的玩法中，RTC 面臨著幾個(gè)比較大的挑戰(zhàn)：

一是高并發(fā)的問(wèn)題，包括音視頻流數(shù)高并發(fā)和大量進(jìn)退房請(qǐng)求對(duì)系統(tǒng)的沖擊。世界杯是四年一度的體育盛會(huì)，會(huì)有大量用戶同時(shí)在線看球聊球，這為 RTC 房間帶來(lái)了持續(xù)高并發(fā)的音視頻推拉流壓力，對(duì)于系統(tǒng)的性能及穩(wěn)定性提出了巨大挑戰(zhàn)。同時(shí)，在比賽開(kāi)始和比賽結(jié)束時(shí)，短時(shí)間內(nèi)大量用戶進(jìn)房、退房的請(qǐng)求也會(huì)對(duì) RTC 系統(tǒng)形成沖擊 。

二是觀賽中的音視頻體驗(yàn)問(wèn)題。 包括外放時(shí)，比賽的聲音被麥克風(fēng)采集并發(fā)送到遠(yuǎn)端形成回聲的問(wèn)題；通話人聲響度低于直播聲音響度導(dǎo)致聽(tīng)不清問(wèn)題；整體音質(zhì)優(yōu)化等難點(diǎn)問(wèn)題。

2. 整體方案設(shè)計(jì)

抖音“邊看邊聊”的玩法允許單房間 500 人加入，每個(gè)房間允許 9 個(gè)用戶上麥聊天，另外 491 個(gè)未上麥用戶只旁聽(tīng)不發(fā)言。在整體方案設(shè)計(jì)的過(guò)程中，火山引擎 RTC 考慮了“語(yǔ)音聊天室方案”和“ RTC 互動(dòng)語(yǔ)聊方案”兩種方案，并對(duì)兩種方案架構(gòu)進(jìn)行了分析。

2.1 語(yǔ)音聊天室方案

方案選型初期，其中一個(gè)候選方案是“在直播間中再嵌入一個(gè)語(yǔ)音聊天室”，即，在觀看比賽直播的同時(shí)，上麥用戶加入 RTC 進(jìn)行語(yǔ)音聊天，其余未上麥觀眾再多拉一路 CDN 流收聽(tīng)聊天內(nèi)容， 整體結(jié)構(gòu)如下：

該方案的優(yōu)勢(shì)是可以快速?gòu)?fù)用線上業(yè)務(wù)語(yǔ)音聊天室的主播、觀眾代碼，以及復(fù)用當(dāng)前線上業(yè)務(wù)中上麥、下麥流程，快速搭建該玩法場(chǎng)景。但這個(gè)方案也存在一個(gè)問(wèn)題， 即未上麥的用戶（圖中好友 C、好友 D）聽(tīng)到的聊天內(nèi)容會(huì)有較大的延時(shí)， 麥下用戶會(huì)在進(jìn)球后大約 1~3 秒（CDN 轉(zhuǎn)推延時(shí)）才能聽(tīng)到麥上用戶聊進(jìn)球相關(guān)內(nèi)容，這會(huì)導(dǎo)致比賽進(jìn)程畫(huà)面和聊天內(nèi)容不同步、聊天內(nèi)容延時(shí)大，對(duì)于需要“同頻共振”的大型賽事觀播是無(wú)法接受的體驗(yàn)。

2.2 RTC 互動(dòng)語(yǔ)聊方案

為了保證所有用戶“邊看邊聊、精彩共享”的核心體驗(yàn)，“邊看邊聊”玩法選擇了“ RTC 互動(dòng)語(yǔ)聊”的方案，即所有用戶都加入 RTC 房間，使用火山引擎 RTC 為支持超大型視頻會(huì)議、在線教育大班課場(chǎng)景打造的“千人上麥”和“穩(wěn)定支持超百萬(wàn)人同時(shí)在線”能力，來(lái)應(yīng)對(duì)百萬(wàn)人并發(fā)量級(jí)的世界杯“邊看邊聊”需求。

方案整體架構(gòu)如下：

方案核心要點(diǎn)如下:

（1）觀眾使用播放器從 CDN 拉取高清比賽直播流，播放器支持用戶手動(dòng)選擇清晰度檔位、支持 seek 觀看高光時(shí)刻等操作；

（2）頻道中好友通過(guò) RTC 進(jìn)行實(shí)時(shí)音頻通話；

（3）RTC 支持將通話的語(yǔ)音切片后存儲(chǔ)，供業(yè)務(wù)進(jìn)行審核，保障通話內(nèi)容安全；同時(shí)，平臺(tái)還可以通過(guò)踢人/拉黑等運(yùn)維 OpenAPI，處理不合規(guī)或不符合業(yè)務(wù)預(yù)期的用戶，保障平臺(tái)運(yùn)營(yíng)安全。

在確認(rèn)整體方案架構(gòu)后，我們重點(diǎn)對(duì)如何應(yīng)對(duì)超高并發(fā)、如何提升邊看邊聊體驗(yàn)進(jìn)行了深度優(yōu)化。

3. 關(guān)于超高并發(fā)問(wèn)題的優(yōu)化和實(shí)踐

“超高并發(fā)”是本次世界杯“邊看邊聊”場(chǎng)景的最大挑戰(zhàn)，由于比賽活動(dòng)時(shí)間集中，相關(guān)流量都會(huì)集中出現(xiàn)在 64 場(chǎng)比賽的時(shí)間段，特別是在開(kāi)幕戰(zhàn)、明星球隊(duì)出戰(zhàn)、決賽等熱門(mén)比賽場(chǎng)次，會(huì)有超大量觀眾同時(shí)進(jìn)入直播間；而且，用戶在比賽開(kāi)始前后集中上線、比賽結(jié)束后集中離線也會(huì)對(duì) RTC 系統(tǒng)穩(wěn)定運(yùn)行形成巨大壓力。

3.1  關(guān)于流數(shù)高并發(fā)的優(yōu)化

世界杯“邊看邊聊”場(chǎng)景的特點(diǎn)是流量大，DAU 高（預(yù)估峰值將超過(guò)百萬(wàn)觀眾同時(shí)“邊看邊聊”），抽象到 RTC 場(chǎng)景，就是房間數(shù)量多，每個(gè)房間的用戶數(shù)也多。因此，我們?cè)O(shè)計(jì)了一套高效率的方案，來(lái)兼顧用戶實(shí)時(shí)交互體驗(yàn)以及承載更多量級(jí)用戶的需求。

3.1.1  常規(guī)方案

首先是常規(guī)方案。在常規(guī)方案中，服務(wù)器只需要轉(zhuǎn)發(fā)流，不需要做過(guò)多額外的處理，用戶在最后一公里就近接入，服務(wù)器之間做級(jí)聯(lián)。在這種架構(gòu)下，用戶的實(shí)時(shí)交互體驗(yàn)極佳，但對(duì)于大房間（用戶多）來(lái)說(shuō)不夠合理，用戶訂閱壓力大，客戶端面臨一定的拉流壓力，服務(wù)端也面臨性能和容量的雙重挑戰(zhàn)。

常規(guī)方案架構(gòu)圖如下：

以“500 人房間”為例，單房間 500 個(gè)用戶看球，其中 9 個(gè)人開(kāi)麥聊天，訂閱端每個(gè)用戶需要訂閱 9 路流，用戶下行拉流過(guò)多，對(duì)用戶的客戶端造成一定的性能壓力。再說(shuō)服務(wù)端，假設(shè)考慮到服務(wù)器之間級(jí)聯(lián)，在最差情況下（500 個(gè)用戶連接到 500 個(gè)不同服務(wù)器節(jié)點(diǎn)，服務(wù)器之間都需要級(jí)聯(lián)轉(zhuǎn)發(fā)），平均一個(gè)用戶會(huì)給整個(gè)系統(tǒng)帶來(lái) 10+ 路媒體流。再考慮到這個(gè)場(chǎng)景的 DAU，這套常規(guī)方案對(duì)服務(wù)端性能、容量都會(huì)造成很大的壓力。

3.1.2  公共流擴(kuò)展方案

常規(guī)方案在房間人數(shù)多時(shí)會(huì)面臨諸多性能壓力，因此我們又設(shè)計(jì)了一套公共流擴(kuò)展方案。在公共流方案中，發(fā)布端（上麥用戶）仍然使用常規(guī)方案的設(shè)計(jì)，媒體服務(wù)器只需要純轉(zhuǎn)發(fā)，不需要做過(guò)多額外的處理；訂閱端（閉麥用戶）則訂閱經(jīng)過(guò) MCU（Multipoint Control Units，多點(diǎn)控制單元）服務(wù)器處理的公共流，在這個(gè)架構(gòu)下，用戶的訂閱流數(shù)降低至 1 路。

同樣以“500 人房間”為例，單房間 500 個(gè)用戶看球，其中 9 個(gè)人開(kāi)麥聊天，訂閱端每個(gè)用戶只需要訂閱 1 路流，釋放了客戶端使用壓力。對(duì)于服務(wù)端來(lái)說(shuō)，平均一個(gè)用戶只會(huì)給整個(gè)系統(tǒng)只會(huì)帶來(lái) 2-3 路媒體流的增加，極大優(yōu)化了服務(wù)端資源消耗。

這套方案架構(gòu)可以很好地解決熱流分發(fā)的壓力，相同的服務(wù)器資源可以承載更大的容量，單流可支持 10w 量級(jí)的并發(fā)訂閱?？蛻舳艘惨?yàn)橛嗛喿兩伲阅艿玫胶艽蟮奶嵘?。但這套方案架構(gòu)也會(huì)對(duì)用戶的交互體驗(yàn)產(chǎn)生影響，當(dāng)用戶從“只訂閱的角色”切換至“發(fā)布 + 訂閱”的角色時(shí)，用戶需要先切換到“常規(guī)方案”，即“從公共流”進(jìn)入到“RTC 房間”，這個(gè)時(shí)候，用戶的流內(nèi)容會(huì)發(fā)生切換，用戶會(huì)有“卡頓一下”的感覺(jué)。如果這個(gè)用戶頻繁地切換角色，那就會(huì)頻繁地感覺(jué)到“卡頓”，用戶體驗(yàn)反而惡化。

3.1.3  融合方案

常規(guī)方案帶給用戶的交互性好，但是增加了大多數(shù)訂閱端用戶的設(shè)備端性能壓力以及服務(wù)端的資源消耗；公共流方案減少了 RTC 系統(tǒng)全鏈路并發(fā)音視頻流數(shù)，緩解了訂閱端用戶的性能壓力，但是在頻繁上下麥時(shí)，頻繁地“常規(guī)方案”和“公共流方案”之間切換會(huì)導(dǎo)致戶體驗(yàn)受損?；谝陨咸攸c(diǎn)，火山引擎 RTC 在抖音“邊看邊聊”場(chǎng)景中設(shè)計(jì)了一套“有房間+公共流”的融合方案，來(lái)兼顧用戶體驗(yàn)和設(shè)備端、服務(wù)端性能優(yōu)化。

融合方案設(shè)計(jì)流程如下：

具體流程為：

1. 用戶進(jìn)房
   a.  當(dāng)一個(gè)聊天頻道的用戶小于 M 人時(shí)，該房間使用“常規(guī)方案”，用戶使用“靜默用戶”的身份進(jìn)入 RTC  房間并訂閱流；
   b.  當(dāng)一個(gè)聊天頻道的用戶大于等于 M 人時(shí)，用戶使用“公共流擴(kuò)展方案”加入。
2. 首次上麥
   a.  當(dāng)用戶以常規(guī) RTC 方案訂閱流時(shí)，上麥時(shí)用戶改變狀態(tài)，靜默用戶 -> 非靜默用戶；
   b.  當(dāng)用戶以公共流方式訂閱流時(shí)，上麥時(shí)用戶以非靜默用戶身份直接進(jìn)入 RTC 房間。
3. 二次上麥
   a.  用戶改變狀態(tài)，靜默用戶 -> 非靜默用戶。
4. 用戶下麥
   a.  用戶改變狀態(tài)，非靜默用戶 -> 靜默用戶。

將常規(guī)方案與公共流方案結(jié)合的方案融合了兩者的優(yōu)點(diǎn)：

（1）用戶默認(rèn)以訂閱公共流的方式加入“大房間”中，可以減少 RTC 系統(tǒng)全鏈路的并發(fā)音視頻流數(shù)，擴(kuò)大 RTC 系統(tǒng)并發(fā)容量；

（2）能有效減少用戶在不拉流時(shí)候的設(shè)備端性能壓力；

（3）用戶在上麥時(shí)切換為常規(guī) RTC 方案“有房間”的模式，可以保證用戶實(shí)時(shí)的交互音視頻體驗(yàn)。在切換為有房間模式后，后續(xù)的上下麥則不會(huì)再變更模式，保證了用戶的平滑體驗(yàn)。

3.2  系統(tǒng)容災(zāi)保護(hù)

抖音 DAU 很大，參與“邊看邊聊”玩法的用戶并發(fā)峰值超過(guò)百萬(wàn)量級(jí)，并且，世界杯類(lèi)大型賽事活動(dòng)有個(gè)特征——在比賽開(kāi)始的時(shí)候，用戶集中進(jìn)房；比賽結(jié)束時(shí)刻，用戶又會(huì)集中停止使用音視頻功能，所以在比賽開(kāi)始和結(jié)束的時(shí)候會(huì)有大量請(qǐng)求發(fā)到 RTC 云端服務(wù)器，對(duì)云服務(wù)造成很大壓力，極端情況下甚至?xí)?dǎo)致服務(wù)異常。針對(duì)進(jìn)房和退房的不同特點(diǎn)，火山引擎 RTC 分別采用了“多級(jí)限流”的進(jìn)房保護(hù)策略和“延時(shí)處理”的退房保護(hù)策略。

3.2.1  進(jìn)房多級(jí)限流保護(hù)

火山引擎 RTC 采用“邊緣+中心”結(jié)構(gòu)，用戶就近接入邊緣節(jié)點(diǎn)，數(shù)據(jù)則存儲(chǔ)在中心機(jī)房。在做限流保護(hù)的時(shí)候，我們也采用了相似的策略，即多級(jí)保護(hù)、分段限流，包括全局分布式 QPS 限流，中心 QPS 限流，中心房間數(shù)限流。

架構(gòu)如下：

全局分布式 QPS 限流

全局分布式 QPS 限流采用滑動(dòng)窗口算法實(shí)現(xiàn)。中心信令通過(guò)存儲(chǔ)維護(hù)每秒可以消耗的令牌數(shù)量，邊緣節(jié)點(diǎn)定時(shí)向中心同步自己的令牌數(shù)量，同時(shí)中心返回當(dāng)前時(shí)間戳內(nèi)消耗的總令牌數(shù)。進(jìn)房時(shí)刻的尖峰流量對(duì)中心節(jié)點(diǎn)不友好，全局分布式 QPS 限流可以保證限流平滑，即使部分節(jié)點(diǎn)有瞬時(shí)尖峰流量，整個(gè)系統(tǒng)也不會(huì)受到過(guò)大沖擊。

中心 QPS 限流

中心 QPS 限流采用令牌桶算法實(shí)現(xiàn)。中心信令以恒定的速率產(chǎn)生令牌，然后把令牌放到令牌桶中，令牌桶有一個(gè)容量，當(dāng)令牌桶滿了后，如果再向其中放入令牌，多余令牌就會(huì)被丟棄。當(dāng)中心信令想要處理一個(gè)請(qǐng)求的時(shí)候，需要從令牌桶中取出一個(gè)令牌，如果此時(shí)令牌桶中沒(méi)有令牌，那么該請(qǐng)求就會(huì)被拒絕，客戶端會(huì)收到服務(wù)端返回的錯(cuò)誤碼提示。

中心房間數(shù)限流

中心信令會(huì)在存儲(chǔ)中維護(hù)當(dāng)前系統(tǒng)可以承載的最大房間數(shù)量，每當(dāng)新用戶使用火山引擎 RTC 之后，中心信令就會(huì)查詢(xún)存儲(chǔ)判斷當(dāng)前的房間數(shù)量是否已到達(dá)上限，如果超過(guò)了，則會(huì)拒絕本次用戶的請(qǐng)求，客戶端會(huì)收到服務(wù)端返回的錯(cuò)誤碼提示。

全局分布式 QPS 限流、中心 QPS 限流，中心房間數(shù)限流“三管齊下”的進(jìn)房多級(jí)限流保護(hù)措施解決了“邊看邊聊”場(chǎng)景大流量對(duì)整個(gè)系統(tǒng)的威脅。云服務(wù)系統(tǒng)在處理高并發(fā)請(qǐng)求時(shí)，先進(jìn)行全局分布式 QPS 限流，然后再進(jìn)行中心 QPS 限流，當(dāng)整體系統(tǒng)處于高水位時(shí)，又會(huì)采取全局分布式房間數(shù)限流。

3.2.2  退房/斷連延時(shí)處理保護(hù)

進(jìn)房操作對(duì)實(shí)時(shí)性要求很高，如果進(jìn)房慢，用戶的體驗(yàn)也會(huì)嚴(yán)重受損。不同于進(jìn)房操作，用戶可以在一定程度上忍受“退房慢”，因此服務(wù)端的保護(hù)策略上也和進(jìn)房略有不同。退房/斷連保護(hù)的策略核心是“延時(shí)處理”，在邊緣節(jié)點(diǎn)設(shè)置一個(gè)定長(zhǎng)的 FIFO 隊(duì)列，每個(gè)邊緣節(jié)點(diǎn)的請(qǐng)求先進(jìn)入 FIFO 隊(duì)列中，后續(xù)按照一定的速率重新發(fā)送到中心信令。經(jīng)過(guò)這樣的保護(hù)，服務(wù)可以處理超百萬(wàn) QPS 的退房操作。

退房/斷連保護(hù)的基本執(zhí)行步驟：

1. 檢測(cè)用戶退房事件（包括用戶正常離開(kāi)房間與斷網(wǎng)離房）的 QPS，如果 QPS 超過(guò)可以立即處理的閾值，將事件觸發(fā)的上下文保存到隊(duì)列中，且記錄當(dāng)前時(shí)間戳到事件的上下文中；
2. 在隊(duì)列中啟動(dòng)一個(gè) Loop，嘗試獲取隊(duì)列中請(qǐng)求任務(wù)去執(zhí)行，每次在執(zhí)行前，還會(huì)檢查退房事件觸發(fā)事件的時(shí)間戳與當(dāng)前時(shí)間差是否小于某個(gè)定義的閾值，小于該閾值的請(qǐng)求會(huì)被執(zhí)行發(fā)送到中心信令；大于等于該閾值的請(qǐng)求則會(huì)被丟棄；
3. 在發(fā)送成功后，從隊(duì)列中刪除該事件的上下文信息。

異常場(chǎng)景考慮

1. 用戶發(fā)送退房請(qǐng)求，且被攔截保存到緩存隊(duì)列中，之后很短時(shí)間內(nèi)用戶又重新進(jìn)房，那么會(huì)出現(xiàn)用戶退房事件與用戶下次進(jìn)房存在時(shí)序問(wèn)題，我們用引入“退房時(shí)間戳”來(lái)解決這個(gè)問(wèn)題。中心信令在接收到用戶退房請(qǐng)求時(shí)，會(huì)比較當(dāng)前用戶進(jìn)房時(shí)間戳與退房時(shí)間戳，若進(jìn)房時(shí)間晚于退房時(shí)間，說(shuō)明是用戶退房后再進(jìn)房，系統(tǒng)可以直接忽略該用戶的離房請(qǐng)求。
2. 退房請(qǐng)求放入隊(duì)列超過(guò)一定時(shí)長(zhǎng)后可能會(huì)觸發(fā)斷連請(qǐng)求。這里的處理方式就是依次處理退房請(qǐng)求和斷連請(qǐng)求，如果用戶已經(jīng)退房，則忽略斷連請(qǐng)求。

4.  極致用戶體驗(yàn)

極致的音視頻體驗(yàn)是業(yè)務(wù)玩法獲得用戶認(rèn)可的必要條件。在邊看邊聊場(chǎng)景中，我們面對(duì)著本地直播音頻被麥克風(fēng)采集形成回聲、使用通話模式導(dǎo)致直播音質(zhì)變差、比賽聲音比聊天聲音大導(dǎo)致人聲聽(tīng)不清楚等問(wèn)題，這些問(wèn)題都嚴(yán)重影響了用戶的邊看邊聊體驗(yàn)；為了解決相關(guān)問(wèn)題，我們使用了直播音頻托管 RTC 播放、全鏈路音頻媒體通道模式、智能音頻閃避等方案，為邊看邊聊提供了良好的音視頻體驗(yàn)。

4.1 音頻托管

回聲消除問(wèn)題是 RTC 的重點(diǎn)和難點(diǎn)問(wèn)題；在邊看邊聊場(chǎng)景中，部分用戶會(huì)使用外放音頻方式來(lái)觀看比賽， 在這種情況下，RTC 播放的遠(yuǎn)端人聲和直播播放器播放的比賽聲音會(huì)被麥克風(fēng)采集后發(fā)送到遠(yuǎn)端形成回聲。

為了解決邊看邊聊場(chǎng)景的回聲問(wèn)題，RTC 和播放器提供了播放器音頻托管由 RTC 來(lái)播放的解決方案，由播放器將解碼后的直播音頻數(shù)據(jù)調(diào)用 RTC 音頻托管接口來(lái)播放；在 RTC 內(nèi)部，直播音頻會(huì)和遠(yuǎn)端用戶音頻進(jìn)行混合，再調(diào)用系統(tǒng)音頻播放接口進(jìn)行播放，同時(shí)將混合信號(hào)送到 RTC 回聲消除模塊，回聲消除模塊會(huì)將麥克風(fēng)采集到的聲音中的遠(yuǎn)端音頻和直播比賽聲音消除，這樣就得到了沒(méi)有回聲的本地人聲數(shù)據(jù)，這些數(shù)據(jù)會(huì)在編碼后送到遠(yuǎn)端，避免了回聲問(wèn)題的出現(xiàn)。

4.2  外放媒體模式

在移動(dòng)端設(shè)備上，音頻播放區(qū)分通話模式（通話模式音頻通道）和媒體模式（媒體模式音頻通道），二者在音質(zhì)表現(xiàn)、音量控制上略有不同，從而適用于不同的業(yè)務(wù)場(chǎng)景， 具體表現(xiàn)如下：?

由于邊看邊聊場(chǎng)景是在直播間觀看比賽過(guò)程中開(kāi)啟音頻通話，我們既要保障通話沒(méi)有回聲，也要保障直播音頻音質(zhì)；我們分別對(duì)邊看邊聊場(chǎng)景 RTC 使用媒體通道和通話通道進(jìn)行了對(duì)比測(cè)試結(jié)果如下：

為了給用戶提供更好的音質(zhì)體驗(yàn)，本次邊看邊聊場(chǎng)景配置了外放媒體模式；為了解決外放媒體模式時(shí)系統(tǒng)回聲消除效果差的問(wèn)題，火山引擎 RTC 引入了基于深度學(xué)習(xí)的回音消除算法，對(duì)傳統(tǒng)算法難以覆蓋的場(chǎng)景進(jìn)行音質(zhì)提升，比如信號(hào)回聲比較大的情況，非線性失真加大的情況，以及音樂(lè)場(chǎng)景等，在保障聊天回聲消除條件下，達(dá)到了高音質(zhì)體驗(yàn)。

4.3  智能音頻閃避

邊看邊聊場(chǎng)景的另外一個(gè)特點(diǎn)是直播流中現(xiàn)場(chǎng)聲音、解說(shuō)聲音的音量通常會(huì)比好友之間聊天聲音音量大，這就造成了聊天的聲音偏小或者幾乎聽(tīng)不到遠(yuǎn)端好友聲音的問(wèn)題；為了解決直播聲音大而聊天聲音比較小的問(wèn)題，我們?cè)谶吙催吜膱?chǎng)景中調(diào)整了遠(yuǎn)端人聲和直播聲音的音量配比，保障遠(yuǎn)端聊天人聲和直播聲音響度基本持平。

為了更進(jìn)一步避免比賽聲音和遠(yuǎn)端人聲沖突導(dǎo)致無(wú)法聽(tīng)清聊天內(nèi)容的問(wèn)題， 我們引入了智能音頻閃避算法。音頻閃避（Audio Ducking）的功能是當(dāng)檢測(cè)到 A 信號(hào)出現(xiàn)時(shí)，將 B 信號(hào)的電平降低，仿佛 B 信號(hào)「躲避」了 A 信號(hào)，因此得名「閃避」。閃避算法非常適合在「邊看邊聊」和「游戲直播」場(chǎng)景中開(kāi)啟，在邊看邊聊場(chǎng)景中，A 信號(hào)是遠(yuǎn)端用戶人聲，B 信號(hào)是播放器播放的比賽聲音。開(kāi)啟閃避功能后，RTC 在收到遠(yuǎn)端語(yǔ)音時(shí)，將播放的直播聲音進(jìn)行閃避，能讓用戶更清晰地聽(tīng)到遠(yuǎn)端好友的語(yǔ)音， 經(jīng)過(guò)驗(yàn)證，達(dá)到了非常好的音頻體驗(yàn)。

邊看邊聊場(chǎng)景添加智能音頻閃避后的音頻處理流程如圖：

關(guān)于智能音頻閃避功能中的音頻增益控制，還有一些經(jīng)驗(yàn)性原則需注意：

• 增益下降應(yīng)足夠快，否則語(yǔ)音的開(kāi)始片段仍會(huì)被音樂(lè)掩蔽；但又不能過(guò)快，導(dǎo)致出現(xiàn)音質(zhì)問(wèn)題；
• 增益下降后，應(yīng)該保持足夠的時(shí)間，等待人聲消失一段時(shí)間后再恢復(fù)，否則，正常講話的停頓會(huì)頻繁觸發(fā)閃避效果，體驗(yàn)很差；
• 增益的恢復(fù)可以稍慢，不要給人很突然的感覺(jué)；
• 要對(duì)遠(yuǎn)端人聲進(jìn)行智能識(shí)別檢測(cè)，避免遠(yuǎn)端噪聲引起過(guò)度閃避。

5.  總結(jié)與展望

火山引擎 RTC 邊看邊聊場(chǎng)景解決方案， 通過(guò) RTC 公共流 + RTC 有房間無(wú)縫切換的方案，在兼顧實(shí)時(shí)音視頻體驗(yàn)基礎(chǔ)上，支持了單流超大規(guī)模的并發(fā)，降低了用戶拉流數(shù)量，不僅提高了觀賽機(jī)型滲透率也提高了 RTC 系統(tǒng)容量；針對(duì)世界杯觀賽用戶集中進(jìn)房 ，集中退房的特點(diǎn)，RTC 服務(wù)端制定了 “邊緣限流”，“中心限流” ，“信令平滑發(fā)送” 等重保策略，提高了 RTC 服務(wù)在高 QPS 場(chǎng)景下的穩(wěn)定性；使用直播流音頻托管給 RTC 播放的方案，解決了雙端同時(shí)播放直播流音頻引入的回聲問(wèn)題；使用外放媒體模式 + 軟件 3A 方案，在兼顧回聲消除基礎(chǔ)上保障了高音質(zhì)邊看邊聊體驗(yàn)；通過(guò)調(diào)整音量配比和智能音頻閃避功能，解決了直播流聲音大， 聊天聲音小的問(wèn)題。經(jīng)線上打磨驗(yàn)證，方案設(shè)計(jì)合理有效，為世界杯邊看邊聊觀賽體驗(yàn)提供了有力的保障。

更進(jìn)一步，在一起看短視頻、一起看電影等場(chǎng)景，業(yè)務(wù)還可以通過(guò)實(shí)時(shí)信令(RTS)來(lái)對(duì)房間中各個(gè)用戶觀看進(jìn)度進(jìn)行集中控制，保障房間中用戶觀看相同內(nèi)容；業(yè)務(wù)還可以選擇打開(kāi)視頻， 更進(jìn)一步增加好友之間的觀影、觀賽體驗(yàn)；在UGC 大咖解說(shuō)場(chǎng)景，我們還可以支持用戶上麥與主播進(jìn)行互動(dòng)聊天，更進(jìn)一步拉近主播和觀眾的距離，實(shí)現(xiàn)更好的互動(dòng)效果。

6.  Demo 和場(chǎng)景搭建

我們將支持邊看邊聊的材料整理成了場(chǎng)景化解決方案文檔和 Demo， 供有需要的開(kāi)發(fā)者來(lái)快速實(shí)現(xiàn)自己的業(yè)務(wù)場(chǎng)景， 歡迎廣大開(kāi)發(fā)者點(diǎn)擊閱讀原文參考和體驗(yàn)。

7.  加入我們

火山引擎 RTC，致力于提供全球互聯(lián)網(wǎng)范圍內(nèi)高質(zhì)量、低延時(shí)的實(shí)時(shí)音視頻通信能力，幫助開(kāi)發(fā)者快速構(gòu)建語(yǔ)音通話、視頻通話、互動(dòng)直播、轉(zhuǎn)推直播等豐富場(chǎng)景功能，目前已覆蓋互娛、教育、會(huì)議、游戲、汽車(chē)、金融、IoT 等豐富實(shí)時(shí)音視頻互動(dòng)場(chǎng)景，服務(wù)數(shù)億用戶。