JP7205485B2 - Ｖｒビデオ用に画像解像度を最適化してビデオストリーミングの帯域幅を最適化する画像処理のための方法及びストリーミングサーバ - Google Patents

Description

相互参照

[0001]本出願は、２０１８年３月２６日に出願された米国ユーティリティ特許出願第１５／９３５，３８１号に対する優先権を主張し、この米国ユーティリティ特許出願は、２０１７年３月３０日に出願された米国特許仮出願第６２／４７８，７８０号「ＭＥＴＨＯＤＳ ＡＮＤ ＡＰＰＡＲＡＴＵＳＥＳ ＴＯ ＯＰＴＩＭＩＺＥ ＲＥＳＯＬＵＴＩＯＮ ＡＮＤ ＢＡＮＤＷＩＤＴＨ ＦＯＲ ＶＲ ＶＩＤＥＯＳ」の恩恵を主張し、この米国特許仮出願は、参照によって本明細書に組み込まれる。

[0002]分野：実施形態は、パケットの送信元と送信先の間でのリアルタイム又は疑似リアルタイムのビデオ転送に関する。

[0003]背景：仮想現実（ＶＲ：ｖｉｒｔｕａｌ ｒｅａｌｉｔｙ）体験を生み出すための最も重要なアプローチの１つは、コンピュータ３次元（３Ｄ：ｔｈｒｅｅ－ｄｉｍｅｎｓｉｏｎａｌ）グラフィックスのみに頼るのではなく、既存のデジタルビデオの能力を再利用することである。このアプローチは、通常、ＶＲビデオ（例えば、１８０度ビデオ及び３６０度ビデオ）と呼ばれ、人工環境と現実世界のビデオキャプチャの両方に同様に適用され得る。このアプローチには、すでに大量に採用されているユーザデバイス（スマートフォン、パーソナルコンピュータ、及びＶＲヘッドグラスなど）における既存の能力を再利用するという利点がある。

[0004]従来の３Ｄグラフィックス手法と比較して、ＶＲビデオのアプローチの主な差別化要因は、４Ｋ超高解像度（ＵＨＤ：Ｕｌｔｒａ－Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ）テレビを使用しても、ユーザの満足なＶＲ没入体験を生み出すための適切なレベルの品質を提供するのに十分でないということである。また、スポーツ、コンサート、アクション映画などの種類のコンテンツのような、動的なシーンを含むほとんどのコンテンツで現実的な体験を提供するために必要なより高いフレームレートでは、毎秒６０フレームが必要最小限のフレームレートになる。それらの要件に加えて、立体ビデオ形式が、必要な情報量を２倍にすることさえある。その結果、高品質の信号を送信するために、４Ｋを超える解像度及び６０Ｍｂｐをはるかに超えるビットレートが必要になることがあり、この解像度及ビットレートは、既存のネットワークにわたるユーザデバイス及びプレーヤの大量の配置では、手に負えない。これらの高帯域幅及び高解像度の要件は、所得水準、地理、及びインターネット接続の成熟度などの要因に応じて、ユーザのために克服するべき困難な障害になるということが分かっており、したがって、アドレス可能な人口が大幅に狭められるということが考えられる。

[0005]ＶＲビデオ及びその高解像度の要件との関連において、既存のコード変換方法も、非常に高い計算能力の必要性をもたらすことがあり、ストリームを準備するための時間が指数関数的に増加する。もう１つの重要な結論は、高解像度及び信頼性を有するライブイベントの送信が、現在の技術では困難であるということである。

[0006]ユーザの３６０度ビデオ体験の品質、及びリアルタイムでのＶＲビデコンテンツの作成を含む高品質のＶＲビデオコンテンツが作成される速度を改善できる解決策が必要である。さらに、ＶＲビデオの送信を改善するための解決策が必要である。

概要

[0007]本開示は、３６０度ビデオ体験の品質及びリアルタイムでの高品質のＶＲビデオコンテンツを準備するための速度を改善できる解決策について説明する。この解決策は、既存のハードウェア、ビデオコーデック（コーダデコーダ）、及びストリーミングプロトコルとの互換性を維持したまま新しい方法で現在の問題を解決する。開示される解決策のその他の恩恵は、デバイスに課される追加要件がないことである。この解決策は、最適化された高品質のビットレートでインターネットを経由するストリーミングを可能にするサーバ及びクライアントの構成要素を含み、ライブコンテンツ及びファイルベースのコンテンツに適用できる。

[0008]本説明の第１の部分は、ビデオコンテンツの取り込み方法及び受信コンテンツを断片にセグメント化してリポジトリに格納するメカニズムを対象にする。そのようなセグメント化は、ワークフロー内のその後のステップにおいて並列プロセスで処理するときに、ライブビデオコンテンツの同期を可能にする。

[0009]本説明の態様によれば、この方法は、ＶＲビデオを処理し、解像度の大部分を入力画像の特定の領域に割り当てるビデオのセットにすることを対象にする。これらの特定の領域の各々は、ビューポートと呼ばれる。

[0010]本開示の別の態様は、適切なビューポート及び期間の生成を柔軟な方法で調整するために入力「レシピ」ファイルが使用されるプロセスについて説明する。

[0011]本開示のさらに別の態様は、方法が、ビューポートの中心の周囲の解像度を最大にするようにビューポート内のピクセルを割り当て直すための第２のメカニズムをさらに説明するということについて説明する。

[0012]本開示のさらに別の態様は、方法が、ビデオフレームスタンプのメカニズムを説明するということについて説明し、ビデオフレームスタンプは、ユーザに表示される最適化された各ビデオフレームの正確な特徴を決定するための方法をクライアント側のプレーヤに提供するために実行される。

[0013]本開示の別の態様は、適切なフレームスタンプのための望ましい値をビットストリームにマッピングするためのメカニズムについて説明する。

[0014]本開示の別の態様は、フレームスタンプのためのパリティに基づくデータ品質保証メカニズムについて説明する。

[0015]本開示のさらに別の態様は、柔軟性フレームスタンプが、ビューポートの実装及び切り替えに関して、幾何学的変換、投影、及びビデオ解像度のアプローチの価値ある混合を可能にするということについて説明する。

