TWI459215B - 用於將程式碼及資料儲存於應用程式主機代管中心內之系統及方法 - Google Patents

用於將程式碼及資料儲存於應用程式主機代管中心內之系統及方法 Download PDF

Info

Publication number
TWI459215B
TWI459215B TW097147248A TW97147248A TWI459215B TW I459215 B TWI459215 B TW I459215B TW 097147248 A TW097147248 A TW 097147248A TW 97147248 A TW97147248 A TW 97147248A TW I459215 B TWI459215 B TW I459215B
Authority
TW
Taiwan
Prior art keywords
video
game
frame
user
server
Prior art date
Application number
TW097147248A
Other languages
English (en)
Other versions
TW200937220A (en
Inventor
Stephen G Perlman
Der Laan Roger Van
Original Assignee
Ol2 Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ol2 Inc filed Critical Ol2 Inc
Publication of TW200937220A publication Critical patent/TW200937220A/zh
Application granted granted Critical
Publication of TWI459215B publication Critical patent/TWI459215B/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8545—Content authoring for generating interactive applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/231—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
    • H04N21/23106—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion involving caching operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2402—Monitoring of the downstream path of the transmission network, e.g. bandwidth available
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
    • H04N21/4781—Games

Description

用於將程式碼及資料儲存於應用程式主機代管中心內之系統及方法
本揭示案大體而言係關於改良使用者操縱及存取音訊及視訊媒體之能力的資料處理系統之領域。
本申請案為2002年12月10日申請之名為「用於無線視訊遊戲之裝置及方法(Apparatus and Method for Wireless Video Gaming)」的第10/315,460號部分接續(CIP)申請案，該案已讓與給本CIP申請案之受讓人。
自從托馬斯‧愛迪生(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數位音樂系統之音訊器件使音訊直接自網際網路串流。同樣地，類似SlingboxTM 娛樂播放機之器件記錄視訊且使其經由家庭網路串流或經由網際網路串流而出，其中可在PC上於遠端觀看該視訊。且網際網路協定電視(IPTV)服務經由數位用戶線(DSL)或其他家庭網際網路連接而提供類似電纜TV之服務。近來亦存在將多個媒體功能整合於單一器件(諸如，Moxi媒體中心及執行Windows XP媒體中心版本之PC)中的努力。儘管此等器件中之每一者對其執行之功能提供一點便利，但每一者缺乏對大多數媒體之普遍且簡單的存取。另外，常常由於昂貴處理及/或本端儲存之需要而使得該等器件經常花費數百美元來製造。另外，此等現代消費者電子器件通常消耗大量電力，甚至當閒置時亦消耗大量電力，此意謂其隨著時間而昂貴且浪費能源。舉例而言，若消費者忘記將一器件切斷或將其切換至不同視訊輸入端，則該器件可能繼續操作。此外，因為該等器件當中沒有一者為完全解決方案，所以必須將其與家庭中之其他器件堆疊整合，此仍對使用者留下鼠窩式線及許多遠端控制。
此外，當許多較新的以網際網路為基礎之器件適當地工作時，其通常提供更一般形式(與其原本可能可用之形式相比)之媒體。舉例而言，使視訊經由網際網路串流之器件常常僅使視訊材料串流，而不能使常常伴隨DVD互動式「額外計費項目」串流，如視訊之「製作」、遊戲或導演評論。此係由於以下事實：互動式材料經常係以意欲用於在本端處理互動性之特定器件的特定格式而製作。舉例而言，DVD、HD-DVD及藍光光碟中之每一者具有其自身的特定互動格式。任何家庭媒體器件或本端電腦(其可能經開發以支援所有風行格式)將需要一定程度的尖端性(sophistication)及靈活性，其將可能對於消費者操作而言過於昂貴及複雜。
使該問題加重，若稍後在將來引入新格式，則本端器件可能不具有支援新格式之硬體能力，此將意謂消費者將必須購買升級的本端媒體器件。舉例而言，若在稍後之日期引入較高解析度之視訊或立體視訊(例如，每一隻眼一視訊流)，則本端器件可能不具有解碼該視訊之計算能力，或其可能不具有用於以新格式輸出該視訊的硬體(例如，假定藉由與遮光眼鏡(shuttered glassess)同步之120fps視訊來達成立體視覺，其中將60fps遞送至每一隻眼，若消費者之視訊硬體僅可支援60fps視訊，則此選項在缺乏升級的硬體購買之情況下將不可用)。
當談及尖端的互動式媒體(尤其是視訊遊戲)時，媒體器件廢棄及複雜度之問題為一嚴重問題。
現代視訊遊戲應用基本上劃分成四個主要非可攜式硬體平台：Sony PlayStation1、2及3(PS1、PS2，及PS3)；Microsoft Xbox及Xbox 360；及Nintendo Gamecube及WiiTM ；以及以PC為基礎之遊戲。此等平台中之每一者不同於其他者，使得經編寫以在一平台上執行之遊戲通常不會在另一平台上執行。亦可能存在一代器件與下一代器件之相容性問題。即使大多數軟體遊戲開發者建立獨立於特定平台而設計之軟體遊戲，為了在特定平台上執行特定遊戲，亦需要專有軟體層(其經常被稱為「遊戲開發引擎」)來調適遊戲以在特定平台上使用。每一平台以「控制台」(亦即，附接至TV或監視器/揚聲器之獨立盒子)之形式出售給消費者或其本身為一PC。通常，視訊遊戲係在諸如藍光DVD、DVD-ROM或CD-ROM之光學媒體上出售，該光學媒體含有體現為尖端的即時軟體應用程式之視訊遊戲。隨著家庭寬頻帶速度增加，視訊遊戲正日益變得可用於下載。
由於高階視訊遊戲之即時性及高計算要求而使得達成與視訊遊戲軟體之平台相容性的特殊性要求極端苛刻。舉例而言，吾人可能期望自一代視訊遊戲至下一代視訊遊戲(例如，自XBox至XBox 360，或自Playstation 2(「PS2」)至Playstation 3(「PS3」))的完全遊戲相容性，正如存在自一PC至具有較快處理單元或核心之另一PC的生產力應用程式(例如，Microsoft Word)之普遍相容性。然而，對於視訊遊戲並非為此狀況。因為當發行一代視訊遊戲時，視訊遊戲製造商通常尋求對於給定價格點之最高可能效能，所以經常對系統進行動態架構改變，以使得經編寫以用於前代系統之許多遊戲在稍後一代系統上不工作。舉例而言，XBox係基於x86系列處理器，而XBox 360係基於PowerPC系列。
可利用技術來模擬先前架構，但假定視訊遊戲為即時應用程式，則在模擬中達成完全相同之行為常常不切實際。此係對消費者、視訊遊戲控制台製造商及視訊遊戲軟體出版商之損失。對於消費者而言，其意謂保持將舊的一代視訊遊戲控制台與新的一代視訊遊戲控制台兩者接通至TV以便能夠玩所有遊戲的必要性。對於控制台製造商而言，其意謂與新控制台之模擬及較緩慢採用相關聯的成本。且對於出版商而言，其意謂可能必須發行新遊戲之多個版本以便涵蓋所有潛在的消費者-不僅發行用於視訊遊戲之每一商標(例如，XBox、Playstation)的版本，而且常常發行用於給定商標之每一版本(例如，PS2及PS3)的版本。舉例而言，開發電子藝術「瘋狂橄欖球08」之單獨版本以用於XBox、XBox 360、PS2、PS3、Gamecube、Wii及PC平台以及其他平台。
可攜式器件(諸如，蜂巢式電話及可攜式媒體播放機)亦對遊戲開發商提出挑戰。日益增加地，該等器件連接至無線資料網路且能夠下載視訊遊戲。但是，市場中存在具有多種不同顯示解析度及計算能力的多種蜂巢式電話及媒體器件。又，因為該等器件通常具有電力消耗、成本及重量約束，所以其通常缺乏類似圖形處理單元(「GPU」)之高階圖形加速硬體(諸如，由CA之Santa Clara之NVIDIA製造的器件)。因此，遊戲軟體開發商通常開發同時用於許多不同類型之可攜式器件的給定遊戲標題。使用者可發現：給定遊戲標題不可用於其特定蜂巢式電話或可攜式媒體播放機。
在家庭遊戲控制台之狀況下，硬體平台製造商通常向軟體遊戲開發商索要用於在其平台上發布遊戲之能力的版稅。蜂巢式電話無線通信公司通常亦向遊戲出版商索要用於將遊戲下載至蜂巢式電話中之版稅。在PC遊戲之狀況下，不存在用於發布遊戲所支付之版稅，但由於用於支援多種PC組態及可能引起的安裝問題的較高消費者服務負擔而使得遊戲開發商通常面臨高成本。又，PC通常較少對遊戲軟體之盜版提出障礙，因為其可由技術上博學之使用者容易地重新程式化且遊戲可更容易地被盜版且更容易地被分配(例如，經由網際網路)。因此，對於軟體遊戲開發商而言，在遊戲控制台、蜂巢式電話及PC上發現存在成本及不利之處。
對於控制台及PC軟體之遊戲出版商而言，成本不止於此。為了經由零售通道分配遊戲，出版商向零售商索要低於出售價格之批發價格以使零售商具有利潤率。出版商通常亦必須支付製造及分配保存遊戲之實體媒體的成本。零售商經常亦向出版商索要「價格保護費」以涵蓋可能的意外費用(諸如，遊戲售不出，或遊戲之價格降低，或零售商必須退還部分或所有批發價格及/或自購買者收回遊戲)。另外，零售商通常亦向出版商索要用於幫助在廣告傳單中銷售遊戲之費用。此外，零售商日益增加地自已完成遊戲之使用者購買回遊戲，且接著將該等遊戲以已使用之遊戲出售，通常不與遊戲出版商分享已使用遊戲之收入。以下事實添加施加於遊戲出版商之成本負擔：遊戲常常被經由網際網路盜版及分配以供使用者下載及進行免費複製。
隨著網際網路寬頻帶速度增加且寬頻帶連接性在美國及全世界變得更廣泛(特定言之，至家庭及至租賃連接網際網路之PC的「網咖」)，遊戲日益增加地被經由下載而分配至PC或控制台。又，寬頻帶連接日益增加地用於玩多人及大型多人線上遊戲(該兩者在本揭示案中藉由首字母縮寫詞「MMOG」來指稱)。此等改變減輕了與零售分配相關聯之一些成本及問題。下載線上遊戲解決了遊戲出版商之一些不利之處，因為分配成本通常較小且存在較少或不存在未出售媒體之成本。但已下載的遊戲仍經受盜版，且由於其大小(大小常常為許多個十億位元組)而使得其可能花費非常長之時間來下載。另外，多個遊戲可填滿小磁碟機，諸如連同可攜式電腦一起或連同視訊遊戲控制台一起出售之彼等磁碟機。然而，就遊戲或MMOG需要線上連接以使得遊戲可玩之程度而言，盜版問題得以減輕，因為通常需要使用者具有有效的使用者帳戶。不同於可藉由相機拍攝顯示螢幕之視訊或藉由麥克風記錄來自揚聲器之音訊來複製的線性媒體(例如，視訊及音樂)，每一視訊遊戲體驗係唯一的，且不可使用簡單視訊/音訊記錄來複製。因此，甚至在未強力執行版權法且盜版猖獗的區域中，亦可保護MMOG免於被盜版且因此可支援商業。舉例而言，已成功地部署Vivendi SA之「魔獸世界」MMOG，而在全世界未遭受盜版。且許多線上或MMOG遊戲(諸如，Linden Lab之「第二人生」MMOG)經由建置於遊戲中之經濟模型而產生遊戲運營商的收入，其中資產可使用線上工具而帶來、出售且甚至建立。因此，可使用除習知遊戲軟體購買或訂用之外的機制來為線上遊戲之使用付費。
儘管由於線上或MMOG之性質而使得常常可減輕盜版，但線上遊戲運營商仍面臨其餘挑戰。許多遊戲需要大量的本端(亦即，家庭內)處理資源以供線上或MMOG適當地工作。若使用者具有低效能之本端電腦(例如，不具有GPU之電腦，諸如低端膝上型電腦)，則其可能不能夠玩該遊戲。另外，隨著遊戲控制台老化，其遠落後於目前技術狀態且可能不能夠處理更高階之遊戲。即使假定使用者之本端PC能夠處理遊戲之計算要求，常常亦存在安裝複雜度。可能存在驅動器不相容性(例如，若下載新遊戲，則可能安裝新版本的圖形驅動器，其致使依賴於舊版本圖形驅動器之先前已安裝之遊戲不可操作)。隨著下載更多遊戲，控制台可能用完本端磁碟空間。當發現缺陷並修復時或若對遊戲進行了修改(例如，若遊戲開發商發現遊戲之級別太難玩或太容易玩)，複雜遊戲通常隨著時間推移而自遊戲開發商接收下載之修補程式(patch)。此等修補程式需要新的下載。但有時並非所有使用者完成所有修補程式之下載。在其他時候，下載之修補程式引入其他相容性或磁碟空間消耗問題。
又，在遊戲播放期間，可能需要大資料下載以將圖形或行為資訊提供至本端PC或控制台。舉例而言，若使用者進入MMOG中之一房間中，且遭遇由圖形資料組成或具有在使用者之本端機器上不可用之行為的場景或人物，則必須下載彼場景或人物之資料。若網際網路連接不夠快，則此可導致玩遊戲期間的實質延遲。此外，若所遭遇之場景或人物需要超過本端PC或控制台之儲存空間或計算能力的儲存空間或計算能力，則其可產生一情形：其中使用者不可在遊戲中繼續，或必須以品質降低之圖形繼續。因此，線上或MMOG遊戲常常限制其儲存及/或計算複雜度要求。另外，其常常限制遊戲期間之資料傳送的量。線上或MMOG遊戲亦可使可玩遊戲之使用者之市場變窄。
此外，技術上博學之使用者日益增加地反向工程設計遊戲之本端複本且修改遊戲以使得其可作弊。作弊可能與進行比用人力可能的速度快的重複按鈕按壓(例如，以便非常快速地射擊)一般簡單。在支援遊戲中資產交易之遊戲中，作弊可達到導致欺騙性交易涉及具有實際經濟價值之資產的欺詐程度。當線上或MMOG經濟模型係基於該等資產交易時，此可導致對遊戲運營商之實質有害後果。
開發新遊戲之成本隨著PC及控制台能夠製作愈加尖端的遊戲(例如，具有更逼真之圖形(諸如，即時光線追蹤)，及更逼真之行為(諸如，即時物理學仿真))而增長。在視訊遊戲業之早期，視訊遊戲開發係與應用程式軟體開發非常類似之過程；亦即，大多數開發成本係在軟體之開發中(與圖形、音訊及行為要素或「資產」之開發相對比)，諸如可經開發以用於具有廣泛特殊效果之電影的彼等軟體開發。現今，許多尖端的視訊遊戲開發努力比軟體開發更類似於富有特殊效果之電影開發。舉例而言，許多視訊遊戲提供3-D世界之仿真，且產生日益真實(亦即，看似與攝影拍攝的活人動作影像一般逼真的電腦圖形)的人物、道具及環境。照片般逼真的遊戲開發之最具挑戰方面中之一者為建立不能區別於活人動作人面的電腦產生之人面。面部俘獲技術(諸如，由CA之San Francisco之Mova開發的ContourTM 真實性俘獲系統)俘獲表演者之面部之精確幾何形狀並在表演者處於運動中時以高解析度追蹤表演者之面部之精確幾何形狀。此技術允許在PC或遊戲控制台上再現3D面部，該3D面部實際上不能區別於所俘獲的活人動作面部。精確地俘獲及再現「照片般逼真的」人面在若干方面有用。首先，高度可辨識之名人或運動員常常用於視訊遊戲中(常常以高成本雇用)，且不完美性可能對於使用者而言顯而易見，從而使檢視體驗分心或令人不愉快。經常地，需要高度細節來達成高度照片般逼真感-潛在地需要再現大量多邊形及高解析度紋理(在多邊形及/或紋理在圖框接圖框基礎上隨著面部移動而改變之情況下)。
當具有詳細紋理之高多邊形計數場景快速改變時，支援遊戲之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、Sony Playstation 3及Nintendo Wii預定為在大約相同的一般時間框引入。但在該等引入之前的數年中，遊戲開發商實質上必須「壓注」哪些控制台平台將比其他者更成功，且相應地投入其開發資源。電影製作公司亦必須在電影發行之前很長時間基於其估計可能成功之電影而分攤其有限的製作資源。給定視訊遊戲所需之投資之增長程度，則遊戲製作愈加變得類似電影製作，且遊戲製作公司常規上基於其對特定視訊遊戲之將來成功的估計而投入其製作資源。但是，不同於電影公司，此壓注並非僅基於製作本身之成功；實情為，其依據於遊戲意欲在其上執行之遊戲控制台的成功。同時在多個控制台上發行遊戲可減輕風險，但此額外努力增加成本，且經常延遲遊戲之實際發行。
PC上之應用程式軟體及使用者環境正變得更為計算上密集、動態及互動，不僅使其在視覺上更吸引使用者，而且使其更有用及直觀。舉例而言，新Windows VistaTM 作業系統與Macintosh作業系統之相繼版本兩者併有視覺動畫效應。高階圖形工具(諸如，來自Autodesk公司之MayaTM )提供非常尖端之3D再現及動畫製作能力(其推動了目前技術狀態的CPU及GPU之限制)。然而，此等新工具之計算要求對於該等產品之使用者及軟體開發商而言產生許多實際問題。
因為作業系統(OS)之視覺顯示必須在多種電腦(包括不再出售但仍可隨著新OS而升級之前代電腦)上工作，OS圖形要求在很大程度上受OS意欲用於之電腦(其通常包括不包括GPU之電腦)的最少共同點限制。此嚴重地限制OS之圖形能力。此外，電池供電之可攜式電腦(例如，膝上型電腦)限制視覺顯示能力，因為CPU或GPU中之高計算活動通常導致較高電力消耗及較短電池壽命。可攜式電腦通常包括在不利用處理器時自動地減低處理器活動性以降低電力消耗的軟體。在一些電腦型號中，使用者可手動地減低處理器活動性。舉例而言，Sony之VGN-SZ280P膝上型電腦含有在一側上標記為「Stamina」(用於低效能，更長電池壽命)且另一側上標記為「Speed」(用於高效能，較短電池壽命)之交換器。在可攜式電腦上執行之OS必須能夠即使在電腦以其峰值效能能力之一分率執行的情況下亦可用地起作用。因此，OS圖形效能常常保持為遠低於目前技術狀態的可用計算能力。
經常出售高端的計算上密集之應用程式(如Maya)，期望該等應用程式將用於高效能PC上。此通常產生高得多的效能，及更昂貴且可攜性較差、最少共同點之要求。因此，該等應用程式具有比通用OS(或通用生產力應用程式，類似Microsoft Office)有限得多的目標受眾且通常以比通用OS軟體或通用應用程式軟體低得多的量出售。潛在的受眾進一步受限制，因為預期的使用者時常難以提前試用該等計算上密集之應用程式。舉例而言，假設學生希望瞭解如何使用Maya或已經知道該等應用程式之潛在購買者在購買中希望在進行投資之前試用Maya(此可能涉及亦購買能夠執行Maya之高端電腦)。當學生或潛在購買者可下載Maya之演示版本或得到Maya演示版本之實體媒體複本時，若其缺乏能夠執行Maya至其全部潛能(例如，處理複雜3D場景)之電腦，則其將不能夠進行產品之全方位評估。此實質上限制該等高端應用程式之受眾。其亦使出售價格變高，因為開發成本通常經由比通用應用程式之購買次數小得多之購買次數而清償。
高價應用程式亦對使用應用程式軟體之盜版複本之個體及商業產生更多刺激。因此，高端應用程式軟體遭受猖獗盜版，儘管該軟體之出版商進行了大量努力來藉由各種技術減輕該盜版。但是，甚至當使用盜版的高端應用程式時，使用者亦不可能排除投資昂貴的目前技術狀態的PC來執行盜版複本之需要。因此，儘管使用者可以軟體應用程式之實際零售價格之一分率獲得軟體應用程式之使用，但盜版軟體之使用者仍需要購買或獲得昂貴的PC，以便完全利用該應用程式。
此對於高效能盜版視訊遊戲之使用者同樣成立。儘管盜版者可以遊戲之實際價格之一分率得到遊戲，但其仍需要購買適當地玩遊戲所需的昂貴計算硬體(例如，GPU-增強型PC，或類似XBox 360之高端視訊遊戲控制台)。假定視訊遊戲通常為消費者之娛樂，則用於高端視訊遊戲系統之額外成本可為過於昂貴的。此情形在當前工人之平均年收入相當低(相對於美國之當前工人平均年收入)的國家(例如，中國)中更糟。因此，小得多的百分比之人口擁有高端視訊遊戲系統或高端PC。在該等國家中，使用者可支付費用以使用連接至網際網路之電腦的「網咖」相當普遍。經常地，該等網咖具有不具有高效能特徵(諸如，原本可使玩家能夠玩計算上密集之視訊遊戲的GPU)的較舊型號或低端PC。此為在低端PC上執行之遊戲成功的關鍵因素(諸如，Vivendi之「魔獸世界」，其在中國高度成功，且通常係在中國的網咖中玩)。相比之下，計算上密集之遊戲(如「第二人生」)更不可能在安裝於中國網咖中之PC上玩。該等遊戲實際上達不到僅能夠存取網咖中之低效能PC的使用者。
對於考慮購買視訊遊戲且首先願意藉由經由網際網路將演示下載至其家庭而試用遊戲之示範版本的使用者亦存在障礙。視訊遊戲演示常常為遊戲之全能版本，其中一些特徵停用，或對遊戲播放之量施加限制。此可能涉及在可將遊戲安裝於PC或控制台上且在PC或控制台上執行之前下載數十億位元組之資料的長過程(可能幾個小時)。在PC之狀況下，其亦可能涉及算出遊戲需要哪些特殊驅動器(例如，DirectX或OpenGL驅動器)，下載正確的版本，安裝正確的版本，及接著判定PC是否能夠播放該遊戲。此後者步驟可能涉及判定PC是否具有足夠的處理(CPU及GPU)能力、足夠的RAM及相容的OS(例如，一些遊戲在Windows XP上執行而不在Vista上執行)。因此，在試圖執行視訊遊戲演示之長過程之後，使用者可能發現視訊遊戲演示不可能玩(給定使用者之PC組態)。更糟地，一旦使用者已下載新驅動器以便嘗試該演示，此等驅動器版本就可能與使用者在PC上習慣使用的其他遊戲或應用程式不相容，因此，演示之安裝可致使先前可操作的遊戲或應用程式不能操作。此等障礙不僅使使用者受挫，而且其對視訊遊戲軟體出版商及視訊遊戲開發商銷售其遊戲產生障礙。
導致不具經濟效益之另一問題與以下事實有關：給定PC或遊戲控制台通常經設計以適應對應用程式及/或遊戲的特定程度之效能要求。舉例而言，一些PC具有或多或少之RAM、較緩慢或較快之CPU及較緩慢或較快之GPU(若其具有GPU)。一些遊戲或應用程式利用給定PC或控制台之全計算能力，而一些遊戲或應用程式卻不利用給定PC或控制台之全計算能力。若使用者之遊戲或應用程式之選擇未達到本端PC或控制台之峰值效能能力，則使用者可能由於未利用之特徵而在PC或控制台上浪費了財力。在控制台之狀況下，控制台製造商可能支付地比資助控制台成本所要的多。
存在於視訊遊戲之銷售及享受中的另一問題涉及在使用者實施購買遊戲之前允許使用者觀看他人玩遊戲。存在用於記錄視訊遊戲以在稍後時間重放的若干先前技術方法。舉例而言，美國專利第5,558,339號教示了在「遊戲播放」期間將遊戲狀態資訊(包括遊戲控制器動作)記錄於視訊遊戲用戶端電腦(由同一或不同使用者擁有)中。此狀態資訊可在稍後時間使用以在視訊遊戲用戶端電腦(例如，PC或控制台)上重放一些或所有遊戲動作。此方法之顯著缺點在於：對於檢視已記錄之遊戲的使用者，使用者必須具有能夠播放該遊戲之視訊遊戲用戶端電腦且必須具有在彼電腦上執行之視訊遊戲應用程式，以使得當重放已記錄之遊戲狀態時遊戲播放係等同的。除此之外，視訊遊戲應用程式必須係以在已記錄之遊戲與經回放之遊戲之間不存在可能的執行差異的此種方式編寫。
舉例而言，遊戲圖形大體係在圖框接圖框基礎上計算。對於許多遊戲，取決於場景是否特別複雜或是否存在減緩執行之其他延遲(例如，在PC上，另一過程可能正在執行，以致自遊戲應用程式奪走CPU循環)，遊戲邏輯有時可能花費比一圖框時間短或比一圖框時間長之時間來計算為下一個圖框而顯示之圖形。在此種遊戲中，以比一圖框時間稍少之時間(例如，少幾個CPU時脈循環)計算的「臨限值」圖框最終可出現。當使用完全相同之遊戲狀態資訊再次計算彼同一場景時，可能容易花費比一圖框時間多幾個CPU時脈循環之時間(例如，若內部CPU匯流排稍微與外部DRAM匯流排不同相，且即使不存在來自自遊戲處理奪走數毫秒CPU時間之另一過程的大延遲，其亦引入幾個CPU循環時間之延遲)。因此，當回放遊戲時，圖框變成以兩個圖框時間計算而非以單一圖框時間計算。一些行為係基於遊戲計算新圖框之頻率(例如，當遊戲取樣來自遊戲控制器之輸入時)。當播放遊戲時，用於不同行為的時間參考中之此偏差不會影響遊戲播放，但其可導致所回放之遊戲產生不同結果。舉例而言，若籃球之軌道係以穩定的60fps速率來計算，但遊戲控制器輸入係基於經計算之圖框之速率來取樣，則當記錄遊戲時，經計算之圖框之速率可能為53fps，而當重放遊戲時，經計算之圖框之速率可能為52fps，此可使得籃球是否被阻止進入籃中存在差異，從而導致不同結果。因此，使用遊戲狀態記錄視訊遊戲需要非常謹慎之遊戲軟體設計，以確保使用同一遊戲狀態資訊重放產生完全相同之結果。
用於記錄視訊遊戲之另一先前技術方法係僅記錄PC或視訊遊戲系統之視訊輸出(例如，至VCR、DVD記錄器，或至PC上之視訊俘獲板)。接著可將視訊回倒及重放，或替代地，將已記錄之視訊上載至網際網路(通常在將視訊壓縮之後)。此方法之不利之處在於：當回放3D遊戲序列時，使用者限於僅自檢視點(序列被自其記錄)來檢視序列。換言之，使用者不可改變場景之檢視點。
另外，當經由網際網路而使在家庭PC或遊戲控制台上播放的已記錄之遊戲序列的經壓縮之視訊為其他使用者可用時，即使視訊係即時壓縮，亦不可能即時地將經壓縮之視訊上載至網際網路。其原因係因為世界上連接至網際網路之許多家庭具有高度不對稱之寬頻帶連接(例如，DSL及電纜數據機通常具有比上傳頻寬高得多的下傳頻寬)。經壓縮之高解析度視訊序列常常具有比網路之上傳頻寬容量高的頻寬，使得其不可能即時上載。因此，在播放遊戲序列之後(可能幾分鐘或甚至幾小時)，在網際網路上之另一使用者能夠檢視該遊戲之前，將存在顯著延遲。儘管此延遲在特定情形下(例如，觀看在先前時間出現的遊戲玩家之成果)可容忍，但其消除了觀看遊戲現場直播(例如，由優勝玩家玩的籃球錦標賽)之能力或現場直播地播放遊戲時的「即刻重放」能力。
另一先前技術方法允許具有電視接收器之檢視者觀看視訊遊戲現場直播，但僅在電視製作人員之控制下。美國與其他國家中的一些電視頻道提供視訊遊戲檢視頻道，其中電視觀眾能夠在視訊遊戲頻道上觀看特定視訊遊戲使用者(例如，參加錦標賽之頂級玩家)。此藉由將視訊遊戲系統(PC及/或控制台)之視訊輸出饋送至用於電視頻道之視訊分配及處理設備中來完成。此正如電視頻道廣播現場直播之籃球比賽時的情況，其中若干個相機自籃球場周圍之不同角度提供現場直播之饋送。電視頻道接著能夠利用其視訊/音訊處理及效應設備來操縱來自各種視訊遊戲系統之輸出。舉例而言，電視頻道可在來自視訊遊戲的視訊之上上覆指示不同玩家之狀態的文字(正如其可在現場直播之籃球比賽期間上覆文字)，且電視頻道可加錄來自評論員(其可論述在比賽期間出現之動作)之音訊。另外，可將視訊遊戲輸出與記錄遊戲之實際玩家之視訊的相機(例如，展示玩家對遊戲之情緒反應)組合。
此方法之一問題在於：必須即時地使該等現場直播之視訊饋送為電視頻道之視訊分配及處理設備可用，以便使其具有現場直播之廣播的刺激性。然而，如先前所論述，當視訊遊戲系統係自家庭執行時(尤其是當廣播之一部封包化括來自正俘獲遊戲玩家之真實世界視訊之相機的現場直播之視訊時)，此常常不可能。另外，在錦標賽情形下，所關注的為家庭中遊戲者可修改遊戲及作弊，如先前所描述。由於此等原因，電視頻道上之該等視訊遊戲廣播常常配置有聚集於公共位置處(例如，在電視演播室處或在競技場中)之播放器及視訊遊戲系統，其中電視製作設備可接受來自多個視訊遊戲系統及潛在的現場直播之相機的視訊饋送。
儘管該等先前技術視訊遊戲電視頻道可為電視觀眾提供非常刺激之演出(其為與現場直播之運動事件同類(例如，與以「運動員」呈現之視訊遊戲玩家同類)的體驗，不僅根據其在視訊遊戲世界中之動作，而且根據其在真實世界中之動作)，但此等視訊遊戲系統常常限於玩家彼此實體極接近之情形。此外，因為電視頻道係經廣播，所以每一經廣播之頻道僅可展示由電視頻道之製作人員選擇的一視訊流。由於此等限制及廣播時間、製作設備及製作人員之高成本，該等電視頻道通常僅展示參加頂級錦標賽之頂級玩家。
另外，向全部電視觀眾廣播視訊遊戲之全螢幕影像的給定電視頻道每次僅展示一視訊遊戲。此嚴重地限制電視檢視者之選擇。舉例而言，電視檢視者可能對給定時間展示之遊戲不感興趣。另一檢視者可能僅對觀看並非由電視頻道在給定時間放映的特定玩家之遊戲播放感興趣。在其他狀況下，檢視者可能僅對觀看內行玩家如何處理遊戲中之特定級別感興趣。其他檢視者可能希望控制檢視點(視訊遊戲係自其來看)，該檢視點不同於由製作小組等選擇之檢視點。簡言之，電視檢視者在觀看視訊遊戲中可能具有無數的偏好(即使若干個不同電視頻道可用，電視網路之特定廣播亦不適應該等偏好)。由於所有上述原因，使得先前技術視訊遊戲電視頻道在向電視檢視者呈現視訊遊戲中具有顯著限制。
先前技術視訊遊戲系統及應用程式軟體系統之另一缺點在於：其複雜，且通常遭受錯誤、崩潰及/或非所欲且不需要的行為(統稱「缺陷」)。儘管遊戲及應用程式在發行之前通常經歷除錯及調諧過程(經常稱為「軟體品質保證」或SQA)，但幾乎不變的是：一旦遊戲或應用程式被發行至領域中之廣大受眾，缺陷就會突然出現。遺憾的是，軟體開發商難以在發行之後識別及追蹤到許多缺陷。軟體開發商可能難以意識到缺陷。即使當其瞭解一缺陷時，亦可能僅存在其可用於識別是什麼引起該缺陷的有限量之資訊。舉例而言，使用者可打電話給遊戲開發商之消費者服務熱線且留下訊息，該訊息陳述：當玩遊戲時，螢幕開始閃爍，接著改變成固體藍且PC凍結。其為SQA小組提供了在追蹤缺陷中有用的非常少之資訊。線上連接之一些遊戲或應用程式在特定狀況下有時可提供更多資訊。舉例而言，有時可使用「看門狗」過程來監視遊戲或應用程式是否「崩潰」。看門狗過程可收集遊戲或應用程式崩潰時關於遊戲或應用程式過程之狀態(例如，記憶體堆疊之使用狀態、遊戲或應用程式進展至之程度等)的統計，且接著經由網際網路而將彼資訊上載至SQA小組。但在複雜遊戲或應用程式中，該資訊可花費非常長之時間來解密，以便準確地判定在崩潰時使用者正在進行什麼。儘管如此，亦不可能判定何事件序列導致崩潰。
與PC及遊戲控制台相關聯之又一問題在於：其經受使消費者極不便利之服務問題。服務問題亦影響PC或遊戲控制台之製造商，因為其通常需要發送特殊盒子以安全地裝運破損的PC或控制台，且因而招致修理之成本(若PC或控制台處於保修期內)。遊戲或應用程式軟體出版商亦可受處於修理狀態中之PC及/或控制台引起的銷售損失(或線上服務使用)影響。
圖1說明諸如Sony Playstation3、Microsoft Xbox 360、Nintendo WiiTM 、以Windows為基礎之個人電腦或Apple Macintosh的先前技術視訊遊戲系統。此等系統中之每一者包括用於執行程式碼之中央處理單元(CPU)(通常為用於執行高階圖形操作之圖形處理單元(GPU))，及用於與外部器件及使用者通信的多個形式之輸入/輸出(I/O)。為簡單起見，將此等組件展示為組合在一起為單一單元100。圖1之先前技術視訊遊戲系統亦展示為包括光學媒體驅動器104(例如，DVD-ROM驅動器)；用於儲存視訊遊戲程式碼及資料之硬碟機103；用於播放多人遊戲、用於下載遊戲、修補程式、演示或其他媒體之網路連接105；用於儲存當前正由CPU/GPU 100執行之程式碼的隨機存取記憶體(RAM)101；用於在遊戲播放期間接收來自使用者之輸入命令的遊戲控制器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遊戲)。組合起來，銷售之損失及與新平台相關聯之增加的開發成本可對遊戲開發商之收益性有非常顯著之不利影響。
新遊戲控制台亦非常昂貴。Xbox 360、Nintendo Wii及Sony Playstation 3均以數百美元零售。高能力之個人電腦遊戲系統可花費高達$8000。此表示使用者之顯著投資，特定言之，考慮到硬體在幾年後變陳舊及許多系統係為孩子而購買的事實。
上述問題之一方法係線上遊戲，其中將遊戲程式碼及資料主機代管於伺服器上且按要求將其遞送至用戶端機器，經壓縮之視訊及音訊經由數位寬頻帶網路而串流。一些公司(諸如，Finland之G-Cluster，其現在為日本之SOFTBANK Broadmedia的子公司)當前線上提供此等服務。類似遊戲服務變得在本端網路(諸如，旅館內及由DSL及電纜電視提供者提供之彼等網路)中可用。此等系統之較大缺點係延時之問題，亦即，信號行進至遊戲伺服器及自遊戲伺服器行進所花費的時間，遊戲伺服器通常定位於運營商之「頭端」中。快速動作視訊遊戲(亦稱為「極速(twitch)」視訊遊戲)在使用者藉由遊戲控制器執行動作之時間與更新顯示螢幕以展示使用者動作之結果的時間之間需要非常低的延時。需要低延時，以使得使用者感覺到遊戲「即刻地」回應。可視遊戲之類型及使用者之熟練程度而以不同延時間隔來滿足使用者。舉例而言，對於緩慢的非正式遊戲(類似西洋雙陸棋)或緩慢動作角色扮演遊戲而言，100毫秒之延時可能係可容忍的，但在快動作遊戲中，超過70毫秒或80毫秒之延時可引起使用者在遊戲中更拙劣地表現，且因此不可接受。舉例而言，在需要快反應時間之遊戲中，當延時自50毫秒增加至100毫秒時，存在準確度之銳降。
當遊戲或應用伺服器安裝於附近的受控網路環境或至使用者之網路路徑可預測及/或可容忍頻寬峰值的網路環境中時，在最大延時以及延時之一致性方面，控制延時容易得多(例如，因此使用者經由網路觀察到來自數位視訊串流之穩定運動)。該程度之控制可在以下達成：在電纜TV網路頭端至電纜TV用戶之家庭之間，或自DSL中央辦公室至DSL用戶之家庭，或在來自伺服器或使用者之商業辦公室區域網路(LAN)環境中。又，有可能獲得商業之間的具有得到保證之頻寬及延時的經特定分級的點到點私用連接。但在將遊戲主機代管於連接至通用網際網路之伺服器中心中且接著經由寬頻帶連接而使經壓縮之視訊串流至使用者的遊戲或應用系統中，許多因素招致延時，導致先前技術系統之部署中的嚴重限制。
在典型的連接寬頻帶之家庭中，使用者可具有用於寬頻帶服務之DSL或電纜數據機。該等寬頻帶服務通常招致使用者之家庭與通用網際網路之間的多達25毫秒之來回行程延時(且有時更多)。另外，存在由於經由網際網路將資料路由至伺服器中心而招致的來回行程延時。經由網際網路之延時基於給出資料之路線及資料被路由時資料所招致之延遲而改變。除路由延遲之外，亦由於光穿過互連大多數網際網路之光纖的速度而招致來回行程延時。舉例而言，對於每一1000英里，由於光穿過光纖之速度及其他耗用而招致約22毫秒之來回行程延時。
額外延時可由於經由網際網路串流之資料的資料速率而招致。舉例而言，若使用者具有以「6Mbps DSL服務」出售之DSL服務，則在實踐中，使用者將很可能最多得到小於5Mbps之下行輸送量，且將可能週期性地看見由於各種因素(諸如，峰值載入時間期間在數位用戶線存取多工器(DSLAM)處之擁擠)產生的連接降級。若經由相鄰者循環之本端共用同軸電纜中存在擁擠或電纜數據機系統網路中之其他地方存在擁擠，則類似問題可出現，從而將用於以「6Mbps電纜數據機服務」出售之連接的電纜數據機之資料速率減小至遠小於彼資料速率。若使4Mbps之穩定速率下的資料封包以使用者資料報協定(UDP)格式單向地自伺服器中心經由該等連接而串流，若一切皆適當地工作，則資料封包將通過而不招致額外延時，但若存在擁擠(或其他妨礙)且僅3.5Mbps可用於使資料串流至使用者，則在典型情形下，封包將被丟棄，導致丟失資料，或者封包將在擁擠點處排入佇列直至其可被發送為止，藉此引入了額外延時。不同擁擠點具有用於保存經延遲之封包的不同排入佇列容量，因此在一些狀況下，立即將不可成功解決擁擠之封包丟棄。在其他狀況下，將數百萬位元之資料排入佇列且最終將其發送。但是，在幾乎所有狀況下，擁擠點處之佇列具有容量限制，且一旦超過彼等限制，佇列將溢出且封包將被丟棄。因此，為了避免招致額外延時(或更糟地，封包之丟失)，必須避免超過自遊戲或應用伺服器至使用者之資料速率容量。
亦由於在伺服器中壓縮視訊及在用戶端器件中解壓縮視訊所需之時間而招致延時。當在伺服器上執行之視訊遊戲正在計算待顯示之下一個圖框時，進一步招致延時。當前可用之視訊壓縮演算法遭受高資料速率或高延時。舉例而言，運動JPEG為僅框內有損之壓縮演算法，其特徵為低延時。視訊之每一圖框獨立於視訊之每一其他圖框而壓縮。當用戶端器件接收經壓縮之運動JPEG視訊的一圖框時，其可立即解壓縮該圖框且顯示該圖框，從而導致非常低之延時。但因為每一圖框係分開進行壓縮，所以演算法不能夠利用相繼圖框之間的類似性，且因此僅框內視訊壓縮演算法遭受非常高之資料速率。舉例而言，60fps(每秒圖框數)640×480運動JPEG視訊可能需要40Mbps(每秒百萬位元)或40Mbps(每秒百萬位元)以上之資料。用於該等低解析度視訊窗之該等高資料速率在許多寬頻帶應用程式中將係過於昂貴(且對於大多數消費者的以網際網路為基礎之應用程式的確如此)。另外，因為每一圖框經獨立壓縮，所以可能由於有損壓縮而產生的圖框中之假影可能出現於相繼圖框中之不同位置處。此可導致當解壓縮視訊時，在檢視者看來為移動的視覺假影。
其他壓縮演算法(諸如，來自Microsoft公司之MPEG2、H.264或VC9)當用於先前技術組態中時，可達成高壓縮比率，但以高延時為代價。該等演算法利用框間壓縮以及框內壓縮。週期性地，該等演算法執行圖框之僅框內壓縮。此種圖框被稱為關鍵圖框(通常稱作「I」圖框)。接著，此等演算法通常將I圖框與先前圖框與相繼圖框兩者相比較。並非獨立地壓縮先前圖框及相繼圖框，而是演算法判定影像自I圖框至先前圖框及相繼圖框有何改變，且接著將彼等改變儲存為：「B」圖框(對於I圖框之前的改變)及「P」圖框(對於I圖框之後的改變)。此導致比僅框內壓縮低得多的資料速率。但是，其通常以較高延時為代價。I圖框通常比B圖框或P圖框大得多(常常大10倍)，且因此，以給定資料速率傳輸成比例地花費較長之時間。
考慮(例如)一情形：其中I圖框為B圖框及P圖框之大小的10倍，且對於每個單一I框內，存在29個B圖框+30個P圖框==59個框間，或對於每一「圖框群」(GOP)總共60個圖框。因此，在60fps下，每秒存在1個60圖框GOP。假設傳輸頻道具有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(通常額定在100Mbps-1 Gbps)及具有足夠頻寬之租用線路通常可支援峰值頻寬要求(例如，18Mbps峰值頻寬為100 Mbps LAN容量之一小分率)。
若進行特殊適應，則峰值頻寬要求亦可由住宅寬頻帶基礎架構來適應。舉例而言，在電纜TV系統上，可為數位視訊訊務給出專用頻寬，該專用頻寬可處理諸如大I圖框之峰值。此外，在DSL系統上，可供應較高速度之DSL數據機(慮及高峰值)，或可供應可處理較高資料速率之經特別分級的連接。但是，附接至通用網際網路之習知電纜數據機及DSL基礎架構對於用於經壓縮之視訊的峰值頻寬要求而言遠不能容忍。因此，線上服務(將視訊遊戲或應用程式主機代管於距用戶端器件長距離之伺服器中心中，且接著經由習知的住宅寬頻帶連接經由網際網路而使經壓縮之視訊輸出串流)遭受顯著之延時及峰值頻寬要求-尤其對於需要非常低之延時的遊戲及應用程式(例如，第一人稱射擊遊戲及其他多使用者、互動式動作遊戲，或需要快回應時間之應用程式)。
本揭示案將自以下[實施方式]及附圖而更完全地理解，然而，其不應用於將所揭示之標的物限於所展示之特定實施例，而僅用於說明及理解。
在以下描述中闡述特定細節(諸如，器件類型、系統組態、通信方法等)，以便提供對本揭示案之徹底理解。然而，一般熟習相關技術者應瞭解，實踐所描述之該等實施例可能不需要此等特定細節。
圖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毫秒之延時(自輸入器件被使用者致動之時刻至在顯示器件上顯示回應時之時刻)為用於需要快回應時間之遊戲及應用程式的上限。然而，由於大量實際及實體約束而使得此在圖2a及圖2b中所展示之架構的情況下非常難以達成。
如圖3中所指示，當使用者訂用網際網路服務時，連接通常額定為至使用者之家庭或辦公室的標稱最大資料速率301。取決於提供者之策略及路由設備能力，彼最大資料速率可或多或少被嚴格地強制執行，但通常由於許多不同原因中之一者而使得實際可用資料速率較低。舉例而言，可能在DSL中央辦公室處或在本端電纜數據機迴路上存在過多網路訊務，或可能在電纜線上存在雜訊，從而引起丟棄之封包，或提供者可能建立每使用者每月最大數目之位元。當前，用於電纜及DSL服務之最大下行資料速率通常在數百千位元/秒(Kbps)至30Mbps之範圍內。蜂巢式服務通常限於數百Kbps之下行資料。然而，寬頻帶服務之速度及訂用寬頻帶服務之使用者之數目將隨著時間而急劇增加。當前，一些分析者估計33%之美國寬頻帶用戶具有2Mbps或2Mbps以上之下行資料速率。舉例而言，一些分析者預測：至2010年止，超過85%之美國寬頻帶用戶將具有2Mbps或2Mbps以上之資料速率。
如圖3中所指示，實際可用最大資料速率302可隨著時間而波動。因此，在低延時、線上遊戲或應用程式軟體情況下，有時難以預測用於特定視訊流之實際可用資料速率。若對於特定量之場景複雜度及運動在給定數目之每秒圖框數(fps)下以給定解析度(例如，640×480＠60fps)維持給定品質位準所需的資料速率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，以較不頻繁地存取幾何形狀或遊戲狀態資訊之大資料庫。
另外，在一實施例中，主機代管服務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使用用戶端475 USB輸入將經壓縮之視訊提供至用戶端475，經壓縮之視訊由用戶端475上載至主機代管服務210以用於下文所描述之用途。將利用下文所描述之壓縮技術將低延時壓縮器建置於相機477中。
除具有用於其網際網路連接之乙太網路連接器之外，用戶端475亦具有至網際網路之802.11g無線介面。兩種介面均能夠在支援NAT之網路內使用NAT。
又，除具有用於輸出視訊及音訊之HDMI連接器之外，用戶端475亦具有雙鏈接DVI-I連接器，雙鏈接DVI-I連接器包括類比輸出端(且具有將提供VGA輸出之標準配接器電纜)。其亦具有用於複合視訊及S視訊之類比輸出端。
對於音訊，用戶端475具有左/右類比立體RCA插孔，且對於數位音訊輸出，其具有TOSLINK輸出端。
除了至輸入器件479之藍芽無線介面之外，其亦具有用於介接至輸入器件之USB插孔。
圖4e展示用戶端465之內部架構之一實施例。該圖中所展示的所有器件或一些器件可實施於場可程式化邏輯陣列、定製ASIC中或若干個離散器件(定製設計或者現成的)中。
具有PoE之乙太網路497附接至乙太網路介面481。電力499係自具有PoE之乙太網路497得到且連接至用戶端465中之其餘器件。匯流排480為用於器件之間的通信之公同匯流排。
執行來自快閃記憶體476之小用戶端控制應用程式的控制CPU 483(幾乎任何小CPU係適當的，諸如具有嵌入式RAM的100MHz下的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 Logic of Manly。使用IP之優點在於：本文中所使用之壓縮技術與壓縮標準不相符。一些標準解壓縮器足夠靈活以經組態以適應本文中之壓縮技術，但一些標準解壓縮器可能並非如此。但是，在IP之情況下，在視需要而重新設計解壓縮器中存在完全靈活性。
視訊解壓縮器之輸出端耦合至視訊輸出子系統487，視訊輸出子系統487將視訊耦合至HDMI介面490之視訊輸出端。
音訊解壓縮子系統488或者使用可用的標準音訊解壓縮器來實施，或者其可實施為IP，或者可在可(例如)實施Vorbis音訊解壓縮器之控制處理器483內實施音訊解壓縮。
實施音訊解壓縮之器件耦合至音訊輸出子系統489，音訊輸出子系統489將音訊耦合至HDMI介面490之音訊輸出端。
圖4f展示用戶端475之內部架構之一實施例。如可見，除額外介面及來自插入牆壁中之電源配接器的可選外部DC電力(且若如此使用，則可選外部DC電力替換將來自乙太網路PoE 497之電力)之外，該架構與用戶端465之架構相同。下文中將不重複與用戶端465共同之功能性，但將額外功能性描述如下。
CPU 483與額外器件通信且組態額外器件。
WiFi子系統482經由其天線提供無線網際網路存取，作為對乙太網路497之替代。WiFi子系統可購自多家製造商，包括CA之Santa Clara之Atheros Communications。
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及電纜數據機連接，此等延時可在下一段中所描述之情形中達成。又，注意，儘管至網際網路之蜂巢式無線連接性的確將在所展示之系統中工作，但大多數當前美國蜂巢式資料系統(諸如，EVDO)招致非常高之延時且將不能夠達成圖4b中所展示之延時。然而，此等基本原理可在可能能夠實施此位準之延時的未來蜂巢式技術上實施。
自使用者場所211處之輸入器件421開始，一旦使用者致動輸入器件421，就將使用者控制信號發送至用戶端415(其可為諸如機頂盒之獨立器件，或其可為在諸如PC或行動器件之另一器件中執行的軟體或硬體)，且將其封包化(在一實施例中以UDP格式)並為封包給出目的地位址以到達主機代管服務210。封包將亦含有用於指示控制信號係來自哪個使用者的資訊。接著經由防火牆/路由器/NAT(網路位址轉譯)器件443將控制信號封包轉遞至WAN介面442。WAN介面442為由使用者之ISP(網際網路服務提供者)提供至使用者場所211的介面器件。WAN介面442可為電纜或DSL數據機、WiMax收發器、光纖收發器、蜂巢式資料介面、電力線網際網路協定介面(Internet Protocol-over-powerline interface)，或至網際網路之許多介面中的任何其他介面。另外，可將防火牆/路由器/NAT器件443(及(可能地)WAN介面442)整合於用戶端415中。此之一實例將為行動電話，其包括用於實施家庭或辦公室用戶端415之功能性的軟體，以及用於經由某一標準(例如，802.11g)而無線地路由及連接至網際網路的構件。
WAN介面442接著將控制信號路由至本文中所稱的用於使用者之網際網路服務提供者(ISP)的「存在點」441，WAN介面442為提供連接至使用者場所211之WAN輸送器與通用網際網路或私用網路之間的介面的設施。存在點之特性將視所提供之網際網路服務的性質而改變。對於DSL，其通常將為DSLAM所定位之電話公司中央辦公室。對於電纜數據機，其通常將為電纜多系統運營商(MSO)頭端。對於蜂巢式系統，其通常將為與蜂巢式塔相關聯的控制室。但無論存在點之性質怎樣，其均將接著將控制信號封包路由至通用網際網路410。接著經由將最可能係光纖收發器介面之介面將控制信號封包路由至WAN介面444至主機代管服務210。WAN 444將接著將控制信號封包路由至路由邏輯409(其可以許多不同方式來實施，包括乙太網路交換器及路由伺服器)，路由邏輯409估計使用者之位址且將控制信號路由至用於給定使用者之正確的伺服器402。
伺服器402接著將該等控制信號視為在伺服器402上執行之遊戲或應用程式軟體的輸入且使用該等控制信號來處理遊戲或應用程式之下一個圖框。一旦產生下一個圖框，就將視訊及音訊自伺服器402輸出至視訊壓縮器404。可經由各種構件將視訊及音訊自伺服器402輸出至壓縮器404。首先，可將壓縮器404建置於伺服器402中，因此可在伺服器402內在本端實施壓縮。或者，可經由至網路(其或者為伺服器402與視訊壓縮器404之間的私用網路，或者為經由諸如SAN 403之共用網路的網路)之網路連接(諸如，乙太網路連接)以封包化形式輸出視訊及/或音訊。或者，可經由視訊輸出連接器(諸如，DVI或VGA連接器)將視訊自伺服器402輸出，且接著由視訊壓縮器404來俘獲。又，可將音訊自伺服器402輸出為數位音訊(例如，經由TOSLINK或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×480×24位元/像素=640*480*24/8/1024=900千位元組/圖框(KB/圖框)之圖框速率，則對於給定品質之影像，運動JPEG可能僅將該流壓縮1/10，從而產生90KB/圖框之資料流。在60圖框/秒下，此將需要90KB*8位元*60圖框/秒=42.2Mbps之頻道頻寬，其對於美國現今幾乎所有的家庭網際網路連接而言將為極高之頻寬，且對於許多辦公室網際網路連接而言為過高之頻寬。實際上，假定其在此種高頻寬之情況下要求恆定資料流，且其將僅伺服一使用者，則即使在辦公室LAN環境中，其亦將消耗100Mbps乙太網路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圖框之解碼僅依賴於先前所接收之圖框。此方法仍存在的問題在於：I圖框比平均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下640×480像素的相對低解析度的視訊流的實例。60fps下之1920×1080的HDTV流容易由現代電腦及顯示器來處理，且60fps下之2560×1440解析度顯示器日益可用(例如，Apple公司之30"顯示器)。使用H.264壓縮，60fps下之1920×1080之高動作視訊序列可能需要4.5Mbps以獲得合理品質位準。若假定I圖框峰值為標稱資料速率之10倍，則其將產生45Mbps峰值，以及較小但仍相當大的P圖框峰值。若若干個使用者正在同一100Mbps網路(例如，辦公室與資料中心之間的私用網路連接)上接收視訊流，則容易看見來自若干使用者之視訊流之峰值可如何碰巧對準，從而淹沒網路之頻寬，且可能淹沒網路上支援使用者之交換器的底板之頻寬。即使在超高速乙太網路之狀況下，若足夠的使用者具有同時對準的足夠峰值，則其可淹沒網路或網路交換器。此外，一旦2560×1440解析度視訊變得更常見，平均視訊流資料速率就可能為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中所展示之特定實例中，將每一未經壓縮之圖框再分成4×4矩陣的16個影像塊。然而，此等基本原理不限於任何特定再分機制。
在一實施例中，低延時壓縮邏輯404將視訊圖框劃分成許多影像塊，且將來自每一圖框之一影像塊編碼(亦即，壓縮)為I圖框(亦即，將該影像塊壓縮，好像其為全影像之大小之1/16的單獨視訊圖框，且用於此「迷你型」圖框之壓縮為I圖框壓縮)並將剩餘影像塊編碼為P圖框(亦即，用於每一「迷你型」1/16圖框之壓縮為P圖框壓縮)。經壓縮為I圖框之影像塊及經壓縮為P圖框之影像塊將分別被稱作「I影像塊」及「P影像塊」。隨著每一相繼視訊圖框而改變待編碼為I影像塊之影像塊。因此，在給定圖框時間中，視訊圖框中之該等影像塊中僅一影像塊為I影像塊，且該等影像塊中之剩餘者為P影像塊。舉例而言，在圖7a中，未經壓縮之圖框701之影像塊0經編碼為I影像塊I0 且剩餘的1-15影像塊經編碼為P影像塊(P1 至P15 )以產生R圖框711。在下一個未經壓縮之視訊圖框702中，未經壓縮之圖框701之影像塊1經編碼為I影像塊I1 且剩餘的影像塊0及2至15經編碼為P影像塊(P0 ，及P2 至P15 )以產生R圖框712。因此，用於影像塊之I影像塊及P影像塊在相繼圖框上逐漸地在時間上交錯。該過程繼續，直至產生R影像塊770(矩陣中最末影像塊經編碼為I影像塊(亦即，I15 ))為止。該過程接著重新開始，從而產生諸如圖框711(亦即，對於影像塊0，編碼I影像塊)等之另一R圖框。儘管圖7a中未說明，但在一實施例中，R圖框之視訊序列之第一R圖框僅含有I影像塊(亦即，以使得隨後之P圖框具有參考影像資料(自其開始計算運動))。或者，在一實施例中，啟動序列使用與正常相同的I影像塊型樣，但不包括用於尚未連同I影像塊一起編碼之彼等影像塊的P影像塊。換言之，在第一I影像塊到達之前不連同任何資料一起編碼特定影像塊，藉此避免圖9a中的視訊流資料速率934中之啟動峰值，其在下文進一步詳細說明。此外，如下所述，各種不同大小及形狀可用於該等影像塊同時仍遵守此等基本原理。
在用戶端415上執行之視訊解壓縮邏輯412解壓縮每一影像塊，好像其為小I圖框及P圖框之單獨視訊序列，且接著將每一影像塊再現給驅動顯示器件422之圖框緩衝器。舉例而言，使用來自R圖框711至770之I0 及P0 來解壓縮並再現視訊影像之影像塊0。類似地，使用來自R圖框711至770之I1 及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*1Kb=25Kb之R圖框。因此，每一60圖框序列將係25Kb*60=1.5Mbps。因此，在60圖框/秒下，此將需要能夠維持1.5Mbps之頻寬的頻道，但由於I影像塊係貫穿60圖框間隔而分散而使得具有低得多的峰值。
注意，在先前實例中，在用於I圖框及P圖框之相同假定資料速率情況下，平均資料速率為1.1Mbps。此係因為在先前實例中，每隔60個圖框時間僅引入一新I圖框，而在此實例中，構成I圖框之16個影像塊在16個圖框時間中循環，且因此，每隔16個圖框時間引入一I圖框之均等物，從而導致稍高之平均資料速率。儘管如此，但在實踐中，引入更頻繁之I圖框並不會線性地增加資料速率。此係由於以下事實：P圖框(或P影像塊)主要編碼自先前圖框至下一個圖框之差異。因此，若先前圖框與下一個圖框相當類似，則P圖框將非常小，若先前圖框與下一個圖框相當不同，則P圖框將非常大。但因為P圖框很大程度上係自先前圖框導出，而非自實際圖框導出，所以所得的經編碼圖框可能含有比具有足夠數目之位元之I圖框多的錯誤(例如，視覺假影)。此外，當一P圖框跟隨另一P圖框時，可出現錯誤累加(當存在長P圖框序列時，變得更糟)。現在，尖端的視訊壓縮器將偵測到影像之品質在一序列P圖框之後降級的事實，且必要時，其將更多位元分配給隨後之P圖框以提高品質，或若其為最有效之動作過程，則用I圖框替換P圖框。因此，當使用長P圖框序列(例如，59個P圖框，如上文先前實例中)時，特定言之當場景具有大量複雜度及/或運動時，通常，對於P圖框而言需要更多位元(因為其變得距I圖框更遠)。
或者，自相對檢視點看P圖框，緊密地跟隨I圖框之P圖框傾向於需要比距I圖框更遠之P圖框少的位元。因此，在圖7a中所展示之實例中，無P圖框比距I圖框隔開15個圖框更遠(在I圖框之前)，而在先前實例中，P圖框可為自I圖框隔開59個圖框。因此，在更頻繁之I圖框情況下，P圖框較小。當然，確切相對大小將基於視訊流之性質而改變，但在圖7a之實例中，若I影像塊為10Kb，則P影像塊之大小平均可為僅0.75kb，從而導致10Kb+15*0.75Kb=21.25Kb，或在60圖框/秒下，資料速率將為21.25Kb*60=1.3Mbps，或比1.1Mbps下的具有一I圖框繼之以59個P圖框之流之資料速率高約16%。再一次，用於視訊壓縮之此等兩種方法之間的相對結果將視視訊序列而改變，但通常，吾人憑經驗發現，對於給定品質位準，使用R圖框比使用I/P圖框序列需要多約20%之位元。但是，當然，R圖框急劇地減少峰值，此使視訊序列在遠小於I/P圖框序列之延時下可用。
可視視訊序列之性質、頻道之可靠性及可用資料速率而以多種不同方式來組態R圖框。在替代實施例中，在4×4組態中使用不同於16之數目之影像塊。舉例而言，可在2×1或1×2組態中使用2個影像塊，可在2×2、4×1或1×4組態中使用4個影像塊，可在3×2、2×3、6×1或1×6組態中使用6個影像塊或可在4×2(如圖7b中所展示)、2×4、8×1或1×8組態中使用8個影像塊。注意，影像塊不需要為方形，視訊圖框亦不必為方形，或甚至矩形。可將影像塊分解成最佳地適合所使用之視訊流及應用程式的無論什麼形狀。
在另一實施例中，I影像塊及P影像塊之循環不鎖定至影像塊之數目。舉例而言，在8影像塊4×2組態中，仍可如圖7b中所說明而使用16循環序列。順序的未經壓縮之圖框721、722、723各自經劃分成8個影像塊0-7，且每一影像塊經個別壓縮。自R圖框731，僅影像塊0經壓縮為I影像塊，且剩餘影像塊經壓縮為P影像塊。對於隨後之R圖框732，所有8個影像塊經壓縮為P影像塊，且接著對於隨後之R圖框733，影像塊1經壓縮為I影像塊且其他影像塊均經壓縮為P影像塊。此外，如此對於16個圖框繼續進行排序，僅每隔一圖框產生一I影像塊，因此在第15個圖框時間期間(圖7b中未圖示)及在第16個圖框時間期間產生用於影像塊7之最末I影像塊(使用所有的P影像塊壓縮R圖框780)。接著，序列再次以影像塊0經壓縮為I影像塊且其他影像塊經壓縮為P影像塊開始。如在先前實施例中，整個視訊序列之第一圖框通常將均為I影像塊，以提供用於自彼點向前之P影像塊的參考。I影像塊及P影像塊之循環甚至不需要為影像塊之數目之偶倍數。舉例而言，在8個影像塊之情況下，在使用另一I影像塊之前，具有一I影像塊之每一圖框之後可為所有皆為P影像塊之2個圖框。在又一實施例中，若(例如)已知螢幕之特定區域具有更多運動(需要更頻繁之I影像塊)，而其他區域更為靜態(例如，展示遊戲之分數)(需要較不頻繁之I影像塊)，則與其他影像塊相比，可更經常地將特定影像塊連同I影像塊一起進行排序。此外，儘管在圖7a-圖7b中說明每一圖框具有單一I影像塊，但可在單一圖框中編碼多個I影像塊(取決於傳輸頻道之頻寬)。相反地，特定圖框或圖框序列可在不具有I影像塊(亦即，僅P影像塊)的情況下傳輸。
前一段之方法適當起作用之原因在於：儘管不具有跨越每個單一圖框而分散之I影像塊看來似乎導致較大峰值，但系統之行為並不如此簡單。因為每一影像塊係與其他影像塊分開進行壓縮，所以當影像塊變小時，每一影像塊之編碼可變得較不有效，因為給定影像塊之壓縮器不能夠利用來自其他影像塊之類似影像特徵及類似運動。因此，與將螢幕劃分成8個影像塊相比較，將螢幕劃分成16個影像塊通常將導致較不有效之編碼。但是，若將螢幕劃分成8個影像塊且其引起每隔8個圖框(而非每隔16個圖框)引入一完全I圖框之資料，則其導致總體上高得多的資料速率。因此，藉由每隔16個圖框(而非每隔8個圖框)引入一完全I圖框，減小了總資料速率。又，藉由使用8個較大影像塊(而非16個較小影像塊)，減小了總資料速率，其亦將由較大影像塊引起之資料峰值減輕至某種程度。
在另一實施例中，圖7a及圖7b中之低延時視訊壓縮邏輯404藉由基於待壓縮之視訊序列之已知特性而藉由設定預先組態或者基於每一影像塊中之影像品質的正在進行之分析而自動地控制至R圖框中之各影像塊之位元的分配。舉例而言，在一些競賽視訊遊戲中，玩家之汽車(其為場景中相對無運動的)之前方佔據螢幕之下半部之大部分，而螢幕之上半部完全被填滿正接近的道路、建築物及風景，其幾乎總是在運動中。若壓縮邏輯404將相等數目之位元分配給每一影像塊，則圖7b中的未經壓縮之圖框721中的螢幕之下半部上之影像塊(影像塊4-7)通常將以比圖7b中的未經壓縮之圖框721中的螢幕之上半部中之影像塊(影像塊0-3)高的品質而壓縮。若已知此特定遊戲或遊戲之此特定場景具有該等特性，則主機代管服務210之運營商可組態壓縮邏輯404以將更多位元分配給螢幕之頂部之影像塊(與分配給螢幕之底部處之影像塊的位元相比)。或者，壓縮邏輯404可在壓縮圖框之後估計影像塊之壓縮品質(使用許多壓縮品質度量中之一或多者，諸如峰值信號雜訊比(PSNR))，且若判定在特定時間窗上，特定影像塊始終如一地產生較佳品質結果，則其逐漸地將更多位元分配給產生較低品質結果之影像塊，直至各種影像塊達到類似位準之品質為止。在替代實施例中，壓縮器邏輯404分配位元以在特定影像塊或影像塊群中達成較高品質。舉例而言，其可提供較佳的總體感知外觀，以在螢幕之中心具有比邊緣處高之品質。
在一實施例中，為了改良視訊流之特定區域之解析度，視訊壓縮邏輯404使用較小影像塊來編碼視訊流之具有相對多之場景複雜度及/或運動的區域(與視訊流之具有相對少之場景複雜度及/或運動的區域相比)。舉例而言，如圖8中所說明，在一R圖框811(可能繼之以具有相同影像塊大小之一系列R圖框(未圖示))之一區域中的移動人物805之周圍使用較小影像塊。接著，當人物805移動至影像之新區域時，在另一R圖框812內之此新區域之周圍使用較小影像塊，如所說明。如上所述，各種不同大小及形狀可用作「影像塊」同時仍遵守此等基本原理。
儘管上文所描述之循環I/P影像塊實質上減小視訊流之資料速率中的峰值，但其並不完全消除峰值，尤其在快速改變或高度複雜之視訊影像(諸如在電影、視訊遊戲及某一應用程式軟體下出現)的狀況下。舉例而言，在突然場景轉變期間，一複雜圖框可能繼之以完全不同之另一複雜圖框。即使若干個I影像塊可領先於場景轉變僅幾個圖框時間，其在此情形下亦無助益，因為新圖框之材料與先前I影像塊無關。在此種情形下(及在即使並非一切皆改變，大量影像亦改變的其他情形下)，視訊壓縮器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(例如，100Mbs乙太網路或802.11g無線網路)上或私用網路(例如，資料中心與辦公室之間的100Mbps連接)上之辦公室環境中，可在無峰值情況下傳輸高動作視訊流，以使得多個使用者(例如，以4.5Mbps傳輸60fps下之1920×1080)可使用LAN或共用私用資料連接，而不使重疊峰值淹沒網路或網路交換器底板。
資料速率調整
在一實施例中，主機代管服務210最初評估頻道之可用最大資料速率622及延時以判定用於視訊流之適當資料速率且接著回應於此而動態地調整資料速率。為了調整資料速率，主機代管服務210可(例如)修改待發送至用戶端415之視訊流的影像解析度及/或每秒圖框數。又，主機代管服務可調整經壓縮視訊的品質位準。當改變視訊流之解析度時(例如，自1280×720解析度至640×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技術產生錯誤校正資料資訊並將其附加至經由通信頻道而傳輸之資料。若錯誤在基本資料(例如，1圖框)中出現，則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之錯誤校正碼且FEC 1104含有用於I影像塊1103之錯誤校正碼。在此實施例中，對於P影像塊不產生FEC。
在圖11b中所說明之一實施例中，對於在丟失時最可能引起視覺假影之P影像塊亦產生FEC碼。在此實施例中，FEC 1105提供用於前3個P影像塊但不用於跟隨的P影像塊之錯誤校正碼。在另一實施例中，對於資料大小最小之P影像塊產生FEC碼(其將傾向於自選在I影像塊之後最早出現的P影像塊，其對於保護最為關鍵)。
在另一實施例中，並非將FEC碼連同影像塊一起發送，而是將影像塊傳輸兩次，每次在不同封包中傳輸。若一封包丟失/延遲，則使用另一封包。
在圖11c中所展示之一實施例中，產生分別用於與視訊同時自主機代管服務傳輸之音訊封包1110及1112的FEC碼1111及1113。維持視訊流中之音訊之完整性特別重要，因為失真之音訊(例如，滴答聲或嘶嘶聲)將導致特別不合需要之使用者體驗。FEC碼幫助確保音訊內容在用戶端電腦415處無失真地再現。
在另一實施例中，並非將FEC碼連同音訊資料一起發送，而是將音訊資料傳輸兩次，每次在不同封包中傳輸。若一封包丟失/延遲，則使用另一封包。
另外，在圖11d中所說明之一實施例中，FEC碼1121及1123分別用於自用戶端415上行傳輸至主機代管服務210之使用者輸入命令(例如，按鈕按壓)1120及1122。此係重要的，因為在視訊遊戲或應用程式中漏掉按鈕按壓或滑鼠運動可能導致不合需要之使用者體驗。
在另一實施例中，並非將FEC碼連同使用者輸入命令資料一起發送，而是將使用者輸入命令資料傳輸兩次，每次在不同封包中傳輸。若一封包丟失/延遲，則使用另一封包。
在一實施例中，主機代管服務210評估與用戶端415之通信頻道之品質，以判定是否使用FEC，且若使用，則判定應對視訊、音訊及使用者命令之何部分應用FEC。評估頻道之「品質」可包括如上所述的諸如估計封包丟失、延時等之功能。若頻道特別不可靠，則主機代管服務210可對所有I影像塊、P影像塊、音訊及使用者命令應用FEC。相比之下，若頻道可靠，則主機代管服務210可僅對音訊及使用者命令應用FEC，或可不對音訊或視訊應用FEC，或可根本不使用FEC。可使用FEC之應用之各種其他排列，同時仍遵守此等基本原理。在一實施例中，主機代管服務210不斷地監視頻道之狀況且相應地改變FEC策略。
在另一實施例中，參看圖4a及圖4b，當封包丟失/延遲，從而導致影像塊資料之丟失時，或若可能由於特別糟之封包丟失而使得FEC不能夠校正丟失的影像塊資料，用戶端415評估在將接收新的I影像塊之前剩餘多少個圖框且將其與自用戶端415至主機代管服務210之來回行程延時相比較。若來回行程延時小於新的I影像塊應到達之前的圖框之數目，則用戶端415向主機代管服務210發送訊息，請求新的I影像塊。將此訊息路由至視訊壓縮器404，且其並非產生用於資料已丟失之影像塊的P影像塊，而是產生I影像塊。假定圖4a及圖4b中所展示之系統經設計以提供通常小於80毫秒之來回行程延時，則此導致影像塊被校正於80毫秒內(在60fps下，圖框具有16.67毫秒之持續時間，因此在全圖框時間中，80毫秒延時將導致83.33毫秒內的經校正之影像塊，83.33毫秒為5個圖框時間，其為引人注意的中斷，但遠不及(例如)對於15個圖框250毫秒中斷引人注意)。當壓縮器404脫離其通常的循環次序而產生此種I影像塊時，若I影像塊將引起彼圖框之頻寬超過可用頻寬，則壓縮器404將延遲其他影像塊之循環，以使得其他影像塊在彼圖框時間期間接收P影像塊(即使在彼圖框期間一影像、塊通常將應為I影像塊)，且接著通常的循環將自下一個圖框開始繼續，且通常將已接收到先前圖框中之I影像塊的影像塊將接收I影像塊。儘管此動作暫時延遲R圖框循環之階段，但其通常將在視覺上不引人注意。
視訊及音訊壓縮器/解壓縮器實施
圖12說明一特定實施例，其中使用多核及/或多處理器1200來並行地壓縮8個影像塊。在一實施例中，使用在2.66GHz或更高下執行之雙核處理器、四核Xeon CPU電腦系統，每一核心作為獨立過程實施開源x264 H.264壓縮器。然而，可使用各種其他硬體/軟體組態，同時仍遵守此等基本原理。舉例而言，CPU核心中之每一者可藉由以FPGA實施之H.264壓縮器來替換。在圖12中所展示之實例中，核心1201-1208用於作為八個獨立線緒來同時處理I影像塊及P影像塊。如此項技術中眾所熟知的，當前多核及多處理器電腦系統與諸如Microsoft Windows XP專業版(64位元版或者32位元版)及Linux之多線緒處理作業系統整合時，其固有地能夠進行多線緒處理。
在圖12中所說明之實施例中，因為該8個核心中之每一者僅負責一影像塊，所以其很大程度上獨立於其他核心而操作，每一者執行x264之單獨實例化。使用以PCI Express x1為基礎之DVI俘獲卡(諸如，來自Nether1ands的Microtronix of Oosterhout之Sendero視訊成像IP開發板)來俘獲640×480、800×600或1280×720解析度下的未經壓縮之視訊，且卡上之FPGA使用直接記憶體存取(DMA)來將所俘獲之視訊經由DVI匯流排傳送至系統RAM中。將該等影像塊配置成4×2配置1205(儘管其說明為方形影像塊，但在此實施例中，其具有160×240解析度)。x264之每一實例化經組態以壓縮該8個160×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輸出端將新圖框自以主機板為基礎之圖形系統或者經由NVIDIA 8800GTX PCIEXpress卡之DVI輸出端輸出。
同時，伺服器402經由其數位音訊輸出端(例如，S/PDIF)輸出由遊戲或應用程式產生之音訊，該數位音訊輸出端耦合至實施視訊壓縮的以雙四核Xeon為基礎之PC上的數位音訊輸入端。Vorbis開源音訊壓縮器用於使用可用於處理線緒之無論什麼核心來與視訊同時地壓縮音訊。在一實施例中，完成壓縮其影像塊之核心首先執行音訊壓縮。接著將經壓縮之音訊連同經壓縮之視訊一起傳輸，並在用戶端415上使用Vorbis音訊解壓縮器來解壓縮經壓縮之音訊。
主機代管服務伺服器中心分配
經由玻璃(諸如，光纖)之光以光在真空中之速度的某一分率行進，且因此可判定光在光纖中之確切傳播速度。但是，在實踐中，考慮用於路由延遲、傳輸無效率及其他耗用之時間，吾人觀察到網際網路上之最佳延時反映較接近光速之50%的傳輸速度。因此，最佳1000英里來回行程延時為約22毫秒，且最佳3000英里來回行程延時為約64毫秒。因此，一美國海岸上之單一伺服器將距離過遠以致不能以所要之延時伺服另一海岸上之用戶端(其可能達3000英里遠)。然而，如圖13a中所說明，若主機代管服務210伺服器中心1300定位於美國之中心(例如，Kansas、Nebraska等)，以致至美國大陸中之任何點之距離為約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正使用在San Francisco提供的AT&T之DSL服務接收來自使用者之大量訊務(而非路由至以AT&T之San Francisco為基地的中央辦公室)，則主機代管服務210將在以San Francisco為基地之中央辦公室與用於主機代管服務210之伺服器中心中的一或多者之間租用來自服務提供者(可能為AT&T本身或另一提供者)之高容量私用資料連接。接著，若自所有主機代管服務伺服器中心HS1-HS6經由通用網際網路至San Francisco中使用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之子網路的網路連接及至附接至其他器件之子網路的另一網路連接。
應用程式/遊戲伺服器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影像塊之參考)、視訊輸出之解析度；壓縮之品質；影像塊結構；每影像塊之位元之分配；壓縮品質、音訊格式(例如，立體聲、環繞音效、DolbyAC-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中(「遊戲取景器」螢幕)。此特定使用者介面螢幕允許使用者觀看由其他使用者現場玩的(或延遲的)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」)及遊戲標誌「極品飛車卡本峽谷」及橙色橫條在相對條件下指示在彼特定時刻玩遊戲或檢視遊戲之人的數目(在此狀況下，許多，因此遊戲為「熱門」)。另外提供「狀態」，指示存在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發送訊息以指示不再檢視其他遊戲。此時，產生的唯一顯示為螢幕頂部的上覆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完成地早一圖框時間之一半，則其將衝擊傳輸時間992)。在此種情形下，共用視訊壓縮硬體1530將忽略來自新伺服器之第一圖框(例如，如忽略(974)圖框4964)，且用戶端415將來自舊伺服器之最末圖框保持一額外圖框時間，且共用視訊壓縮硬體1530將開始壓縮來自主機代管遊戲之新應用程式/遊戲伺服器的下一圖框時間視訊。對於使用者而言，在視覺上，自一應用程式/遊戲伺服器至另一應用程式/遊戲伺服器之轉變將係無縫的。主機代管服務控制伺服器401接著將通知主機代管遊戲取景器之應用程式/遊戲伺服器1521-1525切換至閒置狀態，直至再次需要其為止。
使用者接著能夠玩該遊戲。此外，例外的係遊戲將在感知上係即刻地播放(因為遊戲已被以十億位元/秒速度自Raid陣列1511-1512載入至應用程式/遊戲伺服器1521-1525上)，且將藉由理想的驅動器、暫存器組態(在Windows之狀況下)將遊戲連同經確切組態以用於該遊戲之作業系統一起載入至確切適合於該遊戲之伺服器上，且無可能與該遊戲之操作競爭的其他應用程式在該伺服器上執行。
又，隨著使用者在遊戲中進展，遊戲之片段中之每一者將以十億位元/秒速度(亦即，8秒1次十億位元組載入)自RAID陣列1511-1512載入伺服器中，且由於RAID陣列1511-1512之巨大儲存容量(因為其為許多使用者之共用資源，所以其可能非常大，但仍具成本效益)，使得可預先計算幾何形狀設置或其他遊戲片段設置並將其儲存於RAID陣列1511-1512上且極快速地進行載入。此外，因為每一應用程式/遊戲伺服器1521-1525之硬體組態及計算能力係已知的，所以可預先計算像素及頂點著色。
因此，遊戲可幾乎即刻啟動，其將在理想環境中執行，且隨後之片段將幾乎即刻載入。
但是，除此等優點之外，使用者將能夠檢視他人玩遊戲(經由先前所描述之遊戲取景器，及其他構件)，且兩者均決定遊戲是否有趣，且若如此，則自觀看他人而學習技巧。此外，使用者將能夠即刻地演示該遊戲，而不必等待大的下載及/或安裝，且使用者將能夠即刻玩該遊戲(可能在較小費用之試用基礎上，或在較長期基礎上)。此外，使用者將能夠藉由足夠低延時之無線連接而在Windows PC、Macintosh上、在電視機上、在家裏、在行進時且甚至在行動電話上玩該遊戲。此外，此均可在並非曾經實體擁有遊戲複本的情況下完成。
如先前所敍述，使用者可決定不允許其遊戲播放可被他人檢視，允許其遊戲可在延遲之後檢視，允許其遊戲可被選定使用者檢視，或允許其遊戲可被所有使用者檢視。不管怎樣，在一實施例中，將視訊/音訊儲存於延遲緩衝器1515中歷時15分鐘，且使用者將能夠「回倒」並檢視其先前的遊戲播放，且將遊戲暫停，將遊戲緩慢地回放，將遊戲快進等，正如其在觀看具有數位視訊記錄器(DVR)之TV時所能夠進行的。儘管在此實例中，使用者係在玩遊戲，但若使用者正使用應用程式，則相同「DVR」能力係可用的。此在核查先前工作中及在如下詳述之其他應用中可係有用的。另外，若遊戲經設計為具有基於利用遊戲狀態資訊而回倒之能力，以便可改變相機視圖等，則亦將支援此「3D DVR」能力，但其將需要將遊戲設計為支援「3D DVR」能力。使用延遲緩衝器1515之「DVR」能力將連同任何遊戲或應用程式(當然，限於在使用遊戲或應用程式時所產生的視訊)一起起作用，但在具有3D DVR能力之遊戲的狀況下，使用者可控制先前所播放之片段的3D「穿越」，且使延遲緩衝器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中之一者上(或若其需要大量計算能力，則在若干者上)執行。處於全異位置處之3個使用者中之每一者將連接至主機代管服務210，且每一者將具有對建築設計應用程式之視訊輸出的同時檢視，但其將被針對每一使用者具有的給定器件及網路連接特性而由共用硬體壓縮1530適當地定大小(例如，建築公司可經由20Mbps商用網際網路連接看見2560×1440 60 fps顯示，紐約之房地產開發商可經由其膝上型電腦上之6Mbps DSL連接看見1280×720 60 fps影像，且投資者可經由其行動電話上之250Kbps蜂巢式資料連接看見320×180 60 fps影像)。每一方將聽到其他方之語音(將藉由應用程式/遊戲伺服器1521-1525中的許多廣泛可用之會議呼叫套裝軟體中之任一者來處理會議呼叫)，且經由使用者輸入器件上之按鈕之致動，使用者將能夠使用其本端相機使視訊出現。隨著會議進行，建築師將能夠藉由極具照片般逼真感之3D再現展示當其使建築物旋轉且使其鄰接該區域中之另一建築物穿越時建築物看起來像什麼，且所有方均將在各方之顯示器件之解析度下可見到相同視訊。由任何方使用之本端器件中之任一者均能夠以該真實感處理3D動畫不係問題，更不用說下載或甚至儲存再現紐約市之周圍建築物所需的巨大資料庫。自使用者中之每一者的觀點看，儘管距離很遠，且儘管係全異本端器件，但其將簡單地在難以置信之真實感程度下具有無縫體驗。此外，當一方希望其面部被看來較佳地傳達其情緒狀態時，其可如此進行。另外，若房地產開發商或投資者希望控制建築程式且使用其自身的輸入器件(其為鍵盤、滑鼠、小鍵盤或觸摸螢幕)，則其可如此，且其可以無感知的延時來回應(假定其網路連接不具有不合理的延時)。舉例而言，在行動電話之狀況下，若行動電話連接至機場之WiFi網路，則其將具有非常低之延時。但若其使用美國現今可用之蜂巢式資料網路，則其很可能將遭受引人注意的滯後。但是，對於會議之大多數目的(其中投資者正觀看建築師控制建築物穿越或正談論視訊電話會議)，甚至蜂巢式延時亦應係可接受的。
最後，在合作性會議呼叫結束時，房地產開發商及投資者將進行其評論且自主機代管服務停播，建築公司將能夠「回倒」已記錄於延遲緩衝器1515上之會議的視訊且核查在會議期間進行的應用於建築物之3D模型的評論、面部表情及/或動作。若存在其希望保存之特定片段，則可將視訊/音訊之彼等片段自延遲緩衝器1515移動至RAID陣列1511-1512以用於檔案儲存及稍後回放。
又，自成本觀點看，若建築師僅需要使用紐約市之計算能力及大資料庫歷時15分鐘之會議呼叫，則其僅需要支付該等資源被使用之時間的費用，而不必擁有高能力之工作台且不必購買大資料庫之昂貴複本。
視訊豐富之社區服務
主機代管服務210致能用於在網際網路上建立視訊豐富之社區服務的空前機會。圖20展示用於主機代管服務210上之遊戲玩家的例示性使用者頁面。如同遊戲取景器應用程式一樣，使用者頁面為在應用程式/遊戲伺服器1521-1525中之一者上執行的應用程式。此頁面上之所有縮略圖及視訊窗展示恆定地移動的視訊(若片段短，則其循環)。
使用視訊相機或藉由上載視訊，使用者(其用戶名為「KILLHAZARD」)能夠公布其本身之視訊2000(其他使用者可檢視該視訊)。該視訊儲存於RAID陣列1511-1512上。又，當其他使用者來到KILLHAZARD之使用者頁面時，若KILLHAZARD此時正使用主機代管服務210，則將展示其正進行的無論什麼的現場直播之視訊2001(假定其准許檢視其使用者頁面之使用者觀看其)。此將由主機代管使用者頁面應用程式之應用程式/遊戲伺服器1521-1525自服務控制系統401請求KILLHAZARD是否為活躍的(且若如此，則請求其正使用的應用程式/遊戲伺服器1521-1525)來完成。接著，使用由遊戲取景器應用程式使用之相同方法，將合適解析度及格式的經壓縮視訊流發送至執行使用者頁面應用程式之應用程式/遊戲伺服器1521-1525且將其顯示。若使用者選擇具有KILLHAZARD之現場直播之遊戲播放的窗口且接著適當地單擊其輸入器件，則該窗口將放大(再次使用與遊戲取景器應用程式相同之方法)，且現場直播之視訊將以觀看使用者之顯示器件422的解析度(適合於觀看使用者之網際網路連接的特性)填充螢幕。
此優於先前技術方法之關鍵優點係：檢視使用者頁面之使用者能夠看見使用者不擁有的現場直播地播放的遊戲，且可不具有能夠玩該遊戲之本端電腦或遊戲控制台。其為使用者提供看使用者頁面中展示為「活動中」的使用者玩遊戲之極好機會，且其為瞭解檢視使用者可能希望嘗試或較擅長之遊戲的機會。
來自KILLHAZARD之搭檔2002之相機記錄的或上載的視訊剪輯亦展示於使用者頁面上，且每一視訊剪輯之下方為指示該搭檔是否線上玩遊戲之文字(例如，six_shot正玩遊戲「龍騎士(Eragon)」且MrSnuggles99離線等)。藉由單擊選單項(未圖示)，搭檔視訊剪輯自展示已記錄的或上載的視訊切換至當前正玩主機代管服務210上之遊戲之搭檔在彼時刻在其遊戲中正在進行的內容的現場直播之視訊。因此，其變成為搭檔分群的遊戲取景器。若選擇搭檔之遊戲且使用者單擊該遊戲，則該遊戲將放大至全螢幕，且使用者將能夠觀看全螢幕現場直播地播放的遊戲。
再次，檢視搭檔之遊戲之使用者不擁有遊戲之複本，亦不擁有用於玩該遊戲之本端計算/遊戲控制台資源。遊戲檢視係有效瞬時的。
如上文先前所描述，當使用者玩主機代管服務210上之遊戲時，使用者能夠「回倒」遊戲且發現其希望保存之視訊片段，且接著將該視訊片段保存至其使用者頁面。此等被稱為「自賞剪輯(Brag Clip)」。視訊片段2003均為由KILLHAZARD自其所玩的先前遊戲保存的自賞剪輯2003。數字2004展示自賞剪輯已被檢視多少次，及自賞剪輯何時被檢視，使用者具有對其評定等級之機會，且橙色鑰匙孔形狀的圖示2005之數目指示等級係多高。當使用者檢視使用者頁面時，自賞剪輯2003連同頁面上之其餘視訊一起恆定地循環。若使用者選擇並單擊自賞剪輯2003中之一者，則其放大以呈現自賞剪輯2003，以及允許播放、暫停、回倒、快進、步進等該剪輯之DVR控制。
自賞剪輯2003回放係藉由應用程式/遊戲伺服器1521-1525載入使用者記錄自賞剪輯時儲存於RAID陣列1511-1512上的經壓縮視訊片段且將其解壓縮並將其回放來實施。
自賞剪輯2003亦可為來自支援3D DVR能力之遊戲的「3D DVR」視訊片段(亦即，來自可被重放且允許使用者改變相機檢視點之遊戲的遊戲狀態序列)。在此狀況下，除使用者在記錄遊戲片段時進行的特定「穿越」的經壓縮視訊記錄之外，亦儲存遊戲狀態資訊。當使用者頁面正被檢視且所有縮略圖及視訊窗均恆定地循環時，3D DVR自賞剪輯2003將使在使用者記錄遊戲片段之「穿越」時記錄為經壓縮視訊的自賞剪輯2003恆定地循環。但是，當使用者選擇3D DVR自賞剪輯2003並單擊3D DVR自賞剪輯2003時，除允許播放經壓縮視訊自賞剪輯的DVR控制之外，使用者將能夠單擊給出其用於遊戲片段之3D DVR能力的按鈕。其將能夠獨立地控制遊戲片段期間的相機「穿越」，且若其希望(且擁有使用者頁面的使用者如此允許)，則其將能夠以經壓縮視訊之形式記錄替代性自賞剪輯「穿越」，替代性自賞剪輯「穿越」將接著可為使用者頁面之其他檢視者所用(立即地，或者在使用者頁面之擁有者具有核查自賞剪輯之機會之後)。
此3DDVR自賞剪輯2003能力係藉由啟動將要在另一應用程式/遊戲伺服器1521-1525上重放已記錄之遊戲狀態資訊的遊戲來啟用。因為遊戲可被幾乎瞬時地啟動(如先前所描述)，所以啟動其(其播放限於由自賞剪輯片段記錄之遊戲狀態)且接著允許使用者在將經壓縮視訊記錄至延遲緩衝器1515的同時用相機進行「穿越」並不困難。一旦使用者完成進行「穿越」，則將遊戲撤銷啟動。
自使用者之觀點看，啟動具有3D DVR自賞剪輯2003之「穿越」並不比控制線性自賞剪輯2003之DVR控制難。其可不知道該遊戲或甚至不知道如何玩該遊戲。其僅為盯著看另一操作者記錄的遊戲片段期間之3D世界的虛擬相機操作者。
使用者將亦能夠將其自身的音訊加錄於自賞剪輯上(或者自麥克風記錄或者上載)。以此方式，可使用自賞剪輯來使用來自遊戲之人物及動作產生定製動畫。此動畫製作技術通常被稱為「遊戲電影(machinima)」。
隨著使用者在遊戲中進展，其將達成不同技能級別。所播放之遊戲將成果報告給服務控制系統401，且此等技能級別亦將展示於使用者頁面上。
互動式動畫廣告
線上廣告已自文字轉變至靜態影像、視訊、且現在轉變至互動式片段，通常係使用如Adobe Flash之動畫精簡型用戶端來實施。使用動畫精簡型用戶端之原因在於：使用者通常對於因向其推銷產品或服務之特權而被延遲較無耐心。又，精簡型用戶端在非常低效能之PC上執行，且因此廣告商可具有高度信心：互動式廣告將適當地工作。遺憾地，諸如Adobe Flash之動畫精簡型用戶端在互動性之程度及體驗(以減少下載時間)之持續時間上受限制。
圖21說明一互動式廣告，其中使用者將在汽車在陳列室中旋轉時選擇汽車之外部及內部色彩，同時即時射線追蹤展示汽車看起來如何。接著使用者選擇化身來駕駛汽車，且接著使用者可採用該汽車來用於在競賽軌道上或者穿過諸如Monaco之外國場所駕駛。使用者可選擇較大引擎或較佳輪胎，且接著可看見改變的組態如何影響汽車加速或保持穩定之能力。
當然，廣告有效地的為尖端的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展示使用ContourTM 真實性俘獲技術(以下同在申請中之申請案的主題：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 the ezpression of a performer」；2005年2月25日申請之第11/066,954號「Apparatus and method for improving marker identification within a motion capture system」；2005年3月10日申請之第11/077,628號「Apparatus and method for performing motion capture using shutter synchronization」；2005年10月20日申請之第11/255,854號「Apparatus and method for performing motion capture using a random pattern on capture surfaces」；2006年6月7日申請之第11/449,131號「System and method for performing motion capture using phosphor application techniques」；2006年6月7日申請之第11/449,043號「System and method for performing motion capture by strobing a fluorescent lamp」；2006年6月7日申請之第1/449,127號「System and method for three dimensional capture of stop-motion animated characters」，該等申請案中之每一者已讓於給本CIP申請案之受讓人)俘獲的現場直播之表演如何導致非常平滑之俘獲表面，既而達成高多邊形計數的追蹤表面(亦即，多邊形運動精確地追隨面部之運動)。最後，當將現場直播之表演之視訊映射於追蹤表面上以產生紋理表面時，產生照片般逼真的結果。
儘管當前GPU技術能夠再現追蹤表面及紋理中的許多多邊形且即時地照明該表面，但若多邊形及紋理每一圖框時間改變(其將產生最具照片般逼真感之結果)，則其將迅速地消耗現代PC或視訊遊戲控制台之所有可用RAM。
使用上文所描述之串流幾何形狀技術，將幾何形狀不斷地饋送至應用程式/遊戲伺服器1521-1525中以使得其可不斷地動畫製作照片般逼真的面部從而允許產生具有幾乎不能區別於現場直播之動作面部之面部的視訊遊戲變得實際。
線性內容與互動式特徵之整合
電影、電視節目及音訊材料(統稱「線性內容」)廣泛地以許多形式可用於家庭及辦公室使用者。線性內容可在如CD、DVD、HD-DVD及藍光媒體之實體媒體上獲取。其亦可藉由來自衛星及電纜TV廣播之DVR來記錄。此外，其可以經由衛星及電纜TV之即付即看(PPV)內容及以電纜TV上之視訊點播(VOD)可用。
日益增加的線性內容可經由網際網路以下載的內容及串流內容可用。現今，確實不存在一能體驗與線性媒體相關聯之所有特徵的位置。舉例而言，DVD及其他視訊光學媒體通常具有在其他位置處不可用之互動式特徵(如導演之評論、「花絮」短片等)。線上音樂站點具有通常在CD上不可用之封面藝術及歌曲資訊，但並非所有CD線上可用。且與電視節目相關聯之網站常常具有額外特徵、網志(blog)及有時來自演員或創作人員之評論。
另外，在許多電影或運動事件之情況下，常常存在常常連同線性媒體一起發行(在電影之狀況下)或(在運動之狀況下)可緊密地聯繫至真實世界事件(例如，玩家之交易)的視訊遊戲。
主機代管服務210非常適合於在將全異形式之相關內容連結在一起時遞送線性內容。的確，遞送電影電影不如遞送高度互動式視訊遊戲有挑戰，且主機代管服務210能夠將線性內容遞送至家庭或辦公室中的多種器件，或遞送至行動器件。圖23展示用於主機代管服務210之例示性使用者介面頁面，其展示線性內容之選擇。
但是，不同於大多數線性內容遞送系統，主機代管服務210亦能夠遞送相關的互動式成份(例如，DVD上之選單及特徵、HD-DVD上之互動式上覆，及網站上之Adobe Flash動畫(如下文所說明))。因此，用戶端器件415限制不再引入關於哪些特徵可用之限制。
另外，主機代管系統210能夠動態且即時地將線性內容與視訊遊戲內容連結在一起。舉例而言，若使用者正觀看哈利波特電影中之Quidditch比賽，且決定其願意嘗試玩Quidditch，則其可僅僅單擊按鈕且電影將暫停且其將被立即輸送至哈利波特視訊遊戲之Quidditch片段。在玩Quidditch比賽之後，另一次單擊按鈕，且電影將即刻重新開始。
在照片般逼真的圖形及製作技術之情況下，其中攝影俘獲的視訊不能區別於現場直播之動作人物，當使用者進行自現場直播之動作電影中之Quidditch遊戲至主機代管服務上之視訊遊戲中之Quidditch遊戲的轉變時(如本文中所描述)，該兩個場景實際上不能區別。此為線性內容與互動式(例如，視訊遊戲)內容兩者之導演提供全新的創作選項，因為該兩個世界之間的線變得不能區別。
利用圖14中所展示之主機代管服務架構，可將3D電影中之虛擬相機之控制提供給檢視者。舉例而言，在發生於列車內之場景中，將有可能允許檢視者在故事進展時控制虛擬相機且環顧列車。此假定列車中之所有3D物件(「資產」)以及能夠即時地再現該等場景以及原始電影的足夠計算能力位準可用。
且甚至對於非電腦產生之娛樂，存在可提供的非常刺激之互動式特徵。舉例而言，2005電影「傲慢與偏見」具有裝飾華麗的舊英國大廈中之許多場景。對於特定大廈場景，使用者可將視訊暫停且接著控制相機以巡視大廈，或可能的周圍區域。為實施此，可載運具有魚眼透鏡之相機穿過大廈，當其追蹤其位置時，非常類似於實施先前技術Apple公司之QuickTime VR。各種圖框接著將被轉換，因此影像不失真，且接著其連同電影一起被儲存於RAID陣列1511-1512上，且在使用者選擇繼續虛擬巡視時被回放。
在運動事件之情況下，可經由主機代管服務210來串流現場直播之運動事件(諸如，籃球比賽)以供使用者觀看(如同其對於常見TV所想要的那樣)。在使用者觀看特定播放之後，遊戲之視訊遊戲(最終籃球玩家看起來與真實玩家一般照片般逼真)可趕上在同一位置中開始的玩家，且使用者(可能各自控制一玩家)可重新玩以查看其是否可比該等玩家做得更佳。
本文中所描述之主機代管服務210極其適合於支援此未來世界，因為其能夠承受不切實際以致不能安裝於家庭中或大多數辦公室背景中的計算能力及大容量儲存資源，而且其計算資源總是最新的(在可用的最新的計算硬體之情況下)，但是在家庭背景中，將總是存在具有較舊代之PC及視訊遊戲的家庭。此外，在主機代管服務210中，使用者被隱瞞所有此計算複雜度，因此，即使使用者可能正使用非常尖端之系統，自使用者之觀點看，亦如改變電視上之頻道一般簡單。另外，使用者將能夠存取所有計算能力及計算能力將自任何用戶端415帶來的體驗。
多人遊戲
至遊戲為多人遊戲之程度，則其將能夠不僅經由入埠路由1502網路傳達至應用程式/遊戲伺服器1521-1525而且藉由網路橋接器傳達至具有不在主機代管服務210中執行之伺服器或遊戲機器的網際網路(未圖示)。當藉由通用網際網路上之電腦玩多人遊戲時，則應用程式/遊戲伺服器1521-1525將具有極快存取網際網路之益處(與遊戲係在家庭中之伺服器上執行的情況相比)，但其將受在較緩慢連接上玩遊戲之其他電腦的能力限制，且亦潛在地受網際網路上之遊戲伺服器經設計以適應最少共同點(該等遊戲伺服器將為相對緩慢之消費者網際網路連接上的家庭電腦)的事實限制。
但當完全在主機代管服務210伺服器中心內玩多人遊戲時，則可達成極大差異。主機代管用於使用者之遊戲之每一應用程式/遊戲伺服器1521-1525將與其他應用程式/遊戲伺服器1521-1525以及藉由極高速度、極低延時連接性及巨大、非常快之儲存陣列主機代管對多人遊戲之中央控制的任何伺服器互連。舉例而言，若超高速乙太網路用於入埠路由1502網路，則應用程式/遊戲伺服器1521-1525將在彼此當中傳達，且傳達至以十億位元/秒速度在潛在的僅1毫秒或1毫秒以下之延時下主機代管對多人遊戲之中央控制的任何伺服器。另外，RAID陣列1511-1512將能夠非常快速地回應且接著以十億位元/秒速度傳送資料。作為一實例，若使用者在外表及服裝方面定製人物，以使得人物具有對於人物而言唯一的大量幾何形狀及行為，在限於在家庭中在PC或遊戲控制台上執行之遊戲用戶端的先前技術系統下，若彼人物將進入另一使用者之視野中，則使用者將必須等待直至長的緩慢下載完成為止，以便將所有幾何形狀及行為資料載入其電腦中。在主機代管服務210內，彼相同下載可優於以十億位元/秒速度自RAID陣列1511-1512伺服的超高速乙太網路。即使家庭使用者具有8Mbps網際網路連接(其根據現今之標準來看極快)，超高速乙太網路亦快100倍。因此，在快的網際網路連接上花費一分鐘進行的工作在超高速乙太網路上將花費小於一秒。
頂級玩家分群及錦標賽
主機代管服務210極其適合於錦標賽。因為無遊戲係在本端用戶端中執行，所以不存在使用者作弊之機會。又，由於輸出路由1540多播UDP流之能力，使得主機代管服務210能夠同時向觀眾中的數千人廣播較大錦標賽。
事實上，當存在如此風行以致數千名使用者正接收相同流的特定視訊流時(例如，展示較大錦標賽之視圖)，將視訊流發送至內容遞送網路(CDN)(諸如，Akamai或Limelight)以供至大量分配至許多用戶端器件415可能更有效。
當使用CDN來展示頂級玩家分群之遊戲取景器頁面時，可獲得類似位準之效率。
對於較大錦標賽，可使用現場直播的名人解說員來在特定比賽期間提供評論。儘管大量使用者將係在觀看較大錦標賽，且相對小數目將係在錦標賽中玩。可將來自名人解說員之音訊路由至主機代管在錦標賽中玩之使用者且主機代管錦標賽中之遊戲之任何旁觀者模式複本的應用程式/遊戲伺服器1521-1525，且可將音訊加錄於遊戲音訊之上。可在遊戲上(亦可能剛好在旁觀者視圖上)上覆名人解說員之視訊。
網頁載入之加速
全球資訊網之主要輸送協定、超文字傳送協定(HTTP)係經構想並界定於一其中僅商業具有高速網際網路連接，且線上之消費者使用撥號數據機或ISDN的時代中。此時，用於快速連接之「黃金標準」為T1線，其對稱地提供1.5Mbps資料速率(亦即，兩個方向中具有相等資料速率)。
現今，情形完全不同。大量發達世界中經由DSL或電纜數據機連接之平均家庭連接速度具有比T1線高得多的下行資料速率。事實上，在世界之一些地方中，光纖至路邊(fiber-to-the-curb)正將高達50Mbps至100Mbps之資料速率引入家庭。
遺憾地，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-100Mbps連接，但大多數家庭仍具有較緩慢之速度，且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娛樂「活躍遊戲者基準點研究」(http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/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個峰值小時。由於以下許多原因而使得難以估計系統上之確切峰值使用者負載：一些使用者將在峰值外時間期間玩，可能存在特定日間時間存在使用者之叢集峰值，峰值時間可受所玩遊戲之類型(例如，孩子之遊戲將可能係在晚上的較早時間玩)等影響。但是，假定當遊戲者可能玩遊戲時，遊戲者玩的平均小時數遠小於日間之小時數，則僅主機代管服務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中之遊戲或應用程式之所有複本)。實際上，在使用者開始使用主機代管服務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所提供的為串流互動式視訊位準下之遞歸，因為可在應用程式需要視訊時將視訊無限地循環。此致能之前從未可用的多種應用可能性。
另一關鍵架構特徵在於：視訊流係單向UDP流。此有效地致能串流互動式視訊之任意程度的多播(相比之下，諸如TCP/IP流之雙向流將隨著使用者之數目增加而在來自來回通信之網路上產生愈加更多的訊務停滯)。多播係伺服器中心內之重要能力，因為其允許系統對網際網路使用者(且實際上，世界之人口)之增長的需要作出回應以在一對多或甚至多對多基礎上通信。再次，本文中所論述的說明串流互動式視訊遞歸與多播兩者之使用的實例(諸如，圖16)僅為具有可能性之非常大之冰山的尖端。
在一實施例中，本文中所說明之各種功能模組及相關聯之步驟可由含有用於執行該等步驟之固線式邏輯的特定硬體組件(諸如，特殊應用積體電路(「ASIC」))或由經程式化之電腦組件與定製硬體組件之任何組合來執行。
在一實施例中，可將該等模組實施於諸如Texas儀器的TMS320x架構(例如，TMS320C6000、TMS320C5000，…等)之可程式化數位信號處理器(「DSP」)上。可使用各種不同的DSP，同時仍遵守此等基本原理。
實施例可包括如上文所闡述之各種步驟。該等步驟可體現於引起通用或專用處理器執行特定步驟之機器可執行指令中。已將與此等基本原理無關之各種元件(諸如，電腦記憶體、硬碟機、輸入器件)自圖中省去以避免混淆相關態樣。
所揭示之標的物之要素亦可作為用於儲存機器可執行指令之機器可讀媒體來提供。機器可讀媒體可包括(但不限於)快閃記憶體、光碟、CD-ROM、DVD ROM、RAM、EPROM、EEPROM、磁卡或光卡、傳播媒體或適合於儲存電子指令之其他類型之機器可讀媒體。舉例而言，本發明可作為電腦程式來下載，該電腦程式可經由通信鏈路(例如，數據機或網路連接)藉助於體現於載波或其他傳播媒體中之資料信號而自遠端電腦(例如，伺服器)傳送至請求電腦(例如，用戶端)。
亦應理解，所揭示之標的物之要素亦可作為電腦程式產品來提供，該電腦程式產品可包括在上面儲存有指令之機器可讀媒體，該等指令可用於程式化電腦(例如，處理器或其他電子器件)以執行一序列操作。或者，該等操作可藉由硬體與軟體之組合來執行。機器可讀媒體可包括(但不限於)軟性磁碟、光碟、CD-ROM，及磁光碟、ROM、RAM、EPROM、EEPROM、磁卡或光卡、傳播媒體或適合於儲存電子指令之其他類型之媒體/機器可讀媒體。舉例而言，所揭示之標的物之要素可作為電腦程式產品來下載，其中程式可經由通信鏈路(例如，數據機或網路連接)藉助於體現於載波或其他傳播媒體中之資料信號而自遠端電腦或電子器件傳送至請求過程。
另外，儘管已結合特定實施例描述所揭示之標的物，但眾多修改及變更將適當地處於本揭示案之範疇內。因此，說明書及圖式應視為說明性的而非限制性的意義。
100．．．CPU/GPU
101．．．隨機存取記憶體(RAM)
102．．．顯示器件(SDTV/HDTV或電腦監視器)
103．．．硬碟機
104．．．光學媒體驅動器/光學媒體/光碟機
105．．．網路連接
106．．．遊戲控制器
205．．．用戶端器件/用戶端/用戶端平台
206．．．網際網路
210．．．主機代管服務/主機代管系統
211．．．使用者場所
220．．．遊戲或應用程式軟體開發商
221．．．輸入器件
222．．．顯示器件/監視器或電視機
301．．．標稱最大資料速率
302．．．可用最大資料速率
303．．．所需的資料速率
401．．．主機代管服務控制系統/主機代管服務控制伺服器
402．．．伺服器
403．．．儲存區域網路(SAN)
404．．．視訊壓縮邏輯/視訊壓縮器
405．．．獨立冗餘磁碟陣列(RAID)
406．．．控制信號
406a．．．控制信號
406b．．．控制信號
409．．．路由邏輯
410．．．網際網路
412．．．低延時視訊解壓縮邏輯
413．．．控制信號邏輯
415．．．用戶端/用戶端器件/用戶端電腦
420．．．顯示器件
421．．．輸入器件
422．．．顯示器件/顯示器
440．．．網際網路繞過服務
441．．．存在點
442．．．WAN介面
443．．．防火牆/路由器/NAT(網路位址轉譯)器件
444．．．WAN介面
451．．．用於發送控制信號之單向傳輸時間
452．．．經由使用者場所之來回行程路由/使用者場所路由
453．．．箭頭/來回行程延遲/使用者ISP
454．．．通用網際網路延時
455．．．單向路由
456．．．最大單向延時
457．．．箭頭/壓縮
458．．．視訊解壓縮
462．．．乙太網路插孔/網際網路連接
463．．．HDMI(高清晰度多媒體介面)、連接器
464．．．顯示能力
465．．．用戶端器件/用戶端
466．．．遮光眼鏡
468．．．顯示器件/SDTV(標準清晰度電視)或HDTV(高清晰度電視)/監視器
469．．．輸入器件
475．．．用戶端器件
476．．．快閃記憶體
477．．．視訊相機
478．．．顯示器件
479．．．藍芽輸入器件/有線USB輸入器件
480．．．匯流排
481．．．乙太網路介面
482．．．WiFi子系統
483．．．控制CPU/控制處理器
484．．．藍芽介面
485．．．USB子系統
486．．．視訊解壓縮器
487．．．視訊輸出子系統
488．．．音訊解壓縮子系統
489．．．音訊輸出子系統
490．．．HDMI介面
491．．．DVI-I
492．．．S-視訊
493．．．複合視訊
494．．．數位介面
495．．．立體類比介面
497．．．乙太網路
499．．．電力
501．．．未經壓縮之視訊圖框
502．．．未經壓縮之視訊圖框
503．．．未經壓縮之視訊圖框
511．．．經壓縮之圖框
512．．．經壓縮之圖框
513．．．經壓縮之圖框
520．．．壓縮邏輯
559-561．．．未經壓縮之視訊圖框
611．．．I圖框
612-613．．．P圖框
620．．．壓縮邏輯
621．．．額定最大資料速率
622．．．可用最大資料速率/可用資料速率
623．．．I圖框所需之峰值資料速率/峰值資料速率
624．．．視訊流資料速率/視訊流資料速率序列
633．．．I圖框峰值
634．．．視訊流資料速率序列/視訊流資料速率
635．．．P圖框峰值
636．．．P圖框峰值
670．．．B圖框
671．．．I圖框
701-760．．．未經壓縮之圖框
711-770．．．R圖框
721-770．．．未經壓縮之圖框
731-780．．．R圖框
805．．．移動人物
811．．．R圖框
812．．．R圖框
922．．．可用最大資料速率
934．．．視訊流資料速率
941．．．峰值資料速率/峰值最大資料速率
942．．．2倍峰值資料速率
943．．．3倍峰值資料速率
944．．．4倍峰值資料速率
952．．．圖框2倍峰值
953．．．平坦化的2倍峰值
954．．．圖框4倍峰值
955．．．平坦化的4倍峰值
961．．．未經壓縮之圖框1
962．．．未經壓縮之圖框2
963．．．未經壓縮之圖框3
964．．．未經壓縮之圖框4
965．．．未經壓縮之圖框5
966．．．未經壓縮之圖框6
967．．．未經壓縮之圖框7
968．．．未經壓縮之圖框8
969．．．未經壓縮之圖框9
970．．．未經壓縮之圖框10
981．．．經壓縮之圖框1
982．．．經壓縮之圖框2
983．．．經壓縮之圖框3
985．．．經壓縮之圖框5
986．．．經壓縮之圖框6
987．．．經壓縮之圖框10
991．．．傳輸時間(xmit時間)
992．．．傳輸時間
993．．．傳輸時間(2倍峰值)
995．．．傳輸時間
996．．．傳輸時間(4倍峰值)
997．．．傳輸時間
1001-1005．．．封包
1010．．．影像塊包裝封裝邏輯
1100．．．I影像塊
1101．．．前向錯誤校正碼(FEC)
1103．．．I影像塊
1104．．．前向錯誤校正碼(FEC)
1105．．．前向錯誤校正碼(FEC)
1110．．．音訊封包
1111．．．FEC碼
1112．．．音訊封包
1113．．．FEC碼
1120．．．使用者輸入命令
1121．．．FEC碼
1122．．．使用者輸入命令
1123．．．FEC碼
1200．．．多核及/或多處理器
1201-1208．．．核心
1205．．．4×2配置/未經壓縮之圖框
1300．．．伺服器中心/主機代管服務
1301．．．網路
1501．．．入埠網際網路訊務
1502．．．入埠路由/入埠路由網路
1511．．．RAID陣列
1512．．．RAID陣列
1515．．．RAID陣列/延遲緩衝器
1521-1525．．．應用程式/遊戲伺服器
1529．．．未經壓縮之視訊/音訊
1530．．．共用視訊壓縮/共用集區/共用硬體壓縮/共用硬體壓縮器/共用視訊壓縮硬體
1539．．．經壓縮視訊/音訊輸出
1540．．．出埠路由/出埠路由網路
1550．．．延遲緩衝器及/或分群視訊/反饋迴路
1551．．．路徑
1552．．．路徑
1599．．．出埠網際網路訊務
1600．．．「縮略圖」視訊窗
1601．．．黃色選擇框
1602．．．遊戲資訊
1700．．．視訊窗
1800．．．箭頭
1801．．．上覆
1900．．．視訊及音訊
2000．．．使用者本身之視訊
2001．．．現場直播之視訊
2002．．．搭檔
2003．．．視訊片段/自賞剪輯/3D DVR自賞剪輯
2004．．．數字
2005．．．圖示
2400．．．線
2401．．．1.5Mbps連接速度
2402．．．12Mbps連接速度
2403．．．96Mbps連接速度
HS1-HS6．．．主機代管服務伺服器中心
圖1說明先前技術視訊遊戲系統之架構。
圖2a至圖2b說明根據一實施例之高階系統架構。
圖3說明用於用戶端與伺服器之間的通信的實際的、額定的及所需的資料速率。
圖4a說明根據一實施例而使用的主機代管服務及用戶端。
圖4b說明與用戶端與主機代管服務之間的通信相關聯的例示性延時。
圖4c說明根據一實施例之用戶端器件。
圖4d說明根據另一實施例之用戶端器件。
圖4e說明圖4c中之用戶端器件的實例方塊圖。
圖4f說明圖4d中之用戶端器件的實例方塊圖。
圖5說明可根據一實施例而使用的視訊壓縮之一實例形式。
圖6a說明可在另一實施例中使用的視訊壓縮之一實例形式。
圖6b說明與傳輸低複雜度、低動作視訊序列相關聯的資料速率中之峰值。
圖6c說明與傳輸高複雜度、高動作視訊序列相關聯的資料速率中之峰值。
圖7a至圖7b說明在一實施例中使用之實例視訊壓縮技術。
圖8說明在一實施例中使用之額外實例視訊壓縮技術。
圖9a至圖9c說明在一實施例中使用以用於緩解資料速率峰值的實例技術。
圖10a至圖10b說明將影像影像塊有效地封裝於封包內的一實施例。
圖11a至圖11d說明使用前向錯誤校正技術之實施例。
圖12說明使用多核心處理單元來進行壓縮之一實施例。
圖13a至圖13b說明根據各種實施例之主機代管服務之間的地理定位及通信。
圖14說明與用戶端與主機代管服務之間的通信相關聯的例示性延時。
圖15說明實例主機代管服務伺服器中心架構。
圖16說明包括複數個現場直播之視訊窗的使用者介面之一實施例的實例螢幕拍攝。
圖17說明在選擇特定視訊窗之後的圖16之使用者介面。
圖18說明在將特定視訊窗放大至全螢幕大小之後的圖17之使用者介面。
圖19說明上覆於多人遊戲之螢幕上的實例合作使用者視訊資料。
圖20說明用於主機代管服務上的一遊戲玩家之實例使用者頁面。
圖21說明實例3D互動式廣告。
圖22說明用於自現場直播之表演的表面俘獲產生具有紋理表面之照片般逼真的影像的實例步驟序列。
圖23說明允許選擇線性媒體內容之實例使用者介面頁面。
圖24為說明在現場直播網頁之前消逝的時間量與連接速度之曲線圖。
205．．．用戶端器件/用戶端/用戶端平台
206．．．網際網路
210．．．主機代管服務/主機代管系統
211．．．使用者場所
220．．．遊戲或應用軟體開發商
221．．．輸入器件
222．．．顯示器件/監視器或電視機

Claims (3)

  1. 一種電腦實施方法，其包含：將用於執行一線上應用程式之程式碼及/或資料再分成一第一類型及一第二類型；將該第一類型之程式碼及資料儲存於一第一類型之記憶體中，該第一類型之記憶體提供相對低延時之記憶體存取；將該第二類型之程式碼及資料儲存於一第二類型之記憶體中，與該第一類型之記憶體相比，該第二類型之記憶體提供相對較高延時之記憶體存取；回應於一用於執行一線上應用程式之用戶端請求而自該第一記憶體及該第二記憶體擷取程式碼及資料；及將表示由該應用程式產生之影像的一串流互動式視訊流傳輸至該用戶端。
  2. 如請求項1之方法，其中該第一類型之記憶體為快閃記憶體，且該第二類型之記憶體為一硬碟機。
  3. 如請求項1之方法，其中該應用程式為一視訊遊戲。
TW097147248A 2007-12-05 2008-12-04 用於將程式碼及資料儲存於應用程式主機代管中心內之系統及方法 TWI459215B (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US99965807A 2007-12-05 2007-12-05

Publications (2)

Publication Number Publication Date
TW200937220A TW200937220A (en) 2009-09-01
TWI459215B true TWI459215B (zh) 2014-11-01

Family

ID=40718184

Family Applications (2)

Application Number Title Priority Date Filing Date
TW98114137A TW200943078A (en) 2007-12-05 2008-12-04 Method for acceleration of web page delivery
TW097147248A TWI459215B (zh) 2007-12-05 2008-12-04 用於將程式碼及資料儲存於應用程式主機代管中心內之系統及方法

Family Applications Before (1)

Application Number Title Priority Date Filing Date
TW98114137A TW200943078A (en) 2007-12-05 2008-12-04 Method for acceleration of web page delivery

Country Status (10)

Country Link
EP (1) EP2232375A4 (zh)
JP (1) JP2011507347A (zh)
KR (1) KR20100113503A (zh)
CN (1) CN101918924A (zh)
AU (1) AU2008333828B2 (zh)
CA (1) CA2707704A1 (zh)
NZ (1) NZ585909A (zh)
RU (1) RU2497184C2 (zh)
TW (2) TW200943078A (zh)
WO (1) WO2009073826A1 (zh)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8888592B1 (en) 2009-06-01 2014-11-18 Sony Computer Entertainment America Llc Voice overlay
US8613673B2 (en) 2008-12-15 2013-12-24 Sony Computer Entertainment America Llc Intelligent game loading
US8147339B1 (en) 2007-12-15 2012-04-03 Gaikai Inc. Systems and methods of serving game video
US8968087B1 (en) 2009-06-01 2015-03-03 Sony Computer Entertainment America Llc Video game overlay
US8926435B2 (en) 2008-12-15 2015-01-06 Sony Computer Entertainment America Llc Dual-mode program execution
US8506402B2 (en) 2009-06-01 2013-08-13 Sony Computer Entertainment America Llc Game execution environments
JP5605673B2 (ja) * 2009-10-01 2014-10-15 日本電気株式会社 デジタルデータ共有サービス端末、方法、プログラム、及びデジタルデータ共有サービスシステム
US8771064B2 (en) 2010-05-26 2014-07-08 Aristocrat Technologies Australia Pty Limited Gaming system and a method of gaming
US8560331B1 (en) 2010-08-02 2013-10-15 Sony Computer Entertainment America Llc Audio acceleration
KR102000618B1 (ko) 2010-09-13 2019-10-21 소니 인터랙티브 엔터테인먼트 아메리카 엘엘씨 부가기능의 관리
KR20130090898A (ko) 2010-09-13 2013-08-14 소니 컴퓨터 엔터테인먼트 아메리카 엘엘씨 2중 모드 프로그램 실행 및 로딩
CN102841809B (zh) * 2011-06-22 2016-06-01 联想(北京)有限公司 信息处理方法及装置、模式切换方法以及终端设备
KR101319243B1 (ko) * 2011-08-24 2013-10-16 연세대학교 산학협력단 웹페이지 제공방법 및 이를 수행하는 프로그램을 기록한 컴퓨터 판독 가능한 기록 매체
US9131245B2 (en) 2011-09-23 2015-09-08 Qualcomm Incorporated Reference picture list construction for video coding
WO2013076576A1 (en) * 2011-11-23 2013-05-30 Roboreus Limited Systems and methods for providing and processing software objects in connection with a map-based game
KR102247892B1 (ko) 2014-12-02 2021-05-04 에스케이플래닛 주식회사 클라우드 스트리밍 서비스 시스템, 어플리케이션 코드를 이용한 이미지 클라우드 스트리밍 서비스 방법 및 이를 위한 장치
KR102273142B1 (ko) 2015-01-13 2021-07-05 에스케이플래닛 주식회사 클라우드 스트리밍 서비스 시스템, 어플리케이션 코드 변환을 이용한 이미지 클라우드 스트리밍 서비스 방법 및 이를 위한 장치
CN105844532A (zh) * 2016-03-23 2016-08-10 努比亚技术有限公司 一种处理订阅信息的方法及服务器
CN110110865B (zh) * 2018-07-20 2023-08-11 深圳怡化电脑股份有限公司 一种设备维保方法、装置、服务器、设备及存储介质
US11269612B2 (en) * 2019-12-10 2022-03-08 Paypal, Inc. Low latency dynamic content management
CN113515255B (zh) * 2021-05-17 2023-02-07 英华达（上海）科技有限公司 音频播放控制方法、系统、电子设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020053075A1 (en) * 1998-07-27 2002-05-02 Webtv Networks, Inc.; Providing compressed video
TW513655B (en) * 2000-07-04 2002-12-11 Konami Corp Method, video game device, and program for controlling game
TWI223192B (en) * 2000-10-27 2004-11-01 Sony Computer Entertainment Inc Information processing device, method for processing information, operation terminal device, information communication system, computer-readable recording medium, video game machine, method for processing information of video game machine, information
US20050125825A1 (en) * 2002-10-01 2005-06-09 Sony Corporation Broadcast system, recording device, recording method, program, and recording medium
TWI290060B (en) * 2003-09-12 2007-11-21 Konami Corp Video game program, video game device, and video game method

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6909708B1 (en) * 1996-11-18 2005-06-21 Mci Communications Corporation System, method and article of manufacture for a communication system architecture including video conferencing
JP3522527B2 (ja) * 1998-03-27 2004-04-26 富士通株式会社 入出力制御装置および入出力制御方法
US6640284B1 (en) * 2000-05-12 2003-10-28 Nortel Networks Limited System and method of dynamic online session caching
SE521645C2 (sv) * 2001-04-11 2003-11-18 Ericsson Telefon Ab L M Metod och mobiltelefon och mobiltelefonsystem som möjliggör paus i fleranvändarspel då telefonsamtal tas emot
US20030093806A1 (en) * 2001-11-14 2003-05-15 Vincent Dureau Remote re-creation of data in a television system
RU2283509C2 (ru) * 2002-07-23 2006-09-10 Самсунг Электроникс Ко., Лтд. Индексная структура метаданных, способ предоставления индексов метаданных, а также способ поиска метаданных и устройство, использующее индексы метаданных
FI116016B (fi) * 2002-12-20 2005-08-31 Oplayo Oy Puskurointijärjestely
US8370888B2 (en) * 2004-06-22 2013-02-05 University Of Southern California Hydra: high-performance data recording architecture for streaming media
JP4615958B2 (ja) * 2004-10-15 2011-01-19 クラリオン株式会社 デジタル放送の送出装置、受信装置およびデジタル放送システム
US7751324B2 (en) * 2004-11-19 2010-07-06 Nokia Corporation Packet stream arrangement in multimedia transmission
WO2006100664A2 (en) * 2005-03-21 2006-09-28 Yosef Mizrahi Method, system and computer-readable code for providing a computer gaming service
US20070265094A1 (en) * 2006-05-10 2007-11-15 Norio Tone System and Method for Streaming Games and Services to Gaming Devices
KR100776635B1 (ko) * 2006-09-28 2007-11-15 주식회사 셀런 Ｈ.264 코덱을 이용한 셋톱박스와 원격지 서버 시스템상호간의 원격접속 방법 및 이를 위한 장치

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020053075A1 (en) * 1998-07-27 2002-05-02 Webtv Networks, Inc.; Providing compressed video
TW513655B (en) * 2000-07-04 2002-12-11 Konami Corp Method, video game device, and program for controlling game
TWI223192B (en) * 2000-10-27 2004-11-01 Sony Computer Entertainment Inc Information processing device, method for processing information, operation terminal device, information communication system, computer-readable recording medium, video game machine, method for processing information of video game machine, information
US20050125825A1 (en) * 2002-10-01 2005-06-09 Sony Corporation Broadcast system, recording device, recording method, program, and recording medium
TWI290060B (en) * 2003-09-12 2007-11-21 Konami Corp Video game program, video game device, and video game method

Also Published As

Publication number Publication date
CA2707704A1 (en) 2009-06-11
TW200937220A (en) 2009-09-01
CN101918924A (zh) 2010-12-15
EP2232375A4 (en) 2012-10-10
JP2011507347A (ja) 2011-03-03
TW200943078A (en) 2009-10-16
AU2008333828B2 (en) 2013-10-03
EP2232375A1 (en) 2010-09-29
KR20100113503A (ko) 2010-10-21
AU2008333828A1 (en) 2009-06-11
WO2009073826A1 (en) 2009-06-11
RU2497184C2 (ru) 2013-10-27
NZ585909A (en) 2013-08-30
RU2010127316A (ru) 2012-01-10

Similar Documents

Publication Publication Date Title
JP6369999B2 (ja) 通信チャンネルを経て送信されるある形式のマルチメディアデータを保護するシステム及び方法
TWI399982B (zh) 用以壓縮串流互動視訊之系統
TWI459215B (zh) 用於將程式碼及資料儲存於應用程式主機代管中心內之系統及方法
TWI536804B (zh) 基於通信頻道之已偵測之資料速率以壓縮視訊的系統及方法
JP6442461B2 (ja) 通信チャンネルにわたるパケットロスの影響を減少するためのビデオ圧縮システム及び方法
JP6106208B2 (ja) ストリーミング双方向ビデオを圧縮するシステム及び方法
JP5677093B2 (ja) システム故障の前の記録されたビデオを報告するシステム
TW200951728A (en) Mothod for reporting recorded video preceding system failures
TW200942305A (en) Apparatus for streaming databases serving real-time applications used through streaming interactive video
JP2011509545A (ja) ストリーミング双方向ビデオを使用して協力的に会議を行うシステム
JP2011508478A (ja) リアルタイムストリーミング双方向ビデオのビューをマルチキャスティングする方法
JP2011509546A (ja) ストリーミング双方向ビデオとして一緒に圧縮されるリニアコンテンツ及び双方向コンテンツを合成する方法
JP2011507340A (ja) 記録されたビデオセグメントと一体化されたストリーミング双方向ビデオ
JP2011507339A (ja) リアルタイムストリーミング双方向ビデオの複数のビューを合成するシステム
JP2011507344A (ja) 記録されたアプリケーション状態をアプリケーションストリーミング双方向ビデオ出力と合成するシステム
JP2011514017A (ja) ストリーミング双方向ビデオを通して使用されるリアルタイムアプリケーションに応対するデータベースをストリーミングするシステム
JP2011507077A (ja) ストリーミング双方向ビデオサーバー間でユーザセッションを移行する方法
JP2011507341A (ja) ストリーミング双方向ビデオを使用したバーチャル事象のホスティング及びブロードキャスティング
TW200952495A (en) Apparatus for combining aplurality of views of real-time streaming interactive video
TW200935916A (en) System and method for compressing video by adjusting tile size based on detected intraframe motion or scene complexity
TW200939789A (en) Method for user session transitioning among streaming interactive video servers
TW200939780A (en) Video compression system and method for compensating for bandwidth limitations of a communication channel