特許 7280058 ビデオを記録および再生するシステムおよび方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-05-15

(45)【発行日】2023-05-23

(54)【発明の名称】ビデオを記録および再生するシステムおよび方法

(51)【国際特許分類】

   H04N 5/92 20060101AFI20230516BHJP

   A63F 13/52 20140101ALI20230516BHJP

   A63F 13/497 20140101ALI20230516BHJP

   G11B 20/10 20060101ALI20230516BHJP

   G11B 27/00 20060101ALI20230516BHJP

   G06T 13/20 20110101ALI20230516BHJP

【ＦＩ】

H04N5/92 010

A63F13/52

A63F13/497

G11B20/10 321Z

G11B27/00 D

G06T13/20

【請求項の数】 12

【外国語出願】

(21)【出願番号】P 2019027394

(22)【出願日】2019-02-19

(65)【公開番号】P2019216405

(43)【公開日】2019-12-19

【審査請求日】2021-11-30

(31)【優先権主張番号】1802946.2

(32)【優先日】2018-02-23

(33)【優先権主張国・地域又は機関】GB

(31)【優先権主張番号】1806301.6

(32)【優先日】2018-04-18

(33)【優先権主張国・地域又は機関】GB

(73)【特許権者】

【識別番号】506379415

【氏名又は名称】ソニー インタラクティブ エンタテインメント ヨーロッパ リミテッド

(73)【特許権者】

【識別番号】310021766

【氏名又は名称】株式会社ソニー・インタラクティブエンタテインメント

(74)【代理人】

【識別番号】100105924

【弁理士】

【氏名又は名称】森下 賢樹

(72)【発明者】

【氏名】ヒュー アレクサンダー ディンズデール スペンサー

(72)【発明者】

【氏名】アンドリュー スワン

(72)【発明者】

【氏名】ニコラス アンソニー エドワード ライアン

【審査官】鈴木 隆夫

(56)【参考文献】

【文献】特開２０１８－０１１８４９（ＪＰ，Ａ）

【文献】特開２００６－００６８５３（ＪＰ，Ａ）

【文献】特表２０１６－５２６９５７（ＪＰ，Ａ）

【文献】特開２０１６－２０７２０３（ＪＰ，Ａ）

【文献】国際公開第２０１７／０６６０２９（ＷＯ，Ａ１）

【文献】特開２０１４－１２１６１０（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｎ ５／９１－５／９５６

Ａ６３Ｆ １３／５２

Ａ６３Ｆ １３／４９７

Ｇ１１Ｂ ２０／１０

Ｇ１１Ｂ ２７／００

Ｇ０６Ｔ １３／２０

(57)【特許請求の範囲】

【請求項1】

ビデオゲームによって出力されたビデオ画像の第１のシーケンスを記録するステップと、
前記ビデオゲームによって使用された深度バッファについての深度バッファ値のシーケンスを記録するステップと、
前記ビデオ画像の生成に使用されたゲーム内仮想カメラ位置のシーケンスを記録するステップと、
１つ以上のゲーム内イベントおよび該ゲーム内イベントのそれぞれのゲーム内位置を記録するステップと、
前記深度バッファ値のシーケンスを符号化するビデオ画像の第２のシーケンスを生成するステップと、
前記ゲーム内仮想カメラ位置のシーケンスを前記ビデオ画像の第１および第２のシーケンスの少なくとも一方と関連付けるステップと、
を含む、ビデオ記録方法。

【請求項2】

前記１つ以上のゲーム内イベントおよび該ゲーム内イベントのそれぞれのゲーム内位置を前記ビデオゲームの識別子と関連付けるステップ
を含む、請求項１に記載のビデオ記録方法。

【請求項3】

前記深度バッファ値のシーケンスを符号化するビデオ画像の第２のシーケンスを生成するステップは、
第１のビット深度の深度データを、選択されたビデオ方式によって使用される複数のカラー空間記述子チャンネルにまたがって、第１のチャンネルが第１の精度レベルまで深度を表すデータを符号化し、後続のチャンネルまたは後続の各チャンネルが前記第１のチャンネルのデータと併せて第２のより高いレベルまで深度を表すデータを符号化するように、符号化するステップ
を含む、請求項１に記載のビデオ記録方法。

【請求項4】

深度データをカラー空間記述子チャンネル内に符号化するステップは、前記深度データを各々のチャンネルにおいてそれぞれのチャンネルのビット長よりも短いビット長まで符号化するステップを含む、請求項３に記載のビデオ記録方法。

【請求項5】

ビデオ画像のシーケンスを含むビデオゲームプレイセッションの第１のビデオ記録を取得するステップと、
深度バッファ値のシーケンスを符号化することによって生成された第２のビデオ記録を取得するステップと、
前記取得されるビデオ記録の少なくとも一方に関連付けられたゲーム内仮想カメラ位置のシーケンスを表すデータを取得するステップと、
ゲーム内イベントおよびゲーム内イベント位置を表すデータを取得するステップと、
前記関連付けられたゲーム内仮想カメラ位置および復号された深度バッファ値に応じて、ゲーム内イベント位置に対応する前記第１のビデオ記録の現在のビデオ画像内の位置を計算するステップと、
前記計算された位置に応じて、ゲーム内イベントのグラフィック表現によって前記現在のビデオ画像を増補するステップと、
を含む、ビデオ再生方法。

【請求項6】

前記ゲーム内イベントおよびゲーム内イベント位置を表すデータを取得するステップは、統計的に有意なゲーム内イベントおよびゲーム内イベント位置を表すデータを取得するステップを含み、
前記現在のビデオ画像を増補するステップは、前記計算された位置に応じて、前記統計的に有意なゲーム内イベントのグラフィック表現によって前記現在のビデオ画像を増補するステップを含む、請求項５に記載のビデオ再生方法。

【請求項7】

前記増補するステップは、
前記深度バッファ値に応じて、前記ビデオ画像の前景要素によって引き起こされる前記計算された位置における前記グラフィック表現の遮蔽を計算するステップ
を含む、請求項５に記載のビデオ再生方法。

【請求項8】

前記増補するステップは、
異なるそれぞれのグラフィック表現を対応する異なるイベント種類について使用するステップ
を含む、請求項５～７のいずれか一項に記載のビデオ再生方法。

【請求項9】

請求項１～８のいずれか一項に記載の方法をコンピュータシステムに実行させるように構成されたコンピュータ実行可能命令を有しているコンピュータ可読媒体。

【請求項10】

ビデオゲームによって出力されたビデオ画像の第１のシーケンスをビデオストレージ手段に記録するように構成され、
前記ビデオゲームによって使用された深度バッファについての深度バッファ値のシーケンスを記録するように構成され、
前記ビデオ画像の生成に使用されたゲーム内仮想カメラ位置のシーケンスを記録するように構成され、
１つ以上のゲーム内イベントおよび該ゲーム内イベントのそれぞれのゲーム内位置を記録するように構成された記録プロセッサと、
前記深度バッファ値のシーケンスを符号化するビデオ画像の第２のシーケンスを生成するように構成されたビデオ生成プロセッサと、
前記ゲーム内仮想カメラ位置のシーケンスを前記ビデオ画像の第１および第２のシーケンスの少なくとも一方と関連付けるように構成された関連付けプロセッサと、
を備える、ビデオ記録装置。

【請求項11】

ビデオ画像のシーケンスを含むビデオゲームプレイセッションの第１のビデオ記録を取得するように構成され、
深度バッファ値のシーケンスを符号化することによって生成された第２のビデオ記録を取得するように構成され、
前記取得されるビデオ記録の少なくとも一方に関連付けられたゲーム内仮想カメラ位置のシーケンスを取得するように構成された再生プロセッサと、
ゲーム内仮想カメラ位置をイベント分析器へともたらすように構成され、
統計的に有意なゲーム内イベントおよびゲーム内イベント位置を表すデータを取得するように構成された分析プロセッサと、
前記関連付けられたゲーム内仮想カメラ位置および復号された深度バッファ値に応じて、前記ゲーム内イベント位置に対応する前記第１のビデオ記録の現在のビデオ画像内の位置を計算するように構成された位置計算プロセッサと、
前記計算された位置に応じて、前記統計的に有意なゲーム内イベントのグラフィック表現によって前記現在のビデオ画像を増補するように構成された増補プロセッサと、
を備える、ビデオ再生装置。

【請求項12】

請求項１０に記載のビデオ記録装置と、
請求項１１に記載のビデオ再生装置と
を備える、システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ビデオを記録および再生するシステムおよび方法に関する。

【背景技術】

【0002】

ビデオゲームのプレイヤは、立ち往生の場合においてゲーム内で前進し、あるいは追加の特徴の発見を望み、あるいは例えば個人のベストスコアを更新すべく自身の現状のプレイを改善するために、支援を望むことが多い。

【0003】

ビデオの制作者による解説付きのゲーム内映像のビデオキャプチャ（例えば、ＹｏｕＴｕｂｅ（登録商標）におけるウォークスルー（ｗａｌｋ－ｔｈｒｏｕｇｈ）やスピードラン（ｓｐｅｅｄ－ｒｕｎ））が、ガイドまたはエンターテイメントとして人気があるが、所望の情報の提供ならびに／あるいは視聴者が望む特定の動作の説明または実演について、解説者に依存している。所与のビデオについて、関連の情報が視聴者を満足させるように提供されるかどうかを容易に予測することはできず、ビデオを見ても所望の解答が明らかにならない場合、欲求不満につながる。さらに、若い視聴者にとって、解説者が悪態をつき、あるいは他のかたちで不適切な行動を取り得るビデオを見ることは、問題かもしれない。結果として、ビデオゲームに関する支援を望む視聴者にとって、そのようなビデオの恩恵は、きわめて変動し得る。

