CN116320260A - 一种视频会议控制方法、系统及计算设备 - Google Patents

Abstract

一种视频会议控制方法，包括：在目标场景下，云服务器获取参加视频会议的会议人数，目标场景为多个观看方同时观看多个被观看方的画面的场景；在会议人数大于第一预设人数的情况下，云服务器将从各个被观看方的客户端处获取到的多路视频合成为一路视频，并将一路视频分别发送至各个观看方的客户端；在会议人数小于第二预设人数的情况下，云服务器将从各个被观看方的客户端处获取到的多路视频均分别发送至各个观看方的客户端，其中，第二预设人数小于或等于第一预设人数。由此，通过根据会议人数动态开启和关闭服务器对多路视频进行合成，降低了视频会议过程中所占用的资源。

Description

一种视频会议控制方法、系统及计算设备

技术领域

本申请涉及信息技术(information technology，IT)技术领域，尤其涉及一种视频会议控制方法、系统及计算设备。

背景技术

随着通信技术的发展，视频会议应用越来越广泛，不仅在传统的办公会议，在远程医疗、教育培训、远程维护、应急指挥、视频客服领域也广泛使用。但目前在进行视频会议时，常会出现资源(比如：计算资源、带宽资源等)占用过高的情况。因此，如何降低视频会议过程中所占用的资源是目前亟需解决的技术问题。

发明内容

本申请提供了一种视频会议控制方法、系统、计算设备、计算设备集群、计算机存储介质及计算机产品，能够降低视频会议过程中所占用的资源。

第一方面，本申请提供一种视频会议控制方法，应用于云服务器。该方法可以包括：在目标场景下，获取参加视频会议的会议人数，目标场景为多个观看方同时观看多个被观看方的画面的场景；在会议人数大于第一预设人数的情况下，将从各个被观看方的客户端处获取到的多路视频合成为一路视频，并将一路视频分别发送至各个观看方的客户端；在会议人数小于第二预设人数的情况下，将从各个被观看方的客户端处获取到的多路视频均分别发送至各个观看方的客户端，其中，第二预设人数小于或等于第一预设人数。

由此，通过根据会议人数动态开启和关闭服务器合成多画面，在会议人数少的时候采用多流模式(此时因会议人数少，多流模式总带宽不高且信令交互少，节省了服务器编码CPU)，在会议人数多的时候采用单流模式(会议人数多，单流模式虽然编制了一路合成画面，平均下来人均消耗的服务器CPU较低，但大大降低了带宽和信令交互)，既利用了两个方案的优点，也避免了两个方案的缺点。示例性的，视频会议的场景可以理解为是由多个用户同时进行视频的场景，其并不一定是必须开会，也可以是闲聊或娱乐等。示例性的，合成多画面可以理解为是将不同用户的多路视频合成为一路视频。

在一种可能的实现方式中，云服务器包括第一服务器和第二服务器。在将一路视频分别发送至各个观看方的客户端之前，该方法还可以包括：在会议人数大于第一预设人数的情况下，第一服务器通知各个观看方的客户端向第二服务器订阅合成视频，以及通知第二服务器将从各个被观看方的客户端处获取到的多路视频合成为一路视频；第二服务器获取各个被观看方的客户端发送的用于订阅合成视频的订阅请求，以及，将从各个被观看方的客户端处获取到的多路视频合成为一路视频。

在一种可能的实现方式中，云服务器包括第一服务器和第二服务器。在将通过各个被观看方的客户端处获取到的多路视频均分别发送至各个观看方的客户端之前，该方法还可以包括：在会议人数小于第二预设人数的情况下，第一服务器通知各个观看方的客户端向第二服务器订阅各个被观看方的视频；第二服务器获取各个被观看方的客户端发送的用于订阅各个被观看方的视频的订阅请求。

在一种可能的实现方式中，第二服务器在获取到订阅请求之后，该方法还可以包括：获取各个订阅请求中携带的目标值，目标值用于表征订阅请求所订阅的多路视频；在目标值的数量达到预设值或者距离前次处理订阅请求的时间达到预设时间的情况下，进行路由配置，路由配置用于配置第二服务器与各个观看方间的路由。由此第二服务器即可以批量处理订阅请求，提高了订阅请求的处理效率和降低服务器性能压力。

在一种可能的实现方式中，该方法还可以包括：获取第一客户端发送的第一指令；在第一指令为要求多个观看方同时观看多个被观看方的画面的情况下，确定当前的会议场景为目标场景。示例性的，第一客户端可以是为浏览器或者APP。

在一种可能的实现方式中，该方法还可以包括：获取第二客户端发送的第二指令，第二指令用于配置第一预设人数和/或第二预设人数；基于第二指令，配置第一预设人数和第二预设人数。示例性的，第二客户端可以是为浏览器或者APP。

第二方面，本申请提供一种视频会议控制系统包括：云服务器和与会人员所使用的客户端。其中，云服务器，用于在目标场景下，获取参加视频会议的会议人数，目标场景为多个观看方同时观看多个被观看方的画面的场景。云服务器，还用于在会议人数大于第一预设人数的情况下，将从各个被观看方的客户端处获取到的多路视频合成为一路视频，并将一路视频分别发送至各个观看方的客户端。云服务器，还用于在会议人数小于第二预设人数的情况下，将从各个被观看方的客户端处获取到的多路视频均分别发送至各个观看方的客户端，其中，第二预设人数小于或等于第一预设人数。

在一种可能的实现方式中，云服务器包括第一服务器和第二服务器。在会议人数大于第一预设人数的情况下，第一服务器用于通知各个观看方的客户端向第二服务器订阅合成视频，以及，通知第二服务器将从各个被观看方的客户端处获取到的多路视频合成为一路视频；第二服务器用于获取各个被观看方的客户端发送的用于订阅合成视频的订阅请求，以及，将从各个被观看方的客户端处获取到的多路视频合成为一路视频。

在一种可能的实现方式中，云服务器包括第一服务器和第二服务器。在会议人数小于第二预设人数的情况下，第一服务器用于通知各个观看方的客户端向第二服务器订阅各个被观看方的视频；第二服务器用于获取各个被观看方的客户端发送的用于订阅各个被观看方的视频的订阅请求。

在一种可能的实现方式中，第二服务器在获取到订阅请求之后，还用于：获取各个订阅请求中携带的目标值，目标值用于表征订阅请求所订阅的多路视频；在目标值的数量达到预设值或者距离前次处理订阅请求的时间达到预设时间的情况下，进行路由配置，路由配置用于配置第二服务器与各个观看方间的路由。

在一种可能的实现方式中，云服务器，还用于：获取第一客户端发送的第一指令；在第一指令为要求多个观看方同时观看多个被观看方的画面的情况下，确定当前的会议场景为目标场景。

在一种可能的实现方式中，云服务器，还用于：获取第二客户端发送的第二指令，第二指令用于配置第一预设人数和/或第二预设人数；基于第二指令，配置第一预设人数和第二预设人数。

