CN112203038B

CN112203038B - 在线会议的处理方法、装置、电子设备及计算机存储介质

Info

Publication number: CN112203038B
Application number: CN202011085673.3A
Authority: CN
Inventors: 徐斌
Original assignee: Beijing ByteDance Network Technology Co Ltd
Current assignee: Douyin Vision Co Ltd; Douyin Vision Beijing Co Ltd
Priority date: 2020-10-12
Filing date: 2020-10-12
Publication date: 2022-09-16
Anticipated expiration: 2040-10-12
Also published as: CN112203038A

Abstract

本公开提供了一种在线会议的处理方法、装置、电子设备及计算机可读存储介质，涉及在线会议领域。该方法包括：基于预设的订阅信息、音频流数据集中的至少一种，从所述在线会议的多个参与方中确定出至少一个目标参与方；基于所述至少一个目标参与方的订阅信息获取各个目标参与方各自对应的视频流数据，并从所述音频流数据集中获取各个目标参与方各自对应的音频流数据；展示各个目标参与方各自对应的视频流数据，以及播放各个目标参与方各自对应的音频流数据。本公开大大减少了在线会议时数据传输时占用的带宽；同时，也大大减少了终端处理数据时的硬件资源消耗。

Description

在线会议的处理方法、装置、电子设备及计算机存储介质

技术领域

本公开涉及在线会议技术领域，具体而言，本公开涉及一种在线会议的处理方法、装置、电子设备及计算机可读存储介质。

背景技术

市面上的视频会议解决方案往往只能支撑到百人会议，主要原因是一场视频会议人数越多，所需要的网络带宽也就越大，接入设备所需要计算能力和内存也就越多。

视频会议所消耗的网络带宽：对于N个人参与的视频会议，如果每个与会者会发送两路数据流：音频流和视频流。每个与会者发送的码流是B kbps，则每个人接收的码流是(N-1)*B kbps，视频会议的服务器转发两路数据流所需要的带宽是(N-1)*(N-1)*B kbps。

比如，对于100人会议，假设每个客户端的码流是500kbps，则服务器需要约5Gbps的带宽来转发两路数据流，而每个客户端需要50Mbps的带宽。因此，服务器所需要的带宽成本非常高，客户端所需要的带宽要求也非常高。而对于万人会议，这种方案几乎不可能支撑得住。而且，如果客户端每处理一路数据流需要的内存是50M，那么针对百人会议，每个客户端需要约5G内存，会超出很多客户端的处理能力。

发明内容

提供该发明内容部分以便以简要的形式介绍构思，这些构思将在后面的具体实施方式部分被详细描述。该发明内容部分并不旨在标识要求保护的技术方案的关键特征或必要特征，也不旨在用于限制所要求的保护的技术方案的范围。

本公开提供了一种在线会议的处理方法、装置、电子设备及计算机可读存储介质，可以解决现有视频会议消耗过多网络资源和硬件资源的问题。所述技术方案如下：

第一方面，提供了一种在线会议的处理方法，该方法包括：

基于预设的订阅信息、音频流数据集中的至少一种，从所述在线会议的多个参与方中确定出至少一个目标参与方；

基于所述至少一个目标参与方的订阅信息获取各个目标参与方各自对应的视频流数据，并从所述音频流数据集中获取各个目标参与方各自对应的音频流数据；

展示各个目标参与方各自对应的视频流数据，以及播放各个目标参与方各自对应的音频流数据。

第二方面，提供了一种在线会议的处理装置，该装置包括：

确定模块，用于基于预设的订阅信息、音频流数据集中的至少一种，从所述在线会议的多个参与方中确定出至少一个目标参与方；

获取模块，用于基于所述至少一个目标参与方的订阅信息获取各个目标参与方各自对应的视频流数据，并从所述音频流数据集中获取各个目标参与方各自对应的音频流数据；

展示模块，用于展示各个目标参与方各自对应的视频流数据，以及播放各个目标参与方各自对应的音频流数据。

第三方面，提供了一种电子设备，该电子设备包括：

处理器、存储器和总线；

所述总线，用于连接所述处理器和所述存储器；

所述存储器，用于存储操作指令；

所述处理器，用于通过调用所述操作指令，可执行指令使处理器执行如本公开的第一方面所示的在线会议的处理方法对应的操作。

第四方面，提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现本公开第一方面所示的在线会议的处理方法。

本公开提供的技术方案带来的有益效果是：

基于预设的订阅信息、音频流数据集中的至少一种，从所述在线会议的多个参与方中确定出至少一个目标参与方，再基于所述至少一个目标参与方的订阅信息获取各个目标参与方各自对应的视频流数据，并从所述音频流数据集中获取各个目标参与方各自对应的音频流数据，然后展示各个目标参与方各自对应的视频流数据，以及播放各个目标参与方各自对应的音频流数据即可。通过上述方式，使得在进行在线会议时，既可以通过订阅的方式确定出需要展示的目标参与方，也可以通过在线会议每个参与方的音频流数据确定出目标参与方，还可以通过二者结合的方式确定出目标参与方，这样，当前参与方对应的终端就不需要从服务器获取每个参与方的视频流数据和音频流数据，而是有针对性的获取目标参与方的视频流数据和音频流数据，从而大大减少了数据传输时占用的带宽；同时，由于终端不需要处理每个参与方的视频流数据和音频流数据，而是处理目标参与方的视频流数据和音频流数据即可，所以，也大大减少了终端处理数据时的硬件资源消耗。

附图说明

结合附图并参考以下具体实施方式，本公开各实施例的上述和其他特征、优点及方面将变得更加明显。贯穿附图中，相同或相似的附图标记表示相同或相似的元素。应当理解附图是示意性的，原件和元素不一定按照比例绘制。

图1为本公开执行一种在线会议的处理方法的应用环境示意图；

图2为本公开一个实施例提供的一种在线会议的处理方法的流程示意图；

图3为本公开另一实施例提供的一种在线会议的处理方法的流程示意图；

