大約一年前，我發表了一篇文章 。 它分析了在弱 PC 上進行雲端遊戲的各種服務的優缺點。 我在遊戲過程中測試了每項服務並分享了我的整體印象。
在這篇文章和其他類似文章的評論中，讀者經常分享他們對各種遊戲服務的印象。 對於同一件事，常常有相反的意見。 對於某些人來說，一切都是完美的，但對於其他人來說，他們因為滯後和凍結而無法玩。 然後我想到了在不同條件下評估這些服務的品質——從理想到糟糕。 我們談論網路質量，因為用戶不能總是吹噓快速且無故障的通訊通道，對吧？ 一般來說，削減的是透過模擬不同網路運行品質來評估服務。
到底有什麼問題呢？
如上所述 - 作為連接。 更準確地說，是在遊戲過程中丟包。 損失越高，玩家遇到的問題越多，他對遊戲的滿意度就越低。 但很少有人擁有理想的通訊通道，例如連接設備的光纖和專用互聯網，並且不由公寓大樓的所有居民共享。
作為參考，在連線速度為 25 Mbit/s 的情況下，每幀傳輸 1 幀需要 40-50 個資料包。 遺失的資料包越多，影像品質就越低，延遲和凍結就越明顯。 特別嚴重的情況下，根本就無法玩。
當然，雲端服務本身不能以任何方式影響用戶通道的寬度和穩定性（當然，儘管那會很棒）。 但可以設想不同的方法來解決溝通問題。 我們將在下面看到哪些服務最能解決這個問題。
我們到底在比較什麼？
普通 PC（Intel i3-8100、GTX 1060 6 GB、8GB RAM）、GeForce Now（俄語版本） 伺服器位於莫斯科）， , , , 。 在 Stadia 以外的所有服務上，我們研究了《巫師》中的遊戲品質。 在撰寫本文時，Google Stadia 還沒有這款遊戲，因此我不得不測試另一款遊戲 - 奧德賽。
測試條件和方法是什麼？
我們從莫斯科進行測試。 提供者 - MGTS，資費 500 Mbit/s，有線連接，而非 WiFi。 我們將服務中的圖形品質設定設為預設解析度 - 全高清。
使用程式 我們模擬網路問題，即各種類型和大小的資料包遺失。
均勻單次損失。 這是只有 1 個資料包遺失且遺失分佈或多或少均勻的情況。 因此，統一遺失 10% 意味著在 100 個資料包中，每 10 個資料包就會遺失，但始終只有 1 個資料包。 當從客戶端到伺服器的通道出現失真（屏蔽）時，該問題通常會出現。
我們測試統一損失為 5%、10%、25%。
質量損失不均勻，在任何時刻連續 40-70 個資料包立即遺失。 這種損失最常發生在使用者或提供者的網路設備（路由器等）出現問題時。 可能與用戶-伺服器通訊線路上網路設備的緩衝區溢位有關。 牆厚的WiFi也會造成這樣的損失。 由於大量設備的存在而導致無線網路擁塞是另一個原因，這對於辦公室和公寓大樓來說非常典型。
我們測試了0,01%、0,1%、0,5%的不均勻損失。
下面我對所有這些案例進行分析，並附上視訊比較以便清楚起見。 在文章末尾，我提供了來自所有服務和案例的原始、未經編輯的遊戲視頻的鏈接- 在那裡您可以更詳細地查看工件以及技術信息（在除Stadia 之外的所有服務中，來自技術部門的數據）控制台被記錄；Stadia 沒有找到這樣的）。
我們走吧！
以下是7個壓力測試場景和帶有時間戳的影片（影片是相同的，為了方便起見，每個點都從正確的時刻開始觀看）。 貼文的最後是每項服務的原始影片。 一個好朋友幫我製作了這個視頻，為此我感謝他！
場景#1。 理想的條件。 網路零損耗
一切都是理想世界中該有的樣子。 沒有連線問題，沒有一次中斷，沒有乾擾，您的存取點就是網路的燈塔。 在這樣的溫室條件下，幾乎所有測試參與者都表現良好。
個人計算機
對於每個場景，我們都從電腦遊戲中獲取了片段作為參考。 顯然，網路品質不會對其產生任何影響；遊戲在本地 PC 上運行。 這些幀的存在回答了「在雲端玩遊戲與在 PC 上玩遊戲是否有區別」的問題。 在理想條件下，就我們而言，大多數服務都感覺不到這一點。 下面我們不會寫任何關於 PC 的內容，只要記住它的存在即可。
現在的GeForce
一切都很好，畫面清晰，過程順利，沒有條帶。
渦流
漩渦正在破壞我們的理想世界。 他立即開始遇到問題——這張照片比其他所有照片都糟糕，而且「煞車」清晰可見。 一個可能的問題是遊戲伺服器距離莫斯科很遠，而且遊戲伺服器上的硬體似乎較弱並且不能很好地處理全高清。 Vortex 在所有測試中表現不佳。 如果有人在玩 Vortex 時獲得了積極的體驗，請寫下評論，分享您在哪裡玩以及一切結果如何。
遊戲鍵
一切都很好，就像在本地電腦上一樣。 明顯的問題，例如凍結、滯後等。 不。
大聲播放
服務表現非常好，沒有明顯的問題。
體育場
儘管Google在俄羅斯聯邦沒有伺服器，但Google的遊戲服務運作良好，而且一般來說，Stadia 在俄羅斯也沒有正式運作。 不過，一切都很好。 當然，遺憾的是，《巫師》在比賽時還沒有在 Stadia 上播放，但你能做什麼，他們拿了《奧德賽》——同樣要求很高，同樣是關於一個砍人和動物的人。
場景二。 統一損失2%
在此測試中，在 100 個資料包中，大約有 20 個資料包遺失。 讓我提醒您，渲染一幀需要 40-50 個資料包。
現在的GeForce
Nvidia 的服務很好，沒有任何問題。 圖片比 Playkey 的有點模糊，但《巫師》仍然可以玩。
渦流
這就是事情變得更糟的地方。 原因尚不完全清楚；很可能沒有提供冗餘或冗餘很少。 冗餘是轉發資料的抗雜訊編碼（FEC - 前向糾錯）。 當資料因網路問題而部分遺失時，該技術可以復原資料。 它可以透過不同的方式實現和配置，從結果來看，Vortex 的創建者並沒有成功。 即使損失極小，您也無法繼續遊戲。 在隨後的測試中，Vortex 就「死了」。
遊戲鍵
一切都很好，與理想狀態沒有顯著差異。 也許該公司的伺服器位於進行測試的莫斯科有幫助。 好吧，也許上面提到的冗餘配置會更好。
大聲播放
儘管丟包率相對較低，但該服務突然變得無法播放。 有什麼問題嗎？ 我假設 Loudplay 使用 TCP 協定。 在這種情況下，雖然沒有確認包裹收到，也沒有發送其他包裹，但係統會等待遞送確認。 因此，如果包裹遺失，將無法確認其已送達，也不會發送新包裹，圖片將變為空白，故事結束。
但如果使用UDP，則不需要確認接收資料包。 據判斷，除了Loudplay之外，其他服務均使用UDP協定。 如果不是這種情況，請在評論中糾正我。
體育場
一切都可以玩。 有時，圖片會變得像素化，並且反應延遲極小。 也許抗噪音編碼不能完美工作，因此當整個串流可播放時會出現輕微的偽影。
場景二。 統一損失3%
每 10 個資料包就有 XNUMX 個資料包遺失。 這對於服務來說已經是一個挑戰。 為了有效地處理此類遺失，需要技術來恢復和/或重新發送遺失的資料。
現在的GeForce
GeForce 的視訊串流品質略有下降。 據我們所知，GFN 正在透過嘗試緩解網路問題來應對這些問題。 此服務降低位元率，即資料傳輸的位數。 透過這種方式，他試圖減少他認為質量不夠高的網路的負載並保持穩定的連接。 穩定性確實沒有問題，但影片品質明顯受到影響。 我們看到圖像有明顯的像素化。 好吧，由於建模假設持續丟失 10% 的資料包，因此降低位元率並沒有真正幫助，情況不會恢復正常。
在現實生活中，圖片很可能不會一直很糟糕，而是浮動的。 損失增加－影像變得模糊； 損失減少了——影像恢復正常，等等。 當然，這不利於遊戲體驗。
遊戲鍵
沒有什麼特殊問題。 該演算法可能會檢測網路上的問題，確定丟失的程度，並更多地關注冗餘而不是降低比特率。 事實證明，當均勻損失 10% 時，影像品質幾乎保持不變，使用者不太可能注意到這種損失。
大聲播放
它不起作用，它只是沒有開始。 在進一步的測試中，情況又重演了。 據判斷，該服務無論如何都不能適應網路問題。 或許 TCP 協定是罪魁禍首。 稍有損失就會導致服務完全癱瘓。 當然，對於現實生活來說不太實用。
渦流
也是大問題。 你不能在這樣的條件下玩遊戲，儘管圖片仍然存在並且角色繼續奔跑，儘管有些急促。 我認為這都是因為執行不力或缺乏冗餘所造成的。 資料包經常丟失並且無法恢復。 結果，影像品質下降到無法播放的水平。
體育場
不幸的是，這裡一切都很糟糕。 流程中存在中斷，這就是為什麼螢幕上的事件會突然發生，使得遊戲變得極其困難。 可以假設，與 Vortex 的情況一樣，問題的出現是由於冗餘很少或沒有冗餘。 我諮詢了幾個「知情」的朋友，他們說 Stadia 很可能正在等待框架完全組裝完成。 與 GFN 不同的是，它並沒有試圖透過完全降低位元率來挽救局面。 結果，沒有偽影，但出現了凍結和滯後（相反，GFN 的條紋/滯後較少，但由於位元率較低，影像完全沒有吸引力）。
其他服務似乎也不等待框架完全組裝完畢，而是用舊框架的碎片替換缺少的部分。 這是一個很好的解決方案，在大多數情況下，用戶不會注意到捕獲（每秒更改 30 多個幀），儘管有時可能會出現偽影。
場景二。 統一損失4%
每四個資料包就會遺失一次。 它變得越來越可怕和有趣。 一般來說，在這種「洩漏」連線的情況下，幾乎不可能在雲端進行正常的遊戲。 儘管一些比較參與者能夠應對，儘管並不完美。
NFG
問題已經相當明顯。 圖片像素化且模糊。 你仍然可以玩，但這根本不是 GFN 一開始提供的。 這絕對不是精美遊戲該玩的方式。 美已經無法被欣賞。
遊戲鍵
遊戲進行得很順利。 雖然畫面稍微受到影響，但還是很平滑。 順便說一句，左上角是顯示恢復了多少遺失資料包的數字。 如您所見，96% 的資料包已恢復。
大聲播放
沒有開始。
渦流
即使你有非常強烈的願望也無法玩，凍結（凍結圖像，從新片段恢復視訊串流）甚至更加明顯。
體育場
這項服務幾乎無法播放。 原因上面已經說過了。 等待框架組裝時，冗餘是最小的，有這樣的損失是不夠的。
場景#5。 不均勻損失0,01%。
每 10 個資料包，連續遺失 000-1 個資料包。 也就是說，我們大約丟失了 40 幀中的 70 幀。 當網路設備的緩衝區已滿並且所有新資料包都被簡單地丟棄（丟棄）直到緩衝區被釋放時，就會發生這種情況。 除 Loudplay 外，所有比較參與者都在一定程度上彌補了此類損失。
NFG
畫面品質有所下降，變得有些渾濁，但一切都相當可玩。
遊戲鍵
一切都很好。 畫面流暢，成像良好。 你可以毫無問題地玩。
大聲播放
最初的幾秒鐘有一個畫面，英雄甚至跑了。 但與伺服器的連線幾乎立即就斷開了。 哦，這個TCP協定。 第一次損失就從根本上削弱了服務。
渦流
觀察到常見問題。 飾帶、滯後，僅此而已。 在這樣的條件下打球會非常困難。
體育場
可玩。 小幅下降很明顯，圖片有時會出現像素化。
場景6。 不均勻損失0,1%
對於 10 個資料包，連續遺失 000-10 個資料包 40 次。 結果是 70 幀中我們遺失了 10 幀。
我馬上就會說，大多數服務都有明顯的問題。 例如，圖片會抽搐，因此冗餘在這裡沒有幫助。 也就是說，使用冗餘技術時有正面作用，但很小。
事實是，對使用者操作和遊戲本身的反應時間是有限的，視訊串流必須是連續的。 儘管服務做出了任何努力，但都不可能將流恢復到可接受的品質。
出現偽影（試圖補償資料包遺失，沒有足夠的資料）和影像抖動。
NFG
影像品質明顯下降，位元率明顯降低，而且相當顯著。
遊戲鍵
它處理得更好 - 可能是因為冗餘配置得很好，加上比特率演算法認為損失不是很高，並且不會將圖片變成像素化的混亂。
大聲播放
沒有開始。
渦流
它開始了，但圖像品質很糟糕。 抽搐和下沉非常明顯。 在這樣的條件下，幾乎不可能打球。
體育場
抽動現象清晰可見，這是冗餘不足的明確指示。 圖片凍結，然後出現其他幀，視訊串流中斷。 原則上，如果你有強烈的願望並且有自我折磨的臨床傾向，你就可以玩。
場景7。 不均勻損失0,5%
對於 10 個資料包 000 次，連續遺失 50-40 個資料包。 我們在 70 幀中丟失了 50 幀。
「一團糟」班級的情況。 你的路由器冒火了，你的 ISP 癱瘓了，你的電線被老鼠咬壞了，但你仍然想在雲端玩。 您應該選擇哪種服務？
NFG
玩起來已經非常困難了——比特率已經大大降低了。 幀丟失了，我們看到的不是正常的圖片，而是“肥皂”。 幀未恢復 - 沒有足夠的資訊用於恢復。 如果 GFN 提供恢復的話。 該服務積極嘗試透過比特率來挽救局面的方式引起了人們對其是否願意使用冗餘的懷疑。
遊戲鍵
存在幀失真，影像抽搐，即各個幀的元素重複。 可以看出，大部分「破碎」的框架都是由前一個框架的碎片恢復的。 也就是說，新幀包含舊幀的一部分。 但影像或多或少是清晰的。 你可以控制它，但在動態場景中，例如在打鬥中，你需要良好的反應，這是很困難的。
大聲播放
沒有開始。
渦流
它開始了，但最好不要開始——你不能玩它。
體育場
在這種情況下服務是無法播放的。 原因是需要等待框架組裝且冗餘性差。
誰是贏家？
當然，評級是主觀的。 大家可以在評論裡爭論。 嗯，第一個地方當然是本地 PC。 正是因為雲端服務對網路品質極為敏感，而這種品質在現實世界中又相當不穩定，所以你自己的遊戲電腦仍然無法匹敵。 但如果由於某種原因它不存在，那麼看看評級。
- 本地電腦。 預期的。
- 遊戲鍵
- 現在的GeForce
- 谷歌Stadia
- 渦流
- 大聲播放
作為結論，我再次提醒大家，雲端遊戲在抵抗網路問題方面發揮主要作用的是：
- 使用什麼網路協定。 最好使用UDP來傳輸視訊串流。 我懷疑 Loudplay 使用 TCP，儘管我不確定。 但你看到了測試結果。
- 是否實施了抗噪音編碼？ （FEC - 前向糾錯，也稱為冗餘）。 它適應丟包的方式也很重要。 正如我們所看到的，影像的品質很大程度上取決於實施。
- 如何配置比特率自適應。 如果服務主要以位元率來保存情況，這對影像有更大的影響。 成功的關鍵是比特率操縱和冗餘之間的微妙平衡。
- 如何設定後處理。 如果出現問題，框架將被重置、恢復或用舊框架的碎片重新組裝。
- 伺服器與遊戲玩家的距離和硬體功率 也會顯著影響遊戲的質量，但這對於理想的網路也是如此。 如果伺服器的 ping 值太高，即使在理想的網路中，您也無法舒適地玩遊戲。 本研究中我們沒有進行 ping 實驗。
正如所承諾的，這是鏈接.
來源： www.habr.com