JP7471731B2 - メディアファイルのカプセル化方法、メディアファイルのカプセル化解除方法及び関連機器 - Google Patents

Description

本願はデータ処理の技術分野に関し、具体的にメディアファイルのカプセル化及びカプセル化解除の技術に関する。

本願は、２０２０年１０月１４日に中国特許局に提出された、出願番号が第２０２０１１０９８１９０７号であり、出願の名称が「メディアファイルのカプセル化方法、メディアファイルのカプセル化解除方法及び関連機器」である中国特許出願の優先権を主張し、その全内容が引用により本願に組み込まれている。

没入型メディア（Ｉｍｍｅｒｓｉｖｅ Ｍｅｄｉａ）とは、ユーザーに没入型体験をもたらすことができるメディアコンテンツを指し、イマーシブメディアとも呼ばれてもよい。広義に言えば、オーディオビデオ技術によってユーザーに没入感を生じさせるメディアコンテンツである限り、没入型メディアに属する。例えば、ユーザーがＶＲ（Ｖｉｒｔｕａｌ Ｒｅａｌｉｔｙ、仮想現実）ヘルメットを着用すると、現場への強い没入感が生まれるようになる。

没入型メディアの応用形式は様々であり、ユーザー側は異なる応用シーンの没入型メディアに対してカプセル化解除、復号及びレンダリングを行うときに、必要な操作ステップ及び処理能力はそれぞれ異なる。一方、現状では、関連技術は没入型メディアと対応する応用シーンを効果的に区別できず、これはユーザー側による没入型メディアに対する処理の困難性を増加させてしまう。

本願の実施例はメディアファイルのカプセル化方法、メディアファイルのカプセル化解除方法、メディアファイルのカプセル化装置、メディアファイルのカプセル化解除装置、電子機器及びコンピュータ可読記憶媒体を提供し、メディアファイルのカプセル化において異なる応用シーンを区別することができる。

本願の実施例はメディアファイルのカプセル化方法を提供し、電子機器により実行され、前記方法は、ターゲットメディアコンテンツの当該ターゲットメディアコンテンツに対応する応用シーン下でのメディアストリームを取得するステップと、前記メディアストリームをカプセル化し、前記メディアストリームのカプセル化ファイルを生成するステップであって、前記カプセル化ファイルには第１応用シーンタイプフィールドが含まれ、前記第１応用シーンタイプフィールドは前記メディアストリームに対応する応用シーンを指示することに用いられる、ステップと、前記カプセル化ファイルを第１機器に送信することにより前記第１機器は前記第１応用シーンタイプフィールドに基づき前記メディアストリームに対応する応用シーンを決定し、且つ前記メディアストリームに対応する応用シーンに基づき前記メディアストリームの復号方式及びレンダリング方式のうちの少なくとも一種を決定するステップと、を含む。

本願の実施例はメディアファイルのカプセル化解除方法を提供し、電子機器により実行され、前記方法は、ターゲットメディアコンテンツの当該ターゲットメディアコンテンツに対応する応用シーン下でのメディアストリームのカプセル化ファイルを受信するステップであって、前記カプセル化ファイルには第１応用シーンタイプフィールドが含まれ、前記第１応用シーンタイプフィールドは前記メディアストリームに対応する応用シーンを示すことに用いられる、ステップと、前記カプセル化ファイルをカプセル化解除し、前記第１応用シーンタイプフィールドを獲得するステップと、前記第１応用シーンタイプフィールドに基づき、前記メディアストリームに対応する応用シーンを決定するステップと、前記メディアストリームに対応する応用シーンに基づき、前記メディアストリームの復号方式及びレンダリング方式のうちの少なくとも一種を決定するステップと、を含む。

本願の実施例はメディアファイルのカプセル化装置を提供し、前記装置は、ターゲットメディアコンテンツの当該ターゲットメディアコンテンツに対応する応用シーン下でのメディアストリームを取得することに用いられるメディアストリーム取得ユニットと、前記メディアストリームをカプセル化し、前記メディアストリームのカプセル化ファイルを生成することに用いられるメディアストリームカプセル化ユニットであって、前記カプセル化ファイルには第１応用シーンタイプフィールドが含まれ、前記第１応用シーンタイプフィールドは前記メディアストリームに対応する応用シーンを示すことに用いられる、メディアストリームカプセル化ユニットと、前記カプセル化ファイルを第１機器に送信することにより前記第１機器は前記第１応用シーンタイプフィールドに基づき前記メディアストリームに対応する応用シーンを決定し、且つ前記メディアストリームに対応する応用シーンに基づき前記メディアストリームの復号方式及びレンダリング方式のうちの少なくとも一種を決定することに用いられるカプセル化ファイル送信ユニットと、を含む。

本願の実施例はメディアファイルのカプセル化解除装置を提供し、前記装置は、ターゲットメディアコンテンツの当該ターゲットメディアコンテンツに対応する応用シーン下でのメディアストリームのカプセル化ファイルを受信することに用いられるカプセル化ファイル受信ユニットであって、前記カプセル化ファイルには第１応用シーンタイプフィールドが含まれ、前記第１応用シーンタイプフィールドは前記メディアストリームに対応する応用シーンを示すことに用いられる、カプセル化ファイル受信ユニットと、前記カプセル化ファイルをカプセル化解除し、前記第１応用シーンタイプフィールドを獲得することに用いられるファイルカプセル化解除ユニットと、前記第１応用シーンタイプフィールドに基づき、前記メディアストリームに対応する応用シーンを決定することに用いられる応用シーン獲得ユニットと、前記メディアストリームに対応する応用シーンに基づき、前記メディアストリームの復号方式及びレンダリング方式のうちの少なくとも一種を決定することに用いられる復号レンダリング決定ユニットと、を含む。

本願の実施例はコンピュータ可読記憶媒体を提供し、それにおいてコンピュータプログラムが記憶されており、前記プログラムがプロセッサにより実行されるときに、上記実施例における前記メディアファイルのカプセル化方法又はメディアファイルのカプセル化解除方法を実現する。

本願の実施例は電子機器を提供し、少なくとも１つのプロセッサと、少なくとも１つのプログラムを記憶するように配置される記憶装置と、を含み、前記少なくとも１つのプログラムが前記少なくとも１つのプロセッサにより実行されるときに、前記少なくとも１つのプロセッサに上記実施例における前記メディアファイルのカプセル化方法又はメディアファイルのカプセル化解除方法を実現させる。

本願の実施例はコンピュータプログラム製品を提供し、命令を含み、それがコンピュータ上で作動されるときに、コンピュータに上記実施例における前記メディアファイルのカプセル化方法又はメディアファイルのカプセル化解除方法を実行させる。

本願のいくつかの実施例が提供する技術的手段において、対応する応用シーン下でのメディアストリームのカプセル化ファイルを生成するときに、カプセル化ファイルにおいて第１応用シーンタイプフィールドを拡張し、該第１応用シーンタイプフィールドによって該メディアストリームに対応する応用シーンを示し、それによってメディアファイルのカプセル化において異なるメディアストリームに対応する応用シーンを区別することを実現する。一方では、該カプセル化ファイルを第１機器に送信するときに、該第１機器は該カプセル化ファイルにおける第１応用シーンタイプフィールドに基づき該メディアストリームの応用シーンを区別でき、それにより該メディアストリームに対応する応用シーンに基づき該メディアストリームに対してどの復号方式又はレンダリング方式を使用するかを決定でき、第１機器の演算能力及びリソースを節約できる。他方では、カプセル化段階でメディアストリームの応用シーンを決定できるため、第１機器がメディアストリームの復号能力を備えていないとしても、該メディアストリームに対応する応用シーンを決定でき、区別できるために該メディアストリームを復号した後まで待つ必要がない。

３自由度の模式図を模式的に示す。 ３自由度＋の模式図を模式的に示す。 ６自由度の模式図を模式的に示す。 本願の一実施例によるメディアファイルのカプセル化方法のフローチャートを模式的に示す。 本願の一実施例によるメディアファイルのカプセル化方法のフローチャートを模式的に示す。 本願の一実施例によるメディアファイルのカプセル化方法のフローチャートを模式的に示す。 本願の一実施例による６自由度メディアの上下スティッチング方式の模式図を模式的に示す。 本願の一実施例による６自由度メディアの左右スティッチング方式の模式図を模式的に示す。 本願の一実施例による６自由度メディアの深度マップの１／４解像度スティッチング方式の模式図を模式的に示す。 本願の一実施例によるメディアファイルのカプセル化方法のフローチャートを模式的に示す。 本願の一実施例によるメディアファイルのカプセル化方法のフローチャートを模式的に示す。 本願の一実施例によるメディアファイルのカプセル化方法のフローチャートを模式的に示す。 本願の一実施例による第１多視点ビデオの上下スティッチング方式の模式図を模式的に示す。 本願の一実施例による第２多視点ビデオの上下スティッチング方式の模式図を模式的に示す。 本願の一実施例によるメディアファイルのカプセル化解除方法のフローチャートを模式的に示す。 本願の一実施例によるメディアファイルのカプセル化装置のブロック図を模式的に示す。 本願の一実施例によるメディアファイルのカプセル化解除装置のブロック図を模式的に示す。 本願の実施例を実現するために適する電子機器の構造模式図を示す。

これから、図面を参照しながら例示的な実施形態をより全面的に記述する。しかしながら、例示的な実施形態は複数種の形式で実施することができ、且つここで述べる例に限定されるものではないと理解すべきである。逆に、これらの実施形態を提供することにより本願はより全面的で完全になり、且つ例示的な実施形態のアイディアを当業者に全面的に伝える。

また、記述される特徴、構造又は特性は何らの適切な方式で１つ又はより多くの実施例と併せてもよい。以下の記述において、多くの具体的な詳細を提供することにより、本願の実施例に対する十分な理解を与える。しかしながら、当業者が意識するように、特定の詳細のうちの１つ又はより多くがなくても本願の技術的手段を実施してもよく、又は他の方法、構成要素、装置、又はステップなどを採用してもよい。他の場合には、公知の方法、装置、実現又は操作を詳細に示さない又は記述しないことで、本願の各態様を曖昧にすることを回避する。

図面に示すブロック図は単に機能エンティティであり、必ずしも物理的に独立したエンティティと互いに対応しない。すなわち、ソフトウェア形式を採用してこれらの機能エンティティを実現し、又は少なくとも１つのハードウェアモジュール又は集積回路においてこれらの機能エンティティを実現し、又は異なるネットワーク及び／又はプロセッサ装置及び／又はマイクロコントローラ装置においてこれらの機能エンティティを実現するようにしてもよい。

図面に示すフローチャートは単に例示的な説明であり、必ずしもすべてのコンテンツ及び操作／ステップを含まず、必ずしも記述される順序に応じて実行されない。例えば、ある操作／ステップはさらに分解されてもよいが、ある操作／ステップは合併又は部分的に合併されてもよく、従って、実際に実行される順序は実際の状況に応じて変更される可能性がある。

まず、本願の実施例に関する用語の一部を説明する。

点群（Ｐｏｉｎｔ Ｃｌｏｕｄ）：点群は空間において不規則に分布し、３次元物体又はシーンの空間構造及び表面属性を表す１組の離散点のセットである。点群とは大量の３次元点の集合を指し、点群のうちの各点は少なくとも３次元位置情報を有し、応用シーンの差異に基づき、色彩（色）、材質又は他の情報（例えば反射率などの付加的属性）を有する可能性もある。通常、点群のうちの各点はいずれも同じ数の付加的属性を有する。例えば、レーザー測定の原理に基づき得られた点群は、３次元座標（ＸＹＺ）及びレーザー反射強度（ｒｅｆｌｅｃｔａｎｃｅ）を含み、写真測定の原理に基づき得られた点群は、３次元座標（ＸＹＺ）及び色情報（ＲＧＢ、赤緑青）を含み、レーザー測定及び写真測定の原理を併せて得られた点群は、３次元座標（ＸＹＺ）、レーザー反射強度（ｒｅｆｌｅｃｔａｎｃｅ）及び色情報（ＲＧＢ）を含む。

ここで、用途に応じて、点群は機械で感知される点群及び人間の目で感知される点群の二種類に大きく分けられてもよい。ここで、機械で感知される点群は、例えば、自律ナビゲーションシステム、リアルタイムパトロールシステム、地理情報システム、視覚ピッキングロボット、又は災害救援ロボットなどのシーンに用いられてもよく、人間の目で感知される点群は、例えば、デジタル文化遺産、自由視点放送、３次元没入通信、又は３次元没入インタラクションなどのシーンに用いられてもよい。

ここで、取得する手法に応じて、点群は静的点群、動的点群及び動的取得点群の三種類に分けられてもよく、第１類の静的点群について、すなわち、物体は静止し、点群を取得する機器も静止し、第２類の動的点群について、物体は運動するが、点群を取得する機器は静止し、第３類の動的取得点群について、点群を取得する機器は運動する。

ＰＣＣ：Ｐｏｉｎｔ Ｃｌｏｕｄ Ｃｏｍｐｒｅｓｓｉｏｎ、点群圧縮である。点群は大量の点の集合であり、これらの点群データは大量の記憶メモリを消費し得るだけでなく、且つ伝送に不利であり、関連技術では、点群を圧縮せずにネットワーク層で直接伝送することをサポートできる十分な帯域幅がなく、従って点群を圧縮することは非常に必要である。

Ｇ－ＰＣＣ：Ｇｅｏｍｅｔｒｙ－ｂａｓｅｄ Ｐｏｉｎｔ Ｃｌｏｕｄ Ｃｏｍｐｒｅｓｓｉｏｎ、幾何学的特徴に基づく点群圧縮である。Ｇ－ＰＣＣは第１類の静的点群及び第３類の動的取得点群を圧縮することに用いられてもよく、このように獲得する点群メディアは幾何学的特徴に基づいて圧縮された点群メディアと呼ばれてもよく、Ｇ－ＰＣＣ点群メディアと略称される。

Ｖ－ＰＣＣ：Ｖｉｄｅｏ－ｂａｓｅｄ Ｐｏｉｎｔ Ｃｌｏｕｄ Ｃｏｍｐｒｅｓｓｉｏｎ、従来のビデオ符号化に基づく点群圧縮である。Ｖ－ＰＣＣは第２類の動的点群を圧縮することに用いられてもよく、このように獲得する点群メディアは従来のビデオ符号化方式に基づいて圧縮された点群メディアと呼ばれてもよく、Ｖ－ＰＣＣ点群メディアと略称される。

ｓａｍｐｌｅ：サンプルであり、メディアファイルカプセル化過程におけるカプセル化単位であり、１つのメディアファイルは多数のサンプルからなる。メディアファイルがビデオメディアであることを例とすると、ビデオメディアの１つのサンプルは通常、１つのビデオフレームである。

ＤｏＦ：Ｄｅｇｒｅｅ ｏｆ Ｆｒｅｅｄｏｍ、自由度である。力学システムにおいて独立する座標の個数を指し、並進の自由度を除き、さらに回転及び振動の自由度がある。本願の実施例において、自由度とはユーザーが没入型メディアを視聴するときに、サポートする運動で且つコンテンツインタラクションを発生させる自由度を指す。

３ＤｏＦ：すなわち３自由度であり、ユーザーの頭部がＸＹＺ軸の周りに回転する三種の自由度を指す。図１は３自由度の模式図を模式的に示す。図１に示すように、ある場所、ある１つの点において３つの軸上でいずれも回転することができ、頭を回転させることができ、頭を上下に曲げることもでき、頭を振ることもできる。３自由度の体験によって、ユーザーは３６０度で１つの現場に没入できる。もし静的であれば、パノラマピクチャであると理解できる。もしパノラマピクチャが動的であれば、パノラマビデオであり、つまりＶＲビデオである。しかし、３自由度のＶＲビデオは一定の局限性があり、すなわち、ユーザーは移動できず、任意の１つの場所を選択して視聴することができない。

３ＤｏＦ＋：すなわち、３自由度をもとに、ユーザーはさらにＸＹＺ軸に沿って有限運動を行う自由度を持ち、それは制限された６自由度とも呼ばれてもよく、これに対応するメディアストリームは制限された６自由度メディアストリームと呼ばれてもよい。図２は３自由度＋の模式図を模式的に示す。