图4为本公开又一实施例提供的一种在线会议的处理方法的流程示意图；

图5为本公开另一实施例提供的一种在线会议的处理方法的流程示意图；

图6为本公开又一实施提供的音频处理架构示意图；

图7为本公开又一实施提供的视频处理架构示意图；

图8为本公开又一实施例提供的一种在线会议的处理装置的结构示意图；

图9为本公开又一实施例提供的一种在线会议的处理的电子设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。

应当理解，本公开的方法实施方式中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。此外，方法实施方式可以包括附加的步骤和/或省略执行示出的步骤。本公开的范围在此方面不受限制。

本文使用的术语“包括”及其变形是开放性包括，即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”；术语“一些实施例”表示“至少一些实施例”。其他术语的相关定义将在下文描述中给出。

需要注意，本公开中提及的“第一”、“第二”等概念仅用于对不同的装置、模块或单元进行区分，并非用于限定这些装置、模块或单元一定为不同的装置、模块或单元，也并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。

需要注意，本公开中提及的“一个”、“多个”的修饰是示意性而非限制性的，本领域技术人员应当理解，除非在上下文另有明确指出，否则应该理解为“一个或多个”。

本公开实施方式中的多个装置之间所交互的消息或者信息的名称仅用于说明性的目的，而并不是用于对这些消息或信息的范围进行限制。

为使本公开的目的、技术方案和优点更加清楚，下面将结合附图对本公开实施方式作进一步地详细描述。

本公开提供的在线会议的处理方法、装置、电子设备和计算机可读存储介质，旨在解决现有技术的如上技术问题。

下面以具体地实施例对本公开的技术方案以及本公开的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本公开的实施例进行描述。

本公开实施例提供了一种在线会议的处理方法的应用环境，参见图1，该应用环境包括：第一设备101和第二设备102。第一设备101和第二设备102之间通过网络连接，第一设备101为访问设备，第二设备102为被访问设备。第一设备101可以为终端，第二设备102可以为服务器。终端可以为智能电视、智能平板或者电脑终端等任一终端，该终端可以具有如下特点：

(1)在硬件体系上，设备具备中央处理器、存储器、输入部件和输出部件，也就是说，设备往往是具备通信功能的微型计算机设备。另外，还可以具有多种输入方式，诸如键盘、鼠标、触摸屏、送话器和摄像头等，并可以根据需要进行调整输入。同时，设备往往具有多种输出方式，如受话器、显示屏等，也可以根据需要进行调整；

(2)在软件体系上，设备必须具备操作系统，如Windows Mobile、Symbian、Palm、Android、iOS等。同时，这些操作系统越来越开放，基于这些开放的操作系统平台开发的个性化应用程序层出不穷，如通信簿、日程表、记事本、计算器以及各类游戏等，极大程度地满足了个性化用户的需求；

(3)在通信能力上，设备具有灵活的接入方式和高带宽通信性能，并且能根据所选择的业务和所处的环境，自动调整所选的通信方式，从而方便用户使用。设备可以支持GSM(Global System for Mobile Communication，全球移动通信系统)、WCDMA(Wideband CodeDivision Multiple Access，宽带码分多址)、CDMA2000(Code Division MultipleAccess，码分多址)、TDSCDMA(Time Division-Synchronous Code Division MultipleAccess，时分同步码分多址)、Wi-Fi(Wireless-Fidelity，无线保真)以及WiMAX(WorldwideInteroperability for Microwave Access，全球微波互联接入)等，从而适应多种制式网络，不仅支持语音业务，更支持多种无线数据业务；

(4)在功能使用上，设备更加注重人性化、个性化和多功能化。随着计算机技术的发展，设备从“以设备为中心”的模式进入“以人为中心”的模式，集成了嵌入式计算、控制技术、人工智能技术以及生物认证技术等，充分体现了以人为本的宗旨。由于软件技术的发展，设备可以根据个人需求调整设置，更加个性化。同时，设备本身集成了众多软件和硬件，功能也越来越强大。

进一步，该终端中可以安装在线会议的应用程序客户端，包括但不限于语音会议、视频会议。服务器可以用于为应用程序客户端提供服务，服务器的可以是一台，也可以是由多台组成的服务器集群。

在上述应用环境中可以执行一种在线会议的处理方法，如图2所示，该方法包括：

步骤S201，基于预设的订阅信息、音频流数据集中的至少一种，从在线会议的多个参与方中确定出至少一个目标参与方；

在本公开实施例中，在线会议的包括至少两个参与方。其中，订阅可以是当前参与方从服务器获取目标参与方的视频流数据，目标参与方可以通过订阅信息确定；目标参与方可以包括当前参与方，也可以不包括当前参与方；订阅信息可以被订阅的参与方的相关信息，相关信息包括但不限于被订阅的参与方的标识信息、网络地址信息。

相应地，取消订阅可以是当前参与方不再在对应的终端中展示目标参与方的视频流数据，且不再从服务器获取目标参与方的视频流数据。取消订阅指令可以是被取消订阅的参与方的相关信息。

在实际应用中，订阅的方式可以是参与方手动订阅；也可以是应用程序客户端自动订阅。当然，还可以通过其它方式进行订阅，在实际应用中可以根据实际需求进行设置，本公开实施例对此不作限制。

订阅之后即可确定出被订阅的参与方的相关信息，也就是订阅信息，然后基于订阅信息确定出至少一个目标参与方，也就是被订阅的参与方。

进一步，音频流数据集为除当前参与方之外的其它参与方各自对应的音频流数据。具体地，在进行在线会议时，当前参与方对应的终端可以接收音频流数据集，该音频流数据集包括除当前参与方之外的其它所有参与方的音频流数据。然后基于各个音频流数据确定出至少一个目标参与方。

在实际应用中，可以通过订阅信息和音频流数据集中的至少一种确定出至少一个目标参与方，可以根据实际需求进行调整，本公开实施例对此不作限制。