[0016]本開示のさらに別の態様は、生成されたビデオをエンコードしてパッケージ化するための、標準的なコーデック（ブロック指向の動き補償に基づくビデオ圧縮規格Ｈ．２６４又はＨ．２６５（又はＭＰＥＧ－４ Ｐａｒｔ １０）、Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＭＰＥＧ－４ ＡＶＣ）など）、及び標準的なメカニズム（ＭＰＥＧ－ＤＡＳＨ又はＨＬＳなど）に従う平均ビットレート（ＡＢＲ：ａｖｅｒａｇｅ ｂｉｔｒａｔｅ）の送信用のパッケージビューポートの利用について説明する。本開示は、立体ビデオの場合に、立体画像の一部において不必要な画像の複雑さを除去することによって（コーデックの実装を変更しないで）エンコーディング効率を改善するための第２のメカニズムも対象にする。

[0017]本開示の別の態様は、ビューポートの構造を識別するための追加の信号伝達メタデータの生成方法について説明する。

[0018]本開示のさらに別の態様は、ＶＲビデオコンテンツをデコードして提示するために行われる方法のクライアント側について説明する。

[0019]本開示のさらに別の態様は、生成されたメタデータをデコードしてビューポート構成に関する情報を受信し、ビューポート構成情報を使用して最も関連性のある最適化されたビューポートをフェッチ（fetch）するために、クライアントによって使用されるメカニズムを提示する。

[0020]本開示の別の態様は、デコードされたメタデータを使用して、特定のビューポート構成に従って受信ビデオフレームを適切に提示するために、クライアントによって使用されるメカニズムを提示する。

[0021]本開示のさらに別の態様は、適切なビューポートのストリームを選択するために使用されるユーザの頭部の位置を決定するために、クライアントのヘッドセットメカニズムの利用を提示する。

[0022]本開示のさらに別の態様は、未来の頭部の位置を推定するための予測モデルのクライアント側の利用についてさらに説明し、この未来の頭部の位置は、その後、クライアント側で適切なビューポートの要求をさらに最適化するために使用される。

[0023]本開示の別の態様は、より速いビューポート変更能力を可能にするために、２つ以上のビューポートを並行して要求する能力、及びビューポートの変更をユーザに切れ目なく表示できる瞬間を検出するためのメカニズムについて説明する。

[0024]本開示のさらに別の態様は、クライアントがフレームスタンプをデコードして、表示されようとしているフレームに関する情報を取得するメカニズム、及びフレームをユーザに表示するときに、投影されたビューポートにおいて調整が実行されるメカニズムについて説明する。

[0025]本開示のさらに別の態様は、フレームスタンプが適切に読み取られていることを保証するため、及び下位互換性を有効化するように機能するための、パリティに基づくデータ品質メカニズムの利用についてさらに説明する。

[0026]本開示の別の態様は、ビューポートのセットをリアルタイムに生成してパッケージ化できる並列処理メカニズムについてさらに説明する。

[0027]本開示のさらに別の態様は、ビデオの再生及びユーザの位置に関する情報がバックエンドの分析処理に返送されるデータ収集メカニズム、並びにユーザの体験及び行動について知るために収集される関連するデータ要素について説明する。

[0028]本開示のさらに別の態様は、クライアント側の予測において役立つ機械学習モデルをトレーニングするために、データを集約して処理するバックエンドのメカニズムをさらに示す。

[0029]本開示のこれら及びその他の態様並びに関連する実施形態は、以降の実施形態の詳細な開示を考慮して明らかになるであろう。

[0030]本開示の態様は、少なくとも８Ｋの解像度を有するビデオ入力を受信するステップと、受信されたビデオ入力を処理し、少なくともより多くのピクセルを第１の領域に、より少ないピクセルを第２の領域に割り当てる２つ以上のビューポートセグメントにするステップであって、受信されたビデオ入力を２つ以上のビューポートセグメントに処理することが並行して実行される、ステップと、第１の信号伝達情報を生成するステップであって、第１の信号伝達情報が外部のメタデータである、ステップと、第２の信号伝達情報を生成するステップであって、第２の信号伝達情報が外埋め込まれたメタデータである、ステップとを含む方法を対象にする。さらに、この方法は、処理されたビデオを再生するステップと、第１の信号伝達情報及び第２の信号伝達情報を１つ又は複数のビデオフレームに埋め込むステップと、受信されたビデオ入力をリアルタイムに処理するステップと、適応ビットレート表現を生成するステップとのうちの１つ又は複数を含むことができる。さらに、適応ビットレート表現を生成するステップは、立体ビデオの送信を最適化するためのフレーム処理プロセスをさらに含むように構成可能である。この方法は、凝視位置モニタと通信して適切なビューポートをフェッチする追加のステップと、再生のために、クライアント側で、埋め込まれたフレームメタデータをパース（parse）する追加のステップとを含むこともできる。さらに、一部の構成では、ユーザの予測された頭部の位置を計算し、予測された頭部の位置に応答して再生要求を調整するステップが含まれ得る。モデルの状態をフェッチするステップ、モデルの状態をトレーニングするステップ、及びモデルの状態を保存するステップも含まれ得る。

[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]ビデオフレーム内の黒色のスタンプでビット０を表し（図１０）、ビデオフレーム内の白色のスタンプでビット１を表す（図１１）、ビデオフレーム内のスタンプを示す図である。 [0067]ビデオフレーム内の黒色のスタンプでビット０を表し（図１０）、ビデオフレーム内の白色のスタンプでビット１を表す（図１１）、ビデオフレーム内のスタンプを示す図である。

[0068]層の深さが１（図１２）～３（図１４）に増えるビデオのスタンプビット構成のレイアウトを示す図であり、ビット配置及びエンコードできるビットの量における増加を示す。 [0068]層の深さが１（図１２）～３（図１４）に増えるビデオのスタンプビット構成のレイアウトを示す図であり、ビット配置及びエンコードできるビットの量における増加を示す。 [0068]層の深さが１（図１２）～３（図１４）に増えるビデオのスタンプビット構成のレイアウトを示す図であり、ビット配置及びエンコードできるビットの量における増加を示す。

[0069]意味のある値へのビットの可能なマッピング（例えば、５の深さのスタンプビット構成の場合のビットと１０進数の間のマッピング）を示す図であり、このマッピングは、スタンプから意味のある変数をエンコード及びデコードするために、サーバとクライアント側の間で共有されなければならない。

[0070]最適化されたＶＲビデオの望ましいセットを生成するために、処理命令（「レシピ」と呼ばれる）の完全なセットがパースされる、基本的なフロー図である。

[0071]最適化されたビューポートを生成するための例示的なレシピファイルを示す図である。 [0071]最適化されたビューポートを生成するための例示的なレシピファイルを示す図である。 [0071]最適化されたビューポートを生成するための例示的なレシピファイルを示す図である。 [0071]最適化されたビューポートを生成するための例示的なレシピファイルを示す図である。 [0071]最適化されたビューポートを生成するための例示的なレシピファイルを示す図である。

