1.本发明涉及音频通信技术，特别是涉及一种用于评估音频卡顿率的方法、装置、计算设备及存储介质。


背景技术：

2.互联网通信技术的发展使得网络电话、流媒体、音视频直播等的应用越来越广泛。音频实时通信(real-time communication)是这些应用中不可或缺的功能。音频实时通信应用都是基于互联网进行通信的。然而，不稳定的网络环境会导致丢包、延时、数据包抖动等，这些会造成通信双方中的接收端接收到的音频数据包异常，从而出现音频卡顿。音频的卡顿本身是音频体验服务的重要指标之一，音频卡顿的严重程度直接影响着用户体验。
3.相关技术中，通常在音频播放端使用动态的抖动缓存(jitter buffer)技术，以消除上述网络因素对音频流畅度的影响。然而，音频数据包到达接收端后，在从接收端的抖动缓存传输到声卡进行播放的过程中还会经过一系列操作，例如主动丢弃音频帧、清空或重置抖动缓存等操作。这些操作都有可能造成音频帧丢失，从而导致音频卡顿。因此，有必要对这一过程可能造成的卡顿进行评估和量化。这种卡顿的量化例如可以作为参考指标用来衡量音频产品中相关模块设计的优劣，从而推动音频产品在流畅性体验方面的改进。这种卡顿的量化还可以作为一种反馈，以使发送端和/或接收端根据反馈做出相应的响应，从而改善卡顿状况，提高音频流畅度。
4.目前评估音频流畅度的方法主要包括主观评估方法和客观评估方法。一种主观评估方法主要基于测试人员的主观听觉反馈来评估流畅度。然而，长时间的主观评价活动容易引起测试人员的误判，并且这种方法效率低、成本高，不适于推广。客观评估方法主要体现为对音频质量的整体评估。对音频的整体评估主要是根据itu-tp.862 pesq和itu-rbs.1387 peaq等标准进行的。然而，这些标准没有把音频卡顿的严重程度单独进行量化，其中音频卡顿的评估仅是音频质量整体评估的一部分。这种客观评估方法不能直观地反映音频卡顿的程度，因而不适于推进对音频产品的流畅性体验的验证和改进。


技术实现要素：

