一种服务器、会场终端以及云会议处理方法与流程

本发明涉及视频会议通信领域，尤其涉及一种服务器、会场终端及云会议处理方法。

背景技术：

目前的云会议系统运行在公有云或私有云上，使用公有云或私有云召开视频会议会占用服务器的cpu，内存等资源，需要预约好资源(cpu核数/内存)。而现有技术中，服务器的cpu主要是用来对视频进行解码、编码处理的，在需要对所有端进行解码、编码(全编全解)的会议或多画面会议中，因为每个服务器cpu的核数是比较少的，能处理的码流数量相应的也比较少。例如，一个16核的cpu的服务器，可以虚拟出32个虚拟核，召开一组云视频会议则可以添加h.264编解码格式，720p(分辨率为：1280*720像素)高清的会场终端的数量为虚拟核的总数32个；添加h.264-4cif(分辨率为：704*576像素)标清能力的会场终端的数量为64个。可见云服务器的接入容量比较少，资源利用率也不高。针对该问题，现有技术中的解决方案一是直接增加服务器的cpu的核数，二是降低视频质量；对于第一个方案而言，最直观的无疑就是会增大生产成本，而且由于服务器的配置也是一直在提升中，因此该方案并不能从根本上解决问题；对于第二个方案而言，最直观的则是降低了用户体验。同样的也是治标不治本。

技术实现要素：

本发明提供了一种服务器、会场终端以及云会议处理方法，旨在解决现有技术中过度依赖服务器对视频编解码而导致的服务器的接入容量低，用户体验差的问题。

为了解决上述技术问题，本发明提供了一种云会议处理方法，包括如下步骤：

接收各个会场终端上报的本地视频码流；

针对各个会场终端，分别根据预设的规则确定向其下发的本地视频码流集合，所述本地视频码流集合至少包括一个所述本地视频码流；

将所述本地视频码流集合包括的本地视频码流发送给对应的所述的会场终端。

可选的，所述接收各个会场终端的本地视频码流时，还包括：

接收来自各个会场终端的第一音频码流；

将所述各个会场终端的第一音频码流处理后发送给各个会场终端。

可选的，所述将各个会场终端的第一音频码流处理后发送给各个会场终端包括：

将所述第一音频码流进行解码，得到至少一个音频；

对所述音频进行混音；

对所述混音后的音频进行编码，得到第二音频码流；

将所述第二音频码流发送给各个所述会场终端。

可选的，所述预设的规则包括：所述本地视频码流集合包括广播源的本地视频码流；

所述将本地视频码流集合包括的本地视频码流发送给对应的会场终端包括：将所述广播源的本地视频码流发送给对应的会场终端。

可选的，所述预设的规则还包括：接收所述会场终端的请求，所述本地视频码流集合包括所述会场终端请求的本地视频码流；

所述将本地视频码流集合包括的本地视频码流发送给对应的会场终端还包括：将所述会场终端请求的本地视频码流发送给所述会场终端。

进一步的，本发明还提供了一种云会议处理方法，包括如下步骤：

将会场终端的本地视频码流发送给服务器；

接收所述服务器下发的本地视频码流集合包括的所述本地视频码流；

对所述本地视频码流进行处理，得到视频。

可选的，所述接收所述服务器下发的本地视频码流集合包括的本地视频码 流包括：接收广播源的本地视频码流。

可选的，所述接收所述服务器下发的本地视频码流集合包括的本地视频码流还包括：向所述服务器发送请求；接收请求的本地视频码流。

可选的，在所述将会场终端的本地视频码流发送给服务器时，还包括：将所述会场终端的第一音频码流发送给所述服务器。

可选的，在所述将会场终端的第一音频码流发送给服务器之后，还包括：接收来自服务器的第二音频码流。

可选的，所述对本地视频码流进行处理，得到视频包括：对所述本地视频码流进行解码，得到至少一个子视频；将所述子视频进行合成，得到视频。

进一步的，本发明还提供了一种服务器，包括：

第一接收模块，用于接收各个会场终端上报的本地视频码流；

确定模块，用于针对各个会场终端，分别根据预设规则确定向其下发的本地视频码流集合，所述本地视频码流集合至少包括一个所述本地视频码流；

第一发送模块，用于将所述本地视频码流集合包括的本地视频码流发送给对应的所述的会场终端。

可选的，还包括第一音频接收模块和音频处理模块；所述第一音频接收模块用于接收来自各个会场终端的第一音频码流；所述音频处理模块用于将所述音频码流处理后发送给各个会场终端。

可选的，所述音频处理模块包括音频解码模块、混音模块、编码模块、第一音频发送模块；所述音频解码模块用于将所述第一音频码流进行解码，得到至少一个音频；所述混音模块用于对所述音频进行混音；所述编码模块用于对所述混音后的音频进行编码，得到第二音频码流；所述音频发送模块用于将所述第二音频码流发送给各个所述会场终端。

