教育互动直播,11年技术演进之殇

LiveVideoStack 2017年7月18日

各位下午好,我是CC视频的唐通,先简单介绍一下CC视频,CC视频成立于2005年,实际上做视频领域已经整整11年了,我们公司的目标和愿景主要是为企业提供场景化的视频解决方案,这里面“场景化”就比较关键了,可能是因为我们深入到一些垂直的领域,比如说教育、金融、互联网,今天我主要会聊一些教育方面的,比如说我们在教育方面一些代表的客户,大家都熟知的像新东方、华图,还有类似高顿这样一些客户。



今天的分享主要围绕着三个关键词——在线教育、场景化和互动,我分享的这个标题,也是我们直播中的一些混合互动模型,刚才百家云张总和布卡互动另一位张总,他们都分享了一些教育直播的方方面面,但我的分享侧重点有所区别,我会着重讲一下互动。


这是我分享的一个目录,首先我们先由需求出发,讲一下教育直播用户他有什么诉求,然后依次来讲几种互动:视频互动,文档和白板的互动,还有我们的一些信令服务如何来架构,以及未来我认为的教育行业的一些趋势、教育行业直播的一些趋势。


教育直播的用户诉求


首先是教育类直播它的用户诉求,直播的技术架构需要什么?因为刚刚我们一直在讨论直播,这里可以捋出很多词来:可扩展、网络适配、高并发、开放、实时、可运维、低延迟、服务化、高可用,还在这里着重的写了一个稳定,这些可能是我们一般通用直播技术架构的一些特性,但对于教育类直播来说,我认为有一点是非常重要的——也是直播相较于比如点播的一点,核心的区别就在于互动,就是让老师和观众能互动起来,能让课堂不像点播那么枯燥。



1.连麦互动


在互动方面,我们都有些什么?首先是连麦,它的一些场景,像教学答疑,有些学生上完课之后还有些疑问,他就会需要答疑,再比如我们的双师教学,这个场景的难点在于实时性和跨平台,这样的教育场景可能使得我们做2B业务跟2C的不太一样,2C业务可以规定几个平台,但我们做2B业务是一定要做到全平台,全平台刚刚也有分享,就是我们常用的那六大平台。


2.文档和白板互动


其次是文档和白板的互动,我们上课的时候肯定要有课件,需要在上面勾勾画画,这样能让老师教学更容易,学生也能更容易理解,这个场景就是我们课件的一些教学,还有白板的一些互动。这部分的难点在于一个同步性,还有回放的留存。


3.其他互动


此外还有一些其他的形式互动,比如我们还能设置抽奖,它是为了能够活跃课堂气氛,还有像签到,像答题等等,这些我就不一一列举了。这些场景主要是帮助我们来做一些教学质量的评估,也就是我要知道这节课的签到率是多少,有多少人没在,比如说人并不在电脑前只是开视频挂机,我一签到肯定就被抓出来了。说了这么多种互动,实际上这一切都是为了我们要做到一个事——达到在线教育也要做到身临其境的上课体验,就是要让他感受跟在线下课堂一样的体验。


视频互动


接下来我会具体分享一下这几种互动是怎么来实现的,这里可能更多的会从架构上来做分享,也是我们一路走过来踩的一些坑。视频互动的协议和框架,我们最早尝试过用RTMP来进行连麦,后来我们使用了WebRTC,还有一些私有协议,大家都知道RTMP是基于TCP的,用它来做连麦,延迟是比较大的,而WebRTC是完整的一套方案,但它有很多信令交互的地方是比较麻烦的。在视频互动模型的选择上,有网状模型、星状模型、还有混屏模型,接下来我就着重讲一下这三种模型。


1.网状模型



