JP2023544049A - 双方向プレゼンテーションデータストリーム - Google Patents

Abstract

本開示の態様は、メディア処理のための方法および装置を提供する。いくつかの例では、装置は処理回路を備える。処理回路は、サーバデバイスと、没入型メディアのための双方向プロトコルに従って、サーバデバイスが装置の1つまたは複数の特定の特性を受信することを保証する第1の複数のメッセージを交換する。処理回路は、サーバデバイスから、没入型メディアのための双方向プロトコルに従って、メディアコンテンツを搬送するメディアストリームを受信する。メディアストリームは没入型コンテンツを含み、装置の1つまたは複数の特定の特性に従って適合される。処理回路は、メディアストリームからのメディアコンテンツを提示する。

Description

関連出願の相互参照
本出願は、2022年6月28日に出願された米国特許出願第17／851，904号「BIDIRECTIONAL PRESENTATION DATASTREAM」の優先権の利益を主張し、上記出願は、2021年6月30日に出願された米国仮出願第63／217，038号「INTELLIGENT BIDIRECTIONAL PRESENTATION DATASTREAM」に基づく優先権の利益を主張する。先行出願の開示は、それらの全体が参照により本明細書に組み込まれる。

本開示は、概してメディア処理および配信に関する実施形態を説明する。

本明細書において提供される背景技術の説明は、本開示の文脈を大まかに提示することを目的としている。ここに記された発明者の仕事は、その仕事がこの背景技術の欄に記載されている限りにおいて、ならびにさもなければ出願時に従来技術として適格ではない可能性がある説明の態様は、明示的にも黙示的にも本開示に対する従来技術として認められるものではない。

没入型メディアは、一般に、タイムド2次元（2D）ビデオおよび「レガシーメディア」として知られている対応するオーディオのために既存の商用ネットワークを介して配信されるものを超えるなど、任意のまたはすべての人間の感覚系（視覚、聴覚、体性感覚、嗅覚、および場合によっては味覚）を刺激して、メディアの体験に物理的に存在するユーザの知覚を作成または強化するメディアを指す。没入型メディアとレガシーメディアの両方は、タイムドメディアまたは非タイムドメディアのいずれかとして特徴付けられ得る。

タイムドメディアは、時間に従って構造化され提示されるメディアを指す。例としては、映画の特集、ニュース報道、エピソードコンテンツが挙げられ、これらはすべて、期間に従って編成される。従来のビデオおよびオーディオは、一般にタイムドメディアであると考えられている。

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

没入型メディア対応デバイスは、没入型メディアにアクセス、解釈、および提示する能力を備えたデバイスを指しうる。そのようなメディアおよびデバイスは、メディアの数およびフォーマット、ならびにそのようなメディアを大規模に配信するために、すなわち、ネットワークを介してレガシービデオおよびオーディオメディアと同等の配信を達成するために必要なネットワークリソースの数およびタイプに関して異種である。対照的に、ラップトップディスプレイ、テレビ、およびモバイルハンドセットディスプレイなどのレガシーデバイスは、これらのデバイスのすべてが長方形のディスプレイスクリーンで構成され、それらのプライマリメディアフォーマットとして2D長方形のビデオまたは静止画像を消費するため、それらの能力において同種である。

本開示の態様は、メディア処理のための方法および装置を提供する。いくつかの例では、装置は処理回路を備える。処理回路は、サーバデバイスと、没入型メディアのための双方向プロトコルを使用して、サーバデバイスが装置の1つまたは複数の特定の特性を受信することを保証する第1の複数のメッセージを交換する。処理回路は、サーバデバイスから、没入型メディアのための双方向プロトコルを使用して、メディアコンテンツを搬送するメディアストリームを受信する。メディアストリームは没入型コンテンツを含み、装置の1つまたは複数の特定の特性に従って適合される。処理回路は、メディアストリームからメディアコンテンツを提示する。

いくつかの例では、1つまたは複数の特定の特性は、クライアントデバイスのコンピューティングリソースと、クライアントデバイスのストレージリソースと、クライアントデバイスにおけるネットワークサービスプロバイダのサービスレベルアグリーメントと、没入型アプリケーション要件と、クライアントデバイスのタイプと、クライアントデバイスのモデルと、クライアントデバイスにおけるニューラルネットワークモデルと、のうちの少なくとも1つを含む。

一実施形態では、処理回路は、装置の1つまたは複数の特定の特性をサーバデバイスに通知するための第1のメッセージを送信し、サーバデバイスの確認応答のための第2のメッセージを受信する。

他の実施形態では、処理回路は、装置の1つまたは複数の特定の特性を提供することを求める要求の第1のメッセージを受信し、装置の1つまたは複数の特定の特性をサーバデバイスに通知するために第2のメッセージを送信する。

一例では、処理回路は、サーバデバイスから装置への要求に応じてメディアストリームを受信する。他の例では、処理回路は、装置からサーバデバイスへの要求に応じてメディアストリームを受信する。

本開示の一態様によれば、装置は第1のクライアントデバイスであり、処理回路は、没入型メディアのための双方向プロトコルを使用して、サーバデバイスが第2のクライアントデバイスとメディアコンテンツを共有することを可能にする第2の複数のメッセージをサーバデバイスと交換する。一例では、処理回路は、サーバデバイスからの要求に応じて、共有可能なアセットのタイプのリストと、不変ストレージにキャッシュされているアセットの統一リソース識別子（URI）と、を提供する。他の例では、処理回路は、サーバデバイスからの要求に応じて、第1のクライアントデバイスによってアクセス可能な各アセットのステータス更新を提供する。他の例では、処理回路は、サーバデバイスからの要求に応じて、特定のアセットタイプの現在の状態と、特定のサーバ割り当て識別子および特定のアセットの統一リソース識別子（URI）のうちの一方と、を提供する。

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

本開示の主題のさらなる特徴、性質、および様々な利点は、以下の詳細な説明、および添付の図面でより明らかになるであろう。

一例におけるタイムドメディア配信のエンドツーエンドプロセスの図である。 一例におけるタイムドメディアのストリーミングに使用される標準メディアフォーマットの図である。 いくつかの例におけるタイムド没入型メディアの表現およびストリーミングのデータモデルの図である。 いくつかの例における非タイムド没入型メディアの表現およびストリーミングのデータモデルの図である。 いくつかの例における、自然なシーンをキャプチャし、異種クライアントエンドポイントにサービスを提供するネットワークのインジェストフォーマットとして使用され得る表現に変換するプロセスの図である。 いくつかの例における、異種クライアントエンドポイントにサービスを提供するネットワークのインジェストフォーマットとして使用され得る合成シーンの表現を作成するために3次元（3D）モデリングツールおよびフォーマットを使用するプロセスの図である。 いくつかの例における複数の異種クライアントエンドポイントにサービスを提供するネットワークの図である。 いくつかの例における特定の没入型メディアクライアントエンドポイントによる消費のためにメディアを適合させるネットワークのプロセスの前に、メディアインジェストフォーマットで表現される特定のメディアに関するアダプテーション情報を提供するネットワークの図である。 いくつかの例における、ソースメディアをインジェストフォーマットから特定のクライアントエンドポイントに適した特定のフォーマットに変換するメディアレンダコンバータを含むメディアアダプテーションプロセスのシステム図である。 いくつかの例における、適合されたソースメディアを表現およびストリーミングに適したデータモデルにフォーマッティングするネットワークの図である。 いくつかの例における、図11のデータモデルをネットワークプロトコルパケットのペイロードに断片化するメディアストリーミングプロセスのシステム図である。 いくつかの例における、インジェストフォーマットの特定の没入型メディアを特定の没入型メディアクライアントエンドポイントのためのストリーミング可能で適切な配信フォーマットに適合させるネットワークのシーケンス図である。 いくつかの例におけるインジェストメディアフォーマットの図である。 いくつかの例における符号化ビデオストリームと共にニューラルネットワークモデル情報のキャリッジを示す図である。 いくつかの例における入力没入型メディアおよびアセットと共にニューラルネットワークモデル情報のキャリッジを示す図である。 いくつかの例における、没入型メディア配信のための双方向プロトコルを使用してサーバ側からクライアント側に送信されるメッセージを示す図である。 いくつかの例における、没入型メディア配信のための双方向プロトコルを使用してサーバ側からクライアント側に送信されるメッセージを示す図である。 いくつかの例における、没入型メディア配信のための双方向プロトコルを使用してクライアント側からサーバ側に送信されるメッセージを示す図である。 いくつかの例におけるサーバ側からクライアント側に送信されるメッセージの定義を示す図である。 いくつかの例におけるサーバ側からクライアント側に送信されるメッセージの定義を示す図である。 いくつかの例におけるサーバ側からクライアント側に送信されるメッセージの定義を示す図である。 いくつかの例におけるサーバ側からクライアント側に送信されるメッセージの定義を示す図である。 いくつかの例におけるサーバ側からクライアント側に送信されるメッセージの定義を示す図である。 いくつかの例におけるサーバ側からクライアント側に送信されるメッセージの定義を示す図である。 いくつかの例におけるサーバ側からクライアント側に送信されるメッセージの定義を示す図である。 いくつかの例におけるクライアント側からサーバ側に送信されるメッセージの定義を示す図である。 いくつかの例における没入型メディアの配信のための双方向プロトコルを使用するメディアシステムを示す図である。 本開示のいくつかの実施形態によるプロセスの概要を示すフローチャートを示す図である。 本開示のいくつかの実施形態による他のプロセスの概要を示すフローチャートを示す図である。 一実施形態によるコンピュータシステムの概略図である。

本開示の態様は、双方向提示データストリームのための技術を提供する。本開示は、ビデオ、オーディオ、幾何学的（3D）オブジェクト、触覚、関連するメタデータ、またはクライアント提示デバイスのための他のコンテンツを含む、メディアを配信するシステムおよびネットワークのためのアーキテクチャ、構造、および構成要素に関する実施形態を説明する。いくつかの実施形態は、異種没入型およびインタラクティブなクライアント提示デバイスへのメディアコンテンツの配信のためのシステム、構造、およびアーキテクチャに関する。

没入型メディアは、一般に、任意のまたはすべての人間の感覚系（視覚、聴覚、体性感覚、嗅覚、および場合によっては味覚）を刺激して、メディアの体験に物理的に存在するユーザの知覚を作成または強化する、すなわち、タイムド2次元（2D）ビデオおよび「レガシーメディア」として知られている対応するオーディオのために既存の商用ネットワークを介して配信されるものを超えるメディアを指す。没入型メディアとレガシーメディアの両方は、タイムドメディアまたは非タイムドメディアのいずれかとして特徴付けられ得る。

タイムドメディアは、時間に従って構造化され提示されるメディアを指す。例としては、映画の特集、ニュース報道、エピソードコンテンツが挙げられ、これらはすべて、期間に従って編成される。従来のビデオおよびオーディオは、一般にタイムドメディアであると考えられている。

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

没入型メディア対応デバイスは、没入型メディアにアクセス、解釈、および提示する能力を備えたデバイスを指すことができる。そのようなメディアおよびデバイスは、メディアの数およびフォーマット、ならびにそのようなメディアを大規模に配信するために、すなわち、ネットワークを介してレガシービデオおよびオーディオメディアと同等の配信を達成するために必要なネットワークリソースの数およびタイプに関して異種である。対照的に、ラップトップディスプレイ、テレビ、およびモバイルハンドセットディスプレイなどのレガシーデバイスは、これらのデバイスのすべてが長方形のディスプレイスクリーンで構成され、それらのプライマリメディアフォーマットとして2D長方形のビデオまたは静止画像を消費するため、それらの能力において同種である。同様に、レガシーデバイスでサポートされるオーディオフォーマットの数は、比較的少ないセットに制限される。

ネットワークを介した任意のメディアの配信は、入力またはネットワークインジェストフォーマットから最終的な配信フォーマットにメディアを再フォーマットするメディア配信システムおよびアーキテクチャを採用することができ、その配信フォーマットは、ターゲットのクライアントデバイスおよびそのアプリケーションに適しているだけでなく、ネットワークを介してストリーミングされるのにも役立つ。メディアのストリーミングとは、メディアの時間的または空間的構造のいずれかまたは両方に従って論理的に編成および配列された連続したより小さいサイズの「チャンク」でネットワークを介してメディアが配信され得るように、ソースメディアの断片化およびパケット化を広く指す。そのような配信アーキテクチャおよびシステムでは、最も顕著なメディア情報のみが最初にクライアントに配信されるように、メディアは圧縮または階層化プロセスを受けることができる。場合によっては、クライアントは、クライアントがエンドユーザに同じメディア部分のいずれかを提示することができる前に、メディアの一部についての顕著なメディア情報のすべてを受信する。

対象クライアントのエンドポイントの能力に一致するように入力メディアを再フォーマットするプロセスは、再フォーマットされる特定のメディアのいくつかの事前知識をカプセル化することができるネットワークモデルをとるニューラルネットワークプロセスを採用することができる。例えば、特定のモデルは、屋外の公園のシーン（樹木、植物、草、および公園の景色に共通の他のオブジェクト）を認識するように調整されてもよいが、異なる特定のモデルは、屋内の夕食のシーン（夕食のテーブル、配膳器具、テーブルに座っている人など）を認識するように調整されてもよい。いくつかの例では、ネットワークモデルは、特定のコンテキストからのオブジェクト、例えば公園の風景オブジェクトを認識するように調整され得、特定のシーンの内容に一致するように調整されたネットワークモデルを備えたニューラルネットワークプロセスは、そのように調整されていないネットワークモデルよりも良好な視覚的結果を生成することができる。したがって、ターゲットクライアントのエンドポイントの能力に一致するように入力メディアを再フォーマットすることを担当するニューラルネットワークプロセスにシーン固有のネットワークモデルを提供する利点がある。

ニューラルネットワークモデルを2次元（2D）メディアのための特定のシーンに関連付けるためのメカニズムは、例えば、ネットワークモデルを圧縮し、例えば、H．264、H．265、およびH．266ビデオ圧縮フォーマットにおいて、符号化されたビデオストリームにメタデータを付加するために一般的に使用される補足拡張情報（SEI）構造化フィールドによって、ビジュアルシーンのための2D符号化ビットストリームに圧縮されたネットワークモデルを直接挿入することによって達成されてもよい。符号化ビデオビットストリームの一部のコンテキスト内の特定のニューラルネットワークモデルを含むSEIメッセージの存在は、ネットワークモデルが、モデルが埋め込まれているビットストリームの一部内のビデオコンテンツを解釈および適合するために使用されるべきであることを示すために使用されてもよい。いくつかの例では、ネットワークモデルの識別子によって、実際のモデル自体がない場合にどのニューラルネットワークモデルを使用され得るかをシグナリングするために、SEIメッセージが使用されてもよい。

没入型メディアに適切なニューラルネットワークを関連付ける機構は、没入型メディア自体が使用する適切なニューラルネットワークモデルを参照することによって達成されてもよい。この参照は、オブジェクトごとに、またはシーンごとに、またはそれらの何らかの組合せによって、ネットワークモデルおよびそのパラメータをオブジェクトに直接埋め込むことによって達成されてもよい。いくつかの例では、メディア内に1つまたは複数のニューラルネットワークモデルを埋め込むのではなく、メディアオブジェクトまたはシーンは、識別子によって特定のニューラルネットワークモデルを参照することができる。

いくつかの他の例では、クライアントのエンドポイントへのストリーミングのためのメディアのアダプテーションのために適切なニューラルネットワークを参照する機構は、特定のクライアントのエンドポイント自体が、使用するアダプテーションプロセスに少なくとも1つのニューラルネットワークモデルおよび対応するパラメータを提供するためのものである。そのような機構は、例えばクライアントがネットワークに自身を接続するときに、アダプテーションプロセスとの通信においてニューラルネットワークモデルを提供するクライアントによって実装されてもよい。

