CN107241564A - 基于ims网络架构的多流视频会议方法、装置及系统 - Google Patents

Abstract

本发明是关于一种基于IP多媒体子系统IMS网络架构的多流视频会议方法、装置及系统，其方法包括：将所述终端采集到的视频生成不同分辨率的多流视频；将所述多流视频处理为单流视频；将所述单流视频发送给视频会议平台。这样视频会议平台在接到终端发送的处理后的单流视频后，转发给所需观看该视频的终端，可以避免传统方式中由于不同终端可能传输的分辨率或传输协议等不同，还需要视频会议平台重新对其重新的解码和编码，进而造成硬件成本较大的问题。

Description

基于IMS网络架构的多流视频会议方法、装置及系统

技术领域

本发明涉及通信技术领域，尤其涉及一种基于IMS网络架构的多流视频会议方法、装置及系统。

背景技术

随着多媒体技术、计算机技术及通信网络技术的快速发展，使得音视频会议等相关技术也得到快速发展。例如，视频协议从H261、H263发展到目前主流的H264协议，音频协议从G711、G722、G728发展到宽频语音AAC-LD(Advanced Audio Coding-Low Delay，高级音频编码-低延迟)，图像分辨率从以往的CIF(Common Intermediate Format，常用视频标准化格式)、4CIF提高到高清的720P、1080P，能够接入的网络带宽也从以往的几百K提高到目前的2M、4M甚至8M，使音视频会议的效果有了质的提高。

传统的IMS(IP Multimedia Subsystem，IP多媒体子系统)视频会议通常采用星形组网的方式，将MRFP(Multimedia Resource Function Processor,多媒体资源功能处理器)作为与会终端之间的媒体交流交换和控制的枢纽设备，把某个或者某些与会终端的媒体流发送给其它与会者终端。由于IMS融合会议的媒体流至少包含语音和视频两种不同的码流，并且在双流会议的应用中还有辅流，因此MRFP网元的切换作用不像电话交换那样只是简单地将语音进行连接，而是要对语音、视频和辅流分别进行处理。

在接收媒体流的接收终端与发送媒体流的发送终端分别采用不同速率(如接收终端采用2Mbit/s速率观看采用768kbit/s速率的发送终端发送的媒体流)，或接收媒体流的接收终端与发送流体流的发送终端分别采用不同的视频协议(如接收端采用H.263 4CIF协议观看采用H.264CIF协议的发送端发送的媒体流)时，MRFP网元需要进行音视频媒体流的转换，首先MRFP需要对发送终端发送的媒体流解码，然后再按接收终端的协议和速率重新对该媒体流编码，最后将重新编码后的媒体流发送给接收终端，此过程称为速率或协议适配。由于MRFP网元进行速率或协议适配时，需要进行编解码处理，造成硬件成本高。

发明内容

为克服相关技术中存在的问题，本发明提供一种基于IP多媒体子系统IMS网络架构的多流视频会议方法、装置及系统。

根据本发明实施例的第一方面，提供一种基于IP多媒体子系统IMS网络架构的多流视频会议方法，应用于终端，所述方法包括：

将所述终端采集到的视频生成不同分辨率的多流视频；

将所述多流视频处理为单流视频；

将所述单流视频发送给视频会议平台。

根据本发明实施例的第二方面，提供一种基于IP多媒体子系统IMS网络架构的多流视频会议装置，应用于视频会议平台，所述方法包括：

接收发送终端发送的上行单流视频；

将所述上行单流视频处理为多流视频；

获取接收终端的终端参数信息及网络质量信息；

从所述多流视频中选取与所述终端参数信息、所述网络质量信息相匹配视频流；

将所述视频流处理为下行单流视频，并将所述下行单流视频发送给所述接收终端。

根据本发明实施例的第三方面，提供一种基于IP多媒体子系统IMS网络架构的多流视频会议装置，应用于终端，所述装置包括：

多流视频生成单元，用于将所述终端采集到的视频生成不同分辨率的多流视频；

单流视频处理单元，用于将所述多流视频处理为单流视频；

单流视频发送单元，用于将所述单流视频发送给视频会议平台。

根据本发明实施例的第四方面，提供一种基于IP多媒体子系统IMS网络架构的多流视频会议装置，应用于视频会议平台，所述装置包括：

单流视频接收单元，用于接收发送终端发送的上行单流视频；

上行单流视频处理单元，用于将所述上行单流视频处理为多流视频；

信息获取单元，用于获取接收终端的终端参数信息及网络质量信息；

视频流处理单元，用于将从所述多流视频中选取与所述终端参数信息、所述网络质量信息相匹配视频流；

下行单流视频生成单元，用于将所述视频流处理为下行单流视频，

下行单流视频发送单元，用于将所述下行单流视频发送给所述接收终端。

根据本发明实施例的第五方面，提供一种基于IP多媒体子系统IMS多流视频会议系统，包括：第一终端、第二终端和视频会议平台；

所述第一终端，用于将所述终端采集到的视频生成不同分辨率的多流视频；将所述多流视频处理为上行单流视频；并将所述上行单流视频发送给所述视频会议平台；

所述视频会议平台，用于所述接收第一终端发送的上行单流视频；将所述上行单流视频处理为多流视频；根据获取到的第二终端的终端参数信息和网络质量信息，从所述多流视频中选取与所述终端参数信息、所述网络质量信息相匹配视频流；将所述视频流处理为下行单流视频，并将所述下行单流视频发送给所述第二终端；

所述第二终端，用于向所述视频会议平台发送所述第二终端的终端参数信息和网络质量信息；接收所述视频会议平台发送的下行单流视频；将所述下行单流视频处理为多流视频；在所述第二终端上播放处理后得到的多流视频。

本发明的实施例提供的技术方案可以包括以下有益效果：

本发明实施例中提供的基于IP多媒体子系统IMS网络架构的多流视频会议方法，通过终端将采集到的视频生成不同分辨率的多流视频，将该多流视频处理为单流视频，并将该单流视频发送给视频会议平台。这样视频会议平台在接到终端发送的处理后的单流视频后，转发给所需观看该视频的终端，可以避免传统方式中由于不同终端可能传输的分辨率或传输协议等不同，还需要视频会议平台重新对其重新的解码和编码，进而造成硬件成本较大的问题。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本发明。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。

图1是根据一示例性实施例中提供的基于IP多媒体子系统IMS网络架构的多流视频会议系统的应用场景图；

图2是根据一示例性实施例中提供的基于IP多媒体子系统IMS网络架构的多流视频会议系统的示意图；

图3是根据一示例性实施例中基于IP多媒体子系统IMS网络架构的多流视频会议系统示意图；

图4是根据一示例性实施例中处理RTP数据的示意图；

图5是根据一示例性实施例中终端与系统中其它组件之间数据交互的信令图；

图6是根据一示例性实施例中终端与系统中其它组件之间数据交互的信令图；

图7是根据一示例性实施例中终端与系统中其它组件之间数据交互的信令图；