步骤S202，基于至少一个目标参与方的订阅信息获取各个目标参与方各自对应的视频流数据，并从音频流数据集中获取各个目标参与方各自对应的音频流数据；

确定出至少一个目标参与方后，基于订阅信息从服务器获取各个目标参与方各自对应的视频流数据，同时，从音频流数据集中获取各个目标参与方各自对应的音频流数据。

步骤S203，展示各个目标参与方各自对应的视频流数据，以及播放各个目标参与方各自对应的音频流数据。

获取到各个目标参与方各自对应的音频流数据和视频流数据之后，在终端中展示各个目标参与方各自对应的视频流数据、播放各个目标参与方各自对应的音频流数据即可。

在本公开实施例中，基于预设的订阅信息、音频流数据集中的至少一种，从在线会议的多个参与方中确定出至少一个目标参与方，再基于至少一个目标参与方的订阅信息获取各个目标参与方各自对应的视频流数据，并从音频流数据集中获取各个目标参与方各自对应的音频流数据，然后展示各个目标参与方各自对应的视频流数据，以及播放各个目标参与方各自对应的音频流数据即可。通过上述方式，使得在进行在线会议时，既可以通过订阅的方式确定出需要展示的目标参与方，也可以通过在线会议每个参与方的音频流数据确定出目标参与方，还可以通过二者结合的方式确定出目标参与方，这样，当前参与方对应的终端就不需要从服务器获取每个参与方的视频流数据和音频流数据，而是有针对性的获取目标参与方的视频流数据和音频流数据，从而大大减少了数据传输时占用的带宽；同时，由于终端不需要处理每个参与方的视频流数据和音频流数据，而是处理目标参与方的视频流数据和音频流数据即可，所以，也大大减少了终端处理数据时的硬件资源消耗。

在另一个实施例中提供了一种在线会议的处理方法，如图3所示，该方法包括：

步骤S301，基于预设的订阅信息、音频流数据集中的至少一种，从在线会议的多个参与方中确定出至少一个目标参与方；

在本公开实施例中，在线会议的包括至少两个参与方。其中，订阅可以是当前参与方从服务器获取目标参与方的视频流数据，目标参与方可以通过订阅信息确定；目标参与方可以包括当前参与方，也可以不包括当前参与方；订阅信息可以被订阅的参与方的相关信息，相关信息包括但不限于被订阅的参与方的标识信息、网络地址信息。比如，某个在线会议包括三个参与方：A、B、C，A订阅了B和C，那么B和C的相关信息可以作为订阅信息，然后A对应的终端从服务器获取B和C的视频流数据，并在该终端中进行展示。

相应地，取消订阅可以是当前参与方不再在对应的终端中展示目标参与方的视频流数据，且不再从服务器获取目标参与方的视频流数据。取消订阅指令可以是被取消订阅的参与方的相关信息。比如，接上例，当A取消订阅了B，那么B的相关信息作为取消订阅指令，并不再在A对应的终端中展示B。

在实际应用中，订阅的方式可以是参与方手动订阅，比如参与方A手动订阅了B和C；也可以是应用程序客户端自动订阅，比如，按照进入在线会议的先后顺序来自动订阅。当然，还可以通过其它方式进行订阅，在实际应用中可以根据实际需求进行设置，本公开实施例对此不作限制。

在本公开一种优选实施例中，基于预设的订阅信息、音频流数据集中的至少一种，从在线会议的多个参与方中确定出至少一个目标参与方，包括：

当接收到针对多个参与方中至少一个参与方的选择指令，且未接收到音频流数据集时，将至少一个参与方作为候选参与方；

当接收到针对候选参与方的确认指令时，将候选参与方确定为目标参与方。

具体而言，当前参与方可以在应用程序客户端中查看当前在线会议的所有参与方，比如，在线会议的应用程序客户端可以具有预设的参与方列表，该参与方列表包括当前参加在线会议的所有参与方。

然后从所有参与方中选择至少一个参与方，也就是发起针对多个参与方中至少一个参与方的选择指令，应用程序客户端接收到选择指令时，如果没有接收到音频流数据集，那么就可以将选择出的至少一个参与方作为候选参与方，然后展示用于确认的交互按钮。

当当前参与方点击该交互按钮，即发起了针对候选参与方的确认指令，应用程序客户端接收到确认指令后，确定出候选参与方的相关信息作为订阅信息，并将订阅信息对应的参与方作为目标参与方。

需要说明的是，当前参与方可以一次选择一个参与方作为候选参与方，也可以一次选择多个参与方作为候选参与方，在实际应用中可以根据实际需求进行设置，本公开实施例对此不作限制。

进一步，应用程序客户端也可以自动订阅。具体地，应用程序客户端按照进入在线会方的先后顺序确定出至少一个目标参与方。

当接收到音频流数据集且未接收到订阅信息时，基于预设规则对音频流数据集中的音频流数据进行过滤，得到至少一个过滤后的音频流数据；

对至少一个过滤后的音频流数据进行排序，并将排序靠前的预设数量的音频流数据对应的参与方作为目标参与方。

具体而言，在进行在线会议时，如果接收到了音频流数据集且没有接收到订阅信息(比如当前参与方没有手动订阅，也没有在应用程序客户端中设置自动订阅)时，可以基于预设的过滤规则对音频流数据集中的各个音频流数据进行过滤，从而得到至少一个过滤后的音频流数据，然后基于预设的排序规则对各个过滤后的音频流数据进行排序，并将排序靠前的预设数量的音频流数据对应的参与方作为目标参与方。

其中，基于预设规则对音频流数据集中的音频流数据进行过滤，得到至少一个过滤后的音频流数据，包括：

对音频流数据集中的各个音频流数据分别进行解析，得到各个音频流数据各自对应的音频状态和音频能量参数；音频状态包括静音状态和非静音状态；

将音频状态为非静音状态的音频流数据丢弃，得到至少一个过滤后的音频流数据；

对至少一个过滤后的音频流数据进行排序，包括：

基于各个剩余的音频流数据各自对应的音频能量参数分别计算出各个过滤后的音频流数据各自对应的音频能量；

