基于 RTC 的全景 8K@120fps FoV 实践

1. 行业现状和技术挑战

VR 眼镜的出现与快速发展让“赛博朋克”、“未来世界”不再遥远，通过手柄与音视频画面的互动，人们可以在娱乐、健身时体会到一种全面超越现有音视频的“沉浸式”体验。而在体验云游戏、大型全景赛事互动等应用时，如果想保持这种“身临其境”的“沉浸式”体验，还需要有超高清、高帧率的全景视频源、强劲的传输带宽和超低头动延时（MTP）。

视频源方面，因 VR 眼镜独有的 FOV（Field of View，视场角，VR 设备的重要指标之一，反映视野广度），4K 全景视频在 VR 眼镜上看起来也就只相当于 540P，所以 8K 分辨率视频的分发也仅仅是超高清画质体验的“入门级需求”。另外，一些游戏、体育赛事等内容的视频对帧率也有很高的要求，达到 120fps 才会有较好的体验；传输方面，要实现对这类「富媒体」的超低延时传输则是个很大的挑战，带宽需达到 150Mbps 以上。

VR 眼镜方面，最近两年 VR 一体机技术发展迅速，它 All-in-one 的设计脱离了外部设备的连线束缚，即开即用，受到了市场的广泛欢迎，有逐渐代替 VR 头显之势。不过，“便携”的优点也不可避免地会影响它在解码、渲染、带宽处理上的性能表现，在处理上述 8K@120fps / 150Mbps 的任务时需要进行特殊处理。

当前行业使用的一些解决方案在视频质量/帧率/延时/带宽等各方面做了取舍，导致最终用户体验不太理想：要么是无法忍受的图像质量（低画质），或者是低帧率带来的眩晕（低帧率），又或是无法忍受的延时（高延时），以及巨额的带宽成本（最后一公里全景下发）等，像业内采用的「直播转码」+ 「CDN 分发链路」方案，一方面它的延时较高，无法适用于一些互动性较高的场景；另一方面，由于在云端进行了一次转码，对画质会产生一定的损伤，也会影响用户的“沉浸式”体验。

利用 RTC 传输这类「富媒体」到 VR 一体机可以较好地解决高画质和低延时的问题，但也面临着一些难点。

1.1 8K 和 120 fps 难以兼得

上文已提到，在 VR 场景中，像云游戏、大型展会、赛事等内容的视频，「高分辨率」和「高帧率」缺一不可。然而我们发现，不管是 GPU 还是 VR 一体机的芯片，其编解码能力都无法兼顾到「8K」和「120 fps」性能体验。我们使用了 gpu-z 工具和 Nsight 工具分析了 Nvidia Tesla T4 硬件的编码能力，分析发现，当视频源达到 8K 分辨率时，单张 Nvidia Tesla T4 最高只能支持到 8K@60fps，且存在性能波动，一般单张显卡的性能稳定在 8K@50fps。

以下为测试数据：

从解码能力看，目前市场上主流的 VR 一体机（价位1500-2000元）基本都选用 高通 XR2 芯片，该芯片对外宣称的解码能力为 8K@60fps 或 4k@120fps，实测下来发现，8K@60fps 也是上限数值，实际难以稳定在 8K@60fps。

以下为测试数据：

因此，编解码的性能成为了支持 8K@120fps 最大的瓶颈。

1.2 全解码方案引起带宽性能不足

传输 8K@120fps 全景视频需要 150Mbps 的带宽，目前 5G 渗透率还不高，宽带下载网速无法满足这样的传输条件。

以下为三大运营商2021年下行速度中值数据：

数据来源：《2021年全国网络速度和质量报告》

从合理性上看，VR 眼镜由于视角问题，观看端并不需要同时解码全场景的画面内容，全解码方案浪费了大部分的码流带宽占用，造成了很大的下行带宽，给最后一公里带来了巨大的压力，不利于互联网分发。

1.3 头动延时高易引起眩晕

MTP（Motion To Photons）是 VR 眼镜的另一个重要指标，指从头动到显示出相应画面的时间，MTP 时延太大容易引起眩晕，目前公认的是，当 MTP 时延低于 20ms 就能大幅减少晕动症的发生。

2. 火山引擎 RTC 做了什么

2.1 总体介绍