图8是根据一示例性实施例中终端与系统中其它组件之间数据交互的信令图；

图9是根据一示例性实施例示出的一种基于IP多媒体子系统IMS网络架构的多流视频会议方法的流程图；

图10是图9中步骤S120的流程图；

图11是根据一示例性实施例示出的一种基于IP多媒体子系统IMS网络架构的多流视频会议方法的流程图；

图12是根据一示例性实施例示出的一种基于IP多媒体子系统IMS网络架构的多流视频会议方法的流程图；

图13是根据一示例性实施例示出的一种基于IP多媒体子系统IMS网络架构的多流视频会议方法的流程图；

图14是根据一示例性实施例示出的一种基于IP多媒体子系统IMS网络架构的多流视频会议方法的流程图；

图15是根据一示例性实施例示出的一种基于IP多媒体子系统IMS网络架构的多流视频会议方法的流程图；

图16是根据一示例性实施例示出的一种基于IP多媒体子系统IMS网络架构的多流视频会议装置的示意图；

图17是图16中单流视频处理单元的示意图；

图18是根据一示例性实施例示出的一种基于IP多媒体子系统IMS网络架构的多流视频会议装置的示意图；

图19是根据一示例性实施例示出的一种基于IP多媒体子系统IMS网络架构的多流视频会议装置的示意图；

图20是根据一示例性实施例示出的一种基于IP多媒体子系统IMS网络架构的多流视频会议装置的示意图；

图21是图20中上行单流视频处理单元的示意图；

图22是图20中下行单流视频生成单元的示意图；

图23是根据一示例性实施例示出的一种基于IP多媒体子系统IMS网络架构的多流视频会议装置的示意图；

图24是是根据一示例性实施例示出的一种基于IP多媒体子系统IMS网络架构的多流视频会议装置的示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。

下面首先对于本文下述中将要出现的缩略语给出解释和定义，便于读者理解。

UE(User Equipment，用户终端)；

CSCF(Call Session Control Function，呼叫会话控制功能)；

S-CSCF(Call Session Control Function，呼叫会话控制功能)；

AS(Application Server，应用服务器)；

MRFC(Multimedia Resource Function Controller,多媒体资源功能控制器)；

MRS(Multimedia Resource Server，是MRFC+MRFP的整体称谓)；

PSI(Public Service Identity，公共服务号)，例如会议接入号就是一个PSI；

I帧(Intra-Frame)，I帧是指不依赖于其他任何帧、可独立解码的帧；

BFCP(Binary Floor Control Protocol，席位控制协议)，用于控制辅流令牌控制；

TC(Transcoding)，转码是指对输入进行decoding、对输出进行re-encoding，分为视频转码、语音转码。在转码型视频会议中，不同codec、不同分辨率/帧率的与会终端之间相互选看，需要由会议媒体资源服务器进行视频转码处理；

RTP(Real-time Transport Protocol，实时传输协议)；

RTCP(Real-time Transport Control Protocol，RTP控制协议)；

RTCP Receiver report(RTCP接收报告)；

Simulcast(多流)，是实现转发型视频会议的一种技术，与会终端作为视频源时发送多个分辨率的码流，会议平台根据观看方终端的接收分辨率能力进行转发；更进一步，接收方终端可选看多个与会者，终端本地组多画面；

PT ID(Payload Type ID)，一路视频或者一路语音码流的全部RTP包采用一个呼叫协商的ID值，称为PT值；一个视频源的多个分辨率复用一路RTP码流进行传输，使用不同的PT值标识区分；

SBC(Session Border Controller，会话边界控制器)；

A-SBC(Access-Session Border Controller，接入会话边界控制器)；

IM-MGW(IP Multimedia Media Gateway，IP多媒体网关)；

IMS core(IMS核心网)；

Conference AS(Conference Application Server，会议应用服务器)；

SIP(Session Initiation Protocol,会话初始协议)；

SDP(Session Description Protocol，会话协议)；

VAS(Voice Activated Switching，语音激活切换)；

HSS(Home Subscriber Server，归属签约用户服务器)；

UDP(User Datagram Protocol，用户数据报协议)；

IVR(Interactive Voice Response即互动式语音应答)。

由于传统的IMS视频会议受限于现网中的A-SBC及IMS中的IMS core(IMS核心网)通常只支持一路音频媒体流、一路视频媒体流和一路辅流，使得在传统的IMS视频会议中，在接入IMS视频会议的终端采用的视频传输协议或视频分辨率等不同时，IMS视频会议需要将发送终端发送的视频转换为在接收终端处理能力内的视频，即先对发送终端发送的视频解码，然后再根据接收终端的所需进行重新编码，达到速率或协议适配。接收终端才能正常处理接收到的视频，以使用户可以通过接收终端正常观看视频会议中所需的视频。即IMS视频会议通常需要将发送终端发送的视频处理为符合接收终端采用的视频传输协议、分辨率等的要求时，接收终端才能正常处理接收到的视频。这种IMS视频会议对很多与会终端传输的视频都需要转码，达到速率或协议适配，导致IMS视频会议端口的硬件成本很高。

为了解决上述技术问题，在IMS视频会议的基础上，本发明实施例中一种基于IMS网络架构的多流视频会议方法、装置及系统。

图1为本发明实施例中一种场景应用示意图。如图1所示，图1包括：视频会议平台100及多个终端200。其中，

终端200可以是发送终端，又可以是接收终端。即，终端200不但可以通过安装在该终端上的摄像头采集用户的视频，并将该视频通过视频会议平台100发送给另一终端200；还可通过视频会议平台接收其他终端200发送的视频。

受限于现有的IMS视频会议受限于现网中的A-SBC及IMS中的IMS core通常只支持一路音频媒体流、一路视频媒体流和一路辅流，因此，本发明实施例中，在终端200获取到摄像头采集到的视频后，将该视频通过降采样等方式将获取到的视频分为多份不同分辨率的视频，并将这些多份不同分辨率的视频分别编码，得到多流视频。由于IMS网络不支持这些多流视频同时传输，因此本发明实施例中将这些多流视频伪装为单流视频，并将该单流视频发送给视频会议平台100。需要说明的是，为了更清楚的表述，将发送视频的终端200称为发送终端，将需要接收视频的终端200称为接收终端。

视频会议平台100在接收到发送终端发送的单流视频后，将该单流视频重新拆分为多流视频，并根据接收终端的需要(如终端处理视频的能力和网络状况等)，将些多流视频中符合接收终端要求的视频重新伪装为单流视频发送接收终端。示例性的，以一看多为例，在A1用户通过接收终端收看A2、A3、A4、A5用户时，A2、A3、A4、A5用户分别向视频会议平台发送的视频分别是分辨率为360P+180P+90P、180P+90P、360P+90P、180P+90P的视频流，而在接收终端最高只支持分辨率为180P视频的情况下，那么A1用户会通过接受终端接收到视频会议平台100转发的A2用户的180P、A3用户的180P、A4用户的90P、A5用户的180P的视频。即视频会议平台100会将上述的A2用户的180P、A3用户的180P、A4用户的90P、A5用户的180P的视频伪装为单流视频发送给接收终端，以使接收终端在接收到视频会议平台发送的单流视频后，重新拆分为多流视频，并将该多流视频解码后在本端播放。