基于各个音频能量对至少一个过滤后的音频流数据进行排序。

具体而言，当前参与方对应的应用程序客户端对各个音频流数据分别进行解析，得到各个音频流数据各自对应的音频状态和音频能量参数，其中，音频状态包括静音状态和非静音状态。

针对任一音频流数据，如果其音频状态为静音状态，那么就可以丢弃该任一音频流数据。依此类推，从而得到至少一个过滤后的音频流数据(比如，当前只有一个参与方正在发言，那么就得到一个过滤后的音频流数据)。

然后基于各个过滤的音频流数据各自对应的音频能量参数计算出各自对应的当前音频能量。具体地，可以采用一阶平滑迭代计算每个音频流数据中的音频能量，如下公式所示：

smoothed_RMS(i)＝RMS*(1-coef)+smoothed_RMS(i-1)*coef；

其中，smoothed_RMS为当前音频能量；RMS为音频能量参数；coef为平滑系数，可以自行取值，比如取0.9；当i＝1时，smoothed_RMS(1)＝RMS。

计算得到各个音频流数据各自对应的当前音频能量后，基于音频能量的大到小进行排序，即可得到排序后的音频流数据。

在实际应用中，终端的屏幕中可以同时展示预设数量的目标参与方的视频流数据，比如，在终端中同时展示4个目标参与方的视频流数据。所以，当排序后的音频流数据的数量超过预设数量时，保留排序靠前的预设数量的音频流数据即可。当然，在实际应用中，预设数量可以根据实际需求进行设置，本公开实施例对此不作限制。

当接收到音频流数据集时，基于音频流数据集确定出至少一个第一参与方；

当至少一个第一参与方的数量不超过预设数量时，基于至少一个第一参与方的数量和预设数量计算得到数量差值；

当接收到订阅信息时，基于数量差值和订阅信息确定出至少一个第二参与方；至少一个第一参与方与至少一个第二参与方不存在任一相同的参与方；

将第一目标参与方和第二目标参与方作为最终的目标参与方；

当至少一个第一参与方的数量超过预设数量时，对至少一个第一参与方进行排序，并将排序靠前的预设数量的参与方作为最终的目标参与方。

具体而言，当接收到了订阅信息，同时也接收到了音频流数据集时，先基于音频流数据集确定出至少一个第一参与方；其中，确定的方式可参照上述基于音频流数据集确定出至少一个目标参与方，在此就不赘述了。

然后判断第一参与方的数量是否超过预设数量，如果否，则计算出第一参与方的数量与预设数量的数量差值，再基于接收到的订阅信息确定数量差值的第二参与方，然后将第一参与方和第二参与方一起作为最终的目标参与方。其中，第一参与方与第二参与方不存在任一相同的参与方，也就是说，二者是没有重叠的。

如果第一参与方的数量超过了预设数量，那么就基于各个第一参与方各自对应的音频能量对各个第一参与方进行排序，然后将音频能量大的前预设数量的参与方作为最终的目标参与方。

进一步，如果第一参与方的数量没有超过预设数量，而且当前参与方也没有手动订阅，那么可以基于自动订阅确定出第二参与方。

需要说明的是，因为在进行在线会议时，如果当前有参与方正在发言，那么就会默认将发言的参与方作为目标参与方，所以，在本公开中，基于音频流数据集确定出的参与方的优先级高于基于订阅信息确定出的参与方。

进一步，参与方在订阅时可以单个订阅，也可以批量订阅。比如，终端的当前页面中展示多个目标参与方，当参与方对当前页面进行滑动操作跳转到下一页面时，就是对当前页面中的多个目标参与方同时取消订阅，同时对下一页面中的多个参与方进行订阅。例如，终端的当前页面中展示A、B、C、D四个目标参与方，当参与方对当前页面进行滑动操作时，跳转到下一页面，下一页面包括D、E、F、G四个参与方，那么滑动操作完成时，参与方就对A、B、C、D四个参与方取消订阅，同时重新批量订阅D、E、F、G四个参与方。

步骤S302，基于至少一个目标参与方的订阅信息获取各个目标参与方各自对应的视频流数据，并从音频流数据集中获取各个目标参与方各自对应的音频流数据；

具体而言，确定出至少一个目标参与方后，基于订阅信息从服务器获取各个目标参与方各自对应的视频流数据，同时，从音频流数据集中获取各个目标参与方各自对应的音频流数据。

步骤S303，展示各个目标参与方各自对应音频流数据和视频流数据；

步骤S304，当接收到针对各个目标参与方中至少一个目标参与方的取消订阅指令时，停止展示取消订阅的至少一个目标参与方各自对应的视频流数据，以及停止播放至少一个目标参与方各自对应的音频流数据。

具体而言，当当前参与方对各个目标参与方中至少一个目标参与方取消订阅时，即发起了取消订阅指令，应用程序客户端接收到取消订阅指令时，停止展示取消订阅的各个目标参与方各自对应的音频流数据和视频流数据，同时，停止从服务器获取取消订阅的各个目标参与方各自对应的视频流数据，以及停止播放各个目标参与方各自对应的音频流数据。

进一步，由于基于音频流数据确定出的参与方的优先级高于基于订阅信息确定出的参与方，所以，在展示参与方时，可以将当前正在发言的参与方自动进行优先展示，实用性更高；同时，当前参与方可以通过订阅和取消订阅的方式来选择需要在终端中进行展示的参与方，灵活性更高。

在另一个实施例中提供了一种在线会议的处理方法，如图4所示，该方法包括：

步骤S401，基于预设的订阅信息、音频流数据集中的至少一种，从在线会议的多个参与方中确定出至少一个目标参与方；

步骤S402，基于至少一个目标参与方的订阅信息获取各个目标参与方各自对应的视频流数据，并从音频流数据集中获取各个目标参与方各自对应的音频流数据；

步骤S403，展示各个目标参与方各自对应的视频流数据，以及播放各个目标参与方各自对应的音频流数据；

