互动直播应对卡顿、延迟、掉线的技术难点实践

LiveVideoStack 2020年5月22日

大家好,我叫张玺辉,来自布卡互动,我做直播很早了,在2011年我就开始做,但那个时候行业还不是很成熟,另外我个人比较固执,就钻到教育领域去了。我在起步的时候,不是因为技术而去技术,而是想解决教育里面的问题,结果就错过了斗鱼、花椒、映客,结果活的很苦。但是这几年折腾下来还是留下了一些技术沉淀,来跟大家分享一下。


两种技术形态



1,从这两年开始,有的是做PaaS层,提供SDK级别的服务,像腾讯、声网、即构都做得不错。他是专注在PaaS层,全行业全领域都在用,像我们做APP就不用去关注底层的什么TCP\UDP,什么编解码传输等等,人家都做好了,调个API用就行了。


2,SaaS层,衍生出很多很多垂直的机会来,像在线医疗、在线教育、电商、客服、企业培训营销等,实际上是垂直行业的应用,这里面的机会是特别多的,因为音视频和工具是这个行业的基础设施,基础设施建设的好了,这个行业的效率才能提高,才能快速发展。


两条赛道


1,第一个跑道里面,人员的技术素质是远远没有第二个行业高的,好多教育公司里面的CTO是网管级别的,就是装装系统,插插网线那种。


2,第二类是游戏和美女直播,这个商业模式比较成熟,技术沉淀各方面做得还是不错的,我们布卡是从PaaS到SaaS,在在线教育领域做了一套整体方案。在2012年我们就开始在做互动了,当时遇到的一个大问题,就是回声的问题,结果没有处理好。接下来我们又在做直播,行业需要这样一种方案,这个方案是直播和互动混合在一起的,因为有时候场景是需要直播的,比如说我这场活动,有一万个人来听,不可能是互动的。有的K12课程里,包括一些教育机构的小班课一对二、一对六,一个老师带几个孩子一起来学,是需要频繁的互动的。我觉得真正好的解决方案是直播和交互要在一个软件里都要具备的,当然我的假设场景是教育。


教育互动直播平台的基本能力


在线教育领域这几个事情都是要干好的,包括媒体、信令。信令这个有点特殊,在一般的娱乐直播中是用不着的。另外,文档PPT、共享、画笔等要求特别高。最后,教育对录制和点播也是要求特别高。



对在线教育而言,服务需要覆盖六个端,一个端都不能少,在娱乐直播领域很少覆盖这么多,一般没有人在做PC端和Mac端。现在大部分老师在上课的时候,还是用PC和Mac,因为PPT等课件都在电脑里,毕竟手机的屏幕还很小。因此我们花了大量的时间在PC和Mac上。


不卡


音视频传输方面,布卡核心是用的UDP,自己设计了一套基于UDP的低延迟解决方案,大概延时在两百毫秒以内,一来一回两百毫秒以内。音频抗丢包,大概在30到50,视频丢包在10%到20%是看不出来的。信令是控制一些命令,比如说让谁上台发言,让谁下线,把谁踢出去,还包括文档翻页、画笔同步。文档是传PPT实现,实际上是要把文档转成别的格式才能同步分享,否则一个正常PPT是分享不出去的。录制点播就比较简单了。



1,协议与开发语言


协议要选对。如果用TCP玩音视频,就肯定会卡的,所以要用UDP。如果是单向直播,用TCP也好,其实是无所谓的。想低延迟和稳定传输的话,建议还是用UDP。语言,要选一个比较好的语言,性能比较高。比如多线程,包括大并发上来能抗的住,一百个并发和一万个并发,服务器的表现是完全不一样的。


