1、媒介

2017 年 12 月，微信小程序向开发者开放了及时音视频本领，给业内带来广阔的想象空间。连麦互动视频直播技术在 2016 年直播风口中成为视频直播的标配，然而只有在原生的 APP 上才气保障良好的用户体验。
当时候，在微信小程序中无法举行及时音视频互动。微信小程序在客岁 12 月公布开放及时音视频本领，再加上客岁 6 月苹果公布即将支持 WebRTC，业内一下子千树万树梨花开，出息一片光明。
连麦互动直播技术和微信小程序以及 WebRTC 能产生怎么样的化学作用？开发者在微信小程序或者欣赏器 WebRTC 上实现连麦互动直播技术的时候，须要知道什么和考虑什么？
连麦视频直播的客户端主要包括：原生 APP、欣赏器 H5、欣赏器 WebRTC、微信小程序。欣赏器上的应用包括 H5 和 WebRTC，前者可以拉流观看，后者可以实现推流和拉流。

2、视频直播客户端技术之Native APP

原生 APP 终端音视频引擎的结构框图如下，根本包括了音频引擎、视频引擎和网络传输，合称及时语音视频终端引擎。这里还包罗底层的音视频采集和渲染，还有网络的输入输出本领，这是使用系统开放的本领。

原生 APP 有个天然的利益，它是直接和使用系统打交道的，使用系统开放的资源和本领它都可以直接用，好比说音视频的采集渲染，还有网络的输入输出。套用一句时髦的广告语：“没有中间商赚差价”，直接和使用系统对接，可以获得比力好的用户体验。
在原生 APP 上实现连麦直播的上风是，对上面所说的七个环节有较好的把控，可以获得比力低的耽误，能自研实现语音前处置惩罚 3A 算法，包括回声消除，还有对抖动缓冲策略和码率自顺应的策略都有比力好的把控。另外，可以自主选择使用 RTMP 协议照旧基于 UDP 的私有协议，对抗弱网情况更加有保障。
市面上比力盛行的前处置惩罚技术，好比美颜、挂件、变声等，原生 APP 都可以通过开放前处置惩罚接口让开发者实现或者对接这些技术。为什么要强调这个呢？因为欣赏器 WebRTC 和微信小程序都没有开放前处置惩罚接口，开发者没有办法自行实现或者对接第三方的美颜或者挂件等技术模块。
在原生 APP 上，开发者可以得到全面的把控本领，让用户可以获得更好的体验。主流的视频直播平台都有本身的原生 APP 平台，而欣赏器和微信小程序相对来说是辅助的。原生 APP 的用户体验是最好的，而且对开发者来说也是最可控的。
在原生 APP 上实现连麦直播的劣势是什么呢？开发门槛高，开发周期长、人力成本高。另外，从获取用户和流传的角度来讲，也没有欣赏器和微信小程序那么便利。

3、视频直播客户端技术之欣赏器（HTML5）

欣赏器 H5 就像一个硬币有两面，有利益也有劣势，利益是开发成本低，轻易流传，劣势是只能拉流，不能推流，不能做到多个用户连麦直播。另外，在欣赏器 H5 上耽误也是比力大。假如使用 RTMP 或者 HTTP-FLV，耽误会在 1 秒到 3 秒之间，假如用 HLS 耽误会大于 8 秒甚至 10 秒，这么大的耽误就根本就不答应实现连麦直播。
使用这三种协议都是通过欣赏器 H5 中的播放器来播放的。在多主播连麦互动的场景中，一个播放器内里只能播一起视频流，三个主播就得三个播放器，因此看不到多个主播同框连麦互动的情况。假如要看到多个主播同框互动的画面，就必须把多路流混淆成一起流，在单个播放器内里播放。
另外，欣赏器 H5 的源代码是开放的。假如在欣赏器上把音视频终端引擎实现了，相当于对外公开了所有核心的源代码。因此，还没有见过哪个厂商在欣赏器 H5 上完备地把音视频引擎真正做出来。即使你乐意做出来，欣赏器也不会答应你如许做，开发者和使用系统之隔断着欣赏器，假如欣赏器不把使用系统的核心本领开放给开发者，开发者就不能自主采集和渲染，不能掌控网络输入输出，雷同流控码控等功能无法实现。
在欣赏器 H5 中也可以通过 websocket 来传输，用 jsmpeg 来播放，视频编解码的格式用 mpeg1。
mpeg1 是一个比力老的媒体格式，所有欣赏器都支持。在欣赏器中使用 jsmpeg 播放器播放 mpeg1，所有欣赏器也可以支持。这么做可以获得比力低的耽误，但是照旧无法推流，没办法实现连麦直播。

