特表 2025-501535 高忠実度倍率を可能にするインタラクティブビデオ再生技法

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2025-01-22

(54)【発明の名称】高忠実度倍率を可能にするインタラクティブビデオ再生技法

(51)【国際特許分類】

   G09G 5/373 20060101AFI20250115BHJP

   H04N 21/4402 20110101ALI20250115BHJP

   H04N 21/4728 20110101ALI20250115BHJP

   G09G 5/37 20060101ALI20250115BHJP

   G09G 5/00 20060101ALI20250115BHJP

   G09G 5/377 20060101ALI20250115BHJP

【ＦＩ】

G09G5/373 100

H04N21/4402

H04N21/4728

G09G5/37 320

G09G5/00 550C

G09G5/00 555A

G09G5/00 530M

G09G5/377

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024536485

(86)(22)【出願日】2022-12-25

(85)【翻訳文提出日】2024-06-18

(86)【国際出願番号】 US2022082385

(87)【国際公開番号】W WO2023133060

(87)【国際公開日】2023-07-13

(31)【優先権主張番号】17/571,397

(32)【優先日】2022-01-07

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】310021766

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

(74)【代理人】

【識別番号】100105924

【弁理士】

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

(72)【発明者】

【氏名】クリシュナン、ラティシュ

【テーマコード（参考）】

5C164

5C182

【Ｆターム（参考）】

5C164GA07

5C164MA02S

5C164PA33

5C164UA31S

5C164UB02P

5C164UD44P

5C182AA22

5C182AA31

5C182AB01

5C182AB02

5C182AB08

5C182AB14

5C182AB34

5C182AB35

5C182AC43

5C182BA01

5C182BA06

5C182BA27

5C182BA29

5C182BA30

5C182BA39

5C182BA46

5C182BA47

5C182BC01

5C182BC22

5C182BC25

5C182BC26

5C182BC29

5C182CB13

5C182CB14

5C182CB45

5C182CB52

5C182CC21

5C182DA41

5C182DA44

(57)【要約】

第１のビデオ（４００）を提示しているときに、ズームコマンド（２０６）に応答して、第２のビデオ（４０８）が第１のビデオと組み合わされて提示される。第１及び第２のビデオは、互いに実質的に同じカメラ場所から、実質的に同じ時間に、実質的に同じ解像度で生成される。しかしながら、第２のビデオは、第１のビデオを生成する際に使用される物理又は仮想レンズの視野（ＦＯＶ）よりも小さいＦＯＶを有する物理又は仮想レンズによって生成される。整合メトリックを使用して第２のビデオを内側ビデオの上に正しく配置し、それをシームレスに見せるためのモジュール（５０８、５１０）が記載されている。
【選択図】なし

【特許請求の範囲】

【請求項1】

デバイスであって、
一時的な信号ではなく、少なくとも１つのプロセッサによって実行可能な命令を含む少なくとも１つのストレージデバイスを備え、前記命令は、前記プロセッサに、
第１のサイズを有する第１のオブジェクトを有する第１のビデオを提示させ、
ズームコマンドに応答して、前記第１のサイズよりも大きい第２のサイズを有する前記第１のオブジェクトを有する第２のビデオを提示させ、
前記第２のビデオのフレームを、単一の次元における前記第２のビデオ内の提示された画素の数に対する前記第１のビデオ内の提示された画素の数の比率を少なくとも部分的に使用して、前記第１のビデオのフレームと整合させる、デバイス。

【請求項2】

前記命令は、
前記第１のビデオのフレームの関心領域（ＲＯＩ）に対する前記第２のビデオの水平オフセットを識別し、
前記第１のビデオの前記フレームの前記ＲＯＩに対する前記第２のビデオの垂直オフセットを識別し、
前記オフセットを使用して、前記第２のビデオのフレームを前記第１のビデオのフレームに整合させるように実行可能である、請求項１に記載のデバイス。

【請求項3】