[0072]ＪＳＯＮ形式で生成された信号伝達情報に関して生成された、追加の信号伝達の例を示す図である。 [0072]ＪＳＯＮ形式で生成された信号伝達情報に関して生成された、追加の信号伝達の例を示す図である。

[0073]異なるヨーとピッチの組み合わせをカバーする８ビューポートのレイアウトを示すことによって、複数のビューポートを示す図である。

[0074]クライアント側の機能ブロックを示す図である。

[0075]オンデマンドのライブＶＲビデオの処理のための拡張性の考慮を示す図であり、各ケースでの計算ノードの増加を推進する主要な変数、及び各ケースで必要な一時的リポジトリを示す。 [0075]オンデマンドのライブＶＲビデオの処理のための拡張性の考慮を示す図であり、各ケースでの計算ノードの増加を推進する主要な変数、及び各ケースで必要な一時的リポジトリを示す。

[0076]クライアント側でのイベントの再生順序を示す図である。

[0077]さらに分析を実行するためにクライアントから収集されたデータ要素の一部の例を示す図である。

[0078]ＶＲビデオストリーミングにおいて利用される機械学習モデルのデータ処理のフローチャートを示す図である。

[0079]図２５に示されたフローを通ることができる視界方向モデルの具体的な特徴エンジニアリングチェーンを示す図である。 [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]モデルのトレーニング２５８０プロセスの間に生成され、モデルの状態の保存２５８２の間に格納されたモデルの加重及びパラメータは、１つ又は複数のクライアント２５１０によって利用されるよう意図されている。これは、処理されて格納されたモデルの加重及びパラメータが、未来の頭部の位置を予測するようにモデルをキャリブレートするために採用される加重を含むためである。この再生セッションに関連するモデルの状態は、モデルの取得段階２５１８で、リモートデータストアから取り出される。次に、ユーザの現在の頭部の位置が、システムによってヘッドセットから取得され、予測された頭部の位置が計算される（２５２２）ときに、特定の時間枠内の未来の頭部の位置の推定を生成するための推定モデルの入力として追加される（この予測の長さは、凝視位置モニタ２５２１の構成可能なパラメータである）。この頭部の位置の予測は、パースされ信号伝達メタデータと組み合わせて使用され、信号伝達デコーダ２３３２（図２３）が、この予測を使用して、予測された頭部の位置への最も近い角距離を有するビューポートを計算する。視点の計算が完了した後に、凝視位置モニタ２３３５で再生プロセスが続行し、その後、前述したように進む。

[0133]バックエンドの学習層２５００内のモデルトレーニングパイプラインは、使用可能なトレーニングサンプルの数に応じて使用される、さまざまなレベルの粒度に対応するように構成可能である。
レベル０ － 単一のマスターモデル
レベル１ － ヘッドセットの種類に固有のモデル
レベル２ －ユーザアカウントに固有のモデル
レベル３ － コンテンツの種類に固有のモデル
レベル4－ ヘッドセット及びユーザの両方に固有のモデル
レベル５－ ヘッドセット及びコンテンツの種類の両方に固有のモデル
レベル６－ ヘッドセット、コンテンツの種類、及びユーザのすべてに固有のモデル
これらのモデルは、モデルの状態のフェッチ２５７８の一部として別々のパイプライン内でフェッチされ、モデルのトレーニング２５８０の一部としてトレーニングされ、独立したモデルの状態が、モデルの状態の保存２５８２の一部として格納されるが、保存されたモデルのうちの１つのみが、モデルの状態取得２５１８の一部としてクライアント２５１０に提供される。どのモデルを提供するべきかを決定するためにシステムによって使用される基本論理は、最も高い資格を満たすモデルのレベルを選択することであり、モデルのレベルは、モデルのトレーニングに使用されるトレーニングサンプルの数が指定されたサンプルの最小しきい値を超える場合に、資格を満たすと見なされる。

[0134]開示された対象の態様に従うシステム及び方法は、さまざまなコンピュータ及びコンピューティングシステム、通信デバイス、ネットワーク、並びに／又はデジタル／論理デバイスを、動作に利用してもよい。さらにシステム及び方法の各々は、命令を使用して製造され、命令を搭載し、及び／又は何らかのストレージデバイスから命令をフェッチし、その後、命令を実行することができる、適切なコンピューティングデバイスを利用するように構成可能であってよく、それらの命令は、コンピューティングデバイスに、開示された対象の態様に従って方法を実行させる。本開示の特定の部分は、特定の各デバイスの計算能力に従って、有効化又は無効化されてよい。

[0135]コンピューティングデバイスは、携帯電話、スマートフォン及びセルラーフォン、パーソナルデジタルアシスタント（ＰＤＡ：ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ）、タブレット、ラップトップ、専用の仮想現実ヘッドマウントディスプレイ（ＨＭＤ：Ｈｅａｄ－Ｍｏｕｎｔｅｄ Ｄｉｓｐｌａｙ）などの、モバイルユーザデバイスを含むことができるが、これらに限定されない。少なくとも一部の構成では、ユーザは、インターネットなどのネットワークを経由してブラウザアプリケーションを実行し、画面表示などのデジタルコンテンツを表示して、操作することができる。表示は、例えば、コンピューティングデバイスからのデータの視覚的表現を可能にするインターフェイスを含む。他の形態のコンピューティングネットワーク及び／又は通信ネットワークを経由して、又は部分的に経由して、アクセスが可能である。ユーザは、Ｗｅｂブラウザにアクセスして、例えば、アプリケーション及びデータ並びにＷｅｂサイト上又はＷｅｂサイトのＷｅｂページ上にあるその他のコンテンツにアクセスすることができてよい。

[0136]適切なコンピューティングデバイスは、論理及びその他の計算動作を実行するためのプロセッサ（例えば、スタンドアロンのコンピュータ処理ユニット（ＣＰＵ：ｃｏｍｐｕｔｅｒ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）、又はマイクロコントローラにおけるような配線論理、或いはその組み合わせ）を含んでよく、オペレーティングシステムに従う命令、及び方法のステップ又はプロセスの要素を実行するための命令を実行してもよい。ユーザのコンピューティングデバイスは、コンピューティングデバイスのネットワークの一部であってよく、開示された対象の方法は、ネットワークに関連付けられたさまざまなコンピューティングデバイスによって、おそらくはさまざまな物理的位置で、開示された方法を実行するように連携して、又はその他の方法で相互作用して、実行されてよい。例えば、ユーザのポータブルコンピューティングデバイスは、アプリを単独で、又はインターネット上のサーバなどのリモートコンピューティングデバイスと連動して実行してもよい。本出願の目的では、「コンピューティングデバイス」という用語は、前述した論理回路、通信デバイス、及びデジタル処理能力、又はこれらの組み合わせのいずれか又はすべてを含む。

