双师教育模式下软硬结合的直播技术实现

LiveVideoStack 2017年8月3日

大家好,我是来自百家云的张弩,我们应该和布卡是友商。我在视频会议行业做了很多年,主要是音视频相关的技术工作。14年加入百家云,主要是在教育场景下做一款在线直播的教学工具,在这方面有一些经验,今天和大家做一个分享。

 

我今天分享的内容叫《直播技术在教育行业的探索和实践》,会大概分成五个部分来讲,第一个是先跟大家简单介绍一下教育行业的发展,第二部分讲一下教育场景下的直播的一些技术特征和我们应对的做法,后面几个部分我们会有三个小的主题,一方面介绍一下我们和硬件的结合情况,以及我们和海外用户的直接保障,最后连麦这个功能比较火,我们讲下它在教育场景下的意义和我们的一些处理。

 

教育行业发展

 

我们先看一下教育行业的发展,为什么要讲教育行业?我们现在一直秉持技术是为业务服务的,所以只有在深入的了解业务以后,我们才能拿出比较好的技术方案,或者说技术的方向是由业务来决定的。

 

1.教育场景的演变

 

 

教育场景在很早以前只有线下面授的这个过程中,用户的体验是很好的,教学质量也很好,但是也会有些小问题,比如说场地成本、人员出行可能会受到天气、交通等等的一些影响,所以后来有了点播业务,随着这个软件的发展,点播业务,就是我们对于用户的重复观看视频的需求得到比较大的满足,但是它的互动性是比较差的,也就是我们在学习过程中很难跟主讲的老师进行互动,或者你有问题他也没办法给你回答,你只能自己去领悟这部分教学内容。

 

而随着移动互联网发展,直播业务变得很火,这个火也就烧到了教育行业,教育行业也开设了直播,一些老师在线上开放直播课程,这个直播课程就比较好的解决了时效性和互动性的问题,包括也降低了场地的费用,以及一些时间的成本都比较好的解决了。当然我们所说这个演进过程,并不是直播会替代点播,或者说会替代线下面授的过程,它其实是三种形式,共同去完成整个教育场景的工作。

 

2.教培行业的线上需求

 

我们一起来看下教培行业对线上业务方面的一些需求,比如说一些老师或者教育机构对于线上业务来说肯定是希望可以扩大规模,因为他以前的招生范围只有在线下,或者他自身周边的一些生源,最多也就覆盖到所在城市的生源,然而向全国或者全球的这些覆盖其实是很难做到的,当然现在已经有一些比较好的教育机构,比如说能够通过美国的外教或者菲律宾的外教给国内学生上课,这都是比较好的尝试。第二个,就是希望能够通过线上的方式降低成本,当然场地费用是明显能够下降的,还有师资的费用,比如说学生的管理,通过互联网化的一些工具也能够明显降低一部分运营成本。

 

推广引流,教育机构希望通过线上一些免费课程能够吸引大量的学生,提高关注、增加平台流量,然后再去完成流量转化,也就是最终还是希望学生能够报名付费的课程;当然在教学场景里面,他希望能够提升体验,也就是他希望在线上的教学过程和线下面对面的教学体验是一样的,希望学生有一个沉浸式的教学体验,能够达成比较好的教学质量。最后就是互联网化,互联网上的应用越来越多,教育机构或者老师也希望通过有一些互联网化的产品扩大自身的业务范围

 

教育场景下直播业务的特征及其应对

 

我们理解了这些需求以后,就知道我们后面所有的产品都是围绕着解决这些需求来的,我们第二个部分就是介绍一下直播业务在教育场景下的一些特点和应对方法,这里我会简单讲四个方面,当然特点有很多,时间关系我就跟大家分享以下这四个方面:第一个是低延迟和交互,第二个是我们的用户分布有一定特点,第三个是我们的文档、问答等等的业务,这部分业务在教学过程中很关键,最后是我们课程回顾的能力,因为上完课是一定要有一个复习的过程。

 

1.低延迟、交互频繁

 

