音频数据传输方法、装置、计算机设备及存储介质与流程

本发明实施例涉及音频通信技术领域，尤其涉及一种音频数据传输方法、装置、计算机设备及存储介质。

背景技术：

随着通信技术的不断发展，网际互连协议(internetprotocol，ip)网络的实时传输协议(real-timetransportprotocol，rtp)方式的实时音频数据传输得到了广泛应用。但是由于ip网络的不可靠性，导致音频数据传输过程中丢包现象严重。当发生音频数据丢包时，接收端接收到的音频会出现明显的断续，语音质量下降的情况。

现阶段，主要通过丢包补偿、冗余传输或者丢包重传三个技术解决音频数据的丢包现象。其中，丢包补偿技术是在接收端通过已经获取到的音频包，将丢失的音频数据通过插值等手段恢复出来；冗余传输技术是在发送端将音频数据打包为数据包以及冗余包后再对音频数据进行发送，接收端将接收到的数据包以及冗余包分别进行还原；丢包重传技术是当接收端检测到丢失的音频数据包时向发送端发出重传请求，发送端对丢失的音频数据进行重新发送。

现有技术的方法中，对于丢包补偿技术当丢包率超过20％时，很难恢复出完整的音频数据，使语义变得难以理解；对于冗余传输技术会增加对网络带宽的占用，并且在进行数据包转发时对于不支持冗余的设备无法正常提取音频数据；对于丢包重传技术由于接收端的重传的请求和发送端重传的数据包的过程仍然有可能发生丢包，因此在高丢包率的场景下需要多次重传才能恢复数据。每次重传所需的时间和网络延时相关，因此丢包重传的实时性较差，不适合在实时通信的场景下使用。

技术实现要素：

本发明实施例提供一种音频数据传输方法、装置、计算机设备及存储介质，以实现通过ip网络对音频数据进行实时传输，在有效减少音频数据丢包率的同时，并且不会明显增加对网络带宽的占用。

第一方面，本发明实施例提供了一种音频数据传输方法，应用于音频数据发送端，该方法包括：

获取目标帧音频数据之前的至少一个历史帧音频数据；

将所述目标帧音频数据和各所述历史帧音频数据进行打包传输。

第二方面，本发明实施例提供了一种音频数据传输方法，应用于音频数据接收端，该方法包括：

接收音频数据包，并解析；

根据解析得到的至少一个历史帧音频数据，还原丢失的音频数据。

第三方面，本发明实施例还提供了一种音频数据传输装置，应用于音频数据发送端，该装置包括：

历史帧音频数据获取模块，用于获取目标帧音频数据之前的至少一个历史帧音频数据；

打包传输模块，用于将所述目标帧音频数据和各所述历史帧音频数据进行打包传输。

第四方面，本发明实施例还提供了一种音频数据传输装置，应用于音频数据接收端，该装置包括：

音频数据包接收模块，用于接收音频数据包，并解析；

音频数据还原模块，用于根据解析得到的至少一个历史帧音频数据，还原丢失的音频数据。

第五方面，本发明实施例还提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如本发明实施例中任一实施例所述的方法。

第六方面，本发明实施例还提供了一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行本发明实施例中任一实施例所述的方法。

本发明实施例的方案，通过获取目标帧音频数据之前的至少一个历史帧音频数据；将目标帧音频数据和各历史帧音频数据进行打包传输。实现了通过ip网络对音频数据的实时传输，在有效减少音频数据丢包率的同时，并且不会明显增加对网络带宽的占用。

附图说明

图1是本发明实施例一中的一种音频数据传输方法的流程图；

图2是本发明实施例二中的一种音频数据传输方法的流程图；

图3是本发明实施例二中的一种rtp数据包的结构示意图；

图4是本发明实施例二中的一种音频数据传输方法的流程图；

图5是本发明实施例三中的一种音频数据传输装置的结构示意图；

图6是本发明实施例四中的一种音频数据传输装置的结构示意图；

图7是本发明实施例五中的一种计算机设备的结构示意图。

具体实施方式

下面结合附图和实施例对本发明实施例作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明实施例，而非对本发明实施例的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明实施例相关的部分而非全部结构。

实施例一

图1为本发明实施例一提供的一种音频数据传输方法的流程图，应用于音频数据发送端，本实施例可适用于通过ip网络对音频数据进行实时传输的情况，该方法可以由音频数据传输装置来执行，该装置可以通过软件和/或硬件的方式实现，并集成在执行本方法的计算机设备中。具体的，参考图1，该方法具体包括如下步骤：

