连麦直播在各种终端的比较

连麦直播在各种终端的比较

连麦直播的终端主要包括：原生APP、浏览器H5、浏览器WebRTC、微信小程序。浏览器上的应用包括H5和WebRTC，前者可以拉流观看，后者可以实现推流和拉流。

连麦直播移动终端-Native APP

原生APP终端音视频引擎画的结构框图如下，基本包括了音频引擎、视频引擎和网络传输，合称实时语音视频终端引擎。这里还包含底层的音视频采集和渲染，还有网络的输入输出能力，这是操作系统开放的能力。

原生APP有个天然的好处，它是直接和操作系统打交道的，操作系统开放的资源和能力它都可以直接用，比如说音视频的采集渲染，还有网络的输入输出。套用一句时髦的广告语：“没有中间商赚差价”，直接和操作系统对接，可以获得比较好的用户体验。

在原生APP上实现连麦直播的优势是，对上面所说的七个环节有较好的把控，可以获得比较低的延迟，能自研实现语音前处理3A算法，包括回声消

除，还有对抖动缓冲策略和码率自适应的策略都有比较好的把控。另外，可以自主选择使用RTMP协议还是基于UDP的私有协议，对抗弱网环境更加有保障。

市面上比较流行的前处理技术，比如美颜、挂件、变声等，原生APP都可以通过开放前处理接口让开发者实现或者对接这些技术。为什么要强调这个呢？因为浏览器WebRTC和微信小程序都没有开放前处理接口，开发者没有办法自行实现或者对接第三方的美颜或者挂件等技术模块。

在原生APP上，开发者可以得到全面的把控能力，让用户可以获得更好的体验。主流的视频直播平台都有自己的原生APP平台，而浏览器和微信小程序相对来说是辅助的。原生APP的用户体验是最好的，而且对开发者来说也是最可控的。

在原生APP上实现连麦直播的劣势是什么呢？开发门槛高，开发周期长、人力成本高。另外，从获取用户和传播的角度来讲，也没有浏览器和微信小程序那么便利。

连麦直播移动终端-浏览器（H5）

浏览器H5就像一个硬币有两面，有好处也有劣势，好处是开发成本低，容易传播，劣势是只能拉流，不能推流，不能做到多个用户连麦直播。另外，在浏览器H5上延迟也是比较大。如果使用RTMP或者HTTP-FLV，延迟会在1秒到3秒之间，如果用HLS延迟会大于8秒甚至10秒，这么大的延迟就根本就不允许实现连麦直播。

使用这三种协议都是通过浏览器H5中的播放器来播放的。在多主播连麦互动的场景中，一个播放器里面只能播一路视频流，三个主播就得三个播放器，因此看不到多个主播同框连麦互动的情形。如果要看到多个主播同框互动的画面，就必须把多路流混合成一路流，在单个播放器里面播放。

另外，浏览器H5的源代码是开放的。如果在浏览器上把音视频终端引擎实现了，相当于对外公开了所有核心的源代码。因此，还没有见过哪个厂商在浏览器H5上完整地把音视频引擎真正做出来。即使你愿意做出来，浏览器也不会允许你这样做，开发者和操作系统之间隔着浏览器，如果浏览器不把操作系统的核心能力开放给开发者，开发者就不能自主采集和渲染，不能掌控网络输入输出，类似流控码控等功能无法实现。

在浏览器H5中也可以通过websocket来传输，用jsmpeg来播放，视频编解码的格式用mpeg1。mpeg1是一个比较老的媒体格式，所有浏览器都支持。在浏览器中使用jsmpeg播放器播放mpeg1，所有浏览器也可以支持。这么做可以获得比较低的延迟，但是还是无法推流，没办法实现连麦直播。

例子：线上抓娃娃H5版

下面使用即构线上抓娃娃H5版本为例，简单介绍一下websocket在浏览器H5上的应用。从下图左上角可以看到，在浏览器H5终端接入即构实时传输网络时，我们加入了一个视频接入服务器，右边是即构实时传输网络，使用基于UDP的私有协议。通过接入服务器实现协议的转换和媒体格式的转

换：websocket和基于UDP的私有协议的转换，mpeg1和H.264的转换。如果原生APP接入就不需要做转换，虽然有接入服务器，但是不会做转换。

另外，线上抓娃娃的H5版本是没有声音的，除了应用场景的特点要求外，也要用H5实现了音频引擎才能有声音。如果在浏览器H5上实现了音频引擎，就相当于把技术开源了，目前还没有看到哪个厂商这么做。

连麦直播移动终端-浏览器（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也有不足：1）没有开放前处理接口，美颜和挂件这些模块没办法接入第三方的或者自研方案。

2）媒体服务器后端没有实现，开发者要实现媒体服务器，然后通过开源WebRTC网关（比如说janus）接入。