由于图1中的视频会议平台由Conference AS、IMS core(IMS核心网)、MRFP和MRFC等组成，因此，为了详细阐述图1中终端与视频会议平台之间的视频处理和视频传输等数据交互过程，在本发明提供的又一实施例中，如图2所示，图2包括：IMS core110、ConferenceAS120、MRFC130、MRFP140和UE150。其中，

UE150为图1中的终端200，UE150通过Gm接口与IMS core110连接。其中，Gm接口采用SIP(或SDP，即Gm(SIP/SDP)。UE150通过Gm(SIP/SDP)接口实现多媒体能力协商的功能。

UE150通过Ut(HTTP)接口实现来宾自由选看多画面功能。

MRFP140通过Mb(RTCP)接口向UE150发送指示信息，使UE150执行视频发送套餐。UE150通过Mb(RTCP)向MRFP140上报执行视频发送套餐的结果信息；UE150通过Mb(RTCP)向MRFP140发送或接收多流视频，并显示多画面和支持多流协同。

另外，通过表1描述了图2中各设备的功能。

表1

为了进一步介绍上述实施例中各组件的功能及如何扩展各接口，在本发明提供的有一实施例中，结合图2，如图3所示，提供了一种基于IMS网络架构的系统示意图，其中，图3包括：IMS core110、Conference AS120、MRFC130、MRFP140和UE150。在本发明提供的实施例中，基于已有的IMS系统架构，将接口Gm(SIP/SDP)、Mb(RTCP)、Mr(SIP)和Ut(HTTP)进行扩展，并对UE150(即终端)、Conference AS120、MRFC130和MRFP140进行功能划分。

Conference AS120，用于提供会议资源的管理、会议预定、会议调度、会议控制、用户管理、计费管理等会议业务的具体功能方面的应用。Conference AS120在IMS网络中作为PSI用户，在IMS Core110上发放会议接入号(PSI账号)，用户拨打会议接入号之后，由IMSCore110将呼叫触发给Conference AS120，Conference AS120将用户的呼叫接续给MRS，从而将用户终端150和MRS建立媒体流。

IMS core110为IMS核心网，IMS核心网中的S-CSCF、P-CSCF及HSS等设备可以为视频会议平台提供核心网的基础功能，并且和其他网络交互，屏蔽接入网和终端类型的差异性，对Conference AS120提供标准的ISC(SIP)接口。

MRFC130为IMS网络的媒体资源控制单元，解析来自Conference AS120的SIP资源控制命令，转换为对MRFP140的控制命令；MRFC130需要支持管理多个MRFP140的资源。

MRFP140为IMS网络的媒体资源处理单元，在MRFC130控制下和终端150建立音视频RTP媒体流，实现混音、视频、多画面等会议相关的媒体处理要求，并且支持编解码转换、带宽适配、码率适配等功能。

另外，终端150还可以分为语音终端、标清终端、高清终端和智真终端，语音终端和标清终端通常是电信网络的通信终端，其日常更主要的功能是拨打点对点的音视频通话，参加会议属于增强业务。高清终端和智真终端是专门用于参加高清会议和智真会议的终端，用户使用这些终端主要是为了参加会议，很少用这些终端来拨打普通的音视频电话。

下面详述图3中各组件之间的接口功能及对接口的功能扩展。

1)对Mb(RTP/RTCP)接口的扩展

Mb接口是IMS架构中定义的承载层接口，终端通过SBC或者IM-MGW与MRFP140建立媒体流。Mb接口基于RTP/RTCP协议，用于会议媒体传输，当系统支持其他网络终端的资源接入控制时，此处可以传递资源接入控制信息。

然而，在多流视频转发场景中，在多个RTP数据流通过一个UDP Port发送与接收情况下。如果采用SSRC标识数据流，在不同厂商的SBC上进行加解密会存在兼容性问题。因此，需要将多流伪装成单流RTP格式。

如图4所示，本发明实施例中在原有Mb接口的基础上对其功能扩展，直接在原有RTP头上添加一个RTP头信息(12字节标准头)，在同一个UDP Port的多流的RTP包格式数据添加一个额外的RTP头信息，将多流的RTP的SSRC/PT进行归一化处理，然后再进行加密操作，这样在SBC解密就将其当做单流处理，到服务器之后将额外的RTP头去掉，恢复多流数据，进行上行探测处理，下行发送前，再将隶属于同一个port的多路流添加额外RTP头信息处理。

其中，多流RTP格式定义为，直接在原有RTP头上添加一个RTP头信息(12字节标准头)，其中前两个字节除PT外其它保持不变，Seq根据一个port发出的数据包进行累计，Timestamp周期性递增，SSRC依赖第一个流的或其他均可。RTP多流复用的包头字段(SeqNo.、Timestamp等)定义和填写算法，需要给出详细设计方案(例如同一个Timestamp发多少个视频RTP包)，满足多流伪装成单流的RTP要求(不影响中间网元SBC的IPQoS统计)。

示例性的，表针RTP头如表1所示：

表1

终端150在通过Mb接口采用RTCP协议与MRFP140传输多流视频时，采用RTCP多流复用的方式进行。其中，一个RTP子流对应一份RTCP包，仿照“多个RTP子流共用同一个UDP通道”的做法，多份RTCP包可以通过戴上UDP通道级别的RTCP帽子，实现传送RTP子流的RTCP消息。

多流RTP传输方式中，端对端E2E的流程如下：

1、多流用户终端：摄像头采集一份视频源，通过降采样的方式得到多份分辨率的视频源，每个视频源启用一个视频编码器进行编码；

2、通过SBC透传码流；

3、MRFP根据多看多关系转发码流；

4、接收方终端接收多流视频，分别为每路RTP子流创建视频解码器进行解码，在终端上显示多画面。

其中，具体消息定义如表2所示：

表2

示例性的如表3所示：

表3

2)扩展Gm(SIP/SDP)接口

结合图5所示，本发明实施例中在原有Gm接口功能的基础上，对其扩展，使得视频会议中的多流呼叫可以兼容单流呼叫。如图5所示，终端与其他组件的数据交互如下：

步骤S501、用户通过终端输入会议ID和密码，拨打会议接入号接入会议。终端支持多流视频功能，兼容单流功能，呼叫请求SIP INVITE消息携带XML+SDP双body，其中XML含有会议ID、密码信息，SDP含有扩展的多流媒体能力描述信息。其中，SDP是基本的，XML是可选的，跟多流特性没有必然关系，携带XML的目的是实现一键入会需求，不需要通过IVR语音交互方式输入会议ID、密码。多流媒体能力描述信息是在单流媒体能力描述信息的基础上，扩展了多流simulcast的a行，如果对端不支持多流，则可简单忽略，建立单流呼叫；