[0137]開示された対象の特定の実施形態は、ソフトウェアを実行するコンピューティングデバイス上で実行されてよい方法のステップとして、例示の目的で説明されてよく、プロセスフローのブロック図として、単に例として示されてよい。そのような実施形態は、ソフトウェアフローチャートと見なされてもよい。実行される方法又はコンピューティングデバイスの動作のそのようなブロック図などの動作の説明、及びブロック図内のブロックの組み合わせは、例として、コンピューティングデバイスに提供され得るソフトウェアプログラムコード／命令、又は命令の実行中にコンピューティングデバイスによって実行される機能及び動作の少なくとも短縮された記述を示すことができる。一部の可能な代替の実装は、ブロック図のブロックに示された関数、機能、及び動作が、同時若しくはほぼ同時に発生すること、又は別の順序で発生すること、或いは全く発生しないことを含む、ブロック図に示された順序と異なる順序で発生することを含んでよい。開示された対象の態様は、例えばインターネットなどを含む相互接続されたネットワークを経由する、コンピューティングデバイスのアレイ又はネットワーク内で、同じ場所に配置されたか、又は少なくとも一部において互いにリモートに配置された、ハードウェア、ファームウェア、ソフトウェア、又はこれらの任意の組み合わせ（複数可）において、並列に又は逐次的に実装されてよい。

[0138]命令は、コンピューティングデバイス内にあるか、又はコンピューティングデバイスが通信若しくはその他の方法でアクセスできる、適切な「機械可読媒体」に格納されてよい。本出願で使用されるとき、機械可読媒体は有形のストレージデバイスであり、命令は非一時的方法で格納される。同時に、動作中に命令は、時々、例えば通信リンクを経由したリモートストレージデバイスからコンピューティングデバイスへの送信中に、一時的であってよい。しかし、機械可読媒体が有形且つ非一時的である場合、命令は、少なくともある期間の間、ランダムアクセスメモリ（ＲＡＭ：ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、読み取り専用メモリ（ＲＯＭ：ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、磁気ディスクストレージデバイス又は光ディスクストレージデバイスなどの、メモリストレージデバイスに格納され、それらのメモリストレージデバイスのアレイ及び／又は組み合わせが、ローカルキャッシュメモリ（例えば、プロセッサの集積回路上に存在する）、ローカルメインメモリ（例えば、コンピューティングデバイスのプロセッサ、ローカル電子又はディスクハードドライブ、ローカルサーバ又はネットワークを経由するリモートサーバアクセスに接続されたリモートストレージの場所の、筐体内に収容される）などを形成してもよい。そのように格納される場合、ソフトウェアは、有形の、命令を非一時的形態で格納する「機械可読媒体」を構成する。したがって、少なくとも、関連するコンピューティングデバイス上で実行するための命令を格納する機械可読媒体は、コンピューティングデバイスのプロセッサによる命令の実行時、及び命令がコンピューティングデバイスによるその後のアクセスのために格納されているときに、「有形」且つ「非一時的」になる。

