当前位置 :主页 > 直播 >

即构科技冼牛:微信小程序的视频直播实践

* 来源 :http://www.jamielwallace.com * 作者 : * 发表时间 : 2018-06-07 23:00 * 浏览 :

  2018 年 4 月 10 日,TGO 鲲鹏会深圳分会会员、即构科技资深技术专家 & 架构师冼牛作为 TGO 鲲鹏会线上分享第六季的嘉宾,以直播的形式分享了实时视频通话和直播技术在微信小程序上的实践。本文根据当天直播内容整理。

  大家好,我是 TGO 鲲鹏会深圳分会的会员冼牛。即构科技是实时语音视频云计算服务商,为在线教育、视频会议、视频直播和视频物联网等领域提供音视频通信技术解决方案。今天很荣幸有机会跟大家分享实时视频通话和直播技术在微信小程序上的实践。

  上图是一张典型的视频直播系统架构图,左边框架为低延迟用户服务,右边框架为围观用户服务。左边的主播和连麦观众是从实时网络中拉流观看,享受低延迟体验;右边是通过 CDN 拉流来的围观观众,延迟相对较高。使用 CDN 的好处是可以支撑海量用户并发,同时成本也低。如果我们只看左边的低延迟框架,这就是典型的实时视频通话的系统架构图。

  视频直播:主播端通过 RTMP 协议或基于 UDP 的私有协议推拉流,观众端通过 RTMP 、HTTP-FLV 或 HLS 拉流,低延迟的观众通过 RTMP协议或者基于 UDP 的私有协议从实时网络拉流;

  实时视频通话:一般采用基于 UDP 的私有协议,在弱网络中会有更好的抗性。

  物联网场景包括最近很火的抓娃娃机。上图左边是一台真实的娃娃机,右边是通过手机远程观看和遥控真实的娃娃机。从技术上的角度看,这里包括了视频直播和物联网,把这两个技术结合,就是视频直播在物联网场景中的应用。

  物联网场景还包括车联网,允许司机和客服、家人、朋友进行通话。特别是在车辆出现险情时,客服能够通过语音视频了解现场情况,为伤者采取紧急救援行动,同时陪伴伤者渡过。上图中的场景是即构科技的一个客户翼卡车联网的应用场景。

  在线教育的场景和视频会议场景比较接近,从产品的角度来说比较容易进行平移。这里涉及三个场景:

  老师通过连麦、白板、共享屏幕的互动方式,远程教授 10 - 20 个小朋友学习。

  所有集中到一起,通过远程直播的方式学习、互动。同时,在近端的教室也有一名助教老师来帮助学习。

  这种场景虽然没有互动,但是盈利能力很强。从技术的角度说,因为通过 CDN 拉流,所以成本比较低。

  为了获得低延迟,我们不仅要把整个流程中的每个环节都进行优化,还要从一开始就要设计超低延迟的架构。在此之上,我们需要思考这五点:

  负载均衡。必须确保所有接入服务器达到负载均衡,这样才不会出现服务器在过载时服务、大量丢包的情况;

  就“近”接入。比如从迪拜到,虽然看上去直线距离“更近”,但实际上不是,如果直接推拉流是不行的,经常出现掉线。这时借道或东京,延迟更低,效果更好,这就是逻辑上的“更近”;

  质量评估。网络通话的质量评估有两种方法:第一种是事后评估,第二种是实时 / 动态评估。事后评估:跑一段时间积累数据后,分析这些链上的网络数据和用户接入数据,评估在哪个时间点接入到哪个服务器走哪条链是最优的,通过这次数据来制定策略,做静态配置;

  动态由。跑一段时间积累数据后,把数据积累做成策略沉淀下来,在运行时动态的根据这些策略动态地选择链,这就是动态由;

  算法流控。如果网络情况好,就把码率推高,提高清晰度;如果网络情况不好,丢包率增加的时候,把码率降下来,可用性、流畅性。

  回声消除简单的原理就是把麦克风采集到的回声干掉。回声和用户的声音就像是红墨水和蓝墨水混在一起,是很难分开的。对于系统的算法来说,这两者都是无差别的数字信号。我们需要通过滤波器,以参考信号为输入,尽量逼近模拟回声,然后从麦克风采集到的信号里把回声信号干掉,从而达到回声消除的目的。这一步称作线性处理。

  经过线性处理后,如果回声得比较好,说明这是单讲的情况,否则就是双讲的情况。在双讲的情况下,回声消除得不干净,还需要做非线性处理,把剩余的回声信号一点一点地消除掉。如果回声消除过得过分,无可避免地会到有效的声音。市场上有两种做法:

  数据包的延迟有时大,有时小,这就是网络抖动。为了消除网络抖动,要在接收端抖动缓冲区。抖动缓冲区的长度实质就是延迟时间,所以不能太长,也不能太短。如果太长,延迟就会较大;如果太短,抖动就会出来。有厂商采用延迟的最大方差作为抖动缓冲队列的长度,接受端也通过抖动缓冲评估发送端发送数据包的最佳时间间隔,然后告诉发送端。

  去年 12 月 26 日,微信小程序正式对外实时音视频能力,的类目包括社交、教育、医疗、政务民生和金融。

  上图是我画的两个维度 —— 横坐标是刚需和非刚需应用,纵坐标是高频和低频的应用。如果是高频而且刚需的应用,用户的粘性很高,最终都会沉淀到原生 APP 上,因为原生 APP 的体验最好,对运营方来说也完全可控。

  这种情况下,微信小程序对运营方的意义就是拉新的流量入口,最终用户还是会被引流到原生 APP 上。如果是低频或者非刚需,用户偶尔用一次,希望使用的门槛低,即用即走,用户往往会更加倾向于使用微信小程序,而不是安装一个原生 APP 。这种情况下,微信小程序对运营方的意义就是用户的重要入口和运营的重要阵地。

  刚刚提到的微信小程序的两个标签( Live-pusher 推流端和 Live-player 拉流端),他们都有两种运作模式 —— RTC 模式和 Live 模式。在进行视频通话或者连麦直播的情况下,使用 RTC 模式;在视频直播的观众端采用 Live 模式。

  通过微信小程序的音视频能力可以实现连麦直播和视频通话,那么不通过微信小程序的音视频能力是否可以做到呢?答案是:可以做到。市面上有一种基于 WebRTC 的方案就是很好的例子。

  这个方案利用了微信小程序最近推出的 WebView 组件来承载基于 WebRTC 的应用。小程序的 WebView 是否支持 WebRTC 呢?我的答案是:支持,也不支持。

  WebView 在端支持 WebRTC ,在 IOS 端不支持 WebRTC ,而且在端的 WebView 还不是完整的浏览器,所以功能会受限。因此,这个方案虽然讨巧地借用 WebView 来承载基于 WebRTC 方案,但它也带来下面几个问题:

  那么,如何才能真正地利用上小程序的音视频能力,来实现视频通话或者连麦直播呢?要知道,小程序只提供终端上的能力,没有实现服务器,因此要自己开发服务器端或接入第三方的服务器,来实现多人连麦直播或者视频通话。

  我们以即构科技的连麦直播方案为例。即构的实时通信网络支持两种传输协议:RTMP 协议和基于 UDP 的私有协议。那么,把小程序接入到实时通信网络有两种方法:

  小程序支持 RTMP 协议,可以直接接入到即构实时通信网络,采用 RTMP 协议;

  通过即构 ZEGO 接入服务器,把小程序支持的 RTMP 协议转成即构的基于 UDP 的私有协议,另外还要进行格式转换等。通过接入服务器,即构的方案支持小程序和原生 APP ,WebRTC 终端互通连麦。

  上图展示了小程序和 WebRTC 互通连麦的架构图。左边是小程序,右下方是 WebRTC 终端。后者通过接入层 proxy gateway 接进来,WebRTC 的 SRTP 转成即构的传输协议,格式也会做相应的转换来适配。

  WebRTC 网关服务器有很多开源的方案,比如 Licode 、Janus 或 Kurento 。即构团队经过深入研究这些开源方案后,放弃了采用开源的 WebRTC 网关,而自行研发了自己的 WebRTC 网关服务器。

  分享了如何在微信小程序上实现连麦直播或视频通话,同时将连麦直播技术覆盖到原生 APP 和 WebRTC 浏览器上。因此,我把原生 APP 、微信小程序、WebRTC 浏览器、以及最近推出的快应用都列在了上图,在几个方面进行了对比。