第三方面，本申请提供一种计算设备，包括：至少一个存储器，用于存储程序；至少一个处理器，用于执行存储器存储的程序；其中，当存储器存储的程序被执行时，处理器用于执行第一方面或第一方面的任一种可能的实现方式所描述的方法。

第四方面，本申请提供一种计算设备集群，包括至少一个计算设备，每个计算设备均包括处理器和存储器；至少一个计算设备的处理器用于执行至少一个计算设备的存储器中存储的指令，以使得计算设备集群执行第一方面或第一方面的任一种可能的实现方式所描述的方法。

第五方面，本申请提供一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，当计算机程序在处理器上运行时，使得处理器执行第一方面或第一方面的任一种可能的实现方式所描述的方法。

第六方面，本申请提供一种计算机程序产品，当计算机程序产品在处理器上运行时，使得处理器执行第一方面或第一方面的任一种可能的实现方式所描述的方法。

可以理解的是，上述第二方面至第六方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

图1是本申请实施例提供的一种视频会议的应用场景的示意图；

图2是本申请实施例提供的一种在视频会议中采用单流模式的示意图；

图3是本申请实施例提供的一种在视频会议中采用多流模式的示意图；

图4是本申请实施例提供的一种视频会议控制系统的示意图；

图5是本申请实施例提供的一种视频会议控制系统中各个组件，及组件间连接的示意图；

图6是本申请实施例提供的一种在视频会议时启动多画面合成的过程示意图；

图7是本申请实施例提供的一种在视频会议时关闭多画面合成的过程示意图；

图8是本申请实施例提供的一种在视频会议时批量处理订阅请求的过程示意图；

图9是本申请实施例提供的一种视频会议控制方法的流程示意图；

图10是本申请实施例提供的一种计算设备的结构示意图；

图11是本申请实施例提供的一种计算设备集群的结构示意图。

具体实施方式

本文中术语“和/或”，是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。本文中符号“/”表示关联对象是或者的关系，例如A/B表示A或者B。

本文中的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一响应消息和第二响应消息等是用于区别不同的响应消息，而不是用于描述响应消息的特定顺序。

在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或者两个以上，例如，多个处理单元是指两个或者两个以上的处理单元等；多个元件是指两个或者两个以上的元件等。

示例性的，图1示出了一种视频会议的应用场景。如图1所示，在视频会议时，可以有多个用户(即与会者)，每个用户均可以使用其自己的电子设备进行会议，每个用户所使用的电子设备上均可以配置有用于进行视频会议的应用程序(application，APP)或者是客户端。不同的用户所使用的电子设备间均可以通过有线网络或无线网络进行通信。不同的用户可以位于同一区域，也可以位于不同的区域。一个电子设备可以被一个用户使用，也可以被多个用户使用，即多个用户可以同时使用一个电子设备与其他的用户进行视频会议。在视频会议过程中，每个用户均可以在其所使用的电子设备上观看到其他的用户的画面。当然，每个用户也可以选择在观看其他的用户的画面时，同时观看其自己的画面。在视频会议开始前，可以从所有的用户中选择一个用户作为主持人，该主持人可以主持此次视频会议。另外，在预约视频会议时，预约人可以为主持人，在会议中当前的主持人可以将主持人转让给其他的用户。此外，预约人还可以将主持人的会议链接或密码转发给某个用户，该用户在使用主持人的会议链接入会后，该用户即为主持人。在视频会议过程中，该主持人可以通过其所使用的会议APP(即用于进行视频会议的APP、浏览器等)，向所有的用户所使用的会议APP下发指令，也可以向一部分用户所使用的会议APP下发指令。示例性的，主持人可以选择让所有的用户(即观看方)同时观看一部分用户(即被观看方)的画面。例如，当除主持人之外的用户有10个人时，主持人可以选择让所有人均观看其中4个人的画面。示例性的，每个用户的画面均可以通过其自身所使用的会议APP发送至与用户所使用的APP关联的服务器，再由该服务器转发至其他的用户所使用的会议APP上。另外，主持人通过其所使用的会议APP下发的指令，可以先传输至服务器，再由该服务器转发至其他的用户所使用的会议APP。

一般地，当被观看方有多个时，每个被观看方所使用的电子设备可以分别将它们各自所采集到视频发送至服务器。然后，服务器中的编码器可以对这多路视频进行编码，以将这多路视频编码成一路视频。最后，服务器在将其编码后的一路视频分别转发至各个观看方。例如，如图2所示，当除主持人之外的用户有6个人，且主持人指示用户4至6同时观看用户1至3的画面时，用户1至3所使用的电子设备可以分别将它们各自所采集到视频发送至服务器。然后，服务器中的编码器可以对这三路视频进行编码，以将这三路视频编码成一路视频。最后，服务器在分别将其编码后的一路视频转发至用户4至6。这样，用户4至6即可以均同时观看到用户1至3的画面。这种方式虽然可以实现让观看方同时观看到多个被观看方的画面，但因为解码、编码会消耗一定的计算资源，而编码成一路视频后会节约部分带宽，所以这种方式优缺点很明显，即计算资源占用高、带宽消耗低。这种方式在会议人数多时，因为同一个会议消耗的编码资源是固定的，如果能被更多的用户使用且节省了每个用户所消耗的带宽，从资源的使用效率上更划算。但在会议人数较少时，同一份编码资源被少量用户使用，且节省的总带宽比较少，编码资源的使用效率较低。示例性的，此种视频会议模式可以称之为“单流模式”。

因为单流模式占用服务器计算资源较多的原因，视频会议等实时音视频业务开始使用多流模式。在多流模式下，服务器根据观看方的订阅请求(即观看方向服务器请求观看哪些被观看方的画面)，按需向观看方转发被观看方的视频码流。因只做码流的转发，对观看方来说，如果其观看多个用户，其将会同时接收多个被观看方的视频，并在本地进行渲染后展示到其所使用的电子设备的显示界面上。例如，如图3所示，当除主持人之外的用户有6个人，且主持人指示用户4至6同时观看用户1至3的画面时，用户1至3所使用的电子设备可以分别将它们各自所采集到视频发送至服务器。然后，服务器中可以将这三路视频均转发至用户4至6。最后，用户4至6所使用的电子设备可以均对这三路视频进行本地渲染，并进行显示。这样，用户4至6即可以均同时观看到用户1至3的画面。在这种模式下，服务器只做视频的转发不做编解码，因此会节省计算资源，但对观看方来说，因为其会接收多路视频，所以将会占用较多的带宽资源。另外，在这种模式下，当一个会议中用户数比较多的时候，会产额生大量的信令消息，比如：召开了一个1000人的会议，主持人设置了广播25个人的画面，所有与会人均观看这25各画面，服务器会短时间收到1000个订阅请求，每个订阅请求均会订阅25条视频，此时服务器需要处理1000*25＝25000条流，对服务器性能压力非常大。

