CN104754283A - 音视频通讯方法、服务器和*** - Google Patents

Abstract

本发明公开了一种音视频通讯方法、服务器和***。该方法包括：接收每个客户端发送的视频流，将接收的所有视频流进行混屏处理得到混屏视频流；接收第一客户端发送的独立视频请求，根据所述独立视频请求中的第二客户端的标识信息获取第二客户端的独立视频流；将所述混屏视频流和第二客户端的独立视频流传输至所述第一客户端，使得所述第一客户端显示所述混屏视频流和第二客户端的独立视频流。本发明提供的技术方案能够解决现有音视频通讯中每个与会人员所接收的音视频数据相同，不能满足用户个性化需要的问题。

Description

音视频通讯方法、服务器和***

技术领域

本发明涉及计算机智能终端技术领域，特别是涉及一种音视频通讯方法、服务器和***。

背景技术

在当今的互联网时代，随着网络状况的不断升级以及智能终端的不断普及，多方音视频会议的业务形态受到了越来越多的重视和发展。现在的智能终端所处的网络还主要处于2G、3G或者是wifi网络。

目前多人语音视频的通讯大多数采用混屏技术，即所有与会人员发送自己的视频流，由服务器将各个与会人员发送的视频流进行混屏然后进行分路的发送。

现有的技术方案中，各与会人员接收到的混屏数据都是一样的数据，各个与会人员看到的视频固定统一，不够灵活，不能满足各与会人员的个性化需求。

发明内容

本发明提供了一种音视频通讯方法、服务器和***。本发明提供的技术方案能解决现有的在音视频通讯中，每个与会人员所接收的音视频数据相同，以及每个与会人员所看到的视频的无法改变的问题。

本发明公开了一种音视频通讯方法，该方法包括：

接收每个客户端发送的视频流，将接收的所有视频流进行混屏处理得到混屏视频流；

接收第一客户端发送的独立视频请求，根据所述独立视频请求中的第二客户端的标识信息获取第二客户端的独立视频流；

将所述混屏视频流和第二客户端的独立视频流传输至所述第一客户端，使得所述第一客户端显示所述混屏视频流和第二客户端的独立视频流。

在上述方法中，所述将接收的所有视频流进行混屏处理得到混屏视频流之前，该方法进一步包括：

接收***客户端发送的突出显示请求，在所述突出显示请求中携带指定客户端的标识信息；

所述将接收的所有视频流进行混屏处理得到混屏视频流包括：

根据所述突出显示请求中的标识信息，将接收的所有视频流进行混屏处理得到混屏视频流，其中，所述混屏视频流的显示区域中的指定区域显示所述指定客户端对应的视频。

进一步地，在上述方法中，所述将所述混屏视频流和第二客户端的独立视频流传输至所述第一客户端，使得所述第一客户端显示所述混屏视频流和第二客户端的独立视频流之后，该方法进一步包括：

接收第一客户端发送的独立视频释放请求，所述独立视频释放请求中携带所述第一客户端需要释放的视频数据所对应的客户端的标识信息；

根据所述独立视频释放请求中的标识信息，停止向所述第一客户端发送所述标识信息所对应的客户端的视频流。

进一步地，在上述方法中，所述接收每个客户端发送的视频流之前，该方法进一步包括：

通过移动设备管理MDM生成各客户端对应的适配结果信息，并发送给各客户端，以使各客户端根据对应的适配结果信息采集视频流；

所述将所述混屏视频流和第二客户端的独立视频传输至所述第一客户端，使得所述第一客户端显示所述混屏视频流和第二客户端的独立视频流具体包括：

将所述混屏视频流和第二客户端的独立视频传输至所述第一客户端，使得所述第一客户端在同一界面显示或在不同界面切换显示所述混屏视频流和第二客户端的独立视频流。

在上述方法中，其特征在于，所述接收第一客户端发送的独立视频请求之后，该方法进一步包括：

根据第一客户端当前进行视频传输的实际流量和当前视频传输的丢包率，以及所述第一客户端发送的独立视频请求所需的新增流量，计算最终丢包率，根据计算得到的最终丢包率向所述第一客户端发送网络质量提醒信息，以使所述第一客户端根据所述网络质量提醒信息，判断是否继续所述独立视频请求；

所述将所述混屏视频流和第二客户端的独立视频流传输至所述第一客户端，使得所述第一客户端显示所述混屏视频流和第二客户端的独立视频流包括：

在所述客户端确定继续所述独立视频请求时，将所述混屏视频流和第二客户端的独立视频流传输至所述第一客户端，使得所述第一客户端显示所述混屏视频流和第二客户端的独立视频流。