可选的，所述预设的规则包括：所述本地视频码流集合包括广播源的本地视频码流；所述第一发送模块包括视频发送模块，用于将广播源的本地视频码流发送给对应的会场终端.

可选的，所述预设的规则还包括：接收所述会场终端的请求，所述本地视频码流集合包括所述会场终端请求的本地视频码流；所述视频发送模块还用于 将所述会场终端请求的本地视频码流直接转发给所述会场终端。

进一步的，本发明还提供了一种会场终端，包括：

第二发送模块，用于将会场终端的本地视频码流发送给服务器；

第二接收模块，用于接收所述服务器下发的本地视频码流集合包括的所述本地视频码流；

视频处理模块，用于对所述本地视频码流进行处理，得到视频。

可选的，所述第二接收模块包括视频接收模块，用于接收广播源的本地视频码流。

可选的，所述第二接收模块还包括请求发送模块，用于向所述服务器发送请求；所述视频接收模块还用于接收请求的本地视频码流。

可选的，还包括第二音频发送模块，用于在将会场终端的本地视频码流发送给服务器时，将所述会场终端的第一音频码流发送给所述服务器。

可选的，还包括第二音频接收模块，用于接收来自服务器的第二音频码流。

可选的，所述视频处理模块包括视频解码模块和合成模块，所述解码模块用于对所述本地视频码流进行解码，得到至少一个子视频；所述合成模块用于将所述子视频进行合成，得到视频。

有益效果：

本发明提供了一种服务器、会场终端及云会议处理方法，服务器接收各个会场终端发送的本地视频码流，然后针对各个会场终端，分别根据预设的规则确定向其下发的本地视频码流集合，本地视频码流集合至少包括一个本地视频码流；将所述本地视频码流集合包括的本地视频码流发送给对应的所述的会场终端；会场终端接收服务器下发的本地视频码流集合包括的本地视频码流，并对该本地视频码流进行处理，得到视频。克服了现有技术中的由服务器对本地视频码流进行处理而导致的服务器的cpu和内存的占用高，进而使得服务器的接入容量低的问题，大大提升了服务器的会场终端接入量，且保证了用户体验。

附图说明

图1是本发明实施例提供的一种云会议处理方法流程图；

图2是本发明实施例提供的一种云会议处理方法流程图；

图3是本发明实施例提供的一种云会议处理方法流程图；

图4是本发明实施例提供的一种云会议处理方法流程图；；

图5是本发明实施例提供的一种服务器的模块示意图；

图6是本发明实施例提供的一种会场终端的模块示意图。

具体实施方式

本发明的构思在于：将本来由服务器来完成的本地视频码流的解码、合成等操作，改由会场终端来进行，且根据不同的会场终端的需求可以自行订制，服务器免去了对本地视频码流的解码合成操作，从而节约了服务器的cpu和内存资源，使得影响服务器的接入容量由服务器的配置改为了服务器的网口总带宽，从而大大提升了服务器的接入容量。

下面结合附图对本发明的具体实施方式作进一步说明。

本实施例提供了一种云会议处理方法，请参考图1，包括：

s101、接收各个会场终端上报的本地视频码流；

s102、针对各个会场终端，分别根据预设的规则确定向其下发的本地视频码流集合，本地视频码流集合至少包括一个本地视频码流；

s103、将本地视频码流集合包括的本地视频码流发送给对应的会场终端。

在进行云会议时，各个会场终端均需要将自己的本地视频码流发送给服务器。此时，服务器已经不再对各个会场终端所发送的本地视频码流进行解码合成等处理，而是针对各个会场终端，分别根据预设的规则确定向其下发的本地视频码流集合，而本地视频码流集合至少包括一个本地视频码流；然后再根据确定的向会场终端下发的本地视频码流集合，将该本地视频码流集合包括的本地视频码流发送给各个会场终端，可以有效的节约服务器的资源，让各个会场终端对本地视频码流的处理进行分担。服务器发送本地视频码流是各个会场终端分别发送的，各个会场终端之间也不会有干扰。由于与会的会场终端并不止一个，因此，会场终端的本地视频码流也会有很多；所以，步骤s103中的分别 的含义，就是各个会场终端所需的本地视频码流很可能不止一个，那么就将该会场终端所需的本地视频码流分别进行转发；服务器将接收到的各个会场终端的本地视频码流，不加处理的直接转发，转发给各个会场终端的所需的本地视频码流是各个会场终端发送给服务器的原始本地视频码流。本地视频码流集合，是指各个终端上报给服务器的本地视频码流的集合，这个集合是原始的本地视频码流的集合，而各个会场终端所对应的本地视频码流集合中所包括的本地视频码流可能是相同的，也可能是部分相同的，或者是各不相同。

上述的预设的规则，可以包括：将广播源的本地视频码流，作为本地视频码流集合中的一部分，即本地视频码流集合包括广播源的本地视频码流；还可以包括，接收会场终端的请求，将会场终端请求的本地视频码流作为本地视频码流集合中的一部分，即本地视频码流集合包括会场终端请求的本地视频码流。

