摘  要： 基于JMF和多播技术实现了一个没有多点控制单元的分布式视频会议。视音频的压缩由各个客户端来处理，并引入了视频会议的自由模式和主讲模式，两种模式之间的切换由各个对等点之间协调同步完成。在没有多点控制单元的情况下，依然保证视频会议的正常进行。会议中的各个对等点采用多播技术传输视音频流，以尽量减少对带宽的占用。
关键词： 多播；分布式；JMF；同步

1 视频会议的发展历程
    视频会议在电信行业己经存在了30多年，但在上世纪90年代以前，这些系统一直使用专用的编解码硬件和软件，视频会议都需要昂贵的设备和专线互连才能实现。
    而近几年来，随着国内外大型网络运营商对网络环境的建设和改造，以及ISDN、DDN、VPN、xDSL、ATM等技术的应用和推广，视音频编解码技术趋于成熟，图像传输质量大为提高，视频会议系统价格开始下调，视频会议系统的使用环境变得越来越好，因此无论是通信行业还是IT行业，都对视频会议领域重新进行关注。
    目前视频音频数据的编码解码技术也趋于成熟，计算机处理速度和附属板卡的处理速度也大幅度增强，很多以前需要专门的硬件设备MCU来进行的音视频编码解码操作，现在都可以在普通的计算机上进行，宽带的接入愈来愈廉价、普及，成本比硬件系统低很多，为了使视频会议“大众化”，利用其现有的计算机和网络系统，实现视频会议的应用，视频会议由“硬”到“软”是必然的趋势。就市场来看，据国际著名的通信研究机构Wainhouse Research近期预测，未来全球硬件视频会议设备销售的增长约为18%，而软件视频会议的增长则将达到144%。
2 多播技术的应用
    视频会议可以采取单播、多播和广播中任一技术来实现。单播即点对点的通信，需建立连接，虽然能保证数据不丢失，但很占用资源，例如，为了使视频会议系统显现的图像是动态的、连续的，一个视频信息流就需要占用1.5 Mb/s的带宽[1]，在一个单播（unicast）环境里，若有N个用户接收，视频服务器依次送出N个信息流，共需要N×1.5 Mb/s的带宽；如果服务器处于10 M的以太网内，6~7个信息流就占满了带宽；而在一个多播（multicast）环境里，不论网络中的用户数目有多少，服务器只发出的一个视频流，仅需1.5 Mb/s的带宽即可。
    广播技术在发送给参与视频会议用户的同时也会把视频流发送给那些对此不关心的用户，尤其视频音频的数据都比较大，这样会导致Internet面临崩溃，而多播通信的目标性更强并且比广播通信窄[1]。例如，如图1所示，若采用多播发送，则发送端A的视频流只会在路由器1复制一次，并发送给路由器2，路由器2再复制一次发给接收端B；如用广播技术，则发送端A的视频流到达路由器1时，路由器1将复制出三个视频流分别发给与它相连的3个路由器，这3个路由器又将收到的视频流广播到其他网络，而不管这些客户是否有需要。因此本系统采用多播技术来实现流媒体的传输。

3 分布式视频会议及JMF
    分布式视频会议是传统的会议系统（如：H.320视频会议系统）所没有的，又与点对点网络下视频会议不同[2]。在这种管理方式中，系统没有MCU，也就是没有集中控制和集中管理的设备，MCU的功能分别由终端实现。这种方式之所以能在基于分组的通信网（如IP网）中实现，其主要原因是网络中的通信在逻辑信道进行而不是以物理信道为单位进行的，并且目前视频编码技术和客户端计算机的处理能力也大幅提高，使得这种分布式视频会议模式成为可能。
    Java媒体框架JMF（Java Media Framework）[3]是一个把音频、视频和其他基于时间（Time-Base）的媒体结合到Java程序中的应用程序接口。它使Java程序具有许多新功能：捕捉音视频信号、存储、播放并处理媒体数据，并能够传输媒体数据和对多媒体格式进行编译码。它还支持压缩的媒体流及存储媒体的同步、控制、处理和播放。
    JMF包括JMF API和RTP API两个部分，前者的主要功能是捕捉、处理、存储和播放媒体流；后者主要是在网络上实时地（Real-Time）传输和接收媒体流，另外由于它是一种采用Java语言开发媒体应用的API，因此保证了媒体应用程序的跨平台性。
