4. 引入小程序音频和视频以及

什么是小程序音视频？

2017年，腾讯视频云团队与微信团队合作，将视频云SDK与微信小程序进行集成，并通过两个标签开放内部功能。通过这两个标签，开发者可以实现在线直播、低延迟监控、双人视频通话、多人视频会议等功能。

关于微信Mini 音视频技术的由来，请阅读此文：《腾讯技术分享：微信小程序音视频技术背后的故事》。

那么它是什么？

Web Real-Time（Web Real-Time）是一种支持网页浏览器实时语音或视频对话的技术，是收购GIPS时获得的技术，无需在浏览器上安装插件，通过它即可编写实时音视频通话程序。

欲了解该项目幕后更多情况，请阅读：《标准之父访谈：过去、现在和未来》。

5.微信小程序音频和视频有什么区别？

如果你和我一样是个实用主义者，那我简单从实用的角度说一下我的结论：音视频小程序已经占领了手机和PC。

如果你对技术更感兴趣，我们可以从多个技术角度列出两者的区别，下面是详细的对比表格：

实现原理：

小程序的音视频是通过在微信中嵌入腾讯视频云，然后通过两个标签来开放SDK内部的音视频能力来实现的。因此小程序的标签起到了开发者API的作用，而内部SDK才是真正用来实现音视频功能的。

它是由 从 GIPS 收购而来（不得不提，我加入腾讯时加入的第一个团队就是这个团队，当时音视频还是从 GIPS 购买的，但因为各种不靠谱，后来就转为自研了），因此其技术被完整保留下来并加入到了浏览器内核中，而最近苹果也开始在自家浏览器中支持相关能力。

底层协议：

小程序中音视频的主要协议是目前直播领域最常用的RTMP流媒体协议和HTTP-FLV播放协议，这两种协议都已经存在很多年了，网上关于它们的资料非常丰富。

底层采用了RTP和RTCP两种数据协议，RTP主要用于音视频数据的传输，而RTCP一般用于控制方面。

移动碎片化问题：

由于小程序的音频和视频都是微信统一实现的，并且微信团队在各个版本都尽量保证功能对齐，否则宁愿不用，所以基本不存在碎片化的问题。

事情到这里就尴尬多了。一方面，系统本身的碎片化让具体表现呈现出“百花齐放”的景象。同时，iOS 目前对内嵌（即微信等 App 内打开的各种内嵌网页）的支持不足，依然是一个非常头疼的问题。

可扩展性：

小程序的音频和视频是随微信版本一起发布的，如果出现问题，通常会修正当前代码流程，然后随下一个版本发布。因此，从建立到最终实现（或解决）一个功能点（比如增加美颜功能）或一个问题点（比如不支持手势缩放），通常只需要一个月的时间。另外，微信APP新版本覆盖速度确实很快。

相比之下，它不是一个团队或一家公司的问题，因为现在已经走的是标准路线，所以每个新特性都先由标准决定，然后再推动浏览器厂商（包括苹果）去遵循。这里面的故事比较多，耗时也比较长。

桌面浏览器支持：

相信大家已经发现，在前面几个问题的分析中，我的观点倾向于音视频的小程序。确实，目前国内移动领域，不是谷歌、苹果说了算，真正说了算的还是微信。

但在桌面浏览器领域，其目前在PC浏览器市场的地位决定了其优势是巨大的，开发者不需要安装插件就可以实现自己想要的功能。

相比之下，由于没有原生的支持，我们如果想在PC上接入小程序音视频，需要安装浏览器插件或者通过://这样的伪协议调用本地exe应用程序（类似在网页上打开聊天窗口）。

6. 微信小程序音频和视频不是零和游戏

小程序音视频和互通并不是一场零和博弈，双方各有优劣。所以本着“打不过就加入”的思路，2018年春节刚过，腾讯视频云团队就启动了小程序音视频和互通的相关工作。

目前需要向各位开发者汇报的是，在微信最新版本中，小程序的音视频已经可以打通，目前在PC浏览器上已经可以与小程序进行实时音视频通讯。

7. 了解自己和敌人，并充分理解他们

就如同结婚一样，既然决定选择另外一个人作为你一生的伴侣，那你一定会先深入了解他/她，比如他的性格，脾气，爱好等方面。

同样，我们要想把小程序的音视频融合好，也要多多了解，这里我就说说我对这个“人”的性格的理解。

首先她虽然长得不怎么样，但是内涵却非常丰富：

说不好看只是比喻，我的意思是学习成本不低，虽然现在有很多通俗易懂的 PPT 教你怎么做，但真正想彻底学会它，还是需要静下心来慢慢把它当成一个你认可的目标去学习。但如果这是你的初恋（也就是你第一次接触实时音视频），你会发现学习的过程本身就是一个了解一门实时音视频技术细节的过程。

其次，她喜欢迁就别人，能够支持各种架构方案：

说 喜欢迁就别人，也是比喻。支持的后端架构有很多（例如 Mesh），而 认为这些后端实现都比较简单，所以它既不开放后端相关的源代码，也不提供统一的后端解决方案。这种开放的设计思路很好，但副作用就是实现成本高昂。在真正的项目落地时，小规模的公司或者开发者很容易被这个技术门槛挡住。尤其是如果想真正应用到企业级解决方案中，面对记录归档这样的刚需，需要花费大量时间进行定制化开发。

