編者按：從2019年開始，云游戲的熱度迅速上升，云游戲平臺如雨后春筍般出現。然而，目前還未出現一個影響力大的標志性平臺，并且大家對云游戲的預期與云游戲的真實現狀有出入。那么，如何才能為玩家提供高畫質、超流暢和低時延的游戲體驗呢？今天LiveVideoStack邀請到了智杰融興的吳振永老師，為我們介紹云游戲音視頻體驗和優化實踐。

文/吳振永

整理/LiveVideoStack

大家好！我是吳振永，來自智杰融興科技有限公司，很高興能跟大家做一次分享。我和我的團隊從2019年開始做云游戲里的技術研發和平臺的運營。今天，我分享的主題是：云游戲音視頻體驗優化實踐。

今天，我分享的內容主要分為四個部分。首先，介紹一下我們團隊當前的工作。然后，介紹云游戲的現狀。接著，介紹一些技術架構。最后，和大家分享我們在實踐過程中遇到的一些“坑”和應對方法。

01  自我介紹

首先，介紹一下我的公司。

智杰融興主要提供實時互動視頻云技術服務，為客戶提供相應的技術能力。實時互動視頻云技術可以應用于很多場景，比如在線教育、視頻會議等。目前，我們團隊主要專注于三個方向：云游戲、云電腦和云手機。從2019年開始，云游戲、云應用的熱度迅速上升，許多做游戲開發、游戲發行、游戲平臺的合作伙伴都想參與其中。然而，實時互動視頻云技術涉及的技術環節較多，而合作伙伴更希望專注于自身的業務。因此，我們把自己定義為技術服務提供商，幫助合作伙伴快速使用相關的技術服務。左下圖是我們做的云電腦，主要供做設計的合作伙伴使用。右圖展示了我們為做游戲平臺的合作伙伴提供的服務。

02  云游戲現狀

接下來，介紹云游戲的現狀。

從2019年底開始，受到谷歌的影響，云游戲的熱度迅速上升。當時，谷歌推出了Stadia，整個行業都沸騰了，不管是行業參與者還是媒體都對其非常關注，聚集了很多參與者。于是，從2019年開始，云游戲平臺如雨后春筍般出現。從圖中可以看到，有技術、有流量、有內容、有資金的各方都開始布局云游戲。圖中還列出了目前行業里做云游戲較好的App?，F在打開應用商店，搜索云游戲或云電腦，會出現一百多個相關App。雖然在2019年云游戲的熱度非常高，但現在云游戲的熱度已經有所降低，大家轉而開始關注元宇宙。

目前，云游戲平臺越來越多，參與者越來越多，但還未出現一個影響力大的標志性平臺。當前，大家對云游戲的預期與云游戲的真實現狀有出入。在云游戲中，除了游戲內容的吸引力和運營手段外，玩家更關注畫質、流暢度和時延。隨著電子游戲的發展，畫質也變得越來越好，可到達2K、4K，甚至8K的水平。這是因為玩家對畫質的要求越來越高。此外，玩家對流暢度也有一定要求。流暢度可以映射為幀率，30fps和60fps已經成為了標配。對于有電競級要求的玩家來說，幀率需要達到120fps（達到144fps則更好）。除了對流暢度有要求外，玩家對時延也有要求。云游戲包含了音視頻的技術，但與點播、直播不同的是，云游戲對時延的要求非常高。對于視頻點播和直播數據傳輸（音視頻技術的傳統應用場景），可以將其吞吐做得很大，或使用各種加速技術將管道充滿。但在云游戲中，畫面是實時生成的，因此要保證持續性的低時延可控傳輸。此時若只是單純增大物理帶寬會無法完全滿足玩家對時延的訴求。

玩家對云游戲有高畫質、超流暢和低時延的要求，希望有類似于本地化游戲的體驗。然而，現實中會出現網絡丟包、延遲抖動的情況，并且我們還要考慮到運營中的成本控制的問題。因此，面對玩家對業務的訴求或預期與網絡的現實情況有出入的情況，我們要尋求合適的解決方法。目前，行業里的伙伴一直在探索如何在當前的網絡情況下，提供更好的游戲體驗。

03  技術架構

接下來，介紹一下整體的技術架構。

圖中展示了整體的技術框架。從底層來看，我們實現了算力和存儲的接入（包括自有的算力和第三方的算力）。然后，在底層的上一層中我們搭建了游戲的服務。接著，在服務層的上一層中實現平臺的調度的管理，為客戶提供SDK實現快速接入和業務的快速對接。在其上一層，我們可以支撐各類型的應用，比如云游戲、云桌面、云應用和云聯運等，實現不同的業務。其中，與音視頻直接相關的是各端SDK與GS服務間的流化傳輸。

