实时视频直播客户端技术盘点Native、HTML5、WebRTC、微信小程序 _视频直播

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）