本发明还公开了一种音视频通讯服务器，该服务器包括：

第一接收模块，用于接收每个客户端发送的视频流，将接收的所有视频流进行混屏处理得到混屏视频流；

第二接收模块，用于接收第一客户端发送的独立视频请求，根据所述独立视频请求中的第二客户端的标识信息获取第二客户端的独立视频流；

传输模块，用于将所述混屏视频流和第二客户端的独立视频流传输至所述第一客户端，使得所述第一客户端显示所述混屏视频流和第二客户端的独立视频流。

所述第一接收模块，进一步用于接收***客户端发送的突出显示请求，在所述突出显示请求中携带指定客户端的标识信息；根据所述突出显示请求中的标识信息，将接收的所有视频流进行混屏处理得到混屏视频流，其中，所述混屏视频流的显示区域中的指定区域显示所述指定客户端对应的视频；

所述传输模块，还用于接收第一客户端发送的独立视频释放请求，所述独立视频释放请求中携带所述第一客户端需要释放的视频数据所对应的客户端的标识信息；根据所述独立视频释放请求中的标识信息，停止向所述第一客户端发送所述标识信息所对应的客户端的视频流。

进一步地，该服务器进一步包括：移动设备管理模块；

所述移动设备管理模块，用于生成各客户端对应的适配结果信息，并发送给各客户端，以使各客户端根据对应的适配结果信息采集视频流；

所述第二接收模块，进一步用于在接收第一客户端发送的独立视频请求之后，根据第一客户端当前进行视频传输的实际流量和当前视频传输的丢包率，以及所述第一客户端发送的独立视频请求所需的新增流量，计算最终丢包率，根据计算得到的最终丢包率向所述第一客户端发送网络质量提醒信息；使得所述第一客户端根据所述网络质量提醒信息，判断是否继续独立视频释放请求；

所述传输模块具体用于在在所述客户端确定继续所述独立视频请求时，将所述混屏视频流和第二客户端的独立视频流传输至所述第一客户端。

本发明还公开了一种音视频通讯***，该***包括：客户端，以及如上述的服务器。

综上所述，本发明提供的技术方案通过接收第一客户端发送的独立视频请求，在发送混屏数据的同时将独立视频请求中的客户端标识信息所对应客户端发送的视频流转发给第一客户端，使得第一客户端可以根据自身的显示混屏视频流和所关注的客户端的视频流。能够根据终端的实际情况如网络状况、终端性能等，及根据用户的需要来显示所需的客户端的视频，解决了现有的视频会议中，每个客户端中所显现的音视频数据相同，以及每个与会人员所看到的视频固定、无法改变的问题，即缺乏个性化设置支持的弊端。

附图说明

图1是本发明中一种音视频通讯的方法的流程图；

图2是本发明第一实施例中音视频通讯方法的流程图；

图3是本发明第二实施例中音视频通讯方法的流程图；

图4是本发明中一种音视频通讯服务器的结构示意图;

图5是本发明中一种音视频通讯***的结构示意图。

具体实施方式

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

图1是本发明中一种音视频通讯的方法的流程图，参见图1所示，该方法包括如下步骤。

步骤101，接收每个客户端发送的视频流，将接收的所有视频流进行混屏处理得到混屏视频流；

步骤102，接收第一客户端发送的独立视频请求，根据所述独立视频请求中的第二客户端的标识信息获取第二客户端的独立视频流；

步骤103，将所述混屏视频流和第二客户端的独立视频流传输至所述第一客户端，使得所述第一客户端显示所述混屏视频流和第二客户端的独立视频流。

本实施例中，独立视频的传输根据第一客户端发送的独立视频请求来触发，客户端可以在开始进行会议视频时发送独立视频请求，这样服务器可以同时开始传输所述混屏视频流和所述第二客户端的独立视频流，也可以在视频会议中发送，这样本实施例中，具体是服务器在视频会议开始时开始向第一客户端传输混屏数据，在接收到第一客户端的独立视频请求时，开始向第一客户端传输第二客户端的独立视频流。在如图1所示的实施例中，在建立多个客户端之间的视频会议之后，将接收的客户端发送的视频流进行混屏处理之后发送给每个客户端，第一客户端在流量较为宽裕的情况下，通过发送携带第二客户端的标识信息的独立视频请求向服务器请求第二客户端的视频流。服务器在接收到该独立视频请求之后，将第二客户端发送的视频流不经过任何处理直接转发给第一客户端。使得第一客户端在接收混屏视频流的同时，也能接收到第二客户端的高保真视频。

