CN108076306A

CN108076306A - 会议实现方法、装置、设备和系统、计算机可读存储介质

Info

Publication number: CN108076306A
Application number: CN201711482042.3A
Authority: CN
Inventors: 胡景欣
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2017-12-29
Filing date: 2017-12-29
Publication date: 2018-05-25
Anticipated expiration: 2037-12-29
Also published as: CN108076306B; WO2019128204A1

Abstract

一种会议实现方法、装置、设备和系统，计算机可读存储介质，该会议实现方法包括：获取终端所在会场的原始语音以及所述原始语音对应的翻译语音，生成多声道音频流，且一个声道对应一种语言类型的音频流；将所述多声道音频流进行编码获得多声道编码包；将所述多声道编码包发送给多点控制单元。本申请提供的方案，将多种语言类型的音频流组成多声道音频流发送给多点控制单元，降低了网络通信量，减少了对资源的占用，提高了通信效率。

Description

会议实现方法、装置、设备和系统、计算机可读存储介质

技术领域

本发明涉及通信技术，尤指一种会议实现方法、装置、设备和系统、以及一种计算机可读存储介质。

背景技术

在信息交流全球化的今天，视频会议业务应用也越来越广泛，跨地区化交流不断增多，多国多地区使用不同语言的人共同交流，实现沟通无障碍化，这对政治、经济、文化各方面的影响都是巨大的。

视频会议是一种多媒体通信手段，可以同时实现两个或多个地点之间的图像、语音和数据的交互功能，利用电视设备和通信网络召开会议。视频会议系统一般由视频终端、传输网络和多点控制单元(Multipoint Control Unit，简称MCU)等几部分组成。视频会议基本的语音业务涉及两个通话方，通话双方可以相互听到对方的声音，而在多方通话的会议业务中，同时通话的可能不止两方，其中任意一方的语音信号够可以被传送至所有其他通话方，而每一通话方都同时可听到多个其他通话方的声音。而当上述多方通话视频会议业务中使用多种语言时，需要对发言者的讲话内容按需进行翻译转换，使参与会议的不同国家不同地区使用不同语言的人能够一起交流，沟通无障碍。

相关技术中，实现多语种视频会议的技术是：各终端能够按照自身的翻译语言类型对会场的原始语音进行翻译，输出两路音频：一路是源语音，一路是翻译语音，需要两个通道传输到MCU，MCU会判断翻译会场上传的翻译后的语音的语言类型，MCU进行混音处理时，需要多个混音器，按照识别的语言类型对翻译语音进行混音以及对原始语音进行混音，在对各语言类型的语音进行混音处理后，针对每一个会场，MCU需发送两路音频数据给会场：一路是各会场原始语音混音，一路是目的会场相应语言类型的翻译混音。上述方案网络通信量比较大，容易造成网络拥塞。

发明内容

本发明至少一实施例提供了一种会议实现方法、装置、设备和系统、计算机可读存储介质，降低网络资源的占用，提高会议效率。

为了达到本发明目的，本发明至少一实施例提供了一种会议实现方法，包括：

获取终端所在会场的原始语音以及所述原始语音对应的翻译语音，生成多声道音频流，且一个声道对应一种语言类型的音频流；

将所述多声道音频流进行编码获得多声道编码包；

将所述多声道编码包发送给多点控制单元。

本发明至少一实施例提供一种会议实现装置，包括：

码流生成单元，设置为，获取终端所在会场的原始语音以及所述原始语音对应的翻译语音，生成多声道音频流，且一个声道对应一种语言类型的音频流；

第一编码单元，设置为，将所述多声道音频流进行编码获得多声道编码包；

第一发送单元，设置为，将所述多声道编码包发送给多点控制单元。

本发明至少一实施例提供一种会议实现方法，包括：

接收参与会议的终端发送的多声道编码包，进行解析获得多声道音频流，其中，所述多声道音频流中每个声道对应一个语言类型的音频流；

确定需要混音的终端，将所确定的终端的多声道音频流中同一语言类型的音频流进行混音，获得多声道混音音频流；

将所述多声道混音音频流进行编码获得多声道混音编码包；

将所述多声道混音编码包发送给参与会议的终端。

本发明至少一实施例提供一种会议实现装置，包括：

第二接收单元，设置为，接收参与会议的终端发送的多声道编码包；

第二解析单元，设置为，对所述多声道编码包进行解析获得多声道音频流，其中，所述多声道音频流中每个声道对应一个语言类型的音频流；

混音单元，设置为，确定需要混音的终端，将所确定的终端的多声道音频流中同一语言类型的音频流进行混音，获得多声道混音音频流；

第二编码单元，设置为，将所述多声道混音音频流进行编码获得多声道混音编码包；

第二发送单元，设置为，将所述多声道混音编码包发送给参与会议的终端。

本发明至少一实施例提供一种会议实现方法，包括：

接收多点控制单元发送的多声道混音编码包；

解析所述多声道混音编码包，获取多声道混音音频流。

本发明至少一实施例提供一种会议实现装置，包括：

第一接收单元，设置为，接收多点控制单元发送的多声道混音编码包；

第一解析单元，设置为，解析所述多声道混音编码包，获取多声道混音音频流。

本发明至少一实施例提供一种会议实现设备，包括存储器和处理器，所述存储器存储有程序，所述程序在被所述处理器读取执行时，实现上述任一实施例任一所述的会议实现方法。

本发明一实施例提供一种计算机可读存储介质，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现如权利要求1至6、8至13、15至17任一所述的会议实现方法。

本发明一实施例提供一种会议实现系统，包括：多点控制单元和至少一个终端，其中：

所述终端设置为，获取所述终端所在会场的原始语音以及所述原始语音对应的翻译语音，生成多声道音频流，且一个声道对应一种语言类型的音频流；将所述多声道音频流进行编码获得多声道编码包；将所述多声道编码包发送给所述多点控制单元，以及，接收多点控制单元发送的多声道混音编码包；解析所述多声道混音编码包，获取多声道混音音频流；

所述多点控制单元设置为，接收参与会议的终端发送的多声道编码包，进行解析获得多声道音频流，其中，所述多声道音频流中每个声道对应一个语言类型的音频流；确定需要混音的终端，将所确定的终端的多声道音频流中同一语言类型的音频流进行混音，获得多声道混音音频流；将所述多声道混音音频流进行编码获得多声道混音编码包；将所述多声道混音编码包发送给参与会议的终端。

