JP2023544383A - 制御及びデータプレーンチャネルを使用した双方向プレゼンテーションデータストリーム - Google Patents

Abstract

本開示の態様は、メディア処理のための方法及び装置を提供する。いくつかの実施例において、装置は処理回路を含む。処理回路は、第１トランスポートプロトコルを使用する制御プレーンチャネルの上で、サーバデバイスと、複数の制御メッセージを交換できる。複数の制御メッセージは、イマーシブメディア配信のための双方向プロトコルの制御プレーンに属する。処理回路は、サーバデバイスから、第２トランスポートプロトコルを使用する第１データプレーンチャネルの上で、第１の複数のデータメッセージを受信する。第１の複数のデータメッセージは、双方向プロトコルのデータプレーンに属し、イマーシブメディアコンテンツを搬送する。処理回路は、第１の複数のデータメッセージによって搬送されるイマーシブメディアコンテンツを提示する。

Description

参照による援用
本出願は、２０２２年６月２８日に出願された米国特許出願第１７／８５１，８３８号 「ＢＩＤＩＲＥＣＴＩＯＮＡＬ ＰＲＥＳＥＮＴＡＴＩＯＮ ＤＡＴＡＳＴＲＥＡＭ ＵＳＩＮＧ ＣＯＮＴＲＯＬ ＡＮＤ ＤＡＴＡ ＰＬＡＮＥ ＣＨＡＮＮＥＬＳ」 に基づく優先権の利益を主張するものであり、同出願は、２０２１年６月３０日に出願された米国仮出願第６３／２１７，０４９号 「ＩＮＴＥＬＬＩＧＥＮＴ ＢＩＤＩＲＥＣＴＩＯＮＡＬ ＰＲＥＳＥＮＴＡＴＩＯＮ ＤＡＴＡＳＴＲＥＡＭ ＵＳＩＮＧ ＣＯＮＴＲＯＬ ＡＮＤ ＤＡＴＡ ＰＬＡＮＥ ＣＨＡＮＮＥＬＳ」 に基づく優先権の利益を主張するものである。先の出願の開示は、その全体が参照により本明細書に組み込まれる。

技術分野
本開示は、概してメディア処理及び配信に関連する実施形態について説明する。

本明細書で提供される背景説明は、本開示のコンテキストを全般的に提示するためのものである。現在挙げられている発明者の研究は、その研究がこの背景部分に記載されている範囲において、また、出願時に他の点では先行技術として適格でないかもしれない説明の側面において、本開示に対する先行技術として明示的にも黙示的にも認められていない。

イマーシブメディアとは、概して、時間指定された２次元（２Ｄ）ビデオ及び対応するオーディオのために既存の商用ネットワーク上に配信されるものを超えて、メディアの経験の中に物理的に存在するユーザーの知覚を作成又は強化するために、任意又はすべての人間の感覚システム（視覚、聴覚、体性感覚、嗅覚、及びおそらく味覚）を刺激するメディアを指し、これは「レガシーメディア」として知られている。イマーシブメディアとレガシーメディアはどちらも、時間指定又は非時間指定のいずれかとして特徴付けられる。

タイムドメディア又は時間指定メディア（Ｔｉｍｅｄ ｍｅｄｉａ）とは、時間に応じて構造化され提示されるメディアを指す。例えば、ムービーフィーチャ、ニュースレポート、エピソードコンテンツなどがあり、いずれも時間に応じて編成されています。レガシービデオ及びオーディオは、概してタイムドメディアと見なされる。

アンタイムドメディア又は非時間指定メディア（Ｕｎｔｉｍｅｄ ｍｅｄｉａ）とは、時間によって構造化されていないが、論理的、空間的、及び／又は時間的な関係によって構造化されているメディアのことである。例えば、ユーザーがゲームデバイスによって作成された経験の制御を有するビデオゲームを含む。アンタイムドメディアの別の例は、カメラによって撮影された静止画像写真である。アンタイムドメディアは、例えば、ビデオゲームのシーンの連続的にループされたオーディオ又はビデオセグメントに、タイムドメディアを組み込み得る。逆に、タイムドメディアは、例えば、固定静止画像を背景にしたビデオなどのアンタイムドメディアを組み込み得る。

イマーシブメディア対応デバイスは、イマーシブメディアにアクセスし、解釈し、提示する機能を備えたデバイスを指し得る。かかるメディア及びデバイスは、メディアの量と形式、及び、かかるメディアを大規模に配布するために必要な、つまり、ネットワーク上でレガシービデオ及びオーディオメディアと同等の配布を実現するために、必要なネットワークリソースの数及び種類に関して、異質なものである。対照的に、ラップトップのディスプレイ、テレビ及びモバイルハンドセットディスプレイなどのレガシーデバイスは、これらのデバイスのすべてが長方形のディスプレイ画面で構成されており、主要なメディア形式として２Ｄの長方形のビデオ又は静止画像を消費するため、その機能に関して均質なものである。

本開示の態様は、メディア処理のための方法及び装置を提供する。いくつかの実施例において、装置は処理回路を含む。処理回路は、第１トランスポートプロトコルを使用する制御プレーンチャネルの上で、サーバデバイスと、複数の制御メッセージを交換できる。複数の制御メッセージは、イマーシブメディア配信のための双方向プロトコルの制御プレーンに属する。処理回路は、サーバデバイスから、第２トランスポートプロトコルを使用する第１データプレーンチャネルの上で、第１の複数のデータメッセージを受信する。第１の複数のデータメッセージは、双方向プロトコルのデータプレーンに属し、イマーシブメディアコンテンツを搬送する。処理回路は、第１の複数のデータメッセージによって搬送されるイマーシブメディアコンテンツを提示する。

いくつかの実施例において、第１トランスポートプロトコルは、トランスミッション制御プロトコル（ＴＣＰ）であり、第２トランスポートプロトコルは、ユーザーデータグラムプロトコル（ＵＤＰ）である。

いくつかの実施例において、第１トランスポートプロトコルは、コネクションベースのトランスポートプロトコルであり、第２トランスポートプロトコルは、コネクションレスのトランスポートプロトコルである。

いくつかの実施形態では、処理回路は、制御プレーンチャネルの上で交換される複数の制御メッセージにしたがって、サーバデバイスを有する前記第１データプレーンチャネルを設定する。

いくつかの実施例において、処理回路は、装置の１つ以上の特定の特性を、制御プレーンチャネルの上でサーバデバイスに提供する。１つ以上の特定の特性は：装置の計算リソース； 装置のストレージリソース； 装置でのネットワークサービスプロバイダのサービスレベルの契約； イマーシブアプリケーション要件； 装置の種類；装置のモデル；装置のニューラルネットワークモデル；のうちの少なくとも１つを含む。

いくつかの実施例において、処理回路は、第２トランスポートプロトコルを使用する第２データプレーンチャネルの上で、第２の複数のデータメッセージをサーバデバイスに送信する。第２の複数のデータメッセージは、装置におけるニューラルネットワークモデルのレイヤ情報及び装置によってレンダリングされたメディアコンテンツのうちの少なくとも１つを搬送する。

いくつかの実施形態では、装置は、第１クライアントデバイスであり、複数の制御メッセージは、サーバデバイスが第２のクライアントデバイスとイマーシブメディアコンテンツを共有できるようにする。実施例において、処理回路は、サーバデバイスからの要求に応じて、制御プレーンチャネルを介して、不変のストレージにキャッシュされたアセットのユニフォームリソース識別子（ＵＲＩ）と、共有可能なアセットの種類とのリストを提供する。他の実施例において、処理回路は、サーバデバイスからの要求に応じて、制御プレーンチャネルを介して、第１クライアントデバイスによってアクセス可能である各アセットのステータスアップデートを提供する。他の実施例において、処理回路は、サーバデバイスからの要求に応じて、制御プレーンチャネルを介して、特定のアセットタイプの現在ステータスと、特定のサーバ割り当て識別子及び特定のアセットユニフォームリソース識別子（ＵＲＩ）のうちの１つと、を提供する。

本開示の態様はまた、コンピュータによって実行されると、メディア処理のための方法をコンピュータに実行させる命令を格納する非一時的コンピュータ可読媒体を提供する。

開示された主題のさらなる特徴、性質、及び様々な利点は、以下の詳細な説明及び添付の図面からより明らかになるであろう。
図１は、一実施例におけるタイムドメディア配信のエンドツーエンドプロセスを示す図である。 図２は、一実施例におけるタイムドメディアのストリーミングに使用される標準的なメディアフォーマットを示す図である。 図３は、いくつかの実施例における時間指定イマーシブメディアの表現及びストリーミングのためのデータモデルを示す図である。 図４は、いくつかの実施例における非時間指定イマーシブの表現及びストリーミングのためのデータモデルの線図である。 図５は、自然なシーンをキャプチャし、いくつかの実施例における異種クライアントのエンドポイントを提供するネットワークの取り込みフォーマットとして使用できる表現に変換するプロセスを示す図である。 図６は、いくつかの実施例における異種クライアントのエンドポイントを提供するネットワークの取り込みフォーマットとして使用できる合成シーンの表現を作成するために、３次元（３Ｄ）モデリングツール及びフォーマットを使用するプロセスを示す図である。 図７は、いくつかの実施例において、複数の異種クライアントエンドポイントを提供するネットワークを示す図である。 図８は、いくつかの実施例において、特定のイマーシブメディアクライアントエンドポイントによる消費のためにメディアを適応するネットワークのプロセスの前に、メディア取り込みフォーマットで表される特定のメディアに関する適応情報を提供するネットワークを示す図である。 図９は、いくつかの実施例において、ソースメディアを取り込みフォーマットから特定のクライアントエンドポイントに適した特定のフォーマットに変換するメディアレンダリング変換を含むメディア適応プロセスのシステム図を示す図である。 図１０は、いくつかの実施例において、適応されたソースメディアを表現及びストリーミングに適したデータモデルにフォーマットするネットワークを示す図である。 図１１は、いくつかの実施例において、図１１のデータモデルをネットワークプロトコルパケットのペイロードに分解するメディアストリーミングプロセスのシステムを示す図である。 図１２は、いくつかの実施例において、特定のイマーシブメディアクライアントのエンドポイントに対して、取り込みフォーマットの特定のイマーシブメディアを、ストリーミング可能で適切な配信フォーマットに適応させるネットワークのシーケンスを示す図である。 図１３は、いくつかの実施例における取り込みメディアフォーマットの図である。 図１４は、いくつかの実施例において、コード化されたビデオストリームとともにニューラルネットワークモデル情報の搬送を示す図である。 図１５は、いくつかの実施例において、入力イマーシブメディア及びアセットとともにニューラルネットワークモデル情報の搬送を示す図である。 図１６Ａは、いくつかの実施例において、イマーシブメディア配信のための双方向プロトコルを使用して、サーバ側からクライアント側に送信されるメッセージの図を示す。 図１６Ｂは、いくつかの実施例において、イマーシブメディア配信のための双方向プロトコルを使用して、サーバ側からクライアント側に送信されるメッセージの図を示す。 図１６Ｃは、いくつかの実施例において、イマーシブメディア配信のための双方向プロトコルを使用して、クライアント側からサーバ側に送信されるメッセージの図を示します。 図１７Ａは、いくつかの実施例において、サーバ側からクライアント側に送信されるメッセージの定義を示す図である。 図１７Ｂは、いくつかの実施例において、サーバ側からクライアント側に送信されるメッセージの定義を示す図である。 図１７Ｃは、いくつかの実施例において、サーバ側からクライアント側に送信されるメッセージの定義を示す図である。 図１７Ｄは、いくつかの実施例において、サーバ側からクライアント側に送信されるメッセージの定義を示す図である。 図１７Ｅは、いくつかの実施例において、サーバ側からクライアント側に送信されるメッセージの定義を示す図である。 図１７Ｆは、いくつかの実施例において、サーバ側からクライアント側に送信されるメッセージの定義を示す図である。 図１７Ｇは、いくつかの実施例において、サーバ側からクライアント側に送信されるメッセージの定義を示す図である。 図１８は、いくつかの実施例において、クライアント側からサーバ側に送信されるメッセージの定義を示す図である。 図１９Ａは、別個の制御プレーンチャネル及びデータプレーンチャネル上で双方向プレゼンテーションデータストリームを示す図である。 図１９Ｂは、別個の制御プレーンチャネル及びデータプレーンチャネル上で双方向プレゼンテーションデータストリームを示す図である。 図１９Ｃは、別個の制御プレーンチャネル及びデータプレーンチャネル上で双方向プレゼンテーションデータストリームを示す図である。 図１９Ｄは、別個の制御プレーンチャネル及びデータプレーンチャネル上で双方向プレゼンテーションデータストリームを示す図である。 図１９Ｅは、別個の制御プレーンチャネル及びデータプレーンチャネル上で双方向プレゼンテーションデータストリームを示す図である。 図２０は、いくつかの実施例において、イマーシブメディアの配信のために、別個の制御プレーンチャネル及びデータプレーンチャネル上で双方向プロトコルを使用するメディアシステムを示す図である。 図２１は、本開示のいくつかの実施形態によるプロセスの概概説するフローチャートを示す図である。 図２２は、本開示のいくつかの実施形態による、他のプロセスを概説するフローチャートを示す図である。 図２３は、一実施形態によるコンピュータシステムを概略的に示す図である。

本開示の態様は、別個のデータプレーンチャネルと制御プレーンチャネルの上で双方向プレゼンテーションデータストリームのための技術を提供する。本開示は、一般に、ビデオ、オーディオ、幾何学的（３Ｄ）オブジェクト、触覚、関連するメタデータ、又はクライアントプレゼンテーションデバイスのためのその他のコンテンツを含むメディアを配布するシステム及びネットワークのためのアーキテクチャ、構造及びコンポーネントに関連する実施形態について説明する。いくつかの実施形態は、異種のイマーシブ及びインタラクティブなクライアントプレゼンテーションデバイスにメディアコンテンツを配布するためのシステム、構造、及びアーキテクチャに向けられている。

イマーシブメディアとは、一般に、メディアの経験野中に物理的に存在するユーザーの知覚を作成又は強化するために、任意又はすべての人間の感覚システム（視覚、聴覚、体性感覚、嗅覚、そしておそらく味覚）を刺激するメディアを指し、つまり、「レガシーメディア」として知られる、時間指定された２次元（２Ｄ）ビデオ及び対応するオーディオのために既存の商用ネットワーク上で配布されるものを超えている。イマーシブメディアとレガシーメディアはどちらも、時間指定されたメディア又は時間指定されていないメディアとして特徴付けられる。

タイムドメディアは、時間にしたがって構造化され提示されるメディアを指す。例えば、動画フィーチャ、ニュースレポート、エピソードコンテンツなどが含まれ、いずれも時間にしたがって編成されている。レガシービデオ及びオーディオは、概してタイムドメディアと見なされる。

アンタイムドメディア又は非時間指定メディアとは、時間によって構造化されていないメディアのことであるが、論理的、空間的及び／又は時間的な関係によって構造化されている。例えば、ユーザーがゲームデバイスによって作成された経験を制御できるビデオゲームが含まれる。アンタイムドメディアの別の例として、カメラによって撮影された静止画像写真があります。アンタイムドメディアは、例えば、ビデオゲームのためのシーンの連続的にループされたオーディオ又はビデオセグメントにタイムドメディアを組み込み得る。逆に、タイムドメディアは、例えば、固定静止画像を背景にしたビデオなどのアンタイムドメディアを組み込み得る。

イマーシブメディア対応デバイスは、イマーシブメディアにアクセスし、解釈し、提示する機能を備えたデバイスを指し得る。かかるメディア及びデバイスは、メディアの量と形式、及び、かかるメディアを大規模に配布するために必要な、つまり、ネットワーク上でレガシービデオ及びオーディオメディアと同等の配布を実現するために、必要なネットワークリソースの数及び種類に関して、異質なものである。対照的に、ラップトップのディスプレイ、テレビ、移動式ハンドセットのディスプレイ等のレガシーバイスは、これらのデバイスのすべてが長方形のディスプレイ画面で構成されており、主要なメディア形式として２ Ｄの長方形のビデオ又は静止画像を消費するため、その機能は均質なものである。同様に、レガシーデバイスにおいてサポートされるオーディオフォーマット数は、比較的少数のセットに限られている。

ネットワーク上の任意のメディアの配信では、メディア配信システムとアーキテクチャを採用することができ、メディアを入力又はネットワーク取り込み形式から最終的な配信形式に再フォーマットし、その配信形式は、対象のクライアントデバイスとそのアプリケーションに適しているだけでなく、ネットワーク上でストリーミングされるのにも適している。メディアのストリーミングとは、広くは、メディアの時間的又は空間的構造のいずれか又は両方に従って論理的に編成及びシーケンスされた、連続した小さいサイズの「チャンク」で、メディアをネットワーク上で配信できるように、ソースメディアを細分化（ｆｒａｇｍｅｎｔｉｎｇ）及びパケット化することを指す。このような配信アーキテクチャ及びシステムでは、最も顕著なメディア情報のみが最初にクライアントに配信されるように、メディアが圧縮又は階レイヤ化プロセスを受ける場合がある。場合によっては、クライアントがエンドユーザーに同じメディア部分のいずれかを提示できる前に、クライアントがメディアの一部のための顕著なメディア情報を全て受信することがある。

ターゲットクライアントエンドポイントの能力に適合する（ｔｏ ｍａｔｃｈ ｔｈｅ ｃａｐａｂｉｌｉｔｉｅ）ように入力メディアを再フォーマットするプロセスでは、再フォーマット注の特定のメディアの事前知識をカプセル化し得るネットワークモデルを使用するニューラルネットワークプロセスを採用することがある。例えば、特定のモデルは、屋外の公園のシーン（公園のシーンに共通する木、植物、草、その他のオブジェクトを有する）を認識するように、チューニングされることがあるが、別の特定のモデルは、屋内のディナーシーン（ディナーテーブル、給仕用具、テーブルに座っている人などを有する）を認識するようにチューニングされることもある。いくつかの実施例では、ネットワークモデルを特定のコンテキストからのオブジェクト、例えば、公園シーンのオブジェクトを認識するようにチューニングでき、特定のシーンのコンテンツに一致するようにチューニングされたネットワークモデルを備えるニューラルネットワークプロセスは、そのようにチューニングされていないネットワークモデルよりも優れた視覚的結果を生成できる。したがって、ターゲットクライアントエンドポイントの能力に適合するように入力メディアを再フォーマットすることをタスクとするニューラルネットワークプロセスに、シーン固有のネットワークモデル（ｓｃｅｎｅ－ｓｐｅｃｉｆｉｃ ｎｅｔｗｏｒｋ ｍｏｄｅｌｓ）を提供する利点がある。