实际上这三种模型我们都实践过,首先是网状模型和直播的结合,为什么叫做网状呢?实际上就是我们进来的所有人——参与互动、参与视频互动、参与连麦的所有人之间都得互相建立连接,所以它看起来就像一个网一样,这就叫网状模型。网状模型,实际上是基于点到点的,也就是没有中心服务器的这样一个模型。在这个模型里面,单个终端网络负载,大家可以很容易想到,我要把这个视频发给除我以外的所有其他人,我也要去拉取其他所有人的这个视频,如果是n个终端进入就是n-1路上行和n-1路下行,这样整个网络的负载是非常高的。第二个,如果我们想把它和直播结合起来,我们还想让互动过程让其他人看见,我们还要实现在客户端混屏,因为其他人不可能也同时来拉这么多路流,这个是一个比较乌龙的事情,所以要混屏。在PC端混屏还好一些,如果我们码率和分辨率这些比较低一些的话,PC端还是能承受的,但如果我们是在移动端,在安卓、iOS上它机器性能毕竟是有限的,混屏就会非常麻烦。基于这个的模型,如果我们想互相之间传输消息,实际上是有很多协议的,比如说RTMP是可以做的,但它不是P2P的,还有我们基于WebRTC这套架构,我们也可以做这种基于UDP的传输,当然因为我们是点对点的,还需要P2P的穿透,所以我们需要Stun和Turn这些服务器,以及中间的一些信令服务器,来发它ICE的一些信息,所以整体而言这个模型的架构比较简单,但是实际应用的效果并不是很好,是我们最早实验的一个架构。


2.星状模型



在网状模型实验过后,我们就进入到下一个模型——星状模型,星状模型中间多了一个中心的服务器,它为什么叫星状?就是相当于我们中间有一个核心、一个服务器,我们内部把它叫MCU,这是一个视频会议领域的词汇,就是一个多点控制单元,它指的是我们可以接多路视频进来,然后把相应的视频中间进行一些转发,转给其他人。这个模型跟网状模型,最大的区别就在于,我的视频不是点对点的进行传输了,视频都是先传到服务器上,其他的再去拿这个视频。最大的一个好处,它可能解决了我们P2P网络的一个连通性的问题,大家应该知道,如果我们使用P2P网络,一些小运营商它打洞是很难成功的,是会有很多坑、很多问题的,当然这个模型较上一个模型改进的就是它只用1路上行,就是我只要把我自己的传给中间这个MCU,而不用传给其他的所有端,它解决了上行的问题,但没有解决下行的问题,下行还是n-1路非常多。对于混屏而言,它还是要在客户端来完成混屏,这样的话,我们客户端处理的压力实际上还是非常大的,如果我们在安卓和iOS上想实现多人连麦,超过一个人的连麦,耗的CPU基本都是非常高的。


3.混屏模型



最后这个混屏模型,就是我们的一个服务端混屏的模型,这个模型跟星状模型很像,但它的区别在于我们把混屏的处理放到服务端来做,这个也是目前比较通用的一个方案。我们在服务端MCU会把多个参与互动的端的视频和音频进行混合,视频我们按预先的模板进行合屏,音频我们进行混音,混完之后,我们再通过RTMP推到CDN上,由CDN来进行分发,这样的话,首先我们参与互动的终端,我们能拿到的就是这个互动的视频,并且我们能承载大并发量的观看端,因为我们中间经过了CDN,CDN它能承载,它有更广的网络资源,所有终端能拿到这个合屏的视频它看的会更全。这样的模型,它是1路上行和1路下行,他解决了多个互动端之间的网络问题,也就是它不用再拉那么多路流,而且它不用再在客户端来合流,这个是一个非常好的事情,即便我们在移动端也能实现多人的的合屏连麦。


4.各模型优缺点