当然，网络状况允许的情况下，在本发明的其他实施例中，第一客户端在请求第二客户端对应的视频流之后，还可以请求第三客户端、甚至是第四客户端对应的视频流。即通过发送多次独立视频请求，使得在第一客户端中可以显示第二客户端、第三客户端和第四客户端所对应的高保真视频。在本发明的其他实施例中，第一客户端可以在一个独立视频请求中携带第二客户端、第三客户端和第四客户端的标识信息，即只需要发送一次独立视频请求，就能使得第一客户端中显示多个客户端的视频流。

由上述可知，由于参与视频会议中的各个客户端的所在的终端能力（处理器、内存等硬件性能）以及各个客户端所在终端的所处的网络状况并不相同（wifi、3G、4G或局域网等），本发明提供的技术方案能够根据终端的实际情况，显示所需的客户端的视频，解决了现有的视频会议中，每个客户端中所显现的音视频数据相同，且混屏视频流中每个客户端对应的图像较小，不能清晰显示用户需要查看的某一客户端的视频，不能满足用户个性化需要，即缺乏个性化设置支持的弊端。

在本发明中，所述的第一客户端、第二客户端、第三客户端和第四客户端仅为所建立的视频会议中的任意一个客户端，其中，第一、第二、第三和第四不是特指某个客户端。此外，在本发明中，对应于音频的处理可以与视频的处理方式相同。

在本发明的一种具体实施例中，可以通过采用***控制的方式设置每个客户端所要关注的客户端的视频。

图2是本发明第一实施例中音视频通讯方法的流程图。参见图2所示，该方法包括如下步骤。

步骤201，建立与多个客户端之间的视频会议。

在本步骤中，客户端向服务器发送视频会议请求，服务器根据所述视频会议请求建议多个客户端之间的视频会议。其中，在建立客户端与服务器之间的信令通道和媒体通道。信令通道用于传输信令，即用于传输会议状态管理信息，具体为状态推送消息，会议加入退出消息等。媒体通道用于传输视频流，具体为，用于传输客户端发送的视频流，用于传输服务器发送的混屏后的混屏视频流。

步骤202，将接收的所有视频流进行混屏处理得到混屏视频流；将混屏视频流发送给每个客户端。

在本步骤中，服务器接收视频会议中的所有客户端发送的视频流，根据发送视频流的客户端的标识信息区分每个客户端发送的视频流。较佳的，使得每个客户端中能够显示在本次视频会议中的其他客户端的列表以及对应的编号，编号可以为对应客户端的标识信息，或者与客户端的标识信息一一映射。

步骤203，接收***客户端发送的突出显示请求，在所述突出显示请求中携带指定客户端的标识信息。

步骤204，根据所述突出显示请求中的标识信息，将接收的所有视频流进行混屏处理之后发送给每个客户端。

在本实施例中，由***客户端进行管理和控制，所述***客户端具体可以为发起视频会议请求的客户端，也可以由各个主动申请成为***客户端。在步骤203和步骤204中，服务器接收***客户端发送的突出显示请求，即在混屏视频流中存在需要突出显示的指定客户端的视频，根据突出显示请求中的标识信息，对各个客户端发送的视频流进行混屏处理，再将得到的混屏视频流发送给每个客户端。。此外，在其他实施例中，服务器还可以根据***客户端发送的指令，对混屏视频流中突出显示的视频流进行调整。

步骤205，使得在每个客户端的混屏视频流的显示区域中的指定区域显示所述指定客户端对应的视频。

客户端的混屏视频流显示区域包括突出显示区及悬浮显示区，所述指定区域即突出显示区，在突出显示区域显示所述指定客户端对应的视频数据，即在突出显示区域显示指定客户端对应的视频，在悬浮显示区显示其他各个客户端对应的视频。所述悬浮显示区悬浮在突出显示区域之上，优选地，在本实施例中，所述突出显示区所占区域较大，可以清晰显示指定客户端对应的视频，所述悬浮区中显示其他客户端对应的缩略视频图像，从而实现可以根据显示需要，在混屏视频流对应的视频中清晰显示所需要关注的客户端对应的视频，与现有技术中混屏视频中每个客户端对应的视频图像均比较小、不够清晰相比，进一步满足了用户的需要，提高混屏视频显示的灵活性及实用性。

具体地，本实施例中，服务器对各客户端发送的视频流进行混屏处理，主要是通过混屏计算来实现对混屏数据的蒙版添加和区域绘制：其中，蒙版部分实现如下：

//增加底部蒙板

uint8_t*

