大约一年前，我发表了一篇文章 。 它分析了在弱 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 时获得了积极的体验，请写下评论，分享您在哪里玩以及一切结果如何。
播放键
一切都很好，就像在本地电脑上一样。 明显的问题，例如冻结、滞后等。 不。
大声播放
服务表现非常好，没有明显的问题。
体育场
尽管谷歌在俄罗斯联邦没有服务器，但谷歌的游戏服务运行良好，而且一般来说，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%
每四个数据包就会丢失一次。 它变得越来越可怕和有趣。 一般来说，在这种“泄漏”连接的情况下，几乎不可能在云端进行正常的游戏。 尽管一些比较参与者能够应对，尽管并不完美。
GFN
问题已经相当明显。 图片像素化且模糊。 你仍然可以玩，但这根本不是 GFN 一开始提供的。 这绝对不是精美游戏应该玩的方式。 美已经无法被欣赏。
播放键
游戏进行得很顺利。 虽然画面稍微受到影响，但还是很平滑。 顺便说一句，左上角是显示恢复了多少丢失数据包的数字。 如您所见，96% 的数据包已恢复。
大声播放
没有开始。
涡流
即使你有非常强烈的愿望也无法玩，冻结（冻结图像，从新片段恢复视频流）甚至更加明显。
体育场
这项服务几乎无法播放。 原因上面已经说过了。 等待框架组装时，冗余是最小的，有这样的损失是不够的。
场景#5。 不均匀损失0,01%。
每 10 个数据包，连续丢失 000-1 个数据包。 也就是说，我们大约丢失了 40 帧中的 70 帧。 当网络设备的缓冲区已满并且所有新数据包都被简单地丢弃（丢弃）直到缓冲区被释放时，就会发生这种情况。 除 Loudplay 外，所有比较参与者都在一定程度上弥补了此类损失。
GFN
画面质量有所下降，变得有些浑浊，但一切都相当可玩。
播放键
一切都很好。 画面流畅，成像良好。 你可以毫无问题地玩。
大声播放
最初的几秒钟有一个画面，英雄甚至跑了。 但与服务器的连接几乎立即就断开了。 哦，这个TCP协议。 第一次损失就从根本上削弱了服务。
涡流
观察到常见问题。 饰带、滞后，仅此而已。 在这样的条件下打球会非常困难。
体育场
可玩。 小幅下降很明显，图片有时会出现像素化。
场景 6。 不均匀损失0,1%
对于 10 个数据包，连续丢失 000-10 个数据包 40 次。 结果是 70 帧中我们丢失了 10 帧。
我马上就会说，大多数服务都存在明显的问题。 例如，图片会抽搐，因此冗余在这里没有帮助。 也就是说，使用冗余技术时有积极作用，但很小。
事实是，对用户操作和游戏本身的反应时间是有限的，视频流必须是连续的。 尽管服务做出了任何努力，但都不可能将流恢复到可接受的质量。
出现伪影（试图补偿数据包丢失，没有足够的数据）和图像抖动。
GFN
图像质量明显下降，比特率明显降低，而且相当显着。
播放键
它处理得更好 - 可能是因为冗余配置得很好，加上比特率算法认为损失不是很高，并且不会将图片变成像素化的混乱。
大声播放
没有开始。
涡流
它开始了，但图像质量很糟糕。 抽搐和下沉非常明显。 在这样的条件下，几乎不可能打球。
体育场
抽动现象清晰可见，这是冗余不足的明确指示。 图片冻结，然后出现其他帧，视频流中断。 原则上，如果你有强烈的愿望并且有自我折磨的临床倾向，你就可以玩。
场景 7。 不均匀损失0,5%
对于 10 个数据包 000 次，连续丢失 50-40 个数据包。 我们在 70 帧中丢失了 50 帧。
“一团糟”班级的情况。 你的路由器冒火了，你的 ISP 瘫痪了，你的电线被老鼠咬坏了，但你仍然想在云端玩。 您应该选择哪种服务？
GFN
玩起来已经非常困难了——比特率已经大大降低了。 帧丢失了，我们看到的不是正常的图片，而是“肥皂”。 帧未恢复 - 没有足够的信息用于恢复。 如果 GFN 提供恢复的话。 该服务积极尝试通过比特率来挽救局面的方式引起了人们对其是否愿意使用冗余的怀疑。
播放键
存在帧失真，图像抽搐，即各个帧的元素重复。 可以看出，大部分“破碎”的框架都是由前一个框架的碎片恢复的。 也就是说，新帧包含旧帧的一部分。 但图像或多或少是清晰的。 你可以控制它，但在动态场景中，例如在打斗中，你需要良好的反应，这是很困难的。
大声播放
没有开始。
涡流
它开始了，但最好不要开始——你不能玩它。
体育场
在这种情况下服务是无法播放的。 原因是需要等待框架组装且冗余性差。
谁是赢家？
当然，评级是主观的。 大家可以在评论里争论。 嗯，第一个地方当然是本地 PC。 正是因为云服务对网络质量极其敏感，而这种质量在现实世界中又相当不稳定，所以你自己的游戏电脑仍然无法匹敌。 但如果由于某种原因它不存在，那么看看评级。
- 本地电脑。 预期的。
- 播放键
- 现在的GeForce
- 谷歌体育馆
- 涡流
- 大声播放
作为结论，我再次提醒大家，云游戏在抵抗网络问题方面发挥主要作用的是：
- 使用什么网络协议。 最好使用UDP来传输视频流。 我怀疑 Loudplay 使用 TCP，尽管我不确定。 但你看到了测试结果。
- 是否实施了抗噪声编码？ （FEC - 前向纠错，也称为冗余）。 它适应丢包的方式也很重要。 正如我们所看到的，图像的质量很大程度上取决于实施。
- 如何配置比特率适配。 如果服务主要用比特率来保存情况，这对图像有更大的影响。 成功的关键是比特率操纵和冗余之间的微妙平衡。
- 如何设置后处理。 如果出现问题，框架将被重置、恢复或用旧框架的碎片重新组装。
- 服务器与游戏玩家的距离和硬件功率 也会显着影响游戏的质量，但这对于理想的网络来说也是如此。 如果服务器的 ping 值太高，即使在理想的网络中，您也无法舒适地玩游戏。 在本研究中我们没有进行 ping 实验。
正如所承诺的，这是链接.
来源： habr.com