《IP网络多媒体通信技术及应用》课件第9章

第9章视频会议多点通信控制技术

9.1多点视频会议系统通信方式9.2

MCU的工作原理及通信流程9.3

MCU级联控制及通信流程9.4

MCU的功能及实现9.5视频IP组播技术9.6视频会议中多画面合成技术9.1多点视频会议系统通信方式

1.集中型多点会议

在该类会议中,所有参会终端(包括网关)和MCU中的MC建立H.245控制信道的点到点联系,该MC执行对整个会议的集中控制。各终端的音频、视频和数据信道与MCU中的MP相连。该MP对各终端送来的信号进行音频混合、视频交换或混合及T.120数据分配,然后将处理所得的音频、视频和数据流再送回各终端。MP可以选择转送哪一个终端或哪几个终端的信号,也可以对不同的音频、视频和数据格式和比特率进行转换,使得各个参加会议的终端可以使用不同的通信模式。视频信号还可以采用多播方式分发至各终端。

图9－1所示为集中型多点会议结构示意图。其中虚线表示控制信道,传送H.245控制消息;实线表示逻辑信道,传送媒体信息。

2.分散型多点会议

该类会议的终端仍然以点到点的方式和MC建立H.245通信信道连接,MC可位于MCU、网关、网守和某个终端中。各终端的数据信号一般仍通过MP集中分发,但音频和视频信号则直接发送至其他终端,其发送方法有两种:多播方式和多重单播方式。所谓多重单播,指的是每两个终端之间都建有单播信道。这种管理方式没有集中控制和集中管理的设备,MCU的功能以MC和MP功能模块形式分别存在于系统的其他设备(如终端、网关和网守)中。MC仍然具有对会议的控制功能。图9－2所示为分散型多点会议结构示意图。图9－1集中型多点会议图9－2分散型多点会议

3.集中音频混合型多点会议

该类会议的终端和MC之间仍然是点到点的H.245控制连接。音频和数据信道连接至MP,由MP进行音频混合,并能为每个终端发送不同的音频组合信号。视频信号则经由多播或多重单播方式在终端之间直接传送。终端的媒体分配能力设定为集中式控制、集中型音频、分散型视频、集中型数据。

4.集中视频混合型多点会议

该类会议和集中音频混合型多点会议类似,只是音频信号采用直接传送方式,视频信号经由MP集中分发,可以根据需要为每个终端发送不同的视频流,也可以按多播方式统一发送,以降低网络带宽消耗。终端的媒体分配能力设定为集中式控制、分散型音频、集中型视频、集中型数据。

5.特殊型多点会议

这类会议开始时是一个点到点会议,以后在呼叫过程中通过邀请他人或他人主动加入的方式扩展成为多点会议。它要求在初始的点到点呼叫中必须有一个MC。其可能的情况包括:其中一个终端含有或两个终端都含有MC;呼叫控制通过网守转接,该网守具有MC功能;虽然只是两方呼叫,但也是通过MCU作为多点呼叫来处理的。

H.323标准规定,H.323终端和MCU必须支持集中型多点会议,而对分散型和混合型多点会议的支持是可选的。表9－1给出了常用的四种多点会议系统的特征。表9－1四种多点会议的特征9.2

MCU的工作原理及通信流程

9.2.1多点控制器

多点控制器是视频会议系统中具有多点会议控制功能的H.323实体。MC完成对整个会议的集中控制。MC的控制功能通过H.245协议完成,因此参会各端点首先要建立至MC的H.245控制信道。

1.多点会议通信控制原理

1)呼叫建立

每一端点应与MC完成呼叫建立,建立至MC的H.245控制信道。由于MC本身并无独立的地址,无法作为呼叫方,因此一般MC是位于MCU中的,但也可能位于网守或终端中。与MC建立H.245控制连接后,利用主从确定过程确定主MC,即经由MC位置指示消息通告主MC的地址(主MC所在端点IP地址),然后利用能力交换过程选定会议形式(集中型或分散型),会议形式的选择受限于端点和MC的能力。对于每个新加入的端点,MC用“终端号分配”消息赋予终端号,用“终端加入会议”消息通知其他端点新成员的加入,新端点也可用“终端清单请求”消息请求其他端点的名单。

2)通信模式的确定

该过程确定各个逻辑信道的媒体类型、编码方式、媒体信道和媒体信道传输层地址等参数。

在单播情况下,端点通过“打开逻辑信道”和“打开逻辑信道证实”消息建立至MCU或另一端点的逻辑信道。在多重单播情况下,端点必须逐一打开至所有其他端点的逻辑信道。由于端点只与MC建有H.245控制信道,因此“打开逻辑信道”消息必须送往MC,消息中带有逻辑信道对端的终端号,然后由MC转送给对端。端点收到回送的“打开逻辑信道证实”消息,可根据消息中的“前向逻辑信道号”和原请求消息匹配。

多播情况下,则由MC分配多播地址并决定通信模式,经由“通信模式信令”消息告知每个端点。然后,由各端点向MC发送“打开逻辑信道”消息,消息中带有该多播地址;MC根据多播地址将此消息转发给每个接收端点。

3)逻辑信道和RTP流的关联

多播情况下,接收端点会从同一端口收到来自不同源的RTP流,在处理时需要加以识别。为此,H.245规定端点在发送“打开逻辑信道”消息时,应将MC分配给它的终端标记置入逻辑信道参数的源字段;目的地字段空缺,表示该信道的媒体流是多播流。同时,约定源端点发送的RTP流的源标记SSRC的最低字节取为该端点终端标记的最低字节。这样,目的端点收到RTP流后,通过比较SSRC和逻辑信道参数源字段的最低比特就可判定该媒体流所属的逻辑信道。

4)速率匹配

在多点会议中,各终端可能会以不同比特率发送信号。为了使发送能力和接收能力匹配,并使各个终端地位平等,MC可以通过发送“流量控制命令”消息来限定各终端的发送比特率。如有新的终端加入会议,MC将向其发送“多点会议”指示消息,要求它遵从比特率均等的安排。

5)加密

在集中型多点会议中,MP被认为是可信任实体。它可以将来自各端点的信息流解密,进行必要的处理,然后将处理后的复合信息重新加密后送往各端点。

6)会议控制

H.245专门定义了一组会议请求及响应消息和一组会议命令消息,供MC在通信过程中对会议进行控制。例如,在会议中,终端可以请求参会终端清单、充当主席、退出会议等,MC可以要求终端输入口令、终端标识、命令结束会议等。

7)同步

在集中式或混合式多点会议中,为了保证音频和视频的同步,提供音频混合的MP应该修改音频流和视频流的时间戳,实现多点会议中的多点音频同步。当MP对进入MP的音频流和/或视频流进行处理产生新的媒体流时,它还应该在产生的音频或视频流包上打上自己的序列号。

2.多点会议控制方式

