CN105282477A - 多方视频数据混屏实现方法、装置、***和混屏服务器 - Google Patents

Abstract

本发明公开了一种多方视频数据混屏实现方法、装置、***和混屏服务器，用以在服务器端实现多方视频数据混屏，从而降低混屏服务器向终端传输视频数据时所需的带宽，并同时减少终端处理视频数据时对处理资源和电量的消耗。多方视频数据混屏实现方法，包括：接收参与多方视频通话的每一用户终端发送的视频图像数据；将每一视频图像数据分别绘制在预先定义的内存图所包含的任一视频图像数据绘制区域上；根据每一用户终端的视频展示区域信息，分别向对应的用户终端发送所述视频展示区域信息对应的内存图，所述视频展示区域信息用于指示所述用户终端待显示的视频图像数据。

Description

多方视频数据混屏实现方法、装置、***和混屏服务器

技术领域

本发明涉及视频数据处理技术领域，尤其涉及一种多方视频数据混屏实现方法、装置、***和混屏服务器。

背景技术

随着移动互联网的飞速发展，在移动终端上提供多方视频通话业务成为移动互联网热点业务之一。现有的在移动终端上实现的多方视频通话业务均采用传统分流视频混屏的方式，即在网络侧的服务器端将多方视频通话内每一用户的视频数据分别分发给当前通话的每一用户，然后由终端设备自行完成混屏操作。以三方进行视频通话为例，如图1所示，其为现有的网络侧视频数据处理方式，位于网络侧的视频服务器接收用户1、用户2和用户3发送的视频数据，并将用户2和用户3的视频数据发送给用户1，将用户1和用户3的视频数据发送给用户2，将用户1和用户2的视频数据发送给用户3，用户1、用户2和用户3在接收到视频数据之后，进行视频数据混屏处理。

在多方视频通话中，视频服务器需要为每个多方视频通话中的用户终端下发其他所有人的视频数据，从而导致随着视频通话中的用户增加，针对向每个终端传输数据所需的带宽也相应的增加。其中，视频服务器下行带宽消耗如下，其中m为通话个数，n为通话人数：

$\mathrm{BW}={\mathrm{\Σ}}_0^m(n*(n-1))*\mathrm{Avg}\left(\mathrm{Kbps})\right)$

上述视频数据处理方法中，用户终端在接收到视频服务器下发的其他用户的视频数据之后，自行进行混屏处理，如图2所示，为用户终端对接收到的视频数据进行处理的示意图，由于终端需要接收视频通话中其他用户终端的视频数据，这无疑还会带来用户终端对下行数据传输带宽需求的增加，而且由于终端需要为每一路视频数据进行解码操作，从而导致对用户终端的性能要求较高。其中，用户终端所需的下行带宽、CPU与电量消耗如下所示：

终端需要的下行带宽如下，其中n为通话人数：

终端产生的耗电量如下，其中，n为通话人数，Q为对单路视频进行解码所消耗电量： $\mathrm{BW}={\mathrm{\Σ}}_0^{n-1}\left(\mathrm{Avg}\left(Q\right)\right)$

终端的CPU(中央处理单元)消耗如下，n为通话人数，CPU为对单路视频进行解码CPU的消耗率:

由此可见，现有的视频数据混屏技术中，一方面，由于视频服务器需要针对每一用户，向该用户传输除自身以外其他通话视频参与用户的视频数据，增加了对视频数据传输所需的带宽要求；另一方面，每一用户终端在接收到视频服务器发送的多路视频数据之后需要自行进行混屏，既增加了终端数据传输带宽需求，又增加终端处理资源和电量的消耗。

发明内容

本发明实施例提供一种多方视频数据混屏实现方法、装置、***和混屏服务器，用以在服务器端实现多方视频数据混屏，从而降低混屏服务器向终端传输视频数据时所需的带宽，并同时减少终端处理视频数据时对处理资源和电量的消耗。

本发明实施例提供一种多方视频数据混屏实现方法，包括：

接收参与多方视频通话的每一用户终端发送的视频图像数据；

将每一视频图像数据分别绘制在预先定义的内存图所包含的任一视频图像数据绘制区域上；

根据每一用户终端的视频展示区域信息，分别向对应的用户终端发送所述视频展示区域信息对应的内存图，所述视频展示区域信息用于指示所述用户终端待显示的视频图像数据。

其中，使用矩形RECT表示每一视频图像数据在所述内存图中的区域信息，其中，所述RECT包括表示矩形左上角的横坐标的LEFT，表示矩形左上角的纵坐标TOP，表示矩形右下角的横坐标RIGHT和表示矩形右下角的纵坐标的BOTTOM；以及

按照以下方法确定每一视频图像数据在所述内存图中的区域信息：

为每一视频图像数据建立图像索引；

针对每一视频图像数据，判断该视频图像数据对应的用户索引是否大于预先定义的用户终端一屏所能够显示的、参与视频通话的用户数量；

如果是，则按照以下公式确定LEFT：LEFT＝UI％2*DW；

如果否，则按照以下公式确定LEFT：LEFT＝UI％2*DW+SW/2；

针对每一视频图像数据，判断该视频数据对应的图像索引是否位于所述内存图的上区域；