一般而言，发送给某一个会场终端的本地视频码流应该是不同于该会场终端的本地视频码流，当然，该会场终端自己的本地视频码流是无须从服务器接收的；在云会议中，任何会场终端至少应该有一个会场终端的画面，更多的时候可以有多个画面。由于与会的会场终端数目并不是唯一的，而各个会场终端并不是都需要看到所有的会场终端，有的会场终端出于突出重点的考虑，可能只会查看某一个会场终端的视频，有的会场终端又可能为了多看看其他会场终端的画面而选择查看所有会场终端的视频，因此，服务器所需要的是，根据不同的会场终端的需求，将这些会场终端需要的那些会场终端的本地视频码流发送给这些会场终端。

在云会议中，常常会有广播源，广播源也是会场终端中的一个，即整个云会议的大局由这个会场终端来掌控，因此，往往需要将这个会场终端的本地视频码流发送到每一个会场终端，那么，此时，本地视频码流集合包括广播源的本地视频码流，就需要将广播源的本地视频码流直接转发给其他每一个会场终端；此外，广播源在会议中也需要有指向的看某个或者某些会场终端，相应的，需要将这些会场终端的本地视频码流发送给广播源；广播源可以看其他的会场终端，也可以看广播源自己，广播源所看的会场终端，就称为广播源看的端；在一个云会议中，往往会有这两个比较特殊的会场终端，其中，广播源的本地视频码流需要发送给每个会场终端，而广播源看的端需要发送给广播源。当然，广播源看的端在一次云会议中是可以变化的，而且可能会经常性的变化，这个 并不影响本方案的实施。此外，出于各种原因，广播源本身在一次云会议中也是可能变化的，在广播源变化之后，也应该将变化后的广播源的本地视频码流发送给各个会场终端。

各个会场终端在云会议中的任何时候，不论是刚开始，或者在会议中，都可以向服务器发送请求，这个请求至少包括该会场终端需要看的会场终端，也即是说，各个会场终端向服务器发送包括需要看的会场终端的请求；服务器则根据该请求，确定该会场终端所需的本地视频码流，即本地视频码流集合包括会场终端请求的本地视频码流，并向该会场终端发送相应的本地视频码流。也即是说，各个会场终端至少应该接收广播源的本地视频码流，此外，还可以接收其他会场终端的本地视频码流。

服务器在接收各个会场终端的本地视频码流时，相应的，也会接收各个会场终端的第一音频码流；在接收各个会场终端的第一音频码流时，诚然，服务器也可以直接将各个会场终端的第一音频码流发送给各个会场终端进行处理，然而，由于音频的处理与视频的处理相比其占用的服务器的cpu和内存较低，因此没有必要；此外，从实际出发，由于各个与会的会场终端在会议中并不需要看到每个会场终端的画面，但是一般需要听到所有会场终端的声音，这样才能使的会议能够正常进行。若会场终端选择性的对第一音频码流流进行接收，则会导致该会场终端错过某些其他会场终端的发言，若错过的发言特别重要的话，则会直接影响此次会议的质量。因此，本实施例中的各个会场终端所发送的第一音频码流，服务器直接对该第一音频码流进行处理，然后发送给各个会场终端。而对各个会场终端所发送的第一音频码流进行处理包括：对第一音频码流进行解码，得到至少一个音频；对该音频进行混音；将混音后的音频进行编码，得到第二音频码流；将第二音频码流发送给各个会场终端。其中，对各个会场终端发送的第一音频解码和/或第二音频编码可以包括波形编解码、参数编解码以及混合编解码中的任何可行的方式；波形编解码包括pcm(pulsemodemodulation，脉冲编码调制)、adpcm(adaptivedifferencepulsecodemodulation，自适应差分脉冲编码调制)、sb-adpcm(subbandadaptivedifferentialpulsecodemodulation，子带-自适应差分脉冲编码)等等编解码方式，参数编解码包括lpc(linearpredictivecoding，线性预测编码)等编解码方式，混合编解码包括celpc(codeexcitedlinearpredictivecoding，码激励线性预测编码)、vslpc(vectorsumexcitedlinearpredictivecoding， 矢量和激励线性预测编码)、rpe-ltp(regularpulseexcited-longtermpredictive，规则脉冲激励长时预测)、ld-celp(lowdelay-codeexcitedlinearpredictive，低时延码激励线性预测)、mpe(multi-pulseexcited，多脉冲激励)等等编解码方式。对音频进行混音(audiomixing，常简称为mix)是音频处理中的一个步骤，是把多种来源的声音，整合为一个声音。本实施例中的各个音频来自不同的会场终端，在混音过程中，会将每一个音频的频率、动态、音质、定位、残响和声场单独进行调整，让各音轨最佳化，之后再叠加于最终成品上。这种处理方式，能制作出层次分明的音频效果。混音可以由混音软件来进行处理。对混音后的音频再进行编码，就可以发送给各个会场终端。服务器可以对所有音频均进行处理，但在某些情况下，服务器也可以选择性的对各个会场终端的音频码流进行处理，这可能是因为该会场终端不需要说话，或者由广播源进行调配，采用有序发言的方式等等。