６ＤｏＦ：すなわち、３自由度をもとに、ユーザーはさらにＸＹＺ軸に沿って自由に運動する自由度を持ち、これに対応するメディアストリームは６自由度メディアストリームと呼ばれてもよい。図３は６自由度の模式図を模式的に示す。ここで、６ＤｏＦメディアとは６自由度ビデオを指し、ビデオが３次元空間のＸＹＺ軸方向に視点を自由に移動させ、及びＸＹＸ軸の周りに視点を自由に回転させる高自由度の視聴体験をユーザーに提供できることを指す。６ＤｏＦメディアはカメラアレイにより収集して得られた空間の異なる視点に対応するビデオ組み合わせである。６ＤｏＦメディアの表現、記憶、圧縮及び処理を容易にするために、６ＤｏＦメディアデータを、マルチカメラにより収集されたテクスチャマップ、マルチカメラのテクスチャマップと対応する深度マップ、及び相応な６ＤｏＦメディアコンテンツ記述メタデータという情報の組み合わせとして表す。メタデータには、マルチカメラのパラメータ、並びに６ＤｏＦメディアのスティッチングレイアウト及びエッジ保護などの記述情報が含まれる。符号化側では、マルチカメラのテクスチャマップ情報と対応する深度マップ情報とに対してスティッチング処理を行い、且つ定義されたシンタックス及びセマンティクスに基づき、スティッチングして得られた記述データをメタデータに書き込む。平面ビデオ圧縮方式によってスティッチング後のマルチカメラの深度マップ及びテクスチャマップ情報を符号化し、且つ端末に伝送して復号した後に、ユーザーが要求する６ＤｏＦ仮想視点の合成を行い、それにより６ＤｏＦメディアの視聴体験をユーザーに提供する。

ボリュメトリックメディア：没入型メディアの一種であり、例えば、ボリュメトリックビデオを含んでもよい。ボリュメトリックビデオは３次元データ表現であり、現状では、主流の符号化はいずれも２次元のビデオデータに基づくものであるため、元のボリュメトリックビデオデータに対してシステム層においてカプセル化、及び伝送などの処理を行う前に、まずそれを３次元から２次元に変換してから符号化を行う必要がある。ボリュメトリックビデオのコンテンツ表示の過程において、さらに２次元で表現されたデータを３次元データに変換して、最終的に表示されるボリュメトリックビデオを表す必要がある。ボリュメトリックビデオをどのように２次元平面で表すかはシステム層でのカプセル化、伝送、及び最後のボリュメトリックビデオのコンテンツ表示処理に直接作用し得る。

アトラス（ａｔｌａｓ）：２Ｄ（２－ｄｉｍｅｎｓｉｏｎ、２次元）の平面フレームにおける領域情報、３Ｄ（３－ｄｉｍｅｎｓｉｏｎ、３次元）表示空間の領域情報、両者間のマッピング関係、及びマッピングに必要な必要パラメータ情報を示す。アトラスは、パッチ、及びパッチがボリュメトリックデータの３次元空間における１つの領域に対応付けられた関連情報の集合を含む。パッチ（ｐａｔｃｈ）はアトラスにおける１つの矩形領域であり、３次元空間のボリュメトリック情報に関連する。ボリュメトリックビデオの２次元表現のコンポーネントデータを処理してパッチを生成し、幾何学的コンポーネントデータで表現されるボリュメトリックビデオの位置に基づき、ボリュメトリックビデオの２次元表現が所在する２次元平面領域を異なるサイズの複数の矩形領域に分割する。１つの矩形領域は１つのパッチであり、パッチは該矩形領域を３次元空間に逆投影する必要情報を含み、パッチをパッキングしてアトラスを生成し、パッチを１つの２次元グリッドに入れ、且つ各パッチにおける有効部分が重なっていないことを確実にする。１つのボリュメトリックビデオにより生成されるパッチを１つ又は複数のアトラスにパッキングしてもよい。アトラスデータに基づいて対応する幾何学的データ、属性データ及びスタブデータを生成し、アトラスデータ、幾何学的データ、属性データ、及びスタブデータの組み合わせに基づきボリュメトリックビデオの２次元平面での最終的な表現を生成する。ここで、幾何学的コンポーネントは必須であり、スタブコンポーネントは条件付き必須であり、属性コンポーネントはオプションである。

ＡＶＳ：Ａｕｄｉｏ Ｖｉｄｅｏ Ｃｏｄｉｎｇ Ｓｔａｎｄａｒｄ、オーディオビデオ符号化標準である。

ＩＳＯＢＭＦＦ：ＩＳＯ Ｂａｓｅｄ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ、ＩＳＯ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｔａｎｄａｒｄ Ｏｒｇａｎｉｚａｔｉｏｎ、国際標準化機構）標準に基づくメディアファイルフォーマットである。ＩＳＯＢＭＦＦはメディアファイルのカプセル化標準であり、最も典型的なＩＳＯＢＭＦＦファイルはＭＰ４（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ ４、ＭＰＥＧ４）ファイルである。

深度マップ（Ｄｅｐｔｈ ｍａｐ）：一種の３次元シーン情報の表現方式として、深度マップの各画素点のグレー値はシーンにおけるある１つの点からカメラまでの距離を表すことに用いられてもよい。

本願の実施例が提供するメディアファイルのカプセル化方法は任意の電子機器により実行されてもよく、以下の例示的な説明において、没入型システムに応用されるサーバが該メディアファイルのカプセル化を実行することを例として例示的な説明を行うが、本願はこれに限定されない。

図４は本願の一実施例によるメディアファイルのカプセル化方法のフローチャートを模式的に示す。図４に示すように、本願の実施例が提供する方法は以下のステップを含んでもよい。

ステップＳ４１０では、ターゲットメディアコンテンツの当該ターゲットメディアコンテンツに対応する応用シーン下でのメディアストリームを取得する。

本願の実施例において、ターゲットメディアコンテンツはビデオ、オーディオ、及び画像などのうちの任意の一種の又は複数種の組み合わせであってもよく、以下の例示的な説明において、ビデオを例として例示的な説明を行うが、本願はこれに限定されない。

本願の実施例において、上記メディアストリームは、６自由度（６ＤｏＦ）メディアストリーム、及び制限された６自由度（３ＤｏＦ＋）メディアストリームなどの、３Ｄ空間内に存在するレンダリング可能な任意のメディアストリームを含んでもよく、以下の例示的な説明において、６ＤｏＦメディアストリームを例として例示的な説明を行う。本願の実施例が提供する方法は、６ＤｏＦメディアコンテンツの録画放送、オンデマンド、生放送、通信、番組編集、及び制作などの応用に適用できる。

没入型メディアは、ユーザーがターゲットメディアコンテンツを消費するときにサポートできる自由度に応じて、３ＤｏＦメディア、３ＤｏＦ＋メディア、及び６ＤｏＦメディアに分けられてもよい。ここで、６ＤｏＦメディアは多視点ビデオ及び点群メディアを含んでもよい。

ここで、点群メディアは符号化方式から、さらに従来のビデオ符号化方式に基づいて圧縮された点群メディア（すなわちＶ－ＰＣＣ）、及び幾何学的特徴に基づいて圧縮された点群メディア（Ｇ－ＰＣＣ）に分けられてもよい。

多視点ビデオについては、通常、カメラアレイにより複数の角度（視点とも呼ばれてもよい）から同一シーンを撮影し、シーンのテクスチャ情報（色彩情報など）を含むテクスチャマップ及び深度情報（空間距離情報など）を含む深度マップを形成し、さらに２Ｄ平面フレームから３Ｄ表示空間へのマッピング情報に加え、ユーザー側で消費可能な６ＤｏＦメディアを構成する。

関連技術からわかるように、６ＤｏＦメディアの応用形式は様々であり、ユーザーは異なる応用シーンの６ＤｏＦメディアに対してカプセル化解除、復号及びレンダリングを行うときに、必要な操作ステップ及び処理能力はそれぞれ異なる。

例えば、多視点ビデオ及びＶ－ＰＣＣの符号化は１セットのルールであり、Ｇ－ＰＣＣの符号化はもう１セットのルールであり、両者の符号化標準は異なり、したがって、復号処理の方式も異なる。

さらに例えば、多視点ビデオ及びＶ－ＰＣＣの符号化標準は同じであるが、一方はピクチャを３Ｄ空間にレンダリングするが、他方は一群の点を３Ｄ空間にレンダリングし、従って、いくつかの相違点が存在し得る。また、多視点ビデオはテクスチャマップ及び深度マップを必要とするが、Ｖ－ＰＣＣはこれらに加えて、さらに占有マップを必要とする可能性があり、これも１つの相違点である。

ステップＳ４２０では、上記メディアストリームをカプセル化し、上記メディアストリームのカプセル化ファイルを生成する。上記カプセル化ファイルには第１応用シーンタイプフィールドが含まれ、上記第１応用シーンタイプフィールドは上記メディアストリームに対応する応用シーンを示すことに用いられる。

例えば、６ＤｏＦメディアの応用を対象としてもよく、本願の実施例は異なる６ＤｏＦメディアの応用シーンを区別できる。

現在の業界では６ＤｏＦメディアをボリュメトリックメディアとして統一的に定義するため、もしファイルカプセル化過程において異なる応用シーンを区別できないなら、ユーザー側の処理に不必要な面倒をもたらし得る。例えば、もしメディアファイルのカプセル化過程においてこれらのメディアファイルに対応する異なる応用シーンを区別できないとすれば、メディアストリームを復号してから区別する必要がある。一方では、これは演算リソースの浪費を引き起こすようになり、他方では、例えばＣＤＮ（Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ Ｎｅｔｗｏｒｋ、コンテンツ配信ネットワーク）ノードのようないくつかの中間ノードは復号能力を備えないため、復号が失敗する状況の発生を引き起こす。

上記のように、これらの異なる応用自体の処理方式は異なり、区別する必要があり、ファイルカプセル化過程において応用シーンを区別するメリットはメディアファイルの非常に上位の層でこの情報を取得できることである。それにより演算リソースを節約でき、同時に例えばＣＤＮノードのような復号能力を備えないいくつかの中間ノードもこの情報を取得できる。

ステップＳ４３０では、上記カプセル化ファイルを第１機器に送信することにより上記第１機器は上記第１応用シーンタイプフィールドに基づき上記メディアストリームに対応する応用シーンを決定し、且つ上記メディアストリームの応用シーンに基づき上記メディアストリームの復号方式及びレンダリング方式のうちの少なくとも一種を決定する。

本願の実施例において、第１機器は任意の中間ノードであってもよく、該メディアストリームを消費する任意のユーザー端末であってもよく、本願においてはこれを限定しない。

本願の実施形態が提供するメディアファイルのカプセル化方法は、対応する応用シーン下でのメディアストリームのカプセル化ファイルを生成するときに、カプセル化ファイルにおいて第１応用シーンタイプフィールドを拡張し、該第１応用シーンタイプフィールドによって該メディアストリームに対応する応用シーンを示し、それによってメディアファイルのカプセル化において異なるメディアストリームの異なる応用シーンを区別できる。一方では、該カプセル化ファイルを第１機器に送信するときに、該第１機器は該カプセル化ファイルにおける第１応用シーンタイプフィールドに基づき該メディアストリームの応用シーンを区別でき、それにより該メディアストリームに対応する応用シーンに基づき該メディアストリームに対してどの復号方式及び／又はレンダリング方式を使用するかを決定でき、第１機器の演算能力及びリソースを節約できる。他方では、カプセル化段階でメディアストリームの応用シーンを決定できるため、第１機器がメディアストリームの復号能力を備えないとしても、該メディアストリームに対応する応用シーンを決定でき、区別できるために該メディアストリームを復号した後まで待つ必要がない。

図５は本願の一実施例によるメディアファイルのカプセル化方法のフローチャートを模式的に示す。図５に示すように、本願の実施例が提供する方法は以下のステップを含んでもよい。

図５の実施例におけるステップＳ４１０は上記実施例を参照できる。

図５の実施例において、上記図４の実施例におけるステップＳ４２０はさらに以下のステップを含んでもよい。

ステップＳ４２１では、ターゲットメディアファイルフォーマットデータボックスのボリュメトリックビジュアルメディアヘッダーデータボックス（例えば、以下で挙げられるＶｏｌｕｍｅｔｒｉｃ Ｖｉｓｕａｌ Ｍｅｄｉａ Ｈｅａｄｅｒ Ｂｏｘ）において上記第１応用シーンタイプフィールドを追加する。

本願の実施例において、例えば６ＤｏＦメディアの応用シーンに基づきメディアファイルに対して対応する識別を行うことができるために、システム層に若干の記述性フィールドを追加してもよく、ファイルカプセル化レベルのフィールド拡張を含んでもよい。例えば、以下の例示的な説明において、ＩＳＯＢＭＦＦデータボックス（ターゲットメディアファイルフォーマットデータボックスとする）の拡張を例として例示的な説明を行うが、本願においてはこれに限定されない。

ステップＳ４２２では、上記メディアストリームに対応する応用シーンに基づき上記第１応用シーンタイプフィールドの数値を決定する。

例示的な実施例において、上記第１応用シーンタイプフィールドの数値は、上記メディアストリームが非大規模アトラス情報の多視点ビデオであることを表す第１値（例えば「０」）と、上記メディアストリームが大規模アトラス情報の多視点ビデオであることを表す第２値（例えば「１」）と、上記メディアストリームが従来のビデオ符号化方式に基づいて圧縮される点群メディアであることを表す第３値（例えば「２」）と、上記メディアストリームが幾何学的特徴に基づいて圧縮される点群メディアであることを表す第４値（例えば「３」）とのうちのいずれか１つを含んでもよい。

理解されるように、第１応用シーンタイプフィールドの数値は上記応用シーンを示すことに限定されず、それはより多い又はより少ない応用シーンを指示することができ、実際のニーズに応じて設定できる。

図５の実施例におけるステップＳ４３０は上記実施例を参照できる。

本願の実施形態が提供するメディアファイルのカプセル化方法は、異なる６ＤｏＦメディアの応用シーンを区別することによって、６ＤｏＦメディアを消費する第１機器が６ＤｏＦメディアのカプセル化解除、復号、及びレンダリング工程などでポリシー選択を適宜行うことができる。

図６は本願の一実施例によるメディアファイルのカプセル化方法のフローチャートを模式的に示す。図６に示すように、本願の実施例が提供する方法は以下のステップを含んでもよい。

図６の実施例におけるステップＳ４１０は上記実施例を参照できる。

図６の実施例において、上記実施例におけるステップＳ４２０はさらに以下のステップＳ４２２１を含んでもよい。すなわち、カプセル化のときに、第１応用シーンタイプフィールドによって、該メディアストリームが大規模アトラス情報の多視点ビデオであると決定している。

ステップＳ４２２１では、メディアストリームをカプセル化し、メディアストリームのカプセル化ファイルを生成し、上記カプセル化ファイルには第１応用シーンタイプフィールド（例えば、以下で挙げられるａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅ）が含まれ、上記第１応用シーンタイプフィールドの数値は上記メディアストリームが大規模アトラス情報の多視点ビデオであることを表す第２値である。

多視点ビデオの場合、その２Ｄ平面フレームから３Ｄ表示空間へのマッピング情報は多視点ビデオの６ＤｏＦ体験を決める。このようなマッピング関係の指示については、二種類の方法が存在する。一種の方法は、アトラスを定義して２Ｄ平面の領域を比較的細かく分割し、さらにこれらの２Ｄ小領域集合から３Ｄ空間へのマッピング関係を示す。このようなものは非大規模アトラス情報と呼ばれ、対応する多視点ビデオは非大規模アトラス情報の多視点ビデオである。もう一種の方法はより大まかであり、収集機器（いずれもカメラを例として例示的な説明を行う）の角度から、各カメラにより生成された深度マップ及びテクスチャマップを直接識別し、且つ各カメラパラメータに基づき、対応する２Ｄ深度マップとテクスチャマップとの３Ｄ空間でのマッピング関係を復元する。このようなものは大規模アトラス情報と呼ばれ、対応する多視点ビデオは大規模アトラス情報の多視点ビデオである。理解できるように、ここでの大規模アトラス情報及び非大規模アトラス情報は相対的なものであり、具体的なサイズを直接限定しない。

ここで、カメラパラメータは通常、カメラの外部パラメータ及び内部パラメータに分けられ、外部パラメータは通常、カメラが撮影する位置、及び角度などの情報を含み、内部パラメータは通常、カメラの光学中心の位置、及び焦点距離の長さなどの情報を含む。

これからわかるように、６ＤｏＦメディアにおける多視点ビデオは大規模アトラス情報の多視点ビデオ及び非大規模アトラス情報の多視点ビデオをさらに含んでもよい。すなわち、６ＤｏＦメディアの応用形式は様々であり、ユーザーは異なる応用シーンの６ＤｏＦメディアに対してカプセル化解除、復号及びレンダリングを行うときに、必要な操作ステップ及び処理能力はそれぞれ異なる。