如果是，则按照以下公式确定TOP：TOP＝SH；

如果否，则按照以下公式确定TOP：TOP＝SH/2；

针对每一视频图像数据，分别按照以下公式确定RIGHT和BOTTOM：

RIGHT＝LEFT+DW；

BOTTOM＝TOP-DH；其中：

UI表示每一视频图像数据对应的图像索引；

DW表示每一视频图像数据的宽度；

DH表示每一视频图像数据的高度；

SW表示所述内存图的宽度；

SH表示所述内存图的高度。

向对应的用户终端发送所述视频展示区域信息对应的内存图之前，还包括：

按照预设的用户终端每一屏显示的、参与视频通话的用户数量对所述内存图进行划分；

将划分得到的每一部分内存图按照用户终端支持显示的视频图像大小进行处理。

根据每一用户终端的视频展示区域信息，分别向对应的用户终端发送所述视频展示区域信息对应的内存图，具体包括：

根据每一用户终端的视频展示区域信息，将所述视频展示区域信息对应的内存图封装为实时传输协议RTP数据包发送给对应的用户终端；以及

在发送RTP数据包过程中，使用实时传输控制协议RTCP进行数据包发送控制。

将所述视频展示区域信息对应的内存图封装为RTP数据包时需满足以下至少一个条件：

RTP数据包中的最大传输单元MTU的大小不超过预设值；不对所述RTP数据包中包含的任一RTP分组内的视频图像数据解码；无需解码整个数据流便能够检测所述RTP数据包中的数据类型；支持将一个网络抽象层单元类型NALU拆分为多个RTP包；支持将多个NALU汇集在一个RTP分组中。

还包括：

接收任一用户终端发送的视频展示区域切换指示，所述视频展示区域切换指示中携带有切换到的至少一个视频展示区域信息；

针对所述视频展示区域切换指示，将所述视频展示区域信息对应的内存图发送给该用户终端。

本发明实施例提供一种多方视频数据混屏实现装置，包括：

用户数据处理单元，用于接收参与多方视频通话的每一用户终端发送的视频图像数据；以及根据每一用户终端的视频展示区域信息，分别向对应的用户终端发送所述视频展示区域信息对应的内存图，所述视频展示区域信息用于指示所述用户终端待显示的视频图像数据；

混屏单元，用于将每一视频图像数据分别绘制在预先定义的内存图所包含的任一视频图像数据绘制区域上。

所述混屏单元，包括：

视频过滤器，用于在所述用户数据处理单元向对应的用户终端发送所述视频展示区域信息对应的内存图之前，按照预设的用户终端每一屏显示的、参与视频通话的用户数量对所述内存图进行划分；将划分得到的每一部分内存图按照用户终端支持显示的视频图像大小进行处理。

所述装置，还包括：

RTP/RTCP协议栈，用于根据每一用户终端的视频展示区域信息，将所述视频展示区域信息对应的内存图封装为实时传输协议RTP数据包发送给对应的用户终端；以及在发送RTP数据包过程中，使用实时传输控制协议RTCP进行数据包发送控制。

所述混屏单元，还用于接收任一用户终端发送的视频展示区域切换指示，所述视频展示区域切换指示中携带有切换到的至少一个视频展示区域信息；针对所述视频展示区域切换指示，将所述视频展示区域信息对应的内存图发送给该用户终端。

本发明实施例提供一种混屏服务器，包括上述的多方视频数据混屏实现装置。

本发明实施例提供一种多方视频数据混屏实现***，包括至少两个用户终端和混屏服务器，其中：

所述用户终端，用于向所述混屏服务器发送视频图像数据；

所述混屏服务器，用于将每一用户终端发送的视频图像数据分别绘制在预先定义的内存图所包含的任一视频图像数据绘制区域上；以及根据每一用户终端的视频展示区域信息，分别向对应的用户终端发送所述视频展示区域信息对应的内存图，所述视频展示区域信息用于指示所述用户终端待显示的视频图像数据。

所述混屏服务器，还用于向对应的用户终端发送所述视频展示区域信息对应的内存图之前，按照预设的用户终端每一屏显示的、参与视频通话的用户数量对所述内存图进行划分；将划分得到的每一部分内存图按照用户终端支持显示的视频图像大小进行处理。

所述混屏服务器，具体用于根据每一用户终端的视频展示区域信息，将所述视频展示区域信息对应的内存图封装为实时传输协议RTP数据包发送给对应的用户终端；以及在发送RTP数据包过程中，使用实时传输控制协议RTCP进行数据包发送控制。

所述用户终端，还用于向所述混屏服务器发送视频展示区域切换指示，所述视频展示区域切换指示中携带有切换到的至少一个视频展示区域信息；

所述混屏服务器，还用于针对所述视频展示区域切换指示，将所述视频展示区域信息对应的内存图发送给所述用户终端。