步骤S502～503：Conference AS给终端应答180Ringing消息，并且Conference AS对终端入会请求消息鉴权，鉴权通过后，向MRFC请求加入指定的多流视频会议；

步骤504～505：MRFC向MRFP请求加入指定的多流视频会议，MRFP为终端分配会议端口，并响应成功消息；

步骤506～511：MRFC给Conference AS响应成功消息。Conference AS给终端响应成功消息，并通过Mr接口SIP INFO(MSML＝Join)把终端加入会议中。

多流会议的主视频流采用PT复用方式，SDP中主视频流m行只携带单个复用的PT。原来用于标识上下行各路视频流的PT则通过a＝simulcast属性行进行描述。下行广播源使用的PT与上行流中分辨率较大的流的PT一致。

SDP中还需要携带辅流和辅流控制的m行。其中辅流控制m行用于BFCP协商。

示例性的，表4示出了SDP的格式样例：

表4

其中m＝video 37052RTP/AVP 96为主流m行。由于PT复用方案下m行携带的PT只用于把多流封装成单流，对各路视频流的参数设置没有参考意义，所以a＝rtpmap只需要默认填写为H264/90000即可。对于a＝fmtp行，考虑到A-SBC上可能预留带宽资源等因素，profile-level-id还是需要设置为较高的等级。目前默认设置为64001F。

结合表5，simulcast的a行描述各个PT的上下行方向以及广播源PT。其中：send指示上行的多流各视频流PT值。softcodec参数指示对应的视频流使用的是TemporalScalability编码。如果不携带softcodec或者PT不在softcodec中描述，则代表PT不支持Temporal Scalability。softcodec参数主要是为了让MRFP识别可通过抽帧调整码率的上行视频流PT。

表5

另外，sendidc指示上行各视频流的profile-level-id，描述顺序与send保持一致，即PT＝97对应的level_idc为0A，PT＝98对应的level_idc为0D，PT＝99对应的level_idc为1F。多流会议profile-level-id采用H.264标准定义。作为例子，具体分辨率与profile-level-id的关系参考表6。

表6

分辨率	profile_idc	profile_iop	level_idc	profile_level_id
					90P	H/64	00000000	1.0/A	64000A
180P	H/64	00000000	1.3/D	64000D
					360P	H/64	00000000	3/1E	64001E
720P	H/64	00000000	3.1/1F	64001F
					1080P	H/64	00000000	4/28	640028

综上，本实施例通过扩展SIP/SDP接口，在单流SDP标准基础上，扩展a行，实现多流视频呼叫向下兼容单流呼叫。

3)扩展Ut(HTTP)接口

在终端接入到视频会议当中后，可以选定观看模式，指定观看与会方。由于本发明实施例中传输多流视频，因此，终端需要将自身的终端参数信息发送给视频会议平台，以使视频会议平台转发与终端参数信息相匹配的多流视频。因此，如图6所示，用户通过终端选看多画面的流程可以包括以下步骤：

步骤601、终端用户选定观看模式后，指定每个屏幕对应的与会方。终端发送HTTP消息给Conference AS，携带<与会者,PT,显示区域相对大小,可接受的最小分辨率,可接受的最大分辨率,优先级>列表、是否看辅流等信息。

广播源由会议决定，与会者固定填写为“broadcast”。可扩展为支持接收多个广播源，终端通过查询会议详情获知会议支持的广播源数量，在选看多画面请求中，可自由选看若干个broadcast视频源。

用户无法指定的，但可选择是否接收。不接收则将该节点的与会者置为“NULL”即可。其他屏幕的处理类似。其中，

子画面显示区域相对大小：子画面在多画面中权重，采用子画面的相对大小来量化(不需要绝对大小)。会议平台根据子画面权重给子画面分配带宽，以带宽分配的变更驱动接收分辨率能力调整。当前算法是：按多画面模式定死每个子画面的权重值。不接收视频的子画面权重参数无意义，MRFP不为其分配带宽。

例如，四画面Layout，当前子画面1看终端、权重50，子画面2没看人、权重10，子画面3没看人、权重10。此时，全部下行可用带宽都分配给子画面1使用。接着，软终端发送增量选看请求，子画面2看UE#B、权重10，此时，子画面1占比为50÷(50+10)，子画面2占比为10÷(50+10)。

可接受的最小分辨率：低于此分辨率则不转发。例如，MSG5100E采用电视机作显示器，小画面的最低分辨率可能要达到180P，而不是90P，具体要UCD设计针对多流终端型号进行设计。

可接受的最大分辨率：设定每个子画面的最大分辨率，即使全部子画面要同时能达到最大分辨率，也不会超出软终端的解码能力。

优先级：当两个子画面的大小相同，如果按等比分配带宽不能匹配到最合适分辨率能力，则资源向优先级高的子画面倾斜。大小不同的子画面不会比较优先级。

对于辅流，指示是否接收辅流。子画面屏幕则填写对应与会方的ID。

此HTTP消息为增量消息，则每次设定layout模式时，只需要和上一次对比，把差异部分携带到消息中即可。

对于多画面模式变化，不再看的子画面也要在请求消息中携带。

对于子画面权重大小有相对变化，则要带全量请求。

如果只是被选看的与会者变化，可以增量请求。

终端在发送HTTP消息后需要启动对应PT的编解码器，准备接收响应的视频流并解码。

步骤602、Conference AS收到HTTP消息后，更新与会者间的选看关系，转换为Mr接口消息下发调整分辨率的INFO请求给MRFC。

步骤603、MRFC根据Conference AS提供的<与会者,PT,显示区域相对大小,可接受的最小分辨率,可接受的最大分辨率,优先级>列表，下发Mod消息给MRFP，修改PT和与会方的转发关系。

步骤604、MRFP根据MRFC下发的<与会者,PT,显示区域相对大小,可接受的最小分辨率,可接受的最大分辨率,优先级>列表调整转发关系，并返回响应给MRFC。

如果某个视频源当前发送的3个分辨率都无法与Conference AS下发的分辨率匹配，则MRFP转发不高于Conference AS要求分辨率的视频源中分辨率较高的一路视频源。如Conference AS要求360p分辨率，但是视频源上行的3路视频分辨率分别为720p、180p、90p，则MRFP应该转发180p。

步骤605-606：返回响应给终端。终端可以根据UCD设计提示用户操作成功。

4)扩展Mb(RTCP)接口

Mb是MRFP与终端的媒体流接口，Mb接口是IMS架构中定义的承载层接口，终端通过SBC或者IM-MGW与MRFP建立媒体流。Mb接口基于RTP/RTCP协议，用于会议媒体传输，当系统支持其他网络终端的资源接入控制时，此处可以传递资源接入控制信息。