【発明の概要】

【発明が解決しようとする課題】

【0004】

本発明は、この問題への対処またはこの問題の軽減を追求する。

【課題を解決するための手段】

【0005】

第１の態様においては、請求項１に記載のビデオ記録方法が提供される。

【0006】

別の態様においては、請求項５に記載のビデオ再生方法が提供される。

【0007】

別の態様においては、請求項９に記載のイベント分析方法が提供される。

【0008】

第１の態様においては、請求項１２に記載のビデオ記録装置が提供される。

【0009】

別の態様においては、請求項１３に記載のビデオ再生装置が提供される。

【0010】

別の態様においては、請求項１４に従ってイベント分析器が提供される。

【0011】

本発明のさらなるそれぞれの態様および特徴は、添付の特許請求の範囲に定められる。

【図面の簡単な説明】

【0012】

次に、本発明の実施形態を、添付の図面を参照して、あくまでも例として説明する。

【図1】本発明の実施形態によるビデオ記録装置、ビデオ再生装置、およびイベント分析器のうちの１つ以上として動作することができるエンターテイメント機器の概略図である。

【図2】本発明の実施形態によるビデオ記録装置、ビデオ再生装置、およびイベント分析器を含むシステムの概略図である。

【図3】本発明の実施形態によるビデオ記録方法のフロー図である。

【図4A】本発明の実施形態によるビデオ画像を示している。

【図4B】本発明の実施形態によるビデオ画像に対応する深度バッファ情報を示している。

【図5】本発明の実施形態による深度バッファ情報および追加データのための画像符号化方式を示している。

【図6】本発明の実施形態によるビデオ再生方法のフロー図である。

【図7】本発明の実施形態による統計的に有意なゲーム内イベントのグラフィック表現によるビデオの増補を示している。

【図8】本発明の実施形態によるイベント分析方法のフロー図である。

【図9】本発明の実施形態によるゲーム映像のビデオ記録について可能な増補の典型的な図である。

【図10】本発明の実施形態によるゲーム映像のビデオ記録について可能な増補の典型的な図である。

【図11】本発明の実施形態によるゲーム映像のビデオ記録について可能な増補の典型的な図である。

【図12】本発明の実施形態によるゲーム映像のビデオ記録について可能な増補の典型的な図である。

【発明を実施するための形態】

【0013】

ビデオの記録および再生のシステムおよび方法が開示される。以下の説明においては、本発明の実施形態の完全な理解をもたらすために、いくつかの具体的な詳細が提示される。しかしながら、これらの具体的な詳細が、本発明の実施において必ずしも使用されなくてよいことは、当業者にとって明らかであろう。反対に、当業者にとって公知の具体的詳細は、必要に応じて、分かり易さの目的で省略されている。

【0014】

図１が、Ｓｏｎｙ（登録商標）ＰｌａｙＳｔａｔｉｏｎ ４（登録商標）エンターテイメント機器の全体的なシステムアーキテクチャを概略的に示している。システムユニット１０は、システムユニットに接続することができる種々の周辺機器を備える。

【0015】

システムユニット１０は、加速処理装置（ＡＰＵ）２０を備え、加速処理装置（ＡＰＵ）２０は、中央処理装置（ＣＰＵ）２０Ａとグラフィック処理装置（ＧＰＵ）２０Ｂとを備える単一のチップである。ＡＰＵ２０は、ランダムアクセスメモリ（ＲＡＭ）ユニット２２にアクセスする。

【0016】

ＡＰＵ２０は、随意によりＩ／Ｏブリッジ２４を介してバス４０と通信し、Ｉ／Ｏブリッジ２４は、個別の構成要素であっても、ＡＰＵ２０の一部であってもよい。

【0017】

ハードディスクドライブ３７ならびに互換性のある光ディスク３６Ａ上のデータにアクセスするように動作することができるＢｌｕ－ｒａｙ（登録商標）ドライブ３６などのデータストレージコンポーネントが、バス４０に接続される。さらに、ＲＡＭユニット２２は、バス４０と通信することができる。

【0018】

随意により、補助プロセッサ３８もバス４０へと接続される。補助プロセッサ３８を、オペレーティングシステムを実行し、あるいはサポートするために設けることができる。

【0019】

システムユニット１０は、必要に応じて、オーディオ／ビジュアル入力ポート３１、Ｅｔｈｅｒｎｅｔ（登録商標）ポート３２、Ｂｌｕｅｔｏｏｔｈ（登録商標）無線リンク３３、Ｗｉ－Ｆｉ（登録商標）無線リンク３４、または１つ以上のユニバーサルシリアルバス（ＵＳＢ）ポート３５を介して周辺機器と通信する。オーディオおよびビデオを、ＨＤＭＩ（登録商標）ポートなどのＡＶ出力３９を介して出力することができる。

【0020】

周辺機器として、ＰｌａｙＳｔａｔｉｏｎ Ｅｙｅ（登録商標）などの単眼または立体ビデオカメラ４１、ＰｌａｙＳｔａｔｉｏｎ Ｍｏｖｅ（登録商標）などの杖状のビデオゲームコントローラ４２およびＤｕａｌＳｈｏｃｋ ４（登録商標）などの従来からの手持ち型のビデオゲームコントローラ４３、ＰｌａｙＳｔａｔｉｏｎ Ｐｏｒｔａｂｌｅ（登録商標）およびＰｌａｙＳｔａｔｉｏｎ Ｖｉｔａ（登録商標）などの携帯型のエンターテイメント機器４４、キーボード４５および／またはマウス４６、例えばリモコンの形態のメディアコントローラ４７、ならびにヘッドセット４８を挙げることができる。プリンタまたは３Ｄプリンタ（図示せず）など、他の周辺機器も同様に考慮することができる。

【0021】

ＧＰＵ２０Ｂは、随意によりＣＰＵ２０Ａと連携して、ＡＶ出力３９を介して出力されるビデオ画像およびオーディオを生成する。随意により、オーディオを、オーディオプロセッサ（図示せず）と連係して生成することができ、あるいはオーディオプロセッサによって生成することができる。

【0022】

ビデオ、および随意によりオーディオを、テレビ受像機５１に提示することができる。テレビ受像機がサポートしているのであれば、ビデオは立体であってもよい。オーディオを、ステレオ、５．１サラウンドサウンド、または７．１サラウンドサウンドなどのいくつかのフォーマットのうちの１つにてホームシネマシステム５２に提示することができる。同様に、ビデオおよびオーディオを、ユーザ６０が装着しているヘッドマウントディスプレイユニット５３に提示することができる。

【0023】

動作において、エンターテイメント機器は、ＦｒｅｅＢＳＤ ９．０の変種などのオペレーティングシステムをデフォルトとする。オペレーティングシステムは、ＣＰＵ２０Ａ、補助プロセッサ３８、または両者の混合物上で動作することができる。オペレーティングシステムは、ＰｌａｙＳｔａｔｉｏｎ Ｄｙｎａｍｉｃ Ｍｅｎｕなどのグラフィカルユーザインタフェースをユーザに提供する。このメニューにより、ユーザは、オペレーティングシステムの機能にアクセスし、ゲームおよび随意による他のコンテンツを選択することができる。

【0024】

ここで図２も参照すると、上述のエンターテイメント機器１０は、適切なソフトウェア命令の下で、本発明の一実施形態によるビデオ記録装置（２１０Ａ）および／またはビデオ再生装置（２１０Ｂ）として動作することができる。随意により、エンターテイメント機器は、記録／再生の役割とは別、または記録の役割と一体的に、イベント分析器２２０として動作することもできる。他の実施例において、イベント分析器は、リモートサーバであってよく、さらには／あるいはビデオ再生装置は、携帯電話機もしくはタブレット、ＰＣ、スマートＴＶ、セットトップボックス、または種々さまざまなビデオゲームコンソールなど、エンターテイメント機器１０とは異なる形態の機器であってよい。

【0025】

装置が別々の機器である場合、それらはインターネットを介して（例えば、必要に応じてＥｔｈｅｒｎｅｔ（登録商標）またはＷｉｆｉ（登録商標）ポート３２、３４を使用し、あるいはセルラーモバイルデータを使用して）通信することができる。
ここで図３も参照すると、ビデオ記録装置２１０Ａは、以下のビデオ記録方法に従って動作することができる。

【0026】

第１のステップｓ３１０は、ビデオゲームによって出力されたビデオ画像の第１のシーケンスを記録することを含む。例えば、ＰｌａｙＳｔａｔｉｏｎ ４は、最後のＮ分間のゲームプレイを記憶することを可能にするデータループにて現在のビデオ画像出力のビデオを日常的に保存し、ここでＮは、例えば２０分間であってよい。その後に、ユーザ入力、ゲーム内イベント、またはスケジュールされたイベントに応答して、そのようなビデオデータを、データループにおける上書き時に失われることがないように、エンターテイメント機器のディスクドライブまたはネットワークを介したリモートホストなどの長期のストレージにコピーすることもできる。

【0027】

第２のステップｓ３２０は、ビデオゲームによって使用される深度バッファのための深度バッファ値のシーケンスを記録することを含む。深度バッファは、仮想シーンのどの部分がお互いの前方にあり、したがって最終的にレンダリングされた画像においてお互いを遮る可能性があるかを計算するときに、エンターテイメント機器によって使用される。したがって、深度バッファは、レンダリングされた画像の各々のピクセルについて深度データを提供することができる。

【0028】

次いで、一実施形態においては、レンダリングされた画像の対応するピクセルの深度データのアレイを、深度画像として扱うことができる。したがって、例えば８ビットまたは１６ビットの深度値を、レンダリングされた画像に対応する８ビットまたは１６ビットのグレースケール画像として記憶することができる。深度画像は、対応するビデオ画像と同じ解像度を有することができ、あるいは低解像度バージョン（例えば、ピクセルが１／４である５０％サイズ）を使用することができる。

