將線性內容與壓縮後的交互式內容一起組合為流動交互式視頻的方法

2023-05-21 14:20:31

專利名稱：將線性內容與壓縮後的交互式內容一起組合為流動交互式視頻的方法
技術領域：
本公開總體上涉及改善用戶操作及存取音頻和視頻媒體的能力的數據處理系統 的領域。
背景技術：
自從託馬斯·愛迪生(Thomas Edison)時代以來，記錄的音頻及電影媒體已成為 社會的一方面。在20世紀初期，記錄的音頻媒體(磁柱及唱片)及電影媒體(投幣式自動 點唱機及電影)廣泛發行，但兩種技術仍處於其起步階段。在20世紀20年代後期，在大 眾市場的基礎上將電影與音頻組合，之後將彩色電影與音頻組合。無線電廣播逐漸演變成 很大程度上支持廣告的形式的廣播大眾市場音頻媒體。當在20世紀40年代中期建立電視 (TV)廣播標準時，電視與無線電以廣播大眾市場媒體的形式接合，從而將先前記錄的或現 場直播的電影帶入家庭中。至20世紀中期為止，大部分美國家庭已具有用於播放記錄的音頻媒體的唱片播 放器(phonograph record player)、用於接收現場直播的廣播音頻的無線電設備，及用於 播放現場直播的廣播音頻/視頻(A/V)媒體的電視機。常常將所述3個「媒體播放器」(唱 片播放器、無線電設備及TV)組合到共有公共揚聲器的櫥櫃中，變成家庭的「媒體中心」。盡 管對於消費者而言媒體選擇有限，但媒體「生態系統」非常穩定。大多數消費者知道如何使 用「媒體播放器」且能夠享受其能力的全部範圍。同時，媒體的出版商(大多為電影和電視 工作室，及音樂公司)能夠將其媒體分配給電影院與家庭兩者，而不遭受廣泛的盜版或「二 次銷售」(也即，已使用媒體的重新銷售)。通常，出版商不會從二次銷售得到收入，且因此， 二次銷售減少了出版商對於新的銷售從原本可自己使用媒體的購買者得到的收入。儘管在 20世紀中期期間的確存有已使用的唱片出售，但所述銷售不會對唱片出版商有大影響，因 為不同於電影或視頻節目(其通常被成年人觀看一次或僅數次)，音樂曲目可被收聽數百 次或甚至數千次。因此，音樂媒體遠比電影/視頻媒體「經久」(也即，對於成年消費者而 言，其具有持久價值)。一旦購買了唱片，若消費者喜歡該音樂，則消費者可能將其保持很長 時間。自20世紀中期到現在，媒體生態系統對於消費者與出版商的利益及損失來說都 經歷了一系列根本改變。在音頻錄音機(尤其是具有高質量立體聲的盒式磁帶)的廣泛 引入的情況下，的確有較高程度的消費者便利。但其也標誌著現在廣泛的消費者媒體實 踐_盜版的開始。的確，許多消費者純粹出於便利起見而使用盒式磁帶來錄製其自己的唱片，但日益增加的消費者(例如，宿舍中準備存取彼此的唱片收集的學生)將進行盜版復 制。而且，消費者將錄製經由無線電播放的音樂，而非從出版商購買唱片或磁帶。消費者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) 中。儘管所述設備中的每個設備對其執行的功能提供一點便利，但每個設備缺乏對大多數 媒體的普遍且簡單的存取。另外，常常由於昂貴的處理和/或本地儲存的需要而使得所述 設備經常花費數百美元來製造。另外，所述現代的消費者電子設備通常消耗大量電力，甚至 當閒置時也消耗大量電力，這意謂著其隨著時間而更加昂貴且浪費能源。舉例而言，若消費 者忘記將設備切斷或將其切換到不同視頻輸入端，則該設備可能繼續操作。此外，因為所述 設備當中沒有一個設備為完全的解決方案，所以必須將其與家庭中的其他設備的堆棧整合 在一起，這仍對用戶留下鼠窩式線及許多遠程控制。
此外，當許多較新的以網際網路為基礎的設備適當地工作時，其通常提供更一般形 式(與其原本可能可用的形式相比)的媒體。舉例而言，使視頻經由網際網路流動的設備常 常僅使視頻材料流動，而不能使常常伴隨DVD的互動式「額外項目」流動，如視頻的「製作」、 遊戲或導演評論。這是由於以下事實互動式材料經常是以特定格式製作，該特定格式意 欲用於在本地處理互動性的特定設備。舉例而言，DVD、HD-DVD及藍光光碟中每一者具有其 自身的特定互動格式。任何家庭媒體設備或本地計算機(其可能經開發以支持所有流行格 式)將需要一定程度的尖端性(sophistication)及靈活性，其將可能對於消費者操作而言 過於昂貴及複雜。使該問題加重，若稍後在將來引入新格式，則本地設備可能不具有支持新格式的 硬體能力，這將意味著消費者將必須購買升級的本地媒體設備。舉例而言，若在稍後的日期 引入較高解析度的視頻或立體視頻(例如，每一隻眼一個視頻流)，則本地設備可能不具有 解碼該視頻的計算能力，或其可能不具有用於以新格式輸出該視頻的硬體(例如，假定通 過與遮光眼鏡(shuttered glassess)同步的120fps視頻來實現立體視覺，其中將60fps 傳送到每一隻眼，若消費者的視頻硬體僅可支持60fps視頻，則該選項在缺乏升級的硬體 購買的情況下將不可用)。當談及尖端的互動式媒體(尤其是視頻遊戲)時，媒體設備廢棄及複雜度的問題 為嚴重問題。現代視頻遊戲應用基本上劃分成四個主要非可攜式式硬體平臺 Sony PlayStation 1、2 及 3 (PSl、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系列。可利用技術來模仿先前架構，但假定視頻遊戲為實時應用程式，則在模仿中達成 完全相同的行為常常不切實際。這是對消費者、視頻遊戲控制臺製造商及視頻遊戲軟體出版商的損失。對於消費者而言，這意味著將舊的一代視頻遊戲控制臺與新的一代視頻遊戲 控制臺兩者保持接通到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)圖像一樣逼真的計算機圖形)的人物、道具及環境。照片一樣逼真的遊戲開發的最具挑戰方面中的一者為創建不能區別 於實景人臉的計算機產生的人臉。面部捕獲技術(諸如，由加州的聖弗朗西斯科的Mova開 發的Contour (輪廓 )真實性捕獲系統)捕獲表演者的面部的精確幾何形狀並在表演者 處於運動中時以高解析度追蹤表演者的面部的精確幾何形狀。此技術允許在PC或遊戲控 制臺上再現3D面部，該3D面部實際上不能區別於所捕獲的實景面部。精確地捕獲及再現 「照片一樣逼真的」人臉在多個方面是有用的。首先，高度可識別的名人或運動員常常用於 視頻遊戲中(常常被高成本僱用)，且不完美性可能對於用戶而言顯而易見，從而使觀看體 驗(viewing experience)分心或令人不愉快。經常地，需要高度細節來實現高度的照片一 樣的逼真感_潛在地需要再現大量多邊形及高解析度紋理(在多邊形和/或紋理在幀接幀 的基礎上隨著面部移動而改變的情況下)。當具有詳細紋理的高多邊形計數場景快速改變時，支持遊戲的PC或遊戲控制臺 可能不具有足夠的RAM來儲存用於遊戲片段中所產生的所需數目的動畫幀的足夠多邊形 及紋理數據。另外，通常可用於PC或遊戲控制臺上的單個光學驅動器或單個磁碟驅動器通 常比RAM緩慢得多，且通常不能跟上GPU在再現多邊形及紋理中可接受的最大數據速率。當 前遊戲通常將大多數多邊形及紋理載入到RAM中，這意味著給定場景在複雜度及持續時間 上很大程度上受RAM的容量限制。在例如面部動畫製作的狀況下，這可能將PC或遊戲控制 臺限制於並無真實感的低解析度面部，或限制於僅可在遊戲暫停且載入用於更多幀的多邊 形及紋理(及其他數據)之前在有限數目的幀中製作成動畫的真實感面部。當PC或控制臺顯示類似於「正在載入...」的消息時，觀看進程條跨屏幕緩慢地 移動被現今的複雜視頻遊戲的用戶公認為是內在缺點。下一個場景從磁碟(除非另外有 條件，否則本文中的「磁碟」指非易失性光學媒體或磁性媒體，以及諸如半導體「快閃記憶體」存儲 器的非磁碟媒體)載入時的延遲可花費若干秒或甚至若干分鐘。這浪費時間且可能使遊戲 玩家相當沮喪。如先前所述，大量或所有延遲可能是由於來自磁碟的多邊形、紋理或其他數 據的載入時間，但也可能是以下狀況當PC或控制臺中的處理器和/或GPU準備用於場景 的數據時，花費一部分載入時間。舉例而言，英式足球視頻遊戲可允許玩家在大量玩家、小 組、運動場及天氣條件當中選擇。因此，取決於選擇什麼特定組合，可能需要用於場景的不 同多邊形、紋理及其他數據(統稱「對象」)(例如，不同小組在其制服上具有不同色彩及圖 案)。可能要列舉各種排列中的許多或所有排列且提前預先計算對象中的許多或所有對象 並將對象儲存在用於儲存遊戲的磁碟上。但是，若排列的數目很大，則所有對象所需的儲存 量可能過大以致不能安裝在磁碟上(或太不切實際以致不能下載)。因此，現有的PC及控 制臺系統通常在給定場景的複雜度與播放持續時間兩者上受約束且對於複雜場景遭受長 的載入時間。先前技術的視頻遊戲系統及應用程式軟體系統的另一顯著限制在於其越來越多 地使用例如3D對象的大資料庫(諸如，多邊形及紋理)，所述大資料庫需要被載入到PC或 遊戲控制臺中以用於處理。如上所述，當將所述資料庫在本地儲存於磁碟上時，所述資料庫 可花費長時間來載入。然而，若資料庫系儲存於遠程位置且經由網際網路來存取，則載入時間 通常嚴重得多。在此種情形下，下載大資料庫可能花費幾分鐘、幾小時或甚至幾天。另外， 所述資料庫常常產生大量費用(例如，用於遊戲、電影或歷史記錄片中的詳細的高的有桅 帆船的3D模型)且意欲用於銷售給本地終端用戶。然而，一旦資料庫被下載至本地用戶，其就有被盜版的風險。在許多狀況下，用戶僅為了評估資料庫來觀看其是否適合用戶的需 要(例如，當用戶執行特定移動時，用於遊戲人物的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(或通用生產力應用程式，類似MicrosoftOffice)有限得多的 目標受眾且通常以比通用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和/或控制臺)的視頻輸出饋送至用於電視頻道的視頻 分配及處理設備中來完成。這正如電視頻道廣播現場直播的籃球比賽時的情況，其中若干 個相機從籃球場周圍的不同角度提供現場直播的饋送。電視頻道接著能夠利用其視頻/音 頻處理及效應設備來操作來自各種視頻遊戲系統的輸出。舉例而言，電視頻道可在來自視 頻遊戲的視頻之上疊加指示不同玩家的狀態的文字(正如其可在現場直播的籃球比賽期 間疊加文字)，且電視頻道可加錄來自評論員(其可論述在比賽期間出現的動作)的音頻。 另外，可將視頻遊戲輸出與記錄遊戲的實際玩家的視頻的相機(例如，顯示玩家對遊戲的 情緒反應)組合。該方法的一個問題在於必須實時地使所述現場直播的視頻饋送為電視頻道的視 頻分配及處理設備可用，以便使其具有現場直播的廣播的刺激性。然而，如先前所述，當視 頻遊戲系統從家庭執行時(尤其是當廣播的一部分包括來自正捕獲遊戲玩家的真實世界 視頻的相機的現場直播的視頻時)，這常常不可能。另外，在錦標賽情形下，所關注的是家庭 中遊戲者可修改遊戲及作弊，如先前所述。由於這些原因，電視頻道上的所述視頻遊戲廣播 常常配置有聚集於公共位置處(例如，在電視演播室處或在競技場中)的播放器及視頻遊 戲系統，其中電視製作設備可接受來自多個視頻遊戲系統及潛在的現場直播的相機的視頻 饋送。儘管所述先前技術視頻遊戲電視頻道可為電視觀眾提供非常刺激的演出(這是 與現場直播的運動事件同類(例如，與以「運動員」呈現的視頻遊戲玩家同類)的體驗，不 僅根據其在視頻遊戲世界中的動作，而且根據其在真實世界中的動作)，但這些視頻遊戲系 統常常限於玩家彼此身體上極接近的情形。此外，因為電視頻道被廣播，所以每個被廣播的 頻道僅可顯示由電視頻道的製作人員選擇的一個視頻流。由於這些限制及廣播時間、製作 設備及製作人員的高成本，所述電視頻道通常僅顯示參加頂級錦標賽的頂級玩家。另外，向全部電視觀眾廣播視頻遊戲的全屏幕圖像的給定電視頻道每次僅顯示一個視頻遊戲。這嚴重地限制電視觀看者的選擇。舉例而言，電視觀看者可能對給定時間顯 示的遊戲不感興趣。另一觀看者可能僅對觀看並非由電視頻道在給定時間放映的特定玩家 的遊戲播放感興趣。在其他狀況下，觀看者可能僅對觀看內行玩家如何處理遊戲中的特定 級別感興趣。其他觀看者可能希望控制觀看點(視頻遊戲從該觀看點來看)，該觀看點不同 於由製作小組等選擇的觀看點。簡言之，電視觀看者在觀看視頻遊戲中可能具有無數的偏 好(即使若干個不同電視頻道可用，電視網絡的特定廣播也不適應所述偏好)。由於所有上 述原因，使得先前技術視頻遊戲電視頻道在向電視觀看者呈現視頻遊戲中具有顯著限制。先前技術視頻遊戲系統及應用程式軟體系統的另一缺點在於他們很複雜，且通 常遭受錯誤、崩潰和/或無意識且不需要的行為(統稱「缺陷」)。儘管遊戲及應用程式在 發行之前通常經歷除錯及調諧過程(經常稱為「軟體質量保證」或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年代的遊戲，其僅需要幾千字節的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幀之前存在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為示出了在現場直播網頁之前消逝的時間量與連接速度的曲線圖。
具體實施例方式在以下描述中列舉了特定細節(諸如，設備類型、系統配置、通信方法等)，以便提 供對本公開的徹底理解。然而，一般本領域的技術人員應了解，實踐所描述的所述實施例可 能不需要這些特定細節。圖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中的峰值指示)，則可出現若干問題。舉例而言，一些網際網路服務將僅丟棄 分組，從而導致用戶的視頻屏幕上的丟失的數據及失真的/丟失的圖像。其他服務將暫時緩衝(也即，排隊)額外分組且以可用數據速率將所述分組提供到客戶端，從而導致延時的 增加-對於許多視頻遊戲及應用程式而言為不可接受的結果。最後，一些網際網路服務提供 者將數據速率的增加視為惡意攻擊(諸如，否認服務攻擊(由計算機黑客用以使網絡連接 停用的公知技術))，且將在特定時間周期中切斷用戶的網際網路連接。因此，本文中所描述的 實施例設法確保用於視頻遊戲的所需數據速率不會超過最大可用數據速率。主機服務架構圖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，以較不頻繁地存取幾何形 狀或遊戲狀態信息的大資料庫。
22
另外，在一個實施例中，主機服務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的公司為澳大利亞新南 威爾斯州(NSW Australia)的Ocean LogicofManly0使用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提供的所有接口均為相當標準的接口且容易以許多形式可用。音頻輸出子系統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。
26
伺服器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毫秒 (當然，更欠佳的版本可花費更長時間，但所述實施將影響來回行程的總延時且將需要其他延時較短(例如，可減小經由通用網際網路的可允許的距離)以維持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) 產生在靜止圖像中可能不引人注意的壓縮假影(例如，場景中的密集樹葉內的假影可能不呈現為假影，因為眼並不確切地知道密集樹葉應如何呈現)。但是，一旦場景在運動中，假影 就可能突出，因為眼偵測到自幀至幀而改變的假影，儘管假影在場景的區域(在該區域中， 假影在靜止圖像中可能不引人注意)中。此導致幀序列中的「背景噪音」的感知，該「背景 噪音」的外觀與邊緣模擬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. 1Mbps)，但 單個I幀可能花費若干個幀時間來傳輸。舉例而言，使用先前技術，2. 2Mbps網絡連接(例 如，DSL或電纜數據機，其具有來自圖3a的最大可用數據速率302的2. 2Mbps峰值) 通常將足夠使視頻以1. 1Mbps流動，每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. 1Mbps)。該方法消除了由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,或高帶寬100Mbps私用連接)上，網絡將能 夠容忍諸如I幀峰值633或P幀峰值636的大峰值，但原則上，可維持低延時。但是，所述 網絡經常在許多用戶當中共用(例如，在辦公室環境中)，且該「有峰」數據將影響LAN的 性能，尤其在網絡通信經路由至私用共用連接(例如，從遠程數據中心到辦公室)的情況 下。首先，記住此實例是60fps下640X480像素的相對低解析度的視頻流的實例。60fps 下的1920X1080的HDTV流容易由現代計算機及顯示器來處理，且60fps下的2560X1440解析度顯示器日益可用(例如，Apple公司的30"顯示器)。使用H. 264壓縮，60fps下的 1920X1080的高動作視頻序列可能需要4. 5Mbps以獲得合理質量水平。若假定I幀峰值為 標定數據速率的10倍，則其將產生45Mbps峰值，以及較小但仍相當大的P幀峰值。若若干 個用戶正在同一 100Mbps網絡(例如，辦公室與數據中心之間的私用網絡連接)上接收視 頻流，則容易看見來自若干用戶的視頻流的峰值可如何碰巧對準，從而淹沒網絡的帶寬，且 可能淹沒網絡上支持用戶的交換器的底板的帶寬。即使在超高速乙太網的狀況下，若足夠 的用戶具有同時對準的足夠峰值，則其可淹沒網絡或網絡交換器。此外，一旦2560X1440 解析度視頻變得更常見，平均視頻流數據速率就可能為9. 5Mbps,從而或許產生95Mbps峰 值數據速率。不用說，數據中心與辦公室之間的100Mbps連接(其在現今為格外快的連接) 將完全被來自單一用戶的峰值通信擊潰。因此，即使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圖像塊10且剩餘的1-15圖像塊經編碼為P圖像塊(P1至P15) 以產生R幀711。在下一個未經壓縮的視頻幀702中，未經壓縮的幀701的圖像塊1經編碼 為I圖像塊II且剩餘的圖像塊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的10及P0來解壓縮並再現視頻圖像的圖像塊0。類似地， 使用來自R幀711至770的II及P1來重建圖像塊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圖像塊)主要編碼自先前幀至下一個幀的差
32異。因此，若先前幀與下一個幀相當類似，則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. 1Mbps下的具有I幀隨後跟著 59個P幀的流的數據速率高約16%。再一次，用於視頻壓縮的所述兩種方法之間的相對結 果將視視頻序列而改變，但通常，我們憑經驗發現，對於給定質量水平，使用R幀比使用I/P 幀序列需要多約20%的比特。但是，當然，R幀急劇地減少峰值，這使視頻序列在遠小於1/ 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圖像塊一起進行排序。此外，儘管在圖
337a-圖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圖像塊無關。在這種情形下(及在即使並非一切都改變，大量圖像也改變的其他情形下)，視頻壓縮器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，這是不 可接受的。在實踐中，即使對於來自快速改變的視頻遊戲的高動作視頻，超過峰值數據速率941的峰值也在小於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(例如，lOOMbs乙太網或802. llg無線網絡)上或私 用網絡(例如，數據中心與辦公室之間的100Mbps連接)上的辦公室環境中，可在無峰值情 況下傳輸高動作視頻流，以使得多個用戶(例如，以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幀實施中，若存在丟失/延遲的分組，則整個屏幕受影響，從而可能引起屏幕完全凍結一段時間周 期或顯示其他屏幕寬視覺假影。舉例而言，若丟失/延遲的分組引起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(用戶數據報協議)分組內而減少丟失分組的效應。舉例而言，在一個實施例中，只 要可能，即將圖像塊與分組邊界對準。圖10a說明可如何在不實施此特徵的情況下將圖像 塊封裝於一系列分組1001-1005內。具體言之，在圖10a中，圖像塊越過分組邊界且經無效 率地封裝以致單一分組的丟失導致多個幀的丟失。舉例而言，若分組1003或1004丟失，則 丟失三個圖像塊，導致視覺假影。相比之下，圖10b說明用於將圖像塊智能地封裝於分組內以減少分組丟失的效應 的圖像塊封裝邏輯1010。首先，圖像塊封裝邏輯1010將圖像塊與分組邊界對準。因此，圖 像塊T1、T3、T4、T7及T2分別與分組1001-1005的邊界對準。圖像塊封裝邏輯也試圖以可 能的更有效的方式將圖像塊組合於分組內，而不越過分組邊界。基於圖像塊中的每一者的 大小，將圖像塊T1與T6組合於一個分組1001中；將T3與T5組合於一個分組1002中；將 圖像塊T4與T8組合於一個分組1003中；將圖像塊T8添加至分組1004 ；且將圖像塊T2添 加至分組1005。因此，在此方案下，單個分組丟失將導致不多於2個圖像塊(而非如圖10a 中所說明的3個圖像塊)的丟失。圖10b中所顯示的實施例的一個額外益處在於圖像塊是以其在圖像內被顯示的 不同次序進行傳輸。若鄰近分組由於幹擾傳輸的同一事件(其將影響屏幕上彼此不接近的 區域)而丟失，則此方式在顯示器上產生較不引人注意的假影。一個實施例使用前向糾錯(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碼越小。因此，如圖11a中所說明，在一個實施例中，由於I圖像塊在視頻流中的重要性，僅 I圖像塊具備FEC碼。因此，FEC 1101含有用於I圖像塊1100的糾錯碼且FEC1104含有用 於I圖像塊1103的糾錯碼。在此實施例中，對於P圖像塊不產生FEC。在圖lib中所說明的一個實施例中，對於在丟失時最可能引起視覺假影的P圖像 塊也產生FEC碼。在此實施例中，FEC 1105提供用於前3個P圖像塊但不用於跟隨的P圖 像塊的糾錯碼。在另一實施例中，對於數據大小最小的P圖像塊產生FEC碼(其將傾向於 自選在I圖像塊的後最早出現的P圖像塊，其對於保護最為關鍵)。在另一實施例中，並非將FEC碼連同圖像塊一起發送，而是將圖像塊傳輸兩次，每 次在不同分組中傳輸。若一分組丟失/延遲，則使用另一分組。在圖11c中所顯示的一個實施例中，產生分別用於與視頻同時自主機服務傳輸的 音頻分組1110及1112的FEC碼1111及1113。維持視頻流中的音頻的完整性特別重要，因 為失真的音頻(例如，滴答聲或嘶嘶聲)將導致特別不合需要的用戶體驗。FEC碼幫助確保 音頻內容在客戶端計算機415處無失真地再現。在另一實施例中，並非將FEC碼連同音頻數據一起發送，而是將音頻數據傳輸兩 次，每次在不同分組中傳輸。若一個分組丟失/延遲，則使用另一分組。另外，在圖lid中所說明的一個實施例中，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，當分組丟失/延遲，從而導致圖像塊數據的丟
39失時，或若可能由於特別糟的分組丟失而使得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 計算機系統，每個核心作為獨立過程實施開源x264H. 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 ofOosterhout 的Sendero視頻成像IP開發板)來捕獲640 X 480、800 X 600或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卡的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路由至給定目的地的故障。因此，儘管通用網際網路通常以相當可靠且最佳的路由及延時來提供從一點到另一點的連接，該相當可靠且最佳的路線及延時很大程度上是 通過距離來確定(尤其是在導致路由至用戶的本地區域的外部的長距離連接的情況下)， 但該可靠性及延時得不到任何保證且常常不可自用戶的場所至通用網際網路上的給定目的 地而達成。在一個實施例中，當用戶客戶端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中的每一者彼此共用用戶數據，以便在一個 伺服器中心具有電力故障時，其可將在進行中的遊戲及應用程式暫停，且接著將遊戲或應用程式狀態數據自每個伺服器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的子網絡的網絡連接及至附接 至其他設備的子網絡的另一網絡連接。
43
應用程式/遊戲伺服器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)為在運動中的現場直播的視頻 窗，其顯示來自一個用戶的遊戲的一個視頻。縮略圖中所顯示的視圖可為用戶正看的同一視圖，或其可為延遲的視圖(例如，若用戶正玩搏鬥遊戲，則用戶可能不希望其他用戶看見 其隱藏在哪裡且其可選擇將其遊戲播放的任何視圖延遲一時間周期(例如，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」)及遊戲標誌「極品飛車卡本峽谷」及橙色橫條在相對條件下指示在該
46特定時刻玩遊戲或觀看遊戲的人的數目(在此狀況下，許多，因此遊戲為「熱門」)。另外提 供「狀態」，指示存在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的硬 件配置及計算能力是已知的，所以可預先計算像素及頂點著色。因此，遊戲可幾乎即刻啟動，其將在理想環境中執行，且隨後的片段將幾乎即刻載 入。但是，除這些優點之外，用戶將能夠觀看他人玩遊戲(經由先前所描述的遊戲取 景器，及其他裝置)，且兩者均決定遊戲是否有趣，如果這樣，則自觀看他人來學習技巧。此外，用戶將能夠即刻地演示該遊戲，而不必等待大的下載和/或安裝，且用戶將能夠即刻玩 該遊戲(可能在較小費用的試用基礎上，或在較長期的基礎上)。此外，用戶將能夠通過足 夠低延時的無線連接而在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商用網際網路連接看見2560X 144060fps顯 示，紐約的房地產開發商可經由其筆記本計算機上的6Mbps DSL連接看見1280X72060fps 圖像，且投資者可經由其行動電話上的250Kbps蜂窩式數據連接看見320X 18060fps圖 像)。每一方將聽到其他方的語音(將通過應用程式/遊戲伺服器1521-1525中的許多 廣泛可用的會議呼叫套裝軟體中的任一者來處理會議呼叫)，且經由用戶輸入設備上的按 鈕的致動，用戶將能夠使用其本地相機使視頻出現。隨著會議進行，建築師將能夠通過極 具照片般逼真感的3D再現顯示當其使建築物旋轉且使其鄰接該區域中的另一建築物飛越 (fly-by)時建築物看起來像什麼，且所有方均將在各方的顯示設備的解析度下可見到相同 視頻。由任何方使用的本地設備中的任一者均能夠以該真實感處理3D動畫不是問題，更不 用說下載或甚至儲存再現紐約市的周圍建築物所需的巨大資料庫。自用戶中的每一者的觀 點看，儘管距離很遠，且儘管是全異本地設備，但其將簡單地在難以置信的真實感程度下具 有無縫體驗。此外，當一方希望其面部被看來較佳地傳達其情緒狀態時，其可如此進行。另 外，若房地產開發商或投資者希望控制建築程序且使用其自身的輸入設備(其為鍵盤、鼠 標、小鍵盤或觸控螢幕幕)，則其可如此，且其可以用無感知的延時來響應(假定其網絡連接 不具有不合理的延時)。舉例而言，在行動電話的狀況下，若行動電話連接至機場的WiFi網 絡，則其將具有非常低的延時。但若其使用美國現今可用的蜂窩式數據網絡，則其很可能將遭受引人注意的滯後。但是，對於會議的大多數目的(其中投資者正觀看建築師控制建築 物飛越或正談論視頻電話會議)，甚至蜂窩式延時也應是可接受的。最後，在合作性會議呼叫結束時，房地產開發商及投資者將進行其評論且從主機 服務停播，建築公司將能夠「回倒」已記錄在延遲緩衝器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 shot正玩遊 戲「龍騎士(Eragon)」且MrSnUggleS99離線等)。通過單擊菜單項(未圖示)，搭檔視頻 剪輯自顯示已記錄的或上傳的視頻切換至當前正玩主機服務210上的遊戲的搭檔在所述 時刻在其遊戲中正在進行的內容的現場直播的視頻。因此，其變成為搭檔分群的遊戲取景 器。若選擇搭檔的遊戲且用戶單擊該遊戲，則該遊戲將放大至全屏幕，且用戶將能夠觀看全 屏幕現場直播地播放的遊戲。再次，觀看搭檔的遊戲的用戶不擁有遊戲的複本，也不擁有用於玩該遊戲的本地
51計算/遊戲控制臺資源。遊戲觀看是有效瞬時的。如上文先前所描述，當用戶玩主機服務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中。因此，在 先前所給出的實例中，其中用戶突然將其人物轉向且向後看，可在人物完成旋轉之前載入其身後的所有人物的幾何形狀，且因此，對於用戶而言，將看來似乎其處於與現場直播的動 作一般真實的照片般逼真的世界中。如先前所論述，照片般逼真的計算機動畫中的最後的邊界中的一者是人臉，且由 於人眼對於不完全性的敏感性，來自照片般逼真的面部的最輕微錯誤可導致來自觀看者的 負面反應。圖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在線可用。且與電視 節目相關聯的網站常常具有額外特徵、博客及有時來自演員或創作人員的評論。另外，在許多電影或運動事件的情況下，通常有經常連同線性媒體一起發行(在 電影的狀況下)或(在運動的狀況下)可以被緊密地聯繫到真實世界事件(例如，玩家的
54交易)的視頻遊戲。主機服務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上(或潛在地在對網絡瀏覽器進行主機代管的應用程式/遊戲伺服器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 內的專用組件的損壞的問題的學校特別有吸引力。
這種配置解決了用於所述組織的許多問題(且許多這種優點也為進行通用計算 的家庭用戶共用)。舉例而言，操作成本(其最終必須以某種形式傳遞迴至用戶以便具有 可行的商業)可能低得多，因為(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所提供的是流動互動式視頻水平下的遞歸，
63因為可在應用程式需要視頻時將視頻無限地循環。這使得之前從未可用的多種應用可能性 成為可能。另一關鍵架構特徵在於視頻流是單向UDP流。這有效地實現流動互動式視頻的 任意程度的多播(相比之下，諸如TCP/IP流的雙向流將隨著用戶的數目增加而在來自來回 通信的網絡上產生越來越多的通信停滯)。多播是伺服器中心內的重要能力，因為其允許系 統對網際網路用戶(且實際上，世界的人口)的增長的需要作出響應以在一對多或甚至多對 多基礎上通信。再次，本文中所論述的說明流動互動式視頻遞歸與多播兩者的使用的實例 (諸如，圖16)僅為具有可能性的非常大的冰山的尖端。在一個實施例中，本文中所說明的各種功能模組及相關聯的步驟可由含有用於執 行所述步驟的固線式邏輯的特定硬體組件(諸如，特殊用途集成電路(「ASIC」))或由被編 程的計算機組件與定製硬體組件的任何組合來執行。在一個實施例中，可將所述模組實施於諸如Texas儀器的TMS320x架構(例如， TMS320C6000, TMS320C5000,...等)的可編程數位訊號處理器(「DSP」)上。可使用各種 不同的DSP，同時仍遵守所述基本原理。實施例可包括如上文所闡述的各種步驟。所述步驟可體現於引起通用或專用處理 器執行特定步驟的機器可執行指令中。已將與這些基本原理無關的各種元件(諸如，計算 機存儲器、硬碟機、輸入設備)從圖中省去以避免混淆相關方面。所公開的標的物的要素也可作為用於儲存機器可執行指令的機器可讀媒體來提 供。機器可讀媒體可包括(但不限於)快閃記憶體、光碟、CD-ROM、DVDROM、RAM、EPR0M、EEPR0M、磁 卡或光卡、傳播媒體或適合於儲存電子指令的其他類型的機器可讀媒體。舉例而言，本發明 可作為電腦程式來下載，該電腦程式可經由通信鏈路(例如，數據機或網絡連接)藉助 於體現在載波或其他傳播媒體中的數據信號而從遠程計算機(例如，伺服器)傳送到請求 計算機(例如，客戶端)。還應理解，所公開的標的物的要素也可作為電腦程式產品來提供，該計算機程 序產品可包括在上面儲存有指令的機器可讀媒體，所述指令可用於程序化計算機(例如， 處理器或其他電子設備)以執行一序列操作。或者，所述操作可通過硬體與軟體的組合來 執行。機器可讀媒體可包括(但不限於)軟盤、光碟、CD-ROM，及磁光碟、ROM、RAM、EPROM、 EEPR0M、磁卡或光卡、傳播媒體或適合於儲存電子指令的其他類型的媒體/機器可讀媒體。 舉例而言，所公開的標的物的要素可作為電腦程式產品來下載，其中程序可經由通信鏈 路(例如，數據機或網絡連接)藉助於體現於載波或其他傳播媒體中的數據信號而自遠程 計算機或電子設備傳送至請求過程。另外，儘管已結合特定實施例描述所公開的標的物，但眾多修改及變更將適當地 處於本公開的範疇內。因此，說明書及圖式應視為說明性的而非限制性的意義。
6權利要求
一種方法，該方法包括將網際網路線性視頻與交互式視頻內容一起組合成單個視頻流；對所述單個視頻流進行壓縮；將壓縮後的單個視頻流以流動互動式視頻的形式通過網際網路發送至用戶客戶端設備。
全文摘要
一種方法，該方法包括將網際網路線性視頻與交互式視頻內容一起組合成單個視頻流，該單個視頻流被壓縮，並被以流動互動式視頻的形式通過網際網路發送至用戶客戶端設備。
文檔編號H04N7/173GK101897183SQ200880119271
公開日2010年11月24日 申請日期2008年12月4日 優先權日2007年12月5日
發明者R·范德拉安, S·G·珀爾曼 申請人:生命力有限公司