用于對通信信道的帶寬限制進行補償的視頻壓縮系統及方法

專利名稱：用于對通信信道的帶寬限制進行補償的視頻壓縮系統及方法
技術領域：
本公開總體上涉及改善用戶操作及存取音頻和視頻媒體的能力的數據處理系統 的領域。
背景技術：
自從托馬斯·愛迪生(Thomas Edison)時代以來，記錄的音頻及電影媒體已成為 社會的一方面。在20世紀初期，記錄的音頻媒體(磁柱及唱片)及電影媒體(投幣式自動 點唱機及電影)廣泛發行，但兩種技術仍處于其起步階段。在20世紀20年代后期，在大 眾市場的基礎上將電影與音頻組合，之后將彩色電影與音頻組合。無線電廣播逐漸演變成 很大程度上支持廣告的形式的廣播大眾市場音頻媒體。當在20世紀40年代中期建立電視 (TV)廣播標準時，電視與無線電以廣播大眾市場媒體的形式接合，從而將先前記錄的或現 場直播的電影帶入家庭中。至20世紀中期為止，大部分美國家庭已具有用于播放記錄的音頻媒體的唱片播 放器(phonograph record player)、用于接收現場直播的廣播音頻的無線電設備，及用于 播放現場直播的廣播音頻/視頻(A/V)媒體的電視機。常常將所述3個“媒體播放器”(唱 片播放器、無線電設備及TV)組合到共有公共揚聲器的櫥柜中，變成家庭的“媒體中心”。盡 管對于消費者而言媒體選擇有限，但媒體“生態系統”非常穩定。大多數消費者知道如何使 用“媒體播放器”且能夠享受其能力的全部范圍。同時，媒體的出版商(大多為電影和電視 工作室，及音樂公司)能夠將其媒體分配給電影院與家庭兩者，而不遭受廣泛的盜版或“二 次銷售”(也即，已使用媒體的重新銷售)。通常，出版商不會從二次銷售得到收入，且因此， 二次銷售減少了出版商對于新的銷售從原本可自己使用媒體的購買者得到的收入。盡管在 20世紀中期期間的確存有已使用的唱片出售，但所述銷售不會對唱片出版商有大影響，因 為不同于電影或視頻節目(其通常被成年人觀看一次或僅數次)，音樂曲目可被收聽數百 次或甚至數千次。因此，音樂媒體遠比電影/視頻媒體“經久”(也即，對于成年消費者而 言，其具有持久價值)。一旦購買了唱片，若消費者喜歡該音樂，則消費者可能將其保持很長 時間。自20世紀中期到現在，媒體生態系統對于消費者與出版商的利益及損失來說都 經歷了一系列根本改變。在音頻錄音機(尤其是具有高質量立體聲的盒式磁帶)的廣泛 引入的情況下，的確有較高程度的消費者便利。但其也標志著現在廣泛的消費者媒體實 踐_盜版的開始。的確，許多消費者純粹出于便利起見而使用盒式磁帶來錄制其自己的唱
3片，但日益增加的消費者(例如，宿舍中準備存取彼此的唱片收集的學生)將進行盜版復 制。而且，消費者將錄制經由無線電播放的音樂，而非從出版商購買唱片或磁帶。消費者VCR的出現導致更多的消費者便利，因為現在VCR被設置為記錄TV節目， 其可在稍后時間觀看，且VCR也導致視頻租賃業的建立，其中電影以及TV節目設計可在“點 播”基礎上進行存取。自20世紀80年代中期以來的大眾市場家庭媒體設備的快速開發已 導致消費者的空前的選擇及便利程度，且也導致媒體出版市場的快速擴張。現今，消費者面對過多媒體選擇以及過多媒體設備，其中許多被綁定到特定形式 的媒體或特定出版商。熱衷的媒體消費者可能將一堆設備連接到房屋各房間中的TV及計 算機，造成至一或多個電視機和/或個人計算機(PC)的“鼠窩式”電纜以及一群遠程控制。 (在本申請的上下文中，術語“個人計算機”或“PC”指代適合于在家庭或辦公室中使用的任 何種類的計算機)，包括臺式計算機、Macintosh麥金托什機器) 或其他非Windows (視 窗)計算機、與Windows相容的設備、Unix變體、筆記本計算機等)。所述設備可包括視頻 游戲控制臺、VCR、DVD播放器、音頻環繞音效處理器/放大器、衛星機頂盒、電纜TV機頂盒 等。此外，對于熱衷的消費者，可能由于相容性問題而存在多個類似功能的設備。舉例而言， 消費者可能擁有HD-DVD與藍光(Blu-ray) DVD播放器兩者，或Microsoft Xbox (微軟家用 游戲機)⑧與Sony Playstation(索尼游戲站) 視頻游戲系統兩者。實際上，由于一些 跨游戲控制臺版本的的游戲的不相容性，消費者可能擁有XBox與稍后的版本(諸如，Xbox 360 )兩者。經常地，消費者對于使用哪個視頻輸入端及哪個遠端感到迷惑。甚至在將光 碟置放于正確的播放器(例如，DVD、HD_DVD、藍光、Xbox或Playstation)中、選擇用于該設 備的視頻及音頻輸入端且發現正確遠程控制之后，消費者仍面臨技術挑戰。舉例而言，在寬 屏DVD的狀況下，用戶可能需要首先確定正確的縱橫比(例如，4 3、完全、放大、寬放大、 電影院寬等)且接著在其TV或監視器屏幕上設定正確的縱橫比。類似地，用戶可能需要首 先確定正確的音頻環繞音效系統格式(例如，AC-3、杜比數字、DTS等)且接著設定正確的 音頻環繞音效系統格式。時常，消費者未意識到其可能未享受到其電視或音頻系統的全部 能力下的媒體內容(例如，觀看以錯誤縱橫比擠壓的電影，或收聽立體聲的音頻而非環繞 音效的音頻)。日益增加地，已將以基于互聯網的媒體設備添加到設備的堆棧中。類似Sonos (索 羅斯) 數字音樂系統的音頻設備使音頻直接從互聯網流動(stream)。同樣地，類似 Slingbox (視靈寶 )娛樂播放器的設備記錄視頻且使其經由家庭網絡流動或經由互聯網 流動而出，其中可在PC上遠程觀看該視頻。且互聯網協議電視(IPTV)服務經由數字用戶 線(DSL)或其他家庭互聯網連接而提供類似電纜TV的服務。近來還努力將多個媒體功能 整合到單個設備(諸如，Moxi (摩西)⑧媒體中心及執行Windows XP媒體中心版本的PC) 中。盡管所述設備中的每個設備對其執行的功能提供一點便利，但每個設備缺乏對大多數 媒體的普遍且簡單的存取。另外，常常由于昂貴的處理和/或本地儲存的需要而使得所述 設備經常花費數百美元來制造。另外，所述現代的消費者電子設備通常消耗大量電力，甚至 當閑置時也消耗大量電力，這意謂著其隨著時間而更加昂貴且浪費能源。舉例而言，若消費 者忘記將設備切斷或將其切換到不同視頻輸入端，則該設備可能繼續操作。此外，因為所述 設備當中沒有一個設備為完全的解決方案，所以必須將其與家庭中的其他設備的堆棧整合 在一起，這仍對用戶留下鼠窩式線及許多遠程控制。
4
此外，當許多較新的以互聯網為基礎的設備適當地工作時，其通常提供更一般形 式(與其原本可能可用的形式相比)的媒體。舉例而言，使視頻經由互聯網流動的設備常 常僅使視頻材料流動，而不能使常常伴隨DVD的互動式“額外項目”流動，如視頻的“制作”、 游戲或導演評論。這是由于以下事實互動式材料經常是以特定格式制作，該特定格式意 欲用于在本地處理互動性的特定設備。舉例而言，DVD、HD-DVD及藍光光碟中每一者具有其 自身的特定互動格式。任何家庭媒體設備或本地計算機(其可能經開發以支持所有流行格 式)將需要一定程度的尖端性(sophistication)及靈活性，其將可能對于消費者操作而言 過于昂貴及復雜。使該問題加重，若稍后在將來引入新格式，則本地設備可能不具有支持新格式的 硬件能力，這將意味著消費者將必須購買升級的本地媒體設備。舉例而言，若在稍后的日期 引入較高分辨率的視頻或立體視頻(例如，每一只眼一個視頻流)，則本地設備可能不具有 解碼該視頻的計算能力，或其可能不具有用于以新格式輸出該視頻的硬件(例如，假定通 過與遮光眼鏡(shuttered glassess)同步的120fps視頻來實現立體視覺，其中將60fps 傳送到每一只眼，若消費者的視頻硬件僅可支持60fps視頻，則該選項在缺乏升級的硬件 購買的情況下將不可用)。當談及尖端的互動式媒體(尤其是視頻游戲)時，媒體設備廢棄及復雜度的問題 為嚴重問題。現代視頻游戲應用基本上劃分成四個主要非便攜式式硬件平臺 SonyPlayStation 1、2 及 3(PS1、PS2,及 PS3) ；Microsoft Xbox 及 Xbox 360 ；及 Nintendo Gamecube (任天堂方糖)⑧及Wi i ；以及以PC為基礎的游戲。所述平臺中的每一 者不同于其他者，使得被編寫以在一個平臺上執行的游戲通常不會在另一平臺上執行。也 可能存在一代設備與下一代設備的相容性問題。即使大多數軟件游戲開發者建立獨立于特 定平臺而設計的軟件游戲，為了在特定平臺上執行特定游戲，也需要專有軟件層(其經常 被稱為“游戲開發引擎」”)來調適游戲以在特定平臺上使用。每一個平臺以“控制臺”(也 即，附接到TV或監視器/揚聲器的脫機盒(standalone box))的形式出售給消費者或其本 身為PC。通常，視頻游戲在諸如藍光DVD、DVD_R0M或⑶-ROM的光學媒體上出售，該光學媒 體含有體現為尖端的實時軟件應用程序的視頻游戲。隨著家庭寬帶速度增加，視頻游戲正 日益變得可用于下載。由于高級視頻游戲的實時性及高計算要求而使得實現與視頻游戲軟件的平臺相 容性的特殊性要求極端苛刻。舉例而言，一個人可能期望從一代視頻游戲到下一代視頻游 戲(例如，自 XBox 至 XBox 360，或自 Playstation 2(“PS2”)至 Playstation 3(“PS3”)) 的完全游戲相容性，正如存在從一個PC到具有較快處理單元或核心的另一 PC的生產力應 用程序(例如，MicrosoftWord(微軟文字處理軟件))的普遍相容性。然而，對于視頻游戲 并非是這種狀況。因為當發行一代視頻游戲時，視頻游戲制造商通常尋求對于給定價格點 的最高可能性能，所以經常對系統進行動態架構改變，以使得被編寫以用于前代系統的許 多游戲在稍后一代系統上不能工作。舉例而言，XBox基于x86系列處理器，而XBox 360基 于PowerPC系列。可利用技術來模仿先前架構，但假定視頻游戲為實時應用程序，則在模仿中達成 完全相同的行為常常不切實際。這是對消費者、視頻游戲控制臺制造商及視頻游戲軟件出
5版商的損失。對于消費者而言，這意味著將舊的一代視頻游戲控制臺與新的一代視頻游戲 控制臺兩者保持接通到TV以便能夠玩所有游戲的必要性。對于控制臺制造商而言，這意味 著與新控制臺的模仿及較慢采用相關的成本。且對于出版商而言，這意味著可能必須發行 新游戲的多個版本以便涵蓋所有潛在的消費者_不僅發行用于視頻游戲的每個商標(例 如，XBohPlaystation)的版本，而且常常發行用于給定商標的每個版本(例如，PS2及PS3) 的版本。舉例而言，開發藝電有限公司(Electronic Arts)的“瘋狂橄欖球08”的單獨版本 以用于XBox、XBox 360、PS2、PS3、Gamecube、Wii及PC平臺以及其他平臺。便攜式設備(諸如，移動電話及便攜式媒體播放器)也對游戲開發商提出挑戰。日 益增加地，所述設備連接到無線數據網絡且能夠下載視頻游戲。但是，市場中存在具有多種 不同顯示分辨率及計算能力的多種移動電話及媒體設備。而且，因為所述設備通常具有電 力消耗、成本及重量約束，所以其通常缺乏類似于圖形處理單元(“GPU”)的高級圖形加速 硬件(諸如，由美國加州的圣克拉拉的NVIDIA(英偉達公司)制造的設備)。因此，游戲軟 件開發商通常開發同時用于許多不同類型的便攜式設備的給定游戲標題。用戶可發現給 定游戲標題不可用于其特定移動電話或便攜式媒體播放器。在家庭游戲控制臺的狀況下，硬件平臺制造商通常向軟件游戲開發商收取用于在 其平臺上發布游戲的能力的版稅。移動電話無線通信公司通常也向游戲出版商收取用于將 游戲下載到移動電話中的版稅。在PC游戲的狀況下，不存在用于發布游戲所支付的版稅， 但由于用于支持多種PC配置及可能引起的安裝問題的較高消費者服務負擔而使得游戲開 發商通常面臨高成本。而且，PC通常較少阻礙游戲軟件的盜版，因為其可很容易地由精通 技術的用戶重新編程且游戲可更容易地被盜版且更容易地被分配(例如，經由互聯網)。因 此，對于軟件游戲開發商而言，在游戲控制臺、移動電話及PC上發行具有成本及不利之處。對于控制臺及PC軟件的游戲出版商而言，成本不止于此。為了經由零售通道分配 游戲，出版商向零售商收取低于出售價格的批發價格以使零售商具有利潤率。出版商通常 也必須支付制造及分配保存游戲的物理媒體的成本。零售商經常也向出版商收取“價格保 護費”以涵蓋可能的意外費用(諸如，游戲售不出，或游戲的價格降低，或零售商必須退還部 分或所有批發價格和/或從購買者收回游戲)。另外，零售商通常也向出版商收取用于幫助 在廣告傳單中銷售游戲的費用。此外，零售商日益增加地從已玩完游戲的用戶購買回游戲， 且接著將所述游戲以使用過的游戲出售，通常不與游戲出版商分享使用過的游戲的收入。 以下事實增加了施加給游戲出版商的成本負擔游戲常常被經由互聯網盜版及分配以供用 戶下載及進行免費復制。隨著互聯網寬帶速度增加且寬帶連接性在美國及全世界變得更廣泛(更具體地， 到家庭和到租賃連接互聯網的PC的“網吧”)，游戲被更多地經由下載而分配到PC或控制 臺。而且，寬帶連接更多地用于玩多人及大型多人在線游戲(該兩者在本公開中由首字母 縮寫詞“MM0G”來指代)。這些改變減輕了與零售分配相關的一些成本及問題。下載在線游 戲解決了游戲出版商的一些不利之處，因為分配成本通常較小且存在較少或不存在未出售 媒體的成本。但已下載的游戲仍被盜版，且由于其大小(大小常常為幾十億字節)而使得 其可能花費非常長的時間來下載。另外，多個游戲可裝滿小磁盤驅動器，例如連同便攜式計 算機一起或連同視頻游戲控制臺一起出售的那些磁盤驅動器。然而，就游戲或MMOG需要在 線連接以使得游戲可玩的程度而言，盜版問題得以減輕，因為通常需要用戶具有有效的用戶帳戶。不同于可由相機拍攝顯示屏幕的視頻或由麥克風記錄來自揚聲器的音頻來復制的 線性媒體(例如，視頻及音樂)，每個視頻游戲體驗是唯一的，且不可使用簡單的視頻/音 頻記錄來復制。因此，甚至在未強力執行版權法且盜版猖獗的區域中，也可保護MMOG免于 被盜版，從而可支持商業。舉例而言，已成功地部署Vivendi SA(維旺迪公司)的“魔獸世 界”MM0G，而在全世界未遭受盜版。且許多在線或MMOG游戲(諸如，Linden Lab (林登實驗 室)的“第二人生”MM0G)通過建在游戲中的經濟模型而產生游戲運營商的收入，其中資產 可使用在線工具而帶來、出售且甚至建立。因此，可使用除傳統游戲軟件購買或訂閱之外的 機制來為在線游戲的使用付費。盡管由于在線或MMOG的性質而使得常常可減輕盜版，但在線游戲運營商仍面臨 其余挑戰。許多游戲需要大量的本地(也即，家庭內)處理資源以供在線或MMOG適當地工 作。若用戶具有低性能的本地計算機(例如，不具有GPU的計算機，諸如低端筆記本計算 機)，則其可能不能夠玩該游戲。另外，隨著游戲控制臺老化，其遠落后于目前技術狀態且 可能不能夠處理更高級的游戲。即使假定用戶的本地PC能夠處理游戲的計算要求，常常也 存在安裝復雜度。可能存在驅動器不相容性(例如，若下載新游戲，則可能安裝新版本的圖 形驅動器，其致使依賴于舊版本圖形驅動器的先前已安裝的游戲不可操作)。隨著下載更 多游戲，控制臺可能用完本地磁盤空間。當發現缺陷并修復時或若對游戲進行了修改(例 如，若游戲開發商發現游戲的級別太難玩或太容易玩)，復雜游戲通常隨著時間推移而從游 戲開發商接收下載的補丁(patch)。該補丁需要新的下載。但有時并非所有用戶完成所有 補丁的下載。在其他時候，下載的補丁引入其他相容性或磁盤空間消耗問題。而且，在游戲播放期間，可能需要大數據下載以將圖形或行為信息提供到本地PC 或控制臺。舉例而言，若用戶進入MMOG中的一個房間中，且遇到由圖形數據組成或具有在 用戶的本地機器上不可用的行為的場景或人物，則必須下載那個場景或人物的數據。若互 聯網連接不夠快，則此可導致玩游戲期間的實質延遲。此外，若所遇到的場景或人物需要超 過本地PC或控制臺的儲存空間或計算能力的儲存空間或計算能力，則其可產生下述情形 其中用戶不能在游戲中繼續，或必須以質量降低的圖形繼續。因此，在線或MMOG游戲常常 限制其儲存和/或計算復雜度要求。另外，其常常限制游戲期間的數據傳送的量。在線或 MMOG游戲也可使可玩游戲的用戶的市場變窄。此外，精通技術的用戶越來越多地對游戲的本地復本進行反向工程且修改游戲以 使得他們可以作弊。作弊可能與進行比用人力可能的速度快的重復按鈕按壓(例如，為了 非常快速地射擊)一樣簡單。在支持游戲中資產交易的游戲中，作弊可達到導致欺騙性交 易涉及具有實際經濟價值的資產的欺詐程度。當在線或MMOG經濟模型基于所述資產交易 時，這可導致對游戲運營商的實質有害后果。開發新游戲的成本隨著PC及控制臺能夠制作越來越尖端的游戲(例如，具有更逼 真的圖形(諸如，實時光線追蹤)，及更逼真的行為(諸如，實時物理學仿真))而增長。在 視頻游戲業的早期，視頻游戲開發是應用程序軟件開發非常類似的過程；也即，大多數開發 成本在軟件的開發中(與圖形、音頻及行為要素或“資產”的開發相對比)，諸如可被開發以 用于具有廣泛特殊效果的電影的那些軟件開發。現今，許多尖端的視頻游戲開發成果比軟 件開發更類似于富有特效的電影開發。舉例而言，許多視頻游戲提供3-D世界的仿真，且產 生更加真實(也即，看似與攝影拍攝的實景(live action)圖像一樣逼真的計算機圖形)
7的人物、道具及環境。照片一樣逼真的游戲開發的最具挑戰方面中的一者為創建不能區別 于實景人臉的計算機產生的人臉。面部捕獲技術(諸如，由加州的圣弗朗西斯科的Mova開 發的Contour (輪廓 )真實性捕獲系統)捕獲表演者的面部的精確幾何形狀并在表演者 處于運動中時以高分辨率追蹤表演者的面部的精確幾何形狀。此技術允許在PC或游戲控 制臺上再現3D面部，該3D面部實際上不能區別于所捕獲的實景面部。精確地捕獲及再現 “照片一樣逼真的”人臉在多個方面是有用的。首先，高度可識別的名人或運動員常常用于 視頻游戲中(常常被高成本雇用)，且不完美性可能對于用戶而言顯而易見，從而使觀看體 驗(viewing experience)分心或令人不愉快。經常地，需要高度細節來實現高度的照片一 樣的逼真感_潛在地需要再現大量多邊形及高分辨率紋理(在多邊形和/或紋理在幀接幀 的基礎上隨著面部移動而改變的情況下)。當具有詳細紋理的高多邊形計數場景快速改變時，支持游戲的PC或游戲控制臺 可能不具有足夠的RAM來儲存用于游戲片段中所產生的所需數目的動畫幀的足夠多邊形 及紋理數據。另外，通常可用于PC或游戲控制臺上的單個光學驅動器或單個磁盤驅動器通 常比RAM緩慢得多，且通常不能跟上GPU在再現多邊形及紋理中可接受的最大數據速率。當 前游戲通常將大多數多邊形及紋理載入到RAM中，這意味著給定場景在復雜度及持續時間 上很大程度上受RAM的容量限制。在例如面部動畫制作的狀況下，這可能將PC或游戲控制 臺限制于并無真實感的低分辨率面部，或限制于僅可在游戲暫停且載入用于更多幀的多邊 形及紋理(及其他數據)之前在有限數目的幀中制作成動畫的真實感面部。當PC或控制臺顯示類似于“正在載入...”的消息時，觀看進程條跨屏幕緩慢地 移動被現今的復雜視頻游戲的用戶公認為是內在缺點。下一個場景從磁盤(除非另外有 條件，否則本文中的“磁盤”指非易失性光學媒體或磁性媒體，以及諸如半導體“閃存”存儲 器的非磁盤媒體)載入時的延遲可花費若干秒或甚至若干分鐘。這浪費時間且可能使游戲 玩家相當沮喪。如先前所述，大量或所有延遲可能是由于來自磁盤的多邊形、紋理或其他數 據的載入時間，但也可能是以下狀況當PC或控制臺中的處理器和/或GPU準備用于場景 的數據時，花費一部分載入時間。舉例而言，英式足球視頻游戲可允許玩家在大量玩家、小 組、運動場及天氣條件當中選擇。因此，取決于選擇什么特定組合，可能需要用于場景的不 同多邊形、紋理及其他數據(統稱“對象”)(例如，不同小組在其制服上具有不同色彩及圖 案)。可能要列舉各種排列中的許多或所有排列且提前預先計算對象中的許多或所有對象 并將對象儲存在用于儲存游戲的磁盤上。但是，若排列的數目很大，則所有對象所需的儲存 量可能過大以致不能安裝在磁盤上(或太不切實際以致不能下載)。因此，現有的PC及控 制臺系統通常在給定場景的復雜度與播放持續時間兩者上受約束且對于復雜場景遭受長 的載入時間。先前技術的視頻游戲系統及應用程序軟件系統的另一顯著限制在于其越來越多 地使用例如3D對象的大數據庫(諸如，多邊形及紋理)，所述大數據庫需要被載入到PC或 游戲控制臺中以用于處理。如上所述，當將所述數據庫在本地儲存于磁盤上時，所述數據庫 可花費長時間來載入。然而，若數據庫系儲存于遠程位置且經由互聯網來存取，則載入時間 通常嚴重得多。在此種情形下，下載大數據庫可能花費幾分鐘、幾小時或甚至幾天。另外， 所述數據庫常常產生大量費用(例如，用于游戲、電影或歷史記錄片中的詳細的高的有桅 帆船的3D模型)且意欲用于銷售給本地終端用戶。然而，一旦數據庫被下載至本地用戶，
8其就有被盜版的風險。在許多狀況下，用戶僅為了評估數據庫來觀看其是否適合用戶的需 要(例如，當用戶執行特定移動時，用于游戲人物的3D服裝是否具有滿意的外觀或外表) 的目的而希望下載數據庫。對于在決定進行購買之前評估3D數據庫的用戶而言，長載入時 間可能是阻礙。類似問題在MMOG (更具體地，如允許用戶利用更加定制化的人物的游戲)中出現。 對于顯示人物的PC或游戲控制臺，其需要能夠存取具有3D幾何形狀(多邊形、紋理等)以 及所述人物的行為(例如，若人物具有盾牌，則盾牌是否足夠強以使矛偏轉)的數據庫。通 常，當MMOG由用戶初次玩時，用于人物的大量數據庫在游戲的初始復本下已經可用，游戲 的初始復本在本地在游戲光盤上可用或被下載到磁盤。但是，隨著游戲進展，若用戶遇到數 據庫在本地不可用的人物或對象(例如，若另一用戶已建立一定制人物)，則在可顯示該人 物或對象之前，必須下載其數據庫。這可導致游戲的實質延遲。給定視頻游戲的尖端性及復雜度，則在先前技術視頻游戲控制臺情況下對視頻游 戲開發商及出版商的另一挑戰在于開發視頻游戲經常花費2年到3年，成本在數千萬美 元。假定新視頻游戲控制臺平臺以大致每隔五年一次的速率引入，則游戲開發商需要在新 游戲控制臺發行之前的數年開始那些游戲的開發工作，以便在發行新平臺時使視頻游戲同 時可用。來自競爭性制造商的若干個控制臺有時大約同時發行(例如，彼此在一年或兩年 內)，但尚待分曉的是每個控制臺的流行性(例如，哪個控制臺將產生最大的視頻游戲軟件 銷售)。舉例而言，在最近的控制臺周期中，Microsoft XBox 360、SonyPlaystation 3及 Nintendo Wii計劃在大約相同的大體時段引進。但在所述引進之前的數年中，游戲開發商 實質上必須“壓注(place bets)”哪些控制臺平臺將比其他者更成功，且相應地投入其開 發資源。電影制作公司也必須在電影發行之前很長時間基于其估計可能成功的電影而分 攤其有限的制作資源。給定視頻游戲所需的投資的增長程度，則游戲制作越加變得類似電 影制作，且游戲制作公司常規上基于其對特定視頻游戲的將來成功的估計而投入其制作資 源。但是，不同于電影公司，此壓注并非僅基于制作本身的成功；而是，其依據于游戲要在其 上執行的游戲控制臺的成功。同時在多個控制臺上發行游戲可減輕風險，但此額外努力增 加成本，且經常延遲游戲的實際發行。PC上的應用程序軟件及用戶環境正變得更為計算上密集、動態及互動，不僅使其 在視覺上更吸引用戶，而且使其更有用及直觀。舉例而言，新Windows Vista(視窗遠景) 操作系統與Macintosh 操作系統的后續版本兩者并入了視覺動畫效應。高級圖形工具 (諸如，來自Autodesk(歐特克)公司的Maya (瑪雅 ))提供非常尖端的3D再現及動畫 制作能力(其推動了目前技術狀態的CPU及GPU的限制)。然而，這些新工具的計算要求對 于所述產品的用戶及軟件開發商而言產生了許多實際問題。因為操作系統(OS)的視覺顯示必須在多種計算機(包括不再出售但仍可隨著新 OS而升級的前代計算機)上工作，OS圖形要求在很大程度上受OS要用于的計算機(其通 常包括不包括GPU的計算機)的最少共同點限制。這嚴重地限制OS的圖形能力。此外，電 池供電的便攜式計算機(例如，筆記本計算機)限制視覺顯示能力，因為CPU或GPU中的高 計算活動通常導致較高電力消耗及較短電池壽命。便攜式計算機通常包括在不利用處理 器時自動地減低處理器活動性以降低電力消耗的軟件。在一些計算機型號中，用戶可手動 地減低處理器活動性。舉例而言，Sony的VGN-SZ280P筆記本計算機包括在一側上標記為"Stamina (持久性)”(用于低性能，更長電池壽命)且另一側上標記為“Speed (速度)”(用 于高性能，較短電池壽命)的交換器。在便攜式計算機上執行的OS必須能夠即使在計算機 以其峰值性能能力的一小部分執行的情況下也可用地起作用。因此，OS圖形性能常常保持 為遠低于目前技術狀態的可用計算能力。經常出售高端的計算上密集的應用程序(如Maya)，期望所述應用程序將用于高 性能PC上。此通常產生高得多的性能，及更昂貴且便攜性較差、最少共同點的要求。因此， 所述應用程序具有比通用OS(或通用生產力應用程序，類似Microsoft Office)有限得多 的目標受眾且通常以比通用OS軟件或通用應用程序軟件低得多的量出售。潛在的受眾進 一步受限制，因為預期的用戶時常難以提前試用所述計算上密集的應用程序。舉例而言，假 設學生希望了解如何使用Maya或已經知道所述應用程序的潛在購買者在購買中希望在進 行投資之前試用Maya (此可能涉及也購買能夠執行Maya的高端計算機)。當學生或潛在購 買者可下載Maya的演示版本或得到Maya演示版本的物理媒體復本時，若其缺乏能夠執行 Maya的全部潛能(例如，處理復雜3D場景)的計算機，則其將不能夠進行產品的全方位評 估。此實質上限制所述高端應用程序的受眾。這也使出售價格變高，因為開發成本通常經 過比通用應用程序的購買次數小得多的購買次數而分攤。高價應用程序也對使用應用程序軟件的盜版復本的個體及商業產生更多刺激。因 此，高端應用程序軟件遭受猖獗盜版，盡管該軟件的出版商進行了大量努力來通過各種技 術減輕該盜版。但是，甚至當使用盜版的高端應用程序時，用戶也不可能排除投資昂貴的目 前技術狀態的PC來執行盜版復本的需要。因此，盡管用戶可以用軟件應用程序的實際零 售價格的一小部分獲得軟件應用程序的使用，但盜版軟件的用戶仍需要購買或獲得昂貴的 PC,以便完全利用該應用程序。此對于高性能盜版視頻游戲的用戶同樣成立。盡管盜版者可以用游戲的實際價格 的一小部分得到游戲，但其仍需要購買適當地玩游戲所需的昂貴計算硬件(例如，GPU-增 強型PC，或類似XBox 360的高端視頻游戲控制臺)。假定視頻游戲通常是消費者的娛樂， 則用于高端視頻游戲系統的額外成本可能是過于昂貴的。該情形在當前工人的平均年收入 相當低(相對于美國的當前工人平均年收入)的國家(例如，中國)中更糟。這樣，小得多 的百分比的人口擁有高端視頻游戲系統或高端PC。在這些國家中，用戶可支付費用以使用 連接到互聯網的計算機的“網吧”相當普遍。經常地，所述網吧具有不具有高性能特征(諸 如，原本可使玩家能夠玩計算上密集的視頻游戲的GPU)的較舊型號或低端PC。這是在低端 PC上執行的游戲成功的關鍵因素(諸如，Vivendi的“魔獸世界”，其在中國高度成功，且通 常是在中國的網吧中玩)。相比之下，計算上密集的游戲(如“第二人生”)更不可能在安 裝于中國網吧中的PC上玩。所述游戲實際上對于僅能夠存取網吧中的低性能PC的用戶來 說是不可訪問的。對于考慮購買視頻游戲且首先愿意通過經由互聯網將演示下載到其家庭而試用 游戲的示范版本的用戶也存在障礙。視頻游戲演示常常為游戲的全能版本，其中一些特征 停用，或對游戲播放的量施加限制。此可能涉及在可將游戲安裝于PC或控制臺上且在PC或 控制臺上執行之前下載數十億字節的數據的長過程(可能幾個小時)。在PC的狀況下，其 也可能涉及算出游戲需要哪些特殊驅動器(例如，DirectX或OpenGL驅動器)，下載正確的 版本，安裝正確的版本，及接著確定PC是否能夠播放該游戲。后者步驟可能涉及確定PC是否具有足夠的處理(CPU及GPU)能力、足夠的RAM及相容的OS (例如，一些游戲在Windows XP上執行而不在Vista上執行)。因此，在試圖執行視頻游戲演示的長過程之后，用戶可能 發現在給定用戶的PC配置的情況下視頻游戲演示不可能玩。更糟地，一旦用戶已下載新驅 動器以用于嘗試該演示，這些驅動器版本就可能與用戶在PC上習慣使用的其他游戲或應 用程序不相容，因此，演示的安裝可致使先前可操作的游戲或應用程序不能操作。這些障 礙不僅使用戶沮喪，而且其也對視頻游戲軟件出版商及視頻游戲開發商銷售其游戲產生障 礙。導致不具經濟效益的另一問題與以下事實有關給定PC或游戲控制臺通常被設 計以適應對應用程序和/或游戲的特定程度的性能要求。舉例而言，一些PC具有或多或少 的RAM、較慢或較快的CPU及較慢或較快的GPU (若其具有GPU)。一些游戲或應用程序利用 給定PC或控制臺的全計算能力，而一些游戲或應用程序卻不利用給定PC或控制臺的全計 算能力。若用戶的游戲或應用程序的選擇未達到本地PC或控制臺的峰值性能能力，則用戶 可能由于未利用的特征而在PC或控制臺上浪費了財力。在控制臺的狀況下，控制臺制造商 可能支付比資助控制臺成本所要的多的成本。存在于視頻游戲的銷售及享受中的另一問題涉及在用戶實施購買游戲之前允許 用戶觀看他人玩游戲。存在用于記錄視頻游戲以在稍后時間重放的若干先前技術方法。舉 例而言，美國專利第5，558，339號教導了在“游戲播放”期間將游戲狀態信息(包括游戲控 制器動作)記錄在視頻游戲客戶端計算機(由同一個或不同用戶擁有)中。此狀態信息可 在稍后時間使用以在視頻游戲客戶端計算機(例如，PC或控制臺)上重放一些或所有游戲 動作。該方法的顯著缺點在于對于觀看已記錄的游戲的用戶，用戶必須具有能夠播放該游 戲的視頻游戲客戶端計算機且必須具有在該計算機上執行的視頻游戲應用程序，以使得當 重放被記錄的游戲狀態時游戲播放是完全相同的。除此之外，視頻游戲應用程序必須是以 在被記錄的游戲與經回放的游戲之間不存在可能的執行差異的方式編寫。舉例而言，游戲圖形大體在幀接幀基礎上計算。對于許多游戲，取決于場景是否特 別復雜或是否存在減緩執行的其他延遲(例如，在PC上，另一過程可能正在執行，以致從游 戲應用程序奪走CPU周期)，游戲邏輯有時可能花費比一幀時間短或比一幀時間長的時間 來計算為下一個幀而顯示的圖形。在此種游戲中，以比一幀時間稍少的時間(例如，少幾個 CPU時鐘周期)計算的“臨限值”巾貞最終可出現。當使用完全相同的游戲狀態信息再次計算 該同一場景時，可能容易花費比一幀時間多幾個CPU時鐘周期的時間(例如，若內部CPU總 線稍微與外部DRAM總線不同相，且即使不存在來自從游戲處理奪走數毫秒CPU時間的另一 過程的大延遲，其也引入幾個CPU周期時間的延遲)。因此，當回放游戲時，幀變成以兩個 幀時間計算而非以單個幀時間計算。一些行為基于游戲計算新幀的頻率(例如，當游戲取 樣來自游戲控制器的輸入時)。當播放游戲時，用于不同行為的時間參考中的該偏差不會 影響游戲播放，但其可導致所回放的游戲產生不同結果。舉例而言，若籃球的軌道是以穩定 的60fps速率來計算，但游戲控制器輸入是基于計算的幀的速率來取樣，則當記錄游戲時， 計算的幀的速率可能為53fps，而當重放游戲時，計算的幀的速率可能為52fps，此可使得 籃球是否被阻止進入籃中存在差異，從而導致不同結果。因此，使用游戲狀態記錄視頻游戲 需要非常謹慎的游戲軟件設計，以確保使用同一游戲狀態信息重放產生完全相同的結果。用于記錄視頻游戲的另一先前技術方法是僅記錄PC或視頻游戲系統的視頻輸出
11(例如，到VCR、DVD記錄器，或到PC上的視頻捕獲板)。接著可將視頻回倒及重放，或替代 地，將記錄的視頻上傳到互聯網(通常在將視頻壓縮之后)。該方法的不利之處在于當回 放3D游戲序列時，用戶限于僅從觀看點(序列從該觀看點被記錄)來觀看序列。換言之， 用戶不可改變場景的觀看點。另外，當經由互聯網而使在家庭PC或游戲控制臺上播放的記錄的游戲序列的經 壓縮的視頻為其他用戶可用時，即使視頻是實時壓縮，也不可能實時地將經壓縮的視頻上 傳到互聯網。其原因是因為世界上連接到互聯網的許多家庭具有高度不對稱的寬帶連接 (例如，DSL及電纜調制解調器通常具有比上流帶寬高得多的下流帶寬)。被壓縮的高分辨 率視頻序列常常具有比網絡的上傳帶寬容量高的帶寬，使得其不可能實時上傳。因此，在播 放游戲序列之后(可能幾分鐘或甚至幾小時)，在互聯網上的另一用戶能夠觀看該游戲之 前，將存在顯著延遲。盡管該延遲在特定情形下(例如，觀看在先前時間出現的游戲玩家的 成果)可容忍，但其消除了觀看游戲現場直播(例如，由優勝玩家玩的籃球錦標賽)的能力 或現場直播地播放游戲時的“即刻重放”能力。另一先前技術方法允許具有電視接收器的觀看者觀看視頻游戲現場直播，但僅在 電視制作人員的控制下。美國與其他國家中的一些電視頻道提供視頻游戲觀看頻道，其中 電視觀眾能夠在視頻游戲頻道上觀看特定的視頻游戲用戶(例如，參加錦標賽煩人頂級玩 家)。這通過將視頻游戲系統(PC和/或控制臺)的視頻輸出饋送至用于電視頻道的視頻 分配及處理設備中來完成。這正如電視頻道廣播現場直播的籃球比賽時的情況，其中若干 個相機從籃球場周圍的不同角度提供現場直播的饋送。電視頻道接著能夠利用其視頻/音 頻處理及效應設備來操作來自各種視頻游戲系統的輸出。舉例而言，電視頻道可在來自視 頻游戲的視頻之上疊加指示不同玩家的狀態的文字(正如其可在現場直播的籃球比賽期 間疊加文字)，且電視頻道可加錄來自評論員(其可論述在比賽期間出現的動作)的音頻。 另外，可將視頻游戲輸出與記錄游戲的實際玩家的視頻的相機(例如，顯示玩家對游戲的 情緒反應)組合。該方法的一個問題在于必須實時地使所述現場直播的視頻饋送為電視頻道的視 頻分配及處理設備可用，以便使其具有現場直播的廣播的刺激性。然而，如先前所述，當視 頻游戲系統從家庭執行時(尤其是當廣播的一部分包括來自正捕獲游戲玩家的真實世界 視頻的相機的現場直播的視頻時)，這常常不可能。另外，在錦標賽情形下，所關注的是家庭 中游戲者可修改游戲及作弊，如先前所述。由于這些原因，電視頻道上的所述視頻游戲廣播 常常配置有聚集于公共位置處(例如，在電視演播室處或在競技場中)的播放器及視頻游 戲系統，其中電視制作設備可接受來自多個視頻游戲系統及潛在的現場直播的相機的視頻 饋送。盡管所述先前技術視頻游戲電視頻道可為電視觀眾提供非常刺激的演出(這是 與現場直播的運動事件同類(例如，與以“運動員”呈現的視頻游戲玩家同類)的體驗，不 僅根據其在視頻游戲世界中的動作，而且根據其在真實世界中的動作)，但這些視頻游戲系 統常常限于玩家彼此身體上極接近的情形。此外，因為電視頻道被廣播，所以每個被廣播的 頻道僅可顯示由電視頻道的制作人員選擇的一個視頻流。由于這些限制及廣播時間、制作 設備及制作人員的高成本，所述電視頻道通常僅顯示參加頂級錦標賽的頂級玩家。另外，向全部電視觀眾廣播視頻游戲的全屏幕圖像的給定電視頻道每次僅顯示一
12個視頻游戲。這嚴重地限制電視觀看者的選擇。舉例而言，電視觀看者可能對給定時間顯 示的游戲不感興趣。另一觀看者可能僅對觀看并非由電視頻道在給定時間放映的特定玩家 的游戲播放感興趣。在其他狀況下，觀看者可能僅對觀看內行玩家如何處理游戲中的特定 級別感興趣。其他觀看者可能希望控制觀看點(視頻游戲從該觀看點來看)，該觀看點不同 于由制作小組等選擇的觀看點。簡言之，電視觀看者在觀看視頻游戲中可能具有無數的偏 好(即使若干個不同電視頻道可用，電視網絡的特定廣播也不適應所述偏好)。由于所有上 述原因，使得先前技術視頻游戲電視頻道在向電視觀看者呈現視頻游戲中具有顯著限制。先前技術視頻游戲系統及應用程序軟件系統的另一缺點在于他們很復雜，且通 常遭受錯誤、崩潰和/或無意識且不需要的行為(統稱“缺陷”)。盡管游戲及應用程序在 發行之前通常經歷除錯及調諧過程(經常稱為“軟件質量保證”或SQA)，但幾乎不變的是 一旦游戲或應用程序被發行到領域中的廣大受眾，缺陷就會突然出現。遺憾的是，軟件開發 商難以在發行之后識別及追蹤到許多缺陷。軟件開發商可能難以意識到缺陷。即使當其了 解缺陷時，也可能僅存在其可用于識別是什么引起該缺陷的有限量的信息。舉例而言，用戶 可打電話給游戲開發商的消費者服務熱線且留下消息，該消息陳述當玩游戲時，屏幕開始 閃爍，接著變成固體藍(solid blue)且PC凍結。其為SQA小組提供了在追蹤缺陷中有用 的非常少的信息。在線連接的一些游戲或應用程序在特定狀況下有時可提供更多信息。舉 例而言，有時可使用”看門狗”過程來監視游戲或應用程序是否“崩潰”。看門狗過程可收 集游戲或應用程序崩潰時關于游戲或應用程序過程的狀態(例如，存儲器堆棧使用狀態、 游戲或應用程序進展到的程度等)的統計，且接著經由互聯網而將所述信息上傳至SQA小 組。但在復雜游戲或應用程序中，該信息可花費非常長的時間來解密，以便準確地確定在崩 潰時用戶正在進行什么。盡管如此，也不可能確定什么事件序列導致崩潰。與PC及游戲控制臺相關聯的又一問題在于其經受使消費者極不便利的服務問 題。服務問題也影響PC或游戲控制臺的制造商，因為其通常需要發送特殊盒子以安全地裝 運破損的PC或控制臺，且因而招致修理的成本(若PC或控制臺處于保修期內)。游戲或應 用程序軟件出版商也可受處于修理狀態中的PC和/或控制臺引起的銷售損失(或在線服 務使用)影響。圖 1 說明諸如 Sony Playstation 3、Microsoft Xbox 360 、NintendoWii 、以 Windows為基礎的個人計算機或Apple Macintosh的先前技術視頻游戲系統。所述系統中 的每一者包括用于執行程序碼的中央處理單元(CPU)(通常為用于執行高級圖形操作的圖 形處理單元(GPU))，及用于與外部設備及用戶通信的多個形式的輸入/輸出(1/0)。為簡 單起見，將所述組件顯示為組合在一起為單個單元100。圖1的先前技術視頻游戲系統也顯 示為包括光學媒體驅動器104 (例如，DVD-ROM驅動器)；用于儲存視頻游戲程序代碼及數據 的硬盤驅動器103 ；用于播放多人游戲、用于下載游戲、補丁、演示或其他媒體的網絡連接 105 ；用于儲存當前正由CPU/GPU 100執行的程序碼的隨機存取存儲器(RAM)IOl ；用于在游 戲播放期間接收來自用戶的輸入命令的游戲控制器106 ；及顯示設備102(例如，SDTV/HDTV 或計算機監視器)。圖1中所顯示的先前技術系統受到若干限制。首先，與RAM 101的存取速度相比 較，光學驅動器104及硬碟機103往往具有慢得多的存取速度。當直接通過RAM 101工作 時，由于RAM 101通常具有高得多的帶寬且不會受到磁盤機構相對長的搜尋延遲的事實，CPU/GPU 100在實踐中可處理比直接從硬盤驅動器103或光學驅動器104讀出程序代碼及 數據時可能的每秒多邊形數多得多的每秒多邊形數。但僅有限量的RAM提供于這些先前技 術系統中(例如，256-512兆字節)。因此，常常需要“正在載入...”序列，其中RAM 101被 周期性地填充有用于視頻游戲的下一個場景的數據。一些系統試圖同時地重迭程序代碼的載入與游戲播放，但這僅可在存在已知序列 的事件時進行(例如，若正沿道路駕駛車，則可在駕駛車的同時載入路旁的正接近的建筑 物的幾何形狀)。對于復雜和/或快速場景改變，此類型的重迭通常不起作用。舉例而言， 在用戶處于戰役進行之中且在那時刻的視圖內RAM 101完全被填滿表示對象的數據的狀 況下，若用戶將視圖快速地向左移動以觀看當前未載入在RAM 101中的對象，則將導致動 作的不連續性，因為不存在足夠的時間來將新對象自硬盤驅動器103或光學媒體104載入 到 RAM 101 中。圖1的系統的另一問題是由于硬盤驅動器103及光學媒體104的儲存容量的限制 引起。盡管磁盤儲存設備可被制造成有相對較大的儲存容量(例如，500億字節或500億字 節以上)，但其仍不提供用于在當前視頻游戲中所遇到的特定情況的足夠儲存容量。舉例而 言，如先前所述，英式足球視頻游戲可允許用戶在全世界的許多小組、玩家及運動場當中選 擇。對于每個小組、每個玩家及每個運動場，需要大量紋理映射及環境映射來特征化世界上 的3D表面(例如，每個小組具有唯一運動衫，每一者需要唯一紋理映射)。用于解決上述后者問題的一個技術是對于游戲，一旦用戶選擇了紋理及環境映 射，就預先計算紋理及環境映射。此可涉及許多計算上密集的過程，包括解壓縮圖像、3D映 射、加陰影、組織數據結構等。因此，當視頻游戲執行這些計算時，對于用戶可能存在延遲。 減少此延遲的一個方法原則上為最初開發游戲時執行所有這些計算_包括小組、玩家名 冊及運動場的每個排列。游戲的發行版本因而將包括儲存在光學媒體104上或互聯網上的 一個或多個服務器上的所有所述經預先處理的數據，當用戶作出選擇時，僅經由互聯網將 用于給定小組、玩家名冊、運動場選擇的選定的預先處理的數據下載到硬盤驅動器103。然 而，作為實際問題，游戲播放中可能的每個排列的該預先載入的數據可能輕易地為幾兆兆 字節(terabyte)的數據，其遠超過現今的光學媒體設備的容量。此外，用于給定小組、玩家 名冊、運動場選擇的數據可能輕易地為幾億字節的數據或幾億字節以上的數據。在家庭網 絡連接的情況下(例如，10Mbps)，經由網絡連接105下載該數據將比在本地計算數據花費 更長時間。因此，圖1中所顯示的先前技術游戲架構使用戶在復雜游戲的較大場景轉變之間 經受顯著延遲。諸如圖1中所顯示的先前技術方法的先前技術方法的另一問題在于這些年來， 視頻游戲傾向于變得更高級且需要更多CPU/GPU處理能力。因此，即使采用無限量的RAM， 視頻游戲硬件要求也超過所述系統中可用的處理能力的峰值水平。因此，需要用戶每隔幾 年升級游戲硬件以保持同步(或以較低質量水準玩較新游戲)。比以往更高級的視頻游戲 的趨勢的后果為用于家庭用途的玩視頻游戲的機器通常不具經濟效益，因為其成本通常 由其可支持的最高性能游戲的要求來確定。舉例而言，可能使用XBox 360來玩類似“戰爭 機器(Gears of War) ”的游戲，該游戲要求高性能的CPU、GPU及幾億字節的RAM，或者可能 使用XBox 360來玩“吃豆(Pac Man) ”，其為來自20世紀70年代的游戲，其僅需要幾千字
14節的RAM及非常低性能的CPU。實際上，XBox 360具有同時主機代管許多同時的“吃豆”游 戲的足夠計算能力。在一周的大多數小時中，通常關閉視頻游戲機。根據2006年7月Nielsen(尼爾 森)娛樂對13歲及13歲以上的活躍游戲者的研究，平均起來，活躍游戲者一周中花費十四 個小時或一周中的全部小時的僅12%來玩控制臺視頻游戲。這意味著平均視頻游戲控制臺 在88%的時間內閑置，這是昂貴資源的無效率使用。假定視頻游戲控制臺常常是由制造商 來資助以降低購買價格(期望該資助將通過來自未來視頻游戲軟件購買的版稅來賺回)， 則這特別有意義。視頻游戲控制臺也造成與幾乎任何消費者電子設備相關的成本。舉例而言，需要 將系統的電子設備及機構容納于外殼中。制造商需要提供服務保證。出售該系統的零售商 需要收取關于系統的銷售和/或關于視頻游戲軟件的銷售的利潤。所有這些因素添加視頻 游戲控制臺的成本，該成本必須由制造商來資助、傳遞至消費者，或者由制造商與消費者兩 者來資助。另外，盜版是視頻游戲工業的較大問題。實際上每個較大視頻游戲系統上所利用 的安全機構這些年來已“破裂”，導致視頻游戲的未經授權的復制。舉例而言，Xbox 360安 全系統在2006年7月破裂且用戶現在能夠在線下載非法復本。可下載的游戲(例如，用于 PC或Mac的游戲)特別容易經受盜版。在世界的特定區域(其中盜版管制不強)中，實質 上不存在獨立視頻游戲軟件的可行市場，因為用戶可與合法復本一般容易地以成本的非常 小一部分購買盜版復本。而且，在世界的許多地方，游戲控制臺的成本占收入的高百分比， 以致即使盜版受控制，也很少有人可買得起目前技術狀態的游戲系統。另外，已使用的游戲的市場減少了視頻游戲業的收入。當用戶變得對游戲厭倦時， 其可將游戲出售給將游戲轉售給其他用戶的店鋪。這種未經授權但普遍的實踐顯著減少 了游戲出版商的收入。類似地，當每隔幾年存在平臺轉變時，通常出現大約50%的銷售減 少。這是因為當用戶知道即將發行較新版本的平臺時，用戶停止購買用于較舊平臺的游戲 (例如，當即將發行Playstation 3時，用戶停止購買Playstation 2游戲)。組合起來，銷 售的損失及與新平臺相關的增加的開發成本可對游戲開發商的收益性有非常顯著的不利 影響。新游戲控制臺也非常昂貴。Xbox360、Nintendo Wii 及 Sony Playstation 3 均 以數百美元零售。高能力的個人計算機游戲系統可花費高達$8000。這表示用戶的顯著投 資，具體來說，考慮到硬件在幾年后變陳舊及許多系統是為孩子而購買的事實。上述問題的一個方法是在線游戲，其中將游戲程序代碼及數據主機代管于服務器 上且按要求將其傳送至客戶端機器，經壓縮的視頻及音頻經由數字寬帶網絡而流動。一些 公司(諸如，芬蘭的G-ClusteHG-群集公司)，其現在為日本的SOFTBANK Broadmedia(軟 銀寬媒)的子公司)當前在線提供所述服務。類似游戲服務變得在本地網絡(諸如，旅館 內及由DSL及電纜電視提供者提供的那些網絡)中可用。這些系統的較大缺點是延時的問 題，也即，信號行進到游戲服務器及從游戲服務器行進所花費的時間，游戲服務器通常定位 在運營商的“前端”中。快速動作視頻游戲(也稱為“極速(twitch)”視頻游戲)在用戶 通過游戲控制器執行動作的時間與更新顯示屏幕以顯示用戶動作的結果的時間之間需要 非常低的延時。需要低延時，以使得用戶感覺到游戲“即刻地”響應。可視游戲的類型及用戶的熟練程度而以不同延時間隔來滿足用戶。舉例而言，對于緩慢的非正式游戲(類似西 洋雙陸棋)或慢動作角色扮演游戲而言，100毫秒的延時可能是可容忍的，但在快動作游戲 中，超過70毫秒或80毫秒的延時可引起用戶在游戲中更拙劣地表現，且因此不可接受。舉 例而言，在需要快反應時間的游戲中，當延時自50毫秒增加至100毫秒時，存在準確度的銳 降。當游戲或應用服務器安裝在附近的受控網絡環境或至用戶的網絡路徑可預測和/ 或可容忍帶寬峰值的網絡環境中時，在最大延時以及延時的一致性方面，控制延時容易得 多(例如，因此用戶經由網絡觀察到來自數字視頻流動的穩定運動)。該程度的控制可在以 下達成在電纜TV網絡前端到電纜TV用戶的家庭之間，或自DSL中央辦公室至DSL用戶的 家庭，或在來自服務器或用戶的商業辦公室區域網絡(LAN)環境中。而且，有可能獲得商業 之間的具有得到保證的帶寬及延時的特定分級的點到點私用連接。但在將游戲主機代管于 連接到通用互聯網的服務器中心中且接著經由寬帶連接而使經壓縮的視頻流動(stream) 到用戶的游戲或應用系統中，許多因素造成延時，導致先前技術系統的部署中的嚴重限制。在典型的連接寬帶的家庭中，用戶可具有用于寬帶服務的DSL或電纜調制解調 器。所述寬帶服務通常造成用戶的家庭與通用互聯網之間的多達25毫秒的來回行程延時 (且有時更多)。另外，存在由于經由互聯網將數據路由到服務器中心而造成的來回行程延 時。經由互聯網的延時基于給出數據的路線及數據被路由時數據所造成的延遲而改變。除 路由延遲之外，還由于光穿過使大多數互聯網互連的光纖的速度而造成來回行程延時。舉 例而言，對于每1000英里，由于光穿過光纖的速度及其他耗用而造成約22毫秒的來回行程 延時。額外延時可由于經由互聯網流動的數據的數據速率而造成。舉例而言，若用戶具 有以“6Mbps DSL服務”出售的DSL服務，則在實踐中，用戶將很可能最多得到小于5Mbps 的下行輸送量，且將可能周期性地看見由于各種因素(諸如，峰值載入時間期間在數字用 戶線接入復用器(DSLAM)處的擁擠)產生的連接降級。若經由相鄰者循環的本地共用同軸 電纜中存在擁擠或電纜調制解調器系統網絡中的其他地方存在擁擠，則類似問題可出現， 從而將用于以“6Mbps電纜調制解調器服務”出售的連接的電纜調制解調器的數據速率減 小至遠小于該數據速率。若使4Mbps的穩定速率下的數據分組以用戶數據報協議(UDP)格 式單向地從服務器中心經由所述連接而流動，若一切都適當地工作，則數據分組將通過而 不造成額外延時，但若存在擁擠(或其他妨礙)且僅3. 5Mbps可用于使數據流動到用戶，則 在典型情形下，包將被丟棄，導致丟失數據，或者分組將在擁擠點處排隊直至它們可被發送 為止，從而引入了額外延時。不同擁擠點具有用于保存被延遲的分組的不同隊列容量，因此 在一些狀況下，立即將不可成功解決擁擠的分組丟棄。在其他狀況下，將幾百萬比特的數據 排隊且最終將其發送。但是，在幾乎所有狀況下，擁擠點處的排隊具有容量限制，且一旦超 過該限制，隊列將溢出且分組將被丟棄。因此，為了避免造成額外延時(或更糟地，分組丟 失)，必須避免超過從游戲或應用服務器到用戶的數據速率容量。還由于在服務器中壓縮視頻及在客戶端設備中解壓縮視頻所需的時間而造成延 時。當在服務器上執行的視頻游戲正在計算待顯示的下一個幀時，進一步造成延時。當前可 用的視頻壓縮算法受到高數據速率或高延時。舉例而言，運動JPEG為僅幀內有損的壓縮算 法，該壓縮算法特征為低延時。視頻的每個幀獨立于視頻的每個其他幀而壓縮。當客戶端設備接收經壓縮的運動JPEG視頻的一個幀時，其可立即解壓縮該幀且顯示該幀，從而導致 非常低的延時。但因為每個幀分開進行壓縮，所以算法不能夠利用連續幀之間的類似性，且 因此僅幀內視頻壓縮算法受到非常高的數據速率。舉例而言，60fps (每秒幀數)640X480 運動JPEG視頻可能需要40Mbps (每秒百萬比特)或40Mbps (每秒百萬比特)以上的數據。 用于所述低分辨率視頻窗的所述高數據速率在許多寬帶應用程序中將是過于昂貴的(且 對于大多數消費者的基于互聯網的應用程序的確如此)。另外，因為每個幀經獨立壓縮，所 以可能由于有損壓縮而產生的幀中的假影可能出現于連續幀中的不同位置處。這可導致當 解壓縮視頻時，在觀看者看來為移動的視覺假影。其他壓縮算法(諸如，來自Microsoft公司的MPEG2、H. 264或VC9)當用于先前技 術的配置中時，可實現高壓縮比率，但以高延時為代價。所述算法利用幀間壓縮以及幀內壓 縮。周期性地，所述算法執行幀的僅幀內壓縮。這種幀被稱為關鍵幀(通常稱作“I”幀)。 接著，該算法通常將I幀與先前幀與相繼幀兩者相比較。并非獨立地壓縮先前幀及相繼幀， 而是算法確定圖像從I幀到先前幀及相繼幀有什么改變，且接著將該改變儲存為“B”幀 (對于I幀之前的改變)及“P”幀(對于I幀之后的改變)。這導致比僅幀內壓縮低得多 的數據速率。但是，其通常以較高延時為代價。I幀通常比B幀或P幀大得多(常常大10 倍)，且因此，以給定數據速率傳輸成比例地花費較長的時間。考慮(例如)一個i情形其中I幀為B幀及P幀的大小的10倍，且對于每個單 個I幀內，存在29個B幀+30個P幀=59個幀間，或對于每個“幀群”(GOP)總共60個幀。 因此，在60fps下，每秒存在1個60幀G0P。假設傳輸信道具有2Mbps的最大數據速率。為 了在信道中達成最高質量的視頻，壓縮算法將產生2Mbps數據流，且給定上述比率，這將產 生每幀內2百萬比特(Mb)/(59+10) = 30，394個比特及每I幀303，935個比特。當通過解 壓縮算法接收經壓縮的視頻流時，為了穩定地播放視頻，需要以規則間隔(例如，60fps)解 壓縮及顯示每個幀。為了實現該結果，若任何幀受到傳輸延時，則需要將所有幀延遲至少該 延時，因此最糟狀況的幀延時將限定用于每個視頻幀的延時。因為I幀最大，所以I幀引入 最長傳輸延時，且整個I幀將必須在可解壓縮及顯示I幀(或取決于I幀的任何幀間)之 前接收。假定信道數據速率為2Mbps，則傳輸I幀將花費303，935/2Mb = 145毫秒。使用傳輸信道的帶寬的大百分比的幀間視頻壓縮系統(如上所述)將由于I幀相 對于幀的平均大小的大的大小而經受長延時。或者，換言之，當先前技術幀間壓縮算法達成 比僅幀內壓縮算法低的平均每幀數據速率(例如，2Mbps對40Mbps)時，其由于大I幀而仍 遭受高的峰值每幀數據速率(例如，303，935*60 = 18. 2Mbps)。但請記住上述分析假定P 幀及B幀均比I幀小得多。盡管這大體成立，但對于具有與先前幀、高運動或場景改變不相 關的高圖像復雜度的幀，這不成立。在所述情形下，P幀或B幀可變得與I幀一般大(若P 幀或B幀變得比I幀大，則尖端壓縮算法通常將“強制”I幀且用I幀替換P幀或B幀)。因 此，I幀大小的數據速率峰值可在任何時刻出現于數字視頻流中。因此，對于經壓縮的視頻， 當平均視頻數據速率接近傳輸信道的數據速率容量時(經常為該狀況，給定對于視頻的高 數據速率要求)，來自I幀或大的P幀或B幀的高峰值數據速率導致高幀延時。當然，上述論述僅特征化由GOP中的大的B幀、P幀或I幀產生的壓縮算法延時。 若使用B幀，則延時將更高。原因是因為在可顯示B幀之前，必須接收B幀之后的所有B幀 及I幀。因此，在諸如BBBBBIPPPPPBBBBBIPPPPP的圖片群(GOP)序列中，其中在每個I幀之
17前存在5個B幀，只有在接收到隨后的B幀及I幀之后才可由視頻解壓縮器顯示第一 B幀。 因此，若使視頻以60fps (也即，16. 67毫秒/幀)流動，則在可解壓縮第一 B幀之前，不管 信道帶寬如何快，接收五個B幀及I幀將花費16. 67*6 = 100毫秒，且這是僅5個B幀的情 況。具有30個B幀的經壓縮的視頻序列相當普遍。此外，在如2Mbps的低信道帶寬下，由 于I幀的大小而引起的延時影響很大程度上增加到由于等待B幀到達而產生的延時影響。 因此，在2Mbps信道上，在大量B幀的情況下，使用先前技術視頻壓縮技術超過500毫秒或 500毫秒以上的延時相當容易。若不使用B幀(對于給定質量水準，以較低壓縮比率為代 價)，則不招致B幀延時，但仍招致上文所描述的由于峰值幀大小而引起的延時。問題恰恰由于許多視頻游戲的性質而加重。利用上文所描述的GOP結構的視頻壓 縮算法很大程度上被最佳化以用于連同要用于被動觀看的現場直播的視頻或電影材料一 起使用。通常，相機(真實相機，或者計算機產生的動畫的狀況下的虛擬相機)及場景相對 穩定，僅因為若相機或場景太顛簸地來回移動，則視頻或電影材料(a)通常觀看起來令人 不愉快，且(b)若其正被觀看，當相機突然來回顛簸時，觀看者通常不能夠緊密地跟隨該動 作(例如，若相機在拍攝吹滅生日蛋糕上的蠟燭的孩子時被擾動且突然在蛋糕之間來回顛 簸，則觀看者通常集中于孩子及蛋糕上，而不理會相機突然移動時的簡短中斷)。在視頻會 談或視頻電話會議的狀況下，可將相機固持于固定位置中且根本不移動，從而導致根本非 常少的數據峰值。但3D高動作視頻游戲通過恒定運動來被特征化(例如，考慮3D競賽，其 中整個幀在競賽的持續時間中處于快速運動中，或者考慮第一人稱射擊游戲，其中虛擬相 機恒定地顛簸地來回移動)。所述視頻游戲可產生具有大的及頻繁的峰值的幀序列，其中用 戶可能需要清楚地看見在該突然運動期間發生了什么。因此，在3D高動作視頻游戲中，壓 縮假影遠不可容忍。因此，許多視頻游戲的視頻輸出(由于其性質)產生具有非常高且頻 繁的峰值的經壓縮的視頻流。假定快動作視頻游戲的用戶對于高延時具有小的容忍度，且給定所有上述延時原 因，至今存在對于使視頻在互聯網上流動的服務器主機代管的視頻游戲的限制。另外，若需 要高度互動性的應用程序被主機代管于通用互聯網上且使視頻流動，則所述應用程序的用 戶遭受類似限制。所述服務需要網絡配置，其中主機代管服務器直接設置于前端(在電纜 寬帶的狀況下)或中央辦公室(在數字用戶線(DSL)的狀況下)中，或商業背景中的LAN內 (或特別分級的私用連接上)，以便控制自客戶端設備至服務器的路線及距離以最小化延 時且可適應峰值而不造成延時。LAN(通常額定在lOOMbps-lGbps)及具有足夠帶寬的租用 線路通常可支持峰值帶寬要求(例如，18Mbps峰值帶寬為100Mbps LAN容量的一小部分)。若進行特殊適應，則峰值帶寬要求也可由住宅寬帶基礎架構來適應。舉例而言，在 電纜TV系統上，可為數字視頻通信給出專用帶寬，該專用帶寬可處理諸如大I幀的峰值。此 外，在DSL系統上，可供應較高速度的DSL調制解調器(考慮高峰值)，或可供應可處理較高 數據速率的特別分級的連接。但是，附接至通用互聯網的傳統電纜調制解調器及DSL基礎 架構對于用于壓縮的視頻的峰值帶寬要求而言遠不能容忍。因此，在線服務(將視頻游戲 或應用程序主機代管于距客戶端設備長距離的服務器中心中，且接著經由傳統的住宅寬帶 連接經由互聯網而使經壓縮的視頻輸出流動)遭受顯著的延時及峰值帶寬要求-尤其對于 需要非常低的延時的游戲及應用程序(例如，第一人稱射擊游戲及其他多用戶、互動式動 作游戲，或需要快響應時間的應用程序)。


