JP7472220B2 - 方法、プログラム、及びデバイス - Google Patents

方法、プログラム、及びデバイス Download PDF

Info

Publication number
JP7472220B2
JP7472220B2 JP2022155292A JP2022155292A JP7472220B2 JP 7472220 B2 JP7472220 B2 JP 7472220B2 JP 2022155292 A JP2022155292 A JP 2022155292A JP 2022155292 A JP2022155292 A JP 2022155292A JP 7472220 B2 JP7472220 B2 JP 7472220B2
Authority
JP
Japan
Prior art keywords
track
group
tracks
picture
media
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2022155292A
Other languages
English (en)
Other versions
JP2022177265A (ja
Inventor
フランク ドゥヌアル，
フレデリック マゼ，
ナエル ウエドラオゴ，
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Publication of JP2022177265A publication Critical patent/JP2022177265A/ja
Application granted granted Critical
Publication of JP7472220B2 publication Critical patent/JP7472220B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/816—Monomedia components thereof involving special video data, e.g 3D video
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H04N21/2355—Processing of additional data, e.g. scrambling of additional data or processing content descriptors involving reformatting operations of additional data, e.g. HTML pages
    • H04N21/2358—Processing of additional data, e.g. scrambling of additional data or processing content descriptors involving reformatting operations of additional data, e.g. HTML pages for generating different versions, e.g. for different recipient devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Description

本発明はメディアデータをカプセル化し、送信するための方法及び装置に関する。
本発明は、メディアコンテンツの交換、管理、編集及びプレゼンテーションを容易にする、柔軟で拡張可能なフォーマットを提供するために、及び、例えば適応ｈｔｔｐストリーミング・プロトコルを使用するインターネットのようなＩＰネットワーク上でそれの配信を改善するために、例えばＭＰＥＧ標準化団体によって定義された通り、ＩＳＯベース・メディアファイル・フォーマットに従って、メディアコンテンツをカプセル化することに関連する。国際標準化機構ベース・メディアファイル・フォーマット(ＩＳＯ ＢＭＦＦ、ＩＳＯ／ＩＥＣ １４４９６－１２）は、ローカルストレージ又はネットワーク介し又は別のビットストリーム配信メカニズムを介する送信のいずれかのための符号化された時限メディアデータ・ビットストリームを記述する周知の柔軟かつ拡張可能なフォーマットである。
拡張の一例は、様々なＮＡＬ(ネットワーク抽象化レイヤ）ユニットベースのビデオ符号化フォーマットのためのカプセル化ツールを記述するＩＳＯ／ＩＥＣ １４４９６－１５である。このような符号化フォーマットの例は、ＡＶＣ（Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）、ＳＶＣ（Ｓｃａｌａｂｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）、ＨＥＶＣ（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）、及びＬ－ＨＥＶＣ（Ｌａｙｅｒｅｄ ＨＥＶＣ）である。ファイル・フォーマット拡張の別の例は、ＨＥＶＣ静止画のような静止画像又は静止画像のシーケンスのためのカプセル化ツールを記述するＩＳＯ／ＩＥＣ ２３００８－１２である。ファイル・フォーマット拡張の別の例は、全方向メディアアプリケーションフォーマット（ＯＭＡＦ）を定義するＩＳＯ／ＩＥＣ ２３０９０－２である。
ＩＳＯ Ｂａｓｅ Ｍｅｄｉａファイル・フォーマットは、オブジェクト指向である。それは、逐次又は階層的に編成されて、タイミング及び構造パラメータのような符号化された時限メディアデータ・ビットストリームのパラメータを定義するボックスと呼ばれる構築ブロック（又は４文字コードによって特徴づけられるデータ構造）から構成される。ファイル・フォーマットでは、全体的なプレゼンテーションはムービーと呼ばれる。ムービーは、メディア又はプレゼンテーションファイルの最上位階層にムービーボックス（４文字コード‘ｍｏｏｖ’）により記述される。このムービーボックスは、プレゼンテーションを記述する様々なボックスのセットを含む初期情報コンテナを表す。
各トラック（トラック識別子（ｔｒａｃｋ＿ＩＤ）によって一意に識別される）は、プレゼンテーションに属するメディアデータの時限シーケンス（例えば、ビデオのフレーム）を表す。各トラック内で、データの各時限単位は、サンプルと呼ばれる。これは、ビデオ、オーディオ、又は時限メタデータのフレームの可能性がある。サンプルは、黙示的に順次番号を付与される。実際のサンプルデータは、ムービーボックスと同じ階層でＭｅｄｉａ Ｄａｔａ Ｂｏｘｅｓ(４文字コード‘ｍｄａｔ’）と呼ばれるボックスに保存される。サンプルの記述は、ＳａｍｐｌｅＴａｂｌｅＢｏｘのファイルのメタデータ部分に保存される。ムービーは、結合ムービーフラグメント及びメディアデータボックスのリストに続いて、全体プレゼンテーションの情報を含むムービーボックスとして一時的に編成され得る。ムービーフラグメント（４文字コード‘ｍｏｏｆ’のボックス）内には、ムービーフラグメントごとに０以上のトラックフラグメントのセット（４文字コード‘ｔｒａｆ’のボックス）がある。トラックフラグメントは、それぞれが、そのトラックフラグメントについてサンプルの連続した動作を文書化する、順次０以上のトラックランボックス（‘ｔｒｕｎ’）を含む。
ＩＳＯＢＭＦＦファイルは、複数のトラックを形成する符号化された時限メディアデータ・ビットストリームの複数の符号化された時限メディアデータ・ビットストリーム又はサブ部を含むことができる。サブ部が、時間（例えば、時間が引き継がれたしばしば‘タイル’と呼ばれる少なくとも１つの矩形領域）が引き継がれたビデオソースの１つ又は連続する空間部分に対応する場合、対応する複数のトラックは、サブピクチャトラックと呼ばれてもよい。ＩＳＯＢＭＦＦ及びそれの拡張は、トラック、静的な項目、又はサンプルを一緒にグループ化するためのいくつかのグループ化機構を含む。グループは、通常、共通のセマンティック及び／又は特性を共有する。
例えば、ＩＳＯＢＭＦＦは、エンティティグループ機構、トラックグループ機構、及びサンプルグループ化機構を備える。エンティティグループ化機構は、トラック及び／又は静的アイテムが、表示されたグループ化タイプ又はセマンティックに従ってグループ化されることを示すために使用され得る。トラックグループ化機構は、表示されたグループ化タイプ又はセマンティックに従ってトラックがグループ化されていることを示すために使用され得る。サンプルグループ化機構は、表示されたグループ化タイプ又はセマンティックに関連付けられた特定のプロパティが、トラック内のサンプルの示されたグループに適用することを示すために使用され得る。例えば、同じソースからのサブピクチャトラックは、トラックグループ機構を使用してグループ化されてもよい。
ユーザ体験を改善するために、時限メディアデータ・ビットストリーム（ビデオ及びオーディオでさえ）は、超高精細ビデオ（例えば、４ｋピクセル以上による８ｋ）に記録されてもよい。ユーザ体験を改善し、特に没入型体験を提供するために、時限メディアデータ・ビットストリーム（ビデオ及びオーディオでさえ）は、全方向性（又は多方向性又は複数方向性）であってよい。３６０°パノラマビデオとしても知られるビデオに適用される場合、ユーザは、表示されるシーン内に位置するように感じる。全方向性ビデオは、３６０°カメラから、及び／又は、全てのカメラが共通の節点を有するように、例えば、特別なリグに取り付けられたいくつかのカメラから取得されたビデオストリームの画像を合成することによって、取得されてもよい。このような画像の組合せは、画像スティッチング又はカメラスティッチングとして知られている。
このような全方向性ビデオは、ユーザの視線方向に従ってヘッドマウントディスプレイを介して、又はユーザを取り囲む湾曲した画面上への投影によってレンダリングされ得る。全方向性ビデオのユーザの所望の部分（ビューポートとしても知られる）に従って全方向性ビデオにパンするために、ナビゲーション・ユーザ・インターフェースを有する従来の２Ｄ画面上に表示されてもよい。それはしばしば、ユーザが仮想世界にいるように感じるので、仮想現実（ＶＲ）と呼ばれる。仮想オブジェクトが全方位ビデオに追加される場合、それは拡張現実（ＡＲ）と呼ばれる。本発明者らは、送信するためのメディアデータについての情報を記述し、信号伝達する時、特にメディアコンテンツが複数のサブピクチャトラックによって搬送されるいくつかのサブ部に分割される場合、いくつかの問題に気付いた。
例は、オーバーヘッドを生成し、複雑である、クライアントから特定の解析プロセスを要求するサブピクチャトラックの信号を含む。別の例は、トラック又はサブピクチャトラックのグループの信号伝達、及び、特にトラック又はサブピクチャトラックのこれらのグループ間の可能な関連付けに関連する。別の例は、表示の準備ができた全方向性メディアコンテンツを再構成するために、組み合わされることが許可されるか否か、サブピクチャトラックの信号伝達を含む。既存のソリューションは、複雑であるか、又はよく定義されていないかのいずれかであり、及び、２次元マルチトラックカプセル化処理のための既存機構に完全に準拠していない。
本発明は、上記の関連のうちの１つ以上に対処するように考案された。この文脈において、例えば、ｈｔｔｐプロトコルを使用するインターネットのようなＩＰネットワーク上で、メディアコンテンツ（例えば、無指向性メディアコンテンツ）をストリーミングするためのソリューションが提供されている。
本発明の第１の態様によれば、符号化時限メディアデータを１つの同じトラックグループに属する少なくとも第１及び第２のトラックにカプセル化する方法であって、前記メディアデータは、フルフレームで構成される１以上のビデオシーケンスに対応し、前記方法は、少なくとも第１又は第２のトラックのために、前記第１のトラックにカプセル化された１つのフレームの第１の空間部分の空間的関係に関する記述的情報を、前記第２のトラックにカプセル化された前記フレームの第２の空間部分に、提供することを有し、同じトラックのグループに属する前記トラックに共有される前記記述的情報は、前記第１及び前記第２の空間部分の両方によりカバーされる前記領域が、フルフレームを形成するか否かを示す、ことを特徴とする方法が提供される。
特に、各グループは、特定の関係を有するグループ内で特定の特性又はトラックを共有する。一実施形態では、前記記述的情報は、トラックグループの全ての前記トラックによって共有される記述的情報を有する、同じデータ構造に提供される。
一実施形態では、前記データ構造は、ＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘである。
一実施形態では、前記記述的情報は、前記第１及び前記第２の空間部分によってカバーされる前記領域が、フルフレームである場合には第１の値、前記第１及び前記第２の空間部分によってカバーされる前記領域が、フルフレームでない場合には第２の値を取る、前記トラックグループの全ての前記トラックに提供されるパラメータを有する。
一実施形態では、前記記述的情報は、前記第１及び前記第２の空間部分によってカバーされる前記領域が、前記フルフレームでない場合には、前記フルフレームから前記欠落空間部分に信号伝達するためのパラメータをさらに含む。
本発明の第２の態様によれば、符号化されたメディアデータをカプセル化したメディアファイルを生成する方法であって、各メディアトラックの少なくとも一部がトラックグループとしてグループ化され、グループ識別子によって識別されるトラックグループに属する複数のメディアトラックを生成することと、前記複数のメディアトラックのうち、参照するトラックからデータを抽出するためのＥｘｔｒａｃｔｏｒを含むＥｘｔｒａｃｔｏｒトラックを生成することと、前記複数のメディアトラックと前記Ｅｘｔｒａｃｔｏｒトラックとを含むメディアファイルを生成することと、を含み、前記Ｅｘｔｒａｃｔｏｒに含まれるＣｏｎｓｔｒｕｃｔｏｒのタイプとして、前記Ｅｘｔｒａｃｔｏｒが参照するトラックが、前記Ｃｏｎｓｔｒｕｃｔｏｒにより指定されるグループ識別子を有するトラックグループに属する他のトラックに切り替え可能であることを示す所定のタイプを指定可能である、ことを特徴とする方法が提供される。
一実施形態では、前記Ｃｏｎｓｔｒｕｃｔｏｒが参照するトラックとして、前記トラックグループに属する最初のトラックが選択される、
一実施形態では、前記複数のメディアトラックは、画像品質、解像度、ビットレートのいずれかが異なる。
一実施形態では、前記メディアファイルは、ＩＳＯ／ＩＥＣ１４４９６－１５規格で規定されるフォーマットのメディアファイルである。
一実施形態では、前記Ｅｘｔｒａｃｔｏｒにより抽出されるデータは、ＩＳＯ／ＩＥＣ１４４９６－１５規格で規定されるＮＡＬユニットのペイロードである。
本発明の第３の態様によれば、シーンのワイドビューに対応する符号化メディアデータをカプセル化する方法であって、前記シーンのワイドビューから前記投影ピクチャを得ることと、少なくとも１つのサブピクチャに得られた投影ピクチャをパッキングすることと、前記少なくとも１つのパック化ピクチャを少なくとも１つのサブピクチャに分割することと、前記少なくとも１つのサブピクチャを複数のトラックに符号化することと、前記符号化トラックに関連付けられた記述的メタデータを生成することを含み、前記記述的メタデータは、前記トラックに符号化された前記少なくとも１つのサブピクチャと前記少なくとも１つの投影ピクチャとの間の空間的関係を示す、各トラックに関連付けられた情報項目を含む、ことを特徴とする方法が提供される。
本発明の第４の態様によれば、メディアファイルを生成する方法であって、フルフレームで構成される１以上のビデオシーケンスをキャプチャすることと、前記１以上のビデオシーケンスの前記フレームに対応するメディアデータを符号化することと、前記符号化メディアデータを、請求項１に記載の前記カプセル化する方法に従って、１つの同じトラックグループに属する少なくとも第１及び第２のトラックにカプセル化することと、前記第１及び第２のトラックを有する、少なくとも１つのメディアファイルを生成することを含む、ことを特徴とする方法が提供される。
本発明の第５の態様によれば、メディアファイルから少なくとも１つのフレームを取得する方法であって、前記メディアファイルは、１つの同じトラックグループに属する少なくとも１つの第１及び第２のトラックにカプセル化された符号化時限メディアデータを有し、前記メディアデータは、フルフレームで構成される１以上のビデオシーケンスに対応し、前記方法は、前記第１及び前記第２のトラックに関連付けられた情報を解析することを有し、前記解析された情報は、前記第２のトラックにカプセル化された前記フレームの第２の空間部分とともに、前記第１のトラックにカプセル化された前記１つのフレームの第１の空間部分の空間的関係に関する記述的情報を有し、トラックグループの全ての前記トラックによって共有される前記記述的情報は、前記第１及び前記第２の空間部分の両方によってカバーされた前記領域が、フルフレームを形成するか否かを示すことを有する、ことを特徴する方法が提供される。
本発明の第６の態様によれば、メディアファイルを生成する方法であって、
メディアデータを符号化することと、請求項８に記載の前記カプセル化する方法に従って、前記符号化メディアデータを少なくとも第１又は第２のトラックグループに属する複数のトラックにカプセル化することと、少なくとも１つのメディアファイルを生成することを有し、前記少なくとも１つのメディアファイルは、前記第１及び第２のトラックを有する、ことを特徴とする方法が提供される。
本発明の第７の態様によれば、メディアファイルから符号化されたメディアデータを取得する方法であって、（１）各メディアトラックの少なくとも一部がトラックグループとしてグループ化され、グループ識別子によって識別されるトラックグループに属する複数のメディアトラックと、（２）前記複数のメディアトラックのうち、参照するトラックからデータを抽出するＥｘｔｒａｃｔｏｒを含むＥｘｔｒａｃｔｏｒトラックと、を含むメディアファイルを取得することと、取得した前記メディアファイルを処理することと、を含み、前記Ｅｘｔｒａｃｔｏｒに含まれるＣｏｎｓｔｒｕｃｔｏｒのタイプとして、前記Ｃｏｎｓｔｒｕｃｔｏｒが参照するトラックが、前記Ｃｏｎｓｔｒｕｃｔｏｒにより指定されるグループ識別子を有するトラックグループに属する他のトラックに切り替え可能であることを示す所定のタイプを指定可能である、ことを特徴とする方法が提供される。
本発明の第８の態様によれば、符号化されたメディアデータをカプセル化したメディアファイルを生成するデバイスであって、前記デバイスは、各メディアトラックの少なくとも一部がトラックグループとしてグループ化され、グループ識別子によって識別されるトラックグループに属する複数のメディアトラックを生成する第１生成手段と、前記複数のメディアトラックのうち、参照するトラックからデータを抽出するＥｘｔｒａｃｔｏｒを含むＥｘｔｒａｃｔｏｒトラックを生成する第２生成手段と、前記複数のメディアトラックと前記Ｅｘｔｒａｃｔｏｒトラックとを含むメディアファイルを生成する第３生成手段と、を備え、前記Ｅｘｔｒａｃｔｏｒに含まれるＣｏｎｓｔｒｕｃｔｏｒのタイプとして、前記Ｃｏｎｓｔｒｕｃｔｏｒが参照するトラックが、前記Ｃｏｎｓｔｒｕｃｔｏｒにより指定されるグループ識別子を有するトラックグループに属する他のトラックに切り替え可能であることを示す所定のタイプを指定可能である、ことを特徴とするデバイスが提供される。
本発明の第９の態様によれば、符号化メディアデータを少なくとも第１又は第２の同じグループタイプのトラックグループに属する複数のトラックにカプセル化するコンピューティングデバイスであって、前記コンピューティングデバイスは、前記第１のトラックグループに属する前記複数のトラックの前記トラックのために、記述的情報を提供するように構成され、前記記述的情報は、前記第１のトラックグループに属する少なくとも１つのトラックと前記第２のトラックグループに属する少なくとも１つのトラックが、切り替え可能であることを示す、ことを特徴とするコンピューティングデバイスが提供される。
本発明の第１０の態様によれば、メディアファイルから少なくとも１つのフレームを取得するコンピューティングデバイスであって、前記メディアファイルは、１つの同じトラックグループに属する少なくとも第１及び第２のトラックにカプセル化された符号化時限メディアデータを有し、前記メディアデータは、フルフレームで構成される１以上のビデオシーケンスに対応し、前記コンピューティングデバイスは、前記第１及び前記第２のトラックに関連付けられた情報を解析するように構成され、前記解析された情報は、前記第１のトラックにカプセル化された１つのフレームの第１の空間部分の空間的関係に関する記述的情報を含み、前記トラックグループの全ての前記トラックによって共有される前記記述的情報は、前記第１及び前記第２の空間部分の両方によってカバーされる前記領域が、フルフレームを形成するか否かを示す、ことを特徴とするコンピューティングデバイスが提供される。
本発明の第１１の態様によれば、メディアファイルから符号化されたメディアデータを取得するデバイスであって、（１）各メディアトラックの少なくとも一部がトラックグループとしてグループ化され、グループ識別子によって識別されるトラックグループに属する複数のメディアトラックと、（２）前記複数のメディアトラックのうち、参照するトラックからデータを抽出するＥｘｔｒａｃｔｏｒを含むＥｘｔｒａｃｔｏｒトラックと、を含むメディアファイルを取得する取得手段と、前記取得手段により取得された前記メディアファイルを処理する処理手段と、を備え、前記Ｅｘｔｒａｃｔｏｒに含まれるＣｏｎｓｔｒｕｃｔｏｒのタイプとして、前記Ｃｏｎｓｔｒｕｃｔｏｒが参照するトラックが、前記Ｃｏｎｓｔｒｕｃｔｏｒにより指定されるグループ識別子を有するトラックグループに属するトラックに切り替え可能であることを示す所定のタイプを指定可能である、ことを特徴とするデバイスが提供される。
本発明の第１２の態様によれば、プログラム可能な装置のコンピュータプログラム製品であって、前記コンピュータプログラム製品は、前記プログラム可能な装置によってロードされ実行される場合、請求項１から１４のいずれか１項に記載の方法を実行するための一連の命令を備える、ことを特徴とするコンピュータプログラム製品が提供される。
本発明の第１３の態様によれば、請求項１から１４のいずれか１項に記載の方法を実行するために、コンピュータプログラムの命令を格納するコンピュータ可読記憶媒体が提供される。
本発明の第１４の態様によれば、実行すると、コンピュータに請求項１から１４のいずれか１項に記載の方法を実行させるためのプログラムが提供される。
本発明のさらなる利点は図面及び詳細な説明を考察することにより、当業者に明らかになるであろう。任意の追加の利点は、本明細書に組み込まれることが意図される。本発明の実施形態は、単なる例として、以下の図面を参照して以下に記載される。
図１ａは、サーバからクライアントへの全方向ビデオのキャプチャ、処理、カプセル化、送信、及びレンダリングのためのデータフローの例を示す。 図１ｂは、サーバからクライアントへの全方向ビデオのキャプチャ、処理、カプセル化、送信、及びレンダリングのためのデータフローの例を示す。 図２ａは、本発明の実施形態によるカプセル化の例を示すブロック図を示す。 図２ｂは、本発明の実施形態によるカプセル化の例を示すブロック図を示す。 図３は、本発明の１つ以上の実施形態の実施のためのコンピューティングデバイスの概略ブロック図である。 図４ａは、２Ｄ空間関係記述のためのいくつかのトラックグループを含むサブピクチャトラックカプセル化の例を記載する。 図４ｂは、本発明の第２の態様によれば、グループが等価なグループであることを示すために代替方法に関する例を示す。 図５は、本発明の第２の態様による、等価なトラックグループの表示がトラック宣言の外側に提供される別の実施形態の例を示す。 図６は、本発明の実施形態によるＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤｄｅｓｃｒｉｐｔｉｏｎＢｏｘ及びｓｏｕｒｃｅ＿ｉｄの使用例を示す。 図７は、本発明の第３の態様の本発明の実施形態によるサブピクチャカプセル化を示す。 図８は、本発明の実施形態による解析処理を示す。 図９は、本発明の実施形態によるシステムを示す。 図１０ａは、本発明の実施形態による、投影、オプションのパッキング及びサブピクチャトラックへの分割の処理全体のいくつかの例を示す。 図１０ｂは、本発明の実施形態による、投影、オプションのパッキング及びサブピクチャトラックへの分割の処理全体のいくつかの例を示す。 図１０ｃは、本発明の実施形態による、投影、オプションのパッキング及びサブピクチャトラックへの分割の処理全体のいくつかの例を示す。 図１０ｄは、本発明の実施形態による、投影、オプションのパッキング及びサブピクチャトラックへの分割の処理全体のいくつかの例を示す。 図１１は、本発明の第１の態様の実施形態による、サブピクチャトラックとソース画像のセットとの間の関係の実施形態を示す。 図１２は、本発明の第１の態様の実施形態による、再構成に関連する追加情報を有する２Ｄ空間関係のトラックグループの例を示す。 図１３は、図１３ａ及び図１３ｂを含み、本発明の第２の態様の実施形態による、サブピクチャトラックの代替セットからの明示的な再構成を示す。 図１３は、図１３ａ及び図１３ｂを含み、本発明の第２の態様の実施形態による、サブピクチャトラックの代替セットからの明示的な再構成を示す。 図１４は、本発明の第２の態様の実施形態による、例えばＩＳＯＢＭＦＦパーサで、本発明によるファイル／セグメントのカプセル化解除手段による、抽出手段解像度を示す。
図１ａは、送信方法を実施するシステム１０の一例を示す。システム１０は、メディアデータ（例えば、２Ｄ画像）を流すことを可能にする。システム１０は、サーバ装置１０１とクライアント装置１７０とを備え、メディアデータは、サーバ装置１０１からクライアント装置１７０に送信される。図示されるように、メディアデータは、カメラシステム１００によってキャプチャされ、クライアントデバイス１７０に配信され、例えばユーザによって２Ｄ画面１７５（ＴＶ、タブレット、スマートフォンなど）上に表示されるビデオシーケンス１０１１であってよい。
ビデオシーケンスを形成する画像１０１１は、好ましい実施形態では、符号化手段１４０によって独立して符号化されるように、分割手段１０１２によって空間部分１０１３に分割される。独立した符号化は、１つの空間部分が、別の空間部分からの任意のデータを、差分又は予測符号化のための基準として使用しないことを意味する。例えば、符号化手段１４０がＨＥＶＣ（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）圧縮フォーマットに基づく場合、空間部分１０１３は、独立したタイルとして符号化され得る。代替実施形態では、空間部分１０１３は、動き制限タイルとして符号化され得る。符号化手段は、（例えば、ＨＥＶＣが独立したタイルを符号化するために使用される場合）Ｎ個の独立したサブビットストリームを有する空間部分又は１つのビットストリームと同数のビットストリームを提供する。次に、各提供されたビットストリーム又はサブビットストリームは、ファイル／セグメントカプセル化手段１５０によって、複数のサブピクチャトラック１０１４にカプセル化される。パッケージング又はカプセル化フォーマットは、例えば、ＭＰＥＧ標準化機構によって定義されているように、ＩＳＯベース・メディアファイル・フォーマット及びＩＳＯ／ＩＥＣ １４４９６－１５に従ってよい。生じるファイル又はセグメントファイルは、ｍｐ４ファイル又はｍｐ４セグメントであってよい。カプセル化中に、オーディオストリームは、ビデオシーケンス又は追加オーディオストリームに関する記述的情報（メタデータ）を提供するメタデータトラックだけでなく、ビデオビットストリームが追加されてよい。
次に、カプセル化されたファイル又はセグメントファイルは、例えば、ｈｔｔｐ(ハイパーテキスト・トランスファー・プロトコル）プロトコルを使用するインターネットのようなＩＰネットワーク上、又は例えばディスク又はＵＳＢキーなどの取り外し可能なデジタル媒体で、配信手段１６０を介してクライアント装置１７０に配信される。説明のために、配信手段１６０は、ＭＰＥＧ標準化委員会（「ＩＳＯ／ＩＥＣ ２３００９－１、動的適応オーバーＨＴＴＰ（ＤＡＳＨ）、第１部：メディアプレゼンテーション記述及びセグメントフォーマット」）からのＤＡＳＨ（動的適応ストリーミングオーバーＨＴＴＰ）のようなＨＴＴＰを介した適応ストリーミングを実装する。配信手段は、ストリーミングサーバ１６１及びストリーミングクライアント１６２を備えることができる。メディアプレゼンテーション記述は、全画像を含むビデオシーケンスをカプセル化するトラックに対応するメディアセグメント、又はサブピクチャトラックのみ、又は両方に対して、記述及びＵＲＬを提供することができる。メディアプレゼンテーション記述は、サブピクチャトラックの代替グループを提供することができ、各グループは、カメラ１１０によってキャプチャされたシーンの異なる再構成レベルを可能にする。代替は、例えば、解像度、品質、又はビットレート、異なる分割（分割手段１０１３に関連付けられた粗い又は細かいグリッド）に関してであってよい。
ストリーミングクライアント１６２によって受信されると、カプセル化されたメディアファイル又はメディアセグメントは、１つ以上のデータストリームを抽出するために、ファイル／セグメントカプセル化解除手段１７１によって解析される。抽出されたデータストリームは、復号化手段１７２によって復号される。ファイル／セグメントカプセル化解除手段１７１によって受信されたＩＳＯＢＭＦＦファイル又はセグメントの場合、解析は、典型的には、ｍｐ４リーダ又はｍｐ４パーサによって処理される。記述メタデータから、パーサはカプセル化されたビデオビットストリーム及び／又はビデオサブビットストリームを抽出できる。次に、オプションで、復号化手段１７２によって提供されるビデオシーケンスの復号化された画像又はサブ画像は、レンダリング手段１７４によって、ビデオレンダリングのために生じる画像に構成される。レンダリングされたビデオは、画面（ユーザ装置）のような表示手段１７５に表示される。
ビデオレンダリングは、クライアントの表示サイズ又は処理能力の中でいくつかのパラメータに依存することに留意されたい。次に、レンダリングは、解析され及び復号されたサブピクチャトラックのサブセットのみを表示することから構成してもよい。これは、レンダリング手段１７４によって又はストリーミングクライアント１６２によるコンテンツ選択において直接制御されてもよい。ＶＨＤ（「超高精細」のための）ビデオストリームのいくつかの画像の送信及びレンダリングは、非常に高いビットレート及び超高解像度のメディアデータストリームをもたらし得ることが観察されている。したがって、システム全体を考慮する場合、帯域幅の浪費を避けるために、及び、クライアントプレーヤの処理能力に準拠したままにするために、メディアデータへのアクセスを最適化する必要がある。このような必要性は、メディアデータストリームが特定のアプリケーションのために使用され得るということで、一層重要である。特に、メディアデータストリームは、プロジェクタのアレイのような専用ディスプレイで画像を表示するために使用され得る。キャプチャビデオ１１０内の特定の対象領域を表示するために使用されてもよい。
図１ｂは、送信方法を実施するシステム１１の別の例を示す。システム１１は、全方向性メディアデータを流すことを可能にする。図示されるように、このメディアは、カメラシステム１００から取得され、ヘッドマウントディスプレイ（ＨＭＤ）１７０及び１７６に配信されるビデオコンテンツを有する。カメラシステム１００は、広角レンズを備えた１つのカメラ、又は一緒に組み立てられた複数のカメラのセット（例えば、仮想現実用のカメラリグ）を含むことができる。配信手段１６０は、例えば、ストリーミングサーバ１６１及びストリーミングクライアント１６２を介して、適応ｈｔｔｐストリーミング・プロトコルを用いて、インターネットのようなＩＰネットワーク１６３を介して配信を行うことができる。図示のために、使用されるカメラシステム１００は、立方体の各面に関連付けられた６つの標準カメラのセットに基づいている。それは、カメラシステムを取り囲む実際のシーンを表す画像をキャプチャするために使用される。この構成によれば、１つのカメラが前方画像を提供し、１つのカメラが後方画像を提供し、１つのカメラが左側画像を提供し、１つのカメラが右側画像を提供し、１つのカメラが下方画像を提供し、及び１台のカメラが上方画像を提供する。
カメラシステム１００から得られた画像は、３６０ビデオストリーム又は仮想現実メディアデータストリームとも呼ばれる全方向性ビデオストリームを形成する３６０の画像を生成するために、サーバ１０１内の画像処理手段によって処理される。処理手段１２０は、同時インスタンスのキャプチャ画像をスティッチングし、及び、投影することを可能にする。画像はまず、水平及び垂直の寸法の両方で３６０°ビューを形成する球体１２１を示す三次元投影構造上にスティッチ及び投影される。投影構造上の３６０の画像データは、例えば正距円筒図法投影（ｈｔｔｐｓ://ｅｎ.ｗｉｋｉｐｅｄｉａ.ｏｒｇ/ｗｉｋｉ/Ｅｑｕｉｒｅｃｔａｎｇｕｌａｒ_ｐｒｏｊｅｃｔｉｏｎ)）を使用して、二次元投影画像１２２（キャプチャ投影とも表記される）にさらに変換される。投影画像は、球全体をカバーする。
あるいは、全方位メディアが立体視３６０度ビデオである場合、カメラシステム１００は、左側ビューを表す画像シーケンスをキャプチャする複数のカメラと、三次元３６０度シーンをレンダリングするために、クライアントにより後で使用され得る右側ビューとで構成されてもよい。このような場合、上記の処理手段１２０は、左側ビュー及び右側ビューの画像シーケンスの両方を別々に処理する。オプションで、フレームパッキングは、同時インスタンスの各左側ビュー画像及び右側ビュー画像を、１つの単一の左＋右投影画像シーケンス上に生じる同じ投影画像にパックするために、立体視フレームパッキング手段１２５によって適用されてよい。いくつかの立体視フレームパッキング構成は、例えば、並行、上下、列ベースのインターリーブ、行ベースのインターリーブ、左右のビューを交互にする時間的インターリーブが可能である。あるいは、立体視フレームパッキング構成は、符号化手段１４０による符号化後に独立したビデオビットストリームをもたらす、別々に及び独立した投影画像シーケンスに左右のビューを保持することからなってもよい。例えば、一つのビデオビットストリームは、左側のビュー画像を示し、他方は、右側のビュー画像を示す。
オプションで、領域的パッキング手段１３０による領域的パッキングは、次に、パックされた画像１３１上に投影画像１２２をマッピングするために適用される。領域的パッキングは、例えば、ユーザにとって最も有用な球の部分に信号情報を最大化するために、変換（例えば、画素ブロックの回転、ミラーリング、コピー、又は移動など）、投影画像の領域のサイズ変更、及び再配置を順番に適用することからなる。パックされた画像は、球全体の一部のみをカバーすることができることに留意され得る。領域的パッキングが適用されない場合、パックされた画像１３１は、投影画像１２２と同一である。立体視全方位メディアの場合、領域的パッキングは、立体フレームパッキング手段１２５によって選択されるフレームパッキング構成に依存する、左＋右投影画像シーケンス上、又は、左側ビュー及び右側のビュー投影画像シーケンス上の別々、のいずれかに適用する。
投影画像１２２又はパック化画像１３１は、符号化手段１４０によって１つ又は複数のビデオビットストリームに符号化される。立体視全方向性メディアの場合、符号化ステップは、立体視フレームパッキング手段１２５によって選択されたフレームパッキング構成に依存する、左＋右パッキング画像シーケンス上、又は、左側ビュー及び右側ビューのパック化画像シーケンス上の別々、のいずれかに適用する。あるいは、マルチビュー符号化は、左側ビュー及び右側ビューのパック化画像シーケンス上で使用され得る。符号化フォーマットの例としては、ＡＶＣ （Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）、ＳＶＣ （Ｓｃａｌａｂｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）、ＨＥＶＣ （Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）又はＬ－ＨＥＶＣ （Ｌａｙｅｒｅｄ ＨＥＶＣ）がある。以下では、ＨＥＶＣは、ＨＥＶＣ及びそれの階層化拡張（Ｌ－ＨＥＶＣ）への両方を参照するために使用される。
ＨＥＶＣ及び同様のビデオ符号化フォーマットは、サンプルの異なる空間的小部分、例えば、ピクチャ、すなわちタイル、スライス、及びスライスセグメントを定義する。タイルは、水平及び垂直の境界（すなわち、行及び列）によって定義され、符号化ツリーユニット（ＣＴＵ）又は符号化ブロックの整数個を含むピクチャの矩形領域を定義し、全ては以下で符号化ユニットと呼ばれる。したがって、タイルはピクチャの空間的サブ部を表現するための良い候補である。しかしながら、シンタックス及びＮＡＬユニット（又はＮＡＬＵ）へのそれのカプセル化に関して、符号化ビデオデータ（ビットストリーム）編成は、（ＡＶＣ内のように）むしろスライス及びスライスセグメントに基づく。ＨＥＶＣ内のスライスは、独立したスライスセグメントであり、もしあれば、他は従属スライスセグメントである少なくとも第１のスライスセグメントを有する、スライスセグメントのセットである。スライスセグメントは、整数個の連続する（ラスタスキャン順の)ＣＴＵを含む。
スライスは、必ずしも矩形状を有する必要はない（したがって、それは空間サブ部表現のためのタイルよりも少し適切である）。スライスセグメントは、ｓｌｉｃｅ＿ｓｅｇｍｅｎｔ＿ｈｅａｄｅｒの後に続くｓｌｉｃｅ＿ｓｅｇｍｅｎｔ＿ｄａｔａとして、ＨＥＶＣビットストリームに符号化される。独立スライスセグメント（ＩＳＳ）及び従属スライスセグメント（ＤＳＳ）は、それらのヘッダにより異なる。つまり、従属スライスセグメントは、独立スライスセグメントのヘッダからの情報を再利用するため、より短いヘッダを有する。独立及び従属スライスセグメントの両方は、ビットストリーム内のエントリポイントのリストを含む。ビデオビットストリームがタイルで符号化されるとき、タイルは、タイルが同じピクチャ内の近傍タイル（空間依存性）から及び先行参照ピクチャ内の近傍タイル（時間依存性）から依存しないことを保証するために動き制限され得る。このように、動き制限されたタイルは、独立して復号可能である。
あるいは、投影画像１２２又はパック化画像１３１は、例えば、独立して符号化されたＨＥＶＣビットストリームを形成する、独立して符号化された各サブピクチャを符号化する前に、いくつかの空間サブピクチャに分割手段によって分割され得る。あるいは、領域的パッキング手段１３０及び分割手段によるいくつかの空間サブピクチャへの分割は、完全な中間パック化画像１３１をメモリ内に生成することなく同時に操作することができる。投影画像１２２（又は、オプションの領域的パッキング後に生じる立体視投影画像）は、サブ部に分割されてよく、各サブ部は、符号化手段１４０によって符号化されるように空間的サブピクチャに直接パックされてよい。
図１０ａ、図１０ｂ、図１０ｃ、及び図１０ｄは、本発明の実施形態による、例えば手段１２５、１３０、又は１０１２で実施される投影、オプションのパッキング、及びサブピクチャトラックへの分割のプロセス全体のいくつかの例を示す。投影画像１００１からの１つ以上の領域（１、２、３及び４と記される）は、いくつかの変換操作（識別、上下スケーリング、回転、ミラーリング、再配置など）を適用することによってパック化領域１００２（１’、２’、３’及び４’と記される）に再配置され、次に、１つ以上のサブピクチャトラック１００３に分割および再編成される。分割はまた、パック化領域（１’、２’、３’又は４’）ごとに１つのサブピクチャトラックをもたらすことができる。パッキング及び分割操作は、投影ピクチャ１０１１から１つ以上のサブピクチャトラック１０１２へ直接的に、一度に実行されてもよい。図１０ｃ及び１０ｄは、全方向性コンテンツが立体コンテンツである場合の異なる可能なカプセル化の例を提供する。このような場合、キャプチャステップ１１０は、立体視記録、典型的には目ごとに１つのビデオを可能にするカメラリグを使用する。
図１０ｃは、フレームパッキング（図１のオプションのフレームパッキングのための手段１２５）がない場合の立体全方位コンテンツの例を示す。次に、各投影ビュー１０２１は、（１０２２において）領域的パッキングが各ビューに適用されるとき、１０２３のような複数のサブピクチャトラックにできる限り独立してカプセル化される。この例では、各ビューの領域毎に１つのサブピクチャトラックがある。一つは、同じサブピクチャトラック内の同じ領域の両方のビューをカプセル化することを決定することさえできる。次に、サブピクチャトラックは、使用されるフレームパッキングを示すサンプル記述レベルでステレオビデオボックスを含む。
図１０ｄは、２つの投影ビュー１０３１を単一のフレームパック化ピクチャ１０３２にパックするために、適用されるフレームパッキング（オプションのフレームパッキングのための手段１２５）がある場合の立体全方位コンテンツの例を示す。次に、生じるフレームパック化ピクチャ１０３２は、１０３３のように、おそらく複数のサブピクチャトラックにカプセル化される。この例では、各サブピクチャトラックは、所定の空間領域に対する両方のビューを記述する。投影の後に続くパッキングについては、１つのサブピクチャトラックは、（図１０に示されるように）１つの領域又は多くの領域をカプセル化することができる。カプセル化モジュールは、例えば、コンテンツを複数のパック化領域を含むサブピクチャトラックにカプセル化するために、記述コスト対アクセス粒度のトレードオフを決定することができる。これは、パック化領域の逆投影を計算することによるカプセル化が、パック化フレーム内の連続する領域の逆投影にギャップがないことを見出す場合のケースであってもよい。これは、パック化ピクチャからのこれらの領域を単一のサブピクチャトラックにグループ化するための決定基準とすることができる。
図１０ａ、１０ｂ、１０ｃ及び１０ｄは、同じサブピクチャトラックにおけるいくつかの領域のそのような集合を示す。カプセル化モジュールが、投影ピクチャ内にギャップ、ホール又はカバーされていないピクセルを生成するサブピクチャトラック内の複数の領域を集める場合には、それは、サブピクチャトラック位置及びサイズを、これらの複数の領域のバウンディングボックスの位置及びサイズと等しく設定することができる。したがって、符号化手段１４０によって実行される符号化の結果として、投影画像１２２又はパック化画像１３１は、１つ以上が独立して符号化されたビットストリームによって、又は１つ以上が独立して符号化されたサブビットストリームから構成される少なくとも１つの符号化ビットストリームによって表され得る。それらの符号化ビットストリーム及びサブビットストリームは、次に、カプセル化手段１５０によって、例えば、ＭＰＥＧ標準化機構によって定義されるように、ＩＳＯベース・メディアファイル・フォーマット及び全方向性メディアフォーマット（ＯＭＡＦ－ＩＳＯ／ＩＥＣ ２３０９０－２）に従って、カプセル化ファイル・フォーマットに記載のファイル又は小さい時間的なセグメントファイル１６５にカプセル化される。生じるファイル又はセグメントファイルは、ｍｐ４ファイル又はｍｐ４セグメントであってよい。カプセル化の間、オーディオストリームは、ビデオ上又はオーディオストリーム上の情報を提供するメタデータトラックだけでなく、ビデオビットストリームにも追加されてよい。
次に、カプセル化されたファイル又はセグメントファイルは、例えば、ｈｔｔｐ（ハイパーテキスト・トランスファー・プロトコル）プロトコルを用いてインターネット上で、又は例えばディスクのような取り外し可能なデジタル媒体上で、配信メカニズム１６０を介してクライアント１７０に配信される。説明のために、配信１６０は、ＭＰＥＧ標準化委員会（「ＩＳＯ／ＩＥＣ ２３００９－１、動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ）、第１部：メディアプレゼンテーション記述及びセグメントフォーマット」）からのＤＡＳＨ（動的適応ストリーミングオーバーＨＴＴＰ）のようなＨＴＴＰを介した適応ストリーミングを使用して実行される。この標準は、メディアプレゼンテーションのメディアコンテンツのコンパクトな記述をＨＴＴＰユニフォームリソースロケーションズ(ＵＲＬｓ)と関連付けることを可能にする。このような関連付けは、典型的には、マニフェストファイル又は記述ファイル１６４と呼ばれるファイルに記述される。ＤＡＳＨの文脈では、このマニフェストファイルはＭＰＤファイル(メディアプレゼンテーション記述)とも呼ばれるＸＭＬファイルである。
ＭＰＤファイルを受信することにより、クライアント装置１７０は、各メディアコンテンツ要素の記述を取得する。したがって、それはメディアプレゼンテーションで提案されているメディアコンテンツ要素の種類を認識し、ストリーミングクライアント１６２を介して、ストリーミングサーバ１６１から関連するメディアセグメント１６５をダウンロードするために使用されるようなＨＴＴＰ ＵＲＬｓを知得する。したがって、クライアント１７０は、どのメディアコンテンツ要素を（ＨＴＴＰ要求を介して）ダウンロードし、及び再生するか（すなわち、復号化し及びメディアセグメントの受信後に再生する）を決定することができる。クライアントデバイスは、ユーザのビューポート（すなわち、ユーザによって現在表示され、及び視聴されている球状ビデオの一部）により、シーンのワイドビューを表すフルパック化画像の空間部分に対応するメディアセグメントのみを取得することができることに留意されたい。シーンのワイドビューは、フルパック化画像によって表されるフルビューを表すことができる。
受信すると、カプセル化された仮想現実メディアファイル又はメディアセグメントは、復号化手段１７２によって復号化される１つ以上のデータストリームを抽出するために、手段１７１によって解析される。手段１７１によって受信されるＩＳＯＢＭＦＦファイル又はセグメントの場合、解析は、典型的には、記述的メタデータからカプセル化されたビデオビットストリーム及び／又はビデオサブビットストリームを抽出できるｍｐ４リーダ又はｍｐ４パーサによって処理される。次に、オプションで、手段１７３に提供されるパック化画像又はパック化サブ画像は、復号化手段１７２が、次に、ビデオレンダリングのために処理され（レンダリング手段１７４）、及び表示される（表示手段１７５）投影画像を得るために、アンパックされる。あるいは、パック化サブ画像は、投影ピクチャにアンパックされる前に、中間フルパック化画像を合成するように再配置されてもよい。
ビデオレンダリングは、投影画像を生成するために使用されるユーザの視点、視点、及び投影の中からいくつかのパラメータに依存することに留意されたい。図示のように、ビデオレンダリングは、復号された投影画像を球上に再投影するステップを含む。このような再投影から得られた画像は、ヘッドマウントディスプレイ１７６に表示される。立体視ビューを処理するために、図１を参照して説明される処理は、複製されてよく、又は部分的に複製されてもよい。ＵＨＤ(超高精細)ビデオストリームのいくつかの画像を仮想現実メディアデータストリームのパノラマ画像にスティッチングすることは、非常に高いビットレート及び非常に超高解像度の仮想現実メディアデータストリームをもたらすことが観察されている。したがって、システムの観点から、及び帯域幅の浪費を回避し、クライアントプレーヤの処理能力に準拠したままにするために、仮想現実メディアデータへのアクセスを最適化する必要がある。
このような必要性は、仮想現実メディアデータストリームが、図１を参照して説明されたものより別の目的のために使用され得ることが、一層重要である。特に、仮想現実メディアデータストリームが、３６０°プロジェクタアレイのような特定のディスプレイを用いて３６０°画像を表示するために使用され得る。特定の視野を表示し、及び／又は視点、視野、及び視点を変更するために使用されてもよい。特定の実施形態によれば、パック化画像１３１の符号化から生じる符号化ビットストリーム及びサブビットストリーム（図１の手段１４０）は、カプセル化ファイル・フォーマット、例えば、ＩＳＯベース・メディアファイル・フォーマット（ＩＳＯ／ＩＥＣ １４４９６－１２及びＩＳＯ／ＩＥＣ １４４９６－１５）、全方向性メディアフォーマット（ＯＭＡＦ）（ＩＳＯ／ＩＥＣ ２３０９０－２）、及びＭＰＥＧ標準化機構によって定義される関連仕様に従って、ファイル又は小さい時間的セグメントファイルにカプセル化される。符号化ビットストリーム（例えば、ＨＥＶＣ）及び場合によってはそれのサブビットストリーム（例えば、タイル化されたＨＥＶＣ、ＭＶ－ＨＥＶＣ、スケーラブルＨＥＶＣ）は、１つの単一トラックとしてカプセル化され得る。あるいは、空間的に関連する（すなわち、投影画像のサブ空間部である）複数の符号化ビットストリームが、いくつかのサブピクチャトラックとしてカプセル化され得る。あるいは、いくつかのサブビットストリーム（タイル、ビュー、レイヤ）を含む符号化ビットストリーム（例えば、タイル化ＨＥＶＣ、ＭＶ－ＨＥＶＣ、スケーラブルＨＥＶＣ）は、複数のサブピクチャトラックとしてカプセル化され得る。
サブピクチャトラックは、ピクチャ又は画像のサブ部分、典型的には空間部分又は矩形領域のためのデータを埋め込むトラックである。サブピクチャトラックは、他のサブピクチャトラック、又はサブピクチャが抽出されるフルピクチャを記述するトラックに関連付けられてもよい。例えば、サブピクチャトラックは、タイルトラックであってよい。それは、ＡＶＣトラック、ＨＥＶＣトラック、ＨＥＶＣタイルトラック、又はサンプルのシーケンスとしてカプセル化された任意の圧縮ビデオビットストリームによって表され得る。タイルトラックは、画像の空間部分、又は画像又はピクチャのサブピクチャに対応する時限ビデオサンプルのシーケンスである。それは、例えば画像内の対象領域又は画像内の任意領域となることができる。タイルトラックに対応するデータは、ビデオビットストリームから入手することができ、又はビデオビットストリームのサブ部から入手することができる。例えば、タイルトラックは、ＡＶＣ又はＨＥＶＣに準拠したビットストリームであってよく、又は、ＡＶＣ又はＨＥＶＣ又は例えばＨＥＶＣタイルのような任意の符号化ビットストリームのサブ部であってよい。好ましい実施形態では、タイルトラックは、独立して復号可能である（符号化手段は、「動き制限」タイルを生成することによって他のタイルから動き予測を除去するように注意した）。
タイルトラックが、タイルを有するＨＥＶＣで符号化されたビデオビットストリームに対応する場合、それはＩＳＯ／ＩＥＣ １４４９６－１５ 第４版に記載されているように、‘ｈｖｔ１’トラックとして示されるＨＥＶＣタイルトラックにカプセル化され得る。それは次に、パラメータセット、ビデオ復号化手段をセットアップするための高レベル情報を取得するために、タイルベーストラックを参照することができる。それは、ＨＥＶＣトラック‘ｈｖｃ１’又は‘ｈｅｖ１’トラックにカプセル化され得る。タイルトラックは、サブピクチャをより大きな画像又はピクチャに空間的に合成するために使用され得る。タイルベーストラックは、これらの１つ以上のトラック間で共有されるデータ又はメタデータを含む１つ以上のタイルトラックに共通するトラックである。タイルベーストラックは、１つ以上のタイルトラックから画像を合成するための命令を含むことができる。タイルトラックは、完了の復号又はレンダリングのためにタイルベーストラックに依存することができる。タイルベーストラックは、タイルを有するＨＥＶＣで符号化されたビデオビットストリームから導出する場合、それは‘ｈｖｃ２’又は‘ｈｅｖ２’トラックとして示されるＨＥＶＣトラックにカプセル化される。さらに、それはトラック参照‘ｔｂａｓ’を介してＨＥＶＣタイルトラックによって参照され、それはＩＳＯ／ＩＥＣ １４４９６－１５ 第４版に記載されているように、ＨＥＶＣタイルトラックへの‘ｓａｂｔ’トラック参照を用いたタイル規則化を示す。
合成トラック（参照トラックとも表記される）は、画像を合成するために他のトラックを参照するトラックである。合成トラックの一例は、ビデオトラックの場合、サブピクチャトラックをより大きな画像に合成するトラックである。これは、例えば、各ビデオトラックからの画像をより大きな画像に合成するための変換及び変形パラメータを提供するビデオトラックから導出するトラックにおいて、ポストデコーディング操作によって実行され得る。合成トラックは、サブビットストリーム連結から生じるビットストリームを復号する前に形成するために、他のビデオトラック又はタイルトラックからＮＡＬユニットを抽出するための命令を提供する抽出手段ＮＡＬユニットを有するトラックであってもよい。合成トラックは、例えば、他のトラックへのトラック参照を介して、合成命令を黙示的に提供するトラックであってもよい。合成トラックは、ビットストリーム連結又はサンプル再構成規則を提供することによって、サブピクチャトラックの空間的合成のためのレンダリング手段１７４によって実行されるレンダリングに役立つことができる。ビットストリーム連結又はサンプル再構成規則は、例えば、１つ以上の抽出手段ＮＡＬユニットを使用して、各サンプルに対して定義されてよく、又は、それらは例えば、タイルベーストラックのようなトラック参照を介して、トラックレベルで定義されてよい。
ＩＳＯ／ＩＥＣ １４４９６－１２は、各グループが特定の特性を共有する、又はグループ内のトラックが特定の関係を有する場合、トラックグループを記述するために、トラックレベル（すなわち、ＩＳＯＢＭＦＦボックス階層における‘ｔｒａｋ’ボックス内）に位置する‘ｔｒｇｒ’と示されるボックスを提供する。このトラックグループボックスは、次のように定義された空のコンテナである。
ボックスタイプ: ‘trgr'
コンテナ: TrackBox (‘trak')
必須: No
数量: ０又は１
aligned(8) class TrackGroupBox extends Box(‘trgr') {
}
このトラックグループボックスは、以下の通り定義されるトラックグループタイプボックスのセットを含むことができる:
aligned(8) class TrackGroupTypeBox(unsigned int(32) track_group_type)
extends FullBox(track_group_type, version = 0, flags = 0)
{
unsigned int(32) track_group_id;
// 残りのデータは、特定のtrack_group_typeに指定されてよい
}
特定の特性、又はこのトラックグループタイプボックスのインスタンスによって宣言された関係は、ボックスタイプ（ｔｒａｃｋ＿ｇｒｏｕｐ＿ｔｙｐｅ）によって示される。このボックスは、同じトラックグループに属するトラックを判定するために使用され得る、識別子（ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ）も含む。同じｔｒａｃｋ＿ｇｒｏｕｐ＿ｔｙｐｅとｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄの値を有するトラックグループタイプボックスを有するトラックグループボックスを有する全てのトラックは、同じトラックグループの一部である。このボックスは、特定のトラックグループタイプに対するトラックに関連する特定のパラメータを宣言することも可能にする。ＭＰＥＧ ＩＳＯＢＭＦＦ規格（ＩＳＯ／ＩＥＣ １４４９６－１２ 第７版 補正１－５月 ２０１８）は、二次元空間関係のための特定のトラックグループＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘを、タイプ‘２ｄｃｃ’のＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘとして提案している。Ｔｒａｃｋ＿ｇｒｏｕｐ＿ｔｙｐｅが「２ｄｃｃ」に等しいＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘ ＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘは、このトラックが２Ｄ空間関係を有するトラックのグループに属することを示す（例えば、ビデオソースの平面空間部分に対応する）。
所定のｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄを有するＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘ ＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘは、任意の原点（０，０）とｔｏｔａｌ＿ｗｉｄｔｈとｔｏｔａｌ＿ｈｅｉｇｈｔで定義される最大サイズを有する座標系を黙示的に定義する。ｘ軸は左から右に、及び、ｙ軸は上から下に向けられる。ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘ ＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘ内のｓｏｕｒｃｅ＿ｉｄの同値を有するトラックは、同じソースから生じるようにマッピングされ、及び、それらの関連する座標系は、同じ原点（０，０）及びそれらの軸の向きを共有する。ファイル内に２Ｄ空間関係のための１つのトラックグループだけが存在する場合、ｓｏｕｒｃｅ＿ｉｄパラメータはオプションである。ソース又はビデオソースは、全方向性コンテンツのためにカメラ又はカメラのセットによってキャプチャされているコンテンツに対応する。例えば、非常に高解像度のビデオは、サブピクチャトラックに分割され得る。次に、各サブピクチャトラックは、ソースビデオにそれの位置及びサイズを搬送する。
タイプ「２ｄｃｃ」の二次元空間関係トラックグループは、以下のように定義される：
aligned(8) class SpatialRelationship2DSourceBox
extends FullBox(’2dsr', 0, 0) {
unsigned int(32) total_width;
unsigned int(32) total_height;
unsigned int(32) source_id;
}

aligned(8) class SubPictureRegionBox extends FullBox('sprg',0,0) {
unsigned int(16) object_x;
unsigned int(16) object_y;
unsigned int(16) object_width;
unsigned int(16) object_height;
}

aligned(8) class SpatialRelationship2DDescriptionBox extends TrackGroupTypeBox('2dcc')
{
// track_group_idはTrackGroupTypeBoxから引き継がれる;
SpatialRelationship2DSourceBox(); // 必須,最初でなければならない
SubPictureRegionBox (); // オプション
}
ここで、ｏｂｊｅｃｔ＿ｘは、囲んでいるトラックグループにより指定された領域内のトラックの左上角の水平位置を指定する。位置値は、もしあれば、トラックの幅と高さによって引き起こされる黙示的なリサンプリングを適用する前の値であり、０～ｔｏｔａｌ＿ｗｉｄｔｈ－１の範囲に含まれ、ｔｏｔａｌ＿ｗｉｄｔｈは囲んでいるトラックグループによって定義される場合、ｏｂｊｅｃｔ＿ｙは囲んでいるトラックグループによって指定された領域内のトラックの左上角の垂直位置を指定する。位置値は、もしあれば、トラックの幅と高さによって引き起こされる黙示的なリサンプリングを適用する前の値であり、０～ｔｏｔａｌ＿ｈｅｉｇｈｔ－１の範囲で含まれ、ｔｏｔａｌ＿ｈｅｉｇｈｔは囲んでいるトラックグループによって定義される場合、ｏｂｊｅｃｔ＿ｗｉｄｔｈは囲んでいるトラックグループによって指定された領域内のトラックの幅を指定する。位置値は、もしあれば、トラック幅と高さによって引き起こされる黙示的なリサンプリングを適用する前の値であり、１～ｔｏｔａｌ＿ｗｉｄｔｈの範囲で含まれ、ｔｏｔａｌ＿ｗｉｄｔｈは囲んでいるトラックグループに定義される場合、ｏｂｊｅｃｔ＿ｈｅｉｇｈｔは囲んでいるトラックグループによって指定された領域内のトラックの高さを指定する。
ｔｏｔａｌ＿ｗｉｄｔｈの値は、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄの同値を有するＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐＤｅｓｃｒｉｐｔｉｏｎＢｏｘの全てのインスタンスで同じであり、ｔｏｔａｌ＿ｈｅｉｇｈｔは、画素単位で、‘ｓｒｄ'トラックグループの座標系における最大高さを指定する。ｔｏｔａｌ＿ｈｅｉｇｈｔの値は、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄの同値を有するＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐＤｅｓｃｒｉｐｔｉｏｎＢｏｘの全てのインスタンスで同じであり、ｓｏｕｒｃｅ＿ｉｄはソースのための固有識別子を提供するオプションのパラメータである。それは、このソースに関連付けられた座標系を黙示的に定義する。ＳｕｂＰｉｃｔｕｒｅＲｅｇｉｏｎＢｏｘ（）は、囲んでいるトラックグループで指定された領域内のトラックの静的な位置とサイズを提供するオプションのボックスである。ＳｕｂＰｉｃｔｕｒｅＲｅｇｉｏｎＢｏｘ（）がＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘ内に存在する場合、次に、関連するトラック内に関連するＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＧｒｏｕｐＥｎｔｒｙは存在しない（このトラックは、定数、静的、サイズ、及び位置を有する）。
ＳｕｂＰｉｃｔｕｒｅＲｅｇｉｏｎＢｏｘ（）が、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘに存在しない場合は、関連するトラック内に一つ以上の関連するＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＧｒｏｕｐＥｎｔｒｙが存在する（このトラックはおそらく動的サイズ及び／又は位置を有する）。‘２ｄｃｃ’サンプルグループを定義するＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＧｒｏｕｐＥｎｔｒｙ（）は、二次元空間関係トラックグループ内のサブピクチャトラックからのサンプルの位置及びサイズを宣言することを可能にする。ｇｒｏｕｐｉｎｇ＿ｔｙｐｅが‘２ｄｃｃ’に等しいとき、ＳａｍｐｌｅＴｏＧｒｏｕｐＢｏｘのバージョン１が使用される。ｇｒｏｕｐｉｎｇ＿ｔｙｐｅ＿ｐａｒａｍｅｔｅｒの値は、対応する空間関係トラックグループのｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄと等しい。ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＧｒｏｕｐＥｎｔｒｙ（）は次のように定義される：
class SpatialRelationship2DGroupEntry () extends VisualSampleGroupEntry ('2dcc') {
unsigned int(16) object_x;
unsigned int(16) object_y;
unsigned int(16) object_width;
unsigned int(16) object_height;
}
ここで、ｏｂｊｅｃｔ＿ｘは、対応する空間関係トラックグループによって指定される座標系内のこのグループのサンプルの左上角の水平位置を指定する。位置値は、もしあれば、トラック幅及び高さによって引き起こされる黙示的なリサンプリングを適用する前の値であり、０～ｔｏｔａｌ＿ｗｉｄｔｈ－１の範囲内に含まれ、ｔｏｔａｌ＿ｗｉｄｔｈは、対応するＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘに含まれる場合、ｏｂｊｅｃｔ＿ｙは、対応する空間関係トラックグループによって指定される座標系内のこのグループのサンプルの左上角の垂直位置を指定する。位置値は、もしあれば、トラック幅と高さによって引き起こされる黙示的なリサンプリングを適用する前の値であり、０～ｔｏｔａｌ＿ｈｅｉｇｈｔ－１の範囲内に含まれ、ｔｏｔａｌ＿ｈｅｉｇｈｔは対応するＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘに含まれる場合、ｏｂｊｅｃｔ＿ｗｉｄｔｈは、対応する空間関係トラックグループによって指定された座標系内のこのグループのサンプルの幅を指定する。
位置値は、もしあれば、トラック幅と高さによって引き起こされる黙示的なリサンプリングを適用する前の値であり、１～ｔｏｔａｌ＿ｗｉｄｔｈの範囲内に含まれ、ｏｂｊｅｃｔ＿ｈｅｉｇｈｔは、対応する空間関係トラックグループによって指定される座標系内のこのグループのサンプルの高さを指定する。位置値は、もしあれば、トラック幅と高さによって引き起こされる黙示的なリサンプリングを適用する前の値であり、１～ｔｏｔａｌ＿ｈｅｉｇｈｔの範囲内に含まれる。‘２ｄｃｃ’トラックグループ内の各トラックのサンプルは、より大きな画像を生成するために、この同じグループ内の他のトラックからのサンプルで（同じ合成又は復号化時間で）空間的に合成され得る。パック化画像１３１の符号化（図１のステップ１４０）から生じる符号化ビットストリーム及びサブビットストリームに依存して、ファイル・フォーマットにおけるカプセル化のいくつかの変形が可能である。図２ａ及び図２ｂは、本発明の一実施形態によるファイル／セグメントカプセル化（図１の手段１５０で実施される）の例を示すブロック図を示す。
図２ａは、２Ｄビデオを複数のトラックに（手段１５０によって）カプセル化するためのステップを示す。ステップ２２００で、サーバは、符号化後の入力ビットストリームを単一又は複数のトラックとしてカプセル化するかどうかを決定する。単一トラックカプセル化がオンである場合、ビデオは、オプションで、どのＮＡＬユニットがどの領域に対応するかを示すＮＡＬユニットマッピングを用いて、単一トラックとしてカプセル化される。複数のトラックが作成させられなければならない場合（試験２２００「真」）、例えば、図１ａの手段１１２２によって実行される分割の場合、次にステップ２２２０において、ファイルのコンテンツクリエータは、合成トラックを追加することができる。合成トラックは、パーサ又はプレーヤのためのエントリポイント又は「メイン」又は「デフォルト」トラックを提供することを可能にする。例えば、合成トラックは、有効であること及びムービーでプレビューとして使用されていることを示す、トラックヘッダーにフラグ値のセットを有する。
合成トラックによって参照されるトラックは、クライアント又はプレーヤ又はユーザによる選択からこれらのトラックを非表示にするために、これらのフラグ値セットを有さなくてよい（ｔｒａｃｋ＿ｅｎａｂｌｅフラグ値を除く）。合成トラックがない場合、ステップ２２３０で、メディアファイルと、符号化後の各ビットストリーム又はサブビットストリームは、それ自体のトラックにカプセル化される。オプションステップは、オリジナルの分割領域よりも大きな領域を形成するために、ビットストリーム又はサブビットストリームを集めることによって、トラック数を減らすことで構成できる。カプセル化が合成トラックを提供する場合（テスト２２２０が「真」である）、２つのオプションは、サンプル再構成規則、すなわちメディアファイル内の黙示的又は明示的な再構成指示に対して可能である。黙示的な再構成（テスト２２４０が「真」、ブランチが「ＹＥＳ」）に対して、ステップ２２４１において、合成トラックは、ＩＳＯ／ＩＥＣ １４４９６－１５によって定義されるようにタイルベーストラック（例えば、「ｈｖｔ１」サンプルエントリを有するトラック）として提供される。
その後、各サブピクチャトラックは、ＩＳＯ／ＩＥＣ １４４９６－１５に規定されるように、ステップ２２４３でこのタイルベーストラックによりタイルトラックとしてカプセル化される。タイルトラックのための‘ｔｒｉｆ’記述子に加えて、各タイルトラックは、２Ｄ空間関係記述のための同じトラックグループの一部として宣言されてもよいことに留意されたい。合成トラックが、明示的な再構成のための抽出手段を有するトラックとして提供される場合（テスト２２４０が「偽」、ブランチが「ｎｏ」）、追加のトラックがメディアファイル内に作成される。この作成されたトラックは、ステップ２４４４で作成された各サブピクチャトラックを、例えば‘ｓｃａｌ’トラック参照タイプで参照する。合成トラックが提供されない場合（テスト２２２０が「偽」、ブランチが「ｎｏ」）、ステップ２２３０において、メディアのビデオ部分がサブピクチャトラックとしてカプセル化される。合成トラックが存在する場合であっても、サブピクチャトラックは、トラックグループ機構によってグループ化されてもよいことに留意されたい。最後に、ステップ２２５０において、空間的合成及びサブピクチャトラック間の関係のための記述が生成される。２Ｄ空間関係記述のためのトラックグループボックスは、オリジナルビデオソース内の各サブピクチャトラックの相対位置及びサイズを記述するために、各サブピクチャトラックに追加される。
本発明の一実施形態によれば、追加の空間情報が提供され得る。この追加情報は、図１２及び図１３を参照してより詳細に説明されるように、追加信号であってもよい。追加の情報は、メディアパーサ又はメディアプレーヤが、ディスプレイにビデオを再構成することを可能にする（図１ａ及び図１ｂの表示手段）。代替的には、ステップ２２５０で追加情報が提供されない場合、パーサは、ビットストリーム内の他のデータから情報を推測することができる。
図２ｂ：ステップ２００で、サーバは、いくつかの空間的関連ビデオビットストリーム（すなわち、空間的合成がより大きな画像を生成することができる、パック化画像の空間サブ部を表すこと）があるか、又は、複数のサブピクチャトラックとしてクライアントに公開され得る、動き制限されたタイル又は複数のビューのいずれかを表すビデオサブビットストリームを含むビデオビットストリームがあるかを判定する。符号化パック化画像は、それが単一のビデオビットストリームとして符号化されているため、複数のトラックとして公開されない、又はコンテンツクリエータが符号化パック化画像を複数のトラックとして公開したくない場合、次にビデオビットストリーム又はビデオサブビットストリームは、１つの単一のトラックにカプセル化される（ステップ２１０）。そうでない場合、ステップ２２０において、カプセル化されるべきメディアコンテンツが、動き制限されたタイルを表すビデオサブビットストリームから構成される場合が判定される。
ｙｅｓの場合、複数のタイルトラックの少なくとも１つの合成を表すために、少なくとも１つの合成トラックが提供される必要があり得る。合成は、完全なパック化画像、又は完全なパック化画像のサブ部のみを表すことができる。タイルトラックで合成トラックを使用することは、クライアント側でストリームの別々のレンダリング及び復号化を要求することを回避する。クライアントに公開されるべき可能な組み合わせの数は、コンテンツクリエータの選択に依存する。例えば、コンテンツクリエータは、現在のユーザのビューポートにより、異なる視覚的品質を有するタイルを組み合わせたい場合がある。このために、それは異なる視覚的品質のパック化画像を数回符号化し、視覚的品質に関してタイルの異なる組合せを含む完全なパック化画像を表すいくつかの合成トラックを提案することができる。ユーザのビューポートに依存する異なる品質でタイルを結合することにより、コンテンツクリエータはネットワーク資源の消費を低減することができる。
ステップ２２０において、合成トラックが提供されなければならないと判定される場合、次に、合成トラックに対して黙示的な再構成が使用されてよいか否かが判定される（ステップ２４０）。黙示的な再構成は、例えばＩＳＯ／ＩＥＣ １４４９６－１５ 第４版で定義されるように、タイルベース及びタイルトラックからのビットストリーム再構成を指す。それらがタイルトラックのサンプル中で参照するデータで合成トラックのサンプル中の抽出手段を置き換えることによって、タイルトラックのサンプルから合成トラックのサンプルを再構成するために、抽出手段のようなストリーム内構造を使用するのではなく、黙示的な再構成は、合成トラックとタイルトラックのサンプルをトラック参照の順序で連結することによって、合成トラックのサンプルを再構成することを可能にする（例えば、ＨＥＶＣの黙示的な再構成における‘ｓａｂｔ’トラック参照）。黙示的な再構成の使用は、使用のシナリオに依存する。このような場合、黙示的な再構成は不可能であり、抽出手段を有する明示的な再構成が選択されなければならない。
黙示的な再構成が可能である場合、タイルベーストラックが生成されて（ステップ２４１）、ビデオサブビットストリームは、独立して復号可能でないタイルトラックとして（例えば、ＨＥＶＣ‘ｈｖｔ１’トラックとして）カプセル化される。そうでない場合、抽出手段トラックが生成され（ステップ２４２）、ビデオサブビットストリームは、独立して復号可能なタイルトラックとして（例えば、ＨＥＶＣ‘ｈｖｃ１’又は‘ｈｅｖ１’トラックとして）カプセル化される。ステップ２２０に戻って、メディアコンテンツがタイルサブビットストリームを含まない又はコンテンツクリエータが合成トラックを作成して公開したくない場合、次に空間的に関連するビデオビットストリーム又はビデオサブビットストリーム（例えば、タイル又は複数のビュー）が、別々のサブピクチャトラックにカプセル化される（ステップ２３０）。このような特定の場合、タイルサブビットストリームがＨＥＶＣタイルの場合、それらはＨＥＶＣトラック‘ｈｖｃ１’又は‘ｈｅｖ１’トラックとしてカプセル化される。
ステップ２５０では、空間合成のための信号が、空間的に関連するビデオビットストリーム又はビデオサブビットストリームを一緒にグループ化するために追加される。空間合成信号は、前述のように、例えばＭＰＥＧ ＩＳＯＢＭＦＦ（ＩＳＯ／ＩＥＣ １４４９６－１２ 第７版 補正１）で定義されているように、同じグループに関連する全てのトラックに対して同じｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄを有する、タイプ‘２ｄｃｃ’のトラックグループのような、グループを合成するそれぞれのトラック（サブピクチャトラック、タイルトラック、合成トラック）に特有のＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘを定義することによって提供され得る。このトラックグループボックス‘２ｄｃｃ’は、合成内のトラックの相対的な２次元座標及び合成によって形成された画像の全体サイズを提供する。合成は、パック化画像全体又はパック化画像のサブ部のみを表すことができる。例えば、コンテンツクリエータは、パック化画像全体又はパック化画像のサブ部のみを構築することを可能にする、複数の合成トラックを公開したい場合がある。
代替的に、合成は、投影画像全体又は投影画像のサブ部のみを表すことができる。‘２ｄｃｃ’トラックグループ（ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ、ｓｏｕｒｃｅ＿ｉｄ、ｔｏｔａｌ＿ｗｉｄｔｈ、ｔｏｔａｌ＿ｈｅｉｇｈｔ、ｏｂｊｅｃｔ＿ｘ、ｏｂｊｅｃｔ＿ｙ、ｏｂｊｅｃｔ＿ｗｉｄｔｈ、ｏｂｊｅｃｔ＿ｈｅｉｇｈｔ）からのパラメータは、それらのトラックを表す適応セットの空間的関係を記述するために、ＤＡＳＨマニフェストで使用され得る、ＤＡＳＨ空間関係記述（ＳＲＤ）記述子（ＩＳＯ／ＩＥＣ ２３００９－１ 第３版で定義される）のパラメータに直接一致する。つまり、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄは、ＤＡＳＨ ＳＲＤ ｓｐａｔｉａｌ＿ｓｅｔ＿ｉｄパラメータと一致し、ｓｏｕｒｃｅ＿ｉｄはＤＡＳＨ ＳＲＤ ｓｏｕｒｃｅ＿ｉｄパラメータと一致する（存在しない場合、ＤＡＳＨ ＳＲＤで必須なので、デフォルト値「１」が使用され得る）。ｏｂｊｅｃｔ＿ｘ、ｏｂｊｅｃｔ＿ｙ、ｏｂｊｅｃｔ＿ｗｉｄｔｈ、ｏｂｊｅｃｔ＿ｈｅｉｇｈｔはＤＡＳＨ ＳＲＤパラメータｏｂｊｅｃｔ＿ｘ、ｏｂｊｅｃｔ＿ｙ、ｏｂｊｅｃｔ＿ｗｉｄｔｈ、ｏｂｊｅｃｔ＿ｈｅｉｇｈｔパラメータとそれぞれ一致し、及び関連するトラックグループからのｔｏｔａｌ＿ｗｉｄｔｈ及びｔｏｔａｌ＿ｈｅｉｇｈｔ（ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄを介して）は、ＤＡＳＨ ＳＲＤ ｔｏｔａｌ＿ｗｉｄｔｈ、ｔｏｔａｌ＿ｈｅｉｇｈｔに一致する。
代替として、合成トラックがある場合、空間合成信号は、この合成トラックによって黙示的に提供され得る。実際、合成トラックがタイルベーストラックである場合、タイルベーストラックは、タイプ‘ｓａｂｔ’のトラック参照を介してタイルトラックのセットを参照する。このタイルベーストラック及びタイルトラックのセットは、合成グループを形成する。同様に、合成トラックが抽出手段トラックである場合、抽出手段トラックは、タイプ‘ｓｃａｌ’のトラック参照を介してタイルトラックのセットを参照する。この抽出手段トラック及びタイルトラックのセットは、合成グループも形成する。両方の場合で、ＩＳＯ／ＩＥＣ １４４９６－１５ 第４版で定義されているように、合成内の各タイルトラックの相対的な２次元座標は、タイプ‘ｔｒｉｆ’のサンプルグループ化又は既定のサンプルグループ化を定義することにより提供され得る。
別の代替として、空間合成信号は、新しいエンティティグループを定義することによって提供され得る。エンティティグループは、項目又はトラックのグループである。エンティティグループは、ＭｅｔａＢｏｘ内のＧｒｏｕｐｓＬｉｓｔＢｏｘ内に示される。トラックを参照するエンティティグループは、ファイルレベルＭｅｔａＢｏｘのＧｒｏｕｐｓＬｉｓｔＢｏｘ又はムービーレベルＭｅｔａＢｏｘのＧｒｏｕｐｓＬｉｓｔＢｏｘで指定されてもよい。ＧｒｏｕｐＬｉｓｔＢｏｘ（‘ｇｒｐｌ’）は、定義されたグループ化タイプを示す４文字コードが関連付けられた、それぞれがＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘと呼ばれる一連の完全なボックスを含む。ＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘは次のように定義される。
aligned(8) class EntityToGroupBox(grouping_type, version, flags)
extends FullBox(grouping_type, version, flags) {
unsigned int(32) group_id;
unsigned int(32) num_entities_in_group;
for(i=0; i＜num_entities_in_group; i++)
unsigned int(32) entity_id;
// 残りのデータは特定のgrouping_typeに対して指定されてよい
}
通常、ｇｒｏｕｐ＿ｉｄはグループのｉｄを提供し、ｅｎｔｉｔｙ＿ｉｄのセットはエンティティグループに関連するトラックのｔｒａｃｋ＿ＩＤを提供する。ｅｎｔｉｔｙ＿ｉｄのセットに続いて、特定のｇｒｏｕｐｉｎｇ＿ｔｙｐｅの追加データを定義することによって、ＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘの定義を拡張することは可能である。一実施形態によれば、（エンティティグループ合成のための）‘ｅｇｃｏ’に等しい、例えばｇｒｏｕｐｉｎｇ＿ｔｙｐｅを有する新しいＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘは、２次元空間関連ビデオビットストリーム又はビデオサブビットストリームの合成を記述するように定義され得る。エンティティｉｄのセットは、グループを合成するトラック（サブピクチャ、タイルトラック、合成トラック）のｔｒａｃｋ＿ＩＤのセットを含む。合成によって形成される画像の全体的なサイズは、この新しいｇｒｏｕｐｉｎｇ＿ｔｙｐｅ‘ｅｇｃｏ’に関連付けられた追加データの一部として提供され得る。
ＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘ（‘ｅｇｃｏ’）は次のように定義される。
aligned(8) class EntityToGroupBox(‘egco’, version, flags)
extends FullBox(‘egco’, version, flags) {
unsigned int(32) group_id;
unsigned int(32) num_entities_in_group;
for(i=0; i＜num_entities_in_group; i++)
unsigned int(32) entity_id;
unsigned int(16) total_width;
unsigned int(16) total_height;
unsigned int(32) source_id;
}
ここで、ｔｏｔａｌ＿ｗｉｄｔｈとｔｏｔａｌ＿ｈｅｉｇｈｔは、合成のサイズを提供し、オプションのｓｏｕｒｃｅ＿ｉｄパラメータは、ソースのための一意の識別子を提供し、ソースに関連付けられた座標系（つまり、原点（０，０）とそれらの軸の方向）を黙示的に定義する。
ＤＡＳＨと比較すると、ｇｒｏｕｐ＿ｉｄはＤＡＳＨ ＳＲＤ ｓｐａｔｉａｌ＿ｓｅｔ＿ｉｄパラメータと一致し、ｓｏｕｒｃｅ＿ｉｄはＤＡＳＨ ＳＲＤ ｓｏｕｒｃｅ＿ｉｄパラメータと一致し、及び、ｔｏｔａｌ＿ｗｉｄｔｈとｔｏｔａｌ＿ｈｅｉｇｈｔはＤＡＳＨ ＳＲＤ ｔｏｔａｌ＿ｗｉｄｔｈパラメータとｔｏｔａｌ＿ｈｅｉｇｈｔパラメータとそれぞれ一致する。合成のためにＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘにｓｏｕｒｃｅ＿ｉｄが存在しない場合、デフォルト値「１」がＤＡＳＨ ＭＰＤへマッピングするために使用される。ＭＰＤが複数のメディアコンテンツを記述する場合、次に１つのメディアコンテンツを別のメディアコンテンツから区別することを可能にするｓｏｕｒｃｅ＿ｉｄ値を処理して割り当てるのは、ＭＰＤ生成手段次第である。タイプ‘ｅｇｃｏ’のエンティティグループ化によって定義される合成内の各トラックの相対的な２次元座標は、以下に定義されるようにタイプ（‘ｅｇｃｏ’）のトラックグループを定義することによって提供され得る。
aligned(8) class SubPictureRegionBox extends FullBox('sprg',0,0) {
unsigned int(16) object_x;
unsigned int(16) object_y;
unsigned int(16) object_width;
unsigned int(16) object_height;
}
aligned(8) class SpatialRelationship2DDescriptionBox extends TrackGroupTypeBox('2dcc')
{
// track_group_idはTrackGroupTypeBoxから継承される;
SubPictureRegionBox ();
}
ここで、ｏｂｊｅｃｔ＿ｘ、ｏｂｊｅｃｔ＿ｙ、ｏｂｊｅｃｔ＿ｗｉｄｔｈ、ｏｂｊｅｃｔ＿ｈｅｉｇｈｔは、合成内の各トラックの相対的な２次元座標を提供する。タイプ‘ｅｇｃｏ’の所定のＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘは、ｇｒｏｕｐ＿ｉｄがｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄと等しいように定義することによって、対応するＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘに関連付けられる。
あるいは、‘ｅｇｃｏ’タイプのエンティティグループ化によって定義された合成内の各トラックの相対的な二次元座標は、ＩＳＯ／ＩＥＣ １４４９６－１５ 第４版で定義されるように、各タイルトラックにタイプ‘ｔｒｉｆ’のサンプルグループ化又はデフォルトサンプルグループを定義することによって、提供され得る。代替として、相対的な２次元座標は、グループに関連する各タイルトラック内のＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙ内に位置する新しい汎用完全ボックス２ＤＣｏｏｒｄｉｎａｔｅＦｏｒＥｎｔｉｔｙＧｒｏｕｐＢｏｘ（‘２ｄｃｏ’）として定義され得る。
aligned(8) class 2DCoordinateForEntityGroupBox extends FullBox('2dco', version, flags)
{
unsigned int(32) entity_group_id;
unsigned int(16) object_x;
unsigned int(16) object_y;
unsigned int(16) object_width;
unsigned int(16) object_height;
}
ここで、ｅｎｔｉｔｙ＿ｇｒｏｕｐ＿ｉｄはグループを定義する関連するＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘ（‘ｅｇｃｏ’）の識別子を提供し、ｏｂｊｅｃｔ＿ｘとｏｂｊｅｃｔ＿ｙは合成内のこのトラックのサンプルの左上角の水平位置と垂直位置を提供し、及び、ｏｂｊｅｃｔ＿ｗｉｄｔｈとｏｂｊｅｃｔ＿ｈｅｉｇｈｔは合成内のこのトラックのサンプルの幅と高さを提供する。
代替として、この新しい汎用ボックス２ＤＣｏｏｒｄｉｎａｔｅＦｏｒＥｎｔｉｔｙＧｒｏｕｐＢｏｘ（‘２ｄｃｏ’）は、以下のように新しいサンプルグループとして定義され得る。
class 2DCoordinateForEntityGroupBox extends VisualSampleGroupEntry('2dco')
{
unsigned int(32) entity_group_id;
unsigned int(16) object_x;
unsigned int(16) object_y;
unsigned int(16) object_width;
unsigned int(16) object_height;
}
図２ｂに戻ると、ステップ２６０で、トラックについて領域的パッキング情報が、ビデオビットストリーム又はビデオサブビットストリームのカプセル化を記述するメタデータに追加される。このステップは、サブピクチャトラックがさらに領域に再配置されない場合のオプションである。領域的パッキングは、パック化領域内のルマサンプル位置を、対応する投影領域のルマサンプル位置に再マッピングするための情報を提供する。ＭＰＥＧ ＯＭＡＦでは、領域的パッキングは、以下のデータ構造に従って記述され得る。
aligned(8) class RegionWisePackingStruct() {
unsigned int(1) constituent_picture_matching_flag;
bit(7) reserved = 0;
unsigned int(8) num_regions;
unsigned int(32) proj_picture_width;
unsigned int(32) proj_picture_height;
unsigned int(16) packed_picture_width;
unsigned int(16) packed_picture_height;
for (i = 0; i ＜ num_regions; i++) {
bit(3) reserved = 0;
unsigned int(1) guard_band_flag[i];
unsigned int(4) packing_type[i];
if (packing_type[i] == 0) {
RectRegionPacking(i);
if (guard_band_flag[i])
GuardBand(i);
}
}
}
ここで、ｐｒｏｊ＿ｐｉｃｔｕｒｅ＿ｗｉｄｔｈ及びｐｒｏｊ＿ｐｉｃｔｕｒｅ＿ｈｅｉｇｈｔは、相対投影ピクチャサンプルユニットにおける投影ピクチャの幅及び高さをそれぞれ指定し、ｐａｃｋｅｄ＿ｐｉｃｔｕｒｅ＿ｗｉｄｔｈ及びｐａｃｋｅｄ＿ｐｉｃｔｕｒｅ＿ｈｅｉｇｈｔは、相対パック化ピクチャサンプルユニットにおけるパック化ピクチャの幅及び高さをそれぞれ指定し、ｎｕｍ＿ｒｅｇｉｏｎは、ｃｏｎｓｔｉｔｕｅｎｔ＿ｐｉｃｔｕｒｅ＿ｍａｔｃｈｉｎｇ＿ｆｌａｇが０に等しい場合のパック化領域である。ｃｏｎｓｔｉｔｕｅｎｔ＿ｐｉｃｔｕｒｅ＿ｍａｔｃｈｉｎｇ＿ｆｌａｇが１に等しい場合、パック化領域の総数は２＊ｎｕｍ＿ｒｅｇｉｏｎに等しく、ＲｅｃｔＲｅｇｉｏｎＰａｃｋｉｎｇ（ｉ）及びＧｕａｒｄＢａｎｄ（ｉ）内の情報は、投影ピクチャ及びパック化ピクチャの各ステレオ構成ピクチャに適用し、ＲｅｃｔＲｅｇｉｏｎＰａｃｋｉｎｇ（ｉ）は、ｉ番目のパック化領域とｉ番目の投影領域との間の領域的パッキングを指定し（すなわち、ｘ、ｙ、幅、高さ座標を、パック化領域からオプションの変換（回転、ミラーリング）を伴う投影領域に変換する）、ＧｕａｒｄＢａｎｄ（ｉ）は、ｉ番目のパック化領域について、もしあれば、ガードバンドを指定する。
本発明の実施形態によれば、領域的パッキング情報がサブピクチャトラック内で定義されるとき、この構造は、完了投影ピクチャを参照することによってサブピクチャトラックのパッキングのみを記述する。したがって、ｐａｃｋｅｄ＿ｐｉｃｔｕｒｅ＿ｗｉｄｔｈ及びｐａｃｋｅｄ＿ｐｉｃｔｕｒｅ＿ｈｅｉｇｈｔは、サブピクチャトラックの幅及び高さに等しい。オプションとして、ステップ２７０で、トラック及びトラックの合成のためのコンテンツカバレッジ情報が、ビデオビットストリーム又はビデオサブビットストリームのカプセル化を記述するメタデータに追加される。このステップはオプションで、ＩＳＯ／ＩＥＣ ２３０９０－２で定義されるようにＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘを使用する。全方向ビデオについて、ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘは、コンテンツによってカバーされる球上の領域に情報を提供する。コンテンツの性質は、このボックスのコンテナに依存する。ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘ‘２ｄｃｃ’に存在する場合、コンテンツは、同じサブピクチャ合成トラックグループに属する全てのトラックによって表されるコンテンツ全体を指し、これらのトラックから構成される合成ピクチャは、コンテンツ全体のパック化ピクチャと呼ばれる。トラックのサンプルエントリ内に存在する場合、コンテンツは、このトラック自体によって表されるコンテンツを参照し、このトラック内のサンプルのピクチャは、コンテンツ全体のパック化ピクチャと呼ばれる。トラックに対してＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎ Ｂｏｘが存在しない場合、それは、コンテンツが球全体をカバーすることを示す。
全方向性ビデオについて、投影全方向性ビデオボックス（‘ｐｏｖｄ’）は、ＭＰＥＧ ＯＭＡＦによって定義され、トラック内のＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙ内に位置する中間ボックスであることに留意されたい。さらに、全方向性ビデオについて、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘトラックグループボックス（‘２ｄｃｃ’）は、以下のように拡張され得る。
aligned(8) class SpatialRelationship2DDescriptionBox extends TrackGroupTypeBox('2dcc')
{
// track_group_idはTrackGroupTypeBoxから継承される;
SpatialRelationship2DSourceBox(); // 必須, 最初でなければならない
SubPictureRegionBox (); // オプション
CoverageInformationBox(); // オプション
}
第２の実施形態として、トラックカバレッジ情報及び合成カバレッジ情報は、ローカル及びグローバル指示を区別するためにフラグ値を有する単一の共通ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘを使用して信号伝達され得る。ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘはＩＳＯＢＭＦＦ ＦｕｌｌＢｏｘであるため、トラックとグローバルカバレッジとの間の区別は、ボックスのフラグパラメータによって表され得る。この第２の実施形態によれば、ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎ Ｂｏｘは、以下のように定義される。
ボックスタイプ: 'covi'
コンテナ: 投影全方向性ビデオボックス(‘povd’)
必須: No
数量: ０以上
aligned(8) class CoverageInformationBox extends FullBox('covi', 0, 0) {
ContentCoverageStruct()
}
ボックスの構造は、ボックスの複数のインスタンスが、ローカル及び合成カバレッジ情報が同じトラックに定義されなければならない場合に定義され得ることを除いて、前の実施形態とほぼ同じである。次に、ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘは、コンテンツによってカバーされる球上の領域の情報を提供するものとして定義される。コンテンツの性質はフラグパラメータにより与えられる。カバレッジ情報フラグのためのデフォルト値は０で、このボックスはコンテンツ全体のカバレッジを記述することを意味する。このトラックが２次元空間関係トラックグループに属する場合、コンテンツ全体は、同じ２次元空間関係トラックグループに属する全てのトラックによって表されるコンテンツを指し、これらのトラックから構成される合成ピクチャは、コンテンツ全体のパック化又は投影ピクチャと呼ばれる。そうでない場合、コンテンツ全体は、このトラック自体によって表されるコンテンツを参照し、このトラック内のサンプルのピクチャは、コンテンツ全体のパック化又は投影ピクチャと呼ばれる。
カバレッジ情報フラグのための値が１である場合、このボックスは、このトラックによって表されるコンテンツのパック化又は投影ピクチャによってカバーされる球状領域を記述する。このボックスの不在は、コンテンツが球全体をカバーすることを示す。さらに、新たなフラグ値は、次のように定義される。Ｃｏｖｅｒａｇｅ＿ｌｏｃａｌは、カバレッジ情報がボックスを含むトラックにローカルであることを示す。フラグ値は０ｘ０００００１である。デフォルトにより、この値はセットではない。図２ｂに戻ると、ステップ２８０で、仮想現実メディアコンテンツが実際に立体視仮想現実メディアコンテンツであるか、すなわち、左ビュー及び右ビューを含むかがチェックされる。コンテンツが平面視のみである場合、プロセスは直接ステップ２９０に進む。コンテンツが立体視である場合、ステップ２８５で、立体視信号がカプセル化に追加される。
立体視コンテンツについて、従来、左と右のビューシーケンスの両方が立体視カメラから取得され、合成タイプに従ってビデオシーケンス又は２つのビデオシーケンスに合成される。立体視コンテンツの２つの異なるビューを表す２つのフレームを１つの単一フレームに結合するためのプロセスは、フレームパッキングと呼ばれる（図１のステップ１２５参照）。フレームパッキングは、ステレオペアを形成する２つのビューを単一のフレームにパッキングすることからなる。いくつかのよく知られた、使用されているフレームパッキング方式が存在する、つまり並行、上下、フレーム順次、垂直ラインインタリーブ型など。例えば、ＭＰＥＧアプリケーションフォーマットＩＳＯ／ＩＥＣ ２３０００－１１ 第１版（「立体視映像アプリケーションフォーマット」）又はＩＳＯ／ＩＥＣ ２３００１－８ 第２版（「コーディング非依存コードポイント（ＣＩＣＰ）」）は、これらの方式のいくつかを定義する。フレームパッキングは、例えば、ＩＳＯ／ＩＥＣ ２３００１－８ 第２版（「ＣＩＣＰ」）で定義された値６を有するＶｉｄｅｏＦｒａｍｅＰａｃｋｉｎｇＴｙｐｅのような、それぞれのビューを別々のフレームに保持することからなってもよい
例えば、さらに本明細書によれば、値３は、各復号化フレームが２つの構成ビューの対応するフレームの並行パッキング構成を含むことを信号伝達し、値４は、各復号化フレームが２つの構成ビューの対応するフレームの上下パッキング構成を含むことを信号伝達する。トラックが立体視メディアデータを含むかを信号伝達するために、ＳｔｅｒｅｏＶｉｄｅｏＢｏｘがトラック内のＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙに定義される。図２のステップ２５０に戻ると、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘは、以下の表に提供されるように、ビデオトラック間の空間的関係を表すために、動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ）プロトコル（ＩＳＯ／ＩＥＣ ２３００９－１第３版）で定義されるように、空間関係記述子‘ＳＲＤ’の定義と一致するように定義される。
Figure 0007472220000001
‘２ｄｃｃ’ＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘを有するｔｒａｃｋ＿ｇｒｏｕｐｉｎｇ＿ｔｙｐｅは、トラックがビデオの空間部分に対応するトラックのグループに属することを示す。ｔｒａｃｋ＿ｇｒｏｕｐ＿ｔｙｐｅ‘２ｄｃｃ’のＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘ内のｓｏｕｒｃｅ＿ｉｄの同値を有するトラックは、同じソース（つまり、同じ原点（０，０）、同じそれらの方向の軸）から生じるものとしてマッピングされる。より正確には、同じｓｏｕｒｃｅ＿ｉｄを有する２つのトラックグループからの完了合成ピクチャ(ｔｏｔａｌ＿ｗｉｄｔｈ及びｔｏｔａｌ＿ｈｅｉｇｈｔのサイズを有する）は、知覚的又は視覚的に等価である（例えば、２つの異なる解像度又は２つの異なる品質で同じ視覚的コンテンツを表す２つの合成ピクチャ）。ｓｏｕｒｃｅ＿ｉｄパラメータの追加は、２セットのサブピクチャトラックが共通の基準を共有しているか（同じｓｏｕｒｃｅ＿ｉｄ値）否か（異なるｓｏｕｒｃｅ＿ｉｄ値）を表すことを可能にする。
２セットのサブピクチャトラックが同じ基準を共有する表示は、レンダリングのために異なるセットのサブピクチャトラックを組み合わせるための可能性として解釈されてよい（しかし、これはアプリケーションに任される、つまり、カプセル化ファイルの表示からＩＳＯＢＭＦＦパーサは、可能な代替についてのアプリケーションに通知できる）。２Ｄ空間関係のためのトラックグループの記述におけるｓｏｕｒｃｅ＿ｉｄパラメータの不在は、サブピクチャトラックの２つのセット間の相対位置が未知であるか又は不特定であることを示す。‘２ｄｃｃ’ｔｒａｃｋ＿ｇｒｏｕｐｉｎｇ＿ｔｙｐｅ及び同じｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄを有するＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘに属する全てのサブピクチャトラックは、存在する場合、同じｓｏｕｒｃｅ＿ｉｄを有さなければならない。
‘２ｄｃｃ’ｔｒａｃｋ＿ｇｒｏｕｐｉｎｇ＿ｔｙｐｅ及び異なるｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄを有するＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘに属するトラックは、互換性があり、それらが同じｓｏｕｒｃｅ＿ｉｄを有する場合、一緒に組み合わされ得る。ｓｏｕｒｃｅ＿ｉｄが存在する場合、‘２ｄｃｃ’ｔｒａｃｋ＿ｇｒｏｕｐｉｎｇ＿ｔｙｐｅ及び異なるｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄを有するＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘに属するトラックは互換性がなく、それらがそれらのｓｏｕｒｃｅ＿ｉｄのための異なる値を有する場合、一緒に組み合わせられ得ない。‘２ｄｃｃ’ｔｒａｃｋ＿ｇｒｏｕｐｉｎｇ＿ｔｙｐｅを有するＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘの記述において、ｓｏｕｒｃｅ＿ｉｄパラメータが存在しない場合、これは‘２ｄｃｃ’ｔｒａｃｋ＿ｇｒｏｕｐｉｎｇ＿ｔｙｐｅを有する異なるトラックグループからのサブピクチャトラックは組み合わせられ得ないことを示唆しない。そのような組合せに対して可能性を示すための代替であってもよい。例えば、全方向性ビデオの場合、２つのサブピクチャトラックは、このソースを表す２次元投影ピクチャが視覚的に等価でない（例えば、それらが異なる投影フォーマット又は異なるビューポート向きを有する）場合、同じソースのサブ部を表さない。そのような場合、それらは、２Ｄ空間関係に対してトラックグループのそれらの各記述において、ｓｏｕｒｃｅ＿ｉｄの異なる値で信号伝達されてもよい。
代替として、この後のルールは、異なるｓｏｕｒｃｅ＿ｉｄを有する‘２ｄｃｃ’トラックグループからのサブピクチャトラックをグループ化する代替グループが存在する場合であっても、適用する。それは、これらのサブピクチャトラックが代替であることを意味する（例えば、それらは、異なる符号化フォーマット、例えば、ＡＶＣ及びＨＥＶＣを有する）が、それらは、異なる符号化フォーマットを有するサブピクチャトラックと組み合わされることが意図されていない。メディアコンテンツが、個別に符号化及びカプセル化するためにサブ部に分割される場合、生じるサブピクチャトラックは、図２ａ又は２ｂのステップ２２５０又は２５０の参照によって説明されるように、追加の記述情報から利益を得ることができる。実際、コンテンツ生成の観点から、コンテンツを空間サブ部に分割することは、クライアントの表示又は処理能力への適応を提供する。したがって、メディアは、キャプチャ画像１０１１又は１２２を多かれ少なかれカバーするサブピクチャトラックの代替セットとして提供されてもよい。例えば、サーバは、サブピクチャトラックを、１つのトラックグループに属するサブピクチャトラックのセットがソース画像全体をカバーするか否かを示す情報と共にカプセル化することができる。
さらに、ソース画像全体がカバーされる場合、サブピクチャトラックのセットがソース画像全体を正確にカバーするかどうか又はいくつかのオーバーラップがあるかどうかを知ることが有利である。むしろ、ソース画像全体がカバーされていないかを知ることは有利である。この場合、どの部分が正確にカバーされるか及びホールがあるかどうか、及びそれらがどこに位置しているかを知ることは有利である。前記情報は、不足部分を検索するために、クライアントがメディアファイル又はメディア記述ファイルを検索することを可能にする。このような情報をクライアント側に有することは、プレーヤが、それらの容量又はアプリケーションのニーズ、又はユーザの選択に従って最良のサブピクチャトラックを選択するのに役立つ。次に、本発明の第１の態様は、ソース画像に関するサブピクチャトラックのセットに関する表示を有する２Ｄ空間関係記述のためのトラックグループを改善することを提案する。
図１１は、本発明の第１の態様の一実施形態によれば、サブピクチャトラックとソース画像のセット間の関係の一実施形態を示す。最初に、キャプチャ画像１２００（例えば、図１ａ又は図１ｂの参照により１０１１又は１２２）は、タイル又は矩形領域又は空間サブ部（図１１の８つの領域）に分割される。この大きな画像上で、対象の領域は、レンダリング、アクセス、又は送信のための潜在的な関心を伴って識別される（１２０１）。次に、カプセル化は、キャプチャ画像１２００の記述を異なるトラックグループ１２０２及び１２０３として生成する。１２０２は、トラックグループ１２０２に関連付けられた情報１２０４によって示されるように、一緒に合成された場合に完全ピクチャ１２００をもたらすサブピクチャトラックのセットに対応する。同様に、他のトラックグループ１２０３は、類似の情報１２０４を有するが、このトラックグループ内のサブピクチャトラックの合成から再構成画像を示す今回が、ソース画像１２００の部分的ビューをもたらす。
この例では、対象領域１２０１へのアクセスがトラックの組合せとして提供されるので、それは実際にカプセル化の選択である。次いで、クライアントは、対象領域のみをレンダリングすることを決定するときに、処理すべきサブピクチャトラックのリストを判定する。全てのサブピクチャトラックを処理する必要はない。オプションで、トラックグループが完全な再構成をもたらさない場合、トラックグループ記述は、再構成がなぜ部分的であるかを説明するための追加情報１２０５を提供することができる。ＩＳＯＢＭＦＦでカプセル化する場合、情報１２０４及び１２０５は、図１２に示されるように提供され得る。図１２は、再構成に関連する追加情報を有する２Ｄ空間関係のためのトラックグループの例を示す。下位互換性を保つために、グループプロパティを提供する部分に対して、‘２ｄｃｃ’ボックス（１３００）の新しいバージョンが提案され、‘２ｄｓｒ’ボックス１３０１は、サブピクチャトラックのセット上の情報１３０３を示す、つまり、それは「完全なセット」に対応するか否か。「１」に設定された「完全なセット」は、このトラックグループ内のサブピクチャトラックからの再構成が完全なソース画像に対応することを意味する。「０」に設定された「完全なセット」は、このトラックグループ内のサブピクチャトラックからの再構成が完全なソース画像に対応しないことを意味する。後者の場合、追加情報が提供されてもよい（１３０４）。
例えば、フラグセットは、ギャップが存在するかどうか、又はいくつかの重複があるかどうかを示すことができる。一方又は他方が存在する場合、‘ｓｐｒｇ’構造を使用して、ギャップ又は重複のリストが矩形領域のリストとして提供されてもよい。全方向性コンテンツの場合、サブピクチャトラックのセットが完全なセットではないという指示は、パーサによって、例えば、領域的パッキング記述を探すことによって、及び存在する場合にはこの記述を解析することによって、メディアファイルをさらに検査するための命令として解釈され得る。例えば、１３０４において重複指示が存在する場合、パーサは、重複がサブピクチャトラック内のガードバンドの存在によるものであるかどうかを判定することができる。ＯＭＡＦでは、これは、領域的パッキングボックス‘ｒｗｐｋ’を検査し、ｇｕａｒｄ＿ｂａｎｄ＿ｆｌａｇパラメータをチェックすることによって決定され得る。下位互換性が問題でない場合、次に追加指示は、２Ｄ空間関係のトラックグループの１つの一部に追加パラメータとして直接挿入されてもよい。例えば、ｃｏｍｐｌｅｔｅ＿ｓｅｔ上の指示は、次のように、バージョンとフラグの両方の値に０を使用して提供されてもよい。
aligned(8) class SpatialRelationship2DSourceBox extends FullBox('2dsr', 0, 0) {
unsigned int(32) total_width;
unsigned int(32) total_height;
unsigned int(32) source_id;
unsigned int(2) reference_picture;
unsigned int(1) complete_set;
unsigned int(29) reserved;

}
ここで、ｔｏｔａｌ＿ｗｉｄｔｈ、ｔｏｔａｌ＿ｈｅｉｇｈｔ、及びｓｏｕｒｃｅ＿ｉｄのセマンティクは未変更のままであり、ｒｅｆｅｒｅｎｃｅ＿ｐｉｃｔｕｒｅ(ここでは２ビットで表される）は、このトラックグループのサブピクチャトラックに分割されたソースイメージを指定する。値「０」を取る場合、このトラックグループ内のサブピクチャトラックの位置は、キャプチャピクチャの座標系で表されることを示す（これはデフォルト値である）。値「１」を取る場合、このトラックグループ内のサブピクチャトラックの位置は、投影ピクチャの座標系で表されることを示す。値２を取る場合、このトラックグループ内のサブピクチャトラックの位置は、フレームパック化ピクチャの座標系で表されることを示す。値３を取る場合、このトラックグループ内のサブピクチャトラックの位置は、パック化ピクチャの座標系で表されることを示す。
上記の例では、再構成に関連する追加情報（ｃｏｍｐｌｅｔｅ＿ｓｅｔパラメータ）がｓｏｕｒｃｅ＿ｉｄ及び参照ピクチャと混在している。ｓｏｕｒｃｅ＿ｉｄ上に情報が存在しない場合又は参照ピクチャ上に指示が提供されていない場合、同様にそれは提供されてよい。
aligned(8) class SpatialRelationship2DSourceBox extends FullBox('2dsr', 0, 0) {
unsigned int(32) total_width;
unsigned int(32) total_height;
unsigned int(1) complete_set;
unsigned int(30) reserved;

}
代替実施形態では、より多くのビットが、再構成に関連する追加情報に割り当てられ得る。例えば、１つの代わりに２ビットを使用することは、トラックグループ内のサブピクチャのセットから再構築が完了再構築をもたらすかどうかをメディアプレーヤ又ＩＳＯＢＭＦＦ パーサに示すことができ（例えば、２ビットが値「００」、小数で０を取る場合）、又はそれが全体ピクチャのサブセットをもたらす場合、すなわち再構築が１つ以上のギャップを含む（例えば、２ビットが値「０１」、小数で１を取る場合）、又はそれが全体ピクチャのスーパーセットをもたらす場合、すなわち再構築が重複である部分を含む（例えば、２ビットが値「１０」、小数で２を取る場合）。２ビットが値「１１」、少数で３を取る場合、再構築がギャップと重複の両方を含む。再構成に関連する情報を記述するために、単純な指示以上が使用される場合、再構成を記述するパラメータは、トラックグループ記述の中に専用記述子に編成されてもよい。
aligned(8) class SpatialRelationship2DDescriptionBox extends TrackGroupTypeBox('2dcc') {
// track_group_idはTrackGroupTypeBoxから継承される;
SpatialRelationship2DSourceBox(); // 必須, 最初でなければならない
SubPictureRegionBox (); // オプション
ReconstructionInfoBox(); // オプション
}
ここで、ＲｅｃｏｎｓｔｒｕｃｔｉｏｎＩｎｆｏＢｏｘ（）は、再構成の以下の情報を提供し、サブピクチャトラックのセットは、完全ソース、サブセット（ギャップ）、又はスーパーセット（重複）に対応する。この値により、例えば、重複の場合と同様に、ギャップがどこにあるかの記述が提供される。ギャップ及び重複の両方があってもよいことに留意されたい。
オプションで、パラメータは、トラックグループ内の予想されるサブピクチャトラックの数を示す。この情報は、ファイル内に存在する場合、再構成のために予想されるサブピクチャトラックの数を提供する。例えば、１０に設定される場合、クライアントが、トラックグループに１０のサブピクチャトラックを有さないメディアファイルをストリーミング又はダウンロードしている間に、それはサンプルの再構成が開始できない。時間に沿って予想されるサブピクチャトラックの動的な数を処理するために、この情報は、２Ｄ空間関係‘２ｄｃｃ’についてサンプルグループ内に提供されてもよく、１つのメディアフラグメントから別のものへ更新されてよい。再構成のために予想されるサブピクチャトラックの予想される数の指示は、例えば、２Ｄ空間関係のためのトラックグループの場合には、‘２ｄｓｒ’ボックスにおいて、グループのプロパティ内に提供されてもよい。サブピクチャトラックからの再構成に関連する指示は、ｓｏｕｒｃｅ＿ｉｎｄｉｃａｔｉｏｎ(‘２ｄｓｒ’のｓｏｕｒｃｅ＿ｉｄパラメータ）と、参照ピクチャ信号と、又は本発明の第２の態様で以下に記載される同等のグループ信号と組み合わせられ得る。それは、２Ｄ又は３６０°メディアに適用する。
３６０°メディアに適用される場合、再構成に関連する追加情報は、２Ｄ空間関係についてトラックグループの記述に存在する場合、参照ピクチャ指示に関連する。それは、ｃｏｍｐｌｅｔｅ＿ｓｅｔパラメータのようなバイナリ情報であってもよい。それは、２ビット値パラメータであってもよい。それは、サブピクチャトラックの組合せから生じる再構成されたピクチャによってカバーされる投影ピクチャ１２２の割合を示すパラメータであってもよい。参照ピクチャが示されていない場合、再構成に関連する追加情報は、投影ピクチャ１２２が完全にカバーされているか、又は部分的にカバーされている（バイナリ値「０１」）バイナリ値００で、パック化ピクチャが完全にカバーされているか、又は部分的にカバーされている（値「１１」）バイナリ値「１０」で、示すことができる。最初のビットの値により、パーサは、領域的パッキングが投影ピクチャに適用されるかどうかを判定し、最後のビットが部分的な再構成を示すときに、メディアファイルをさらに分析することを決定することができる。この追加の分析は、再構成ピクチャ内にどの部分が存在するか、又は欠落しているかを判定するために使用され得る。最後のビットが完全な再構成を示している場合、再構成が完了していると判定するためにファイルをさらに解析又は分析する必要はない。
３６０°ビデオの場合の参照ピクチャ又は投影ピクチャ又は２Ｄビデオの場合のソースピクチャの割合では、オプションとして、トラックグループ１３０２内のトラックプロパティに対応する部分において、追加のパラメータ（図１２には示されていない）が、この割合にトラックの寄与を提供することができる。例えば、サブピクチャの所定のグループに対して、サブピクチャトラックが再構成に顕著な寄与を有する場合、それは、ダウンロードし、最初にそれをストリーミングし、プレーヤがプログレッシブ再構成を実施するときに、最初にそれを再構成することを開始するための良好な指示であってもよい。図４ａは、２Ｄ空間関係記述のためのいくつかのトラックグループを含むサブピクチャトラックカプセル化の例を示す。
図４ａは、２Ｄ空間関係記述のためのいくつかのトラックグループを含むサブピクチャトラックカプセル化の例を示す。この例は、２Ｄ又は全方向ビデオの両方に適用する。この例では、トラック＃１～＃４は、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄが１０と同じで、かつ、ｓｏｕｒｃｅ＿ｉｄが１と同じ、タイプ‘２ｄｃｃ’のトラックグループ４１に属している。トラック＃５から＃８は、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄは２０と同じであるが、同じｓｏｕｒｃｅ＿ｉｄ４００は１に等しい、タイプ‘２ｄｃｃ’の異なるトラックグループ４２に属する。ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄが３０に等しく、異なるｓｏｕｒｃｅ＿ｉｄ４０１が２に等しいタイプ‘２ｄｃｃ’の３番目のトラックグループ４３もある。さらに、複数の別のグループ４４～４７がある。同じ代替グループに属する全てのトラック（つまり、それらのトラックヘッダボックス‘ｔｋｈｄ’に同じａｌｔｅｒｎａｔｅ＿ｇｒｏｕｐ識別を有する）は、代替データを含むトラックのグループ又はコレクションを指定する。代替データは、代替ビットレート、コーデック、言語、パケットサイズなどに対応してもよい。これらの識別属性は、トラック選択ボックスに示されてもよい。代替グループ内の１つのトラックのみが、いつでも再生又はストリーミングされるべきである。この例では、トラック＃１、＃５、及び＃９は、識別子が１００に等しい同じ代替グループ４４に属する。例えば、トラック＃１とトラック＃５は、品質の異なる別のトラックであり、トラック＃９はコーデックの観点からトラック＃１とトラック＃５の別のトラックである。トラック＃２、＃６及び＃１０は、２００と等しい識別子を有する同じ代替グループ４５に属する、例えば、トラック＃２とトラック＃６は異なる解像度を有する代替トラックであり、トラック＃１０はフレームレートなどの点でトラック＃２とトラック＃６への代替トラックである。
反対に、トラックグループ４３からのサブピクチャトラックは、それらが同じｓｏｕｒｃｅ＿ｉｄを有していないので、それらが同じ代替グループに属することができるにもかかわらず、トラックグループ４１及び４２からの任意のサブピクチャトラックと結合されることは意図されていない。ｓｏｕｒｃｅ＿ｉｄパラメータは、次に、同じ空間合成の一部となることができる、サブピクチャトラック上のプレーヤに指示を与える。所定の空間位置に対して、一つのサブピクチャトラックは同じ所定の空間位置で他のサブピクチャトラックと視覚的に同等であると見なされ得る。これは、メディアコンテンツが複数のトラックに提供される場合の（サブピクチャ）トラック選択に有用である。さらに、それは選択されたサブピクチャトラックにより、動的適応（品質／ビットレート又は解像度）が同じ空間合成を表示することを可能にする。
図４ｂは、本発明の第２の態様によれば、グループが同等のグループであることを示すための代替方法を示す。一実施形態によれば、それは、トラックグループの記述内に直接存在し、トラックヘッダボックス内の代替グループ又はフラグにもはや依存しない指示を含むことができる。この代替は、ｓｏｕｒｃｅ＿ｉｄが存在しない場合、又はメディアファイル内にトラック選択ボックスが存在しない場合に有用であり、プレーヤは、表示するための画像を合成する際、代替トラックを判定する。この実施形態では、ここでは‘ＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘ’と呼ばれるトラックグループ化に関する記述データと、特に、例えば‘ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤｓｏｕｒｃｅＢｏｘ’４１０などの２Ｄ空間関係記述のための記述データは、図４ｂの参照４１１によって示されるように、既知のソリューションと比較して補正される。ここで、ｅｑｕｉｖａｌｅｎｔ＿ｇｒｏｕｐ＿ＩＤ［］と呼ばれる追加のパラメータ４１３は、このトラックグループに対する同等のトラックグループのリストを提供する。それは、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ(例えばＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘで宣言されたｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄなど）のリストとして記述される。
図４ｂは、２Ｄ空間関係記述のためのＴｒａｃｋＧｒｏｕｐｉｎｇＴｙｐｅＢｏｘの初期バージョンとの下位互換性を可能にする。好ましくは、同等のグループ信号のための追加パラメータ４１３は、ボックスの補正バージョン（図示せず）が使用されるか、又は既知のＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘにおける場合のみ、タイプ‘２ｄｃｃ’のＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘのフラグパラメータ（図示４１４）値の値に条件付きで存在する。例えば、２４ビット整数フラグ４１４は、定義される以下の値を有する。「ｔｒａｃｋ＿ｇｒｏｕｐ＿ｅｑｕｉｖａｌｅｎｃｅ」は、このトラックグループは同等のトラックグループを有することを示し、このトラックグループと同等の一つにおいて、同じプロパティを有するトラックは、交換可能又は切り替え可能であることを意味する。フラグ値は、例えば、０ｘ０００００２（予約された２４ビット値、トラックグループタイプボックスのフラグパラメータのための他の予約された値と競合しない）である。上述したように、ｆｌａｇｓパラメータのために予約された値を使用する代わりに、同等のグループの指示は、以下のように、トラックグループ、すなわち、ＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘの記述を提供する構造体の新しいバージョンに条件付けされてもよい。
aligned(8) class SpatialRelationship2DDescriptionBox extends TrackGroupTypeBox('2dcc', version, 0)
{
// track_group_idは、TrackGroupTypeBoxから継承される;
SpatialRelationship2DSourceBox(); // 必須, 最初でなければならない
SubPictureRegionBox (); // オプション
if (version == 1) {
GroupEquivalenceBox();
}
}
ＧｒｏｕｐＥｑｕｉｖａｌｅｎｃｅＢｏｘがＦｕｌｌＢｏｘとして定義されている場合
aligned(8) class GroupEquivalenceBox extends TrackGroupTypeBox('grev')
{
// track_group_idは、TrackGroupTypeBoxから継承される;
unsigned int (32) track_group_IDs[];
}
ここで、ｔｒａｃｋ＿ｇｒｏｕｐ＿ＩＤｓパラメータは、このトラックグループのトラックと「同等」のトラックを含むトラックグループを識別するｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値のリストを提供する。上記の例では、同等のトラックグループのリストが、トラックグループタイプボックス新しいバージョンに新しいボックスとして提供される。あるいは、それは‘２ｄｓｒ’ボックスの新しいパラメータとして、より一般的には、以下のようにグループプロパティを提供するボックスに提供されてよい。
aligned(8) class SpatialRelationship2DSourceBox
extends FullBox('2dsr', version, 0) {
unsigned int(32) total_width;
unsigned int(32) total_height;
unsigned int(32) source_id;
if (version == 1) {
unsigned int (32) equivalent_group_ID[]
}
}
バージョンパラメータを使用する代わりに、ｆｌａｇｓパラメータが使用される場合、２Ｄ空間関係のためのグループプロパティ‘２ｄｓｒ’ボックス４１１の記述は、次のようになる。
aligned(8) class SpatialRelationship2DSourceBox
extends FullBox('2dsr', version, flags) {
unsigned int(32) total_width;
unsigned int(32) total_height;
unsigned int(32) source_id;
if ( (flags&0x02) == 1) {
unsigned int (32) equivalent_group_ID[]
}
}
同等のトラックグループの宣言は、‘２ｄｃｃ’トラックグループタイプに限定されない。実際、トラックグループが、同じｔｒａｃｋ＿ｇｒｏｕｐ＿ｔｙｐｅを有する他のトラックグループ内の他のトラックと互換可能であるトラックを含むとすぐに、同等のトラックグループのリストがトラックグループ宣言内に提供され得る。同等のトラックグループ内の各トラックのマッチングは、トラックプロパティを比較することによって計算される。例えば、２Ｄ空間関係のためのトラックグループの場合、同等トラックグループの１つで別のトラックと同じｏｂｊｅｃｔ＿ｘ、ｏｂｊｅｃｔ＿ｙ、ｏｂｊｅｃｔ＿ｗｉｄｔｈ、ｏｂｊｅｃｔ＿ｈｅｉｇｈｔを有する任意のトラックは、交換可能なトラックとして見なされ得る。それは、例えば、ＨＥＶＣ及び独立したタイルで符号化する場合、品質又はビットレートのような異なる符号化構成において同じタイル（同じ位置）に対応するサブピクチャトラックとなり得る。所定のソースを再構成するために一緒に合成され得る独立したビットストリーム（例えば、ＡＶＣ、ＨＥＶＣなど）からのサブピクチャトラックに対応することもできる。
同等のグループの指示のための代替実施形態として、等価性は、それのトラックグループに関してトラックプロパティ内で信号伝達され得る。実際、トラックグループ、すなわちＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘの記述は、グループプロパティを宣言する構造体（ＩＳＯＢＭＦＦボックス又はＦｕｌｌＢｏｘ)(例示的な‘２ｄｃｃ’トラックグループタイプ４１１のための‘２ｄｓｒ’）と、トラックグループ内のトラックプロパティを宣言する１つ以上のボックス（例示的な‘２ｄｃｃ’トラックグループタイプ４１２のための‘ｓｐｒｇ’）を含むことができる。図４ｂに示す実施形態は、グループプロパティ４１１のためのボックス内の同等なトラックグループの宣言を提案し、したがって、それはパーサが各同等のトラックグループ内でトラック間のマッチングを計算することを要求する。この演算を回避する代替実施形態は、トラックグループ内のトラックプロパティ（例えば４１２）の一部として、トラックグループの各トラックのための等価性を宣言することからなる。例えば、２Ｄ空間関係のためのトラックグループで使用される場合、‘ｓｐｒｇ’ボックス４１２は、次のようになる。
aligned(8) class SubPictureRegionBox extends FullBox('sprg',version,0) {
unsigned int(16) object_x;
unsigned int(16) object_y;
unsigned int(16) object_width;
unsigned int(16) object_height;
if (version == 1) {
unsigned int(32) equivalent_track_IDs[];
}
}
ここで、ｅｑｕｉｖａｌｅｎｔ＿ｔｒａｃｋ＿ＩＤｓパラメータは、このトラックグループに関連する現在のトラックと同等と見なされ得るトラックのための、ｔｒａｃｋ＿ＩＤ(トラックヘッダボックスで宣言されたトラック識別子用）のリストを提供する。ｖｅｒｓｉｏｎパラメータを使用する代わりに、フラグパラメータが使用される場合、‘ｓｐｒｇ’ボックスは次のようになる。
aligned(8) class SubPictureRegionBox extends FullBox('sprg',version,flags) {
unsigned int(16) object_x;
unsigned int(16) object_y;
unsigned int(16) object_width;
unsigned int(16) object_height;
if ( (flags & 0x02) == 1) {
unsigned int(32) equivalent_track_IDs[];
}
}
各トラックグループ宣言内に同等のトラックグループのリストを有することは、バイトの観点でコストがかかる場合がある。実際、トラックグループ宣言は、トラックグループの各トラックで発生する。たくさんの同等のグループがある場合、トラックグループＩＤ記述のリストが、次に、各同等のトラックグループの各トラックで繰り返される。よりコンパクトな記述を提供する実施形態は、トラックグループ間の等価性を単一の場所で定義することからなる。図５は、同等のトラックグループの表示が、記述のコンパクト性のためにトラック宣言の外側に提供される別の実施形態を示す。実際、同等のトラックグループの表示がトラックレベルで、例えばトラックグループの記述で提供されるとき、それはトラックグループの各トラックに複製される。この宣言をメディアファイルの最上位に有することは、例えば‘ｍｏｏｖ’ボックスの下で、単一の宣言及びパーサによるこの情報への迅速なアクセスを可能にする。図５において、カプセル化メディアファイル４２０は、トラックグループタイプ及びｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ(＃１１、＃１２及び＃１３）をそれぞれ有する４２１、４２２、４２３の３つのトラックグループを含む。各トラックグループは、それらのｔｒａｃｋ＿ＩＤ で識別される多少のトラックを含む。トラックグループ４２１及び４２２は、４２５で表されるように同等である。専用ボックス４２４は、この等価性を宣言するために使用される。
トラックグループのリストがＩＳＯＢＭＦＦのエンティティグループ化機構（つまり、ＧｒｏｕｐＬｉｓｔＢｏｘにおいて）を使用して宣言されている場合、同等のトラックグループの表示は、例えば追加の記述子としてＧｒｏｕｐＬｉｓｔＢｏｘ内のエンティティグループ化機構と共に宣言される。図５の例では、ＧｒｏｕｐＥｑｕｉｖａｌｅｎｃｅＢｏｘとして提供される４２４は、リスト、つまりこれらのトラックグループにおいて各トラックが等価であることをパーサ又はプレーヤに示すための＃１１と＃１２を宣言する。トラック＃１及びトラック＃４は、＃２及び＃６、＃８を有する＃３及び＃７及び＃４と共に等価である。オプションで、ＧｒｏｕｐＥｑｕｉｖａｌｅｎｃｅＢｏｘは、等価のタイプを提供する追加のフィールド又はパラメータを含むことができる。このパラメータのためにあり得る値は、例えば、「ｂｉｔｓｔｒｅａｍ＿ｅｑｕｉｖａｌｅｎｃｅ」は、パーサがサンプルの再構築（黙示的又は明示的のいずれか）を行っているときに、トラックが交換可能であることを意味するような事前定義された又は登録された値のリストである。
等価のタイプを提供する追加フィールド又はパラメータのための値の別の例は、例えば「ｄｉｓｐｌａｙ＿ｅｑｕｉｖａｌｅｎｃｅ」がこれらのトラックのデコードから生じるピクチャ又はサブピクチャが視覚的に等価であることを意味するような別の事前定義された又は登録された値である。例えば、サブピクチャトラックの場合、トラックグループ＃１１からの１つのトラックは、分割された初期画像を合成及び再構成するために、トラックグループ＃１２（又はその逆）において他のトラックと共に使用されてよい。あるいは、ＧｒｏｕｐＥｑｕｉｖａｌｅｎｃｅＢｏｘとして同等のトラックグループ４２４の表示を記述する代わりに、同等のトラックグループ４２４の表示は、１つのＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘとして提供されてよい。例えば、構造体４２４は、トラックグループの等価性のために専用のｇｒｏｕｐｉｎｇ＿ｔｙｐｅが‘ｔｇｅｑ’に等しいＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘであり、グループ内の２つのエンティティ、つまりトラックグループ＃１１と＃１２（ｅｎｔｉｔｙ＿ｉｄ値として）を示している。ＩＳＯ／ＩＥＣ ２３００８－１２からの既存の‘ｅｑｉｖ’を使用する代わりに、専用のグループ化タイプが好ましい。これは、ＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘにおいて既存の‘ｅｑｉｖ’グループ化タイプが、トラックのサンプルに適用される場合、サンプルが同じトラック内で互いに等価であり、潜在的に別のトラック又はＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘにリストされたアイテムのサンプルと等価であることを示すためである。
この後者の方法は、トラックグループが各トラックのＴｒａｃｋＧｒｏｕｐＢｏｘ‘ｔｒｇｒ’で宣言されている場合にも適用する。トラックグループ等価性４２４のための記述子又は構造は、メディアファイルの‘メタ’ボックスの下に格納されてもよい。例えば、それはｍｏｏｖ／ｍｅｔａボックスの下、又は、ファイルの最上位のメタボックス内であってよい。トラックグループ等価性４２４のための記述子又は構造は、トラックレベルで等価性を提供してもよく、この場合、グループ化タイプ値は、トラック等価性信号のための別の予約コード、すなわち‘ｔｒｅｖ’である。次に、構造体４２４内に提供されるｅｎｔｉｔｙ＿ＩＤは、ｔｒａｃｋ＿ＩＤｓである。これは、宣言するための関連付けを追跡するためのトラックがあるのと、同数のトラック等価信号（例えば‘ｔｒｅｖ’）のためのｇｒｏｕｐｉｎｇ＿ｔｙｐｅを有するＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘ（ｅｓ）を必要とする。図５の例では、ｔｒａｃｋ＃１とｔｒａｃｋ＃５を等価トラックとして、ｔｒａｃｋ＃２とｔｒａｃｋ＃６用に１つ、ｔｒａｃｋ＃３とｔｒａｃｋ＃７用に１つ、ｔｒａｃｋ＃８を有するｔｒａｃｋ＃４用に最後の１つを宣言するために、ｇｒｏｕｐｉｎｇ＿ｔｙｐｅ‘ｔｒｅｖ’を有する１つのＥｎｔｉｔｙＴｏＧｒｏｕｐであってよい。
図４ｂに示す実施形態の別の代替として、等価トラックグループ４２４の表示は、既存のトラック基準機構を使用する。しかしながら、利用可能で、かつ「等価」表示専用のトラック参照タイプはない。次にそれは、２つのトラック間で使用される場合、トラックがビットストリーム（ビットストリーム連結又はサンプル再構成プロセス中の交換可能なサブビットストリーム）に関して等価又は切り替え可能又はディスプレイに関して等価（すなわち、同じコンテンツを表示するが、潜在的に異なる品質又は解像度）であることをそれぞれ示す、新しいトラック参照タイプ‘ｂｅｑｔ’及び‘ｄｅｑｔ’を定義することが提案される。前者は、圧縮領域における組合せ／トラック置換を可能にするのに対し、後者は、復号後のみ、すなわち画素領域において、組合せ／トラック置換を可能にする。ＩＳＯＢＭＦＦで定義されるようにトラック参照機構は、トラックグループ間の記述された関連性にも拡張され得る。ボックスのＩＳＯＢＭＦＦ階層内の現在のトラック参照ボックスは、‘ｔｒａｋ’ボックスの下でのみ宣言され得る。本発明の一実施形態では、（グループ内の）トラックのグループがトラックの別のグループに直接関連付けることができるように、トラックグループボックス内のトラック参照も同様に可能にすることが提案される。
ボックスタイプ: 'tref'
コンテナ: TrackBox or TrackGroupBox
必須: No
数量: ０又は１
以下のセマンティクスで、ＴｒａｃｋＧｒｏｕｐＢｏｘで使用される場合、ｔｒａｃｋ＿ＩＤｓは、参照トラックグループのトラックグループ識別子（ＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘからのｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ）を提供する整数の配列である。参照タイプの使用のために可能な値のリストは、次のように‘ｅｑｉｖ’値で拡張される。‘ｅｑｉｖ’、つまりこのトラックグループは、それぞれが参照されたトラックグループ内の等価トラックを有するトラックを含む。参照されるトラックグループからのどのトラックがこのトラックグループにおいて所定のトラックに対応するかを判定するために、トラックグループのタイプとトラックグループ内のトラックプロパティに依存して、パーサ次第である。例えば、サブピクチャトラックの場合、同じ位置で同じサイズのトラックは等価性あると見なされ得る。図６を参照して以下に説明するように、‘ｔｒｇｒ’ボックス６０１及び６０２は、トラックグループレベルでこの‘ｔｒｅｆ’を介して関連付けられ得る。等価トラックグループの宣言のための代替実施形態に関して、トラック参照タイプは、記述に関してより正確であってよい。単一の‘ｅｑｉｖ’トラック参照タイプを定義する代わりに、２つの新しいトラック参照タイプが使用され得る、つまりビットストリーム等価性（例えば‘ｂｅｑｖ’）用に１つ、表示等価性（例えば‘ｄｅｑｖ’）用にもう１つ。
図１３は、図１３ａ及び図１３ｂを含み、サブピクチャトラックの代替セットからの明示的な再構成を示す。本発明は、図１３ａの１４００又は図１３ｂの１４５０のような抽出手段トラックで使用するために、抽出手段ＮＡＬユニットの新しい種類を提案する。ＩＳＯ／ＩＥＣ １４４９６－１５は、ＳＶＣ、ＭＶＣ、ＨＥＶＣなどの異なる圧縮フォーマットのための抽出手段を定義する。ＨＥＶＣ抽出手段が、参照されるトラックから、又は構造体内で提供されるデータからサンプルを再構成するために特定の構造体を導入する。我々は、ＨＥＶＣ及びＬ－ＨＥＶＣ抽出手段（又は抽出手段内の構造体の概念を再利用する任意の圧縮フォーマット）を拡張するＳａｍｐｌｅＣｏｎｓｔｒｕｃｔｏｒＷｉｔｈＡｌｔｅｒｎａｔｉｖｅｓと呼ぶことができる新しい構造体の種類を以下の通り提案する。
class aligned(8) Extractor () {
NALUnitHeader();
do {
unsigned int(8) constructor_type;
if( constructor_type == 0 )
SampleConstructor();
else if( constructor_type == 2 )
InlineConstructor();

else if ( constructor_type == 4)
SampleConstructorWithAlternatives();
} while( !EndOfNALUnit() )
}
Ｅｘｔｒａｃｔｏｒ：：ｃｏｎｓｔｒｕｃｔｏｒ＿ｔｙｐｅのセマンティクは次のように更新される。ｃｏｎｓｔｒｕｃｔｏｒ＿ｔｙｐｅは、次の構造体を指定する。ＳａｍｐｌｅＣｏｎｓｔｒｕｃｔｏｒ、ＩｎｌｉｎｅＣｏｎｓｔｒｕｃｔｏｒ、ＳａｍｐｌｅＣｏｎｓｔｒｕｃｔｏｒＷｉｔｈＡｌｔｅｒｎａｔｉｖｅｓは、それぞれ０、２、４に等しいｃｏｎｓｔｒｕｃｔｏｒ＿ｔｙｐｅに対応する。ｃｏｎｓｔｒｕｃｔｏｒ＿ｔｙｐｅの他の値は予約されている。新しい抽出手段を定義する新しいセクションは、この新しい構造体に対して、ファイル／セグメントカプセル化手段１５０（例えば、ｍｐ４ライタ）とファイル／セグメントカプセル化解除手段１７１（例えば、ｍｐ４リーダ）との間で相互運用可能になるように、ＩＳＯ／ＩＥＣ １４４９６－１５の別紙に追加される。代替を有する新しいサンプル構造体は、次のように定義される。
構文
class aligned(8) SampleConstructorWithAlternatives () {
unsigned int(8) ref_index; // トラック又はtrack_groupインデックスであってよい
signed int(8) sample_offset;
unsigned int((lengthSizeMinusOne+1)*8) data_offset;
unsigned int((lengthSizeMinusOne+1)*8) data_length;
}
以下のセマンティクスで
ｒｅｆ＿ｉｎｄｅｘは、トラック又はデータを抽出するためのトラックを含むトラックグループを見つけるための使用に、‘ｓｃａｌ’タイプのトラック参照インデックス（又は１４０１や１４５１のようなビットストリーム等価性の専用トラック参照タイプ）を指定する。
ｓａｍｐｌｅ＿ｏｆｆｓｅｔ：Ａ．３．３の中で指定される通り。
ｄａｔａ＿ｏｆｆｓｅｔ：コピーするための参照サンプル内の最初のバイトのオフセット。抽出がそのサンプル内のデータの最初のバイトから始まる場合、オフセットは値０を取る。
ｄａｔａ＿ｌｅｎｇｔｈ:ＤＣＯＲ３のＡ．７．４．１．２で指定される通り。特定の構造体を有するこのような抽出手段は、図２ａ、ステップ２２４２又は図２ｂのステップ２４２からのカプセル化ステップで使用され得る。
図１４は、例えばＩＳＯＢＭＦＦパーサを用いた、本発明によるファイル／セグメントカプセル化解除手段１７１による抽出手段解像度を示す。サンプルを再構成する間、カプセル化解除手段は、ファイルのメディア部分からＮＡＬユニットを読み込む。ステップ１５００で、それはＮＡＬユニットタイプをチェックする。それが、抽出手段のためのＮＡＬＵタイプ（テスト１５０１ 真）に対応する場合、それは１５０２のｒｅｆ＿ｉｎｄｅｘパラメータを取得する。ｒｅｆ＿ｉｎｄｅｘがｔｒａｃｋ＿ＩＤを解決する場合（ｔｅｓｔ１５０３ 真）、ＩＳＯＢＭＦＦパーサは、構造体及びサンプル記述情報で与えられたｓａｍｐｌｅ＿ｏｆｆｓｅｔを潜在的に考慮する、抽出手段によって参照される１５０４内の参照されるサンプルを識別する。次にそれは、それを解析から生じる１５０７で再構成ビットストリームに補正するため、及び、復号化手段１７２に提供するために、１５０５でＮＡＬユニットを読み込み、１５０６でＮＡＬユニットペイロードを抽出する。
ｒｅｆ＿ｉｎｄｅｘがトラックグループ_ｉｄ(１５０３ 偽）を判定する場合、図１３ａのトラック選択によって示されるように、対応するトラックグループ内の最も適切なトラックを選択することは、ＩＳＯＢＭＦＦパーサ次第である。これはステップ１５０８で行われる。デフォルトの動作は、それのトラックグループの１つで宣言されているトラックグループＩＤを有するファイル内の最初のトラックを選択することである。トラックグループ等価性の表示が、区別する属性の表示を含む場合（例えば、トラック選択ボックス内のような属性リストを再利用）、この情報は、参照されているｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄを有するトラックグループに関連するトラックのリスト内の１つのトラックを選択するために、メディアプレーヤによって、使用され得る。いったんｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄが、ｔｒａｃｋ＿ＩＤとして変換されると、ＩＳＯＢＭＦＦパーサはステップ１５０４～１５０８に従い、最後までＮＡＬユニットの処理を継続する。ｔｒａｃｋ＿ＩＤとｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄの間の潜在的な競合を回避するために、それは、この構造体を含むメディアファイルが、ｔｒａｃｋ＿ＩＤ、ｔｒａｃｋ＿ｇｒｏｕｐ＿ＩＤ、ＥｎｔｉｔｙＴｏＧｒｏｕｐ：：ｇｒｏｕｐ＿ｉｄが一意の識別子であることを示すブランド、互換性のあるブランドのそれらのリストに含めることが推奨される。
メモ：ブランドの上記の要件は、(ｆｌａｇｓ ＆ １）が真であるかどうかをチェックするために全てのトラックグループを調査するよりも簡単である。この新しい抽出手段は、‘ｓｃａｌ’トラック参照を再利用することができるが、これはＩＳＯ／ＩＥＣ １４４９６ Ｐａｒｔ－１５のいくつかの部分の補正を必要とする。おそらく、‘ｓｃａｌ’の代わりに「代替を有する明示的空間再構成」（‘ｅｓｒａ’、１４０１及び１４５１内のような）を示す専用トラック参照を有することは、特定の抽出手段の使用を示す利益を有する。図１３ｂは、‘２ｄｃｃ’及び‘ａｌｔｅ’トラックグループの両方を定義するよりも、交換可能な、併合可能な、又は切り替え可能なサブピクチャトラックの説明のためのよりコンパクトなソリューション（図１３ａよりも）を提案する。図１３ｂは、その間にトラックの等価性を記録するために、空間的関係記述のためにトラックグループの利益を取る方法を示す。そのために、‘２ｄｃｃ’トラックグループに関連するように示される各サブピクチャトラックは、サブセットに関連するようにも示される。次に、同じサブセット内のトラックは、ＩＳＯＢＭＦＦパーサによるビットストリーム連結中に使用され得る代替、交換可能、又は切り替え可能なビットストリームと見なされる。サブセットは、特定のＳａｍｐｌｅＣｏｎｓｔｒｕｃｔｏｒＷｉｔｈＡｌｔｅｒｎａｔｉｖｅｓ(ＩＤ＃１００のトラック）内でｒｅｆ＿ｉｎｄｅｘとして使用され得る一意の識別子によって識別される。サブセット識別子は、‘２ｄｓｒ’ボックスでパラメータとして宣言され得る。ｓｕｂｓｅｔ＿ｉｄｅｎｔｉｆｉｅｒの使用は、‘ａｌｔｅ’トラックの宣言がサブピクチャトラック毎に２４バイトを費やす、サブピクチャトラック毎に４バイトを費やす。さらに、これは解析するためのトラックグループの数を減らす。
図１３ｂの実施形態では、２Ｄ空間関係グループ（‘２ｄｓｒ’ボックス）のプロパティの記述は、以下のように、サブセットの宣言をサポートするように拡張される。
aligned(8) class SpatialRelationship2DSourceBox
extends FullBox('2dsr', 0, 0) {
unsigned int(32) total_width;
unsigned int(32) total_height;
unsigned int(32) source_id;
unsigned int (32) subset_id;
}
ここで、ｓｕｂｓｅｔ＿ｉｄは、同じ空間位置でサブピクチャトラックのセットのための識別子であり、ビットストリームに関して等価又は切り替え可能である。これは、ビットストリーム連結中に、サブセット内の同等のトラックのいずれか１つの、あるサンプルのためのバイトが、同じサブセット内の任意の他の同等のトラックの同じサンプルのためのバイトの代わりに使用されてよい。あるいは、ｓｕｂｓｅｔ＿ｉｄは、例えば‘２ｄｃｃ’ｔｒａｃｋ ｇｒｏｕｐｉｎｇ＿ｔｙｐｅの場合の‘ｓｐｒｇ’ボックスである、トラックグループ内のトラックのプロパティを記述するパラメータのセットにおいて定義されてよい。
図１３ｂのコンパクトな記述を使用する場合、ＳａｍｐｌｅＣｏｎｓｔｒｕｃｔｏｒＷｉｔｈＡｌｔｅｒｎａｔｉｖｅｓ１４５２及び１４５３のｒｅｆ＿ｉｎｄｅｘのセマンティックは、サブセット識別子のサブピクチャサブセットを参照することを可能とするよう、以下のように変更される。ｒｅｆ＿ｉｎｄｅｘは、トラック、トラックグループ、又はデータを抽出するトラックを含むトラックグループのサブセットを見つけるための使用に、‘ｓｃａｌ’タイプ（又は１４０１又は１４５１のような‘ｅｓｒａ’）のトラック参照のインデックスを指定する。ｒｅｆ＿ｉｎｄｅｘがトラックグループｉｄ又はトラックグループのｓｕｂｓｅｔ＿ｉｄを判定する場合、トラックグループの対応するトラックグループ又はサブセットで最も適切なトラックを選択することは、パーサ又はプレーヤ次第である。デフォルトの動作は、トラックグループＩＤ又はｓｕｂｓｅｔ＿ｉｄを有するファイル内の最初のトラックを選択することである。ｔｒａｃｋ＿ＩＤ、ｓｕｂｓｅｔ＿ｉｄ、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄの間の潜在的な競合を回避するために、この構造体を含むメディアファイルは、ｔｒａｃｋ＿ＩＤ、ｔｒａｃｋ＿ｇｒｏｕｐ＿ＩＤ、ＥｎｔｉｔｙＴｏＧｒｏｕｐ：：ｇｒｏｕｐ＿ｉｄ、及びｓｕｂｓｅｔ＿ｉｄが一意の識別子であることを示すブランド、互換性のあるブランドのそれらのリストを含めることが推奨される。
同じ機構は、黙示的な再構成、すなわち、再構成規則がトラックレベルで定義され、抽出手段を有するサンプルレベルでそれ以上でない場合に拡張され得る。「代替を伴う黙示的再構成」のための特定のトラック参照タイプが、定義される（例えば、‘ｉｓｒａ’）。同じタイルベーストラックが、再構成用の代替タイルトラックを有する場合、この特定のトラック参照は、タイルベーストラックをトラックグループＩＤ又は代替タイルトラックを記述するｓｕｂｓｅｔ＿ｉｄに関連付けるために使用される。次に、このようなファイルを処理するパーサは、ｔｒａｃｋ＿ｒｅｆｅｒｅｎｃｅをｔｒａｃｋ ｇｒｏｕｐ＿ｉｄ又はｓｕｂｓｅｔ＿ｉｄへｔｒａｃｋ＿ＩＤに変換する中間ステップを有する。それは、参照されているｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ又はｓｕｂｓｅｔ＿ｉｄ又は代替のサブピクチャトラックに関連する追加プロパティ（例えば‘ｓｐｒｇ’ボックスのような、トラックグループ内のトラックプロパティで直接記述されている属性を区別するような）に基づいた選択を有することが発見された最初のトラックの選択であってよい。
図６は、本発明の実施形態による、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤｄｅｓｃｒｉｐｔｉｏｎＢｏｘ及びグループ等価性６０３の指示の使用の第２の例を示す。同じビデオソース６００（例えば、同じ投影ビデオソース）が、品質（＠ｑｕａｌｉｔｙ１及び＠ｑｕａｌｉｔｙ２）に関して、２つの代替版を生成するために使用される。２つのサブピクチャトラックのセットがある、高品質（品質１）６１０用の１つ及び低品質（品質２）６２０用の１つ。対応するサブピクチャトラックは、図６の右部（‘ｔｒａｋ’ボックス階層６１１及び６２１内）のように記述され得る。両方のトラックグループは、同じｓｏｕｒｃｅ＿ｉｄと、各サブピクチャトラックセットの解像度に対応する同じｔｏｔａｌ＿ｗｉｄｔｈとｔｏｔａｌ＿ｈｅｉｇｈｔを有する。サブピクチャトラック座標（ｏｂｊｅｃｔ＿ｘ、ｏｂｊｅｃｔ＿ｙ、ｏｂｊｅｃｔ＿ｗｉｄｔｈ、ｏｂｊｅｃｔ＿ｈｅｉｇｈｔ）は、それらの各トラックグループ合成内のサブピクチャトラックの空間的関係又は位置を記述する。再度、両方のトラックグループは同じソース＿ｉｄを有し、これはそれらが、同じトラックグループからのサブピクチャトラックだけでなく、第２トラックグループ６０２からのサブピクチャトラックをそれらの各構成でそれらの各位置に関して組み合わせられ得る（ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄが２０に等しい）第１トラックグループ６０１からの同じソースとサブピクチャトラック（ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄが１０に等しい）を表すことを意味する。
この例によれば、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄが１０と等しいトラックグループ６０１によって表される合成ピクチャは、専用のトラックレファレンス６０３で示されるように別のグループ６０２から１つのサブピクチャを選択することで合成され得る。２次元（２Ｄ）ビデオコンテンツとは反対に、ＯＭＡＦメディアコンテンツは、球の内側表面に向かって外向きに見た球の中心からのユーザのビューを示す全方向性メディアコンテンツを表す。次いで、この３６０°メディアコンテンツは、ビデオ投影フォーマットを適用することによって２次元平面に投影される。次に、オプションで、投影ピクチャからパック化領域に領域を再編成するように、領域的パッキングが適用される。３６０°のメディアコンテンツは、魚眼レンズ（広角カメラレンズ）を用いてキャプチャされたいくつかの円形画像によって表されてもよい。従って、ＯＭＡＦの文脈において、２Ｄピクチャ（サブピクチャトラックの再構成から生じる）は、投影ピクチャ又はパック化ピクチャのいずれかであってもよく、サブピクチャトラックは、異なる種類のコンテンツを含んでもよい。
投影ピクチャのサブ部（パッキングなし）、フレームパック化ピクチャのサブ部、例えば、コンテンツが立体視の場合、投影及びパック化ピクチャのサブ部、又は魚眼コード化ピクチャのサブ部。本発明の第３の態様によれば、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤｄｅｓｃｒｉｐｔｉｏｎＢｏｘの定義は、ＯＭＡＦメディアコンテンツを含むサブピクチャトラックのサイズ及び位置座標が、投影ピクチャに、パック化ピクチャに、又は別のピクチャに対して相対的であるかどうかを示すために改良される。第３の態様は、第１及び第２の態様の両方と組み合わせられ得る。一実施形態では、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤｄｅｓｃｒｉｐｔｉｏｎＢｏｘは、ＯＭＡＦメディアコンテンツを含むサブピクチャトラックのサイズ及び位置座標が常にパック化ピクチャに対して相対的であるように定義される。パッキングがない場合、パック化ピクチャは投影ピクチャに等しい。
別の実施形態では、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤｄｅｓｃｒｉｐｔｉｏｎＢｏｘは、ＯＭＡＦメディアコンテンツを含むサブピクチャトラックのサイズ及び位置座標が、キャプチャステップ１１０と符号化ステップ１４０との間の処理ステップにおいて、投影ピクチャ又はパック化ピクチャ又は任意の中間ピクチャに対して相対的であるように定義される。特に、全方向性メディア（ＯＭＡＦ）用のアプリケーションフォーマットの場合、２Ｄ空間関係で表現される位置及びサイズが、投影又はパック化ピクチャを参照するかどうかは明確ではない。一実施形態では、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤｄｅｓｃｒｉｐｔｉｏｎＢｏｘは、常にパック化ピクチャに対して相対的である。パッキングがない場合、パック化ピクチャは投影ピクチャと同じである。別の実施形態では、好ましいアプローチは、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤｄｅｓｃｒｉｐｔｉｏｎＢｏｘが常に投影画像に対して相対的であることを定義することである。シーンのワイドビューに対応する符号化メディアデータをカプセル化するための方法は、いくつかの実施形態では、以下のステップを含むことができる。シーンのワイドビューから投影ピクチャを得ることと、得られた投影ピクチャを少なくとも１つのパック化ピクチャにパッキングすることと、少なくとも１つのパック化ピクチャを少なくとも１つのサブピクチャに分割することと、少なくとも１つのサブピクチャを複数のトラックに符号化することと、符号化されたトラックに関連する記述メタデータを生成することを含み、記述メタデータは、トラック内で符号化された少なくとも１つのサブピクチャと少なくとも１つの投影ピクチャとの間の空間的関係を示す、各トラックに関連する情報の項目を含む、ことを特徴とする方法。
したがって、参照ピクチャの特定の信号は必要とされない。参照ピクチャは、サブピクチャがパック化ピクチャを分割することにより得られる場合であっても、投影ピクチャとなるように定義される。シーンのワイドビューに対応する符号化メディアデータをカプセル化するための方法は、いくつかの実施形態では、以下のステップを含むことができる。シーンのワイドビューから投影ピクチャを得ることと、投影ピクチャを少なくとも１つのサブピクチャに分割することと、少なくとも１つのサブピクチャを複数のトラックに符号化することと、符号化されたトラックに関連する記述メタデータを生成することを含み、記述メタデータは、トラック内で符号化された少なくとも１つのサブピクチャと参照ピクチャとの間の空間的関係を示す、各トラックに関連する第１の情報項目を含み、記述メタデータは、参照ピクチャを示す第２の情報項目をさらに含む、ことを特徴とする方法。したがって、メタデータ内の参照ピクチャを指定することにより、分割動作とは独立して、投影ピクチャ、パック化ピクチャ、又は任意の他の参照ピクチャのいずれかに関連するサブピクチャデータを生成することが可能である。
以下の表は、投射として例えば、正距円筒図法（ＥＲＰ）又はキューブマップ投射、パック化又は魚眼コンテンツの使用のいずれかを含むサブピクチャトラックに対するＯＭＡＦの文脈における投射ピクチャに対して相対的な、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤｄｅｓｃｒｉｐｔｉｏｎＢｏｘトラックグループサイズ及び座標属性の実用的なマッピングを提案する。以下の表では、「ｒｗｐｋ」は、領域的パッキング構造、すなわち、パック化領域とそれぞれの投影領域との間のマッピングを指定し、もしあれば、ガードバンドの位置及びサイズを指定する構造のためのショートカットである。同様に、‘ｆｏｖｉ’は、ＯＭＡＦプレーヤで魚眼画像のスティッチング及びレンダリングを可能にするためのパラメータを記述する構造である、ＦｉｓｈｅｙｅＶｉｄｅｏＥｓｓｅｎｔｉａｌＩｎｆｏＳｔｒｕｃｔのためのショートカットである。
Figure 0007472220000002
Figure 0007472220000003
ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤｄｅｓｃｒｉｐｔｉｏｎＢｏｘ属性を投影ピクチャに対して定義することは、それらをパック化ピクチャに対して定義することと比較して、アプリケーションに利点を提供する。実際、ビューポート依存ストリーミングの場合、アプリケーションは、現在のユーザのビューポートに対応する（すなわち、ユーザの視野と方向に対応する）サブピクチャトラックのみをダウンロードしたい場合がある。ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤｄｅｓｃｒｉｐｔｉｏｎＢｏｘ属性が、投影されたピクチャに対して定義される場合、アプリケーションは、それが投影ピクチャ内で移動している間に、適切なサブピクチャトラックを選択するために、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤｄｅｓｃｒｉｐｔｉｏｎＢｏｘトラックグループからのこの情報を直接使用することができる。そうでない場合、アプリケーションは、適切なサブピクチャトラックを選択することができる前に、サブピクチャパック化コンテンツを投影ピクチャに変換するために、トラックグループ情報に加えて、ＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙ内に位置する領域的パッキング情報を解析する必要がある。
オプションで、空間関係を記述するトラックグループ（例えば、‘２ｄｃｃ’トラックグループ）は、所定のサブピクチャトラックに対して、３６０°球へのそれのマッピングを提供する追加の記述子を含むことができる。この追加の記述子は、所定のユーザのビュー方向に対応する関連トラック又はトラックセットのプレーヤによる選択がより容易になるように、メディアプレーヤのためのいかなる計算もなしに、２Ｄビデオサブピクチャトラックと３Ｄビューポートとの間のマッピングを提供する。次に、空間関係を記述するトラックグループは、以下のように書き換える。
aligned(8) class SpatialRelationship2DDescriptionBox extends TrackGroupTypeBox('2dcc') {
// track_group_idはTrackGroupTypeBoxから引き継がれる;
SpatialRelationship2DSourceBox(); // 必須, 最初でなければならない
SubPictureRegionBox (); // オプション
SphericalRegionBox (); // オプション
}
ここで、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＳｏｕｒｃｅＢｏｘ及びＳｕｂＰｉｃｔｕｒｅＲｅｇｉｏｎＢｏｘは、トラックグループに関連するサブピクチャトラックの２Ｄ座標系及びそれらの位置及びサイズをそれぞれ記述する。ＳｐｈｅｒｉｃａｌＲｅｇｉｏｎＢｏｘは、以下のように定義された新しいボックスである（４文字コードは単なる一例であり、球領域の表示のために予約されている場合、任意の４文字コードは使用され得る）。
aligned(8) class SphericalRegionBox extends FullBox('sspr', 0, 0) {
SphereRegionStruct(1);
}
ここで、ＳｐｈｅｒｅＲｅｇｉｏｎＳｔｒｕｃｔは、方位角（垂直）及び仰角（水平）次元の範囲を有する三重項（ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈ、ｃｅｎｔｅｒ＿ｅｌｅｖａｔｉｏｎ、ｃｅｎｔｅｒ＿ｐｉｔｃｈ）又は時々（ｙａｗ、ｐｉｔｃｈ、ｒｏｌｌ）として球領域を指定する。
図７は、図１ａの手段２５０及びオプションの手段２６０と、２８０と、２８５によって実行される、サブピクチャカプセル化を示す。ステップ７０１において、ユーザは、カプセル化モジュール（例えば、図１ａの手段１５０におけるＩＳＯＢＭＦＦライタ又はｍｐ４パッケージャ又はライタ）を構成する。これは、カプセル化ソフトウェアを制御するグラフィカル・ユーザ・インターフェースを介して実行され得る。これは、カプセル化するためのソース、又は、例えばサブピクチャトラックへの分解のようなカプセル化のためのパラメータ、又は１つの単一のメディアファイル又は多くのセグメントファイルの生成の特定情報からなる。あるいは、シーンをキャプチャする記録装置（カメラ、ネットワークカメラ、スマートフォン等）に設定として予め登録されていてもよい。次に、カプセル化モジュールは、ステップ７０２において、参照ピクチャをキャプチャされた画像として初期化する。これは、カプセル化モジュールを実行しているデバイスのＲＡＭに、キャプチャ画像のサイズを格納することで構成する。
次に、ステップ７０３で、カプセル化モジュールは、カプセル化構成が投影ステップを含むかどうかをチェックする。偽の場合、次のステップは７０６である。例えば、キャプチャされたコンテンツが３６０°コンテンツである場合、それは、投影ピクチャと呼ばれる２Ｄ画像上に投影され得る。投影が使用されている場合（テスト７０３ 真）、次にカプセル化モジュールは、メディアファイル（又はメディアセグメント）の記述メタデータで使用されている投影の記述を挿入する（ステップ７０４）。これは、例えば、ＯＭＡＦ仕様による投影全方向ビデオボックス‘ｐｏｖｄ’であってよい。次に（ステップ７０５）、参照ピクチャが投影ピクチャに設定される。これは、例えば、この投影ピクチャのサイズがメモリに記憶されることを意味する。ステップ７０６は、キャプチャされたソースが立体視か否か、及びビューが単一のフレームにパックされているかどうかをチェックすることからなる。テスト７０６が真である場合、次にカプセル化モジュールは、ステレオコンテンツのための記述子をメディアファイルに挿入する（ステップ７０７）。ＯＭＡＦ又はＩＳＯＢＭＦＦの場合、それはＳｔｅｒｅｏＶｉｄｅｏＢｏｘである。テスト７０６が偽である場合、次のステップは７０９である。ステップ７０７に続いて、フレームパック化ピクチャは、参照ピクチャにおいてメモリに格納される。
テスト７０９は、カプセル化構成が、投影及びオプションでフレームパック化ピクチャがさらにパック領域に再配置される必要があることを示すかどうかをチェックすることからなる。テスト７０９が真である場合、カプセル化モジュールは、このパッキングの記述を領域に挿入する（図１のオプションのステップ２６０に相当する）（ステップ７１０）。ＯＭＡＦの場合、それは、‘ｒｗｐｋ’ボックスタイプによって識別されるＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘとなることができる。次に、７１１において、参照ピクチャがパック化ピクチャに設定される。テスト７０９が偽である場合、次のステップは７１２である。ステップ７１２におけるテストは、カプセル化構成、すなわち、サブピクチャトラックのための黙示的な信号又は明示的な信号が、ユーザ又はアプリケーションによって選択又は設定されるかどうかをチェックすることからなる。黙示的な信号がオフである場合、次にステップ７１３で、カプセル化モジュールは、どの参照ピクチャがサブピクチャトラック生成のために使用されるか（すなわち、それぞれサブピクチャトラックにカプセル化された空間部分に分割されたピクチャ）を提供する記述メタデータを挿入する。黙示的な信号がオンである場合、次のステップは７１４である。ステップ７１４において、カプセル化モジュールは、分割ピクチャの異なる空間部分間の空間関係を記述するトラックグループを挿入する。
特に、サブピクチャトラックの生じる合成のサイズは、メモリ（７０２、７０５、７０８、又は７１１）に格納された参照ピクチャのサイズに設定される。例えば、これはＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＳｏｕｒｃｅＢｏｘのｔｏｔａｌ＿ｗｉｄｔｈ及びｔｏｔａｌ＿ｈｅｉｇｈｔのパラメータであってよい。最後に、ステップ７１５で、カプセル化モジュールは、参照ピクチャ内の位置及びサイズに関して各サブピクチャトラックを記述する。これは、例えば、これらのパラメータが静的である場合、分割から生じる値をＳｕｂＰｉｃｔｕｒｅＲｅｇｉｏｎＢｏｘのパラメータに入れるためのＯＭＡＦ又はＩＳＯＢＭＦＦ、又は空間関係記述のためのサンプルグループ記述ボックス（例えば、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＧｒｏｕｐＥｎｔｒｙボックス）からなる。ステップ７１３の明示的な信号は、図８に示すように解析プロセスの記述と共に説明した通り、様々な方法で実行され得る。
いくつかの実施形態では、複数の符号化トラック及び関連する記述メタデータを備えるメディアファイルから少なくとも１つの画像を生成するための方法は、複数の符号化トラックが、シーンのワイドビューの投影ピクチャをパッキングすることによって得られるパック化ピクチャの分割から生じる少なくとも１つのサブピクチャを符号化するトラックのグループを備えることを判定することと、トラックのグループに関連する記述的メタデータを解析することを含み、トラックのグループに関連する記述メタデータを解析することは、トラック内に符号化された少なくとも１つのサブピクチャと少なくとも１つの投影ピクチャとの間の空間関係を示す各トラックに関連付けられた情報の項目を解釈することを含む、ことを特徴とする方法。
いくつかの実施形態では、複数の符号化トラック及び関連する記述メタデータを備えるメディアファイルから少なくとも１つの画像を生成するための方法は、複数の符号化トラックが、シーンのワイドビューの投影ピクチャの分割から生じる少なくとも１つのサブピクチャを符号化するトラックのグループを含むことを決定することと、トラックのグループに関連する記述的メタデータを解析することを含み、トラックのグループに関連する記述的メタデータを解析することは、トラック内に符号化された少なくとも１つのサブピクチャと少なくとも１つの参照ピクチャとの間の空間関係を示す、各トラックに関連付けられた第１の情報項目を解釈することと、参照ピクチャを示す第２の情報項目を解釈することを含む、ことを特徴とする方法。
メディアプレーヤは、ＩＳＯＢＭＦＦパーサを使用して、８０１でＯＭＡＦファイルを受信する。それは、メディアファイルに存在する異なるトラック及び、特にビデオトラックを識別する。それらのビデオトラックについて、パーサは、これらが、２Ｄピクチャ上に投影された全方向性メディアのための古典的な２Ｄビデオ又はビデオトラックであるかどうかをチェックする。これは、ステップ８０２の‘ｆｔｙｐ’ボックス内の主要ブランド又は互換ブランドのリストで見ることによって判定される。例えば、‘ｏｖｄｐ’に設定されたブランドは、メディアファイルが、ＯＭＡＦビューポート依存ベースラインプレゼンテーションプロファイルのための技術を使用するＶＲ体験を含むことを示す。本発明は、一実施形態において、ＯＭＡＦビューポート依存プロファイルによるＶＲ体験がサブピクチャトラックをさらに使用することを示す明示的ブランド（主要ブランド値として、又は互換ブランドのリストに入れられる）を定義することを提案する。ブランド（主要又は互換ブランド）について、少なくとも２つの特定の値が定義され得る。
第１の値は、全方向依存プロファイルに対して、例えば名称‘ｏｄｐｒ’と定義されてもよい。この値は、全方向性メディアが、投影ピクチャを参照するサブピクチャトラックに分割されることを示す。このブランドに準拠する任意のＩＳＯＢＭＦＦパーサ又はＯＭＡＦプレーヤは、サブピクチャトラックの位置を投影ピクチャ内の位置として解釈する。同様に、ｔｏｔａｌ＿ｗｉｄｔｈ及びｔｏｔａｌ＿ｈｅｉｇｈｔは、投影ピクチャの幅及び高さとしてそれぞれ解釈される。第２の値は、全方向依存プロファイルに対して、例えば名称「ｏｄｐａ」と定義されてもよい。この値は、全方向性メディアが、パック化ピクチャを参照するサブピクチャトラックに分割されることを示す。このブランドに準拠した任意のＩＳＯＢＭＦＦパーサ又はＯＭＡＦプレーヤは、サブピクチャトラックの位置をパック化ピクチャ内の位置として解釈する。同様に、ｔｏｔａｌ＿ｗｉｄｔｈ及びｔｏｔａｌ＿ｈｅｉｇｈｔは、パック化ピクチャの幅及び高さとして、それぞれ解釈される。
このブランドの１つが存在する場合、ＯＭＡＦプレーヤ又はメディアプレーヤは、参照ピクチャ情報を取得する方法を直ぐに識別する。次に、それは、参照ピクチャの指示を含む空間関係記述について明示的トラックグループを解析する。これはステップ８０３で実行される。これらのブランドが‘ｆｔｙｐ’ボックスに存在しない場合、メディアファイルパーサ又はメディアプレーヤは、サブピクチャトラックの存在、及びそれらが投影ピクチャ又はパック化ピクチャを参照するかどうかを判定するために、メディアファイルをさらに解析しなければならない（テスト８０２のオブジェクト）。空間関係を記述するトラックグループが本発明の実施形態による明示的トラックグループである場合、次にパーサは、８０３において、これらの明示的トラックグループを解析する。それは、ステップ８０４で、所定のトラックグループ（例えば、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄを通して識別される）内のサブピクチャトラックを記述するために使用中の参照ピクチャを判定する。これは、選択のためにサブピクチャトラックをユーザに提示するとき、又はサブピクチャトラックをレンダリングするときに考慮されなければならない。追加の変換は、参照ピクチャで表現されたサブピクチャトラックからキャプチャされたピクチャへの画像を生成するために、必要とされてもよい。例えば、参照ピクチャがパック化ピクチャである場合、投影ピクチャで表現するために、サブピクチャトラックの位置とサイズはアンパックされなければならない。この処理はステップ８１２のオブジェクトである。我々は今、ステップ８０３においてパーサによって使用されるカプセル化ステップ７１３の間に明示的信号がどのように実行されるかを説明する。
新しいブランドの代替実施形態では、トラック又はトラックグループレベルで明示的信号を追加することが提案される。これは、ＩＳＯＢＭＦＦにおける２Ｄ空間関係記述のための‘２ｄｃｃ’トラックグループを使用して実行されてもよい。この追加信号は、パーサ又はプレーヤが、サブピクチャトラックを処理すること、特に、それらが投影又はパック化ピクチャのための位置及びサイズを表すかどうかを判定することに役立つことができる。そのような信号の一実施形態は、空間関係記述のための特定のトラックグループタイプボックス内に新しいパラメータを定義することであってもよい。好ましくは、それは、パーサが情報を得ることができるように、トラックグループボックスの必須部分、すなわち、空間関係記述のためのＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＳｏｕｒｃｅＢｏｘにおいて定義される。この実施形態の一例は、以下の通りであってもよい。
aligned(8) class SpatialRelationship2DDescriptionBox extends TrackGroupTypeBox('2dcc')
{
// track_group_idはTrackGroupTypeBoxから引き継がれる;
SpatialRelationship2DSourceBox(); // 必須, 最初でなければならない
SubPictureRegionBox (); // オプション
}
aligned(8) class SpatialRelationship2DSourceBox extends FullBox('2dsr', 0, 0) {
unsigned int(32) total_width;
unsigned int(32) total_height;
unsigned int(32) source_id;
unsigned int(1) reference_picture;
unsigned int(31) reserved
}
ここで、「ｒｅｆｅｒｅｎｃｅ＿ｐｉｃｔｕｒｅ」は、値「０」を取る場合、このグループ内のサブピクチャトラックのための位置が投影ピクチャ座標系で表現されることを示す新しいパラメータである。値「１」を取る場合、それはこのグループ内のサブピクチャトラックがパック化ピクチャ内で表現されることを示す。このパラメータに付与される名前は、一例である。同様に、ｔｏｔａｌ＿ｗｉｄｔｈ及びｔｏｔａｌ＿ｈｅｉｇｈｔは、投影ピクチャの幅及び高さをそれぞれ示す。投影又はパック化ピクチャとの間の参照ピクチャの選択を単にサポートするよりも一般的であるために、ｒｅｆｅｒｅｎｃｅ＿ｐｉｃｔｕｒｅは、キャプチャ及び符号化手段との間の参照として使用するための中間ピクチャに対応する値であるいくつかの値をとることができる。例えば、値０は、投影が存在しない場合にキャプチャ画像のために使用されてよく（ステップ７０２）、値１は、投影のみが存在する場合に使用されてよく（ステップ７０５）、値２は、フレームパック化ピクチャのため（ステップ７０８）、及び、値３は、パック化フレームのため（７１１）に使用され得る。この指示は、投影及びパック化フレームのみをサポートする先行実施形態と比較して、２ビットを必要とする。
より明示的な信号である別の実施形態は、（整数値の代わりに）参照ピクチャを記述するための４ｃｃコードを提供することからなる。これは、記述（サブピクチャトラック毎に４バイト）の点で、よりコストがかかる。例えば、参照ピクチャが投影ピクチャであることを示すために、参照ピクチャ値は‘ｐｏｖｄ’に設定され得る。パック化ピクチャについて、それは‘ｒｗｐｋ’に設定されてよく、フレームパック化ピクチャについて、それは‘ｓｔｖｉ’であってよい。キャプチャ画像について、デフォルトの場合は、キャプチャ画像を意味する「ｄｅｆａｕｌｔ」のための専用４文字コード‘ｄｆｌｔ’に設定され得る。好ましくは、中間ピクチャと整数コードとの間のマッピングは、参照ピクチャ値のための相互運用可能なコードを有するために、例えば、ｍｐ４登録権限によって定義され、登録される。代替として、追加のｒｅｆｅｒｅｎｃｅ＿ｐｉｃｔｕｒｅパラメータは、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘの任意の部分、すなわちＳｕｂＰｉｃｔｕｒｅＲｅｇｉｏｎＢｏｘにおいて宣言されてもよい。ステップ７１２において、それは、明示的な信号が決定されるとき、必須部分にそれを有することが好ましい。これは、パーサ又はプレーヤが情報を見つけることができることを確認するためである。
別の代替実施形態では、空間関係記述のための特定のトラックグループタイプボックス内の追加信号は、それがＩＳＯＢＭＦＦ又はＯＭＡＦ内の空間関係記述の古いバージョンとの下位互換性を保存する方法で定義される。そのために、新しいバージョンのＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘは、例えば、ｖｅｒｓｉｏｎ＝１又はフラグ値以外を有する同じｖｅｒｓｉｏｎ＝０で定義される。先行技術におけるＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘは、ｆｌａｇｓ値を許容しないことに留意されたい。ＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘにフラグ値を与えることは、本発明のこの実施形態の一部である。例えば、値０ｘ０１に設定されたフラグ値「Ｒｅｆｅｒｅｎｃｅ＿ｉｎｆｏ＿ｉｓ＿ｐｒｅｓｅｎｔ」は、このトラックグループが空間関係情報の位置及びサイズについて考慮するよう、参照ピクチャ上の情報を含むことを示すために定義されてもよい。次に、２ｄｃｃトラックグループは、以下のように表され得る。
aligned(8) class SpatialRelationship2DDescriptionBox extends TrackGroupTypeBox('2dcc', 0, flags)
{
// track_group_idはTrackGroupTypeBoxから引き継がれる;
SpatialRelationship2DSourceBox(flags); // 必須, 最初でなければならない
SubPictureRegionBox (); // オプション
}
aligned(8) class SpatialRelationship2DSourceBox extends FullBox('2dsr', 0, flags) {
unsigned int(32) total_width;
unsigned int(32) total_height;
unsigned int(32) source_id;
if ( (flags & 0x01) == 1) {
unsigned int(1) reference_picture;
unsigned int(31) reserved
}
}
ここで、値「０」を取る場合にこのグループ内のサブピクチャトラックのための位置が投影ピクチャ座標系で表されることを示す新しいパラメータである。パラメータの名前は、一例として付与される。同様に、ｔｏｔａｌ＿ｗｉｄｔｈ及びｔｏｔａｌ＿ｈｅｉｇｈｔは、投影ピクチャの幅及び高さをそれぞれ示す。
フラグを使用することは、例えば２Ｄクラシックビデオについて、参照ピクチャに曖昧性がない場合に、各サブピクチャトラックの記述コストを低減する。参照ピクチャの有無を示すためにフラグを使用することは、２ｄｃｃトラックグループ化タイプの再使用が、全方向コンテンツをサブピクチャトラックに分割する両方の場合、すなわち、領域的パッキングステップの有無を処理することを可能にする。さらに別の実施形態では、ＴｒａｃｋＧｒｏｕｐｉｎｇＴｙｐｅＢｏｘのフラグパラメータ、又はＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘのようなそれの引き継ぎボックスの１つは、参照ピクチャをフラグ値に直接提供するように使用される。例えば、フラグパラメータが０に設定された最下位ビットを有する場合、これは、参照ピクチャが全方向ビデオの場合における投影ピクチャであることを意味する。フラグパラメータが、１に設定されているそれの最下位ビットを有する場合、次にそれは、参照ピクチャが全方向ビデオの場合におけるパック化ピクチャであることを意味する。デフォルト値は、０に設定されたフラグパラメータの最下位ビットである。この実施形態とともに、ファイル記述をよりコンパクトにする（サブピクチャトラック毎に４バイトを節約）、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＳｏｕｒｃｅＢｏｘ内に追加のパラメータはない。
代替実施形態では、黙示的又は明示的サブピクチャトラック信号間の区別は、２つの異なるトラックグループ化タイプを使用することによって行われる。現在のグループ化タイプは、黙示的信号のために使用され、新しいトラックグループ化タイプは、明示的な空間関係トラックグループのために定義される。例えば、４文字コード‘ｅｄｃｃ’が使用され、新しいＴｒａｃｋＧｒｏｕｐｉｎｇＴｙｐｅＢｏｘが次のように作成される。
aligned(8) class ExplicitSpatialRelationship2DDescriptionBox extends TrackGroupTypeBox('edcc', 0, flags)
{
// track_group_idはTrackGroupTypeBoxから引き継がれる;
ExplicitSpatialRelationship2DSourceBox(flags); // 必須, 最初でなければならない
SubPictureRegionBox (); // オプション
}
aligned(8) class ExplicitSpatialRelationship2DSourceBox extends FullBox('edsr', 0, flags) {
unsigned int(32) total_width;
unsigned int(32) total_height;
unsigned int(32) source_id;
unsigned int(8) reference_picture;
}
カプセル化構成が「黙示的」であると判定される場合（テスト８０１及び８０２ 偽）、特定の信号が使用されていないことを意味し、パーサは、参照ピクチャの黙示的な判定を調査する。それは、変換又は復号化後の操作が実行されなければならない、制限情報ボックス‘ｒｉｎｆ’で宣言された方式を解析することによって構成され、及び潜在的に参照ピクチャを提供する。ＯＭＡＦのためのほとんどの時間で、それはパック化ピクチャ又は投影ピクチャであってよい。立体視コンテンツについて、それはフレームパック化ピクチャであってもよい。次に、パーサは、候補参照ピクチャを判定するためにＯＭＡＦ記述子の存在をチェックする。パーサは、メディアファイル内に領域的パッキング指示がない場合、空間関係記述のための位置及びサイズパラメータが投影ピクチャに関して表現されると仮定する（テスト８１０ 偽）。領域的パッキングボックスが存在する場合、空間関係記述のための位置及びサイズパラメータは、パック化ピクチャに関して表現される（ステップ８１１）。
オプションで、パーサは、空間関係を記述するトラックグループのサブピクチャトラック内の‘ｓｔｖｉ’ボックスの存在についてテストすることによって、フレームパック化ピクチャの有無を考慮することができる（ステップ８０８）。存在する場合、パーサは、フレームパック化ピクチャを候補参照ピクチャとして記録する。より一般的には、黙示的信号について、サブピクチャトラックの位置及びサイズは、キャプチャ１１０と符号化手段１４０との間の異なる処理ステップから生じる最後のピクチャにおいて表現されると考えられる。これらの異なる処理は、制限方式情報ボックス‘ｒｉｎｆ’に反映される。例えば、コンテンツ準備が投影１２０、フレームパッキング１２５、及び領域的パッキング１３０を含む場合、ＲｅｓｔｒｉｃｔｅｄＳｃｈｅｍｅＩｎｆｏＢｏｘ‘ｒｉｎｆ’ボックスは、投影が適用されたことを示す‘ｐｏｖｄ’ボックスを、それのＳｃｈｅｍｅＴｙｐｅＢｏｘ内に含む。この‘ｐｏｖｄ’ボックスは、それ自体、例えばＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘ‘ｒｗｐｋ’として、１３０で行われる領域的パッキングを記述する構造を含むことができる。同様に、ステレオビデオボックスは、手段１２５によって実施されるフレームパッキングを示すために、例えばＣｏｍｐａｔｉｂｌｅＳｃｈｅｍｅＴｙｐｅＢｏｘ内に存在する。
最適化黙示的モードとクローズドシステム内について、カプセル化とパーサは、設定情報を交換することができ、サブピクチャトラック記述のための事前定義されたデフォルトモードを宣言するための設定を定義することができる。例えば、それらは、メディアが全方向性コンテンツを含む場合、サブピクチャトラックが常に投影画像を参照することに同意することができる。図９は、本発明の実施形態による、エンコーダ９５０又はデコーダ９００、及び通信ネットワーク９９９のうちの少なくとも１つを備えるシステム９９１ ９９５を示す。一実施形態によれば、例えばシステム９９５は、デコーダ９００を備えるユーザ端末又はデコーダ９００と通信可能なユーザ端子のユーザインターフェースを介して、デコーダ９００にアクセスするユーザにコンテンツ（例えば、ビデオ／オーディオコンテンツを表示／出力又はストリーミングするためのビデオ及びオーディオコンテンツ）を処理及び提供するためのものである。このようなユーザ端末は、コンピュータ、携帯電話、タブレット、又は（提供／ストリーミングされた）コンテンツをユーザに提供／表示することができる任意の他の種類の装置であってもよい。システム９９５は、通信ネットワーク９９９を介して（例えば、先のビデオ／オーディオが表示／出力されている間に）ビットストリーム９０１を取得／受信する。一実施形態によれば、システム９９１は、コンテンツ処理及び処理コンテンツ、例えば、後の時間で表示／出力／ストリーミングするために処理されたビデオ及びオーディオコンテンツを記憶するためのものである。
システム９９１は、エンコーダ９５０によって受信及び処理され、及びエンコーダ９５０は、通信ネットワーク９９１を介してデコーダ９００に通信されるビットストリーム９０１を生成する、例えば、本発明の実施形態におけるワイドビューシーンに対応する画像９５１のオリジナルシーケンスを含むコンテンツを取得／受信する。次に、ビットストリーム９０１は、いくつかの方法でデコーダ９００に通信され、例えば、それはエンコーダ９５０によって予め生成されてよく、データが記憶装置からデコーダ９００に通信／ストリーミングされる時点で、ユーザが記憶装置からコンテンツ（すなわちビットストリームデータ）を要求するまで、通信ネットワーク９９９内の記憶装置（例えば、サーバ又はクラウドストレージ上）にデータとして記憶されてよい。システム９９１は、ユーザに（例えば、ユーザ端末上に表示されるユーザインターフェースのためのデータを通信することによって）、記憶装置に格納されたコンテンツのための（例えば、コンテンツのタイトルや、コンテンツを識別、選択及び要求するための他のメタ／格納位置データ）、及び要求されたコンテンツが記憶装置からユーザ端末に配信／ストリーミングされ得るように、コンテンツのためのユーザ要求を受信及び処理するための、コンテンツ情報を提供／ストリーミングするためのコンテンツ提供装置を備えることもできる。好ましくは、本発明の実施形態では、ユーザ端末はヘッドマウントディスプレイである。
あるいは、エンコーダ９５０は、ユーザがコンテンツを要求するときに、ビットストリーム９０１を生成し、それをデコーダ９００に直接通信／ストリーミングする。次に、デコーダ９００は、要求コンテンツをユーザに提供するために、次にユーザ端末によって使用される、ビデオ信号９０９及び／又はオーディオ信号を取得／生成するために、ビットストリーム９０１（又は信号）を受信し、本発明によるサブピクチャトラックの復号を実行する。図３は、本発明の１つ以上の実施形態を実施するためのコンピューティングデバイス３００の概略ブロック図である。コンピューティングデバイス３００は、例えばマイクロコンピュータ、ワークステーション、又はライトポータブルデバイスなどのデバイスであってよい。コンピューティングデバイス３００は、以下に接続された通信バスを備える。マイクロプロセッサのような中央演算処理装置（ＣＰＵ）３０１、本発明の実施形態の方法の実行可能なコードを記憶するためのランダムアクセスメモリ（ＲＡＭ）３０２、及び所定のファイル・フォーマット下でマニフェストの読取り及び書込みのため及び／又はビデオを符号化するため及び／又はデータを読取り又は生成するための方法を実施するために必要な変数及びパラメータを記録するように適合された登録、それのメモリ容量は例えば拡張ポートに接続されたオプションのＲＡＭによって拡張され得る。本発明の実施形態を実現するためのコンピュータプログラムを記憶するための読み出し専用メモリ（ＲＯＭ）３０３。
ネットワークインターフェース３０４は、すなわち、順次処理されるためのデジタルデータが転送又は受信される、通信ネットワークを介して接続される。ネットワークインターフェース３０４は、単一のネットワークインターフェースであってもよく、又は異なるネットワークインターフェースのセット（例えば、有線及び無線インターフェース、又は異なる種類の有線又は無線インターフェース）から構成されてもよい。データは、送信のためにネットワークインターフェースに書き込まれるか、又はＣＰＵ３０１内で実行されているソフトウェアアプリケーションの制御の下で受信のためにネットワークインターフェースから読み出される。ユーザからの入力を受け取るため、又はユーザに情報を表示するためのユーザインターフェース（ＵＩ）３０５。ハードディスク（ＨＤ）３０６。例えばビデオソース又はディスプレイのような外部装置から／までデータを受信／送信するためのＩ／Ｏモジュール３０７。実行可能コードは、読み出し専用メモリ３０３、ハードディスク３０６、又は例えばディスクのようなリムーバブルデジタル媒体のいずれかに格納され得る。変形例によれば、プログラムの実行可能コードは、実行される前に、ハードディスク３０６などの通信装置３００の記憶手段の１つに記憶されるために、ネットワークインターフェース３０４を介して、通信ネットワークによって受信され得る。
中央演算処理装置３０１は、命令は、上記の記憶手段のうちの１つに記憶されている、本発明の実施形態による命令又はプログラムソフトウェアコードの部分又はプログラムの実行を制御及び指向するように適合されている。電源オン後、ＣＰＵ３０１は、例えば、プログラムＲＯＭ３０３又はハードディスク３０６からそれらの命令がロードされた後に、ソフトウェアアプリケーションに関するメインＲＡＭメモリ３０２からの命令を実行することができる。このようなソフトウェアアプリケーションは、ＣＰＵ３０１によって実行されると、前の図に示したフローチャートのステップを実行する。この実施形態では、装置は、本発明を実施するためにソフトウェアを使用するプログラム可能な装置である。しかしながら、代替的に、本発明は、ハードウェア（例えば、特定用途向け集積回路（ＡＳＩＣ）の形態で）で実施されてもよい。本発明は、特定の実施形態を参照して上記で説明されたが、本発明は特定の実施形態に限定されるものではなく、変形例は本発明の趣旨の範囲内にある技術分野における当業者には明らかである。
例えば、本発明は、カメラ、スマートフォン、ヘッドマウントディスプレイ、又は、例えば対象の特定領域にズームインするためのＴＶ又はマルチメディアディスプレイのためのリモートコントローラとして機能するタブレットのようなデバイスに組み込まれてもよい。それはまた、特定の対照領域を選択することによって、マルチメディアプレゼンテーションの個人化ブラウジング体験を有するために、同じデバイスから使用されてよい。ユーザによるこれらの装置及び方法からの別の使用は、他の接続された装置と、ユーザの好ましいビデオのいくつかの選択されたサブ部を共有することである。それはまた、監視カメラが本発明によるデータを提供する方法をサポートする場合には、監視下に置かれた建物の特定の領域で何が起こるかを監視するために、スマートフォン又はタブレットと共に使用されてもよい。
多くのさらなる修正及び変形は、単に例として与えられ、本発明の範囲を限定することを意図しておらず、その範囲は添付の特許請求の範囲によってのみ決定される、前述の例示的な実施形態を参照することにより、当業者に示唆されるであろう。特に、様々な実施形態からの異なる特徴は、適宜、入れ替えられ得る。

Claims (14)

  1. 符号化されたメディアデータをカプセル化したメディアファイルを生成する方法であって、
    各メディアトラックの少なくとも一部がトラックグループとしてグループ化され、グループ識別子によって識別されるトラックグループに属する複数のメディアトラックを生成することと、
    前記複数のメディアトラックのうち、参照するトラックからデータを抽出するためのＥｘｔｒａｃｔｏｒを含むＥｘｔｒａｃｔｏｒトラックを生成することと、
    前記複数のメディアトラックと前記Ｅｘｔｒａｃｔｏｒトラックとを含むメディアファイルを生成することと、を含み、
    前記Ｅｘｔｒａｃｔｏｒに含まれるＣｏｎｓｔｒｕｃｔｏｒのタイプとして、前記Ｃｏｎｓｔｒｕｃｔｏｒが参照するトラックが、前記Ｃｏｎｓｔｒｕｃｔｏｒにより指定されるグループ識別子を有するトラックグループに属する他のトラックに切り替え可能であることを示す所定のタイプを指定可能である、
    ことを特徴とする方法。
  2. 前記Ｃｏｎｓｔｒｕｃｔｏｒが参照するトラックとして、前記トラックグループに属する最初のトラックが選択される、
    ことを特徴とする請求項１に記載の方法。
  3. 前記複数のメディアトラックは、画像品質、解像度、ビットレートのいずれかが異なる、
    ことを特徴とする請求項１または２に記載の方法。
  4. 前記メディアファイルは、ＩＳＯ／ＩＥＣ１４４９６－１５規格で規定されるフォーマットのメディアファイルである、
    ことを特徴とする請求項１から３のいずれか１項に記載の方法。
  5. 前記Ｅｘｔｒａｃｔｏｒにより抽出されるデータは、ＩＳＯ／ＩＥＣ１４４９６－１５規格で規定されるＮＡＬユニットのペイロードである、
    ことを特徴とする請求項１から４のいずれか１項に記載の方法。
  6. メディアファイルから符号化されたメディアデータを取得する方法であって、
    （１）各メディアトラックの少なくとも一部がトラックグループとしてグループ化され、グループ識別子によって識別されるトラックグループに属する複数のメディアトラックと、（２）前記複数のメディアトラックのうち、参照するトラックからデータを抽出するＥｘｔｒａｃｔｏｒを含むＥｘｔｒａｃｔｏｒトラックと、を含むメディアファイルを取得することと、
    取得した前記メディアファイルを処理することと、を含み、
    前記Ｅｘｔｒａｃｔｏｒに含まれるＣｏｎｓｔｒｕｃｔｏｒのタイプとして、前記Ｃｏｎｓｔｒｕｃｔｏｒが参照するトラックが、前記Ｃｏｎｓｔｒｕｃｔｏｒにより指定されるグループ識別子を有するトラックグループに属する他のトラックに切り替え可能であることを示す所定のタイプを指定可能である、
    ことを特徴とする方法。
  7. 前記Ｃｏｎｓｔｒｕｃｔｏｒが参照するトラックとして、前記トラックグループに属する最初のトラックが選択される、
    ことを特徴とする請求項６に記載の方法。
  8. 前記複数のメディアトラックは、画像品質、解像度、ビットレートのいずれかが異なる
    ことを特徴とする請求項６または７に記載の方法。
  9. 前記メディアファイルは、ＩＳＯ／ＩＥＣ１４４９６－１５規格で規定されるフォーマットのメディアファイルである
    ことを特徴とする請求項６から８のいずれか１項に記載の方法。
  10. 前記Ｅｘｔｒａｃｔｏｒにより抽出されるデータは、ＩＳＯ／ＩＥＣ１４４９６－１５規格で規定されるＮＡＬユニットのペイロードである
    ことを特徴とする請求項６から９のいずれか１項に記載の方法。
  11. コンピュータに、請求項１から５までのいずれか１項に記載の方法を実行させるためのプログラム。
  12. コンピュータに、請求項６から１０までのいずれか１項に記載の方法を実行させるためのプログラム。
  13. 符号化されたメディアデータをカプセル化したメディアファイルを生成するデバイスであって、
    前記デバイスは、
    各メディアトラックの少なくとも一部がトラックグループとしてグループ化され、グループ識別子によって識別されるトラックグループに属する複数のメディアトラックを生成する第１生成手段と、
    前記複数のメディアトラックのうち、参照するトラックからデータを抽出するＥｘｔｒａｃｔｏｒを含むＥｘｔｒａｃｔｏｒトラックを生成する第２生成手段と、
    前記複数のメディアトラックと前記Ｅｘｔｒａｃｔｏｒトラックとを含むメディアファイルを生成する第３生成手段と、を備え、
    前記Ｅｘｔｒａｃｔｏｒに含まれるＣｏｎｓｔｒｕｃｔｏｒのタイプとして、前記Ｃｏｎｓｔｒｕｃｔｏｒが参照するトラックが、前記Ｃｏｎｓｔｒｕｃｔｏｒにより指定されるグループ識別子を有するトラックグループに属する他のトラックに切り替え可能であることを示す所定のタイプを指定可能である、
    ことを特徴とするデバイス。
  14. メディアファイルから符号化されたメディアデータを取得するデバイスであって、
    （１）各メディアトラックの少なくとも一部がトラックグループとしてグループ化され、グループ識別子によって識別されるトラックグループに属する複数のメディアトラックと、（２）前記複数のメディアトラックのうち、参照するトラックからデータを抽出するＥｘｔｒａｃｔｏｒを含むＥｘｔｒａｃｔｏｒトラックと、を含むメディアファイルを取得する取得手段と、
    前記取得手段により取得された前記メディアファイルを処理する処理手段と、を備え、
    前記Ｅｘｔｒａｃｔｏｒに含まれるＣｏｎｓｔｒｕｃｔｏｒのタイプとして、前記Ｃｏｎｓｔｒｕｃｔｏｒが参照するトラックが、前記Ｃｏｎｓｔｒｕｃｔｏｒにより指定されるグループ識別子を有するトラックグループに属する他のトラックに切り替え可能であることを示す所定のタイプを指定可能である、
    ことを特徴とするデバイス。
JP2022155292A 2018-06-27 2022-09-28 方法、プログラム、及びデバイス Active JP7472220B2 (ja)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
GB1810563.5A GB2575074B (en) 2018-06-27 2018-06-27 Encapsulating video content with an indication of whether a group of tracks collectively represents a full frame or a part of a frame
GB1810563.5 2018-06-27
PCT/EP2019/066334 WO2020002122A1 (en) 2018-06-27 2019-06-20 Method, device, and computer program for transmitting media content
JP2020564931A JP7154314B2 (ja) 2018-06-27 2019-06-20 メディアコンテンツを送信する方法、装置及びコンピュータプログラム

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2020564931A Division JP7154314B2 (ja) 2018-06-27 2019-06-20 メディアコンテンツを送信する方法、装置及びコンピュータプログラム

Publications (2)

Publication Number Publication Date
JP2022177265A JP2022177265A (ja) 2022-11-30
JP7472220B2 true JP7472220B2 (ja) 2024-04-22

Family

ID=63143593

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2020564931A Active JP7154314B2 (ja) 2018-06-27 2019-06-20 メディアコンテンツを送信する方法、装置及びコンピュータプログラム
JP2022155292A Active JP7472220B2 (ja) 2018-06-27 2022-09-28 方法、プログラム、及びデバイス

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2020564931A Active JP7154314B2 (ja) 2018-06-27 2019-06-20 メディアコンテンツを送信する方法、装置及びコンピュータプログラム

Country Status (4)

Country Link
US (2) US11765407B2 (ja)
JP (2) JP7154314B2 (ja)
GB (1) GB2575074B (ja)
WO (1) WO2020002122A1 (ja)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11968374B2 (en) * 2019-07-03 2024-04-23 Beijing Xiaomi Mobile Software Co., Ltd. Method and device for coding and decoding
GB2587364B (en) * 2019-09-24 2023-11-15 Canon Kk Method, device, and computer program for encapsulating media data into a media file
US20230027058A1 (en) 2019-12-31 2023-01-26 Nokia Technologies Oy A Method, An Apparatus and A Computer Program Product for Video Encoding and Video Decoding
US11589032B2 (en) * 2020-01-07 2023-02-21 Mediatek Singapore Pte. Ltd. Methods and apparatus for using track derivations to generate new tracks for network based media processing applications
CN113766271B (zh) * 2020-06-04 2022-07-12 腾讯科技（深圳）有限公司 一种沉浸媒体的数据处理方法、装置及设备
US20230328261A1 (en) * 2020-09-24 2023-10-12 Lg Electronics Inc. Media file processing method and device therefor
EP4226631A1 (en) * 2020-10-07 2023-08-16 Nokia Technologies Oy A coded picture with mixed vcl nal unit type
CN116248642A (zh) * 2020-10-14 2023-06-09 腾讯科技（深圳）有限公司 媒体文件的封装方法、媒体文件的解封装方法及相关设备
US11900687B2 (en) * 2021-07-06 2024-02-13 Canoo Technologies Inc. Fisheye collage transformation for road object detection or other object detection
GB2611105B (en) * 2021-09-28 2024-01-17 Canon Kk Method, device and computer program for optimizing encapsulation of redundant portions of metadata in fragments of media file
WO2024028330A1 (en) * 2022-08-01 2024-02-08 Dolby International Ab Methods, apparatus and systems for isobmff file enhanced grouping of tracks
KR20240026314A (ko) * 2022-08-18 2024-02-28 한국전자기술연구원 비디오 기반의 증강현실 컨텐츠 제공 시스템
CN116634209B (zh) * 2023-07-24 2023-11-17 武汉能钠智能装备技术股份有限公司 一种基于热插拔的断点视频恢复系统及方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011528868A (ja) 2008-07-16 2011-11-24 ノキア コーポレイション トラックおよびトラックサブセットグループ化の方法および装置
JP2013505646A (ja) 2009-09-22 2013-02-14 クゥアルコム・インコーポレイテッド ファイルフォーマットトラック選択のためのメディアエクストラクタトラック
JP2018513574A (ja) 2015-02-10 2018-05-24 ノキア テクノロジーズ オサケユイチア 画像シーケンストラックを処理する方法、装置、及びコンピュータプログラムプロダクト

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8976871B2 (en) * 2009-09-16 2015-03-10 Qualcomm Incorporated Media extractor tracks for file format track selection
GB2513140B (en) 2013-04-16 2016-05-04 Canon Kk Methods, devices, and computer programs for streaming partitioned timed media data
JP6493765B2 (ja) 2013-07-19 2019-04-03 ソニー株式会社 情報処理装置および方法
JP6572222B2 (ja) * 2014-01-07 2019-09-04 キヤノン株式会社 メディアファイルの生成方法、生成装置、及びプログラム
GB2527786B (en) 2014-07-01 2016-10-26 Canon Kk Method, device, and computer program for encapsulating HEVC layered media data
GB2539462B (en) * 2015-06-16 2019-04-03 Canon Kk Obtaining media data and metadata from encapsulated bit-streams wherein operating point descriptors can be dynamically set
CN108886639B (zh) * 2016-02-02 2021-05-07 弗劳恩霍夫应用研究促进协会 视频流传输中的场景部分和感兴趣区域处理
US10419768B2 (en) * 2016-03-30 2019-09-17 Qualcomm Incorporated Tile grouping in HEVC and L-HEVC file formats
GB2550604A (en) * 2016-05-24 2017-11-29 Canon Kk Method, device, and computer program for encapsulating and parsing timed media data
BR112019003605A2 (pt) 2016-08-25 2019-05-21 Lg Electronics Inc. método para transmitir vídeo omnidirecional, método para receber vídeo omnidirecional, aparelho para transmitir vídeo omnidirecional, e aparelho para receber vídeo omnidirecional
US11197040B2 (en) * 2016-10-17 2021-12-07 Mediatek Inc. Deriving and signaling a region or viewport in streaming media
US10841621B2 (en) * 2017-03-01 2020-11-17 Wyse Technology L.L.C. Fault recovery of video bitstream in remote sessions

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011528868A (ja) 2008-07-16 2011-11-24 ノキア コーポレイション トラックおよびトラックサブセットグループ化の方法および装置
JP2013505646A (ja) 2009-09-22 2013-02-14 クゥアルコム・インコーポレイテッド ファイルフォーマットトラック選択のためのメディアエクストラクタトラック
JP2018513574A (ja) 2015-02-10 2018-05-24 ノキア テクノロジーズ オサケユイチア 画像シーケンストラックを処理する方法、装置、及びコンピュータプログラムプロダクト

Also Published As

Publication number Publication date
WO2020002122A1 (en) 2020-01-02
JP7154314B2 (ja) 2022-10-17
US20210377581A1 (en) 2021-12-02
GB2575074B (en) 2022-09-28
US20240040170A1 (en) 2024-02-01
JP2021528891A (ja) 2021-10-21
GB2575074A (en) 2020-01-01
JP2022177265A (ja) 2022-11-30
GB201810563D0 (en) 2018-08-15
US11765407B2 (en) 2023-09-19

Similar Documents

Publication Publication Date Title
JP7472220B2 (ja) 方法、プログラム、及びデバイス
JP6960528B2 (ja) メディアコンテンツを生成および処理するための方法、装置、およびコンピュータプログラム
JP7133038B2 (ja) メディアコンテンツを送信する方法、装置及びコンピュータプログラム
JP7399224B2 (ja) メディアコンテンツを送信するための方法、装置及びコンピュータプログラム
CN109155874B (zh) 虚拟现实媒体内容的自适应流传输的方法、装置和计算机程序
US11638066B2 (en) Method, device and computer program for encapsulating media data into a media file
GB2509953A (en) Displaying a Region of Interest in a Video Stream by Providing Links Between Encapsulated Video Streams

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20221028

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20231012

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20231020

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20231214

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20240311

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240410

R150 Certificate of patent or registration of utility model

Ref document number: 7472220

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150