有鉴于此，本申请实施例提供了一种视频会议控制方法。该方法可以在进行视频会议，且被观看方为多个的情况下，可以根据会议人数动态控制使用单流模式和多流模式，即：在会议人数比较少时，采用多流模式，节省服务器编码资源，当会议人数较多时，将会议动态调整单流模式，用消耗一定计算资源的代价，节省更多的带宽资源，同时减少服务器内部或者外部的信令交互。示例性的，视频会议的场景可以理解为是由多个用户同时进行视频的场景，其并不一定是必须开会，也可以是闲聊或娱乐等。

示例性的，图4示出了一种视频会议控制系统的架构示意图。如图4所示，该视频会议控制系统400包括：云服务器410、主持人的客户端420和n个(n≥1)用户的客户端430。

云服务器410中可以设置有控制服务器411和媒体服务器412。其中，控制服务器411可以但不限于用于接收客户端420下发的控制指令，以及，向媒体服务器412下发控制指令，和向n个客户端430下发控制指令。媒体服务器412可以但不限于用于接收各个用户的客户端发送的用户的视频，以及，将客户端420指定的多个用户的画面传输至n个客户端430。示例性的，控制服务器411和媒体服务器412可以单独布置，也可以集成在一起。另外，当控制服务器411和媒体服务器412单独布置时，两者可以位于同一区域，也可以位于不同区域。例如，控制服务器411可以位于东北地区，媒体服务器412可以位于西南地区等。在一些实施例中，媒体服务器412可以由多个子服务器组成，这些子服务器同样可以位于同一区域，也可以位于不同的区域。

客户端420可以配置在主持人所使用的电子设备(比如：手机、电脑等)上。每个客户端430可以配置在相应的用户所使用的电子设备上。客户端420所在的电子设备和各个客户端430所在的电子设备均可以通过有线网络或无线网络与云服务器410进行通信。每个客户端430均可以将与其关联的电子设备所采集的用户的视频传输至媒体服务器412中。示例性的，客户端420和430均可以为APP或浏览器等。

继续参阅图4，在进行视频会议时，在S401，主持人可以通过客户端420启动广播多画面，即指定一部分或全部用户观看一部分或全部用户的画面。在S402，控制服务器411获取到客户端420发送的指令后，可以判断当前的与会人数是否超过预设人数。在S402，当超过预设人数时，控制服务器411可以向媒体服务器下发用于进行多画面合成的合成多画面指令(即将不同用户的多路视频合成为一路视频的指令)。在S403，媒体服务器412在获取到控制服务器411发送的指令后，可以对客户端420指定的多个用户的视频画面进行合成。另外，在S404，控制服务器411在下发合成多画面指令时，还可以通知n个用户(即主持人指定的需要观看多画面的用户)的客户端430订阅合成的多画面。在S405，每个客户端430在获取到控制服务器411发送的指令后，均可以向媒体服务器412订阅该服务器合成的多画面。在S406，媒体服务器412在获取到各个客户端430的订阅后，可以将其合成的画面下发至各个客户端430。示例性的，当与会人数未超过预设人数时，控制服务器411可以不向媒体服务器412发送合成多画面指令，即此时继续使用多流模式传输视频。由此，即实现根据会议人数动态控制使用单流模式和多流模式，从而在会议人数较多时，采用多流模式，以节省服务器编码资源，在会议人数较少时，采用单流模式，用消耗一定计算资源的代价，节省更多的带宽资源。

接下来，对客户端420、控制服务器411、媒体服务器412和客户端430分别进行介绍。

示例性的，如图5所示，客户端420中可以包括控制模块421。该控制模块421可以用于基于获取到的主持人下发的指令，向控制服务器411下发启动多画面的指令，或者是其他的对会议进行控制的指令。示例性的，主持人可以通过客户端420选择多画面的布局、多画面中的用户(即被观看方)的标识等。其中，启动多画面的指令可以包括主持人所选择的多画面的布局、被观看方的标识等信息。

以上即是对客户端420的介绍，下面基于图5对控制服务器411进行介绍。

继续参阅图5，控制服务器411中可以包括：系统配置模块4111、会议控制模块4112、媒体任务调度模块4113和用户代理模块4114。其中，系统配置模块4111可以用于配置和/或存储启动合成多画面的会议人数和停止合成多画面的会议人数。示例性的，视频会议系统的管理员可以通过访问用于对视频会议进行管理的会议管理平台等对启动和停止合成多画面的会议人数进行配置。例如，管理员可以配置当会议人数大于30人时，启动合成多画面，当会议人数小于或等于30人时，停止合成多画面。在一些实施例中，为了避免短时间内反复交替出现启动和停止合成多画面的情况，可以将停止合成多画面的会议人数设置为低于启动合成多画面的会议人数，例如，可以配置当会议人数大于30人时，启动合成多画面，当会议人数小于或等于20人时，停止合成多画面。在管理员完成会议人数的配置后，这些配置即存储在系统配置模块4111中。示例性的，合成多画面可以理解为是将不同用户的多路视频合成为一路视频。

会议控制模块4112主要是用于对于视频会议相关的业务进行控制。示例性的，每个用户在入会和离会时，均可以通过用户代理模块4114通知会议控制模块4112，改名、关闭麦克风、关闭摄像头之类的指令均需通过用户代理模块4114通知会议控制模块4112完成。会议控制模块4112可以从系统配置模块4111中读取到管理员配置的启动和关闭合成多画面的会议人数。在一些实施例中，会议控制模块4112可以通过用户代理模块4114接收客户端420下发启动多画面的指令。之后，会议控制模块4112可以对该指令进行解析，以创建合成多画面任务指令和向用户下发订阅合成多画面的指令。其中，向用户下发订阅合成多画面的指令中可以包括被观看方的标识等信息。若当前的会议人数大于系统配置模块4111中配置的启动合成多画面的会议人数，会议控制模块4112则可以向媒体任务调度模块4113发送多画面合成指令。另外，若当前的会议人数小于或等于系统配置模块4111中配置的停止合成多画面的会议人数，且会议控制模块4112已发送多画面合成指令，会议控制模块4112则可以向媒体任务调度模块4113发送停止多画面合成指令。此外，若当前的会议人数小于或等于系统配置模块4111中配置的停止合成多画面的会议人数，且会议控制模块4112未发送多画面合成指令，会议控制模块4112则可以不向媒体任务调度模块4113发送指令。

媒体任务调度模块4113主要用于在接收到会议控制模块4112下发的多画面合成指令后，从云服务器410中选择一个合适的媒体服务器412，并向其下发多画面合成指令，以使媒体服务器412进行多画面合成，或者，用于在接收到会议控制模块4112下发的停止多画面合成指令后，向媒体服务器412下发停止多画面合成指令，以使媒体服务器412不再进行多画面合成。