目前在音視頻的處理中，主要是基于RTC框架來運行。當游戲接入服務端后，通過游戲并行渲染和虛擬設備將游戲的音頻、視頻、操控和存儲進行分離，做到單系統環境下多游戲并行運行的軟件隔離，然后實現相應的編碼、封包、ICE和擁塞，最后實現與客戶端的跨平臺互通。音視頻是云游戲重要的核心技術之一，未來游戲的形態和音視頻的界限會越來越模糊。目前，行業里已經出現比如游戲直播、圍觀、打賞等比較火熱的場景方案。其中，云游戲的游戲過程是實時流，目前我們默認同時支持四路實時流的接入，即允許四個玩家同時接入平臺進行實時地交互。對于進行游戲圍觀的觀眾，他們看的是直播流，所以在服務端中會同時推五路流。其中，有四路流是實時流，需要各自進行編碼、封包、擁塞控制等處理。還有一路流專門作為直播的推流。在一個大的游戲的氛圍建設中，會提高其曝光度，并增強其互動性、趣味性。因此，多人實時的互動游戲有很大的魅力。

04  優化實踐

接下來，介紹我們在實踐過程中遇到的問題和采取的解決策略（重點介紹我們自己采取的部分策略）。

我們先來看視頻壓縮。提到視頻壓縮，首先想到的是H.264、H.265、H.266或AV1，但在云游戲中我們要考慮更多的因素。比如在考慮編碼效率和解碼效率時，我們要從兩個角度來考慮，分別是時延和消耗。這是因為服務端的計算資源有限，若編碼的時延很大，則不適用于我們的場景。當前從編碼效率和終端接入的情況來看，在短時間內還無法普遍地應用AV1。這是因為不僅要考慮整體的時延，還要考慮計算資源的消耗，其中包含了服務端的編碼和播放端的解碼。在壓縮率方面，我們主要關注相同畫質情況下的碼率，在運行時以H.265為主，以H.264為輔，這樣的選擇與兼容性有關，目前還是存在小部分機型和芯片在解碼265的時候存在大緩沖或者不穩定的問題，特別是一些舊手機和ott設備，所以都需要針對性地進行兼容處理。

之前提到，云游戲對時延非常敏感，那么我們要考慮如何最大程度地降低處理時延。在程序設計中，不同的模塊間有緩沖機制、輪詢機制，這是正常且合理的。但對于游戲業務或強實時業務來說，雖然每個環節只增加了幾毫秒的時延，但所有環節的時延加起來就有幾十毫秒，玩家在操作時就會有不舒服的感覺。因此，在流線化的處理中，我們要快速地傳遞數據，即在畫面渲染后，要快速地進行轉換和編碼。需要特別注意的是畫面的渲染和處理，需要避免 在GPU和CPU間進行拷貝，這個會導致較大的時延和系統開銷，所以要把處理和編碼都放在GPU中進行。這樣在GPU內，可以快速處理渲染后的畫面，并快速地進行數據封包和發送。

緩沖區是另一個需要特別注意的設計。因為有緩沖區存在，就會導致時延的累加。當然，由于網絡中存在丟包現象，所以需要緩存發送的數據，但整個的處理流程中盡量避免緩沖區。其中，在視頻解碼和渲染顯示之間，需要進行必要的緩沖。這是因為在前面的過程中網絡會抖動，處理就會有快有慢。此時玩家觀看導出的畫面時，發現畫面可能會突然出現一個慢動作或快動作，這是因為幀的間隔不穩定。因此在這個環節中，需要進行緩沖處理來保證幀的間隔穩定。所以，在整個處理流程中，要取消緩沖、緩存、定時器機制，采用流化處理快速驅動。

接下來，介紹必要緩沖策略。在數據的整個傳輸過程中（包括解包和最后的處理），會出現波動。如圖所示，藍色的線是一條正常波動的曲線。在正常情況下，波動的曲線是穩定的，但同時也會有突發的情況。

按照常規算法來看，呈現出的應該是橙色曲線的情況。在網絡穩定的情況下，可以降低緩沖的時延。相對地，在網絡出現問題時，可以提高緩沖的時延。最終的波動情況就如橙色曲線那樣。橙色曲線是較平滑和較穩定的，但對于需要快速降低時延的場景來說，還需要進行進一步地優化。

灰色曲線是優化后的結果。當網絡較穩定時，要快速地降低時延。降低時延的程度與抖動的范圍相關。當網絡出現大幅度地抖動時，要快速提高緩沖的時延。此時，玩家會感覺畫面突然跳了一下。畫面出現跳動后，會馬上恢復正常狀態。隨著時間的推移，網絡恢復穩定，如灰色曲線中以更平緩的方式下降。如果連續出現幾次跳變，最后會讓曲線更加平緩。因為根據數據的累積可以發現，網絡的情況比較糟糕。當然，在網絡情況良好的情況下，時延會非常低，基本接近端到端的時延。在網絡情況糟糕的情況下，經過幾次循環后，若還是判定網絡情況糟糕，后續會以更平緩的方式運行?？傊?，這個策略采用了快降，但當出現波動時，會調整斜率來達到平衡穩定。這樣，在網絡情況良好時，時延較低，在網絡情況糟糕時，也可以恢復到比較平衡穩定的狀態。

