一个应用级视频网关

《一个应用级视频网关》由会员分享，可在线阅读，更多相关《一个应用级视频网关（13页珍藏版）》请在金锄头文库上搜索。

1、一个一个应应用用级视频级视频网关网关Elan Amir 美国加利福尼亚大学伯克利分校elancs.berkeley.edu Steven McCanne 美国加利福尼亚大学伯克利分校mccannecs.berkeley.edu 张辉 卡内基梅隆大学hzhangcs.cmu.edu摘要： 当前对于视频在因特网的多点传输的模式是假设当前全国统一的网络是一个固 的平均带宽。源信号限制了他们的传输速率以适应其低带宽连接，即使高带宽 的连通性可能提过给许多参与者。我们提出了一个构架，它将视频传输能够分 为多个部分一不同的带宽请求在使用一个应用级的网关。我们的视频网关通过 小心的操纵视频流的数据和控制信息

2、，以一个单一的逻辑会议来连接到成对的 会议。尤其是，网关执行自适应带宽通过转换和速率控制。我们描叙了一个对 于转换JPEG运动到H.261有效的算法，其实时运行在标准工作站。通过使得实 时传输协议（RTP）中我们架构的一个完整的补充，视频网关与现有互联网视 频工具以一个透明的传输方式相互操作。我们已经建立了一个视频网关的原型， 并用它重新分配多兆位的JPEG视频流从湾区的千兆网，作为H.261 MBone的会 议的128kb/s标准。 关键字：会议协议；数字视频；图像和视频压缩和处理；多点传送；联网和通 信；高效转换。 1.介绍 一些多媒体应用的初步应用，例如在多点传输的骨干上nevot 13

3、, vat 7, ivs 16,nv 5,和在因特网和覆盖多点传送骨干的vic 9，或MBone4已经证明是成功 的。但是，在它们的新应用的全部的潜力被认识之前还有许多问题需要我们解 决。其中的一个问题就是怎样处理在一个会议中以不同特点的大量的接收器。 异质性对于因特网技术是天生固有的。它既存在于内部网络也存在于终端系统 中。在网络内部，由于连接速度和内部网络的不平衡负担分配的不匹配。在不 同收发对之间其带宽是不同的。虽然有一个部分的网络可能是一个高速ATM网 络，其他部分可能是以太网，骨干结构又可能是由T1和T3组成。此外，不同的 主机有不同的处理能力和视频/音频的不同的硬件配置。一个主机可

4、能是没有专 门视频硬件100 MIPS的工作站，另一个主机可能是又一个JPEG板的PC机。随着 互联网的发展，达到更高的速度和更大的规模时，由异质性所造成的问题只会 变得更糟。 在现有的应用中，每个发送者发送视频以同样的速度发向所有的接收器。对于 一个异构设置的接收机，源主机将不得以一个最不匹配的接收机的速度来运行。 这是不能令人满意的。相反，接收器以高带宽路径就应该得到相应的高品质。 解决这个问题的一个办法是使用分层编码算法 10 ，15 ，17 ，其中主机在低 的带宽接收更少的层。虽然这种做法是简洁和高效的，但它尚未实际部署，也不符合基于JPEG硬件的安装基础的和现有的视频应用。我们的目标

5、是为了建立 一个架构，使它符合当前流行的硬件和网络技术。 在本文中，我们提交了一种视频网关的设计和执行结果，它解决了非均质性问 题。我们的方法提供了一种匹配的传输质量的机制，它能匹配不同地区的一个 单一的逻辑组播会议的传输质量的异构带宽限制。网关是通过使用转换代码和 比特控制的方法来集中管理输入输出视频流。通过制作实时传输协议（RTP） 14，是我们架构的一个组成部分，视频网关能准确无误的处理当前的互联网 的视频工具。我们已经说明了我们在湾区千兆网（BAGNet）上能够执行，并成 功地用它来转换高速率JPEG 6 研讨会视频通过128字节/秒的视频流。2 背景和动机 在这节中，我们通过几个例子