例えば、大規模アトラス情報と非大規模アトラス情報との相違点は、２Ｄ領域から３Ｄ空間へのマッピング及びレンダリングの粒度が異なることであり、大規模アトラス情報は６つの２Ｄ断片を３Ｄ空間にマッピングすると仮定すると、非大規模アトラス情報は６０個の断片を３Ｄ空間にマッピングする可能性がある。この場合、これら二種のマッピングのアルゴリズムの複雑さは間違いなく異なり、大規模アトラス情報のアルゴリズムは非大規模アトラス情報のアルゴリズムよりも簡単になる。

特に、多視点ビデオの場合、もしその２Ｄ領域から３Ｄ空間へのマッピング関係がカメラパラメータにより得られ、すなわちそれが大規模アトラス情報の多視点ビデオであるなら、カプセル化ファイルにおいてより小さい２Ｄ領域から３Ｄ空間へのマッピング関係を定義する必要がない。

該メディアストリームが大規模アトラス情報の多視点ビデオであるときに、上記方法はさらに以下のステップを含んでもよい。

ステップＳ６０１では、もし上記メディアストリームをシングルトラックに応じてカプセル化するなら、上記ターゲットメディアファイルフォーマットデータボックスのビットストリームサンプルエントリ（例えば、以下で例示的に説明されるＶ３ＣｂｉｔｓｔｒｅａｍＳａｍｐｌｅＥｎｔｒｙであるが、本願はこれに限定されない）において大規模アトラス識別子（例えば、以下で挙げられるｌａｒｇｅ＿ｓｃａｌｅ＿ａｔｌａｓ＿ｆｌａｇ）を追加する。

ステップＳ６０２では、もし上記大規模アトラス識別子が上記メディアストリームは大規模アトラス情報の多視点ビデオであることを示すなら、上記ビットストリームサンプルエントリにおいて、上記メディアストリームを収集するカメラの数量識別子（例えば、以下で挙げられるｃａｍｅｒａ＿ｃｏｕｎｔ）、及び上記メディアストリームの現在のファイルに含まれるカメラに対応する視点数識別子（例えば、以下で挙げられるｃａｍｅｒａ＿ｃｏｕｎｔ＿ｃｏｎｔａｉｎｅｄ）を追加する。

ステップＳ６０３では、上記ビットストリームサンプルエントリにおいて、上記現在のファイルに含まれるカメラに対応する視点で収集されたテクスチャマップと深度マップとの解像度（例えば、以下で挙げられるｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｘ及びｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｙ）を追加する。

引き続き図６に参照されるように、さらに、上記方法はさらに以下のステップＳ６０４～Ｓ６０７のうちの少なくとも１つを含む。

ステップＳ６０４では、上記ビットストリームサンプルエントリにおいて、上記現在のファイルに含まれるカメラに対応する視点で収集された深度マップのダウンサンプリング倍数因子（例えば、以下で挙げられるｄｅｐｔｈ＿ｄｏｗｎｓａｍｐｌｅ＿ｆａｃｔｏｒ）を追加する。

ステップＳ６０５では、上記ビットストリームサンプルエントリにおいて、上記現在のファイルに含まれるカメラに対応する視点で収集されたテクスチャマップの左上頂点の上記大規模アトラス情報における平面フレームの原点に対するオフセット量（例えば、以下で挙げられるｔｅｘｔｕｒｅ＿ｖｅｔｅｘ＿ｘ及びｔｅｘｔｕｒｅ＿ｖｅｔｅｘ＿ｙ）を追加する。

ステップＳ６０６では、上記ビットストリームサンプルエントリにおいて、上記現在のファイルに含まれるカメラに対応する視点で収集された深度マップの左上頂点の上記大規模アトラス情報における平面フレームの原点に対するオフセット量（例えば、以下で挙げられるｄｅｐｔｈ＿ｖｅｔｅｘ＿ｘ及びｄｅｐｔｈ＿ｖｅｔｅｘ＿ｙ）を追加する。

ステップＳ６０７では、上記ビットストリームサンプルエントリにおいて、上記現在のファイルに含まれるカメラに対応する視点で収集されたテクスチャマップと深度マップとのパディング幅（例えば、以下で挙げられるｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｔｅｘｔｕｒｅ及びｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｄｅｐｔｈ）を追加する。

本願の実施例において、ｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｔｅｘｔｕｒｅとｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｄｅｐｔｈとはそれぞれ各テクスチャマップ及び深度マップのエッジ保護領域のサイズを定義しており、これはスティッチング画像を圧縮するときのエッジ突然変化領域を保護するためである。ｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｔｅｘｔｕｒｅとｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｄｅｐｔｈとの値はテクスチャマップと深度マップとのエッジ保護領域の幅を表現し、ｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｔｅｘｔｕｒｅとｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｄｅｐｔｈとは０に等しいことは、何らのエッジ保護もないことを表す。

引き続き図６に参照されるように、該メディアストリームが大規模アトラス情報の多視点ビデオであるときに、上記方法はさらに以下のステップを含んでもよい。

ステップＳ６０８では、もし上記メディアストリームをマルチトラックに応じてカプセル化するなら、上記ターゲットメディアファイルフォーマットデータボックスのサンプルエントリにおいて大規模アトラス識別子を追加する。

ステップＳ６０９では、もし上記大規模アトラス識別子が上記メディアストリームは大規模アトラス情報の多視点ビデオであることを示すなら、上記サンプルエントリにおいて、上記メディアストリームを収集するカメラの数量識別子、及び上記メディアストリームの現在のファイルに含まれるカメラに対応する視点数識別子を追加する。

ステップＳ６１０では、上記サンプルエントリにおいて、上記現在のファイルに含まれるカメラに対応する視点で収集されたテクスチャマップと深度マップとの解像度を追加する。

引き続き図６に参照されるように、さらに、上記方法はさらに以下のステップＳ６１１～Ｓ６１４のうちの少なくとも１つを含む。

ステップＳ６１１では、上記サンプルエントリにおいて、上記現在のファイルに含まれるカメラに対応する視点で収集された深度マップのダウンサンプリング倍数因子を追加する。

ステップＳ６１２では、上記サンプルエントリにおいて、上記現在のファイルに含まれるカメラに対応する視点で収集されたテクスチャマップの左上頂点の上記大規模アトラス情報における平面フレームの原点に対するオフセット量を追加する。

ステップＳ６１３では、上記サンプルエントリにおいて、上記現在のファイルに含まれるカメラに対応する視点で収集された深度マップの左上頂点の上記大規模アトラス情報における平面フレームの原点に対するオフセット量を追加する。

ステップＳ６１４では、上記サンプルエントリにおいて、上記現在のファイルに含まれるカメラに対応する視点で収集されたテクスチャマップと深度マップとのパディング幅を追加する。

図６の実施例におけるステップＳ４３０は上記実施例を参照できる。

本願の実施例において、ｓｉｘ＿ｄｏｆ＿ｓｔｉｔｃｈｉｎｇ＿ｌａｙｏｕｔフィールドを採用して６ＤｏＦメディアにおける各カメラに対応する視点で収集された深度マップとテクスチャマップとのスティッチング方法を示すことができ、これは６ＤｏＦメディアのテクスチャマップと深度マップとのスティッチングレイアウトを識別することに用いられ、具体的な数値は下記［表１］を参照すればよい。

図７は本願の一実施例による６自由度メディアの上下スティッチング方式の模式図を模式的に示す。

ｓｉｘ＿ｄｏｆ＿ｓｔｉｔｃｈｉｎｇ＿ｌａｙｏｕｔの値が０であるときに、６ＤｏＦメディアのスティッチングモードは上下スティッチングである。図７に示すように、上下スティッチングモードにおいて、マルチカメラにより収集されたテクスチャマップ（例えば、図７における視点１のテクスチャマップ、視点２のテクスチャマップ、視点３のテクスチャマップ、及び視点４のテクスチャマップ）は順序に応じて画像の上方に配列される一方、互いに対応する深度マップ（例えば、図７における視点１の深度マップ、視点２の深度マップ、視点３の深度マップ、及び視点４の深度マップ）は順番に画像の下方に配列される。

スティッチング後の６ＤｏＦメディアの解像度をｎＷｉｄｔｈ×ｎＨｅｉｇｈｔに設定し、再構成モジュールはｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｘ及びｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｙの値を利用して相応な各カメラのテクスチャマップ及び深度マップのレイアウト位置を算出できることにより、さらにマルチカメラのテクスチャマップ及び深度マップ情報を利用して６ＤｏＦメディアの再構成を行う。

図８は本願の一実施例による６自由度メディアの左右スティッチング方式の模式図を模式的に示す。

ｓｉｘ＿ｄｏｆ＿ｓｔｉｔｃｈｉｎｇ＿ｌａｙｏｕｔの値が１であるときに、６ＤｏＦメディアのスティッチングモードは左右スティッチングである。図８に示すように、左右スティッチングモードにおいて、マルチカメラにより収集されたテクスチャマップ（例えば、図８における視点１のテクスチャマップ、視点２のテクスチャマップ、視点３のテクスチャマップ、及び視点４のテクスチャマップ）は順序に応じて画像の左方に配列される一方、互いに対応する深度マップ（例えば、図８における視点１の深度マップ、視点２の深度マップ、視点３の深度マップ、及び視点４の深度マップ）は順番に画像の右方に配列される。

図９は本願の一実施例による６自由度メディアの深度マップの１／４解像度スティッチング方式の模式図を模式的に示す。

ｓｉｘ＿ｄｏｆ＿ｓｔｉｔｃｈｉｎｇ＿ｌａｙｏｕｔの値が２であるときに、６ＤｏＦメディアのスティッチングモードは深度マップの１／４ダウンサンプリングのスティッチングである。図９に示すように、深度マップの１／４ダウンサンプリングのスティッチング方式において、深度マップ（例えば、図９における視点１の深度マップ、視点２の深度マップ、視点３の深度マップ、及び視点４の深度マップ）は１／４解像度ダウンサンプリングを行った後に、テクスチャマップ（例えば、図９における視点１のテクスチャマップ、視点２のテクスチャマップ、視点３のテクスチャマップ、及び視点４のテクスチャマップ）の右下方にスティッチングされる。もし深度マップのスティッチングが最終的なスティッチングマップの矩形領域を埋め尽くすことができないとすれば、残りの部分に空白の画像を充填する。

本願の実施形態が提供するメディアファイルのカプセル化方法は、異なる６ＤｏＦメディアの応用シーンを区別できるだけでなく、６ＤｏＦメディアを消費する第１機器は６ＤｏＦメディアのカプセル化解除、復号、及びレンダリング工程でポリシー選択を適宜行うことができる。さらに、６ＤｏＦメディアにおける多視点ビデオ応用に対して、ファイルカプセル化において多視点ビデオの深度マップ、及びテクスチャマップの関連情報を示す一種の方法を提案することにより、多視点ビデオの異なる視点の深度マップ、及びテクスチャマップのカプセル化組み合わせ方式はより柔軟なものとなる。

例示的な実施例において、上記方法は、上記ターゲットメディアコンテンツのターゲット記述ファイルを生成するステップであって、上記ターゲット記述ファイルには第２応用シーンタイプフィールドが含まれ、上記第２応用シーンタイプフィールドは上記メディアストリームに対応する応用シーンを示すことに用いられる、ステップと、上記ターゲット記述ファイルを上記第１機器に送信することにより上記第１機器は上記第２応用シーンタイプフィールドに基づき、上記メディアストリームのカプセル化ファイルのうちターゲットメディアストリームに対応するターゲットカプセル化ファイルを決定するステップと、をさらに含んでもよい。

相応には、上記カプセル化ファイルを第１機器に送信することにより上記第１機器は上記第１応用シーンタイプフィールドに基づき上記メディアストリームに対応する応用シーンを決定するステップは、上記ターゲットカプセル化ファイルを上記第１機器に送信することにより上記第１機器は上記ターゲットカプセル化ファイルにおける第１応用シーンタイプフィールドに基づき、上記ターゲットメディアストリームに対応するターゲット応用シーンを決定するステップを含んでもよい。

図１０は本願の一実施例によるメディアファイルのカプセル化方法のフローチャートを模式的に示す。図１０に示すように、本願の実施例が提供する方法は以下のステップを含んでもよい。

図１０の実施例におけるステップＳ４１０～Ｓ４２０は上記実施例を参照することができ、それはさらに以下のステップを含んでもよい。

ステップＳ１０１０では、上記ターゲットメディアコンテンツのターゲット記述ファイルを生成し、上記ターゲット記述ファイルには第２応用シーンタイプフィールド（例えば、以下で挙げられるｖ３ｃＡｐｐＴｙｐｅ）が含まれ、上記第２応用シーンタイプフィールドは上記メディアストリームに対応する応用シーンを示す。

本願の実施例において、システム層に若干の記述性フィールドを追加し、上記ファイルカプセル化レベルのフィールド拡張を含むことを除き、さらにシグナリング伝送レベルのフィールドに対して拡張を行ってもよい。以下の実施例において、ＤＡＳＨ（Ｄｙｎａｍｉｃ ａｄａｐｔｉｖｅ ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ、ハイパーテキスト転送プロトコル）、ハイパーテキスト転送プロトコルに基づく動的自己適応ストリーミングメディア伝送） ＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ、メディアファイルの記述ファイル）シグナリング（ターゲット記述ファイルとする）をサポートする形式で例示的な説明を行い、６ＤｏＦメディアの応用シーンタイプ指示及び大規模アトラス指示を定義している。

ステップＳ１０２０では、上記ターゲット記述ファイルを上記第１機器に送信することにより上記第１機器は上記第２応用シーンタイプフィールドに基づき、上記メディアストリームのカプセル化ファイルのうちからターゲットメディアストリームのターゲットカプセル化ファイルを決定する。

ステップＳ１０３０では、上記ターゲットカプセル化ファイルを上記第１機器に送信することにより上記第１機器は上記ターゲットカプセル化ファイルにおける第１応用シーンタイプフィールドに基づき、上記ターゲットメディアストリームのターゲット応用シーンを決定する。

本願の実施形態が提供するメディアファイルのカプセル化方法は、カプセル化ファイルにおいて第１応用シーンタイプフィールドによってメディアストリームに対応する応用シーンを識別できるだけでなく、さらにターゲット記述ファイルにおいて第２応用シーンタイプフィールドによってメディアストリームに対応する応用シーンを識別できる。このように、第１機器はまず、ターゲット記述ファイルにおける第２応用シーンタイプフィールドに基づきそれがどのメディアストリームを取得する必要があるかを決定でき、それによりサーバ端末に相応なターゲットメディアストリームを要求でき、それによりデータの伝送量を減少させ、且つ要求されるターゲットメディアストリームが第１機器の実際の能力にマッチングできることを確実にし、第１機器は要求されるターゲットメディアストリームを受信した後に、さらにカプセル化ファイルにおける第１応用シーンタイプフィールドに基づきターゲットメディアストリームのターゲット応用シーンを決定することにより、どの復号及びレンダリング方式を使用すべきであるかを理解して、演算リソースを低減させることができる。

図１１は本願の一実施例によるメディアファイルのカプセル化方法のフローチャートを模式的に示す。図１１に示すように、本願の実施例が提供する方法は以下のステップを含んでもよい。

図１１の実施例におけるステップＳ４１０～Ｓ４２０は上記実施例を参照できる。

図１１の実施例において、上記図１０の実施例におけるステップＳ１０１０はさらに以下のステップを含んでもよい。

ステップＳ１０１１では、上記ターゲットメディアコンテンツのハイパーテキスト転送プロトコルに基づく動的自己適応ストリーミングメディア伝送のターゲット記述ファイルにおいて上記第２応用シーンタイプフィールドを追加する。

ステップＳ１０１２では、上記メディアストリームに対応する応用シーンに基づき、上記第２応用シーンタイプフィールドの数値を決定する。

図１１の実施例におけるステップＳ１０２０及びステップＳ１０３０は上記実施例を参照できる。

以下、本願の実施例が提案するメディアファイルのカプセル化方法に対して例示的な説明を行う。６ＤｏＦメディアを例として、本願の実施例が提案する方法は６ＤｏＦメディアの応用シーンの指示に用いられてもよく、以下のステップを含んでもよい。

１．６ＤｏＦメディアの応用シーンに基づき、メディアファイルに対して対応する識別を行う。