s110、获取目标帧音频数据之前的至少一个历史帧音频数据。

其中，本发明实施例中涉及到的目标帧音频数据可以为音频数据发送端采集到的任意一帧的音频数据，本发明实施例中对其不作限定。需要说明的是，若目标帧音频数据为采集音频的第一帧音频数据，则在此目标帧音频数据之前不存在与其对应的历史帧音频数据。当目标帧音频数据不存在与其对应的历史帧音频数据时，无需获取历史帧音频数据；获取目标帧音频数据之前的至少一个历史帧音频数据，其并不是对本发明实施例的限定。

具体的，本发明实施例中可以通过rtp实时通信协议实现音频数据在ip网络中的传输，需要说明的是，本发明实施例中涉及到的音频数据也可以通过其他的多媒体实时传输协议进行传输，其并不是对本发明实施例的限制。

具体的，当通过rtp实时通信协议实现音频数据在ip网络中的传输时，音频数据发送端需要根据设定的采样频率(如每20ms采样一次)对音频数据进行采集，将采集到的一帧音频数据通过rtp数据包进行打包，并将打包好的音频数据包发送到音频数据接收端，音频数据再对接收到的音频数据进行播报；不断地对音频数据进行采集、打包以及发送等操作，从而实现接收端接收到完整的音频数据，以使用户听到完整的音频。

可选的，获取目标帧音频数据之前的至少一个历史帧音频数据可以包括：接收丢包率统计结果；根据丢包率统计结果，计算与目标帧音频数据对应的历史帧音频数据的数量，得到至少一个历史帧音频数据。

具体的，音频数据发送端接收音频数据接收端统计的音频数据接收端丢包率，并根据丢包率统计结果，计算与目标帧音频数据对应的历史帧音频数据的数量，从而得到至少一个历史帧音频数据。其中，丢包率是指音频数据接收端接收到的音频数据包的数量占音频数据发送端发送的音频数据包的比率。

示例性的，若音频数据接收端统计的音频数据接收端丢包率为60％，按通常情况下，当丢包率小于10％时音频数据接收端才可以较完整的恢复出音频数据；通过(60％)^x＜10％计算与目标帧音频数据对应的历史帧音频数量，其中，x即为历史帧音频数据的数量，通过计算可知，当x＝5时，(60％)⁵＝7.78％＜10％，此时，可以将历史帧音频数据的数量设为5。

进一步的，上述例子中，当计算得出历史帧音频数据的数量为5时，可以进一步的获取与目标帧音频数据对应的5帧历史帧音频数据。示例性的，若目标帧音频数据为第n帧音频数据，n可以为任意一个大于5的正整数，则与第n帧音频数据对应的5帧历史帧音频数据分别为第n-1帧音频数据、第n-2帧音频数据、第n-3帧音频数据、第n-4帧音频数据以及第n-5帧音频数据。

可选的，若音频数据发送端接收音频数据接收端统计的音频数据接收端丢包率为0，则将目标帧音频数据进行打包传输。

具体的，若音频数据发送端接收音频数据接收端统计的音频数据接收端丢包率为0，则不需要做任何处理，直接将目标帧音频数据进行打包，并将打包好的音频数据通过ip网络发送至音频数据接收端，即可实现音频数据的实时传输。

s120、将目标帧音频数据和各历史帧音频数据进行打包传输。

具体的，在获取目标帧音频数据之前的至少一个历史帧音频数据之后，可以将目标帧音频数据和各历史帧音频数据进行打包，并将打包后的音频数据通过ip网络传输至音频数据接收端。

可选的，将目标帧音频数据和各历史帧音频数据进行打包传输，可以包括：将至少一个历史帧音频数据写入到rtp头扩展中，将目标帧音频数据写入到rtp的载荷部分；得到与目标帧对应的rtp数据包，并通过网络将与目标帧对应的rtp数据包发送至音频数据接收端。

具体的，获取到目标帧音频数据以及与目标帧音频数据对应的至少一个历史帧音频数据之后，可以分别将目标帧音频数据写入到rtp的载荷部分，将至少一个历史帧音频数据写入到rtp头扩展中，从而得到与目标帧音频数据对应的rtp数据包；并通过ip网络将与目标帧对应的rtp数据包发送至音频数据接收端。