本实施例提供了一种云会议处理方法，请参考图2，包括：

s201、将会场终端的本地视频码流发送给服务器；

s202、接收服务器下发的本地视频码流集合包括的本地视频码流；

s203、对本地视频码流进行处理，得到视频。

在云会议中，每一个加入云会议的会场终端都应该将各自的本地视频码流发送给服务器。虽然各个云服务器处在同一个云会议中，但各个会场终端发送本地视频码流的过程是独立的，即各个会场终端是分别将各自的本地视频码流发送给服务器，同样的，各个会场终端接收服务器的至少一个其他会场终端的本地视频码流的过程也是独立的，各个会场终端之间不会互相干扰。

接收服务器下发的本地视频码流集合包括的本地视频码流指的是，在云会议中，服务器接收了各个会场终端分别发送的本地视频码流，然后将本地视频码流分别发送给各个会场终端；各个会场终端所要接收的本地视频码流应该是其他会场终端的本地视频码流，而无须接收会场终端自己的本地视频码流；本地视频码流集合包括的本地视频码流，一般而言，是指在云会议中，任何会场终端至少应该有一个会场终端的画面，更多的时候有多个画面。由于与会的会场终端数目并不是唯一的，而各个会场终端并不是都需要看到所有的会场终端，有的会场终端出于突出重点的考虑，可能只会查看某一个会场终端的视频，有 的会场终端又可能为了多看看其他会场终端的画面而选择查看所有会场终端的视频，因此，服务器所需要的是，根据不同的会场终端的需求，将这些会场终端需要的那些会场终端的本地视频码流发送给这些会场终端。本地视频码流集合，是指各个终端上报给服务器的本地视频码流的集合，这个集合是原始的本地视频码流的集合，而各个会场终端所对应的本地视频码流集合中所包括的本地视频码流可能是相同的，也可能是部分相同的，或者是各不相同。

在云会议中，常常会有广播源，广播源也是会场终端中的一个，即整个云会议的大局由这个会场终端来掌控，因此，往往需要将这个会场终端的本地视频码流发送到每一个会场终端，那么，此时，各个会场终端就需要接收广播源的本地视频码流，即本地视频码流集合包括广播源的本地视频码流；当然，这里的接收还是由服务器所发送的；此外，广播源在会议中也需要有指向的看某个或者某些会场终端，相应的，需要将这些会场终端的本地视频码流发送给广播源，也就是说广播源需要接收广播源看的端的本地视频码流；广播源可以看其他的会场终端，也可以看广播源自己，广播源所看的会场终端，就称为广播源看的端；在一个云会议中，往往会有这两个比较特殊的会场终端，其中，广播源的本地视频码流需要发送给每个会场终端，而广播源看的端需要发送给广播源。当然，广播源看的端在一次云会议中是可以变化的，而且可能会经常性的变化，这个并不影响本方案的实施。此外，出于各种原因，广播源本身在一次云会议中也是可能变化的，在广播源变化之后，也应该将变化后的广播源的本地视频码流发送给各个会场终端。

各个会场终端在云会议中的任何时候，不论是刚开始，或者在会议中，都可以向服务器发送请求，这个请求至少包括该会场终端需要看的会场终端，也即是说，各个会场终端向服务器发送包括需要看的会场终端的请求；服务器则根据该请求向该会场终端发送相应的本地视频码流。本地视频码流集合包括会场终端请求的本地视频码流。也即是说，各个会场终端至少应该接收广播源的本地视频码流，此外，还可以接收其他会场终端的本地视频码流。

在接收到至少一个本地视频码流后，就可以对本地视频码流进行处理，处理的过程包括：对本地视频码流进行解码，得到至少一个子视频；然后对子视频执行合成操作，得到视频。会场终端接收的本地视频码流，包括广播源在内，可能有多个，会场终端对这多个本地视频码流进行解码；视频的编解码的格式 主要有以下几种：h.261、h.263、h.264，采用任何一种格式均可。将各个本地视频码流解码后，得到了至少一个子视频，就可以根据会场终端自己的意愿对各个子视频进行合成。合成后的视频的画面版式可以是任意的，一些常用的合成后的画面版式可以是：其一，对应各个会场终端的子视频按照同样的大小在画面中均匀分布；其二，以其中一个子视频为主视频，使其画面最大，其他的子视频作为从视频，画面分布在主画面的周围，其中，主视频可以以广播源作为主视频，或者此时云会议中主要发言的会场终端的视频作为主视频；其三，合成后的视频的画面可以是动态的，如谁发言谁的视频画面就相应的放大，显得比较突出。采用以上任何的方式或者其他未提及的合成方式在本实施例中均是适用的，只要其能够让该会场终端上的视频正常显示给与会的用户看即可。这样，将本地视频码流的解码合成的处理过程转到相应的会场终端来处理，由于各个会场终端的处理是独立的，不仅可以依照各个会场终端私人订制，有很好的用户体验，还减少了服务器端的cpu和内存使用，使得服务器可以接入更多的会场终端，从而可以提高会议的效率。