在多点视频会议中,与会者既能看到其他会场的与会者,同时又能听到他们的讲话,但这个过程可能并不是同时发生的。那么,在某一时刻到底能看到谁呢?这是由多点视频会议的控制模式来决定的。

目前广泛应用在各类视频会议系统中的控制模式主要有:声控模式、发言人控制模式、主席控制模式、广播/自动扫描模式以及多分屏模式。

(1)声控模式。声控模式又称语音激励模式,是一种自动工作模式,按照“谁发言,显示谁”的原则,由当前发言者的声音信号控制图像的自动切换。在会场数目较多的情况下,声控模式对MCU的语音选择处理器要求过高。

(2)发言人控制模式。发言人控制模式也是一种自动工作模式,欲发言的人通过会议管理界面或遥控器向MCU发出发言请求,若MCU认可则将它的图像、语音信号播放到所有与MCU相连的会议终端,发言者发言完毕,MCU自动切换到声控模式。

(3)主席控制模式。该控制模式下,将所有会场分成主会场和分会场两类,由主会场组织者(或称主席)行使会议的控制权,根据会议进行情况和各个分会场的发言情况,决定在某个时刻人们可以看到哪个会场,而不考虑此刻是谁在发言。这种方式具有很大的主动性,控制较好,避免了声控模式频繁切换图像造成会议“混乱无序”的现象。

(4)广播/自动扫描模式。该控制模式实质是主席控制模式的一个变体。这种模式可以将画面设置为某个会场,而这个会场中的与会者则可以定时轮流看到其他各个分会场。这种模式按照事先设定好的扫描间隔自动切换广播画面,而不论此刻谁在发言。

(5)多分屏模式。这是一种新的控制模式,这种模式通过将屏幕分割成为若干个窗口,而使与会者可以同时看到多个分会场的情况,当然这样对于整个系统的软硬件要求也较高。

H.323视频会议系统只是逻辑意义上的网状网结构,MCU与MCU、终端与MCU之间不是静态固定连接的,会议组织流程较复杂,存在终端和MCU之间相互选择的问题。在召开一个会议时,终端首先被接入所连接的本域MCU,其他域终端可加入到此MCU上参加会议。在选择路由上,若参会终端比较分散,则可选择任意一个参会终端所在地的MCU作为召集方,其他终端汇接到此MCU上。对于会议中邀请和加入其他终端的情况,若会议使用中的MCU端口数已满,则终端会被指向与邻近的MCU建立连接。9.2.2多点处理器

多点处理器(Multipointprocessor,MP)是视频会议系统中接收并处理音视频流的H.323实体。集中型会议各终端的音频、视频和数据信道与MCU中的MP相连。MP对各终端送来的信号进行音频混合、视频交换或合成以及T.120数据分配,然后将处理后的音视频流和数据流再回送各终端。因此,MP必须能执行各种媒体信息的编解码。MP应具备在不同的音频、视频和数据格式以及比特率之间转换的能力,使得与会终端能使用不同的通信模式加入同一会议。如果终端之间的SCM不同,MP则要进行通信模式的转换以保证各终端之间的正常通信。对于视频信号,MP必须能进行视频交换或视频合成。视频交换就是选定某一源信号发往各终端,源选择可通过发言者变换(检测话音信号电平确定)实现或由H.245控制实现。视频合成是指将多个视频源信号组合成一个视频信号后再传送给各终端,其典型应用是将4幅源图像组合成一个2×2的多画面图像,又称为四分屏图像。选择哪些源和多少源图像进行合成则由MC决定。对于音频信号,MP能够通过交换、混合或二者的组合将M个音频输入经处理后生成N个输出。需要注意的是,音频混合需要将每个输入音频首先解码为线性PCM信号或模拟信号,然后将各路信号合成,最后再将合成后的信号重新编码成相应格式。混合时,MP可以去除或衰减某些输入信号,以降低噪声和其他不需要的信号。终端应保证自己的话音信号不在自己的终端输出。

1.音频信号的处理

多点控制单元对语音信号可分为两种情况:如只有一个会场发言,多点控制单元将它的音频信号切换到其他不发言的会场;若同时有几个会场发言,多点控制单元挑出电平最高的音频信号切换到其他不发言的会场,或将它们的音频信号进行混合处理,然后切换到除该会场以外的其他所有会场。在一个会议组中,为便于进行语音混合,一般为每个与MP建立连接的终端均设计了M个音频缓冲区,其中,M＝(与MCU建立呼叫连接的总终端数-1),即假设一个会议组中有N个终端与MP建立了连接,则MP为每一个终端均准备了M=(N-1)个缓冲区,这(N-1)个缓冲区分别用来存放从除本终端外其他终端接收到的音频数据,MP对它们进行音频混合后再回送给这一个对应的终端。据此推断,MP中共计有音频缓冲区N×(N-1)个。每增加一个建立连接的新终端,都要新开辟多个缓冲区,首先要为其他终端都开辟一个缓冲区用于存放从这个新终端接收到的音频数据,然后还要为这个新增终端开辟多个缓冲区用于存放从其他终端接收到的音频数据。图9－3给出了仅有三个终端与MP建立连接时缓冲区的分配情况。图9－3

MP中音频缓冲区的分配MP的音频处理方式采用了事件驱动的多线程机制。对于终端与MCU建立的每个呼叫连接,都对应有两个线程:接收线程负责将从网络上接收到的音频数据送去解码器进行解码,并将得到的解码流存放在用于存放这个终端的音频信号的缓冲区;而发送线程负责将已混合的音频数据送去给编码器进行编码,并将得到的编码流发送出去。MP对多个音频缓冲区中的数据进行音频混合的过程并不在这两个线程当中。由于两个线程之间存在有共享资源,为避免由于资源共享而引起的竞争、死锁等错误,MCU软件采用了事件和互斥方法来达到线程之间的同步。事件1是指由接收线程将解码流送入对应缓冲区,缓冲区被更新;事件2是指读取缓冲区中的数据并对其进行语音混合。事件与线程之间的关系如下:接收线程挂起直到事件2发生才继续执行,发送线程被挂起直到事件1发生才继续执行,这样,就可以保证线程间的同步了。

2.视频信号的处理

对于视频来说,要为每个与MP建立连接的终端准备一个缓冲区,它既是接收缓冲区也是发送缓冲区。在主席模式下,对接收到的视频数据,MP需先判断是否是来自主席或选定听众的。若是来自主席的,则将它们分别存入与其他所有终端相对应的缓冲区中；若是来自选定听众的,则将其存入为主席准备的缓冲区中；若是来自其他终端的,则MP不予理会。发送时,只需将本缓冲区中的数据发往与本缓冲区对应的呼叫连接即可。在非主席模式下,MCU在接收到来自各终端音频数据时就要进行判断,选其音频最高的作为当前发言者。对于视频来说,MCU需将当前发言者的视频数据存入与其他所有终端相对应的缓冲区中,而与当前发言者相对应的缓冲区中则存放从上一个发言者接收到视频数据。图9－4给出了主席模式下缓冲区的分配情况,而非主席模式下的情形类似。图9－4主席模式下MP视频缓冲区的分配若MP要进行四画面合成,则情形又要稍复杂一些。首先通过MCU的操作界面选定参与画面合成的四个源终端,MP将为这四个源终端另外创建四个缓冲区,分别用来存放这四个源终端的视频数据,MP将这四路视频数据合成后再送到与各终端相对应的缓冲区中,其后的发送情况和单画面时相同。9.2.3