ビデオのターゲットクライアント端点へのアダプテーションに続いて、ネットワーク内のアダプテーションプロセスは、結果に圧縮アルゴリズムを適用することを選択することができる。さらに、圧縮アルゴリズムは、いくつかの例では、適合されたビデオ信号を、ビジュアル信号の最も顕著な部分から最も顕著でない部分に対応する層に分離することができる。

いくつかの例では、JPEG標準規格（ISO／IEC 10918 Part 1）のプログレッシブ形式などの圧縮および階層化プロセスは、最初に焦点が合っていない、すなわち画像スキャン全体の低次DCT係数からの基本形状および色のみで画像全体を最初に提示させる層に画像を分離することができ、その後に、画像に焦点を合わせる、すなわち画像スキャンの高次DCT係数からの詳細の追加の層が続く。

メディアをより小さい部分に分割し、それらを連続したネットワークプロトコルパケットのペイロード部分に編成し、これらのプロトコルパケットを配信するプロセスは、メディアのストリーミングと称され、一方、メディアを、様々な異種アプリケーションのうちの1つを動作させている様々な異種クライアントエンドポイントのうちの1つでの提示に適したフォーマットに変換するプロセスは、メディアの適合と称される。

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

シーングラフ：ベクトルベースのグラフィックス編集アプリケーションおよび最新のコンピュータゲームによって通常使用される一般的なデータ構造であって、グラフィックシーンの論理的かつ多くの場合（必ずしもそうとは限らないが）空間的な表現を配置する。グラフ構造におけるノードおよび頂点の集合。

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

ベース層：通常、アセットをレンダリングするのに必要な計算リソースもしくは時間、またはネットワークを介してアセットを送信する時間を最小限に抑えるように定式化された、アセットの公称表現。

強化層：アセットのベース層表現に適用される場合に、ベース層でサポートされていない機能または能力を含むようにベース層を拡張する情報のセット。

属性：基準形式またはより複雑な形式（例えば、他のノードに関して）のいずれかでそのノードの特定の特性または特徴を記述するために使用されるノードに関連付けられたメタデータ。

コンテナ：シーングラフおよびシーンのレンダリングに必要なすべてのメディアリソースを含むすべての自然シーン、すべての合成シーン、または合成シーンと自然シーンとの組合せを表すための情報を記憶し、交換するための直列化フォーマット。

シリアライゼーション：データ構造またはオブジェクト状態を、記憶（例えば、ファイルバッファまたはメモリバッファ）され、または送信（例えば、ネットワーク接続リンクを介して）され、後で（場合によっては異なるコンピュータ環境で）再構築され得るフォーマットに変換するプロセス。結果として得られた一連のビットが直列化フォーマットに従って再読み取りされると、元のオブジェクトの意味的に同一のクローンを作成するためにそれが使用され得る。

レンダラ：音響物理学、光物理学、視覚的知覚、聴覚的知覚、数学およびソフトウェア開発に関連する分野の選択的な組合せに基づく（通常はソフトウェアベースの）アプリケーションまたはプロセスであり、入力シーングラフおよびアセットコンテナが与えられると、対象デバイス上でのプレゼンテーションに適した、またはシーングラフ内のレンダリング対象ノードの属性によって指定される所望の特性に従った、典型的なビジュアル信号および／またはオーディオ信号を発する。ビジュアルベースのメディアアセットの場合、レンダラは、対象ディスプレイに適した、または（例えば、他のコンテナに再パッケージ化され、すなわちグラフィックパイプラインの一連のレンダリングプロセスで使用される）中間アセットとしての記憶に適したビジュアル信号を発してもよく、オーディオベースのメディアアセットの場合、レンダラは、マルチチャネルラウドスピーカおよび／またはバイノーラル化されたヘッドホンでのプレゼンテーションのために、または他の（出力）コンテナに再パッケージ化するために、オーディオ信号を発してもよい。レンダラの一般的な例には、Unity、Unrealが含まれる。

評価：出力を要約から具体的な結果に移動させる結果（例えば、ウェブページのためのドキュメントオブジェクトモデルの評価と同様）を生成する。

スクリプト言語：空間および時間オブジェクトトポロジ（物理的な力、制約、IK、変形、衝突を含む）、ならびにエネルギー伝搬および伝送（光、音）のレンダリングおよび評価に影響を及ぼす、シーングラフノードに対して行われる動的入力および可変状態変更を処理するために、実行時にレンダラによって実行され得る解釈されたプログラミング言語。

シェーダ：シェーディング（画像内の適切なレベルの光、暗さおよび色の生成）に元々使用されていたが、現在はコンピュータグラフィックス特殊効果の様々な分野で様々な特殊な機能を行うか、シェーディングとは無関係のビデオ後処理を行うか、またはグラフィックスとはまったく無関係の機能さえ行うコンピュータプログラムのタイプ。

経路追跡：シーンの照明が現実に忠実になるように3次元シーンをレンダリングするコンピュータグラフィックス方法。

タイムドメディア：時間によって順序付けられるメディアであって、例えば、特定のクロックに従った開始時間および終了時間を含む。

非タイムドメディア：例えば、ユーザが行った動作に従って実現される対話型体験のように、空間的、論理的または時間的な関係によって編成されたメディアである。

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

本開示のいくつかの態様によれば、没入型メディアは、没入型メディア対応デバイスによって人間に提示されると、より現実的であり、自然世界内の経験の人間の理解と一致する方法で、視覚、音、味覚、触覚、および聴覚の五感のいずれかを刺激する、すなわち、そうでなければレガシーデバイスによって提示されるレガシーメディアによって達成されたであろう刺激を超える刺激である、1つまたは複数のタイプのメディアとみなすことができる。これに関連して、レガシーメディアという用語は、静止画または動画のいずれかの2次元（2D）ビジュアルメディア、および／または対話するユーザの能力が一時停止、再生、早送り、または巻き戻しに限定される対応するオーディオを指し、レガシーデバイスは、その能力がレガシーメディアのみの提示に制約されているテレビ、ラップトップ、ディスプレイ、およびモバイルデバイスを指すことができる。

いくつかの消費者向けアプリケーションシナリオでは、没入型メディア（すなわち、没入型メディア対応デバイス）用の提示デバイスは、没入型メディアによって具現化される特定の情報を活用する能力を特に備えた消費者向けハードウェアデバイスであり、それにより、デバイスは、物理世界の人間の理解および物理世界との相互作用をより密接に近似する、すなわちそうするためのレガシーデバイスの能力を超える提示を作成することができる。レガシーデバイスは、レガシーメディアのみを提示する能力に制約があるが、没入型メディアデバイスは同様に制約されない。

過去10年間に、ヘッドマウントディスプレイ、拡張現実メガネ、ハンドヘルドコントローラ、触覚グローブ、およびゲーム機を含む多くの没入型メディア対応デバイスが消費者市場に導入されてきた。同様に、ホログラフィックディスプレイおよび他の形態の立体ディスプレイは、今後10年以内に出現する可能性がある。これらのデバイスの即時または差し迫った利用可能性にもかかわらず、商用ネットワークを介した没入型メディアの配信のためのコヒーレントなエンドツーエンドのエコシステムは、いくつかの理由で実現されていない。

それらの理由の1つは、商用ネットワークを介した大規模なメディアの現在の配信に対する2つの主要なユースケース、すなわち、1）ライブアクションイベントのリアルタイム配信、すなわち、コンテンツが作成されてリアルタイムまたはほぼリアルタイムでクライアントのエンドポイントに配信される場合、および2）非リアルタイム配信、すなわち、コンテンツが物理的にキャプチャまたは作成されているときにリアルタイムでコンテンツを配信する必要がない場合に対処することができる没入型メディアの単一の標準的表現の欠如である。それぞれ、これら2つのユースケースは、今日存在するような放送およびオンデマンドの配信フォーマットと比較可能に比較されてもよい。

リアルタイム配信のために、コンテンツは、1つまたは複数のカメラによってキャプチャされ得るか、またはコンピュータ生成技術を使用して作成され得る。いくつかの例では、カメラによってキャプチャされたコンテンツは、本明細書では自然コンテンツと称され、コンピュータ生成技術を使用して作成されたコンテンツは、本明細書では合成コンテンツと称される。合成コンテンツを表現するためのメディアフォーマットは、3Dモデリング、ビジュアル効果、およびCAD／CAM産業で使用されるフォーマットとすることができ、メッシュ、テクスチャ、点群、構造化ボリューム、非晶質ボリューム（例えば、火、煙、および霧の場合）、シェーダ、手続き的に生成されたジオメトリ、材料、照明、仮想カメラ定義、およびアニメーションなどのオブジェクトフォーマットおよびツールを含むことができる。合成コンテンツはコンピュータで生成されるが、合成メディアフォーマットは自然コンテンツと合成コンテンツの両方に使用され得るが、自然コンテンツを合成メディアフォーマットに変換するプロセス（例えば、合成表現に）は、時間と計算集約的なプロセスである可能性があり、したがって、リアルタイムアプリケーションおよびユースケースには実用的ではない場合がある。

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

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

複数の異なる没入型メディアデバイスのためのコヒーレント配信システムを作成することのさらに他の問題は、現在および新興の没入型メディア対応デバイス自体が大幅に変化し得ることである。例えば、一部の没入型メディアデバイスは、例えばヘッドマウントディスプレイなど、一度に1人のユーザのみが使用するように明示的に設計されている。いくつかの他の没入型メディアデバイスは、それらが複数のユーザによって同時に使用され得るように設計されており、例えば、「ルッキングガラスファクトリ8Kディスプレイ」（以下、「レンチキュラーライトフィールドディスプレイ」と称される）は、最大12人のユーザによって同時に見ることができるコンテンツを表示することができ、各ユーザは、表示されているコンテンツの自分自身の固有の視点（すなわち、ビュー）を体験している。

コヒーレント配信システムの開発をさらに複雑にするのは、各ディスプレイが生成することができる固有のビューの数が大きく変化し得ることである。ほとんどの場合、レガシーディスプレイは、コンテンツの単一のビューのみを作成することができる。一方、レンチキュラーライトフィールドディスプレイは、複数のユーザをサポートすることができ、各ユーザは同じビジュアルシーンの固有のビューを体験する。同じシーンの複数のビューのこの生成を達成するために、レンチキュラーライトフィールドディスプレイは、同じシーンの45個の固有のビューがディスプレイへの入力として必要とされる特定の立体視錐台を生成する。これは、同じシーンの45個のわずかに異なる固有のラスタ表現がキャプチャされ、この特定のディスプレイ、すなわちその視錐台に固有のフォーマットでディスプレイに分配される必要があることを意味する。対照的に、レガシーディスプレイの視錐台は、単一の2次元平面に制限され、したがって、ディスプレイを体験している同時視聴者の数にかかわらず、ディスプレイの視錐台を介してコンテンツの2つ以上の視聴視点を提示する方法はない。

一般に、没入型メディアディスプレイは、すべてのディスプレイのこれらの特性、すなわち、視錐台の寸法および体積、同時にサポートされる視聴者の数、点ベース、光線ベース、または波ベースの技術であり得る視錐台を埋めるために使用される光学技術、視錐台を占有する光単位（点、光線、または波のいずれか）の密度、計算電力の利用可能性および計算のタイプ（CPUまたはGPU）、電力の供給源および利用可能性（バッテリまたはワイヤ）、ローカルストレージまたはキャッシュの量、ならびにクラウドベースの計算およびストレージなどの補助リソースへのアクセスに応じて大幅に変化し得る。これらの特性は、没入型メディアディスプレイの異種性に寄与し、レガシーディスプレイの同種性とは対照的に、レガシータイプと没入型タイプのディスプレイの両方を含むそれらのすべてをサポートできる単一の配信システムの開発を複雑にする。

開示された主題は、単一のネットワークのコンテキスト内のクライアントエンドポイントとしてレガシーおよび没入型メディアディスプレイの両方をサポートすることができるネットワークベースのメディア配信システムの開発に対処する。具体的には、入力没入型メディアソースを、そのクライアントエンドポイントデバイス上で現在実行されているアプリケーションを含むクライアントエンドポイントデバイスの特定の特性に適したフォーマットに適合させる機構が本明細書に提示される。入力没入型メディアソースを適合させるこのような機構は、入力没入型メディアの特性を、クライアントデバイス上で実行されているアプリケーションを含むターゲットエンドポイントクライアントデバイスの特性と一致させ、次いで入力没入型メディアをターゲットエンドポイントおよびそのアプリケーションに適したフォーマットに適合させることを含む。さらに、アダプテーションプロセスは、クライアントのエンドポイントが必要とする追加のビューを作成するために、入力メディアから追加のビュー、例えば新規のビューを補間することを含むことができる。そのような補間は、ニューラルネットワーク処理の助けを借りて行われてもよい。

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

レガシーメディアによってサポートされるレガシーデバイスは、レガシーメディアの標準ベースの表現を生成するレガシーメディアコンテンツプロバイダ、およびレガシーデバイスを標準的なレガシーコンテンツのソースに接続するためのネットワークインフラストラクチャを提供する商用ネットワークサービスプロバイダのエコシステムによって同様にサポートされるので、広範な消費者による導入が達成されている。ネットワークを介してレガシーメディアを配信する役割を超えて、商用ネットワークサービスプロバイダはまた、コンテンツ配信ネットワーク（CDN）上のレガシーコンテンツへのアクセスを有するレガシークライアントデバイスのペアリングを容易にすることができる。適切な形態のコンテンツへのアクセスとペアリングされると、レガシークライアントデバイスは、エンドユーザへの提示のためにコンテンツサーバからデバイスにレガシーコンテンツを要求またはプルすることができる。それにもかかわらず、ネットワークサーバが適切なメディアを適切なクライアントにプッシュするアーキテクチャは、全体的なアーキテクチャおよびソリューション設計にさらなる複雑さを招くことなく、同様に関連性がある。

本開示のいくつかの態様によれば、異種クライアントをサポートするメディア配信ネットワークは、入力メディアフォーマットから特定のターゲットフォーマットに適合されたアセットのいくつかが、類似の表示ターゲット（クライアントデバイス）のセットにわたって再利用され得るという事実を利用することができる。例えば、ターゲットディスプレイに適したフォーマットに変換されると、いくつかのアセットは、同様のアダプテーション要件を有するいくつかのそのようなディスプレイにわたって再利用されてもよい。いくつかの例では、メディア配信ネットワークは、キャッシュ機構を採用して、適合されたアセットを比較的不変のストレージに格納することができる。

本開示の一態様によれば、没入型メディアは、シーン記述としても知られるシーングラフによって記述される「シーン」に編成されてもよい。シーングラフの範囲は、プレゼンテーションの一部である特定の設定を含むビジュアル、オーディオ、および他の形態の没入型アセットを記述することであり、例えば、映画などのプレゼンテーションの一部である建物内の特定の場所で行われる俳優およびイベントである。単一のプレゼンテーションを含むすべてのシーンのリストは、シーンのマニフェストに定式化されてもよい。

いくつかの例では、そのようなコンテンツを配信しなければならない前に準備されたコンテンツについて、プレゼンテーション全体に使用されるすべてのアセット、およびプレゼンテーション内の様々なシーンにわたって各アセットが使用される頻度を識別する「部品表」が作成され得る。メディア配信ネットワークは、特定のプレゼンテーションのアセット要件を満たすために使用され得るキャッシュリソースの存在の知識を有するように実装され得る。

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

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

