CN104869004B

CN104869004B - 音频数据处理方法和装置

Info

Publication number: CN104869004B
Application number: CN201510248919.7A
Authority: CN
Inventors: 张洪彬; 郭启行; 姜俊
Original assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Current assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Priority date: 2015-05-15
Filing date: 2015-05-15
Publication date: 2017-07-25
Anticipated expiration: 2035-05-15
Also published as: CN104869004A

Abstract

本发明提出一种音频数据处理方法和装置，该音频数据处理方法包括接收作为发送方的终端发送的解码前的音频数据，以及，对所述解码前的音频数据进行解码，得到解码后的音频数据；确定作为接收方的终端的当前角色，如果当前角色是发言者，根据所述解码前的音频数据获取要转发的音频数据，或者，如果当前角色是听众，根据所述解码后的音频数据获取要转发的音频数据；将所述要转发的音频数据，发送给所述作为接收方的终端。该方法能够兼顾Full‑transcoding模式和relay模式的优点，尽量降低CPU消耗和网络流量消耗。

Description

音频数据处理方法和装置

技术领域

本发明涉及数据处理技术领域，尤其涉及一种音频数据处理方法和装置。

背景技术

在音频会议通讯时，现有技术一是服务器全编全解(Full-transcoding)模式，该模式下在服务器(server)内对应每个与会终端分配独立的音频解码器(decoder)和编码器(encoder)，独立解码后根据会议的发言情况，进行混音处理，并独立编码发送到终端。现有技术二是中继(relay)模式，在不用解码的情况下，利用码流的特殊标记字段提取音频数据(audio)的特性，来预判会议中的发言人以及发言人切换，将发言人的相应数据转发给所有的与会终端，这样大大降低了后台Server的CPU资源消耗。

但是，现有技术一中，由于编码需要耗费较多的CPU资源，独立配置编码器会引起巨大的CPU资源开销。现有技术二，不进行编解码的音频数据传输会增加终端的下行带宽消耗，引起较多的网络流量开销。

发明内容

本发明旨在至少在一定程度上解决相关技术中的技术问题之一。

为此，本发明的一个目的在于提出一种音频数据处理方法，该方法可以兼顾Full-transcoding模式和relay模式的优点，尽量降低CPU消耗和网络流量消耗。

本发明的另一个目的在于提出一种音频数据处理装置。

为达到上述目的，本发明第一方面实施例提出的音频数据处理方法，包括：接收作为发送方的终端发送的解码前的音频数据，以及，对所述解码前的音频数据进行解码，得到解码后的音频数据；确定作为接收方的终端的当前角色，如果当前角色是发言者，根据所述解码前的音频数据获取要转发的音频数据，或者，如果当前角色是听众，根据所述解码后的音频数据获取要转发的音频数据；将所述要转发的音频数据，发送给所述作为接收方的终端。

本发明第一方面实施例提出的音频数据处理方法，通过获取解码前的音频数据和解码后的音频数据，并根据当前角色的不同，采用不同的方式获取要转发的音频数据，可以兼顾Full-transcoding模式和relay模式的优点，尽量降低CPU消耗和网络流量消耗。

为达到上述目的，本发明第二方面实施例提出的音频数据处理装置，包括：接收及解码模块，用于接收作为发送方的终端发送的解码前的音频数据，以及，对所述解码前的音频数据进行解码，得到解码后的音频数据；获取模块，用于确定作为接收方的终端的当前角色，如果当前角色是发言者，根据所述解码前的音频数据获取要转发的音频数据，或者，如果当前角色是听众，根据所述解码后的音频数据获取要转发的音频数据；发送模块，用于将所述要转发的音频数据，发送给所述作为接收方的终端。

本发明第二方面实施例提出的音频数据处理装置，通过获取解码前的音频数据和解码后的音频数据，并根据当前角色的不同，采用不同的方式获取要转发的音频数据，可以兼顾Full-transcoding模式和relay模式的优点，尽量降低CPU消耗和网络流量消耗。

本发明附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1是本发明一实施例提出的音频数据处理方法的流程示意图；

图2是本发明实施例对应的音频处理***的示意图；

图3是本发明另一实施例提出的音频数据处理方法的流程示意图；

图4是本发明实施例中确定要转发的音频数据的一种实现流程示意图；