4、视频直播客户端技术之欣赏器（WebRTC）

大家大概会以为很遗憾，欣赏器 H5 固然很轻易流传，开发简朴但是体验欠佳，不能连麦直播。那么在欣赏器上能不能推流，能不能实现连麦直播呢？答案是可以的，那就要用到 WebRTC。
这里说的 WebRTC 是指已经被内嵌到欣赏器内里，被欣赏器支持的 WebRTC，而不是 WebRTC 的源代码。部门主流欣赏器内嵌了 WebRTC，对开发者开放了欣赏器的及时音视频本领。
上图是 WebRTC 的结构图。我们可以看到 WebRTC 包括了音频引擎，视频引擎、传输引擎等，最底层的虚线框表示可以重载，也就是说欣赏器把最底层的音视频渲染和网络传输的底层本领开放给开发者，开发者可以根据本身的需求选择是否举行重载。音频引擎中，包括了两个编解码器：iSAC 和 iLBC，前者针对宽带和超宽带的音频编解码，后者针对窄带音频编解码。
音频引擎还包括了音频抖动缓冲，回声消除和噪音克制模块等。抖动缓冲中的 NetEQ 算法可以说是 WebRTC 内里的精华之一。
视频引擎中，包括了 VP8 和 VP9 的视频编解码器，甚至是即将到来的 AV1。视频引擎还包括视频抖动缓冲和图像质量增强等模块。传输引擎，WebRTC 使用的是 SRTP（Secured Realtime Transport Protocol）安全及时传输协议。
最后，WebRTC 接纳 P2P 的通讯方式，没有媒体服务器等后端的实现。以上是 WebRTC 的简朴先容。
欣赏器 WebRTC 一般的上风和劣势这里就不再重复，请大家自行百度，这里只说重点。欣赏器 WebRTC 的利益就是实现了相对完备的音视频终端引擎，答应在欣赏器上推流，可以实现连麦直播。
然而，欣赏器 WebRTC 也有不足：

• 没有开放前处置惩罚接口，美颜和挂件这些模块没办法接入第三方的或者自研方案；
• 媒体服务器后端没有实现，开发者要实现媒体服务器，然后通过开源 WebRTC 网关（好比说 janus）接入；
• 编解码器、抖动缓冲和语音前处置惩罚 3A 等本领只能依靠 WebRTC，不能自行定制化；
• 部门主流欣赏器是不支持 WebRTC 的，特别是苹果的欣赏器。固然说客岁苹果公布支持 WebRTC, 但是目前 iOS Safari 最新版本对 WebRTC 的支持并不好，iOS Safari 的主流版本并不支持 WebRTC，在 iOS 上面微信欣赏器也是不支持 WebRTC 的。

由于 WebRTC 不提供媒体服务器的实现，因此须要把欣赏器 WebRTC 接入到媒体服务器后端，这个可以是自研的，也可以是第三方的服务。欣赏器 WebRTC 和媒体服务器后端之间的协议和媒体格式是不一样的，因此要做协议和格式的转换。WebRTC 用的基于 UDP 的 SRTP，须要把它转换成媒体服务器的基于 UDP 的私有协议。另外，媒体格式也须要转换，因为 WebRTC 中语音视频格式默认用的是 VP8 或者 VP9。同时及时传输网络中有关信令调理也须要做一些调解。欣赏器 WebRTC 和媒体服务器后端之间的接入层也可以采用开源的 WebRTC Gateway（好比说 janus）来实现。
欣赏器是雷同使用系统的一种超等应用，它坐拥重要的流量入口，然而它也是开发者和使用系统之间的“中间商”。开发者通过 WebRTC 获得欣赏器开放的及时音视频本领，然而也必须要蒙受 WebRTC 带来的痛楚。

5、视频直播客户端技术之微信小程序

微信小程序是什么？是跑在微信上面的轻型应用。微信是什么？是类使用系统的超等应用。这些特性和欣赏器以及 H5 是不是很靠近？H5 是欣赏器支持的轻型应用，而欣赏器是类使用系统的超等应用。欣赏器背后是各大国际科技巨头，不像微信如许背后只有腾讯一个互联网巨头。因此，从这个角度来看，微信小程序、欣赏器 WebRTC 和 H5 是有相通之处的。
微信小程序可以类比为欣赏器 H5 那样的客户端和服务器的结构。此中 HTML 对应微信小程序的 WXML，CSS 对应小程序的 WXSS，小程序的脚本语言和 JS 是一样的，只是框架不一样。微信小程序提供了两个标签，一个是<live-pusher>，一个是<live-player>。<live-pusher>就是推流，<live-player>就是拉流，可以实现单向直播或者连麦直播。小程序提供两种模式：LIVE 和 RTC，LIVE 支持单向直播，RTC 支持低耽误的连麦直播。目前微信小程序推流采用 RTMP 协议，假如要和私有协议互通，须要举行协议转换。