本開示の態様によれば、レガシーメディアによってサポートされるレガシーデバイスは、レガシーメディアの標準ベースの表現を生成するレガシーメディアコンテンツプロバイダ、およびレガシーデバイスを標準的なレガシーコンテンツのソースに接続するためのネットワークインフラストラクチャを提供する商用ネットワークサービスプロバイダのエコシステムによって同様にサポートされるので、広範な消費者による導入が達成されている。ネットワークを介してレガシーメディアを配信する役割を超えて、商用ネットワークサービスプロバイダはまた、コンテンツ配信ネットワーク（CDN）上のレガシーコンテンツへのアクセスを有するレガシークライアントデバイスのペアリングを容易にすることができる。適切な形態のコンテンツへのアクセスとペアリングされると、レガシークライアントデバイスは、エンドユーザへのプレゼンテーションのためにコンテンツサーバからデバイスにレガシーコンテンツを要求するかまたは「プル」することができる。それにもかかわらず、メディア配信ネットワークは、ネットワークサーバが適切なメディアを適切なクライアントに「プッシュ」するアーキテクチャを利用することができる。

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

様々な実施形態による方法、装置（システム）、およびコンピュータ可読媒体のフローチャート図および／またはブロック図を参照して、態様を本明細書で説明する。フローチャート図および／またはブロック図の各ブロック、ならびにフローチャート図および／またはブロック図のブロックの組合せは、コンピュータ可読プログラム命令によって実施され得ることが理解されよう。

以下に説明する例示的な実施形態は、ビデオ、オーディオ、幾何学的（3D）オブジェクト、触覚、関連するメタデータ、またはクライアントデバイスのための他のコンテンツを含む、メディアを配信するシステムおよびネットワークのためのアーキテクチャ、構造、および構成要素に関する。特定の実施形態は、異種没入型および対話型クライアントデバイスへのメディアコンテンツの配信のためのシステム、構造、およびアーキテクチャに関する。

図1は、タイムドレガシーメディア配信のエンドツーエンドプロセス（100）の図を示す。図1において、タイムドオーディオビジュアルコンテンツは、カメラまたはマイクロフォン（101A）によってキャプチャされるか、またはコンピュータ（101B）によって生成され、準備モジュール（103）に入力される2D画像および関連するオーディオのシーケンス（102）を作成する。準備モジュール（103）の出力は、変換器モジュール（104）によって、例えばオンデマンドメディア用の標準的なメザニンフォーマットに、または例えばライブイベント用の標準的な寄与フォーマットに変換される準備ができているマスタフォーマットと称される編集されたコンテンツ（例えば、言語翻訳、字幕、他の編集機能を含むポスト制作用）である。一例では、メディアは、商用ネットワークサービスプロバイダによって取り込まれ、アダプテーションモジュール（105）は、メディアを、標準的な配信フォーマットにパッケージ化される様々なビットレート、時間解像度（フレームレート）、または空間解像度（フレームサイズ）にパッケージ化する。結果として得られるアダプテーションは、様々なクライアント（108A）～（108C）がそこからメディアをフェッチしてエンドユーザに提示するためにプル要求（107A）～（107C）を行うコンテンツ配信ネットワーク（CDN）（106）上に記憶される。マスタフォーマットは、（101A）または（101B）の両方からのメディアのハイブリッドから構成されてもよく、（101A）のフォーマットは、例えば、ライブスポーツイベントから取得されたメディアなど、リアルタイムで取得されてもよいことに留意することが重要である。さらに、クライアント（108A）～（108C）は、クライアントの構成および／または現在のネットワーク条件に最も適した特定のアダプテーション（107）を選択する役割を担うが、ネットワークサーバ（図1には示されていない）が適切なコンテンツを決定し、続いてクライアント（108A）～（108C）にプッシュすることも同様に可能である。

図2は、いくつかの例におけるレガシータイムドメディア、例えばビデオ、オーディオ、およびサポートメタデータ（字幕に使用されるようなタイムドテキストを含む）の配信に使用される標準メディアフォーマット（200）の図を示す。図1のCDN（106）によって示されるように、メディアは、図2のCDN（201A）～（201C）などのCDN上に標準ベースの配信フォーマットで記憶される。標準ベースのフォーマットは、MPD（202）として示されており、これは、クロックに対応する開始時間および終了時間を有する、期間（203A）および期間（203B）などのタイムド期間を包含する複数のセクションからなる。一例では、各期間（例えば、（203A）（203B））は、1つまたは複数のアダプテーションセット（204A）～（204F）を指す。（204A）～（204F）の各アダプテーションセットは、一般に、単一のタイプのメディア、例えばビデオ、オーディオ、またはタイムドテキストに使用される。いくつかの例では、任意の所与の期間（例えば、（203A））について、複数のアダプテーションセット（例えば、（204A）～（204C））、例えば、ビデオ用の1つ、および様々な言語への翻訳に使用されるようなオーディオ用の複数が提供されてもよい。（204A）～（204F）の各アダプテーションセットは、メディアのフレーム解像度（ビデオ用）、フレームレート、およびビットレートに関する情報を提供する1つまたは複数の表現（205）を指す。例えば、超高精細度、高精細度、または標準的精細度ビデオのための表現（205）へのアクセスを提供するために、複数の表現（205）が使用されてもよい。各表現（205）は、（図1の（108A）～（108C）に示すように）クライアントによるフェッチのために、またはネットワークメディアサーバ（図1には示されていない）による（プッシュベースのアーキテクチャにおける）配信のために、メディアが実際に記憶される、1つまたは複数のセグメントファイル（206）を指す。

図3は、一例においてタイムド式である異種没入型メディアのためのストリーミング可能フォーマット（300）の表現を示し、図4は、一例において非タイムド式である異種没入型メディアのためのストリーミング可能フォーマット（400）の表現を示す。図3の場合、図3はタイムドメディアのシーン（301）を参照する。図4の場合、図4は非タイムドメディアのシーン（401）を参照する。どちらの場合も、シーンは、様々なシーン表現またはシーン記述によって具現化されてもよい。

例えば、いくつかの没入型メディア設計では、シーンはシーングラフによって、または多平面画像（MPI）として、または多球面画像（MSI）として具現化されてもよい。MPIおよびMSI技術の両方は、自然なコンテンツ、すなわち1つまたは複数のカメラから同時にキャプチャされた現実世界の画像についてディスプレイに依存しないシーン表現の作成を支援する技術の例である。一方、シーングラフ技術は、自然画像とコンピュータ生成画像の両方を合成表現の形式で表現するために採用され得るが、そのような表現は、コンテンツが1つまたは複数のカメラによって自然シーンとしてキャプチャされる場合に作成するために特に計算集約的である。すなわち、自然にキャプチャされたコンテンツのシーングラフ表現は、作成するのに時間と計算集約的であり、ターゲットの没入型クライアントディスプレイの視錐台を満たすのに十分かつ適切な数のビューを補間するために後で使用できる合成表現を作成するために、写真測量または深層学習またはその両方の技術を用いた自然画像の複雑な解析を必要とする。結果として、そのような合成表現は、リアルタイム配信を必要とするユースケースを考慮するためにリアルタイムで実際に作成することができないため、自然なコンテンツを表現するための候補として考慮するには現在実用的ではない。いくつかの例では、コンピュータ生成画像の最良の候補表現は、3Dモデリングプロセスおよびツールを使用してコンピュータ生成画像が作成されるので、合成モデルを有するシーングラフの使用を採用することである。

自然コンテンツとコンピュータ生成コンテンツの両方の最適表現におけるそのような2分法は、自然にキャプチャされたコンテンツの最適なインジェストフォーマットが、リアルタイム配信アプリケーションに必須ではないコンピュータ生成コンテンツまたは自然コンテンツの最適なインジェストフォーマットとは異なることを示唆している。したがって、開示された主題は、それらが自然に作成されるかコンピュータによって作成されるかにかかわらず、視覚的に没入可能なメディアのための複数のインジェストフォーマットをサポートするのに十分に堅牢であることを目標とする。

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

1．OTOY社のORBX（登録商標）
OTOY社のORBXは、レイトレース可能、レガシー（フレームベース）、立体および他のタイプの、合成またはベクトルベースのビジュアルフォーマットを含むタイムド式または非タイムド式の任意のタイプのビジュアルメディアをサポートすることができるいくつかのシーングラフ技術のうちの1つである。一態様によれば、ORBXは、メッシュ、点群、およびテクスチャのための自由に利用可能なおよび／またはオープンソース形式のネイティブサポートを提供するので、ORBXは他のシーングラフからユニークである。ORBXは、シーングラフ上で動作する複数のベンダ技術にわたる交換を容易にすることを目的として意図的に設計されたシーングラフである。さらに、ORBXは、豊富な素材システム、オープンシェーダ言語のサポート、堅牢なカメラシステム、およびLuaスクリプトのサポートを提供する。ORBXはまた、没入型デジタル体験アライアンス（IDEA）によって使用料無料の条件でライセンスのために公開された没入型技術メディアフォーマットの基礎でもある。メディアのリアルタイム配信のコンテキストでは、自然なシーンのORBX表現を作成および配信する能力は、カメラによってキャプチャされたデータの複雑な分析および同じデータの合成表現への合成を行うための計算リソースの利用可能性の関数である。今日まで、リアルタイム配信のための十分な計算の利用可能性は実用的ではないが、それでもなお不可能ではない。

2．Pixar社によるユニバーサルシーン記述
Pixar社によるユニバーサルシーン記述（USD）は、ビジュアルエフェクト（VFX）およびプロフェッショナルコンテンツ制作コミュニティにおいて使用され得る他のシーングラフである。USDは、Nvidia社のGPUを用いた3Dモデル作成およびレンダリングのための開発者向けツールのセットであるNvidia社のOmniverseプラットフォームに統合されている。USDのサブセットは、USDZとしてApple社およびPixar社によって公開された。USDZは、Apple社のARKitによってサポートされている。

3．Khronos社のglTF2．0
glTF2．0は、Khronos 3D Groupによって書かれたグラフィックス言語伝送フォーマット仕様の最新バージョンである。このフォーマットは、「png」および「jpeg」画像フォーマットを含む、一般にシーン内の静的（非タイムド式）オブジェクトをサポートすることができる単純なシーングラフフォーマットをサポートする。glTF2．0は、単純なアニメーションをサポートし、glTFプリミティブを使用して記述された基本形状、すなわち幾何学的オブジェクトの並進、回転、およびスケーリングをサポートする。glTF2．0はタイムドメディアをサポートしておらず、したがって、ビデオもオーディオもサポートしていない。

没入型ビジュアルメディアの上記のシーン表現は、例えば提供されているにすぎず、入力没入型メディアソースをクライアントエンドポイントデバイスの特定の特性に適したフォーマットに適合させるプロセスを指定するその能力において開示された主題を限定しないことに留意されたい。

さらに、上記の例示的なメディア表現のいずれかまたはすべては、錐台の特定の寸法に基づいて特定のディスプレイの視錐台を満たすために特定のビューの選択を可能にするかまたは容易にするニューラルネットワークモデルを訓練および作成するために、ディープラーニング技術を現在採用している、または採用しうる。特定のディスプレイの視錐台のために選択されたビューは、シーン表現で明示的に提供される既存のビュー、例えばMSIまたはMPI技術から補間されてもよく、またはこれらのレンダリングエンジンのための特定の仮想カメラ位置、フィルタ、または仮想カメラの記述に基づいてレンダリングエンジンから直接レンダリングされてもよい。

したがって、開示された主題は、自然に（例えば、1つまたは複数のカメラを用いて）キャプチャされるか、またはコンピュータ生成技術を用いて作成されるメディアのリアルタイムまたは「オンデマンド」（例えば、非リアルタイム）配信の両方の要件を十分に満たすことができる、比較的小さいが周知の没入型メディアインジェストフォーマットのセットがあることを考慮するのに十分に堅牢である。

ニューラルネットワークモデルまたはネットワークベースのレンダリングエンジンのいずれかの使用による没入型メディアインジェストフォーマットからのビューの補間は、モバイルネットワーク用の5Gおよび固定ネットワーク用の光ファイバケーブルなどの高度なネットワーク技術が展開されるにつれてさらに容易になる。すなわち、これらの高度なネットワーク技術は、そのような高度なネットワークインフラストラクチャがますます大量のビジュアル情報の伝送および配信をサポートすることができるので、商用ネットワークの容量および能力を増加させる。マルチアクセスエッジコンピューティング（MEC）、ソフトウェア定義ネットワーク（SDN）、およびネットワーク機能仮想化（NFV）などのネットワークインフラ管理技術は、商用ネットワークサービスプロバイダが、特定のネットワークリソースに対する需要の変化に適合するように、例えば、ネットワークスループット、ネットワーク速度、往復遅延、および計算リソースに対する需要の動的な増減に応答するように、それらのネットワークインフラを柔軟に構成することを可能にする。さらに、動的ネットワーク要件に適合するこの固有の能力は、同様に、異種クライアントエンドポイントのための潜在的に異種のビジュアルメディアフォーマットを有する様々な没入型メディアアプリケーションをサポートするために、没入型メディアインジェストフォーマットを適切な配信フォーマットに適合させるネットワークの能力を容易にする。

没入型メディアアプリケーション自体はまた、ゲームの状態でリアルタイム更新に応答するために著しく低いネットワーク待ち時間を必要とするゲームアプリケーション、ネットワークのアップリンク部分およびダウンリンク部分の両方に対して対称的なスループット要件を有するテレプレゼンスアプリケーション、およびデータを消費しているクライアントのエンドポイントのディスプレイのタイプに応じてダウンリンクリソースに対する需要が増加する可能性のある受動的閲覧アプリケーションを含む、ネットワークリソースに対する様々な要件を有してもよい。一般に、任意の消費者向けアプリケーションは、ストレージ、計算および電力のための様々なオンボードクライアント機能、ならびに特定のメディア表現のための同じく様々な要件を含む様々なクライアントのエンドポイントによってサポートされてもよい。

したがって、開示された主題は、十分に装備されたネットワーク、すなわち、最新のネットワークの特性の一部またはすべてを採用するネットワークが、以下の中で指定された特徴に従って複数のレガシーおよび没入型メディア対応デバイスを同時にサポートすることを可能にする。

1．メディアの配信のためのリアルタイムおよびオンデマンドのユースケースの両方に実用的なメディアインジェストフォーマットを活用する柔軟性を提供する。

2．レガシーおよび没入型メディア対応のクライアントエンドポイントの両方について、自然コンテンツとコンピュータ生成コンテンツの両方をサポートする柔軟性を提供する。

3．タイムドメディアと非タイムドメディアの両方をサポートする。

4．クライアントエンドポイントの機能および能力に基づいて、ならびにアプリケーションの要件に基づいて、ソースメディアインジェストフォーマットを適切な配信フォーマットに動的に適合させるためのプロセスを提供する。

5．配信フォーマットがIPベースのネットワーク上でストリーミング可能であることを保証する。

6．ネットワークが、レガシーおよび没入型メディア対応デバイスの両方を含み得る複数の異種クライアントエンドポイントに同時にサービスを提供できるようにする。

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

開示された主題によって可能にされる改善のエンドツーエンドの実施形態は、図3から図15の詳細な説明に記載された処理および構成要素に従って達成される。