在发送会场终端的本地视频码流给服务器的同时，还可以将各个会场终端的第一音频码流发送给服务器。在发送各个会场终端的第一音频码流时，诚然，会场终端也可以采用类似本地视频码流的处理方式对音频码流进行处理，但是音频码流有其特殊性，音频的处理与视频的处理相比，音频处理所占用的服务器的cpu和内存较低，因此没有必要；此外，从实际出发，由于各个与会的会场终端在会议中并不需要看到每个会场终端的画面，但是一般需要听到所有会场终端的声音，这样才能使得会议能够正常进行。因此，各个会场终端将第一音频码流发送给服务器后，服务器对其进行处理，得到第二音频码流，然后将第二音频码流发送给每个会场终端。服务器对第一音频码流的处理与以上实施例中的一致，这里不再赘述。

本实施例提供了一种云会议处理方法，请参考图3，包括：

s301、服务器将与会会场终端t1-tn呼叫加入会议；

云会议的发起者一般就是广播源，广播源通过服务器发起呼叫，建立云会议。

s302、各个会场终端t1-tn加入会议，并将本地视频码流、第一音频码流 发给服务器；

各个收到会议请求的会场终端在加入会议时，就将各自的本地视频码流、音频码流发送给服务器。

s303、服务器确定tx会场终端为会议广播源；ty会场终端为广播源会场终端tx看的端；

由于各个与会的会场终端在会议中至少需要广播源的画面，因此服务器需要确定哪个是广播源；由于广播源是会议的发起者，此步骤也可以在一开始就进行。

s304、服务器将收到的会议广播源tx的本地视频码流不进行编解码处理直接透传、转发给入会的t1-tn会场终端；将收到的ty会场终端的本地视频码流转发给广播源tx会场终端。同时云服务器将各会场终端发来的第一音频码流进行解码、混音再编码后形成第二音频码流，再重新发回给所有会场终端；

服务器已经不再对各个会场终端所发送的本地视频码流进行解码合成等处理，而是直接分别将不同于各个会场终端的至少一个其他会场终端的本地视频码流发送给各个会场终端，可以有效的节约服务器的资源，让各个会场终端对本地视频码流的处理进行分担。

广播源的本地视频码流应该发送给每一个其他的会场终端，即t1-tn中除了tx的会场终端；广播源看的端ty的本地视频码流则发送给广播源。

与此同时，服务器也接收来自各个会场终端的第一音频码流，对该第一音频码流进行解码处理，得到至少一个音频；对这些音频进行混音；然后将混音后的音频进行编码，得到第二音频码流，再将第二音频码流发送给每个会场终端。

s305、如果没有收到会场终端的请求，则继续保持s304的流程；

服务器此时已经将广播源的本地视频码流发送给了各个会场终端，第二音频码流也已经发送给了各个会场终端；若会场终端没有查看其他会场终端的画面的需求，那么，此时服务器就继续进行s304的步骤，继续云会议。

s306、当收到会场终端发送过来的请求，服务器会场终端请求的内容中判断该会场终端请求的是哪个/哪些会场终端的本地视频码流；

当会场终端想查看某些会场终端的画面时，会场终端就向服务器发送一个 请求，服务器则根据该请求确认该会场终端想要看的是哪个/哪些会场终端的本地视频码流。

s307、服务器将相应的本地视频码流发送给该会场终端。

服务器确认了该会场终端需要看的会场终端的本地视频码流之后，就可以将该本地视频码流发送给该会场终端；之后，就由该会场终端对该本地视频码流进行处理，从而得到所需的视频画面。

本实施例提供了一种云会议处理方法，请参考图4，包括：

s401、本会场终端收到入会请求；

此时，广播源发起了云会议，相应的会场终端则需要入会。

s402、本会场终端加入会议，并将本地的本地视频码流、第一音频码流编码后发给服务器；

本会场终端在加入会议时，就将本会场终端的本地视频码流、第一音频码流发送给服务器；本地视频码流和第一音频码流都是通过编码而成的，根据各自的编码格式。

s403、本会场终端收到云服务器发送过来的广播源的本地视频码流和第二音频码流；同时收到与会的会场终端列表；

广播源的本地视频码流需要每个会场终端均接收，也就是说广播源的画面每个会场终端都需要看到；服务器在接收各个会场终端发送的第一音频码流之后，就对该音频码流进行处理，包括解码、混音再编码，然后发送给各个会场终端。