在本发明实施例中提供的多流转发方式中，定义分辨率阶梯，例如90p、180p、360p、720p、1080p分辨率5个阶梯。多流终端上行发送多流采用堆叠组合方式，例如发送某个分辨率时需连带把更低的若干个分辨率一起发出来，例如360P+180P+90P就是一种发送套餐。因此，如图7所示，图7中示出了MRFP向终端发送视频发送套餐及MRFP根据视频发送套餐向MRFP发送多流视频等的流程，结合图7，该流程可以包括如下步骤：

步骤701、Conference AS根据新广播源触发更新<视频源,接收者列表及其接收分辨率能力>信息，初始化新广播源的起步发送套餐＝min(max(接收者列表及其接收分辨率能力)，终端平台上限)，修改广播源用户发送套餐以观看者的最高分辨率而定。

Conference AS初始化广播新用户终端的发送套餐，广播源用户发送套餐以观看者的最高分辨率而定，且广播源用户的最低发送套餐为90p+180p+360。终端自适应多流协同，保证低分辨率质量优先，并通过RTCP上报各分辨率可用性。通过后续接收者的带宽探测反馈机制，Conference AS调整发送套餐。Conference AS不需处理具体分辨率码流的可用性情况，Conference AS只需要根据视频源的观看者接收分辨率能力，决定视频源的上行发送套餐。即使视频源的上行探测带宽不到该发送套餐要求，也可以给该视频源下发发送套餐要求。

当高分辨率没有观看者时，可以关掉高分辨率，Conference AS下发调整发送套餐命令。

步骤702、MRFC把调整发送套餐请求转发给MRFP。

步骤703、MRFP把调整发送套餐请求通过90p的RTCP通道以RTCP扩展消息转发给终端，判断哪些与会者要180p、360p，准备做平滑切换。对期望180p及以上的接收者，在未收到180p的I帧前，继续转发90p；对期望360p的接收者，在未收到360p的I帧前，继续转发90p或180p。

步骤704、终端从90p的RTCP通道收到发送90p+180p+360p请求消息，判断自己上行带宽够发180p、360p，执行发送套餐切换和上行多流协同处理。后续，执行“上行带宽探测信息收集流程”。其中，上行带宽探测信息收集流程主要是通过若干周期(如0.5s/T)的丢包率、时延、抖动信息推测出得到的上行带宽探测值，实现上行带宽探测信息收集流程。

步骤705、MRFP切换转发90p、180p、360p给相关与会者。

步骤706、Conference AS监控<视频源,接收者列表及其接收分辨率能力>信息发生变更，则修改视频源的发送套餐，例如由之前的90p+180p+360p套餐切换为90p+180p+720。720p发送套餐要给出720p分辨率的下限[360p,720p]，1080p发送套餐要给出1080p分辨率的下限[360p,1080p]。

步骤707、MRFC把调整发送套餐请求转发给MRFP。

步骤708、MRFP把调整发送套餐请求转发给终端

步骤709、MRFP判断哪些与会者要720p。需要把所有在看360p、但接不住720p的观看者降为观看180p(原因是发送方是720p和360p互斥)。对期望720p的接收者，不需要180p过渡，直接等待720p的I帧转发。

步骤710、终端收到发送720p的请求，判断自己上行带宽够发720p，执行发送套餐切换和上行多流协同处理，开始发送90p+180p+720p。后续，执行“上行带宽探测信息收集流程”。

步骤711、终端停发360p，开始发720p，360p和720p共用PT值。后续，执行“多流终端上行带宽探测信息收集流程”，在多个终端中，通过分别获取上行带宽探测值来达到上行带宽探测信息收集的目的。

步骤712、MRFP向终端请求720p I帧，MRFP收到终端的720p I帧，切换转发720p给相关与会者。

步骤713～715、MRFP向终端请求180p I帧。MRFP收到终端的180p I帧，切换转发180p给相关与会者。

5)扩展Mb(RTCP)接口

本实施例中，通过扩展RTCP APP接口(上行)，在终端获取到视频会议平台(FRFP)转发的多流视频后，终端会向FRFP上报多流视频的可用性状况，以使FRFP可以根据终端上报的情况调整视频发送套餐。因此，如图8所示，终端上报多流视频的可用性状况可以包括如下步骤：

步骤801：终端按照会议平台指示的发送套餐发送多流。终端上行网络质量状况良好时，需采用发冗余包方式上探带宽。终端只探发送套餐范围内的PT值带宽，MRFP也按这个原则预留资源。

终端上行发送多个分辨率的码流，自适应多流协同，包括两个功能：各分辨率码流分别探测带宽，各自调帧率。终端在会议平台给定的发送套餐下自主做多流协同，上行码流优先级语音>辅流>主视频流，主视频流低分辨率>高分辨率。

如果720p(最高分辨率)码流帧率过低，则终端自主调分辨率，根据带宽探测，可调高、调低分辨率，但必须高于180p(第二分辨率)、不高于发送套餐限定。

终端评估每个上行的分辨率码流可用性，质量情况帧率/码率只有达到一定要求，才可用于转发给接收方，给MRFP上报可用性。终端上报可用分辨率是实发的分辨率，例如发送套餐720p，最高分辨率在[360p,720p]范围内自适应，均为可用，终端上报给会议平台可用分辨率时，上报实发的分辨率，而不是发送套餐名义上的720p。

步骤802、MRFP定时反馈接收者报告，反馈每个子画面的网络质量信息，包括丢包率、时延、抖动。

步骤803、终端的上行带宽探测值是通过最近若干周期(0.5秒/周期)的丢包率、时延、抖动信息推测出来，通过RTCP扩展消息上报终端的上行可用分辨率列表list of<PT值,分辨率,是否可用>，PT值与分辨率的对应关系由终端决定。终端上报时机是与会终端上行可用分辨率发生变更，任一个分辨率的可用性发生变更就要报一次全量信息，90p也可报为不可用。

步骤804、MRFP通过Mp接口用户腿上报终端的上行状况信息，消息格式如下：

示例性的，终端收发信息如下：

上行发送套餐＝<PT值,分辨率1,是否可用>,<PT值,分辨率2,是否可用>,……

步骤805、MRFC收到MRFP上报终端的上行状况信息，通过Mr接口用户腿转发给Conference AS。

步骤806、Conference AS通过Mr接口用户腿修改终端的上行可用分辨率列表。Conference AS不需处理具体分辨率码流的可用性情况，Conference AS只需要根据视频源被观看的分辨率诉求，决定视频源的上行发送套餐。即使视频源的上行探测带宽不到该发送套餐要求，也可以给该视频源下发发送套餐要求。

示例性的，INFO(MSML)设置各分辨率可用性：

上行发送套餐＝<PT值,分辨率1,是否可用>,<PT值,分辨率2,是否可用>,……

步骤807、MRFC把修改终端的上行可用分辨率列表的请求消息转发给MRFP。

步骤808、MRFP按照Conference AS指示的终端上行可用分辨率列表，与相应观看者终端的接收分辨率能力取交集转发视频。网络质量状况良好时，需采用发冗余包方式上探带宽。MRFP记录更新该视频源的可用分辨率，不可用视频源分辨率不参与转发。任何一档由不可用变为可用，MRFP需要给软终端下发I帧请求后，才能使用这个分辨率进行转发。