２次元（２Ｄ）メディアの特定のシーンにニューラルネットワークモデルを関連付けるメカニズムは、例えば、ネットワークモデルを圧縮し、圧縮したネットワークモデルを、例えば、Ｈ．２６４、Ｈ．２６５、及びＨ．２６６ビデオ圧縮フォーマットでコード化されたビデオストリームにメタデータを添付するために一般的に使用される補足強化情報（ＳＥＩ）構造化フィールドを使用して、視覚シーンの２Ｄコード化ビットストリームに直接挿入することによって実現できる。コード化されたビデオビットストリームの一部のコンテキスト内の特定のニューラルネットワークモデルを含むＳＥＩメッセージが存在することは、ネットワークモデルが、モデルが埋め込まれているビットストリームの部分内のビデオコンテンツを解釈し、適応させるために使用されるべきことを示すために使用され得る。いくつかの実施例では、ＳＥＩメッセージは、実際のモデル自体が存在しない場合に、ネットワークモデルのための識別子によって、どのニューラルネットワークモデルが使用されるかをシグナリングするために使用され得る。

イマーシブメディアに適切なニューラルネットワークを関連付けるメカニズムは、使用すべき適切なニューラルネットワークモデルを参照するイマーシブメディア自体によって達成されることがある。この参照は、ネットワークモデルとそのパラメータを、オブジェクトベース又はシーン毎ベースによって、或いはそれらの何らかの組み合わせによって、オブジェクトに直接埋め込むことによって達成されることがあるる。いくつかの実施例では、メディア内に１つ以上のニューラルネットワークモデルを埋め込むのではなく、メディアオブジェクト又はシーンが識別子によって特定のニューラルネットワークモデルを参照することがある

他のいくつかの例では、クライアントエンドポイントへのストリーミングのためのメディアを適応するために適切なニューラルネットワークを参照するメカニズムは、特定のクライアントエンドポイント自体が、使用すべき適応プロセスに少なくとも１つのニューラルネットワークモデルと対応するパラメータを提供することである。かかるメカニズムは、例えば、クライアントが自身をネットワークに接続するときに、クライアントが適応プロセスと通信して（１つ以上の）ニューラルネットワークモデルを提供することによって実装することができる。

ターゲットクライアントエンドポイントへのビデオの適応に続いて、ネットワーク内の適応プロセスは、結果に圧縮アルゴリズムを適用することを選択することがある。さらに、圧縮アルゴリズムは、いくつかの例では、適応されたビデオ信号を、視覚信号の最も顕著な部分から最も顕著でない部分に対応する（ｃｏｒｒｅｓｐｏｎｄ ｔｏ ｔｈｅ ｍｏｓｔ ｓａｌｉｅｎｔ ｔｏ ｔｈｅ ｌｅａｓｔ ｓａｌｉｅｎｔ ｐｏｒｔｉｏｎｓ）レイヤに分離する場合がある。

いくつかの実施例では、ＪＰＥＧ標準のプログレッシブフォーマット（ＩＳＯ／ＩＥＣ １０９１８ Ｐａｒｔ １）などの圧縮及びレイヤ 化プロセスは、画像を、全体画像を基本的な会場及び色のみで表示させ、はじめは焦点の外にあるレイヤに、即ち、全体画像スキャンのための、より下位のＤＣＴ係数から、分離し、その後、画像が焦点内に来るようにする、追加の詳細のレイヤに、即ち、全体画像スキャンのための、より下位のＤＣＴ係数から、分離することができる。

メディアを小さな部分に分割し、連続するネットワークプロトコルパケットのペイロード部分に編成し、これらのプロトコルパケットを配布するプロセスは、メディアのストリーミングと称されるが、さまざまな異種アプリケーションの１つを動作させているさまざまな異種クライアントエンドポイントの１つでのプレゼンテーションに適したフォーマットにメディアを変換するプロセスは、メディアのアダプティングと称される。

本開示で使用されるいくつかの用語の定義は、以下の段落で提供される。

シーングラフ：ベクターベースのグラフィックス編集アプリケーションや最新のコンピュータゲームによって一般に使用される汎用データ構造であり、グラフィカルなシーン；グラフ構造内のノード及び頂点の集合、の論理的、かつ多くの場合（必須ではない）空間的表現をアレンジする。

ノード：視覚、音声、触覚、嗅覚、味覚、又は関連する処理情報の論理的又は空間的又は時間的表現に関連する情報で構成されるシーングラフの基本要素；各ノードは、最大で１つの出力エッジ、０以上の入力エッジ、及びそれに接続された少なくとも１つのエッジ（入力又は出力のいずれか）を有するものとする。

ベースレイヤ：通常、アセットのレンダリングに必要な計算リソース又は時間、又はネットワーク上でアセットを伝送する時間を最小化するように定式化された、名目上のアセットの表現（ａ ｎｏｍｉｎａｌ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ｏｆ ａｎ ａｓｓｅｔ）。

拡張レイヤ：アセットのベースレイヤ表現に適用すると、ベースレイヤでサポートされていない特徴又は能力を含むようにベースレイヤを強化する情報のセット。

属性：ノードに関連付けられたメタデータであって、そのノードの特定の特性又は特徴を標準的又はより複雑なフォーマット（例えば、他のノードに関して）で記述するために使用される。

コンテナ：シーングラフ及びシーンのレンダリングに必要なすべてのメディアリソースを含む、すべての自然、すべての合成、又は合成と自然の混合シーンを表すための情報を格納及び交換するためのシリアル化されたフォーマット。

シリアル化：データ構造又はオブジェクトの状態を、例えば、ファイル又はメモリバッファ内に）格納又は（例えば、ネットワーク接続リンクを介して）伝送し、後に（おそらく別のコンピュータ環境で）再構築できるフォーマットに変換するプロセス。結果の一連のビットがシリアル化フォーマットに従って再読み込みされるときに、元のオブジェクトの意味的に同一のクローンを作成するために使用できる。

レンダラー（Ｒｅｎｄｅｒｅｒ）：音響物理学、光物理学、視覚認識、音声認識、数学、及びソフトウェア開発に関連する分野の選択的な混合に基づく（通常はソフトウェアベースの）アプリケーション又はプロセスであって、入力シーングラフとアセットコンテナが与えられると、ターゲットデバイスでのプレゼンテーションに適した、又はシーングラフ内のレンダーターゲットノードの属性によって指定された所望のプロパティに準拠した、通常は視覚及び／又は音声信号を発する。視覚ベースのメディアアセットの場合、レンダラーは、ターゲットディスプレイに適した、又は中間アセット（例えば、別のコンテナに再パッケージされる、すなわちグラフィックスパイプラインの一連のレンダリングプロセスで使用される）としてのストレージに適した視覚信号を発することができ；オーディオベースのメディアアセットの場合、レンダラーは、マルチチャネルラウドスピーカー及び／又はバイノーラル化ヘッドフォンでのプレゼンテーション用、又は別の（出力）コンテナへの再パッケージ用にオーディオ信号を発し得る。普及しているレンダラーの例は、Ｕｎｉｔｙ、Ｕｎｒｅａｌなどを含む。

評価：出力を抽象的な結果から具体的な結果に移行させる結果（例えば、Ｗｅｂページのためのドキュメントオブジェクトモデルの評価に類似）を生成する。

スクリプト言語：実行時にレンダラーによって実行され、シーングラフノードに対して行われた動的入力と変数状態の変更を処理できるインタープリター型プログラミング言語であって、これは、空間的及び時間的なオブジェクトトポロジ（物理的な力、制約、ＩＫ、変形、衝突を含む）のレンダリングと評価、及びエネルギ伝播と伝送（光、音）に影響する。

シェイダー（Ｓｈａｄｅｒ）：もともとはシェーディング（画像内の適切なレベルの光、暗さ、色の生成）に使用されていたが、現在ではコンピュータグラフィックス特別効果のさまざまな分野でさまざまな特殊機能を実行するか、又はシェーディングとは関係のないビデオの後処理を行うか、又は、グラフィックとはまったく関係のない機能さえも実行するコンピュータプログラムの一種。

パストレーシング：シーンの照明が現実に忠実であるように３次元のシーンをレンダリングするコンピュータグラフィックス方法。

タイムドメディア：時間によって順序付けられたメディア；例えば、特定のクロックに従った開始時刻と終了時刻を有する。

アンタイムドメディア：空間的、論理的又は時間的な関係によって編成されたメディア；例えば、（１以上の）ユーザーが取る行動に従って実現されるインタラクティブな体験として。

ニューラルネットワークモデル：元の信号によって明示的に提供されなかった視覚信号のための新しいビューの補間を含み得る改善された視覚出力に到達するために、視覚信号に適用される十分に定義された数学的演算で使用される重み付け（即ち数値）を定義するパラメータ及びテンソル（例えば行列）の集合。

開示のいくつかの態様によれば、イマーシブメディアは、イマーシブメディア対応デバイスによって人間に提示されたときに、より現実的で、自然界内の経験の人間の理解と整合する方法で、視覚、聴覚、味覚、触覚、聴覚の五感のいずれかを刺激する１つ以上のタイプのメディアと見なすことができ、即ち；レガシーデバイスによって提示されたレガシーメディアで達成された以上の刺激。このコンテキストでは、レガシーメディアという用語は、２次元（２Ｄ）ビジュアルメディア、静止画又は動画のいずれかの画像フレーム、及び／又はユーザーの相互作用機能が一時停止、再生、早送り、又は巻き戻しに制限されている対応するオーディオを指す。レガシーデバイスとは、その能力がレガシーメディアのみの表示に制限されている、テレビ、ラップトップ、ディスプレイ、及びモバイルデバイスを指し得る。

一部の消費者向けアプリケーションシナリオでは、イマーシブメディア（即ち、イマーシブメディア対応デバイス）用のプレゼンテーションデバイスは、特に、イマーシブメディアによって具体化された特定の情報を活用する能力を備えた消費者向けハードウェアデバイスであり、したがって、デバイスは、物理的な世界に対する人間の理解及び相互作用により近いプレゼンテーションを作成することができ、つまり、それを行うためのレガシーデバイスの能力を超える。レガシーデバイスは、レガシーメディアのみを表示するように性能に制約があるのに対して、イマーシブメディアデバイスは同様に制約されない。

この１０年間で、ヘッドマウントディスプレイ、拡張現実メガネ、ハンドヘルドコントローラ、触覚グローブ、ゲームコンソールなど、多数のイマーシブメディア対応デバイスが消費者市場に導入されている。同様に、ホログラフィックディスプレイやその他のフォーマットのボリュームディスプレイも、今後１０年以内に登場する準備ができている。これらのデバイスが即時に又は切迫して利用可能になるにもかかわらず、商用ネットワーク上のイマーシブメディアの配信のための一貫したエンドツーエンドのエコシステムは、いくつかの理由で実現できていない。

これらの理由の １ つは、商用ネットワーク上での大規模なメディアの現在の配信に関連する２つの主要なユースケースに対応できるイマーシブメディアの単一の標準表現がないことである。
１） ライブアクションイベントのためのリアルタイム配信、すなわち、コンテンツが作成され、クライアントのエンドポイントにリアルタイム又は略リアルタイムで配信される場合と、
２） リアルタイムでコンテンツを配信する必要がない、非リアルタイム配信、すなわち、コンテンツが物理的にキャプチャ又は作成されている場合。
これらの２つのユースケースは、それぞれ、現在存在する配信のブロードキャストフォーマット及びオンデマンドフォーマットと比較できる可能性がある。

リアルタイム配信では、コンテンツを１つ以上のカメラでキャプチャすること、又は、コンピュータ生成技術を使用して作成することができる。いくつかの実施例では、（１つ以上の）カメラによってキャプチャされたコンテンツはここでは自然コンテンツと称され、コンピュータ生成技術を使用して作成されたコンテンツはここでは合成コンテンツ（ｓｙｎｔｈｅｔｉｃ ｃｏｎｔｅｎｔ）と称される。合成コンテンツを表すメディアフォーマットは、３ Ｄモデリング、視覚効果、ＣＡＤ／ＣＡＭ業界で使用されるフォーマットであり得、メッシュ、テクスチャ、ポイントクラウド、構造化ボリューム、アモルファスボリューム（例えば、火、煙、霧の場合）、シェーダー、手続き的に生成されたジオメトリ、マテリアル、ライティング、仮想カメラ定義、アニメーションなどのオブジェクトフォーマット及びツールを含むことができる。合成コンテンツはコンピュータによって生成されるが、合成メディアフォーマットは自然コンテンツ及び合成コンテンツの両方に使用できる。しかしながら、自然コンテンツを合成メディアフォーマット（例えば、合成表現に）に変換するプロセスは時間と計算量のかかるプロセスであり得るため、リアルタイムのアプリケーションやユースケースでは実用的ではない場合があり得る。

自然コンテンツのリアルタイム配信では、カメラでキャプチャされたコンテンツをラスターフォーマットで配信でき、これは、レガシーディスプレイデバイスに適している。このようなデバイスの多くは同様にラスターフォーマットを表示するように設計されているからである。つまり、レガシーディスプレイがラスターフォーマットを表示するように均質に設計されていることを考えると、ラスターフォーマットの配信はラスターフォーマットのみを表示できるディスプレイに最適です。

ただし、イマーシブメディア対応ディスプレイは、ラスターベースのフォーマットの表示に制約される必要はない。さらに、一部のイマーシブメディア対応ディスプレイでは、ラスターベースのフォーマットでのみ利用可能なメディアを表示できない。ラスターベースのフォーマット以外のフォーマットに基づいてイマーシブ体験を作成するように最適化されたディスプレイが利用可能であることも、イマーシブメディアの配信に一貫したエンドツーエンドのエコシステムがまだ存在しない重要な理由の１つです。

複数の異なるイマーシブメディアデバイスのための一貫した配信システムを作成することに関するさらに別の問題は、現在のイマーシブメディア対応デバイスと新進のイマーシブメディア対応デバイス自体が大きく異なり得ることである。例えば、一部のイマーシブメディアデバイスは、一度に１人のユーザーのみが使用するように明示的に設計されている。例えばヘッドマウントディスプレイなど。他のいくつかのイマーシブメディアデバイスは、複数のユーザーが同時に使用できるように設計されている。例えば、「Ｌｏｏｋｉｎｇ Ｇｌａｓｓ Ｆａｃｔｏｒｙ ８Ｋ ディスプレイ」（以降、「レンチキュラーライトフィールドディスプレイ」と称する）は、最大１２人のユーザーが同時に見ることができるコンテンツを表示でき、各ユーザーが、表示されているコンテンツの独自の視点（ビュー）を体験している。

一貫した配信システムの開発をさらに複雑にしているのは、各ディスプレイが生成できる固有のビューの数が大きく異なり得ることである。ほとんどの場合、レガシーディスプレイで作成できるコンテンツのビューは１つだけである。一方、レンチキュラーライトフィールドディスプレイでは、各ユーザーが同じ視覚シーンのユニークビュー（ｕｎｉｑｕｅ ｖｉｅｗｓ）を体験することで、複数のユーザーをサポートできる。このような同一シーンの複数のビューの作成を実現するために、レンチキュラーライトフィールドディスプレイでは、ディスプレイへの入力として同一シーンの４５のユニークビューが必要とされる特定の立体視フラスタム（ａ ｓｐｅｃｉｆｉｃ ｖｏｌｕｍｅｔｒｉｃ ｖｉｅｗｉｎｇ ｆｒｕｓｔｕｍ）が作成されます。これは、同一シーンのわずかに異なる４５のユニークスター表現をキャプチャし、この１つの特定のディスプレイ、つまり、ビューフラスタム、に固有のフォーマットでディスプレイに配信する必要があることを意味する。これとは対照的に、レガシーディスプレイのビューフラスタムは単一の二次元平面に制限されており、従って、そのディスプレイを経験している同時視聴者の数に関係なく、ディスプレイの視野台を介してコンテンツの複数の視野を表示する方法はない。

一般に、イマーシブメディアディスプレイは、全てのディスプレイの以下の特徴性によって顕著に異なり得る：ビューフラスタムの寸法と体積、同時にサポートされる視聴者の数、点ベース、光線ベース、波ベースの技術であり得る、ビューフラスタムを埋めるために使用される光学技術、ビューフラスタムを占有する光ユニット（点、光線、波のいずれか）の密度、コンピューティングパワーとコンピューティングの種類（ＣＰＵ又はＧＰＵ）の可用性、電源及びパワーの可用性（バッテリ又は配線）、ローカルストレージ又はキャッシュの量、クラウドベースのコンピューティング及びストレージなどの補助リソースへのアクセス。これらの特性は、イマーシブメディアディスプレイの異質性に寄与しており、レガシーディスプレイの均質性とは対照的に、レガシーディスプレイとイマーシブディスプレイの両方を含む全てのディスプレイをサポートできる単一の配信システムの開発を複雑にしている。

