用于VR的同步远程渲染

摘要

VR远程渲染技术是在低功耗设备上实现高质量VR的技术。这是通过卸载繁重的计算和渲染到高性能的服务器来实现的，这些服务器将VR视频流传输给客户端。本文主要关注远程呈现中的一个特定问题，即客户端和服务器之间不完美的帧定时可能会导致重复的帧丢失。我们提出了一个同步执行的系统设计，消除了上述问题。提出了该设计，并使用各种网络和硬件测试了一个实现。该设计不能由于同步问题而丢弃帧，但在另一方面，如果发生时间干扰，例如，由于网络延迟峰值或损失，则可能停止帧。然而，实验证实，在适当的环境下，这样的事件仍然很少见。例如，在内部网上以90帧/秒的速度进行远程渲染，而服务器位于大约50公里之外，只产生0.002%的延迟帧，而渲染的额外延迟时间对应于一帧的持续时间(90帧/秒，11.1毫秒)。在没有额外延迟设置的局域网中，即延迟等于本地渲染的VR，使用有线以太网连接时观察到0.009%的延迟，使用5 GHz无线IEEE 802.11 ac时观察到0.058%的延迟。

1.介绍

随着人们对虚拟现实(VR)越来越感兴趣，在手机或其他轻薄设备上部署VR功能的机会来了，由于成本或移动性，这些设备缺乏在自己的硬件上渲染高质量VR所需的计算能力。1］.通过卸载游戏逻辑和渲染到本地网络或边缘的强大服务器上，并将实时渲染内容流媒体为视频，这些瘦设备只需要强大的硬件解码器和网络连接，就可以实现高质量的VR。最后，这可以降低成本，增加VR客户端的移动性。