本申请至少一实施例提供的会议实现方法，不同于相关技术中，使用不同通道分别传输原始语音和翻译语音，本实施例中，将不同语言类型的语音生成多声道编码包后发送，仅需要一路通道，减少了对端口的占用。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

附图说明

附图用来提供对本发明技术方案的进一步理解，并且构成说明书的一部分，与本申请的实施例一起用于解释本发明的技术方案，并不构成对本发明技术方案的限制。

图1为本发明一实施例提供的多语会议的组网示意图。

图2为本发明一实施例提供的会议实现方法流程图。

图3为本发明一实施例提供的会议实现方法终端侧处理示意图。

图4为本发明一实施例提供的多语会议语种协商流程图。

图5为本发明一实施例提供的基于H323协议终端呼叫流程图。

图6为本发明一实施例提供的基于SIP协议终端呼叫流程图。

图7(a)为相关技术中提供的RTP报文格式示意图。

图7(b)为本发明一实施例提供的对RTP报文扩展示意图。

图8(a)为本发明一实施例提供的多语会议多声道编码打包流程示意图。

图8(b)为本发明一实施例提供的多语会议多声道解包解码流程示意图。

图9为本发明第一实施例提供的会议实现方法MCU侧实现的流程图。

图10为本发明一实施例提供的MCU混音过程原理图。

图11为本发明一实施例提供的会议实现方法流程图(终端侧)。

图12为本发明一实施例提供的多语会议电视应用场景示意图。

图13为本发明一实施例提供的多语会议电视应用场景示意图。

图14为本发明一实施例提供的多语会议电视应用场景示意图。

图15为本发明一实施例提供的多语会议电视应用场景示意图。

图16为本发明一实施例提供的会议实现装置框图。

图17为本发明一实施例提供的会议实现装置框图。

图18为本发明一实施例提供的会议实现装置框图。

图19为本发明一实施例提供的会议实现系统示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下文中将结合附图对本发明的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。

在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

相关技术中的视频会议实现方案，存在如下缺点：

终端与MCU直接连接原始语音通道和翻译语音通道，分别采用不同的通道进行传输，通过原始语音通道传输原始语音，通过翻译语音通道传输翻译语音，网络通信量加大，容易造成网络拥塞，终端与MCU之间的音频输入输出接口的占用数量加倍。

一个会议室根据翻译语音的语言类型对所述翻译语音进行混音处理，需要创建多个混音过程，随着语音种类的增加，混音器个数随之线性增加，导致了混音过程的重复计算，加大了混音过程对CPU性能的占用。

图1为本发明一实施例提供的多语会议的组网示意图。如图1所示，支持多语会议电视的系统中，包括至少一个终端以及与各终端连接的MCU。终端与MCU通过通信网络连接。终端通过标准接口连接到MCU，实现图像和语音的混合与交换。MCU根据会议各会场的语音需求以及翻译能力确定会议支持的语言类型，其中，会议支持的语言类型可以是一种或多种。会议中的各个会场中的与会人员所使用的交流语言可以多样化，各个会场可以根据需要设置翻译人员，对发送以及接收到的语音进行翻译。各会场可以根据会议确定的会议语言类型对本会场的声音进行翻译转换，各会场接收的会议混音可以按需直接收听播放或翻译成自身所在会场可懂的语言类型再进行收听播放。其中终端对本会场的原始语音进行转换成会议语言类型的翻译语音的方法，可采用人工方式或者采用软件硬件等非人工的智能方式。目前的国际会议基本上采用对发言者的讲话内容进行人工口头翻译(简称口译)的方式。本申请中以人工翻译这种翻译方式为例进行方案的描述，但是不限于该种翻译方式或者手段。

本发明一实施例提供一种会议实现方法，如图2所示，包括：

步骤201，获取终端所在会场的原始语音以及所述原始语音对应的翻译语音，生成多声道音频流，且一个声道对应一种语言类型的音频流；

步骤202，将所述多声道音频流进行编码获得多声道编码包；

步骤203，将所述多声道编码包发送给MCU。

本实施例提供的会议实现方法，将不同语言类型的音频流将其组成多声道编码包传输给MCU。本实施例中，多声道编码包可以通过一路音频通道进行发送，因此，仅需一路音频通道实现了多路不同语言类型的音频传输，相比多通道的实现方式，降低了网络通信量，减少了对资源的占用，提高了通信效率。

在一实施例中，步骤201之前还包括：

步骤200，获取会议支持的语言类型；

所述步骤201中的所述翻译语音为所述原始语音对应的所述会议支持的语言类型的翻译语音。

一般地，由多点控制单元与终端进行协商确定会议支持的语言类型，并在确定会议支持的语言类型后，由多点控制单元将会议支持的语言类型发送给终端。因此，终端获取会议支持的语言类型的一种方式为：所述终端接收所述多点控制单元发送的所述会议支持的语言类型。

需要说明的是，会议支持的语言类型也可以预先进行配置。

其中，所述多声道音频流中包括所述会议支持的每个语言类型的音频流。比如，会议支持的语言类型为3个时，多声道音频流中包括3个声道，每个声道为一个语言类型的音频流。

在一实施例中，所述终端获取所在会场的原始语音以及所述原始语音对应的翻译语音，生成多声道音频流，包括：

当所述原始语音的语言类型为所述会议支持的语言类型之一时，将所述原始语音对应的音频流作为一个声道的音频流，将所述原始语音对应的所述会议支持的除所述原始语音的语言类型外的其他语言类型的翻译语音作为其他声道的音频流，生成所述多声道音频流；比如，会场的原始语音为中文，会议支持中文和英文，则将中文语音作为一个声道的音频流，将该中文语音翻译得到的英文语音作为一个声道的音频流，得到中文语音和英文语音组成的多声道音频流；

当所述原始语音的语言类型非所述会议支持的语言类型时，将所述原始语音对应的所述会议支持的每个语言类型的翻译语音分别作为一个声道的音频流，生成所述多声道音频流。比如，会场的原始语音为法语，会议支持中文和英文，则将原始的法语语音翻译得到的中文语音作为一个声道的音频流，将原始的法语语音翻译得到的英文语音作为一个声道的音频流，得到中文语音和英文语音组成的多声道音频流。

其中，每个声道具体对应哪个语言类型可以预先设置，也可以通过语言类型信息进行指示，具体的，包括：