開示された主題は、単一のネットワークのコンテキスト内でクライアントエンドポイントとしてレガシーディスプレイ及びイマーシブメディアディスプレイの両方をサポートできるネットワークベースのメディア配信システムの開発を対象にする。具体的には、入力イマーシブメディアソースを、そのクライアントエンドポイントデバイス上で現在実行されているアプリケーションを含む、クライアントエンドポイントデバイスの特定の特性に適したフォーマットに適応させるメカニズムがここに提示される。かかる、入力イマーシブメディアソースを適応させるメカニズムは、入力イマーシブメディアの特性を、クライアントデバイス上で実行されているアプリケーションを含むターゲットエンドポイントクライアントデバイスの特性と調和させること（ｒｅｃｏｎｃｉｌｉｎｇ）と、その後、入力イマーシブメディアをターゲットエンドポイントとそのアプリケーションに適したフォーマットに適応させることと、を含む。さらに、適応プロセスは、クライアントエンドポイントによって必要とされる追加のビューを作成するために、入力メディアから追加のビュー、例えば新規のビューを補間することを含み得る。かかる補間は、ニューラルネットワークプロセスの支援を受けて実行され得る。

開示された主題の残りの部分は、一般性を失うことなく、入力イマーシブメディアソースを特定のエンドポイントクライアントデバイスに適応させるプロセスが、特定のクライアントエンドポイントデバイス上で実行されている特定のアプリケーションに同一の入力イマーシブメディアソースを適応させるプロセスと同じか、又は類似していることを前提としていることに留意されたい。つまり、入力メディアソースをエンドポイントデバイスの特性に適応させる問題は、特定の入力メディアソースを特定のアプリケーションの特性に適応させる問題と同じ複雑さである。

レガシーメディアによってサポートされるレガシーデバイスは、消費者に広く普及している。レガシーメディアの標準ベースの表現を生成するレガシーメディアコンテンツプロバイダ、及び、レガシーデバイスを標準レガシーコンテンツのソースに接続するためのネットワークインフラストラクチャを提供する商用ネットワークサービスプロバイダのエコシステムによって同様にサポートされる。ネットワーク上でレガシーメディアを配信する役割を超えて、商用ネットワークサービスプロバイダは、コンテンツ配信ネットワーク（ＣＤＮ：ｃｏｎｔｅｎｔ ｄｉｓｔｒｉｂｕｔｉｏｎ ｎｅｔｗｏｒｋｓ）上のレガシーコンテンツにアクセスするためのレガシークライアントデバイスのペアリングを容易にすることもできる。一旦適切な形式のコンテンツへのアクセスとペアリングされると、レガシークライアントデバイスは、コンテンツサーバーからデバイスにレガシーコンテンツを要求し又はプルして、エンドユーザーに表示することができる。それにもかかわらず、ネットワークサーバーが適切なメディアを適切なクライアントにプッシュするアーキテクチャは、全体的なアーキテクチャとソリューション設計に追加の複雑さを生じさせることなく、同様に関連性がある。

開示のいくつかの態様によると、異種クライアントをサポートするメディア配信ネットワークは、入力メディアフォーマットから特定のターゲットフォーマットに適応されたアセットの一部が、類似のディスプレイターゲット（クライアントデバイス）のセットにわたって再利用され得るという事実を活用できる。たとえば、一旦ターゲットディスプレイに適したフォーマットに変換された一部のアセットは、類似の適応要件を有する多数のかかるディスプレイにわたって（ａｃｒｏｓｓ ａ ｎｕｍｂｅｒ ｏｆ ｓｕｃｈ ｄｉｓｐｌａｙｓ）再利用され得る。いくつかの実施例では、メディア配信ネットワークはキャッシュメカニズムを採用して、適応されたアセットを比較的不変の（ｒｅｌａｔｉｖｅｌｙ ｉｍｍｕｔａｂｌｅ）ストレージに格納できる。

開示の態様によると、イマーシブメディアは、シーングラフ、シーン記述とも称される、によって記述される「シーン」に編成され得る。シーングラフの範囲は、プレゼンテーションの一部である特定の設定を構成するビジュアル、オーディオ、及びその他のフォーマットのイマーシブアセットを記述することであり、例えば、プレゼンテーションの一部である建物内の特定の場所で行われるイベント （映画など）及び俳優を記述する。１つのプレゼンテーションを構成するすべてのシーンのリストは、シーンのマニフェストに定式化できる。

いくつかの実施例では、かかるコンテンツを配信する必要がある前に準備されたコンテンツについて、プレゼンテーション全体に使用されるであろう全てのアセットと、プレゼンテーション内のさまざまなシーンにわたって各アセットが使用される頻度を識別する 「素材表（ｂｉｌｌ ｏｆ ｍａｔｅｒｉａｌｓ）」を作成できる。メディア配信ネットワークは、特定のプレゼンテーションのためのアセット要件を満足するために使用できるキャッシュされたリソースの存在を認識するように実装されることができる。

開示のいくつかの態様は、メディア配信ネットワーク（たとえば、メディア配信ネットワークをクライアントデバイスとインタフェースする、メディア配信ネットワーク内のサーバデバイス）とクライアントデバイス間で使用できる双方向プロトコルを提供できる。いくつかの実施例では、双方向プロトコルは、イマーシブメディアを配信するメディア配信ネットワークで使用できる。双方向プロトコルは、さまざまなフォーマットのアセットタイプを必要とするさまざまな多様なクライアントデバイスをサポートできる。いくつかの実施例では、双方向プロトコルは、以前に特定のクライアントデバイスによる使用に適応されたアセットの再利用を可能する。

本開示では、一般性を失うことなく、入力イマーシブメディアソースを特定のエンドポイントクライアントデバイスに適合させるプロセスは、特定のエンドポイントクライアントデバイスで実行されている特定のアプリケーションに同じ入力イマーシブメディアソースを適合させるプロセスと同じか、又は類似していることに留意されたい。入力メディアソースをエンドポイントデバイスの特性に適合させる技術は、入力メディアソースを特定のアプリケーションの特性に適合させる技術とほぼ同じである可能性がある。

開示の態様によると、レガシーメディアによってサポートされているレガシーデバイスは、レガシーメディアの標準ベースの表現を生成するレガシーメディアコンテンツプロバイダと、レガシーデバイスを標準レガシーコンテンツのソースに接続するためのネットワークインフラを提供する商用ネットワークサービスプロバイダとのエコシステムによって同様にサポートされているため、広範な消費者の採用を達成している。ネットワーク上でレガシーメディアを配信する役割を超えて、商用ネットワークサービスプロバイダは、コンテンツ配信ネットワーク（ＣＤＮ：ｃｏｎｔｅｎｔ ｄｉｓｔｒｉｂｕｔｉｏｎ ｎｅｔｗｏｒｋｓ）上のレガシーコンテンツにアクセスするためのレガシークライアントデバイスのペアリングを容易にすることもできる。一旦適切な形式のコンテンツへのアクセスとペアリングされると、レガシークライアントデバイスは、コンテンツサーバーからデバイスにレガシーコンテンツを要求し又はプルして、エンドユーザーに表示することができる。それにもかかわらず、メディア配信ネットワークは、ネットワークサーバーが適切なクライアントに適切なメディアを「プッシュ」するアーキテクチャを利用し得る。

開示のいくつかの態様は、メディア配信ネットワークをクライアントデバイスとインタフェースするためのインターフェイスデバイス（サーバデバイスとも称される） を含むメディア配信ネットワークを提供する。サーバデバイスは、クライアントデバイスとの通信に双方向通信プロトコル（双方向プロトコルとも称される）を採用することができ、クライアントデバイスのユニーク性、又はクライアントデバイス上で実行されているアプリケーションから発生する要件に適合するようにメディアを適応させることを容易にすることができる。また、サーバデバイスは双方向プロトコルを使用して、全体的に新たに適応されたアセット、又は以前に適応されてキャッシュされたアセットを特定のクライアントデバイスにストリーミングすることもできる。いくつかの実施例では、サーバデバイスは双方向プロトコルを使用して、クライアントデバイスがサーバデバイスから特定の支援を要求する機能をサポートできる。例えば、クライアントデバイスがアセットを提示する準備として、アセットのレンダリングを支援する。

ここでは、さまざまな実施形態による法、装置（システム）、及びコンピュータが読み取り可能な媒体のフローチャート図及び／又はブロック図を参照して、態様を記載する。フローチャート図及び／又はブロック図の各ブロック、及びフローチャート図及び／又はブロック図のブロックの組み合わせは、コンピュータが読み取り可能なプログラム命令によって実装できることが理解されるであろう。

本開示は、一般に、ビデオ、オーディオ、幾何学的（３Ｄ）オブジェクト、触覚、関連するメタデータ、又はクライアントデバイスのためのその他のコンテンツを含むメディアを配布するシステム及びネットワークのためのアーキテクチャ、構造及びコンポーネントに関連する実施形態について説明する。特定の実施形態は、異種のイマーシブ及びインタラクティブなクライアントデバイスにメディアコンテンツを配信するための指向システム、構造、及びアーキテクチャである。

図１は、タイムドレガシーメディア配信のエンドツーエンドプロセス（１００）の図を示している。図１では、タイムド視聴覚コンテンツは、カメラ又はマイク（１０１Ａ）によってキャプチャされるか、コンピュータ（１０１Ｂ）によって生成され、準備モジュール（１０３）に入力される２Ｄ画像及び関連する音声のシーケンス（１０２）を作成する。準備モジュール（１０３）の出力は、（例えば、言語翻訳、字幕、その他の編集機能を含むポストプロダクションのための）編集されたコンテンツであり、コンバータモジュール（１０４）により、例えばライブイベントの場合は、標準コントリビューションフォーマット（ａ ｓｔａｎｄａｒｄ ｃｏｎｔｒｉｂｕｔｉｏｎ ｆｏｒｍａｔ）と称されるか、又は、例えばオンデマンドメディアの場合は、標準メザニンフォーマット（ａ ｓｔａｎｄａｒｄ Ｍｅｚｚａｎｉｎｅ ｆｏｒｍａｔ）に変換する準備ができているマスターフォーマットと称される。一実施例では、メディアは商用ネットワークサービスプロバイダによって取り込まれ、適応モジュール（１０５）は標準配信フォーマットにパッケージ化されたさまざまなビットレート、時間的解像度（フレームレート）、又は空間解像度（フレームサイズ）にメディアをパッケージ化する。結果として得られる適応はコンテンツ配信ネットワーク（ＣＤＮ）（１０６）上に格納され、そこからさまざまなクライアント （１０８ Ａ）－（１０８Ｃ）がプルリクエスト（１０７Ａ）－（１０７Ｃ）を行い、メディアをフェッチしてエンドユーザーに提示する。マスターフォーマットは（１０１Ａ）又は（１０１Ｂ）の両方のメディアのハイブリッドで構成され得、（１０１Ａ）のフォーマットはリアルタイムで取得され得る、例えばライブスポーツイベントから取得される、ことに留意することが重要である。さらに、クライアント（１０８Ａ）－（１０８Ｃ）は、クライアントの構成及び／又は現在のネットワーク条件に最適な特定の適応を選択する責任があるが、ネットワークサーバ（図１には示されていない）が適切なコンテンツを決定し、その後クライアント（１０８Ａ）－（１０８Ｃ）にプッシュすることも同様に可能である。

図２は、いくつかの実施例において、レガシータイムドメディア、例えばビデオ、オーディオ、及びサポートメタデータ（字幕に使用されるようなタイムドテキストを含む）の配信に使用される標準メディアフォーマット（２００）の図を示す。図１のＣＤＮ（１０６）で示されているように、メディアは、図２のＣＤＮ（２０１Ａ）－（２０１Ｃ）などのＣＤＮ上に標準ベースの配信フォーマットで格納される。標準ベースのフォーマットはＭＰＤ（２０２）として示されており、期間（２０３Ａ）及び期間（２０３Ｂ）などの期間を含む複数のセクションで構成され、開始時刻と終了時刻がクロックに対応する。実施例では、各期間（例えば（２０３Ａ）（２０３Ｂ））は、１つ以上の適応セット（２０４Ａ）－（２０４Ｆ）に関連する（ｒｅｆｅｒｓ ｔｏ）。（２０４Ａ）－（２０４Ｆ）の各適応セットは、一般に、ビデオ、オーディオ、又はタイムドテキストなど、単一の種類のメディアに使用される。いくつかの実施例では、任意の所与の期間（例えば（２０３Ａ））に対して、複数の適応セット（例えば （２０４Ａ）－（２０４Ｃ））が提供され得る。例えば、ビデオ用に１つ、さまざまな言語への翻訳に使用されるなどのオーディオ用に複数が提供される。（２０４Ａ）－（２０４Ｆ） の各適応セットは、メディアのフレーム解像度（ビデオ用）、フレームレート、及びビットレートに関する情報を提供する１つ以上の表現（２０５）に関連する。複数の表現（２０５）を使用して、たとえば、超高精細、高精細、又は標準精細のビデオのそれぞれの表現（２０５）へのアクセスを提供できる。各表現（２０５）は、（（１０８Ａ）－（１０８Ｃ）として図１に示されるような）クライアントによるフェッチ用、又はネットワークメディアサーバー（図１には示されていない）による配信用（プッシュベースのアーキテクチャ）にメディアが実際に格納されている１つ以上のセグメントファイル（２０６）に関連する。

図３は、実施例において、タイムドである又は時間が設定されている異種のイマーシブメディアのためのストリーミング可能なフォーマット（３００）の表現を示す。図４は、実施例において、アンタイムドである又は時間が設定されていない異種のイマーシブメディアのためのストリーミング可能なフォーマット（４００）の表現を示す。図３の場合、図３はタイムドメディアのシーン（３０１）を示している。図４の場合、図４はアンタイムドメディアのシーン（４０１）を示している。どちらの場合も、シーンはさまざまなシーン表現、又はシーン記述によって実装され得る。

例えば、いくつかのイマーシブメディア設計では、シーンはシーングラフ、又はマルチプレーンイメージ（ＭＰＩ）、又はマルチスフィアイメージ（ＭＳＩ）として実装され得る。ＭＰＩとＭＳＩの両方の技術は、自然なコンテンツ、つまり１つ以上のカメラから同時にキャプチャされた現実世界のイメージのためのディスプレイを選ばないシーン表現の作成を支援する技術の例である。
一方、シーングラフ技術は、合成表現の形で自然なイメージとコンピュータ生成されたイメージの両方を表すために使用され得るが、かかる表現は、コンテンツが１つ以上のカメラによって自然なシーンとしてキャプチャされる場合のために作成するのに特に計算集約的である。つまり、自然にキャプチャされたコンテンツのシーングラフ表現は、作成に時間と計算集約的であり、ターゲットイマーシブクライアントディスプレイのビューフラスタムを埋めるのに十分かつ適切な数のビューを補間するためにその後使用できる合成表現を作成するために、写真測量又はディープラーニング或いはその両方の技術を使用して自然なイメージの複雑な分析を必要とする。その結果、かかる合成表現は、リアルタイムの配信を必要とするユースケースを考慮するためにリアルタイムで実際に作成することはできないため、現在、自然なコンテンツを表す候補として検討することは実用的ではない。いくつかの実施例では、コンピュータ生成画像は３Ｄモデリングプロセス及びツールを使用して作成されるため、コンピュータ生成画像のための最適な候補表現は、合成モデルを有するシーングラフの使用を採用することである。

自然なコンテンツとコンピュータで生成されたコンテンツの両方の最適な表現におけるかかる二分法は、自然にキャプチャされたコンテンツのための最適な取り込みフォーマットが、コンピュータで生成されたコンテンツ又はリアルタイム配信アプリケーションのために不可欠ではない自然なコンテンツの最適な取り込みフォーマットとは異なることを示唆する。したがって、開示された主題は、自然に作成されたかコンピュータによって作成されたかにかかわらず、視覚的に没入できるメディアの複数の取り込みフォーマットをサポートするのに十分なロバスト性を目標としている。

以下は、コンピュータ生成技術を使用して作成された視覚的イマーシブメディア、又は、ディープラーニング若しくは写真測量技術を使用して自然シーンの対応する合成表現を作成する自然にキャプチャされたコンテンツを表すのに適したフォーマットとしてシーングラフを具体化する技術の例である。 つまり、リアルタイム配信アプリケーションには必須ではない。

１．ＯＴＯＹによるＯＲＢＸ（登録商標）

ＯＴＯＹによるＯＲＢＸは、レイトレーサブル、レガシー（フレームベース）、ボリューム、その他の種類の合成又はベクトルベースの視覚フォーマットを含む、タイムド又はアンタイムドの任意の種類の視覚メディアをサポートできるいくつかのシーングラフ技術の１つである。一態様によれば、ＯＲＢＸは、メッシュ、ポイントクラウド、及びテクスチャに対して自由に利用できるフォーマット及び／又はオープンソースフォーマットに対してネイティブなサポートを提供しているため、ＯＲＢＸは他のシーングラフからユニークである。ＯＲＢＸは、シーングラフ上で動作する複数のベンダー技術にわたって交換を容易にすることを目的として意図的に設計されたシーングラフである。さらに、ＯＲＢＸは豊富なマテリアルシステム、オープンシェーダー言語に対するサポート、ロバストなカメラシステム、Ｌｕａスクリプトに対するサポートを提供する。ＯＲＢＸは、イマーシブデジタル体験アライアンス（ＩＤＥＡ：ｔｈｅ ｉｍｍｅｒｓｉｖｅ ｄｉｇｉｔａｌ ｅｘｐｅｒｉｅｎｃｅｓ ａｌｌｉａｎｃｅ）によってロイヤリティフリーの条件でライセンス公開されているイマーシブ技術メディアフォーマットの基礎でもある。メディアのリアルタイム配信のコンテキストでは、自然なシーンのＯＲＢＸ表現を作成して配信できる能力は、カメラでキャプチャされたデータの複雑な分析を実行し、同じデータを合成表現内へ合成するための計算リソースの可用性の機能である。現在のところ、リアルタイム配信に十分なコンピューティングを利用することは現実的ではないが、不可能ではない。

２．Ｐｉｘａｒによるユニバーサルシーンデスクリプション

ピクサーによるユニバーサルシーンデスクリプション（ＵＳＤ）は、視覚効果（ＶＦＸ）及び専門的なコンテンツ制作コミュニティで使用できる別のシーングラフです。ＵＳＤは、ＮＶＩＤＩＡのＧＰＵを使用した３Ｄモデルの作成及びレンダリングのための開発者向けツールセットであるＮＶＩＤＩＡのＯｍｎｉｖｅｒｓｅプラットフォームに統合されている。ＵＳＤのサブセットは、Ａｐｐｌｅ及びＰｉｘａｒによってＵＳＤＺとして公開された。ＵＳＤＺはＡｐｐｌｅのＡＲＫｉｔによってサポートされている。