前記それぞれの第１及び第２のビデオを生成するように構成されたそれぞれの第１及び第２の視野（ＦＯＶ）を有する第１及び第２の物理カメラ又は仮想カメラを備え、前記第１のＦＯＶは、前記第２のＦＯＶよりも大きく、前記第１及び第２のカメラは、前記第１のオブジェクトの画像を互いに同時にキャプチャする、請求項２に記載のデバイス。

【請求項4】

前記命令は、前記第１及び第２のビデオのブレンドを促進するために、前記カメラのための自動露出を無効にするように実行可能である、請求項３に記載のデバイス。

【請求項5】

前記命令は、
前記第１及び第２のビデオを時間的に同期し、
前記第１及び第２のビデオを、それぞれの第１及び第２のビットストリームとして符号化するように実行可能である、請求項３に記載のデバイス。

【請求項6】

前記命令は、それぞれの第１及び第２のデコーダを使用して、両方のビットストリームを同時に復号するように実行可能である、請求項３に記載のデバイス。

【請求項7】

前記命令は、前記第１及び第２のビットストリームを単一のビットストリームに圧縮し、前記単一のビットストリームを復号するために単一のデコーダを使用するように実行可能である、請求項３に記載のデバイス。

【請求項8】

ビデオプレーヤーであって、
少なくとも１つのプロセッサを備え、前記少なくとも１つのプロセッサは、
第１の視野（ＦＯＶ）を有する第１のビデオ、及び前記第１のＦＯＶよりも小さい第２のＦＯＶを有する第２のビデオの画素を出力することと、
前記画素を出力するために少なくとも１つの復号モジュール（ＤＭ）及び少なくとも１つのレンダリングモジュール（ＲＭ）を実行することであって、前記ＤＭは、少なくとも１つのデコーダを備え、前記ＲＭは、少なくとも１つのシェーダを備える、実行することと、
少なくとも部分的に前記ＤＭ及び／又はＲＭを使用して、ズームコマンドに応答して前記第１及び第２のビデオの少なくとも一部を少なくとも１つのディスプレイに提供することと、を行うように構成された、ビデオプレーヤー。

【請求項9】

前記プロセッサは、
前記第１のビデオにおける関心領域（ＲＯＩ）に対する整合メトリックを使用して、前記第２のビデオを前記第１のビデオと整合させるように構成されている、請求項８に記載のビデオプレーヤー。

【請求項10】

前記ビデオを整合させることは、固定された整合メトリックを使用する、請求項９に記載のビデオプレーヤー。

【請求項11】

前記ビデオを整合させることは、時間とともに変化する整合メトリックを使用する、請求項９に記載のビデオプレーヤー。

【請求項12】

前記整合メトリックは、前記ＤＭによって復号されたビットストリーム内のメタデータにおいて受信される、請求項１１に記載のビデオプレーヤー。

【請求項13】

前記プロセッサは、動き推定及び画像マッチングを使用して前記整合メトリックを計算するように構成されている、請求項１１に記載のビデオプレーヤー。

【請求項14】

前記ズームコマンドは、倍率レベル（ＭＬ）を確立し、前記プロセッサは、前記第１及び第２のビデオのどの部分が前記ディスプレイ上で可視にされるかを判定するために前記ＭＬを使用するように構成されている、請求項８に記載のビデオプレーヤー。

【請求項15】

前記プロセッサは、画質劣化をもたらす倍率レベルを回避するために、ＭＬについて上限及び下限を配置するように構成されている、請求項１４に記載のビデオプレーヤー。

【請求項16】

前記プロセッサは、ＭＬを増加させる前記ズームコマンドに応答して、第１のビデオの可視画素の数を減少させ、前記第２のビデオの可視画素の数を増加させるように構成されている、請求項１４に記載のビデオプレーヤー。

【請求項17】

前記プロセッサは、２つの別個のビデオではなく単一のビデオを見ることの知覚を作成するために、前記ズームコマンドに関連付けられた倍率レベル（ＭＬ）、前記整合メトリック、及び同期のための前記ビデオに関連付けられた入力ビットストリームのフレーム番号を使用するために、前記ＲＭの前記少なくとも１つのシェーダを実行するように構成されている、請求項９に記載のビデオプレーヤー。

