一种在互联网上多点视频会议多屏幕显示的方法
发明领域
本发明属于计算机网络多媒体通信领域，具体地说，涉及一种在互联网上进行多点视频会议时，多会场视频数据的传输与显示的方法。
发明背景
随着计算机网络和多媒体技术的迅速发展，视频会议系统逐渐应用在政府部门、商业领域、教育领域、医疗领域以及个人生活等许多方面。911事件和SARS疫情之后，国内外视频会议业务需求更是急剧上升，视频业务已渗透到各个行业。一般预测，今后五年全球视频会议和相关的语音会议市场、数据会议市场总量将以平均35％-45％的速度成长。美国IDG预测的2004年度IT业界热点技术中，视频会议技术位居前列。著名的通信领域研究机构WainHouse预测，2004年将是视频会议系统的成长“拐点”。而据IDC统计：2003年国内视频会议市场大概10亿元，随着企业集团的需求猛增，未来1-2年内将急骤上升，2004年和2005年中国视频会议市场增长率将保持在32％以上。根据目前我国大中企业的数量推算，仅企业视频会议市场的潜在规模就有100多亿元
在进行多点会议时，H.323系统通常情况下，会以两种方式传送视频图像：一种是混图模式，也就是将用户终端所要求的几路视频混合为一个屏幕，并发送给会议终端(典型情况为将4路视频混合为一个屏幕)，另一种是主席模式，专门发送由会议主席(或其它指定方式，例如有发言的一路视频)指定的某一路视频。这两种方式都存在如下两个缺陷：
1.交互性差，不能同时看到所有会场的视频图像
无论是混图模式还是主席模式，都不可能看到所有的与会者的视频信息(在典型混图模式下，最多只能看到四路变小的视频)，甚至不知道有哪些与会人员，因此无法根据自身的需要与某个或某些与会人员进行交流。用户终端始终只能被动地看到一个会场的视频图像(主席方式下)或由多会场图像混合而成的视频图像(混图方式下)，与会者得到的视频信息非常有限，严重影响了会议的效果。在网络带宽波动时，用户会可能看不清楚视频。这种情况并不适应当前的网络带宽快速增加和显示屏大幅变大的趋势。
2.消耗大量的CPU资源，多点控制单元容量提升困难。
多点控制单元(MCU)在每接收到一路视频后，都会将其解码，放在缓冲区中。在混图模式下，MCU需要将已解码的图像进行重新布局，形成一个混合图像(简称“混图”)，然后再对混图进行编码，最后才发送给各个终端。MCU的这个步骤耗费了大量的CPU资源，从而使MCU容量的提升相当困难。主席模式下，虽然减少了混图这个步骤，但是编码和解码必不可少。因此MCU容量提升的空间也很有限。
本发明的目的是提出一种多点视频会议的多屏幕显示方法，一方面可以使用户方便地进行音视频交互，另一方面有效提高系统容量，从而推动视频会议系统的大规模应用。
发明内容
针对上面的描述，本发明提出了一种在互联网上多点视频会议多屏幕显示的方法，并具体包括以下步骤：(1)用户终端登录MCU并将本地视频数据发送给MCU；(2)MCU将登录到同一会议室内的用户信息发送给各个用户终端；(3)用户终端刷新用户列表；(4)用户终端根据用户的要求向MCU申请某一路或某几路视频数据；(5)如果用户终端向MCU申请了某几路视频数据，那么MCU收到请求后，对所申请的视频数据进行复合，然后发送给用户终端；(6)用户终端收到这些视频数据后，对复合视频数据进行分离和解码，并根据用户的要求，在相应的区域显示这些视频图像。
根据本发明的一个方面，其中步骤(5)进一步包括：所申请的各个视频流均以子流的方式进行复合，但需保留各视频流原有的标志信息。
根据本发明的另一个方面，其中步骤(3)进一步包括：用户终端将收到的用户信息以列表的方式显示出来。
根据本发明的另一个方面，其中步骤(6)进一步包括：用户终端在接收到来自MCU的视频数据后，首先读取其CSRC域，并查看CSRC与解码器的映射表；对于已存在于映射表中的CSRC，则数据报的净荷直接送给对应的解码器；对于映射表中不存在的CSRC，用户终端进一步读取数据报中的PT域，了解视频流所采用的编码标准，然后启动对应的编码器，并在CSRC与解码器的映射表中添加相应的条目，最后将视频数据的净荷提供给解码器。
附图的简要说明
图1示出了用户终端与MCU交互流程简图；
图2示出了用户终端工作界面；
图3示出了不同会场视频流进行混合的过程；
图4示出了单视频流的转发过程；
图5示出了用户终端处理视频数据的流程。
具体实施方式
在进行多点会议时，参加同一会议的各个终端都需与MCU进行能力交互并接受MCU的管理。如图1所示，用户终端与MCU之间需要进行交互。为适应本方法，定义了一套终端与MCU交互，用于传递同一会议室内用户信息的控制报文如下：
q931pdu{protocalDiscriminator 8[0x08]callReference{valueLength 8flag 1[0]value 15}messageType 8--消息类型user-User xh225pdu{h323_uu_pdu x--****-UUIEh245Tunneling 1}}Q931.MsgTypes{NationEscapeMsg ＝0x00AlertingMsg ＝0x01CallProceedingMsg ＝0x02SetupMsg ＝0x05......UserListMsg ＝0xe0--MCU向客户端发送用户列表RequestVideoMsg ＝0xe1--客户端向MCU请求数据流}UserList-UUIE∷＝SEQUENCE{protocolIdentifier 16(bits)sessionType 1--会话类型(多屏/混图)frameStartFlag 1--帧起始标识frameEndFlag 1--帧终止标识frameSequence 13--帧序列号sessionIdentifier 1024--会话标识<!-- SIPO <DP n="3"> --><dp n="d3"/>userListData 1024--请求方标识}RequestVideo-UUIE∷＝SEQUENCE{protocolIdentifier 16actionFlag 1--打开/关闭标识sessionIdentifier 1023--会话标识sourceIdentifier 1024--请求方标识targetIdentifier 1024--被请求方标识}
参考图1，用户终端登录到MCU时，会携带表明特征的标志信息：nlsdemeetingendpoint(步骤1)。MCU以此可以辨别用户终端是否具有接收用户列表的能力。对于不具此能力的H.323用户终端，则MCU不会将用户信息发送给它。下文提及的用户终端均指本方法下的用户终端。
每当有新的用户进入“会议室”，MCU都将用户信息发送给各个用户终端(步骤2)。传递该信息的是控制报文q931pdu，其中的messageType域设定为0xe0，h323_uu_pdu采用UserList-UUIE地格式。
如附图2所示，用户终端收到来自MCU的用户信息后，以列表的形式显示出来(步骤3)。这样用户就可以直观地了解参与会议的其他人员的情况。当用户希望看到某个或某些与会人员的视频图像时，将用户名后的视频开关打开，则用户终端向MCU发送对该用户视频数据的申请报文。传递视频申请信息的是控制报文仍是q931pdu，但其中的messageType域设定为0xe1，而h323_uu_pdu采用RequestVideo-UUIE的格式。
此后，用户根据各自的需要向MCU申请某一路或某几路视频数据(步骤4)。
当用户终端申请的视频流是两个以上时，则MCU还需要对视频流进行复合，然后将其发送给用户终端(步骤5)。所申请的各个视频流均以子流的方式进行复合，但需保留各视频流原有的标志信息。
此后，用户终端收到这些视频数据后，对复合视频数据进行分离和解码，并根据用户的指定，在相应的区域显示这些图像(步骤6)。下面参考图5对其进行详细的说明。当用户终端接收到来自MCU的RTP视频数据流后，首先读取其CSRC域，并查看CSRC与解码器的映射表。对于已存在于映射表中的CSRC，则数据报的净荷直接送给对应的解码器。如果对于映射表中不存在的CSRC，用户终端进一步读取数据报中的PT域，了解视频流所采用的编码标准，然后启动对应的编码器，并在CSRC与解码器的映射表中添加相应的条目。
为了使被复合的视频流保留原会场的信息，本方法对传输视频流的RTP数据报的SSRC、CSRC域进行相应的处理。下面以两个视频流进行复合为例说明具体工作的过程。如图3所示，假设在多点会议的一次会话过程中，MCU的SSRC域设定为0xFFFFFFFF，三个用户终端的SSRC域分别设定为0x11111111，0x22222222和0x33333333。由MCU转发的视频数据流，其RTP报文的SSRC域均被设定为0xFFFFFFFF。如果用户终端A申请B和C的视频数据，则MCU需要将发自B和C的视频流进行复合。从B发出的视频流，其RTP数据报的SSRC域被设置为0x22222222。但当它被MCU转发时，新的RTP数据报的SSRC域被设定为0xFFFFFFFF，而CSRC域设定为0x22222222，表明该数据来源自用户终端B。同样道理，MCU转发的用户终端C的视频数据的RTP数据报的SSRC域仍是0xFFFFFFFF，而CSRC为0x33333333。由于SSRC代表了发送源信息，因此从用户终端A看来，发自用户终端B和C的视频数据被MCU进行了复合。用户终端A中的视频分离器根据收到复合视频数据的CSRC域进行分离，将它们分别提供给对应的解码器。当用户终端申请3个以上视频流时，处理过程同上。
如果在步骤4用户终端只向MCU申请某一个会场的图像，则MCU只对所申请的视频流进行转发。如图4所示，当用户只申请了一个视频流，MCU同样将被转发的数据在CSRC域进行处理。主要的不同在于，用户终端不创建视频分离器，直接将从网络上的得到的视频数据提供给解码器。
本方法可以在用户终端同时处理多路不同的压缩标准的视频流。如图2所示，有6路会场的视频图像显示出来。它们可以基于不同的视频压缩标准。
本方法的显示方式可以根据申请视频流的数量灵活选择，有2×2，2×3，5+1等多种方式。用户可以任意选择视频流的显示位置。
对于本领域的普通技术人员来说可显而易见的得出其他优点和修改。因此，具有更广方面的本发明并不局限于这里所示出的并且所描述的具体说明及示例性实施例。因此，在不脱离由随后权利要求及其等价体所定义的一般发明构思的精神和范围的情况下，可对其作出各种修改。