yPtr=pMixFrame->data[0]+(pMixFrame->width*(pMixFrame->height-OTRectHeight(backDst)));

for(size_t i=0;i<pMixFrame->width*OTRectHeight(backDst);i++){int y=(uint8_t)(*yPtr);

y=TSK_MAX(0,TSK_MIN(255,y-20));

*yPtr=(uint8_t)y;

yPtr++;

}

//区域绘制部分算法如下

static inline void_findListenerDest(

size_t nConsumers,size_t nListenerIndex,

size_t nMixFrameWidth,size_t nMixFrameHeight,

size_t nListenerFrameWidth,size_t nListenerFrameHeight,

OTRect_t&rectDst,

const OTRatio_t&PAR,

OTRect_t&backDst

)

{

if(nListenerIndex==0){

const size_t nActiveParticipants=1;

const size_t nNumWindows=1;

const size_t nNumWindowsHaft=1;

rectDst.nTop=0;

rectDst.nLeft=0;

rectDst.nBottom=nMixFrameHeight;

rectDst.nRight=nMixFrameWidth;

//ratio()

OTRect_t rcSrc={0,0,nListenerFrameWidth,nListenerFrameHeight};

if(PAR.nDenominator!=0&&PAR.nDenominator!=0)

{

_correctAspectRatio(rcSrc,PAR,rcSrc);

_letterBoxRect(rcSrc,rectDst,rectDst);

}

backDst.nTop=0;

backDst.nLeft=0;

backDst.nBottom=nMixFrameHeight;

backDst.nRight=nMixFrameWidth;

}

else{

const size_t picOffset=5;

const size_t picCount=nConsumers-1;

const size_t nActiveParticipants=TSK_MAX(picCount,kMinActiveParticipants4SizeCompute);

const size_tpicHeight=(nMixFrameWidth-nListenerIndex*picOffset)/nActiveParticipants;

rectDst.nTop=nMixFrameHeight-picHeight-picOffset;

rectDst.nBottom=rectDst.nTop+picHeight;

rectDst.nLeft=(nListenerIndex-1)*picHeight+picOffset*nListenerIndex+picOffset;

rectDst.nRight=rectDst.nLeft+picHeight;

////modify by lyh

////获取最少需要混频的数量

//const size_t nActiveParticipants=TSK_MAX(nConsumers,kMinActiveParticipants4SizeCompute);

//const size_t nNumWindows=(nActiveParticipants%2==0)?nActiveParticipants:(nActiveParticipants+1);

(nMixFrameWidth/nNumWindowsHaft);

OTRect_t rcSrc={0,0,nListenerFrameWidth,nListenerFrameHeight};

if(PAR.nDenominator!=0&&PAR.nDenominator!=0)

{

_correctAspectRatio(rcSrc,PAR,rcSrc);

_letterBoxRect(rcSrc,rectDst,rectDst);

const size_t height=OTRectHeight(rectDst);;

rectDst.nTop=nMixFrameHeight-height-picOffset;

rectDst.nBottom=rectDst.nTop+height;

}

backDst.nTop=rectDst.nTop-picOffset;

backDst.nBottom=nMixFrameHeight;

backDst.nLeft=(nListenerIndex-1)*picHeight+picOffset*nListenerIndex;

backDst.nRight=rectDst.nLeft+picHeight;

}

}

在本发明的一种具体实施例中，在没有发送突出显示请求的情况下，默认突出显示***客户端发送的视频数据。

在本发明的另一种具体实施例中，可以通过采用自由控制的方式实现每个客户端显示所关注的客户端的视频。

图3是本发明第二实施例中音视频通讯方法的流程图。参见图3所示，该方法包括如下步骤。

步骤301，客户端发送视频会议建立请求。

在本步骤中，客户端向服务器发送视频会议建立请求，请求建立与其他一个或者多个客户端之间的视频会议。

步骤302，建立与多个客户端之间的视频会议。

在本步骤中，服务器根据客户端发送的视频会议建立请求，建议视频会议。

步骤303，接收每个客户端发送的视频流。

在本发明的一种实施例中，在建立视频会议连接时，各个客户端将所在设备的型号、性能配置等相关信息发送给服务器，服务器在接收每个客户端发送的视频流之前，进一步通过MDM（Mobile Device Management；移动设备管理）生成各客户端所在设备对应的适配结果信息，并发送给对应的客户端，使得各客户端能够根据对应的适配结果信息采集视频流。较佳的，在接收到的适配结果信息中包括分辨率信息，帧信息等。即客户端能够根据该适配结果信息以对应的分辨率以及每秒多少帧的方式采集生成视频流并向服务器发送，由于适配结果是由MDM生成的，是与终端的性能对应的，因此对于不同配置的终端能够显示的视频流的能力是不相同的，进而达到根据客户端所在终端的性能进行个性化显示的效果。