MCU通信流程

1.注册流程

MCU注册流程如图9－5所示。

(1)MCU启动,向网守发“请求接入认证”(RRQ)消息。

(2)网守回送RCF消息。如果注册消息被拒绝,则回送RRJ消息,MCU需重新注册。

2.注销流程

MCU注销流程如图9－6所示。

(1)MCU向网守发“请求用户退出”(URQ)消息。

(2)网守收到URQ消息后,向MCU发送UCF消息。如果注销消息被拒绝,则回送URJ消息,需重新进行注销;如果MCU已关机,则网守应强制注销。图9－5

MCU注册流程图9－6

MCU注销流程(1)MCU向网守发起注册请求ARQ。

(2)网守回送ACF。

(3)向终端1发起Setup请求建立连接。

(4)终端1向MCU发送CallProceding消息。

(5)终端1向网守发送ARQ接入请求。

(6)网守向终端1回送ACF响应。

(7)终端1向MCU回送Alerting消息。

(8)终端1向MCU发送Connect消息,建立与MCU之间的媒体通道。图9－7MCU发起会议流程

(9)终端1和MCU之间发送TerminalCapabilitySet交换能力。

(10)MCU发送MasterSlaverDetermination进行主从判决,确定MCU为主,终端为从。

(11)MCU发送TerminalNumberAssign,为终端1分配终端号。

(12)MCU和终端1之间发送OpenLogicChannel打开逻辑信道,建立连接。

(13)MCU向终端2发起Setup请求建立连接。

(14)终端2向MCU发送CallProceding消息。

(15)终端2向网守发送ARQ接入请求。

(16)网守向终端2回送ACF响应。

(17)终端2向MCU回送Alerting消息。

(18)终端2向MCU发送Connect消息,建立与MCU之间的媒体通道。

(19)终端2向MCU发送TerminalCapabilitySet报告能力。

(20)MCU发送MasterSlaverDetermination进行主从判决,确定MCU为主,终端为从。

(21)MCU向终端1和终端2发送MultipointConference消息,通知其已经加入多点会议。

(22)MCU为终端2分配终端号。

(23)MCU和终端2打开逻辑信道,建立连接。

(24)MCU在会议进行中定期发送相应的资源报告到GK。

(25)GK向MCU回送相应的确认消息和指示。

4.召集人发起会议

预约会议时间到了以及即时召集的会议认证通过后,会议就可以召集了。召集者终端发出会议建立请求,网守告知MCU需要召集的会议信息,由MCU呼叫其他与会终端。

召集人发起会议流程如图9－8所示。图9－8召集人发起会议流程

(1)召集人终端(终端1)发起会议申请,向网守发送带有预约会议号和密码的ARQ消息。

(2)驻地网守收到ARQ消息认证通过后,向其后的AAA服务器发送AccessRequest消息,开始对会议进行计费。

(3)AAA服务器向网守回送AcceptResponse消息。

(4)网守向终端回送ACF消息。

(5)预约终端在通过认证后,向网守发送ARQ消息,消息中包含会议召集者标识、受邀请的会议成员的情况和标识等。

(6)驻地网守收到ARQ消息后,调度相应的资源供会议使用,并回送ACF消息。

(7)召集人终端向驻地网守发送Setup消息,建立与其他终端的连接。

(8)网守向MCU发邀请会议成员的Setup消息,请求MCU邀请其他与会终端。

(9)MCU向网守发送ARQ消息,请求会议认证。

(10)网守回送ACF确认。

(11)MCU确认收到消息后,向网守发送Alerting消息。

(12)驻地网守确认收到消息后,向召集人终端发送Alerting消息。

(13)MCU向驻地网守发送Connect消息。

(14)驻地网守确认收到消息后,向召集人终端发送Connect消息。

(15)终端1和MCU之间发送TerminalCapabilitySet交换能力。

(16)MCU发送MasterSlaverDetermination进行主从判决,确定MCU为主,终端为从。

(17)MCU发送TerminalNumberAssign,为终端1分配终端号。

(18)MCU和终端1之间发送OpenLogicChannel打开逻辑信道,建立连接。

(19)MCU向终端2发起Setup请求。

(20)终端2向网守发送ARQ消息,请求认证。

(21)网守回送ACF确认。

(22)终端2向MCU回送Alerting消息。

(23)终端2向MCU发送Connect消息。

(24)终端2向MCU发送TerminalCapabilitySet报告能力。

(25)MCU发送MasterSlaverDetermination进行主从判决,确定MCU为主,终端为从。

(26)MCU向终端2发送MultipointConference消息,通知其已经加入多点会议。

(27)MCU向终端1发送MultipointConference消息,通知其已经加入多点会议。

(28)MCU为终端2分配终端号。

(29)MCU和终端2打开逻辑信道，建立连接。

(30)MCU在会议进行中定期发送相应的资源报告到网守。

(31)网守向MCU回送相应的确认消息和指示。

(16)所有终端退出会议后,MCU向GK发送DRQ消息拆除链接。

(17)网守回送DCF消息。

(18)网守向AAA递送计费信息。

(19)AAA回送响应。

6.主席控制

主席控制流程包括申请主席、释放主席、请求发言、广播会场、视频选看、强制非主席终端退出等。

1)申请主席

申请主席流程如图9－10所示。

(1)终端使用ConferenceRequest(MakeMeChair)向MCU申请主席。

(2)如果当前没有其他主席或该终端本身就是主席,MCU同意请求,回送ConferenceResponse;如果当前有其他主席,则拒绝该申请ConferenceResponse。一旦会议中某个终端申请主席成功,该会议中其他终端不能再申请主席。

2)释放主席

释放主席流程如图9－11所示。

(1)终端使用ConferenceRequest向MCU申请释放主席。

(2)MCU同意请求,回送ConferenceResponse。会议中其他终端可以再申请主席。图9－10申请主席流程图9－11释放主席流程

3)终端请求发言

终端请求发言流程如图9－12所示。

(1)终端向MCU请求发言。

(2)MCU向主席终端发送终端的发言请求。

(3)MCU如果同意发言,则回送广播终端的命令。图9－12终端请求发言流程

4)广播会场

广播会场流程如图9－13所示。图9－13选择一视频进行广播5)视频选看

图9－14视频选看流程

6)强制非主席终端退出

强制非主席终端退出流程如图9－15所示。图9－15强制非主席终端退出流程

(1)主席终端向MCU发送请求,强制一个终端的退出。