２．特に、多視点ビデオの場合、その２Ｄ平面フレームから３Ｄ空間へのマッピングが、収集カメラの出力を単位としてマッピングを行うか否かを判断する。すなわち、２Ｄ平面フレームから３Ｄ空間へのマッピングが各カメラにより収集されたテクスチャマップ及び深度マップを単位としてマッピングを行うと、大規模アトラス情報と呼ばれる。もし各カメラにより収集されたテクスチャマップ及び深度マップをさらに比較的細かく分割する必要があり、分割後の２Ｄ小領域集合から３Ｄ空間へのマッピングを示すなら、非大規模アトラス情報と呼ばれる。

３．もし多視点ビデオの２Ｄ平面フレームから３Ｄ空間へのマッピングが収集カメラの出力を単位としてマッピングを行うなら、カプセル化ファイルにおいて異なる収集カメラの出力の関連情報を示す。

本実施例は、システム層に若干の記述性フィールドを追加でき、ファイルカプセル化レベルのフィールド拡張及びシグナリング伝送レベルのフィールド拡張を含んでもよく、それによって本願の実施例の上記ステップをサポートすることができる。以下、ＩＳＯＢＭＦＦデータボックス及びＤＡＳＨ ＭＰＤシグナリングを拡張する形式で例示し、６ＤｏＦメディアの応用タイプ指示及び大規模アトラス指示を定義しており、具体的に以下の通りである（ここで、拡張部分はイタリックで識別される）。

一、ＩＳＯＢＭＦＦデータボックスの拡張
本部分で使用される数学演算子及び優先順位はＣ言語を参照する。特に説明しない限り、番号付け及びカウントは０から開始することを約束する。

ａｌｉｇｎｅｄ（８） ｃｌａｓｓ ＶｏｌｕｍｅｔｒｉｃＶｉｓｕａｌＭｅｄｉａＨｅａｄｅｒＢｏｘ
ｅｘｔｅｎｄｓ ＦｕｌｌＢｏｘ（’ｖｖｈｄ’， ｖｅｒｓｉｏｎ ＝ ０， １） ｛
ｕｎｓｉｇｎｅｄ ｉｎｔ（８） ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅ；／／８ビット符号なし整数の第１応用シーンタイプフィールド
｝
ａｌｉｇｎｅｄ（８） ｃｌａｓｓ Ｖ３ＣＢｉｔｓｔｒｅａｍＳａｍｐｌｅＥｎｔｒｙ（） ｅｘｔｅｎｄｓ ＶｏｌｕｍｅｔｒｉｃＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙ （’ｖ３ｅ１’） ｛ ／／６ＤｏＦメディアをカプセル化するときに、シングルトラック又はマルチトラックに応じてカプセル化することができるため、この構造はシングルトラックの場合に対応する。
Ｖ３ＣＣｏｎｆｉｇｕｒａｔｉｏｎＢｏｘ ｃｏｎｆｉｇ；
ｕｎｓｉｇｎｅｄ ｉｎｔ（１） ｌａｒｇｅ＿ｓｃａｌｅ＿ａｔｌａｓ＿ｆｌａｇ；
ｂｉｔ（７） ｒｅｓｅｒｖｅｄ； ／／予約フィールド、一般的に、フィールドは整数個のｂｙｔｅを必要とし、従って、予約されたｂｉｔ（ビット）で補足する必要がある。
ｉｆ（ｌａｒｇｅ＿ｓｃａｌｅ＿ａｔｌａｓ＿ｆｌａｇ ＝＝ １）｛／／大規模アトラス情報の多視点ビデオであることを示す
ｕｎｓｉｇｎｅｄ ｉｎｔ（８） ｃａｍｅｒａ＿ｃｏｕｎｔ；
ｕｎｓｉｇｎｅｄ ｉｎｔ（８） ｃａｍｅｒａ＿ｃｏｕｎｔ＿ｃｏｎｔａｉｎｅｄ；
ｕｎｓｉｇｎｅｄ ｉｎｔ（８） ｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｄｅｐｔｈ；
ｕｎｓｉｇｎｅｄ ｉｎｔ（８） ｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｔｅｘｔｕｒｅ；
ｆｏｒ（ｉ＝０； ｉ＜ｃａｍｅｒａ＿ｃｏｕｎｔ＿ｃｏｎｔａｉｎｅｄ； ｉ＋＋）｛
ｕｎｓｉｇｎｅｄ ｉｎｔ（８） ｃａｍｅｒａ＿ｉｄ；
ｆｌｏａｔ（３２） ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｘ；／／ ｆｌｏａｔ（３２）は特定値の連続する３２個のバイナリビットを取ることを表す
ｆｌｏａｔ（３２） ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｙ；
ｕｎｓｉｇｎｅｄ ｉｎｔ（８） ｄｅｐｔｈ＿ｄｏｗｎｓａｍｐｌｅ＿ｆａｃｔｏｒ；
ｕｎｓｉｇｎｅｄ ｉｎｔ（３２） ｔｅｘｔｕｒｅ＿ｖｅｔｅｘ＿ｘ；
ｕｎｓｉｇｎｅｄ ｉｎｔ（３２） ｔｅｘｔｕｒｅ＿ｖｅｔｅｘ＿ｙ；
ｕｎｓｉｇｎｅｄ ｉｎｔ（３２） ｄｅｐｔｈ＿ｖｅｔｅｘ＿ｘ；
ｕｎｓｉｇｎｅｄ ｉｎｔ（３２） ｄｅｐｔｈ＿ｖｅｔｅｘ＿ｙ；
｝
｝
｝

ａｌｉｇｎｅｄ（８） ｃｌａｓｓ Ｖ３ＣＳａｍｐｌｅＥｎｔｒｙ（） ｅｘｔｅｎｄｓ ＶｏｌｕｍｅｔｒｉｃＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙ （’ｖ３ｃ１’） ｛ ／／この構造はマルチトラックの場合に対応する。
Ｖ３ＣＣｏｎｆｉｇｕｒａｔｉｏｎＢｏｘ ｃｏｎｆｉｇ；
Ｖ３ＣＵｎｉｔＨｅａｄｅｒＢｏｘ ｕｎｉｔ＿ｈｅａｄｅｒ；
ｕｎｓｉｇｎｅｄ ｉｎｔ（１） ｌａｒｇｅ＿ｓｃａｌｅ＿ａｔｌａｓ＿ｆｌａｇ；
ｂｉｔ（７） ｒｅｓｅｒｖｅｄ；
ｉｆ（ｌａｒｇｅ＿ｓｃａｌｅ＿ａｔｌａｓ＿ｆｌａｇ ＝＝ １）｛
ｕｎｓｉｇｎｅｄ ｉｎｔ（８） ｃａｍｅｒａ＿ｃｏｕｎｔ；
ｕｎｓｉｇｎｅｄ ｉｎｔ（８） ｃａｍｅｒａ＿ｃｏｕｎｔ＿ｃｏｎｔａｉｎｅｄ；
ｕｎｓｉｇｎｅｄ ｉｎｔ（８） ｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｄｅｐｔｈ；
ｕｎｓｉｇｎｅｄ ｉｎｔ（８） ｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｔｅｘｔｕｒｅ；
ｆｏｒ（ｉ＝０； ｉ＜ｃａｍｅｒａ＿ｃｏｕｎｔ＿ｃｏｎｔａｉｎｅｄ； ｉ＋＋）｛
ｕｎｓｉｇｎｅｄ ｉｎｔ（８） ｃａｍｅｒａ＿ｉｄ；
ｆｌｏａｔ（３２） ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｘ；
ｆｌｏａｔ（３２） ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｙ；
ｕｎｓｉｇｎｅｄ ｉｎｔ（８） ｄｅｐｔｈ＿ｄｏｗｎｓａｍｐｌｅ＿ｆａｃｔｏｒ；
ｕｎｓｉｇｎｅｄ ｉｎｔ（３２） ｔｅｘｔｕｒｅ＿ｖｅｔｅｘ＿ｘ；
ｕｎｓｉｇｎｅｄ ｉｎｔ（３２） ｔｅｘｔｕｒｅ＿ｖｅｔｅｘ＿ｙ；
ｕｎｓｉｇｎｅｄ ｉｎｔ（３２） ｄｅｐｔｈ＿ｖｅｔｅｘ＿ｘ；
ｕｎｓｉｇｎｅｄ ｉｎｔ（３２） ｄｅｐｔｈ＿ｖｅｔｅｘ＿ｙ；
｝
｝
｝

本願の実施例において、第１応用シーンタイプフィールドａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅは６ＤｏＦメディアの応用シーンタイプを示し、具体的な数値は下記［表２］に示すコンテンツを含むが、これらに限定されない。

ここで、大規模アトラス識別子ｌａｒｇｅ＿ｓｃａｌｅ＿ａｔｌａｓ＿ｆｌａｇはアトラス情報が大規模アトラス情報であるか否か、すなわち、アトラス情報がカメラパラメータなどの関連情報のみによって取得できるか否かを示し、ここでは、ｌａｒｇｅ＿ｓｃａｌｅ＿ａｔｌａｓ＿ｆｌａｇが１に等しいときに、多視点ビデオ（大規模アトラス情報）であることを示し、０に等しいときには、多視点ビデオ（非大規模アトラス情報）であることを示すと仮定する。

説明する必要がある点として、上記［表２］からわかるように、第１応用シーンタイプフィールドａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅは既に大規模アトラス情報の多視点ビデオであるか否かを示すことができ、ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅの指示が比較的上位であることを考慮して、ｌａｒｇｅ＿ｓｃａｌｅ＿ａｔｌａｓ＿ｆｌａｇを増加させることで、解析を容易にする。使用上は１つだけでよいが、しかし、そのときどのフィールドが採用され得るかを決定できないため、ここでの情報は冗長である。

ここで、ｃａｍｅｒａ＿ｃｏｕｎｔは、６ＤｏＦメディアを収集するすべてのカメラの個数を示すことに用いられ、該メディアストリームを収集するカメラの数量識別子と呼ばれる。ｃａｍｅｒａ＿ｎｕｍｂｅｒの数値は１～２５５である。ｃａｍｅｒａ＿ｃｏｕｎｔ＿ｃｏｎｔａｉｎｅｄは６ＤｏＦメディアの現在のファイルに含まれるカメラに対応する視点の数を表すことに用いられ、現在のファイルに含まれるカメラに対応する視点数識別子と呼ばれる。

ここで、ｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｄｅｐｔｈは深度マップのパディング幅を表す。ｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｔｅｘｔｕｒｅ：テクスチャマップのパディング幅である。ビデオ符号化の過程において、通常、いくつかのパディングを加えることで、ビデオ復号のエラー許容率を向上させるようにする。つまり、ピクチャフレームのエッジにいくつかの付加的な画素を充填する。

ｃａｍｅｒａ＿ｉｄは各視点に対応するカメラ識別子を表す。ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｘ、及びｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｙはカメラにより収集されたテクスチャマップ、及び深度マップの解像度の幅及び高さを表現し、それぞれ対応するカメラにより収集されたＸ及びＹ方向における解像度を表す。ｄｅｐｔｈ＿ｄｏｗｎｓａｍｐｌｅ＿ｆａｃｔｏｒは対応する深度マップのダウンサンプリング倍数因子を表現し、深度マップの実際の解像度の幅及び高さはカメラにより収集された解像度の幅及び高さの１／２^{ｄｅｐｔｈ＿ｄｏｗｎｓａｍｐｌｅ＿ｆａｃｔｏｒ}である。

ｄｅｐｔｈ＿ｖｅｔｅｘ＿ｘ、及びｄｅｐｔｈ＿ｖｅｔｅｘ＿ｙはそれぞれ対応する深度マップの左上頂点の平面フレームの原点（平面フレームの左上頂点）に対するオフセット量におけるＸ、及びＹ成分値を表す。

ｔｅｘｔｕｒｅ＿ｖｅｔｅｘ＿ｘ、及びｔｅｘｔｕｒｅ＿ｖｅｔｅｘ＿ｙはそれぞれ対応するテクスチャマップの左上頂点の平面フレームの原点（平面フレームの左上頂点）に対するオフセット量におけるＸ、及びＹ成分値を表す。

二、ＤＡＳＨ ＭＰＤシグナリングの拡張
ＤＡＳＨ ＭＰＤシグナリングの下記［表３］に示すフォームにおいて第２応用シーンタイプフィールドｖ３ｃＡｐｐＴｙｐｅを拡張できる。

上記図７の実施例に対応して、サーバ端末には１つの多視点ビデオＡが存在し、且つ該多視点ビデオＡのアトラス情報が大規模アトラス情報であると仮定する。

このとき、ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅ＝１；
ｌａｒｇｅ＿ｓｃａｌｅ＿ａｔｌａｓ＿ｆｌａｇ＝１：ｃａｍｅｒａ＿ｃｏｕｎｔ＝４；ｃａｍｅｒａ＿ｃｏｕｎｔ＿ｃｏｎｔａｉｎｅｄ＝４；
ｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｄｅｐｔｈ＝０；ｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｔｅｘｔｕｒｅ＝０；
｛ｃａｍｅｒａ＿ｉｄ＝１；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｘ＝１００；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｙ＝１００；
ｄｅｐｔｈ＿ｄｏｗｎｓａｍｐｌｅ＿ｆａｃｔｏｒ＝０；ｔｅｘｔｕｒｅ＿ｖｅｔｅｘ ＝（０，０）；ｄｅｐｔｈ＿ｖｅｔｅｘ ＝ （０，２００） ｝／／視点１のテクスチャマップ及び視点１の深度マップ
｛ｃａｍｅｒａ＿ｉｄ＝２；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｘ＝１００；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｙ＝１００；
ｄｅｐｔｈ＿ｄｏｗｎｓａｍｐｌｅ＿ｆａｃｔｏｒ＝０；ｔｅｘｔｕｒｅ＿ｖｅｔｅｘ ＝（１００，０）；ｄｅｐｔｈ＿ｖｅｔｅｘ ＝ （１００，２００） ｝／／視点２のテクスチャマップ及び視点２の深度マップ
｛ｃａｍｅｒａ＿ｉｄ＝３；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｘ＝１００；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｙ＝１００；
ｄｅｐｔｈ＿ｄｏｗｎｓａｍｐｌｅ＿ｆａｃｔｏｒ＝０；ｔｅｘｔｕｒｅ＿ｖｅｔｅｘ ＝（０，１００）；ｄｅｐｔｈ＿ｖｅｔｅｘ ＝ （０，３００） ｝／／視点３のテクスチャマップ及び視点３の深度マップ
｛ｃａｍｅｒａ＿ｉｄ＝４；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｘ＝１００；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｙ＝１００；
ｄｅｐｔｈ＿ｄｏｗｎｓａｍｐｌｅ＿ｆａｃｔｏｒ＝０；ｔｅｘｔｕｒｅ＿ｖｅｔｅｘ ＝（１００，１００）；ｄｅｐｔｈ＿ｖｅｔｅｘ ＝ （１００，３００） ｝／／視点４のテクスチャマップ及び視点４の深度マップ

以上のシステム記述は、図７の平面フレームの各領域のデータ構成に対応する。

上記図８の実施例に対応して、サーバ端末には１つの多視点ビデオＡが存在し、且つ該多視点ビデオＡのアトラス情報が大規模アトラス情報であると仮定する。

このとき、ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅ＝１；
ｌａｒｇｅ＿ｓｃａｌｅ＿ａｔｌａｓ＿ｆｌａｇ＝１：ｃａｍｅｒａ＿ｃｏｕｎｔ＝４；ｃａｍｅｒａ＿ｃｏｕｎｔ＿ｃｏｎｔａｉｎｅｄ＝４；
ｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｄｅｐｔｈ＝０；ｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｔｅｘｔｕｒｅ＝０；
｛ｃａｍｅｒａ＿ｉｄ＝１；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｘ＝１００；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｙ＝１００；
ｄｅｐｔｈ＿ｄｏｗｎｓａｍｐｌｅ＿ｆａｃｔｏｒ＝０；ｔｅｘｔｕｒｅ＿ｖｅｔｅｘ ＝（０，０）；ｄｅｐｔｈ＿ｖｅｔｅｘ ＝ （２００，０） ｝
｛ｃａｍｅｒａ＿ｉｄ＝２；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｘ＝１００；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｙ＝１００；
ｄｅｐｔｈ＿ｄｏｗｎｓａｍｐｌｅ＿ｆａｃｔｏｒ＝０；ｔｅｘｔｕｒｅ＿ｖｅｔｅｘ ＝（１００，０）；ｄｅｐｔｈ＿ｖｅｔｅｘ ＝ （３００，０） ｝
｛ｃａｍｅｒａ＿ｉｄ＝３；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｘ＝１００；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｙ＝１００；
ｄｅｐｔｈ＿ｄｏｗｎｓａｍｐｌｅ＿ｆａｃｔｏｒ＝０；ｔｅｘｔｕｒｅ＿ｖｅｔｅｘ ＝（０，１００）；ｄｅｐｔｈ＿ｖｅｔｅｘ ＝ （２００，１００） ｝
｛ｃａｍｅｒａ＿ｉｄ＝４；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｘ＝１００；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｙ＝１００；
ｄｅｐｔｈ＿ｄｏｗｎｓａｍｐｌｅ＿ｆａｃｔｏｒ＝０；ｔｅｘｔｕｒｅ＿ｖｅｔｅｘ ＝（１００，１００）；ｄｅｐｔｈ＿ｖｅｔｅｘ ＝ （３００，１００） ｝

