Volumetric Video in Mobicom20
本文
最近读了两篇关于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 × 200 K × 20 × 8 = 720 M b p s 。 15\times 200K \times 20 \times 8=720Mbps。 15×200K×20×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
×
25
×
25
c
m
3
25 \times 25 \times 25 cm^{3}
25×25×25cm3,
50
×
50
×
50
c
m
3
50 \times 50 \times 50 cm^{3}
50×50×50cm3,
100
×
100
×
100
c
m
3
100 \times 100 \times 100 cm^{3}
100×100×100cm3。指标:分割后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.07 m − 0.09 m 0.07m-0.09m 0.07m−0.09m。
- yaw和pitch的误差在
3
∘
−
5
∘
3^{\circ}-5^{\circ}
3∘−5∘ 。
优化
任务:为每个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
)
D(c)
D(c)表示对应的档次。
Distance Visibility(DV)
距离:由用户的距离确定PDL,即
D
(
c
)
D(c)
D(c)
任务:找到用户和cell的距离
d
d
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
)
D(c)
D(c)。
过程:
- 给定6DOFs,在3D图中计算用户的frustum(视锥),同时依据视锥判断哪些cell在用户的视野内。视野外的不传输。
- 作者把垂直的角度范围扩大为 12 0 ∘ 120^{\circ} 120∘容忍预测误差。
- 把区域依据与viewpoint的角度范围按 6 0 ∘ 60^{\circ} 60∘、 9 0 ∘ 90^{\circ} 90∘和 12 0 ∘ 120^{\circ} 120∘向外分割,每进入下一个区域, D ( c ) D(c) D(c)的值,即PDL的值减1。比如原始PDL为 D ( c ) D(c) D(c),为100%。则向外进入到 6 0 ∘ 60^{\circ} 60∘后变为80%,依次递减。
ps:这里具体如何计算视锥好像没细说;以及为什么是垂直角度也不清楚。不过这种向外清晰度依次降低的思想还是可以理解的。
Occlusion Visibility (OV)
作者提出一个变量,遮挡系数
O
(
c
)
O(c)
O(c),
O
(
c
)
O(c)
O(c)越大,越有可能被其他cell遮挡。
求解
O
(
c
)
O(c)
O(c):
- 对于每一个cell:
- 从预测的viewpoint向当前cell的中心画条射线,计算射线的距离 d d d。
- 取cell周围 L L L距离范围内的其他cell。
- 计算这些cell中距离小于 d d d且穿过当前射线的cell数目,记为 S ( c ) S(c) S(c)。
- 记其中点最多的cell的点数目为 c ′ c^{'} c′,当前cell的数目为 c c c,记 R ( c ) = c ′ / c R(c)=c^{'}/c R(c)=c′/c。
则
O
(
c
)
O(c)
O(c)正比于
R
(
c
)
R(c)
R(c)和
S
(
c
)
S(c)
S(c)。也就是它前面的cell越多,其他cell的密度越大,越可能被遮挡。
从而,
D
(
c
)
=
m
a
x
{
D
(
c
)
−
O
(
c
)
,
0
}
D(c)=max\{ D(c)-O(c),0\}
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 D_b Db往下,结点直接表示成对应的索引,比如427,为父节点中对应的第4、第2、第7个方块,这样各个结点相互独立,可以并行解码。有点像哈希。
Octree Color Bytes (OCB) Compression
编码颜色信息:
编码颜色文件时,将颜色值保存成2D的图像文件并使用JPEG压缩。挑战:3D点应该放置在2D图像的什么位置。
采用Morton Order压缩算法使得相邻点的颜色比较接近。
同时,对
D
b
D_b
Db层的同一个子树下的的结点重排序,使得颜色相近的结点相邻,提高压缩性能。
解码
- 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。
性能:压缩大小、帧率、延时。