金学骥

（上海数字电视国家工程研究中心有限公司 上海市 200125）

虚拟现实（Virtual reality，简写VR）在最近十年爆发性的增长，其应用范围也越来越广泛，全景视频是最典型的一种VR 应用，全景视频给用户提供了沉浸式的视觉体验，在体育、游戏、教育等领域得到越来越多的应用，大量的在线全景视频业务得到广泛应用。全景视频的一个显著特点是分辨率高，数据量大，传输占用带宽高，这对全景视频传输带来了巨大挑战，另一方面全景视频在观看时只需将视窗区域呈现，因此如何利用全景视频的特点来有效传输是VR 技术关注的一个焦点。全景视频技术发展十分迅速，为了统一全景视频技术标准，运动图像专家组（Moving Picture Experts Group, MPEG)从2015 年开始制定全景视频技术了标准，称为Omnidirectional Media Format (OMAF)，标准中制定了基于三自由度的360 度全景视频系统架构。OMAF 标准定义了一系列全景视频传输机制，其中视窗依赖的传输机制可以减少全景视频传输带宽，提高传输效率。有些传输机制可以不降低视窗区域图像质量时减小视频的分辨率，在相同的解码能力下，可提升观看全景视频的清晰度。视窗依赖传输机制在用户转头时不能立即看到高质图像，会先看到低质图像，然后再切换到高质图像，这对用户体验有所影响。

1 OMAF标准中传输机制介绍

OMAF 标准中在内容传输策略上提出了多种传输机制，各种传输机制关系如图 1 所示。总体上，这些传输机制可分为两类，一种是视窗独立机制（viewport-independent），另一种是视窗依赖机制（viewport-dependent）。

图1： OMAF 标准中传输机制关系图

在视窗独立机制时，全景视频不用分层或分块，全景视频内容在360 度方向上保持相同的映射方法，视频在各个区域有相同的图像质量，传输时将整个全景视频作为一个比特流，终端不需因观看视窗不同而去获取不同的视频。与视窗独立机制不同，视窗依赖机制的特点是终端在观看视窗不同时需要去获取不同的视频，这种机制下利用了全景视频在呈现时并不需要所有区域都呈现的特点，对视窗区域内的图像质量保持不变，降低视窗区域外的图像质量，这样可以降低总体传输带宽。为了实现视窗依赖机制要在源端准备多套视频源，终端OMAF 播放器需要根据用户视窗位置去获取相应的视频源。

视窗依赖机制的实现方法有很多，OMAF 标准中将视窗依赖机制分为整体切换与分块组合两种机制。在整体切换机制下源端准备多个版本的视频源，每一个视频源都包含了360 度的内容，只不过每一个视频源有它偏重的视窗区域，播放器根据用户的视窗角度选择一个全景视频。在分块组合机制下，源端将全景视频在空间上分割多个矩形分块，每个分块可准备多个码率或分辨率版本，分块视频编码后单独做为一个分块轨道，终端获取分块轨道后需将分块轨道组合在一起解码，解码后的视频在视窗区域具有高质量图像。

分块组合机制分为源端绑定机制（Author-driven binding）与终端绑定机制（Late binding）两种。源端绑定机制是指在源端准备了多套视频源，每一套视频源由许多分块组成，视窗内的分块图像质量高，视窗外的分块图像质量低，源端提供提取轨道（Extractor Track）来指示如何将分块数据提取并组合成一个比特流，终端根据用户观察的视窗位置选择某一套视频源，并按提取轨道来完成分块数据组合并解码。终端绑定机制与源端绑定机制相比，终端OMAF播放器有更大的自由度，终端OMAF 播放器来选择哪些分块需要下载，分块下载后，OMAF 播放器从分块中提取出Slice，并改写Slice 头，再将Slice 组合成一个新的比特流。

源端绑定机制可以再细分为两种形式：固定视窗源端绑定（Viewport-specific author-driven binding）与自由视窗源端绑定（Free-viewport author-driven binding）。在固定视窗源端绑定时，源端将全景视频在空间上分割多个矩形分块，每个分块使用运动约束图块集（HEVC Motion Constrained Tile Sets，MCTS）对视频进行编码，每个分块可准备多个码率或分辨率版本，同时源端提供了多种提取轨道（Extractor Track）用于将分块数据组合在一起，每一种提取轨道有固定的高质视窗区域，终端根据视窗区域选择一种提取轨道与相关的分块轨道，将分块轨道组合成一个比特流交给解码器解码。