5.本发明提出了一种用于评估音频卡顿率的方法、装置、计算设备及存储介质，用于更精确地评估音频的卡顿率，以解决上述一个或多个问题以及其他问题。
6.根据本发明的第一方面，提供了一种用于评估音频卡顿率的方法。该方法包括：
7.针对待评估音频设定观察窗口，所述观察窗口包括一个或多个音频帧；
8.针对单位时间内的每一个观察窗口，按预设条件判断该观察窗口是否包含卡顿窗口，并对所包含卡顿窗口计数；以及
9.评估卡顿率，其中，所述卡顿率为所述单位时间内确定的卡顿窗口的累计数量与所述单位时间内的所有观察窗口的累计数量之比。
10.根据本发明的第二方面，提供了一种用于评估音频卡顿率的装置。该装置包括：
11.设定模块，用于针对待评估音频设定观察窗口，所述观察窗口包括一个或多个音频帧；
12.判断模块，用于针对单位时间内的每一个观察窗口，按预设条件判断该观察窗口是否包含卡顿窗口，并对所包含卡顿窗口计数；以及
13.评估模块，用于评估卡顿率，其中，所述卡顿率为所述单位时间内确定的卡顿窗口的累计数量与所述单位时间内的所有观察窗口的累计数量之比。
14.根据本发明的第三方面，提供了一种计算设备。该计算设备包括：存储器和处理器，其中，存储器用于存储计算机可执行指令；处理器用于运行所述计算机可执行指令，以执行上述用于评估音频卡顿率的方法的任一实施例。
15.根据本发明的第四方面，提供了一种非暂时性计算机可读存储介质，所述存储介质上存储有计算机可执行指令，当所述指令被计算机执行时，使得所述计算机执行上述用于评估音频卡顿率的方法的任一实施例。
16.本发明的用于评估音频卡顿率的方法、装置、计算设备及存储介质具有以下优点：
17.本发明识别导致卡顿的两种主要场景，即持续插入空帧场景和强制丢帧场景，并基于观察窗口模式，将识别出的卡顿场景可能导致的主观卡顿感受量化为卡顿窗口计数。通过识别导致卡顿的主要场景可以提高卡顿率评估的精确度，并且卡顿窗口的使用简化了卡顿量化和评估的计算过程。
18.进一步地，在音频帧从空帧切换到正常编码帧时，识别发送端的静音或dtx场景，并排除静音或dtx场景下引入的空帧对卡顿的量化和评估的干扰，从而进一步提高了卡顿率评估的精确度。
附图说明
19.图1示出了根据本发明实施例的用于评估音频卡顿率的示例性系统。
20.图2示出了根据本发明实施例的用于评估音频卡顿率的方法的示例性流程图。
21.图3a和3b示出了根据本发明实施例的卡顿窗口的示例以及持续插入空帧场景和强制丢帧场景下音频帧的示例。
22.图4示出了根据本发明实施例的用于评估音频卡顿率的方法的另一示例性流程图。
23.图5示出了根据本发明实施例的正常播放状态下的音频帧和静音或dtx状态下的音频帧的示例。
24.图6示出了根据本发明实施例的判断发送端是否处于静音状态的过程的示例性流程图。
25.图7示出了根据本发明实施例的用于评估音频卡顿率的方法的一个具体示例性应用场景。
26.图8示出了根据本发明实施例的示例性计算设备。
具体实施方式
27.以下描述中，结合附图以及示例性实施例对本发明做了进一步详细的阐述。然而，本领域技术人员能够理解，本发明不限于这些示例性实施例。
28.本技术提供的用于评估音频卡顿率的方法、装置、计算设备以及存储介质可以应用于任何涉及音频通信的应用中，例如直播连麦、主播pk、语聊房等。
29.参见图1，图1示出了用于评估音频卡顿率的示例性系统。包含音频帧的语音报文从发送端通过网络传输到接收端。如前所述，在接收端的抖动缓存中，音频帧会经过一系列处理，例如丢帧、插帧等。然后，音频帧被传输到解码模块进行编解码，解码模块会对音频数据包进行解码(decode)或修复(recover)操作。可选地，在解码模块之后，还可以设置其他处理模块，例如图1中的播放缓存(playbackbuffer)，以对音频帧进行其他逻辑处理。音频帧最终被传输到声卡设备进行播放。在这一系列操作过程中，对音频帧的各种处理都可能导致音频卡顿。因此，可以在音频帧被解码之后且到达声卡之前，对音频帧的特征信息(例如序列号、编解码情况、时间戳等)进行分析，以识别卡顿并量化卡顿的严重程度。
30.本发明设想在抖动缓存和解码模块之后设置卡顿评估模块，从而能很好地涵盖导致卡顿发生的各种场景，以更精确地识别和量化卡顿并评估卡顿率。
31.根据本发明的一个方面，提供了一种用于评估音频卡顿率的方法100，如图2所示。方法100可以由图1中示出的卡顿评估模块执行，也可以由其他合适的硬件、软件或者软硬件的组合来执行。方法100包括步骤101～103。
32.在步骤101，针对待评估音频设定观察窗口，所述观察窗口包括一个或多个音频帧。
33.本发明实施例中，卡顿评估模块可以从例如播放缓存中获取单位时间的音频帧，然后以观察窗口的方式进行卡顿的识别和量化。
34.单位时间可以根据实际需要来设置，例如可以设置为30秒、1分钟、5分钟等。单位时间内的音频帧可以被一次性获取，也可以在方法执行过程中以数据流的形式获取。单位时间可以被看作卡顿率的一个评估周期。通常，在评估周期结束时，卡顿评估模块计算该评估周期内的音频卡顿率。
35.获取的音频帧被分配到设定的观察窗口中。通常，观察窗口具有固定的大小，并且不会出现重叠。观察窗口的大小可以根据实际应用预先设定。
36.具体地，根据已知的声学统计理论，中国人正常说话的频率一般是一分钟200～300个字左右，即约为200～300ms一个字。人耳对字级别的语音播放中断才会有明确感知，这种能感知到的语音中断被视为语音卡顿。因此，例如，可以将观察窗口的大小设定为200ms。在一个音频帧的长度为20ms的情况下，时长为200ms的观察窗口包括10个音频帧。实际应用中，观察窗口的大小根据需要设定。一个观察窗口可以包括一个或一个以上的音频帧，而不限于10个音频帧，观察窗口的时长也不限于200ms。例如，观察窗口的大小可以根据语言(例如汉语、英语等)和音频帧的长度而定。
37.参见图3a，图3a示出了观察窗口的示例。如图所示，观察窗口的大小设定为200ms，音频帧被根据时间划分到窗口w0、窗口w1、窗口w2等窗口中，每个观察窗口中包括10个音频帧。
38.本发明实施例中，使用观察窗口既能够从“字”的维度很好地量化人耳能感知到的卡顿，又能够简化对卡顿量化及卡顿率评估的计算过程。
39.在步骤102，针对单位时间内的每一个观察窗口，按预设条件判断该观察窗口是否包含卡顿窗口，并对所包含卡顿窗口计数。
40.本发明实施例中，根据导致卡顿的不同场景的特征，对音频帧进行分析以识别这些场景，并根据不同的场景使用相应的卡顿评估逻辑来计算并更新卡顿窗口的数量。其中卡顿窗口是其中包含的音频帧会导致卡顿的观察窗口。
41.从音频帧层面来讲，导致出现卡顿的场景主要有两种：持续插入空帧场景和强制丢帧场景。
42.(1)持续插入空帧场景
43.如前所述，解码模块中主要会进行两种操作，即解码和修复。包含音频内容的正常音频帧(也称正常解码帧)会被解码，解码生成的音频数据流本身不会出现卡顿。当没有正常音频帧可以被解码时，解码模块会进行修复操作。执行修复操作的原因有多种，包括规定时间内没有收到可以被解码的正常音频帧或者理应被解码的音频帧被丢弃等。修复操作会产生空帧，即没有任何音频信息的音频帧。产生的空帧被插入音频数据流中，如果持续插入空帧，则会引起卡顿。在实际音频通信中，解码和修复会交替发生。在一段时间内，修复操作越多，持续插入的空帧就越多，造成的卡顿也就会越明显。持续插入空帧场景也是造成卡顿的最普遍场景。
44.(2)强制丢帧场景
45.通常情况下，抖动缓存会按照音频帧的序列号(也称seq)递增的顺序存储音频帧。例如，音频帧999、1000、1001会按其seq递增的顺序存储在抖动缓存中，后续会按这一顺序被解码和播放。但是，在网络环境比较糟糕的情况下，会出现大丢包或大网络抖动导致的数据包更晚到达接收端。为了接收新到的其他音频数据包，接收端的抖动缓存会强制丢弃某些音频帧，这导致了相邻两个正常解码帧的seq不连续。当丢弃的音频帧超过一定量时，即相邻两个音频帧的seq之差过大时，也会出现卡顿。
46.因此，需要识别上述两种导致卡顿的主要场景，并计算相应的卡顿参数，例如卡顿窗口的数量和待累积观察窗口的数量。出于本技术布局的考虑，待累积观察窗口会在稍后进行说明。
47.本发明实施例中，首先，识别持续插入空帧场景。相应地，步骤102中的按预设条件判断该观察窗口是否包含卡顿窗口的操作包括：
48.判断该观察窗口中的音频帧是否满足预设空帧条件；
49.如果是，则确定该观察窗口为卡顿窗口，并对卡顿窗口的数量进行累计。
50.上述预设空帧条件指的是一个观察窗口中空帧的数量是否大于或等于预设的空帧数阈值。空帧数阈值可以根据实际应用预先设定。通常，空帧数阈值可以根据观察窗口的大小来设置，例如可以设为观察窗口中音频帧总数的二分之一。当然，空帧数阈值也可以根据实际需求设置为其他值。
51.如果一个观察窗口中包括空帧且空帧的数量大于或等于空帧数阈值，则可以确定该观察窗口中出现了持续插入空帧场景。该观察窗口中的音频帧在被播放时，会产生卡顿。该观察窗因而被视为卡顿窗口。
52.举例来说，在音频帧的长度为20ms且观察窗口大小为200ms(即10个音频帧)的情况下，可以将空帧数阈值设为5。因此，如果该观察窗口中存在5个或以上的空帧(即总时长为100ms或以上的空帧)，则可以认为当前观察窗口中的音频帧的播放会产生可感知的卡顿。
53.参见图3a，在观察窗口w0中，序列号为1～4和6的音频帧是正常解码或者可被渲染播放的帧，而序列号为5和7～10的音频帧是无音频信息而不能被渲染播放的空帧。因此，观察窗口w0中出现了5个空帧，空帧总数等于空帧数阈值，因此观察窗口w0为卡顿窗口。
54.判断出卡顿窗口后，需对卡顿窗口进行计数。对于持续插入空帧场景，卡顿窗口数量的计算相对简单。每次空帧的个数超过空帧数阈值时，相应地识别到一个卡顿窗口。此时卡顿窗口的计数值为1，且当前评估周期内卡顿窗口的数量累加1。
55.进一步地，本发明实施例中，还识别强制丢帧场景。相应地，步骤102中的按预设条件判断该观察窗口是否包含卡顿窗口的操作包括：
56.判断该观察窗口中相邻两个正常音频帧是否满足预设丢帧条件；
57.如果是，则按照与所述预设丢帧条件对应的计算方式确定该观察窗口下的卡顿窗口的数量和待累积观察窗口的数量。
58.其中，单位时间内的所有观察窗口包括该单位时间内包含的实际观察窗口以及所有待累积观察窗口。
59.上述丢帧条件指的是一个观察窗口中相邻两个正常音频帧的序列号之差大于或等于预设丢帧数阈值。如果一个观察窗口中两个相邻的正常音频帧的序列号不连续且序列号之差大于或等于丢帧数阈值，则可以确定存在强制丢帧场景。该观察窗口中的音频帧在被播放时，会产生卡顿。
60.丢帧数阈值可以根据实际应用预先设定。例如，丢帧数阈值可以设为20。如果一个观察窗口中观测到的强制丢弃的帧的数量达到或超过20，则可以认为该观察窗口中的音频帧被播放时会产生卡顿。实验中，当一个观察窗口中观测到的强制丢弃的帧的数量超过20个时，音频质量会有明显下降。根据具体应用场景对于音频质量的要求，丢帧数阈值还可以设为其他值，例如8、9、10等，本发明不受具体丢弃的音频帧数量的限定。
61.举例来说，参见图3b，正常情况下，1001帧之后应该是seq为1002的帧。但由于发生了强制丢帧，下一帧可能是seq为1200的帧。两个正常解码帧1001、1200的seq之差达到199，这表示有199帧被丢弃了，因而有199个音频帧无法被解码和播放。此时，丢弃的音频帧的数量超过了丢帧数阈值，因而会造成卡顿。例如，对于音频帧长度为20ms的情况，丢失的199帧会造成约4s的卡顿。
62.识别出强制丢帧场景后，需计算对应的卡顿窗口的数量和待累积观察窗口的数量。此处的卡顿窗口数量与待累积观察窗口的数量是相同的，均为被丢弃的音频帧对应的观察窗口数。
63.步骤102中，按照所述计算方式确定所述卡顿窗口的数量和所述待累积观察窗口的数量包括：将所述卡顿窗口的数量和所述待累积观察窗口的数量均确定为n，其中，
64.n＝ceil((framelength*seqdiff)/windowduration)，
65.其中，framelength表示单个音频帧的长度，seqdiff表示两个相邻正常音频帧的序列号之差，windowduration表示一个观察窗口的时长，ceil()为上取整函数，其输出为大于或等于输入参数并且与该输入参数最接近的整数。
66.本实施例中，将丢弃的音频帧的数量换算成观察窗口的数量。这些观察窗口均为卡顿窗口，且其数量为n，因而当前评估周期内卡顿窗口的数量累加n。此时，这些被丢弃而导致出现卡顿的音频帧(如果为丢弃的话)实际上使观察窗口的数量以与卡顿窗口数量同
等程度地增加。因此，在计算卡顿率的相关参数时，这些被丢弃的音频帧同样需要累加到评估周期内，进而使评估周期内的音频帧总数量增加。换言之，评估周期内原有观察窗口的数量会增加，增加的量即为待累积观察窗口的数量n。
67.在步骤103，评估卡顿率，其中，所述卡顿率为所述单位时间内确定的卡顿窗口的累计数量与所述单位时间内的所有观察窗口的累计数量之比。卡顿率可以用以下公式表示：
[0068][0069]
其中，stuckpercent表示卡顿率，stuckcount表示单位时间内确定的卡顿窗口的数量，windowcount表示单位时间内实际的观察窗口的总数与确定的所有待累积观察窗口的数量之和。
[0070]
本发明实施例中，对音频帧的seq和编解码信息等特征信息来进行分析，从而识别导致卡顿的主要场景。然后，基于观察窗口模式，将识别出的卡顿场景可能导致的主观卡顿感受量化为卡顿窗口计数。最后，根据卡顿窗口数和观察窗口数来计算卡顿率。本发明实施例中，卡顿窗口的使用简化了卡顿量化和评估的过程，并且，通过识别导致卡顿的主要场景可以提高卡顿率评估的精确度。
[0071]
此外，在发送端发送语音的过程中，发送端可能处于某些原因设置了静音。对于音频通信来说，静音状态下的任何导致卡顿的场景实际上都不会造成主观卡顿感受。因此，本发明进一步排除发送端的静音状态可能给卡顿识别带来的干扰，从而进一步提高卡顿率评估的精确度。
[0072]
在端对端的语音通信中，如果发送端设置了静音或者处于话音间隙，为了降低语音报文占用的带宽，发送端通常不发送语音报文，而是采用不连续传输(discontinuous transmission，简称dtx)。在静音期间或话音间隙，dtx会在音频数据包中插入sid(silence insertion descriptor)帧。sid帧中包含背景噪声参数，接收端将sid帧解码后生成背景噪声，这就是舒适噪声。通过提供舒适噪声，可以防止在发送端静音或静默的状态下接收端用户误以为通话已结束，从而提高用户体验。
[0073]
在发送端静音(一般都伴随着dtx)的情况下，接收端由于没有收到语音报文，其抖动缓存中会引入大量空帧。但静音状态下的空帧不会引起卡顿感，不应被纳入卡顿率的计算中。因此，需要识别静音或dtx场景，并排除静音或dtx场景下引入的空帧对卡顿的识别及量化的干扰。
[0074]
相应地，本发明实施例提供了一种用于评估音频卡顿率的方法200，如图4所示。方法200可以由图1中示出的卡顿评估模块来执行，也可以由其他合适的硬件、软件或者软硬件的组合来执行。方法200包括步骤201～205。
[0075]
步骤201和202与方法100中的步骤101和102相同，此处不再赘述。
[0076]
在步骤203，在当前音频帧为正常音频帧且前一音频帧为空帧时，检测静音或dtx场景。
[0077]
如上所述，在静音状态下，接收端的抖动缓存会引入空帧，而在计算卡顿率时不应考虑这些因静音而引入的空帧。因此，当从空帧切换到正常音频帧时，也即解码模块从recover操作转换为decode操作时，判断是否存在静音或dtx场景。如果存在，则需要排除因
静音状态而引入的空帧对卡顿率评估的干扰。
[0078]
在步骤204，如果检测到所述静音或dtx场景，重置所述单位时间内确定的卡顿窗口的累计数量与所述单位时间内的所有观察窗口的累计数量。
[0079]
如果当前音频帧是在发送端处于静音或静默状态下发送的，则在静音或静默期间识别的卡顿场景均不应被考虑在卡顿率的评估中。因此，本发明实施例中，当检测到静音或dtx场景时，将临时累计的卡顿窗口数和观察窗口数清零，以排除静音或dtx场景对最终卡顿率计算的干扰。重置操作之后，方法200继续对后续的音频帧进行识别，也即返回到步骤202继续判断接下来的音频帧是否会导致卡顿。上述方法步骤循环执行，直至当前评估周期内的音频帧均已分析完毕，之后方法200执行步骤205。
[0080]
在步骤205，评估卡顿率，其中，所述卡顿率为所述单位时间内确定的卡顿窗口的累计数量与所述单位时间内的所有观察窗口的累计数量之比。
[0081]
步骤205与方法100中步骤103类似，此处不再赘述。但方法200中卡顿率的计算已经排除了静音状态引入的空帧对卡顿率造成干扰，因而更精确。
[0082]
在上述实施中，本发明在识别出导致卡顿的主要场景后，进一步检测静音或dtx状态。如果检测到静音或dtx状态，则将静音状态下判断出的卡顿窗口排除，从而进一步提高卡顿率评估的精确度。
[0083]
本发明实施例中，对静音或dtx场景的检测可以根据静音状态下音频数据包的发送特性来执行。
[0084]
在一个示例中，在从正常语音状态切换到静音状态之后，发送端发送的音频数据包中，最初的1～2个音频数据包的有效载荷部分包含不编码的静音帧，静音帧中包含静音通知标识。接收端可以判断音频帧中是否包含静音通知标识，如果音频帧中包含静音通知标识，则表明当前发送端刚刚进入静音状态。由于进入了静音状态，接收端在收到包含静音通知标识的音频帧时，其抖动缓存中已引入了一定数量的空帧，这些空帧不应被纳入卡顿率的评估中。
[0085]
相应地，步骤203中的所述检测静音或dtx场景可以包括：
[0086]
步骤2031，判断所述当前音频帧中是否包含静音通知标识；
[0087]
步骤2034，如果是，确定检测到静音或dtx场景。
[0088]
在另一示例中，正常语音情况下，发送端发送的音频数据帧的时间戳是按照一固定时间间隔递增的。以一个数据包包含两个音频帧的情况为例，如图5所示，正常语音情况下，音频数据包都是连续的，且每两个音频帧之间的发送时间戳的间隔都是20ms(即一个音频帧的长度)。但是，在静音或dtx的情况下，发送端不会持续发送音频数据包，而是每隔另一固定时间间隔发送包含sid帧的数据包或者是无实际音频数据的空包。因此，发送的数据包的时间戳也会按照该另一固定时间间隔递增，而不会按正常语音情况下的时间间隔递增。再次参见图5，在静音或dtx场景下，发送端连续发送的两个数据包(包含音频帧1和2的第一音频数据包以及包含音频帧3和4的第二音频包)之间的时间间隔为2000ms。如果两个相邻正常音频数据包的时间戳之差(即前一音频数据包的最后一针与后一音频数据包的第一帧的时间戳之差)约等于静麦场景下发送音频数据包的时间间隔(例如2000ms)，则表明当前发送端处于静音状态期间。在接收端，第一音频数据包与第二音频数据包之间同样间隔了2000ms。
[0089]
相应地，步骤203中的所述检测静音或dtx场景还可以包括：
[0090]
步骤2032，判断前一正常音频帧的时间戳与当前音频帧的时间戳之差(timestampdiff)是否约等于第一静音间隔阈值；以
[0091]
步骤2034，如果是，确定检测到静音或dtx场景。
[0092]
该第一静音间隔阈值需根据实际应用中静音场景下发送数据包的时间间隔而定。例如，对于图5所示的示例，静音或dtx状态下，两个音频包的间隔为2000ms，此时，第一静音间隔阈值可以设置为2000ms。第二音频数据包中seq为3的音频帧与第一音频数据包的seq为2的音频帧的时间戳之差为2000
–
20＝1980ms，约等于第一静音间隔阈值。因此，可以确定当前发送端处于静音状态。
[0093]
在又一示例中，在静音期间，虽然时间在不断累加，但发送端的编码器并没有如正常语音状态下那样进行正常音频数据包的编码。或者说，在静音期间，时间在不断累积，但从发送端发出的正常音频数据包远远少于正常语音状态下应发送的音频数据包，这使得音频数据包中音频帧的seq的递增比正常语音状态下有所减慢。因此，从静音状态切换到正常语音状态时，发送端发送的第一个正常音频数据包(其第一个音频帧)的时间戳会远远大于前一个正常音频数据包(其最后一个音频帧)的时间戳，而二者的序列号之差却不会很大。如果音频帧或者说音频数据包符合上述情况，则表明当前发送端刚刚从静音状态切换到正常语音状态。
[0094]
相应地，步骤203中的所述检测静音或dtx场景还可以包括：
[0095]
步骤2033，计算前一正常音频帧的序列号与当前音频帧的序列号之间的第一差值(seqdiff)；计算所述前一正常音频帧的时间戳与当前音频帧的时间戳之间的第二差值(timestampdiff)；并且判断所述第一差值(seqdiff)与所述第二差值(timestampdiff)是否满足：
[0096]
timestampdiff
–
seqdiff*framelength＞第二静音间隔阈值，
[0097]
其中，framelength为单个音频帧的长度；
[0098]
步骤2034，如果是，确定检测到静音或dtx场景。
[0099]
上述第二静音间隔阈值的具体值可以通过仿真实验或经验值来获得，也可以根据实际应用来设置。例如，第二静音间隔阈值可以设置为1500ms。参见图5中的示例，单个音频帧的长度为20ms，第3音频帧与第2音频帧的时间戳之差(timestampdiff)为2000
–
20＝1980ms，而二者的序列号之差(seqdiff)仅为1。此时，1980ms
–
1*20ms＝1960ms超过了1500ms，从而可以确定当前发送端刚刚从静音状态切换到正常语音状态。当然，第二静音间隔阈值还可以设置为其他值，例如2500ms。
[0100]
在上述三个示例均可以判断是否在静音或dtx状态，不同之处在于，静音状态所处的阶段。第一个示例中，发送端刚刚从正常语音状态切换到静音状态；第二示例中，发送端正处于静音期间；第三个示例中，发送端刚刚从静音状态切换到正常语音状态。实际应用中，如图6所示的静音检测过程，无论判断出发送端处于这三个阶段中的哪个阶段，均可以确定发送端处于静音或dxt场景中。
[0101]
上述实施例中，方法200在识别持续插入空帧和强制丢帧等卡顿场景的基础上，进一步判断发送端是否处于静音或dtx状态，进而排除静音或dtx场景下引入的空帧对卡顿的量化和评估的干扰，从而进一步提高了卡顿率评估的精确度。
[0102]
现在参考图7来阐述本发明的卡顿率判断逻辑的一个具体实例，以便更好地理解本发明构思。该示例仅是本发明的实施方式中的一个实施方式，本发明并不限于此。
[0103]
参见图7，首先，检测音频播放状态。如果是持续播放空帧状态，则进行临时卡顿统计，持续更新空帧个数。
[0104]
如果是持续播放正常解码音频帧状态，则进入是否是强制丢帧处理场景的判断，具体判断方法如前所述。如果判断出没有出现强制丢帧，则当前是正常播放状态，不判断为卡顿，而仅更新最终卡顿率分母windowcount，即观察窗口数量。如果判断出强制丢帧场景，且一个观察窗口中相邻两个正常音频帧序列号之差大于或等于预设丢帧数阈值，则判定为卡顿。由于静音或dtx状态下不会出现强制丢帧的场景，所以此时可以不考虑对静音或dtx状态的判断和排除。此时，丢失的音频帧的数量可以前文所述的计算方式纳入到最终卡顿率的分子和分母的累计中。
[0105]
从播放空帧状态切换到播放正常解码帧状态时，即解码模块从recover操作转变为decode操作时，首先判断发送端是否在端静音或dtx状态。如果是，则说明音频传输及播放处于静音状态，无需将临时卡顿率的分子和分母纳入最终卡顿率计算中，并重置临时空帧个数和卡顿率分母。如果发送端未处于静音或dtx状态，则判断临时空帧个数是否超过空帧数阈值(例如5)，如果是，则判断为卡顿，并纳入到最终卡顿率的分子中，并更新最终的分子分母，重置临时空帧个数。如果不是，则不判定为卡顿，而仅更新最终卡顿率的分母，并重置临时空帧个数。
[0106]
按照上述卡顿率判断逻辑，可以在接收播放音频的过程中，判断播放空帧状态和播放正常音频帧状态下是否发生卡顿；并且，还可以在从播放空帧切换到播放正常音频帧这一状态切换时，识别静音场景并排除其对卡顿率统计的干扰，从而能够及时且准确地判断卡顿是否存在，并实时计算卡顿率。
[0107]
根据前述方法计算所得的卡顿率，可以反馈至发送端，作为发送端调整发送参数或选择发送路径的基础，以改善卡顿状况，提高音频流畅度。例如，当发送端处于移动网络与局域网络交叉覆盖的环境下时，根据接收端所反馈的卡顿率、两种通信网络的数据传输质量等参数动态选择移动网络或局域网络，以降低卡顿率；根据通信网络的数据传输质量，发送端可以调整音频编码方式，以降低卡顿率。
[0108]
虽然本技术将上述示例性方法描述为一系列的步骤或操作，但是应当理解，本发明不受本文所示步骤或操作的顺序的限制。以上步骤中的一个或多个可以以不同的顺序执行，其中某些步骤也可以与其他步骤同时执行。此外，在实现本发明的方法时，不一定需要执行本技术所示的所有步骤。
[0109]
根据本发明的另一个方面，还提供了一种用于评估音频卡顿率的装置。该装置包括：
[0110]
设定模块，用于针对待评估音频设定观察窗口，所述观察窗口包括一个或多个音频帧；
[0111]
判断模块，用于针对单位时间内的每一个观察窗口，按预设条件判断该观察窗口是否包含卡顿窗口，并对所包含卡顿窗口计数；以及
[0112]
评估模块，用于评估卡顿率，其中，所述卡顿率为所述单位时间内确定的卡顿窗口的累计数量与所述单位时间内的所有观察窗口的累计数量之比。
[0113]
在一些实施例中，所述判断模块包括：
[0114]
空帧判断子模块，用于判断该观察窗口中的音频帧是否满足预设空帧条件，其中，所述预设空帧条件为所述观察窗口中空帧的数量大于或等于预设的空帧数阈值；和
[0115]
第一累计子模块，用于在所述空帧判断子模块确定该观察窗口中的音频帧满足所述预设空帧条件时，确定该观察窗口为卡顿窗口，并对卡顿窗口的数量进行累计。
[0116]
在一些实施例中，所述判断模块包括：
[0117]
丢帧判断子模块，用于判断该观察窗口中相邻两个正常音频帧是否满足预设丢帧条件；和
[0118]
第二累计子模块，用于在所述丢帧判断子模块确定该观察窗口中相邻两个正常音频帧满足预设丢帧条件时，按照与所述预设丢帧条件对应的计算方式确定该观察窗口下的卡顿窗口的数量和待累积观察窗口的数量；
[0119]
其中，所述单位时间内的所有观察窗口包括所述单位时间内包含的实际观察窗口以及所有待累积观察窗口。
[0120]
在一些实施例中，所述丢帧条件为所述观察窗口中相邻两个正常音频帧的序列号之差大于或等于预设丢帧数阈值，并且
[0121]
所述第二累计子模块还用于：
[0122]
将所述卡顿窗口的数量和所述待累积观察窗口的数量均确定为n，
[0123]
n＝ceil((framelength*seqdiff)/windowduration)
[0124]
其中，framelength表示单个音频帧的长度，seqdiff表示所述相邻两个正常音频帧的序列号之差，windowduration表示一个观察窗口的时长，ceil()为上取整函数。
[0125]
在一些实施例中，所述装置还包括：
[0126]
静音检测模块，用于在当前音频帧为正常音频帧且前一音频帧为空帧时，检测静音或dtx场景；和
[0127]
重置模块，用于在所述静音检测模块检测到静音或dtx场景时，重置所述单位时间内确定的卡顿窗口的累计数量与所述单位时间内的所有观察窗口的累计数量。
[0128]
在一些实施例中，所述静音检测模块包括第一静音检测子模块，用于：
[0129]
判断所述当前音频帧中是否包含静音通知标识；
[0130]
如果是，确定检测到静音或dtx场景。
[0131]
在一些实施例中，所述静音检测模块包括第二静音检测子模块，用于：
[0132]
判断前一正常音频帧的时间戳与所述当前音频帧的时间戳之差是否等于第一静音间隔阈值；
[0133]
如果是，确定检测到静音或dtx场景。
[0134]
在一些实施例中，所述静音检测模块包括第三静音检测子模块，用于：
[0135]
计算前一正常音频帧的序列号与所述当前音频帧的序列号之间的第一差值；
[0136]
计算所述前一正常音频帧的时间戳与所述当前音频帧的时间戳之间的第二差值；
[0137]
判断所述第一差值与所述第二差值是否满足：
[0138]
timestampdiff
–
seqdiff*framelength＞第二静音间隔阈值，
[0139]
其中，timestampdiff为所述第二差值，seqdiff为所述第一差值，framelength为单个音频帧的长度；
[0140]
如果是，确定检测到静音或dtx场景。
[0141]
根据本发明的又一方面，还提供了一种计算设备300，如图8所示。计算设备300可以包括一个或多个处理器301和存储器302。存储器302中存储有计算机可执行指令，该指令在由处理器301执行时，使计算设备300执行上述用于评估音频卡顿率的方法的任一实施例。计算设备300还可以包括通信接口305。
[0142]
处理器300可以是任何合适的处理设备，例如微处理器(microprocessor)、微控制器(microcontroller)、集成电路或其他合适的处理设备。存储器302可以包括任何合适的计算系统或介质，包括但不限于非暂时性计算机可读介质、随机存取存储器(ram)、只读存储器(rom)、硬盘、闪存或其他存储器设备。存储器302可以存储计算机可执行指令303，该指令303可以由处理器301执行，以使计算设备300执行上述用于评估音频卡顿率的方法的任一实施例。存储器302还可以存储数据304。
[0143]
本发明实施例中，处理器302可以执行包括在指令303中的各种模块，以便实现上述用于评估音频卡顿率的方法的任一实施例。例如，计算设备300可以实现上述用于评估音频卡顿率的装置包括的各个模块，以便执行图2和图4示出的方法100和200中任一个。
[0144]
根据本发明的再一方面，还提供了一种非暂时性计算机可读存储介质。所述存储介质上存储有计算机可执行指令，当所述指令被计算机执行时，使得所述计算机执行上述用于评估音频卡顿率的方法的任一实施例。
[0145]
应当理解，术语“模块”是指用于提供期望功能的计算机逻辑。因此，模块可以由硬件、专用电路、固件和/或软件及其组合来实现。在一个实施例中，模块是存储在存储设备上、加载到存储器中并且由处理器执行的程序代码文件，或者可以由存储在诸如ram、硬盘或光学或磁性介质的有形计算机可读存储介质中的计算机程序产品(例如，计算机可执行指令)。
[0146]
以上介绍了本发明的一些实施例和特征，本领域技术人员能够理解，在不脱离本发明的精神和范围的情况下，可以对这些特征和实施例进行各种改变或等效替换。另外，在本发明的教导下，可以对这些特征和实施例进行修改以适应具体的情况而不会脱离本发明的精神和范围。因此，本发明不受此处所公开的具体实施例的限制。