所述多声道编码包中每个声道对应预设语言类型的音频流；或者，所述多声道编码包中携带每个声道的语言类型信息。比如，预设第一声道对应中文，第二声道对应英文，则组成多声道编码包时，将中文语音的音频流作为第一声道的音频流，将英文语音的音频流作为第二声道的音频流。另外一种方式，每个声道携带语言类型信息，该语言类型信息指示该声道的音频流的语言类型。

图3为本发明实施例提供的支持多语会议的终端处理过程示意图。实际应用中，由会场的麦克风拾取会场发言者的原始语音，如果会场的原始语音仅为一种语言类型且与会议支持的语言类型一致，即可直接将原始语音作为终端一个声道的声音源输入，若会场的原始语音为多种语言类型或者与会议支持的语言类型不一致，则需要经过会场设置的翻译机构进行翻译转换，将本会场的原始语音转换成会议支持的语言类型的翻译语音，每一种翻译语音对应终端的一个声道输入，经过终端的编码器进行多声道编码，打包形成一路音频输出，发送给MCU。由于各终端已对自身所在的会场发言的原始语音进行了翻译，因此，MCU无需再进行翻译，直接将各终端的翻译语音进行多声道混音处理后，将混音结果发送给各终端即可，具体实现方式见实施例。终端接收到MCU发送的多声道混音编码包后，首先进行解包解出各个声道的编码数据，然后对各个声道的编码数据进行解码，然后判断各个声道中的语言类型与本会场支持的语言类型是否一致，按需对会议混音进行翻译转换，可以经扬声器输出，也可以接入不同的外设收听，也可以通过终端内部的语音文字转换模块转换为文字后，在终端的屏幕上进行字幕输出。

召开多语会议的协商过程中，首先由MCU与终端协商确定会议支持的语言类型，MCU混音的声道数量也是会议支持的语言类型数量，在同一个混音器中完成多语种多声道混音。

图4为本发明一实施例提供的会议支持的语言类型的协商过程流程图。如图4所示，包括：

步骤401，会议召开时的信令控制阶段，MCU与各个终端开始进行会议语言协商，MCU获取每个会场的信息，包括如下至少之一：会场优先级，会场的听说属性(仅作为发言端或者仅作为收听端或者既要发言又要收听)，会场支持的语言类型(会场的发言语种)，会场具备的翻译能力等等。每个终端都可以从多个不同的语种中自由选择收听的语种，对于发言权，可以进行权限设定，比如对于一般身份的终端，其发言的语种只能使用默认的语种，身份为翻译或者高级的终端可以选择发言的语种为其他的语种。

步骤402，MCU遍历所有参与会议的终端；

步骤403，判断是否已遍历完所有参与会议的终端，如果是，结束，得到会议支持的语言类型L1～Ln；否则，转步骤404；

步骤404，判断终端所在会场的优先级是否最高，如果是，转步骤407，否则，转步骤405；

步骤405，判断终端所在会场的发言语种是否为会议中所有会场使用最多的语言类型，如果是，转步骤407，否则，转步骤405；

步骤406，判断会场使用的发言语种是否与其他会场具备互译功能力，如果是，转步骤407，否则，返回步骤402。

比如，比如，某个会场使用英文，其他会场均能将英文翻译为自身使用的语言，则可以将英文作为会议支持的一种语言类型。

步骤407，将该会场的发言语种作为会议支持的一种语言类型，转步骤402。

需要说明的是，上述协商会议支持的语言类型的方式仅为示例，可以通过其他方式确定会议支持的语言类型。比如，直接使用默认的语言类型。

为了使终端能有效获取会议的语种类型，可以使用新的终端上会协议流程，分别如图5和图6所示。

图5为H.323协议呼叫流程，根据H.323协议标准，呼叫流程大体上可以分为Q931阶段和H245阶段。这里以MCU呼叫终端进行说明：

步骤501，首先进入Q931阶段，即MCU发送setup消息；

步骤502～504，终端收到后依次回复callProceeding、alerting、connect消息给MCU；至此Q931阶段完成，接着进入H245阶段。

H245阶段主要包括能力集交互、主从确认和打开逻辑通道三部分，能力交互包括互相发送terminalCapabilitySet和terminalCapabilitySetAck，主从确认过程包括相互发送masterSlaveDetermination和masterSlaveDeterminationAck，打开逻辑通道包括相互发送openLogicalChannel和openLogicalChannelAck。当双向音频逻辑通道打开后，即表示上端成功。以上是标准的上端流程，在此基础上添加一条非标准的私有消息，即在能力交互完成后，通过发送一条nonStandard消息，将本申请中所述的会议支持的语言类型通知给终端。具体包括：

步骤505，MCU发送terminalCapabilitySet消息给终端；

步骤506，MCU发送masterSlaveDetermination消息给终端；

步骤507，终端发送terminalCapabilitySet消息给MCU；

步骤508，MCU发送terminalCapabilitySetAck消息给终端；

步骤509，终端发送masterSlaveDetermination消息给MCU；

步骤510，MCU发送masterSlaveDeterminationAck消息给终端；

步骤511，终端发送terminalCapabilitySetAck消息给MCU；

步骤512，终端发送masterSlaveDeterminationAck消息给MCU；

步骤513，MCU发送nonStandard消息给终端，携带会议支持的语言类型；

步骤514，终端发送openLogicalChannel消息给MCU；

步骤515，MCU发送openLogicalChannelAck消息给终端；

步骤516，MCU发送openLogicalChannel消息给终端；

步骤517，终端发送openLogicalChannelAck消息给MCU。

通过上述方式，MCU将会议支持的语言类型通知终端。需要说明的是，图5所示方式仅为示例，也可以通过nonStandard消息外的其他消息携带会议支持的语言类型，另外，携带会议支持的语言类型的消息也不限于步骤513中，也可以在其他位置，比如其他步骤之前或之后。

图6为SIP协议呼叫流程图，相对于H.323协议，SIP协议呼叫流程较为简单，如图6所示，包括：

步骤601，MCU发送INVITE消息给终端；

步骤602，终端发送100Trying消息给MCU；

步骤603，终端发送180Ringing消息给MCU；

步骤604，终端发送200OK消息给MCU；

步骤605，MCU发送ACK消息给终端；至此上端流程完成。

本申请中，在此基础上添加一条非标准的私有消息，通过发送一条INFO消息，将会议支持的语言类型通知给终端，包括：。

步骤606，MCU发送INFO消息给终端，携带会议支持的语言类型；

步骤607，终端发送200OK消息给MCU。

通过上述方式，MCU将会议支持的语言类型通知终端。需要说明的是，通过IFO消息携带会议支持的语言类型仅为示例，也可以使用其他消息携带会议支持的语言类型。

