概述 本文介绍了微信小程序视音视频和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 有更强的抗弱网能力和更低的卡顿率。 小程序音视频内核 LiteAVSDK 的抗弱网演示 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": "对应事件的详细参数" } [代码] 如何快速接入? 上面说了很多细节的技术原理和内部细节，如果您想要快速尝试一下，建议您阅读下面三篇文章就可以了。 一分钟跑通demo 我们准备了一个简单上手的小程序音视频Demo，输入房间号即可开始通话，这篇文章主要介绍如何把Demo快速地 run 起来。 一分钟集成组件 这篇文章主要介绍如何快速地将 <webrtc-room> 组件集成到您的小程序工程项目中。 快速调通基本功能 这篇文档就主要介绍如何二次开发了，它介绍了<webrtc-room> 中主要 API 的使用。 总结 本篇文章主要介绍了小程序音视频和Chrome浏览中重要的WebRTC技术的互通方案，希望能对您的项目开发有所帮助，期待您的反馈。

小程序中可以使用webview嵌入webrtc实现音视频通话吗？

1. 微信小程序是否支持WebRTC 如果不支持请问是哪里不支持？ 2.微信小程序做多人视频，是否可以使用除了腾讯云以外的第三方sdk？

问题背景： 根据官方文档描述，小程序推流组件live-pusher只能支持rtmp格式地址： [图片] 但实际rtmp传输不安全，在官方的其他文档下，也没有详细说明是否支持加密传输。 问题： 请官方解答一下： 现在推流组件live-pusher在iOS/Android下是否支持rtmps加密数据流？如果支持，对应各个端的兼容版本是什么？如果不支持，详细的支持情况和排期是如何？测试现状： 根据实际在小程序真机测试效果来看，最新版本iOS可以支持使用rtmps推&拉流，但是Android下，显示连接服务器失败，一直是重试状态；

小程序推流组件live-pusher，是否支持rtmps加密的功能