用户代理模块4114主要用于与客户端420和客户端430进行通信，以及，接收会议控制模块4112下发的广播指令，并向会议中全部或一部分用户的客户端430推送用于观看主持人所指定的被观看方的视频画面的订阅指令。

以上即是对控制服务器411的介绍，下面基于图5对媒体服务器412进行介绍。

继续参阅图5，媒体服务器412中可以包括：媒体任务管理模块4121、路由管理模块4122、媒体接收模块4123、媒体发送模块4124、编解码模块4125、信令控制模块4126和系统配置模块4127。其中，媒体任务管理模块4121主要用于接收控制服务器411中的媒体任务调度模块4113发送的指令，并基于该指令进行媒体任务分发。媒体任务可以包括媒体编解码任务和媒体转发任务。媒体编解码任务是指将多个视频合成一个视频，并将合成后的视频转发至各个视频订阅者的任务；媒体转发任务是指不对视频进行合成，而是直接将各个视频分别转发至各个视频订阅者的任务。在一些实施例中，当媒体任务管理模块4121接收到的是多画面合成指令时，其所分发的任务可以是媒体编解码任务；当媒体任务管理模块4121接收到的是停止多画面合成指令时，其所分发的任务可以是媒体转发任务；当媒体任务管理模块4121一直未接收到多画面合成指令，或者，在接收到停止多画面合成指令后始终未接收到多画面合成指令时，其所分发的任务可以是媒体转发任务。

在一些实施例中，媒体任务管理模块4121在下发媒体编解码任务时，其是向编解码模块4125发送多画面合成指令，以及，向路由管理模块4122发送从媒体接收模块4123向编解码模块4125转发视频的任务，和发送从编解码模块4125向媒体发送模块4124转发视频的任务。此时，媒体接收模块4123在获取到各个客户端430发送的视频，或者主持人所指定的需要合成的视频后，可以将这些视频转发至编解码模块4125。接着，编解码模块4125可以对主持人所指定的需要合成的视频进行编解码，以完成视频合成，并将合成后的视频转发至媒体发送模块4124。最后，在由媒体发送模块4124将合成后的视频转发至相应的客户端430。

在一些实施例中，媒体任务管理模块4121在下发媒体转发任务时，其是向路由管理模块4122发送从编解码模块4125向媒体发送模块4124转发视频的任务。此时，媒体接收模块4123在获取到各个客户端430发送的视频，或者主持人所指定的需要合成的视频后，可以直接将这些视频转发至媒体发送模块4124。最后，在由媒体发送模块4124将主持人所指定的各个视频分别转发至相应的客户端430。

路由管理模块4122主要是用于管理媒体接收模块4123向媒体发送模块4124的路由，管理媒体接收模块4123到编解码模块4125的路由，管理编解码模块4125到媒体发送模块4124的路由。

媒体接收模块4123主要是用于接收各个客户端430发送的视频，并根据路由管理模块4122的路由配置将相应的视频转发到媒体发送模块，或者，转发到编解码模块4125。

媒体发送模块4124主要是用于负责将视频通过网络发送给会议用户所使用的客户端430。在一些实施例中，媒体发送模块4124和媒体接收模块4123可以集成在一起，也可以单独布置。

编解码模块4125主要是用于从媒体接收模块4123获取视频，并对主持人所指定的视频进行编解码，以将多路视频合成一个视频，以及，再根据路由配置将合成后的视频转发到媒体发送模块4124。

信令控制模块4126主要是用于接收各个客户端430的订阅请求。在一些实施例中，该订阅请求中可以包括各个客户端430所需订阅的视频的标识，比如视频对应的用户的标识等。另外，信令控制模块4126还可以基于接收到的订阅请求，向路由管理模块4122下发路由配置，以告知路由管理模块4122需要将哪些用户的视频转发给哪些用户。例如，当除主持人之外的会议人数为6人，且主持人指定的视频为用户1和2的视频时，各个订阅请求中均可以包括用户1和2的标识，信令控制模块4126向路由管理模块4122下发路由配置可以为：将用户1和2的视频转发至用户1至6。在一些实施例中，信令控制模块4126还可以读取系统配置模块4127中的相关配置。

系统配置模块4127主要是用于配置批量处理订阅请求的时长间隔和每批次处理的订阅请求数量。批量处理订阅请求是指信令控制模块4126在接收到一定数量或者经过一段时间后，再对其接收到的订阅请求进行处理，而不是每接收到一个订阅请求就马上进行处理，由此通过这种方式，减少了信令控制模块4126和路由管理模块4122的交互，同时路由管理通过批量处理也提高了路由配置的效率，从而达到减少媒体服务器412内部模块间的交互次数和提高处理效率的目的。

以上即是对媒体服务器412的介绍，下面基于图5对客户端430进行介绍。

继续参阅图5，客户端430中可以包括：媒体发送模块431、媒体接收模块432、媒体显示模块433和信令控制模块434。媒体发送模块431主要是用于将配置有客户端430的电子设备采集到的视频发送至媒体服务器412中的媒体接收模块4123。媒体接收模块432主要是用于接收媒体服务器412中媒体发送模块4124发送的视频，并解码后发送给媒体显示模块433。媒体显示模块433主要是用于渲染视频画面，以及显示主持人所指定的视频的画面。信令控制模块434主要是用于处理控制服务器411中用户代理模块4114下发的会议业务控制指令，以及，向媒体服务器412中的信令控制模块4126发送订阅请求等。在一些实施例中，媒体发送模块431和媒体接收模块432可以集成在一起，也可以单独布置。

应理解的是，图5中仅示出了一个客户端430，实际上客户端430可以为多个。当客户端430为多个时，也可以参照前述描述，此处不再一一赘述。

以上即是对本申请实施例提供的视频会议控制系统400，以及该系统中相关的硬件或软件的介绍。接下来，基于上述内容，分别对启动和停止多画面合成的流程进行介绍。

(1)启动多画面合成的流程

示例性的，如图6所示，step1，管理员可以预先在会议控制服务器411的系统配置模块4111中设置合成多画面的参数，比如：配置启动合成多画面的人数和关闭合成多画面的人数等。当然，这些参数也可以是默认的，具体可根据实际情况而定。

step2，主持人可以通过其所使用的客户端向用户代理模块4114下发多画面指令，即启动广播多画面，要求所有用户观看其所指定的多个用户的画面。接着，用户代理模块4114可以将该指令转发至会议控制模块4112。示例性的，多画面指令中可以包含多个画面的布局(即视频布局)和视频源(即被观看方的视频)的标识等。

step3，会议控制模块4112可以基于当前的会议人数和其从系统配置模块4111读取到的配置参数，计算是否启动合成多画面。当会议人数达到启动合成多画面的人数时，其将向媒体任务调度模块4113下发多画面合成指令。在一些实施例中，当会议人数发生变化时，会议控制模块4112也需要执行此计算，判断是否应该启动合成多画面，并把指令下发到媒体任务调度模块4113。