各自模型的一个优缺点在这总结一下,对于网状模型而言,当然是架构比较简单,我们基于现有的WebRTC做一些改动,在客户端我们实现合屏连麦就完成了,不过它存在很多缺点,比如说连通性的问题,我们需要P2P打洞,在一些小运营商、一些非对称的NAT上它是非常难通的,特别是在那些小运营商比如说宽带通这些,它本身就是在一个大局域网内的,网络负载和各个端的负载比较高,而且我们需要在客户端合屏,这就同时占用我们两个可贵资源,一个CPU,一个网络IO。星状模型它解决了上行的问题,就是我刚说它只用传一路视频到MCU上,它解决了上行的问题,不需要打洞,但还是没解决下行的问题,仍然需要在客户端来进行合屏。最后混屏模型的上下行我们都只用一路流,且不用在客户端来合屏,但是想把它做好,实际上架构还是比较复杂的,而且它不支持单独获取某一个客户端的流,也就是说我能拉倒的一定是合屏之后的流,而不是单个的,比如说我单向看某一个学生或者某一个老师的流,这个是没法实现。因此我们最终采用的方案是星状模型和混屏模型两种混用,保证既可以拉混屏后的流,又可以拉单个学生的流,而且我们混屏的这种方式还支持输出多种模板,比如说一个混屏的模板我们把两个老师混进去了,另一个混屏的模板我们把所有人混进去了,我都可以单独来拉。


5.WebRTC MCU



然后简单介绍下我们要实现一个WebRTC MCU,需要实现的一些点,我们这个是基于WebRTC来讲的,因为WebRTC帮我们做了很多事,虽然它也有很多坑,刚之前分享者也说了。首先客户端的话,我们在全国布很多接入的节点,这些接入的节点是多协议适配的,它是可以接入WebRTC,基于RTP、RTCP、UDP的这种传输,当然我们也可以接其他流媒体协议比如说RTMP,这样的话,我们在全国布上这些接入节点,它能保证我们的上行传输,我们能有覆盖,但这还需要调度。客户端,我们通过WebRTC里面的RTP、RTCP、UDP传到我们的WebRTC的接入节点——分布在全国,然后这些接入节点会把流传到媒体处理中心——我们有一个机房专门处理流媒体,在这个媒体处理中心,我们会把音频和视频分开处理,音频进行混音,视频进行合屏,处理完之后我们又混成一路,之后再进行其他的一些服务,比如说我们把混完的视频转推出去,我们转推1路RTNP到CDN,让他帮我们再做更深层次的加速,全国节点的一个观看的覆盖。还有录制的服务,比如说我们把这个视频再给录下来。同时我们业务这边,我们还有整个的一个业务中心,它会负责我们中间所有这些过程的信令的交互,因为大家知道这个WebRTC在做的过程中,它是需要很多信令交互的。此外还有调度服务,客户端请求连接,我们会基于它的IP、地域、还有ISP,我们来给它分配指定覆盖的一个节点。还有我们整个的一个机群管理,比如说哪些节点宕了;还有一些API服务。 我们这个WebRTC MCU的架构可以看到最明显的一点,就是把流媒体处理这部分和接入这部分真正网络的承载,CPU敏感的和IO敏感的这两层我们给分开了。


文档互动


接下来是文档互动,这部分内容之前也有分享过,我再来讲一下。我们做CC视频实际上是以点播起家的,2005年开始我们就一直在做2B的点播服务,应该国内是第一家,一直做到现在,种种原因,我们直播是相对起步比较晚的,可能是在15年年初的时候才开始起步,当时面临的问题就是我们怎么来在网页中展示这个文档?


1.如何在网页中展示文档?



大家都知道PPT、PDF、Word在网页里面是没法直接展示的,所以我们需要进行转码,转码我们可以转成很多种方式让它能在网页上来展示。首先是JPG,图片是肯定能在网页上展示的,SWF肯定也是可以的,这两个是我们在PC端展示的;如果想在移动端展示,我们还需要H5,就是转成HTML,还有一种方式我们直接把文档作为视频给传过来,这种方式也是可以的。所以我们中间就面临一个问题,我们如何来进行一个转换,如何让大家都能看到这个转换后的视频。


2.互动文档的架构