(2)MCU与退出终端间关闭逻辑通道。

(3)MCU与退出终端间关闭H.245会话。

(4)MCU向该终端发送ReleaseComplete消息。

(5)终端返回ReleaseComplete消息。

(6)MCU向主席终端返回TerminalLeftConference消息。

7)声音控制

(1)每个会场均能同时听到其他各会场的声音。

(2)MCU自动根据与会者发言音量大小,将图像切换到发言声音最大的会场并广播出去。

7.呼叫扩展流程

1)会议延时

会议延时流程如图9－16所示:

(1)会议进行中,预约的时间就要到达,而会议并未结束,会议召集终端向网守发送ARQ请求,在ARQ请求中为同一个会议申请新的会议时间,会议标识与原预约会议标识相同,开始时间为原预约会议的结束时间,并且在ARQ消息中预约一个新的时长。

(2)网守检查用户是否有资源冲突,并向AAA服务器请求验证用户是否有权进行会议的延长或用户账上是否有足够的余额。

(3)如果各种条件满足,AAA返回确认信息。

(4)网守给终端返回一个ACF消息接受用户新的预约。

注:如果是允许持卡用户申请会议的延时,网守在开始会议预约时,应从AAA服务器得到用户账户上剩余的金额。图9－16会议延时流程图9－17终端申请加入

2)成员加入

终端申请加入流程如图9－17所示。

(1)申请加入一个已经召开的会议的终端,在取得会议号和密码后发起会议申请,向网守发送带有会议号和密码的ARQ消息。

(2)网守收到ARQ消息后,向其后台的AAA服务器发送AccessRequest消息,对终端的申请进行认证。

(3)AAA服务器查找其数据库中关于会议的信息,确认该用户有权加入会议后,AAA服务器向网守回送AcceptResponse消息。

(4)收到AccessResponse消息,网守向终端回送ACF消息。

(5)新加入终端在通过认证后,向网守发送ARQ消息,消息中包含新加入会议成员的情况和标识等。

(6)驻地网守收到ARQ消息后,向新加入终端回送ACF消息,其中包含驻地网守的信息;否则发送ARJ消息。

(7)新加入终端向驻地网守发送Setup消息,建立与其他终端的连接。

(8)驻地网守向MCU发会议成员申请加入的Setup消息,请求MCU连接新加入终端。

(9)MCU确认收到消息后,向网守送Alerting消息。

(10)驻地网守确认收到消息后,向召集人终端送Alerting消息。

(11)MCU向驻地网守送Connect消息。

(12)驻地网守确认收到消息后,向召集人终端送Connect消息。3)邀请新成员图9－18邀请新成员流程

(1)会议在进行中,召集人邀请新成员加入,召集人在其终端填写所邀新成员的终端标识号,向网守发送邀请消息Setup。

(2)邀请终端向网守发送ARQ,带有预约会议号和密码以及邀请新成员的信息。

(3)驻地网守收到ARQ消息后,向其后台的AAA服务器发送AccessRequest消息,对终端申请进行认证。

(4)AAA服务器查找其数据库中关于该终端的信息,确认该用户有权邀请新成员,AAA服务器向网守回送AccessResponse消息。

(5)收到AccessResponse消息,网守向终端回送ACF消息。

(6)网守将被邀请终端标识用Setup消息送给MCU。

(7)MCU向受邀请终端发送Setup呼叫建立请求。

(8)受邀终端向网守发送ARQ消息,请求认证。

(9)网守回送ACF确认。

(10)被邀请终端回送Alerting。

(11)MCU向网守回送Alerting。

(12)被邀请终端参加会议,向MCU送Connect消息。

(13)MCU向网守发送邀请已完成的确认Connect消息。

(14)网守向召集人终端发送邀请成功应答消息。

9.3

MCU级联控制及通信流程

9.3.1

MCU级联的原理

在计算机硬件有限的处理能力下,要扩大会议规模,就必须对会议核心设备MCU的网络结构进行合理的设计,基本原理是把各个处在不同地域的MCU通过管理软件连接在一起,组成一个更大容量的会议系统。分布式MCU构建的方法主要是把MCU设备通过逻辑级联的方式连接起来,把多个MCU设备连接成一个大型MCU,实现大容量的会议系统。在分布式级联方案中,将主持方的MCU设置成主MCU,其余各个地域中不同的分MCU设置成从MCU,整个会议系统采用“一主多从”的形式,本质上是把主MCU中的会议参数传递给参加级联的从MCU,即把主MCU中参加级联的会议的音频、视频和会议模式等参数传递给所有从MCU中参加级联的会议,把从MCU以用户的身份加入到主MCU的参加级联的会议中,把主MCU以用户的身份加入到各个从MCU的参加级联的会议中。用户终端会议功能是通过参加级联的各个级联会议实现的,级联会议的会议功能再通过MCU完成数据交互。按照每组会议总是把主席或者发言听众的数据转发给其他用户的原则,要把从MCU中用户的数据传递给上层主MCU或者其他从MCU中的用户,首先要把该用户设置成主席,把该从MCU在主MCU中的身份设置成主席,把主MCU在其他从MCU中的身份设置成主席,再把主MCU在该从MCU中的身份设置成普通听众或者发言听众。要把主MCU中的用户数据传递给下层从MCU的用户,首先把该用户设置为主席,再把主MCU在从MCU中的身份设置为主席就可以了。9.3.2

MCU级联的流程

图9－19

MCU级联流程

(1)MCU1向网守1发起接入请求ARQ。

(2)网守1回送ACF。

(3)MCU1向MCU2发起Setup请求建立连接。

(4)MCU2向MCU1发送CallProcessing消息。

(5)MCU2向网守2发送ARQ接入请求。

(6)网守向MCU2回送ACF响应。

(7)MCU2向MCU1回送Alerting消息。

(8)MCU2向MCU1发送Connect消息,建立MCU之间的媒体通道。

(9)MCU2向MCU1发送TerminalCapabilitySet报告能力。

(10)MCU2发送MasterSlaverDetermination进行主从判决,确定MCU1为主MCU2为从。

(11)MCU1为MCU2分配终端号。

(12)MCU1发送RemoteMCRequest,激活MCU2。

(13)MCU2发送RemoteMCResponse,确认或拒绝激活。

(14)MCU1为MCU2上的终端分配号码。

(15)逻辑信道打开,连接建立,会议正常进行。

(16)会议结束时,MCU1发送关闭逻辑信道请求。

(17)MCU1发送结束会话请求,MCU2回送结束会话请求。

(18)MCU1拆除连接。

(19)MCU1向网守1发送DRQ,报告会议结束并退出,MCU2向网守2发送DRQ,报告会议结束并退出。

(20)网守1回送DCF给MCU1,网守2回送DCF给MCU2。

9.4

MCU的功能及实现

9.4.1

MCU的功能要求

1.多点控制功能

MCU提供了在三个或更多个终端间召开多点会议的控制功能。