其中，步骤S401～步骤S403具体可参照步骤S301～步骤S303，在此就不赘述了。

步骤S404，实时采集当前参与方的音频数据；

在实际应用中，在进行在线会议时，当前参与方对应的终端除了可以获取目标参与方的音频流数据和视频流数据，还可以实时采集当前参与方的音频数据。当然，除了实时采集音频数据之外，还可以每隔预设的时间间隔采集，比如每隔3秒采集一次。

步骤S405，当检测到音频数据中不存在人声时，将音频数据的音频状态标记为静音状态，并计算音频数据的第一音频能量；

采集到音频数据之后，检测该音频数据中是否存在人声，如果不存在，则将该音频数据的音频状态标记为静音状态，并计算得到该音频数据的第一音频能量。由于并不存在人声，所以第一音频能量可以为0。

步骤S406，基于音频数据、静音状态和第一音频能量生成第一音频流数据，并将第一音频流数据发送至预设服务器；

标记完成和计算完成之后，就可以将音频数据、静音状态以及第一音频能量封装，得到第一音频流数据，并将该第一音频流数据发送至预设服务器。

步骤S407，当检测到音频数据中存在人声时，检测人声是否超过人声阈值；

如果检测到音频数据中存在人声时，进一步检测人声是否超过了预设的人声阈值。

步骤S408，若是，则将音频数据的音频状态标记为非静音状态，并计算音频数据的第二音频能量；

如果人声超过了预设的人声阈值，则将音频数据的音频状态标记为非静音状态，同时计算得到音频数据的第二音频能量。

步骤S409，基于音频数据、非静音状态和第二音频能量生成第二音频流数据，并将第二音频流数据发送至预设服务器；

标记完成和计算完成之后，就可以将音频数据、非静音状态以及第二音频能量封装，得到第二音频流数据，并将该第二音频流数据发送至预设服务器。

步骤S4010，若否，则将音频数据的音频状态标记为静音状态，并计算音频数据的第三音频能量；

如果人声没有超过预设的人声阈值，则将音频数据的音频状态标记为静音状态，同时计算得到音频数据的第三音频能量。

步骤S4011，基于音频数据、静音状态和第三音频能量生成第三音频流数据，并将第三音频流数据发送至预设服务器。

标记完成和计算完成之后，就可以将音频数据、非静音状态以及第三音频能量封装，得到第三音频流数据，并将该第三音频流数据发送至预设服务器。

需要说明的是，终端在采集当前参与方的音频数据的同时，也会同时采集图像数据。然后基于音频数据生成音频流数据，以及基于图像数据生成视频流数据，再将音频流数据和视频流数据同时发送至预设服务器，预设服务器将音频流数据发送至其它参与方，以使得其它参与方基于该音频流数据确定出目标参与方，确定的具体方式可参照步骤S301～步骤S303，在此就不赘述了。

进一步，当前参与方对应的终端在获取目标参与方的视频流数据和音频流数据的同时，也会采集当前参与方的音频数据和图像数据。然后基于音频数据生成音频流数据，以及基于图像数据生成视频流数据，再将音频流数据和视频流数据同时发送至预设服务器，预设服务器将音频流数据发送至其它参与方，以使得其它参与方基于该音频流数据确定出目标参与方。

在另一个实施例中提供了一种在线会议的处理方法，如图5所示，该方法包括：

步骤S501，基于预设的订阅信息、音频流数据集中的至少一种，从在线会议的多个参与方中确定出至少一个目标参与方；

步骤S502，基于至少一个目标参与方的订阅信息获取各个目标参与方各自对应的视频流数据，并从音频流数据集中获取各个目标参与方各自对应的音频流数据；

步骤S503，展示各个目标参与方各自对应的视频流数据，以及播放各个目标参与方各自对应的音频流数据；

步骤S504，当接收到针对各个目标参与方中至少一个目标参与方的取消订阅指令时，停止展示取消订阅的至少一个目标参与方各自对应的视频流数据，以及停止播放至少一个目标参与方各自对应的音频流数据；

其中，步骤S501～步骤S504具体可参照步骤S301～步骤S304，在此就不赘述了。

步骤S505，实时采集当前参与方的音频数据；

步骤S506，当检测到音频数据中不存在人声时，将音频数据的音频状态标记为静音状态，并计算音频数据的第一音频能量；

步骤S507，基于音频数据、静音状态和第一音频能量生成第一音频流数据，并将第一音频流数据发送至预设服务器；

步骤S508，当检测到音频数据中存在人声时，检测人声是否超过人声阈值；

步骤S509，若是，则将音频数据的音频状态标记为非静音状态，并计算音频数据的第二音频能量；

步骤S5010，基于音频数据、非静音状态和第二音频能量生成第二音频流数据，并将第二音频流数据发送至预设服务器；

步骤S5011，若否，则将音频数据的音频状态标记为静音状态，并计算音频数据的第三音频能量；

步骤S5012，基于音频数据、静音状态和第三音频能量生成第三音频流数据，并将第三音频流数据发送至预设服务器。

其中，步骤S505～步骤S5012具体可参照步骤S404～步骤S4011，在此就不赘述了。

需要说明的是，步骤S504可以在步骤S505之前执行，也可以在步骤S5012之后执行，在实际应用中可以根据实际需求进行调整，本公开实施例对此不作限制。

为方便理解，在本公开实施例中对音频流数据和视频流数据的传输过程进行详细说明。

在如图6所示的音频处理架构中，发送端为在线会议的任一参与方(比如A)对应的终端，接收端为在线会议中除该任一参与方之外的其它任一参与方(比如B)对应的终端。

发送端包括：音频采集模块，用于采集音频数据；检测/计算模块，用于检测人声、标记音频状态以及计算音频能量，并生成音频流数据；传输模块，用于将音频流数据发送至预设服务器。

接收端包括：传输模块，还用于接收预设服务器发送的音频流数据集；处理模块，用于从音频流数据集中的各个音频流数据中确定出各个目标参与方各自对应的音频流数据；播放模块，用于播放确定出的各个音频流数据。

