适用于云游戏场景的超低延迟音频处理方法及装置与流程

1.本技术提供一种延迟音频传输技术，尤其涉及一种适用于云游戏场景的超低延迟音频处理方法。本技术还涉及一种适用于云游戏场景的超低延迟音频处理装置。


背景技术：

2.在现有的音频传输技术中，声音的流式传输是最常见的一种方式。然而，随着计算机的进步，不同场景对音频传输的要求越来越高，如云游戏场景。
3.由于云游戏场景进一步增加了对声音延时和声音质量的要求，所以极易产生爆音，电流音等场景。因此，如何在极低延迟的场景下平衡声音质量、卡顿和延迟成为当下亟需解决的问题。


技术实现要素：

4.为解决在极低延迟的场景不产生电流音和爆音等问题，本技术提供一种适用于云游戏场景的超低延迟音频处理方法。本技术还涉及一种适用于云游戏场景的超低延迟音频处理装置。
5.本技术提供一种适用于云游戏场景的超低延迟音频处理方法，包括：
6.获取客户端发送的与传输音频对应的传输协议参数；
7.根据所述传输协议参数，对所述传输协议参数进行再次封装生成新的传输协议；
8.基于所述新的传输协议向客户端传输所述音频。
9.可选的，通过以下方式对所述传输协议参数进行再次封装生成新的传输协议，包括：通过调整所述传输音频的编码码率，控制所述传输协议承载的数据包个数和内容进行再次封装生成新的传输协议。
10.可选的，所述方法还包括：获得所述客户端发送的重发数据包的请求；根据本时段的状态判断是否通过传输协议单独重发所述数据包，或者通过发送下一个数据包时的传输协议发送所述数据包。
11.可选的，所述传输协议参数包括以下至少一种：延迟、丢包率、网络丢包次数、实际丢包次数、当前声音质量、卡顿次数、卡顿时长。
12.本技术还提供一种适用于云游戏场景的超低延迟音频处理方法，包括：
13.接收服务端发送的新的传输协议；
14.对所述新的传输协议中包含的音频数据进行调整处理以获得满足云游戏场景的延迟要求，包括：拉长不足的音频数据，或者压缩音频数据冗余时的声音数据，或者淡出没有音频数据的播放。
15.本技术还提供一种适用于云游戏场景的超低延迟音频处理装置，包括：
16.获取传输协议参数单元，用于获取客户端发送的与传输音频对应的传输协议参数；
17.再次封装单元，用于根据所述传输协议参数，对所述传输协议参数进行再次封装
生成新的传输协议；
18.传输音频数据单元，用于基于所述新的传输协议向客户端传输所述音频数据。
19.可选的，通过以下方式对所述传输协议参数进行再次封装生成新的传输协议，包括：通过调整所述传输音频的编码码率，控制所述传输协议承载的数据包个数和内容进行再次封装生成新的传输协议。
20.可选的，所述装置还包括：获得所述客户端发送的重发数据包的请求；根据本时段的状态判断是否通过传输协议单独重发所述数据包，或者通过发送下一个数据包时的传输协议发送所述数据包。
21.可选的，所述传输协议参数包括以下至少一种信息：延迟、丢包率、网络丢包次数、实际丢包次数、当前声音质量、卡顿次数、卡顿时长。
22.本技术还提供一种适用于云游戏场景的超低延迟音频处理装置，包括：
23.新的传输协议接收单元，用于接收服务端发送的新的传输协议；
24.音频数据调整处理单元，用于对所述新的传输协议中包含的音频数据进行调整处理以获得满足云游戏场景的延迟要求，包括：拉长不足的音频数据，或者压缩音频数据冗余时的声音数据，或者淡出没有音频数据的播放。
25.本技术相对与现有技术的优点：
26.本技术提供一种适用于云游戏场景的超低延迟音频处理方法，包括：获取客户端发送的与传输音频对应的传输协议参数；根据所述传输协议参数，对所述传输协议参数进行再次封装生成新的传输协议；基于所述新的传输协议向客户端传输所述音频。本技术通过对传输协议进行再次封装使得在极低延迟的场景下不产生电流音和爆音，从而在延迟，卡顿，声音质量中找到一种适合于云游戏的平衡。
附图说明
27.图1是本技术中适用于云游戏场景的超低延迟音频传输的第一流程图。
28.图2是本技术中适用于云游戏场景的超低延迟音频传输的第二流程图。
29.图3是本技术中适用于云游戏场景的超低延迟音频传输的第一装置示意图。
30.图4是本技术中适用于云游戏场景的超低延迟音频传输的第二装置示意图。
具体实施方式
31.在下面的描述中阐述了很多具体细节以便于充分理解本技术。但是本技术能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本技术内涵的情况下做类似推广，因此本技术不受下面公开的具体实施的限制。
32.本技术提供一种适用于云游戏场景的超低延迟音频处理方法，包括：获取客户端发送的与传输音频对应的传输协议参数；根据所述传输协议参数，对所述传输协议参数进行再次封装生成新的传输协议；基于所述新的传输协议向客户端传输所述音频。本技术通过对传输协议进行再次封装使得在极低延迟的场景下不产生电流音和爆音，从而在延迟，卡顿，声音质量中找到一种适合于云游戏的平衡。
33.图1是本技术中适用于云游戏场景的超低延迟音频传输的第一流程图。
34.请参照图1所示，s101获取客户端发送的与传输音频对应的传输协议参数。
35.为便于更好地理解本方案，先简单说明一下与传输协议有关的信息：传输协议中各层都为上一层提供业务功能。为了提供这种业务功能，下一层将上一层中的数据并入到本层的数据域中，然后通过加入报头或报尾来实现该层业务功能，该过程叫做数据封装。用户的数据要经过一次次包装，最后转化成可以在网络上传输的信号，发送到网络上。当到达目标计算机后，再执行相反的拆包过程。
36.本技术中的所述传输协议主要是指rtp(real-time transport protocol或实时传输协议)和udp(user datagram protocol或用户数据报协议)。其中，每个rtp需要保证可以封装多个音频包，且多个音频包可以拥有不同的包类型。传输协议参数主要包括延迟、丢包率、网络丢包次数、实际丢包次数、当前声音质量、卡顿次数和卡顿时长等。
37.该步骤客户端统计传输协议参数，并将该协议参数发送给服务端由服务端进行处理。
38.请参照图1所示，s102根据所述传输协议参数，对所述传输协议参数进行再次封装生成新的传输协议。
39.本技术中由于每个rtp包中存在复数个数据包分段，每个分段数据类型也可能不同，所以，处理器会根据延迟，丢包率，网络丢包次数，实际丢包次数，当前声音质量，卡顿次数，卡顿时长等参数调整音频编码码率，控制单rtp包承载的数据包个数和内容，进而控制声音的延时和质量为了便于理解。
40.优选的，本技术服务器会根据特定时间段内的如下公式对延迟，丢包率，网络丢包次数，实际丢包次数，当前声音质量，卡顿次数，卡顿时长等参数进行计算确定单rtp包承载的数据包个数：
[0041][0042]
其中，b表示服务器通过计算确定单rtp包承载的数据包个数，i表示上述参数的排列序号，如i＝1表示延迟、i＝7表示卡顿时长，x1表示延迟对服务器计算单rtp包承载的数据包个数的影响系数，a1表示在特定时段内的延迟次数。
[0043]
当然，本技术还可以其他方式确定新的协议，如以rtp/udp为基础通过对协议头封装格式进行再次封装生成新的传输协议，具体为：
[0044]
表一为rtp协议data/nack头格式
[0045]
pakcettype包类型4bitlength数据长度12bitpacketnum包序号16bittimestamp时间戳32bit
[0046]
其中，包类型现在存在三种类型：包基础数据，前向纠错，重发。数据长度：数据包分段的数据长度，不包括头。包序号：在基础数据和重发中，这个字段即为后续数据的包序号。时间戳：包捕获的相对时间戳，用于播放端控制播放时间。
[0047]
表二为rtp协议fec头格式
[0048]
pakcettype包类型4bitxfor_marks前向纠错保护标识12bitpacketnumbase前向纠错保护包序号起始值16bit
xfor_timestamp前向纠错保护时间戳32bitlength数据长度16bitxfor_length前向纠错保护长度16bit
[0049]
其中，包类型现在存在三种包类型：基础数据，前向纠错，重发。前向纠错保护标识：数据内容为从packetnumbase-packetnumbase 11这12个包中，任意一个包若取值为1，则在前向纠错的保护中。前向纠错保护包序号起始值：在前向纠错中这个数据是保护包的包序号起始值，实际包中可能并没有保护对应的数据。前向纠错保护时间戳：所有被保护的包的时间戳按位进行亦或运算所得的值。数据长度：这个数据包分段的数据长度，不包括头。前向纠错保护长度：所有被保护的包的长度按位进行亦或运算所得的值。
[0050]
请参照图1所示，s103基于所述新的传输协议向客户端传输所述音频。
[0051]
服务端将音频数据以新的传输协议发送至客户端，客户端便可根据新的协议获得能够满足云游戏场景要求的音频数据。
[0052]
需要注意的是，当数据包存在丢失的情况是，客户端会向服务端请求重发数据包。此时，服务端会根据本段状态判断是通过rtp单独重新发送数据包，还是由下一个音频包发送时一同打包在一个rtp中发送。
[0053]
本技术还提供一种适用于云游戏场景的超低延迟音频处理方法。
[0054]
图2是本技术中适用于云游戏场景的超低延迟音频传输的第二流程图。
[0055]
请参照图2所示，s201接收服务端发送的新的传输协议。
[0056]
该方法的执行主体为客户端，客户端接收服务端发送的新的传输协议，根据所述新的传输协议可以获得相关的音频数据。
[0057]
请参照图2所示，s202对所述新的传输协议中包含的音频数据进行调整处理以获得满足云游戏场景的延迟要求，包括：拉长不足的音频数据，或者压缩音频数据冗余时的声音数据，或者淡出没有音频数据的播放。
[0058]
由于云游戏场景对延迟的要求，客户端的缓冲区大小受到极大限制，缓存大小不可能超过100ms。所以，在这种情况下，客户端采用以下方法对声音数据进行处理，以保证声音不会过多卡顿，完全没有爆音和电流音：当数据不足时可以拉长数据；或者，当数据冗余时可以压缩声音数据；或者，当无数据能播放时可以淡出播放，并等待缓冲区填充至60ms等等。
[0059]
本技术还提供一种适用于云游戏场景的超低延迟音频处理装置，包括：获取传输协议参数单元301，再次封装单元302，传输音频数据单元303。
[0060]
图3是本技术中适用于云游戏场景的超低延迟音频传输的第一装置示意图。
[0061]
请参照图3所示，获取传输协议参数单元301，用于获取客户端发送的与传输音频对应的传输协议参数。
[0062]
本技术中的所述传输协议主要是指rtp(real-time transport protocol或实时传输协议)和udp(user datagram protocol或用户数据报协议)。其中，每个rtp需要保证可以封装多个音频包，且多个音频包可以拥有不同的包类型。传输协议参数主要包括延迟、丢包率、网络丢包次数、实际丢包次数、当前声音质量、卡顿次数和卡顿时长等。
[0063]
该步骤客户端统计传输协议参数，并将该协议参数发送给服务端由服务端进行处理。
[0064]
请参照图3所示，再次封装单元302，用于根据所述传输协议参数，对所述传输协议参数进行再次封装生成新的传输协议。
[0065]
本技术中的封装是指传输协议中各层都为上一层提供业务功能，为了提供这种业务功能，下一层将上一层中的数据并入到本层的数据域中，然后通过加入报头或报尾来实现该层业务功能，该过程叫做数据封装。
[0066]
为了便于理解，本技术优选以rtp/udp为基础通过对协议头封装格式进行再次封装生成新的传输协议。
[0067]
表一为rtp协议data/nack头格式
[0068]
pakcettype包类型4bitlength数据长度12bitpacketnum包序号16bittimestamp时间戳32bit
[0069]
其中，包类型现在存在三种类型：包基础数据，前向纠错，重发。数据长度：数据包分段的数据长度，不包括头。包序号：在基础数据和重发中，这个字段即为后续数据的包序号。时间戳：包捕获的相对时间戳，用于播放端控制播放时间。
[0070]
表二为rtp协议fec头格式
[0071][0072]
其中，包类型现在存在三种包类型：基础数据，前向纠错，重发。前向纠错保护标识：数据内容为从packetnumbase-packetnumbase 11这12个包中，任意一个包若取值为1，则在前向纠错的保护中。前向纠错保护包序号起始值：在前向纠错中这个数据是保护包的包序号起始值，实际包中可能并没有保护对应的数据。前向纠错保护时间戳：所有被保护的包的时间戳按位进行亦或运算所得的值。数据长度：这个数据包分段的数据长度，不包括头。前向纠错保护长度：所有被保护的包的长度按位进行亦或运算所得的值。
[0073]
由于每个rtp包中存在复数个数据包分段，每个分段数据类型也可能不同，所以，处理器会根据延迟，丢包率，网络丢包次数，实际丢包次数，当前声音质量，卡顿次数，卡顿时长等参数调整音频编码码率，控制单rtp包承载的数据包个数和内容，进而控制声音的延时和质量。
[0074]
请参照图3所示，传输音频数据单元303，用于基于所述新的传输协议向客户端传输所述音频。
[0075]
服务端将音频数据以新的传输协议发送至客户端，客户端便可根据新的协议获得
能够满足云游戏场景要求的音频数据。
[0076]
需要注意的是，当数据包存在丢失的情况是，客户端会向服务端请求重发数据包。此时，服务端会根据本段状态判断是通过rtp单独重新发送数据包，还是由下一个音频包发送时一同打包在一个rtp中发送。
[0077]
本技术还提供一种适用于云游戏场景的超低延迟音频处理装置，包括：新的传输协议接收单元401，音频数据调整处理单元402。
[0078]
图4是本技术中适用于云游戏场景的超低延迟音频传输的第二装置示意图。
[0079]
请参照图4所示，新的传输协议接收单元401，用于接收服务端发送的新的传输协议。
[0080]
该方法的执行主体为客户端，客户端接收服务端发送的新的传输协议，根据所述新的传输协议可以获得相关的音频数据。
[0081]
请参照图4所示，音频数据调整处理单元402，用于对所述新的传输协议中包含的音频数据进行调整处理以获得满足云游戏场景的延迟要求，包括：拉长不足的音频数据，或者压缩音频数据冗余时的声音数据，或者淡出没有音频数据的播放。
[0082]
由于云游戏场景对延迟的要求，客户端的缓冲区大小受到极大限制，缓存大小不可能超过100ms。所以，在这种情况下，客户端采用以下方法对声音数据进行处理，以保证声音不会过多卡顿，完全没有爆音和电流音：当数据不足时可以拉长数据；或者，当数据冗余时可以压缩声音数据；或者，当无数据能播放时可以淡出播放，并等待缓冲区填充至60ms等等。