OMAF 标准中提供了多种固定视窗源端绑定机制方案，图 2 为OMAF 标准提供的一种方案，该方案中原始视频分辨率为（6144×3072），基于ERP 映射全景视频，以下简称该方案为6K ERP 方案。源端在准备工作时需将全景视频按四种方法进行分割，分别是靠近赤道中心区域的分辨率为6K和3K的分割方法，用于南北极区域的分辨率为3K和1.5K的分割方法。视窗内取自6K 版本，而视窗外区域部分来自3K（3072×1536）版本或1.5K（1536×768）版本。南北两极的条纹（纬度值高于60 或低于-60 度）以1.5K 和3K 分辨率进行编码，而中心部分（纬度值在-60 至60 度之间）覆盖纬度范围120°的角度以3K 和6K 分辨率编码，在编码中使用了运动受限（MCTS）的编码方式。编码后的分块比特流序列与提取轨道组合在一起提供16 种不同的视窗观看方向，每个方向都对应于从6K 比特流中选择四个相邻的分块，以及在赤道上方或下方的观看方向。提取轨道指示分块区域如何组合，组合的视频是终端最终解码视频，其分辨率为3840×2304。

图2： 固定视窗源端绑定机制示例

自由视窗源端绑定机制中，源端提供一个提取轨道，但提取轨道在每一个区域上提供了多个分块轨道选择，每一个区域选择哪一种质量的分块轨道由终端OMAF 播放器来决定。图 3 为自由视窗源端绑定机制的一个例子，全视视频按8×4 进行分块编码，分别编码成高码率分块与低码率分块，每一个分块编码序列存成一个分块轨道。提取轨道中每一个分块所在区域提供两个可选项，分别对应高码率与低码率的分块轨道，终端可以在某些区域选择高码率分块轨道，其他区域选择低码率分块轨道。

图3： 自由视窗源端绑定机制示例

2 OMAF标准的全景视频系统流程

基于OMAF 标准的系统流程如图 4 所示，在源端流程包括获取视频源、视频预处理、编码、封装等流程。封装后的视频数据以MMT 协议或DASH 协议进行传输，终端流程包括解封装、视频流组装、解码、映射和渲染等流程。终端上的OMAF 播放器需要根据OMAF 传输机制不同而实现不同的流程，以源端绑定传输机制下终端为例，终端上的OMAF 播放器播放VR 视频的一般流程如图 5 所示。

图4： 基于OMAF 标准的全景视频系统流程图

图5： 终端OMAF 播放器播放流程

OMAF 播放器播放VR 视频的一般流程描述如下：

（1）终端OMAF 播放器根据uri 下载mpd 文件。

（2）终端OMAF 播放器在mpd 中找合适的提取轨道。mpd 中codecs="resv.podv+ercm.hvc2.1.6.L153.80" 表 示 是 提取轨道的描述信息。描述信息中都有srqr 信息，根据这些srqr 信息与当前的观察视察，选择一个合适的提取轨道。

（3）终端OMAF 播放器下载提取轨道与相关分块轨道，根据SegmentTemplate 中的uri 下载提取轨道（包括

initialization）中的value 指示了哪些关联分块轨道对应的adaptationSetid。

（4）终端OMAF 播放器解析提取轨道，得到track id顺序，解析媒体分块轨道文件，知道该文件的track id，把各分块轨道按顺序拼接，然后送入解码器。

（5）终端OMAF 播放器解码时将组装后的码流进行解码。

（6）终端OMAF 播放器对某些分块进行映射操作，这时需要使用rwpk 信息，rwpk 信息可能从提取轨道的initialization 文件中获取。

（7）终端OMAF 播放器最终将2D 的图像变换到3D空间，并将视窗区域呈现到屏幕上来。

3 OMAF标准中实验与分析

OMAF 传输机制中的视频依赖传输机制结合了全景视频传输特点，能减少全景视频传输带宽，提高传输效率。除了传输码率的变化，视窗依赖传输机制对全景视频的分辨率与交互延时带来变化。本文从传输码率、分辨率与交互延时三个方面对OMAF 标准中的典型机制进行实验与分析。

3.1 OMAF传输机制的视频生成