【請求項18】

前記プロセッサは、前記ビデオ間の境界をマスクするために、前記少なくとも１つのシェーダを使用して前記ビデオをフェザリングするように構成されている、請求項１７に記載のビデオプレーヤー。

【請求項19】

前記プロセッサは、前記ズームコマンドによって確立された倍率レベル（ＭＬ）が、前記第２のビデオの一部が復号されず、前記ＤＭの少なくとも１つのデコーダが非アクティブ状態にあるような第１のＭＬであるとき、前記第２のビデオの少なくとも一部のレンダリングをスキップするように構成されている、請求項８に記載のビデオプレーヤー。

【請求項20】

前記プロセッサは、前記ＭＬの変化に応答して、復号される現在のフレームがキーフレームであるときにのみ、前記少なくとも１つのデコーダを非アクティブ状態からアクティブ状態に変化させるように構成されている、請求項１９に記載のビデオプレーヤー。

【請求項21】

方法であって、
それぞれの第１、第２、及び第３のビデオを表す少なくとも第１、第２、及び第３のビットストリームを受信することと、
少なくとも第１の要求倍率レベル（ＭＬ）に応答して、前記第１のビデオをレンダリングするために第１のデコーダで前記第１のビットストリームを復号し、前記第２のビデオをレンダリングするために第２のデコーダで前記第２のビットストリームを復号することと、
前記第１及び第２のビデオをディスプレイ上に提示することと、
前記第１の要求ＭＬよりも大きい第２の要求ＭＬに応答して、前記第３のビデオをレンダリングするために前記第１のデコーダで前記第３のビットストリームを復号し、前記第２のビデオをレンダリングするために前記第２のデコーダで前記第２のビットストリームを復号することと、
前記第２及び第３のビデオをディスプレイ上に提示することと、を含む、方法。

【請求項22】

前記第１又は第２の要求ＭＬに従って各ビットストリームの復号された画素を表示するために、前記デコーダのうちの少なくとも１つから渡されたビットストリーム識別子（ＩＤ）を使用することと、
少なくとも１つのビットストリームＩＤの変化に応答して、異なるテクスチャ及びサンプリング座標を使用するようにレンダリングを更新することと、を含む、請求項２１に記載の方法。

【請求項23】

複数のビットストリームを処理するために前記第１のデコーダの同じインスタンスを使用することであって、前記ビットストリームのキーフレームが、ユーザーが前記ＭＬをどのくらい速く増加又は減少させることができるかに従って整合され、均等に離間される、使用することと、
各ビットストリームについてのキーフレーム位置及びオフセットを事前計算することと、を含む、請求項２１に記載の方法。

【請求項24】

要求ＭＬに基づいて処理されるべき次のビットストリームを予測するために少なくとも１つのデコーダを使用することと、
前記ＭＬの変化速度を促進するために、復号された画素を、前記復号された画素が前記ディスプレイ上で可視にされる前に、レンダリングするように前記次のビットストリームを復号することと、を含む、請求項２３に記載の方法。

【請求項25】

前記プロセッサは、ＭＬを減少させる前記ズームコマンドに応答して、第１のビデオの可視画素の数を増加させ、前記第２のビデオの可視画素の数を減少させるように構成されている、請求項１４に記載のビデオプレーヤー。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、概して、解像度を失うことなくビデオをズームするためのモジュールに関する。

【背景技術】

【0002】

本明細書で認識されるように、ビデオをズームするとき、高レベルのズームでは、画像がピクセル化する。これは、非常に高い解像度を有するビデオを提供することによって緩和されることができるが、そのようなビデオは、過度のストレージ及び帯域幅を消費する。現在、上記のコンピュータ関連の技術的問題に対する適切な解決策はない。

【発明の概要】

【0003】