[0139]本明細書では、本発明の好ましい実施形態が示され、説明されたが、そのような実施形態が単に例として提供されているということは、当業者にとって明らかであろう。当業者は、本発明から逸脱することなく、多くの変形、変更、及び代替に思い当たるであろう。本明細書に記載された本発明の実施形態のさまざまな代替手段が、本発明の実践において採用されてよいということが、理解されるべきである。以下の特許請求の範囲が本発明の範囲を定義し、以て、以下の特許請求の範囲内の方法及び構造並びにそれらと同等のものが対象にされるということが意図される。
［発明の項目］
［項目１］
方法であって、
少なくとも８Ｋの解像度を有するビデオ入力を受信するステップと、
前記受信されたビデオ入力を処理し、少なくともより多くのピクセルを第１の領域に、より少ないピクセルを第２の領域に割り当てる２つ以上のビューポートセグメントにするステップであって、前記受信されたビデオ入力を２つ以上のビューポートセグメントに処理することが並行して実行される、ステップと、
第１の信号伝達情報を生成するステップであって、前記第１の信号伝達情報が外部のメタデータである、ステップと、
第２の信号伝達情報を生成するステップであって、前記第２の信号伝達情報が埋め込まれたメタデータである、ステップと、
を含む、方法。
［項目２］
前記処理されたビデオを再生するステップをさらに含む、項目１に記載の方法。
［項目３］
前記第１の信号伝達情報及び前記第２の信号伝達情報を１つ又は複数のビデオフレームに埋め込むステップをさらに含む、項目１に記載の方法。
［項目４］
前記受信されたビデオ入力をリアルタイムに処理するステップをさらに含む、項目１に記載の方法。
［項目５］
適応ビットレート表現を生成するステップをさらに含む、項目１に記載の方法。
［項目６］
適応ビットレート表現を生成する前記ステップが、立体ビデオの送信を最適化するためのフレーム処理プロセスをさらに含む、項目５に記載の方法。
［項目７］
適切なビューポートをフェッチするために凝視位置モニタと通信するステップと、再生のために、クライアント側で、埋め込まれたフレームメタデータをパースするステップと、をさらに含む、項目１に記載の方法。
［項目８］
ユーザの予測された頭部の位置を計算し、前記予測された頭部の位置に応答して再生要求を調整するステップをさらに含む、項目７に記載の方法。
［項目９］
モデルの状態をフェッチするステップと、前記モデルの状態をトレーニングするステップと、前記モデルの状態を保存するステップと、をさらに含む、項目１に記載の方法。
［項目１０］
ストリーミングサーバであって、
メモリと、
コントローラであって、前記コントローラが、
少なくとも８Ｋの解像度を有するビデオ入力を受信することと、
前記ビデオ入力を処理し、より多くのピクセルを第１の領域に割り当て、その結果、より少ないピクセルが第２の領域に割り当てられる２つ以上のビューポートセグメントにし、前記２つ以上のビューポートセグメントが、並行して作成されることと、
外部のメタデータと、前記ビデオフレームに埋め込まれたメタデータとの両方として信号伝達情報を生成することと、
前記処理されたビデオ入力を、デバイスがストリーミングするための標準的なストリーム発生源フォルダーに配信することと、
を実行するように構成されている、コントローラと、
を備える、ストリーミングサーバ。
［項目１１］
前記コントローラが、第１のプロセスとして前記入力ビデオをセグメント化することと、セグメント化されたソースから前記処理タスクを設定することと、を実行するようにさらに構成されている、項目１０に記載のストリーミングサーバ。
［項目１２］
前記コントローラが、保留中の処理タスクを検出して、それらの処理タスクのみを処理するようにさらに構成されており、そのような複数のサーバが並行して効率的に動作できるようにする、項目１０に記載のストリーミングサーバ。
［項目１３］
前記コントローラが、立体ビデオの送信をさらに最適化するために、追加の任意選択的フレーム処理を伴って適応ビットレート表現を生成するように、さらに構成されている、項目１０に記載のストリーミングサーバ。
［項目１４］
方法であって、
２つ以上のビデオフレームを含む少なくとも８Ｋの解像度を有するビデオ入力をシステムに受信するステップと、
前記受信されたビデオ入力を処理し、少なくともより多くのピクセルを第１の領域に、より少ないピクセルを第２の領域に割り当てる２つ以上のビューポートセグメントにするステップであって、前記受信されたビデオ入力を２つ以上のビューポートセグメントに処理することが並行して実行される、ステップと、
第１の信号伝達情報を外部のメタデータとして生成し、第２の信号伝達情報を前記２つ以上のビデオフレームに埋め込まれたメタデータとして生成するステップと、
処理されたビデオ入力を前記システムからクライアントデバイスに配信するステップと、
を含む、方法。
［項目１５］
埋め込まれたメタデータを前記ビデオフレームに追加するステップと、ビューポートの追加の信号伝達情報を生成するステップと、をさらに含む、項目１４に記載の方法。
［項目１６］
立体ビデオの送信をさらに最適化するために、追加の任意選択的フレーム処理を伴って適応ビットレート表現を生成するステップをさらに含む、項目１４に記載の方法。
［項目１７］
方法であって、
少なくとも８Ｋの解像度を有するビデオ入力を受信するステップと、
前記受信されたビデオ入力を処理するステップと、
第１の信号伝達情報を生成するステップであって、前記第１の信号伝達情報が外部のメタデータである、ステップと、
第２の信号伝達情報を生成するステップであって、前記第２の信号伝達情報が埋め込まれたメタデータである、ステップと、
前記第１の信号伝達情報及び前記第２の信号伝達情報を１つ又は複数のビデオフレームに埋め込むステップと、
を含む、方法。
［項目１８］
前記処理されたビデオを再生するステップをさらに含む、項目１７に記載の方法。
［項目１９］
前記受信されたビデオ入力を処理し、少なくともより多くのピクセルを第１の領域に、より少ないピクセルを第２の領域に割り当てる２つ以上のビューポートセグメントにするステップであって、前記受信されたビデオ入力を２つ以上のビューポートセグメントに処理することが並行して実行される、ステップをさらに含む、項目１７に記載の方法。
［項目２０］
前記受信されたビデオ入力をリアルタイムに処理するステップをさらに含む、項目１７に記載の方法。
［項目２１］
適応ビットレート表現を生成するステップをさらに含む、項目１７に記載の方法。
［項目２２］
適応ビットレート表現を生成する前記ステップが、立体ビデオの送信を最適化するためのフレーム処理プロセスをさらに含む、項目２１に記載の方法。
［項目２３］
適切なビューポートをフェッチするために凝視位置モニタと通信するステップと、再生のために、クライアント側で、埋め込まれたフレームメタデータをパースするステップと、をさらに含む、項目１７に記載の方法。
［項目２４］
ユーザの予測された頭部の位置を計算し、前記予測された頭部の位置に応答して再生要求を調整するステップをさらに含む、項目２３に記載の方法。
［項目２５］
モデルの状態をフェッチするステップと、前記モデルの状態をトレーニングするステップと、前記モデルの状態を保存するステップと、をさらに含む、項目１７に記載の方法。
［項目２６］
ストリーミングサーバであって、
メモリと、
コントローラであって、前記コントローラが、
少なくとも８Ｋの解像度を有するビデオ入力を受信することと、
前記ビデオ入力を処理することと、
セグメント化されたソースから第１のプロセスとして、前記入力ビデオをセグメント化することと、
外部のメタデータと、前記ビデオフレームに埋め込まれたメタデータとの両方として信号伝達情報を生成することと、
前記処理されたビデオ入力を、デバイスがストリーミングするための標準的なストリーム発生源フォルダーに配信することと、
を実行するように構成されている、コントローラと、
を備える、ストリーミングサーバ。
［項目２７］
前記コントローラが、前記ビデオ入力を処理し、より多くのピクセルを第１の領域に割り当て、その結果、より少ないピクセルが第２の領域に割り当てられる２つ以上のビューポートセグメントにし、前記２つ以上のビューポートセグメントが、並行して作成されることを実行するようにさらに構成されている、項目２６に記載のストリーミングサーバ。
［項目２８］
前記コントローラが、保留中の処理タスクを検出して、それらの処理タスクのみを処理するようにさらに構成されており、そのような複数のサーバが並行して効率的に動作できるようにする、項目２６に記載のストリーミングサーバ。
［項目２９］
前記コントローラが、立体ビデオの送信をさらに最適化するために、追加の任意選択的フレーム処理を伴って適応ビットレート表現を生成するように、さらに構成されている、項目２６に記載のストリーミングサーバ。
［項目３０］
方法であって、
２つ以上のビデオフレームを含む少なくとも８Ｋの解像度を有するビデオ入力をシステムに受信するステップと、
前記受信されたビデオ入力を処理するステップと、
第１の信号伝達情報を生成するステップであって、前記第１の信号伝達情報が外部のメタデータである、ステップと、
第２の信号伝達情報を生成するステップであって、前記第２の信号伝達情報が埋め込まれたメタデータである、ステップと、
前記第１の信号伝達情報及び前記第２の信号伝達情報を１つ又は複数のビデオフレームに埋め込むステップと、
処理されたビデオ入力を前記システムからクライアントデバイスに配信するステップと、
を含む、方法。
［項目３１］
埋め込まれたメタデータを前記ビデオフレームに追加するステップと、ビューポートの追加の信号伝達情報を生成するステップと、をさらに含む、項目３０に記載の方法。
［項目３２］
立体ビデオの送信をさらに最適化するために、追加の任意選択的フレーム処理を伴って適応ビットレート表現を生成するステップをさらに含む、項目３１に記載の方法。
［項目３３］
方法であって、
少なくとも８Ｋの解像度を有するビデオ入力を受信するステップと、
前記受信されたビデオ入力を２つ以上のビューポートセグメントに処理するステップと、
第１の信号伝達情報を生成するステップであって、前記第１の信号伝達情報が外部のメタデータである、ステップと、
第２の信号伝達情報を生成するステップであって、前記第２の信号伝達情報が埋め込まれたメタデータである、ステップと、
適切なビューポートをフェッチするために凝視位置モニタと通信するステップと、
を含む、方法。
［項目３４］
前記処理されたビデオを再生するステップをさらに含む、項目３３に記載の方法。
［項目３５］
前記第１の信号伝達情報及び前記第２の信号伝達情報を１つ又は複数のビデオフレームに埋め込むステップをさらに含む、項目３３に記載の方法。
［項目３６］
前記受信されたビデオ入力をリアルタイムに処理するステップをさらに含む、項目３３に記載の方法。
［項目３７］
適応ビットレート表現を生成するステップをさらに含む、項目３３に記載の方法。
［項目３８］
適応ビットレート表現を生成する前記ステップが、立体ビデオの送信を最適化するためのフレーム処理プロセスをさらに含む、項目３７に記載の方法。
［項目３９］
再生のために、クライアント側で、埋め込まれたフレームメタデータをパースするステップをさらに含む、項目３３に記載の方法。
［項目４０］
ユーザの予測された頭部の位置を計算し、前記予測された頭部の位置に応答して再生要求を調整するステップをさらに含む、項目３９に記載の方法。
［項目４１］
モデルの状態をフェッチするステップと、前記モデルの状態をトレーニングするステップと、前記モデルの状態を保存するステップと、をさらに含む、項目３３に記載の方法。
［項目４２］
ストリーミングサーバであって、
メモリと、
コントローラであって、前記コントローラが、
少なくとも８Ｋの解像度を有するビデオ入力を受信することと、
前記ビデオ入力を処理することと、
外部のメタデータと、前記ビデオフレームに埋め込まれたメタデータとの両方として信号伝達情報を生成することと、
前記処理されたビデオ入力を、デバイスがストリーミングするための標準的なストリーム発生源フォルダーに配信することと、
適切なビューポートをフェッチするために凝視位置モニタと通信することと、
を実行するように構成されている、コントローラと、
を備える、ストリーミングサーバ。
［項目４３］
前記コントローラが、第１のプロセスとして前記入力ビデオをセグメント化することと、セグメント化されたソースから前記処理タスクを設定することと、を実行するようにさらに構成されている、項目４２に記載のストリーミングサーバ。
［項目４４］
前記コントローラが、保留中の処理タスクを検出して、それらの処理タスクのみを処理するようにさらに構成されており、そのような複数のサーバが並行して効率的に動作できるようにする、項目４２に記載のストリーミングサーバ。
［項目４５］
前記コントローラが、立体ビデオの送信をさらに最適化するために、追加の任意選択的フレーム処理を伴って適応ビットレート表現を生成するように、さらに構成されている、項目４２に記載のストリーミングサーバ。
［項目４６］
方法であって、
２つ以上のビデオフレームを含む少なくとも８Ｋの解像度を有するビデオ入力をシステムに受信するステップと、
前記受信されたビデオを処理するステップと、
第１の信号伝達情報を外部のメタデータとして生成し、第２の信号伝達情報を前記２つ以上のビデオフレームに埋め込まれたメタデータとして生成するステップと、
適切なビューポートをフェッチするために凝視位置モニタと通信するステップと、
を含む、方法。
［項目４７］
埋め込まれたメタデータを前記ビデオフレームに追加するステップと、ビューポートの追加の信号伝達情報を生成するステップと、をさらに含む、項目４６に記載の方法。
［項目４８］
立体ビデオの送信をさらに最適化するために、追加の任意選択的フレーム処理を伴って適応ビットレート表現を生成するステップをさらに含む、項目４７に記載の方法。
［項目４９］
方法であって、
少なくとも８Ｋの解像度を有するビデオ入力を受信するステップと、
２つ以上のビデオフレームを含む前記受信されたビデオ入力を処理するステップであって、各ビデオフレームが前半及び後半を含む、ステップと、
第１のビデオフレームの前記前半においてビットレートを増やし、前記第１のビデオフレームの前記後半においてビットレートを減らすステップと、
ビデオ入力全体のエンコードされたビットレートを減らすステップと、
を含む、方法。
［項目５０］
前記処理されたビデオを再生するステップをさらに含む、項目４９に記載の方法。
［項目５１］
第１の信号伝達情報及び第２の信号伝達情報を１つ又は複数のビデオフレームに埋め込むステップをさらに含む、項目４９に記載の方法。
［項目５２］
前記受信されたビデオ入力をリアルタイムに処理するステップをさらに含む、項目４９に記載の方法。
［項目５３］
適応ビットレート表現を生成するステップをさらに含む、項目４９に記載の方法。
［項目５４］
適応ビットレート表現を生成する前記ステップが、立体ビデオの送信を最適化するためのフレーム処理プロセスをさらに含む、項目５３に記載の方法。
［項目５５］
適切なビューポートをフェッチするために凝視位置モニタと通信するステップと、再生のために、クライアント側で、埋め込まれたフレームメタデータをパースするステップと、をさらに含む、項目４９に記載の方法。
［項目５６］
ユーザの予測された頭部の位置を計算し、前記予測された頭部の位置に応答して再生要求を調整するステップをさらに含む、項目５５に記載の方法。
［項目５７］
モデルの状態をフェッチするステップと、前記モデルの状態をトレーニングするステップと、前記モデルの状態を保存するステップと、をさらに含む、項目４９に記載の方法。
［項目５８］
ストリーミングサーバであって、
メモリと、
コントローラであって、前記コントローラが、
少なくとも８Ｋの解像度を有するビデオ入力を受信することと、
第１のビデオフレームの前記前半においてビットレートを増やし、前記第１のビデオフレームの前記後半においてビットレートを減らすことと、
ビデオ入力全体のエンコードされたビットレートを減らすことと、
を実行するように構成されている、コントローラと、
を備える、ストリーミングサーバ。
［項目５９］
前記コントローラが、第１のプロセスとして前記入力ビデオをセグメント化することと、セグメント化されたソースから前記処理タスクを設定することと、を実行するようにさらに構成されている、項目５８に記載のストリーミングサーバ。
［項目６０］
前記コントローラが、保留中の処理タスクを検出して、それらの処理タスクのみを処理するようにさらに構成されており、そのような複数のサーバが並行して効率的に動作できるようにする、項目５８に記載のストリーミングサーバ。
［項目６１］
前記コントローラが、立体ビデオの送信をさらに最適化するために、追加の任意選択的フレーム処理を伴って適応ビットレート表現を生成するように、さらに構成されている、項目５８に記載のストリーミングサーバ。
［項目６２］
方法であって、
２つ以上のビデオフレームを含む少なくとも８Ｋの解像度を有するビデオ入力をシステムに受信するステップと、
前記受信されたビデオ入力を処理し、少なくともより多くのピクセルを第１の領域に、より少ないピクセルを第２の領域に割り当てる２つ以上のビューポートセグメントにするステップであって、前記受信されたビデオ入力を２つ以上のビューポートセグメントに処理することが並行して実行される、ステップと、
第１の信号伝達情報を外部のメタデータとして生成し、第２の信号伝達情報を前記２つ以上のビデオフレームに埋め込まれたメタデータとして生成するステップと、
処理されたビデオ入力を前記システムからクライアントデバイスに配信するステップと、
を含む、方法。
［項目６３］
埋め込まれたメタデータを前記ビデオフレームに追加するステップと、ビューポートの追加の信号伝達情報を生成するステップと、をさらに含む、項目６２に記載の方法。
［項目６４］
立体ビデオの送信をさらに最適化するために、追加の任意選択的フレーム処理を伴って適応ビットレート表現を生成するステップをさらに含む、項目６３に記載の方法。

