《WebRTC系列》实战 Web 端支持 h265 硬解_webrtc h265

1、背景

Web 端实时预览 H.265 需求一直存在，但由于之前 Chrome 本身不支持 H.265 硬解，软解性能消耗大，仅能支持一路播放，该需求被搁置。

去年 9 月份，Chrome 发布 M106 版本，默认开启 H.265 硬解，使得实时预览支持 H.265 硬解具备可行性。

然而 WebRTC 本身支持的视频编码格式仅包括 VP8、VP9、H.264、AV1，并不包含 H.265。根据 w3c 发布的 2023 WebRTC Next Version Use Cases 来看，近期也没有打算支持 H.265 的迹象，因而决定自研实现 WebRTC 对 H.265 的支持。

2、DataChannel

背景说到 chrome 支持了 h265 的硬解，但 WebRTC 并不支持直接传输 h265 视频流。但可以通过 datachannel 来绕过这个限制。

WebRTC 的数据通道 DataChannel 是专门用来传输除音视频数据之外的任何数据的（但并不意味着不可以传输音视频数据，本质上它就是一条 socket 通道），如短消息、实时文字聊天、文件传输、远程桌面、游戏控制、P2P加速等。

1）SCTP协议

DataChannel 使用的协议是 SCTP(Stream Control Transport Protocol) (是一种与TCP、UDP同级的传输协议)，可以直接在 IP 协议之上运行。

但在 WebRTC 的情况下，SCTP 通过安全的 DTLS 隧道进行隧道传输，该隧道本身在 UDP 之上运行，同时支持流控、拥塞控制、按消息传输、传输模式可配置等特性。需注意单次发送消息大小不能超过 maxMessageSize(只读, 默认65535字节)。

2）可配置传输模式

DataChannel 可以配置在不同模式中，一种是使用重传机制的可靠传输模式(默认模式)，可以确保数据成功传输到对等端；另一种是不可靠传输模式，该模式下可以通过设置 maxRetransmits 指定最大传输次数，或通过 maxPacketLife 设置传输间隔时间实现；

这两种配置项是互斥的，不可同时设置，当同为null 时使用可靠传输模式，有一个值不为 null 时开启不可靠传输模式。

3）支持数据类型

数据通道支持 string 类型或 ArrayBuffer 类型，即二进制流或字符串数据。

后续两种方案，都是基于 datachannel 来做。

3、方案一 WebCodecs

官方文档: github.com/w3c/webcode…

思路: DataChannel 传输 H.265 裸流 + Webcodecs 解码 + Canvas 渲染。即 WebRTC 的音视频传输通道(PeerConnection) 不支持 H.265 编码格式，但可采用其数据通道(DataChannel)来传输 H.265数据，前端收到后使用 Wecodecs 解码、Canvas 渲染。

优点：

• 直接传输 H.265 裸码流，无需额外封装，实现简单方便；无冗余数据，传输效率高

• Wecodecs 解码延迟低，实时性很高

缺点：

• 音频需额外单独传输、解码和播放，需处理音视频同步问题

• 既有 sdk 基于 video 封装，webcodes 方案依赖 canvas，既有 video 相关操作，需要全部重写，比如截图，录像等操作

• 由于线上各项目等历史原因，既有 sdk 改动大，时间上不允许

4、方案二 MSE

官方例子: github.com/bitmovin/ms…

思路：Fmp4封装 + DataChannel 传输 + MSE 解码播放。即先将 H.265 视频数据封装成 Fmp4 格式，再通过 WebRTC DataChannel 通道进行传输，前端收到后采用 MSE 解码, video 进行播放。

优点：

• 复用 video 标签播放，无需单独实现渲染

• 音视频已封装到 Fmp4 中，web 端无需考虑音视频同步问题

• 整体工作量相比 Wecodecs 小