【0029】

したがって、例えば、３つの８ビットデータチャンネル（例えば、赤色、緑色、および青色）を有する従来からの画像フォーマットの場合、８ビットの深度値が１つのデータチャンネルを占めることができ、あるいは１６ビットの深度値が２つのデータチャンネルを占めることができる。

【0030】

図４Ａが、レンダリングされた画像を示している一方で、図４Ｂが、２つのデータチャンネルにおける対応する深度画像を示している。

【0031】

したがって、深度バッファ値のシーケンスを記録するステップは、記録された深度バッファの各々のインスタンスについて、深度画像の複数の画像データチャンネルのうちの少なくとも１つを使用して深度画像を生成することを含むことができる。

【0032】

深度バッファ値のシーケンスを記録するための別の手法は、本明細書において後述される。

【0033】

第３のステップｓ３３０は、ビデオ画像を生成するために使用されたゲーム内仮想カメラ位置のシーケンスを記録することを含む。仮想カメラ位置は、出力ビデオ画像をレンダリングするときに使用されたカメラの位置である。位置を、ゲーム世界座標系を基準とした絶対位置、および／または所定の原点を有するグローバル座標系に対する絶対位置として定義することができる（例えば、この後者の場合、最初の出力ビデオ画像における仮想カメラの場所を原点に設定でき、後のカメラ位置をこの原点に対する位置とすることができる）。随意により、必要に応じて、その場所におけるカメラの向き／回転、視野、焦点距離、最も近い描画距離、最も遠い描画距離、などのうちの１つ以上など、追加のカメラ位置情報を提供することができる。

【0034】

仮想カメラ位置データを、本明細書において後述されるように、別個のデータストリームとして記録でき、あるいは符号化された深度データに関連付けられたメタデータとして記録することができるが、代案として、複数の画像データチャンネルのうちの深度バッファ値の記録に使用されていない別のチャンネルにデータを符号化することによって記録してもよい。したがって、例えば、赤色および緑色のチャンネルが深度データを符号化するために使用されるＲＧＢ画像において、青色のチャンネルを使用してカメラ位置データを符号化することができる。したがって、本発明の一実施形態において、ゲーム内仮想カメラ位置データは、それぞれの画像データチャンネル内の高コントラストブロックとして空間的に記録される。

【0035】

また、随意により、ゲームが一人称視点からのものではない（すなわち、プレイヤが概念的にも仮想カメラ位置になく、むしろ画面上にアバターが表示されている）場合に、プレイヤの位置、ならびに随意によりプレイヤの向き／回転、速度、モード（例えば、ランニング／ウォーキング）、および／またはポーズも、仮想ビデオカメラ位置データの記録に使用される方式と同じ１つ以上の座標方式を使用して記録することができる。やはり、これも、別個のデータストリームまたはメタデータであってよく、あるいは例えば仮想カメラデータと一緒に同様のやり方で画像内に符号化されてよい。

【0036】

ビデオ画像のカラーチャンネル内に深度データを符号化する第１の例において、図５が、図４Ａの画像と同じ画像について、図４Ｂに示した深度データに対応して、深度データを赤色および緑色チャンネルに符号化し、カメラ／プレイヤ位置データを青色チャンネルに符号化するそのようなＲＧＢ画像を示している。画像のグレースケール再現のために、ブロッキーな特徴が、青色チャンネルにおけるカメラ位置データおよび随意によるプレイヤ位置データなどの空間符号化を表すことを、理解できるであろう。ブロックサイズは、符号化された画像のマクロブロックに対応していても、あるいは符号化される情報の量に応じた任意のサイズであってもよい。ブロックサイズの下限は、ビデオの記録、必要に応じたホスティング／保存／ストリーミング、および再生の際に使用される画像の圧縮／解凍後に確実に復元できるブロックサイズによって定まると考えられる。やはり画像のグレースケール再現のために、地形の縞模様が、１６ビットの距離値が増加するにつれて緑色値を０～２５５の間で循環させる緑色チャンネル内の１６ビットの深度データの下位８ビットによって引き起こされることを、理解できるであろう。この例において、Ｒ、Ｇ、およびＢチャンネルの選択は任意である。したがって、この補足データを、ビデオゲームによって出力されるビデオ画像シーケンスと並列して進む第２の画像シーケンスとして提供することができる。

【0037】

しかしながら、この方式は、オンラインのストリーミングビデオでしばしば見られる高い圧縮率の影響を受ける可能性がある。したがって、深度バッファデータおよび随意による他のデータを記録するための好ましい代案の手法一式を、次に説明する。

【0038】

本発明の一実施形態においては、２つのカラービデオが記録され、すなわち、すでに説明したとおりのレンダリングおよび表示されたシーンのカラービデオと、１６ビットの深度データを符号化するカラービデオとが記録され、１６ビットの深度データを符号化するカラービデオは、典型的には以下のフォーマット、すなわち
・１６ビットのビット深度における４：０：０モノクロームでのＭａｉｎ ４：４：４ １６ Ｉｎｔｒａプロファイルを使用するＨ．２６５ビデオ、または
・１６ビットのビット深度における４：４：４クロマサンプリングでのＭａｉｎ ４：４：４ １６ Ｉｎｔｒａプロファイルを使用するＨ．２６５ビデオ、または
・１６ビットにおける４：０：０または４：４：４でのＨｉｇｈ Ｔｈｒｏｕｇｈｐｕｔ ４：４：４ １６ Ｉｎｔｒａプロファイルなどの同様のフォーマットのビデオ
（これらは、例えばこれらのプロファイルをサポートするＨＥＶＣバージョンまたは同等の符号化方式である）、ならびに／あるいは
・１６ビットの深度バッファがｈ２６４、ＡＶ９、ｈ２６５、などを用いる通常のビデオのように記憶することができる３つのカラーチャンネル（例えば、ＲＧＢ値）へと変換されるＵＣＬカラービデオ
のうちの１つに基づく。

【0039】

その内容が本明細書に援用されるＦａｂｒｉｚｉｏ Ｐｅｃｅ、Ｊａｎ Ｋａｕｔｚ、およびＴｉｍ Ｗｅｙｒｉｃｈの「Ａｄａｐｔｉｎｇ Ｓｔａｎｄａｒｄ Ｖｉｄｅｏ Ｃｏｄｅｃｓ ｆｏｒ Ｄｅｐｔｈ Ｓｔｒｅａｍｉｎｇ」、Ｊｏｉｎｔ Ｖｉｒｔｕａｌ Ｒｅａｌｉｔｙ Ｃｏｎｆｅｒｅｎｃｅ ｏｆ ＥｕｒｏＶＲ － ＥＧＶＥ （２０１１）、編集人Ｒ．Ｂｌａｃｈ、Ｓ．Ｃｏｑｕｉｌｌａｒｔ、Ｍ．Ｄ'Ｃｒｕｚ、Ａ．Ｓｔｅｅｄ、およびＧ．Ｗｅｌｃｈにおいてライブアクションビデオに関連して説明されているように、ＵＣＬカラービデオは、深度データ（カラーデータとして扱われる）の弾力的な圧縮を可能にする。

【0040】

要約すると、ＵＣＬカラービデオフォーマットにおいては、第１のカラーチャンネルの上位８ビットが、おおよその深度値を提供するための１６ビットの深度データからの線形マッピングである。次に、第２および第３のカラーチャンネルが、１６ビットの深度データにも適用され、位相は異なるが深度データの量子化レベルの少なくとも２倍の周期（例えば、２５６のレベルを有する８ビットの深度の場合、周期は５１２以下になると考えられる）を有するマッピング（例えば、三角波）である。位相差により、それらは、関数の空間周期に関して相補的な高分解能の深度情報を符号化する。その後に、第１のチャンネルにおけるマッピングを逆にして大まかな深度値をもたらし、次いで第１のチャンネルからの値に応じて第２および第３のチャンネルのうちの典型的には一方のマッピングを逆にすることによって大まかな値を調整するための相対の深度値を得ることによって、深度情報を回復することができる。

【0041】

同様に考慮され得る別のフォーマットにおいては、１６ビットの深度データが、損失の多いやり方で８ビットに圧縮され、第１のカラーチャンネルの上位８ビットに格納される。次に、第１の補正層（例えば、元の深度層と第１のカラーチャンネル内のデータの解凍バージョンとの間の差）が、第２のカラーチャンネルの上位８ビットに格納される。最後に、第２の補正層（例えば、元の深度層と補正層を使用して補正されたときの第１のカラーチャンネル内のデータの解凍バージョンとの間の差）が、第３のカラーチャンネルの上位８ビットに格納される。あるいは、単一の補正ステップのための補正データを、それぞれの上位８ビットにおいて第２および第３の両方のカラーチャンネルの間に格納することができる。

【0042】

換言すると、どちらのフォーマットでも、８ビットの第１のチャンネルが、大まかではあるが全体的な深度値をもたらす一方で、８ビットの第２および第３のチャンネルが、大まかな推定値を調整するためのより高い解像度の深度情報を提供する。

【0043】

やはりいずれの場合も、ビデオコーデックが例えば１０ビットの色深度を含む場合に、各々のチャンネルの８ビットが、ビデオ圧縮に対してさらにロバストである。

【0044】