这个是我们设计的文档服务的架构,首先主播端,肯定是要提前把文档上传到我们的服务器,我们会有接收的节点在接收之后,通过调度分配到进行文档转换的服务器上,我们会把转换完的文档放到存储服务上,存储服务我们肯定会使用CDN的加速,让所有观众能更快速的能看到这个文档,这还只是我们能让观众看到,如果要做到同步来翻这个文档的话,实际上我们还需要依赖其他的一些信令服务,刚说了我们是要在网页上能看到这个翻页,所以我们会基于WebSocket这种方式,我们来达成一个长连接,来传输一些信令服务,之后的话,也会专门来讲这个信令服务,当然中间的话,我们肯定都会有一个中间调度中心。


3.传输面板信令的方式


我们在做教育行业的文档的时候面临这样一个问题,就是翻页如何来同步,老师嘴上说着“接下来我们来看下一页”,但是这边文档还停留在上一页,这可能因为视频的延迟,以及视频和我们翻页的信令服务,是在两个通道里面传输的,所以这两个通道想做到延迟,实际上是很难的。我们在传输信令的时候考虑过两种方式,第一种是带内传输,什么意思呢?就是我们把文档翻页的信令,直接通过音视频RTMP这个协议内部进行传输——oncuedata,可以传输一些自定义数据,这样我们就能保证翻页和视频是严格同步的,但是它也存在明显的缺点,就是在于它的兼容性,因为我们是对接的CDN厂商,目前很多CDN厂商和流媒体服务器都是不支持的,服务器在收到这样的信息时会选择直接丢弃掉,这个是很麻烦的,而且还有一点我们要做到播放器的兼容,播放器也要能识别这种消息,把它读出来做相应的事件触发,此外还有移动端H5网页,我们刚说了它是通过RTMP这种消息,当然他也可以存到FLV里面,但是如果想在H5上实现,目前还是不行的。我们考虑另外一种传输方式,也就是第二种带外传输,它是通过另外的信道——WebSocket,通过音视频之外的信道来传输,兼容性好,灵活性高,这是在多个端都可以实现的,但缺点的话,就是需要额外实现与视频的同步,也就是说我们可能需要在观看端来计算目前视频的延迟,然后来做这个延迟的显示。


信令服务


接下来说一下信令服务,大家可能看秀场直播看的会比较多一些,秀场上的互动,比如说主播做了一件很牛的事,大家就抠“666”,这个时候弹幕是会刷很多的,在这种情况下,后台的聊天服务器压力是很大的,如果一个聊天室里面同时有两万个人,三万个人,甚至十万个人,他们同时在刷666,这时候不管是我们的聊天服务器的带宽,还是观看端展示所消耗的CPU都是非常高的。在我们教育行业也会面临同样的问题,当然表现形式会不同,教育行业主要面临的一个问题就是老师在讲题的时候,它有ABCD选项,当需要学生作答的时候,所有人就会抠个A或者抠个B,这个时候弹幕的量还是非常大的,我们在这方面也做了很多的优化。


1.教育场景的聊天与信令需求



教育行业的聊天和信令的一些需求,首先是实时,我们要求在一万人的情况下,端到端的延迟要在五百毫秒之内,第二是弹性可扩展,就是在我们突发大并发的这种直播,我们要随时增加服务器来进行热扩容,跨平台和兼容性这个刚刚说了,因为做2B业务,我们需要兼容多个端,我们要跨所有的端,还有就是高可用和流量控制,流量控制就是可根据需求实时控制聊天等流量,对于我们公司也是控制成本,这个聊天的流量实际是非常高的,因为它是一个N×N的关系,这个我后面会讲。


2.信令服务的简单架构



