一个应用级视频网关

—个应用级视频网关ElanAmir美国加利福尼亚大学伯克利分校elan@StevenMcCanne美国加利福尼亚大学伯克利分校mccanne@张辉卡内基梅隆大学hzhang@摘要：当前对于视频在因特网的多点传输的模式是假设当前全国统一的网络是一个固的平均带宽。源信号限制了他们的传输速率以适应其低带宽连接，即使高带宽的连通性可能提过给许多参与者。我们提出了一个构架，它将视频传输能够分为多个部分一不同的带宽请求在使用一个应用级的网关。我们的视频网关通过小心的操纵视频流的数据和控制信息，以一个单一的逻辑会议来连接到成对的会议。尤其是，网关执行自适应带宽通过转换和速率控制。我们描叙了一个对于转换JPEG运动到H.261有效的算法，其实时运行在标准工作站。通过使得实时传输协议(RTP)中我们架构的一个完整的补充，视频网关与现有互联网视频工具以一个透明的传输方式相互操作。我们已经建立了一个视频网关的原型，并用它重新分配多兆位的JPEG视频流从湾区的千兆网，作为H.261MBone的会议的128kb/s标准。关键字：会议协议；数字视频；图像和视频压缩和处理；多点传送；联网和通信；咼效转换。1.介绍一些多媒体应用的初步应用，例如在多点传输的骨干上nevot[13],vat[7],ivs[16],nv⑸,和在因特网和覆盖多点传送骨干的vic[9],或MBone[4]已经证明是成功的。但是，在它们的新应用的全部的潜力被认识之前还有许多问题需要我们解决。其中的一个问题就是怎样处理在一个会议中以不同特点的大量的接收器。异质性对于因特网技术是天生固有的。它既存在于内部网络也存在于终端系统中。在网络内部，由于连接速度和内部网络的不平衡负担分配的不匹配。在不同收发对之间其带宽是不同的。虽然有一个部分的网络可能是一个高速ATM网络，其他部分可能是以太网，骨干结构又可能是由T1和T3组成。此外，不同的主机有不同的处理能力和视频/音频的不同的硬件配置。一个主机可能是没有专门视频硬件100MIPS的工作站，另一个主机可能是又一个JPEG板的PC机。随着互联网的发展，达到更高的速度和更大的规模时，由异质性所造成的问题只会变得更糟。在现有的应用中，每个发送者发送视频以同样的速度发向所有的接收器。对于一个异构设置的接收机，源主机将不得以一个最不匹配的接收机的速度来运行。这是不能令人满意的。相反，接收器以高带宽路径就应该得到相应的高品质。解决这个问题的一个办法是使用分层编码算法[10，15，17]，其中主机在低的带宽接收更少的层。虽然这种做法是简洁和高效的，但它尚未实际部署，也不符合基于JPEG硬件的安装基础的和现有的视频应用。我们的目标是为了建立一个架构，使它符合当前流行的硬件和网络技术。在本文中，我们提交了一种视频网关的设计和执行结果，它解决了非均质性问题。我们的方法提供了一种匹配的传输质量的机制，它能匹配不同地区的一个单一的逻辑组播会议的传输质量的异构带宽限制。网关是通过使用转换代码和比特控制的方法来集中管理输入输出视频流。通过制作实时传输协议(RTP)[14],是我们架构的一个组成部分，视频网关能准确无误的处理当前的互联网的视频工具。我们已经说明了我们在湾区千兆网(BAGNet)上能够执行，并成功地用它来转换高速率JPEG[6]研讨会视频通过128字节/秒的视频流。2背景和动机在这节中，我们通过几个例子来说明我们提出视频网关构架的需要。2.1BAGNet和MBone我们的目标之一是在BAGNet环境中整合MBone应用。我们简要描述BAGNet和MBone环境，然后，在视频网关的需要时，通过讨论现有MBone应用问题，通过在BAGNet和一般互联网中。BAGNet是一个0C-3C认证(155Mb/s)的ATMnetwork，它连接了15旧金山湾区网站包括大学，政府和工业研究实验室。BAGNet项目的一个目的是为了以高品质的视频和音频开发和部署teleseminar的应用。目前，每个博客网站上只有几个工作站直接连接到ATM网络，在这个组织中，这些机器中的一个被用来作为网关来连接到BAGNet与其他机器。通常情况下，以太网被用来在每个组织中。在一个电信研讨方案中，一个机器直接连接到BAGNet，通过BAGNet将多点传送高品质的高点播率的视频。一个全动态的JPEG压缩的NTSC质量的视频流将消耗约600Mb/s的带宽。虽然多个6Mb/s的视频流，可以在BAGNet很容易实现,转递这些视频流到以太网是不现实的当以太网在被共享时。此外，它可能被描绘来传送视频在整个MBone上，其总带宽对于所有会议来说只有500kb/s。因此，我们将在这样的环境中容纳三种类型的接收器：主机直接连接BAGNet，主机连接到BAGNet通过以太网和路由器和主机在全球MBone上。图1(a)表明这样一种情况。假定主机H0以6Mb/s传输高品质的JPEG视频。ATM交换机S转发到BAGNet和路由器R0，它连接到以太网上，其中包括载有各MBone路由器受体R1。为了不使以太网溢出，我们在R0上运行一个视频网关，它将6Mb/s的JPEG格式转换为1MB/s。因此，如H1的以太网主机仍然能收到一个合理的高品质视频传输。我们将一个视频网关置于R1和MBone之间。这个网关通过转换的JPEG流到H.261和限制其输出比特率128字节/秒进一步减少了带宽需求。2.2连接远程MBone站点我们的视频网关架构的另一个应用程序连结与MBone一起几个远程站点。考虑下面的例子：一个在伯克利分校的研讨会在当地的校园多点传输，一组在卡内基梅隆大学研究人员想收听和参与。不幸的是，像这样的情况-其中小群体通过长途网络沟通-是不能通过当前的IP多播的基础设施而有效地支持的。限制组播流量的范围的主要机制在今天的MBone是使用的TTL。该机制的运作细节如下。每个组播数据包在IP报头被分配一个存活时间编号，每一个环节是指定一个静态阈值。如果数据包的存活时间值小于阈值，该数据包不转。通过在连接上放置更大的阀值，那些连接远程站点和每个组播数据包使用较小的TTL数字，组播流量能包括在一个局部区域里。在上面提到的例子，为了使研究人员在监控装置中接收组播视频，视频必须派出由伯克利使用高于跨国连接的TTL值发出，这意味着影片将分发给全国各地。这不能令人满意。以我们的视频网关，这个问题可以很容易地解决。通过在每个站点上放置一个视频网关，并通过单播连接两个视频网关。图1 (b)就说明了这种情况。从监控系统中的组播视频是由当地视频网关通过单播连接到远程视频网关，这依次在监控系统中来传送视频到远程站点。2.3通过综合业务数字网链接的组播视频大多数的MBone传输使用其目标速率为对于视频128kb/s和对于音频64kb/s,排除了MBone会议的简单的桥接，通过以128字节/秒的ISDN线路。通过将128字节/秒H.261编码视频流转换为64字节/秒H.261流(同样适应音频比特率)，一个MBone会议可以弥合了一个综合业务数字网链接，就像图1(c)所描绘的。2.4在无线连接上的组播视频无线链路的特点是相对较低的带宽和高传输错误率。图1(b)说明在拓扑载控制的无线主机中视频网关的作用。放置视频网关在基站路由器中(BS),我们可以以较低的带宽流转换传入的视频流和在无线连接上控制输出传输率。3.视频网关我们现在处理的一种视频网关架构的设计，它将灵活支持在上一节讨论的配置。为了与现有MBone视频工具相互操作，视频网关必须是与RTP协议兼容。在本节中，我们给出了RTP协议的简要概述，讨论了转RTP数据流的影响，并提出了一种结构，它可以一致的方式执行此转换协议。何 (4)Figwe1Fqlu:pxau毋He沁日迪巾心^foa-日video3.1实时传输协议实时传输协议［14］是一个应用级协议，它的目的是为了满足多媒体应用的需求。在IP协议栈中，RTP协议位于UDP协议之上。该协议包括两部分：数据传输协议RTP和控制协议RTCP。每个RTP协议数据包包括一个RTP协议数据包头和RTP协议的有效载荷。数据包头包含一个序列号，一个专门媒体的时间标志，和同步源的标识符（SSRC）。SSRC提供了一种机制来确定媒体来源以一种独立于底层传输或网络层的方式。终端主机随机分配他们SSRC，因为SSRC必须是在全球唯一的RTP协议届会议确定的，一种碰撞检测算法用来避免冲突。所有的数据包从一个SSRC相同的时间和序列号空间的组成部分。通过SSRC标识符接收数据包进行播放。RTP协议控制协议为数据分发监测（RTCP协议）提供方案，跨媒介同步和发件人身份。这种控制信息被定期转递控制包的所有与会者，为数据包使用相同的分配机制。传输时间间隔是随机和调整，根据会议规模保持RTCP协议带宽的使其在一些结构上限之上。分布监控RTCP协议的主要功能是对数据的质量分布向机构提供反馈意见。这一信息对于诊断故障和监测性能是至关重要的。它可以使用的应用软件来动态适应网络拥塞［3］。监测统计数据的传播从活动源通过RTCP协议发件报告（SR）和由接收机通过接收报告（RR）回传到整个会议。统计数据包括除其他外的发件人的累计数据包数量和累积字节数。每个接收器为每个活动源生成一个单独的接收报告。RR数据包括一个累积的丢失包的总数，一个短期亏损指标的估计，数据包的抖动和往返时间的估计。同步由于媒体流分布于不同的RTP协议中（具有独特SSRCs），该协议对于通过会议的同步媒体提供了一种机制，依靠规范的名称（记录）的标识符和SRS。每个SR包括局域实时和特定媒体时间单元的通信。根据他们的记录通过匹配在不同媒体上的发件人报告，接收器可以根据不同媒体流时间补偿来重建原始的同止^步。发件人身份每届会议的参与者通过结合文字说明来识别自己，使他们SSRC使用“来源说明”（SDEC）消息。除了基本协议的语义，RTP协议规范定义的两种类型的“中间制度”：混频器和翻译器。混频器将多个数据流和成一个单一输出流。为了结合流，混频器可能通过注入缓冲延迟抵制网络抖动，因此必须使流同步。因此，混频器因此有自己的SSRC标识符和在管理机构中显示明确。另一方面，翻译器没有同步的数据流,不一定出现在管理机构中。3.2网关架构从理论上讲，基本网关结构很简单：我们只是建立一个应用程序级的路径，其中加入两个单独的RTP协议，并适当改变了RTP协议的数据和控制流。RTP协议的数据包是特别容易处理。我们可以简单地转发数据流从一个机构到另一个，或是修改或转换以适应传输带宽。带宽可以进一步规范通过对输出应用率限幅器。由于RTP协议数据流是自我描叙的和“无国籍”，没有任何特殊的处理或外部信号来进行转化流。通过直接连接两个管理机构，我们暗中合并标识符空间和碰撞解决算法穿透网关。然而，当我们考虑RTCP协议的数据包一个问题出现。虽然SDES消息可以流经网关修改，同步信息和SR/RR分布的统计数字是有问题的。当一个网关转换流时,数据包数，字节数和时间信息都将受到影响。因此，RTCP协议包不能简单地通过网关转发，他们必须以自我一致的方式修改。当我们第一次开始设计我们的视频网关时，我们遇到一个在协议定义中对这个问题的不足处理。RTP协议草案规范第6修订版仅仅为混频器，它的同步流和翻译器不能修改数据包。因为我们希望我们的架构以承认数据转换，我们必须使用混频器的设计。然而，由于混频器将成为同步的新起点，基于这种模式的视频网关，不能维持跨媒体同步信息的RTP协议的语义。也就是说，新生成的视频流不再和音频流在原信号是同步产生。对于这个问题的一个立即解决的办法是为了执行一项综合的音频/视频网关，在整个系统保持同步，但这使设计复杂化，并引入了不必要的新同步延迟。作为我们与RTP协议示意者互动的结果，翻译器和混频器的新定义出现在议定书草案第7版的修订中。修改后的规格放宽翻译器的限制，对于应用网关设计留下更多的自由。修订后的RTP协议规范使我们能够建立一个转换网关：保留跨媒体同步信息，而不需要更新时间媒体；提供最低限度的延迟，因为数据包能常常尽快转交当他们到达时；而且，以透明会议的方式操作。我们实现这个架构这些目标，它有效地通过所有RTCP协议的源识别信息，直接通过网关，但分离发送和接收报告的流。相反，发送和接收报告被修改以反映网关所看到的分配质量。、口 厂 M2 VGW (JPEG) 」 (H.251)图2—个视频网关在两个RTP多点传送组之间。M］组正在传输JPEG视频，然而组M2视频只有接收或传送H.261的能力。更具体的说，考虑图2中的情况，其中两个组播组Ml和M2通过视频网关VGW连接。假设Ml包含高速率的JPEG源以及低第速率的H.261源，而在M2中只包含H.261源。进一步假设网关配置为JPEG格式转换为H.261在M1/M2方向。在我们的架构中，网关只不过简单的传输H.261包到交替机构中（两个方向），但转JPEG包到H.261标准。虽然数据包以一种简单的方式转换，RTCP协议发送和接收报告必须处理如下：在M1中从JPEG源接受一个SR，VGW修改发送数据来反馈个H.261从VGW的原始转换流数据。在从一个H.261源在M1或M2中接收一个SR，VGW传送未修改的数据包。在M2的一个接收者中收到一个RR时，它从M1中在一个转换源中报告，VGW修改接收数据给JPEG接收数据看通过VGW。从M1或M2的一个接收者中在接受一个RR，它正被报告在一个非转换代码源，VGW传输未修改的包。在所有情况下，修改（或修改）RTCP协议数据包被立即转交给其他机构。由分配报告的解耦流量跨越网关，我们防止以二分之一的信号源，从另一半机构中学习分配问题。这可能会引起冲击避免算子方面的担忧，其中，一个信号源来依靠这样的信息来适应它的传输速率。然而，我们明确解耦实际上是一种可行的配置，即使在自适应速率控制时。记得转换操作的最初动机是提供带宽适应。而不是在源头上调整速率，最好是将调整的速度点接近拥挤的接收器，从而避免不必要的速度后退为了更好的连接接收器。因此，它使得对于网关源头更有意义，为了运行它自己的拥塞控制回路。3.3网关控制在上一节介绍的网关架构提供了一个普遍的机制为带宽适应和会议聚集。这一机制必须以某种方式来控制和配置。因此，我们出口的界面，允许远程代理人动态配置网关。控制界面可以让代理做如下操作：为每个数据流以及全球机构建立利率控制，从输入格式中为选择输出格式确定规则，为每个转换流定义压缩参数（例如，数字转换器），安装过滤器（例如，为了只传输“讲师的视频”）。这分解机理从政策上分离机制。通过以这种方式定义一个控制接口，我们取代了政策级的功能与机构控制外部代理人的联系。这种外部控制代理的设置超出了本文的范围。4•转换代码我们现在讨论的转换过程中，视频网关绘制一个压缩的视频比特流进入一个不同（低速率）比特流，既可通过采用同样的压缩格式与改变参数或完全应用另一种格式。我们呼吁代理执行此转换算法的一个转换机。4.1设计我们转设计的一个高级别描述是在图3。基本模式涉及转换从支持输入格式到一个（可能不同）输出格式。每个输入格式是由一个模块操纵，它解码输入比特流成一个中间的代表性。这代理被转化和传递到编码器，它产生了新的比特流以一个新的（或可能相同）格式。如果我们限制我们的设计依赖于一个单一的格式为了中间代理，我们将被迫采取像素代理，因为这是所有压缩方案中最不发达的特点。但是，要求所有转配置的方式解压缩所有的像素域，然后重新从零开始编码流，将会导致性能的重大损失。相反，我们允许多个中间格式。通过这种方式，编码器/解码器可优化其合作通过选择一个适当的中间格式。例如，基于DCT编码方案，如：JPEG和H.261可以更有效地转换使用DCT系数，绕过每个区块正向和反向的转换。因为我们已经分解了不同的转换机为不同的编码器和解码器的阶段，该系统很容易扩展。为了支持新的输入格式，例如，只有一个编码器模块需要得到实施。此外，以一种灵活的方式支持多种中间格式，我们定义在中间格式间定义的格式翻译器。例如，我们可能有一个JPEG解码器，仅能产生一个DCT的输出代理，需要一种基于小波变换的编码方案加以编码，只接受像素输入。而不是执行一个分离的的JPEG解码器，它直接产生像素，我们执行一个通用DCT的作为像素转换器。如果这项通用的办法的参数是不能令人满意的，它可以通过实施编码器/解码器对优化匹配。通过解耦的编码器和解码器，通过一个中间格式，我们可以在典型图像数据执行通用转变。这种转变是至关重要对于视频网关，因为在输入格式和输出格式之间的带宽的大量减少就不可能实现完全编码参数和格式的选择。例如，低于64字节/秒的比特率对于在30f/s的全尺寸的NTSC流是或多或少不可行的。相反，使用我们的转化模型，我们可以申请侵略性和时空抽取在顶部的格式转换。我们还可能需要执行几何转换框架，因为不是所有的压缩方案都支持同样的解决方案（例如，H.261只支持“公共交换格式”），或颜色抽取转换，因为不同的格式的抽样调查色度面位是不同的（例如，4时01分01对4:2:2YUV）。4.2一个JPEG/H.261转换器两个主要因素决定我们最初的转换设计的重点：（1）Motion-JPEG硬件的

