在 1024 程序员节这天,我们举行了 RTC Dev Meetup 活动,和开发者们一起过了一个实时通信质量"治虫日"。 活动开始前半小时,就有不少开发者到场了 在活动上,声网Agora数据平台首席架构师何丰与声网Agora资深工程师毛峰,基于实际案例分享了如何发现、分析、判断通信质量问题,以及声网为开发者免费提供的质量监控与分析工具"水晶球"的使用。 1 通信质量背后那些事 从直播、社交、教育,到游戏、IoT、金融等,目前声网正为各种各样的产品提供着实时通信服务。但我们认为作为通信云服务,服务不应止于通信,后续的通信质量监控与分析对开发者同样重要。声网Agora数据平台首席架构师何丰,在活动中详细介绍了声网自研的通信质量监控与分析工具"水晶球"(Agora Analytics)的技术指标及其技术挑战。演讲中有很多技术细节与经验,可以参见我们此前的分享。 "水晶球"(Agora Analytics)是声网Agora 为开发者免费提供的一款实时通信质量监控与分析工具,可以为开发者提供端到端的全链路通信质量数据,包括用户端设备性能(如 SDK 对 CPU 的占用情况)、系统、上下行网络丢包、音频与视频发送帧率等信息。开发者在进入 Dashboard 后,可在左侧边栏找到并使用"水晶球"。 "水晶球"的主要作用有两点:第一,解决"通话体验差"无法定义的问题,开发者可以通过"水晶球"的可视化数据清晰地看到遇到的问题类型,以及问题的严重程度;第二,通过水晶球可以判断质量问题是什么,从而快速找到解决方法。 目前"水晶球"已经发布第一个版本。"水晶球"可以让开发者实时地查询到每一通通话的质量情况,包括上下行码率、网络上下行质量、用户行为、用户设备性能与状态等信息。我们将这些数据信息全部进行了可视化处理,能让开发者一眼看出问题所在。至于如何分析?一会告诉你。 可能你会想问,是否能提供比如丢包、抖动等更多的数据。其实目前,已经可以通过"水晶球"看到每个通话的丢包情况,而抖动以及更多数据指标,还会在之后的版本中陆续提供给开发者们。 现场有开发者问及"这里的实时性到底是意味着多久"。由于涉及到大量数据的收集与前期处理,目前水晶球可以查询到2分钟之前的通话数据,可以满足大部分开发者对质量查询及时性的要求。当然,仍然有不少开发者会希望能更快地发现和分析质量问题,所以我还会不断地对这"2分钟的延时"进行优化。另外,目前开发者还可以回溯近 3 天内的通话质量详情。 2 实例解析:通话质量问题 为了让大家更容易理解如何分析通话质量问题。资深工程师毛峰分享了几个实际案例。 首先实时音视频通信的主要质量问题分为以下几类: 1. 音视频不可用(音频听不到,视频看不到等) 2. SDK不稳定(比如崩溃等) 3. SDK性能差(比如 CPU 占用过高等) 4. 通话体验差: 1) 音视频卡顿 2) 视频模糊 3) 音视频延迟 4) 音质不好(回声,噪音等) 5) 音画不同步 6) 首帧出图慢 从声网的角度来讲,我们有一套标准的质量评定规则。譬如,当视频通话时,如果发送端的 Video Send Loss >40%,且比例超过了 10%的时候,我们认定上行丢包过高,也就是说上行的网络较差。 再譬如,音频通话时,如果发现卡顿时间 >3s,且卡顿时间 ÷ 通话时间 ≥ 8%;或卡顿次数 ≥20 ,且通话时长 ÷ 卡顿次数 ≤30s,那么这时视为音频出现比较明显的卡顿。 当然,这只是其中的两种情况,你可能还遇到过网络异常、录音声音等各种各样的问题,对此,我们也有相应的评定标准。 如果遇到这些问题,通常开发者需要按照以下步骤来调查问题: 1.首先,需要了解音视频通话的基本原理/流程 2.然后,收集好问题信息:通话的频道号,问题出现的时间,出现问题的UID,具体问题细节 3.然后,利用调查工具"水晶球"来定位/解决问题 如果通过"水晶球"来看,通话中的质量问题会是什么样呢? 在 QoE 页面中,横轴以上显示视频接收码率,横轴以下则是音频接收码率。 当你发现一个通话中出现异常曲线(如下图中红色曲线)时,可以点击"查看详情",当鼠标悬停在用户 ID 上时,该 ID 对应曲线会显示为高亮状态。点击有 ID 就可以进入 E2E(End to End)页面进一步查看端到端数据,分析原因。 在下图这段通话中,我们可以看到右侧接收端用户的视频出现卡顿,有明显的红色虚线。 在进入 E2E 页面之后,你会发现发送端用户(左侧)视频上行码率较低,且网络丢包较多,这说明发送端的网络较差。再对比查看出现丢包时接收端的下行码率,同样出现了卡顿。那么我们得出结论:接收端的视频卡顿是由于发送端网络问题导致的。 再举一个例子。在下面这一通话中,后半段通话图表中突然出现了较多的红色毛刺,说明出现了视频卡顿。 进入 E2E 页面查看具体通话数据。在发送端这一侧,所有数据显示正常,但是右侧接收端的下行网络出现较多的丢包,而且视频卡顿与网络丢包的时间点一致,所以可以判断是接收端自身网络问题导致了他的视频卡顿。 当然,有些时候,视频、音频的质量问题,不一定就是因为网络问题产生的。也可能因为硬件设备性能太差导致的,比如下图中的通话就是如此。 在活动的后半程,开发者们分为不同小组,与我们的资深工程师们深度交流了 RTC 应用开发中的问题。 深度交流环节 1024 ,与开发者一起吃蛋糕 不同主题的 RTC Dev Meetup 还在将陆续登陆更多城市,敬请期待。 |