导语

过去这一年，中文互联网只有一个热点：直播！直播！！直播！！！不只有网红可以直播，在线教育也是视频直播的重度应用领域。本文是根据卫向军在『见云·沙龙』的分享整理而成，他介绍了三好网创立两年多来，遇到的核心技术难点，以及相应的解决方案。包括兼容多种OS和采集设备，降噪和回声消除效果，图像处理优化；移动网络下编码，优化编码参数，降低带宽消耗；降低端到端延迟，多运营商跨地域问题；适配显示器，提升播放流畅度等，以及创业公司技术选型等研发经验。

大家都知道从15年下半年到16年直播+网红是非常火的话题，今天我说的是在教育交互直播领域的技术探索。首先简单介绍一下我自己，我在微软工作过5年，当时是做Lync音视频会议系统移动平台的产品研发，后来在金山云和新浪微博，负责技术研发管理工作，现在的话加入三好网，是一家做在线教育的创业公司，我们成立于两年前，在15年初拿到7500万的融资，我们具体做得是面向老师、家长和学生和家长中小学生一对一在线教育服务。

在线教育简单介绍

对于传统的线下教育它的问题是：

1.老师和学生需要到培训机构去面对面的做授课，它有个严重的问题，就是培训机构必须得到全国各地去开分公司，导致它的招生和推广成本非常高；

2.对教育来说它最终追求学习效果，相同的时间效率越高效果越好，但是线下的效率是比较低下的。

3.对于教育来说，在全国各地，可以看到教育分布是非常不均衡的，比如说北京，它的师资力量就非常雄厚，而很多偏远地区的学生他就享受不到比较好的师资。

三好网就是为了打破传统线下教育的一些瓶颈，改造和提升教育产业的效率。

三种教育直播场景

我们做在线教育一直在探索，在过去主要有两种授课方式，一个是录播，另一个是直播。对于录播来说，过去几年探索证实，录播课程是像现在的MOOC一样，大家在网上发布一些短视频，学习者在看的时候是没有互动性的，它整个的学习效果并不高。从16年开始，直播是整个教育行业都看准的方向，从前作O2O的几乎都切入到直播领域， 因为直播本身它有较高的互动性，同时也有比较好的体验。

从整个直播来看，在教育行业又分为三种模式:

1.一对一，有一个老师对一个学生做针对性的辅导；

2.公开课，老师讲的是非常基础的课程，一个老师他就会有成百上千个学生同时上课；

3.小班课，如果大家有过线下的经验，线下有小班和大班课，小班课有三个人到十个人左右，这样的话，几个学生一起听一个老师的课，就有老师和学生的互动，也有学生之间的互动，这样学习效率是比较高的。

三种模式

1.从延时上看：

（1）一对一，因为它是交互式的两个人互相来授课和学习，所以说它对延时的要求是最高的，至少要在一秒以内。

（2）对于公开课来说，最主要的是老师授课，它延时的要求相对会比较低，在三秒以上都可以接受。

（3）小班课它的延时要求也比较低，至少在一秒以内。

2.从效果来看：一对一有针对性的，它的效果肯定是最好的，其他的效果依次次之。

3.从技术方面看：对于非交互式的直播，它一般来对于视频流使用CDN来分发；对于交互式的，如果使用CDN，整个链路中多一个节点，延时就会比较高，所以一般不会依赖于CDN，所有的媒体服务器会直接和你的客户连接，这也是一对一技术场景中最重要的一个特点。

在线教育

对于教育来说，我们怎么把线下的面对面的授课搬到线上? 这是一个学生他登陆我们的客户端以后，就可以让老师来辅导，这是我们上课的界面，老师有一个辅助的硬件，手写的时候，我们的硬件有一个摄像头可以把手写的这个过程拍下来，同步视频传输到远端，这样的话，双方就可以进行交互式的教学。

我们总结过，对教育培训这个行业来说，现在最成熟的就是语言培训，尤其是英语培训，英语培训给大家打的一个口号是，动口说，我们要做动手说，那其实要学习效果，对我们来说，不仅需要学生和老师通过视频交流，还需要他们来动手写，动手练，这是我们做线教育的一个目的。

业务形态方面的技术挑战

我们分别从视频的采集，处理，编码，传输以及播放几个阶段来分析。在采集的时候涉及多个操作系统版本的兼容性以及硬件设备的兼容性；视频处理的时候，音频如何降低背景噪音，如何消除你的回声； 在各种不同的网络环境下用什么样的编码合适；怎样降低带宽消耗；在传输的时候，国内的运营商网络非常复杂，如何解决跨运营商，跨网络的问题；在播放的时候，要不同的适配，以及一些加速等等的处理。

案例分享

在我们整个业务过程中，有几个案例，我想稍微分享一下。

1.对操作系统的兼容，我们PC客户端遇到一些问题是非常少见的。突然有一天，一个学生说，他的硬件设备不识别，然后我们去看，会发现他的操作系统是中国人喜欢用的不花钱的番茄花园，而且是一个很少见的版本，但是我们需要把系统这样的适配问题给解决。