图5是本发明另一实施例提出的音频数据处理方法的流程示意图；

图6是本发明另一实施例提出的音频数据处理装置的结构示意图；

图7是本发明另一实施例提出的音频数据处理装置的结构示意图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的模块或具有相同或类似功能的模块。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能理解为对本发明的限制。相反，本发明的实施例包括落入所附加权利要求书的精神和内涵范围内的所有变化、修改和等同物。

图1是本发明一实施例提出的音频数据处理方法的流程示意图，本实施例的执行主体是服务器(server)，该方法包括：

S11：接收作为发送方的终端发送的解码前的音频数据，以及，对所述解码前的音频数据进行解码，得到解码后的音频数据。

参见图2，假设终端分别用A，B，C，D，E表示，终端可以发送音频数据，也可以接收音频数据，其中，作为发送方时用终端21表示。

在服务器22内，对应每个发送方，分别设置接收模块(Recv)和解码模块(Dec)，接收模块用于接收发送方发送的音频数据，该音频数据是解码前的音频数据，解码模块用于对接收的音频数据进行解码，得到解码后的音频数据。如图2所示，经过接收模块和解码模块，对应每个发送方可以得到两种数据，分别是解码前的音频数据和解码后的音频数据，在图2中，两种数据分别用不同的填充方式表示。

S12：确定作为接收方的终端的当前角色，如果当前角色是发言者，根据所述解码前的音频数据获取要转发的音频数据，或者，如果当前角色是听众，根据所述解码后的音频数据获取要转发的音频数据。

参见图2，在服务器内，该步骤可以具体由转发决策模块(forwarding decisionmodule)执行。

当前角色可以包括：发言者，或者，听众。

可以理解的是，在不同的时刻，发言者或者听众是可以切换的。

类似relay模式，转发决策模块可以根据音频特性，在不解码的前提下确定出发言者，以及将不是发言者的其余终端确定为听众。音频特性例如为音频数据的能量值。

例如，转发决策模块可以接收到来自A，B，C，D，E的解码前的音频数据，之后可以检测每个解码前的音频数据的能量值，当一个终端的解码前的音频数据的能量值大于预设值，则表明该终端是发言者，否则是听众。

根据当前角色的不同，可以采用不同的处理方式得到要转发的音频数据。例如，对于发言者，可以将其他发言者的解码前的音频数据打包，而对于听众，可以将发言者的解码后的音频数据进行混音，并对混音后的数据进行编码。

可选的，参见图3，所述根据所述当前角色，获取要转发的音频数据，包括：

S31：如果所述当前角色是发言者，获取除自身之外的其他发言者的解码前的音频数据，并将所述解码前的音频数据打包后确定为要转发的音频数据；

例如，参见图2，如果发言者包括：A，B，C，则对应A，获取B和C的解码前的音频数据，将B和C的解码前的音频数据打包后确定为要转发给A的音频数据。对应B，获取A和C的解码前的音频数据，将A和C的解码前的音频数据打包后确定为要转发给B的音频数据。对应C，获取A和B的解码前的音频数据，将A和B的解码前的音频数据打包后确定为要转发给C的音频数据。

可以理解的是，如果发言者仅有一个，则不需要转发音频数据给该发言者对应的接收方。

S32：如果所述当前角色是听众，获取发言者的解码后的音频数据，并对所述解码后的音频数据进行混音处理，以及对混音处理后的音频数据进行编码处理，得到编码后的音频数据，并将所述编码后的音频数据确定为要转发的音频数据。

例如，参见图2，如果发言者包括：A，B，C，听众是D和E，则对应D和E，获取A，B和C的解码后的音频数据，对该解码后的音频数据进行混音处理，再对混音后的音频数据进行编码处理，之后将编码处理后的音频数据分别发送给D和E。

通过根据角色的不同，采用不同的手段得到要转发的数据，可以尽量降低CPU消耗以及网络流量开销。

另外，如图2所示，当听众的个数为多个时，可以不需要对应每个听众设置一个编码器，而由同一个编码器对混音处理后的音频数据进行编码处理。例如，参见图2，对应D和E，都由同一个编码器(conf Encoder)进行编码处理。

