JP2023014990A - ビデオ録画および再生システムおよび方法 - Google Patents

Abstract

【課題】ビデオ録画および再生システムおよび方法を提供する。【解決手段】ビデオ録画方法であって、ヘッドマウントディスプレイの第１のユーザの仮想環境の視野を第１の解像度でレンダリングするステップと、第１のユーザの視野外の仮想環境の画像を第１の解像度より低い第２の解像度でレンダリングするステップと、レンダリングされた視野を第１のユーザに表示するために出力するステップと、組み合わされたレンダリングを第２のユーザが続けて見るためにビデオとして録画するステップと、を含む。【選択図】図１５

Description

本開示は、ビデオ録画および再生システムおよび方法に関する。

Ｔｗｉｔｃｈ（登録商標）のような従来のビデオゲームストリーミングシステムおよびＹｏｕＴｕｂｅ（登録商標）やＦａｃｅｂｏｏｋ（登録商標）のようなビデオホスティングプラットフォームにより、ビデオゲームのプレーヤーは、これらのゲームのプレーを広く視聴者に配信できるようになった。

ビデオゲームをプレーすることと、これらのゲームプレーのビデオ録画を視聴することとの大きな違いは、体験の受動的特徴にある。これは、ゲーム中の決断の点でも、プレーヤーの視点（これは例えばプレーヤーの入力で決められる）の点でも然りである。

ゲームがＶＲまたはＡＲゲームの場合、後者の問題はより深刻である。この場合、通常はゲームのプレーヤーは、少なくとも部分的には、自分の頭または目の動きに基づいて視点を決める。従ってこうしたＶＲまたはＡＲゲームのライブまたは録画のストリームを見ているとき、録画された画像は、視聴者ではなく配信者の頭および／または目の動きを追跡しているだろう。これにより視聴者の気分が悪くなる可能性があり、配信者と違う方向を見たいと望む視聴者がイライラすることにもつながる。

本開示は、こうした問題を緩和または軽減することを目的とする。

本発明の様々な態様および特徴は、添付の請求項および明細書の文脈の中で定義される。本発明は、少なくとも第１の態様ではビデオ録画方法を含み、別の態様ではビデオ録画の配信方法を含み、さらに別の態様ではビデオ録画の視聴方法を含み、さらに別の態様ではビデオ録画システムを含み、さらに別の態様ではビデオ再生システムを含む。

上記の一般的な説明および以下の詳細な説明は、いずれも発明の例示であって限定ではないことが理解される。

添付図面を参照して以下の詳細な説明を読むことにより、本開示およびその多くの利点の完全な理解が得られるだろう。
ユーザに装着されたＨＭＤの模式図である。 ＨＭＤの模式的な平面図である。 ＨＭＤによる仮想画像の形成を示す模式図である。 ＨＭＤで使われる別のタイプのディスプレイの模式図である。 立体画像のペアの模式図である。 ＨＭＤの模式的な平面図である。 ニアアイ追跡構成の模式図である。 リモート追跡構成の模式図である。 視線追跡環境の模式図である。 視線追跡システムの模式図である。 人間の目の模式図である。 人間の視力のグラフの模式図である。 中心窩レンダリングの模式図である。 中心窩レンダリングの模式図である。 解像度の変化を示す模式図である。 解像度の変化を示す模式図である。 本発明の実施の形態に係る拡張レンダリングスキームの模式図である。 本発明の実施の形態に係る拡張レンダリングスキームの模式図である。 本発明の実施の形態に係るビデオ録画方法のフロー図である。 本発明の実施の形態に係るビデオ再生方法のフロー図である。

本明細書は、ビデオ録画および再生のシステム、それらの方法を開示する。以下の説明では、本発明の実施の形態の完全な理解を目的に、いくつかの特定の詳細を示す。しかしこれらの特定の詳細の使用は、本発明の実施のために必須でないことは当業者に明らかである。逆に明確化のため、必要に応じて、当業者に既知の特定の詳細は省略することもある。

以下、参照する図面において、同一または類似の構成には同様の符号を付す。図１において、ユーザ１０は、ユーザの頭３０にＨＭＤ２０（一例では通常のヘッドマウント可能な装置だが、他の例ではオーディオ・ヘッドホンまたはヘッドマウント可能な光源も含む）を装着している。ＨＭＤは、フレーム４０（この例では、リアストラップおよびトップストラップで形成される）と、ディスプレイ部分５０と、を備える。

選択的にＨＭＤは、関連するヘッドホントランスデューサまたはイヤーピース６０（これは、ユーザの左右の耳７０にフィットする）を有する。イヤーピース６０は、外部音源（これは、ディスプレイにビデオ信号を与えるビデオ信号源と同じものであってもよい）から与えられるオーディオ信号を再生する。

動作中、ディスプレイのためのビデオ信号はＨＭＤによって与えられる。これは、外部のビデオ信号源８０（例えばビデオゲーム機やパーソナルコンピュータなどのデータ処理装置など）によって与えられてもよい。その場合、信号は、有線または無線接続８２によってＨＭＤに送信されてもよい。好適な無線接続の例は、Ｂｌｕｅｔｏｏｔｈ（登録商標）接続を含む。イヤーピース６０のためのオーディオ信号が、同じ接続によって伝達されてもよい。同様にＨＭＤからビデオ（オーディオ）信号源へ送られる任意の制御信号が、同じ接続によって伝達されてもよい。さらに電源８３（１つ以上のバッテリーを含んでもよく、および／または主電源コンセントに接続されていてもよい）が、ケーブル８４によってＨＭＤに接続されてもよい。

このように図１の構成は、視聴者の頭にマウントされるフレームと、視線表示位置に対してマウントされるディスプレイ要素と、を備えたヘッドマウント可能なディスプレイシステムの例を与える。フレームは、１つまたは２つの視線表示位置を定義する。視線表示位置は、使用中、視聴者の目の前に配置される。ディスプレイ要素は、ビデオ信号源から視聴者の目に向けて、ビデオ表示信号の仮想画像を与える。図１はＨＭＤの一例を示すにすぎず、他の形態も可能である。例えばＨＭＤは、従来の眼鏡に近いフレームを用いてもよい。

図１の例では、ユーザの左右の目ごとに別々のディスプレイが与えられる。図２は、これを実現する様子の模式的な平面図である。図２は、ユーザの目の位置１００およびユーザの鼻の相対位置１１０を示す。ディスプレイ部分５０は、概略的には、周辺光をユーザの目から遮断するための外部シールド１２０と、一方の目が見るディスプレイを他方の目が見ないようにするための内部シールド１３０と、を備える。ユーザの顔に関し、外部シールド１２０および内部シールド１３０は、それぞれの目に関する２つの区画１４０を形成する。それぞれの区画内に、ディスプレイ要素１５０と、１つ以上の光学要素１６０と、が与えられる。図３に、ディスプレイ要素および光学要素で形成される光路（これによりユーザに表示が与えられる）を示す。

