20ATC_Firefly: Untethered Multi-user VR for Commodity Mobile Devices解读

Overview

20年出了两篇Muti-user VR的文章，今天阅读了其中一篇并记录一下。
VR系统主要解决的是渲染延时，常见的方法是将small objects在客户端渲染，将heavy background放在服务端渲染。
本文提出的优化方法包括：

• offline content preparation. 提前将background在服务器端渲染和编码好。
• viewport-adaptive streaming. 划分tile，预测用户的viewport背景并下载。
• adaptive content quality control. 在多用户场景下，分配有限的带宽资源。

作者分析该系统能支持15个用户和60FPS帧率。

这是系统的架构图。左边是服务器，作者把background都提前渲染编码好放在Content DB(database)。客户端发送tile请求后（Tile Req. Queue），由AQC分配给各tile对应的质量，由Tile Xmit Queue返回。客户端有多级缓存存储tiles，其中L2和L3存储待解码的tile，L2速度更快。L1存储已解码的tiles，可以拿去跟objects复合及渲染。下方是viewport prediction并决定下载的tile list。

System Design

Offline Rendering Engine

客户端，作者将frame在水平方向上划分为tile，采样为不同的quality level，渲染编码后存储在content database中。客户端依据对应的tile list可以直接下载。每一帧包含颜色信息和深度信息。
如果是online rendering，则服务器负载过大；如果是在client渲染，则资源不足。本文的方式用存储空间换取负荷和延时。

viewport prediction

作者首先采集了一个包含25个用户的数据集，并分析了一些轨迹特征。
作者提出了跟360 videos一样，针对background采用FoV prediction和prefetch。预测的值包括：translational movement (X/Y/Z)和rotational movement (yaw/pitch)。作者通过在线训练一个linear regression model，采用前50ms的轨迹来预测后150ms的轨迹。这里预测的粒度是ms级的。

Client-side tile fetching scheduling

预测完视野后，就可以预取对应的tile。由于background基本没变化，因此作者提前2点优化：

• 如果该tile依据存储在客户端缓存中了，那么可以不用下载；
• 如果同一tile多次出现在一个list中，则取最新的一次。

作者提出三点优化容忍预测错误：

• 只要tile跟用户视野有重合，就下载；
• 扩大约10%的FoV；
• 用户保持静止时，则要多下载相邻的4个tile，防止用户移动。（作者测量得出用户静止2s后很可能移动）

Adaptive Quality Control

AQC收到用户请求的tile lists后，则要给各个用户的tile分配quality level。（同一用户的各tile质量一样）本质是分配带宽，使得多用户的fair。
先计算该系统的总带宽（line 1），当前各tile的分配方案（line 2），各用户能提供的带宽（3）。对于每个用户，如果当前需要的带宽大于用户已有的带宽，则依次下降对应的质量水平（5-6）。将总带宽减去对应的用户分配带宽。如果最后总带宽被耗尽了，则采用LRU依次选取用户质量水平最近最少变化的用户，将质量水平减1。（按我的理解变化次数应该是基于5-6行决定的）带宽还剩余则相反。
Q：初始的质量如何确定。（按我的理解应该是初始化为最高质量）

Client-Side hierarchical cache

作者在客户端划分为多级缓存，速度L1>L2>L3。L1存储已解码待渲染的背景。L2和L3存储待解码的背景。多级缓存的优点跟存储系统类似。

Handling dynamic foreground objects

跟传统一样，作者在客户端渲染small objects。首先，objects’ 3D models (polygons, textures, etc.) are distributed to the clients offline.提前渲染好在客户端，应该是降低渲染资源。
Foreground objects are rendered locally by the client. 对于同一个object，作者依据客户端资源又提出不同的渲染quality level。比如对于objects数量太多、客户端资源差的，应渲染成低质量，保证60FPS。作者提前测量并计算了对照表，实际系统可以直接查阅。

实现

作者在安卓上进行实现。解码采用Android MediaCodec API，投影和渲染采用OpenGL ES，线下的背景渲染采用Unity。整个系统看起来比较复杂。
作者从frame rate, stall duration, content quality, inter-frame quality variation和intra-frame quality variation评估，跟Furion和perfect进行对比。更多实验工作参见原文。

Comments：
这个实验室的工作都是很扎实的，做的工作也很前沿，向他们学习~