8K内容分发挑战

来源：SMPTE Session：Solving the 8K distribution Challenge 主讲人：Bill Mandel、Stephan Wenger、Mickael Raulet 内容整理：胡经川这篇文章中 3 位主讲人分别从电视制造商角度、终端用户角度以及编码器从业者角度来分析讨论8K内容的分发问题

从电视制造商角度看8K分发问题
从终端用户角度看8K分发问题
从编码器从业者角度看8K分发问题

1从电视制造商角度看8K分发问题

首先来自三星的 Bill Mandel 从电视制造商的角度来看 8K 分发问题。他先从 HDR 谈起，现在有多种编解码器和系统可以支持 8K, 而 HDR 服务也往往随着 8K 一起被推出，三星则在智慧电视Tizen操作系统上为开发者构建了 8K 服务开发工具，除了三星的一些 8K 服务提供商为 Tizen 开发的一些应用程序，开发者们可以基于 C# 或 javascript 来进行开发。三星还开发了一个 HDR10 的sdk，在直播或点播场景中支持高达 8K/60FPS，目前该SDK的 4K 商业版本可从 PIXTREE 和 Android Q 手机上获得

下一个 8K 发行版是大家所希望的低延时直播场景上的应用。现在智能电视使用标准技术,包括 CMAF、WebRTC、DASH-LL 以及 HLS-LL 等针对低延迟进行了很好的优化，这对于云游戏或其他实时视频流也有许多好处。你可以使用 CMAF 将延迟降低到低于 1 秒，对于 WebRTC 流，延迟甚至可以降低到 0.2 秒，这与传统类型的直播系统 30 到 40 秒的延迟相比要好得多。

至于 8K 的带宽的问题。最近 Mediacom 演示了他们的 10G 带宽技术，该技术将为家庭用户带来非常高的带宽，三星基于此实现了一个Vecima的CDN到三星 QLED 智能 8K 套装的 8K/60FPS 流，证明了在有线电视设备上你可以通过互联网为家庭提供 8k 流媒体服务支持。

AV1 是一种可用的编解码器，自今年 3 月以来，Youtube 已经在支持 HDR10 的 8K 内容上使用AV1来进行与 8K 电视的流式传输，但码率可能达到 50 Mb/s, 虽然不是每个家庭都有这么高的带宽，但肯定有些人有，这也表明了这种服务的可行性。

而视频编解码器问题，主要有两部分，一方面是提供比现有视频编码标准显著改进的压缩能力，另一方面是可以通过有效的编码工具选择和及时的许可条款来提供一个在许可方面十分友好的标准。这一直是一个持续存在的问题，甚至可以追溯到VC1 和 AVC，行业很难制定许可条款。

图1：EVC标准

EVC 旨在通过提供两个配置文件来解决这个问题，其中Baseline profile是只包含 20 多年前制定的工具，或者只有一个 Type1 声明，以便它可以用于一个已知的许可费用甚至免版税。这个配置文件旨在相同的质量下比 H.264/AVC 节省 50% 的带宽。而 EVC 的Main profile 使用了少量附加工具，并要收取相应版税，但它在许可方面的复杂性要低得多，并且每个工具都会有显著的增益，而且它启用了编码工具选择，因此如果你想使用主配置文件，但出于某种许可原因，你不想使用某个工具，可以在使用所有工具时将其关闭。它在相同的视频质量下比 HEVC 节省 50% 的比特率。

最后一个是机器学习，机器学习将大规模进入编解码器领域，三星也开发的一个称为 ScaleNet 的神经网络，可提供两倍的压缩性能，并且可与标准视频编解码器一起使用，也与传统电视兼容。首先高分辨率图像会经过下采样神经网络，然后经过编码传输，在电视端有一个较小的网络只能进行两倍上采样，而剩下的缩放将使用传统技术完成。

图2：三星Scalenet

2从终端用户角度看8K分发问题

第二个主题的分享者是来自腾讯的 Stephan Wenger。他会介绍向终端用户分发 8K 视频的一些标准，这些标准主要分为物理层技术、低层协议和高层协议以及编解码器，并且他会重点介绍编解码器方面。

图3：8K分发相关标准

要从终端用户角度看问题，首先得知道他们关心什么，需要什么。从终端用户角度来看，他们只关心技术是否能正常工作，而且最好不用下载应用程序，不需要插件，不需要复杂的配置，他们的理想流程是打开他们的设备，然后会导航到他们想要看到的内容并按播放按钮进行播放，这就够了。他们想要录制，但他们不关心它是如何录制的，除了可能质量与存储上有需求，他们想要上传它并且他们希望能够在他们的所有设备上看到它。所以即插即用和从移动设备到流媒体电视的所有平台上的内容可用性都很重要，他们关心视频质量，但不像作为视频压缩从业人员想要的那样，诸如 PSNR 是 42db 还是 48db，他们不在乎，只要他们从今天的专业电视中看到的质量足够好，他们就满足了。他们通常也不关心标准委员会的个人执行标准，他们只关心最终的价格。

