武海滨：沪江如何搭建优秀的在线教育平台

3月31日，ZEGO Meetup 视频直播+的技术实践之道第三期在上海成功举办，现场吸引了满堂的音视频开发人员到场聆听。会上，如预期一样，么么直播前端团队负责人黄铭新、即构科技资深技术专家和架构师冼牛、沪江 CCTalk 音视频架构师武海滨、涂图TuSDK 研发技术总监王胜，这4位直播行业大咖给大家做了精彩分享。沪江 CCTalk 音视频架构师武海滨老师给我们带来的是《使用RTC技术搭建优秀的在线教育平台技术》，本文是对武海滨老师演讲内容的整理。

 

嘉宾介绍

 

 

武海滨，沪江 CCTalk 音视频架构师

 

先后就职于盛大创新院多媒体主题院、阿里巴巴等公司。目前担任沪江 CCtalk 音视频架构师，从事CCtalk音视频相关研发。

 

关于CCtalk

 

上图是CCtalk在2017年春节举行大型课堂在线直播时的截图，当时最高人数达到了1万多人。2018年春节，这个课堂已经达到了2~3万人左右。从这个规模上来看，CCtalk可以轻松应对一对一、一对多、多对多甚至超大规模的音视频在线教育直播课。

 

上图是CCtalk用户的分布情况。老师遍布全球，主要在欧美、日韩、东南亚、拉美等，有些老师甚至会一边旅游一边上课。学生主要在中国大陆，人口越多的城市，学生就越多。同时在偏远山区，也有一定的学生分布。因为沪江有一个专门的公益项目，叫做沪江计划，主要是通过互联网的形式，给中西部山区的孩子们提供教育服务。用户群体也是多种多样的。医学专家可以通过直播做一些医学方面的讲解，公务员也可以通过直播教观众如何报税等。还有画家、音乐家和刺绣从业人员等，都可以通过在CCtalk上面开课做直播。

 

传统直播技术与直播架构

 

这个模型的优点不言而喻：首先是技术门槛比较低，而且技术比较稳定，同时它能够支持多种设备端，比如说HLS协议，在移动端同时支持安卓和iOS，减少了移动端的开发量，另外在PC端上也支持flash公司的产品。

但是，这个模型也有延迟和低互动的缺点。由于HLS协议的特点，导致延迟无法避免。但是HLS在移动端又是被广泛支持的，如果使用HLS来收看直播，就不用在移动端做过多的开发。所以一般通过这种流来做单向直播。这样，一边学生从CDN通过多种协议多种终端进行拉流观看，另一边老师则是推流到CDN，然后通过CDN把内容分发给学生。从非技术方面考虑，它能同时带来很多客户端，从经济成本上考虑，它比互动性强的在线直播成本要低廉。像这样的架构，主要是应用在CCtalk里面录播课的播放。

 

RTC低延迟直播场景

 

CCtalk有两大核心，直播课和是录播课。前面提到的架构在CCtalk的录播课里面应用非常广泛。而上图的架构则用于RTC低延迟直播的场景，它的优缺点相信大家也很了解，优点是延迟小、互动性强，缺点就是贵，因为按照流量来算，使用这种架构进行直播需要有一定的成本预算。另一个缺点是它的技术门槛比较高。

 

传统直播技术与直播架构（改进型）

 

在线教育的直播课程中，往往会遇到这样的问题：比如一个老师直播开课的时候，报名的100个学生中，90个人的网络是好的，往往有那么几个人，看不到老师的屏幕共享。因为老师的屏幕共享一般都在1080P以上，来做Photoshop或者编程IDE的界面分享，这种界面需要的分辨率很高，对应的网络要求也就比较高。所以接入小运营商网络的用户或者是用户在信号不太好的地方时，就会出现延迟较大或者是卡顿的情况。而从用户的角度看，用户会认为既然付费了，就必须要得到非常优质的服务。如果用户体验不好，就会要求赔偿。

针对这类问题提出了一个设想：在Alice老师的直播端，同时推几套码流上来，根据不同用户的网络情况选择推送不同的码流，这样就能解决几个人上课卡顿的问题。但是这个方案也有弊端，因为为了解决这几个人卡顿的问题，从Alice老师直播端到后台服务器的分发上，需要实现的技术难点有很多，所以在这样的问题上，在线教育平台往往选择直接通过经济补偿用户。

 

混合方案，远近场分离

 还有一种是远近场混合的方案，这种方案对于在线教育直播课程是非常有用的。假设在两个小时的直播课程中有2万人同时在线，但是根据统计的结果以及感官上的认知，与老师互动的人和互动的时间都很少，即便在两小时内不断地连麦，也就是几百个人，剩下绝大多数的学生都只是在收听。传统CDN的方式能够将视频同时分发给大量用户，而且非常便宜。所以我们可以把绝大部分只收听的学生放在远场，如果老师要与某个学生进行连麦互动的时候，就将学生从远场切到近场。从经济上以及从用户的感知和形式上来讲，这种方式非常适合在线教育的大型直播课程。