通过采用同一个编码器对应不同听众进行处理，可以相对于Full-transcoding模式，减少编码器的数量，由于CPU的开销主要是由编码器引起的，因此可以降低CPU开销。

进一步的，考虑到发言者可能不具有多路解码能力，此时，可以类似Full-transcoding的处理流程，即对其他发言者的解码后的音频数据进行混音以及编码后得到要转发的音频数据。

例如，参见图4，如果所述当前角色是发言者，且其他发言者的个数是多个时，确定要转发的音频数据的具体流程可以包括：

S41：确定所述发言者是否具有多路解码能力。

其中，服务器可以与发言者进行预设格式的信令交互，通过信令交互获知发言者是否具有多路解码能力。例如，服务器向A发送查询信令，查询信令用于查询A是否具有多路解码能力，A接收到该信令后，获取自身的能力，如果具有多路解码能力，则向服务器反馈具有多路解码能力的反馈信令，反之反馈不具有多路解码能力的反馈信令。而具体的查询信令以及反馈信令的格式可以是预先规定的，例如，某个字段用特定值表示查询信令，某个字段用1或0表示具有或不具有多路解码能力。

S42：在具有多路解码能力时，获取除自身之外的其他发言者的解码前的音频数据，并将所述解码前的音频数据打包后确定为要转发的音频数据。

该步骤的具体内容可以参见S31，在此不再赘述。

S43：在不具有多路解码能力时，获取出自身之外的其他发言者的解码后的音频数据，并对所述解码后的音频数据进行混音，以及对混音后的音频数据进行编码，将编码后的音频数据确定为要转发的音频数据。

例如，A是发言者，但A不具有多路解码能力，则可以获取B和C的解码后的音频数据，对B和C的解码后的音频数据进行混音处理，再对混音处理后的音频数据进行编码处理，将编码处理后的音频数据确定为转发给A的音频数据。

通过检测多路解码能力，可以很好解决具有或不具有多路解码能力的终端同时接入会议的兼容性问题。

另一实施例中，还可以对发言者的数量进行限制，以获取更优良的收听效果。参见图5，该方法还可以包括：

S51：检测发言者的数量，并在该数量超过预设个数时，从检测到的发言者中选择出预设个数的发言者。

之后，在根据当前角色获取要转发的音频数据时，采用的发言者的解码前或解码后的音频数据时，该采用的发言者是指选择出的预设个数的发言者。

可选的，预设个数可以是3个或者2个。

以3个为例，假设检测到的发言者是4个，则可以根据音频特性，例如每个音频数据的能量值，选择能量值较大的3个音频数据对应的发言者作为选择出的发言者。

S13：将所述要转发的音频数据，发送给所述作为接收方的终端。

该步骤可以由服务器内的发送模块执行。参见图2，作为接收方的终端用23表示。

具体的，当发言者是A，B，C，且接收方都具有多路解码能力时，将B的解码前的音频数据和C的解码前的音频数据打包(B+C packet)后发送给A，将A的解码前的音频数据和C的解码前的音频数据打包(A+C packet)后发送给B，将A的解码前的音频数据和B的解码前的音频数据打包(A+B packet)后发送给C。

而对于听众D，E，是将A的解码后的音频数据，B的解码后的音频数据，以及C的解码后的音频数据进行混音，得到混音后的音频数据(A+B+C PCM)，再对混音后的音频数据进行编码(由conf Encoder进行编码)，得到编码后的音频数据，将该编码后的音频数据发送给D和E。

需要说明的是，图2中的作为接收方的D和E中虽然标识了多个解码器(Decoder)，但是，对于当前作为听众的角色，该D和E只需要一个解码器就可以，多个解码器可以在D和E作为发言者时采用。

本实施例中，通过获取解码前的音频数据和解码后的音频数据，并根据当前角色的不同，采用不同的方式获取要转发的音频数据，可以兼顾Full-transcoding模式和relay模式的优点，尽量降低CPU消耗和网络流量消耗。具体的，现有技术一需要对应每个终端设置编码器，而本实施例可以只设置一个编码器，由于编码器占用较大的CPU开销，因此，本实施例可以解决音频通讯***运营级别架构服务器(Server)的CPU成本问题，显著提升单CPU的并发处理能力。由于大部分终端处于听众状态，对听众对应的音频数据进行编码，而不是直接转发多路音频数据，可以降低绝大部分与会终端的网络流量。通过Server的优化取得CPU消耗和网络流量的平衡，即在有效降低CPU消耗情况下，同时也降低了Server和终端(Client)的IO网络流量。