我们先说一下低延迟和互动交互,上课本来就是一个互动非常频繁的过程,我们说的低延迟主要指的是交互的实时性,一般而言老师在上课过程中,经常会跟学生进行一些互动或者问答,我们很难想象说,老师问了一个问题,比如说学生过了5秒钟以后听到,他再进行思考,比如思考了10秒钟,他再把这个问题通过麦克风传到老师这边,这个过程时间就很长了,老师甚至很有可能已经忘了问题是什么,所以在低延迟方面我们主要在这讲的是实时性。当然前面分享直播场景下的秒开功能,我们认为它是一个能够解决用户快速加载视频、提升体验的一个功能,而不是主要考虑实时性,因为在我理解CDN厂商可能会做类似于一些小的缓存,在用户第一次登陆的时候,快速把这些数据发送给客户端,客户端能够快速的渲染出来,这是秒开的核心的思路,当然这个技术一直在发展,很多厂商已经不这么做了。

 

 

我们在这有一个小的区别,我们区别这个秒开的功能,下面介绍一下我们的应对策略,当然这个应对策略也是有很多种。我们先看下从老师讲课到学生听到的这一整个流程,大家就能够在各个环节上找出一些解决办法。首先老师的客户端能够把原始的音频和视频数据采集到本地,经过本地编码,编码的数据发送给服务器,服务器把数据推送给客户端,客户把这些数据再交给解码器,然后把它解码出来渲染在客户端上,学生就能够听到老师的声音和画面了,当然声音还是要交给声卡。

 

  • 选用合适的VOIP音频编码

在整个流程里面,我们每一个环节都有一些做法,比如说我们在编码这个阶段——老师的编码阶段,大部分的直播场景可能用的编码都是像AAC这些,那AAC在高音质的生产还原上有非常好的一些表现,比如说它在音乐场景下就有非常好的表现,在一定码流下让客户听到非常高质量的声音,但是这种高质量的声音就必然带来编码的复杂性,我们实测AAC的编码,尤其是HEV2的这种编码,相对于VOIP音频编码最少要慢一百到两百毫秒。针对这种场景AAC有没有低延迟呢?当然也有,比如LC这种编码,为什么不能用LC呢?因为LC把复杂度降低以后,带宽就控制不住了,它的带宽可能就达到100多K,视频的带宽在某些场景下也才一百多K,而如果音频也要占用一百多K,那这个技术方案就不是特别合适的。

 

所以我们会在互动场景下尽量选用一些VOIP音频编码,这个互动我们主要还是特指比如说一对一或者一对多的这种小班课,对于直播这种大班课一般还是在用AAC。那对于VOIP的一些编码而言,比如说speex能够大概提供最高32K的采样,每一帧大概30多毫秒,在解码端只要加上这三十毫秒再多出一个三四毫秒,基本上声音就能够被渲染出来了,所以它的编码和解码的效率是非常高的,整个环境里面能节省很多的时间,当然speex又会有一些别的问题,因为最高只有32K,它的音质没办法保证,比如老师要放音乐,这种场景就会比较差,所以我们的策略还会有些别的编码,刚才布卡也介绍了,比如OPUS在延迟、音质和码流方面能够做到一些比较好的控制,这也是我们一些尝试的方向。

 

  • 选用合适的传输协议

编码完成后,我们会把它传输到服务器,传输协议的选择也是比较有意思的一个事,一般直播场景的话我们都是在用RTMP来传输,当然它背后就是TCP这种传输协议了,在我们看来它的一些延迟还不是最重要的问题,虽然它有TCP的三次握手,再加上RTP本身的一些握手协议,但是我们认为TCP最重要的问题是说它在网络抖动以后拥塞的处理上有很多问题,它是比较君子的一个协议,就是说一旦发现有拥塞,我是会把网络给让出来的,会减少我的发包,然后他会不断的尝试我能不能多发一些包,直到再恢复,这整个过程是非常长的,在音视频的应用里面,这么长时间的尝试对用户来说,表现上可能就是音视频会卡,效果就很差,弄不好流就断了,很有可能还要重新去连接这个链路。

 

所以我们认为UDP在低延迟互动上是个比较好的协议选择,因为UDP所有的发包、所有的重传都是能够进行自己控制的,所以说这是有非常好的一些优势的,使用UDP以后,我们大概认为在20%以下的丢包音视频体验基本是OK的,不会有非常明显的画面上的抖动这些问题出现。

 

  • 尽量减少数据在服务器的中转

第三的话,就是我们尽量减少在服务器之间的中转,虽然现在各个服务器之间,无论是IDC,还是云厂商,这种服务器对服务器之间的网络带宽很好了,这个Ping值也都比较高,但是从我们实战的情况看,很多服务器厂商之间也都还在50毫秒之间,也就是说服务器中转一道就要花50毫秒,如果是一个三层的中转结构,在这方面的带宽延迟就已经达到了到两百到三百毫秒,是非常不划算的一个事情,所以我们尽量减少在服务器之间的中转。

 

  • 客户端应用层零缓冲