步骤304，将接收的所有视频流进行混屏处理得到混屏视频流。

在本步骤中，服务器对接收到的视频流进行统一的控制与管理。具体为将接收的所有视频流进行混屏处理得到混屏视频流；将得到的音频数据进行混音处理。

优选地，在本步骤之前，还包括接收***客户端发送的突出显示请求，根据突出显示请求中的客户端标识信息，确定混屏视频流显示区域中的突出显示区显示的视频；或者，默认将***客户端的视频确定为突出显示区显示的视频。

步骤305，将混屏视频流发送给每个客户端。

在本步骤中，服务器将混屏处理后的视频流发送给每个客户端。其中，在混屏数据流中包含各种视频流对应的客户端的标识信息；此外，还包括混屏处理后得到的混频视频流对应的标识。举例为：分别有第一客户端、第二客户端、第三客户端和第四客户端，对应的客户端的标识信息为1、2、3、4。在发送的RTP数据包中，标记混屏视频流为0；视频流1用于标识第一客户端发送的视频流，视频流2用于标识第二客户端发送的视频流，视频流3用于标识第三客户端发送的视频流，视频流4用于标识第四客户端发送的视频流。

在本发明的一种实施例中，客户端的标识信息可以为客户端所在终端的标识信息，也可以是客户端上用户的登录信息，也可以是其他的用于区分不同客户端的标识信息。

在本发明的一种具体实施例中，由于在一般的视频会议中，最多支持8路视频流，因此，在发送的RTP数据包中，通常使用3个比特位来放置视频流对应的客户端的编号。

步骤306，发送携带第二客户端的标识信息的独立视频请求。

在本步骤中，在网络状况良好的情况下，假如第一客户端想看第二客户端发送的视频流，则向服务器发送独立视频请求，在该独立视频请求中携带第二客户端发送视频流的编号2。

在本发明的一种实施例中，在向服务器发送独立视频请求之后，服务器会根据客户端得到的适配结果信息，以及网络信息进行判断网络状态是否良好，当前客户端是否能够支持该独立视频请求。其中，客户端所在终端的性能由MDM适配取得，网络信息以5%的RTCP丢包率为阈值，作为网络传输状况是否良好的界限判断。

步骤307，计算最终丢包率，根据最终丢包率发送网络质量提醒信息。

在本步骤中，服务器在将第二客户端发送的视频流直接转发给第一客户端之前，进一步根据客户端当前进行视频传输的实际流量和当前视频传输的丢包率，以及第一客户端发送的独立视频请求所需的新增流量，计算最终丢包率，根据计算得到的最终丢包率向第一客户端发送网络质量提醒信息。使得第一客户端根据所述网络质量提醒信息，判断是否发送独立视频请求。即服务器接收第一客户端发送的携带第二客户端的标识信息的独立视频请求，计算第一客户端根据第二客户端对应的视频流所需的流量最终丢包率。进而提醒用户，在申请该独立视频请求之后网络状况，以及第一客户端是否能支持该独立视频请求，便于用户判断是否继续本次独立视频的请求。具体为，通过计算得到的最终丢包率，用户能够获知在显示第二客户端发送视频流之后，是否会导致网络会变得很卡，是否会导致当前视频不流畅，进而确认是否继续独立视频的请求。

在本发明的一种具体实施例中，根据公式ELR=LR*（1+AT/CT）计算最终丢包率；其中，ELR为最终丢包率，LR为当前视频传输的丢包率，AT为新增流量，CT为当前流量。其中，当ELR>15%时，服务器向第一客户端发送网络质量提醒信息。具体为，服务器向客户端告知，在申请新的视频流之后，可能会导致丢包率过高无法保证视频流畅。再由客户端自行判断是否继续请求。

步骤308，判断是否继续所述独立视频请求。

如果判断是则进行步骤309，反之则放弃发送当前独立视频请求。

步骤309，根据所述独立视频请求中的客户端的标识信息，将对应的第二客户端的视频流直接转发给第一客户端。

在本步骤中，服务器在接收到第一客户端发送的独立视频请求之后，在发送编号为0的混屏视频流之外，将第二客户端发送的视频流数据不做修改的转发到第一客户端，从而使得第一客户端接收到第二客户端的高保真视频数据。其中，第一客户端与第二客户端之间采用独立的传输模式。并且，RTCP数据也与混屏视频流的数据进行区分，即第二客户端将为第一客户端提供单独的传输控制机制。

