当前位置: 主页 > 经济 >

1024 RTC Dev Meetup | 我们和开发者一起捉了一次"虫

时间:2018-11-22来源:互联网 作者:编辑 点击:
在 1024 程序员节这天,我们举行了 RTC Dev Meetup 活动,和开发者们一起过了一个实时通信质量"治虫日"。 活动开始前半小时,就有不少开发者到场了 在活动上,声网Agora数据平台首席架构

在 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 还在将陆续登陆更多城市,敬请期待。

顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
发表评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
文章导航
推荐内容