以上のシステム記述は、図８の平面フレームの各領域のデータ構成に対応する。

上記図９の実施例に対応し、サーバ端末には１つの多視点ビデオＡが存在し、且つ該多視点ビデオＡのアトラス情報が大規模アトラス情報であると仮定する。

このとき、ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅ＝１；
ｌａｒｇｅ＿ｓｃａｌｅ＿ａｔｌａｓ＿ｆｌａｇ＝１：ｃａｍｅｒａ＿ｃｏｕｎｔ＝４；ｃａｍｅｒａ＿ｃｏｕｎｔ＿ｃｏｎｔａｉｎｅｄ＝４；
ｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｄｅｐｔｈ＝０；ｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｔｅｘｔｕｒｅ＝０；
｛ｃａｍｅｒａ＿ｉｄ＝１；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｘ＝１００；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｙ＝１００；
ｄｅｐｔｈ＿ｄｏｗｎｓａｍｐｌｅ＿ｆａｃｔｏｒ＝１；ｔｅｘｔｕｒｅ＿ｖｅｔｅｘ ＝（０，０）；ｄｅｐｔｈ＿ｖｅｔｅｘ ＝ （０，２００） ｝
｛ｃａｍｅｒａ＿ｉｄ＝２；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｘ＝１００；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｙ＝１００；
ｄｅｐｔｈ＿ｄｏｗｎｓａｍｐｌｅ＿ｆａｃｔｏｒ＝１；ｔｅｘｔｕｒｅ＿ｖｅｔｅｘ ＝（１００，０）；ｄｅｐｔｈ＿ｖｅｔｅｘ ＝ （５０，２００） ｝
｛ｃａｍｅｒａ＿ｉｄ＝３；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｘ＝１００；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｙ＝１００；
ｄｅｐｔｈ＿ｄｏｗｎｓａｍｐｌｅ＿ｆａｃｔｏｒ＝１；ｔｅｘｔｕｒｅ＿ｖｅｔｅｘ ＝（０，１００）；ｄｅｐｔｈ＿ｖｅｔｅｘ ＝ （１００，２００） ｝
｛ｃａｍｅｒａ＿ｉｄ＝４；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｘ＝１００；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｙ＝１００；
ｄｅｐｔｈ＿ｄｏｗｎｓａｍｐｌｅ＿ｆａｃｔｏｒ＝１；ｔｅｘｔｕｒｅ＿ｖｅｔｅｘ ＝（１００，１００）；ｄｅｐｔｈ＿ｖｅｔｅｘ ＝ （１５０，２００） ｝

以上のシステム記述は、図９の平面フレームの各領域のデータ構成に対応する。

説明する必要がある点として、ｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｄｅｐｔｈ及びｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｔｅｘｔｕｒｅは絶対な数値範囲がなく、異なる数値は本願の実施例が提供する方法に影響しない。本手段は単にｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｄｅｐｔｈ及びｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｔｅｘｔｕｒｅの大きさを示し、ｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｄｅｐｔｈ及びｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｔｅｘｔｕｒｅの大きさがなぜこのようなものであるかは、符号化アルゴリズムにより決められ、本願の実施例が提供する方法とは無関係である。

ここで、ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｘ及びｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｙは深度マップの実際の解像度の幅及び高さ、つまり、各カメラの解像度を計算することに用いられ、多視点ビデオは複数のカメラにより撮影され、異なるカメラの解像度は異なってもよい。ここではすべての視点の解像度の幅及び高さをいずれも１００画素として例示しているが、これは単に例示を容易にするために数値を取っているものであり、実際にはこれに限定されない。

理解できるように、上記組み合わせ方式には限定されず、本願の実施例が提供する方法は任意の組み合わせに対して対応する指示を行うことができる。

第１機器に取り付けられたクライアント端末はサーバ端末から送信される多視点ビデオのカプセル化ファイルを受信した後に、カプセル化ファイルにおける対応するフィールドを解析することによって、多視点ビデオの平面フレームの各領域を異なるカメラのテクスチャマップ、及び深度マップに対応付けることができる。さらに多視点ビデオのメディアストリームにおけるカメラパラメータ情報を復号することによって、平面フレームの各領域を３Ｄレンダリング表示領域に復元することができ、それにより多視点ビデオを消費する。

上記図１０の実施例に対応して例示的な説明を行う。同一ターゲットメディアコンテンツに対して、サーバ端末に３つの異なる形式の６ＤｏＦメディアが存在し、それぞれを多視点ビデオＡ（大規模アトラス情報）、Ｖ－ＰＣＣ点群メディアＢ、及びＧ－ＰＣＣ点群メディアＣであると仮定する。この場合、サーバ端末はこれら３つのメディアストリームをカプセル化するときに、ＶｏｌｕｍｅｔｒｉｃＶｉｓｕａｌＭｅｄｉａＨｅａｄｅｒＢｏｘデータボックスにおけるａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅフィールドに対して対応する値を与える。具体的に言えば、多視点ビデオＡ：ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅ＝１、Ｖ－ＰＣＣ点群メディアＢ：ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅ＝２、Ｇ－ＰＣＣ点群メディアＣ：ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅ＝３である。

同時に、ＭＰＤファイルにおいて多視点ビデオＡ（大規模アトラス情報）、Ｖ－ＰＣＣ点群メディアＢ、及びＧ－ＰＣＣ点群メディアＣの３つのＲｅｐｒｅｓｅｎｔａｔｉｏｎの応用シーンタイプを記述する。すなわち、ｖ３ｃＡｐｐＴｙｐｅフィールドの数値はそれぞれ、多視点ビデオＡ：ｖ３ｃＡｐｐＴｙｐｅ＝１、Ｖ－ＰＣＣ点群メディアＢ：ｖ３ｃＡｐｐＴｙｐｅ＝２、Ｇ－ＰＣＣ点群メディアＣ：ｖ３ｃＡｐｐＴｙｐｅ＝３である。

次に、サーバはＭＰＤシグナリングに対応するターゲット記述ファイルを第１機器に取り付けられたクライアント端末に発行する。

クライアント端末はサーバ端末から送信されるＭＰＤシグナリングに対応するターゲット記述ファイルを受信した後に、クライアント端末の機器能力及び表示ニーズに基づき、対応する応用シーンタイプのターゲットメディアストリームのターゲットカプセル化ファイルを要求する。第１機器のクライアント端末の処理能力が比較的低いと仮定し、従って、クライアント端末は多視点ビデオＡのターゲットカプセル化ファイルを要求する。

この場合、サーバ端末は多視点ビデオＡのターゲットカプセル化ファイルを第１機器のクライアント端末に送信する。

第１機器のクライアント端末はサーバ端末から送信される多視点ビデオＡのターゲットカプセル化ファイルを受信した後に、ＶｏｌｕｍｅｔｒｉｃＶｉｓｕａｌＭｅｄｉａＨｅａｄｅｒＢｏｘデータボックスにおけるａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅフィールドに基づき、現在の６ＤｏＦメディアファイルの応用シーンタイプを決定し、対応する処理を行うことができる。異なる応用シーンタイプは異なる復号及びレンダリング処理アルゴリズムを有するようになる。

多視点ビデオを例とすると、もしａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅ＝１であるなら、該多視点ビデオのアトラス情報はカメラにより収集された深度マップ、及びテクスチャマップを単位とすることを説明している。従って、クライアント端末は相対的に簡単な処理アルゴリズムによって該多視点ビデオを処理することができる。

説明する必要がある点として、他の実施例において、ＤＡＳＨ ＭＰＤを除き、さらに類似するシグナリングファイルに対して同様な拡張を行い、シグナリングファイルにおいて異なるメディアファイルの応用シーンタイプを示すことができる。

例示的な実施例において、上記ターゲットメディアコンテンツの当該ターゲットメディアコンテンツに対応する応用シーン下でのメディアストリームを取得するステップは、第２機器が送信する第１多視点ビデオの第１カプセル化ファイルと第３機器が送信する第２多視点ビデオの第２カプセル化ファイルとを受信するステップと、上記第１カプセル化ファイル及び上記第２カプセル化ファイルをそれぞれカプセル化解除し、上記第１多視点ビデオ及び上記第２多視点ビデオを獲得するステップと、上記第１多視点ビデオ及び上記第２多視点ビデオをそれぞれ復号し、上記第１多視点ビデオにおける第１深度マップ及び第１テクスチャマップ、並びに上記第２多視点ビデオにおける第２深度マップ及び第２テクスチャマップを獲得するステップと、上記第１深度マップ、上記第２深度マップ、上記第１テクスチャマップ及び上記第２テクスチャマップに基づき、合併多視点ビデオを獲得するステップと、を含んでもよい。

ここで、上記第２機器において第１数量のカメラが取り付けられてもよく、上記第３機器において第２数量のカメラが取り付けられてもよく、上記第２機器及び上記第３機器はそれぞれ各自のカメラを利用して同一シーンに対して多視点ビデオの収集及び撮影を行い、上記第１多視点ビデオ及び上記第２多視点ビデオを獲得してもよい。

ここで、上記第１カプセル化ファイル及び上記第２カプセル化ファイルにはいずれも上記第１応用シーンタイプフィールドが含まれてもよく、且つ上記第１カプセル化ファイル及び上記第２カプセル化ファイルにおける第１応用シーンタイプフィールドの数値はそれぞれ、上記第１多視点ビデオ及び上記第２多視点ビデオが大規模アトラス情報の多視点ビデオであることを表すことに用いられる第２値である。

図１２は本願の一実施例によるメディアファイルのカプセル化方法のフローチャートを模式的に示す。図１２に示すように、本願の実施例が提供する方法は以下のステップを含んでもよい。

ステップＳ１２１０では、第２機器が送信する第１多視点ビデオの第１カプセル化ファイルと第３機器が送信する第２多視点ビデオの第２カプセル化ファイルとを受信する。

ステップＳ１２２０では、上記第１カプセル化ファイル及び上記第２カプセル化ファイルをそれぞれカプセル化解除し、上記第１多視点ビデオ及び上記第２多視点ビデオを獲得する。

ステップＳ１２３０では、上記第１多視点ビデオ及び上記第２多視点ビデオをそれぞれ復号し、上記第１多視点ビデオにおける第１深度マップ及び第１テクスチャマップ、並びに上記第２多視点ビデオにおける第２深度マップ及び第２テクスチャマップを獲得する。

ステップＳ１２４０では、上記第１深度マップ、上記第２深度マップ、上記第１テクスチャマップ及び上記第２テクスチャマップに基づき、合併多視点ビデオを獲得する。

ステップＳ１２５０では、合併多視点ビデオをカプセル化し、合併多視点ビデオのカプセル化ファイルを生成し、カプセル化ファイルには第１応用シーンタイプフィールドが含まれ、第１応用シーンタイプフィールドは合併多視点ビデオに対応する応用シーンが大規模アトラス情報の多視点ビデオであることを示すことに用いられる第２値である。

ステップＳ１２６０では、上記カプセル化ファイルを第１機器に送信することにより上記第１機器は上記第１応用シーンタイプフィールドに基づき上記合併多視点ビデオに対応する応用シーンを獲得し、且つ上記合併多視点ビデオに対応する応用シーンに基づき上記合併多視点ビデオの復号又はレンダリング方式を決定する。

以下、図１３及び１４と併せて図１２の実施例が提供する方法に対して例示的な説明を行う。第２機器及び第３機器はそれぞれドローンＡ及びドローンＢであると仮定し（しかし、本願はこれに限定されない）、且つドローンＡ及びドローンＢにそれぞれ２つのカメラ（すなわち、第１数量及び第２数量はいずれも２に等しいが、本願はこれに限定されず、実際のシーンに応じて設定できる）が取り付けられると仮定する。ドローンＡ及びドローンＢを利用して同一シーンに対して多視点ビデオの収集及び撮影を行い、この場合に、ドローンＡが第１多視点ビデオを収集して制作する過程において、第１多視点ビデオを対応させてカプセル化する第１カプセル化ファイルは以下の通りである。

ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅ＝１；
ｌａｒｇｅ＿ｓｃａｌｅ＿ａｔｌａｓ＿ｆｌａｇ＝１：ｃａｍｅｒａ＿ｃｏｕｎｔ＝４；ｃａｍｅｒａ＿ｃｏｕｎｔ＿ｃｏｎｔａｉｎｅｄ＝２；
ｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｄｅｐｔｈ＝０；ｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｔｅｘｔｕｒｅ＝０；
｛ｃａｍｅｒａ＿ｉｄ＝１；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｘ＝１００；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｙ＝１００；
ｄｅｐｔｈ＿ｄｏｗｎｓａｍｐｌｅ＿ｆａｃｔｏｒ＝１；ｔｅｘｔｕｒｅ＿ｖｅｔｅｘ ＝（０，０）；ｄｅｐｔｈ＿ｖｅｔｅｘ ＝ （０，１００） ｝／／視点１のテクスチャマップ及び視点１の深度マップ
｛ｃａｍｅｒａ＿ｉｄ＝２；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｘ＝１００；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｙ＝１００；
ｄｅｐｔｈ＿ｄｏｗｎｓａｍｐｌｅ＿ｆａｃｔｏｒ＝１；ｔｅｘｔｕｒｅ＿ｖｅｔｅｘ ＝（１００，０）；ｄｅｐｔｈ＿ｖｅｔｅｘ ＝ （１００，１００） ｝／／視点２のテクスチャマップ及び視点２の深度マップ

以上のシステム記述は、図１３の平面フレームの各領域のデータ構成に対応しており、ここでは上下スティッチング方式で例示的な説明を行う。

ドローンＢは第２多視点ビデオを収集して制作する過程において、第２多視点ビデオを対応させてカプセル化する第２カプセル化ファイルは以下の通りである。

ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅ＝１；
ｌａｒｇｅ＿ｓｃａｌｅ＿ａｔｌａｓ＿ｆｌａｇ＝１：ｃａｍｅｒａ＿ｃｏｕｎｔ＝４；ｃａｍｅｒａ＿ｃｏｕｎｔ＿ｃｏｎｔａｉｎｅｄ＝２；
ｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｄｅｐｔｈ＝０；ｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｔｅｘｔｕｒｅ＝０；
｛ｃａｍｅｒａ＿ｉｄ＝３；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｘ＝１００；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｙ＝１００；
ｄｅｐｔｈ＿ｄｏｗｎｓａｍｐｌｅ＿ｆａｃｔｏｒ＝１；ｔｅｘｔｕｒｅ＿ｖｅｔｅｘ ＝（０，０）；ｄｅｐｔｈ＿ｖｅｔｅｘ ＝ （０，１００） ｝／／視点３のテクスチャマップ及び視点３の深度マップ
｛ｃａｍｅｒａ＿ｉｄ＝４；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｘ＝１００；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｙ＝１００；
ｄｅｐｔｈ＿ｄｏｗｎｓａｍｐｌｅ＿ｆａｃｔｏｒ＝１；ｔｅｘｔｕｒｅ＿ｖｅｔｅｘ ＝（１００，０）；ｄｅｐｔｈ＿ｖｅｔｅｘ ＝ （１００，１００） ｝／／視点４のテクスチャマップ及び視点４の深度マップ

以上のシステム記述は、図１４に示す平面フレームの各領域のデータ構成に対応する。

