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 硬件的编码能力，剖析发现，当视频源到达 8K 分辨率时，单张 Nvidia Tesla 最高只能支撑到 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 运用自研编码器独自进行编码；一起编码一个 2K 的全景图，它能够在接纳端做“兜底”，又不会引进较大的码率添加导致解码端功能跟不上；然后，在媒体服务器侧，上行经过一个 ssrc 一起接纳高清 tile 流和低清布景流，其中下行高清 tile 流依照用户视场角过滤转发，下行低清布景流不过滤直接悉数转发；最后，接纳端依照 HEVC tile 标准，将一切 tile 依照图画的方位合并成一路原始巨细的编码视频，解码，上屏。

下文详细介绍火山引擎 RTC FoV 计划的完成与优化。

2.2 编码的完成与优化

2.2.1 多 GPU 分布式编码

上文提到，由于单张 Nvidia Tesla 不具备 8K@120fps 的编码能力，所以需求经过多 GPU 并行编码来完成。火山引擎 RTC 在编码侧选用多 Nvidia Tesla 显卡并行，将 8K 视频切割成若干个 tile，运用若干个编码器进行编码，然后经过 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 全景视频需求传输，涉及到带宽占用和画质损害的问题， 不同的投影方法会对画质及码率形成较大的影响。

引用自：leohope.com/%E8%A7%A3%E…

咱们运用了 EAC 的投影方法，相关于简单直观的 ERP 投影，EAC 投影比 ERP 投影节省了 25% 的面积，接纳端下降约 15% 的数据接纳，且更利于视频编码器做画质优化。

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

2.3.3 从姿势信息核算视场角规模内 tile

界说正前方是零点向量，视场角鸿沟是 tile 向量，零点向量和 tile 向量夹角小于 X 规模内的 tile，都是视场角规模内的 tile。

如上图所示，粉色+黄色是全景的视频，区分红了若干个 640×640 的区域，黄色区域是依据向量夹角核算出来的视场角规模内的 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、视频来源：www.youtube.com/watch?v=L_t…

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

当头动速到较快时，才会偶然有绿色的低清 tile 块进入到视场角规模内（想象一下，假如没有低清视频流兜底，用户看到的将是缺失的画面）。 [视频请跳转此链接](根据 RTC 的全景 8K@120fps FoV 实践)

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 技能来进一步进步画质体会，让用户更挨近真实环境中的视觉感触。