step4，媒体任务调度模块4113可以向媒体服务器412中的媒体任务管理模块4121下发用于合成多画面的多画面合成指令。

step5，媒体任务管理模块4121向编解码模块4125下发用于进行多画面合成的多画面合成指令，同时向路由管理模块4122下发从媒体接收模块4123向编解码模块4125转发的路由任务。

step6，路由管理模块4122向媒体接收模块4123下发路由配置，以使媒体接收模块4123将其接收到的视频转发至编解码模块4125，而不再转发至媒体发送模块4124。

step7，控制服务器411中的会议控制模块4112在发送多画面合成指令的同时，可以向用户代理模块4114发送通知所有用户订阅合成多画面的指令。接着，用户代理模块4114可以将该指令转发至各个客户端430。这样，各个客户端430即可以只订阅一路画面而非订阅多路画面，并且在画面布局和内容变化时也不需要重新订阅，节约了带宽且减少了信令交互。

step8，各个客户端430均向媒体服务器412的信令控制模块4126发送订阅单路合成多画面的订阅请求(注：根据业务需要，客户端也可以不订阅服务器合成多画面，如手机端屏幕较小不适合服务器推送的画面，或视频教学场景学生看相同的画面但老师看一个特殊的画面)。

step9，媒体服务器412的信令控制模块4126对各个订阅请求进行处理，确定出观看方和被观看方等，并向路由管理模块4122下发路由配置请求。示例性的，路由配置请求可以用于请求配置编解码模块4125至媒体发送模块4124的路由，和/或，请求配置媒体发送模块4124到各个客户端430的路由等。

step10，路由管理模块4122向编解码模块4125下发到媒体发送模块4124的路由，并向媒体发送模块4124下发到用户侧的路由。

step11，媒体发送模块4124在获取到编解码模块4125发送的合成后的视频后，可以根据路由配置向用户发送合成后的单路多画面视频。最后，各个客户端430在接收到视频后，可以对该视频进行渲染，并进行显示。

(2)关闭多画面合成的流程

在启动合成多画面后，当会议人数降低到关闭阈值时，控制服务器411将推送关闭合成多画面消息，执行退出流程。

示例性的，如图7所示，step1，管理员可以预先在会议控制服务器411的系统配置模块4111中设置合成多画面的参数，比如：配置启动合成多画面的人数和关闭合成多画面的人数等。当然，这些参数也可以是默认的，具体可根据实际情况而定。

step2，主持人可以通过其所使用的客户端向用户代理模块4114下发多画面指令，即启动广播多画面，要求所有用户观看其所指定的多个用户的画面。接着，用户代理模块4114可以将该指令转发至向会议控制模块4112。示例性的，多画面指令中可以包含多个画面的布局(即视频布局)和视频源(即被观看方的视频)的标识等。

step3，会议控制模块4112可以基于当前的会议人数和其从系统配置模块4111读取到的配置参数，计算是否启动合成多画面。当会议人数未达到启动合成多画面的人数时，其将向媒体任务调度模块4113下发停止多画面合成指令。在一些实施例中，当会议人数发生变化时，会议控制模块4112也需要执行此计算，判断是否应该启动或停止合成多画面，并把指令下发到媒体任务调度模块。在一些实施例中，当在step3之前未启动合成多画面时，若会议人数未达到启动合成多画面的人数，会议控制模块4112则保持现状即可，即不需要下发停止多画面合成指令。

step4，媒体任务调度模块4113可以向媒体服务器412中的媒体任务管理模块4121下发用于停止合成多画面的停止多画面合成指令。

step5，媒体任务管理模块4121向编解码模块4125下发用于进行停止多画面合成的停止多画面合成指令，同时向路由管理模块4122下发删除从媒体接收模块4123向编解码模块4125转发的路由任务，以及，删除编解码模块4125向媒体发送模块4124转发的路由任务。

step6，当有客户端430向媒体服务器412订阅视频时，路由管理模块4122可以向媒体接收模块4123下发路由配置。这样，当有客户端向媒体服务器412订阅视频时，可以使得媒体接收模块4123将其接收到的视频直接转发至媒体发送模块4124。

step7，控制服务器411中的会议控制模块4112在发送停止多画面合成指令的同时，可以向用户代理模块4114发送通知所有用户关闭订阅合成多画面的指令。接着，用户代理模块4114可以将该指令转发至各个客户端430。这样，各个客户端430即可以重新向媒体服务器412订阅多路视频。

step8，各个客户端430均向媒体服务器412的信令控制模块4126发送订阅多路视频的订阅请求。

step9，媒体服务器412的信令控制模块4126对各个订阅请求进行处理，确定出观看方和被观看方等，并向路由管理模块4122下发路由配置请求。示例性的，路由配置请求可以用于请求配置媒体发送模块4124到各个客户端430的路由等。

step10，路由管理模块4122向媒体发送模块4124下发到用户侧的路由。

step11，媒体发送模块4124在获取到媒体接收模块4123发送的视频后，可以根据路由配置向用户发送多路视频。最后，各个客户端430在接收到视频后，可以对这多路视频进行合成，并进行显示。

应理解的是，图6所示的启动多画面合成的流程和图7所示的关闭多画面合成的流程的各个步骤的顺序可以根据实际情况进行选择，此处不做限定。另外，这些步骤也可以根据实际需要进行选取。在一些实施例中，在图7中，若主持人在下发合成多画面的指令时，会议人数未达到系统配置模块4111中配置的启动人数，会议控制模块4112则可以不用与媒体任务调度模块4113交互，而只需通知各个客户端430订阅多路视频即可。也即是说，在默认状态下，可以是不进行视频合成。当然，在默认状态下，也可以是需要进行视频合成的，具体可根据实际情况而定。

由上述内容可知，本申请实施例提供的视频会议控制方法，通过根据会议人数动态开启和关闭服务器合成多画面，在会议人数少的时候采用多流模式(此时因会议人数少，多流模式总带宽不高且信令交互少，节省了服务器编码CPU)，在会议人数多的时候采用单流模式(会议人数多，单流模式虽然编制了一路合成画面，平均下来人均消耗的服务器CPU较低，但大大降低了带宽和信令交互)，既利用了两个方案的优点，也能避免两个方案的缺点。

另外，根据使用场景的不同，结合服务器CPU资源和带宽自定义的稀缺性，可以通过调整开启合成的会议人数和关闭合成的人数来最大化的利用资源。如公网场景，带宽资源较为昂贵，可以将会议人数调整的更小，内网场景，带宽资源更充裕，可以将开启合成的会议人数调整的更大。同时关闭合成的人数和开启人数可以留有足够的空间，以防止会议人数在开启阈值和关闭阈值不停变化时，出现合成画面频繁开启和关闭，对服务器和客户端产生不必要的信令交互。

