技术分享| anyRTC 音视频与微信小程序互通实践

随着网络架构的变迁、媒体技术发展、音视频场景迭代，基于流媒体的技术也是推陈出新。WebRTC 渐渐的成为了音视频互动场景的主流，而微信在 6.5.21 版本通过小程序开放了实时音视频能力，开发者们可以使用组件 < live-pusher > 实现基于 RTMP 的直播推流（录制），用于实时音视频通话上行，使用组件 < live-player > 实现基于 RTMP 的直播拉流（播放）。可以看出，微信小程序的音视频是基于 RTMP 协议的，但是微信小程序的音视频只是提供了终端上的能力，并没有实现媒体服务器，腾讯给出了 2 个方案，1 是使用腾讯云的快直播服务，2 是开发者自己实现一套媒体网关服务。方案 1，需要完全使用腾讯云的服务，很显然不太适合我们这样的开发者；于是留给我们的之后方案 2 了。

一．什么是 RTMP，什么是 RTC

1.RTMP

RTMP 是 Real Time Messaging Protocol 实时消息传输协议，是 Adobe 公司为 Flash 播放器和服务器之间开发的音视频数据传输的开放协议，一般传输 flv 或 f4v 格式的媒体流。RTMP 是工作在 TCP 之上的协议，默认使用端口 1935，能够保持长连接，并为用户提供低延时通信。RTMP 是目前低延时直播应用最普遍的协议，几乎是全部编码器标准输出协议，是 PC 机打开浏览器就能播放（通常浏览器默认有 Flash），也是全部 CDN 支持的最好的直播分发协议。

RTMP 是基于 TCP 协议的，且通常只占用 TCP 一个通道来传输数据和指令，能保证了视频的传输质量。RTMP 包括 RTMP 基本协议及 RTMPT/RTMPS/RTMPE 等多种变种。RTMPT 封装在 HTTP 请求之上，可穿透防火墙；RTMPS 类似 RTMPT，增加了 TLS/SSL 的安全功能；RTMPE 在 RTMP 的基础上增加了加密功能。

因为 RTMP 是基于 TCP 之上的，所以也存在三次握手的要求，另外 RTMP 还增加了 C0/S0 到 C2/S2 的三次握手。所以播放一个 RTMP 协议的流媒体需要经过：握手，建立连接，建立流，播放。

RTMP 也有不可忽视的缺点，首先，RTMP 协议太老，HEVC/H.265/AV1 等视频格式都没有官方定义，另外就如刚刚所说，RTMP 连接过程较长，存在 TCP 三次握手和本身的 C0/S0 到 C2/S2 的三次握手，再加上 connection，createstream，play/publish，总地来说 RTMP 完成一次建连需要进行 9 次会话。而且 RTMP 的拥塞控制完全依赖传输层 TCP 的拥塞控制算法来进行拥塞管理，无法提供带宽自适应的算法。

2.WebRTC

WebRTC 是 Web Real-Time Communication 网页实时通信，是一个支持网页浏览器进行实时语音对话或视频对话的技术而无需任何插件。由谷歌 2010 年以 6820 万美元收购 Global IP Solutions 公司而获得，如今 WebRTC 已经不仅仅局限于 PC 的网页浏览器，Android，iOS 平台上很多应用都已经采用了这样技术。

WebRTC 使用是 RTP 分装码流，跟视频监控，IPTV，会议电视一样都是 RTP 承载媒体流，只不过 WebRTC 信令遵守 ICE 框架，走自定义信令，IPTV 领域走 RTSP 信令，视频监控走 GB28181 或者 onvif 信令，会议电视走 h323 或 SIP 协议。另外，WebRTC 的码流采用 SRTP 进行加密，且 WebRTC 优先使用 VP9、VP8、H.264、AV1，暂不支持 H.265。

二．WebRTC 如何跟小程序互通

1.如何互通大概分三步走：

A.微信小程序端使用 RTMP 协议，接入边缘媒体网关，即 Xcx 网关；

B.Xcx 网关支持 RTMP 协议接入和输出，完成微信小程序间的媒体转发；

C.同时 Xcx 网关将 RTMP 协议转换成 RTP 协议，转发给 anyRTC 的 WebRTC 服务器，完成与 Native、标准 WebRTC 终端的互联互通。

anyRTC 的 Xcx 网关的主要工作就是对 RTMP 和 WebRTC 的音视频格式进行转换。一般 RTMP 的视频是 H264 编码，音频是 AAC 编码；WebRTC 的视频是 H264 编码，音频是 Opus 编码。所以我们可以看出，视频只需要转换封装格式，而音频则需要进行转码工作。

2.视频格式转换

anyRTC 的 Xcx 网关收到视频帧之后，将帧进行 RTP 封装 H.264。

WebRTC 选择了使用 RFC3984 的 Non-Interleaved 封装方案对 H.264 进行封装。

Single NAL Unit Packet

Single NAL Unit Packet 是 RTP 最基本的打包方式，其中，forbidden_bit：禁止位，初始为 0，当网络发现 NAL 单元有比特错误时可设置该比特为 1，以便接收方纠错或丢掉该单元。

nal_reference_bit：nal 重要性指示，标志该 NAL 单元的重要性，值越大，越重要，解码器在解码处理不过来的时候，可以丢掉重要性为 0 的 NALU。Type：NAL 单元中的 RBSP 数据结构的类型，其中 0 未指，1-19 在 H.264 协议中有定义，20-23 为 264 协议指定的保留位，24-29 在 RFC3984 中进行了指定。Type 后面的数据为 RBSP 的数据，需要注意的是：编码器的每个 slice 或者每帧头一般会有由 0x000001 或者 0x00000001 作为起始头，在 RTP 封装中需要去掉。此外在 H.264 裸码流数据后面可能还会带有 padding 的数据由 RTP 头的 padding 位决定。

STAP-A

STAP-A 的作用是可以把多个 nal 单元封装在一个 RTP 包里面进行传输，需要注意：-A 的格式都是不允许跨帧的，也就是 nal 单元的时间戳必须是相同的。常见的场景是 sps 和 pps 两个小包被合并封装。

RTP 头后面仅跟着 STAP-A 的头，由 F、NRI 和 Type 组合而成，占一个字节，这里的 Type 为 24。后面两个字节为第一个 nalu 单元的长度，后面跟第一个 nalu 数据同 Single NAL Unit 的封装一致，第一个数据结束后，跟着第二个 nalu 的长度，占 2 个字节，依次类推。

FU-A

FU-A 的作用是把一个原始大的 nalu 切成多个数据包进行传输，主要使用场景在 slice 比较大的情况下。FU-A 比较特殊，有 FU-A 起始包、FU-A 包（如果只切两个包可能没有）和 FU-A 结束包组成。

FU indicator 占一个字节，由 F、NRI 和 Type 组合而成，这里的 Type 为 28。FU header 占一个字节：

S： 占 1 位如果是 1 表示当前这个包是 FU-A 的起始包 E： 占 1 位如果是 1 表示当前这个包是 FU-A 的结束包 R： 占 1 位，保留位，为 0Type： 实际包含 nalu 的类型。

音频转码

在 Xcx 网关中，我们采用了独立的音频转码线程组，减轻逻辑处理线程的压力的目的。每个转码任务将被分配到固定的音频转码线程，线程根据任务数量进行负载均衡。

三．总结

与小程序的互通相对来说还是比较容易实现，开发者可以选择 anyRTC 的小程序服务，避免过多的踩坑；也可以尝试自己实现一套服务来满足自身的业务诉求。