2.我们在海外，通过口碑传播的用户想来我这上课，有澳大利亚的客户，他就想找一个国内的老师。我们的线上服务主要在国内，这样的情况出现之后我们怎么处理，对于海外来说，我们不可能建很多的海外节点，我们采用一个成本和体验折中的方式，在香港和美国各布一些节点，让这些学生测试上课的流畅度，测试的过程中，我们会做一些优化。如果在我们部署这些节点他还不流畅的话，我们暂时服务不好这个客户。

3.在网络优化上，问题更复杂一些，我们有老师和学生反馈，他们俩上课过程不是特别流畅，但是老师又说，我同时带了很多学生，我给其他学生上课流畅；学生说，我也是报了多个老师的课，我和其他老师上课也都很流畅，结果就是他们跟其他所有都很流畅，但是他们两个一连就是不流畅，这个情况下也需要我们去解决，怎么样让所有的直播都流畅。

在整个直播中，我们总结，影响他体验的点包括：

1.延迟一定要小；

2.卡顿一定要非常的少；

3.反过来看，就是除了这些衡量的技术指标，在我们这个产品场景下，影响他最重要的因素肯定是他设备CPU的处理能力，网络和我们自己硬件的整体能力要求。我们毕竟是视频处理，所以对CPU要求比较高；网络的话，包括终端连接边缘节点，是自己家带宽，还有就是我们整个服务提供的节点，他网络服务的带宽能力。

从我们整个过程来看，我们是一个交互式的业务流程，所以说它在流程中，发送端和接收端，当然接收端也会反过来，给发送端发送音视频。我们没有考虑用RTMP、HLS协议，而是直接采用RTP实时传输协议。

在对整个发送和接收端来看有一些关键技术：

1.音频处理中几个比较常见的技术一是降噪，再是回声消除。在我们的产品中，如果有背景噪音，我们需要用一些算法把噪音给消除掉；对于回声消除，一般会有线性的和非线性的消除，我们是两种结合，当线性的消除效果不好的时候，非线性的也会用，这是一个工程学的问题，非线性消除的时候，有可能会让你的数据失真，这时会不断的来调优。

2.视频的处理中常见的是颜色空间转化，还有裁剪、拉伸。视频编解码一般都会用H.264，H.265现在也已经走出来，但是大规模推广还需要3、5年。 

3.对于编解码，我们首先会看电脑是不是支持硬件编解码，如果支持的话，用硬件的GPU来加速，没有的话，我们再用CPU。

4.对于音频处理，我们把Jitter Buffer 放在接收端来做，在传输过程中网络的速度是时快时慢的，如果不做处理，接收到的声音也会不自然，这个时候需要做一个缓冲区来缓存网络数据包，当输出出去的时候，它会变成一个匀速的数据包。

这是我们整体的架构，更多偏向服务器视角，我们有几大块，第一块绿色是硬件好学宝，黄色是PC客户端，就是我们刚才视频里面介绍的客户端，上边是画了三个IDC机房， 每一个里面都有三种类型的服务，分别是媒体服务，信令服务和文档服务。这三类服务，都是完全隔离，互相之间是完全解耦的，各自都可以单独存在。

相应的针对这三类服务，我们整个流也会分为三类：

1.信令流。我们的客户端和我们的信令服务器来做通信，主要是用户的注册、用户的登陆、加入房间等等。

2.文档服务。我们在上课的过程中，会有PPT的演示、排版等。

3.媒体服务。 在直播过程中，音频流、视频流处理。在这个过程中还有做转码、录制的功能。我们所有的媒体服务器，技术上定义它是无状态的，我们可以围绕机房再自由的扩容。另外，对每个机房来说，互相之间也是一个平等的地位。 我们的老师和学生，如果在不同的区域，我们会假设老师先连离他最近的机房，学生连离他最近的机房，老师和学生连接的这两个机房之间只需要做一次额外的转发。

教学质量监控和保障

对于一对一教学来说，达到规模化以后，怎么样来保证教学的质量？当只有一千个老师的时候，很容易监管，当你的老师到一万，到十万的时候，管理的难度指数级增长，针对这个问题我们有两套系统来逐步做支撑 。

1.LiveMonitor监控系统，我们提供三种角色使用这个系统

（1）手机旁听：在老师和学生上课的过程中，家长通过手机可以去旁听。家长共同参与老师给学生上课辅导的过程， 督促老师来提升教学质量；

（2）监课系统：会给我们的教研团队提供一个后台的监控系统，这个监控系统可以时时的监看老师给学生上课的整个过程，他们会对每一个正在上课的做审核和添加监控记录；

（3）录像回放：对于我们的班主任来说， 他在课后会查看上课的视频，对上课的质量有把控。

2.监控系统更多的是从系统的角度看，绝大多数公司的系统一样分为业务监控和技术监控。技术监控看服务器节点它CPU、带宽、节点之间的延时；从业务监控来看，我们看客户的并发数、丢包率以及业务的分布。

端到端延迟和卡顿