したがって、とりわけ、どちらの場合においても、元の深度データの１６ビットが、ホストデータ方式における２４ビットの符号化された深度データ（ＲＧＢデータ、あるいはＹＵＶ、ＹＣｏＣｇ、ＹＣｂＣｒ、などの同様のデータ）として格納され、好ましくはそれらのビットは、ホストデータ方式の少なくとも最下位ビットを含まないが、いくつかの方式は異なるチャンネルに異なる数のビットを割り当て、したがって随意により、あまり好ましくはないが、少なくとも１つのチャンネル（ただし、全てのチャンネルではない）が符号化された深度データによって占められてもよいことを、理解できるであろう。当然ながら、深度情報における潜在的な誤差を許容でき、あるいは予想される圧縮方式がビット値に影響を及ぼさない（あるいは、視覚的に許容できる程度の影響しか及ぼさない）場合、符号化された深度データは、一部または全てのカラーチャンネルのそれぞれのビットの全てを占めてもよい。

【0045】

とりわけ、上記の概要がカラーチャンネルに言及している一方で、いくつかのカラー符号化方式では、全てのチャンネルが色自体に対応しているわけではない（例えば、或るチャンネルは輝度を表すことができる）が、いずれにせよ、全体としての方式は、色空間における点を定めるように働き、この意味において、チャンネルは本明細書においてカラーチャンネルと呼ばれ、あるいは色空間記述子チャンネルとも呼ばれる。

【0046】

３つのチャンネルにおける１６ビットの深度データおよび８ビットへの圧縮が、全て例示にすぎないことを理解できるであろう。より一般的には、ＵＣＬカラービデオにおいて、Ｎビットの深度データ（Ｎは、典型的には１６）を、色空間記述子チャンネル毎にＭビット（Ｍは、典型的には８）へと符号化することができ、典型的にはＭ＜Ｐであって、Ｐはホストデータ方式におけるそれぞれのチャンネルの本来のビット深度であり、ＭはＰよりも好ましくは１ビット、より好ましくは２ビット少ない。使用されるカラーチャンネルの数は、典型的には３（例えば、ＹＵＶ）であるが、違ってもよい（例えば、ＣＭＹＫ）。

【0047】

したがって、より一般的には、深度バッファ値のシーケンスを符号化することは、第１のビット深度の深度データを、選択されたビデオ方式によって使用される複数の色空間記述子チャンネルにまたがって、第１のチャンネルが第１の精度レベルまで深度を表すデータを符号化し、後続のチャンネルまたは後続の各々のチャンネルが第１のチャンネルのデータとの組み合わせにおいて第２のより高いレベルまで深度を表すデータを符号化するように、符号化することを含む。したがって、典型的には、この符号化において、各々のチャンネルにおける深度データは、それぞれのチャンネルのビット長よりも短いビット長に符号化されるが、これは必須ではない。

【0048】

したがって、レンダリングされた環境のカラービデオおよび深度データのカラー符号化ビデオの両方を、例えば１名以上の視聴者へとストリーミングされるように、ｈ．２６５などの従来からのビデオ符号化技術によって符号化および／または圧縮することができ、深度情報の量子化は、典型的には、レンダリングされたビデオにおけるカラーデータと同じように（または、それ以上に）ロバストなやり方で保存されると考えられる。

【0049】

随意により、送信および同期を容易にするために、２つのビデオを（そうでないにもかかわらず）立体視ペアとして符号化してもよい。第４のステップｓ３４０は、仮想カメラ位置および随意によるプレイヤ位置についての方式と同様の方式を使用して、１つ以上のゲーム内イベントおよびそれらのそれぞれのゲーム内位置を記録することを含む。どのようなゲーム内イベントをこのやり方で記録するかの選択は、設計者によって行われると考えられるが、典型的には、クラッシュ／キャラクタの死亡、本物またはコンピュータベースの対戦相手の追い越し／殴打、ユーザのゲーム内状態の変化（例えば、装備する武器などの変更、車におけるナイトロックスブーストの使用）、およびプレイヤの選択（障害物を避けるために左または右に曲がる、またはそれを飛び越えることを選択する、など）のうちの１つ以上を含むことができる。この後者の場合、選択は、場所に基づいても（例えば、障害物または経路選択）、あるいは論理的（例えば、ゲーム内キャラクタでダイアログツリーをナビゲートするとき）であってもよい所定のゲーム内決定ポイントに関連付けられてよい。場所に基づく選択の場合、いつ選択に応答するかに関するユーザの多様性のために、行われた選択は、決定の後の分析を支援するために、ユーザまたはカメラの位置よりもむしろ、ゲーム内決定ポイントの位置に関連付けられ得る。これに代え、あるいはこれに加えて、そのような決定は、どのビデオ画像を選択データに関連付けることができるのかについての予測可能性をもたらすために、ユーザによってなされたとき、またはゲーム内決定ポイントが仮想カメラに対する最も近い描画位置もしくは仮想カメラとの何らかの他の所定の関係（例えば、所定の距離の範囲内）にあるときに符号化されてよく、あるいは選択データは、これら２つの瞬間の間の各々の画像について（あるいは同様に、カメラおよび／またはユーザのアバターがゲーム内決定ポイントの所定の距離の範囲内にあるビデオフレームについて）符号化されてよい。場所特有のイベントに加えて、進行中のイベントも記録され得る。したがって、随意により、各々のビデオ画像について、現在の１つ以上のユーザ入力（例えば、押されたボタン、または関連する入力値）も同様のやり方で記録して、ユーザのゲームとの対話のおおよその記録をもたらすことができ、同様に、ユーザのゲーム内位置（例えば、アバター位置）を、カメラ位置と異なる場合に進行中のイベントとして扱うことができる。本明細書において後述されるように、この記録ステップが、典型的にはゲームプレイの最中に行われ、ゲームプレイから直接生じるイベントを反映する一方で、これに代え、あるいはこれに加えて、そのようなゲーム内イベントの記録ステップは、ビデオ画像および他のデータが出力された後、かつ随意によりそれらがブロードキャスト／ストリーミングされた後に行われ、すなわち本明細書における技術と互換性のあるビューアを使用してビデオを後に視聴する視聴者は、事後に自身のゲーム内イベントを定義するために利用することができる充分な情報を有する。その後に、これらを、必要に応じて、本明細書において後述されるように、更新されたビデオを再投稿し、あるいは中央サーバに送信することによって、共有することができる。

【0050】

上述のように、データは、ビデオゲームによって出力されたビデオ画像のシーケンスの各々について記録されるが、一般に、出力ビデオ画像自体のシーケンスの一部としては記録されず、代わりにビデオ画像として符号化された少なくとも深度データを有するデータの並列シーケンスとして記録される。

【0051】

好ましいカラービデオ符号化手法において、仮想カメラ位置ならびに随意によるアバター位置および／またはゲーム内イベント位置など、カラーデータチャンネル内に符号化されているものとして本明細書において説明される他の情報は、色符号化による深度ビデオ（あるいは、潜在的にはレンダリングされた出力のビデオ、または潜在的には両者（冗長性をもたらすため、あるいは例えばビデオの同期ストリーミングを助けるべく両者において個々のオーバーヘッドを減らし、もしくはバランスさせるため））において別個のデータストリームとして保存され得る。

【0052】

例えば、このデータを、２つのビデオのうちの１つにそれぞれ関連付けられた１つ以上の拡張可能なメタデータプラットフォームストリームなどに格納することができる。あるいは、選択されたビデオ方式は、このデータを収容し得るユーザフィールドを含み得る。

【0053】

したがって、第５のステップＳ３５０において、深度バッファ値シーケンスは、ビデオ画像の第２のシーケンスとして符号化され、第６のステップＳ３６０において、ゲーム内仮想カメラ位置シーケンスは、ビデオ画像の第１および第２のシーケンスの少なくとも一方（典型的には、ビデオ画像の第２のシーケンス）に関連付けられる。

【0054】

さらなる随意によるステップにおいて、ビデオゲームの識別子も、（プレイヤの位置およびユーザの選択などのやはり符号化される随意による追加情報のいずれかと共に）一方または両方のビデオ画像シーケンスに関連付けられる。

【0055】

識別子は、ビデオシーケンスの後の分析を、ビデオシーケンスが記録されたゲームの画像に基づく認識を必要とせずに可能にする。識別子は、単にプレーンテキストでのゲームの名称であってよく、あるいはゲームに関連付けられた固有の発行番号であってよい。簡単にするために、識別子は、例えばゲームの所有権をホストビデオゲームコンソールに関連付けられた管理サービスに登録する目的のためにすでにゲームに関連付けられている識別子に対応することができる。

【0056】

随意により、１つ以上のゲーム内イベントおよびそれらのそれぞれのゲーム内位置が、ビデオゲームの識別子に関連付けられる。

【0057】

次いで、ゲーム内イベント、それらのそれぞれのゲーム内位置、およびビデオゲームの識別子を、随意により、本明細書において後述されるように、そのようなデータをビデオ記録装置として機能する複数のクライアント装置から受信して、データの統計的に有意な特徴を識別するイベント分析器２２０として動作することができるリモートサーバにアップロードすることができる。

【0058】

これに代え、あるいはこれに加えて、ゲーム内イベントおよびそれらのそれぞれのゲーム内位置を、補足画像シーケンスのカラーチャンネルにおいて深度バッファ値シーケンス、ゲーム内仮想カメラ位置シーケンス、およびビデオゲームの識別子と一緒に符号化することにより、このやり方でビデオゲームの識別子と（やはり）関連付けることができる。これにより、ゲーム内イベントの特定のインスタンスを特定のビデオ記録に関連付けることができる。

【0059】

随意により、ビデオゲームの各々の記録された画像シーケンス（ビデオ記録）は、随意によりイベント分析器へと送信されてよい固有のビデオＩＤを有することができる。次いで、イベントデータを、固有のビデオＩＤと関連付けてイベント分析器へと送信することができる。その後に、イベント分析器は、随意により、イベントデータを、統計的分析に加えて、固有のビデオＩＤを送信したビデオ再生装置に送り返すことができる。