在多点会议中,MCU接受网守控制,召集、结束会议,呼叫参会终端,对一组或多组会议进行管理,处理会议中的呼叫服务,并向网守报告会议状态。

MCU负责与每个端点的能力交换。在呼叫时,MCU发送能力集给会议中的端点,指示它们可用的传输模式。MCU可以因终端加入/离开会议或是其他原因而修改它发送到终端的能力集。

2.多点处理功能

在一个集中或混合的多点会议中,MCU接收来自终端的音频、视频和/或数据流。MCU处理这些媒体流并把它们送回到端点。

MCU应该具备视频处理功能,提供视频切换及视频合成控制。

MCU必须具备音频处理功能,通过混合或组合操作从多路音频输入中得到一路或多路音频输出。

MCU必须采取一定的措施以保持音频和视频的同步。

3.多点适应能力

MCU应该支持多点控制、级联等功能,可选支持多点速率匹配、多通信模式匹配等功能。

(1)多点控制。MCU应该支持会议中的控制。会议中的控制包括设备控制和会议控制。设备控制的内容有摄像机远程控制、麦克风远程控制、图像播放远程控制、幻灯片播放远程控制等;会议控制应该支持主席控制、可选操作员(导演)控制和语音控制等。

(2)级联能力。多点控制功能可以在多个MCU之间分配。

(3)多点速率匹配。MCU可以支持终端以不同的比特率工作。

(4)多通信模式匹配。MCU应该具备音频和/或视频格式转换的能力,不同端点可以采用不同的通信模式。

4.网管功能

多点控制单元应该支持本地和远程的配置管理、故障管理、版本管理、用户管理、日志管理等网管功能。9.4.2

MCU功能的实现

1.会议管理

单台MCU的最大容量一般为16个用户或更高,在其最大容量范围内应能同时处理多组会议,每组会议之间互不干扰,独立控制。各组支持的终端数之和不能超过MCU允许的最大容量。

会议管理功能支持多组会议控制(包括创建新的会议组和取消原有的会议组),对每组会议的成员信息可在会议进行中进行管理,方便新的与会者加入,自动处理某一与会者的退出等。为完成此项功能,首先要在程序内部维护一个会议成员信息类、一个会议成员列表类和一个组列表类。会议成员信息类用于存放会议组中成员的一些相关信息,如此成员的用户名、别名、IP地址、所在会议组的组名和ID号、状态(是否在线)以及其身份(主席、选定听众或一般用户)等;会议成员列表类则相当于一个用户链表,它存放了参加会议的所有用户的信息,并且包含了完成添加、删除、插入及查找某一用户等与链表操作相当的一些基本操作的成员函数;而组列表类则相当于一个组链表,用于存放每个组,它也同样具有完成添加、删除、查找等功能的成员函数。另外,还可以添加一些友好界面,将这些操作显示在界面上,加强人机交互的实用性。

MCU一般为嵌入式设备,其管理和控制是由专门的软件通过与MCU互联的远端计算机来完成的。用户可以通过B/S,即Web方式或C/S方式进行远端访问和控制。当然也可安装专门的会议管理软件,对MCU进行管理。

2.与参会终端建立一点到多点的通信

对于MCU设备来说,最重要的是能够兼容各厂商符合H.323标准的设备,如终端、网关、网守等,并提供良好的互操作能力。对不同厂商的H.323设备要能够做到互联、互通和互控。对于符合H.320标准的终端,可通过网关接入,实现H.320和H.323会议终端的互通。与参会终端建立点到点通信是指MCU可以作为主叫方呼叫参会终端,也可以作为被叫方接受参会终端的呼叫,并与之建立呼叫连接。实现时,首先添加一个发起呼叫的功能块和一个接受呼叫的功能块,其次再完成其他工作,如完成RAS协议、Q.931协议和H.245协议等。为实现呼叫连接,必须为每个呼叫都创建一个呼叫线程,使得MCU与每个会议成员之间的呼叫互不影响。对于单个呼叫来说,必然要创建一个守听线程来在特定的端口上侦听来自远端的呼叫。当有呼叫进来时,判断呼叫方是否是本MCU成员列表里的一个成员。若是,则接受呼叫,并将此成员的状态改为在线；若不是,则自动拒绝此呼叫。如果MCU作为主叫方呼叫了某一会议成员,首先就要生成一个新的传输层类,用于以后媒体信号的传输;接着构造一个新的H.323连接对象,用于管理它们之间的呼叫连接;最后还要生成一个呼叫守护线程,用于管理双方的H.225/Q.931信令在TCP信道上的信令交换,而这些信令的发送与处理都是由呼叫连接类来完成。呼叫连接的建立标志着一个呼叫的成功。

MCU支持群呼和群挂断功能,它可以呼叫一组终端,或者挂断一组终端,甚至可以呼叫或挂断所有终端。MCU可设置与会者列表,通过MCU或IVR的群呼功能,实现自动召集会议功能,无需各分会场主动呼入。对于IVR控制方式,可以使用任何一台与会议系统互联的IP电话、普通电话或移动电话召集和组织会议。

3.MCU工作方式的确定

MCU的工作方式主要分为主席模式和非主席模式两种。在会议的进行过程中,可以动态地指定会议模式为主席模式或者非主席模式。在主席模式下,终端有三种可能的身份:主席、选定听众以及一般听众。除主席外,所有终端接收的视频源均为主席的,即它们收看主席的图像,而主席则收看选定听众的图像。MCU具有语音选择控制和操作员手工控制两种控制方式,会议进行中可以在两种控制方式之间切换。在手工操作方式下,发言者或主席是可以根据需要动态指定的。在语音选择方式下,MCU自动将当前发言者的音视频数据发送给其他与会者。在非主席模式下,采用语音激励方式进行数据的转发,这时,所有会议成员(除发言者外)均接收发言者的信号源,而发言者则接收上一发言者的信号源。

MCU能自动检测到每组会议中发言音频强度最高的会场,并立即将该会场的音视频流传给该组其他所有会场。其语音激励灵敏度可以根据会场具体情况进行动态手工调节,以避免某些会场的噪音干扰。这样MCU在无人操作的情况下,通过语音就能对会议进行控制,完成视频画面的切换。

在主席模式下,最重要的是在用户类的数据成员“身份”上做好用户的身份标志。而在非主席模式下,对每一组会议来说都需要维护一个发言者列表,以数组的形式存放,用于列出所有曾经是发言者的成员,而最新检测到的发言者总是列在列表的最末位,即为数组的最后一个元素。

4.多路音视频处理