客户端层面上的一些缓冲,我们认为这个数据发送给了客户端,客户端在交给编码器之前有一个编码器的小的Buffer,这个Buffer我们认为一般也没有什么可优化的空间,因为这都解码器自己来维护的,我们说得这个零缓冲主要是在应用层,为什么要加这个应用层的缓冲呢?主要是为了抗抖动,这个缓冲大了,那我有些抖动是能够抗过去的,在这里面的一些策略也比较好理解,就是网络如果足够好,那我们的缓冲就要足够小,接近于0,如果发生了一些抖动,我们可能要动态去调整Buffer的大小,可能要把它加大,当网络好了以后,我们再慢慢把它调整回来,这是一些基本的策略。

 

当然我们对于抖动来说,刚才其他分享者也介绍过,尤其在教育场景下,我们认为音频是比较重要的,我们可能会选择在服务器端,如果发现这个用户带宽不够的场景下,我可能会选择少发一些视频数据,比如把平时数据全部都丢掉,然后用这种方法来减少客户端带宽的一些消耗,这是我们对于低延迟的一些处理的办法。

 

2.单教室用户数量有限+地域分散

 

我们接下来说一下第二个特点,就是用户数量有限,我们的教室或者说我们的房间很难想象像直播秀场类的业务,动辄几万人,搞不好十几万、几十万都有,但是我们的教室人数一直不会特别多,这个是为什么呢?其实这也是基于业务特点来的,因为我们开这个课主要是为了教学服务,而教学的质量是随着人数增加而出现衰减的,也就是说人数越多,教学的质量就越差,你也很难想象一个老师面对一万个人在一个直播教室里面进行教学,可能仅仅是打赏的刷屏量就会让老师分心了,所以这样的教学内容是很差的。

 

那我们大量看到的课程是什么样的呢?一对一或者一对五、一对六,这种课程是很多的,一般的一些班课也都是在一对五十到一对一百之间,规模都不会特别大,当然我们也有特别大的课,比如上万人的课,这些课程主要用于老师招生的,一般都是一些免费课,大家报名就可以上,但是这种万人课的目标并不是真的要在里面去讲授知识,而是让这些用户能够在线下转化成他的一些付费用户,这才是他的最终目标,这类课程上完以后,很多助教或者教育机构的同事会把这一万个用户都筛一遍,去促成转化,这些特征就造成了说我们单个教室的用户不会有那么多。

 

 

基于这些特点,我们在服务器这端有些简单的设计思路可以跟大家分享一下:第一就是媒体服务器,我们不会像很多CDN节点一样,分很多级,然后有很多转化的一些事情,我们就是非常简单的分为两级,一个级别是上行节点,一个级别是下行节点,为什么这么分呢?我们的目标也是说,要简化整个转发的逻辑,如果不是因为转发逻辑复杂,我们很可能一级节点就做到这个事了。第二是我们的课程预约机制,一般都是学生先报名,报完名以后,才说这节课要怎么来上。我们会根据人数预先分配一些服务器的地址,分配一些服务器资源,这是我们可以提前做到的,那我们可能会把一节课分配到一个上行节点,然后一组下行节点上,这个是根据报名人数来的。

 

那每个教室的人数上限到底是多少呢?我们认为是受限于上行节点的带宽的能力和服务器本身性能。举个例子,按一个教室老师发500K码流算,如果一个上行节点能够去转发500兆下行带宽,那他就可以转发1000路,因为我们是两级节点,1000路又可以转发1000路学生出去,所以我们认为我们设计的单教室这个能力,大概是一个教室可以满足一百万个学生的,但是这种数量级只是个设计目标,很少能够实现。我们一个教室有平均大概也就在几千人,一般是一个比较常规的量。单教室大概是这么一个能力,那我们整个服务器集群的能力理论上是没有上限的,因为我们是通过水平方式来进行扩展的,然后把不同课程调度到不同的服务器上,所以用这种方法,只要去增加服务器,就能够增加整个系统的负载情况,所以我们的设计目标是整个机群的负载是没有上限的。

 

