在线教育场景下对提供稳定、高质量的音视频服务提出了非常高的要求。而不断推陈出新的课堂形式以及新技术的应用,使得好未来自研音视频SDK面临更多的挑战。
LiveVideoStackCon 2022北京站邀请到好未来音视频开发高级专家郭晓明介绍好未来自研SDK在工程化上所做出的努力,包括遇到的各式各样的挑战以及所采用的对策;同时介绍好未来客户端如何在以客户体验为主旨的前提下,合理调度自研与第三方服务,以提供更加良好的课堂体验。
文/郭晓明
整理/LiveVideoStack
大家好,我是郭晓明,我分享的主题是在线教育场景下客户端的实践与优化。
我先做个自我介绍。我来自好未来直播中台客户端团队,主要提供多引擎支持的RTCSDK,并为前台提供基础的音视频服务。除了RTC,也包括点播云等等各项能力。目前我们的客户端团队为大班云、素质、学习云、1V1,包括大学生等很多的业务线、多个场景都提供了支持。目前我们的自研引擎在很多的业务场景之下都占比超过了90%。
本次分享分为六个部分,第一是在线教育应用的特点,第二是RTC的典型场景,第三是核心指标。第四,在这些场景之下有哪些优化策略,第五是全面的支撑体系,第六是未来的挑战。
-01-
在线教育应用特点
第一个特点是高质量,高稳定性。这是有别于其他RTC场景的特点。没有一个应用能够像在线教育这样要求这么高的质量。一个字,就是稳。为什么要求这么稳?
这里引用了一个示例如图:老师的网卡、软件卡,还有闪退、黑屏什么的,老师讲课需要连贯性,上面这些情况出现一种,调动起来的积极性就没了,出现个两三种,这堂课就白上了。就是说,除了平时的一些质量要求,它(在线教育)要求讲课需要连贯性,过程中不断积累,到了最核心的那一刻——啪——卡了,那就不行了,这堂课就白上了。
第二个特点就是多:业务角色多、课程模式多、业务场景多。
为什么角色多?老师有主讲老师、辅导老师、监课老师。学生分组的时候是同组学生,上完台是上台学生。家长还要旁听。
直播模式分为三分屏、半身、全身、小灶课、真小班、优网、自习室。课程模式多。
接着是复杂的业务场景。旁路转推、跨房间推流、辩论会、辩论赛,一共列全了有50多个。
基于这两个相同的特点,引出SDK的设计理念。首先第一,易用性,得让业务用得爽,简单点不容易出错。第二,可扩展性。灵活、迅速响应,设计的时候有没有足够的扩展性在里面。第三,数据驱动,详细可靠的数据支持。第四是安全合规。
-02-
典型的RTC场景
接着就是典型的RTC的一些场景。场景太重要了,刚才也提到场景很复杂,那到底是怎么玩儿的呢?我们看一下。
首先,举个3V3的例子。为什么举3V3呢?3V3是我们第一个真正全面使用RTC的场景,而且是一上线就取得了非常非常好的反馈的一个场景,就是从RTMP时代转型到RTC时代的标志性的点。这是一个三分屏的3V3。什么叫三分屏呢?老师的屏幕分为了三个部分,右上角是头像区,左边是课件区,右下是聊天区。为什么叫3V3呢?左边三个孩子,右边三个孩子,他们在一块儿互动,所以这是一个3V3的场景。它的整体图是什么样子呢?
如图所示。最上面的是老师的房间。学生以观众的身份进入老师的房间去拉流。这个房间会很大,有可能几万甚至十几万的学生都会在里面。另外学生会加入自己的一个小房间,就是刚才那个3V3的小房间。
家长怎么旁听呢?家长首先进入老师的大房间去拉流,也进入学生与家长的专门的一个小房间。
为什么这么做呢?因为我们的业务很多很多。家长跟学生之间的小房间形成一个规则,这样无论学生在哪个课程上课,家长都能够很容易地接听到自己的孩子。
接着看第二个,左边的老师用了两个设备,一个是iPad,一个是安卓。
移动授课的老师通常用平放在桌面的iPad进行课件展示和绘图。这样就会有个问题,iPad的摄像头采集的是老师的下巴,老师还低着头,然后每个老师都变成了双下巴,那肯定不行。所以需要一个辅助设备在旁边当摄像头,这样就是两个设备。
但是两个设备会有一些问题。首先,最难的点是音视频同步。麦克风用安卓采集不行吗?如果有一天安卓设备坏了,或老师需要关闭视频,我们也需要保证老师能正常上课。iPad可以支持课件和语音,这堂课也是能够完整地上下来的。这就是它的一个设计理念。
另外一个需求是画板要跟老师的语音同步,我们加入音频SEI,根据SEI对齐课件的画笔,这样老师的语言跟绘画动作是在同一个时间轴里面的。
图中是AI课场景。云端下发一系列video list,由播放器SDK播放,真人互动的时候再唤起RTC SDK,然后再做交流。
同屏小班课场景有多路流音视频的上/下行需求。
例如,A只采用老师的麦克风;B包含课件信息、学生的发言;然后C是在某些特定条件下需要屏蔽某个发言。整个业务场景非常复杂。
有几种解决方案:首先是多进程。但不太友好,为了加一路流,需要客户端服务器整体改,还要能够找到老师的匹配规则。所以我们决定使用SDK支持同一个用户推多路的音视频流,目前客户体验和支持都比较好。
另外一个场景就是全员开麦,30多路流同时开始,还要选定多个设备进行语音增强、输出。这里面有一个优化点,稍后会讲到。
-03-
核心指标
在线教育都关心哪些核心指标呢?
第一点,最关心的指标——客诉指标。第二卡顿,第三音画同步,第四延迟,第五性能。客诉指标是一个结果指标,如果下面四个做好了,客诉指标也会变得很少。
这是客诉指标的示意图。需要分析引起客诉的原因,针对用户的网络还有设备进行微调,解决相应问题。
客诉指标显而易见,其他的数据指标如何来呢?
首先,其它数值指标在线上运行时要综合各家引擎的统一逻辑,形成统一的指标。第二,要建立一个科学的测试和评价体系。
为了进入第二点,我们就建立了音视频实验室,目前可以做到:第一,发版前进行验证,保证质量;第二,对友商进行评估并了解自身产品在行业中的位置;第三,帮助自身产品更新迭代,对成果进行验证;第四,可以学习音视频行业的评测技术和方法,提高能力。
从前期看我们投入了一些人力物力,几年过去了,我们觉得自身SDK的进步都离不开这一个音视频实验室的建立,可见当时的决策是正确的,做难而正确的事。
目前实验室的音视频能力已囊括多方面,包括3A测试、音质测试、视频帧率、卡顿率、延迟、同步等等。
接下来介绍一下全流程卡顿的测试方法。这是一个简单的推拉流流程,具体操作流程是:通过HDMI输入视频采集卡中,用分析终端进行高帧率的信息采集,然后判断视频是否有变化,如果没有变化,就认为是帧没有刷新过来。目前检测是程序帧间隔超过500ms为卡顿,卡顿率统计为卡顿时长/总时长。
上图是具体的卡顿计算方法
接下来是全流程延迟测试方法:首先是推流端上生成一个时间戳二维码,然后由分析终端进行信息采集,与上面的(全流程卡顿测试方法)是一样的,只不过分析终端出来以后会分析二维码数据,二者就会形成时差即为视频延迟。
然后是音画同步。拉流端拉完之后将音频与视频分别放在不同的声道里。视频通过光敏电阻判断黑白块,黑的时候发出一个信号,白的时候发出一个信号,音频会检测特定的声音,通过分析左右声道里的时差来得到音画不同步的指标。
可以看一下计算方法,其实也很简单,一个左声道一个右声道,分析两个声道的时间差,大于200ms就认为触发了不同步。为什么是200ms呢,因为我们认为一个人平均1秒说5个字,所以200ms就可以了。但是调研团队认为英语的发音可能没有这么慢,是不是需要把数据进行更新,这还在我们的调研之中。
另外一个就是我们比较关注的性能指标,目前较为关注CPU以及内存的数据。
-04-
场景下的优化策略
场景下的优化策略分六点去做:第一是优先拉流,第二是大小流,第三就是跨设备音画同步,第四是刚才所说的多拉流的一些优化,第五是AI课的回音问题,第六是流畅模式。
首先说优先拉流,其实在这个场景里很好做判断,老师的流比学生的流重要,当带宽评估不足的时候,会优先保证老师的流量码率,剩下的由学生进行平分。
第二个,大小流。例如在紧急的时候、看不见老师画面的时候提供一个解决方案,让用户还可以看见老师。我们的产品设计得很人性化:切流通知会经用户确认再进行操作。
接着是优化结果,经过优先拉流、大小流的策略,卡顿率是明显有优化的。
接着说跨设备音画同步是怎么做的?首先,各个端要进行中央时间戳的同步,包括信令服务器。当用户一进去的时候,第一时间和信令服务器进行同步,这样的目的就是为了防止和后续的一些周期性同步变得特别大。安卓是周期性进行netp校正,这样能保证音视频出来的时间戳是差不多的,再通知iOS和安卓去绑定音视频流,这样来做到音视频同步。
图为NTP同步计算方式
接着说拉多路音频的一些优化,第一个是我们进行了关键点的监控,检测出有没有性能问题;第二是优化策略,一个是静音包检测,静音包不参与解码;另一个是优先保证关键角色。
大致流程是这样的。在Render现场里会有一个统计信息,同步到Mixer策略里面,决策哪些流可以进入后续的流程里。前面提到多流的时候老师可以设置关键角色,那么关键角色是老师,学生是接下来要保证的,最次级的是vad的引流。当出现问题,会按照优先级逐级去优化。
接着就是AI课的回声问题,如何解决回声问题?AI的视频是由RTC SDK播放并进行回音消除。第二,音画同步问题,RTC SDK通知播放器当前的剩余播放时长,进行一些优化。剩余的就是pause、seek等等细节的处理。
我们认为产生buffer的点是两个,一个是业务方,可以理解为APP;另一个就是RTC SDK的内部,这两个加起来就是buffer产生的点。我们会告知播放器目前有多少时长差值,这样就保证了音画同步。
最后一个就是流畅模式:第一点是特定的老款机器默认不拉其他学生的流,只有老师;第二就是检查到卡顿,提示学生进入流畅模式关闭视频。
-05-
全面的支撑体系
没有全面的支撑体系,SDK就不会特别流畅地支持业务,要做到那些支撑呢?
第一点,关键点上报,目前应用到统计告警里面差不多有70个的指标,我们会将这些点统计上来,然后进行各种告警、各种事件的分析。
那么什么是关键点呢?第一,需要统计的点,第二,有助于解决问题的点。我这里有两个例子。一个是家长说,孩子爸爸一回家,孩子就没有声音了,最后发现是爸爸的蓝牙耳机的问题,我们给加上一个路由就好了。第二个是老师给学生上垃圾分类的素质课,好多学生录不上声音。后来发现,是因为这堂课学生经常会说“这个是什么垃圾”“那个是什么垃圾”,“垃圾”被识别为脏话,就被禁流了。
上报的注意事项有定时上报、压缩上报、限速上报、资源占用、丢弃策略。这五个点,每个点都是一种复盘。简简单单的上报,可能引起很多问题,要知道上报是不能和音视频抢资源的,无论磁盘还是网速、策略,都要做好。
然后就是全链路监控。刚才提到会有一些关键点上报,客户端及服务端都上报后就可以做自动化报警,例如哪个老师内存高了,哪个老师卡顿了,都可以做自动化报警和自动化归因,极大提高整体的客诉执行效率。
配置下发。我们可以做到:功能灰度上线、不同场景的差异化配置、不同机型的差异化配置。我们要求所有线上线下的功能都是可以回滚的,如果达不到这个功能就别上线。
另一个就是全量日志的实时回捞。关键调用流程,很多时候出现线上问题,例如无声、黑屏,大概率是业务调用的问题,这时候要能精确地排查出业务当时的调用状态,呈现核心状态和流水信息。
这是全量日志的解析结果,它也是业务场景化自动测试的一个很好的数据源。
另一个很重要的点,测试人员不足怎么办?办法就是把人工变成自动化,降本增效。目前我们实现了以下几个功能,基本功能自动化,业务流程自动化,还有质量自动化。
上图是质量自动化的一个示例。
多引擎互备,多活双可用。目前我们可以做到核心业务必须是双引擎的,能够做到智能的调度,后续可能有些场景会做一些无感知的切换。
-06-
未来的挑战
更加沉浸式的体验:老师带着去月球背面遨游的这种场景是传统行业感觉不到的。
另一个是越来越多的音画路数,The more the better,这是未来已经确定的。
多种多样的设备支持,如智能硬件、学习机、台灯。
最后是降本增效,首先是场景化编码优化,因为课件大概率是一些静态场景,肯定可以做一些优化。第二是更优的传输策略;第三就是行之有效的流程,通过流程去规范开发或者测试来实现降本增效;第四,向融合RTC靠拢。
我的分享就是这些,谢谢大家。
▲扫描图中二维码或点击“阅读原文” ▲
查看更多
LiveVideoStackCon 2023上海站精彩话题