根據下面的詳細描述并根據附圖可以更完整地理解本公開，然而，所述附圖并不 用來將公開的主題限制到所示特定實施方式中，而只是用作解釋和理解。圖1示出了先前技術視頻游戲系統的架構。圖2a至圖2b示出了根據一個實施例的高級系統架構。圖3示出了用于客戶端與服務器之間的通信的實際的、額定的及所需的數據速率。圖4a示出了根據一個實施例而使用的主機服務及客戶端。圖4b示出了與客戶端與主機服務之間的通信相關的例示性延時。圖4c示出了根據一個實施例的客戶端設備。圖4d示出了根據另一個實施例的客戶端設備。圖4e示出了圖4c中的客戶端設備的實例方塊圖。圖4f示出了圖4d中的客戶端設備的實例方塊圖。圖5示出了可根據一個實施例而使用的視頻壓縮的一個實例。圖6a示出了可在另一個實施例中使用的視頻壓縮的一個實例。圖6b示出了與傳輸低復雜度、低動作視頻序列相關的數據速率中的峰值。圖6c示出了與傳輸高復雜度、高動作視頻序列相關的數據速率中的峰值。圖7a至圖7b示出了在一個實施例中使用的實例視頻壓縮技術。圖8示出了在一個實施例中使用的額外實例視頻壓縮技術。圖9a至圖9c示出了在一個實施例中使用以用于緩解數據速率峰值的實例技術。圖IOa至圖IOb示出了將圖像圖像塊有效地封裝于分組內的一個實施例。圖Ila至圖Ild示出了使用前向糾錯技術的實施例。圖12示出了使用多核心處理單元來進行壓縮的一個實施例。圖13a至圖13b示出了根據各種實施例的主機服務之間的地理定位及通信。圖14示出了與客戶端與主機服務之間的通信相關的示例性延時。圖15示出了實例主機服務服務器中心架構。圖16示出了包括多個現場直播的視頻窗的用戶接口的一個實施例的實例屏幕拍攝。圖17示出了在選擇特定視頻窗之后的圖16的用戶接口。圖18示出了在將特定視頻窗放大至全屏幕大小之后的圖17的用戶接口。圖19示出了疊加在多人游戲的屏幕上的實例合作用戶視頻數據。圖20示出了用于主機服務上的游戲玩家的實例用戶頁面。圖21示出了實例3D互動式廣告。圖22示出了用于自現場直播的表演的表面捕獲產生具有紋理表面的照片般逼真 的圖像的實例步驟序列。圖23示出了允許選擇線性媒體內容的實例用戶接口頁面。圖24為示出了在現場直播網頁之前消逝的時間量與連接速度的曲線圖。
19
具體實施例方式在以下描述中列舉了特定細節(諸如，設備類型、系統配置、通信方法等)，以便提 供對本公開的徹底理解。然而，一般本領域的技術人員應了解，實踐所描述的所述實施例可 能不需要這些特定細節。圖2a至圖2b提供兩個實施例的高級架構，其中視頻游戲及軟件應用程序由主機 服務210主機代管且在訂閱服務下由用戶場所211 (注意，“用戶場所”意思是用戶所定位的 無論何處的位置，若使用移動設備則包括室外)處的客戶端設備205經由互聯網206 (或其 他公眾網絡或私用網絡)來存取。客戶端設備205可為具有至互聯網的有線或無線連接、 具有內部或外部顯示設備222的通用計算機(諸如，以Microsoft Windows或Linux為基 礎的PC或Apple公司的Macintosh計算機)，或者其可為將視頻及音頻輸出到監視器或電 視機222的諸如機頂盒的專用客戶端設備(具有至互聯網的有線或無線連接)，或者其可為 推測起來具有至互聯網的無線連接的行動設備。所述設備中的任一者可具有其自身的用戶輸入設備(例如，鍵盤、按鈕、觸摸屏 幕、追蹤板(track pad)或慣性感測棒(inertial-sensing wand)、視頻捕獲相機和/或運 動追蹤相機等)，或者其可使用通過有線或無線連接的外部輸入設備221 (例如，鍵盤、鼠 標、游戲控制器、慣性感測棒、視頻捕獲相機和/或運動追蹤相機等)。如下文更詳細描述， 主機服務210包括各種性能水平的服務器(包括具有高能力CPU/GPU處理能力的那些服務 器)。在播放游戲或使用主機服務210上的應用程序期間，家庭或辦公室客戶端設備205 接收來自用戶的鍵盤和/或控制器輸入，且接著其將控制器輸入經由互聯網206傳輸至主 機服務210，主機服務210作為響應來執行游戲程序代碼并產生用于游戲或應用程序軟件 的視頻輸出(視頻圖像序列)的相繼幀(例如，若用戶按壓將會指引屏幕上的人物向右移 動的按鈕，則游戲程序接著將產生顯示人物向右移動的視頻圖像序列)。接著使用低延時 視頻壓縮器壓縮該視頻圖像序列，且主機服務210接著經由互聯網206而傳輸低延時視頻 流。家庭或辦公室客戶端設備接著解碼經壓縮的視頻流并將經解壓縮的視頻圖像再現于監 視器或TV上。因此，顯著地減少客戶端設備205的計算及圖形硬件要求。客戶端205僅需 要具有用于將鍵盤/控制器輸入轉發到互聯網206且解碼并解壓縮從互聯網206所接收的 經壓縮的視頻流的處理能力，實際上現今任何個人計算機均能夠在其CPU上以軟件來進行 這些(例如，以約2GHz執行的Intel公司雙核CPU能夠解壓縮使用諸如H. 264及Windows 媒體VC9的壓縮器編碼的720p HDTV)。此外，在任何客戶端設備的狀況下，專用芯片也可以 比通用CPU低得多的成本及比通用CPU少得多的電力消耗(諸如，現代PC所需的)來實時 地執行用于所述標準的視頻解壓縮。值得注意地，為了執行轉遞控制器輸入及解壓縮視頻 的功能，家庭客戶端設備205不需要任何專門化的圖形處理單元(GPU)、光學驅動器或硬盤 驅動器(諸如，圖1中所顯示的先前技術視頻游戲系統)。隨著游戲及應用程序軟件變得更復雜及更具照片般逼真感，其將需要較高性能的 CPU、GPU、較多RAM，及較大且較快的磁盤驅動器，且可使主機服務210處的計算能力不斷地 升級，但終端用戶將不需要使家庭或辦公室客戶端平臺205升級，因為將通過給定視頻解 壓縮算法而使家庭或辦公室客戶端平臺205的處理要求對于顯示分辨率及幀速率保持恒 定。因此，圖2a至圖2b中所說明的系統中不存在現今所見的硬件限制及相容性問題。另外，因為游戲及應用程序軟件僅在主機服務210中的服務器中執行，所以在用戶的家庭或辦公室(除非另外有條件，否則如本文中所使用的“辦公室”將包括任何非住宅 背景，包括(例如)教室)中決不存在游戲或應用程序軟件的復本(光學媒體的形式，或者 為下載的軟件)。這顯著減輕游戲或應用程序軟件被非法復制(盜版)的可能性，以及減輕 可由游戲或應用程序軟件使用的有價值的數據庫被盜版的可能性。實際上，若需要專門化 的服務器(例如，需要非常昂貴的、大的或有噪音的設備)來播放對于家庭或辦公室使用不 可行的游戲或應用程序軟件，則即使獲得游戲或應用程序軟件的盜版復本，其也將不可在 家庭或辦公室中操作。在一個實施例中，主機服務210向設計視頻游戲的游戲或應用程序軟件開發商 (其大體指代軟件開發公司、游戲或電影工作室，或游戲或應用程序軟件出版商)220提供 軟件開發工具，以使得其可設計能夠在主機服務210上執行的游戲。所述工具允許開發商 利用主機服務的特征(所述特征通常在獨立PC或游戲控制臺中將不可用)(例如，快速存 取復雜幾何形狀的非常大的數據庫(除非另外有條件，否則“幾何形狀”將在本文中用于指 代限定3D數據集的多邊形、紋理、索具、照明、行為及其他組件及參數))。在該架構下，不同商業模型是可能的。在一個模型下，主機服務210從終端用戶 收取訂閱費用且向開發商220支付版稅，如圖2a中所顯示。在替代實施中(圖2b中所顯 示)，開發商220直接從用戶收取訂閱費用且向主機服務210支付用于主機代管游戲或應用 程序內容的費用。這些基本原理不限于用于提供在線游戲或應用程序主機代管的任何特定 商業模型。經壓縮的視頻特性如先前所論述，在線提供視頻游戲服務或應用程序軟件服務的一個顯著問題在于 延時。70毫秒-80毫秒的延時(自輸入設備被用戶致動(actuate)的時刻到在顯示設備上 顯示響應時的時刻)為用于需要快響應時間的游戲及應用程序的上限。然而，由于大量實 際及物理約束而使得這在圖2a及圖2b中所顯示的架構的情況下非常難以達成。如圖3中所指示，當用戶訂閱互聯網服務時，連接通常額定為到用戶的家庭或辦 公室的標定最大數據速率301。取決于提供者的策略及路由設備能力，該最大數據速率可或 多或少被嚴格地強制執行，但通常由于許多不同原因中的一者而使得實際可用數據速率較 低。舉例而言，可能在DSL中央辦公室處或在本地電纜調制解調器回路上存在過多網絡通 信通信，或可能在電纜線上存在噪音，從而引起丟棄的分組，或提供者可能建立每用戶每月 最大數目的比特。當前，用于電纜及DSL服務的最大下行數據速率通常在數百千比特/秒 (Kbps)到30Mbps的范圍內。蜂窩式服務通常限于數百Kbps的下行數據。然而，寬帶服務 的速度及訂閱寬帶服務的用戶的數目將隨著時間而急劇增加。當前，一些分析者估計33% 的美國寬帶用戶具有2Mbps或2Mbps以上的下行數據速率。舉例而言，一些分析者預測至 2010年止，超過85%的美國寬帶用戶將具有2Mbps或2Mbps以上的數據速率。如圖3中所指示，實際可用最大數據速率302可隨著時間而波動。因此，在低延 時、在線游戲或應用程序軟件情況下，有時難以預測用于特定視頻流的實際可用數據速率。 若對于特定量的場景復雜度及運動在給定數目的每秒幀數(fps)下以給定分辨率(例如， 640X480i60fps)維持給定質量水平所需的數據速率303升高高于實際可用最大數據速率 302 (如通過圖3中的峰值指示)，則可出現若干問題。舉例而言，一些互聯網服務將僅丟棄 分組，從而導致用戶的視頻屏幕上的丟失的數據及失真的/丟失的圖像。其他服務將暫時
21緩沖(也即，排隊)額外分組且以可用數據速率將所述分組提供到客戶端，從而導致延時的 增加-對于許多視頻游戲及應用程序而言為不可接受的結果。最后，一些互聯網服務提供 者將數據速率的增加視為惡意攻擊(諸如，否認服務攻擊(由計算機黑客用以使網絡連接 停用的公知技術))，且將在特定時間周期中切斷用戶的互聯網連接。因此，本文中所描述的 實施例設法確保用于視頻游戲的所需數據速率不會超過最大可用數據速率。主機服務架構圖4a說明根據一個實施例的主機服務210的架構。主機服務210可位于單個服 務器中心中，或者可跨越多個服務器中心而分散(以為具有比其他者低延時的至特定服務 器中心的路徑的用戶提供低延時連接，以在用戶之間提供負載平衡，且在一或多個服務器 中心出故障的狀況下提供冗余)。主機服務210最終可包括成千上萬個或甚至數百萬個服 務器402，從而服務非常大的用戶基礎(user base)。主機服務控制系統401提供對主機服 務210的總體控制，且指引路由器、服務器、視頻壓縮系統、計費及帳務系統等。在一個實施 例中，主機服務控制系統401實施在基于Linux的分散式處理系統上，該處理系統綁定到用 于儲存用于用戶信息、服務器信息及系統統計數據的數據庫的RAID陣列。在上述描述中， 除非歸因于其他特定系統，否則由主機服務210實施的各種動作由主機服務控制系統401 來起始及控制。主機服務210包括許多服務器402，諸如當前可從Intel (因特爾公司)、IBM(美 國國際商用機器公司)及Hewlett Packard(惠普公司)及其他者得到的所述服務器。或 者，可將服務器402裝配成定制組件配置，或者最終可將服務器402整合以便將整個服務器 實施為單個芯片。盡管此圖為說明起見而顯示少數服務器402，但在實際部署中，可能存在 少至一個服務器402或多達數百萬個或數百萬個以上服務器402的服務器。服務器402均 可以相同方式配置(作為一些配置參數的實例，具有相同CPU類型及性能；具有或不具有 GPU，且若具有GPU，則具有相同GPU類型及性能；具有相同數目的CPU及GPU ；具有相同量及 相同類型/速度的RAM ；及具有相同RAM配置)，或服務器402的各種子集可具有相同配置 (例如，25%的服務器可以一個特定方式配置，50%的服務器以不同方式配置，且25%的服 務器以又一個方式配置)，或每個服務器402可不同。在一個實施例中，服務器402無磁盤，也即，并非具有其自身的本地大容量儲存器 (其為光學或磁性儲存器，或者基于半導體的儲存器，諸如閃存或服務類似功能的其他大 容量儲存裝置)，每一個服務器經由快速底板或網絡連接而存取共用的大容量儲存器。在 一個實施例中，該快速連接為連接到獨立冗余磁盤陣列(RAID)405系列的儲存區域網絡 (SAN)403，在使用超高速以太網實施的設備之間具有連接。如本領域的技術人員已知的， SAN 403可用于將許多RAID陣列405組合在一起，從而導致極高的帶寬_接近或可能超過 可自用于當前游戲控制臺及PC中的RAM得到的帶寬。此外，盡管基于諸如磁性媒體的旋轉 媒體的RAID陣列經常具有顯著的搜尋時間存取延時，但基于半導體儲存器的RAID陣列可 實施為具有低得多的存取延時。在另一配置中，一些或所有服務器402在本地提供一些或 所有其自身的大容量儲存器。舉例而言，服務器402可將頻繁存取的信息(諸如，其操作 系統及視頻游戲或應用程序的復本)儲存在基于低延時本地閃存的儲存器上，但其可利用 SAN來存取基于旋轉媒體的具有較高搜尋延時的RAID陣列405，以較不頻繁地存取幾何形 狀或游戲狀態信息的大數據庫。
另外，在一個實施例中，主機服務210使用下文詳細描述的低延時視頻壓縮邏輯 404。視頻壓縮邏輯404可以軟件、硬件或其任何組合來實施(下文描述其特定實施例)。 視頻壓縮邏輯404包括用于壓縮音頻以及視覺材料的邏輯。在操作中，當經由鍵盤、鼠標、游戲控制器或其他輸入設備421而玩視頻游戲或使 用用戶場所211處的應用程序時，客戶端415上的控制信號邏輯413將表示由用戶促使的 按鈕按壓(及其他類型的用戶輸入)的控制信號406a-b(通常為UDP分組的形式)傳輸 到主機服務210。將來自給定用戶的控制信號路由到適當服務器(或若多個服務器響應于 用戶的輸入設備，則路由至多個服務器)402。如圖4a中所說明，可經由SAN而將控制信號 406a路由至服務器402。可替換地或另外，可經由主機服務網絡(例如，基于以太網的區域 網絡)而將控制信號406b直接路由至服務器402。不管控制信號406a-b是如何被傳輸，該 或所述服務器均響應于控制信號406a_b而執行游戲或應用程序軟件。盡管圖4a中未說明， 但各種網絡連接組件(諸如，防火墻和/或網關)可處理主機服務210的邊緣處(例如，主 機服務210與互聯網410之間)和/或用戶場所211的邊緣處(互聯網410與家庭或辦公 室客戶端415之間)的傳入及傳出的通信。所執行的游戲或應用程序軟件的圖形及音頻輸 出(也即，新的視頻圖像序列)提供至低延時視頻壓縮邏輯404，低延時視頻壓縮邏輯404 根據低延時視頻壓縮技術(諸如，本文中所描述的所述技術)而壓縮視頻圖像序列且經由 互聯網410(或，如下文所描述，經由繞過通用互聯網的最佳高速網絡服務)而將經壓縮的 視頻流(通常具有經壓縮或未經壓縮的音頻)傳輸回至客戶端415。接著，客戶端415上的 低延時視頻解壓縮邏輯412解壓縮視頻及音頻流并再現經解壓縮的視頻流，且通常在顯示 設備422上播放經解壓縮的音頻流。或者，可在與顯示設備422分開的揚聲器上播放音頻 或根本不播放音頻。注意，盡管輸入設備421及顯示設備422在圖2a及圖2b中顯示為獨 立式設備，但其可集成在諸如便攜式計算機或行動設備的客戶端設備內。家庭或辦公室客戶端415 (先前在圖2a及圖2b中描述為家庭或辦公室客戶端 205)可為非常低廉且低能力的設備，其具有非常有限的計算或圖形性能且可能具有非常 有限的本地大容量儲存器或不具有本地大容量儲存器。相比之下，耦合至SAN 403及多個 RAID 405的每一個服務器402可為格外高性能的計算系統，且實際上，若多個服務器以并 列處理配置合作地使用，則幾乎不存在對可承受的計算量及圖形處理能力的限制。此外，由 于低延時視頻壓縮404及低延時視頻解壓縮412(由用戶感知地)，所以將服務器402的計 算能力提供給用戶。當用戶按壓輸入設備421上的按鈕時，顯示器422上的圖像被響應于 按鈕按壓而更新(在感知上無有意義的延遲)，好像游戲或應用程序軟件在本地執行。因 此，對于為非常低性能的計算機或只是實施低延時視頻解壓縮及控制信號邏輯413的低廉 芯片的家庭或辦公室客戶端415，自看來在本地可用的遠程位置有效地為用戶提供任意計 算能力。此為用戶給出用于玩最高級、處理器密集的(通常為新的)視頻游戲及最高性能 的應用程序的能力。圖4c顯示非常基礎且低廉的家庭或辦公室客戶端設備465。該設備為根據圖4a 及圖4b的家庭或辦公室客戶端415的一個實施例。其大約2英寸長。其具有與具有以太 網供電(PoE)的以太網電纜相接口的以太網插孔462，該設備從以太網插孔462得到其電 力及其到互聯網的連接性。該設備能夠在支持網絡地址轉換(NAT)的網絡內執行NAT。在 辦公室環境中，許多新的以太網交換器具有PoE且將PoE直接帶到辦公室中的以太網插孔。在此種情形下，所需的為從壁式插孔到客戶端465的以太網電纜。若可用的以太網連接不 運輸電力(例如，在具有DSL或電纜調制解調器但無PoE的家庭中)，則存在可用的低廉的 壁式“磚塊(brick)，，(也即，電源)，其將接受無電力的以太網電纜且輸出具有PoE的以太 網。客戶端465含有耦合至藍牙無線接口的控制信號邏輯413 (圖4a)，該藍牙無線接 口與諸如鍵盤、鼠標、游戲控制器和/或麥克風和/或耳機的藍牙輸入設備479相接口。而 且，客戶端465的一個實施例在與顯示設備468耦合的情況下能夠以120fps輸出視頻，顯 示設備468能夠支持120fps視頻且向一對遮光眼鏡466發信號(通常經由紅外)以對于 每個相繼幀交替地遮蔽一只眼接著遮蔽另一只眼。用戶所感覺的效果為“跳出”顯示屏幕 的立體3D圖像。支持該操作的一種該顯示設備468為Samsung HL-T5076S。因為用于每一 只眼的視頻流是單獨的，所以在兩個獨立視頻流由主機服務210壓縮的一個實施例中，幀 在時間上交錯，且幀在客戶端465內以兩個獨立解壓縮過程來解壓縮。客戶端465也含有低延時視頻解壓縮邏輯412，其解壓縮傳入的視頻及音頻且經 由HDMI (高清晰度多媒體接口 )、連接器463輸出，HDMI (高清晰度多媒體接口 )、連接器463 插入到SDTV (標準清晰度電視)或HDTV (高清晰度電視)468中，從而向TV提供視頻及音 頻，或插入到支持HDMI的監視器468中。若用戶的監視器468不支持HDMI，則可使用HDMI 至DVI (數字視覺接口)，但音頻將丟失。在HDMI標準下，顯示能力(例如，所支持的分辨 率，幀速率)464從顯示設備468表達，且接著經由互聯網連接462將該信息傳回到主機服 務210，因此主機服務210可使經壓縮的視頻以適合于該顯示設備的格式流動。圖4d顯示家庭或辦公室客戶端設備475，除了客戶端設備475具有更多外部接口 之外，其與圖4c中所顯示的家庭或辦公室客戶端設備465相同。而且，客戶端475可接受 PoE來供電，或者其可占用插入墻壁中的外部電源適配器(未圖示)。視頻相機477使用客 戶端475USB輸入將經壓縮的視頻提供到客戶端475，經壓縮的視頻由客戶端475上傳到主 機服務210以用于下文所描述的用途。將利用下文所描述的壓縮技術將低延時壓縮器創建 到相機477中。除具有用于其互聯網連接的以太網連接器之外，客戶端475還具有到互聯網的 802. Ilg無線接口。兩種接口均能夠在支持NAT的網絡內使用NAT。而且，除具有用于輸出視頻及音頻的HDMI連接器之外，客戶端475還具有雙鏈接 DVI-I連接器，雙鏈接DVI-I連接器包括模擬輸出端(且具有將提供VGA輸出的標準適配器 電纜)。其還具有用于復合視頻及S視頻的模擬輸出端。對于音頻，客戶端475具有左/右模擬立體RCA插孔，且對于數字音頻輸出，其具 有T0SLINK (光纖)輸出端。除了到輸入設備479的藍牙無線接口之外，其還具有用于接口到輸入設備的USB 插孔。圖4e顯示客戶端465的內部架構的一個實施例。該圖中所顯示的所有設備或一 些設備可實施在場可程序化邏輯陣列、定制ASIC中或若干個離散設備(定制設計或者現成 的)中。具有PoE的以太網497附接到以太網接口 481。電力499才具有PoE的以太網497 得到且連接到客戶端465中的其余設備。總線480為用于設備之間的通信的公同總線。
執行來自閃存476的小客戶端控制應用程序的控制CPU 483 (幾乎任何小CPU都 是適當的，諸如具有嵌入式RAM的IOOMHz下的MIPS R4000系列CPU)實施用于網絡(也即， 以太網接口)的協議棧且還與主機服務210通信，并配置客戶端465中的所有設備。其還 處理與輸入設備469的接口并將分組(必要時，連同受前向糾錯保護的用戶控制器數據一 起)發送回至主機服務210。而且，控制CPU 483監視分組通信(例如，分組是丟失還是延 遲，以及其到達的時間戳)。將此信息發送回至主機服務210，以使得其可恒定地監視網絡 連接且相應地調整其發送的內容。最初在制造時為閃存476載入用于控制CPU 483的控制 程序以及對于特定客戶端465單元而言唯一的序號。此序號允許主機服務210唯一地識別 客戶端465單元。藍牙接口 484經由其天線(在客戶端465內部)無線地通信至輸入設備469。視頻解壓縮器486為經配置以實施本文中所描述的視頻解壓縮的低延時視頻解 壓縮器。大量視頻解壓縮設備存在，或者為現成產品，或者作為具有可整合在FPGA或定制 ASIC中的設計的知識產權(IP)。一個提供用于H. 264解碼器的IP的公司為澳大利亞新南 威爾士州(NSWAustralia)的Ocean Logicof Manly。使用IP的優點在于本文中所使用 的壓縮技術與壓縮標準不相符。一些標準解壓縮器足夠靈活以經配置以適應本文中的壓縮 技術，但一些標準解壓縮器可能并非如此。但是，在IP的情況下，在視需要而重新設計解壓 縮器中存在完全靈活性。視頻解壓縮器的輸出端耦合至視頻輸出子系統487，視頻輸出子系統487將視頻 耦合至HDMI接口 490的視頻輸出端。音頻解壓縮子系統488或者使用可用的標準音頻解壓縮器來實施，或者其可實施 為IP，或者可在可(例如)實施VorbiS音頻解壓縮器的控制處理器483內實施音頻解壓 縮。實施音頻解壓縮的設備耦合到音頻輸出子系統489，音頻輸出子系統489將音頻 耦合至HDMI接口 490的音頻輸出端。圖4f顯示客戶端475的內部架構的一個實施例。如可見，除額外接口及來自插入 墻壁中的電源適配器的可選外部DC電力(且若如此使用，則可選外部DC電力替換將來自 以太網PoE 497的電力)之外，該架構與客戶端465的架構相同。下文中將不重復與客戶 端465共同的功能性，但將額外功能性描述如下。CPU 483與額外設備通信且配置額外設備。WiFi子系統482經由其天線提供無線互聯網存取，作為對以太網497的替代。WiFi 子系統可購自多家制造商，包括美國加州的圣克拉拉的AtherosCommunications (阿特赫 魯斯通信公司)。USB子系統485提供對用于有線USB輸入設備479的藍牙通信的替代。USB子系 統相當標準且可容易地用于FPGA及ASIC，且經常創建到執行如視頻解壓縮的其他功能的 現成設備中。與客戶端465內的視頻輸出相比較，視頻輸出子系統487產生較寬范圍的視頻輸 出。除提供HDMI 490視頻輸出之外，其提供DVI-I 491、S-視頻492及合成視頻493。而 且，當DVI-I 491接口用于數字視頻時，將顯示能力464自顯示設備傳回至控制CPU 483，以 使得其可向主機服務210通知顯示設備478的能力。由視頻輸出子系統487提供的所有接
25口均為相當標準的接口且容易以許多形式可用。音頻輸出子系統489經由數字接口 494(S/PDIF和/或Toslink)數字地輸出音頻 且經由立體模擬接口 495輸出模擬形式的音頻。來回行程延時分析當然，為了實現前一段的利益，用戶使用輸入設備421的動作與在顯示設備420上 看見該動作的后果之間的來回行程延時應不大于70毫秒-80毫秒。此延時必須考慮在自用 戶場所211中的輸入設備421到主機服務210及再次返回到用戶場所211至顯示設備422 的路徑中的所有因素。圖4b說明各種組件及網絡(信號必須經由該組件或網絡行進)，且 該組件及網絡上方的為時間線，該時間線列出實際實施中可預期的例示性延時。注意，圖4b 經簡化以便僅顯示重要路徑路由。下文描述用于系統的其他特征的數據的其他路由。雙頭 箭頭(例如，箭頭453)指示來回行程延時且單頭箭頭(例如，箭頭457)指示單向延時，且 “ ”表示近似量測。應指出，將存在所列的延時不可達成的真實世界情形，但在大量狀況 下，在美國，使用至用戶場所211的DSL及電纜調制解調器連接，該延時可在下一段中所描 述的情形中達成。而且，注意，盡管至互聯網的蜂窩式無線連接性的確將在所顯示的系統中 工作，但大多數當前美國蜂窩式數據系統(諸如，EVD0)招致非常高的延時且將不能夠達成 圖4b中所顯示的延時。然而，這些基本原理可在可能能夠實施該水平的延時的未來蜂窩式 技術上實施。自用戶場所211處的輸入設備421開始，一旦用戶致動輸入設備421，就將用戶控 制信號發送至客戶端415 (其可為諸如機頂盒的獨立設備，或其可為在諸如PC或行動設備 的另一設備中執行的軟件或硬件)，且將其分組化(在一個實施例中以UDP格式)并為分組 給出目的地地址以到達主機服務210。分組將也含有用于指示控制信號來自哪個用戶的信 息。接著經由防火墻/路由器/NAT(網絡地址轉換)設備443將控制信號分組轉發到WAN 接口 442。WAN接口 442為由用戶的ISP (互聯網服務提供者)提供到用戶場所211的接口 設備。WAN接口 442可以是電纜或DSL數據機、WiMax收發器、光纖收發器、蜂窩式數據接 □、電網十辦i^din (InternetProtocol-over-powerline interface), ^ilJSKN 的許多接口中的任何其他接口。另外，可將防火墻/路由器/NAT設備443 (及(可能地) WAN接口 442)整合到客戶端415中。該一個實例將為移動電話，其包括用于實施家庭或辦 公室客戶端415的功能性的軟件，以及用于經由某標準(例如，802. Ilg)而無線地路由及連 接到互聯網的裝置。WAN接口 442接著將控制信號路由至本文中所稱的用于用戶的互聯網服務提供者 (ISP)的“存在點”441，WAN接口 442為提供連接至用戶場所211的WAN輸送器與通用互聯 網或私用網絡之間的接口的設施。存在點的特性將視所提供的互聯網服務的性質而改變。 對于DSL，其通常是DSLAM位于的電話公司中央辦公室。對于電纜調制解調器，其通常是電 纜多系統運營商(MSO)前端。對于蜂窩式系統，其通常是與蜂窩式塔相關的控制室。但無 論存在點的性質怎樣，其均將接著將控制信號分組路由至通用互聯網410。接著經由將最 可能系光纖收發器接口的接口將控制信號分組路由至WAN接口 444至主機服務210。WAN 444將接著將控制信號分組路由至路由邏輯409 (其可以許多不同方式來實施，包括以太網 交換器及路由服務器)，路由邏輯409估計用戶的地址且將控制信號路由至用于給定用戶 的正確的服務器402。
服務器402接著將所述控制信號視為在服務器402上執行的游戲或應用程序軟件 的輸入且使用所述控制信號來處理游戲或應用程序的下一個幀。一旦產生下一個幀，就將 視頻及音頻自服務器402輸出至視頻壓縮器404。可經由各種裝置將視頻及音頻自服務器 402輸出至壓縮器404。首先，可將壓縮器404創建到服務器402中，因此可在服務器402 內在本地實施壓縮。或者，可經由到網絡(其或者是服務器402與視頻壓縮器404之間的 私用網絡，或者是經由諸如SAN 403的共用網絡的網絡)的網絡連接(諸如，以太網連接) 以分組化的形式輸出視頻和/或音頻。或者，可經由視頻輸出連接器(諸如，DVI或VGA連 接器)將視頻自服務器402輸出，且接著由視頻壓縮器404來捕獲。而且，可將音頻自服務 器402輸出為數字音頻(例如，經由T0SLINK或S/PDIF連接器)或模擬音頻，模擬音頻由 視頻壓縮器404內的音頻壓縮邏輯來數字化并編碼。—旦視頻壓縮器404已捕獲來自服務器402的視頻幀及在該幀時間期間所產生的 音頻，則視頻壓縮器將使用下文所描述的技術壓縮視頻及音頻。一旦視頻及音頻被壓縮，就 通過一地址將其分組化以將其發送回至用戶的客戶端415，且將其路由至WAN接口 444，WAN 接口 444接著經由通用互聯網410路由視頻及音頻分組，通用互聯網410接著將視頻及音 頻分組路由至用戶的ISP的存在點441，存在點441將視頻及音頻分組路由至用戶場所處的 WAN接口 442，WAN接口 442將視頻及音頻分組路由至防火墻/路由器/NAT設備443，防火 墻/路由器/NAT設備443接著將視頻及音頻分組路由至客戶端415。客戶端415解壓縮視頻及音頻，且接著在顯示設備422(或客戶端的內置顯示設 備)上顯示視頻并將音頻發送到顯示設備422或到單獨的放大器/揚聲器或到創建到客戶 端中的放大器/揚聲器。為使用戶感覺到剛才所描述的整個過程在感知上沒有滯后，來回行程延遲需要小 于70毫秒或80毫秒。所描述的來回行程路徑中的一些延時延遲受主機服務210和/或用 戶的控制，而其他的延時延遲不受主機服務210和/或用戶的控制。盡管如此，基于大量真 實世界情況的分析及測試，以下為近似量測。用于發送控制信號的單向傳輸時間451通常小于1毫秒，經由用戶場所的來回行 程路由452通常使用以太網上的易得的消費者級防火墻/路由器/NAT交換器而在約1毫 秒內完成。用戶ISP廣泛地改變其來回行程延遲453，但在DSL及電纜調制解調器提供者 的情況下，通常看見其在10毫秒與25毫秒之間。通用互聯網410上的來回行程延時可視 頻務被如何路由及路在線是否存在任何故障(且該問題在下文加以論述)而極大地改變， 但通常通用互聯網提供相當最佳的路由且延時很大程度上由光穿過光纖的速度(給定到 目的地的距離)來確定。如下文進一步論述，已確定1000英里作為期望將主機服務210遠 離用戶場所211置放的大致最遠距離。在1000英里處(來回行程2000英里)，用于信號 經由互聯網的實際傳輸時間為約22毫秒。至主機服務210的WAN接口 444通常為具有可 忽略的延時的商業級光纖高速接口。因此，通用互聯網延時454通常在1毫秒與10毫秒之 間。經由主機服務210的單向路由455延時可在小于1毫秒內達成。服務器402通常將在 小于一幀時間(其在60fps下為16. 7毫秒)的時間中計算用于游戲或應用程序的新幀，因 此16毫秒為將使用的合理的最大單向延時456。在本文中所描述的視頻壓縮及音頻壓縮算 法的最佳硬件實施中，壓縮457可在1毫秒內完成。在次佳版本中，壓縮可花費多達6毫秒 (當然，更欠佳的版本可花費更長時間，但所述實施將影響來回行程的總延時且將需要其他
27延時較短(例如，可減小經由通用互聯網的可允許的距離)以維持70毫秒-80毫秒延時目 標)。已經考慮互聯網454、用戶ISP 453及用戶場所路由452的來回行程延時，因此剩余 的為視頻解壓縮458延時，視頻解壓縮458延時取決于視頻解壓縮458是實施于專用硬件 中還是實施于客戶端設備415(諸如，PC或行動設備)上的軟件中，可視顯示器的大小及解 壓縮CPU的性能而改變。通常，解壓縮458花費1毫秒與8毫秒之間的時間。因此，可通過將在實踐中所見的所有最糟狀況的延時加在一起來確定圖4a中所顯 示的系統的用戶可預期將經歷的最糟狀況的來回行程延時。他們是1+1+25+22+1+16+6+8 =80毫秒。此外，實際上，在實踐中(具有下文所論述的防止誤解的說明)，此大致為使用 圖4a中所顯示的系統的原型版本(在美國使用現成的Windows PC作為客戶端設備及家庭 DSL及電纜調制解調器連接)所見的來回行程延時。當然，優于最糟狀況的情況可導致短得 多的延時，但不可依賴其來開發廣泛使用的商業服務。為了經由通用互聯網達成圖4b中所列出的延時，需要客戶端415中的視頻壓縮器 404及視頻解壓縮器412 (來自圖4a)產生具有非常特定的特性的分組流，以使得經由自主 機服務210至顯示設備422的整個路徑所產生的分組序列不經受延遲或過多分組丟失，且 詳言之，始終如一地落在經由用戶的互聯網連接(經由WAN接口 442及防火墻/路由器/ NAT 433)而可用于用戶的帶寬的約束內。另外，視頻壓縮器必須產生足夠強健的分組流，以 使得其可容忍在正常互聯網及網絡傳輸中出現的不可避免的分組丟失及分組重排序。低延時視頻壓縮為了完成上述目標，一個實施例采用新的視頻壓縮方法，該方法降低用于傳輸視 頻的延時及峰值帶寬要求。在描述該實施例之前，將關于圖5及圖6a至圖6b提供對當前 視頻壓縮技術的分析。當然，若用戶具備足以處理所述技術所需的數據速率的帶寬，則該技 術可根據基本原理來使用。注意，本文中不解決音頻壓縮，而是陳述音頻壓縮與視頻壓縮同 時且同步地來實施。滿足用于該系統的要求的先前技術音頻壓縮技術存在。圖5說明用于壓縮視頻的一個特定先前技術，其中由壓縮邏輯520使用特定壓縮 算法來壓縮每個個別視頻幀501-503以產生一系列經壓縮的幀511-513。該技術的一個實 施例是“運動JPEG”，其中根據聯合圖像專家群(JPEG)壓縮算法基于離散余弦變換(DCT) 來壓縮每一幀。可使用各種不同類型的壓縮算法，然而，仍遵守該基本原理(例如，以小波 為基礎的壓縮算法，諸如JPEG-2000)。此類型壓縮的一個問題在于其減小了每個幀的數據速率，但其不利用連續幀之 間的類似性來減小總視頻流的數據速率。舉例而言，如圖5中所說明，假定640 X 480 X 24比 特/像素=640*480*24/8/1024 = 900千字節/幀(KB/幀)的幀速率，則對于給定質量的 圖像，運動JPEG可能僅將該流壓縮1/10，從而產生90KB/幀的數據流。在60幀/秒下，此 將需要90KB*8比特*60幀/秒=42. 2Mbps的信道帶寬，其對于美國現今幾乎所有的家庭 互聯網連接而言將為極高的帶寬，且對于許多辦公室互聯網連接而言為過高的帶寬。實際 上，假定其在此種高帶寬的情況下要求恒定數據流，且其將僅服務一個用戶，則即使在辦公 室LAN環境中，其也將消耗IOOMbps以太網LAN的帶寬的大百分比及支持LAN的負擔沉重的 以太網交換器。因此，當與其他壓縮技術(諸如下文所描述的那些技術)相比較時，用于運 動視頻的壓縮無效率。此外，使用有損壓縮算法的單個幀壓縮算法(如JPEG及JPEG-2000) 產生在靜止圖像中可能不引人注意的壓縮假影(例如，場景中的密集樹葉內的假影可能不
28呈現為假影，因為眼并不確切地知道密集樹葉應如何呈現)。但是，一旦場景在運動中，假影 就可能突出，因為眼偵測到自幀至幀而改變的假影，盡管假影在場景的區域(在該區域中， 假影在靜止圖像中可能不引人注意)中。此導致幀序列中的“背景噪音”的感知，該“背景 噪音”的外觀與邊緣模擬TV接收期間可見的“雪花”雜音類似。當然，該類型的壓縮仍可用 于本文中所描述的特定實施例中，但一般而言，為了避免場景中的背景噪音，對于給定感知 質量，需要高數據速率(也即，低壓縮比率)。其他類型的壓縮(諸如，H. 264，或Windows媒體VC9、MPEG2及MPEG4)在壓縮視頻 流中均更有效，因為其利用連續幀之間的類似性。這些技術均依賴于用于壓縮視頻的相同 的一般技術。因此，盡管將描述H. 264標準，但相同的一般原理適用于各種其他壓縮算法。 大量H. 264壓縮器及解壓縮器可用，包括用于壓縮H. 264的x264開放源軟件庫及用于解壓 縮H. 264的FFmpeg (—種視頻和音頻流方案)開放源軟件庫。圖6a及圖6b說明例示性先前技術壓縮技術，其中由壓縮邏輯620將一系列未 經壓縮的視頻幀501-503,559-561壓縮成一系列“I幀” 611、671 ；“P幀” 612-613 ；及“B 幀” 670。圖6a中的垂直軸大體表示經編碼的幀中的每一者的所得大小(盡管所述幀未按 比例進行繪制)。如上所述，本領域的技術人員良好地理解使用I幀、B幀及P幀的視頻寫 碼。簡言之，I幀611為完全未壓縮的幀501的基于DCT的壓縮(類似于如上所述的經壓縮 的JPEG圖像)。P幀612-613的大小通常顯著小于I幀611的大小，因為其利用先前I幀 或P幀中的數據；也即，其含有指示先前I幀或P幀之間的改變的數據。除B幀使用隨后參 考幀中的幀以及(可能地)之前參考幀中的幀之外，B幀670類似于P幀。對于以下論述，將假定所要的幀速率為60幀/秒，每個I幀為約160Kb，平均 P幀及B幀為16Kb且每隔一秒產生一新的I幀。在該組參數下，平均數據速率將為 160Kb+16Kb*59 = 1. 1Mbps。該數據速率適當地落在用于到家庭及辦公室的許多當前寬帶 互聯網連接的最大數據速率內。該技術也傾向于避免來自僅幀內編碼的背景噪音問題，因 為P幀及B幀追蹤幀之間的差異，因此壓縮假影傾向于不自幀至幀而呈現及消失，從而減少 上文所描述的背景噪音問題。上述類型的壓縮的一個問題在于盡管平均數據速率相對低(例如，1. IMbps)，但 單個I幀可能花費若干個幀時間來傳輸。舉例而言，使用先前技術，2. 2Mbps網絡連接(例 如，DSL或電纜調制解調器，其具有來自圖3a的最大可用數據速率302的2. 2Mbps峰值) 通常將足夠使視頻以1. IMbps流動，每60個幀一個160Kbps的I幀。這將通過使解壓縮器 在解壓縮視頻之前將1秒視頻排入隊列來完成。在1秒內，將傳輸1. 1Mb的數據，其將通過 2. 2Mbps最大可用數據速率來容易地適應，即使假定可用數據速率可能周期性地下降多達 50%也如此。遺憾地，此先前技術方法將由于接收器處的1秒視頻緩沖而導致視頻的1秒 延時。此種延遲對于許多先前技術應用程序(例如，線性視頻的回放)而言足夠，但對于不 可容忍大于70毫秒-80毫秒的延時的快動作視頻游戲而言其為極長的延時。若進行嘗試來消除1秒視頻緩沖，其仍將不會導致用于快動作視頻游戲的足夠延 時減少。舉例而言，如先前所述，B幀的使用將需要接收I幀的前的所有B幀以及I幀。若 假定在P幀與B幀之間大致分裂59個非I幀，則將存在至少29個B幀且可顯示任何B幀 之前所接收的I幀。因此，不管信道的可用帶寬如何，均需要29+1 = 30個幀每一者1/60 秒持續時間的延遲，或500毫秒的延時。顯而易見，該時間極長。
因此，另一方法將是消除B幀且僅使用I幀及P幀。(其中一個后果是對于給 定質量水平，數據速率將增加，但出于此實例中的一致性起見，繼續假定每個I幀的大小為 160Kb且平均P幀的大小為16Kb，且因此數據速率仍為1. IMbps)。該方法消除了由B幀引 入的不可避免的延時，因為每個P幀的解碼僅依賴于先前所接收的幀。該方法仍存在的問 題在于1幀比平均P幀大得多，以致在低帶寬信道上(如大多數家庭中及許多辦公室中典 型的)，I幀的傳輸添加實質延時。此在圖6b中加以說明。視頻流數據速率624低于可用 最大數據速率621 (除對于I幀之外)，其中I幀所需的峰值數據速率623遠超過可用最大 數據速率622 (且甚至超過額定最大數據速率621)。P幀所需的數據速率小于可用最大數據 速率。即使在2. 2Mbps的可用最大數據速率峰值穩定地保持在其2. 2Mbps峰值速率，也將花 費160Kb/2. 2Mb = 71毫秒來傳輸I幀，且若可用最大數據速率622下降50% (1. 1Mbps)，則 將花費142毫秒來傳輸I幀。因此，傳輸I幀中的延時將落在71毫秒與142毫秒之間的某 處。該延時添加到圖4b中所識別的延時(所述延時在最糟狀況下總計達70毫秒)，因此， 這將導致從用戶致動輸入設備421的時刻直到圖像呈現于顯示設備422上的為141-222毫 秒的總來回行程延時，其極高。且若可用最大數據速率下降至低于2. 2Mbps，則延時將進一 步增加。還注意到，以遠超過可用數據速率622的峰值數據速率623使ISP “堵塞”通常存 在嚴重后果。不同ISP中的設備將不同地表現，但當以比可用數據速率622高得多的數據 速率接收分組時，以下行為在DSL及電纜調制解調器ISP當中相當普遍(a)通過將分組排 入隊列而使分組延遲(引入延時)，(b)丟棄一些或所有分組，(c)將連接停用一時間周期 (最可能因為ISP擔憂其為惡意攻擊，諸如“否認服務”攻擊)。因此，以全數據速率傳輸分 組流(具有諸如圖6b中所顯示的所述特性的特性)并非為可行的選項。可在主機服務210 處將峰值623排入隊列且以低于可用最大數據速率的數據速率進行發送，從而引入前一段 中所描述的不可接受的延時。另外，圖6b中所顯示的視頻流數據速率序列624為非常“馴服的(tame) ”視頻流數 據速率序列，且將是由于壓縮來自視頻序列的視頻而預期產生的該種數據速率序列，該視 頻序列并不改變很大且具有非常少的運動(例如，如在視頻電話會議中將是普遍的，在視 頻電話會議中，相機處于固定位置中且具有非常少的運動，且場景(例如，就座的人談話) 中的對象顯示較少運動)。圖6c中所顯示的視頻流數據速率序列634為從具有多得多的動作的視頻(諸如， 可能在電影或視頻游戲中或在某應用程序軟件中產生)預期可見的典型序列。注意，除I 幀峰值633之外，還存在相當大且在許多場合上超過可用最大數據速率的P幀峰值(諸如， 635及636)。盡管所述P幀峰值并不如I幀峰值一般相當大，但其仍極大以致不能由信道 以全數據速率來運輸，且如同I幀峰值一樣，P幀峰值必須緩慢地傳輸(借此增加延時)。在高帶寬信道(例如，100Mbps LAN,或高帶寬IOOMbps私用連接)上，網絡將能 夠容忍諸如I幀峰值633或P幀峰值636的大峰值，但原則上，可維持低延時。但是，所述 網絡經常在許多用戶當中共用(例如，在辦公室環境中)，且該“有峰”數據將影響LAN的 性能，尤其在網絡通信經路由至私用共用連接(例如，從遠程數據中心到辦公室)的情況 下。首先，記住此實例是60fps下640X480像素的相對低分辨率的視頻流的實例。60fps 下的1920X1080的HDTV流容易由現代計算機及顯示器來處理，且60fps下的2560X1440
30分辨率顯示器日益可用(例如，Apple公司的30"顯示器)。使用H. 264壓縮，60fps下的 1920X1080的高動作視頻序列可能需要4. 5Mbps以獲得合理質量水平。若假定I幀峰值為 標定數據速率的10倍，則其將產生45Mbps峰值，以及較小但仍相當大的P幀峰值。若若干 個用戶正在同一 IOOMbps網絡(例如，辦公室與數據中心之間的私用網絡連接)上接收視 頻流，則容易看見來自若干用戶的視頻流的峰值可如何碰巧對準，從而淹沒網絡的帶寬，且 可能淹沒網絡上支持用戶的交換器的底板的帶寬。即使在超高速以太網的狀況下，若足夠 的用戶具有同時對準的足夠峰值，則其可淹沒網絡或網絡交換器。此外，一旦2560X1440 分辨率視頻變得更常見，平均視頻流數據速率就可能為9. 5Mbps,從而或許產生95Mbps峰 值數據速率。不用說，數據中心與辦公室之間的IOOMbps連接(其在現今為格外快的連接) 將完全被來自單一用戶的峰值通信擊潰。因此，即使LAN及私用網絡連接對有峰流動視頻 可具有更高容忍度，具有高峰值的流動視頻也是不需要的且可能需要辦公室的IT部門的 特殊計劃及適應。當然，對于標準線性視頻應用程序，該問題并不是問題，因為數據速率在傳輸點 “經平滑化”且用于每一幀的數據低于最大可用數據速率622，且在解壓縮I幀、P幀及B幀 序列之前，客戶端中的緩沖器儲存I幀、P幀及B幀序列。因此，網絡上的數據速率保持接 近于視頻流的平均數據速率。很遺憾地，這引入延時，即使不使用B幀，對于諸如需要快響 應時間的視頻游戲及應用程序的低延時應用程序而言，這也是不可接受的。用于減輕具有高峰值的視頻流的一個先前技術解決方法是使用常常被稱作“恒定 比特速率”(CBR)編碼的技術。盡管術語CBR看來似乎暗示將所有幀壓縮以具有相同比特速 率(也即，大小)，但其經常提及的為壓縮范例，在壓縮范例中，允許跨越特定數目的幀(在 我們的狀況下，1個幀)的最大比特速率。舉例而言，在圖6c的狀況下，若對編碼施加CBR 約束(其將比特速率限于(例如)額定最大數據速率621的70% )，則壓縮算法將限制所 述幀中的每一者的壓縮，以使得通常將使用額定最大數據速率621的70%以上來壓縮的任 何幀將以較少比特來壓縮。這個結果是將使通常將需要更多比特來維持給定質量水平的 幀“極度缺乏”比特且所述幀的圖像質量將比不需要比額定最大數據速率621的70%多的 比特的其他幀的圖像質量糟。此方法對于特定類型的經壓縮視頻(其中(a)預期較少運動 或場景改變且(b)用戶可接受周期性的質量降級)可產生可接受的結果。適合CBR的應用 的良好實例為視頻電話會議，因為存在較少峰值，且在質量暫時降級的情況下(例如，若使 相機掃視，從而導致顯著場景運動及大峰值，則在掃視期間可能不存在足夠的比特用于高 質量圖像壓縮，其將導致降級的圖像質量)，大多數用戶可接受。很遺憾地，CBR并非良好地 適合具有高復雜度的場景或大量運動和/或需要合理恒定的質量水平的許多其他應用。在一個實施例中所使用的低延時壓縮邏輯404使用若干不同技術來解決流動低 延時經壓縮視頻同時維持高質量的許多問題。首先，低延時壓縮邏輯404僅產生I幀及P 幀，從而緩解等待若干個幀時間來解碼每個B幀的需要。另外，如圖7a中所說明，在一個實 施例中，低延時壓縮邏輯404將每個未經壓縮的幀701-760再分成一系列“圖像塊(tile) ” 且將每個圖像塊個別地編碼為I幀或P幀。在本文中將該群經壓縮的I幀及P幀稱作“R 幀”711-770。在圖7a中所顯示的特定實例中，將每個未經壓縮的幀再分成4X4矩陣的16 個圖像塊。然而，所述基本原理不限于任何特定再分機制。在一實施例中，低延時壓縮邏輯404將視頻幀劃分成許多圖像塊，且將來自每個幀的一個圖像塊編碼(也即，壓縮)為I幀(也即，將該圖像塊壓縮，好像其為全圖像的大 小的1/16的單獨視頻幀，且用于此“迷你型”巾貞的壓縮為I幀壓縮)并將剩余圖像塊編碼為 P幀(也即，用于每個“迷你型” 1/16幀的壓縮為P幀壓縮)。經壓縮為I幀的圖像塊及經 壓縮為P幀的圖像塊將分別被稱作“I圖像塊”及“P圖像塊”。隨著每個相繼視頻幀而改變 待編碼為I圖像塊的圖像塊。因此，在給定幀時間中，視頻幀中的所述圖像塊中僅一個圖像 塊為I圖像塊，且所述圖像塊中的剩余者為P圖像塊。舉例而言，在圖7a中，未經壓縮的幀 701的圖像塊0經編碼為I圖像塊IO且剩余的1-15圖像塊經編碼為P圖像塊(Pl至P15) 以產生R幀711。在下一個未經壓縮的視頻幀702中，未經壓縮的幀701的圖像塊1經編碼 為I圖像塊Il且剩余的圖像塊0及2至15經編碼為P圖像塊(P0，及P2至P15)以產生R 幀712。因此，用于圖像塊的I圖像塊及P圖像塊在相繼幀上逐漸地在時間上交錯。該過 程繼續，直至產生R圖像塊770 (矩陣中最末圖像塊經編碼為I圖像塊(也即，115))為止。 該過程接著重新開始，從而產生諸如幀711(也即，對于圖像塊0，編碼I圖像塊)等的另一 個R幀。盡管圖7a中未說明，但在一個實施例中，R幀的視頻序列的第一 R幀僅含有I圖 像塊(也即，以使得隨后的P幀具有參考圖像數據(自其開始計算運動))。或者，在一實施 例中，啟動序列使用與正常相同的I圖像塊型樣，但不包括用于尚未連同I圖像塊一起編碼 的所述圖像塊的P圖像塊。換言之，在第一I圖像塊到達之前不連同任何數據一起編碼特 定圖像塊，從而避免圖9a中的視頻流數據速率934中的啟動峰值，其在下文進一步詳細說 明。此外，如下所述，各種不同大小及形狀可用于所述圖像塊同時仍遵守所述基本原理。在客戶端415上執行的視頻解壓縮邏輯412解壓縮每個圖像塊，好像其為小I幀 及P幀的單獨視頻序列，且接著將每個圖像塊再現給驅動顯示設備422的幀緩沖器。舉例 而言，使用來自R幀711至770的IO及PO來解壓縮并再現視頻圖像的圖像塊0。類似地， 使用來自R幀711至770的Il及Pl來重建圖像塊1，等等。如上所述，I幀及P幀的解壓 縮是這項技術中眾所熟知的，且I圖像塊及P圖像塊的解壓縮可通過使視頻解壓縮器的多 個執行個體在客戶端415上執行來完成。盡管倍增過程看來似乎增加客戶端415上的計算 負擔，但實際上其不會增加客戶端415上的計算負擔，因為圖像塊本身成比例地較小(相對 于額外處理的數目而言)，因此所顯示的像素的數目相同，好像存在一個處理且使用傳統的 全大小的I幀及P幀。該R幀技術顯著減輕通常與I幀相關聯的帶寬峰值(圖6b及圖6c中所說明)，因 為任何給定幀主要是由通常比I幀小的P幀構成。舉例而言，再次假定典型I幀為160Kb， 則圖7a中所說明的幀中的每一者的I圖像塊將為該量的大致1/16或10Kb。類似地，假定 典型P幀為16Kb，則用于圖7a中所說明的圖像塊中的每一者的P幀可為大致1Kb。最終結 果為約10Kb+15*lKb = 25Kb的R幀。因此，每一 60幀序列將是25Kb*60 = 1. 5Mbps。因 此，在60幀/秒下，這將需要能夠維持1. 5Mbps的帶寬的信道，但由于I圖像塊是貫穿60 幀間隔而分散而使得具有低得多的峰值。注意，在先前實例中，在用于I幀及P幀的相同假定數據速率情況下，平均數據速 率為1. 1Mbps。這是因為在先前實例中，每隔60個幀時間僅引入新I幀，而在此實例中，構 成I幀的16個圖像塊在16個幀時間中循環，且因此，每隔16個幀時間引入I幀的均等物， 從而導致稍高的平均數據速率。盡管如此，但在實踐中，引入更頻繁的I幀并不會線性地增 加數據速率。這是由于以下事實P幀(或P圖像塊)主要編碼自先前幀至下一個幀的差異。因此，若先前幀與下一個幀相當類似，則P幀將非常小，若先前幀與下一個幀相當不同， 則P幀將非常大。但因為P幀很大程度上是自先前幀導出，而非自實際幀導出，所以所得的 經編碼幀可能含有比具有足夠數目的比特的I幀多的錯誤(例如，視覺假影)。此外，當一 個P幀跟隨另一 P幀時，可出現錯誤累加(當存在長P幀序列時，變得更糟)。現在，尖端的 視頻壓縮器將偵測到圖像的質量在一序列P幀的后降級的事實，且必要時，其將更多比特 分配給隨后的P幀以提高質量，或若其為最有效的動作過程，則用I幀替換P幀。因此，當 使用長P幀序列(例如，59個P幀，如上文先前實例中)時，特定言的當場景具有大量復雜 度和/或運動時，通常，對于P幀而言需要更多比特(因為其變得距I幀更遠)。或者，自相對觀看點看P幀，緊密地跟隨I幀的P幀傾向于需要比距I幀更遠的P 幀少的比特。因此，在圖7a中所顯示的實例中，沒有P幀比距I幀隔開15個幀更遠(在I 幀之前)，而在先前實例中，P幀可能從I幀隔開59個幀。因此，在更頻繁的I幀情況下，P 幀較小。當然，確切相對大小將基于視頻流的性質而改變，但在圖7a的實例中，若I圖像塊 為10Kb，則P圖像塊的大小平均可為僅0. 75kb，從而導致10Kb+15*0. 75Kb = 21. 25Kb，或在 60幀/秒下，數據速率將為21. 25Kb*60 = 1. 3Mbps，或比1. IMbps下的具有I幀隨后跟著 59個P幀的流的數據速率高約16%。再一次，用于視頻壓縮的所述兩種方法之間的相對結 果將視視頻序列而改變，但通常，我們憑經驗發現，對于給定質量水平，使用R幀比使用I/P 幀序列需要多約20%的比特。但是，當然，R幀急劇地減少峰值，這使視頻序列在遠小于I/ P幀序列的延時下可用。可視視頻序列的性質、信道的可靠性及可用數據速率而以多種不同方式來配置R 幀。在替代實施例中，在4X4配置中使用不同于16的數目的圖像塊。舉例而言，可在2X1 或1X2配置中使用2個圖像塊，可在2X2、4X1或1X4配置中使用4個圖像塊，可在3X2、 2X3、6X1或1X6配置中使用6個圖像塊或可在4X2(如圖7b中所顯示)、2X4、8X 1或 1 X 8配置中使用8個圖像塊。注意，圖像塊不需要為方形，視頻幀也不必為方形，或甚至矩 形。可將圖像塊分解成最佳地適合所使用的視頻流及應用程序的無論什么形狀。在另一實施例中，I圖像塊及P圖像塊的循環不鎖定到圖像塊的數目。舉例而言， 在8圖像塊4X2配置中，仍可如圖7b中所說明而使用16循環序列。順序的未經壓縮的幀 721、722、723各自經劃分成8個圖像塊0_7，且每個圖像塊被個別壓縮。自R幀731，僅圖 像塊0被壓縮為I圖像塊，且剩余圖像塊被壓縮為P圖像塊。對于隨后的R幀732，所有8 個圖像塊被壓縮為P圖像塊，且接著對于隨后的R幀733，圖像塊1被壓縮為I圖像塊且其 他圖像塊均被壓縮為P圖像塊。此外，如此對于16個幀繼續進行排序，僅每隔一幀產生一 個I圖像塊，因此在第15個幀時間期間(圖7b中未圖示)及在第16個幀時間期間產生用 于圖像塊7的最末I圖像塊(使用所有的P圖像塊壓縮R幀780)。接著，序列再次以圖像 塊0被壓縮為I圖像塊且其他圖像塊被壓縮為P圖像塊開始。如在先前實施例中，整個視 頻序列的第一幀通常將均為I圖像塊，以提供用于從該點向前的P圖像塊的參考。I圖像 塊及P圖像塊的循環甚至不需要為圖像塊的數目的偶倍數。舉例而言，在8個圖像塊的情 況下，在使用另一 I圖像塊之前，具有一個I圖像塊的每一幀之后可為所有都為P圖像塊的 2個幀。在又一實施例中，若(例如)已知屏幕的特定區域具有更多運動(需要更頻繁的I 圖像塊)，而其他區域更為靜態(例如，顯示游戲的分數)(需要較不頻繁的I圖像塊)，則 與其他圖像塊相比，可更經常地將特定圖像塊連同I圖像塊一起進行排序。此外，盡管在圖7a-圖7b中說明每個幀具有單個I圖像塊，但可在單個幀中編碼多個I圖像塊(取決于傳 輸信道的帶寬)。相反地，特定幀或幀序列可在不具有I圖像塊(也即，僅P圖像塊)的情 況下傳輸。前一段的方法適當起作用的原因在于盡管不具有跨越每個單個幀而分散的I圖 像塊看來似乎導致較大峰值，但系統的行為并不如此簡單。因為每個圖像塊是與其他圖像 塊分開進行壓縮，所以當圖像塊變小時，每個圖像塊的編碼可變得較不有效，因為給定圖像 塊的壓縮器不能夠利用來自其他圖像塊的類似圖像特征及類似運動。因此，與將屏幕劃分 成8個圖像塊相比較，將屏幕劃分成16個圖像塊通常將導致較不有效的編碼。但是，若將 屏幕劃分成8個圖像塊且其引起每隔8個幀(而非每隔16個幀)引入一個完全I幀的數 據，則其導致總體上高得多的數據速率。因此，通過每隔16個幀(而非每隔8個幀)引入 一個完全I幀，減小了總數據速率。而且，通過使用8個較大圖像塊(而非16個較小圖像 塊)，減小了總數據速率，其也將由較大圖像塊引起的數據峰值減輕至某種程度。在另一實施例中，圖7a及圖7b中的低延時視頻壓縮邏輯404通過基于待壓縮的 視頻序列的已知特性而通過設定預先配置或者基于每個圖像塊中的圖像質量的正在進行 的分析而自動地控制至R幀中的各圖像塊的比特的分配。舉例而言，在一些競賽視頻游戲 中，玩家的汽車(其為場景中相對無運動的)的前方占據屏幕的下半部的大部分，而屏幕 的上半部完全被填滿正接近的道路、建筑物及風景，其幾乎總是在運動中。若壓縮邏輯404 將相等數目的比特分配給每個圖像塊，則圖7b中的未經壓縮的幀721中的屏幕的下半部 上的圖像塊(圖像塊4-7)通常將以比圖7b中的未經壓縮的幀721中的屏幕的上半部中的 圖像塊(圖像塊0-3)高的質量而壓縮。若已知該特定游戲或游戲的此特定場景具有所述 特性，則主機服務210的運營商可配置壓縮邏輯404以將更多比特分配給屏幕的頂部的圖 像塊(與分配給屏幕的底部處的圖像塊的比特相比)。或者，壓縮邏輯404可在壓縮幀之 后估計圖像塊的壓縮質量(使用許多壓縮質量度量中的一者或多者，諸如峰值信號噪音比 (PSNR))，且若確定在特定時間窗上，特定圖像塊始終如一地產生較佳質量結果，則其逐漸 地將更多比特分配給產生較低質量結果的圖像塊，直至各種圖像塊達到類似水平的質量為 止。在替代實施例中，壓縮器邏輯404分配比特以在特定圖像塊或圖像塊群中達成較高質 量。舉例而言，其可提供較佳的總體感知外觀，以在屏幕的中心具有比邊緣處高的質量。在一個實施例中，為了改良視頻流的特定區域的分辨率，視頻壓縮邏輯404使用 較小圖像塊來編碼視頻流的具有相對多的場景復雜度和/或運動的區域(與視頻流的具 有相對少的場景復雜度和/或運動的區域相比)。舉例而言，如圖8中所說明，在一個R幀 811 (可能隨后跟著具有相同圖像塊大小的一系列R幀(未圖示))的一個區域中的移動人 物805的周圍使用較小圖像塊。接著，當人物805移動至圖像的新區域時，在另一 R幀812 內的此新區域的周圍使用較小圖像塊，如所說明。如上所述，各種不同大小及形狀可用作 “圖像塊”同時仍遵守所述基本原理。盡管上文所描述的循環I/P圖像塊實質上減小視頻流的數據速率中的峰值，但其 并不完全消除峰值，尤其在快速改變或高度復雜的視頻圖像(諸如在電影、視頻游戲及某 一應用程序軟件下出現)的狀況下。舉例而言，在突然場景轉變期間，復雜幀可能隨后跟著 完全不同的另一復雜幀。即使若干個I圖像塊可領先于場景轉變僅幾個幀時間，其在該情 形下也沒有幫助，因為新幀的材料與先前I圖像塊無關。在這種情形下(及在即使并非一
34切都改變，大量圖像也改變的其他情形下)，視頻壓縮器404將確定將許多(若并非所有)P 圖像塊更有效地寫碼為I圖像塊，且所導致的是所述幀的數據速率中的非常大的峰值。如先前所論述，其僅為對于大多數消費者級互聯網連接(及許多辦公室連接)的 狀況，其僅不可“堵塞”超過圖6c中顯示為622的可用最大數據速率以及額定最大數據速 率621的數據。注意，額定最大數據速率621 (例如，“6Mbps DSL”)實質上為對于考慮購買 互聯網連接的用戶的銷售數字，但通常其不保證性能水平。出于該應用的目的，其是不相關 的，因為我們僅關注經由連接使視頻流動時的可用最大數據速率622。因此，在圖9a及圖 9c中，當描述對峰值問題的解決方法時，自曲線圖省略額定最大數據速率，且僅顯示可用最 大數據速率922。視頻流數據速率不得超過可用最大數據速率922。為了解決此問題，視頻壓縮器404進行的第一件事是確定峰值數據速率941，其為 信道能夠穩定地處理的數據速率。該速率可通過許多技術來確定。一種該技術是將越加變 高的數據速率測試流自主機服務210逐漸發送至客戶端415 (圖4a及圖4b中)，且使客戶 端將關于分組丟失及延時的水平的反饋提供至主機服務。當分組丟失和/或延時開始顯示 尖銳增加時，其為達到可用最大數據速率922的指示。之后，主機服務210可逐漸地減小測 試流的數據速率，直至客戶端415報告在合理的時間周期中已接收到測試流(分組丟失及 延時的可接受水平接近最小)為止。這確定峰值最大數據速率941，其接著將用作用于流動 視頻的峰值數據速率。隨著時間的推移，峰值數據速率941將波動(例如，若家庭中的另一 用戶開始嚴重地使用互聯網連接)，且客戶端415將需要恒定地監視峰值數據速率941以觀 看分組丟失或延時是否增加(指示可用最大數據速率922下降至低于先前所確定的峰值數 據速率941)，且若如此，則峰值數據速率941。類似地，若隨著時間的推移，客戶端415發現 分組丟失及延時保持在最佳水平，則其可請求視頻壓縮器緩慢地增加數據速率以觀看可用 最大數據速率是否增加(例如，若家庭中的另一用戶已停止對互聯網連接的嚴重使用)，且 再次等待直至分組丟失和/或較高延時指示已超過可用最大數據速率922為止，且可再次 發現用于峰值數據速率941的較低水平，但該較低水平可能高于測試增加的數據速率之前 的水平。因此，可通過使用該技術(及類似其的其他技術)而發現峰值數據速率941，且視 需要而周期性地進行調整。峰值數據速率941確定可由視頻壓縮器404使用以使視頻流動 至用戶的最大數據速率。用于確定峰值數據速率的邏輯可在用戶場所211處和/或在主機 服務210上加以實施。在用戶場所211處，客戶端設備415執行計算以確定峰值數據速率 且將此信息傳輸回至主機服務210 ；在主機服務210處，主機服務處的服務器402執行計算 以基于自客戶端415所接收的統計數據(例如，峰值丟失、延時、最大數據速率等)而確定 峰值數據速率。圖9a顯示具有實質場景復雜度和/或運動的實例視頻流數據速率934，其是使用 先前所描述且在圖7a、圖7b及圖8中加以說明的循環I/P圖像塊壓縮技術而產生。視頻 壓縮器404經配置而以低于峰值數據速率941的平均數據速率輸出經壓縮的視頻，且注意， 大部分時間，視頻流數據速率保持低于峰值數據速率941。數據速率934與圖6c中所顯示 的視頻流數據速率634 (其是使用I/P/B或I/P幀而產生)的比較顯示循環I/P圖像塊壓 縮產生平滑得多的數據速率。但在幀2倍峰值952 (其接近2倍峰值數據速率942)及幀4 倍峰值954 (其接近4倍峰值數據速率944)下，數據速率仍超過峰值數據速率941，這是不 可接受的。在實踐中，即使對于來自快速改變的視頻游戲的高動作視頻，超過峰值數據速率
35941的峰值也在小于2%的幀中出現，超過2倍峰值數據速率942的峰值很少出現，且超過 3倍峰值數據速率943的峰值難得出現。但是，當其確實出現時(例如，在場景轉變期間)， 其所需的數據速率必須產生良好質量的視頻圖像。解決此問題的一個方式是簡單地配置視頻壓縮器404以使得其最大數據速率輸 出為峰值數據速率941。遺憾地，峰值幀期間的所得視頻輸出質量不良，因為壓縮算法“極 度缺乏”比特。所導致的為當存在突然轉變或快速運動時出現壓縮假影，且及時地，用戶開 始認識到當存在突然改變或快速運動時假影總是突然出現，且其可變得相當討厭。盡管人的視覺系統對在突然改變或快速運動期間出現的視覺假影相當敏感，但對 在所述情形下偵測到幀速率的減小并不是非常敏感。事實上，當所述突然改變出現時，看來 似乎人的視覺系統專注于追蹤所述改變，且若幀速率暫時從60fps下降到30fps且接著立 即返回到60fps，則人的視覺系統不會注意到。此外，在非常急劇的轉變(如突然場景改變) 的狀況下，若幀速率下降到20fps或甚至15fps且接著立即返回到60fps，則人的視覺系統 不會注意到。只要幀速率減小僅偶爾出現，對于人觀察者而言，看來似乎視頻以60fps不斷 地執行。通過圖9b中所說明的技術來利用人的視覺系統的此特性。服務器402 (來自圖4a 及圖4b)以穩定幀速率(在一個實施例中，在60fps下)產生未經壓縮的視頻輸出流。時間 線顯示每個1/60秒每個幀961-970輸出。自幀961開始，將每個未經壓縮的視頻幀輸出至 低延時視頻壓縮器404，低延時視頻壓縮器404在小于一幀時間的時間中壓縮所述幀，產生 用于第一幀的經壓縮的幀1981。經產生用于經壓縮的幀1981的數據可視如先前所描述的 許多因素而較大或較小。若數據足夠小以致可以峰值數據速率941在一幀時間(1/60秒) 或小于一幀時間內將其傳輸至客戶端415，則在傳輸時間(xmit時間)991(指示傳輸時間的 持續時間的箭頭的長度)期間將其傳輸。在下一個幀時間中，服務器402產生未經壓縮的 幀2962，將其壓縮成經壓縮的幀2982，且在小于一幀時間的傳輸時間992期間以峰值數據 速率941將其傳輸至客戶端415。接著，在下一個幀時間中，服務器402產生未經壓縮的幀3963。當由視頻壓縮器 404來壓縮未經壓縮的幀3963時，所得的經壓縮的幀3983為比可以峰值數據速率941在一 幀時間中傳輸的數據多的數據。因此，在傳輸時間(2倍峰值)993期間將其傳輸，其占據所 有幀時間及下一個幀時間的一部分。現在，在下一個幀時間期間，服務器402產生另一未經 壓縮的幀4964且將其輸出至視頻壓縮器404，但數據被忽略且通過974來說明。這是因為 視頻壓縮器404經配置以忽略在其仍傳輸先前經壓縮的幀時到達的其他未經壓縮的視頻 幀。當然，客戶端415的視頻解壓縮器將未能接收到幀4，但其簡單地繼續在顯示設備422 上顯示幀3歷時2個幀時間(也即，暫時將幀速率自60fps減小至30fps)。對于下一個幀5，服務器402輸出未經壓縮的幀5965，將其壓縮成經壓縮的幀5985 且在傳輸時間995期間在1幀內將其傳輸。客戶端415的視頻解壓縮器解壓縮幀5并將其 顯示于顯示設備422上。接著，服務器402輸出未經壓縮的幀6966，視頻壓縮器404將其壓 縮成經壓縮的幀6986，但此時所得的數據非常大。在傳輸時間(4倍峰值)996期間以峰值 數據速率941傳輸經壓縮的幀，但花費幾乎4個幀時間來傳輸幀。在接下來的3個幀時間期 間，視頻壓縮器404忽略來自服務器402的3個幀，且客戶端415的解壓縮器將幀6穩定地 保持在顯示設備422上歷時4個幀時間(也即，暫時將幀速率自60fps減小至15fps)。接著最后，服務器402輸出幀10970，視頻壓縮器404將其壓縮成經壓縮的幀10987，且在傳輸 時間997期間將其傳輸，且客戶端415的解壓縮器解壓縮幀10并將其顯示于顯示設備422 上且再一次視頻以60fps重新開始。注意，盡管視頻壓縮器404丟棄了來自由服務器402產生的視頻流的視頻幀，但其 不會丟棄音頻數據(不管音頻是以什么形式來的)，且當丟棄視頻幀時視頻壓縮器404繼 續壓縮音頻數據并將其傳輸至客戶端415，客戶端415繼續解壓縮音頻數據并將音頻提供 至由用戶使用以回放音頻的無論什么設備。因此在丟棄幀的周期期間，音頻繼續而不減弱。 與經壓縮的視頻相比，經壓縮的音頻消耗相對小百分比的帶寬，且因此不會對總數據速率 有較大影響。盡管在數據速率圖中的任一者中都未說明，但峰值數據速率941內總是存在 經保留用于經壓縮音頻流的數據速率容量。選擇剛剛在圖9b中所描述的實例來說明在數據速率峰值期間幀速率如何下降， 但未說明的是當使用先前所描述的循環I/P圖像塊技術時，所述數據速率峰值及隨的發生 的丟棄的幀很少，即使在高場景復雜度/高動作序列(諸如在視頻游戲、電影及某個應用程 序軟件中出現的那些)期間也如此。因此，減小的幀速率罕有且暫時，且人的視覺系統不會 偵測到它們。若將剛剛所描述的幀速率減小機制應用于圖9a中所說明的視頻流數據速率，則 在圖9c中說明所得的視頻流數據速率。在此實例中，2倍峰值952已減小至平坦化的2倍 峰值953，且4倍峰值955已減小至平坦化的4倍峰值955，且整個視頻流數據速率934保 持處于或低于峰值數據速率941。因此，使用上文所描述的技術，可經由通用互聯網及消費者級互聯網連接而以低 延時來傳輸高動作視頻流。另外，在LAN(例如，IOOMbs以太網或802. Ilg無線網絡)上或私 用網絡(例如，數據中心與辦公室之間的IOOMbps連接)上的辦公室環境中，可在無峰值情 況下傳輸高動作視頻流，以使得多個用戶(例如，以4. 5Mbps傳輸60fps下的1920X 1080) 可使用LAN或共用私用數據連接，而不使重迭峰值淹沒(overwhelm)網絡或網絡交換器底 板。數據速率調整在一個實施例中，主機服務210最初評估信道的可用最大數據速率622及延時以 確定用于視頻流的適當數據速率且接著響應于此而動態地調整數據速率。為了調整數據速 率，主機服務210可(例如)修改待發送至客戶端415的視頻流的圖像分辨率和/或每秒 幀數。而且，主機服務可調整經壓縮視頻的質量水平。當改變視頻流的分辨率時(例如，自 1280 X 720分辨率至640 X 360)，客戶端415上的視頻解壓縮邏輯412可將圖像按比例增加 以在顯示屏幕上維持相同圖像大小。在一個實施例中，在信道完全退出的情形下，主機服務210將游戲暫停。在多人游 戲的狀況下，主機服務向其他用戶報告該用戶已退出游戲和/或將游戲暫停以用于其他用戶。丟棄或延遲的分組在一個實施例中，若數據由于圖4a或圖4b中的視頻壓縮器404與客戶端415之間 的分組丟失而丟失，或由于到達得過晚以致不能解壓縮及滿足經解壓縮幀的延時要求的分 組被無次序地接收而丟失，則視頻解壓縮邏輯412能夠減輕視覺假影。在流動I/P幀實施
37中，若存在丟失/延遲的分組，則整個屏幕受影響，從而可能引起屏幕完全凍結一段時間周 期或顯示其他屏幕寬視覺假影。舉例而言，若丟失/延遲的分組引起I幀的丟失，則在接收 新的I幀之前，解壓縮器將缺乏用于跟隨的所有P幀的參考。若丟失P幀，則其將影響跟隨 的用于整個屏幕的P幀。視I幀出現之前有多久，這將具有較長或較短的視覺影響。使用 如圖7a及圖7b中所顯示的交錯I/P圖像塊，丟失/延遲的分組不太可能影響整個屏幕，因 為其僅影響受影響的分組中所含有的圖像塊。若每個圖像塊的數據是在個別分組內發送， 則若分組丟失，則其僅影響一個圖像塊。當然，視覺假影的持續時間將取決于I圖像塊分組 是否丟失及在P圖像塊丟失的情況下在I圖像塊出現之前將花費多少個幀。但是，假定屏 幕上的不同圖像塊是通過I幀非常頻繁地(可能每個幀)更新，則即使屏幕上的一圖像塊 受影響，其他圖像塊也可能不受影響。另外，若某一事件引起若干分組同時丟失(例如，鄰 接DSL線的電力中的暫時中斷數據流的尖峰信號)，則一些圖像塊將比其他圖像塊受到更 大影響，但因為一些圖像塊將通過新的I圖像塊迅速地更新，所以其僅暫時受影響。而且， 在流動I/P幀實施的情況下，不僅I幀為最關鍵幀，而且I幀極大，因此若存在引起丟棄/ 延遲的分組的事件，則與小得多的I圖像塊相比，I幀受影響存在較高機率(也即，若I幀 的任何部分丟失，則根本不可能可解壓縮I幀)。由于所有所述原因，與I/P幀的情況相比， 當分組被丟棄/延遲時，使用I/P圖像塊導致小得多的視覺假影。一個實施例試圖通過將經壓縮的圖像塊智能地封裝于TCP(傳輸控制協議)分組 或UDP(用戶數據報協議)分組內而減少丟失分組的效應。舉例而言，在一個實施例中，只 要可能，即將圖像塊與分組邊界對準。圖IOa說明可如何在不實施此特征的情況下將圖像 塊封裝于一系列分組1001-1005內。具體言之，在圖IOa中，圖像塊越過分組邊界且經無效 率地封裝以致單一分組的丟失導致多個幀的丟失。舉例而言，若分組1003或1004丟失，則 丟失三個圖像塊，導致視覺假影。相比之下，圖IOb說明用于將圖像塊智能地封裝于分組內以減少分組丟失的效應 的圖像塊封裝邏輯1010。首先，圖像塊封裝邏輯1010將圖像塊與分組邊界對準。因此，圖 像塊T1、T3、T4、T7及Τ2分別與分組1001-1005的邊界對準。圖像塊封裝邏輯也試圖以可 能的更有效的方式將圖像塊組合于分組內，而不越過分組邊界。基于圖像塊中的每一者的 大小，將圖像塊Tl與Τ6組合于一個分組1001中；將Τ3與Τ5組合于一個分組1002中；將 圖像塊Τ4與Τ8組合于一個分組1003中；將圖像塊Τ8添加至分組1004 ；且將圖像塊Τ2添 加至分組1005。因此，在此方案下，單個分組丟失將導致不多于2個圖像塊(而非如圖IOa 中所說明的3個圖像塊)的丟失。圖IOb中所顯示的實施例的一個額外益處在于圖像塊是以其在圖像內被顯示的 不同次序進行傳輸。若鄰近分組由于干擾傳輸的同一事件(其將影響屏幕上彼此不接近的 區域)而丟失，則此方式在顯示器上產生較不引人注意的假影。一個實施例使用前向糾錯(FEC)技術來保護視頻流的特定部分以使其免受信道 錯誤的影響。如此項技術中已知，諸如里德-所羅門及Viterbi (維特比)的FEC技術產生 糾錯數據信息并將其附加至經由通信信道而傳輸的數據。若錯誤在基本數據(例如，I幀) 中出現，則FEC可用于校正該錯誤。FEC碼增加傳輸的數據速率，因此理想地，其僅在最需要時使用。若數據正被發送， 且其將不導致非常引人注意的視覺假影，則可較佳不使用FEC碼來保護數據。舉例而言，緊接于丟失的I圖像塊之前的P圖像塊將僅在屏幕上產生1/60秒的視覺假影(也即，屏幕上 的圖像塊將不被更新)。此種視覺假影幾乎不能被人眼偵測到。隨著P圖像塊自I圖像塊 進一步向后，丟失P圖像塊越加變得更引人注意。舉例而言，若圖像塊循環型樣為在I圖像 塊再次可用之前I圖像塊隨后跟著15個P圖像塊，則若緊接于I圖像塊之后的P圖像塊丟 失，則其導致該圖像塊顯示不正確的圖像歷時15個幀時間(在60fps下，這將為250毫秒)。 人眼將容易偵測到250毫秒的流的中斷。因此，P圖像塊距新的I圖像塊越向后(也即，P 圖像塊跟隨I圖像塊越接近)，則假影越引人注意。如先前所論述，盡管如此，但一般而言， P圖像塊跟隨I圖像塊越接近，用于該P圖像塊的數據越小。因此，跟隨I圖像塊的P圖像 塊不僅對于保護以免丟失而言更關鍵，而且其大小較小。此外，一般而言，需要保護的數據 越小，保護其所需的FEC碼越小。因此，如圖Ila中所說明，在一個實施例中，由于I圖像塊在視頻流中的重要性，僅 I圖像塊具備FEC碼。因此，FEC 1101含有用于I圖像塊1100的糾錯碼且FEC 1104含有 用于I圖像塊1103的糾錯碼。在此實施例中，對于P圖像塊不產生FEC。在圖lib中所說明的一個實施例中，對于在丟失時最可能引起視覺假影的P圖像 塊也產生FEC碼。在此實施例中，FEC 1105提供用于前3個P圖像塊但不用于跟隨的P圖 像塊的糾錯碼。在另一實施例中，對于數據大小最小的P圖像塊產生FEC碼(其將傾向于 自選在I圖像塊的后最早出現的P圖像塊，其對于保護最為關鍵)。在另一實施例中，并非將FEC碼連同圖像塊一起發送，而是將圖像塊傳輸兩次，每 次在不同分組中傳輸。若一分組丟失/延遲，則使用另一分組。在圖Ilc中所顯示的一個實施例中，產生分別用于與視頻同時自主機服務傳輸的 音頻分組1110及1112的FEC碼1111及1113。維持視頻流中的音頻的完整性特別重要，因 為失真的音頻(例如，滴答聲或嘶嘶聲)將導致特別不合需要的用戶體驗。FEC碼幫助確保 音頻內容在客戶端計算機415處無失真地再現。在另一實施例中，并非將FEC碼連同音頻數據一起發送，而是將音頻數據傳輸兩 次，每次在不同分組中傳輸。若一個分組丟失/延遲，則使用另一分組。另外，在圖Ild中所說明的一個實施例中，FEC碼1121及1123分別用于自客戶 端415上行傳輸到主機服務210的用戶輸入命令(例如，按鈕按壓)1120及1122。這是重 要的，因為在視頻游戲或應用程序中漏掉按鈕按壓或鼠標運動可能導致不合需要的用戶體 驗。在另一實施例中，并非將FEC碼連同用戶輸入命令數據一起發送，而是將用戶輸 入命令數據傳輸兩次，每次在不同分組中傳輸。若一個分組丟失/延遲，則使用另一分組。在一個實施例中，主機服務210評估與客戶端415的通信信道的質量，以確定是否 使用FEC，且若使用，則確定應對視頻、音頻及用戶命令的何部分應用FEC。評估信道的“質 量”可包括如上所述的諸如估計分組丟失、延時等的功能。若信道特別不可靠，則主機服務 210可對所有I圖像塊、P圖像塊、音頻及用戶命令應用FEC。相比之下，若信道可靠，則主 機服務210可僅對音頻及用戶命令應用FEC，或可不對音頻或視頻應用FEC，或可根本不使 用FEC。可使用FEC的應用的各種其他排列，同時仍遵守所述基本原理。在一個實施例中， 主機服務210不斷地監視信道的狀況且相應地改變FEC策略。在另一實施例中，參看圖4a及圖4b，當分組丟失/延遲，從而導致圖像塊數據的丟失時，或若可能由于特別糟的分組丟失而使得FEC不能夠校正丟失的圖像塊數據，客戶端 415評估在將接收新的I圖像塊之前剩余多少個幀且將其與自客戶端415至主機服務210 的來回行程延時相比較。若來回行程延時小于新的I圖像塊應到達之前的幀的數目，則客 戶端415向主機服務210發送消息，請求新的I圖像塊。將此消息路由至視頻壓縮器404， 且其并非產生用于數據已丟失的圖像塊的P圖像塊，而是產生I圖像塊。假定圖4a及圖 4b中所顯示的系統經設計以提供通常小于80毫秒的來回行程延時，則這導致圖像塊被校 正于80毫秒內(在60fps下，幀具有16. 67毫秒的持續時間，因此在全幀時間中，80毫秒 延時將導致83. 33毫秒內的經校正的圖像塊，83. 33毫秒為5個幀時間，其為引人注意的中 斷，但遠不及(例如)對于15個幀250毫秒中斷引人注意)。當壓縮器404脫離其通常的 循環次序而產生此種I圖像塊時，若I圖像塊將引起所述幀的帶寬超過可用帶寬，則壓縮器 404將延遲其他圖像塊的循環，以使得其他圖像塊在所述幀時間期間接收P圖像塊(即使在 所述幀期間一個圖像塊通常將應為I圖像塊)，且接著通常的循環將自下一個幀開始繼續， 且通常將已接收到先前幀中的I圖像塊的圖像塊將接收I圖像塊。盡管此動作暫時延遲R 幀循環的階段，但其通常將在視覺上不引人注意。視頻及音頻壓縮器/解壓縮器實施圖12說明一個特定實施例，其中使用多核和/或多處理器1200來并行地壓縮8個 圖像塊。在一實施例中，使用在2. 66GHz或更高下執行的雙核處理器、四核Xeon (至強)CPU 計算機系統，每個核心作為獨立過程實施開源x264 H. 264壓縮器。然而，可使用各種其他 硬件/軟件配置，同時仍遵守所述基本原理。舉例而言，CPU核心中的每一者可通過以FPGA 實施的H. 264壓縮器來替換。在圖12中所顯示的實例中，核心1201-1208用于作為八個獨 立線緒來同時處理I圖像塊及P圖像塊。如此項技術中眾所周知的，當前多核及多處理器 計算機系統與諸如Microsoft Windows XP專業版(64比特版或者32比特版)及Linux的 多線緒處理操作系統整合時，其固有地能夠進行多線緒處理。在圖12中所說明的實施例中，因為該8個核心中的每一者僅負責一個圖像塊， 所以其很大程度上獨立于其他核心而操作，每一者執行x264的單獨實例化。使用以PCI Express xl 為基礎的 DVI 捕獲卡(諸如，來自 Netherlands 的Microtronix of Oosterhout 的Sendero視頻成像IP開發板)來捕獲640X480、800X600或1280X720分辨率下的未 經壓縮的視頻，且卡上的FPGA使用直接存儲器存取(DMA)來將所捕獲的視頻經由DVI總線 傳送至系統RAM中。將所述圖像塊配置成4X2配置1205 (盡管其說明為方形圖像塊，但在 該實施例中，其具有160 X 240分辨率)。x264的每個實例化被配置成壓縮該8個160 X 240 圖像塊中的一者，且其經同步化以使得在初始I圖像塊壓縮的后每一核心進入一循環，每 一幀與另一幀不同相，以壓縮一 I圖像塊繼的以七個P圖像塊，如圖12中所說明。在每一幀時間，使用先前所描述的技術將所得的經壓縮圖像塊組合成分組流，且 接著將經壓縮圖像塊傳輸至目的地客戶端415。盡管圖12中未說明，但若組合的8個圖像塊的數據速率超過指定峰值數據速率 941，則所有8個x264過程將暫時中止歷時達必要的幀時間，直至已傳輸用于組合的8個圖 像塊的數據為止。在一個實施例中，將客戶端415實施為執行FFmpeg的8個實例化的PC上的軟件。 接收過程接收8個圖像塊，且將每一圖像塊路由至FFmpeg實例化，FFmpeg實例化解壓縮圖像塊并將其再現至顯示設備422上的適當圖像塊位置。客戶端415接收來自PC的輸入設備驅動器的鍵盤、鼠標或游戲控制器輸入并將其 傳輸到服務器402。服務器402接著應用所接收的輸入設備數據并將其應用于在服務器402 上執行的游戲或應用程序，服務器402為使用Intel 2. 16GHz雙核CPU執行Windows的PC。 服務器402接著產生新幀并經由其DVI輸出端將新幀自以主機板為基礎的圖形系統或者經 由 NVIDIA8800GTX PCI Express 卡的 DVI 輸出端輸出。同時，服務器402經由其數字音頻輸出端(例如，S/PDIF)輸出由游戲或應用程序 產生的音頻，該數字音頻輸出端耦合至實施視頻壓縮的以雙四核Xeon為基礎的PC上的數 字音頻輸入端。Vorbis開源音頻壓縮器用于使用可用于處理線緒的無論什么核心來與視頻 同時地壓縮音頻。在一個實施例中，完成壓縮其圖像塊的核心首先執行音頻壓縮。接著將 經壓縮的音頻連同經壓縮的視頻一起傳輸，并在客戶端415上使用Vorbis音頻解壓縮器來 解壓縮經壓縮的音頻。主機服務服務器中心分配經由玻璃(諸如，光纖)的光以光在真空中的速度的某一部分行進，且因此可確定 光在光纖中的確切傳播速度。但是，在實踐中，考慮用于路由延遲、傳輸無效率及其他耗用 的時間，我們觀察到互聯網上的最佳延時反映較接近光速的50%的傳輸速度。因此，最佳 1000英里來回行程延時為約22毫秒，且最佳3000英里來回行程延時為約64毫秒。因此， 一美國海岸上的單個服務器將距離過遠以致不能以所要的延時伺服另一海岸上的客戶端 (其可能達3000英里遠)。然而，如圖13a中所說明，若主機服務210服務器中心1300定位 于美國的中心(例如，堪薩斯州、內布拉斯加州等)，以致至美國大陸中的任何點的距離為 約1500英里或1500英里以下，來回行程互聯網延時可低至32毫秒。參看圖4b，注意盡管 用戶ISP 453所允許的最糟狀況延時為25毫秒，但通常，在DSL及電纜調制解調器系統的 情況下我們觀察到較接近10-15毫秒的延時。而且，圖4b假定自用戶場所211至主機代管 中心210的最大距離為1000英里。因此，在所使用的典型的15毫秒的用戶ISP來回行程延 時及對于32毫秒的來回行程延時的1500英里的最大互聯網距離的情況下，自用戶致動輸 入設備421的時刻至在顯示設備422上看見響應的總來回行程延時為1+1+15+32+1+16+6+8 =80毫秒。因此，通常可在1500英里的互聯網距離上達成80毫秒響應時間。這將允許美 國大陸中具有足夠短的用戶ISP延時453的任何用戶場所存取在中心定位的單個服務器中 心。在圖13b中所說明的另一實施例中，主機服務210服務器中心HS1-HS6戰略上定 位于美國(或其他地理區域)的周圍，特定較大的主機服務服務器中心接近高人口中心而 定位(例如，HS2及HS5)。在一個實施例中，服務器中心HS1-HS6經由網絡1301交換信息， 網絡1301可為互聯網或私用網絡或兩者的組合。在多個服務器中心的情況下，可以較低延 時向具有高用戶ISP延時453的用戶提供服務。盡管互聯網上的距離的確為對經由互聯網的來回行程延時有影響的因素，但有時 很大程度上與延時無關的其他因素也起作用。有時經由互聯網將分組流路由至距離遠的位 置且再次返回，從而導致來自長循環的延時。有時在路徑上存在不適當操作的路由設備，從 而導致傳輸的延遲。有時存在使路徑超載的通信，其引入延遲。此外，有時，根本是存在防 止用戶的ISP路由至給定目的地的故障。因此，盡管通用互聯網通常以相當可靠且最佳的
41路由及延時來提供從一點到另一點的連接，該相當可靠且最佳的路線及延時很大程度上是 通過距離來確定(尤其是在導致路由至用戶的本地區域的外部的長距離連接的情況下)， 但該可靠性及延時得不到任何保證且常常不可自用戶的場所至通用互聯網上的給定目的 地而達成。在一個實施例中，當用戶客戶端415最初連接到主機服務210以玩視頻游戲或使 用應用程序時，客戶端在啟動時與可用的主機服務服務器中心HS1-HS6中的每一者通信 (例如，使用上文所描述的技術)。若延時對于特定連接而言足夠低，則使用該連接。在一 個實施例中，客戶端與所有主機服務服務器中心或主機服務服務器中心的一個子集通信， 選擇具有最低延時連接的主機服務服務器中心。客戶端可選擇具有最低延時連接的服務中 心，或服務器中心可識別具有最低延時連接的服務器中心并將此信息(例如，以互聯網地 址的形式)提供給客戶端。若特定主機服務服務器中心超載和/或用戶的游戲或應用程序可容忍至另一、較 少載入的主機服務服務器中心的延時，則可將客戶端415重定向至另一主機服務服務器中 心。在此種情形下，將使用戶正執行的游戲或應用程序在用戶的超載服務器中心處的服務 器402上暫停，且將游戲或應用程序狀態數據傳送至另一主機服務服務器中心處的服務器 402。接著將重新開始該游戲或應用程序。在一個實施例中，主機服務210將等待直至游戲 或應用程序達到自然暫停點(例如，游戲中的級別之間，或者在用戶在應用程序中起始“保 存”操作之后)才進行傳送。在又一實施例中，主機服務210將等待直至用戶活動停止歷時 指定時間周期(例如，1分鐘)為止且接著將在這時起始傳送。如上所述，在一個實施例中，主機服務210訂閱圖14的互聯網旁路服務440以試 圖將得到保證的延時提供給其客戶端。如本文中所使用的互聯網旁路服務是提供自互聯網 上的一點至另一點的具有得到保證的特性(例如，延時、數據速率等)的私用網絡路線的服 務。舉例而言，若主機服務210正使用在圣弗朗西斯科提供的AT&T的DSL服務接收來自 用戶的大量通信(而非路由至以AT&T的圣弗朗西斯科為基地的中央辦公室)，則主機服務 210將在以圣弗朗西斯科為基地的中央辦公室與用于主機服務210的服務器中心中的一或 多者之間租用來自服務提供者(可能為AT&T本身或另一提供者)的高容量私用數據連接。 接著，若自所有主機服務服務器中心HS1-HS6經由通用互聯網至圣弗朗西斯科中使用AT&T DSL的用戶的路線導致過高延時，則可改為使用私用數據連接。盡管私用數據連接通常比經 由通用互聯網的路線更昂貴，但只要其保持主機服務210的一小百分比連接至用戶，總成 本影響就低，且用戶將體驗到更一貫的服務體驗。在電力故障的情況下，服務器中心常常具有兩個備用電力層。第一層通常為來自 電池(或來自替代的立即可用的能量源，諸如保持運轉且附接至發電機的飛輪)的備用電 力，其在電力干線出故障時立即提供電力且保持服務器中心運轉。若電力故障為暫時的，且 電力干線迅速返回(例如，在一分鐘內)，則電池所需的是保持服務器中心運轉。但若電力 故障歷時較長的時間周期，則通常啟動發電機(例如，柴油機供電)來取代電池且發電機只 要具有燃料即可運轉。所述發電機極昂貴，因為其必須能夠產生多達服務器中心通常自電 力干線所得到的電力。在一個實施例中，主機服務HS1-HS5中的每一者彼此共用用戶數據，以便在一個 服務器中心具有電力故障時，其可將在進行中的游戲及應用程序暫停，且接著將游戲或應
42用程序狀態數據自每個服務器402傳送至其他服務器中心處的服務器402，且接著將通知 每一用戶的客戶端415以指導其傳達至新的服務器402。假定所述情形偶爾出現，則將用戶 轉移至不能夠提供最佳延時的主機服務服務器中心(也即，用戶將僅必須容忍較高延時歷 時電力故障的持續時間)可為可接受的，其將允許用于轉移用戶的寬得多的范圍的選項。 舉例而言，給定跨越美國的時區差，則東海岸上的用戶在11 30PM可能將要睡眠，而西海岸 上的用戶在8:30PM正開始在視頻游戲使用上達到峰值。若那時西海岸上的主機服務服務 器中心中存在電力故障，則其他主機服務服務器中心處可能不存在用于處理所有用戶的足 夠的西海岸服務器402。在此種情形下，可將一些用戶轉移至東海岸上具有可用服務器402 的主機服務服務器中心，且對于用戶而言的唯一后果將是較高延時。一旦將用戶自失去電 力的服務器中心轉移，服務器中心接著就可開始其服務器及設備的有序切斷，以便在電池 (或其他立即電力備用)耗盡之前切斷所有設備。以此方式，可避免用于服務器中心的發電 機的成本。在一個實施例中，在主機服務210的嚴重載入的時間期間(或者由于峰值用戶載 入，或者因為一個或多個服務器中心出故障)，基于用戶正使用的游戲或應用程序的延時要 求將用戶轉移至其他服務器中心。因此，將為使用需要低延時的游戲或應用程序的用戶給 出對存在有限供應的可用低延時服務器連接的優選。主機服務特征圖15說明在以下特征描述中利用的用于主機服務210的服務器中心的組件的實 施例。如同圖2a中所說明的主機服務210 —樣，除非另外有條件，否則此服務器中心的組 件由主機服務210控制系統401來控制及協調。將來自用戶客戶端415的入埠互聯網通信1501指引至入埠路由1502。通常，入埠 互聯網通信1501將經由至互聯網的高速光纖連接而進入服務器中心，但具有足夠帶寬、可 靠性及低延時的任何網絡連接裝置將是足夠的。入埠路由1502是網絡(該網絡可實施為 以太網、光纖信道網絡，或經由任何其他輸送裝置)交換器及支持所述交換器的路由服務 器的系統，其取得到達的分組且將每個分組路由到適當應用程序/游戲服務器1521-1525。 在一實施例中，傳送至特定應用程序/游戲服務器的分組表示自客戶端所接收的數據的一 子集和/或可由數據中心內的其他組件(例如，網絡連接組件，諸如網關及路由器)來轉 譯/改變。在一些狀況下，(例如)若游戲或應用程序同時并行地在多個服務器上執行，則 每次將分組路由至一個以上服務器1521-1525。RAID陣列1511-1512連接至入埠路由網絡 1502，以使得應用程序/游戲服務器1521-1525可讀取RAID陣列1511-1512及寫入RAID 陣列1511-1512。另外，RAID陣列1515 (其可實施為多個RAID陣列)也連接至入埠路由 1502，且來自RAID陣列1515的數據可自應用程序/游戲服務器1521-1525來讀取。入埠路 由1502可在多種先前技術網絡架構(包括樹結構的交換器，入埠互聯網通信1501在其根 部)中實施；在互連所有各種設備的網狀結構中實施；或作為互連的子網絡序列(互通設 備當中的集中通信與其他設備當中的集中通信隔離)來實施。一類型的網絡配置為SAN(存 儲區域網絡)，其盡管通常用于儲存設備，但其也可用于設備之間的通用高速數據傳送。又， 應用程序/游戲服務器1521-1525可各自具有至入埠路由1502的多個網絡連接。舉例而 言，服務器1521-1525可具有至附接至RAID陣列1511-1512的子網絡的網絡連接及至附 至其他設備的子網絡的另一網絡連接。
應用程序/游戲服務器1521-1525可經相同地、有些不同地或全部不同地來配置， 如先前關于圖4a中所說明的實施例中的服務器402所描述的。在一實施例中，每一用戶當 使用主機服務時通常為至少一應用程序/游戲服務器1521-1525。出于說明的簡單起見，將 假定給定用戶正使用應用程序/游戲服務器1521，但多個服務器可由一用戶使用，且多個 用戶可共用單一應用程序/游戲服務器1521-1525。自客戶端415 (如先前所描述)所發 送的用戶的控制輸入經接收為入埠互聯網通信1501，且經由入埠路由1502而路由至應用 程序/游戲服務器1521。應用程序/游戲服務器1521使用用戶的控制輸入作為至在服務 器上執行的游戲或應用程序的控制輸入，且計算視頻及與其相關聯的音頻的下一個幀。應 用程序/游戲服務器1521接著將未經壓縮的視頻/音頻1529輸出至共用視頻壓縮1530。 應用程序/游戲服務器可經由任何裝置(包括一或多個超高速以太網連接)而輸出未經壓 縮的視頻，但在一實施例中，視頻是經由DVI (交互式數字視頻系統)連接而輸出，且音頻及 其他壓縮及通信信道狀態信息系經由通用串列總線(USB)連接而輸出。共用視頻壓縮1530壓縮來自應用程序/游戲服務器1521-1525的未經壓縮的視 頻及音頻。該壓縮可完全以硬件或以執行軟件的硬件來實施。可存在用于每個應用程序/ 游戲服務器1521-1525的專用壓縮器，或若壓縮器足夠快，則可使用給定壓縮器來壓縮來 自一個以上應用程序/游戲服務器1521-1525的視頻/音頻。舉例而言，在60fps下，視頻 幀時間為16. 67毫秒。若壓縮器能夠在1毫秒內壓縮1幀，則該壓縮器可用于通過取得來 自一個接一個的服務器的輸入而壓縮來自多達16個應用程序/游戲服務器1521-1525的 視頻/音頻，該壓縮器保存每個視頻/音頻壓縮過程的狀態且當其在來自服務器的視頻/ 音頻流當中循環時切換背景。這導致壓縮硬件的實質成本節省。因為不同服務器將在不同 時間完成幀，所以在一個實施例中，壓縮器資源是處于具有用于儲存每個壓縮過程的狀態 的共用儲存裝置(例如，RAM，閃存)的共用集區1530中，且當服務器1521-1525幀完整且 準備被壓縮時，控制裝置確定那時哪個壓縮資源可用，為該壓縮資源提供服務器的壓縮過 程的狀態及待壓縮的未經壓縮的視頻/音頻的幀。注意，用于每個服務器的壓縮過程的狀態的一部分包括關于壓縮本身的信息，諸 如先前幀的經解壓縮的幀緩沖數據(其可用作用于P圖像塊的參考)、視頻輸出的分辨率； 壓縮的質量；圖像塊結構；每圖像塊的比特的分配；壓縮質量、音頻格式(例如，立體聲、環 繞音效、Dolby AC-3(杜比 )AC-3)。但是壓縮過程狀態也包括關于以下的通信信道狀 態信息峰值數據速率941，及先前幀(如圖9b中所說明)當前是否正被輸出(且因此應 忽略當前幀)，及潛在地是否存在應在壓縮中考慮的(諸如，過多分組丟失)影響壓縮決策 (例如，在I圖像塊的頻率方面，等)的信道特性。因為峰值數據速率941或其他信道特性 隨著時間而改變，如由支持每個用戶監視從客戶端415發送的數據的應用程序/游戲服務 器1521-1525所確定的，所以應用程序/游戲服務器1521-1525將相關信息發送至共用硬 件壓縮1530。共用硬件壓縮1530也使用諸如先前所描述的所述裝置的裝置將經壓縮的視頻/ 音頻分組化，且在適當時，應用FEC碼，復制特定數據，或采取其他步驟，以便充分地確保視 頻/音頻數據流由客戶端415接收且以可行的高質量及可靠性解壓縮的能力。—些應用程序(諸如，下文所描述的應用程序)需要給定應用程序/游戲服務器 1521-1525的視頻/音頻輸出同時在多個分辨率下(或以其他多個格式)可用。若應用程序/游戲服務器1521-1525如此通知共用硬件壓縮1530資源，則該應用程序/游戲服務 器1521-1525的未經壓縮的視頻音頻1529將被以不同格式、不同分辨率和/或在不同分組 /糾錯結構中同時壓縮。在一些狀況下，一些壓縮資源可在壓縮同一視頻/音頻的多個壓 縮過程當中共用(例如，在許多壓縮算法中，存在借以在應用壓縮的前將圖像按比例調整 成多個大小的步驟。若需要輸出不同大小的圖像，則該步驟可用于同時服務若干個壓縮過 程)。在其他狀況下，對于每個格式將需要單獨的壓縮資源。在任何狀況下，將用于給定應 用程序/游戲服務器1521-1525 ( 一或多個)所需的所有各種分辨率及格式的經壓縮的視 頻/音頻1539同時輸出到出埠路由1540。在一個實施例中，經壓縮的視頻/音頻1539的 輸出是處于UDP格式，因此其為單向分組流。出埠路由網絡1540包含一系列路由服務器及交換器，該系列路由服務器及交換 器將每個經壓縮的視頻/音頻流經由出埠互聯網通信1599接口(其通常將連接到至互聯 網的光纖接口)而指引到有意的用戶或其他目的地和/或返回至延遲緩沖器1515，和/或 返回至入埠路由1502，和/或經由私用網絡(未圖示)而輸出以供進行視頻分配。注意(如 下所述)出埠路由1540可將給定視頻/音頻流同時輸出至多個目的地。在一實施例中， 這是使用互聯網協議(IP)多播來實施，其中廣播意欲同時流動到多個目的地的給定UDP 流，且該廣播由出埠路由1540中的路由服務器及交換器來重復。廣播的該多個目的地可經 由互聯網而至多個用戶的客戶端415、經由入埠路由1502而到多個應用程序/游戲服務器 1521-1525，和/或到一個或多個延遲緩沖器1515。因此，將給定服務器1521-1522的輸出 壓縮成一個或多個格式，且將每個經壓縮的流指引到一個或多個目的地。另外，在另一實施例中，若多個應用程序/游戲服務器1521-1525同時由一個用戶 使用(例如，在用于產生具有復雜場景的3D輸出的并行處理配置中)且每個服務器產生 所得圖像的部分，則可由共用硬件壓縮1530將多個服務器1521-1525的視頻輸出組合成 一組合幀，且自該點向前如上所述處理該組合幀，好像其來自單個應用程序/游戲服務器 1521-1525。注意，在一個實施例中，將由應用程序/游戲服務器1521-1525產生的所有視頻的 復本(至少以由用戶觀看的視頻的分辨率或更高分辨率)記錄于延遲緩沖器1515中歷時 至少某一數目的分鐘(在一個實施例中為15分鐘)。這允許每個用戶“回放”來自每個會 話的視頻，以便核查先前工作或業績(在游戲的狀況下)。因此，在一個實施例中，將路由至 用戶客戶端415的每個經壓縮視頻/音頻輸出1539流也多播至延遲緩沖器1515。當將視 頻/音頻儲存于延遲緩沖器1515上時，延遲緩沖器1515上的目錄提供應用程序/游戲服 務器1521-1525 (其為延遲的視頻/音頻的來源)的網絡地址與延遲緩沖器1515上可發現 延遲的視頻/音頻的位置之間的交叉參考。 現場直播的、可即刻觀看的、可即刻播放的游戲 應用程序/游戲服務器1521-1525不僅可用于執行用戶的給定應用程序或視頻 游戲，而且其可用于建立用于支持經由主機服務210的導航及其他特征的主機服務210的 用戶接口應用程序。一種該用戶接口應用程序的屏幕拍攝顯示在圖16中(“游戲取景器 (Game Finder) ”屏幕)。該特定用戶接口屏幕允許用戶觀看由其他用戶現場玩的(或延遲 的)15個游戲。“縮略圖”視頻窗中的每一者(諸如，1600)為在運動中的現場直播的視頻 窗，其顯示來自一個用戶的游戲的一個視頻。縮略圖中所顯示的視圖可為用戶正看的同一
45視圖，或其可為延遲的視圖(例如，若用戶正玩搏斗游戲，則用戶可能不希望其他用戶看見 其隱藏在哪里且其可選擇將其游戲播放的任何視圖延遲一時間周期(例如，10分鐘))。視 圖也可為不同于任何用戶的視圖的游戲的相機視圖。通過菜單選擇(此說明中未圖示)，用 戶可基于多種標準來選擇要同時觀看的游戲的選擇。作為例示性選擇的小取樣，用戶可選 擇游戲的隨機選擇(諸如圖16中所顯示的游戲)、所有一個類別的游戲(均由不同玩家來 玩)、僅游戲的頂級玩家、游戲中的給定級別的玩家，或較低級玩家(例如，若玩家正學習基 礎)、是“搭檔”(或為競爭者)的玩家、具有最多數目觀看者的游戲等。注意，通常，每個用戶將決定來自其游戲或應用程序的視頻是否可由他人觀看，且 若如此，則決定該視頻可由哪些他人觀看及何時可由他人觀看，決定該視頻是否只可在具 有延遲的情況下觀看。產生圖16中所顯示的用戶接口屏幕的應用程序/游戲服務器1521-1525通過向 每個用戶(該應用程序/游戲服務器1521-1525正請求來自該用戶的游戲)的應用程序 /游戲服務器1521-1525發送消息而獲取該15個視頻/音頻饋送。該消息經由入埠路由 1502或另一網絡來發送。該消息將包括被請求的視頻/音頻的大小及格式，且將識別觀看 用戶接口屏幕的用戶。給定用戶可選擇選擇“盜版”模式且不準許任何其他用戶觀看其游 戲的視頻/音頻(自其觀看點或者自另一觀看點)，或如先前的段中所描述，用戶可選擇允 許觀看來自其游戲的視頻/音頻，但延遲所觀看的視頻/音頻。用戶應用程序/游戲服務 器1521-1525 (其接收并接受允許其視頻/音頻被觀看的請求)將因此向請求服務器確認， 且其也將通知共用硬件壓縮1530需要產生被請求格式或屏幕大小(假定格式及屏幕大小 不同于已經產生的格式及屏幕大小)的額外經壓縮視頻流，且其也將指示經壓縮視頻的目 的地(也即，請求服務器)。若被請求的視頻/音頻僅被延遲，則請求應用程序/游戲服務 器1521-1525將被這樣通知，且其將通過查找延遲緩沖器1515上的目錄中的視頻/音頻的 位置及為延遲的視頻/音頻的來源的應用程序/游戲服務器1521-1525的網絡地址而自延 遲緩沖器1515獲取延遲的視頻/音頻。一旦所有該請求被產生并處理，則將高達15個現 場直播的縮略圖大小的視頻流從出埠路由1540路由到入埠路由1502、到產生用戶接口屏 幕的應用程序/游戲服務器1521-1525，且將由該服務器來解壓縮及顯示。延遲的視頻/音 頻流可能處于過大的屏幕大小，如果這樣，則應用程序/游戲服務器1521-1525將解壓縮所 述流并將視頻流按比例縮減至縮略圖大小。在一個實施例中，將對音頻/視頻的請求發送 到與圖4a的主機服務控制系統類似的中央“管理”服務(圖15中未顯示)(且由中央“管 理”服務來管理)，中央“管理”服務接著將所述請求重定向到適當應用程序/游戲服務器 1521-1525。此外，在一個實施例中，可能不需要請求，因為縮略圖被“推送”至允許其的那 些用戶的客戶端。來自15個游戲的所有同時混合的音頻可能產生刺耳的聲音。用戶可選擇以此方 式將所有聲音混合在一起(可能就為得到由被觀看的所有動作產生的“喧囂”的感覺)，或 者用戶可選擇每次僅收聽來自一個游戲的音頻。單個游戲的選擇是通過將黃色選擇幀1601 移動到給定游戲來完成(黃色幀移動可通過使用鍵盤上的箭頭鍵、通過移動鼠標、通過移 動操縱桿或通過推動諸如移動電話的另一設備上的方向按鈕來完成)。一旦選擇了單個游 戲，則只有來自該游戲的音頻播放。而且，顯示游戲信息1602。在該游戲的狀況下，例如， 出版商標志(“EA”)及游戲標志“極品飛車卡本峽谷”及橙色橫條在相對條件下指示在該特定時刻玩游戲或觀看游戲的人的數目(在此狀況下，許多，因此游戲為“熱門”)。另外提 供“狀態”，指示存在145個玩家正積極地玩極品飛車游戲的80個不同具體實例(也即，該 游戲可通過個別玩家游戲或多人游戲來玩)，且存在680個觀看者(此用戶是其中之一)。 注意，該統計數據(及其他統計數據)由主機服務控制系統401來收集并儲存于RAID陣列 1511-1512上，以用于保持主機服務210操作的日志且用于適當地向用戶計費并向提供內 容的出版商支付費用。一些統計數據是由于由服務控制系統401進行的動作而記錄，且一 些統計數據是由個別應用程序/游戲服務器1521-1525報告給服務控制系統401。舉例而 言，當游戲正被觀看時(及當游戲被停止觀看時)，執行此游戲取景器應用程序的應用程序 /游戲服務器1521-1525向主機服務控制系統401發送消息，以使得主機服務控制系統401 可更新多少個游戲處于觀看中的統計數據。一些統計數據可為用戶接口應用程序(諸如， 此游戲取景器應用程序)所用。若用戶單擊其輸入設備上的啟動按鈕，則其將看見黃色幀中的縮略圖視頻放大同 時縮略圖視頻保持現場直播為全屏幕大小。該效果顯示在圖17中的過程中。注意，視頻窗 1700的大小增大。為了實施該效果，應用程序/游戲服務器1521-1525從運行選定的游戲 的應用程序/游戲服務器1521-1525請求具有路由到其的游戲的全屏幕大小(以用戶的顯 示設備422的分辨率)的視頻流的復本。執行游戲的應用程序/游戲服務器1521-1525通 知共用硬件壓縮器1530不再需要游戲的縮略圖大小的復本(除非另一應用程序/游戲服 務器1521-1525需要這種縮略圖)，且接著其指引共用硬件壓縮器1530將視頻的全屏幕大 小的復本發送至放大視頻的應用程序/游戲服務器1521-1525。玩該游戲的用戶可或可不 具有分辨率與將游戲放大的用戶的所述顯示設備的分辨率相同的顯示設備422。另外，游 戲的其他觀看者可或可不具有分辨率與將游戲放大的用戶相同的顯示設備422(且可具有 不同的音頻回放裝置，例如，立體聲或環繞音效)。因此，共用硬件壓縮器1530確定是否已 經產生滿足請求視頻/音頻流的用戶的要求的合適的經壓縮視頻/音頻流，且若合適的經 壓縮視頻/音頻流確實存在，則共用硬件壓縮器1530通知出埠路由1540將該流的復本路 由至放大該視頻的應用程序/游戲服務器1521-1525，且若合適的經壓縮視頻/音頻流不 存在，則壓縮視頻的適合于所述用戶的另一復本并指導出埠路由將該流發送回至入埠路由 1502及放大該視頻的應用程序/游戲服務器1521-1525。現在接收選定視頻的全屏幕版本 的該服務器將解壓縮該全屏幕版本并將其逐漸地按比例放大至全大小。圖18說明在將游戲完全放大至全屏幕且以用戶的顯示設備422的全分辨率顯示 游戲之后屏幕看起來如何(如通過箭頭1800指向的圖像所指示的)。執行游戲取景器應 用程序的應用程序/游戲服務器1521-1525向提供縮略圖的其他應用程序/游戲服務器 1521-1525發送消息以指示所述縮略圖不再需要且向主機服務控制服務器401發送消息以 指示不再觀看其他游戲。此時，產生的唯一顯示為屏幕頂部的疊加層(overlay) 1801，其將 信息及菜單控制提供給用戶。注意，隨著該游戲進展，觀眾增長至2，503個觀看者。在如此 多的觀看者的情況下，必然存在具有顯示設備422的許多觀看者，所述顯示設備422具有相 同或接近的分辨率(每個應用程序/游戲服務器1521-1525具有按比例調整視頻以用于調 整配合度的能力)。因為所顯示的游戲為多人游戲，所以用戶可決定在某時刻加入該游戲。由于多種 原因，主機服務210可或可不允許用戶加入該游戲。舉例而言，用戶可能必須支付玩游戲的費用而選擇不支付，用戶可能不具有足以加入所述特定游戲的足夠等級(例如，對于其他 玩家而言，其將不有競爭性)，或者用戶的互聯網連接可能不具有足以允許用戶玩的足夠低 的延時(例如，不存在用于觀看游戲的延時約束，因此可在無延時關注的情況下觀看被遠 距離地(實際上，在另一大陸上)玩的游戲，但對于待玩的游戲而言，延時必須足夠低以使 用戶(a)享受該游戲，且(b)處于與可能具有較低延時連接的其他玩家相等的地位)。若 準許用戶玩，則為用戶提供游戲取景器用戶接口的應用程序/游戲服務器1521-1525將請 求主機服務控制服務器401初始化(也即，定位并啟動)被合適地配置以用于播放特定游 戲的應用程序/游戲服務器1521-1525從而從RAID陣列1511-1512載入該游戲，且接著主 機服務控制服務器401將指導入埠路由1502將來自用戶的控制信號傳送至現在對游戲進 行主機代管的應用程序/游戲服務器且現在對游戲進行主機代管的應用程序/游戲服務器 將指導共用硬件壓縮1530自壓縮來從主機代管游戲取景器應用程序的應用程序/游戲服 務器的視頻/音頻切換至壓縮來自現在對游戲進行主機代管的應用程序/游戲服務器的視 頻/音頻。游戲取景器應用程序/游戲服務與對游戲進行主機代管的新的應用程序/游戲 服務器的垂直同步并不同步，且因此在該兩個同步之間可能存在時間差。因為共用視頻壓 縮硬件1530將在應用程序/游戲服務器1521-1525完成視頻幀之后即開始壓縮視頻，所以 來自新服務器的第一幀可比舊服務器的全幀時間完成得早，來自新服務器的第一幀可能在 先前經壓縮的幀完成其傳輸之前(例如，考慮圖9b的傳輸時間992 若未經壓縮的幀3963 早一幀時間的一半地完成，則其將影響(impinge)傳輸時間992)。在這種情形下，共用視 頻壓縮硬件1530將忽略來自新服務器的第一幀(例如，如忽略(974)幀4964)，且客戶端 415將來自舊服務器的最末幀保持額外一幀時間，且共用視頻壓縮硬件1530將開始壓縮來 自對游戲進行主機代管的新應用程序/游戲服務器的下一幀時間視頻。對于用戶而言，在 視覺上，從一個應用程序/游戲服務器至另一應用程序/游戲服務器的轉變將是無縫的。 主機服務控制服務器401接著將通知對游戲取景器進行主機代管的應用程序/游戲服務器 1521-1525切換至閑置狀態，直至再次需要其為止。用戶接著能夠玩該游戲。此外，例外的是游戲將在感知上即刻地播放(因為游戲 已被以十億比特/秒速度從Raid陣列1511-1512載入到應用程序/游戲服務器1521-1525 上)，且將通過理想的驅動器、暫存器配置(在Windows的狀況下)將游戲連同被正確配置 以用于該游戲的操作系統一起載入到準確適合于該游戲的服務器上，且沒有可能與該游戲 的操作競爭的其他應用程序在該服務器上執行。而且，隨著用戶在游戲中進展，游戲的片段中的每一者將以十億比特/秒的速度 (也即，在8秒內載入十億字節)從RAID陣列1511-1512載入服務器中，且由于RAID陣 列1511-1512的巨大儲存容量(因為其為許多用戶的共用資源，所以其可能非常大，但仍 具成本效益)，使得可預先計算幾何形狀設置或其他游戲片段設置并將其儲存于RAID陣列 1511-1512上且極快速地進行載入。此外，因為每個應用程序/游戲服務器1521-1525的硬 件配置及計算能力是已知的，所以可預先計算像素及頂點著色。因此，游戲可幾乎即刻啟動，其將在理想環境中執行，且隨后的片段將幾乎即刻載 入。但是，除這些優點之外，用戶將能夠觀看他人玩游戲(經由先前所描述的游戲取 景器，及其他裝置)，且兩者均決定游戲是否有趣，如果這樣，則自觀看他人來學習技巧。此
48外，用戶將能夠即刻地演示該游戲，而不必等待大的下載和/或安裝，且用戶將能夠即刻玩 該游戲(可能在較小費用的試用基礎上，或在較長期的基礎上)。此外，用戶將能夠通過足 夠低延時的無線連接而在Windows PC、MaCint0Sh上、在電視機上、在家里、在行進時且甚至 在移動電話上玩該游戲。此外，這均可在并非曾經實體擁有游戲復本的情況下完成。如先前所敘述，用戶可決定不允許其游戲播放可被他人觀看，允許其游戲可在延 遲之后觀看，允許其游戲可被選定用戶觀看，或允許其游戲可被所有用戶觀看。不管怎樣， 在一個實施例中，將視頻/音頻儲存于延遲緩沖器1515中歷時15分鐘，且用戶將能夠“回 倒”并觀看其先前的游戲播放，且將游戲暫停，將游戲緩慢地回放，將游戲快進等，正如其在 觀看具有數字視頻記錄器(DVR)的TV時所能夠進行的。盡管在該實例中，用戶在玩游戲， 但若用戶正使用應用程序，則相同“DVR”能力是可用的。這在核查先前工作中及在如下詳 述的其他應用中可是有用的。另外，若游戲經設計為具有基于利用游戲狀態信息而回倒的 能力，以便可改變相機視圖等，則也將支持此“3D DVR”能力，但其將需要將游戲設計為支持 “3D DVR”能力。使用延遲緩沖器1515的“DVR”能力將連同任何游戲或應用程序(當然，限 于在使用游戲或應用程序時所產生的視頻)一起起作用，但在具有3D DVR能力的游戲的狀 況下，用戶可控制先前所播放的片段的3D “飛越(fly-through) ”，且使延遲緩沖器1515記 錄所得視頻并記錄游戲片段的游戲狀態。因此，將特定“飛越”記錄為經壓縮的視頻，但因 為也將記錄游戲狀態，所以不同的飛越將可能在游戲的同一片段的稍后日期。如下所述，主機服務210上的用戶將各自具有一個用戶頁面，在該用戶頁面中，用 戶可公布關于其本身的信息及其他數據。用戶將能夠公布的事情之一為來自其已保存的游 戲播放的視頻片段。舉例而言，若用戶已克服游戲中的特別困難的挑戰，則用戶可剛好“回 倒”到其在游戲中獲得其大成果的地點之前，且接著指導主機服務210將某一持續時間(例 如，30秒)的視頻片段保存在用戶的用戶頁面上以供其他用戶觀看。為了實施這些，用戶正 使用的應用程序/游戲服務器1521-1525僅要做的事情是將儲存于延遲緩沖器1515中的 視頻回放至RAID陣列1511-1512且接著在用戶的用戶頁面上給所述視頻片段編索引。若游戲具有3D DVR的能力，如上所述，則也可由用戶來記錄3D DVR所需的游戲狀 態信息且使其為用戶的用戶頁面可用。在游戲經設計為除具有活躍玩家外還具有“旁觀者”(也即，能夠在不參與的情況 下在3D世界行進并觀察到動作的用戶)的情況下，則游戲取景器應用程序將使用戶能夠作 為旁觀者以及玩家加入游戲。從觀看的實施點看，對于主機系統210而言，用戶是旁觀者而 不是活躍玩家是不存在差異的。將游戲載入應用程序/游戲服務器1521-1525上且用戶將 控制該游戲(例如，控制觀看世界的虛擬相機)。唯一的差異是用戶的游戲體驗。多個用戶合作主機服務210的另一特征是多個用戶在觀看現場直播的視頻的同時合作的能力 (即使使用迥然不同的設備來觀看也如此)。當玩游戲時及當使用應用程序時，這都有用。許多PC及移動電話裝備有視頻相機且具有進行實時視頻壓縮的能力(尤其當圖 像小時)。而且，小相機是可用的，可附接到電視，且以軟件或使用用于壓縮視頻的許多硬件 壓縮設備中的一者來實施實時壓縮并不困難。而且，許多PC及所有移動電話具有麥克風， 且耳機在具有麥克風情況下可用。組合有本地視頻/音頻壓縮能力(具體來說，使用本文中所描述的低延時視頻壓縮技術)的所述相機和/或麥克風將使用戶能夠將視頻和/或音頻連同輸入設備控制數據 一起從用戶場所211傳輸到主機服務210。當使用所述技術時，則可實現圖19中所說明的 能力用戶可使其視頻及音頻1900出現在另一用戶的游戲或應用程序內的屏幕上。該實例 為多人游戲，其中隊友在賽車中合作。用戶的視頻/音頻僅可被其隊友選擇性地觀看/聽 到。此外，因為使用上文所描述的技術將有效地不存在延時，所以玩家將能夠實時地彼此談 話或進行運動而沒有可感知的延遲。該視頻/音頻整合是通過使來自用戶的相機/麥克風的經壓縮視頻和/或音頻作 為入埠互聯網通信1501到達而完成。接著，入埠路由1502將該視頻和/或音頻路由到被 準許觀看/聽到視頻和/或音頻的應用程序/游戲服務器1521-1525。接著，選擇使用視頻 和/或音頻的各別應用程序/游戲服務器1521-1525的用戶解壓縮視頻和/或音頻且視需 要而將其整合以出現于游戲或應用程序內，諸如通過1900所說明的。圖19的實例顯示如何在游戲中使用該合作，但該合作可為用于應用程序的極其 強大的工具。考慮一各情形其中一大建筑物正由在芝加哥的建筑師為以紐約為基地的房 地產開發商為紐約市設計，但該決策涉及在旅游中且碰巧在邁阿密機場的財務投資者，且 需要進行關于建筑物的特定設計要素(在其如何搭配其附近的建筑物方面)的決策，以滿 足投資者與房地產開發商兩者。假定建筑公司在芝加哥具有具有附接到PC的相機的高分 辨率監視器，房地產開發商在紐約具有帶相機的筆記本計算機，且投資者在邁阿密具有帶 相機的移動電話。建筑公司可使用主機服務210來對能夠進行高度逼真3D再現的強大的 建筑設計應用程序進行主機代管，且其可利用紐約市的建筑物的大數據庫，以及正設計的 建筑物的數據庫。建筑設計應用程序將在應用程序/游戲服務器1521-1525中的一者上 (或若其需要大量計算能力，則在若干者上)執行。處于全異(disparate)位置處的3個用 戶中的每一者將連接至主機服務210，且每一者將具有對建筑設計應用程序的視頻輸出的 同時觀看，但其將被針對每個用戶具有的給定設備及網絡連接特性而由共用硬件壓縮1530 適當地設定大小(例如，建筑公司可經由20Mbps商用互聯網連接看見2560X1440 60fps 顯示，紐約的房地產開發商可經由其筆記本計算機上的6Mbps DSL連接看見1280X720 60fps圖像，且投資者可經由其移動電話上的250Kbps蜂窩式數據連接看見320X180 60fps圖像)。每一方將聽到其他方的語音(將通過應用程序/游戲服務器1521-1525中 的許多廣泛可用的會議呼叫套裝軟件中的任一者來處理會議呼叫)，且經由用戶輸入設備 上的按鈕的致動，用戶將能夠使用其本地相機使視頻出現。隨著會議進行，建筑師將能夠通 過極具照片般逼真感的3D再現顯示當其使建筑物旋轉且使其鄰接該區域中的另一建筑物 飛越(fly-by)時建筑物看起來像什么，且所有方均將在各方的顯示設備的分辨率下可見 到相同視頻。由任何方使用的本地設備中的任一者均能夠以該真實感處理3D動畫不是問 題，更不用說下載或甚至儲存再現紐約市的周圍建筑物所需的巨大數據庫。自用戶中的每 一者的觀點看，盡管距離很遠，且盡管是全異本地設備，但其將簡單地在難以置信的真實感 程度下具有無縫體驗。此外，當一方希望其面部被看來較佳地傳達其情緒狀態時，其可如此 進行。另外，若房地產開發商或投資者希望控制建筑程序且使用其自身的輸入設備(其為 鍵盤、鼠標、小鍵盤或觸摸屏幕)，則其可如此，且其可以用無感知的延時來響應(假定其網 絡連接不具有不合理的延時)。舉例而言，在移動電話的狀況下，若移動電話連接至機場的 WiFi網絡，則其將具有非常低的延時。但若其使用美國現今可用的蜂窩式數據網絡，則其很
50可能將遭受引人注意的滯后。但是，對于會議的大多數目的(其中投資者正觀看建筑師控 制建筑物飛越或正談論視頻電話會議)，甚至蜂窩式延時也應是可接受的。最后，在合作性會議呼叫結束時，房地產開發商及投資者將進行其評論且從主機 服務停播，建筑公司將能夠“回倒”已記錄在延遲緩沖器1515上的會議的視頻且核查在會 議期間進行的應用于建筑物的3D模型的評論、面部表情和/或動作。若存在其希望保存的 特定片段，則可將視頻/音頻的所述片段自延遲緩沖器1515移動至RAID陣列1511-1512 以用于檔案儲存及稍后回放。而且，從成本觀點看，若建筑師僅需要使用紐約市的計算能力及大數據庫歷時15 分鐘的會議呼叫，則其僅需要支付所述資源被使用的時間的費用，而不必擁有高能力的工 作臺且不必購買大數據庫的昂貴復本。視頻豐富的社區服務主機服務210使得有空前機會來在互聯網上建立視頻豐富的社區服務。圖20顯 示用于主機服務210上的游戲玩家的例示性用戶頁面。如同游戲取景器應用程序一樣，用 戶頁面為在應用程序/游戲服務器1521-1525中的一者上執行的應用程序。該頁面上的所 有縮略圖及視頻窗顯示恒定地移動的視頻(若片段短，則其循環)。使用視頻相機或通過上傳視頻，用戶(其用戶名為“KILLHAZARD”)能夠公布其本 身的視頻2000 (其他用戶可觀看該視頻)。該視頻儲存于RAID陣列1511-1512上。而且， 當其他用戶來到KILLHAZARD的用戶頁面時，若KILLHAZARD此時正使用主機服務210，則將 顯示其正進行的無論什么的現場直播的視頻2001 (假定KILLHAZARD準許觀看其用戶頁面 的用戶觀看該視頻)。這將由對用戶頁面應用程序進行主機代管的應用程序/游戲服務器 1521-1525從服務控制系統401請求KILLHAZARD是否為活躍的(且若如此，則請求其正使 用的應用程序/游戲服務器1521-1525)來完成。接著，使用由游戲取景器應用程序使用的 相同方法，將合適分辨率及格式的經壓縮的視頻流發送至執行用戶頁面應用程序的應用程 序/游戲服務器1521-1525且將其顯示。若用戶選擇具有KILLHAZARD的現場直播的游戲 播放的窗口且接著適當地單擊其輸入設備，則該窗口將放大(再次使用與游戲取景器應用 程序相同的方法)，且現場直播的視頻將以觀看用戶的顯示設備422的分辨率(適合于觀看 用戶的互聯網連接的特性)填充屏幕。這優于先前技術方法的關鍵優點是觀看用戶頁面的用戶能夠看見用戶不擁有的 現場直播地播放的游戲，且可不具有能夠玩該游戲的本地計算機或游戲控制臺。其為用戶 提供看用戶頁面中顯示為“活動中”的用戶玩游戲的極好機會，且這是了解觀看用戶可能希 望嘗試或較擅長的游戲的機會。來自KILLHAZARD的搭檔2002的相機記錄的或上傳的視頻剪輯也顯示于用戶頁面 上，且每個視頻剪輯的下方為指示該搭檔是否在線玩游戲的文字(例如，siX_sh0t正玩游 戲“龍騎士(Eragon) ”且MrSnUggleS99離線等)。通過單擊菜單項(未圖示)，搭檔視頻 剪輯自顯示已記錄的或上傳的視頻切換至當前正玩主機服務210上的游戲的搭檔在所述 時刻在其游戲中正在進行的內容的現場直播的視頻。因此，其變成為搭檔分群的游戲取景 器。若選擇搭檔的游戲且用戶單擊該游戲，則該游戲將放大至全屏幕，且用戶將能夠觀看全 屏幕現場直播地播放的游戲。再次，觀看搭檔的游戲的用戶不擁有游戲的復本，也不擁有用于玩該游戲的本地計算/游戲控制臺資源。游戲觀看是有效瞬時的。如上文先前所描述，當用戶玩主機服務210上的游戲時，用戶能夠“回倒”游戲且 發現其希望保存的視頻片段，且接著將該視頻片段保存到其用戶頁面。這被稱為“自賞剪 輯(Brag Clip)”。視頻片段2003都是由KILLHAZARD從其所玩的先前游戲保存的自賞剪 輯2003。數字2004顯示自賞剪輯已被觀看多少次，及自賞剪輯何時被觀看，用戶具有對其 評定等級的機會，且橙色鑰匙孔形狀的圖示2005的數目指示等級是多高。當用戶觀看用戶 頁面時，自賞剪輯2003連同頁面上的其余視頻一起恒定地循環。若用戶選擇并單擊自賞剪 輯2003中的一者，則其放大以呈現自賞剪輯2003，以及允許播放、暫停、回倒、快進、步進等 該剪輯的DVR控制。自賞剪輯2003回放是通過應用程序/游戲服務器1521-1525載入用戶記錄自賞 剪輯時儲存于RAID陣列1511-1512上的經壓縮視頻片段且將其解壓縮并將其回放來實施。自賞剪輯2003也可為來自支持3D DVR能力的游戲的“3D DVR”視頻片段(也即， 來自可被重放且允許用戶改變相機觀看點的游戲的游戲狀態序列)。在此狀況下，除用戶 在記錄游戲片段時進行的特定“飛越”的經壓縮視頻記錄之外，也儲存游戲狀態信息。當用 戶頁面正被觀看且所有縮略圖及視頻窗均恒定地循環時，3D DVR自賞剪輯2003將使在用 戶記錄游戲片段的“飛越”時記錄為經壓縮視頻的自賞剪輯2003恒定地循環。但是，當用 戶選擇3D DVR自賞剪輯2003并單擊3D DVR自賞剪輯2003時，除允許播放經壓縮視頻自 賞剪輯的DVR控制之外，用戶將能夠單擊給出其用于游戲片段的3D DVR能力的按鈕。其將 能夠獨立地控制游戲片段期間的相機“飛越”，且若其希望(且擁有用戶頁面的用戶允許如 此)，則其將能夠以經壓縮的視頻的形式記錄替代性自賞剪輯“飛越”，替代性自賞剪輯“飛 越”將接著可為用戶頁面的其他觀看者所用(立即地，或者在用戶頁面的擁有者具有核查自 賞剪輯的機會之后)。該3D DVR自賞剪輯2003能力是通過啟動將要在另一應用程序/游戲服務器 1521-1525上重放已記錄的游戲狀態信息的游戲來啟用。因為游戲可被幾乎瞬時地啟動 (如先前所描述)，所以啟動其(其播放限于由自賞剪輯片段記錄的游戲狀態)且接著允許 用戶在將經壓縮視頻記錄到延遲緩沖器1515的同時用相機進行“飛越”并不困難。一旦用 戶完成進行“飛越”，則將游戲撤銷啟動。從用戶的觀點看，啟動具有3D DVR自賞剪輯2003的“飛越”并不比控制線性自賞 剪輯2003的DVR控制難。用戶可不知道該游戲或甚至不知道如何玩該游戲。用戶指示盯 著看另一操作者記錄的游戲片段期間的3D世界的虛擬相機操作者。用戶將也能夠將其自身的音頻加錄于自賞剪輯上(或者自麥克風記錄或者上 傳)。以這種方式，可使用自賞剪輯來使用來自游戲的人物及動作產生定制動畫。此動畫制 作技術通常被稱為“游戲電影(machinima) ”。隨著用戶在游戲中進展，其將達成不同技能級別。所播放的游戲將成果報告給服 務控制系統401，且所述技能級別也將顯示于用戶頁面上。互動式動畫廣告在線廣告已自文字轉變至靜態圖像、視頻，且現在轉變至互動式片段，通常使用如 Adobe Flash的動畫精簡型客戶端來實施。使用動畫精簡型客戶端的原因在于用戶通常 對于因向其推銷產品或服務的特權而被延遲較無耐心。而且，精簡型客戶端在非常低性能的PC上執行，且因此廣告商可具有高度信心互動式廣告將適當地工作。很遺憾地，諸如 Adobe Flash的動畫精簡型客戶端在互動性的程度及體驗(以減少下載時間)的持續時間 上受限制。圖21說明一個互動式廣告，其中用戶將在汽車在陳列室中旋轉時選擇汽車的外 部及內部色彩，同時實時射線追蹤顯示汽車看起來如何。接著用戶選擇角色來駕駛汽車，且 接著用戶可采用該汽車來用于在競賽軌道上或者穿過諸如摩納哥的外國場所駕駛。用戶 可選擇較大引擎或較佳輪胎，且接著可看見改變的配置如何影響汽車加速或保持穩定的能 力。當然，廣告有效地的為尖端的3D視頻游戲。但對于可在PC或視頻游戲控制臺上播 放的這種廣告，其將需要可能100MB下載，且在PC的狀況下，其可能需要安裝特殊驅動器， 且可能在PC缺乏足夠CPU或GPU計算能力時根本不執行。因此，所述廣告在先前技術配置 中不切實際。在主機服務210中，所述廣告幾乎即刻地投放，且較佳地執行，無論用戶的客戶端 415能力如何。因此，其比精簡型客戶端互動式廣告更迅速地投放，體驗上更加豐富，且高度可靠。實時動畫期間流動的幾何形狀RAID陣列1511-1512及入埠路由1502可提供如此快的數據速率且具有如此低的 延時，以致有可能設計依賴于RAID陣列1511-1512及入埠路由1502來在實時動畫(例如， 具有復雜數據庫的飛越)期間于游戲播放的中間或應用程序中可靠地直接傳送幾何形狀 的視頻游戲及應用程序。在先前技術的系統(諸如，圖1中所顯示的視頻游戲系統)下，可用的大量儲存設 備(尤其是在實用的家庭設備中)極緩慢以致不能在游戲播放期間流動幾何形狀(除了所 需的幾何形狀稍微可預測的情形之外)。舉例而言，在存在指定道路的駕駛游戲中，可合理 地適當預測用于進入視野內的建筑物的幾何形狀且大量儲存設備可提前搜尋即將到來的 幾何形狀所定位的位置。但在具有不可預測的改變的復雜場景中(例如，在周圍具有復雜人物的戰役場景 中)，若PC或視頻游戲系統上的RAM完全被填滿用于當前在視圖中的對象的幾何形狀，且接 著用戶突然將其人物轉向以觀看其人物之后是什么，若未將幾何形狀預先載入RAM中，則 可能在可顯示幾何形狀之前存在延遲。在主機服務210中，RAID陣列1511-1512可以超過超高速以太網速度的速度使數 據流動，且在SAN網絡下，有可能達到優于10個十億比特以太網或優于其他網絡技術的100 億比特/秒的速度。100億比特/秒將在小于一秒內載入十億字節的數據。在60fps幀時 間(16. 67毫秒)內，可載入約170百萬比特(21MB)的數據。當然，甚至在RAID配置中，旋 轉媒體也仍將導致大于一幀時間的延時，但以閃存為基礎的RAID儲存器最終將與旋轉媒 體RAID陣列一般大且將不會招致該高延時。在一各實施例中，使用經由大量RAM寫入的高 速緩存來提供非常低延時的存取。因此，在足夠高的網絡速度，以及足夠低延時的大量儲存器下，可與CPU和/或GPU 可處理3D數據一般快地將幾何形狀流動到應用程序/游戲服務器1521-1525中。因此，在 先前所給出的實例中，其中用戶突然將其人物轉向且向后看，可在人物完成旋轉之前載入
53其身后的所有人物的幾何形狀，且因此，對于用戶而言，將看來似乎其處于與現場直播的動 作一般真實的照片般逼真的世界中。如先前所論述，照片般逼真的計算機動畫中的最后的邊界中的一者是人臉，且由 于人眼對于不完全性的敏感性，來自照片般逼真的面部的最輕微錯誤可導致來自觀看者的 負面反應。圖22顯示使用Contour 真實性捕獲技術(以下共同待審申請中的申請的主 題2004 年 9 月 15 日申請的第 10/942，609 號 “Apparatus and method for capturing the motion of a performer，，;2004 年 9 月 15 日申請的第 10/942，413 號"Apparatus and method for capturing theexpression of a performer，，；2005 年 2 月 25 日申請的第 11/066，954 號“Apparatusand method for improving marker identification within a motion capturesystem，，;2005年 3 月 10 日申請的第 11/077，628 號"Apparatus and method forperforming motion capture using shutter synchronization，，；2005 年 10 月 20 El 串 i青白勺第 11/255, 854 ^ "Apparatus and method for performing motion captureusing a random pattern on capture surfaces，，;2006 年 6 月 7 日申請的第 11/449，131 號“System and method for performing motion capture usingphosphor application techniques"； 2006 ^ 6 7 H ^itWH 11/449, 043 ^-"System and method for performing motion capture by strobing a f luorescentlamp" ；2006 年6 月 7 日申請的第 11/449，127 號"System and method for threedimensional capture of stop-motion animated characters”，上述申請中的每一者都被轉讓給本CIP申請的受讓人)捕獲的現場直播的表 演如何導致非常平滑的捕獲表面，既而達成高多邊形計數的追蹤表面(也即，多邊形運動 精確地追隨面部的運動)。最后，當將現場直播的表演的視頻映射于追蹤表面上以產生紋理 表面時，產生照片般逼真的結果。盡管當前GPU技術能夠再現追蹤表面及紋理中的許多多邊形且實時地照明該表 面，但若多邊形及紋理每一幀時間改變(其將產生最具照片般逼真感的結果)，則其將迅速 地消耗現代PC或視頻游戲控制臺的所有可用RAM。使用上文所描述的流動幾何形狀技術，將幾何形狀不斷地饋送至應用程序/游戲 服務器1521-1525中以使得其可不斷地動畫制作照片般逼真的面部從而允許產生具有幾 乎不能區別于現場直播的動作面部的面部的視頻游戲變得實際。線性內容與互動式特征的整合電影、電視節目及音頻材料(統稱“線性內容”)廣泛地以許多形式可用于家庭及 辦公室用戶。線性內容可在如⑶、DVD、HD-DVD及藍光媒體的實體媒體上獲取。其也可通過 來自衛星及電纜TV廣播的DVR來記錄。此外，其可以經由衛星及電纜TV的即付即看(PPV) 內容及以電纜TV上的視頻點播(VOD)可用。日益增加的線性內容可經由互聯網以下載的內容及流動內容可用。現今，確實不 存在一個能體驗與線性媒體相關的所有特征的位置。舉例而言，DVD及其他視頻光學媒體 通常具有在其他位置處不可用的互動式特征(如導演的評論、“花絮”短片等)。在線音樂 站點具有通常在CD上不可用的封面藝術及歌曲信息，但并非所有CD在線可用。且與電視 節目相關聯的網站常常具有額外特征、博客及有時來自演員或創作人員的評論。另外，在許多電影或運動事件的情況下，通常有經常連同線性媒體一起發行(在 電影的狀況下)或(在運動的狀況下)可以被緊密地聯系到真實世界事件(例如，玩家的交易)的視頻游戲。主機服務210非常適合于在將全異形式的相關內容連結在一起時傳送線性內容。 的確，傳送電影不如傳送高度互動式視頻游戲有挑戰，且主機服務210能夠將線性內容傳 送至家庭或辦公室中的多種設備，或傳送至移動設備。圖23顯示用于主機服務210的例示 性用戶接口頁面，其顯示線性內容的選擇。但是，不同于大多數線性內容傳送系統，主機服務210還能夠傳送相關的互動式 成份(例如，DVD上的菜單及特征、HD-DVD上的互動式疊加層，及網站上的Adobe Flash動 畫(如下文所述))。因此，客戶端設備415限制不再引入哪些特征可用的限制。另外，主機代管系統210能夠動態且實時地將線性內容與視頻游戲內容連結在一 起。舉例而言，若用戶正觀看哈利波特電影中的Quidditch(魁地奇)比賽，且決定其愿意 嘗試玩Quidditch，則其可僅僅單擊按鈕且電影將暫停且其將被立即輸送到哈利波特視頻 游戲的Quidditch片段。在玩Quidditch比賽的后，另一次單擊按鈕，且電影將即刻重新開 始。在照片般逼真的圖形及制作技術的情況下，其中攝影捕獲的視頻不能區別于現場 直播的動作人物，當用戶進行自現場直播的動作電影中的Quidditch游戲至主機服務上的 視頻游戲中的Quidditch游戲的轉變時(如本文中所述)，該兩個場景實際上不能區別。此 為線性內容與互動式(例如，視頻游戲)內容兩者的導演提供全新的創作選項，因為該兩個 世界之間的線變得不能區別。利用圖14中所顯示的主機服務架構，可將3D電影中的虛擬相機的控制提供給觀 看者。舉例而言，在發生于列車內的場景中，將有可能允許觀看者在故事進展時控制虛擬相 機且環顧列車。此假定列車中的所有3D對象(“資產”)以及能夠實時地再現所述場景以 及原始電影的足夠計算能力水平可用。且甚至對于非計算機產生的娛樂，存在可提供的非常刺激的互動式特征。舉例而 言，2005電影“傲慢與偏見”具有裝飾華麗的舊英國大廈中的許多場景。對于特定大廈場景， 用戶可將視頻暫停且接著控制相機以巡視大廈，或可能的周圍區域。為了實施這些，可攜 帶具有魚眼鏡頭的相機穿過大廈，當其追蹤其位置時，非常類似于實施先前技術Apple (蘋 果)公司的QuickTimeVR。各種幀接著將被轉換，因此圖像不失真，且接著其連同電影一起 被儲存于RAID陣列1511-1512上，且在用戶選擇繼續虛擬巡視時被回放。在運動事件的情況下，可經由主機服務210來使現場直播的運動事件(諸如，籃球 比賽)流動以供用戶觀看(如同其對于常見TV所想要的那樣)。在用戶觀看特定播放之 后，游戲的視頻游戲(最終籃球玩家看起來與真實玩家一般照片般逼真)可趕上在同一位 置中開始的玩家，且用戶(可能各自控制一玩家)可重新玩以觀看其是否可比所述玩家做 得更佳。本文中所描述的主機服務210極其適合于支持此未來世界，因為其能夠承受不切 實際以致不能安裝于家庭中或大多數辦公室背景中的計算能力及大容量儲存資源，而且其 計算資源總是最新的(在可用的最新的計算硬件的情況下)，但是在家庭背景中，將總是存 在具有較舊代的PC及視頻游戲的家庭。此外，在主機服務210中，用戶被隱瞞所有此計算 復雜度，因此，即使用戶可能正使用非常尖端的系統，自用戶的觀點看，也如改變電視上的 信道一般簡單。另外，用戶將能夠存取所有計算能力及計算能力將自任何客戶端415帶來的體驗。多人游戲對于游戲為多人游戲的程度，則游戲將能夠不僅經由入埠路由1502網絡傳達到 應用程序/游戲服務器1521-1525，而且通過網絡橋接器傳達至具有不在主機服務210中 執行的服務器或游戲機器的互聯網(未圖示)。當通過通用互聯網上的計算機玩多人游戲 時，則應用程序/游戲服務器1521-1525將具有極快訪問互聯網的益處(與游戲在家庭中 的服務器上執行的情況相比)，但其將受在較緩慢連接上玩游戲的其他計算機的能力限制， 且也潛在地受互聯網上的游戲服務器被設計以適應最少共同點(common denominator)(所 述游戲服務器是相對較慢的消費者互聯網連接上的家庭計算機)的事實限制。但當完全在主機服務210服務器中心內玩多人游戲時，則可達到極大差異。對用 于用戶的游戲進行主機代管的每個應用程序/游戲服務器1521-1525將與其他應用程序/ 游戲服務器1521-1525以及用極高速度、極低延時連接性及巨大、非常快的儲存陣列對針 對多人游戲的中央控制進行主機代管的任何服務器互連。舉例而言，若超高速以太網用于 入埠路由1502網絡，則應用程序/游戲服務器1521-1525將在彼此當中傳達，且傳達到以 十億比特/秒速度在潛在的僅1毫秒或1毫秒以下的延時下對針對多人游戲的中央控制進 行主機代管的任何服務器。另外，RAID陣列1511-1512將能夠非常快速地響應且接著以十 億比特/秒速度傳送數據。作為一個實例，若用戶在外表及服裝方面定制人物，以使得人物 具有對于人物而言唯一的大量幾何形狀及行為，在限于在家庭中在PC或游戲控制臺上執 行的游戲客戶端的先前技術系統下，若所述人物將進入另一用戶的視野中，則用戶將必須 等待直到長的緩慢下載完成為止，以便將所有幾何形狀及行為數據載入其計算機中。在主 機服務210內，所述相同下載可優于以十億比特/秒速度從RAID陣列1511-1512服務的超 高速以太網。即使家庭用戶具有8Mbps互聯網連接(其根據現今的標準來看極快)，超高速 以太網也快100倍。因此，在快的互聯網連接上花費一分鐘進行的工作在超高速以太網上 將花費小于一秒。頂級玩家分群及錦標賽主機服務210極其適合于錦標賽。因為無游戲在本地客戶端中執行，所以不存在 用戶作弊的機會。而且，由于輸出路由1540多播UDP流的能力，使得主機服務210能夠同 時向觀眾中的數千人廣播較大錦標賽。事實上，當存在如此風行以致數千名用戶正接收相同流的特定視頻流時(例 如，顯示較大錦標賽的視圖)，可以更有效的將視頻流發送到內容傳送網絡(⑶N)(諸如， Akamai (阿卡邁公司)或Limelight (聚光燈公司))以用于大量分配到許多客戶端設備 415。當使用CDN來顯示頂級玩家分群的游戲取景器頁面時，可獲得類似水平的效率。對于較大錦標賽，可使用現場直播的名人解說員來在特定比賽期間提供評論。盡 管大量用戶將是在觀看較大錦標賽，且相對小數目將是在錦標賽中玩。可將來自名人解說 員的音頻路由到對在錦標賽中玩的用戶進行主機代管且對錦標賽中的游戲的任何旁觀者 模式復本進行主機代管的應用程序/游戲服務器1521-1525，且可將音頻加錄于游戲音頻 之上。可在游戲上(也可能剛好在旁觀者視圖上)疊加名人解說員的視頻。網頁載入的加速議(HTTP)是被構想并被限定在其中 僅商業具有高速互聯網連接，且在線的消費者使用撥號數據機或ISDN的時代中。此時，用 于快速連接的“黃金標準”是Tl線，其對稱地提供1. 5Mbps數據速率(也即，兩個方向中具 有相等數據速率)。現今，情形完全不同。大量發達世界中經由DSL或電纜調制解調器連接的平均家 庭連接速度具有比Tl線高得多的下行數據速率。事實上，在世界的一些地方中，光纖到路 邊(fiber-to-the-curb)正將高達50Mbps至IOOMbps的數據速率帶入家庭。遺憾地，HTTP沒有被架構(也沒有被實施)成有效地利用該急劇的速度改善。網 站為遠程服務器上的檔案的集合。非常簡單地說，HTTP請求第一檔案，等待下載該檔案，且 接著請求第二檔案，等待下載該檔案等。事實上，HTTP允許一個以上“開放連接”(也即，每 次請求一個以上檔案)，但由于商定的標準(及防止網絡服務器被超載的愿望)而使得僅準 許非常少的開放連接。此外，由于網頁被構造的方式，瀏覽器常常未意識到可用于立即下載 的多個同時頁面(也即，僅在剖析一個頁面之后才變得顯而易見需要下載如圖像的新檔 案)。因此，網站上的檔案實質上是逐個地載入。此外，由于由HTTP使用的請求及響應協 議，存在與所載入的每個檔案相關的大致(訪問美國的典型網絡服務器)100毫秒的延時。在相對低速連接的情況下，這不會引入大量問題，因為用于檔案本身的下載時間 決定網頁的等待時間。但是，隨著連接速度增大(尤其是復雜網頁情況下)，開始引起問題。在圖24中所顯示的實例中，顯示了典型商業網站(該特定網站來自較大的運動鞋 商標)。網站上具有54個檔案。檔案包括HTML、CSS、JPEG、PHP、JavaScript及Flash檔 案，且包括視頻內容。在現場直播網頁(也即，用戶可單擊該網頁并開始使用該網頁)之 前，必須載入總共1.5M字節。對于大量檔案存在許多原因。首先，該網頁為復雜且尖端的 網頁，且其次，該網頁為基于關于存取該頁面的用戶的信息動態地組合的網頁(例如，用戶 來自哪個國家，何種語言，用戶之前是否進行購買等)，且視所有這些因素而下載不同檔案。 但是，其仍為非常典型的商業網頁。圖24顯示隨著連接速度增大在現場直播網頁之前經過的時間量。在1. 5Mbps連接 速度2401下，使用具有傳統網絡瀏覽器的傳統網絡服務器，在現場直播網頁之前花費13. 5 秒。在12Mbps連接速度2402下，載入時間減少至6. 5秒，或約快一倍。但在96Mbps連接 速度2403下，載入時間僅減少至約5. 5秒。這個原因是因為在這種高下載速度下，下載檔 案本身的時間最小，但每個檔案各自大致100毫秒的延時仍保持，從而導致54個檔案*100 毫秒=5. 4秒的延時。因此，無論到家庭的連接多快，該網站在現場直播之前將總是花費至 少5. 4秒。另一因素是服務器側排隊；每個HTTP請求是在隊列的后部添加，因此在忙碌的 服務器上這將具有顯著影響，因為對于要從網絡服務器得到的每個小項目，HTTP請求需要 等待其返回。解決這些問題的一個方式是廢棄或重新限定HTTP。或者，可能使網站擁有者較佳 地將其檔案合并成單一檔案(例如，以Adobe Flash格式)。但是，作為一個實際問題，該 公司以及許多他人在其網站架構中具有大量投資。另外，盡管一些家庭具有12-lOOMbps連 接，但大多數家庭仍具有較緩慢的速度，且HTTP在緩慢速度下確實工作良好。一個替代方法是在應用程序/游戲服務器1521-1525上對網絡瀏覽器進行主機 代管，且在RAID陣列1511-1512上(或潛在地在對網絡瀏覽器進行主機代管的應用程序/
57游戲服務器1521-1525上的RAM中或本地儲存器上)對用于網絡服務器的檔案進行主機代 管。由于經由入埠路由1502 (或至本地儲存器)的非常快的互連，并非在使用HTTP下每檔 案具有100毫秒的延時，而是在使用HTTP下將存在每檔案最小延時。接著，并非使家庭中 的用戶經由HTTP存取網頁，而是用戶可經由客戶端415存取網頁。接著，甚至在1.5Mbps 連接下(因為此網頁不需要大量帶寬來用于其視頻)，網頁也將在每個線2400小于1秒的 時間內處于現場直播。實質上，在應用程序/游戲服務器1521-1525上執行的網絡瀏覽器 顯示現場直播的頁面之前將不存在延時，且在客戶端415顯示來自網絡瀏覽器的視頻輸出 之前將不存在可偵測到的延時。當用戶使用鼠標搜尋網頁和/或在網頁上鍵入字時，將用 戶的輸入信息發送至在應用程序/游戲服務器1521-1525上執行的網絡瀏覽器，且網絡瀏 覽器將相應地作出響應。此方法的一個不利之處是若壓縮器正恒定地傳輸視頻數據，則使用帶寬，即使網 頁變成靜態也如此。這可通過配置壓縮器以僅在(并且如果)網頁改變時才傳輸數據且接 著僅將數據傳輸到發生改變的頁面部分來補救。當存在具有恒定地改變的閃爍標語等的一 些網頁時，所述網頁往往令人討厭，且除非存在要移動某物(例如，視頻剪輯)的原因，否 則通常網頁為靜態的。對于所述網頁，可能為以下狀況使用主機服務210將傳輸較少數 據(與傳統網絡服務器相比)，因為將僅傳輸實際顯示的圖像，沒有精簡型客戶端可執行代 碼，且沒有可能從不被觀看的大對象(諸如，滾動翻轉圖像)。因此，使用主機服務210來對舊版網頁進行主機代管，可將網頁載入時間減少到 打開網頁是類似改變電視上的頻道的程度有效地即刻地現場直播該網頁。便于游戲及應用程序的除錯如先前所述，具有實時圖形的視頻游戲及應用程序為非常復雜的應用程序且通常 當其被發行到該領域中時，其含有缺陷。盡管軟件開發商將自用戶得到關于缺陷的反饋，且 其可能具有用于在崩潰之后將機器狀態傳回的一些方式，但確切地識別是什么引起游戲或 實時應用程序崩潰或不適當地執行非常困難。當游戲或應用程序在主機服務210中執行時，將游戲或應用程序的視頻/音頻輸 出恒定地記錄在延遲緩沖器1515上。另外，看門狗進程執行每個應用程序/游戲服務器 1521-1525，該看門狗進程將向主機服務控制系統401定期地報告應用程序/游戲服務器 1521-1525正平穩地執行。若看門狗進程未能報告，則服務器控制系統401將試圖與應用程 序/游戲服務器1521-1525通信，且若成功，則將收集可用的無論什么機器狀態。將無論什 么可用的信息連同由延遲緩沖器1515記錄的視頻/音頻一起發送到軟件開發商。因此，當游戲或應用程序軟件開發商自主機服務210得到崩潰的通知時，其得到 導致崩潰的原因的幀接幀的紀錄。該信息在追蹤到缺陷并將缺陷修復中可能是極具價值 的。還應該注意，當應用程序/游戲服務器1521-1525崩潰時，在最近的可重新啟動的 時刻重新啟動服務器，且將消息提供給用戶，從而就技術困難道歉。資源共用及成本節省圖4a及圖4b中所顯示的系統為終端用戶與游戲及應用程序開發商兩者提供多種 益處。舉例而言，通常，家庭及辦公室客戶端系統(例如，PC或游戲控制臺)僅在一周中的 小百分比的小時中處于使用中。根據由Nielsen(尼爾森)娛樂“Active Gamer BenchmarkStudy (活躍游戲者基準點研究)” (http://www. prnewswire. com/cgi-bin/stories, pi ？ ACCT = 104&ST0RY = /www/story/10-05-2006/0004446115&EDATE =)的 2006 年 10 月 5 日通信稿，活躍的游戲者一周平均花費14個小時來在視頻游戲控制臺上玩且約一周17個 小時在手持設備上玩。該報告還陳述對于所有游戲播放活動(包括控制臺、手持設備及 PC游戲播放)，活躍的游戲者平均一周13個小時。考慮較高數字的控制臺視頻游戲播放時 間，存在一周24*7 = 168個小時，這暗示在活躍游戲者的家中，視頻游戲控制臺僅在一周 的17/168 = 10%的小時中處于使用中。或者，90%的時間，視頻游戲控制臺是閑置的。給 定視頻游戲控制臺的高成本，及制造商資助所述設備的事實，這是昂貴資源的非常無效率 的使用。商業內的PC通常也僅在一周的一部分小時中使用，尤其是高端應用程序(諸如， Autodesk Maya)常常所需的非便攜式臺式PC。盡管一些商業在所有小時及假日都操作，且 一些PC(例如，帶回家以用于在晚上進行工作的便攜式PC)是在所有小時及假日使用，但大 多數商業活動傾向于在給定商業時區中集中在從周一至周五的約9AM至5PM、較少的假日 以及休息時間(諸如，午餐)，且因為大多數PC使用在用戶積極地利用PC時出現，所以其遵 循臺式PC的利用傾向于遵循這些操作小時數。若假定一周中的五天的自9AM至5PM不斷 地使用PC，則這將暗示PC在一周的40/168 = 24%的小時中被使用。高性能臺式PC是用 于商業的非常昂貴的投資，且這反映了非常低的利用度。在臺式計算機上教學的學校可在 一周的甚至更小部分中使用計算機，且盡管其視教學的小時數而改變，但大多數教學在自 周一至周五的日間小時期間出現。因此，一般而言，PC及視頻游戲控制臺僅在一周的小部 分小時中被利用。值得注意地，因為許多人在非假日的周一至周五的日間小時期間在商業或在學校 工作，所以這些人通常在這些小時期間不玩視頻游戲，且因此當其確實玩視頻游戲時，其通 常是在其他小時期間(諸如，晚上、周末及假日)。給定圖4a中所顯示的主機服務的配置，則上述兩段中所描述的使用模式導致資 源的非常有效的利用。顯而易見，存在對于可在給定時間由主機服務210來服務的用戶的 數目的限制，尤其在用戶需要用于復雜應用程序(如尖端3D視頻游戲)的實時響應性的情 況下。但是，不同于家庭中的視頻游戲控制臺或由商業使用的PC(其通常在大多數時間閑 置放置)，服務器402可由不同用戶在不同時間重新利用。舉例而言，具有高性能雙CPU及 雙GPU及大量RAM的高性能服務器402可由商業及學校在非假日的9AM至5PM利用，但由 玩尖端視頻游戲的游戲者在晚上、周末及假日利用。類似地，低性能應用程序可由商業及學 校在商業小時期間在具有Celeron (賽揚)CPU、無GPU (或非常低端的GPU)及有限RAM的低 性能服務器402上利用且低性能游戲可在非商業小時期間利用低性能服務器402。另外，在本文中所描述的主機服務配置的情況下，資源是在數千名(若非數百萬 名)用戶當中有效地共用。一般而言，在線服務僅具有其總用戶基礎的小百分比在給定 時間使用服務。若考慮先前所列出的Nielsen視頻游戲使用統計數據，則容易了解為什 么。若活躍游戲者一周僅17個小時玩控制臺游戲，且若假定游戲的峰值使用時間是在晚上 (5-12AM，7*5天=35小時/周)及周末(8AM-12AM，16*2 = 32小時/周)的典型非工作、 非商業小時期間，則對于17個小時的游戲播放，一周存在35+32 = 65個峰值小時。由于 以下許多原因而使得難以估計系統上的確切峰值用戶負載一些用戶將在峰值外時間期間 玩，可能存在特定日間時間存在用戶的叢集(clustering)峰值，峰值時間可受所玩游戲的類型(例如，孩子的游戲將可能是在晚上的較早時間玩)等影響。但是，假定當游戲者可能 玩游戲時，游戲者玩的平均小時數遠小于日間的小時數，則僅主機服務210的一部分數目 的用戶將是在給定時間使用主機服務210。為了該分析，我們假定峰值負載為12.5%。因 此，僅12. 5%的計算、壓縮及帶寬資源是在給定時間使用，從而由于資源的再使用而導致僅 12. 5%的硬件成本來支持給定用戶玩性能游戲的給定級別。此外，假定一些游戲及應用程序需要比其他者多的計算能力，則可基于被用戶玩 的游戲或由用戶執行的應用程序來動態地分配資源。因此，選擇低性能游戲或應用程序的 用戶將被分配低性能(較低廉)服務器402，且選擇高性能游戲或應用程序的用戶將被分配 高性能(較昂貴)服務器402。實際上，給定游戲或應用程序可能具有游戲或應用程序的 較低性能及較高性能區，且可在游戲或應用程序的區之間將用戶從一個服務器402切換到 另一服務器402，以保持用戶在滿足游戲或應用程序的需要的最低成本服務器402上執行。 注意，比單個磁盤快得多的RAID陣列405將可以被甚至低性能服務器402所用，這具有較 快磁盤傳送速率的益處。因此，跨越所有所玩游戲或所使用的應用程序的每服務器402平 均成本比玩最高性能游戲或應用程序的大多數昂貴服務器402的成本小得多，然而，即使 低性能服務器402也會從RAID陣列405得到磁盤性能益處。另外，主機服務210中的服務器402可能只是不具有磁盤或周邊接口(不同于網 絡接口)的PC主機板，且恰好，可向下整合成剛好具有到SAN 403的快速網絡接口的單個 芯片。而且，RAID陣列405可能將在比存在磁盤的情況多得多的用戶當中共用，因此每個活 躍的用戶的磁盤成本將遠小于一個磁盤驅動器。所有該設備將可能駐留于環境上受控制的 服務器室環境中的支架中。若服務器402出故障，則其可容易地在主機服務210處進行修 理或替換。相比之下，家庭或辦公室中的PC或游戲控制臺必須堅固，必須能夠幸免于合理 的磨損及撕裂以防被重擊或降落的獨立器具需要外殼，具有至少一個磁盤驅動器，必須幸 免于不利的環境條件(例如，被勉強塞入具有其他用具的過熱AV櫥柜中)，需要服務保證， 必須被封裝及裝運，且由可能收取零售利潤的零售商來出售。另外，PC或游戲控制臺必須 被配置以滿足將在未來某一時刻使用的計算上最密集的預期游戲或應用程序的峰值性能， 即使較低性能游戲或應用程序(或游戲或應用程序的區)也可能在大多數時間玩。此外， 若PC或控制臺出故障，則使其得到修理是昂貴且耗時的過程(不利地影響制造商、用戶及 軟件開發商)。因此，假定圖4a中所顯示的系統將相當于本地計算資源的體驗的體驗提供給用 戶，以供用戶在家庭、辦公室或學校中體驗給定水平的計算能力，則通過圖4a中所顯示的 架構提供所述計算能力要低廉得多。消除對升級的需要另外，用戶不必再擔憂將PC和/或控制臺升級以玩新游戲或處理較高性能的新 應用程序。主機服務210上的任何游戲或應用程序(不管所述游戲或應用程序需要何類 型的服務器402)均可為用戶所用，且所有游戲及應用程序接近即刻地執行(也即，快速地 從RAID陣列405或服務器402上的本地儲存器載入)且適當地具有最新更新及缺陷修復 (也即，軟件開發商將能夠選擇用于執行給定游戲或應用程序的服務器402的理想服務器 配置，且接著將服務器402配置有最佳驅動器，且接著隨著時間的推移，開發商將能夠同時 將更新、缺陷修復等提供給主機服務210中的游戲或應用程序的所有復本)。實際上，在用
60戶開始使用主機服務210之后，用戶可能發現游戲及應用程序繼續提供較佳體驗(例如，經 由更新和/或缺陷修復)且可能是以下狀況用戶一年后發現新游戲或應用程序可用于利 用計算技術(例如，較高性能的GPU)(其在一年前甚至不存在)的服務210上，因此對于用 戶而言，將不可能購買將在一年后玩游戲或執行應用程序的一年前的技術。因為玩游戲或 執行應用程序的計算資源對于用戶而言不可見(也即，自用戶的觀點看，用戶僅選擇開始 接近即刻地執行的游戲或應用程序_更像用戶改變電視上的信道)，所以用戶的硬件將在 用戶甚至未意識到升級的情況下已被“升級”。消除對于備份的需要對于商業、學校及家庭中的用戶的另一較大問題是備份。若磁盤出故障，或若存在 無意擦除，則儲存在本地PC或視頻游戲控制臺中的信息(例如，在控制臺的狀況下，用戶的 游戲成果及等級)可能丟失。存在提供用于PC的手動或自動備份的許多可用的應用程序， 且可將游戲控制臺狀態上傳至在線服務器以供備份，但通常將本地備份復制至必須儲存于 安全且有組織的某處的另一本地磁盤(或其他非揮發性儲存設備)，且由于經由典型低成 本互聯網連接可用的緩慢上行速度而使得對于在線服務的備份常常有限。在圖4a的主機 服務210下，儲存于RAID陣列405中的數據可使用為本領域技術人員所熟知的先前技術 RAID配置技術來配置，以使得當磁盤出故障時，將不丟失數據，且將通知在容納出故障的磁 盤的服務器中心處的技術員，且接著技術員將替換該磁盤，該磁盤接著將被自動地更新以 使得RAID陣列再一次容忍故障。另外，因為所有磁盤驅動器彼此接近且其間具有經由SAN 403的快速本地網絡，所以在服務器中心中將所有磁盤系統配置定期地備份到次級儲存器 (其可儲存于服務器中心處或者經易地重新定位)并不困難。從主機服務210的用戶的觀 點看，其數據始終完全安全，且其從不必考慮備份。對演示的存取用戶經常希望在購買游戲或應用程序的前試用游戲或應用程序。如先前所述，存 在先前技術裝置，通過該先前技術裝置來演示(“演示”的動詞形式意思是試用演示版本，演 示版本也被稱為“演示”，但作為名詞)游戲及應用程序，但其中的每一者遭受限制和/或不 便利。使用主機服務210，對于用戶而言，容易且便于試用演示。實際上，用戶所進行的系經 由用戶接口(諸如，下文所描述的用戶接口)選擇演示且試用該演示。演示將幾乎即刻地 載入適合于該演示的服務器402上，且其將完全類似任何其他游戲或應用程序而執行。無 論演示需要非常高性能的服務器402還是低性能的服務器402，且無論用戶使用的家庭或 辦公室客戶端415是何類型，自用戶的觀點看，演示均將工作。游戲演示或應用程序演示的 軟件出版商將能夠確切地控制準許用戶試用何演示及試用多長時間，且當然，演示可包括 為用戶提供獲得對所演示的游戲或應用程序的全版本的存取機會的用戶接口要素。因為演示可能是低于成本價或免費提供，所以一些用戶可能試圖使用重復的演示 (尤其是重復地玩可能有趣的游戲演示)。主機服務210可使用各種技術來限制用于給定 用戶的演示使用。最直接的方法是建立用于每個用戶的用戶ID且限制允許給定用戶ID播 放演示的次數。然而，用戶可設置多個用戶ID，尤其是其是自由的情況下。用于解決此問 題的一個技術是限制允許給定客戶端415播放演示的次數。若客戶端為獨立設備，則該設 備將具有一序號，且主機服務210可限制演示可由具有所述序號的客戶端存取的次數。若 客戶端415正以PC或其他設備上的軟件執行，則可由主機服務210來指派序號且將該序號儲存于PC上并使用該序號來限制演示使用，但假定PC可由用戶來重新程序化，且序號被擦 除或改變，則另一選項是主機服務210保持PC網絡適配器媒體訪問控制(MAC)地址(和/ 或其他機器特定識別符，諸如硬盤驅動器序號等)的紀錄并將演示使用限制于該MAC地址。 假定可改變網絡適配器的MAC地址，然而，這并非極簡單的方法。另一方法是限制演示可被 播放到給定IP地址的次數。盡管可由電纜調制解調器及DSL提供者來周期性地重新指派 IP地址，但其在實踐中不會非常頻繁地發生，且若可確定(例如，通過聯系ISP) IP是處于用 于住宅DSL或電纜調制解調器存取的IP地址的區塊中，則通常可建立用于給定家庭的小數 目的演示使用。而且，在家庭中在共用同一 IP地址的NAT路由器之后可能存在多個設備， 但通常在住宅背景中，將存在有限數目的所述設備。若IP地址是處于服務商業的區塊中， 則可建立用于商業的較大數目的演示。但是，最后，所有先前所述方法的組合是限制PC上 的演示的數目的最佳方式。盡管可能不存在使得所確定的且技術上熟練的用戶可能在重復 播放演示的數目中受到限制的極簡單的方式，但建立大量障礙可建立足夠阻礙以使得大多 數PC用戶不值得費神去濫用演示系統，且相反，其在其意欲試用新游戲及應用程序時使用 演示。對學校、商業及其他機構的益處顯著益處尤其出現在利用圖4a中所顯示的系統的商業、學校及其他機構。商業及 學校具有與安裝、維護及升級PC相關聯的實質成本，尤其當談及執行諸如Maya的高性能應 用程序的PC時。如先前所陳述，PC通常僅在一周的小時的一部分中被利用，且如在家庭中， 具有給定水平的性能能力的PC在辦公室或學校環境中的成本遠高于在服務器中心環境中 的成本。在較大商業或學校(例如，大的大學)的狀況下，所述實體的IT部門設置服務 器中心且維護經由LAN級連接而遠程地存取的計算機可以是實際的。存在用于經由LAN 或經由辦公室之間的私用高帶寬連接而遠程存取計算機的許多解決方法。舉例而言， 通過Microsoft的Windows終端機服務器，或者通過虛擬網絡計算應用程序(如來自 RealVNC(遠程控制)有限公司的VNC)或者通過來自Sun Microsystems (太陽計算機系統 公司)的精簡型客戶端裝置，用戶可獲得對PC或服務器的遠程存取，在圖形響應時間及用 戶體驗中具有一定范圍的質量。另外，所述自行管理的服務器中心通常專用于單個商業或 學校，且因此不能夠利用在全異應用程序(例如，娛樂及商業應用程序)在一周的不同時間 利用同一計算資源時所可能的使用的重疊。因此，許多商業及學校缺乏獨立設置具有至每 一用戶的LAN速度的網絡連接的服務器中心的規模、資源或專門技能。實際上，大百分比的 學校及商業具有與家庭相同的互聯網連接(例如，DSL、電纜調制解調器)。然而，所述組織仍可能具有對于非常高性能的計算的需要(或者定期地或者周期 性地)。舉例而言，小建筑公司可能僅具有小數目的建筑師，當進行設計工作時，具有相對適 度的計算需要，但其可能周期性地需要非常高性能的3D計算(例如，當建立用于客戶端的 新建筑設計的3D飛越時)。圖4a中所顯示的系統極其適合于所述組織。所述組織僅需要 為提供至家庭的同一種類的網絡連接(例如，DSL、電纜調制解調器)且通常非常低廉。其 可利用低廉的PC作為客戶端415，或者完全沒有PC也可以，而利用簡單實施控制信號邏輯 413及低延時視頻解壓縮412的低廉的專用設備。該特征對于可能具有PC的偷竊或對PC 內的專用組件的損壞的問題的學校特別有吸引力。
62
這種配置解決了用于所述組織的許多問題(且許多這種優點也為進行通用計算 的家庭用戶共用)。舉例而言，操作成本(其最終必須以某種形式傳遞回至用戶以便具有 可行的商業)可能低得多，因為(a)計算資源是與在一周中具有不同峰值使用時間的其他 應用程序共用，(b)所述組織可僅在需要時獲得(且招致成本)對高性能計算資源的存取， (c)所述組織不必提供用于備份或以其他方式維護高性能計算資源的資源。盜版的消除另外，游戲、應用程序、互動式電影等可能不再如現今這樣被盜版。因為游戲是在 服務器中心處執行，所以用戶不具備對于基本程序碼的存取，因此不存在盜版。即使用戶將 要復制原始碼，用戶也不能夠在標準游戲控制臺或家庭計算機上執行該碼。此打開了標準 視頻游戲不可用的世界各地(諸如，中國)的市場。已使用的游戲的重新銷售也是不可能 的。對于游戲開發商而言，如同現今的狀況，存在較少市場不連續性。與全新的一代技 術迫使用戶及開發商升級且游戲開發商取決于硬件平臺的及時傳送的當前情形對比，可隨 著時間隨著游戲要求改變而逐漸地更新主機服務210。流動互動式視頻以上描述提供由以通用互聯網為基礎的低延時流動互動式視頻(其隱含地也包 括連同視頻一起的音頻，如本文中所使用)的新穎基本概念致能的多種應用。經由互聯網 而提供流動視頻的先前技術系統僅具有可通過高延時互動實施的所致能的應用。舉例而 言，用于線性視頻的基本回放控制(例如，暫停、回倒、快進)在高延時下適當地工作，且有 可能在線性視頻饋送當中進行選擇。此外，如先前所陳述，一些視頻游戲的性質允許其以高 延時來播放。但是，用于流動視頻的先前技術方法的高延時(或低壓縮比率)嚴重限制流 動視頻的潛在應用或使其部署變窄到專門化的網絡環境，且甚至在所述環境中，先前技術 也引入網絡上的實質負擔。本文中所描述的技術打開了在經由互聯網的低延時流動互動式 視頻下可能的多種應用的大門，尤其是經由消費者級互聯網連接而致能的所述應用。實際上，在與圖4c的客戶端465 —般小的客戶端設備下，足以通過有效的任意量 的計算能力、任意量的快速儲存及強大服務器之間的極快網絡連接而提供增強的用戶體 驗，其使新的計算時代成為可能。另外，因為帶寬要求并不隨著系統的計算能力增長而增長 (也即，因為帶寬要求僅關于顯示分辨率、質量及幀速率)，所以一旦寬帶互聯網連接性是 普遍存在的(例如，經由分布廣的低延時無線涵蓋)、可靠的且具有足以滿足所有用戶的顯 示設備422的需要的足夠高的帶寬，則問題將是典型消費者及商業應用所必要的是厚重客 戶端(諸如，執行Windows、Linux、OSX等的PC或移動電話)還是甚至精簡型客戶端(諸 如，Adobe Flash 或 Java)。流動互動式視頻的出現導致關于計算架構的結構的假定的重新考慮。該一個實例 是圖15中所顯示的主機服務210服務器中心實施例。用于延遲緩沖G器和/或分群視頻 1550的視頻路徑是反饋回路，其中應用程序/游戲服務器1521-1525的經多播的流動互動 式視頻輸出經由路徑1552而實時地或者經由路徑1551在可選擇的延遲之后被反饋回到應 用程序/游戲服務器1521-1525中。這使得通過先前技術服務器或本地計算架構將是不可 能或不可行的多種實際應用(例如，諸如圖16、圖17及圖20中所說明的應用)成為可能。 但是，作為更一般的架構特征，反饋回路1550所提供的是流動互動式視頻水平下的遞歸，因為可在應用程序需要視頻時將視頻無限地循環。這使得之前從未可用的多種應用可能性 成為可能。另一關鍵架構特征在于視頻流是單向UDP流。這有效地實現流動互動式視頻的 任意程度的多播(相比之下，諸如TCP/IP流的雙向流將隨著用戶的數目增加而在來自來回 通信的網絡上產生越來越多的通信停滯)。多播是服務器中心內的重要能力，因為其允許系 統對互聯網用戶(且實際上，世界的人口)的增長的需要作出響應以在一對多或甚至多對 多基礎上通信。再次，本文中所論述的說明流動互動式視頻遞歸與多播兩者的使用的實例 (諸如，圖16)僅為具有可能性的非常大的冰山的尖端。在一個實施例中，本文中所說明的各種功能模組及相關聯的步驟可由含有用于執 行所述步驟的固線式邏輯的特定硬件組件(諸如，特殊用途集成電路(“ASIC”))或由被編 程的計算機組件與定制硬件組件的任何組合來執行。在一個實施例中，可將所述模組實施于諸如Texas儀器的TMS320x架構(例如， TMS320C6000, TMS320C5000,...等)的可編程數字信號處理器(“DSP”)上。可使用各種 不同的DSP，同時仍遵守所述基本原理。實施例可包括如上文所闡述的各種步驟。所述步驟可體現于引起通用或專用處理 器執行特定步驟的機器可執行指令中。已將與這些基本原理無關的各種元件(諸如，計算 機存儲器、硬碟機、輸入設備)從圖中省去以避免混淆相關方面。所公開的標的物的要素也可作為用于儲存機器可執行指令的機器可讀媒體來提 供。機器可讀媒體可包括(但不限于)閃存、光碟、CD-ROM、DVDROM、RAM、EPR0M、EEPR0M、磁 卡或光卡、傳播媒體或適合于儲存電子指令的其他類型的機器可讀媒體。舉例而言，本發明 可作為計算機程序來下載，該計算機程序可經由通信鏈路(例如，數據機或網絡連接)借助 于體現在載波或其他傳播媒體中的數據信號而從遠程計算機(例如，服務器)傳送到請求 計算機(例如，客戶端)。還應理解，所公開的標的物的要素也可作為計算機程序產品來提供，該計算機程 序產品可包括在上面儲存有指令的機器可讀媒體，所述指令可用于程序化計算機(例如， 處理器或其他電子設備)以執行一序列操作。或者，所述操作可通過硬件與軟件的組合來 執行。機器可讀媒體可包括(但不限于)軟盤、光盤、CD-ROM，及磁光盤、ROM、RAM、EPROM、 EEPR0M、磁卡或光卡、傳播媒體或適合于儲存電子指令的其他類型的媒體/機器可讀媒體。 舉例而言，所公開的標的物的要素可作為計算機程序產品來下載，其中程序可經由通信鏈 路(例如，數據機或網絡連接)借助于體現于載波或其他傳播媒體中的數據信號而自遠程 計算機或電子設備傳送至請求過程。另外，盡管已結合特定實施例描述所公開的標的物，但眾多修改及變更將適當地 處于本公開的范疇內。因此，說明書及圖式應視為說明性的而非限制性的意義。
6權利要求
一種用計算機實施的用于執行視頻壓縮的方法，該方法包括檢測服務器和客戶端之間的通信信道的最大數據速率；將包括一系列順序幀的視頻流從所述服務器傳送到所述客戶端；檢測在將所述幀的序列中的特定幀通過所述通信信道從所述服務器傳送到所述客戶端的情況下是否會超出所述最大數據速率；使所述客戶端對所述幀的序列中的先前的幀進行再現，而不再傳送將導致所述最大數據速率被超出的幀，從而有效地減小在所述客戶端上顯現的所述視頻流的幀速率。
2.根據權利要求1所述的方法，該方法還包括選擇一組壓縮參數，以用于基于所述最大數據速率對所述視頻流的幀進行壓縮。
全文摘要
本發明描述一種用于使用幀間編碼來編碼互動式低延時視頻的系統及方法。舉例而言，一種用于執行視頻壓縮的計算機實施的方法的一個實施例包含檢測服務器和客戶端之間的通信信道的最大數據速率；將包括一系列順序幀的視頻流從所述服務器傳送到所述客戶端；檢測在將所述幀的序列的特定幀通過所述通信信道從所述服務器傳送到所述客戶端的情況下是否會超出所述最大數據速率；使所述客戶端對所述幀的序列中的先前的幀進行再現，而不再傳送將導致所述最大數據速率被超出的幀，從而有效地減小在所述客戶端上顯現的所述視頻流的幀速率。
文檔編號H04N7/12GK101919242SQ200880119260
公開日2010年12月15日 申請日期2008年12月4日 優先權日2007年12月5日
發明者R·范德拉安, S·G·珀爾曼 申請人:生命力有限公司