図３を参照すると、ディスプレイ要素１５０は表示画像を生成する。（この例では）表示画像は光学要素１６０（模式的に１つの凸レンズで示されるが、複合レンズ等であってもよい）によって屈折される。その結果、仮想画像１７０が生成される。仮想画像１７０は、ユーザにとっては、ディスプレイ要素１５０によって生成された実像より大きく、遥かに遠くにあるように見える。図３では、実線（例えば線１８０）は実際の光線を表し、点線（例えば線１９０）は仮想的な光線を表す。

図４に代替的な構成を示す。ここではディスプレイ要素１５０および光学要素２００は共同して、ミラー２１０に投射される画像を与える。ミラー２１０は、画像をユーザの目の位置２２０に向けて反射する。ユーザは、仮想画像がユーザの前方位置２３０にあり、ユーザから適度に離れていると感じる。

ユーザの左右の目ごとに別々のディスプレイが与えられると、立体画像を表示できる。図５に、左右の目に表示するための立体画像のペアの例を示す。

ＨＭＤをバーチャルリアリティ（ＶＲ）システムなどに使った場合、ユーザの視点は、ユーザがいる空間に関する動きを追跡する必要がある。

追跡には、頭部追跡および／または視線追跡を使ってもよい。頭部追跡は、ＨＭＤの動きを検出し、表示された画像の見かけの視点を変えることによって行われる。その結果、見かけの視点は動きを追跡する。動きの追跡には、ハードウェアモーション検知器（例えば加速度計またはジャイロスコープなど）や、ＨＭＤを撮影可能な外部カメラおよびＨＭＤに取り付けられた外向きカメラを含む任意の好適な構成を使ってもよい。

視線追跡に関し、図６ａおよび図６ｂに２つの可能な構成を示す。

図６ａは視線追跡構成の一例を示す。この構成では、ＨＭＤ内にカメラが配置される。これにより、ユーザの目の画像が近距離からキャプチャされる。これはニアアイ追跡またはヘッドマウント追跡と呼ばれることもある。この例では、ＨＭＤ４００が（ディスプレイ要素６０１とともに）、カメラ６１０を与えられる。これらのカメラの各々は、１つ以上のそれぞれの画像を直接キャプチャするように配置される。図では、眼球追跡カメラの提供可能な配置の例として、４つのカメラ６１０が示されている。しかし典型的には、１つの目ごとにカメラが１つあることが望ましい。選択的には、通常通り目の動きが一定の場合は、片方の目だけが追跡されてもよい。目の画像をキャプチャするための光路内にレンズ６２０が含まれる形で、こうしたカメラが１つ以上配置されてもよい。カメラ６３０を用いたこうした配置の一例が図示されている。レンズが光路内に含まれることの利点の一例は、ＨＭＤのデザインに与える物理的制約を簡略化できることにある。

図６ｂに視線追跡構成の一例を示す。ここでは、ユーザの目の画像を間接的にキャプチャする形でカメラが配置される。図６ｂは、ディスプレイ６０１および視聴者の目との間に配置されたミラー６５０を含む。明確化のために、この図ではレンズなどの追加的な光学要素はすべて省いている。このような構成では、ミラー６５０は、部分的に光を透過するものが選択される。すなわちミラー６５０は、ユーザがディスプレイ６０１を見るとき、カメラ６４０がユーザの目の画像を撮影できるようなものが選択される。これを実現する方法の１つとして、ＩＲ波長の光は反射するが、可視光は透過するミラー６５０を採用することがある。これにより、追跡に使われるＩＲ光はユーザの目からカメラ６４０に向けて反射される一方、ディスプレイ６０１が発した光は干渉されずにミラー内を透過する。このような構成の利点の１つに、ユーザの視野外にカメラを容易に配置できることがある。さらに、（反射のおかげで）カメラが実質的にユーザの目とディスプレイとの間の軸に沿った位置から画像をキャプチャするので、眼球追跡の精度が改善される。

代替的には、眼球追跡構成は、上記のヘッドマウント型またはニアアイ型でなくてもよい。例えば図７は、ユーザの画像を遠くからキャプチャするようにカメラが配置されたシステムの模式図である。図７では、カメラ７００のアレイが与えられ、ユーザ７１０の複数の画像を与える。これらのカメラは、好適な方法を用いて、少なくともユーザ７１０の目が焦点を結ぶ方向を特定するための情報をキャプチャするように配置される。

図８は、眼球追跡プロセスが行われる環境の模式図である。この例では、ユーザ８００は、処理ユニット８３０（例えばゲームコンソール）に関連するＨＭＤ８１０と、処理を制御するためのコマンドを入力する周辺機器８２０と、を使っている。ＨＭＤ８１０は、図６ａまたは図６ｂに例示される構成に従って眼球追跡を実行してもよい。すなわちＨＭＤ８１０は、ユーザ８００の一方の目または両方の目の画像をキャプチャするための１つ以上のカメラを備えてもよい。処理ユニット８３０は、ＨＭＤ８１０に表示するコンテンツを生成してもよい。しかしいくつかの（またはすべての）表示コンテンツは、ＨＭＤ８１０内の処理ユニットで生成されてもよい。

図８の構成は、ＨＭＤ８１０の外部に配置されたカメラ８４０と、ディスプレイ８５０と、を備える。場合によっては、例えば身体の動きや頭の方向を特定するためにＨＭＤ８１０が使われ、ユーザ８００の追跡を行うためにカメラ８４０が使われてもよい。代替的な構成では、キャプチャされたビデオ内の動きに基づいてＨＭＤの動きを決めるために、カメラ８４０が外向きにＨＭＤに取り付けられてもよい。

キャプチャされたユーザ８００の目の画像から追跡情報を生成するのに必要な処理は、ＨＭＤ８１０によってその場で実行されてもよい。あるいは、キャプチャされた画像または１つ以上の検出結果は、処理のための外部デバイス（例えば処理ユニット８３０）に送信されてもよい。前者の場合、ＨＭＤ８１０は処理結果を外部デバイスに出力してもよい。

図９は、１つ以上の眼球追跡および頭部追跡の処理を実行するシステムの模式図である。このシステムでは、例えば図８で説明した処理が実行される。システム９００は、処理デバイス９１０と、１つ以上の周辺機器９２０と、ＨＭＤ９３０と、カメラ９４０と、ディスプレイ９５０と、を備える。

図９に示されるように、処理デバイス９１０は、１つ以上の中央処理ユニット（ＣＰＵ）９１１と、グラフィック処理ユニット（ＧＰＵ）９１２と、ストレージ（ハードドライブその他の任意の好適なストレージメディア）９１３と、入力／出力９１４と、を備える。これらのユニットは、パーソナルコンピュータの形で与えられてもよいし、その他の任意の好適な処理デバイスの形で与えられてもよい。