在一些实施例中，在多个观看方同时观看相同的被观看方时，每个观看方均将向服务器发送一个用于订阅视频的订阅请求，无论是客户端订阅合成后的一路视频，还是订阅未合成的多路视频，服务器都需要对每个订阅请求依次进行处理。这样的处理效率较低，且服务器的压力较大。有鉴于此，本申请实施例在对订阅请求处理时，可以进行批量处理，以优化处理效率，减轻服务器压力。具体地，如图8所示，step1，管理员在媒体服务器412的系统配置模块4127中配置打包处理订阅请求的间隔和数量，如20ms或订阅请求达到100个，媒体服务器412就开始批量处理这些订阅请求。管理员通过配置模块设置这些参数，信令控制模块4126在读取到配置后，即可以通过这些配置控制批量处理的时间和数量。

step2，主持人在会议控制服务器411启动广播多画面(或其他要求客户端观看统一画面内容的指令)。其中，主持人可以使用其客户端向会议控制服务器411中的用户代理模块4114下发多画面指令，即启动广播多画面，要求所有用户观看其所指定的多个用户的画面。接着，用户代理模块4114可以将该指令转发至向会议控制模块4112。示例性的，多画面指令中可以包含多个画面的布局(即视频布局)和视频源(即被观看方的视频)的标识等。

step3，控制服务器411中的会议控制模块4112向用户代理模块4114下发客户端观看布局及内容；之后，用户代理模块4112可以向所有用户或者是主持人所指定的一部分用户下发观看指令。该观看指令中可以包括视频布局(比如25画面、16画面等)和视频源(即被观看方的视频)的标识。

step4，每个客户端430均根据观看指令下发的视频布局视频内容，组装订阅请求，并根据订阅请求的视频源的流标识(比如视频源所属的用户，视频源的分辨率等)，计算出一个hash值，以及将携带有该hash值的订阅请求发送至信令控制模块4126。示例性的，观看指令中的每个视频源的标识均可以对应一个子订阅请求，每个客户端430可以将各个子订阅请求进行拼接，以得到订阅请求。由于每个子订阅请求均相同，且不同客户端430得到的视频源的流标识也均相同，因此不同客户端430计算出的hash值也相同。当然，hash值也可以替换为其他的能够表征这些订阅请求是同一请求的值也可以。

step5，信令控制模4126收到订阅请求后，不会立即处理，而是把拥有相同hash值的请求分类放在缓存中。

step6，信令控制模块4126在积攒的请求数量或距离上次处理的时间达到阈值后统一处理，将所有请求组装为批量的路由配置下发到路管理模块，通过这种方式，减少了信令控制模块和路由管理的交互，路由管理通过批量处理也提高了路由配置的效率。

由此，本申请实施例通过在订阅请求加入一个hash值作为订阅请求的合并条件，可以将短时间大量的订阅请求中快速识别出来相似的请求，将相似请求汇总批量处理，提高订阅请求的处理效率和降低服务器性能压力。另外，批量处理的间隔和数量，需要配置为一个合适的值，间隔过长或数量过多，会导致客户端等待时间过长，影响用户体验，时间过短或数量过少，容易导致汇总的请求数量太少，批量处理的效益不明显。

以上即是对本申请实施例提供的视频会议控制系统等相关的介绍。接下来，基于上文所描述的内容，对本申请实施例提供的视频会议控制方法进行介绍。

示例性的，图9示出了一种视频会议控制方法。可以理解，该方法可以通过任何具有计算、处理能力的装置、设备、平台、设备集群来执行。为便于描述，下面以前述所描述的云服务器执行为例进行描述。如图9所示，该视频会议控制方法，可以包括：

S901、在目标场景下，获取参加视频会议的会议人数，目标场景为多个观看方同时观看多个被观看方的画面的场景。

本实施例中，在多个观看方同时观看多个被观看方的画面的场景下，云服务器可以获取参加视频会议的会议人数。其中，在进行视频会议时，每个进入或退出会议的人所使用的客户端均会告知云服务器，这样，云服务器即可以获知到当前正在参见会议的人数，以及各个参会人员都是谁。

在一些实施例中，云服务器在获取到第一客户端发送的第一指令后，若第一指令为要求多个观看方同时观看多个被观看方的画面的指令，其则可以确定当前的会议场景为目标场景。示例性的，第一客户端可以为前述所描述的主持人所使用的客户端420。示例性的，第一客户端可以是为浏览器或者APP。

S902、在会议人数大于第一预设人数的情况下，将从各个被观看方的客户端处获取到的多路视频合成为一路视频，并将一路视频分别发送至各个观看方的客户端。

本实施例中，在会议人数大于第一预设人数的情况下，云服务器可以将从各个被观看方的客户端处获取到的多路视频合成为一路视频，并将一路视频分别发送至各个观看方的客户端。即在会议人数大于一定人数的情况下，可以使用单流模式，以用消耗一定计算资源的代价，节省更多的带宽资源。示例性的，观看方的客户端和被观看方的客户端均可以为前述所描述的客户端430。

在一些实施例中，云服务器可以包括第一服务器和第二服务器。其中，在将一路视频分别发送至各个观看方的客户端之前，第一服务器可以通知各个观看方的客户端向第二服务器订阅合成视频，以及通知第二服务器将从各个被观看方的客户端处获取到的多路视频合成为一路视频。第二服务器获取各个被观看方的客户端发送的用于订阅合成视频的订阅请求，以及，将从各个被观看方的客户端处获取到的多路视频合成为一路视频。示例性的，第一服务器可以为前述所描述的会议控制服务器411，第二服务器可以为前述所描述的媒体服务器412。

S903、在会议人数小于第二预设人数的情况下，将从各个被观看方的客户端处获取到的多路视频均分别发送至各个观看方的客户端，其中，第二预设人数小于或等于第一预设人数。

本实施例中，在会议人数小于第二预设人数的情况下，云服务器可以直接将从各个被观看方的客户端处获取到的多路视频均分别发送至各个观看方的客户端，其中，第二预设人数小于或等于第一预设人数。即在会议人数小于一定人数的情况下，可以使用多流模式，节省服务器编码资源。在一些实施例中，云服务器可以包括第一服务器和第二服务器。其中，在将通过各个被观看方的客户端处获取到的多路视频均分别发送至各个观看方的客户端之前，第一服务器可以通知各个观看方的客户端向第二服务器订阅各个被观看方的视频；第二服务器可以获取各个被观看方的客户端发送的用于订阅各个被观看方的视频的订阅请求。示例性的，第一服务器可以为前述所描述的会议控制服务器411，第二服务器可以为前述所描述的媒体服务器412。

由此，通过根据会议人数动态开启和关闭服务器合成多画面，在会议人数少的时候采用多流模式(此时因会议人数少，多流模式总带宽不高且信令交互少，节省了服务器编码CPU)，在会议人数多的时候采用单流模式(会议人数多，单流模式虽然编制了一路合成画面，平均下来人均消耗的服务器CPU较低，但大大降低了带宽和信令交互)，既利用了两个方案的优点，也避免了两个方案的缺点。