本发明实施例提供的多方视频数据混屏实现方法、装置、***和混屏服务器，由参与多方视频的每一用户终端分别将自身采集的视频图像数据发送给混屏服务器，混屏服务器将接收到的每一视频图像数据分别绘制在预先移动的内存图所包含的任一区域上，并根据每一用户终端希望显示的视频图像数据对应的区域信息，将对应的内存图发送给该用户终端，由于上述过程中在服务器端实现视频图像数据的混屏，并根据用户终端的展示需求下发混屏后的视频图像数据，这样，既降低了服务器向用户终端传输视频图像数据时所需的带宽需求，另一方面，由于用户终端接收到的视频图像数据为已经混屏的图像数据，从而用户终端无需进行混屏操作，能够减少用户终端消耗的处理资源和电量。

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

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本发明的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1为现有技术中，网络侧视频数据处理流程示意图；

图2为现有技术中，用户终端对接收到的视频数据进行处理的示意图；

图3为本发明实施例中，服务器对接收到的视频数据进行处理的示意图；

图4为本发明实施例中，用户终端对接收到的视频数据进行处理的示意图；

图5a为本发明实施例中，第一种内存图的格式示意图；

图5b为本发明实施例中，第二种内存图的格式示意图；

图5c为本发明实施例中，第一种内存图在终端展示的示意图；

图6为本发明实施例中，多方视频数据混屏实现方法的实施流程示意图；

图7为本发明实施例中，确定绘制区域对应的区域信息的实施流程示意图；

图8为本发明实施例中，内存图裁剪示意图；

图9为本发明实施例中，混屏服务器的***架构示意图；

图10为本发明实施例中，视频图像数据处理流程示意图；

图11为本发明实施例中，用户数据处理单元的结构示意图；

图12为本发明实施例中，视频合成器的结构示意图；

图13为本发明实施例中，多方视频数据混屏实现装置的结构示意图；

图14为本发明实施例中，多方视频数据混屏实现***的结构示意图。

具体实施方式

为了降低多方视频通话时，服务器向用户终端传输的视频图像数据所需的带宽，同时减少终端处理视频图像数据时所消耗的处理资源和电量，本发明实施例提供了一种多方视频数据混屏实现方法、装置、***和混屏服务器。

以下结合说明书附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明，并且在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。

本发明实施例提供一种服务器侧实现视频图像数据混屏的方法，即在服务器侧进行混屏后根据每一用户终端的不同的需求发送给用户终端。如图3所示，为服务器对接收到的视频数据进行处理的示意图，服务器在接收到每一用户终端发送的视频图像数据后(具体实施时，用户终端和服务器之间采用RTP/RTCP协议进行视频图像数据的传输)，首先进行解码处理，然后直接进行混屏操作，服务器在混屏后将混屏的视屏图像数据根据不同用户终端的需求动态下发给各用户终端。基于此，本发明实施例中，服务器下行传输所消耗的带宽如下，其中m为通话个数，n为通话人数：

$\mathrm{BW}={\mathrm{\Σ}}_0^m(n*\mathrm{Avg}\left(\mathrm{Kbps}\right))$

为了在混屏服务器侧实现多方视频数据的混屏，本发明实施例中，混屏服务器需要预先定义混屏所需的内存图。较佳的，如图5a所示，其为本发明实施例提供的第一种格式的内存图，其以九宫格形式定义，将每一参与视频通话的用户终端采集的视频图像数据绘制在定义好的内存图上，需要具体实施时，根据用户终端展示需要，可以定义分屏展示，即第一屏展示4人，第二屏展示4人，依次类推。图5a所示的内存图其共包括8个视频图像数据绘制区域，分别以序号1～8表示，能够支持同时有8人参与视频通话，具体实施时，并不局限于此。

需要说明的是，上述只是内存图较佳的定义格式，具体实施时，可以根据需要自行进行定义，如图5b所示，其为内存图另外一种可能的格式，可以定义每一屏显示3人，当然还可以定义每页展示2人、5人、6人……等，当然也可以单独展示其中一人，本发明实施例对此不做限定。只要是符合用户终端展示需求的内存图格式均可。

如图5c所示，为本发明实施例中，用户终端每屏展示4人和每屏展示1人的展示效果示意图。

较佳的，为了保证用户终端图像显示的清晰度，本发明实施例中，混屏服务器在混屏时定义的内存图可以保证与用户终端采集的视频图像为按照1:1比例进行绘制，这样，如果某一用户终端需要查看单个用户的视频图像时能够保证原有的清晰度。

需要说明的是，根据用户终端采集的视频图像像素的不同，其原始图像大小有所不同，现有用户终端采集的视频图像大小一般为320*240，因此，本发明实施例中以各图像终端采集的视频图像为320*240为例，具体实施时，若各用户终端采集的视频图像大小不同时，在进行混屏操作之前，还需要将其转换为标准大小(可以自行设置，本发明实施例对此不做限定，例如可以设置为320*240)。

如图6所示，为本发明实施例提供的多方视频数据混屏实现方法的实施流程示意图，包括以下步骤：

S61、接收参与多方视频通话的每一用户终端发送的视频图像数据。

具体实施时，每一参与多方视频通话的用户终端采集视频图像数据，并将采集的视频图像数据发送给混频服务器。

S62、将每一视频图像数据分别绘制在预先定义的内存图所包含的任一视频图像数据绘制区域上。

具体实施时，混屏服务器可以按照接收到的视频图像数据的时间顺序为每一视频图像数据建立图像索引，例如可以从0开始，按照接收的时间顺序依次编写，假设有8人参与视频通话，则其建立的图像索引可以按照0，1，2…，7的顺序依次建立，当然具体实施时，也可以随机建立图像索引，本发明对此不做限定。