在如图7所示的视频处理架构中，发送端为在线会议的任一参与方(比如A)对应的终端，接收端为在线会议中除该任一参与方之外的其它任一参与方(比如B)对应的终端。

发送端包括：图像采集模块，用于采集图像数据；编码模块，用于对图像数据进行编码，生成视频流数据；传输模块，用于将视频流数据发送至预设服务器。

接收端包括：订阅模块，用于订阅目标参与方和取消订阅目标参与方；传输模块，还用于人预设服务器获取各个目标参与方各自对应的视频流数据；渲染模块，用于对各个视频流数据进行渲染。

图8为本公开又一实施例提供的一种在线会议的处理装置的结构示意图，如图8所示，本实施例的装置可以包括：

确定模块801，用于基于预设的订阅信息、音频流数据集中的至少一种，从在线会议的多个参与方中确定出至少一个目标参与方；

获取模块802，用于基于至少一个目标参与方的订阅信息获取各个目标参与方各自对应的视频流数据，并从音频流数据集中获取各个目标参与方各自对应的音频流数据；

展示模块803，用于展示各个目标参与方各自对应的视频流数据，以及播放各个目标参与方各自对应的音频流数据。

在本公开一种优选实施例中，确定模块包括：

第一处理子模块，用于当接收到针对多个参与方中至少一个参与方的选择指令，且未接收到音频流数据集时，将至少一个参与方作为候选参与方；

第二处理子模块，用于当接收到针对候选参与方的确认指令时，将候选参与方确定为目标参与方。

在本公开一种优选实施例中，音频流数据集为除当前参与方之外的其它参与方各自对应的音频流数据；

确定模块包括：

过滤子模块，用于当接收到音频流数据集且未接收到订阅信息时，基于预设规则对所述音频流数据集中的音频流数据进行过滤，得到至少一个过滤后的音频流数据；

排序子模块，用于对至少一个过滤后的音频流数据进行排序，并将排序靠前的预设数量的音频流数据对应的参与方作为目标参与方。

在本公开一种优选实施例中，过滤子模块包括：

解析单元，用于对音频流数据集中的各个音频流数据分别进行解析，得到各个音频流数据各自对应的音频状态和音频能量参数；音频状态包括静音状态和非静音状态；

丢弃单元，用于将音频状态为非静音状态的音频流数据丢弃，得到至少一个过滤后的音频流数据；

排序子模块包括：

计算单元，用于基于各个剩余的音频流数据各自对应的音频能量参数分别计算出各个过滤后的音频流数据各自对应的音频能量；

排序单元，用于基于各个音频能量对至少一个过滤后的音频流数据进行排序。

在本公开一种优选实施例中，确定模块包括：

第三处理子模块，用于当接收到音频流数据集时，基于音频流数据集确定出至少一个第一参与方；

第四处理子模块，用于当至少一个第一参与方的数量不超过预设数量时，基于至少一个第一参与方的数量和预设数量计算得到数量差值；

第五处理子模块，用于当接收到订阅信息时，基于数量差值和订阅信息确定出至少一个第二参与方；至少一个第一参与方与至少一个第二参与方不存在任一相同的参与方；

第六处理子模块，用于将第一目标参与方和第二目标参与方作为最终的目标参与方。

在本公开一种优选实施例中，还包括：

第七处理子模块，用于当至少一个第一参与方的数量超过预设数量时，对至少一个第一参与方进行排序，并将排序靠前的预设数量的参与方作为最终的目标参与方。

在本公开一种优选实施例中，展示模块还用于：

当接收到针对各个目标参与方中至少一个目标参与方的取消订阅指令时，停止展示取消订阅的至少一个目标参与方各自对应的视频流数据，以及停止播放所述至少一个目标参与方各自对应的音频流数据。

在本公开一种优选实施例中，还包括：

采集模块，用于实时采集当前参与方的音频数据；

计算模块，用于当检测到音频数据中不存在人声时，将音频数据的音频状态标记为静音状态，并计算音频数据的第一音频能量；

生成模块，用于基于音频数据、静音状态和第一音频能量生成第一音频流数据，并将第一音频流数据发送至预设服务器。

在本公开一种优选实施例中，还包括：

检测模块，用于当检测到音频数据中存在人声时，检测人声是否超过人声阈值；

计算模块，还用于则将音频数据的音频状态标记为非静音状态，并计算音频数据的第二音频能量；

生成模块，还用于基于音频数据、非静音状态和第二音频能量生成第二音频流数据，并将第二音频流数据发送至预设服务器；

在本公开一种优选实施例中，还包括：

计算模块，还用于则将音频数据的音频状态标记为静音状态，并计算音频数据的第三音频能量；

生成模块，还用基于音频数据、静音状态和第三音频能量生成第三音频流数据，并将第三音频流数据发送至预设服务器。

本实施例的在线会议的处理装置可执行本公开步骤S201～步骤S203、步骤S301～步骤S304、步骤S401～步骤S4011、步骤S501～步骤S5012所示的在线会议的处理方法，其实现原理相类似，此处不再赘述。

更进一步，当前参与方对应的终端在获取目标参与方的视频流数据和音频流数据的同时，也会采集当前参与方的音频数据和图像数据。然后基于音频数据生成音频流数据，以及基于图像数据生成视频流数据，再将音频流数据和视频流数据同时发送至预设服务器，预设服务器将音频流数据发送至其它参与方，以使得其它参与方基于该音频流数据确定出目标参与方。

下面参考图9，其示出了适于用来实现本公开实施例的电子设备900的结构示意图。本公开实施例中的电子设备可以包括但不限于诸如移动电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、车载终端(例如车载导航终端)等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。图9示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