4 设计和核心技术实现
    模拟现实中的会议，会议模式包括自由模式和主讲模式两种。自由模式下，各个用户间可以自由交流，通过本地终端能看到和听到其他所有参与会议的人的动态画面和声音；主讲模式下，由一个终端用户主讲，其他用户每个终端只接收主讲的视频和音频流，并关闭自己的视频音频流的网络传输。各个终端既作为服务器也作为客户端，即每个用户从摄像头和麦克风捕获视频流和音频流并向其他3人传送，同时也分别接收其他3人传送来的视频音频流并分别同步播放，无需其他专门的硬件设备比如MCU来控制会议的进行，会议的管理控制由各个终端共同协作完成。流程图如图2所示。

4.1 流媒体的采集和压缩
    利用JMF中的类CaptureDevice获取本地捕获音频流的设备信息对象CaptureDeviceInfo，利用获取的设备信息创建媒体流的URL，并封装到数据源DataSource（JMF中处理多媒体数据的数据模型）。
    发送前对捕获的视频音频流进行压缩。由于直接从捕获的视频中得到的音频或视频原始数据很大，无法直接在网络上传输，例如，10 s内捕获的原始音频流1.70 M，而进行G723.1压缩后10 s内的数据量仅为151 KB，因此需要进行压缩编码然后再由网络传输。
4.2 流媒体的传输
    JMF提供的RTPConnector接口实现了与底层网络的独立性，RTP管理器使用RTPConnector接口可以实现基于底层UDP/TCP网络的媒体流应用。但JMF没有提供RTPConnector的缺省实现，为了实现UTP和RTP的通信，需要设计一个类RTPUTPHandle来实现RTPConnector接口中的主要的两个方法：getDataInputStream（）和getDataOutputStream（），这两个方法分别实现将接收到的数据源和要发送的数据源的处理给RTP管理器。但在实现这个RTPConnector接口前，还需要实现javax.media.protocol包中PushsourceStream和OutputDataStream接口中的方法。PushSoureStream中主要实现read（）方法，用于将底层网络中的UDP数据包中的数据传输给RTP管理器，OutputDataStream中主要需要实现write（）方法，用于将RTP管理的所要发送的数据输出到底层网络。用UML表示如图3所示。

4.3 同步处理
    由于处理器的状态要经历如图4所示几个阶段，首先获取要播放的流，再获得计算机资源，之后才能播放。当接收到来自同一个源的视频音频对时，若直接创建两个处理器并直接播放，则两个处理器都互相不考虑各自从初始状态（Unrealized）到播放状态（Started）所用的时间，则必定造成画面和声音的不同步。因此当其中一个处理器到达就绪状态时（Prefetched），如果另一个处理器还未就绪，则等待，直到另一个处理器到达就绪状态再播放。由于从Prefetched到Started状态的时间很短可忽略不计，便于实现音频视频的同步播放。若从Prefetched到Started状态还是造成了不同步，比如其中一个处理器从Prefetched到Started状态用时0.1 s，而另一个处理器用时0.2 s，造成0.1 s的不同步，则需要设置播放延时，即当两处理器都处于Prefetched状态时，设置延时为0.2 s，这样即使先进入Started也需要等0.1 s才能播放，依次实现播放的同步。

4.4 会议模式之间的切换
    系统在自由模式和主讲模式之间切换时，由于没有独立出来的控制器，如多点控制单元MCU，因此使用阻塞机制及Java的线程同步技术保证各终端之间能相互协作以完成会议模式的同步转换，避免出现某些终端处于自由模式而某些终端处于主讲模式。当自由模式向主讲模式转换时，由主讲向各个终端发送主讲控制信息，各个终端关闭本地视频音频流的发送，并进入阻塞状态，只接收主讲的视频音频流；当主讲模式向自由模式转换时，由主讲向各个终端发送结束主讲控制信息，各个终端解除阻塞状态，打开本地视频音频流的发送。
    软件化的分布式视频会议由于在客户端进行视音频的编码压缩操作，增加了一定的处理负担，采用软件编码也比硬件编码速度上有劣势，但可扩展性却是硬件视频会议无法比拟的，MCU的端口数直接限制了可接入的用户数，且可接入数越多，MCU的价格越昂贵，很难被广泛使用；在带宽足够大的情况下，分布式视频会议却不受这个限制。
参考文献
[1] 朱涛江，林剑.Java网络编程[M].北京：中国电力出版社，2005：478-500.
[2] 郭琳，杨晓军，王云泽.P2P网络下多媒体实时共享系统[J].计算机工程，2010，36（17）：245-248.
[3] 孙一林，彭波.Java网络编程实例[M].北京：清华大学出版社，2003.219-277.