例えばＣＰＵ９１１は、１つ以上のカメラから得られた１つ以上のユーザの目の入力画像から、またはユーザの視線方向を表すデータから、追跡データを生成するように構成されてもよい。これは、例えば遠隔デバイスによるユーザの目の処理画像から得られたデータであってもよい。追跡データが別の場所で生成されていれば、処理デバイス９１０はこうした処理をする必要がないことは言うまでもない。

代替的にまたは追加的に、上記のように頭の動きを追跡するために、（視線追跡カメラ以外の）１つ以上のカメラが使われてもよいし、ＨＭＤ内の加速度計のような任意の好適なモーショントラッカーが使われてもよい。

眼球追跡または頭部追跡の対象となるユーザに表示するコンテンツを生成するために、ＧＰＵが配置されてもよい。

取得される追跡データに応じて、表示コンテンツ自体が改良されてもよい。その一例として、中心窩レンダリング技術を用いた表示コンテンツ生成がある。もちろんこうした表示コンテンツの生成処理は、別の方法で行われてもよい。例えばＨＭＤ９３０は、眼球追跡および／またはヘッドモーションデータを用いて表示コンテンツを生成するオンボードＧＰＵであってもよい。

任意の好適な情報を記憶するストレージ９１３が与えられてもよい。一例としてこうした情報は、プログラムデータ、表示コンテンツ生成データ、眼球追跡および／または頭部追跡モデルデータを含む。こうした情報は、遠隔サーバに記憶されることもある。すなわちストレージ９１３は、ローカルにあっても遠隔にあってもよく、これらの組み合わせであってもよい。

このようなストレージは、生成された表示コンテンツを記録するのに使われてもよい。

処理デバイス９１０に適した通信を行うために、入力／出力９１４が配置されてもよい。一例としてこうした通信は、表示コンテンツのＨＭＤ９３０および／またはディスプレイ９５０への送信、眼球追跡データ、ヘッドモーションデータおよび／またはＨＭＤ９３０やカメラ９４からの画像の認識、１つ以上の遠隔デバイスとの通信（例えばインターネット経由）を含む。

周辺機器９２０が与えられてもよい。これによりユーザは、処理を制御するために、または生成された表示コンテンツと相互作用するために、処理ユニット９１０に入力を与えることができる。周辺機器９２０はボタン等であってもよく、入力として使えるジェスチャーを実現するモーショントラックを介したものであってもよい。

ＨＭＤ９３０は、図２の対応する要素と同様に構成されてもよい。カメラ９４０およびディスプレイ９５０は、図８の対応する要素と同様に構成されてもよい。

図１０を参照すると、人間の目の構造は一様でないことが分かる。すなわち目は完全な球面ではない。異なる目のパーツは異なる特徴を持つ（例えば屈折率や色が異なる）。図１０は、典型的な目１０００の構造を簡略化した側面図である。明確化のためこの図では、目の動きを制御する筋肉などの特徴は省いている。

目１０００は、球面に近い構造で形成され、水溶液１０１０で満たされる。網膜１０２０は目１０００の前面に形成される。視神経１０３０は、目１０００の後部で接続される。目１０００に入射する光によって網膜上に画像が形成される。視覚情報を伝達する信号が、網膜１０２０から脳に視神経１０３０を介して送信される。

目１０００の前面を参照すると、強膜１０４０（通常は白目と呼ばれる）が虹彩１０５０を取り巻いている。この虹彩１０５０は、瞳１０６０の大きさを制御する。瞳１０６０は、目１０００に光が入射するときの開口である。虹彩１０５０および瞳１０６０は、角膜１０７０によって覆われている。角膜１０７０は透明な層であり、目１０００に入射する光を屈折する。目１０００はまた、虹彩１０５０の後に位置するレンズ（図示せず）を備える。このレンズは、目１０００に入射する光の焦点を調整するように制御される。

目の構造には視力の高い領域（中心窩）があり、この中心窩の両側に向けて視力が急速に低下する。図１１は、この様子を曲線１１００で示す。図１１の中心付近のピークが、中心窩領域に相当する。領域１１１０は「盲点」である。盲点は視力が喪失する領域である。これは、この領域で視神経が網膜に接続することによる。周辺部（すなわち視角が中心窩から大きく外れた領域）は、色や細部に対してあまり敏感でなく、動きを検知するために使われる。

上記のように、中心窩レンダリング（または中心窩適応レンダリング）は、中心窩付近の比較的小さい領域（およそ２．５度から５度）で有効であり、この領域外では視力は急速に低下する。

通常の中心窩レンダリング技術は、典型的には複数のレンダーパスを必要とする。これは、異なる解像度で画像フレームを複数回レンダリングできるようにするためである。レンダリング結果はその後合成され、１つの画像フレーム内に解像度の異なる領域が作成される。複数のレンダーパスを使うと、大きな処理オーバーヘッドが必要となり、領域間の境界に望ましくない画像アーティファクトが生じる可能性がある。

代替的に、解像度の異なる部分を１つの画像内にレンダリングできるハードウェアが使える場合がある（いわゆるフレキシブル・スケール・ラスタライゼーション）。この場合、追加的なレンダーパスは不要である。こうしたハードウェアが入手できれば、性能の点でもこうしたハードウェア・アクセラレート実装は有利である。

図１２ａは、表示されたシーン１２００のための中心窩レンダリングの模式図である。ユーザは、関心領域の方向に視線を向ける。上で説明したように、視線の方向は追跡される。明確化のため、この例では、視線の方向は、表示された視野の中心に向けられている。従って、ユーザの高解像度中心窩領域に概ね一致する領域１２１０は、高解像度でレンダリングされる。一方、周辺領域１２２０は、低解像度でレンダリングされる。視線追跡により、画像の高解像度領域はユーザの目の視力の高い中心窩領域に投射される一方、画像の低解像度領域はユーザの目の視力の低い領域に投射される。ユーザの視線を継続的に追跡してレンダリングすることにより、ユーザは、画像全体が高解像度の画像であるかのように錯覚する。なぜなら、画像は常にユーザ自身の視野の高解像度部分に現れるからである。しかし実際には、典型的に画像の大部分は、低解像度でレンダリングされる。これにより、全画像をレンダリングするための計算機オーバーヘッドを大きく低減できる。

これはいくつかの点で有利である。第１に、同じ計算機資源で、従来に比べてより豊かで、より複雑なおよび／またはより詳細なグラフィックスをユーザに提供できる。さらに同じ計算機資源で、単一の画像（例えばテレビジョンに表示される画像）でなく、２つの画像（例えばヘッドマウントディスプレイに表示する立体画像の左右の画像）をレンダリングできる。第２に、ＨＭＤのようなディスプレイに送信されるデータの量を低減できる。さらに選択的には、ＨＭＤでの画像の前処理（例えば再投影）の計算機コストを低減できる。

図１２ｂを参照すると、選択的に、中心窩レンダリングは、画像の中心窩領域と周辺領域との間で、解像度をマルチステップでまたは段階的に変化させることができる。これは、図１１に示されるように、目の中心窩から周辺領域への視力低下が滑らかであることによる。