信令服务器的一个简单架构也是分层的,跟我们音视频的架构很像,实际上我们也是有前端的一些节点来承载连接压力,这些前端节点我们也会在全国来进行部署,然后我们有后端的节点来处理一些业务,这中间会有一些消息路由,比如说会有消息队列这样的一些组件来进行消息路由,假如一个主播想和其他人说话的时候,我们会通过这个消息路由传到后端,再传到前端节点进行聊天,当然我们在后端的时候会进行存储,一个消息的留存,这样我们整个回放的功能才能得以实现,就比如说老师翻页的信息,还有学员说的一些话,这些都是要存起来的,在回放的时候,我们重新把它展现出来。在前端节点我们为了兼容多个端也使用了不同的协议,大家知道WebSocket它是H5其中的一部分,但是目前市面上还是有很多老的浏览器,像IE这些,所以我们还是需要一些其他的协议,比如说基于HEP的这种长轮询这种方式,我们来实现推送,但整体我们也有一个调度服务器,当我们前端压力过大的时候,我们直接可以增加前端的聊天节点,承载的节点,来扩展我们整个系统的负载。我们后端的节点是按业务来分的,这种划分方式也是能保证把压力给负载到不同的节点上。


3.如何控制流量?


如何控制流量?假如这样一个场景,有X人的一个聊天室里面同时有Y个人在群聊,就像一个漏斗一样,进入的可能是那Y个人聊的信息,但是我要给所有的X人都群发,如果不进行任何优化的话,就是X*Y,这就是聊天流量大的一个原因,就是它是一个乘积的关系。当然我们就需要考虑其他的一些技术方案了,就比如说我们分为N个桶,分桶是什么意思?就是我们把这X人按照它用户ID的哈希再进行分桶,把某些人分到一个组里面,这样在一个聊天室里面我们又分成很多小组,每个小组内部的人聊天是互相可见的,但是组和组之间他们聊天是不可见的,这样我们分成N个桶,相当于把出口缩小了,他们之间总的消息就变成X*Y/N。然后我们还可以再进一步的优化,就是以M的几率再来一个丢弃,当然这个丢弃不能丢的太狠,因为丢太狠的话可能就被发现了,我们丢弃的话,一定还是要给被丢弃的那个人把这个消息发过去,让他以为这个消息发到了,当然我们的丢弃不是随时开启的,是当我们这个聊天室的人数,比如说超过一万人,我们觉得这个一万人在线聊天的话,这种常场景我不知道大家经历过没有,实际上是没有多大意义的,我们就会再以M的几率去丢弃从而去控制流量。


未来趋势


最后讲一下我认为未来的一些趋势,首先一个趋势就是轻端与重端的分化,一些小班课的教育,我觉得以后可能会越来越轻,我觉得像基于WebRTC或者基于浏览器的一些功能就能完成小班课的教学,所有老师和学生都不用下载客户端去安装,这里面还是存在兼容性和跨平台的一些问题;但是对于一些K12的教育,比如说刚才张总分享的K12的一些教育,他会和硬件进行深度整合,就像我刚提到的双师课堂、还有的全景课堂的产品,这部分是往重端来走的。第二个趋势是从Flash到H5,因为教育行业说实话相对比较土一些,很多还在用PC来看,因为Flash正在走下坡路,一些浏览器目前也正在为难Flash,而且IE的市场份额越来越小,大家知道目前我们视频播放,大部分都还是播放的FLV这个协议,FLV还是Adobe的协议,但是我们知道Flash在走下坡路,它总有一天会死去,新的一些H5的播放技术正在崛起,比如说像bilibili分享的一个flv.js,它就生成基于用原生H5我们就能播flv,flv当然是目前我们CDN支持的最广的一个播放格式。双师教育,就是名师进行网络直播授课,现场再辅以助教进行互动,刚刚张总已经分享了很多。需求的话就是实时的视频互动,以及与硬件的深度整合。好了,这就是我分享的全部内容,谢谢大家。

还可输入800
全部评论
作者介绍

唐通

CC视频

研发副总监

文章

粉丝

视频

相关文章
阅读排行
热门视频

WebRTC视频数据流程分析

许建林/《WebRTC Native开发实战》书籍作者