音频包在互联网上传输采用的数据包格式遵守实时传送协议(Real-timeTransport Protocol，简称RTP或RTTP)。其中RTP协议是一个网络传输协议，由IETF的多媒体传输工作小组1996年在RFC 1889中公布。

RTP报文包括：RTP报头和RTP负载，其中，如图7(a)所示，RTP报头包括：

1.V：RTP协议的版本号，占2位，当前协议版本号为2。

2.P：填充标志，占1位，如果P＝1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。

3.X：扩展标志，占1位，如果X＝1，则在RTP报头后跟有一个扩展报头。

4.CC：CSRC(Contributing Source，特约信源)计数器，占4位，指示CSRC标识符的个数。

5.M:标记，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。

6.PT:有效载荷类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM(GlobalSystem for mobile Communications，全球移动通信系统)音频、JPEG(JointPhotographic Experts Group，联合图像专家小组)图像等，在流媒体中大部分是用来区分音频流和视频流，便于客户端进行解析。

7.序列号(sequence number)：占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。这个字段当下层的承载协议用UDP的时候，网络状况不好的时候可以用来检查丢包。同时出现网络抖动的情况可以用来对数据进行重新排序，在helix服务器中这个字段是从0开始的，同时音频包和视频包的sequence是分别记数的。

8.时戳(Timestamp)：占32位，时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。

9.同步信源(synchronization source，简称SSRC)标识符：占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。

10.特约信源(CSRC)标识符：每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。

本申请的一个实施例中，对RTP报文进行扩展，将RTP协议中固定头的扩展标志位(X)置为“1”，启用扩展头，紧跟在报头后面是一个长度可变的头扩展，利用头扩展传递多通道语音的各个通道语种以及编码长度等信息，其格式如图7(b)所示。

如图7(b)所示，头扩展包括多个扩展项，具体的，包括：

标识信息字段，用于标识当前头扩展的类型；可以占用16比特；标识信息字段具体实现由上层协议定义。

长度字段(length)，用于指示该通道一共有多少种声道编码数据，即指示后续的帧信息字段的个数。

多个帧信息字段，可以跟随在length字段之后，每个帧信息字段包括：帧类型字段和帧长度字段，其中，帧类型字段用于指示一种帧类型即一个声道的语言类型，帧长度字段用于指示帧长度即该声道的编码数据长度。其中，每个帧信息字段可以占用32比特，其前16个比特为帧类型字段，后16比特为帧长度字段。当然，每个帧信息字段的长度可以根据需要设定，本申请对此不作限定。

需要说明的是，扩展项中也可以不包含标识信息字段。另外，也可以根据需要扩展其他字段，本申请对此不作限定。

需要说明的是，上述扩展头的格式仅为示例，可以根据需要定义其他格式的扩展头携带各通道相关信息，本申请对此不作限定。在本申请的一个实施例中，可以使用上述扩展的RTP报文传输多声道编码包或者多声道混音编码包。当然，在本申请的其他实施例中，也可以使用其他格式的报文传输多声道混音编码包，本申请对此不作限定。

图8(a)为本发明一实施例提供的多语会议多声道编码打包流程图。如图8(a)所示，终端侧，首先由会场的麦克风拾取会场发言者的原始语音，传输到终端侧的翻译室，经翻译人员翻译转换后，输入到终端的不同声道。当会议为双语会议时，终端的左右声道分别放置终端对应会议语种的终端语音，采用立体声编码。当会议的语种多于两种语言的时候，终端分别对各个声道进行编码，获得声道信息和编码数据，如图8(a)所示，获取声道信息1至声道信息n，以及编码数据1至编码数据n，其中，声道信息中包括语言类型信息和编码数据长度信息。将各个声道的语言类型作为帧类型，编码数据长度作为帧长度分别填入RTP头扩展的各相应字段，最后将各声道的编码数据按照头扩展的语言类型顺序依次排列作为RTP负载，最终生成包括RTP头、RTP头扩展和RTP负载的多声道编码包，其中，RTP头中的扩展标志位指示存在扩展头，经网络发送出去。MCU侧同理，混音器输出的多声道混音数据发送给MCU的编码器，编码器按照混音器创建时各个声道的语种信息，对应混音器的多声道混音数据，进行编码后，在编码数据前加上RTP头扩展的语种标识以及编码长度等信息。在其他实施例中，多声道编码包也可以只包括RTP头和RTP负载，RTP负载中携带各声道的数据，每个声道的数据包括该声道的语种标识信息和该声道的编码数据，其中，语种标识信息指示该声道的语言类型。

图8(b)为本发明一实施例提供的多语会议多声道解包解码流程图。如图8(b)所示，在终端侧，接收MCU发送过来的包括RTP头、RTP头扩展和RTP负载的会议混音编码包，根据RTP头中的扩展标志位，可知该编码包存在头扩展，按照头扩展格式，对编码包中各个声道的数据进行解包。首先解析头扩展中各声道的语言类型以及各声道的编码数据长度，对应找到RTP负载中各个声道的编码数据，送入多个解码器解码后输出各个声道的会议声音。MCU侧同理，MCU接收到终端发送的多声道编码包，根据RTP头中的扩展标志位，可知该编码包存在头扩展，按照头扩展格式，对多声道编码包中各个声道的数据进行解包。首先解析头扩展中各声道的语言类型以及各声道道的编码数据长度，获得声道信息1至声道信息n，对应找到RTP负载中各个声道的编码数据，获得编码数据1至编码数据n，送入多个解码器解码后输出各个声道的会议声音给混音器模块进行多声道混音。

下面通过具体实施例进一步说明本申请。

图9为本发明第一实施例提供的会议实现方法流程图。本实施例的执行主体为MCU。如图9所示，包括：

步骤901，MCU接接收参与会议的终端发送的多声道编码包，对所述多声道编码包进行解析，获得多声道音频流；所述多声道音频流中每个声道对应一个语言类型的音频流；

由于各终端已对自身所在会场发言的原始语音进行了翻译，因此，MCU无需再进行翻译，MCU的解码器按照图8(b)所示步骤，对各个终端的多声道编码包进行解包解码，然后将各个声道的音频流送入混音器。

步骤902，所述MCU确定需要混音的终端，将所确定的各终端的多声道音频流中同一语言类型的音频流进行混音，获得多声道混音音频流，且一个声道对应一种语言类型的混音音频流；