第五个思路就是服务器被动式拉流,这个主要是为了减少带宽的一些使用。第六个,我们会对服务器有比较多的监控,如果这个服务器的带宽使用已经达到它的域值,那我们可能会把它会通知客户端,让客户端调度到别的一些服务器上,这些监控或者调度的策略在整个服务器的稳定度上有非常大的一些考量。最后就是我们会对着边远地区,或者海外,或者教育网,这些网络不好的地方架一些代理节点,后面我们会专门说一下海外的代理节点的设计是怎么样的。

 

3.音视频+文档+问答业务

 

然后我们再介绍下文档和业务的特点。文档在教学过程中非常重要,就像我们今天的这个PPT一样,如果老师要讲清楚内容,没有文档和标注是完全不可理解的。

 

 

  • 静态文档和动态文档

我们文档一般会分为静态的或者动态的文档,静态的就比较简单了,我们着重说一下动态文档,我们动态文档的处理跟布卡的思路很像,我们也是把它转成了动态的HTML5的动画,所以我们也在采用一些第三方的插件来完成这些事情,这样老师动态的PPT就通过插件转成HTML5的动画,或者是flash的动画,我把这些文档或者这些HTML5的页面分发到Web Server上,用户在进入教室以后,首先把这些文档一次性加载下来,他的动画就和老师那端保持同步了,老师讲解到哪个动画,客户端就触发对应的动画,从而完成一个动态PPT的展示过程,这就是我们动态文档的做法。

 

  • 文档标注和音视频内容同步

此外文档的标注和音视频内容的同步也是个比较麻烦的事,音视频在客户端是有一定缓冲的,这个缓冲是随着网络环境不同,每次缓冲的时间也不一样;PPT又和文档走的不同的信道,我们怎么保证它门是同步的呢?我们在采集端,或者在产生内容这端的时候可能时间戳就已经打好了,打好以后,我们会在渲染端进行相应的这些配对的显示,用这种方法来达成它的同步。

 

  • 聊天问答服务的虚拟分组和流控

聊天问答,也就是文字聊天的这个问题在普通的聊天室也经常遇到,就是一个500人的教室如果老师问一些问题,很多学生都用文字的方式来聊,每一个文字都会被其他的同学看到,五百乘五百就是两万五千条这个文字数量,先不说服务器能不能扛的住,客户端刷屏就受不了。客户端我们现在用HTML5的弹幕节点来画,弹幕节点的能力大家也知道,渲染多了就卡的不行,所以我们认为在整个聊天业务里面除了老师和助教的文字是很关键的因素以外,其他学生与学生之间本身的文字聊天是没有必要让所有学生都看到的,所以我们在学生这面做了一些虚拟分组,思路上就是要把整个转发量给降下来,把渲染量给降下来;流控就是我们每个用户每秒能够刷的条数,这个对于客户端也是非常关键的,不能让客户端无休止的去刷这种文字聊天。

 

4.直播课程回顾,学习场景再现

 

我们最后的这个业务就是课程回顾,就是学生上完课以后,要有一个回看的过程。回看我们认为是非常简单的,就是一个录制的功能,录制的内容要被学生看到。录制也会分为两种,一种叫本地录制,一种叫云端录制。先说本地录制,本地录制我们会用抓屏的方式把整个用户桌面的那内容抓下来,包括声音,在本地形成视频文件,用户就可以进行回看了,也可以进行复习,老师也可以拿这个视频文件进行二次分享,这都是业务里面经常遇到的,它的问题一方面对于老师来说版权是无法保护的;第二方面,就是我们在很多场景下,用户机器的性能没有想象的那么好,他在录制的时候,造成CPU的升高,这种问题非常难解决。

 

 

而云端录制就解决了这些问题,因为我们的音视频所有的数据,包括白板在网上已经有了,正常的流程或者说我们云端录制的流程,就是客户端会去做一次触发,通知给云端录制的模块,云端录制的模块让信令服务器去把用户进出的数据、白板的数据、标注的数据、像文字聊天的数据,统统都把它录成资源保存起来,并且进行加密的工作,通知给媒体服务器,媒体服务器会把所有语音的信息、视频的信息,把它录成服务器的视频文件,然后进行转码的动作,这块本来不需要做转码,但是为什么我们这有呢?是因为客户端种类的不同,所使用的文件格式也不一样,比如我们这是TS流,那Flash如果用网页播,可能是FLV的或者是MP4的文件,我们在这块加了一个转码的动作。

 