【0060】

同様に、随意により、深度バッファ値シーケンスならびに／あるいはゲーム内仮想カメラ位置シーケンスおよび他の随意によるデータのいずれか（プレイヤアバター位置など）も、固有のビデオＩＤと関連付けてイベント分析器にアップロードすることができる。

【0061】

全ての補足データがこのやり方でアップロードされる場合、それは、本明細書において前述したように符号化された並列なビデオ記録として、あるいはこのやり方で符号化するためのサーバ用の別々のデータ要素として、サーバに提供され得る。

【0062】

続いて、ビデオ再生装置がビデオ記録内に見出される固有のビデオＩＤを送信するとき、それは、例えば本明細書において前述したように符号化された並列のビデオ記録として、全ての補足データを受信することができる。

【0063】

これに代え、あるいはこれに加えて、ビデオレコーダは、最初に並列ビデオ記録をオンラインホスト（ＹｏｕＴｕｂｅ（登録商標）またはＴｗｉｔｃｈ（登録商標）など）にアップロードし、ホストされた記録に関連するＵＲＬを取得し、このＵＲＬをゲームのビデオ記録のユーザフィールドに埋め込んだ後に、このビデオ記録をオンラインホストにさらにアップロードすることができる。同様に、ビデオ名として固有のビデオＩＤを使用して並列ビデオ記録をオンラインホストにアップロードした後に、ビデオレコーダは、オンラインホストとの検索語として後に使用されるように、ビデオＩＤをビデオ記録のユーザフィールドに埋め込むことができる。

【0064】

いずれの場合も、固有のビデオＩＤまたはＵＲＬが元のビデオに（例えば、ビデオのユーザフィールドにおいて）関連付けられたままである限りにおいて、本明細書に開示の技術を実行するように構成されたビデオ再生機器は、イベント分析器への要求またはオンラインホストからの並列なホストされたビデオへのアクセスのいずれかによって所望の補足データにアクセスできるが、ビデオ自体は他の点では従来のままであり、これらの技術に関する非標準の補足データをさらに処理および送信する特別な考慮を必要とせずに、従来または過去の機器およびアプリケーションによる処理および送信が可能である。

【0065】

ここで図６を参照すると、ビデオ再生装置２１０Ｂは、以下のビデオ再生方法に従って動作することができる。

【0066】

第１のステップｓ６１０は、ビデオ画像のシーケンスを含むビデオゲームのプレイセッションの第１のビデオ記録を取得することを含む。これは、ビデオファイルのダウンロード、ＹｏｕＴｕｂｅ（登録商標）またはＴｗｉｔｃｈ（登録商標）などのＷｅｂサービス用のビデオストリームのストリーミング、あるいはすでに再生装置のローカルメモリ（ＨＤＤ３７またはＢＤ ＲＯＭ ３６／３６Ａなど）にあるビデオ記録へのアクセスなどの任意の適切な手段によって行われ得る。

【0067】

第２のステップｓ６２０は、深度バッファ値シーケンスを符号化することによって生成された第２のビデオ記録（本明細書におけるＨ．２６５およびＵＣＬの例など）を取得することを含む。

【0068】

第３のステップｓ６３０は、取得されたビデオ記録のうちの少なくとも１つに関連付けられたゲーム内仮想カメラ位置シーケンスを、例えばビデオ記録、またはメタデータ拡張、あるいはユーザフィールドによってもたらされるデータファイルとして取得することを含む。随意により、アバター位置およびゲーム内イベントデータなどの追加のデータも含まれ得る。

【0069】

あるいは、符号化されたデータ、および／または他のデータシーケンス（カメラ位置、アバター位置、イベント位置、など）のうちの１つ以上を含むそのような並列ビデオ記録は、受信されたビデオ記録のデータフィールドから取得されてイベント分析器サーバへと提出される固有のビデオＩＤを参照することによってアクセスされ得、あるいはデータホスティングサービスからのデータにアクセスするために使用される受信されたビデオ記録のデータフィールドから取得されるＵＲＬまたは検索語を参照することによってアクセスされ得る。

【0070】

補足データは、その全体がダウンロードされてもよく、あるいは補足データがジャストインタイムのやり方でもたらされるようにビデオゲームのビデオ記録（さらには、必要に応じて、深度データビデオ）と同じレートでストリーミングされてもよいことを、理解できるであろう。随意により、補足データを、所定のフレームオフセット（例えば、ビデオゲームのビデオ記録に対して予め１、２、３またはそれ以上のフレーム）でストリーミングすることで、ビデオゲームの対応するビデオの受信に備えて処理済み情報を準備し、さらには／あるいは補足データの後続のフレームの受信に依存すると考えられる補足データのための平滑化、平均化、または誤り訂正機能を提供するための充分な処理時間をもたらすことができる。これは、ビデオゲームのビデオ記録をその始まりにおいて所望の所定の数の空白フレームで引き延ばすことによって達成でき、あるいはビデオゲームのビデオ記録の再生を所望の所定の数のフレームだけ遅らせることによって達成することができる。このような処理時間のオフセットを、随意により、ゲーム映像と深度ビデオとを、深度ビデオがゲーム映像より先の所定の１つ以上のフレームであるように立体視ペアとして符号化する場合にも実施することができる。

【0071】

上述したように、随意により、ゲーム内イベントデータをこの段階で取得することによって、後のそのゲーム内イベント自体に応答した増補（例えば、辿った経路またはユーザのコメントの表示）を可能にすることができる。

【0072】

しかしながら、これに代え、あるいはこれに加えて、随意によるさらなるステップＳ６３５が、統計的に有意なゲーム内イベントおよびゲーム内イベント位置を示すデータを取得することを含む。本明細書の他の箇所で説明されるように、このデータは、イベント分析器からファイルとして取得され、あるいは再生時にビデオプレイヤへとストリーミングされる。データは、典型的には、例えばイベントの重要性に関するデータおよび随意による他の統計データ（さらには、典型的には、イベントをどのようにグラフィカルに表すかの選択を助けるためのイベントの種類なども）など、ゲーム内イベント分析データを示すデータを含む。

【0073】

前述したように、どのゲーム内イベントが記録されるかの選択は、設計者によってなされていてよく、クラッシュ、キャラクタの死亡、相手を追い越し、もしくは殴打すること、または実際に相手に追い越され、もしくは殴打されること、ユーザのゲーム内状態の変化、プレイヤの選択、および／またはプレイヤの入力のうちの１つ以上を含むことができる。上述のように、これらのイベント自体に基づく増補が提供され得る。しかしながら、随意により、このデータは、本明細書の他の場所で説明されるように分析され得、次いで、この分析に関連するデータが、イベント位置に関連付けられ得る。

【0074】

データが特定のゲーム内位置を表示するビデオ再生の前にファイルとして後にダウンロードされる場合、イベント位置を、イベント分析データをいつ使用するかを決定するために使用することができる一方で、これに代え、あるいはこれに加えて、データがビデオゲームの記録の再生に同期して後にストリーミングされる場合、イベント分析データを、ビデオゲームの記録がいつイベント位置に達するかに従って、随意により記録におけるその瞬間のカメラ位置または随意によるプレイヤアバター位置からの所定のオフセットに関して、ストリーミングすることができる。

【0075】

次に、第４のステップＳ６４０が、ゲーム内イベント位置に対応する第１のビデオ記録（ゲーム映像）の現在のビデオ画像内の位置を、関連するゲーム内仮想カメラ位置および第２の深度ビデオから得られた復号後の深度バッファ値に応じて計算することを含む。

【0076】

したがって、ビデオゲームの現在表示されているビデオ画像について、ゲーム内またはグローバル座標系を使用するカメラの位置が既知であり、表示ビデオ画像内のピクセルの深度データが既知であり、あるいは関連の深度データから補間できる場合、基本的に、ビデオゲームの現在表示されているビデオ画像内の各ピクセルのゲーム内またはグローバル（Ｘ、Ｙ、Ｚ）座標を決定することができる。したがって、現在表示されているビデオ画像内のゲーム内イベントの位置を決定することができる。

【0077】

とくには、所与のイベントについて、現在の表示ビデオ画像内の対応するＸ、Ｙ座標が、イベントのＺ座標よりも近いＺ座標を有すると決定された場合、基本的に、そのイベントは、ビデオ画像内に描かれた仮想環境内のオブジェクトによって表示ビデオ画像の現在の視点から隠される。

【0078】

この情報を使用して、第５のステップｓ６５０において、ビデオ再生機器は、計算された位置に応じて、ゲーム内イベントのグラフィカル表現で現在のビデオ画像を増補することができる。とくに、ビデオ再生機器は、表示された環境の構成要素が現時点においてゲームイベントの位置とビデオによって提示された視点との間にあるかどうかに基づいて、ゲーム内イベントのグラフィック表現の一部または全部を隠すかどうかを決定できる。例えば、ビデオ再生機器は、ポインタとして機能する四面体などの単純なポリゴンベースのオブジェクトをレンダリングする準備をし、次いで四面体がビデオ画像を記録した仮想カメラの現在の視点から適切に隠されて、ビデオの環境内に自然に埋め込まれているように見えるように、ビデオ画像のＺ値を使用して最終的なレンダリングにおいて四面体についていわゆるｚカリングを実行することができる。したがって、この技術は、深度バッファ値に応じて、ビデオ画像の前景要素によって引き起こされる計算位置でのグラフィック表現の遮蔽を計算することを含むことができる。

【0079】

