Volumetric Video in Mobicom20

本文ViVo: Visibility-Aware Mobile Volumetric Video StreamingPTCL Encoding视频采集编码 预测优化Distance Visibility(DV)Viewport Visibility (VV)Occlusion Visibility (OV) 系统 GROOT: A Real-time Streaming System of High-Fidelity Volumetric Videos数据格式2D Projection-based Compression3D Tree-based Compression Octree Color Bytes (OCB) Compression解码Frustum CullingDepth-based SamplingSystem

本文

最近读了两篇关于Volumetric Video的文章，都是发表在Mobicom 2020的，老板说这是一个promising的方向，感觉Volumetric Video还是有点牛逼的，比现在在做的360度视频又多了三个DoF（Degree-of-Freedom）。

ViVo: Visibility-Aware Mobile Volumetric Video Streaming

普通视频：你没法控制，给你放啥就看啥。

360度视频：三个自由度旋转（yaw, pitch, roll），人不动，头360度旋转。

volumetric视频（立体视频）：再增加三个自由度（X, Y, Z），可以在场景中自由走动，头自由旋转。TED的介绍 最主要的一个区别是表示方式的不同。

普通视频和360度视频：像素点。像素点越多，视频越大，越清晰。

立体视频：用Point Cloud表示，分布在3维空间。密度越大，视频越大，越清晰。 假设一个3D点是15bytes，一帧有200K个点，帧率为30FPS，那么stream这个视频需要的带宽为： $$15\times 200K\times 20\times 8=720Mbps。$$ 因此，需要优化带宽。

360度视频：viewport-adaptation。分割出tile。为不同的tile分配不同的码率。

立体视频：分割出3D cells。为不同的cell分配不同的码率。 全文的核心在这种图上，分别为：

VV：跟360度视频一样，用户只能看到一部分区域，所以看不到的我们可以不要下载。

OV：后面的cell可能会被前面的cell遮挡，所以可以稍微降低密度。

DV：离得近的物体，需要清晰点，密度高；离得远的则相反。 本文要解决的问题有：

立体视频的编码/解码：测量压缩效率如何、分割出cell会给编解码造成多大影响。

用户行为预测：六个维度的预测。

优化：依据三个点分配point density level。

系统设计。

PTCL Encoding

视频采集

作者自己采集了一个数据集。P1-P3分别有1-3个人在谈话，M2-M4有2和4个人在表演。每个视频由32个人观看。 从左到右依次为：id，每帧有多少个点，有多少帧，里面有多少个人，探索空间有多大，码率。

编码

作者对三种已有的不同编码方式进行测量。可以看到，Draco的压缩比最高。可以看到，每帧的点越少，压缩比越高。E和D分别为编码和解码的时间。 利用并行解码进行加速，可以看到，用SGS8时，帧率由10fps提升到40fps。 切分：为了后面的优化，需要把一整块大的空间分割成多块3D cells。但是分割会降低编码的效率，使得视频大小增大。 作者测量了三种方案$25\times 25\times 25c{m}^3$，$50\times 50\times 50c{m}^3$，$100\times 100\times 100c{m}^3$。指标：分割后encoding后的大小/原始视频encoding后的大小。 可以看到，分割后对视频大小的影响是可以接受的。作者最后采用了100的大小。

预测

设置：

共有32个用户，每个用户观看4个视频。第一个视频用户熟悉。一半用户用手机观看，一半用户用MR观看。

测量结论：

用户比较少在垂直方向Y上移动。用户用手机观看时单次移动幅度比较距离，用MR时移动比较顺滑。当场景只有一个物体时，用户会绕着这个物体移动；当有多个物体时，用户会站在中间环视。用户用MR观看时平均移动速度和移动频率更大。

预测：

作者对六个维度分开预测。分别采用linear regression(LR)和multilayer perceptron(MLP)进行预测。预测窗口为200ms。在预测X, Y, Z时，采用过去660ms的数据，在预测yaw和pitch时，采用过去66ms的数据。每33ms更新一次参数。在系统中，作者采用的是LR。

结果：

X和Y误差的中位数在$0.07m-0.09m$。yaw和pitch的误差在$3^{\circ }-5^{\circ }$ 。

优化

任务：为每个cell分配point density level(PDL)，PDL越大，则视频越清晰。适当降低某些cell的PDL，节约带宽。 依据：Distance Visibility (DV), Viewport Visibility (VV)和Occlusion Visibility (OV)。 PDL有5档：20%, 40%, 60%, 80%和100%。（类似码率），用$D(c)$表示对应的档次。

Distance Visibility(DV)

距离：由用户的距离确定PDL，即$D(c)$ 任务：找到用户和cell的距离$d$与PDL的对应关系。