３．Ｋｈｒｏｎｏｓによる ｇｌＴＦ２．０

ｇｌＴＦ ２．０はＫｈｒｏｎｏｓ ３ Ｄ Ｇｒｏｕｐによって書かれたグラフィックス言語伝送フォーマット仕様の最新バージョンである。このフォーマットは、一般的にシーン内の静的な（アンタイムド）オブジェクト（「ｐｎｇ」や「ｊｐｅｇ」イメージフォーマットなど）をサポートできる単純なシーングラフフォーマットをサポートする。ｇｌＴＦ ２．０は、ｇｌＴＦプリミティブを使用して記述された基本的な形状、つまり幾何学的なオブジェクトの移動、回転、スケールに対するサポートを含む単純なアニメーションをサポートする。ｇｌＴＦ ２．０はタイムドメディアをサポートしていないため、ビデオやオーディオをサポートしていない。

イマーシブ視覚メディアの上記のシーン表現は、例としてのみ提供されており、入力イマーシブメディアソースをクライアントのエンドポイントデバイスの特定の特性に適したフォーマットに適応させるプロセスを指定する能力において、開示される主題を制限しないことに留意されたい。

さらに、上記の例のメディア表現のいずれか又は全ては、現在ディープラーニング技術を採用しているか、又は採用することができ、フラスタムの特定の寸法に基づいて特定のディスプレイのビューフラスタムを満たす特定のビューの選択を可能又は容易にするニューラルネットワークモデルをトレーニング及び作成する。特定のディスプレイのビューフラスタムに対して選択されたビューは、シーン表現で明示的に提供されている既存のビュー （例えば、ＭＳＩ又はＭＰＩ技術から）から補間され得、例えば、これらのレンダエンジンの特定の仮想カメラの位置、フィルター、又は仮想カメラの記述に基づいてレンダエンジンから直接レンダリングされ得る。

したがって、開示された主題は、自然にキャプチャされたメディア（例：１台以上のカメラで）又はコンピュータ生成技術を使用して作成されたメディアのリアルタイム又は 「オンデマンド」 （例：非リアルタイム）配信の両方の要件を満たすのに十分な、比較的小さいがよく知られている一連のイマーシブメディア取り込みフォーマットがあることを考慮するのに十分なロバスト性を備えている。

ニューラルネットワークモデル又はネットワークベースのレンダリングエンジンのいずれかを使用して、イマーシブメディア取り込みフォーマットからのビューの補間は、モバイルネットワーク用の５Ｇや固定ネットワーク用の光ファイバーケーブルなどの高度なネットワーク技術が展開されるにつれて、さらに容易になる。つまり、このような高度なネットワークインフラは、ますます大量の視覚情報の伝送と配信をサポートできるため、これらの高度なネットワーク技術は商用ネットワークの容量と能力を向上させる。マルチアクセスエッジコンピューティング（ＭＥＣ）、ソフトウェア定義ネットワーク（ＳＤＮ）、ネットワーク機能仮想化（ＮＦＶ）などのネットワークインフラストラクチャ管理技術により、商用ネットワークサービスプロバイダは、例えば、ネットワークスループット、ネットワークスピード、ラウンドトリップ遅延、及びコンピューティングリソースに対する需要の動的な増減に応答して、特定のネットワークリソースに対する需要の変化に適応するように、ネットワークインフラストラクチャを柔軟に構成できる。さらに、動的なネットワーク要件に適応するこの固有の能力は、異種のクライアントエンドポイントのための潜在的に異種の視覚メディアフォーマットを持つさまざまなイマーシブメディアアプリケーションをサポートするために、イマーシブメディア取り込みフォーマットを適切な配信フォーマットに適応させるネットワークの能力を促進する。

イマーシブメディアアプリケーション自体も、ゲームの状態でリアルタイムの更新に応答するために大幅に低いネットワークレイテンシを必要とするゲームアプリケーション、ネットワークのアップリンクとダウンリンクの両方の部分に対して対称的なスループット要件を持つテレプレゼンスアプリケーション、及び、データを消費しているクライアントエンドポイントディスプレイの種類に応じてダウンリンクリソースの需要が増加する可能性があるパッシブビューイングアプリケーション、を含むネットワークリソースに対するさまざまな要件を有し得る。一般に、消費者向けアプリケーションは、ストレージ、コンピューティング、及び電力に対するさまざまなオンボードクライアント機能を備えたさまざまなクライアントエンドポイントによってサポートされ得、同様に特定のメディア表現に対するさまざまな要件によってサポートされ得る。

したがって、開示された主題は、十分に装備されたネットワーク、つまり、最新のネットワークの特性の一部又は全てを採用したネットワークが、その中で指定された特徴に従って、複数のレガシー及びイマーシブメディア対応デバイスを同時にサポートすることを可能にする。

１．メディアの配信のためのリアルタイムとオンデマンドの両方のユースケースに実用的なメディア取り込みフォーマットを活用するフレキシビリティを提供する。

２．レガシー及びイマーシブメディア対応のクライアントエンドポイントの両方で、自然なコンテンツ及びコンピュータで生成されたコンテンツの両方をサポートするフレキシビリティを提供する。

３．タイムドメディア及びアンタイムドメディアの両方をサポートする。

４．クライアントのエンドポイントの特徴及び機能に基づいて、及びアプリケーションの要件に基づいて、ソースメディアの取り込みフォーマットを適切な配信フォーマットに動的に適応させるプロセスを提供する。

５．配信フォーマットがＩＰベースのネットワーク上でストリーミング可能であることを確認する。

６．ネットワークが、レガシーメディア及びイマーシブメディア対応デバイスの両方を含む可能性のある複数の異種クライアントエンドポイントに同時にサービスを提供できるようにする。

７．シーン境界に沿った配信メディアの編成を容易にする模範的なメディア表現フレームワークを提供する。

開示された主題によって可能になる改善のエンドツーエンドの実施例は、図３から図１５の詳細な説明に記載された処理とコンポーネントに従って達成される。

図３及び図４はそれぞれ、特定のクライアントエンドポイントの機能に適合するように、取り込みソースフォーマットから適応させることができる例示的な包括的配信フォーマットを採用している。以上のように、図３に示すメディアはタイムドであり、図４に示すメディアはアンタイムドである。特定の包括的フォーマットは、その構造において十分にロバストであり、各レイヤがメディアのプレゼンテーションに寄与する顕著な情報の量に基づいてそれぞれが階レイヤ化され得る様々なメディア属性に対応する。階レイヤ化プロセスは、例えばプログレッシブＪＰＥＧ及びスケーラブルビデオアーキテクチャ（例えば、ＩＳＯ／ＩＥＣ １４４９６－１０ Ｓｃａｌａｂｌｅ Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇで規定されている）に適用できることに留意されたい。

一態様によれば、包括的なメディアフォーマットに従ってストリーミングされるメディアは、レガシー視覚及び音声メディアに限定されず、視覚、音、味覚、触覚、及び嗅覚に対して人間の感覚を刺激するために機械と相互作用する信号を生成することができる任意の種類のメディア情報を含み得る。

別の態様によると、包括的なメディアフォーマットに従ってストリーミングされるメディアは、タイムドメディア又はアンタイムドメディアの両方、又は両方の混合であることができる。

別の態様によると、包括的なメディアフォーマットは、ベースレイヤ とエンハンスメントレイヤ アーキテクチャを使用してメディアオブジェクトのレイヤ 化された表現を可能にすることによって、さらにストリーミング可能である。１つの実施例では、別個のベースレイヤ及びエンハンスメントレイヤは、各シーンのメディアオブジェクトに対するマルチ解像度又はマルチテッセレーション分析技術の適用によって計算される。これは、ＩＳＯ／ＩＥＣ １０９１８－１ （ＪＰＥＧ） 及びＩＳＯ／ＩＥＣ １５４４４－１ （ＪＰＥＧ ２０００） で指定されているプログレッシブレンダリングイメージフォーマットに似ているが、ラスターベースのビジュアルフォーマットに限定されない。実施例では、幾何学的オブジェクトのプログレッシブ表現は、ウェーブレット解析を使用して計算されたオブジェクトのマルチ解像度表現である可能性がある。

メディアフォーマットのレイヤ 化された表現の別の実施例では、エンハンスメントレイヤ は、ベースレイヤ によって表される視覚オブジェクトの表面の素材特性を改善する（ｒｅｆｉｎｉｎｇ）など、異なる属性をベースレイヤ に適用する。さらに別の実施例では、属性は、表面を滑らかなテクスチャから多孔質テクスチャに変更し、又は、マットな表面から光沢のある表面に変更したりするなど、基本レイヤオブジェクトの表面のテクスチャを洗練させることができます。

レイヤ化された表現のさらに別の実施例では、シーン内の１つ以上の視覚オブジェクトの表面を、ランバーシアンからレイ トレース可能に変更することができる。

レイヤ 化された表現のさらに別の例では、ネットワークはクライアントにベースレイヤ 表現を配信し、クライアントがベース表現の解像度又はその他の特性を改善するために追加のエンハンスメントレイヤ の送信を待機している間に、クライアントがシーンの名目上のプレゼンテーション（ａ ｎｏｍｉｎａｌ ｐｒｅｓｅｎｔａｔｉｏｎ）を作成できるようにする。

別の態様によると、エンハンスメントレイヤ の属性又は改善情報の解像度は、既存のＭＰＥＧビデオ及びＪＰＥＧイメージ標準で現在行われているように、ベースレイヤ のオブジェクトの解像度と明示的に結合されていない。

別の態様によれば、包括的なメディアフォーマットは、プレゼンテーションデバイス又はマシンによって提示又は動作させることができる任意の種類の情報メディアをサポートし、それによって異種クライアントのエンドポイントに対する異種メディアフォーマットのサポートを可能にする。メディアフォーマットを配信するネットワークの一実施形態では、ネットワークは最初にクライアントエンドポイントに照会してクライアントの能力を判断し、クライアントがメディア表現を意味のある形で取り込むことができない場合、ネットワークはクライアントによってサポートされていない属性のレイヤを削除するか、又はメディアを現在のフォーマットからクライアントエンドポイントに適したフォーマットに適応させる。かかる適応の一実施例では、ネットワークは、ネットワークベースのメディア処理プロトコルを使用することにより、ボリューメトリックな視覚メディアアセットを同じ視覚アセットの２Ｄ表現に変換する。かかる適応の別の実施例では、ネットワークは、ニューラルネットワークプロセスを採用して、メディアを適切な形式に再フォーマットし、又は、オプションでクライアントエンドポイントが必要とするビューを合成する。

別の態様によれば、完全に又は部分的に完全なイマーシブ体験（ライブストリーミングイベント、ゲーム、又はオンデマンドアセットの再生）に対するマニフェストは、レンダリング及びゲームエンジンがプレゼンテーションを作成するために現在取り込むことができる最小限の情報量であるシーンによって編成される。マニフェストは、クライアントによって要求された没入体験全体に対してレンダリングされる個々のシーンのリストを含む。各シーンには、シーンジオメトリのストリーミング可能なバージョンに対応するシーン内のジオメトリックオブジェクトの１つ以上の表現が関連付けられている。シーン表現の１つの実施形態は、シーンに対するジオメトリックオブジェクトの低解像度バージョンに関連する。同じシーンの別の実施形態は、シーンの低解像度表現のエンハンスメントレイヤ に関連し、同じシーンのジオメトリックオブジェクトに追加の詳細を追加し、テッセレーションを増加させる。前述のように、各シーンは複数のエンハンスメントレイヤを有し、シーンのジオメトリオブジェクトの詳細をプログレッシブ方式で増加させることができる。

別の態様によると、シーン内で参照されるメディアオブジェクトの各レイヤ は、ネットワーク内でリソースにアクセスできる場所のアドレスを指すトークン（例：ＵＲＩ）に関連付けられる。かかるリソースは、クライアントがコンテンツを取得できるＣＤＮに似ている。

別の態様によると、幾何学的オブジェクトの表現のためのトークンは、ネットワーク内の場所又はクライアント内の場所を指し得る。すなわち、クライアントは、そのリソースがネットワークベースのメディア処理のためにネットワークで利用可能であることをネットワークにシグナリングすることができる。

図３は、いくつかの実施例において、タイムドメディアのための包括的なメディアフォーマットの実施形態を示す。いくつかの実施例では、タイムドシーンマニフェストはシーン（シーン情報とも称される）（３０１）を含む。シーン（３０１）は、シーン（３０１）を含む処理情報及びメディアアセットの種類を個別に記述するコンポーネント（３０２）のリストに関連する。コンポーネント（３０２）は、ベースレイヤ（３０４）と属性強化レイヤ（３０５）をさらに参照するアセット（３０３）に関連する。

図４は、いくつかの実施例において、アンタイムドメディアのための包括的なメディアフォーマットの実施形態を示す。アンタイムドシーンマニフェストは、シーン（４０１）を含む。シーン（シーン情報とも称される）（４０１）は、クロックによる開始期間と終了期間とは関連付けられていない。シーン（４０１）は、処理情報と、シーン（４０１）を有するメディアアセットのタイプと、を個別に記述するコンポーネント（４０２）のリストに関連する。コンポーネント（４０２）は、ベースレイヤ（４０４）と属性強化レイヤ（４０５）とをさらに参照するアセット（４０３）（例：視覚、音声、触覚アセット）に関連する。さらに、シーン（４０１）は、アンタイムドメディア用の他のシーン（４１１）に関連する。シーン（４０１）は、いくつかの実施例では、タイムドメディアシーン（４０７）に関連し得る。

図５は、自然なコンテンツから取り込みフォーマットを合成するプロセス （５００） の図を示す。プロセス （５００） は、コンテンツキャプチャのための第一サブプロセスと、自然画像のための取り込みフォーマット合成の第二サブプロセスと、を含む。

図５の実施例では、最初のサブプロセスにおいて、カメラユニットを使用して自然画像コンテンツ（５０９）をキャプチャできる。例えば、カメラユニット（５０１）は、単一のカメラレンズを使用して人物のシーンをキャプチャできます。カメラユニット（５０２）は、リング状のオブジェクトの周囲に５つのカメラレンズを装着することで、５つの視野が分岐するシーンをキャプチャできる。（５０２）の装置は、ＶＲアプリケーションに対する全方位コンテンツをキャプチャするための例示的な装置である。カメラユニット（５０３）は、球体の内径部分に７つのカメラレンズを装着することによって、７つの収束する視野を有するシーンをキャプチャする。（５０３）の装置は、光フィールド又はホログラフィックイマーシブディスプレイ用の光フィールドをキャプチャするための例示的な装置である。

図５の例では、２番目のサブプロセスで、自然な画像コンテンツ（５０９）が合成されます。例えば、自然な画像コンテンツ（５０９）は、例えば、キャプチャニューラルネットワークモデル（５０８）を生成するために、トレーニング画像のコレクション（５０６）を使用してニューラルネットワークトレーニングモジュール（５０５）を採用することができる合成モジュール（５０４） への入力として提供されます。トレーニングプロセスの代わりに一般的に使用される別のプロセスは、写真測量です。モデル（５０８）が図５に示されているプロセス（５００）の間に作成された場合、モデル（５０８）は自然コンテンツの取り込みフォーマット（５０７）のアセットの一つになる。取り込みフォーマット（５０７）の例示的な実施形態には、ＭＰＩ及びＭＳＩが含まれる。

図６は、合成メディア（６０８）、例えばコンピュータ生成画像のための取り込みフォーマットを作成するプロセス（６００）の図を示す。図６の実施例では、ＬＩＤＡＲカメラ（６０１）がシーンの点群（６０２）をキャプチャする。合成コンテンツを作成するためのコンピュータ生成画像 （ＣＧＩ）ツール、３Ｄモデリングツール、又は別のアニメーションプロセスは、ネットワーク経由で （６０４）ＣＧＩアセットを作成するためにコンピュータ（６０３）で使用される。センサー付きモーションキャプチャスーツ（６０５Ａ）をアクター（６０５）が着用して、アクター （６０５） の動きのデジタル記録をキャプチャし、アニメーションモーションキャプチャ（ＭｏＣａｐ）データ（６０６）を生成する。データ（６０２）、（６０４）、及び（６０６）は、合成モジュール（６０７） への入力として提供され、同様に、ニューラルネットワークとトレーニングデータを使用してニューラルネットワークモデル（図６には示されていない）を作成することもできる。

