陈曦：超低延迟下的实时合唱体验升级
點擊上方“LiveVideoStack”關注我們
RTC（實時音視頻通信）近年來廣泛應用于語聊房、直播連麥、視頻會議、互動課堂等場景，延遲一般在200ms-300ms，已經(jīng)可以滿足大部分場景的互動需求。但還有一些場景對延遲的要求非常苛刻，延遲的高低直接影響用戶體驗，如“線上KTV”、“云游戲”等。本文來自即構科技行業(yè)解決方案總監(jiān) 陳曦在LiveVideoStack公開課的分享，結合即構科技在實時合唱場景中實現(xiàn)極致工程化的經(jīng)驗，對超低延遲體驗的優(yōu)化思路進行了詳細解析。
文 | 陳曦
整理 | LiveVideoStack
陳曦
?公開課
大家好，我是即構科技的陳曦，目前主要負責解決方案架構方面的工作，包括新產(chǎn)品、新場景設計以及線上項目維護。
?
本次分享的主題是即構科技在超低延遲下如何進行優(yōu)化，以及如何在超低延遲的支持下研發(fā)新場景，如實時合唱等。內(nèi)容主要分為四個部分：第一，RTC發(fā)展與泛娛樂場景創(chuàng)新；第二，超低延遲體驗的優(yōu)化思路；第三，實時合唱場景中實現(xiàn)極致工程化的經(jīng)驗；最后是即構即將推出的新場景以及RTC行業(yè)的未來展望。
01
RTC發(fā)展與泛娛樂場景創(chuàng)新
?
首先回顧一下在線實時娛樂的發(fā)展歷程。十幾年前還沒有實時互動的概念，那時主要是單向直播，技術條件的限制使得延遲高達3-5s，沒有觀眾及麥上用戶和主播進行互動；近十年，基于傳統(tǒng)CDN技術，延遲勉強可以壓縮至1s左右，因而陸續(xù)出現(xiàn)了“偽實時互動”。在1s延遲的前提下，一來一回延遲大概是2s，這是人們在面對面交流時無法適應的；隨著Google WebRTC技術框架的興起，近幾年延遲逐步壓縮至500ms、300ms、200ms，300ms和200ms也就是大家線上語音、連麥、開黑時的常見延遲時長。
?
結合已有的創(chuàng)新場景，主要是實時共享體驗。人類是社會動物，分享欲是與生俱來的，我們樂于向他人分享語言、情感、甚至是肢體語言和表情。由于疫情的發(fā)生，以及當前工作壓力越來越大，生活節(jié)奏越來越快，大家在周末可能更傾向于宅在家中而非線下社交，因此創(chuàng)造貼近線下的線上實時共享體驗就成為了主流訴求。目前的共享體驗場景主要圍繞“一起+”展開，如一起玩、一起看、一起聽、一起唱，甚至包括未來網(wǎng)絡實時互動的走向，也就是“元宇宙”，通過VR/AR等設備開展沉浸式體驗。
日常生活中，戀人、朋友會共用一副耳機來分享好聽的歌曲。“一起+”系列中的“一起聽”就是將這種分享模式轉換為線上，喜馬拉雅在今年3月推出了“一起聽”，用戶可以邀請好友進入房間一起分享音樂，隨時進行評論、開麥聊天等。
當我們向好友分享一部好看的影片或是一段搞笑片段時，僅僅通過分享鏈接無法得知對方是否觀看以及看完之后的感受評價。“一起看”的推出避免了以上問題，把朋友拉入視頻所在房間，可以直觀地看到對方觀感，可以實時連麥、打開攝像頭進行交流，這就真正地模擬了線下社交時的種種體驗。
以前的斗魚游戲主播進行游戲直播時只能通過打字和粉絲進行弱互動，而且在玩游戲時可能漏掉許多留言。“一起玩”中，無論是主播或是任意玩家，都可以在玩游戲時通過實時直播連帶畫面及音效一同推出，同時可以和粉絲以及小隊隊友保持語音連麥，相較于之前的互動模式實現(xiàn)了質(zhì)的飛躍。
“一起唱”包括元宇宙中的沉浸式“一起看演唱會”等，其對延遲的要求更為極致，前面介紹的場景延遲在200-300ms左右就可以滿足當前需求。“一起唱”模擬的是線下多位好友一同去KTV包廂時，各拿一個麥克風，或是兩到三個甚至是四個麥克風同時唱一首歌，歌的旋律是固定的，不會停頓。如果A和B在合唱時，A需要聽到相同進度節(jié)奏時B的歌聲，并且沒有網(wǎng)絡傳輸?shù)难舆t以防打亂節(jié)奏，這些需求之前行業(yè)內(nèi)基本無法實現(xiàn)，所以更多的是單人唱、排隊輪唱、搶唱，后兩者存在轉場可以留出延遲時間。
大家可以聽一下即構“一起唱”方案中app的合唱效果。音頻中的男聲唱的是和弦的旋律，和主唱的音準基本在3度5度和弦上面。無論是從觀眾角度還是音頻中兩位歌手的角度，聽到的都是剛才音頻中的效果，可以聽出延遲非常低大概70~80毫秒，幾乎感覺不到線上有網(wǎng)絡的阻隔。
02
超低延遲體驗的思路
?
RTC體驗刻畫中，觀看端主要從低延遲、流暢、高音質(zhì)和畫質(zhì)評價體驗，但在RTC的各個場景不斷優(yōu)化的進程中，這三個指標如同三角形的三個角，相加始終等于180°，不可能同時很小，比如降低延遲，buffer減小時流暢度會下降，碼率也會減小，因為許多用戶下行帶寬不穩(wěn)定，無法實現(xiàn)高音質(zhì)，高畫質(zhì)需要的高碼率。
?
即構經(jīng)過二十年的運營經(jīng)驗積累及每天20億的時長積累，基于對用戶的時長行為分析得出調(diào)優(yōu)數(shù)據(jù)，目前已經(jīng)基本做到低延遲、流暢，高音質(zhì)及高畫質(zhì)。
無論是聲音還是畫面，整個鏈條從采集、前處理（美聲、變聲、回聲消除等）、編碼（編程AAC）、經(jīng)過MSDN傳輸、播放端解碼、后處理，硬件渲染，其中的每一步既在生產(chǎn)數(shù)據(jù)也在消費前一個流程的數(shù)據(jù)，那么會導致任一環(huán)節(jié)的延遲升高就會成為木桶效應中的短板，從而升高整個流程的延遲甚至崩潰。每一步信息的“保鮮期”很短，如何做到使每個流程的速度彼此匹配，不會因為出現(xiàn)抖動而成為短板，這都需要基于大量線上運行經(jīng)驗、底層的挖掘、即構極致工程思想，一步步在平衡取舍下實現(xiàn)。
?
在采集端，無論是iOS或是安卓，尤其是安卓，我們采集時用了新的底層接口并做了參數(shù)調(diào)優(yōu)，以實現(xiàn)更低的采集延遲；前處理板塊，盡量減少了不必要的前處理，對必要的3A包括聲音美化，進一步精簡處理算法，將延遲降至更低；編碼板塊，盡量使用Opus（縱坐標代表延遲，橫坐標代表碼率），右圖看到Opus在碼率從低到高的過程中，延遲一直很低；網(wǎng)絡傳輸?shù)膬?yōu)化包括實時監(jiān)控主動探測；對端的拉流側也相同，推流只是一半，拉流如何保證低延遲渲染及解碼都關系著延遲高低，大家可以猜測我們肯定把jitterbuffer設置非常低，只有幾十毫秒，但其實jitterbuffer是兩難的取舍，設置太低時緩存池小導致卡頓，設置太高時卡頓率下降但是延遲升高，所以需要經(jīng)過大量數(shù)據(jù)進行平衡得出結果。
?
最終即構做到保證穩(wěn)定流暢前提下，iOS延遲在70ms以內(nèi)，安卓平均在86ms以內(nèi)（高通芯片低于86ms，海思芯片稍高于86ms低于100ms），Windows表現(xiàn)正常。從聲樂角度、人類聽覺原理上通過測試得出，在實時合唱場景中，只要控制端到端延遲穩(wěn)定在130ms以內(nèi)，作為主場和副唱，聽到的對端歌聲和自身感覺一致，不會影響演唱。
即構主要通過對網(wǎng)絡傳輸鏈路進行優(yōu)化來保持網(wǎng)絡端的穩(wěn)定并盡量降低RTT、抖動。優(yōu)化分為兩點：
第一，在全球部署了500多個節(jié)點，覆蓋200多個國家。節(jié)點之間可進行主動探測，探測節(jié)點之間的鏈路、sdn線路及當前狀態(tài)，而不是只依賴于線上用戶跑的數(shù)據(jù)，被動地收集日志；
第二是即構的產(chǎn)品SDK，在接入之前也會進行主動探測的過程。
?
接入之前進行主動探測是調(diào)度策略所要求的，一般是兩個策略并具：
默認調(diào)度策略，即調(diào)度服務器實時獲取不同節(jié)點網(wǎng)絡質(zhì)量，服務器質(zhì)量，經(jīng)過算法匯總后，為某一區(qū)域用戶默認指派某一集群節(jié)點服務器。但由于網(wǎng)絡瞬息萬變，如網(wǎng)絡抖動，節(jié)點質(zhì)量發(fā)生變化，默認調(diào)度策略可能存在反應不及時的情況。因此就需要SDK用戶端在接入之前，主動探測、選路，接入探測對比默認調(diào)度策略分配節(jié)點與其它節(jié)點RTT、丟包率、下載速度等，選擇更為優(yōu)質(zhì)的節(jié)點。
03
實時合唱場景中實現(xiàn)極致工程化的經(jīng)驗
?
K歌最早是“弱互動”甚至沒有互動，用戶錄好歌曲后上傳到社區(qū)或者云端服務器，其他用戶看到作品后進行評價，唱的好的用戶在社區(qū)里人氣就比較高。后來出現(xiàn)了多人KTV，市面上以搶唱及輪唱為主，少有能夠做到偽實時合唱（下文會解釋）。今年落地的幾個實時合唱項目都由即構科技支持拓寬，可以支持雙人、三人甚至幾十個人大合唱。
前中國K歌行業(yè)用戶意愿及付費率逐步升高。
潛力巨大的Z世代用戶使用的在線音樂產(chǎn)品中排名前十甚至有50%都和K歌相關，比如全民K歌、唱吧、酷狗，酷狗有自己的酷狗直播、酷狗唱唱、酷狗酷群等。
目前在線KTV無論是獲客能力還是用戶黏性都位居第一，這是一個很火熱的場景，對用戶社交及互動的吸引力非常高。
上文提到目前市面最多的“偽實時合唱”實質(zhì)是串行合唱，特點是主唱基本無法聽見副唱的聲音，他們之間的延遲高達500ms以上，這對節(jié)奏較快的歌曲來說會相差1-2拍，嚴重影響主唱節(jié)奏。所以一般“偽實時合唱”的app中，主唱都聽不見副唱的聲音從而避免干擾，但這和真正的線下K歌完全不同。另外是多人合唱難以落地，因為串行合唱只能主唱串副唱，副唱串觀眾，無法做到多人合唱。
?
串行合唱方案的架構很簡單，主唱先在本地使用麥克風唱歌，麥克風聲音過來后加入伴奏音樂混成一路流后推給副唱，副唱聽到主唱聲音的同時按照節(jié)奏從麥克風錄入聲音，最后的音樂有三個部分，主唱人聲、副唱人聲和伴奏音樂。最后一起通過低延時或cdn方式播放給觀眾。
?
此方案的缺點是，主唱聲音到達后，副唱才可以唱，副唱聲音回退后，主唱才能聽到，一去一回雙倍延遲大概500ms聲導致主唱體驗糟糕，聽不見其他人的聲音，從而失去社交體。
為了解決以上痛點，真正實現(xiàn)線上K歌貼近線下K歌，即構設計了在線實時K歌合唱技術架構。
此架構完全不同于串行架構，它是變形架構，不分主唱和副唱，只分為歌唱者1和2。在業(yè)務側選擇一人作為麥主，麥主和另一副唱把麥克風采集的歌聲推給 ZEGO RTC，不同的是，麥主會額外推一路音樂，也就是推兩路流（一個伴奏一個人聲），其他合唱者只需要推自己人聲即可。
?
如果是多人合唱也相同，圖中右下紅色框可表示一位或多位歌唱者。總之有n個人合唱就有n+1路流，ZEGO RTC會將到達的每一路流時間戳逐幀對齊。這里的時間戳是NTP的絕對時間戳，是由每位歌唱者在歌唱之前向同一個網(wǎng)絡NTP時間服務器，通過NTP時間協(xié)議獲取的絕對時間，對每個人來說都一樣。在此前提下，混流服務器就可以把每個人音頻的每一幀時間戳取出，因為音頻每秒有50幀，相當于每秒把每幀的時間戳取出。然后跟其他所有流的時間戳對比，將相同時間戳的幀合成一路流后播放給觀眾，觀眾聽到的流里歌聲一定是齊的，當然前提是歌手的節(jié)奏準確。
?
那么實現(xiàn)架構原理的前提是什么，歌手如何同步把自己和他人進度相同的歌聲推上云，也就是如何保證歌手唱歌的進度和他人一樣。唱歌進度取決于伴奏進度，如何保證每位歌手聽到的伴奏進度和他人一樣。即構給出了一個創(chuàng)新解決方案，不同于串行的一個人推出音樂給別人聽，上文強調(diào)伴奏推出來只是給觀眾聽，此方案是讓每位歌手本地播放伴奏音樂，伴奏音樂基于每位歌手本地提前同步好的絕對NTP時間，約定好12345倒數(shù)后同時播放本地伴奏的絕對時間值，只要到了約定時間，所有人本地的媒體服務器會同時播放同首伴奏音樂，只要伴奏音樂對齊，所有人唱歌進度自然也就對齊了。
這段音頻是三人實時合唱KTV的效果展示，可以聽到三人合唱進度非常齊，很難聽出是線上合唱，這是每位歌手聽本地的伴奏進度來實時合唱的。無論是觀眾角度還是麥上的其他歌手聽到的效果都相同，用戶體驗非常好。
上文提到了每一步的做法，這里不再贅述。
每位歌手本地同步播放伴奏有兩個前提：第一，是提前每個端獲取同步NTP網(wǎng)絡時間；第二，是本地的媒體播放器預加載歌曲資源，只有全部預加載之后，才開始倒計時54321開播，播放器就可以在幾毫秒之內(nèi)開始播放。目前可以做到進度誤差在8ms之內(nèi)，對整個延遲的影響微乎其微。
?
開始兩個人一起合唱可以保障，如果中途有人加入合唱，或是唱到一半播放器突然卡頓，一卡就是50ms，又或是中途用戶插拔耳機造成底層流媒體引擎的暫停重啟，延遲了幾十毫秒，一來一回誤差逐漸變大，播放進度誤差從8ms到50ms甚至100ms，再加上延遲可能達到200ms。
?
針對這些情況設置有相應的獨特算法，實時從麥主的流獲取當前唱歌進度，以SEI方式寫在流里，頻率可以自定義，非麥主歌唱者不斷從麥主流取得進度值，并且比對與麥主流中的進度值相對應的NTP時間戳和發(fā)送時間。然后再與非麥主的本地播放進度進行比對，知道麥主在一個NTP時間的進度是多少，再比對本地當前的播放進度，相減就可以消掉網(wǎng)絡延遲誤差，還可精確預測出麥主目前的進度。非麥主歌手只需向麥主seek對齊即可，這里涉及到seek精度問題，許多廠商的seek精度無法做到很低，大概在百毫秒級，我們經(jīng)過一系列攻堅，目前可以做到10毫秒級seek從而完成以上動作。
?
上文也提到了混流服務器是逐幀對齊麥上歌手的所有音頻流并混流在一起，從而保證觀眾的聽歌體驗。
?
為了避免網(wǎng)絡環(huán)境較差的用戶場景體驗較差，我們做了一些代碼和相關參數(shù)，接入場景后建議用戶合唱之前進行測速，主要測試RTT和丟包率。如果用戶網(wǎng)絡較差，業(yè)務層會給出友好的業(yè)務引導，比如建議用戶優(yōu)化網(wǎng)絡后再使用進行合唱。
實時合唱除了要求超低延遲以及場景匹配能力達到要求之外，還需要本地播放音樂。那么如何獲得版權？響應國家“凈網(wǎng)”行動，不能要求用戶從其他渠道獲得音頻，為了讓更多平臺接入實時KTV，即構和TME打通了版權購買通道，版權費用是其他渠道的1/5以下，支付方式靈活，曲庫非常廣。
?
音速達引擎基本覆蓋老年、中年、青年及抖音熱門歌曲，滿足了不同年齡層用戶的訴求。
04
超低延遲場景的未來展望
與其說是超低延遲場景的未來展望，其實更確切的說應該是用戶之間的實時互動，實時泛娛樂，甚至整個網(wǎng)絡社會未來的走向。未來必然會出現(xiàn)更強大的終端，編解碼器可能會有H.266或者H.267，編解碼質(zhì)量越來越高，壓縮率也越來越高，網(wǎng)絡可能發(fā)展為6G、7G，傳輸速度越來越快，丟包率、延遲越來越低。
?
基于這些系統(tǒng)基石，未來的網(wǎng)絡一定是以元宇宙、沉浸式體驗、虛擬第二人生為主的充滿VR/AR交互、肢體交互、表情控制元素的完整虛擬世界。完全滿足用戶在線上模擬線下社交的所有訴求。
?
元宇宙
很多年前的《黑客帝國》，相信大家都了解過，電影講述了未來社會，人類的生化身體被禁錮在一些維生設備中，每個人所認為的真實社會都是超級AI模擬出的虛擬社會。無論是從肉眼還是哈勃望遠鏡，我們所能觀測到的現(xiàn)實世界都是來自感受到的。從這個角度出發(fā)，只要模擬的夠逼真，虛擬和現(xiàn)實的區(qū)別到底在哪里。現(xiàn)在有一些學術流派說宇宙是一個龐大的超級AI模擬出來的，例證是普朗克時間無法再分，也就是超級AI的計算機頻率無法再細分。
?
總之聚焦于不遠的未來，元宇宙一定是完整的，完全自洽的虛擬世界，經(jīng)濟可能來源于區(qū)塊鏈。主要依賴于超低延遲，因為每個人都有自己的虛擬形象，虛擬形象之間的社交幾乎完全等同于真實社交，所需延遲會低于現(xiàn)在要求的70ms。沉浸式體驗和社交體驗更依賴于虛擬設備制造廠商，如HTC、惠普、SONY等，VR渲染引擎依靠于游戲廠商。
?
舉個例子，如去年疫情期間，Travis Scott在當時一個用戶量很大的游戲《堡壘之夜》中利用VR舉辦了一場虛擬演唱會，雖然只有10min，但參加用戶超過了1200萬。短時間內(nèi)如此大的流量聚集線下基本都無法實現(xiàn)，并且玩家在游戲中可以通過不同的角度觀看演唱會，歌手本人在10min內(nèi)切換了大概十種場景，場景的多樣性也是線下演唱會無法比擬的。
從二十多年前的第二人生開始，到現(xiàn)在出現(xiàn)了許多真人社交基于VR引擎的游戲。圖中展示的是VR虛擬課堂，人物角色是由VR引擎生成的虛擬形象，聲音來自真實的玩家。左上角是用戶在游戲中的角色，他們之間可以進行實時語音溝通，與真實世界的教室場景及交互完全相同。
?
云游戲場景
圖中是云游戲的場景， 云游戲不消耗本地硬件資源而是在服務器上，服務器實時運算游戲引擎，把游戲畫面以超低延遲傳給用戶的終端設備，終端屏幕的觸控或是電腦鍵盤鼠標等交互再以超低延遲傳回給服務器。目前畫面延遲基于上文提到的超低延遲技術可以做到幾十毫秒以內(nèi)，應用新的信令通道，延遲可以壓縮到10ms以內(nèi)。與本地運行游戲基本沒有區(qū)別，并且節(jié)約了顯卡、PC、旗艦手機的成本，任意終端都可以不發(fā)熱地運行游戲。
?
云游戲+一起玩+直播
我們希望結合云游戲、一起玩和直播，手機本地沒有運行超大3D游戲帶來的硬件損耗，也就可以實現(xiàn)邊玩游戲邊直播、和好友連麥、組隊或是和粉絲聊天互動。
虛擬形象
視頻片段中展示是一組正在唱歌的虛擬形象，是我們即將在10月份上線的虛擬形象引擎。虛擬形象引擎會同時具備人物模型、相關能力、動作、表情等，虛擬形象的表情可以模擬攝像頭內(nèi)的用戶表情。并且會將其包裝成一套整體的能力，平臺接入時無需專業(yè)游戲開發(fā)人員，只需接入SDK即可快速實現(xiàn)。盡管和真正的VR、沉浸式體驗差距較大，但作為虛擬形象的快捷接入也是邁出了第一步。
VR場景
后續(xù)我們會添加支持VR設備的VR引擎的輸出能力，VR設備支持目前市面上常見的如索尼、HTC、惠普等硬件。
?
以上就是本次分享的內(nèi)容，謝謝！
掃描圖中二維碼或點擊閱讀原文
了解大會更多信息
喜歡我們的內(nèi)容就點個“在看”吧！
超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生總結
以上是生活随笔為你收集整理的陈曦：超低延迟下的实时合唱体验升级的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【多媒体内容与体验创新】
- 下一篇： 【福利解锁Part1】报名参与腾讯云专场