1.Jitter Buffer：他是削峰填谷的作用，但它其实不是能降低延迟，反而是增加了延迟，但是为了保障播放无抖动必须要添加。Buffer的大小与音频数据的码流、网络状况相关，需要 不断的调优。

2.客户端直连：整个交互过程是没有CDN分发流媒体数据，我们都是客户端直连服务器来做转发，我们刚才也提到，我们服务端会在全国布很多的节点，我们节点布的时候会对节点做分组，就是我们对于不同的服务商，不同的地理位置会分为一组。我们客户端在直连的时候，首先会和这些分组的服务器之间做测速，我们从不同的组中去测，测出哪一组速度最快，我们会对于这一组内，使用负载均衡策略来给大家做分发。

3.节点之间线路，两个分组之间节点做转发的话，我们最多只需要转发一次。我们看过，比如说我们从北京到香港来看服务器之间延迟200ms左右，北京到杭州有30ms，杭州到香港有160或170毫秒。对于三个地点，如果说你直连和你通过第三方来连，它有可能有最优的路由，但绝大多数场景下，目前的方案能够达到我们的要求。

性能优化

我们做了一些什么样性能优化？

1.首屏加载加速：客户端初始化时需要连接信令、媒体和文档服务器， 所以客户端在开始登陆的时候，就已经异步的去连这些后台服务器，甚至客户测速的工作都提前做了，通过异步加载的方式，当用户真正加入房间的时候很快就进入啦。

2.硬件加速优化： 有GPU的电脑，我们都会默认把它打开。

3.传输协议优化：我们最开始在第一版的时候还用的是TCP，实现相对简单，TCP对带宽的消耗还是比较高，后面改成UDP以后，带宽降低了30%，效果非常的好。

4.传输策略优化：

（1）对我们客户端来说，网络不能永远不掉线，当你在连接的过程中掉线的话，客户端会自动的连服务器，这样用户是没有感知的。

（2）如果我们发现这次连的媒体服务器不稳定，我们会定一个范围，在多少的时间内断线多少次，定义它不稳定，主动切换别的服务器。

（3）在传输过程中，我们会优先保证音频流优先传输，其次是视频。

5.服务质量保证：

（1）对音频来说：我们采取的策略，因为UDP是不保证可靠到达的，我们会用FEC，发送端会加一些额外的专业包，这样在接收端的时候，如果你在有限的丢失包的情况下，通过FEC的算法就可以把它的包解出来。

（2）对视频来说：我们采取的策略，对于非关键帧，都可以丢弃，但是对于关键帧，我们在UDP的基础上加了自己的重传机制。

6.多版本客户端：客户端考虑系统兼容性，在Windows上，国内的XP用户还是很多，这对我们来说也非常的头疼，因为XP上很多有用的库的版本是比较低，我们为了这个版本单独做了一个XP版本给用户来用，当然它的代价是增加了维护的成本。

创业公司技术研发经验分享

最后分享一下，在创业公司你要做技术研发一些经验分享。

1.ROI（投入产出比）：我们在做任何事情的时候都会考虑投入多少人力、物力、资源，实现什么样的产品功能。

2.KISS原则（Keep It Simple and Stupid）：我们在做设计的时候，我们一定结合业务需求往前走的，我们不会过度的Over Design。

3.使用云服务、第三方服务： 把自己核心的竞争力给发挥出来，专注于自己的核心业务，对于一些基础的服务都可以使用第三方的。像我们的短消息、推送、日志分析，包括支付等都不会自己去做，全部都用的第三方。非核心的基础服务，能用第三方就用第三方的。

4.成熟技术，擅长的技术，前沿技术的选择：其实我写的顺序，基本代表我个人看法。在创业公司里，推荐业务为主的情况下，尽量先使用成熟的技术，成熟的技术如果不行的时候，考虑擅长的技术，最后才是前沿的技术。但是当你的业务量发展到很大的规模，在一些非核心业务上，是可以用不成熟的前沿技术。

5.8/2原则：大家都知道在创业公司这个问题会尤其突出，你要开发的产品功能多，做事的流程还没有那么规范，用户提的需求有时候很无理， 这个时候一定要把自己的精力放在最核心的事情上，把一些不重要的事情，不重要的功能就能砍掉就砍掉。

我的分享就到这，谢谢大家。

Q：你好，刚才你说Buffer，Buffer你是缓存多长时间，或者缓存多少，跟其他的参数有什么关系？Buffer效果到底怎么样

A：这个跟你的码率是有关系的，因为你的码率越大，你单位时间内收到这个数据量也会大。

讲师介绍：卫向军三好网联合创始人及CTO

主要负责面向K12领域的直播互动教学服务平台、教育O2O系统，曾在微软、金山、新浪微博从事技术研发管理工作，擅长大规模分布式系统架构设计。

见云沙龙旨在传播先进的云计算技术与应用实践，帮助开发者及云计算服务使用者学习新技术，掌握新技能，提升效率，降低成本。

声明：所有来源为“聚合数据”的内容信息，未经本网许可，不得转载！如对内容有异议或投诉，请与我们联系。邮箱：marketing@think-land.com