サーバ端末では、サーバ端末が異なるドローンにより撮影された後の第１カプセル化ファイル及び第２カプセル化ファイルを受信した後に、第１カプセル化ファイル及び第２カプセル化ファイルに対してカプセル化解除及び復号を行った後に、すべての深度マップ、及びテクスチャマップを合併し、且つ深度マップをダウンサンプリングした後に、合併多視点ビデオを得ると仮定する。

深度マップの重要性はテクスチャマップよりも低く、ダウンサンプリング後に、データ量を低減させることができる。本願の実施例はこのようなシナリオを示すが、このようなシナリオを限定する。

合併多視点ビデオをカプセル化した後に、以下に示すカプセル化ファイルを獲得できる。

ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅ＝１；
ｌａｒｇｅ＿ｓｃａｌｅ＿ａｔｌａｓ＿ｆｌａｇ＝１：ｃａｍｅｒａ＿ｃｏｕｎｔ＝４；ｃａｍｅｒａ＿ｃｏｕｎｔ＿ｃｏｎｔａｉｎｅｄ＝４；
ｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｄｅｐｔｈ＝０；ｐａｄｄｉｎｇ＿ｓｉｚｅ＿ｔｅｘｔｕｒｅ＝０；
｛ｃａｍｅｒａ＿ｉｄ＝１；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｘ＝１００；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｙ＝１００；
ｄｅｐｔｈ＿ｄｏｗｎｓａｍｐｌｅ＿ｆａｃｔｏｒ＝１；ｔｅｘｔｕｒｅ＿ｖｅｔｅｘ ＝（０，０）；ｄｅｐｔｈ＿ｖｅｔｅｘ ＝ （０，２００） ｝
｛ｃａｍｅｒａ＿ｉｄ＝２；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｘ＝１００；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｙ＝１００；
ｄｅｐｔｈ＿ｄｏｗｎｓａｍｐｌｅ＿ｆａｃｔｏｒ＝１；ｔｅｘｔｕｒｅ＿ｖｅｔｅｘ ＝（１００，０）；ｄｅｐｔｈ＿ｖｅｔｅｘ ＝ （５０，２００） ｝
｛ｃａｍｅｒａ＿ｉｄ＝３；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｘ＝１００；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｙ＝１００；
ｄｅｐｔｈ＿ｄｏｗｎｓａｍｐｌｅ＿ｆａｃｔｏｒ＝１；ｔｅｘｔｕｒｅ＿ｖｅｔｅｘ ＝（０，１００）；ｄｅｐｔｈ＿ｖｅｔｅｘ ＝ （１００，２００） ｝
｛ｃａｍｅｒａ＿ｉｄ＝４；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｘ＝１００；ｃａｍｅｒａ＿ｒｅｓｏｌｕｔｉｏｎ＿ｙ＝１００；
ｄｅｐｔｈ＿ｄｏｗｎｓａｍｐｌｅ＿ｆａｃｔｏｒ＝１；ｔｅｘｔｕｒｅ＿ｖｅｔｅｘ ＝（１００，１００）；ｄｅｐｔｈ＿ｖｅｔｅｘ ＝ （１５０，２００） ｝

以上のシステム記述は、上記図９に示す平面フレームの各領域のデータ構成に対応する。

第１機器のクライアント端末はサーバ端末から送信される合併多視点ビデオのカプセル化ファイルを受信した後に、カプセル化ファイルにおける対応するフィールドを解析することによって、合併多視点ビデオの平面フレームの各領域を異なるカメラのテクスチャマップ、及び深度マップに対応付けることができる。さらに合併多視点ビデオのメディアストリームにおけるカメラパラメータ情報を復号することによって、平面フレームの各領域を３Ｄレンダリング表示領域に復元することができ、それにより合併多視点ビデオを消費することができる。

本願の実施形態が提供するメディアファイルのカプセル化方法は、６ＤｏＦメディアにおける多視点ビデオ応用に対して、ファイルカプセル化において多視点ビデオの深度マップ、及びテクスチャマップの関連情報を示す一種の方法を提案し、それにより多視点ビデオの異なる視点の深度マップ、及びテクスチャマップのカプセル化組み合わせ方式はより柔軟になり、異なる応用シーンをサポートすることができる。上記実施例に記載されるように、いくつかのシーンでは、異なる機器が撮影し、２つのファイルをカプセル化するようになるが、本願の実施例が提供する方法はこれら２つのファイルを関連付け、併せて消費することができる。そうでない場合、上記実施例において、２つのファイルをそれぞれ表示するしかできず、一緒に表示することができない。

本願の実施例が提供するメディアファイルのカプセル化解除方法は任意の電子機器により実行されてもよく、以下の例示的な説明においては、該メディアファイルのカプセル化解除方法が没入型システムの中間ノード、又は第１機器（例えば、プレーヤー端末）に応用されることを例として例示的な説明を行うが、本願はこれに限定されない。

図１５は本願の一実施例によるメディアファイルのカプセル化解除方法のフローチャートを模式的に示す。図１５に示すように、本願の実施例が提供する方法は以下のステップを含んでもよい。

ステップＳ１５１０では、ターゲットメディアコンテンツの当該ターゲットメディアコンテンツに対応する応用シーン下でのメディアストリームのカプセル化ファイルを受信し、上記カプセル化ファイルには第１応用シーンタイプフィールドが含まれ、上記第１応用シーンタイプフィールドは上記メディアストリームに対応する応用シーンを示すことに用いられる。

例示的な実施例において、上記方法は、上記ターゲットメディアコンテンツのターゲット記述ファイルを受信するステップであって、上記ターゲット記述ファイルには第２応用シーンタイプフィールドが含まれ、上記第２応用シーンタイプフィールドは上記メディアストリームに対応する応用シーンを示すことに用いられる、ステップと、上記第２応用シーンタイプフィールドに基づき、上記メディアストリームのカプセル化ファイルのうちターゲットメディアストリームのターゲットカプセル化ファイルを決定するステップと、をさらに含んでもよい。

相応には、ターゲットメディアコンテンツの当該ターゲットメディアコンテンツに対応する応用シーン下でのメディアストリームのカプセル化ファイルを受信するステップは、上記ターゲットカプセル化ファイルを受信し、上記ターゲットカプセル化ファイルにおける第１応用シーンタイプフィールドに基づき、上記ターゲットメディアストリームのターゲット応用シーンを決定するステップを含んでもよい。

ステップＳ１５２０では、上記カプセル化ファイルをカプセル化解除し、上記第１応用シーンタイプフィールドを獲得する。

ステップＳ１５３０では、上記第１応用シーンタイプフィールドに基づき、上記メディアストリームに対応する応用シーンを決定する。

ステップＳ１５４０では、上記メディアストリームに対応する応用シーンに基づき、上記メディアストリームの復号方式及びレンダリング方式のうちの少なくとも一種を決定する。

例示的な実施例において、もし上記第１応用シーンタイプフィールドの数値は上記メディアストリームが大規模アトラス情報の多視点ビデオであることを表す第２値であるなら、上記方法は、上記カプセル化ファイルを解析し、上記メディアストリームに含まれるカメラに対応する視点で収集されたテクスチャマップ及び深度マップと上記大規模アトラス情報における平面フレームとの間のマッピング関係を獲得するステップと、上記メディアストリームを復号し、上記メディアストリームにおけるカメラパラメータを獲得するステップと、上記マッピング関係及び上記カメラパラメータに基づき、３次元空間に上記多視点ビデオを表示するステップと、をさらに含んでもよい。

本願の実施例が提供するメディアファイルのカプセル化解除方法の他のコンテンツは上記の他の実施例におけるメディアファイルのカプセル化方法を参照できる。

本願の実施例が提供するメディアファイルのカプセル化装置は任意の電子機器に設置されてもよく、以下の例示的な説明において、没入型システムのサーバ端末に設置されることを例として例示的な説明を行うが、本願はこれに限定されない。

図１６は本願の一実施例によるメディアファイルのカプセル化装置のブロック図を模式的に示す。図１６に示すように、本願の実施例が提供するメディアファイルのカプセル化装置１６００はメディアストリーム取得ユニット１６１０と、メディアストリームカプセル化ユニット１６２０と、カプセル化ファイル送信ユニット１６３０と、を含んでもよい。

本願の実施例において、メディアストリーム取得ユニット１６１０は、ターゲットメディアコンテンツの当該ターゲットメディアコンテンツに対応する応用シーン下でのメディアストリームを取得することに用いられてもよい。メディアストリームカプセル化ユニット１６２０は、上記メディアストリームをカプセル化し、上記メディアストリームのカプセル化ファイルを生成することに用いられてもよく、上記カプセル化ファイルには第１応用シーンタイプフィールドが含まれ、上記第１応用シーンタイプフィールドは上記メディアストリームに対応する応用シーンを示すことに用いられる。カプセル化ファイル送信ユニット１６４０は、上記カプセル化ファイルを第１機器に送信することにより上記第１機器は上記第１応用シーンタイプフィールドに基づき上記メディアストリームに対応する応用シーンを決定し、且つ上記メディアストリームに対応する応用シーンに基づき上記メディアストリームの復号方式及びレンダリング方式のうちの少なくとも一種を決定することに用いられてもよい。

本願の実施形態が提供するメディアファイルのカプセル化装置は、対応する応用シーン下でのメディアストリームのカプセル化ファイルを生成するときに、カプセル化ファイルにおいて第１応用シーンタイプフィールドを拡張し、該第１応用シーンタイプフィールドによって該メディアストリームに対応する応用シーンを示し、それによってメディアファイルのカプセル化において異なるメディアストリームに対応する応用シーンを区別することを実現する。一方では、該カプセル化ファイルを第１機器に送信するときに、該第１機器は該カプセル化ファイルにおける第１応用シーンタイプフィールドに基づき該メディアストリームの応用シーンを区別でき、それにより該メディアストリームに対応する応用シーンに基づき該メディアストリームに対してどの復号方式又はレンダリング方式を使用するかを決定でき、第１機器の演算能力及びリソースを節約できる。他方では、カプセル化段階でメディアストリームの応用シーンを決定できるため、第１機器がメディアストリームの復号能力を備えないとしても、該メディアストリームに対応する応用シーンを決定でき、区別できるために該メディアストリームを復号した後まで待つ必要がない。

例示的な実施例において、メディアストリームカプセル化ユニット１６２０は第１応用シーンタイプフィールド追加ユニットと、第１応用シーンタイプフィールド数値決定ユニットと、を含んでもよく、第１応用シーンタイプフィールド追加ユニットは、ターゲットメディアファイルフォーマットデータボックスのボリュメトリックビジュアルメディアヘッダーデータボックスにおいて上記第１応用シーンタイプフィールドを追加することに用いられてもよく、第１応用シーンタイプフィールド数値決定ユニットは、上記メディアストリームに対応する応用シーンに基づき、上記第１応用シーンタイプフィールドの数値を決定することに用いられてもよい。

例示的な実施例において、上記第１応用シーンタイプフィールドの数値は、上記メディアストリームが非大規模アトラス情報の多視点ビデオであることを表す第１値と、上記メディアストリームが大規模アトラス情報の多視点ビデオであることを表す第２値と、上記メディアストリームが従来のビデオ符号化方式に基づいて圧縮される点群メディアであることを表す第３値と、上記メディアストリームが幾何学的特徴に基づいて圧縮される点群メディアであることを表す第４値とのうちのいずれか１つを含んでもよい。

例示的な実施例において、上記第１応用シーンタイプフィールドの数値が上記第２値に等しい場合には、メディアファイルのカプセル化装置１６００は、シングルトラック大規模アトラス識別子追加ユニットと、シングルトラックカメラ視点識別子追加ユニットと、シングルトラックテクスチャ深度マップ解像度追加ユニットと、をさらに含んでもよい。シングルトラック大規模アトラス識別子追加ユニットは、もし上記メディアストリームをシングルトラックに応じてカプセル化するなら、上記ターゲットメディアファイルフォーマットデータボックスのビットストリームサンプルエントリにおいて大規模アトラス識別子を追加することに用いられてもよい。シングルトラックカメラ視点識別子追加ユニットは、もし上記大規模アトラス識別子が上記メディアストリームが大規模アトラス情報の多視点ビデオであることを示すなら、上記ビットストリームサンプルエントリにおいて、上記メディアストリームを収集するカメラの数量識別子、及び上記メディアストリームの現在のファイルに含まれるカメラに対応する視点数識別子を追加することに用いられてもよい。シングルトラックテクスチャ深度マップ解像度追加ユニットは、上記ビットストリームサンプルエントリにおいて、上記現在のファイルに含まれるカメラに対応する視点で収集されたテクスチャマップと深度マップとの解像度を追加することに用いられてもよい。

例示的な実施例において、メディアファイルのカプセル化装置１６００は、シングルトラックダウンサンプリング倍数因子追加ユニット、シングルトラックテクスチャマップオフセット量追加ユニット、シングルトラック深度マップオフセット量追加ユニット、及びシングルトラックパディング幅追加ユニットのうちの少なくとも１つをさらに含んでもよい。シングルトラックダウンサンプリング倍数因子追加ユニットは、上記ビットストリームサンプルエントリにおいて、上記現在のファイルに含まれるカメラに対応する視点で収集された深度マップのダウンサンプリング倍数因子を追加することに用いられてもよい。シングルトラックテクスチャマップオフセット量追加ユニットは、上記ビットストリームサンプルエントリにおいて、上記現在のファイルに含まれるカメラに対応する視点で収集されたテクスチャマップの左上頂点の上記大規模アトラス情報における平面フレームの原点に対するオフセット量を追加することに用いられてもよい。シングルトラック深度マップオフセット量追加ユニットは、上記ビットストリームサンプルエントリにおいて、上記現在のファイルに含まれるカメラに対応する視点で収集された深度マップの左上頂点の上記大規模アトラス情報における平面フレームの原点に対するオフセット量を追加することに用いられてもよい。シングルトラックパディング幅追加ユニットは、上記ビットストリームサンプルエントリにおいて、上記現在のファイルに含まれるカメラに対応する視点で収集されたテクスチャマップと深度マップとのパディング幅を追加することに用いられてもよい。

例示的な実施例において、上記第１応用シーンタイプフィールドの数値が上記第２値に等しい場合には、メディアファイルのカプセル化装置１６００は、マルチトラック大規模アトラス識別子追加ユニットと、マルチトラックカメラ視点識別子追加ユニットと、マルチトラックテクスチャ深度マップ解像度追加ユニットと、をさらに含んでもよい。マルチトラック大規模アトラス識別子追加ユニットは、もし上記メディアストリームをマルチトラックに応じてカプセル化するなら、上記ターゲットメディアファイルフォーマットデータボックスのサンプルエントリにおいて大規模アトラス識別子を追加することに用いられてもよい。マルチトラックカメラ視点識別子追加ユニットは、もし上記大規模アトラス識別子が上記メディアストリームが大規模アトラス情報の多視点ビデオであることを示すなら、上記サンプルエントリにおいて、上記メディアストリームを収集するカメラの数量識別子、及び上記メディアストリームの現在のファイルに含まれるカメラに対応する視点数識別子を追加することに用いられてもよい。マルチトラックテクスチャ深度マップ解像度追加ユニットは、上記サンプルエントリにおいて、上記現在のファイルに含まれるカメラに対応する視点で収集されたテクスチャマップと深度マップとの解像度を追加することに用いられてもよい。

例示的な実施例において、メディアファイルのカプセル化装置１６００は、マルチトラックダウンサンプリング倍数因子追加ユニット、マルチトラックテクスチャマップオフセット量追加ユニット、マルチトラック深度マップオフセット量追加ユニット、及びマルチトラックパディング幅追加ユニットのうちの少なくとも１つをさらに含んでもよい。マルチトラックダウンサンプリング倍数因子追加ユニットは、上記サンプルエントリにおいて、上記現在のファイルに含まれるカメラに対応する視点で収集された深度マップのダウンサンプリング倍数因子を追加することに用いられてもよい。マルチトラックテクスチャマップオフセット量追加ユニットは、上記サンプルエントリにおいて、上記現在のファイルに含まれるカメラに対応する視点で収集されたテクスチャマップの左上頂点の上記大規模アトラス情報における平面フレームの原点に対するオフセット量を追加することに用いられてもよい。マルチトラック深度マップオフセット量追加ユニットは、上記サンプルエントリにおいて、上記現在のファイルに含まれるカメラに対応する視点で収集された深度マップの左上頂点の上記大規模アトラス情報における平面フレームの原点に対するオフセット量を追加することに用いられてもよい。マルチトラックパディング幅追加ユニットは、上記サンプルエントリにおいて、上記現在のファイルに含まれるカメラに対応する視点で収集されたテクスチャマップと深度マップとのパディング幅を追加することに用いられてもよい。