再生機器は、得られたゲーム内イベントの全てを増補しなくてもよい。例えば、視聴者は、どの種類のイベントを表示するかを切り替えることができ、あるいはイベントしきい値を設定することができる（例えば、スコアにしきい値超を加えるイベントだけを表示する）。同様に、再生機器は、再生設定に応じて、統計的に有意なインイベントまたはサブセットを示し、あるいは統計的に有意なイベントまたはサブセットだけを示すことができる。

【0080】

図７が、図４Ａの典型的なビデオ画像におけるこの増補を示している。この図において、他のプレイヤの経路が示されている（例えば、とくに速いプレイヤおよび遅いプレイヤがそれぞれ赤色または青色の軌跡で示されている）。グレースケールでの再現のために、各々の軌跡の特定の意味は、本発明の理解に必要ではない。とりわけ、拡大部分に見られるように、軌跡データのＺ位置がビデオ画像における特徴のＺ位置を超えるため、軌跡が環境の特徴の背後に消えている。

【0081】

図７には、車両の横滑りやブレーキなどのイベントを示す単純なポリゴンオブジェクト（この場合は、四面体）も示されている。この目的のために、随意により固有のテクスチャを有するより複雑で視覚的に訴求力のある情報量の多いインジケータオブジェクトを使用することができ、典型的には、異なるそれぞれのグラフィック表現が、対応する異なるイベント種類について使用されることを、理解できるであろう。ｘ、ｙ、ｚ位置がインジケータオブジェクトからの所定の方向の線と交差するビデオピクセルの明るさを減少させることによって、ビデオゲーム環境内にインジケータオブジェクトの見かけの影を生じさせ、インジケータオブジェクトの見かけの没入を改善するなど、他のグラフィック効果を適用できることを、理解できるであろう。同様に、ビデオ再生機器は、ビデオの有効解像度または圧縮率を分析し、これに実質的に一致するようにインジケータオブジェクトの有効解像度を（例えば、レンダリングされたオブジェクトをピクセル化し、さらには／あるいはぼかすことによって）低下させることで、インジケータオブジェクトをより背景ビデオ画像の一部であるように見せることができる。

【0082】

随意により、ビデオ再生機器は、ビデオ記録に関連付けられたゲーム内プレイヤ位置シーケンスも取得することができる。やはり前述したように、これは、別個のファイルまたはストリーム内にあっても、あるいは並列画像シーケンス内に符号化されていてもよい。次いで、増補の段階は、ビデオ内の現在のプレイヤ位置と１つ以上のイベント位置との間の関係を表示することを含むことができる。これは、プレイヤ位置とイベント位置との間の距離／カウントダウン値を示し、プレイヤ位置とイベント位置との間に線、矢印、または経路を追加し、プレイヤ位置とイベント位置との間の距離が所定のしきい値の範囲内であるときにのみイベントに関連するインジケータオブジェクトを示し、もしくはフェードインさせる、などの形態をさまざまに取り得る。

【0083】

ここで図８に目を向けると、イベント分析器２２０として動作するサーバは、以下のイベント分析方法に従って動作することができる。

【0084】

第１のステップＳ８１０は、ビデオゲーム識別子ならびに１つ以上の関連のゲーム内イベントおよびそれらのそれぞれのゲーム内位置を複数のビデオゲーム機器（ビデオ記録装置として機能する）からそれぞれ受信することを含む。したがって、本明細書において前述したように、イベント分析器は、ゲーム内イベントおよびゲームにおけるそれらの発生場所を識別する特定のビデオゲームに関するデータを、複数のビデオゲーム機器から受信する。

【0085】

本明細書において前述したように、随意により、イベント分析器は、ビデオ記録装置によって記録された他の補足データのいずれかを、固有のビデオ記録ＩＤと共に受信することができる。

【0086】

次に、第２のステップＳ８２０は、ビデオゲーム識別子に関連付けられたゲーム内イベントの１つ以上の態様、およびそれらのそれぞれのゲーム内位置に関する分析を実行し、統計的に有意なゲーム内イベントを識別することを含む。

【0087】

これは、例えば、同様の種類の複数のイベントの地理空間分析を実行することで、ホットスポット、コールドスポット、ならびにその種類のイベントまたは特定の位置におけるイベントの特定のインスタンスについてのプレイヤの集団の行動を示す他のグループ統計を識別することによって行われ得る。

【0088】

地理空間分析の典型的な形態は、既知のＧｅｔｉｓ－Ｏｒｄ－Ｇｉ＊統計であり得る。この分析は、特徴をそれらの隣人に対して評価するため、類似の特徴のクラスタは、大域的な評価に対して重要性を得、したがってホットスポットとして識別される。必要に応じて、コールドスポットを逆のやり方で識別することができる。

【0089】

イベントについての重要性の側面を、重み付けによって選択することができる。したがって、例えば、レースゲームにおいてユーザがブレーキをかける場所に関連するゲーム空間内の地点の組を、各地点に関連するそれぞれの最終的なラップタイムに従って重み付けすることができる。

【0090】

次いで、分析は、各地点について別々にｚスコア（例えば、やはり大きな重みを有した隣人がどのくらい多いかを反映する）と、この地点が異常であるかどうかを示すｐ値とを生成する。

【0091】

これらの分析を、特定のゲームタイトルについて周期的に、かつ／またはそのゲームについてのより多くのデータの受信に応答して（例えば、必要に応じて、１個、１０個、１００個、１，０００個、１０，０００個、または１００，０００個の追加データセットを受け取った後に）実行することができる。

【0092】

使用される重み付けに応じて、イベントまたはイベント種類の異なる態様を、このやり方で別々に分析できることを、理解できるであろう。例えば、ブレーキのイベントを、ラップタイムまたはラップが完了したかどうか、車種、またはユーザの人口統計に関して分析することができる。

【0093】

この目的のために、セッションデータと呼ぶことができるゲームプレイに関する他の情報、すなわちゲームプレイ自体におけるイベントではなく、難易度設定、プレイヤのスキルレベルまたは使用された装備、レベルの完了後に決定された最終的な結果（時間、スコア、実績、ランキング、など）、などのゲームプレイに関する情報も、ビデオ記録装置によって記録できることを、理解できるであろう。したがって、レベルの一部のみがビデオ記録される場合、ビデオ記録装置は、随意により、たとえビデオ記録自体が終えられた場合でも、ひとたびレベル（または、そのような値を得るための他の論理点）に達すると、そのようなデータをビデオ記録に添えることができる。そのようなセッションデータを、別々のファイルとして記憶することができ、あるいはゲームビデオ記録または並列ビデオ記録内に任意の適切なやり方で符号化することができる。例えば、セッションデータは、並列ビデオ記録の始まりまたは終わりの１つ以上のフレームとして含まれ得る。

【0094】

そのような地理空間分析に代え、あるいはそれに加えて、ユーザ生成イベントマーカまたはユーザＩＤを、特定のアップロードされたイベントデータの組に関連付けることができる。

【0095】

これにより、イベント分析器は、例えばユーザのユーザＩＤに関連付けられたユーザの友人リストにおいて発見されたプレイヤなどの特定の個人に対応するイベントデータを提供することができる。このようにして、プレイヤのより大きな集団の統計的分析に代え、あるいはそれに加えて、再生の視聴者の友人からの個々の選択およびイベントを、ビデオの増補、および／または友人グループだけに限定された地理空間分析として示すことができる。

【0096】

この原理を、例えばｅスポーツチームがパフォーマンスデータの単なるオーバーレイによって競争相手によってポストされたビデオを増補できるよう、ユーザが作成したマーカにより、氏族、チーム、および他の自己特定グループに拡張することも可能である。

【0097】

さらに拡張すると、地理空間分析を、プレイヤの異なる集団について複数回実行して、場所（例えば、全国統計）ならびに年齢および性別などの人口統計に基づく分析を提供することができる。そのような情報は、一般に、各々のユーザＩＤに関連して保持されている登録詳細から入手可能である。

【0098】

いずれにしても、分析に続いて、第３のステップＳ８３０は、ビデオ再生機器から、ビデオゲーム識別子と、ゲーム内仮想カメラ位置およびゲーム内プレイヤ位置のうちの少なくとも一方とを受信することを含む。

【0099】

したがって、ビデオ記録装置からのデータの受信に加えて、イベント分析サーバは、１つ以上のビデオ再生装置からのデータ要求も受信する。要求は、イベント分析器が参照すべきデータセットを認識できるように、ビデオ内のビデオゲームを識別する（これは、例えばイベント分析サーバがただ１つのゲームだけをサポートすることに専念しており、したがってこのサーバへの要求送信行為が関連のビデオゲームおよびデータセットの識別を構成する場合、黙示であり得る）。

【0100】

要求は、ゲーム内仮想カメラ位置およびゲーム内プレイヤ位置のうちの少なくとも一方をさらに含む。データがどのようにビデオ再生装置に送り返されるかに応じて、これは異なる形態をとることができる。レベル全体（あるいは、レベルまたは領域のセグメント／ブランチなど）のデータをダウンロードする場合、レベルの識別は、関連データを取得するのに必要な範囲でカメラ／プレイヤの位置を識別するのに役立つ。

【0101】

一方で、データがストリーミングされている場合、ビデオストリームの表示されたフレーム（または、随意により、アクセスおよびネットワークのレイテンシを考慮した所定の数だけ前のフレーム）に対応するカメラ／プレイヤの現在位置が使用され得る。これは、各ユーザがどのようにゲームをプレイするか、およびどのイベントを経験するか（滑らかな運転ではなく、自動車のクラッシュまたは故障など）に起因して個々のビデオ間で異なる可能性が高く、どのイベントが現在のビデオ表示に関連するのかの予測を難しくしかねないと考えられるビデオ内のイベントの進行を、受信したデータストリームが追跡することを可能にする。

【0102】

