声网张倚豪：RTE场景下高清能力迭代升级的若干关键问题

大家好，我是声网的视频算法工程师张倚豪。

今天我要讲的内容，主要是在 RTE 场景下高清能力迭代升级中，可能遇到的一些关键问题以及声网的一些解决思路的分享。整个 PPT 分三个部分：

• 从准高清到高清的升级

• RTE 场景的关键点

• 声网的 H.265 方案简析

在学术界，对压缩效率的追求是视频编解码技术永恒的主题。每一代的编码标准，在制定初期的提案阶段，目标都是在相同的客观画质下，比前代标准节省约 50% 的码率。

从 1984 年第一代 H.120 开始，后续基本在 8-10 年的周期进行更新迭代。到目前的 H.265 也达到了所有编码工具打开的前提下同画质的码率比 H.264 节省 40%~50% 的目标。

但是值得注意的是，标准升级带来的优化是仅仅从压缩率和适当的复杂度性能代价考虑的，并不针对具体场景。比如，编码标准并不是专门针对实时直播或者是广播类的需求设计的，其应用场景包括了更多的视频编码需求，如点播类的、VOD 等。简而言之，并不是所有工具都适用于低延时的场景。

从工业界的视角来看，随着视频分辨率增加，老一代标准将面临码率利用效率低下的问题。升级到新标准是不可避免的。但工业界的关注点和学术界关注的压缩效率不同。工业界关注的更多是各个关键指标之间的权衡。

首先是清晰度和码率，这两项结合起来可以认为就是所谓的编码压缩效率。但在具体的应用中，每个客户的需求存在区别，所以还是需要单独拆解分析。工业界关注的指标还包含复杂度、流畅度、适配率等。应当基于这些指标来综合考虑，分析编码标准升级迭代是否能满足对应的需求，并且评估其性价比。

另外还要考虑的因素，正如前文所述：H.265 在测试模型当中的压缩率非常高，但在实时应用中不可避免的会裁减掉一些非实时的编码工具，在这个前提下，总的压缩率收益就需要另外进行测试与统计了。

我们先从 RTE 场景来进行一些简单的分析。在 RTE 场景下，从 H.264 升级到 H.265，需要关注的点是什么呢？大致分为三类：

• 代价

• 收益

• 适用范围

首先从代价来看，需要关注在端上的复杂度增加了多少，量化的数据是怎么样的。收益则比较好量化，可以看清晰度指标提升了多少/码率节省了多少，码率节省后流畅度提升了多少等等。

适用范围指的是升级后客户真正能收益的比例。这点和 Video Profile 相关，和客户使用了哪些功能、哪些系统平台，所在地区以及所在地区的设备分布相关。

我们围绕声网的 H.265 方案，进行针对上述关键点的简单分析。

1、代价

首先我们评估了 H.265 的复杂度。其中，在硬编硬解部分我们评估了编解码的时间和整体功耗，以及不同分辨率下的复杂度；在软编软解部分，我们进行了基准测试，也集成到 SDK 中进行了端侧编解码复杂度的 profiling。

如上图所示，硬编硬解部分的单帧编解码时间、整体功耗与 H.264 较为接近，也符合分辨率越高，复杂度 overhead 越小的趋势。

软编软解部分，软编复杂度约为 H.264 的 130%~150%，软解复杂度约为 H.264 的100%~120%。如上图所示，在相对比较低端的手机 dec_720p 场景中，H.265 的软解已经略快于 H.264，这对于高清方案的应用是比较有利的，因为我们需要解决在性能不是很优秀的机器上使用软解的方案。

总的来看，我们可以通过软硬结合的方案，来提高整体的覆盖率。

2、收益

根据我们前面分析的结论，当复杂度相对较小的情况下，我们还需要关注清晰度以及码率节省方面的收益。基于声网官方文档推荐的 video profie 来看，我们分别截取了 360P、540P、720P 三类不同的 video profile 进行测试。测试结果如上图所示。

根据结果可知，PSNR 收益基本在 0.8-1.5 dB，以 base 为 36dB 来看这是颇为可观的。VMAF 的收益则在 3-4 分左右。

除了这两个指标，我们还通过一些自研的 VQA 之类的指标进行了相关数据的佐证，证实在固定源测试、同码率的前提下，H.265 的效果明显优于 H.264。

与此同时，我们也做了一些主观的对比，得出了相同的结论。

上图是通过一个滑动视频的例子来观察区别。左侧是 H.264 右侧是 H.265，可以看到从左向右滑动画面会变模糊，从右往左滑动，画面变得更加清晰。

客观而言，在设定的码率条件下，这两种 codec 都没有编的非常清晰，但在 H.264 下出现了较多的块效应，而在 H.265 下则比较好的保持了人物的纹理边沿，块效应也更少。而该种带宽受限前提条件是RTC场景下经常遇到的情况。

在相同画质下的码率收益是比较好测试的。我们通过 CTC 标准测试就可以拿到比较客观的数据。

我们分别做了软编和硬编的收益 profile。

根据 CTC 测试结果，在 RTE 这种实时性场景中，软编的 BD-rate 平均收益约为 35%。结合我们前文提到的复杂度增加 30%-50%，可以得出交换比基本达到了 1:1，还是比较不错的。硬编的收益要略低于软编，但也保持在 20%-25% 之间。