従って、変形例において表示されたシーン１２００’では、中心窩領域１２１０は、中心窩領域と減少した周辺領域１２２０’との間に配置された移行領域１２３０で取り巻かれている。

移行領域は、中心窩領域の解像度と周辺領域の解像度の間の中間の解像度でレンダリングされてもよい。

図１３ａおよび図１３ｂを参照する。代替的にこれは、見積もられた視線位置からの距離の関数としてレンダリングされてもよい。例えばこれは、距離とともに徐々にまばらとなるピクセルとと、ピクセルマスクと、を用いて実行されてもよい。これは、対応する画像ピクセルが先ずレンダリングされ、残りのピクセルは近くのレンダリングされた色に従って混入されることを表す。代替的に、フレキシブルスケールラスタライゼーションシステムにより、好適な解像度分布曲線を用いて実行されてもよい。図１３ａは、解像度の線型遷移を示す。図１３ｂは、ユーザの目の中心窩から離れるときの視力の非線型減衰を反映した、解像度の非線型遷移を示す。第２のアプローチでは、解像度はより速く減衰するので、より効率的に計算機オーバーヘッドを低減できる。

このようにして、視線追跡が可能である（例えば、１つ以上の視線追跡カメラの使用、その後のユーザの視線および仮想画像上の視線位置の計算によって）。選択的に、高解像度の錯覚を維持するために、中心窩レンダリングを適用してもよい。この場合、画像生成に伴う計算機オーバーヘッドを低減しつつ、少なくとも中心窩領域では、得られる画像の品質を向上することができる。および／または、２つの通常の画像を生成するとき、２倍より低いコストで、第２の視点を提供する（例えば立体画像のペアを生成する）ことができる。

さらにＨＭＤを装着しているとき、視線領域１２１０が視線ベースの最大関心領域の表示領域である場合、レンダリングされたシーン全体は頭の位置ベースの一般関心領域の表示領域である。すなわち、表示された視野１２００は、ＨＭＤを装着しているときのユーザの頭の位置を反映する。これに対し、当該領域内の中心窩レンダリングは、ユーザの視線位置を反映する。

実際には、表示された視野１２００の周辺領域は、特別なケースとして解像度ゼロでレンダリングされた（すなわち実際にはレンダリングされない）領域と考えることができる。なぜならユーザは、表示された視野の外は見ることができないからである。

しかし、録画されたオリジナルユーザのゲームプレーを、第２のユーザが自分のＨＭＤを装着して見たい場合は、（オリジナルユーザと同じコンテンツを見る場合であっても）上記の限りではない。以下で説明する実施の形態では、図１４ａに従うと、中心窩レンダリングの原理を、オリジナルユーザに表示される視野１２００を超えた領域にまで拡張することができる。これは、オリジナルユーザの視野のさらに外側の周辺領域を、さらに低い解像度でレンダリングすることを意味する。こうしたより低解像度の領域は、通常はオリジナルユーザには見えない（なぜなら、これは現在の視野１２００とともにのみ表示されるからである）。しかしこれは、現在の視野内の中心窩レンダリングと同じ技術を用いて、同じレンダリングパイプラインの一部としてレンダリングすることができる。

この実施の形態では、ゲーム機または他のレンダリング源は、表示された画像１２００の上位セットをレンダリングする。選択的には、先ず高解像度中心窩領域１２１０がレンダリングされる。その後選択的に、移行領域１２３０（図１４ａには示されない）とともに、ユーザに表示される視野内にある周辺領域１２２０がレンダリングされる。その後、さらなる周辺領域１２４０、すなわちユーザに表示される視野の外がレンダリングされる。なお本明細書の文脈で「レンダリング」とは、表示（および／または録画）可能な、または即座に準備可能な、または何らかの可視的な形で出力可能な、画像データを生成することを意味する。

このさらなる周辺領域は、典型的には、ユーザの頭を仮想的な中心とする球面である（またはより正確には、球面が形成される）。このさらなる周辺領域は、ユーザに表示される視野の内部の領域１２２０より低い解像度でレンダリングされる。

選択的に図１４ｂを参照すると、図１２ｂに示される移行領域と同様の方法で、ユーザに表示される視野の周辺に移行領域１２５０が作成されてもよい。この場合、ユーザに表示される視野内の周辺領域１２２０の解像度は、球面状のさらなる周辺領域のために、より低い解像度に引き下げられる。再びこれは、中間解像度または線型もしくは非線型の下降であってもよい。移行領域の相対サイズは、デザイン選択の問題であってもよいし、実験的に決められてもよい。例えば、オリジナルユーザの頭の動きを追跡したいと思うオリジナルユーザの録画の視聴者（典型的には、オリジナルユーザが、ゲーム内の関心対象または関心イベントを追跡していることによる）は、反応時間が限られるので、表示された視野を完全に追跡しなくてもよい。従って、移行領域のサイズは、ユーザに表示された視野が仮想的な球面周辺を動くとき、これを追跡するときの相対的なタイムラグに基づいて選ばれてよい。このタイムラグは、視野のサイズおよび速度の関数であってもよい。従って例えば、オリジナルユーザが頭を素早くおよび／または長い距離を動かした場合、移行領域１２５０は時間的に長く、そのサイズは速度および／または距離の関数であり、選択的には全体的な計算機資源の関数でもある（この場合は、選択的に、全体的な計算機資源を維持するために、さらなる球面領域の残りの部分の解像度は、時間的に縮小されてもよい）。逆に、オリジナルユーザの視野が比較的固定されている場合、移行領域は比較的小さくてもよい。例えば、第２のユーザの頭の微小な動きに適応するのに十分な大きさとか、次のヘッドマウントディスプレイの異なる（おそらくより大きな）視野に適応するのに十分な大きさ（例えば、視野が１１０°の第１世代のヘッドマウントディスプレイを使って録画した場合、より広い視野を持つ第２世代のヘッドマウントディスプレイを見越して、移行領域は１２０°まで拡大されてもよい）といった具合である。

球面画像のレンダリングは、レンダリングパイプの中で、例えばキューブマップとして行われてもよいし、その他の好適な球面レンダリング技術を用いて行われてもよい。

上記のように、オリジナルユーザは、表示された視野１２００だけを見る。選択的に、表示された視野１２００自体は、高解像度の中心窩領域、選択的な移行領域、および周辺領域を備える。あるいは、ヘッドマウントディスプレイが視線追跡を行わないところでは、表示された視野は所定の解像度を持つ。レンダリングされた球面画像の残りの部分は、オリジナルユーザが見ることはなく、低解像度でレンダリングされる。選択的に、表示された視野と球面の残りの部分との間に、移行領域が存在する。

従ってこのスキームでは、表示された視野は、視線ベースの中心窩レンダリングではなく、頭部ベースの中心窩レンダリングスキームであると考えることができる。このスキームでは、ユーザが頭を動かしたとき、比較的高解像度で表示された視野が、レンダリングされた球面全体の周辺を動く。一方選択的には、同時にユーザが視線を動かしたとき、より高解像度の領域が、表示された視野内で動き回る。オリジナルユーザは、表示された視野のみを見る。しかしその後でレンダリングされた画像の録画を見る視聴者は、オリジナルユーザの視野の球面内とは無関係に、潜在的には球面全体にアクセスできる。

