一個應(yīng)用級視頻網(wǎng)關(guān)

—個應(yīng)用級視頻網(wǎng)關(guān)ElanAmir美國加利福尼亞大學(xué)伯克利分校elan@StevenMcCanne美國加利福尼亞大學(xué)伯克利分校mccanne@張輝卡內(nèi)基梅隆大學(xué)hzhang@摘要：當(dāng)前對于視頻在因特網(wǎng)的多點傳輸?shù)哪Ｊ绞羌僭O(shè)當(dāng)前全國統(tǒng)一的網(wǎng)絡(luò)是一個固的平均帶寬。源信號限制了他們的傳輸速率以適應(yīng)其低帶寬連接，即使高帶寬的連通性可能提過給許多參與者。我們提出了一個構(gòu)架，它將視頻傳輸能夠分為多個部分一不同的帶寬請求在使用一個應(yīng)用級的網(wǎng)關(guān)。我們的視頻網(wǎng)關(guān)通過小心的操縱視頻流的數(shù)據(jù)和控制信息，以一個單一的邏輯會議來連接到成對的會議。尤其是，網(wǎng)關(guān)執(zhí)行自適應(yīng)帶寬通過轉(zhuǎn)換和速率控制。我們描敘了一個對于轉(zhuǎn)換JPEG運動到H.261有效的算法，其實時運行在標(biāo)準(zhǔn)工作站。通過使得實時傳輸協(xié)議(RTP)中我們架構(gòu)的一個完整的補充，視頻網(wǎng)關(guān)與現(xiàn)有互聯(lián)網(wǎng)視頻工具以一個透明的傳輸方式相互操作。我們已經(jīng)建立了一個視頻網(wǎng)關(guān)的原型，并用它重新分配多兆位的JPEG視頻流從灣區(qū)的千兆網(wǎng)，作為H.261MBone的會議的128kb/s標(biāo)準(zhǔn)。關(guān)鍵字：會議協(xié)議；數(shù)字視頻；圖像和視頻壓縮和處理；多點傳送；聯(lián)網(wǎng)和通信；咼效轉(zhuǎn)換。1.介紹一些多媒體應(yīng)用的初步應(yīng)用，例如在多點傳輸?shù)墓歉缮蟦evot[13],vat[7],ivs[16],nv⑸,和在因特網(wǎng)和覆蓋多點傳送骨干的vic[9],或MBone[4]已經(jīng)證明是成功的。但是，在它們的新應(yīng)用的全部的潛力被認(rèn)識之前還有許多問題需要我們解決。其中的一個問題就是怎樣處理在一個會議中以不同特點的大量的接收器。異質(zhì)性對于因特網(wǎng)技術(shù)是天生固有的。它既存在于內(nèi)部網(wǎng)絡(luò)也存在于終端系統(tǒng)中。在網(wǎng)絡(luò)內(nèi)部，由于連接速度和內(nèi)部網(wǎng)絡(luò)的不平衡負(fù)擔(dān)分配的不匹配。在不同收發(fā)對之間其帶寬是不同的。雖然有一個部分的網(wǎng)絡(luò)可能是一個高速ATM網(wǎng)絡(luò)，其他部分可能是以太網(wǎng)，骨干結(jié)構(gòu)又可能是由T1和T3組成。此外，不同的主機有不同的處理能力和視頻/音頻的不同的硬件配置。一個主機可能是沒有專門視頻硬件100MIPS的工作站，另一個主機可能是又一個JPEG板的PC機。隨著互聯(lián)網(wǎng)的發(fā)展，達(dá)到更高的速度和更大的規(guī)模時，由異質(zhì)性所造成的問題只會變得更糟。在現(xiàn)有的應(yīng)用中，每個發(fā)送者發(fā)送視頻以同樣的速度發(fā)向所有的接收器。對于一個異構(gòu)設(shè)置的接收機，源主機將不得以一個最不匹配的接收機的速度來運行。這是不能令人滿意的。相反，接收器以高帶寬路徑就應(yīng)該得到相應(yīng)的高品質(zhì)。解決這個問題的一個辦法是使用分層編碼算法[10，15，17]，其中主機在低的帶寬接收更少的層。雖然這種做法是簡潔和高效的，但它尚未實際部署，也不符合基于JPEG硬件的安裝基礎(chǔ)的和現(xiàn)有的視頻應(yīng)用。我們的目標(biāo)是為了建立一個架構(gòu)，使它符合當(dāng)前流行的硬件和網(wǎng)絡(luò)技術(shù)。在本文中，我們提交了一種視頻網(wǎng)關(guān)的設(shè)計和執(zhí)行結(jié)果，它解決了非均質(zhì)性問題。我們的方法提供了一種匹配的傳輸質(zhì)量的機制，它能匹配不同地區(qū)的一個單一的邏輯組播會議的傳輸質(zhì)量的異構(gòu)帶寬限制。網(wǎng)關(guān)是通過使用轉(zhuǎn)換代碼和比特控制的方法來集中管理輸入輸出視頻流。通過制作實時傳輸協(xié)議(RTP)[14],是我們架構(gòu)的一個組成部分，視頻網(wǎng)關(guān)能準(zhǔn)確無誤的處理當(dāng)前的互聯(lián)網(wǎng)的視頻工具。我們已經(jīng)說明了我們在灣區(qū)千兆網(wǎng)(BAGNet)上能夠執(zhí)行，并成功地用它來轉(zhuǎn)換高速率JPEG[6]研討會視頻通過128字節(jié)/秒的視頻流。2背景和動機在這節(jié)中，我們通過幾個例子來說明我們提出視頻網(wǎng)關(guān)構(gòu)架的需要。2.1BAGNet和MBone我們的目標(biāo)之一是在BAGNet環(huán)境中整合MBone應(yīng)用。我們簡要描述BAGNet和MBone環(huán)境，然后，在視頻網(wǎng)關(guān)的需要時，通過討論現(xiàn)有MBone應(yīng)用問題，通過在BAGNet和一般互聯(lián)網(wǎng)中。BAGNet是一個0C-3C認(rèn)證(155Mb/s)的ATMnetwork，它連接了15舊金山灣區(qū)網(wǎng)站包括大學(xué)，政府和工業(yè)研究實驗室。BAGNet項目的一個目的是為了以高品質(zhì)的視頻和音頻開發(fā)和部署teleseminar的應(yīng)用。目前，每個博客網(wǎng)站上只有幾個工作站直接連接到ATM網(wǎng)絡(luò)，在這個組織中，這些機器中的一個被用來作為網(wǎng)關(guān)來連接到BAGNet與其他機器。通常情況下，以太網(wǎng)被用來在每個組織中。在一個電信研討方案中，一個機器直接連接到BAGNet，通過BAGNet將多點傳送高品質(zhì)的高點播率的視頻。一個全動態(tài)的JPEG壓縮的NTSC質(zhì)量的視頻流將消耗約600Mb/s的帶寬。雖然多個6Mb/s的視頻流，可以在BAGNet很容易實現(xiàn),轉(zhuǎn)遞這些視頻流到以太網(wǎng)是不現(xiàn)實的當(dāng)以太網(wǎng)在被共享時。此外，它可能被描繪來傳送視頻在整個MBone上，其總帶寬對于所有會議來說只有500kb/s。因此，我們將在這樣的環(huán)境中容納三種類型的接收器：主機直接連接BAGNet，主機連接到BAGNet通過以太網(wǎng)和路由器和主機在全球MBone上。圖1(a)表明這樣一種情況。假定主機H0以6Mb/s傳輸高品質(zhì)的JPEG視頻。ATM交換機S轉(zhuǎn)發(fā)到BAGNet和路由器R0，它連接到以太網(wǎng)上，其中包括載有各MBone路由器受體R1。為了不使以太網(wǎng)溢出，我們在R0上運行一個視頻網(wǎng)關(guān)，它將6Mb/s的JPEG格式轉(zhuǎn)換為1MB/s。因此，如H1的以太網(wǎng)主機仍然能收到一個合理的高品質(zhì)視頻傳輸。我們將一個視頻網(wǎng)關(guān)置于R1和MBone之間。這個網(wǎng)關(guān)通過轉(zhuǎn)換的JPEG流到H.261和限制其輸出比特率128字節(jié)/秒進(jìn)一步減少了帶寬需求。2.2連接遠(yuǎn)程MBone站點我們的視頻網(wǎng)關(guān)架構(gòu)的另一個應(yīng)用程序連結(jié)與MBone一起幾個遠(yuǎn)程站點?？紤]下面的例子：一個在伯克利分校的研討會在當(dāng)?shù)氐男@多點傳輸，一組在卡內(nèi)基梅隆大學(xué)研究人員想收聽和參與。不幸的是，像這樣的情況-其中小群體通過長途網(wǎng)絡(luò)溝通-是不能通過當(dāng)前的IP多播的基礎(chǔ)設(shè)施而有效地支持的。限制組播流量的范圍的主要機制在今天的MBone是使用的TTL。該機制的運作細(xì)節(jié)如下。每個組播數(shù)據(jù)包在IP報頭被分配一個存活時間編號，每一個環(huán)節(jié)是指定一個靜態(tài)閾值。如果數(shù)據(jù)包的存活時間值小于閾值，該數(shù)據(jù)包不轉(zhuǎn)。通過在連接上放置更大的閥值，那些連接遠(yuǎn)程站點和每個組播數(shù)據(jù)包使用較小的TTL數(shù)字，組播流量能包括在一個局部區(qū)域里。在上面提到的例子，為了使研究人員在監(jiān)控裝置中接收組播視頻，視頻必須派出由伯克利使用高于跨國連接的TTL值發(fā)出，這意味著影片將分發(fā)給全國各地。這不能令人滿意。以我們的視頻網(wǎng)關(guān)，這個問題可以很容易地解決。通過在每個站點上放置一個視頻網(wǎng)關(guān)，并通過單播連接兩個視頻網(wǎng)關(guān)。圖1 (b)就說明了這種情況。從監(jiān)控系統(tǒng)中的組播視頻是由當(dāng)?shù)匾曨l網(wǎng)關(guān)通過單播連接到遠(yuǎn)程視頻網(wǎng)關(guān)，這依次在監(jiān)控系統(tǒng)中來傳送視頻到遠(yuǎn)程站點。2.3通過綜合業(yè)務(wù)數(shù)字網(wǎng)鏈接的組播視頻大多數(shù)的MBone傳輸使用其目標(biāo)速率為對于視頻128kb/s和對于音頻64kb/s,排除了MBone會議的簡單的橋接，通過以128字節(jié)/秒的ISDN線路。通過將128字節(jié)/秒H.261編碼視頻流轉(zhuǎn)換為64字節(jié)/秒H.261流(同樣適應(yīng)音頻比特率)，一個MBone會議可以彌合了一個綜合業(yè)務(wù)數(shù)字網(wǎng)鏈接，就像圖1(c)所描繪的。2.4在無線連接上的組播視頻無線鏈路的特點是相對較低的帶寬和高傳輸錯誤率。圖1(b)說明在拓?fù)漭d控制的無線主機中視頻網(wǎng)關(guān)的作用。放置視頻網(wǎng)關(guān)在基站路由器中(BS),我們可以以較低的帶寬流轉(zhuǎn)換傳入的視頻流和在無線連接上控制輸出傳輸率。3.視頻網(wǎng)關(guān)我們現(xiàn)在處理的一種視頻網(wǎng)關(guān)架構(gòu)的設(shè)計，它將靈活支持在上一節(jié)討論的配置。為了與現(xiàn)有MBone視頻工具相互操作，視頻網(wǎng)關(guān)必須是與RTP協(xié)議兼容。在本節(jié)中，我們給出了RTP協(xié)議的簡要概述，討論了轉(zhuǎn)RTP數(shù)據(jù)流的影響，并提出了一種結(jié)構(gòu)，它可以一致的方式執(zhí)行此轉(zhuǎn)換協(xié)議。何 (4)Figwe1Fqlu:pxau毋He沁日迪巾心^foa-日video3.1實時傳輸協(xié)議實時傳輸協(xié)議［14］是一個應(yīng)用級協(xié)議，它的目的是為了滿足多媒體應(yīng)用的需求。在IP協(xié)議棧中，RTP協(xié)議位于UDP協(xié)議之上。該協(xié)議包括兩部分：數(shù)據(jù)傳輸協(xié)議RTP和控制協(xié)議RTCP。每個RTP協(xié)議數(shù)據(jù)包包括一個RTP協(xié)議數(shù)據(jù)包頭和RTP協(xié)議的有效載荷。數(shù)據(jù)包頭包含一個序列號，一個專門媒體的時間標(biāo)志，和同步源的標(biāo)識符（SSRC）。SSRC提供了一種機制來確定媒體來源以一種獨立于底層傳輸或網(wǎng)絡(luò)層的方式。終端主機隨機分配他們SSRC，因為SSRC必須是在全球唯一的RTP協(xié)議屆會議確定的，一種碰撞檢測算法用來避免沖突。所有的數(shù)據(jù)包從一個SSRC相同的時間和序列號空間的組成部分。通過SSRC標(biāo)識符接收數(shù)據(jù)包進(jìn)行播放。RTP協(xié)議控制協(xié)議為數(shù)據(jù)分發(fā)監(jiān)測（RTCP協(xié)議）提供方案，跨媒介同步和發(fā)件人身份。這種控制信息被定期轉(zhuǎn)遞控制包的所有與會者，為數(shù)據(jù)包使用相同的分配機制。傳輸時間間隔是隨機和調(diào)整，根據(jù)會議規(guī)模保持RTCP協(xié)議帶寬的使其在一些結(jié)構(gòu)上限之上。分布監(jiān)控RTCP協(xié)議的主要功能是對數(shù)據(jù)的質(zhì)量分布向機構(gòu)提供反饋意見。這一信息對于診斷故障和監(jiān)測性能是至關(guān)重要的。它可以使用的應(yīng)用軟件來動態(tài)適應(yīng)網(wǎng)絡(luò)擁塞［3］。監(jiān)測統(tǒng)計數(shù)據(jù)的傳播從活動源通過RTCP協(xié)議發(fā)件報告（SR）和由接收機通過接收報告（RR）回傳到整個會議。統(tǒng)計數(shù)據(jù)包括除其他外的發(fā)件人的累計數(shù)據(jù)包數(shù)量和累積字節(jié)數(shù)。每個接收器為每個活動源生成一個單獨的接收報告。RR數(shù)據(jù)包括一個累積的丟失包的總數(shù)，一個短期虧損指標(biāo)的估計，數(shù)據(jù)包的抖動和往返時間的估計。同步由于媒體流分布于不同的RTP協(xié)議中（具有獨特SSRCs），該協(xié)議對于通過會議的同步媒體提供了一種機制，依靠規(guī)范的名稱（記錄）的標(biāo)識符和SRS。每個SR包括局域?qū)崟r和特定媒體時間單元的通信。根據(jù)他們的記錄通過匹配在不同媒體上的發(fā)件人報告，接收器可以根據(jù)不同媒體流時間補償來重建原始的同止^步。發(fā)件人身份每屆會議的參與者通過結(jié)合文字說明來識別自己，使他們SSRC使用“來源說明”（SDEC）消息。除了基本協(xié)議的語義，RTP協(xié)議規(guī)范定義的兩種類型的“中間制度”：混頻器和翻譯器?；祛l器將多個數(shù)據(jù)流和成一個單一輸出流。為了結(jié)合流，混頻器可能通過注入緩沖延遲抵制網(wǎng)絡(luò)抖動，因此必須使流同步。因此，混頻器因此有自己的SSRC標(biāo)識符和在管理機構(gòu)中顯示明確。另一方面，翻譯器沒有同步的數(shù)據(jù)流,不一定出現(xiàn)在管理機構(gòu)中。3.2網(wǎng)關(guān)架構(gòu)從理論上講，基本網(wǎng)關(guān)結(jié)構(gòu)很簡單：我們只是建立一個應(yīng)用程序級的路徑，其中加入兩個單獨的RTP協(xié)議，并適當(dāng)改變了RTP協(xié)議的數(shù)據(jù)和控制流。RTP協(xié)議的數(shù)據(jù)包是特別容易處理。我們可以簡單地轉(zhuǎn)發(fā)數(shù)據(jù)流從一個機構(gòu)到另一個，或是修改或轉(zhuǎn)換以適應(yīng)傳輸帶寬。帶寬可以進(jìn)一步規(guī)范通過對輸出應(yīng)用率限幅器。由于RTP協(xié)議數(shù)據(jù)流是自我描敘的和“無國籍”，沒有任何特殊的處理或外部信號來進(jìn)行轉(zhuǎn)化流。通過直接連接兩個管理機構(gòu)，我們暗中合并標(biāo)識符空間和碰撞解決算法穿透網(wǎng)關(guān)。然而，當(dāng)我們考慮RTCP協(xié)議的數(shù)據(jù)包一個問題出現(xiàn)。雖然SDES消息可以流經(jīng)網(wǎng)關(guān)修改，同步信息和SR/RR分布的統(tǒng)計數(shù)字是有問題的。當(dāng)一個網(wǎng)關(guān)轉(zhuǎn)換流時,數(shù)據(jù)包數(shù)，字節(jié)數(shù)和時間信息都將受到影響。因此，RTCP協(xié)議包不能簡單地通過網(wǎng)關(guān)轉(zhuǎn)發(fā)，他們必須以自我一致的方式修改。當(dāng)我們第一次開始設(shè)計我們的視頻網(wǎng)關(guān)時，我們遇到一個在協(xié)議定義中對這個問題的不足處理。RTP協(xié)議草案規(guī)范第6修訂版僅僅為混頻器，它的同步流和翻譯器不能修改數(shù)據(jù)包。因為我們希望我們的架構(gòu)以承認(rèn)數(shù)據(jù)轉(zhuǎn)換，我們必須使用混頻器的設(shè)計。然而，由于混頻器將成為同步的新起點，基于這種模式的視頻網(wǎng)關(guān)，不能維持跨媒體同步信息的RTP協(xié)議的語義。也就是說，新生成的視頻流不再和音頻流在原信號是同步產(chǎn)生。對于這個問題的一個立即解決的辦法是為了執(zhí)行一項綜合的音頻/視頻網(wǎng)關(guān)，在整個系統(tǒng)保持同步，但這使設(shè)計復(fù)雜化，并引入了不必要的新同步延遲。作為我們與RTP協(xié)議示意者互動的結(jié)果，翻譯器和混頻器的新定義出現(xiàn)在議定書草案第7版的修訂中。修改后的規(guī)格放寬翻譯器的限制，對于應(yīng)用網(wǎng)關(guān)設(shè)計留下更多的自由。修訂后的RTP協(xié)議規(guī)范使我們能夠建立一個轉(zhuǎn)換網(wǎng)關(guān)：保留跨媒體同步信息，而不需要更新時間媒體；提供最低限度的延遲，因為數(shù)據(jù)包能常常盡快轉(zhuǎn)交當(dāng)他們到達(dá)時；而且，以透明會議的方式操作。我們實現(xiàn)這個架構(gòu)這些目標(biāo)，它有效地通過所有RTCP協(xié)議的源識別信息，直接通過網(wǎng)關(guān)，但分離發(fā)送和接收報告的流。相反，發(fā)送和接收報告被修改以反映網(wǎng)關(guān)所看到的分配質(zhì)量。、口 廠 M2 VGW (JPEG) 」 (H.251)圖2—個視頻網(wǎng)關(guān)在兩個RTP多點傳送組之間。M］組正在傳輸JPEG視頻，然而組M2視頻只有接收或傳送H.261的能力。更具體的說，考慮圖2中的情況，其中兩個組播組Ml和M2通過視頻網(wǎng)關(guān)VGW連接。假設(shè)Ml包含高速率的JPEG源以及低第速率的H.261源，而在M2中只包含H.261源。進(jìn)一步假設(shè)網(wǎng)關(guān)配置為JPEG格式轉(zhuǎn)換為H.261在M1/M2方向。在我們的架構(gòu)中，網(wǎng)關(guān)只不過簡單的傳輸H.261包到交替機構(gòu)中（兩個方向），但轉(zhuǎn)JPEG包到H.261標(biāo)準(zhǔn)。雖然數(shù)據(jù)包以一種簡單的方式轉(zhuǎn)換，RTCP協(xié)議發(fā)送和接收報告必須處理如下：在M1中從JPEG源接受一個SR，VGW修改發(fā)送數(shù)據(jù)來反饋個H.261從VGW的原始轉(zhuǎn)換流數(shù)據(jù)。在從一個H.261源在M1或M2中接收一個SR，VGW傳送未修改的數(shù)據(jù)包。在M2的一個接收者中收到一個RR時，它從M1中在一個轉(zhuǎn)換源中報告，VGW修改接收數(shù)據(jù)給JPEG接收數(shù)據(jù)看通過VGW。從M1或M2的一個接收者中在接受一個RR，它正被報告在一個非轉(zhuǎn)換代碼源，VGW傳輸未修改的包。在所有情況下，修改（或修改）RTCP協(xié)議數(shù)據(jù)包被立即轉(zhuǎn)交給其他機構(gòu)。由分配報告的解耦流量跨越網(wǎng)關(guān)，我們防止以二分之一的信號源，從另一半機構(gòu)中學(xué)習(xí)分配問題。這可能會引起沖擊避免算子方面的擔(dān)憂，其中，一個信號源來依靠這樣的信息來適應(yīng)它的傳輸速率。然而，我們明確解耦實際上是一種可行的配置，即使在自適應(yīng)速率控制時。記得轉(zhuǎn)換操作的最初動機是提供帶寬適應(yīng)。而不是在源頭上調(diào)整速率，最好是將調(diào)整的速度點接近擁擠的接收器，從而避免不必要的速度后退為了更好的連接接收器。因此，它使得對于網(wǎng)關(guān)源頭更有意義，為了運行它自己的擁塞控制回路。3.3網(wǎng)關(guān)控制在上一節(jié)介紹的網(wǎng)關(guān)架構(gòu)提供了一個普遍的機制為帶寬適應(yīng)和會議聚集。這一機制必須以某種方式來控制和配置。因此，我們出口的界面，允許遠(yuǎn)程代理人動態(tài)配置網(wǎng)關(guān)。控制界面可以讓代理做如下操作：為每個數(shù)據(jù)流以及全球機構(gòu)建立利率控制，從輸入格式中為選擇輸出格式確定規(guī)則，為每個轉(zhuǎn)換流定義壓縮參數(shù)（例如，數(shù)字轉(zhuǎn)換器），安裝過濾器（例如，為了只傳輸“講師的視頻”）。這分解機理從政策上分離機制。通過以這種方式定義一個控制接口，我們?nèi)〈苏呒壍墓δ芘c機構(gòu)控制外部代理人的聯(lián)系。這種外部控制代理的設(shè)置超出了本文的范圍。4?轉(zhuǎn)換代碼我們現(xiàn)在討論的轉(zhuǎn)換過程中，視頻網(wǎng)關(guān)繪制一個壓縮的視頻比特流進(jìn)入一個不同（低速率）比特流，既可通過采用同樣的壓縮格式與改變參數(shù)或完全應(yīng)用另一種格式。我們呼吁代理執(zhí)行此轉(zhuǎn)換算法的一個轉(zhuǎn)換機。4.1設(shè)計我們轉(zhuǎn)設(shè)計的一個高級別描述是在圖3?；灸Ｊ缴婕稗D(zhuǎn)換從支持輸入格式到一個（可能不同）輸出格式。每個輸入格式是由一個模塊操縱，它解碼輸入比特流成一個中間的代表性。這代理被轉(zhuǎn)化和傳遞到編碼器，它產(chǎn)生了新的比特流以一個新的（或可能相同）格式。如果我們限制我們的設(shè)計依賴于一個單一的格式為了中間代理，我們將被迫采取像素代理，因為這是所有壓縮方案中最不發(fā)達(dá)的特點。但是，要求所有轉(zhuǎn)配置的方式解壓縮所有的像素域，然后重新從零開始編碼流，將會導(dǎo)致性能的重大損失。相反，我們允許多個中間格式。通過這種方式，編碼器/解碼器可優(yōu)化其合作通過選擇一個適當(dāng)?shù)闹虚g格式。例如，基于DCT編碼方案，如：JPEG和H.261可以更有效地轉(zhuǎn)換使用DCT系數(shù)，繞過每個區(qū)塊正向和反向的轉(zhuǎn)換。因為我們已經(jīng)分解了不同的轉(zhuǎn)換機為不同的編碼器和解碼器的階段，該系統(tǒng)很容易擴展。為了支持新的輸入格式，例如，只有一個編碼器模塊需要得到實施。此外，以一種靈活的方式支持多種中間格式，我們定義在中間格式間定義的格式翻譯器。例如，我們可能有一個JPEG解碼器，僅能產(chǎn)生一個DCT的輸出代理，需要一種基于小波變換的編碼方案加以編碼，只接受像素輸入。而不是執(zhí)行一個分離的的JPEG解碼器，它直接產(chǎn)生像素，我們執(zhí)行一個通用DCT的作為像素轉(zhuǎn)換器。如果這項通用的辦法的參數(shù)是不能令人滿意的，它可以通過實施編碼器/解碼器對優(yōu)化匹配。通過解耦的編碼器和解碼器，通過一個中間格式，我們可以在典型圖像數(shù)據(jù)執(zhí)行通用轉(zhuǎn)變。這種轉(zhuǎn)變是至關(guān)重要對于視頻網(wǎng)關(guān)，因為在輸入格式和輸出格式之間的帶寬的大量減少就不可能實現(xiàn)完全編碼參數(shù)和格式的選擇。例如，低于64字節(jié)/秒的比特率對于在30f/s的全尺寸的NTSC流是或多或少不可行的。相反，使用我們的轉(zhuǎn)化模型，我們可以申請侵略性和時空抽取在頂部的格式轉(zhuǎn)換。我們還可能需要執(zhí)行幾何轉(zhuǎn)換框架，因為不是所有的壓縮方案都支持同樣的解決方案（例如，H.261只支持“公共交換格式”），或顏色抽取轉(zhuǎn)換，因為不同的格式的抽樣調(diào)查色度面位是不同的（例如，4時01分01對4:2:2YUV）。4.2一個JPEG/H.261轉(zhuǎn)換器兩個主要因素決定我們最初的轉(zhuǎn)換設(shè)計的重點：（1）Motion-JPEG硬件的