将接收到的每一图像索引绘制在预先定义的内存图中，如图5a所示的内存图中，分别绘制图像索引为0～7的视频图像数据。

较佳的，本发明实施例中，可以使用矩形RECT表示每一视频图像数据在内存图中的区域信息，其中，RECT包括表示矩形左上角的横坐标的LEFT，表示矩形左上角的纵坐标TOP，表示矩形右下角的横坐标RIGHT和表示矩形右下角的纵坐标的BOTTOM。

由此，针对内存图包含的每一绘制区域，可以按照图7所示的步骤确定其对应的区域信息：

S621、针对每一视频图像数据，判断该视频图像数据对应的用户索引是否大于预先定义的用户终端一屏所能够显示的、参与视频通话的用户数量，如果是，执行步骤S622，否则执行步骤S623；

为例便于理解，以图5a所示的内存图为例进行说明。以图5a中序号为1～8的绘制区域分别绘制图像索引为0～7的视频图像数据，假设预先设置的用户终端一屏能够显示的参与视频通话的用户数量为4，即每一屏显示4人的视频图像数据。

S622、按照以下公式确定LEFT：LEFT＝UI％2*DW，并执行步骤S624；

例如，图像索引为0、1、2和3的视频图像数据可以按照步骤S622确定：图像索引为0和2时，其对应的LEFT为0，图像索引为1和3时，其对应的LEFT为320。

S623、按照以下公式确定LEFT：LEFT＝UI％2*DW+SW/2；

例如，图像索引为4、5、6和7的视频图像数据可以按照步骤S623确定：图像索引为4和6时，其对应的LEFT为0+640，图像索引为5和7时，其对应的LEFT为320+640。

S624、针对每一视频图像数据，判断该视频数据对应的图像索引是否位于所述内存图的上区域，如果是，执行步骤S625，否则，执行步骤S626；

具体实施时，图5a所示的内存图包含上下两块区域，每一绘制区域(以及位于该绘制区域上的视频图像数据对应的区域信息)的左上角的纵坐标可以按照步骤S625或者步骤S626来确定。

S625、按照以下公式确定TOP：TOP＝SH，并执行步骤S627；

具体实施时，针对每一视频图像数据，如果其位于上区域，则其左上角的纵坐标为内存图的高度SH，如图5a所示，SH＝480。

S626、按照以下公式确定TOP：TOP＝SH/2；

具体实施时，针对每一视频图像数据，如果其位于下区域，则其左上角的纵坐标为内存图的高度SH/2，如图5a所示，SH＝480/2＝240。

S627、针对每一视频图像数据，按照以下公式确定RIGHT：RIGHT＝LEFT+DW；

相应的，每一绘制区域的右下角的横坐标可以为：LEFT+DW，如图5a所示，DW为320。

S628、针对每一视频图像数据，按照以下公式确定：BOTTOM＝TOP-DH。

相应的，每一绘制区域的右下角的总坐标可以为：TOP-DH，如图5a所示，DH为240。

其中：UI表示每一视频图像数据对应的图像索引；DW表示每一视频图像数据的宽度(以图5a为例，每一视频图像数据的宽度320)；DH表示每一视频图像数据的高度(以图5a为例，每一视频图像数据的高度240)；SW表示预先定义的内存图的宽度(以图5a为例，内存图的宽度320*4＝1280)；SH表示预先定义的内存图的高度(以图5a为例，内存图的高度240*2＝480)。

图5a中，索引为0的视频图像数据(图5中序号为1)位于内存图的上区域，则其以RETS可以表示为(0,480,320,240)，图像索引为1的视频图像数据(内存图中序号为2)其以RETS可以表示为(320,480,640,240)，图像索引为2的视频图像数据(内存图中序号为3)其以RETS可以表示为(0,240,320,0)，图像索引为3的视频图像数据(内存图中序号为4)其以RETS可以表示为(320,240,640,0)。

S63、根据每一用户终端的视频展示区域信息，分别向对应的用户终端发送所述视频展示区域信息对应的内存图；

其中，视频展示区域信息用于指示用户终端待显示的视频图像数据。

具体实施时，初始时，混屏服务器段默认每一用户终端需要展示的视频区域为除自身以外其他所有用户的视频图像数据，即针对每一用户终端来说，内存图中除该用户终端自身的视屏图像数据所在的绘制区域以外的绘制区域对应的区域信息为该用户终端的视频展示区域信息。后续可以根据用户终端发送的视频展示区域切换指示进行视频展示区域的切换。

较佳的，如果在绘制内存图时按照1:1的比例进行绘制，假设每一视频图像数据大小为320*240，以一屏显示4人的视频图像数据为例，由于其按照1：1比例进行绘制，则4人的视频图像数据所占据的内存图大小为(320*240)*4，其超过了用户终端支持显示的视频图像数据大小(320*240)，因此，在向对应的用户终端发送视频展示区域信息对应的内存图之前，还需要按照预设的用户终端每一屏显示的、参与视频通话的用户数量对内存图进行划分；将划分得到的每一部分内存图按照用户终端支持显示的视频图像大小进行处理。以图5a为例，将其划分两部分，序号为1～4的为一部分其在用户终端的第一屏显示，序号为5～8的为一部分其在用户终端的第二屏进行显示，如图8所示，在分辨率为320*240传输下用户终端在显示左图时将有4个用户的区域，将原始内存图中坐标为RECT(0,480,640,0)(即序号为1～4的绘制区域)的区域裁剪为320*240后再发送给用户终端进行显示。

