乐趣区

关于java:网易云信-NERTC-高清画质体验之-H265的工程实践-体验共享技术专题

jiezi

导读：H.265 是 ITU-T VCEG 继 H.264 之后制订的新一代视频编码标准，相比于 H.264，H.265 可能进一步提高压缩效率，晋升画质，在以后的很多音视频场景中，失去了越来越宽泛的利用，咱们在网易云信 NERTC 中对 H.265 做了大量的工程实际，本文为体验共享系列第三篇—视频篇，文章将从四个方面做具体介绍。

能力协商

一个客户端是否发送指定的特色的码流，不仅由本端是否反对编码决定，也由房间里其余接收端是否解码决定。即发送端和接收端独特决定了本端能发送什么样的码流。对于 H.265，可能会呈现上面的状况：

那么他们之间将如何通信？客户端 B 如果发 H.265 的流，客户端 A 和客户端 D 因为只反对 H.264 解码，它们接管到客户端 B 发送的 H.265 的码流，是无奈解码的，所以咱们须要设计一套能力协商机制，来保障反对不同编解码能力的客户端之间能够失常的通信。

下图为 能力协商 的整体设计图：

上面具体介绍一下咱们能力协商的设计方案。

能力集设计

能力集定义为 {uint32 key : [ uint8 value1, uint8 value2 …] }，应用 1 位掩码

sdk 的 key 范畴是 [0, 2^8) 

video 的 key 范畴是 [2^8, 2^16)

audio 的 key 的范畴是 [2^16, 2^24)

字节示意如下：

举例说明如下：

能力协商流程（客户端）

  1. 客户端本地定义能力集
  2. 客户端本地实现能力集上报，能力集下发配置的机制
  3. 服务端提供频道内能力集的生成、综合以及下发性能

举例说明：

定义：能力字段 VideoCodec : 256 (2^8)，能力值 H.264 : 0，H.265 : 1

 客户端 A 和客户端 B 进入同一个频道时，客户端 A 上报能力集{256 : [0, 1]}，客户端 B 上报能力{256 : [0]}

服务端收到客户端 A 和客户端 B 的能力集上报之后，晓得 A 反对 H.264 和 H.265，B 反对 H.264，综合 A 和 B 的能力集，失去 频道内反对 H.264 的论断，下发能力集 {256: [0]}

客户端 A 收到能力集后，被动敞开本人的 H.265 能力；客户端 B 收到能力集后，和本人的能力集统一，不做扭转。

能力协商流程（服务器）

  1. 房间创立时，生成默认能力集，** 默认能力集由引擎提供，服务器用作一个全局配置
    **
  2. 第一个 edge_login 申请如果 有能力集字段 ，则应用这个能力集笼罩默认能力集，作为房间的能力集；如果 没有能力集字段，则应用默认能力集作为房间的能力集。因为是第一个，不须要播送。
  3. 后续每个用户进来，如果 能力集大于房间的能力集，则返回房间的能力集给这个用户，房间的能力集不变。举例说明如下图：

  1. 后续每个用户进来，如果 能力集小于房间的能力集，则取交加，放大房间的能力集，并把后果播送给所有的用户。举例说明如下图：

H.265 编解码器实际

各个平台有本人特有的硬件 265 编解码器，同时还有各种开源的软件 265 编解码器，那么咱们将如何抉择，能力实现最佳的应用成果？

上面咱们将分 Android，iOS，Mac 和 Windows 四个平台别离介绍各平台 265 编解码器的实际状况。其中软件编码器选用 x265 做测评，软解选用 ffmpeg，libhevc 做测评。

Android 端

首先咱们看一下 android 端硬件编解码器的功耗和码率状况（测试机型 Mi 10 : Qualcomm Technologies, Inc SM8250，测试 Profile：720P 30fps 1.7M）

再看一下 android 端各软件编解码器的性能状况（测试机型 Mi 10 : Qualcomm Technologies, Inc SM8250，测试 Profile：720P 30fps 1.7M）

最初看一下 画质比照（测试机型 Mi 10 : Qualcomm Technologies, Inc SM8250，测试 Profile：720P 30fps 858k），左为 H.264，右为 H.265

总结：

  1. android 硬编 265 在功耗方面根本跟硬编 264 持平，同时 android 硬编 265 码率比硬编 264 更稳一些
  2. android 端软编 265 的性能还是比拟差的，不能满足需要
  3. android 端 ffmpeg 软解 265 在 arm64 下面性能比拟差，CPU 占用达 15%，同样条件下，应用 libhevc，CPU 占用只有 4.5%，性能上有很大晋升空间
    4. android 硬编 265 的画质显著要比硬编 264 的画质更清晰，画质收益很显著

所以 android 端 咱们 265 编解码器的应用策略如下：

  1.  优先应用 265 硬解。一些设施存在 265 硬解兼容问题的，高端机型抉择 265 软解码器，低端设施间接认为不反对 265 解码
  2.  优先应用 265 硬编。一些设施存在 265 硬编兼容问题的，则认为不反对 265 编码，降级到 264 编码
  3. 因为 libhevc 软解的性能显著优于 ffmpeg 软解 265，所以 265 软解码器咱们会优先选择 libhevc