レベル毎およびフレーム毎のやり方での位置更新の間に、時間または距離に基づく位置の周期的な更新（例えば、Ｎ秒またはＭメートル毎（ここでＮおよびＭは予め定められた値））など、いくつかの方式を本技術内で採用することができる。随意により、再生中にイベントに遭遇したときに該当のイベントについてのデータを受け取るために対応するカメラまたはプレイヤ位置がイベント分析器へと送信されるように、トリガを、ゲームプレイの最中のイベントの発生時に対応して、ビデオ記録装置によってビデオ自体の中（例えば、フラグまたはユーザフィールドの値）に符号化することができる。

【0103】

いずれにしても、それに応答して、第４のステップＳ８４０において、イベント分析サーバは、受信したビデオゲーム識別子に関連し、（上述のように、レベル、周期的な時間または距離、あるいは現在または差し迫るビデオフレームに対応する）少なくとも１つの受信した位置の所定の距離の範囲内のゲーム内位置を有する１つ以上の識別された統計的に有意なゲーム内イベントに関する分析データを選択する。所定の距離は、イベントのインジケータオブジェクトがあたかもゲーム内レンダリングの一部であるかのように見え得るように、ビデオゲームの描画距離であり得るが、原則として、受信した位置からの任意の所定の距離であり得る。

【0104】

分析データの選択は、１つ以上の原理に従い得る。例えば、イベントにとって最も重要なデータが選択され得る（例えば、左または右に曲がる選択肢がユーザに提示され、右に曲がるプレイヤの９５％がレベルをクリアする一方で、左に曲がるプレイヤの９５％がレベルをクリアできない場合、決定イベントのこの態様は、自動車の６０％が右に曲がり、オートバイの６０％が左に曲がるかどうかよりも重要である）。あるいは、ビデオ内のプレイヤの見かけの選択／イベントに関するデータが、優先的に選択され得る。同様に、最も一般的なイベント、最も一般的ではないイベント、または追い越しではなくクラッシュなどの好ましいイベントを探すなど、ビデオの視聴者によって設定された好みに関するデータが選択され得る。

【0105】

最後に、第５のステップＳ８５０において、イベント分析サーバは、ゲーム内イベント分析データおよびそのゲーム内位置を示すデータを、ビデオ再生装置に送信する。次に、前述のように、ビデオ再生装置は、図７に示したように、そのデータを使用してビデオ用の増補レイヤを構築することができる。

【0106】

ゲーム内イベントの位置はそれ自体がゲームの規則および環境によって制約されるので、イベント分析サーバによって受信された累積イベントデータは、そのゲームに矛盾しない（例えば、追い越しに関連する全てのイベントは、レースのコースまたは少なくともゲーム内で追い越しが合法である位置に対応する位置にある）ことを、理解できるであろう。結果として、イベント分析データに関連付けられた場所および現在のビデオ内のカメラ／プレイヤに関連付けられた場所が、（図７のように）互いに矛盾せず、かつビデオ内のゲーム環境に矛盾せず、したがってたとえイベント分析サーバおよびビデオ再生装置がゲーム内の実際の仮想環境についての明確な知識／モデルを持ち得なくても、自然に相互作用するように見える。

【0107】

原則として、ビデオゲームコンソールが、ビデオ記録装置およびビデオ再生装置の両方として動作することができ、したがってユーザが、自身のプレイを、上に重ね合わせられる統計的イベントデータの恩恵を受けつつほぼ即座にレビューできることを、理解できるであろう。さらに、ビデオゲームコンソールは、原則として、イベント分析サーバとしても動作することができ、例えばプロのｅスポーツ選手などの一人のユーザによるプレイの履歴記録を分析して、プレイの傾向を識別するのを助けることができる。

【0108】

上記の技術の変種も想定され得る。

【0109】

例えば、ビデオ圧縮がカラービット深度を効果的に減少させることが一般的である。これにより、色のわずかに平坦な領域が生じるが、ほとんどのビデオへの影響は限定的である。しかしながら、カラーチャンネルが深度データを符号化するために使用されている場合、この圧縮は深度データに大きな影響を及ぼし得る。

【0110】

考えられる解決策として、チャンネル内の上位のビットだけ（例えば、８ビットのチャンネルにおける６ビット、１０ビットのチャンネルにおける８ビット、あるいは１２０ビットのチャンネルにおける１０ビットだけ）を使用することが挙げられる

【0111】

別の解決策は、１６ビットの深度値が、圧縮によって影響される下位ビットを別々に有する２つの８ビットのチャンネルにまたがって符号化される場合に、実際には、深度値の中位ビットが損なわれる可能性があることに注目する。しかしながら、ビットが２つのカラーチャンネルの間で交互にされる場合（例えば、ビット１（深度）がビット１（緑色）になり、ビット２（深度）がビット１（青色）になり、ビット３（深度）がビット２（緑色）になり、ビット４（深度）がビット２（青色）になり、以下同様）には、深度データの下位ビットだけが、このやり方での圧縮の影響を受けると考えられる。

【0112】

受信した分析データの使用は、ビデオ撮影されたゲームのスタイルに適するようにさまざまであってよい。例えば、ゲーム内の特定の時点においてプレイヤが人気のある選択をしたか、あるいは人気のない選択をしたかを単に説明する解説を提供することが、いくつかの場合に適用可能であり得る一方で、多数のプレイヤの位置に関する大量のグラフィック的に複雑な統計が、他のゲームにおいては適切であり得る。

【0113】

同様に、（ビデオ再生装置自体にはゲームがインストールされておらず、ビデオ再生装置がゲームについての情報またはゲームのためのアセットを有していないかもしれないため）ビデオ再生装置がビデオ内の特定のゲームにグラフィック的に一致してイベントを強調表示するグラフィックアセットを有するように、イベント分析サーバが、受信ビデオゲーム識別子に応答してグラフィックデータ（インジケータ幾何学形状、テクスチャ、など）を提供することができる。

【0114】

説明は、深度データの並列ビデオ記録の使用に言及しており、カメラおよびイベントデータなどもその並列ビデオ記録のデータチャンネル内に符号化されることを示唆しているが、原理的に、そのようなデータは、データの一部または全てがゲームプレイのビデオ記録に直接含まれるように、ユーザデータフィールドをサポートするビデオコーデックのそのようなフィールドに含まれ得る。これは、ビデオが本技術に対応するように（例えば、そのようなデータフィールドを保持し、あるいはそれらに劣化を伴う圧縮を適用しないことによって）構成された非レガシーサービスによってホストされる場合に選択肢であり得る。

【0115】

本明細書に記載の技術は、他のプレイヤが辿った経路（例えば、図７に示されるとおり）および他の情報を、これらを適切な深度で表示すべく深度バッファおよびゲーム内仮想カメラ位置を使用して、レースのコースまたは任意の他の横断され得る仮想環境に重ねて表示することを可能にする。

【0116】

これらの技術が、いくつかの用途に関してゲームプレイのビデオ記録の増補を容易にすることができることを、理解できるであろう。例えば、解説および分析を提供するグラフィックスを、ｅスポーツの報道の上に重ねることができる。

【0117】

他の例として、ユーザがユーザのビデオの再生に仮想オブジェクトを追加できることが挙げられる。仮想オブジェクトは、例えば、マーカであってよく、あるいはテキスト付きの３Ｄ吹き出しの形態のメッセージであってよい。典型的には、ユーザは、仮想オブジェクトまたはグラフィック効果が提供される事後のゲーム内イベントを定義する。

【0118】

例えば、図９に示されるように、レースのコースを完走するプレイヤのビデオを見ているときに、視聴者は、プレイヤがジャンプした地点に「すばらしいジャンプ！（ａｗｅｓｏｍｅ ｊｕｍｐ！）」などのメッセージを残すことができ、あるいはジャンプのピーク高さを示すことができる。そのようなイベントを示すために選択されたオブジェクトがそれ自体３Ｄである場合、それらはビデオ内の環境に矛盾しない位置および向きを有し、したがって、それらはあたかも元々取り込まれた映像の一部のように見える。一例は、図１０に示されるように、隠された宝物を指す元のプレイヤまたは後のビデオの視聴者によって設定された矢印である。

【0119】

別の例において、プレイヤまたは視聴者は、「デスゾーン（ｄｅａｔｈ ｚｏｎｅ）」オプションを表示するという選択肢を有し得る。「デスゾーン」は、仮想環境内の空間の影付きの部分（図１１においてハッチングされた領域によって示されている）として表示され、多くのプレイヤが殺されたマップ内の領域を表す。ゲームプレイの最中に、深度ビデオに格納された深度データを使用して、デスゾーンを、環境の現在のビューに関して正しい深度で現れるようにレンダリングすることができる。これは、（例えば、ｅスポーツにおいて）そのプレイヤがゲームをプレイしているのを見ている観客によってオンにされ得る。

【0120】

別の例においては、図７に関連して示したやり方と同様のやり方で、仮想オブジェクトは、成功したプレイヤが辿った経路であり得る。別の例において、仮想オブジェクトは、例えばゲーム内の敵の位置を示すインジケータであり得る。さらに別の例において、仮想オブジェクトは、武器の有効範囲を示すことができる（図１２において、遠方への武器の有効性を示す色分けされたストリップとして見て取ることができる）。ｅスポーツの観客は、例えば、プレイヤが殺されたときに敵がどこにいるのかを確認するために、これらをオンにすることを望むかもしれない。

【0121】

したがって、原理的には、ビデオを増補する目的でゲーム内のイベントをプレイの最中に記録することができる一方で、より一般的には、ゲームイベント、したがって仮想オブジェクトまたはグラフィック効果を、（オフラインまたはライブで）記録が生成された後に記録に関連付け、プレイの最中に記録されたゲーム内イベントと同一のやり方で、別の可能な増補のデータ源または層として取り扱うことができることを、より一般的に理解できるであろう。