本会场终端除了需要接收广播源的本地视频码流以及第二音频码流之外，还应该得知与会的会场终端情况，这样才能决定是否看其他的会场终端。

s404、本会场终端分别对接收到的本地视频码流和第二音频码流进行处理，形成视频和音频；

会场终端此时接收到的本地视频码流是广播源的本地视频码流；对本地视频码流的处理包括解码，再合成；当只有一个本地视频码流时，无须进行合成操作，直接对本地视频码流进行解码就可以得到视频了；第二音频码流是各个 会场终端的第一音频码流在服务器端处理所得，解码后，本会场终端就可以得到各个会场终端合成后的音频。

s405、如果不向服务器发送请求，本会场终端保持步骤s403、s404；

如果本会场终端没有多画面的需求，此时仅仅需要保持看广播源的画面即可。

s406、本会场终端向服务器发送请求，先从与会的会场终端列表中确定需要看那些会场终端的画面；然后将请求消息发给服务器，请求中包含需要看的会场终端的列表；

若本会场终端需要看其他的会场终端的图像，首先，确定需要看的会场终端是哪些；然后，将体现这些会场终端的列表发送给服务器。

s407、云服务器从会场终端的请求中的会场终端的列表中找出对应的会场终端，并将这些会场终端的本地视频码流流转发给本会场终端；

s408、本会场终端收到这些本地视频码流流后分别进行解码，再合成为多画面，输出到显示设备上。

本实施例提供了一种服务器，请参考图5，包括：

第一接收模块101，用于接收各个会场终端上报的本地视频码流；

确定模块105，用于针对各个会场终端，分别根据预设的规则确定向其下发的本地视频码流集合，本地视频码流集合至少包括一个本地视频码流；

第一发送模块102，用于将本地视频码流集合包括的本地视频码流发送给对应的会场终端。

在进行云会议时，各个会场终端均需要将自己的本地视频码流发送给服务器。此时，服务器已经不再对各个会场终端所发送的本地视频码流进行解码合成等处理，而是针对各个会场终端，分别根据预设的规则确定向其下发的本地视频码流集合，而本地视频码流集合至少包括一个本地视频码流；然后再根据确定的向会场终端下发的本地视频码流集合，将该本地视频码流集合包括的本地视频码流发送给各个会场终端，可以有效的节约服务器的资源，让各个会场终端对本地视频码流的处理进行分担。服务器发送本地视频码流是各个会场终 端分别发送的，各个会场终端之间也不会有干扰。由于与会的会场终端并不止一个，因此，会场终端的本地视频码流也会有很多；所以，第一发送模块102中的分别的含义，就是各个会场终端所需的本地视频码流很可能不止一个，那么就将该会场终端所需的本地视频码流分别进行转发；服务器将接收到的各个会场终端的本地视频码流，不加处理的直接转发，转发给各个会场终端的所需的本地视频码流是各个会场终端发送给服务器的原始本地视频码流。本地视频码流集合，是指各个终端上报给服务器的本地视频码流的集合，这个集合是原始的本地视频码流的集合，而各个会场终端所对应的本地视频码流集合中所包括的本地视频码流可能是相同的，也可能是部分相同的，或者是各不相同。

上述的预设的规则，可以包括：将广播源的本地视频码流，作为本地视频码流集合中的一部分，即本地视频码流集合包括广播源的本地视频码流；还可以包括，接收会场终端的请求，将会场终端请求的本地视频码流作为本地视频码流集合中的一部分，即本地视频码流集合包括会场终端请求的本地视频码流。

一般而言，发送给某一个会场终端的本地视频码流应该是不同于该会场终端的本地视频码流，当然，该会场终端自己的本地视频码流是无须从服务器接收的；在云会议中，任何会场终端至少应该有一个会场终端的画面，更多的时候可以有多个画面。由于与会的会场终端数目并不是唯一的，而各个会场终端并不是都需要看到所有的会场终端，有的会场终端出于突出重点的考虑，可能只会查看某一个会场终端的视频，有的会场终端又可能为了多看看其他会场终端的画面而选择查看所有会场终端的视频，因此，服务器所需要的是，根据不同的会场终端的需求，将这些会场终端需要的那些会场终端的本地视频码流发送给这些会场终端。

在云会议中，常常会有广播源，广播源也是会场终端中的一个，即整个云会议的大局由这个会场终端来掌控，因此，往往需要将这个会场终端的本地视频码流发送到每一个会场终端，那么，此时，本地视频码流集合包括广播源的本地视频码流，第一发送模块102包括视频发送模块1021，用于将广播源的本地视频码流发送给其他各个会场终端；此外，广播源在会议中也需要有指向的看某个或者某些会场终端，相应的，需要将这些会场终端的本地视频码流发送给广播源；广播源可以看其他的会场终端，也可以看广播源自己，广播源所看的会场终端，就称为广播源看的端；在一个云会议中，往往会有这两个比较特 殊的会场终端，其中，广播源的本地视频码流需要发送给每个会场终端，而广播源看的端需要发送给广播源。当然，广播源看的端在一次云会议中是可以变化的，而且可能会经常性的变化，这个并不影响本方案的实施。此外，出于各种原因，广播源本身在一次云会议中也是可能变化的，在广播源变化之后，也应该将变化后的广播源的本地视频码流发送给各个会场终端。