図７は、いくつかの実施例において、クライアントエンドポイントとして、さまざまなレガシーメディア及び異種のイマーシブメディア対応ディスプレイをサポートするネットワークメディア配信システム（７００）を示す。図７の実施例では、コンテンツ取得モジュール（７０１）は、図６又は図５の例示的の実施形態を使用してメディアをキャプチャ又は作成する。取り込みフォーマットは、コンテンツ準備モジュール（７０２）で作成され、その後、伝送モジュール（７０３）を使用してネットワークメディア配信システム内の１つ以上のクライアントエンドポイントに伝送される。ゲートウェイ（７０４）は、ネットワークに対するさまざまなクライアントエンドポイントへのネットワークアクセスを提供するために、顧客構内機器（ｃｕｓｔｏｍｅｒ ｐｒｅｍｉｓｅ ｅｑｕｉｐｍｅｎｔ）にサービスを提供し得る。セットトップボックス（７０５）は、ネットワークサービスプロバイダによって集約されたコンテンツへのアクセスを提供するために、顧客構内機器としても機能し得る。無線復調器（７０６）は、モバイルデバイス（例えば、携帯電話やディスプレイ（７１３）のように）のためのモバイルネットワークアクセスポイントとして機能し得る。１つ以上の実施形態では、レガシー２Ｄテレビ（７０７）は、ゲートウェイ（７０４）、セットトップボックス（７０５）、又はＷｉＦｉルーター（７０８）に直接接続し得る。レガシー２Ｄディスプレイ（７０９）を備えるコンピュータラップトップは、ＷｉＦｉルーター（７０８）に接続されたクライアントエンドポイントであり得る。ヘッドマウント２Ｄ（ラスターベース）ディスプレイ（７１０）は、ルーター（７０８）にも接続し得る。レンチキュラーライトフィールドディスプレイ（７１１）は、ゲートウェイ（７０４）に接続し得る。ディスプレイ（７１１）は、ローカルコンピューティングＧＰＵ（７１１Ａ）、ストレージデバイス（７１１Ｂ）、及び光線ベースのレンチキュラー光学技術を使用して複数のビューを作成するビジュアルプレゼンテーションユニット（７１１Ｃ）で構成され得る。ホログラフィックディスプレイ（７１２）は、セットトップボックス（７０５）に接続され得、ローカルコンピューティングＣＰＵ（７１２Ａ）、ＧＰＵ（７１２Ｂ）、ストレージデバイス （７１２Ｃ）、及びＦｒｅｓｎａｌパターンのウェーブベースのホログラフィック視覚化ユニット（７１２Ｄ）を含み得る。拡張現実ヘッドセット（７１４）は、無線復調器（７０６）に接続され得、ＧＰＵ（７１４Ａ）、ストレージデバイス（７１４Ｂ）、バッテリー（７１４Ｃ）、及びボリュームメトリック視覚プレゼンテーションコンポーネント（７１４Ｄ）を含む場合がありますみ得る。高密度ライトフィールドディスプレイ（７１５）は、ＷｉＦｉルーター（７０８）に接続し得、複数のＧＰＵ（７１５Ａ）、ＣＰＵ（７１５Ｂ）、及びストレージデバイス（７１５Ｃ）；アイトラッキングデバイス（７１５Ｄ）；カメラ（７１５Ｅ）；及び高密度の光線ベースのライトフィールドパネル（７１５Ｆ）を含み得る。

図８は、以前に図７に示したようなレガシーメディア及び異種のイマーシブメディア対応ディスプレイに対応できるイマーシブメディア配信モジュール（８００）の図を示す。コンテンツはモジュール（８０１）で作成又は取得され、これは図５及び図６にそれぞれ自然コンテンツ及びＣＧＩコンテンツとして表現されている。その後、コンテンツはネットワーク取り込みフォーマット作成モジュール（８０２）を使用して取り込みフォーマットに変換される。モジュール（８０２）のいくつかの実施例は、図５及び図６に、それぞれ自然コンテンツとＣＧＩコンテンツのために表現されている。取り込みメディアフォーマットはネットワークに送信され、ストレージデバイス（８０３）に保存される。他のいくつかの実施例では、ストレージデバイスはイマーシブメディアコンテンツプロデューサのネットワークに存在し、二分する点線で示されるように、イマーシブメディアネットワーク配信モジュール（８００）によってリモートでアクセスされ得る。クライアント及びアプリケーション固有の情報は、いくつかの実施例では、リモートストレージデバイス（８０４）上で利用可能であり、実施例ではオプションで代替クラウドネットワークにリモートで存在し得る。

図８に示すように、クライアントインタフェースモジュール（８０５）（例えば、いくつかの例ではサーバデバイスと呼ばれる）は、配信ネットワークの主要なタスクを実行するための情報の主要なソース及びシンクとして機能する。この特定の実施形態では、クライアントインタフェースモジュール（８０５）は、ネットワークの他のコンポーネントと統一されたフォーマットで実装することができる。それにもかかわらず、図８のクライアントインタフェースモジュール（８０５）によって示されるタスクは、いくつかの例において、開示された主題の要素を形成する。クライアントインタフェースモジュール（８０５）は、クライアントデバイスの特性に従ってメディアの全ての処理と配信を容易にするために、クライアントデバイスとの通信に双方向プロトコルをさらに採用することができる。さらに、双方向プロトコルは、異なる配信チャネル、すなわち、制御プレーンチャネルとデータプレーンチャネルにわたって実装することができる。

開示のいくつかの態様によると、クライアントインタフェースモジュール（８０５）は、クライアントデバイスの特性に従ってメディア（例えば、イマーシブメディア）の処理と配信を容易にするために、クライアントデバイスとの通信に双方向プロトコルをさらに採用することができる。

クライアントインタフェースモジュール（８０５）は、図８のクライアント（８０８）（クライアントデバイス（８０８）とも称される）などのクライアントデバイスの特徴と属性に関する情報を受信し、さらにクライアント（８０８）上で現在実行されているアプリケーションに関する要件を収集する。この情報は、デバイス（８０４）から取得することも、別の実施形態では、クライアント（８０８）に直接照会することによって取得することもできる。いくつかの例では、双方向プロトコルを使用して、クライアントインタフェースモジュール（８０５）とクライアント（８０８）の間の直接通信を可能にする。例えば、クライアントインタフェースモジュール（８０５）は、クライアント （８０８） に直接クエリを送信できる。双方向プロトコルのメッセージの例は、図１６Ａ－Ｃ、図１７Ａ－Ｇ及び図１８を参照して提供される。

クライアントインタフェースモジュール（８０５）も開始し、図９で説明するメディア適応及びフラグメンテーションモジュール（８１０）と通信する。取り込みメディアはモジュール（８１０）によって適応及び断片化されるため、メディアは、いくつかの実施例では、配信ストレージデバイス（８０９）用に準備されたメディアとして示されるインターメディアストレージデバイスに転送される。配信メディアがデバイス（８０９）に準備及び格納されると、クライアントインタフェースモジュール（８０５）は、イマーシブクライアント（８０８）が、そのネットワークインタフェース（８０８Ｂ）を介して、プッシュ要求を通じて配信メディア及び対応する記述情報（８０６）を受信するか、クライアント（８０８）自体がストレージデバイス（８０９）からメディア（８０６）のプル要求を開始し得る。イマーシブクライアント（８０８）は、いくつかの実施例では、ＧＰＵ（又は表示されていないＣＰＵ）（８０８Ｃ）を採用し得る。メディアの配信フォーマットは、クライアント（８０８）のストレージデバイス又はストレージキャッシュ（８０８Ｄ）に保存される。最終的に、イマーシブクライアント（８０８）は、その視覚化コンポーネント（８０８Ａ）を介してメディアを視覚的に提示する。

イマーシブメディアをイマーシブクライアント（８０８）にストリーミングするプロセス全体を通して、クライアントインタフェースモジュール（８０５）は、クライアントの進行状況とステータスフィードバックチャネル（８０７）を介してクライアントの進行状況のステータスを監視できる。

図９は、いくつかの実施例において、メディア適応プロセスの図を示し、したがって、取り込まれたソースメディアがイマーシブクライアント（８０８）の要件に適合するように適切に適応される。メディア適応モジュール（９０１）は、イマーシブクライアント（８０８）のための適切な配信フォーマットへの取り込みメディアの適応を容易にする複数のコンポーネントを備える。図９では、メディア適応モジュール（９０１）は、ネットワーク上の現在のトラフィック負荷を追跡するために入力ネットワークステータス（９０５）を受信する。イマーシブクライアント（８０８）情報には、属性と特徴の記述、アプリケーションの特徴と記述、及びアプリケーションの現在のステータス、及び、クライアントのフラスタムのジオメトリを取り込みイマーシブメディアの補間機能にマッピングするのに役立つクライアントニューラルネットワークモデルを含むことができる。メディア適応モジュール（９０１）は、適応された出力が作成されたときに、クライアント適応型メディアストレージデバイス（９０６）に格納されることを保証する。

いくつかの実施例では、メディア適応モジュール（９０１）は、レンダラー（９０１Ｂ）又はニューラルネットワークプロセッサ（９０１Ｃ）を採用して、特定の取り込み元メディアをクライアントに適したフォーマットに適応させる。一実施例では、メディア適応モジュール（９０１）は、クライアント情報（９０４）を、例えばサーバデバイスなどのクライアントインタフェースモジュール（９０３）から受信する。クライアント情報（９０４）は、クライアント記述と現在ステータスを含み、アプリケーション記述と現在ステータスを含み、及びクライアントニューラルネットワークモデルを含むことができる。ニューラルネットワークプロセッサ（９０１Ｃ）は、ニューラルネットワークモデル（９０１Ａ）を使用する。かかるニューラルネットワークプロセッサ（９０１Ｃ）の例は、ＭＰＩ及びＭＳＩで記述されているように、ＤｅｅｐＶｉｅｗニューラルネットワークモデル生成器を含む。いくつかの実施例では、メディアは２ Ｄフォーマットであるが、クライアントは３Ｄフォーマットを必要とし、その後、ニューラルネットワークプロセッサ（９０１Ｃ）は、２Ｄビデオ信号から高度に相関されたイメージを使用するプロセスを呼び出して、ビデオに描写されたシーンのボリューム表現を派生させることができる。このようなプロセスの例としては、カリフォルニア大学バークレー校で開発された１つ又はいくつかの画像プロセスからのＮｅＲＦ（ｔｈｅ ｎｅｕｒａｌ ｒａｄｉａｎｃｅ ｆｉｅｌｄｓ）が考えられる。適切なレンダラー（９０１Ｂ）の例としては、メディア適応モジュール（９０１）と直接相互作用するように変更されるＯＴＯＹ Ｏｃｔａｎｅレンダラー（図示せず） の変更バージョンがあり得る。メディア適応モジュール（９０１）は、いくつかの例では、取り込みメディアのフォーマットとイマーシブクライアント（８０８）が必要とするフォーマットとに関して、これらのツールの必要性に応じて、メディアコンプレッサー（９０１Ｄ）とメディアデコンプレッサー（９０１Ｅ）を採用し得る。

図１０は、いくつかの実施例において、クライアント適応メディアストレージデバイス（１００２）上に現在存在するメディア適応モジュール（１００１）（例えば、図９のメディア適応モジュール（９０１）に対応する）から適応メディアを最終的に変換する適応メディアパッケージングプロセスを示す。例えば、メディアパッキングモジュール（１００３）は、メディア適応モジュール（１００１）から適応メディアを、例えば図３又は図４に示されている例示的なフォーマットであるロバストな配信フォーマット（１００４）にフォーマットする。マニフェスト情報（１００４Ａ）は、クライアント（８０８） が受信することを期待できるシーンデータのリストをイマーシブクライアント（８０８） に提供し、視覚アセット及び対応するメタデータ、及び音声アセット及び対応するメタデータのリストも提供する。

図１１は、いくつかのじっし例におけるフラグメンテーションプロセスを示す。図１１の例では、パケタイザ（１１０２）は、ネットワーク上のクライアントエンドポイント（１１０４）として示されるイマーシブクライアント（８０８）へのストリーミングに適した個々のパケット（１１０３） にさまざまな適応メディア（１１０１）をフラグメント化する。

図１２は、いくつかの実施例において、特定のイマーシブメディアクライアントのエンドポイントに対して、取り込みフォーマットの特定のイマーシブメディアを、ストリーミング可能で適切な配信フォーマットに適応させるネットワークのシーケンスを示す図である。

図１２に示すコンポーネントと通信は、次のように説明される：クライアント （１２０１） （いくつかの実施例ではクライアントエンドポイントとも称される） は、ネットワーク配信インタフェース（１２０２）へのメディア要求（１２０８）を開始する。メディア要求（１２０８）には、ＵＲＮ又はその他の標準的な命名法のいずれかによって、クライアント（１２０１）によって要求されたメディアを識別するための情報が含まれる。ネットワーク配信インタフェース（１２０２）、クライアント（１２０１）が現在使用可能なリソース（計算、ストレージ、充電されたバッテリーの割合、及びクライアントの現在の動作ステータスを特徴づけるその他の情報を含む）に関する情報を提供することを要求するプロファイル要求（１２０９）でメディア要求（１２０８）に応答する。プロファイル要求（１２０９）はまた、クライアントでそのようなモデルが使用可能な場合、クライアントのプレゼンテーションシステムの特徴に適合する正しいメディアビューを抽出又は補間するために、ニューラルネットワーク推論のためにネットワークで使用できる１つ以上のニューラルネットワークモデルをクライアントが提供することを要求する。クライアント（１２０１）からネットワーク配信インタフェース（１２０２）への応答（１２１０）は、クライアントトークン、アプリケーショントークン、及び１つ以上のニューラルネットワークモデルトークン（かかるニューラルネットワークモデルトークンがクライアントで使用可能な場合）を提供する。ネットワーク配信インタフェース（１２０２）は、その後クライアント（１２０１）にセッションＩＤトークン（１２１１）を提供する。その後、ネットワーク配信インタフェース（１２０２）は、要求（１２０８）で識別されたメディアのためのＵＲＮ又は標準的な命名法の名前を含む、取り込みメディア要求（１２１２）で取り込みメディアサーバ（１２０３）を要求する。取り込みメディアサーバ（１２０３）は、取り込みメディアトークンを含む応答（１２１３）で要求（１２１２）に応答する。次に、ネットワーク分散インタフェース（１２０２）は、コール（１２１４）の応答（１２１３）からクライアント（１２０１）にメディアトークンを提供する。その後、ネットワーク配信インタフェース（１２０２）は、取り込みメディアトークン、クライアントトークン、アプリケーショントークン、及びニューラルネットワークモデルトークン（１２１５）を適応インタフェース（１２０４）に提供することによって、メディア要求（１２０８）の適応プロセスを開始する。適応インターフェース（１２０４）は、取り込みメディアアセットへのアクセスを要求するための呼び出し（１２１６）で取り込みメディアサーバ（１２０３）に取り込みメディアトークンを提供することによって、取り込みメディアへのアクセスを要求する。取り込みメディアサーバ（１２０３）は、適応インタフェース（１２０４）への応答（１２１７）に応じて、取り込みメディアアクセストークンで要求（１２１６）に応答する。適応インタフェース（１２０４）は、メディア適応モジュール（１２０５）が、（１２１３）で作成されたセッションＩＤトークンに対応する、クライアント、アプリケーション、及びニューラルネットワーク推論モデルのために、取り込みメディアアクセストークンに位置する取り込みメディアを適応させるように要求する。適応インタフェース（１２０４）からメディア適応モジュール（１２０５）への要求（１２１８）には、必要なトークン及びセッションＩＤが含まれる。メディア適応モジュール（１２０５）は、ネットワーク配信インタフェース（１２０２）に適応型メディアアクセストークン及びセッションＩＤを更新（１２１９）で提供する。ネットワーク配信インタフェース（１２０２）は、パッケージモジュール（１２０６）に適応型メディアアクセストークンとセッションＩＤをインタフェースコール（１２２０）で提供する。パッケージモジュール（１２０６）は、応答メッセージ（１２２１）でパッケージ化されたメディアアクセストークン及びセッションＩＤを使用して、ネットワーク配信インタフェース（１３０２）への応答（１２２１）を提供する。パッケージモジュール（１２０６）は、応答（１２２２）でパッケージ化されたアセット、ＵＲＮ、及びセッションＩＤのパッケージ化されたメディアアクセストークンをパッケージ化されたメディアサーバ（１２０７）に提供する。クライアント（１２０１）は要求（１２２３）を実行して、応答メッセージ（１２２１）で受信したパッケージ化されたメディアアクセストークンに対応するメディアアセットのストリーミングを開始する。クライアント（１２０１） は他の要求を実行し、メッセージ（１２２４）のステータス更新をネットワーク配信インタフェース （１２０２）に提供する。

図１３は、いくつかの実施例では、３Ｄフォーマット（１３０１）及び２Ｄフォーマット（１３０２）のイマーシブメディア及びアセットの２つの部分で構成される、図９の取り込みメディアフォーマット及びアセット（９０２）を示す。２Ｄフォーマット（１３０２）は、例えば、ＩＳＯ／ＩＥＣ １４４９６ Ｐａｒｔ １０ Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇのように、シングルビューでコード化されたビデオストリームでも、例えば、ＩＳＯ／ＩＥＣ １４４９６ Ｐａｒｔ １０のマルチビュー圧縮修正版のように、複数のビューを含むコード化されたビデオストリームでもあり得る。

図１４は、コード化されたビデオストリームに沿ったニューラルネットワークモデル情報の搬送を示す図である。図１４において、コード化ビデオストリーム（１４０１）は、ニューラルネットワークモデルと、一つ以上のＳＥＩメッセージ（１４０１Ａ）及び符号化ビデオストリーム（１４０１Ｂ）によって直接運ばれる対応するパラメータを含む。一方、コード化ビデオストリーム（１４０２）では、１つ以上のＳＥＩメッセージは、ニューラルネットワークモデルとその対応するパラメータ（１４０２Ａ）及びコード化ビデオビットストリーム（１４０２Ｂ）の識別子を搬送する。（１４０２）のシナリオでは、ニューラルネットワークモデル及びパラメータは、例えば図９の（９０１Ａ）のように、コード化ビデオストリームの外部に格納される。

図１５は、取り込まれたイマーシブメディア及びアセット３Ｄフォーマット（１５０１）（図１３の３Ｄフォーマット（１３０１）のイマーシブメディア及びアセットに対応する）でのニューラルネットワークモデル情報の搬送を示す。取り込まれたイマーシブメディア及びアセットの３Ｄフォーマット（１５０１）は、１５０２）として表されたシーン１からＮを参照する。各シーン（１５０２）は、ジオメトリ（１５０３）及び処理パラメータ（１５０４）を参照する。ジオメトリ（１５０３）は、ニューラルネットワークモデルへの参照（１５０３Ａ）を含み得る。処理パラメータ（１５０４）は、ニューラルネットワークモデルへの参照（１５０４Ａ）を含み得る。（１５０４Ａ）及び（１５０３Ａ）の両方は、シーンと共に直接格納されているネットワークモデル、又は取り込まれたメディアの外部に存在するニューラルネットワークモデルを参照する識別子、例えば、図９の９０１Ａ）に格納されているネットワークモデルを参照することができる。

本開示の様々なモジュールは、個々のデバイスであることも、デバイス内のコンポーネントであることもできることに留意されたい。いくつかの実施例では、モジュールは個々のデバイスであり、他のデバイスと結合することができる。いくつかの実施例では、モジュールは処理回路であり、他の処理回路と相互接続することができる。いくつかの実施例では、モジュールはソフトウェア命令モジュールであり、１つ以上のプロセッサで実行できる。

