點擊上方“LiveVideoStack”關注我們
隨着遊戲及軟件雲端化運行能力的支持，大型遊戲和軟件可以在瀏覽器、輕客戶端以及小程序中運行，在擴展了使用場景邊界的同時，也爲遊戲和軟件探索雲原生實現提供了基礎。騰訊云云渲染 PaaS 提供了基於 WebRTC 的萬人級互動交互的雲原生能力，包括操作權限轉移管理、多人語音會話等，在本次LiveVideoStackCon 2021北京站，騰訊雲專家工程師 雲渲染技術負責人——王超向我們分享了互動新玩法上的技術實現。
文 | 王超
今天分享的大概內容，會從什麼是雲渲染開始，介紹雲渲染最基礎的交互層面的核心技術，主要會從編碼和傳輸兩個方面進行分析。第三塊是雲原生渲染和互動雲渲染能力的探索，看看我們能在雲渲染上做出什麼內容。
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小時內給予反饋。
喜歡我們的內容就點個“在看”吧！
本文分享自微信公衆號 - LiveVideoStack（livevideostack）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。