MCU创建一个多声道的混音器，该混音器的声道数量与会议支持的语言类型的数量一致，MCU将解码后得到的各个声道的音频流，根据对应的语言类型，对应送入混音器的各个声道进行混音。

以会议支持的语言类型为中文和英文为例，假设确定需要混音的终端为第一终端和第二终端，获取第一终端的中文语音和英文语音，第二终端的中文语音和英文语音，将第一终端的中文语音和第二终端的中文语音进行混音，生成中文语音混音音频流，将第一终端的英文语音和第二终端的英文语音进行混音，生成英文语音混音音频流，中文语音混音音频流和英文语音混音音频流构成多声道混音音频流。

步骤903，所述MCU将所述多声道混音音频流进行编码获得多声道混音编码包，将所述多声道混音编码包发送给终端。

对于会议中的终端，MCU仅需建立一路音频通道进行与终端的音频传输。MCU发送给某个终端的多声道混音编码包中不包括该终端自身所在的会场的音频信息。

本实施例提供的会议实现方法，只需创建一个混音过程，混音器数量少，混音过程的计算量小，减少了对CPU的占用，且发送给同一个会场的原始语言和翻译语言混音的表达信息一致。

下面对步骤902进一步说明。MCU的混音单元包括：VAD模块、排序模块、选择模块、混音及交换处理模块。其中VAD模块是对会议发言端的SNR(信噪比)和能量进行估计。排序模块是根据VAD模块的运算结果，对会议的所有终端进行排序。选择模块从排序后的终端中挑出符合混音条件的若干个(比如音量最大的3个)终端进行混音。混音和交换处理模块是对参加混音的发言端进行混音处理，得到参加混音的各端口发送端数据。MCU的混音处理策略应使得任一会场听不到自身的声音，只听到其他会场的声音。如图10所示，包括：

步骤1001，获取终端的SNR和能量；

步骤1002，根据终端的SNR和能量判断终端是否参加排序和混音，生成终端链表；

该处理是为了排除不发言的终端，即只让发言的终端参加排序和混音，让不发言的终端不参加排序和混音。终端参加排序的条件有两个：一，终端不静音。二，终端被判断为发言端。终端链表中包括参加排序的终端。

步骤1003，对会议的终端链表进行排序；

其中，可以根据终端的能量和信噪比对终端链表进行排序。

步骤1004，根据排序后的终端链表选择参加混音的终端。

比如，可以选择三个音量最大的终端作为参加混音的终端。当然，可以根据需要选择更多或更少的终端作为参加混音的终端。

在选择参加混音的终端后，根据选择的混音端口数量实行两种不同方式的混音处理，分为混音端口数量等于1和混音端口数量大于1两种情况，其中：

混音端口数量等于1时，此时主要选择混音端口的输出比较重要，在非参与混音端口中选择一个非静音输入端口的输入当作混音端口的输出。

混音端口数量大于1时，此时内部混音端口相互混音，非参与混音端口的输出为所有混音端口输入的和。例如：A,B,C,D四个终端，通过SNR和能量判断A,B,C三个终端符合排序条件，可以参与混音；混音输出的结果是：A_out：B+C；B_out：A+C；C_out：B+A；D_out：A+B+C。其中A_out：B+C的含义是：将终端B和终端C发送至MCU的音频流进行混音后发送给终端A。

由于混音器支持多种不同声道数以及不同采样率的终端混音，所以在混音过程中还需进行声道数据之间的数据转换以及进行混音端口之间的采样率统一。

在下面各详述实施例中，可采用与本实施例相同的混音处理策略进行多语多声道语音的混音处理，不再赘述。

图11为本发明一实施例提供的一种会议实现方法流程图，如图11所示，包括：

步骤1101，终端接收MCU发送的多声道混音编码包；

步骤1102，所述终端解析所述多声道混音编码包，获得多声道混音音频流。

本实施例提供的会议实现方法，终端可以通过一个通道获取各声道的混音音频流，降低了对资源的占用。

在一可选实施例中，所述方法还包括：所述终端根据所述多声道混音编码包中携带的语言类型信息确定各声道的音频流所使用的语言类型，或者，根据预设的声道与语言类型的对应关系确定每个声道对应的语言类型。即有两种方式可以获取各声道的音频流的语言类型，一种是预先设定，比如预先设定第一声道为中文，第二声道为英文，第三声道为法文，等等，MCU在多声道混音编码包中按预设设定的方式使用第一声道携带中文音频流，第二声道携带英文音频流，第三声道携带法文音频流，终端从第一声道获取中文音频流，第二声道获取英文音频流，第三声道获取发文音频流。

在一可选实施例中，所述多声道编码包为实时传输协议报文，所述终端根据所述多声道混音编码包中携带的语言类型信息确定各声道的音频流所使用的语言类型包括：

所述终端从所述多声道编码包中的实时传输协议头扩展中的帧类型字段获取各声道的音频流所使用的语言类型信息。

在一可选实施例中，所述方法还包括，所述终端获得各声道的音频流后，如果其中一个声道的音频流的语言类型为所述终端所在会场使用的语言类型，则播放该声道的音频流。

相关技术中，终端接收到的原始语音混音为会议中所有发言者声音最大的若干个发言者的声音混音，终端接收到的翻译语音混音仅为该终端支持的语言类型对应的翻译语音的混音，无法获取所有会场翻译语音的有效信息，即同一个会场接收到的原始语音混音的表达信息与翻译语音混音的表达信息不一致。本实施例中，终端接收到的原始语音的表达信息与翻译语音混音的表达信息一致。

图12为本发明第二实施例提供的会议电视应用场景示意图。本实施例结合具体的应用场景对支持多语会议电视的方法实施例的技术方案进行详细说明。

如图12所示的应用场景中，中文会场、英文会场召开会议电视，各会场根据会议支持的语言类型，对会场的原始语音进行翻译处理，如该场景会议协商的语言为中文和英文，中文会场的原始语音为中文，则中文会场的左声道的音源为原始中文语音，右声道的音源为对原始语音进行翻译后的英文语音，英文会场的原始语音为英文，则英文会场的左声道的音源为对原始英文语音进行翻译后的中文语音，右声道的音源为该会场的原始语音即英文语音。在本实施例中，各会场的终端支持的语言类型为两种，MCU和各会场的终端的交互如下：