但是这种方式也有一定的缺点。首先是绝大部分的学生会被放到远场，有时候从远场转到近场，可能会错过上麦的机会。即便成功上麦了，在远场到近场的转换中可能会有一个跳页，导致一定的延迟，可能是1~2秒钟。还有一种情况，比如老师在讲课的时候出了一个答题卡，让学生做选择题，由于CDN的弱互动特点，这时远场同学的用户体验可能会差一点。还有一点是PPT、激光笔和白板等走的是另外一条传输线路，比如说RTMP或者TCP等。这样在混合的时候，会导致在远场接收到的音视频和PPT会有一定的时间差，从统计结果看，可能会达到1、2秒或者更长时间。比如老师正在圈讲某个字，可能音视频看到的还是上一张图片，这时一些比较较真的老师和学生就会投诉。

 

编码算法的选择

 

目前的视频编码算法一般都是基于H.264，我们现在所用的级别就是Baseline profile，录制直播用的是high profile。如果能够对编解码的算法进行优化，对网络传输的效率会有较大的提高。举个例子：当老师在直播端播放一个1080P的视频时，由于在H.264压缩标准中I帧的压缩效率非常小，而P帧的压缩效率相对于I帧比较大，这种落差可能会导致有的用户看不到老师的展示画面。经过比较和探讨，我们一致认为适合音视频传输的编解码算法应该要做到，无论是I帧还是P帧的压缩大小应该都是一样的。假设视频的大小是800K，每秒钟以20或者15 FPS进行传输，而每一帧大小都是差别不大的，这样对于传输和渲染都比较好。

 

课程录制的问题和解决方法

接下来是有关课程录制的相关内容，首先分享的架构是通过CDN分发搭配RTMP传输的方式，这也是在CCtalk里课程录制所使用的一个直播方式。为什么要强调录播课在在线教育中的核心位置呢？有几个考虑的原因：第一个，很多时候，学生可能会因为各种原因错过直播开课的时间，这时希望可以通过录播课的回顾错过的课程。还有是基于学习的特性，一般来说，学习是反复练习的过程，可能一遍不行来两遍，两遍不行来三遍，基于这种学习的特性，录播课显得尤为重要。第二个，帮助老师进行备课，因为有的老师开课比较多，没有足够的时间备课，就会把原来做的PPT或者录制好的视频直接播放，鉴于这种情况，也需要对老师们每次上课进行记录存档，这样对于课程的录制就非常必要。

 

遇到的问题

课程录制在技术上会遇到如下一些问题：第一是需要大量的转码机。第二个是要最大限度地还原上课的场景，因为录播的上课场景跟直播的时候是不一样的，由于直播的强互动性，老师和学生之间可以进行探讨和答题，同时可以搭配PPT、白板的使用，但是录播的课程是做不到的，或者说很难做到。

首先看为什么需要大量的转码机。CCTalk每天直播上课的高峰期大概在晚上8点钟，同时在线的课堂大概有1000~2000多个。假如需要同时将2000个课录制下来，就需要对音视频做一次解码，解码成pcl、flv格式，然后将PPT生成PNG文件后再去合成，最后通过编码的方式生成课程录制的一套元素。熟悉编解码的开发人员都知道，这会消耗很多CPU和memory，因为在H.264编码中，一个640×480的视频就需要1G Hz的主频CPU资源。

还有一点就是音视频、PPT和激光笔之间会有一定时间差的。由于音视频和PPT与激光笔走的是不同服务器传输模式，这样在音视频和PPT与激光笔的对接上会增加不少难度。

 解决的方法

第一个解决办法是开发新款播放器，它可以最大限度还原当时上课的场景。比如老师在直播课45分钟的时候出了一个答题卡，测试同学选择A还是B，如果仅仅生成一个MP4文件，学生们在观看录播课时就看不到答题卡，即便看到了也只是静态画面，没有交互性。而这个播放器要做的是，在录播视频播放到第45分钟的时候，与一个互动连在一起，出现一张答题卡和学生们进行交互，等待学生完成后，播放视频剩下的内容，比如老师的讲解等。