步骤310，在客户端中显示所述独立视频请求中的客户端的标识信息对应的视频流。

在本步骤中，第一客户端能够显示第二客户端的高保真视频数据。第一客户端接收到了第二客户端的视频流（编号为2）和混屏视频流（编号为0）之后，能够根据自己的需求或者喜好自定义控制第二客户端的视频流和混屏视频流在客户端中的显示。

在本发明的一种实施例中，在多股视频流共存的情况下，第一客户端可以根据自己的需求，采用手势拖拽的方式在同一个界面中将视频框进行自定义需求的排版和位置放置。其中，拖拽的排版可以有九宫格形式，即所有视频流大小一致的放置在九宫格中。还可以是主从形式，即主要观看对象在中间为最大图，其余在下面以小图排成一列，另外，也可以通过不同的界面来切换显示不同的视频流。

此外，第一客户端还可以申请第三客户端和第四客户端的视频流，实现更丰富的需求体验。与此同时，在第一客户端接收到的视频总数大于1时，第一客户端可以向服务器发送独立视频释放请求，请求对释放任意一个视频流。

步骤311，发送当前视频传输的丢包率。

在传输过程中，服务器会根据客户端当前的网络状态，向客户端反馈当前的网络质量。具体为，客户端能够从服务器发送的RTCP中获取网络质量的反馈。

在本发明的一种实施例中，在获取RTCP丢包率达到预设值时，客户端会自动提示当前网络质量无法承担当前的数据压力。此外，当客户端正在接受一股以上的视频流时，客户端会自动提示，建议关闭某股视频流。

在本发明的一种具体实施例中，在RTCP丢包率大于等于5%时，客户端判断当前网络质量不佳，自动提示。

步骤312，客户端判断是否发送独立视频释放请求。

在步骤中，第一客户端接收服务器发送的当前视频传输的丢包率，根据丢包率判断是否发送独立视频释放请求。具体为，客户端可以根据在步骤311中的丢包率进行判断。例如，在网络状况比较好的情况下（丢包率小于5%），不弹出提示，第一客户端不向服务器发送独立视频释放请求。在网络状态不佳的情况下（丢包率大于等于5%），弹出提示，进而发送独立视频释放请求。

步骤313，接收客户端发送的独立视频释放请求。

在步骤313中，接收第一客户端发送的独立视频释放请求，独立视频释放请求中携带所述第一客户端需要释放的视频数据所对应的客户端的标识信息。

步骤314，根据所述独立视频释放请求中的标识信息，停止向所述第一客户端发送所所述标识信息所对应的客户端的视频流。

在本发明的一种实施例中，服务器接收第一客户端发送的携带第二客户端的标识信息（即编号2）的独立视频释放请求，根据独立视频释放请求中的编号2，停止向第一客户端转发编号2对应的第二客户端的视频流。

由上述可知，由于参与视频会议中的各个客户端的所在的终端能力（处理器、内存等硬件性能）以及各个客户端所在终端的所处的网络状况并不相同（wifi、3G、4G或局域网等），本发明提供的技术方案能够结合由MDM生成的客户端所在终端的适配结果信息，通过发送独立视频请求，使得在客户端中能够显示独立视频请求中的标识信息所对应的视频流，增加了在客户端中显示标识信息所对应的客户端所上传的视频流，以及混屏视频流之间的选择，在针对不同终端上的客户端中实现了个性化显示。解决了现有的视频会议中，每个客户端中所显现的音视频数据相同，以及每个客户端中显示的视频的无法改变的问题，即解决了现有技术中视频会议存在缺乏个性化设置支持的弊端。

本发明还公开了一种音视频通讯服务器，图4是本发明中一种音视频通讯服务器的结构示意图，参见图4所示，该服务器400包括：

第一接收模块401，用于接收每个客户端发送的视频流，将接收的所有视频流进行混屏处理得到混屏视频流；

第二接收模块402，用于接收第一客户端发送的独立视频请求，根据所述独立视频请求中的第二客户端的标识信息获取第二客户端的独立视频流；

传输模块403，用于将所述混屏视频流和第二客户端的独立视频流传输至所述第一客户端，使得所述第一客户端显示所述混屏视频流和第二客户端的独立视频流。

在上述服务器中，

所述第一接收模块401，进一步用于接收***客户端发送的突出显示请求，在所述突出显示请求中携带指定客户端的标识信息，根据所述突出显示请求中的标识信息，将接收的所有视频流进行混屏处理得到混屏视频流，其中，所述混屏视频流的显示区域中的指定区域显示所述指定客户端对应的视频；