例示的な実施例において、メディアファイルのカプセル化装置１６００は、ターゲット記述ファイル生成ユニットと、ターゲット記述ファイル送信ユニットと、をさらに含んでもよい。ターゲット記述ファイル生成ユニットは、上記ターゲットメディアコンテンツのターゲット記述ファイルを生成することに用いられてもよい。上記ターゲット記述ファイルには第２応用シーンタイプフィールドが含まれ、上記第２応用シーンタイプフィールドは上記メディアストリームに対応する応用シーンを示すことに用いられる。ターゲット記述ファイル送信ユニットは、上記ターゲット記述ファイルを上記第１機器に送信することにより上記第１機器は上記第２応用シーンタイプフィールドに基づき、上記メディアストリームのカプセル化ファイルのうちターゲットメディアストリームに対応するターゲットカプセル化ファイルを決定することに用いられてもよい。ここで、カプセル化ファイル送信ユニット１６４０はターゲットカプセル化ファイル送信ユニットを含んでもよく、ターゲットカプセル化ファイル送信ユニットは、上記ターゲットカプセル化ファイルを上記第１機器に送信することにより上記第１機器は上記ターゲットカプセル化ファイルにおける第１応用シーンタイプフィールドに基づき上記ターゲットメディアストリームに対応するターゲット応用シーンを決定することに用いられてもよい。

例示的な実施例において、ターゲット記述ファイル生成ユニットは、第２応用シーンタイプフィールド追加ユニットと、第２応用シーンタイプフィールド数値決定ユニットと、を含んでもよい。第２応用シーンタイプフィールド追加ユニットは、上記ターゲットメディアコンテンツのハイパーテキスト転送プロトコルに基づく動的自己適応ストリーミングメディア伝送のターゲット記述ファイルにおいて上記第２応用シーンタイプフィールドを追加することに用いられてもよい。第２応用シーンタイプフィールド数値決定ユニットは、上記メディアストリームに対応する応用シーンに基づき、上記第２応用シーンタイプフィールドの数値を決定することに用いられてもよい。

例示的な実施例において、メディアストリーム取得ユニット１６２０は、カプセル化ファイル受信ユニットと、カプセル化ファイルカプセル化解除ユニットと、多視点ビデオ復号ユニットと、多視点ビデオ合併ユニットと、を含んでもよい。カプセル化ファイル受信ユニットは、第２機器が送信する第１多視点ビデオの第１カプセル化ファイルと第３機器が送信する第２多視点ビデオの第２カプセル化ファイルとを受信することに用いられてもよい。カプセル化ファイルカプセル化解除ユニットは、上記第１カプセル化ファイル及び上記第２カプセル化ファイルをそれぞれカプセル化解除し、上記第１多視点ビデオ及び上記第２多視点ビデオを獲得することに用いられてもよい。多視点ビデオ復号ユニットは、上記第１多視点ビデオ及び上記第２多視点ビデオをそれぞれ復号し、上記第１多視点ビデオにおける第１深度マップ及び第１テクスチャマップ、並びに上記第２多視点ビデオにおける第２深度マップ及び第２テクスチャマップを獲得することに用いられてもよい。多視点ビデオ合併ユニットは、上記第１深度マップ、上記第２深度マップ、上記第１テクスチャマップ及び上記第２テクスチャマップに基づき、合併多視点ビデオを獲得することに用いられてもよい。

例示的な実施例において、上記第２機器において第１数量のカメラが取り付けられてもよく、上記第３機器において第２数量のカメラが取り付けられてもよい。上記第２機器及び上記第３機器はそれぞれ各自のカメラを利用して同一シーンに対して多視点ビデオの収集及び撮影を行い、上記第１多視点ビデオ及び上記第２多視点ビデオを獲得することができる。ここで、上記第１カプセル化ファイル及び上記第２カプセル化ファイルにはいずれも上記第１応用シーンタイプフィールドが含まれてもよく、且つ上記第１カプセル化ファイル及び上記第２カプセル化ファイルにおける第１応用シーンタイプフィールドの数値はそれぞれ、上記第１多視点ビデオ及び上記第２多視点ビデオが大規模アトラス情報の多視点ビデオであることを表すことに用いられる第２値であってもよい。

例示的な実施例において、上記メディアストリームは６自由度メディアストリーム、及び制限された６自由度メディアストリームを含んでもよい。

本願の実施例が提供するメディアファイルのカプセル化装置の各ユニットの具体的な実現は上記メディアファイルのカプセル化方法のコンテンツを参照できるため、ここでは重複して説明はしない。

本願の実施例が提供するメディアファイルのカプセル化解除装置は任意の電子機器に設置されてもよく、以下の例示的な説明において、没入型システムの中間ノード又は第１機器（例えば、プレーヤー端末）に設置されることを例として例示的な説明を行うが、本願はこれに限定されない。

図１７は本願の一実施例によるメディアファイルのカプセル化解除装置のブロック図を模式的に示す。図１７に示すように、本願の実施例が提供するメディアファイルのカプセル化解除装置１７００は、カプセル化ファイル受信ユニット１７１０と、ファイルカプセル化解除ユニット１７２０と、応用シーン獲得ユニット１７３０と、復号レンダリング決定ユニット１７４０と、を含んでもよい。

本願の実施例において、カプセル化ファイル受信ユニット１７１０は、ターゲットメディアコンテンツの当該ターゲットメディアコンテンツに対応する応用シーン下でのメディアストリームのカプセル化ファイルを受信することに用いられてもよい。上記カプセル化ファイルには第１応用シーンタイプフィールドが含まれ、上記第１応用シーンタイプフィールドは上記メディアストリームに対応する応用シーンを示すことに用いられる。ファイルカプセル化解除ユニット１７２０は、上記カプセル化ファイルをカプセル化解除し、上記第１応用シーンタイプフィールドを獲得することに用いられてもよい。応用シーン獲得ユニット１７３０は、上記第１応用シーンタイプフィールドに基づき、上記メディアストリームに対応する応用シーンを決定することに用いられてもよい。復号レンダリング決定ユニット１７４０は、上記メディアストリームに対応する応用シーンに基づき、上記メディアストリームの復号方式及びレンダリング方式のうちの少なくとも一種を決定することに用いられてもよい。

例示的な実施例において、上記第１応用シーンタイプフィールドの数値が上記メディアストリームが大規模アトラス情報の多視点ビデオであることを表す第２値である場合には、メディアファイルのカプセル化解除装置１７００は、カプセル化ファイル解析ユニットと、メディアストリーム復号ユニットと、多視点ビデオ表示ユニットと、をさらに含んでもよい。カプセル化ファイル解析ユニットは、上記カプセル化ファイルを解析し、上記メディアストリームに含まれるカメラに対応する視点で収集されたテクスチャマップ及び深度マップと上記大規模アトラス情報における平面フレームとの間のマッピング関係を獲得することに用いられてもよい。メディアストリーム復号ユニットは、上記メディアストリームを復号し、上記メディアストリームにおけるカメラパラメータを獲得することに用いられてもよい。多視点ビデオ表示ユニットは、上記マッピング関係及び上記カメラパラメータに基づき、３次元空間に上記多視点ビデオを表示することに用いられてもよい。

例示的な実施例において、メディアファイルのカプセル化解除装置１７００は、ターゲット記述ファイル受信ユニットと、ターゲットカプセル化ファイル決定ユニットと、をさらに含んでもよい。ターゲット記述ファイル受信ユニットは、上記ターゲットメディアコンテンツのターゲット記述ファイルを受信することに用いられてもよく、上記ターゲット記述ファイルには第２応用シーンタイプフィールドが含まれ、上記第２応用シーンタイプフィールドは上記メディアストリームに対応する応用シーンを示すことに用いられ、ターゲットカプセル化ファイル決定ユニットは、上記第２応用シーンタイプフィールドに基づき、上記メディアストリームのカプセル化ファイルのうちターゲットメディアストリームのターゲットカプセル化ファイルを決定することに用いられてもよい。ここで、カプセル化ファイル受信ユニット１７１０はターゲット応用シーン決定ユニットを含んでもよく、ターゲット応用シーン決定ユニットは、上記ターゲットカプセル化ファイルを受信し、上記ターゲットカプセル化ファイルにおける第１応用シーンタイプフィールドに基づき、上記ターゲットメディアストリームのターゲット応用シーンを決定することに用いられてもよい。

本願の実施例が提供するメディアファイルのカプセル化解除装置の各ユニットの具体的な実現は上記メディアファイルのカプセル化解除方法のコンテンツを参照できるため、ここでは重複して説明はしない。

注意すべき点として、以上の詳細な記述では動作を実行することに用いられる機器の若干のユニットが言及されたが、このような分割は強制的なものではない。実際には、本願の実施形態に基づき、以上記述された２つ又はより多くのユニットの特徴及び機能は１つのユニットにおいて具体化されてもよい。逆に、以上記述された１つのユニットの特徴及び機能はさらに複数のユニットに分割して具体化されてもよい。

本願の実施例はコンピュータ可読記憶媒体を提供し、それにおいてコンピュータプログラムが記憶されており、上記プログラムがプロセッサにより実行されるときに、上記実施例における上記メディアファイルのカプセル化方法を実現する。

本願の実施例はコンピュータ可読記憶媒体を提供し、それにおいてコンピュータプログラムが記憶されており、上記プログラムがプロセッサにより実行されるときに、上記実施例における上記メディアファイルのカプセル化解除方法を実現する。

本願の実施例は電子機器を提供し、少なくとも１つのプロセッサと、少なくとも１つのプログラムを記憶するように配置される記憶装置と、を含み、上記少なくとも１つのプログラムが上記少なくとも１つのプロセッサにより実行されるときに、上記少なくとも１つのプロセッサに上記実施例における上記メディアファイルのカプセル化方法を実現させる。

本願の実施例は電子機器を提供し、少なくとも１つのプロセッサと、少なくとも１つのプログラムを記憶するように配置される記憶装置と、を含み、上記少なくとも１つのプログラムが上記少なくとも１つのプロセッサにより実行されるときに、上記少なくとも１つのプロセッサに上記実施例における上記メディアファイルのカプセル化解除方法を実現させる。

図１８は本願の実施例を実現するために適する電子機器の構造模式図を示す。

説明する必要がある点として、図１８に示す電子機器１８００は単に一例であり、本願の実施例の機能及び使用範囲に何らの制限をもたらすものではない。

図１８に示すように、電子機器１８００は中央処理ユニット（ＣＰＵ、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１８０１を含み、それは読み出し専用メモリ（ＲＯＭ、Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）１８０２に記憶されるプログラム又は記憶部分１８０８からランダムアクセスメモリ（ＲＡＭ、Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１８０３にロードされるプログラムに基づき、各種の適切な動作及び処理を実行することができる。ＲＡＭ １８０３には、システム操作に必要な各種のプログラム及びデータがさらに記憶されている。ＣＰＵ １８０１、ＲＯＭ １８０２及びＲＡＭ １８０３はバス１８０４によって互いに連結される。入力／出力（ｉｎｐｕｔ／ｏｕｔｐｕｔ、Ｉ／Ｏ）インタフェース１８０５もバス１８０４に接続される。

キーボード及びマウスなどを含む入力部分１８０６と、例えばカソードレイチューブ（ＣＲＴ、Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）、液晶ディスプレイ（ＬＣＤ、Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）など及びスピーカなどを含む出力部分１８０７と、ハードディスクなどを含む記憶部分１８０８と、例えばＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ、ローカルエリアネットワーク）カード、及びモデムなどのネットワークインタフェースカードを含む通信部分１８０９とは、Ｉ／Ｏインタフェース１８０５に接続される。通信部分１８０９は例えばインターネットのようなネットワークを経由して通信処理を実行する。ドライバ１８１０も必要に応じてＩ／Ｏインタフェース１８０５に接続される。例えば磁気ディスク、光ディスク、光磁気ディスク、及び半導体メモリなどのような取り外し可能な媒体１８１１は、必要に応じてドライバ１８１０に取り付けられ、それによりそれから読み出したコンピュータプログラムは必要に応じて記憶部分１８０８にインストールされる。

特に、本願の実施例によれば、以下でフローチャートを参照して記述される過程はコンピュータソフトウェアプログラムとして実現されてもよい。例えば、本願の実施例は一種のコンピュータプログラム製品を含み、それはコンピュータ可読記憶媒体に載せられるコンピュータプログラムを含み、該コンピュータプログラムはフローチャートに示す方法を実行することに用いられるプログラムコードを含む。このような実施例において、該コンピュータプログラムは通信部分１８０９によってネットワークからダウンロード及びインストールされ、及び／又は取り外し可能な媒体１８１１からインストールされるようにしてもよい。該コンピュータプログラムが中央処理ユニット（ＣＰＵ）１８０１により実行されるときに、本願の方法及び／又は装置に限定された各種の機能を実行する。

説明する必要がある点として、本願に示すコンピュータ可読記憶媒体はコンピュータ可読信号媒体又はコンピュータ可読記憶媒体又は上記両者の任意の組み合わせであってもよい。コンピュータ可読記憶媒体は、例えば、電気、磁気、光、電磁、赤外線、又は半導体のシステム、装置又はデバイス、又は任意の以上の組み合わせであってもよいが、これらに限定されない。コンピュータ可読記憶媒体のさらに具体的な例は、少なくとも１つの導線を有する電気的接続、ポータブルコンピュータ磁気ディスク、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能プログラマブル読み出し専用メモリ（ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ、消去可能プログラマブル読み出し専用メモリ）又はフラッシュメモリ）、光ファイバー、ポータブルコンパクトディスク読み出し専用メモリ（ＣＤ－ＲＯＭ）、光記憶デバイス、磁気記憶デバイス、又は上記任意の適切な組み合わせを含んでもよいが、これらに限定されない。本願では、コンピュータ可読記憶媒体はプログラムを含む又は記憶する何らの有形媒体であってもよく、該プログラムは命令実行システム、装置又はデバイスに使用される又はそれと併せて使用されるようにしてもよい。本願では、コンピュータ可読信号媒体はベースバンドで又は搬送波の一部として伝播されるデータ信号を含んでもよく、ここでコンピュータ可読プログラムコードが載せられている。このように伝播されるデータ信号は複数種の形式を採用でき、電磁信号、光信号又は上記任意の適切な組み合わせを含むが、これらに限定されない。コンピュータ可読信号媒体はさらにコンピュータ可読記憶媒体を除く何らのコンピュータ可読記憶媒体であってもよく、該コンピュータ可読記憶媒体は、命令実行システム、装置又はデバイスに使用される又はそれと併せて使用されることに用いられるプログラムを送信、伝播又は伝送することができる。コンピュータ可読記憶媒体に含まれるプログラムコードは何らの適切な媒体で伝送されてもよく、無線、ワイヤ、光ケーブル、ＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ、無線周波数）など、又は上記任意の適切な組み合わせを含むが、これらに限定されない。

図面におけるフローチャート及びブロック図は、本願の各種の実施例による方法、装置及びコンピュータプログラム製品の実現可能な体系アーキテクチャ、機能及び操作を図示した。この点では、フローチャート又はブロック図における各ブロックは１つのモジュール、プログラムセグメント、又はコードの一部を表すことができ、上記モジュール、プログラムセグメント、又はコードの一部は所定のロジック機能を実現することに用いられる少なくとも１つの実行可能命令を含む。さらに注意すべき点として、いくつかの代替としての実施においては、ブロックにおいてマークされた機能は図面にマークされた順序とは異なる順序で発生してもよい。例えば、連続して示される２つのブロックは実際にほぼ並行に実行されてもよく、場合によってそれらは逆の順序で実行されてもよく、これは関する機能に依存して決められる。さらに注意する必要がある点として、ブロック図又はフローチャートにおける各ブロック、及びブロック図又はフローチャートにおけるブロックの組み合わせは、所定の機能又は操作を実行する専用のハードウェアに基づくシステムで実現されてもよく、又は専用ハードウェアとコンピュータ命令との組み合わせで実現されてもよい。

本願の実施例の記述において関するユニットはソフトウェアの方式によって実現されてもよく、ハードウェアの方式によって実現されてもよく、記述されたユニットはプロセッサ内に設置されてもよい。ここで、ある場合には、これらのユニットの名称は該ユニット自体に対する限定を構成しない。