可以实时将多路语音进行合成,使每个与会者能同时听到多个与会者的声音。为了避免自激、回音等现象的出现,每个与会者将不能听见自己的声音。在会议进行的过程中可以动态选择是否选中语音合成,不进行语音合成则可以通过选定主席或者选定组播方式完成数据交换和会议功能。多画面合成又称为多分屏或动态分屏,有多种实现方法,例如压缩域合成方法和非压缩域合成方法。在H.261视频格式下,可以进行四画面合成,将四路QCIF格式的视频图像合成为一路CIF格式的视频图像。MCU同时接收四路会场的视频数据,不进行解码处理,在压缩域内合成,形成一条视频流,再将合成后的视频流发送给所有与会者,使每个与会者能同时看到四个会场的图像。这种方法称为压缩域合成方法,该方法仅适用于H.261格式的视频图像,不适用于H.263或H.264等其他格式的视频图像。

MCU支持多画面显示功能,完成该功能的设备称为多点显示单元(MDU),又称为多画面电视墙。在不影响现有系统的情况下,MDU采用独立的网络接口,对多个会场的视频数据进行解码,这样在中心会场就可选择同时收看多路会场的图像。

5.其他功能

MCU支持远端摄像机控制(FarEndCamraControl,FECC)。在主席模式下,主席和选定听众之间可以实现远端摄像机的互控。在语音激励模式下,可实现当前发言人和前一发言人之间的远端摄像机互控。在视频会议中,远端摄像机控制应遵循H.281协议。

MCU具有组播功能,可选择组播多路视频数据(最多四路),终端通过组播接收软件动态选择接收其中的任意一路组播视频数据并进行显示。

MCU应支持网络远程软件升级。用户可利用专门的软件通过网络对MCU软件进行快速升级更新。

MCU应支持级联控制,以便扩充MCU的容量。利用级联方式,使用有限的带宽将位于不同地域的多组用户连接起来,有效节省长途传输带宽。9.4.3

MCU的控制平台CMS

MCU是多点会议的核心设备,承担着几乎所有的会议控制功能。同时,MCU作为一个系统设备,通常安装在视频会议网络中的主要节点处,如网络中心机房。而会议的控制通常由会议成员来进行,即对MCU的操作一般通过远程控制平台实现。

CMS(ContentManagementSystem)可作为MCU的管理中心,对MCU设备进行全面的功能设置和会议调度。CMS工具可安装在Windows系统中。运行CMS管理程序,将自动搜索网上正在运行的MCU设备,选择连接其中的一个,即可对其进行控制。这些控制通常包括设备管理、会议管理、会议设置、会议控制和MCU系统信息等。

(1)设备管理包括基本设置、时间同步、网守管理、网络接口管理、用户管理、终端列表、组播地址管理。

(2)会议管理包括会议添加和会议删除。

(3)会议设置包括基本设置、会议成员、会议格式、字幕叠加、实况组播、会议预约、双流显示、摄像机远程控制、允许自动发言、发言听众模式、允许终端发起会议、会议成员默认混音、会议成员默认闭音、断线重连、带宽优化。

(4)会议控制包括呼叫连接、呼叫挂断、多分屏切换、会议成员信息统计。

(5)MCU系统信息包括软件版本、CPU资源利用率、软件下载更新。 9.5视频IP组播技术

9.5.1

IP组播的基本概念

我们知道,在多点视频会议系统中,用户数过多会造成基于IP网络系统的服务质量的严重下降;若要保证服务质量,则又严重制约了用户数的增加。针对这一矛盾,可以考虑使用IP组播技术。

1.视频IP组播的概念

IPV4支持单播(Unicast)、广播(Brocdcast)、组播(Multicast)三种数据传送方式。组播是相对于单播和广播而言的一种面向“组”发送数据的形式。广播是指将信息从一个发送端传送到整个子网中所有终端,而组播将信息从一个发送端传送到多个接收端。

IP组播将IP数据包“尽最大努力”传输到一个构成组播群组的主机集合,群组的各个成员可以分布于各个独立的物理网络上。IP组播群组中成员的关系是动态的,主机可以随时加入和退出群组。群组的成员关系决定了主机是否接收送给该群组的组播数据包,不是该群组的成员主机也能向该群组发送组播数据包。

IP组播是单播传输很好的改进,同单播相比效率非常高,不论网络中有多少个接收端,发送端只需发送一个媒体流,因此可以显著节省网络带宽和资源。如果有一个视频服务器与远端网络通信,网络中有n个用户,对于一个活动全屏图像,一个视频信息流需占用1.5Mb/s的带宽。在单播环境中,视频服务器依次送出n个信息流,由网络中的用户接收,共需要n×1.5Mb/s的带宽;如果服务器处于10Mb/s以太网内,6～7个信息流就占满了带宽;既便在高速以太网中,最多也只能容纳250～300个1.5Mb/s的视频流。在组播环境中,不论网络中的用户数目有多少,服务器发出一个视频流,由网络中的路由器或交换器同时复制出n个视频流,广播到每个用户,仅需1.5Mb/s的带宽。由此可见,IP组播能够有效地节省网络带宽和资源,管理网络的增容和控制开销,大大减轻发送服务器的负荷,从而高性能地发送信息。组播传送的信息能同时到达用户端,时延小,且网络中的服务器不需要知道每个客户机的地址,所有的接收者使用一个网络组播地址,可实现匿名服务,并且IP组播具有可升级性,与新的IP业务兼容。

在多点视频会议系统中,我们让大部分会议终端只有参加会议的权力,而不给它们提供发言权,利用组播技术把音视频数据发送给它们,只让少数重要的会议终端具有发言权。这样做的目的是既节约了网络带宽,又增加了用户数,同时还保证了视频会议系统的服务质量。在MCU中,音视频媒体流组播一般是作为一种可选附加模块进行添加的,其机制和视频终端的机制很相似。只要在MCU的主席控制端中打开媒体流组播的功能,在控制中心即可将任意会场的视频图像通过媒体流组播发送出去。例如在召开四点视频会议的同时,控制中心主席端可以打开流广播的功能,将任意会场(主会场或分会场)的音、视频广播到其他未参加双向会议的会场。

2.视频IP组播实现机制

IP组播利用组播协议将IP数据包从一个源传送到多个目的地,将信息的拷贝发送到一组地址,到达所有想要接收它的接收者处。

组播发送数据时,接收端通过IP网D类地址判断自己是否是本组成员,若是则接收组播数据流。D类地址是一个格式为224.0.0.0～239.255.255.255的IP地址,其中较低位置的256个地址被保留给管理和系统级的路由选择使用,中间范围被组、内部网和Internet中的组播端用户应用系统使用,较高位置的D类地址238.255.255.255～239.255.255.255被保留用于特定的多路广播应用系统。在组播通信模型中,需要两种新型地址:一个IP组播地址和一个Ethernet组播地址。IP组播地址表示一组接收者,它们要接收发给整个组的数据。由于IP包封装在Ethernet帧内,所以还需要一个Ethernet组播地址。为使组播正常工作,主机应能同时接收单播和组播数据,主机需要多个IP地址和Ethernet地址,其中单播IP和Ethernet地址用于单播通信,而Ethernet组播地址用于组播通信。如果主机不准备接收组播,组播地址就设置为零组播地址。因此,单播和组播地址之间的主要差异在于每个主机都有一个惟一的单播地址,组播地址则不然。将D类IP地址映射为EthernetMAC地址是由数据链路层完成的。在映射过程中,组播IP地址中共有9位不参与替换,包括高位字节8位以及紧接在该字节后面的一个标志位,其中最开始的4位1110表示属于D类IP地址,剩下的5位实际不参与映射,无论这些位的值是什么,组播Ethernet地址都是相同的。由于5个位共可以有32种不同的组合,所以映射并不具有惟一性。