【0122】

したがって、ビデオ、深度、およびカメラ位置の並列データセットとの互換性を有するビデオビューアは、元のプレイヤによって記録が行われて出力された後に、ユーザによる現在の画像におけるゲームイベントの配置場所の選択に基づいて、追加のゲーム内イベント（コメント、オブジェクト、または領域のうちの１つ、あるいは上記の他のオーバーレイなど）を定義すべき場所を計算でき、このｘ、ｙ位置が、それぞれのビデオ画像内のカメラ視点からの深度値（距離）に対応し、したがって追加のゲーム内イベントを関連のデータにおいて（他のゲーム内イベントデータと同様のやり方で）カメラ自体と同じ基準点に対して定義することを可能にすることを、理解できるであろう。

【0123】

本明細書では「ビデオ記録」および「ビデオ画像のシーケンス」に言及しているが、これらが（例えば、ウェブベースのホストまたはストリーミングサーバにアップロードされた）事前記録されたビデオも、（やはり、例えばストリーミングサーバにアップロードされた）ライブビデオも包含することを、理解できるであろう。いずれの場合でも、得られた映像を増補する能力は、ゲーム映像のビデオ記録と、深度データおよびカメラデータの並列記録との組み合わせに基づく。

【0124】

したがって、例えばＰＳ ＮＯＷ（登録商標）などのストリーミングゲームサービスは、ライブゲーム内で仮想オブジェクトをレンダリングするために使用することができるカラービデオおよび深度符号化ビデオの両方を出力することができる。例えば、ローカルコンソールにおける第２のプレイヤが、第１のプレイヤの経験を増補および／または視覚的に説明することによって参加することができる。

【0125】

上記の方法を、ソフトウェア命令あるいは専用ハードウェアの包含または置換によって必要に応じて適切に構成される従来からのハードウェア上で実行できることを、理解できるであろう。

【0126】

したがって、従来からの同等の機器の既存の部分への必要な適応を、フロッピー（登録商標）ディスク、光ディスク、ハードディスク、ＰＲＯＭ、ＲＡＭ、フラッシュメモリ、あるいはこれらの記憶媒体または他の記憶媒体の任意の組み合わせなどの非一時的な機械可読媒体に記憶されたプロセッサ実行可能命令を含むコンピュータプログラム製品の形態で実施でき、あるいはＡＳＩＣ（特定用途向け集積回路）またはＦＰＧＡ（フィールドプログラマブルゲートアレイ）または従来からの同等の機器の適応において使用するために適した他の設定可能回路として、ハードウェアにて実現することができる。さらに、そのようなコンピュータプログラムを、Ｅｔｈｅｒｎｅｔ、無線ネットワーク、Ｉｎｔｅｒｎｅｔ、あるいはこれらのネットワークまたは他のネットワークの任意の組み合わせなどのネットワーク上のデータ信号を介して送信することができる。

【0127】

したがって、ビデオ記録装置のためのハードウェアは適切なソフトウェア命令の下で動作するＰｌａｙＳｔａｔｉｏｎ ４などの従来からのコンピューティングデバイスであってよく、そのようなコンピューティングデバイスは、ビデオゲームによって出力されるビデオ画像の第１のシーケンスをビデオストレージ手段（例えば、ＨＤＤ３７）に記録するように構成され、ビデオゲームによって使用された深度バッファのための深度バッファ値のシーケンスを記録するように（例えば、適切なソフトウェア命令によって）構成され、ビデオ画像の生成に使用されたゲーム内仮想カメラ位置のシーケンスを記録するように（例えば、適切なソフトウェア命令によって）構成され、１つ以上のゲーム内イベントおよびそれらのそれぞれのゲーム内位置を記録するように（例えば、適切なソフトウェア命令によって）構成された記録プロセッサ（例えば、適切なソフトウェア命令の下で動作するＣＰＵ２０Ａ）と、深度バッファ値のシーケンスを符号化するビデオ画像の第２のシーケンスを生成するように構成されたビデオ生成プロセッサ（例えば、やはり適切なソフトウェア命令の下で動作するＣＰＵ２０Ａ）と、ゲーム内仮想カメラ位置のシーケンスをビデオ画像の第１および第２のシーケンスの少なくとも一方に関連付けるように（例えば、適切なソフトウェア命令によって）構成された関連付けプロセッサとを備える。いずれの場合も、適切なソフトウェア命令は、本明細書に記載の方法および技術を必要に応じて実行する。

【0128】

同様に、ビデオ再生装置のためのハードウェアは、適切なソフトウェア命令の下で動作するＰｌａｙＳｔａｔｉｏｎ ４などの従来からのコンピューティングデバイスであってよく、そのようなコンピューティングデバイスは、ビデオ画像のシーケンスを含むビデオゲームプレイセッションの第１のビデオ記録を取得するように構成され、深度バッファ値のシーケンスを符号化することによって生成された第２のビデオ記録を取得するように（例えば、適切なソフトウェア命令によって）構成され、前記取得されるビデオ記録の少なくとも一方に関連付けられたゲーム内仮想カメラ位置のシーケンスを取得するように構成された再生プロセッサ（例えば、適切なソフトウェア命令の下で動作するＣＰＵ２０Ａ）と、ゲーム内仮想カメラ位置をイベント分析器へともたらすように構成され、統計的に有意なゲーム内イベントおよびゲーム内イベント位置を表すデータを取得するように（例えば、適切なソフトウェア命令によって）構成された分析プロセッサ（例えば、適切なソフトウェア命令の下で動作するＣＰＵ２０Ａ）と、関連付けられたゲーム内仮想カメラ位置および復号された深度バッファ値に応じて、ゲーム内イベント位置に対応する第１のビデオ記録の現在のビデオ画像における位置を計算するように構成された位置計算プロセッサ（例えば、適切なソフトウェア命令の下で動作するＣＰＵ２０Ａ）と、計算された位置に応じて統計的に有意なゲーム内イベントのグラフィック表示で現在のビデオ画像を増補するように構成された増補プロセッサ（例えば、適切なソフトウェア命令の下で動作するＣＰＵ２０Ａおよび／またはＧＰＵ２０Ｂ）と、を備える。やはり、いずれの場合も、適切なソフトウェア命令は、本明細書に記載の方法および技術を必要に応じて実行する。

【0129】

最後に、同様に、イベント分析器は、適切なソフトウェア命令の下で動作するサーバまたはＰｌａｙＳｔａｔｉｏｎ ４などの従来からのコンピューティングデバイスであってよく、そのようなコンピューティングデバイスは、受信部（例えば、適切なソフトウェア命令の下でＣＰＵ２０Ａと協力して動作するＥｔｈｅｒｎｅｔ（登録商標）ポート３２）と、分析プロセッサ（例えば、適切なソフトウェア命令の下で動作するＣＰＵ２０Ａ）と、選択プロセッサ（例えば、適切なソフトウェア命令の下で動作するＣＰＵ２０Ａ）と、送信部（例えば、適切なソフトウェア命令の下でＣＰＵ２０Ａと協力して動作するＥｔｈｅｒｎｅｔ（登録商標）ポート３２）とを備え、受信部は、ビデオゲーム識別子ならびに１つ以上の関連付けられたゲーム内イベントおよびそれらのそれぞれのゲーム内位置を複数のビデオ記録装置からそれぞれ受信するように構成され、分析プロセッサは、ビデオゲーム識別子に関連付けられたゲーム内イベントおよびそれらのそれぞれのゲーム内位置の１つ以上の側面について分析を実行し、統計的に有意なゲーム内イベントを識別するように構成され、受信部は、ビデオゲーム識別子ならびにゲーム内仮想カメラ位置およびゲーム内プレイヤ位置の少なくとも一方をビデオ再生装置から後に受信するように構成され、選択プロセッサは、受信されたビデオゲーム識別子に関連付けられ、少なくとも１つの受信された位置の所定の距離の範囲内のゲーム内位置を有する１つ以上の識別された統計的に有意なゲーム内イベントを選択するように構成され、送信部は、ゲーム内イベントおよびそのゲーム内位置を表すデータをビデオ再生装置へと送信するように構成される。やはり、いずれの場合も、適切なソフトウェア命令は、本明細書に記載の方法および技術を必要に応じて実行する。

【0130】

前述のように、ビデオ記録装置、ビデオ再生装置、およびイベント分析器は、３つの別々の装置、または任意の組み合わせの２つの別々の装置、または３つの態様の全てを備える単一の装置であってよい。

【0131】

したがって、システム（２００）は、本明細書に記載のビデオ記録装置と、ビデオ再生装置およびイベント分析器のうちの１つ以上とを、別々の装置として含むことができ、あるいは単一の装置内に含むことができる。原理的に、システムは、同様に、本明細書に記載のビデオ再生装置をイベント分析器と一緒に備えることができる。

【0132】

上記の技術および装置を使用して、ユーザが自身のゲームプレイを記録し、ＹｏｕＴｕｂｅ（登録商標）およびＴｗｉｔｃｈ（登録商標）などの公衆のアクセスが可能なホスト（あるいは、潜在的には、或る種のビデオゲームコンソールに関連付けられたネットワークの管理者に属するホストなどの私的なホスト）にアップロードでき、後に、本明細書に記載の技術を必要に応じて実行する機器またはアプリケーションを使用するそのビデオの視聴者が、他のプレイヤがどのようにゲームをプレイしたかに関する情報で増補されたゲームをプレイするユーザのビデオを見ることができ、したがってゲームにおけるユーザの決定、成功、および失敗の背景、ならびにより豊かな視聴体験を生成する機能が提供されることを、理解できるであろう。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】