分布式视频会议系统的关键技术及实现


引言

在目前已成为计算机领域热点的群组协作计算工具中,视频会议系统是其中的一个重要组成部分。电路交换网络中的视频会议系统已有较成熟的模型,如ITU的H.320标准等,但分组交换网(包括Ethernet、Internet等)的使用正日益普及,新的解决方案必须着重考虑如何利用这种网络来实现视讯系统。

本文提出的方案并不针对某种具体网络,而是根据Internet上多点视频会议系统的需要设计的。它充分利用了分组交换网多播功能和高带宽特点,是基于RTP协议的分布式多点会议系统,端主机是支持IP多播的Solaris 2.x系统,具有以下特点:

每个节点的数据通过多播到达其他节点。

音频和视频的合成由端主机完成。

不使用参考时钟实现发送/接收编解码器的良好同步,对分组抖动和丢失有较好控制。

动态流控机制允许视频压缩器根据网络状态调整发送率。

采用一种适合IP网络并能穿越防火墙的目录服务体系。

分布式视频会议系统的关键技术

会议系统的控制和数据传送

这是集中式方案中MCU的主要功能,在分布式系统中,MCU的功能可由网络和/或端节点来实现。在我们的方案中,数据传送主要利用了分布式网络的多播功能,不少控制功能都由端主机和网络共同实现。

带宽的有效使用和服务质量保证

分组交换网的复用机制可有效利用带宽,但也可能导致报文抖动甚至丢失。Internet大部分还未实现服务质量(QoS)保证,传统应用中通常由较高层TCP/IP协议来保证可靠传输。TCP用重传机制实现可靠传输,其内部流控机制根据确认包动态调整发送率。对于实时会议,重传导致的延迟是无法忍受的,因此传输层协议使用不具有可靠传输和内部流控制的UDP,而端到端同步和流控的任务则转嫁到视频会议系统上。

目录服务功能

Internet不像电路交换网,它没有统一的寻址机制,另外还存在防火墙和地址不公开的问题,因此目录服务是分布式会议系统中要解决的重点问题。

  分布式多点视频会议系统的具体实现方案

整体结构

该系统的主要硬件如下:

音频/视频捕捉/回放卡。声音、图像和数据作为不同的流进行传送,接收者可选择从某个源只接收声音,这对于没有图像处理功能的端节点特别有用,用静默检测避免不发言时发送音频流。

Codec和DSP(数字信号处理器)卡。DSP根据端用户的选择合成视频和音频源,它还具有屏蔽时钟不同步、声音/图像不同步和分组丢失等功能。卡上还有一个Ethernet网卡,会议系统可直接连到LAN上,无需CPU的参与。音频/视频捕捉/回放卡和Codec/DSP卡之间有直接接口,可绕过系统总线,节省CPU时间。

传输层协议的选择

由于UDP不提供端到端可靠传输,出现了基于UDP、专为实时通信提供传输层服务的RTP协议。尽管RTP本身不实现服务质量保证,但它提供的多路复用、顺序号、时标、监控及对IP多播的灵活接口对我们设计的多播、同步、会话数据加密、动态流控、目录服务、安全穿越防火墙等方法非常重要。RTP是一个开放协议,为上层应用提供了充分的灵活性。但RTP的组成部分之一RTCP(实时传输控制协议)提供的松散管理和监控功能还不能满足我们所需的控制和管理功能(如动态获取和分发多播地址、分发会话密钥等),所以我们采用H.323的集中管理模型。

网络的多播

多播在现有网络中实现的并不多,在这种情形下,我们认为实现多播的途径可有以下几中:

使用实现了DVMRP的交换式以太网Hub,通过Hub之间的Tunnel功能在Internet上构造多播网络。

在Internet上以传统方式进行分组的复制和转发,端系统通过为每个目的节点复制和转发分组的方式来模拟多播。

当数据从实现多播的局域网向未实现的局域网发送时,使用RTP的Translator模拟多播功能。我们使用的是第三种,为了实现更方便的地址分配和安全保密功能,还需具有动态、分布式和安全特性的目录服务的配合。

压缩数据流的合成

在分布式系统中,网络的多播功能使每个端节点可同时接收多个源的图像和声音,而合成由端系统实现。为了降低开销,我们的合成是对压缩视频流进行的。压缩视频流的合成算法也是当前的研究热点,我们的算法利用了以下事实;几乎所有的标准视频压缩数据都包含一系列独立的由预定义分隔符分隔的编码组,通过检查分隔符可将压缩数据流分成像素区域。将各段压缩数据与像素区域对应起来后,就可根据用户设置来重新组装这些数据。

会话的保密

接收方发起的多播使得发送方无法控制接收数据的用户,局域网的广播性质使得局域网上任何主机都有可能监听会话,因此有必要对会话数据加密。可以用会话初始协议分发会话密钥,也可用RTP会话配置文件保存会话密钥(这种方法安全性低)。为了防止已知明文攻击,每个消息中应加入一次性且不可预测的信息。RTP报头的时标字段为我们提供了这个机制,而加密RTCP报文之前应在要加密的报文前添加一个随机数。

时钟同步和声音/视频同步

点到点连接中接收方根据数据到达速率实现与服务方的同步。

分布式多点会议中有多个发送/接收对需同步,这种方案就不适合了。我们设计了一种简单有效的方法解决时钟不同步和同一源的声音/图像不同步问题。该方法使用了RTP提供的时标,可简单概括为:静音抑制音频数据包的发送。声音在接收端以接收方的音频时钟回放,音频时钟的不同步在静默期间被抵消。音频/视频的同步是在每个音频突发的开始时刻,通过丢弃一些延迟的视频帧或者重用一些视频帧实现的。此机制不需回放时钟与捕捉时钟的同步,它能达到预期性能是基于以下事实:

突发平均持续时间相对静默持续时间较短;

捕捉端和回放端时钟的不同步较小。这两点使音频/视频的同步在较短的突发持续期间内不可能漂移很多。我们对不同源数据流之间的顺序关系没有采取任何控制。随着RMP(可靠多点发送协议)等协议在群组通信中的使用,我们将对这种顺序进行控制。

IP网目录服务目录服务在集中和分布式会议中都很重要。电路交换网中节点由固定号码标识,分组交换网中节点由IP地址来标识。异质网络中,ATM节点由E.164标识,POTS和ISDN节点由电话号码标识,Internet节点由IP地址标识,如果目录服务能将会议参加者的名字转换成其物理地址,将带来很大方便。在移动通信中,会议参加者可能从不同地方接入Internet,使用动态地址,目录服务更显得必要。如果防火墙内的用户不想暴露自己的IP地址,目录服务的功能将更复杂。

  Internet域名服务系统(DNS)是一种分布式目录服务解决方案,但普通的DNS系统不支持动态分配的IP地址。动态IP地址查询方案要求有一个实时登记机制获取用户登录时动态分配的IP地址。目前已有的实时登记协议有SDP、LDAP、安全动态更新的DNS等(分布式)。Internet数据库提供商也为各种应用提供了专用实时登记协议(集中式)。集中式方案易实现,但扩展性差,且要求所会议成员向同一服务提供商登记也不大可能。分布方式基于有DNS系统,实践证明它运行稳定、扩展性良好。安全动态更新的DNS就是一个理想选择。

目前人们提出的目录服务都未考虑穿越防火墙的问题。穿越防火墙最常用的方法是使用代理服务器。通用代理服务器也能进行IP地址转换,且有一整套强大的安全功能,但它们的通用性也带来了以下问题:

同时有许多应用使用可能造成延迟,无法保证实时性;

为黑客提供了可突破的漏洞;

无法提供不同子网间域名查询服务;

在IP地址转换级连的情况下会产生无法预料的情况。我们使用的专用代理能克服以上缺点,可在RTP的Mixer或Translator上实现 。

假设A和B分别位于两个不同的防火墙之内,我们可在A和B所在子网的防火墙上各设一个代理PA和PB,在它们共同连接的Internet有一个公共目录服务提供商。假设A是呼叫方,B是被呼叫方。下面是穿越防火墙通信的过程:

用户A登录到网上时向PA登记。PA为A建立一个内部记录,登记A的IP地址和E-mail地址。然后,PA向外部目录服务提供商登记A的用户名(E-mail地址)和自己的IP地址。用户B登录时,B和PB进行同样的操作。

当A要与B通信时,A向PA发一个呼叫请求,给出呼叫目标B的E-mail地址。

  PA向外部目录服务提供商发出解析名字B的请求。外部目录服务将返回步骤1中为B登记的地址(即PB的IP)。根据B的域名或目录服务提供的一些特殊信息,PA可以知道B处于某个防火墙内。

  PA向PB发出一个连接请求,给出呼叫方和被呼方的名字A和B。这样PA和PB就可为A和B建立一个虚连接,后面的通信可以通过A-PA-PB-B这条链路进行。

结束语

Internet 的发展促使了新的分布式多点视频会议解决方案的出现,分布式解决方案与电路交换网络中的集中式方案有很大区别。作为群组计算的一个重要应用,分布式多点视频会议系统会得到新的群组通信技术的进一步支持,如:更理想的多播路由算法和协议;能适应复杂网络环境的资源预留和信息过滤技术;可靠有序的通信保障;针对会议系统应用的支持。然而,如何最有效地使用这些支持来适应视频会议中复杂、多样的需求将继续是我们的研究主题。

分布式会议案例:(来自CSDN)

android:http://download.csdn.net/detail/aoliaoaoao/4981727
WIN:http://download.csdn.net/detail/aoliaoaoao/4983918
Linux:http://download.csdn.net/detail/aoliaoaoao/4983892
IOS:http://download.csdn.net/detail/aoliaoaoao/4983874

  • 0
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
视频对讲和流媒体转发是一种高并发、高数据量的应用场景,对数据库设计会有以下影响: 1. 数据库的读写压力增大:音视频对讲和流媒体转发需要大量的数据读写操作,特别是对于视频的实时流媒体转发,会增加数据库的读写压力。 2. 数据库的存储容量需求增加:音视频对讲和流媒体转发需要存储大量的音视频数据,会增加数据库的存储容量需求,因此需要考虑数据库的扩容和管理问题。 3. 数据库的性能要求增高:音视频对讲和流媒体转发需要实现实时传输和处理,因此需要保证数据库的高性能和低延迟,以确保音视频数据的传输和处理效率。 为了应对以上影响,可以采取以下措施: 1. 采用分布式存储技术:采用分布式存储技术将音视频数据分散存储在多个节点上,减轻单个数据库的读写压力和存储容量需求。 2. 数据库优化:对数据库的结构、索引和查询语句进行优化,提高数据库的访问效率和响应速度。 3. 数据库缓存:采用缓存技术缓存热点数据,减少数据库的访问频率和读写压力。 4. 增加数据库服务器的数量:增加数据库服务器的数量,实现负载均衡,提高数据库的并发处理能力和性能。 5. 采用流媒体服务器:采用流媒体服务器,实现视频数据的实时流媒体转发,减轻数据库的读写压力。 通过以上措施,可以有效地提高音视频对讲和流媒体转发的数据处理性能和效率,保证系统的稳定和可靠性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值