各会场的终端获取自身所在会场的原始语音，根据所在多语会议支持的语言类型，将原始语音直接作为左声道输入或者直接作为右声道输入或者经过翻译后作为左右声道的音源输入，通过终端的立体声编码，发送给MCU。如图12中文会场的终端将本会场中的原始语音(中文)直接作为左声道音源输入，原始语音翻译成英文后，作为右声道音源输入，通过立体声编码形成一路音频，通过一路音频通道发送给MCU。英文会场的终端将本会场中的原始语音(英文)直接作为右声道音源输入，原始语音翻译成中文后，作为左声道音源输入，进行编码形成一路音频，通过一路音频通道发送给MCU。

MCU将各终端发送的多声道音频流进行混音处理生成多声道混音编码包，并将发送到各终端。MCU的混音处理策略应使得任一会场听不到自身的声音，只听到其他会场的声音。此外，当发言的会场有多个时，可以设定参加混音的多个会场为音量最大的若干个会场，比如音量最大的三个会场。

各终端接收MCU发送的多声道混音编码包(本实施例中也可称为立体声混音)，解码接收到的多声道混音音频流(本实施例中为两个声道)，分别通过终端的左右声道选择性的进行播放。

如果MCU发送给某会场的终端的左右声道的立体声混音中的某声道声音与该会场支持的语言类型相同时，该会场的终端可以直接在所在会场中播放该声道的声音。比如中文会场接收到的立体声混音的左声道为中文会议混音，中文会场的终端可以直接在所在会场中播放左声道声音；又比如英文会场接收到的立体声混音的右声道为英文会议混音，英文会场的终端可以直接在所在会场中播放右声道声音。

对于接收到的立体声会议混音，会场可以根据具体的需求进行处理，如有的会场需要进行翻译，然后再进行播放，而有的会场则可以不进行翻译直接播放原始混音。本实施例中每个终端都可以不经过翻译直接收听左声道或者右声道的声音。在另一实施例中，会议的混音还可以通过语音转文字处理，形成字幕，在终端屏幕上显示。

图13为本发明第三实施例提供的会议电视应用场景示意图。本实施例结合具体的应用场景对支持多语会议电视的方法实施例的技术方案进行详细说明。

本实施例与第二实施例的区别在于会议中的会场自身的交流语言为多种。如图13所示的应用场景中，中文会场、英文会场和中英混合会场召开会议电视。同一会场中的与会人员所使用的语言类型可以多种，如中英文混合会场。各会场根据会议支持的语言类型，对会场的原始语音进行翻译处理，如该场景下，多语会议支持的语言为中文跟英文，中文会场的原始语音为中文，则中文会场的左声道的音源为原始中文语音，右声道的音源为对原始语音进行翻译的英文语音，英文会场的原始语音为英文，则英文会场的左声道的音源为对原始英文语音进行翻译的中文语音，右声道的音源为原始英文语音。一个会场可能会使用多种语言发言，如中英文混合会场，会场的原始语音相应的为多种语言类型，该会场的左声道音源为对原始语音进行翻译后得到的中文语音，该会场的右声道音源为对原始语音进行翻译后得到的英文语音。在本实施例中，各会场的终端翻译后的语言类型为固定的，即终端将本会场的原始语音翻译成会议支持的固定语言类型的语音。在本实施例中，在会议进行时，MCU和各会场的终端的工作方法如下：

各会场的终端获取自身所在会场的原始语音，根据所在多语会议支持的语言类型，将原始语音直接作为左声道输入或者直接作为右声道输入或者经过翻译后作为左右声道的音源输入，通过终端的立体声编码，发送给MCU。如，中文会场的终端将本会场中的原始语音(中文)作为左声道音源输入，原始语音翻译成英文后，作为右声道音源输入，通过立体声编码形成一路音频(即多声道编码包)，通过一路音频通道发送给MCU。英文会场的终端将本会场中的原始语音(英文)作为右声道音源输入，原始语音翻译成中文后，作为左声道音源输入，通过立体声编码形成一路音频(即多声道编码包)，通过一路音频通道发送给MCU。中英文混合会场的终端将本会场中的原始语音(中英混合)翻译成中文作为左声道音源输入，将本会场中的原始语音(中英混合)翻译成英文后，作为右声道音源输入，通过立体声编码形成一路音频，通过一路音频通道发送给MCU。

MCU将各终端发送的立体声多语语音进行混音处理，并将立体声混音(多声道混音编码包)发送到各终端。MCU的混音处理策略应使得任一会场听不到自身的声音，只听到其他会场的声音。此外，当发言的会场有多个时，可以设定参加混音的多个会场为音量较大的三个会场。

各终端接收MCU发送的立体声混音。同时，各终端解码接收MCU发送的立体声混音，分别通过终端的左右声道选择性的进行播放。

由于MCU发送给某会场的终端的左右声道的立体声混音中的某路声音可能与该会场支持的语言类型相同：比如中文会场接收到的立体声混音的左声道为中文会议混音，因此，中文会场的终端可以直接在所在会场中播放左声道声音。又比如英文会场接收到的立体声混音的右声道为英文会议混音，因此，英文会场的终端可以直接在所在会场中播放右声道声音。又比如中英文混合会场接收到的立体声混音的左声道为中文会议混音，右声道为英文会议混音，因此，中英文混合会场的与会成员可以根据自己熟悉的语言类型分别收听左右不同声道的会议混音。

从第二实施例以及第三实施例可以看出，本申请提出的会议实现方法，不仅可以有效的减少终端侧翻译人员的工作量，又可以有效满足多语会议环境下各个会场人员的语言听说需求。

图14为本发明第四实施例提供的会议电视应用场景示意图。本实施例结合具体的应用场景对支持多语会议电视的方法实施例的技术方案进行详细说明。

本实施例与第三实施例的区别在于，会议支持的语言类型为三种，各个会场之间具有互译的能力，确定为中英法三语会议。本实例中英法会场的音频采集到的原始会场声音后，会经过两种翻译转换，比如中文会场，原始语音作为终端声道1的输入，中译英的翻译语音作为终端声道2的输入，中译法的翻译声音作为终端声道3的输入，分别编码后，进行打包处理，具体实现方式见图8(a)。英文以及法文会场的声音输入处理步骤同理。

在本实施例中，在会议进行时，MCU和各会场的终端的工作方法如下：

(1)各会场的终端获取自身所在会场的原始语音以及会议支持的语言类型，确定翻译的种类，如英译汉或者汉译英或者其他等，将原始语音连同两路翻译的语音作为声道1到声道3的输入音源，打包生成多声道编码包作为一路音频码流发送给MCU。