3.组播路由协议

在一个组播路由器建立路由,传送其组播群组成员关系信息之前,它必须确定在本地网络上是否有一个或多个主机加入了某个组播群组。为此,组播路由器和实现组播的主机必须使用互联网组管理协议(InternetGroupManagementProtocol,IGMP)来进行群组成员关系信息的通信。利用IGMP,组播路由器可判断在与自己连接的任何一个网络上是否存在组播组的一些成员,如存在组成员,组播路由器便可加入一个特定的组播组,并将组播数据转发给加入该组的主机。因此,IGMP被主机用来通知直连的路由器,令其加入一个组播组,使组播网具有动态性和灵活性。

IP网络的二层组播相关协议包括IGMPSnooping和CGMP。IGMPSnooping通过交换机去侦听主机发向路由器的IGMP成员报告消息,形成组成员和交换机接口的对应关系,放在组播CAM表项中。交换机根据该对应关系将收到组播数据包只转给有组成员的接口。

CGMP(CiscoGroupManagementProtocol)是Cisco基于客户机/服务器模型开发的私有协议,它运行在路由器和交换机上,允许成员关系信息从路由器到交换机进行通信。在CGMP的支持下,组播路由器能够根据接收到的IGMP数据包通知交换机哪些主机何时加入和脱离组播组,交换机利用由这些信息所构建的转发表来确定将组播数据包向哪些接口转发。组播注册协议(GMRP)是主机到以太网交换机的标准协议,它使组播用户可以在第二层交换机上对组播成员进行注册。在基于路由器的网络中,对于传递组播信息流,一个至关重要的问题是IP组播路由协议。它克服了利用单播通信模型传递组播信息带来的带宽瓶颈,减少了发送相同数据信息到多个接收者的通信费用,这也是IP组播应用得到发展的主要原因。组播网内数据的流动必须根据组播路由协议建立生成树,使发送源和组播组成员之间形成一条单独的转发路径,确保每个数据包都能转发到目的地。

IP组播路由协议分为域内协议和域间协议。域内协议包括PIM－SM、PIM－DM、DVMRP、CBT等;域间协议包括MBGP、MSDP、BGMP等。根据网络中主机的分布,上述IP组播域内路由协议一般可以分为两类。第一类称为密集型模式,这种模式指组播成员在网络中密集分布,有足够的带宽,所以密集协议通过扩散技术传播信息至整个网络,包括DVMRP、MOSPF和PIM－DM,这类协议属于数据驱动型的。第二类称为松散型模式,这种模式指组播成员在网络中分散分布,没有足够的带宽,例如广域网或用户使用ISDN线上网,但松散型模式并不意味群组有很少的成员,只不过它们是分散分布的,它包括CBT和PIM－SM。扩散技术将浪费带宽,它通过发出加入请求申请,在含有集中点或核心点的空生成树上添加树枝形成组播生成树,这类协议属于接收者驱动型。使用DVMRP、MOSPF组播路由协议时,单播路由协议相应地必须使用RIP、OSPF,这就造成了一定的局限性。DVMRP使用距离向量路由协议建立生成树,MOSPF使用链路状态数据库建立生成树。PIM和CBT独立于单播路由协议,但依赖于单播路由表,其中PIM－SM和CBT有一个集中点或核心,连接源和接收者之间的各个路由器而形成路由。针对域间组播路由有两类解决方案:短期方案和长期方案。短期方案包括三个协议:MBGP、MSDP和PIM－SM。MBGP(组播边缘网关协议)用于在自治域间交换组播路由信息;MSDP(组播信源发现协议)用于在ISP之间交换组播信源信息;PIM－SM(协议无关组播－稀疏模式)用于域内组播路由管理。长期方案目前讨论最多的是MASC、MBGP和BGMP,它们建立在现有的组播业务模型上。其中,MASC实现域间组播地址的分配;MBGP在域间传递组播路由信息;BGMP完成域间路由树的构造。此外还有一些组播路由策略,如PIM－SSM(特定信源协议无关组播)等,建立在其他组播业务模型上。目前只有短期方案MBGP、MSDP和PIM－SM是成熟的,并被许多运营商所使用,其他方案的标准还在研究中。9.5.2

IP组播技术的特点

IP组播技术具有以下特点:

(1)群地址。在组播网中,每个组播群组拥有惟一的组播地址(D类地址),一部分IP组播地址是由Internet管理机构分配的,其他的组播地址作为暂时地址被用户使用。组播数据包可以送到标识目的主机的组地址,发送者不必知道有哪些组成员,它自己不必是组成员,对组成员中主机的数目和位置也没有限制。主机不需要和组成员以及发送者商量,可以任意加入和离开组播组。使用组地址,不必知道主机指定的位置,可以找到具有此组播地址的任何资源和服务器,在动态变化的信息提供者中搜寻到需要的信息,或者发布信息到任意大小的可选用户群。

(2)规模可扩展性。如果网络速率提高,则广域组播网络的容量需要扩大。组播路由算法和协议如PIM－DM、PIM－SM、CBT等都支持网络规模的扩展,而群地址和动态性也是适应规模可扩展性的另一方面。

(3)健壮性。IP组播网络使用的路由协议和算法能适应网络路由动态变化,它采用软件状态刷新机制、制作路由备份等方法,来维护群组成员之间的连接,加强网络的健壮性。

(4)路由算法的独立性。组播路由算法和协议独立于单播路由使用的协议,但又依靠现存的单播路由表,在域内适应网络拓扑的变化,动态生成组播树。

(5)组播生成树的灵活性。组播生成树的形成与发送者和接收者的分布、网络的流量状况以及组成员的动态性有关,且组播生成树也反映了不同的组播路由算法和组播应用。灵活的组播生成树有利于数据包的传送,不容易造成网络的拥塞。9.5.3

IP组播在视频中的应用

如果要将组播通信应用在视频网络中,网络里的会议终端、网关、MCU(发送和接收主机)、网络路由器以及它们之间的网络结构必须支持组播,防火墙应设置成允许组播通过。

每个会议端点要能支持组播,网络接口卡能有效滤出由网络层IP组播地址被映射成的数据链路层地址;要有加入组播组请求的IGMP的软件和路由器通信并加入组播群;要有支持IP组播传送和接收的TCP/IP协议栈。在视频网络中IP组播通信的过程如下:

(1)端点送出一条IGMP加入消息到相邻路由器,端点的MAC地址映射为将要加入的D类组地址,并包含在IGMP数据报中,路由器知道端点想加入组播组。