示例性的，如上述例子中，当计算得出历史帧音频数据的数量为5之后，并进一步的获取与目标帧音频数据对应的5帧历史帧音频数据。示例性的，若目标帧音频数据为第n帧音频数据，n可以为任意一个大于5的正整数，则与第n帧音频数据对应的5帧历史帧音频数据分别为第n-1帧音频数据、第n-2帧音频数据、第n-3帧音频数据、第n-4帧音频数据以及第n-5帧音频数据。可以将第n帧音频数据写入到rtp的载荷部分，将第n-1帧音频数据、第n-2帧音频数据、第n-3帧音频数据、第n-4帧音频数据以及第n-5帧音频数据写入到rtp头扩展中，从而得到与第n帧音频数据对应的rtp数据包；并通过ip网络将与第n帧对应的rtp数据包发送至音频数据接收端。

需要说明的是，本发明实施例采用的rtp协议进行数据传输，如果传输的数据包过大，会影响数据传输的实时性。也即，传输的每帧音频数据的数据包的大小需要满足设定数据大小条件。通常，一帧音频数据均满足该设定数据大小条件。

本实施例的方案，应用于音频数据发送端，通过获取目标帧音频数据之前的至少一个历史帧音频数据；将目标帧音频数据和各历史帧音频数据进行打包传输，实现了通过ip网络对音频数据的实时传输，并且可以有效减少音频数据的丢包率。

实施例二

图2为本发明实施例二提供的一种音频数据传输方法的流程图，应用于音频数据接收端，本实施例可适用于通过ip网络对音频数据进行实时传输的情况，该方法可以由音频数据传输装置来执行，该装置可以通过软件和/或硬件的方式实现，并集成在执行本方法的计算机设备中。具体的，参考图2，该方法具体包括如下步骤：

s210、接收音频数据包，并解析。

音频数据包为封装有音频数据的数据包。

具体的，音频数据接收端接收音频数据发送端通过ip网络发送的音频数据包，并对接收到的音频数据包进行解析。需要说明的是，本实施例中涉及到的音频数据包即为上述实施例中涉及到的rtp数据包。

具体的，音频数据接收端对接收到的音频数据包进行解析，即对接收到的音频数据包进行解包处理，分别得到目标帧音频数据以及与目标帧音频数据对应的历史帧音频数据。

可选的，当音频数据接收端接收到音频数据发送端通过ip网络发送的音频数据包之后，还可以判断音频数据接收端是否支持网络适应性处理，即判断音频数据接收端是否可以识别出音频数据包的rtp头扩展中包含的至少一个历史帧音频数据。示例性的，若音频数据接收端不支持rtp头扩展，则直接丢弃rtp头扩展中包含的至少一个历史帧音频数据；若音频数据接收端支持rtp头扩展，则获取到至少一个与目标帧音频数据对应的历史帧音频数据，从而为还原丢失的音频数据做准备。

这样设置的好处在于，对于不支持rtp协议的设备，可以直接丢弃rtp扩展的数据，而不影响解码的正确性，使得采用本发明的专利可以兼容传统的音频设备，无需对传统设备进行额外修改。

s220、根据解析得到的至少一个历史帧音频数据，还原丢失的音频数据。

具体的，音频数据接收端对接收到的音频数据包进行解析之后，可以进一步的根据解析得到的至少一个历史帧音频数据，还原丢失的音频数据。即，音频数据接收端接收端可以从rtp扩展中还原若干丢失的音频数据，并将还原的音频数据和目标帧音频数据发送给下一级进行处理。

示例性的，若音频数据接收端对接收到的音频数据接收包进行解析，得到了与目标帧音频数据对应的3帧历史帧音频数据，则音频数据接收端可以根据这3帧历史帧音频数据还原丢失的音频数据。

可选的，在根据解析得到的至少一个历史帧音频数据，还原丢失的音频数据之后，还可以包括：对所述目标帧音频数据进行解码，并根据还原的音频数据对解码后的目标帧音频数据进行丢包补偿，对补偿后的音频数据进行播报。

具体的，音频数据根据至少一个历史帧音频数据对丢失的音频数据进行还原之后，还可以对目标帧音频数据进行解码，并根据通过至少一个历史帧音频数据还原的音频数据对解码后的目标帧音频数据进行丢包补偿，从而得到完整的音频数据，并对完整的音频数据进行播报。

可选的，在根据解析得到的至少一个历史帧音频数据，还原丢失的音频数据之后，还包括：周期性统计丢包率，并通过实时传输控制协议(real-timetransportcontrolprotocol，rtcp)向音频数据发送端反馈丢包率。

具体的，音频数据接收端还可以周期性地统计本端接收到的音频数据的丢包率，并通过rtcp实时传输控制协议向音频数据发送端反馈丢包率。音频数据发送端可以根据音频数据接收端实时反馈的丢包率对发送的音频数据包进行调整，从而可以实现在ip网络中的音频数据的实时传输的同时，保证音频数据的丢包率较小。