另外，从测试数据可以看到，分辨率高的序列压缩率的收益更大，能节省更多的码率。这对于我们去推广 1080P、2K、4K 等 profile 中应用 H.265 是非常有利的。我们的官网中也给出了相关数据，在 2K 和 4K 的 profile 中，码率能达到 50% 或以上。如上图所示，右侧即为 CTC 测试的结果。

但是不是所有线上的 profile，都适用 H.265 呢？从 codec 的原理来分析是这样的。因为 codec 不关注用什么样的分辨率、码率、帧率去编码。然而，从实际应用的过程中可以发现，H.265 和 H.264 在适用分辨率方面存在差异。

由于 H.265 的 transform 是(可以)在更大尺寸的编码单元上进行的，所以在量化后会产生比 H.264(在相同 QP 下)更明显的振铃效应。对于小分辨率的输入而言，该情况将更加严重。为了缓解该问题，H.265 引入了 SAO(Sample Adaptive Offset)技术作为环路滤波器。

引入这个技术后，振铃效应有所缓解，但对小分辨率而言还是存在一定的问题。

上图中右侧的示例，是一个 1080P 分辨率的 video profile，尝试用非常高的码率目标来编码。但和原图相比，仍然存在整体的振铃模糊，因为在 QP 达到 20 以上的时候是避免不了的。

那 H.265 适用于什么样的 video profile？笼统来讲，profile≥θ，θ 是 video profile 的边界。帧率/目标码率不同，θ 值不同，我们在 SDK 中可以采用灵活的自适应的方法来做边界的判断。

另外，一个 workaround 是，采集更大的分辨率，裁出用户真正感兴趣的部分，来达到缓解小分辨率振铃效应的效果。

还有一个解决方案是推动用户用同样的码率做分辨率的升级，来规避相关的问题。但总的而言，处理这类问题，需要给 video profile 一个明确的应用边界。

3、适用范围

为什么要做设备适配性呢？因为现在市面已有的机器中，硬编硬解的设备覆盖率可能在 80% 以上，但在 80% 能支持 H.265 的机器中，有相当一部分不能在 RTE 场景使用，因为它的码控可能不稳定，或者它有一些 B 帧的特性是没法控制的。

这会导致什么问题呢？我们一般来讲，希望 B 帧能够明确受控，否则第一会有延迟，第二在整个 RTC链路上可能会有一些端不支持或者解码的问题，第三就是在硬解部分有一些兼容性、出帧延迟以及均匀性的问题，会导致实时体验比较差。所以对这类设备，需要在有必要的时候，整体的方案 fallback 到 H.264。

一般而言，我们是基于能力协商来做 fallback。下图右侧是能力协商的一个例子，这里会涉及到两方面，第一个是 profile，第二个是 codec。

我们先说第一种情况，基于 codec 支持类型的能力协商。比如说我们已知目前 SDK 已有的各种能力，可以支持 H.264、H.265、AV1，也可以支持更高的 profile 比如 4K60帧，但观众端下行端未必能够支持，比如观众端只能解析 H.264 而不能解析 H.265，这种情况就要触发基于 codec 支持类型的能力协商，让主播端退回到 H.264 的方案去编码。

第二种情况，比如说上图中的观众 3 支持 H.265，但没办法解析 4K60 帧的 profile，这时候也需要触发回退机制，让主播端将编码上行设置为最高 1080P 30帧的码流。这里协商的机制有些像编码标准里的 level 的概念。

我们也支持无需 fallback 的方案，在云端来统一处理这些复杂的情况。比如说下行的观众端中有一部分不支持 H.265，我们可以在云端提供转码服务，提供他们能支持的较低的 profile。这个思路有些类似CDN 提供的订阅转码流功能。

这几种思路都需要端上有能力上报和协商，来进行相应的触发。

在实际应用中，还存在两个频道内主播进行连麦 PK 的场景，这时需要考虑如何将端上的能力透传并且有效管理。

这是一个比较典型并且必须解决的问题。在我们的实践中，端云结合的应用场景会发生一些不可预期的行为，比如从单主播切换到双主播 PK 场景，如果主播 1 的观众在端侧不能解析 H.265，而连麦进来的主播 2 发送的是 H.265 的流，这时候就会出现比较大的体验问题。因此我们根据前文所述的一些思路，提供出了这类场景的解决方案。

总的来讲，端云结合的方案中存在以下几个关键点。

首先是体验要能够保证，也就是复杂度代价比较低、体验提升比较大的情况下，我们支持了 Windows、Mac、iOS、Android、Web、小程序等端；支持并升级了各种云服务，比如推流、录制、低码高清等。

另外我们也要保证频道内不做过多的整体方案的回退，提供类似 CDN 形态的频道内自动转码方案。

以上这些方案涉及到的最重要一环，是能力协商和管理模块，这个模块要做的足够智能，需要考虑端上的编解码自适应支持。因为 H.265 在不同分辨率、帧率、码率下会存在不适应的情况，这时候要如何做自适应的切换并且保持相同的体验，已经如何评判切换后是否是最优解，都是其中的关键点。关于这些问题，声网有一些解决思路，欢迎大家联系我们，进行更进一步的沟通、交流。

（正文完）

点击下方图片

即可查看完整视频回顾

⬇️⬇️⬇️