1、名称设置方法 1）小程序名称可以由中文、数字、英文、空格及部分特殊符号组成。长度在4-30个字符之间，一个中文字等于2个字符。 2）公众号、小程序在微信公众平台上的名称是唯一的，且属于同一主体下，可以重名。 3）不得与不同主体的公众号名称重名。   2、简称设置方法 1）小程序简称可以从小程序名称中按顺序截取字符创建。长度在4-10个字符之间，一个中文字等于2个字符。 2）小程序简称在微信公众平台是不唯一的，可以重名。但对于仿冒、侵权等恶意情况，平台仍会做出相关处罚。开发者也可通过侵权投诉维护自己的正当权益。 3）小程序简称设置后，将在客户端任务栏向用户展示。开发者可以凭借此功能，更好地实现产品品牌价值和展示。目前暂不支持名称的其他功能。   3、小程序改名方法 修改方法：登录【微信公众平台小程序】-> 【设置】->【基本信息】->【小程序名称】->【修改】->通过管理员扫码验证后即可进入修改页面，当修改名称命中保护词的时候，需要进一步审核通过方可修改成功，名称修改成功后，原名称会立即释放。 类型  个人  非个人  发布前修改机会  2次  2次  发布后修改机会  2次/年  通过微信认证修改    温馨提示：  1）个人类型的小程序已发布后一自然年内可有2次修改名称的机会。（例：2016年1月1日至2016年12月31日内可修改2次名称） ； 2）同一个主体的小程序和公众号可以同名； 3）若修改名称涉嫌命中保护词的情况，审核时间为7个工作日内。 4）名称修改超过2次小程序要先发布后，再去微信认证，认证过程中会有改名入口，如果小程序未发布，即使小程序去微信认证也不会有改名入口。 [图片] [图片] 4、小程序简称修改方法 修改方法：登录【微信公众平台小程序】-> 【设置】->【基本信息】->【小程序简称】->【修改】->通过管理员扫码验证后即可进入修改页面，当修改简称命中保护词的时候，需要进一步审核通过方可修改成功。 修改频次：发布前修改机会：2次；发布后修改机会：2次/年。 温馨提示：  1）小程序已发布后一自然年内可有2次修改简称的机会。（例：2018年1月1日至2018年12月31日内可修改2次简称）； 2）小程序名称修改期间，简称不可进行修改操作。   5、小程序简称删除方法 删除方法：登录【微信公众平台小程序】-> 【设置】->【基本信息】->【小程序简称】->【修改】->通过管理员扫码验证后进入修改页面 ->不填写输入框，直接【确定】提交->弹窗【确定】 温馨提示：  1）每次小程序简称删除操作也占用一次修改次数； 2）简称删除后，任务栏将展示小程序名称。   6、小程序改名名称释放时间  发布前 小程序名称从A改到B，名称A立即释放。 发布后 帐号改名成功后，原来的名称会有一个2*24小时（即2天）的保护期，在此期间，符合命名唯一规则情况下，只有同一主体下的其他帐号可以使用该名称，主体不一致的，则需要在保护期满后才能申请使用该名称。 7、同一个主体的小程序和公众号可以同名 如果公众号、小程序在微信公众平台上的名称是唯一的，且属于同一主体下，那么它们可以同名。 若小程序名称在审核环节中发现不符合名称命名规则，即使同主体同名，其名称申请亦可能会被驳回，小程序完整的名称规则可具体参照：《微信小程序平台运营规范》2. 基本信息规范 例如：公司A拥有公众号【微信公开课】，同时可申请小程序【微信公开课】，反过来也成立。 8、同一主体下存在多个重名公众号，可以同名 由于历史原因，你可能在早期申请了多个重名公众号，那么你的小程序依旧能申请使用这个名称。 例如：公司A早期申请了多个公众号【微信公开课】（第一个）、【微信公开课】（第二个）、【微信公开课】（第三个）,仍可申请小程序【微信公开课】。 9、不同主体重名公众号，不能同名  要是存在这样一种情况：你和其他一个或多个主体使用相同的公众号名称（由于微信公众平台早期允许），那么这个名称在小程序内就不能被使用。 例如：个人A和公司B同时拥有公众号【张三】，则【张三】的名称在小程序内不可被申请使用。   10、同主体下，名称后缀“+”仍然可用  公众号和小程序名称均不与其他重复的情况下，可支持同主体申请名称添加“+”后缀，这一点对公众号和小程序都适用。 例如：公众号【微信公开课】的主体，支持申请【微信公开课+】小程序。  

原始ID：gh_e506f71acbad 审核订单：16693004976068624991  公司名称：黑龙江省容维证券数据程序化有限公司深圳分公司 提交资料：黑龙江省容维证券数据程序化有限公司的《经营期货证券业务许可证》 审核方：世纪恒通科技股份有限 审核方提供的理由：请提交分公司的《经营期货证券业务许可证》 现实情况：我们公司是 黑龙江省容维证券数据程序化有限公司 直属分公司，按照法律规定并没有法人意义 分公司相当于 黑龙江省容维证券数据程序化有限公司 的一个部门，我们在深圳进行的业务是以总公司的名义进行的 所以深圳公司使用总公司的资质合理而且合法，也有总公司的授权盖章文件 参考法律规定：https://china.findlaw.cn/gongsifalv/gongsishelifa/fengongsisheli/fengongsishelichengxu/1451001.html 现在你们的合作公司的审核人员认为我们公司要找对应的法律法规才可以给我审核通过，但是这个是参考公司法定义的。我们进行的任何商业行为均以总公司名义进行，总公司对我们公司的任何行为需要无限承担责任。 法律并没有规定该证无法给自己的分公司使用，只需要出具相应的授权即可。 希望微信督促该工作人员好好了解法律，我们是客户，不是律师也不是法律的制定者。证监会只会给唯一主体出具该资格证，分公司不具备法人资质。希望他们招人的时候找的水平高一点

我知道可以限制发送的群里的的卡片消息禁止长按转发，但是如果发给个人，他还是可以继续转发。问题是有些机密的业备需求，只需要发给A用户打开看就行，不允许他转发B用户或其他人点击查看使用。所以这种情况下有没有什么办法或接口可以实现的？真的迫切需要这种功能。私密消息应该不仅局限于群，个人与个人间应该也要实现的私密吧，希望官方能尽快升级一下。