従って視聴者は、通常はオリジナルユーザの視野を追跡しようとするが、現在の自分の視野がオリジナルユーザの視野と異なるときは、周辺を楽しむために球面画像内の別の場所を見てもよいし、オリジナルユーザが興味を持たなかったところを見てもよいし、単純により大きな没入感を得てもよい。

従来の画像がゲーム機の環状バッファに記録されるのと同じ方法で、例えば画像全体（オリジナルユーザに表示された画像の球面状の上位セット）が環状バッファに記録されてもよい。画像全体の１分、５分、１５分、３０分または６０分といったフッテージを記録するのに、例えばゲーム機のハードディスク、固体ディスクおよび／またはＲＡＭが使われてもよい。ユーザが録画した素材を保存／アーカイブすることを特に望まない限り（望む場合は、個別のファイルをハードディスクや固体ディスクに複製してもよいし、サーバにアップロードしてもよい）、最も古いフッテージを新しいフッテージで上書きしてもよい。同様に画像全体が、配信サーバにアップロードされてライブで配信されてもよいし、環状バッファから配信またはアップロードされてもよいし、配信サーバまたはＶＯＤサーバにアップロードされ後に配信されてもよい。

結果として、ＨＭＤを装着したオリジナルユーザが頭を動かしたとき、当該オリジナルユーザに表示された視野が高解像度領域となるような球面画像が生成される。選択的に、この高解像度領域の中に、視野内の視線位置に相当するさらに解像度の高い領域が生成される。

選択的に、球面画像とともにメタデータが記録されてもよい。メタデータは、ビデオ録画の一部であってもよいし、関連ファイルであってもよい。メタデータは、表示された視野が球面画像内のどこにあるかを表す。これは、例えば第２のユーザが混乱したりオリジナルユーザの視野を見失って追跡できなくなったりしたとき、彼を手助けするために使われてもよい（例えば、スペースバトルを視聴中にオリジナルユーザが宇宙船を視野外に撃ち落とした場合、第２のユーザは宇宙船やオリジナルユーザの視野を追跡するための視点を失うだろう）。この場合、オリジナルユーザの表示視野が現在どの方向にあるかを示す矢印や、第２のユーザの視野の周辺部の端部にある輝点などのナビゲーションツールがあれば、録画された画像内の最高解像度領域に戻れるようガイドするのに役立つだろう。

このようにして第２のユーザは、視線を変えて別の場所に移動した場合も、オリジナルユーザの表示視野内に確実に戻ることができる。

第２のユーザがシーンを見回すのは、別のイベントが起こった場合や、仮想環境内に他のオブジェクトが存在した場合であると考えられる。これらは、オリジナルユーザにとっては関心がないか興味がないが、第２のユーザにとってはより興味深いものである。

従って選択的に、ゲーム機（またはゲームその他のアプリケーション）はリスト、表その他の関連データを維持してもよい。これらのデータは、特定のオブジェクト（ノンプレーヤーキャラクターなど）や環境要因の関心度、および／または、特定のイベント（オブジェクトやキャラクターの登場、爆発など）への関心度、または関心が高いとタグ付けされたスクリプトイベントの一部などを表すデータである。

このような場合、こうしたオブジェクトまたはイベントがオリジナルユーザに表示される視野外の球面画像内で発生する場合は、こうしたオブジェクトまたはイベントに相当する球面内の領域が、比較的高解像度（例えば、移行領域１２５０の途中または最初に表示された周辺領域１２２０に相当する解像度）でレンダリングされてもよい。選択的に、全体的な計算機資源を維持するために、球面画像の他の部分がより低解像度でレンダリングされてもよい。選択的に、オブジェクトまたはイベントの関心度に応じて、解像度が引き上げられてもよい（例えば、関心度が０、低い、高いオブジェクトまたはイベントに対する解像度の引き上げは、それぞれ０、１、２といった具合である）。

こうしたオブジェクトまたはイベントは、画像が周辺領域に滑らかに移行できるように、周囲に移行領域１２３０または１２５０と同様の移行領域を有していてもよい。これにより、オリジナルユーザが見ないオブジェクトまたはイベントを、第２のユーザが見ることができる。このときの解像度は、より関心度の低い球面画像の部分の解像度より引き上がられている。

中心窩レンダリングの原理がオリジナルユーザの視野を越えて拡張されて、さらなる周辺領域または球面領域（または環状立体領域や円柱領域）を生成する領域が追加される場合、あるいは実際には中心窩レンダリングが使われず（例えば視線追跡が存在しないため）中心窩レンダリングの原理がオリジナルユーザの視野外に適用される場合を考える。このような場合、選択的に、上記のスキームは、１人以上のユーザ、レンダリングされた環境を生成するアプリケーションゲームコンソールのオペレーティングシステムまたはヘルパーアプリケーション（例えば配信／ストリーミングやアップロードのためのアプリケーション）によって起動または停止されてもよい。

例えば上記のスキームは、デフォルトではオフであってもよい。なぜなら上記のスキームは計算機オーバーヘッドとなり、実行中のゲームがストリームまたは配信されてない間は不要だからである。従って上記のスキームは、ゲームがストリームまたは配信されるときオンとなるような、またはストリームやアップロード開始の指示に応答してオンとなるような、オプションとしてユーザに与えられてもよい。

視聴者が、オリジナルユーザとはさらに異なる視線方向を見たい場合を考える。この場合もやはり、例えばゲームイベントまたは特定のレベルもしくはカットシーンなどに応答して、ゲームまたはレンダリングされた環境を生成するアプリケーションが上記のイベントを起動してもよい。

［変形例］
上記のスキームは、計算機オーバーヘッドを増加させる。なぜなら上記のスキームは、たとえオリジナルユーザに表示された視野内のより低解像度のシーンであっても、より多くのシーンをレンダリングする必要があるからである。

これを軽減するために、オリジナルユーザに表示される視野外（または選択的に、オリジナルユーザに表示される視野との境界である移行領域１２５０の外）でレンダリングされる部分は、視野内（または選択的に移行領域）より低いフレームレートでレンダリングされてもよい。

従って、例えば視野が毎秒６０フレーム（ｆｐｓ）でレンダリングされ、球面の残りの部分が３０ｆｐｓでレンダリングされてもよく、選択的に計算機資源が許せば６０ｆｐｓより高解像度でレンダリングされてもよい。

選択的に、６０ｆｐｓのフレームレートを回復するために、録画画像のアップロードサーバが球面の残りのフレームを挿入してもよい。

より一般的には、球面の残りの部分（選択的にオリジナルユーザの視野の周辺の移行部分を含む）は、オリジナルユーザに表示される視野のフレームレートの数分の１（典型的には１／２または１／４）のフレームレートでレンダリングされる。その後、画像のこの部分は、ゲーム機または録画画像が送信されるサーバによってフレーム挿入される。

