記録音声及び動画メディアは、トーマスエジソンの時代から世相を表している。20世紀の初頭に、記録音声メディア(シリンダー及びレコード)及び動画メディア(ニコロデオン及び映画)が広く配給されたが、両技術は、まだ幼時期であった。1920年代後期に、動画が大量市場ベースで音声と結合され、その後、音声を伴うカラー動画となった。ラジオ放送は、大規模な広告支援形態の放送大量市場音声メディアへと徐々に進化した。1940年代中期にテレビ(TV)放送規格が確立されると、テレビは、予め録画された又は生の動画を家庭へ届ける放送大量市場メディアの一形式としてラジオに加わった。
20世紀中期までは、米国の家庭の大部分は、記録音声メディアを再生する蓄音器レコードプレーヤ、生放送音声を受信するラジオ、及び生放送オーディオ/ビデオ(A/V)メディアを上映するテレビ受像機を有していた。多くの場合に、これら3つの「メディアプレーヤ」(レコードプレーヤ、ラジオ及びTV)は、共通のスピーカを共有する1つのキャビネットに結合されて、家庭の「メディアセンター」となった。メディアの選択肢は、消費者に制限されるが、メディア「エコシステム」は、かなり安定したものであった。ほとんどの消費者は、「メディアプレーヤ」をどのように使用するか知っており、それらの能力をフルに楽しむことができた。同時に、メディアの発行者(主に動画及びテレビスタジオ、並びに音楽会社)は、一般に普及した海賊版又は「二次販売」即ち中古メディアの再販から悩まされることなく、それらのメディアを劇場及び家庭の両方に配給することができた。典型的に、発行者は、二次販売から収入を得ず、従って、そうでなければ新規販売のために中古メディアの買い手から発行者が得るかもしれない収入が減少した。20世紀の中期に販売された中古レコードは確かにあるが、そのような販売は、レコード発行者に大きな影響を及ぼさなかった。というのは、典型的に大人が一度又は数回見るだけの動画又はビデオ番組とは異なり、音楽トラックは、数百回又は数千回も聞かれるからである。従って、音楽メディアは、動画/ビデオメディアより遥かに「腐敗」しない(即ち、大人の消費者にとって価値が継続する)。レコードを購入すると、消費者がその音楽が好きな場合、消費者は、おそらくそれを長期間保持する。
20世紀の中期から今日にかけて、メディアエコシステムは、消費者及び発行者の利益及び損害の両方にとって一連の根本的な変化を受けた。オーディオレコーダー、特に、高品質ステレオサウンド付きのカセットテープが広く導入されると、確かに高度の消費者便宜性があった。しかし、それは、消費者メディアと共に今や広く普及したもの、即ち海賊版の始まりも印した。確かに、大勢の消費者が彼ら自身のレコードを純粋に便宜性のためにテープ記録するのにカセットテープを使用したが、次第に多くの消費者(例えば、互いのレコードコレクションに手早くアクセスできる寄宿舎の学生)が海賊版コピーを作成した。又、消費者は、発行者からレコードやテープを買うのではなく、ラジオを経て演奏される音楽もテープ記録した。
消費者向けVCRの出現は、新規なVCRがTVショーを録画するようにセットでき、後で見ることができるので、更なる消費者便宜性を導くと共に、映画やTV番組に「オンデマンド」ベースでアクセスできるビデオレンタルビジネスの創設も導いた。1980年代中期以来の大量市場家庭用メディア装置の急速な開発は、かつてない選択肢レベル及び消費者にとっての便宜性を導くと共に、メディア発行市場の急速な膨張も導いた。
今日、消費者は、過度のメディア選択肢及び過度のメディア装置に直面し、その多くは、特定の形式のメディア又は特定の発行者に結び付いたものである。熱心なメディア消費者は、家の種々の部屋にTV及びコンピュータに接続された装置を積み重ねて有し、その結果、1つ以上のTV受像機及び/又はパーソナルコンピュータ(PC)へのケーブルの「ネズミの巣穴」、並びにリモートコントローラのグループが生じている。(本出願に関して、「パーソナルコンピュータ」又は「PC」という語は、デスクトップ、Macintosh(登録商標)又は他の非Windows(登録商標)コンピュータ、Windows適合装置、Unix(登録商標)バリエーション、ラップトップ、等を含めて、家庭又はオフィスで使用するのに適した任意の種類のコンピュータを指す。)これらの装置は、ビデオゲームコンソール、VCR、DVDプレーヤ、オーディオサラウンド−サウンドプロセッサ/増幅器、衛星セットトップボックス、ケーブルTVセットトップボックス、等を含む。そして、熱心な消費者にとって、互換性の問題があるために、複数の類似機能装置が存在する。例えば、消費者は、HD−DVD及びBlu−ray DVDプレーヤの両方を所有したり、又はMicrosoft Xbox(登録商標)及びSony Playstation(登録商標)の両ビデオゲームシステムを所有したりすることがある。実際に、あるゲームはゲームコンソールのバージョンにわたって互換性がないために、消費者は、XBoxと、その後のバージョン、例えば、Xbox360(登録商標)との両方を所有することがある。多くの場合、消費者は、どのビデオ入力及びどのリモートコントローラを使用すべきか混乱する。ディスクが正しいプレーヤ(例えば、DVD、HD−DVD、Blu−ray、Xbox又はPlaystation)に入れられ、その装置に対してビデオ及びオーディオ入力が選択され、そして正しいリモートコントローラが見つかった後でも、消費者は、まだ、技術的な挑戦に直面する。例えば、ワイドスクリーンDVDのケースでは、ユーザは、先ず、自分のTV又はモニタスクリーンにおける正しいアスペクト比(例えば、4:3、フル、ズーム、ワイドズーム、シネマワイド、等)を決定し、次いで、セットすることが必要になる。同様に、ユーザは、先ず、正しいオーディオサラウンドサウンドシステムフォーマット(例えば、AC−3、ドルビーデジタル、DTS、等)を決定し、次いで、セットすることが必要になる。多くの場合、消費者は、彼等のテレビ又はオーディオシステムのフル能力でメディアコンテンツを楽しんでいないことに気付かない(例えば、間違ったアスペクト比で押しつぶされた映画を見たり、又はサラウンドサウンドではなくステレオでオーディオを聞いたりしている)。
装置の積み重ね体には、インターネットベースのメディア装置が益々追加されている。Sonos(登録商標)デジタルミュージックシステムのようなオーディオ装置は、インターネットからオーディオを直接ストリーミングしている。同様に、Slingbox(登録商標)エンターテイメントプレーヤのような装置は、ビデオを録画し、そしてホームネットワーク又はインターネットを通してそれをストリーミングし、遠隔位置でPCにおいてそれを見ることができる。インターネットプロトコルテレビジョン(IPTV)サービスは、デジタルサブスクライバーライン(DSL)又は他のホームインターネット接続を通してケーブルTV型のサービスを提供している。又、最近では、Moxi(登録商標)メディアセンターや、Windows XPメディアセンターエディションを実行するPCのような単一の装置へ複数のメディアファンクションを一体化する努力もなされている。これらの装置は、各々、それが遂行するファンクションに対する便宜性の要素を与えるが、偏在性及びほとんどのメディアへの簡単なアクセス性が欠如している。更に、このような装置は、多くの場合に高価な処理及び/又はローカル記憶が必要なために、製造コストがしばしば数百ドルに達する。更に、これらの近代的な消費者向け電子装置は、典型的に、アイドル状態である間も、多量の電力を消費し、これは、時間と共に経費高となり且つエネルギーリソースを浪費することを意味する。例えば、ある装置は、消費者がそれをターンオフするのを怠るか又は異なるビデオ入力へスイッチした場合に動作し続けることがある。そして、どの装置も完全な解決策ではないので、家庭内の装置の他の積み重ね体と一体化しなければならず、これでは、依然、ユーザをワイヤのネズミの巣穴及びリモートコントローラの海に残すことになる。
更に、多くの新しいインターネットベースの装置は、それが適切に機能するときには、典型的に、メディアを、それが入手できる以上に一般的な形態で提供する。例えば、インターネットを通してビデオをストリーミングする装置は、多くの場合、ビデオ、ゲームの「制作」又は演出家の解説のようなDVDをしばしば付随する双方向「エキストラ」ではなく、ビデオ資料だけをストリーミングする。これは、多くの場合、双方向性をローカルに取り扱う特定の装置に意図された特定のフォーマットで双方向資料が発生されることによるものである。例えば、DVD、HD−DVD及びBlu−rayディスクは、それら自身の特定の双方向フォーマットを有している。普及型フォーマットを全てサポートするように開発されるホームメディア装置又はローカルコンピュータは、おそらく消費者が動作するには法外なほど高価で且つ複雑なものにするレベルの精巧さ及び融通性を要求することになる。
この問題に加えて、将来的に新規なフォーマットが導入された場合には、ローカル装置は、その新規なフォーマットをサポートするハードウェア能力をもたないことがあり、これは、消費者がアップグレード型のローカルメディア装置を購入しなければならないことを意味する。例えば、高解像度ビデオ又はステレオビデオ(例えば、各目に対して1つのビデオストリーム)が後日に導入された場合には、ローカル装置は、そのビデオをデコードする計算能力をもたないか、又は新たなフォーマットでビデオを出力するためのハードウェアをもたないことがある(例えば、各目に60fpsが与えられて、120fpsのビデオがシャッター付き眼鏡と同期されることでステレオ感が達成されると仮定すれば、消費者のビデオハードウェアが60fpsビデオしかサポートできない場合、このオプションは、アップグレード型ハードウェアを購入しなければ、利用できない)。
メディア装置の老朽化及び複雑さの問題は、精巧な双方向メディア、特に、ビデオゲームに至ったときには、重大な問題となる。
近代的なビデオゲームアプリケーションは、主として、4つの主要な非ポータブルハードウェアプラットホーム:即ち、Sony Playstation(登録商標)1、2及び3(PS1、PS2及びPS3)、Microsoft Xbox(登録商標)及びXbox 360(登録商標)、Nintendo Gamecube(登録商標)及びWiiTM、並びにPCベースのゲーム、に分割される。これらプラットホームの各々は、他のものとは異なり、1つのプラットホームで実行するように書かれたゲームは、別のプラットホームでは実行されない。又、装置のある世代から次の世代への互換性の問題もある。ソフトウェアゲーム開発者の大半が、特定のプラットホームとは独立して設計されたソフトウェアゲームを創作しても、特定のゲームを特定のプラットホームで実行するためには、特定のプラットホームで使用するようにゲームを適応させるのに、ソフトウェアの専有レイヤ(しばしば「ゲーム開発エンジン」と称される)が必要になる。各プラットホームは、消費者へ「コンソール」(即ち、TV又はモニタ/スピーカに取り付けられるスタンドアローンボックス)として販売されるか、或いはPCそれ自体である。典型的に、ビデオゲームは、精巧なリアルタイムソフトウェアアプリケーションとして実施されるビデオゲームを含むBlu−ray DVD、DVD−ROM、又はCD−ROMのような光学的メディアで販売される。家庭用ブロードバンドの速度が高まるにつれて、ビデオゲームは、ダウンロードに利用されることが益々増えている。
ビデオゲームソフトウェアとのプラットホーム互換性を得るための特定の要件は、進歩型ビデオゲームのリアルタイム性及び高計算要件のために極めて厳しいものである。例えば、あるPCから、より速い処理ユニット又はコアをもつ別のPCへの製造アプリケーション(例えば、マイクロソフトワード)の一般的な互換性と同様に、ビデオゲームのある世代から次の世代への(例えば、XBoxからXBox360への、又はPlaystation2(PS2)からPlaystation3(PS3)への)完全なゲーム互換性が期待される。しかしながら、ビデオゲームでは、このようにならない。ビデオゲームの製造者は、典型的に、あるビデオゲーム世代が発売になるときに所与の価格点に対して考えられる最高の性能を求めているので、前世代システムに対して書かれた多くのゲームが後世代システムでは機能しないような急激なアーキテクチャー変更がシステムに対してしばしばなされる。例えば、XBoxは、プロセッサのx86ファミリーをベースとしたものであり、一方、XBox360は、PowerPCファミリーをベースとしたものである。
従来のアーキテクチャーをエミュレートするための技術を利用できるが、ビデオゲームがリアルタイムアプリケーションであるとすれば、エミュレーションにおいて厳密に同じ挙動を達成することはしばしば不可能である。これは、消費者、ビデオゲームコンソール製造者、及びビデオゲームソフトウェア発行者にとって損害である。消費者については、全てのゲームをプレイできるようにするために、ビデオゲームコンソールの新旧の世代をTVに接続したままにする必要があることを意味する。コンソールの製造者については、エミュレーションに関連したコスト、及び新規コンソールの採用に手間取ることを意味する。又、発行者については、全ての潜在的な消費者に届くように、新たなゲームの複数のバージョンを発売する必要があり、即ちビデオゲームのブランド(例えば、XBox、Playstation)ごとのバージョンを発売するだけでなく、所与のブランドのバージョン(例えば、PS2及びPS3)ごとのバージョンをしばしば発売する必要がある。例えば、他のプラットホームの中でも、XBox、XBox 360、PS2、PS3、Gamecube、Wii及びPCに対して、エレクトロニックアーツ“Madden NFL 08”の個別バージョンが開発されている。
セルラー(セル)電話及びポータブルメディアプレーヤのようなポータブル装置も、ゲーム開発者への挑戦を提示する。次第に、このような装置は、ワイヤレスデータネットワークに接続されており、ビデオゲームをダウンロードできるようになっている。しかし、市場には、広範囲な異なる表示解像度及び計算能力をもつ種々様々なセル電話及びメディア装置が出回っている。又、このような装置は、典型的に、電力消費、コスト及び重量に制約があるので、カリフォルニア州サンタクララのNVIDIAで製造される装置、等のグラフィックプロセッシングユニット(GPU)のような進歩型グラフィック加速ハードウェアに欠けるものである。その結果、ゲームソフトウェアの開発者は、典型的に、多数の異なる形式のポータブル装置に対して所与のゲームタイトルを同時に開発する。ユーザは、自分の特定のセル電話又はポータブルメディアプレーヤに対して所与のゲームタイトルが得られないことが分かる。
家庭用ゲームコンソールの場合には、ハードウェアプラットホームの製造者は、典型的に、彼等のプラットホームでゲームを発行する能力についてソフトウェアゲーム開発者にロイヤリティを課する。セル電話の電信会社も、典型的に、ゲームをセル電話にダウンロードするためにゲーム発行者にロイヤリティを課する。PCゲームの場合には、ゲームを発行するために支払われるロイヤリティはないが、ゲームの開発者は、典型的に、生じ得る広範囲のPCコンフィギュレーション及びインストール問題をサポートするための消費者サービス負担が大きいために、高いコストに直面する。又、PCは、典型的に、ゲームソフトウェアの海賊行為に対してバリアがほとんどない。というのは、それらは、技術的知識のあるユーザによって再プログラムが容易であり、ゲームの海賊版を容易に作成して(例えば、インターネットを通して)容易に配布することができる。従って、ソフトウェアゲーム開発者については、ゲームコンソール、セル電話及びPCにおいて発行する上でコストがかかり且つ欠点があることになる。
コンソール及びPCソフトウェアのゲーム発行者にとって、コストは、これだけでは終わらない。小売チャンネルを通してゲームを配布するために、発行者は、利ざやを得るように小売店の販売価格より低い卸売価格を課する。又、発行者は、典型的に、製造コストを支払いそしてゲームを保持する物理的メディアを配布しなければならない。又、発行者は、例えば、ゲームが売れない場合、ゲームの価格が下がった場合、或いは小売店が卸売価格の一部又は全部を払い戻し及び/又はゲームを買い手から引き取らねばならない場合に考えられる不測の事態をカバーするために小売店により「価格保護費用」がしばしば課せられる。更に、小売店は、典型的に、広告チラシでゲームを市場に出す上で助けとなるように発行者に費用を課する。更に、小売店は、ゲームをプレイし終えたユーザからゲームを買い戻して、それを中古ゲームとして販売し、典型的に、中古ゲームの収入をゲーム発行者と分配しないことが増えている。ゲーム発行者に課せられるコスト負担に加えて、しばしばゲームの海賊版が作成されてインターネットを通して配布され、ユーザがそれをダウンロードして無料でコピーする事態になっている。
インターネットのブロードバンド速度が高まりつつあり、そして米国内及び世界中で、特に、家庭や、インターネット接続PCがレンタルされるインターネット「カフェー」へのブロードバンド接続がより一般的になってきているので、ゲームは、PC又はコンソールへのダウンロードを経て益々配布されてきている。又、マルチプレーヤ及び大規模マルチプレーヤのオンラインゲームをプレイするためにブロードバンド接続が益々使用されてきている(それらは、両方とも、本開示では頭文字“MMOG”で参照される)。これらの変更は、小売配布に関連した問題及びコストをある程度軽減する。オンラインゲームをダウンロードすることは、配布コストが典型的に僅かであり且つ売れ残りメディアからのコストがほとんど又は全くないという点で、幾つかの欠点をゲーム発行者に差し向ける。しかし、ダウンロードされたゲームは、依然、海賊行為を受け、そしてそのサイズ(しばしば数ギガバイトのサイズ)のために、ダウンロードするのに非常に長い時間を要する。更に、ポータブルコンピュータ又はビデオゲームコンソールと共に販売されるような小さなディスク装置は複数のゲームで埋め尽くされる。しかしながら、ゲーム又はMMOGがプレイ可能なゲームのためのオンライン接続を要求する程度まで、海賊版の問題は、軽減されている。というのは、ユーザが、通常、有効なユーザアカウントを有することが要求されるからである。ディスプレイスクリーンのビデオを撮影するカメラ又はスピーカからの音声を録音するマイクロホンによりコピーできるリニアメディア(例えば、ビデオ及び音楽)とは異なり、各ビデオゲームの経験は独特なものであり、簡単なビデオ/オーディオ記録を使用してコピーすることができない。従って、著作権法が強力に施行されておらず、海賊行為が横行する地域でも、MMOGは、海賊行為から遮蔽され、それ故、ビジネスをサポートすることができる。例えば、Vivendi SAの“World of Warcraft”MMOGは、世界中にわたって海賊行為で悩まされずに首尾良く展開された。そして、多くのオンライン又はMMOGゲーム、例えば、Linden Labの“Second Life”MMOGは、オンラインツールを使用して資産を買い、売り、そして形成するゲームに内蔵された経済的モデルを通してゲームのオペレータのための収入を発生する。従って、従来のゲームソフトウェアの購入又は契約に加えて、メカニズムを使用して、オンラインゲームを使用するための支払をすることができる。
オンラインの性質又はMMOGにより海賊行為をしばしば軽減できるが、オンラインゲームオペレータは、依然、残りの挑戦に直面している。多くのゲームは、オンライン又はMMOGが適切に機能するために実質的なローカル(即ち、家庭内)処理リソースを要求する。ユーザは、性能の低いローカルコンピュータ(例えば、ローエンドラップトップのような、GPUをもたないもの)を有する場合に、ゲームをプレイできないことがある。更に、ゲームコンソールが古くなるにつれて、最新型から徐々に後退し、より進歩したゲームを取り扱うことができなくなる。ユーザのローカルPCがゲームの計算要求を取り扱いできると仮定しても、しばしばインストールの複雑さがある。ドライバの互換性がないことがある(例えば、新たなゲームがダウンロードされる場合に、グラフィックドライバの新たなバージョンがインストールされ、これは、グラフィックドライバの古いバージョンに基づく以前にインストールされたゲームを不作動にすることがある)。コンソールは、より多くのゲームがダウンロードされるにつれて、ローカルディスクスペースを使い果たす。複雑なゲームは、典型的に、バグが見つかって修理されたとき、又はゲームに変更がなされた場合に(例えば、ゲームのレベルがプレイするのに難し過ぎるか又は容易過ぎるとゲーム開発者が分かった場合に)、ゲーム開発者から時間と共にダウンロードされたパッチを受け取る。これらのパッチは、新たなダウンロードを要求する。しかし、時々、全てのユーザが全てのパッチのダウンロードを完了するのではない。他のときには、ダウンロードされたパッチが他の互換性又はディスクスペース消費の問題を導入する。
又、ゲームのプレイ中に、グラフィック又は挙動情報をローカルPC又はコンソールに与えるために大きなデータダウンロードが要求されることがある。例えば、ユーザがMMOGの部屋に入り、そしてグラフィックデータで作られるか又はユーザのローカルマシンでは得られない挙動をもつシーン又はキャラクタに遭遇する場合には、そのシーン又はキャラクタのデータをダウンロードしなければならない。その結果、インターネット接続が充分に高速でない場合には、ゲームのプレイ中に実質的な遅延を招く。そして、遭遇したシーン又はキャラクタが、ローカルPC又はコンソールを越えるような記憶スペース又は計算能力を要求する場合には、ユーザがゲームを進められないか又は質の低いグラフィックで続けねばならない事態を招く。従って、オンライン又はMMOGゲームは、それらの記憶及び/又は計算の複雑さの要件をしばしば制限する。更に、それらは、ゲーム中のデータ転送の量をしばしば制限する。又、オンライン又はMMOGは、ゲームをプレイできるユーザの市場を狭めることもある。
更に、技術的知識のあるユーザがゲームのローカルコピーをリバースエンジニアリングし、そしてチートできるようにゲームを変更することが次第に増えてきている。チートは、人間的に可能である以上に速くボタン押しを繰り返すのと同程度に簡単である(例えば、銃を非常に速く撃つように)。ゲーム内資産トランザクションをサポートするゲームでは、チートが、実際の経済的価値の資産を含む詐欺的トランザクションを生じるレベルの精巧さに到達する。オンライン又はMMOG経済的モデルがそのような資産トランザクションに基づくものであるときは、これは、ゲームオペレータに実質的に有害な結果をもたらす。
新たなゲームを開発するコストは、PC及びコンソールが(例えば、リアルタイムレイトレーシングのようなより現実的なグラフィック、及びリアルタイム物理的シミュレーションのようなより現実的な挙動と共に)益々精巧なゲームを作成できるのにつれて増大している。ビデオゲーム産業の初期には、ビデオゲーム開発は、アプリケーションソフトウェア開発に非常に類似したプロセスであり、即ち開発コストの大部分は、ソフトウェアの開発であり、グラフィック、オーディオ、及び挙動エレメント又は「資産」の開発、例えば、広範囲な特殊効果をもつ動画に対して開発されるものではない。今日、多くの精巧なビデオゲーム開発努力は、ソフトウェア開発よりも、特殊効果に富んだ動画開発に厳密に似ている。例えば、多くのビデオゲームは、3D世界のシミュレーションを与え、そして益々ホトリアリスティックな(即ち、生きた動きの映像写真撮影と同程度に現実的に見えるコンピュータグラフィックの)キャラクタ、プロップ及び環境を発生する。ホトリアリスティックなゲーム開発の最も挑戦的な観点の1つは、生きた動きの人間の顔と見分けがつかないようなコンピュータ発生の人間の顔を創作することである。カリフォルニア州サンフランシスコのMovaにより開発されたContourTMリアリティキャプチャーのような顔捕獲技術は、演技者の顔の正確な形状を運動中に高い解像度で捕獲し追跡する。この技術は、捕獲された生きた動きの顔と実質上区別できない3Dの顔をPC又はゲームコンソール上にレンダリングできるようにする。「ホトリアル」な人間の顔を捕獲してレンダリングすることは、多数の観点で有用である。第1に、非常に認識し易い有名人又はスポーツプレーヤ(多くの場合に高い費用で雇われた)がビデオゲームにしばしば使用され、不完全さがユーザにとって明らかで、視覚体験(viewing experience)を混乱させ又は不快にさせることがある。又、多くの場合に、高度のホトリアリズムを達成するには高度の細部が要求され、即ち、潜在的に、顔が動くときに多角形及び/又はテクスチャがフレームごとに変化するようにして、多数の多角形及び高解像度テクスチャをレンダリングすることが要求される。
詳細なテクスチャを伴う多数の多角形のシーンが急速に変化するときには、ゲームをサポートするPC又はゲームコンソールは、ゲームセグメントで発生される所要数のアニメーションフレームに対して充分な多角形及びテクスチャデータを記憶するに足るRAMを有していないことがある。更に、PC又はコンソールに典型的に利用できる単一の光学的ドライブ又は単一のディスクドライブは、通常、RAMより非常に低速であり、そして典型的に、多角形及びテクスチャをレンダリングする際にGPUが受け容れられる最大データレートを維持することができない。現在のゲームは、典型的に、多角形及びテクスチャの大部分をRAMにロードし、これは、所与のシーンの複雑さ及び時間巾が主としてRAMの容量により制限されることを意味する。例えば、顔のアニメーションの場合に、これは、ゲームが休止して多角形及びテクスチャ(及び他のデータ)をより多くのフレームに対してロードする前に、PC又はゲームコンソールを、ホトリアルでない低解像度の顔、又は限定された数のフレームについてのみアニメ化できるホトリアルな顔、のいずれかに制限する。
“Loading...”に類似したメッセージをPC又はコンソールが表示するときに進行バーがスクリーンを横切ってゆっくり移動するのを見ていることは、複雑なビデオゲームの今日のユーザによって固有の欠点として容認されている。次のシーンがディスク(ここで、「ディスク」とは、特に指示のない限り、不揮発性の光学又は磁気メディア、並びに非ディスクメディア、例えば、半導体「フラッシュ」メモリを指す)からロードする間の遅延は、数秒又は数分を要する。これは、時間の浪費であり、ゲームプレーヤにとってかなりのフラストレーションとなる。上述したように、多くの又は全ての遅延は、多角形、テクスチャ又は他のデータをディスクからロードする時間によるものであるが、PC又はコンソール内のプロセッサ及び/又はGPUがシーンのためのデータを準備する間にロード時間の一部分が費やされる場合もある。例えば、サッカービデオゲームは、プレーヤが、多数の選手、チーム、スタジアム及び天候条件の中から選択を行えるようにする。従って、どんな特定の組合せが選択されるかに基づいて、異なる多角形、テクスチャ及び他のデータ(集合的に「オブジェクト」)がシーンに対して要求される(例えば、異なるチームは、そのユニホームに異なるカラー及びパターンを有する)。多数の又は全ての種々の順列を列挙し、多数の又は全てのオブジェクトを前もって予め計算し、そしてそれらオブジェクトを、ゲームを記憶するのに使用されるディスクに記憶することができる。しかし、順列の数が多い場合には、全オブジェクトに対して要求される記憶の量が、ディスクに適合するには大き過ぎる(ダウンロードするには不可能である)ことがある。従って、既存のPC及びコンソールシステムは、典型的に、所与のシーンの複雑さ及びプレイ時間巾の両方について制約があり、複雑なシーンに対する長いロード時間で悩まされている。
従来のビデオゲームシステム及びアプリケーションソフトウェアシステムに伴う別の顕著な制限は、それらが、例えば、PC又はゲームコンソールへ処理のためにロードされる必要のある多角形及びテクスチャのような3Dオブジェクトの大きなデータベースを次第に使用してきていることである。上述したように、このようなデータベースは、ディスクにローカルに記憶されるときに長いロード時間を要する。しかしながら、ロード時間は、通常、データベースがリモート位置に記憶されそしてインターネットを通してアクセスされる場合には更に厳しいものとなる。このような状態では、大きなデータベースをダウンロードするのに、数分、数時間、又は数日を要することがある。更に、このようなデータベースは、多くの場合に多大な費用で生成され(例えば、ゲーム、映画又は歴史ドキュメンタリーに使用するための詳細な高いマスト付きの帆船の3Dモデル)、そしてローカルエンドユーザに販売するように意図される。しかしながら、データベースは、ローカルユーザへダウンロードされると、海賊行為を受けるおそれがある。多くの場合、ユーザは、データベースを評価してそれがユーザのニーズに合うか(例えば、ユーザが特定の動きをするときにゲームキャラクタの3Dコスチュームが満足な見掛け又は外観を有するか)どうか調べるだけのためにデータベースのダウンロードを希望する。長いロード時間は、購入することを決断する前に3Dデータベースを評価するユーザにとって妨げになる。
MMOGでは、特に、ユーザがカスタマイズされたキャラクタを次第に使用できるようなゲームとして、同様の問題が発生する。キャラクタを表示するためのPC又はゲームコンソールの場合に、3D幾何学(多角形、テクスチャ、等)のデータベースへのアクセス及びそのキャラクタに対する挙動(例えば、キャラクタが盾を有する場合に、その盾が槍をそらすに充分な強度であるかどうか)を得ることが必要である。典型的に、MMOGがユーザにより最初にプレイされるときには、キャラクタに対する多数のデータベースが、ゲームの初期コピーと共に予め入手でき、これは、ゲームの光学的ディスクにローカルで入手できるか又はディスクへダウンロードされる。しかし、ゲームが進行するにつれて、データベースがローカルで入手できないキャラクタ又はオブジェクトにユーザが遭遇する場合には(例えば、別のユーザがカスタマイズされたキャラクタを生成した場合には)、そのキャラクタ又はオブジェクトを表示できるまでに、そのデータベースがダウンロードされねばならない。これは、ゲームの実質的な遅延を生じさせる。
ビデオゲームの精巧さ及び複雑さがあるとすれば、従来のビデオゲームコンソールでのビデオゲーム開発者及び発行者の別の挑戦は、多くの場合、数千万ドルのコストで2ないし3年を掛けてビデオゲームを開発することである。新規なビデオゲームコンソールプラットホームがほぼ5年毎に一度の割合で導入されると仮定すれば、ゲーム開発者は、新規なプラットホームが発売されるのと同時にビデオゲームを入手できるようにするために、新規なゲームコンソールの発売よりこれらゲーム年だけ前に開発作業をスタートする必要がある。ほぼ同じ時期に(例えば、互いに1年又は2年以内に)競合する製造者から多数のコンソールが時々発売されるが、調べなければならないものは、各コンソールの人気であり、例えば、どのコンソールがビデオゲームソフトウェアの最大売り上げを生じるかである。例えば、近年のコンソールサイクルでは、Microsoft XBox360、Sony Playstation3及びNintendo Wiiがほぼ同じ一般的な時間枠で導入されるようにスケジュールされている。しかし、導入の何年か前に、ゲーム開発者は、どのコンソールプラットホームが他のものより成功するか本質的に「賭け」をし、それに応じて、開発リソースを捧げなければならない。又、動画制作会社も、映画の封切りの充分前に映画の成功の見込みの推定に基づいて限られた制作リソースを配分しなければならない。ビデオゲームに要求される投資レベルの増大を仮定すれば、ゲーム制作は、動画制作と益々類似してきており、ゲーム制作会社は、特定のビデオゲームの将来の成功の推定に基づいて制作リソースを日常的に捧げる。しかし、動画会社とは異なり、この賭けは、単に制作それ自体の成功に基づくものではなく、むしろ、ゲームの実行が意図されたゲームコンソールの成功に基づいたものである。複数のコンソールに対するゲームを一度に発売することでリスクを軽減できるが、この付加的な努力がコストを増大し、ゲームの実際の発売をしばしば遅らせる。
PCにおけるアプリケーションソフトウェア及びユーザ環境は、ユーザに対してより視覚的に訴えるだけでなく、より有効で且つ直感的なものにするために、計算上より集中的で、動的で且つ双方向のものとなる。例えば、新規なWindows VistaTMオペレーティングシステム、及びMacintosh(登録商標)オペレーティングシステムの次々のバージョンは、視覚アニメーション効果を合体している。Autodesk社からのMayaTMのような進歩型グラフィックツールは、最新のCPU及びGPUの限界を押し進める非常に精巧な3Dレンダリング及びアニメーション能力を与える。しかしながら、これら新規なツールの計算上の要件は、そのような製品のユーザ及びソフトウェア開発者にとって多数の実際上の問題を生じさせる。
オペレーティングシステム(OS)の視覚表示は、もはや販売されていないが新規なOSで依然アップグレード可能である前世代のコンピュータを含めて、広範囲な種類のコンピュータにおいて機能しなければならないので、OSグラフィック要件は、典型的にGPUを含まないコンピュータを含めたOSのターゲットであるコンピュータの最小公分母によって大きく制限される。これは、OSのグラフィック能力を甚だしく制限する。更に、バッテリ作動式のポータブルコンピュータ(例えば、ラップトップ)は、視覚表示能力を制限する。というのは、CPU又はGPUにおける高い計算上のアクティビティが、典型的に、電力消費を高め、バッテリ寿命を短くするからである。ポータブルコンピュータは、典型的に、プロセッサが利用されないときに消費電力を下げるためにプロセッサのアクティビティを自動的に下げるソフトウェアを含む。あるコンピュータモデルでは、ユーザは、プロセッサのアクティビティを手動で下げることができる。例えば、ソニーのVGN−SZ280Pラップトップは、(低性能、長バッテリ寿命のために)片側に“Stamina”と表示され且つ(高性能、短バッテリ寿命のために)他側に“Speed”と表示されたスイッチを含む。ポータブルコンピュータで実行されるOSは、コンピュータがそのピーク性能能力の一部分で実行される場合でも、有用に機能することができねばならない。従って、OSグラフィック性能は、入手可能な最新の計算能力より遥かに下に留まることがしばしばある。
Mayaのようなハイエンドの計算に強いアプリケーションは、高性能PCに使用されるという期待でしばしば販売される。これは、典型的に、非常に高い性能と、より高価で且つ低ポータブル性の最小公分母要求を確立する。その結果、このようなアプリケーションは、汎用のOS(又はMicrosoft Officeのような汎用の生産アプリケーション)より非常に限定されたターゲット視聴者を有し、典型的に、汎用のOSソフトウェア又は汎用のアプリケーションソフトウェアより相当に少ない量で販売される。又、多くの場合、見込みのあるユーザがこのような計算に強いアプリケーションを前もって試すことは困難であるから、潜在的な視聴者は更に限定される。例えば、学生がMayaの使い方を学習することを希望し、又はこのようなアプリケーションについて既に知識のある潜在的な買い手が購入(Mayaを実行できるハイエンドコンピュータを買うことも含む)に投資する前にMayaを試すことを希望すると仮定する。学生又は潜在的な買い手は、Mayaのデモバージョンをダウンロードするか又はその物理的メディアコピーを得ることはできるが、Mayaをそのフル能力(例えば、複雑な3Dシーンを取り扱う)で実行できるコンピュータがない場合には、製品の完全なインフォームドアセスメントを行うことができない。これは、このようなハイエンドアプリケーションの視聴者を制限するものである。又、これは、高い販売価格にも貢献する。というのは、開発コストは、通常、汎用アプリケーションより非常に少数の購入にわたって割賦されるからである。
又、高価格アプリケーションは、個人や企業がアプリケーションソフトウェアの海賊版コピーを使用する大きな誘因も生み出す。その結果、ハイエンドのアプリケーションソフトウェアは、種々の技術を通して海賊行為を軽減するためにそのようなソフトウェアの発行者による顕著な努力にも関わらず、海賊版がはびこることで悩まされている。海賊版のハイエンドのアプリケーションを使用するときでも、ユーザは、海賊版コピーを実行するために高価な最新のPCに投資する必要性を排除することはできない。従って、海賊版ソフトウェアのユーザは、その実際の小売価格の一部分でソフトウェアアプリケーションを使用できるが、そのアプリケーションをフルに利用するためには、高価なPCを購入又は入手することが依然要求される。
高性能の海賊版ビデオゲームのユーザについても同じことが言える。海賊行為者は、ゲームをそれらの実際の価格の一部分で得ることはできるが、ゲームを適切にプレイするのに必要な高価なコンピューティングハードウェア(例えば、GPU増強型PC、又はXBox360のようなハイエンドのビデオゲームコンソール)を購入することが依然要求される。ビデオゲームが典型的に消費者にとって気晴らしであると仮定すれば、ハイエンドのビデオゲームシステムのための付加的なコストが法外なものとなる。この事態は、現在の労働者の平均年収が米国に比してかなり低い国(例えば、中国)では、一層悪いものである。その結果、ハイエンドのビデオゲームシステム又はハイエンドのPCを所有するのは、人口の非常に僅かな割合だけとなる。このような国々では、インターネットに接続されたコンピュータを使用するための料金をユーザが支払う「インターネットカフェ」が極めて一般的となる。多くの場合に、このようなインターネットカフェは、プレーヤが計算に強いビデオゲームをプレイできるようにするGPUのような高性能特徴をもたない旧モデル又はローエンドPCしか有していない。これは、中国で非常に成功し、そこのインターネットカフェで一般にプレイされるVivendiの“World of Warcraft”のような、ローエンドPCで実行されるゲームの成功における重要なファクタである。それと対照的に、“Second Life”のような計算に強いゲームは、中国のインターネットカフェにインストールされたPCでプレイできる見込みが極めて低い。このようなゲームは、インターネットカフェの低性能PCにしかアクセスできないユーザには、実質上アクセス不能である。
又、ビデオゲームの購入を考えており、先ず、インターネットを経て自分の家にゲームのデモバージョンをダウンロードすることによりそれを試してみたいユーザにとってもバリアが存在する。ビデオゲームのデモは、多くの場合、幾つかの特徴がディスエイブルされるか又はゲームのプレイ量に限度が課せられたゲームの一人前のバージョンである。これは、PC又はコンソールのいずれかにゲームをインストールして実行できるまでにギガバイトのゲームをダウンロードする長いプロセス(おそらく数時間)を伴うことがある。PCの場合には、ゲームに対して必要とされる特殊なドライバ(例えば、DirectX又はOpenGLドライバ)を計算し、正しいバージョンをダウンロードして、それらをインストールし、次いで、PCがゲームをプレイできるかどうか決定することを含む。この後者のステップは、PCが充分な処理(CPU及びGPU)能力、充分なRAM、及び互換性のあるOS(例えば、あるゲームは、Windows XPで実行されるが、Vistaでは実行されない)を有するかどうか決定することを含む。従って、ビデオゲームデモを実行するよう試みる長いプロセスの後に、ユーザは、ユーザのPCコンフィギュレーションを仮定すれば、ビデオゲームデモがおそらくプレイできないことを充分見出すことができる。悪いことに、ユーザが、デモを試すために新規なドライバダウンロードすると、それらのドライババージョンは、ユーザがPCにおいて普通に使用している他のゲーム又はアプリケーションとの互換性がないことがあり、従って、デモをインストールすると、以前に動作できたゲーム又はアプリケーションが不作動になることがある。これらのバリアは、ユーザにフラストレーションを与えるだけでなく、ゲームを市場に出すビデオゲームソフトウェア発行者及びビデオゲーム開発者にとってもバリアとなる。
経済的な非効率さを招く別の問題は、所与のPC又はゲームコンソールが、通常、アプリケーション及び/又はゲームに対するあるレベルの性能要件を受け容れるように設計されていることに関する。例えば、あるPCは、多少のRAMを有し、低速又は高速のCPUを有し、そしてGPUを有する場合には低速又は高速のGPUを有する。あるゲーム又はアプリケーションは、所与のPC又はコンソールの全計算パワーの利点を取り入れるが、多くのゲーム又はアプリケーションは、そうではない。ゲーム又はアプリケーションについてのユーザの選択が、ローカルPC又はコンソールのピーク性能能力に達しない場合には、ユーザは、利用されない特徴に関してPC又はコンソール上で金銭を浪費することになる。コンソールの場合には、コンソールの製造者は、コンソールコストを助成するために必要であった以上に支払ったことになる。
ビデオゲームを買って楽しむ際に存在する別の問題は、ユーザがゲームの購入を決める前に他の者がそのゲームをプレイしているのをユーザが見ることができるようにすることに関する。ビデオゲームを記録して後で再生するための多数の従来の解決策が存在する。例えば、米国特許第5,558,339号は、(同じユーザ又は異なるユーザにより所有された)ビデオゲームクライアントコンピュータでの「ゲームプレイ」中にゲームコントローラのアクションを含むゲーム情報体情報を記録することを教示している。この状態情報を後で使用して、ビデオゲームクライアントコンピュータ(例えば、PC又はコンソール)上で幾つか又は全てのゲームアクションを再生することができる。この解決策の顕著な欠点は、ユーザが記録されたゲームを見るために、ユーザは、ゲームをプレイできるビデオゲームクライアントコンピュータを所有すると共に、記録されたゲーム状態が再生されたときにゲームプレイが同一となるようにそのコンピュータ上で実行されるビデオゲームアプリケーションを有していなければならないことである。この他に、ビデオゲームアプリケーションは、記録されたゲームと再生されるゲームとの間に実行の相違がないように書かれねばならない。
例えば、ゲームグラフィックは、一般的に、フレームごとに計算される。多くのゲームの場合に、ゲームロジックは、時々、シーンが特に複雑であるかどうか、又は実行速度を下げる他の遅延があるかどうか(例えば、PCにおいて、ゲームアプリケーションからCPUサイクルを取り去る別のプロセスが実行されるかどうか)に基づいて、次のフレームに対して表示されるグラフィックを計算するのに1フレームより短い又は長い時間を要する。このようなゲームでは、1フレーム時間より若干短く(例えば、数CPUクロックサイクル短く)計算された「スレッシュホールド」フレームが最終的に発生する。その同じシーンが、全く同じゲーム状態情報を使用して再び計算されたときには、1フレーム時間より数CPUクロックサイクル長くかかることが容易に起きる(例えば、内部CPUバスが外部DRAMバスと若干位相ずれし、そしてゲーム処理から数ミリ秒のCPU時間を取り去る別のプロセスによる大きな遅延がなくても、数CPUサイクルの時間遅延を導入する場合には)。それ故、ゲームが再生されるときには、フレームは、1つのフレーム時間ではなく、2つのフレーム時間で計算される。幾つかの挙動は、ゲームがどれほど頻繁に新たなフレームを計算するか(例えば、いつゲームがゲームコントローラから入力をサンプルするか)に基づいている。ゲームが表示されている間には、異なる挙動に対する時間基準のこの相違は、ゲームのプレイに影響しないが、再生されたゲームが異なる結果を生じさせることを招く。例えば、バスケットボールの弾道は、一定の60fps速度で計算されるが、ゲームコントローラの入力が、計算されたフレームの速度に基づいてサンプリングされる場合には、計算されたフレームの速度は、ゲームが記録されたときは53fpsであるが、ゲームが再生されるときは52fpsとなり、これは、バスケットボールがバスケットへ入ることが阻止されるかどうかに差を生じさせ、異なる結果を招くことになる。従って、ゲーム状態を使用してビデオゲームを記録するには、同じゲーム状態情報を使用した再生が全く同じ結果を生じさせるよう保証するために非常に入念なゲームソフトウェア設計が要求される。
ビデオゲームを記録するための別の従来の解決策は、PC又はビデオゲームシステムのビデオ出力を(例えば、VCR、DVDレコーダへ、又はPC上のビデオ捕獲ボードへ)単に記録することである。次いで、ビデオは、巻き戻して再生することもできるし、或いは記録されたビデオを、典型的に、圧縮した後にインターネットへアップロードすることもできる。この解決策の欠点は、3Dゲームシーケンスが再生されるときに、ユーザは、シーケンスが記録された視点のみからシーケンスを見ることに限定されることである。換言すれば、ユーザは、シーンの視点を変更することができない。
更に、家庭用PC又はゲームコンソールで再生される記録されたゲームシーケンスの圧縮ビデオがインターネットを通して他のユーザに利用されるときには、ビデオがリアルタイムで圧縮された場合でも、その圧縮されたビデオをリアルタイムでインターネットにアップロードすることは不可能である。その理由は、インターネットに接続された世界中の多数の家庭が、極めて非対称的なブロードバンド接続を有する(例えば、DSL及びケーブルモデムは、典型的に、アップストリーム帯域巾よりも遥かに広いダウンストリーム帯域巾を有する)からである。圧縮された高解像度ビデオシーケンスは、多くの場合に、ネットワークのアップストリーム帯域巾容量より広い帯域巾を有し、それらをリアルタイムでアップロードするのを不可能にする。従って、ゲームシーケンスが再生された後、インターネットの別のユーザがゲームを見ることができるまでに著しい遅延が生じる(おそらく数分又は数時間)。この遅延は、ある状況(例えば、以前に生じたゲームプレーヤの成績を見る)では許容できるが、ゲーム(例えば、チャンピオンプレーヤによりプレイされるバスケットボールトーナメント)を生で見る能力、又はゲームが生でプレイされるときの「瞬時再生」能力を排除する。
別の従来の解決策は、テレビジョン制作員の管理下でのみ、視聴者が、テレビ受像機でビデオゲームを生で見ることができるようにする。米国及び他の国々における幾つかのチャンネルは、ビデオゲーム視聴チャンネルを提供し、テレビ視聴者は、ビデオゲームチャンネル上で何人かのビデオゲームユーザ(例えば、トーナメントでプレイする最高評価プレーヤ)を見ることができる。これは、テレビジョンチャンネル用のビデオ配信及び処理装置へビデオゲームシステム(PC及び/又はコンソール)のビデオ出力をフィードすることにより達成される。これは、多数のカメラがバスケットボールコートの周囲で異なるアングルから生映像を送る生のバスケットボールゲームをテレビチャンネルが放送するときとは異なる。従って、テレビチャンネルは、それらのビデオ/オーディオ処理を活用して、種々のビデオゲームシステムからの出力を操作するように装置に作用することができる。例えば、テレビチャンネルは、異なるプレーヤの状態を示すテキストをビデオゲームからのビデオの上に重畳することができ(生のバスケットボールゲーム中のオーバーレイテキストであるかのように)、そしてテレビチャンネルは、ゲーム中に生じるアクションについて論じることのできるコメンテータからの音声をかぶせて録音することができる。更に、ビデオゲーム出力を、ゲームの実際のプレーヤのビデオを記録するカメラと合成することができる(例えば、ゲームに対する感情的応答を示す)。
この解決策に伴う1つの問題は、生放送の興奮を得るために、このような生のビデオフィードがテレビチャンネルのビデオ配信及び処理装置にリアルタイムで得られねばならないことである。しかしながら、上述したように、これは、ビデオゲームシステムが家庭から実行されるとき、特に、放送の一部分が、ゲームプレーヤの実世界ビデオを捕獲するカメラからの生ビデオを含む場合には、しばしば不可能である。更に、トーナメント状態において、上述したように、家庭内のゲーム遊技者がゲームを変更し及びチートする問題もある。これらの理由で、テレビチャンネルを経てのこのようなビデオゲーム放送は、プレーヤ及びビデオゲームシステムが共通の位置(例えば、テレビスタジオ又は競技場)に集合し、そこで、テレビ制作装置が多数のビデオゲームシステム及び潜在的な生カメラからのビデオフィードを受け容れることができるように、しばしば構成される。
このような従来のビデオゲームテレビチャンネルは、ビデオゲームの世界におけるアクション及び実世界におけるアクションの両方に関して、例えば、ビデオゲームプレーヤが「アスリート」として描かれるようにして、生のスポーツイベントに類似した体験である非常に興奮させる上映をテレビの視聴者に与えることができるが、これらのビデオゲームシステムは、プレーヤが互いに物理的に非常に接近した状態にしばしば限定される。そして、テレビチャンネルが放送されて以来、各放送チャンネルは、テレビチャンネルの制作員により選択された1つのビデオストリームしか示すことができない。これらの制限や、放送時間、制作装置及び制作員の高いコストのために、テレビチャンネルは、典型的に、トップトーナメントでプレイする最高評価プレーヤしか示さない。
更に、ビデオゲームのフルスクリーン映像を全テレビ視聴者に放送する所与のテレビチャンネルは、一度に1つのビデオゲームしか示さない。これは、テレビ視聴者の選択肢を甚だしく制限する。例えば、テレビ視聴者は、所与の時間に映されるゲームに関心がないことがある。別の視聴者は、所与の時間にテレビチャンネルによって特集されない特定のプレーヤのゲームプレイを見ることにしか関心がない。他のケースでは、視聴者は、専門プレーヤがゲームにおける特定のレベルをどのように取り扱うか見ることにしか関心がない。更に他の視聴者は、制作チーム等により選択されたものとは異なる、ビデオゲームを見る視点をコントロールすることを希望する。手短に言えば、テレビ視聴者は、多数の異なるテレビチャンネルが見られる場合でも、テレビネットワークの特定の放送によって受け容れられないビデオゲームを見ることに無数の好みをもっている。上述した全ての理由で、従来のビデオゲームテレビチャンネルは、テレビ視聴者にビデオゲームを示す上で著しい制限がある。
従来のビデオゲームシステム及びアプリケーションソフトウェアシステムの別の欠点は、それらが複雑であり、且つエラー、クラッシュ及び/又は意図されない及び望ましからぬ挙動(集合的に「バグ」)により通常悩まされていることである。ゲーム及びアプリケーションは、典型的に、発売までにデバッグ及びチューニングプロセス(しばしば「ソフトウェアクオリティアシュアランス」又はSQAと称される)に通されるが、ほぼ常に、ゲーム又はアプリケーションがその分野の広範囲な視聴者に発売されると、バグが突然現れる。不都合なことに、ソフトウェア開発者は、発売後に多くのバグを識別して追跡することは困難である。ソフトウェア開発者がバグに気付くことは困難である。バグについて学習したときでも、何がバグを生じさせたか識別するために利用できる情報は、限られた量しかない。例えば、ユーザは、ゲーム開発者の顧客サービスラインに電話し、ゲームをプレイするときに、スクリーンがフラッシュを開始し、次いで、濃い青色に変化し、PCがフリーズすることを示すメッセージを残す。これは、SQAチームに、バグを追跡するのに有用な非常に僅かな情報しか与えない。オンライン接続されたあるゲーム又はアプリケーションは、時々、幾つかのケースでは、多くの情報を与えることができる。例えば、ゲーム又はアプリケーションを「クラッシュ」について監視するために、時々「ウオッチドッグ」プロセスを使用することができる。ウオッチドッグプロセスは、ゲーム又はアプリケーションプロセスがクラッシュしたときにその状態(例えば、スタックの状態、メモリ使用状態、ゲーム又はアプリケーションがどれほど進行したか、等)に関する統計情報を収集し、次いで、その情報を、インターネットを経てSQAチームへアップロードすることができる。しかし、複雑なゲーム又はアプリケーションでは、このような情報は、クラッシュ時にユーザが何を行ったか正確に決定するために解読するのに非常に長時間を要する。従って、どんな事象シーケンスがクラッシュを招いたか決定することが不可能である。
PC及びゲームコンソールに関連した更に別の問題は、消費者に相当不便をかけるサービスの問題を受けることである。又、これらサービスの問題は、PC又はゲームコンソールの製造者に影響を及ぼす。というのは、製造者は、壊れたPC又はコンソールを安全に運搬するために特殊なボックスを送付し、PC又はコンソールが保証期間内である場合には修理のコストを負う必要があるからである。又、ゲーム又はアプリケーションソフトウェアの発行者は、PC及び/又はコンソールが修理の状態にあることによる販売の損失(又はオンラインサービス使用)によっても影響を受ける。
図1は、Sony Playstation(登録商標)3、Microsoft XBox 360(登録商標)、Nintendo WiiTM、Windowベースのパーソナルコンピュータ、又はApple Macintoshのような従来のビデオゲームシステムを示す。これらシステムは、各々、プログラムコードを実行するための中央処理ユニット(CPU)、典型的に、進歩型グラフィックオペレーションを遂行するためのグラフィック処理ユニット(GPU)、並びに外部装置及びユーザと通信するための複数の形態の入力/出力(I/O)を備えている。簡単化のために、これらのコンポーネントは、単一のユニット100として一緒に結合されて示されている。又、図1の従来のビデオゲームシステムは、光学的メディアドライブ104(例えば、DVD−ROMドライブ)、ビデオゲームのプログラムコード及びデータを記憶するためのハードドライブ103、マルチプレーヤゲームをプレイし、ゲーム、パッチ、デモ又は他のメディアをダウンロードするためのネットワーク接続105、CPU/GPU100により現在実行されているプログラムコードを記憶するためのランダムアクセスメモリ(RAM)101、ゲームプレイ中にユーザからの入力コマンドを受け取るためのゲームコントローラ106、及びディスプレイ装置102(例えば、SDTV/HDTV又はコンピュータモニタ)を含むように示されている。
図1に示す従来のシステムは、多数の制限で悩まされている。第1に、光学的ドライブ104及びハードドライブ103は、RAM101に比して非常に低速のアクセス速度を有する傾向がある。RAM101を通して直接機能するときには、CPU/GPU100は、実際に、プログラムコード及びデータがハードドライブ103又は光学ドライブ104から直接読み取られるときに可能であるより遥かに多くの多角形を毎秒処理することができる。というのは、RAM101は、一般的に、帯域巾が非常に広く、ディスクメカニズムの比較的長いシーク遅延で悩まされないからである。しかし、これら従来システムでは、限定された量のRAMしか設けられていない(例えば、256−512Mバイト)。それ故、ビデオゲームの次のシーケンスのためのデータでRAM101が周期的に埋められる“Loading...”シーケンスがしばしば要求される。
あるシステムは、ゲームプレイと同時にプログラムコードのローディングを重畳させるように試みているが、これは、既知の事象シーケンスがあるときしか行うことができない(例えば、車を運転して道路を下る場合に、車を運転しながら、路傍にある接近してくるビルの幾何学形状をロードすることができる)。複雑で及び/又は急速なシーンの変化については、この形式の重畳は、通常、機能しない。例えば、ユーザが戦いの最中であり、そしてその瞬間に視野内のオブジェクトを表すデータでRAM101が完全に埋められるケースでは、RAM101に現在ロードされていないオブジェクトを見るためにユーザが視野を素早く左へ動かした場合に、アクションの不連続状態が生じる。というのは、ハードドライブ103又は光学的メディア104から新たなオブジェクトをRAM101へロードするに充分な時間がないからである。
図1のシステムでは、ハードドライブ103及び光学的メディア104の記憶容量に制限があるために別の問題が生じる。比較的大きな記憶容量(例えば、50ギガバイト以上)をもつディスク記憶装置を製造することはできるが、現在ビデオゲームで遭遇する幾つかのシーンについて充分な記憶容量をまだ与えることができない。例えば、上述したように、サッカーのビデオゲームは、世界中の多数のチーム、プレーヤ及びスタジアムの中からユーザが選択を行えるようにする。各チーム、各プレーヤ及び各スタジアムに対して、世界中の3D曲面を特徴付けるには非常に多数のテクスチャマップ及び環境マップが要求される(例えば、各チームが独特のジャージを有し、その各々が独特のテクスチャマップを要求する)。
この後者の問題に対処するために使用される1つの技術は、ユーザによってテクスチャ及び環境マップが選択されたときにゲームがそれらを予め計算することである。これは、映像の解凍、3Dマッピング、シェーディング、データ構造の編成、等を含めて、多数の計算上強いプロセスを含むことがある。その結果、ビデオゲームがこれらの計算を遂行する間にユーザにとって遅延が生じ得る。この遅延を減少するための1つの方法は、原理的に、ゲームが最初に開発されたときに、チーム、プレーヤ名簿及びスタジアムの各順列を含めて、これら計算の全てを遂行することである。従って、ゲームの発売バージョンは、光学的メディア104、又はインターネット上の1つ以上のサーバーに記憶された全てのこの前処理されたデータを、ユーザが選択を行うときにインターネットを通してハードドライブ103へダウンロードされる所与のチーム、プレーヤ名簿、スタジアム選択のための選択された前処理されたデータと共に含む。しかしながら、実際上の問題として、ゲームプレイにおいて考えられる各順列のこのような予めロードされるデータは、多分、今日の光学的メディア装置の容量を遥かに越えるテラバイトのデータになってしまう。更に、所与のチーム、プレーヤ名簿、スタジアム選択のためのデータは、多分、数百メガバイト以上のデータになってしまう。例えば、10Mbpsの家庭用ネットワーク接続では、ネットワーク接続105を通してこのデータをダウンロードするのに、データをローカルで計算する以上の時間を要することになる。
従って、図1に示す従来のゲームアーキテクチャーは、複雑なゲームの主要シーン移行間にユーザに著しい遅延を受けさせる。
図1に示す従来の解決策に伴う別の問題は、年々、ビデオゲームがより進歩する傾向にあり、より高いCPU/GPUパワーを要求することである。従って、限定された量のRAMを仮定しても、ビデオゲームハードウェアの要件は、これらシステムに得られる処理パワーのピークレベルを越えてしまう。その結果、ユーザは、歩調を合わせるためにゲームハードウェアを数年毎にアップグレードする必要がある(又は新たなゲームを質の低いレベルでプレイする)。ビデオゲームが絶えず進歩する傾向の1つの結果として、家庭で使用するためのビデオゲームプレイマシンは、典型的に、それらのコストが、通常、サポートできる最高性能ゲームの要件により決定されるので、経済的に効率が悪い。例えば、XBox 360は、高性能CPU、GPU、及び数百メガバイトのRAMを必要とする“Gears of War”のようなゲームをプレイするのに使用されるか、又はXBox 360は、数キロバイトのRAM及び非常に低性能のCPUしか要求しない1970年代のゲームであるPac Manをプレイするのに使用される。実際に、XBox 360は、Pac Manゲームを一度に多数同時にホストするに充分な計算パワーを有している。
ビデオゲームマシンは、典型的に、一週間のほとんどの時間中オフにされている。13年以上経った現役ゲームに関するニールセン・エンターテーメント・スタディ2006年7月号によれば、平均で、現役のゲームは、毎週14時間をコンソールビデオゲームのプレイに費やしており、即ち一週間の合計時間の12%に過ぎない。これは、平均でビデオゲームコンソールが88%の時間アイドル状態であり、高価なリソースの使用効率が悪いことを意味する。購入価格を下げるためにビデオゲームコンソールが製造者によりしばしば助成されると仮定すれば(その助成金が将来のビデオゲームソフトウェアの購入からのロイヤリティにより還元されることを期待して)、これは、特に意義深いことである。
又、ビデオゲームコンソールは、ほとんどの消費者電子装置に関連したコストを負っている。例えば、システムの電子装置及びメカニズムは、エンクロージャ内に収容する必要がある。製造者は、修理保証を提供する必要がある。システムを販売する小売店は、システムの販売及び/又はビデオゲームソフトウェアの販売において利ざやを収集する必要がある。これらのファクタは、全てビデオゲームコンソールのコストに追加され、これは、製造者によって助成されねばならないか、消費者へ回されるか、又はその両方である。
更に、ビデオゲーム産業にとって海賊版が主たる問題である。実質上全ての主要ビデオゲームシステムに使用されるセキュリティメカニズムは、年々「クラック」されて、ビデオゲームの無断コピーが取られている。例えば、XBox 360のセキュリティシステムは、2006年7月にクラックされ、ユーザは、今や、不正コピーをオンラインでダウンロードすることができる。ダウンロード可能なゲーム(例えば、PC又はMac用のゲーム)は、特に海賊行為を受け易い。海賊行為の取り締まりが弱い世界のある地域では、スタンドアローンビデオゲームソフトウェアのための成功が見込める市場が本質的にない。というのは、ユーザが海賊版コピーを合法的コピーと同程度に容易にそのコストのほんの一部分で買えるからである。又、世界の多くの地域では、ゲームコンソールのコストが収入の高い割合であり、海賊版を取り締まっても、最新のゲームシステムを買う余裕がある人は僅かに過ぎない。
更に、中古ゲーム市場は、ビデオゲーム産業の収入を減少させる。ユーザは、ゲームに飽きると、ゲームを店に売ることができ、店は、ゲームを他のユーザに再販売する。この無許可であるが一般的な慣習は、ゲーム発行者の収入を著しく減少させる。同様に、数年毎にプラットホームの移行があるときには、通常、50%の販売量低下が生じる。これは、ユーザが、新規バージョンプラットホームが発売されようとしていることを知ると、旧型プラットホーム用のゲームの購入を止める(例えば、Playstation3が発売されようとしているときに、ユーザは、Playstation2のゲームの購入を止める)からである。新規のプラットホームに関連した販売の損失及び開発コストの増加が相まって、ゲーム開発者の利益に非常に大きな影響が及ぶことになる。
又、新規なゲームコンソールは、非常に高価である。XBox 360、Nintendo Wii、及びSony Playstation3は、全て、数百ドルで小売される。ハイパワーのパーソナルコンピュータゲームシステムは、その価格が$8000までである。これは、特に、ハードウェアが数年後に旧式となり且つ多くのシステムが子供のために購入されることを考えると、ユーザにとって著しい投資を表す。
以上の問題に対する1つの解決策は、ゲームプログラムコード及びデータがサーバーにホストされそしてオンデマンドでクライアントマシンへデジタルブロードバンドネットワークを経てストリーミングされる圧縮されたビデオ及びオーディオとして配信されるオンラインゲームである。フィンランドのG−Cluster(現在では、日本のソフトバンクブロードメディアの子会社)のような幾つかの会社は、これらのサービスをオンラインで提供する。同様のゲームサービスが、ホテル内にあるようなローカルネットワークにおいて利用でき、DSL及びケーブルテレビジョンプロバイダーによって提供されている。これらシステムの主たる欠点は、待ち時間(latency)、即ちオペレータの「ヘッドエンド」に典型的に配置されたゲームサーバーへ信号が進み且つそこから進むのに要する時間の問題である。高速アクションビデオゲーム(「ツイッチ」ビデオゲームとしても知られている)は、ユーザがゲームコントローラでアクションを遂行する時間と、ディスプレイスクリーンが更新されてユーザアクションの結果を示す時間との間に非常に短い待ち時間を要求する。ゲームが「即座」に応答するという感覚をユーザがもつようにするため、短い待ち時間が必要とされる。ユーザは、ゲームの形式及びユーザの熟練度レベルに基づいて異なる待ち時間間隔で満足することができる。例えば、ゆっくりしたカジュアルなゲーム(バックギャモンのような)又は低速アクションの役割を演じるゲームについては100msの待ち時間が許容できるが、高速アクションゲームでは、待ち時間が70又は80msを越えると、ユーザは、ゲームにおいて演技が不充分となり、受け容れられない。例えば、高速反応時間を要求するゲームでは、待ち時間が50から100msへ増加するにつれて、精度が鋭く低下する。
ゲーム又はアプリケーションサーバーが、近傍のコントロールされたネットワーク環境にインストールされるか、又はユーザへのネットワーク経路が予想可能で及び/又は帯域巾ピークを許容できる環境にインストールされるときには、最大待ち時間と、待ち時間の一貫性の両方について、待ち時間をコントロールすることが遥かに容易である(例えば、ユーザがネットワークを通してストリーミングするデジタルビデオから一定の動きを観察するように)。このようなレベルのコントロールは、ケーブルTVネットワークのヘッドエンドとケーブルTV加入者の家庭との間、又はDSL中央オフィスからDSL加入者の家庭までの間、或いはサーバー又はユーザからの商業的オフィスのローカルエリアネットワーク(LAN)環境において、達成することができる。又、保証された帯域巾及び待ち時間を有する会社間に特殊グレードのポイント対ポイントプライベート接続を得ることができる。しかし、一般的なインターネットに接続されたサーバーセンターにおいてゲームをホストし、次いで、ブロードバンド接続を経てユーザへ圧縮ビデオをストリーミングするゲーム又はアプリケーションシステムでは、多数のファクタから待ち時間を招き、従来システムの展開に甚だしい制限を生じさせる。
典型的なブロードバンド接続の家庭では、ユーザは、ブロードバンドサービスのためにDSL又はケーブルモデムをもつことができる。このようなブロードバンドサービスは、通常、ユーザの家庭と一般的なインターネットとの間に25ms程度(時々はそれ以上の)の往復待ち時間を被る。更に、インターネットを経てサーバーセンターへデータをルーティングすることからも往復遅延を被る。インターネットを通しての待ち時間は、データが与えられるルート及びそれがルーティングされるときに被る遅延に基づいて変化する。ルーティング遅延に加えて、ほとんどのインターネットを相互接続する光ファイバを経て進む光の速度のために、往復遅延も被る。例えば、1000マイルごとに、光ファイバを通る光の速度及び他のオーバーヘッドのために、約22msの往復待ち時間を被る。
インターネットを経てストリーミングされるデータのデータレートのために、付加的な待ち時間が生じる。例えば、ユーザが「6Mbps DSLサービス」として販売されるDSLサービスを有する場合に、実際に、ユーザは、おそらく、せいぜい5Mbps未満のダウンストリームスループットしか得ず、そしておそらく、デジタルサブスクライバーラインアクセスマルチプレクサ(DSLAM)におけるピークロード時間中の混雑のような種々のファクタのために、接続の質低下を周期的に見ることになる。又、ケーブルモデムシステムネットワークにおける隣接部又は他のどこかを経てループされるローカル共有同軸ケーブルに混雑が生じる場合には、「6Mbpsケーブルモデムサービス」として販売される接続に使用されるケーブルモデムのデータレートを遥かに低く減少する同様の問題が発生する。4Mbpsの一定レートでのデータパケットがサーバーセンターからこのような接続を経てユーザデータグラムプロトコル(UDP)フォーマットで一方向としてストリーミングされる場合には、全てがうまく機能すれば、データパケットが、付加的な待ち時間を被ることなく通過するが、混雑(又は他の障害)が存在し且つユーザへデータをストリーミングするのに3.5Mbpsしか利用できない場合には、典型的な状態において、パケットがドロップされてデータロスを生じるか、又はパケットを送ることができるまで混雑点にパケットがキューイングされて付加的な待ち時間を招くか、のいずれかである。異なる混雑点は、遅延パケットを保持する異なるキューイング容量を有し、従って、あるケースでは、混雑を通過できないパケットが直ちにドロップされる。他のケースでは、数メガビットのデータがキューイングされ、最終的に、送出される。しかし、ほぼ全てのケースにおいて、混雑点におけるキューは、容量限界があり、これらの限界を越えると、キューがオーバーフローし、パケットがドロップされる。従って、付加的な待ち時間(又は更に悪い場合は、パケットのロス)を被るのを回避するために、ゲーム又はアプリケーションサーバーからユーザへのデータレート容量を越えないようにする必要がある。
又、サーバーにおいてビデオを圧縮しそしてクライアント装置においてビデオを解凍するのに要求される時間によっても待ち時間を被る。更に、サーバー上で実行されているビデオゲームが、表示されるべき次のフレームを計算する間にも待ち時間を被る。現在入手できるビデオ圧縮アルゴリズムは、高いデータレート又は長い待ち時間のいずれかで悩まされている。例えば、モーションJPEGは、待ち時間が短いことを特徴とするイントラフレーム専用ロッシー(intra frame-only lossy)圧縮アルゴリズムである。各ビデオフレームは、互いのビデオフレームと独立して圧縮される。クライアント装置は、圧縮されたモーションJPEGビデオのフレームを受け取ると、そのフレームを直ちに解凍して表示し、待ち時間を非常に短くする。しかし、各フレームは、別々に圧縮されるので、アルゴリズムは、連続するフレーム間の類似性を利用することができず、その結果、イントラフレーム専用ビデオ圧縮アルゴリズムは、非常に高いデータレートで悩まされている。例えば、60fps(フレーム/秒)640x480モーションJPEGビデオは、40Mbps(メガビット/秒)以上のデータを要求する。このように低い解像度のビデオウインドウに対するこのように高いデータレートは、多くのブロードバンドアプリケーションにおいて(及び確実にほとんどの消費者インターネットベースのアプリケーションに対して)法外に高価なものとなる。更に、各フレームは独立して圧縮されるので、ロッシー圧縮から生じ得るフレーム内の欠陥は、おそらく、連続するフレームの異なる場所に現れる。これは、ビデオが解凍されたときに、動く視覚上の欠陥として視聴者に見える。
マイクロソフト社からのMPEG2、H.264、又はVC9のような他の圧縮アルゴリズムは、従来の構成で使用されたときに、高い圧縮比を達成できるが、長い待ち時間が犠牲となる。このようなアルゴリズムは、インターフレーム及びイントラフレームの圧縮を使用する。周期的に、このようなアルゴリズムは、フレームのイントラフレーム専用圧縮を遂行する。このようなフレームは、キーフレーム(典型的に“I”フレームと称される)として知られている。次いで、これらのアルゴリズムは、典型的に、Iフレームを手前のフレーム及び連続するフレームの両方と比較する。手前のフレーム及び連続するフレームを独立して圧縮するのではなく、このアルゴリズムは、Iフレームから手前のフレーム及び連続するフレームへと映像の何が変化したか決定し、次いで、それらの変化を、Iフレームに先行する変化については“B”フレームとして、及びIフレームに続く変化については“P”フレームとして記憶する。これは、イントラフレーム専用圧縮よりも非常にゆっくりしたデータレートを生じさせる。しかし、これは、典型的に、長い待ち時間を犠牲とする。Iフレームは、典型的に、B又はPフレームより非常に大きく(しばしば10倍以上)、その結果、所与のデータレートで送信するのに比例的に長い時間を要する。
例えば、Iフレームが、B及びPフレームのサイズの10倍であり、単一のIイントラフレームごとに29個のBフレーム+30個のPフレーム=59個のインターフレームがあるか、又は「フレームグループ(GOP)」ごとに合計60個のフレームがある状態を考える。従って、60fpsでは、毎秒1つの60フレームGOPがある。送信チャンネルが2Mbpsの最大データレートを有すると仮定する。チャンネルに最高クオリティのビデオを得るために、圧縮アルゴリズムは、2Mbpsのデータストリームを発生し、上述した比を仮定すれば、これは、2メガビット(Mb)/(59+10)=30,394ビット/イントラフレーム及び303,935ビット/Iフレームを生じさせる。圧縮されたビデオストリームが解凍アルゴリズムによって受信されるときには、ビデオを着実にプレイするために、各フレームを規則的な間隔(例えば、60fps)で解凍して表示する必要がある。この結果を得るために、フレームが送信待ち時間を受ける場合には、全てのフレームを少なくともその待ち時間だけ遅延する必要があり、従って、最悪のケースのフレーム待ち時間は、各ビデオフレームに対する待ち時間を定義する。Iフレームは、最も大きなものであるから、最長の送信待ち時間を導入し、Iフレームを解凍して表示できるまでにIフレーム全体を受信しなければならない(又はインターフレームがIフレームに依存する)。チャンネルデータレートが2Mbpsであると仮定すれば、Iフレームを送信するのに、303,935/2Mb=145msを要することになる。
送信チャンネルの帯域巾の大部分を使用する上述したインターフレームビデオ圧縮システムは、フレームの平均サイズに対してIフレームのサイズが大きいために長い待ち時間を受けることになる。又は、換言すれば、従来のインターフレーム圧縮アルゴリズムは、イントラフレーム専用圧縮アルゴリズムより低いフレーム当たり平均データレートを達成するが(例えば、2Mbps対40Mbps)、大きなIフレームのために、依然、高いフレーム当たりピークデータレートで悩まされている(例えば、303,935*60=18.2Mbps)。前記分析は、P及びBの両フレームがIフレームより非常に小さいと仮定していることを銘記されたい。これは、一般的には、真であるが、高い映像複雑さが手前のフレーム、高モーション又はシーンの変化に相関していないフレームについては真ではない。このような状態では、P又はBフレームがIフレームと同程度の大きさになる(P又はBフレームがIフレームより大きくなると、精巧な圧縮アルゴリズムが、典型的に、Iフレームを「強制(force)」し、そしてP又はBフレームをIフレームに置き換える)。従って、デジタルビデオストリームには、いつでも、Iフレームサイズのデータレートピークが生じる。従って、圧縮されたビデオでは、平均ビデオデータレートが送信チャンネルのデータレート容量に接近するときに(ビデオに対する高いデータレート要求を仮定すると、しばしばそうである)、Iフレーム或いは大きなP又はBフレームからの高いピークデータレートが長いフレーム待ち時間を生じさせる。
もちろん、以上の説明は、GOPにおける大きなB、P又はIフレームによって生じる圧縮アルゴリズムの待ち時間を特徴付けるに過ぎない。Bフレームが使用される場合は、待ち時間がより長くなる。その理由は、Bフレームを表示できるまでに、Bフレーム及びIフレーム後の全てのBフレームを受信しなければならないからである。従って、各Iフレームの前に5個のBフレームがあるBBBBBIPPPPPBBBBBIPPPPPのような画像グループ(GOP)シーケンスにおいて、最初のBフレームは、その後のBフレーム及びIフレームが受信されるまでビデオデコンプレッサによって表示することができない。従って、ビデオが60fps(即ち、16.67ms/フレーム)でストリーミングされる場合には、最初のBフレームを解凍できるまでに、チャンネル帯域巾がどれほど速くても、5個のBフレーム及びIフレームは、受信するのに16.67*6=100msを要し、これは、ちょうど、5個のBフレームである。30個のBフレームをもつ圧縮されたビデオシーケンスは、極めて一般的である。そして、2Mbpsのような低いチャンネル帯域巾では、Iフレームのサイズにより生じる待ち時間の影響が、主として、Bフレームが到着するのを待機することによる待ち時間の影響に加えられる。従って、2Mbpsチャンネルにおいて、非常に多数のBフレームがある状態では、従来のビデオ圧縮技術を使用して、500ms以上の待ち時間を越えるのは極めて容易である。Bフレームが使用されない(所与のクオリティレベルに対して低い圧縮比を犠牲にして)場合には、Bフレームの待ち時間を被らないが、上述したピークフレームサイズにより生じる待ち時間は、依然、被る。
この問題は、まさに多数のビデオゲームの性質により激化される。上述したGOP構造を使用するビデオ圧縮アルゴリズムは、主として、受動的な視聴に意図された生のビデオ又は動画資料で、使用上最適化されている。典型的に、カメラ(実際のカメラであるか、コンピュータ発生アニメーションの場合のバーチャルカメラであるかに関わらず)、及びシーンは、比較的安定である。というのは、単に、カメラ又はシーンがあまりに急に動く場合に、ビデオ又は映画資料が、(a)典型的に見るのに不快であり、そして(b)それを見る場合に、カメラが突然グイと動くときに、通常、視聴者がアクションを厳密に追従できないからである(例えば、バースディケーキのキャンドルに息を吹きかける子供を撮影するときにカメラがバンプされ、そして突然ケーキから離れて戻るようにグイと動かされる場合に、視聴者は、典型的に、子供及びケーキに集中し、カメラが突然動くときの短い中断は無視する)。ビデオのインタビュー又はビデオ遠隔会議のケースでは、カメラを固定位置に保持して、全く動かさず、非常に僅かなデータピークしか生じさせない。しかし、3D高アクションビデオゲームは、一定の動きにより特徴付けられる(例えば、レースの期間中に全フレームが迅速な動きにあるような3Dレースを考えるか、又はバーチャルカメラが常にグイと動くようなファーストパーソンシューター(first-person shooter)を考える)。このようなビデオゲームは、これらの突然の動きの間に何が起きたかユーザがはっきり見る必要があるところの大きなそして頻繁なピークを伴うフレームシーケンスを生じさせる。従って、3D高アクションビデオゲームでは、圧縮欠陥は、ほとんど許容できない。従って、多くのビデオゲームのビデオ出力は、それらの性質により、非常に高く且つ頻繁なピークをもつ圧縮ビデオストリームを発生する。
高速アクションビデオゲームのユーザが長い待ち時間に対してあまり寛容度がないと仮定し、又、上述した全ての待ち時間の原因を仮定すれば、今日まで、インターネットを経てビデオをストリーミングするサーバーホスト型ビデオゲームには制限があった。更に、高度の双方向性を要求するアプリケーションのユーザは、そのアプリケーションが一般的なインターネット及びストリームビデオでホストされる場合には、同様に制限で悩まされている。このようなサービスは、ホスティングサーバーが、商業的な設定において、ヘッドエンド(ケーブルブロードバンドの場合)、又は中央オフィス(デジタルサブスクライバーライン(DSL)の場合)、或いはLAN(又は特殊グレードのプライベート接続)内に直接設定されて、クライアント装置からサーバーへのルート及び距離が待ち時間を最小にするように制御され、且つ待ち時間を被ることなくピークを受け容れできるようなネットワークコンフィギュレーションを要求する。LAN(典型的に100Mbpsから1Gbps定格)及び充分な帯域巾の賃貸ラインは、典型的に、ピーク帯域巾要求をサポートすることができる(例えば、18Mbpsのピーク帯域巾は、100MbpsのLAN容量の小部分である)。
又、ピーク帯域巾要求は、特殊な受け容れがなされる場合には、住居用ブロードバンドインフラストラクチャーにより受け容れることができる。例えば、ケーブルTVシステムでは、デジタルビデオトラフィックに、大きなIフレームのようなピークを取り扱うことのできる専用帯域巾が与えられる。そしてDSLシステムでは、高速DSLモデムを準備して、高いピークを許すことができるか、又は高いデータレートを取り扱うことのできる特殊グレードの接続を準備することができる。しかし、一般的なインターネットに取り付けられる従来のケーブルモデム及びDSLインフラストラクチャーは、圧縮ビデオのピーク帯域要件に対して遥かに低い寛容度しか有していない。従って、クライアント装置から長距離にあるサーバーセンターにおいてビデオゲーム又はアプリケーションをホストし、次いで、インターネットを経て従来の住居用ブロードバンド接続を通して圧縮ビデオ出力をストリーミングするオンラインサービスは、特に、非常に短い待ち時間を要求するゲーム及びアプリケーション(例えば、ファーストパーソンシューター及び他のマルチユーザ双方向アクションゲーム、又は高速応答時間を要求するアプリケーション)に関して、顕著な待ち時間及びピーク帯域巾制限で悩まされている。
本開示は、添付図面及び以下の詳細な説明から、より完全に理解されよう。しかしながら、ここに開示した要旨は、本発明を例示するものに過ぎず、ここに示す特定の実施形態に限定されるものではない。
以下の説明では、本開示を完全に理解するために、装置の形式、システムコンフィギュレーション、通信方法、等の特定の細部について述べる。しかしながら、当業者であれば、ここに述べる実施形態を具現化するのに、これらの特定の細部は必要ないことが明らかであろう。
図2a−bは、ビデオゲーム及びソフトウェアアプリケーションが、契約サービスのもとでインターネット206(或いは他のパブリック又はプライベートネットワーク)を経てユーザの家屋211(「ユーザの家屋」とは、ユーザが所在する場所を意味し、移動装置を使用する場合には屋外も含む)においてホスティングサービス210によりホストされそしてクライアント装置205によりアクセスされるような2つの実施形態の高レベルアーキテクチャーを示す。クライアント装置205は、内部又は外部ディスプレイ装置222を有していてインターネットにワイヤード又はワイヤレス接続されるMicrosoft Windows又はLinuxベースのPC又はApple社のMacintoshコンピュータのような汎用コンピュータでもよいし、又はビデオ及びオーディオをモニタ又はTV受像機222へ出力するセットトップボックス(インターネットにワイヤード又はワイヤレス接続される)のような専用クライアント装置でもよいし、或いはおそらくインターネットにワイヤレス接続される移動装置でもよい。
これらの装置は、いずれも、それ自身のユーザ入力装置(例えば、キーボード、ボタン、タッチスクリーン、トラックパッド又は慣性感知棒、ビデオ捕獲カメラ及び/又は運動追跡カメラ、等)を有してもよいし、又は有線又は無線で接続された外部入力装置221(例えば、キーボード、マウス、ゲームコントローラ、慣性感知棒、ビデオ捕獲カメラ、及び/又は運動追跡カメラ、等)を使用してもよい。以下に詳細に述べるように、ホスティングサービス210は、高パワーのCPU/GPU処理能力を伴うものを含めて、種々の性能レベルのサーバーを含む。ゲームのプレイ中、又はホスティングサービス210におけるアプリケーションの使用中に、家庭又はオフィス用のクライアント装置205は、ユーザからのキーボード及び/又はコントローラ入力を受け取り、次いで、インターネット206を通してホスティングサービス210へコントローラ入力を送信し、このホスティングサービス210は、それに応答してゲームプログラムを実行し、そしてゲーム又はアプリケーションソフトウェアのためのビデオ出力の連続フレーム(一連のビデオ映像)を発生する(例えば、ユーザがボタンを押して、スクリーン上のキャラクタを右へ移動するように指令する場合には、ゲームプログラムが、右へ移動するキャラクタを示す一連のビデオ映像を生成する)。この一連のビデオ映像は、次いで、短待ち時間のビデオコンプレッサを使用して圧縮され、次いで、ホスティングサービス210は、インターネット206を通して短待ち時間のビデオストリームを送信する。家庭又はオフィス用クライアント装置は、次いで、圧縮されたビデオストリームをデコードし、そしてモニタ又はTVにおいてその解凍されたビデオ映像をレンダリングする。その結果、クライアント装置205のコンピューティング及びグラフィックハードウェア要件が著しく緩和される。クライアント205は、キーボード/コントローラ入力をインターネット206へ転送し、そしてインターネット206から受け取った圧縮されたビデオストリームをデコードし解凍するための処理パワーを有するだけでよく、これは、実質上、パーソナルコンピュータが、今日、そのCPUにおいてソフトウケアで実行できることである(例えば、ほぼ2GHzで実行されるインテル社のCore Duo CPUは、H.264及びWindows Media VC9のようなコンプレッサを使用してエンコードされた720p HDTVを解凍することができる)。そして、クライアント装置のケースでは、専用のチップも、このような規格に対するビデオ解凍を、リアルタイムで、遥かに低いコストにおいて、且つ近代的な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)における所与のレベルのクオリティをある量のシーンの複雑さに対し所与の解像度(例えば、640x480@60fps)において維持するためにデータレート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は、ディスクレスであり、即ちそれ自身のローカル大量記憶装置(光学又は磁気記憶装置、或いは半導体ベースの記憶装置、例えば、フラッシュメモリ又は同様の機能を果たす他の大量記憶手段)を有するのではなく、各サーバーは、高速バックプレーン又はネットワーク接続を通して共有大量記憶装置にアクセスする。一実施形態では、この高速接続は、一連の独立ディスク冗長アレイ(RAID)405に接続された記憶エリアネットワーク(SAN)403であり、装置間の接続がギガビットイーサネット(登録商標)を使用して具現化される。当業者に明らかなように、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は、Samsung HL−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のMIPS R4000シリーズ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オーストラリアのオーシャンロジックオブマンリー(Ocean Logic of Manly)である。IPを使用する効果は、ここで使用する圧縮技術が圧縮規格に従わないことである。ある標準的なデコンプレッサは、ここに述べる圧縮技術を受け容れるように構成されるに充分なほど融通性があるが、あるものはそうではない。しかし、IPでは、デコンプレッサを必要に応じて設計し直す上で完全な融通性がある。
ビデオデコンプレッサの出力は、ビデオ出力サブシステム487に結合され、これは、ビデオをHDMIインターフェイス490のビデオ出力に結合する。
オーディオ解凍サブシステム488は、入手可能な標準的オーディオデコンプレッサを使用して具現化されるか、又はIPとして具現化することもでき、或いはオーディオの解凍は、例えば、Vorbisオーディオデコンプレッサを具現化できるコントロールプロセッサ483内で具現化することもできる。
オーディオの解凍を具現化する装置は、オーディオ出力サブシステム489へ結合され、これは、オーディオをHDMIインターフェイス490のオーディオ出力へ結合する。
図4fは、クライアント475の内部アーキテクチャーの一実施形態を示す。明らかなように、このアーキテクチャーは、付加的なインターフェイスと、壁に差し込む電源アダプタからの任意の外部DC電力を除き、クライアント465と同じであり、その外部DC電力は、そのように使用される場合、イーサネットPoE497から到来する電力に取って代わる。クライアント465と共通の機能は、以下に説明を繰り返さず、付加的な機能を以下に説明する。
CPU483は、付加的な装置と通信し、それを構成する。
WiFiサブシステム482は、そのアンテナを通してイーサネット497への代替物としてワイヤレスインターネットアクセスを与える。WiFiサブシステムは、カリフォルニア州サンタクララのアセロスコミュニケーションズ(Atheros Communications)を含めて幅広い製造者から入手できる。
USBサブシステム485は、ワイヤードUSB入力装置479に対してブルーツース通信の代替物を与える。USBサブシステムは、極めて標準的で、FPGA及びASICについて入手容易であり、且つビデオ解凍と同様に、他の機能を遂行する既製装置にしばしば内蔵される。
ビデオ出力サブシステム487は、クライアント465内よりも広範囲なビデオ出力を発生する。これは、HDMI490ビデオ出力を与えるのに加えて、DVI−I491、S−ビデオ492及び複合ビデオ493を与える。又、DVI−I491インターフェイスがデジタルビデオに対して使用されるときには、ディスプレイ能力464がディスプレイ装置からコントロールCPU483へ返送され、ディスプレイ装置478の能力をホスティングサービス210に通知できるようにする。ビデオ出力サブシステム487により与えられる全てのインターフェイスは、極めて標準的なインターフェイスであり、多数の形態で入手容易である。
オーディオ出力サブシステム489は、デジタルインターフェイス494(S/PDIF及び/又はToslink)を通してオーディオをデジタルで出力すると共に、ステレオアナログインターフェイス495を通してオーディオをアナログ形態で出力する。
往復待ち時間の分析
もちろん、以上の段落を理解するために、入力装置421を使用したユーザのアクションと、そのアクションの結果をディスプレイ装置420で見るときとの間の往復待ち時間は、70−80ms以下でなければならない。この待ち時間は、ユーザの家屋211内の入力装置421からホスティングサービス210へそしてユーザの家屋211へ戻って、ディスプレイ装置422へ至る経路における全てのファクタを考慮しなければならない。図4bは、信号が進行しなければならない種々のコンポーネント及びネットワークを示し、これらコンポーネント及びネットワークの上には、実際の具現化で予想できる待ち時間を列挙した時間線がある。図4bは、重要な経路ルーティングだけを示すように簡略化されていることに注意されたい。システムの他の特徴のために使用されるデータの他のルーティングは、以下で説明する。双頭矢印(例えば、矢印453)は、往復待ち時間を表し、単頭矢印(例えば、矢印457)は、片道待ち時間を表し、そして「〜」は、近似尺度を示す。列挙した待ち時間を達成できない実世界の状況があるが、米国内における多くのケースでは、ユーザの家屋211へのDSL及びケーブルモデム接続を使用し、次の段落で述べる環境においてこれら待ち時間を達成できることを指摘しなければならない。又、インターネットへのセルラーワイヤレス接続は、図示されたシステムにおいて確実に機能するが、ほとんどの現在のUSセルラーデータシステム(EVDOのような)は、非常に長い待ち時間を被り、図4bに示す待ち時間を達成できないことにも注意されたい。しかしながら、これらの基礎的な原理は、このレベルの待ち時間を具現化できる将来のセルラー技術において具現化することができよう。
ユーザの家屋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)のための「存在点(point of presence)」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に示すシステムのユーザにより経験されると予想できる最悪のケースの往復待ち時間を決定することができる。それらは、1+1+25+22+1+16+6+8=80msである。そして、正に、実際に(以下に述べる注意と共に)、これは、図4aに示すシステムのプロートタイプバージョンを使用し、既製品のWindows PCをクライアント装置として及び米国内の家庭用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ビット/ピクセル=640*480*24/8/1024=900キロバイト/フレーム(KB/フレーム)のフレームレートを仮定すれば、モーションJPEGは、10のファクタでストリームを圧縮するだけであり、90KB/フレームのデータストリームを生じさせる。60フレーム/秒では、これは、90KB*8ビット*60フレーム/秒=42.2Mbpsのチャンネル帯域巾を要求し、これは、今日の米国内のほぼ全ての家庭用インターネット接続に対して遥かに広い帯域巾となり、且つ多数のオフィス用インターネット接続に対しても非常に広い帯域巾となる。実際に、このような広い帯域巾で一定のデータストリームを要求し、且つオフィスLAN環境においても1人のユーザにしか役立たないとすれば、100MbpsのイーサネットLAN帯域巾の大きな割合を消費し、LANをサポートするイーサネットスイッチに大きな負担を掛けることになる。従って、動画ビデオに対する圧縮は、(以下に述べるような)他の圧縮技術と比べたときに、非効率的である。更に、ロッシー圧縮アルゴリズムを使用するJPEG及びJPEG−2000のような単一フレーム圧縮アルゴリズムは、静止映像では気付かない圧縮欠陥(例えば、シーンにおける密集した葉の中の欠陥は、その密集した葉がどのように見えるべきか目にとって厳密に分からないので、欠陥として見えないことがある)を生じる。しかし、シーンが動くと、欠陥が静止映像では気付かないシーンのエリアにあるにも関わらず、欠陥がフレームごとに変化することが目で検出されるので、欠陥が目立つようになる。その結果、余白的アナログTV受信中に見える「スノー」ノイズに見掛けが類似した「バックグランドノイズ」がフレームのシーケンスにおいて知覚される。もちろん、この形式の圧縮は、ここに述べる幾つかの実施形態で依然使用できるが、一般的に述べると、シーンにおけるバックグランドノイズを回避するため、所与の知覚上のクオリティに対して高いデータレート(即ち、低い圧縮比)が要求される。
H.264、又はWindows MediaVC9、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組のパラメータで、平均データレートは、160Kb+16Kb*59=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秒巾の29+1=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が50%(1.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となる。最終の結果として、ほぼ10Kb+15*1Kb=25KbのRフレームとなる。従って、各60フレームシーケンスは、25Kb*60=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のみのサイズとなり、10Kb+15*0.75Kb=21.25Kbとなるか、又は60フレーム/秒では、データレートは、21.25Kb*60=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と共に「ジャム(jam)」することが単純に実行できないケースがある。定格最大データレート621(例えば、“6Mbps DSL”)は、インターネット接続の購入を考えるユーザにとって本質的にマーケッティングナンバーであるが、一般的に、性能のレベルを保証するものではない。本発明の説明上、これは、無関係である。というのは、ビデオが接続を通してストリーミングされるときには、利用可能な最大データレート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フレームとして圧縮フレーム1 981を発生する。圧縮フレーム1 981に対して発生されるデータは、上述したように、多数のファクタに基づいて大きくてもよいし小さくてもよい。データが、フレーム時間(1/60秒)内又はピークデータレート941未満でクライアント415へ送信できるに充分なほど小さい場合には、それが送信時間(xmit時間)991中に送信される(矢印の長さは、送信時間の巾を示す)。次のフレーム時間において、サーバー402は、非圧縮フレーム2 962を発生し、これは、圧縮フレーム2 982へと圧縮され、そしてピークデータレート941においてフレーム時間未満である送信時間992中にクライアント415へ送信される。
次いで、次のフレーム時間に、サーバー402は、非圧縮フレーム3 963を発生する。これがビデオコンプレッサ404により圧縮されると、それにより生じる圧縮フレーム3 983は、1フレーム時間にピークデータレート941で送信できる以上のデータとなる。従って、それは、全フレーム時間と次のフレーム時間の一部分とを取り上げた送信時間(2xピーク)993中に送信される。ここで、次のフレーム時間中に、サーバー402は、別の非圧縮フレーム4 964を発生し、それをビデオコンプレッサ404へ出力するが、データは、無視され、974で示されている。これは、ビデオコンプレッサ404が、手前の圧縮フレームをまだ送信している間に到着する更に別の非圧縮ビデオフレームを無視するように構成されているからである。もちろん、クライアント415のビデオデコンプレッサは、フレーム4を受信せず、2フレームの時間中、フレーム3をディスプレイ装置422に単に表示し続ける(即ち、フレームレートを60fpsから30fpsへ簡単に減少する)。
次のフレーム5に対して、サーバー402は、非圧縮フレーム5 965を出力し、これは、圧縮フレーム5 985へと圧縮され、そして送信時間995中の1フレーム以内に送信される。クライアント415のビデオデコンプレッサは、フレーム5を解凍し、ディスプレイ装置422に表示する。次いで、サーバー402は、非圧縮フレーム6 966を出力し、ビデオコンプレッサ404は、それを圧縮フレーム6 986へと圧縮するが、このときには、得られるデータが非常に長い。圧縮フレームは、送信時間(4xピーク)996中にピークデータレート941で送信されるが、フレームを送信するのに、ほぼ4フレームの時間を要する。次の3フレームの時間中に、ビデオコンプレッサ404は、サーバー402からの3フレームを無視し、そしてクライアント415のデコンプレッサは、フレーム6を4フレームの時間中にディスプレイ装置422に着実に保持する(即ち、フレームレートを60fpsから15fpsへ簡単に減少する)。次いで、最終的に、サーバー402は、フレーム10 970を出力し、ビデオコンプレッサ404は、それを圧縮フレーム10 987へ圧縮し、これは、送信時間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以上で動作するデュアルプロセッサ・クオドコアXeon CPUコンピュータシステムが使用され、各コアは、オープンソースx264 H.264コンプレッサを独立プロセスとして具現化する。しかしながら、これら基礎的な原理に依然合致しながら、種々の他のハードウェア/ソフトウェアコンフィギュレーションが使用されてもよい。例えば、CPUコアの各々を、FPGAで具現化されるH.264コンプレッサに置き換えることができる。図12に示す例では、コア1201−1208を使用して、Iタイル及びPタイルを8個の独立したスレッドとして同時に処理する。この技術で良く知られているように、現在のマルチコア及びマルチプロセッサコンピュータシステムは、本来、Microsoft Windows XPプロフェッショナルエディション(64ビット又は32ビットエディション)及びLinuxのようなマルチスレッドオペレーティングシステムと一体化されたときにマルチスレッディング可能である。
図12に示す実施形態では、8個のコアの各々は、1つのタイルについてのみ役立つので、x264の個別インスタンス生成を各々実行する他のコアとは主として独立して動作する。PCI Express x1ベースの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は、Intel 2.16GHzCore Duo CPUを使用してWindowsを実行するPCである。次いで、サーバー402は、新たなフレームを発生し、そしてそのDVI出力を通して、マザーボードベースのグラフィックシステムから、或いはNVIDIA8800GTX PCIエクスプレスカードの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上に応答を見る点からの合計往復待ち時間は、1+1+15+32+1+16+6+8=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が、AT&Tのサンフランシスコベースの中央オフィスへのルーティングではなく、サンフランシスコで提供されるAT&TのDSLサービスを利用してユーザから大量のトラフィックを受信した場合に、ホスティングサービス210は、サンフランシスコベースの中央オフィスと、ホスティングサービス210のための1つ以上のサービスセンターとの間のサービスプロバイダー(おそらくAT&Tそれ自体又は別のプロバイダー)から大容量のプライベートデータ接続をリースすることができる。次いで、全てのホスティングサービスサーバーセンターHS1ないしHS6から一般的なインターネットを経てAT&Tの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人のユーザのゲームから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を所与のゲームへ移動することにより達成される(黄色のボックスの移動は、キーボード上の矢印キーを使用するか、マウスを移動するか、ジョイスティックを動かすか、又は移動電話のような別の装置の方向ボタンを押すことにより達成できる)。単一のゲームが選択されると、そのゲームからのオーディオだけが再生される。又、ゲーム情報1602も示される。このゲームの場合には、例えば、発行者ロゴ(“EA”)及びゲームロゴ“Need for Speed Carbon”、及びオレンジの水平バーは、その特定の瞬間にゲームをプレイするか又は見ている人々の数を相対的な表現で指示する(この場合は、多数、従って、ゲームは、「ホット」)。更に、「スタッツ(Stats)」も設けられ、これは、145人のプレーヤがNeed for Speed Gameの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を考えると、非圧縮フレーム3 963がフレーム時間の半分早期に完成された場合に、送信時間992に影響を及ぼす)。このような状況では、共有ビデオ圧縮ハードウェア1530は、新たなサーバーからの第1のフレームを無視し(例えば、フレーム4 964が無視される(974)のと同様に)、クライアント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”能力を利用することができる。これは、以前の行動を再検討すること及び以下に述べる他のアプリケーションでも有用である。更に、カメラの視野を変更できる、等のように、ゲーム状態情報の利用に基づいて巻き戻することができるようにゲームが設計されている場合は、この“3D DVR”能力もサポートされるが、それをサポートするようにゲームを設計することが要求される。遅延バッファ1515を使用する“DVR”能力は、もちろん、ゲーム又はアプリケーションが使用されたときに発生するビデオに限定して、ゲーム又はアプリケーションと共に機能するが、3D DVR能力をもつゲームの場合には、ユーザは、以前にプレイしたセグメントの3Dにおける「フライスルー(fly through)」を制御することができ、そしてそれにより得られるビデオを遅延バッファ1515で記録させ、ゲームセグメントのゲーム状態を記録させることができる。従って、特定の「フライスルー」が、圧縮されたビデオとして記録されるが、ゲーム状態も記録されるので、後日、ゲームの同じセグメントについて異なるフライスルーが考えられることになる。
以下に述べるように、ホスティングサービス210におけるユーザは、各々、彼等に関する情報及び他のデータを掲示することのできる「ユーザページ」を有する。ユーザが掲示することのできるものの中には、彼等がセーブしたゲームプレイからのビデオセグメントがある。例えば、ユーザがゲームにおいて特に困難な挑戦を克服した場合には、ユーザは、ゲームにおいて偉大な成果をなし得た点の直前まで「巻き戻し」、次いで、他のユーザが見るために、ある時間巾(例えば、30秒)のビデオセグメントをユーザの「ユーザページ」にセーブするようにホスティングサービス210に命令することができる。これを達成するには、ユーザが、遅延バッファ1515に記憶されたビデオをRAIDアレイ1511−1512へ再生してユーザの「ユーザページ」においてそのビデオセグメントをインデックスするように使用するという、単なるapp/gameサーバー1521−1525の問題である。
ゲームが、上述した3D DVRの能力を有する場合には、3D DVRに要求されるゲーム状態情報もユーザによって記録して、ユーザの「ユーザページ」に利用することができる。
能動的なプレーヤに加えて「観客」(即ち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”をプレイしており、MrSnuggles99は、オフラインであり、等)。メニューアイテム(図示せず)をクリップすることにより、相棒のビデオクリップは、記録又はアップロードされたビデオを示すものから、ホスティングサービス210上で現在ゲームをプレイしている相棒がそのときゲームにおいて何をしているかの生のビデオへとスイッチする。従って、これは、相棒のためのゲームファインダーグループとなる。相棒のゲームが選択されそしてユーザがそれをクリックする場合には、全スクリーンをズームアップし、そしてユーザは、全スクリーンでプレイされるゲームを生で見ることができる。
この場合も、相棒のゲームを見ているユーザは、ゲームのコピーも、ゲームをプレイするためのローカルコンピューティング/ゲームコンソールリソースも、所有していない。ゲームを見るのは、実際上、瞬間的である。
上述したように、ユーザがホスティングサービス210においてゲームをプレイするときには、ユーザは、ゲームを「巻き戻し」、セーブしたいビデオセグメントを見出し、次いで、ビデオセグメントを自分の「ユーザページ」へセーブする。これらは、「自慢のクリップ(Brag Clips)」と称される。ビデオセグメント2003は、全て、プレイした以前のゲームからKILLHAZARDによりセーブされた「自慢のクリップ」2003である。番号2004は、「自慢のクリップ」が何回見られたかを示し、そして「自慢のクリップ」が見られるときに、ユーザは、それを格付けする機会を得、オレンジのキー穴形状のアイコン2005の数は、どれほど高い格付けであるかを示す。「自慢のクリップ」2003は、ユーザが「ユーザページ」を見るとき、そのページにおけるビデオの残りと共に絶えずループする。ユーザが「自慢のクリップ」2003の1つを選択してクリックする場合には、それがズームアップし、「自慢のクリップ」2003を、クリップの再生、休止、巻き戻し、早送り、ステップスルー、等を行えるようにするDVRコントロールと共に提示する。
「自慢のクリップ」2003の再生は、ユーザが「自慢のクリップ」を記録し、それを解凍して再生するときに、RAIDアレイ1511−1512に記憶された圧縮ビデオセグメントをapp/gameサーバー1521−1525がロードすることにより具現化される。
又、「自慢のクリップ」2003は、“3D DVR”ビデオセグメント(即ち、再生でき且つユーザがカメラの視点を変更するのを許すゲームからのゲーム状態シーケンス)でもあり、これは、そのような能力をサポートするゲームからのものである。この場合、ゲームセグメントが記録されたときにユーザが作った特定の「フライスルー」の圧縮ビデオ記録に加えて、ゲーム状態情報が記憶される。「ユーザページ」が見られ、そして全てのサムネール及びビデオウインドウが絶えずループ化するときには、3D DVR「自慢のクリップ」2003は、ユーザがゲームセグメントの「フライスルー」を記録したときに圧縮ビデオとして記録された「自慢のクリップ」2003を絶えずループ化する。しかし、ユーザが3D DVR「自慢のクリップ」2003を選択してそれをクリップするときには、圧縮ビデオの「自慢のクリップ」を再生できるようにするDVRコントロールに加えて、ユーザは、ゲームセグメントに対する3D DVR能力を与えるボタンをクリックすることができる。それらは、彼等自身でゲームセグメント中にカメラの「フライスルー」を制御することができ、そしてそれらが望む(及びユーザページを所有するユーザがそれを許す)場合に、別の「自慢のクリップ」の「フライスルー」を圧縮ビデオ形態で記録することができ、これは、次いで、ユーザページの他の視聴者に利用可能となる(直ちに、又はユーザページの所有者が「自慢のクリップ」を再検討する機会をもった後に)。
この3D DVR「自慢のクリップ」2003の能力は、記録されたゲーム状態情報を別のapp/gameサーバー1521−1525において再生しようとしているゲームを作動することによりイネーブルされる。ゲームは、ほぼ瞬間的に作動できるので(上述したように)、「自慢のクリップ」により記録されたゲーム状態にプレイを限定してゲームを作動し、次いで、ユーザが、圧縮ビデオを遅延バッファ1515に記録しながらカメラで「フライスルー」を実行できるようにするのは、困難ではない。ユーザが「フライスルー」の実行を完了すると、ゲームが不作動にされる。
ユーザの視点から、3D DVRの「自慢のクリップ」2003で「フライスルー」を作動することは、リニアな「自慢のクリップ」2003のDVRコントロールを制御することより努力が要らない。それらは、ゲームについて又はゲームをどのようにプレイするかについて何も知らなくてよい。それらは、別の者により記録されるゲームセグメント中に3D世界を凝視するバーチャルカメラオペレータに過ぎない。
又、ユーザは、それら自身のオーディオを、マイクロホンから記録されるか又はアップロードされる「自慢のクリップ」にオーバーダビングすることもできる。このようにして、「自慢のクリップ」は、ゲームからのキャラクタ及びアクションを使用して、カスタムアニメーションを生成するのに使用できる。このアニメーション技術は、「マシニマ(machinima)」として一般に知られている。
ユーザがゲームを進めるにつれて、異なるスキルレベルを達成する。プレイしたゲームは、達成度をサービスコントロールシステム401へ報告し、それらのスキルレベルが「ユーザページ」に示される。
双方向アニメ化広告
オンライン広告は、テキストから、静止映像へ、ビデオへ、そして今や、Adobe Flashのようなアニメーションシンクライアントを使用して典型的に具現化される双方向セグメントへと推移してきた。アニメーションシンクライアントを使用する理由は、ユーザが、典型的に、製品やサービスが彼等に推薦される特典に対する遅れが耐え難いからである。又、シンクライアントは、非常に低性能のPCで実行され、従って、広告主は、双方向アドが適切に機能するという高い信頼度をもつことができる。不都合なことに、Adobe Flashのようなアニメーションシンクライアントは、双方向性の度合い及び経験の巾が制限される(ダウンロード時間を軽減するために)。
図21は、ショールーム内で車を回転させ、車がどのように見えるかリアルタイムレイトレーシングで示しながら、ユーザが車の外部及び内部の色を選択する双方向広告を示している。ユーザは、車を運転するアバターを選択し、次いで、ユーザは、レーストラック上、又はモナコのようなエキゾチックな場所でドライブするように車を取り出すことができる。ユーザは、より大きなエンジン又はより優れたタイヤを選択することができ、次いで、その変更した構成が車の加速性能又は路面の食い付きにどのように影響するか見ることができる。
もちろん、広告は、実際上、精巧な3Dビデオゲームである。しかし、PC又はビデオゲームコンソール上に再生できる広告については、おそらく、100MBダウンロードを要求し、そしてPCの場合には、特殊なドライバのインストールを要求すると共に、PCが充分なCPU又はGPU計算能力に欠ける場合には全く実行されないことがある。従って、このような広告は、従来の構成では不可能である。
ホスティングサービス210では、このような広告は、ほぼ瞬時に起動し、そしてユーザのクライアント415の能力がどんなものであっても、完全に実行される。従って、それらは、シンクライアント双方向アドより素早く起動し、著しく経験に富み、且つ非常に信頼性が高い。
リアルタイムアニメーション中のストリーミング幾何学形状
RAIDアレイ1511−1512及びインバウンドルーティング1502は、リアルタイムアニメーション(例えば、複雑なデータベースを伴うフライスルー)中にゲームプレイ又はアプリケーションの中間において幾何学形状をオンザフライで確実に配信するためにRAIDアレイ1511−1512及びインバウンドルーティング1502に依存するビデオゲーム及びアプリケーションを設計できるように高速で且つ短待ち時間のデータレートを与えることができる。
図1に示すビデオゲームシステムのような従来のシステムでは、特に実際の家庭用装置に使用できる大量記憶装置は、要求される幾何学形状をある程度予想できる状況を除き、ゲームプレイ中に幾何学形状をストリームするには遥かに低速である。例えば、特定の道路が存在するドライブゲームにおいて、視野に入って来るビルの幾何学形状は、合理的に充分なほど予想でき、そして大量記憶装置は、近づきつつある幾何学形状が位置している場所を前もって探すことができる。
しかし、予想できない変化を伴う複雑なシーンにおいて(例えば、あたり一面に複雑なキャラクタが存在する戦闘のシーンにおいて)、PC又はビデオゲームシステムのRAMが、現在視野にある物体に対する幾何学形状で完全に埋められており、次いで、ユーザが突然それらのキャラクタを、それらキャラクタの背後の視野へ方向転換する場合に、幾何学形状がRAMに予めロードされていなければ、それを表示できるまでに遅延が生じることになる。
ホスティングサービス210において、RAIDアレイ1511−1512は、ギガビットイーサネット速度以上でデータをストリームすることができ、そしてSANネットワークでは、10ギガビットのイーサネット又は他のネットワークに勝る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号“Apparatus and method for capturing the motion of a performer”、2004年9月15日に出願された第10/942,413号“Apparatus and method for capturing the expression of a performer”、2005年2月25日に出願された第11/066,954号“Apparatus and method for improving marker identification within a motion capture system”、2005年3月10日に出願された第11/077,628号“Apparatus and method for performing motion capture using shutter synchronization”、2005年10月20日に出願された第11/255,854号“Apparatus and method for performing motion capture using a random pattern on capture surfaces”、2006年6月7日に出願された第11/449,131号“System and method for performing motion capture using phosphor application techniques”、2006年6月7日に出願された第11/449,043号“System and method for performing motion capture by strobing a fluorescent lamp”、2006年6月7日に出願された第11/449,127号“System and method for three dimensional capture of stop-motion animated characters”の要旨)を使用して捕獲される生の演技が、非常に滑らかな捕獲表面を、次いで、高多角形数追跡表面(即ち、多角形の動きが顔の動きに正確に追従する)をどのように生じるか示している。最終的に、生の演技のビデオが追跡表面にマップされて、テクスチャ処理表面を形成するときに、ホトリアルな結果が得られる。
現在のGPU技術は、追跡表面における多角形の数及びテクスチャをレンダリングしそして表面をリアルタイムで照明することができるが、多角形及びテクスチャがフレーム時間ごとに変化する(これは、最もホトリアルな結果を生じる)場合には、近代的PC又はビデオゲームコンソールの利用可能な全てのRAMを急速に消費してしまう。
上述したストリーミング幾何学形状技術を使用すると、app/gameゲームサーバー1521−1525へ幾何学形状を連続的に供給して、ホトリアルな顔を連続的にアニメ化し、生の動きの顔とほとんど見分けがつかない顔をもつビデオゲームを作成できるようにするが実際的である。
リニアなコンテンツと双方向特徴との一体化
動画、テレビ番組及びオーディオ資料(集合的に「リニアコンテンツ」)は、家庭及びオフィスのユーザに多数の形態で広く利用することができる。リニアコンテンツは、CD、DVD、HD−DVD及びBlu−rayメディアのような物理的なメディアにおいて取得することができる。又、これは、衛星及びケーブルTV放送からDVRにより記録することもできる。そして、衛星及びケーブルTVを通してペイパービュー(PPV)コンテンツとして、及びケーブルTVのビデオオンデマンド(VOD)として利用することもできる。
益々多くのリニアコンテンツが、インターネットを通して、ダウンロードされたコンテンツとして及びストリーミングコンテンツとして利用できるようになった。今日、リニアメディアに関連した全ての特徴を経験するための場所は、実際に1つではない。例えば、DVD及び他のビデオ光学メディアは、典型的に、演出家の解説、「メーキングオブ(making of)」特徴、等のように、他の場所では利用できない双方向特徴を有する。オンライン音楽サイトは、一般的にCDでは入手できないカバー技術及び歌情報を有するが、全てのCDをオンラインで入手できるのではない。又、テレビ番組に関連したウェブサイトは、しばしば、特別な特徴、ブログ、及びときには、俳優又は創作スタッフからのコメントを有する。
更に、多くの動画又はスポーツの出来事では、(動画の場合)しばしばリニアメディアと一緒に発売されるか、或いは(スポーツの場合)実世界の出来事(例えば、プレーヤのトレード)に密接に結びついたビデオゲームがしばしばある。
ホスティングサービス210は、異なる形態の関連コンテンツと一緒にリンクしてリニアコンテンツを配布するのに良く適している。確かに、動画の配信は、もはや、高度な双方向性のビデオゲームを配信する挑戦ではなく、ホスティングサービス210は、リニアコンテンツを家庭又はオフィスの広範な装置或いは移動装置へ配信することができる。図23は、リニアコンテンツの選択を示すホスティングサービス210の規範的なユーザインターフェイスページを示している。
しかし、ほとんどのリニアコンテンツ配信システムとは異なり、ホスティングサービス210は、関連する双方向コンポーネント(例えば、DVDにおけるメニュー及び特徴、HD−DVDにおける双方向オーバーレイ、及びウェブサイトにおけるAdobe Flashアニメーション(以下に述べる))を配信することもできる。従って、クライアント装置415の制限は、どの特徴が利用できるかについて、もはや制限を導入しない。
更に、ホスティングサービス210は、リニアコンテンツをビデオゲームコンテンツと動的に且つリアルタイムでリンクすることができる。例えば、ユーザがハリーポッターの映画においてクィディッチの試合を見て、クィディッチのプレイにトライしたい場合に、ボタンをクリックするだけで、映画を休止し、直ちに、ハリーポッタービデオゲームのクィディッチセグメントへ移ることができる。クィディッチの試合をプレイした後に、ボタンの別のクリックで、即座に映画が再開する。
写真的に捕獲されたビデオが生の動きのキャラクタと見分けがつかないようなホトリアルなグラフィック及び制作技術では、ユーザが、生の動きの映画におけるクィディッチゲームから、ここに述べるホスティングサービスにおけるビデオゲームのクィディッチゲームへ移行するときに、2つのシーンは、実質上、見分けがつかない。これは、2つの世界の間の線が見分けられないのでリニアコンテンツ及び双方向(例えば、ビデオゲーム)コンテンツの両方の演出家にとって全く新しい創作オプションを与える。
図14に示すホスティングサービスアーキテクチャーを使用して、3D映画のバーチャルカメラの制御権を視聴者に与えることができる。例えば、列車の車両内で生じるシーンでは、視聴者がバーチャルカメラを制御して、ストーリーが進行する間に車両の周囲を見ることができる。これは、車両内の全ての3Dオブジェクト(アセット)が利用できると共に、シーンをリアルタイムでレンダリングできる充分なレベルの計算パワー、及びオリジナルの映画を仮定している。
そして、非コンピュータ発生娯楽であっても、非常にエキサイティングな双方向特徴を提供することができる。例えば、2005動画“高慢と偏見(Pride and Prejudice)”は、華麗な古い英国風大邸宅における多くのシーンを有している。大邸宅の幾つかのシーンに対し、ユーザは、ビデオを休止し、次いで、カメラを制御して、大邸宅の塔、又はおそらく、周囲のエリアを撮影することができる。これを具現化するために、従来のアップル社のQuickTime VRが具現化されたのと同様に、位置を見失わないように魚眼レンズをつけて大邸宅を通してカメラを搬送することができる。次いで、種々のフレームが変換され、従って、映像は歪むことなく、映画と共に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は、トーナメントに非常に良く適している。ローカルクライアントではゲームが実行されないので、ユーザがチートする機会がない。又、出力ルーティング1540がUDPストリームをマルチキャストできるので、ホスティングサービス210は、メジャートーナメントを観衆の中の数千の人々に一度にブロードキャストすることができる。
実際に、数千のユーザが同じストリーム(例えば、メジャートーナメントのビューを示す)を受信するように普及した幾つかのビデオストリームがあるときは、多くのクライアント装置415へ大量配布するためにAkamai又はLimelightのような「コンテンツデリバリーネットワーク」(CDN)へビデオストリームを送信するのがより効率的である。
CDNを使用してトッププレーヤグループの「ゲームファインダー」ページを示すときには、同様の効率レベルを得ることができる。
メジャートーナメントの場合、生の有名アナウンサを使用して、ある試合中に実況放送することができる。メジャートーナメントを見ているのは大勢のユーザであるが、トーナメントでプレイするのは比較的少数である。有名アナウンサからの音声は、トーナメントでプレイしているユーザをホストすると共にトーナメントにおけるゲームの観客モードコピーをホストするapp/gameゲームサーバー1521−1525へルーティングすることができ、そしてその音声は、ゲーム音声の上にオーバーダビングすることができる。有名アナウンサの映像も、ゲームにオーバーレイし、おそらくは、観客のビューにオーバーレイすることができる。
ウェブページロードの加速
ワールドワイドウェブ、その一次トランスポートプロトコルであるハイパーテキストトランスファープロトコル(HTTP)は、ビジネスだけが高速インターネット接続をもちそしてオンラインにいる消費者がダイヤルアップモデム又はISDNを使用していた時代に考えられ定義されたものである。そのとき、高速接続用の「黄金律(gold standard)」は、1.5Mbpsのデータレートを対称的に(即ち、両方向に等しいデータレートで)与えるT1ラインであった。
今日、状況は、完全に異なる。開発された世界の多くにおいてDSL又はケーブルモデム接続を通る平均的な家庭用接続の速度は、T1ラインより遥かに高いダウンストリームデータレートを有している。実際に、世界の幾つかの部分では、ファイバー・ツー・ザ・カーブ(fiber-to-the-curb)が、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を破棄するか又は再定義することである。或いは、おそらく、ウェブサイト所有者がそのファイルを単一のファイル(例えば、Adobe Flashフォーマットの)へうまく合併することである。しかし、実際的な問題として、この会社及び多くの他の者は、そのウェブサイトアーキテクチャー多大な投資をしている。更に、ある家庭は、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又はゲームコンソール)は、一週間に僅かな時間しか使用されない。ニールセンエンターテイメント“Active Gamer Benchmark Study”(http://www.prnewswire.com/cgibin/stories.pl?ACCT=104&STORY=/www/story/10-05-2006/0004446115&EDATE=)による2006年10月5日プレスリリースによれば、積極的なゲーマーは、一週間に平均14時間を費やしてビデオゲームコンソールをプレイし、そして一週間に約17時間をハンドヘルド状態にしている。又、このレポートは、(コンソール、ハンドヘルド及びPCゲームプレイを含む)全てのゲームプレイ活動に対し、積極的なゲーマーは、一週間に平均13時間を費やすと述べている。コンソールビデオゲームのプレイ時間が高い数値であることを考慮すれば、一週間は、24*7=168時間であり、これは、積極的なゲーマーの家では、ビデオゲームコンソールが一週間の時間のうち17/168=10%しか使用されないことを意味する。即ち、90%の時間は、ビデオゲームコンソールがアイドル状態である。高いコストのビデオゲームコンソールであり、そして製造者がこのような装置に助成しているとすれば、高価なリソースの非常に非効率的な使い方である。会社の中のPCも、典型的に、一週間のうち僅かな時間しか使用されず、特に、Autodesk Mayaのようなハイエンドアプリケーションにしばしば要求される非ポータブルのデスクトップPCがそうである。ある会社は、全ての時間及び休日も営業し、そしてあるPC(例えば、夜家で仕事をするために持ち運ばれるポータブル)は、全ての時間及び休日も使用されるが、会社のほとんどの活動は、月曜日から金曜日まで所定の営業時間ゾーンのほぼ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時まで会社及び学校により利用することができるが、夜、週末及び休日には精巧なビデオゲームをプレイするゲーマーにより利用することができる。同様に、低性能のアプリケーションは、Celeron CPUをもち、GPUをもたず(又は非常にローエンドのGPUをもち)且つ制限されたRAMをもつ低性能サーバー402において会社の時間中に会社及び学校によって利用することができ、そして低性能ゲームは、会社の時間中でないときに低性能サーバー402を利用することができる。
更に、ここに述べるホスティングサービス構成では、数百万でなくても数千のユーザ間でリソースが効率的に共用される。一般的に、オンラインサービスは、所与の時間にサービスを利用する全ユーザベースの僅かな割合しかもたない。上述したニールセンのビデオゲーム使用統計値を考えると、なぜそうなるか調べることは容易である。積極的なゲーマーがコンソールゲームを一週間に17時間しかプレイしない場合に、ゲームのピーク使用時間が、夜(5−AM12、7*5日=35時間/週)及び週末(AM8−AM12、16*2=32時間/週)の典型的な非仕事非会社時間中であると仮定すると、17時間のゲームプレイに対して一週間に35+32=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を経て又はオフィス間のプライベートな広帯域巾接続を通してコンピュータにリモートアクセスするための解決策は、多数存在する。例えば、Microsoft Windowsターミナルサーバーでは、又はRealVNC社からのVNCのようなバーチャルネットワーク計算アプリケーションを通して、或いはSun Microsystemsからのシンクライアント手段を通して、ユーザは、グラフィック応答時間及びユーザ経験においてある範囲のクオリティでPC又はサーバーへのリモートアクセスを得ることができる。更に、このような自己管理型のサーバーセンターは、典型的に、単一の会社又は学校専用であり、従って、異種のアプリケーション(例えば、娯楽及び会社アプリケーション)が週の異なる時間に同じ計算リソースを利用するときに考えられる使用の重複の利点を取り入れることができない。従って、多くの会社及び学校は、各ユーザへのLAN速度ネットワーク接続を有するサーバーセンターをそれ自身で設定するスケール、リソース又は専門知識に欠ける。実際に、学校及び会社の大部分は、家庭と同じインターネット接続(例えば、DSL、ケーブルモデム)を有する。
このような組織は、定常的ベース又は周期的ベースのいずれかで非常に高性能の計算の必要性を依然有している。例えば、小さな建築会社は、少数の建築家しかおらず、設計の仕事をするときに計算の必要性が比較的僅かであるが、非常に高性能の3D計算を周期的に必要とする(例えば、クライアントに対する新たな建築設計の3Dフライスルーを創作するときに)。図4aに示すシステムは、このような組織に非常に良く適している。組織は、典型的に非常に安価な、家庭に提供されるものと同じ種類のネットワーク接続(例えば、DSL、ケーブルモデム)以上のものを必要としない。それらは、安価なPCをクライアント415として利用するか、或いはPCを全く省き、制御信号ロジック413及び短待ち時間ビデオ解凍412を簡単に具現化する安価な専用装置を利用するかのいずれかである。これらの特徴は、PCの窃盗や、PC内の専用コンポーネントへのダメージに伴う問題がある学校にとって特に魅力的である。
このような構成は、このような組織の多数の問題を解決する(そしてこれら効果の多くは、一般的な計算を行う家庭のユーザによっても共用される)。その1つとして、運営コスト(最終的に、実現可能な取引を得るためにある形態でユーザへ還元されねばならない)を非常に低くすることができる。というのは、(a)計算リソースが、週内に異なるピーク使用時間を有する他のアプリケーションと共有され、(b)組織が、必要な時だけ高性能計算リソースにアクセスする(及びそのコストを被る)ことができ、(c)組織が、高性能計算リソースをバックアップ又は維持するためのリソースを設ける必要がないからである。
海賊行為の排除
更に、ゲーム、アプリケーション、双方向映画、等は、今日のように海賊行為を受けることがもはやない。ゲームは、サービスセンターで実行されるので、ユーザには、基礎的なプログラムコードへのアクセス権が与えられず、従って、海賊行為を受けるものは何もない。ユーザがソースコードをコピーする場合でも、ユーザは、標準的なゲームコンソール又は家庭用コンピュータにおいてコードを実行することはできない。これは、標準的なビデオゲームが入手できない中国のような世界の場所に市場を開く。又、中古ゲームの再販売はできない。
ゲームの開発者にとって、今日、市場の不連続部は僅かである。ホスティングサービス210は、技術の完全に新たな世代がユーザや開発者を強制的にアップグレードさせ且つゲーム開発者がハードウェアプラットホームの適時の配信に依存する現在の状況とは対照的に、ゲームの要件が変化するにつれて時間と共に徐々に更新することができる。
ストリーミング双方向ビデオ
以上の説明は、一般的インターネットをベースとする短待ち時間のストリーミング双方向ビデオ(これは、ここで使用されるオーディオもビデオと一緒に暗示的に含む)の新規な基礎的概念により可能となる広範囲なアプリケーションを述べるものである。インターネットを通してストリーミングビデオを与える従来のシステムは、長待ち時間の双方向性で具現化できるアプリケーションを可能にするだけである。例えば、リニアビデオのための再生コントロール(例えば、休止、巻き戻し、早送り)は、長い待ち時間で充分に機能し、リニアビデオフィードの中から選択することができる。そして、上述したように、あるビデオゲームの性質は、それらを長待ち時間でプレイすることを許す。しかし、ストリーミングビデオのための従来の解決策の長待ち時間(又は低圧縮比)は、ストリーミングビデオの潜在的なアプリケーションを甚だしく制限するか、又はそれらの開発を特殊なネットワーク環境へと狭め、そしてそのような環境においても、従来の技術は、ネットワークに実質的な負担を導入する。ここに述べる技術は、インターネットを通る短待ち時間のストリーミング双方向ビデオ、特に、消費者グレードのインターネット接続を通して可能になるもの、で考えられる広範囲なアプリケーションに対してドアを開く。
実際上任意の量の計算パワー、任意の量の高速記憶、並びにパワフルなサーバーの中の非常に高速なネットワークでユーザ経験の向上を果たすに充分な、図4cのクライアント465と同程度に小さいクライアント装置で、実際に、新しい計算の時代を可能にする。更に、帯域巾要件は、システムの計算パワーが増大するにつれて拡大しないので(即ち、帯域巾要件は、表示解像度、クオリティ及びフレームレートに結び付いているだけであるので)、ブロードバンドインターネット接続が偏在し(例えば、広く普及した短待ち時間のワイヤレスカバレージを通して)、信頼性があり、且つ全ユーザのディスプレイ装置422のニーズを満足するに充分な広い帯域巾であるときには、典型的な消費者及び会社向けアプリケーションに対して、(Windows、Linux、OSX、等を実行するPC又は移動電話のような)シッククライアントが必要か、又は(Adobe Flash又はJavaのような)シンクライアントでもよいかが問題となる。
ストリーミング双方向ビデオの出現は、計算アーキテクチャーの構造についての仮定を考え直す結果となった。その一例が、図15に示すホスティングサービス210のサーバーセンター実施形態である。遅延バッファ及び/又はグループビデオ1550のためのビデオ経路は、app/gameサーバー1521−1525のマルチキャストされたストリーミング双方向ビデオ出力が、経路1552を経てリアルタイムで、又は経路1551を経て選択可能な遅延の後に、app/gameサーバー1521−1525へフィードバックされる。これは、従来のサーバー又はローカル計算アーキテクチャーでは不可能であるか又は実現不能な広範囲の実際的なアプリケーション(例えば、図16,17及び20に示すもののような)を可能にする。しかし、より一般的なアーキテクチャー上の特徴として、フィードバックループ1550が与えるものは、ストリーミング双方向ビデオレベルでの反復である。というのは、アプリケーションが要求したときに、ビデオを不定にループバックできるからである。これは、従来得られなかった広範囲のアプリケーションの可能性を実現できるようにする。
別の重要なアーキテクチャー上の特徴は、ビデオストリームが単一方向のUDPストリームであることである。これは、実際上、ストリーミング双方向ビデオのマルチキャスティングを任意の度合いで行えるようにする(対照的に、TCP/IPストリームの両方向ストリームは、ユーザの数が増えるにつれて前後通信からネットワークに益々大きな渋滞を生じることになる)。マルチキャスティングは、サーバーセンター内で重要な能力である。というのは、システムが、インターネットユーザ(及び実際には世界の人口)の増大するニーズに応答して、1対多又は多対多で、通信を行えるようにするからである。この場合も、ストリーミング双方向ビデオ反復及びマルチキャスティングの両方の使用を示す図16について述べた例は、可能性についての非常に大きな氷山の頂点に過ぎない。
一実施形態では、ここ及び関連するステップに示す種々の機能的モジュールは、そのステップを遂行するための固定布線ロジックを含む特定のハードウェアコンポーネント、例えば、特定用途向け集積回路(ASIC)により遂行されるか、又はプログラムされたコンピュータコンポーネント及びカスタムハードウェアコンポーネントの組合せにより遂行される。
一実施形態では、これらモジュールは、テキサスインスツルーメント社のTMS320xアーキテクチャー(例えば、TMS320C6000、TMS320C5000、等)のプログラム可能なデジタル信号プロセッサ(DSP)において具現化される。これらの基礎的な原理に適合する種々の異なるDSPを使用することができる。
これら実施形態は、上述した種々のステップを含むことができる。これらステップは、汎用プロセッサ又は特殊目的のプロセッサが幾つかのステップを遂行するようにさせるマシン実行可能なインストラクションにおいて実施することができる。これら基礎的な原理に関連しない種々の要素、例えば、コンピュータメモリ、ハードドライブ、入力装置は、適切な観点を不明瞭にしないために図面から除外してある。
ここに開示する要旨の要素は、マシン実行可能なインストラクションを記憶するためのマシン読み取り可能なメディアとして与えられてもよい。マシン読み取り可能なメディアは、フラッシュメモリ、光学的ディスク、CD−ROM、DVD ROM、RAM、EPROM、EEPROM、磁気又は光学カード、電子的インストラクションを記憶するのに適した伝播メディア又は他の形式のマシン読み取り可能なメディアを含むが、これらに限定されない。例えば、本発明は、通信リンク(例えば、モデム又はネットワーク接続)を経ての搬送波又は他の伝播メディアで実施されるデータ信号によりリモートコンピュータ(例えば、サーバー)から要求側コンピュータ(例えば、クライアント)へ転送されるコンピュータプログラムとしてダウンロードすることができる。
又、ここに開示する要旨の要素は、一連のオペレーションを遂行するようにコンピュータ(例えば、プロセッサ又は他の電子装置)をプログラムするのに使用されるインストラクションが記憶されたマシン読み取り可能なメディアを含むコンピュータプログラム製品として提供されてもよいことを理解されたい。或いは又、オペレーションは、ハードウェア及びソフトウェアの組合せにより遂行されてもよい。マシン読み取り可能なメディアは、フロッピー(登録商標)ディスケット、光学的ディスク、CD−ROM、及び磁気・光学ディスク、ROM、RAM、EPROM、EEPROM、磁気又は光学カード、電子的インストラクションを記憶するのに適した伝播メディア又は他の形式のメディア/マシン読み取り可能なメディアを含むが、これらに限定されない。例えば、ここに開示する要旨の要素は、通信リンク(例えば、モデム又はネットワーク接続)を経ての搬送波又は他の伝播メディアで実施されるデータ信号によりプログラムがリモートコンピュータ又は電子装置から要求側コンピュータへ転送されるようなコンピュータプログラム製品としてダウンロードすることができる。
更に、ここに開示する要旨は、特定の実施形態に関連して説明したが、本開示の範囲内で多数の変更や修正がなされ得る。従って、本発明及び添付図面は、単なる例示に過ぎず、それに限定されるものではない。