把这些资源都准备好以后,会通过WebServer发布到CDN,回看用户就会根据课程的内容,把这个课程所有的资源都下载到本地,然后把它展开、进行渲染,如果是图片就加载图片,如果是文字聊天就加载文字聊天,如果是视频就加载视频,然后进行播放,所有的内容应该都是同步的,最后进度控制这部分,是说我们可以让它set到某个时间段进行播放。在整个场景里面还会有一块比较复杂的技术问题,就是我们云端混音和混视频的问题,因为我有很多同学可能会同时发言,他需要去混这个视频,混视频我们在后面还会有涉及,先不过多去介绍。

 

多媒体硬件的融合

 

我们说下多媒体硬件结合的一些情况,在教育场景下,周边的硬件设备非常多,首先比如说我们的写字板,写字板本身没有什么技术问题,它主要是写字板本身和操作系统一些触屏的兼容,这些都会在软件里面进行一些处理。双摄象头,在一对一这种业务场景里面,一般是说一个摄像头对着老师的书写内容,一个抓取老师的头像,这个对整个沉浸式的教学有非常好的表现,但是双摄像头的问题在于,硬件本身的稳定性和USB总线供电问题,这是个严重的问题;监控设备和硬件视频会议,在教育场景也是经常会被接入到教学系统里的,因为很多学校都有相关的硬件设备,这部分接入存在的主要技术问题就是我们在客户端,或者服务器这端要兼容更多的传输协议,比如说RTSP、RTMP、H323、SIP这些协议,只要建好这些协议基本上就没有太大问题。

 

1.双师业务模式

 

 

双师业务是最近发展比较火的一个业务,很多教育机构也都在尝试,双师的基本业务形态就是一个主讲老师在主讲教室,一个辅导老师在远程教室,主讲老师主要负责课程讲授,辅导老师则是负责监督另外一个场地学生的秩序,和进行答疑的一些工作。那他最重要的这个形态是什么呢?这张拓普图大概能做一个简单示意:有一个主讲教室和一个远程教室,通过一些软件系统,比如说像百家云,通过互联网或者校园网的系统,能够把音视频数据双向的进行传输,达成在一个教室的里面这么一套系统,当然走到互联网上的话,老师也不见得非要在一个物理的教室里面,他可以在家里授课,同样的学生也可以在家里进行听课。

 

2.双师业务周边硬件

 

 

在这两个物理教室上有非常多的一些硬件需要去配合的,比如说摄像头、麦克风、音箱书写的白板,还有远程的视频画面,同样远程教室的硬件也是一样的。我们具体看一下周边的硬件,硬件其实挺多:视频模块一般有高清摄像头+视频处理器,或者摄像机+采集卡;音频模块会比较复杂一些,有这种专用的小蜜蜂麦、全向会议麦克风,主要是为了整个会场里面的采集用的,还会有话筒阵列,很有可能在一个教室里面有六组,在任何一个场景下聊天都会被正常的采集;还有一个重要的模块——音频处理模块,这个是消回音、混音的硬件设备,在一个物理教室里面纯靠软件进行消回音或者混音这个效果都非常的差,一般我们会采用硬件的专业设备来进行。

 

 

音响模块就是功放和音响;显示模块就是投影仪、电子屏;书写模块也会比较复杂一些,一般会有这种压杆式的电子白板,或者是红外的电子白板,或者触摸屏的,比如说触控一体机就是一个比较好的选择;软件系统这里面最重要的问题是说,这里面都是用硬件拼出来的,所以软件系统非常大的一个工作量或者技术点,就是要把硬件的特点和功效能够发挥到最大,配合在一起,能够消掉所有的回音、能够清楚的听到所有人的聊天,这才是这个系统最复杂的地方,目前百家云已经有几套推荐配置能够达成这样的效果。

 

3.VR直播(全景视频直播)

 

此外,我们也做了一些VR直播的尝试,当然这件事也是跟一些厂商一起合作的,就是传统的一体机来进行的一些尝试,那主要能解决什么问题?解决拍摄、全景画面的拼接、视频的编码,然后通过内部协议传送给我们客户端,我们客户端会根据自己的要求把这些传输协议重新打包一次,然后发送给我们自己的媒体服务器,这样学生端呢就能够正常的进行观看了。在学生APP端,如果发现是一个全景视频,它可能以全景的方法或者全视频的方案进行显示,学生带上VR头盔就可以用移动的方法来观看视频的每一个环节;如果是PC端,那我们会用一些全景的插件,比如说krpano,然后用裸眼的方法、用手触屏的方法能够看到所有的效果。

 

 