本实施例的方案，应用于音频数据接收端，通过接收音频数据包，并解析；根据解析得到的至少一个历史帧音频数据，还原丢失的音频数据。实现了通过ip网络对音频数据的实时传输，并且可以有效减少音频数据的丢包率。

应用场景

为了更好地理解本发明实施例，本应用场景对本发明实施例的发明构思进一步地阐述。图3是本应用场景中列举的一种rtp数据包的结构示意图，其主要包括：媒体访问控制(mediaaccesscontrol，mac)头部分310、ip头部分320、用户数据报协议(userdatagramprotocol，udp)头部分330、rtp头部分340以及rtp载荷(payload)部分350。需要说明的是，mac头部分310、ip头部分320、udp头部分330以及rtp头部分340所占的字节分别为14字节、20字节、8字节以及12字节。待传输的目标帧音频数据的编码存储在rtp载荷部分350。示例性的，若目标帧音频数据以g729音频编码方式进行编码，则将目标帧音频数据存储在rtp载荷部分350，即实现了目标帧音频数据的打包，将打包好的rtp数据包进行传输，即实现了目标帧音频数据的传输。

需要说明的是，若目标帧音频数据以g729音频编码方式进行编码，当采用20ms打包间隔时，即每20ms采集160个采样点，得到一帧音频数据；编码后的一帧音频数据的长度为20字节，此时rtp载荷部分350存储的目标帧音频数据占全部网络传输数据的20/(14+20+8+12+20)＝27％，可以明显的看出，其有效传输率较低。

具体的，当目标帧音频数据以g729音频编码方式进行编码时，可以在每个音频数据包的rtp头部分340增加与目标帧音频数据对应的5个历史帧音频数据，得到音频数据包。若丢包率为60％时，连续5帧数据丢失的概率为(60％)5＝7.78％，当采用能够还原10％的丢包补偿配合本发明实施例中涉及到的方法时，足以还原剩余的丢失数据，即本发明实施例的抗丢包率能够高达60％。随着历史帧音频数据数量的提升，还可以继续提高抗丢包率。

进一步的，对上述例子中得到音频数据包进行传输时，需要的额外传输空间为4+20*5＝104字节，原有的包大小为74字节，即额外传输了104/74＝140％的传输带宽就传输了500％的冗余数据，大大节省了额外带宽的占用。

图4是本发明实施例适用的一种音频数据传输方法的流程图，其主要包括以下步骤：

s410、音频数据发送端采集并编码目标帧音频数据。

s420、音频数据发送端计算需要的历史帧音频数据的数量。具体的，音频数据发送端根据音频数据接收端反馈的丢包率统计结果，计算与目标帧音频数据对应的历史帧音频数据的数量，得到至少一个历史帧音频数据。将历史帧音频数据填写到rtp头扩展中，将目标帧音频数据放置到rtp的载荷部分，形成一个与目标帧音频数据对应的音频数据包，并通过ip网络将其发送至音频数据接收端。

s430、音频数据接收端判断是否支持网络适应性传输？

s431、若是，音频数据接收端根据历史帧音频数据还原丢失的音频数据。

s432、若否，丢弃历史帧音频数据，仅保留目标帧音频数据。

s440、音频数据接收端对目标帧音频数据进行解码。具体的，音频数据接收端对目标帧音频数据进行解码，根据还原的音频数据对解码后的目标帧音频数据进行丢包补偿，并对补偿后的音频数据进行播报。

s450、音频数据接收端周期性统计丢包率。具体的，音频数据接收端周期性统计本端丢包率，并通过rtcp向音频数据发送端反馈所述丢包率。

在上述例子中，通过音频数据发送端计算历史帧音频数据的数量，并对目标帧音频数据以及各历史帧音频数据进行打包，将打包好的音频数据发送至音频数据接收端；音频数据接收端根据历史帧音频数据还原丢失的音频数据，并对解码后的目标帧音频数据进行补偿，得到补偿后的音频数据，并对其进行播报。实现了通过ip网络对音频数据的实时传输，在有效减少音频数据丢包率的同时，并且不会明显增加对网络带宽的占用。

实施例三

图5是本发明实施例三提供的一种音频数据传输装置的结构示意图，该装置应用于音频数据发送端，该装置可以执行本发明实施例中任意实施例中涉及到的音频数据传输方法，可以通过软件和/或硬件的方式实现。具体的，参考图5，该装置主要包括：历史帧音频数据获取模块510和打包传输模块520。