的广泛部署并决定利用JPEG格式作为主要的BAGNet压缩方案，（2）MBone应用的大型安装基础那能解码H.261（vi（和ivc）以及H.261的低比特率的要求。在剩下的这一节，我们描述了一个有效率的JPEG到H.261的转换机。H.261规范定义了两种类型的视频模块：内部模块是完全独立于过去块的，中间模块从先前的区块预测的。由于跨块编码模式的差异，一个丟失的更新将导致重建错误，那将直到内部模式块刷新。在低比特率，这个中间的模块是十分重大的。内部的H.261协议解决这个问题的办法是避免内部模块完全阻塞和在外部取代取代模块。这种方法称为内H.261[9]依赖于“有条件的补充”，而不是运动补偿来降低比特率。在有条件的补充中，视频图像被分割成小模块，只有块的变化被传送。Transcodervq|EncoderITranscodervq|EncoderI图3转换机的基本设计。任何支持的输入格式都转换成任何支持的输出格式。中间阶段指由T执行一个转化在内部代理时，在必要时，为了匹配解码器和编码器的协议。除了在格式转换时任何固有的带宽减少，输出率可以从输入帧的到达，控制的解耦产生输出帧。内H.261通过使用H.261宏模块寻址略过未补充的模块而进行有条件补充。由于一个内部-H.261编码从未使用模式块，它不需要进行运动补偿，这大大降低了运行时的复杂性。此外，我们可以很容易地建立一个编码器，负责DCTs变换而不是像素作为输入。这样，编码器复杂度进一步降低，因为它不必计算DCTs。此属性是利用其数据流路径的优化，在下一节中详细讲叙。4.2.1数据流优化Figure4:Figure4:AgeneiicJPEGH.261transcodei.图4显示了一种JPEG/H.261转换器的通用执行的基本数据流向。转换器的输入是一个JPEG编码帧流。每帧解码到像素，其中涉及熵解码，逆向量化和反向变换。一旦在像素域，帧是H.261编码器的输入，它在每个模块上执行运动补偿和使用一种类似于JPEG格式的方法编码剩余运动。这种分解是直截了当的执行，因为它可以通过连接现有的源代码而简单的实现。然而，因为了一个软件实施，由此产生的结果是不能令人满意的。我们尝试用此精确的配置较好调整JPEG译码器和（内）H.261编码器从vic中。即使在一个快速工作站（SGI印第安纳，133MHzMIPSR4600SC），在无经验转换器的配置操作只在6-13f/s的范围内操作，远低于实时性能。JPEGH.261Figure5:AnoptunizedJPEG.H.261tratiscodei.JPEGH.261Figure5:AnoptunizedJPEG.H.261tratiscodei.在转换器中两个主要瓶颈是DCT运算和操作非压缩图像导致的存储量流量增大。减少或消除这些瓶颈，将大大改善转换器性能。通过在DCT域开展有条件增资和通过利用一个内部的H.261协议，它将DCTs作为输入，我们可以做的就是这个。图5显示的是修改的数据流过程。这里逆量化的JPEG输出被重定向到H.261量化器的输入，从而绕过两个变换计算。而且，由于有条件增资在DCT域中实现，我们可以去除内存流量的大部分，通过更早的决定模块是否被忽略。随着我们修改数据路径有两个并发症：分辨率转换和色度抽样。分辨率转换JPEG是最典型的以PAL或NTSC格式发送的，而H.261是CIF（或1/4-CIF）的解决方案。相比于采用一个昂贵的大规模的操作，我们只是抽样输入（如有必要）来近似匹配CIF或1/4-CIF方案。然后，为了NTSC，帧被嵌入在一个CIF几何方案中，使用灰色边界，对于PAL制式，帧的垂直边界上的一些像素被修剪掉。色度抽样由于大多数基于硬件的JPEG编解码器只支持4:2:2YUV损失的视频，当H.261要求4：2：1损失视频，我们必须通过二次垂直的抽样JPEG色度位面。这在像素区域里是微小的：简单的丢弃其他的像素（在低通滤波以避免混淆后）。一个蛮力计算方法是计算两个垂直临近模块的翻转8x8二维DCT变换，从16x8模块中产生一个8x8的模块，并提出转换这个8x8块。然而，这使我们的快速路径优化失败，依靠避免DCT的计算。原来认为像素二次抽样可以进行直接通过操作DCT系数来实现。由于二维DCT的是可分变换，我们只需要考虑一维抽样问题，也就是说，我们可以独立的再二维DCT的每一列上操作。附录载有派生的（近似）算法用来一个16信号的计算，采用直接操作两半的16个点的信号的两个8点DCT系数。输出是一个二次抽样信号的8点DCT变换。通过运行该算法的每列的两个相邻的垂直的8x8DCT，我们有效地对底层信号进行二次抽样。虽然我们的算法只是近似，但它的速度快，而且产生高质量的结果。4.3解决一些缺点通常提到转换系统的两个弱点是加强的端到端延迟和加密的不相容。增加的延迟是被招致的，例如，当编码JPEG压缩到MPEG（以B帧），因为编码器必须在产生新的输出之前收集几个帧以成“组图片”。然而，对于常用于互联网的压缩格式，这不是一个问题。基于有条件补充的数据包格式是故意设计的，以使每个数据包可以独立处理独其他的。因此，理论转换延迟是零（模加工，存储和转发延迟），因为我们可以在到达时尽快转换每个数据包。事实上，我们JPEG/H.261编码器会等待直到整个JPEG帧到达。由于交通通常从源头上被平滑，我们引起一帧间隔的延时。另一方面，如果JPEG数据包按次序到达，他们能够进行递增解码和逐步“对飞”输出数据包。其他的问题相对于编码系统是他们的加密时不相容性。这种说法是基于认为，转换代理将被纳入网络架构，其隐私将通过委托网络的加密密钥受到损害的。然而，在我们的模型中，转换器是一个应用层级用户部署的代理。因此，用户能够通过会话密钥以一个安全的方式配置转换器。5•执行我们实施我们的网关和转换器架构以一个称为vgw的原型架构。我们充分利用了基于vic的灵活的代码，通过整合vic的H.261编码器，JPEG译码和纳入vgw网络的执行工作。虽然我们最终的目标是以高效率的转换操作支持的几个组合体，目前的功能只支持在上一节描述的JPEG/H.261转换模型。不符合JPEG格式的流（或不打算转换）只是简单的通过网关转发。JPEG/H.261转换器通过修改vic的H.261编码器和JPEG解码器，以支持基于调用接口的DCT，我们将能够很容易地实施在上一节中描叙的转换器架构。JPEG解码器执行DCT变换系数的表驱动Huffman解码与有条件的补充。我们通过Huffman解码前六个月的DCT系数来优化补充模块并通过比较看出那些已经被传送了，就像在文献［9］中描叙的。如果他们是“类似不够”，我们通过剖析剩下的系数块跳过当前块，没有任何额外的处理。因此，在这种情况下，如果没有什么运动的场景，该系统就运行在Huffman的解码速度（这只是使用表查询）。一个DCT系数的帧缓冲区是通过解码器来保持的，它可以用来作为有条件补充决定的参考。当解码器遇到的补充模块时，它取代了相应区块的参考框架，并在位矢量上确立了一个特征位，来指示这个模块已经发生了变化。在整个帧解码后，位矢量和DCT帧缓冲区被传递给H.261编码器。编码器然后对每个H.261宏块包含改变块编码，通过使用一个索引表联系H.261宏块和“组块”地址到NTSC块号码。编码器以宏块处理跳过了补充模块。为了保证模块如果丢失后最终补充（或者，如果一个接收器连接一个转换器），一个更新过程促使每帧的一些额外的背景模块的传送。除了执行有条件补充，H.261编码器等分使用标量量化的系数。因为DCT系数的整个动态范围不是根本不可能实现的对于小的编码器，我们的动态调整每个宏模块的转换器，以保证模块中最大DCT变换系数是可以代表的。最后，在色度平板编码前，它必须是如上所述二次抽样。这个子样品通过在附录中使用编码实现，DCT帧缓冲区中的两个模块转成一个单一的DCT帧，存储在一个缓冲区里。这个临时的结果然后像往常一样进行编码。速率控制器一个网关的基本功能是通过转换数据包流调节输出带宽的。由于我们的编解码器的实现事使用固定数字转换器，我们不能依靠自适应量化微调输出比特率。相反，我们产生可变帧率输出，在必要时从输入流中放弃帧，以满足某一特定率的制约因素。大多数压缩方案是固定的，这意味着我们必须不断的解码输入流到一个中间帧缓冲区中，然后以低速重新编码。另一方面，与像运动的JPEG不固定格式，我们可以解码唯一的帧，我们在输入中能发送和丢弃其他的帧，从而节省计算时间。举例来说，我们假设，我们要测试以较低的费率一个H.261流（即从H.261转换为H.261）。我们可以通过应用两种方法一种更积极的量化器（为了交换比特率质量）和一种输出帧速率控制（为了微调产生的速率）。由于H.261是块导向，我们可以通过编码所有的模块合并一些输入帧成一个单一的输出帧，因此，改变了自上次输出帧。因此，输出的帧速率是独立于输入帧速率的，随着如下描叙的流量整形机制，我们才能实现所需要的带宽限制。我们通过调整帧的倍数实施变帧率方案。当从某一源的一个帧被发送是，下一帧的时间是远远不够进一步选择的将来的帧以至于所产生的比特率符合分配给该来源的速率。然而，预定输出帧的时间将不完全符合一个新的输入帧的到来。但是,如果我们包括了预定时间和在计算比特位的实际时间的差距时间，然后由此产生的输出率将将完全匹配的目标速率。此外，速率控制器执行流量平滑在整个帧时间里通过匹配一个单一帧的数据包。由于网关支持任意数量的活动视频源，我们必须扩大我们的速率控制算法来操纵多源。我们这样做最直截了当的可能的方式 速率控制器的一个单独的实例是运行的每个活动源像那些个体的总和，速率被配置的会议带宽所控制。分配给每个源的带宽的分数是动态指定的，通过一个外部会议协调协议。如果没有分配被明确指定，带宽将在一切活动源中平分。6•性能我们衡量vgw的性能，是通过在一个SGIIndy（133MHz的MIPS的R4600SC）运行IRIX5.3。JPEG量化表的生成是以一个30的输入值使用单独的JPEG组的公式，而且H.261量化器被设置为10。为了一个低运动情况，JPEG/内部-H.261转换器使用大约60%的CPU，而以30%处理30f/s的1/4-NTSC。对于一个非常高的运动情况，性能下降到15f/s。我们还比较了优化的相对性能和蛮力数据路径在4.2节中已经在叙述。最优化解释了在运行时参数时，三个改进中的一个因素，其中在低和高运动情况：morion日 fast-pathlowhigh12.9fs 33.3fs6.9f's 214f57•进一步的工作目前，视频网关只支持JPEG格式转换为H.261。我们打算执行另外的格式，包括为加州大学伯克利分校［1］的InfoPad项目的矢量量化方案制订。为了非转换代码流，速度控制器采用了仅有的包速率，而不是帧速率。这导致质量下降，因为数据包在通过比特流时随机丢弃。一个更有效的模型是为了通过控制帧速率调整带宽。换句话说，在输出上放置一个速率限制器要求转换所有的输入流。因此，我们需要制定支持相同格式之间转换。特别是，如果我们支H.261和NV压缩算法vgw将更加有用，这将在互联网中广泛使用。对于视频网关的外部控制接口尚未得到执行。我们计划实现它，在文献［9冲以“会议总线”抽象描述。会议总线为实时多媒体应用提供了一个高级别协调协议。简单的控制脚本可以很容易地实现通过使用一个TCL［11］接口会议总线。通过这种方式，用户可以为不可预见的应用轻松地配置网关。例如，一个脚本可以配置和动态控制网关在会议的与会者中切换。8.摘要我们已经提出了一个应用级网关，为了适应分组视频到多种多样的环境中传输。通过兼容一个RTP协议框架，我们的视频网关立即成为一个现有应用的不可分割的组成部分和互联网的网络基础设施。我们已经推出了一个灵活的架构可以转换多种视频格式。特别是，我们已经制定和实施一个有效的算法为Motion-JPEG到内部H.261的实时转换。最后，我们已经成功地部署该系统在生产环境中，高带宽的研讨会由BAGNet被桥接的MBone。9致谢我们感谢RahulGarg,DeanaGoldsmith和Razavi,他们为这片论文的初稿提供了有益的意见。我们的架构起源于在LBLMbone会议工具中的设计的框架，和VanJacobson开发。Van提供了有建设性的意见为我们的网关方案。最后，我们感谢VanJacobson，HenningSchulzrinne,RonFrederick,和VanJacobson，因为在1994年11月的电子邮件交流，影响我们的设计决定和澄清了RTP协议规范。附录本附录介绍了一个有效的算法（近似的）为抽样信号直接操作转换信号的DCT系数。我们使用矩阵分解就像在［8］。而不是单纯的因式分解矩阵，为减少许多的成倍操作，我们使用近似乘数，以减少他们的不动点的变化和增加。让x1和x2作为两个8点信号（代表作为列向量），X1和X2作为他们的DCTs。让x表示从（x1x2）t抽样后的信号。我们的问题然后是计算X，x的DCT变换，让G作为一个16*8的抽样矩阵，「_J1a随后，我们会表达像素低抽样运算作为DCT系数的一个运算：为避免混淆，我们让x1和x2通过低通滤波器。让h（n）作为我们的反混淆滤波器，而且H是它的列向量DCT。我们将H=（1,1,1,1,0,0,0,0）t作为一个非常简单的低通滤波器。然后，通过DCT卷积性质，我们能乘Xk和H，为了（近似的）有卷积h（n）和xk的效果。我们能写出H作为如下一个操作矩阵F：■■/.| 0 00 0 00 0 /.IU 0 0其中14是4*4特征，且0是一个4*4的零矩阵，现在，我们得出■=[T汕—住]|然后有 l-ji这一结果表明，我们可以计算损失信号的DCT,作为输入信号DCTs的的一个线性组合。线性方程组是由M决定的，它比较容易通过在图6显示的程序计算出来。然而，在8x8二维矩阵该算法的直接执行将需要成倍增加，这是在复杂性比蛮力方法更高的使用正向和反向DCTs。幸运的是，M的许多值是0,通过使用近似算子计算其执行速度是非常快。在RISC处理器，每个8角信号可以加载到寄存器，每个输出点以少量的变化和增加计算。对这个方案的代码，生产良好的定性结果,在图7给出。dctMatrlx_function{m_inQt■工ixM/LUN)v~Ot(N-l)for^1inv){k_^2*v+1J*1m[i+lr]_cos(k*pi/{2*N)J}m_m*sqrt(2/NJm[lr]_m[lr] /sqrt(2JmDB_de8