导读：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 视频引擎的开发与保护。