図3および図4はそれぞれ、特定のクライアントエンドポイントの能力に一致するようにインジェストソースフォーマットから適合され得る例示的な包括的な配信フォーマットを採用する。上述したように、図3に示されているメディアはタイムド式であり、図4に示されているメディアは非タイムド式である。特定の包含フォーマットは、その構造において、各層がメディアの提示に寄与する顕著な情報の量に基づいてそれぞれが階層化され得る多種多様なメディア属性に対応するのに十分に堅牢である。レイヤリングプロセスは、例えば、プログレッシブJPEGおよびスケーラブルビデオアーキテクチャ（例えば、ISO／IEC 14496－10スケーラブルアドバンストビデオ符号化に規定されている）に適用され得ることに留意されたい。

一態様によれば、包含するメディアフォーマットに従ってストリーミングされるメディアは、レガシービジュアルメディアおよびオーディオメディアに限定されず、機械と相互作用して人間の視覚、音、味、触覚、および匂いを刺激する信号を生成することができる任意のタイプのメディア情報を含むことができる。

他の態様によれば、包含するメディアフォーマットに従ってストリーミングされるメディアは、タイムドメディアもしくは非タイムドメディアの両方、または両方の混合であり得る。

他の態様によれば、包含するメディアフォーマットは、ベース層および強化層アーキテクチャを使用することによってメディアオブジェクトの階層表現を可能にすることによってさらに流線型化可能である。一例では、別々のベース層および強化層は、各シーン内のメディアオブジェクトについての多重解像度または多重モザイク化の解析技術の適用によって計算される。これは、ISO／IEC 10918－1（JPEG）およびISO／IEC 15444－1（JPEG2000）で指定されたプログレッシブレンダリング画像フォーマットに類似しているが、ラスタベースのビジュアルフォーマットに限定されない。一例では、幾何学的オブジェクトのプログレッシブ表現は、ウェーブレット解析を使用して計算されたオブジェクトの多重解像度表現であり得る。

メディアフォーマットの階層化表現の他の例では、強化層は、ベース層によって表されるビジュアルオブジェクトの表面の材料特性を改良するなど、ベース層に異なる属性を適用する。さらに他の例では、属性は、表面を滑らかなテクスチャから多孔質のテクスチャに、またはつや消しの表面から光沢のある表面に変更するなど、ベース層オブジェクトの表面のテクスチャを改良することができる。

階層化表現のさらに他の例では、シーン内の1つまたは複数のビジュアルオブジェクトの表面は、ランバート面からレイトレース可能な表面に変更されてもよい。

階層化表現のさらに他の例では、ネットワークはベース層表現をクライアントに配信し、その結果、クライアントは、ベース表現の解像度または他の特性を改良するために追加の強化層の送信を待機している間にクライアントがシーンの公称プレゼンテーションを作成してもよい。

他の態様によれば、強化層における属性の解像度または精緻化情報は、既存のMPEGビデオおよびJPEG画像標準規格において現在のようにベース層におけるオブジェクトの解像度と明示的に結合されない。

他の態様によれば、包含するメディアフォーマットは、提示デバイスまたはマシンによって提示または作動され得る任意のタイプの情報メディアをサポートし、それによって異種クライアントエンドポイントへの異種メディアフォーマットのサポートを可能にする。メディアフォーマットを配信するネットワークの一実施形態では、ネットワークは、最初にクライアントの能力を判定するためにクライアントエンドポイントに問い合わせ、クライアントがメディア表現を有意に取り込むことができない場合、ネットワークは、クライアントによってサポートされていない属性の層を除去するか、またはメディアをその現在のフォーマットからクライアントエンドポイントに適したフォーマットに適合させる。そのようなアダプテーションの1つの例では、ネットワークは、ネットワークベースのメディア処理プロトコルを使用することによって、ボリュームのビジュアルメディアアセットを同じビジュアルアセットの2D表現に変換する。そのようなアダプテーションの他の例では、ネットワークは、適切なフォーマットにメディアを再フォーマットするために、または任意選択的にクライアントのエンドポイントによって必要とされるビューを合成するために、ニューラルネットワークプロセスを使用することができる。

他の態様によれば、完全なまたは部分的に完全な没入型体験（ライブストリーミングイベント、ゲーム、またはオンデマンドアセットの再生）のためのマニフェストは、プレゼンテーションを作成するためにレンダリングおよびゲームエンジンが現在取り込み得る最小量の情報であるシーンによって編成される。マニフェストは、クライアントによって要求された没入型体験の全体がレンダリングされる個々のシーンのリストを含む。各シーンには、シーンジオメトリのストリーミング可能なバージョンに対応するシーン内の幾何学的オブジェクトの1つまたは複数の表現が関連付けられている。シーン表現の一実施形態は、シーンの幾何学的オブジェクトの低解像度バージョンに関する。同じシーンの他の実施形態は、同じシーンの幾何学的オブジェクトにさらなる詳細を追加するか、またはモザイク化を増加させるための、シーンの低解像度表現のための強化層に関する。上述したように、各シーンは、シーンの幾何学的オブジェクトの詳細を漸進的に増加させるために、2つ以上の強化層を有してもよい。

他の態様によれば、シーン内で参照されるメディアオブジェクトの各層は、リソースがネットワーク内でアクセスされ得る場所のアドレスを指すトークン（例えば、URI）に関連付けられる。このようなリソースは、コンテンツがクライアントによってフェッチされ得るCDNに類似している。

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

図3は、いくつかの例におけるタイムドメディアのための包含するメディアフォーマットの一実施形態を説明する。いくつかの例では、タイムドシーンマニフェストは、シーン（シーン情報とも称される）を含む（301）。シーン（301）は、処理情報と、シーン（301）を含むメディアアセットのタイプとを別々に記述する構成要素（302）のリストを指す。構成要素（302）は、さらにベース層（304）および属性強化層（305）を指すアセット（303）を指す。

図4は、いくつかの例における非タイムドメディアのための包含するメディアフォーマットの一実施形態を説明する。非タイムドシーンマニフェストは、シーン（401）を含む。シーン（シーン情報とも称される）（401）は、クロックによる開始時間および終了時間に関連付けられていない。シーン（401）は、シーン（401）を構成する処理情報およびメディアアセットのタイプを別々に記述する構成要素（402）のリストを指す。構成要素（402）は、ベース層（404）および属性強化層（405）をさらに指すアセット（403）（例えば、ビジュアルアセット、オーディオアセット、触覚アセット）を指す。さらに、シーン（401）は、非タイムドメディア用の他のシーン（411）を指す。シーン（401）はまた、いくつかの例では、タイムドメディアシーン（407）を指してもよい。

図5は、自然コンテンツからインジェストフォーマットを合成するためのプロセス（500）の図を示す。プロセス（500）は、コンテンツキャプチャのための第1のサブプロセスと、自然画像のためのインジェストフォーマット合成のための第2のサブプロセスと、を含む。

図5の例では、第1のサブプロセスでは、自然な画像コンテンツをキャプチャするために、カメラユニットが使用され得る（509）。例えば、カメラユニット（501）は、人物のシーンをキャプチャするために単一のカメラレンズを使用することができる。カメラユニット（502）は、リング状の物体の周囲に5つのカメラレンズを装着することで、5つの発散する視野のシーンをキャプチャすることができる。（502）の配置は、VRアプリケーション用の全方向コンテンツをキャプチャするための例示的な配置である。カメラユニット（503）は、7つのカメラレンズを球体の内径部分に装着することにより、7つの視野が収束するシーンをキャプチャする。（503）の配置は、ライトフィールドまたはホログラフィック没入型ディスプレイのためのライトフィールドを捕捉するための例示的な配置である。

図5の例では、第2のサブプロセスにおいて、自然画像コンテンツ（509）が合成される。例えば、自然画像コンテンツ（509）は、一例では、キャプチャニューラルネットワークモデル（508）を生成するために訓練画像（506）の集合を使用するニューラルネットワーク訓練モジュール（505）を使用することができる合成モジュール（504）への入力として提供される。訓練プロセスの代わりに一般的に使用される他のプロセスは写真測量である。モデル（508）が図5に示すプロセス（500）中に作成される場合、モデル（508）は、自然なコンテンツのインジェストフォーマット（507）のアセットのうちの1つになる。インジェストフォーマット（507）の例示的な実施形態は、MPIおよびMSIを含む。

図6は、合成メディア（608）、例えばコンピュータ生成画像のインジェストフォーマットを作成するプロセス（600）の図を示す。図6の例では、LIDARカメラ（601）はシーンの点群（602）をキャプチャする。合成コンテンツを作成するためのコンピュータ生成画像（CGI）ツール、3Dモデリングツール、または他のアニメーションプロセスは、ネットワークを介してCGIアセットを作成する（604）ためにコンピュータ（603）上で使用される。センサ（605A）を有するモーションキャプチャスーツが、行為者（605）に装着されて、行為者（605）の動きのデジタル記録をキャプチャして、アニメーション化されたモーションキャプチャ（MoCap）データ（606）を生成する。データ（602）、（604）、および（606）は、合成モジュール（607）への入力として提供され、合成モジュールも同様に、例えば、ニューラルネットワークおよび訓練データを使用して、ニューラルネットワークモデル（図6には示されていない）を作成することができる。

図7は、いくつかの例においてクライアントエンドポイントとして様々なレガシーおよび異種没入型メディア対応ディスプレイをサポートするネットワークメディア配信システム（700）を示す。図7の例では、コンテンツ取得モジュール（701）は、図6または図5の例示的な実施形態を使用してメディアをキャプチャまたは作成する。インジェストフォーマットは、コンテンツ準備モジュール（702）において作成され、次いで、送信モジュール（703）を使用してネットワークメディア配信システム内の1つまたは複数のクライアントエンドポイントに送信される。ゲートウェイ（704）は、顧客宅内機器にサービスして、ネットワークのための様々なクライアントエンドポイントへのネットワークアクセスを提供することができる。セットトップボックス（705）はまた、ネットワークサービスプロバイダによる集約コンテンツへのアクセスを提供するための顧客宅内機器として機能することができる。無線復調器（706）は、（例えば、モバイルハンドセットおよびディスプレイ（713）と同様に）モバイルデバイスのためのモバイルネットワークアクセスポイントとして機能し得る。1つまたは複数の実施形態では、レガシー2Dテレビ（707）は、ゲートウェイ（704）、セットトップボックス（705）、またはWiFiルータ（708）に直接接続されてもよい。レガシー2Dディスプレイ（709）を有するコンピュータラップトップは、WiFiルータ（708）に接続されたクライアントエンドポイントであってもよい。ヘッドマウント2D（ラスタベース）ディスプレイ（710）はまた、ルータ（708）に接続されてもよい。レンチキュラーライトフィールドディスプレイ（711）はゲートウェイ（704）に接続されてもよい。ディスプレイ（711）は、ローカル計算GPU（711A）、ストレージデバイス（711B）、および光線ベースのレンチキュラー光学技術を使用して複数のビューを作成するビジュアルプレゼンテーションユニット（711C）から構成されてもよい。ホログラフィックディスプレイ（712）は、セットトップボックス（705）に接続されてもよく、ローカル計算CPU（712A）、GPU（712B）、ストレージデバイス（712C）、およびフレネルパターン、波ベースのホログラフィック視覚化ユニット（712D）を含んでもよい。拡張現実ヘッドセット（714）は、無線復調器（706）に接続されてもよく、GPU（714A）、ストレージデバイス（714B）、バッテリ（714C）、および体積ビジュアルプレゼンテーションコンポーネント（714D）を含んでもよい。高密度ライトフィールドディスプレイ（715）は、WiFiルータ（708）に接続されてもよく、複数のGPU（715A）、CPU（715B）、およびストレージデバイス（715C）、視線追跡デバイス（715D）、カメラ（715E）、ならびに高密度光線ベースのライトフィールドパネル（715F）を含んでもよい。

図8は、図7に前述したようにレガシーおよび異種の没入型メディア対応ディスプレイにサービスを提供することができる没入型メディア配信モジュール（800）の図を示す。コンテンツは、それぞれ自然コンテンツおよびCGIコンテンツについて図5および図6に具現化されるモジュール（801）において作成または取得される。次いで、コンテンツは、ネットワークインジェストフォーマット作成モジュール（802）を使用してインジェストフォーマットに変換される。モジュール（802）のいくつかの例は、それぞれ自然コンテンツおよびCGIコンテンツについて図5および図6に具体化されている。インジェストメディアフォーマットは、ネットワークに送信され、ストレージデバイス（803）に格納される。いくつかの他の例では、ストレージデバイスは没入型メディアコンテンツ制作者のネットワーク内に存在し、二等分する破線で示すように没入型メディアネットワーク配信モジュール（800）によってリモートでアクセスされてもよい。クライアントおよびアプリケーション固有の情報は、いくつかの例では、リモートストレージデバイス（804）で利用可能であり、これは、例では代替クラウドネットワークに任意選択的に遠隔に存在してもよい。

図8に示すように、クライアントインターフェースモジュール（805）は、配信ネットワークの主要なタスクを実行するための情報の主要なソースおよびシンクとして機能する。この特定の実施形態では、クライアントインターフェースモジュール（805）は、ネットワークの他の構成要素と統一されたフォーマットで実装されてもよい。それにもかかわらず、図8のクライアントインターフェースモジュール（805）によって描写されたタスクは、いくつかの例では開示された主題の要素を形成する。

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

クライアントインターフェースモジュール（805）は、図8のクライアント（808）（クライアントデバイス（808）とも称される）などのクライアントデバイスの特徴および属性に関する情報を受信し、さらに、クライアント（808）上で現在実行されているアプリケーションに関する要件を収集する。この情報は、デバイス（804）から取得されてもよく、または代替的な実施形態では、クライアント（808）に直接問い合わせることによって取得されてもよい。いくつかの例では、クライアントインターフェースモジュール（805）とクライアント（808）との間の直接通信を可能にするために双方向プロトコルが使用される。例えば、クライアントインターフェースモジュール（805）は、クライアント（808）に直接クエリを送信することができる。双方向プロトコルにおけるメッセージの一例が、図16A～図16C、図17A～図17G、および図18を参照して提供される。

クライアントインターフェースモジュール（805）はまた、図9に記載されるメディアアダプテーションおよびフラグメンテーションモジュール（810）を開始してそれと通信する。インジェストメディアがモジュール（810）によって適合され断片化されると、メディアは、いくつかの例では、配信ストレージデバイス（809）のために準備されたメディアとして示されたメディア間ストレージデバイスに転送される。配信メディアが準備されてデバイス（809）に記憶されると、クライアントインターフェースモジュール（805）は、没入型クライアント（808）が、そのネットワークインターフェース（808B）を介して、プッシュ要求を介して配信メディアおよび対応する記述情報（806）を受信するか、またはクライアント（808）自体がストレージデバイス（809）からメディア（806）のプル要求を開始することができるかのいずれかを確実にする。没入型クライアント（808）は、いくつかの例では、GPU（または図示されていないCPU）（808C）を使用することができる。メディアの配信フォーマットは、クライアント（808）のストレージデバイスまたはストレージキャッシュ（808D）に格納される。最後に、没入型クライアント（808）は、その視覚化コンポーネント（808A）を介してメディアを視覚的に提示する。

没入型メディアを没入型クライアント（808）にストリーミングするプロセス全体を通して、クライアントインターフェースモジュール（805）は、クライアント進捗およびステータスフィードバックチャネル（807）を介してクライアントの進捗のステータスを監視することができる。