別の態様として、本願はさらにコンピュータ可読記憶媒体を提供し、該コンピュータ可読記憶媒体は上記実施例で記述された電子機器に含まれてもよく、該電子機器内に組み立てられずに単独で存在してもよい。上記コンピュータ可読記憶媒体に１つ又は複数のプログラムが載せられており、上記１つ又は複数のプログラムが１つの該電子機器により実行されるときに、該電子機器に下記実施例に記載の方法を実現させる。例えば、上記電子機器は図４又は図５又は図６又は図１０又は図１１又は図１２又は図１５に示す各ステップを実現できる。

以上の実施形態の記述によって当業者が容易に理解できるように、ここで記述される例示的な実施形態はソフトウェアによって実現されてもよく、ソフトウェアと必要なハードウェアとを併せる方式によって実現されてもよい。従って、本願の実施形態による技術的手段はソフトウェア製品の形式で具現化でき、該ソフトウェア製品は１つの不揮発性記憶媒体（ＣＤ－ＲＯＭ、Ｕディスク、モバイルハードディスクなどであってもよい）又はネットワークにおいて記憶されてもよく、若干の命令を含み、それにより１台の計算機器（パーソナルコンピュータ、サーバ、タッチ制御端末、又はネットワーク機器などであってもよい）に本願の実施形態による方法を実行させる。

当業者は明細書を考慮し及びここで出願された発明を実施した後に、本願の他の実施手段を容易に想到できる。本願は本願の何らの変形、用途又は適応的な変化をカバーすることを意図し、これらの変形、用途又は適応的な変化は本願の一般的な原理に従い、本願により出願されていない本技術分野における公知の常識又は慣用の技術手段を含む。明細書及び実施例は単に例示的なものとしてみなされ、本願の実際の範囲及び精神は以下の特許請求の範囲により定められる。

理解されるように、本願は以上で既に記述され且つ図面に示した精確な構造に限定されず、且つその範囲を逸脱せずに各種の変更や変化を行うことができる。本願の範囲は添付する特許請求の範囲のみにより制限される。

１６００ カプセル化装置
１６１０ メディアストリーム取得ユニット
１６２０ メディアストリームカプセル化ユニット
１６３０ カプセル化ファイル送信ユニット
１６４０ カプセル化ファイル送信ユニット
１７００ カプセル化解除装置
１７１０ カプセル化ファイル受信ユニット
１７２０ ファイルカプセル化解除ユニット
１７３０ 応用シーン獲得ユニット
１７４０ 復号レンダリング決定ユニット
１８００ 電子機器
１８０１ 中央処理ユニット
１８０２ 専用メモリ
１８０３ ランダムアクセスメモリ
１８０４ バス
１８０５ Ｉ／Ｏインタフェース
１８０６ 入力部分
１８０７ 出力部分
１８０８ 記憶部分
１８０９ 通信部分
１８１０ ドライバ
１８１１ 媒体

Claims (17)

1. 電子機器により実行される、メディアファイルのカプセル化方法であって、
   ターゲットメディアコンテンツの当該ターゲットメディアコンテンツに対応する応用シーン下でのメディアストリームを取得するステップと、
   ターゲットメディアファイルフォーマットデータボックスのボリュメトリックビジュアルメディアヘッダーデータボックスに、前記メディアストリームに対応する応用シーンのタイプを示す第１応用シーンタイプフィールドを追加し、前記メディアストリームに対応する応用シーンに基づき前記第１応用シーンタイプフィールドの数値を決定することで前記メディアストリームをカプセル化し、前記メディアストリームのカプセル化ファイルを生成するステップと、
   前記カプセル化ファイルを第１機器に送信することにより前記第１機器は前記第１応用シーンタイプフィールドに基づき前記メディアストリームに対応する応用シーンを決定し、且つ前記メディアストリームに対応する応用シーンに基づき前記メディアストリームの復号方式及びレンダリング方式のうちの少なくとも一種を決定するステップと、を含む、メディアファイルのカプセル化方法。
2. 前記第１応用シーンタイプフィールドの数値は、
   前記メディアストリームが非大規模アトラス情報の多視点ビデオであることを表す第１値と、
   前記メディアストリームが大規模アトラス情報の多視点ビデオであることを表す第２値と、
   前記メディアストリームが従来のビデオ符号化方式に基づいて圧縮される点群メディアであることを表す第３値と、
   前記メディアストリームが幾何学的特徴に基づいて圧縮される点群メディアであることを表す第４値と、
   のうちのいずれか１つを含む、請求項１に記載のメディアファイルのカプセル化方法。
3. 前記第１応用シーンタイプフィールドの数値が前記第２値に等しい場合には、前記方法は、
   もし前記メディアストリームをシングルトラックに応じてカプセル化するなら、前記ターゲットメディアファイルフォーマットデータボックスのビットストリームサンプルエントリにおいて大規模アトラス識別子を追加するステップと、
   もし前記大規模アトラス識別子が前記メディアストリームが大規模アトラス情報の多視点ビデオであることを示すなら、前記ビットストリームサンプルエントリにおいて、前記メディアストリームを収集するカメラの数量識別子、及び前記メディアストリームの現在のファイルに含まれるカメラに対応する視点数識別子を追加するステップと、
   前記ビットストリームサンプルエントリにおいて、前記現在のファイルに含まれるカメラに対応する視点で収集されたテクスチャマップと深度マップとの解像度を追加するステップと、をさらに含む、請求項２に記載のメディアファイルのカプセル化方法。
4. 前記方法は、
   前記ビットストリームサンプルエントリにおいて、前記現在のファイルに含まれるカメラに対応する視点で収集された深度マップのダウンサンプリング倍数因子を追加する方式と、
   前記ビットストリームサンプルエントリにおいて、前記現在のファイルに含まれるカメラに対応する視点で収集されたテクスチャマップの左上頂点の前記大規模アトラス情報における平面フレームの原点に対するオフセット量を追加する方式と、
   前記ビットストリームサンプルエントリにおいて、前記現在のファイルに含まれるカメラに対応する視点で収集された深度マップの左上頂点の前記大規模アトラス情報における平面フレームの原点に対するオフセット量を追加する方式と、
   前記ビットストリームサンプルエントリにおいて、前記現在のファイルに含まれるカメラに対応する視点で収集されたテクスチャマップと深度マップとのパディング幅を追加する方式と、
   のうちの少なくとも一種の情報追加方式をさらに含む、請求項３に記載のメディアファイルのカプセル化方法。
5. 前記第１応用シーンタイプフィールドの数値が前記第２値に等しい場合には、前記方法は、
   もし前記メディアストリームをマルチトラックに応じてカプセル化するなら、前記ターゲットメディアファイルフォーマットデータボックスのサンプルエントリにおいて大規模アトラス識別子を追加するステップと、
   もし前記大規模アトラス識別子が前記メディアストリームが大規模アトラス情報の多視点ビデオであることを示すなら、前記サンプルエントリにおいて、前記メディアストリームを収集するカメラの数量識別子、及び前記メディアストリームの現在のファイルに含まれるカメラに対応する視点数識別子を追加するステップと、
   前記サンプルエントリにおいて、前記現在のファイルに含まれるカメラに対応する視点で収集されたテクスチャマップと深度マップとの解像度を追加するステップと、をさらに含む、請求項２に記載のメディアファイルのカプセル化方法。
6. 前記方法は、
   前記ターゲットメディアコンテンツのターゲット記述ファイルを生成するステップであって、前記ターゲット記述ファイルには前記メディアストリームに対応する応用シーンのタイプを示す第２応用シーンタイプフィールドが含まれる、ステップと、
   前記ターゲット記述ファイルを前記第１機器に送信することにより前記第１機器は前記第２応用シーンタイプフィールドに基づき、前記メディアストリームのカプセル化ファイルのうちターゲットメディアストリームに対応するターゲットカプセル化ファイルを決定するステップと、をさらに含み、
   前記カプセル化ファイルを第１機器に送信することにより前記第１機器は前記第１応用シーンタイプフィールドに基づき前記メディアストリームに対応する応用シーンを決定することは、
   前記ターゲットカプセル化ファイルを前記第１機器に送信することにより前記第１機器は前記ターゲットカプセル化ファイルにおける第１応用シーンタイプフィールドに基づき前記ターゲットメディアストリームに対応するターゲット応用シーンを決定するステップを含む、請求項１に記載のメディアファイルのカプセル化方法。
7. 前記ターゲットメディアコンテンツのターゲット記述ファイルを生成する前記ステップは、
   前記ターゲットメディアコンテンツのハイパーテキスト転送プロトコルに基づく動的自己適応ストリーミングメディア伝送のターゲット記述ファイルにおいて前記第２応用シーンタイプフィールドを追加するステップと、
   前記メディアストリームに対応する応用シーンに基づき、前記第２応用シーンタイプフィールドの数値を決定するステップと、を含む、請求項６に記載のメディアファイルのカプセル化方法。
8. ターゲットメディアコンテンツの当該ターゲットメディアコンテンツに対応する応用シーン下でのメディアストリームを取得する前記ステップは、
   第２機器が送信する第１多視点ビデオの第１カプセル化ファイルと第３機器が送信する第２多視点ビデオの第２カプセル化ファイルとを受信するステップと、
   前記第１カプセル化ファイル及び前記第２カプセル化ファイルをそれぞれカプセル化解除し、前記第１多視点ビデオ及び前記第２多視点ビデオを獲得するステップと、
   前記第１多視点ビデオ及び前記第２多視点ビデオをそれぞれ復号し、前記第１多視点ビデオにおける第１深度マップ及び第１テクスチャマップ、並びに前記第２多視点ビデオにおける第２深度マップ及び第２テクスチャマップを獲得するステップと、
   前記第１深度マップ、前記第２深度マップ、前記第１テクスチャマップ及び前記第２テクスチャマップに基づき、合併多視点ビデオを獲得するステップと、を含む、請求項１に記載のメディアファイルのカプセル化方法。
9. 前記第２機器において第１数量のカメラが取り付けられ、前記第３機器において第２数量のカメラが取り付けられ、前記第２機器及び前記第３機器はそれぞれ各自のカメラを利用して同一シーンに対して多視点ビデオの収集及び撮影を行い、前記第１多視点ビデオ及び前記第２多視点ビデオを獲得し、
   前記第１カプセル化ファイル及び前記第２カプセル化ファイルにはいずれも前記第１応用シーンタイプフィールドが含まれ、且つ前記第１カプセル化ファイル及び前記第２カプセル化ファイルにおける第１応用シーンタイプフィールドの数値はそれぞれ、前記第１多視点ビデオ及び前記第２多視点ビデオが大規模アトラス情報の多視点ビデオであることを表すことに用いられる第２値である、請求項８に記載のメディアファイルのカプセル化方法。
10. 前記メディアストリームは６自由度メディアストリーム、及び制限された６自由度メディアストリームを含む、請求項１～９のいずれか一項に記載のメディアファイルのカプセル化方法。
11. 電子機器により実行される、メディアファイルのカプセル化解除方法であって、
    ターゲットメディアコンテンツの当該ターゲットメディアコンテンツに対応する応用シーン下でのメディアストリームのカプセル化ファイルを受信するステップであって、前記カプセル化ファイルのターゲットメディアファイルフォーマットデータボックスのボリュメトリックビジュアルメディアヘッダーデータボックスには前記メディアストリームに対応する応用シーンのタイプを示す第１応用シーンタイプフィールドが含まれる、ステップと、
    前記カプセル化ファイルをカプセル化解除し、前記第１応用シーンタイプフィールドを獲得するステップと、
    前記第１応用シーンタイプフィールドに基づき、前記メディアストリームに対応する応用シーンを決定するステップと、
    前記メディアストリームに対応する応用シーンに基づき、前記メディアストリームの復号方式及びレンダリング方式のうちの少なくとも一種を決定するステップと、を含む、メディアファイルのカプセル化解除方法。
12. 前記第１応用シーンタイプフィールドの数値は前記メディアストリームが大規模アトラス情報の多視点ビデオであることを表すことに用いられる第２値である場合には、前記方法は、
    前記カプセル化ファイルを解析し、前記メディアストリームに含まれるカメラに対応する視点で収集されたテクスチャマップ及び深度マップと前記大規模アトラス情報における平面フレームとの間のマッピング関係を獲得するステップと、
    前記メディアストリームを復号し、前記メディアストリームにおけるカメラパラメータを獲得するステップと、
    前記マッピング関係及び前記カメラパラメータに基づき、３次元空間に前記多視点ビデオを表示するステップと、をさらに含む、請求項１１に記載のメディアファイルのカプセル化解除方法。
13. 前記方法は、
    前記ターゲットメディアコンテンツのターゲット記述ファイルを受信するステップであって、前記ターゲット記述ファイルには前記メディアストリームに対応する応用シーンのタイプを示す第２応用シーンタイプフィールドが含まれる、ステップと、
    前記第２応用シーンタイプフィールドに基づき、前記メディアストリームのカプセル化ファイルのうちターゲットメディアストリームのターゲットカプセル化ファイルを決定するステップと、をさらに含み、
    ターゲットメディアコンテンツの当該ターゲットメディアコンテンツに対応する応用シーン下でのメディアストリームのカプセル化ファイルを受信する前記ステップは、
    前記ターゲットカプセル化ファイルを受信し、前記ターゲットカプセル化ファイルにおける第１応用シーンタイプフィールドに基づき、前記ターゲットメディアストリームのターゲット応用シーンを決定するステップを含む、請求項１１または１２に記載のメディアファイルのカプセル化解除方法。
14. メディアファイルのカプセル化装置であって、
    ターゲットメディアコンテンツの当該ターゲットメディアコンテンツに対応する応用シーン下でのメディアストリームを取得することに用いられるメディアストリーム取得ユニットと、
    ターゲットメディアファイルフォーマットデータボックスのボリュメトリックビジュアルメディアヘッダーデータボックスに、前記メディアストリームに対応する応用シーンのタイプを示す第１応用シーンタイプフィールドを追加し、前記メディアストリームに対応する応用シーンに基づき前記第１応用シーンタイプフィールドの数値を決定することで前記メディアストリームをカプセル化し、前記メディアストリームのカプセル化ファイルを生成することに用いられるメディアストリームカプセル化ユニットであって、前記カプセル化ファイルには前記メディアストリームに対応する応用シーンのタイプを示す第１応用シーンタイプフィールドが含まれる、メディアストリームカプセル化ユニットと、
    前記カプセル化ファイルを第１機器に送信することにより前記第１機器は前記第１応用シーンタイプフィールドに基づき前記メディアストリームに対応する応用シーンを決定し、且つ前記メディアストリームに対応する応用シーンに基づき前記メディアストリームの復号方式及びレンダリング方式のうちの少なくとも一種を決定することに用いられるカプセル化ファイル送信ユニットと、を含む、メディアファイルのカプセル化装置。
15. メディアファイルのカプセル化解除装置であって、
    ターゲットメディアコンテンツの当該ターゲットメディアコンテンツに対応する応用シーン下でのメディアストリームのカプセル化ファイルを受信することに用いられるカプセル化ファイル受信ユニットであって、前記カプセル化ファイルのターゲットメディアファイルフォーマットデータボックスのボリュメトリックビジュアルメディアヘッダーデータボックスには前記メディアストリームに対応する応用シーンのタイプを示す第１応用シーンタイプフィールドが含まれる、カプセル化ファイル受信ユニットと、
    前記カプセル化ファイルをカプセル化解除し、前記第１応用シーンタイプフィールドを獲得することに用いられるファイルカプセル化解除ユニットと、
    前記第１応用シーンタイプフィールドに基づき、前記メディアストリームに対応する応用シーンを決定することに用いられる応用シーン獲得ユニットと、
    前記メディアストリームに対応する応用シーンに基づき、前記メディアストリームの復号方式及びレンダリング方式のうちの少なくとも一種を決定することに用いられる復号レンダリング決定ユニットと、を含む、メディアファイルのカプセル化解除装置。
16. 電子機器であって、
    少なくとも１つのプロセッサと、
    少なくとも１つのプログラムを記憶するように配置される記憶装置と、を含み、前記少なくとも１つのプログラムが前記少なくとも１つのプロセッサにより実行されるときに、前記少なくとも１つのプロセッサに請求項１～１０のいずれか一項に記載のメディアファイルのカプセル化方法又は請求項１１～１３のいずれか一項に記載のメディアファイルのカプセル化解除方法を実現させる、電子機器。
17. コンピュータプログラムであって、命令を含み、コンピュータ上で作動されるときに、コンピュータに請求項１～１０のいずれか一項に記載のメディアファイルのカプセル化方法又は請求項１１～１３のいずれか一項に記載のメディアファイルのカプセル化解除方法を実行させる、コンピュータプログラム。

Images