在一些实施例中，在S902和S903中所描述的第二服务器，其在获取到订阅请求之后，还可以获取各个订阅请求中携带的目标值，该目标值可以用于表征订阅请求所订阅的多路视频。以及，在目标值的数量达到预设值或者距离前次处理订阅请求的时间达到预设时间的情况下，进行路由配置，路由配置用于配置第二服务器与各个观看方间的路由。即第二服务器可以批量处理订阅请求，由此以提高订阅请求的处理效率和降低服务器性能压力。

在一些实施例中，在图9中，云服务器还可以获取第二客户端发送的第二指令，第二指令用于配置第一预设人数和/或第二预设人数；以及，基于第二指令，配置第一预设人数和第二预设人数。示例性的，第二客户端可以为前述所描述的管理员对会议控制服务器411进行配置时所使用的客户端。示例性的，第二客户端可以是为浏览器或者APP。

基于上述实施例中的方法，本申请实施例还提供了一种视频会议控制系统。该系统可以

包括：云服务器和与会人员所使用的客户端。其中，云服务器，用于在目标场景下，获取参5加视频会议的会议人数，目标场景为多个观看方同时观看多个被观看方的画面的场景。云服

务器，还用于在会议人数大于第一预设人数的情况下，将从各个被观看方的客户端处获取到的多路视频合成为一路视频，并将一路视频分别发送至各个观看方的客户端。云服务器，还用于在会议人数小于第二预设人数的情况下，将从各个被观看方的客户端处获取到的多路视频均分别发送至各个观看方的客户端，其中，第二预设人数小于或等于第一预设人数。

0在一些实施例中，云服务器包括第一服务器和第二服务器。在会议人数大于第一预设人

数的情况下，第一服务器用于通知各个观看方的客户端向第二服务器订阅合成视频，以及，

通知第二服务器将从各个被观看方的客户端处获取到的多路视频合成为一路视频。第二服务器用于获取各个被观看方的客户端发送的用于订阅合成视频的订阅请求，以及，将从各个被观看方的客户端处获取到的多路视频合成为一路视频。

5在一些实施例中，云服务器包括第一服务器和第二服务器。在会议人数小于第二预设人

数的情况下，第一服务器用于通知各个观看方的客户端向第二服务器订阅各个被观看方的视频。第二服务器用于获取各个被观看方的客户端发送的用于订阅各个被观看方的视频的订阅请求。

在一些实施例中，第二服务器在获取到订阅请求之后，还用于：获取各个订阅请求中携0带的目标值，目标值用于表征订阅请求所订阅的多路视频；在目标值的数量达到预设值或者

距离前次处理订阅请求的时间达到预设时间的情况下，进行路由配置，路由配置用于配置第二服务器与各个观看方间的路由。

在一些实施例中，云服务器，还用于：获取第一客户端发送的第一指令；在第一指令为

要求多个观看方同时观看多个被观看方的画面的情况下，确定当前的会议场景为目标场景。5在一些实施例中，云服务器，还用于：获取第二客户端发送的第二指令，第二指令用于

配置第一预设人数和/或第二预设人数；基于第二指令，配置第一预设人数和第二预设人数。

本申请还提供一种计算设备1000。如图10所示，计算设备1000包括：总线1002、处理

器1004、存储器1006和通信接口1008。处理器1004、存储器1006和通信接口1008之间通0过总线1002通信。计算设备1000可以是服务器或终端设备。应理解，本申请不限定计算设

备1000中的处理器、存储器的个数。

总线1002可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extended industry standard architecture，EISA)总线等。总线可

以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一条线表示，但并不表5示仅有一根总线或一种类型的总线。总线1004可包括在计算设备1000各个部件(例如，存

储器1006、处理器1004、通信接口1008)之间传送信息的通路。

处理器1004可以包括中央处理器(central processing unit，CPU)、图形处理器(graphics processing unit，GPU)、微处理器(micro processor，MP)或者数字信号处理器(digital signal processor，DSP)等处理器中的任意一种或多种。

0存储器1006可以包括易失性存储器(volatile memory)，例如随机存取存储器(randomaccess memory，RAM)。处理器104还可以包括非易失性存储器(non-volatilememory)，例如只读存储器(read-only memory，ROM)，快闪存储器，机械硬盘(hard diskdrive，HDD)或固态硬盘(solid state drive，SSD)。

存储器1006中存储有可执行的程序代码，处理器1004执行该可执行的程序代码以分别实现前述所描述的各个模块的功能，从而实现上述实施例中方法的全部或部分步骤。也即，存储器1006上存有用于执行上述实施例方法中全部或部分步骤的指令。

或者，存储器1006中存储有可执行的代码，处理器1004执行该可执行的代码以分别实现前述所描述的视频会议控制系统的功能，从而实现上述实施例方法中全部或部分步骤。也即，存储器1006上存有用于执行上述实施例方法中全部或部分步骤的指令。

通信接口1003使用例如但不限于网络接口卡、收发器一类的收发模块，来实现计算设备1000与其他设备或通信网络之间的通信。

本申请实施例还提供了一种计算设备集群。该计算设备集群包括至少一台计算设备。该计算设备可以是服务器，例如是中心服务器、边缘服务器，或者是本地数据中心中的本地服务器。在一些实施例中，计算设备也可以是台式机、笔记本电脑或者智能手机等终端设备。

如图11所示，所述计算设备集群包括至少一个计算设备1000。计算设备集群中的一个或多个计算设备1000中的存储器1006中可以存有相同的用于执行上述实施例方法中全部或部分步骤的指令。

在一些可能的实现方式中，该计算设备集群中的一个或多个计算设备1000的存储器1006中也可以分别存有用于执行上述实施例方法中全部或部分步骤的部分指令。换言之，一个或多个计算设备1000的组合可以共同执行用于执行上述实施例方法中全部或部分步骤的指令。

需要说明的是，计算设备集群中的不同的计算设备1000中的存储器1006可以存储不同的指令，分别用于执行前述视频会议控制系统的部分功能。也即，不同的计算设备1000中的存储器1006存储的指令可以实现前述各个模块中的一个或多个模块的功能。

在一些可能的实现方式中，计算设备集群中的一个或多个计算设备可以通过网络连接。其中，所述网络可以是广域网或局域网等等。

基于上述实施例中的方法，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，当计算机程序在处理器上运行时，使得处理器执行上述实施例中的方法。

基于上述实施例中的方法，本申请实施例提供了一种计算机程序产品，当计算机程序产品在处理器上运行时，使得处理器执行上述实施例中的方法。