的廣泛部署并決定利用JPEG格式作為主要的BAGNet壓縮方案，（2）MBone應(yīng)用的大型安裝基礎(chǔ)那能解碼H.261（vi（和ivc）以及H.261的低比特率的要求。在剩下的這一節(jié)，我們描述了一個有效率的JPEG到H.261的轉(zhuǎn)換機。H.261規(guī)范定義了兩種類型的視頻模塊：內(nèi)部模塊是完全獨立于過去塊的，中間模塊從先前的區(qū)塊預(yù)測的。由于跨塊編碼模式的差異，一個丟失的更新將導(dǎo)致重建錯誤，那將直到內(nèi)部模式塊刷新。在低比特率，這個中間的模塊是十分重大的。內(nèi)部的H.261協(xié)議解決這個問題的辦法是避免內(nèi)部模塊完全阻塞和在外部取代取代模塊。這種方法稱為內(nèi)H.261[9]依賴于“有條件的補充”，而不是運動補償來降低比特率。在有條件的補充中，視頻圖像被分割成小模塊，只有塊的變化被傳送。Transcodervq|EncoderITranscodervq|EncoderI圖3轉(zhuǎn)換機的基本設(shè)計。任何支持的輸入格式都轉(zhuǎn)換成任何支持的輸出格式。中間階段指由T執(zhí)行一個轉(zhuǎn)化在內(nèi)部代理時，在必要時，為了匹配解碼器和編碼器的協(xié)議。除了在格式轉(zhuǎn)換時任何固有的帶寬減少，輸出率可以從輸入幀的到達(dá)，控制的解耦產(chǎn)生輸出幀。內(nèi)H.261通過使用H.261宏模塊尋址略過未補充的模塊而進(jìn)行有條件補充。由于一個內(nèi)部-H.261編碼從未使用模式塊，它不需要進(jìn)行運動補償，這大大降低了運行時的復(fù)雜性。此外，我們可以很容易地建立一個編碼器，負(fù)責(zé)DCTs變換而不是像素作為輸入。這樣，編碼器復(fù)雜度進(jìn)一步降低，因為它不必計算DCTs。此屬性是利用其數(shù)據(jù)流路徑的優(yōu)化，在下一節(jié)中詳細(xì)講敘。4.2.1數(shù)據(jù)流優(yōu)化Figure4:Figure4:AgeneiicJPEGH.261transcodei.圖4顯示了一種JPEG/H.261轉(zhuǎn)換器的通用執(zhí)行的基本數(shù)據(jù)流向。轉(zhuǎn)換器的輸入是一個JPEG編碼幀流。每幀解碼到像素，其中涉及熵解碼，逆向量化和反向變換。一旦在像素域，幀是H.261編碼器的輸入，它在每個模塊上執(zhí)行運動補償和使用一種類似于JPEG格式的方法編碼剩余運動。這種分解是直截了當(dāng)?shù)膱?zhí)行，因為它可以通過連接現(xiàn)有的源代碼而簡單的實現(xiàn)。然而，因為了一個軟件實施，由此產(chǎn)生的結(jié)果是不能令人滿意的。我們嘗試用此精確的配置較好調(diào)整JPEG譯碼器和（內(nèi)）H.261編碼器從vic中。即使在一個快速工作站（SGI印第安納，133MHzMIPSR4600SC），在無經(jīng)驗轉(zhuǎn)換器的配置操作只在6-13f/s的范圍內(nèi)操作，遠(yuǎn)低于實時性能。JPEGH.261Figure5:AnoptunizedJPEG.H.261tratiscodei.JPEGH.261Figure5:AnoptunizedJPEG.H.261tratiscodei.在轉(zhuǎn)換器中兩個主要瓶頸是DCT運算和操作非壓縮圖像導(dǎo)致的存儲量流量增大。減少或消除這些瓶頸，將大大改善轉(zhuǎn)換器性能。通過在DCT域開展有條件增資和通過利用一個內(nèi)部的H.261協(xié)議，它將DCTs作為輸入，我們可以做的就是這個。圖5顯示的是修改的數(shù)據(jù)流過程。這里逆量化的JPEG輸出被重定向到H.261量化器的輸入，從而繞過兩個變換計算。而且，由于有條件增資在DCT域中實現(xiàn)，我們可以去除內(nèi)存流量的大部分，通過更早的決定模塊是否被忽略。隨著我們修改數(shù)據(jù)路徑有兩個并發(fā)癥：分辨率轉(zhuǎn)換和色度抽樣。分辨率轉(zhuǎn)換JPEG是最典型的以PAL或NTSC格式發(fā)送的，而H.261是CIF（或1/4-CIF）的解決方案。相比于采用一個昂貴的大規(guī)模的操作，我們只是抽樣輸入（如有必要）來近似匹配CIF或1/4-CIF方案。然后，為了NTSC，幀被嵌入在一個CIF幾何方案中，使用灰色邊界，對于PAL制式，幀的垂直邊界上的一些像素被修剪掉。色度抽樣由于大多數(shù)基于硬件的JPEG編解碼器只支持4:2:2YUV損失的視頻，當(dāng)H.261要求4：2：1損失視頻，我們必須通過二次垂直的抽樣JPEG色度位面。這在像素區(qū)域里是微小的：簡單的丟棄其他的像素（在低通濾波以避免混淆后）。一個蠻力計算方法是計算兩個垂直臨近模塊的翻轉(zhuǎn)8x8二維DCT變換，從16x8模塊中產(chǎn)生一個8x8的模塊，并提出轉(zhuǎn)換這個8x8塊。然而，這使我們的快速路徑優(yōu)化失敗，依靠避免DCT的計算。原來認(rèn)為像素二次抽樣可以進(jìn)行直接通過操作DCT系數(shù)來實現(xiàn)。由于二維DCT的是可分變換，我們只需要考慮一維抽樣問題，也就是說，我們可以獨立的再二維DCT的每一列上操作。附錄載有派生的（近似）算法用來一個16信號的計算，采用直接操作兩半的16個點的信號的兩個8點DCT系數(shù)。輸出是一個二次抽樣信號的8點DCT變換。通過運行該算法的每列的兩個相鄰的垂直的8x8DCT，我們有效地對底層信號進(jìn)行二次抽樣。雖然我們的算法只是近似，但它的速度快，而且產(chǎn)生高質(zhì)量的結(jié)果。4.3解決一些缺點通常提到轉(zhuǎn)換系統(tǒng)的兩個弱點是加強的端到端延遲和加密的不相容。增加的延遲是被招致的，例如，當(dāng)編碼JPEG壓縮到MPEG（以B幀），因為編碼器必須在產(chǎn)生新的輸出之前收集幾個幀以成“組圖片”。然而，對于常用于互聯(lián)網(wǎng)的壓縮格式，這不是一個問題?；谟袟l件補充的數(shù)據(jù)包格式是故意設(shè)計的，以使每個數(shù)據(jù)包可以獨立處理獨其他的。因此，理論轉(zhuǎn)換延遲是零（模加工，存儲和轉(zhuǎn)發(fā)延遲），因為我們可以在到達(dá)時盡快轉(zhuǎn)換每個數(shù)據(jù)包。事實上，我們JPEG/H.261編碼器會等待直到整個JPEG幀到達(dá)。由于交通通常從源頭上被平滑，我們引起一幀間隔的延時。另一方面，如果JPEG數(shù)據(jù)包按次序到達(dá)，他們能夠進(jìn)行遞增解碼和逐步“對飛”輸出數(shù)據(jù)包。其他的問題相對于編碼系統(tǒng)是他們的加密時不相容性。這種說法是基于認(rèn)為，轉(zhuǎn)換代理將被納入網(wǎng)絡(luò)架構(gòu)，其隱私將通過委托網(wǎng)絡(luò)的加密密鑰受到損害的。然而，在我們的模型中，轉(zhuǎn)換器是一個應(yīng)用層級用戶部署的代理。因此，用戶能夠通過會話密鑰以一個安全的方式配置轉(zhuǎn)換器。5?執(zhí)行我們實施我們的網(wǎng)關(guān)和轉(zhuǎn)換器架構(gòu)以一個稱為vgw的原型架構(gòu)。我們充分利用了基于vic的靈活的代碼，通過整合vic的H.261編碼器，JPEG譯碼和納入vgw網(wǎng)絡(luò)的執(zhí)行工作。雖然我們最終的目標(biāo)是以高效率的轉(zhuǎn)換操作支持的幾個組合體，目前的功能只支持在上一節(jié)描述的JPEG/H.261轉(zhuǎn)換模型。不符合JPEG格式的流（或不打算轉(zhuǎn)換）只是簡單的通過網(wǎng)關(guān)轉(zhuǎn)發(fā)。JPEG/H.261轉(zhuǎn)換器通過修改vic的H.261編碼器和JPEG解碼器，以支持基于調(diào)用接口的DCT，我們將能夠很容易地實施在上一節(jié)中描敘的轉(zhuǎn)換器架構(gòu)。JPEG解碼器執(zhí)行DCT變換系數(shù)的表驅(qū)動Huffman解碼與有條件的補充。我們通過Huffman解碼前六個月的DCT系數(shù)來優(yōu)化補充模塊并通過比較看出那些已經(jīng)被傳送了，就像在文獻(xiàn)［9］中描敘的。如果他們是“類似不夠”，我們通過剖析剩下的系數(shù)塊跳過當(dāng)前塊，沒有任何額外的處理。因此，在這種情況下，如果沒有什么運動的場景，該系統(tǒng)就運行在Huffman的解碼速度（這只是使用表查詢）。一個DCT系數(shù)的幀緩沖區(qū)是通過解碼器來保持的，它可以用來作為有條件補充決定的參考。當(dāng)解碼器遇到的補充模塊時，它取代了相應(yīng)區(qū)塊的參考框架，并在位矢量上確立了一個特征位，來指示這個模塊已經(jīng)發(fā)生了變化。在整個幀解碼后，位矢量和DCT幀緩沖區(qū)被傳遞給H.261編碼器。編碼器然后對每個H.261宏塊包含改變塊編碼，通過使用一個索引表聯(lián)系H.261宏塊和“組塊”地址到NTSC塊號碼。編碼器以宏塊處理跳過了補充模塊。為了保證模塊如果丟失后最終補充（或者，如果一個接收器連接一個轉(zhuǎn)換器），一個更新過程促使每幀的一些額外的背景模塊的傳送。除了執(zhí)行有條件補充，H.261編碼器等分使用標(biāo)量量化的系數(shù)。因為DCT系數(shù)的整個動態(tài)范圍不是根本不可能實現(xiàn)的對于小的編碼器，我們的動態(tài)調(diào)整每個宏模塊的轉(zhuǎn)換器，以保證模塊中最大DCT變換系數(shù)是可以代表的。最后，在色度平板編碼前，它必須是如上所述二次抽樣。這個子樣品通過在附錄中使用編碼實現(xiàn)，DCT幀緩沖區(qū)中的兩個模塊轉(zhuǎn)成一個單一的DCT幀，存儲在一個緩沖區(qū)里。這個臨時的結(jié)果然后像往常一樣進(jìn)行編碼。速率控制器一個網(wǎng)關(guān)的基本功能是通過轉(zhuǎn)換數(shù)據(jù)包流調(diào)節(jié)輸出帶寬的。由于我們的編解碼器的實現(xiàn)事使用固定數(shù)字轉(zhuǎn)換器，我們不能依靠自適應(yīng)量化微調(diào)輸出比特率。相反，我們產(chǎn)生可變幀率輸出，在必要時從輸入流中放棄幀，以滿足某一特定率的制約因素。大多數(shù)壓縮方案是固定的，這意味著我們必須不斷的解碼輸入流到一個中間幀緩沖區(qū)中，然后以低速重新編碼。另一方面，與像運動的JPEG不固定格式，我們可以解碼唯一的幀，我們在輸入中能發(fā)送和丟棄其他的幀，從而節(jié)省計算時間。舉例來說，我們假設(shè)，我們要測試以較低的費率一個H.261流（即從H.261轉(zhuǎn)換為H.261）。我們可以通過應(yīng)用兩種方法一種更積極的量化器（為了交換比特率質(zhì)量）和一種輸出幀速率控制（為了微調(diào)產(chǎn)生的速率）。由于H.261是塊導(dǎo)向，我們可以通過編碼所有的模塊合并一些輸入幀成一個單一的輸出幀，因此，改變了自上次輸出幀。因此，輸出的幀速率是獨立于輸入幀速率的，隨著如下描敘的流量整形機制，我們才能實現(xiàn)所需要的帶寬限制。我們通過調(diào)整幀的倍數(shù)實施變幀率方案。當(dāng)從某一源的一個幀被發(fā)送是，下一幀的時間是遠(yuǎn)遠(yuǎn)不夠進(jìn)一步選擇的將來的幀以至于所產(chǎn)生的比特率符合分配給該來源的速率。然而，預(yù)定輸出幀的時間將不完全符合一個新的輸入幀的到來。但是,如果我們包括了預(yù)定時間和在計算比特位的實際時間的差距時間，然后由此產(chǎn)生的輸出率將將完全匹配的目標(biāo)速率。此外，速率控制器執(zhí)行流量平滑在整個幀時間里通過匹配一個單一幀的數(shù)據(jù)包。由于網(wǎng)關(guān)支持任意數(shù)量的活動視頻源，我們必須擴大我們的速率控制算法來操縱多源。我們這樣做最直截了當(dāng)?shù)目赡艿姆绞?速率控制器的一個單獨的實例是運行的每個活動源像那些個體的總和，速率被配置的會議帶寬所控制。分配給每個源的帶寬的分?jǐn)?shù)是動態(tài)指定的，通過一個外部會議協(xié)調(diào)協(xié)議。如果沒有分配被明確指定，帶寬將在一切活動源中平分。6?性能我們衡量vgw的性能，是通過在一個SGIIndy（133MHz的MIPS的R4600SC）運行IRIX5.3。JPEG量化表的生成是以一個30的輸入值使用單獨的JPEG組的公式，而且H.261量化器被設(shè)置為10。為了一個低運動情況，JPEG/內(nèi)部-H.261轉(zhuǎn)換器使用大約60%的CPU，而以30%處理30f/s的1/4-NTSC。對于一個非常高的運動情況，性能下降到15f/s。我們還比較了優(yōu)化的相對性能和蠻力數(shù)據(jù)路徑在4.2節(jié)中已經(jīng)在敘述。最優(yōu)化解釋了在運行時參數(shù)時，三個改進(jìn)中的一個因素，其中在低和高運動情況：morion日 fast-pathlowhigh12.9fs 33.3fs6.9f's 214f57?進(jìn)一步的工作目前，視頻網(wǎng)關(guān)只支持JPEG格式轉(zhuǎn)換為H.261。我們打算執(zhí)行另外的格式，包括為加州大學(xué)伯克利分校［1］的InfoPad項目的矢量量化方案制訂。為了非轉(zhuǎn)換代碼流，速度控制器采用了僅有的包速率，而不是幀速率。這導(dǎo)致質(zhì)量下降，因為數(shù)據(jù)包在通過比特流時隨機丟棄。一個更有效的模型是為了通過控制幀速率調(diào)整帶寬。換句話說，在輸出上放置一個速率限制器要求轉(zhuǎn)換所有的輸入流。因此，我們需要制定支持相同格式之間轉(zhuǎn)換。特別是，如果我們支H.261和NV壓縮算法vgw將更加有用，這將在互聯(lián)網(wǎng)中廣泛使用。對于視頻網(wǎng)關(guān)的外部控制接口尚未得到執(zhí)行。我們計劃實現(xiàn)它，在文獻(xiàn)［9沖以“會議總線”抽象描述。會議總線為實時多媒體應(yīng)用提供了一個高級別協(xié)調(diào)協(xié)議。簡單的控制腳本可以很容易地實現(xiàn)通過使用一個TCL［11］接口會議總線。通過這種方式，用戶可以為不可預(yù)見的應(yīng)用輕松地配置網(wǎng)關(guān)。例如，一個腳本可以配置和動態(tài)控制網(wǎng)關(guān)在會議的與會者中切換。8.摘要我們已經(jīng)提出了一個應(yīng)用級網(wǎng)關(guān)，為了適應(yīng)分組視頻到多種多樣的環(huán)境中傳輸。通過兼容一個RTP協(xié)議框架，我們的視頻網(wǎng)關(guān)立即成為一個現(xiàn)有應(yīng)用的不可分割的組成部分和互聯(lián)網(wǎng)的網(wǎng)絡(luò)基礎(chǔ)設(shè)施。我們已經(jīng)推出了一個靈活的架構(gòu)可以轉(zhuǎn)換多種視頻格式。特別是，我們已經(jīng)制定和實施一個有效的算法為Motion-JPEG到內(nèi)部H.261的實時轉(zhuǎn)換。最后，我們已經(jīng)成功地部署該系統(tǒng)在生產(chǎn)環(huán)境中，高帶寬的研討會由BAGNet被橋接的MBone。9致謝我們感謝RahulGarg,DeanaGoldsmith和Razavi,他們?yōu)檫@片論文的初稿提供了有益的意見。我們的架構(gòu)起源于在LBLMbone會議工具中的設(shè)計的框架，和VanJacobson開發(fā)。Van提供了有建設(shè)性的意見為我們的網(wǎng)關(guān)方案。最后，我們感謝VanJacobson，HenningSchulzrinne,RonFrederick,和VanJacobson，因為在1994年11月的電子郵件交流，影響我們的設(shè)計決定和澄清了RTP協(xié)議規(guī)范。附錄本附錄介紹了一個有效的算法（近似的）為抽樣信號直接操作轉(zhuǎn)換信號的DCT系數(shù)。我們使用矩陣分解就像在［8］。而不是單純的因式分解矩陣，為減少許多的成倍操作，我們使用近似乘數(shù)，以減少他們的不動點的變化和增加。讓x1和x2作為兩個8點信號（代表作為列向量），X1和X2作為他們的DCTs。讓x表示從（x1x2）t抽樣后的信號。我們的問題然后是計算X，x的DCT變換，讓G作為一個16*8的抽樣矩陣，「_J1a隨后，我們會表達(dá)像素低抽樣運算作為DCT系數(shù)的一個運算：為避免混淆，我們讓x1和x2通過低通濾波器。讓h（n）作為我們的反混淆濾波器，而且H是它的列向量DCT。我們將H=（1,1,1,1,0,0,0,0）t作為一個非常簡單的低通濾波器。然后，通過DCT卷積性質(zhì)，我們能乘Xk和H，為了（近似的）有卷積h（n）和xk的效果。我們能寫出H作為如下一個操作矩陣F：■■/.| 0 00 0 00 0 /.IU 0 0其中14是4*4特征，且0是一個4*4的零矩陣，現(xiàn)在，我們得出■=[T汕—住]|然后有 l-ji這一結(jié)果表明，我們可以計算損失信號的DCT,作為輸入信號DCTs的的一個線性組合。線性方程組是由M決定的，它比較容易通過在圖6顯示的程序計算出來。然而，在8x8二維矩陣該算法的直接執(zhí)行將需要成倍增加，這是在復(fù)雜性比蠻力方法更高的使用正向和反向DCTs。幸運的是，M的許多值是0,通過使用近似算子計算其執(zhí)行速度是非?？?。在RISC處理器，每個8角信號可以加載到寄存器，每個輸出點以少量的變化和增加計算。對這個方案的代碼，生產(chǎn)良好的定性結(jié)果,在圖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