8.微信小程序音视频及互通解决方案建立

理解了这些特点之后，我们的互操作性解决方案变得更加清晰：

1）首先小程序音视频的特点就是接口简单，启动快捷，这是小程序的优点；但这恰恰是缺点，所以没必要在小程序侧暴露十几个接口类，而是继续使用小程序音视频和标签来解决问题；

2）其次，官方还没有实现后端，这意味着还有很大的改进空间。腾讯视频云可以实现一个后端，并与小程序音视频使用的 RTMP 后端打通。简而言之，腾讯视频云将扮演小程序音视频和流媒体之间的媒人（或者更确切地说是翻译官）的角色。

但看过《新闻联播》里国家领导人对话的人都知道，这种翻译会影响沟通速度。如果小程序音频和视频互通，中间引入翻译，沟通延迟会不会增加？

其实不会，因为小程序音视频的视频编码标准和常规应用场景下小程序的视频编码标准是一样的，都是H.264标准，音频的格式不一样。这就意味着翻译人员要做的工作很少，双方基本都能听懂对方在说什么，所以延迟不会增加太多。

9.微信小程序音视频握手成功

下图显示了针对该互操作性问题所采用的解决方案：

如上图所示，该互操作方案的原理如下：

1）首先微信小程序通过腾讯视频云SDK将音视频流推送到腾讯云RTMP服务器；

2）其次，腾讯云RTMP服务器会对音视频数据进行初步的转换处理，然后透传到腾讯视频云的实时音视频后端集群；

3）再次，实时音视频后台会再次把数据交给一个叫-的模块，这个模块就是把小程序音视频中传来的音视频数据翻译成人们能听懂的“语言”；

4）最后PC上的浏览器就可以通过浏览器内置的模块跟-进行通信，进而看到小程序的视频图像了；

5）如果将以上四个步骤反过来，就可以实现双向视频通话；而通过以腾讯视频云作为星型结构的中心节点，连接多个终端（无论是小程序还是浏览器），就可以形成多人音视频解决方案。

10.微信小程序音视频及开房间逻辑

仅仅完成小程序与系统之间音视频数据的握手是远远不够的，因为一次成功的音视频通话背后，不只是将音视频数据从一端传送到另一端那么简单，还涉及到成员之间的状态同步、状态协调。

例如在多人视频通话中，涉及到呼叫和接通的过程，如果一方挂断，其他人会收到挂断通知，同时如果有新的参与者加入，其他人也会收到相应的通知。 中有很多组件，比如 ，处理上述逻辑。但是界面中引入了很多新术语，对于初学者来说还是有一定的入门门槛。为了简化这里的逻辑，我们引入了一个叫“房间”的概念。

房间是视频通话中所有参与方聚集在一起的地方。例如，在两人通话中，可以认为 A 和 B 两个人在一个房间中。再例如，在多人通话中，也可以认为五个人（）在一个房间中。

有了房间的概念，我们就可以用两个简单的动作来描述刚才提到的状态协作：如果有人加入视频通话，可以理解为进入了房间（）；如果有人退出视频通话，可以理解为离开房间（）。房间的门板上永远都会写着“目前谁在房间里”。

有了房间的概念，我们就可以把小程序两个简单和标签的功能和复杂的API对齐，甚至不用修改我们在第一个版本定义的接口就可以达到这个目的：

如上图所示，其原理如下：

1）URL接口不再传rtmp://协议的推流地址，而是传room://协议的推流地址，room://协议的使用请参考我们的原理版文档DOC；

2）标签添加成功后，相当于成功进入一个房间，之后你就可以通过（ST=1020）事件收到房间内其他人的信息了。视频通话过程中，房间内各个成员的进出也会通过此事件通知到你的小程序码中；

3） 中的每一项都是一个元组（如果是1v1视频通话，则其中只有一个人）： 和 代表用户， 是用户远程屏幕的播放地址。你需要做的就是使用标签来播放这些远程屏幕的图像和声音；

4）在这方面，您可以参考我们的API，它比原生的API更适合初学者。

11.我们来看看最终的访问效果

如果你想在一天之内就和小程序建立音视频通信，那我建议你不要从头开始，因为那样会浪费你太多的时间去坑。我建议你直接使用我们的套餐方案，它可以帮你完成快速接入，并且满足一定的定制化需求。

本方案最终的接入效果可以在腾讯云官方Demo中的互通效果中通过“微信=>发现=>小程序=>腾讯云视频云”来体验：

标签描述：

标签是基于 和 自定义的互通组件，如果你想直接使用 和 标签完成连接，或者想了解内部原理，可以参考DOC。

版本要求：

微信6.6.6版本起支持。

效果演示：

1）PC端：使用浏览器打开体验页面，体验桌面版的效果；

2）微信：发现=>小程序=>搜索“腾讯视频云”，点击功能卡片，即可体验与桌面版的互通。

连接信息：

1）小程序源码（包括组件源码和demo源码）；

2）PC端源码（API版本访问源码（/.js实现简单的房间管理功能，/.js包含使用API​​的代码））；

3）后端源代码（实现了简单的房间列表功能，并包含了一些生成所需参数的代码）。