较佳的，本发明实施例中，在与用户终端之间传输视频图像数据时(包括混屏前和混屏后)可以但不限于使用RTP/RTCP协议。即在完成混屏后，混屏服务器可以根据每一用户终端的视频展示区域信息，将视频展示区域信息对应的内存图封装为RTP(实时传输协议)数据包发送给对应的用户终端；在发送RTP数据包过程中，使用RTCP(实时传输控制协议)进行数据包发送控制。

更佳的，本发明实施例中，将视频展示区域信息对应的内存图封装为RTP数据包时需满足以下至少一个条件：RTP数据包中的最大传输单元MTU的大小不超过预设值；不对所述RTP数据包中包含的任一RTP分组内的视频图像数据解码；无需解码整个数据流便能够检测RTP数据包中的数据类型；支持将一个NALU(网络抽象层单元类型)拆分为多个RTP包；支持将多个NALU汇集在一个RTP分组中。

具体实施时，在多方视频通话过程中，用户终端还可以向混屏服务器发送视频展示区域切换指示，在该指示中携带有待切换到的至少一个视频展示区域信息，针对视频展示区域切换指示，将视频展示区域信息对应的内存图发送给该用户终端进行展示。例如，用户在通话过程中，当其希望单独展示其中一人的视频图像数据时，可以触摸该用户视屏图像数据所在区域，用户终端通过识别该区域对应的区域信息，并将其携带在视频展示区域切换指示中发送该混屏服务器，混屏服务器将该区域信息对应的内存图发送给用户终端进行显示即可。

为了更好的理解本发明，以下结合混屏服务器的***架构示意图对本发明实施例的具体实施过程进行描述，如图9所示，其为混屏服务器的***架构示意图，主要由NetStack、RTP/RTCP协议栈、编解码器、用户数据处理单元、混屏单元五部分组成，其中，混屏单元包括混屏定时器、视频合成器、视频过滤器、视频分发器、用户视频缓存区和用户状态缓存器，各部分分工合作完成视频的到达、混屏、下发过程。以下将对各部分作逐一说明。

每一用户终端采集的视频图像数据到达混屏服务器后，首先将视频图像数据进行RTP解包，视频解码后提交到用户视频缓存区，混屏定时器负责启动混屏操作，在混屏完成后根据用户状态缓存器发送内存图中的不同区域的视频图像数据给用户终端。下面对各部分做详细说明。

NetStack：NetStack提供UDP(用户数据报协议)数据的互通功能。为应对互联网环境的复杂性，NetStack提供ICE协商，支持TURN\STUN流程，保证了网络的互通性，为视频图像数据的互通提供可行性。

RTP/RTCP协议栈：实时传输协议RTP是针对Internet上多媒体数据流的一个传输协议,其被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它需要依靠RTCP提供这些服务。实时传输控制协议RTCP负责管理传输质量在当前应用进程之间交换控制信息。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，可以更有效的反馈和最小的开销使传输效率最佳化。

利用RTCP提供的主要能力：利用反馈信息来提供分配数据的传送质量，这种反馈可以用来进行流量的拥塞控制，也可以用来监视网络和用来诊断网络中的问题；为RTP源提供一个永久性的CNAME(规范性名字)的传送层标志，因为在发现冲突或者程序更新重启时SSRC(同步源标识)会变，需要一个运作痕迹，在一组相关的会话中接收方也要用CNAME来从一个指定的与会者得到相联系的数据流(如音频和视频)；根据与会者的数量来调整RTCP包的发送率；传送会话控制信息。

如图10所示，为本发明实施例中，视频图像数据的处理流程示意图，在视频图像数据发送端，视频图像数据解码后首先经RTP进行封装，并根据IP/UDP协议打包成适合网络传输的数据包已在Internet(互联网)中进行传输。RTCP与RTP数据协议一起配合使用，当启动一个RTP会话时将同时占用两个端口，分别供RTP和RTCP使用。由于RTP本身并不能为按序传输数据包提供可靠的保证，也不提供流量控制和拥塞控制，所以这些都由RTCP来负责完成。RTCP会采用与RTP相同的分发机制，向会话中的所有成员周期性地发送控制信息，程序通过接收这些数据，从中获取会话参与者的相关资料，以及网络状况、分组丢失概率等反馈信息提交给QoS(服务质量)反馈***，从而能够对服务质量进行控制或者对网络状况进行诊断。相应的，在视频图像数据接收端按照上述过程的逆过程对视频图像数据进行处理并解码。其中，SR表示发送端报告，其是指发出RTP数据包的应用程序或者终端，发送端同时也可以是接收端，RR表示接收端报告，其是指仅接收但不发送RTP数据包的应用程序或者终端。