至于今天在 8K 生态系统中部署的编解码器主要是 HEVC 和 AV1，相信大家都非常熟悉。HEVC 是 2013 代的标准， AV1 则更晚一点，但他们在同一个赛道。许可方面，HEVC大部分解决了之前留下来的问题，而AV1则完全开源；性能方面，EVC相较于 AV1 表现更好一些，它可以实现 4k 实时的软件编码和解码，而AV1则在实时编码方面还存在问题，但 HEVC 部署的配置文件可扩展性不如 AV1。

图4：HEVC vs AV1

最新的标准当然还有 VVC，它的芯片产品已经有发布，解码器的复杂度大约是 HEVC 的两倍，而编码器的复杂度相当高，但高端 PC 还是可以进行 4K 内容的编码；对于高分辨率的内容来说编码效率增益大约是50%，这意味着当你有一个 4K 的 HEVC 码流并且你想转码到 8K 的 VVC 码流时，比特率只需增加两倍。预计 VVC 将最早于 2022 年得到广泛部署。至于许可情况，目前还存在许多未知，很多人正在为此努力工作，但可以肯定的是，不会有HEVC生命周期中的同一时间那么严峻。

图5：VVC

然后是MPEG-5 的 EVC ，它的出现是因为 MPEG 中的某些人认为当将标准的贡献者基础限制在少数几家公司时，许可情况应该是更方便一些，因为只有少数公司需要同意将他们的 IP 许可用于该技术，但这一层理论无论在短期内还是从长远来看仍有待观察。EVC技术特性与 VVC 大致相当，和前文提到的一样，EVC包括两个配置文件，旨在通过仅依赖旧技术或承诺在免版税条款下获得许可的技术来免版税，但如果要用在 8K 内容上，只能考虑它的Main profil，但它是否足以被市场采用还有待观察。

图6：EVC

还有一个叫做 LCEVC 它很奇特，它指定的不是完整的视频编解码器，而是仅指定一个增强层，该增强层可以以非常低的复杂度进行解码，以至于即使对于很高分辨率的内容，它也可以在芯片组和软件的嵌入式处理器实时解码，但它是否适用于 8K 分辨率，Stephan 表示持怀疑态度。而且编码器的复杂度可能相当高，目前有人在谈论基于 AI 的编码，对于专业用途，它可能是一个可行的选择，它作为固有的和可扩展的编码方式，可能有助于 4K 到 8K 升级路上的挑战。

图7：LCEVC

总的来说，从终端用户角度来看，最终用户并不真正关心编解码器工作，他们只关心对他们直接作用的技术。

HEVC 和 AV1 对于 8K 应用已经足够好了他们都已经广泛部署，有相对较低的实施成本和合理的性能，这就是为什么他们几乎存在于今天所有的 8K 设备中，在可能在未来几年都不会有太大改变。而一旦 VVC 部署达到临界质量，则会对 8K 内容分发给用户做出巨大贡献。EVC 虽然在压缩性能上不如 VVC，但它在许可方面很有优势。现在宣布的许多芯片组都支持所有以上四个或至少三个带有 EVC 的编解码器，而且你可以通过固件更改启用和禁用相应编解码器，所以最终部署问题还是会落到许可问题上。Stephan 认为 VVC、EVC、LCEVC都不会在 2022 年之前得到广泛应用。

图8：总结

3从编码器从业者角度看8K分发问题

最后一个主题的分享者是来自 Ateme 的 Mickael Raulet，他首先介绍了 4K/8K 的现状。现在的 4K 内容共有约 148 个 UHD 通道已经部署，其中直播占服务形式的 75% ，OTT 分发则约为25%，但是 HEVC 许可存在诸多问题，导致部署十分缓慢。而 8K 内容的许多测试性服务像 NHK、SES 等公司也已经发布，东京奥运会也有 8K 的广播有应该在 8k 中的奥运会，在 2020 年，共售出约两百万台 8K 电视，其中 75% 在中国，但用 HEVC 进行编码的 8K 内容带宽高于 50Mb/s，这是相当高的，再加上 HEVC 本身的许可问题，因此 Mickael 认为 HEVC 并不合适用于 8K 内容的编解码器，继续新的编解码器用于 8K 内容的分发。

图9：4K/8K现状

8K 广播场景主要有使用 DVB-S2X 的卫星广播、使用 DVB-T2/ATSC-3.0 的地面广播以及使用 5G 的手机服务。而这三类里只有卫星广播的 80Mbps 带宽能够满足 HEVC 的 8K 内容，剩下的两者都只能提供 30~35Mbps 的带宽，所以 HEVC 还是无法胜任这些场景。

图10：8K 广播场景

所以如果我们想在些特定场景中获得 8K 服务，那么编解码器的性能至少比现在的 HEVC 所能做的好 30%，而且编解码器还应支持 MPEG-TS 和 Dash 来进行分发。因此有两个编解码器似乎符合条件：VVC 和 EVC，他们都能获得比 HEVC 高 30% 的性能，而且支持 MPEG-TS 以及 Dash 分发，所以认为这两个中的一个可以满足我们正在寻找的下一代 8K 部署的编解码器要求。