特許 7480432 メディアシーン記述のための方法および装置

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-04-26

(45)【発行日】2024-05-09

(54)【発明の名称】メディアシーン記述のための方法および装置

(51)【国際特許分類】

   H04N 21/83 20110101AFI20240430BHJP

   H04N 21/84 20110101ALI20240430BHJP

【ＦＩ】

H04N21/83

H04N21/84

【請求項の数】 9

(21)【出願番号】P 2023518014

(86)(22)【出願日】2021-10-07

(65)【公表番号】

(43)【公表日】2023-10-24

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

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

(87)【国際公開日】2022-07-21

【審査請求日】2023-03-17

(31)【優先権主張番号】63/137,274

(32)【優先日】2021-01-14

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

(31)【優先権主張番号】17/477,134

(32)【優先日】2021-09-16

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

(73)【特許権者】

【識別番号】520353802

【氏名又は名称】テンセント・アメリカ・エルエルシー

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100150197

【弁理士】

【氏名又は名称】松尾 直樹

(72)【発明者】

【氏名】シュアイ・ジャオ

(72)【発明者】

【氏名】ステファン・ヴェンガー

(72)【発明者】

【氏名】シャン・リュウ

【審査官】岩井 健二

(56)【参考文献】

【文献】国際公開第２０２２／１５００８０（ＷＯ，Ａ１）

【文献】国際公開第２０２２／１５００７７（ＷＯ，Ａ１）

【文献】米国特許出願公開第２０２０／０１０４５２２（ＵＳ，Ａ１）

【文献】中国特許出願公開第１１０７５１６９６（ＣＮ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｎ ２１／００ － ２１／８５８

(57)【特許請求の範囲】

【請求項1】

メディアの記憶および配信を管理する方法であって、前記方法は、少なくとも1つのプロセッサによって実施され、
メディアアクセス機能（MAF）により、シーンに対応するglTF（Graphics Language Transmission Format）ファイルを取得するステップと、
前記glTFファイルがCBOR（Concise Binary Object Representation）フォーマットを有すると判定するステップと、
前記MAFによって実装された第1のCBORパーサ関数を使用して、前記glTFファイルを、JSON（JavaScript Object Notation）フォーマットを有する変換されたglTFファイルに変換するステップと、
前記変換されたglTFファイルに基づいて、前記シーンに対応するメディアコンテンツを取得するステップと
を含む、方法。

【請求項2】

前記JSONフォーマットを有する前記変換されたglTFファイルは、前記CBORフォーマットを有する前記glTFファイルよりも大きい、請求項1に記載の方法。

【請求項3】

前記MAFは、ムービングピクチャエクスパーツグループ（MPEG）シーン記述アーキテクチャに含まれる、請求項1に記載の方法。

【請求項4】

前記第1のCBORパーサ関数は、前記MAFと関連付けられたアプリケーションプログラミングインターフェースを使用して実装される、請求項1に記載の方法。

【請求項5】

前記MAFによって実装されたJSONパーサ関数を使用して、前記変換されたglTFファイルを、前記CBORフォーマットを有する再変換されたglTFファイルに再変換するステップと、
前記再変換されたglTFファイルを、ローカルストレージまたはキャッシュの少なくとも一方に記憶するステップと
をさらに含む、請求項1に記載の方法。

【請求項6】

前記CBORフォーマットを有する前記再変換されたglTFファイルは、前記JSONフォーマットを有する前記変換されたglTFファイルよりも小さい、請求項5に記載の方法。

【請求項7】

前記JSONパーサ関数は、前記MAFと関連付けられたアプリケーションプログラミングインターフェースを使用して実装される、請求項5に記載の方法。

【請求項8】

メディアの記憶および配信を管理するためのデバイスであって、前記デバイスは、
プログラムコードを記憶するように構成された少なくとも1つのメモリと、
前記プログラムコードを読み出し、前記プログラムコードによって命令されるように動作するように構成された少なくとも1つのプロセッサと
を備え、前記プログラムコードは、前記少なくとも1つのプロセッサに、請求項1から7のいずれか一項に記載の方法を行わせる、デバイス。

【請求項9】

コンピュータに、請求項1から7のいずれか一項に記載の方法を行わせる、コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本出願は、2021年1月14日に出願された米国仮特許出願第63/137,274号および2021年9月16日に出願された米国特許出願第17/477,134号の優先権を主張し、これらの開示はその全体が参照により本明細書に組み込まれる。

【0002】

本開示の実施形態は、3Dモデリング構文を使用してメディアオブジェクトをサポートし、様々なメディアコーデック、コンテナ、およびフォーマットをサポートするメディア構文を実装し、所定のプログラミングインターフェースを介してメディアの記憶および配信方法を管理し、メディアのバッファ制御およびレンダリング機能を提供するためのシステム設計に関する。

【背景技術】

【0003】

glTF（Graphics Language Transmission Format）は、API中立なランタイムアセット3Dモデリング配信フォーマットである。従来の3Dモデリングツールと比べて、glTFは、3Dコンテンツの伝送およびロードのためのより効率的で拡張可能かつ相互運用可能なフォーマットを提供する。glTF 2.0は、Khronos 3D Groupによって書かれたglTF仕様の最新バージョンである。このフォーマットは、「png」および「jpeg」画像フォーマットを含む、一般にシーン内の静的（非時限）オブジェクトをサポートすることができる単純なシーングラフフォーマットをサポートする。glTF 2.0は、単純なアニメーションをサポートしており、これは、glTFプリミティブを使用して記述された基本形状、すなわち幾何学的オブジェクトの並進、回転、およびスケーリングのサポートを含む。glTF 2.0は時限メディアをサポートしておらず、したがって、ビデオもオーディオもサポートしていない。

