动态分辨率编码

来源
：MHV 2022 day 2

主讲人
：Xavier Ducloux

内容整理
：尹文沛

传统动态分辨率选择需要太多的处理能力，不能实时使用，难以应用于直播。本文提出的方法基于机器学习机制，该机制学习如何在监督学习环境中选择要编码的最佳分辨率。在运行时，使用已经存在的预处理阶段，实时编码器可以决定编码的最佳分辨率，而不会增加任何处理复杂性或延迟。

摘要
背景介绍
实时视频传输的动态分辨率选择
动态分辨率编码应用和用例

OTT 流
广播分发

视频质量评估结果

HD AVC
UHD HEVC

标准化布局

DASH OTT 传输
HLS 传输

更多讨论

摘要

动态分辨率选择是 Netflix 部署的一项技术，其按场景编码机制应用于 VOD 资产。该技术基于对所有编码分辨率的后验分析，以确定给定场景的最佳分辨率，根据使用的质量和带宽，基于 VMAF 分析。它不能应用于实时内容，因为它需要太多的处理能力并且不能实时使用。

本文提出的方法基于机器学习 (ML) 机制，该机制学习如何在监督学习环境中选择要编码的最佳分辨率。在运行时，使用已经存在的预处理阶段，实时编码器可以决定编码的最佳分辨率，而不会增加任何处理复杂性或延迟。与经典的固定阶梯方法相比，这会导致更高的体验质量 (QoE) 或更低的比特率，以及更低的 CPU 占用空间。本文将介绍跨不同网络传输实时高清或 4K 内容所获得的结果，包括经典 TS (DVB)、本地 IP (ATSC 3.0) 和 ABR (DASH/HLS)。此外，论文还将报告测试设备的互操作性结果。

背景介绍

视频压缩专家都知道，当带宽减少时，保持质量和限制可见压缩伪影的一个很好的权衡是降低分辨率。当然，给定比特率的最佳分辨率很大程度上取决于视频内容。

2015 年 12 月，Netflix 在其博客“Per-Title Encoding Optimization”中推广了可变分辨率编码的概念。当时，为每个 VOD 内容选择了最佳分辨率。

在接下来的几年里，Netflix 改进了这一概念，将动态分辨率选择应用于每个场景。由于 Netflix 的市场是 VOD，因此可以离线进行此选择，但基于观看的选择会非常耗时。为了缓解这个问题，Netflix 开发了一个名为 VMAF 的客观视频质量 (VQ) 指标，以帮助实现分辨率选择过程的自动化。

Harmonic 在实时内容上实施了类似的概念，具有非常动态的选择，适用于持续时间为几秒的每个视频交付片段。

接下来：第一部分解释了动态分辨率选择如何在实时工作流程中工作。第二部分介绍了已确定的 DRE 部署用例。接下来的两节将介绍质量和互操作性评估的结果。最后一段以对结果和展望的讨论结束。

实时视频传输的动态分辨率选择

Netflix 的每场景编码优化利用了多种编码以及基于真实 VQ 测量的分辨率选择，如图 2-1 所示。这种解决方案的计算量太大，并且会导致实时流媒体延迟过多。

实时编码系统的特点是在编码和交付阶段之前对图像分析有限。因此，对可能具有可变持续时间的全局场景做出决定是不现实的。相反，一个非常动态的决策方案是通过为有限持续时间（通常为 2 到 3 秒）的每个视频片段应用的分辨率选择构建的。视频预分析阶段的特征已用于在监督学习环境中离线训练基于 ML 的预测模型，如下图 2 所示。每个视频片段都以给定的目标比特率（恒定或上限比特率）以各种分辨率编码。

在运行时，使用已经存在的预分析阶段和相同的目标比特率，实时编码器可以通过使用离线创建的预测模型来决定对当前片段的图片进行编码的最佳分辨率。最佳分辨率是提供最佳视觉质量的分辨率。

由于预测模型是由已经计算的特征驱动的决策树算法，因此处理复杂度的增加非常有限。与往常一样，额外的延迟是与质量的权衡。对整个分段持续时间进行预分析可以更好地解决分段最后部分发生的变化，但会增加显著的延迟。使用经典的前瞻不会增加延迟，但会在段的第一部分做出决定，并且可能会对一个段延迟的变化做出反应。限制影响的一种方法是使用与场景变化对齐的片段。

动态分辨率编码应用和用例

OTT 流

想到的第一个动态分辨率编码 (DRE) 用例是使用最广泛使用的 DASH 和 HLS 交付格式的 OTT 流。在这种类型的交付中，为视频编码表示构建了具有各种比特率的配置文件阶梯，以便客户端可以通过请求适当的表示来适应带宽波动。梯形图是使用每个比特率的最佳分辨率的平均统计数据构建的，并且没有考虑到各个视频内容的特征。使用 DRE 方案，分辨率将在所有或选定的比特率配置文件中变化。