微信小程序开放了及时音视频本领，对业界来说是庞大利好。然而，根据上面的信息和逻辑，我们也看到采用微信小程序实现连麦互动直播的利益和不足。
利益有三点：

• 1）开发成本低，开发周期短，根本和 H5 的开发难度差不多；
• 2）很轻易流传和获客，充实使用好微信的优质流量；
• 3）可以推流和拉流，答应实现连麦直播和及时语音视频通话。

不足有四点：

• 1）你会受制于微信小程序的及时音视频本领，好比说，假如它的回声消除有某些题目，你只能等微信团队按照本身的节奏来优化，而本身没有任何办法去优化；
• 2）小程序没有开放前处置惩罚接口，只能使用小程序自带的美颜或者变声功能（假如有），不能对接自行研发或者第三方的美颜或者变声模块；
• 3）通过 RTMP 协议推流和拉流，不能和基于 UDP 的私有协议互通连麦。假如要实现和基于 UDP 的私有协议互通连麦，就必须要增长接入层来转换协议格式甚至媒体格式；
• 4）没有实现后端媒体服务器，开发者必须要自行实现媒体服务器，或者把微信小程序接入到第三方的及时通讯网络。

欣赏器通过 WebRTC 开放了欣赏器的及时音视频本领，而微信通过小程序开放了微信的及时音视频本领，在两个类使用系统的平台上答应开发者去实现连麦直播和及时音视频通话。然而，无论 WebRTC 照旧小程序只是在终端上带你入门，对开发者来说，要真正实现整套系统，还有许多工作须要做的。
假如要将微信小程序接入及时音视频传输网络，中间得有接入服务器，我们叫接入层。在接入层我们须要做协议的转换，好比说，假如及时音视频传输网络是使用基于 UDP 的私有协议，那么要把 RTMP 协议转为基于 UDP 的私有协议。还有媒体格式的转换，假如和及时传输网络的媒体格式不一样，还须要举行转换。

6、视频直播客户端技术之WebRTC 通过WebView接入小程序

还有别的方法在小程序上做连麦直播互动吗？必须要使用微信小程序开放的语音视频本领吗？也不一定。下图展示了我在市面上看过的一个技术方案，它绕过了微信小程序及时语音视频本领，通过微信小程序 WebView 组件实现了连麦直播的方案。这里和大家分享一下。

这个方案的根本思路是使用 WebView 的欣赏器特点，在 WebView 内使用 WebRTC 的 Web API，从而在小程序上获得及时音视频本领。上图是这个方案的架构图。最底层是微信小程序的基础本领。上一层是 WebView，微信小程序的 WebView 雷同欣赏器，那么就大概会支持 WebRTC。然而必须要留意到，微信小程序的 WebView 在安卓平台上支持 WebRTC，但在 iOS 平台上面不支持 WebRTC。
固然这个方案理论上也能在微信小程序上实现连麦直播，但是它有以下的局限性：

• 1）在 iOS 平台上，微信小程序不支持这个方案，上面已经说过；
• 2）小程序 WebView 不是完备的欣赏器，要比平凡欣赏器表现差而且有许多的限制；
• 3）开发者和使用系统之隔断了好几层：微信底层，小程序，WebView，WebRTC，然后才是开发者的小程序应用。每一层的抽象都会带来性能上的斲丧，都会影响到最终的体验。

这个方案本质上照旧一个基于 WebRTC 的解决方案，没有用到微信小程序开放的及时音视频本领，而是快速地借助 WebView 组件，剑走偏锋，非常讨巧地在微信小程序里使用了 WebRTC。

7、本文小结

连麦直播技术渐渐在原生 APP, 欣赏器 H5，欣赏器 WebRTC，微信小程序上延伸，衍生出更加丰富的生态，提供更加便捷和良好的用户体验，对视频直播平台和用户来说是好消息。然而，欲带皇冠，必承其重。特别是在欣赏器 WebRTC 和微信小程序上，开发者要充实明白这些范例终端的特点和局限，才气更好地在上面使用连麦直播技术举行创新，服务用户。

喜好的朋侪可以后台私信【1】获取学习视频

附上一份音视频学习课程大纲给大家