【0004】

「Information technology - Coding of audiovisual objects - Part 12: ISO base media file format」，ISO/IEC 14496-12（2015年12月）、「Draft of FDIS of ISO/IEC 23000-19 Common Media Application Format for Segmented Media」，ISO/IEC JTC1/SC29/WG11 MPEG117/16819（2017年4月）、および「Text of ISO/IEC FDIS 23009-1 4th edition」，ISO/IEC JTC 1/SC 29/WG 11 N18609（2019年8月）、ならびにglTF 2.0仕様は、その全体が参照により本明細書に組み込まれる。

【発明の概要】

【課題を解決するための手段】

【0005】

一実施形態によれば、メディアの記憶および配信を管理する方法は、少なくとも1つのプロセッサによって実施され、メディアアクセス機能（MAF）により、シーンに対応するglTFファイルを取得するステップと、glTFファイルがCBORフォーマットを有すると判定するステップと、MAFによって実装された第1のCBORパーサ関数を使用して、glTFファイルを、JSONフォーマットを有する変換されたglTFファイルに変換するステップと、変換されたglTFファイルに基づいて、シーンに対応するメディアコンテンツを取得するステップと、を含む。

【0006】

一実施形態によれば、メディアの記憶および配信を管理するためのデバイスは、プログラムコードを記憶するように構成された少なくとも1つのメモリと、プログラムコードを読み出し、プログラムコードによって命令されるように動作するように構成された少なくとも1つのプロセッサと、を含み、プログラムコードは、少なくとも1つのプロセッサに、メディアアクセス機能（MAF）により、シーンに対応するglTFファイルを取得させるように構成された第1の取得コードと、少なくとも1つのプロセッサに、glTFファイルがCBORフォーマットを有すると判定させるように構成された第1の判定コードと、少なくとも1つのプロセッサに、MAFによって実装された第1のCBORパーサ関数を使用して、glTFファイルを、JSONフォーマットを有する変換されたglTFファイルに変換させるように構成された第1の変換コードと、少なくとも1つのプロセッサに、変換されたglTFファイルに基づいて、シーンに対応するメディアコンテンツを取得させるように構成された第2の取得コードと、を含む。

【0007】

一実施形態によれば、非一時的コンピュータ可読媒体は、命令を記憶しており、命令は、メディアの記憶および配信を管理するためのデバイスの少なくとも1つのプロセッサによって実行されると、少なくとも1つのプロセッサに、メディアアクセス機能（MAF）により、シーンに対応するglTFファイルを取得することと、glTFファイルがCBORフォーマットを有すると判定することと、MAFによって実装された第1のCBORパーサ関数を使用して、glTFファイルを、JSONフォーマットを有する変換されたglTFファイルに変換することと、変換されたglTFファイルに基づいて、シーンに対応するメディアコンテンツを取得することと、を行わせるように構成されている1つまたは複数の命令を含む。

【0008】

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

【図面の簡単な説明】

【0009】

【図1】実施形態による、本明細書に記載される方法、装置、およびシステムが実施されうる環境の図である。

【図2】実施形態による、図1の1つまたは複数のデバイスの例示的な構成要素のブロック図である。

【図3】実施形態による、glTFシーン記述オブジェクトの概略図である。

【図4】実施形態による、メディアシーン記述システムリファレンスアーキテクチャの概略図である。

【図5】実施形態による、glTF JSON（JavaScript Object Notation）フォーマット表現の一例である。

【図6】実施形態による、MPEG glTF拡張の一例である。

【図7A】実施形態による、JSONフォーマットを有するファイルの図である。

【図7B】実施形態による、CBORフォーマットを有するファイルの図である。

【図8】実施形態による、glTF構文の一例の図である。

【図9A】実施形態による、メディアの記憶および配信を管理するための例示的なプロセスの図である。

【図9B】実施形態による、メディアの記憶および配信を管理するための例示的なプロセスの図である。

【図9C】実施形態による、メディアの記憶および配信を管理するための例示的なプロセスの図である。

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

【0010】

図1は、実施形態による、本明細書に記載される方法、装置、およびシステムが実施されうる環境100の図である。図1に示されるように、環境100は、ユーザデバイス110と、プラットフォーム120と、ネットワーク130とを含みうる。環境100のデバイスは、有線接続、無線接続、または有線接続と無線接続との組合せを介して相互接続しうる。

【0011】

ユーザデバイス110は、プラットフォーム120と関連付けられた情報を受信、生成、記憶、処理、および／または提供することができる1つまたは複数のデバイスを含む。例えば、ユーザデバイス110は、コンピューティングデバイス（例えば、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、ハンドヘルドコンピュータ、スマートスピーカ、サーバなど）、携帯電話（例えば、スマートフォン、無線電話など）、ウェアラブルデバイス（例えば、スマートグラスやスマートウォッチなど）、または同様のデバイスを含みうる。いくつかの実装形態では、ユーザデバイス110は、プラットフォーム120から情報を受信し、かつ／またはプラットフォーム120に情報を送信しうる。

【0012】

プラットフォーム120は、本明細書の他の箇所に記載されるような1つまたは複数のデバイスを含む。いくつかの実装形態では、プラットフォーム120は、クラウドサーバまたはクラウドサーバ群を含みうる。いくつかの実装形態では、プラットフォーム120は、特定の必要に応じてソフトウェア構成要素がスワップインまたはスワップアウトされうるようにモジュール式に設計されうる。そのため、プラットフォーム120は、異なる用途向けに、容易に、かつ／または迅速に再構成されうる。

【0013】

いくつかの実装形態では、図示のように、プラットフォーム120は、クラウドコンピューティング環境122下でホストされうる。特に、本明細書に記載される実装形態は、プラットフォーム120をクラウドコンピューティング環境122内でホストされているものとして説明しているが、いくつかの実装形態では、プラットフォーム120は、クラウドベースでない場合もあり（すなわち、クラウドコンピューティング環境の外部で実装される場合もあり）、または部分的にクラウドベースのある場合もある。

【0014】

クラウドコンピューティング環境122は、プラットフォーム120をホストする環境を含む。クラウドコンピューティング環境122は、プラットフォーム120をホストする（1つもしくは複数の）システムおよび／または（1つもしくは複数の）デバイスの物理的な位置と構成に関するエンドユーザ（例えば、ユーザデバイス110）の知識を必要としない計算、ソフトウェア、データアクセス、ストレージなどのサービスを提供しうる。図示のように、クラウドコンピューティング環境122は、一群のコンピューティングリソース124（「コンピューティングリソース124」と総称され、個別に「コンピューティングリソース124」と呼ばれる）を含みうる。

【0015】

コンピューティングリソース124は、1つまたは複数のパーソナルコンピュータ、ワークステーションコンピュータ、サーバデバイス、または他のタイプの計算および／または通信デバイスを含む。いくつかの実装形態では、コンピューティングリソース124は、プラットフォーム120をホストしうる。クラウドリソースは、コンピューティングリソース124内で実行される計算インスタンス、コンピューティングリソース124内で提供されるストレージデバイス、コンピューティングリソース124によって提供されるデータ転送デバイスなどを含んでいてもよい。いくつかの実装形態では、コンピューティングリソース124は、有線接続、無線接続、または有線接続と無線接続との組合せを介して他のコンピューティングリソース124と通信しうる。

【0016】

図1にさらに示されるように、コンピューティングリソース124は、1つまたは複数のアプリケーション（「APP」）124-1、1つまたは複数の仮想マシン（「VM」）124-2、仮想化ストレージ（「VS」）124-3、1つまたは複数のハイパーバイザ（「HYP」）124-4などのクラウドリソース群を含む。

【0017】

アプリケーション124-1は、ユーザデバイス110および／またはプラットフォーム120に提供されうるかまたはアクセスされうる1つまたは複数のソフトウェアアプリケーションを含む。アプリケーション124-1は、ユーザデバイス110にソフトウェアアプリケーションをインストールして実行する必要性を排除しうる。例えば、アプリケーション124-1は、プラットフォーム120と関連付けられたソフトウェア、および／またはクラウドコンピューティング環境122を介して提供されることが可能な他の任意のソフトウェアを含んでいてもよい。いくつかの実装形態では、1つのアプリケーション124-1が、仮想マシン124-2を介して、1つまたは複数の他のアプリケーション124-1に情報を送信し／1つまたは複数の他のアプリケーション124-1から情報を受信しうる。

【0018】

仮想マシン124-2は、物理マシンのようにプログラムを実行するマシン（例えば、コンピュータ）のソフトウェア実装を含む。仮想マシン124-2は、仮想マシン124-2による用途および任意の実マシンとの対応関係の度合いに応じて、システム仮想マシンまたはプロセス仮想マシンのいずれかでありうる。システム仮想マシンは、完全なオペレーティングシステム（「OS」）の実行をサポートする完全なシステムプラットフォームを提供しうる。プロセス仮想マシンは、単一のプログラムを実行し、単一のプロセスをサポートしうる。いくつかの実装形態では、仮想マシン124-2は、ユーザ（例えば、ユーザデバイス110）に代わって実行し、データ管理、同期、長時間のデータ転送などのクラウドコンピューティング環境122のインフラストラクチャを管理しうる。

【0019】

仮想化ストレージ124-3は、コンピューティングリソース124のストレージシステムまたはデバイス内で仮想化技術を使用する、1つもしくは複数のストレージシステムおよび／または1つもしくは複数のデバイスを含む。いくつかの実装形態では、ストレージシステムのコンテキスト内で、仮想化のタイプは、ブロック仮想化およびファイル仮想化を含みうる。ブロック仮想化は、当該ストレージシステムが物理ストレージや異種構造を考慮せずにアクセスされうるような物理ストレージからの論理ストレージの抽象化（または分離）を指しうる。この分離により、ストレージシステムの管理者がエンドユーザのストレージを管理する方法に柔軟性がもたらされうる。ファイル仮想化は、ファイルレベルでアクセスされるデータとファイルが物理的に記憶されている場所との間の依存関係を排除しうる。これにより、ストレージ使用の最適化、サーバの統合、および／または中断のないファイル移行の実行が可能となりうる。

【0020】

ハイパーバイザ124-4は、コンピューティングリソース124などのホストコンピュータ上で複数のオペレーティングシステム（例えば、「ゲストオペレーティングシステム」）が同時に実行することを可能にするハードウェア仮想化技術を提供しうる。ハイパーバイザ124-4は、ゲストオペレーティングシステムに仮想オペレーティングプラットフォームを提示し、ゲストオペレーティングシステムの実行を管理しうる。様々なオペレーティングシステムの複数のインスタンスは、仮想化ハードウェアリソースを共有しうる。

【0021】

ネットワーク130は、1つまたは複数の有線および／または無線ネットワークを含む。例えば、ネットワーク130は、セルラーネットワーク（例えば、第5世代（5G）ネットワーク、ロングタームエボリューション（LTE）ネットワーク、第3世代（3G）ネットワーク、符号分割多元接続（CDMA）ネットワークなど）、公衆陸上移動網（PLMN）、ローカルエリアネットワーク（LAN）、ワイドエリアネットワーク（WAN）、メトロポリタンエリアネットワーク（MAN）、電話網（例えば、公衆交換電話網（PSTN））、プライベートネットワーク、アドホックネットワーク、イントラネット、インターネット、光ファイバベースのネットワークなど、および／またはこれらもしくは他のタイプのネットワークの組合せであってもよい。

【0022】

図1に示されるデバイスおよびネットワークの数および配置は、一例として提供されている。実際には、図1に示されるものに対して、追加のデバイスおよび／もしくはネットワーク、より少ないデバイスおよび／もしくはネットワーク、異なるデバイスおよび／もしくはネットワーク、または異なる配置のデバイスおよび／もしくはネットワークがあってもよい。さらに、図1に示される2つ以上のデバイスが単一のデバイス内に実装されてもよく、または図1に示される単一のデバイスが複数の分散されたデバイスとして実装されてもよい。追加的または代替的に、環境100のデバイスのセット（例えば、1つまたは複数のデバイス）が、環境100の別のデバイスのセットによって実行されるものとして説明されている1つまたは複数の機能を実施してもよい。

【0023】

図2は、図1の1つまたは複数のデバイスの例示的な構成要素のブロック図である。デバイス200は、ユーザデバイス110および／またはプラットフォーム120に対応しうる。図2に示されるように、デバイス200は、バス210と、プロセッサ220と、メモリ230と、ストレージ構成要素240と、入力構成要素250と、出力構成要素260と、通信インターフェース270とを含みうる。

【0024】

バス210は、デバイス200の構成要素間の通信を可能にする構成要素を含む。プロセッサ220は、ハードウェア、ファームウェア、またはハードウェアとソフトウェアとの組合せで実装される。プロセッサ220は、中央処理装置（CPU）、グラフィックスプロセッシングユニット（GPU）、アクセラレーテッドプロセッシングユニット（APU）、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ（DSP）、フィールドプログラマブルゲートアレイ（FPGA）、特定用途向け集積回路（ASIC）、または別のタイプの処理構成要素である。いくつかの実装形態では、プロセッサ220は、機能を実施するようにプログラムされることが可能な1つまたは複数のプロセッサを含む。メモリ230は、ランダムアクセスメモリ（RAM）、読み出し専用メモリ（ROM）、ならびに／またはプロセッサ220が使用するための情報および／もしくは命令を記憶する別のタイプの動的もしくは静的なストレージデバイス（例えば、フラッシュメモリ、磁気メモリ、および／もしくは光メモリ）を含む。

【0025】

ストレージ構成要素240は、デバイス200の動作および使用に関連する情報および／またはソフトウェアを記憶する。例えば、ストレージ構成要素240は、ハードディスク（例えば、磁気ディスク、光ディスク、光磁気ディスク、および／もしくはソリッドステートディスク）、コンパクトディスク（CD）、デジタル多用途ディスク（DVD）、フロッピーディスク、カートリッジ、磁気テープ、ならびに／または別のタイプの非一時的コンピュータ可読媒体を、対応するドライブとともに含みうる。

【0026】

入力構成要素250は、デバイス200がユーザ入力（例えば、タッチスクリーンディスプレイ、キーボード、キーパッド、マウス、ボタン、スイッチ、および／またはマイクロフォン）などを介して情報を受け取ることを可能にする構成要素を含む。追加的または代替的に、入力構成要素250は、情報を感知するためのセンサ（例えば、全地球測位システム（GPS）構成要素、加速度計、ジャイロスコープ、および／またはアクチュエータ）を含んでいてもよい。出力構成要素260は、デバイス200（例えば、ディスプレイ、スピーカ、および／または1つもしくは複数の発光ダイオード（LED））から出力情報を提供する構成要素を含む。

【0027】

通信インターフェース270は、デバイス200が、有線接続、無線接続、または有線接続と無線接続の組合せなどを介して他のデバイスと通信することを可能にする、トランシーバ様の構成要素（例えば、トランシーバおよび／または別々の受信機と送信機）を含む。通信インターフェース270は、デバイス200が別のデバイスから情報を受信し、かつ／または別のデバイスに情報を提供することを可能にしうる。例えば、通信インターフェース270は、イーサネットインターフェース、光インターフェース、同軸インターフェース、赤外線インターフェース、無線周波数（RF）インターフェース、ユニバーサルシリアルバス（USB）インターフェース、Wi-Fiインターフェース、セルラーネットワークインターフェースなどを含みうる。

【0028】

デバイス200は、本明細書に記載される1つまたは複数のプロセスを実行しうる。デバイス200は、プロセッサ220が、メモリ230および／またはストレージ構成要素240などの非一時的コンピュータ可読媒体によって記憶されたソフトウェア命令を実行したことに応答して、これらのプロセスを実行しうる。コンピュータ可読媒体は、本明細書では非一時的メモリデバイスと定義されている。メモリデバイスは、単一の物理ストレージデバイス内のメモリ空間、または複数の物理ストレージデバイスにわたって広がるメモリ空間を含む。

【0029】

ソフトウェア命令は、別のコンピュータ可読媒体から、または通信インターフェース270を介して別のデバイスから、メモリ230および／またはストレージ構成要素240に読み込まれうる。メモリ230および／またはストレージ構成要素240に記憶されたソフトウェア命令は、実行されると、プロセッサ220に、本明細書に記載される1つまたは複数のプロセスを実行させうる。追加的または代替的に、ハードワイヤード回路が、本明細書に記載される1つまたは複数のプロセスを実行するために、ソフトウェア命令の代わりに、またはソフトウェア命令と組合せて使用されてもよい。よって、本明細書に記載される実装形態は、ハードウェア回路とソフトウェアのいかなる特定の組合せにも限定されない。

【0030】

図2に示される構成要素の数および配置は、一例として提供されている。実際には、デバイス200は、図2に示される構成要素に対して、追加の構成要素、より少ない構成要素、異なる構成要素、または異なる配置の構成要素を含んでいてもよい。追加的または代替的に、デバイス200の構成要素のセット（例えば、1つまたは複数の構成要素）が、デバイス200の別の構成要素のセットによって実行されるものとして説明されている1つまたは複数の機能を実施してもよい。

【0031】

図3を参照すると、glTF（Graphics Language Transmission Format）は、アプリケーションプログラミングインターフェース（API）中立なランタイムアセット3Dモデリング配信フォーマットである。従来の3Dモデリングツールと比較して、glTFは、3Dコンテンツの伝送およびロードのためのより効率的で拡張可能かつ相互運用可能なフォーマットを提供する。

【0032】

glTFシーンは、複数のglTFアセットの組合せでありうる。glTFアセットは、例えば、シーンオブジェクト301、ノード302、カメラ303、メッシュ304、照明305、アニメーション306、アクセサ307、マテリアル308、スキン309、バッファビュー310、技法311、テクスチャ312、バッファ313、プログラム314、画像315、サンプラ316、シェーダ317、およびサポートする外部データを含みうるフルシーン記述を含むJSON（JavaScript Object Notation）フォーマットのファイルでありうる。

【0033】

glTFはまた、任意の上述のシーンオブジェクトにおいて参照されうる外部データソースをサポートする。実施形態では、バイナリファイルがアニメーション306または他のバッファベースのデータ313に使用されてもよい。画像ファイルは、オブジェクトテクスチャ312に使用されうる。

【0034】

図5を参照すると、上述のように、glTFシーンはJSONフォーマットで編成されうる。glTFアセットは、ゼロ個以上のシーン503を含んでいてもよく、シーン503はレンダリングすべきビジュアルオブジェクトのセットでありうる。シーンは、シーン配列で定義されうる。図5に示される例には、単一のノード501を有する単一のシーン506があるが、実施形態はこれに限定されない。各ノードオブジェクトと関連付けられうる様々なパラメータ。例えば、名称502は、ノードオブジェクトの名称を指定してもよく、シーン名504は、単一のシーンの名称を指定してもよい。

【0035】

glTFシーンアセットは、3Dまたは没入型シーンをユーザにレンダリングするためにプレゼンテーションエンジンによって消費されうる。既存のglTF構文は、静的またはコンピュータ生成アニメーションを含む3Dオブジェクトのみをサポートする。ビデオやオーディオなどのメディアタイプに対するサポートはなく、ましてやビデオ／オーディオメディアタイプをレンダリングすることはない。

【0036】

一方、既存のglTFは、地理座標系を使用してシーンを記述することができず、いくつかのメディア提示シナリオではそのような特徴が求められる。

【0037】

したがって、従来の2D平面映像、仮想現実（VR）、拡張現実（AR）、エクステンデッドリアリティ（XR）、空間オーディオなどの没入型メディアコンテンツを含むメディアタイプをサポートするようにglTFを拡張することが必要とされている。これには、ビデオ／オーディオ構文をサポートするための拡張およびメディアの配信およびレンダリングのためのシステムを必要としうる。

【0038】

ムービングピクチャエクスパーツグループ（MPEG）は、没入型メディアコンテンツをサポートするためにglTF仕様に加えていくつかの拡張を定義している。図3を参照すると、新たな拡張は、MPEG_media330、MPEG_scene_dynamic331、MPEG_texture_video333、MEPG_animation_timing332、MPEG_audio_spatial334、MPEG_accessor_timed335、MPEG_buffer_circular336である。図3では一般に、丸い輪郭を有する要素、例えば要素301～317は、glTF要素であってもよく、四角い輪郭を有する要素、例えば要素330～336は、glTF仕様のMPEGベースの拡張に対応してもよいが、実施形態はこれに限定されない。

【0039】

ルート識別子としてのMPEG_media330が指定される場合には、MPEG_mediaがサポートされうる。図6を参照すると、MPEGメディアをサポートする構文は、最上位のJSON構文として宣言されうる。図6の601から604までの構文は、サポートされる場合、図示されているとおりに提示されうる。

【0040】

シーン更新はJSONパッチプロトコルを使用して表現されてもよく、にMPEG_scene_dynamic331がJSONパッチプロトコルをサポートするため使用されてもよい。

【0041】

MPEGテクスチャビデオ拡張は、MPEG_texture_video333によって識別され、glTFテクスチャオブジェクトを、MPEG_mediaオブジェクトによってリストされたMPEGメディアおよびその対応するトラックにリンクする可能性を提供しうる。MPEGテクスチャビデオ拡張はまた、復号された時限テクスチャが利用可能になるMPEG_accessor_timed335への参照も提供しうる。

【0042】

MPEG_audio_spatial334拡張は、複数のオーディオタイプをサポートしうる。

【0043】

時限データアクセスをサポートするために、バッファ要素は、循環バッファ機能を提供するように拡張されうる。この拡張は、MPEG_buffer_circular336と名付けられ、例えばバッファ313のようなglTF「バッファ」オブジェクトの一部として含まれうる。

【0044】

上記のMEPG拡張は、glTFを使用した没入型体験の作成を可能にしうる。最終的に、MPEG拡張を有するglTFアセットは、視覚化のためのレンダリングエンジンにロードするために使用されうる。

【0045】

図4を参照すると、リファレンスメディアシーン記述アーキテクチャ400は、MPEG拡張がオーディオ／ビデオなどのメディアタイプをサポートするためにどのように使用されうるかの一例を示している。メディアコンテンツは、メディアクラウド401などの外部ソースからメディア検索エンジンおよびメディアアクセス機能（MAF）402を使用して検索され、ビデオデコーダ403、オーディオデコーダ404、および他のデータ圧縮器405を使用して処理され、ビデオバッファ406、オーディオバッファ407、および他のバッファ408にバッファされ、プレゼンテーションエンジン409によってレンダリングされうる。場合によっては、メディアコンテンツはローカルストレージ410に記憶されてもよい。

【0046】

図4を参照すると、MPEGシーン記述拡張は、プレゼンテーションエンジン409をメディア検索エンジン402から分離しうる。プレゼンテーションエンジン409とメディア検索エンジン402とは、所定のプログラミングインターフェースを介して通信してもよく、所定のプログラミングインターフェースは、プレゼンテーションエンジン409がシーンのレンダリングに必要なメディアデータを要求することを可能にするメディア検索エンジン402は、要求されたメディアを検索し、それを適時に、プレゼンテーションエンジン409が即時に処理できるフォーマットで提供しうる。例えば、要求されたメディアアセットは、圧縮されてネットワークに存在している場合があり、そのためメディア検索エンジン402は、アセットを検索して復号し、得られたメディアデータをレンダリングのためにプレゼンテーションエンジン409に渡す。メディアデータは、バッファの形態でメディア検索エンジン402からプレゼンテーションエンジン409に渡されてもよい。メディアデータを求める要求は、メディア検索APIを介してプレゼンテーションエンジン409からメディア検索エンジン402に渡されてもよい。ビデオ復号リソースの柔軟な使用のために、ビデオデコーダ403が使用されうる。ビデオデコーダ403が使用される場合、プレゼンテーションエンジン409は、アプリケーション構成APIを介してビデオデコーダ403に入力フォーマットおよび出力フォーマットのための情報を提供しうる。

【0047】

上述のように、glTF構文はJSONファイルで表現されうる。インターネット技術標準化委員会（Internet Engineering Task Force、IETF）のCBOR（Concise Binary Object Representation）は、従来のJSONフォーマットと比較して簡潔なデータフォーマットを表しうる。CBORは、名称／値ペアフォーマットのJSONのような類似したデータオブジェクトに関連するが、バイナリでコンパクトに表現され、またキー・値タイプによるはるかに多くのサポートを有する。CBORフォーマットのファイルのサイズは、JSONフォーマットの対応するファイルよりも小さい可能性がある。場合によっては、CBORファイルは、対応するJSONファイルよりも50％超小さい可能性がある。CBORは、インターネット番号割当て機関（Internet Assigned Numbers Authority、IANA）において「application/cbor」として登録されている。

【0048】

CBORは、そのコンパクトなデータサイズおよびJSONとの互換性のために同様に広くサポートされているglTF交換可能圧縮ファイルフォーマットの1つとして使用されうる。

【0049】

CBORにおける情報は、バイナリ形式で記憶される。情報の多くのユースケースはデータを理解するためのマシンを含むので、バイナリデータフォーマットは、記憶されたデータを理解するためにコンピュータまたはマシンが使用されるたびに解析を必要としうるJSONやXMLのような人間が読み取り可能なデータフォーマットに優る速度上の利点を有しうる。

【0050】

図7Aは、JSONフォーマットのファイルの一例を示しており、図7Bは、CBORフォーマットの対応するファイルの一例を示している。例えば、図7AのJSONフォーマットのファイルの文字「a」（711）は、図7BのCBORフォーマットのファイルの0x61（721）に対応しうる。同様に、図7AのJSONフォーマットのファイルの文字「b」（712）は、図7BのCBORフォーマットのファイルの0x62（722）に対応し、図7AのJSONフォーマットのファイルの文字「c」（713）は、図7BのCBORフォーマットのファイルの0x63（723）に対応しうる。

【0051】

シーン記述のためにCBORを使用することは、JSONと比較して、データサイズが小さく、JSONにおけるStringオブジェクトだけではなく複数のキー・値タイプをサポートするという点で利点をもたらしうる。機能プログラミングインターフェースが、提示されたメディアシーン記述リファレンスアーキテクチャにおいて、より正確にはメディアアクセス機能モジュールにおいて使用されてもよい。

【0052】

glTFによるCBORのサポートが普及してきているため、例えば、glTFファイルフォーマットの相互運用性を高め、ローカルストレージまたはキャッシュのファイルサイズを低減し、MAF402における最小限の処理能力でglTFファイル転送待ち時間を短縮するために、そのようなサポートがMPEGシーン記述に追加されてもよい。

【0053】

実施形態によるCBORパーサ関数が、CBOR入力をglTFネイティブサポートJSONフォーマットに変換するためにMAF402によって実装されてもよく、またCBORパーサ関数を、大きなglTFファイルをローカルストレージまたはキャッシュ410に保存するためのファイル圧縮器として使用することもできる。

【0054】

CBORパーサAPIは、以下の表1に示されるように、cbor2Json()、json2Cbor、save()などのメソッドのうちの1つを提供する。

【0055】

【表1】

【0056】

詳細なインターフェース記述は以下のとおりでありうる。
interface InputFileParser {
readonly attribute FILE inputFileName;
readonly attribute FILE outputFileName;
readonly attribute CBOR cborDataBlob;
FILE cbor2Json()(FILE cborInput);
FILE json2Cbor(FILE jsonInput);
FILE cbor2Json(CBOR cborDataBlob);
bool save();
};};