电子设备包括：存储器以及处理器，其中，这里的处理器可以称为下文所述的处理装置901，存储器可以包括下文中的只读存储器(ROM)902、随机访问存储器(RAM)903以及存储装置908中的至少一项，具体如下所示：如图9所示，电子设备900可以包括处理装置(例如中央处理器、图形处理器等)901，其可以根据存储在只读存储器(ROM)902中的程序或者从存储装置908加载到随机访问存储器(RAM)903中的程序而执行各种适当的动作和处理。在RAM 903中，还存储有电子设备900操作所需的各种程序和数据。处理装置901、ROM 902以及RAM 903通过总线904彼此相连。输入/输出(I/O)接口905也连接至总线904。

通常，以下装置可以连接至I/O接口905：包括例如触摸屏、触摸板、键盘、鼠标、摄像头、麦克风、加速度计、陀螺仪等的输入装置906；包括例如液晶显示器(LCD)、扬声器、振动器等的输出装置907；包括例如磁带、硬盘等的存储装置908；以及通信装置909。通信装置909可以允许电子设备900与其他设备进行无线或有线通信以交换数据。虽然图9示出了具有各种装置的电子设备900，但是应理解的是，并不要求实施或具备所有示出的装置。可以替代地实施或具备更多或更少的装置。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在非暂态计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信装置909从网络上被下载和安装，或者从存储装置908被安装，或者从ROM 902被安装。在该计算机程序被处理装置901执行时，执行本公开实施例的方法中限定的上述功能。

需要说明的是，本公开上述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、RF(射频)等等，或者上述的任意合适的组合。

在一些实施方式中，客户端、服务器可以利用诸如HTTP(HyperText TransferProtocol，超文本传输协议)之类的任何当前已知或未来研发的网络协议进行通信，并且可以与任意形式或介质的数字数据通信(例如，通信网络)互连。通信网络的示例包括局域网(“LAN”)，广域网(“WAN”)，网际网(例如，互联网)以及端对端网络(例如，ad hoc端对端网络)，以及任何当前已知或未来研发的网络。

上述计算机可读介质可以是上述电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。

上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该电子设备执行时，使得该电子设备：基于预设的订阅信息、音频流数据集中的至少一种，从所述在线会议的多个参与方中确定出至少一个目标参与方；基于各个目标参与方的订阅信息获取各个目标参与方各自对应的视频流数据，并从所述音频流数据集中获取各个目标参与方各自对应的音频流数据；展示各个目标参与方各自对应音频流数据和视频流数据。

可以以一种或多种程序设计语言或其组合来编写用于执行本公开的操作的计算机程序代码，上述程序设计语言包括但不限于面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本公开实施例中所涉及到的模块或单元可以通过软件的方式实现，也可以通过硬件的方式来实现。其中，模块或单元的名称在某种情况下并不构成对该单元本身的限定。

本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、片上系统(SOC)、复杂可编程逻辑设备(CPLD)等等。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

根据本公开的一个或多个实施例，【示例一】提供了一种在线会议的处理方法，包括：

在本公开一种优选实施例中，所述基于预设的订阅信息、音频流数据集中的至少一种，从所述在线会议的多个参与方中确定出至少一个目标参与方，包括：

当接收到针对多个参与方中至少一个参与方的选择指令，且未接收到音频流数据集时，将所述至少一个参与方作为候选参与方；

当接收到针对所述候选参与方的确认指令时，将所述候选参与方确定为目标参与方。

在本公开一种优选实施例中，所述音频流数据集为除当前参与方之外的其它参与方各自对应的音频流数据；

所述基于预设的订阅信息、音频流数据集中的至少一种，从所述在线会议的多个参与方中确定出至少一个目标参与方，包括：

当接收到音频流数据集且未接收到订阅信息时，基于预设规则对所述音频流数据集中的音频流数据进行过滤，得到至少一个过滤后的音频流数据；

对所述至少一个过滤后的音频流数据进行排序，并将排序靠前的预设数量的音频流数据对应的参与方作为目标参与方。

在本公开一种优选实施例中，所述基于预设规则对所述音频流数据集中的音频流数据进行过滤，得到至少一个过滤后的音频流数据，包括：

对所述音频流数据集中的各个音频流数据分别进行解析，得到各个音频流数据各自对应的音频状态和音频能量参数；所述音频状态包括静音状态和非静音状态；

所述对所述至少一个过滤后的音频流数据进行排序，包括：

基于各个音频能量对所述至少一个过滤后的音频流数据进行排序。

当接收到音频流数据集时，基于所述音频流数据集确定出至少一个第一参与方；

当所述至少一个第一参与方的数量不超过预设数量时，基于所述至少一个第一参与方的数量和所述预设数量计算得到数量差值；

当接收到订阅信息时，基于所述数量差值和所述订阅信息确定出至少一个第二参与方；所述至少一个第一参与方与所述至少一个第二参与方不存在任一相同的参与方；

将所述第一目标参与方和所述第二目标参与方作为最终的目标参与方。

在本公开一种优选实施例中，还包括：

当所述至少一个第一参与方的数量超过所述预设数量时，对所述至少一个第一参与方进行排序，并将排序靠前的所述预设数量的参与方作为最终的目标参与方。

在本公开一种优选实施例中，还包括：

实时采集当前参与方的音频数据；

当检测到所述音频数据中不存在人声时，将所述音频数据的音频状态标记为静音状态，并计算所述音频数据的第一音频能量；

基于所述音频数据、所述静音状态和所述第一音频能量生成第一音频流数据，并将所述第一音频流数据发送至预设服务器。

在本公开一种优选实施例中，还包括：

当检测到所述音频数据中存在人声时，检测所述人声是否超过人声阈值；

若是，则将所述音频数据的音频状态标记为非静音状态，并计算所述音频数据的第二音频能量；

基于所述音频数据、所述非静音状态和所述第二音频能量生成第二音频流数据，并将所述第二音频流数据发送至所述预设服务器。

在本公开一种优选实施例中，还包括：

若所述人声不超过所述人声阈值，则将所述音频数据的音频状态标记为静音状态，并计算所述音频数据的第三音频能量；

基于所述音频数据、所述静音状态和所述第三音频能量生成第三音频流数据，并将所述第三音频流数据发送至所述预设服务器。