(2)相邻路由器接收加入消息后,动态跟踪这些组播组,使用组播路由协议,在源端和接收端各个路由器之间建立组播生成树,从每个发送者伸展到所有接收者。

(3)在源端和接收端建立组播路由后,源端就开始沿着组播路由发送数据给各个接收者。

9.6视频会议中多画面合成技术

9.6.1压缩域合成

1.压缩域合成算法原理

H.261标准分为CIF和QCIF两种格式,其中一帧CIF格式图像的大小为352×288像素,一帧QCIF格式图像的大小为176×144像素,如表9－2所示。一帧H.261CIF图像由12个块组(GroupOfBlocks,GOB)组成,一帧H.261QCIF由3个块组(GOB)组成。两种格式的块组空间排列方式如图9－20所示,其数字为块组号。表9－2

H.261CIF和QCIF像素大小比较图9－20

H.261帧内块组空间的结构

H.261视频数据的编码过程如下:首先通过离散余弦变换(DCT)压缩图像数据,再经过变长编码进一步压缩;然后对视频数据进行四层复用数据结构封装,由上到下依次是:图像层、块组层、宏块层和像块层,该封装用来对视频数据进行重组。H.261解码过程是上述过程的逆过程。此处的压缩域四画面合成算法就是在图像层进行解码和编码处理的一种合成算法。为了说明算法实现原理,假设MCU设备同时与4个终端连接,并分别从终端接收H.261QCIF视频数据,MCU对4路数据进行压缩域合成处理,合并成1路H.261CIF格式视频数据,并将合并后的视频数据分别发送给4个终端,每个终端都只接收并解码1路H.261CIF格式的视频数据流,但能同时显示4个终端的画面。其合成系统结构图如图9－21所示。图9－21压缩域内4画面合成系统的结构

4画面合成需要完成三个方面的操作:

(1)处理图像帧头的时域参考量TR。由以上对H.261数据结构的介绍可知,TR为5bit,可取32个值,其取值公式为

TR=(Ns+Nd+1)mod32

式中:Ns为已经发送的图像数;Nd为从上次发送的图像之后所丢掉的图像数。时域参考量用来平滑视频的播放,让人的视觉流畅,是保证视频质量的重要方法。在合成图像中,时域参考量TR可以按照下列方法取值:

(2)处理图像层中帧头的各个字段值。图像合成之后只有一个图像层帧头,因此需要对4组源图像层帧头进行处理。当得到4路4层图像复用数据结构之后,只保留第1路的图像层帧头,丢掉其他3路的图像层帧头。其中时域参考量TR按上述方法填充;类型信息域PTYPE的第4位由原来的“0”改为“1”,亦即由QCIF图像标识修改为CIF图像标识。

(3)处理块组层块组头。合成过程需要把4组3个QCIF块组合并成一组12个CIF块组。MCU接收到4路H.261QCIF数据后,对4路视频数据均进行找帧头和找块组头操作,分别得到4路数据的帧头和3个块组数据。读取帧头信息的PTYPE字段,要保证视频数据信源格式为QCIF,并且其块组号分别是1、3、5。进行合并时,第1路QCIF数据的块组号保持不变;将第2路QCIF数据的块组号分别由1、3、5修改成2、4、6;将第3路QCIF数据的块组号分别由1、3、5修改成7、9、11;将第4路QCIF数据的块组号分别由1、3、5修改成8、10、12。合并后形成1路视频数据,要按照修改后的块组号进行顺序存储。4路H.261QCIF的视频数据在对块组号修改和块组排序后,形成了1路H.261CIF视频数据。

2.具体的合成算法

算法设计中几个关键问题在于:如何匹配帧头(PSC)和块组头(GSC);如何组合各路数据;如何协调各路视频之间的同步。

首先要寻找帧头和块组头,其过程需要对位进行操作。由H.261数据结构的知识可知,PSC(帧起始码)为00000000000000010000,而GSC(块组起始码)为0000000000000001,则PSC的前16位和GSC均为0000000000000001。在找帧头和块组头的过程中,首先对帧头和块组头不区分对待,按位进行操作,若出现连续15个或15个以上连0,并随后出现1时,则认为是找到了帧头或块组头。紧接其后的4位若为0000,则为PSC,找到帧头;若其值介于0001(1)和1100(12)之间,则是GSC,找到块组头;若为其他值,则出错。通过对接收到的H.261视频流进行循环查找,可得到各路视频的每一个块组数据。找到4路H.261QCIF的各个块组后,则需要对4路数据的块组进行排列组合,数据组合的方式在上面已经做了较为详细的介绍。在具体组合的实现过程中,利用一个类CMergeH.261来完成合并,该类的主要成员变量和成员函数及其描述如表9－3所示。表9－3类CMergeH261的主要成员变量和成员函数图9－22压缩域4画面合成算法的流程由于4路视频来自不同的视频源,因而会出现视频速率和帧速率不匹配的情况,即出现有的视频帧速率快,而有的帧速率慢的情况。为了保证4路数据之间的同步,需要采用一些有效的手段和方法。首先,在进行H.323呼叫协商的时候,保证4个终端发送的视频数据带宽和帧速率与标称值相同。然后,在MCU端利用RTP包包头信息分别计算出4路数据的实际帧速率,其计算方法如下:根据RTP包头信息的M标志位判断RTP包是否是一帧结束,若是,则记录下该RTP包到达的时间,即该帧到达的时间。每接收到25帧时,比较前后时间差,可实时计算出25帧所需要的实际时间T,将25除以T,则得到当前的实际帧速率。一般来讲,实际帧速率和其标称值会有一定的误差,此时需要根据标称值对实际帧速率进行调整。对照标称值,使帧速率快的视频数据接收线程进行等待,直到与标称值相同;对帧速率慢的视频数据进行空数据填充,使达到与标称值相同。采用上述方式,基本可以保证各路视频数据之间的同步。

压缩域合成算法在实际项目应用中,效果较为理想。相对于传统的模拟多画面合成技术来说,它无需对视频数据进行编解码,因此时延小,硬件成本低。在合并的过程仅仅对数据进行重新组合,不存在数据丢失现象,保真率达到100%。9.6.2像素域合成

以上讨论的压缩域合成算法,执行效率高,实际效果理想。但是,它仅仅适用于4路H.261QCIF到1路H.261CIF的4画面合成,因此,它的适用范围窄。针对这种情况,本节讨论像素域合成的多画面合成方法,理论上它适用于任何视频格式数据的多画面合成。因为只要能够将视频编码数据解码成YUV或者RGB这样像素点数据,即可利用此像素域合成算法。本节对算法的讨论,主要是针对YUV数据进行操作的,但同样适用于对RGB数据的处理。但一般都会采用对YUV数据进行操作,因为这样避免了从YUV数据到RGB数据的矩阵转换,有效地节省了系统资源和运行时间。像素域合成方法可分为两大类:无损