低減されたフレームレートを補償するための独立した時間的フレーム挿入の代替または追加として、低減された画像解像度を補償するために独立した空間的挿入が行われてもよい。これは、（例えば上記のゲーム機またはサーバによる）オフライン処理を用いて実行されてもよく、（選択的には）連続するフレームから得られる情報および／またはシーンの周囲を動くオリジナルの視野から得られる情報を用いて実行されてもよい（これにより、より高解像度の参照ピクセル（これは、より低解像度でレンダリングされた部分の処理または情報に置き換えられてもよい）が与えられる）。選択的に、ビデオ（具体的には、ゲーム環境のより低解像度または高解像度のウォークスルーで訓練されたビデオ。これは例えば、環境での開発者の動きによって生成されてもよく、球面画像を目標解像度でレンダリングしてもよい。このときのフレームレート／実行時間は、結果物のフレームと独立であってもよい。なぜならこれはゲームプレーを目的とするものではないからである）をスケールアップするために機械学習システムが訓練されてもよい。

原理的には、球面の残りの部分を含む録画されたビデオは、時間的に短縮されても空間的に短縮されてもよい。こうしたビデオは、少なくとも部分的には、ゲーム機および／または蓄積サーバや配信サーバの並行処理または逐次処理によって補償される。

その後、サーバは、（時間的および／または空間的に）スケールアップされたビデオ画像を（あるいは上記の変形例を適用しない場合は、オリジナルのアップロードされたビデオ画像を）１人以上の視聴者に（またはこうした機能を持つさらなるサーバに）配信することができる。

その後、この視聴者は、自分のクライアントデバイスのアプリケーションを用いてビデオを視聴することができる。あるいは視聴者は、オリジナルユーザの視点を追跡したり、シーンを自由に見回したりすることができる。

［実施の形態の概要］
図１５を参照すると、本発明の実施の形態の方法は概略的に以下のビデオ録画方法は以下のステップを含む。

第１のステップＳ１５１０は、上記のように、ヘッドマウントディスプレイを装着した第１のユーザの仮想環境の視野を第１の解像度でレンダリングする。

第２のステップＳ１５２０は、上記のように、第１のユーザの視野外の仮想環境を第１の解像度より低い第２の解像度でレンダリングする。

第３のステップＳ１５３０は、上記のように、レンダリングされた視野を第１のユーザに表示するために出力する。

第４のステップＳ１５４０は、上記のように、第２のユーザが続けて視聴できるように、組み合わされたレンダリングをビデオとして録画する。

原理的には、第３のステップと第４のステップとは交換可能である。さらに選択的には、第３のステップは、第２のステップより先であってもよいし、第２のステップと並行して実施されてもよい。同様に第４のステップは、第１のステップおよび第２のステップのレンダリングに基づいて逐次的に実行されてもよい。

本発明の方法および／または装置の様々な実施の形態の操作に相当する上記の方法の変形例は、本開示の範囲に含まれることを当業者は理解するだろう。これらの変形例は、以下を含むがこれらに限定されない。
－この方法は、第１のユーザの視線追跡に基づいて、視野内で、仮想環境の中心窩領域を第１の解像度より高い第３の解像度でレンダリングするステップを含む。
－第１のユーザの視野外の仮想環境の画像をレンダリングするステップは、仮想環境の球面状または円柱状の画像を生成する。
－この方法は、第１のユーザの視野外で、レンダリングされた視野の境界であり、第１の解像度と第２の解像度との中間の解像度を持つ移行領域をレンダリングするステップを含む。
－移行領域の大きさは、連続する画像フレーム間におけるレンダリングされた視野位置の違い、連続する画像フレーム間におけるレンダリングされた視野位置の変化率、第１のユーザの頭の微小な動きにより発生したレンダリングされた視野位置の変動、第２のユーザの頭の微小な動きにより発生した位置変動の期待値、の１つ以上の項目に依存する。
－この方法は、第１のユーザの視野外にある仮想環境のレンダリング画像内の関心対象であるオブジェクトまたはイベントを、第２の解像度より高い解像度でレンダリングするステップを含み、第１のユーザの視野外にある仮想環境のレンダリング画像内の残りの部分は、第２の解像度を維持する。
－第１のユーザの視野外の仮想環境の画像をレンダリングするステップは、第１のユーザ、仮想環境をレンダリングするアプリケーション、仮想環境をレンダリングするデバイスのオペレーティングシステム、仮想環境をレンダリングするデバイスのオペレーティングシステムのヘルパーアプリケーション、の１つ以上の項目に依存する。
－この方法は、第１の解像度でレンダリングされたヘッドマウントディスプレイの第１のユーザの仮想環境の視野と、第１の解像度より低い第２の解像度でレンダリングされた第１のユーザの視野外の仮想環境の画像と、が含まれる録画されたビデオを取得するステップと、第１のユーザの視野外の仮想環境の画像の録画における空間解像度、第１のユーザの視野外の仮想環境の画像の録画における時間分解能、のいずれかまたは両方を引き上げるステップと、を含む。

一方、実施の形態の概要に記載された方法を用いて録画されたビデオを配信する方法では、録画されたビデオには、第１の解像度でレンダリングされたヘッドマウントディスプレイの第１のユーザの仮想環境の視野と、第１の解像度より低い第２の解像度でレンダリングされた第１のユーザの視野外の仮想環境の画像と、が含まれ、録画されたビデオを第２のユーザにダウンロードまたはストリームする要求を受信するステップと、録画されたビデオを第２のユーザにダウンロードまたはストリームするステップと、を含む。

この方法は選択的に、配信をする前に、第１のユーザの視野外の仮想環境の画像の録画における空間解像度、第１のユーザの視野外の仮想環境の画像の録画における時間分解能、のいずれかまたは両方を引き上げるステップを含む。

図１６を参照すると、本発明の実施の形態の概要に記載されたビデオ録画（第１の解像度でレンダリングされたヘッドマウントディスプレイの第１のユーザの仮想環境の視野と、第１の解像度より低い第２の解像度でレンダリングされた第１のユーザの視野外の仮想環境の画像と、が含まれる）の視聴方法は、以下のステップを含む。

第１のステップＳ１６１０は、リモートソース（例えば、配信またはストリーミングサーバ、あるいは潜在的にはピアツーピアサーバまたはゲームコンソール）からのビデオのダウンロードまたはストリームを要求する。

第２のステップＳ１６２０は、リモートソースからのビデオのダウンロードまたはストリームを受信する。

第３のステップＳ１６３０は、ヘッドマウントディスプレイを装着した第２のユーザに表示するためにストリームまたはビデオの少なくとも一部を出力する。

ここで、ビデオのストリームを出力するステップは、以下のサブステップを含む。

第１のサブステップＳ１６３２は、上記のように、ヘッドマウントディスプレイを装着した第２のユーザの視野を検出する。