根据本公开的一个或多个实施例，【示例二】提供了示例一的装置，包括：

在本公开一种优选实施例中，所述确定模块包括：

第一处理子模块，用于当接收到针对多个参与方中至少一个参与方的选择指令，且未接收到音频流数据集时，将所述至少一个参与方作为候选参与方；

第二处理子模块，用于当接收到针对所述候选参与方的确认指令时，将所述候选参与方确定为目标参与方。

所述确定模块包括：

排序子模块，用于对所述至少一个过滤后的音频流数据进行排序，并将排序靠前的预设数量的音频流数据对应的参与方作为目标参与方。

在本公开一种优选实施例中，所述过滤子模块包括：

解析单元，用于对所述音频流数据集中的各个音频流数据分别进行解析，得到各个音频流数据各自对应的音频状态和音频能量参数；所述音频状态包括静音状态和非静音状态；

所述排序子模块包括：

计算单元，用于基于各个剩余的音频流数据各自对应的音频能量参数分别计算出所述至少一个过滤后的音频流数据各自对应的音频能量；

排序单元，用于基于各个音频能量对各个过滤后的音频流数据进行排序。

在本公开一种优选实施例中，所述确定模块包括：

第三处理子模块，用于当接收到音频流数据集时，基于所述音频流数据集确定出至少一个第一参与方；

第四处理子模块，用于当所述至少一个第一参与方的数量不超过预设数量时，基于所述至少一个第一参与方的数量和所述预设数量计算得到数量差值；

第五处理子模块，用于当接收到订阅信息时，基于所述数量差值和所述订阅信息确定出至少一个第二参与方；所述至少一个第一参与方与所述至少一个第二参与方不存在任一相同的参与方；

第六处理子模块，用于将所述第一目标参与方和所述第二目标参与方作为最终的目标参与方。

在本公开一种优选实施例中，还包括：

第七处理子模块，用于当所述至少一个第一参与方的数量超过所述预设数量时，对所述至少一个第一参与方进行排序，并将排序靠前的所述预设数量的参与方作为最终的目标参与方。

在本公开一种优选实施例中，所述展示模块还用于：

在本公开一种优选实施例中，还包括：

采集模块，用于实时采集当前参与方的音频数据；

计算模块，用于当检测到所述音频数据中不存在人声时，将所述音频数据的音频状态标记为静音状态，并计算所述音频数据的第一音频能量；

生成模块，用于基于所述音频数据、所述静音状态和所述第一音频能量生成第一音频流数据，并将所述第一音频流数据发送至预设服务器。

在本公开一种优选实施例中，还包括：

检测模块，用于当检测到所述音频数据中存在人声时，检测所述人声是否超过人声阈值；

所述计算模块，还用于则将所述音频数据的音频状态标记为非静音状态，并计算所述音频数据的第二音频能量；

所述生成模块，还用于基于所述音频数据、所述非静音状态和所述第二音频能量生成第二音频流数据，并将所述第二音频流数据发送至所述预设服务器；

在本公开一种优选实施例中，还包括：

所述计算模块，还用于则将所述音频数据的音频状态标记为静音状态，并计算所述音频数据的第三音频能量；

所述生成模块，还用基于所述音频数据、所述静音状态和所述第三音频能量生成第三音频流数据，并将所述第三音频流数据发送至所述预设服务器。

以上描述仅为本公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本公开中所涉及的公开范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述公开构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

此外，虽然采用特定次序描绘了各操作，但是这不应当理解为要求这些操作以所示出的特定次序或以顺序次序执行来执行。在一定环境下，多任务和并行处理可能是有利的。同样地，虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实施例中。相反地，在单个实施例的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实施例中。

尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。

Claims

1.一种在线会议的处理方法，其特征在于，包括：

展示各个目标参与方各自对应的视频流数据，以及播放各个目标参与方各自对应的音频流数据；

其中，所述基于预设的订阅信息、音频流数据集中的至少一种，从所述在线会议的多个参与方中确定出至少一个目标参与方，包括：

将所述至少一个第一参与方和所述至少一个第二参与方作为所述目标参与方。

2.根据权利要求1所述的在线会议的处理方法，其特征在于，所述基于预设的订阅信息、音频流数据集中的至少一种，从所述在线会议的多个参与方中确定出至少一个目标参与方，包括：

3.根据权利要求1所述的在线会议的处理方法，其特征在于，所述音频流数据集为除当前参与方之外的其它参与方各自对应的音频流数据；

4.根据权利要求3所述的在线会议的处理方法，其特征在于，所述基于预设规则对所述音频流数据集中的音频流数据进行过滤，得到至少一个过滤后的音频流数据，包括：

所述对所述至少一个过滤后的音频流数据进行排序，包括：

5.根据权利要求1所述的在线会议的处理方法，其特征在于，还包括：

6.根据权利要求1所述的在线会议的处理方法，其特征在于，还包括：

7.根据权利要求1或6所述的在线会议的处理方法，其特征在于，还包括：

实时采集当前参与方的音频数据；

8.根据权利要求7所述的在线会议的处理方法，其特征在于，还包括：

9.根据权利要求8所述的在线会议的处理方法，其特征在于，还包括：

10.一种在线会议的处理装置，其特征在于，包括：

展示模块，用于展示各个目标参与方各自对应的视频流数据，以及播放各个目标参与方各自对应的音频流数据；

其中，所述确定模块包括：

第六处理子模块，用于将所述至少一个第一参与方和所述至少一个第二参与方作为所述目标参与方。

11.一种电子设备，其特征在于，其包括：

处理器、存储器和总线；

所述总线，用于连接所述处理器和所述存储器；

所述存储器，用于存储操作指令；

所述处理器，用于通过调用所述操作指令，执行上述权利要求1-9中任一项所述的在线会议的处理方法。

12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质用于存储计算机指令，当其在计算机上运行时，使得计算机可以执行上述权利要求1-9中任一项所述的在线会议的处理方法。