我们实际的效果是什么呢?我们在测试环境下,或者有些真实上课的场景下,我们跑到一兆码流,实测的延迟大概在两秒,我们推上来的延迟还蛮低的,在三百多毫秒,但是为什么渲染端就达到了两秒呢?主要是我们渲染的模块,CPU的问题,还有本身画面剪裁的问题,它绘制的效率在我看来还没有那么强,结论是什么呢?结论就是这种课程在教学场景下用于单向传输,比如说瑜珈课程,或者舞蹈课程表现都不错,但是对于互动性比较强的K12课程体验还没有那么好。

海外用户的直播保障

第四部分,我们说一下海外用户的直播保障的问题。举一个美国的例子:从美国的服务器发送数据到国内,我们检测一般正常在UDP场景下是2%的丢包,从海外传到线路损失了2%,但是我们国家还有防火墙,过了防火墙,丢包的抖动性就要非常的大,偶尔一个包都不丢,但是在晚上高峰的时候,很有可能2%就变成20%,弄不好变成40%,当然没有不通的时候,基本上还是以丢包为主。所以在这种场景下,我们要解决海外问题最重要的就是解决线路问题,好在我们国内有一些厂商提供了比较好的这种专线服务,所以这件事情变得也就简单起来,我们只要能够在海外,或者国内架设两组中转的节点能够让用户在专线上跑数据,整个事情就OK了。

 

 

通过调度把海外老师的数据传送给海外的这些服务器,再由海外服务器指定好传送到中转节点,再由中转节点传回到国内,整个体验都还不错,我们实测如果从美国传过来,我们大概是能够在200到300毫秒接收到音视频数据包,当然从欧洲过来会比较复杂一些,欧洲传到香港本身的延迟已经三百多毫秒,正常看起来就是三百多毫秒,偶尔的线路能够达到两百,传回到国内有又得加两百左右,所以它整体的延迟是在三四百毫秒之间。反向的话学生也是这样,学生把数据送给节点,节点再传到海外,整个这部分业务在我们现在线上跑的也还是不错的。

 

直播连麦在教育场景的意义和处理

 

最后我们再说一下直播连麦在教育场景的意义,我画的这个流程可能是比较老的流程,因为连麦这个业务本来也是在飞速发展的,每家做法不太一样,我们自己做过一些,也跟一些CDN厂商聊过。

 

1.直播连麦的处理流程

 

我们大概的流程是什么呢?首先主讲人和上麦者是使用特定客户端的,我们不会直接让他走一些像OBS这样的软件,我们肯定都是特定的软件,然后双向的传输走UDP,整个的交互就主讲人和上麦者本身的同步性都是不错的,包括延迟这部分的处理都不错。在服务器端,我们会把主讲人和上麦者的音频和视频混在一起作为一路,在系统内转发或者推送给CDN,其他用户就只使用这路混音的数据流观看,当然这也是现在的一些做法,很有可能我们会在这个线路之间进行选择。

 

2.优势

 

它的优势很明显,就是能够节省客户端观看者的有效带宽,看一路总比看两路节省带宽是非常简单的道理;观看者的同步性也很好,无论你客户端的缓冲有多大,它在上麦者和主讲人本身交流的同步已经保证了。第三就是我们认为的在研发上观看的逻辑非常简单,适配H5适配的比较好,包括微信这个场景适配的比较好。

 

3.改进

 

当然需要进的地方也有一些,我们服务器混音和混视频造成的物理延迟,一般我们会造成一个50到100,或者有时候会更长的延迟,具体看混的数量;视频布局的固定,就是混完以后视频已经是固定下来了,你很难在观看者去切换整个视频的布局,你用手机去观看的时候这个体验还没有那么糟糕,但是在PC上布局的时候,它就非常的麻烦,尤其在教育场景下的布局,因为我们已经有一个大的PPT了,那你两路视频在一个画面上要看清楚,这个体验就不是特别OK的。第三个就是我服务器硬件的投入还是比较大的,我们认为一个16核的机器大概只能混到几十路,如果一个晚上同时有一两万节课在进行的话,这个服务器的数量投入也是非常巨大的。

以上是我今天介绍的所有内容,非常感谢大家。

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

张弩

百家云

架构师

文章

粉丝

视频

相关文章
阅读排行
  • 2周
  • 4周
  • 16周
热门视频

WebRTC视频数据流程分析

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