图6是本发明另一实施例提出的音频数据处理装置的结构示意图，该装置可以是指服务器，该装置60包括：

接收及解码模块61，用于接收作为发送方的终端发送的解码前的音频数据，以及，对所述解码前的音频数据进行解码，得到解码后的音频数据；

获取模块62，用于确定作为接收方的终端的当前角色，如果当前角色是发言者，根据所述解码前的音频数据获取要转发的音频数据，或者，如果当前角色是听众，根据所述解码后的音频数据获取要转发的音频数据；

当前角色可以包括：发言者，或者，听众。

可选的，参见图7，所述获取模块62包括：

第一单元621，用于确定作为接收方的终端的当前角色；

可以根据音频特性，在不解码的前提下确定出发言者，以及将不是发言者的其余终端确定为听众。音频特性例如为音频数据的能量值。

第二单元622，用于如果所述当前角色是发言者，获取除自身之外的其他发言者的解码前的音频数据，并将所述解码前的音频数据打包后确定为要转发的音频数据；或者，如果所述当前角色是听众，获取发言者的解码后的音频数据，并对所述解码后的音频数据进行混音处理，以及对混音处理后的音频数据进行编码处理，得到编码后的音频数据，并将所述编码后的音频数据确定为要转发的音频数据。

可选的，当听众有多个时，所述第二单元622用于对混音处理后的音频数据进行编码处理，包括：

采用同一个编码器对混音处理后的音频数据进行编码处理。

另一实施例中，参见图7，该装置60还包括：

选择模块64，用于检测发言者的数量，并在该数量超过预设个数时，从检测到的发言者中选择出预设个数的发言者。

可选的，预设个数可以是3个或者2个。

通过对发言者的数量进行限制，可以获取更优良的收听效果。

可选的，参见图7，如果当前角色是发言者，且其他发言者的个数是多个时，所述获取模块62还包括：

第三单元623，用于确定所述发言者是否具有多路解码能力；

其中，第三单元可以与发言者进行预设格式的信令交互，通过信令交互获知发言者是否具有多路解码能力。例如，第三单元向A发送查询信令，查询信令用于查询A是否具有多路解码能力，A接收到该信令后，获取自身的能力，如果具有多路解码能力，则向服务器反馈具有多路解码能力的反馈信令，反之反馈不具有多路解码能力的反馈信令。而具体的查询信令以及反馈信令的格式可以是预先规定的，例如，某个字段用特定值表示查询信令，某个字段用1或0表示具有或不具有多路解码能力。

所述第二单元622具体用于在所述第三单元确定出所述发言者具有多路解码能力时，获取除自身之外的其他发言者的解码前的音频数据；

具体内容可以参见S31，在此不再赘述。

第四单元624，用于在不具有多路解码能力时，获取出自身之外的其他发言者的解码后的音频数据，并对所述解码后的音频数据进行混音，以及对混音后的音频数据进行编码，将编码后的音频数据确定为要转发的音频数据。

发送模块63，用于将所述要转发的音频数据，发送给所述作为接收方的终端。

当发言者是A，B，C，且接收方都具有多路解码能力时，将B的解码前的音频数据和C的解码前的音频数据打包(B+C packet)后发送给A，将A的解码前的音频数据和C的解码前的音频数据打包(A+C packet)后发送给B，将A的解码前的音频数据和B的解码前的音频数据打包(A+B packet)后发送给C。

需要说明的是，在本发明的描述中，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本发明的描述中，除非另有说明，“多个”的含义是指至少两个。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本发明的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本发明的实施例所属技术领域的技术人员所理解。

应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行***执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本发明各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管上面已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims

1.一种音频数据处理方法，其特征在于，包括：

接收作为发送方的终端发送的解码前的音频数据，以及，对所述解码前的音频数据进行解码，得到解码后的音频数据；

确定作为接收方的终端的当前角色，如果当前角色是发言者，根据所述解码前的音频数据获取要转发的音频数据，或者，如果当前角色是听众，根据所述解码后的音频数据获取要转发的音频数据；