此外，确定模块105还包括请求接收模块1051；各个会场终端在云会议中的任何时候，不论是刚开始，或者在会议中，都可以向服务器发送请求，这个请求至少包括该会场终端需要看的会场终端，也即是说，各个会场终端向服务器发送包括需要看的会场终端的请求；请求接收模块1051则用于接收该请求，确定该会场终端所需的本地视频码流，即本地视频码流集合包括会场终端请求的本地视频码流，视频发送模块1021则根据该请求向该会场终端发送相应的本地视频码流。也即是说，各个会场终端至少应该接收广播源的本地视频码流，此外，还可以接收其他会场终端的本地视频码流。视频发送模块1021还用于将会场终端请求的本地视频码流发送给会场终端。

可选的，还包括第一音频接收模块103和音频处理模块104；服务器在接收各个会场终端的本地视频码流时，相应的，由第一音频接收模块103接收各个会场终端的第一音频码流；在接收各个会场终端的第一音频码流时，诚然，服务器也可以直接将各个会场终端的第一音频码流发送给各个会场终端进行处理，然而，由于音频的处理与视频的处理相比其占用的服务器的cpu和内存较低，因此没有必要；此外，从实际出发，由于各个与会的会场终端在会议中并不需要看到每个会场终端的画面，但是一般需要听到所有会场终端的声音，这样才能使的会议能够正常进行。若会场终端选择性的对第一音频码流流进行接收，则会导致该会场终端错过某些其他会场终端的发言，若错过的发言特别重要的话，则会直接影响此次会议的质量。因此，本实施例中的各个会场终端所发送的第一音频码流，由音频处理模块104对该第一音频码流进行处理，然后发送给各个会场终端。音频处理模块104包括：音频解码模块1041、混音模块1042、编码模块1043、第一音频发送模块1044；其中，音频解码模块1041用于对第一音频码流进行解码，得到至少一个音频；混音模块1042用于对该音频进行混音；编码模块1043用于将混音后的音频进行编码，得到第二音频码流；第一音频发送模块1044用于将第二音频码流发送给各个会场终端。其中，对各个会场终端发送的第一音频解码和/或第二音频编码可以包括波形编解码、参数编解码 以及混合编解码中的任何可行的方式；波形编解码包括pcm、adpcm、sb-adpcm等等编解码方式，参数编解码包括lpc等编解码方式，混合编解码包括celpc、vslpc、rpe-ltp、ld-celp、mpe等等编解码方式。对音频进行混音是音频处理中的一个步骤，是把多种来源的声音，整合为一个声音。本实施例中的各个音频来自不同的会场终端，在混音过程中，会将每一个音频的频率、动态、音质、定位、残响和声场单独进行调整，让各音轨最佳化，之后再叠加于最终成品上。这种处理方式，能制作出层次分明的音频效果。混音可以由混音软件来进行处理。对混音后的音频再进行编码，就可以发送给各个会场终端。服务器可以对所有音频均进行处理，但在某些情况下，服务器也可以选择性的对各个会场终端的音频码流进行处理，这可能是因为该会场终端不需要说话，或者由广播源进行调配，采用有序发言的方式等等。

本实施例提供了一种会场终端，请参考图6，包括：

第二发送模块201，用于将会场终端的本地视频码流发送给服务器；

第二接收模块202，用于接收服务器下发的本地视频码流集合包括的本地视频码流；

视频处理模块203，用于对本地视频码流进行处理，得到视频。

在云会议中，每一个加入云会议的会场终端都应该将各自的本地视频码流发送给服务器。虽然各个云服务器处在同一个云会议中，但各个会场终端发送本地视频码流的过程是独立的，即各个会场终端是分别将各自的本地视频码流发送给服务器，同样的，各个会场终端接收服务器的至少一个其他会场终端的本地视频码流的过程也是独立的，各个会场终端之间不会互相干扰。

接收服务器下发的本地视频码流集合包括的本地视频码流指的是，在云会议中，服务器接收了各个会场终端分别发送的本地视频码流，然后将本地视频码流分别发送给各个会场终端；各个会场终端所要接收的本地视频码流应该是其他会场终端的本地视频码流，而无须接收会场终端自己的本地视频码流；本地视频码流集合包括的本地视频码流，一般而言，是指在云会议中，任何会场终端至少应该有一个会场终端的画面，更多的时候有多个画面。由于与会的会场终端数目并不是唯一的，而各个会场终端并不是都需要看到所有的会场终端，有的会场终端出于突出重点的考虑，可能只会查看某一个会场终端的视频，有 的会场终端又可能为了多看看其他会场终端的画面而选择查看所有会场终端的视频，因此，服务器所需要的是，根据不同的会场终端的需求，将这些会场终端需要的那些会场终端的本地视频码流发送给这些会场终端。本地视频码流集合，是指各个终端上报给服务器的本地视频码流的集合，这个集合是原始的本地视频码流的集合，而各个会场终端所对应的本地视频码流集合中所包括的本地视频码流可能是相同的，也可能是部分相同的，或者是各不相同。

