共计 4861 个字符，预计需要花费 13 分钟才能阅读完成。
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 投影，像素为 7680×3840；下图为 EAC 投影，像素仅为 5760×3840。
2.3.3 从姿势信息计算视场角范畴内 tile
定义正前方是零点向量，视场角边界是 tile 向量，零点向量和 tile 向量夹角小于 X° 范畴内的 tile，都是视场角范畴内的 tile。
如上图所示，粉色 + 黄色是全景的视频，划分成了 72 个 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、视频起源：https://www.youtube.com/watch…
当头动速度较慢时，视场角范畴内只能看到高清的图，看不到绿色的低清图。
当头动速到较快时，才会偶然有绿色的低清 tile 块进入到视场角范畴内（设想一下，如果没有低清视频流兜底，用户看到的将是缺失的画面）。视频请跳转此链接
4. 总结与瞻望
4.1 总结
火山引擎 RTC FoV 计划通过如下的技术优化，实现了 8K@120fps 全景视频的实时传输：
- 对 8k 高清视频进行分片，反对多 GPU 分布式并行编码；
- 按需下发和解码视场角范畴的视频分片，极大水平升高了上行带宽要求，并且实现基于 4K 解码器能力达到全景 8K 的画质体验；
- 通过视角预测，极大地升高了高清视频的头动延时（MTP）< 100ms；
4.2 后续优化
以后计划仍有不少优化空间。
比方以后在解码端将 2K 低清背景流到放大到 8K 高清流的采纳的是传统的缩放算法，会对画质造成肯定的损失，应用超分算法会极大的进步低清背景的优化体验。
AI 头动预测，利用多个用户的头动数据学习失去具备群体共性的头动模式，从而能在将来一段时间内放慢内容预取，进行预测。
另外，目前 Nvidia 和高通支流芯片平台均已反对 HDR 10 的编码和解码 (High-Dynamic Range，是一种进步影像亮度和对比度的解决技术，它能够将每个暗部的细节变亮，暗的中央更暗，丰盛更多细节色调)，咱们后续也将引入 HDR 10 技术来进一步晋升画质体验，让用户更靠近实在环境中的视觉感触。