第２のサブステップＳ１６３４は、上記のように、第２のユーザのヘッドマウントディスプレイに出力するために、録画されたストリームまたはビデオの対応部分を供給する。

再び本発明の方法および／または装置の様々な実施の形態の操作に相当する上記の方法の変形例は、本開示の範囲に含まれることを当業者は理解するだろう。これらの変形例は、以下を含むがこれらに限定されない。
－この方法は、録画ビデオに関連するデータに基づいて第２のユーザの現在の視野の第１のユーザの視野に対する相対位置を計算するステップを含み、相対位置が所定の閾値より大きくずれていた場合、対応する第１のユーザの視野に向けて第２のユーザが視野を移動するための修正方向を計算するステップと、第２のユーザに示される視野内に修正方向を表示するステップと、を含む。

上記の方法は、好適なソフトウェア命令が適用可能な通常のハードウェアまたは（これらに追加してもしくはこれらに代えて）専用のハードウェアを用いて実行できることが理解できるだろう。

通常の同等デバイスの既存のパーツを用いた実現は、非一時的なコンピュータ読み取り可能な媒体（例えば、フロッピーディスク（登録商標）、光ディスク、ハードディスク、固体ディスク、ＰＲＯＭ、ＲＡＭ、フラッシュメモリまたはこれらの記録媒体の組み合わせ）に記録された命令を実行可能なプロセッサを備えたコンピュータプログラムプロダクトの形で可能であり、あるいはハードウェア（例えば、ＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）、ＦＰＧＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）その他の通常のデバイスに適した設定可能な回路）を用いても可能である。こうしたコンピュータプログラムは、ネットワーク（例えば、イーサネット（登録商標）、無線ネットワーク、インターネットまたはこれらのネットワークの好適な組み合わせ）上のデータ信号を介して送信されてもよい。

本開示の概要において、ビデオ録画システム９１０（例えば、ＰｌａｙＳｔａｔｉｏｎ５（登録商標）などのビデオゲームコンソール、典型的にはヘッドマウントディスプレイ８１０と組み合わされたもの）は、ヘッドマウントディスプレイの第１のユーザの仮想環境の視野を第１の解像度でレンダリングする（例えば好適なソフトウェア命令により）ように構成されたレンダリングプロセッサ（例えばＧＰＵ９１２および／またはＣＰＵ９１１）を備える。レンダリングプロセッサはまた、第１のユーザの視野外の仮想環境の画像を第１の解像度より低い第２の解像度でレンダリングする（再び例えば好適なソフトウェア命令により）ように構成される。この２つのステップのレンダリング処理は、シーケンシャルに実行されてもパラレルに実行されてもよく、レンダリング中に解像度を動的に変える単一プロセス（例えば、フレキシブルスケールラスタライゼーション）の一部であってもよい。出力プロセッサ（例えば、ＧＰＵ９１２、ＣＰＵ９１１および／または入力／出力９１４）は、レンダリングされた視野を第１のユーザに表示するために出力する（再び例えば好適なソフトウェア命令により）ように構成される。さらに第２のユーザが続けて視聴できるビデオとして、ストレージユニット（図示されないが例えばハードディスク、固体ドライブまたはＲＯＭであり、典型的にはＣＰＵ９１１および／またはＧＰＵ９１２と関連する）が、組み合わされたレンダリングを第２のユーザが続けて見るためにビデオとして録画する（再び例えば好適なソフトウェア命令により）ように構成される。

本明細書の方法および技術を実現する（例えば好適なソフトウェア命令により）これらの実施の形態の概要の例は、本出願の範囲内にあるシステムであって、好適なソフトウェア命令を用いて、配信をする前にレンダリングの空間解像度および／または時間分解能を引き上げるように構成されたサーバを備えたシステムを含む（しかし限定されない）。

同様に、ビデオ再生システム９１０（例えば、ＰｌａｙＳｔａｔｉｏｎ５（登録商標）などのビデオゲームコンソール、典型的にはヘッドマウントディスプレイ８１０と組み合わされたもの）は、録画ビデオ（第１の解像度でレンダリングされたヘッドマウントディスプレイの第１のユーザの仮想環境の視野と、第１の解像度より低い第２の解像度でレンダリングされた第１のユーザの視野外の仮想環境の画像と、が含まれる）を再生することに適用される。このビデオ再生システムは、以下を備える。

リモートソース（例えば、ビデオをホスティングまたは中継する配信またはストリーミングサーバ）からビデオをダウンロードまたはストリームする要求を送信する（例えば好適なソフトウェア命令により）ように構成された送信器（例えば、入力／出力９１４、選択的にＣＰＵ９１１と連携する）。

リモートソースからのビデオのダウンロードまたはストリームを受信する（例えば好適なソフトウェア命令により）ように構成された受信器。

ヘッドマウントディスプレイを装着した第２のユーザに表示するためにストリームまたはビデオの少なくとも一部を出力する（例えば好適なソフトウェア命令により）ように構成されたグラフィックプロセッサ（例えば、ＧＰＵ９１２および／またはＣＰＵ９１１）。

グラフィックプロセッサはさらに、ヘッドマウントディスプレイを装着した第２のユーザの視野を検出し（例えば、任意の頭の動きを追跡する技術を用いて）、第２のユーザのヘッドマウントディスプレイに出力するために、録画されたストリームまたはビデオの対応部分を供給するように構成される（例えば好適なソフトウェア命令により）。

本明細書の方法および技術を実現する（例えば好適なソフトウェア命令により）これらの実施の形態の概要の例は、本出願の範囲内にあるグラフィックプロセッサ（例えば、ＧＰＵ９１２および／またはＣＰＵ９１１）を含む（しかし限定されない）。こうしたグラフィックプロセッサは、録画ビデオに関連するデータ（例えば、録画ビデオまたは関連ファイル内で、オリジナルの第１のユーザの視野を定義するメタデータ）に基づいて第２のユーザの現在の視野の第１のユーザの視野に対する相対位置を計算するように構成される。さらにグラフィックプロセッサは、これらの視野の相対位置が所定の閾値より大きくずれていた場合、第２のユーザが対応する第１のユーザの視野に向けて視野を移動するための修正方向を計算し、第２のユーザに示される現在の視野内に修正方向を表示するように構成される。

上記の議論は、本発明の実施の形態の例を開示し説明するに過ぎない。本発明の思想および本質的な特徴を逸脱することなく、本発明を別の特定の形で実現できることを当業者は理解するだろう。従って本発明の開示は例示を目的とし、本発明の範囲および請求項を限定することを意図しない。上記の教示の識別可能な任意の変形例を含む本開示は、請求項の用語の範囲を部分的に定義する。発明の主題は公衆に献呈されるものではない。

Claims (15)