因此，为了解决相关技术问题，并结合上述各实施例，在本发明提供的又一实施例中，如图9所示，本发明提供了一种基于IP多媒体子系统IMS网络架构的多流视频会议方法，应用于终端，该方法可以包括如下步骤：

在步骤S110中，将终端采集到的视频生成不同分辨率的多流视频。

如前述实施例中所述，终端可以是标清终端、高清终端或智真终端等，用户参加视频会议时，需要通过安装在终端上的摄像头采集用户的视频。

需要说明的是，摄像头可以是普通的单眼摄像头，即这种摄像头一次只能采集一路单一分辨率的视频。为了将单眼摄像头采集到的视频分成多流视频，可以采用降采样的方式，对获取到的一路视频流进行降采样，得到多份不同分辨率的视频。示例性的，在单眼摄像头采集到的视频为360P时，可以通过降采样的方式得到另外两份分辨率分别为180P和90P的视频，这样就可以得到360P+180P+90P的三路视频。

另外，还可以通过多眼摄像头进行一采多编的方式，一次获取多流不同分辨率的视频。

在步骤S120中，将多流视频处理为单流视频。

由于IMS网络架构只支持一个音频媒体流、一个视频媒体流和一个辅流，为了在IMS网络架构下可以同时多流视频传输，本发明实施例中将获取到的多流视频处理为单流视频进行传输，以符合IMS网络架构的要求。

在步骤S130中，将单流视频发送给视频会议平台。

这样在将多流视频处理为单流视频后，就可以发送给视频会议平台，以使视频会议平台将其处理后转发给其他需要观看视频的终端。

本发明实施例中提供的基于IP多媒体子系统IMS网络架构的多流视频会议方法，通过终端将采集到的视频生成不同分辨率的多流视频，将该多流视频处理为单流视频，并将该单流视频发送给视频会议平台。这样视频会议平台在接到终端发送的处理后的单流视频后，转发给所需观看该视频的终端，可以避免传统方式中由于不同终端可能传输的分辨率或传输协议等不同，还需要视频会议平台重新对其重新的解码和编码，进而造成硬件成本较大的问题。

作为图9方法的细化，在本发明的另一实施例中，如图10所示，步骤S120还可以包括如下步骤：

在步骤S121中，将多流视频分别编码，得到多流编码视频。

在生成多流视频后，还需要对每一流的视频进行编码。其中，多流编码视频为多流实时传输协议RTP包格式数据。

在步骤S122中，在多流RTP包格式数据上添加RTP头信息，得到单流视频。

在RTP包格式数据上添加RTP头信息，就可以将多流视频伪装成单流视频，由于此步骤在前述实施例中已有详细阐述，这里就不在赘述。

作为图9方法的细化，在本发明的另一实施例中，如图11所示，在步骤S110之前，该方法还可以包括如下步骤：

在步骤S101中，获取终端的终端参数信息。

终端参数信息，可以是终端的上行传输带宽、下行传输带宽及可接收的视频最大分辨率等参数信息。

在步骤S102中，将终端参数信息发送给视频会议平台，以使视频会议平台将根据接收到的终端参数信息生成的视频发送套餐发送给终端。

视频会议平台在接收到终端发送的终端参数信息之后，就可以根据该终端参数信息，生成与之相对应的视频发送套餐。

在步骤S103中，接收视频会议平台发送的视频发送套餐。

这样终端在接收到视频会议平台发送的视频发送套餐之后，就可以根据该视频发送套餐，执行步骤S110的流程内容。

作为图9方法的细化，在本发明的另一实施例中，如图12所示，在步骤S110之前，该方法还可以包括如下步骤：

在步骤S104中，获取用户在终端中输入的用户信息。

这里的用户信息主要的用户输入的ID和密码。

在步骤S105中，将用户信息发送给视频会议平台，以使视频会议平台在对用户信息验证通过后，为终端分配会议端口，并向终端发送接入视频会议成功信息。

在步骤S106中，接收视频会议平台发送的接入视频会议成功信息。

用户通过向视频会议平台发送用户的ID和密码，请求接入视频会议平台。视频会议平台在对用户发送的ID和密码验证通过之后，会向终端发送接入视频会议成功信息。

在本发明提供的又一实施例中，如图13所示，又提供了一种基于IP多媒体子系统IMS网络架构的多流视频会议方法，应用于视频会议平台，该方法可以包括如下步骤：

在步骤S210中，接收发送终端发送的上行单流视频。

在步骤S220中，将上行单流视频处理为多流视频。

在步骤S230中，获取接收终端的终端参数信息及网络质量信息；

在步骤S240中，从多流视频中选取与终端参数信息、网络质量信息相匹配视频流。

在步骤S250中，将所述视频流处理为下行单流视频，并将所述下行单流视频发送给所述接收终端。

在该实施例中，由于该单流接收视频为终端将多流视频伪装成的单流视频，里面可以包括多份不同分辨率的视频。在多看多的视频会议中，需要观看该视频的其他终端用户可能有多个，而每个终端用户首先与带宽、最大分辨率等所限，需要将符合接收终端用户要求的视频发送给该终端用户。需要说明的是，将终端向视频会议平台发送数据时称为上行，将视频会议平台向终端发送数据时称为下行。

因此，还需要将该单流视频处理为多流视频。针对某一接收端的用户，从这些多流视频中筛选符合该接收端用户所需的视频发送，以满足该接收端用户正常参加观看视频的要求。

需要说明的是，该单流接收视频可以是复合实时传输协议RTP包格式数据，将所述单流接收视频处理为多流视频，具体可以是去除所述复合RTP包格式数据的头信息，得到所述多流视频。在RTP包格式数据上添加RTP头文件，可以得到下行单流视频。

为了使需要接收多流视频的接收端用户可以正常观看该视频，需要从多流视频中选取与该接收端用户相匹配的视频，如满足带宽、分辨率等要求等。另外，将多流视频伪装为单流视频的方式在前述实施例中已有较为详细的阐述，这里就不在赘述。

作为图13方法的细化，如图14所示，在本发明提供的又一实施例中，该方法还可以包括如下步骤：

在步骤S250中，根据发送终端的终端参数信息和网络质量信息，生成视频发送套餐。

在步骤S260中，将视频发送套餐发送给发送终端，以使发送终端根据视频发送套餐向视频会议平台发送视频数据。

视频会议平台在接收到终端发送的终端参数信息之后，就可以依据该终端参数信息制定视频发送套餐，避免终端将无法满足条件的视频也发送给视频会议平台，导致资源浪费的现象。

作为图13方法的细化，如图15所示，在本发明提供的又一实施例中，该方法还可以包括如下步骤：

在步骤S281中，接收发送终端发送的用户信息。

在步骤S282中，当用户信息通过验证之后，为发送终端分配会议端口。

在步骤S283中，向发送终端发送接入视频会议成功信息。