第二个方法是转码机，这是随着业务增长时遇到的一个难点。随着需要录制的直播课程的数量增加，只能通过提高服务器的质量和增加服务器的数量来分担这一部分的转码。同时也尝试过一些调度上的优化，例如提高编码的质量和效率，但是效果不如采用GPU加速的方案。CCtalk通过调研比较选择了英特尔的GPU加速转码机。每台GPU加速转码机中有16个核，每个核都有单独的server，可以同时负责20~25路的转码，甚至能够同时进行30路转码，但是CPU过满可能会出现乱序或者丢包的问题。为此我们购买了两台GPU的加速器，通过运行支持GPU加速转码机的SDK来缓解后台的压力。比起增加服务器的做法，这个方案的效果更加明显。

 

数据监控和完善的log

 

在线教育的故障排查和问题解决，需要数据监控和完善的log。很多时候，老师都是在即将开播时才发现设备出现故障，这时上报问题再进行排查已经来不及了。而且，如果事后再来排查问题，用户也不能及时响应，所以这个时候就需要做数据监控和完善的log。

第一是确保现在数据一定要能查到每一个群，每一个上课的教室在每一个server点的传输情况和丢包率。假如某时刻某个地点出现卡顿，这个时候就需要进行排查可能出现的情况。

第二是能够查到每个client与gateway之间的传输情况，有些用户在最后一公里中丢包情况很严重。用户做直播的时候，往往会反馈说网络情况很好，但是为什么做直播的时候会卡顿，可能就是最后一公里的问题。

第三能够查到每个client使用的PC和手机的型号，从而评估出对应的机器配置。因为CCtalk的老师遍布世界各地，而国外的老师的机器配置往往比国内的机器配置要低。如果在直播中出现开启摄像头卡顿的现象，很多情况下是机器配置的问题，因为直播的效果和机器的memory和CPU都有关系。

第四，能够查到每个client直播时候的CPU占用率和memory占用率，有些用户在上课的同时会启用其他的APP，导致CPU紧张，结果表现为卡顿。曾经有老师反映说开课后出现卡顿导致没有办法继续，需要重新重启电脑，影响了正常上课。造成卡顿的原因可能是CPU紧张，事后他说当时正在后台正在下载一个电影。

第五，能够查到每个client上麦和下麦的行为，开摄像头和屏幕分享等用户操作行为，这个和cc server不一样，因为cc server不一定准确。曾经在一次直播中，老师在讲课时突然有人上麦了，而这个人讲话的内容跟课程完全不一样。从谈话内容看，他不应该在麦上，这样的bug会导致严重影响课程质量。事后他们也排查了这个问题，从cc server的统计结果来看，这个人不在麦上。因为cc server是记录用户的行为，比如用户点了某个按纽和操作，cc server就会记录下用户行为，所以从用户行为分析，他应该不在麦上。但是从音视频来讲，这个人确实上了麦，因为他有音频出来。后来查到是端上的问题，因为有时候UI界面和后台的SDK是一个松吻合的过程，用户在点击UI界面时，可能触发了事件，导致SDK自动上麦，而且又绕过了系统的健全判断，所以正常上麦了，而这样的bug导致了严重的问题。

第六，能够查到每个client上麦的时候，能否有音频流出来，音频是否静音，是否有视频流出来，这些能直接得到用户是否上麦成功的结论。一对一授课时，常见的问题是学生听不到老师的声音。而学生听不到老师的声音有两种可能，第一个老师的麦克坏掉了，第二个是学生端的播放设备坏掉了。所以要确认在线上有没有音频流出来，这时就需要做数据监控。

基于第六点，如果确定了是学生端的播放设备坏掉了，要知道损坏的形式就需要有第七点。

第七，在直播结束时，把本地的log有选择地上报上来。由于本地log会对错误信息进行记录，同时也会记录当时音视频设备的情况。由于人手不足没办法及时排查所有错误，当用户要求赔偿时，他们会通过用户log信息排查问题，以确认一下用户到底会不会获得经济上的补偿。

第八，后台的查找和上报的延迟不能太久。就像刚才提到，很多时候老师都是在即将开播时才发现设备故障，如果不能及时排查上报问题，会影响上课质量和用户体验。

第九，能够支持脚本查找，实时地监控。这是CCtalk的自动报警方案，有很多不起眼的地方，用户不上报，但不代表这个没有问题，因为用户不知道它是对还是错，所以有时候自动化报警也是很重要的。

上面是武海滨老师的演讲内容全文，感谢阅读。

关于即构ZEGO

即构科技于2015年由QQ前总经理林友尧创立，A轮获得IDG投资，核心团队来自腾讯QQ，汇聚了来自YY和华为等厂商的顶尖语音视频人才。即构ZEGO致力于提供全球最清晰最稳定的实时语音视频云服务，助力企业业务创新，改变用户线上沟通方式。即构ZEGO深耕视频直播、视频社交、游戏语音、线上抓娃娃和在线教育等领域，赢得了映客、花椒直播、一直播、喜马拉雅FM、陌陌游戏、自由之战2、和好未来等顶级厂商托付和信赖。