したがって、一態様では、デバイスは、一時的な信号ではない一方、少なくとも１つのプロセッサによって実行可能な命令を含む少なくとも１つのストレージデバイスを含み、実行可能な命令は、プロセッサに第１のサイズを有する第１のオブジェクトを有する第１のビデオを提示させる。命令は、ズームコマンドに応答して、第１のサイズよりも大きい第２のサイズを有する第１のオブジェクトを有する第２のビデオを提示し、第２のビデオのフレームを、単一の次元における第２のビデオ内の画素の数に対する第１のビデオ内の画素の数の比率を少なくとも部分的に使用して、第１のビデオのフレームと整合させるように実行可能である。

【0004】

この第１の態様の例示的な実装形態では、命令は、第１のビデオのフレームの関心領域（ＲＯＩ）に対する第２のビデオの水平オフセットを識別し、第１のビデオのフレームのＲＯＩに対する第２のビデオの垂直オフセットを識別し、それらのオフセットを使用して、第２のビデオのフレームを第１のビデオのフレームに整合させるように実行可能であり得る。そのような実装形態では、デバイスは、それぞれの第１及び第２のビデオを生成するように構成されたそれぞれの第１及び第２の視野（ＦＯＶ）を有する第１及び第２の物理カメラ又は仮想カメラを含み得、第１のＦＯＶは、第２のＦＯＶよりも大きく、第１及び第２のカメラは、第１のオブジェクトの画像を互いに同時にキャプチャする。

【0005】

所望であれば、命令は、第１及び第２のビデオのブレンドを促進するために、カメラのための自動露出を無効にするように更に実行可能であり得る。

【0006】

上記の実施例では、命令は、第１及び第２のビデオを時間的に同期し、第１及び第２のビデオを、それぞれの第１及び第２のビットストリームとして符号化するように実行可能であることができる。命令は、それぞれの第１及び第２のデコーダを使用して、両方のビットストリームを同時に復号するように実行可能であり得る。他の実施形態では、命令は、第１及び第２のビットストリームを単一のビットストリームに圧縮し、その単一のビットストリームを復号するために単一のデコーダを使用するように実行可能であり得る。

【0007】

別の態様では、ビデオプレーヤーが、第１の視野（ＦＯＶ）を有する第１のビデオ、及び第１のＦＯＶよりも小さい第２のＦＯＶを有する第２のビデオの画素を出力するように構成された少なくとも１つのプロセッサを含む。プロセッサは、画素を出力するために少なくとも１つの復号モジュール（ＤＭ）及び少なくとも１つのレンダリングモジュール（ＲＭ）を実行するように構成されている。ＤＭは、少なくとも１つのデコーダを含み、ＲＭは、少なくとも１つのシェーダを含む。プロセッサは、ＤＭ及び／又はＲＭを少なくとも部分的に使用して、ズームコマンドに応答して第１及び第２のビデオの少なくとも一部を少なくとも１つのディスプレイに提供するように構成されている。

【0008】

この第２の態様のいくつかの実装形態では、プロセッサは、第１のビデオにおける関心領域（ＲＯＩ）に対する整合メトリックを使用して、第２のビデオを第１のビデオと整合させるように構成され得る。ビデオを整合させることは、固定された整合メトリックを使用することができる、又は整合メトリックは、時間とともに変化することができ、その場合、それらは、ＤＭによって復号されたビットストリーム内のメタデータにおいて受信されるか、又は動き推定及び画像マッチングを使用して計算され得る。

【0009】

第２の態様の実装形態では、ズームコマンドは、倍率レベル（ＭＬ）を確立し、プロセッサは、第１及び第２のビデオのどの部分がディスプレイ上で可視にされるかを判定するためにＭＬを使用するように構成され得る。そのような場合では、プロセッサは、画質劣化をもたらす倍率レベルを回避するために、ＭＬについて上限及び下限を設定するように構成することができる。プロセッサはまた、ＭＬを増加させるズームコマンドに応答して、第１のビデオの可視画素の数を減少させ、第２のビデオの可視画素の数を増加させるように構成することができる。

【0010】

