腾讯技术分享:微信小程序音视频与WebRTC互通的技术思路和实践
4.介绍小程序的音频和视频以及
什么是小程序音视频?
2017年,腾讯视频云团队与微信团队强强联手,将视频云SDK与微信小程序集成,并以两个标签的形式开放内部功能。 通过这两个标签,开发者可以实现在线直播、低延时监控、两人视频通话、多人视频会议等功能。
关于微信小视频音视频技术的由来,请阅读这篇文章:《腾讯技术分享:微信小程序音视频技术背后的故事》。
那么它是什么?
(Web Real-Time),是一种支持网络浏览器进行实时语音对话或视频对话的技术。 它是收购GIPS后获得的一项技术。 它可以编写实时音频和视频,无需在浏览器上安装插件。 调用程序。
有关幕后的更多信息,请阅读:标准之父访谈:过去、现在和未来。
5.微信小程序音频和视频有什么区别?
如果你和我一样是一个实用主义者,那么我就简单地从实用主义的角度陈述一下我的结论:小程序的音视频已经照顾到了手机和PC。
如果你对技术更感兴趣,那么我们可以从多个技术角度列出两者的区别。 以下为详细对比表:
实现原理:
小程序的音视频是通过将腾讯视频云嵌入到微信中来实现的,然后通过两个标签来开放SDK内部的音视频能力。 因此,小程序的标签扮演的是开发者API的角色,而内部的SDK才是真正用来实现音视频功能的。
从收购GIPS获得的(这里不得不提一下,我加入腾讯时第一个所在的团队就是团队,当时的音视频产品都是从GIPS购买的,但由于各种不靠谱,后来就被淘汰了)转为自主开发路线)。 因此,其技术被完整保留并添加到浏览器内核中。 而最近苹果也开始在浏览器中支持相关功能。
底层协议:
小程序的主要音视频协议有直播领域最常用的RTMP流媒体协议和HTTP-FLV播放协议。
底层使用RTP和RTCP两种数据协议,其中RTP主要用于音视频数据传输,而RTCP一般用于控制。
移动碎片问题:
由于小程序的音视频都是微信统一实现的,而且微信团队尽量要求各个版本功能对齐,否则宁可不可用,所以碎片化的问题基本不存在。
这里就尴尬多了。 一方面,系统本身的碎片化使得具体表现呈现出“百花齐放”的景象。 支持也是一个问题。
可扩展性:
小程序的音频和视频是跟随微信版本发布的。 如果出现问题,一般都会修正当前的代码流程,然后随下一个版本一起发布,所以一般一个功能点(比如增加美颜功能)或者一个问题点(比如不支持)只需要一个月的时间从建立到最终实现(或解决方案),新版微信APP的覆盖速度确实很快。
相比之下,这不是一个团队或一个公司的问题,因为它已经走标准路线了,所以每一个新功能都是先确定标准,然后推动浏览器制造商(包括苹果)遵循。 这里的故事比较多,时间也比较长。
桌面浏览器支持:
相信大家已经发现了,在前面几个问题的分析中,我的观点是倾向于小程序的音视频的。 确实,在目前的国内移动领域,谷歌和苹果都无法说了算,真正说了算的还是微信。
但在桌面浏览器部分,目前在PC浏览器市场的地位决定了优势。 开发者无需安装插件即可实现自己想要的功能。
相比之下,由于没有原生支持,如果我们想要连接PC上小程序的音视频,我们需要安装浏览器插件或者通过像://这样的伪协议来调用本地的exe应用程序。开始(类似于打开聊天窗口)。
6、微信小程序音视频融合不是零和游戏
小程序音视频和括号不是零和游戏。 双方都有各自的优点和缺点。 因此快手直播伴侣电脑版使用教程,本着“如果你打不过他们,就加入他们”的理念,腾讯视频云团队在2018年春节归来后就马不停蹄地开始了小程序音视频相关工作和相互沟通。
目前需要向各位开发者汇报的是,在最新版本的微信中,小程序的音视频已经可以与小程序进行对接了。 目前与小程序的实时音视频交换可以在PC的浏览器上进行。
7、知己知彼,充分了解
就像结婚一样,既然你决定选择另一个人作为你的一生伴侣,那么你首先要深入了解他,比如性格、脾气、爱好等各方面。
同样的,我们想要打通小程序的音频和视频,就必须要多学点。 这里我就谈谈我对这个“人”的性格的理解。
首先,她虽然长得不是很好看,但是很有内涵:
说不好看只是我的一个比喻。 我的意思是学习成本不低。 虽然我做了很多通俗易懂的PPT来教大家如何入门,但是如果你真的想彻底学好,还是需要静下心来,慢慢地向她学习,作为你认可的目标。 但如果你是第一次恋爱(也就是第一次接触实时音视频),你会发现学习的过程本身就是一个了解实时音视频技术细节的过程。音频和视频。
其次,她非常喜欢迁就别人,她可以支持各种架构方案:
也是比喻说我喜欢迁就别人,而且它支持很多后台架构(比如Mixer、Mesh、),而认为这些后台实现都比较简单,所以它既没有开放相关源码到后台,也没有提供统一的后台解决方案。 这种开放式的设计思想很好,但是副作用就是实现成本高。 当真正的项目上线时,规模较小的公司或开发商很容易被这个技术门槛挡住。 尤其是想要真正应用到企业级解决方案中,面对记录和归档的硬性要求,需要花费大量的时间进行定制开发。
8、微信小程序音视频及互通解决方案建立
了解了这些特点之后,我们的互通方案就比较清晰了:
1)首先,音视频小程序的特点是界面简单,使用快捷,这是小程序的优势; 而这恰恰是小程序的缺点,所以我们不需要在小程序端暴露十多个接口类,而是继续使用小程序音视频和标签来解决问题;
2)其次,后台还没有正式实现,这意味着这里还有很大的发展空间。 腾讯视频云可以实现一个后台,与小程序音视频使用的RTMP后台对接。 简单来说,腾讯视频云将扮演小程序音视频之间的媒人(更准确地说是翻译者)的角色。
但看过《新闻联播》国家领导人谈话片段的人都知道,这种翻译会影响沟通速度。 小程序的音频和视频互相通信,中间引入了一个翻译器。 通讯延迟会增加吗?
其实不是,因为常见应用场景下小程序和视频的音视频编码标准是一致的,都是H.264标准,只是音频格式不同。 这意味着翻译者要做的事情很少,双方基本都能听懂对方在说什么,因此延迟不会增加太多。
9、微信小程序音视频握手成功
下图展示了针对此互操作问题所采用的解决方案:
如上图所示,该互通方案原理如下:
1)首先微信小程序通过腾讯视频云SDK将音视频流推送到腾讯云RTMP服务器;
2)其次,腾讯云RTMP服务器会对音视频数据进行初步的转换处理,然后透传到腾讯视频云的实时音视频后台集群;
3)同样,实时音视频后台会再次将数据交给一个叫-Proxy的模块。 这里,-Proxy会将小程序的音视频中的音视频数据翻译成可以理解的“语言”;
4)最后PC上的浏览器可以通过浏览器内置模块与-Proxy通信,进而看到小程序的视频图像;
5)通过颠倒以上四个过程,即可实现双向视频通话; 而如果以腾讯视频云作为星型结构的中心节点,将多个终端(无论是小程序还是浏览器)接入进来,那么就可以形成多人音视频解决方案。
10.微信小程序音视频及开房逻辑
仅仅完成小程序与小程序之间音视频数据的握手是不够的,因为一次成功的音视频通话背后,不仅仅是将音视频数据从一端传输到另一端那么简单,也是成员之间的状态同步和状态协调。
例如,在多人视频通话中,涉及到呼叫和接通的过程。 如果其中一方挂断,其他方将收到挂断通知。 同时,如果有新的参与者加入,其他人也应该收到相应的通知。 里面有很多组件,比如处理申诉的各种逻辑。 但界面中引入了很多新术语,对于初学者来说还是有一定的入门门槛。 这里为了简化逻辑,我们引入一个概念,叫做“房间”。
所谓房间(Room),就是同时包围参与视频通话的各方的东西。 例如,在两人通话中,通话中的两个人A和B可以认为是在同一个房间。 再比如多人通话中快手直播伴侣电脑版使用教程,通话中的五个人(ABCDE)也可以认为是在一个房间。
有了房间的概念,我们就可以用两个简单的动作来描述刚才提到的状态协作:如果有人加入视频通话,可以理解为他/她进入了房间(); 如果有人退出视频通话,则认为他/她已离开房间()。 而房间的门板上永远写着:“目前房间里有哪些人”。
有了房间的概念,我们就可以在功能上将小程序的两个简单和标签与一组复杂的 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)后台源码(实现了一个简单的房间列表功能,还包含了几个所需参数的生成代码)。
共有 0 条评论