本节列出实验视频生成的方法，包括视窗独立机制、自由视窗源端绑定机制与固定视窗源端绑定机制下视频生成方法。方法中使用了ffmpeg 对原始视频进行解码，用kvazaar对YUV 格式视频进行编码，使用MP4Box 生成mp4 文件，使用omafvi 与omafvd 实现OMAF 封装。

3.1.1 视窗独立机制视频生成

3.2 传输码率分析

本文对视窗独立传输机制、固定视窗源端绑定机制与自由视窗源端绑定机制进行了对比实验。为了进行对比，三种机制下原始视频的分辨率都为6K（6144x3072），通过wireshark 软件进行抓包，并通过该wireshark 中的I/O Graphs 功能得到实测码率数据，再计算出各种传输机制下的平均码率如表1 所示。

表1： 三种传输机制实测平均码率

从实验结果上看，视窗独立传输机制、固定视窗源端绑定机制与自由视窗源端绑定机制三种实测码率分别为11.6Mbps、6.7Mbps 与7.7Mbps。固定视窗源端绑定机制与自由视窗源端绑定机制都是视窗依赖机制，视窗依赖机制相对于视窗独立机制传输码率上都有降低。固定视窗源端绑定机制能降低解码视频的分辨率，从6144x3072 降到了3840×2304，因此能显著降低传输码率。

3.3 清晰度分析

全景视频清晰度以单位角度的像素数 (pixel per degree,PPD) 来衡量，人眼能达到的理想分辨率大约为60PPD（每度像素数），在工业和信息化部印发的《关于加快推进虚拟现实产业发展的指导意见》中提出“实现30PPD（每度像素数）单眼角分辨率、100Hz 以上刷新率、毫秒级响应时间的新型显示器件及配套驱动芯片的规模量产”，所以达到30PPD是目前全景视频清晰度的一个目标。从表 2 可以看到要达到30PPD 的效果全景视频需要12K 的分辨率，这对于目前的VR 头盔是无法达到的一个高度，如何充分利用VR 头盔硬件能力，达到最佳的呈现效果对全景视频体验至关重要。

表2： 全景视频分辨率与PPD 的对应关系

对于VR 头盔，解码能力与屏幕分辨率是制约最终显示清晰度的两大因素。以Pico G2 4K 为例，该VR 头盔可以解码4K 分辨率的全景视频，全景视频为ERP 映射方式时，PPD 可以达到10.67。Pico G2 4K 屏幕分辨率为3840x2160，左右视场角为101 度，屏幕可以显示的PPD 为(3840/2)/101=19。结合两方面的数据，呈现ERP 映射的全景视频，最高的清晰度只能达到10.67，屏幕显示能力还未允分发挥。

在不降低视窗区域内的图像质量下减小全景视频的分辨率，可允分利用头盔的解码与屏幕显示能力，如图 2 的6K ERP 方案中，原始视频的分辨率为6144×3072，通过区域封装后，在终端组合的视频分辨率为3840×2304，达到4K 水平，但视窗区域内的图像质量保持原始6K 的效果，这样可使最终观看的像素密度由原来10.67 提高到17。

3.4 交互延时分析

OMAF 视窗依赖传输机制下，但当用户转头离开了高质的视窗区域，用户先看到低质图像，经过一个时延再看到高质图像，这一切换过程就是交互延时。这个时间与MTP(Motion To Photons)不同，MTP 是指用户开始转头到呈现出图像的时间差。在OMAF 视窗依赖传输机制下，用户转头后会在MTP 时间里先看到低质图像，然后再切换高质图像。交互时间太长会使用户无法忍耐，当切换时间超过1秒后，用户很可能认为无法切换到高质图像，而导致转看其他视角或放弃观看全景视频。

本文对视窗依赖传输机制时，不同分辨率视频交互延时进行了测试，结果如表 3 所示，交互延时随全景视频分辨率提高而变长，在8K 分辨率时切换时间达到1.48 秒，用户明显感觉切换时间比较长。

表3： 高质视频恢复时间

4 结束语

OMAF 标准提供了多种传输机制，这些传输机制各有特点，为终端提供了多种全景视频传输与呈现选择。在带宽受限的情况下可以采用视窗依赖机制，尤其固定视窗源端绑定机制可以节约更多的带宽。若终端设备的解码能力有限时，为了充分利用设备的屏幕显示能力，可以选择一些固定视窗源端绑定机制，如6KERP 方案。但使用OMAF 传输机制时需要注意到采用OMAF 标准后带来的交互延时，尽量避免交互延时过长。