隨著遊戲及軟體雲端化執行能力的支援，大型遊戲和軟體可以在瀏覽器、輕客戶端以及小程式中執行，在擴充套件了使用場景邊界的同時，也為遊戲和軟體探索雲原生實現提供了基礎。騰訊云云渲染 PaaS 提供了基於 WebRTC 的萬人級互動互動的雲原生能力，包括操作許可權轉移管理、多人語音會話等，在本次LiveVideoStackCon 2021北京站，騰訊雲專家工程師 雲渲染技術負責人——王超向我們分享了互動新玩法上的技術實現。
文 | 王超
整理 | LiveVideoStack
大家好，我是來自騰訊雲的王超，我2011年入職騰訊，待了將近11年，之前也一直都在從事音影片相關的工作，最早是在QQ的後臺音影片，到騰訊雲影片直播場景的建設等，從去年開始我的主要投入到整個行業內相對比較新的方向，包括雲原生能力在內的初步技術探索，這也是我今天分享的主題——互動雲渲染，主要是和大家探討一下雲原生渲染的能力，以及可能會遇到的問題。
今天分享的大概內容，會從什麼是雲渲染開始，介紹雲渲染最基礎的互動層面的核心技術，主要會從編碼和傳輸兩個方面進行分析。第三塊是雲原生渲染和互動雲渲染能力的探索，看看我們能在雲渲染上做出什麼內容。
1. 雲渲染介紹
首先介紹一下雲渲染。
如果用一句話介紹，雲渲染就是把我們的軟體和遊戲放到雲端執行，透過全端的SDK支援接入，使用者可以跨任何平臺實現接近於本地延遲及畫質的操作體驗。左圖呈現的是一個成功案例，它在小程式裡透過雲渲染平臺，接入到我們整個的服務。後端執行的軟體是基於UE引擎開發的，我們將深圳南頭古城進行1比1的數字孿生復原，展現的場景和實地景點是一模一樣的，同時還有很多互動內容，包括直接購票、評論等等，主要探索的是線上線下結合的互動體驗。除此之外，我們也兼顧了手機解析度自適應等方面。
如果從更細的層次來看，雲渲染是什麼呢？雲渲染是我們基於底層內容、資源、排程的服務。構建中間層的雲端遊、雲手遊、雲應用的PaaS能力，最終以更SaaS或者解決方案的形式推出一些成品。
這裡列舉了三個例子，虛擬人就是雲端執行的一個人物模型，可能是像真人一樣的，也可能是卡通的，它的表情和動作會跟著真實人的動作實時反饋。虛擬人的應用場景非常廣泛，比如在會議，不想用真人的方式顯現出來，或者主播想要用虛擬的形象代替真人去呈現等等。
第二個是廣告試玩，我們現在更多的是運用在各個平臺的資訊流，普通的廣告可能就是一張圖片或一段影片，使用者並不能知道具體的內容是什麼，而廣告試玩可以幫助廣告投放商，在資訊流中直接開啟並且體驗內容。數字孿生在之前提到過，就不再展開了，整體的產品能力層次大概就是這樣。
2. 雲渲染核心技術
基於現在的產品能力，接下來讓我們看看它是如何實現的，到底需要做些什麼，又涉及哪些核心的技術。
2.1 雲渲染能力概覽
上圖是雲渲染能力的概覽，左邊是我們整體的平臺能力，底層有一些支撐的系統，包括運營系統，監控服務，這些都是非常底層的，一般使用者不會關注到。第二個是一些硬體資源，比如GPU資源、網路資源、邊緣節點資源等，對它們進行整體的管理和排程。基於這個能力再去構建內容平臺，比如，一些客戶自己有軟體，可能就會涉及內容包的上傳、版本管理、自動更新以及內容分發。再上一層，就是把這些硬體資源和內容管理資源結合起來做一個排程，同時也會有一些不同使用者之間的配置差異管理，如果在有些場景下適用性沒這麼強，就還會有更通用的指令碼，實現更定製化的能力支援。
右邊上面是我們真正雲渲染實力的體現，是雲渲染互動中可能會涉及到的一些功能，比如，資料特傳，分別率自適應等能力。對於不同的平臺，都會提供雲渲染的例項，透過SDK進行實時互動。這裡使用了WebRTC，像前面也看到的小程式本身可以理解為一個網頁，更多的就是Web端的呈現，所以我們希望更多的使用者可以在輕便的網頁上進行訪問，不一定是Native App去做這樣的支援。那如果我們選擇私有協議就很難在Web端做擴充，只有選擇一個業界公認的、標準的協議WebRTC。基於WebRTC的標準能力，我們也可以做一些深度最佳化，在Native端提供比Web端更深層次的最佳化能力。
2.2 雲渲染核心流程
完整來看，左邊大概就是整體雲渲染的層次，右邊就是SDK的層次。位於底層的GPU，常見的就是英偉達的GPU，上層OS一般是Windows、安卓這種，再上面有一個裝置驅動。真實使用者和客戶提供的軟體在上層進行執行，而我們的服務就是在軟體執行時，透過Capture層捕獲渲染的資料，再透過編碼器編碼出來真實的音影片資料傳遞給WebRTC層，WebRTC層就透過音影片資料流傳送給SDK，SDK獲取資料後會解碼做渲染，底層能力平臺相關的東西，我們封裝在SDK裡，都會遮蔽掉。
因為是互動的互動過程，使用者還會有一些反饋操作，比如滑鼠、鍵盤、手機觸控式螢幕的事件，這些事件的回饋，我們都透過資料通道Datachannel往WebRTC回傳，應用層獲取的操作會把這些資料往裝置驅動發，裝置驅動收到資訊後其實是傳給OS的，OS最終以某種形式傳給軟體、遊戲，軟體和遊戲會對操作進行真實響應，畫面就會產生相應變化。按剛剛說的整個流程，大家就都能看到畫面的變化過程，這就是我們真正核心的東西。
2.3 雲渲染延遲分析
剛剛看來核心流程，現在從細分來看一下整體的延遲。雲渲染說到底是要提供接近於本地平臺原生的體驗能力，是有兩大非常重要的東西，一個是延遲，一個是畫質。延遲和畫質之間又有相互矛盾的地方，接下來就來分析一下。
上圖是簡化的流程圖，左邊透過採集端採集到畫面，然後做影片畫面的編碼進行傳輸，再到終端做解碼和渲染。圖中佔比比較大的就是編碼、傳輸和解碼，這也是真實影響延遲非常重要的因素。
從採集端來看，耗時會比較穩定，一般是2ms左右，編碼耗時就和其他東西有相關性，採用的編碼方式、引數、質量都會影響到耗時，而傳輸就包括RTT和RTT裡的收發包JitterBuffer都會影響到延遲。解碼端可控的會比較少，更多依賴於編碼引數，但也有些場景，比如預設的硬解解碼策略，並沒有啟用低延遲的解碼策略，所以這裡可能需要進行一些低延遲的引數設定，來降低解碼端的延遲。
從編碼質量上來看，主要是編碼格式，常見的是H.264、H.265，H.265的編碼在同等位元速率下肯定是要優於H.264，但H.265又有一些相容性的問題，比如WebRTC並沒有做對於H.265的支援。所以編碼格式只是其中一個因素，編碼器本身的BD-rate也會影響整體編碼質量。還有位元速率和GOP，理論上來說，如果GOP越大，單位幀的位元速率就會越大，因為I幀數量越少，最理想的方式就是從頭到尾沒有GOP沒有I幀，但這種情況一般不會出現。我們考慮的就是採用無限GOP的方式，出現丟包、破圖時，透過PLI的方式去反饋，傳一個I幀，實時減少I幀在整體影片流中位元速率的佔比，提升畫面質量。
2.4 編碼方式分析
接下來介紹一下編碼方式，軟體或遊戲的渲染方式是在GPU中進行的，GPU裡面簡單分為渲染單元和解碼單元。一般來說這兩單元是相互隔離的，資源都是獨立的，相互之間不會有衝突。軟體包括遊戲都是使用渲染單元，渲染單元之後所有資料都生成在視訊記憶體中，如果能在GPU視訊記憶體中直接拿編碼單元編碼其實是最理想的，因為能看到在同一個硬解層面做這個事情，所有資料都是共享的。這個實踐雖然是理想的實踐，但也會有一些瓶頸，比如因為一張GPU卡只跑一路，編碼肯定能跟上，但一張GPU跑多路，那編碼效能整體可能就跟不上了。
所以我們也要考慮多種方式，一種方式是用記憶體做CPU的軟編，這時資料要從視訊記憶體中拷到記憶體中再做軟編。拷的過程中，以1080P的大小來看，1幀大概是8Mib，60幀大概是 480MiB，這個傳輸量以目前PCIe 4.0 x4的速度大約 7.88GB/s。這麼看其實還好，但實際上這是單路，佔整體頻寬的1/16，假設一張GPU卡跑10路，這個佔比就非常高了，整體會出現比較大的衝突。這時發現用軟編的方式分析，本身也會有資料複製和其他衝突瓶頸在其中。
另外，可以用硬體解決GPU編碼能力不足的問題，比較常見的方式是ASIC。它本身並沒有直接從視訊記憶體中獲取到資料，所以一樣會有透過PCIe通道進行資料傳輸。這個通道理論上來說是一個理想的通道，它使用了GPUDirect的方式能實現直接透過PCIe通道往外傳輸。一般傳輸可能會透過記憶體，做一次中轉，然後再透過PCIe到ASIC卡里做資料傳輸，這樣會經過兩次傳輸，你就算做到最好，也會有至少一次的資料傳輸。
所以，相對來說，最理想的還是GPU硬編，但GPU有各種各樣的限制，那這個到底怎麼選呢？小孩子才做選擇，成年人全都要。各種場景都會有適用性，像GPU渲染能力非常強，編碼能力不足必須要透過其他軟體或硬體支援。當然，如果英偉達或者其他顯示卡供應商，能考慮這種情況，把編碼單元加強到和渲染單元的能力匹配，那我們都可以透過GPU來實現，在現階段只能考慮都要了。
2.5 傳輸最佳化分析
在傳輸方面比較重要的東西，首先關於延遲影響就是RTT，那影響RTT最重要的因素是距離，我們一般透過邊緣節點覆蓋，就近距離排程。當然這個因素也不一定是距離，但距離在很大程度上會反應這個問題。如果遇到距離近RTT也非常高，那隻能作為歷史資訊，儲存下來，做下次排程策略的選擇因素參考。
第二個是網路傳輸，大家可能會有常規看法，在低延遲雲渲染的情況下，我們發包要儘量快，編碼出來的包採集完資料要把所有包快速往外發，這其實是有些同學常規的錯誤理解。因為編碼出來的資料量瞬時會非常大，比如以1080p 60幀來看，實際上是16ms/幀，是有間隔性的，並不是從頭到尾都是均勻的資料，中間可能還會穿插著I幀，整體資料量會非常大。不應該在低延遲的情況下把Pacing去掉，Pacing策略要針對場景做特定最佳化，減少Pacing對整體網路擁塞的影響。如果沒有Pacing，真的會引起突發的卡頓，這個體驗是非常不好的，也會影響到整體頻寬的評估。
第三個是頻寬評估演算法，頻寬評估出來才能真實決定位元速率，位元速率多少又決定畫質。在WebRTC裡，頻寬評估演算法有兩種，TCC和REMB，REMB在接收端，但在官方已經被放棄了，TCC在傳送端，雲渲染正好就是資料傳送端，適合我們進行深度的最佳化。TCC預設的策略不一定完全適合雲渲染，我們可能要做一些策略的調優，比如敏感度，當位元速率突然下降，要快速地調低位元速率，減少延遲，頻寬恢復是不是要快速，這些都要做引數調優，控制預測的準確性。
3. 互動雲渲染
前面介紹的都是1v1的雲渲染，但我們更多的探索是多人接入雲渲染。
3.1 互動雲渲染是什麼
上圖是我們互動雲渲染的探索方向，左圖是應用的截圖，主要和直播場景結合，比如主播在玩遊戲時想和粉絲進行互動，目前手段還是很有限的。如果主播是用雲渲染玩遊戲，那粉絲在觀看直播後覺得有興趣，可能會透過上麥接力等方式，進入雲渲染環境和主播進行雲互動，包括許可權申請，角色變化等等。
3.2 互動雲渲染難點分析
整體的邏輯架構圖氛圍兩部分，一邊是雲渲染示例，下面會接入N個玩家，一邊是各大廠商都會有的雲直播，觀眾一般都會在各個直播平臺觀看直播內容。雲渲染要和直播打通的就是混音推流能力，這時候的推流不能是簡單的遊戲軟體內的音影片畫面，還要把各個玩家語音資料做混音往外推。觀眾觀看時，就能看到遊戲內容和玩家之間的對話語音，他可以選擇加入遊戲進入到雲渲染例項中，這時他看到的畫面，就和主播實時看到的一模一樣了，操作許可權等能力也是一樣的。
使用者加入後，我們會遇到兩個非常重要的問題，一個是使用者玩家非常多，分佈環境差異大，距離非常遠，鏈路差異也很大，我們要怎麼讓每個使用者都低延遲呢？第二個在於每個使用者的頻寬不一樣，給到的位元速率也不一樣，頻寬可能還會產生波動，我們要怎樣支援每個使用者呢？這是我們互動雲渲染中必然會遇到的兩個問題，接下來和大家一起探討一下解決方案。
3.3 互動雲渲染的延遲控制
前面說到，希望玩家能接入到雲渲染例項中，但實際上我們不可能讓所有玩家接入到同一個雲渲染例項，一個雲渲染例項只能在某一個地方，如果例項在北京，那北京的使用者沒有問題，但廣州的使用者想接距離就非常遠了。同時也受到出口頻寬的限制，當有幾十、上百或更多使用者時，單口負載是接受不了的，就要引入SFU做資料拆分。雲渲染例項透過資料到SFU，每個玩家透過邊緣節點的方式就近接入。
玩家直接連結SFU或者透過邊緣節點連結SFU，會有兩種延遲情況出現，我們要在這兩者之間選擇合適的，最終選擇完也會成為歷史參考資訊，做下次排程的依據。另一方面，當玩家距離邊緣節點非常近，但延遲非常不理想時，我們就要考慮動態鏈路切換，可能切換到別的邊緣節點或者直接連結到SFU。如果要做動態切換，必須要依靠整體上報到排程系統中的資料，排程系統會實時彙總，做策略決策。
3.4 互動雲渲染的位元速率控制
解決延遲方面的問題，就要面臨位元速率的控制。不同使用者接入的邊緣節點不一樣，頻寬可能也不一樣。有些使用者頻寬10Mbps，有些使用者頻寬20Mbps，假設最低頻寬都是比較理想的情況，那沒問題，我們都用10Mbps，可能會有富餘，但影片場景大機率在10Mbps以上看不出有什麼區別，這時沒必要用更高的位元速率了。可是有些使用者頻寬真的很低，那我們在不放棄他們的前提下，有這幾種解決方式。
一種是引入分檔轉碼，但這個肯定會引入額外的延遲，我覺得最少產生一個解碼和一個編碼的2幀延遲，同時還會提升成本。
另一種是編碼上的探索方式SVC(Scalable Video Coding)，普通的編碼只有一層，SVC會把影片資料編碼成多層，一般分三類：幀率級別的分層，假設原始影片是60幀，它透過分層編碼的方式降到15幀依然能播，中間是跳了一些幀；解析度的分層，可能1080p是一檔，720p是一檔，480p是一檔，不同的層次解碼出來不同分別率；畫質分層，分別率不變，不同層次解出的畫面是有差異的，最低層次的畫面比較差，所有層次一起解，畫面就比較好。這個看起來是非常理想，非常適合我們互動雲渲染，每個玩家如果真的按照分層解碼的話，這個問題就解決了。但實際上SVC需要在編碼端和解碼端上支援，同時因為我們是WebRTC，在Web上要支援，在瀏覽器上本身也要支援。目前在WebRTC這些能力的支援還是比較受限的。
另一種是Simulcast，有點像SVC，不一樣的是源端編碼編了多種碼流，10Mbps的碼流一條流，5Mbps的碼流一條流，兩條流一起上傳SFU，透過選路的方式，頻寬高的選擇碼流高的，頻寬低的選低的。這種會引入另一個問題，它對編碼的整體要求非常高，編碼能力足夠強就沒有問題，但編碼能力不夠強就會造成一定的負擔。當然這也是一種可選的方式，從整體策略來看，第一種和第三種會是我們的優先選擇。
3.5 多例項的互動雲渲染
前面說的是多個人接入同一個互動雲渲染例項，如果要把多人接入多個例項是要怎麼實現呢？就是在原有架構上擴充套件一下，整體會類似一個房間的概念，每個使用者自己操控自己的雲渲染例項，中間有一個軟體伺服器。假設這是一整個遊戲，每個雲渲染例項是遊戲中的不同角色，你操控的這個雲渲染例項是虛擬人形象，和你真人的動作表情都能對映，並且這個虛擬人是在第一人稱視角，你自己不能看到這些動作表情，但其他人都能看到，就有一點電影《頭號玩家》的方式。
3.6 互動雲渲染之上
基於雲渲染本身的能力，我們實現了數字虛擬人、Cloud AR、Cloud VR。AR、VR之前沒提到，我們現在的AR、VR都比較依靠於裝置，使用者需要頻繁地更新裝置，但如果把這個搬到雲端，使用者本地只需要做解碼能力的支援，網路頻寬更新換代也是非常快的，那這樣就可以實現輕客戶端的能力，把所有渲染都放到雲端。現在整體結合看是否就在真實地探索元宇宙的雛形。
以上就是我本次分享的所有內容，謝謝。
講師招募
LiveVideoStackCon 2022 音影片技術大會 上海站，正在面向社會公開招募講師，無論你所處的公司大小，title高低，老鳥還是菜鳥，只要你的內容對技術人有幫助，其他都是次要的。歡迎透過 [email protected] 提交個人資料及議題描述，我們將會在24小時內給予反饋。