在上述服务器中，所述传输模块403，还用于接收第一客户端发送的独立视频释放请求，所述独立视频释放请求中携带所述第一客户端需要释放的视频数据所对应的客户端的标识信息；根据所述独立视频释放请求中的标识信息，停止向所述第一客户端发送所述标识信息所对应的客户端的视频流。

在上述服务器中，该服务器进一步包括：移动设备管理模块404；

所述移动设备管理模块404，用于生成各客户端对应的适配结果信息，并发送给各客户端，以使各客户端根据对应的适配结果信息采集视频流；。

在上述服务器中，

所述第二接收模块402，进一步用于在接收第一客户端发送的独立视频请求之后，根据第一客户端当前进行视频传输的实际流量和当前视频传输的丢包率，以及所述第一客户端发送的独立视频请求所需的新增流量，计算最终丢包率，根据计算得到的最终丢包率向所述第一客户端发送网络质量提醒信息，使得所述第一客户端根据所述网络质量提醒信息，判断是否继续独立视频释放请求；

进一步地，所述传输模块403具体用于在在所述客户端确定继续所述独立视频请求时，将所述混屏视频流和第二客户端的独立视频流传输至所述第一客户端。

在上述服务器中，第二接收模块402，具体用于根据公式ELR=LR*（1+AT/CT）计算最终丢包率；其中，ELR为最终丢包率，LR为当前视频传输的丢包率，AT为新增流量，CT为当前流量；其中，当ELR>15%时，服务器向第一客户端发送网络质量提醒信息。

本发明还提供了一种音视频通讯***。图5是本发明中一种音视频通讯***的结构示意图，参见图5所示，该***包括：客户端501，以及如图4所示的服务器400。

在本发明的一种实施例中，客户端501，用于在建立视频会议之后，向服务器发送视频流。

在本发明的一种实施例中，客户端501，用于向服务器发送携带第二客户端对应的标识信息的独立视频请求，接收并显示服务器转发的第二客户端的视频。

在本发明的一种实施例中，客户端501，用于向服务器发送独立视频释放请求，所述独立视频释放请求中携带所述客户端需要释放的视频流的所对应的标识信息。

在本发明的一种实施例中，客户端501，用于接收服务器发送的当前视频传输的丢包率，根据所述丢包率判断是否发送独立视频释放请求。

在本发明的一种实施例中，客户端501，用于接收服务器发送的网络质量提醒信息，根据所述网络质量提醒信息判断是否发送独立视频释放请求。

综上所述，本发明提供的技术方案中，通过接收第一客户端发送的独立视频请求，在发送混屏数据的同时将独立视频请求中的标识信息所对应的第二客户端发送的视频流转发给第一客户端，使得第一客户端可以根据自身所在终端的适配结果信息以及所在网络的网络状况，显示独立视频请求对应的视频流。并且在数据传输的过程中，服务器可以根据第一客户端的所要发送的独立视频请求发送网络质量提醒信息。并且客户端可以根据丢包率判断是否继续请求突出显示的视频流。解决了现有的在音视频通讯中，每个与会人员所接收的音视频数据相同，以及每个与会人员所看到的视频的无法改变的缺陷。

以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。

Claims (10)

1.一种音视频通讯的方法，其特征在于，该方法包括：

接收每个客户端发送的视频流，将接收的所有视频流进行混屏处理得到混屏视频流；

接收第一客户端发送的独立视频请求，根据所述独立视频请求中的第二客户端的标识信息获取第二客户端的独立视频流；

将所述混屏视频流和第二客户端的独立视频流传输至所述第一客户端，使得所述第一客户端显示所述混屏视频流和第二客户端的独立视频流。

2.根据权利要求1所述的方法，其特征在于，所述将接收的所有视频流进行混屏处理得到混屏视频流之前，该方法进一步包括：

接收***客户端发送的突出显示请求，在所述突出显示请求中携带指定客户端的标识信息；

所述将接收的所有视频流进行混屏处理得到混屏视频流包括：

根据所述突出显示请求中的标识信息，将接收的所有视频流进行混屏处理得到混屏视频流，其中，所述混屏视频流的显示区域中的指定区域显示所述指定客户端对应的视频。

3.根据权利要求1所述的方法，其特征在于，所述将所述混屏视频流和第二客户端的独立视频流传输至所述第一客户端，使得所述第一客户端显示所述混屏视频流和第二客户端的独立视频流之后，该方法进一步包括：

接收第一客户端发送的独立视频释放请求，所述独立视频释放请求中携带所述第一客户端需要释放的视频数据所对应的客户端的标识信息；