1. ビデオ録画方法であって、
   ヘッドマウントディスプレイの第１のユーザの仮想環境の視野を第１の解像度でレンダリングするステップと、
   前記第１のユーザの視野外の仮想環境の画像を前記第１の解像度より低い第２の解像度でレンダリングするステップと、
   レンダリングされた視野を前記第１のユーザに表示するために出力するステップと、
   組み合わされたレンダリングを第２のユーザが続けて見るためにビデオとして録画するステップと、を含むことを特徴とする方法。
2. 前記第１のユーザの視線追跡に基づいて、前記視野内で、仮想環境の中心窩領域を前記第１の解像度より高い第３の解像度でレンダリングするステップを含むことを特徴とする請求項１に記載の方法。
3. 前記第１のユーザの視野外の仮想環境の画像をレンダリングするステップは、仮想環境の球面状または円柱状の画像を生成することを特徴とする請求項１または２に記載の方法。
4. 前記第１のユーザの視野外で、レンダリングされた視野の境界であり、前記第１の解像度と前記第２の解像度との中間の解像度を持つ移行領域をレンダリングするステップを含むことを特徴とする請求項１から３のいずれかに記載の方法。
5. 前記移行領域の大きさは、
   ｉ．連続する画像フレーム間におけるレンダリングされた視野位置の違い、
   ｉｉ．連続する画像フレーム間におけるレンダリングされた視野位置の変化率、
   ｉｉｉ．前記第１のユーザの頭の微小な動きにより発生したレンダリングされた視野位置の変動、
   ｉｖ．前記第２のユーザの頭の微小な動きにより発生した位置変動の期待値、
   の１つ以上の項目に依存することを特徴とする請求項４に記載の方法。
6. 前記第１のユーザの視野外にある仮想環境のレンダリング画像内の関心対象であるオブジェクトまたはイベントを、前記第２の解像度より高い解像度でレンダリングするステップを含み、
   前記第１のユーザの視野外にある仮想環境のレンダリング画像内の残りの部分は、前記第２の解像度を維持することを特徴とする請求項１から５のいずれかに記載の方法。
7. 前記第１のユーザの視野外の仮想環境の画像をレンダリングするステップは、
   ｉ．前記第１のユーザ、
   ｉｉ．仮想環境をレンダリングするアプリケーション、
   ｉｉｉ．仮想環境をレンダリングするデバイスのオペレーティングシステム、
   ｉｖ．仮想環境をレンダリングするデバイスのオペレーティングシステムのヘルパーアプリケーション、
   の１つ以上の項目に依存することを特徴とする請求項１から６のいずれかに記載の方法。
8. 第１の解像度でレンダリングされたヘッドマウントディスプレイの第１のユーザの仮想環境の視野と、前記第１の解像度より低い第２の解像度でレンダリングされた第１のユーザの視野外の仮想環境の画像と、が含まれる録画されたビデオを取得するステップと、
   ｉ．前記第１のユーザの視野外の仮想環境の画像の録画における空間解像度、
   ｉｉ．前記第１のユーザの視野外の仮想環境の画像の録画における時間分解能、
   のいずれかまたは両方を引き上げるステップと、を含むことを特徴とする請求項１から７のいずれかに記載の方法。
9. 請求項１に記載の方法を用いて録画されたビデオを配信する方法であって、
   前記録画されたビデオには、第１の解像度でレンダリングされたヘッドマウントディスプレイの第１のユーザの仮想環境の視野と、前記第１の解像度より低い第２の解像度でレンダリングされた第１のユーザの視野外の仮想環境の画像と、が含まれ、
   前記録画されたビデオを第２のユーザにダウンロードまたはストリームする要求を受信するステップと、
   前記録画されたビデオを前記第２のユーザにダウンロードまたはストリームするステップと、を含むことを特徴とする方法。
10. 配信をする前に、
    ｉ．前記第１のユーザの視野外の仮想環境の画像の録画における空間解像度、
    ｉｉ．前記第１のユーザの視野外の仮想環境の画像の録画における時間分解能、
    のいずれかまたは両方を引き上げるステップを含むことを特徴とする請求項９に記載の方法。
11. 第１の解像度でレンダリングされたヘッドマウントディスプレイの第１のユーザの仮想環境の視野と、前記第１の解像度より低い第２の解像度でレンダリングされた第１のユーザの視野外の仮想環境の画像と、が含まれた録画ビデオを視聴する方法であって、
    リモートソースからのビデオのダウンロードまたはストリームを要求するステップと、
    前記リモートソースからのビデオのダウンロードまたはストリームを受信するステップと、
    ヘッドマウントディスプレイを装着した第２のユーザに表示するためにストリームまたはビデオの少なくとも一部を出力するステップと、を含み、
    前記出力するステップは、
    ヘッドマウントディスプレイを装着した第２のユーザの視野を検出するステップと、
    前記第２のユーザのヘッドマウントディスプレイに出力するために、録画されたストリームまたはビデオの対応部分を供給するステップと、を含むことを特徴とする方法。
12. 前記録画ビデオに関連するデータに基づいて前記第２のユーザの現在の視野の前記第１のユーザの視野に対する相対位置を計算するステップを含み、
    前記相対位置が所定の閾値より大きくずれていた場合、
    対応する前記第１のユーザの視野に向けて前記第２のユーザが視野を移動するための修正方向を計算するステップと、
    前記第２のユーザに示される視野内に前記修正方向を表示するステップと、を含むことを特徴とする請求項１１に記載の方法。
13. 請求項１から１２のいずれかに記載の方法をコンピュータに実行させることを特徴とするコンピュータプログラム。
14. ビデオ録画システムであって、
    ヘッドマウントディスプレイの第１のユーザの仮想環境の視野を第１の解像度でレンダリングするように構成されたレンダリングプロセッサと、
    前記レンダリングされた視野を第１のユーザに表示するために出力するように構成された出力プロセッサと、
    組み合わされたレンダリングを第２のユーザが続けて見るためにビデオとして録画するように構成されたストレージユニットと、を備え、
    前記レンダリングプロセッサは、前記第１のユーザの視野外の仮想環境の画像を前記第１の解像度より低い第２の解像度でレンダリングすることを特徴とするビデオ録画システム。
15. 第１の解像度でレンダリングされたヘッドマウントディスプレイの第１のユーザの仮想環境の視野と、前記第１の解像度より低い第２の解像度でレンダリングされた第１のユーザの視野外の仮想環境の画像と、が含まれた録画ビデオを再生するビデオ再生システムであって、
    リモートソースからビデオをダウンロードまたはストリームする要求を送信するように構成された送信器と、
    リモートソースからのビデオのダウンロードまたはストリームを受信するように構成された受信器と、
    ヘッドマウントディスプレイを装着した第２のユーザに表示するためにストリームまたはビデオの少なくとも一部を出力するように構成されたグラフィックプロセッサと、を備え、
    前記グラフィックプロセッサは、ヘッドマウントディスプレイを装着した第２のユーザの視野を検出し、前記第２のユーザのヘッドマウントディスプレイに出力するために、録画されたストリームまたはビデオの対応部分を供給するように構成されることを特徴とするビデオ再生システム。

Images