Claims (20)

1. コンピューティングデバイスによって実行される方法であって、
   ２つ以上のビデオフレームを含む少なくとも８Ｋの解像度とソース画像を有する仮想現実ビデオ入力を受信するステップと、
   入力された前記画像の幾何学的変換を有する第１のビューポートに前記受信された仮想現実ビデオ入力を処理するステップであって、
   前記幾何学的変換は、第１の適応ビットレートターゲットについて前記仮想現実ビデオ入力のパノラマ画像全体の第１の頭部位置からの第１のターゲット投影にて再マッピングされた画像を生成し、
   前記再マッピングされた前記画像の一部分にはより大きな解像度が割り当てられ、再マッピングされた前記画像の残りにはより小さな解像度が割り当てられ、
   再マッピングされた前記画像は、
   立体ビデオの送信を最適化するために処理される、ステップと、
   第２の適応ビットレートターゲットにて第２の頭部位置からの第２のビューポートに前記仮想現実ビデオ入力を処理することを繰り返すステップと、
   全ての処理されたビューポートについての第１の信号伝達情報を生成するステップであって、前記第１の信号伝達情報が、メディアストリームとは別個のＪＳОＮ形式ファイルを示す外部のメタデータである、ステップと、
   前記２つ以上のビデオフレームの一のビデオフレームに対応する特定のビューポートから第２の信号伝達情報を生成するステップであって、前記第２の信号伝達情報が、前記一のビデオフレームに埋め込まれたメタデータである、ステップと、
   を含む、方法。
