原文链接

邱建林 （jianlin.qiu@intel.com）

在当今的数字环境中，视频会议、云游戏和内容服务等应用程序对高质量视频流的需求比以往任何时候都大。然而，此类应用的性能和能效一直是开发人员和服务提供商面临的一个持续挑战。WebRTC H.265/HEVC 的推出解决了这一关键问题，为独立软件供应商（ISV）和服务提供商提供了一种增强编解码器产品组合的解决方案。 

经过四年的努力，英特尔Web工程团队在Chrome浏览器136版本正式启用这一期待已久的功能，通过在功率和性能方面的重大改进，可支持更流畅、更高效的流媒体体验。作为 Microsoft Teams®、Google Meet®和Cisco Webex® 等视频会议平台的重要组成部分，WebRTC 在这些应用传输音视频数据时发挥着关键作用。随着 H.265/HEVC 的加入，WebRTC将可使用新增的高级功能来提供卓越的流媒体服务质量。

如上图所示，根据剑桥大学出版社发布的《综合视频编解码器比较》，H.265/HEVC 可提供与 VP9 相当的压缩效率（同码率下通过峰值信噪比度量，以AV1 为基准）。在各种硬件平台上，它更广泛地支持编解码硬件加速。此外大多数 IP 摄像头支持 H.265/HEVC， 这使其成为极具吸引力的低带宽免转码方案。