首先进行离线采样，统计出距离d与质量SSIM的关系。（由于观看画面、角度等不同，同个d、同个PDL对应的SSIM稍有不同）（画点）找出SSIM为0.98的分界线。（0.98通常被认为质量无损）（横线的确立）找出此分界线与各PDL采样点的交界处。（竖线的确立）确定距离d与PDL的对应关系。（关系的写出） 由图看到，这里对应关系为：[0,3.2)→100%, [3.2,4.2)→80%, [4.2,5.2)→60%, [5.2,6.2)→40%,[6.2,∞)→20%。 然后应用中就可以依据距离查表得到分配的PDL。

Viewport Visibility (VV)

距离：由viewport确定PDL，即$D(c)$。 过程：

给定6DOFs，在3D图中计算用户的frustum(视锥)，同时依据视锥判断哪些cell在用户的视野内。视野外的不传输。作者把垂直的角度范围扩大为$120^{\circ }$容忍预测误差。把区域依据与viewpoint的角度范围按$60^{\circ }$、$90^{\circ }$和$120^{\circ }$向外分割，每进入下一个区域，$D(c)$的值，即PDL的值减1。比如原始PDL为$D(c)$，为100%。则向外进入到$60^{\circ }$后变为80%，依次递减。

ps：这里具体如何计算视锥好像没细说；以及为什么是垂直角度也不清楚。不过这种向外清晰度依次降低的思想还是可以理解的。

Occlusion Visibility (OV)

作者提出一个变量，遮挡系数$O(c)$， $O(c)$越大，越有可能被其他cell遮挡。 求解$O(c)$：

对于每一个cell：从预测的viewpoint向当前cell的中心画条射线，计算射线的距离$d$。取cell周围$L$距离范围内的其他cell。计算这些cell中距离小于$d$且穿过当前射线的cell数目，记为$S(c)$。记其中点最多的cell的点数目为$c^{{}^{\prime }}$，当前cell的数目为$c$，记$R(c)=c^{{}^{\prime }}/c$。

则$O(c)$正比于$R(c)$和$S(c)$。也就是它前面的cell越多，其他cell的密度越大，越可能被遮挡。 从而，$D(c)=max\{D(c)-O(c),0\}$。 以上就是三种优化方案，还是有点启发式设计。

系统

Rate adaptation：如果分配的PDLs不满足预测的带宽，则会从整体上降低总的PDLs。 （这里没有细讲） 实现：客户端：安卓；服务器：Linux。 性能：主要从节省的带宽和比较高的视频质量两方面论述。

GROOT: A Real-time Streaming System of High-Fidelity Volumetric Videos

GROOT主要是优化视频的传输格式、编解码、PDL来提升。

数据格式

2D Projection-based Compression

将点云通过表面的法线信息分解成多块，并通过dense packing的方法投影到二维矩阵。 传输的图像共包含三个信息：（1）灰度图表示深度信息；（2）颜色信息；（3）是否是有效的point。 缺点：

在noisy data中提取表面法线和映射到二维平面比较困难。当有多个物体时，会增加解码难度和信息的损失。

3D Tree-based Compression

更多的是采用这种树形结构存储。 从整个空间开始，依次分割成8块，编码0-7，包含内容的标为1。再选取非空的继续分割。最终得到一棵树。 这样的话，下面的必须等上面的解码完才能开始，导致无法并行化，因此效率较低。如上所示，帧率均低于30fps。 缺点：

每一层子节点的获取都需要先解码父节点，因此叶子结点没办法并行；随着树的深度的增大，解码的效率会比较低。没办法携带颜色属性。 作者又进行了测量，可以看到，结点的数量会在某一次剧增，导致解码延时也剧增。如果这些结点可以并行解码，将会有极大的优化。 因此，作者提出了并行解码树。在最大深度$D_b$往下，结点直接表示成对应的索引，比如427，为父节点中对应的第4、第2、第7个方块，这样各个结点相互独立，可以并行解码。有点像哈希。

Octree Color Bytes (OCB) Compression

编码颜色信息： 编码颜色文件时，将颜色值保存成2D的图像文件并使用JPEG压缩。挑战：3D点应该放置在2D图像的什么位置。 采用Morton Order压缩算法使得相邻点的颜色比较接近。 同时，对$D_b$层的同一个子树下的的结点重排序，使得颜色相近的结点相邻，提高压缩性能。

解码

CPU解析头部信息并对OBB（位置信息）进行解码。采用JPEG对OBB（颜色信息）进行解码。采用GPU对ODB进行解码（优化后的位置信息）。

Frustum Culling

把用户视野外的点移除。

从根结点依次往下遍历。检查孩子结点是否跟用户的视野重合。如果所有的孩子结点都跟视野重合（或不重合），则提前剪枝（全部包含或不包含）。设置一个遍历的最大深度，节约计算负载。从叶子结点中选择与视野重合的点。

Depth-based Sampling

距离较远的点则降低清晰度。

根据用户的视野投射出一个立方体。然后从viewpoint出发将立方体分成12段。设置每一段的清晰度（sampling density）依次为10%, 13%, 17%, 25%, 33%, 50%, 67%, 75%, 83%, 87%, 90%和100%。

System

实现：客户端：ios，服务器：Linux。 性能：压缩大小、帧率、延时。