"装置からコントロール入力を受け取る段階と、ストリーミング双方向ビデオであるホスティングサービスにおいてビデオタイルのウオールをレンダリングする段階であって、ビデオタイルのウオールが前記コントロール入力に基づいて3Dで歪められる段階と、を備えた方法。前記コントロール入力は、1つ以上のコントロールアクションに応答して装置のユーザインターフェイスにより発生される、請求項1に記載の方法。前記コントロール入力は、タッチスワイプ信号を含む、請求項1に記載の方法。前記コントロール入力は、ジョイスティック動き信号を含む、請求項1に記載の方法。前記コントロール入力は、矢印キー信号を含む、請求項1に記載の方法。前記コントロール入力は、マウスアクション信号を含む、請求項1に記載の方法。前記ビデオタイルのウオールは、前記コントロール入力の比例する程度に歪められる、請求項1に記載の方法。前記パラメータは、コントロールアクションの速度又は程度である、請求項7に記載の方法。多数のビデオタイルがレンダリングされるときは、ある数のビデオタイルを交互の静止画像に置き換える、請求項1に記載の方法。以下の説明では、本開示を完全に理解するために、装置の形式、システムコンフィギュレーション、通信方法、等の特定の細部について述べる。しかしながら、当業者であれば、ここに述べる実施形態を具現化するのに、これらの特定の細部は必要ないことが明らかであろう。図2a-bは、ビデオゲーム及びソフトウェアアプリケーションが、契約サービスのもとでインターネット206或いは他のパブリック又はプライベートネットワークを経てユーザの家屋211ユーザの家屋とは、ユーザが所在する場所を意味し、移動装置を使用する場合には屋外も含むにおいてホスティングサービス210によりホストされそしてクライアント装置205によりアクセスされるような2つの実施形態の高レベルアーキテクチャーを示す。クライアント装置205は、内部又は外部ディスプレイ装置222を有していてインターネットにワイヤード又はワイヤレス接続されるMicrosoftWindows又はLinux登録商標ベースのPC又はApple社のMacintoshコンピュータのような汎用コンピュータでもよいし、又はビデオ及びオーディオをモニタ又はTV受像機222へ出力するセットトップボックスインターネットにワイヤード又はワイヤレス接続されるのような専用クライアント装置でもよいし、或いはおそらくインターネットにワイヤレス接続される移動装置でもよい。これらの装置は、いずれも、それ自身のユーザ入力装置例えば、キーボード、ボタン、タッチスクリーン、トラックパッド又は慣性感知棒、ビデオ捕獲カメラ及び/又は運動追跡カメラ、等を有してもよいし、又は有線又は無線で接続された外部入力装置221例えば、キーボード、マウス、ゲームコントローラ、慣性感知棒、ビデオ捕獲カメラ、及び/又は運動追跡カメラ、等を使用してもよい。以下に詳細に述べるように、ホスティングサービス210は、高パワーのCPU/GPU処理能力を伴うものを含めて、種々の性能レベルのサーバーを含む。ゲームのプレイ中、又はホスティングサービス210におけるアプリケーションの使用中に、家庭又はオフィス用のクライアント装置205は、ユーザからのキーボード及び/又はコントローラ入力を受け取り、次いで、インターネット206を通してホスティングサービス210へコントローラ入力を送信し、このホスティングサービス210は、それに応答してゲームプログラムを実行し、そしてゲーム又はアプリケーションソフトウェアのためのビデオ出力の連続フレーム一連のビデオ映像を発生する例えば、ユーザがボタンを押して、スクリーン上のキャラクタを右へ移動するように指令する場合には、ゲームプログラムが、右へ移動するキャラクタを示す一連のビデオ映像を生成する。この一連のビデオ映像は、次いで、短待ち時間のビデオコンプレッサを使用して圧縮され、次いで、ホスティングサービス210は、インターネット206を通して短待ち時間のビデオストリームを送信する。家庭又はオフィス用クライアント装置は、次いで、圧縮されたビデオストリームをデコードし、そしてモニタ又はTVにおいてその解凍されたビデオ映像をレンダリングする。その結果、クライアント装置205のコンピューティング及びグラフィックハードウェア要件が著しく緩和される。クライアント205は、キーボード/コントローラ入力をインターネット206へ転送し、そしてインターネット206から受け取った圧縮されたビデオストリームをデコードし解凍するための処理パワーを有するだけでよく、これは、実質上、パーソナルコンピュータが、今日、そのCPUにおいてソフトウケアで実行できることである例えば、ほぼ2GHzで実行されるインテル社のCoreDuoCPUは、H.264及びWindowsMediaVC9のようなコンプレッサを使用してエンコードされた720pHDTVを解凍することができる。そして、クライアント装置のケースでは、専用のチップも、このような規格に対するビデオ解凍を、リアルタイムで、遥かに低いコストにおいて、且つ近代的なPCに要求されるような汎用CPUより遥かに低い消費電力で遂行することができる。特に、コントローラ入力を転送しそしてビデオを解凍する機能を遂行するために、家庭用クライアント装置205は、特殊なグラフィック処理ユニットGPU、光学的ドライブ又はハードドライブ、例えば、図1に示す従来のビデオゲームシステムを要求しない。ゲーム及びアプリケーションソフトウェアが、より複雑になり且つよりホトリアリスティックになるにつれて、それらは、高性能CPU、GPU、より多くのRAM、及びより大きくて高速のディスクドライブを要求し、且つホスティングサービス210のコンピューティングパワーは、アップグレードし続けるが、エンドユーザは、家庭又はオフィス用のクライアントプラットホーム205を更新することが要求されない。というのは、その処理要件は、所与のビデオ解凍アルゴリズムでの表示解像度及びフレームレートに対して一定のままだからである。従って、図2a-bに示すシステムには、今日見られるハードウェア制限及び互換性の問題が生じない。更に、ゲーム及びアプリケーションソフトウェアは、ホスティングサービス210のサーバーでのみ実行されるので、ゲーム又はアプリケーションソフトウェアのコピー光学的メディアの形態又はダウンロードされたソフトウェアとしてがユーザの家庭又はオフィスに存在することはないここで使用するオフィスとは、特に指示のない限り、例えば、学校の教室を含めて、非住居設定を含むものとする。これは、ゲーム又はアプリケーションソフトウェアが不法にコピーされる海賊版作成されるおそれを著しく軽減すると共に、海賊版作成されるゲーム又はアプリケーションにより貴重なデータベースが使用されるおそれを軽減する。実際に、家庭又はオフィスでの使用に実際的でないゲーム又はアプリケーションソフトウェアをプレイするために特殊なサーバーが要求される例えば、非常に高価で、大きく又はノイズを発生する装置が要求される場合には、ゲーム又はアプリケーションソフトウェアの海賊版コピーが得られたとしても、家庭又はオフィスで動作することはできない。一実施形態では、ホスティングサービス210は、ソフトウェア開発ツールをゲーム又はアプリケーションソフトウェア開発者一般的に、ソフトウェア開発会社、ゲーム又は映画スタジオ、或いはゲーム又はアプリケーションソフトウェア発行者を指す220に与え、この開発者は、ホスティングサービス210において実行できるゲームを設計するようにビデオゲームを設計する。そのようなツールは、スタンドアローンPC又はビデオゲームコンソールでは通常利用できないホスティングサービスの特徴を開発者が利用できるようにする例えば、複雑な幾何学形状の非常に大きなデータベースへの高速アクセス幾何学形状とは、特に指示のない限り、ここでは、多角形、テクスチャ、リギング、照明、挙動、並びに3Dデータベースを定義する他のコンポーネント及びパラメータを指すものとする。このアーキテクチャーのもとでは、異なるビジネスモデルが考えられる。1つのモデルのもとで、ホスティングサービス210は、図2aに示すように、エンドユーザから契約料金を収集し、そして開発者220にロイヤリティを支払う。図2bに示す別の具現化においては、開発者220がユーザから契約料金を直接収集し、そしてゲーム又はアプリケーションコンテンツをホストするためにホスティングサービス210に支払をする。これらの基礎的な原理は、オンラインゲーム又はアプリケーションホスティングを提供するための特定のビジネスモデルに限定されない。圧縮ビデオ特性上述したように、ビデオゲームサービス又はアプリケーションソフトウェアサービスをオンラインで提供することに伴う1つの顕著な問題は、待ち時間である。ユーザにより入力装置が操作される点から、ディスプレイ装置に応答が表示される点までの70から80msの待ち時間が、高速応答時間を要求するゲーム及びアプリケーションの上限である。しかしながら、図2a及び2bに示すアーキテクチャーの環境では多数の実際的及び物理的な制約があるために、これを達成することが非常に困難である。図3に示すように、ユーザがインターネットサービスに契約するときに、その接続は、典型的に、ユーザの家庭又はオフィスへの公称最大データレート301によって定格付けされる。プロバイダーのポリシー及びルーティング装置の能力に基づいて、その最大データレートは、若干厳格に施行できるが、典型的に、実際に得られるデータレートは、多数の異なる理由の1つで、低いものとなる。例えば、DSL中央オフィス又はローカルケーブルモデムループに非常に多くのネットワークトラフィックがあるか、又はケーブルにノイズが生じてパケットをドロップさせるか、或いはプロバイダーが最大ビット数/月/ユーザを確立することがある。現在、ケーブル及びDSLサービスに対する最大ダウンストリームデータレートは、典型的に、数百キロビット/秒Kbpsから30Mbpsの範囲である。セルラーサービスは、典型的に、数百Kbpsのダウンストリームデータに制限される。しかしながら、ブロードバンドサービスの速度及びブロードバンドサービスに契約するユーザの数は、時間と共に急激に増加する。現在、ある分析では、米国のブロードバンド加入者の33が2Mbps以上のダウンストリームデータレートを有することが推定される。例えば、ある分析では、2010年までに、米国のブロードバンド加入者の85以上が2Mbps以上のデータレートを有することが推定される。図3に示すように、実際に利用可能な最大データレート302は、時間と共に変動し得る。従って、短い待ち時間のオンラインゲーム又はアプリケーションソフトウェアコンテクストでは、時々、特定のビデオストリームに対する実際に利用できるデータレートを予想することが困難である。所与の数値のフレーム/秒fpsにおける所与のレベルのクオリティをある量のシーンの複雑さに対し所与の解像度例えば、640x48060fpsにおいて維持するためにデータレート303が要求され、そして図3にピークで示されるように実際に利用できる最大データレート302より上に動きが上昇する場合には、多数の問題が発生し得る。例えば、あるインターネットサービスは、単にパケットをドロップし、ユーザのビデオスクリーンにデータロス及び映像歪/ロスを招くことになる。他のサービスは、付加的なパケットを一時的にバッファし即ち、キューイングし、そして利用可能なデータレートでクライアントへパケットを与えて、待ち時間の増加、即ち多数のビデオゲーム及びアプリケーションにとって受け容れられない結果を招くことになる。最終的に、あるインターネットサービスプロバイダーは、データレートの増加を、悪意のある攻撃、例えば、サービス拒否攻撃ネットワーク接続を無能化するためにハッカーにより使用される良く知られた技術とみなし、そしてユーザのインターネット接続を指定期間中切断する。従って、ここに述べる実施形態は、ビデオゲームに要求されるデータレートが、利用可能な最大データレートを越えないことを保証するステップをとる。ホスティングサービスアーキテクチャー図4aは、一実施形態によるホスティングサービス210のアーキテクチャーを示す。ホスティングサービス210は、単一サーバーセンターに配置することもできるし、又は複数のサーバーセンターにわたり分散することもできるあるサーバーセンターへの経路が他のサーバーセンターより短い待ち時間となる短待ち時間接続をユーザに与え、ユーザ間に負荷バランスを与え、そして1つ以上のサーバーセンターがフェイルする場合に冗長性を与えるために。ホスティングサービス210は、最終的に、数百又は数千或いは数百万のサーバー402を含み、非常に大きなユーザベースにサービスすることができる。ホスティングサービスコントロールシステム401は、ホスティングサービス210に対する全体的なコントロールを与え、ルーター、サーバー、ビデオ圧縮システム、ビリング及びアカウンティングシステム、等に指令する。一実施形態では、ホスティングサービスコントロールシステム401は、ユーザ情報、サーバー情報及びシステム統計情報のためのデータベースを記憶するのに使用されるRAIDアレイに結合された分散処理Linuxベースシステムにおいて具現化される。以上の説明では、ホスティングサービス210により具現化される種々のアクションは、他の特定システムに起因しない限り、ホスティングサービスコントロールシステム401により開始されコントロールされる。ホスティングサービス210は、インテル、IBM、ヒューレットパッカード、等から現在入手できるもののような多数のサーバー402を含む。或いは又、サーバー402は、コンポーネントのカスタム構成でアッセンブルすることもできるし、又は全サーバーが単一チップとして具現化されるように最終的に一体化することもできる。この図は、図示明瞭化のために、少数のサーバー402しか示していないが、実際の展開では、1つ程度のサーバー402があってもよいし、又は数百万以上のサーバー402があってもよい。サーバー402は、全てが同様に構成されてもよいし幾つかの構成パラメータの例として、同じCPU形式及び性能で、GPUをもったりもたなかったりして、そしてGPUをもつ場合には、同じGPU形式及び性能で、又、同じ数のCPU及びGPUで、又、同じ量及び形式/速度のRAMで、並びに同じRAM構成で、又はサーバー402の種々のサブセットが同じ構成を有してもよいし例えば、サーバーの25をある仕方で構成することができ、50を異なる仕方で構成することができ、そして25を更に別の仕方で構成することができ、或いは各サーバー402が異なるものでもよい。一実施形態では、サーバー402は、ディスクレスであり、即ちそれ自身のローカル大量記憶装置光学又は磁気記憶装置、或いは半導体ベースの記憶装置、例えば、フラッシュメモリ又は同様の機能を果たす他の大量記憶手段を有するのではなく、各サーバーは、高速バックプレーン又はネットワーク接続を通して共有大量記憶装置にアクセスする。一実施形態では、この高速接続は、一連の独立ディスク冗長アレイRAID405に接続された記憶エリアネットワークSAN403であり、装置間の接続がギガビットイーサネット登録商標を使用して具現化される。当業者に明らかなように、SAN403は、多数のRAIDアレイ405を一緒に合成して、最終的に広い帯域巾を生じさせ、即ち現在のゲームコンソール及びPCに使用されるRAMから得られる帯域巾に接近するか又はそれを潜在的に越えるのに使用される。そして、磁気メディアのような回転メディアをベースとするRAIDアレイは、著しいシーク時間アクセス待ち時間をしばしば有するが、半導体記憶装置をベースとするRAIDアレイは、相当に短いアクセス待ち時間で具現化することができる。別の構成では、サーバー402の幾つか又は全部が、それら自身の大量記憶装置の幾つか又は全部をローカルで与える。例えば、サーバー402は、そのオペレーティングシステムのような頻繁にアクセスされる情報、及びビデオゲーム又はアプリケーションのコピーを短待ち時間のローカルフラッシュベースの記憶装置に記憶するが、幾何学形状又はゲーム状態情報の大きなデータベースに時々アクセスするには、SANを使用して、回転メディアをベースとするRAIDアレイ405に大きなシーク待ち時間でアクセスする。更に、一実施形態では、ホスティングサービス210は、以下に詳細に説明する短待ち時間のビデオ圧縮ロジック404を使用する。このビデオ圧縮ロジック404は、ソフトウェア、ハードウェア又はその組合せで具現化することができるその幾つかの実施形態を以下に説明する。ビデオ圧縮ロジック404は、オーディオ及びビジュアル資料を圧縮するためのロジックを含む。動作に際し、ユーザの家屋211において、キーボード、マウス、ゲームコントローラ又は他の入力装置421を経てビデオゲームをプレイするか又はアプリケーションを使用する間に、クライアント415のコントロール信号ロジック413は、ユーザにより作動されたボタン押圧及び他の形式のユーザ入力を表す典型的にUDPパケットの形態のコントロール信号406a-bを送信する。所与のユーザからのコントロール信号は、適当なサーバー又は複数のサーバーがユーザの入力装置に応答する場合には複数のサーバー402へルーティングされる。図4aに示すように、コントロール信号406aは、SANを経てサーバー402へルーティングされる。それとは別に又はそれに加えて、コントロール信号406bは、ホスティングサービスネットワーク例えば、イーサネットベースのローカルエリアネットワークを経てサーバー402へ直接ルーティングされる。それらがどのように送信されるかに関わらず、サーバー1つ又は複数は、コントロール信号406a-bに応答してゲーム又はアプリケーションソフトウェアを実行する。図4aに示されていないが、ファイアウオール1つ又は複数及び/又はゲートウェイ1つ又は複数のような種々のネットワークコンポーネントは、ホスティングサービス210の縁例えば、ホスティングサービス210とインターネット410との間において、及び/又はインターネット410と家庭又はオフィスクライアント415との間のユーザの家屋211の縁において到来するトラフィック及び出て行くトラフィックを処理することができる。実行されたゲーム又はアプリケーションソフトウェアのグラフィック及びオーディオ出力、即ちビデオ映像の新たなシーケンスは、短待ち時間のビデオ圧縮ロジック404へ供給され、このロジックは、ここに述べるような短待ち時間のビデオ圧縮技術に基づいてビデオ映像のシーケンスを圧縮し、そして圧縮されたビデオストリームを、典型的に、圧縮された又は非圧縮のオーディオと共に、インターネット410を経て又は、以下に述べるように、一般的なインターネットをバイパスする最適な高速ネットワークサービスを経てクライアント415へ返送する。クライアント415における短待ち時間のビデオ解凍ロジック412は、次いで、ビデオ及びオーディオストリームを解凍し、その解凍されたビデオストリームをレンダリングし、そして典型的に、その解凍されたオーディオストリームをディスプレイ装置422においてプレイする。或いは又、オーディオは、ディスプレイ装置422とは個別のスピーカで再生してもよいし、そうでなくてもよい。入力装置421及びディスプレイ装置422は、図2a及び2bでは独立した装置として示されているが、ポータブルコンピュータ又は移動装置のようなクライアント装置内に一体化されてもよいことに注意されたい。家庭又はオフィスクライアント415図2a及び2bにおいて家庭又はオフィスクライアント205として既に述べたは、非常に安価で且つ低電力の装置で、計算又はグラフィック性能が非常に限定されていると共に、ローカルの大量記憶装置が非常に限定されたものであるか又はそれを全く有していない。対照的に、SAN403及び複数のRAID405に結合された各サーバー402は、非常に高い性能のコンピューティングシステムであり、そして実際に、複数のサーバーが並列処理構成で協働的に使用される場合は、保持することのできる計算及びグラフィック処理パワーの量にほぼ制限がなくなる。そして、ユーザにとって知覚的に短待ち時間のビデオ圧縮404及び短待ち時間のビデオ圧縮412のために、サーバー402の計算パワーがユーザに与えられる。ユーザが入力装置421のボタンを押すと、ディスプレイ422上の映像は、ゲーム又はアプリケーションソフトウェアがローカルで実行されるかのように、知覚的に意義のある遅延を伴わずに、ボタンの押圧に応答して更新される。従って、短待ち時間のビデオ解凍及びコントロール信号ロジック413を具現化する非常に低性能のコンピュータ又は安価なチップである家庭又はオフィスクライアント415では、ローカルで利用できると思われるリモート位置から効果的な任意の計算パワーがユーザに与えられる。これは、最も進歩したプロセッサ集中の典型的に新規なビデオゲーム及び最高性能のアプリケーションをプレイするパワーをユーザに与える。図4cは、非常に基本的で且つ安価な家庭又はオフィスクライアント装置465を示す。この装置は、図4a及び4bからの家庭又はオフィスクライアント415の実施形態である。これは約2インチの長さである。これは、パワーオーバーイーサネットPoEでイーサネットケーブルとインターフェイスするイーサネットジャック462を有し、そこから、インターネットへの電力及び接続が得られる。ネットワークアドレストランスレーションNATをサポートするネットワーク内でNATを実行することができる。オフィス環境では、多数の新規なイーサネットスイッチは、PoEを有し、そしてPoEをオフィスのイーサネットジャックへ直接持って行く。このような状況では、壁ジャックからクライアント465へのイーサネットケーブルが要求されるだけである。利用できるイーサネット接続が例えば、DSL又はケーブルモデムをもつが、PoEはもたない家庭において電力を搬送しない場合には、非給電イーサネットケーブル及びPoE付き出力イーサネットを受け容れる安価な壁ブリック即ち電源が利用できる。クライアント465は、キーボード、マウス、ゲームコントローラ及び/又はマイクロホン及び/又はヘッドセットのようなブルーツース入力装置479とインターフェイスするブルーツースワイヤレスインターフェイスに結合された図4aのコントロール信号ロジック413を含む。又、クライアント465の一実施形態は、120fpsビデオをサポートできるディスプレイ装置468に結合されるビデオを120fpsで出力し、そしてシャッター付き眼鏡466に信号を送って典型的に赤外線により、各次々のフレームで片方の目に、次いで、他方の目に交互にシャッター作動することができる。ユーザが認知する効果は、ディスプレイスクリーンを跳び出すステレオ3D映像である。このようなオペレーションをサポートする1つのこのようなディスプレイ装置468は、SamsungHL-T5076Sである。各目のビデオストリームは個別であるから、一実施形態では、独立した2つのビデオストリームがホスティングサービス210により圧縮され、フレームは、時間的にインターリーブされ、そしてフレームは、クライアント465内の独立した2つの解凍プロセスとして解凍される。又、クライアント465は、到来するビデオ及びオーディオを解凍してHDMI高鮮明度マルチメディアインターフェイスを通して出力する短待ち時間のビデオ解凍ロジック412と、SDTV標準鮮明度テレビジョン又はHDTV高鮮明度テレビジョン468に差し込まれてTVにビデオ及びオーディオを与えるか又はHDMIをサポートするモニタ468に差し込まれるコネクタ463とを含む。ユーザのモニタ468がHDMIをサポートしない場合には、HDMI対DVIデジタルビジュアルインターフェイスを使用することができるが、オーディオが失われる。HDMI規格のもとでは、ディスプレイの能力例えば、サポートされる解像度、フレームレート464がディスプレイ装置468から通信され、この情報は、次いで、インターネット接続462を通してホスティングサービス210へ返送され、従って、ディスプレイ装置に適したフォーマットで圧縮ビデオをストリーミングすることができる。図4dは、より多くの外部インターフェイスを有する以外は図4cに示す家庭又はオフィスクライアント装置465と同じである家庭又はオフィスクライアント装置475を示す。又、クライアント475は、電力に対してPoEを受け容れることもできるし、又は壁に差し込まれる外部電源アダプタ図示せずから延びることもできる。クライアント475のUSB入力を使用すると、ビデオカメラ477は、圧縮されたビデオをクライアント475へ供給し、これは、クライアント475によってホスティングサービス210へアップロードされ、以下に述べるように使用される。カメラ477に内蔵されるのは、以下に述べる圧縮技術を使用した短待ち時間のコンプレッサである。インターネット接続としてイーサネットコネクタを有するのに加えて、クライアント475は、インターネットへの802.11gワイヤレスインターフェイスも有する。両インターフェイスは、NATをサポートするネットワーク内でNATを使用することができる。又、ビデオ及びオーディオを出力するためにHDMIコネクタを有するのに加えて、クライアント475は、アナログ出力を含む且つ標準アダプタケーブルでVGA出力を与えるデュアルリンクDVI-Iコネクタも有する。又、これは、複合ビデオ及びS-ビデオのためのアナログ出力も有する。オーディオに対して、クライアント475は、左右のアナログステレオRCAジャックを、そしてデジタルオーディオ出力に対して、TOSLINK出力を有する。又、入力装置479へのブルーツースワイヤレスインターフェイスに加えて、入力装置にインターフェイスするためのUSBジャックも有する。図4eは、クライアント465の内部アーキテクチャーの一実施形態を示す。図示された装置の全部又は幾つかを、フィールドプログラマブルロジックアレー、カスタムASIC、或いはカスタム設計又は既製の多数の個別装置で具現化することができる。PoEを伴うイーサネット497がイーサネットインターフェイス481に取り付けられる。PoEを伴うイーサネット497から電力499が導出され、クライアント465内の残りの装置に接続される。バス480は、装置間の通信のための共通バスである。フラッシュ476からの小さなクライアントコントロールアプリケーションを実行するコントロールCPU483ほとんどの場合に、RAMが埋設された100MHzのMIPSR4000シリーズCPUのような小型のCPUで充分であるは、ネットワーク即ち、イーサネットインターフェイスのためのプロトコルスタックを具現化し、又、ホスティングサービス210と通信し、そしてクライアント465内の全ての装置を構成する。又、これは、入力装置469とのインターフェイスを取り扱い、そして必要に応じて、順方向エラー修正で保護して、パケットをユーザコントローラデータと共にホスティングサービス210へ返送する。又、コントロールCPU483は、パケットトラフィックを監視する例えば、パケットが失われるか遅延された場合、それらの到着にタイムスタンプも押す。この情報は、ホスティングサービス210へ返送され、従って、ネットワーク接続を常時監視し、それに応じて何を送信するか調整することができる。フラッシュメモリ476は、最初に、製造時に、コントロールCPU483のコントロールプログラムがロードされると共に、特定のクライアント465ユニットにとって独特のシリアル番号もロードされる。このシリアル番号は、ホスティングサービス210がクライアント465ユニットを独特に識別できるようにする。ブルーツースインターフェイス484は、クライアント465の内部にあるそのアンテナを通して入力装置469へワイヤレス通信する。ビデオデコンプレッサ486は、ここに述べるビデオ解凍を具現化するように構成された短待ち時間のビデオデコンプレッサである。非常に多数のビデオ解凍装置が、既製品として、又はFPGA又はカスタムASICへ一体化できる知的プロパティIP設計として、存在する。H.264デコーダのためのIPを提供する1つの会社は、NSWオーストラリアのオーシャンロジックオブマンリーである。IPを使用する効果は、ここで使用する圧縮技術が圧縮規格に従わないことである。ある標準的なデコンプレッサは、ここに述べる圧縮技術を受け容れるように構成されるに充分なほど融通性があるが、あるものはそうではない。しかし、IPでは、デコンプレッサを必要に応じて設計し直す上で完全な融通性がある。ビデオデコンプレッサの出力は、ビデオ出力サブシステム487に結合され、これは、ビデオをHDMIインターフェイス490のビデオ出力に結合する。オーディオ解凍サブシステム488は、入手可能な標準的オーディオデコンプレッサを使用して具現化されるか、又はIPとして具現化することもでき、或いはオーディオの解凍は、例えば、Vorbis.comにおいて入手できるVorbisオーディオデコンプレッサを具現化できるコントロールプロセッサ483内で具現化することもできる。オーディオの解凍を具現化する装置は、オーディオ出力サブシステム489へ結合され、これは、オーディオをHDMIインターフェイス490のオーディオ出力へ結合する。図4fは、クライアント475の内部アーキテクチャーの一実施形態を示す。明らかなように、このアーキテクチャーは、付加的なインターフェイスと、壁に差し込む電源アダプタからの任意の外部DC電力を除き、クライアント465と同じであり、その外部DC電力は、そのように使用される場合、イーサネットPoE497から到来する電力に取って代わる。クライアント465と共通の機能は、以下に説明を繰り返さず、付加的な機能を以下に説明する。CPU483は、付加的な装置と通信し、それを構成する。WiFiサブシステム482は、そのアンテナを通してイーサネット497への代替物としてワイヤレスインターネットアクセスを与える。WiFiサブシステムは、カリフォルニア州サンタクララのアセロスコミュニケーションズを含めて幅広い製造者から入手できる。USBサブシステム485は、ワイヤードUSB入力装置479に対してブルーツース通信の代替物を与える。USBサブシステムは、極めて標準的で、FPGA及びASICについて入手容易であり、且つビデオ解凍と同様に、他の機能を遂行する既製装置にしばしば内蔵される。ビデオ出力サブシステム487は、クライアント465内よりも広範囲なビデオ出力を発生する。これは、HDMI490ビデオ出力を与えるのに加えて、DVI-I491、S-ビデオ492及び複合ビデオ493を与える。又、DVI-I491インターフェイスがデジタルビデオに対して使用されるときには、ディスプレイ能力464がディスプレイ装置からコントロールCPU483へ返送され、ディスプレイ装置478の能力をホスティングサービス210に通知できるようにする。ビデオ出力サブシステム487により与えられる全てのインターフェイスは、極めて標準的なインターフェイスであり、多数の形態で入手容易である。オーディオ出力サブシステム489は、デジタルインターフェイス494S/PDIF及び/又はToslinkを通してオーディオをデジタルで出力すると共に、ステレオアナログインターフェイス495を通してオーディオをアナログ形態で出力する。往復待ち時間の分析もちろん、以上の段落を理解するために、入力装置421を使用したユーザのアクションと、そのアクションの結果をディスプレイ装置420で見るときとの間の往復待ち時間は、70-80ms以下でなければならない。この待ち時間は、ユーザの家屋211内の入力装置421からホスティングサービス210へそしてユーザの家屋211へ戻って、ディスプレイ装置422へ至る経路における全てのファクタを考慮しなければならない。図4bは、信号が進行しなければならない種々のコンポーネント及びネットワークを示し、これらコンポーネント及びネットワークの上には、実際の具現化で予想できる待ち時間を列挙した時間線がある。図4bは、重要な経路ルーティングだけを示すように簡略化されていることに注意されたい。システムの他の特徴のために使用されるデータの他のルーティングは、以下で説明する。双頭矢印例えば、矢印453は、往復待ち時間を表し、単頭矢印例えば、矢印457は、片道待ち時間を表し、そして~は、近似尺度を示す。列挙した待ち時間を達成できない実世界の状況があるが、米国内における多くのケースでは、ユーザの家屋211へのDSL及びケーブルモデム接続を使用し、次の段落で述べる環境においてこれら待ち時間を達成できることを指摘しなければならない。又、インターネットへのセルラーワイヤレス接続は、図示されたシステムにおいて確実に機能するが、ほとんどの現在のUSセルラーデータシステムEVDOのようなは、非常に長い待ち時間を被り、図4bに示す待ち時間を達成できないことにも注意されたい。しかしながら、これらの基礎的な原理は、このレベルの待ち時間を具現化できる将来のセルラー技術において具現化することができよう。更に、現在のUSセルラーデータシステムを経て被る待ち時間が、ユーザに気付くものであるが、ゲーム又はアプリケーションにとって許容できるようなゲーム及びアプリケーションシナリオ例えば、チェスのような速いユーザ反応時間を要求しないゲームもある。ユーザの家屋211における入力装置421からスタートして、ユーザが入力装置421を操作すると、ユーザコントロール信号がクライアント415へ送信されこれは、セットトップボックスのようなスタンドアローン装置でもよいし、或いはPC又は移動装置のような別の装置で実行されるソフトウェア又はハードウェアでもよい、そして一実施形態ではUDPフォーマットでパケット化され、そのパケットには、ホスティングサービス210に到着するための行先アドレスが与えられる。又、パケットは、コントロール信号がどのユーザから到来するか指示する情報も含む。次いで、コントロール信号のパケット1つ又は複数は、ファイアウオール/ルーター/NATネットワークアドレストランスレーション装置443を通してWANインターフェイス442へ転送される。WANインターフェイス442は、ユーザのISPインターネットサービスプロバイダーによりユーザの家屋211に与えられるインターフェイス装置である。WANインターフェイス442は、ケーブル又はDSLモデム、WiMaxトランシーバー、ファイバートランシーバー、セルラーデータインターフェイス、インターネットプロトコルオーバーパワーラインインターフェイス、又はインターネットへの多数のインターフェイスの他のものでよい。更に、ファイアウオール/ルーター/NAT装置443及び潜在的にWANインターフェイス442は、クライアント415に一体化されてもよい。その一例は、家庭又はオフィスクライアント415の機能を具現化するためのソフトウェアと、ある規格例えば、802.11gによりインターネットへワイヤレスでルーティング及び接続する手段とを含む移動電話である。WANインターフェイス442は、次いで、コントロール信号をユーザのインターネットサービスプロバイダーISPのための存在点441と称されるものへルーティングし、これは、ユーザの家屋211に接続されたWANトランスポートと、一般的インターネット又はプライベートネットワークとの間のインターフェイスをなすファシリティである。存在点の特性は、提供されるインターネットサービスの性質に基づいて変化する。DSLの場合、これは、典型的に、DSLAMが配置される電話会社の中央オフィスとなる。ケーブルモデムの場合、これは、典型的に、ケーブルマルチシステムオペレータMSOヘッドエンドとなる。セルラーシステムの場合、これは、典型的に、セルラータワーに関連したコントロールルームとなる。しかし、存在点の性質が何であれ、これは、コントロール信号パケット1つ又は複数を一般的インターネット410へルーティングする。コントロール信号パケット1つ又は複数は、次いで、最も多くはファイバトランシーバーインターフェイスであるものを通して、ホスティングサービス210へのWANインターフェイス441へルーティングされる。WAN441は、次いで、コントロール信号パケットをルーティングロジック409これは、イーサネットスイッチ及びルーティングサーバーを含めて、多数の異なる仕方で具現化されるへルーティングし、これは、ユーザのアドレスを評価し、そしてコントロール信号を所与のユーザに対する正しいサーバー402へルーティングする。サーバー402は、次いで、コントロール信号を、サーバー402で実行されるゲーム又はアプリケーションソフトウェアに対する入力として取り上げ、そしてそのコントロール信号を使用して、ゲーム又はアプリケーションの次のフレームを処理する。次のフレームが発生されると、サーバー402からビデオコンプレッサ404へビデオ及びオーディオが出力される。ビデオ及びオーディオは、サーバー402から種々の手段を経てコンプレッサ404へ出力される。先ず、コンプレッサ404は、サーバー402に組み込むことができ、従って、圧縮をサーバー402内でローカルに具現化することができる。又は、ビデオ及び/又はオーディオは、パケット化形態で、イーサネット接続のようなネットワーク接続を経て、サーバー402とビデオコンプレッサ404との間のプライベートネットワークであるネットワークへ、又はSAN403のような共有ネットワークを通して、出力することができる。或いは、ビデオは、サーバー402から、DVI又はVGAコネクタのようなビデオ出力コネクタを通して出力され、次いで、ビデオコンプレッサ404により捕獲されてもよい。又、オーディオは、サーバー402からデジタルオーディオとして例えば、TOSLINK又はS/PDIFコネクタを経て出力されるか又はアナログオーディオとして出力されてもよく、アナログオーディオは、ビデオコンプレッサ404内のオーディオ圧縮ロジックによりデジタル化されエンコードされる。ビデオコンプレッサ404は、ビデオフレーム、及びサーバー402からのそのフレーム時間中に発生されたオーディオを捕獲すると、以下に述べる技術を使用してビデオ及びオーディオを圧縮する。ビデオ及びオーディオが圧縮されると、アドレスと共にパケット化されて、ユーザのクライアント415へ返送され、WANインターフェイス441へルーティングされ、このWANインターフェイスは、ビデオ及びオーディオパケットを一般的なインターネット410を経てルーティングし、このインターネットは、ビデオ及びオーディオパケットをユーザのISP存在点441へルーティングし、この存在点は、ビデオ及びオーディオパケットをユーザの家屋のWANインターフェイス442へルーティングし、このインターフェイスは、ビデオ及びオーディオパケットをファイアウオール/ルーター/NAT装置443へルーティングし、次いで、この装置は、ビデオ及びオーディオパケットをクライアント415へルーティングする。クライアント415は、ビデオ及びオーディオを解凍し、次いで、ビデオをディスプレイ装置422又はクライアントの内蔵ディスプレイ装置に表示すると共に、オーディオをディスプレイ装置422又は個別の増幅器/スピーカへ或いはクライアントに内蔵された増幅器/スピーカへ送信する。上述した全プロセスに知覚的に遅れがないことをユーザが認知するためには、往復遅延が70又は80ms未満である必要がある。前記往復経路における待ち時間遅延のあるものは、ホスティングサービス210及び/又はユーザのコントロールのもとにあり、他のものは、そうではない。それでも、非常に多数の実世界のシナリオの分析及びテストに基づき、おおよその測定値は次のようになる。コントロール信号451を送信するための片道送信時間は、典型的に、1ms未満であり、ユーザの家屋452を通る往復ルーティングは、典型的に、イーサネット上に入手容易な消費者グレードのファイアウオール/ルーター/NATスイッチを使用して約1msで達成される。ユーザISPは、その往復遅延453が広く変化するが、DSL及びケーブルモデムプロバイダーでは、典型的に、10ないし25msである。一般的なインターネット410における往復待ち時間は、トラフィックがどのようにルーティングされるか及びルートに欠陥があるかどうかこれらの問題は以下で述べるに基づいて大きく変化するが、典型的に、一般的なインターネットは、非常に最適なルートを与え、そして待ち時間は、行先までの距離が与えられると、主として光ファイバを通る光の速度によって決定される。以下に更に述べるように、ユーザの家屋211から離れてホスティングサービス210を発することが予想される最も遠いおおよその距離として1000マイルを確立した。1000マイル往復2000マイルでは、インターネットを通る信号の実際の通過時間は、約22msである。ホスティングサービス210へのWANインターフェイス441は、典型的に、待ち時間を無視できる商業的グレードファイバの高速インターフェイスである。従って、一般的インターネットの待ち時間454は、典型的に、1ないし10msである。ホスティングサービス210を通る片道ルーティング455の待ち時間は、1ms未満である。サーバー402は、典型的に、ゲーム又はアプリケーションのための新たなフレームを1フレーム時間60fpsでは16.7msである未満で計算し、従って、使用するために合理的な最大片道待ち時間は、16msである。ここに述べるビデオ圧縮及びオーディオ圧縮アルゴリズムの最適なハードウェア具現化では、圧縮457を1msで完了することができる。あまり最適でない形態では、圧縮に6ms程度を要するもちろん、もっと最適でない形態は、更に長い時間を要するが、このような具現化は、往復の全待ち時間に影響を及ぼし、70-80msの待ち時間目標を維持するには他の待ち時間を短縮する必要がある例えば、一般的なインターネットを通る許容距離を短縮することができる。インターネット454、ユーザISP453及びユーザ家屋ルーティング452の往復待ち時間は、既に考慮されており、従って、残りは、ビデオ解凍458の待ち時間であり、これは、ビデオ解凍458が専用のハードウェアで具現化されるか、又はPC又は移動装置のようなクライアント装置415においてソフトウェアで具現化されるかに基づいて、又、ディスプレイのサイズ及び解凍CPUの性能に基づいて、変化する。典型的に、解凍458は、1ないし8msを要する。従って、実際上見られる最悪のケースの待ち時間を全部加算することにより、図4aに示すシステムのユーザにより経験されると予想できる最悪のケースの往復待ち時間を決定することができる。それらは、11252211668=80msである。そして、正に、実際に以下に述べる注意と共に、これは、図4aに示すシステムのプロートタイプバージョンを使用し、既製品のWindowsPCをクライアント装置として及び米国内の家庭用DSL及びケーブルモデム接続を使用して分かったおおよその往復待ち時間である。もちろん、最悪のケースより良好のシナリオでは、非常に短い待ち時間が得られるが、それは、広く使用される商業的サービスの開発に依存することができない。一般的なインターネットを経て図4bに列挙する待ち時間を得るには、図4aのビデオコンプレッサ404及びクライアント415のビデオデコンプレッサ412が、非常に特定の特性をもつパケットストリームを発生し、ホスティングサービス210からディスプレイ装置422までの全経路を経て発生されるパケットシーケンスが、遅延や過剰なパケットロスを受けず、且つ特に、WANインターフェイス442及びファイアウオール/ルーター/NAT443を通るユーザのインターネット接続を経てユーザに利用できる帯域巾の制約内に一貫して入るようにする必要がある。更に、ビデオコンプレッサは、通常のインターネット及びネットワーク送信において生じる不可避なパケットロス及びパケット並べ替えを許容できるに充分なほど頑丈なパケットストリームを生成しなければならない。短待ち時間のビデオ圧縮前記目標を達成するために、一実施形態は、待ち時間を減少し且つビデオを送信するためのピーク帯域巾要件を緩和するというビデオ圧縮の新規な解決策をとる。これらの実施形態を説明する前に、図5及び図6a-bを参照して、現在のビデオ圧縮技術の分析を行う。もちろん、これらの技術は、これらの技術で要求されるデータレートを取り扱うに充分な帯域巾がユーザに与えられる場合には、基礎的な原理に基づいて使用することができる。オーディオの圧縮は、ビデオの圧縮と同時に且つ同期して具現化されることを述べる以外、ここでは扱わないことに注意されたい。このシステムの要件を満足する従来のオーディオ圧縮技術が存在する。図5は、ビデオを圧縮するための1つの特定の従来技術であって、特定の圧縮アルゴリズムを使用する圧縮ロジック520により各個々のビデオフレーム501-503を圧縮して、一連の圧縮されたフレーム511-513を発生する従来技術を示している。この技術の一実施形態は、モーションJPEGであり、各フレームが、離散的コサイン変換DCTに基づき、ジョイントピクチャーエクスパートグループJPEG圧縮アルゴリズムに従って圧縮されるというものである。種々の異なる形式の圧縮アルゴリズムを使用してもよいが、これらの基礎的な原理例えば、JPEG-2000のようなウェーブレットベースの圧縮アルゴリズムに依然適合させるようにする。この形式の圧縮の1つの問題は、各フレームのデータレートを下げるが、連続フレーム間の類似性を利用してビデオストリーム全体のデータレートを下げるものでないことである。例えば、図5に示すように、映像の所与のクオリティに対し、640x480x24ビット/ピクセル=64048024/8/1024=900キロバイト/フレームKB/フレームのフレームレートを仮定すれば、モーションJPEGは、10のファクタでストリームを圧縮するだけであり、90KB/フレームのデータストリームを生じさせる。60フレーム/秒では、これは、90KB8ビット60フレーム/秒=42.2Mbpsのチャンネル帯域巾を要求し、これは、今日の米国内のほぼ全ての家庭用インターネット接続に対して遥かに広い帯域巾となり、且つ多数のオフィス用インターネット接続に対しても非常に広い帯域巾となる。実際に、このような広い帯域巾で一定のデータストリームを要求し、且つオフィスLAN環境においても1人のユーザにしか役立たないとすれば、100MbpsのイーサネットLAN帯域巾の大きな割合を消費し、LANをサポートするイーサネットスイッチに大きな負担を掛けることになる。従って、動画ビデオに対する圧縮は、以下に述べるような他の圧縮技術と比べたときに、非効率的である。更に、ロッシー圧縮アルゴリズムを使用するJPEG及びJPEG-2000のような単一フレーム圧縮アルゴリズムは、静止映像では気付かない圧縮欠陥例えば、シーンにおける密集した葉の中の欠陥は、その密集した葉がどのように見えるべきか目にとって厳密に分からないので、欠陥として見えないことがあるを生じる。しかし、シーンが動くと、欠陥が静止映像では気付かないシーンのエリアにあるにも関わらず、欠陥がフレームごとに変化することが目で検出されるので、欠陥が目立つようになる。その結果、余白的アナログTV受信中に見えるスノーノイズに見掛けが類似したバックグランドノイズがフレームのシーケンスにおいて知覚される。もちろん、この形式の圧縮は、ここに述べる幾つかの実施形態で依然使用できるが、一般的に述べると、シーンにおけるバックグランドノイズを回避するため、所与の知覚上のクオリティに対して高いデータレート即ち、低い圧縮比が要求される。H.264、又はWindowsMediaVC9、MPEG2及びMPEG4のような他の形式の圧縮は、全て、連続するフレーム間の類似性を利用しているので、ビデオストリームの圧縮がより効率的である。これらの技術は、全て、ビデオを圧縮するための同じ一般的技術に依存している。従って、H.264規格について述べるが、他の種々の圧縮アルゴリズムにも同じ一般的原理が適用される。圧縮H.264のためのx264オープンソースソフトウェアライブラリー、及び解凍H.264のためのFFmpegオープンソースソフトウェアライブラリーを含めて、非常に多数のH.264コンプレッサ及びデコンプレッサを利用することができる。図6a及び6bは、従来の圧縮技術を例示するもので、一連の非圧縮のビデオフレーム501-503、559-561が、圧縮ロジック620により、一連の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フレーム670は、Pフレームと同様であるが、Bフレームは、後続する基準フレームにおけるフレームと、先行する基準フレームにおける潜在的なフレームとを使用する。以下の説明では、望ましいフレームレートが60フレーム/秒であり、各Iフレームが約160Kbであり、平均Pフレーム及びBフレームが16Kbであり、そして毎秒新たなIフレームが発生されると仮定する。この1組のパラメータで、平均データレートは、160Kb16Kb59=1.1Mbpsとなる。このデータレートは、家庭及びオフィスへの多くの現在のブロードバンドインターネット接続に対する最大データレート内に充分入る。又、この技術は、イントラフレーム専用のエンコーディングからバックグランドノイズの問題を回避する傾向がある。というのは、P及びBフレームは、フレーム間の差を追跡し、圧縮欠陥がフレームごとに現れたり消えたりする傾向がなく、前記バックグランドノイズの問題を緩和するからである。前記形式の圧縮に伴う1つの問題は、平均データレートが比較的低い例えば、1.1Mbpsが、単一のIフレームが送信に多数のフレーム分の時間を要することである。例えば、従来技術を使用すると、60フレームごとに160KbpsのIフレームの状態で1.1Mbpsでビデオをストリーミングするのに、典型的に、2.2Mbpsのネットワーク接続例えば、図3aから2.2Mbpsピークの利用可能な最大データレート302をもつDSL又はケーブルモデムで充分である。これは、ビデオを解凍するまで解凍キューに1秒のビデオを入れておくことにより達成される。1秒で、1.1Mbのデータが送信され、これは、利用可能なデータレートが周期的に50程度下がると仮定しても、2.2Mbpsの利用可能な最大データレートによって容易に受け容れられる。不都合なことに、この従来の解決策は、1秒のビデオバッファが受信器にあるので、ビデオについて1秒の待ち時間を生じさせる。このような遅延は、多数の従来の用途例えば、リニアビデオの再生では充分であるが、70-80msを越える待ち時間を許容できない高速アクションのビデオゲームに対しては遥かに長い待ち時間である。1秒のビデオバッファを排除する試みがなされたが、高速アクションビデオゲームのための充分な待ち時間短縮が得られていない。一例として、上述したBフレームの使用は、Iフレームに先行する全てのBフレーム及びIフレームの受信を必要とする。PフレームとBフレームとの間で59個の非Iフレームがおおよそ分割されると仮定すれば、少なくとも29個のBフレームがあり、そしてBフレームを表示できるまでにIフレームが受信される。従って、チャンネルの利用可能な帯域巾に関わらず、各々1/60秒巾の291=30フレームの遅延、即ち500msの待ち時間が必要になる。明らかに、これは、遥かに長過ぎる。従って、別の解決策は、Bフレームを排除し、そしてI及びPフレームだけを使用することである。その1つの結果として、所与のクオリティレベルに対してデータレートが増加することになるが、この例における一貫性のために、各Iフレームが160Kbであり、平均Pフレームが16Kbのサイズであり、従って、データレートが依然1.1Mbpsであると仮定し続ける。この解決策は、Bフレームにより導入される不可避な待ち時間を排除する。というのは、各Pフレームのデコーディングが、以前に受信したフレームに依存するだけだからである。この解決策に伴う問題は、Iフレームが平均Pフレームより非常に大きいために、ほとんどの家庭及び多くのオフィスにおいて典型的である狭帯域巾チャンネルでは、Iフレームの送信が実質的な待ち時間を増大することである。これが図6bに示されている。Iフレームに要求されるピークデータレート623が、利用可能な最大データレート622を及び定格最大データレート621も遥かに越えるIフレームを除いて、ビデオストリームのデータレート624は、利用可能な最大データレート621より低い。Pフレームにより要求されるデータレートは、利用可能な最大データレート未満である。2.2Mbpsの利用可能な最大データレートのピークがその2.2Mbpsのピークレートに着実に保たれるとしても、Iフレームを送信するのに160Kb/2.2Mb=71msを要し、利用可能な最大データレート622が501.1Mbps下がった場合には、Iフレームを送信するのに142msを要する。従って、Iフレームを送信する際の待ち時間は、71から142msのどこかに入る。この待ち時間は、図4bに示された待ち時間に加算され、最悪の場合、これが70msに加算され、従って、これは、ユーザが入力装置421を操作する時点から、ディスプレイ装置422に映像が現れるまで、141ないし222msの合計往復待ち時間を生じ、遥かに高いものとなる。そして、利用可能な最大データレートが2.2Mbpsより下がる場合には、待ち時間は更に増大する。又、一般的に、ピークデータレート623でISPをジャミングさせて、利用可能なデータレート622を遥かに越える厳しい結果が生じることにも注意されたい。異なるISPの装置は、異なる挙動をするが、利用可能なデータレート622より非常に高いデータレートでパケットを受け取るときには、次の挙動がDSL及びケーブルモデムISPの間で極めて一般的となる。aパケットをキューイングすることでパケットを遅延させ待ち時間を導入し、bパケットの幾つか又は全部をドロップさせ、cある期間接続をディスエイブルするおそらく、ISPに関するものであるから、サービス拒絶攻撃のような悪意のある攻撃である。従って、図6bに示すような特性で全データレートにおいてパケットストリームを送信することは、実現可能な選択肢ではない。ピーク623は、ホスティングサービス210においてキューイングされ、そして利用可能な最大データレートより低いデータレートで送信され、上述した許容できない待ち時間を導入することがある。更に、図6bに示すビデオストリームデータレートシーケンス624は、非常に従順なビデオストリームデータレートシーケンスであり、そして著しく変化せず且つほとんど動きのないビデオシーケンスからビデオを圧縮することにより生じると予想される種類のデータレートシーケンスである例えば、カメラが固定位置にあってほとんど動かず、そしてシーン内のオブジェクト、例えば、椅子に座って話している人がほとんど動きを示さないビデオ遠隔会議において一般的であるように。図6cに示すビデオストリームデータレートシーケンス634は、動画又はビデオゲーム或いはあるアプリケーションソフトウェアにおいて発生されるような、遥かに多いアクションを伴うビデオから見えると予想されるものに対して典型的なシーケンスである。Iフレームピーク633に加えて、極めて大きく且つ多くの場合に利用可能な最大データレートを越える635及び636のようなPフレームピークもあることに注意されたい。これらのPフレームピークは、Iフレームピークと同程度に大きいことはあまりないが、全データレートでチャンネルにより搬送されるには遥かに大き過ぎるもので、又、Iフレームピークと同様に、Pフレームピークは、ゆっくり送信されねばならない従って、待ち時間が増大する。広帯域巾チャンネル例えば、100MbpsのLAN、又は広帯域巾100Mbpsのプライベート接続において、ネットワークは、Iフレームピーク633又はPフレームピーク636のような大きなピークを許容することができ、そして原理的に、短い待ち時間を維持することができる。しかし、このようなネットワークは、多くの場合、大勢のユーザ間に共有され例えば、オフィス環境において、そしてこのようなピークデータは、特に、ネットワークトラフィックがプライベート共有接続へルーティングされた場合に例えば、リモートデータセンターからオフィスへ、LANの性能に影響を及ぼす。先ず、この例は、60fpsにおいて640x480ピクセルの比較的低解像度のビデオストリームであることを銘記されたい。60fpsにおいて1920x1080のHDTVストリームは、近代的なコンピュータ及びディスプレイによって容易に取り扱われ、そして60fpsにおいて2560x1440解像度のディスプレイが益々入手可能になってきている例えば、アップル社の30ディスプレイ。又、60fpsにおいて1920x1080の高アクションビデオシーケンスは、適度なクオリティレベルに対してH.264圧縮を使用して4.5Mbpsを必要とする。公称データレートの10倍のIフレームピークを仮定すれば、それは45Mbps以下のピークを生じるが、まだかなりのPフレームピークがある。大勢のユーザが同じ100Mbpsのネットワーク例えば、オフィスとデータセンターとの間のプライベートなネットワーク接続を経てビデオストリームを受信する場合、大勢のユーザのビデオストリームからのピークがどのように整列して、ネットワークの帯域巾を圧倒し、そしてネットワーク上のユーザをサポートするスイッチのバックプレーンの帯域巾を潜在的に圧倒するか容易に見ることができる。ギガビットのイーサネットネットワークの場合でも、充分なユーザが充分なピークを一度に整列させる場合は、ネットワーク又はネットワークスイッチを圧倒することができる。そして、2560x1440解像度のビデオがより平凡なものになると、平均ビデオストリームデータレートが9.5Mbpsとなり、おそらく、95Mbpsのピークデータレートを生じさせる。言うまでもなく、データセンターとオフィスとの間の100Mbpsの接続これは、今日、非常に高速な接続であるは、単一ユーザからのピークトラフィックによって完全に沈没される。従って、LAN及びプライベートネットワーク接続が、ピークストリーミングビデオを更に許容できるとしても、高いピークを伴うストリーミングビデオは、望ましいものではなく、オフィスのIT部門による特殊なプランニング及び適応を要求する。もちろん、標準的なリニアビデオアプリケーションの場合、これらの事柄は、問題ではない。というのは、データレートが送信点において平滑化され、各フレームのデータが利用可能な最大データレート622より低く、そしてクライアントのバッファが、I、P及びBフレームのシーケンスを、それらが解凍されるまで記憶するからである。従って、ネットワークにわたるデータレートは、ビデオストリームの平均データレートの近くに保たれる。不都合なことに、これは、Bフレームが使用されない場合でも待ち時間を導入し、即ち高速応答時間を要求するビデオゲーム及びアプリケーションのような短待ち時間アプリケーションについては受け容れられない。高いピークを有するビデオストリームを軽減する1つの従来の解決策は、コンスタントビットレートCBRエンコーディングとしばしば称される技術を使用することである。CBRという語は、全てのフレームが同じビットレート即ち、サイズを有するように圧縮されることを意味すると思われるが、それが通常指すのは、ある数のフレームここでは、1フレームにわたり最大ビットレートが許されるという圧縮パラダイムである。例えば、図6cのケースでは、ビットレートを、定格最大データレート621の例えば70に制限するエンコーディングにCBR制約が適用される場合に、圧縮アルゴリズムは、定格最大データレート621の70以上を使用して通常圧縮されるフレームが少ないビットで圧縮されるように、各フレームの圧縮を制限する。その結果、所与のクオリティレベルを維持するために通常より多くのビットを要求するフレームがビットの欠乏となり、これらフレームの映像クオリティは、定格最大データレート621の70以上のビットを要求しない他のフレームの場合より悪くなる。この解決策は、a予想される動き又はシーンの変化があまりなく、且つbユーザが周期的なクオリティ低下を受け容れできるようなある形式の圧縮ビデオに対して、受け容れられる結果を生じさせることができる。CBRに適したアプリケーションの良い例は、ビデオ遠隔会議である。というのは、ピークが僅かしかなく、且つクオリティが短時間低下した場合に例えば、カメラがパンして、著しいシーンの動き及び大きなピークを生じ、そのパン中に、高クオリティ映像圧縮に充分なビットがなく、映像クオリティの低下を招く場合に、ほとんどのユーザにそれが受け容れられるからである。不都合なことに、CBRは、非常に複雑な又は多くの動きのあるシーンを有し、及び/又は適度な一定レベルのクオリティが要求される他の多数のアプリケーションにはあまり適していない。一実施形態に使用される短待ち時間の圧縮ロジック404は、高いクオリティを維持しながら短待ち時間の圧縮ビデオをストリーミングすることに伴うある範囲の問題に対処するために多数の異なる技術を使用する。第1に、短待ち時間の圧縮ロジック404は、Iフレーム及びPフレームしか発生せず、各Bフレームをデコードするために多数のフレーム分の時間を待機する必要性を緩和する。更に、図7aに示すように、一実施形態では、短待ち時間の圧縮ロジック404は、各非圧縮フレーム701-760を一連のタイルへと細分化し、そして各タイルをIフレーム又はPフレームのいずれかとして個々にエンコードする。圧縮されたIフレーム及びPフレームのグループは、ここでは、Rフレーム711-770と称される。図7aに示す特定例では、各非圧縮フレームが、16タイルの4x4マトリクスへと細分化される。しかしながら、これらの基礎的な原理は、特定の細分化スキムに限定されない。一実施形態では、短待ち時間の圧縮ロジック404は、ビデオフレームを多数のタイルに分割し、そして各フレームからの1つのタイルをIフレームとしてエンコード即ち、圧縮し即ち、タイルは、フル映像サイズの1/16の個別ビデオフレームであるかのように圧縮され、このミニフレームに使用される圧縮は、Iフレーム圧縮である、そして残りのタイルをPフレームとしてエンコード即ち、圧縮する即ち、1/16の各ミニフレームに使用される圧縮は、Pフレーム圧縮である。Iフレーム及びPフレームとして圧縮されるタイルは、各々、Iタイル及びPタイルと称される。各連続するビデオフレームでは、Iタイルとしてエンコードされるべきタイルが変化される。従って、所与のフレーム時間では、ビデオフレーム内のタイルのうちの1つのタイルだけが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タイルは、連続するフレームにわたり時間的に次々にインターリーブされる。このプロセスは、マトリクス内の最後のタイルがIタイル即ち、I15としてエンコードされてRタイル770が発生されるまで続く。次いで、このプロセスが再開されて、フレーム711のような別のRフレームを発生する即ち、タイル0に対してIタイルをエンコードし、等々。図7aには示されていないが、一実施形態では、Rフレームのビデオシーケンスのうちの第1のRフレームがIタイルしか含まない即ち、その後のPフレームが、動きを計算するための基準映像データを有するように。或いは又、一実施形態では、スタートアップシーケンスが、通常と同じIタイルパターンを使用するが、Iタイルでまだエンコードされていないタイルに対してPタイルを含まない。換言すれば、あるタイルは、第1の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の計算負担を増大すると思われるが、実際には、そうではない。というのは、タイルそれ自体は、付加的なプロセスの数に対し比例的に小さく、従って、表示されるピクセルの数は、1つのプロセスがあって従来のフルサイズのI及びPフレームを使用する場合と同じだからである。このRフレーム技術は、図6b及び6cに示したIフレームに典型的に関連した帯域巾ピークを著しく軽減する。というのは、所与のフレームが、大抵は、Iフレームより典型的に小さなPフレームで作られるからである。例えば、典型的なIフレームが160Kbであると再び仮定すれば、図7aに示す各フレームのIタイルは、この量のほぼ1/16即ち10Kbとなる。同様に、典型的なPフレームが16Kbであると仮定すれば、図7aに示す各タイルのPフレームは、ほぼ1Kbとなる。最終の結果として、ほぼ10Kb151Kb=25KbのRフレームとなる。従って、各60フレームシーケンスは、25Kb60=1.5Mbpsとなる。従って、60フレーム/秒では、これは、1.5Mbpsの帯域巾を維持することのできるチャンネルを要求するが、Iタイルのために相当に低いピークが60フレームインターバル全体にわたって分布される。Iフレーム及びPフレームに対して同じデータレートを仮定した先の例では、平均データレートが1.1Mbpsであったことに注意されたい。これは、先の例では、新たなIフレームが60フレームの時間ごとに一度しか導入されず、一方、この例では、16フレームの時間、ひいては、Iフレームに等しい時間でIフレームサイクルを作り上げる16個のタイルが16フレームの時間ごとに導入され、著しく高い平均データレートとなるからである。実際に、より頻繁にIフレームを導入しても、データレートを直線的に高めることはない。これは、Pフレーム又はPタイルが主として手前のフレームから次のフレームへの相違をエンコードするという事実のためである。従って、手前のフレームが次のフレームにかなり類似している場合には、Pフレームが非常に小さくなり、一方、手前のフレームが次のフレームとかなり相違がある場合には、Pフレームが非常に大きくなる。しかし、Pフレームは、主として、実際のフレームではなく、手前のフレームから導出されるので、それにより生じるエンコードされたフレームは、充分なビット数でIフレームより大きなエラー例えば、視覚欠陥を含むことができる。そして、1つのPフレームに別のPフレームが続くときには、エラーの蓄積が生じ、長いシーケンスのPフレームがあるときには悪化する。ここで、精巧なビデオコンプレッサは、一連のPフレームの後に映像のクオリティが低下することを検出し、必要に応じて、より多くのビットをその後続Pフレームに割り当てて、クオリティを上げるか、又はそれが最も効率的なアクションのコースである場合には、PフレームをIフレームに置き換える。従って、長いシーケンスのPフレーム例えば、上述した例のように59個のPフレームが使用されるとき、特に、シーンが多大な複雑さ及び/又は動きを有するときには、典型的に、PフレームがIフレームから更に離れるにつれて、より多くのビットがPフレームに必要とされる。或いは、Pフレームを逆の視点から見ると、Iフレームに接近して続くPフレームは、Iフレームから更に離れたPフレームよりビットを必要としない傾向がある。従って、図7aに示す例では、先行するIフレームから15フレーム以上離れたPフレームはなく、一方、先の例では、Pフレームは、Iフレームから59フレーム離れることができる。従って、より頻繁にIフレームがあると、Pフレームは、より小さくなる。もちろん、厳密な相対的サイズは、ビデオストリームの性質に基づいて変化するが、図7aの例では、Iタイルが10Kbである場合、Pタイルは、平均で、0.75Kbのみのサイズとなり、10Kb150.75Kb=21.25Kbとなるか、又は60フレーム/秒では、データレートは、21.25Kb60=1.3Mbpsとなり、又はIフレームの後に59個のPフレームが続く1.1Mbpsのストリームより約16高いデータレートとなる。この場合も、ビデオ圧縮に対するこれら2つの解決策間の相対的な結果は、ビデオシーケンスに基づいて変化するが、典型的に、Rフレームを使用すると、I/Pフレームシーケンスを使用する場合より、所与のクオリティレベルに対して約20多くのビットを要求することが実験で分かった。しかし、当然、Rフレームは、ピークを劇的に減少させ、I/Pフレームシーケンスより遥かに短い待ち時間でビデオシーケンスを使用可能にする。Rフレームは、ビデオシーケンスの性質、チャンネルの信頼性、及び利用できるデータレートに基づいて、種々の異なる仕方で構成することができる。別の実施形態では、4x4構成の16とは異なる数のタイルが使用される。例えば、2枚のタイルを2x1又は1x2構成で使用することができ、4枚のタイルを2x2、4x1又は1x4構成で使用することができ、6枚のタイルを3x2、2x3、6x1又は1x6構成で使用することができ、或いは8枚のタイルを4x2図7bに示すような、2x4、8x1又は1x8構成で使用することができる。タイルは、方形である必要がなく、又、ビデオフレームも、方形又は長方形である必要がないことに注意されたい。タイルは、使用するビデオフレーム及びアプリケーションに最も適した形状に分割することができる。別の実施形態では、I及びPタイルのサイクルがタイルの数に固定されない。例えば、8タイルの4x2構成では、図7bに示すように16サイクルシーケンスを依然使用することができる。順次の非圧縮フレーム721、722、723は、各々、8枚のタイル、0-7に分割され、各タイルが個々に圧縮される。Rフレーム731から、タイル0だけがIタイルとして圧縮され、残りのタイルは、Pタイルとして圧縮される。その後のRフレーム732については、8枚のタイル全部がPタイルとして圧縮され、次いで、その後のRフレーム733については、タイル1がIタイルとして圧縮され、そして他のタイル全部がPタイルとして圧縮される。従って、16個のフレームについてシーケンスが続き、Iタイルは、1つおきのフレームのみに発生され、最後のIタイルは、15番目のフレーム時間中にタイル7について発生され図7bには示さず、そして第16番目のフレーム時間中に、全Pタイルを使用してRフレーム780が圧縮される。次いで、タイル0がIタイルとして圧縮されそして他のタイルがPタイルとして圧縮されるようにしてシーケンスが再開される。先の実施形態と同様に、全ビデオシーケンスの各第1フレームは、典型的に、全てIタイルであり、その点から前方へのPタイルの基準を与える。Iタイル及びPタイルのサイクルは、タイルの数の偶数倍である必要がない。例えば、8枚のタイルでは、Iタイルをもつ各フレームの後に、全てPタイルをもつ2つのフレームが続き、その後に、別のIタイルが使用される。更に別の実施形態では、あるタイルは、例えば、スクリーンのあるエリアがより多くの動きを有し頻繁なIタイルを要求すると分かっているが、他のエリアはより静的であって例えば、ゲームのスコアを示す頻繁なIタイルをほとんど要求しない場合に、Iタイルが他のタイルより頻繁にある状態でシーケンスされる。更に、各フレームは、図7a-bにおいて単一のIタイルと共に示されているが、送信チャンネルの帯域巾に基づいて単一のフレーム内で複数のIタイルをエンコードすることもできる。逆に、あるフレーム又はフレームシーケンスを、Iタイルなしで即ち、Pタイルのみで送信することもできる。先の段落で述べた解決策が良く機能する理由は、各単一フレームにわたってIタイルを分布させないことで、大きなピークを生じると思われるが、システムの挙動は、そのように単純ではないことである。各タイルは、他のタイルとは個別に圧縮されるので、タイルが小さくなるほど、各タイルのエンコーディングは、効率的でなくなる。というのは、所与のタイルのコンプレッサが、他のタイルからの類似映像特徴及び類似の動きを利用できないためである。従って、スクリーンを16枚のタイルに分割すると、一般的に、スクリーンを8枚のタイルに分割する場合よりエンコーディングの効率が低下する。しかし、スクリーンが8枚のタイルに分割され、そして全Iフレームのデータを、16フレームごとではなく8フレームごとに導入させる場合には、全体的に非常に高いデータレートとなる。従って、8フレームごとではなく16フレームごとに全Iフレームを導入することにより、全体的なデータレートが減少される。又、16枚の小さなタイルではなく8枚の大きなタイルを使用することにより、全データレートが減少され、大きなタイルにより生じるデータピークをある程度軽減させる。別の実施形態では、図7a及び7bの短待ち時間のビデオ圧縮ロジック404は、Rフレームにおける種々のタイルへのビットの割り当てを、圧縮されるべきビデオシーケンスの既知の特性に基づく設定で予め構成することにより、或いは各タイルにおける映像クオリティの進行中の分析に基づいて自動的に、コントロールする。例えば、ある競争ビデオゲームでは、シーンにおいて比較的動きの少ないプレーヤの車の前部が、シーンの下半分の大部分を占有し、一方、シーンの上半分が、ほぼ常に動いている接近する道路、ビル及び風景で完全に埋められる。圧縮ロジック404が各タイルに等しい数のビットを割り当てる場合には、図7bの非圧縮フレーム721のスクリーンの下半分のタイルタイル4-7が、一般的に、図7bの非圧縮フレーム721のスクリーンの上半分のタイルタイル0-3より高いクオリティで圧縮される。この特定のゲーム又はゲームのこの特定のシーンがこのような特性を有すると分かっている場合には、ホスティングサービス210のオペレータは、スクリーンの下部のタイルよりスクリーンの上部のタイルにより多くのビットを割り当てるように圧縮ロジック404を構成することができる。或いは、圧縮ロジック404は、フレームが圧縮された後にピーク信号対雑音比PSNRのような多数の圧縮クオリティメトリックの1つ以上を使用してタイルの圧縮のクオリティを評価することができ、そしてある時間ウインドウにわたり、あるタイルが高いクオリティの結果を一貫して生じると決定する場合に、種々のタイルが同様のクオリティレベルに達するまで、低いクオリティの結果を生じるタイルにより多くのビットを徐々に割り当てる。別の実施形態では、圧縮ロジック404は、特定のタイル又はタイルのグループに高いクオリティを得るようにビットを割り当てる。例えば、スクリーンの縁より中心部のクオリティを高くするように全体的に良好な知覚上の見掛けを与えることができる。一実施形態では、ビデオストリームのある領域の解像度を改善するために、ビデオ圧縮ロジック404は、シーンの複雑さ及び/又は動きが比較的大きいビデオスクリーンのエリアを、シーンの複雑さ及び/又は動きが比較的小さいビデオスクリーンのエリアより小さいタイルを使用してエンコードする。例えば、図8に示すように、1つのRフレーム811の1つのエリア内の動くキャラクタ805の周りに小さなタイルが使用される潜在的に、その後に、同じタイルサイズをもつ一連のRフレーム図示せずが続く。次いで、キャラクタ805が映像の新たなエリアへ移動すると、図示されたように、別のRフレーム812内のこの新たなエリアの周りに小さなタイルが使用される。上述したように、これらの基礎的な原理に依然合致しながら、種々の異なるサイズ及び形状をタイルとして使用することができる。上述した循環するI/Pタイルは、ビデオストリームのデータレートのピークを実質的に減少するが、特に、動画、ビデオゲーム及びあるアプリケーションソフトウェアで発生する急速に変化する又は非常に複雑なビデオ映像の場合には、ピークを完全に排除することができない。例えば、突然のシーンの移行中に、複雑なフレームの後に、完全に異なる別の複雑なフレームが続くことがある。多数のIタイルが若干のフレームの時間だけシーンの移行に先行することがあっても、それらは、この状態において助けとならない。というのは、新たなフレーム資料が手前のIタイルと関係がないからである。このような状態及び何もかもが変化しなくても、多くの映像が変化する他の状態では、ビデオコンプレッサ404は、Pタイルの全部でなくてもその多くがIタイルとしてより効率的にコード化され、その結果、そのフレームに対するデータレートに非常に大きなピークが生じると決定する。上述したように、ほとんどの消費者グレードのインターネット接続及び多くのオフィス接続では、図6cに622として示す利用可能な最大データレートを越えるデータを定格最大データレート621と共にジャムすることが単純に実行できないケースがある。定格最大データレート621例えば、6MbpsDSLは、インターネット接続の購入を考えるユーザにとって本質的にマーケッティングナンバーであるが、一般的に、性能のレベルを保証するものではない。本発明の説明上、これは、無関係である。というのは、ビデオが接続を通してストリーミングされるときには、利用可能な最大データレート622だけが問題だからである。その結果、図9a及び9cにおいて、ピークの問題に対する解決策を説明するときに、定格最大データレートがグラフから削除され、利用可能な最大データレート922だけが示される。ビデオストリームデータレートは、利用可能な最大データレート922を越えてはならない。これに対処するために、ビデオコンプレッサ404が第1に実行すべきことは、チャンネルが着実に取り扱うことのできるデータレートであるピークデータレート941を決定することである。このレートは、多数の技術によって決定することができる。1つのこのような技術は、図4a及び4bにおいて、ホスティングサービス210からクライアント415へ次第に高いデータレートテストストリームを徐々に送信し、そしてクライアントがパケットロス及び待ち時間のレベルに関してホスティングサービスへフィードバックを与えるようにさせるものである。パケットロス及び/又は待ち時間が鋭い増加を示し始めるときには、それは、利用可能な最大データレート922に到達しつつあるという指示である。その後、ホスティングサービス210は、適度な期間中受け容れられるパケットロスレベルでテストストリームが受信され且つ待ち時間がほぼ最小であることをクライアント415が報告するまで、テストストリームのデータレートを徐々に減少することができる。これは、ピーク最大データレート941を確立し、これは、次いで、ストリーミングビデオのためのピークデータレートとして使用される。時間と共に、ピークデータレート941が変動し例えば、家の別のユーザがインターネット接続を激しく使用し始める場合に、そしてクライアント415は、それを常時監視して、パケットロス又は待ち時間が増大するかどうか調べる必要があり、利用可能な最大データレート922が以前に確立されたピークデータレート941より降下することを指示し、そしてもしそうであれば、ピークデータレート941を指示する。同様に、時間と共に、クライアント415は、パケットロス及び待ち時間が最適なレベルに保たれることを見つけた場合には、ビデオコンプレッサがデータレートをゆっくり増加して利用可能な最大データレートが増加したかどうか調べることを要求でき例えば、家の別のユーザがインターネット接続の激しい使用を止めた場合に、そして利用可能な最大データレート922を越えたことをパケットロス及び/又は長い待ち時間が指示し、ピークデータレート941に対して低いレベルを再び見つけることができるが、それがおそらく増加データレートのテストの前のレベルより高いものとなるまで、再び待機する。従って、この技術及びそれに類似した他の技術を使用することにより、ピークデータレート941を見つけて、必要に応じて、周期的に調整することができる。ピークデータレート941は、ユーザへビデオをストリーミングするためにビデオコンプレッサにより使用できる最大データレートを確立する。ピークデータレートを決定するためのロジックは、ユーザの家屋211及び/又はホスティングサービス210において具現化することができる。ユーザの家屋211において、クライアント装置415は、計算を行ってピークデータレートを決定し、そしてその情報をホスティングサービス210へ返送し、ホスティングサービス210において、ホスティングサービスのサーバー402は、クライアント415から受け取った統計情報例えば、パケットロス、待ち時間、最大データレート、等に基づいて、計算を行ってピークデータレートを決定する。図9aは、図7a、7b及び図8に示されて上述した循環I/Pタイル圧縮技術を使用して発生された実質的なシーンの複雑さ及び/又は動きを有するビデオストリームデータレート934を例示する。ビデオコンプレッサ404は、ピークデータレート941より低い平均データレートで圧縮ビデオを出力するように構成され、ほとんどの時間、ビデオストリームデータレートは、ピークデータレート941より低く保たれることに注意されたい。I/P/B又はI/Pフレームを使用して生成された図6cに示すビデオストリームデータレート634とデータレート934との比較は、循環I/Pタイル圧縮が非常に滑らかなデータレートを発生することを示している。更に、フレーム2xピーク952これは2xピークデータレート942に接近する及びフレーム4xピーク954これは4xピークデータレート944に接近するにおいて、データレートは、ピークデータレート941を越え、受け容れられない。実際に、迅速に変化するビデオゲームからの高アクションビデオでも、ピークデータレート941を越えるピークがフレームの2未満で発生し、2xピークデータレート942を越えるピークがまれに発生し、そして3xピークデータレート943を越えるピークはほとんど発生しない。しかし、それらが例えば、シーンの移行中に発生するときには、それらによって要求されるデータレートは、良好なクオリティのビデオ映像を発生するのに必要なものである。この問題を解決する1つの方法は、最大データレート出力がピークデータレート941となるようにビデオコンプレッサ404を単に構成することである。不都合なことに、それによりピークフレーム中に生じるビデオ出力のクオリティは、圧縮アルゴリズムがビットについて欠乏しているので、不充分である。その結果、突然の移行又は高速な動きがあるときに圧縮欠陥が現れ、やがて、ユーザは、突然の変化又は急速な動きがあるときに常に欠陥が現れ、それが極めて迷惑であることを悟る。人間の視覚系は、突然の変化又は急速な動きの間に現れる視覚上の欠陥には極めて敏感であるが、このような状態におけるフレームレートの減少の検出にはあまり敏感でない。実際に、このような突然の変化が生じたときに、人間の視覚系は、変化を追跡することに心を奪われ、フレームレートが短時間で60fpsから30fpsへ降下し、次いで、即座に60fpsへ復帰することに気付かないと思われる。そして、突然のシーンの切り換えのような非常に急激な移行の場合には、人間の視覚系は、フレームレートが20fps又は15fpsへ降下し、次いで、即座に60fpsへ戻ることに気付かない。観察する人間にとってフレームレートの減少が時々生じるだけである限り、ビデオは、60fpsで連続的に動作したかのように見える。人間の視覚系のこの特性は、図9bに示す技術により利用される。サーバー402図4a及び4bからのは、一定のフレームレート一実施形態では60fpsの非圧縮ビデオ出力ストリームを発生する。時間線は、各フレーム961-970を各々1/60秒で示している。各非圧縮ビデオフレームは、フレーム961でスタートして、短待ち時間のビデオコンプレッサ404へ出力され、これは、フレームを1フレーム時間未満で圧縮し、第1フレームとして圧縮フレーム1981を発生する。圧縮フレーム1981に対して発生されるデータは、上述したように、多数のファクタに基づいて大きくてもよいし小さくてもよい。データが、フレーム時間1/60秒内又はピークデータレート941未満でクライアント415へ送信できるに充分なほど小さい場合には、それが送信時間xmit時間991中に送信される矢印の長さは、送信時間の巾を示す。次のフレーム時間において、サーバー402は、非圧縮フレーム2962を発生し、これは、圧縮フレーム2982へと圧縮され、そしてピークデータレート941においてフレーム時間未満である送信時間992中にクライアント415へ送信される。次いで、次のフレーム時間に、サーバー402は、非圧縮フレーム3963を発生する。これがビデオコンプレッサ404により圧縮されると、それにより生じる圧縮フレーム3983は、1フレーム時間にピークデータレート941で送信できる以上のデータとなる。従って、それは、全フレーム時間と次のフレーム時間の一部分とを取り上げた送信時間2xピーク993中に送信される。ここで、次のフレーム時間中に、サーバー402は、別の非圧縮フレーム4964を発生し、それをビデオコンプレッサ404へ出力するが、データは、無視され、974で示されている。これは、ビデオコンプレッサ404が、手前の圧縮フレームをまだ送信している間に到着する更に別の非圧縮ビデオフレームを無視するように構成されているからである。もちろん、クライアント415のビデオデコンプレッサは、フレーム4を受信せず、2フレームの時間中、フレーム3をディスプレイ装置422に単に表示し続ける即ち、フレームレートを60fpsから30fpsへ簡単に減少する。次のフレーム5に対して、サーバー402は、非圧縮フレーム5965を出力し、これは、圧縮フレーム5985へと圧縮され、そして送信時間995中の1フレーム以内に送信される。クライアント415のビデオデコンプレッサは、フレーム5を解凍し、ディスプレイ装置422に表示する。次いで、サーバー402は、非圧縮フレーム6966を出力し、ビデオコンプレッサ404は、それを圧縮フレーム6986へと圧縮するが、このときには、得られるデータが非常に長い。圧縮フレームは、送信時間4xピーク996中にピークデータレート941で送信されるが、フレームを送信するのに、ほぼ4フレームの時間を要する。次の3フレームの時間中に、ビデオコンプレッサ404は、サーバー402からの3フレームを無視し、そしてクライアント415のデコンプレッサは、フレーム6を4フレームの時間中にディスプレイ装置422に着実に保持する即ち、フレームレートを60fpsから15fpsへ簡単に減少する。次いで、最終的に、サーバー402は、フレーム10970を出力し、ビデオコンプレッサ404は、それを圧縮フレーム10987へ圧縮し、これは、送信時間997中に送信され、そしてクライアント415のデコンプレッサは、フレーム10を解凍してディスプレイ装置422に表示し、そしてもう一度ビデオが60fpsで再開する。ビデオコンプレッサ404は、サーバー402により発生されたビデオストリームからビデオフレームをドロップするが、オーディオがどんな形態で到来するかに関わらずオーディオデータはドロップせず、ビデオフレームがドロップされるときにオーディオデータを圧縮し続けて、それらをクライアント415へ送信し、クライアントは、オーディオデータを解凍し続け、そしてオーディオを、ユーザにより使用される装置へ供給し、オーディオを再生することに注意されたい。従って、オーディオは、フレームがドロップされる期間中は非減衰状態を続ける。圧縮オーディオは、圧縮ビデオに比して、帯域巾の比較的僅かな割合を消費するだけであり、その結果、全体的なデータレートに大きな影響は及ぼさない。いずれのデータレート図にも示されていないが、ピークデータレート941内で圧縮オーディオストリームに対して常にデータレート容量が予約されている。図9bについて上述した例は、データレートピーク中にフレームレートがいかに降下するか示すために選択されたものであるが、先に述べた循環I/Pタイル技術が使用されるときに、そのようなデータレートピーク及びそれによりドロップされるフレームは、ビデオゲーム、動画及びあるアプリケーションソフトウェアにおいて生じるような高いシーン複雑さ/高いアクションのシーケンス中でもまれであることは、示されていない。従って、フレームレートの減少は、時々で且つ短時間であり、人間の視覚系は、それを検知しない。上述したフレームレート減少メカニズムが、図9aに示すビデオストリームデータレートに適用される場合に、それにより生じるビデオストリームデータレートが図9cに示されている。この例では、2xピーク952が平坦な2xピーク953へ減少され、4xピーク955が平坦な4xピーク955へ減少され、そして全ビデオストリームデータレート934がピークデータレート941以下に保たれる。従って、上述した技術を使用して、高アクションビデオストリームを、一般的なインターネット及び消費者グレードのインターネット接続を通して短い待ち時間で送信することができる。更に、LAN例えば、100Mbsイーサネット又は802.11gワイヤレス、或いはプライベートネットワーク例えば、データセンターとオフィスとの間の100Mbps接続におけるオフィス環境では、高アクションビデオストリームをピークなしに送信することができ、大勢のユーザ例えば、4.5Mbpsにおいて60fpsで1920x1080を送信するが、ネットワーク又はネットワークスイッチバックプレーンを圧倒する重畳ピークをもたずに、LAN又は共有プライベートデータ接続を使用できるようにする。データレートの調整一実施形態では、ホスティングサービス210は、最初、利用可能な最大データレート622及びチャンネルの待ち時間にアクセスして、ビデオストリームのための適当なデータレートを決定し、次いで、それに応答してデータレートを動的に調整する。データレートを調整するために、ホスティングサービス210は、例えば、映像の解像度、及び/又はクライアント415へ送信されるビデオストリームのフレーム数/秒を変更することができる。又、ホスティングサービスは、圧縮ビデオのクオリティレベルを調整することもできる。ビデオストリームの解像度を、例えば、1280x720解像度から640x360へ変更するときに、クライアント415のビデオ解凍ロジック412は、ディスプレイスクリーン上に同じ映像サイズを維持するように映像をスケールアップすることができる。一実施形態では、チャンネルが完全にドロップアウトする状況において、ホスティングサービス210は、ゲームを休止する。マルチプレーヤゲームの場合には、ホスティングサービスは、ユーザがゲームからドロップアウトしたことを他のユーザに報告し、及び/又は他のユーザに対してゲームを休止する。ドロップ又は遅延したパケット一実施形態において、図4a又は4bにおけるビデオコンプレッサ404とクライアント415との間のパケットロスのために、或いはパケットが順序ずれして受け取られて、解凍するには遅過ぎ且つ解凍フレームの待ち時間要件を満足するには遅過ぎる到着であるために、データが失われる場合に、ビデオ解凍ロジック412は、視覚上の欠陥を軽減することができる。ストリーミングI/Pフレーム具現化において、失われ/遅延したパケットがある場合には、スクリーン全体に影響が及び、潜在的に、ある期間中スクリーンを完全に凍結させるか、又は他のスクリーン巾の視覚上の欠陥を表示させる。例えば、失われ/遅延したパケットがIフレームの損失を生じさせる場合には、デコンプレッサは、それに続く全てのPフレームに対する基準を、新たなIフレームが受け取られるまで欠くことになる。Pフレームが失われた場合には、それに続く全スクリーンのためのPフレームに影響を及ぼすことになる。Iフレームが現れるまでどれほど長いかに基づき、これは、長い又は短い視覚上の影響となる。図7a及び7bに示すインターリーブされたI/Pタイルを使用すると、失われ/遅延したパケットは、スクリーン全体に影響を及ぼすおそれが非常に僅かになる。というのは、影響を受けるパケットに含まれたタイルにしか影響しないからである。各タイルのデータが個々のパケット内で送信される場合には、パケットが失われた場合に、それが1つのタイルにしか影響しない。もちろん、視覚上の欠陥の巾は、Iタイルパケットが失われるかどうか、及びPタイルが失われた場合には、Iタイルが現れるまでにどれほど多くのフレームを要するか、に依存する。しかし、スクリーン上の異なるタイルがIフレームで頻繁に潜在的にフレームごとに更新されるとすれば、スクリーン上の1つのタイルが影響を受ける場合でも、他のタイルは、そうではない。更に、ある事象が一度に多数のパケットのロスを生じさせる場合には例えば、DSLラインに続く電力のスパイクでデータ流を短時間中断するもの、あるタイルが、他のタイル以上に影響を受けるが、あるタイルは、新たなIタイルで素早く更新されるので、短時間影響を受けるだけである。又、ストリーミングI/Pフレーム具現化では、Iフレームが最も重要なフレームであるだけでなく、非常に大きなフレームでもあり、従って、ドロップされ/遅延されたパケットを生じさせる事象がある場合には、Iフレームが影響を受ける確率が、非常に小さなIタイルより高くなる即ち、Iフレームが一部分でも失われた場合には、Iフレームを解凍できる見込みが全くなくなる。これら全ての理由で、I/Pタイルを使用すると、パケットがドロップされ/遅延されるときに、視覚上の欠陥は、I/Pフレームの場合より遥かに少なくなる。一実施形態では、圧縮されたタイルをTCP送信コントロールプロトコルパケット又はUDPユーザデータグラムプロトコルパケット内にインテリジェントにパッケージすることにより失われたパケットの作用を減少することが試みられる。例えば、一実施形態では、タイルが、可能であれば、パケット境界に整列される。図10aは、この特徴を具現化せずに、タイルを一連のパケット1001-1005内にどのようにパックするか示す。より詳細には、図10aにおいて、単一パケットのロスが複数のフレームのロスを生じるように、タイルがパケット境界に交差し、非効率的にパックされる。例えば、パケット1003または1004が失われる場合に、3つのタイルが失われ、視覚上の欠陥を招く。対称的に、図10bは、パケットロスの作用を減少するためにパケット内にタイルをインテリジェントにパッキングするためのタイルパッキングロジック1010を示す。第1に、タイルパッキングロジック1010は、タイルをパケット境界に整列させる。従って、タイルT1、T3、T4、T7及びT2は、各々、パケット1001-1005の境界に整列される。又、タイルパッキングロジックは、パケット境界に交差せずに、考えられる最も効率的な仕方で、パケット内にタイルを嵌合させることも試みる。各タイルのサイズに基づいて、タイルT1及びT6は、1つのパケット1001内で合成され、T3及びT5は、1つのパケット1002内で合成され、タイルT4及びT8は、1つのパケット1003内で合成され、タイルT8は、パケット1004に追加され、そしてタイルT2は、パケット1005に追加される。従って、このスキムのもとでは、単一パケットのロスは、図10aに示す3つのタイルではなく2つ以下のタイルのロスを招くことになる。図10bに示す実施形態に対する1つの付加的な利益は、タイルが、映像内に表示されるのとは異なる順序で送信されることである。このように、隣接パケットが送信を妨げる同じ事象から失われた場合に、スクリーン上の互いに近隣でないエリアに影響を及ぼし、ディスプレイ上の欠陥をあまり目立たなくする。一実施形態では、順方向エラー修正FEC技術を使用して、ビデオストリームの幾つかの部分をチャンネルエラーから保護する。この技術で知られているように、リードソロモン及びビタビのようなFEC技術は、エラー修正データ情報を発生して、通信チャンネルを経て送信されるデータに添付させる。基礎的なデータ例えば、Iフレームにエラーが発生した場合には、FECを使用して、エラーを修正することができる。FECコードは、送信のデータレートを高め、従って、理想的には、それらが最も必要とされるところに使用されるだけである。非常に目立つ視覚上の欠陥を生じないデータが送信される場合には、データを保護するためにFECコードを使用しないのが好ましい。例えば、失われるIタイルの直前のPタイルは、スクリーン上に1/60秒だけ視覚上の欠陥を生じさせる即ち、スクリーン上のタイルは更新されない。このような視覚上の欠陥は、人間の目でかろうじて検知できる。PタイルがIタイルから更に後方にある場合には、Pタイルを失うと、益々目立つことになる。例えば、タイルサイクルパターンが、Iタイルの後に15個のPタイルが続き、その後、Iタイルが再び得られるというものである場合、Iタイルの直後のPタイルが失われると、そのタイルは、15フレームの時間中誤った映像を示すことになる60fpsでは、それは、250msである。人間の目は、250ms間のストリームの中断は容易に検知する。従って、Pタイルが新たなIタイルから更に後方にあるほど即ち、Pタイルがより接近してIタイルに続くほど、欠陥がより目立ったものになる。上述したように、一般的に、Pタイルがより接近してIタイルに続くほど、そのPタイルに対するデータがより小さくなる。従って、Iタイルに続くPタイルは、失われないよう保護するのがより重要であるだけでなく、サイズが小さいことも重要である。そして、一般的に、保護される必要のあるデータが小さいほど、それを保護するために必要なFECコードも小さくなる。従って、図11aに示すように、一実施形態では、ビデオストリームにおけるIタイルの重要性のために、IタイルだけにFECコードが与えられる。従って、FEC1101は、Iタイル1100に対するエラー修正コードを含み、そしてFEC1104は、Iタイル1103に対するエラー修正コードを含む。この実施形態では、Pタイルに対してFECは発生されない。図11bに示す一実施形態では、失われた場合に視覚上の欠陥を生じさせるおそれが最もあるPタイルについてもFECコードが発生される。この実施形態では、FEC1105は、最初の3つのPタイルに対してエラー修正コードを与えるが、それに続くPタイルについては与えない。別の実施形態では、データサイズが最も小さいPタイルについてFECコードが発生されるIタイルの後に最も早く発生して、保護することが最も重要なPタイルを自己選択する傾向がある。別の実施形態では、FECコードをタイルと共に送信するのではなく、タイルが2回、そのたびに異なるパケットで、送信される。1つのパケットが失われ/遅延された場合には、他のパケットが使用される。図11cに示す一実施形態では、FECコード1111及び1113は、ビデオと同時にホスティングサービスから送信されるオーディオパケット1110及び1112に対して各々発生される。ビデオストリームにおいてオーディオの完全性を維持することが特に重要である。というのは、歪んだオーディオ例えば、カチカチ音又はスー音は、特に望ましからぬユーザの経験を招くからである。FECコードは、オーディオコンテンツがクライアントコンピュータ415において歪なくレンダリングされることを保証する上で助けとなる。別の実施形態では、FECコードをオーディオデータと共に送信するのではなく、オーディオデータが2回、そのたびに異なるパケットで、送信される。1つのパケットが失われ/遅延された場合には、他のパケットが使用される。更に、図11dに示す一実施形態では、クライアント415からホスティングサービス210へと上流に送信されるユーザ入力コマンド1120及び1122例えば、ボタン押圧に対してFECコード1121及び1123が各々使用される。これは重要である。というのは、ビデオゲーム又はアプリケーションにおいてボタン押圧又はマウス移動が欠落すると、望ましからぬユーザ経験を招くからである。別の実施形態では、FECコードをユーザ入力コマンドデータと共に送信するのではなく、ユーザ入力コマンドデータが2回、そのたびに異なるパケットで、送信される。1つのパケットが失われ/遅延された場合には、他のパケットが使用される。一実施形態では、ホスティングサービス210がクライアント415との通信チャンネルのクオリティを評価して、FECを使用すべきかどうか決定し、もしそうであれば、ビデオ、オーディオ及びユーザコマンドのどの部分にFECを適用すべきか決定する。チャンネルのクオリティを評価することは、上述したように、パケットロス、待ち時間、等を評価するようなファンクションを含む。チャンネルに特に信頼性がない場合には、ホスティングサービス210は、Iタイル、Pタイル、オーディオ及びユーザコマンドの全てにFECを適用することができる。対照的に、チャンネルに信頼性がある場合には、ホスティングサービス210は、オーディオ及びユーザコマンドのみにFECを適用するか、又はオーディオ又はビデオにFECを適用するか、或いはFECを全く使用しない。これら基礎的な原理に依然合致しながら、FECの適用の種々の他の順列を使用することができる。一実施形態では、ホスティングサービス210は、チャンネルの状態を常時監視し、それに応じてFECポリシーを変更する。別の実施形態では、図4a及び4bを参照すれば、パケットが失われ/遅延されてタイルデータを失うことになるか、又はおそらく特に悪いパケット損失のために、FECが、失われたタイルデータを修正できない場合には、クライアント415は、新たなIタイルが受け取られる前にどれほど多くのフレームが残っているか評価し、それをクライアント415からホスティングサービス210への往復待ち時間と比較する。その往復待ち時間が、新たなIタイルが当然到着するまでのフレームの数より少ない場合には、クライアント415は、新たなIタイルを要求するメッセージをホスティングサービス210へ送信する。このメッセージは、ビデオコンプレッサ404へルーティングされ、このコンプレッサは、データが失われたところのタイルに対してPタイルを発生するのではなく、Iタイルを発生する。図4a及び4bに示すシステムが、典型的に80ms未満の往復待ち時間を与えるように設計されているとすれば、それにより、タイルが80ms以内に修正される60fpsにおいて、フレームは、16.67msの巾であり、従って、全フレームの時間において、80msの待ち時間で、5フレームの時間である83.33ms以内にタイルが修正され、即ち、これは、目立った中断であるが、例えば、15フレームに対する250msの中断よりは遥かに目立たないものである。コンプレッサ404がその通常の循環順序からIタイルを発生するときに、Iタイルによりそのフレームの帯域巾が利用可能な帯域巾を越える場合は、コンプレッサ404は、他のタイルのサイクルを遅延させて、他のタイルがそのフレーム時間中にPタイルを受け取るようにし1つのタイルが通常そのフレーム中に当然Iタイルであるべき場合でも、次いで、次のフレームでスタートして、通常の循環が続き、そして通常はその手前のフレームでIタイルを受信するタイルが、Iタイルを受信するようにする。このアクションは、Rフレーム循環の位相を短時間遅延するが、通常は、視覚上、目立つものではない。ビデオ及びオーディオコンプレッサ/デコンプレッサ具現化図12は、マルチコア及び/又はマルチプロセッサ1200を使用して8枚のタイルを並列に圧縮する1つの特定の実施形態を示す。一実施形態では、2.66GHz以上で動作するデュアルプロセッサクオドコアXeonCPUコンピュータシステムが使用され、各コアは、オープンソースx264H.264コンプレッサを独立プロセスとして具現化する。しかしながら、これら基礎的な原理に依然合致しながら、種々の他のハードウェア/ソフトウェアコンフィギュレーションが使用されてもよい。例えば、CPUコアの各々を、FPGAで具現化されるH.264コンプレッサに置き換えることができる。図12に示す例では、コア1201-1208を使用して、Iタイル及びPタイルを8個の独立したスレッドとして同時に処理する。この技術で良く知られているように、現在のマルチコア及びマルチプロセッサコンピュータシステムは、本来、MicrosoftWindowsXPプロフェッショナルエディション64ビット又は32ビットエディション及びLinuxのようなマルチスレッドオペレーティングシステムと一体化されたときにマルチスレッディング可能である。図12に示す実施形態では、8個のコアの各々は、1つのタイルについてのみ役立つので、x264の個別インスタンス生成を各々実行する他のコアとは主として独立して動作する。PCIExpressx1ベースのDVI捕獲カード、例えば、オランダ、オーステルハウトのマイクロトロニクスからのセンデロビデオイメージングIPデベロープメントボードを使用して、640x480、800x600、又は1280x720解像度で非圧縮ビデオを捕獲し、そしてこのカードのFPGAは、直接メモリアクセスDMAを使用して、DVIバスを経て捕獲されたビデオをシステムRAMへと転送する。タイルは、4x2配列1205に配列されるそれらは、方形タイルとして示されているが、この実施形態では、160x240解像度である。x264の各インスタンス化は、8個の168x240タイルの1つを圧縮するように構成され、そしてそれらは、最初のIタイル圧縮の後に、各コアがサイクルに入り、各1つのフレームが他のフレームと位相ずれし、1つのIタイル、その後、7つのPタイルを圧縮するように、図12に示すように、同期される。フレーム時間ごとに、得られた圧縮されたタイルが、上述した技術を使用して、パケットストリームへと合成され、次いで、その圧縮されたタイルが、行先クライアント415へ送信される。図12には示されていないが、合成される8枚のタイルのデータレートが特定のピークデータレート941を越える場合には、その合成される8枚のタイルのデータが送信されてしまうまで必要に応じて多数のフレームの時間中、全部で8x264のプロセスが保留される。一実施形態では、クライアント415は、FFmpegの8個のインスタンスを実行するPCにおいてソフトウェアとして具現化される。受信プロセスは、8枚のタイルを受信し、そして各タイルは、FFmpegへルーティングされ、これは、タイルを解凍して、ディスプレイ装置422上の適当なタイル位置にレンダリングする。クライアント415は、PCの入力装置ドライバからキーボード、マウス、又はゲームコントローラ入力を受け取り、そしてそれをサーバー402へ送信する。サーバー402は、次いで、その受け取った入力装置データを、サーバー402で実行されるゲーム又はアプリケーションに適用し、サーバー402は、Intel2.16GHzCoreDuoCPUを使用してWindowsを実行するPCである。次いで、サーバー402は、新たなフレームを発生し、そしてそのDVI出力を通して、マザーボードベースのグラフィックシステムから、或いはNVIDIA8800GTXPCIエクスプレスカードのDVI出力を通して、それを出力する。同時に、サーバー402は、ゲーム又はアプリケーションにより形成されたオーディオを、そのデジタルオーディオ出力例えば、S/PDIFを通して出力し、これは、ビデオ圧縮を具現化するデュアルクオドコアXeonベースPCのデジタルオーディオ入力に結合される。Vorbisオープンソースオーディオコンプレッサは、プロセススレッドに対して利用可能なコアを使用して、オーディオをビデオと同時に圧縮するように使用される。一実施形態では、タイルの圧縮を完了するコアが、オーディオ圧縮を最初に実行する。圧縮されたオーディオは、次いで、圧縮されたビデオと共に送信され、そしてクライアント415においてVorbisオーディオデコンプレッサを使用して解凍される。ホスティングサービスサーバーセンター配布光ファイバのようなガラスを通る光は、真空中の光の速度の一部分で進行し、従って、光ファイバにおける光の厳密な伝播速度を決定することができる。しかし、実際には、ルーティング遅延の時間、送信の非効率さ、及び他のオーバーヘッドを考慮すると、インターネット上の最適な待ち時間は、光速のほぼ50の送信速度を反映することが観察される。従って、最適な1000マイル往復待ち時間は、約22msであり、そして最適な3000マイル往復待ち時間は、約64msである。従って、米国の一方の海岸にある単一のサーバーは、3000マイル程度離れた他方の海岸にあるクライアントに望ましい待ち時間でサービスするには離れ過ぎている。しかしながら、図13aに示すように、ホスティングサービス210のサーバーセンター1300が、米国の中央部例えば、カンザス、ネブラスカ、等に位置されて、米国大陸の任意の点までの距離が約1500マイル以下となる場合には、往復インターネット待ち時間を32ms程度に小さくすることができる。図4bを参照すれば、ユーザISP453に許された最悪のケースの待ち時間は、典型的に、25msであるが、DSL及びケーブルモデムシステムでは、10から15msに近い待ち時間が観察されていることに注意されたい。又、図4bは、ユーザの家屋211からホスティングセンター210までの最大距離が1000マイルであると仮定している。従って、15msの典型的なユーザISP往復待ち時間が使用され、32msの往復待ち時間に対して1500マイルの最大インターネット距離では、ユーザが入力装置421を操作しそしてディスプレイ装置422上に応答を見る点からの合計往復待ち時間は、11153211668=80msとなる。従って、80msの応答時間が、典型的に、1500マイルのインターネット距離にわたって得られる。これは、米国大陸において充分短いユーザISP待ち時間453をもつユーザの家屋が、中央部に位置する単一のサーバーにアクセスできるようにする。図13bに示した別の実施形態では、ホスティングサービス210のサーバーセンターHS-1ないしHS6が、米国又は他の地理的領域に戦略的に配置され、ある大きなホスティングサービスサーバーセンター例えば、HS2及びHS5は、人口の多いセンターの付近に配置される。一実施形態では、サーバーセンターHS1ないしHS6は、インターネット又はプライベートネットワーク或いはその両方の組合せであるネットワーク1301を経て情報を交換する。複数のサーバーセンターがある状態では、長いユーザISP待ち時間453をもつユーザに対して短い待ち時間でサービスを提供することができる。インターネット上の距離は、確実に、インターネットを通しての往復待ち時間に貢献するファクタであるが、時々、待ち時間にあまり関係のない他のファクタが影響するようになる。時々、パケットストリームがインターネットを通して離れた位置へルーティングされそして再び戻り、長いループから待ち時間を招く。時々、適切に動作しないルーティング装置が経路上にあり、送信遅延を招く。時々、経路に過負荷となるトラフィックがあって、遅延を導入する。そして、時々、ユーザのISPが所与の行先へルーティングされるのを全く阻止する故障が生じる。従って、一般的なインターネットは、通常、距離により主として決定される非常に信頼性のある最適なルート及び待ち時間で特に、ユーザのローカルエリアの外部へのルートを生じさせる長距離接続で、ある点から別の点への接続を与えるが、このような信頼性及び待ち時間は、保証されるものではなく、多くの場合、ユーザの家屋から一般的なインターネット上の所与の行先まで得ることができない。一実施形態では、ユーザクライアント415が、最初にホスティングサービス210に接続して、ビデオゲームをプレイするか又はアプリケーションを使用するときに、クライアントは、始動時に利用可能なホスティングサービスサーバーセンターHS1ないしHS6の各々と通信する例えば、上述した技術を使用して。特定の接続に対して待ち時間が充分短い場合には、その接続が使用される。一実施形態では、クライアントは、最短待ち時間接続をもつものが選択されたところのホスティングサービスサーバーセンターの全部又はサブセットと通信する。クライアントが最短待ち時間接続をもつサービスセンターを選択してもよいし、又はサービスセンターが最短的時間接続をもつものを識別しそしてこの情報を例えば、インターネットアドレスの形態でクライアントに与えてもよい。特定のホスティングサービスサーバーセンターが過負荷状態になり及び/又はユーザのゲーム又はアプリケーションが、別の負荷の少ないホスティングサービスサーバーセンターへの待ち時間を許容できる場合には、クライアント415は、他のホスティングサービスサーバーセンターに向け直される。このような状況では、ユーザが実行しているゲーム又はアプリケーションは、ユーザの過負荷状態にサーバーセンターにおけるサーバー402上で休止され、そしてゲーム又はアプリケーションの状態データは、別のホスティングサービスサーバーセンターにおけるサーバー402へ転送される。次いで、ゲーム又はアプリケーションが再開される。一実施形態では、ホスティングサービス210は、ゲーム又はアプリケーションが自然の休止点例えば、ゲームにおけるレベル間、又はユーザがアプリケーションにおいてセーブオペレーションを開始した後に到達して転送を行うまで、待機する。更に別の実施形態では、ホスティングサービス210は、ユーザのアクティビティが特定の期間中例えば1分間休止するまで待機し、次いで、その時点で転送を開始する。上述したように、一実施形態では、ホスティングサービス210は、そのクライアントに保証された待ち時間を与えるよう試みるために、図14のインターネットバイパスサービス440に契約する。ここで使用されるインターネットバイパスサービスとは、保証された特性例えば、待ち時間、データレート、等をもつインターネットにおいてある点から別の点へのプライベートネットワークルートを与えるサービスである。例えば、ホスティングサービス210が、ATTのサンフランシスコベースの中央オフィスへのルーティングではなく、サンフランシスコで提供されるATTのDSLサービスを利用してユーザから大量のトラフィックを受信した場合に、ホスティングサービス210は、サンフランシスコベースの中央オフィスと、ホスティングサービス210のための1つ以上のサービスセンターとの間のサービスプロバイダーおそらくATTそれ自体又は別のプロバイダーから大容量のプライベートデータ接続をリースすることができる。次いで、全てのホスティングサービスサーバーセンターHS1ないしHS6から一般的なインターネットを経てATTのDSLを使用するサンフランシスコのユーザへのルートが非常に長い待ち時間を生じる場合には、それに代わって、プライベートデータ接続を使用することができる。プライベートデータ接続は、一般的に、一般的なインターネットを通るルートより費用が高いが、それがユーザへのホスティングサービス210接続の僅かな割合に保たれる限り、全コストへの影響は低く、ユーザは、より一貫したサービスを経験することになる。サービスセンターは、多くの場合、停電時に2層のバックアップ電源を有する。第1の層は、典型的に、バッテリから又は発電機に取り付けられてランニング状態に保たれるフライホイールのような別の直ちに利用できるエネルギー源からのバックアップ電源であって、主電源が停電したときに直ちに電力を供給して、サーバーセンターをランニング状態に保持する。停電が短時間で、主電源が素早く例えば、1分以内に回復する場合には、バッテリは、全て、サーバーセンターをランニング状態に保持するために必要とされる。しかし、停電が長期間である場合には、典型的に、発電機例えば、ジーゼル付勢が始動され、バッテリを引き継いで、燃料がある限り運転することができる。このような発電機は、サーバーセンターが通常主電源から得るのと同程度の電力を発生できねばならないので、非常に高価である。一実施形態では、ホスティングサービスHS1ないしHS5の各々は、互いにユーザデータを共有し、1つのサーバーセンターが停電した場合に、進行中のゲーム及びアプリケーションを休止し、次いで、ゲーム又はアプリケーションの状態データを各サーバー402から他のサーバーセンターのサーバー402へ転送し、そして各ユーザのクライアント415に通知して、新たなサーバー402と通信するように指令する。このような状態が頻繁に生じないとすれば、最適な待ち時間を与えることのできないホスティングサービスサーバーセンターへのユーザの転送を受け容れることができ即ち、ユーザは、単に停電期間中に長い待ち時間を許容するだけでよく、これは、ユーザを転送するための非常に広範囲のオプションを許す。例えば、米国を横切る時間ゾーン差が与えられると、東海岸のユーザは、PM11時30分には就寝するが、PM8時30分の西海岸のユーザは、ビデオゲームの使用がピークになり始めている。その時間に西海岸のホスティングサービスサーバーセンターに停電が生じた場合に、他のホスティングサービスサーバーセンターには、全てのユーザを取り扱うに充分な西海岸サーバー402が存在しないことがある。このような状況では、利用できるサーバー402を有する東海岸のホスティングサービスサーバーセンターへあるユーザを転送することができ、それらユーザに対してのみ長い待ち時間となる。ユーザが、停電したサーバーセンターから転送されると、サーバーセンターは、次いで、そのサーバー及び装置の整然とした遮断を開始し、バッテリ又は他の即座の電源バックアップが尽きるまでに全ての装置を遮断することができる。このように、サーバーセンター用の発電機のコストを回避することができる。一実施形態では、ホスティングサービス210の激しい負荷の時間中にピークユーザ負荷によるか、又は1つ以上のサーバーセンターが停電したために、ユーザは、彼等が使用しているゲーム又はアプリケーションの待ち時間要件に基づいて他のサーバーセンターへ転送される。従って、短待ち時間を要求するゲーム又はアプリケーションを使用しているユーザは、電源に制限があるときに、利用可能な短待ち時間サーバー接続への優先権が与えられる。ホスティングサービスの特徴図15は、以下の特徴説明に使用されるホスティングサービス210のためのサーバーセンターのコンポーネントの実施形態を示す。図2aに示されたホスティングサービス210と同様に、サーバーセンターのコンポーネントは、特に指示のない限り、ホスティングサービス210の制御システム401により制御され整合される。ユーザクライアント415からのインバウンドインターネットトラフィック1501は、インバウンドルーティング1502に向けられる。典型的に、インバウンドインターネットトラフィック1501は、インターネットへの高速光ファイバ接続を経てサーバーセンターに入るが、適当な帯域巾、信頼性及び短待ち時間のネットワーク接続手段で充分である。インバウンドルーティング1502は、ネットワークネットワークは、イーサネットネットワーク、ファイバチャンネルネットワークとして、或いは他の搬送手段を経て具現化できるスイッチ、及びスイッチをサポートするルーティングサーバーのシステムであり、これは、到着するパケットを取り上げ、そして各パケットを適当なアプリケーション/ゲームapp/gameサーバー1521-1525へルーティングする。一実施形態では、特定のapp/gameサーバーに配送されるパケットは、クライアントから受信されたデータのサブセットを表し、及び/又はデータセンター内の他のコンポーネント例えば、ゲートウェイ及びルーターのようなネットワークコンポーネントによって変換/変更されてもよい。あるケースでは、例えば、ゲーム又はアプリケーションが複数のサーバー上で並列に一度実行される場合に、パケットが一度に2つ以上のサーバー1521-1525へルーティングされる。RAIDアレイ1511-1512は、インバウンドルーティングネットワーク1502へ接続され、app/gameサーバー1521-1525がそれらRAIDアレイ1511-1512の読み取り及び書き込みを行えるようにする。更に、RAIDアレイ1515複数のRAIDアレイとして具現化できるも、インバウンドルーティング1502に接続され、RAIDアレイ1515からのデータは、app/gameサーバー1521-1525から読み出すことができる。インバウンドルーティング1502は、インバウンドインターネットトラフィック1501を根にもつスイッチのツリー構造、全ての種々の装置を相互接続するメッシュ構造、或いは相互通信装置間の集中トラフィックが他の装置間の集中トラフィックから分離されるようにして相互接続された一連のサブネットを含めて、広範囲な従来のネットワークアーキテクチャーで具現化することができる。ネットワークコンフィギュレーションの一形式は、SANであり、これは、典型的に記憶装置として使用されるが、装置間の一般的な高速データ転送に使用することもできる。又、app/gameサーバー1521-1525は、各々、インバウンドルーティング1502への複数のネットワーク接続を有する。例えば、サーバー1521-1525は、RAIDアレイ1511-1512に取り付けられたサブネットへのネットワーク接続と、他の装置に取り付けられたサブネットへの別のネットワーク接続とを有することができる。app/gameサーバー1521-1525は、図4aに示す実施形態におけるサーバー402に関して上述したように、全部が同じに、幾つかが異なるように、又は全部が異なるように構成されてもよい。一実施形態では、各ユーザは、ホスティングサービスを利用するときに、典型的に、少なくとも1つのapp/gameサーバー1521-1525を使用する。説明を簡略化するため、所与のユーザがapp/gameサーバー1521を使用すると仮定するが、1人のユーザが複数のサーバーを使用することができると共に、複数のユーザが単一のapp/gameサーバー1521-1525を共有することができる。上述したようにクライアント415から送られるユーザ制御入力は、インバウンドインターネットトラフィック1501として受け取られ、そしてインバウンドルーティング1502を通してapp/gameサーバー1521へルーティングされる。app/gameサーバー1521は、ユーザの制御入力を、サーバー上で実行されるゲーム又はアプリケーションへの制御入力として使用し、そしてビデオ及びそれに関連したオーディオの次のフレームを計算する。次いで、app/gameサーバー1521は、非圧縮のビデオ/オーディオ1529を共有ビデオ圧縮1530へ出力する。app/gameサーバーは、非圧縮のビデオを、1ギガビット以上のイーサネット接続を含む手段を経て出力できるが、一実施形態では、ビデオがDVI接続を経て出力され、そしてオーディオ及び他の圧縮並びに通信チャンネル状態情報は、ユニバーサルシリアルバスUSB接続を経て出力される。共有ビデオ圧縮1530は、app/gameサーバー1521ないし1525からの非圧縮ビデオ及びオーディオを圧縮する。圧縮は、完全にハードウェアで具現化されてもよいし、又はハードウェア実行ソフトウェアで具現化されてもよい。各app/gameサーバー1521ないし1525に対する専用コンプレッサがあってもよいし、又はコンプレッサが充分高速である場合には、所与のコンプレッサを使用して、2つ以上のapp/gameサーバー1521ないし1525からのビデオ/オーディオを圧縮することができる。例えば、60fpsでは、ビデオフレーム時間は、16.67msである。コンプレッサがフレームを1msで圧縮できる場合には、そのコンプレッサを使用して、16個程度のapp/gameサーバー1521ないし1525からのビデオ/オーディオを圧縮することができ、これは、あるサーバーからの入力を別のサーバーの後に取り上げ、コンプレッサが各ビデオ/オーディオ圧縮プロセスの状態をセーブし、そしてコンテクストを、それがサーバーからのビデオ/オーディオストリーム間で循環するときにスイッチすることにより行われる。その結果、圧縮ハードウェアにおいて実質的なコスト節約が得られる。異なるサーバーが異なる時間にフレームを完了するので、一実施形態では、コンプレッサリソースが、各圧縮プロセスの状態を記憶するための共有記憶手段例えば、RAM、フラッシュと共に共有プール1530にあり、サーバー1521-1525のフレームが完了して圧縮の準備ができると、制御手段は、どの圧縮リソースがそのとき利用できるか決定し、圧縮リソースに、サーバーの圧縮プロセスの状態と、圧縮すべき非圧縮ビデオ/オーディオのフレームとを与える。各サーバーの圧縮プロセスの状態の一部分は、圧縮それ自体に関する情報、例えば、Pタイルの基準として使用できる以前のフレームの解凍フレームバッファデータ、ビデオ出力の解像度;圧縮のクオリティ;タイル構造;タイル当たりのビットの割り当て;圧縮のクオリティ、オーディオフォーマット例えば、ステレオ、サラウンドサウンド、Dolby登録商標、AC-3を含むことに注意されたい。しかし、圧縮プロセスの状態は、ピークデータレート941に関する通信チャンネル状態情報、以前のフレーム図9bに示すが現在出力されるかどうかその結果、現在フレームを無視すべきかどうか、そして潜在的に、圧縮に考慮すべきチャンネル特性、例えば、圧縮の判断に影響する過剰なパケットロス例えば、Iタイルの頻度、等に関してがあるかどうか、も含む。クライアント415から送られるデータを監視する各ユーザをサポートするapp/gameサーバー1521-1525により決定されるように、ピークデータレート941又は他のチャンネル特性が時間と共に変化するときに、app/gameサーバー1521-1525は、共有ハードウェア圧縮1530へ関連情報を送信する。又、共有ハードウェア圧縮1530は、上述したような手段を使用して、圧縮されたビデオ/オーディオをパケット化し、そしてもし適当であれば、FECコードを適用し、あるデータを複写し、又は他のステップを行って、ビデオ/オーディオデータストリームをクライアント415により受信しそしてできるだけ高いクオリティ及び信頼性で解凍するという能力を充分に確保するようにする。以下に述べるような幾つかのアプリケーションでは、所与のapp/gameサーバー1521-1525のビデオ/オーディオ出力を同時に複数の解像度で又は他の複数のフォーマットで得られることが要求される。従って、app/gameサーバー1521-1525が共有ハードウェア圧縮1530のリソースを通知する場合には、そのapp/gameサーバー1521-1525の非圧縮ビデオ/オーディオ1529が、異なるフォーマット、異なるリソース、及び/又は異なるパケット/エラー修正構造で同時に圧縮される。あるケースでは、幾つかの圧縮リソースを、同じビデオ/オーディオを圧縮する複数の圧縮プロセス間で共有することができる例えば、多くの圧縮アルゴリズムには、圧縮を適用する前に映像を複数のサイズにスケーリングするステップがある。異なるサイズの映像を出力することが要求される場合に、このステップを使用して、一度に多数の圧縮プロセスに応じることができる。他のケースでは、フォーマットごとに個別の圧縮リソースが要求される。いずれにせよ、所与のapp/gameサーバー1521-1525に要求される全ての種々の解像度及びフォーマットの圧縮されたビデオ/オーディオ1539は、1つであっても多数であってもアウトバウンドルーティング1540へ一度に出力される。一実施形態では、圧縮されたビデオ/オーディオ1539の出力はUDPフォーマットであり、従って、パケットの位置方向性ストリームである。アウトバウンドルーティングネットワーク1540は、圧縮された各ビデオ/オーディオストリームを、アウトバウンドインターネットトラフィック1599インターフェイスこれは、典型的に、インターネットへのファイバインターフェイスに接続されるを通して意図されたユーザ1人又は複数又は他の行先へ向け、及び/又は遅延バッファ1515へ戻し、及び/又はインバウンドルーティング1502へ戻し、及び/又はビデオ配布のためにプライベートネットワーク図示せずを通して向ける一連のルーティングサーバー及びスイッチを備えている。以下に述べるようにアウトバウンドルーティング1540は、所与のビデオ/オーディオストリームを一度に複数の行先へ出力できることに注意されたい。一実施形態では、これは、一度に複数の行先へストリーミングされることが意図された所与のUDPストリームをブロードキャストし、そしてこのブロードキャストをアウトバウンドルーティング1540内のルーティングサーバー及びスイッチにより繰り返すようなインターネットプロトコルIPマルチキャストを使用して具現化される。ブロードキャストの複数の行先は、インターネットを経て複数のユーザのクライアント415、インバウンドルーティング1502を経て複数のapp/gameサーバー1521-1525、及び/又は1つ以上の遅延バッファ1515である。従って、所与のサーバー1521-1522の出力は、1つ又は複数のフォーマットへ圧縮され、そして各圧縮されたストリームは、1つ又は複数の行先へ向けられる。更に、別の実施形態では、複数のapp/gameサーバー1521-1525が1人のユーザにより同時に使用され例えば、複雑なシーンの3D出力を生成するために並列処理構成でそして各サーバーが出来上がる映像の一部分を発生する場合には、複数のサーバー1521-1525のビデオ出力を共有ハードウェア圧縮1530により合成フレームへと合成することができ、そしてその点以降は、それが単一のapp/gameサーバー1521-1525から到来したかのように、上述したように取り扱われる。一実施形態では、app/gameサーバー1521-1525により発生される全ビデオのコピー少なくともユーザが見るビデオの解像度又はそれ以上が、少なくとも数分一実施形態では、15分、遅延バッファ1515に記録されることに注意されたい。これは、各ユーザが、以前の働き又は成績ゲームの場合を再検討するために各セッションからビデオを巻き戻しできるようにする。従って、一実施形態では、ユーザクライアント415へルーティングされる圧縮された各ビデオ/オーディオ出力1539のストリームは、遅延バッファ1515へもマルチキャストされる。ビデオ/オーディオが遅延バッファ1515に記憶されるときには、遅延バッファ1515のディレクトリが、遅延されたビデオ/オーディオのソースであるapp/gameサーバー1521-1525のネットワークアドレスと、遅延されたビデオ/オーディオを見つけることのできる遅延バッファ1515上の位置との間の相互参照を与える。生の、瞬時に見られる、瞬時にプレイ可能なゲームapp/gameサーバー1521-1525は、ユーザのための所与のアプリケーション又はビデオゲームを実行するのに使用できるだけでなく、ホスティングサービス210によるナビゲーション及び他の特徴をサポートするホスティングサービス210のためのユーザインターフェイスアプリケーションを生成するのにも使用できる。1つのこのようなユーザインターフェイスアプリケーションのスクリーンショットが図16に示されており、即ちゲームファインダースクリーンである。この特定のユーザインターフェイススクリーンは、ユーザが、他のユーザにより生で又は遅延されてプレイされている15のゲームを見ることができるようにする。1600のようなサムネールビデオウインドウの各々は、動きのある生のビデオウインドウで、1人のユーザのゲームからのビデオを示している。サムネールに示される視野は、ユーザが見ている同じ視野でもよいし、遅延された視野でもよい例えば、ユーザがコンバットゲームをプレイする場合、ユーザは、自分がどこに隠れているか他のユーザから見えるのを望まず、又、ゲームプレイの視野を、ある期間、例えば、10分遅らせることを選択してもよい。又、視野は、ユーザの視野とは異なるゲームのカメラ視野でもよい。メニュー選択肢この図には示さずを通して、ユーザは、種々の基準に基づいて、一度に見るゲームの選択を選ぶことができる。例示的選択の小さな例として、ユーザは、図16に示すようなゲームのランダムな選択、異なるプレーヤにより全てプレイされる一種類の全てのゲーム、ゲームのトップランクプレーヤのみ、ゲームの所与のレベルのプレーヤ、低いランクのプレーヤ例えば、プレーヤが基礎を学習している場合、相棒又はライバルであるプレーヤ、視聴者の最も多いゲーム、等を選ぶことができる。一般的に、各ユーザは、自分のゲーム又はアプリケーションからのビデオが他人に見られるかどうか判断し、もしそうであれば、どんな他人、いつ他人に見られるか、遅れて見られるだけかどうか、判断することに注意されたい。図16に示すユーザインターフェイススクリーンを発生するapp/gameサーバー1521-1525は、ゲームが要求される各ユーザについてapp/gameサーバー1521-1525へメッセージを送信することにより15個のビデオ/オーディオフィードを取得する。このメッセージは、インバウンドルーティング1502又は別のネットワークを通して送信される。このメッセージは、要求されたビデオ/オーディオのサイズ及びフォーマットを含み、ユーザインターフェイススクリーンを見ているユーザを識別する。所与のユーザは、プライバシーモードを選択し、他のユーザが彼のゲームのビデオ/オーディオを彼の視点又は別の視点から見るのを許さないことを選ぶか、或いは前記段落で述べたように、ユーザは、彼のゲームからのビデオ/オーディオを見るのを許すが、見るビデオ/オーディオを遅らせることを選んでもよい。ビデオ/オーディオを見ることを許すための要求を受け取って受け容れるユーザapp/gameサーバー1521-1525は、要求側サーバーに確認を送り、共有ハードウェア圧縮1530に、要求されたフォーマット又はスクリーンサイズで付加的な圧縮されたビデオストリームを発生する要求も通知しフォーマット及びスクリーンサイズが、既に発生されたものとは異なると仮定すれば、そしてその圧縮されたビデオの行先即ち、要求側サーバーも指示する。要求されたビデオ/オーディオが遅延されるだけである場合には、要求側app/gameサーバー1521-1525は、そのように通知され、そして遅延バッファ1515のディレクトリにおけるビデオ/オーディオの位置と、遅延されたビデオ/オーディオのソースであるapp/gameサーバー1521-1525のネットワークアドレスとをルックアップすることにより、遅延バッファ1515から遅延されたビデオ/オーディオを取得する。これらの要求が全て発生されて処理されると、15までの生のサムネールサイズのビデオストリームが、アウトバウンドルーティング1540から、app/gameサーバー1521-1525へのインバウンドルーティング1502へルーティングされて、ユーザインターフェイススクリーンを発生し、そしてサーバーにより解凍されて表示される。遅延されたビデオ/オーディオストリームは、スクリーンサイズが大き過ぎることがあり、もしそうであれば、app/gameサーバー1521-1525は、ストリームを解凍して、ビデオストリームをサムネールサイズへスケールダウンする。一実施形態では、オーディオ/ビデオのための要求が、図4aのホスティングサービス制御システムと同様の中央管理サービス図15には示さずへ送られ及びそれにより管理され、これは、次いで、その要求を適当なapp/gameサーバー1521-1525へ向け直す。更に、一実施形態では、サムネールが、それを許すユーザのクライアントへプッシュされるので、要求が発せられないこともある。全て同時に混合される15個のゲームからのオーディオは、不快な音を発することがある。ユーザは、このように全ての音を一緒に混合することを選んでもよいしおそらく、見ている全てのアクションにより生じる騒音の感覚を単に得るために、又はユーザは、一度に1つのゲームからのオーディオのみを聞くことを選んでもよい。単一ゲームの選択は、黄色の選択ボックス1601図16の白黒レンダリングでは、黒い長方形の輪郭として現われるを所与のゲームへ移動することにより達成される黄色のボックスの移動は、キーボード上の矢印キーを使用するか、マウスを移動するか、ジョイスティックを動かすか、又は移動電話のような別の装置の方向ボタンを押すことにより達成できる。単一のゲームが選択されると、そのゲームからのオーディオだけが再生される。又、ゲーム情報1602も示される。このゲームの場合には、例えば、発行者ロゴ例えば、電子アートについては、EA及びゲームロゴ、例えば、NeedforSpeedCarbon、及びオレンジの水平バー図16では、縦縞をもつバーとしてレンダリングされるは、その特定の瞬間にゲームをプレイするか又は見ている人々の数を相対的な表現で指示するこの場合は、多数、従って、ゲームは、ホット。更に、スタッツ即ち、統計値も設けられ、これは、145人のプレーヤがNeedforSpeedGameの80個の異なるインスタンス化を能動的にプレイしており即ち、個人プレーヤゲーム又はマルチプレーヤゲームのいずれかによりプレイできる、そして680人の視聴者がいるこのユーザは、そのうちの1人であることを示している。これらの統計値及び他の統計値は、ホスティングサービス210のオペレーションのログを保持すると共に、ユーザに適宜請求し、又、コンテンツを提供する発行者に支払するために、ホスティングサービス制御システム401により収集され、そしてRAIDアレイ1511-1512に記憶される。統計値のあるものは、サービス制御システム401によりアクションによって記録され、そしてあるものは、個々のapp/gameサーバー1521-1525によりサービス制御システム401へ報告される。例えば、このゲームファインダーアプリケーションを実行するapp/gameサーバー1521-1525は、ゲームを見ているとき及びゲームを見終えたときホスティングサービス制御システム401へメッセージを送信し、どれほど多くのゲームが見られているかの統計値を更新できるようにする。統計値のあるものは、このゲームファインダーアプリケーションのようなユーザインターフェイスアプリケーションに利用される。ユーザは、入力装置のアクチベーションボタンをクリックした場合に、フルスクリーンサイズへの生のビデオのプレイを続けながら黄色のボックス内のサムネールビデオをズームアップして見ることができる。この効果が図17のプロセスに示されている。ビデオウインドウ1700は、サイズが増大していることに注意されたい。この効果を具現化するために、app/gameサーバー1521-1525は、選択されたゲームを実行しているapp/gameサーバー1521-1525から、そこにルーティングされたゲームのフルスクリーンサイズのビデオストリームのコピーを取ることを要求するユーザのディスプレイ装置422の解像度で。ゲームを実行しているapp/gameサーバー1521-1525は、共有ハードウェアコンプレッサ1530に、ゲームのサムネールサイズのコピーがもはや必要ない別のapp/gameサーバー1521-1525がそのようなサムネールを要求しない限りことを通知し、次いで、ビデオのフルスクリーンサイズコピーを、ビデオをズームしているapp/gameサーバー1521-1525へ送信することを指令する。ゲームをプレイしているユーザは、ゲームをズームアップしているユーザと同じ解像度のディスプレイ装置422を有していても、いなくてもよい。更に、ゲームを見る他の者も、ゲームをズームアップしているユーザと同じ解像度のディスプレイ装置422を有していても、いなくてもよい且つ異なるオーディオ再生手段、例えば、ステレオ又はサラウンドサウンドを有してもよい。従って、共有ハードウェアコンプレッサ1530は、ビデオ/オーディオストリームを要求しているユーザの要件を満足する適当に圧縮されたビデオ/オーディオストリームが既に発生されたかどうか決定し、もしそれが存在する場合には、ビデオをズームしているapp/gameサーバー1521-1525へストリームのコピーをルーティングするようにアウトバウンドルーティング1540に通知し、又、もしそうでなければ、そのユーザに適したビデオの別のコピーを圧縮して、ビデオをズームしているapp/gameサーバー1521-1525及びインバウンドルーティング1502へストリームを返送するようにアウトバウンドルーティングに命令する。選択されたビデオのフルスクリーンバージョンを現在受信しているこのサーバーは、それを解凍し、フルサイズまで徐々にスケールアップする。図18は、ゲームがフルスクリーンへ完全にズームアップされた後にスクリーンがどのように見えるか示しており、ゲームは、矢印1800で指された映像により示すように、ユーザのディスプレイ装置422の全解像度で示されている。ゲームファインダーアプリケーションを実行しているapp/gameサーバー1521-1525は、もはや必要でないサムネールを発生した他のapp/gameサーバー1521-1525へメッセージを送信すると共に、他のゲームがもはや見られていないホスティングサービス制御サーバー401へメッセージを送信する。この点において、発生される表示は、スクリーンの頂部にあって、情報及びメニュー制御をユーザに与えるオーバーレイ1801である。このゲームが進行するにつれて、観衆は、2503人の視聴者まで増加したことに注意されたい。このように大勢の視聴者では、同じ又はほぼ同じ解像度をもつディスプレイ装置422に大勢の視聴者が結び付けられる各app/gameサーバー1521-1525は、適合性を調整するためにビデオをスケーリングする能力を有する。図示されたゲームは、マルチプレーヤゲームであるから、ユーザは、ある点でゲームに加わることを決定できる。ホスティングサービス210は、種々の理由で、ユーザがゲームに加わるのを許しても許さなくてもよい。例えば、ユーザは、ゲームをプレイするために支払しなければならず、又、プレイしないことを選んでもよく、ユーザは、その特定のゲームに加わるに充分なランキングを有していないことがあり例えば、他のプレーヤとの競争に耐えない、或いはユーザのインターネット接続は、ユーザがプレイするのに充分な短い待ち時間を有していないことがある例えば、ゲームを見るための待ち時間制約がなく、従って、遠くで実際上、別の大陸でプレイされるゲームを、待ち時間の問題なしに見ることはできるが、プレイするゲームについては、待ち時間は、aゲームを楽しむために、及びb短い待ち時間接続を有する他のプレーヤと平等の立場であるために、ユーザにとって充分短いものでなければならない。ユーザがプレイを許された場合には、ユーザに対してゲームファインダーユーザインターフェイスを与えたapp/gameサーバー1521-1525は、ホスティングサービス制御サーバー401が、特定のゲームをプレイするために適当に構成されたapp/gameサーバー1521-1525を始動して即ち、探索し始動して、RAIDアレイ1511-1512からゲームをロードし、次いで、ホスティングサービス制御サーバー401が、ゲームを現在ホストしているapp/gameゲームサーバーへユーザから制御信号を転送するようにインバウンドルーティング1502に命令すると共に、ゲームファインダーアプリケーションをホストしたapp/gameサーバーからのビデオ/オーディオを圧縮することから、ゲームを現在ホストしているapp/gameサーバーからのビデオ/オーディオを圧縮することへスイッチするように共有ハードウェアコンプレッサ1530に命令することを要求する。ゲームファインダーapp/gameサービス、及びゲームをホストしている新たなapp/gameサーバーの垂直同期は、同期されず、その結果、2つの同期間におそらく時間差が生じる。共有ビデオ圧縮ハードウェア1530は、app/gameサーバー1521-1525がビデオフレームを完成したときにビデオの圧縮を開始するので、新たなサーバーからの第1のフレームは、古いサーバーのフルフレーム時間より早期に完成され、これは、その手前の圧縮されたフレームがその送信を完了する前である例えば、図9bの送信時間992を考えると、非圧縮フレーム3963がフレーム時間の半分早期に完成された場合に、送信時間992に影響を及ぼす。このような状況では、共有ビデオ圧縮ハードウェア1530は、新たなサーバーからの第1のフレームを無視し例えば、フレーム4964が無視されるのと同様に、クライアント415は、古いサーバーからの最後のフレームを特別のフレーム時間中保持し、そして共有ビデオ圧縮ハードウェア1530は、ゲームをホストする新たなapp/gameサーバーからの次のフレーム時間ビデオの圧縮を開始する。視覚上、あるapp/gameサーバーから他のapp/gameサーバーへの移行は、シームレスである。ホスティングサービス制御サーバー401は、次いで、ゲームファインダーをホストしていたapp/gameゲームサーバー1521-1525に、それが再び必要になるまでアイドル状態にスイッチするように通知する。次いで、ユーザは、ゲームをプレイすることができる。そして、何が優れているかと言えば、ゲームは、知覚上即座にプレイされギガビット/秒の速度でRaidアレイ1511-1512からapp/gameゲームサーバー1521-1525にロードされるので、そしてゲームは、理想的なドライバ、レジストリ構成Windowsの場合をもち、且つゲームのオペレーションと競合し得るサーバーで実行される他のアプリケーションをもたずに、ゲームに対して厳密に構成されたオペレーティングシステムと一緒にゲームに厳密に適したサーバーにロードされる。又、ユーザがゲームを通して進行するにつれて、ゲームの各セグメントが、RAIDアレイ1511-1512からギガビット/秒の速度でサーバーへロードされ即ち、1ギガバイトの負荷が8秒で、そしてRAIDアレイ1511-1512の膨大な記憶容量のためにこれは多数のユーザ間の共有リソースであるから、非常に大きく、又、コスト効率がよい、幾何学的な設定又は他のゲームセグメント設定を予め計算して、RAIDアレイ1511-1512に記憶し、そして非常に迅速にロードすることができる。更に、各app/gameサーバー1521-1525のハードウェア構成及び計算能力が既知であるから、ピクセル及び頂点シェーダーを予め計算することができる。従って、ゲームは、ほぼ瞬間的に始動し、理想的な環境で実行され、そしてその後のセグメントがほぼ瞬間的にロードされる。しかし、これらの効果を越えて、ユーザは、ゲームをプレイする他人を見ることができ上述したゲームファインダー及び他の手段を経て、そしてゲームに関心があるかどうか判断し、もしそうであれば、他人を見ることから秘訣を学習することができる。そして、ユーザは、大きなダウンロード及び/又はインストールを待機する必要なく、ゲームを瞬時にデモすることができ、又、ユーザは、おそらく、僅かな費用の試行ベースで、又は長期間ベースで、ゲームを瞬時にプレイすることができる。そして、ユーザは、ゲームを、ウインドウズPC、マッキントッシュ、家のTV受像機で、又、旅行中も、移動電話で、充分短い待ち時間のワイヤレス接続によりプレイすることができる見物するだけでは、待ち時間は問題にならないが。又、これは、全て、ゲームのコピーを物理的に所持せずに行うことができる。上述したように、ユーザは、自分のゲームプレイを他人に見られることを許さないか、自分のゲームを遅延の後に見られるのを許すか、自分のゲームを選択されたユーザにより見られるのを許すか、又は自分のゲームを全てのユーザにより見られるのを許すかを判断することができる。それにも関わらず、ビデオ/オーディオは、一実施形態では、15分間、遅延バッファ1515に記憶され、そしてユーザは、デジタルビデオレコーダDVRでTVを見ていたときに行うことができたのと同様に、自分の以前のゲームプレイを巻き戻して見ることができ、又、休止し、スローで再生し、早送りし、等々を行うことができる。この例では、ユーザは、ゲームをプレイするが、ユーザがアプリケーションを使用する場合には、同じDVR能力を利用することができる。これは、以前の行動を再検討すること及び以下に述べる他のアプリケーションでも有用である。更に、カメラの視野を変更できる、等のように、ゲーム状態情報の利用に基づいて巻き戻することができるようにゲームが設計されている場合は、この3DDVR能力もサポートされるが、それをサポートするようにゲームを設計することが要求される。遅延バッファ1515を使用するDVR能力は、もちろん、ゲーム又はアプリケーションが使用されたときに発生するビデオに限定して、ゲーム又はアプリケーションと共に機能するが、3DDVR能力をもつゲームの場合には、ユーザは、以前にプレイしたセグメントの3Dにおけるフライスルーを制御することができ、そしてそれにより得られるビデオを遅延バッファ1515で記録させ、ゲームセグメントのゲーム状態を記録させることができる。従って、特定のフライスルーが、圧縮されたビデオとして記録されるが、ゲーム状態も記録されるので、後日、ゲームの同じセグメントについて異なるフライスルーが考えられることになる。以下に述べるように、ホスティングサービス210におけるユーザは、各々、彼等に関する情報及び他のデータを掲示することのできるユーザページを有する。ユーザが掲示することのできるものの中には、彼等がセーブしたゲームプレイからのビデオセグメントがある。例えば、ユーザがゲームにおいて特に困難な挑戦を克服した場合には、ユーザは、ゲームにおいて偉大な成果をなし得た点の直前まで巻き戻し、次いで、他のユーザが見るために、ある時間巾例えば、30秒のビデオセグメントをユーザのユーザページにセーブするようにホスティングサービス210に命令することができる。これを達成するには、ユーザが、遅延バッファ1515に記憶されたビデオをRAIDアレイ1511-1512へ再生してユーザのユーザページにおいてそのビデオセグメントをインデックスするように使用するという、単なるapp/gameサーバー1521-1525の問題である。ゲームが、上述した3DDVRの能力を有する場合には、3DDVRに要求されるゲーム状態情報もユーザによって記録して、ユーザのユーザページに利用することができる。能動的なプレーヤに加えて観客即ち3Dの世界を進んで、アクションに関与せずにそれを観察できるユーザをもつようにゲームが設計されている場合には、ゲームファインダーアプリケーションは、ユーザが観客及びプレーヤとしてゲームに加わることができるようにする。具現化の視点から、ユーザが能動的なプレーヤではなく観客である場合も、ホスティングシステム210に対して差はない。ゲームは、app/gameサーバー1521-1525にロードされ、そしてユーザは、ゲームを制御する例えば、世界を見るバーチャルカメラを制御する。唯一の相違は、ユーザのゲーム経験である。複数ユーザの協力ホスティングサービス210の別の特徴は、複数のユーザが、大きく異なる視聴装置を使用していても、生のビデオを見ながら協力する能力である。これは、ゲームをプレイするとき及びアプリケーションを使用するときの両方に有用である。多くのPC及び移動電話は、ビデオカメラを装備しており、且つ特に、映像が小さいときには、リアルタイム映像圧縮を行う能力を有している。又、テレビに取り付けることのできる小型カメラも入手でき、リアルタイム圧縮を、ソフトウェアで具現化するか、又はビデオを圧縮するための多数のハードウェア圧縮装置の1つを使用して具現化するのは、困難なことではない。又、多数のPC及び全ての移動電話は、マイクロホンを有し、又、マイクロホンと共にヘッドセットが利用できる。このようなカメラ及び/又はマイクロホンは、ローカルのビデオ/オーディオ圧縮能力特に、ここに述べる短待ち時間のビデオ圧縮技術を使用すると合成されると、ユーザが、ユーザの家屋211からのビデオ及び/又はオーディオを入力装置の制御データと共にホスティングサービス210へ送信できるようにする。このような技術が使用されるときには、図19に示す能力を達成でき、即ちユーザは、自分のビデオ及びオーディオ1900を別のユーザのゲーム又はアプリケーション内のスクリーンに出現させることができる。この例は、カーレースにおいてチームメートが協力するマルチプレーヤゲームである。ユーザのビデオ/オーディオは、チームメートだけにより選択的に見る/聞くことができる。そして、実質上、待ち時間がないので、上述した技術を使用すると、プレーヤは、気付くほどの遅延を伴うことなく、互いにリアルタイムで話したり動いたりすることができる。このビデオ/オーディオの一体化は、ユーザのカメラ/マイクロホンからの圧縮されたビデオ及び/又はオーディオをインバウンドインターネットトラフィック1501として到着させることにより達成される。次いで、インバウンドルーティング1502が、ビデオ及び/又はオーディオを、それを見る/聞くことが許されたapp/gameゲームサーバー1521-1525へルーティングする。次いで、ビデオ及び/又はオーディオを使用することを選択する各app/gameゲームサーバー1521-1525のユーザは、それを解凍し、そして1900で示されたように、必要に応じて、ゲーム又はアプリケーション内に現れるように一体化する。図19の例は、このような協力がゲームにおいてどのように利用されるか示しているが、このような協力は、アプリケーションにとって非常にパワフルなツールである。ニューヨーク市ではニューヨークに本拠地を置く不動産開発業者のためにシカゴの建築家により大きなビルが設計されているが、その判断には、旅行中でマイアミの空港にたまたまいる金融投資家が含まれ、そして投資家と不動産開発業者の両方を満足させるために、周囲のビルにどのように調和させるかに関してそのビルの幾つかの設計要素について判断をする必要がある状況を考える。建設会社は、シカゴにおいてカメラがPCに取り付けられた高解像度モニタを有し、不動産開発業者は、ニューヨークにおいてカメラ付きのラップトップを有し、そして投資家は、マイアミにおいてカメラ付きの移動電話を有している。建設会社は、ホスティングサービス210を使用して、非常に現実的な3Dレンダリングを行うことのできるパワフルな建設設計アプリケーションをホストすることができ、ニューヨーク市内のビルの大きなデータベース及び設計中のビルのデータベースを使用することができる。建設設計アプリケーションは、app/gameサーバー1521-1525の1つで実行され、又は多大な計算パワーを要求する場合には、その幾つかにおいて実行される。異なる位置にいる3人のユーザの各々は、ホスティングサービス210に接続され、そしてその各々は、建設設計アプリケーションのビデオ出力の同時ビューを有するが、これは、各ユーザが有する所与の装置及びネットワーク接続特性に対して共有ハードウェア圧縮1530により適当なサイズにされる例えば、建設会社は、20Mbpsの商業的インターネット接続を通して2560x1440の60fpsディスプレイを見ることができ、ニューヨークの不動産開発業者は、自分のラップトップの6MbpsのDSL接続を経て1280x720の60fps映像を見ることができ、そして投資家は、自分の移動電話の250Kbpsのセルラーデータ接続を経て320x180の60fps映像を見ることができる。各当事者は、他の当事者の音声を聞き会議コールは、app/gameサーバー1521-1525において広く利用できる多数の会議コールソフトウェアパッケージのいずれかにより取り扱われ、そしてユーザ入力装置上のボタンの操作を通して、ユーザは、ローカルカメラを使用してそれら自身のビデオ出演をすることができる。ミーティングが進むにつれて、建築家は、そのビルを回転し且つそのエリアの他のビルの近くを飛行したときにそのビルがどのように見えるか、非常にホトリアルな3Dレンダリングで示すことができ、そして同じビデオを、各当事者のディスプレイ装置の解像度で全ての当事者が見ることができる。当事者により使用されるローカル装置が、どれも、このようなリアリズムで3Dアニメーションを取り扱いできないことは問題ではないが、ニューヨーク市の周囲のビルをレンダリングするために要求される膨大なデータベースをダウンロードするか又は記憶することは言うまでもない。各ユーザの視点から、距離が離れているにも関わらず、又、異なるローカル装置であるにも関わらず、ユーザは、単純に、信じられないほどのリアリズムで繋ぎ目のない経験をする。そして、1人の当事者が顔を見えるようにして感情を良く伝えたいときには、そのようにすることができる。更に、不動産開発業者又は投資家のいずれかが建設プログラムの制御を手に入れてそれら自身の入力装置キーボード、マウス、キーパッド又はタッチスクリーンを使用したい場合には、知覚上待ち時間なしに応答でき、又、応答することになるそれらのネットワーク接続が不合理な待ち時間をもたないと仮定して。例えば、移動電話の場合には、その移動電話が空港のWiFiネットワークに接続された場合には、待ち時間が非常に短くなる。しかし、米国で今日利用できるセルラーデータネットワークを使用する場合には、おそらく、顕著な遅れで悩まされることになる。更に、投資家が見ているミーティングのほとんどの目的では、建築家がビルの接近飛行を制御し、又はビデオ遠隔会議で話をするためには、セルラー待ち時間でも許容できねばならない。最終的に、協力会議コールの終わりに、不動産開発業者及び投資家は、ホスティングサービスから彼等のコメントを発し且つ署名し、建設会社は、遅延バッファ1515に記録された会議のビデオを巻き戻し、そしてコメント、顔の表情、及び/又はミーティング中に作られたビルの3Dモデルに加えられたアクションを再検討することができる。セーブしたい特定のセグメントがある場合は、ビデオ/オーディオのそれらセグメントを、記録保管及び後で再生するために遅延バッファ1515からRAIDアレイ1511-1512へ移動することができる。又、コストの観点から、建築家が計算パワー及びニューヨーク市の大きなデータベースを15分の会議コールにしか使用する必要がない場合には、ハイパワーのワークステーションを所有し且つ大きなデータベースの高価なコピーを購入するのではなく、リソースを使用した時間について支払するだけでよい。ビデオリッチなコミュニティサービスホスティングサービス210は、インターネットにビデオリッチなコミュニティサービスを確立するための空前の機会を可能にする。図20は、ホスティングサービス210におけるゲームプレーヤのための規範的ユーザページを示す。ゲームファインダーアプリケーションと同様に、ユーザページは、app/gameサーバー1521-1525の1つにおいて実行されるアプリケーションである。このページにおけるサムネール及びビデオウインドウは、全て、絶えず動くビデオセグメントが短い場合は、ループになるを示す。ビデオカメラを使用するか、又はビデオをアップロードすることにより、ユーザユーザ名はKILLHAZARDであるは、自分自身のビデオ2000を掲示することができ、他のユーザがこれを見ることができる。このビデオは、RAIDアレイ1511-1512に記憶される。又、他のユーザがKILLHAZARDのユーザページに到来するときに、KILLHAZARDがそのときホスティングサービス210を使用していれば、ユーザが彼を見るために彼のユーザページを見ることを許すと仮定すれば彼が何を行おうとその生のビデオ2001が示される。これは、サーバー制御システム401から要求されるユーザページアプリケーションをホストするapp/gameサーバー1521-1525により達成され、KILLHAZARDがアクティブであるかどうか、そしてもしそうであれば、彼が使用するapp/gameサーバー1521-1525により達成される。次いで、ゲームファインダーアプリケーションにより使用される同じ方法を使用して、適当な解像度及びフォーマットの圧縮されたビデオストリームが、ユーザページアプリケーションを実行するapp/gameサーバー1521-1525へ送信され、そして表示される。ユーザがKILLHAZARDの生のゲームプレイでウインドウを選択し、次いで、その入力装置を適当にクリックする場合は、ウインドウがズームアップされこの場合もゲームファインダーアプリケーションと同じ方法を使用して、そして生のビデオが、見ているユーザのインターネット接続の特性に適した、見ているユーザのディスプレイ装置422の解像度でスクリーンを埋める。従来に勝るこの解決策の重要な効果は、ユーザページを見ているユーザが、自分が所有していないゲームの生のプレイを見ることができ、且つ非常に良いことに、ゲームをプレイできるローカルコンピュータ又はゲームコンソールをもたなくてよいことである。これは、ゲームをプレイするアクション中であるユーザページに示されたユーザをユーザが見る良い機会を与えると共に、見ているユーザが試してみたい又は上手くなりたいゲームに関して学習する機会でもある。KILLHAZARDの相棒2002からのカメラ記録又はアップロードされたビデオクリップもユーザページに示され、そして各ビデオクリップの下には、相棒がオンラインでゲームをプレイしているかどうか示すテキストがある例えば、six_shotは、ゲームEragonをプレイしておりここでは、Game4として示す、MrSnuggles99は、オフラインであり、等。メニューアイテム図示せずをクリップすることにより、相棒のビデオクリップは、記録又はアップロードされたビデオを示すものから、ホスティングサービス210上で現在ゲームをプレイしている相棒がそのときゲームにおいて何をしているかの生のビデオへとスイッチする。従って、これは、相棒のためのゲームファインダーグループとなる。相棒のゲームが選択されそしてユーザがそれをクリックする場合には、全スクリーンをズームアップし、そしてユーザは、全スクリーンでプレイされるゲームを生で見ることができる。この場合も、相棒のゲームを見ているユーザは、ゲームのコピーも、ゲームをプレイするためのローカルコンピューティング/ゲームコンソールリソースも、所有していない。ゲームを見るのは、実際上、瞬間的である。上述したように、ユーザがホスティングサービス210においてゲームをプレイするときには、ユーザは、ゲームを巻き戻し、セーブしたいビデオセグメントを見出し、次いで、ビデオセグメントを自分のユーザページへセーブする。これらは、自慢のクリップと称される。ビデオセグメント2003は、全て、プレイした以前のゲームからKILLHAZARDによりセーブされた自慢のクリップ2003である。番号2004は、自慢のクリップが何回見られたかを示し、そして自慢のクリップが見られるときに、ユーザは、それを格付けする機会を得、オレンジここでは黒の輪郭として示すのキー穴形状のアイコン2005の数は、どれほど高い格付けであるかを示す。自慢のクリップ2003は、ユーザがユーザページを見るとき、そのページにおけるビデオの残りと共に絶えずループする。ユーザが自慢のクリップ2003の1つを選択してクリックする場合には、それがズームアップし、自慢のクリップ2003を、クリップの再生、休止、巻き戻し、早送り、ステップスルー、等を行えるようにするDVRコントロールと共に提示する。自慢のクリップ2003の再生は、ユーザが自慢のクリップを記録し、それを解凍して再生するときに、RAIDアレイ1511-1512に記憶された圧縮ビデオセグメントをapp/gameサーバー1521-1525がロードすることにより具現化される。又、自慢のクリップ2003は、3DDVRビデオセグメント即ち、再生でき且つユーザがカメラの視点を変更するのを許すゲームからのゲーム状態シーケンスでもあり、これは、そのような能力をサポートするゲームからのものである。この場合、ゲームセグメントが記録されたときにユーザが作った特定のフライスルーの圧縮ビデオ記録に加えて、ゲーム状態情報が記憶される。ユーザページが見られ、そして全てのサムネール及びビデオウインドウが絶えずループ化するときには、3DDVR自慢のクリップ2003は、ユーザがゲームセグメントのフライスルーを記録したときに圧縮ビデオとして記録された自慢のクリップ2003を絶えずループ化する。しかし、ユーザが3DDVR自慢のクリップ2003を選択してそれをクリップするときには、圧縮ビデオの自慢のクリップを再生できるようにするDVRコントロールに加えて、ユーザは、ゲームセグメントに対する3DDVR能力を与えるボタンをクリックすることができる。それらは、彼等自身でゲームセグメント中にカメラのフライスルーを制御することができ、そしてそれらが望む及びユーザページを所有するユーザがそれを許す場合に、別の自慢のクリップのフライスルーを圧縮ビデオ形態で記録することができ、これは、次いで、ユーザページの他の視聴者に利用可能となる直ちに、又はユーザページの所有者が自慢のクリップを再検討する機会をもった後に。この3DDVR自慢のクリップ2003の能力は、記録されたゲーム状態情報を別のapp/gameサーバー1521-1525において再生しようとしているゲームを作動することによりイネーブルされる。ゲームは、ほぼ瞬間的に作動できるので上述したように、自慢のクリップにより記録されたゲーム状態にプレイを限定してゲームを作動し、次いで、ユーザが、圧縮ビデオを遅延バッファ1515に記録しながらカメラでフライスルーを実行できるようにするのは、困難ではない。ユーザがフライスルーの実行を完了すると、ゲームが不作動にされる。ユーザの視点から、3DDVRの自慢のクリップ2003でフライスルーを作動することは、リニアな自慢のクリップ2003のDVRコントロールを制御することより努力が要らない。それらは、ゲームについて又はゲームをどのようにプレイするかについて何も知らなくてよい。それらは、別の者により記録されるゲームセグメント中に3D世界を凝視するバーチャルカメラオペレータに過ぎない。又、ユーザは、それら自身のオーディオを、マイクロホンから記録されるか又はアップロードされる自慢のクリップにオーバーダビングすることもできる。このようにして、自慢のクリップは、ゲームからのキャラクタ及びアクションを使用して、カスタムアニメーションを生成するのに使用できる。このアニメーション技術は、マシニマとして一般に知られている。ユーザがゲームを進めるにつれて、異なるスキルレベルを達成する。プレイしたゲームは、達成度をサービスコントロールシステム401へ報告し、それらのスキルレベルがユーザページに示される。双方向アニメ化広告オンライン広告は、テキストから、静止映像へ、ビデオへ、そして今や、AdobeFlashのようなアニメーションシンクライアントを使用して典型的に具現化される双方向セグメントへと推移してきた。アニメーションシンクライアントを使用する理由は、ユーザが、典型的に、製品やサービスが彼等に推薦される特典に対する遅れが耐え難いからである。又、シンクライアントは、非常に低性能のPCで実行され、従って、広告主は、双方向アドが適切に機能するという高い信頼度をもつことができる。不都合なことに、AdobeFlashのようなアニメーションシンクライアントは、双方向性の度合い及び経験の巾が制限されるダウンロード時間を軽減し、そしてGPUをもたない低性能PC及びMac、又は高性能CPUを含むほぼ全てのユーザ装置で動作するために。図21は、ショールーム内で車を回転させ、車がどのように見えるかリアルタイムレイトレーシングで示しながら、ユーザが車の外部及び内部の色を選択する双方向広告を示している。ユーザは、車を運転するアバターを選択し、次いで、ユーザは、レーストラック上、又はモナコのようなエキゾチックな場所でドライブするように車を取り出すことができる。ユーザは、より大きなエンジン又はより優れたタイヤを選択することができ、次いで、その変更した構成が車の加速性能又は路面の食い付きにどのように影響するか見ることができる。もちろん、広告は、実際上、精巧な3Dビデオゲームである。しかし、PC又はビデオゲームコンソール上に再生できる広告については、おそらく、100MBダウンロードを要求し、そしてPCの場合には、特殊なドライバのインストールを要求すると共に、PCが充分なCPU又はGPU計算能力に欠ける場合には全く実行されないことがある。従って、このような広告は、従来の構成では不可能である。ホスティングサービス210では、このような広告は、ほぼ瞬時に起動し、そしてユーザのクライアント415の能力がどんなものであっても、完全に実行される。従って、それらは、シンクライアント双方向アドより素早く起動し、著しく経験に富み、且つ非常に信頼性が高い。リアルタイムアニメーション中のストリーミング幾何学形状RAIDアレイ1511-1512及びインバウンドルーティング1502は、リアルタイムアニメーション例えば、複雑なデータベースを伴うフライスルー中にゲームプレイ又はアプリケーションの中間において幾何学形状をオンザフライで確実に配信するためにRAIDアレイ1511-1512及びインバウンドルーティング1502に依存するビデオゲーム及びアプリケーションを設計できるように高速で且つ短待ち時間のデータレートを与えることができる。図1に示すビデオゲームシステムのような従来のシステムでは、特に実際の家庭用装置に使用できる大量記憶装置は、要求される幾何学形状をある程度予想できる状況を除き、ゲームプレイ中に幾何学形状をストリームするには遥かに低速である。例えば、特定の道路が存在するドライブゲームにおいて、視野に入って来るビルの幾何学形状は、合理的に充分なほど予想でき、そして大量記憶装置は、近づきつつある幾何学形状が位置している場所を前もって探すことができる。しかし、予想できない変化を伴う複雑なシーンにおいて例えば、あたり一面に複雑なキャラクタが存在する戦闘のシーンにおいて、PC又はビデオゲームシステムのRAMが、現在視野にある物体に対する幾何学形状で完全に埋められており、次いで、ユーザが突然それらのキャラクタを、それらキャラクタの背後の視野へ方向転換する場合に、幾何学形状がRAMに予めロードされていなければ、それを表示できるまでに遅延が生じることになる。ホスティングサービス210において、RAIDアレイ1511-1512は、ギガビットイーサネット速度以上でデータをストリームすることができ、そしてSANネットワークでは、10ギガビットのイーサネット又は他のネットワークに勝る10ギガビット/秒の速度を達成することができる。10ギガビット/秒は、ギガバイトのデータを1秒未満でロードする。60fpsのフレーム時間16.67msでは、ほぼ170メガビット21MBのデータをロードすることができる。当然、RAID構成にある回転するメディアは、1フレーム時間より大きな待ち時間を依然被るが、フラッシュベースのRAID記憶装置は、結局、回転するメディアRAIDアレイと同程度の大きさであり、そのような長い待ち時間は被らない。一実施形態では、大量RAMライトスルーキャッシングを使用して、非常に短い待ち時間のアクセスを与える。従って、充分に高いネットワーク速度及び充分に短い待ち時間の大量記憶では、CPU及び/又はGPUが3Dデータを処理できるのと同程度の速さでapp/gameゲームサーバー1521-1525へ幾何学形状をストリームすることができる。従って、ユーザがそのキャラクタを突然方向転換しそして後を見る上述した例では、後方の全てのキャラクタに対する幾何学形状を、キャラクタが回転を完了する前にロードすることができ、従って、ユーザにとって、生のアクションと同程度にリアルなホトリアルな世界にいるかのように思える。上述したように、ホトリアルなコンピュータアニメーションにおける最後の未開拓の1つは、人間の顔であり、不完全さに対して人間の目が敏感であるために、ホトリアルな顔からの若干のエラーが視聴者から否定的なリアクションを招くことがある。図22は、ContourTMリアリティキャプチャーテクノロジー本CIP出願の譲受人に各々譲渡された同時係争中の特許出願、即ち2004年9月15日に出願された第10/942,609号Apparatusandmethodforcapturingthemotionofaperformer、2004年9月15日に出願された第10/942,413号Apparatusandmethodforcapturingtheexpressionofaperformer、2005年2月25日に出願された第11/066,954号Apparatusandmethodforimprovingmarkeridentificationwithinamotioncapturesystem、2005年3月10日に出願された第11/077,628号Apparatusandmethodforperformingmotioncaptureusingshuttersynchronization、2005年10月20日に出願された第11/255,854号Apparatusandmethodforperformingmotioncaptureusingarandompatternoncapturesurfaces、2006年6月7日に出願された第11/449,131号Systemandmethodforperformingmotioncaptureusingphosphorapplicationtechniques、2006年6月7日に出願された第11/449,043号Systemandmethodforperformingmotioncapturebystrobingafluorescentlamp、2006年6月7日に出願された第11/449,127号Systemandmethodforthreedimensionalcaptureofstopmotionanimatedcharactersの要旨を使用して捕獲される生の演技が、非常に滑らかな捕獲表面を、次いで、高多角形数追跡表面即ち、多角形の動きが顔の動きに正確に追従するをどのように生じるか示している。最終的に、生の演技のビデオが追跡表面にマップされて、テクスチャ処理表面を形成するときに、ホトリアルな結果が得られる。現在のGPU技術は、追跡表面における多角形の数及びテクスチャをレンダリングしそして表面をリアルタイムで照明することができるが、多角形及びテクスチャがフレーム時間ごとに変化するこれは、最もホトリアルな結果を生じる場合には、近代的PC又はビデオゲームコンソールの利用可能な全てのRAMを急速に消費してしまう。上述したストリーミング幾何学形状技術を使用すると、app/gameゲームサーバー1521-1525へ幾何学形状を連続的に供給して、ホトリアルな顔を連続的にアニメ化し、生の動きの顔とほとんど見分けがつかない顔をもつビデオゲームを作成できるようにするが実際的である。リニアなコンテンツと双方向特徴との一体化動画、テレビ番組及びオーディオ資料集合的にリニアコンテンツは、家庭及びオフィスのユーザに多数の形態で広く利用することができる。リニアコンテンツは、CD、DVD及びBlu-rayメディアのような物理的なメディアにおいて取得することができる。又、これは、衛星及びケーブルTV放送からDVRにより記録することもできる。そして、衛星及びケーブルTVを通してペイパービューPPVコンテンツとして、及びケーブルTVのビデオオンデマンドVODとして利用することもできる。益々多くのリニアコンテンツが、インターネットを通して、ダウンロードされたコンテンツとして及びストリーミングコンテンツとして利用できるようになった。今日、リニアメディアに関連した全ての特徴を経験するための場所は、実際に1つではない。例えば、DVD及び他のビデオ光学メディアは、典型的に、演出家の解説、メーキングオブ特徴、等のように、他の場所では利用できない双方向特徴を有する。オンライン音楽サイトは、一般的にCDでは入手できないカバー技術及び歌情報を有するが、全てのCDをオンラインで入手できるのではない。又、テレビ番組に関連したウェブサイトは、しばしば、特別な特徴、ブログ、及びときには、俳優又は創作スタッフからのコメントを有する。更に、多くの動画又はスポーツの出来事では、動画の場合しばしばリニアメディアと一緒に発売されるか、或いはスポーツの場合実世界の出来事例えば、プレーヤのトレードに密接に結びついたビデオゲームがしばしばある。ホスティングサービス210は、異なる形態の関連コンテンツと一緒にリンクしてリニアコンテンツを配布するのに良く適している。確かに、動画の配信は、もはや、高度な双方向性のビデオゲームを配信する挑戦ではなく、ホスティングサービス210は、リニアコンテンツを家庭又はオフィスの広範な装置或いは移動装置へ配信することができる。図23は、リニアコンテンツの選択を示すホスティングサービス210の規範的なユーザインターフェイスページを示している。しかし、ほとんどのリニアコンテンツ配信システムとは異なり、ホスティングサービス210は、関連する双方向コンポーネント例えば、DVDにおけるメニュー及び特徴、HD-DVDにおける双方向オーバーレイ、及びウェブサイトにおけるAdobeFlashアニメーション以下に述べるを配信することもできる。従って、クライアント装置415の制限は、どの特徴が利用できるかについて、もはや制限を導入しない。更に、ホスティングサービス210は、リニアコンテンツをビデオゲームコンテンツと動的に且つリアルタイムでリンクすることができる。例えば、ユーザがハリーポッターの映画においてクィディッチの試合を見て、クィディッチのプレイにトライしたい場合に、ボタンをクリックするだけで、映画を休止し、直ちに、ハリーポッタービデオゲームのクィディッチセグメントへ移ることができる。クィディッチの試合をプレイした後に、ボタンの別のクリックで、即座に映画が再開する。写真的に捕獲されたビデオが生の動きのキャラクタと見分けがつかないようなホトリアルなグラフィック及び制作技術では、ユーザが、生の動きの映画におけるクィディッチゲームから、ここに述べるホスティングサービスにおけるビデオゲームのクィディッチゲームへ移行するときに、2つのシーンは、実質上、見分けがつかない。これは、2つの世界の間の線が見分けられないのでリニアコンテンツ及び双方向例えば、ビデオゲームコンテンツの両方の演出家にとって全く新しい創作オプションを与える。図14に示すホスティングサービスアーキテクチャーを使用して、3D映画のバーチャルカメラの制御権を視聴者に与えることができる。例えば、列車の車両内で生じるシーンでは、視聴者がバーチャルカメラを制御して、ストーリーが進行する間に車両の周囲を見ることができる。これは、車両内の全ての3Dオブジェクトアセットが利用できると共に、シーンをリアルタイムでレンダリングできる充分なレベルの計算パワー、及びオリジナルの映画を仮定している。そして、非コンピュータ発生娯楽であっても、非常にエキサイティングな双方向特徴を提供することができる。例えば、2005動画高慢と偏見は、華麗な古い英国風大邸宅における多くのシーンを有している。大邸宅の幾つかのシーンに対し、ユーザは、ビデオを休止し、次いで、カメラを制御して、大邸宅の塔、又はおそらく、周囲のエリアを撮影することができる。これを具現化するために、従来のアップル社のQuickTimeVRが具現化されたのと同様に、位置を見失わないように魚眼レンズをつけて大邸宅を通してカメラを搬送することができる。次いで、種々のフレームが変換され、従って、映像は歪むことなく、映画と共にRAIDアレイ1511-1512に記憶され、そしてユーザがバーチャルの塔に行くことを選択したときに再生することができる。スポーツ行事では、バスケットボールゲームのような生のスポーツ行事を、ユーザが普通のTVで見るために、ホスティングサービス210を通してストリーミングすることができる。ユーザが特定のプレイを見た後に、ゲームのビデオゲーム最終的には実際のプレーヤと同程度ホトリアルに見えるバスケットプレーヤを伴うを、プレーヤが同じ位置でスタートして始めることができ、そしてユーザおそらく各々1人のプレーヤの制御権を得ているがプレイをやり直して、プレーヤよりうまくいくかどうか確かめることができる。ここに述べるホスティングサービス210は、この未来派的な世界をサポートするのに非常に良く適している。というのは、家庭又はほとんどのオフィス設定でインストールするのが不可能である計算パワー及び大量記憶リソースを保持することができ、又、家庭用設定では常に古い世代のPC及びビデオゲームをもつものとなるが、その計算リソースは、入手可能な最新の計算ハードウェアで、常に、最新のものだからである。そして、ホスティングサービス210では、この計算の複雑さが全てユーザから隠され、従って、非常に精巧なシステムを使用しても、ユーザの観点から、テレビのチャンネルを切り換えるように簡単である。更に、ユーザは、全ての計算パワーにアクセスし、そして計算パワーがクライアント415から得られるところの経験にアクセスすることができる。マルチプレーヤゲームゲームがマルチプレーヤゲームであるという点で、インバウンドルーティング1502のネットワークを通してapp/gameゲームサーバー1521-1525と通信できると共に、インターネット図示せずへのネットワークブリッジで、ホスティングサービス210において実行されないサーバー又はゲームマシンと通信することができる。一般的なインターネットにおけるコンピュータでマルチプレーヤゲームをプレイするときには、app/gameゲームサーバー1521-1525は、インターネットへのアクセスが非常に速いゲームが家庭のサーバーで実行された場合に比してという利点を有するが、低速な接続でゲームをプレイする他のコンピュータの能力により制限を受けると共に、インターネット上のゲームサーバーが、比較的低速の消費者用インターネット接続上の家庭用コンピュータである最小公分母を受け容れるように設計されたことによっても潜在的に制限を受ける。しかし、マルチプレーヤゲームが完全にホスティングサービス210のサーバーセンター内でプレイされるときには、差の世界を達成することができる。ユーザのためのゲームをホストする各app/gameゲームサーバー1521-1525は、他のapp/gameゲームサーバー1521-1525と、非常に高速で非常に短待ち時間の接続及び膨大な非常に高速の記憶アレイをもつマルチプレーヤゲームのための集中制御をホストするサーバーとに相互接続される。例えば、インバウンドルーティング1502のネットワークにギガビットのイーサネットが使用される場合には、app/gameゲームサーバー1521-1525は、ギガビット/秒の速度において潜在的に1ms以下の待ち時間で、互いに通信すると共に、マルチプレーヤゲームのための集中制御をホストするサーバーとも通信する。更に、RAIDアレイ1511-1512は、非常に迅速に応答し、そしてギガビット/秒の速度でデータを転送することができる。例えば、家庭においてPC又はゲームコンソールで実行されるゲームクライアントに制限された従来のシステムで、キャラクタが大量の幾何学形状及びそのキャラクタ独特の挙動を有するように、容貌及び服装に関してユーザがキャラクタをカスタマイズする場合に、そのキャラクタが別のユーザの視野に入ってきた場合には、ユーザは、長くて低速のダウンロードが完了して全ての幾何学形状及び挙動データがコンピュータにロードされるまで、待機しなければならなくなる。ホスティングサービス210内では、その同じダウンロードを、RAIDアレイ1511-1512から対応されるギガビットのイーサネットを経てギガビット/秒の速度で行うことができる。家庭のユーザが8Mbpsのインターネット接続これは、今日の規格では非常に高速であるを有する場合でも、ギガビットイーサネットは、100倍も高速である。従って、高速インターネット接続で1分かかるものが、ギガビットイーサネットでは1秒未満である。トッププレーヤグループ及びトーナメントホスティングサービス210は、トーナメントに非常に良く適している。ローカルクライアントでゲームが実行されないので、ユーザがチートする機会がない例えば、従来のトーナメントにおいてローカルPCで実行されるゲームのコピーを変更して不公平な利益を与えることにより得られる。又、出力ルーティング1540がUDPストリームをマルチキャストできるので、ホスティングサービス210は、メジャートーナメントを観衆の中の数千以上の人々に一度にブロードキャストすることができる。実際に、数千のユーザが同じストリーム例えば、メジャートーナメントのビューを示すを受信するように普及した幾つかのビデオストリームがあるときは、多くのクライアント装置415へ大量配布するためにAkamai又はLimelightのようなコンテンツデリバリーネットワークCDNへビデオストリームを送信するのがより効率的である。CDNを使用してトッププレーヤグループのゲームファインダーページを示すときには、同様の効率レベルを得ることができる。メジャートーナメントの場合、生の有名アナウンサを使用して、ある試合中に実況放送することができる。メジャートーナメントを見ているのは大勢のユーザであるが、トーナメントでプレイするのは比較的少数である。有名アナウンサからの音声は、トーナメントでプレイしているユーザをホストすると共にトーナメントにおけるゲームの観客モードコピーをホストするapp/gameゲームサーバー1521-1525へルーティングすることができ、そしてその音声は、ゲーム音声の上にオーバーダビングすることができる。有名アナウンサの映像も、ゲームにオーバーレイし、おそらくは、観客のビューにオーバーレイすることができる。ウェブページロードの加速ワールドワイドウェブ及びその一次トランスポートプロトコルであるハイパーテキストトランスファープロトコルHTTPは、ビジネスだけが高速インターネット接続をもちそしてオンラインにいる消費者がダイヤルアップモデム又はISDNを使用していた時代に考えられ定義されたものである。そのとき、高速接続用の黄金律は、1.5Mbpsのデータレートを対称的に即ち、両方向に等しいデータレートで与えるT1ラインであった。今日、状況は、完全に異なる。開発された世界の多くにおいてDSL又はケーブルモデム接続を通る平均的な家庭用接続の速度は、T1ラインより遥かに高いダウンストリームデータレートを有している。実際に、世界の幾つかの部分では、ファイバーツーザカーブが、50ないし100Mbps程度の高さのデータレートを家庭へ運ぶ。不都合なことに、HTTPは、これらの急激な速度改善の利点を効果的に取り入れるように構成されてこなかった又、具現化もされなかった。ウェブサイトは、リモートサーバーにおけるファイルの集合である。非常に簡単に言えば、HTTPは、第1のファイルを要求し、そのファイルがダウンロードされるのを待機し、次いで、第2のファイルを要求し、そのファイルがダウンロードされるのを待機し、等々である。実際に、HTTPは、2つ以上のオープン接続を許し、即ち一度に2つ以上のファイルを要求できるようにするが、合意された規格及びウェブサーバーが過負荷にならないよう防止する要望があるために、非常に僅かなオープン接続しか許されない。更に、ウェブページが構成される方法のために、ブラウザは、多くの場合、直ちにダウンロードに利用できる複数の同時のページに気付かない即ち、ページをパーズした後にのみ、映像と同様に、新たなファイルをダウンロードする必要があることが明らかとなる。従って、ウェブサイトのファイルは、本質的に1つ1つロードされる。そして、HTTPによって使用される要求及び応答プロトコルのために、ロードされる各ファイルに関連して米国で典型的なウェブサーバーにアクセスするとおおよそ100msの待ち時間がある。比較的低速の接続では、これにより大きな問題が導入されることはない。というのは、ファイルそれ自体のダウンロード時間がウェブページの待ち時間を支配するからである。しかし、接続速度が上がるにつれて、特に、複雑なウェブページでは、問題が起き始める。図24に示す例では、典型的な商業的ウェブサイトが示されているこの特定のウェブサイトは、一流運動選手用の靴のブランドからのものである。このウェブサイトには、54のファイルがある。これらファイルは、HTML、CSS、JPEG、PHP、Java登録商標Script、及びFlashファイルを含むと共に、ビデオコンテンツを含む。ページが生になる即ち、ユーザがそれをクリックして、それを使用し始める前に、合計1.5Mバイトをロードしなければならない。多数のファイルには、多くの理由がある。1つのこととして、複雑で且つ精巧なウェブページであり、そして別のこととして、ページにアクセスするユーザに関する情報例えば、ユーザの母国、言語、以前に購入したかどうか、等に動的に基づいてアッセンブルされるウェブページであり、そしてこれら全てのファクタに基づいて、異なるファイルがダウンロードされる。依然、これは、非常に典型的な商業用ウェブページである。図24は、接続速度が上がるにつれてウェブページが生になるまでに経過する時間量を示している。1.5Mbpsの接続速度2401では、従来のウェブブラウザを伴う従来のウェブサーバーを使用すると、ウェブページが生になるまでに13.5秒を要する。12Mbpsの接続速度2402では、ロード時間は、6.5秒に短縮され、即ち約2倍の速さになる。しかし、96Mbpsの接続速度2403では、ロード時間は、約5.5秒までしか短縮されない。その理由として、このように高いダウンロード速度では、ファイルそれ自体をダウンロードするための時間は最小であるが、ファイル当たりの待ち時間、各々約100msが依然あって、その結果、54ファイル100ms=5.4秒の待ち時間となる。従って、家庭への接続がどれほど速くても、このウェブサイトは、常に、それが生となるまでに少なくとも少なくとも5.4秒を要する。別のファクタは、サーバー側のキューイングであり、即ち各HTTP要求がキューの後部に追加され、従って、ビジーのサーバーでは、これが大きな影響を及ぼす。というのは、ウェブサーバーから小さなアイテムを得るたびに、HTTP要求がその方向転換を待機する必要があるためである。これらの問題を解決する1つの仕方は、HTTPを破棄するか又は再定義することである。或いは、おそらく、ウェブサイト所有者がそのファイルを単一のファイル例えば、AdobeFlashフォーマットのへうまく合併することである。しかし、実際的な問題として、この会社及び多くの他の者は、そのウェブサイトアーキテクチャー多大な投資をしている。更に、ある家庭は、12-100Mbpsの接続を有するが、大多数の家庭は、依然、ゆっくりした速度であり、HTTPも、低速度で機能する。1つの別の仕方は、app/gameサーバー1521-1525のウェブブラウザをホストすると共に、RAIDアレイ1511-1512のウェブサーバーに対するファイルをホストすることである或いは潜在的にウェブブラウザをホストするapp/gameサーバー1521-1525のRAM又はローカル記憶装置において。インバウンドルーティング1502を通して又はローカル記憶装置への非常に高速の相互接続があるために、HTTPを使用してファイル当たり100msの待ち時間となるのではなく、HTTPを使用してファイル当たり最小の待ち時間となる。従って、家にいるユーザがHTTPを通してウェブページにアクセスするのではなく、ユーザは、クライアント415を通してウェブページにアクセスすることができる。次いで、1.5Mbpsの接続ではこのウェブページがそのビデオに対して著しい帯域巾を要求しないので、ウェブページは、線2400当たり1秒未満で生となる。本質的に、app/gameサーバー1521-1525で実行されるウェブブラウザが生のページを表示するまでは待ち時間がなく、そしてクライアント415がウェブブラウザからのビデオ出力を表示するまでは検出可能な待ち時間がない。ユーザがウェブページ上でマウス操作し及び/又はタイプするときに、ユーザの入力情報がapp/gameサーバー1521-1525で実行されるウェブブラウザへ送信され、そしてウェブブラウザが適宜に応答する。この解決策の1つの欠点は、コンプレッサがビデオデータを常時送信する場合に、ウェブページが静的なものとなっても、帯域巾が使用されることである。これは、ウェブページが変化するときだけ及びその場合にのみデータを送信し、次いで、変化したページの部分にのみデータを送信するようにコンプレッサを構成することにより、改善することができる。常時変化するフラッシングバナー、等をもつ幾つかのウェブページがあるが、このようなウェブページは、うっとうしい傾向となり、通常、ウェブページは、何かが動く例えば、ビデオクリップ理由がない限り静的なものとなる。このようなウェブページの場合、おそらく、従来のウェブサーバーよりも少ないデータがホスティングサービス210を使用して送信される。というのは、実際に表示される映像だけが送信され、シンクライアント実行コードも、決して見ることのない大きなオブジェクト、例えば、ロールオーバー映像も、送信されないからである。従って、ホスティングサービス210を使用して、レガシーウェブページをホストすると、ウェブページのロード時間は、ウェブページをオープンすることがテレビのチャンネルを切り換えることと同じである点まで短縮することができ、即ちウェブページは、実際上瞬時に生となる。ゲーム及びアプリケーションのデバッグの容易化上述したように、リアルタイムグラフィックを伴うビデオゲーム及びアプリケーションは、非常に複雑なアプリケーションであり、典型的に、市場に発売されるときに、バグを含むことがある。ソフトウェア開発者は、バグに関してユーザからフィードバックを得、そしてクラッシュ後にマシン状態を還元するための何らかの手段を有するが、ゲーム又はリアルタイムアプリケーションに何が起きてクラッシュさせ又は不適切に機能させたか厳密に識別することは非常に困難である。ゲーム又はアプリケーションがホスティングサービス210で実行されるときに、ゲーム又はアプリケーションのビデオ/オーディオ出力は、遅延バッファ1515に常時記録される。更に、ウオッチドッグプロセスが、各app/gameサーバー1521-1525で動作し、app/gameサーバー1521-1525が円滑に動作することをホスティングサービスコントロールシステム401に規則的に報告する。ウオッチドッグプロセスが報告を怠った場合には、サーバーコントロールシステム401は、app/gameサーバー1521-1525と通信するように試み、それが成功すれば、どんなマシン状態が得られてもそれを収集する。どんな情報が得られてもそれが、遅延バッファ1515に記録されたビデオ/オーディオと共に、ソフトウェア開発者へ送信される。従って、ゲーム又はアプリケーションソフトウェアの開発者が、ホスティングサービス210からクラッシュの通知を得ると、何がクラッシュを招いたかのフレームごとの記録を得る。この情報は、バグを追跡して修理する上で非常に価値がある。又、app/gameサーバー1521-1525がクラッシュすると、サーバーは、最も最近の再スタート可能な点において再スタートされ、そして技術的な困難さについて謝罪するメッセージがユーザに与えられる。リソースの共有及びコストの節約図4a及び4bに示されたシステムは、エンドユーザとゲーム及びアプリケーションの開発者の両方に種々の利益を与える。例えば、典型的に、家庭及びオフィスのクライアントシステム例えば、PC又はゲームコンソールは、一週間に僅かな時間しか使用されない。ニールセンエンターテイメントActiveGamerBenchmarkStudyによる2006年10月5日プレスリリースによれば、積極的なゲーマーは、一週間に平均14時間を費やしてビデオゲームコンソールをプレイし、そして一週間に約17時間をハンドヘルド状態にしている。又、このレポートは、コンソール、ハンドヘルド及びPCゲームプレイを含む全てのゲームプレイ活動に対し、積極的なゲーマーは、一週間に平均13時間を費やすと述べている。コンソールビデオゲームのプレイ時間が高い数値であることを考慮すれば、一週間は、247=168時間であり、これは、積極的なゲーマーの家では、ビデオゲームコンソールが一週間の時間のうち17/168=10しか使用されないことを意味する。即ち、90の時間は、ビデオゲームコンソールがアイドル状態である。高いコストのビデオゲームコンソールであり、そして製造者がこのような装置に助成しているとすれば、高価なリソースの非常に非効率的な使い方である。会社の中のPCも、典型的に、一週間のうち僅かな時間しか使用されず、特に、AutodeskMayaのようなハイエンドアプリケーションにしばしば要求される非ポータブルのデスクトップPCがそうである。ある会社は、全ての時間及び休日も営業し、そしてあるPC例えば、夜家で仕事をするために持ち運ばれるポータブルは、全ての時間及び休日も使用されるが、会社のほとんどの活動は、月曜日から金曜日まで所定の営業時間ゾーンのほぼAM9時からPM5時までを中心とする傾向があり、休日や休息時間昼食時のようなにはほとんど行われず、又、ほとんどのPC使用は、ユーザがPCに積極的に関わる間に生じるので、デスクトップPCの使用は、これらの営業時間に従う傾向となる。PCが、週5日間、AM9時からPM5時まで恒常的に使用されると仮定すれば、PCが週の時間の40/168=24使用されることを意味する。高性能デスクトップPCは、会社にとって非常個高価な投資であり、これは、非常に低い利用レベルを反映している。デスクトップコンピュータで授業する学校は、週のより小さな時間巾でもコンピュータを使用し、授業時間に基づいて変化するが、ほとんどの授業は、月曜日から金曜日までの昼間の時間中に行われる。従って、一般的に、PC及びビデオゲームコンソールは、週の時間の僅かな部分でしか利用されない。特に、多くの人々は、平日月曜日から金曜日の昼間の時間中は会社や学校にいるので、これらの人々は、一般的に、これらの時間中はビデオゲームをプレイせず、従って、ビデオゲームをプレイするのは、一般的に、夜や週末や休日のような他の時間中である。図4aに示すホスティングサービスの構成が与えられると、上述した2つの段落で述べた使用パターンは、リソースの非常に効率的な利用を生じる。明らかなように、特に、ユーザが、精巧な3Dビデオゲームのような複雑なアプリケーションに対してリアルタイム応答を要求する場合には、所与の時間にホスティングサービス210によってサービスを受けることのできるユーザの数に限度がある。しかし、典型的にほとんどの時間アイドル状態にある家庭のビデオゲームコンソールや会社で使用されるPCとは異なり、サーバー402は、異なる時間に異なるユーザにより再利用することができる。例えば、高性能のデュアルCPU及びデュアルGPUと大容量のRAMとを伴う高性能サーバー402は、平日のAM9時からPM5時まで会社及び学校により利用することができるが、夜、週末及び休日には精巧なビデオゲームをプレイするゲーマーにより利用することができる。同様に、低性能のアプリケーションは、CeleronCPUをもち、GPUをもたず又は非常にローエンドのGPUをもち且つ制限されたRAMをもつ低性能サーバー402において会社の時間中に会社及び学校によって利用することができ、そして低性能ゲームは、会社の時間中でないときに低性能サーバー402を利用することができる。更に、ここに述べるホスティングサービス構成では、数百万でなくても数千のユーザ間でリソースが効率的に共用される。一般的に、オンラインサービスは、所与の時間にサービスを利用する全ユーザベースの僅かな割合しかもたない。上述したニールセンのビデオゲーム使用統計値を考えると、なぜそうなるか調べることは容易である。積極的なゲーマーがコンソールゲームを一週間に17時間しかプレイしない場合に、ゲームのピーク使用時間が、夜5-AM12、75日=35時間/週及び週末AM8-AM12、162=32時間/週の典型的な非仕事非会社時間中であると仮定すると、17時間のゲームプレイに対して一週間に3532=65ピーク時間ある。システムに対する厳密なピークユーザ負荷は、多くの理由で推定が困難であり、即ちあるユーザは、オフピーク時間中にプレイし、ある日中の時間にユーザの集団ピークがあり、ピーク時間は、プレイするゲームの形式により影響され例えば、子供のゲームは、おそらく、夜の早い時間にプレイされ、等々である。しかし、ゲーマーがプレイする平均時間数が、ゲーマーがおそらくゲームをプレイする日の時間数より遥かに少ないとすれば、所与の時間にホスティングサービス210のユーザ数の一部分がそれを使用するだけである。この分析のためには、ピーク負荷が12.5であると仮定しなければならない。従って、計算、圧縮及び帯域巾リソースの12.5が所与の時間に使用されるだけであり、その結果、リソースの再使用により所与の性能レベルのゲームをプレイするように所与のユーザをサポートするのにハードウェアコストの12.5だけとなる。更に、あるゲーム及びアプリケーションが他のものより多くの計算パワーを要求するとすれば、ユーザによってプレイされるゲーム又は実行されるアプリケーションに基づいてリソースを動的に割り当てることができる。従って、低性能ゲーム又はアプリケーションを選択するユーザには、低性能低廉なサーバー402が割り当てられ、そして高性能ゲーム又はアプリケーションを選択するユーザには、高性能より高価なサーバー402が割り当てられる。実際に、所与のゲーム又はアプリケーションは、ゲーム又はアプリケーションの低性能区分及び高性能区分を有し、そしてユーザは、ゲーム又はアプリケーションのニーズを満足する最低コストのサーバー402でのユーザの動作を保持するように、ゲーム又はアプリケーションの区分間で、あるサーバー402から別のサーバー402へスイッチすることができる。単一のディスクより遥かに高速のRAIDアレイ405が、低性能のサーバー402でも使用でき、高速ディスク転送レートの利益を得る。従って、プレイされるゲーム又は使用されるアプリケーションの全部にわたるサーバー402当たりの平均コストは、最高性能のゲーム又はアプリケーションをプレイする最も高価なサーバー402のコストよりかなり低く、更に、低性能サーバー402は、RAIDアレイ405からディスク性能の利益を導出する。更に、ホスティングサービス210のサーバー402は、ネットワークインターフェイス以外のディスク又は周辺インターフェイスをもたないPCマザーボード以上のものではなく、やがて、SAN403への高速ネットワークインターフェイスのみをもつ単一チップへと一体化される。又、RAIDアレイ405は、おそらく、ディスクより遥かに多数のユーザ間で共用され、従って、活動的なユーザ当たりのディスクコストは、1つのディスクドライブより遥かに低い。この装置は、全て、おそらく、環境的に制御されたサーバールーム環境においてラック内に存在する。サーバー402がフェイルした場合に、ホスティングサービス210において容易に修理又は交換することができる。対照的に、家庭又はオフィスにおけるPC又はゲームコンソールは、叩かれたり落とされたりすることによる適度な摩耗及び引き裂きに生き残ることができねばならず、ハウジングを要求し、少なくとも1つのディスクドライブを有し、悪い環境条件例えば、他のギアでオーバーヘッドAVキャビネットへ詰め込まれるに生き残らねばならず、サービス保証を要求し、パッケージされて出荷されねばならず、且つおそらく小売利ざやを徴収する小売店により販売される頑強なスタンドアローン機器でなければならない。更に、PC又はゲームコンソールは、ほとんどの時間に低性能ゲーム又はアプリケーション或いはゲーム又はアプリケーションの区分がプレイされても、将来のある時点で使用される最も計算上強いと予想されるゲーム又はアプリケーションのピーク性能を満足するように構成されねばならない。そして、PC又はコンソールがフェイルした場合に、それを修理するのは、高価で且つ時間のかかるプロセス製造者、ユーザ及びソフトウェア開発者に悪影響が及ぶである。従って、図4aに示すシステムがローカル計算リソースに匹敵する経験をユーザに与えるとすれば、家庭、オフィス又は学校のユーザが所与のレベルの計算能力を経験するために、図4aに示すアーキテクチャーを通してその計算能力を与えるのにかなり低廉なものとなる。アップグレードの必要性の排除更に、ユーザは、新たなゲームをプレイし又はより高い性能の新たなアプリケーションを取り扱うためにPC及び/又はコンソールをアップグレードすることに関して心配する必要はもはやない。ホスティングサービス210におけるゲーム又はアプリケーションは、そのゲーム又はアプリケーションのためにどんな形式のサーバー402が要求されるかに関わらず、ユーザに利用することができ、全てのゲーム及びアプリケーションは、ほぼ即座に例えば、サーバー402上のRAIDアレイ405又はローカル記憶装置から素早くロードされて且つ最新の更新及びバグ修理で適切に実行される即ち、ソフトウェア開発者は、所与のゲーム又はアプリケーションを実行するサーバー402にとって理想的なサーバー構成を選択し、次いで、最適なドライバを伴うサーバー402を構成することができ、そして時間の経過と共に、開発者は、ホスティングサービス210におけるゲーム又はアプリケーションの全てのコピーに更新、バグ修理、等を一度に与えることができる。実際に、ユーザがホスティングサービス210の使用を開始した後に、ユーザは、おそらく、例えば、更新及び/又はバグ修理を通じて優れた経験を与え続けるゲーム及びアプリケーションを見出し、そしてユーザは、1年前に存在しなかったコンピューティング技術例えば、高性能GPUを使用するサービス210に新たなゲーム又はアプリケーションを利用できることを1年後に発見し、ひいては、1年後にゲームをプレイし又はアプリケーションを実行する技術を1年前に買うことがユーザにとって不可能であったことを発見することになろう。ゲームをプレイし又はアプリケーションを実行する計算リソースは、ユーザには見えないから即ち、ユーザの観点から、ユーザは、テレビのチャンネルを切り換えるのと同様に、ほぼ瞬時に実行を開始するゲーム又はアプリケーションを単に選択するだけであるから、ユーザのハードウェアは、ユーザが絶えずアップグレードに気付かなくてもアップグレードされている。バックアップの必要性の排除会社、学校及び家庭においてユーザに対する別の主たる問題は、バックアップである。ローカルPC又はビデオゲームコンソールに記憶された情報例えば、コンソールの場合には、ユーザのゲーム成績及びランキングは、ディスクがフェイルするか、又は偶発的な消去があった場合に、失われる。PCのための手動又は自動バックアップを与えるアプリケーションは、多数入手でき、ゲームコンソールの状態をバックアップのためにオンラインサーバーへアップロードできるが、ローカルバックアップは、典型的に、別のローカルディスク又は他の不揮発性記憶装置へコピーして、これをどこか安全な場所に保管し組織化しなければならず、又、オンラインサービスに対するバックアップは、典型的な低コストインターネット接続を通して利用できるのがゆっくりのアップストリーム速度であるから、しばしば制限がある。図4aのホスティングサービス210では、RAIDアレイ405に記憶されるデータは、当業者に良く知られた従来のRAID構成技術を使用して、ディスクがフェイルした場合にも、データが失われず、そのフェイルしたディスクを収容しているサーバーセンターの専門家が通知を受けて、ディスクを交換し、RAIDアレイがもう一度フェイル許容となるよう自動的に更新されるように、構成することができる。更に、全てのディスクドライブが互いに近くにあり、そしてそれらの間にはSAN402を通して高速ローカルネットワークがあるので、サーバーセンターにおいて全てのディスクシステムを規則的に二次記憶装置でバックアップし、この二次記憶装置をサーバーセンターに保管するか又は離れた場所へ移すことは困難ではない。ホスティングサービス210のユーザの視点から、データは、単純に常時セキュアなものであり、バックアップについて考える必要はない。デモへのアクセスユーザは、多くの場合に、ゲーム又はアプリケーションを購入する前にそれを試したがる。上述したように、ゲーム及びアプリケーションをデモする従来の手段があるがデモの動詞形は、デモンストレーションバージョンを試すことを意味し、これは、名詞としてデモとも称される、それらの各々は、制限及び/又は不便さで悩まされている。ホスティングサービス210を使用すると、ユーザがデモを試すのが容易で且つ便利になる。実際に、全てのユーザがユーザインターフェイス以下に述べるようなを通してモデを選択して、デモを試す。デモは、デモに適したサーバー402へほぼ瞬間的にロードを行い、そして他のゲーム又はアプリケーションと同様に実行するだけである。デモが非常に高性能のサーバー402を要求するか低性能のサーバー402を要求するかに関わらず、又、どんな形式の家庭又はオフィスクライアント415をユーザが使用しても、ユーザの観点から、デモは、きちんと機能する。ゲーム又はアプリケーションデモのソフトウェア発行者は、どんなデモをどれほど長くユーザが試すことが許されるか厳密に制御することができ、そしてもちろん、デモは、デモンストレーションされるゲーム又はアプリケーションのフルバージョンにアクセスする機会をユーザに与えるユーザインターフェイスエレメントを含むことができる。デモは、おそらく、価格未満又は無料で提供されるので、あるユーザは、デモ特に、繰り返しプレイするのが楽しいゲームデモを繰り返し使用することを試みる。ホスティングサービス210は、所与のユーザに対してデモの使用を制限する種々の技術を使用することができる。最も単純な解決策は、ユーザごとにユーザIDを確立して、所与のユーザIDがデモをプレイすることが許される回数を制限することである。しかしながら、ユーザは、ユーザIDが無料の場合には、複数のユーザIDを設定することができる。この問題に対処する1つの技術は、所与のクライアント415がデモをプレイすることが許される回数を制限することである。クライアントがスタンドアローン装置である場合には、装置がシリアルナンバーを有し、ホスティングサービス210は、そのシリアルナンバーをもつクライアントによりデモをアクセスできる回数を制限することができる。クライアント415がPC又は他の装置のソフトウェアとして実行される場合には、ホスティングサービス210によりシリアルナンバーを指定してPCに記憶し、これを使用してデモの使用を制限できるが、PCをユーザが再プログラムでき且つシリアルナンバーを消去又は変更できるとすれば、PCネットワークアダプタメディアアクセスコントロールMACアドレス及び/又は他のマシン特有の識別子、例えば、ハードドライブのシリアルナンバー、等のレコードを保持して、それに対してデモの使用を制限するという別のオプションがホスティングサービス210に対して設けられる。しかしながら、ネットワークアダプタのMACアドレスを変更できるとすれば、これは、フールプルーフな方法ではない。別の解決策は、所与のIPアドレスに対してデモをプレイできる回数を制限することである。IPアドレスは、ケーブルモデム及びDSLプロバイダーによって周期的に再指定できるが、実際にはあまり頻繁に行われず、IPが、住居DSL又はケーブルモデムアクセスに対するIPアドレスのブロック内にあると決定できる場合には例えば、ISPにコンタクトすることによって、典型的に、所与の家庭に対して少数のデモ使用を確立することができる。又、家庭において同じIPアドレスを共有するNATルーターの後方に複数の装置が存在することもあるが、典型的に、住居設定では、このような装置は限定された数だけである。IPアドレスが、会社にサービスするブロック内にある場合には、1つの会社に対して多数のデモを確立することができる。しかし、結局、PCにおけるデモの数を制限する最良の方法は、上述した全ての解決策の組合せである。断固とした技術的に熟練したユーザが、繰り返しプレイされるデモの数を制限できるフールプルーフの方法はないが、多数のバリアを生成することで、ほとんどのPCユーザにとってデモシステムを悪用するトラブルは価値がなく、むしろ、デモをそれらが意図されたように使用して新たなゲーム及びアプリケーションを試せるように、充分な抑止力を生み出すことができる。学校、会社及び他の施設の利益特に、図4aに示すシステムを利用する会社、学校及び他の施設に対して著しい利益が得られる。会社及び学校は、PCをインストールし、維持し及びアップグレードすることに関連して著しいコストがかかり、それが、Mayaのような高性能アプリケーションを実行するためのPCになったときには、特にそうである。上述したように、PCは、一般的に、週の時間の僅かな部分しか利用されず、そして家庭の場合と同様に、所与のレベルの性能能力を伴うPCのコストは、オフィス又は学校環境の方がサーバーセンター環境よりも遥かに高い。大きな会社又は学校例えば、大規模な大学の場合には、そのようなエンティティのIT部門がサーバーセンターを設定し、そしてLANグレード接続を経てリモートアクセスされるコンピュータを維持するのが実際的である。LANを経て又はオフィス間のプライベートな広帯域巾接続を通してコンピュータにリモートアクセスするための解決策は、多数存在する。例えば、MicrosoftWindowsターミナルサーバーでは、又はRealVNC社からのVNCのようなバーチャルネットワーク計算アプリケーションを通して、或いはSunMicrosystemsからのシンクライアント手段を通して、ユーザは、グラフィック応答時間及びユーザ経験においてある範囲のクオリティでPC又はサーバーへのリモートアクセスを得ることができる。更に、このような自己管理型のサーバーセンターは、典型的に、単一の会社又は学校専用であり、従って、異種のアプリケーション例えば、娯楽及び会社アプリケーションが週の異なる時間に同じ計算リソースを利用するときに考えられる使用の重複の利点を取り入れることができない。従って、多くの会社及び学校は、各ユーザへのLAN速度ネットワーク接続を有するサーバーセンターをそれ自身で設定するスケール、リソース又は専門知識に欠ける。実際に、学校及び会社の大部分は、家庭と同じインターネット接続例えば、DSL、ケーブルモデムを有する。このような組織は、定常的ベース又は周期的ベースのいずれかで非常に高性能の計算の必要性を依然有している。例えば、小さな建築会社は、少数の建築家しかおらず、設計の仕事をするときに計算の必要性が比較的僅かであるが、非常に高性能の3D計算を周期的に必要とする例えば、クライアントに対する新たな建築設計の3Dフライスルーを創作するときに。図4aに示すシステムは、このような組織に非常に良く適している。組織は、典型的に非常に安価な、家庭に提供されるものと同じ種類のネットワーク接続例えば、DSL、ケーブルモデム以上のものを必要としない。それらは、安価なPCをクライアント415として利用するか、或いはPCを全く省き、制御信号ロジック413及び短待ち時間ビデオ解凍412を簡単に具現化する安価な専用装置を利用するかのいずれかである。これらの特徴は、PCの窃盗や、PC内の専用コンポーネントへのダメージに伴う問題がある学校にとって特に魅力的である。このような構成は、このような組織の多数の問題を解決するそしてこれら効果の多くは、一般的な計算を行う家庭のユーザによっても共用される。その1つとして、運営コスト最終的に、実現可能な取引を得るためにある形態でユーザへ還元されねばならないを非常に低くすることができる。というのは、a計算リソースが、週内に異なるピーク使用時間を有する他のアプリケーションと共有され、b組織が、必要な時だけ高性能計算リソースにアクセスする及びそのコストを被ることができ、c組織が、高性能計算リソースをバックアップ又は維持するためのリソースを設ける必要がないからである。海賊行為の排除更に、ゲーム、アプリケーション、双方向映画、等は、今日のように海賊行為を受けることがもはやない。各ゲームは、記憶されて、ホスティングサービスセンター210で実行されるので、ユーザには、基礎的なプログラムコードへのアクセス権が与えられず、従って、海賊行為を受けるものは何もない。ユーザがソースコードをコピーする場合でも、ユーザは、標準的なゲームコンソール又は家庭用コンピュータにおいてコードを実行することはできない。これは、標準的なビデオゲームが入手できない中国のような世界の場所に市場を開く。又、ユーザに配布されたゲームのコピーがないので、中古ゲームの再販売はできない。ゲームの開発者にとって、今日、新たな世代のゲームコンソール又はPCが市場に導入されるときに、市場の中断は僅かである。ホスティングサービス210は、コンソール又はPC技術の完全に新たな世代がユーザや開発者にアップグレードを強制し且つゲーム開発者がユーザへのハードウェアプラットホームの適時の配信に依存する現在の状況例えば、PlayStation3の場合には、その導入が1年以上遅らされ、開発者は、それが入手できるようになり且つ著しい数のユニットが購入されるまで待たねばならなかったとは対照的に、ゲームの要件が変化するにつれて時間と共に更に進歩したコンピューティング技術で徐々に更新することができる。ストリーミング双方向ビデオ以上の説明は、一般的インターネットをベースとする短待ち時間のストリーミング双方向ビデオこれは、ここで使用されるオーディオもビデオと一緒に暗示的に含むの新規な基礎的概念により可能となる広範囲なアプリケーションを述べるものである。インターネットを通してストリーミングビデオを与える従来のシステムは、長待ち時間の双方向性で具現化できるアプリケーションを可能にするだけである。例えば、リニアビデオのための再生コントロール例えば、休止、巻き戻し、早送りは、長い待ち時間で充分に機能し、リニアビデオフィードの中から選択することができる。そして、上述したように、あるビデオゲームの性質は、それらを長待ち時間でプレイすることを許す。しかし、ストリーミングビデオのための従来の解決策の長待ち時間又は低圧縮比は、ストリーミングビデオの潜在的なアプリケーションを甚だしく制限するか、又はそれらの開発を特殊なネットワーク環境へと狭め、そしてそのような環境においても、従来の技術は、ネットワークに実質的な負担を導入する。ここに述べる技術は、インターネットを通る短待ち時間のストリーミング双方向ビデオ、特に、消費者グレードのインターネット接続を通して可能になるもの、で考えられる広範囲なアプリケーションに対してドアを開く。実際上任意の量の計算パワー、任意の量の高速記憶、並びにパワフルなサーバーの中の非常に高速なネットワークでユーザ経験の向上を果たすに充分な、図4cのクライアント465と同程度に小さいクライアント装置で、実際に、新しい計算の時代を可能にする。更に、帯域巾要件は、システムの計算パワーが増大するにつれて拡大しないので即ち、帯域巾要件は、表示解像度、クオリティ及びフレームレートに結び付いているだけであるので、ブロードバンドインターネット接続が偏在し例えば、広く普及した短待ち時間のワイヤレスカバレージを通して、信頼性があり、且つ全ユーザのディスプレイ装置422のニーズを満足するに充分な広い帯域巾であるときには、典型的な消費者及び会社向けアプリケーションに対して、Windows、Linux、OSX、等を実行するPC又は移動電話のようなシッククライアントが必要か、又はAdobeFlash又はJavaのようなシンクライアントでもよいかが問題となる。ストリーミング双方向ビデオの出現は、計算アーキテクチャーの構造についての仮定を考え直す結果となった。その一例が、図15に示すホスティングサービス210のサーバーセンター実施形態である。遅延バッファ及び/又はグループビデオ1550のためのビデオ経路は、app/gameサーバー1521-1525のマルチキャストされたストリーミング双方向ビデオ出力が、経路1552を経てリアルタイムで、又は経路1551を経て選択可能な遅延の後に、app/gameサーバー1521-1525へフィードバックされる。これは、従来のサーバー又はローカル計算アーキテクチャーでは不可能であるか又は実現不能な広範囲の実際的なアプリケーション例えば、図16、17及び20に示すもののようなを可能にする。しかし、より一般的なアーキテクチャー上の特徴として、フィードバックループ1550が与えるものは、ストリーミング双方向ビデオレベルでの反復である。というのは、アプリケーションが要求したときに、ビデオを不定にループバックできるからである。これは、従来得られなかった広範囲のアプリケーションの可能性を実現できるようにする。別の重要なアーキテクチャー上の特徴は、ビデオストリームが単一方向のUDPストリームであることである。これは、実際上、ストリーミング双方向ビデオのマルチキャスティングを任意の度合いで行えるようにする対照的に、TCP/IPストリームの両方向ストリームは、ユーザの数が増えるにつれて前後通信からネットワークに益々大きな渋滞を生じることになる。マルチキャスティングは、サーバーセンター内で重要な能力である。というのは、システムが、インターネットユーザ及び実際には世界の人口の増大するニーズに応答して、1対多又は多対多で、通信を行えるようにするからである。この場合も、ストリーミング双方向ビデオ反復及びマルチキャスティングの両方の使用を示す図16について述べた例は、可能性についての非常に大きな氷山の一角に過ぎない。非トランジットピアリング一実施形態において、ホスティングサービス210は、ユーザへインターネットサービスも提供する1つ以上のインターネットサービスプロバイダーISPへの1つ以上のピア接続を有し、このようにして、ホスティングサービス210は、ISPネットワーク内に留まる非トランジットルートを通してユーザと通信することができる。例えば、ホスティングサービス210のWANインターフェイス441がコムキャストケーブルコミュニケーションズ社のネットワークに直結され、そしてユーザの家屋211にコムキャストケーブルモデムでブロードバンドサービスが供給される場合には、ホスティングサービス210とクライアント415との間のルートがコムキャストのネットワーク内に完全に確立される。その潜在的な効果は、通信コストが低く2つ以上のISPネットワーク間のIPトランジットコストが回避されるので、接続の信頼性が潜在的に高くISPネットワーク間に混雑又は他のトランジット混乱がある場合に、及び待ち時間が短いISPネットワーク間に混雑、非効率的なルート又は他の遅延がある場合にことを含む。この実施形態では、クライアント415が、最初に、セッションの始めに、ホスティングサービス210に連絡するときに、ホスティングサービス210は、ユーザの家屋211のIPアドレスを受け取る。例えば、ARINAmericanRegistryforInternetNumbersからの利用可能なIPアドレステーブルを使用して、そのIPアドレスが、別のISPを通してIPトランジットせずにユーザの家屋211へルーティングできるホスティングサービス210に接続された特定のISPに割り当てられたものであることを調べる。例えば、IPアドレスが76.21.0.0と76.21.127.255との間である場合には、そのIPアドレスは、コムキャストケーブルコミュニケーションズ社に指定される。この例において、ホスティングサービス210が、コムキャスト、ATT、及びCoxISPへの接続を維持する場合には、特定のユーザへの最適なルートを与える見込みが最も高いISPとしてコムキャストを選択する。フィードバックを使用するビデオ圧縮1つの実施形態において、首尾良い又は不首尾なタイル及び/又はフレームの配信を指示するためにクライアント装置からホスティングサービスへフィードバックが与えられる。次いで、クライアントから与えられるフィードバック情報を使用して、ホスティングサービスにおいてビデオ圧縮動作を調整する。例えば、図25a-bは、クライアント装置205とホスティングサービス210との間にフィードバックチャンネル2501が確立される本発明の一実施形態を示す。フィードバックチャンネル2501は、首尾良く受信されたタイル/フレームのパケット化された確認、及び/又は受信が不首尾なタイル/フレームの指示を送信するためにクライアント装置205によって使用される。1つの実施形態において、各タイル/フレームを首尾良く受信した後に、クライアントは、ホスティングサービス210へ確認メッセージを送信する。この実施形態では、ホスティングサービス210は、指定の期間の後に確認を受信しない場合、及び/又は送信されたものではないその後のタイル/フレームをクライアント装置205が受信したという確認を受信した場合には、パケットロスを検出する。それとは別に又はそれに加えて、クライアント装置205は、パケットロスを検出し、そしてパケットロスの指示を、そのパケットロスにより影響を受けるタイル/フレームの指示と共に、ホスティングサービス210へ送信する。この実施形態では、首尾良く配信されたタイル/フレームの連続的な確認は、要求されない。パケットロスがどのように検出されるかに関わらず、図25a-bに示す実施形態では、映像のためのIタイルの最初のセット図25aには示さずを発生した後に、エンコーダは、それに続いて、パケットロスが検出されるまでPタイルしか発生しない。図25aにおいて、2510のような各フレームは、4つの垂直タイルとして示されていることに注意されたい。フレームは、2x2、2x4、4x4、等の異なる構成でタイル化されてもよいし、或いはフレームは、タイルなしに即ち、1つの大きなタイルとして全体的にエンコードされてもよい。フレームタイル化構成の以上の例は、本発明のこの実施形態を例示するために取り上げたものである。本発明の基礎となる原理は、特定のフレームタイル構成に限定されない。Pタイルのみを送信することで、上述した全ての理由で即ち、Pタイルは、一般に、Iタイルより小さい、チャンネルの帯域巾要求が緩和される。フィードバックチャンネル2501を経てパケットロスが検出されたときには、クライアント装置205におけるデコーダ2502の状態を再初期化するために、図25bに示すように、新たなIタイルがエンコーダ2500により発生される。図示されたように、1つの実施形態では、各個々のエンコードされたフレームにより消費される帯域巾を限定するために、複数のエンコードされたフレームにわたってIタイルが分散される。例えば、各フレームが4個のタイルを含む図25では、4つの連続するエンコードされたフレーム内の異なる位置で単一のIタイルが送信される。エンコーダ2500は、この実施形態について述べる技術を、ここに述べる他のエンコード技術と合成することができる。例えば、検出されたパケットロスに応答してIタイルを発生するのに加えて、エンコーダ2500は、映像シーケンスを適切にレンダリングするのにIタイルが有益である他の環境においてIタイルを発生することができる例えば、突然のシーン移行に応答して。図26aは、クライアント装置205とホスティングサービス210との間のフィードバックチャンネル2601に依存する本発明の別の実施形態を示す。検出されたパケットロスに応答して新たなIタイル/フレームを発生するのではなく、この実施形態のエンコーダ2600は、Pタイル/フレームの依存性を調整する。最初の事柄として、この例について述べる特定の細部は、本発明の基礎的な原理に合致する必要がないことに注意されたい。例えば、この例は、Pタイル/フレームを使用して説明するが、本発明の基礎的な原理は、特定のエンコードフォーマットに限定されない。図26aにおいて、エンコーダ2600は、複数の非圧縮のタイル/フレーム2605を複数のPタイル/フレーム2606へとエンコードし、そしてそれらPタイル/フレームを、通信チャンネル例えば、インターネットを経てクライアント装置205へ送信する。クライアント装置205のデコーダ2602は、Pタイル/フレーム2606をデコードして、複数の解凍されたタイル/フレーム2607を発生する。エンコーダ2600の過去の状態2611は、ホスティングサービス210のメモリ装置2610内に記憶され、そしてデコーダ2602の過去の状態2621は、クライアント装置205のメモリ装置2620内に記憶される。デコーダの状態は、MPEG-2及びMPEG-4のようにビデオコード化システムにおいて良く知られた用語である。1つの実施形態では、メモリ内に記憶された過去の状態は、以前のPタイル/フレームからの合成データを含む。メモリ2611及び2621は、図26aに示すように、エンコーダ2600及びデコーダ2602から取り外されるのではなく、エンコーダ2600及びデコーダ2602内に一体化されてもよい。更に、例えば、これに限定されないが、ランダムアクセスメモリを含む種々の形式のメモリが使用されてもよい。1つの実施形態において、パケットロスが生じないときには、エンコーダ2600は、各Pタイル/フレームを、手前のPタイル/フレームに依存すべくエンコードする。従って、図26aに使用された表記法で示されたように、Pタイル/フレーム4は、Pタイル/フレーム3表記43を使用して識別されるに依存し、Pタイル/フレーム5は、Pタイル/フレーム4表記54を使用して識別されるに依存し、そしてPタイル/フレーム6は、Pタイル/フレーム5表記65を使用して識別されるに依存する。この例では、エンコーダ2600とデコーダ2602との間の送信中にPタイル/フレーム43が失われる。このロスは、上述したものこれに限定されないがを含む種々の仕方でエンコーダ2600へ送信することができる。例えば、デコーダ2602がタイル/フレームを首尾良く受信し及び/又はデコードするたびに、この情報をデコーダ2602からエンコーダ2600へ通信することができる。エンコーダ2600が、特定のタイル/フレームが受信され及び/又はデコードされたという指示をある期間の後に受信しない場合には、エンコーダ2600は、タイル/フレームが首尾良く受信されなかったと仮定する。それとは別に又はそれに加えて、デコーダ2602は、特定のタイル/フレームが首尾良く受信されなかったときにエンコーダ2600に通知することができる。1つの実施形態において、失われたタイル/フレームがどのように検出されるかに関わらず、それが生じると、エンコーダ2600は、デコーダ2602により首尾良く受信されたことが分かっている最後のタイル/フレームを使用して次のタイル/フレームをエンコードする。図26aに示す例では、タイル/フレーム5及び6は、首尾良く受信されたと考えられない。というのは、それらは、タイル/フレーム4のロスのためにデコーダ2602により適切にデコードできないからである即ち、タイル/フレーム5のデコーディングは、タイル/フレーム4に依存し、そしてタイル/フレーム6のデコーディングは、タイル/フレーム5に依存する。従って、図26aに示す例では、エンコーダ2600は、タイル/フレーム7を、デコーダ2602が適切にデコードできないタイル/フレーム6ではなくて、タイル/フレーム3最後に首尾良く受信されたタイル/フレームに依存すべくエンコードする。図26aには示されていないが、付加的なパケットロスが検出されないと仮定すれば、タイル/フレーム8は、その後、タイル/フレーム7に依存すべくエンコードされ、そしてタイル/フレーム9は、タイル/フレーム8に依存すべくエンコードされる。上述したように、エンコーダ2600及びデコーダ2602は、両方とも、過去のエンコーダ及びデコーダ状態2611及び2621を各々メモリ2610及び2620に維持する。従って、タイル/フレーム7をエンコードするときに、エンコーダ2600は、タイル/フレーム3に関連した以前のエンコーダ状態をメモリ2610から検索する。同様に、デコーダ2602に関連したメモリ2620は、少なくとも最後に知られた良好なデコーダ状態この例では、Pタイル/フレーム3に関連した状態を記憶する。その結果、デコーダ2602は、タイル/フレーム7をデコードできるようにタイル/フレーム3に関連した過去の状態情報を検索する。上述した技術の結果として、Iタイル/フレームが要求されないのでストリームのスタートにデコーダ及びエンコーダを初期化する以外、比較的小さな帯域巾を使用して、リアルタイム、短待ち時間の双方向ビデオをエンコードし、ストリーミングすることができる。更に、デコーダにより発生されるビデオ映像は、失われたタイル/フレーム4及びこの失われたタイル/フレーム4のために適切にデコードできないタイル/フレーム5及び6から生じる望ましからぬ歪を一時的に含むが、この歪は、非常に短い時間中、見ることができる。更に、フルビデオフレームではなくタイルが使用される場合には、歪は、レンダリングされるビデオ映像の特定の領域に限定される。本発明の一実施形態による方法が図26bに示されている。2650において、以前に発生されたタイル/フレームに基づいて、タイル/フレームが発生される。2651において、失われたタイル/フレームが検出される。1つの実施形態では、失われたタイル/フレームは、上述したように、エンコーダからデコーダへ通信される情報に基づいて検出される。2652において、首尾よく受信され及び/又はデコーダでデコードされたと分かっているタイル/フレームに基づいて次のタイル/フレームが発生される。1つの実施形態では、エンコーダは、首尾良く受信され及び/又はデコードされたタイル/フレームに関連した状態をメモリからロードすることにより次のタイル/フレームを発生する。同様に、デコーダは、新たなタイル/フレームを受信すると、首尾良く受信され及び/又はデコードされたタイル/フレームに関連した状態をメモリからロードすることによりタイル/フレームをデコードする。1つの実施形態において、首尾良く受信され及び/又はエンコーダにおいてデコードされた最後のタイル/フレームに基づいて、次のタイル/フレームが発生される。別の実施形態では、発生される次のタイル/フレームがIタイル/フレームである。更に別の実施形態では、以前に首尾良く受信されたタイル/フレームに基づいて次のタイル/フレームを発生するか又はIフレームとして発生するかの選択は、どれほど多くのタイル/フレームが失われたか、及び/又はチャンネルの待ち時間に基づく。比較的少数例えば、1又は2のタイル/フレームが失われ、そして往復待ち時間が比較的短い例えば、1又は2フレームの時間状況では、Pタイル/フレームを発生するのが最適である。というのは、首尾良く受信された最後のタイル/フレームと、新たに発生されるタイル/フレームとの間の差が比較的小さいからである。多数のタイル/フレームが失われるか又は往復待ち時間が長い場合には、Iタイル/フレームを発生するのが最適である。というのは、首尾良く受信された最後のタイル/フレームと、新たに発生されるタイル/フレームとの間の差が大きいからである。1つの実施形態では、Iタイル/フレームを送信するか、Pタイル/フレームを送信するか決定するために、タイル/フレームロススレッシュホールド及び/又は待ち時間スレッシュホールド値がセットされる。失われたタイル/フレームの数がタイル/フレームロススレッシュホールドより低く、及び/又は往復待ち時間が待ち時間スレッシュホールド値より低い場合には、新たなIタイル/フレームが発生され、さもなければ、新たなPタイル/フレームが発生される。1つの実施形態において、エンコーダは、常に、首尾良く受信された最後のタイル/フレームに対してPタイル/フレームを発生するように試み、そしてエンコーディングプロセスにおいて、Pタイル/フレームがおそらくIタイル/フレームより大きいことをエンコーダが決定した場合には例えば、それがタイル/フレームの圧縮された1/8を有し、そして圧縮されたサイズが、以前に圧縮された平均Iタイル/フレームのサイズの1/8より大きい場合には、エンコーダは、Pタイル/フレームの圧縮を断念し、それに代わって、Iタイル/フレームを圧縮する。失われたパケットの発生が頻繁でない場合には、ドロップしたタイル/フレームを報告するためにフィードバックを使用する前記システムは、典型的に、ユーザへのビデオストリームに生じる混乱を非常に僅かなものにする。というのは、エンコーダ2600がタイル/フレームを短時間で圧縮すると仮定すれば、失われたパケットにより混乱を受けるタイル/フレームが、ほぼ1往復の時間に、クライアント装置205とホスティングサービス210との間で置き換わるからである。そして、圧縮される新たなタイル/フレームは、非圧縮のビデオストリームの後期フレームに基づくものであるから、ビデオストリームが非圧縮ビデオフレームの後方に入ることはない。しかし、新たなタイル/フレームを含むパケットも失われた場合には、少なくとも2往復の遅延を招き、別の新たなタイル/フレームを再び要求及び送信することになり、これは、多くの実際的な状況において、ビデオストリームに著しい混乱を招くことがある。その結果、ドロップしたタイル/フレームの後に送信される新たにエンコードされたタイル/フレームがホスティングサービス210からクライアント装置205へ首尾良く送信されることが非常に重要である。1つの実施形態において、図11a、11b、11c及び11dに示されて上述されたもののような順方向エラー修正FECコード化技術を使用して、新たにエンコードされたタイル/フレームを失う確率を軽減する。タイル/フレームを送信するときにFECコーディングが既に使用されている場合には、新たにエンコードされるタイル/フレームに対してより強いFECコードが使用される。ドロップしたパケットの1つの潜在的な原因は、例えば、ユーザの家屋211におけるブロードバンド接続の他のユーザが多量の帯域巾を使用し始める場合にチャンネル帯域巾が突然失われることである。FECが使用される場合でも新たに発生されたタイル/フレームもパケットのドロップのために失われる場合には、1つの実施形態において、新たにエンコードされた第2のタイル/フレームがドロップしたことがクライアント415によりホスティングサービス210に通知されるとき、ビデオコンプレッサ404は、その後に新たにエンコードされるタイル/フレームをエンコードするときにデータレートを下げる。異なる実施形態では、異なる技術を使用してデータレートが減少される。例えば、1つの実施形態において、このデータレートの低下は、圧縮比を高めることにより、エンコードされたタイル/フレームのクオリティを下げることで、達成される。別の実施形態では、ビデオのフレームレートを下げ例えば、60fpsから30fpsへ、それに応じて、データ送信のレートを低速にすることで、データレートが下げられる。一実施形態では、データレートを下げるために両方の技術が使用される例えば、両方とも、フレームレートを下げ、圧縮比を上げる。データ送信のこの低いレートが、パケットのドロップを首尾良く軽減する場合には、上述したチャンネルデータレート検出及び調整方法により、ホスティングサービス210は、低いデータレートでエンコーディングを続け、次いで、チャンネルが許すとき、データレートを徐々にアップ方向又はダウン方向に調整する。ドロップしたパケット及び/又は待ち時間に関連したフィードバックデータを受信し続けることで、ホスティングサービス210は、現在チャンネル状態に基づいてデータレートを動的に調整することが許される。オンラインゲームシステムにおける状態管理本発明の一実施形態は、能動的ゲームの現在状態を効率的に記憶してサーバー間で搬送する技術を使用する。ここに述べる実施形態は、オンラインゲームに係るものであるが、本発明の基礎的な原理は、種々の他の形式のアプリケーション例えば、設計アプリケーション、ワードプロセッサ、e-メール又はインスタントメッセージングのような通信ソフトウェア、等にも使用することができる。図27aは、この実施形態を具現化するための規範的なシステムアーキテクチャーを示し、図27bは、規範的な方法を示す。この方法及びシステムアーキテクチャーは、同時に説明するが、図27bに示す方法は、特定のシステムアーキテクチャーに限定されない。図27bの2751において、ユーザは、クライアント装置205からホスティングサービス210の新たなオンラインゲームを開始する。それに応答して、2752において、ゲーム2702aのクリーン映像が記憶装置例えば、ゲームを実行するサーバーに直結されるか、又はネットワークを通してサーバーに接続されるかに関わらず、ハードドライブから、ホスティングサービス210aのメモリ例えば、RAMへロードされる。クリーン映像は、例えば、ゲームを初めて実行するときのようにゲームのプレイを開始する前のゲームのためのランタイムプログラムコード及びデータを含む。ユーザは、次いで、2753において、ゲームをプレイし、クリーン映像を非クリーン映像例えば、図27aにおいて状態Aで表された実行ゲームへ変化させる。2754において、ユーザ又はホスティングサービス210aによってゲームが休止又は終了される。2755において、ホスティングサービス210aの状態管理ロジック2700aは、ゲームのクリーン映像と現在ゲーム状態状態Aとの間の相違を決定する。例えば、Unixオペレーティングシステムで利用できる良く知られたdiffユーティリティに使用されるものを含む2つのバイナリ映像間の差を計算するために、種々の既知の技術を使用することができる。もちろん、本発明の基礎的な原理は、差を計算するための特定の技術に限定されない。どのように差を計算するかに関わらず、それらが計算されると、差のデータが記憶装置2705a内にローカル記憶され、及び/又は異なるホスティングサービス210bへ送信される。異なるホスティングサービス210bへ送信される場合には、差のデータが、新たなホスティングサービス210bにおける記憶装置図示せずに記憶される。いずれの場合にも、差のデータは、ホスティングサービスにおけるユーザのアカウントに関連付けられ、ユーザがホスティングサービスにログインしてゲームを開始する次のときに、それが識別される。1つの実施形態では、直ちに送信されるのではなく、ユーザがゲームのプレイを試みる且つ異なるホスティングサービスが、ゲームをホストする最良の選択肢として識別される次のときまで、差のデータは、新たなホスティングサービスへ送信されない。図27bに示す方法に戻ると、2757において、ユーザは、ユーザが最初にゲームをプレイした同じクライアント装置205であるか、又は異なるクライアント装置図示せずであるクライアント装置からゲームを再開する。それに応答して、2758において、ホスティングサービス210bの状態管理ロジック2700bは、ゲームのクリーン映像を記憶装置及び差のデータから検索する。2759において、状態管理ロジック2700bは、クリーン映像及び差のデータを合成して、ゲームがオリジナルのホスティングサービス210aにあったときの状態状態Aを再構成する。例えば、Unixオペレーティングシステムで利用できる良く知られたパッチユーティリティに使用されるものを含む差のデータを使用してバイナリ映像の状態を再構成するために、種々の既知の技術を使用することができる。PCバックアップのような良く知られたバックアッププログラムに使用される差の計算技術を使用してもよい。本発明の基礎的な原理は、差のデータを使用してバイナリ映像を再生成する特定の技術に限定されない。加えて、2760において、プラットホーム依存データ2710が最終的なゲーム映像2701bに合体される。プラットホーム依存データ2710は、行先サーバープラットホームに対して独特のデータを含む。例えば、これに限定されないが、プラットホーム依存データ2710は、新たなプラットホームのメディアアクセスコントロールMACアドレス、TCP/IPアドレス、1日の時刻、ハードウェアシリアル番号例えば、ハードドライブ及びCPUのための、ネットワークサーバーアドレス例えば、DHCP/Winsサーバー、及びソフトウェアシリアル番号/アクチベーションコードオペレーティングシステムシリアル番号/アクチベーションコードを含むを含む。クライアント/ユーザに関連した他のプラットホーム依存データは、次のものを含むこれに限定されないが。1.ユーザスクリーンの解像度。ユーザがゲームを再開するときに、ユーザは、異なる解像度の異なる装置を使用してもよい。2.ユーザコントローラの構成。ゲームが再開するとき、ユーザは、ゲームコントローラからキーボード/マウスへスイッチすることができる。3.割引率が終了になったかどうか例えば、ユーザが促進期間中にゲームをプレイしていたが、今や、通常期間の高いコストでプレイする場合、又はユーザ又は装置に何らかの年齢制約があるかどうか例えば、ユーザの親が子供に対する設定を切り換え、子供が成人向け資料を見られないようにする、又はゲームをプレイする装置例えば、パブリックライブラリのコンピュータが、成人向け資料を表示できるかどうかについて何らかの制約を有するかどうか、のようなユーザの資格。4.ユーザのランク。ユーザは、あるリーグにおいてマルチプレーヤゲームをプレイすることが許されているが、他の若干のユーザがユーザランクを越えるために、ユーザは、より低いリーグへ格下げされる。プラットホーム依存データ2710の以上の例は、本発明の実施形態を例示するために取り上げられたものである。本発明の基礎的な原理は、プラットホーム依存データの特定のセットに限定されない。図28は、第1のホスティングサービスにおける状態管理ロジック2700aが実行ゲーム2701aから差のデータ2800をどのように抽出するかグラフで示す。第2のホスティングサービスにおける状態管理ロジック2700bは、次いで、クリーン映像2702bを差のデータ2800及びプラットホーム依存データ2710と合成し、実行ゲーム2701bの状態を再生する。図28に一般的に示すように、差のデータのサイズは、全ゲーム映像2701aのサイズより著しく小さく、その結果、差のデータだけを記憶/送信することで、著しい量の記憶スペース及び帯域巾が保存される。図28には示されていないが、プラットホーム依存データ2700は、若干の差のデータを、それが最終的なゲーム映像2701bに合体されるときに、オーバーライトすることができる。オンラインビデオゲームの具現化について上述したが、本発明の基礎的な原理は、ビデオゲームに限定されない。例えば、以上の状態管理技術は、任意の形式のオンラインホストアプリケーションの環境内で具現化することができる。クライアントデコーダを維持する技術本発明の一実施形態において、ホスティングサービス210は、ユーザがホスティングサービス210への接続を要求するたびに、クライアント装置205へ新たなデコーダを送信する。従って、この実施形態では、クライアント装置により使用されるデコーダは、常に、最新のものであり、クライアント装置において具現化されるハードウェア/ソフトウェアに対して独特に仕立てられる。図29に例示されたように、この実施形態では、クライアント装置205に永久的にインストールされるアプリケーションは、デコーダを含まない。むしろ、クライアント装置205がホスティングサービス210に接続されるたびに一時的デコーダ2900のダウンロード及びインストールを管理するのはクライアントダウンローダーアプリケーション2903である。このダウンローダーアプリケーション2903は、ハードウェア、ソフトウェア、ファームウェア、又はその組み合わせで具現化することができる。新たなオンラインセッションに対するユーザ要求に応答して、ダウンローダーアプリケーション2903は、クライアント装置205に関連した情報を、ネットワーク例えば、インターネットを経て送信する。この情報は、クライアント装置及び/又はクライアント装置のハードウェア/ソフトウェア構成例えば、プロセッサ、オペレーティングシステム、等を識別する識別データを含む。この情報に基づき、ホスティングサービス210のダウンローダーアプリケーション2901は、クライアント装置205に使用されるべき適当な一時的デコーダ2900を選択する。ホスティングサービスのダウンローダーアプリケーション2901は、次いで、一時的デコーダ2900を送信し、そしてクライアント装置のダウンローダーアプリケーション2903は、クライアント装置205のデコーダを検証し及び/又はインストールする。エンコーダ2902は、次いで、ここに述べるいずれかの技術を使用してオーディオ/ビデオコンテンツをエンコードし、そしてコンテンツ2910をデコーダ2900へ送信する。新たなデコーダ2900がインストールされると、現在オンラインセッションに対するコンテンツをデコードする即ち、ここに述べるオーディオ/ビデオ解凍技術の1つ以上を使用して。一実施形態において、セッションが終了したときに、デコーダ2900がクライアント装置205から除去される例えば、アンインストールされる。一実施形態では、ダウンローダーアプリケーション2903は、一時的デコーダ2900がダウンロードされるときに、チャンネルにおいて達成できるデータレート例えば、データをダウンロードするのにどれほどの時間を要するか決定することにより、チャンネルにおけるパケットロスレート、及びチャンネルの待ち時間のようなチャンネル評価を行うことにより、チャンネルを特徴付ける。ダウンローダーアプリケーション2903は、チャンネル評価を表すチャンネル特徴付けデータを発生する。このチャンネル特徴付けデータは、次いで、クライアント装置205からホスティングサービスのダウンローダー2901へ送信され、このダウンローダーは、チャンネル特徴付けデータを使用して、クライアント装置205へメディアを送信するためにチャンネルをどのように最良に使用するか決定する。クライアント装置205は、典型的に、一時的デコーダ2900のダウンロード中にホスティングサービス210へメッセージを返送する。これらのメッセージは、パケットがエラーなく受信されたかエラーがあったかを指示する確認メッセージを含むことができる。加えて、これらのメッセージは、データレートパケットが受信されるレートに基づいて計算された、パケットエラーレートエラーを伴って受信されたと報告されたパケットのパーセンテージに基づく、及びチャンネルの往復待ち時間送信された所与のパケットに関するフィードバックをダウンローダー2901が受信するまでに要した時間長さに基づくに関してダウンローダー2901へフィードバックを与える。例えば、データレートが2Mbpsと決定された場合には、ダウンローダーは、データレートが5Mbpsと決定された場合例えば、60fpsにおいて1280x720より小さなビデオウインドウ解像度をエンコーダ2902に対して選択する例えば、60fpsにおいて640x480。パケットロスの割合に基づいて、異なる順方向エラー修正FEC又はパケット構造を選択することができる。パケットロスが非常に低い場合には、圧縮されたオーディオ及びビデオは、エラー修正なしに送信される。パケットロスが中程度の場合には、圧縮されたオーディオ及びビデオは、エラー修正コード技術例えば、図11a、11b、11c及び11dに示されて上述されたようなで送信される。パケットロスが非常に高い場合には、充分なクオリティのオーディオビジュアルストリームを送信できないと決定され、クライアント装置205は、通信チャンネル即ち、リンクを通してホスティングサービスを利用できないことをユーザに通知するか、又はパケットロスの低いホスティングサービスへの異なるルートを確立するよう試みることができる以下に述べるように。待ち時間が短い場合には、圧縮されたオーディオ及びビデオを短い待ち時間で送信してセッションを確立することができる。待ち時間が非常に長い例えば、80msより長い場合には、短い待ち時間を要求するゲームにとって、クライアント装置205は、リンクを通してホスティングサービスを利用できないか、又はリンクは利用できるが、ユーザ入力に対する応答時間が鈍いか又は遅れるか、或いは待ち時間の短いホスティングサービスへの異なるルートの確立をユーザが試みることができることを、ユーザに通知することができる以下に述べるように。クライアント装置205は、ネットワーク例えば、インターネットを通る別のルートを経てホスティングサービス210への接続を試み、障害が減少されたかどうか例えば、パケットロスが低くなったか、待ち時間が短くなったか、又はデータレートが高くなったか調べることができる。例えば、ホスティングサービス210は、地理的に多数の位置例えば、ロスアンジェルス及びデンバーのホスティングセンターからインターネットに接続することができ、おそらく、ロスアンジェルスでは混雑のためにパケットロスが高いが、デンバーでは混雑がない。又、ホスティングサービス210は、複数のインターネットサービスプロバイダー例えば、ATT及びComcastを通してインターネットに接続することができる。クライアント装置205と、サービスプロバイダーの1つ例えば、ATTとの間の混雑又は他の問題のために、パケットロス及び/又は長い待ち時間及び/又は制約のあるデータレートを招くことがある。しかしながら、クライアント装置205が別のサービスプロバイダー例えば、Comcastを通してホスティングサービス210に接続される場合には、混雑の問題なく、及び/又は低いパケットロス及び/又は短い待ち時間及び/又は高いデータレートで接続することができる。従って、クライアント装置205は、指定のスレッシュホールド例えば、指定の期間にわたる指定のドロップパケット数を越えるパケットロス、指定のスレッシュホールドを越える待ち時間、及び/又は一時的デコーダ2900をダウンロードする間の指定のスレッシュホールドより低いデータレートを経験した場合に、一実施形態では、典型的に異なるIPアドレス又は異なるドメイン名へ接続することにより別のルートを経てホスティングサービス210への再接続を試み、より良い接続が得られるかどうか決定する。別の接続オプションが尽きた後に接続がまだ受け容れられない障害を経験している場合には、インターネットへのクライアント装置205のローカル接続が障害を被っているか、又は適度な待ち時間を達成するのにホスティングサービス210から離れ過ぎている。このような場合には、クライアント装置205は、リンクを通してホスティングサービスが利用できないか、又は障害を伴う状態でしか利用できないか、及び/又はある形式の短待ち時間ゲーム/アプリケーションしか利用できないことをユーザに通知する。一時的デコーダがダウンロードされている間にホスティングサービス210とクライアント装置205との間のリンク特性のこの評価及び潜在的な改善が行われるので、クライアント装置205が一時的デコーダ2900のダウンロードとリンク特性の評価とに別々に費やす必要のある時間量が短縮される。それでも、別の実施形態では、リンク特性の評価及び潜在的な改善は、クライアント装置205により、一時的デコーダ2900をダウンロードすることから別々に遂行される例えば、デコーダプログラムコードではなく、ダミーテストデータを使用することにより。これが好ましい具現化であることの理由は多数ある。例えば、ある実施形態では、クライアント装置205は、その一部分又は全体がハードウェアで具現化される。従って、これらの実施形態では、ダウンロードに必要なソフトウェアデコーダは存在しない。規格ベースのタイルサイズを使用する圧縮上述したように、タイルベースの圧縮が使用されるときに、本発明の基礎的な原理は、特定のタイルサイズ、形状又は方向に限定されない。例えば、MPEG-2及びMPEG-4のようなDCTベースの圧縮システムでは、タイルは、マクロブロック16x16ピクセルのブロックを典型的に表すビデオ圧縮に使用されるコンポーネントのサイズである。この実施形態は、タイルと共に作用するための非常に微細な粒度レベルを与える。更に、タイルサイズに関わりなく、種々の形式のタイルパターンを使用することができる。例えば、図30は、各Rフレーム3001-3004に複数のIタイルが使用される一実施形態を示す。Iタイルが各Rフレーム全体に分散されて、4個のRフレームごとに1つの完全なIフレームが発生されるような回転パターンが使用される。このように、Iタイルを分散することで、パケットロスの影響が減少されるロスをディスプレイの小さな領域に制限する。又、タイルは、基礎的な圧縮アルゴリズムの一体的なネーティブ構造に対するサイズであってもよい。例えば、H.264圧縮アルゴリズムが使用される場合には、1つの実施形態において、タイルがH.264スライスのサイズにセットされる。これは、ここに述べる技術を、H.264及びMPEG-4のような種々の異なる標準圧縮アルゴリズムの環境に容易に一体化できるようにする。タイルサイズがネーティブな圧縮構造にセットされると、上述したものと同じ技術を具現化することができる。ストリーム巻き戻し及び再生動作の技術図15を参照して上述したように、app/gameサーバー1521-1525により発生される非圧縮のビデオ/オーディオストリーム1529は、複数の解像度の共有ハードウェア圧縮1530により同時に圧縮されて、複数の圧縮されたビデオ/オーディオストリーム1539を生じる。例えば、app/gameサーバー1521により発生されたビデオ/オーディオストリームは、共有ハードウェア圧縮1530により1280x720x60fpsで圧縮され、アウトバウンドインターネットトラフィック1599としてアウトバウンドルート1540を経てユーザへ送信される。その同じビデオ/オーディオストリームは、共有ハードウェア圧縮1530によりapp/gameサーバー1522への経路1522を経て又は遅延バッファ1515を通してサムネールサイズ例えば、200x113へ同時にスケールダウンされ、図16のサムネールの集合体の1つのサムネール1600として表示される。サムネール1600が図17の中間サイズ1700を通して図18のサイズ18001280x720x60fpsへとズームされるときに、サムネールストリームを解凍するのではなく、app/gameサーバー1522は、app/gameサーバー1521のユーザへ送られる1280x720x60fpsストリームのコピーを解凍し、そして高解像度ビデオを、それがサムネールサイズからズームされるときに、1280x720サイズへとスケーリングする。この解決策は、1280x720の圧縮されたストリームを、2回、再使用するという効果を有する。しかし、幾つかの欠点もある。aユーザへ送信される圧縮されたビデオストリームは、ユーザのインターネット接続のデータスループットが変化する場合には画質が変化し、たとえそのユーザのインターネット接続が変化しなくても、app/gameサーバー1522の見物ユーザが見る画質が変化することになり、bapp/gameサーバー1522は、処理リソースを使用して、1280x720映像全体を解凍し、次いで、ズーム中に相当に小さいサイズ例えば、640x360を表示するためにその映像をスケーリング及びおそらく再サンプリングフィルタを適用しなければならず、cインターネット接続帯域巾の制限及び/又はパケットの消失/崩壊のためにフレームがドロップし、そして見物ユーザが遅延バッファ1515に記録されたビデオを巻き戻し及び休止する場合には、見物ユーザは、ドロップしたフレームが遅延バッファに見つからないことが分かりこれは、ユーザがフレームごとにステップする場合には特に明らかであり、及びd見物ユーザが遅延バッファに記録されたビデオにおける特定のフレームを見出すために巻き戻す場合には、app/gameサーバー1522は、遅延バッファに記録されたビデオストリームにおける探し求めるフレームの前にIフレーム又はIタイルを見出し、次いで、希望のフレームに到達するまで全てのPフレーム/タイルを解凍しなければならない。この同じ限定が、ビデオ/オーディオストリームを生で見物しているユーザに適用されるだけでなく、ビデオ/オーディオストリームのアーカイブ例えば、BragClipコピーを見ているユーザビデオ/オーディオストリームを発生したユーザを含むにも適用される。本発明の別の実施形態は、ビデオストリームを2つ以上のサイズ及び/又は構造で圧縮することによりこれらの問題に対処する。1つのストリーム生のストリームは、ここに述べるように、ネットワーク接続の特性例えば、データ帯域巾、パケット信頼性、及びユーザのローカルクライアント能力例えば、解凍能力、表示解像度に基づいて、エンドユーザへのストリームへと最適に圧縮される。他のストリームHQストリームと称されるは、高いクオリティ、1つ以上の解像度、及びビデオ再生可能な構造で圧縮され、このようなHQストリームは、ルーティングされて、サーバーセンター210内に記憶される。例えば、1つの実施形態において、HQ圧縮ストリームは、RAIDディスクアレイ1515に記憶され、そして休止、巻き戻し及び他の再生機能例えば、他のユーザへ配布されて見られるBragClipを与えるのに使用される。図31aに示すように、本発明の一実施形態は、ストリームの混乱のために、或いはIタイル又はIフレームが上述したIタイル又はIフレームよりおそらく小さいと決定されるために、必要でない限り、1つはIタイル又はIフレーム3110を周期的に含みそしてもう1つはIタイル又はIフレーム3111を含まない少なくとも2つのフォーマットでビデオストリームを圧縮できるエンコーダ3100を備えている。例えば、ビデオゲームをプレイしている間にユーザへ送信される生のストリーム3111は、Pフレームのみを使用して圧縮される上述したように、Iタイル又はIフレームが必要でも小さいものでもない限り。加えて、この実施形態のエンコーダ3100は、生のビデオストリーム3111を、一実施形態においてIタイル又はIフレームを周期的に含む第2のフォーマット又は同様の形式の映像フォーマットで同時に圧縮する。上述した実施形態は、Iタイル、Iフレーム、Pタイル及びPフレームを使用するが、本発明の基本的な原理は、特定の圧縮アルゴリズムに限定されない。例えば、フレームが以前の又はその後のフレームに依存する任意の形式の映像フォーマットを、Pタイル又はPフレームに代わって使用することができる。同様に、以前の又はその後のフレームに依存しない任意の形式の映像フォーマットを、前記Iタイル又はIフレームに置き換えることもできる。上述したように、HQストリーム3110は、周期的なIフレーム例えば、一実施形態では、12フレームごと、等々を含む。これは、ユーザが記憶されたビデオストリームを特定のポイントへ素早く巻き戻すことを希望する場合に、Iタイル又はIフレームが要求されるので、意義深いことである。Pフレームだけの圧縮されたストリームでは即ち、シーケンスの第1フレームがIフレームでないと、デコーダは、数時間の長さのこともあるシーケンスの第1フレームへ戻り、ユーザが巻き戻しを希望するポイントまでPフレームを解凍する必要がある。HQストリーム3110に記憶された12フレームごとのIフレームでは、ユーザは、特定のスポットへ巻き戻すことを決心し、その直前のHQストリームのIフレームは、希望のフレームより12以下のフレームだけ前である。デコーダの最大デコードレートがリアルタイム例えば、60フレーム/秒のストリームに対して1/60秒である場合でも、12フレーム/60フレーム/秒=1/5秒だけIフレームから離れている。そして、多くの場合に、デコーダは、リアルタイムより非常に速く動作することができ、例えば、2xリアルタイムで、デコーダは、6フレーム内に12フレームをデコードすることができ、これは、巻き戻しに対する第2の遅延の1/10に過ぎない。言うまでもなく、高速デコーダ例えば、10xリアルタイムでも、直前のIフレームが巻き戻しポイントより多数のフレーム分だけ前にある場合には受け容れられない遅延をもつことになる例えば、巻き戻しを行うのに1時間/10=6分を要する。別の実施形態では、周期的なIタイルが使用され、この場合に、ユーザが巻き戻しを求めるとき、デコーダは、直前のIタイルを巻き戻しポイントの前に見出し、次いで、巻き戻しポイントまで全てのタイルがデコードされるまで、そのポイントからそのタイルのデコーディングを開始する。周期的なIタイル又はIフレームは、Iフレーム全体を排除するより効率の悪い圧縮となるが、ホスティングサービス210は、典型的に、HQストリームを管理するのに充分過ぎるローカル利用帯域巾及び記憶容量を有する。別の実施形態において、エンコーダ3100は、HQストリームを、上述したように、周期的なIタイル又はIフレームで、それに続いて、Pタイル又はPフレームでエンコードするが、それに先行して、Bタイル又はBフレームでエンコードする。Bフレームは、上述したように、Iフレームに先行するフレームであり、時間的に後方に作用するIフレームからのフレーム差に基づくものである。Bタイルは、Iタイルに先行するタイル対応部であり、Iタイルから後方に作用するフレーム差に基づくものである。この実施形態において、望ましい巻き戻しポイントがBフレームである又はBタイルを含む場合には、デコーダは、直前のIフレーム又はIタイルを見出し、そして希望の巻き戻しポイントがデコードされるまで時間的に後方にデコードし、次いで、ビデオの再生がそのポイントから前方に進むにつれて、デコーダは、前方に向かう次々のフレームにおいて、Bフレーム、Iフレーム及びPフレーム又はそれらのタイル対応部をデコードする。I及びP形式に加えてBフレーム又はBタイルを使用する効果は、所与の圧縮比においてしばしば高いクオリティを達成できることである。更に別の実施形態では、エンコーダ3100は、HQストリームを全てのIフレームとしてエンコードする。この解決策の効果は、各巻き戻しポイントがIフレームであり、その結果、巻き戻しポイントに到達するために他のフレームをデコードする必要がないことである。欠点は、圧縮データレートが、I、P又はI、P、Bストリームのエンコーディングに比して非常に高いことである。他のビデオストリーム再生アクション例えば、高速又は低速巻き戻し、高速又は低速送り、等は、典型的に、周期的なIフレーム又はIタイルで単独であるか又はP及び/又はB対応部と組み合わされて非常に実際的に達成される。というのは、各々の場合に、ストリームは、フレームごとに時間的に前方にではなく、異なるフレーム順序で再生され、その結果、デコーダは、シーケンスにおける特定のしばしば任意のフレームを見出してデコードする必要があるからである。例えば、非常に高速の送り例えば、100x速度の場合には、再生される各次々のフレームが、手前のフレームより100フレーム後である。10xリアルタイムで動作し、1フレームの時間内に10フレームをデコードするデコーダでも、100x高速送りを達成するには、依然、10x遅過ぎである。一方、上述した周期的なIフレーム又はIタイルでは、デコーダは、次に表示する必要のあるフレームに対して最も近い適用可能なIフレーム又はIタイルを探し、そしてターゲットフレームポイントまでの介在するフレーム又はタイルのみをデコードすることができる。別の実施形態では、Iフレームは、HQストリームにおいて一貫した周期例えば、常に、8フレームごとでエンコードされ、そしてIフレームレートより速い高速送り及び巻き戻しに対してユーザに使用できる速度乗数は、Iフレーム周期の厳密な倍数である。例えば、Iフレーム周期が8フレームである場合には、ユーザに使用できる高速送り又は巻き戻しの速度は、1X、2X、3X、4X、8X、16X、64X、128X及び256Xである。Iフレーム周期より速い速度の場合には、デコーダは、最初、その速度でのフレーム数だけ先の最も近いIフレームへ前進ジャンプし例えば、現在表示されているフレームが、Iフレームより3フレーム前の場合には、128Xにおいて、デコーダは、フレーム1283フレーム先へジャンプし、次いで、各次々のフレームに対し、デコーダは、選択された速度として厳密なフレーム数だけジャンプし例えば、128Xの選択された速度では、デコーダは、128フレームジャンプし、そのたびにIフレームに厳密に着地する。従って、Iフレーム周期より速い全ての速度がIフレーム周期の厳密な倍数であるとすれば、デコーダは、希望のフレームを探すためにその先行又は後続フレームをデコードする必要がなく、表示フレーム当たり1つのIフレームをデコードするだけでよい。Iフレーム周期よりゆっくりとした速度例えば、1X、2X、3X、4X、又はIフレーム周期の倍数でない速い速度の場合には、デコーダは、希望のフレームを表示するために付加的な新たにデコードされるフレームを最低限しか必要としないのはどのフレームか求め、未デコードのIフレーム又は既にデコードされたフレームは、デコードされた形態で依然利用できるようにしRAM又は他の高速記憶装置において、次いで、希望のフレームがデコードされ表示されるまで、介在フレームを必要に応じてデコードする。例えば、4Xの高速送りでは、8XのIフレーム周期性をもつI、Pエンコードシーケンスにおいて、現在フレームが、Iフレームの1フレーム後のPフレームである場合に、表示されるべき希望のフレームは、4フレーム後となり、これは、先行するIフレームに続く5番目のPフレームである。現在表示されたフレーム丁度デコードされたがスタートポイントとして使用される場合には、デコーダは、希望のフレームを表示するのに更に4個のPフレームをデコードする必要がある。先行するIフレームが使用される場合には、デコーダは、希望のフレームを表示するのに6個のフレームIフレーム及びその後の5個のPフレームをデコードする必要がある。明らかに、この場合には、デコードすべき付加的なフレームを最小にするために、現在表示されているフレームを使用するのが効果的である。次いで、4フレーム先にある次にデコードされるべきフレームは、Iフレームに続く1番目のPフレームである。このケースでは、現在デコードされたフレームがスタートポイントとして使用される場合に、デコーダは、更に4個のフレーム2個のPフレーム、Iフレーム及びPフレームをデコードする必要がある。しかし、それに代わって、次のIフレームが使用される場合には、デコーダは、Iフレーム及びそれに続くPフレームをデコードするだけでよい。明らかに、この場合には、デコードすべき付加的なフレームを最小にするために、次のIフレームをスタートポイントとして使用するのが効果的である。従って、この例では、デコーダは、現在デコードされたフレームをスタートポイントとして使用することと、その後のIフレームをスタートポイントとして使用することを交互に行う。一般に重要なこととして、HQビデオストリームの再生モード高速送り、巻き戻し又は停止及び速度に関わらず、デコーダは、Iフレームであるか又は以前にデコードされたフレームであるかのどちらかのフレームでスタートし、その再生モード及び速度に対して表示される各次々のフレームについて希望のフレームを表示するのに、新たにデコードされるフレームを最小数しか必要としない。図31bに示すように、ホスティングサービス210の1つの実施形態は、HQストリーム3110をリプレイするユーザ要求を管理するためのストリームリプレイロジック3112を含む。このストリームリプレイロジック3112は、ビデオ再生コマンド例えば、休止、巻き戻し、特定のポイントからの再生、等を含むクライアント要求を受け取り、それらコマンドを解釈し、そして特定のポイントからのHQストリーム3110をデコードする適宜、Iフレーム又は以前にデコードされたフレームのいずれかでスタートし、次いで、前方又は後方に特定の位置まで進む。1つの実施形態では、デコードされたHQストリームは、エンコーダ3100一度に2つ以上のストリームをエンコードできる場合は潜在的に同じエンコーダ3100、又は個別のエンコーダ3100へ送られて、再圧縮されここに述べる技術を使用して、そしてクライアント装置205へ送信される。クライアント装置のデコーダ3102は、次いで、上述したように、ストリームをデコードし、レンダリングする。1つの実施形態において、ストリームリプレイロジック3112は、HQストリームをデコードせず、エンコーダ3100がストリームを再エンコードするようにさせる。むしろ、HQストリーム3110を特定のポイントからクライアント装置205へ単に直接的にストリーミングさせる。次いで、クライアント装置205のデコーダ3102がHQストリームをデコードする。ここに述べる再生機能は、典型的に、リアルタイムビデオゲームをプレイするのと同じ短待ち時間要求を有するものではないので例えば、プレーヤが能動的にプレイせずに、ゲームプレイの前に単にレビューするだけである場合に、通常の高品質HQストリームに典型的に本来ある追加の待ち時間は、受け容れられるエンドユーザ経験例えば、待ち時間は長いが、高品質ビデオであるを生じさせる。例えば、これに限定されないが、ユーザがビデオゲームをプレイする場合に、エンコーダ3100は、ユーザの接続及びローカルクライアントに対して最適化された本質的に全てのPフレームの生のストリームを与える例えば、640x360解像度においてほぼ1.4Mbps。又、同時に、エンコーダ3100は、ビデオストリームをホスティングサービス310内でHQストリーム3110として圧縮し、そしてそのHQストリームを、例えば、12フレームごとにIフレームを伴い10Mbpsにおいて1280x720でローカルデジタルビデオデコーダRAIDアレイに記憶する。ユーザが休止ボタンに触ると、クライアントの最後にデコードされたフレームでゲームが休止され、スクリーンがフリーズする。次いで、ユーザが巻き戻しボタンに触れると、ストリームリプレイロジック3112は、上述したように、最も近いIフレーム又は既にデコードされた使用可能なフレームから始めて、DVRRAIDからHQストリーム3110を読み取る。ストリームリプレイロジック3112は、介在するP又はBフレームを必要に応じて解凍し、それらフレームを必要に応じて再シーケンシングして、再生シーケンスが希望の巻き戻し速度で後方に進むようにし、次いで、表示されることが意図された希望のデコードされたものを良く知られた従来の映像スケーリング技術を使用して1280x720から640x360へサイズ変更し、そして生のストリームエンコーダ3100は、640x360解像度の再シーケンシングされたストリームを再圧縮してユーザへ送信する。ユーザが再び休止し、次いで、ビデオを通して単一ステップして、シーケンスを厳密に見る場合には、DVRRAIDのHQストリーム3110は、単一ステップに各フレームを使用できるようにする元の生のストリームが、ここに述べる多数の理由のいずれかで、フレームをドロップしても。更に、ビデオ再生の画質は、HQストリームの各ポイントにおいてかなり高いが、生のストリームには、例えば、帯域巾が損なわれて、圧縮映像の画質に一時的な低下を招くポイントが生じ得る。短期間中の、又は動画における損なわれた画質は、ユーザにとっては受け入れられるが、ユーザが特定のフレームで停止し又はゆっくり単一ステップし、フレームを厳密に調査する場合には、損なわれた画質を受け容れることができない。又、ユーザには、HQストリーム内のポイント例えば、2分前を指定することにより、高速送り又は特定スポットへジャンプする能力も与えられる。これら全ての動作は、Pフレームのみであるか、又はIフレームを稀に又は予期せず有する生のビデオストリームでは、完全な普遍性及び高い画質において不可能である。一実施形態では、HQストリームがビデオを記憶する限り、ユーザがビデオストリームを通して前後にスイープできるようにするスクラバー即ち左右のスライダーコントロールを伴うアップルクイックタイム又はアドベフラッシュビデオウインドウのようなビデオウインドウ図示せずがユーザに与えられる。ユーザには、生のストリームを通してスクラビングしているように見えるが、実際には、ユーザは、記憶されたHQストリーム3110を通してスクラビングし、これは、次いで、生のストリームとしてサイズ変更され再圧縮される。更に、上述したように、誰か他の者がHQストリームを同時に見るか、又はユーザが別の時間に見る場合には、生のストリームの解像度より高い又は低い解像度で見ることはできが、HQストリームは、同時にエンコードされ、そしてその画像は、潜在的にHQストリームの画像までは、見る者の生のストリームの画質と同程度となる。従って、生のストリームここに述べるように、短い待ち時間、帯域巾及びパケットエラー許容要求に適するように、及び高画質ストリーム再生アクション要求を伴うHQストリームの両方を同時にエンコードすることにより、ユーザには、両シナリオの望ましい構成が与えられる。そして、実際に、ユーザにとって、2つの異なるストリームが異なる仕方でエンコードされることが効果的に良く分かる。ユーザの観点から、非常に変化し易く且つ比較的低い帯域巾のインターネット接続で実行されるにも関わらず、その経験は、短い待ち時間で非常に敏感であり、しかも、デジタルビデオレコーディングDVRの機能は、非常に高画質で、柔軟なアクション及び柔軟な速度を伴う。上述した技術の結果として、ユーザは、オンラインゲームプレイ又は他のオンライン相互作用の間に、生のストリーム又はHQストリームのいずれの制限の影響もなく、生のストリーム及びHQビデオストリームの両方の利益を受ける。図31cは、前記動作を遂行するためのシステムアーキテクチャーの一実施形態を示す。図示されたように、この実施形態では、エンコーダ3100は、一連の生のストリーム3121L、3122L及び3125Lと、それに対応する一連のHQストリーム3121H1-H3、3122H1-H3及び3125H1-H3とを各々エンコードする。各HQストリームH1は、全解像度でエンコードされ、一方、各エンコーダH2及びH3は、ビデオストリームをエンコーディング前の小さなサイズにスケーリングする。例えば、ビデオストリームが1280x720の解像度である場合には、H1は、1280x720の解像度でエンコードし、一方、H2は、640x360へスケーリングしてその解像度でエンコードし、そしてH3は、320x180へスケーリングしてその解像度でエンコードする。nを1より大きな整数とすれば、多数の同時Hnスケーラー/エンコーダを使用して、多数の同時HQエンコーディングを種々の解像度で与えることができる。生のストリームの各々は、上述したように、インバウンドインターネット接続3101を経て受け取ったチャンネルフィードバック信号3161、3162及び3165に応答して動作する例えば、図25-26のフィードバック信号2501及び2601の説明を参照されたい。生のストリームは、インターネット又は他のネットワークを通りアウトバウンドルーティングロジック3140を経て送信される。生のコンプレッサ3121L-3125Lは、チャンネルフィードバックに基づいて、圧縮されたビデオストリームを適応させるロジックフレームをスケーリングし、ドロップさせ、等を含むを含む。HQストリームは、インバウンドルーティングロジック3141及び1502により、信号経路3151を経て内部遅延バッファ例えば、RAIDアレイ3115又は他のデータ記憶装置へルーティングされ、及び/又は信号経路3152を経てapp/gameサーバー及びエンコーダ3100へ更なる処理のためにフィードバックされる。上述したように、HQストリーム3121Hn-3125Hnは、その後、要求があった際にエンドユーザへストリーミングされる例えば、図31b及びそれに関連した説明を参照されたい。1つの実施形態において、エンコーダ3100は、図15に示す共有ハードウェア圧縮ロジック1530で具現化される。別の実施形態では、エンコーダ及びスケーラーの幾つか又は全部が個々のサブシステムである。本発明の基礎的な原理は、スケーリング又は圧縮リソース或いはハードウェア/ソフトウェア構成の特定の共有に限定されない。図31cの構成の効果は、フルサイズより小さいビデオウインドウを要求するApp/Gameサーバー3121-3125は、フルサイズウインドウを処理し解凍する必要がないことである。又、中間のウインドウサイズを要求するApp/Gameサーバー3121-3125は、希望のウインドウサイズ付近の圧縮されたストリームを受け取り、次いで、希望のウインドウサイズへスケールアップ又はダウンすることができる。又、App/Gameサーバー3121-3125が、別のApp/Gameサーバー3121-3125から同じサイズのビデオストリームを要求する場合には、インバウンドルーティング3141は、この技術で良く知られたもののようなIPマルチキャスト技術を具現化し、そして要求を行う各App/Gameサーバーへの独立したストリームを必要とせずに、要求されたストリームを複数のApp/Gameサーバー3121-3125へ一度に放送することができる。放送を受信するApp/Gameサーバーがビデオウインドウのサイズを変更する場合には、異なるビデオサイズの放送へ切り換えることができる。従って、任意の大勢のユーザは、各々、それらのビデオウインドウをスケーリングしそして希望のウインドウサイズに厳密にスケーリングされたビデオストリームの利益を常に得るという柔軟性で、App/Gameサーバービデオストリームを同時に見ることができる。図31cに示す解決策に伴う1つの欠点は、ホスティングサービス210の多数の実際的な具現化において、全ての圧縮されたHQストリームの全てのサイズをそのままにしておいて、全ての圧縮されたHQストリームが一度に見られるときがないことである。エンコーダ3100が共有リソースとして具現化されるときには例えば、ソフトウェア又はハードウェアのいずれかで具現化されるスケーラー/コンプレッサ、この不経済さが軽減される。しかし、多数の未圧縮のストリームを共通の共有リソースに接続する際には、当該帯域巾のために、実際上の問題が生じる。例えば、各1080p60ストリームは、ほぼ3Gbpsであり、ギガビットイーサネットを遥かに上回る。以下に述べる別の実施形態は、この問題に向けられる。図31dは、各App/Gameサーバー3121-3125に次の2つのコンプレッサが割り当てられたホスティングサービス210の別の実施形態を示す。1チャンネルフィードバック3161-3165に基づいて圧縮されたビデオストリームを適応させる生のストリームのコンプレッサ3121-3125L、及び2上述したように全解像度のHQストリームを出力するHQストリームコンプレッサ。注意すべきことに、生のコンプレッサは、動的で且つ適応性があり、クライアント205との両方向通信を使用するが、HQストリームは、非適応性で、一方向である。ストリーム間の他の相違は、生のストリームの画質がチャンネル条件及びビデオ資料の性質に基づいて劇的に変化することである。あるフレームは、画質が悪く、ドロップしたフレームが生じ得る。又、生のフレームは、ほぼ完全にPフレーム又はPタイルであり、Iフレーム又はIタイルは稀に表れるだけである。HQストリームは、典型的に、データレートが生のストリームより相当に高く、いずれのフレームもドロップせずに、一貫した高画質を与える。HQストリームは、全てIフレームでもよいし、又は頻繁で及び/又は規則的なIフレーム又はIタイルを有してもよい。又、HQストリームは、Bフレーム又はBタイルを含んでもよい。1つの実施形態において、共有ビデオスケーリング及び再圧縮3142以下で詳細に述べるは、上述したルーティングのためにインバウンドルーティング3141へ送信される前に、1つ以上の異なる解像度でスケーリング及び再圧縮されるべきあるHQビデオストリーム3121H1-3125H1のみを選択する。他のHQビデオストリームは、上述したルーティングのためにフルサイズでインバウンドルーティング3141へ通されるか、或いは全く通されない。1つの実施形態では、どのHQストリームがスケーリング及び再圧縮され及び/又はどのHQストリームが全体に通されるかの判断は、その特定のHQストリームを特定の解像度或いはスケーリングされた解像度又は全解像度に近い解像度で要求しているApp/Gameサーバー3121-3125があるかどうかに基づいて決定される。この手段により、スケーリング及び再圧縮される又は潜在的に全体に通されるHQストリームのみが、実際に必要とされるHQストリームである。ホスティングサービス210の多数のアプリケーションでは、これは、スケーリング及び圧縮リソースの劇的な減少を生じさせる。又、各HQストリームが、少なくとも、コンプレッサ3121H1-3125H1によりその全解像度で圧縮されるとすると、共有ビデオスケーリング及び再圧縮3142内へルーティングされる必要のある帯域巾は、未圧縮のビデオが受け容れられる場合より劇的に減少される。例えば、3GBpsの未圧縮の1080p60ストリームは、10Mbpsへ圧縮されても、依然、非常に高い画質を保持することができる。従って、ギガビットイーサネット接続では、1つの未圧縮の3Gbpsビデオストリームすら搬送できないのではなく、画質の明らかな低下がほとんどない状態で、多数の10Mbpsのビデオストリームを搬送することができる。図31fは、共有ビデオスケーリング及び再圧縮3142の細部を、多数のHQビデオコンプレッサHQ3121H1-3131H1と共に示している。内部ルーティング3192は、App/Gameサーバー3121-3125からの特定のサイズにスケーリングされた特定のビデオストリームの要求ごとに、典型的に、HQビデオコンプレッサHQ3121H1-3131H1からの圧縮されたHQストリームのサブセットを選択する。この選択されたストリームサブセット内のストリームは、要求されたストリームがスケーリングされるべき場合には、デコンプレッサ3161-3164を通してルーティングされるか、又は要求されたストリームが全解像度である場合には、非スケーリングビデオ経路3196を経てルーティングされる。スケーリングされるべきストリームは、デコンプレッサ3161-3164により未圧縮ビデオへと解凍され、次いで、その各々がスケーラー3171-3174によって要求されたサイズへとスケーリングされ、次いで、その各々がコンプレッサ3181-3184により圧縮される。特定のHQストリームが2つ以上の解像度で要求される場合には、内部ルーティング3192は、そのストリームを当業者に良く知られたIPマルチキャスト技術を使用して1つ以上のデコンプレッサ3161-3164へ及び1つが要求されたサイズで、全解像度である場合にはアウトバウンドルーティング3193へマルチキャストすることに注意されたい。要求された全てのストリームは、コンプレッサ3181-3184からスケーリングされるか内部ルーティング3192からされないかに関わらず、アウトバウンドルーティング3193へ送られる。ルーティング3193は、次いで、各々の要求されたストリームを、それを要求したApp/Gameサーバー3121-3125へ送る。1つの実施形態において、2つ以上のApp/Gameサーバーが同じ解像度の同じストリームを要求する場合には、アウトバウンドルーティング3193が、要求をなす全てのApp/Gameサーバー3121-3125へストリームをマルチキャストする。共有ビデオスケーリング及び再圧縮3142の現在好ましい実施形態では、ルーティングがギガビットイーサネットスイッチを使用して具現化され、そして解凍、スケーリング及び圧縮は、各機能を具現化する個別の特殊な半導体装置により具現化される。同じ機能を、ハードウェアにおける高い一体化レベルで、又は非常に高速なプロセッサで具現化することができる。図31eは、上述した遅延バッファ3115の機能が、共有ビデオ遅延バッファ、スケーリング及び解凍サブシステム3143において具現化されるホスティングサービス210の別の実施形態を示す。このサブシステム3143の細部が図31gに示されている。サブシステム3143の動作は、図31fに示すサブシステム3142と同様であるが、3191は、App/Gameサーバー3121-3125からの要求ごとに、どのHQビデオストリームをルーティングすべきか最初に選択し、次いで、遅延されるべく要求されたHQストリームは、ここに示す好ましい実施形態においてRAIDアレイとして具現化されたしかし、充分な帯域巾及び容量の記憶媒体で具現化することもできる遅延バッファ3194を通してルーティングされ、そして遅延されるべく要求されなかったストリームは、非遅延ビデオ経路3195を通してルーティングされる。遅延バッファ3194及び非遅延ビデオ3195の両出力は、要求されたストリームをスケーリングすべきか否かに基づいて内部ルーティング3192によりルーティングされる。スケーリングされたストリームは、デコンプレッサ3161-3164、スケーラー3171-3174、及びコンプレッサ3181-3184を通してアウトバウンドルーティング3193へルーティングされ、非スケーリングビデオ3196もアウトバウンドルーティング3193へ送られ、次いで、アウトバウンドルーティング3193は、ユニキャスト又はマルチキャストモードのビデオを、図31fのサブシステム3142について上述したのと同様にApp/Gameサーバーへ送信する。ビデオ遅延バッファ、スケーリング及び解凍サブシステム3143の別の実施形態が図31hに示されている。この実施形態では、HQストリームごとに個々の遅延バッファHQ3121D-HQ3131Dが設けられる。個々の圧縮されたビデオストリームを遅延するのに使用できるRAM及びフラッシュROMのコストが急速に低下しているとすれば、共有遅延バッファ3194を有する場合より費用が安く及び/又は柔軟性が高いことになる。或いは、更に別の実施形態では、単一の遅延バッファ3197点線で示すが、高性能の集合リソース例えば、非常に高速なRAM、フラッシュ又はディスクにおいて全てのHQストリームに対して個々に遅延を与えることができる。いずれのシナリオにおいても、各遅延バッファHQ3121D-HQ3131Dは、HQビデオソースからのストリームに可変の遅延を与えることができ、又は遅延なしにストリームを通すことができる。別の実施形態では、各遅延バッファは、複数のストリームに異なる遅延量を与えることができる。App/Gameサーバー3121-3125によって全ての遅延又は非遅延が要求される。これらの全てのケースにおいて、遅延及び非遅延ビデオストリーム3198が内部ルーティング3192へ送られ、そして図31gについて上述したように、サブシステム3143の残り部分を通して進む。種々の図31nに対する前記実施形態では、生のストリームは、両方向接続を使用し、そして特定のユーザに対して最小の待ち時間で仕立てられることに注意されたい。HQストリームは、一方向接続を使用し、ユニキャスト及びマルチキャストの両方である。マルチキャスト機能は、これらの図では、大規模なシステムにおけるギガビットイーサネットスイッチで具現化できるような単一ユニットとして示されているが、マルチキャスト機能は、おそらく、複数のスイッチのツリーを通して具現化される。実際に、トップランクのビデオゲームプレーヤからのビデオストリームの場合に、プレーヤのHQストリームは、数百万のユーザから同時に見られることになる。このようなケースでは、おそらく、マルチキャストHQストリームを放送する次々の段に多数の個々のスイッチが存在する。診断の目的、及びユーザに彼のゲームプレイの成績がどれほど評判の良いものであるか知らせるためにユーザにフィードバックを与えるため、の両方について、1つの実施形態では、ホスティングサービス210は、App/Gameサーバー3121-3125の各ビデオストリームの同時視聴者がどれほどいるか追跡する。これは、特定のビデオストリームに対しApp/Gameサーバーにより能動的な要求の数のランニングカウントを保持することにより達成できる。従って、100000人の同時視聴者がいるゲームプレーヤは、彼のゲームプレイが非常に評判の良いものであることを知り、そしてゲームプレーヤが良い成績を出して視聴者を引き付けるための刺激を生み出す。例えば、ビデオゲーム選手権大会のビデオストリームが非常に大規模で非常に視聴者数が多いときには、ビデオゲームの試合中に解説者が話をして、そのマルチキャストを見ている何人かの又は全てのユーザがそのコメントを聞くことができるようにするのが望ましい。App/Gameサーバーで実行されるアプリケーション及びゲームには、特定の特性例えば、解像度及び遅延量をもつ特定のビデオストリームに対する要求をアプリケーション及び/又はゲームが提示できるようにするアプリケーションインターフェイスAPIが設けられる。又、App/Gameサーバーで実行されるオペレーティング環境、又は図4aのホスティングサービスコントロールシステム401へ提示されるこれらのAPIは、種々の理由で、このような要求を拒絶してもよい。例えば、要求されるビデオストリームは、幾つかのライセンス交付権制約を有し例えば、1人の視聴者しか見ることができず、他の者へは放送されないように、契約上の制約があり例えば、視聴者は、ストリームを見る権利に対して支払しなければならない、年齢制約があり例えば、視聴者は、ストリームを見るには18歳でなければならず、プライバシーの制約があり例えば、アプリケーションを使用するか又はゲームをプレイする個人は、選択された数又はクラスの視聴者例えば、彼又は彼女の友人のみに視聴を制限するか、或いは全く視聴を許さない、そして資料の要求が遅延されるという制約がある例えば、ユーザの位置が暴露されるステルスゲームをユーザがプレイする場合。ストリームの視聴を制限する多数の他の制約がある。これらケースのいずれかにおいて、App/Gameサーバーによる要求は、拒絶の理由のために拒絶され、そして一実施形態では、契約に対してどんな料金を支払わねばならないか示す要求を受け容れるところの代替物で拒絶される。いずれかの前記実施形態において遅延バッファに記憶されたHQビデオストリームは、ホスティングサービス210以外の他の行先へエクスポートされる。例えば、特に関心のあるビデオストリームは、YouTubeへエクスポートされるべく、App/Gameサーバーにより典型的に、ユーザの要求により要求することができる。このようなケースでは、ビデオストリームは、YouTubeと合意されたフォーマットでインターネットを通して、適当な記述情報例えば、プレイするユーザの名前、ゲーム、時間、スコア、等と一緒に送信される。これは、コメントを要求する全てのApp/Gameサーバー3121-3125へ個別のストリームにおいてコメント音声をマルチキャストすることにより具現化できる。App/Gameサーバーは、そのコメントの音声を、当業者に良く知られた音声混合技術を使用して、ユーザの家屋211へ送られる音声ストリームへ合流させる。複数の解説者例えば、異なる視点又は異なる言語のがいてもよく、又、それらの中からユーザが選択することができる。同様に、個別の音声ストリームを、ホスティングサービス210において、リアルタイムのビデオストリームから又は遅延バッファからの音声と混合し又は置き換えることで、混合することもできるし、又は特定のビデオストリーム又は個々のストリームの音声トラックに代わるものとして働くこともできる。このような音声は、コメント又はナレーションであるか、或いはビデオストリームにおけるキャラクタの音声を与えることもできる。これは、ユーザによってマシニマビデオゲームビデオストリームからのユーザ発生アニメーションを容易に制作できるようにする。本書の全体にわたって述べたビデオストリームは、App/Gameサーバーのビデオ出力から捕獲され、次いで、ストリーミング及び/又は遅延され、そして種々の仕方で再使用又は配布されるものとして示された。同じ遅延バッファを使用して、非App/Gameサーバーソースから到来するビデオ資料を保持し、そして再生及び配布に対する同程度の柔軟性を、適当な制約と共に与えることができる。このようなソースは、テレビ局からの生のフィードを含むオーバージエア、又はCNNのような非オーバージエア、及びHBOのような有料、又は無料のいずれか。又、このようなソースは、事前に記録された映画又はテレビショー、ホームムービー、広告、及び生のビデオ遠隔会議フィードも含む。生のフィードは、App/Gameサーバーの生の出力のように取り扱われる。事前に記録された資料は、遅延バッファの出力のように取り扱われる。ビデオウインドウのズーミング及び並進移動図16、17及び18は、サムネールビデオウインドウ1600を中間サイズ1700へそして最終的にはフルサイズのビデオウインドウ1800へズーミングする段階を通してユーザインターフェイスを示している。ズーミングされたビデオウインドウ1600、1700及び1800は、上述したように、図15のApp/Gameサーバー1521-1525により発生される。ユーザが典型的なデスクトップモニタ又はTVスクリーンにおいてビデオウインドウ1600、1700及び1800を見ている場合に、ウインドウがフルサイズへズームされると、その画像は、多くの場合、ユーザがユーザのアプリケーションに対してウインドウのコンテンツを充分詳細に見るに足る大きさとなる。例えば、ビデオウインドウ1800に示されるコンテンツは、ビデオゲームであり、そしてディスプレイ装置が32TVセット又は23コンピュータモニタであって、ユーザがディスプレイ装置のための典型的な視聴距離内にいる場合には、ユーザは、ゲームをプレイできるに充分なビデオの細部を見分けることができる。例えば、ユーザは、車1802が前方にあるそしておそらくゲームに基づいて、それを回避し、それに追突し、それに追従し、等のを見ることができ、そしてユーザは、ゲームをプレイできるに充分な明瞭さで地図1803及びスピードメータ1804の細部を認識することができる。しかしながら、ユーザのディスプレイ装置が非常に小型である場合には、ビデオウインドウ1800も小型であって、ユーザは、ユーザのアプリケーションに対してコンテンツの充分な細部を認識することができない又は視野の限界があるために。例えば、ディスプレイ装置が、AppleiPhone登録商標のような小型のセルラーホンであるか、又はAppleiPodTouchのような小型のメディアプレーヤである場合には、非常に小さなスクリーンサイズ及び/又は低いスクリーン解像度のために、車1802を見分け或いは地図1803又はスピードメータ1804の細部を読み取ることが困難又は不可能となる。そのような場合には、ゲームをプレイすることも困難又は不可能である。1つの実施形態において、サーバー1521-1525は、ユーザ入力に応答して、ビデオウインドウ1800をスクリーンのフルサイズより大きくズームし、及び/又はサーバー1521-1525は、ユーザ入力に応答して、ズームアップスクリーンを水平方向及び/又は垂直方向及び/又は対角方向に並進移動する。これは、ユーザがスクリーンの特定エリアにズームインしてそれをより詳細に見ることができるようにする。例えば、ユーザがスクリーンの中央にズームインすると、車1802は、認識できるに充分な大きさになる。ユーザがスクリーンにズームインし、そして画像を並進移動して左下が見えるようにすると、地図1803が認識可能になる。ユーザがスクリーンの右下にズームインすると、スピードメータ1804が認識可能になる。ゲーム又はアプリケーションの性質に基づき、ユーザは、ユーザが休止を希望することをサーバー1521-1525に指示するユーザインターフェイスアクションを遂行することで、ズーム/並進移動の前、その間又はその後にビデオの休止を希望してもよい。例えば、ドライブゲームにおいて、ユーザは、スクリーンの中心へズームインして道路に焦点を合わせる間は休止しないが、地図1803又はスピードメータ1804を見る前に休止して、前方の道路がスクリーン上にもはや見えなくなる間に車に衝突しないようにすることができる。生産アプリケーション又はウェブブラウザアプリケーションの場合には、ズーミング又は並進移動のためにビデオを休止する必要はない。例えば、AppleiPhone、iPodTouch又はMacintoshにおいてタッチスクリーン又はトラックパッドを指でピンチ、スプレッド及び/又はスワイプする等の、従来のウインドウをスケーリング及び/又は並進移動するのに使用される種々の従来ユーザインターフェイス技術がある。別の例として、マウスのスクロールホイールを使用して、どれほどズームするか指定できる一方、マウスをクリックして移動することを使用して、並進移動を指定することができる。これら及び他の技術を本発明のビデオウインドウ1800の実施形態に適用して、ユーザがズーム及び/又は並進移動を指定できるようにする。指定されたスケーリング及び/又は並進移動ユーザ入力は、図4aのコントロール信号406としてサーバー1521-1525へ送信され、そして要求されたスケーリング及び/又は並進移動アクションが遂行される。1つの実施形態において、スケーリングされ及び/又は並進移動されたビデオウインドウがディスプレイ装置の縁を越えて延びる程度に対し、サーバー1521-1525により、ディスプレイ装置の縁又は画像のズームされた部分を含むウインドウの縁まで切り落とされ、共有ハードウェア圧縮1530によって圧縮された可視ピクセルのみが、図4aにおけるホーム又はオフィスクライアント装置415へ送出され、送信帯域巾を減少させる。別の実施形態では、ディスプレイ装置の縁又は画像のズームされた部分を含むウインドウの縁を越えて延びるズームされ及び/又は並進移動されたビデオウインドウの若干又は全部がサーバー1521-1525により発生され、そして共有ハードウェア圧縮1530により圧縮されて、ホーム又はオフィスクライアント装置415へ送出され、次いで、ディスプレイ装置の縁又は画像のズームされた部分を含むウインドウの縁まで切り落とされる。前記実施形態は、必要最小限よりも高い送信帯域巾を生じるが、スケーリング及び/又は並進移動動作は、ホーム又はオフィスクライアント装置415によってローカルで実行され、これは、特に、ホーム又はオフィスクライアント装置415とホストサービス210との間の接続が著しい待ち時間を被る場合に、ズーミング及び/又は並進移動動作の応答時間の待ち時間を減少することができる。1つの実施形態において、スケーリングされ及び/又は並進移動されるビデオウインドウは、ウェブブラウザウインドウである。小さなスクリーンを伴う従来の装置、例えば、AppleiPhone又はiPodTouchのようなセルラーホン又はメディアプレーヤは、例えば、ピンチ、スプレッド及び/又はスワイプにより表示されたウェブサイトのウインドウをズーム及び/又は並進移動して、コンテンツをより厳密に見て、より詳細に認識するか、又は低い詳細度で全体を見るためのファシリティを有するウェブブラウザを備えている。実際の環境において、このような従来のウェブブラウザを使用すると、著しい欠点が生じ、多くの場合、ウェブページのローディングが低速になるか又はネットワークリソースの利用効率が悪くなる。ユーザがウェブページにズームインする場合に、典型的に、ブラウザは、ウェブページコンテンツの全部ではないまでもそのほとんどをダウンロードする必要が依然ある。というのは、ウェブブラウザは、ウェブページのズームイン部分にどんな画像が得られるか決定できる前にウェブページのエレメントの全部又はほとんどを処理して表示することが典型的に必要になるからである。1つの単純な例として、ウェブブラウザが大きなjpeg画像の一部分にズームインされる場合には、jpeg圧縮アルゴリズムは、典型的に、画像の一部分を表示できるまでに画像全体を解凍する必要がある。別の例として、HTMLページは、ウェブページのあるエレメントを他のエレメントの位置に対してしばしば暗示的に又は明確に配置させ、ズームイン部分のエレメントの位置が分かる前にダウンロード及びパースされるべきズームインページの縁から外れるエレメントを必要とする。更に、図24に示して上述したように、ウェブサイトのロード時間は、ファイルのローディングを重畳できない程度まで、ウェブサイトを作り上げる各ファイルをロードする際に被るロード時間の和に漸近線的に近付く。又、ロールオーバーのためのjpeg画像のような多くのエレメントは、ロードされねばならないが、表示されることはない。図24は、54ファイルウェブサイトの種々の接続速度におけるロード時間を示し、各ファイルは、ワイヤラインインターネット接続を使用するHTTPファイルの共通の待ち時間である100msの待ち時間オーバーヘッドを有する。セルラーネットワーク、例えば、ATT3Gセルラーネットワークが使用される場合には、HTTPファイル待ち時間オーバーヘッドは、典型的に非常に高く、おそらく、400ms以上の高さである。従って、図24の規範的ウェブサイトは、5.4秒のロード時間に漸近線的に近付くが、400msのHTTPファイル待ち時間では、同じウェブサイトが21.6秒のロード時間に漸近線的に近付き、そして3Gセルラーネットワークがワイヤライン接続より低い接続速度で良く動作するとすれば、合計ロード時間は、30秒以上となる。従って、ズームイン部分しか見えなくても、ウェブブラウザは、ウェブページを表示することができる。これは、ユーザにとって不便なだけではなく、ワイヤレスデータスループットの非常に非効率的な使用でもあり、これは、しばしば多数のユーザ間で分担され、そして要求よりしばしば低いたびたび遥かに低いワイヤレスデータスループットが得られる。上述したように、1つの実施形態では、ウェブブラウザは、サーバー1521-1525にホストされるか、ホスティングサービス210にローカル記憶されたソースウェブページファイルにホストされるか、或いはホスティングサービス210に利用できるインターネットへの接続を使用することによりソースファイルにホストされる。次いで、ウェブブラウザウインドウが表示のためにホーム又はオフィスクライアント装置415へ送信される。ウェブブラウザは、コントロール信号406を経てユーザのアクションにより制御される。ホーム又はオフィスクライアント装置415が、セルラーネットワークを通して動作するセルラーホンである場合には、待ち時間は、典型的に、ホスティングサービス210とインターネットとの間よりも、セルラーホンとインターネットとの間の方が相当に長くなる。従って、ウェブページファイルがホスティングサービス210にローカル記憶されるか又はリモートウェブサーバーに位置されるかに関わらず、おそらく、ユーザは、サーバー1521-1525にホストされたウェブブラウザによって発生されてセルラーホンへビデオとして送信されるウェブページを見るときには、セルラーネットワークを通してウェブページファイルが慣習的に送信されるようにして、セルラーホンでローカルに実行されるウェブブラウザにより同じウェブページが発生された場合にユーザが経験する遅延より、相当に短い遅延を経験する。更に、上述したように、ウェブブラウザをサーバー1521-1525にホストすることで、おそらく、所与のウェブページに対してホーム又はオフィスクライアント装置415へ送信されるデータが著しく少なくなる。又、セルラーネットワークの接続速度が低下する場合には、上述した種々の技術を使用して、送信データスループットを動的に減少させ、セルラーチャンネルの容量を越えないようにすることができる。更に、この解決策は、例えば、AdobeFlashの最新バージョンでローカルウェブブラウザを最新の状態に保つ必要性を排除する。というのは、サーバー1521-1525で実行されるウェブブラウザが最新の状態を保持できるからである。実際に、サーバー1521-1525で実行されるウェブブラウザは、ホーム又はオフィスクライアント装置415の計算能力を越えるオペレーションを遂行することができる。一実施形態において、ホーム又はオフィスクライアント装置415で発生されたビデオウインドウは、上述したようにズームされ及び/又は並進移動される。このように、ユーザは、ウェブページの細部を見るためにズーム及び/又は並進移動することができ、或いはズームアウトした場合には、ウェブページの全体図を得ることができる。実際に、ウインドウ1600及び1700のようなスクリーンの一部分だけを取り上げるためにウェブページ画像をズームダウンすることや、又、実際に、他のウインドウが他のウェブページであるかどうか、又はビデオゲーム、ビデオ、アプリケーション、等のビデオウインドウであるかどうかに関わらず、ウェブページ画像をそれら他のウインドウと同時に見ることは、良くあることである。AppleSafariのような従来のウェブブラウザは、例えば、ユーザが最も頻繁に訪問するのはどのウェブサイトであるか示すために、一度に複数の縮小サイズウェブサイトのウインドウを表示することができる。複数のウェブサイトが同時に表示されるので、それら全部を動的に表示する例えば、現在ウェブサイトに生で表示されているものを示すことは、典型的に不可能である。というのは、他の問題の中でも、全てのウェブサイトからの帯域巾需要の和が過剰なものになるからである。例えば、8個のウェブサイトがビデオを示す場合には、全てのウェブサイトからの全ビデオ帯域巾を受信し、解凍しそして縮小サイズウェブサイトのサイズへスケールダウンしなければならない。これは、ユーザにとって非リアルタイムの経験を生じさせるだけでなく、帯域巾の浪費にもなる。というのは、全ウェブサイトをダウンロードする必要があり、それらがスケールダウンされ、細部が相当失われるからである。1つの実施形態においては、1つ以上のウェブブラウザがサーバー1521-1525にホストされ、そしてビデオは、オフィス又はクライアント装置415へ送出される前にスケーリングされ、図16に示すように、複数のスケールダウンしたビデオウインドウとして見えるようにする。一度に複数のウェブサイトを縮小サイズウインドウとして表示できる従来のウェブブラウザとは対照的に、この実施形態では、ウェブサイトは、それらの幾つか又は全部がビデオのような広帯域巾エレメントを組み込んでいても、一度に全部を生で表示することができる。そして、これら複数の生のウェブサイトウインドウは、ビデオゲーム、ビデオ、アプリケーション、等の他の生のビデオウインドウと同時に表示することができる。1つの実施形態において、ユーザにより見るのに利用できるウインドウの数は、ディスプレイ装置の境界内に表示されるビデオウインドウの数より多い。例えば、図16では、18個のビデオウインドウの6x3アレイが見えるが、ユーザにより見るのに利用できる遥かに多くのビデオウインドウがあってもよく例えば、20x20アレイ、所与の時間にディスプレイ装置の境界内に見えるのは6x3サブセットに過ぎない。1つの実施形態において、ユーザは、タッチスクリーン又はトラクパッドを横切って指をスワイプさせることでビデオウインドウのアレイの並進移動例えば、水平方向、垂直方向及び/又は対角方向を行い、これにより、指タッチでビデオウインドウのアレイがその位置を並進移動させて他のビデオウインドウを露呈させるという幻想を生み出すことができる。これは、指スワイプコントロール情報例えば、スワイプの位置、スワイプの速度、等をコントロール信号406として送信し、そしてapp/gameサーバー1521-1525がビデオウインドウのアレイの動きを示すアニメーション効果を具現化することにより、達成することができる。1つの実施形態において、アニメーション効果は、指スワイプ又は他のユーザ入力、例えば、コントローラアクション又はキーボード/マウスの押圧、身体運動、等に応答してビデオウオールが水平方向、垂直方向又はある角度で動くことを示す並進移動であるが、ビデオウインドウは、それらが移動するとき全てが同じサイズのままとされる。別の実施形態において、アニメーション効果は、非直線運動であり、ここで、ビデオウオールは、指スワイプ又は他のユーザ入力アクションに応答して複雑な動きで移動し、そしてビデオウインドウの幾つか又は全部がアニメーション効果中にサイズを変化させる。1つのこのような複雑な動きは、ビデオウオールが3D空間に置かれているという幻想を生み出す遠近感3D運動である。図32a、32b、32c及び32dに示す1つの実施形態において、app/gameサーバー1521-1525により発生されるビデオウオールが3D空間へ投影されて示される程度は、ユーザがビデオウオールを移動させる速度に関連している。ユーザは、キーボード、マウス、トラックパッド、ゲームコントローラ、タッチスクリーン、或いは身体ジェスチャを捕獲する装置、例えば、行動動き捕獲システム、を含む種々の入力装置を使用して、ビデオウオールを移動させることができる。例えば、ディスプレイ装置の縁を越えたところにある付加的なビデオウインドウを見るために、ユーザがそのような各々の装置を使用して、どれほど速くユーザがビデオウオールを特定の方向に移動させたいか指示するユーザ入力アクションを指定することができる。例えば、速度を指定するユーザ入力アクションは、ユーザがキーボード上の矢印キーをどれほど長く下方保持するか、ユーザがマウスをどれほど速く移動するか、ユーザがアナログジョイスティックをどれほど遠くにそらすか、ユーザが自分の指をタッチスクリーン上でどれほど速くスワイプするか、或いはユーザが行動動き捕獲システムにより追跡されている自分の身体の一部分をどれほど速く動かすか、を含む。図32aは、ディスプレイ装置3200上のビデオウオールの一例を、ユーザがそれを移動する前に示したものである。ビデオウインドウ3201aを含む18個の全ビデオウインドウの6x3アレイが表示されている。ビデオウインドウ3202aを含む付加的な全又は部分ビデオウインドウがディスプレイ装置3200の右縁を越えて延びていることが明らかである。図32bは、ビデオウオールを低速度で左へ移動させるユーザアクション3210bの結果を示す。ビデオウオールの著しい3D遠近感歪は示されておらず、ビデオウインドウ3201bは、ビデオウインドウ3201aの新たな位置1つのウインドウだけ左へを示し、そしてビデオウインドウ3202bは、ビデオウインドウ3202aの新たな位置1つのウインドウだけ左へを示している。図32cは、ビデオウオールを中間速度で左へ移動させるユーザアクション3210cの結果を示す。ビデオウオールの小さな3D遠近感歪が示されている。ビデオウインドウ3201bは、ディスプレイ装置3200の縁を越えて移動され、そしてビデオウインドウ3202cは、ビデオウインドウ3202bの新たな位置2つのウインドウだけ左へを示している。図32dは、ビデオウオールを高速度で左へ移動させるユーザアクション3210dの結果を示す。ビデオウオールの中程度の3D遠近感歪が示されている。ビデオウインドウ3202dは、ビデオウインドウ3202cの新たな位置2つのウインドウだけ左へを示している。図示された例において、ユーザがアクションを完了し、そしてビデオウオールアニメーションが徐々に低速化して停止すると、3D遠近感歪が徐々に減少し、最終的には、画像に3D遠近感歪がほとんど又は全く現れない状態で停止となる。画像が移動を停止しそして3D遠近感歪がなくなった後に生じる表示画像は、図32a又は32bと同様のものに見える。図32dにおいて、ビデオウオールは、3D遠近感歪が小さいビデオウオールに表示されるものより多くのビデオウインドウを遠くに表示する。例えば、図32aは、18個の全ビデオウインドウを示すが、図32dは、27個の全ビデオウインドウを示す。ユーザが非常に速い動きを行う場合には、3D遠近感歪は、更に顕著なものとなって、更に多くのビデオウインドウ、おそらく、100個以上が空間へと延びることを表す。app/gameサーバー1521-1525を使用してそのような視覚効果を具現化する上で1つの難点は、サーバーが非常に多数の同時圧縮又は非圧縮のビデオウインドウを受け取って、それらを全てのタイルに表示するために全て解凍し及び/又は表示しなければならないことである。そのような多数のビデオストリームを取り扱うネットワーク及び処理オーバーヘッドは、非常に高いものとなる。この問題を克服するため、1つの実施形態では、ビデオウオールが急速に移動して深い3D遠近感歪を示すときは全てのビデオウインドウが全フレームレートで走るビデオストリームを示すのではない。例えば、図32dにおいて、ウインドウ3221-3226は、真のビデオストリームを示すが、ウインドウ3231-3236は、互いに同期ずれした異なる静止画像へ移行する静止画像を示す。ウオールが移動し、そして多数の活動があるので、人間の目は、おそらく、1つのビデオウインドウを長時間たどることができず、特に、ウインドウ3235のようにウインドウが小さく且つ3D遠近感歪内の遠くにある場合には、そうである。又、静止画像が異なる静止画像へと周期的に及び理想的には互いに同期ずれして変化する限り、ビデオウオールを見る人間の目にとって、全真のビデオが全ての静止画像ウインドウに再生されているかのように見える。又、静止画像の移行は、見る者にとって、リアルタイムビデオにおけるシーンの移行であるかのように見える。従って、静止画像を使用して真のビデオの幻想を生み出すことで、app/gameサーバー1521-1525におけるオーバーヘッドを著しく減少することができる。というのは、app/gameサーバー1521-1525は、ウインドウの小さなサブセットに対して全ビデオストリームを取り扱えばよいからである。静止画像は、広範囲な様々なランダム画像から供給されるが、依然圧倒的にウインドウが真のビデオを含んでいるように見える。静止画像は、ビデオウオールが移動せずに深い3D遠近感歪にある場合には、ウインドウに表示されたビデオのフレームから供給されるのが好ましい。実際のビデオからの静止フレームが得られない場合には、同様のジャンルのビデオからのフレームを使用することができる。例えば、特定のビデオゲームをウインドウにおいて見る場合には、そのビデオゲームの以前に記録されたセッションからの静止画像フレームを使用してもよい。ビデオウオールの動きが低速化され又は停止され、そして少数のウインドウが表示されると例えば、図32a及び32b、全てのウインドウが真のビデオを再び表示する。このように、ユーザに良く見えるに充分なほど低速でビデオウオールが移動するときは、ユーザは、全てのウインドウが真のビデオであるように見る。一実施形態では、ここに示す種々の機能的モジュール及び関連するステップは、そのステップを遂行するための固定布線ロジックを含む特定のハードウェアコンポーネント、例えば、特定用途向け集積回路ASICにより遂行されるか、又はプログラムされたコンピュータコンポーネント及びカスタムハードウェアコンポーネントの組合せにより遂行される。一実施形態では、これらモジュールは、テキサスインスツルーメント社のTMS320xアーキテクチャー例えば、TMS320C6000、TMS320C5000、等のプログラム可能なデジタル信号プロセッサDSPにおいて具現化される。これらの基礎的な原理に適合する種々の異なるDSPを使用することができる。これら実施形態は、上述した種々のステップを含むことができる。これらステップは、汎用プロセッサ又は特殊目的のプロセッサが幾つかのステップを遂行するようにさせるマシン実行可能なインストラクションにおいて実施することができる。これら基礎的な原理に関連しない種々の要素、例えば、コンピュータメモリ、ハードドライブ、入力装置は、当該観点を不明瞭にしないために図面から除外してある。ここに開示する要旨の要素は、マシン実行可能なインストラクションを記憶するためのマシン読み取り可能なメディアとして与えられてもよい。マシン読み取り可能なメディアは、フラッシュメモリ、光学的ディスク、CD-ROM、DVDROM、RAM、EPROM、EEPROM、磁気又は光学カード、電子的インストラクションを記憶するのに適した他の形式のマシン読み取り可能なメディアを含むが、これらに限定されない。又、ここに開示する要旨の要素は、一連のオペレーションを遂行するようにコンピュータ例えば、プロセッサ又は他の電子装置をプログラムするのに使用されるインストラクションが記憶されたマシン読み取り可能なメディアを含むコンピュータプログラム製品として提供されてもよいことを理解されたい。或いは又、オペレーションは、ハードウェア及びソフトウェアの組合せにより遂行されてもよい。マシン読み取り可能なメディアは、フロッピー登録商標ディスケット、光学的ディスク、CD-ROM、及び磁気光学ディスク、ROM、RAM、EPROM、EEPROM、磁気又は光学カード、電子的インストラクションを記憶するのに適した他の形式のマシン読み取り可能なメディアを含むが、これらに限定されない。更に、ここに開示する要旨は、特定の実施形態に関連して説明したが、本開示の範囲内で多数の変更や修正がなされ得る。従って、本発明及び添付図面は、単なる例示に過ぎず、それに限定されるものではない。"