iOS 端

首先咱们看一下 iOS 端硬件编解码器的功耗状况（测试机型 iPhone11，测试 Profile：720P 30fps 1.7M）

另外咱们发现在某些机型上或者某些场景下，iOS 硬编 265 会呈现显著的码率有余的问题（测试机型 iPhoneXR，测试 Profile：720P 30fps 1.7M）

H.264:

H.265:

像这种呈现码率严重不足的状况，咱们基于 iOS 硬编码控，设计了一套码率监控办法，如果监控到码率呈现严重不足，会从 H.265 回退到 H.264

最初看一下 在硬编码率稳固的状况下的画质比照（测试机型 iPhone11，测试 Profile：720P 30fps 858k）

左 H.264，右 H.265

总结：

  1. 应用 iOS 硬编 265 功耗显著比硬编 264 要大，同样的应用 iOS 硬解 265 功耗也显著比硬解 264 要大一些
  2. iOS 硬编 265 偶现一些码率有余的状况，导致画质反而不如 264

3. iOS 硬编 265 的画质要比硬编 264 的画质更清晰一些，有一些画质收益

所以最初 iOS 端 咱们 265 编解码器的应用策略如下：

1. 优先应用硬编 265，不反对软编 265

2. 优先应用硬解 265，只有在硬解 265 屡次解码失败无奈复原后才会回退到 ffmpeg 265 软解

  1. 因为 iOS 265 硬件编码功耗比硬件 264 要大，监测 iOS 设施整体电量，在 低电量状况下（比方到 20% 临界点），咱们把硬件 265 切回到了 264 硬件编码器
  2. 应用 iOS 硬编码控模块，监测理论编码码率状况，若呈现显著的码率有余或者码率超发，咱们把硬编 265 切回到了硬编 264

iOS 硬编码控

下图为硬编码控模块设计图：

码控流程：

首先 硬编码器 将指标码率 Target Bitrate 传递给 码控模块 HWBitrateController

每编码实现一帧，将编码后的帧大小更新给 HWBitrateController 估算出每秒的 理论编码码率 Estimated Bitrate

计算 指标码率与理论码率间接的差值 Diff

通过 二分法，取 0.5 倍的 Diff 加 Target Bitrate，作为须要调整的码率 Adjusted Bitrate

将须要调整的码率 Adjusted Bitrate 设置回硬编码器 HWEncoder，作为 HWEncoder 的指标码率 Target Bitrate

再 回到第一步，硬编码器将以后指标码率 Target Bitrate 传递给码控模块 HWBitrateController

计算 Diff/Target Bitrate，如果继续大于 30%，则认为码率呈现显著有余，须要触发降级编码器

Mac 端 