为了解决上述难题，火山引擎 RTC 引入了 FoV 方案，即让接收端只接收视角区域内的高清码流来解决编解码性能不足和带宽不足的问题。另外，我们通过同时传输高清的 tile 码流和低清的全景背景码流，避免因快速头动导致视角切换而引起的黑屏。利用火山引擎覆盖全球的实时音视频网络边缘节点，最终可实现低清背景 MTP < 20ms，高清 FoV 流 MTP < 100ms。

如图所示，首先，编码端将一路 8K 视频划分成若干个 tile（在 HEVC中，从水平和垂直方向将图像分割为若干个矩形区域，把这些矩形区域称为 tile，每个 tile 都可以独立编码解码），对每个 tile 使用 nvenc 单独进行编码；同时编码一个 2K 的全景图，它可以在接收端做“兜底”，又不会引入较大的码率增加导致解码端性能跟不上；然后，在媒体服务器侧，上行通过一个 ssrc 同时接收高清 tile 流和低清背景流，其中下行高清 tile 流按照用户视场角过滤转发，下行低清背景流不过滤直接全部转发；最后，接收端按照 HEVC tile 标准，将所有 tile 按照图像的位置合并成一路原始大小的编码视频，解码，上屏。

下文详细介绍火山引擎 RTC FoV 方案的实现与优化。

2.2 编码的实现与优化

2.2.1 多 GPU 分布式编码

上文提到，由于单张 Nvidia Tesla T4 不具备 8K@120fps 的编码能力，所以需要通过多 GPU 并行编码来实现。火山引擎 RTC 在编码侧采用多 Nvidia Tesla T4 显卡并行，将 8K 视频切割成 72 个 tile，使用 72 个编码器进行编码，然后通过 RTP 打包发送到网络。

这里需要注意的是不是所有的显卡都能创建多个硬编码器，个人消费级显卡对于编码器的个数是有限制的，Nvidia 的显卡可以在官网进行查询。

2.2.2 码率控制

码率的准确性对下行可接入的 VR 一体机数量比较重要，但测试中我们发现编码器码率控制有时会不准，且单纯调节编码器的编码参数并不能解决这个问题，于是需要在硬编码器内部定时对编码器的实际编码码率进行监控，监控频度设置为 10s，如果实际编码低于预期码率则统一调高所有编码器的码率，反之则调低，调整粒度为 10%。经测试，增加码率监控后能够稳定码率为预设码率。

2.2.3 编码器复杂度调整

编码器的复杂度在默认情况下是在创建完成编码器的时候确认好的，中间不能动态修改，这样会存在如下问题：

• 编码器计算资源过剩的时候不能充分利用编码器，如果编码器的使用率很低是可以提高编码器的编码复杂度，从而提高画质。
• 编码器可能会受到整个系统的性能影响而出现性能下降，如系统的时钟频率被降频会影响编码器的性能，如果此时能够降低编码器的复杂度，从而保障整个视频的流程会对整体体验有所提高。

编码器的复杂度可以通过 preset 来划分，不同的 preset 表示了不同的复杂度（对于 preset 的详细说明可参考 Nvidia 官网的资料），我们实测数据如下：

通过测试数据，我们发现 preset p1 和 p4 是两个性能临界，可以通过动态调整 preset 来提升编码复杂度，进而提升编码的画质（preset 的动态设置耗时不大，不会导致画面卡顿）。因此，我们将当前默认设置的 preset 调整为 p4，如果 p4 性能不能保障实时性，则回退到 p1。

2.3 解码的实现与优化

2.3.1 按 FoV 视场角下发视频

一些直播场景中已经开始使用 FoV 方案，但目前还没有 RTC 厂商来按视场角下发视频内容。

为什么不用 SVC 或 Simulcast 做视频下发？SVC 和 Simulcast 只能针对视频全画幅进行接收和解码，会引起带宽的增加或画质的损失。而火山引擎的 FoV 方案中，一路高清视频流按视角场异步下发和渲染，一路低清视频流全量下发，既可以节省带宽，也没有降低画质，还能避免因视角快速切换、高清视频来不及传输导致看不到画面。

2.3.2 投影方式的选择

球面和平面之间图像的映射问题，是一个从古时候起就一直困扰着地图测绘员的问题。今天，随着 VR 全景视频的发展，又将这一问题摆在了开发者面前。VR 全景视频需要传输，涉及到带宽占用和画质损伤的问题， 不同的投影方式会对画质及码率造成较大的影响。

引用自：全景视频投影方式对比 | Hope