根据所述独立视频释放请求中的标识信息，停止向所述第一客户端发送所述标识信息所对应的客户端的视频流。

4.根据权利要求1所述的方法，其特征在于，所述接收每个客户端发送的视频流之前，该方法进一步包括：

通过移动设备管理MDM生成各客户端对应的适配结果信息，并发送给各客户端，以使各客户端根据对应的适配结果信息采集视频流；

所述将所述混屏视频流和第二客户端的独立视频传输至所述第一客户端，使得所述第一客户端显示所述混屏视频流和第二客户端的独立视频流具体包括：

将所述混屏视频流和第二客户端的独立视频传输至所述第一客户端，使得所述第一客户端在同一界面显示或在不同界面切换显示所述混屏视频流和第二客户端的独立视频流。

5.根据权利要求1-4中任一项所述的方法，其特征在于，所述接收第一客户端发送的独立视频请求之后，该方法进一步包括：

根据第一客户端当前进行视频传输的实际流量和当前视频传输的丢包率，以及所述第一客户端发送的独立视频请求所需的新增流量，计算最终丢包率，根据计算得到的最终丢包率向所述第一客户端发送网络质量提醒信息，以使所述第一客户端根据所述网络质量提醒信息，判断是否继续所述独立视频请求；

所述将所述混屏视频流和第二客户端的独立视频流传输至所述第一客户端，使得所述第一客户端显示所述混屏视频流和第二客户端的独立视频流包括：

在所述客户端确定继续所述独立视频请求时，将所述混屏视频流和第二客户端的独立视频流传输至所述第一客户端，使得所述第一客户端显示所述混屏视频流和第二客户端的独立视频流。

6.根据权利要求5所述的方法，其特征在于，所述根据第一客户端当前进行视频传输的实际流量和当前视频传输的丢包率，以及所述第一客户端发送的独立视频请求所需的新增流量，计算最终丢包率包括：

根据公式ELR=LR*（1+AT/CT）计算最终丢包率；其中，ELR为最终丢包率，LR为当前视频传输的丢包率，AT为独立视频请求所需的新增流量，CT为第一客户端当前进行视频传输的实际流量；

所述根据计算得到的最终丢包率向所述第一客户端发送网络质量提醒信息包括：

确定ELR>15%时，向第一客户端发送网络质量提醒信息。

7.一种音视频通讯服务器，其特征在于，该服务器包括：

第一接收模块，用于接收每个客户端发送的视频流，将接收的所有视频流进行混屏处理得到混屏视频流；

第二接收模块，用于接收第一客户端发送的独立视频请求，根据所述独立视频请求中的第二客户端的标识信息获取第二客户端的独立视频流；

传输模块，用于将所述混屏视频流和第二客户端的独立视频流传输至所述第一客户端，使得所述第一客户端显示所述混屏视频流和第二客户端的独立视频流。

8.根据权利要求7所述的服务器，其特征在于，所述第一接收模块，进一步用于接收***客户端发送的突出显示请求，在所述突出显示请求中携带指定客户端的标识信息；根据所述突出显示请求中的标识信息，将接收的所有视频流进行混屏处理得到混屏视频流，其中，所述混屏视频流的显示区域中的指定区域显示所述指定客户端对应的视频；

所述传输模块，还用于接收第一客户端发送的独立视频释放请求，所述独立视频释放请求中携带所述第一客户端需要释放的视频数据所对应的客户端的标识信息；根据所述独立视频释放请求中的标识信息，停止向所述第一客户端发送所述标识信息所对应的客户端的视频流。

9.根据权利要求7或8所述的服务器，其特征在于，该服务器进一步包括：移动设备管理模块；

所述移动设备管理模块，用于生成各客户端对应的适配结果信息，并发送给各客户端，以使各客户端根据对应的适配结果信息采集视频流；

所述第二接收模块，进一步用于在接收第一客户端发送的独立视频请求之后，根据第一客户端当前进行视频传输的实际流量和当前视频传输的丢包率，以及所述第一客户端发送的独立视频请求所需的新增流量，计算最终丢包率，根据计算得到的最终丢包率向所述第一客户端发送网络质量提醒信息；使得所述第一客户端根据所述网络质量提醒信息，判断是否继续独立视频释放请求；

所述传输模块具体用于在在所述客户端确定继续所述独立视频请求时，将所述混屏视频流和第二客户端的独立视频流传输至所述第一客户端。

10.一种音视频通讯***，其特征在于，该***包括：客户端，以及如权利要求7～9任意一项所述的服务器。