Firefly: Untethered Multi-user VR for Commodity Mobile Devices

這篇發在系統領域USENIX ATC 2020的文章，通過預渲染和儲存使用者在空間裡所有可能位置、所有可能角度上看到的影象，互動時根據VR裝置實時的位姿將對應幀傳輸到VR客戶端，最終可支援15個VR客戶端以60FPS速度併發。不得不感嘆，跨領域的文章，真的視角很獨特，VR的渲染一直都是根據實時位姿實時重新整理，從未想過可以事先存下來。

概念科普

在介紹這篇文章之前，介紹一些基本概念，為了將本文的方法和其他方法區分。

普通視訊

我們日常看的電影電視，顯示在二維螢幕上。拍攝的時候什麼視角，播放就什麼視角，無法控制視角。

立體視訊Stereoscopic

一般所說的3D視訊。一般包含紅藍3D或者偏振3D.電影院的3D電影主要是偏振3D，針對人的左右兩眼送出略微不同的視訊，製造視差，帶來一些立體感。目前常規視訊格式mp4等以普遍之前上下排列和左右排列的3D視訊。

立體視訊仍然無法控制視角。

360度全景視訊

基本的VR視訊，三個自由度3DOF旋轉（yaw, pitch, roll），即人的位置不動，頭可以360度旋轉，無法走近或走遠看。

Volumetric視訊 (和這篇Paper沒啥關係)

在360度全景視訊基礎上再增加三個自由度，6DOF,除了旋轉外，還增加了位移動向量，可以走近走遠。生產Volumetric視訊 一般包含了基於網格和基於點雲的兩大類方法。下面三幅圖分別給出了獲取Volumetric視訊的相機擺放、檔案儲存以及實時播放的過程。

主體流程

區分前景和背景

區分背景和前景，前景指的是其他VR使用者的Avarar或者實時變化的Control Panel。背景指的是比較固定不變，但非常複雜的場景。

預渲染

對於背景，進行預渲染。對VR活動的空間範圍進行離散化，生成一個個grid。對每一個grid上，均多次渲染拼接，以及壓縮成一個360度視訊。

實驗中，資料大小如下：

• Map size: 30 X 30 m
• Grid size: 5cm
• Size: 137GB vs. 99GB

一個場景上百GB，這個資料量還是相當大的，而且這樣儲存其實空間上也有很多冗餘，作者以一句現代儲存便宜不是什麼問題帶過。。。感覺還是有一些優化空間的。

儲存

對於grid上每一個位置（5cm間隔），都儲存一個360視訊的幀，文章裡定義為Mega Frame，Mega Frame包含相匹配的顏色和深度buffer，儲存深度為了和前景有正確的深度關係。為了訪存時的效率，對於360度視訊的某一幀，又做了分塊處理，分成四列的原因主要是25個測試者VR互動時基本都是水平移動，很少上下打量，因此切成列效率更高。Mega

Frame又做了LOD，為後面AQC(Adaptive Quality Control)提供可能。這些Mega Frame按照位置和Tile ID存入資料庫。

VR移動預測和Frame訪存

VR Client根據使用者實時的位姿，訪存對應質量的Mega Frame，解壓縮和進行影象顯示。

作為系統類的文章，這裡寫了很多移動預測和AQC。我沒有細看，大致是通過機器學習的方法預測下一步VR位姿，提前載入到VR端的儲存裡，VR的儲存分為硬碟-記憶體-視訊記憶體三級，分別儲存未解壓的Tile檔案，未解壓的Tile檔案，解壓的Tile檔案。

系統架構

整體系統架構如下圖。值得說明的是這裡的L1~L3 Cache不是真正的Cache，L3 Cache是VR client的硬碟，L2是VR Client的記憶體，L1是VR Client的視訊記憶體Frame Buffer。

實驗

硬體

VR Client是簡易的手機配Cardboard的形式，手機是幾款三星從2017到2019釋出的Android 9手機。Server是一個桌面PC，配置如下：octa-core CPU @ 3.6GHz, 16 GB memory, 1TB disk, and Ubuntu 16.04，server無需渲染，只需要儲存預渲染的結果，因此都不需要有GPU.

效能

延遲

總結

這篇文章預設背景是固定的，不能有動態變化，例如動態燈光等等，這裡有比較大的侷限性，同時一個場景的儲存百G級別也是比較大的。感覺對於多人體驗的展會場景（場景單一，多人作業系統對硬體維護成本小），以及建築、風光TOUR這類的情況，有一定的適用性。