首先咱们看一下 Mac 端 265 软硬件编解码器的 CPU 和码率状况（测试机型 MacBook Pro (15-inch, 2016）: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz，测试 Profile：720P 30fps 1.7M）

硬编 265 码率状况：

软编 265 码率状况：

同时，咱们通过 dump Mac 硬编 265 的码流，发现 应用前向 B 帧取代了 P 帧

最初，咱们看一下 画质比照（测试机型 MacBook Pro (15-inch, 2016): Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz，测试 Profile：720P 30fps 1M）

总结：

  1. Mac 下面 硬件 265绝对于软件 265，CPU 占用更低，性能收益比拟显著

2. 硬编 265 码率稳定性不如软编 265，稳定比拟大，但都是围绕指标码率高低稳定，通过长时间测试，发现整体码率均匀下来没有显著的超发或者有余状况呈现

3. 硬编编码码流前向 B 帧取代了 P 帧，整体压缩率会更高，等同码率画质更优

4. 硬编 265 画质显著优于 264，而软编 265 与硬编 265 画质差别不大

所以  Mac 端 咱们 265 编解码器的应用策略如下：

  1. 优先应用 265 硬解。一些设施存在 265 硬解兼容问题或者不反对 265 硬解的，在 CPU 性能比拟强的设施下面应用软解 265(ffmpeg)，如果是 CPU 比拟弱的设施，则认为不反对 265 解码
  2. 优先应用 265 硬编。一些设施存在 265 硬编兼容问题或者不反对 265 硬编的，在 CPU 性能比拟强的设施下面应用软编 265，如果是 CPU 比拟弱的设施，则认为不反对 265 编码

Windows 端 

windows 下面因为硬编硬解碎片化比较严重，咱们临时没有思考应用硬编硬解，目前以 应用软编软解为主。

下图为 win 下面软编软解 265 的状况（测试机型 Dell Latitude 5290: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz，测试 Profile：720P 30fps 1.7M）

能够看到：

1. 软编 265 和软解 265 在 x86 下面的性能体现不如 x86_64

2. 软编 265 在 x86_64 下面的 CPU 耗费也是远远高于软编 264 的

所以最初  Win 端 咱们 265 编解码器的应用策略如下：

1. 在应用 win x86 的状况下，间接不反对 265 软编软解

2. 在应用 win x86_64 的状况下，CPU 性能比拟强的设施上开启 265 软编软解；同时软编 265 对 CPU 性能要求比软解 265 更高，所以对设施的性能要求也会更加严格

工程策略

白名单策略 

后面有提到，咱们在 应用 265 硬编硬解的时候，须要思考设施兼容性的问题；同时在应用 265 软编软解的时候，因为波及大量的编解码运算，也要思考设施的性能问题。

为了在整体工程层面提供最佳的用户体验，咱们应用到了白名单策略。通过白名单配置下发，把是否反对 265 硬编硬解和软编软解的设施辨别进去。

以下是咱们的具体做法：

  • 通过大量的设施适配，把对 265 硬编硬解反对比拟好的设施，配置到线上白名单外面
  • 通过设施跑分，辨别出设施 CPU 性能的高下，配置高性能的设施反对 265 软编软解，低性能设施不反对 265 软编软解，而后将配置更新到线上白名单外面
  • 最初通过线上白名单配置下发，客户端获取到以后是否反对硬编硬解和是否反对软编软解的配置信息

H.265 能力协商 

协商的是 H.265 解码能力，协商后果最初作用于编码侧，是否应用 H.265 编码

  • H.265 解码的配置下发，用户设置以及以后设施反对能力，三者综合得出以后 H.265 的解码能力
  • 能力协商模块，依据以后 H.265 的解码能力，生成能力集，上报给能力协商服务器
  • 能力协商服务器综合频道内各客户端的能力集，生成新的房间能力集，下发给各客户端
  • 客户端收到来自于服务器下发的能力集，解析出以后频道内 H.265 的能力集
  • 依据以后频道内 H.265 的能力集，H.265 编码的配置下发、用户设置以及以后设施反对能力，服务器对 H.265 的反对能力，三局部综合得出以后是否反对 H.265 编码，最初作用于编码侧是否编 H.265 的流

CPU OverUse 策略 

通过跑分，辨别出不同设施 CPU 性能的高下，可能不是齐全的精确。在理论场景中，有可能存在跑分数据很高，然而编码性能不够的状况，这时候咱们须要 通过实时监测统计以后视频编码耗时，来判断以后是否 CPU 过载。

咱们的做法是：

  • 硬编 265 思考到可能存在 pipeline delay 的状况，目前咱们 暂不统计每帧编码的编码耗时
  • 在应用软编 265 的时候，统计每帧编码的编码耗时，如果呈现继续编码耗时过长，那么就认为以后 CPU 过载，265 软编将会立刻回退到 264

QP 阈值调整 

咱们的 QOE 模块，会依据 QP 阈值调整帧率和分辨率，以达到主观视频品质最优，所以设定正当的编码器 QP 阈值就显得十分重要，那么在理论工程实际中，准对硬件 265 编码器，咱们如何摸索出正当的 QP 上上限阈值？

咱们的做法是：

  • 确保 H.264 和 H.265 在主观画质根本对齐的状况下，打出 QP 值，生成 QP 曲线，基于 QP 曲线得出 QP 上上限阈值根本的范畴

咱们以这款机型为例：（测试机型 Mi 10 : Qualcomm Technologies, Inc SM8250，测试 Profile：720P 30fps）

能够看到：

  1. 在 720p 30fps 这个 Profile 档位，硬编 265 与硬编 264 在画质根本对齐的状况下，硬件 265 码率可能节俭 40%，QP 稳定根本类似，高低阈值也根本靠近。所以如果以后 android 硬编 264 的 QP 高低阈值是[A, B]，那么倡议 android 硬编 265 的 QP 上阈值范畴为[A-1, A+1]，QP 下阈值范畴为[B-1,B+1]
  2. 基于步骤 1 得出的 QP 高低阈值范畴，逐渐网损逐渐放开，观测 QOE 模块基于 QP 阈值的分辨率和帧率的调整状况，从 QP 阈值范畴中摸出最正当的一个 QP 阈值，以上面的数据为例：

咱们发现在 QP 阈值为 [A-1,B-1] 的时候，整体 QOE 体现最好，所以选定 [A-1,B-1] 为最初的硬编 265 的 QP 阈值

收益

目前第一阶段的收益评测，咱们是基于与 H.264 分辨率码率对齐，看 画质收益、端到端提早、CPU 占用、晦涩度 这四个指标。这里先列举了与硬编 264 比照，Android 硬编 265 和 iOS 硬编 265 的画质收益状况，从咱们评测下来的状况看，端到端提早、CPU 占用、晦涩度这三个指标基本上差别不大，而画质收益，能够参考以下图表数据：

总体来看：

  1. 相比于 264，265 在视频画质上是有显著收益的
  2. 在低码率、弱网或者画面变动比拟激烈的场景下，画质收益会更加显著

3. android 硬编 265 的画质收益要显著优于 iOS 硬编 265

总结

不论是硬编 265，还是软编 265，相比于 264，视频画质都有显著的收益；后续网易云信将准对画质对齐，节俭码率这个维度做进一步的摸索。

作者介绍 

施灵凯，网易云信音视频引擎开发工程师，负责 NERTC 视频引擎的开发与保护。

退出移动版