図9は、一部の実施例では、取り込まれたソースメディアが没入型クライアント（808）の要件に一致するように適切に適合され得るように、メディアアダプテーションプロセスの図を示す。メディアアダプテーションモジュール（901）は、没入型クライアント（808）のための適切な配信フォーマットへのインジェストメディアのアダプテーションを容易にする複数の構成要素からなる。図9では、メディアアダプテーションモジュール（901）は、ネットワーク上の現在のトラフィック負荷を追跡するために入力ネットワークステータス（905）を受信する。没入型クライアント（808）情報は、属性および特徴記述、アプリケーション特徴および記述、ならびにアプリケーションの現在ステータス、およびクライアントの錐台のジオメトリをインジェスト没入型メディアの補間機能にマッピングするのを助けるクライアントニューラルネットワークモデル（利用可能な場合）を含むことができる。メディアアダプテーションモジュール（901）は、適合された出力が作成されると、それがクライアントに適合されたメディアストレージデバイス（906）に記憶されることを保証する。

いくつかの例では、メディアアダプテーションモジュール（901）は、特定のインジェストソースメディアをクライアントに適したフォーマットに適合させるために、レンダラ（901B）またはニューラルネットワークプロセッサ（901C）を使用する。一例では、メディアアダプテーションモジュール（901）は、一例ではサーバデバイスなどのクライアントインターフェースモジュール（903）からクライアント情報（904）を受信する。クライアント情報（904）は、クライアント記述および現在ステータスを含むことができ、アプリケーション記述および現在ステータスを含むことができ、クライアントニューラルネットワークモデルを含むことができる。ニューラルネットワークプロセッサ（901C）は、ニューラルネットワークモデル（901A）を用いる。このようなニューラルネットワークプロセッサ（901C）としては、例えば、MPIやMSIに記載されているような深層ニューラルネットワークモデル生成部が挙げられる。いくつかの例では、メディアは2Dフォーマットであるが、クライアントは3Dフォーマットを必要とし、次いで、ニューラルネットワークプロセッサ（901C）は、ビデオに描写されたシーンの立体表現を導出するために2Dビデオ信号から高相関画像を使用するプロセスを呼び出すことができる。そのようなプロセスの例は、カリフォルニア大学Berkleyで開発された1つまたは少数の画像プロセスからのニューラル放射場であり得る。適切なレンダラ（901B）の一例は、メディアアダプテーションモジュール（901）と直接対話するように修正されるOTOY Octaneレンダラ（図示せず）の修正バージョンとすることができる。メディアアダプテーションモジュール（901）は、いくつかの例では、インジェストメディアのフォーマットおよび没入型クライアント（808）が必要とするフォーマットに関するこれらのツールの必要性に応じて、メディア圧縮器（901D）およびメディア解凍器（901E）を使用することができる。

図10は、いくつかの例では、クライアントに適合されたメディアストレージデバイス（1002）上に現在存在するメディアアダプテーションモジュール（1001）（例えば、図9のメディアアダプテーションモジュール（901）に対応する）から適合されたメディアを最終的に変換する適合メディアパッケージングプロセスを示す。例えば、メディアパッケージングモジュール（1003）は、メディアアダプテーションモジュール（1001）からの適合されたメディアを、ロバストな配信フォーマット（1004）、例えば、図3または図4に示す例示的なフォーマットにフォーマットする。マニフェスト情報（1004A）は、没入型クライアント（808）に、クライアント（808）が受信すると期待できるシーンデータのリストを提供し、また、ビジュアルアセットおよび対応するメタデータ、ならびにオーディオアセットおよび対応するメタデータのリストを提供する。

図11は、いくつかの例における断片化プロセスを示す。図11の例では、パケット化器（1102）は、様々な適合されたメディア（1101）を、ネットワーク上のクライアントエンドポイント（1104）として示される没入型クライアント（808）へのストリーミングに適した個々のパケット（1103）にフラグメント化する。

図12は、いくつかの例において、インジェストフォーマットの特定の没入型メディアを特定の没入型メディアクライアントエンドポイントのためのストリーミング可能で適切な配信フォーマットに適合させるネットワークのシーケンス図を示す。

図12に示す構成要素および通信は以下のように説明される：クライアント（1201）（いくつかの例ではクライアントエンドポイントとも称される）は、ネットワーク配信インターフェース（1202）へのメディア要求（1208）を開始する。メディア要求（1208）は、URNまたは他の標準的な命名法のいずれかによってクライアント（1201）によって要求されたメディアを識別するための情報を含む。ネットワーク配信インターフェース（1202）は、クライアント（1201）がその現在利用可能なリソース（クライアントの現在の動作ステータスを特徴付けるための計算、ストレージ、バッテリ充電率、および他の情報を含む）に関する情報を提供することを要求するプロファイル要求（1209）を用いてメディア要求（1208）に応答する。プロファイル要求（1209）はまた、ニューラルネットワーク推論のためにネットワークによって使用されて正しいメディアビューを抽出または補間してクライアントのプレゼンテーションシステムの特徴に一致させられ得る1つまたは複数のニューラルネットワークモデルがクライアントにおいて利用可能である場合、そのようなモデルをクライアントが提供することを要求する。クライアント（1201）からネットワーク配信インターフェース（1202）への応答（1210）は、クライアントトークン、アプリケーショントークン、および1つまたは複数のニューラルネットワークモデルトークン（そのようなニューラルネットワークモデルトークンがクライアントで利用可能な場合）を提供する。次いで、ネットワーク配信インターフェース（1202）は、セッションIDトークン（1211）をクライアント（1201）に提供する。次いで、ネットワーク配信インターフェース（1202）は、要求（1208）で識別されたメディアのURNまたは標準命名法の名前を含むインジェストメディア要求（1212）を用いてインジェストメディアサーバ（1203）を要求する。インジェストメディアサーバ（1203）は、インジェストメディアトークンを含む応答（1213）で要求（1212）に応答する。次いで、ネットワーク配信インターフェース（1202）は、呼び出し（1214）における応答（1213）からのメディアトークンをクライアント（1201）に提供する。次いで、ネットワーク配信インターフェース（1202）は、アダプテーションインターフェース（1204）にインジェストメディアトークン、クライアントトークン、アプリケーショントークン、およびニューラルネットワークモデルトークン（1215）を提供することによって、メディア要求（1208）のアダプテーションプロセスを開始する。アダプテーションインターフェース（1204）は、インジェストメディアアセットへのアクセスを要求する呼び出し時のインジェストメディアトークン（1216）をインジェストメディアサーバ（1203）に提供することによって、インジェストメディアへのアクセスを要求する。インジェストメディアサーバ（1203）は、アダプテーションインターフェース（1204）に対する応答（1217）において、インジェストメディアアクセストークンを有する要求（1216）に応答する。次いで、アダプテーションインターフェース（1204）は、メディアアダプテーションモジュール（1205）が、（1213）において作成されたセッションIDトークンに対応するクライアント、アプリケーション、およびニューラルネットワーク推論モデルのためにインジェストメディアアクセストークンに位置するインジェストメディアを適合させることを要求する。アダプテーションインターフェース（1204）からメディアアダプテーションモジュール（1205）への要求（1218）は、必要なトークンとセッションIDとを含む。メディアアダプテーションモジュール（1205）は、ネットワーク配信インターフェース（1202）に、適合されたメディアアクセストークンおよび更新時のセッションID（1219）を提供する。ネットワーク配信インターフェース（1202）は、インターフェース呼び出し（1220）において、適合されたメディアアクセストークンおよびセッションIDをパッケージングモジュール（1206）に提供する。パッケージングモジュール（1206）は、応答メッセージ（1221）においてパッケージ化されたメディアアクセストークンおよびセッションIDと共に応答（1221）をネットワーク配信インターフェース（1302）に提供する。パッケージングモジュール（1206）は、応答（1222）において、セッションIDのためのパッケージ化されたアセット、URN、およびパッケージ化されたメディアアクセストークンをパッケージ化されたメディアサーバ（1207）に提供する。クライアント（1201）は、要求（1223）を実行して、応答メッセージ（1221）で受信したパッケージ化されたメディアアクセストークンに対応するメディアアセットのストリーミングを開始する。クライアント（1201）は、他の要求を実行し、メッセージ（1224）のステータス更新をネットワーク配信インターフェース（1202）に提供する。

図13は、いくつかの例では、3Dフォーマットの没入型メディアおよびアセット（1301）と2Dフォーマット（1302）との2つの部分からなる、図9のインジェストメディアフォーマットおよびアセット（902）を示す。2Dフォーマット（1302）は、例えばISO／IEC 14496 Part 10アドバンストビデオ符号化のような単一ビュー符号化ビデオストリームであってもよいし、例えばISO／IEC 14496 Part 10に対する多視点圧縮補正のような複数のビューを含む符号化ビデオストリームであってもよい。

図14は、符号化されたビデオストリームと共にニューラルネットワークモデル情報のキャリッジを示す図である。図14において、符号化ビデオストリーム（1401）は、ニューラルネットワークモデルと、1つまたは複数のSEIメッセージ（1401A）および符号化ビデオストリーム（1401B）によって直接搬送される対応するパラメータとを含む。一方、符号化ビデオストリーム（1402）では、1つまたは複数のSEIメッセージは、ニューラルネットワークモデルの識別子およびその対応するパラメータ（1402A）ならびに符号化ビデオビットストリーム（1402B）を搬送する。（1402）のシナリオでは、ニューラルネットワークモデルおよびパラメータは、符号化ビデオストリームの外部、例えば図9の（901A）に記憶される。

図15は、取り込まれた没入型メディアおよびアセット3Dフォーマット（1501）（図13の3Dフォーマットの没入型メディアおよびアセット（1301）に対応する）におけるニューラルネットワークモデル情報のキャリッジを示す。取り込まれた没入型メディアおよびアセット3Dフォーマット（1501）は、（1502）として示されるシーン1からNを指す。各シーン（1502）は、ジオメトリ（1503）および処理パラメータ（1504）を指す。ジオメトリ（1503）は、ニューラルネットワークモデルへの参照（1503A）を含むことができる。処理パラメータ（1504）はまた、ニューラルネットワークモデルへの参照（1504A）を含むことができる。（1504A）および（1503A）の両方は、シーンと共に直接記憶されたネットワークモデル、または取り込まれたメディアの外部に存在するニューラルネットワークモデル、例えば、図9の（901A）に記憶されたネットワークモデルを指す識別子を指すことができる。

本開示における様々なモジュールは、個々のデバイスであってもよく、またはデバイス内の構成要素であってもよいことに留意されたい。いくつかの例では、モジュールは個々のデバイスとすることができ、他のデバイスと結合され得る。いくつかの例では、モジュールは処理回路とすることができ、他の処理回路と相互接続され得る。いくつかの例では、モジュールはソフトウェア命令モジュールとすることができ、1つまたは複数のプロセッサによって実行され得る。

本開示のいくつかの態様は、メディア配信ネットワークのクライアントインターフェース（すなわち、サーバデバイスとも称される）がクライアントプレゼンテーションエンドポイント（すなわち、クライアントデバイスとも称される）と直接通信することを可能にする双方向メッセージを有する双方向プロトコルを提供する。いくつかの例では、双方向プロトコルを使用して、サーバデバイスは、クライアントデバイスのクライアント固有の特性およびサポートされる機能に関する情報を取得することができる。いくつかの例では、双方向プロトコルを使用して、サーバデバイスは、クライアントデバイスへのメディアのアダプテーションおよび配信のための固有のセッションおよび動作コンテキストを確立することによって、クライアントデバイスへのメディアの配信を管理することができる。いくつかの例では、双方向プロトコルを使用して、サーバデバイスは、クライアントデバイスが特定のメディアの提示において、例えば計算またはストレージのためにクライアントデバイスのリソースを補うためにネットワークに依存する必要があるときまたは場合に、セッション中の状況に応答することができる。いくつかの例では、双方向プロトコルは、クライアントデバイスの能力に一致するように入力メディアのアダプテーションプロセスにおいてサーバデバイスを支援することができる。いくつかの例では、双方向プロトコルは、そのような再使用がコンテンツ制作者、例えばスタジオまたはクライアントデバイスによって許可された場合、または許可された場合に、複数のクライアントデバイスにわたって提示するための特定のメディアアセットの効率的な再使用を可能にすることができる。いくつかの例では、双方向プロトコルを使用して、サーバデバイスは、ネットワークオペレータ（無線サービスプロバイダ、無線キャリア、モバイルネットワークキャリアとしても知られている）とクライアントデバイスとの間の既存のサービスレベルアグリーメントに従って、クライアントデバイスによるメディアのほぼリアルタイムの提示を容易にすることができる。いくつかの例では、双方向プロトコルを使用して、サーバデバイスは、アプリケーションの要件、例えば、インタラクティブゲーム対線形受動的視聴体験に従って、クライアントデバイスのほぼリアルタイムのメディアの提示を容易にすることができる。

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

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

図16A～図16Cは、いくつかの例では、サーバデバイス（例えば、図8にクライアントインターフェースモジュール（805）として示されている）とクライアントデバイス（例えば、図8に没入型クライアント（808）として示されている）との間で交換され得るメッセージのリストを提供する。いくつかの例では、メッセージのリストは、サーバデバイスから発信され、クライアントデバイスに送信されたメッセージおよび情報（806）を含むことができ、クライアントデバイスから発信され、サーバデバイスに送信されたフィードバックおよびステータス（807）を含むことができる。

図16A～図16Bは、サーバデバイスからクライアントデバイスへ送信される第1のメッセージグループ（1から20までの番号が付されたメッセージ）を示しており、図16Cは、いくつかの実施形態による、クライアントデバイスからサーバデバイスへ送信される第2のメッセージグループ（21から31までの番号が付されたメッセージ）を示す。

図17A～図17Gは、いくつかの例におけるメッセージの第1のグループについての意味情報の表を示す。図18は、いくつかの例におけるメッセージの第2のグループについての意味情報の表を示す。

なお、図16A～図16C、図17A～図17G、および図18のメッセージは例示のためのものである。双方向プロトコルのメッセージは、修正および／または省略され得る。追加のメッセージが追加され得る。

図19は、いくつかの例における双方向プロトコルの使用を例示するためのメディアシステム（1900）のブロック図を示す。いくつかの例では、双方向プロトコルは、図16A～図16C、図17A～図17G、および図18のメッセージを含むことができる。

メディアシステム（1900）は、没入型メディアアプリケーション、拡張現実（AR）アプリケーション、仮想現実アプリケーション、ビデオゲームアプリケーション、スポーツゲームアニメーションアプリケーション、テレビ会議およびテレプレゼンスアプリケーション、メディアストリーミングアプリケーションなどの様々な使用アプリケーションで使用され得る。

メディアシステム（1900）は、サーバデバイス（1910）と、ネットワーク（図示せず）によって接続され得る、図19に示すクライアントデバイス（1960A）、（1960B）、（1960C）などの複数のメディアクライアントデバイスとを含む。一例では、サーバデバイス（1910）は、没入型メディアコーディング機能を有する1つまたは複数のデバイスを含むことができる。一例では、サーバデバイス（1910）は、デスクトップコンピュータ、ラップトップコンピュータ、サーバコンピュータ、タブレットコンピュータなどの単一のコンピューティングデバイスを含む。他の例では、サーバデバイス（1910）は、データセンタ（複数可）、サーバファーム（複数可）などを含む。サーバデバイス（1910）は、没入型コンテンツ、ビデオコンテンツ、オーディオコンテンツなどの入力メディアコンテンツを受信することができる。クライアントデバイス（例えば、クライアントデバイス（1960A）、（1960B）、および（1960C））は、メディアアプリケーションのためのメディアプレゼンテーション機能を有する1つまたは複数のデバイスをそれぞれ含む。一例では、メディアクライアントデバイスは、デスクトップコンピュータ、ラップトップコンピュータ、サーバコンピュータ、タブレットコンピュータ、ヘッドマウントディスプレイ（HMD）デバイス、レンチキュラーライトフィールドディスプレイなどの提示デバイスを含むことができる。メディアクライアントデバイスは、いくつかの例では、適切なメディア提示フォーマットに従ってメディアを提示することができる。