接下來，介紹在傳輸的序列中，實現的預丟包快速重傳。藍色曲線表示正常網絡傳輸中RTT的曲線。在這條曲線中，通過計算獲得兩條虛線，兩條虛線構成了一個震蕩區間。震蕩區間是隨著時間推移形成的曲線點。在網絡出現抖動時，我們會關注最高點。當最高點的值超過300毫秒、400毫秒甚至更大的值或包出現亂序時，會將其判定為丟包，需要進行數據的快速重傳。但可以看到，此時已經經過了一定的時間，所以對此我們要進行相應地處理。

首先，我們劃定一個震蕩區。震蕩區表示了一個合理的范圍。當網絡出現抖動或接收端沒有接收到預期的數據時，會進行預請求，要求重發一次數據。當真正出現丟包、包發生亂序或包延遲到達時，由于已經進行了預請求來要求重發數據，因此服務端若有這個數據就會快速重傳該數據。此時，可能有2-3個包在傳輸過程中，只要接收到一個包就能還原數據，能將時間線往下推進。

通過預丟包快速重傳的方式，首先判定其丟包或網絡出現問題，不用等待而是要求提前獲取數據。這樣的方式取得了一定的效果。目前在運行時，在整個區間的判定上，將帶寬增加了5%-10%，這會明顯地提高平滑度。需要特別注意的是，重傳（預判）的點位非常重要，這一點若處理不好會導致一直傳輸大量的數據，這就會消耗大量帶寬。

最后，介紹一下多路?；?。玩家在實際玩游戲的過程中，手機連接的可能是場地的WiFi，同時還有4G的網絡。當玩家在場地走動時，WiFi的信號可能會變弱或離開了WiFi的服務區，因此切換到了4G網絡。此時，對于玩家而言，在游戲過程中會感覺發生了網絡斷開。斷開后，會啟動重連或重試機制，這會造成幾秒或十幾秒的卡殼。玩家的直觀感受就是畫面靜止，然后意識到網絡在重連。再過幾秒鐘，會重新連接到網絡?？梢钥闯觯蛻舳说木W絡是不可控的。在實際運行過程中，手機端的用戶在游戲過程中出現連接、斷開的情況接近5%左右，這是正常的現象。這是因為如剛才所說，玩家最開始連接WiFi來玩游戲，當玩家在場地走動導致WiFi信號變弱或離開了服務區，或者玩家在游戲過程中接了電話，都會導致游戲的中斷?？傊?，對于客戶端來說，已經建立連接的網絡發生斷開是正常的現象。

對于服務端來說，情況也是一樣的。在游戲中，玩家可能有開房、跨區和玩家互動的訴求。因此，在節點我們會做多線接入或多端口接入，比如電信、聯通、移動等。在接入過程中，某一個網絡可能會出現問題或抖動，這是正常的。當然，在骨干網上，某一個路由出現擁塞也是正常的。當出現擁塞時，直觀的現象是延遲會發生抖動，丟包也會發生變化?？梢钥吹?，客戶端和服務端的網絡都是不可控的。若網絡斷開則需要重連或恢復，這需要幾秒鐘的時間。此時，玩家會感覺游戲卡殼。

為了優化這個問題，我們設計了多路?；畹臋C制。在客戶端，4G和WiFi會和服務端的多個通道同時建立連接以保持連接狀態，并以一個較高的頻率探測整個路徑的存活狀態。其中，我們引入了中轉方的角色。當出現客戶端和服務端之間的連接被運營商攔截或網絡中斷的情況時，會有第三方作為中轉方進行線路的支撐。如圖所示，我們假設客戶端有兩條線路。一條線路是4G，另一條線路是WiFi。我們假設服務端也有兩條線路（實際有三條線路）。中轉方與客戶端和服務端間也有路徑。其中，有多條路徑處于活躍的狀態。當某條路徑發生丟包或延遲超出允許的區間范圍時，在服務端會馬上通過另一個通道將數據發送出去。在服務端和客戶端，會保證幾條路徑同時都是活躍的，并且持續計算其延遲和丟包。這樣當網絡出現問題時，可以快速選擇另一條路徑。對于客戶端和服務端而言，基本沒有增加消耗。真正增加消耗的是中轉方。這是因為大量設備需要和中轉方建立連接。中轉方在平時不用做事情，但其會維持大量的端口和探測，以此保證路徑是活躍的，從而在發生問題時，能快速接管并保證畫面的流暢度和完整度在預期以內。這在實際運行中，效果還是非常明顯的。從數據統計中可以看到，在單通道的情況下（WiFi或4G），延遲和丟包的比例非常高。在多通道的情況下，鏈路可以得到快速恢復。因此從最終結果來看，玩家獲取的時延和丟包的比例都有所減小。

以上內容介紹了我們遇到的問題和處理的策略。介紹了在復雜的網絡環境下，如何盡最大努力為玩家提供低時延、高畫質的游戲體驗。

以上就是本次分享的主要內容，謝謝大家！