我们使用了 EAC 的投影方式，相对于简单直观的 ERP 投影，EAC 投影比 ERP 投影节省了 25% 的面积，接收端降低约 15% 的数据接收，且更利于视频编码器做画质优化。

下面两组照片中，上图为 ERP 投影，像素为 7680x3840 ；下图为 EAC 投影，像素仅为 5760x3840。

2.3.3 从姿态信息计算视场角范围内 tile

定义正前方是零点向量，视场角边界是 tile 向量，零点向量和 tile 向量夹角小于 X° 范围内的 tile，都是视场角范围内的 tile。

如上图所示，粉色+黄色是全景的视频，划分成了 72 个 640x640 的区域，黄色区域是根据向量夹角计算出来的视场角范围内的 tile，然后接收端向 RTC 边缘媒体服务器请求，下发这些 tile。

2.3.4 合成

接收端按照 HEVC tile 标准，将所有 tile 按照图像的位置合并成一路原始大小的编码视频；同时，将 2K 低清流进行放大，并将高清 FoV 流在渲染前贴到对应的坐标位置。

放大后效果如上图，橙色部分为低清流，放大成为 8K；绿色部分为高清 FoV 流，为原始的 8K。

如果头动较慢，VR 头显中看到的都是高清的视野范围，所以不会对实际体验造成影响；如果产生快速的头动，那就无法避免在视野范围内看到一些低清的图像，此时播放端会根据头动范围重新请求高清 FoV 码流，此时会有短暂的时间看到低清图像，等到高清 FoV 范围的码流下发下来之后，画面就会恢复高清 8K 效果。

2.4 头动延时优化

2.4.1 头动延时

头动延时 = 最后一公里网络rtt + GOP/2 + jitter_buffer + 解码 + 上屏

2.4.2 视场角预测

下图说明了“视场角预测”的流程，即，用户当前 FoV -> 转头 -> 控制信令（携带预测结果） -> RTC 边缘媒体服务器 -> 下发新的 tile -> 更新 FoV 内容。

行业中已经有一些比较成熟的视角预测方案，当用户头部旋转时，可以根据旋转加速度进行预测未来旋转的角度位置，甚至可以根据用户的动作预测转动角度和方向，再根据预测进行拉取相应数据，可以达到很好的预判以及降低延时效果。

首先，这里仅采用本用户自身的历史数据来预测其未来视角，其次，为了适应用户的较快速头动模式，选择了速度较快的 ML 算法来预测。

3. 方案落地体验

上述方案在实际落地中的表现如下：

在 GOP=15 的情况下，8K 高清头动延时在 100ms，端到端延时为 130ms+，下行码率约 20Mbps，数据表现理想。

实际体验效果如下：

注：
1、为了表现高清 FoV 视频和低清背景视频的区别，我们给低清视频添加了绿色滤镜
2、视频来源：https://www.youtube.com/watch...

当头动速度较慢时，视场角范围内只能看到高清的图，看不到绿色的低清图。

当头动速到较快时，才会偶尔有绿色的低清 tile 块进入到视场角范围内（想象一下，如果没有低清视频流兜底，用户看到的将是缺失的画面）。 视频请跳转此链接

4. 总结与展望

4.1 总结

火山引擎 RTC FoV 方案通过如下的技术优化，实现了 8K@120fps 全景视频的实时传输：

1. 对 8k 高清视频进行分片，支持多 GPU 分布式并行编码；
2. 按需下发和解码视场角范围的视频分片，极大程度降低了下行带宽要求，并且实现基于 4K 解码器能力达到全景 8K 的画质体验；
3. 通过视角预测，极大地降低了高清视频的头动延时（MTP）< 100ms；

4.2 后续优化

当前方案仍有不少优化空间。

比如当前在解码端将 2K 低清背景流到放大到 8K 高清流的采用的是传统的缩放算法，会对画质造成一定的损失，使用超分算法会极大的提高低清背景的优化体验。

AI 头动预测，利用多个用户的头动数据学习得到具有群体共性的头动模式，从而能在未来一段时间内加快内容预取，进行预测。

另外，目前 Nvidia 和高通主流芯片平台均已支持 HDR 10 的编码和解码 (High-Dynamic Range，是一种提高影像亮度和对比度的处理技术，它可以将每个暗部的细节变亮，暗的地方更暗，丰富更多细节色彩) ，我们后续也将引入 HDR 10 技术来进一步提升画质体验，让用户更接近真实环境中的视觉感受。