由于本发明还能够提高网络传输的效率，所以设计合适的RTP封装策略对视频图像数据进行封装是十分重要的。较佳的，本发明实施例中，在进行RTP封装时可以遵循以下至少一个设计原则：1、较低的开销，因此MTU(最大传输单元)的尺寸不超过预设值，例如可以但不限于限制在100—64K字节(尽量小字节)范围内。2、易于区分分组的重要性，而不必对分组内的数据解码。3、应能检测到数据的类型，而不需解码整个数据流，并能根据编码流之间的相关性丢弃无用数据。例如网关应能检测A型分割的丢失，并能丢弃相应的B型和C型分割。4、应支持将一个NALU(网络抽象层单元类型)拆分为若干个RTP包：不同大小的输入图片决定了NALU的长度可能会大于MTU，只有拆分后才会避免IP层在传输时出现分片。5、支持将多个NALU汇集在一个RTP分组中，即在一个RTP包中传输超过一个NALU，当多个图片的编码输出小于M1IU时就考虑此模式，以提高网络传输效率。

视频编解码器：随着数字多媒体的应用日渐广泛，视频解码在***设计中变成一个基本要素。视频标准有多种，依赖于产品可实施其中的一个或者多个标准。当然这不是全部，视频仅仅是多媒体码流的一部分，另外还有音频或者语音需要并行处理。视频解码本身对性能要求较高，需要不同于先前基于语音和信息应用的***架构；这就对便携***提出了特殊挑战，而桌面应用同样面临这些问题。因此为了减少对于终端的新能消耗，我们采用服务器编解码技术。

在服务器混屏中为支持终端需求，可采用多种视频编解码(例如H264-BP、H264-MP、VP8、H263、H263+、MP4V-ES等)。

在数据传输过程中与RTP/RTCP协议栈配合使用完成流量控制和用塞控制，并且保证图像的质量。

用户数据处理单元：用户数据处理单元负责将解码后的视频图像数据投递到用户视频缓存区，并且负责将混屏后的视频图像数据投递给用户；它也决定了用户终端下行视频图像数据帧率。

如图11所示，为本发明实施例中用户数据处理单元的结构示意图，包括缓存区、用户区和定时器，其中，缓存区：用于存放需要下发给用户终端的视频图像数据，该缓存区为每个用户终端申请一张图片所存放的区域；用户区(User)：用于存放会话参与方的信息，根据该参与方信息将接收到的视频图像数据投递到混屏单元；定时器：用于启动视频图像数据的发送，该时间决定了混屏服务器向用户终端推送视频图像数据的帧率，具体实施时，例如可以但不限于设置时间间隔为：T(ms)＝1000/Fps。

混屏单元：其中，混屏定时器负责启动混屏操作，它负责将视频图像数据从用户缓存区获取后投递给视频合成器进行合成整张视频内存图。参考用户数据处理单元的定时器设置的时间间隔，该混屏定时器的时间间隔可以但不限于为所有用户终端的视频图像数据的最大帧率间隔：T(ms)＝1000/MAX(Fps)。用户视频缓存区：用于存放预先定义的内存图以及各用户的视频内存图。视频合成器：用于将各用户的视频图像数据绘制到内存图上，它由一系列的过滤器进行组成，绘制调用ffmpeg完成。如图12所示，为视频合成器的结构示意图，包括ButterFilter，ScaleFilter、BorderFilter、ButterFilter。

具体实施时，为了保证用户终端显示单个视频图像情况下保证视频质量，内存中针对个人的数据区域尽量保证为***尺寸。不同用户在内存图中的具***置由计算获得，计算方式可以参见图7所示的流程。

用户状态缓存器：实现了混屏的动态更新功能，用户终端根据自己的需求进行不同区域的视频展示。用户操作分为升级视频(仅需传输视频图像数据)，降级为音频(仅需传输音频数据)，查看左屏(即需传输第一屏对应的内存图给用户终端进行显示)，查看右屏(即需要传输下一屏对应的内存图给用户终端进行显示)，查看指定人员(即需传输单个视频图像数据)。

具体实施时，在有参与多方视频通话的用户终端加入或退出后，用户状态缓存器做相应的用户视频缓存区的更新操作，并将新加入或退出的用户下发给各用户终端。

视频过滤器：根据用户状态缓存器对用户终端希望显示部分的不同区域进行裁剪。其具体的操作过程可参见图8。

视频分发器负责将混屏后的视频图像数据推送给各用户数据处理单元，进行视频图像数据的下发操作。

本发明实施例提供的在服务器侧实现多方视频数据混屏的方法，用户终端显示的混屏效果可由服务器段进行控制，且与传统的在终端侧进行混屏的方案相比，终端只需要在接收到视频图像数据之后进行解码进行显示即可，如图4所示，为本发明实施例中，用户终端对接收到的视频数据进行处理的示意图，用户终端在接收到服务器发送的RTP/RTCP数据包之后，只需要对其进行解码输出即可。服务器侧根据用户终端的具体需求进行不同区域的显示(即用户终端希望显示的参与视频通话的部分用户的视频图像数据)，因此，根据本发明实施例提供的方法，对于用户终端来说，相当于二人视频通话，不会产生带宽、CPU等处理资源以及电量的额外增加，而对于混屏服务器来说，其针对每一用户终端只需要发送一路混屏后的视屏图像数据，从而降低了对传输带宽的需求。