サーバデバイス（1910）は、任意の適切な技術を使用して実装され得る。図19の例では、サーバデバイス（1910）は、互いに結合された処理回路（1930）およびインターフェース回路（1911）を含む。

処理回路（1930）は、1つまたは複数の中央処理装置（CPU）、1つまたは複数のグラフィックス処理装置（GPU）、特定用途向け集積回路などの任意の適切な処理回路を含むことができる。図19の例では、処理回路（1930）は、双方向プロトコルに従ってメッセージを形成するように構成され、双方向プロトコルに従ってメッセージを解釈することができる。さらに、処理回路（1930）は、メディアコンテンツを搬送するメディアストリームを生成することができる。メディアストリームは、サーバデバイス（1910）とメディアクライアントデバイスとの間で交換されるメッセージに基づいて適合され得る。

インターフェース回路（1911）は、サーバデバイス（1910）をネットワークとインターフェース接続することができる。インターフェース回路（1911）は、ネットワークから信号を受信する受信部分と、ネットワークに信号を送信する送信部分と、を含むことができる。例えば、インターフェース回路（1911）は、ネットワークを介してクライアントデバイス（1960A）、クライアントデバイス（1960B）、クライアントデバイス（1960C）などの他のデバイスにメッセージを搬送する信号を送信することができる。インターフェース回路（1911）は、クライアントデバイス（1960A）、（1960B）、および（1960C）などのメディアクライアントデバイスからメッセージを搬送する信号を受信することができる。

ネットワークは、イーサネット接続、光ファイバ接続、WiFi接続、セルラネットワーク接続などの有線および／または無線接続を介してサーバデバイス（1910）およびクライアントデバイス（例えば、クライアントデバイス（1960A）、（1960B）、および（1960C））と適切に結合される。

クライアントデバイス（例えば、クライアントデバイス（1960A）、（1960B）、および（1960C））は、双方向プロトコルを使用するメディアプレゼンテーションおよび双方向通信のためにそれぞれ構成される。

クライアントデバイス（1960A）、（1960B）、および（1960B）などのメディアクライアントデバイスは、任意の適切な技術を使用して実装され得る。図19の例では、クライアントデバイス（1960A）および（1960B）は、限定はしないが、ユーザAおよびユーザBなどのそれぞれのユーザによって使用され得るユーザ機器としてイヤホンを備えたヘッドマウントディスプレイ（HMD）が示されている。クライアントデバイス（1960C）は、複数のユーザまで同時に見ることができるコンテンツを表示することができ、表示されているコンテンツの自分自身の固有の視点（すなわち、ビュー）を各ユーザが体験している、レンチキュラーライトフィールドディスプレイが示されているが、これに限られるものではない。

図19において、クライアントデバイス（1960A）は、図19に示すように互いに結合されたインターフェース回路（1961A）および処理回路（1970A）を含む。クライアントデバイス（1960B）は、図19に示すように、互いに結合されたインターフェース回路（1961B）および処理回路（1970B）を含む。クライアントデバイス（1960C）は、図19に示すように、互いに結合されたインターフェース回路（1961C）および処理回路（1970C）を含む。

インターフェース回路（1961A）は、クライアントデバイス（1960A）をネットワークとインターフェース接続することができる。インターフェース回路（1961A）は、ネットワークから信号を受信する受信部分と、ネットワークに信号を送信する送信部分と、を含むことができる。例えば、インターフェース回路（1961A）は、サーバデバイス（1910）からメッセージを搬送する信号を受信することができ、サーバデバイス（1910）にメッセージを搬送する信号を送信することができる。

処理回路（1970A）は、CPU、GPU、特定用途向け集積回路などの適切な処理回路を含むことができる。処理回路（1970A）は、メディアデコーダ、レンダリングなどの様々な構成要素を含むように構成され得る。

同様に、インターフェース回路（1961B）は、クライアントデバイス（1960B）をネットワークとインターフェース接続することができる。インターフェース回路（1961B）は、ネットワークから信号を受信する受信部分と、ネットワークに信号を送信する送信部分と、を含むことができる。例えば、インターフェース回路（1961B）は、サーバデバイス（1910）からメッセージを搬送する信号を受信することができ、サーバデバイス（1910）にメッセージを搬送する信号を送信することができる。

処理回路（1970B）は、CPU、GPU、特定用途向け集積回路などの適切な処理回路を含むことができる。処理回路（1970B）は、メディアデコーダ、レンダリングなどの様々な構成要素を含むように構成され得る。

同様に、インターフェース回路（1961C）は、クライアントデバイス（1960C）をネットワークとインターフェース接続することができる。インターフェース回路（1961C）は、ネットワークから信号を受信する受信部分と、ネットワークに信号を送信する送信部分と、を含むことができる。例えば、インターフェース回路（1961C）は、サーバデバイス（1910）からメッセージを搬送する信号を受信することができ、サーバデバイス（1910）にメッセージを搬送する信号を送信することができる。

処理回路（1970C）は、CPU、GPU、特定用途向け集積回路などの適切な処理回路を含むことができる。処理回路（1970C）は、メディアデコーダ、レンダリングなどの様々な構成要素を含むように構成され得る。

いくつかの例では、双方向プロトコルを使用して、サーバデバイス（1910）は、クライアントデバイス（1960A）、（1960B）、および（1960C）のクライアント固有の特性およびサポートされる機能に関する情報を取得することができる。一例では、サーバデバイス（1910）は、それぞれのメディアクライアントデバイスから情報を要求するために、クライアントデバイス（1960A）、（1960B）、および（1960C）へのそれぞれのメッセージを生成することができる。情報は、メディアクライアントデバイスのコンピューティングリソース、メディアクライアントデバイスのストレージリソース、ネットワークサービスプロバイダとメディアクライアントデバイスとのサービスレベルアグリーメント、メディアクライアントデバイスの没入型アプリケーション要件、メディアクライアントデバイスのタイプ、メディアクライアントデバイスのモデル、クライアントデバイスにおけるニューラルネットワークモデルを含むことができるが、これらに限られるものではない。クライアントデバイス（1960A）、（1960B）、および（1960C）は、サーバデバイス（1910）からの受信メッセージに応じて、要求された情報を提供することができる。いくつかの例では、クライアントデバイス（1960A）、（1960B）、および（1960C）は、要求されることなく自発的にクライアント固有の特性およびサポートされる機能を提供することができる。

いくつかの例では、双方向プロトコルを使用して、サーバデバイス（1910）は、メディアクライアントデバイスへのメディアのアダプテーションおよび配信のための固有のセッションおよび動作コンテキストを確立することによって、メディアクライアントデバイスへのメディアの配信を管理することができる。いくつかの例では、双方向プロトコルは、メディアクライアントデバイスの能力と一致するように入力メディアのアダプテーションプロセスにおいてメディアサーバデバイス（1910）を支援することができる。

例えば、サーバデバイス（1910）は、双方向プロトコルに従ってサーバデバイス（1910）とクライアントデバイス（1960A）との間のメッセージに基づいてクライアントデバイス（1960A）との第1の固有のセッションを確立することができる。サーバデバイス（1910）は、クライアントデバイス（1960A）の能力と一致するように入力メディアから適合された第1のメディアストリームを生成することができる。第1の固有のセッションは、第1のメディアストリームをクライアントデバイス（1960A）に提供することができる。

サーバデバイス（1910）は、双方向プロトコルに従ってサーバデバイス（1910）とクライアントデバイス（1960B）との間のメッセージに基づいてクライアントデバイス（1960B）と第2の固有のセッションを確立することができる。サーバデバイス（1910）は、クライアントデバイス（1960B）の能力と一致するように入力メディアから適合された第2のメディアストリームを生成することができる。第2の固有のセッションは、第2のメディアストリームをクライアントデバイス（1960B）に提供することができる。

サーバデバイス（1910）は、双方向プロトコルに従ってサーバデバイス（1910）とクライアントデバイス（1960C）との間のメッセージに基づいてクライアントデバイス（1960C）との第3の固有のセッションを確立することができる。サーバデバイス（1910）は、クライアントデバイス（1960C）の能力と一致するように入力メディアから適合された第3のメディアストリームを生成することができる。第3の固有のセッションは、第3のメディアストリームをクライアントデバイス（1960C）に提供することができる。

いくつかの例では、双方向プロトコルを使用して、サーバデバイス（1910）は、特定のメディアの提示において、メディアクライアントデバイスが、例えば計算またはストレージのために、クライアントデバイスのリソースを補うためにネットワークに依存する必要があるときまたは場合に、セッション中の状況に応答することができる。一例では、第2のセッション中、クライアントデバイス（1960B）は、クライアントデバイス（1960B）がコンピューティングリソース（例えば、レンダリングのためのコンピューティングリソース）を補うためにネットワークに依存する必要があることをサーバデバイス（1910）に通知する。サーバデバイス（1910）は、クライアントデバイス（1960B）に補足コンピューティングリソースを提供することを決定することができる。

いくつかの例では、双方向プロトコルは、そのような再使用がコンテンツ制作者、例えばスタジオまたはクライアントデバイスによって許可されたとき、または許可されたならば、複数のクライアントデバイスにわたって提示するための特定のメディアアセットの効率的な再使用を可能にすることができる。一例では、サーバデバイス（1910）は、クライアントデバイス（1960A）のメディアアセットをクライアントデバイス（1960B）に再利用することを決定することができる。例えば、サーバデバイス（1910）は、クライアントデバイス（1960A）から（例えば、ストレージ（1901）の）キャッシュ内のレンダリングされたメディアアセットの情報を取得し、その情報をクライアントデバイス（1960B）に提供することができる。次に、クライアントデバイス（1960B）は、情報に従ってレンダリングされたメディアアセットのキャッシュにアクセスすることができる。

いくつかの例では、双方向プロトコルを使用して、サーバデバイス（1910）は、ネットワークオペレータ（無線サービスプロバイダ、無線キャリア、モバイルネットワークキャリアとしても知られている）とメディアクライアントデバイスとの間の既存のサービスレベルアグリーメントに従って、メディアクライアントデバイスによるメディアのほぼリアルタイムの提示を容易にすることができる。一例では、サーバデバイス（1910）は、クライアントデバイス（1960A）のサービスレベルアグリーメントが高解像度でのメディアデータのほぼリアルタイムの提示をサポートしているが、クライアントデバイス（1960B）のサービスレベルアグリーメントは高解像度でのメディアデータのほぼリアルタイムの提示をサポートしていないと判定することができる。サーバデバイス（1910）は、クライアントデバイス（1960B）がほぼリアルタイムで提示されるのを容易にするために、より低い解像度のメディアを有する第2のメディアストリームを提供することを決定することができる。

いくつかの例では、双方向プロトコルを使用して、サーバデバイス（1910）は、アプリケーションの要件、例えば、インタラクティブゲーム対線形受動的視聴体験に従って、クライアントデバイスのほぼリアルタイムのメディアの提示を容易にすることができる。一例では、サーバデバイス（1910）は、クライアントデバイス（1960A）がインタラクティブゲームに能動的に参加していると判定することができ、次いで、インタラクティブゲームの要件に適合された第1のメディアストリームを提供することができる。サーバデバイス（1910）は、クライアントデバイス（1960B）がリニアパッシブ視聴体験を有する映画アプリケーション内にあると判定することができ、リニアパッシブ視聴体験に適合された第2のメディアストリームを提供することができる。

図20は、本開示の一実施形態によるプロセス（2000）を概説するフローチャートを示す。プロセス（2000）は、サーバデバイス（1910）などのサーバデバイスで使用され得る。様々な実施形態において、プロセス（2000）は、サーバデバイス（1910）内の処理回路（1930）などの処理回路によって実行される。いくつかの実施形態では、プロセス（2000）はソフトウェア命令で実施され、したがって、処理回路がソフトウェア命令を実行すると、処理回路はプロセス（2000）を行う。プロセスは（S2001）から開始し、（S2010）に進む。

（S2010）において、クライアントデバイスの1つまたは複数の特定の特性を受信することをサーバデバイスに保証する第1の複数のメッセージは、没入型メディアコンテンツ配信のための双方向プロトコルを使用してクライアントデバイスと交換される。

一例では、1つまたは複数の特定の特性は、クライアントデバイスのコンピューティングリソースと、クライアントデバイスのストレージリソースと、クライアントデバイスにおけるネットワークサービスプロバイダのサービスレベルアグリーメントと、没入型アプリケーション要件と、クライアントデバイスのタイプと、クライアントデバイスのモデルと、クライアントデバイスにおけるニューラルネットワークモデルと、のうちの少なくとも1つを含む。

一例では、サーバデバイスはクライアントデバイスから第1のメッセージを受信し、第1のメッセージはクライアントデバイスの1つまたは複数の特定の特性を搬送する。次いで、サーバデバイスは第2のメッセージをクライアントデバイスに送信し、第2のメッセージはサーバデバイスの確認応答を搬送する。

他の例では、サーバデバイスは、第1のメッセージをクライアントデバイスに送信し、第1のメッセージは、クライアントデバイスの1つまたは複数の特定の特性に対する要求を搬送する。次いで、サーバデバイスは、クライアントデバイスから第2のメッセージを受信し、第2のメッセージは、クライアントデバイスの1つまたは複数の特定の特性を搬送する。

（S2020）において、メディアコンテンツを搬送するメディアストリームが生成される。メディアストリームは没入型コンテンツを含み、クライアントデバイスの1つまたは複数の特定の特性に従って適合される。

（S2030）において、メディアストリームは、双方向プロトコルを使用してクライアントデバイスに提供される。

いくつかの例では、クライアントデバイスは第1のクライアントデバイスであり、メディアストリームは第1のメディアストリームである。サーバデバイスは、第2のクライアントデバイスと、没入型メディアのための双方向プロトコルを使用して、サーバデバイスが第2のクライアントデバイスの1つまたは複数の特定の特性を受信することを保証する第2の複数のメッセージを交換することができる。サーバデバイスは、メディアコンテンツを搬送する第2のメディアストリームを生成することができる。第2のメディアストリームは、第2のクライアントデバイスの1つまたは複数の特定の特性に従って適合される。サーバデバイスは、双方向プロトコルを使用して第2のメディアストリームを第2のクライアントデバイスに送信することができる。

いくつかの例では、クライアントデバイスは第1のクライアントデバイスであり、サーバデバイスは、第1のクライアントデバイスと、没入型メディアのための双方向プロトコルを使用して、サーバデバイスが第2のクライアントデバイスとメディアコンテンツを共有することを可能にする第2の複数のメッセージを交換する。一例では、サーバデバイスは、サーバデバイスからの要求に応じて、共有可能なアセットのタイプのリストと、不変ストレージにキャッシュされているアセットの統一リソース識別子（URI）とを受信する。他の例では、サーバデバイスは、サーバデバイスからの要求に応じて、第1のクライアントデバイスによってアクセス可能な各アセットのステータス更新を受信する。他の例では、サーバデバイスは、サーバデバイスからの要求に応じて、特定のアセットタイプの現在の状態と、特定のサーバ割り当て識別子と特定のアセットの統一リソース識別子（URI）のいずれかを受信する。いくつかの例では、サーバデバイスは、第2のクライアントデバイスが共有可能なアセットにアクセスすることを可能にするために、共有可能なアセットの情報を第2のクライアントデバイスに提供することができる。

次に、（S2099）に進み、プロセスを終了する。

プロセス（2000）は、適切に適合され得る。プロセス（2000）のステップは、変更および／または省略され得る。追加のステップが追加され得る。任意の適切な実施順序が使用され得る。