第２の態様の実装形態では、プロセッサは、２つの別個のビデオではなく単一のビデオを見ることの知覚を作成するために、ズームコマンドに関連付けられた倍率レベル（ＭＬ）、整合メトリック、及び同期のためのビデオに関連付けられた入力ビットストリームのフレーム番号を使用するために、ＲＭの少なくとも１つのシェーダを実行するように構成され得る。プロセッサは、ビデオ間の境界をマスクするために、少なくとも１つのシェーダを使用してビデオをフェザリングするように構成することができる。

【0011】

第２の態様のいくつかの実施形態では、プロセッサは、ズームコマンドによって確立された倍率レベル（ＭＬ）が、第２のビデオの一部が復号されず、ＤＭの少なくとも１つのデコーダが非アクティブ状態にあるような第１のＭＬであるときに、第２のビデオの少なくとも一部のレンダリングをスキップするように構成することができる。例示的なプロセッサは、ＭＬの変化に応答して、復号される現在のフレームがキーフレームであるときにのみ、少なくとも１つのデコーダを非アクティブ状態からアクティブ状態に変化させるように更に構成され得る。

【0012】

別の態様では、方法は、それぞれの第１、第２、及び第３のビデオを表す少なくとも第１、第２、及び第３のビットストリームを受信することを含む。方法は、少なくとも第１の要求倍率レベル（ＭＬ）に応答して、第１のビデオをレンダリングするために第１のデコーダで第１のビットストリームを復号し、第２のビデオをレンダリングするために第２のデコーダで第２のビットストリームを復号することと、第１及び第２のビデオをディスプレイ上に提示することとを含む。方法はまた、第１の要求ＭＬよりも大きい第２の要求ＭＬに応答して、第３のビデオをレンダリングするために第１のデコーダで第３のビットストリームを復号し、第２のビデオをレンダリングするために第２のデコーダで第２のビットストリームを復号することと、第２及び第３のビデオをディスプレイ上に提示することとを含む。

【0013】

この態様のいくつかの実施形態では、方法は、第１又は第２の要求ＭＬに従って各ビットストリームの復号された画素を表示するために、デコーダのうちの少なくとも１つから渡されたビットストリーム識別子（ＩＤ）を使用することを含む。少なくとも１つのビットストリームＩＤの変化に応答して、レンダリングは、異なるテクスチャ及びサンプリング座標を使用するように更新され得る。

【0014】

この第３の態様の実施例では、方法は、複数のビットストリームを処理するために第１のデコーダの同じインスタンスを使用することであって、ビットストリームのキーフレームは、ユーザーがＭＬをどのくらい速く増加又は減少させることができるかに従って整合され、均等に離間される、使用することと、各ビットストリームについてのキーフレーム位置及びオフセットを事前計算することとを含むことができる。更に、例示的な方法は、要求ＭＬに基づいて処理されるべき次のビットストリームを予測するために少なくとも１つのデコーダを使用することと、ＭＬの変化速度を促進するために、復号された画素を、復号された画素がディスプレイ上で可視にされる前に、レンダリングするように次のビットストリームを復号することと、を含み得る。

【0015】

本出願の詳細は、その構造及び動作の両方に関して、添付図面を参照することにより最良に理解することができ、図中の同様の参照番号は同様の部品を示す。

【図面の簡単な説明】

【0016】

【図1】本原理に従った例示的なシステムのブロック図である。

【図2】本原理に沿ったロジックの実施例をフローチャート形式で例証する。

【図3】Ｚ軸に沿って前方に移動することによってユーザーがズームすることを例証する。

【図4】ズームを概略的に例証する。

【図5】ビデオ間のオフセットを概略的に示す。

【図5A】例示的なレンダリングモジュール及び復号モジュールのブロック図である。

【図6】５台のカメラからの視野を例証する。

【図7】マルチＦＯＶ及びマルチ位置コンテンツキャプチャを例証する。

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

【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】

本明細書では、特定の実施形態を示し、詳細に説明するが、本発明によって包含される主題は、特許請求の範囲によってのみ限定されることを理解されたい。

【図1】

【図2】

【図3】

【図4】

【図5】

【図5A】

【図6】

【図7】

【国際調査報告】