实时视频直播客户端技术盘点Native、HTML5、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 协议，如果要和私有协议互通，需要进行协议转换。