网络传输我们用了三种协议,UDP+RTMP+HLS,所有的上传都是用UDP。在服务器把H.264和ACC转成RTMP和HLS,就可以透过网页上去看,并可以把它录制下来。视频的编码器,H.264和H.265我们都支持,我们还做了一个硬件,一个小盒子,专门把编码器独立出来,因为我们发现一个问题,现在普通的PC编个1080P高清的视频,特别是现在教育做得比较火的这种双视直播,他们实现的大部分方案是拿思科的视频会议方案去搭的,成本比较高,如果是使用一个小盒子,相当于一个外置编码器一样,它能够编H.264、H.265的高清。


我们的音频编码是用的OPUS+AAC,实际上核心是用的OPUS,因为网页里是不支持OPUS的,我们在Server端做了一下转化,就把OPUS转成AAC了,整个这么搭起来的,这么搭起来以后,你可以说去做多人连麦,包括网页直播,各方面的都可以支持了。


语言方面我们是C++和GO混合来开发的,整个音视频的处理是C++,GO负责一些业务逻辑,包括集群、调度。最核心的音视频模块,是用C++去写的。用GO开发的好处是效率比较高,并且多线程比较好用,第三出了问题比较好找。我们第一个版本是用C++写的,但是多线程的实现,没有个十几年功底的C++工程师是Hold不住的,经常崩溃。


2,调度和网络


这也是一个很头疼的话题,原来我们想当然做了一个简单的测速,发了几个包出去,谁给我回的快,就连谁。实际上不是这样,现在你的包回来的快,不代表你的丢包率比较低,在实际的连接成功之后的表现是不一样的。其次,运营商的选择。因为存在很多中美之间的教学,跨国的连接也是比较复杂的,怎么去调度?我们现在是测速和调度是合起来,比如判断你是电信的运营商,我给你返回一组,基于地域能覆盖的一组服务器,再进行测速,测速最关键的一点是丢包,音视频的卡顿,延时稍微大一点是没有关系的,只要包不丢,就不用去补,听起来就比较好了。另外,每一次我们测速的时候,都把数据给收集上来了,后面就做了个算法,不断的去优化,包括中间我们也会收集一些数据,看在这个地域下的这个用户连上这个服务器,它的性能怎么样,不断去优化这个调度策略。我们遇到一个小运营商的问题,同行也都遇到了,像长城宽带、电力猫这种网络也不知道什么情况,是从哪拉来的。小运营商的出口就很小,我们在上课的时候,基本上是晚高峰,卡顿率就特别高,这是比较头疼的。



总结下来的策略包括,第一,运营商。让电信连联通的话,肯定效果好不了,你得把它弄到一个运营商里去。第二,地域。说实话,不是一个决定性的维度。第三,服务器负载。因为我们做音视频不可能是一台服务器干活,有好多台服务器,当用户上来以后,把它分配到哪一个服务器上去,是需要看服务器的负载的,CPU、内存、网络如果是已经满负荷了,继续分配过去,肯定也会卡。第四,测速。我们发现把测速做好了优化,还是能解决很大的问题的,我们实际测一下,你今天连着这个服务器好,明天他连就不一定好,互联网这个网络老是变化的。


3,重传+补包+动态网络调节


从软件上能做的补救就是重传+补包,在音频和视频上有很多算法。特别是音频,丢了一些包以后,通过调整一些策略,前后拟合后用户也听不出来,我们上课主要是声音,把这个做好了,其实也能增加音视频的流畅度。



动态网络调节还是一个蛮有意思的一个事,当一个听众说,觉得我这边网络接受不了,我本来是500K的带宽,你非得给我传800K,你怎么优化也是卡,这种最简单,最直观的做法,我去告诉这端的发布端,我受不了了,你少发一点包,他给你把带宽降下来,我们做过实验,不加这个策略,其实卡的是非常频繁的,那你在动态的调节以后,包括有一个算法,它能够预测你后面可能会卡,主动的去降,主动的去调节,这个卡顿率会大大的降低。


4,噪声