使用 DRE 方法可能会导致：

在相同的 QoE 下，通过使用较低的常数 (CBR) 或上限（具有内容感知编码的 cVBR）比特率来节省带宽，这要归功于当内容对于最高分辨率而言太具有挑战性时较低的分辨率；
通过在最低比特率配置文件（更高锐度）的静态场景上使用更高分辨率或在最高比特率配置文件（更少压缩伪影）的时间复杂场景上使用较低分辨率，获得更好的 QoE；
通过减少阶梯的数量来节省存储空间；
通过降低最高配置文件上最复杂场景的分辨率并减少配置文件数量来节省 CPU。

DRE 的实现取决于 OTT 交付格式。使用基于 DASH 的 OTT 流，清单可以指示每个比特率配置文件的最大分辨率，而不是每个片段将使用的实际分辨率。为确保 OTT 播放器中的解码器能够正确处理此类流，视频表示将具有带内分辨率信号，在 MP4 容器中使用用于 AVC 的 avc3 MP4、用于 HEVC 的 hev1 MP4 和用于 VVC 的 vvc1 MP4。这意味着播放器/解码器将从编码流的高级语法中获得分辨率。

当以低于清单中为所请求配置文件指示的分辨率提供服务时，播放器/解码器将对其进行解码并升级到清单中设置的标称分辨率。

对于基于 HLS 的 OTT 流，每个分辨率创建一个初始化文件。每次分辨率更改时，都会在播放列表中添加一个引用正确初始化文件的 #EXT-X-MAP 标签。这种情况是可能的，因为 HLS 意味着，根据实时内容的构建，每个新片段都会更新一个动态播放列表在原点上提供。视频表示可以具有经典的带外信号，或分辨率的带内信号。在每个片段中使用 avc1 MP4 用于 AVC，hvc1 MP4 用于 HEVC，vvc1 MP4 用于 VVC，如 DASH 交付所述。后一个选项允许为 DASH 和 HLS 交付使用公共段。

广播分发

DRE 也可以应用于广播传输，在时间复杂的场景中使用较低的分辨率可以节省带宽和 CPU。使编码方案适应广播传输的视频内容特性的传统方式是在多个视频通道之间共享转发器的带宽，并根据内容特性以非常动态的方式为每个通道分配比特率，使用统计多路复用引擎。

对于 ATSC 3.0 指定的基于分段的 IP 广播，以及使用 ROUTE 协议对 DASH 分段进行序列化，比特率的动态分配不再存在，并且通道的带宽可能会被共享。因此，DRE 对在这种受限环境中保持 QoE 以及降低转发器成本具有重要意义。

对于这个用例，对于 DASH OTT 交付，在路由封装器中推送的段应该具有带内信令，以确保 ATSC 3.0 接收器上的解码引擎能够正确适应传输流的移动分辨率。

即使对于使用统计复用的传统基于 TS 的广播，DRE 也可以通过平滑峰值比特率请求来发挥价值，因为在最复杂的场景中使用较低的分辨率会导致相同 QoE 的比特率需求较低。它将为所有信道同时复杂的拥塞情况提供更好的 QoE。当转发器中的频道数量较少时，这种情况可能会发生得更多，这在广播 UHD 频道时更为频繁。因此，DRE 可以有利于 UHD 频道的发展。

视频质量评估结果

在 2019 年的 NAB 和 IBC 展会上，Harmonic 通过在低比特率的静态场景上使用更高的分辨率展示了更好的 QoE。

在本文中，我们将视频质量评估的重点放在使用较低分辨率来节省带宽上。评估有两个目标：第一个目标是确认场景内没有感知分辨率变化，第二个目标是测量带宽节省。主观评估由三位专家进行。

我们考虑了具有不同编解码器和最大分辨率的两个用例：

1080p59.94 AVC 传输 4Mbps，具有 1080p、720p 和 540p 分辨率
4K 59.94 HEVC 传输 6Mbps，具有 2160p、1440p、1080p 和 720p 分辨率

HD AVC

在此用例中，内容以 4Mbps 的恒定且具有挑战性的比特率交付，并且可以使用以下三种分辨率之一：1920x1080p、1280x720p 或 960x540p，59.94 fps，每个分段设置为 2 秒。我们拍摄了由 Harmonic 制作的五个 4K HDR PQ BT.2020 @ 59.94fps 内容和一个 8K HDR PQ BT.2020 @ 59.94 fps 内容，并使用 Lanczos 滤镜将它们转换为较低分辨率，并使用专有 HDR-to 将它们转换为 SDR BT.709 -SDR 转换器。内容的持续时间从 20 秒到一分钟不等。我们使用 Harmonic 的 AI 分辨率选择和传统的编码引擎来生成流。

