来源:SPIE2021 作者:Mengyu Chen, Basel Salahieh等 内容整理:胡经川 本文介绍了一种简化的 MPEG Immersive Video 传输方法,利用了 HEVC 码流中的 SEI 消息语义来传输多视角纹理视频以及深度信息。此外还基于开源的 VLC 播放器开发了一套可以实现面部跟踪的自由视角播放器用于验证传输策略,它支持在观众选择的任何观看位置进行实时视角合成。
目录
沉浸式媒体在今天得到了广泛的关注,学术界已经做出了巨大的努力来探索和解决其技术挑战。ISO/IEC MPEG 牵头的沉浸式音频、图像和视频信号编码表示的标准化工作已经得到了非常积极的发展。MPEG Immersive Video(MIV)旨在压缩由多相机捕获的3D场景表示。MIV标准通过播放摄像机拍摄的3D场景,实现高保真的身临其境体验,为观众观看的位置和方向提供六个自由度(6DoF)。随着MIV标准在2021年7月实现技术层面的完成,越来越多的工作希望探索实时沉浸式视频播放和流媒体的能力。
MIV标准的开发旨在满足新兴沉浸式生态系统对数据访问和交付机制的关键需求。它基于可视体积视频 (Visual Volumetric Video)编码(V3C)标准,该标准定义了 MIV 与 MPEG 点云视频编码(V-PCC)之间的共性。比特流格式、配置文件和解码过程都是 MIV 规范的标准范围,而编码和渲染过程是MPEG沉浸式视频相关测试模型(TMIV)中尚未涉及的非标准部分。
图1:TMIV 编码和解码流程
图1显示了 TMIV 软件的编码和解码过程。在编码器阶段,将多个视图(包括纹理和深度信息)及其相机参数(包括位置和方向)输入 TMIV 编码器。TMIV 编码器仅提取重建场景所需的信息,去除冗余信息,并以补丁的形式将其以紧凑的方式打包到视图集中。然后使用所需的视频编码器对视图集进行编码,并且子比特流与相关联的元数据一起复用以形成 MIV 比特流。在解码器端,比特流被解复用和解码,以检索视图集和元数据,并传递给渲染器,渲染器根据观看者的运动以交互方式合成相应的视角。
MIV 可以使用AVC、HEVC、AV1、VVC或其他视频编解码器。此外,它还可以处理任何拍摄系统和任何投影类型以获取真实世界内容或合成内容。此外,MIV 比特流还包括高级语法,用于对齐视图集和相机,从而对视角相关的流进行解码和渲染。此外,MIV具有多种可选特性和操作模式,以支持许多用例。其中一种模式是 MIV 视图模式,如图2所示。在该模式中,编码阶段被简化,此模式选择视图的子集,而不是使用补丁,并且选择的视图被全部打包到视图集中。MIV 还具有可选的帧打包功能,其中纹理和深度可以打包到同一帧中。
图2:MIV 视图模式的处理流程
在这项工作中,作者提出了一种将 MIV 视频只通过一层 HEVC 码流进行传输的简化方法,将 MIV 的传输简化为单层视频码流的好处是使其适合于传统视频编解码器,并有利于利用GPU和视频播放器中已经优化的支持。在 HEVC 补充增强信息(SEI)中存储 MIV 比特流的所有非视频部分,并将多路视频拼接在一起(使用MIV的帧打包功能),并编码为单个视频的 HEVC 比特流(包括 MIV 和 SEI 消息)。图3说明了传统 MIV 比特流和提出的单层 HEVC 比特流之间的差异。此方法简化了编码和解码操作,避免了在处理多个流时遇到的同步和缓冲问题。利用这种方法来保持与主流媒体的兼容性。值得注意的是,SEI 已在MPEG中被提出,但尚未在 MIV 规范中采用,所以使用的 SEI 消息将作为 HEVC 的 SEI 消息而不是 MIV 的 SEI 消息进行传输。所以建议在 HEVC 规范中定义MIV SEI消息的有效负载类型,但在 MIV 规范中定义 SEI 消息有效负载。在 HEVC 规范中定义有效负载类型的替代方法是使用用户定义的SEI消息。
图3:MIV 视频的单层 HEVC 码流表示
开发的 Freeport 播放器用于验证提出的 MIV 数据传输的简化方法。此播放器是在开源 VLC 视频播放器上构建的,该播放器采用了 MIV 渲染器的 DirectX 实现,以及用于用户视角切换指令输入的人脸跟踪工具。Freeport 播放器支持端到端沉浸式视频播放体验,其中观众可以简单地打开本地存储的 MIV 比特流或来自传统流媒体服务器的视频流,并从任何期望的观看角度和位置与合成的沉浸式内容进行交互,并实时进行视图合成,以便在 Freeport 播放器中显示的内容可以与观众面部位置相对应的视角相对应。下面将介绍 Freeport 播放器的主要组件、数据同步机制和渲染步骤。
Freeport 播放器是基于开源 VLC 视频播放器实现的,并将 MIV 解码和渲染作为插件完全集成到VLC中,另外还附加了人脸跟踪输入模块。可以将 Freeport 播放器分为四个组件:VLC 视频播放器、MIV 解码器、基于 DirectX 的 MIV 渲染器和人脸跟踪模式。
图4显示了不同类型的数据如何在不同的硬件组件上同步。在解码 MIV 比特流之后,MIV解码器将解码的视频数据发送到MIV渲染器。视频组件直接作为GPU图形资源进行传递,非视频组件在CPU上处理。CPU上的预渲染阶段会调用面部跟踪模块来收集观看者的姿势,同时调用元数据解析器从非视频组件中提取 MIV V3C 数据。在解析和人脸跟踪之后计算每个相机的权重。一旦所有CPU资源就绪,它们将上载到图形GPU内存,并将在渲染过程中的不同步骤中使用。
图4:数据同步机制
每次渲染器从 MIV 解码器接收到解码后的 MIV 数据时,它会将非视频组件(例如相机参数和渲染器设置)转换为 GPU 兼容的缓冲区对象,并将它们拷贝到 GPU 设备内存,为 DirectX 11 的视图合成做准备。视频数据的子比特流由 MIV 解码器直接作为 GPU 纹理和着色器资源传递,因为它们已在前面的解码步骤中由 GPU 处理。在为着色器正确注册所有着色器资源后,渲染器将逐步调度所有着色器以合成最终视图纹理并将纹理对象传递到最终视频输出窗口。计算着色器由 8 个步骤组成,每个步骤都使用单个线程组中的最大线程数 (32x32x1) 进行调度,以最好地利用 GPU 上的大量并行处理器。图 5 简要概述了视角合成的主要渲染步骤:
图5:视角合成步骤
本节通过比较不同压缩量化参数(QP)值下的播放性能来描述Freeport player的实验结果。Freeport播放器的演示可以在 https://www.youtube.com/watch?v=UeT_Xm1jBGs&t=1015s 观看。
测试序列为因特尔的Frog序列,这个序列中的源视图是由7台按照从左到右顺序排列的相机阵列捕获的。还包括从源视图中预先提取的的背景视图,并与视频组件打包,作为仅用于修复目的的第八视图。序列的测试长度为300帧,帧速率为30fps。源视图分辨率为1280x720,采用 YUV420 的 10 bit 纹理格式。7个源视图和用于修复的背景视图以4x4格式打包在一起,如图6所示。视频组件的分辨率为2560x5760。
图6:Frog序列
使用量化参数(QP)10、18、22和28对序列进行压缩。因此,总共生成了4个视频文件并用于测试。对于每个比特流,我们还将渲染器设置为使用2、4或7个源视图进行目标视图合成。在渲染过程中使用更多视图时,质量通常会提高,但增加视图数量需要更高的计算复杂度。一共在12种不同的条件下测试了性能。
性能测试主要分为两部分:1)解码器、渲染器和显示阶段的FPS测量,2)每个计算着色器步骤的时间消耗。该测试在配备了Intel Core i7-9700 CPU和Intel Xe Max GPU的PC上进行
表1:解码器、渲染器和显示的FPS表现
表1显示了解码器、渲染器和显示阶段(解码器+渲染器)在不同QP级别使用不同数量的视图进行视图合成的平均FPS。在解码器端,我们可以观察到 QP 和 FPS 之间的相关性。更高 QP 值预计将产生更高的 FPS,这可能是由于比特率差异。在渲染器方面,用于视图合成的视图数量对性能有很大影响。使用更多视图意味着在每个着色器步骤中要计算的像素数更多。渲染器使用的计算着色器将需要调度更多的线程来处理所有像素,因此在最终视图渲染之前需要更长的等待时间。显示FPS基于解码器和渲染器性能,在QP=28、22和18使用2个视图实现了实时性能,在QP=28使用4个视图也实现了近实时性能
表2:各模块的运行时间
表2显示了使用2、4和7参考视图时渲染过程中每个着色器步骤的时间消耗及其所占总时间的百分比。我们发现,在所有情况下,计算成本最高的步骤是步骤0、步骤2和步骤3。与其他步骤相比,步骤0具有最多的线程组,因为它需要将整个输入图集解包到单个缓冲区中,并执行大的内存写入和复制。步骤2和3是算法上最复杂的步骤,因为着色器在 2D 和 3D 坐标之间来回转换所有输入视图的像素,然后在每个源视图上进行曲面前向映射和光栅化。用于视图合成的视图越多,它们需要在这些视图上完成每个像素的映射的时间就越多。类似地,在步骤6中,最终视口着色要求着色器遍历所有输入视图,并通过其权重混合所有有效颜色像素。因此,在使用更多视图进行视图合成时,在这一步骤中也可能会看到更高的时间消耗。
最后附上演讲视频: