特表2024-510165資産フォーマットの転換のための即時メディアデータ複雑性アナライザ
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-03-06
(54)【発明の名称】資産フォーマットの転換のための即時メディアデータ複雑性アナライザ
(51)【国際特許分類】
H04N 21/24 20110101AFI20240228BHJP
H04N 21/845 20110101ALI20240228BHJP
【ＦＩ】
H04N21/24
H04N21/845
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2023555127
(86)(22)【出願日】2022-10-25
(85)【翻訳文提出日】2023-09-08
(86)【国際出願番号】 US2022047672
(87)【国際公開番号】W WO2023081037
(87)【国際公開日】2023-05-11
(31)【優先権主張番号】63/276,538
(32)【優先日】2021-11-05
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】17/969,226
(32)【優先日】2022-10-19
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】520353802
【氏名又は名称】テンセント・アメリカ・エルエルシー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】ヒンズ，アリアンヌ
(72)【発明者】
【氏名】アビシェーク，ロヒット
(72)【発明者】
【氏名】ウェンジャー，ステファン
【テーマコード（参考）】
5C164
【Ｆターム（参考）】
5C164MB11S
5C164MB43P
5C164SB01S
5C164SB41P
5C164SC01S
5C164YA21
(57)【要約】
少なくとも１つのプロセッサによって実行されるメディアストリーム（またはメディアデータ）中のシーンのオブジェクトの複雑性を分析することが提供され、コンテンツソースから複数のシーンを含む没入型メディアデータを受信することと、没入型メディアデータから複数のシーン内のそれぞれのシーンのそれぞれのオブジェクトを取得することと、それぞれのシーンのそれぞれのオブジェクトに関連する複雑性情報を生成するためにそれぞれのシーンを分析することと、それぞれのシーンのそれぞれのオブジェクトに関連するメタデータを生成することであって、メタデータは、複雑性情報を含む、メタデータを生成することと、生成されるメタデータに基づく処理のためにそれぞれのシーンをクライアントに配信するかどうかを決定することとを含む。
【特許請求の範囲】
【請求項1】
シーンのオブジェクトの複雑性を分析するために少なくとも１つのプロセッサによって実行される方法であって、コンテンツソースから複数のシーンを含む没入型メディアデータを受信することと、
前記没入型メディアデータから前記複数のシーン内のそれぞれのシーンのそれぞれのオブジェクトを取得することと、
前記それぞれのシーンの前記それぞれのオブジェクトと関連付けられる複雑性情報を生成するために前記それぞれのシーンを分析することと、
前記それぞれのシーンの前記それぞれのオブジェクトと関連付けられるメタデータを生成することであって、前記メタデータは、前記複雑性情報を含む、生成することと、
前記生成されるメタデータに基づく処理のために前記それぞれのシーンをクライアントに配信するかどうかを決定することと、を含む、
方法。
【請求項2】
前記それぞれのオブジェクトから属性情報を獲得することをさらに含む、請求項１に記載の方法。
【請求項3】
前記属性情報が事前定義された複雑性属性のリスト内の１つ以上の複雑性属性に関係するかどうかを識別することと、前記事前定義された複雑性属性の前記リスト内の前記１つ以上の複雑性属性に関連する少なくとも１つの値を導出することと、
前記属性情報と関連する前記少なくとも１つの値を格納すること、および前記それぞれのオブジェクトについての複雑性要約を生成することと、をさらに含む、
請求項２に記載の方法。
【請求項4】
前記それぞれのオブジェクトは、前記オブジェクトの基本表現と、オブジェクト強化層のセットとを含み、該オブジェクト強化層のセットは、前記オブジェクトの属性に対応する前記属性情報を含み、前記オブジェクト強化層のセットが、前記オブジェクトの前記基本表現に適用されるときに、前記オブジェクトの前記基本表現は、前記オブジェクトの前記基本表現を含む基本層において支持されない構成を含むように増強される、
請求項２に記載の方法。
【請求項5】
少なくとも１つのオブジェクトについての少なくとも１つの複雑性情報を前記それぞれのシーンについての複雑性要約に集約することであって、前記それぞれのシーンは、１つ以上のオブジェクトを含む、集約することと、前記それぞれのシーンについての前記複雑性要約を前記それぞれのシーンのビットストリーム内の事前定義された場所に書き込むことと、をさらに含む、
請求項３に記載の方法。
【請求項6】
前記それぞれのシーンに対応する前記没入型メディアデータのフォーマットが、前記それぞれのシーンについての前記複雑性要約に基づいて、クライアントデバイスへの配信前に、第１のフォーマットから第２のフォーマットに転換されるべきかどうかを決定することをさらに含む、請求項３に記載の方法。
【請求項7】
前記それぞれのシーンに対応する前記没入型メディアデータが転換されるべきであるという決定に基づいて、前記コンテンツソースまたは前記クライアントデバイスが前記第１のフォーマットから前記第２のフォーマットへの転換を実行するべきかどうかを決定することをさらに含む、請求項６に記載の方法。
【請求項8】
シーンのオブジェクトの複雑性を分析するためのデバイスであって、コンピュータプログラムコードを格納するように構成される少なくとも１つのメモリと、
前記コンピュータプログラムコードを読み出して、前記コンピュータプログラムコードによって命令されるように動作するように構成される、少なくとも１つのプロセッサと、を含み、前記コンピュータプログラムコードは、
前記少なくとも１つのプロセッサに、コンテンツソースから複数のシーンを含む没入型メディアデータを受信させるように構成される、受信コードと、
前記少なくとも１つのプロセッサに、前記没入型メディアデータから、前記複数のシーン内のそれぞれのシーンのそれぞれのオブジェクトを取得させるように構成される、取得コードと、
前記少なくとも１つのプロセッサに、前記それぞれのシーンの前記それぞれのオブジェクトと関連付けられる複雑性情報を生成させるために、前記それぞれのシーンを分析させるように構成される、分析コードと、
前記少なくとも１つのプロセッサに、前記それぞれのシーンの前記それぞれのオブジェクトと関連付けられるメタデータを生成させるように構成される、生成コードであって、前記メタデータは、前記複雑性情報を含む、生成コードと、
前記少なくとも１つのプロセッサに、前記生成されるメタデータに基づく処理のために、前記それぞれのシーンをクライアントに配信するかどうかを決定させる、決定コードと、を含む、
デバイス。
【請求項9】
前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサに、前記それぞれのオブジェクトから属性情報を獲得させるように構成される、獲得コードをさらに含む、請求項８に記載のデバイス。
【請求項10】
前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサに、前記属性情報が事前定義された複雑性属性のリスト内の１つ以上の複雑性属性に関連するかどうかを識別させるように構成される、識別コードと、
前記少なくとも１つのプロセッサに、前記事前定義された複雑性属性の前記リスト内の前記１つ以上の複雑性属性に関連する少なくとも１つの値を導出させるように構成される、導出コードと、
前記少なくとも１つのプロセッサに、前記属性情報と関連する前記少なくとも１つの値を格納させるように構成される、格納コード、および前記それぞれのオブジェクトのための複雑性要約を生成すること、をさらに含む、
請求項９に記載のデバイス。
【請求項11】
前記それぞれのオブジェクトは、前記オブジェクトの基本表現と、オブジェクト強化層のセットとを含み、該オブジェクト強化層のセットは、前記オブジェクトの属性に対応する前記属性情報を含み、前記オブジェクト強化層のセットが前記オブジェクトの前記基本表現に適用されるときに、前記オブジェクトの前記基本表現は、前記オブジェクトの前記基本表現を含む基本層において支持されない構成を含むように増強される、
請求項９に記載のデバイス。
【請求項12】
前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサに、少なくとも１つのオブジェクトについての少なくとも１つの複雑性情報を前記それぞれのシーンについての複雑性要約に集約させるように構成される集約コードであって、前記それぞれのシーンは、１つ以上のオブジェクトを含む、集約コードと、
前記少なくとも１つのプロセッサに、前記それぞれのシーンについての前記複雑性要約を前記それぞれのシーンのビットストリーム内の事前定義された場所に書き込ませるように構成される書込みコードと、をさらに含む、
請求項１０に記載のデバイス。
【請求項13】
前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサに、前記それぞれのシーンに対応する前記没入型メディアデータのフォーマットが、前記それぞれのシーンについての前記複雑性要約に基づいて、クライアントデバイスへの配信前に、第１のフォーマットから第２のフォーマットに転換されるべきかどうかを決定させるように構成される、フォーマット決定コードを更に含む、請求項１０に記載のデバイス。
【請求項14】
前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサに、前記それぞれのシーンに対応する前記没入型メディアデータが転換されるべきであるという決定に基づいて、前記コンテンツソースまたは前記クライアントデバイスが前記第１のフォーマットから前記第２のフォーマットへの転換を実行するべきかどうかを決定させるように構成される、転換決定コードをさらに含む、
請求項１３に記載のデバイス。
【請求項15】
シーンのオブジェクトの複雑性を分析するためにデバイスの少なくとも１つのプロセッサによって実行されるときに、前記少なくとも１つのプロセッサに、コンテンツソースから複数のシーンを含む没入型メディアデータを受信させ、
前記没入型メディアデータから、前記複数のシーン内のそれぞれのシーンのそれぞれのオブジェクトを取得させ、
前記それぞれのシーンの前記それぞれのオブジェクトと関連付けられる複雑性情報を生成するために前記それぞれのシーンを分析させ、
前記それぞれのシーンの前記それぞれのオブジェクトと関連付けられるメタデータを生成させ、
前記生成されるメタデータに基づく処理のために前記それぞれのシーンをクライアントに配信するかどうかを決定させ、
前記メタデータは、前記複雑性情報を含む、
プログラム。
【請求項16】
前記少なくとも１つのプロセッサに、さらに、前記それぞれのオブジェクトから属性情報を獲得させる、請求項１５に記載のプログラム。
【請求項17】
前記少なくとも１つのプロセッサに、さらに、前記属性情報が事前定義された複雑性属性のリスト内の１つ以上の複雑性属性に関連するかどうかを識別させ、
前記事前定義された複雑性属性内の前記リスト内の前記１つ以上の複雑性属性に関連する少なくとも１つの値を導出させ、
前記属性情報と関連する前記少なくとも１つの値を格納させ、前記それぞれのオブジェクトについての複雑性要約を生成させる、
請求項１６に記載のプログラム。
【請求項18】
前記少なくとも１つのプロセッサに、さらに、少なくとも１つのオブジェクトについての少なくとも１つの複雑性情報を前記それぞれのシーンについての複雑性要約に集約させ、
前記それぞれのシーンについての前記複雑性要約を前記それぞれのシーンのビットストリーム内の事前定義された場所に書き込ませ、
前記それぞれのシーンは、１つ以上のオブジェクトを含む、
請求項１７に記載のプログラム。
【請求項19】
前記少なくとも１つのプロセッサに、さらに、前記それぞれのシーンに対応する前記没入型メディアデータのフォーマットが、前記それぞれのシーンについての前記複雑性要約に基づいて、クライアントデバイスへの配信前に、第１のフォーマットから第２のフォーマットに転換されるべきかどうかを決定させる、請求項１７に記載のプログラム。
【請求項20】
前記少なくとも１つのプロセッサに、さらに、前記それぞれのシーンに対応する前記没入型メディアデータが転換されるべきであるという決定に基づいて、前記コンテンツソースまたは前記クライアントデバイスが前記第１のフォーマットから前記第２のフォーマットへの変換を実行するべきかどうかを決定させる、請求項１９に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
（関連出願の参照）
本出願は、２０２１年１１月５日に出願された米国仮特許出願第６３／２７６，５３８号、および２０２２年１０月１９日に出願された米国特許出願第１７／９６９，２２６号に基づいており、それらの優先権を主張し、それらの開示は、その全体が参照により本明細書に組み込まれる）。
本出願は、２０２１年１１月５日に出願された米国仮特許出願第６３／２７６，５３８号、および２０２２年１０月１９日に出願された米国特許出願第１７／９６９，２２６号に基づいており、それらの優先権を主張し、それらの開示は、その全体が参照により本明細書に組み込まれる）。
【0002】
（技術分野）
本開示は、ビデオ、オーディオ、幾何学的（３Ｄ）オブジェクト、触覚、関連するメタデータまたはクライアントプレゼンテーションデバイスのための他のコンテンツを含む、メディアを配信する(distribute)システムおよびネットワークのためのアーキテクチャ、構造、およびコンポーネントに概ね関連する実施形態を説明する。幾つかの実施形態は、不均一な没入型及(immersive)び対話型(interactive)クライアントプレゼンテーションデバイスへのメディアコンテンツの配信(distribution)のためのシステム、構造およびアーキテクチャに向けられている。
本開示は、ビデオ、オーディオ、幾何学的（３Ｄ）オブジェクト、触覚、関連するメタデータまたはクライアントプレゼンテーションデバイスのための他のコンテンツを含む、メディアを配信する(distribute)システムおよびネットワークのためのアーキテクチャ、構造、およびコンポーネントに概ね関連する実施形態を説明する。幾つかの実施形態は、不均一な没入型及(immersive)び対話型(interactive)クライアントプレゼンテーションデバイスへのメディアコンテンツの配信(distribution)のためのシステム、構造およびアーキテクチャに向けられている。
【背景技術】
【0003】
「没入型メディア(immersive media)」とは、一般に、ユーザがそのメディアの体験において物理的に存在していること、すなわち、時限式(timed)二次元（２Ｄ）ビデオおよび対応するオーディオのための既存の（例えば、「レガシー(legacy)」）商用ネットワーク上に配信されることを超えて、ユーザの知覚を創造または強化するために、任意のまたは全ての人間感覚システム（例えば、視覚、聴覚、体性感覚、嗅覚、および場合によっては味覚）を刺激するメディアを指し、そのような時限式メディアは、「レガシーメディア(legacy media)」としても知られている。没入型メディアは、動力学および物理法則のデジタルシミュレーションを通じて物理的世界を創造または模倣し、それによって、実世界または仮想世界を描くシーンの内側に物理的に存在するというユーザによる知覚を創り出すように、任意のまたは全ての人間感覚システムを刺激しようとする、メディアとしても定義される。
【0004】
ヘッドマウントディスプレイ、拡張現実メガネ、ハンドヘルドコントローラ、マルチビューディスプレイ、触覚グローブ、ゲームコンソール、ホログラフィックディスプレイおよび他の形態の容量ディスプレイを含む、多数の没入型メディア対応デバイスが、消費者市場に導入されている（あるいは、現れる構えを見せている）。これらのデバイスの利用可能性にもかかわらず、商用ネットワークを通じた没入型メディアの配信のための一貫したエンドツーエンドのエコシステムは、実現していない。
【0005】
関連技術において、商用ネットワークを通じた没入型メディアの配信のための一貫したエンドツーエンドのエコシステムを実現するための障害の１つは、没入型ディスプレイのためのそのような配信ネットワークのためのエンドポイントとして機能するクライアントデバイスが全て非常に多様であることである。レガシーメディアの配信のためだけに設計されたネットワークとは異なり、多様なディスプレイクライアント（すなわち、異種クライアント）をサポートしなければならないネットワークは、そのようなネットワークがメディアを各ターゲットディスプレイおよび対応するアプリケーションに適したフォーマットに変換する(translate)ための適合プロセスを利用し得る前に、クライアントの各能力の詳細および配信されるべきメディアのフォーマットに関する有意な量の情報を必要とする。そのようなネットワークは、ネットワークがどのようにして入力メディアソースをターゲットディスプレイおよびアプリケーションに適したフォーマットに意味のあるように適合させるかを確認するために、少なくとも、各ターゲットディスプレイの特徴および摂取されるメディアの複雑性を記述する情報へのアクセスを必要とする。
【発明の概要】
【発明が解決しようとする課題】
【0006】
従って、異種の没入型メディアを多様なクライアントに効率的に表現およびストリーミングする方法が必要とされる。
【課題を解決するための手段】
【0007】
実施形態によれば、シーンのオブジェクトの複雑性を特徴付けるための方法が提供される。
【0008】
本開示の一態様によれば、少なくとも１つのプロセッサによって実行される、シーンのオブジェクトの複雑性を特徴付けるための方法が提供される。この方法は、コンテンツソースから複数のシーンを含む没入型メディアデータを受信することと、没入型メディアデータから複数のシーン内のそれぞれのシーンのそれぞれのオブジェクトを取得することと、それぞれのシーンのそれぞれのオブジェクトと関連付けられる複雑性情報を生成するためにそれぞれのシーンを分析することと、それぞれのシーンのそれぞれのオブジェクトと関連付けられるメタデータを生成することであって、メタデータは、複雑性情報を含む、生成することと、生成されるメタデータに基づく処理のためにそれぞれのシーンをクライアントに配信するかどうかを決定することと、を含む。
【0009】
本開示の別の態様によれば、コンピュータプログラムコードを格納するように構成される少なくとも１つのメモリと、コンピュータプログラムコードを読み出して、コンピュータプログラムコードによって命令されるように動作するように構成される、少なくとも１つのプロセッサと、を含む、シーンのオブジェクトの複雑性を分析するためのデバイス（または装置）が提供される。コンピュータプログラムコードは、少なくとも１つのプロセッサに、コンテンツソースから複数のシーンを含む没入型メディアデータを受信させるように構成される、受信コードと、少なくとも１つのプロセッサに、没入型メディアデータから、複数のシーン内のそれぞれのシーンのそれぞれのオブジェクトを取得させるように構成される、取得コードと、少なくとも１つのプロセッサに、それぞれのシーンのそれぞれのオブジェクトと関連付けられる複雑性情報を生成させるために、それぞれのシーンを分析させるように構成される、分析コードと、少なくとも１つのプロセッサに、それぞれのシーンのそれぞれのオブジェクトと関連付けられるメタデータを生成させるように構成される、生成コードであって、メタデータは、複雑性情報を含む、生成コードと、少なくとも１つのプロセッサに、生成されるメタデータに基づく処理のために、それぞれのシーンをクライアントに配信するかどうかを決定させる、決定コードと、を含む
【0010】
本開示の別の態様によれば、シーンのオブジェクトの複雑性を特徴付けるデバイスの、少なくとも１つのプロセッサによって実行される命令を格納する非一時的なコンピュータ読取可能媒体が提供される。命令は、少なくとも１つのプロセッサに、コンテンツソースから複数のシーンを含む没入型メディアデータを受信させ、没入型メディアデータから、複数のシーン内のそれぞれのシーンのそれぞれのオブジェクトを取得させ、それぞれのシーンのそれぞれのオブジェクトと関連付けられる複雑性情報を生成するためにそれぞれのシーンを分析させ、それぞれのシーンのそれぞれのオブジェクトと関連付けられるメタデータを生成させ、生成されるメタデータに基づく処理のためにそれぞれのシーンをクライアントに配信するかどうかを決定させ、メタデータは、複雑性情報を含む。
【0011】
追加的な実施形態は、後続の記述に示され、一部は、記述から明らかであり、かつ／あるいは、本開示の提示される実施形態の実施によって実現されることがある。
【図面の簡単な説明】
【0012】
【図1】実施形態による、クライアントへの配信のためのネットワークを通じるメディアの流れの概略図である。
【0013】
【図2】実施形態による、クライアントにメディアを配信する前に、ネットワークがメディアを転換する(transform)べきかどうかを決定するために意思決定プロセスが利用される、ネットワークを通じるメディアの流れの概略図である。
【0014】
【図3】実施形態による、時限式没入型メディアの表現およびストリーミングのためのデータ－モデルの概略図である。
【0015】
【図4】実施形態による、非時限式没入型メディアの表現およびストリーミングのためのデータ－モデルの概略図である。
【0016】
【図5】実施形態による、天然メディア合成プロセスの概略図である。
【0017】
【図6】実施形態による、合成メディア摂取生成プロセスの一例の概略図である。
【0018】
【図7】実施形態による、コンピュータシステムの概略図である。
【0019】
【図8】実施形態による、ネットワークメディア配信システムの概略図である。
【0020】
【図9】実施形態による、没入型メディア配信プロセスの例示的ワークフローの概略図である。
【0021】
【図10】実施形態による、メディア適合プロセスシステムのシステム図である。
【0022】
【図11】実施形態による、例示的な配信フォーマット作成プロセスの概略図である。
【0023】
【図12】実施形態による、例示的なパケット化プロセスの概略図である。
【0024】
【図13】実施形態による、コンポーネント間の通信フローの一例を示すシーケンス図である。
【0025】
【図14A】実施形態による、オブジェクトの複雑性を特徴付けるための没入型メディア複雑性アナライザの方法を示すワークフローである。
【0026】
【図14B】実施形態による、複雑性属性リストの一例である。
【0027】
【図15】実施形態による、オブジェクトの複雑性を特徴付けるための没入型メディア複雑性アナライザのためのコンピュータコードの一例のブロック図である。
【発明を実施するための形態】
【0028】
例示的な実施形態の以下の詳細な記述、添付の図面を参照する。異なる図面における同じ参照番号は、同じまたは類似の要素を特定することがある。
【0029】
前述の開示は、図示および記述を提供するが、網羅的であることを意図したり、あるいは実施形態を開示の正確な形態に限定することを意図しない。修正および変形が、上記開示に照らして可能であるか、あるいは実装の実施から取得されることがある。さらに、１つの実施形態の１つ以上の構成(features)またはコンポーネント(構成要素)が、別の実施形態（または別の実施形態の１つ以上の構成）に組み込まれるか、あるいは別の実施形態（または別の実施形態の１つ以上の構成）と組み合わされることがある。加えて、以下に提供される動作(操作)のフローチャートおよび記述では、１つ以上の動作が省略されてよく、１つ以上の動作が追加されてよく、１つ以上の動作が（少なくとも部分的に）同時に実行されてよく、１つ以上の動作の順序が切り替えられてよいことが理解されよう。
【0030】
本明細書に記載するシステムおよび／または方法は、異なる形態のハードウェア、ソフトウェア、またはハードウェアとソフトウェアとの組み合わせで実装されることがあることが明らかであろう。これらのシステムおよび／または方法を実装するために使用される実際の特殊化された制御ハードウェアまたはソフトウェアコードは、実装を制限するものでない。よって、システムおよび／または方法の動作および挙動は、特定のソフトウェアコードを参照することなく、本明細書に記載される。ソフトウェアおよびハードウェアは、本明細書の記述に基づいてシステムおよび／または方法を実装するように設計されることがあることが理解されよう。
【0031】
構成の特定の組み合わせが特許請求の範囲に記載され、かつ／あるいは明細書に開示されているとしても、これらの組み合わせは、可能な実装の開示を制限することを意図しない。実際には、これらの構成の多くは、特許請求の範囲に具体的に記載されていないかつ／あるいは明細書に開示されていない方法で組み合わされることがある。以下に列挙される各従属項は、１つだけの請求項に直接従属することがあるが、可能な実装の開示は、請求項のセット中のあらゆる他の請求項との組み合わせにおける各従属項を含む。
【0032】
以下で議論される提案される構成は、別々にあるいは任意の順序で組み合わされることがある。さらに、実施形態は、処理回路構成（例えば、１つ以上のプロセッサまたは１つ以上の集積回路）によって実装されることがある。一例では、１つ以上のプロセッサは、非一時的なコンピュータ読取可能媒体に格納されたプログラムを実行する。
【0033】
本明細書中で使用される如何なる要素、行為、または命令も、そのように明示的に記述されない限り、重要または必須と解釈されるべきでない。また、本明細書中で使用されるとき、単数形の表現は、１つ以上の品目を含むことが意図されており、「１つ以上」と交換可能に使用されることがある。１つだけの品目が意図される場合には、「１つ」という用語または類似の言語が使用される。また、本明細書で使用されるとき、「有する(has)」、「有する(have)」、「有する(having)」、「含む(include)」、「含む(including」などは、オープンエンドの用語であることが意図されている。さらに、「～に基づく」という語句は、明示的に別段の記載がない限り、「少なくとも部分的に～に基づく」を意味することが意図される。さらに、「［Ａ］および［Ｂ］の少なくとも１つ」または「［Ａ］または［Ｂ］の少なくとも１つ」のような表現は、Ａのみ、Ｂのみ、またはＡおよびＢの両方を含むものとして理解されるべきである。
【0034】
本開示の例示的な実施形態は、没入型メディア対応プレゼンテーションデバイスへの配信のために、メディアデータの複雑性に基づいてメディア資産を分析すること(analyzing)および転換すること(transforming)ための方法およびデバイスを提供する。没入型メディア対応プレゼンテーションデバイスは、没入型メディアにアクセスし、解釈し、かつ提示するための十分なリソースおよび能力を備えていると呼ばれることがある。そのようなデバイスは、それらがサポートすることがある（ネットワークによって提供される）メディアの量およびフォーマットに関して異種(heterogeneous)である。同様に、メディアは、そのようなメディアをスケールで配信するために必要とされるネットワークリソースの量およびタイプに関して異種である。「スケールで(at scale)」とは、ネットワーク上のレガシービデオおよびオーディオメディアと同等の配信を実現するサービスプロバイダ（例えば、Ｎｅｔｆｌｉｘ、Ｈｕｌｕ、Ｃｏｍｃａｓｔのサブスクリプション、Ｓｐｅｃｔｒｕｍのサブスクリプションなど）によるメディアの配信を指す。対照的に、ラップトップディスプレイ、テレビ、および携帯ハンドセットディスプレイのようなレガシープレゼンテーションデバイスは、それらの能力において同質(homogenous)である。何故ならば、これらのデバイスの全ては、それらの主要なビジュアルメディアフォーマットとして２Ｄ矩形ビデオまたは静止画像を消費する矩形ディスプレイスクリーンで構成されるからである。レガシープレゼンテーションデバイスで一般的に使用されるビジュアルメディアフォーマットの一部は、例えば、High Efficiency Video Coding/H.265、Advanced Video Coding/H.264、およびVersatile Video Coding/H.266を含むことがある。
【0035】
既述のように、ネットワークを通じた没入型メディアの配信のためのエンドポイントとして機能するクライアントデバイスは、全て非常に多様である。それらの一部は、特定の没入型メディアフォーマットをサポートする一方で、他のものは、サポートしない。それらの一部は、レガシーラスターベースのフォーマットから没入的な体験を作り出すことができる一方で、他のものは、作り出すことができない。この問題に対処するために、ネットワークを通じた任意のメディアの配信は、入力(input)またはネットワーク摂取(network ingest)メディアフォーマットから配信メディアフォーマットに再フォーマットするメディア配信システムおよびアーキテクチャを利用することがあり、この場合、その配信メディアフォーマットは、ターゲットとなるクライアントデバイスおよびそのアプリケーションによって摂取されるのに適しているのみならず、ネットワークを通じてストリーミングされるのにも適している。よって、摂取されたメディアを使用するネットワークによって実行される２つのプロセス、すなわち、１）フォーマットＡから、ターゲットクライアントデバイスによって摂取されるのに適した、すなわち、特定のメディアフォーマットを摂取するクライアントデバイスの能力に基づいて、フォーマットＢへメディアを変換すること(converting)、および２）ストリーミングされるべきメディアを準備することがある場合がある。
【0036】
実施形態において、ストリーミングメディアは、メディアのフラグメント化および／またはパケット化を広義に指すので、ストリーミングメディアは、メディアの時間的または空間的構造の一方または両方に従って論理的に組織化されかつシーケンス化された、より小さいサイズの連続的なチャンクにおいて、ネットワークを通じて送達され得る。（「トランスコーディング(transcoding)」と呼ばれることがある）フォーマットＡからフォーマットＢへのメディアの転換(transforming)は、クライアントデバイスへのメディアの配信前に、通常はネットワークによってあるいはサービスプロバイダによって実行される、プロセスである。そのようなトランスコーディングは、フォーマットＢが、ターゲットクライアントデバイスによって摂取されることができる好ましいフォーマットまたは唯一のフォーマットである、あるいは商用ネットワークのような制約されたリソースを通じた配信により適しているという事前知識に基づいて、フォーマットＡからフォーマットＢにメディアを変換すること(converting)からなることがある。全ての場合でないにしても、多くの場合において、メディアを転換するステップおよびストリーミングされるべきメディアを準備するステップの両方が、メディアがネットワークから受信されて、ターゲットクライアントデバイスによって処理される前に、必要である。
【0037】
メディアを変換すること（または転換すること）、およびストリーミングのためにメディアを準備することは、クライアントデバイスにメディアを配信する前に、ネットワークによって摂取されるメディアに対して作用される。これらのプロセスは、配信メディアフォーマットまたは単に配信フォーマットと呼ばれるメディアフォーマットをもたらす。
【0038】
異種クライアントをサポートする理想的なネットワークは、入力メディアフォーマットから特定のターゲットフォーマットに適合される資産の一部が、類似の表示ターゲットのセットに亘って再利用されることがあるという事実を利用すべきである。すなわち、幾つかの資産は、ひとたびターゲットディスプレイに適したフォーマットに変換されると、同様の適合要件を有する多数のそのようなディスプレイに亘って再利用されることがある。従って、実施形態によれば、そのような理想的なネットワークは、例えば、レガシーネットワークにおけるコンテンツ配信ネットワーク（ＣＤＮｓ：Content Distribution Networks）の使用に類似する、相対的であるエリアに適合資産を格納するために、キャッシュ化メカニズム(cashing mechanism)を利用することがある。
【0039】
没入型メディアは、シーン記述(scene descriptions)としても知られているシーングラフ(scene graphs)によって記述されるシーンに編成することがある。実施形態では、（コンピュータグラフィックスの文脈における）シーンは、オブジェクト（例えば、３Ｄ資産）、オブジェクト属性、および設定内のオブジェクトの相互作用に関して空間または時間のいずれかによって制限される特定の設定を記述する視覚的、音響的、および物理学ベースの特徴(characteristics)を含む他のメタデータの集合である。シーングラフは、グラフィカルシーンの論理的表現およびしばしば（必須ではないが）空間的表現を配置する、ベクトルベースのグラフィックス編集アプリケーションおよび現代のコンピュータゲームによって一般的に使用される一般的なデータ構造である。シーングラフは、グラフ構造内のノードおよび頂点の集合から構成されることがある。ノードは、視覚、可聴、触覚、嗅覚、味覚、または関連処理情報の論理的、空間的、または時間的表現に関連する情報から構成されることがある。各ノードは、最大１つの出力エッジ(output edge)、ゼロ以上の入力エッジ(input edges)、およびそれに接続された少なくとも１つのエッジ（入力または出力のいずれか）を有する。属性またはオブジェクト属性は、そのノードの特定の特徴または構成を規範的な形態または（例えば、他のノードに関する）より複雑な形態で記述するために使用されるノードと関連付けられるメタデータを指す。シーングラフの範囲は、プレゼンテーションの一部である特定の設定、例えば、プレゼンテーション（例えば、映画）の一部である建物内の特定の場所で行われるイベントおよび俳優を含む、視覚的、音響的、および他の形態の没入型資産を記述することである。単一のプレゼンテーションを含む全てのシーンのリストは、シーンのマニフェスト(manifest)に定式化されることがある。
【0040】
キャッシュ化メカニズム(caching mechanism)を利用して適合資産を格納することの付加的な利点は、準備されるコンテンツのために、コンテンツを配信しなければならない前に、材料表(bill of materials)を作成できることである。材料表は、プレゼンテーション全体のために使用される資産の全て、および各資産がプレゼンテーション内の様々なシーンに亘ってどれぐらいの頻度で使用されるかを特定する。理想的なネットワークは、特定のプレゼンテーションのための資産要件を満たすために使用されることがあるキャッシュされたリソースの存在についての知識を持たなければならない。同様に、一連のシーンを提示しているクライアントデバイスは、複数のシーンに亘って使用される任意の所与の資産の頻度についての知識を有することを望むことがある。例えば、（メディアオブジェクトとしても知られる）メディア資産が、クライアントデバイスによって処理されるあるいは処理されるであろう複数のシーンに亘って複数回参照されるならば、クライアントデバイスは、特定の資産がクライアントデバイスによって提示されることを要求する最後のシーンまで、そのキャッシュ化リソースから資産を破棄することを回避しなければならない。本開示の実施形態において、メディア「オブジェクト」およびメディア「資産」という用語は、両方とも、メディアデータの特定のフォーマットの特定のインスタンスを参照して、互換的に使用されることがある。
【0041】
レガシーメディアプレゼンテーションデバイスについて、配信フォーマットは、プレゼンテーションを作成するためにクライアントプレゼンテーションデバイスによって最終的に使用される「プレゼンテーションフォーマット」と同等または十分に同等であることがある。すなわち、プレゼンテーションメディアフォーマットは、その特性（例えば、解像度、フレームレート、ビット深度、色域など）がクライアントプレゼンテーションデバイスの能力に密接に調整されるメディアフォーマットである。配信対プレゼンテーションフォーマットの例は、ネットワークによって解像度（３８４０画素列ｘ２１６０画素行）を有する超高解像度（ＵＨＤ：Ultra-high-definition）クライアントデバイスに配信される高解像度（ＨＤ：high-Definition）ビデオ信号（１９２０画素列ｘ１０８０画素行）を含む。前述の例において、ＵＨＤクライアントデバイスは、ＨＤ配信フォーマットに超解像処理を適用して、ビデオ信号の解像度をＨＤからＵＨＤに増大させる。よって、クライアントデバイスによって提示される最終的な信号フォーマットは、この例では、ＵＨＤ信号である、「プレゼンテーションフォーマット」であるのに対し、ＨＤ信号は、配信フォーマットを含む。この例において、ＨＤ信号配信フォーマットは、両方の信号が直線ビデオフォーマットであるので、ＵＨＤ信号プレゼンテーションフォーマットと非常に類似しており、ＨＤフォーマットをＵＨＤフォーマットに変換するプロセスは、比較的簡単であり、殆どのレガシーメディアクライアントデバイスで実行することが容易である。
【0042】
幾つかの実施形態において、クライアントデバイスのための好ましいプレゼンテーションフォーマットは、ネットワークによって受信される摂取フォーマットとは有意に異なることがある。それにもかかわらず、クライアントデバイスは、メディアを摂取フォーマットからクライアントデバイスによるプレゼンテーションに適した所要のプレゼンテーションフォーマットに転換するために、十分な計算、記憶、および帯域幅リソースへのアクセスを有することがある。このシナリオにおいて、ネットワークは、摂取したメディアをフォーマットＡからフォーマットＢに再フォーマット化するかあるいはトランスコーディングするステップをバイパスすることがある。何故ならば、ただ単に、クライアントデバイスは、全てのメディア転換を実行するのに十分なリソースへのアクセスを有し、ネットワークが先験的にそのようにすることを必要としないからである。しかしながら、ネットワークは、メディアがネットワークを通じてクライアントデバイスにストリーミングされることがあるように、摂取メディアをフラグメント化しかつパッケージ化するステップを依然として実行することがある。
【0043】
幾つかの実施形態において、摂取されるメディアは、クライアントの好ましいプレゼンテーションフォーマットとは有意に異なることがあり、クライアントデバイスは、メディアを摂取フォーマットから好ましいプレゼンテーションフォーマットに転換するのに十分な計算、記憶、および／または帯域幅リソースへのアクセスを有さないことがある。そのようなシナリオにおいて、ネットワークは、クライアントデバイスの代わりに、摂取フォーマットからクライアントの好みのプレゼンテーションフォーマットと同等またはほぼ同等なフォーマットへの転換の一部または全部を実行することによって、クライアントを支援することがある。幾つかのアーキテクチャ設計において、クライアントデバイスの代わりにネットワークによって提供されるそのような支援は、一般に、分割レンダリング(split rendering)と呼ばれる。
【0044】
図１は、クライアントへの配信のためのネットワークを通じるメディアフロープロセス１００の概略図である。図１は、フォーマットＡ（以下「摂取メディアフォーマットＡ」という）におけるメディアの例示的な処理を示している。処理（すなわち、メディアフロープロセス１００）は、ネットワーククラウドまたはエッジデバイス（以下「ネットワークデバイス１０４」）によって実施または実行されることがあり、クライアント、例えば、クライアントデバイス１０８に配信されることがある。幾つかの実施形態において、同じ処理は、手動処理において、あるいはクライアントデバイスによって、先験的に実行されることがある。ネットワークデバイス１０４は、摂取メディアモジュール１０１、ネットワーク処理モジュール１０２、および配信モジュール１０３を含むことがある。クライアントデバイス１０８は、レンダリングモジュール１０６、およびプレゼンテーションモジュール１０７を含むことがある。
【0045】
先ず、ネットワークデバイス１０４は、コンテンツプロバイダなどから摂取されるメディア(ingested media)を受け取る。摂取メディアモジュール１０１は、摂取メディアフォーマットＡにおいて格納される、摂取されるメディアを取得する。ネットワーク処理モジュール１０２は、摂取されるメディアの所要の転換または調整を実行して、メディアの潜在的に代替的な表現を作り出す。すなわち、ネットワーク処理モジュール１０２は、メディアを配信フォーマットＢにフォーマットすることによって、かつ／あるいはクライアントデバイス１０８にストリーミングされるべきメディアを準備することによって、クライアントへの配信のためのメディアを準備する。メディアフォーマットＡおよびＢは、特定のメディアフォーマット仕様の同じ構文に従った表現であることがあり、あるいはそのような表現でないことがある。しかしながら、フォーマットＢは、ネットワークプロトコルを通じたメディアの配信を容易にするスキームに条件付けられる可能性が高い。ネットワークプロトコルは、例えば、コネクション指向プロトコル（ＴＣＰ）またはコネクションレスプロトコル（ＵＤＰ）であることがある。配信モジュール１０３は、ネットワーク接続１０５を介して、ネットワークデバイス１０４からクライアントデバイス１０８に、ストリーミング可能なメディア（すなわち、メディアフォーマットＢ）をストリーミングする。
【0046】
クライアントデバイス１０８は、配信メディアを受信し、任意に、レンダリングモジュール１０６を介したプレゼンテーションのためにメディアを準備する。レンダリングモジュール１０６は、ターゲットとされているクライアントデバイス１０８に依存して、初歩的であることがある、あるいはさもなければ洗練されていることがある、幾つかのレンダリング能力へのアクセスを有する。レンダリングモジュール１０６は、プレゼンテーションフォーマットＣにおいてプレゼンテーションメディアを生成する。プレゼンテーションフォーマットＣは、第３のフォーマット仕様に従って表現されることがあり、あるいは表現されないことがある。従って、プレゼンテーションフォーマットＣは、メディアフォーマットＡおよび／またはＢと同じであることがあり、あるいは異なることがある。レンダリングモジュール１０６は、プレゼンテーションフォーマットＣをプレゼンテーションモジュール１０７に出力し、プレゼンテーションモジュール１０７は、クライアントデバイス１０８のディスプレイ（または同等物）にプレゼンテーションメディアを提示することがある。
【0047】
本開示の実施形態は、ネットワークおよび／またはクライアントによって利用される意思決定プロセスを促進して、ネットワークが摂取メディア(ingest media)の一部または全部をフォーマットＡからフォーマットＢに転換するべきかどうかを決定して、潜在的に第３のフォーマットＣにおいてメディアのプレゼンテーションを生成するクライアントの能力をさらに促進する。そのような意思決定プロセスを支援するために、実施形態は、没入型メディアシーンの一部または全体のいずれかを含む１つ以上のメディアオブジェクトを分析するメカニズムとして没入型メディア複雑性アナライザ(immersive media data complexity analyzer)を記載する。没入型メディア複雑性アナライザは、分析されるシーン内の各オブジェクトに関連する情報メタデータを作成し、そのようなメタデータは、オリジナルのフォーマットＡから別のフォーマットＢに転換されるべき１つ以上のメディアオブジェクトの複雑性に関する情報を含む。従って、ひとたび全てのそのようなメタデータが没入型メディアシーンの一部または全ての部分に関して利用可能になると、意思決定プロセスは、メディアオブジェクトをフォーマットＡから別のフォーマットＢに転換すること、および同様にネットワークまたはクライアントがそのような転換を実行するためにより良く装備されているかどうかを決定することの複雑性に関する情報をより良く備える。
【0048】
実施形態は、ネットワークまたはクライアントによって利用されるときに、フォーマットＡからフォーマットＢへのメディアオブジェクトの転換が完全にネットワークによって、完全にクライアントによって、あるいは（クライアントまたはネットワークによってどの資産が転換されるべきかの表示と共に）両方の混合を介して実行されるべきかにどうかついての表示を提供する、意思決定プロセスをサポートするために使用されることがある十分な情報を得るために没入型メディアシーンを分析する、メカニズムまたはプロセスの必要性に対処する。そのような没入型メディアデータ複雑性アナライザは、自動化された脈絡においてクライアントまたはネットワークのいずれかによって、あるいは、例えば、システムまたはデバイスを操作する人間によって手動で利用されることがある。
【0049】
実施形態によれば、入力没入型メディアソースを特定のエンドポイントクライアントデバイスに適合させるプロセスは、特定のクライアントエンドポイントデバイス上で実行されている特定のアプリケーションに同じ入力没入型メディアソースを適合させるプロセスと同じであることがあり、あるいはそれに類似することがある。従って、入力メディアソースをエンドポイントデバイスの特徴に適合させる問題は、特定の入力メディアソースを特定のアプリケーションの特徴に適合させる問題と同じ複雑性を持つ。
【0050】
図２は、ネットワークを通じて摂取されるメディアを処理するための論理ワークフローである。図２に示されるワークフローは、実施形態によるメディア転換意思決定プロセス２００を示している。メディア転換意思決定プロセス２００は、クライアントデバイスにメディアを配信する前に、ネットワークがメディアを転換するべきかどうかを決定するために利用される。メディア転換意思決定プロセス２００は、ネットワーク内で手動または自動化プロセスを通じて処理されることがある。
【0051】
フォーマットＡで表される摂取メディアは、コンテンツプロバイダによってネットワークに提供される。Ｓ２０１で、メディアは、コンテンツプロバイダからネットワークに摂取される。次に、Ｓ２０２で、既に知られていないならば、ターゲットとなるクライアントについての属性が獲得される(acquired)。属性は、ターゲットとなるクライアントの処理能力を記述する。
【0052】
Ｓ２０３で、ネットワーク（またはクライアント）が摂取されるメディアの転換を支援すべきかどうかが決定される。特に、メディアがターゲットとなるクライアントにストリーミングされる前に、摂取されるメディア内に含まれるメディア資産のいずれかについてのいずれかのフォーマット転換（例えば、フォーマットＡからフォーマットＢへの１つ以上のメディアオブジェクトの変換）が行われるかどうかが決定される。Ｓ２０３における意思決定プロセスは、手動で（すなわち、デバイスオペレータなどによって）実行されることがあり、あるいは自動化プロセスであることがある。Ｓ２０３における意思決定プロセスは、メディアが元の摂取されたフォーマットＡにおいてストリーミングされ得るかどうか、あるいはメディアがクライアントによるメディアのプレゼンテーションを容易にするために異なるフォーマットＢに転換されなければならないか否かの決定に基づくことがある。そのような決定は、最適な選択を行う意思決定プロセスを助けるような方法において（すなわち、摂取メディアの転換がメディアをクライアントにストリーミングする前に必要とされるか否かあるいはメディアがその元の摂取フォーマットＡにおいてクライアントに直接ストリーミングされるべきか否かを決定するために）、摂取メディアの態様または構成を記述する情報へのアクセスを必要とすることがある。
【0053】
ネットワーク（またはクライアント）が、いずれかのメディア資産の転換を支援すべきであると決定されるならば（Ｓ２０３でＹＥＳであるならば）、プロセス２００は、Ｓ２０４に進む。
【0054】
Ｓ２０４で、摂取されたメディアは、メディアをフォーマットＡからフォーマットＢに変換するために転換されて、転換されたメディア２０５を生成する。転換されたメディア２０５は出力され、処理はＳ２０６に進む。Ｓ２０６で、入力メディアは、クライアントにメディアをストリーミングするための準備プロセスを受ける。この場合、転換されたメディア２０５（すなわち、入力メディア）は、ストリーミングされるように準備される。
【0055】
フォーマットＡから別のフォーマット（例えば、フォーマットＢ）へのメディアの転換は、完全にネットワークによって、完全にクライアントによって、あるいはネットワークおよびクライアントの両方の間で共同で行われることがある。分割レンダリングのために、クライアントおよびネットワークの両方が、行われなければならない作業を特徴付ける完全な情報を持つように、メディアフォーマットを記述する属性の語彙(lexicon)が必要とされることがあることが明らかになる。さらに、例えば、利用可能なコンピュータリソース、利用可能なストレージリソース、および帯域幅へのアクセスの観点から、クライアントの能力の属性を提供する語彙も、同様に必要とされることがある。さらに、摂取メディアフォーマットの計算、記憶、または帯域幅の複雑性のレベルを特徴付けるメカニズムが必要とされるので、ネットワークおよびクライアントは、クライアントにメディアを配信するために、ネットワークが分割レンダリングプロセスを利用するか否か、あるいはネットワークが分割レンダリングプロセスをいつ利用するかを、共同であるいは単独で決定することがある。
【0056】
ネットワーク（またはクライアント）が、いずれかのメディア資産の転換を支援すべきでない（あるいは支援する必要がない）と決定されるならば（Ｓ２０３でＮＯ）、プロセス２００は、Ｓ２０６に進む。Ｓ２０６で、メディアはストリーミングのために準備される。この場合、摂取されたデータ（すなわち、その元の形態におけるメディア）は、ストリーミングされるように準備される。
【0057】
最後に、ひとたびメディアデータがストリーミング可能なフォーマットになると、Ｓ２０６で準備されたメディアは、クライアントにストリーミングされる（Ｓ２０７）。
【0058】
メディアのストリーミング可能なフォーマットは、時限式(timed)または非時限式(untimed)の異種の没入型メディアであってよい。図３は、異種の没入型メディアのストリーミング可能なフォーマットの時限式メディア表現３００の一例を示している。時限式没入型メディアは、Ｎ個のシーンのセットを含むことがある。時限式メディア(timed media)とは、例えば、特定のクロックに従った開始時間および終了時間を持つ、時間によって順序付けられるメディアコンテンツである。図４は、異種の没入型メディアのストリーミング可能なフォーマットの非時限式メディア表現４００の一例を示している。非時限式メディア(unlined media)とは、（例えば、１人以上のユーザがとる行動に従って実現されるインタラクティブな体験におけるような）空間的、論理的、または時間的な関係によって組織化されるメディアコンテンツである
【0059】
図３は、時限式メディアのための時限式シーンを参照し、図４は、非時限式メディアのための非時限式シーンを参照している。時限式シーンおよび非時限式シーンは、様々なシーン表現またはシーン記述によって具現されることがある。図３および図４は、両方とも、特定のクライアントエンドポイントの能力に合致するようにソース摂取メディアフォーマットから適合された単一の例示的な包含メディアフォーマット(encompassing media format)を利用する。すなわち、包含メディアフォーマットは、クライアントデバイスにストリーミング可能な配信フォーマットである。包含メディアフォーマットは、多種多様なメディア属性に順応するように、その構造において十分に堅牢であり、各メディア属性は、各層がメディアのプレゼンテーションに寄与する顕著な情報の量に基づいて各層が層化されることがある。
【0060】
図３に示されるように、時限式メディア表現３００は、時限式シーン３０１のリストを含む。時限式シーン３０１は、時限式シーン３０１を構成するメディア資産のタイプおよび処理情報を別々に記述するコンポーネント３０２のリストを参照する。コンポーネント３０２は、ベース層３０４および属性強化層３０５をさらに参照する資産３０３を参照する。ベース層は、計算リソース、資産をレンダリングするのに必要とされる時間、および／またはネットワークを通じて資産を送信するのに必要とされる時間を最小限に抑えるために定式化されることがある資産の公称表現である。強化層は、資産のベース層表現に適用されるときに、ベース層においてサポートされないことがある構成または能力を含むようにベース層を増大させる、情報のセットであることがある。
【0061】
図４に示されるように、非時限式メディア表現４００は、シーン４０１についての情報を含む。シーン４０１は、（クロック、タイマなどによる）開始および終了時間／持続時間と関連付けられていない。シーン４０１は、シーン４０１を構成するメディア資産のタイプおよび処理情報を別々に記述するコンポーネント４０２のリストを参照する。コンポーネント４０２は、（集合的に資産４０３と称される）視覚資産、可聴資産、触覚資産、および時限式資産を参照する。資産４０３は、ベース層４０４と、属性強化層４０５および４０６とをさらに参照する。シーン４０１は、非時限式メディアソースのためのものである他の非時限式シーン（すなわち、図４において非時限式シーン２．１～２．４として参照されるシーン）、および／または時限式メディアシーンのためのものであるシーン４０７（すなわち、図４において時限式シーン３．０として参照されるシーン）も参照することがある。図４の例において、非時限式没入型メディアは、（時限式および非時限式の両方を含む）５つのシーンのセットを含む。
【0062】
包含メディアフォーマットに従ってストリーミングされるメディアは、レガシー視覚および可聴メディアに限定されない。包含メディアフォーマットは、視野(sight)、音、味、触感、および臭いについての人間の感覚を刺激する機械と相互作用する信号を生成することができる任意のタイプのメディア情報を含むことがある。図３～図４に示されるように、包含メディアフォーマットに従ってストリーミングされるメディアは、時限式メディア、非時限式メディア、または両方の混合であることがある。包含メディアフォーマットは、ベース層および強化層アーキテクチャを使用して、メディアオブジェクトの層状表現を可能にすることによってストリーミング可能である。
【0063】
幾つかの実施態様において、別個のベース層および強化層は、各シーンに内のメディアオブジェクトのための多重解像度(multi-resolution)または多重平面充填(multi-tesselation)分析技法の適用によって計算される。この計算技術は、ラスタベースの視覚フォーマットに限定されない。
【0064】
幾つかの実施形態では、幾何学的オブジェクトの漸進的表現が、ウェーブレット(wavelet)分析技法を使用して計算されるオブジェクトの多重解像度表現であることがある。
【0065】
幾つかの実施形態では、層状表現メディアフォーマットにおいて、強化層は、ベース層に異なる属性を適用することがある。例えば、強化層のうちの１つ以上は、ベース層によって表される視覚オブジェクトの表面の材料特性を精緻化することがある。
【0066】
幾つかの実施形態では、層状表現メディアフォーマットにおいて、属性は、例えば、表面を滑らかなものから多孔質のテクスチャに変えることによって、あるいは艶消しされた表面から光沢のある表面に変えることによって、ベース層によって表されるオブジェクトの表面のテクスチャを精緻化することがある。
【0067】
幾つかの実施形態では、層状表現メディアフォーマットにおいて、シーン内の１つ以上の視覚オブジェクトの表面は、均等拡散面(lambertian surface)から光線追跡可能なものであるように変更されることがある。
【0068】
幾つかの実施形態では、層状表現メディアフォーマットにおいて、クライアントがベース層の解像度または他の特徴を精緻化するために追加的な強化層の伝達を待つ間に、クライアントがシーンの名目上のプレゼンテーションを生成することがあるように、ネットワークは、ベース層表現をクライアントに配信することがある。
【0069】
実施形態において、強化層における精緻化情報または属性の解像度は、ベース層におけるオブジェクトの解像度と明示的に結合されない。さらに、包含メディアフォーマットは、プレゼンテーションデバイスまたは機械によって提示されかあるいは作動されることがある任意のタイプの情報メディアをサポートすることがあり、それによって、異種のクライアントエンドポイントへの異種メディアフォーマットのサポートを可能にする。幾つかの実施形態において、メディアフォーマットを配信するネットワークは、クライアントの能力を決定するために、先ず、クライアントエンドポイントに問い合わせる。クエリ(問い合わせ)に基づいて、クライアントがメディア表現を意味があるように摂取できないならば、ネットワークは、クライアントによってサポートされていない属性の層を除去することがある。幾つかの実施形態において、クライアントがメディア表現を意味があるように摂取できないならば、ネットワークは、メディアを、その現在のフォーマットから、クライアントエンドポイントに適したフォーマットに適合させることがある。例えば、ネットワークは、ネットワークベースのメディア処理プロトコルを使用して、容積視覚メディア資産を同じ視覚資産の２Ｄ表現に変換することによって、メディアを適合させることがある。幾つかの実施形態において、ネットワークは、ニューラルネットワーク（ＮＮ：neural network）プロセスを利用して、メディアを適切なフォーマットに再フォーマットするか、あるいはクライアントエンドポイントによって必要とされるビューを任意的に合成することによって、メディアを適合させることがある。
【0070】
完全な（または部分的に完全な）没入体験（ライブストリーミングイベント、ゲーム、オンデマンド資産の再生）のためのシーンのマニフェスト(manifest)は、プレゼンテーションを作成するためのレンダリングおよび摂取のために必要とされる最低限の量の情報を含むシーンによって組織化される。シーンのマニフェストは、クライアントによって要求される没入体験の全体のためにレンダリングされるべき個々のシーンのリストを含む。各シーンと関連付けられるのは、シーンジオメトリ(幾何学的形状)のストリーミング可能なバージョンに対応するシーン内の幾何学的オブジェクトの１つ以上の表現である。シーンの１つの実施形態は、シーンのための幾何学的オブジェクトの低解像度バージョンを参照することがある。同じシーンの別の実施形態は、同じシーンの幾何学的オブジェクトの追加的な詳細を追加するか、あるいはモザイク細工(tessellation)を増加させるために、シーンの低解像度表現のための強化層を参照することがある。上述のように、各シーンは、シーンの幾何学的オブジェクトの詳細を漸進的な方法において増加させるために、１つ以上の強化層を有することがある。シーン内で参照されるメディアオブジェクトの各層は、リソースがネットワーク内でリソースにアクセスできる場所のアドレスを指し示すトークン（例えば、ユニフォームリソース識別子（ＵＲＩ：uniform resource identifier））と関連付けられることがある。そのようなリソースは、コンテンツがクライアントによってフェッチされることがあるコンテンツ配信ネットワーク（ＣＤＮ：content delivery networks）に類似している。幾何学的オブジェクトの表現のためのトークンは、ネットワーク内の場所またはクライアント内の場所を指し示すことがある。すなわち、クライアントは、そのリソースがネットワークベースのメディア処理のためにネットワークに利用可能であることをネットワークに信号伝達する(signal)ことがある。
【0071】
実施形態によれば、シーン（時限式または非時限式）は、シーングラフによって、マルチプレーン画像（ＭＰＩ：Multi-Plane Image）またはマルチ球面画像（ＭＳＩ：Multi-Spherical Image）として具現されることがある。ＭＰＩ技法およびＭＳＩ技法の両方は、自然コンテンツについての表示－不可知論的なシーン表現（すなわち、１つ以上のカメラから同時にキャプチャされる実世界の画像）の作成を支援する技術の例である。他方、シーングラフ技術は、合成表現の形態において、自然像(natural imagery)およびコンピュータ生成像(computer-generated imagery)の両方を表現するために利用されることがある。しかしながら、そのような表現は、コンテンツが１つ以上のカメラによって自然シーンとしてキャプチャされる場合について、作成するのが特に計算集約的(compute-intensive)である。自然にキャプチャされるコンテンツのシーングラフ表現は、作成するのが時間集約的(time intensive)および計算集約的(computation intensive)の両方であり、ターゲット没入型クライアントディスプレイの視認錐台(viewing frustum)を満たすために十分かつ適切な数のビューを補間するために引き続き使用することができる合成表現を作成するために、写真測量またはディープラーニングまたはそれらの両方の技法を用いた自然画像の複雑な分析を必要とする。結果的に、そのような合成表現は、自然コンテンツを表現するための候補として考えることは現実的でない。何故ならば、それらはリアルタイムの配信を必要とするユースケースを考慮するためにリアルタイムで実際に作成することができないからである。よって、コンピュータ生成像のための最良の表現は、合成モデルを用いたシーングラフの使用を利用することである。何故ならば、コンピュータ生成像は、３Ｄモデリングプロセスおよびツールを用いて作成され、合成モデルを用いたシーングラフの使用は、コンピュータ生成像の最良の表現をもたらすからである。
【0072】
図５は、実施形態による、自然メディア合成プロセス５００(natural media synthesis process)の一例を示している。自然メディア合成プロセス５００は、摂取フォーマットを、自然シーンから、異種のクライアントエンドポイントに役立つネットワークのための摂取フォーマットとして使用されることができる表現に変換する。破線５１０の左側は、自然メディア合成プロセス５００のコンテンツ取り込み部分(content capturing portion)である。破線５１０の右側は、自然メディア合成プロセス５００の（自然画像のための）摂取フォーマット合成である。
【0073】
図５に示されるように、第１のカメラ５０１が、例えば、人（すなわち、図５に示される俳優）のシーンをキャプチャするために単一のカメラレンズを使用する。第２のカメラ５０２が、リング形状のオブジェクトの周囲に５つのカメラレンズを取り付けることによって、５つの発散する視野を有するシーンをキャプチャする。図５に示される第２のカメラ５０２の構成は、ＶＲアプリケーションのために全方向コンテンツをキャプチャするために一般的に使用される例示的な構成である。第３のカメラ５０３が、球体の内径部分に７つのカメラレンズを取り付けることによって、７つの収束する視野を有するシーンをキャプチャする。第３のカメラ５０３の構成は、光照射野またはホログラフィック没入型ディスプレイのための光照射野をキャプチャするために一般的に使用される例示的な構成である。実施形態は、図５に示される構成に限定されない。第２のカメラ５０２および第３のカメラ５０３は、複数のカメラレンズを含むことがある。
【0074】
自然画像コンテンツ５０９は、第１のカメラ５０１、第２のカメラ５０２、および第３のカメラ５０３から出力され、シンセサイザ５０４への入力として機能する。シンセサイザ５０４は、トレーニング画像５０６の集合を使用するＮＮトレーニング５０５を利用して、キャプチャＮＮモデル５０８を生成することがある。トレーニング画像５０６は、前の合成処理から事前に定義されることがあり、あるいは格納されることがある。ＮＮモデル（例えば、キャプチャＮＮモデル５０８）が、元の信号によって明示的に提供されなかった視覚信号についての新しいビューの補間を含むことがある改良された視覚出力に到達するために、視覚信号に適用される明確に定義された数学的演算において使用される重み（すなわち、数値）を定義する、パラメータおよびテンソル（例えば、行列）の集合である。
【0075】
幾つかの実施形態では、写真測量プロセスが、ＮＮトレーニング５０５の代わりに実施されることがある。キャプチャＮＮモデル５０８が、自然メディア合成プロセス５００の間に作成されるならば、キャプチャＮＮモデル５０８は、自然メディアコンテンツのための摂取フォーマット５０７における資産の１つとなる。摂取フォーマット５０７は、例えば、ＭＰＩまたはＭＳＩであることがある。摂取フォーマット５０７は、メディア資産を含むこともある。
【0076】
図６は、実施形態による、合成メディア摂取生成プロセス６００の一例を示している。合成メディア摂取生成プロセス６００は、例えば、コンピュータ生成像のような、合成メディアの摂取メディアフォーマットを生成する。
【0077】
図６に示されるように、カメラ６０１は、シーンのポイントクラウド６０２(点群)をキャプチャすることがある。カメラ６０１は、例えば、ライダー(LIDAR)カメラであってよい。コンピュータ６０３は、例えば、共通ゲートウェイインターフェース（ＣＧＩ）ツール、３Ｄモデリングツール、または別のアニメーションプロセスを利用して、合成コンテンツ（すなわち、異種のクライアントエンドポイントを提供するネットワークのための摂取フォーマットとして使用することができる合成シーンの表現）を作成する。コンピュータ６０３は、ネットワークを通じてＣＧＩ資産６０４を生成することがある。加えて、センサ６０５Ａは、シーン内の俳優６０５に装着されることがある。センサ６０５Ａは、例えば、取り付けられたセンサを備えたモーションキャプチャスーツであってよい。センサ６０５Ａは、俳優６０５の動きのデジタル記録をキャプチャして、アニメーション化された動きデータ６０６（またはＭｏＣａｐデータ）を生成する。ポイントクラウド６０２、ＣＧＩ資産６０４、および動きデータ６０６からのデータは、合成メディア摂取フォーマット６０８を生成するシンセサイザ６０７への入力として提供される。幾つかの実施形態において、シンセサイザ６０７は、ＮＮおよびトレーニングデータを使用して、ＮＮモデルを作成して、合成メディア摂取フォーマット６０８を生成することがある。
【0078】
自然コンテンツおよびコンピュータ生成された（すなわち、合成）コンテンツは、コンテナ(容器)に保存されることができる。コンテナは、シーングラフおよびシーンのレンダリングに必要とされる全てのメディアリソースを含む、全て自然シーンの、全て合成シーンの、または合成シーンと自然シーンとの混合物を表すために情報を格納および交換するシリアライズ(シリアル化)されたフォーマットを含むことがある。コンテンツのシリアライゼーション(シリアル化)プロセスは、データ構造またはオブジェクト状態を、（例えば、ファイルまたはメモリバッファに）格納されるかあるいは（例えば、ネットワーク接続リンクに亘って）送信されることができ、同じまたは異なるコンピュータ環境において後に再構成されることができるフォーマットに、変換することを含む。結果として得られる一連のビットがシリアライゼーションフォーマットに従って再読み出しされるときに、それは元のオブジェクトの意味的に同一のクローンを作るために使用されることができる。
【0079】
自然コンテンツおよびコンピュータ生成された（すなわち、合成）コンテンツの両方の表現の最適表現における二分法は、自然にキャプチャされたコンテンツの最適摂取フォーマットが、リアルタイム配信アプリケーションに不可欠ではない自然コンテンツのための最適摂取フォーマットまたはコンピュータ生成されたコンテンツのための最適摂取フォーマットとは異なることを示唆する。従って、実施形態によれば、ネットワークは、例えば、物理カメラの使用を通じて自然に、あるいはコンピュータによって作成されるかにかかわらず、視覚的に没入型のメディアのための複数の摂取フォーマットをサポートするのに十分なほどに堅牢であることを目標とする。
【0080】
ＯＴＯＹによるＯＲＢＸ、ＰｉｘａｒによるＵｎｉｖｅｒｓａｌ Ｓｃｅｎｅ Ｄｅｓｃｒｉｐｔｉｏｎ、Ｋｈｒｏｎｏｓ ３Ｄ Ｇｒｏｕｐによって書かれたＧｒａｐｈｉｃｓ Ｌａｎｇｕａｇｅ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｆｏｒｍａｔ ２．０（ｇｌＴＦ２．０）仕様のような技術は、シーングラフを、コンピュータ生成技術を用いて作成された視覚的な没入型メディアを表現するのに適したフォーマットとして、あるいは自然シーンの対応する（すなわち、リアルタイム配信アプリケーションに必須でない）合成表現を作成するためにディープラーニングまたは写真測量技術を用いた自然にキャプチャされたコンテンツとして具現する。
【0081】
OTOYによるORBXは、光線トレーサブルな、レガシー（フレームベースの）、容量性の、および他のタイプの合成またはベクトルベースのビジュアルフォーマットを含む、時限式のまたは非時限式の、任意のタイプのビジュアルメディアをサポートできる幾つかのシーングラフ技術のうちの１つである。ＯＲＢＸは、他のシーングラフと異なる。何故ならば、ＯＲＢＸは、メッシュ、ポイントクラウド、およびテクスチャのための自由に利用可能なおよび／またはオープンなソースフォーマットをサポートするからである。ＯＲＢＸは、シーングラフ上で動作する複数のベンダ技術に亘る相互交換を容易にすることを目的として意図的に設計されたシーングラフである。その上、ＯＲＢＸは、豊富な素材システム、Ｏｐｅｎ Ｓｈａｄｅｒ Ｌａｎｇｕａｇｅのサポート、堅牢なカメラシステム、Ｌｕａ Ｓｃｒｉｐｔｓのサポートを提供する。ＯＲＢＸは、Ｉｍｍｅｒｓｉｖｅ Ｄｉｇｉｔａｌ Ｅｘｐｅｒｉｅｎｃｅｓ Ａｌｌｉａｎｃｅ（ＩＤＥＡ）がロイヤルティフリーの条件でライセンスを供与するために発行したＩｍｍｅｒｓｉｖｅ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｍｅｄｉａ Ｆｏｒｍａｔのベースでもある。メディアのリアルタイム配信の文脈において、自然シーンのＯＲＢＸ表現を作成して配信する能力は、カメラでキャプチャされたデータの複雑な分析および合成表現への同じデータの合成を実行するための計算リソースの利用可能性の関数である。
【0082】
ＰｉｘａｒによるＵＳＤ は、視覚効果およびプロ向けコンテンツ制作でよく使用されるシーングラフである。ＵＳＤは、Ｎｖｉｄｉａのグラフィックス処理ユニット（ＧＰＵ）で３Ｄモデルを作成してレンダリングするための開発者向けツールのセットである、ＮｖｉｄｉａのＯｍｎｉｖｅｒｓｅプラットフォームに統合される。ＡｐｐｌｅおよびＰｉｘａｒによって公表されたＵＳＤのサブセットは、ＵＳＤＺと呼ばれ、それはＡｐｐｌｅのＡＲＫｉｔによってサポートされる。
【0083】
ｇｌＴＦ２．０は、Ｋｈｒｏｎｏｓ ３Ｄ Ｇｒｏｕｐによって書かれたＧｒａｐｈｉｃｓ Ｌａｎｇｕａｇｅ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｆｏｒｍａｔ仕様のバージョンである。このフォーマットは、ＰＮＧおよびＪＰＥＧ画像フォーマットを含む、シーン内の静的（非時限式）オブジェクトを概ねサポートすることができる単純なシーングラフフォーマットをサポートする。ｇｌＴＦ２．０は、ｇｌＴＦプリミティブを用いて記述された（すなわち、幾何学的オブジェクトのための）基本形状の並進（平行移動）、回転、スケーリングのサポートを含む、単純なアニメーションをサポートする。ｇｌＴＦ２．０は、時限式メディアをサポートせず、故に、ビデオメディア入力もオーディオメディア入力もサポートしない。
【0084】
没入型ビジュアルメディアのシーン表現のためのこれらの設計は、一例として提供されるにすぎず、入力没入型メディアソースを、クライアントエンドポイントデバイスの特定の特徴に適したフォーマットに適合させるプロセスを特定する能力において、開示の主題を限定するものでない。その上、上記の例示的なメディア表現のいずれかまたは全ては、錐台(frustum)の特定の寸法に基づいて特定のディスプレイの視錐台(viewing frustum)を満たす特定のビュー(views)の選択を可能にするかあるいは容易にするＮＮモデルを訓練および作成するために、ディープラーニングを利用し、あるいは利用することがある。特定のディスプレイの視野台のために選択されるビューは、シーン表現において明示的に提供される既存のビュー、例えば、ＭＳＩまたはＭＰＩ技法から補間されることがある。ビューは、特定の仮想カメラ場所、フィルタ、またはこれらのレンダリングエンジンのための仮想カメラの既述に基づいて、レンダリングエンジンから直接レンダリングされることもある。
【0085】
本開示の方法およびデバイスは、（例えば、１つ以上のカメラで）自然にキャプチャされるかあるいはコンピュータ生成技術を用いて作成されるメディアのリアルタイムまたはオンデマンド（例えば、非リアルタイム）配信の要件を十分に満たすことができる、比較的小さいが良く知られている没入型メディア摂取フォーマットのセットが存在すると考えるのに十分な程に堅牢である。
【0086】
ＮＮモデルまたはネットワークベースのレンダリングエンジンのいずれかの使用による没入型メディア摂取フォーマットからのビューの補間は、先進ネットワーク技術（例えば、モバイルネットワーク用の５Ｇ）としてさらに容易にされ、ファイバ光ケーブルは、固定ネットワークのために配備される。これらの先進ネットワーク技術は、商用ネットワークの容量および能力を増加させる。何故ならば、そのような先進ネットワークインフラストラクチャは、ますます大量の視覚情報の輸送および送達を支援することができるからである。マルチアクセスエッジコンピューティング（ＭＥＣ）、ソフトウェア定義ネットワーク（ＳＤＮ）、およびネットワーク機能仮想化（ＮＦＶ）のような、ネットワークインフラストラクチャ管理技術は、商用ネットワークサービスプロバイダが、例えば、ネットワークスループット、ネットワーク速度、ラウンドトリップ待ち時間、および計算リソースについての需要の動的な増加または減少に対応するために、特定のネットワークリソースについての需要の変化に適合するように、それらのネットワークインフラストラクチャを柔軟に構成することを可能にする。その上、動的ネットワーク要求に適合するこの固有の能力は、同様に、異種のクライアントエンドポイントのための潜在的に異種のビジュアルメディアフォーマットを有する様々な没入型メディアアプリケーションをサポートするために、没入型メディア摂取フォーマットを適切な配信フォーマットに適合させるネットワークの能力を容易にする。
【0087】
没入型メディアアプリケーション自体も、ゲームの状態におけるリアルタイム更新に応答するために有意に低いネットワーク待ち時間を必要とするゲームアプリケーション、ネットワークのアップリンクおよびダウンリンク部分の両方についての対称的なスループット要求を有するテレプレゼンスアプリケーション、およびデータを消費しているクライアントエンドポイントディスプレイのタイプに依存してダウンリンクリソースについての増大した需要を有することがある受動的な視認(viewing)アプリケーションを含む、ネットワークリソースについての様々な要求を有することがある。一般に、あらゆる消費者向けアプリケーションは、記憶、計算、および電力のための様々な搭載クライアント能力、ならびに特定のメディア表現のための同様の様々な要件を有する、様々なクライアントエンドポイントによってサポートされることがある。
【0088】
従って、本開示の実施形態は、十分に装備されたネットワーク、すなわち、現代のネットワークの特徴の一部または全部を使用するネットワークが、デバイス内で特定される構成に従って複数のレガシーおよび没入型メディア対応デバイスを同時にサポートすることを可能にする。よって、本明細書に記載される没入型メディア配信方法およびプロセスは、メディアの配信のためのリアルタイムおよびオンデマンドの使用事例の両方のために実用的であるメディア摂取フォーマットを利用する柔軟性、レガシーおよび没入型メディア対応クライアントエンドポイントの両方のための自然コンテンツおよびコンピュータ生成コンテンツの両方をサポートする柔軟性、ならびに時限式および非時限式メディアの両方のサポートを提供する。方法およびプロセスは、クライアントエンドポイントの構成および能力に基づいて、ならびにアプリケーションの要件に基づいて、ソースメディア摂取フォーマットを適切な配信フォーマットに動的に適合させる。これは、配信フォーマットがＩＰベースのネットワークを通じてストリーミング可能であることを保証し、ネットワークが、レガシーおよび没入型メディア対応デバイスの両方を含むことがある複数の異種のクライアントエンドポイントに同時に役立つことを可能にする。さらに、実施形態は、シーン境界に沿った配信メディアの組織化を容易にする例示的なメディア表現フレームワークを提供する。
【0089】
前述の改良を提供する、本開示の実施形態による異種の没入型メディア配信のエンドツーエンド実装が、以下にさらに詳述される、図３～図１６の詳細な記述に記載される処理およびコンポーネント(構成要素)に従って達成される。
【0090】
上述の異種の没入型メディアを表現およびストリーミングするための技術は、コンピュータ読取可能な命令を使用する、ならびに１つ以上の非一時的なコンピュータ読取可能なメディアに物理的に格納される、コンピュータソフトウェアとして、あるいは１つ以上のハードウェアプロセッサによって、ソースおよび宛先の両方において実装されることがある。図７は、開示される主題事項の特定の実施形態を実装するのに適したコンピュータシステム７００を示している。
【0091】
コンピュータソフトウェアは、コンピュータ中央処理ユニット（ＣＰＵｓ）、グラフィックス処理ユニット（ＧＰＵｓ）などによって、直接的にあるいは補間、マイクロコード実行などを通じて実行されることがある命令を含むコードを生成するために、アセンブリ、コンパイル、リンク、または類似のメカニズムに従うことがある、任意の適切な機械コードまたはコンピュータ言語を用いてコーディング(コード化)されることがある。
【0092】
命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲームデバイス、モノのインターネットデバイスなどを含む、様々なタイプのコンピュータまたはそれらのコンポーネントで実行されることがある。
【0093】
コンピュータシステム７００についての図７に示されるコンポーネントは、本質的に例示的であり、本開示の実施形態を実装するコンピュータソフトウェアの使用範囲または機能性に関する如何なる制限も示唆することを意図しない。コンポーネントの構成も、コンピュータシステム７００の例示的な実施形態に示されるコンポーネントの任意の１つまたは組み合わせに関する如何なる従属性または要件も有していると解釈されてならない。
【0094】
コンピュータシステム７００は、特定のヒューマンインターフェース入力デバイスを含むことがある。そのようなヒューマンインターフェース入力デバイスは、例えば、（キーストローク、スワイプ、データグローブの動きのような）触覚入力、（音声、拍手のような）オーディオ入力、（ジェスチャのような）視覚入力、嗅覚入力を通じて、一人以上の人間ユーザによる入力に応答することがある。ヒューマンインターフェースデバイスは、（発話、音楽、周囲音のような）オーディオ、（走査画像、静止画像カメラから得られた写真画像のような）画像、（二次元ビデオ、立体ビデオを含む三次元ビデオのような）ビデオのような、人間による意識的入力に必ずしも直接関係しない特定のメディアをキャプチャするために使用されることもある。
【0095】
入力ヒューマンインターフェースデバイスは、キーボード７０１、トラックパッド７０２、マウス７０３、スクリーン７０９（各々の１つのみが図示されている）のうちの１つ以上を含むことがあり、それらは、例えば、タッチスクリーン、データグローブ、ジョイスティック７０４、マイクロホン７０５、カメラ７０６、およびスキャナ７０７であることがある。
【0096】
コンピュータシステム７００は、特定のヒューマンインターフェース出力デバイスを含むこともある。そのようなヒューマンインターフェース出力デバイスは、例えば、触覚出力、音、光、および臭い／味を通じて、１人以上の人間ユーザの感覚を刺激することがある。そのようなヒューマンインターフェース出力デバイスは、触覚出力デバイス（例えば、スクリーン７０９、データグローブ、またはジョイスティック７０４による触覚フィードバック、しかしながら、入力デバイスとして機能しない触覚フィードバックデバイスがあることもある）、（スピーカ７０８、ヘッドフォンのような）オーディオ出力デバイス、（各々がタッチスクリーン入力能力を有するかあるいは有さない、各々が触覚フィードバック能力を有するかあるいは有さない、それらの一部が、立体画像出力、仮想現実メガネ、ホログラフディスプレイ、およびスモークタンクのような手段を通じて、二次元の視覚出力または三次元以上の出力を出力することができる、ＣＲＴスクリーン、ＬＣＤスクリーン、プラズマスクリーン、ＯＬＥＤスクリーンを含む、スクリーン７０９のような）視覚出力デバイス、およびプリンタを含むことがある。
【0097】
コンピュータシステム７００は、ＣＤ／ＤＶＤまたは同等のメディア７１０を持つＣＤ／ＤＶＤ ＲＯＭ／ＲＷ７１１、親指駆動装置７１２、取り外し可能ハードドライブまたはソリッドステートドライブ７１３、テープおよびフロッピーディスクのようなレガシー磁気媒体、セキュリティドングルのような特殊化されたＲＯＭ／ＡＳＩＣ／ＰＬＤベースのデバイス等を含む、光メディアのような、人間がアクセス可能な記憶デバイスおよびそれらの関連媒体を含むこともある。
【0098】
当業者は、本開示の主題事項に関連して使用されるときの「コンピュータ可読媒体」という用語が、伝送媒体、搬送波、または他の過渡信号を包含しないことも理解するはずである。
【0099】
コンピュータシステム７００は、１つ以上の通信ネットワーク７１４へのインターフェース７１５を含むこともある。ネットワーク７１４は、例えば、無線、有線、光であってよい。ネットワーク７１４は、さらに、ローカル、ワイドエリア、メトロポリタン、車両および工業、リアルタイム、遅延耐性などであってよい。ネットワーク７１４の例は、イーサネット、無線ＬＡＮ、ＧＳＭ、３Ｇ、４Ｇ、５Ｇ、ＬＴＥなどを含むセルラネットワーク、ケーブルＴＶ、衛星ＴＶ、および地上放送ＴＶを含むＴＶ無線または有線ワイドエリアデジタルネットワーク、ＣＡＮＢｕｓを含む車両および産業などを含む。特定のネットワーク７１４は、一般に、（例えば、コンピュータシステム７００のＵＳＢポートのような）特定の汎用データポートまたは周辺バス７１６に取り付けられる外部ネットワークインターフェースアダプタ（例えば、グラフィックスアダプタ７２５）を必要とする（他のものは、一般に、後述するようなシステムバス（例えば、ＰＣコンピュータシステムへのイーサネットインターフェース、またはスマートフォンコンピュータシステムへのセルラネットワークインターフェース）への取り付けによって、コンピュータシステム７００のコアに組み込まれる）。これらのネットワーク７１４のいずれかを使用して、コンピュータシステム７００は、他のエンティティと通信することがある。そのような通信は、単指向性、受信のみ（例えば、放送テレビ）、単指向性送信専用（例えば、特定のＣＡＮｂｕｓデバイスへのＣＡＮｂｕｓ）、または、例えば、ローカルまたはワイドエリアデジタルネットワークを使用する他のコンピュータシステムへの双指向性であることがある。特定のプロトコルおよびプロトコルスタックは、上述のように、それらのネットワークおよびネットワークインターフェースの各々で使用されることがある。
【0100】
前述のヒューマンインターフェースデバイス、人間がアクセス可能な記憶デバイス、およびネットワークインターフェースは、コンピュータシステム７００のコア７１７に取り付けられることがある。
【0101】
コア７１７は、１つ以上の中央処理装置（ＣＰＵ）７１８、グラフィックス処理装置（ＧＰＵ）７１９、フィールドプログラマブルゲートエリア（ＦＰＧＡ）７２０の形態の特殊化されたプログラマブル処理装置、特定のタスクのためのハードウェアアクセラレータ７２１などを含むことがある。これらのデバイスは、読出し専用メモリ（ＲＯＭ）７２３、ランダムアクセスメモリ（ＲＡＭ）７２４、内部ユーザアクセス不能ハードドライブのような内部大容量記憶装置、ＳＳＤ、および同等物７２２とともに、システムバス７２６を通じて接続されることがある。幾つかのコンピュータシステムにおいて、システムバス７２６は、追加のＣＰＵ、ＧＰＵなどによる拡張を可能にするために、１つ以上の物理プラグの形態でアクセス可能である。周辺デバイスは、コアのシステムバス７２６に直接取り付けられることがあり、あるいは周辺バス７１６を通じて取り付けられることがある。周辺バスのためのアーキテクチャは、ＰＣＩ、ＵＳＢなどを含む。
【0102】
ＣＰＵｓ７１８、ＧＰＵｓ７１９、ＦＰＧＡｓ７２０、およびアクセラレータ７２１は、組み合わせにおいて、前述の機械コード（またはコンピュータコード）を構成することがある、特定の命令を実行することがある。そのコンピュータコードは、ＲＯＭ７２３またはＲＡＭ７２４に格納されることがある。移行データも、ＲＡＭ７２４に格納されることがあるのに対し、永久データは、例えば、内部大容量記憶装置７２２に格納されることがある。メモリデバイスのいずれかへの高速格納および検索は、キャッシュメモリの使用を通じて可能にされることがあり、キャッシュメモリは、１つ以上のＣＰＵ７１８、ＧＰＵ７１９、大容量記憶装置７２２、ＲＯＭ７２３、ＲＡＭ７２４などと密接に関連付けられることがある。
【0103】
コンピュータ読取可能媒体は、様々なコンピュータ実装された動作を実行するためのコンピュータコードをその上に有することがある。媒体およびコンピュータコードは、本開示の目的のために特別に設計および構築されることがあり、あるいは、それらは、コンピュータソフトウェア技術の当業者に良く知られておりかつ利用可能である種類であるのものであることがある。
【0104】
限定としてではなく、一例として、コンピュータシステム７００のアーキテクチャ、特にコア７１７を有するコンピュータシステムは、１つ以上の有形のコンピュータ読取可能媒体に具現されるソフトウェアを実行する（ＣＰＵ、ＧＰＵ、ＦＰＧＡ、アクセラレータなどを含む）プロセッサの結果としての機能性を提供することがある。そのようなコンピュータ読取可能媒体は、上述したようなユーザがアクセス可能な大容量記憶装置ならびにコア内部大容量記憶装置７２２またはＲＯＭ７２３のような非一時的な性質のコア７１７の特定の記憶装置と関連付けられる媒体であることがある。本開示の様々な実施形態を実装するソフトウェアは、そのようなデバイスに格納されることがあり、コア７１７によって実行されることがある。コンピュータ読取可能媒体は、特定のニーズに従って、１つ以上のメモリデバイスまたはチップを含むことがある。ソフトウェアは、コア７１７、特にその中の（ＣＰＵ、ＧＰＵ、ＦＰＧＡなどを含む）プロセッサに、ＲＡＭ７２４に格納されるデータ構造を定義すること、およびソフトウェアによって定義されるプロセスに従ってそのようなデータ構造を修正することを含む、本明細書に記載される特定のプロセスまたは特定のプロセスの特定の部分を実行させることがある。追加的にまたは代替的に、コンピュータシステムは、回路（例えば、アクセラレータ７２１）内に配線されるかあるいは他の方法で具現される論理(ロジック)の結果としての機能性を提供することがあり、回路は、本明細書に記載される特定のプロセスまたは特定のプロセスの特定の部分を実行するためのソフトウェアの代わりにあるいはそのようなソフトウェアとともに動作することがある。ソフトウェアへの言及は、必要に応じて、論理を包含することがあり、その逆もまた同様である。コンピュータ読取可能媒体への言及は、必要に応じて、実行のためのソフトウェアを格納する（集積回路（ＩＣ）のような）回路、実行のための論理を具現する回路、またはそれらの両方を包含することがある。本開示は、ハードウェアおよびソフトウェアの任意の適切な組み合わせを包含する。
【0105】
図７に示されるコンポーネントの数および配置は、一例として提供されている。実際には、入力ヒューマンインターフェースデバイスは、図７に示すものよりも、追加のコンポーネント、より少ないコンポーネント、異なるコンポーネント、または異なる配置のコンポーネントを含むことがある。追加的にまたは代替的に、入力ヒューマンインターフェースデバイスのコンポーネント（例えば、１つ以上のコンポーネント）のセットが、入力ヒューマンインターフェースデバイスのコンポーネントの別のセットによって実行されるように記載される１つ以上の機能を実行することがある。
【0106】
【0107】
図８は、複数の異種クライアントエンドポイントを提供する例示的なネットワークメディア配信システム８００を示している。すなわち、システム８００は、クライアントエンドポイントとしての様々なレガシーおよび異種の没入型メディア対応ディスプレイをサポートする。システム８００は、コンテンツ取得モジュール８０１と、コンテンツ準備モジュール８０２と、送信モジュール８０３とを含むことがある。
【0108】
コンテンツ取得モジュール８０１は、例えば、図６および／または図５に記載される実施形態を使用して、ソースメディアをキャプチャまたは作成する。コンテンツ準備モジュール８０２は、摂取フォーマットを生成し、次に、摂取フォーマットは、送信モジュール８０３を使用してネットワークメディア配信システムに送信される。ゲートウェイ８０４は、ネットワークのための様々なクライアントエンドポイントへのネットワークアクセスを提供するために、顧客構内機器にサービスを提供することがある。セットトップボックス８０５も、ネットワークサービスプロバイダによる集約されたコンテンツ(aggregated content)へのアクセスを提供するための顧客構内機器として機能することがある。無線復調器８０６は、例えば、モバイルハンドセットディスプレイ８１３で示されるように、モバイルデバイスのためのモバイルネットワークアクセスポイントとして機能することがある。システム８００のこの特定の実施形態において、レガシー２Ｄテレビジョン８０７は、ゲートウェイ８０４、セットトップボックス８０５、またはＷｉＦｉ（ルータ）８０８のうちの１つに直接接続されるように示されている。ラップトップ２Ｄディスプレイ８０９（すなわち、レガシー２Ｄディスプレイを有するコンピュータまたはラップトップ）は、ＷｉＦｉ８０８に接続されたクライアントエンドポイントとして示されている。ヘッドマウント２Ｄ（ラスタベースの）ディスプレイ８１０も、Ｗｉ－Ｆｉ（ルータ）８０８に接続される。レンチキュラー光照射野ディスプレイ８１１が、ゲートウェイ８０４のうちの１つに接続されて示されている。レンチキュラー光照射野ディスプレイ８１１は、１つ以上のＧＰＵｓ８１１Ａと、記憶デバイス８１１Ｂと、光線ベースのレンチキュラー光学技術を使用して複数のビューを生成する視覚プレゼンテーションコンポーネント８１１Ｃとを含むことがある。ホログラフィックディスプレイ８１２が、セットトップボックス８０５に接続されて示されている。ホログラフィックディスプレイ８１２は、１つ以上のＣＰＵｓ８１２Ａと、ＧＰＵｓ８１２Ｂと、記憶デバイス８１２Ｃと、可視化コンポーネント８１２Ｄとを含むことがある。可視化コンポーネント８１２Ｄは、フレネルパターン、波ベースのホログラフィックデバイス／ディスプレイであることがある。拡張現実（ＡＲ）ヘッドセット８１４が、無線復調器８０６に接続されて示されている。ＡＲヘッドセット８１４は、ＧＰＵ８１４Ａと、記憶デバイス８１４Ｂと、バッテリ８１４Ｃと、容積視覚プレゼンテーションコンポーネント８１４Ｄとを含むことがある。高密度光照射野ディスプレイ８１５が、ＷｉＦｉ（ルータ）８０８に接続されるように示されている。高密度光照射野ディスプレイ８１５は、１つ以上のＧＰＵｓ８１５Ａと、ＣＰＵｓ８１５Ｂと、記憶デバイス８１５Ｃと、眼追跡デバイス８１５Ｄと、カメラ８１５Ｅと、高密度光線ベースの光照射野パネル８１５Ｆとを含むことがある。
【0109】
図８に示されるコンポーネントの数および配置は、一例として提供されている。実際には、システム８００は、図８に示されるものよりも追加のコンポーネント、より少ないコンポーネント、異なるコンポーネント、または異なって配置されたコンポーネントを含むことがある。追加的にまたは代替的に、システム８００のコンポーネント（例えば、１つ以上のコンポーネント）のセットは、デバイスまたはそれぞれのディスプレイのコンポーネントの別のセットによって実行されるものとして記載される１つ以上の機能を実行することがある。
【0110】
図９は、図８に前述したようなレガシーおよび異種の没入型メディア対応ディスプレイにサービスを提供することができる没入型メディア配信プロセス９００の例示的なワークフローを示している。ネットワークによって実行される没入型メディア配信プロセス９００は、例えば、特定の没入型メディアクライアントエンドポイントによって（図１０を参照して記載されたように）消費のためにメディアを適合させるネットワークのプロセスの前に、メディア摂取フォーマットで表現される特定のメディアに関する適合情報を提供することがある。
【0111】
没入型メディア配信プロセス９００は、２つの部分、すなわち、破線９１２の左側にある没入型メディア生成と、破線９１２の右側にある没入型メディアネットワーク配信とに分割されることがある。没入型メディア生成および没入型メディアネットワーク配信は、ネットワークまたはクライアントデバイスによって実行されることがある。
【0112】
第１に、メディアコンテンツ９０１は、それぞれ、ネットワーク（またはクライアントデバイス）によって、あるいはコンテンツソースから作成されるか、あるいは獲得される。データを作成または獲得する方法は、例えば、それぞれ、自然コンテンツおよび合成コンテンツについて、図５および図６において具現されている。次に、作成されたコンテンツ９０１は、ネットワーク摂取フォーマット作成プロセス９０２を使用して摂取フォーマットに変換される。ネットワーク摂取生成プロセス９０２も、それぞれ、自然コンテンツおよび合成コンテンツについて図５および図６において具現されている。摂取フォーマットは、例えば、（図１０および図１４Ａを参照して後に詳述される）没入型メディアデータアナライザ９１１からの複雑性分析情報を格納するように更新されることもある。摂取フォーマットは、ネットワークに送信され、摂取メディア記憶装置９０３（すなわち、記憶デバイス）に格納される。幾つかの実施形態において、記憶デバイスは、没入型メディアコンテンツ生成者のネットワーク内にあることがあり、没入型メディアネットワーク配信９２０のために遠隔にアクセスされることがある。クライアントおよびアプリケーション特異な情報が、任意に、遠隔記憶デバイス、クライアント特異な情報９０４内で利用可能である。幾つかの実施形態において、クライアント特異な情報９０４は、代替的なクラウドネットワーク内に遠隔に存在することがあり、ネットワークに送信されることがある。
【0113】
次に、ネットワークオーケストレータ９０５(network orchestrator)が実行される。ネットワークオーケストレーション(network orchestration)は、ネットワークの主要なタスクを実行するための情報の一次ソースおよびシンクとして機能する。ネットワークオーケストレータ９０５は、ネットワークの他のコンポーネントと一体化されたフォーマットにおいて実装されることがある。ネットワークオーケストレータ９０５は、クライアントデバイスの特性に従ったメディアの全ての処理および配信を容易にするためにクライアントデバイスとともに双方向メッセージプロトコルをさらに使用するプロセスであることがある。さらに、双方向プロトコルは、異なる送達チャネル（例えば、コントロールプレーンチャネルおよび／またはデータプレーンチャネル）にわたって実装されることがある。
【0114】
図９に示されるように、ネットワークオーケストレータ９０５は、クライアントデバイス９０８の構成および属性に関する情報を受信する。ネットワークオーケストレータ９０５は、クライアントデバイス９０８上で現在動作しているアプリケーションに関する仕様を収集する。この情報は、クライアント特異な情報９０４から得られることがある。幾つかの実施形態では、この情報は、クライアントデバイス９０８に直接問い合わせることによって得られることがある。クライアントデバイスが直接問い合わされるときには、クライアントデバイス９０８がネットワークオーケストレータ９０５と直接通信することができるように、双方向プロトコルが存在し且つ動作すると仮定される。
【0115】
ネットワークオーケストレータ９０５は、（図１０に記載される）メディア適合および断片化モジュール９１０(media adaptation and fragmentation module)を開始し、これらと通信することがある。摂取メディアが、メディア適合および断片化モジュール９１０によって適合され且つ断片化されると、メディアは、配信のために準備されたメディアのように中間記憶デバイスに転送されることがある。配信メディアが準備され、配信９０９記憶デバイスのために準備されたメディアに格納されると、ネットワークオーケストレータ９０５は、クライアントデバイス９０８が、配信メディアおよび記述情報９０６を「プッシュ(push)」要求を通じて受信するか、あるいは、クライアントデバイス９０８が、配信９０９のために準備された記憶媒体から、配信メディアおよび記述情報９０６の「プル(pull)」要求を開始することがあることを確実にする。情報は、クライアントデバイス９０８のネットワークインターフェース９０８Ｂを介して「プッシュされる」か、あるいは「プルされる」ことがある。「プッシュされた」あるいは「プルされた」配信メディアおよび記述情報９０６は、配信メディアに対応する記述情報であることがある。
【0116】
幾つかの実施形態において、ネットワークオーケストレータ９０５は、「プッシュ」要求を実行するか、あるいはクライアントデバイス９０８による「プル」要求を開始するために、双方向メッセージインターフェースを使用する。クライアントデバイス９０８は、任意に、ＧＰＵｓ９０８Ｃ（またはＣＰＵｓ）を使用することがある。
【0117】
次に、配信メディアフォーマットは、クライアントデバイス９０８に含まれる記憶デバイスまたは記憶キャッシュ９０８Ｄに格納される。最後に、クライアントデバイス９０８は、視覚化コンポーネント９０８Ａを介してメディアを視覚的に提示する。
【0118】
没入型メディアをクライアントデバイス９０８にストリーミングするプロセスを通じて、ネットワークオーケストレータ９０５は、クライアント進行および状態フィードバックチャネル９０７を介してクライアントの進行の状態を監視(モニタリング)する。幾つかの実施形態において、状態の監視は、双方向通信メッセージインターフェースを通じて実行されることがある。
【0119】
図１０は、例えば、メディア適合及び断片化モジュール９１０によって実行される、メディア適合プロセス１０００の一例を示している。メディア適合プロセス１０００を実行することによって、摂取されたソースメディアは、クライアント（例えば、クライアントデバイス９０８）の仕様に整合する(match)ように適切に適合される(adapted)ことがある。
【0120】
図１０に示されるように、メディア適合プロセス１０００は、クライアントデバイス９０８のための適切な配信フォーマットへの摂取メディアの適応を容易にする複数のコンポーネントを含む。図１０に示されるコンポーネントは、例示的なものとみなされるべきである。実際には、メディア適合プロセス１０００は、図１０に示されるものよりも追加のコンポーネント、より少ないコンポーネント、異なるコンポーネント、または異なって配置されるコンポーネントを含むことがある。追加的にまたは代替的に、メディア適合プロセス１０００のコンポーネント（例えば、１つ以上のコンポーネント）のセットが、コンポーネントの別のセットによって実行されるものとして記載される１つ以上の機能を実行することがある。
【0121】
図１０において、適合モジュール１００１は、ネットワーク上の現在のトラフィック負荷を追跡するために、ネットワーク状態１００５を入力する。既述のように、適合モジュール１００１は、ネットワークオーケストレータ９０５からも情報を受信する。情報は、クライアントデバイス９０８の属性および構成記述と、アプリケーション構成および記述と、アプリケーションの現在の状態と、クライアントの錐台の幾何学的形状を摂取没入型メディアの補間能力にマッピングするのを助けるクライアントＮＮモデルとを含むことがある。そのような情報は、双方向メッセージインターフェースによって得られることがある。適合モジュール１００１は、適合出力が生成されたときに、適合出力がクライアント適合メディア１００６を格納する記憶デバイスに格納されることを確実にする。
【0122】
没入型メディアデータアナライザ９１１は、先験的にあるいはメディアの配信のためのネットワーク自動化プロセスの一部として実行されることがある任意的なプロセスであることがある。没入型メディアデータアナライザ９１１は、摂取メディアフォーマットおよび資産を記憶デバイス１００２に格納することがある。次に、摂取メディアフォーマットおよび資産は、記憶デバイス１００２から適合モジュール１００１に送信されることがある。
【0123】
適合モジュール１００１は、論理コントローラ１００１Ｆによって制御されることがある。適合モジュール１００１は、レンダラ１００１Ｂまたはプロセッサ１００１Ｃを使用して、特定の摂取ソースメディアをクライアントに適したフォーマットに適合させることもある。プロセッサ１００１Ｃは、ＮＮベースのプロセッサであることがある。プロセッサ１００１Ｃは、ＮＮモデル１００１Ａを使用する。そのようなプロセッサ１００１Ｃの例は、ＭＰＩおよびＭＳＩに記載されているようなＤｅｅｐｖｉｅｗ ＮＮモデルジェネレータを含む。メディアが２Ｄフォーマットにあるが、クライアントが３Ｄフォーマットを持たなければならないならば、プロセッサ１００１Ｃは、２Ｄビデオ信号からの高度に相関した画像を使用して、メディアに描かれたシーンの容積表現を導出するプロセスを呼び出すことがある。
【0124】
レンダラ１００１Ｂは、音響物理学、光物理学、視覚知覚、オーディオ知覚、数学、およびソフトウェア開発に関する学問分野の選択的な混合に基づく、ソフトウェアベース（またはハードウェアベース）のアプリケーションまたはプロセスであることがあり、それは、入力シーングラフおよび資産コンテナが与えられると、ターゲットとされるデバイス上でのプレゼンテーションに適した、またはシーングラフ内のレンダリングターゲットノードの属性によって指定されるような所望の特性に適合する、（典型的に）視覚信号および／またはオーディオ信号を発する。視覚ベースのメディア資産の場合、レンダラは、ターゲットとされるディスプレイまたは（例えば、別のコンテナに再パッケージ化され、グラフィックスパイプラインにおける一連のレンダリングプロセスで使用される）中間資産としての保存に適した視覚信号を発することがある。オーディオベースのメディア資産の場合、レンダラは、マルチチャネルラウドスピーカおよび／または双ナウラライズされた(re-nauralized)ヘッドフォンでのプレゼンテーションのために、あるいは別の（出力）コンテナへの再パッケージ化のために、オーディオ信号を発することがある。レンダラは、例えば、ソースおよびクロスプラットフォームゲームエンジンのリアルタイムレンダリング構成を含む。レンダラは、ランタイムにレンダラによって実行されて、シーングラフノードに対して行われた動的入力および可変状態変化を処理することがある、スクリプト言語（すなわち、解釈されたプログラミング言語）を含むことがある。動的入力および可変状態変化は、（物理的力、制約、逆運動学、変形、衝突を含む）空間的および時間的オブジェクトトポロジーのレンダリングおよび評価、ならびにエネルギー伝搬および輸送（光、音）に影響を及ぼすことがある。空間的および時間的オブジェクトのトポロジーの評価は、出力を抽象から具体的な結果に移動させる（例えば、ウェブページの文書オブジェクトモデルの評価に類似する）結果を生成する。
【0125】
レンダラ１００１Ｂは、例えば、適合モジュール１００１と直接対話するように修正されるＯＴＯＹ Ｏｃｔａｎｅレンダラの修正バージョンであることがある。幾つかの実施形態において、レンダラ１００１Ｂは、シーンの照明が現実に忠実であるように、三次元シーンをレンダリングするコンピュータグラフィックス方法（例えば、経路トレーシング(path tracing)）を実装する。幾つかの実施形態において、レンダラ１００１Ｂは、元々はシェーダ（すなわち、シェーディング（画像内の光、暗さ、および色の適切なレベルの生成）のために使用されたが、今ではコンピュータグラフィックス特殊効果の様々な分野、シェーディングとは無関係のビデオ後処理、およびグラフィックスとは無関係の他の機能において、様々な特殊化された機能を実行する、コンピュータプログラムのタイプ）を使用することがある。
【0126】
適合モジュール１００１は、摂取メディアのフォーマットおよびクライアントデバイス９０８によって要求されるフォーマットに基づいた圧縮および解凍の必要性に依存して、メディア圧縮器１００１Ｄおよびメディア解凍器１００１Ｅをそれぞれ使用して、メディアコンテンツの圧縮および解凍を実行することがある。メディア圧縮器１００１Ｄは、メディアエンコーダであることがあり、メディア解凍器１００１Ｅは、メディアデコーダであることがある。（必要であるならば）圧縮および解凍を実行した後に、適合モジュール１００１は、クライアントデバイス９０８へのストリーミングまたは配信に最適なクライアント適合メディア１００６を出力する。クライアント適合メディア１００６は、適合メディアを格納するための記憶デバイスに格納されることがある。
【0127】
図１１は、例示的な配信フォーマット作成プロセス１１００を示している。図１１に示されるように、配信フォーマット作成プロセス１１００は、メディア適合プロセス１０００から出力されかつクライアント適合メディア１００６として格納されたメディアをパッケージ化する適合メディアパッケージ化モジュール１１０３を含む。メディアパッケージングモジュール１１０３は、クライアント適合メディア１００６からの適合メディアを堅牢な配信フォーマット１１０４にフォーマット化する。配信フォーマットは、例えば、図３または図４に示される例示的なフォーマットであることがある。情報マニフェスト１１０４Ａ(information manifest)が、シーンデータ資産１１０４Ｂのリストをクライアントデバイス９０８に提供することがある。シーンデータ資産１１０４Ｂのリストは、シーンデータ資産１１０４Ｂのリスト内の資産の全ての複雑性を記述する複雑性メタデータを含むこともある。シーンデータ資産１１０４Ｂのリストは、視覚資産、オーディオ資産、および触覚資産のリストを示し、各々は、それぞれに対応するメタデータを持つ。
【0128】
メディアは、ストリーミング前にさらにパケット化されることがある。図１２は、例示的なパケット化プロセス１２００(packetizing process)を示している。パケット化システム１２００は、パケット化装置１２０２(packetizer)を含む。パケット化装置１２０２は、（図１２に示すように）シーンデータ資産１１０４Ｂのリストを入力メディア１２０１として受信することがある。幾つかの実施形態において、クライアント適合メディア１００６または配信フォーマット１１０４は、パケット化装置１２０２に入力される。パケット化装置１２０２は、入力メディア１２０１を、ネットワーク上のクライアントデバイス９０８への表現およびストリーミングに適した個々のパケット１２０３に分離する。
【0129】
図１３は、実施形態によるコンポーネント間のデータおよび通信の流れの一例を示すシーケンス図である。図１３のシーケンス図は、摂取フォーマットにある特定の没入型メディアを特定の没入型クライアントエンドポイントのためのストリーミング可能で適切な配信フォーマットに適合させるネットワークの図である。データおよび通信の流れは、以下の通りである。
【0130】
クライアントデバイス９０８は、ネットワークオーケストレータ９０５に対するメディア要求１３０８を開始する。幾つかの実施形態において、要求は、クライアントデバイスのネットワーク配信インターフェースに対して行われることがある。メディア要求１３０８は、クライアントデバイス９０８によって要求されるメディアを識別するための情報を含む。メディア要求は、例えば、ユニフォームリソースネーム（ＵＲＮ）または別の標準命名法によって識別されることがある。次に、ネットワークオーケストレータ９０５は、プロファイル要求１３０９でメディア要求１３０８に応答する。プロファイル要求１３０９は、クライアントが、（クライアントの現在の動作状態を特徴付ける計算、記憶装置、充電されたバッテリの割合、および他の情報を含む）現在利用可能なリソースに関する情報を提供することを要求する。プロファイル要求１３０９は、そのようなＮＮモデルがクライアントエンドポイントで利用可能であるならば、クライアントが、クライアントのプレゼンテーションシステムの構成に一致するように、正しいメディアビューを抽出または補間するために、ＮＮ推論のためにネットワークによって使用されることがある１つ以上のＮＮモデルを提供することも要求する。
【0131】
次に、クライアントデバイス９０８は、クライアントデバイス９０８から、クライアントトークン、アプリケーショントークン、および（そのようなＮＮＮモデルトークンがクライアントエンドポイントで利用可能であるならば）１つ以上のＮＮモデルトークンとして提供されるネットワークオーケストレータ９０５への応答１３１０に従う。次に、ネットワークオーケストレータ９０５は、クライアントデバイスにセッションＩＤトークン１３１１を提供する。次に、ネットワークオーケストレータ９０５は、摂取メディアサーバ１３０３からの摂取メディア１３１２を要求する。摂取メディアサーバ１３０３は、例えば、摂取メディア記憶装置９０３または摂取メディアフォーマットおよび記憶デバイス１００２の資産を含むことがある。摂取メディア１３１２についての要求は、要求１３０８において識別されるメディアについてのＵＲＮまたは他の標準名を含むこともある。摂取メディアサーバ１３０３は、摂取メディア１３１２要求に対して、摂取メディアトークンを含む応答１３１３で応答する。次に、ネットワークオーケストレータ９０５は、呼び出し１３１４における応答１３１３からのメディアトークンをクライアントデバイス９０８に提供する。次に、ネットワークオーケストレータ９０５は、適応および断片化モジュール９１０に、摂取メディアトークン、クライアントトークン、アプリケーショントークン、およびＮＮモデルトークンを提供することによって、要求１３１５における要求されたメディアのための適合プロセスを開始する。適合および断片化モジュール９１０は、摂取メディア資産へのアクセスを要求する要求１３１６で、摂取メディアサーバ１３０３に摂取メディアトークンを提供することによって摂取メディアへのアクセスを要求する。
【0132】
摂取メディアサーバ１３０３は、適合および断片化モジュール９１０に対する応答１３１７において、摂取メディアアクセストークンで要求１３１６に応答する。次に、適合および断片化モジュール９１０は、メディア適合プロセス１０００が、クライアント、アプリケーション、および応答１３１３で作成および送信されるセッションＩＤトークンに対応するＮＮ推論モデルのために、摂取メディアアクセストークンに位置する摂取メディアを適合することを要求する。適合および断片化モジュール９１０からメディア適合プロセス１０００への要求１３１８が行われる。要求１３１８は、所要のトークンおよびセッションＩＤを含む。メディア適合プロセス１０００は、更新応答１３１９において、ネットワークオーケストレータ９０５に、適合メディアアクセストークンおよびセッションＩＤを提供する。次に、ネットワークオーケストレータ９０５は、インターフェース呼び出し１３２０において、メディアパッケージ化モジュール１１０３に、適合メディアアクセストークンおよびセッションＩＤを提供する。メディアパッケージ化モジュール１１０３は、応答１３２１において、ネットワークオーケストレータ９０５への応答１３２１に、パッケージ化されたメディアアクセストークンおよびセッションＩＤを提供する。次に、メディアパッケージ化モジュール１１０３は、応答１３２２において、セッションＩＤのためのパッケージ化された資産、ＵＲＮ、およびセッションＩＤのためのパッケージ化されたメディアアクセストークンを、格納されるべきパッケージ化メディアサーバ１３０７に提供する。続いて、クライアントデバイス９０８は、パッケージ化メディアサーバ１３０７に対する要求１３２３を実行して、応答１３２１において受信されるパッケージ化メディアアクセストークンに対応するメディア資産のストリーミングを開始する。最後に、クライアントデバイス９０８は、他の要求を実行し、メッセージ１３２４における状態更新をネットワークオーケストレータ９０５に提供する。
【0133】
図１４Ａは、図９に示される没入型メディアデータアナライザ９１１のためのワークフローを示している。没入型メディアデータアナライザ９１１は、メディアデータに含まれるシーンのオブジェクトの複雑性を分析する。
【0134】
Ｓ１４０１で、メディアデータが、例えば、コンテンツプロバイダから取得される。Ｓ１４０２で、オブジェクトデータが、メディアデータ内のシーンから読み出される。オブジェクトデータは、１つ以上のオブジェクトからのデータを含むことがある。幾つかの実施形態において、オブジェクトデータは、シーン内のオブジェクトのセットに対応するデータである。幾つかの実施形態において、オブジェクトデータは、メディアデータから直接抽出される。
【0135】
Ｓ１４０３で、オブジェクトデータが成功裡に読み出されたかどうかを決定する決定プロセスが実行される。データが成功裡に読み出されないならば（Ｓ１４０３でＮＯ）、処理は、Ｓ１４０９に続く。Ｓ１４０９で、没入型メディアデータアナライザ９１１の分析が終了する。データが成功裡に読み出されるならば（Ｓ１４０３でＹＥＳ）、処理は、Ｓ１４０４に続く。Ｓ１４０４で、オブジェクトの属性（以下、「属性情報」）が、オブジェクトデータから読み出されるか、あるいは取り出される。幾つかの実施形態において、属性情報は、オブジェクトデータからのオブジェクトを記述するアクセス属性に構文解析される。属性情報に含まれる各属性は、Ｓ１４０５への入力として提供される。
【0136】
Ｓ１４０５で、Ｓ１４０４で読み出された／取り出された属性が検査されて、属性が（図１４Ｂに示される）複雑性属性１４１０のリストに含まれるかどうかが決定される。読み出された／取り出された属性が複雑性属性１４１０のリストに含まれる複雑性属性の１つであるならば（Ｓ１４０５でＹＥＳ）、処理は、Ｓ１４０６に続く。Ｓ１４０６で、複雑性属性の値が取り出される。値は、複雑性属性の複雑性のレベルに基づいて事前定義されることがある。次に、値は、オブジェクトのための（例えば、記憶デバイス内の）複雑性要約（または分析要約）領域に格納される。複雑性要約内の情報は、オブジェクトの複雑性情報である。次に、処理は、Ｓ１４０７に進む。
【0137】
読み出された／取り出された属性が、複雑性属性１４１０のリストに含まれる複雑性属性の１つでないならば（Ｓ１４０５におけるＮＯ）、処理は、Ｓ１４０７に続く。Ｓ１４０７で、オブジェクトから読み出すべきより多くの属性があるかどうかが決定される。読み出されるべき属性がそれ以上ないならば、処理は、Ｓ１４０８に続く。
【0138】
幾つかの実施形態において、オブジェクトについての全ての属性は、Ｓ１４０４で読み出される。この場合、Ｓ１４０７は、全ての属性が検査されたかどうかを決定する。それらが全て検査されているならば、処理は、Ｓ１４０８に進む。それらが全て検査されていないならば、処理は、Ｓ１４０５に続くことがある。
【0139】
Ｓ１４０８で、オブジェクトについての複雑性要約が、オブジェクトを包含するシーンについての複雑性データを格納するために識別された領域に書き込まれる。シーン内の様々なオブジェクトの複雑性要約は、シーンの複雑性の要約に集約され、かつ格納される。次に、シーンの集約された複雑性要約は、シーンについての複雑性データを格納するために識別された領域（例えば、シーンのビットストリーム内の場所）に書き込まれることがある。次に、処理は、Ｓ１４０２に続き、そこでは、次のオブジェクトまたは別のオブジェクトが、シーンから読み出される。さらに、コンテンツプロバイダから受信されるメディアデータの摂取フォーマットを変換する決定または変換するかどうかが、シーンについての複雑性データに基づいて決定されることがある。摂取データの転換の必要性は、シーン毎に決定されることがある。幾つかの実施形態では、フォーマットが転換される必要があるかどうかは、摂取データ（すなわち、コンテンツプロバイダから受信されるメディアデータ）内の全てのシーンの複雑性データの集約に基づいて決定される。
【0140】
図１３～図１４を参照して記載されるシーケンス図およびワークフローにおけるステップは、実施形態におけるデータおよび通信フローの構成を制限することを意図しないことに留意のこと。例えば、ステップのうちの１つ以上は、同時に実行されることがあり、データは、図１３～図１４Ａなどのフローに明示的に示されていない方向に格納されるおよび／または流れることがある。
【0141】
図１４Ｂは、実施形態による、複雑性属性１４１０のリストの一例である。複雑性属性１４１０のリストは、先験的に識別されることがあり、あるいは、ネットワークまたはクライアントデバイスによって事前に定義されることがある。Ｓ１４０５で決定を行うために、没入型メディアデータアナライザ９１１は、例えば、属性情報を複雑性属性１４１０のリスト内の複雑性属性と比較することがある。複雑性属性のリスト１４１０内の複雑性属性は、限定されるものではないが、オブジェクトを処理するのに必要とされる記憶装置の量に影響を与えるオブジェクトのサイズ、ＧＰＵによって必要とされる処理の量の指標であることがあるオブジェクトについてのポリゴンの数、ＧＰＵまたはＣＰＵによって必要とされる処理の量の指標であることがある固定小数点対浮動小数点の数値表現、ＧＰＵまたはＣＰＵによって必要とされる処理の量の指標であることもあるビット深度、処理されるときにデータ値のサイズの指標であることがある単一浮動小数点対二重浮動小数点の数値表現、光がシーンのためにどのように配光されるかの物理学をモデル化するプロセスをシーンが受ける必要があることを示すことがある配光関数の存在、光の物理学をモデル化するために配光関数の複雑性を示すことがある配光関数の種類、オブジェクトがどのようにシーン内に（回転、並進、およびスケーリングを介して）配置される必要があるかの複雑性を示すことがある（存在する場合の）所要の変換プロセスを含むことがある。
【0142】
図１５は、実施形態による、シーンのオブジェクトの複雑性を特徴付けるためのコンピュータコード１５００の一例のブロック図である。実施形態において、コンピュータコードは、例えば、プログラムコードまたはコンピュータプログラムコードであることがある。本開示の実施形態によれば、コンピュータプログラムコードを格納するメモリを備える少なくとも１つのプロセッサを含む装置／デバイスが提供されることがある。コンピュータプログラムコードは、少なくとも１つのプロセッサによって実行されるときに、本開示の任意の数の態様を実行するように構成されることがある。
【0143】
図１５に示されるように、コンピュータコード１５００は、受信コード１５１０と、取得コード１５２０と、分析コード１５３０と、生成コード１５４０と、決定コード１５５０とを含むことがある。
【0144】
受信コード１５１０は、少なくとも１つのプロセッサに、コンテンツソースから複数のシーンを含む没入型メディアデータを受信させるように構成される。
【0145】
取得コード１５２０は、少なくとも１つのプロセッサに、没入型メディアデータから、複数のシーンにおけるそれぞれのシーンのそれぞれのオブジェクトを取得させるように構成される。
【0146】
分析コード１５３０は、少なくとも１つのプロセッサに、それぞれのシーンを分析させて、それぞれのシーンのそれぞれのオブジェクトに関連する複雑性情報を生成させるように構成される。
【0147】
生成コード１５４０は、少なくとも１つのプロセッサに、それぞれのシーンのそれぞれのオブジェクトに関連付けられたメタデータを生成させるように構成され、メタデータは、複雑性情報を含む。
【0148】
決定コード１５５０は、少なくとも１つのプロセッサに、生成されるメタデータに基づいた処理のために、それぞれのシーンをクライアントに配信するかどうかを決定させるように構成される。
【0149】
図１５は、コードのブロックの例を示しているが、幾つかの実装において、装置／デバイスは、図１５に示されるものよりも追加のブロック、より少ないブロック、異なるブロック、または異なって配置されたブロックを含むことがある。追加的にまたは代替的に、装置／デバイスのブロックのうちの２つ以上は、組み合わされることがある。換言すれば、図１５は、コードの別個のブロックを示しているが、様々なコード命令は、別個である必要はなく、混在し得る。
【0150】
本開示は、幾つかの例示的な実施形態を記載しているが、本開示の範囲内に入る変更、置換、および様々な代替的な均等物がある。よって、当業者は、本明細書に明示的に示されていないか、あるいは記載されていないが、本開示の原理を具体化し、よって、本開示の精神および範囲内にある、多くのシステムおよび方法を考案することができることが理解されるであろう。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14A】
【図14B】
【図15】
【国際調査報告】