図21は、本開示の一実施形態によるプロセス（2100）の概要を示すフローチャートを示す。プロセス（2100）は、クライアントデバイス（1960A）、クライアントデバイス（1960B）、クライアントデバイス（1960C）などのクライアントデバイスで使用され得る。様々な実施形態において、プロセス（2100）は、処理回路（1970A）、処理回路（1970B）、処理回路（1970C）などの処理回路によって実行される。いくつかの実施形態では、プロセス（2100）はソフトウェア命令内に実装され、したがって、処理回路がソフトウェア命令を実行すると、処理回路はプロセス（2100）を行う。プロセスは（S2101）から始まり、（S2110）に進む。

（S2110）において、クライアントデバイスは、サーバデバイスと、没入型メディアのための双方向プロトコルを使用して、サーバデバイスがクライアントデバイスの1つまたは複数の特定の特性を受信することを保証する第1の複数のメッセージを交換する。

いくつかの例では、1つまたは複数の特定の特性は、クライアントデバイスのコンピューティングリソースと、クライアントデバイスのストレージリソースと、クライアントデバイスにおけるネットワークサービスプロバイダのサービスレベルアグリーメントと、没入型アプリケーション要件と、クライアントデバイスのタイプと、クライアントデバイスのモデルと、クライアントデバイスにおけるニューラルネットワークモデルと、のうちの少なくとも1つを含む。

一例では、クライアントデバイスは、クライアントデバイスの1つまたは複数の特定の特性をサーバデバイスに通知するために第1のメッセージを送信し、サーバデバイスの確認応答のための第2のメッセージを受信する。他の例では、クライアントデバイスは、クライアントデバイスの1つまたは複数の特定の特性を提供する要求の第1のメッセージを受信し、クライアントデバイスの1つまたは複数の特定の特性をサーバデバイスに通知するために第2のメッセージを送信する。

（S2120）において、クライアントデバイスは、サーバデバイスから双方向プロトコルを使用して、メディアコンテンツを搬送するメディアストリームを受信する。メディアストリームは没入型コンテンツを含み、クライアントデバイスの1つまたは複数の特定の特性に従って適合される。

一例では、クライアントデバイスは、例えばプッシュケースにおいて、サーバデバイスからクライアントデバイスへの要求に応じてメディアストリームを受信する。他の例では、クライアントデバイスは、例えばプルケースにおいて、クライアントデバイスからサーバデバイスへの要求に応じてメディアストリームを受信する。

（S2130）において、クライアントデバイスがメディアストリームからメディアコンテンツを提示する。

いくつかの例では、クライアントデバイスは第1のクライアントデバイスである。第1のクライアントデバイスは、サーバデバイスと、没入型メディアのための双方向プロトコルを使用して、サーバデバイスが第2のクライアントデバイスとメディアコンテンツを共有することを可能にする第2の複数のメッセージを交換することができる。一例では、第1のクライアントデバイスは、サーバデバイスからの要求に応じて、共有可能なアセットのタイプのリストと、不変ストレージにキャッシュされているアセットの統一リソース識別子（URI）とを提供する。他の例では、第1のクライアントデバイスは、サーバデバイスからの要求に応じて、第1のクライアントデバイスによってアクセス可能な各アセットのステータス更新を提供する。他の例では、第1のクライアントデバイスは、サーバデバイスからの要求に応じて、特定のアセットタイプの現在の状態と、特定のサーバ割り当て識別子および特定のアセット統一リソース識別子（URI）のうちの1つとを提供する。サーバデバイスは、共有可能なアセットの情報を第2のクライアントデバイスに提供することができ、したがって、第2のクライアントデバイスは、それに応じて共有可能なアセットにアクセスすることができる。

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

プロセス（2100）は適切に適合され得る。プロセス（2100）のステップは、修正および／または省略することができる。追加のステップが追加され得る。任意の適切な実施順序が使用され得る。

上記で説明した技術は、コンピュータ可読命令を使用するコンピュータソフトウェアとして実装され、1つまたは複数のコンピュータ可読媒体に物理的に記憶され得る。例えば、図22は、開示の主題の特定の実施形態を実施するのに適したコンピュータシステム（2200）を示す。

コンピュータソフトウェアは、1つまたは複数のコンピュータ中央処理装置（CPU）およびグラフィック処理装置（GPU）などによって直接的に、または解釈およびマイクロコードの実行などを通して実行され得る命令を含むコードを生成するために、アセンブリ、コンパイル、リンキング、または同様のメカニズムを受け得る任意の適切なマシンコードまたはコンピュータ言語を使用して符号化され得る。

命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲームデバイス、モノのインターネットデバイスなどを含む、様々なタイプのコンピュータまたはその構成要素で実行され得る。

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

コンピュータシステム（2200）は、特定のヒューマンインターフェース入力デバイスを含み得る。そのようなヒューマンインターフェース入力デバイスは、例えば、触覚入力（キーストローク、スワイプ、データグローブの動きなど）、オーディオ入力（音声、拍手など）、ビジュアル入力（ジェスチャなど）、嗅覚入力（図示せず）を介して、1人または複数の人間のユーザによる入力に反応するものでありうる。ヒューマンインターフェースデバイスは、音声（発話、音楽、周囲音など）、画像（スキャン画像、静止画像カメラから取得される写真画像など）、ビデオ（2次元ビデオ、立体ビデオを含む3次元ビデオなど）など、人間による意識的な入力に必ずしも直接関係ない特定のメディアをキャプチャするために使用され得る。

入力ヒューマンインターフェースデバイスには、キーボード（2201）、マウス（2202）、トラックパッド（2203）、タッチスクリーン（2210）、データグローブ（図示せず）、ジョイスティック（2205）、マイク（2206）、スキャナ（2207）、カメラ（2208）のうちの1つまたは複数が含まれることがある。

コンピュータシステム（2200）はまた、特定のヒューマンインターフェース出力デバイスを含み得る。そのようなヒューマンインターフェース出力デバイスは、例えば、触覚出力、音、光、および嗅覚／味覚を通して、1人または複数の人間のユーザの感覚を刺激してもよい。このようなヒューマンインターフェース出力デバイスは、触覚出力デバイス（例えば、タッチスクリーン（2210）、データグローブ（図示せず）、またはジョイスティック（2205）による触覚フィードバックが含まれることがあるが、入力デバイスとして機能しない触覚フィードバックデバイスもあり得る）、オーディオ出力デバイス（スピーカ（2209）、ヘッドホン（図示せず）など）、ビジュアル出力デバイス（それぞれがタッチスクリーン入力機能の有無にかかわらず、それぞれが触覚フィードバック機能の有無にかかわらず、CRTスクリーン、LCDスクリーン、プラズマスクリーン、OLEDスクリーンを含むスクリーン（2210）など、それらの一部は、ステレオグラフィック出力、仮想現実ガラス（図示せず）、ホログラフィックディスプレイおよびスモークタンク（図示せず）などの手段を通じて2次元視覚出力または3次元以上の出力が可能であり得る）およびプリンタ（図示せず）を含んでもよい。

コンピュータシステム（2200）は、CD／DVDまたは同様の媒体（2221）を有するCD／DVD ROM／RW（2220）を含む光学媒体、サムドライブ（2222）、リムーバブルハードドライブまたはソリッドステートドライブ（2223）、テープおよびフロッピーディスクなどのレガシー磁気媒体（描写せず）、セキュリティドングルなどの特殊なROM／ASIC／PLDベースのデバイス（描写せず）などの、人間がアクセス可能なストレージデバイスおよびそれらに関連する媒体を含むこともできる。

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

コンピュータシステム（2200）はまた、1つまたは複数の通信ネットワーク（2255）へのインターフェース（2254）を含むことができる。ネットワークは、例えば、ワイヤレス、有線、光であり得る。ネットワークはさらに、ローカル、広域、メトロポリタン、車両および産業用、リアルタイム、遅延耐性などであり得る。ネットワークの例は、イーサネット、ワイヤレスLANなどのローカルエリアネットワーク、GSM、3G、4G、5G、LTEなどを含むセルラネットワーク、ケーブルテレビ、衛星テレビ、および地上放送テレビを含むテレビ有線または無線広域デジタルネットワーク、CANBusを含む車両および産業などを含む。特定のネットワークは通常、特定の一般データポートまたは周辺バス（2249）に取り付けられる外部ネットワークインターフェースアダプタを必要とする（例えば、コンピュータシステム（2200）のUSBポート）、その他は一般に、以下に説明するようにシステムバスに接続することによってコンピュータシステム（2200）のコアに統合される（例えば、PCコンピュータシステムへのイーサネットインターフェースまたはスマートフォンコンピュータシステムへのセルラーネットワークインターフェースなど）。これらのネットワークのいずれかを使用して、コンピュータシステム（2200）は他のエンティティと通信できる。このような通信は、一方向、受信のみ（例えば、テレビ放送）、一方向の送信のみ（例えば、特定のCANbusデバイスへのCANbus）、または双方向、例えば、ローカルまたはワイドエリアデジタルネットワークを使用する他のコンピュータシステムへの通信であり得る。特定のプロトコルおよびプロトコルスタックは、上記で説明したように、それらのネットワークおよびネットワークインターフェースのそれぞれで使用され得る。

前述のヒューマンインターフェースデバイス、ヒューマンアクセス可能なストレージデバイス、およびネットワークインターフェースは、コンピュータシステム（2200）のコア（2240）に接続され得る。

コア（2240）は、1つまたは複数の中央処理装置（CPU）（2241）、グラフィック処理装置（GPU）（2242）、フィールドプログラマブルゲートエリア（FPGA）（2243）の形態の専用プログラマブル処理装置、特定のタスク用のハードウェアアクセラレータ（2244）、グラフィックアダプタ（2250）などを含むことができる。これらのデバイスは、読み取り専用メモリ（ROM）（2245）、ランダムアクセスメモリ（2246）、ユーザがアクセスできない内蔵ハードドライブなどの内部大容量ストレージデバイス、SSDなど（2247）と共にシステムバス（2248）を介して接続されてもよい。一部のコンピュータシステムでは、追加のCPU、GPUなどによる拡張を可能にするために、1つまたは複数の物理プラグの形式でシステムバス（2248）にアクセス可能である。周辺デバイスは、コアのシステムバス（2248）に直接接続されても、周辺バス（2249）を介して接続されてもよい。一例では、スクリーン（2210）はグラフィックアダプタ（2250）に接続され得る。周辺バスのアーキテクチャは、PCI、USBなどを含む。

CPU（2241）、GPU（2242）、FPGA（2243）、およびアクセラレータ（2244）は、組み合わせて前述のコンピュータコードを構成できる特定の命令を実行できる。そのコンピュータコードは、ROM（2245）またはRAM（2246）に格納され得る。移行データはRAM（2246）に格納することもできるが、恒久的データは例えば内部大容量ストレージ（2247）に格納され得る。任意のメモリデバイスの高速ストレージおよび検索は、1つまたは複数のCPU（2241）、GPU（2242）、大容量ストレージ（2247）、ROM（2245）、RAM（2246）などに密接に関連付けられ得るキャッシュメモリの使用を通じて可能にされ得る。

コンピュータ可読媒体は、様々なコンピュータ実施動作を行うためのコンピュータコードを有し得る。媒体およびコンピュータコードは、本開示の目的のために特別に設計および構築されたものであり得るか、またはそれらは、コンピュータソフトウェア技術のスキルを有する人々に周知かつ利用可能な種類であり得る。

一例として、限定するものではないが、アーキテクチャを有するコンピュータシステム（2200）、具体的にはコア（2240）は、1つまたは複数の有形のコンピュータ可読媒体に組み込まれたソフトウェアを実行するプロセッサ（CPU、GPU、FPGA、アクセラレータなどを含む）の結果として機能を提供することができる。このようなコンピュータ可読媒体は、上記で紹介したユーザアクセス可能な大容量ストレージ、ならびにコア内部大容量ストレージ（2247）やROM（2245）などの非一時的な性質のコア（2240）の特定のストレージに関連付けられた媒体であり得る。本開示の様々な実施形態を実施するソフトウェアは、そのようなデバイスに格納され、コア（2240）によって実行され得る。コンピュータ可読媒体は、特定の必要性に応じて、1つまたは複数のメモリデバイスまたはチップを含むことができる。ソフトウェアは、コア（2240）、特にその中のプロセッサ（CPU、GPU、FPGAなどを含む）に、RAM（2246）に格納されたデータ構造を定義することと、ソフトウェアによって定義されたプロセスに従って、そのようなデータ構造を変更することとを含む、本明細書に記載の特定のプロセスまたは特定のプロセスの特定の部分を実行させることができる。加えて、または代替として、コンピュータシステムは、本明細書に記載の特定のプロセスまたは特定のプロセスの特定の部分を実行するために、ソフトウェアの代わりにまたはソフトウェアと一緒に動作することができる回路（例えば、アクセラレータ（2244））に論理配線された、あるいは具体化された結果として機能を提供することができる。ソフトウェアへの参照にはロジックを含めることができ、必要に応じてその逆も可能である。必要に応じて、コンピュータ可読媒体への言及は、実行のためのソフトウェアを記憶する回路（集積回路（IC）など）、実行のためのロジックを具体化する回路、またはこれらの両方を包含し得る。本開示は、ハードウェアとソフトウェアの任意の適切な組合せを包含する。

本開示はいくつかの例示的な実施形態を説明してきたが、本開示の範囲内にある修正例、置換例、および様々な代替均等例がある。したがって、当業者は、本明細書に明示的に図示または記載されていないが、本開示の原理を具現化し、したがって、その趣旨および範囲内にある多数のシステムおよび方法を考案できることが諒解されよう。