【0057】

上記の提案の関数は、例えば以下のような様々なシナリオで使用されうる。

【0058】

図8を参照すると、glTF「url」または「uri」構文は、CBORバイナリデータブロブ（802）を指しうる。実施形態では、バイナリが実際にCBORデータフォーマットであるかどうかを指定する2つのやり方がありうる。例1によれば、「application/cbor」（801）で「mimeTypes」を指定する多目的インターネットメール拡張（MIME）タイプがシグナリングされうる。
例2によれば、プレフィックス「application/cbor;」が、実際のバイナリデータの前に含められうる。例1および例2は一緒に使用されてもよい。いずれの場合も、CBORバイナリデータを取る「cbor2Json(Object）」と呼ばれる関数が、CBORファイルフォーマットを構文解析してJSONにするために呼び出されうる。

【0059】

入力glTFがCBORフォーマットである場合、出力は、cbor2Json()APIを使用することによるglTFでありうる。

【0060】

入力がネイティブglTFフォーマットである場合には、変換は不要でありうる。

【0061】

ローカルストレージまたはキャッシュの目的のために、glTFファイルが、json2Cbor()およびsave()インターフェースを使用することによりCBORとして保存されてもよい。

【0062】

したがって、実施形態は、CBORとのglTFファイルフォーマット相互運用性を提供し、ローカルストレージまたはキャッシュのためのファイルサイズを低減し、データ転送速度を高め、ファイル転送待ち時間を短縮する方法に関しうる。

【0063】

図9A～図9Cを参照して、メディアの記憶および配信を管理するためのプロセス900A、プロセス900B、およびプロセス900Cを以下で説明する。

【0064】

図9Aは、メディアの記憶および配信を管理するための例示的なプロセス900Aのフローチャートである。

【0065】

図9Aに示されるように、プロセス900Aは、メディアアクセス機能（MAF）により、シーンに対応するglTFファイルを取得するステップ（ブロック911）を含みうる。実施形態では、MAFはMAF402に対応しうる。

【0066】

図9Aにさらに示されるように、プロセス900Aは、glTFファイルがCBORフォーマットを有すると判定するステップ（ブロック912）を含みうる。

【0067】

図9Aに示されるように、プロセス900Aは、MAFによって実装された第1のCBORパーサ関数を使用して、glTFファイルを、JSONフォーマットを有する変換されたglTFファイルに変換するステップ（ブロック913）を含みうる。

【0068】

図9Aに示されるように、プロセス900Aは、変換されたglTFファイルに基づいて、シーンに対応するメディアコンテンツを取得するステップ（ブロック914）を含みうる。

【0069】

実施形態では、JSONフォーマットを有する変換されたglTFファイルは、CBORフォーマットを有するglTFファイルよりも大きい可能性がある。

【0070】

実施形態では、MAFは、ムービングピクチャエクスパーツグループ（MPEG）シーン記述アーキテクチャに含まれていてもよい。実施形態では、MPEGシーン記述アーキテクチャは、メディアシーン記述アーキテクチャ400に対応しうる。

【0071】

実施形態では、第1のCBORパーサ関数は、MAFと関連付けられたAPIを使用して実装されてもよい。実施形態では、APIは、上述の任意のAPIに対応しうる。

【0072】

図9Bは、メディアの記憶および配信を管理するための例示的なプロセス900Bのフローチャートである。実施形態では、プロセス900Bの1つまたは複数のブロックが、プロセス900Aの1つまたは複数のブロックと組み合わせて実行されてもよい。例えば、プロセス900Bの1つまたは複数のブロックが、プロセス900Aの1つまたは複数のブロックの後に実行されてもよい。

【0073】

図9Bに示されるように、プロセス900Bは、変換されたglTFファイルから、バイナリデータブロブを示すユニフォームリソースロケータ（URL）パラメータを取得するステップ（ブロック921）を含みうる。

【0074】

図9Bにさらに示されるように、プロセス900Bは、バイナリデータブロブがCBORフォーマットを有すると判定するステップ（ブロック922）を含みうる。

【0075】

図9Bにさらに示されるように、プロセス900Bは、MAFによって実装された第2のCBORパーサ関数を使用して、バイナリデータブロブを、JSONフォーマットを有するオブジェクトに変換するステップ（ブロック923）を含みうる。

【0076】

実施形態では、バイナリデータブロブは、glTFファイルでシグナリングされる多目的インターネットメール拡張（MIME）タイプに基づいてCBORフォーマットを有すると判定されてもよい。

【0077】

実施形態では、バイナリデータブロブは、バイナリデータブロブの先頭に含まれるプレフィックスに基づいてCBORフォーマットを有すると判定されてもよい。

【0078】

実施形態では、バイナリデータブロブは、glTFファイルでシグナリングされる多目的インターネットメール拡張（MIME）タイプおよびバイナリデータブロブの先頭に含まれるプレフィックスに基づいてCBORフォーマットを有すると判定されてもよい。

【0079】

図9Cは、メディアの記憶および配信を管理するための例示的なプロセス900Cのフローチャートである。実施形態では、プロセス900Cの1つまたは複数のブロックが、プロセス900Aおよび／またはプロセス900Bの1つまたは複数のブロックと組み合わせて実行されてもよい。例えば、プロセス900Cの1つまたは複数のブロックが、プロセス900Aの1つもしくは複数のブロックの後に、またはプロセス900Bの1つもしくは複数のブロックの後に実行されてもよい。

【0080】

図9Cに示されるように、プロセス900Cは、MAFによって実装されたJSONパーサ関数を使用して、変換されたglTFファイルを、CBORフォーマットを有する再変換されたglTFに再変換するステップ（ブロック931）を含みうる。

【0081】

図9Cにさらに示されるように、プロセス900Cは、再変換されたglTFファイルを、ローカルストレージまたはキャッシュの少なくとも一方に記憶するステップ（ブロック932）を含みうる。

【0082】

実施形態では、CBORフォーマットを有する再変換されたglTFファイルは、JSONフォーマットを有する変換されたglTFファイルよりも小さい可能性がある。

【0083】

実施形態では、JSONパーサ関数は、MAFと関連付けられたアプリケーションプログラミングインターフェースを使用して実装されうる。実施形態では、APIは、上述の任意のAPIに対応しうる。

【0084】

図9A～図9Cは、プロセス900A、プロセス900B、およびプロセス900Cの例示的なブロックを示しているが、いくつかの実装形態では、プロセス900A、プロセス900B、およびプロセス900Cは、図9A～図9Cに示されるものに対して、追加のブロック、より少ないブロック、異なるブロック、または異なる配置のブロックを含んでいてもよい。追加的または代替的に、プロセス900A、プロセス900B、およびプロセス900Cのプロセスのブロックのうちの2つ以上が並列に実行されてもよい。実施形態では、プロセス900A、プロセス900B、およびプロセス900Cの任意の1つまたは複数のブロックが、任意の順序でプロセス900A、プロセス900B、およびプロセス900Cの任意の他の1つまたは複数のブロックと組み合わされてもよく、プロセス900A、プロセス900B、およびプロセス900Cの任意のブロックの任意の1つまたは複数が、必要に応じて分割されるか、または組み合わされてもよい。

【0085】

さらに、提案の方法は、処理回路（例えば、1つまたは複数のプロセッサや1つまたは複数の集積回路）によって実装されてもよい。一例では、1つまたは複数のプロセッサは、提案の方法のうちの1つまたは複数を実行するために非一時的コンピュータ可読媒体に記憶されたプログラムを実行する。

【0086】

前述の開示は、例示および説明を提供しているが、網羅的であることも、実装形態を厳密に開示の形態に限定することも意図されていない。修正形態および変形形態が上記の開示に照らして可能であり、または実装形態の実践から取得されてもよい。

【0087】

本明細書に記載されるシステムおよび／または方法は、異なる形態のハードウェア、ファームウェア、またはハードウェアとソフトウェアとの組合せで実装されてもよいことは明らかであろう。これらのシステムおよび／または方法を実装するために使用される実際の専用の制御ハードウェアまたはソフトウェアコードは、実装形態を限定するものではない。よって、ソフトウェアおよびハードウェアは、本明細書の説明に基づいてシステムおよび／または方法を実装するように設計されうることを理解されたい。

【0088】

特定の特徴の組合せが、特許請求の範囲に記載され、かつ／または本明細書に開示されていても、これらの組合せは、可能な実装形態の開示を限定することを意図されたものではない。実際、これらの特徴の多くは、特許請求の範囲に具体的に記載されておらず、かつ／または本明細書に開示されていない方法で組み合わされうる。以下に列挙される各従属請求項は1つの請求項のみに直接従属しうるが、可能な実装形態の開示は、各従属請求項と、請求項セット内の他のすべての請求項との組み合わせを含む。

【0089】

本明細書で使用される要素、動作、または命令は、そのように明示的に記載されていない限り、不可欠または必須であると解釈されるべきではない。また、本明細書で使用される場合、冠詞の「a」および「an」は、1つまたは複数の項目を含むことを意図されており、「1つまたは複数」と交換可能に使用されうる。さらに、本明細書で使用される場合、「セット（set）」という用語は、1つまたは複数の項目（例えば、関連項目、非関連項目、関連項目と非関連項目の組合せなど）を含むことが意図されており、「1つまたは複数」と交換可能に使用されうる。1つの項目のみが意図される場合、「1つの（one）」という用語または同様の言葉が使用される。また、本明細書で使用される場合、「有する（has）」、「有する（have）」、「有する（having）」などの用語は、オープンエンド用語であることが意図されている。さらに、「に基づいて（based on）」という語句は、特に明記されない限り、「に少なくとも部分的に基づいて」を意味することが意図されている。

【符号の説明】

【0090】

100 環境
110 ユーザデバイス
120 プラットフォーム
122 クラウドコンピューティング環境
124 コンピューティングリソース
124-1 アプリケーション（APP）
124-2 仮想マシン（VM）
124-3 仮想化ストレージ（VS）
124-4 ハイパーバイザ（HYP）
130 ネットワーク
200 デバイス
210 バス
220 プロセッサ
230 メモリ
240 ストレージ構成要素
250 入力構成要素
260 出力構成要素
270 通信インターフェース
301 シーンオブジェクト
302 ノード
303 カメラ
304 メッシュ
305 照明
306 アニメーション
307 アクセサ
308 マテリアル
309 スキン
310 バッファビュー
311 技法
312 テクスチャ
313 バッファ／データ
314 プログラム
315 画像
316 サンプラ
317 シェーダ
400 メディアシーン記述アーキテクチャ
401 メディアクラウド
402 メディア検索エンジンおよびメディアアクセス機能（MAF）
403 ビデオデコーダ
404 オーディオデコーダ
405 他のデータ圧縮器
406 ビデオバッファ
407 オーディオバッファ
408 他のバッファ
409 プレゼンテーションエンジン
410 ローカルストレージ／キャッシュ
501 ノード
502 名称
503 シーン
504 シーン名
506 シーン

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7A】

【図7B】

【図8】

【図9A】

【図9B】

【図9C】