可以理解的是，本申请的实施例中的处理器可以是中央处理单元(centralprocessing unit，CPU)，还可以是其他通用处理器、数字信号处理器(digital signalprocessor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现场可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、晶体管逻辑器件，硬件部件或者其任意组合。通用处理器可以是微处理器，也可以是任何常规的处理器。

本申请的实施例中的方法步骤可以通过硬件的方式来实现，也可以由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成，软件模块可以被存放于随机存取存储器(random access memory，RAM)、闪存、只读存储器(read-only memory，ROM)、可编程只读存储器(programmable rom，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)、寄存器、硬盘、移动硬盘、CD-ROM或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当

使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包5括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产

生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者通过所述计算机可读存储介质进行传输。所述计算机指令可以从一个网站站点、计算机、服务

器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无0线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可

读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。

可以理解的是，在本申请的实施例中涉及的各种数字编号仅为描述方便进行的区分，并5不用来限制本申请的实施例的范围。

Claims (16)

1.一种视频会议控制方法，其特征在于，应用于云服务器，所述方法包括：

在目标场景下，获取参加视频会议的会议人数，所述目标场景为多个观看方同时观看多个被观看方的画面的场景；

在所述会议人数大于第一预设人数的情况下，将从各个所述被观看方的客户端处获取到的多路视频合成为一路视频，并将所述一路视频分别发送至各个所述观看方的客户端；

在所述会议人数小于第二预设人数的情况下，将从各个所述被观看方的客户端处获取到的多路视频均分别发送至各个所述观看方的客户端，其中，所述第二预设人数小于或等于所述第一预设人数。

2.根据权利要求1所述的方法，其特征在于，所述云服务器包括第一服务器和第二服务器；

在将所述一路视频分别发送至各个所述观看方的客户端之前，所述方法还包括：

在所述会议人数大于所述第一预设人数的情况下，所述第一服务器通知各个所述观看方的客户端向所述第二服务器订阅合成视频，以及通知所述第二服务器将从各个所述被观看方的客户端处获取到的多路视频合成为一路视频；

所述第二服务器获取各个所述被观看方的客户端发送的用于订阅合成视频的订阅请求，以及，将从各个所述被观看方的客户端处获取到的多路视频合成为一路视频。

3.根据权利要求1所述的方法，其特征在于，所述云服务器包括第一服务器和第二服务器；

在将通过各个所述被观看方的客户端处获取到的多路视频均分别发送至各个所述观看方的客户端之前，所述方法还包括：

在所述会议人数小于所述第二预设人数的情况下，所述第一服务器通知各个所述观看方的客户端向所述第二服务器订阅各个所述被观看方的视频；

所述第二服务器获取各个所述被观看方的客户端发送的用于订阅各个所述被观看方的视频的订阅请求。

4.根据权利要求2或3所述的方法，其特征在于，所述第二服务器在获取到订阅请求之后，所述方法还包括：

获取各个所述订阅请求中携带的目标值，所述目标值用于表征所述订阅请求所订阅的多路视频；

在所述目标值的数量达到预设值或者距离前次处理所述订阅请求的时间达到预设时间的情况下，进行路由配置，所述路由配置用于配置所述第二服务器与各个所述观看方间的路由。

5.根据权利要求1-4任一所述的方法，其特征在于，所述方法还包括：

获取第一客户端发送的第一指令；

在所述第一指令为要求多个观看方同时观看多个被观看方的画面的情况下，确定当前的会议场景为所述目标场景。

6.根据权利要求1-5任一所述的方法，其特征在于，所述方法还包括：

获取第二客户端发送的第二指令，所述第二指令用于配置所述第一预设人数和/或所述第二预设人数；

基于所述第二指令，配置所述所述第一预设人数和所述第二预设人数。

7.一种视频会议控制系统，其特征在于，包括：云服务器和与会人员所使用的客户端；

其中，所述云服务器，用于在目标场景下，获取参加视频会议的会议人数，所述目标场景为多个观看方同时观看多个被观看方的画面的场景；

所述云服务器，还用于在所述会议人数大于第一预设人数的情况下，将从各个所述被观看方的客户端处获取到的多路视频合成为一路视频，并将所述一路视频分别发送至各个所述观看方的客户端；

所述云服务器，还用于在所述会议人数小于第二预设人数的情况下，将从各个所述被观看方的客户端处获取到的多路视频均分别发送至各个所述观看方的客户端，其中，所述第二预设人数小于或等于所述第一预设人数。

8.根据权利要求7所述的系统，其特征在于，所述云服务器包括第一服务器和第二服务器；

在所述会议人数大于所述第一预设人数的情况下，所述第一服务器用于通知各个所述观看方的客户端向所述第二服务器订阅合成视频，以及，通知所述第二服务器将从各个所述被观看方的客户端处获取到的多路视频合成为一路视频；

所述第二服务器用于获取各个所述被观看方的客户端发送的用于订阅合成视频的订阅请求，以及，将从各个所述被观看方的客户端处获取到的多路视频合成为一路视频。

9.根据权利要求7所述的系统，其特征在于，所述云服务器包括第一服务器和第二服务器；

在所述会议人数小于所述第二预设人数的情况下，所述第一服务器用于通知各个所述观看方的客户端向所述第二服务器订阅各个所述被观看方的视频；

所述第二服务器用于获取各个所述被观看方的客户端发送的用于订阅各个所述被观看方的视频的订阅请求。

10.根据权利要求8或9所述的系统，其特征在于，所述第二服务器在获取到订阅请求之后，还用于：

获取各个所述订阅请求中携带的目标值，所述目标值用于表征所述订阅请求所订阅的多路视频；

在所述目标值的数量达到预设值或者距离前次处理所述订阅请求的时间达到预设时间的情况下，进行路由配置，所述路由配置用于配置所述第二服务器与各个所述观看方间的路由。

11.根据权利要求7-10任一所述的系统，其特征在于，所述云服务器，还用于：

获取第一客户端发送的第一指令；

在所述第一指令为要求多个观看方同时观看多个被观看方的画面的情况下，确定当前的会议场景为所述目标场景。

12.根据权利要求7-11任一所述的系统，其特征在于，所述云服务器，还用于：

获取第二客户端发送的第二指令，所述第二指令用于配置所述第一预设人数和/或所述第二预设人数；

基于所述第二指令，配置所述所述第一预设人数和所述第二预设人数。

13.一种计算设备，其特征在于，包括：

至少一个存储器，用于存储程序；

至少一个处理器，用于执行所述存储器存储的程序；

其中，当所述存储器存储的程序被执行时，所述处理器用于执行如权利要求1-6任一所述的方法。

14.一种计算设备集群，其特征在于，包括至少一个计算设备，每个计算设备均包括处理器和存储器；

所述至少一个计算设备的处理器用于执行所述至少一个计算设备的存储器中存储的指令，以使得所述计算设备集群执行如权利要求1-6任一所述的方法。

15.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，当所述计算机程序在处理器上运行时，使得所述处理器执行如权利要求1-6任一所述的方法。

16.一种计算机程序产品，其特征在于，当所述计算机程序产品在处理器上运行时，使得所述处理器执行如权利要求1-6任一所述的方法。

Images