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