6、来说明我们提出视频网关构架的需要。 2.1 BAGNet和MBone 我们的目标之一是在BAGNet环境中整合MBone应用。我们简要描述BAGNet和 MBone环境，然后，在视频网关的需要时，通过讨论现有MBone应用问题，通 过在BAGNet和一般互联网中。 BAGNet是一个OC - 3C认证（ 155 Mb / s） 的ATMnetwork，它连接了15旧金 山湾区网站包括大学，政府和工业研究实验室。BAGNet项目的一个目的是为了 以高品质的视频和音频开发和部署teleseminar的应用。目前，每个博客网站上 只有几个工作站直接连接到ATM网络，在这个组织中，这些机器中的一个被用

7、 来作为网关来连接到BAGNet与其他机器。通常情况下，以太网被用来在每个组 织中。在一个电信研讨方案中，一个机器直接连接到BAGNet，通过BAGNet将 多点传送高品质的高点播率的视频。一个全动态的JPEG压缩的NTSC质量的视 频流将消耗约600 Mb / s的带宽。虽然多个6 Mb / s的视频流，可以在BAGNet 很容易实现，转递这些视频流到以太网是不现实的当以太网在被共享时。此外， 它可能被描绘来传送视频在整个MBone上，其总带宽对于所有会议来说只有 500kb/s。因此，我们将在这样的环境中容纳三种类型的接收器：主机直接连接 BAGNet ，主机连接到BAGNet通过以太网和

8、路由器和主机在全球MBone 上。 图1(a)表明这样一种情况。假定主机H0以6Mb/s传输高品质的JPEG视频。ATM 交换机S转发到BAGNet和路由器R0，它连接到以太网上，其中包括载有各 MBone路由器受体R1。为了不使以太网溢出，我们在R0上运行一个视频网关， 它将6 Mb / s的JPEG格式转换为1 MB / s。因此，如H1的以太网主机仍然能收到 一个合理的高品质视频传输。我们将一个视频网关置于R1和MBone 之间。这 个网关通过转换的JPEG流到H.261和限制其输出比特率128字节/秒进一步减少了 带宽需求。2.2 连接远程MBone站点 我们的视频网关架构的另一个应用

9、程序连结与MBone一起几个远程站点。考虑 下面的例子：一个在伯克利分校的研讨会在当地的校园多点传输，一组在卡内 基梅隆大学研究人员想收听和参与。 不幸的是，像这样的情况-其中小群体通 过长途网络沟通-是不能通过当前的IP多播的基础设施而有效地支持的。 限制组播流量的范围的主要机制在今天的MBone是使用的TTL 。该机制的运作 细节如下。每个组播数据包在IP报头被分配一个存活时间编号， 每一个环节是 指定一个静态阈值。如果数据包的存活时间值小于阈值，该数据包不转。 通过在连接上放置更大的阀值，那些连接远程站点和每个组播数据包使用较小的 TTL数字，组播流量能包括在一个局部区域里。 在上面提到

10、的例子，为了使研究人员在监控装置中接收组播视频，视频必须派 出由伯克利使用高于跨国连接的TTL值发出，这意味着影片将分发给全国各地。 这不能令人满意。 以我们的视频网关，这个问题可以很容易地解决。通过在每个站点上放置一个 视频网关，并通过单播连接两个视频网关。图1 （ b ）就说明了这种情况。从 监控系统中的组播视频是由当地视频网关通过单播连接到远程视频网关，这依 次在监控系统中来传送视频到远程站点。 2.3 通过综合业务数字网链接的组播视频 大多数的MBone传输使用其目标速率为对于视频128kb/s和对于音频64kb/s，排 除了 MBone会议的简单的桥接，通过以128字节/秒的ISDN

11、线路。通过将128字 节/秒H.261编码视频流转换 为64字节/秒 H.261流（同样适应音频比特率） ， 一个MBone会议可以弥合了一个综合业务数字网链接，就像图1(c)所描绘的。 2.4 在无线连接上的组播视频 无线链路的特点是相对较低的带宽和高传输错误率。图1(b)说明在拓扑载控制 的无线主机中视频网关的作用。放置视频网关在基站路由器中(BS)，我们可以 以较低的带宽流转换传入的视频流和在无线连接上控制输出传输率。 3.视频网关 我们现在处理的一种视频网关架构的设计，它将灵活支持在上一节讨论的配置。 为了与现有 MBone视频工具相互操作，视频网关必须是与RTP协议兼容。 在 本节中