開示のいくつかの態様は、メディア配信ネットワークのクライアントインタフェース（サーバデバイスとも称される）がクライアントプレゼンテーションエンドポイント（つまり、クライアントデバイスとも称される）と直接通信できるようにする双方向メッセージを有する双方向プロトコルを提供する。いくつかの実施例では、双方向プロトコルはトランスポートレイヤ上のネットワークレイヤで実装できる。いくつかの実施例では、双方向プロトコルを使用して、サーバデバイスはクライアント固有の特性とクライアントデバイスのサポートされている機能に関する情報を取得できる。いくつかの実施例では、双方向プロトコルを使用して、サーバデバイスは、クライアントデバイスへのメディアの適応と配信のためのユニークなセッションと動作コンテキストを確立することによって、クライアントデバイスへのメディアの配信を管理できる。いくつかの実施例では、双方向プロトコルを使用して、サーバデバイスは、特定のメディアの表示において、例えばコンピューティング又はストレージなどのために、クライアントデバイスのリソースを補完するためにクライアントデバイスがネットワークに依存する必要があれば又は必要な場合に、セッション中の状況に応答できる。いくつかの実施例では、双方向プロトコルは、クライアントデバイスの機能に適合するように、入力メディアの適応プロセスでサーバデバイスをアシストできる。いくつかの実施例では、双方向プロトコルは、例えばスタジオ又はクライアントデバイスのコンテンツクリエータによってそのような再利用が許可されれば又は許可される場合、複数のクライアントデバイスにわたるプレゼンテーションのための特定のメディアアセットの効率的な再利用を可能にする。いくつかの実施例では、双方向プロトコルを使用して、サーバデバイスは、ネットワークオペレータ（ワイヤレスサービスプロバイダー、ワイヤレスキャリア、モバイルネットワークキャリアとも称される）とクライアントデバイスと間の既存のサービスレベル契約に従って、クライアントデバイスのメディアのほぼリアルタイムのプレゼンテーションを容易にすることができる。いくつかの実施例では、双方向プロトコルを使用して、サーバデバイスは、アプリケーション、例えば相互作用ゲーム対線形パッシブ視覚経験、の要件に従って、クライアントデバイスによるメディアのほぼリアルタイムの表示を容易にすることができる。

開示の一態様によると、双方向プロトコルは、クライアントデバイスと直接通信するサーバデバイスの双方向プレゼンテーションデータストリームを形成するために使用される。双方向プレゼンテーションデータストリームには、入力メディアをクライアントデバイスに適した配信フォーマットにタイムリーに適応させ、適応されたメディアをプレゼンテーション用にクライアントデバイスにストリーミングすることを容易にするために、サーバデバイスとクライアントデバイスの間で交換される一連のメッセージが含まれる。

双方向プロトコルは、さまざまなフォーマットのアセットタイプを必要とするさまざまな多様なクライアントデバイスをサポートし、特定のクライアントによる使用に以前に適応されたアセットを再利用できる、メディア配信ネットワークを構築するために使用できる。

図１６Ａ－１６Ｃは、いくつかの実施例では、サーバデバイス（例えば、図８にクライアントインタフェースモジュール（８０５）として示されている）とクライアントデバイスと（例えば、図８にイマーシブクライアント（８０８）として示されている。）の間で交換できるメッセージのリストを提供する。いくつかの実施例では、メッセージのリストは、サーバデバイスから発信されクライアントデバイスに送信されるメッセージ及び情報（８０６）を含むことができ、クライアントデバイスから発生し、サーバデバイスに送信されるフィードバック及びステータス（８０７）を含むことができる。

図１６Ａ－１６Ｂは、サーバデバイスからクライアントデバイスに送信されるメッセージ（番号が１から２０のメッセージ）の最初のグループを示し、図１６Ｃは、いくつかの実施形態に従ってクライアントデバイスからサーバデバイスに送信されるメッセージ（２１から３１でナンバリングされたメッセージ）の第２グループを示す。

図１７Ａ－１７Ｇは、いくつかの実施例のメッセージの第１グループのための意味情報の表を示す。図１８は、いくつかの実施例のメッセージの第２グループのための意味情報の表を示す。

図１６Ａ－１６Ｃ、図１７Ａ－１７Ｇ及び図１８のメッセージが図示されていることに留意されたい。双方向プロトコルのメッセージを変更及び／又は省略することができる。追加のメッセージを追加することができる。

一部の実装では、メディア配信ネットワークは、双方向プロトコルによって定義されたメッセージを使用して、イマーシブメディアコンテンツなどのメディアの適応とストリーミングを容易にすることができる。いくつかの実施例では、双方向プロトコルは、実行するアクションをシグナリングする特定のメッセージを含むことができる。例えば、特定のメッセージにより、クライアントデバイスがその処理特性をサーバデバイスに送信するようにすることができ、その結果、クライアントデバイスの処理特性を受信すると、サーバデバイスには、取り込まれたメディアをクライアントデバイスに適したフォーマットに有意義に適応させるのに十分な情報が備わっている。別の実施例では、サーバデバイスとクライアントデバイスとの間でメッセージを交換して、クライアントデバイスのエンドユーザが体験したいプレゼンテーションのためのシーンのマニフェストをサーバデバイスが送信できるようにすることができる。例えば、かかるマニフェストを受信すると、クライアントデバイスは、第１シーン、第２シーンなどのための各アセットを要求することを含む、プレゼンテーションの作成準備に必要なステップを開始できる。サーバデバイスは、メディアソースからアセットをクライアントに直接送信するか、近くのデータベースからアセットをフェッチするようにクライアントに通知することにより、アセットの各要求に応答できる。メッセージ要求に応答して、クライアントデバイス又はサーバデバイスは、メッセージ内の要求が正常に実行されたことを示す肯定応答、またはエラーが発生したことを示す否定応答で応答することができる。

開示のいくつかの態様は、双方向プロトコルの実装を容易にする技術を提供する。例えば、双方向プロトコルのメッセージは、制御メッセージ及びデータメッセージの２つのカテゴリに分けられる。いくつかの実施例では、データメッセージは配信用のメディアデータが含み、制御メッセージはデータメッセージを配信するための制御情報が含む。例えば、制御メッセージは、データメッセージの配信を準備するためのセットアップ情報、データメッセージの配信中の処理情報、データメッセージの配信後の情報の確認などを含むことができる。

さらに、制御メッセージ及びデータメッセージを配信するために、別々の通信技術が使用される。例えば、高速配信を可能にする第１通信技術を使用してデータメッセージを配信し、信頼性の高い配信を保証する第２の通信技術を使用して制御メッセージを配信できる。例えば、ユーザーデータグラムプロトコル（ＵＤＰ）などの低遅延のネットワークトランスポートプロトコルを使用してデータメッセージを配信し、伝送制御プロトコル（ＴＣＰ）などのより信頼性の高い接続ベースネットワークトランスポートプロトコルを使用して制御メッセージを配信できます。ＴＣＰは、順序、信頼性、整合性を保証できる。ＵＤＰは、オーバーヘッドとレイテンシを削減し、大量のデータユニットを送信できる。

いくつかの実施例では、制御メッセージは制御プレーンを形成し、制御プレーンチャネルは、制御メッセージの配信のためのメディア配信ネットワークアーキテクチャの統合コンポーネントに関連する。実施例では、制御プレーンチャネルは、制御メッセージを配信するためにＴＣＰプロトコルに従って設定できる。さらに、データメッセージはデータプレーンを形成し、データプレーンチャネルは、データメッセージの配信のためのメディア配信ネットワークアーキテクチャの統合コンポーネントに関連する。実施例では、データプレーンチャネルは、データメッセージを配信するためにＵＤＰに従って設定できる。

この方法では、メディアデータをより少ないレイテンシでデータプレーンチャネル上で送信することができ、設定情報、監視情報、及びデータプレーンチャネル上の送信を支援するステータス通知などの制御情報は、制御プレーンチャネル上で送信することができ、データメッセージの送信を成功させるか、又はデータプレーンチャネル上の送信のエラーを検出してデータプレーンチャネル上で再送信をトリガーすることができる。

開示の態様によると、別々の制御プレーンチャネルとデータプレーンチャネルを使用した双方向通信を使用して、さまざまなフォーマットのアセットタイプを必要とするさまざまな多様なクライアントデバイスをサポートでき、特定のクライアントデバイスでの使用に以前に適応されたアセットを再利用できるメディア配信ネットワークを構築することができる。制御プレーンチャネルとデータプレーンチャネル上での双方向通信の分離により、いくつかの例では、よりロバストで効率的なメディア配信ネットワークを実装することができ、データメッセージは、遅延が少なくても信頼性の低いトランスポートレイヤ上で伝送され、一方、制御メッセージは、メッセージの配信が遅い、より信頼性の高いトランスポートレイヤ上で伝送される。

図１９Ａは、本開示のいくつかの実施形態によるメディアシステム（１９００）のブロック図を示す。メディアシステム（１９００）は、サーバ装置（１９０１）とクライアント装置（１９０６）を含む。いくつかの例では、サーバデバイス（１９０１）はメディア配信ネットワーク（例：クライアントインタフェースモジュール（８０５））におけるクライアントインタフェースモジュールとも称される。図１９Ａの例では、サーバデバイス（１９０１）とクライアントデバイス（１９０６）との間の双方向通信のために、通信チャネル（１９０２）、（１９０３）、（１９０４）、（１９０５）を設定することができる。いくつかの実施例では、通信チャネルは物理的な伝送媒体を指することも、電気通信やコンピュータネットワークにおける多重化された媒体上の論理的な接続を指することもできる。

具体的には、通信チャネル（１９０２）は、サーバデバイス（１９０１）からクライアントデバイス（１９０６）に制御メッセージを配信するように構成される。図１９Ｂは、通信チャネル （１９０２）によって配信できる、図１６Ａ－１６Ｃにおける双方向プロトコルからの制御メッセージのリストを示す。

通信チャネル（１９０３）は、制御メッセージをクライアントデバイス（１９０６）からサーバデバイス（１９０１）に配信するように設定される。図１９Ｃは、通信チャネル（１９０３）によって配信できる、図１６Ａ－１６Ｃにおける双方向プロトコルからの制御メッセージのリストを示す。

いくつかの実施例では、通信チャネル（１９０２）及び通信チャネル（１９０３）は双方向の制御プレーンチャネルであることができる。図１９Ｂと図１９Ｃの制御メッセージは、双方向プロトコルの制御プレーンを形成する。

通信チャネル（１９０４）は、サーバデバイス（１９０１）からクライアントデバイス（１９０６）にデータメッセージを配信するように構成される。図１９Ｄは、通信チャネル（１９０４）によって配信できる、図１６Ａ－１６Ｃにおける双方向プロトコルからの制御メッセージのリストを示す。

通信チャネル（１９０５）は、データメッセージをクライアントデバイス（１９０６）からサーバデバイス（１９０１）に配信するように設定される。図１９Ｅは、通信チャネル（１９０５） によって配信できる、図１６Ａ－１６Ｃにおける双方向プロトコルからの制御メッセージのリストを示す。

いくつかの実施例では、通信チャネル（１９０４）は単方向のデータプレーンチャネルであり、通信チャネル（１９０５）は単方向の別のデータプレーンチャネルである。図１９Ｄ及び図１９Ｅのデータメッセージは、双方向プロトコルのデータプレーンを形成する。

図１９Ｂ－１９Ｅのメッセージが説明のためのものであることに留意されたい。通信チャネル（１９０２）－（１９０５）のメッセージを変更及び／又は省略することができる。追加のメッセージは、追加されることができる。

図２０は、いくつかの実施例において、双方向プロトコルの使用を説明するためのメディアシステム（２０００）のブロック図を示す。いくつかの実施例では、双方向プロトコルは、図１６Ａ－１６Ｃ、図１７Ａ－１７Ｇ及び図１８のメッセージを含むことができる。メッセージは、図１９Ａ－１９Ｅに従って制御プレーン及びデータプレーンに分けることができる。

メディアシステム（２０００）は、イマーシブメディアアプリケーション、拡張現実（ＡＲ）アプリケーション、仮想現実アプリケーション、ビデオゲームアプリケーション、スポーツゲームアニメーションアプリケーション、テレビ会議及びテレプレゼンスアプリケーション、メディアストリーミングアプリケーションなど、様々な用途のアプリケーションで使用することができる。

メディアシステム（２０００）は、サーバデバイス（２０１０）と、図２０に示すクライアントデバイス（２０６０Ａ）、（２０６０Ｂ）、（２０６０Ｃ）など、ネットワーク（図示せず）によって接続できる複数のメディアクライアントデバイスとを含む。一実施例では、サーバデバイス（２０１０）は、イマーシブメディアコーディング機能を備える１つ以上のデバイスを含むことができる。一実施例では、サーバデバイス（２０１０）は、デスクトップコンピュータ、ラップトップコンピュータ、サーバコンピュータ、タブレットコンピュータなどの単一のコンピューティングデバイスを含む。別の例では、サーバデバイス（２０１０）は、（１つ以上の）データセンター、（１つ以上の）サーバファームなどを含む。サーバデバイス（２０１０）は、イマーシブコンテンツ、ビデオコンテンツ、オーディオコンテンツなどの入力メディアコンテンツを受信することができる。クライアントデバイス（例エバクライアントデバイス（２０６０Ａ）、（２０６０Ｂ）、（２０６０Ｃ））は、それぞれ、メディアアプリケーションのためのメディアプレゼンテーション機能を備えた１つ以上のデバイスを含む。一実施例では、メディアクライアントデバイスは、デスクトップコンピュータ、ラップトップコンピュータ、サーバコンピュータ、タブレットコンピュータ、ヘッドマウントディスプレイ（ＨＭＤ）デバイス、レンチキュラライトフィールドディスプレイなどのプレゼンテーションデバイスを含むことができる。メディアクライアントデバイスは、いくつかの実施例では、適切なメディア提示フォーマットに従ってメディアを提示することができる。

サーバデバイス（２０１０）は、任意の適切な技術を使用して実装することができる。図２０の例では、サーバデバイス（２０１０）は、一緒に結合された処理回路（２０３０）とインタフェース回路（２０１１）をを含む。

処理回路（２０３０）は、１つ以上の中央処理ユニット（ＣＰＵ）、１つ以上のグラフィックス処理ユニット（ＧＰＵ）、特定用途向け集積回路など、任意の適切な処理回路を含むことができる。図２０の例では、処理回路（２０３０）は、双方向プロトコルに従ってメッセージを形成するように構成され、双方向プロトコルに従ってメッセージを解釈することができる。さらに、処理回路（２０３０）は、メディアコンテンツを搬送するメディアストリームを生成することができる。いくつかの実施例では、メディアストリームは、サーバデバイス（２０１０）とメディアクライアントデバイスとの間で交換されるメッセージに基づいて適応させることができる。

インタフェース回路（２０１１）は、サーバデバイス（２０１０）とネットワークをインタフェースすることができる。インタフェース回路（２０１１）は、ネットワークから信号を受信する受信部分と、ネットワークに信号を送信する送信部分を含めることができる。例えば、インタフェース回路（２０１１）は、ネットワークを介して、クライアントデバイス（２０６０Ａ）、クライアントデバイス（２０６０Ｂ）、クライアントデバイス（２０６０Ｃ）などの他のデバイスにメッセージを搬送する信号を送信することができる。インタフェース回路（２０１１）は、クライアントデバイス（２０６０Ａ）、（２０６０Ｂ）、（２０６０Ｃ）などのメディアクライアントデバイスからメッセージを搬送する信号を受信できる。

ネットワークは、イーサネット接続、光ファイバ接続、ＷｉＦｉ接続、セルラーネットワーク接続などの有線及び／又は無線接続を介して、サーバデバイス（２０１０）及びクライアントデバイス（例：クライアントデバイス（２０６０Ａ）、（２０６０Ｂ）、（２０６０Ｃ））と適切に結合される。

クライアントデバイス（例：クライアントデバイス（２０６０Ａ）、（２０６０Ｂ）、（２０６０ Ｃ））は、メディアプレゼンテーション用と双方向プロトコルを使用した双方向通信用にそれぞれ構成される。

クライアントデバイス（２０６０Ａ）、（２０６０Ｂ）、（２０６０Ｂ）などのメディアクライアントデバイスは、任意の適切なテクノロジーを使用して実装できる。図２０の実施例では、クライアントデバイス（２０６０Ａ）と（２０６０Ｂ）が示されるが、これは、ユーザーＡやユーザーＢなど、それぞれのユーザーによって使用できるユーザー機器としてイヤホンを備えるヘッドマウントディスプレイ（ＨＭＤ）に限定されない。クライアントデバイス（２０６０Ｃ）が示されるが、これは、最大複数のユーザーが同時に表示できるコンテンツを表示できるレンチキュラーライトフィールドディスプレイに限定されず、各ユーザーは表示されているコンテンツの独自の視点（すなわち、ビュー）を体験している。

図２０では、クライアントデバイス（２０６０Ａ）は、インタフェース回路（２０６１Ａ）と、図２０に示すように一緒に結合された処理回路（２０７０Ａ）を含む。クライアントデバイス（２０６０Ｂ）は、インタフェース回路（２０６１Ｂ）と、図２０に示すように一緒に結合された処理回路（２０７０Ｂ）を含む。クライアントデバイス（２０６０Ｃ）は、インタフェース回路（２０６１Ｃ）と、図２０に示すように一緒に結合された処理回路（２０７０Ｃ）を含む。

インタフェース回路（２０６１Ａ）は、クライアントデバイス（２０６０Ａ）とネットワークをインタフェースすることができる。インタフェース回路（２０６１Ａ）は、ネットワークからの信号を受信する受信部と、ネットワークに信号を送信する送信部を含むことができる。例えば、インタフェース回路（２０６１Ａ）は、サーバデバイス（２０１０）からメッセージを搬送する信号を受信し、サーバデバイス（２０１０）にメッセージを搬送する信号を送信することができる。