图 3 显示了分辨率选择的份额：

我们可以观察到在这个比特率下有多种分辨率选择。当视频特性发生变化时（相机平移的典型情况），分辨率可能会在场景中发生变化。每个单独的 DRE 流的主观评估表明，没有感知到场景内的分辨率变化。我们构建了离线分屏，比较以恒定 1920x1080p 分辨率编码的流与高达 1920x1080p 的 DRE 流，使用 FFMPEG 裁剪和以高比特率重新编码以保持初始质量，如图 4 所示。DRE 增益为在复杂场景以及 Riverplate 和 RSL 序列的草纹理上感知。没有观察到错误的分辨率选择（没有明显的细节或锐度损失）。

为了确定可以节省多少 DRE 带宽，我们制作了相同的分屏，比较了 @ 4 Mb/s DRE 流与恒定分辨率 1080p 流 @ 5Mbps（节省 20%）和 6 Mbps（节省 33%）。主观评估表明，Riverplate 可节省 20% 的比特率，RSL 可节省近 20%，Regatta 可节省近 33%.

对于每个 DRE 流，表 1 显示了平均 VMAF 分数、与 1080p 编码相比 DRE 在片段上的最佳 VMAF 增益以及片段的相关 VMAF 分数。

VMAF 分数评估表明，使用较低的分辨率（在 Regatta 上）可以达到 +13 分，并且在 VMAF 分数远低于序列上的平均 VMAF 分数的片段上获得了最佳增益，这证明了DRE 对于在最复杂的场景中保持质量非常重要。

UHD HEVC

在此用例中，内容以 6 Mbps 的恒定且具有挑战性的比特率交付，并且可以使用以下四种分辨率之一：3840x2160p、2560x1440p、1920x1080p 或 1280x720p，59.94 fps，每个分段设置为 2 秒。我们采用与前一个用例相同的五个 4K HDR PQ BT.2020 @ 59.94fps 内容和一个 8K HDR PQ BT.2020 @ 59.94 fps 内容。使用 Lanczos 过滤器将它们转换为较低的分辨率，并使用专有的 HDR 到 SDR 转换器将它们转换为 SDR BT.709。

我们使用 Harmonic 的 AI 分辨率选择和传统的编码引擎来生成流。

下面的图 5 显示了分辨率选择的份额：

我们可以再次观察到，在这个比特率下，有多种分辨率选择。当视频特性发生变化时（相机平移的典型情况），分辨率可能会在场景中发生变化。每个单独的 DRE 流的主观评估表明，没有感知到场景内的分辨率变化。我们构建了离线分屏，比较以恒定 4K 分辨率编码的流与高达 4K 的 DRE 流，使用 FFMPEG 裁剪和以高比特率重新编码以保持初始质量，如图 6 所示。Riverplate 和 RSL 序列的复杂场景和草地纹理。没有观察到错误的分辨率选择（没有明显的细节或锐度损失）。

为了确定可以节省多少 DRE 带宽，我们制作了相同的分屏，比较了 @ 6 Mbps DRE 流与恒定的 4K 流 @ 7.5Mbps（节省 20%）和 9 Mbps（节省 33%）。主观评估表明，Venice 和 Regatta 可节省 20% 的比特率，Bike、Landspeed、RSL、RiverPlate 可节省 33%。

对于每个 DRE 流，表 2 显示了平均 VMAF 分数、与 4K 编码相比 DRE 在片段上的最佳 VMAF 增益以及片段的相关 VMAF 分数。

VMAF 分数评估表明，使用较低的分辨率（在 Regatta 和 Venice）可以达到 +6.5 分，并且在 VMAF 分数远低于序列上的平均 VMAF 分数的片段上获得了最佳增益，这证明 DRE 对于在最复杂的场景中保持质量很重要。

除了带宽节省或 QoE 改进之外，DRE 还带来了不可忽略的 CPU 节省，因为 CPU 周期随着编码分辨率的降低而减少。在 HEVC 测试集上，与以恒定 4K 分辨率进行编码相比，可以节省 20% 的 CPU。

标准化布局

DASH OTT 传输

在每个表示中，两个参数高度和宽度通常表示此配置文件的内容的分辨率。播放器使用它来检查它是否可以处理该内容的处理能力。如果必须在更大范围内使用 DRE，可能会在 MPEG DASH 标准或 DASH-IF IOP 中添加一些内容，以更具体地说明这些高度和宽度信息对应于最大可能分辨率。

HLS 传输

HLS 规范通过说“该值是十进制分辨率，描述了在变体中显示所有视频的最佳像素分辨率”来描述清单中的分辨率元素。因此，这不是对实际段分辨率的描述，无需更改 HLS 规范中的任何内容。