其中，历史帧音频数据获取模块510，用于获取目标帧音频数据之前的至少一个历史帧音频数据；

打包传输模块520，用于将目标帧音频数据和各历史帧音频数据进行打包传输。

本实施例的方案，通过历史帧音频数据获取模块获取目标帧音频数据之前的至少一个历史帧音频数据；通过打包传输模块将目标帧音频数据和各历史帧音频数据进行打包传输。实现了通过ip网络对音频数据的实时传输，并且可以有效减少音频数据的丢包率。

可选的，历史帧音频数据获取模块510，还具体用于接收丢包率统计结果；根据丢包率统计结果，计算与目标帧音频数据对应的历史帧音频数据的数量，得到至少一个历史帧音频数据。

可选的，打包传输模块520，还具体用于将至少一个历史帧音频数据写入到实时传输协议rtp头扩展中，将目标帧音频数据写入到rtp的载荷部分；得到与目标帧对应的rtp数据包，并通过网络将与目标帧对应的rtp数据包发送至音频数据接收端。

可选的，音频数据传输装置还包括：第二传输打包模块，用于如果丢包率统计结果为0，则将目标帧音频数据进行打包传输。

本发明实施例所提供的音频数据传输装置可执行本发明任意实施例所提供的音频数据传输方法，具备执行方法相应的功能模块和有益效果。

实施例四

图6是本发明实施例四提供的一种音频数据传输装置的结构示意图，该装置应用于音频数据接收端，该装置可以执行本发明实施例中任意实施例中涉及到的音频数据传输方法，可以通过软件和/或硬件的方式实现。具体的，参考图6，该装置主要包括：音频数据包接收模块610和音频数据还原模块620。

其中，音频数据包接收模块610，用于接收音频数据包，并解析；

音频数据还原模块620，用于根据解析得到的至少一个历史帧音频数据，还原丢失的音频数据。

本实施的方案，通过音频数据包接收模块接收音频数据包，并解析；通过音频数据还原模块根据解析得到的至少一个历史帧音频数据，还原丢失的音频数据。实现了通过ip网络对音频数据的实时传输，并且可以有效减少音频数据的丢包率。

可选的，音频数据传输装置还包括：解码模块，用于对目标帧音频数据进行解码，并根据还原的音频数据对解码后的目标帧音频数据进行丢包补偿，对补偿后的音频数据进行播报。

可选的，音频数据传输装置还包括：丢包率统计模块，用于周期性统计丢包率，并通过rtcp向音频数据发送端反馈丢包率。

本发明实施例所提供的音频数据传输装置可执行本发明任意实施例所提供的音频数据传输方法，具备执行方法相应的功能模块和有益效果。

实施例五

图7为本发明实施例五提供的一种计算机设备的结构示意图，如图7所示，该计算机设备包括处理器70、存储器71、输入装置72和输出装置73；计算机设备中处理器70的数量可以是一个或多个，图7中以一个处理器70为例；计算机设备中的处理器70、存储器71、输入装置72和输出装置73可以通过总线或其他方式连接，图7中以通过总线连接为例。

存储器71作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本发明实施例中的音频数据传输方法对应的程序指令/模块(例如，音频数据传输置中的历史帧音频数据获取模块510和打包传输模块520)，或者如本发明实施例中的音频数据传输方法对应的程序指令/模块(例如，音频数据传输置中的音频数据包接收模块610和音频数据还原模块620)。处理器70通过运行存储在存储器71中的软件程序、指令以及模块，从而执行计算机设备的各种功能应用以及数据处理，即实现上述的音频数据传输方法。

存储器71可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储器71可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器71可进一步包括相对于处理器70远程设置的存储器，这些远程存储器可以通过网络连接至计算机设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置72可用于接收输入的数字或字符信息，以及产生与计算机设备的用户设置以及功能控制有关的键信号输入。输出装置73可包括显示屏等显示设备。

实施例六

本发明实施例六还提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行一种音频数据传输方法，该方法包括：

获取目标帧音频数据之前的至少一个历史帧音频数据；

将目标帧音频数据和各历史帧音频数据进行打包传输。

或者，接收音频数据包，并解析；

根据解析得到的至少一个历史帧音频数据，还原丢失的音频数据。

当然，本发明实施例所提供的一种包含计算机可执行指令的存储介质，其计算机可执行指令不限于如上所述的方法操作，还可以执行本发明任意实施例所提供的音频数据传输方法中的相关操作。

通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本发明可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、闪存(flash)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

值得注意的是，上述音频数据传输装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。

注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。