処理回路 （２０７０）は、ＣＰＵ、ＧＰＵ、特定用途向け集積回路などの適切な処理回路を含むことができる。処理回路（２０７０Ａ）は、メディアデコーダ、レンダリングなどのさまざまなコンポーネントを含むように構成することができる。

同様に、インタフェース回路（２０６１Ｂ）は、クライアントデバイス（２０６０Ｂ）とネットワークをインタフェースすることができる。インタフェース回路（２０６１Ｂ）は、ネットワークからの信号を受信する受信部と、ネットワークに信号を送信する送信部を含むことができる。例えば、インタフェース回路（２０６１Ｂ）は、サーバデバイス（２０１０）からメッセージを搬送する信号を受信し、サーバデバイス（２０１０）にメッセージを搬送する信号を送信することができる。

処理回路 （２０７０ Ｂ） は、ＣＰＵ、ＧＰＵ、特定用途向け集積回路などの適切な処理回路を含むことができる。処理回路 （２０７０ Ｂ） は、メディアデコーダ、レンダリングなどのさまざまなコンポーネントを含むように構成することができる。

同様に、インタフェース回路（２０６１Ｃ）は、クライアントデバイス（２０６０Ｃ）とネットワークをインタフェースすることができる。インタフェース回路（２０６１Ｃ）は、ネットワークからの信号を受信する受信部と、ネットワークに信号を送信する送信部を含むことができる。例えば、インタフェース回路（２０６１Ｃ）は、サーバデバイス（２０１０）からメッセージを搬送する信号を受信し、サーバデバイス（２０１０）にメッセージを搬送する信号を送信することができる。

処理回路 （２０７０ Ｃ） は、ＣＰＵ、ＧＰＵ、特定用途向け集積回路などの適切な処理回路を含むことができる。処理回路 （２０７０ Ｃ） は、メディアデコーダ、レンダリングなどのさまざまなコンポーネントを含むように構成することができる。

開示の一態様によれば、サーバデバイス（２０１０）とクライアントデバイス（２０６０Ａ）とは、その間で制御メッセージを交換（送受信）するための制御プレーンチャネル（２００１）を設定することができ；サーバデバイス（２０１０）とクライアントデバイス（２０６０Ｂ）とは、その間で制御メッセージを交換するための制御プレーンチャネル（２００３）を設定することができ；サーバデバイス（２０１０）とクライアントデバイス（２０６０Ｃ）とは、その間で制御メッセージを交換するための制御プレーンチャネル（２００５）を設定することができる。一実施例では、制御プレーンチャネル（２００１）、（２００３）、（２００５）はＴＣＰを使用でき、制御メッセージの双方向伝送を行うことができる。

いくつかの実施例では、チャネルプレーンチャネル（２００１）、（２００３）、（２００５）交換される制御メッセージに基づいて、データプレーンチャネルをメディアシステム（２０００）に設定することができる。一実施例では、制御プレーンチャネル（２００１）上で交換される制御メッセージに基づいて、サーバデバイス（２０１０）とクライアントデバイス（２０６０Ａ）との間にデータプレーンチャネル（２００２）を設定することができ；制御プレーンチャネル（２００３）上で交換される制御メッセージに基づいて、サーバデバイス（２０１０）とクライアントデバイス（２０６０Ｂ）との間にデータプレーンチャネル（２００４）を設定することができ；制御プレーンチャネル（２００５）の上で交換される制御メッセージに基づいて、サーバデバイス（２０１０）とクライアントデバイス（２０６０Ｃ）との間にデータプレーンチャネル（２００６）を設定することができる。一実施例では、データプレーンチャネル（２００２）、（２００４）、（２００６）はＵＤＰを使用でき、データメッセージの単方向送信を実行できる。

いくつかの実施例では、制御プレーンチャネル（２００１）、（２００３）、（２００５）を使用して、サーバデバイス（２０１０）は、クライアントデバイス（２０６０Ａ）、（２０６０Ｂ）、（２０６０Ｃ）のクライアント固有の特性とサポートされている特徴に関する情報を取得できまる。一実施例では、サーバデバイス（２０１０）は、制御チャネルプレーン（２００１）、（２００３）、（２００５）を介してそれぞれのメディアクライアントデバイスから情報を要求するために、クライアントデバイス（２０６０Ａ）、（２０６０Ｂ）、（２０６０Ｃ）へのそれぞれのメッセージを生成できる。この情報は、メディアクライアントデバイスのコンピューティングリソース、メディアクライアントデバイスのストレージリソース、メディアクライアントデバイスのネットワークサービスプロバイダとのサービスレベル契約、メディアクライアントデバイスのイマーシブアプリケーション要件、メディアクライアントデバイスの種類、メディアクライアントデバイスのモデル、クライアントデバイスのニューラルネットワークモデルが含まれるが、これらに限定されない。クライアントデバイス（２０６０Ａ）、（２０６０Ｂ）、及び（２０６０Ｃ）は、制御プレーンチャネル（２００１）、（２００３）、及び（２００５）を介して、サーバデバイス（２０１０）から受信したメッセージに応答して、要求された情報を提供できる。いくつかの実施例では、クライアントデバイス（２０６０Ａ）、（２０６０Ｂ）、（２０６０Ｃは、要求されることなく、クライアント固有の特性とサポートされる機能を自発的に提供できる。

いくつかの実施例では、制御プレーンチャネル（２００１）、（２００３）、（２００５）上で交換される制御メッセージを使用して、サーバデバイス（２０１０）は、メディアクライアントデバイスへのメディアの適応と配信のためのユニークなセッション及び動作コンテキストを確立することによって、メディアクライアントデバイスへのメディアの配信を管理できる。いくつかの実施例では、制御プレーンチャネル（２００１）、（２００３）、（２００５）上で交換される制御メッセージは、メディアクライアントデバイスの機能に適合するように入力メディアの適応プロセスでメディアサーバデバイス（２０１０を支援できる。

例えば、サーバデバイス（２０１０）は、制御プレーンチャネル（２００１）上で交換される制御メッセージに基づいて、クライアントデバイス（２０６０Ａ）との第１のユニークなセッション（例えば、データプレーンチャネル（２００２））を確立できる。サーバデバイス（２０１０）は、クライアントデバイス（２０６０Ａ）の機能に適合するように入力メディアから適応された第１メディアストリームを生成できる。データプレーンチャネル（２００２）は、第１メディアストリームをクライアントデバイス（２０６０Ａ）に提供できる。

サーバデバイス（２０１０）は、制御プレーンチャネル（２００３）上で交換される制御メッセージに基づいて、クライアントデバイス（２０６０Ｂ）との第２のユニークなセッション（例えば、データプレーンチャネル（２００４））を確立できる。サーバデバイス（２０１０）は、クライアントデバイス（２０６０Ｂ）の機能に適合するように入力メディアから適応された第２メディアストリームを生成できる。データプレーンチャネル（２００４）は、クライアントデバイス（２０６０Ｂ）に第２メディアストリームを提供できる。

サーバデバイス（２０１０）は、制御プレーンチャネル（２００５）上で交換される制御メッセージに基づいて、クライアントデバイス（２０６０Ｃ）との第２のユニークなセッション（例えば、データプレーンチャネル（２００６））を確立できる。サーバデバイス（２０１０）は、クライアントデバイス（２０６０Ｃ）の機能に適合するように入力メディアから適応された第３メディアストリームを生成できる。データプレーンチャネル（２００６）は、クライアントデバイス（２０６０Ｃ）に第３メディアストリームを提供できる。

いくつかの実施例では、制御プレーンチャネルを使用して、サーバデバイス（２０１０）は、特定のメディアの表示において、メディアクライアントデバイスがクライアントデバイスのリソース 、例えばコンピューティングやストレージなど）、を補完するためにネットワークに依存する必要があれば、又は必要な場合に、セッション中の状況に応答できる。一実施例では、クライアントデバイス（２０６０Ｂ）は、制御プレーンチャネル（２００３）を介して、クライアントデバイス（２０６０Ｂ）がコンピューティングリソース、例えば、レンダリングのための計算リソース、を補完するためにネットワークに依存する必要があることをサーバデバイス（２０１０）に通知する。サーバデバイス（２０１０）は、クライアントデバイス（２０６０Ｂ）に補完コンピューティングリソースを提供することを決定できる。例えば、サーバデバイス（２０１０）は、クライアントデバイス（２０２０Ｂ）のためにメディアデータに対して計算量の多いメディア処理を実行することができる。

いくつかの実施例では、制御プレーンチャネルを使用すると、スタジオ又はクライアントデバイスなどのコンテンツクリエータによって、かかる再利用が許可されている場合に、複数のクライアントデバイスにわたってプレゼンテーション用の特定のメディアアセットを効率的に再利用できる。一実施例では、サーバデバイス（２０１０）は、クライアントデバイス（２０６０Ａ）のメディアアセットをクライアントデバイス（２０６０Ｂ）に再利用するかどうかを決定できる。例えば、サーバデバイス（２０１０）は、制御プレーンチャネル（２００１）を介してクライアントデバイス （２０６０Ａ）からキャッシュ（例えば、ストレージ（２０９９））にレンダリングされたメディアアセットの情報を取得し、制御プレーンチャネル（２００３）を介してクライアントデバイス（２０６０Ｂ）に情報を提供できる。その後、クライアントデバイス（２０６０Ｂ）は、その情報に従ってレンダリングされたメディアアセットのキャッシュにアクセスできる。ストレージ（２０９９）は、クライアントデバイス（２０６０Ａ）の内部コンポーネントにすることも、クライアントデバイス（２０６０Ａ）の外部コンポーネントにすることもできる。

別の実施例では、サーバデバイス（２０１０）は、レンダリングされたメディアアセットをサーバデバイス（２０１０）に返送するようクライアントデバイス（２０６０Ａ）に要求し、その後、サーバデバイス（２０１０）は受信したメディアアセットをクライアントデバイス（２０６０Ｂ）に提供できる。一実施例では、制御プレーンチャネル（２００１）を介して、別のデータプレーンチャネル（２００７）が、レンダリングされたメディアアセットをクライアントデバイス（２０６０Ａ）からサーバデバイス（２０１０）に返送するように設定される。

図２１は、本開示の一実施形態によるプロセス（２１００）の概略を示すフローチャートを示す。プロセス（２１００）は、サーバデバイス（２０１０）などのサーバデバイスで使用できる。さまざまな実施形態では、プロセス（２１００）は、サーバデバイス（２０１０）の処理回路（２０３０）などの処理回路によって実行される。いくつかの実施形態では、プロセス（２１００）はソフトウェア命令で実装されるため、処理回路がソフトウェア命令を実行するとき、処理回路はプロセス（２１００）を実行する。プロセスは（Ｓ２１０１）から始まり、（Ｓ２１１０）に進む。

（Ｓ２１１０）において、サーバデバイスは、第１トランスポートプロトコルを使用する制御プレーンチャネルの上で、クライアントデバイスとと、複数の制御メッセージを交換する。複数の制御メッセージは、イマーシブメディア配信のための双方向プロトコルの制御プレーンに属する。イマーシブメディア配信のための双方向プロトコルは、一例では、オープンシステム相互接続 （ＯＳＩ） モデルにおけるアプリケーションレイヤ、プレゼンテーションレイヤなどのトランスポートレイヤの上のネットワークレイヤで実装することができる。

（Ｓ ２１２０）で、サーバデバイスは、第２トランスポートプロトコルを使用する第１データプレーンチャネルを介して、第１の複数のデータメッセージをクライアントデバイスに送信する。第１の複数のデータメッセージは、双方向プロトコルのデータプレーンに属し、３Ｄグラフィックデータなどの少なくともイマーシブなメディアコンテンツを伝送する。

いくつかの実施例では、第１トランスポートプロトコルは伝送制御プロトコル （ＴＣＰ） であり、第２トランスポートプロトコルはユーザーデータグラムプロトコル （ＵＤＰ） である。

いくつかの実施例では、第１トランスポートプロトコルはコネクションベースのトランスポートプロトコルであり、双方向であることができる。第２トランスポートプロトコルはコネクションレスの（ｃｏｎｎｅｃｔｉｏｎｌｅｓｓ）トランスポートプロトコルであり、単方向であることができる。

いくつかの実施例では、サーバデバイスは、制御プレーンチャネルを介して交換される複数の制御メッセージに従って、クライアントデバイスと第１データプレーンチャネルを設定することができる。

いくつかの実施例では、サーバデバイスは、制御プレーンチャネルを介してクライアントデバイスの１つ以上の特定の特性を受信することができ、１つ以上の特定の特性に従って、第１の複数のデータメッセージで搬送されるメディアストリームを適応させることができる。いくつかの実施例では、１つ以上の特定の特性は、クライアントデバイスのコンピューティングリソース、クライアントデバイスのストレージリソース、クライアントデバイスでのネットワークサービスプロバイダのサービスレベル契約、イマーシブアプリケーション要件、クライアントデバイスのタイプ、クライアントデバイスのモデル、及びクライアントデバイスでのニューラルネットワークモデルのうちの少なくとも１つを含むことができる。

いくつかの実施例では、サーバデバイスは、第２トランスポートプロトコルを使用する第２データプレーンチャネルの上で、クライアントデバイスから第２の複数のデータメッセージを受信することができる。第２の複数のデータメッセージは、クライアントデバイスにおけるニューラルネットワークモデルのレイヤ情報及びクライアントデバイスによってレンダリングされたメディアコンテンツのうちの少なくとも１つを搬送する。実施例において、サーバデバイスは、クライアントデバイスによってレンダリングされたメディアコンテンツを別のクライアントデバイスに送信することができる。

いくつかの実施形態では、クライアントデバイスは第１クライアントデバイスであり、複数の制御メッセージは、サーバデバイスが第２クライアントデバイスとイマーシブメディアコンテンツを共有することを可能にする。一実施例では、サーバデバイスは、サーバデバイスからの要求に応じて、第１クライアントデバイスから制御プレーンチャネルを介して不変ストレージにキャッシュされるアセットの共有可能なユニフォームリソース識別子（ＵＲＩ）であるタイプのアセットのリストを受信することができる。別の実施例では、サーバデバイスは、サーバデバイスからの要求に応じて、制御プレーンチャネルを介して第１クライアントデバイスからアクセス可能な各アセットのステータス更新を受信することができる。別の実施例では、サーバデバイスは、サーバデバイスからの要求に応じて、特定のアセットタイプの現在の状態、及び第１のクライアントデバイスから制御プレーンチャネルを介して特定のサーバ割り当て識別子及び特定のアセットユニフォームリソース識別子 （ＵＲＩ）のうちのいずれかを受信することができる。サーバデバイスは、サーバデバイスと第２クライアントデバイスとの間の制御プレーンチャネルを介して第２クライアントデバイスに制御メッセージを提供することができ、制御メッセージによって、第２のクライアントデバイスが、キャッシュされたアセットなどの第１クライアントデバイスのイマーシブメディアコンテンツにアクセスできるようにすることができる。

その後、プロセスは（Ｓ２１９９）に進み、終了する。

方法（２１００）は、適切に適合されていることができる。プロセス（２１００）のステップは、修正及び／又は省略することができる。（１つ以上の）追加ステップは、加えられることができる。実施のいかなる適切な順序も、用いられることができる。

図２２は、本開示の一実施形態によるプロセス（２２００）の概略を示すフローチャートを示す。プロセス（２２００）は、クライアントデバイス（２０６０Ａ）、クライアントデバイス（２０６０Ｂ）、クライアントデバイス（２０６０Ｃ）などのクライアントデバイスで使用できる。さまざまな実施形態では、プロセス（２２００）は、処理回路（２０７０Ａ）、処理回路（２０７０Ｂ）、処理回路（２０７０Ｃ）などの処理回路によって実行される。いくつかの実施形態では、プロセス（２２００）はソフトウェア命令で実装されるため、処理回路がソフトウェア命令を実行するとき、処理回路はプロセス（２２００）を実行する。プロセスは（Ｓ２２０１）から始まり、（Ｓ２２１０）に進む。

（Ｓ ２２１０） において、クライアントデバイスは、第１トランスポートプロトコルを使用する制御プレーンチャネル上で、複数の制御メッセージをサーバデバイスと交換する。複数の制御メッセージは、イマーシブメディア配信のための双方向プロトコルの制御プレーンに属する。イマーシブメディア配信のための双方向プロトコルは、一実施例では、オープンシステム相互接続（ＯＳＩ）モデルにおけるアプリケーションレイヤ、プレゼンテーションレイヤなどのトランスポートレイヤの上のネットワークレイヤで実装することができる。

（Ｓ２２２０）において、クライアントデバイスは、サーバデバイスから、第２のトランスポートプロトコルを使用する第１データプレーンチャネル上で、第１の複数のデータメッセージを受信する。第１の複数のデータメッセージは、双方向プロトコルのデータプレーンに属し、少なくともイマーシブなメディアコンテンツを搬送する。

（Ｓ２２３０）において、クライアントデバイスは、第１の複数のデータメッセージによって搬送されるイマーシブなメディアコンテンツを提示することができる。

いくつかの実施例では、第１トランスポートプロトコルは、トランスミッション制御プロトコル（ＴＣＰ）であり、第２トランスポートプロトコルは、ユーザーデータグラムプロトコル（ＵＤＰ）である。

いくつかの実施例では、第１トランスポートプロトコルは、コネクションベースのトランスポートプロトコルであり、双方向であり、第２トランスポートプロトコルは、コネクションレスのトランスポートプロトコルあり、単方向である。

いくつかの実施例では、クライアントデバイスは、制御プレーンチャネルの上で交換される複数の制御メッセージにしたがって、サーバデバイスを有する第１データプレーンチャネルを設定する。

いくつかの実施例では、クライアントデバイスは、制御プレーンチャネル上で、クライアントデバイスの１つ以上の特定の特性をサーバデバイスに提供する。１つ以上の特定の特性は、クライアントデバイスのコンピューティングリソース、クライアントデバイスのストレージリソース、クライアントデバイスでのネットワークサービスプロバイダのサービスレベル契約、イマーシブアプリケーション要件、クライアントデバイスのタイプ、クライアントデバイスのモデル、及びクライアントデバイスでのニューラルネットワークモデルの少なくとも１つを含む。

