即构科技冼牛：微信小程序的视频直播实践
2018 年 4 月 10 日，TGO 鲲鹏会深圳分会会员、即构科技资深技术专家 & 架构师冼牛作为 TGO 鲲鹏会线上分享第六季的嘉宾，以直播的形式分享了实时视频通话和直播技术在微信小程序上的实践。本文根据当天直播内容整理。
大家好，我是 TGO 鲲鹏会深圳分会的会员冼牛。即构科技是实时语音视频云计算服务商，为在线教育、视频会议、视频直播和视频物联网等领域提供音视频通信技术解决方案。今天很荣幸有机会跟大家分享实时视频通话和直播技术在微信小程序上的实践。
实时视频通话：两个或多个人之间，通过语音和视频的方式远程通话；
视频直播：除了上述的情形（多主播之间视频通话）外，还可以让成千上万的观众围观主播之间的视频通话，用户可以和主播连麦通话。
上图是一张典型的视频直播系统架构图，左边框架为低延迟用户服务，右边框架为围观用户服务。左边的主播和连麦观众是从实时网络中拉流观看，享受低延迟体验；右边是通过 CDN 拉流来的围观观众，延迟相对较高。使用 CDN 的好处是可以支撑海量用户并发，同时成本也低。如果我们只看左边的低延迟框架，这就是典型的实时视频通话的系统架构图。
实时视频通话和视频直播的区别包括以下几点：
人数：
视频直播：连麦主播一般不超过三个，用户数从几千到一万不等；
实时视频通话：人数大于或等于两个。即构移动端支持 20 个，PC 端支持 32 个，人数可以继续扩展。
语音：
视频直播：支持人声和音乐；
实时视频通话：支持人声。
延迟
视频直播：场景内的直播端延迟在 300 毫秒左右，观众端延迟在 1- 2 秒；
实时视频通话：比视频直播的延迟更低。采用编码延时更低的编解码器可以直接减少 200 毫秒的延迟。
协议
视频直播：主播端通过 RTMP 协议或基于 UDP 的私有协议推拉流，观众端通过 RTMP 、HTTP-FLV 或 HLS 拉流，低延迟的观众通过 RTMP协议或者基于 UDP 的私有协议从实时网络拉流；
实时视频通话：一般采用基于 UDP 的私有协议，在弱网络环境中会有更好的抗性。
成本
视频直播：采用 CDN 为围观观众分发内容，延迟相对较高，CDN 成本较低；
实时视频通话：采用比较好的网络资源，成本较高，延迟比较低。
远程车险定损：当车辆发生刮碰时，保险公司远程定损可以极大的节省时间和金钱成本；
视频电话报警：这套系统对违法人员具有足够的威慑力，使用方便；
视频会议：视频会议除了在语音、视频方面可以互动外，还会增加白板互动、PPT 屏幕共享；
多方远程会诊：远程会诊更多用在医生与医生之间的远程协同，并不是大家所想的远程看病。
物联网场景包括最近很火的抓娃娃机。上图左边是一台真实的娃娃机，右边是通过手机远程观看和遥控真实的娃娃机。从技术上的角度看，这里包括了视频直播和物联网，把这两个技术结合，就是视频直播在物联网场景中的应用。
物联网场景还包括车联网，允许司机和客服、家人、朋友进行通话。特别是在车辆出现险情时，客服能够通过语音视频了解现场情况，为伤者采取紧急救援行动，同时陪伴伤者渡过难关。上图中的场景是即构科技的一个客户翼卡车联网的应用场景。
在线教育的场景和视频会议场景比较接近，从产品的角度来说比较容易进行平移。这里涉及三个场景：
老师通过连麦、白板、共享屏幕的互动方式，远程教授 10 - 20 个小朋友学习。
所有学员集中到一起，通过远程直播的方式学习、互动。同时，在近端的教室也有一名助教老师来帮助学员学习。
这种场景虽然没有互动，但是盈利能力很强。从技术的角度说，因为通过 CDN 拉流，所以成本比较低。
视频直播和通话技术的核心难点包括三个方面：
为了获得低延迟，我们不仅要把整个流程中的每个环节都进行优化，还要从一开始就要设计超低延迟的架构。在此之上，我们需要思考这五点：
负载均衡。必须确保所有接入服务器达到负载均衡，这样才不会出现服务器在过载时拒绝服务、大量丢包的情况；
就“近”接入。比如从迪拜到北京，虽然看上去直线距离“更近”，但实际上不是，如果直接推拉流是不行的，经常出现掉线。这时借道香港或东京，延迟更低，效果更好，这就是逻辑上的“更近”；
质量评估。网络通话的质量评估有两种方法：第一种是事后评估，第二种是实时 / 动态评估。事后评估：跑一段时间积累数据后，分析这些链路上的网络数据和用户接入数据，评估在哪个时间点接入到哪个服务器走哪条链是最优的，通过这次数据来制定策略，做静态配置；
动态路由。跑一段时间积累数据后，把数据积累做成策略沉淀下来，在运行时动态的根据这些策略动态地选择链路，这就是动态路由；
算法流控。如果网络情况好，就把码率推高，提高清晰度；如果网络情况不好，丢包率增加的时候，把码率降下来，保证可用性、流畅性。
回声消除简单的原理就是把麦克风采集到的回声干掉。回声和用户的声音就像是红墨水和蓝墨水混在一起，是很难分开的。对于系统的算法来说，这两者都是无差别的数字信号。我们需要通过滤波器，以参考信号为输入，尽量逼近模拟回声，然后从麦克风采集到的信号里把回声信号干掉，从而达到回声消除的目的。这一步称作线性处理。
经过线性处理后，如果回声抑制得比较好，说明这是单讲的情况，否则就是双讲的情况。在双讲的情况下，回声消除得不干净，还需要做非线性处理，把剩余的回声信号一点一点地消除掉。如果回声消除过得过分，无可避免地会伤害到有效的声音。市场上有两种做法：
宁愿多留些回声也不要伤害有效的声音；
宁愿伤害到有效的声音，也要把回声消除干净。
数据包的延迟有时大，有时小，这就是网络抖动。为了消除网络抖动，要在接收端维护抖动缓冲区。抖动缓冲区的长度实质就是延迟时间，所以不能太长，也不能太短。如果太长，延迟就会较大；如果太短，抖动就会显现出来。有厂商采用延迟的最大方差作为抖动缓冲队列的长度，接受端也通过抖动缓冲评估发送端发送数据包的最佳时间间隔，然后告诉发送端。
去年 12 月 26 日，微信小程序正式对外开放实时音视频能力，开放的类目包括社交、教育、医疗、政务民生和金融。
上图是我画的两个维度 —— 横坐标是刚需和非刚需应用，纵坐标是高频和低频的应用。如果是高频而且刚需的应用，用户的粘性很高，最终都会沉淀到原生 APP 上，因为原生 APP 的体验最好，对运营方来说也完全可控。
这种情况下，微信小程序对运营方的意义就是拉新的流量入口，最终用户还是会被引流到原生 APP 上。如果是低频或者非刚需，用户偶尔用一次，希望使用的门槛低，即用即走，用户往往会更加倾向于使用微信小程序，而不是安装一个原生 APP 。这种情况下，微信小程序对运营方的意义就是用户的重要入口和运营的重要阵地。
微信小程序技术基本包括三块：
View（视图层），包括 WXML 和 WXSS 。WXSS 对应 H5 的 CSS ，WXML 对应 HTML ；
App Service（逻辑层）：使用 JS 来构建业务逻辑。逻辑层的 JS 和视图层的 WXML & WXSS 和 H5 的技术栈十分接近，这也是为了让前端开发的技术人员能够很快的上手，降低学习和人力的成本；
Native（系统层）：通过 JS Bridge 向上提供微信的原生能力，通过 Event 和 Data 做双向交互。
刚刚提到的微信小程序开放的两个标签（ Live-pusher 推流端和 Live-player 拉流端），他们都有两种运作模式 —— RTC 模式和 Live 模式。在进行视频通话或者连麦直播的情况下，使用 RTC 模式；在视频直播的观众端采用 Live 模式。
微信小程序的音视频技术主要分为三个部分：
小程序源码，通过和两个组件提供音视频能力；
JSBridge 基础库，向上提供小程序的基础能力；
最底层是音视频组件，包括音频引擎，视频引擎，传输引擎，还有两个标签对应的两个组件：CTX LivePlayer 和 CTX LivePusher 。
通过微信小程序的音视频能力可以实现连麦直播和视频通话，那么不通过微信小程序的音视频能力是否可以做到呢？答案是：可以做到。市面上有一种基于 WebRTC 的方案就是很好的例子。
这个方案利用了微信小程序最近推出的 WebView 组件来承载基于 WebRTC 的应用。小程序的 WebView 是否支持 WebRTC 呢？我的答案是：支持，也不支持。
WebView 在安卓端支持 WebRTC ，在 IOS 端不支持 WebRTC ，而且在安卓端的 WebView 还不是完整的浏览器，所以功能会受限。因此，这个方案虽然讨巧地借用 WebView 来承载基于 WebRTC 方案，但它也带来下面几个问题：
只能在安卓端使用，在 iOS 上不能用；
WebView 不是完整的浏览器，存在很多限制；
WebRTC 运行于 WebView 内，和操作系统之间存在多层抽象和消耗；
没有真正使用小程序音视频的能力；
那么，如何才能真正地利用上小程序的音视频能力，来实现视频通话或者连麦直播呢？要知道，小程序只提供终端上的能力，没有实现媒体服务器，因此要自己开发媒体服务器端或接入第三方的服务器，来实现多人连麦直播或者视频通话。
我们以即构科技的连麦直播方案为例。即构的实时通信网络支持两种传输协议：RTMP 协议和基于 UDP 的私有协议。那么，把小程序接入到实时通信网络有两种方法：
小程序支持 RTMP 协议，可以直接接入到即构实时通信网络，采用 RTMP 协议；
通过即构 ZEGO 接入服务器，把小程序支持的 RTMP 协议转成即构的基于 UDP 的私有协议，另外还要进行媒体格式转换等。通过接入服务器，即构的方案支持小程序和原生 APP ，WebRTC 终端互通连麦。
通过接入即构实时通信网络，有两大好处：
超低延迟。通过智能选路，动态回源等实时传输和分发技术，即构的实时通信网络即使在跨国、跨网和弱网环境下，都可以稳定地获得超低的延迟；
海量并发。即构的实时通信网络得益于即构团队在 QQ 上积累的经验。可以支持海量用户的并发，支持超多人（最多 32 ，可扩展）在同一房间通话。
上图展示了小程序和 WebRTC 互通连麦的架构图。左边是小程序，右下方是 WebRTC 终端。后者通过接入层 proxy gateway 接进来，WebRTC 的 SRTP 转成即构的传输协议，媒体格式也会做相应的转换来适配。
WebRTC 网关服务器有很多开源的方案，比如 Licode 、Janus 或 Kurento 。即构团队经过深入研究这些开源方案后，放弃了采用开源的 WebRTC 网关，而自行研发了自己的 WebRTC 网关服务器。
上面分享了如何在微信小程序上实现连麦直播或视频通话，同时将连麦直播技术覆盖到原生 APP 和 WebRTC 浏览器上。因此，我把原生 APP 、微信小程序、WebRTC 浏览器、以及最近推出的快应用都列在了上图，在几个方面进行了对比。
原生 APP 作为体验良好的终端，将会继续保持重要地位；微信小程序和浏览器 WebRTC 由于易传播和开发成本低的优点，在未来也将会快速发展；快应用是最近手机厂商联合推出的，它的发展情况和前景还有待观察。
以上是我今天的分享内容。谢谢大家。