概述
本文介绍了微信小程序视音视频和WebRTC的技术特征、差异等，并针对两者的技术差异分享和总结了微信小程序视音视频和WebRTC互通的实现思路以及技术方案。
关于作者
rexchang（常青）：腾讯视频云终端技术总监，2008 年毕业加入腾讯，一直从事客户端研发相关工作，先后参与过 PC QQ、手机QQ、QQ物联 等产品项目，目前在腾讯视频云团队负责音视频终端解决方案的优化和落地工作。
分别介绍一下小程序音视频和WebRTC
__小程序音视频是什么？__
2017年腾讯视频云团队跟微信团队联合，将视频云 SDK 跟微信小程序整合在一起，并通过 <live-pusher> 和 <live-player> 两个标签的形式开放内部的功能。通过这两个标签，开发者可以实现在线直播、低延时监控、双人视频通话以及多人视频会议等功能
__WebRTC又是什么？__
WebRTC（Web Real-Time Communication），是一个支持网页浏览器进行实时语音对话或视频对话的技术，是谷歌收购 GIPS 公司而获得的一项技术，在 Chrome 浏览器上无需安装插件，通过 javascript 就可以编写实时音视频通话程序。
小程序音视频和WebRTC的区别在哪里？
如果您跟我一样是一个实用主义者，那我就简单从实用主义角度说一下我的结论：小程序搞定了手机，WebRTC拿下了PC。
如果你对技术原理比较感兴趣，那我们就可以从多个技术的角度去列举两者的区别，下面是一张详细对比的表格：
（区别一）：内部原理
小程序音视频是将腾讯视频云的 liteavsdk 嵌入到微信内部实现的，然后通过 <live-pusher> 和 <live-player> 两个标签将 SDK 内部的音视频能力开放出来。所以小程序的标签起到了开发者 API 的作用，而内部的 SDK 则是真正用来实现音视频功能。
WebRTC 由谷歌收购 GIPS 得来（这里不得不提一下，我加入腾讯时所在的第一个团队就是 QQ 团队，当时 QQ 的音视频还是购买的 GIPS 公司的产品，不过由于技术支持不能满足需求，后来我们就转为自研路线了）。所以其技术被完整的保留并且加入到了 Google 的 Chrome 浏览器内核当中。而且最近苹果也已经开始在 Safari 浏览器中支持 WebRTC 的相关能力。
（区别二）：传输协议
小程序音视频在直播场景使用了 RTMP 推流协议以及 FLV 播放协议，这两种协议都已经有多年的沉淀而且在互联网上的资料也是汗牛充栋。
小程序音视频在视频通话场景则使用了经过 UDP 改造的 RTMP 协议，相比于普通 RTMP 有更强的抗弱网能力和更低的卡顿率。
WebRTC的底层则是使用RTP和RTCP两种数据协议，其中RTP主要用于音视频数据传输，而 RTCP 则用于传输控制。
（区别三）：移动端碎片化问题
小程序音视频由于是微信统一实现的，而且微信团队每个版本都尽量要求功能对齐，否则宁可不上，所以在碎片化问题上基本不存在。
相比之下，WebRTC在这里则要尴尬的多，一方面Android系统的碎片化本身让WebRTC的具体表现呈现“百花齐放”的景象，同时，iOS 目前的内嵌WebView（也就是在微信等APP里打开的各种内嵌网页）不支持WebRTC也还是个很麻烦的问题。
（区别四）：未来扩展性
小程序音视频跟随微信的版本发布，有什么问题一般是当前代码流修正，然后跟随下一个版本发布，所以一般一个功能点（比如给 pusher 加一个美颜的功能）或者一个问题点（比如不支持手势放大）从确立到最终实现（或解决）仅需要一个月的时间，而且微信APP新版本的覆盖速度也确实挺快。
相比之下，WebRTC则不是一个团队或者一家公司的问题了，因为它现在已经走标准路线，所以每一个新特性都是先确定标准，然后再推动浏览器厂商（包括苹果）进行跟随。
（区别五）： 桌面浏览器
在前面几个问题的分析上，我的观点都倾向于小程序音视频。确实，在目前国内的移动领域里，谷歌和苹果都不能一家说了算，真正说了算的还是微信。
但是在桌面浏览器这个部分，Chrome目前在PC浏览器市场上留到地位的存在决定了 WebRTC 的优势就很大了，开发者可以在不安装插件的情况下就可以实现自己想要的功能。
所以，实现同 Chrome 浏览器的音视频互通，成为了小程序音视频的一个必不可少的能力特性。
互联互通
小程序音视频和WebRTC支架并非零和博弈，双方都有自己的优势和不足，实现两者的互通就能实现 1 + 1 > 2 的效果。
__PC 端__
用户可以使用 Chrome 浏览器直接使用音视频能力，免去安装桌面应用程序的痛苦。
__移动端__
用户可以使用微信小程序直接使用音视频能力，减少安装App的等待时间。
两者结合，可以将原本局限于小应用场景下的音视频能力扩展到各行各业中。
当然，要实现互联互通，并不是特别容易，首先，我们需要对 WebRTC 协议本身有一个全面的了解：
剖析WebRTC
就像结婚一样，既然你决定要选择另一个人作为人生下半辈子的伴侣，那你肯定会先深入地了解一下TA这个人，比如性格，脾气，爱好等各个方面。
同样，我们要想很好的将小程序音视频和WebRTC打通，那也必须要多了解一下WebRTC，对其知根知底，方能和平相处。
- WebRTC 的设计思路是open的
WebRTC 的接口设计一开始就尽可能把内部细节更多的暴露出来，而不是简单封装一套傻瓜式的接口。这种方案的好处是二次开发的灵活度比较高，比如您可以发现 WebRTC 的 API 可以灵活到操作很多连接细节。
但任何事情都有另一面，WebRTC的学习成本并不低，虽然Google做了很多浅显易懂的PPT来教你怎么 Getting Start，但真要完整的学进去，还是需要静下心来，慢慢啃下去。
- WebRTC 有多种后台接入方案
说WebRTC喜欢迁就比人，也是一种比喻，WebRTC所支持的后台架构非常多（比如 Mixer， Mesh，Router），而且谷歌认为这些后台实现方案并不需要给出什么限制和标准，因此也就没有提供统一的后台解决方案。
这种开放式的设计思路非常好，但副作用就是实现成本高。在真刀真枪的项目落地时，没有踩坑经验的开发者就很容易被这种技术门槛挡在门外。尤其是想要将 WebRTC 真正应用到企业级解决方案中，面对录制和存档的刚性需求，就需要花费大量时间进行定制开发。
互通方案
了解到 WebRTC 的这些特点后，我们的互通方案也就比较清晰了：
首先，小程序音视频的特点是接口简单，快速上手，这是小程序的优势；而这一点恰恰是WebRTC的劣势，所以我们没有必要在小程序端为WebRTC暴露十几组接口函数，而是继续采用小程序音视频的<live-pusher> 和 <live-player> 标签来解决问题。
其次，WebRTC 的后台没有官方实现，那就意味着这里有很大的发挥空间，腾讯视频云就可以实现一套WebRTC后台并将其同小程序音视频所使用RTMP后台进行打通。简单来说，腾讯视频云要在小程序音视频和WebRTC之间充当红娘（更确切的说，应该是翻译员）的角色。
但是看过《新闻联播》里国家领导人之间谈话镜头的人都知道，这种翻译是会影响交流速度的。小程序音视频和WebRTC之间互通，中间引入一个翻译员，是不是通讯延时也就增加了？
其实不会，因为小程序音视频和WebRTC的视频编码标准在常规应用场景中是一致的，都是H.264标准，只是音频格式不同而已。这就意味着，翻译员要做的事情很少，两边基本都能听懂对方在说什么，所以延时不会增加多少。
协议握手
下图所展示的就是腾讯视频云在小程序音视频和WebRTC互通问题上所采取的方案：
（1）首先，微信端的小程序通过腾讯视频云SDK将音视频流推送到腾讯云 RTMP 服务器。
（2）其次，腾讯云 RTMP 服务器的会对音视频数据进行初步的转化处理，然后透传给腾讯视频云的实时音视频后台集群。
（3）再次，实时音视频后台会再次将数据交给一个叫做 WebRTC-Proxy 的模块，就在这里， WebRTC-Proxy 要将来自小程序音视频的音视频数据翻译成 WebRTC 理解的“语言”。
（4）最后，在PC上的Chrome浏览器，就可以通过浏览器内置的WebRTC模块跟 WebRTC-Proxy 通讯，进而看到小程序端的视频影像。
（5）上面的四个过程倒过来，就可以实现双向视频通话；而将腾讯视频云作为星型结构的中心节点，多个端（不管是小程序还是Chrome浏览器）都接入进来，那就可以形成多人音视频解决方案。
打通房间逻辑
仅仅完成了音视频数据在小程序和WebRTC之间的握手还远远不够，因为在一次成功的音视频通话背后，不仅仅是把一端的音视频数据传递到另一端这么简单，还有状态的同步和成员间的状态协同。
比如多人视频通话中，涉及到呼叫和接通的流程，其中一方如果挂断了，其他人要收到挂断的通知。同时，如果有新的参与者加入，那么其他人也要收到相应的通知。WebRTC 中有很多组件，比如 RTCPeerConnection 就负责处理网络连接中各种密密麻麻的逻辑细节。但是 WebRTC 的接口中引入的新名词非常多，对于初学者来说还是有一定的门槛，为了简化这里的逻辑，我们引入一个叫做“房间”的概念。
所谓房间（Room），就是把同时参与视频通话的各方圈在一起的一个东西。比如双人通话中，通话中的两个人 A 和 B 就可以认为在一个房间中。再比如在多人通话中，通话中的五个人（A B C D E）也可以认为是在一个房间里。
有了房间的概念，那我们就可以对刚才说的状态协同用两个简单的动作描述一下：如果有一个人加入了视频通话，那么就可以理解为他/她已经进房（EnterRoom）了；如果有一个退出了视频通话，那么就可以理解为他/她已经离开房间（LeaveRoom）了。而房间的门板上始终写着：“目前在房间里有哪几个人”。
有了房间的概念，我们就可以将小程序的两个简单的<live-pusher> 和 <live-player>标签，同 WebRTC 那一套复杂的 API 进行功能上的对齐，我们甚至不需要修改我们在第一版中定义的接口，就可以达成这个目标：
- <live-pusher> 标签：代表房间中的“我”。
- <live-player> 标签：代表房间中的“其他人”。
内部逻辑细节
（1）<live-pusher> 的 url 接口不再传递 rtmp:// 协议的推流地址，而是传递 room:// 协议的推流地址。
（2）<live-pusher> 标签在 start 成功之后，就相当于成功进入一个 room，之后，您可以通过 onPushEvent (PUSH_EVT_ROOM_USERLIST = 1020) 事件，收到房间里还有那些人的信息。在视频通话期间，房间内各个成员的进进出出，也都会通过这个事件通知给您的小程序代码。
（3）ROOM_USERLIST 里每一项都是一个二元组（如果是 1v1 的视频通话，ROOM_USERLIST 里只会有一个人）: userid 和 playurl。 userid 代表是哪个用户， playurl 则是这个用户远程画面的播放地址。您要做的只是使用 <live-player> 标签播放这些远程画面的图像和声音而已。
（4）在 WebRTC 这一端，您可以参考我们的 webrtc API，这套 API 相对于 WebRTC 原生的 API，更适合初学者使用。
呃… 您可能会说：“你这也叫简单呀，我感觉还是要写几十行代码，能不能真的做到像一个标签一样简单呢？”
好吧，其实上面四步是我们第一个版本的接入流程，就在我们昨晚这套方案之后，小程序团队刚好推出了自定义组件的机制，于是，我们有了更好的接入方案。
能不能更简单?
如果您希望一天内就打通 webrtc 和 小程序音视频 的互通，那么我推荐您不要从零开始，因为那会耗费您太多时间去踩坑和 bugfix，推荐您直接使用我们封装好的 <webrtc-room> ，这套方案既可以帮助您完成快速接入，又能满足一定的定制需求。
另外，不要忘记在微信=>发现=>小程序=>腾讯云视频云，体验一下腾讯云官方 Demo 中的 WebRTC 互通效果哦。
<webrtc-room>
功能说明
<webrtc-room> 标签是基于 <live-pusher> 和 <live-player> 实现的用于 WebRTC 互通的自定义组件。用于实现跟 Chrome 和 App SDK 之间的视频通话功能。
版本要求
微信 6.6.6 版本开始支持。
Demo体验
(1) Chrome: 用谷歌浏览器打开 体验页面。
(2) 微信端：发现=>小程序=>搜索“腾讯视频云”，点击 视频通话 页卡，输入相同的房间号。
对接资料
| 源码地址 | 源码说明 |
|---|---|
| 小程序端源码 | Github |
| Chrome端源码 | Github |
属性定义
| 属性 | 类型 | 默认值 | 说明 |
|---|---|---|---|
| template | String | ‘float’ | 必要，标识组件使用的界面模版。 demo中内置 bigsmall，float，grid三种布局 |
| sdkAppID | String | 必要，开通实时音视频服务创建应用后分配的 sdkAppID | |
| userID | String | 必要，用户 ID | |
| userSig | String | 必要，身份签名，相当于登录密码的作用 | |
| roomID | Number | 必要，房间号 | |
| beauty | Number | 0 | 可选， 美颜指数，取值 0 - 9，数值越大效果越明显 |
| whiteness | String | 0 | 可选， 美白指数，取值 0 - 9，数值越大效果越明显 |
| muted | Boolean | false | 可选，true 静音 false 不静音 |
| debug | Boolean | false | 可选，true 打印推流 debug 信息 fales 不打印推流 debug 信息 |
| bindRoomEvent | Function | 必要，监听 <webrtc-room> 组件返回的事件 | |
| enableIM | Boolean | false | 可选，是否启用IM |
| bindIMEvent | Function | 当IM开启时必要，监听 IM 返回的事件 | |
| aspect | String | 9:16 | 可选， 宽高比3:4, 9:16 |
| minBitrate | String | 200 | 可选，最小码率，该数值决定了画面最差的清晰度表现 |
| maxBitrate | String | 400 | 可选，最大码率，该数值决定了画面最好的清晰度表现 |
| autoplay | Boolean | false | 可选，进入房间后是否自动显示远程画面 |
| enableCamera | Boolean | true | 可选，开启\关闭摄像头 |
| pureAudioPushMode | Number | 可选，纯音频推流模式 | |
| recordId | Number | 可选，自动录制时业务自定义id | |
| enableCamera | Boolean | true | 是否开启摄像头 |
| smallViewLeft | String | ‘1vw’ | 小窗口距离大画面左边的距离，只在template设置为bigsmall有效 |
| smallViewTop | String | ‘1vw’ | 小窗口距离大画面顶部的距离，只在template设置为bigsmall有效 |
| smallViewWidth | String | ‘30vw’ | 小窗口宽度，只在template设置为bigsmall有效 |
| smallViewHeight | String | ‘40vw’ | 小窗口高度，只在template设置为bigsmall有效 |
| waitingImg | String | 当微信切到后台时的垫片图片 | |
| loadingImg | String | 画面loading图片 |
操作接口
<webrtc-room> 组件包含如下操作接口，您需要先通过 selectComponent 获取 <webrtc-room> 标签的引用，之后就可以进行相应的操作了。
| 函数名 | 说明 |
|---|---|
| start() | 启动 |
| pause() | 暂停 |
| resume() | 恢复 |
| stop() | 停止 |
| switchCamera() | 切换摄像头 |
| sendC2CTextMsg(receiveUser, msg, succ, fail) | 发送C2C文本消息 |
| sendC2CCustomMsg(receiveUser, msgObj, succ, fail) | 发送C2C自定义消息 |
| sendGroupTextMsg(msg, succ, fail) | 发送群组文本消息 |
| sendGroupCustomMsg(msgObj, succ, fail) | 发送群组自定义消息 |
var webrtcroom = this.selectComponent("#webrtcroomid")
webrtcroom.pause();
事件通知
<webrtc-room> 标签通过 onRoomEvent 返回内部事件，通过 onIMEvent返回 IM 消息事件，事件参数格式如下:
"detail": {
"tag": "事件tag标识，具有唯一性",
"code": "事件代码",
"detail": "对应事件的详细参数"
}
如何快速接入?
上面说了很多细节的技术原理和内部细节，如果您想要快速尝试一下，建议您阅读下面三篇文章就可以了。
<a href="https://cloud.tencent.com/document/product/647/32399" rel="noopener" target="_blank">__一分钟跑通demo__</a>
我们准备了一个简单上手的小程序音视频Demo，输入房间号即可开始通话，这篇文章主要介绍如何把Demo快速地 run 起来。
<a href="https://cloud.tencent.com/document/product/647/32183" rel="noopener" target="_blank">__一分钟集成组件__</a>
这篇文章主要介绍如何快速地将 <webrtc-room> 组件集成到您的小程序工程项目中。
<a href="https://cloud.tencent.com/document/product/647/32226" rel="noopener" target="_blank">__快速调通基本功能__</a>
这篇文档就主要介绍如何二次开发了，它介绍了<webrtc-room> 中主要 API 的使用。
总结
本篇文章主要介绍了小程序音视频和Chrome浏览中重要的WebRTC技术的互通方案，希望能对您的项目开发有所帮助，期待您的反馈。
强力驱动