100 エンドツーエンドプロセス
101A マイクロフォン
101B コンピュータ
103 準備モジュール
104 変換器モジュール
105 アダプテーションモジュール
107 アダプテーション
107A プル要求
107B プル要求
107C プル要求
108A クライアント
108B クライアント
108C クライアント
200 標準メディアフォーマット
203A 期間
203B 期間
204A アダプテーションセット
204B アダプテーションセット
204C アダプテーションセット
204D アダプテーションセット
204E アダプテーションセット
204F アダプテーションセット
205 表現
206 セグメントファイル
300 ストリーミング可能フォーマット
301 シーン
302 構成要素
303 アセット
304 ベース層
305 属性強化層
400 ストリーミング可能フォーマット
401 シーン
402 構成要素
403 アセット
404 ベース層
405 属性強化層
407 タイムドメディアシーン
411 シーン
500 プロセス
501 カメラユニット
502 カメラユニット
503 カメラユニット
504 合成モジュール
505 ニューラルネットワーク訓練モジュール
506 訓練画像
507 インジェストフォーマット
508 キャプチャニューラルネットワークモデル
509 自然画像コンテンツ
600 プロセス
601 LIDARカメラ
602 点群
603 コンピュータ
604 データ
605 行為者
605A センサ
606 モーションキャプチャ（MoCap）データ
607 合成モジュール
608 合成メディア
700 ネットワークメディア配信システム
701 コンテンツ取得モジュール
702 コンテンツ準備モジュール
703 送信モジュール
704 ゲートウェイ
705 セットトップボックス
706 無線復調器
707 レガシー2Dテレビ
708 WiFiルータ
709 レガシー2Dディスプレイ
710 ヘッドマウント2Dラスタベースディスプレイ
711 レンチキュラーライトフィールドディスプレイ
711A ローカル計算グラフィックス処理装置（GPU）
711B ストレージデバイス
711C ビジュアルプレゼンテーションユニット
712 ホログラフィックディスプレイ
712A ローカル計算中央処理装置（CPU）
712B GPU
712C ストレージデバイス
712D ホログラフィック視覚化ユニット
713 ディスプレイ
714 拡張現実ヘッドセット
714A GPU
714B ストレージデバイス
714C バッテリ
714D 体積ビジュアルプレゼンテーションコンポーネント
715 高密度ライトフィールドディスプレイ
715A GPU
715B CPU
715C ストレージデバイス
715D 視線追跡デバイス
715E カメラ
715F ライトフィールドパネル
800 没入型メディアネットワーク配信モジュール
801 モジュール
802 ネットワークインジェストフォーマット作成モジュール
803 ストレージデバイス
804 リモートストレージデバイス
805 クライアントインターフェースモジュール
806 記述情報、メディア、情報
807 クライアント進捗およびステータスフィードバックチャネル、サーバデバイスに送信されたフィードバックおよびステータス
808 没入型クライアント、クライアントデバイス
808A 視覚化コンポーネント
808B ネットワークインターフェース
808C GPU
808D ストレージキャッシュ
809 配信ストレージデバイス
810 フラグメンテーションモジュール
901 メディアアダプテーションモジュール
901A ニューラルネットワークモデル
901B レンダラ
901C ニューラルネットワークプロセッサ
901D メディア圧縮器
901E メディア解凍器
902 アセット
903 クライアントインターフェースモジュール
904 クライアント情報
905 入力ネットワークステータス
906 メディアストレージデバイス
1001 メディアアダプテーションモジュール
1002 メディアストレージデバイス
1003 メディアパッケージングモジュール
1004 配信フォーマット
1004A マニフェスト情報
1101 メディア
1102 パケット化器
1103 パケット
1104 クライアントエンドポイント
1201 クライアント
1202 ネットワーク配信インターフェース
1203 インジェストメディアサーバ
1204 アダプテーションインターフェース
1205 メディアアダプテーションモジュール
1206 パッケージングモジュール
1207 パッケージ化されたメディアサーバ
1208 メディア要求
1209 プロファイル要求
1210 応答
1211 セッションIDトークン
1212 インジェストメディア要求
1213 応答
1214 呼び出し
1215 ニューラルネットワークモデルトークン
1216 インジェストメディアトークン、要求
1217 応答
1218 要求
1220 インターフェース呼び出し
1221 応答メッセージ
1222 応答
1223 要求
1224 メッセージ
1301 3Dフォーマットの没入型メディアおよびアセット
1302 2Dフォーマット、ネットワーク配信インターフェース
1401 符号化ビデオストリーム
1401A SEIメッセージ
1401B 符号化ビデオストリーム
1402 符号化ビデオストリーム
1402A パラメータ
1402B 符号化ビデオビットストリーム
1501 アセット3Dフォーマット
1502 シーン
1503 ジオメトリ
1504 処理パラメータ
1900 メディアシステム
1901 ストレージ
1910 メディアサーバデバイス
1911 インターフェース回路
1930 処理回路
1960A クライアントデバイス
1960B クライアントデバイス
1960C クライアントデバイス
1961A インターフェース回路
1961B インターフェース回路
1961C インターフェース回路
1970A 処理回路
1970B 処理回路
1970C 処理回路
2000 プロセス
2100 プロセス
2200 コンピュータシステム
2201 キーボード
2202 マウス
2203 トラックパッド
2205 ジョイスティック
2206 マイク
2207 スキャナ
2208 カメラ
2209 オーディオ出力デバイススピーカ
2210 タッチスクリーン
2221 媒体
2222 サムドライブ
2223 ソリッドステートドライブ
2240 コア
2243 フィールドプログラマブルゲートエリア（FPGA）
2244 ハードウェアアクセラレータ
2245 読み取り専用メモリ（ROM）
2246 ランダムアクセスメモリ
2247 コア内部大容量ストレージ
2248 システムバス
2249 周辺バス
2250 グラフィックアダプタ
2254 インターフェース
2255 通信ネットワーク

図12に示す構成要素および通信は以下のように説明される：クライアント（1201）（いくつかの例ではクライアントエンドポイントとも称される）は、ネットワーク配信インターフェース（1202）へのメディア要求（1208）を開始する。メディア要求（1208）は、URNまたは他の標準的な命名法のいずれかによってクライアント（1201）によって要求されたメディアを識別するための情報を含む。ネットワーク配信インターフェース（1202）は、クライアント（1201）がその現在利用可能なリソース（クライアントの現在の動作ステータスを特徴付けるための計算、ストレージ、バッテリ充電率、および他の情報を含む）に関する情報を提供することを要求するプロファイル要求（1209）を用いてメディア要求（1208）に応答する。プロファイル要求（1209）はまた、ニューラルネットワーク推論のためにネットワークによって使用されて正しいメディアビューを抽出または補間してクライアントのプレゼンテーションシステムの特徴に一致させられ得る1つまたは複数のニューラルネットワークモデルがクライアントにおいて利用可能である場合、そのようなモデルをクライアントが提供することを要求する。クライアント（1201）からネットワーク配信インターフェース（1202）への応答（1210）は、クライアントトークン、アプリケーショントークン、および1つまたは複数のニューラルネットワークモデルトークン（そのようなニューラルネットワークモデルトークンがクライアントで利用可能な場合）を提供する。次いで、ネットワーク配信インターフェース（1202）は、セッションIDトークン（1211）をクライアント（1201）に提供する。次いで、ネットワーク配信インターフェース（1202）は、要求（1208）で識別されたメディアのURNまたは標準命名法の名前を含むインジェストメディア要求（1212）を用いてインジェストメディアサーバ（1203）を要求する。インジェストメディアサーバ（1203）は、インジェストメディアトークンを含む応答（1213）で要求（1212）に応答する。次いで、ネットワーク配信インターフェース（1202）は、呼び出し（1214）における応答（1213）からのメディアトークンをクライアント（1201）に提供する。次いで、ネットワーク配信インターフェース（1202）は、アダプテーションインターフェース（1204）にインジェストメディアトークン、クライアントトークン、アプリケーショントークン、およびニューラルネットワークモデルトークン（1215）を提供することによって、メディア要求（1208）のアダプテーションプロセスを開始する。アダプテーションインターフェース（1204）は、インジェストメディアアセットへのアクセスを要求する呼び出し時のインジェストメディアトークン（1216）をインジェストメディアサーバ（1203）に提供することによって、インジェストメディアへのアクセスを要求する。インジェストメディアサーバ（1203）は、アダプテーションインターフェース（1204）に対する応答（1217）において、インジェストメディアアクセストークンを有する要求（1216）に応答する。次いで、アダプテーションインターフェース（1204）は、メディアアダプテーションモジュール（1205）が、（1213）において作成されたセッションIDトークンに対応するクライアント、アプリケーション、およびニューラルネットワーク推論モデルのためにインジェストメディアアクセストークンに位置するインジェストメディアを適合させることを要求する。アダプテーションインターフェース（1204）からメディアアダプテーションモジュール（1205）への要求（1218）は、必要なトークンとセッションIDとを含む。メディアアダプテーションモジュール（1205）は、ネットワーク配信インターフェース（1202）に、適合されたメディアアクセストークンおよび更新時のセッションID（1219）を提供する。ネットワーク配信インターフェース（1202）は、インターフェース呼び出し（1220）において、適合されたメディアアクセストークンおよびセッションIDをパッケージングモジュール（1206）に提供する。パッケージングモジュール（1206）は、応答メッセージ（1221）においてパッケージ化されたメディアアクセストークンおよびセッションIDと共に応答（1221）をネットワーク配信インターフェース（1202）に提供する。パッケージングモジュール（1206）は、応答（1222）において、セッションIDのためのパッケージ化されたアセット、URN、およびパッケージ化されたメディアアクセストークンをパッケージ化されたメディアサーバ（1207）に提供する。クライアント（1201）は、要求（1223）を実行して、応答メッセージ（1221）で受信したパッケージ化されたメディアアクセストークンに対応するメディアアセットのストリーミングを開始する。クライアント（1201）は、他の要求を実行し、メッセージ（1224）のステータス更新をネットワーク配信インターフェース（1202）に提供する。

Claims (20)

1. クライアントデバイスにおけるメディアストリーミングの方法であって、
   没入型メディア配信のための双方向プロトコルに従って、サーバデバイスが前記クライアントデバイスの1つまたは複数の特定の特性を受信することを保証する第1の複数のメッセージを前記サーバデバイスと交換するステップと、
   前記双方向プロトコルに従って、メディアコンテンツを搬送するメディアストリームを前記サーバデバイスから受信するステップであって、前記メディアストリームは、没入型コンテンツを含み、前記クライアントデバイスの前記1つまたは複数の特定の特性に従って適合される、ステップと、
   前記メディアストリームから前記メディアコンテンツを提示するステップと、
   を含む、方法。
2. 前記1つまたは複数の特定の特性は、
   前記クライアントデバイスのコンピューティングリソースと、
   前記クライアントデバイスのストレージリソースと、
   前記クライアントデバイスにおけるネットワークサービスプロバイダのサービスレベルアグリーメントと、
   没入型アプリケーション要件と、
   前記クライアントデバイスのタイプと、
   前記クライアントデバイスのモデルと、
   前記クライアントデバイスにおけるニューラルネットワークモデルと、
   のうちの少なくとも1つを含む、請求項1に記載の方法。
3. 前記第1の複数のメッセージを交換する前記ステップは、
   前記クライアントデバイスの前記1つまたは複数の特定の特性を前記サーバデバイスに通知するために第1のメッセージを送信するステップと、
   前記サーバデバイスの確認応答のための第2のメッセージを受信するステップと、
   を含む、請求項1に記載の方法。
4. 前記第1の複数のメッセージを交換する前記ステップは、
   前記クライアントデバイスの前記1つまたは複数の特定の特性を提供することを求める要求の第1のメッセージを受信するステップと、
   前記クライアントデバイスの前記1つまたは複数の特定の特性を前記サーバデバイスに通知するために第2のメッセージを送信するステップと、
   を含む、請求項1に記載の方法。
5. 前記メディアコンテンツを搬送する前記メディアストリームを受信する前記ステップは、
   前記サーバデバイスから前記クライアントデバイスへの要求に応じて前記メディアストリームを受信するステップと、
   前記クライアントデバイスから前記サーバデバイスへの要求に応じて前記メディアストリームを受信するステップと、
   のうちの少なくとも一方をさらに含む、請求項1に記載の方法。
6. 前記クライアントデバイスは第1のクライアントデバイスであり、前記方法は、
   前記双方向プロトコルに従って、前記サーバデバイスが第2のクライアントデバイスと前記メディアコンテンツを共有することを可能にする第2の複数のメッセージを前記サーバデバイスと交換するステップ
   をさらに含む、請求項1に記載の方法。
7. 前記第2の複数のメッセージを交換する前記ステップは、
   前記サーバデバイスからの要求に応じて、共有可能なアセットのタイプのリストと、不変ストレージにキャッシュされている前記アセットの統一リソース識別子（URI）と、を提供するステップ
   をさらに含む、請求項6に記載の方法。
8. 前記第2の複数のメッセージを交換する前記ステップは、
   前記サーバデバイスからの要求に応じて、前記第1のクライアントデバイスによってアクセス可能な各アセットのステータス更新を提供するステップ
   をさらに含む、請求項6に記載の方法。
9. 前記第2の複数のメッセージを交換する前記ステップは、
   前記サーバデバイスからの要求に応じて、特定のアセットタイプの現在の状態と、特定のサーバ割り当て識別子および特定のアセットの統一リソース識別子（URI）のうちの一方と、を提供するステップ
   をさらに含む、請求項6に記載の方法。
10. メディア処理のための装置であって、
    没入型メディア配信のための双方向プロトコルに従って、サーバデバイスが前記装置の1つまたは複数の特定の特性を受信することを保証する第1の複数のメッセージを前記サーバデバイスと交換し、
    前記双方向プロトコルに従って、メディアコンテンツを搬送するメディアストリームを前記サーバデバイスから受信し、前記メディアストリームは、没入型コンテンツを含み、前記装置の前記1つまたは複数の特定の特性に従って適合され、
    前記メディアストリームから前記メディアコンテンツを提示する
    ように構成される処理回路を備える、装置。
11. 前記1つまたは複数の特定の特性は、
    前記装置のコンピューティングリソースと、
    前記装置のストレージリソースと、
    前記装置におけるネットワークサービスプロバイダのサービスレベルアグリーメントと、
    没入型アプリケーション要件と、
    前記装置のタイプと、
    前記装置のモデルと、
    前記装置におけるニューラルネットワークモデルと、
    のうちの少なくとも1つを含む、請求項10に記載の装置。
12. 前記処理回路は、
    前記装置の前記1つまたは複数の特定の特性を前記サーバデバイスに通知するために第1のメッセージを送信し、
    前記サーバデバイスの確認応答のための第2のメッセージを受信する
    ように構成される、請求項10に記載の装置。
13. 前記処理回路は、
    前記装置の前記1つまたは複数の特定の特性を提供することを求める要求の第1のメッセージを受信し、
    前記装置の前記1つまたは複数の特定の特性を前記サーバデバイスに通知するために第2のメッセージを送信する
    ように構成される、請求項10に記載の装置。
14. 前記処理回路は、
    前記サーバデバイスから前記装置への要求と、
    前記装置から前記サーバデバイスへの要求と、
    の少なくとも一方に応じて、前記メディアストリームを受信するように構成される、請求項10に記載の装置。
15. 前記装置は第1のクライアントデバイスであり、前記処理回路は、
    前記双方向プロトコルに従って、前記サーバデバイスが第2のクライアントデバイスと前記メディアコンテンツを共有することを可能にする第2の複数のメッセージを前記サーバデバイスと交換する
    ように構成される、請求項10に記載の装置。
16. 前記処理回路は、
    前記サーバデバイスからの要求に応じて、共有可能なアセットのタイプのリストと、不変ストレージにキャッシュされている前記アセットの統一リソース識別子（URI）と、を提供する
    ように構成される、請求項15に記載の装置。
17. 前記処理回路は、
    前記サーバデバイスからの要求に応じて、前記第1のクライアントデバイスによってアクセス可能な各アセットのステータス更新を提供する
    ように構成される、請求項15に記載の装置。
18. 前記処理回路は、
    前記サーバデバイスからの要求に応じて、特定のアセットタイプの現在の状態と、特定のサーバ割り当て識別子および特定のアセットの統一リソース識別子（URI）のうちの一方と、を提供する
    ように構成される、請求項15に記載の装置。
19. クライアントデバイス内の少なくとも1つのプロセッサによって実行されると、前記クライアントデバイスに、
    没入型メディア配信のための双方向プロトコルに従って、サーバデバイスが前記クライアントデバイスの1つまたは複数の特定の特性を受信することを保証する第1の複数のメッセージを前記サーバデバイスと交換するステップと、
    前記双方向プロトコルに従って、メディアコンテンツを搬送するメディアストリームを前記サーバデバイスから受信するステップであって、前記メディアストリームは、没入型コンテンツを含み、前記クライアントデバイスの前記1つまたは複数の特定の特性に従って適合される、ステップと、
    前記メディアストリームから前記メディアコンテンツを提示するステップと、
    を実行させる命令を格納する、非一時的コンピュータ可読記憶媒体。
20. 前記クライアントデバイスは第1のクライアントデバイスであり、前記命令は、前記第1のクライアントデバイスに、
    前記双方向プロトコルに従って、前記サーバデバイスが第2のクライアントデバイスと前記メディアコンテンツを共有することを可能にする第2の複数のメッセージを前記サーバデバイスと交換するステップ
    を実行させる、請求項19に記載の非一時的コンピュータ可読記憶媒体。

Images