最近我们很困扰的是我们音质导致的问题。我们发现一个客户很卡,但网络很好,江苏电信。最后抓包发现,根本没有丢包,在网络上传输非常好,但到了终端以后,因为我们回声消除做了很多工作,结果导致对方有一些噪音又传过来了,就像那个滴滴声音一样,又把好多说话当中的噪音消掉了一部分,导致声音听起来很不流畅。我们找了好多人,最后发现这个事只能通过一些策略上来去控制。现在好多人在做的时候,干脆长戴耳机,把回声消除关掉,就这么粗暴的干。


不掉线


再说说不掉线这个事,做音视频肯定会用到的,因为音视频它是个长连接,不像HTTP访问完了就完了,这里面涉及到这六个方面:



第一,媒体的断线与重连。一个用户一个老师在上课,上课的过程中网断了,这个断了怎么办?或者他不小心碰了一下网线,WiFi就是抖动了一下,就是断了,这个事是需要怎么去判断?


第二,信令。信令这个事很麻烦,因为信令是用TCP来连接的,你不可能用UDP来去做。TCP连接很容易断,你认为是这个用户下线了,还是怎样了?所以说信令断了以后要回过头去看媒体,我看媒体还在发着包呢,还有流量呢,信令就连自己的就行了。这里边,信令和媒体连接综合起来是一个问题,就是你怎么判断用户下线的问题,用户正常的下线是好下线的,我把客户端关了,你肯定是知道的。但是用户突然就崩了,还有一万人在等着看呢,那一万个人怎么办呢?怎么处理呢?他已经断线,信令已经发不出去了,这不是技术问题了,是需要在产品上设计一些逻辑来去让用户体验的更好。


第三,录制断线。我们还遇到了一个录像的问题,你这个媒体断了,他一会儿又连上来了,我的服务器就录了两段,一节课录了好几段,用户点播的时候怎么办?怎么来去记录它是一节课里的视频,而不是两节课里的视频,这个是需要去解决的。


第四,文档请求失败。还遇到了文档的问题,我们把文档转成图片,带动画的转成H5。如果房间里有一万个人,老师打开一个PPT,这个PPT有30多页,这会造成一个流量高峰,是非常危险的。同时,文档经常要HTTP请求,因为各种网络比较复杂,很容易请求不到。比如老师发一个信令告诉你要翻到第三页了,结果这个用户的信令丢了,没有翻页,导致他上课不同步,各种问题就会来了。学生就会在群里说我上不了课了。


第五,服务器之间的上课重连。有的时候我们端到服务器之间做了很多策略,去保障它的稳定性,包括各种的策略的优化,但是服务器之间也不可忽视。我们之前出过很多故障,怎么回事呢?因为服务器与服务器之间不通的,现在比较屌丝,什么阿里云,什么腾讯云,各种云我们都买,买了一堆,我们也不知道它的点到底是覆盖情况怎么样,我们就实际去测,但是云与云之间,它们的点之间经常也是不稳定的,端到服务器稳定了没用,服务器到服务器之间不稳定同样导致这个问题。我们需要一个全拓普才能保证服务器之间,保证到端的稳定性是非常好的。


第六,API接口请求。有一堆API请求,特别是进房间的API是非常关键的,因为一节课并发一上来以后,大量用户在短时间内进来,你要查他有没有钱,他是学生还是老师,在哪个房间里等等,去做状态同步。如果这个API请求失败了,他就进不去了,非常麻烦。


不延迟


延迟就比较简单了,原来我们老追求低延迟,到最后发现比人家快3毫秒、5毫秒的也没价值。真正一个好的产品,在于综合的因素,而不是比较单一的去比技术,这个是没价值的。互动的延迟,就是采取刚才说的那些方案的话,能做得效果非常好的,有的时候在局域网内,能控制在100毫秒之内,包括编码、传输、解码等等。



HLS的延迟,大家也没什么好的方案,基本上就是10毫秒、8毫秒的样子。