基于同一发明构思，本发明实施例中还提供了一种移多方视频数据混屏实现装置、***和混屏服务器，由于上述装置、***及设备解决问题的原理与多方视频数据混屏实现方法相似，因此上述装置、***及设备的实施可以参见方法的实施，重复之处不再赘述。

如图13所示，为本发明实施例提供的多方视频数据混屏实现装置的结构示意图，包括：

用户数据处理单元131，用于接收参与多方视频通话的每一用户终端发送的视频图像数据；以及根据每一用户终端的视频展示区域信息，分别向对应的用户终端发送所述视频展示区域信息对应的内存图，所述视频展示区域信息用于指示所述用户终端待显示的视频图像数据；

混屏单元132，用于将每一视频图像数据分别绘制在预先定义的内存图所包含的任一视频图像数据绘制区域上。

其中，混屏单元132，包括：视频过滤器，用于在所述用户数据处理单元向对应的用户终端发送所述视频展示区域信息对应的内存图之前，按照预设的用户终端每一屏显示的、参与视频通话的用户数量对所述内存图进行划分；将划分得到的每一部分内存图按照用户终端支持显示的视频图像大小进行处理。

具体实施时，本发明实施例提供的多方视频数据混屏实现装置，还可以包括：

RTP/RTCP协议栈，用于根据每一用户终端的视频展示区域信息，将所述视频展示区域信息对应的内存图封装为实时传输协议RTP数据包发送给对应的用户终端；以及在发送RTP数据包过程中，使用实时传输控制协议RTCP进行数据包发送控制。

具体实施时，混屏单元132，还可以用于接收任一用户终端发送的视频展示区域切换指示，所述视频展示区域切换指示中携带有切换到的至少一个视频展示区域信息；针对所述视频展示区域切换指示，将所述视频展示区域信息对应的内存图发送给该用户终端。

为了描述的方便，以上各部分按照功能划分为各模块(或单元)分别描述。当然，在实施本发明时可以把各模块(或单元)的功能在同一个或多个软件或硬件中实现，如上述的多方视频数据混屏实现装置可以设置在混屏服务器中。

如图14所示，为本发明实施例提供的多方视频数据混屏实现***的结构示意图，包括至少两个用户终端141和混屏服务器142，其中：

用户终端141，用于向混屏服务器142发送视频图像数据；

混屏服务器142，用于将每一用户终端141发送的视频图像数据分别绘制在预先定义的内存图所包含的任一视频图像数据绘制区域上；以及根据每一用户终端141的视频展示区域信息，分别向对应的用户终端141发送视频展示区域信息对应的内存图，视频展示区域信息用于指示用户终端141待显示的视频图像数据。

具体实施时，混屏服务器142，还可以用于向对应的用户终端141发送视频展示区域信息对应的内存图之前，按照预设的用户终端141每一屏显示的、参与视频通话的用户数量对内存图进行划分；将划分得到的每一部分内存图按照用户终端141支持显示的视频图像大小进行处理。

具体实施时，混屏服务器142，还可以用于根据每一用户终端141的视频展示区域信息，将视频展示区域信息对应的内存图封装为实时传输协议RTP数据包发送给对应的用户终端141；以及在发送RTP数据包过程中，使用实时传输控制协议RTCP进行数据包发送控制。

具体实施时，用户终端141，还可以用于向混屏服务器142发送视频展示区域切换指示，视频展示区域切换指示中携带有切换到的至少一个视频展示区域信息；混屏服务器142，还可以用于针对视频展示区域切换指示，将视频展示区域信息对应的内存图发送给用户终端141。

本领域内的技术人员应明白，本发明的实施例可提供为方法、***、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (15)

1.一种多方视频数据混屏实现方法，其特征在于，包括：

接收参与多方视频通话的每一用户终端发送的视频图像数据；

将每一视频图像数据分别绘制在预先定义的内存图所包含的任一视频图像数据绘制区域上；

根据每一用户终端的视频展示区域信息，分别向对应的用户终端发送所述视频展示区域信息对应的内存图，所述视频展示区域信息用于指示所述用户终端待显示的视频图像数据。

2.如权利要求1所述的方法，其特征在于，使用矩形RECT表示每一视频图像数据在所述内存图中的区域信息，其中，所述RECT包括表示矩形左上角的横坐标的LEFT，表示矩形左上角的纵坐标TOP，表示矩形右下角的横坐标RIGHT和表示矩形右下角的纵坐标的BOTTOM；以及

按照以下方法确定每一视频图像数据在所述内存图中的区域信息：

为每一视频图像数据建立图像索引；

针对每一视频图像数据，判断该视频图像数据对应的用户索引是否大于预先定义的用户终端一屏所能够显示的、参与视频通话的用户数量；

如果是，则按照以下公式确定LEFT：LEFT＝UI％2*DW；

如果否，则按照以下公式确定LEFT：LEFT＝UI％2*DW+SW/2；

针对每一视频图像数据，判断该视频数据对应的图像索引是否位于所述内存图的上区域；

如果是，则按照以下公式确定TOP：TOP＝SH；

