Cloud VR论文解读

引入

总结一下看过的三篇Cloud VR的文章。随着5G的到来，Cloud VR被认为是比较有前景的应用。Cloud VR侧重于VR game（有交互的），相比于VR video (360-degree video)。

传统的游戏/VR渲染是在客户端，这就对客户端的计算能力提出较高要求，耗电也较快。Cloud VR是指渲染迁移到云端，然后直接发送2D视频流到客户端即可。客户端现在变成一个窗口（显示器），不做具体的计算和处理。

一般的game是由背景画面（backgound environment）和物体（object）组成的。比如战场是背景，小兵或英雄是物体等。目前比较场景的处理是在thin client渲染比较轻量级的物体，对于背景这些比较重量级的则放到云上渲染。

Furion: Engineering High-Quality Immersive Virtual Reality on Today’s Mobile Devices

Mobicom 17. 清华/普渡。
这篇是比较早的云VR的系统。作者把渲染分成local rendering和remote rendering，物体放在客户端渲染，背景放在服务器渲染。
虚拟世界被划分为grid points或grid location。每次当用户到达一个grid point时，都把周围的三个区域prefetch下来，避免丢帧。

因此，用户到达前，请求的时延包含：$T_{req}+T_{transfer}$，须小于用户的移动时间20ms。用户到达后，播放的时延包含：$max(T_{phone\_render\_intr},T_{phone\_decode})+T_{intr}$，须满足60FPS。

经过优化，$T_{req}+T_{transfer}=3ms+10ms=13ms$，$max(T_{phone\_render\_intr},T_{phone\_decode})+T_{intr}=max(13ms,12ms)+1ms=14ms$。满足需求。

Coterie: Exploiting Frame Similarity to Enable High-Quality Multiplayer VR on Commodity Mobile Devices

ASPLOS 20. 普渡。

这篇文章相比Fusion可以应用于muti-client的场景。多个用户的带宽需要是单个用户的n倍。但是实际主要还是在单个用户上面优化。
改进主要体现在：

• 提出Near BE (background environment) 和 Far BE，Near BE可以利用client端渲染（作者测量仅渲染object后计算能力还有剩余），Far BE可以放在云端渲染，相似的Far BE可以cache复用。因为Far BE离得较远，所以复用可能性较大（即用相邻帧代替不会引起太大的质量变化）。
• 因此，提升体现在：利用本地资源渲染，利用cache复用相邻帧的背景画面，节省资源。
  

作者通过测量显示，当对比相邻帧时，SSIM的值并不高，比如上面。We observed that many BE frames contain objects (assets in Unity’s terminology) near the player in the virtual world, because of which even a slight displacement of the player location can lead to visible change between the frames. 这些离视野比较近的object会使得相邻帧的SSIM变化大，因此帧之间不能复用。

因此，作者提出把帧分为Near BE和 Far BE，一方面Near BE可以放在客户端渲染，一方面Far BE相邻帧之间SSIM值较高（即画面较接近），因此可以通过cache复用。

这时，需要确定分割半径cutoff radius。系统的响应延时应满足：
$$R{T}_{FI}+R{T}_{NearBE}<16.7ms$$
经过测量$R{T}_{FI}$一般是4ms，则
$$R{T}_{NearBE}<16.7ms-R{T}_{FI}=12.7ms$$
因此，作者的想法是尽可能多地在本地渲染，避免带宽阻塞。即在满足NearBE渲染延时的条件下，尽可能地扩大NearBE的半径。
但同时有一个问题：不同画面包含的object的数目是不一样的，需要的渲染资源或延时是不同的。按我的理解，object越多，需要的资源越多。即在同等client资源条件下，导致的延时更长。
因此，需要解决对于用户到达的某一个位置，如何确定它的cutoff radius，radius以内的在本地渲染，cutoff radius以外的在cloud渲染。这个值是根据每一个VR game和用户计算资源离线确定的。
方法：

1. 对于每一帧，采样K个点。分别计算满足延时条件的最大cutoff radius。
2. 检查这K个采样点的cutoff radius的值是否相同。
3. 如果相同，则将这片区域的cutoff radius设为它们的平均值。
4. 否则，将这片区域分为四个子区域，依次进行上面操作。
5. 最后生成一棵quadtree。每棵树的叶子代表一个子区域，值为它的cutoff radius。

作者测量表面K取10时依据采样半径进行渲染的延时能符合需求。
因此，object density越大，越难渲染，同样计算力条件下时延越长，cutoff radius的值越小，越多地放到云端渲染。
cache复用：作者主要通过前后相似帧进行复用。即要下载Far BE时，在缓存看看有没有与其SSIM高于0.9的帧（0.9被认为是分辨不出差别），如果有则复用。最终的cache ratio能达到80%以上。
经过测量，其他用户的画面并不能很好地提升cache ratio，因此这里没有采用。

Deja View: Spatio-Temporal Compute Reuse for Energy-Efficient 360° VR Video Streaming

ISCA 20. 宾夕法尼亚州立。

这篇文章侧重于VR video。主要解决的是VR设备中的能耗问题，能耗的主要原因是计算。

如图所示，当解码后得到360 Frame（3D）画面后，需要经过360 Video Projection映射得到左右眼观看的2D画面，传到播放器播放。主要能耗在360 Video Projection，输入为360 (3D) Frame和头部朝向，输出为左右眼的2D画面。

其中Video Projection主要包含以下几步：

1. Transformation：计算转换矩阵T，该矩阵可将3D坐标转换为2D坐标，包含5个值，主要看$T_2$：需要head orientation，$T_3$：需要左右眼的pupillary Distance，这里假设该距离是已知且固定的。因此，当头部运动时，$T$是不断变化的；当头部静止时，$T$是不变的。
2. Projection Computation： HMD 采集到的二维坐标图 $V_{2D}^i$ 与 $T^{-1}$(转置) 相乘，将二维坐标矩阵映射到三维坐标矩阵。$i$这里指的应该是每一行。因为 FoV 的像素个数是很庞大的，所以这一步计算是很耗能的。输出是三维映射矩阵 P。
3. Projection Mapping：将计算得到的映射矩阵与 360 Frame 结合，得到最后左右眼的画面 F。

因此，作者提出两个优化方法：

• InterFrame-IntraEye(EA)：当头部不变时，即 head orientation 相同，可以重复利用 P，避免计算 P 的损耗。
• IntraFrame-InterEye(AE)：右眼的 $P_r$ 可以从左眼的 $P_l$ 推断得到。这个后面会说。这样只须计算左眼，然后加一个 $\Delta$，就能得到右眼的。

在 EA 中，作者把过去两帧的 head orientation 及其映射矩阵$P$存储计算，以便后面索引得到。由于头部感知 sensors 是很灵敏的，精度很高，所以存储最近两帧不会浪费空间又能有效节省。这样，计算能耗可以节约到原来的 1%。

AE 中，作者首先计算同一个画面，不同朝向，左右眼各像素点的$P^i$的差异，如图 14所示。可以看到，差值${\Delta }_X$和${\Delta }_Y$均呈周期波动，一个周期刚好是一行 (VR 视频的像素点是 1000 × 1000)。因此，只要计算左眼的$P_l$和第一行的$\Delta$，就能通过加法得到下面行的$P_r$。

上图为实现图。首先由头部朝向确定是否有缓存的$P$，没有则通过 OCE 计算$P_l$和$P_r$的第一行，然后传到 AE 计算$P_r$的其余行，最后更新缓存。