目前市场上有几个类别的遥控渲染。在廉价的低端，有设计用于将VR从家用PC传输到电话或其他薄设备[2-4.］.当使用手机作为客户端时，它放置在VR小工具中，通过将手机充当显示为头戴式显示器（HMD）的VR小工具[5.-7.］.这使得VR的廉价替代品能够为已经在家中拥有高通量的PC但没有高端耳机的用户提供廉价的替代方案。在并发远程VR的高端，例如，HTC Vive和Oculus Rift可提供无线VR适配器[8.那9.为Oculus Quest的USB-TETHETED远程渲染[10］.在这项工作中，我们提供了一种架构，可用于最小化VR中远程渲染系统中的延迟和帧数的帧数。

在远程渲染中，输入到屏幕上的输入到屏幕的延迟必须通常很低，以便提供体积的用户体验。遥控渲染的流行应用是云游戏。云游戏的延迟要求取决于游戏的类型，但通常在60到120 ms之间的范围[11］.然而，在VR中，这个预算被定义为Motion-To-Photon (MTP)预算，预计范围在7毫秒[12-1420毫秒[11那15-18］.最近（2019年）达到了7毫秒的截止日期，阀门的VR耳机指数达到了144 Hz模式（预算6.94毫秒）。然而，注意，除了刷新间隔（例如，来自输入设备）之外的额外延迟可能存在额外的延迟，而后者是所讨论的显示器上的最低延迟。例如，预计寿命的经验需要高达1800 Hz的帧，但根据之前的研究，7毫秒的潜伏期仍然是不明解的[19］.

1.1。VR远程渲染

每一帧都需要多个步骤才能实现VR的远程渲染:（1）客户端:从输入设备获取输入数据（2）客户端：将输入数据发送到服务器（3）服务器：运行游戏逻辑（4）服务器：每只眼睛单独渲染虚拟世界(5）服务器:编码产生的图像（6）服务器：将编码图像发送到客户端（7）客户：解码图像（8）客户端:在HMD中显示图像

考虑到VR的步骤数和7 - 20毫秒的紧凑的MTP预算，远程渲染是一个艰巨的任务。

其中两个最常见的VR耳机是HTC Vive和Oculus Rift，仍然是截至9月20日蒸汽上最常见的VR耳机的前五个[20.］.这两种HMDS都使用90 Hz刷新率，这导致11.1毫秒的帧间预算。但是，即使MTP预算可能是20毫秒，这并不意味着我们获得可以分配给网络延迟的附加8.9毫秒的余量。MTP取决于所讨论的VR系统，部分是持续提供耳机的旋转和翻译数据的设备和驱动程序。例如，在HTC Vive中，HMD的旋转在1000Hz时更新[21.那22.]，在最坏情况下使MTP延迟增加至少1毫秒。另一方面，Oculus Rift也在1000hz采样跟踪数据，但在USB数据线上的每个包发送两次更新，导致500hz的更新速率或2毫秒的最坏情况延迟[23.］.更糟糕的是，据推测，HTC Vive上的翻译更新率可能低至250赫兹[21.］.此外，驱动程序，显示和扫描引起的添加延迟。将图像从GPU扫描到显示需要大量的时间，通常是一个完整帧时间[24.］.因此，即使在本地呈现VR上，也存在大量的延迟。但是，通过预测未来的运动[25.那26.]，并利用其他延迟缓解技术，如2D- [26.-29.]和3D图像翘曲[30.-32.]，这两个系统都可以从用户透视图实现近零延迟（[33.]，第〜12章）。虽然所提到的缓解策略可以严重降低旋转和翻译延迟，但避免问题总是更好的是，而不是减轻它[27.］.此外，如果不将交互组件移动到客户端，交互延迟仍然难以缓解[34.，这会使开发变得复杂，并可能破坏使用远程呈现的目的。

1.1.1。本地延迟模式

理想情况下，远程呈现解决方案完成所有先前提到的步骤（1-8），并且能够在垂直同步（vsync）命中截止日期之前呈现新帧（vsync是一种可确保新扫描的技术直到上一个已经完成之前没有开始。vsync避免了新帧可能会覆盖旧帧的部分的问题，通常称为撕裂[24.]）。如果解决方案实现了这一点，VR体验在潜在呈现VR的延迟方面具有不同的可能性，我们将其称为本地延迟模式。当然，这很难实现，因为游戏逻辑和渲染本身可能已经消耗了大部分可用帧时间。添加编码，传输和解码可以在使用诸如H.264的公共编解码器时，在诸如H.264的公共编解码器中，从而引入延迟或降低帧率时，可以打破艰难的游戏的截止日期。

1.1.2。于服务器-客户机同步挑战

没有特殊硬件的简单远程呈现解决方案通常由服务器和客户机并行执行而不进行任何同步。服务器独立运行一个游戏，并不断地输入数据，用于渲染下面的帧。渲染帧被发送到运行自己的独立游戏循环的客户端，并不断地呈现它最近接收到的帧。这样的设计会导致两个程序之间的帧定时问题。理想情况下，在垂直同步截止日期前几毫秒，新帧已经被解码并准备好在客户端上显示。这是很难实现的，如果没有一些同步，例如决定服务器何时开始呈现[22.］.

1.1.3。同步设计的动机

我们提出了一种远程VR解决方案，它是同步的，并且在理想的场景中，无可用。在后一种情况下，它不会添加延迟并保持相同的MTP，就像在本地使用HMD一样。但是，由于同步，如果在当前环境中不能满足11.1ms（90 fps）的截止日期，则可以减少帧率（见图1）。为了保持截止日期，系统可以减少图像的分辨率以减少编解码器和其他组件的时间消耗。当本地延迟操作是不可能的时，原型也可以注入一个帧延迟以维持90 FP。完成此操作时，系统会引入在本地渲染中不存在的延迟，因此不再以本地延迟模式运行。

在提议的设计中，远程渲染功能被整合到游戏引擎中，并作为帧率预算的一部分。这限制了解决方案的可移植性，因为它不能作为一个单独的进程运行，而是必须写入游戏中。但是，它启用了更短的MTP路径，因为服务器上的渲染会在开始每一帧之前等待一个新的HMD姿态。同样地，客户端等待从服务器传回生成的渲染图像。等待确保两者保持同步，并在所需数据到达后尽快继续操作。

该设计允许本地延迟操作，不会因为同步问题而遭受帧丢失，并且实现最小延迟，因为链中的每一步都尽可能快地开始。此外，因为服务器和客户端是同步的，所以在服务器上渲染的每一帧都会显示在客户端上。这是因为服务器在接收到新的输入之前不会开始呈现，而客户端在呈现前一帧之前不会发送输入。Network-induced帧滴因为在这个系统中不会发生丢包。框架摊位另一方面，当刷新间隔截止日期不能保留时，将发生，例如，由于可能导致重传的损耗。在这种情况下，显示器可以显示与用户的播放失速的多次多次相同的帧。注意，错过的截止日期的效果依赖于实现，如果VR客户端利用可能扭曲的图像扭曲技术，则不一定是冻结图像，该技术可能会扭曲最后一个图像以获得新的方向[29.］.

由于所有帧的到达保证(由应用层协议保证，例如可靠的UDP或TCP)，系统从一个i帧开始流，然后完全运行在p帧上。这在异步系统中是不可能的，它必须通过发送一个不引用任何丢失数据的新i -帧来从丢失中恢复。通过可靠的UDP内部实现，数据传输在这项工作中得到了保证[35.，严格控制重传超时时间。最后，可能被注入系统的延迟是恒定的，并且总是一帧完整的长度，例如，在90帧每秒时11.1毫秒。这可能使未来的运动预测算法更容易作出准确的预测，当比较可变或未知的延迟。在异步系统中，延迟可能在零到几乎全帧时间之间变化，这可能会降低预测精度。

1．2．贡献和结构

呈现同步远程VR系统设计，其中使用各种系统参数和硬件在各种网络中实现和研究了原型。该研究不仅是为了为VR同步远程渲染领域的未来工作铺设方式，还要生成可能用于任何远程渲染方案中的相关工作的知识。我们的主要贡献是同步远程VR系统的设计与评估．本文的其余部分结构如下2，我们讨论VR的远程渲染领域的状态。部分3.介绍了系统的设计和具体实现。部分4.显示系统如何在许多测试中执行，具有各种网络和硬件。最后，部分5.总结了最重要的结论的工作，其局限性，和潜在的未来工作。

2.相关工作

远程渲染由许多子类别组成，并且已经可用，并在几十年中进行了广泛的研究。历史记录中的一些显着的样本在以下列表中呈现，其中包含括号中的发布日期。该列表提供了对该字段的介绍，但无论是绝不完整的。对于更全面的文献综述，我们参考以下出版物：关于交互式远程渲染系统的文献综述[1]，关于现有的综述（2016年）基于Web的可视化应用程序[36.]，有关移动云计算的调查[37.]，以及基于交互式集群的多屏幕呈现平台综述[38.］.(我)(1984) X窗口[39.]是远程渲染器的最早示例之一。它是一种窗口系统，通过设计由服务器和客户组成，因此可以轻松远程使用。例如，在研究中广泛使用X窗口，例如[40，作者发现，当使用X Window时，生成小数据报的应用程序会产生严重的开销，可能只能利用最大带宽的25%。作者建议除非必要，否则不应该刷新更新，因为这会生成更小的数据报;更新应该被缓冲并在可能的情况下批量发送。当然，需要注意的是它会增加延迟(2)(1995)虚拟网络计算[41.]是远程访问与操作和窗口系统无关的图形用户界面的协议。它被描述为x窗口的改进[41.］.[42.]使用VNC量化用户体验，并发现低延迟网络是最重要的因素，而不是带宽（iii）（2000）OpenGL VizServer [43.]是由Silicon Graphics Inc.开发的远程渲染系统，它利用具有OpenGL的硬件加速。在 [44.，作者同时使用VNC和OpenGL Vizserver来展示分布式团队如何同时查看和引导模拟(iv)（2002）Paraview [45.]是一个开源应用程序，可实现数据集的交互式远程可视化。它已广泛用于科学界，并针对可以由超级计算机或服务器集群呈现的极大的数据集。例如，一项研究使用Paraview来提供进入早期宇宙的演变的见解[46.］.该研究中使用的数据集由几百个时间步长由点仿真数据组成，每个时间均载有大约200百万点粒子[46.］.（v）（2007）Streammygame [47.]是一个云游戏服务，可以通过LAN或Internet流传输到Windows或Linux PC和PlayStation 3（vi）（2009）RealityServer [48.是一个基于gpu的云计算环境，通过网络实现逼真的渲染（vii）（2010）onLive [49.]是云虚拟化技术的提供者，具有云游戏服务。Onlive于2015年停止并销往索尼[49.］.2011年进行的一项研究测量了OnLive与StreamMyGame的延迟，发现OnLive测试的处理延迟在110 - 221 ms之间，而StreamMyGame测试的处理延迟在356 - 471 ms之间。50.］.处理延迟被描述为播放器输入和对应帧的呈现之间的差异[50.]，即MTP(八)(2014) GamingAnywhere [51.]是2014年发布的开源云游戏系统。GamingAnywhere的出版物包括与onLive系统的性能比较，并显示出显着的改进[51.］.涉及Onlive和GamingAnywhere的另一个研究发现，使用这些服务时，每个100毫秒的延迟，玩家性能会降低25％[52.]（IX）（2014）Playstation现在[53.]是由索尼互动娱乐提供的云游戏服务，这是2014年第一次推出的(x)（2015）Trinus VR [2通过将PC游戏会话流传输到手机或类似的瘦客户端，实现对VR的远程渲染。此外，它还支持在瘦客户机上的虚拟现实中观看非虚拟现实游戏(十一)（2015）vridge [4.]提供与Trinus VR以前描述的相同功能（XII）（2017）ALVR [3.是一款开源的远程虚拟现实显示器，可以将PC上的虚拟现实数据流传输到Gear VR或Oculus独立的hmd上（XIII）（2017）TPCast [8.]通过在60 GHz频段中使用WirelessHD流媒体，可以通过远程渲染来实现无线VR的HTC Vive和Oculus Rift(十四)(2018) Vive无线适配器[9.]通过IEEE 802.11ad在60ghz频带上进行远程渲染，实现了Vive耳机的无线VR（XV）（2019）Stadia [54.是谷歌提供的云游戏服务。作者的55.]进行一项研究，现在在他们对全球有限公司的影响方面研究了Stadia和Geforce₂排放。作者的分析表明，游戏流将导致游戏能量和碳足迹的显着增加[55.］.(十六)（2020）GeForce现在[56.]是NVIDIA提供的云游戏服务。该服务的Beta版本是在2015年提供的，并在2020年制定了全面公众的全额发布[57.］.2016年的出版物研究了GeForce的质量（QoE）在不同的网络条件下，例如比特率，延迟和数据包丢失。受试者和测试参数的范围是有限的，但结果表明，根据参数几乎没有任何统计学上显着的差异，其具有一个例外。在会议开始后引入潜伏期时，QoE显着降低。对此的可能解释可能是该服务仅初始估计与预测使用的延迟。因此，如果延迟在估计后发生变化，则在整个会话的其余部分中，渲染的预测视图将不正确(十七)(2020) Xbox云游戏[58.是微软提供的云游戏服务(十八)（2020）Luna [59.是亚马逊提供的云游戏服务（xix）(2020) Oculus Link [10是一个通过USB线操作的VR远程渲染系统，可用于Oculus Quest或Quest 2（xx）(2020) CloudXR [60.]是英伟达(Nvidia)的一款解决方案，可以将云、数据中心或边缘OpenVR XR应用程序中的VR、增强现实(AR)和混合现实(MR)内容流传输到运行Windows或Android平台的绑定或不绑定客户端。支持的设备包括连接到Windows 10 pc、Microsoft HoloLens 2、Oculus Quest和Oculus Quest 2的Vive或Valve Index耳机[60.］.在撰写本文时，CloudXR正处于封闭测试阶段(2021年春季)。

在以下小节中，我们将进入更多详细信息，围绕VR的远程渲染，并审查该领域的相关出版物。

2．1.360°全景虚拟现实

VR的远程渲染已研究一段时间。大多数解决方案涉及到覆盖每个角度的全景;该技术用于360°视频，并已广泛用于研究界，通常与游戏发动机统一结合[61.-64.］.在 [64.[作者，作者通过使用两台笔记本电脑研究了360°VR的远程渲染，并报告了30毫秒的端到端延迟，位于30个FPS的立体声1080P分辨率为30 Mbps。将渲染的全景分成切片，仅传输根据当前视图方向所需的那些;这减少了大量的50％。进行了类似的研究，其中专注于通过仅流媒体全景图像的视野（FOV）阐述带宽节省[63.］.该研究的作者能够通过PC将8 k 360-VR通过4G网络流到齿轮VR手机，并与发送整个全景相比，节省了超过80％的带宽。术语动作到更新[63.介绍并报告到67.4和559.6 ms之间的范围，具体取决于分辨率，网络和编解码器。我们的理解是，此处使用Motion-to-更新，以更准确地描述360-VR的MTP，因为考虑到服务器更新。在 [61.，作者进一步研究了带宽削减，发现通过将渲染图像存储在服务器上，并对位置和视图方向相似的客户端重用，可以减少90%的服务器计算负担，降低95%的比特率。最后，本文对360°视频流进行了研究[62.］.不过，带宽并没有在该作品中得到解决;其目的是减少认知负荷和视觉不适。

通过使用全景，通过选择已经获取的全景图像的不同部分，可以立即呈现由耳机的旋转引起的新视图。这使得Panoramas非常适合用于视频，其中仅使用三个自由度（3-DOF），即周围的轮换 - ， - ，和 -轴。然而，Panoramas需要更多的内存和更多时间渲染，这使得它们难以实时与高帧。要创建一个360°视图直播，可以渲染多维数据集地图，这需要六个摄像头，因此六次渲染通行证[64.-66.］.虽然可以在这个过程中完成一些剔除[65.]，立方体映射渲染永远不会像渲染只是视口一样高效。他们还没有高效的6-DOF（附加换算 那 那和 ）和/或交互式场景。当场景的内容由于用户交互或在场景中发生的其他事件而变化时，必须下载显示更改的新图像，除非可以在客户端上呈现。由于这些问题，我们只渲染用户当前正在寻找的默认视口，这是低延迟实现中的常见方法，并且在呈现的像素方面没有与本地VR的不同。

2.2。分开渲染

也有分裂或协作渲染的解决方案[34.那65.那67.］.通过在客户机上呈现时间敏感或低保真度的对象，在服务器上呈现要求较高的对象，可以同时保持响应性和视觉质量。该技术已被应用于VR的远程渲染，例如，在服务器上沿着间隔网格的每个位置预渲染全景图构成的背景[34.］.另一种方法是在服务器上实时呈现立方体地图作为背景，而在客户机上呈现交互对象[65.］.

虽然分离渲染解决方案即使在网络条件不足，但互动组件也可以实现低延迟，但如果它们可能太复杂并且难以扩大行业发展，我们会质疑。拆分渲染的固有问题是开发人员必须涉及开发一个由服务器和客户端组成的最终用户应用程序，这意味着额外的成本。虽然不太重要，但客户也可以为客户下载并保持更新的唯一客户端可执行文件，但对于每个游戏，还有额外的麻烦。此外，远程渲染的点是在低功耗设备上实现高质量的视觉效果;因此，由于任何此类对象的视觉质量将限于低功耗设备可以输出的视觉质量，因此不理想的是呈现客户端上的任何对象。然而，通过行业中的当前谈判来判断，我们注意到似乎可以推动分裂渲染，并相信这将解决目前的远程VR [68.］.不过，有些人仍持怀疑态度[69.只有时间才能告诉我们哪些技术会被市场接受。我们认为分离渲染可能是让远程VR在当今硬件上工作的一种妥协，但它不是未来一代的最终解决方案。

根据本文提出的设计，客户端可以看作是一个视频播放器，可以运行服务器提供的任何游戏。每个游戏的服务器进程都是唯一的，因为远程渲染功能必须添加到游戏引擎中，并且不能作为一个单独的进程运行。

２.３.Nonpanoramic虚拟现实

不使用全景节省时间和带宽，但它还对VR系统的低延迟和稳定性进行了巨大的要求。必须以等于HMD的刷新率的速率下载新图像。如果不能按时实现这一目标，VR体验可能会被破坏。通过具有外部过程复制VR游戏的渲染图像，可以在对其进行编码的情况下，可以将这种系统进行更简单地接近，并在网络上发送它们以解码客户端。这种方法的优点是它很简单，并且远程功能可以在没有修改的情况下添加到任何现有的游戏，因为它基本上是屏幕记录器。尽管如此，可能难以优化这种一般过程，尤其是确保最佳帧同步。

2.3.1。屏幕记录器方法

[70]建立了具有商品硬件的短程（LAN）远程渲染VR系统。他们的系统能够从Steam VR游戏捕获图像，使用GTX Titan x GPU与JPEG对它们进行编码，并在Wigig网络上传输它们。为了测量用户所感知的延迟，它们并排录制两个HMDS，其中一个240 FPS相机，其中一个包含本地VR渲染，另一个遥控器。通过比较HMD图像的差异，他们得出结论，增加的延迟是在范围内 ．所提出的解决方案是屏幕记录器方法的典型示例，其中可以将远程呈现功能添加到任何现有游戏，因为它是外部过程。这种方法是经济且易于为市场带来的，而且难以优化，因为没有比游戏的低级控制，如延迟所揭示。

2.3.2。游戏集成和vsync估计

在 [22.，作者报告了另一个短距离远程渲染虚拟现实系统，也利用了WiGig连接，但被集成到游戏中。使用Nvidia Video Codec SDK进行编码[71.它们利用了4个并行编码器线程和4个并行解码器。它们通过在第一只眼睛的渲染完成后立即开始编码来节省时间。这意味着对第一只眼睛的编码与对第二只眼睛的渲染是并行的。此外，该工作的作者提出了一种技术，包括估计服务器应该在何时最佳地开始呈现，以减少错过客户端垂直同步截止日期的风险。除非应用某种形式的同步，否则客户端到下一个垂直同步信号的等待时间将漂移每一帧，直到重复模式中错过一帧[22.］.根据他们的实验，VSYNC估计导致所有截止日期的0.1和0.2％之间缺失，平均一帧每5-11秒在90 fps下降。这是对天真的实现的显着改进，但在没有同步估计的情况下丢弃了5.3和14.3％的帧。最后，报告了在软件中的16 ms的端到端延迟;我们的理解是，这是最苛刻的场景的平均值。在我们的工作中，我们使用类似的方法，但利用所提出的同步设计，这些设计完全解决了同步问题。

2.3.3。来自行业的例子

也可以在Vridge创建者的开发人员博客中观察同步问题和时间漂移[72.］.它们展示了之前的实现是如何导致时间漂移的，以及更新是如何缓解这个问题的。虽然在更新后出现的次数减少了，但这个问题似乎并没有完全解决，因为在改进版本中帧仍然偶尔会被丢弃。没有报告确切的数字，但从[72.]似乎左右的帧仍然丢失在更新的版本中。

2.3.4。测量

如果异步操作，则测量远程渲染系统的性能很难。例如，如果应该测量图像质量，则可以在服务器和客户端上保存每个渲染的帧，并在流媒体会话结束之后使用客观图像质量估计器进行比较它们。例如，将每个帧保存到磁盘可能会降低性能，因此可能会增加客户端上的错过帧数，导致无效的测量结果。解决此问题的方法称为慢动作基准测试，并应用了许多薄客户端，包括VNC [73.］.慢动作基准测试是提议的同步架构的固有特性，如果需要将服务器渲染的所有帧传递给客户端，它将减慢速度并利用重传输。因此没有丢失帧，使得图像质量估计简单。服务器的延迟时间也可以通过在测试期间将其设置为耳机的帧速率来控制。这将确保任何游戏内容按照预期的行为，即使系统运行在慢动作，因为保存每一帧PNG到磁盘。虽然系统不会丢弃帧，但帧率设定的截止日期仍然会发生。这是一个重要的测量方法，在此通过在客户端每次完成一帧时查询VR驱动程序的物理帧演示数来记录4.3.1.详情)。总之，我们认为图像质量估计等测量将更容易在同步设计中进行，因为慢动作基准是架构的一个属性，并且保证客户端接收到每一帧渲染;这个功能的一个例子可以在[74.］.

3.材料和方法

两个Windows应用程序是用c++开发的。其中一个运行在客户端，并连接到Steam VR;这个应用程序没有游戏逻辑和几何渲染功能。客户端从Steam VR驱动中轮询HMD姿态矩阵，并将此矩阵发送给服务器，服务器根据接收到的姿态矩阵处理游戏逻辑并为两只眼睛渲染场景(见图)1概述)。服务器对两只眼睛的结果图像进行编码，并将其发送回客户端，客户端依次对图像进行解码，最后将其作为OpenGL纹理发送给VR驱动程序，以在耳机中显示。请注意，音频传输超出了本文的工作范围，并没有在原型中实现。

为确保设计是可行的选择，我们使用各种硬件在一系列网络环境中测试原型系统。最终通过每个会话渲染100000帧绘制100000帧来在选择环境中进行SOAK测试。浸泡试验确定停顿的比率，与相关工作中报告的那些相比。与最先进的方法相比，后者将允许判断同步设计的性能。

3．1.同步

该系统包含客户端和显示之间的一个主要同步点，当从VR驱动器轮询HMD姿势矩阵时发生的，并决定系统的帧率。此方法称为配方（），是Steam OpenVR API的一部分[75.]，直到下一帧开始前几毫秒才会阻塞，下一帧被称为“running start”[76.］.如果没有这种同步点，系统将尽可能快地呈现VSYnc，这将导致撕裂。

同步也发生在客户端和服务器之间;服务器将阻止执行，直到新的输入矩阵到达并立即开始渲染到达时。客户端将阻止渲染，直到两个新图像，每个眼睛都被两个解码器线程解码。在完成后，渲染线程将在调整大小之后将图像提交到VR驱动程序（由于支持低于本机分辨率）。在向VR驱动程序提交后，客户端呼叫配方（）以获得新的姿势矩阵，因此循环完成。如果循环可以在少于11.1毫秒的情况下完成，则与HTC中的本地VR相比，它将在零增加延迟以90 fps进行。如果超出截止日期，则配方将阻止更长时间，并使系统以45 fps运行，具有22.2毫秒的截止日期。在这种情况下，可以使用延迟注入一帧或降低分辨率来加速编解码器处理以尝试和达到截止日期。

３．２．编解码器

服务器原型设计用于NVIDIA GPU，具有两个硬件编码器，例如GTX Titan X和GTX 1080（请参阅[77.]有关全部列表）。利用两个编码器芯片，两个编码过程可以完全平行地使用，每个编码过程同时编码它们的相应眼睛。

编码和解码在C ++中使用NVENC和NVDEC从NVIDIA视频编解码器SDK进行完成[71.和CUDA工具包。图像采用H.264编码，NV12作为视频表面格式，YUV420色度子采样。当帧间隔被设置为从一个i帧开始，然后在整个会话中只使用p帧时，将使用无限组图片。这节省了带宽，因为可以避免要求更高的i帧，但它也使解决方案对损失敏感，这就是为什么必须使用可靠的应用层协议，例如可靠的UDP或TCP。

帧率设置为HTC Vive的本机率，90 FPS。VBV缓冲区大小设置为一个平均帧的大小，建议在NVENC文档中的低延迟操作[71.］.速率控制模式设置为nv_enc_params_rc_cbr_lowdelay_hq。在执行期间可以更改编码图像的大小（参见部分3．4有关图像尺寸的详细信息）。平均比特率为每种编码器设置为8 Mbps，总共16 Mbps。根据SSIM测量，选择了此比特率，因为它以最大分辨率提供足够的质量。应当注意，应根据预期的运动水平和可用资源的预期水平使用，每次眼睛之间的10至16mbps [74.］.因此，在这项工作中使用的比特率略低于推荐的水平。这表明对时间消耗的影响可忽略不计，这是这项工作的主要重点。对于将比特率要求与图像质量相关的研究，读者称为[74.］.

除了上面提到的修改，编码器和解码器的配置与Nvidia Video Codec SDK中的低延迟编码器和解码器样本相同[71.］.

3.3。网络

UDP用于传输视频和输入数据;两个编码器线程与服务器并行传输视频数据到客户端。输入数据在从客户端发送到服务器的每帧的一个数据包中传输。为了保证提供所有UDP数据包，我们实现了自己版本的可靠UDP（RUDP）[35.］.rudp实现由valve的gamenetworkingsockets启发[78.]和DCCP的ack向量[79.］.我们选择自己的实施，以确保我们完全控制，并且能够根据需要优化它。该实施旨在通过对延迟变化非常敏感，快速响应损失。如果检测到数据包并且检测到比常规的延迟更高，则系统将估计数据包丢失并触发重传。在延迟变化几乎没有变化的网络中，冗余重传保持罕见，并且损耗的响应时间仍然很低。然而，在具有大延迟变化的网络中可能更常见的冗余重传。

由于同步设计不依赖于本身，因此协议的详细演示超出了这项工作的范围。具有禁用的Nagle算法的TCP（Nagle的算法是TCP的方法，用于减少小数据包的数量，从而提高带宽效率。它通过缓冲数据可以在单独的数据包中立即发送，这引入了TCP中的延迟[80)或任何其他RUDP实现也可以使用。这种选择对远程渲染VR中延迟分布的影响还有待研究。

3．4．动态解析

服务器分配五个帧缓冲区，用于测试分辨率交换机的影响。表中提出了分辨率级别和大小1．分辨率是通过每层在宽度和高度上减去20%的原生分辨率任意确定的，并另外舍入到最接近16的倍数，以避免在解码器中裁剪。

3.5。测试设置

在服务器和客户端上使用Windows PC进行实验。请注意，这自然不是未来现实世界场景的主要目标设备，并且大多数测试的客户端设备甚至可以在自己的GPU上运行桌面VR。然而，它们被使用以获得更多对测试环境的控制，并且足以用于所提出的方法的概念验证。未来的工作涉及开发一个可以运行的客户端，例如，配备硬件解码能力的电话或独立HMD。

实验在四种不同的环境中进行(见表)2）。第一个被称为公寓兰，客户端和服务器都在同一LAN / WLAN上。公寓实验的目的是了解远程VR解决方案如何在短程网络条件下的强硬硬件上以最佳的硬件运行，即，雾渲染。在这种用例中，消费者已经在主页或互联网咖啡馆或互联网咖啡馆中具有本地访问强大的计算机，并将VR流传输到瘦客户端，例如增加移动性或降低成本。如前所述，来自当前市场的一些示例是从PC传输到手机的低端远程VR选项[2-4.］.另一个类似的例子是Oculus Link [10］.

第二个测试环境是校园内部网在Blekinge理工学院（BTH），如果客户和服务器在两个校区之间的光纤分开，在两个校区之间分离，具有1 Gbps带宽。这些实验介绍了解决方案如何在具有更长范围内的较大网络中执行的，但具有良好的路由，即边缘渲染。在这种情况下，消费者将无法立即访问服务器，但是使用瘦客户端的私有内部网或在Internet Cafe时密切连接到它。然后，Intranet将从远程但最佳路由服务器提供远程VR服务，而不是通过公共互联网的稳定性和速度。例如，在这种用例中，例如，可以将机顶盒与远程服务器的最佳路由连接，并且可以将VR耳机插入盒子或无线连接。这种情况的试验是由2017年的HTC进行的[81］.

两个实验在整个公共互联网在纤维和4G。在这些测试中，客户端PC位于公寓和服务器上，校园大约50公里。包括这些测试，以揭示典型的当代公共网络可以支持这种类型的VR的远程渲染。100/100 Mbps订阅用于光纤连接，通过USB在4G测试中通过USB将ASUS ZENFONE 3 ZOOM PHONE定为客户端。在光纤连接中，设备分隔18个网络跳跃。这种情况测试公共云渲染，这不仅是最灵活的选项，而且由于公共互联网的高循环时间（RTT），也很可能失败。

此外，在Luleå技术大学（LTU）中，在室内进行了两个使用5G的两项实验。该试验表明，这种类型的遥控在早期试验台上的适用性，用于即将到来的5G技术。此用例是指移动边缘渲染，其中渲染服务器密切连接到移动接入点。使用LTU 5G网络内的边缘服务器运行5G实验[82]连接到本地突破核心（见图2详情)。客户端和服务器之间注册了四跳。早期发布的5G USB调制解调器为客户端笔记本电脑提供了与蜂窝网络的连接。

在任何无线网络中都没有进行移动性测试。在任何无线条件下，客户只连接到一个基站/ wifi路由器，而没有移动到另一个。另外，除了我们无法控制的4G之外，客户端设备也是测试中唯一连接到服务基站/WiFi路由器的设备。

所有实验都是用HTC Vive VR耳机进行的，所述HTC Vive VR耳机在连接到客户端计算机时完全仍然在平坦的表面上撒谎。为了以可重复的方式模拟用户耳机运动，HMD姿势矩阵以每秒90°的速度为-180°和+ 180°之间的角度旋转。

4.结果与讨论

结果被分成三个测试用例。执行了两个相对较短的测试，其中分辨率分别在运行时本地延迟模式和使用延迟注入时更改。这些测试揭示了编解码器的时间消耗对渲染循环的影响程度，此外，实时分辨率切换对以下帧的即时时间消耗有什么影响。这两个测试进一步提供了有价值的见解，以了解同步呈现循环在各种网络中的执行情况。这将决定所讨论的网络是否适合这种类型的远程呈现。最后，使用适当的设置和环境进行浸泡测试，以揭示最终的延迟分布和失速率随时间的变化。

4.1。解决本地延迟模式的分辨率测试

分辨率测试在所有环境中进行，每种物理介质共用2500帧。每个500帧间隔后，分辨率降低了一个水平（20％）。

结果表明，在切换分辨率的瞬间，解码器的时间消耗增加了，根据GPU的不同，时间消耗增加了1.3 ~ 10.3 ms。编码器不会受到分辨率切换的影响，但当这种切换发生时，比特率会严重增加。因此，根据可用带宽的不同，支付分辨率开关的价格不仅会暂时增加解码器的时间消耗，而且还可能增加视频网络的时间消耗。然而，在我们的实验中，我们只看到切换时刻视频网络时间消耗的微不足道的增长，因为可用带宽可以处理这种增长。在这些实验中，普通视频帧一般需要22kb左右;携带分辨率切换的帧需要大约50-60 kB。

所有分辨率实验的时间曲线显示在图中3.．该图显示了在执行期间的每个组件的时间消耗。从输入到显示的输入到显示的总时间显示在图中的白色（总计）线上显示，并考虑到任何缺失部分，例如显示同步和延迟。类似的线（蓝色）显示客户端上帧演示之间花费的时间（三角洲的时间）。这次控制帧率，并且是更新游戏逻辑的速度。所示的增量时间测量是三个连接帧的平均值，以降低噪声。最终，它是准确地显示框架摊位的总时间，例如尖峰。在图中3.，总时间和δ时间通常是相同的，因为除了在5G案例中除了在该图中包含的5G外壳之外没有使用延迟注入以节省空间。在下图中，总时间和三角洲时间之间的差异变得清楚4.由于延迟注入，两者总是分开的。

以下4.4.1。局域网

在公寓局域网环境中进行了分辨率减少的三个实验，其中服务器和路由器之间的连接由2.4或5 GHz WiFi或以太网CAT6电缆组成。结果为2.4 GHz显示稳定的45 FPS，然后奋斗沉淀到恒定的帧（见图的左侧）3.）。5 GHz实验表明，在100％分辨率下以45 fps开始的相对稳定的运行，然后在较低分辨率下进行90 fps。虽然在100％的决议中，我们称之为一个问题过渡区，杂志的理想情况下，应留在稳定的45处，但在经常性的爆发中保持达到90。CAT6提供了90 FPS稳定的本地延迟体验和100％分辨率。使用CAT6的测试包含了由于暂时增加了解码器的时间消耗而在分辨率开关时发生的单个帧档。

4.1.2。内联网

结果表明，内部网络中的无线媒体支持45帧每秒，重复帧暂停，然后是40% (5 GHz)和20%分辨率的过渡区。CAT6连接在全分辨率(0级)下支持45帧无停顿的fps，以80%的速度进入过渡区，并在其他级别上重复运行帧停顿。

Intranet无法在本机帧中支持稳定的本地延迟远程渲染，无论分辨率和物理介质如何。没有框架摊位的稳定体验仅在45 FPS与CAT6和5 GHz实现。在CAT6的图表中，在20％的分辨率下，在达到11.1毫秒之前可以使用几毫秒，但这显然不足以补偿偶尔在该网络中发生的抖动。

4.1.3。互联网

从互联网环境中减少分辨率的两个实验都是在图的下部呈现3.．结果表明，由于大多数时间消耗是由于网络延迟和抖动的大多数时间来说，解决方案无关紧要。4G连接支持左右10 FPS的不稳定平均值。允许在分辨率开关中发生帧档的稳定连接允许的光纤连接，但由于公共互联网的高延迟，可能仅维持30个FP。这显示了如果想要启用同步远程渲染，则使用私有基础架构的重要性。在地理上，Intranet和Internet测试中的客户端位置有几百米差异，但RTT在Internet连接中大约20毫秒，在内内网上是2-3毫秒。

4.1.4。5G

在与互联网测试的相似之处，通过5G连接的分辨率降低测试受RTT的限制。如图所示3.，大多数时间消耗来自网络组件，即5G USB调制解调器和无线电接口本身。通常，物理无线电层低于使用3：1下行链路/上行比率的类似中频时分双工（TDD）设置的实际测试中的平均值14 ms RTT。然而，诸如USB调制解调器的设备可以增加每个方向约5-6 ms的额外延迟。该延迟预计将在即将到来的更优化的用户设备中减少。为了在每个无线电链路上实现具有邮件的纤维延迟超可靠的低延迟通信（URLLC）[83必须使用，这在该测试网络中尚未使用。

4．2．带有延迟注入的分辨率测试

原型支持注入单帧延迟。使用此功能的测试在公寓，Intranet和5G设置中运行，使用与先前描述的分辨率测试相同的参数。除了在图中显示的5G测试3.为了节省空间，延迟测试的结果如图所示4.．增加一个帧的延迟使得系统在局域网的所有媒体中运行时几乎没有帧延迟。在2.4 GHz的情况下，2500帧中有12帧失速，但在CAT6和5 GHz的情况下没有失速。在CAT6的内部网中增加延迟，在恒定的90帧速率下也可以实现零延迟。然而，在内部网的两种无线媒体中仍然会出现重复的中断，请注意图中总时间消耗的白色峰值4.．这些尖峰可能是校园区拥塞2.4和5 GHz乐队的结果。类似地，由于RTT和尖峰网络时间消耗高，延迟不会显着提高5G。

4.3。浸泡测试

最后，在公寓局域网和内联环境中进行了浸泡测试。在这些测试中，以最高分辨率记录每个介质的100000帧，以在相应介质的分辨率测试中启用90 FPS。在LAN上，这些是CAT6（100％），5 GHz（60％）和2.4 GHz（20％）。然而，在内部网中，只有CAT6被妥善测试，因为无线介质未能在这种环境中保持稳定的帧，并且在这种环境中没有延迟。用Intranet上的CAT6进行两个浸泡试验，一个具有20％的分辨率，一个帧延迟为100％分辨率。

4.3.1。浸泡试验结果

数字5.显示网络组件的互补累积分布函数（CCDF）。图中的图显示了超过横坐标上所示的时间消耗的样本的百分比，最多20毫秒。CCDF根据预算超支的配置和可接受的比例，揭示了每个组分的必要预算;数据总结在表中3.．该表提供了详细的概述，通过显示每个标记百分比的网络组件的预算要求。例如，在带有CAT6（测试A）的LAN上，预算为0.9 ms涵盖了所有除帧的所有除帧中的视频组件的要求。为了在60％的分辨率（测试B）的5 GHz中保持相同水平的5 GHz，将需要7.3毫秒的预算。除了预算外，该表还显示了在测试期间发生了多少帧摊位，例如，在LAN上的CAT6中的0.009％的帧。为了提供最大的精度，我们使用Steam VR来测量摊位的数量。它们是通过在每个帧处的变量“compositor_frametiming :: m_nnumframepresents”的OpenVR API来查询VR Compoisitor来确定，并将其值添加到摊位的总数。大于一个的数字被视为一个或多个帧档位，因为那时多次呈现相同的帧。

该表还显示了每帧的平均帧率，比特率和总时间消耗。请注意，HTC Vive的真正帧率不是90 fps但89.53 fps [84］.因此，测试A的帧率(89.52 fps)接近最佳，但却遭遇了9帧暂停，导致平均帧率较低。当四舍五入到两个小数时，测试E的最佳帧率为89.53 fps。

比特率也受到摊位的影响，因为当帧率降低了一半时，有效的比特率也是如此。这可以在测试C（2.4GHz）中可以看出，其中平均比特率为15.0 Mbps，由于相对较高的帧馏分为3.220％。有效的比特率也受到冗余UDP重传的影响，这就是为什么它可以到达设置的16.0 Mbps。

还显示了每帧的平均总时间消耗，这应该是由于89.53 FPS的真实帧率最佳为11.169毫秒。

4.3.2。浸泡测试摘要

原型在局部潜伏期的LAN上实现了低框架 - 计数比，0.009％，CAT6全部分辨率，0.058％，分辨率为0.058％，分辨率为60％。在内部网上，具有一帧的延迟的CAT6连接能够提供具有0.002％档位的流。这些都改进了以前的工作[22.]报告了0.1-0.2%的帧丢失率，而行业的例子显示了0.3%的帧下降[72.］.

5.结论和展望

我们展示了一种设计同步远程渲染VR系统的方法，解决了客户端和服务器之间的同步问题，从而消除了帧暂停的来源。通过测试这一设计的实现，我们量化了档位的比率，确定并显示了在某些条件下，它可能运行，以及它对支持硬件的要求。我们得出的结论是，该架构可以在延迟等于本地VR的情况下很好地运行，即在本地延迟模式下。然而，必须使用一个稳定的、低延迟的网络，才能以这种模式可靠地流。我们使用的校园网不够用，公共互联网和早期的5G测试网络也不够用。只有在LAN上才能在HTC Vive的本地分辨率和帧速率下实现稳定的本地延迟操作。在LAN/WLAN上，主要问题不是网络，而是编码器和解码器的时间消耗。事实上，除了网络延迟峰值，编码器时间通常是系统的瓶颈，特别是在高分辨率时。在我们的实验中，解码通常需要不到2毫秒，而编码则需要多达6毫秒。将分辨率降低到本机大小的20%通常会将编码时间减少到1.5 ms左右，解码时间减少到1 ms左右，这在某些情况下对于满足截止日期是有用的，但当然会对视频质量产生负面影响。

如果不能保存本地延迟截止日期，则该架构支持注入延迟的完整帧，即每帧为90 fps的11.1 ms的添加等待时间。延迟注射证明在这足以补偿网络抖动的环境中使流更可靠。我们预计在添加未来的运动预测时，延迟的精确添加可能有助于。

5.1。限制

我们还没有考虑到我们范围之外的两个部分，但是在远程渲染中考虑VR的其他部分是重要的。它们如下：

简单的游戏我们实验中使用的游戏是一个简单的3D场景，在这个场景中，玩家在一个小房间里被盒子包围着。这个场景和游戏逻辑并不复杂，通常需要不到1毫秒的时间来计算和渲染。在现实世界中，游戏可能至少需要几毫秒的时间，这是计算预算时必须考虑的因素。

没有音频：我们在实现此系统的实现中忽略了音频。在实际情况下，必须从服务器发送更多包含音频的数据到客户端每个帧。

此外，考虑到HTC Vive的镜头失真，建议渲染为1.4倍的原生分辨率( 代替 ）。然而，为了避免在测试中以100％分辨率传输这种大图像。渲染在1.4倍上进行了1.4倍的尺寸，但在编码之前施加镜头失真，从而减少了图像的大小和编解码器和网络处理的数据量。为此，必须禁用通常在客户端上的VR驱动程序中应用的镜头失真。这还将禁用任何内置图像扭曲功能，这是为了降低感知的旋转和/或转换延迟。因此，更好地仅在原生大小发送非透镜失真的图像并接受以像素密度的损失而不是致残翘曲。无论镜头失真是否应用于服务器或客户端都没有明显地影响本工作中呈现的结果。但是未来的工作可以例如通过使用FOVEATED视频处理来解决这个问题[85那86]这就是在Oculus链接中解决的方式[10］.

5.2。未来的工作

如果可以忽略编码和解码的时间，则本地延迟模式可能是完全可行的，如果可以忽略编码和解码的时间，这可能是这种情况，如果例如非常高的带宽，则需要很少没有压缩。这是当今市场上可用的无线VR适配器的情况，这通常利用60 GHz频带，例如802.11ad [87］.

虽然802.11ad理论上高达8 Gbps [88]但是，对于当前生成HMDS的分辨率和帧的分辨率，例如阀门指数，它不支持压缩的远程渲染。要解决这个问题，人们可能期待下一代称为802.11ay的60 GHz WiFi [88］.802.11ay在编写本文时正在开发中[89]，目标支持最高达100 Gbps [88］.发布802.11ay的那篇文章聚焦了VR用例，其中的部分摘要如下:

“虽然启用多功能GB / S无线本地通信是一个重要的成就，吞吐量和可靠性要求的新应用，例如增强现实（AR）/虚拟现实（VR）和无线回程，超过802.11AD可以提供的。”[88］.

到目前为止，原型是用802.11 ac(表示为5 GHz的缩写)和802.11n (2.4 GHz)进行测试的。该体系结构在更复杂的无线网络中将如何运行?类似的测量可以使用例如802.11ad、802.11ay、802.11ax或启用URLLC的5G进行[90］.

由于对图像翘曲技术的干扰，在服务器上应用镜头失真不是最佳的。由于数据大小，编码和传输超采样的图像对编解码器的另一方面是耗时的。因此，较小的图像可以与超级度结合使用[91]或foveated编码[36.]，后者已应用于Oculus Link [55.］.我们可以从这些技术中获得多少加速以及对图像质量的损害程度？

本文的工作确定了同步设计可以降低车架的档位比率。什么比例的帧档对用户来说是明显的?为了回答这个问题，可能需要进行主观的主观质量评价研究。

数据可用性

数据和代码可在https://github.com/kelkka/remoterenderedvr.．如果链接页面应该不可用，则通过标题页上列出的电子邮件可根据要求提供数据和代码（Viktor.kelkkanen@bth.se.se）。

利益冲突

在使用5G连接的测试中，我们使用了使用爱立信开发的设备的5G测试站点。这可能被认为是利益冲突，因为该公司的一位作者被雇用。

致谢

感谢Mattias Schertell和Siamak Khatibi让我们借用他们的服务器与GTX Titan X GPU。感谢Björn Mattsson为BTH搭建了内部网环境。感谢匿名评论者的反馈。感谢Jesper Gladh在LTU进行5G测试。最后，感谢Hans-Jürgen Zepernick和我们ViaTecH项目的同事进行了富有成果的讨论和反馈。这项工作得到了瑞典KK基金会的部分支持，通过合同号为(20170056)的“ViaTecH”项目。

参考

1. S. Shi和C.-h.HSU，“对互动远程渲染系统的调查”，ACM计算调查，第47卷，第47期。4，第57条，第1-29页，2015。视图:出版商网站|谷歌学术搜索
2. S. L. Odd Sheep，“Trinus虚拟现实”，2015,2020年5月，https://www.trinusvirtualreality.com/．视图:谷歌学术搜索
3. 传闻，“空气轻型VR，”2017，5月20日，https://github.com/polygraphene/alvr.．视图:谷歌学术搜索
4. Riftcat，“纸板上的Vridge-Play PC VR，”2015年5月20日，https://riftcat.com/vridge．视图:谷歌学术搜索
5. 谷歌，“纸板”，2014年，2020年5月，https://arvr.google.com/cardboard//cardboard/．视图:谷歌学术搜索
6. 三星，“Gear VR，”2015，5月20日，https://sv.wikipedia.org/wiki/samsung\_gear\_vr.．视图:谷歌学术搜索
7. 维基百科，“谷歌Daydream”，2016年，2020年5月，https://en.wikipedia.org/wiki/Google \ _Daydream．视图:谷歌学术搜索
8. TPCAST​​，“Vive无线适配器”，2017年4月2020年，https://www.tpcast.cn/index.php?s=/front/goods/index/good/10228/l/ten-us.．视图:谷歌学术搜索
9. 阀门，“Vivewireless适配器”，2018年6月20日，https://www.vive.com/us/wireless-adapter/．视图:谷歌学术搜索
10. Oculus，“Oculus链接如何工作？建筑，管道和AADT解释说，“2019年2月2021年，https://developer.oculus.com/blog/how-does-oculus-link-work-the-architecturepipeline-and-aadt-explained/．视图:谷歌学术搜索
11. M. Abdallah，C.Griwodz，K。陈，G. Simon，P.-c。王，C.-h.HSU，“云中延时敏感的视频计算”《多媒体计算、通信和应用》，卷。14，不。3s，第54条，第54页，2018年1-29，2018年。视图:出版商网站|谷歌学术搜索
12. M.Barash，“延迟 - 正弦值和AR和VR。阀门，“2012年1月20日，http://blogs.valvesoftware.com/abrash/latency-the-sine-qua-non-of-ar-and-vr/．视图:谷歌学术搜索
13. A. Seam, A. Poll, R. Wright, J. Mueller和F. Hoodbhoy，使用5G网络启用移动增强和虚拟现实，AT＆T，2018年1月2020年，https://about.att.com/cmms/dam/snrdocs/foundry%20arvr%20public%20whitepaper%20.pdf.．
14. P.Jombík和V.Bahýl，“短期延迟Disconjugate在音频范围内对瞬态刺激的前景反应”，“神经病学杂志CHINESS，卷。76，没有。10，pp.1398-1402,2005。视图:出版商网站|谷歌学术搜索
15. 3GPP，基于3GPP的虚拟现实(VR)媒体服务(第16版)，2018，技术报告，TR 26.918 v16.0.0。
16. m .个VR在两年内能够、应该和几乎肯定会成为什么， 2014年，2020年3月，https://media.steampowered.com/apps/steamdevdays/slides/vrshouldbe.pdf.．
17. G. S. M. A. Future Networks，“云AR/VR白皮书”，技术代表，GSM协会，2019,2020年1月，https://www.gsma.com/futurenetworks/wiki/cloud-ar-vr-whitepaper/．视图:谷歌学术搜索
18. S. solotko，瞬时云:5G无线网络的新兴消费者应用，Tirias，2018年1月2020年，https://www.tiriasresearch.com/downloads/the-instantaneouscloud-emerging-consumer-applications-of-5g-wireless-networks/．
19. E. Cuervo, K. Chintalapudi和M. Kotaru，“创造完美的幻觉:创造逼真的虚拟现实耳机需要什么?“在第十九届移动计算系统与应用国际研讨会论文集(HotMobile ' 18)，第7-12页，坦佩，亚利桑那州，美国，2018。视图:出版商网站|谷歌学术搜索
20. Valve，“Steam硬件和软件调查:2020年1月”，2020年2月，https://store.steampowered.com/hwsurvey/．视图:谷歌学术搜索
21. O. Kreylos，“灯塔追踪审查，”2016年1月20日，http://doc-ok.org/?p=1478.．视图:谷歌学术搜索
22. L. Liu，R. Zhong，W. Zhang等，“切割绳索：设计具有低延迟远程渲染的高质量未经支持的VR系统，”第16届国际移动系统、应用和服务年会论文集，pp.68-80，慕尼黑，德国，2018年。视图:出版商网站|谷歌学术搜索
23. O. Kreylos，“Oculus Rift DK2的跟踪更新率”，2016年1月20日，http://doc-ok.org/?p=1405.．视图:谷歌学术搜索
24. A. Hogge，控制器显示拨打拨打延迟，动视中央科技，2019,2020年8月，https://twvideo01.ubm-us.net/o1/vault/gdc2019/presentations/hogge_akimitsu_controller_to_display.pdf.．
25. “头盔显示器头部运动的非线性预测”，技术代表，技术论文。空军人力资源实验室布鲁克斯AFB TX，旧金山，美国，1983。视图:谷歌学术搜索
26. 拉塞尔和我，泰勒，使用OSVR说明虚拟现实系统概念， K彼得斯/CRC出版社，美国纽约，2019。视图:出版商网站
27. J. Carmack，“延迟减缓战略”，2013年，2020年9月，https://danluu.com/latency-mitigation/．视图:谷歌学术搜索
28. R. H. Y. So和M. J. Griffin，“使用头部位置预测和图像偏转来补偿头部耦合显示器的滞后”，杂志上的飞机，第29卷，第2期6、1992年。视图:出版商网站|谷歌学术搜索
29. J. M.P.Van Waveren，“消费硬件上虚拟现实的异步时间扭曲，”第22届ACM虚拟现实软件和技术会议的诉讼程序，第37-46页，慕尼黑，德国，2016。视图:出版商网站|谷歌学术搜索
30. W. R. Mark，L. McMillan和G.主教，“渲染3D翘曲”中1997年互动3D图形研讨会的诉讼程序，p。7，普罗维登斯，罗德岛，美国，1997年。视图:出版商网站|谷歌学术搜索
31. E. M. Peek, B. C. Wünsche，和C. lutoth，“图像扭曲增强消费者的头戴式显示器应用，”在第十五届澳大利亚用户界面会议的诉讼程序，第47-55页，奥克兰，新西兰，2014。视图:谷歌学术搜索
32. F. a . Smit, R. van Liere，和B. Fröhlich，“VRArchitecture平滑运动的设计和实现”，在2007年ACM虚拟现实软件和技术研讨会的诉讼程序，第153-156页，加州新港滩，2007年。视图:出版商网站|谷歌学术搜索
33. S. M. Lavalle，虚拟现实，剑桥大学出版社，奥卢大学，芬兰，2019年，http://vr.cs.uiuc.edu/．
34. Z. Lai，Y. C. Hu，Y. Cui，L. Sun，N. Dai和H.S.李，“大海：在今天的移动设备上进行高质量的沉浸式虚拟现实”IEEE移动计算汇刊第19卷第2期7, pp. 1586-1602, 2020。视图:谷歌学术搜索
35. T. Bova和Krivoruchka，可靠的UDP协议，IETF，1999年8月2020年，https://tools.ietf.org/html/draft-ietf-sigtran-reliabiess-udp-00.．
36. F. Mwalongo, M. Krone, G. Reina，和T. Ertl，《基于网络可视化的最新报告》，计算机图形论坛，卷。35，不。3，pp。553-575,2016。视图:出版商网站|谷歌学术搜索
37. H. T. Dinh, C. Lee, D. Niyato, P. Wang，“移动云计算:架构、应用程序和方法的调查”，无线通信和移动计算，第13卷，第2期18，pp。1587-1611,2013。视图:出版商网站|谷歌学术搜索
38. O. G. Staadt，J. Walker，C.Nuber和B. Hamann，“基于互动集群的多屏渲染的软件平台的调查和性能分析”虚拟环境研讨会的程序，PP。261-270，瑞士苏黎世，2003年。视图:出版商网站|谷歌学术搜索
39. X组织基金会，“X窗口系统”，1984年，2021年2月，https://en.wikipedia.org/wiki/x_window_system.．视图:谷歌学术搜索
40. M. R. van der Werff, M. H. K. de Grijp, S. G. vind，和B. R. Haverkort，《isdn上的X窗口系统——性能研究》，刊于第十届英国电信研讨会，第十届。电信网络性能工程，pp.1-7，Marlesham Heath，英国，1993年。视图:谷歌学术搜索
41. T. Richardson, Q. Stafford-Fraser, K. R. Wood和A. Hopper，《虚拟网络计算》，IEEE互联网计算，卷。2，不。1，pp。33-38,1998。视图:出版商网站|谷歌学术搜索
42. N. Tolia, D. G. Andersen和M. Satyanarayanan，“量化瘦客户机上的交互用户体验”，电脑，卷。39，没有。3，第46-52,2006。视图:出版商网站|谷歌学术搜索
43. SGI，“OpenGL Vizserver，2000年2月2021年，https://web.archive.org/web/20000817094004/http://www.sgi.com/software/vizserver/overview.html．视图:谷歌学术搜索
44. J. Brooke，T. Eickermann和U. Woessner，“在协作环境中的应用转向”2003年ACM/IEEE超级计算会议论文集- SC '03，p。61，Phoenix AZ USA，2003。视图:谷歌学术搜索
45. S. N.实验室和K. Inc，“ParaView，”2002年，2021年2月，https://gitlab.kitware.com/paraview/paraview．视图:谷歌学术搜索
46. P. Navratil，J. Johnson和V.Bromm，“基于宇宙学粒子的数据集的可视化”，计算机图形学学报，第13卷，第2期6，页1712-1718,2007。视图:出版商网站|谷歌学术搜索
47. StreamMyGame，“About”，2007年，2021年3月，https://web.archive.org/web/20080927072853/http://www.streammygame.com/smg/modules.php?name=about.．视图:谷歌学术搜索
48. 英伟达，“现实服务器”，2009年，2021年2月，https://web.archive.org/web/20091025074652/http://www.nvidia.com/object/realityserver.html．视图:谷歌学术搜索
49. Onlive，“Onlive，”2010年2月2021年，http://onlive.com/．视图:谷歌学术搜索
50. K.-t.陈，y.-c。chang，p。 -Tseng，C.-Y.黄，C.-l.雷，“测量云游戏系统的延迟，”第19届ACM多媒体国际会议（MM '11）的诉讼程序，第1269-1272页，斯科茨代尔，亚利桑那州，美国，2011。视图:出版商网站|谷歌学术搜索
51. 彭译葶。黄,K.-T。陈,D.-Y。陈,周宏儒。许,学术界。许,“GamingAnywhere”,《多媒体计算、通信和应用》，第10卷，第5期。1，第10条，2014年第1-25页。视图:出版商网站|谷歌学术搜索
52. M. Claypool和D. Finkel，“基于云的游戏中延迟对玩家表现的影响”2014年度网络和系统年度研讨会对游戏的支持，第1-6页，日本名古屋，2014。视图:出版商网站|谷歌学术搜索
53. 索尼，“现在的PlayStation”，2014年2月2021年，https://www.playstation.com/en-us/ps-now/．视图:谷歌学术搜索
54. 谷歌，“Stadia，”2019年2月2021年，https://stadia.google.com/．视图:谷歌学术搜索
55. M. Marsden, M. Hazas，和M. Broadbent，“从一个边缘到另一个:探索游戏在网络上不断上升的存在”第七届ICT促进可持续性国际会议论文集，第247-254页，布里斯托尔，英国，2020。视图:出版商网站|谷歌学术搜索
56. Nvidia，“GeForce现在，”2020年2月2021年，https://www.nvidia.com/en-us/geforce-now/．视图:谷歌学术搜索
57. 维基百科，“立法局，”2015年2月2021年，https://en.wikipedia.org/wiki/GeForce_Now．视图:谷歌学术搜索
58. 微软，“Xbox Cloud Gaming，”2019年2月2021年，https://www.xbox.com/en-US/xboxgame-pass/cloud-gaming．视图:谷歌学术搜索
59. 亚马逊，“Luna”，2020,2021年2月，https://www.amazon.com/luna．视图:谷歌学术搜索
60. 英伟达，“CloudXR”，2020,2021年3月，https://developer.nvidia.com/nvidia-cloudxr-sdk．视图:谷歌学术搜索
61. Y. Li和W. Gao，“Muvr：支持使用资源受限的边云的多用户移动虚拟现实，”2018年IEEE / ACM研讨会上的课程（SEC），pp.1-16，西雅图，WA，美国，2018年。视图:出版商网站|谷歌学术搜索
62. M.F.F. Romero-Rondón，L. Sassatelli，F. Precioso和R. Aparicio-Pardo，“虚拟现实视频的流动流”，第九届ACM多媒体系统会议论文集，第494-497页，阿姆斯特丹，荷兰，2018。视图:出版商网站|谷歌学术搜索
63. S. Shi, V. Gupta, M. Hwang, R. Jana，《边缘云上的移动VR:延迟驱动的设计第十届ACM多媒体系统会议论文集，第222-231页，马萨诸塞阿默斯特，2019年。视图:出版商网站|谷歌学术搜索
64. M. Viitanen, J. Vanne, t.d. Hämäläinen和A. Kulmala，“交互式360度虚拟现实游戏的低延迟边缘渲染方案”2018 IEEE第38届分布式计算系统国际会议(ICDCS)，pp.1557-1560，维也纳，奥地利，2018年。视图:出版商网站|谷歌学术搜索
65. T. Kämäräinen, M. Siekkinen, J. Eerikäinen，和A. Ylä-Jääski，“CloudVR:云加速交互式移动虚拟现实”第26届ACM多媒体国际会议论文集(MM’18)， pp. 1181-1189，韩国首尔，2018。视图:出版商网站|谷歌学术搜索
66. M.Pitkänen，M.Viitanen，A. Mercat和J. Vanne，“移动设备上的远程VR游戏”第27届ACM多媒体国际会议的诉讼程序，页2191-2193，法国尼斯，2019。视图:出版商网站|谷歌学术搜索
67. E. Cuervo, A. Wolman, L. P. Cox等人，“Kahawai:使用GPU卸载的高质量手机游戏”第十三届国际移动系统、应用和服务年会论文集(MobiSys’15)，pp.121-135，佛罗伦萨，意大利，2015。视图:出版商网站|谷歌学术搜索
68. 英伟达，“GTC硅谷2019 ID:S9914，云XR: 5G流媒体XR的挑战和策略”，2019,2021年3月，https://developer.nvidia.com/gtc/2019/video/s9914/video．视图:谷歌学术搜索
69. J. Carmack，“第2天主题演讲|Oculus Connect 6，“2019年5月20日，https://www.youtube.com/watch?v=pmidaomx0ga.．视图:谷歌学术搜索
70. 钟锐，王敏，陈振宇等，“基于可编程无线高质量虚拟现实系统的设计与实现”第八届亚太系统研讨会论文集印度孟买，2017年。视图:出版商网站|谷歌学术搜索
71. Nvidia，“Nvidia video codec SDK”，2013年，2020年1月，https://developer.nvidia.com/nvidia-video-codec-sdk．视图:谷歌学术搜索
72. Riftcat，“Dev update #57-streaming enhanced release，”2020,2020年8月，https://blog.riftcat.com/2020/04/dev-update-57-streaming-enhanced-release.html．视图:谷歌学术搜索
73. J. Nieh，S. J. Yang和N. Novik，“使用慢动作基准测量瘦客户性能”，“计算机系统汇刊第21卷第2期1，页87-115,2003。视图:出版商网站|谷歌学术搜索
74. V.Kelkkanen，M. Fiedler和D. Lindero，“非全景VR远程渲染的比特率要求”第28届ACM多媒体国际会议的诉讼程序（MM '20），第pp。3624-3631，西雅图，WA，美国，2020。视图:出版商网站|谷歌学术搜索
75. Valve，“OpenVR SDK”，2015年，2020年1月，https://github.com/valvesoftware/openvr.．视图:谷歌学术搜索
76. A. Vlachos，先进的虚拟现实呈现，阀门，2015年2月20日，http://alex.vlachos.com/graphics/alex_vlachos_advanced_vr_rendering_gdc2015.pdf.．
77. nvidia，“视频编码和解码GPU支持矩阵”2016，1月20日，https://developer.nvidia.com/video-encode-decode-gpu-support-matrix.．视图:谷歌学术搜索
78. V.软件，“GamenetWorkingsocks，”2018年8月20日，https://github.com/ValveSoftware/GameNetworkingSockets．视图:谷歌学术搜索
79. 数据报拥塞控制协议(DCCP) 11.4。ack矢量选项，"技术代表，IETF, 2006年，2020年8月，https://tools.ietf.org/html/rfc4340#section-11.4．视图:谷歌学术搜索
80. Microsoft，“IPPROTO_TCP套接字选项”，2018年8月20日，https://docs.microsoft.com/en-us/windows/win32/winsock/ipproto-tcp-socket-options.．视图:谷歌学术搜索
81. Engadget，“HTC Vive PC凭借中国的云VR服务，”2017年5月20日，https://www.engadget.com/2017-09-19-htc-vive-china-cloud-vr-service.html.．视图:谷歌学术搜索
82. K. Andersson，M. Nilsson和A. Gylling，北方5G创新中心，爱立信，Telia和Tieto, 2020年，2020年9月，https://www.5ginnovationhubnort.se/．
83. T.-K。Le, U. Salim和F. Kaltenberger，“在3GPP发布15和16中超可靠低延迟通信的物理层设计概述，”2020，http://arxiv.org/abs/2002.03713[eess.sp]。视图:谷歌学术搜索
84. V. Kelkkanen和M. Fiedler，“在TPCAST无线虚拟现实设置中研究时间数据传输问题的试验台”第28届国际电信网络和应用会议论文集，悉尼，澳大利亚，2018年。视图:出版商网站|谷歌学术搜索
85. A. Basu，A. Sullivan和K. Wiebe，“可变分辨率电话，”IEEE系统人与控制论会议论文集，第4卷，170-175页，法国，1993年。视图:谷歌学术搜索
86. S. Lee和A. C. Bovik，“FAVEATED视频处理的快速算法”视频技术电路和系统的IEEE交易，第13卷，第2期2，页149-162,2003。视图:出版商网站|谷歌学术搜索
87. C. J. Hansen， " WiGiG: 60 GHz波段的千兆位无线通信"，IEEE无线通信，卷。18，不。6，pp。6-7,2011。视图:谷歌学术搜索
88. Y.Ghasempour，R. C. M. Claudio，C.C.Dai Silva，以及E. W. Wikightly，IEEE 802.11ay：100 GB / S Wi-Fi的下一代60 GHz沟通，“IEEE通讯杂志，第55卷，第55期12，页186-192,2017。视图:谷歌学术搜索
89. Ieee，项目IEEE 802.11ay的状态， 2020年6月，http://www.ieee802.org/11/Reports/tgay_update.htm．
90. F. Alriksson，L.Boström，S. Joachim，Y.-P。Eric Wang和A. Zaidi，关键的物联网连接，爱立信，2020年9月20日，https://www.ericsson.com/49ba0b/assets/local/reports-papers/ericsson-technology-review/docs/2020/critical-iot-connectivity.pdf．
91. 张伟，王锐，“基于深度学习的实时图像超分辨率研究”，《中国科学(d版)》实时图像处理杂志，卷。17，不。6，pp.1885-1909,2020。视图:出版商网站|谷歌学术搜索

版权

版权所有©2021 Viktor Kelkkanen等。这是分布下的开放式访问文章创意公共归因许可证，允许在任何媒介上不受限制地使用、传播和复制，但必须正确引用原作。