(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-05-01
(45)【発行日】2024-05-13
(54)【発明の名称】メディアシーン記述のための方法、デバイス及びコンピュータプログラム
(51)【国際特許分類】
H04N 21/2385 20110101AFI20240502BHJP
H04N 21/2668 20110101ALI20240502BHJP
H04N 1/387 20060101ALI20240502BHJP
【FI】
H04N21/2385
H04N21/2668
H04N1/387 101
(21)【出願番号】P 2022557649
(86)(22)【出願日】2021-10-01
(86)【国際出願番号】 US2021053088
(87)【国際公開番号】W WO2022150077
(87)【国際公開日】2022-07-14
【審査請求日】2022-09-22
(32)【優先日】2021-01-06
(33)【優先権主張国・地域又は機関】US
(32)【優先日】2021-09-29
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】520353802
【氏名又は名称】テンセント・アメリカ・エルエルシー
(74)【代理人】
【識別番号】100107766
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】ジャオ,シュアイ
(72)【発明者】
【氏名】ウェンジャー,ステファン
(72)【発明者】
【氏名】ソダガァ,イラジ
(72)【発明者】
【氏名】リウ,シャン
【審査官】川中 龍太
(56)【参考文献】
【文献】特表2019-521587(JP,A)
【文献】特表2020-512772(JP,A)
【文献】特表2018-534661(JP,A)
【文献】欧州特許出願公開第03672251(EP,A1)
【文献】米国特許出願公開第2019/0069000(US,A1)
【文献】E.Thomas, et al.,,MPEG MEDIA ENABLERS FOR RICHER XR EXPERIENCES,arXiv.org,米国,Cornell University ,2020年10月09日,pages 1-12,[オンライン], [検索日 2023.11.22],インターネット: <URL:https://arxiv.org/ftp/arxiv/papers/2010/2010.04645.pdf>
(58)【調査した分野】(Int.Cl.,DB名)
H04N 21/00 - 21/858
H04N 1/387
(57)【特許請求の範囲】
【請求項1】
コンピュータがメディアの記憶及び配信を管理する方法であって、
三次元(3D)シーンに関する情報を取得するステップ
であって、前記情報は、グラフィックス言語伝送フォーマット(glTF)アセットを含む、ステップと、
前記情報から、ビューポート適応が有効であることを示すパラメータを取得するステップ
であって、前記パラメータは、glTFアセットのカメラノードに含まれる、ステップと、
前記3Dシーンをレンダリングするステップであり、前記3Dシーンは、前記3Dシーン内で再生される少なくとも1つの二次元(2D)ビデオを含む、ステップと、
ユーザの現在のビューポートを取得するステップと、
前記少なくとも1つの2Dビデオが前記現在のビューポートの範囲内にあるか否かを決定するステップと、
前記決定の結果に基づいて、前記少なくとも1つの2Dビデオのビットレートを調整するステップと
を含む方法。
【請求項2】
前記調整するステップは、
前記少なくとも1つの2Dビデオが前記現在のビューポートの範囲内にあると決定したことに基づいて、前記ビットレートを増加させるステップと、
前記少なくとも1つの2Dビデオが前記現在のビューポートの範囲外にあると決定したことに基づいて、前記ビットレートを減少させるステップと
を含む、請求項1に記載の方法。
【請求項3】
前記少なくとも1つの2Dビデオは、第1のビットレートを有する第1の2Dビデオと、第2のビットレートを有する第2の2Dビデオとを含み、
前記調整するステップは、前記第1の2Dビデオが前記現在のビューポートの範囲内にあり且つ前記第2の2Dビデオが前記現在のビューポートの範囲外にあると決定したことに基づいて、前記第2のビットレートを前記第1のビットレートよりも低くなるように調整するステップを含む、請求項1又は2に記載の方法。
【請求項4】
前記glTFアセットは、JSON(JavaScript Object Notation)オブジェクトを含む、請求項
1に記載の方法。
【請求項5】
前記パラメータは、MPEG-DASH(MPEG-Dynamic Adaptive Streaming over Hypertext Transfer Protocol)を使用した前記少なくとも1つの2Dビデオのストリーミングに関連する、請求項
1に記載の方法。
【請求項6】
メディアの記憶及び配信を管理するためのデバイスであって、
プログラムコードを記憶するように構成された少なくとも1つのメモリと、
前記プログラムコードを読み取って前記プログラムコードによって命令されるように動作するように構成された少なくとも1つのプロセッサと
を含み、
前記プログラムコードは、
前記少なくとも1つのプロセッサに請求項1乃至
5のうちいずれか1項に記載の方法を実行させる、デバイス。
【請求項7】
メディアの記憶及び配信を管理するためのデバイスの少なくとも1つのプロセッサによって実行されたとき、前記少なくとも1つのプロセッサに請求項1乃至
5のうちいずれか1項に記載の方法を実行させるコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
[関連出願への相互参照]
本出願は、2021年1月6日に出願された米国仮出願第63/134,568号、及び2021年9月29日に出願された米国出願第17/489,103号の優先権を主張し、これらの全内容を参照により援用する。
【0002】
[技術分野]
本開示の実施形態は、三次元(3D, three-dimensional)モデリングシンタックスを使用したメディアオブジェクトをサポートし、様々なメディアコーデック、コンテナ及びフォーマットをサポートするためのメディアシンタックスを実装し、所定のプログラミングインタフェースを通じたメディアの記憶及び配信方法を管理し、メディアバッファ制御及びレンダリング機能を提供するためのシステム設計に関連する。
【背景技術】
【0003】
ISO/IEC 23009-1 DASH(Dynamic Adaptive Streaming over Hypertext Transfer Protocol)標準は、トランスポートレベルプロトコルとしてHTTPを使用して高品質を可能にする適応ビットレートストリーミング技術である。
【0004】
グラフィックス言語伝送フォーマット(glTF, Graphics Language Transmission Format)は、APIに属さないランタイムアセット3Dモデリング配信フォーマットである。従来の3Dモデリングツールと比較して、glTFは、3Dコンテンツの転送及びロードのための、より効率的で拡張性があり相互運用性のあるフォーマットを提供する。glTF2.0は、Khronos 3D Groupにより記述されたglTF仕様の最新バージョンである。このフォーマットは、「png」及び「jpeg」画像フォーマットを含む、シーン内の静的(untimed, タイミング無し)オブジェクトを一般的にサポートできる簡単なシーングラフフォーマットをサポートする。glTF2.0は、glTFプリミティブを使用して記述された基本的な形状、すなわち幾何学的オブジェクトの平行移動、回転及びスケール変更のサポートを含む、簡単なアニメーションをサポートする。glTF2.0は、タイミング付き(timed)メディアをサポートしていないため、ビデオもオーディオもサポートしない。
【0005】
「Information technology - Coding of audiovisual objects - Part 12: ISO base media file format」, ISO/IEC 14496-12 (December 2015)、「Draft of FDIS of ISO/IEC 23000-19 Common Media Application Format for Segmented Media」, ISO/IEC JTC1/SC29/WG11 MPEG117/16819 (April 2017)及び「Text of ISO/IEC FDIS 23009-1 4th edition」, ISO/IEC JTC 1/SC 29/WG 11 N18609 (August 2019)並びにglTF2.0仕様の全内容を参照により援用する。
【発明の概要】
【0006】
一実施形態によれば、メディアの記憶及び配信を管理する方法は、三次元(3D, three-dimensional)シーンに関する情報を取得するステップと、当該情報から、ビューポート適応が有効であることを示すパラメータを取得するステップと、3Dシーンをレンダリングするステップであり、3Dシーンは、3Dシーン内で再生される少なくとも1つの二次元(2D, two-dimensional)ビデオを含む、ステップと、ユーザの現在のビューポートを取得するステップと、少なくとも1つの2Dビデオが現在のビューポートの範囲内にあるか否かを決定するステップと、決定の結果に基づいて、少なくとも1つの2Dビデオのビットレートを調整するステップとを含む。
【0007】
一実施形態によれば、メディアの記憶及び配信を管理するためのデバイスは、プログラムコードを記憶するように構成された少なくとも1つのメモリと、プログラムコードを読み取ってプログラムコードによって命令されるように動作するように構成された少なくとも1つのプロセッサとを含み、プログラムコードは、少なくとも1つのプロセッサに三次元(3D, three-dimensional)シーンに関する情報を取得させるように構成された第1の取得コードと、少なくとも1つのプロセッサに、当該情報から、ビューポート適応が有効であることを示すパラメータを取得させるように構成された第2の取得コードと、少なくとも1つのプロセッサに3Dシーンをレンダリングさせるように構成されたレンダリングコードであり、3Dシーンは、3Dシーン内で再生される少なくとも1つの二次元(2D, two-dimensional)ビデオを含む、レンダリングコードと、少なくとも1つのプロセッサにユーザの現在のビューポートを取得させるように構成された第3の取得コードと、少なくとも1つのプロセッサに少なくとも1つの2Dビデオが現在のビューポートの範囲内にあるか否かを決定させるように構成された第2の決定コードと、少なくとも1つのプロセッサに、決定の結果に基づいて、少なくとも1つの2Dビデオのビットレートを調整させるように構成された調整コードとを含む。
【0008】
一実施形態によれば、非一時的なコンピュータ読み取り可能媒体は、命令を記憶し、命令は、メディアの記憶及び配信を管理するためのデバイスの少なくとも1つのプロセッサによって実行されたとき、少なくとも1つのプロセッサに、三次元(3D, three-dimensional)シーンに関する情報を取得するステップと、当該情報から、ビューポート適応が有効であることを示すパラメータを取得するステップと、3Dシーンをレンダリングするステップであり、3Dシーンは、3Dシーン内で再生される少なくとも1つの二次元(2D, two-dimensional)ビデオを含む、ステップと、ユーザの現在のビューポートを取得するステップと、少なくとも1つの2Dビデオが現在のビューポートの範囲内にあるか否かを決定するステップと、決定の結果に基づいて、少なくとも1つの2Dビデオのビットレートを調整するステップとを実行させる。
【図面の簡単な説明】
【0009】
開示の対象物の更なる特徴、性質及び様々な利点は、以下の詳細な説明及び添付の図面からより明らかになる。
【
図1】本明細書に記載の方法、装置及びシステムが実施形態に従って実装され得る環境の図である。
【
図2】実施形態による
図1の1つ以上のデバイスの例示的なコンポーネントのブロック図である。
【
図3】実施形態によるglTFシーン記述オブジェクトの概略図である。
【
図4】実施形態によるメディアシーン記述システム参照アーキテクチャの概略図である。
【
図5】実施形態によるglTF JSON(JavaScript Object Notation)フォーマット表現の例である。
【
図6A】実施形態によるMPEG glTF拡張の例である。
【
図6B】実施形態によるタイミング付きメディアのJSON表現の例である。
【
図7】実施形態による没入型シーンシナリオにおける2つ以上のタイミング付きメディア再生の概略図である。
【
図8】実施形態によるDASHビューポート適応のトップレベルシンタックスの概略図である。
【
図9】実施形態によるMPEG_dash_viewport_adaptationの使用例の概略図である。
【
図10A】実施形態によるメディアの記憶及び配信を管理するための例示的なプロセスの図である。
【
図10B】実施形態によるメディアの記憶及び配信を管理するための例示的なプロセスの図である。
【発明を実施するための形態】
【0010】
図1は、本明細書に記載の方法、装置及びシステムが実施形態に従って実装され得る環境100の図である。
図1に示すように、環境100は、ユーザデバイス110、プラットフォーム120及びネットワーク130を含んでもよい。環境100のデバイスは、有線接続、無線接続、又は有線及び無線接続の組み合わせを介して相互接続されてもよい。
【0011】
ユーザデバイス110は、プラットフォーム120に関連する情報を受信、生成、記憶、処理及び/又は提供できる1つ以上のデバイスを含む。例えば、ユーザデバイス110は、コンピューティングデバイス(例えば、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、ハンドヘルドコンピュータ、スマートスピーカ、サーバ等)、携帯電話(例えば、スマートフォン、無線電話等)、ウェアラブルデバイス(例えば、一対のスマートグラス又はスマートウオッチ)又は同様のデバイスを含んでもよい。いくつかの実装では、ユーザデバイス110は、プラットフォーム120に対して情報を受信及び/又は送信してもよい。
【0012】
プラットフォーム120は、本明細書のどこかに記載の1つ以上のデバイスを含む。いくつかの実装では、プラットフォーム120は、クラウドサーバ又はクラウドサーバのグループを含んでもよい。いくつかの実装では、プラットフォーム120は、ソフトウェアコンポーネントが特定のニーズに応じてスワップイン又はスワップアウトされ得るように、モジュール化となるように設計されてもよい。したがって、プラットフォーム120は、異なる使用のために容易及び/又は迅速に再構成されてもよい。
【0013】
いくつかの実装では、図示のように、プラットフォーム120は、クラウドコンピューティング環境122でホストされてもよい。特に、本明細書に記載の実装は、プラットフォーム120をクラウドコンピューティング環境122でホストされるものとして説明するが、いくつかの実装では、プラットフォーム120は、クラウドベースではなくてもよく(すなわち、クラウドコンピューティング環境の外部に実装されてもよい)、或いは、部分的にクラウドベースでもよい。
【0014】
クラウドコンピューティング環境122は、プラットフォーム120をホストする環境を含む。クラウドコンピューティング環境122は、エンドユーザ(例えば、ユーザデバイス110)がプラットフォーム120をホストするシステム及び/又はデバイスの物理的な位置及び構成の知識を必要としない計算、ソフトウェア、データアクセス、ストレージ等のサービスを提供してもよい。図示のように、クラウドコンピューティング環境122は、コンピューティングリソース124のグループ(併せて「コンピューティングリソース124」と呼ばれ、個々にも「コンピューティングリソース124」と呼ばれる)を含んでもよい。
【0015】
コンピューティングリソース124は、1つ以上のパーソナルコンピュータ、ワークステーションコンピュータ、サーバデバイス又は他のタイプの計算及び/又は通信デバイスを含む。いくつかの実装では、コンピューティングリソース124はプラットフォーム120をホストしてもよい。クラウドリソースは、コンピューティングリソース124において実行される計算インスタンス、コンピューティングリソース124において提供される記憶デバイス、コンピューティングリソース124によって提供されるデータ転送デバイス等を含んでもよい。いくつかの実装では、コンピューティングリソース124は、有線接続、無線接続又は有線接続及び無線接続の組み合わせを介して、他のコンピューティングリソース124と通信してもよい。
【0016】
図1に更に示すように、コンピューティングリソース124は、1つ以上のアプリケーション(APP, application)124-1、1つ以上の仮想マシン(VM, virtual machine)124-2、仮想化ストレージ(VS, virtualized storage)124-3、1つ以上のハイパーバイザ(HYP, hypervisor)124-4等のようなクラウドリソースのグループを含む。
【0017】
アプリケーション124-1は、ユーザデバイス110及び/又はプラットフォーム120に提供されてもよく或いはユーザデバイス110及び/又はプラットフォーム120によってアクセスされてもよい1つ以上のソフトウェアアプリケーションを含む。アプリケーション124-1は、ユーザデバイス110上にソフトウェアアプリケーションをインストールして実行する必要性を除去してもよい。例えば、アプリケーション124-1は、プラットフォーム120に関連するソフトウェア、及び/又はクラウドコンピューティング環境122を介して提供できるいずれかの他のソフトウェアを含んでもよい。いくつかの実装では、1つのアプリケーション124-1は、仮想マシン124-2を介して1つ以上の他のアプリケーション124-1に対して情報を送信/受信してもよい。
【0018】
仮想マシン124-2は、物理マシンのようなプログラムを実行するマシン(例えば、コンピュータ)のソフトウェア実装を含む。仮想マシン124-2は、仮想マシン124-2によるいずれかの実マシンに対する使用及び対応の程度に応じて、システム仮想マシン又はプロセス仮想マシンのいずれかでもよい。システム仮想マシンは、完全なオペレーティングシステム(OS, operating system)の実行をサポートする完全なシステムプラットフォームを提供してもよい。プロセス仮想マシンは、単一のプログラムを実行してもよく、単一のプロセスをサポートしてもよい。いくつかの実装では、仮想マシン124-2は、ユーザ(例えば、ユーザデバイス110)に代わって実行してもよく、データ管理、同期又は長期データ転送のようなクラウドコンピューティング環境122のインフラストラクチャを管理してもよい。
【0019】
仮想化ストレージ124-3は、コンピューティングリソース124の記憶システム又はデバイス内で仮想化技術を使用する1つ以上の記憶システム及び/又は1つ以上のデバイスを含む。いくつかの実装では、記憶システムのコンテキスト内で、仮想化のタイプは、ブロック仮想化及びファイル仮想化を含んでもよい。ブロック仮想化は、物理ストレージ又は異種構造に関係なくストレージシステムにアクセスし得るように、物理ストレージからの論理ストレージの抽象化(又は分離)を示してもよい。この分離は、どのようにストレージシステムの管理者がエンドユーザのためのストレージを管理するかについて、柔軟性を持たせることを可能にし得る。ファイル仮想化は、ファイルレベルでアクセスされるデータと、ファイルが物理的に記憶される位置との間の依存関係を除去してもよい。これは、ストレージ使用の最適化、サーバの統合及び/又は継続的なファイル移行の実行を可能にし得る。
【0020】
ハイパーバイザ124-4は、複数のオペレーティングシステム(例えば、「ゲストオペレーティングシステム」)が、コンピューティングリソース124のようなホストコンピュータ上で同時に実行することを可能にするハードウェア仮想化技術を提供してもよい。ハイパーバイザ124-4は、仮想オペレーティングプラットフォームをゲストオペレーティングシステムに提示してもよく、ゲストオペレーティングシステムの実行を管理してもよい。様々なオペレーティングシステムの複数のインスタンスは、仮想化ハードウェアリソースを共有してもよい。
【0021】
ネットワーク130は、1つ以上の有線及び/又は無線ネットワークを含む。例えば、ネットワーク130は、セルラネットワーク(例えば、第5世代(5G, fifth generation)ネットワーク、ロングタームエボリューション(LTE, long-term evolution)ネットワーク、第3世代(3G, third generation)ネットワーク、符号分割多元接続(CDMA, code division multiple access)ネットワーク等)、公衆陸上移動ネットワーク(PLMN, public land mobile network)、ローカルエリアネットワーク(LAN, local area network)、広域ネットワーク(WAN, wide area network)、メトロポリタンエリアネットワーク(MAN, metropolitan area network)、電話ネットワーク(例えば、公衆交換電話網(PSTN, Public Switched Telephone Network))、プライベートネットワーク、アドホックネットワーク、イントラネット、インターネット、光ファイバベースのネットワーク等、及び/又はこれら又は他のタイプのネットワークの組み合わせを含んでもよい。
【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, central processing unit)、グラフィックス処理装置(GPU, graphics processing unit)、アクセラレータ処理装置(APU, accelerated processing unit)、マイクロプロセッサ、マイクロコントローラ、デジタルシグナルプロセッサ(DSP, digital signal processor)、フィールドプログラマブルゲートアレイ(FPGA, field-programmable gate array)、特定用途向け集積回路(ASIC, application-specific integrated circuit)又は他のタイプの処理コンポーネントである。いくつかの実装では、プロセッサ220は、機能を実行するようにプログラムできる1つ以上のプロセッサを含む。メモリ230は、ランダムアクセスメモリ(RAM, random access memory)、読み取り専用メモリ(ROM, read only memory)、及び/又はプロセッサ220により使用される情報及び/又は命令を記憶する他のタイプの動的又は静的記憶デバイス(例えば、フラッシュメモリ、磁気メモリ及び/又は光メモリ)を含む。
【0025】
記憶コンポーネント240は、デバイス200の動作及び使用に関連する情報及び/又はソフトウェアを記憶する。例えば、記憶コンポーネント240は、ハードディスク(例えば、磁気ディスク、光ディスク、光磁気ディスク及び/又はソリッドステートディスク)、コンパクトディスク(CD, compact disc)、デジタル多用途ディスク(DVD, digital versatile disc)、フロッピーディスク、カートリッジ、磁気テープ及び/又は他のタイプの非一時的なコンピュータ読み取り可能媒体を、対応するドライブと共に含んでもよい。
【0026】
入力コンポーネント250は、デバイス200がユーザ入力(例えば、タッチスクリーンディスプレイ、キーボード、キーパッド、マウス、ボタン、スイッチ及び/又はマイクロホン)等を介して情報を受信することを可能にするコンポーネントを含む。さらに或いは代替として、入力コンポーネント250は、情報を感知するためのセンサ(例えば、全地球測位システム(GPS, global positioning system)コンポーネント、加速度計、ジャイロスコープ、及び/又はアクチュエータ)を含んでもよい。出力コンポーネント260は、デバイス200からの出力情報を提供するコンポーネント(例えば、ディスプレイ、スピーカ及び/又は1つ以上の発光ダイオード(LED, light-emitting diode))を含む。
【0027】
通信インタフェース270は、デバイス200が有線接続、無線接続又は有線接続及び無線接続の組み合わせを介して他のデバイスと通信することを可能にするトランシーバのようなコンポーネント(例えば、トランシーバ及び/又は別々の受信機及び送信機)を含む。通信インタフェース270は、デバイス200が他のデバイスから情報を受信すること、及び/又は情報を他のデバイスに提供することを可能にし得る。例えば、通信インタフェース270は、イーサネットインタフェース、光インタフェース、同軸インタフェース、赤外線インタフェース、無線周波数(RF, radio frequency)インタフェース、ユニバーサルシリアルバス(USB, universal serial bus)インタフェース、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, application programming interface)に属さないランタイムアセット3Dモデリング配信フォーマットである。従来の3Dモデリングツールと比較して、glTFは、3Dコンテンツの転送及びロードのための、より効率的で拡張性があり相互運用性のあるフォーマットを提供する。
【0032】
glTFシーンは、複数のglTFアセットの組み合わせでもよい。glTFアセットは、全シーン記述を含むJSON(JavaScript Object Notation)フォーマットのファイルでもよく、全シーン記述は、例えば、シーンオブジェクト301、ノード302、カメラ303、メッシュ304、ライト305、アニメーション306、アクセサ307、マテリアル308、スキン309、バッファビュー310、テクニック311、テクスチャ312、バッファ313、プログラム314、画像315、サンプラ316、シェーダ317及びサポート外部データを含んでもよい。
【0033】
glTFはまた、上記のシーンオブジェクトで参照され得る外部データソースをサポートする。実施形態では、バイナリファイルは、アニメーション306又は他のバッファベースのデータ313に使用されてもよい。画像ファイルは、オブジェクトテクスチャ312に使用されてもよい。
【0034】
図5を参照すると、上記のように、glTFシーンはJSONフォーマットで組成されてもよい。glTFアセットは、レンダリングすべき視覚オブジェクトのセットでもよい0個以上のシーン503を含んでもよい。シーンは、シーンアレイで定義されてもよい。
図5に示す例では、単一のノード501を有する単一のシーン506が存在するが、実施形態はこれに限定されない。様々なパラメータが各ノードオブジェクトに関連してもよい。例えば、名前502はノードオブジェクトの名前を指定してもよく、シーン名504は単一のシーンの名前を指定してもよい。
【0035】
glTFシーンアセットは、プレゼンテーションエンジンによって、ユーザに対して3Dシーン又は没入型シーンをレンダリングするために利用されてもよい。既存のglTFシンタックスは、静的アニメーション又はコンピュータ生成アニメーションを含む3Dオブジェクトのみをサポートする。ビデオ又はオーディオのようなメディアタイプについてのサポートはなく、これらのビデオ/オーディオのメディアタイプをレンダリングすることはできない。
【0036】
一方、既存のglTFでは、地理的座標系を使用してシーンを記述することはできないが、いくつかのメディアプレゼンテーションシナリオでは、このような機能が望まれる。
【0037】
したがって、従来の2Dフラットビデオ、仮想現実(VR, virtual reality)、拡張現実(AR, augmented reality)、クロスリアリティ(XR, extended reality)及び空間オーディオのような没入型メディアコンテンツを含むメディアタイプをサポートするためにglTFを拡張する必要がある。これは、ビデオ/オーディオシンタックスをサポートするための拡張を必要とし、メディアの配信及びレンダリングのためのシステムを必要とし得る。
【0038】
MPEG(Moving Picture Experts Group)は、没入型メディアコンテンツをサポートするために、glTF仕様の上にいくつかの拡張を定義している。
図3を参照すると、新たな拡張は、MPEG_media330、MPEG_scene_dynamic331、MPEG_texture_video333、MEPG_animation_timing332、MPEG_audio_spatial334、MPEG_accessor_timed335、MPEG_buffere_circular336である。
図3において一般的に丸みを帯びた輪郭を有するエレメント、例えば、エレメント301~317はglTFエレメントでもよく、正方形の輪郭を有するエレメント、例えば、エレメント330~336は、glTF仕様のMPEGベースの拡張に対応してもよいが、実施形態はこれに限定されない。
【0039】
ルート識別子としてMPEG_media330が指定されている場合、MPEG_mediaがサポートされてもよい。
図6を参照すると、MPEGメディアをサポートするためのシンタックスは、最上位のJSONシンタックスとして宣言されてもよい。601~604のシンタックスは、サポートされる場合には、図示の通り正確に提示されてもよい。
【0040】
シーン更新はJSONパッチプロトコルを使用して表現されてもよく、MPEG_scene_dynamic331はJSONパッチプロトコルをサポートするために使用されてもよい。
【0041】
MPEG_texture_video333によって識別されるMPEGテクスチャビデオ拡張は、MPEG_mediaオブジェクトによってリストされたMPEGメディア及びそのそれぞれのトラックにglTFテクスチャオブジェクトをリンクする可能性を提供してもよい。MPEGテクスチャビデオ拡張はまた、デコードされたタイミング付きテクスチャが利用可能になるMPEG_accessor_timed335への参照を提供してもよい。
【0042】
MPEG_audio_spatial334拡張は、複数のオーディオタイプをサポートしてもよい。
【0043】
タイミング付きデータアクセスをサポートするために、バッファエレメントは、循環バッファ機能を提供するように拡張されてもよい。拡張子はMPEG_buffer_circular336という名前であり、glTF「バッファ」オブジェクト(例えば、バッファ313)の一部として含まれてもよい。
【0044】
上記のMEPG拡張は、glTFを使用した没入型体験の創造を可能にし得る。最終的には、MPEG拡張を有するglTFアセットは、可視化のためのレンダリングエンジンにロードするために使用されてもよい。
【0045】
図4を参照すると、参照メディアシーン記述アーキテクチャ400は、どのようにMPEG拡張がオーディオ/ビデオのようなメディアタイプをサポートするために使用され得るかの例を示す。メディアコンテンツは、メディアクラウド401のような外部ソースからメディア取得エンジン及びメディアアクセス機能(MAF, Media Access Function)402を使用して取得され、ビデオデコーダ403、オーディオデコーダ404及び他のデータ圧縮器405を使用して処理され、ビデオバッファ406、オーディオバッファ407及び他のバッファ408にバッファされ、プレゼンテーションエンジン409によってレンダリングされてもよい。いくつかの場合、メディアコンテンツはローカルストレージ410に記憶されてもよい。
【0046】
図4を参照すると、MPEGシーン記述拡張は、メディア取得エンジン402からプレゼンテーションエンジン409を切り離してもよい。プレゼンテーションエンジン409及びメディア取得エンジン402は、所定のプログラミングインタフェースを通じて通信してもよく、このことは、プレゼンテーションエンジン409がシーンのレンダリングに必要なメディアデータを要求することを可能にする。メディア取得エンジン402は、要求されたメディアを取得し、プレゼンテーションエンジン409によって直ちに処理できるフォーマットでタイムリーにそれを利用可能にしてもよい。例えば、要求されたメディアアセットは圧縮され、ネットワークに存在してもよいので、メディア取得エンジン402は、アセットを取得して復号し、結果のメディアデータをレンダリングのためにプレゼンテーションエンジン409に渡す。メディアデータは、メディア取得エンジン402からプレゼンテーションエンジン409にバッファの形式で渡されてもよい。メディアデータについての要求は、メディア取得APIを通じてプレゼンテーションエンジン409からメディア取得エンジン402に渡されてもよい。ビデオ復号リソースを柔軟に使用するために、ビデオデコーダ403が使用されてもよい。ビデオデコーダ403が使用される場合、プレゼンテーションエンジン409は、アプリケーション構成APIを通じて、ビデオデコーダ403への入力フォーマット及び出力フォーマットのための情報を提供してもよい。
【0047】
HTTP上の動的適応ストリーミング(DASH, Dynamic Adaptive Streaming over HTTP)又はMPEG-DASHは、トランスポートレベルプロトコルとしてHTTPを使用して高品質を可能にする適応ビットレートストリーミング技術である。DASHコンテンツは複数のセグメントに分割されてもよく、各セグメントはコンテンツの短い間隔の再生時間を含んでもよい。コンテンツは、様々な異なるビットレートで利用可能にされてもよく、すなわち、位置合わせされた短い間隔の再生時間をカバーする異なるビットレートで符号化された代替セグメントで利用可能にされてもよい。コンテンツがMPEG-DASHクライアントによって再生されている間に、クライアントは、ネットワーク条件に基づいて可能な限り高いビットレートを有するセグメントを自動的に選択するために、カスタマイズされたビットレート適応アルゴリズムを使用してもよく、その結果、再生において停止又は再バッファリングイベントを生じさせることなく、スムーズな再生を生じる。
【0048】
シーン記述は、再生のためにMPEG-DASHをサポートしてもよい。現在、MPEGは、MPEGタイミング付きメディア拡張として識別されるタイミング付きメディアとしてDASHメディア再生をサポートする。
【0049】
図6Bを参照すると、DASHベースのタイミング付きメディアは、IANA値「application/dash+xml」を有するmimeType(613)によって識別されてもよい。各DASHは、メディアセグメントがどのように分割されて構成されるかを示すために、メディアプレゼンテーション記述(MPD, Media Presentation Description)ファイルと呼ばれる1つのマニフェストファイルを有してもよい。このようなMPDファイルは、url又はuri(614)によって識別されてもよい。メディアトラック情報は、トラックによって識別されてもよく、各DASHタイミング付きメディアは、(615)に示すように、1つ以上のトラック情報を有してもよい。DASHクライアントは、ネットワーク条件に基づいて異なるトラック#を使用してもよい。また、その特定のMPDファイルのための1つ以上のトラックを有してもよい拡張(616)で示すように、1つのタイミング付きメディア拡張に1つよりも多くのDASH MPDファイルが存在してもよい。
【0050】
没入型シーン環境では、ユーザ又はカメラの視点は、必ずしも特定のオブジェクトに固定されるとは限らない。シーン記述におけるタイミング付きメディアの現在のサポートでは、シーン内に1つ以上のタイミング付きメディアが存在する場合の最適な視聴体験が望まれる。したがって、実施形態は、ビューポート更新と共にDASH動的ビットレート切り替えを可能にする拡張に関連してもよい。glTFの概念では、これは、カメラがタイミング付きメディアオブジェクトに対してフォーカスをオン/オフにした場合、DASHベースのMPEGタイミング付きメディアがビットレートを自動的に切り替えることを可能にする。これは、ユーザの体感品質を向上させ、ネットワーク帯域幅効率を向上させ得る。
【0051】
上記のように、適応HTTPベースのメディアストリーミング方法としてのDASHは、クライアントが、ネットワーク条件又はバッファ状態に基づいて、所定の小さいビットストリームセグメントによってビットストリームビットレートを自動的に調整することを可能にする。ビットレート品質を上下に切り替える利点は、再バッファ頻度を低減でき、その結果、スムーズな再生体験を生じる。
【0052】
図6Aに示すように、MPEG_media(601)として識別されるMPEGメディア拡張は、DASHベースのタイミング付きメディアを再生するためのシーン記述を可能にし得る。DASH適応ストリーミングの現在の設計は実装特有であるが、DASHネイティブ切り替えの使用は、没入型又は360度シーン環境における最適なネットワーク帯域幅使用を提供しない。例えば、メディア再生のビューが常に現在のビューポートの範囲にあるとは限らず、これは、不要なネットワークリソースの浪費を生じる可能性がある。実施形態では、現在のビューポートは、カメラ又はユーザによって現在見られているか或いはユーザのために再生されている、没入型、3D、VR/AR/XR又は360度シーンの一部でもよい。スムーズなタイミング付きメディア再生体験を提供するために、どのようにネットワーク帯域幅が利用されるかを管理することが重要になり得る。
【0053】
したがって、実施形態は、ビューポート更新と共に、DASHベースのタイミング付きメディアのビットレート適応を可能にし得る。glTFの概念では、これは、カメラがタイミング付きメディアオブジェクトに対してフォーカスをオン/オフにした場合、DASHベースのメディア再生がビットレートを自動的に切り替えることを可能にし得る。これは、ユーザの体感品質を向上させ、ネットワーク帯域幅の効率を増加させる。
【0054】
図7を参照すると、1つ又は潜在的にはより多くのメディア再生を有する没入型シーン(701)が示されている。再生ビュー1(703)及びビュー2(702)は、プレゼンテーションエンジン409によってレンダリングされ、
図7に示す位置に割り当てられてもよい。
【0055】
360度のビューの全てが、ユーザのビューポート(表示域)又はカメラのカバー領域の範囲内にあるとは限らないと仮定することは合理的である。それはそうとして、ビュー1及びビュー2の全てが同時に視聴されているとは限らない。
【0056】
ユースケースを更に説明するために、以下のシーンオブジェクトが、潜在的なユースケースの説明に使用される。
図7を参照すると、ビデオ-1がビュー1(703)で再生され、ビデオ-2がビュー2(704)で再生されていると仮定する。表1は、
図7に示すシーンに関する情報を提供する。
【0057】
【表1】
簡単な例示的なユースケースでは、
図3に示すように、シーン内で再生される1つのDASHベースのタイミング付きメディアのみが存在する。メディアは、自動再生(621)、ループ(622)等のような設定可能なパラメータでMPEG_media拡張に基づいてレンダリングされてもよい。この場合、DASH適応ストリーミングは、ネットワーク条件又はバッファ状態のいずれかに基づいてビットレートを切り替えることによって、そのネイティブメカニズム内で使用されてもよい。この場合の主な観察結果は、ビューポートがフォーカスされていないときでもビデオが再生され続けることである。適切なネットワーク環境では、DASHは全体としてのシーンの全体的な帯域幅利用を考慮することなく、可能な限り高いビットレートに切り替える。望ましくないネットワーク条件では、カメラのフォーカスは、ポイントクラウド圧縮(PCC, point cloud compressed)オブジェクトのような比較的大きい帯域幅利用のシーンオブジェクトのセットにあり、進行中のタイミング付きメディア再生からの不要な帯域幅利用は、現在のビューポートの表示品質の最適解ではない可能性がある。
【0058】
図7に示すように、1つよりも多くのタイミング付きメディアが同時に再生される場合、ネットワーク帯域幅の使用は、上記のようなユースケースと同様である。しかし、全てのタイミング付きメディアが高解像度設定になっている場合、状況は更に悪化する可能性がある。メディア再生のそれぞれにとってネットワークリソースを均衡させることができない場合、表示品質が低下する可能性がある。
【0059】
したがって、DASHベースのタイミング付きメディアのそれぞれのための設定可能な帯域幅使用のためのオプションをクライアントに提供することは、シーン記述のための重要な機能になり得る。
【0060】
したがって、実施形態は、DASHベースのMPEGタイミング付きメディアが、カメラのフォーカスポイントに基づいてビットレートを自動的に切り替えることを可能にする。どのようにビットレートレベルが調整されるかの実装はケースバイケースとすることができる。これは、クライアントが、比較的複雑なシーンレンダリングシナリオにおいてネットワーク帯域幅を節約するために、特定のビュー構成における視点適応をオン/オフするための機会を提供する。
【0061】
図8を参照すると、実施形態によるMPEG DASHビューポート適応拡張は、MPEG_dash_viewport_adapdation(802及び804)によって識別されてもよい。これは、DASHビューポート適応の使用を必要とするシーン記述のために、シーン記述ドキュメントのextensionsUsed(803)及びextensionsRequired(801)に含まれてもよい。実施形態では、ビューポート適応は、ユーザのビューポート又は視点に基づいて或いはこれを考慮して、適応ストリーミング技術、例えば、DASHベースのタイミング付きメディアビットレート適応又はいずれかの他の適応ストリーミング技術の使用を示してもよい。
【0062】
MPEG_dash_viewport_adapdation拡張がサポートされていない場合、カメラオブジェクトはglTFで指定されたものと同じパラメータを保持してもよい。表2は、MPEG_dash_viewport_adapdation拡張のトップレベルオブジェクトの定義の例を示す。
【0063】
【表2】
図9は、提案されるMPEG_dash_viewport_adapdation拡張を有する1つのカメラオブジェクトの例を示す。「application/dash+xml」を指定するmimeTypeを有する元のMPEG_extensionは変更されないままである。
【0064】
MPEG_dash_viewport_adapdationが上記の実施形態に従って使用されている場合、表2に指定されている「adaptive」パラメータのオン/オフを切り替えることにより、クライアントは「adaptive」=「True」でビューポート適応を有効にできる。ビットレートレベル又はDASHトラック切り替えのロジックは実装特有でもよい。
【0065】
したがって、実施形態は、ビューポート更新と共にDASHベースのタイミング付きメディアビットレート適応を可能にするための新たなシーン記述拡張に関連してもよく、提案される拡張を可能にする識別情報としてのパラメータのセットに関連してもよい。
【0066】
図10A~10Bを参照して、メディアの記憶及び配信を管理するためのプロセス1000A及び1000Bが、以下に記載される。
【0067】
図10Aは、メディアの記憶及び配信を管理するための例示的なプロセス1000Aのフローチャートである。
【0068】
図10Aに示すように、プロセス1000Aは、三次元(3D, three-dimensional)シーンに関する情報を取得することを含んでもよい(ブロック1011)。実施形態では、情報は、glTFシーン又はglTFアセットに対応してもよい。
【0069】
図10Aに更に示すように、プロセス1000Aは、当該情報から、ビューポート適応が有効であることを示すパラメータを取得することを含んでもよい(ブロック1012)。実施形態では、パラメータは、上記のDASHビューポート適応拡張の「adaptive」パラメータに対応してもよい。
【0070】
図10Aに更に示すように、プロセス1000Aは、3Dシーンをレンダリングすることを含んでもよく、3Dシーンは、3Dシーン内で再生される少なくとも1つの二次元(2D, two-dimensional)ビデオを含む(ブロック1013)。
【0071】
図10Aに更に示すように、プロセス1000Aは、ユーザの現在のビューポートを取得することを含んでもよい(ブロック1014)。
【0072】
図10Aに更に示すように、プロセス1000Aは、少なくとも1つの2Dビデオが現在のビューポートの範囲内にあるか否かを決定することを含んでもよい(ブロック1015)。
【0073】
図10Aに更に示すように、プロセス1000Aは、決定の結果に基づいて、少なくとも1つの2Dビデオのビットレートを調整することを含んでもよい(ブロック1016)。
【0074】
図10Bは、メディアの記憶及び配信を管理するための例示的なプロセス1000Bのフローチャートである。実施形態では、プロセス1000Bの1つ以上のブロックは、プロセス1000Aの1つ以上のブロックに対応してもよい。例えば、プロセス1000Bのブロック1021は、プロセス1000Aのブロック1014に対応してもよく、プロセス1000のブロック1022及び1023の一方又は双方は、プロセス1000Aのブロック1016に対応してもよい。
【0075】
図10Bに示すように、プロセス1000Bは、少なくとも1つの2Dビデオが現在のビューポートの範囲内にあるか否かを決定することを含んでもよい(ブロック1021)。
【0076】
図10Bに更に示すように、プロセス1000Bは、少なくとも1つの2Dビデオが現在のビューポートの範囲内にあると決定したことに基づいて(ブロック1021におけるYES)、ビットレートを増加させることを含んでもよい(ブロック1022)。
【0077】
図10Bに更に示すように、プロセス1000Bは、少なくとも1つの2Dビデオが現在のビューポートの範囲外にあると決定したことに基づいて(ブロック1021におけるNO)、ビットレートを減少させることを含んでもよい(ブロック1023)。
【0078】
実施形態では、少なくとも1つの2Dビデオは、第1のビットレートを有する第1の2Dビデオと、第2のビットレートを有する第2の2Dビデオとを含んでもよく、調整は、第1の2Dビデオが現在のビューポートの範囲内にあり且つ第2の2Dビデオが現在のビューポートの範囲外にあると決定したことに基づいて、第2のビットレートを第1のビットレートよりも低くなるように調整することを含んでもよい。
【0079】
実施形態では、当該情報は、グラフィックス言語伝送フォーマット(glTF, graphics language transmission format)アセットを含んでもよい。
【0080】
実施形態では、glTFアセットは、JSON(JavaScript Object Notation)オブジェクトを含んでもよい。
【0081】
実施形態では、パラメータは、glTFアセットのカメラノードに含まれてもよい。
【0082】
実施形態では、パラメータは、glTFアセットによって指定されたMPEG(Moving Picture Experts Group)メディア拡張に含まれてもよい。
【0083】
実施形態では、パラメータは、MPEG-DASH(MPEG-Dynamic Adaptive Streaming over Hypertext Transfer Protocol)を使用した少なくとも1つの2Dビデオのストリーミングに関連してもよい。
【0084】
図10A~10Bは、プロセス1000A及び1000Bの例示的なブロックを示しているが、いくつかの実装では、プロセス1000A及び1000Bは、
図10A~10Bに示すものよりも多くのブロック、少ないブロック、異なるブロック又は異なる配置のブロックを含んでもよい。さらに或いは代替として、プロセス1000A及び1000Bのブロックのうち2つ以上は並列に実行されてもよい。実施形態では、プロセス1000Aのいずれか1つ以上のブロックは、プロセス1000Bのいずれか1つ以上のブロックと如何なる順序で組み合わされてもよく、プロセス1000A及び1000Bのいずれかのブロックのうちいずれか1つ以上は所望によって分割又は結合されてもよい。
【0085】
さらに、提案される方法は、処理回路(例えば、1つ以上のプロセッサ又は1つ以上の集積回路)によって実装されてもよい。一例では、1つ以上のプロセッサは、提案される方法の1つ以上を実行するために、非一時的なコンピュータ読み取り可能媒体に記憶されたプログラムを実行する。
【0086】
上記の開示は例示及び説明を提供しているが、網羅的であること、又は実施形態を開示された正確な形式に限定することを意図するものではない。上記の開示に鑑みて変更及び変形が可能であり、或いは、実施形態の実施から取得されてもよい。
【0087】
本明細書に記載のシステム及び/又は方法は、ハードウェア、ファームウェア又はハードウェア及びソフトウェアの組み合わせの異なる形式で実装されてもよいことが明らかである。これらのシステム及び/又は方法を実施するために使用される実際の特別な制御ハードウェア又はソフトウェアコードは、実装を限定するものではない。したがって、ソフトウェア及びハードウェアは、本明細書の記載に基づいてシステム及び/又は方法を実施するように設計されてもよいことが理解されるべきである。
【0088】
特徴の特定の組み合わせが特許請求の範囲に記載され及び/又は明細書に開示されているとしても、これらの組み合わせは、可能な実装の開示を限定することを意図するものではない。実際に、これらの特徴の多くは、請求項に具体的に記載されていない方法、及び/又は明細書に開示されていない方法で組み合わされてもよい。以下に列挙される各従属請求項は、1つの請求項のみに直接従属することがあるが、可能な実装の開示は、各従属請求項を特許請求の範囲内の他の全ての請求項と組み合わせたものを含む。
【0089】
本明細書で使用される如何なるエレメント、動作又は命令も、明示的に記載されない限り、重要又は必須として解釈されるべきではない。また、本明細書で使用される場合、単数(不定冠詞)は、1つ以上の項目を含むことを意図し、「1つ以上」と互換的に使用されてもよい。さらに、本明細書で使用される場合、用語「セット」は、1つ以上の項目(例えば、関連する項目、関連しない項目、関連する項目及び関連しない項目の組み合わせ等)を含むことを意図し、「1つ以上」と互換的に使用されてもよい。1つの項目のみが意図される場合、用語「1つ」又は同様の言語が使用される。また、本明細書で使用される場合、用語「有する(has)」、「有する(have)」、「有する(having)」等は、オープンエンドの用語であることを意図する。さらに、語句「基づく」は、明示的に別段の記載がない限り、「少なくとも部分的に基づく」を意味することを意図する。