英特尔在 Chromium (Chrome/Edge浏览器的内核）中对WebRTC的H.265/HEVC 实现是与 谷歌，微软，字节跳动以及其他行业合作伙伴合作的成果。此功能在Chrome 浏览器版本136开始已默认启用，并可在Intel 的Skylake及之后的平台上运行。

我们在Chromium 中的 WebRTC 视频处理链路中，针对 H.265/HEVC 增加的实现如下图所示：

与 Chromium 中的其他 WebRTC 编解码器相比，H.265/HEVC 在软件/硬件兼容性、服务质量和编码效率方面脱颖而出。

改进的软件/硬件兼容性

借鉴其他 WebRTC 编解码器的经验，我们的实现始于W3C和 IETF 的标准化工作。我们对规范的贡献包括但不限于：

· AVTCore-HEVC-WebRTC 中对 RFC 7798 的信令协议改进，它规定了如何在不同终端节点（包括浏览器）之间协商 H.265/HEVC 的配置文件、层、级别和打包模式。IETF 新建立的这些针对H.265/HEVC的标准可防止出现类似于 H.264/AVC 等编解码器中的互作性问题。

· 针对非对称编码/解码能力的 WebRTC Web API 改进。与其他编解码器不同，H.265/HEVC 为终端节点提供了灵活性，允许终端仅支持编码或解码。WebRTC 规范的增强可确保以明确定义的行为建立 WebRTC 会话，即使终端的H.265/HEVC编码/解码能力是非对称的。

根据谷歌的统计 ，当前 H.265/HEVC 与 AV1 的硬件支持比率在 Windows 和 macOS 上的 Chrome 浏览器上的比较（支持的终端/所有终端）：

编解码器类型	Windows	macOS
H.265/HEVC	75%	90%
AV1	8%	0%

通过采用H.265/HEVC，ISV 和开发人员可以从集成到 WebRTC 中的增强的软件和硬件兼容性中受益。

提升服务质量（QoS）

与 H.264/AVC 相比，Chromium 中的 H.265/HEVC WebRTC 实现在各种网络条件下提供了更高的服务质量（QoS）。这些改进包括在丢包网络上减少重传带宽，和支持时间可扩展性，以及使用新设计的 H.265/HEVC 打包/解包模块来消除关键帧上的视频损坏。

时间可扩展性

对比H.264/AVC，我们在 Chromium 中的第一个功能增强是支持 H.265/HEVC 的时间可扩展性。时间可扩展性的概念如下图所示：

在 Chromium 中通过 WebRTC 编码和传输 H.265/HEVC 视频时，视频帧最多分为三个时间层，以允许视频转发服务器以不同的帧率转发视频。较高的时间层帧可以参考较低的时间层的帧。这种设计允许 WebRTC H.265/HEVC 终端节点在网络帧丢失的情况下选择性地解码较低时间层的视频帧，而无需重新传输丢失的较高时间层的帧。

实验表明，在往返时间（RTT）为100毫秒、随机丢包率为5%的100Mbps网络上，视频分辨率为1280x720（720p）时，H.265/HEVC 时间可扩展性可将重传带宽降低11%，接收视频帧的抖动（jitter）降低18%。

打包和解包

打包是指在视频传输过程中将压缩的视频帧拆分为 RTP 片段，以适应最大传输单元（MTU）大小。解包是相反的过程，从 RTP 片段组装成压缩的视频帧。

我们实现的 H.265/HEVC 打包/解包与 RFC 7798 完全兼容，确保与现有流媒体服务器的互操作性。

在解包过程中，基于 H.264/AVC 的视频会议系统的一个常见问题是不同终端节点之间的关键帧组合行为不一致。在丢包网络中，这通常会导致关键帧在接收端重组时缺少参数集，如果处理不当，会因视频卡顿导致用户体验不佳。

我们解决这个问题的方法首先是将 WebRTC 的 H.265/HEVC 的关键帧定义整合到RFC 规范中，从而避免在解包过程中出现语义歧义。此外，在 Chromium 中设计并实现了一个新的H.265/HEVC专用的组包模块，以简化组帧逻辑。这消除了 WebRTC 堆栈额外修复关键帧的需要，从而降低了接收终端节点上软件堆栈的复杂性。

编码效率改进

Chromium中，WebRTC 的 H.265/HEVC 的编码效率与VP9大致相当，与 H.264/AVC 相比有显著改进。这归因于 Chromium 中新引入的软件码率控制器，以及为 WebRTC H.265/HEVC 添加了自定义参考帧管理，和相应的 RTP 会话级元数据的引入。

软件码率控制器

WebRTC 可根据运行时的实时网络指标（如丢包率和 RTT）动态调整传输码率。在 H.265/HEVC 集成之前，H.264/AVC 编码码率由显卡驱动使用恒定码率（CBR）模式进行管理，因此Chromium 运行时不能精准控制编码后的每帧的大小。这导致来自不同硬件编码器的输出码率不一致，且瞬时较大的帧会导致网络传输带宽突增。

我们的实现通过将软件码率控制器（SW-BRC）集成到 Chromium 中来解决这个问题，该控制器将 H.265/HEVC 硬件编码器的码率模式从恒定码率（CBR）切换到恒定量化参数（CQP）模式。在这种新模式下，驱动程序在编码过程中仅接收由 SW-BRC 预先计算的每帧量化参数（QP）。此方案的优势包括：

·显著减少动态网络中的关键帧：WebRTC 的帧率和码率频繁变化通常会触发关键帧，这会损害网络并降低用户体验。使用 软件码率控制，Chromium 不再为帧率和码率的每次变化生成关键帧。这将对硬件编码器的关键帧请求从极端情况下的每秒 1 个减少到每 100 秒一次。

·提高了请求编码码率与实际编码码率的拟合度：根据我们的测试，偏差从 CBR 模式下的近5%降低到低于1%。与时间可扩展性结合，Chromium 可以控制不同时间层上的比特率，从而在较低的时间层提供更好的视频质量。

自定义参考结构和依赖关系描述符

编码器的另一个关键改进是在 Chromium 中添加了自定义帧参考结构支持。在我们的实现之前，Windows 上 Chromium 中所有编码的硬件加速都是通过 Windows Media Foundation API 实现的，该 API 不支持 Chromium 运行时直接控制哪些帧可以用作帧间参考。这导致了视频会议系统的两个主要问题：

· 当终端节点在多个时间层进行编码时，媒体服务器无法确定帧之间的引用结构。这使得在启用时间可扩展性时，无法选择性转发不同层的视频帧。

· 在丢包网络中，无法利用长期参考（LTR）等编解码器功能，使得编码端无法根据来自接收端点的丢帧信息对后续帧的参考图片进行动态调整。在此情况下，Chromium 必须向发送端请求关键帧编码，这会增加视频传输延迟，降低用户体验。

我们的实现通过将编码框架从 Media Foundation 转换为D3D12 API 来增强 Windows 上的帧引用控制。D3D12 API 提供对编码器硬件的低级访问，支持使用各种工具对编码进行精细控制，其中就包括指定每帧参考图片的能力。此外，它还允许 Chromium 使用不同的参数对视频帧的特定子区域进行编码，从而提高局部编码质量。

我们还添加了对 H.265/HEVC 的依赖项描述符 RTP 扩展的支持，该扩展最初是为AV1设计的。该扩展将会话层帧的参考结构传递给媒体服务器和接收客户端，从而根据当前帧的参考帧是否已被转发，选择性地转发/解码当前视频帧。此功能进一步减少了数据包丢失网络中的重传和关键帧请求。

基准测试

我们对Chromium 中不同 WebRTC 编解器的编码质量进行定量比较，以 2000kbps 和 500kbps 为例，使用峰值信噪比 （PSNR） 作为指标（值越高表示质量越好）。测试在运行 Windows 11 （24H2）的 Intel Core Ultra 24v （Lunar Lake） 系统上进行，使用 Chromium 的视频编码加速器 性能测试套件。

在高码率设置（2000kbps）下，与 H.264/AVC 相比，Chromium 中的 H.265/HEVC 实现使 PSNR 提高了近4dB。在低比特率设置（500kbps）下，PSNR 改进增加到5.7dB。这种质量增强意味着 Chrome 可以实现与2000kbps的 H.264/AVC 相似的 H.265/HEVC 和2000kbps的视觉质量，从而将视频会议应用程序的带宽减少近50%。

总结

我们已经将 H.265/HEVC WebRTC 实现并入 Chromium 中，且在Chrome中默认开启，并对其之前的 H.264/AVC 进行了改进：

· 通过增强W3C和 IETF 标准提高了兼容性。

· 通过时间可扩展性和打包/解打包优化以及 Chromium 中相应的 RTP 会话级元数据，提高了 会话服务质量。

· 通过采用新的软件码率控制器和基于D3D12的新视频编码框架，提高了编码效率。

· 与 H.264/AVC 相比，这些技术共同减少了近50%的同等视频质量下，所需的编码/传输带宽，并在相同的视频质量级别下延长了电池寿命。

展望

英特尔的 Web 平台工程团队正在与各软件服务提供商合作，在其视频会议应用程序中启用 WebRTC H.265/HEVC。这项工作涉及与谷歌WebRTC 团队的密切合作，该团队为 Chrome 中此功能的代码提交和测试提供了重要支持。

随着我们继续推动 H.265/HEVC 在WebRTC中的应用，专注于提高编码效率和性能，与您的合作对于功能增强和生态系统发展至关重要。我们欢迎您在使用此功能期间提供反馈，并期待您通过邮件： open.ecosystem.communications@intel.com 与我们联系，分享您的想法和经验。

关于作者

邱建林：Intel 首席工程师

作为英特尔的 Web 媒体专家，邱建林专注于英特尔客户端平台上 Web 引擎的性能和能效。他是英特尔 Web 平台工程团队的一员。

© 英特尔公司。Intel、Intel 徽标和其他 Intel 标志是 Intel Corporation 或其子公司的商标。其他名称和品牌可能是其他公司的财产。