12、，我们给出了RTP协议的简要概述，讨论了转RTP数据流的影响，并提 出了一种结构，它可以一致的方式执行此转换协议。3.1实时传输协议 实时传输协议 14 是一个应用级协议，它的目的是为了满足多媒体应用的需求。 在IP协议栈中， RTP协议位于UDP协议之上 。该协议包括两部分：数据传输协议RTP和控制协议RTCP。 每个RTP协议数据包包括一个RTP协议数据包头和RTP协议的有效载荷。数据包 头包含一个序列号， 一个专门媒体的时间标志，和同步源的标识符(SSRC)。 SSRC提供了一种机制来确定媒体来源以一种独立于底层传输或网络层的方式。 终端主机随机分配他们SSRC,因为SSRC必须是在全球

13、唯一的RTP协议届会议确 定的，一种碰撞检测算法用来避免冲突。所有的数据包从一个SSRC相同的时间 和序列号空间的组成部分。通过SSRC标识符接收数据包进行播放。 RTP协议控制协议为数据分发监测(RTCP协议)提供方案，跨媒介同步和发件人 身份。这种控制信息被定期转递控制包的所有与会者，为数据包使用相同的分 配机制。传输时间间隔是随机和调整，根据会议规模保持RTCP协议带宽的使其 在一些结构上限之上。 分布监控分布监控 RTCP协议的主要功能是对数据的质量分布向机构提供反馈意见。这 一信息对于诊断故障和监测性能是至关重要的。它可以使用的应用软件来动态 适应网络拥塞 3 。监测统计数据的传播从

14、活动源通过RTCP协议发件报告（ SR ）和由接收机通过接收报告（RR）回传到整个会议 。统计数据包括除其他 外的发件人的累计数据包数量和累积字节数。每个接收器为每个活动源生成一 个单独的接收报告。RR数据包括一个累积的丢失包的总数，一个短期亏损指标 的估计，数据包的抖动和往返时间的估计。 同步同步 由于媒体流分布于不同的RTP协议中（具有独特SSRCs ） ，该协议对 于通过会议的同步媒体提供了一种机制，依靠规范的名称（记录）的标识符和 SRS 。每个SR包括局域实时和特定媒体时间单元的通信。根据他们的记录通过 匹配在不同媒体上的发件人报告，接收器可以根据不同媒体流时间补偿来重建 原始的同步

15、。 发件人身份发件人身份 每届会议的参与者通过结合文字说明来识别自己，使他们SSRC使 用“来源说明”（SDEC）消息。 除了基本协议的语义， RTP协议规范定义的两种类型的“中间制度” ：混频 器和翻译器。混频器将多个数据流和成一个单一输出流。为了结合流，混频器 可能通过注入缓冲延迟抵制网络抖动，因此必须使流同步。因此，混频器因此 有自己的SSRC标识符和在管理机构中显示明确。另一方面，翻译器没有同步的 数据流，不一定出现在管理机构中。 3.2 网关架构网关架构 从理论上讲，基本网关结构很简单： 我们只是建立一个应用程序级的路径，其 中加入两个单独的RTP协议，并适当改变了RTP协议的数据和

16、控制流。 RTP协 议的数据包是特别容易处理。我们可以简单地转发数据流从一个机构到另一个， 或是修改或转换以适应传输带宽。带宽可以进一步规范通过对输出应用率限幅 器。由于RTP协议数据流是自我描叙的和“无国籍” ，没有任何特殊的处理或 外部信号来进行转化流。通过直接连接两个管理机构，我们暗中合并标识符空 间和碰撞解决算法穿透网关。 然而，当我们考虑RTCP协议的数据包一个问题出现。虽然SDES消息可以流经 网关修改，同步信息和SR /RR分布的统计数字是有问题的。当一个网关转换流 时，数据包数，字节数和时间信息都将受到影响。因此， RTCP协议包不能简 单地通过网关转发，他们必须以自我一致的方式修改。 当我们第一次开始设计我们的视频网关时，我们遇到一个在协议定义中对这个 问题的不足处理。RTP协议草案规范第6修订版仅仅为混频器，它的同步流和翻译器不能修改数据包。因为我们希望我们的架构以承认数据转换，我们必须使 用混频器的设计。然而，由于混频器将成为同步的新起点，基于这种模式的视 频网关 ，不能维持跨媒体同步信息的 RTP协议