在云会议中，常常会有广播源，广播源也是会场终端中的一个，即整个云会议的大局由这个会场终端来掌控，因此，往往需要将这个会场终端的本地视频码流发送到每一个会场终端，那么，第二接收模块202包括视频接收模块2021，用于接收广播源的本地视频码流，即本地视频码流集合包括广播源的本地视频码流；当然，这里的接收还是由服务器所发送的；此外，广播源在会议中也需要有指向的看某个或者某些会场终端，相应的，需要将这些会场终端的本地视频码流发送给广播源，也就是说广播源需要接收广播源看的端的本地视频码流；广播源可以看其他的会场终端，也可以看广播源自己，广播源所看的会场终端，就称为广播源看的端；在一个云会议中，往往会有这两个比较特殊的会场终端，其中，广播源的本地视频码流需要发送给每个会场终端，而广播源看的端需要发送给广播源。当然，广播源看的端在一次云会议中是可以变化的，而且可能会经常性的变化，这个并不影响本方案的实施。此外，出于各种原因，广播源本身在一次云会议中也是可能变化的，在广播源变化之后，也应该将变化后的广播源的本地视频码流发送给各个会场终端。

此外，第二接收模块202还包括请求发送模块2022；用于向服务器发送请求；各个会场终端在云会议中的任何时候，不论是刚开始，或者在会议中，都可以向服务器发送请求，这个请求至少包括该会场终端需要看的会场终端，也即是说，各个会场终端向服务器发送包括需要看的会场终端的请求；服务器则根据该请求向该会场终端发送相应的本地视频码流。本地视频码流集合包括会场终端请求的本地视频码流。也即是说，各个会场终端至少应该接收广播源的本地视频码流，此外，还可以接收其他会场终端的本地视频码流。视频接收模块2021还用于接收请求的本地视频码流，即请求发送模块2022请求的会场终端的本地视频码流。

在接收到至少一个本地视频码流后，就可以对本地视频码流进行处理；视 频处理模块203包括视频解码模块2031和合成模块2032，视频解码模块2031用于对本地视频码流进行解码，得到至少一个子视频；然后合成模块2032对子视频执行合成操作，得到视频。会场终端接收的本地视频码流，包括广播源在内，可能有多个，会场终端对这多个本地视频码流进行解码；视频的编解码的格式主要有以下几种：h.261、h.263、h.264，采用任何一种格式均可。将各个本地视频码流解码后，得到了至少一个子视频，就可以根据会场终端自己的意愿对各个子视频进行合成。合成后的视频的画面版式可以是任意的，一些常用的合成后的画面版式可以是：其一，对应各个会场终端的子视频按照同样的大小在画面中均匀分布；其二，以其中一个子视频为主视频，使其画面最大，其他的子视频作为从视频，画面分布在主画面的周围，其中，主视频可以以广播源作为主视频，或者此时云会议中主要发言的会场终端的视频作为主视频；其三，合成后的视频的画面可以是动态的，如谁发言谁的视频画面就相应的放大，显得比较突出。采用以上任何的方式或者其他未提及的合成方式在本实施例中均是适用的，只要其能够让该会场终端上的视频正常显示给与会的用户看即可。这样，将本地视频码流的解码合成的处理过程转到相应的会场终端来处理，由于各个会场终端的处理是独立的，不仅可以依照各个会场终端私人订制，有很好的用户体验，还减少了服务器端的cpu和内存使用，使得服务器可以接入更多的会场终端，从而可以提高会议的效率。

此外，还包括第二音频发送模块204，用于在发送会场终端的本地视频码流给服务器的同时，将各个会场终端的第一音频码流发送给服务器。在发送各个会场终端的第一音频码流时，诚然，会场终端也可以采用类似本地视频码流的处理方式对音频码流进行处理，但是音频码流有其特殊性，音频的处理与视频的处理相比，音频处理所占用的服务器的cpu和内存较低，因此没有必要；此外，从实际出发，由于各个与会的会场终端在会议中并不需要看到每个会场终端的画面，但是一般需要听到所有会场终端的声音，这样才能使得会议能够正常进行。因此，还包括第二音频接收模块205，各个会场终端将第一音频码流发送给服务器后，服务器对其进行处理，得到第二音频码流，然后将第二音频码流发送给每个会场终端。服务器对第一音频码流的处理与以上实施例中的一致，这里不再赘述。

以上内容是结合具体的实施方式对本发明所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本发明的保护范围。