Web的延迟大概是1到3毫秒。这里面有一个问题,客户端也好,Web也好,它的延迟非常低,老师翻了一页PPT,老师讲了这个章节,但是HLS那端慢了许多,大概慢了个10秒、8秒,你怎么去估这个值,去跟它同步起来?因为老师在做标记的时候,其实他这个时间已经在这个时间下面,而看HLS的那帮学生还没有听到呢,怎么去估算这个延迟?或者从哪里拿到,他能确定这个终端在当前播到那个时间点跟它去同步,跟他听PPT能够同步。


经验与坑


这几年来,自己去关注这些技术,有几个点还是感触跟深受的:



第一,日志系统。做音视频最好在未做之前,先把日志系统设计好。我们起步的时候就两三个人,也没在意这个事,上来就是先干,结果干完了以后,把系统搭起来的时候,真正运行的时候发现太痛苦了,因为用户说卡了,你也不知道怎么卡,你也不可能把代码再review一下,你也找不到问题的根源,因为音视频有很多环节,到底是媒体、信令,还是服务器之间,各种环节到底是哪一个环节出了问题,定位问题就很麻烦。一个完善的日志系统,对系统的快速开发与故障定位、完善是非常关键的。


第二,产品设计。这个也很关键,我们刚开始想的非常大,我们想把直播和交互合到一个产品里去了,既能做直播又能做交互,可以多人交互,在多人交互的时候,还能做直播,这里面绕了很多的产品逻辑,这让工程师很痛苦,因为人和人直播,和小班互动就是两种场景,你硬把它从产品里面合起来,就会导致技术很复杂,技术的复杂就导致不稳定性。后来,我们就把直播和交互完全分成两个产品,在直播里,我们可以允许一个人当嘉宾去发言,他可以去交互,但是其他的人就老老实实的用网页听就完了,也别想视频发言了。


第三,运维对这个音视频来说还是很关键的。如果运维有比如说百万级的音视频直播的经验的话,还是非常关键的,因为这里面有很多的经验和坑不是光靠学就学的来的,真正你上手操盘和听别人讲故事完全是两回事。


问答时间


Q1:你好,我们都知道回声消除是一个比较大的难点,我想多了解一下,你们对回声消除是怎么样做的一些具体的技术细节?


张玺辉:回声消除这个事呢,我们是从WebRTC里抠出来的,但是WebRTC好多这个做音视频的后期这一帮人都是参考它的,不是说自己写的,但是抠出来以后,WebRTC也是做得比较粗糙,很多场景下面它是解决不了这个问题。另外在各个端,就是Mac和iOS解决的很好,Windows需要去改一些算法,这里边核心就是那个delay值,是要不停的去计算的,根据不同的场景去计算。但有一些场景是无能为力的,比如你说话同时我也说话,两个人在同时说话的时候,它这个表现就会非常差,那怎么办呢?你就静音,先让一个人关了让另一个人说,这个是通策略控制的回声消除。


问题比较大的就是噪声,比如说我敲敲桌子,或者我碰了一下凳子,或者我在跟你视频会议的时候他在旁边说话,把他的声音收进来以后相当于我说话,就把它给消掉了,这里面就很麻烦,需要设一个值,把你认为哪个档次算是噪音,我就直接干脆把它滤掉了。再做得好一点,我看QQ还比较有意思,我一个同事在嗑瓜子,他完全把它给消掉了,包括这种键盘声,消的非常干净,非常好,我们就做不到,后边我们就找了一些人问了一下,还有一个场景噪音消除,这就看什么场景了。


另外就是安卓更痛苦,你做安卓的回声消除,它后来的这些产品,他用的硬件的消除,他加了一个东西,但是不是很好用,还是要有软件的处理,跟PC还是完全是两套算法。

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

张玺辉

布卡互动

创始人

文章

粉丝

视频

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

WebRTC视频数据流程分析

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

移动音视频SDK工程实践之数据采集和处理

李明路/音视频SDK产品技术负责人