(2)MCU将各终端发送的多声道编码包进行解包解码处理，根据解码后得到的声道语言类型，送入多声道混音器处理，得到多声道混音音频流，进行编码打包得到多声道混音编码包，具体实现方式见图8(a)。最后将多声道混音编码包发送到各终端。本实施例中，MCU的混音处理可以快速实现，仅需一个混音器完成多声道混音。

(3)各终端接收MCU发送的多声道混音编码包，进行解码拆分成三个声道的语音，分别解码成线性码流，终端侧按需收听会议混音。

由于MCU发送给某会场的终端的多声道混音编码包涵盖了各个会场支持的语言类型，因此，会议中的中文终端、英文终端、法文终端可以通过选择不同声道，直接收听或者播放会议的语音。该应用场景下每个终端都可以从多个不同的语种中自由选择收听的语种。

图15为本发明第五实施例提供的会议电视应用场景示意图。本实施例结合具体的应用场景对支持多语会议电视的方法实施例的技术方案进行详细说明。

本实施例与第四实施例的区别在于，会议中的会场语言类型为五种，分别为中、英、德、日、法。在会议召开的信令交互阶段，德日法混合会场具有与中文，英文互译的能力，但是其他会场不具备德日法文的翻译能力，因此，多语会议支持的语言类型为中英两种。德日法会场在参加会议交流的时候，首先将会场的声音翻译成中文以及英文，作为声道1以及声道2的音源输入，如图15所示。中文会场发送的语音分别为原始语音中文以及经原始语音翻译后的英文语音，英文会场发送的语音分别为经原始语音翻译后的中文以及原始语音英文。中英文混合会场将原始中英文混合语音分别翻译成中文语音以及英文语音，德日法文混合会场同理，将德日法混合语音分别翻译成中文语音以及英文语音。

(1)各会场的终端获取自身所在会场的原始语音以及多语会议支持的语言类型，确定翻译的种类，如英译汉或者汉译英或者其他等。将输出的两种语言类型的语音作为左右声道的音源，进行编码得到多声道编码包作为一路音频码流发送给MCU。

(2)MCU将各终端发送的多声道编码包进行混音处理，得到多声道混音音频流，并将多声道混音音频流进行编码打包后发送到各终端。MCU的混音处理可以快速实现，仅需一个混音器完成多语混音。

(3)各终端接收MCU发送的多声道混音编码包，进行解码，拆分左右两路，按照需求分别收听多语语音。

如果MCU发送给某会场的终端的混音编码包中的混音音频流与该会场支持的语言类型相同，如中文与英文多语会议中的中文会场接收到的多语音频为中文以及英文，会议中的中文终端、英文终端、中英文终端可以通过选择不同声道，直接收听或者播放会议的语音。

对于接收到的混音编码包中的语言类型与会场的语言类型不一致的终端，则可以根据具体的需求进行翻译转换，如德日法会场需要对接收到的中文混音或者英文混音进行翻译转换，然后再进行播放。

本实施例中每个会场都具有翻译功能，能够对会场的原始语音进行翻译后输出。MCU将终端输出的多语语音进行混音处理后，仅需一个混音器，仅需一个处理流程，混音前无需新增语音识别模块，可以通过帧类型信息进行语言类型识别。会议中的各个会场的参会人员使用的交流语言可以为一种，也可以为多种，均可无障碍进行会议沟通，方案易于实现，具有很高的实用性。

本发明一实施例提供一种会议实现装置，如图16所示，包括：

码流生成单元1601，设置为，获取所在会场的原始语音以及所述原始语音对应的翻译语音，生成多声道音频流，且一个声道对应一种语言类型的音频流；

第一编码单元1602，设置为，将所述多声道音频流进行编码获得多声道编码包；

第一发送单元1603，设置为，将所述多声道编码包发送给多点控制单元。

所述会议实现装置还包括：语言类型确定单元1604，所述语言类型确定单元1604设置为，确定会议支持的语言类型。比如，所述语言类型确定单元1604从所述多点控制单元获取所述会议支持的语言类型。

所述码流生成单元1601生成的所述多声道音频流中包括所述会议支持的每个语言类型的音频流。

在一实施例中，所述码流生成单元获取所在会场的原始语音以及所述原始语音对应的翻译语音，生成多声道音频流，包括如下之一或其组合：

当所述原始语音的语言类型为所述会议支持的语言类型之一时，将所述原始语音对应的音频流作为一个声道的音频流，将所述原始语音对应的所述会议支持的除所述原始语音的语言类型外的其他语言类型的翻译语音作为其他声道的音频流，生成所述多声道音频流；

当所述原始语音的语言类型非所述会议支持的语言类型时，将所述原始语音对应的所述会议支持的每个语言类型的翻译语音分别作为一个声道的音频流，生成所述多声道音频流。

本发明一实施例提供一种会议实现装置，如图17所示，包括：

第一接收单元1701，设置为，接收多点控制单元发送的多声道混音编码包；

第一解析单元1702，设置为，解析所述多声道混音编码包，获取多声道混音音频流。

在一实施例中，所述第一解析单元1702还设置为，根据所述多声道混音编码包中携带的语言类型信息确定各声道的音频流所使用的语言类型，或者，根据预设的声道与语言类型的对应关系确定每个声道对应的语言类型。

在一实施例中，所述第一解析单元1702获取每个声道的编码数据包括：

所述第一解析单元1702从所述多声道编码包中的实时传输协议头扩展中的帧类型字段获取每个声道的音频流所使用的语言类型信息，从所述实时传输协议头扩展中的帧长度字段获取每个声道的编码数据的长度，根据每个声道的编码数据的长度从所述多声道编码包的实时传输协议负载中获取每个声道的编码数据。

本发明一实施例提供一种会议实现装置，如图18所示，包括：

第二接收单元1801，设置为，接收参与会议的终端发送的多声道编码包；

第二解析单元1802，设置为，对所述多声道编码包进行解析获得多声道音频流，其中，所述多声道音频流中每个声道对应一个语言类型的音频流；

混音单元1803，设置为，确定需要混音的终端，将所确定的终端的多声道音频流中同一语言类型的音频流进行混音，获得多声道混音音频流；且一个声道对应一种语言类型的混音音频流；

第二编码单元1804，设置为，将所述多声道混音音频流进行编码获得多声道混音编码包；

第二发送单元1805，设置为，将所述多声道混音编码包发送给参与会议的终端。

本发明一实施例提供一种会议实现设备，包括存储器和处理器，所述存储器存储有程序，所述程序在被所述处理器读取执行时，实现上述任一所述的会议实现方法。