该用户信息可以是用户的ID和密码，只有视频会议平台验证该ID和密码通过之后，终端才能有接入该视频会议的资格。这时视频会议平台会为该终端用户分配会议端口，在完成之后，向终端发送接入视频会议成功的反馈信息。

本发明实施例中提供的基于IP多媒体子系统IMS网络架构的多流视频会议方法，通过终端将采集到的视频生成不同分辨率的多流视频，将该多流视频处理为单流视频，并将该单流视频发送给视频会议平台。这样视频会议平台在接到终端发送的处理后的单流视频后，转发给所需观看该视频的终端，可以避免传统方式中由于不同终端可能传输的分辨率或传输协议等不同，还需要视频会议平台重新对其重新的解码和编码，进而造成硬件成本较大的问题。

需要说明的是，上述各实施例可以相互结合、相互参考，为了避免重复赘述，很多技术细节只在一个实施例中详细阐述，在其他实施例中没有赘述，需要各实施例通过相互结合、相互参考。因此，对于技术的理解不应局限于一个实施例中。

通过以上的方法实施例的描述，所属领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：只读存储器(ROM)、随机存取存储器(RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

另外，作为对上述各实施例的实现，本发明实施例还提供了一种基于IP多媒体子系统IMS网络架构的多流视频会议装置，该装置位于终端中，如图16所示，该装置包括：多流视频生成单元10、单流视频处理单元20和单流视频发送单元30，其中，

多流视频生成单元10，用于将所述终端采集到的视频生成不同分辨率的多流视频；

单流视频处理单元20，用于将所述多流视频处理为单流视频；

单流视频发送单元30，用于将所述单流视频发送给视频会议平台。

在本发明又一实施例中，基于图16，如图17所示，所述单流视频处理单元20，包括：视频编码模块21和单流视频生成模块22，其中，

视频编码模块21，用于将所述多流视频分别编码，得到多流编码视频，所述多流编码视频为多流实时传输协议RTP包格式数据；

单流视频生成模块22，用于在所述多流RTP包格式数据上添加RTP头信息，得到所述单流视频。

在本发明又一实施例中，基于图16，如图18所示，所述装置还包括：

参数信息获取单元40，用于获取所述终端的终端参数信息；

参数信息发送单元50，用于将所述终端参数信息发送给所述视频会议平台，以使所述视频会议平台根据接收到的所述终端参数信息生成的视频发送套餐发送给所述终端；

视频发送套餐接收单元60，用于接收所述视频会议平台发送的视频发送套餐。

在本发明又一实施例中，基于图16，如图19所示，所述装置还包括：

用户信息获取单元70，用于获取用户在所述终端中输入的用户信息；

用户信息发送单元80，用于将所述用户信息发送给所述视频会议平台，以使所述视频会议平台在对所述用户信息验证通过后，为所述终端分配会议端口，并向所述终端发送接入视频会议成功信息；

成功信息接收单元90，用于接收所述视频会议平台发送的接入视频会议成功信息。

本发明实施例又提供了一种基于IP多媒体子系统IMS网络架构的多流视频会议装置，该装置位于视频会议平台中，如图20所示，该装置包括：

单流视频接收单元91，用于接收发送终端发送的上行单流视频；

上行单流视频处理单元92，用于将所述上行单流视频处理为多流视频；

视频流处理单元93，用于将从所述多流视频中选取与所述终端参数信息、所述网络质量信息相匹配视频流；

下行单流视频生成单元94，用于将所述视频流处理为下行单流视频，

下行单流视频发送单元95，用于将所述下行单流视频发送给所述接收终端。

在本发明又一实施例中，基于图20，如图21所示，所述上行单流视频为复合实时传输协议RTP包格式数据，所述上行单流视频处理单元92，包括：

多流视频生成模块921，用于去除所述复合RTP包格式数据的头信息，得到所述多流视频。

在本发明又一实施例中，基于图20，如图22所示，所述下行单流视频生成单元94，包括：

下行单流视频生成模块941，用于在所述RTP包格式数据上添加RTP头文件，得到所述下行单流视频。

在本发明又一实施例中，基于图20，如图23所示，所述装置还包括：

视频发送套餐生成单元95，用于根据所述发送终端的终端参数信息和所述网络质量信息，生成视频发送套餐；

视频发送套餐发送单元96，用于将所述视频发送套餐发送给所述发送终端，以使所述发送终端根据所述视频发送套餐向所述视频会议平台发送视频数据。

在本发明又一实施例中，基于图20，如图24所示，所述装置还包括：

用户信息接收单元981，用于接收所述发送终端发送的用户信息；

会议端口分配单元982，用于在所述用户信息通过验证之后，为所述发送终端分配会议端口；

成功信息发送单元983，用于向所述发送终端发送接入视频会议成功信息。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

另外，基于上述各实施例的实现，本发明实施例中还提供了一种基于IP多媒体子系统IMS多流视频会议系统，结合图1，该系统包括：第一终端、第二终端和视频会议平台。其中，

所述第一终端，用于将所述终端采集到的视频生成不同分辨率的多流视频；将所述多流视频处理为上行单流视频；并将所述上行单流视频发送给所述视频会议平台；

所述视频会议平台，用于所述接收第一终端发送的上行单流视频；将所述上行单流视频处理为多流视频；根据获取到的第二终端的终端参数信息和网络质量信息，从所述多流视频中选取与所述终端参数信息、所述网络质量信息相匹配视频流；将所述视频流处理为下行单流视频，并将所述下行单流视频发送给所述第二终端；

所述第二终端，用于向所述视频会议平台发送所述第二终端的终端参数信息和网络质量信息；接收所述视频会议平台发送的下行单流视频；将所述下行单流视频处理为多流视频；在所述第二终端上播放处理后得到的多流视频。

其中，第一终端相当于图1中的一个终端200，第二终端为图1中的另一个终端200。由于视频会议平台与终端之间的数据交互关系已经在前述实施例中有了较为详细的阐述，这里不在赘述，可以结合图1及其实施例来说明本实施例中提供的系统。

可以理解的是，本发明可用于众多通用或专用的计算系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

本发明可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本发明，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由下面的权利要求指出。

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。

Claims (19)

1.一种基于IP多媒体子系统IMS网络架构的多流视频会议方法，应用于终端，其特征在于，所述方法包括：

将所述终端采集到的视频生成不同分辨率的多流视频；

将所述多流视频处理为单流视频；

将所述单流视频发送给视频会议平台。

2.根据权利要求1所述的基于IMS网络架构的多流视频会议方法，其特征在于，所述将所述多流视频处理为单流视频，包括：

将所述多流视频分别编码，得到多流编码视频，所述多流编码视频为多流实时传输协议RTP包格式数据；

在所述多流RTP包格式数据上添加RTP头信息，得到所述单流视频。

3.根据权利要求1所述的基于IMS网络架构的多流视频会议方法，其特征在于，所述方法还包括：

获取所述终端的终端参数信息；

将所述终端参数信息发送给所述视频会议平台，以使所述视频会议平台将根据接收到的所述终端参数信息生成的视频发送套餐发送给所述终端；

接收所述视频会议平台发送的视频发送套餐，并根据所述视频发送套餐执行所述将所述终端采集到的视频生成不同分辨率的多流视频的步骤。

4.根据权利要求1所述的基于IMS网络架构的多流视频会议方法，其特征在于，在所述将所述终端采集到的视频生成不同分辨率的多流视频之前，所述方法还包括：

获取用户在所述终端中输入的用户信息；

将所述用户信息发送给所述视频会议平台，以使所述视频会议平台在对所述用户信息验证通过后，为所述终端分配会议端口，并向所述终端发送接入视频会议成功信息；

接收所述视频会议平台发送的接入视频会议成功信息。

5.一种基于IP多媒体子系统IMS网络架构的多流视频会议方法，应用于视频会议平台，其特征在于，所述方法包括：

接收发送终端发送的上行单流视频；

将所述上行单流视频处理为多流视频；

获取接收终端的终端参数信息及网络质量信息；

从所述多流视频中选取与所述终端参数信息、所述网络质量信息相匹配视频流；

将所述视频流处理为下行单流视频，并将所述下行单流视频发送给所述接收终端。

6.根据权利要求5所述的基于IMS网络架构的多流视频会议方法，其特征在于，所述上行单流视频为复合实时传输协议RTP包格式数据，所述将所述上行单流视频处理为多流视频，包括：

去除所述复合RTP包格式数据的头信息，得到所述多流视频。

7.根据权利要求5所述的基于IMS网络架构的多流视频会议方法，其特征在于，所述视频流为RTP包格式数据，所述将所述视频流处理为下行单流视频，包括：

在所述RTP包格式数据上添加RTP头文件，得到所述下行单流视频。

8.根据权利要求5所述的基于IMS网络架构的多流视频会议方法，其特征在于，所述方法还包括：

根据所述终端参数信息和所述网络质量信息，生成视频发送套餐；

将所述视频发送套餐发送给所述发送终端，以使所述发送终端根据所述视频发送套餐向所述视频会议平台发送视频数据。

9.根据权利要求5所述的基于IMS网络架构的多流视频会议方法，其特征在于，所述方法还包括：

接收所述发送终端发送的用户信息；

当所述用户信息通过验证之后，为所述发送终端分配会议端口；

向所述发送终端发送接入视频会议成功信息。

10.一种基于IP多媒体子系统IMS网络架构的多流视频会议装置，应用于终端，其特征在于，所述装置包括：

多流视频生成单元，用于将所述终端采集到的视频生成不同分辨率的多流视频；

单流视频处理单元，用于将所述多流视频处理为单流视频；

单流视频发送单元，用于将所述单流视频发送给视频会议平台。

11.根据权利要求10所述的基于IMS网络架构的多流视频会议装置，其特征在于，所述单流视频处理单元，包括：

视频编码模块，用于将所述多流视频分别编码，得到多流编码视频，所述多流编码视频为多流实时传输协议RTP包格式数据；

单流视频生成模块，用于在所述多流RTP包格式数据上添加RTP头信息，得到所述单流视频。

12.根据权利要求10所述的基于IMS网络架构的多流视频会议装置，其特征在于，所述装置还包括：

参数信息获取单元，用于获取所述终端的终端参数信息；

参数信息发送单元，用于将所述终端参数信息发送给所述视频会议平台，以使所述视频会议平台根据接收到的所述终端参数信息生成的视频发送套餐发送给所述终端；

视频发送套餐接收单元，用于接收所述视频会议平台发送的视频发送套餐。

13.根据权利要求10所述的基于IMS网络架构的多流视频会议装置，其特征在于，所述装置还包括：

用户信息获取单元，用于获取用户在所述终端中输入的用户信息；

用户信息发送单元，用于将所述用户信息发送给所述视频会议平台，以使所述视频会议平台在对所述用户信息验证通过后，为所述终端分配会议端口，并向所述终端发送接入视频会议成功信息；

成功信息接收单元，用于接收所述视频会议平台发送的接入视频会议成功信息。

14.一种基于IP多媒体子系统IMS网络架构的多流视频会议装置，应用于视频会议平台，其特征在于，所述装置包括：

单流视频接收单元，用于接收发送终端发送的上行单流视频；

上行单流视频处理单元，用于将所述上行单流视频处理为多流视频；

信息获取单元，用于获取接收终端的终端参数信息及网络质量信息；

视频流处理单元，用于将从所述多流视频中选取与所述终端参数信息、所述网络质量信息相匹配视频流；

下行单流视频生成单元，用于将所述视频流处理为下行单流视频，

下行单流视频发送单元，用于将所述下行单流视频发送给所述接收终端。

15.根据权利要求14所述的基于IMS网络架构的多流视频会议装置，其特征在于，所述上行单流视频为复合实时传输协议RTP包格式数据，所述上行单流视频处理单元，包括：

多流视频生成模块，用于去除所述复合RTP包格式数据的头信息，得到所述多流视频。

16.根据权利要求14所述的基于IMS网络架构的多流视频会议装置，其特征在于，所述下行单流视频生成单元，包括：

下行单流视频生成模块，用于在所述RTP包格式数据上添加RTP头文件，得到所述下行单流视频。

17.根据权利要求14所述的基于IMS网络架构的多流视频会议装置，其特征在于，所述装置还包括：

视频发送套餐生成单元，用于根据所述终端参数信息和所述网络质量信息，生成视频发送套餐；

视频发送套餐发送单元，用于将所述视频发送套餐发送给所述发送终端，以使所述发送终端根据所述视频发送套餐向所述视频会议平台发送视频数据。

18.根据权利要求14所述的基于IMS网络架构的多流视频会议装置，其特征在于，所述装置还包括：

用户信息接收单元，用于接收所述发送终端发送的用户信息；

会议端口分配单元，用于在所述用户信息通过验证之后，为所述发送终端分配会议端口；

成功信息发送单元，用于向所述发送终端发送接入视频会议成功信息。

19.一种基于IP多媒体子系统IMS多流视频会议系统，其特征在于，包括：第一终端、第二终端和视频会议平台；

所述第一终端，用于将所述终端采集到的视频生成不同分辨率的多流视频；将所述多流视频处理为上行单流视频；并将所述上行单流视频发送给所述视频会议平台；

所述视频会议平台，用于所述接收第一终端发送的上行单流视频；将所述上行单流视频处理为多流视频；根据获取到的第二终端的终端参数信息和网络质量信息，从所述多流视频中选取与所述终端参数信息、所述网络质量信息相匹配视频流；将所述视频流处理为下行单流视频，并将所述下行单流视频发送给所述第二终端；

所述第二终端，用于向所述视频会议平台发送所述第二终端的终端参数信息和网络质量信息；接收所述视频会议平台发送的下行单流视频；将所述下行单流视频处理为多流视频；在所述第二终端上播放处理后得到的多流视频。