いくつかの実施例では、クライアントデバイスは、第２トランスポートプロトコルを使用する第２のデータプレーンチャネルを介して、第２の複数のデータメッセージをサーバデバイスに伝送できる。第２の複数のデータメッセージは、クライアントデバイスのニューラルネットワークモデルのレイヤ 情報の少なくとも１つ、又はクライアントデバイスによってレンダリングされたメディアコンテンツを搬送する。

いくつかの実施例では、クライアントデバイスは第１クライアントデバイスであり、複数の制御メッセージは、サーバデバイスが第２クライアントデバイスとイマーシブメディアコンテンツを共有することを可能にする。一実施例では、第１のクライアントデバイスは、サーバデバイスからの要求に応じて、制御プレーンチャネルを介して不変ストレージにキャッシュされるアセットの共有可能なユニフォームリソース識別子（ＵＲＩ）であるアセットの種類のリストを提供する。別の実施例では、第１クライアントデバイスは、サーバデバイスからの要求に応じて、制御プレーンチャネルを介して第１クライアントデバイスからアクセス可能な各アセットのステータス更新を提供する。別の実施例では、第１クライアントデバイスは、サーバデバイスからの要求に応じて、特定のアセットタイプの現在の状態、及び特定のサーバ割り当て識別子と特定のアセットユニフォームリソース識別子 （ＵＲＩ） のいずれかを、制御プレーンチャネルを介して提供する。サーバデバイスは、第１クライアントデバイスから受信した情報を使用して、第２クライアントデバイスを制御し、キャッシュされたアセットなどのイマーシブメディアコンテンツにアクセスできる。

その後、プロセスは（Ｓ２２９９）に進み、終了する。

方法（２２００）は、適切に適合されることができる。プロセス（２２００）の（１つ以上の）ステップは、変更及び／又は省略することができる。（１つ以上の）追加ステップは、加えられることができる。実施のいかなる適切な順序も、用いられることができる。

上記の技術は、コンピュータ可読命令を用いたコンピュータソフトウェアとして行うことができて、物理的に一つ以上のコンピュータ可読媒体に格納されることができる。例えば、図２３は、開示された主題の特定の実施形態を実施するのに適しているコンピュータシステム（２３００）を示す。

コンピュータソフトウェアは、アセンブリ、コンパイル、リンク、又は類似のメカニズムの対象となり得る任意の適切な機械コード若しくはコンピュータ言語を使用してコーディングされることができ、直接実行されることができるか、又は、１つ以上のコンピュータ中央処理装置（ＣＰＵ）、グラフィックス処理装置（ＧＰＵ）等による、実施、マイクロコード実行等を介して実行されることができる命令を含むコードを作成する。

命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲームデバイス、物品のインターネット等を含む種々のタイプのコンピュータ又はその構成要素上で実行されることができる。

コンピュータシステム（２３００）のための図２３に示されるコンポーネントは、例示的な性質のものであり、本開示の実施形態を実装するコンピュータソフトウェアの使用範囲又は機能性に関する制限を示唆することを意図するものではない。また、コンポーネントの構成は、コンピュータシステム（２３００）の例示的な実施形態に示されるコンポーネントのいずれか１つ又は組み合わせに関連する依存性又は要件を有すると解釈されるべきではない。

コンピュータシステム（２３００）は、特定のヒューマンインタフェース入力デバイスを含み得る。このようなヒューマンインタフェース入力デバイスは、例えば、触覚入力（例えば、キーストローク、スイッピング、データグローブの動き）、音声入力（例えば、音声、拍手）、視覚入力（例えば、ジェスチャ）、嗅覚入力（図示せず）を介して、一人又は複数の人間ユーザーによる入力に応答し得る。また、ヒューマンインタフェースデバイスは、オーディオ（例えば、音声、音楽、周囲の音声）、画像（例えば、走査画像、静止画像カメラから得られる写真画像）、ビデオ（例えば、２次元ビデオ、立体画像を含む３次元ビデオ）等の、人間による意識的入力に必ずしも直接関係しない特定の媒体を捕捉するために用いられ得る。

入力ヒューマンインタフェースデバイスは、キーボード（２３０１）、マウス（２３０２）、トラックパッド（２３０３）、タッチスクリーン（２３１０）、データグローブ（図示せず）、ジョイスティック（２３０５）、マイクロホン（２３０６）、スキャナ（２３０７）、カメラ（２３０８）の１つ以上を含み得る。

コンピュータシステム（２３００）はまた、特定のヒューマンインタフェース出力デバイスを含み得る。かかるヒューマンインタフェース出力デバイスは、例えば、触覚出力、音、光、及び嗅覚／味覚を通して、１人又は複数の人間ユーザーの感覚を刺激し得る。かかるヒューマンインタフェース出力デバイスは、触覚出力デバイス（例えば、タッチスクリーン（２３１０）、データグローブ（図示せず）、又はジョイスティック（２３０５）による触覚フィードバックであることもできるが、入力デバイスとして働かない触覚フィードバックデバイスであることもできる）と、オーディオ出力デバイス（例えば、スピーカー（２３０９）、ヘッドフォン（図示せず））と、視覚出力デバイス（例えば、ＣＲＴスクリーン、ＬＣＤスクリーン、プラズマスクリーン、ＯＬＥＤスクリーンを含むスクリーン（２３１０）であり、各々が触覚フィードバック能力を有するか又は有さず、各々が触覚フィードバック能力を有するか又は有さず、そのうちのいくつかは、仮想現実眼鏡（図示せず）、ホログラフィックディスプレイ及びスモークタンク（図示せず）等の立体出力のような手段を介して２次元視出力又は３次元以上の出力を可能にし得るものと、プリンタ（図示せず）と、を含み得る。

コンピュータシステム（２３００）はまた、人間がアクセス可能な記憶デバイスと、それらのアクセス可能な媒体とを含むことができ、媒体は、例えば、ＣＤ／ＤＶＤ等の媒体（２３２１）によるＣＤ／ＤＶＤ ＲＯＭ／ＲＷを含む光学媒体ドライブ（２３２０）、ＵＳＢメモリ（２３２２）、着脱可能ヘッドドライブ又はソリッドステートドライブ（２３２３）、テープ、フロッピーディスク（図示せず）等の従来の磁気媒体、セキュリティドングル等の特殊化されたＲＯＭ／ＡＳＩＣ／ＰＬＤベースデバイス等である。

当業者はまた、現在開示されている主題に関連して使用される「コンピュータ可読媒体」という用語は、伝送媒体、搬送波、又は他の一時的な信号を包含しないことを理解されたい。

コンピュータシステム（２３００）はまた、１つ以上の通信ネットワーク（２３５５）へのインタフェース（２３５４）を含むことができる。ネットワークは、例えば、無線、有線、光であり得る。ネットワークは、さらに、ローカル、広域、大都市、車両及び工業、リアルタイム、遅延耐性等であり得る。ネットワークの例としては、イーサネット、無線ＬＡＮ、ＧＳＭ、３Ｇ、４Ｇ、５Ｇ、ＬＴＥ等を含むセルラーネットワーク、ケーブルＴＶ、衛星ＴＶ、及び地上放送ＴＶ、ＣＡＮＢｕｓを含む産業用及び車両用を含む。特定のネットワークは、一般に、特定の汎用データポート又はペリフェラルバス（２３４９）（たとえば、コンピュータシステム（２３００）のＵＳＢポート）に接続された外部ネットワークインターフェイスアダプタを必要とする；他には、一般に、以下に説明するようにシステムバス（たとえば、ＰＣコンピュータシステムへのイーサネットインターフェイス又はスマートフォンコンピュータシステムへのセルラーネットワークインタフェース）に接続することによってコンピュータシステム（２３００）のコアに統合される。これらのネットワークのいずれかを使用して、コンピュータシステム（２３００）は、他のエンティティと通信することができる。かかる通信は、単指向性通信、受信のみ（例えば、放送テレビ）通信、単指向性送信専用（例えば、特定のＣＡＮバスデバイスへのＣＡＮバス）通信、又は、例えばローカル又は広域デジタルネットワークを使用する他のコンピュータシステムへの、双方向通信であることができる。特定のプロトコル及びプロトコルスタックは、上述のように、それらのネットワーク及びネットワークインタフェースの各々で使用されることができる。

前述のヒューマンインタフェースデバイス、人間がアクセス可能な記憶デバイス、及びネットワークインタフェースは、コンピュータシステム（２３００）のコア（２３４０）に接続されることができる。

コア（２３４０）は、１つ以上の中央処理デバイス（ＣＰＵ）（２３４１）、グラフィックス処理デバイス（ＧＰＵ）（２３４２）、フィールドプログラマブルゲートエリア（ＦＰＧＡ）（２３４３）の形態の特殊なプログラマブル処理デバイス、特定のタスクのためのハードウェアアクセラレータ（２３４４）、グラフィックアダプタ（２３５０）等を含むことができる。これらのデバイスは、読出し専用メモリ（ＲＯＭ）２３４５）、ランダムアクセスメモリ（２３４６）、内部大容量記憶デバイス、例えば内部非ユーザーアクセス可能ハードドライブ、ＳＳＤ等（２３４７）と共に、システムバス（２３４８）を介して接続され得る。いくつかのコンピュータシステムでは、システムバス（２３４８）は、追加のＣＰＵ、ＧＰＵ等による拡張を可能にするために、１つ又は複数の物理プラグの形態でアクセス可能である。周辺デバイスは、コアのシステムバス（２３４８）に直接接続するか、又は周辺バス（２３４９）を介して接続することができる。実施例において、スクリーン（２３１０）は、グラフィックスアダプタ（２３５０）に接続されることができる。周辺バスのアーキテクチャは、ＰＣＩ、ＵＳＢ等を含む。

ＣＰＵ（２３４１）、ＧＰＵ（２３４２）、ＦＰＧＡ（２３４３）、及びアクセラレータ（２３４４）は、組み合わされて、上述のコンピュータコードを構成することができる特定の命令を実行することができる。そのコンピュータコードは、ＲＯＭ（２３４５）又はＲＡＭ（２３４６）に格納されることができる。移行データは、ＲＡＭ（２３４６）に格納されることもできるが、永久データは例えば内部大容量記憶デバイス（２３４７）に格納されことができる。１つ以上のＣＰＵ（２３４１）、ＧＰＵ（２３４２）、大容量記憶デバイス（２３４７）、ＲＯＭ（２３４５）、ＲＡＭ（２３４６）等と密接に関連付けることができるキャッシュメモリを使用することによって、メモリデバイスのいずれかへの高速記憶及び検索を可能にすることができる。

コンピュータ可読媒体は、各種のコンピュータ実施動作（ｃｏｍｐｕｔｅｒ－ｉｍｐｌｅｍｅｎｔｅｄ ｏｐｅｒａｔｉｏｎｓ）を実行するためにその上のコンピュータコードを有することができる。メディア及びコンピュータコードは特別に設計されたそれらであることができて、本開示のために作成されることができる、又は、それらはよく公知で、コンピュータソフトウェア技術の技術を有するそれらが利用できる種類でありえる。

一例として、限定するものではなく、アーキテクチャ（２３００）、具体的にはコア（２３４０）を有するコンピュータシステムは、１つ以上の有形のコンピュータ可読媒体に具現化されたソフトウェアを実行するプロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡ、アクセラレータ等を含む）の結果として機能性を提供することができる。かかるコンピュータ可読媒体は、コア－内部大容量記憶デバイス（２３４７）又はＲＯＭ（２３４５）等の一時的でない性質のコア（２３４０）の特定の記憶デバイスと同様に、上述のようにユーザーがアクセス可能な大容量記憶デバイスに関連する媒体であってもよい。本開示の様々な実施形態を実装するソフトウェアは、かかるデバイスに記憶され、コア（２３４０）によって実行され得る。コンピュータ読取可能媒体は、特定のニーズに応じて、１つ以上のメモリデバイス又はチップを含むことができる。ソフトウェアは、コア（２３４０）及びその中の具体的にプロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡ等を含む）に、ＲＡＭ（２３４６）に記憶されたデータ構造を定義し、ソフトウェアによって定義されたプロセスにしたがって、かかるデータ構造を変更することを含む、本明細書に記載された特定のプロセス又は特定の部分を実行させることができる。付加的に又は代替的に、コンピュータシステムは、回路（例えば、アクセラレータ（２３４４））内に配線された、又は他の方法で具現化されたロジックの結果として、機能性を提供することができ、これは、本明細書に記載される特定のプロセス又は特定のプロセスの特定の部分を実行するために、ソフトウェアの代わりに、又はソフトウェアと共に動作することができる。ソフトウェアへの言及は、論理を含み、また、必要に応じて、その逆も可能である。コンピュータ読取り可能媒体への参照は、実行のためのソフトウェアを記憶する（集積回路（ＩＣ）等の）回路、実行のためのロジックを具体化する回路、又は適切な場合にはその両方を含むことができる。
本開示は、ハードウェア及びソフトウェアの任意の適切な組み合わせを包含する。

本開示はいくつかの例示的な実施形態を説明しているが、本発明の範囲内に入る、変更、置換、及び様々な均等物が存在する。したがって、当業者は、本明細書に明示的に示されていないか又は記載されていないが、本発明の原理を実施し、したがってその概念及び範囲内にある多数のシステム及び方法を創造することができることが理解されよう。

Claims (12)

1. クライアントデバイスでのメディアストリーミングの方法であって、
   第１トランスポートプロトコルを使用する制御プレーンチャネルの上で、サーバデバイスと、複数の制御メッセージを交換するステップであって、前記複数の制御メッセージは、イマーシブメディア配信のための双方向プロトコルの制御プレーンに属する、ステップと、
   前記サーバデバイスから、第２トランスポートプロトコルを使用する第１データプレーンチャネルの上で、第１の複数のデータメッセージを受信するステップであって、前記第１の複数のデータメッセージは、前記双方向プロトコルのデータプレーンに属する、ステップと、
   前記第１の複数のデータメッセージによって搬送されるイマーシブメディアコンテンツを提示するステップと、
   を含む、方法。
2. 前記第１トランスポートプロトコルは、トランスミッション制御プロトコル（ＴＣＰ）であり、前記第２トランスポートプロトコルは、ユーザーデータグラムプロトコル（ＵＤＰ）である、
   請求項１記載の方法。
3. 前記第１トランスポートプロトコルは、コネクションベースのトランスポートプロトコルであり、前記第２トランスポートプロトコルは、コネクションレスのトランスポートプロトコルである、
   請求項１記載の方法。
4. 前記方法はさらに、
   前記制御プレーンチャネルの上で交換される前記複数の制御メッセージにしたがって、前記サーバデバイスを有する前記第１データプレーンチャネルを設定するステップ、を含む、
   請求項１記載の方法。
5. 前記方法はさらに、
   前記クライアントデバイスの１つ以上の特定の特性を、前記制御プレーンチャネルの上で前記サーバデバイスに提供するステップであって、
   前記１つ以上の特定の特性は：
   前記クライアントデバイスの計算リソース；
   前記クライアントデバイスのストレージリソース；
   前記クライアントデバイスでのネットワークサービスプロバイダのサービスレベルの契約；
   イマーシブアプリケーション要件；
   前記クライアントデバイスの種類；
   前記クライアントデバイスのモデル；
   前記クライアントデバイスのニューラルネットワークモデル；
   のうちの少なくとも１つを含む、ステップを含む、
   請求項１記載の方法。
6. 前記方法はさらに、
   前記第２トランスポートプロトコルを使用する第２データプレーンチャネルの上で、第２の複数のデータメッセージを前記サーバデバイスに送信するステップであって、
   前記第２の複数のデータメッセージは：
   前記クライアントデバイスにおけるニューラルネットワークモデルのレイヤ情報；
   前記クライアントデバイスによってレンダリングされたメディアコンテンツ；
   のうちの少なくとも１つを搬送する、ステップを含む、
   請求項１記載の方法。
7. 前記クライアントデバイスは第１クライアントデバイスであり、
   前記複数の制御メッセージは、前記サーバデバイスが第２クライアントデバイスと前記イマーシブメディアコンテンツを共有できるようにする、
   請求項１記載の方法。
8. 前記複数の制御メッセージを交換するステップは、
   サーバデバイスからの要求に応じて、前記制御プレーンチャネルを介して、不変のストレージにキャッシュされたアセットのユニフォームリソース識別子（ＵＲＩ）と、共有可能なアセットの種類とのリストを提供するステップを含む、
   請求項７記載の方法。
9. 前記複数の制御メッセージを交換するステップは、前記サーバデバイスからの要求に応じて、前記制御プレーンチャネルを介して、前記第１クライアントデバイスによってアクセス可能である各アセットのステータスアップデートを提供するステップと含む、
   請求項７記載の方法。
10. 前記複数の制御メッセージを交換するステップは、前記サーバデバイスからの要求に応じて、制御プレーンチャネルを介して、特定のアセットタイプの現在ステータスと、特定のサーバ割り当て識別子及び特定のアセットユニフォームリソース識別子（ＵＲＩ）のうちの１つと、を提供するステップを含む、
    請求項７記載の方法。
11. サーバでのメディアストリーミングの方法であって、
    第１トランスポートプロトコルを使用する制御プレーンチャネルの上で、クライアントデバイスと、複数の制御メッセージを交換するステップであって、前記複数の制御メッセージは、イマーシブメディア配信のための双方向プロトコルの制御プレーンに属する、ステップと、
    前記クライアントデバイスに、第２トランスポートプロトコルを使用する第１データプレーンチャネルの上で、第１の複数のデータメッセージを送信するステップであって、前記第１の複数のデータメッセージは、前記双方向プロトコルのデータプレーンに属する、ステップと、
    を含む、方法。
12. メディアストリーミングのための装置であって、
    請求項１乃至１１いずれか１項記載の方法を実行するように構成された処理回路を備える、
    装置。

Images