本发明一实施例一种计算机可读存储介质，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现上述任一所述的会议实现方法。

所述计算机可读存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

本发明一实施例提供一种会议实现系统，如图19所示，包括：MCU1901和至少一个终端1902，其中：

所述终端1902设置为，获取所述终端所在会场的原始语音以及所述原始语音对应的翻译语音，生成多声道音频流，且一个声道对应一种语言类型的音频流；将所述多声道音频流进行编码获得多声道编码包；将所述多声道编码包发送给所述多点控制单元，以及，接收多点控制单元发送的多声道混音编码包；解析所述多声道混音编码包，获取多声道混音音频流；

所述MCU1901设置为，接收参与会议的终端发送的多声道编码包，进行解析获得多声道音频流，其中，所述多声道音频流中每个声道对应一个语言类型的音频流；确定需要混音的终端，将所确定的终端的多声道音频流中同一语言类型的音频流进行混音，获得多声道混音音频流；将所述多声道混音音频流进行编码获得多声道混音编码包；将所述多声道混音编码包发送给参与会议的终端。

终端和MCU的详细实现请参考前面的实施例，此处不再赘述。

虽然本发明所揭露的实施方式如上，但所述的内容仅为便于理解本发明而采用的实施方式，并非用以限定本发明。任何本发明所属领域内的技术人员，在不脱离本发明所揭露的精神和范围的前提下，可以在实施的形式及细节上进行任何的修改与变化，但本发明的专利保护范围，仍须以所附的权利要求书所界定的范围为准。

Claims

1.一种会议实现方法，包括：

将所述多声道音频流进行编码获得多声道编码包；

将所述多声道编码包发送给多点控制单元。

2.如权利要求1所述的会议实现方法，其特征在于，所述方法还包括：确定会议支持的语言类型；

所述多声道音频流中包括所述会议支持的每个语言类型的音频流。

3.如权利要求2所述的会议实现方法，其特征在于，所述确定会议支持的语言类型包括：

从所述多点控制单元获取所述会议支持的语言类型。

4.如权利要求2所述的会议实现方法，其特征在于，所述获取终端所在会场的原始语音以及所述原始语音对应的翻译语音，生成多声道音频流，包括如下之一或其组合：

5.如权利要求1至4任一所述的会议实现方法，其特征在于，所述多声道编码包中每个声道对应预设语言类型的音频流；或者，所述多声道编码包中携带每个声道的语言类型信息。

6.如权利要求1至4任一所述的会议实现方法，其特征在于，所述多声道编码包为实时传输协议报文，所述多声道编码包中包括实时传输协议头、实时传输协议头扩展和实时传输协议负载，所述实时传输协议头扩展中包括长度字段和一个或多个帧信息字段，所述长度字段中携带所述帧信息字段的个数，所述帧信息字段包括帧类型字段和帧长度字段，所述帧类型字段携带一个声道的语言类型，所述帧长度字段携带该声道的编码数据长度，所述实时传输协议负载携带每个声道的编码数据。

7.一种会议实现装置，其特征在于，包括：

8.一种会议实现方法，包括：

将所述多声道混音音频流进行编码获得多声道混音编码包；

将所述多声道混音编码包发送给参与会议的终端。

9.如权利要求8所述的会议实现方法，其特征在于，所述方法还包括：

所述多声道混音编码包中携带语言类型信息，指示每个声道的混音音频流所使用的语言类型；或者，所述多声道混音编码包中每个声道对应预设语言类型的混音音频流。

10.如权利要求8所述的会议实现方法，其特征在于，所述多声道混音编码包为实时传输协议报文，所述多声道混音编码包中包括实时传输协议头、实时传输协议头扩展和实时传输协议负载，所述实时传输协议头扩展中包括长度字段和一个或多个帧信息字段，所述长度字段指示所述帧信息字段的个数，所述帧信息字段包括帧类型字段和帧长度字段，所述帧类型字段携带一个声道的语言类型，所述帧长度字段携带该声道的编码数据长度，所述实时传输协议负载携带每个声道的编码数据。

11.如权利要求8至10任一所述的会议实现方法，其特征在于，所述方法还包括：确定会议支持的语言类型，将所述会议支持的语言类型发送给参与会议的终端。

12.如权利要求11所述的会议实现方法，其特征在于，所述确定会议支持的语言类型包括以下至少之一：

当会场的优先级最高时，将该会场的发言语种作为会议支持的一种语言类型；

当会场的发言语种为会议中所有会场中使用最多的语言类型时，将该会场的发言语种作为会议支持的一种语言类型；

当会场的发言语种与其他会场具备互译能力时，将该会场的发言语种作为会议支持的一种语言类型。

13.如权利要求11所述的会议实现方法，其特征在于，所述多声道混音音频流中包括所述会议支持的每个语言类型的混音音频流。

14.一种会议实现装置，其特征在于，包括：

15.一种会议实现方法，包括：

接收多点控制单元发送的多声道混音编码包；

解析所述多声道混音编码包，获取多声道混音音频流。

16.如权利要求15所述的会议实现方法，其特征在于，所述方法还包括：根据所述多声道混音编码包中携带的语言类型信息确定每个声道的语言类型，或者，根据预设的声道与语言类型的对应关系确定每个声道对应的语言类型。

17.如权利要求15或16所述的会议实现方法，其特征在于，所述解析所述多声道混音编码包，获取多声道混音音频流包括：

所述多声道编码包为实时传输协议报文时，从所述多声道编码包中的实时传输协议头扩展中的帧类型字段获取每个声道的音频流所使用的语言类型信息，从所述实时传输协议头扩展中的帧长度字段获取每个声道的编码数据的长度，根据每个声道的编码数据的长度从所述多声道编码包的实时传输协议负载中获取每个声道的编码数据，对每个声道的编码数据进行解码获得该声道的混音音频流。

18.一种会议实现装置，其特征在于，包括：

19.一种会议实现设备，其特征在于，包括存储器和处理器，所述存储器存储有程序，所述程序在被所述处理器读取执行时，实现如权利要求1至6、15至17任一所述的会议实现方法。

20.一种会议实现设备，其特征在于，包括存储器和处理器，所述存储器存储有程序，所述程序在被所述处理器读取执行时，实现如权利要求8至13任一所述的会议实现方法。

21.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现如权利要求1至6、8至13、15至17任一所述的会议实现方法。

22.一种会议实现系统，其特征在于，包括：多点控制单元和至少一个终端，其中：