2. 前記処理された仮想現実ビデオを再生するステップをさらに含む、請求項１に記載の方法。
3. 前記受信された仮想現実ビデオ入力をリアルタイムに処理するステップをさらに含む、請求項１に記載の方法。
4. 適切なビューポートをフェッチするために凝視位置モニタと通信するステップと、再生のために、クライアント側で、埋め込まれたフレームメタデータをパースするステップと、をさらに含む、請求項１に記載の方法。
5. ユーザの予測された頭部の位置を計算し、前記予測された頭部の位置に応答して再生要求を調整するステップをさらに含む、請求項４に記載の方法。
6. 機械学習エンジンにデータを送信するステップと、頭部位置の予測位置を特定するために機械学習モデルの状態をフェッチするステップと、複数のソースからの集約されたデータを用いて前記機械学習モデルの状態をトレーニングするステップと、クライアントデバイスによる後のアクセスのために前記モデルの状態を保存するステップと、をさらに含む、請求項１に記載の方法。
7. ストリーミングサーバであって、
   メモリと、
   コントローラであって、前記コントローラが、
   ２つ以上のビデオフレームを含む少なくとも８Ｋの解像度とソース画像を有する仮想現実ビデオ入力を受信することと、
   入力された前記画像の幾何学的変換を有する第１のビューポートに前記仮想現実ビデオ入力を処理することであって、
   前記幾何学的変換は、第１の適応ビットレートターゲットについて前記仮想現実ビデオ入力のパノラマ画像全体の第１の頭部位置からの第１のターゲット投影にて再マッピングされた画像を生成し、
   前記再マッピングされた前記画像の一部分にはより大きな解像度が割り当てられ、再マッピングされた前記画像の残りにはより小さな解像度が割り当てられ、
   再マッピングされた前記画像は、
   立体ビデオの送信を最適化するために処理される、処理することと、
   第２の適応ビットレートターゲットにて第２の頭部位置からの第２のビューポートに前記仮想現実ビデオ入力を再処理することと、
   メディアストリームとは別個のＪＳОＮ形式ファイルを示す外部のメタデータと、前記ビデオフレームに埋め込まれたメタデータとの両方として、全ての処理されたビューポートについての信号伝達情報を生成することであり、
   前記信号伝達情報の一部が、前記外部のメタデータに適用され、
   前記信号伝達情報の別の一部が、前記埋め込まれたメタデータに適用され、
   前記信号伝達情報のさらに別の一部が、前記外部のメタデータ及び前記埋め込まれたメタデータの両方に適用される、
   生成することと、
   前記処理された仮想現実ビデオ入力を、デバイスがストリーミングするための標準的なストリーム発生源フォルダーに配信することと、
   を実行するように構成されている、コントローラと、
   を備える、ストリーミングサーバ。