将所述要转发的音频数据，发送给所述作为接收方的终端；

其中，所述确定作为接收方的终端的当前角色包括：

检测每个所述解码前的音频数据的能量值，当作为接收方的终端的所述解码前的音频数据的能量值大于预设值，则确定作为接收方的终端为发言者，否则是听众。

2.根据权利要求1所述的方法，其特征在于，所述根据所述当前角色，获取要转发的音频数据，包括：

如果所述当前角色是发言者，获取除自身之外的其他发言者的解码前的音频数据，并将所述解码前的音频数据打包后确定为要转发的音频数据；或者，

如果所述当前角色是听众，获取发言者的解码后的音频数据，并对所述解码后的音频数据进行混音处理，以及对混音处理后的音频数据进行编码处理，得到编码后的音频数据，并将所述编码后的音频数据确定为要转发的音频数据。

3.根据权利要求1所述的方法，其特征在于，所述根据所述当前角色，获取要转发的音频数据之前，所述方法还包括：

检测发言者的数量，并在该数量超过预设个数时，从检测到的发言者中选择出预设个数的发言者，以便根据选择出的发言者进行处理。

4.根据权利要求2所述的方法，其特征在于，当听众有多个时，所述对混音处理后的音频数据进行编码处理，包括：

采用同一个编码器对混音处理后的音频数据进行编码处理。

5.根据权利要求2所述的方法，其特征在于，如果当前角色是发言者，且其他发言者的个数是多个时，所述获取除自身之外的其他发言者的解码前的音频数据之前，所述方法还包括：

确定所述发言者是否具有多路解码能力，以便在具有多路解码能力时，获取除自身之外的其他发言者的解码前的音频数据；或者，

在不具有多路解码能力时，获取出自身之外的其他发言者的解码后的音频数据，并对所述解码后的音频数据进行混音，以及对混音后的音频数据进行编码，将编码后的音频数据确定为要转发的音频数据。

6.一种音频数据处理装置，其特征在于，包括：

接收及解码模块，用于接收作为发送方的终端发送的解码前的音频数据，以及，对所述解码前的音频数据进行解码，得到解码后的音频数据；

获取模块，用于确定作为接收方的终端的当前角色，如果当前角色是发言者，根据所述解码前的音频数据获取要转发的音频数据，或者，如果当前角色是听众，根据所述解码后的音频数据获取要转发的音频数据；

发送模块，用于将所述要转发的音频数据，发送给所述作为接收方的终端；

其中，所述获取模块：具体用于检测每个所述解码前的音频数据的能量值，当作为接收方的终端的所述解码前的音频数据的能量值大于预设值，则确定作为接收方的终端为发言者，否则是听众。

7.根据权利要求6所述的装置，其特征在于，所述获取模块包括：

第一单元，用于确定作为接收方的终端的当前角色；

第二单元，用于如果所述当前角色是发言者，获取除自身之外的其他发言者的解码前的音频数据，并将所述解码前的音频数据打包后确定为要转发的音频数据；或者，如果所述当前角色是听众，获取发言者的解码后的音频数据，并对所述解码后的音频数据进行混音处理，以及对混音处理后的音频数据进行编码处理，得到编码后的音频数据，并将所述编码后的音频数据确定为要转发的音频数据。

8.根据权利要求6所述的装置，其特征在于，还包括：

选择模块，用于检测发言者的数量，并在该数量超过预设个数时，从检测到的发言者中选择出预设个数的发言者。

9.根据权利要求7所述的装置，其特征在于，当听众有多个时，所述第二单元用于对混音处理后的音频数据进行编码处理，包括：

采用同一个编码器对混音处理后的音频数据进行编码处理。

10.根据权利要求7所述的装置，其特征在于，如果当前角色是发言者，且其他发言者的个数是多个时，所述获取模块还包括：

第三单元，用于确定所述发言者是否具有多路解码能力；

所述第二单元具体用于在所述第三单元确定出所述发言者具有多路解码能力时，获取除自身之外的其他发言者的解码前的音频数据；

第四单元，用于在不具有多路解码能力时，获取出自身之外的其他发言者的解码后的音频数据，并对所述解码后的音频数据进行混音，以及对混音后的音频数据进行编码，将编码后的音频数据确定为要转发的音频数据。