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