8. 前記コントローラが、第１のプロセスとして前記仮想現実ビデオ入力をセグメント化することと、セグメント化されたソースから処理タスクを設定することと、を実行するようにさらに構成されている、請求項７に記載のストリーミングサーバ。
9. 前記コントローラが、保留中の処理タスクを検出するようにさらに構成されており、各プロセスが単一のファイルに割り当てられ、並列プロセスが、まだ処理されていない異なる名前を有する複数のファイルについて生じる、請求項７に記載のストリーミングサーバ。
10. コンピューティングデバイスによって実行される方法であって、
    ２つ以上のビデオフレームを含む少なくとも８Ｋの解像度とソース画像を有する仮想現実ビデオ入力をシステムに受信するステップと、
    入力された前記画像の幾何学的変換を有するビューポートに前記受信された仮想現実ビデオ入力を処理するステップであって、前記幾何学的変換は、第１の適応ビットレートターゲットについて前記仮想現実ビデオ入力のパノラマ画像全体の第１の頭部位置からの第１のターゲット投影にて再マッピングされた画像を生成し、
    前記再マッピングされた前記画像の一部分にはより大きな解像度が割り当てられ、再マッピングされた前記画像の残りにはより小さな解像度が割り当てられ、
    再マッピングされた前記画像は、
    立体ビデオの送信を最適化するために処理される、ステップと、
    第２の適応ビットレートターゲットにて前記仮想現実ビデオ入力の各フレームについてのビューポートに前記仮想現実ビデオ入力を処理することを繰り返すステップと、
    全ての処理されたビューポートについての第１の信号伝達情報を、メディアストリームとは別個のＪＳОＮ形式ファイルを示す外部のメタデータとして生成し、前記２つ以上のビデオフレームの一のビデオフレームに対応する特定のビューポートについて第２の信号伝達情報を前記２つ以上のビデオフレームの前記一のビデオフレームに埋め込まれたメタデータとして生成するステップと、
    処理されたビデオ出力を前記システムからクライアントデバイスに配信するステップであって、処理された前記ビデオ出力の各フレームが低密度ピクセル領域および高密度ピクセル領域を有する、ステップと、
    を含む、方法。
11. コンピューティングデバイスによって実行される方法であって、
    ２つ以上のビデオフレームを含む少なくとも８Ｋの解像度とソース画像を有するビデオ入力を受信するステップと、
    入力された前記画像の幾何学的変換を有する第１のビューポートに前記受信されたビデオ入力を処理するステップであって、
    前記幾何学的変換は、第１の適応ビットレートターゲットについて前記ビデオ入力のパノラマ画像全体の第１の頭部位置からの第１のターゲット投影にて再マッピングされた画像を生成し、
    前記再マッピングされた前記画像の一部分にはより大きな解像度が割り当てられ、再マッピングされた前記画像の残りにはより小さな解像度が割り当てられる、ステップと、
    第２の適応ビットレートターゲットにて第２の頭部位置からの第２のビューポートに前記ビデオ入力を処理することを繰り返すステップと、
    全ての処理されたビューポートについての第１の信号伝達情報を生成するステップであって、前記第１の信号伝達情報が、メディアストリームとは別個のＪＳОＮ形式ファイルを示す外部のメタデータである、ステップと、
    前記２つ以上のビデオフレームの一のビデオフレームに対応する特定のビューポートから第２の信号伝達情報を生成するステップであって、前記第２の信号伝達情報が、前記一のビデオフレームに埋め込まれたメタデータである、ステップと、
    機械学習エンジンにデータを送信するステップと、頭部位置の予測位置を特定するために機械学習モデルの状態をフェッチするステップと、複数のソースからの集約されたデータを用いて前記機械学習モデルの状態をトレーニングするステップと、クライアントデバイスによる後のアクセスのために前記モデルの状態を保存するステップと、
    を含む、方法。
12. 前記処理された仮想現実ビデオを再生するステップをさらに含む、請求項１１に記載の方法。
13. 前記受信された仮想現実ビデオ入力をリアルタイムに処理するステップをさらに含む、請求項１１に記載の方法。
14. 適切なビューポートをフェッチするために凝視位置モニタと通信するステップと、再生のために、クライアント側で、埋め込まれたフレームメタデータをパースするステップと、をさらに含む、請求項１１に記載の方法。
15. ユーザの予測された頭部の位置を計算し、前記予測された頭部の位置に応答して再生要求を調整するステップをさらに含む、請求項１４に記載の方法。
16. 立体ビデオの送信を最適化するためのフレーム処理プロセスを有する適応ビットレート表現を生成するステップをさらに含む、請求項１１に記載の方法。
17. ストリーミングサーバであって、
    メモリと、
    コントローラであって、前記コントローラが、
    ２つ以上のビデオフレームを含む少なくとも８Ｋの解像度とソース画像を有するビデオ入力を受信することと、
    入力された前記画像の幾何学的変換を有する第１のビューポートに前記ビデオ入力を処理することであって、
    前記幾何学的変換は、第１の適応ビットレートターゲットについて前記ビデオ入力のパノラマ画像全体の第１の頭部位置からの第１のターゲット投影にて再マッピングされた画像を生成し、
    前記再マッピングされた前記画像の一部分にはより大きな解像度が割り当てられ、再マッピングされた前記画像の残りにはより小さな解像度が割り当てられる、
    処理することと、
    第２の適応ビットレートターゲットにて第２の頭部位置からの第２のビューポートに前記ビデオ入力を再処理することと、
    メディアストリームとは別個のＪＳОＮ形式ファイルを示す外部のメタデータと、前記ビデオフレームに埋め込まれたメタデータとの両方として全ての処理されたビューポートについての信号伝達情報を生成することであり、
    前記信号伝達情報の一部が、前記外部のメタデータに適用され、
    前記信号伝達情報の別の一部が、前記埋め込まれたメタデータに適用され、
    前記信号伝達情報のさらに別の一部が、前記外部のメタデータ及び前記埋め込まれたメタデータの両方に適用される、
    生成することと、
    前記処理されたビデオ入力を、デバイスがストリーミングするための標準的なストリーム発生源フォルダーに配信することと、
    機械学習エンジンにデータを送信し、頭部位置の予測位置を特定するために機械学習モデルの状態をフェッチし、複数のソースからの集約されたデータを用いて前記機械学習モデルの状態をトレーニングし、クライアントデバイスによる後のアクセスのために前記モデルの状態を保存することと、
    を実行するように構成されている、コントローラと、
    を備える、ストリーミングサーバ。
18. 前記コントローラが、第１のプロセスとして前記ビデオ入力をセグメント化することと、セグメント化されたソースから処理タスクを設定することと、を実行するようにさらに構成されている、請求項１７に記載のストリーミングサーバ。
19. 前記コントローラが、保留中の処理タスクを検出するようにさらに構成されており、各プロセスが単一のファイルに割り当てられ、並列プロセスが、まだ処理されていない異なる名前を有する複数のファイルについて生じる、請求項１７に記載のストリーミングサーバ。
20. 前記コントローラが、立体ビデオの送信をさらに最適化するためのフレーム処理プロセスを有する適応ビットレート表現を生成するように、さらに構成されている、請求項１９に記載のストリーミングサーバ。

Images