如果否，则按照以下公式确定TOP：TOP＝SH/2；

针对每一视频图像数据，分别按照以下公式确定RIGHT和BOTTOM：

RIGHT＝LEFT+DW；

BOTTOM＝TOP-DH；其中：

UI表示每一视频图像数据对应的图像索引；

DW表示每一视频图像数据的宽度；

DH表示每一视频图像数据的高度；

SW表示所述内存图的宽度；

SH表示所述内存图的高度。

3.如权利要求1所述的方法，其特征在于，向对应的用户终端发送所述视频展示区域信息对应的内存图之前，还包括：

按照预设的用户终端每一屏显示的、参与视频通话的用户数量对所述内存图进行划分；

将划分得到的每一部分内存图按照用户终端支持显示的视频图像大小进行处理。

4.如权利要求1所述的方法，其特征在于，根据每一用户终端的视频展示区域信息，分别向对应的用户终端发送所述视频展示区域信息对应的内存图，具体包括：

根据每一用户终端的视频展示区域信息，将所述视频展示区域信息对应的内存图封装为实时传输协议RTP数据包发送给对应的用户终端；以及

在发送RTP数据包过程中，使用实时传输控制协议RTCP进行数据包发送控制。

5.如权利要求4所述的方法，其特征在于，将所述视频展示区域信息对应的内存图封装为RTP数据包时需满足以下至少一个条件：

RTP数据包中的最大传输单元MTU的大小不超过预设值；不对所述RTP数据包中包含的任一RTP分组内的视频图像数据解码；无需解码整个数据流便能够检测所述RTP数据包中的数据类型；支持将一个网络抽象层单元类型NALU拆分为多个RTP包；支持将多个NALU汇集在一个RTP分组中。

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

接收任一用户终端发送的视频展示区域切换指示，所述视频展示区域切换指示中携带有切换到的至少一个视频展示区域信息；

针对所述视频展示区域切换指示，将所述视频展示区域信息对应的内存图发送给该用户终端。

7.一种多方视频数据混屏实现装置，其特征在于，包括：

用户数据管理单元，用于接收参与多方视频通话的每一用户终端发送的视频图像数据；以及根据每一用户终端的视频展示区域信息，分别向对应的用户终端发送所述视频展示区域信息对应的内存图，所述视频展示区域信息用于指示所述用户终端待显示的视频图像数据；

混屏单元，用于将每一视频图像数据分别绘制在预先定义的内存图所包含的任一视频图像数据绘制区域上。

8.如权利要求7所述的装置，其特征在于，所述混屏单元，包括：

视频过滤器，用于在所述用户数据管理单元向对应的用户终端发送所述视频展示区域信息对应的内存图之前，按照预设的用户终端每一屏显示的、参与视频通话的用户数量对所述内存图进行划分；将划分得到的每一部分内存图按照用户终端支持显示的视频图像大小进行处理。

9.如权利要求7所述的装置，其特征在于，还包括：

RTP/RTCP协议栈，用于根据每一用户终端的视频展示区域信息，将所述视频展示区域信息对应的内存图封装为实时传输协议RTP数据包发送给对应的用户终端；以及在发送RTP数据包过程中，使用实时传输控制协议RTCP进行数据包发送控制。

10.如权利要求7、8或9所述的装置，其特征在于，

所述混屏单元，还用于接收任一用户终端发送的视频展示区域切换指示，所述视频展示区域切换指示中携带有切换到的至少一个视频展示区域信息；针对所述视频展示区域切换指示，将所述视频展示区域信息对应的内存图发送给该用户终端。

11.一种混屏服务器，其特征在于，包括权利要求7～10任一权利要求所述的装置。

12.一种多方视频数据混屏实现***，其特征在于，包括至少两个用户终端和混屏服务器，其中：

所述用户终端，用于向所述混屏服务器发送视频图像数据；

所述混屏服务器，用于将每一用户终端发送的视频图像数据分别绘制在预先定义的内存图所包含的任一视频图像数据绘制区域上；以及根据每一用户终端的视频展示区域信息，分别向对应的用户终端发送所述视频展示区域信息对应的内存图，所述视频展示区域信息用于指示所述用户终端待显示的视频图像数据。

13.如权利要求12所述的***，其特征在于，

所述混屏服务器，还用于向对应的用户终端发送所述视频展示区域信息对应的内存图之前，按照预设的用户终端每一屏显示的、参与视频通话的用户数量对所述内存图进行划分；将划分得到的每一部分内存图按照用户终端支持显示的视频图像大小进行处理。

14.如权利要求12所述的***，其特征在于，

所述混屏服务器，具体用于根据每一用户终端的视频展示区域信息，将所述视频展示区域信息对应的内存图封装为实时传输协议RTP数据包发送给对应的用户终端；以及在发送RTP数据包过程中，使用实时传输控制协议RTCP进行数据包发送控制。

15.如权利要求12、13或14所述的***，其特征在于，

所述用户终端，还用于向所述混屏服务器发送视频展示区域切换指示，所述视频展示区域切换指示中携带有切换到的至少一个视频展示区域信息；

所述混屏服务器，还用于针对所述视频展示区域切换指示，将所述视频展示区域信息对应的内存图发送给所述用户终端。