ホーム > 特許ランキング > ＢＹＴＥＤＡＮＣＥ ＩＮＣ．
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-09-12
(54)【発明の名称】ビデオ処理の方法、装置及び媒体
(51)【国際特許分類】
H04N 19/70 20140101AFI20240905BHJP
H04N 19/30 20140101ALI20240905BHJP
【ＦＩ】
H04N19/70
H04N19/30
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2024519073
(86)(22)【出願日】2022-09-26
(85)【翻訳文提出日】2024-03-27
(86)【国際出願番号】 US2022077044
(87)【国際公開番号】W WO2023049912
(87)【国際公開日】2023-03-30
(31)【優先権主張番号】63/248,832
(32)【優先日】2021-09-27
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】520477474
【氏名又は名称】バイトダンス インコーポレイテッド
【氏名又は名称原語表記】ＢＹＴＥＤＡＮＣＥ ＩＮＣ．
【住所又は居所原語表記】１２６５５ Ｗｅｓｔ Ｊｅｆｆｅｒｓｏｎ Ｂｏｕｌｅｖａｒｄ， Ｓｉｘｔｈ Ｆｌｏｏｒ， Ｓｕｉｔｅ Ｎｏ． １３７ Ｌｏｓ Ａｎｇｅｌｅｓ， Ｃａｌｉｆｏｒｎｉａ ９００６６ Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100229448
【弁理士】
【氏名又は名称】中槇 利明
(72)【発明者】
【氏名】ワン，イエ－クォイ
【テーマコード（参考）】
5C159
【Ｆターム（参考）】
5C159LA02
5C159MA04
5C159MA05
5C159MA21
5C159MA31
5C159MC11
5C159ME01
5C159PP03
5C159PP04
5C159RB01
5C159RC01
5C159RC11
5C159UA02
5C159UA05
(57)【要約】
本開示の実施形態は、ビデオを処理するための技術を提供している。ビデオを処理するための方法、第１ビデオのメディアファイルと第１ビデオのビットストリームとの間の変換を実行するステップことを含み、メディアファイルは、第１ビデオにおける目標ピクチャインピクチャ領域を示す第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含み、。本開示の方法によれば、ＩＳＯベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ）に基づくメディアファイル内のピクチャインピクチャサービスに容易に対応することができる。
【選択図】図8
【選択図】図8
【特許請求の範囲】
【請求項1】
ビデオ処理方法であって、第１ビデオのメディアファイルと前記第１ビデオのビットストリームとの間の変換を実行するステップを含み、
前記メディアファイルは、前記第１ビデオにおける目標ピクチャインピクチャ領域を示す第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含み、前記第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である、方法。
【請求項2】
前記第２ビデオの空間分解能が、前記第１ビデオの空間分解能よりも低い、請求項１に記載の方法。
【請求項3】
前記第１指示は、前記第１ビデオにおける領域を識別する領域識別（ＩＤ）のリストを含む、請求項１～２の何れか１項に記載の方法。
【請求項4】
前記方法は、前記領域ＩＤのリストにおける１つの領域ＩＤについて、前記第２グループの符号化・復号化されたビデオデータユニットのうち、前記領域ＩＤを持つ第２の符号化・復号化されたビデオデータユニットで、前記第１グループの符号化・復号化されたビデオデータユニットのうち、前記領域ＩＤを持つ第１の符号化・復号化されたビデオデータユニットを入れ替えるステップを更に含む、請求項３に記載の方法。
【請求項5】
前記第１ビデオは、汎用汎用ビデオ符号化方式（ＶＶＣ）で符号化・復号化されたものであり、前記領域識別のリストにおける領域ＩＤは、前記第１ビデオにおけるサブピクチャを識別するサブピクチャＩＤである、請求項３～４の何れか１項に記載の方法。
【請求項6】
前記第１グループの符号化・復号化されたビデオデータユニットは、ビデオコーデック層ネットワーク抽象化層（ＶＣＬ ＮＡＬ）ユニットを含み、前記第２グループの符号化・復号化されたビデオデータユニットは、ＶＣＬ ＮＡＬユニットを含む、請求項１～５の何れか１項に記載の方法。
【請求項7】
前記第１指示は、前記メディアファイルのデータ構成に含まれる、請求項１～６の何れか１項に記載の方法。
【請求項8】
前記データ構成は、「ｐｉｎｐ」エンティティグループである、請求項７に記載の方法。
【請求項9】
前記「ｐｉｎｐ」エンティティグループにおけるエンティティは、前記第１ビデオの前記ビットストリームを担持するトラックである、請求項８に記載の方法。
【請求項10】
前記データ構成は、前記第１ビデオの前記ビットストリームを担持する１グループのトラックを指示するための第２指示を更に含む、請求項７～９の何れか１項に記載の方法。
【請求項11】
前記第２指示は、前記１グループのトラックにおけるトラック数に等しい値と、
前記１グループのトラックにおけるトラックの識別（ＩＤ）を指示するインデックスリストと、
前記１グループのトラックにおけるトラックのトラックＩＤのリストと、のうちの１つを含む、請求項１０に記載の方法。
【請求項12】
前記目標ピクチャインピクチャ領域のサイズは、前記第１ビデオのサイズよりも小さく、かつ、前記データ構成には、前記目標ピクチャインピクチャ領域の位置情報及びサイズ情報が更に含まれる、請求項７～１１の何れか１項に記載の方法。
【請求項13】
前記位置情報は、前記目標ピクチャインピクチャ領域の左上隅の水平位置及び鉛直位置を指示し、前記サイズ情報は、前記目標ピクチャインピクチャ領域の幅及び高さを指示する、請求項１２に記載の方法。
【請求項14】
前記方法は、前記メディアファイルは、前記第１グループの符号化・復号化されたビデオデータユニットが、前記第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能ではない旨を指示するための第３指示を含む場合、前記第２ビデオに対して第１ビデオにおける第１領域を決定するステップと、
第１領域において、前記第２ビデオを前記第１ビデオに重畳するステップと、を更に含む、請求項１～２の何れか１項に記載の方法。
【請求項15】
前記メディアファイルは、前記目標ピクチャインピクチャ領域の位置情報とサイズ情報を更に含み、前記第１領域を決定することは、前記目標ピクチャインピクチャ領域に基づいて前記第１領域を決定するステップを含む、請求項１４に記載の方法。
【請求項16】
前記位置情報は、前記目標ピクチャインピクチャ領域の左上隅の水平位置及び鉛直位置を指示し、前記サイズ情報は、前記目標ピクチャインピクチャ領域の幅及び高さを指示する、請求項１５に記載の方法。
【請求項17】
前記変換は、前記メディアファイルを作成して前記ビットストリームを前記メディアファイルに記憶することを含む、請求項１～１６の何れか１項に記載の方法。
【請求項18】
前記変換は、前記メディアファイルを解析して前記ビットストリームを再構成することを含む、請求項１～１６の何れか１項に記載の方法。
【請求項19】
ビデオデータ処理装置であって、プロセッサと、指令を有する非一時的なメモリとを備え、
前記指令は、前記プロセッサによって実行されると、前記プロセッサに請求項１～１８の何れか１項に記載の方法を実行させる、装置。
【請求項20】
請求項１～１８の何れか１項に記載の方法をプロセッサに実行させる指令を記憶する、非一時的なコンピュータ読み取り可能記憶媒体。
【請求項21】
非一時的なコンピュータ読み取り可能記録媒体であって、ビデオ処理装置において実行される方法で生成された第１ビデオのビットストリームを記憶し、
前記方法は、第１ビデオのメディアファイルと前記第１ビデオのビットストリームとの間の変換を実行するステップを含み、
前記メディアファイルは、前記第１ビデオにおける目標ピクチャインピクチャ領域を示す、第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含み、前記第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である、非一時的なコンピュータ読み取り可能記録媒体。
【請求項22】
ビデオのビットストリームを記憶する方法であって、第１ビデオのメディアファイルと前記第１ビデオのビットストリームとの間の変換を実行するステップと、
前記ビットストリームを非一時的なコンピュータ読み取り可能記録媒体に記憶するステップと、を含み、
前記メディアファイルは、前記第１ビデオにおける目標ピクチャインピクチャ領域を示す、第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含み、前記第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である、方法。
【請求項23】
非一時的なコンピュータ読み取り可能記録媒体であって、ビデオ処理装置において実行される方法で生成された第１ビデオのメディアファイルを記憶し、
前記方法は、前記メディアファイルと前記第１ビデオのビットストリームとの間の変換を実行するステップを含み、
前記メディアファイルは、前記第１ビデオにおける目標ピクチャインピクチャ領域を示す第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含み、前記第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である、非一時的なコンピュータ読み取り可能記録媒体。
【請求項24】
第１ビデオのメディアファイルを記憶するための方法であって、前記メディアファイルと前記第１ビデオのビットストリームとの間の変換を実行するステップ、及び
前記メディアファイルを非一時的なコンピュータ読み取り可能記録媒体に記憶するステップを含み、
前記メディアファイルは、前記第１ビデオにおける目標ピクチャインピクチャ領域を示す第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含み、前記第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である、方法。
【発明の詳細な説明】
【技術分野】
【0001】
［関連出願の相互参照］
本願は、２０２１年９月２７日に出願された米国仮出願第６３／２４８，８３２号に基づく優先権を主張し、当該米国出願に記載されたすべての記載内容を援用により本願に組み込まれる。
本願は、２０２１年９月２７日に出願された米国仮出願第６３／２４８，８３２号に基づく優先権を主張し、当該米国出願に記載されたすべての記載内容を援用により本願に組み込まれる。
【0002】
本開示の実施形態は、主にビデオ処理技術に関し、より具体的に、ピクチャインピクチャに対応するためのファイルフォーマットの設計に関する。
【背景技術】
【0003】
メディアストリームアプリケーションは、一般的にインターネットプロトコル（ＩＰ）や、伝送制御プロトコル（ＴＣＰ）やハイパーテキスト転送プロトコル（ＨＴＴＰ）の伝送方法に準拠し、かつ、一般的に例えばＩＳＯベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ）のファイルフォーマットに依存している。このようなストリームシステムの１つは、ＨＴＴＰに基づく動的適応ストリーミング（ＤＡＳＨ）である。ＤＡＳＨでは、マルチメディアコンテンツのビデオ及び／又はオーディオデータについて、様々な表現が存在してもよく、異なる表現は、異なるコーデック特性（例えば、ビデオコーデック規格の異なるプロファイル又はレベルや、異なるビットレートや、異なる空間分解能など）に対応してもよい。更に、「ピクチャインピクチャ（ｐｉｃｔｕｒｅ－ｉｎ－ｐｉｃｔｕｒｅ）」と呼ばれる技術も提出されていた。そのため、ピクチャインピクチャサービスに対応するファイルフォーマットは検討の余地がある。
【発明の概要】
【0004】
本開示の実施形態は、ビデオを処理するための技術案を提供している。
【0005】
第１の局面によれば、ビデオを処理するための方法を提供している。当該方法は、第１ビデオのメディアファイルと第１ビデオのビットストリームとの間の変換を実行するステップを含む。メディアファイルは、第１ビデオにおける目標ピクチャインピクチャ領域を示す第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含む。当該第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である。
【0006】
上記の方法によれば、指示を採用して、第１ビデオにおける目標ピクチャインピクチャ領域を示す第１グループの符号化・復号化されたビデオデータユニットを指示する。当該第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である。これにより、提出された方法は、ＩＳＯＢＭＦＦに基づくメディアファイル内のピクチャインピクチャサービスに対応することを容易に可能にする。
【0007】
第２局面によれば、ビデオデータを処理するための装置を提供している。当該ビデオデータを処理するための装置は、プロセッサと、指令を記憶した非一時的なメモリを備える。指令がプロセッサによって実行されると、本開示の第１局面に係る方法をプロセッサに実行させる。
【0008】
第３局面によれば、非一時的なコンピュータ読み取り可能記憶媒体を提供している。当該非一時的なコンピュータ読み取り可能記憶媒体は、本開示の第１局面に係る方法の指令をプロセッサに実行させる。
【0009】
第４局面によれば、別の非一時的なコンピュータ読み取り可能記録媒体を提供している。当該非一時的なコンピュータ読み取り可能記録媒体は、ビデオ処理装置において実行される方法で生成されたビデオのビットストリームを記憶する。当該方法は、第１ビデオのメディアファイルと第１ビデオのビットストリームとの間の変換を実行するステップを含み、当該メディアファイルは、第１ビデオにおける目標ピクチャインピクチャ領域を示す、第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含む。第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である。
【0010】
第５局面によれば、第１ビデオのビットストリームを記憶するための方法を提供している。当該方法は、ビデオのメディアファイルと第１ビデオのビットストリームとの間の変換を実行するステップを含み、当該メディアファイルは、第１ビデオにおける目標ピクチャインピクチャ領域を示す、第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含む。第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である。
【0011】
第６局面によれば、別の非一時的なコンピュータ読み取り可能記録媒体を提供している。当該非一時的なコンピュータ読み取り可能記録媒体は、ビデオ処理装置において実行される方法で生成された第１ビデオのメディアファイルを記憶する。当該方法は、第１ビデオのメディアファイルと第１ビデオのビットストリームとの間の変換を実行するステップを含み、メディアファイルは、第１ビデオにおける目標ピクチャインピクチャ領域を示す第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含む。第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である。
【0012】
第７局面によれば、第１ビデオのメディアファイルを記憶するための方法を提供している。当該方法は、第１ビデオのメディアファイルと第１ビデオのビットストリームとの間の変換を実行するステップ、及びメディアファイルを非一時的なコンピュータ読み取り可能記録媒体に記憶するステップを含む。当該メディアファイルは、第１ビデオにおける目標ピクチャインピクチャ領域を示す第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含み、第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である。
【0013】
発明の概要についての記載は、簡素化された形態で概念の選択を説明するためであり、これらは以下の発明を実施するための形態において詳細に説明する。発明の概要は、本開示の重要な特徴又は必要な特徴を識別することを意図せず、本開示の範囲を限定することも意図していない。
【図面の簡単な説明】
【0014】
添付図面を参照した以下の詳細な説明によれば、本開示の例示的な実施形態の上記及び他の目的、特徴及び利点はより明らかになる。本開示の例示的な実施形態において、同一の符号は一般的に同一の構成要素を指す。
【図1】本開示の幾つかの実施形態に係る例示的なビデオコーデックシステムのブロック図を示している。
【図2】本開示の幾つかの実施形態に係る第１例示的なビデオエンコーダのブロック図を示している。
【図3】本開示の幾つかの実施形態に係る例示的なビデオデコーダのブロック図を示している。
【図4】１８個のタイル、２４個のスライス及び２４個のサブピクチャに分割されたピクチャを示している。
【図5】代表として、サブピクチャによるビューポートに関する３６０°ビデオ伝送方式を示している。
【図6】２つのサブピクチャ及び４つのスライスを含むビットストリームから１つのサブピクチャを抽出することを示している。
【図7】ＶＶＣサブピクチャによるピクチャインピクチャ対応の例を示している。
【図8】本発明幾つかの実施形態に係るビデオを処理するための方法のフロー図を示している。
【図9】ピクチャインピクチャの模式図を示している。
【図10】ピクチャインピクチャ領域の位置情報及びサイズ情報の模式図を示している。
【図11】本開示の各種の実施形態を実現可能なコンピュータ装置のブロック図を示している。 すべての添付図面において、同一又は同様な符号は、一般的に同一又は同様な元素を指す。
【発明を実施するための形態】
【0015】
次に、幾つかの実施形態を参照して、本開示の原理を説明する。これらの実施形態は、説明の目的、及び当業者が本開示を理解し実施するのを支援するためにのみ記載されており、本開示の範囲についての限定を意味するものではないことを理解されたい。本明細書に記載される開示内容は、以下に記載されるものに加えて、様々な方法で実施することができる。
【0016】
以下の説明及び特許請求の範囲において、本明細書で使用される全ての科学用語及び技術用語の意味は、特に断りがない限り、本開示が属する技術分野の当業者によって一般的に理解される意味と同じである。
【0017】
本開示における「１つの実施形態」、「実施形態」、「例示的な実施形態」などは、記載された実施形態が特定の特徴、構造、又は特性を含み得ることを示すが、すべての実施形態がそれぞれ上記の特定の特徴、構造、又は特性を含まなければならないわけではない。更に、これらの語句は、必ずしも同一の実施形態を指すとは限らない。更に、例示的な実施形態を参照して特定の特徴、構造、又は特性を説明する場合、明示的に記載されているか否かにかかわらず、他の実施形態に係る特徴、構造、又は特性に影響を及ぼすことは当業者の知識の範囲内であると考えられる。
【0018】
「第１」及び「第２」等の用語は、様々な要素を説明するために使用され得るが、これらの要素は、これらの用語によって限定されるべきではないことが理解されるべきである。これらの用語は、１つの要素を他の要素から区別するために使用されるだけである。例えば、例示的な実施形態の範囲から逸脱することなく、第１要素を第２要素と称することができ、同様に、第２要素を第１要素と称することができる。本明細書で使用される「及び／又は」の用語は、列挙された用語の１つ又は複数の任意の及び全ての組み合わせを含む。
【0019】
本明細書で使用される場合、用語は、特定の実施形態を説明する目的でのみ使用され、例示の実施形態を限定することを意図しない。本明細書で使用される単数形「一」、「一つ」、及び「当該」は、文脈において明らかに記載されない限り、複数形を含むことも意図される。また、本明細書で使用される「備える」、「含む」、及び／又は「有する」の用語は、記載された特徴、要素、及び／又はコンポーネントなどの存在を示すが、１つ又は複数の他の特徴、要素、コンポーネント、及び／又はそれらの組み合わせの存在又は追加を排除するものではないことを理解されたい。
【0020】
実施形態の環境
図１は、本開示の技術を適用可能な例示的なビデオコーデックシステム１００のブロック図を図示している。このように、ビデオコーデックシステム１００は、ソース装置１１０とターゲット装置１２０とを備えてもよい。ソース装置１１０は、ビデオ符号化装置とも称され、ターゲット装置１２０は、ビデオ復号化装置とも称される。操作中に、ソース装置１１０は、符号化されたビデオデータを生成するように配置されてもよく、ターゲット装置１２０は、ソース装置１１０によって生成された、符号化されたビデオデータを復号するように配置されてもよい。ソース装置１１０は、ビデオソース１１２と、ビデオエンコーダ１１４と、入出力（Ｉ／Ｏ）インターフェース１１６とを含んでもよい。
図１は、本開示の技術を適用可能な例示的なビデオコーデックシステム１００のブロック図を図示している。このように、ビデオコーデックシステム１００は、ソース装置１１０とターゲット装置１２０とを備えてもよい。ソース装置１１０は、ビデオ符号化装置とも称され、ターゲット装置１２０は、ビデオ復号化装置とも称される。操作中に、ソース装置１１０は、符号化されたビデオデータを生成するように配置されてもよく、ターゲット装置１２０は、ソース装置１１０によって生成された、符号化されたビデオデータを復号するように配置されてもよい。ソース装置１１０は、ビデオソース１１２と、ビデオエンコーダ１１４と、入出力（Ｉ／Ｏ）インターフェース１１６とを含んでもよい。
【0021】
ビデオソース１１２は、例えばビデオキャプチャ装置のようなソースを備えてもよい。ビデオキャプチャ装置は、ビデオコンテンツの事業者からビデオデータを受信するインターフェースや、ビデオデータを生成するためのコンピュータグラフィックスシステム及び／又はそれらの組み合わせが挙げられるが、これに限定されてない。
【0022】
ビデオデータは、１つ又は複数のピクチャを含むことができる。ビデオエンコーダ１１４ビデオソース１１２からのビデオデータを符号化して、ビットストリームを生成する。ビットストリームは、ビデオデータを形成し符号化されたビット系列を含んでもよい。ビットストリームは、符号化ピクチャとそれに関連するデータを含んでもよい。符号化ピクチャはピクチャを符号化して表現したものである。それに関連するデータは、シーケンスパラメータセットと、ピクチャパラメータセットと、その他の文法構成（構文構造）を含んでもよい。Ｉ／Ｏインターフェース１１６は、変復調機及び／又は送信機を含んでもよい。符号化されたビデオデータは、ネットワーク１３０ＡによりＩ／Ｏインターフェース１１６を介してターゲット装置１２０に直接伝送することができる。符号化されたビデオデータは、ターゲット装置１２０がアクセスするように記憶媒体／サーバ１３０Ｂに記憶することができる。
【0023】
ターゲット装置１２０は、Ｉ／Ｏインターフェース１２６と、ビデオデコーダ１２４と、表示装置１２２を含んでもよい。Ｉ／Ｏインターフェース１２６は、受信機及び／又は変復調機を含んでもよい。Ｉ／Ｏインターフェース１２６は、ソース装置１１０又は記憶媒体／サーバ１３０Ｂから符号化されたビデオデータを取得することができる。ビデオデコーダ１２４は符号化されたビデオデータを復号することができる。表示装置１２２は、ユーザに対して復号化されたビデオデータを表示することができる。表示装置１２２がターゲット装置１２０と一体的に構成されてもよく、ターゲット装置１２０の外部において、外部表示装置インターフェースがこのターゲット装置１２０と接続可能に配置されてもよい。
【0024】
ビデオエンコーダ１１４及びビデオデコーダ１２４は、ビデオ圧縮規格、例えば、高能率ビデオ符号化（ＨＥＶＣ）規格、汎用ビデオ符号化（ＶＶＣ）規格及びその他の従来の及び／又は更なる規格に準じて操作することができる。
【0025】
【0026】
ビデオエンコーダ２００は、本開示の何れか又はすべての技術を実現するように構成することができる。図２の例では、ビデオエンコーダ２００は、複数の機能コンポーネントを含む。本開示に記述の技術は、ビデオエンコーダ２００の各コンポーネントの間で共用することができる。幾つかの例では、プロセッサは、本開示に記述の何れか又はすべての技術を実行するように構成されてもよい。
【0027】
幾つかの実施形態では、ビデオエンコーダ２００は、分割ユニット２０１と、予測ユニット２０２と、残差生成ユニット２０７と、変換ユニット２０８と、量子化ユニット２０９と、逆量子化ユニット２１０と、逆変換ユニット２１１と、再構成ユニット２１２と、バッファ２１３と、エントロピー符号化・復号化ユニット２１４を含んでもよく、該予測ユニット２０２は、モード選択ユニット２０３と、動き推定ユニット２０４と、動き補償ユニット２０５と、フレーム内予測ユニット２０６を含んでもよい。
【0028】
別の例では、ビデオエンコーダ２００は、より多い、又は、より少ない、又は、異なる機能コンポーネントを含んでもよい。一実施形態では、予測ユニット２０２は、ブロック内コピー（ＩＢＣ）ユニットを含んでもよい。ＩＢＣユニットは、ＩＢＣモードにおいて予測を実行することができる。少なくとも１つのリファレンスピクチャは、現在のビデオブロックが位置するピクチャである。
【0029】
更に、幾つかコンポーネント（例えば、動き推定ユニット２０４と動き補償ユニット２０５）は、集約化可能であるが、解釈の便宜上、これらのコンポーネントは、図２の例では離間して示されている。
【0030】
分割ユニット２０１は、ピクチャを１つ又は複数のビデオブロックに分割することができる。ビデオエンコーダ２００とビデオデコーダ３００は、様々なビデオブロックの大きさに対応することができる。
【0031】
モード選択ユニット２０３は、例えば、誤差結果に基づいて、様々なコーデックモード（フレーム内符号化又はインター符号化）の１つを選択して、生じたフレーム内符号化ブロック又はインター符号化ブロックを残差生成ユニット２０７に提供し残差ブロックデータを生成して、再構成ユニット２１２に提供しリファレンスピクチャとして符号化ブロックを再構成することができる。幾つかの例では、モード選択ユニット２０３は、フレーム内及びフレーム間予測（ＣＩＩＰ）モードの結合を選択して、フレーム間予測信号及びフレーム内予測信号に基づいて予測することができる。フレーム間予測の場合、モード選択ユニット２０３は、ブロックに対して動きベクトルについての分解能（例えば、副画素精度又は整数画素精度）を選択することもできる。
【0032】
現在のビデオブロックについてフレーム間予測を実行するために、動き推定ユニット２０４は、バッファ２１３からの１つ又は複数のリファレンスフレームと現在のビデオブロックとを比較することで、現在のビデオブロックについての動き情報を生成することができる。動き補償ユニット２０５は、動き情報と、バッファ２１３からの現在のビデオブロックに関連するピクチャを除くピクチャの復号化されたサンプルに応じて、現在のビデオブロックについての予測ビデオブロックを特定することができる。
【0033】
動き推定ユニット２０４及び動き補償ユニット２０５は、現在のビデオブロックがＩスライス、Ｐスライス又はＢスライスのどっちに位置するかに応じて、現在のビデオブロックについて異なる操作を実行することができる。例えば、本明細書にいて使用される「Ｉスライス」は、マクロブロックからなるピクチャの一部分であってもよく、全てのマクロブロックは何れも同一のピクチャにおけるマクロブロックに由来する。更に、本明細書において使用されるように、ある局面では、「Ｐスライス」及び「Ｂスライス」は、同一のピクチャにおけるマクロブロックとは別のマクロブロックからなるピクチャの部分であってもよい。
【0034】
幾つかの例では、動き推定ユニット２０４は、現在のビデオブロックについて単方向予測を実行することができ、動き推定ユニット２０４は、リスト０又はリスト１のリファレンスピクチャを検索して、現在のビデオブロックに対するリファレンスビデオブロックを探すことができる。そして、動き推定ユニット２０４は、リスト０又はリスト１内のリファレンスビデオブロックを含むリファレンスピクチャを指示するリファレンスインデックスと、現在のビデオブロックとリファレンスビデオブロックとの間の空間変位を指示する動きベクトルとを生成することができる。動き推定ユニット２０４は、現在のビデオブロックの動き情報として、リファレンスインデックス、予測方向標識、及び動きベクトルを出力することができる。動き補償ユニット２０５は、現在のビデオブロックの動き情報で指示されるリファレンスビデオブロックに応じて、現在のビデオブロックの予測ビデオブロックを生成することができる。
【0035】
また、別の例では、動き推定ユニット２０４は、現在のビデオブロックについて両方向予測を実行することができる。動き推定ユニット２０４は、リスト０内のリファレンスピクチャを検索して、現在のビデオブロックに対するリファレンスビデオブロックを探すことができ、更に、リスト１内のリファレンスピクチャを検索して、現在のビデオブロックに対する他のリファレンスビデオブロックを探すことができる。そして、動き推定ユニット２０４は、可以リスト０及びリスト１内の複数のリファレンスビデオブロックを含む複数のリファレンスピクチャを指示する複数のリファレンスインデックスと、複数のリファレンスビデオブロックと現在のビデオブロックとの間の複数の空間変位を指示する複数の動きベクトルとを生成することができる。動き推定ユニット２０４は、現在のビデオブロックの複数のリファレンスインデックスと複数の動きベクトルを現在のビデオブロックの動き情報として出力することができる。動き補償ユニット２０５は、現在のビデオブロックの動き情報で指示される複数のリファレンスビデオブロックに応じて現在のビデオブロックについての予測ビデオブロックを生成することができる。
【0036】
幾つかの例では、動き推定ユニット２０４は、完全な動き情報セットを出力して、デコーダの復号化処理に用いることができる。或いは、幾つかの実施形態では、動き推定ユニット２０４は、他のビデオブロックの動き情報を参照して、信号で現在のビデオブロックの動き情報を伝送することができる。例えば、動き推定ユニット２０４は、現在のビデオブロックの動き情報と近隣のビデオブロックの動き情報とが十分に似ていることを確定することができる。
【0037】
一実施形態では、動き推定ユニット２０４は、現在のビデオブロックに関連する文法構成においてビデオデコーダ３００に対して１つの値を指示することができ、この値は、現在のビデオブロックが他のビデオブロックと同じ動き情報を有することを指示する。
【0038】
別の例では、動き推定ユニット２０４は、現在のビデオブロックに関連する文法構成において、他のビデオブロックと動きベクトル差（ＭＶＤ）を識別することができる。動きベクトル差は、現在のビデオブロックの動きベクトルと指示されるビデオブロックの動きベクトルとの間の差異を指示する。ビデオデコーダ３００は、指示されるビデオブロックの動きベクトル及び動きベクトル差を使用して、現在のビデオブロックの動きベクトルを確定することができる。
【0039】
上述したように、ビデオエンコーダ２００は、予測性の方式にて信号で動きベクトルを伝送することができる。ビデオエンコーダ２００が実現可能な予測シグナリング技術についての２つの例は、高度な動きベクトル予測（ＡＭＶＰ）及びマージモードシグナリングを含む。
【0040】
フレーム内予測ユニット２０６は、現在のビデオブロックについてフレーム内予測を実行することができる。フレーム内予測ユニット２０６が、現在のビデオブロックについてフレーム内予測を実行する際に、フレーム内予測ユニット２０６は、同一のピクチャにおける他のビデオブロックの復号化されたサンプルに基づいて現在のビデオブロックに対する予測データを生成することができる。現在のビデオブロックに対する予測データは、予測ビデオブロックと各々のシンタックスエレメントを含んでもよい。
【0041】
残差生成ユニット２０７は、現在のビデオブロックから（例えば、マイナス記号で指示）現在のビデオブロックの（複数の）予測ビデオブロックを減算することで、現在のビデオブロックについての残差データを生成することができる。現在のビデオブロックの残差データは、現在のビデオブロックのサンプルの異なるサンプル部分に対応する残差ビデオブロックを含んでもよい。
【0042】
別の例では、例えばスキップモードでは、現在のビデオブロックについて現在のビデオブロックについての残差データが存在しないことがあり、残差生成ユニット２０７は、減算動作を実行しなくてもよい。
【0043】
変換処理ユニット２０８は、可以１つ又は複数の変換を現在のビデオブロックに関連する残差ビデオブロックに適用することで、現在のビデオブロックに対する１つ又は複数の変換係数ビデオブロックを生成することができる。
【0044】
変換処理ユニット２０８が現在のビデオブロックに関連する変換係数ビデオブロックを生成した後に、量子化ユニット２０９は、現在のビデオブロックに関連する１つ又は複数の量子化パラメータ（ＱＰ）値に基づいて、現在のビデオブロックに関連する変換係数ビデオブロックを量子化することができる。
【0045】
逆量子化ユニット２１０及び逆変換ユニット２１１は、それぞれ変換係数ビデオブロックに対して逆量子化及び逆変換を適用して、変換係数ビデオブロックから残差ビデオブロック再構成することができる。再構成ユニット２１２は、再構成された残差ビデオブロックを、予測ユニット２０２により生成される１つ又は複数の予測ビデオブロックからの対応するサンプルに追加して、現在のビデオブロックに関連する再構成ビデオブロックを生じて、バッファ２１３に記憶することができる。
【0046】
再構成ユニット２１２は、ビデオブロックを再構成した後に、ループフィルタ処理を実行してビデオブロックにおけるビデオブロック効果アーチファクトを低下させることができる。
【0047】
エントロピー符号化・復号化ユニット２１４は、ビデオエンコーダ２００の他の機能コンポーネントからデータを受信することができる。エントロピー符号化・復号化ユニット２１４がデータを受信する際に、エントロピー符号化・復号化ユニット２１４は、１つ又は複数のエントロピー符号化処理を実行して、エントロピー符号化・復号化データを生成し、当該エントロピー符号化・復号化データを含むビットストリームを出力することができる。
【0048】
【0049】
ビデオデコーダ３００は、本開示の何れか又はすべての技術を実行するように構成してもよい。図３の例では、ビデオデコーダ３００は、複数の機能コンポーネントを含む。本開示に記述の技術は、ビデオデコーダ３００の各コンポーネントの間で共用されてもよい。幾つかの例では、プロセッサは、本開示に記述の何れか又はすべての技術を実行するように配置されてもよい。
【0050】
図３の例では、ビデオデコーダ３００は、エントロピー復号化ユニット３０１と、動き補償ユニット３０２と、フレーム内予測ユニット３０３と、逆量子化ユニット３０４と、逆変換ユニット３０５と、再構成ユニット３０６と、バッファ３０７とを備える。幾つかの例では、ビデオデコーダ３００は、一般的にビデオエンコーダ２００について説明した符号化処理に対する復号化処理を実行することができる。
【0051】
エントロピー復号化ユニット３０１は、符号化されたビットストリームを取り戻すことができる。符号化されたビットストリームは、エントロピー符号化されたビデオデータ（例えば、符号化されたビデオデータブロック）を含んでもよい。エントロピー復号化ユニット３０１は、エントロピー符号化されたビデオデータを復号することができ、動き補償ユニット３０２は、エントロピー復号化されたビデオデータから、動きベクトルと、動きベクトル精度と、リファレンスピクチャリストインデックスとその他の動き情報とを含む動き情報を特定することができる。動き補償ユニット３０２は、例えば、ＡＭＶＰ及びマージモードを実行することで該情報を特定することができる。ＡＭＶＰは、近隣のＰＢのデータ及びリファレンスピクチャから幾つかの最も可能性の高い候補を得ることを含めて使用される。動き情報は、一般的に、水平及び垂直動きベクトル変位値及び１つ又は２つのリファレンスピクチャインデックスを含み、Ｂスライスにおける予測領域の場合、どのリファレンスピクチャリストが各インデックスに関連するかの識別を更に含む。本明細書で使用されるように、ある局面において、「マージモード」は、空間的又は時間的に隣接するブロックから動き情報を導出することを指す場合がある。
【0052】
動き補償ユニット３０２は、場合によっては補間フィルタにより補間を実行するように動き補償ブロックを生成することができる。副画素精度で使用される補間フィルタの識別子は、シンタックスエレメントに含まれてもよい。
【0053】
動き補償ユニット３０２は、ビデオブロックの符号化中にビデオエンコーダ２００に使用される補間フィルタを利用して、リファレンスブロックのサブ整数画素のための補間値を算出することができる。動き補償ユニット３０２は、受信したシンタックス情報に基づいてビデオエンコーダ２００に使用される補間フィルタを決定することができ、動き補償ユニット３０２は、補間フィルタを利用して予測ブロックを生成することができる。
【0054】
動き補償ユニット３０２は、少なくとも一部のシンタックス情報を利用して、符号化されたビデオシーケンスを符号化するための（複数の）フレーム及び／又は（複数の）スライスのブロックの大きさ、符号化されたビデオシーケンスのピクチャの各マクロブロックがどのように分割されるかを説明する分割情報、各分割がどのように符号化されるかを指示するモード、各インター符号化ブロックに対する１つ又は複数のリファレンスフレーム（及びリファレンスフレームリスト）、及び符号化されたビデオシーケンスを復号する他の情報を決定することができる。本明細書において使用されるように、幾つかの局面において、「スライス」は、エントロピー符号化、信号予測及び残差信号再構成について、同一のピクチャの他のスライスから独立して復号化可能なデータ構成であってもよい。スライスは、ピクチャ全体であってもよく、又はピクチャの領域であってもよい。
【0055】
フレーム内予測ユニット３０３は、例えば、ビットストリームにおいて受信したフレーム内予測パターンを利用して、空間的に隣接するブロックから予測ブロックを形成することができる。逆量子化ユニット３０４は、ビットストリームにおいて提供される、エントロピー復号化ユニット３０１により復号化された量子化ビデオブロック係数を逆量子化する（即ち、非量子化する）。逆変換ユニット３０５は、逆変換を適用する。
【0056】
再構成ユニット３０６は、例えば、残差ブロックと動き補償ユニット３０２又はフレーム内予測ユニット３０３により生成された対応する予測ブロックとを加算することで復号化されたブロックを得ることができる。必要であれば、ブロック効果アーチファクトを除去するために、デブロッキング効果フィルタを適用して、復号化されたブロックをフィルタリングしてもよい。そして、復号化されたビデオブロックは、バッファ３０７に記憶され、バッファ３０７は、後続の動き補償／フレーム内予測に対してリファレンスブロックを提供し、バッファ３０７は更に、表示装置に提示するように、復号化されたビデオを生成する。
【0057】
以下、本開示の幾つかの例示的な実施形態を詳細に説明する。本明細書において章の見出しは、理解を容易にするために使用されるものであり、ある章において開示される実施形態をその章に限定するものではないことに留意されたい。更に、汎用のビデオコーデック又は他の特定のビデオコーデックを参照して幾つかの実施形態について説明したが、開示された技術は、他のビデオコーデック技術にも適用可能である。更に、幾つかの実施形態では、ビデオ符号化ステップを詳細に説明したが、符号化をキャンセルするための対応する復号化ステップは、デコーダによって実現することを理解されたい。更に、ビデオ処理という用語は、ビデオ符号化又は圧縮、ビデオ復号化又は展開、及びビデオ画素をある圧縮フォーマットから別の圧縮フォーマットへ、又は別の圧縮ビットレートで表現するビデオトランスコードを含む。
１．概要
本開示は、ビデオファイルフォーマットに関する。具体的には、メディアファイルにおけるピクチャインピクチャ対応に関する。メディアファイルフォーマット、例えばＩＳＯベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ）又はその拡張について、個別に又は様々な組み合わせでこれらの構想を適用することができる。
２．背景技術
２．１ ビデオコーデック規格について
ビデオコーデック規格は、主によく知られたＩＴＵ－Ｔ及びＩＳＯ／ＩＥＣ規格の開発を通じて発展してきた。ＩＴＵ－Ｔは、Ｈ．２６１及びＨ．２６３を制定し、ＩＳＯ／ＩＥＣは、ＭＰＥＧ－１及びＭＰＥＧ－４Ｖｉｓｕａｌを制定し、２つの組織は、Ｈ．２６２／ＭＰＥＧ－２Ｖｉｄｅｏ、Ｈ．２６４／ＭＰＥＧ－４高度なビデオコーデック（ＡＶＣ）及びＨ．２６５／ＨＥＶＣ規格を共同制定した。Ｈ．２６２以降、ビデオコーデック規格は、時間予測及び変換コーデックを使用したハイブリッドビデオコーデックアーキテクチャに基づく。ＨＥＶＣ以外の将来のビデオ符号化技術を探求するために、ＶＣＥＧとＭＰＥＧは、２０１５年に共同ビデオ探索チーム（ＪｏｉｎｔＶｉｄｅｏＥｘｐｌｏｒａｔｉｏｎＴｅａｍ、ＪＶＥＴ）を共同で設立した。それ以来、ＪＶＥＴは、多くの新しいアプローチを採用し、共同探索モデル（ＪＥＭ）と呼ばれる参照ソフトウェアに組み込んでいた。汎用ビデオコーデック（ＶＶＣ）プロジェクトの正式発足に伴い、ＪＶＥＴは、その名称を共同ビデオ専門家チーム（ＪｏｉｎｔＶｉｄｅｏＥｘｐｅｒｔＳＴｅａｍ、ＪＶＥＴ）に変更した。ＶＶＣは、ＪＶＥＴが２０２０年７月１日に終わった第１９回会合で最終決定された、ＨＥＶＣと比較してビットレートを５０％低減させることを目標とする新しいコーデック規格である。
汎用ビデオコーデック（ＶＶＣ）規格（ＩＴＵ－Ｔ Ｈ．２６６｜ＩＳＯ／ＩＥＣ２３０９０－３）及び関連する多機能補足強調情報（ＶＳＥＩ）規格（ＩＴＵ－Ｔ Ｈ．２７４｜ＩＳＯ／ＩＥＣ２３００２－７）は、従来の用途（例えば、テレビ放送、ビデオ会議又は記憶媒体からの再生など）、及びより新しく高度な用途（例えば、適応ビットレートストリーミング、ビデオ領域抽出、及び複数の符号化・復号化されたビデオビットストリーム、マルチビュービデオ、拡張レイヤコーデック及びビューポート適応（ｖｉｅｗｐｏｒｔ－ａｄａｐｔｉｖｅ）３６０°没入型メディアのコンテンツの組み合わせ及びマージ）の両方を含む、最も幅広い用途で使用するように設計されている。
エレメンタリービデオコーデック（ＥＶＣ）規格（ＩＳＯ／ＩＥＣ２３０９４－１）は、ＭＰＥＧが最近開発したもう１つのビデオコーデック規格である。
２．２ ファイルフォーマット規格について
メディアストリームアプリケーションは、通常、ＩＰ、ＴＣＰとＨＴＴＰ伝送方法に基づくとともに、通常、例えばＩＳＯベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ）などのファイルフォーマットに依存する。これらのストリーミングシステムのうちの１つは、ＨＴＴＰに準拠する動的適応ストリーミング（ＤＡＳＨ）である。ＩＳＯＢＭＦＦ及びＤＡＳＨを持つビデオフォーマットを使用するには、ビデオコンテンツをＩＳＯＢＭＦＦのトラック及びＤＡＳＨの表現やクリップにカプセル化するための、ビデオフォーマット固有のファイルフォーマット規格、例えばＡＶＣファイルフォーマットおよびＨＥＶＣファイルフォーマットが必要である。ビデオビットストリームに関する重要な情報、例えば、プロファイル、レイヤ、クラス及び多くの他の情報は、コンテンツの選択目的、例えば、ストリーミングセッション開示時の初期化及びストリーミングセッション期間のストリーミング適応の両方の適切なメディアクリップの選択目的のために、ファイルフォーマットクラスメタデータ及び／又はＤＡＳＨメディアプレゼンテーション記述（ＭＰＤ）として披露される必要がある。
同様に、ＩＳＯＢＭＦＦ画像フォーマットを使用するには、画像フォーマット固有のファイルフォーマット規格、例えば、ＡＶＣ画像ファイルフォーマットおよびＨＥＶＣ画像ファイルフォーマットが必要である。
ＩＳＯＢＭＦＦに基づくＶＶＣビデオコンテンツを記憶するためのファイルフォーマットであるＶＶＣビデオファイルフォーマットは、現在、ＭＰＥＧによって開発されている。ＶＶＣによりエンコードされた画像コンテンツを記憶しＩＳＯＢＭＦＦに基づくＶＶＣ画像ファイルフォーマットは、現在、ＭＰＥＧにより開発されている。
２．３ ＶＶＣにおけるピクチャ分割及びサブピクチャについて
ＶＶＣでは、１枚のピクチャは、１つ又は複数のタイル行と１つ又は複数のタイル列に分割される。タイルは、ピクチャをカバーする矩形領域のＣＴＵシーケンスである。タイルにおけるＣＴＵは、このタイルにおいてラスタースキャン順序でスキャンされる。
スライスは、ピクチャのタイル内の整数個の完全なタイル又は整数個の連続した完全なＣＴＵ行からなる。
２種類のスライスモード、即ち、ラスタースキャンスライスモードと矩形スライスモードはサポートされる。ラスタースキャンスライスモードでは、スライスは、ピクチャのタイルラスタースキャン中の完全なタイルシーケンスを含む。矩形スライスモードでは、スライスは、ピクチャの矩形領域を共同で形成する複数の完全なタイル、又はピクチャの矩形領域を共同で形成する１つのタイルの複数の連続した完全なＣＴＵ行を含む。矩形スライス内のタイルは、当該スライスに対応する矩形領域内で、タイルラスタースキャン順序でスキャンされる。
サブピクチャは、ピクチャの矩形領域を共同でカバーする１つ又は複数のスライスを含む。
２．３．１ サブピクチャの概念及び機能について
ＶＶＣでは、例えば、図４に示すように、各サブピクチャは、ピクチャの矩形領域を共同でカバーする１つ又は複数の完全な矩形スライスからなる。サブピクチャは、抽出可能（即ち、同一の画像の他のサブピクチャ及び復号化の順序での以前の画像の他のサブピクチャとは独立して符号化及び復号化される）又は抽出不可能であると限定されてもよい。サブピクチャが抽出可能であるか抽出不可能であるかにかかわらず、エンコーダは、各サブピクチャに対して個別にサブピクチャ境界を超えてループフィルタリング（デブロッキング、ＳＡＯと及びＡＬＦを含む）を適用するかどうかを制御することができる。
機能的には、サブピクチャは、ＨＥＶＣにおける動き制約付きタイルセット（ｍｏｔｉｏｎ－ｃｏｎｓｔｒａｉｎｅＤｔｉｌｅｓｅｔ、ＭＣＴＳ）に似ている。両方の何れも、例えばビューポートに関する３６０°ビデオストリーム最適化及び感心領域（ｒｅｇｉｏｎｏｆｉｎｔｅｒｅｓｔ、ＲＯＩ）アプリケーションなどの応用例について、独立してコーデックを行うこと、及び符号化・復号化されたピクチャシーケンスの矩形サブセットを抽出することが許容される。
３６０°ビデオストリーム（別名：全方位ビデオ）では、任意の特定の時点において、全方位ビデオ球全体のサブセット（即ち、現在のビューポート）のみがユーザに提示され、ユーザは、いつでも、彼／彼女の頭を回動させて視聴方向及び現在のビューポートを変更することができる。同時に、少なくともクライアント端末の現在のビューポートによってカバーされていない領域について、幾つかの低品質の表現を有することが望ましく、ユーザが突然彼／彼女の視聴方向を球面上の任意の位置に変更することを防止するように、ユーザに対してレンダリングされることを用意しておく。任意の所定の時点において、球面上の全方位ビデオの高品質表現は、ユーザに対するレンダリングが必要である現在のビューポートにのみ必要になる。このような最適化は、図４に示すように、全方位ビデオ全体の高品質表現をサブピクチャに適切な粒度で分割することで実現することができる。ここで、図４は、左側に位置する高分解能を持つ１２つのサブピクチャと、右側に位置する低分解能を持つ全方位ビデオの残りの１２つのサブピクチャとを有する。
別の代表的なサブピクチャによるビューポート関連３６０°ビデオ配信方式は、図５に示すように、完全なビデオの高分解能表現のみがサブピクチャで構成される一方で、完全なビデオの低分解能表現が、サブピクチャを使用せず、高分解能表現よりも少ない頻度のＲＡＰで符号化及び復号化することができる。クライアント端末において、低分解能の完全なビデオを受信するが、高分解能のビデオについては、現在のビューポートをカバーするサブピクチャのみを受信して復号化する。
２．３．２ サブピクチャとＭＣＴＳとの間の違いについて
サブピクチャとＭＣＴＳとの間には、幾つかの重要な設計上での違いがある。第１に、ピクチャの境界と同様に、ＶＶＣのサブピクチャ特徴は、符号化ブロックの動きベクトルがサブピクチャ外側へ指向することを許容する。この場合であっても、サブピクチャ境界においてサンプルパディングを適用することで、サブピクチャを抽出することができる。第２に、マージモード及びＶＶＣのデコーダ側の動き洗練の期間に、動きベクトルの選択及びエクスポートは、追加のバリエーションを導入する。ＭＣＴＳエンコーダ側において適用される非正統的な動き制約と比較して、より高いコーデック効率が可能になる。第３に、画像シーケンスから１つ又は複数の抽出可能なサブピクチャを抽出して、サブビットストリーム（コヒーレントビットストリームである）を作成する場合、ＳＨ（及びＰＨＮＡＬユニット（存在する場合））を書き換える必要がない。ＨＥＶＣ ＭＣＴＳベースのサブビットストリーム抽出において、ＳＨの書き換えが必要である。なお、ＳＰＳ及びＰＰＳは、ＨＥＶＣ ＭＣＴＳ抽出及びＶＶＣサブピクチャ抽出の両方において、書き換える必要がある。しかし、一般的に、１つのビットストリームには、幾つかのパラメータセットしかなく、各ピクチャは、少なくとも１つのスライスを有するため、ＳＨの書き換えは、アプリケーションシステムにとって大きな負担となる。第４に、１枚のピクチャ内の異なるサブピクチャのスライスは、異なるＮＡＬユニットタイプを有することができる。以下、より詳細に説明するように、これは、一般的に、ピクチャにおける混合ＮＡＬユニットタイプ又は混合サブピクチャタイプと称される特徴である。第５に、ＶＶＣがサブピクチャシーケンスのＨＲＤとレベル定義を規定するため、エンコーダは、抽出可能な各サブピクチャシーケンスのサブビットストリームの一貫性を確保することができる。
２．３．３ ピクチャの混合サブピクチャタイプについて
ＡＶＣ及びＨＥＶＣでは、１枚のピクチャにおける全てのＶＣＬ ＮＡＬユニットは、同一のＮＡＬユニットタイプを持つ必要がある。ＶＶＣは、ピクチャには異なるＶＣＬ ＮＡＬユニットタイプを持つサブピクチャが混在したというオプションを導入して、ピクチャレベルだけでなく、サブピクチャレベルでもランダムアクセスをサポートする。ＶＶＣでは、サブピクチャにおけるＶＣＬ ＮＡＬユニットは、依然として同一のＮＡＬユニットタイプを持つ必要がある。
ＩＲＡＰサブピクチャからのランダムアクセスの機能は、３６０°ビデオアプリケーションに有利である。図５に示すビューポートに依存する３６０°ビデオと同様な配信方式では、空間的に隣接するビューポートのコンテンツは大きく重なり合う、即ち、ビューポート方向が変化する間に、ビューポート内のサブピクチャのごく一部だけは新しいサブピクチャに入れ替えられるが、サブピクチャの大半はビューポート内に残る。ビューポートに新たに導入されたサブピクチャのシーケンスは、ＩＲＡＰスライスから開示されなければならないが、残りのサブピクチャがビューポートの変更中にフレーム間予測を実行することが許容される場合、全体的な伝送ビットレートの大幅な低減を達成することができる。
ピクチャが単一のタイプのＮＡＬユニットのみを含むか、又は複数のタイプを含むかの指示は、ピクチャの参照されるＰＰＳにおいて提供される（即ち、ｐｐｓ＿ｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｆｌａｇというフラグを使用する）。ピクチャは、ＩＲＡＰスライスを含むサブピクチャと後続スライスを含むサブピクチャから構成することができる。ピクチャには、ＮＡＬユニットタイプＲＡＳＬとＲＡＤＬの先行ピクチャスライスを含む、異なるＮＡＬユニットタイプの他の幾つかの組み合わせが存在することが可能である。これにより、異なるビットストリームから抽出された、ｏｐｅｎ－ＧＯＰ及びｃｌｏｓｅ－ＧＯＰコーデック構造を持つサブピクチャシーケンスを、１つビットストリームにマージすることができる。
２．３．４ サブピクチャのレイアウト及びＩＤシグナリングについて
ＶＶＣのサブピクチャのレイアウトは、ＳＰＳにおいて信号通知されるため、ＣＬＶＳにおいて変更しない。各サブピクチャが、その左上隅のＣＴＵの位置と複数のＣＴＵの幅及び高さで表現されるため、そのため、サブピクチャは、ＣＴＵ粒度でピクチャをカバーする矩形領域を確保する。ピクチャ内の各サブピクチャのインデックスは、ＳＰＳにおいて信号通知されるサブピクチャの順序で決定される。
ＳＨ又はＰＨを書き換えることなく、サブピクチャシーケンスを抽出しマージできるようにするために、ＶＶＣにおけるスライスアドレス指定方式は、サブピクチャＩＤ及びサブピクチャの特定のスライスインデックスに基づいて、スライスとサブピクチャとを関連付ける。ＳＨでは、スライスを含むサブピクチャのサブピクチャＩＤとサブピクチャレベルのスライスインデックスは信号通知される。なお、特定のサブピクチャのサブピクチャＩＤの値は、そのサブピクチャインデックスの値とは異なることがある。両方の間のマッピングは、ＳＰＳ又はＰＰＳ（両方はない）において信号通知される、若しくは、暗黙的に推測される。サブピクチャＩＤのマッピングが存在する場合、サブピクチャサブビットストリーム抽出処理の期間に、ＳＰＳ及びＰＰＳを書き換える際に、サブピクチャＩＤのマッピングの書き換え又は追加の必要がある。サブピクチャＩＤは、サブピクチャレベルのスライスインデックスと共に、復号化画像のＤＰＢタイムスリット内のスライスの最初の復号化されたＣＴＵの正確な位置をデコーダに対して指示する。サブビットストリームの抽出後に、サブピクチャのサブピクチャＩＤは変化しないが、サブピクチャインデックスは変化する可能性がある。サブピクチャのスライスにおける最初のＣＴＵのラスタースキャンＣＴＵアドレスが、元のビットストリームにおける値と比較して変化しても、対応するＳＨにおける変化しないサブピクチャＩＤとサブピクチャレベルのスライスインデックスにより、抽出されたサブビットストリームの復号化画像における各ＣＴＵの位置を正しく決定する。図６は、２つのサブピクチャと４つのスライスを含む例によって、サブピクチャＩＤ、サブピクチャインデックス及びサブピクチャレベルのスライスインデックスを使用するサブピクチャの抽出を示す。
サブピクチャの抽出と同様に、サブピクチャのシグナリングについて、異なるビットストリームが協調して生成される（例えば、異なるサブピクチャＩＤを使用するが、それ以外は、ＣＴＵの大きさ、クロマフォーマット、コーデックツールなどのＳＰＳ、ＰＰＳ及びＰＨパラメータを揃えることが多い）ことを前提として、ＳＰＳとＰＰＳのみを書き換えることで、異なるビットストリームからの複数のサブピクチャを単一のビットストリームにマージすることができる。
サブピクチャとスライスはそれぞれＳＰＳ及びＰＰＳにおいて独立して信号通知されるが、一貫性のあるビットストリームを形成するために、サブピクチャとスライスレイアウトの間には固有の相互制約がある。先ず、サブピクチャが存在するには、矩形スライスを使用するとともにラスタースキャンスライスを禁止する必要がる。次に、所定のサブピクチャのスライスは、復号化順序で連続したＮＡＬユニットである必要がる。これは、サブピクチャレイアウトが、ビットストリーム内の符号化・復号化されたスライスＮＡＬユニットの順序を制限することを意味する。
２．４ ピクチャインピクチャサービスについて
ピクチャインピクチャサービスは、高分解能のピクチャに低分解能のピクチャを含める機能を提供している。このようなサービスは、ユーザに対して２つのビデオを同時に表示することができるため、分解能の高い方のビデオを主ビデオとし、分解能の低い方のビデオを補足ビデオとする。このようなピクチャインピクチャサービスは、主ビデオが標識（ｓｉｇｎａｇｅ）ビデオで補足されることで、アクセシビリティサービスを提供するために用いられる。
ＶＶＣサブピクチャは、その抽出及びマージ特性を利用することで、ピクチャインピクチャサービスに用いられる。このようなサービスでは、主ビデオは、複数のサブピクチャを利用して符号化が行われ、複数のサブピクチャの１つは、補足ビデオと同じサイズで、補足ビデオを主ビデオに合成しようとする正確な位置に位置し、抽出可能に独立して符号化される。ユーザが補足ビデオを含むサービスのバージョンを見る場合に、図７に示すように、主ビデオビットストリームから主ビデオのピクチャインピクチャ領域に対応するサブピクチャが抽出され、補足ビデオビットストリームがその主ビデオビットストリームにおける位置にマージされる。図７は、ＶＶＣサブピクチャによるピクチャインピクチャ対応の例を示している。
この場合、主ビデオと補足ビデオのピクチャは、同一のビデオ特性を共有しなければならず、特にビット深度、サンプルアスペクト比、サイズ、フレームレート、色空間、伝送特性、クロマサンプル位置が同じでなければならない。主ビデオビットストリーム及び補足ビデオビットストリームは、各ピクチャにおいてＮＡＬユニットタイプを使用する必要はない。しかし、マージには、主ビットストリームと補足ビットストリームのピクチャが同じ順序で符号化・復号化されることが必要である。
本開示では、マージサブピクチャが必要であるため、主ビデオと補足ビデオにおいて使用されるサブピクチャＩＤは重複してはならない。補足ビデオビットストリームは、任意の他のタイル又はスライス分割を有せず、１つのサブピクチャのみで構成されても、サブピクチャ情報、特にサブピクチャＩＤ及びサブピクチャＩＤ長さを信号通知することで、補足ビデオビットストリームを主ビデオビットストリームにマージする必要がある。補足ビデオビットストリームのシグナリング通知用のスライスＮＡＬユニット内のサブピクチャシンタックスエレメントのサブピクチャＩＤ長さは、主ビデオビットストリームのシグナリング通知用のスライスＮＡＬユニット内のサブピクチャＩＤのサブピクチャＩＤ長さと同じでなければならない。また、ＰＰＳ分割情報を書き換えることなく、補足ビデオビットストリームと主ビデオビットストリームのマージを簡素化させるために、主ビデオの対応する領域において、１つのスライス及び１つのタイルのみを使用して補足ビデオを符号化することは有益である。主ビデオビットストリームと補助ビデオビットストリームは、ＳＰＳ、ＰＰＳ及びピクチャヘッダーにおいて使用される同一のコーデックツールをシグナリング通知しなければならない。これには、ブロック分割のための同一の最大許容サイズ、最小許容サイズ、及びＰＰＳにおいて指示される初期量子化パラメータと同じ値（ｐｐｓ＿ｉｎｉｔ＿ｑｐ＿ｍｉｎｕｓ２６シンタックスエレメントと同じ値）を使用することが含まれている。コーデックツールの使用は、スライスヘッダーレベルで変更可能である。
主ビットストリーム及び補足ビットストリームは、ＩＳＯＢＭＦＦに基づくメディアファイル内で利用可能な場合、これらは、２つの別々のファイルフォーマットトラックに記憶することができる。
３．問題点
ＩＳＯＢＭＦＦに基づくメディアファイルにおいてピクチャインピクチャをサポートする場合に、以下の問題点が指摘されている：
１）異なるファイルフォーマットトラックを使用してピクチャインピクチャ主ビットストリーム及び補足ビットストリームのそれぞれを記憶可能であるが、ＩＳＯＢＭＦＦに基づくメディアファイル内のこのようなトラックのペアを指示するためのメカニズムが欠如している。
２）ＶＶＣサブピクチャを使用してピクチャインピクチャの体験を実現可能であるが、例えば、上述したように、主ビデオにおける目標ピクチャインピクチャ領域を示す符号化ビデオデータユニットを補足ビデオの対応するビデオデータユニットに入れ替え可能ではない場合、他のデコーダ及び方法を利用してもよい。そのため、ＩＳＯＢＭＦＦに基づくメディアファイルにおいて、このような入れ替えが可能かどうかを指示する必要がある。
３）上述した入れ替えが可能である場合、クライアント端末では、主ビデオの各ピクチャにおける符号化・復号化されたビデオデータユニットのどれがターゲット図における画像領域を代表するかを知っていなければ、入れ替えを行うことができない。そのため、この場合、ＩＳＯＢＭＦＦに基づくメディアファイルにおいて、この情報を信号通知する必要がある。
４）コンテンツ選択の目的及び他の可能な目的のために、ＩＳＯＢＭＦＦに基づくメディアファイルにおいて主ビデオにおける目標ピクチャインピクチャ領域の位置及びサイズをシグナリング通知することは有用である。
４．例示的な実施形態
上述した問題点を解決するために、以下の概括的に説明する方法が開示されている。なお、本実施形態は、一般的な概念を説明するための例として、限定的に理解されるべきではない。更に、実施形態は、個別に適用してもよいし、任意の組み合わせで適用してもよい。便宜上、ピクチャインピクチャ体験を共同で提供する主ビットストリーム及び補足ビットストリームを担持する（carry）一対のトラックは、一対のピクチャインピクチャトラック又はピクチャインピクチャトラックのペアと称される。
１）最初の問題点を解決するために、トラックがトラックリファレンスを含み、かつ、トラックリファレンスによって参照されるトラックが一対のピクチャインピクチャトラックであることを指示するように、新しいトラックリファレンスタイプが定義される。
ａ．一実施形態では、このようなトラックリファレンスの新しいタイプは、特定の値に等しいトラックリファレンスタイプ、例えば、「ｐｉｐｓ」（「ピクチャインピクチャ補足ビットストリームを参照する」という意味）で指示されるとともに、該トラックリファレンスを含むトラックは、主ビットストリームを担持し、トラックリファレンスによって参照されるトラックは、補足ビットストリームを担持する。
ｂ．別の例では、このトラックリファレンスの新しいタイプは、特定の値に等しいのトラックリファレンスタイプ、例えば、「ｐｉｐｍ」（ピクチャインピクチャ主ビットストリームを参照する」という意味）で指示されるとともに、該トラックリファレンスを含むトラックは、補足ビットストリームを担持し、トラックリファレンスによって参照されるトラックは、主ビットストリームを担持する。
ｃ．更に別の一例では、上記のような２種類のトラックリファレンスタイプが定義される。
２）第１及び第２の問題点を解決するために、主ビットストリームを担持するトラックに含まれる２種類のトラックリファレンスの新しいタイプが定義され、その一方は、補足ビットストリームの対応するビデオデータユニットで主ビデオにおける目標ピクチャインピクチャ領域を示す符号化されたビデオデータユニットを入れ替え可能な一対のピクチャインピクチャトラックを指示し、他方は、このようなビデオデータユニットの入れ替えを可能にしない一対のピクチャインピクチャトラックを指示する。
ａ．一実施形態では、この２種類のトラックリファレンスの新しいタイプは、「ｐｐｓｒ」（「ビデオデータユニットの入れ替えが可能なピクチャインピクチャ補足ビットストリームを参照する」という意味）と「ｐｐｓｎ」（「ビデオデータユニットの入れ替えを可能にしないピクチャインピクチャ補足ビットストリーム」の意味）に等しいトラックリファレンスタイプ値で指示する。
３）或いは、第１及び第２の問題点を解決するために、補足ビットストリームを担持するトラックに含まれる２種類のトラックリファレンスの新しいタイプ定義され、その一方は、補足ビットストリームの対応するビデオデータユニットで主ビデオにおける目標ピクチャインピクチャ領域を示す符号化・復号化されたビデオデータユニットを入れ替え可能な一対のピクチャインピクチャトラックを指示し、他方は、このようなビデオデータユニットの入れ替えを可能にしない一対のピクチャインピクチャトラックを指示する。
ａ．一実施形態では、この２種類のトラックリファレンスの新しいタイプは、「ｐｐｍｒ」（「ビデオデータユニットの入れ替えが可能であるピクチャインピクチャ主ビットストリームを参照する」という意味）と「ｐｐｍｎ」（「ビデオデータユニットの入れ替えを可能にしないピクチャインピクチャ主ビットストリームを参照する」という意味）に等しいトラックリファレンスタイプ値で指示する。
４）或いは、第１及び第２の問題点を解決するために、上記の第２項及び第３項に記載されたように、前記４つの種類のトラックリファレンスの新しいタイプが定義される。
５）上述した４つの問題点を解決するために、エンティティグループ化の新しいタイプが定義される。以下は詳細に説明する。
ａ．エンティティグループ化の新しいタイプは、ピクチャインピクチャエンティティグループ化と名付けられ、そのｇｒｏｕｐｉｎｇ＿ｔｙｐｅが「ｐｉｎｐ」（又は異なる名称又は異なるグループ化タイプ値であるが、以下に説明するように、同様な機能を持つ）に等しい。
ｂ．一実施形態では、エンティティグループ内の各エンティティがビデオトラックでなければならないと規定する。
ｃ．ＰｉｃＩｎＰｉｃＥｎｔｉｔｙＧｒｏｕｐＢｏｘは、ＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘを拡張することで定義され、以下の情報のうちの少なくとも１つ又は複数を乗せる：
ｉ．主ビットストリームトラックの数がＮである。ＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘ内の最初のＮ个ｅｎｔｉｔｙ＿ｉｄ値で識別されるエンティティ（即ち、ここでのトラック）は、主ビットストリームトラックであり、エンティティＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘ内の他のｅｎｔｉｔｙ＿ｉｄ値で識別されるのは、補足ビットストリームトラックである。ピクチャインピクチャ体験を再生するために、主ビットストリームトラックにおける１つの主ビットストリームトラックが選択され、補足ビットストリームトラックにおける１つの補足ビットストリームトラックが選択される。
１．或いは、主のビットストリームトラックは、インデックスリストを介してＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘ内のＥｎｔｉｔｙ＿ｉｄ値リストにシグナリング通知され、エンティティグループ内の他のエンティティ／トラックは、補足のビットストリームトラックである。
２．或いは、主ビットストリームトラックは、ｔｒａｃｋ＿ｉｄ値リストを介してシグナリング通知され、エンティティグループ内の他のエンティティ／トラックは、補足ビットストリームトラックである。
ｉｉ．主ビデオ内の目標ピクチャインピクチャ領域を代表する符号化・復号化されたビデオデータユニットを補足ビデオ中対応のビデオデータユニット入れ替え可能かどうかを指示するための指示について。
１．一実施形態では、当該指示は、ｄａｔａ＿ｕｎｉｔｓ＿ｒｅｐｌａｃａｂｌｅと称される１ビットのフラグでシグナリング通知され、値１及び０は、それぞれ、このビデオデータユニットの入れ替えを可能にすること及び可能しないことを指示する。
ｉｉｉ．主ビデオの各ピクチャにおける符号化・復号化されたビデオデータユニットのどれが目標ピクチャインピクチャ領域を示すかを指示するための領域ＩＤリストについて。
１．一実施形態では、特定のビデオデコーダについて、領域ＩＤの特定のセマンティクスを明示的に規定する必要があると規定される。
ａ．一実施形態では、以下のように規定される：ＶＶＣの場合、領域ＩＤがサブピクチャＩＤであり、符号化・復号化されたビデオデータユニットがＶＣＬ ＮＡＬユニットである。主ビデオにおける目標ピクチャインピクチャ領域を示すＶＣＬ ＮＡＬユニットは、これらのサブピクチャＩＤを持つＶＣＬ ＮＡＬユニットであり、これらのサブピクチャＩＤは、補足ビデオの対応するＶＣＬ ＮＡＬユニットにおけるサブピクチャＩＤと同じである（一般的に、補足ビデオにおける１つ画面の全てのＶＣＬ ＮＡＬユニットは、明確に信号通知される同一のサブピクチャＩＤを共用し、この場合、領域ＩＤのリストには、領域ＩＤが１つしか存在しない）。
ｂ．一実施形態では、以下のように規定される：ＶＶＣの場合、ビデオデコーダに送信される前に、クライアント端末では、補足ビデオの対応するＶＣＬ ＮＡＬユニットを使用して、主ビデオにおける目標ピクチャインピクチャ領域を示す符号化・復号化されたビデオデータユニット（即ち、ＶＣＬ ＮＡＬユニット）を入れ替えるするように選択すると、対応するＶＣＬ ＮＡＬユニットの順序を変更することなく、各サブピクチャＩＤについて、主ビデオにおけるＶＣＬ ＮＡＬユニットを補足ビデオ中具有該サブピクチャＩＤの対応するＶＣＬ ＮＡＬユニットに入れ替える。
ｉｖ．補足ビデオを埋込／重畳するための主ビデオにおける位置及びサイズは、サイズの点で主ビデオよりも小さい。
１．一実施形態では、４つの値（ｘ、ｙ、幅、高さ）でシグナリング通知され、ｘ、ｙは、領域の左上隅の位置を指定し、幅及び高さは、領域の幅及び高さを指定する。単位は、輝度サンプル／ピクセルであってもよい。
２．一実施形態では、ｄａｔａ＿ｕｎｉｔｓ＿ｒｅｐｌａｃａｂｌｅが１に等しく、位置及びサイズの情報が存在する場合、該位置及びサイズは、主ビデオにおける目標ピクチャインピクチャ領域を正しく示すべきであると規定される。
３．一実施形態では、ｄａｔａ＿ｕｎｉｔｓ＿ｒｅｐｌａｃａｂｌｅが０に等しく、位置及びサイズの情報が存する場合、位置及びサイズの情報は、補足ビデオを埋め込んでカバーするための好適な領域（即ち、クライアント端末では、補足ビデオを主ビデオの異なる領域に重畳することを選択可能である）を指示すると規定される。
４．一実施形態では、ｄａｔａ＿ｕｎｉｔｓ＿ｒｅｐｌａｃａｂｌｅが０に等しく、位置及びサイズの情報が存在しない場合、どこで補足ビデオをカバーするかに関する情報又は推奨はなく、クライアントの選択に完全に依存すると規定される。
５．実施形態
以下は、第５項及び上記のセクション４において概括的に説明した幾つかのサブ項目の幾つかの例示的な実施形態の実施形態である。
これらの実施形態は、ＩＳＯＢＭＦＦに適用可能である。
５．１ ピクチャインピクチャエンティティグループ化について
５．１．１ 定義について
ピクチャインピクチャサービスは、空間分解能の低い方のビデオを空間分解能の高い方のビデオに含める機能を提供し、それぞれは、補足ビデオ及び主ビデオと呼ばれる。主ビデオを含むように指示されるトラックから１つのトラックを選択し、他のトラックから１つのトラック（補足ビデオを含む）を選択することで、ｇｒｏｕｐｉｎｇ＿ｔｙｐｅが「ｐｉｎｐ」に等しいの同一のエンティティグループ内のトラックは、ピクチャインピクチャサービスに対応するために用いられる。
ピクチャインピクチャエンティティグループ内の全てのエンティティは何れもビデオトラックであるべきである。
５．１．２ シンタックスについて
ａｌｉｇｎｅｄ（８）ｃｌａｓＳＰｉｃＩｎＰｉｃＥｎｔｉｔｙＧｒｏｕｐＢｏｘｅｘｔｅｎｄＳＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘ（「ｐｉｎｐ」，０，０）｛
ｕｎｓｉｇｎｅＤｉｎｔ（８）ｎｕｍ＿ｍａｉｎ＿ｖｉｄｅｏ＿ｔｒａｃｋｓ；
ｕｎｓｉｇｎｅＤｉｎｔ（１）ｄａｔａ＿ｕｎｉｔｓ＿ｒｅｐｌａｃａｂｌｅ；
ｕｎｓｉｇｎｅＤｉｎｔ（１）ｐｉｎｐ＿ｗｉｎｄｏｗ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ；
ｂｉｔ（６）ｒｅｓｅｒｖｅＤ＝０；
ｉｆ（ｄａｔａ＿ｕｎｉｔｓ＿ｒｅｐｌａｃａｂｌｅ）｛
ｕｎｓｉｇｎｅＤｉｎｔ（８）ｎｕｍ＿ｒｅｇｉｏｎ＿ｉｄｓ；
ｆｏｒ（ｉ＝０；ｉ＜ｎｕｍ＿ｒｅｇｉｏｎ＿ｉｄｓ；ｉ＋＋）
ｕｎｓｉｇｎｅＤｉｎｔ（１６）ｒｅｇｉｏｎ＿ｉｄ［ｉ］；
｝
ｉｆ（ｐｉｎｐ＿ｗｉｎｄｏｗ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ）｛
ｕｎｓｉｇｎｅＤｉｎｔ（１６）ｘ；
ｕｎｓｉｇｎｅＤｉｎｔ（１６）ｙ；
ｕｎｓｉｇｎｅＤｉｎｔ（１６）ｗｉｄｔｈ；
ｕｎｓｉｇｎｅＤｉｎｔ（１６）ｈｅｉｇｈｔ；
｝
｝
５．１．３ セマンティクスについて
ｎｕｍ＿ｍａｉｎ＿ｖｉｄｅｏ＿ｔｒａｃｋｓは、そのエンティティグループ内のピクチャインピクチャ主ビデオを担持するトラック数を指定する。
ｄａｔａ＿ｕｎｉｔｓ＿ｒｅｐｌａｃａｂｌｅは、主ビデオ内の、目標ピクチャインピクチャ領域を示す符号化・復号化されたビデオデータユニットが、補足ビデオの対応するビデオデータユニットで入れ替え可能かどうかを指示する。値１は、このようなビデオデータユニットの入れ替えを可能にすることを指示し、値０は、このようなビデオデータユニットの入れ替えを可能にしないことを指示する。
ｄａｔａ＿ｕｎｉｔｓ＿ｒｅｐｌａｃａｂｌｅが１に等しい場合、デコードのためにビデオデコーダに送信される前に、プレーヤは、補足ビデオに対応する符号化・復号化されたビデオデータユニットで主ビデオにおける目標ピクチャインピクチャ領域を示す符号化・復号化されたビデオデータユニットを入れ替えることを選択可能である。この場合、主ビデオにおける特定のピクチャについて、補足ビデオの対応するビデオデータユニットは、補足ビデオトラックにおける復号化時間同期サンプル内の符号化・復号化されたビデオデータユニットの全てである。ＶＶＣの場合、ビデオデコーダに送信される前に、クライアント端末では、主ビデオにおける目標ピクチャインピクチャ領域を示す符号化・復号化されたビデオデータユニット（即ち、ＶＣＬ ＮＡＬユニット）を補足ビデオにおける対応ＶＣＬ ＮＡＬユニットに入れ替えることを選択すると、各サブピクチャＩＤについて、対応ＶＣＬ ＮＡＬユニットの順序を変更することなく、主ビデオにおけるＶＣＬ ＮＡＬユニットが補足ビデオのける該サブピクチャＩＤを持つ対応ＶＣＬ ＮＡＬユニットに入れ替えられる。
ｐｉｎｐ＿ｗｉｎｄｏｗ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔが１に等しいことは、フィールドｘ、ｙ、幅及び高さが存在すると指定する。値０は、これらのフィールドが存在しないと指定する。
ｎｕｍ＿ｒｅｇｉｏｎ＿ｉｄｓは、後続のフィールドＲｅｇｉｏｎ＿ｉｄ［ｉ］の数を指定する。
ｒｅｇｉｏｎ＿ｉｄ［ｉ］は、目標ピクチャインピクチャ領域を示す符号化・復号化されたビデオデータユニットのｉ番目のＩＤを指定する。
特定のビデオデコーダについて、領域ＩＤの特定のセマンティクスを明示的に規定する必要がある。ＶＶＣの場合、領域ＩＤがサブピクチャＩＤであり、符号化・復号化されたビデオデータユニットがＶＣＬ ＮＡＬユニットである。主ビデオにおける目標ピクチャインピクチャ領域を示すＶＣＬ ＮＡＬユニットは、これらのサブピクチャＩＤを持つＶＣＬ ＮＡＬユニットであり、これらのサブピクチャＩＤは、補足ビデオの対応するＶＣＬ ＮＡＬユニット内のサブピクチャＩＤと同じである。
ｘは、主ビデオにおける目標ピクチャインピクチャ領域の左上隅に位置する符号化ビデオ画素（サンプル）の水平位置を指定する。単位は、ビデオ画素（サンプル）である。
ｙは、主ビデオにおける目標ピクチャインピクチャ領域の左上隅に位置する符号化ビデオ画素（サンプル）の垂直位置を指定する。単位は、ビデオ画素（サンプル）である。
幅は、主ビデオにおける目標ピクチャインピクチャ領域の幅を指定する。単位は、ビデオ画素（サンプル）である。
高さは、主ビデオにおける目標ピクチャインピクチャ領域の高さを指定する。単位は、ビデオ画素（サンプル）である。
１．概要
本開示は、ビデオファイルフォーマットに関する。具体的には、メディアファイルにおけるピクチャインピクチャ対応に関する。メディアファイルフォーマット、例えばＩＳＯベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ）又はその拡張について、個別に又は様々な組み合わせでこれらの構想を適用することができる。
２．背景技術
２．１ ビデオコーデック規格について
ビデオコーデック規格は、主によく知られたＩＴＵ－Ｔ及びＩＳＯ／ＩＥＣ規格の開発を通じて発展してきた。ＩＴＵ－Ｔは、Ｈ．２６１及びＨ．２６３を制定し、ＩＳＯ／ＩＥＣは、ＭＰＥＧ－１及びＭＰＥＧ－４Ｖｉｓｕａｌを制定し、２つの組織は、Ｈ．２６２／ＭＰＥＧ－２Ｖｉｄｅｏ、Ｈ．２６４／ＭＰＥＧ－４高度なビデオコーデック（ＡＶＣ）及びＨ．２６５／ＨＥＶＣ規格を共同制定した。Ｈ．２６２以降、ビデオコーデック規格は、時間予測及び変換コーデックを使用したハイブリッドビデオコーデックアーキテクチャに基づく。ＨＥＶＣ以外の将来のビデオ符号化技術を探求するために、ＶＣＥＧとＭＰＥＧは、２０１５年に共同ビデオ探索チーム（ＪｏｉｎｔＶｉｄｅｏＥｘｐｌｏｒａｔｉｏｎＴｅａｍ、ＪＶＥＴ）を共同で設立した。それ以来、ＪＶＥＴは、多くの新しいアプローチを採用し、共同探索モデル（ＪＥＭ）と呼ばれる参照ソフトウェアに組み込んでいた。汎用ビデオコーデック（ＶＶＣ）プロジェクトの正式発足に伴い、ＪＶＥＴは、その名称を共同ビデオ専門家チーム（ＪｏｉｎｔＶｉｄｅｏＥｘｐｅｒｔＳＴｅａｍ、ＪＶＥＴ）に変更した。ＶＶＣは、ＪＶＥＴが２０２０年７月１日に終わった第１９回会合で最終決定された、ＨＥＶＣと比較してビットレートを５０％低減させることを目標とする新しいコーデック規格である。
汎用ビデオコーデック（ＶＶＣ）規格（ＩＴＵ－Ｔ Ｈ．２６６｜ＩＳＯ／ＩＥＣ２３０９０－３）及び関連する多機能補足強調情報（ＶＳＥＩ）規格（ＩＴＵ－Ｔ Ｈ．２７４｜ＩＳＯ／ＩＥＣ２３００２－７）は、従来の用途（例えば、テレビ放送、ビデオ会議又は記憶媒体からの再生など）、及びより新しく高度な用途（例えば、適応ビットレートストリーミング、ビデオ領域抽出、及び複数の符号化・復号化されたビデオビットストリーム、マルチビュービデオ、拡張レイヤコーデック及びビューポート適応（ｖｉｅｗｐｏｒｔ－ａｄａｐｔｉｖｅ）３６０°没入型メディアのコンテンツの組み合わせ及びマージ）の両方を含む、最も幅広い用途で使用するように設計されている。
エレメンタリービデオコーデック（ＥＶＣ）規格（ＩＳＯ／ＩＥＣ２３０９４－１）は、ＭＰＥＧが最近開発したもう１つのビデオコーデック規格である。
２．２ ファイルフォーマット規格について
メディアストリームアプリケーションは、通常、ＩＰ、ＴＣＰとＨＴＴＰ伝送方法に基づくとともに、通常、例えばＩＳＯベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ）などのファイルフォーマットに依存する。これらのストリーミングシステムのうちの１つは、ＨＴＴＰに準拠する動的適応ストリーミング（ＤＡＳＨ）である。ＩＳＯＢＭＦＦ及びＤＡＳＨを持つビデオフォーマットを使用するには、ビデオコンテンツをＩＳＯＢＭＦＦのトラック及びＤＡＳＨの表現やクリップにカプセル化するための、ビデオフォーマット固有のファイルフォーマット規格、例えばＡＶＣファイルフォーマットおよびＨＥＶＣファイルフォーマットが必要である。ビデオビットストリームに関する重要な情報、例えば、プロファイル、レイヤ、クラス及び多くの他の情報は、コンテンツの選択目的、例えば、ストリーミングセッション開示時の初期化及びストリーミングセッション期間のストリーミング適応の両方の適切なメディアクリップの選択目的のために、ファイルフォーマットクラスメタデータ及び／又はＤＡＳＨメディアプレゼンテーション記述（ＭＰＤ）として披露される必要がある。
同様に、ＩＳＯＢＭＦＦ画像フォーマットを使用するには、画像フォーマット固有のファイルフォーマット規格、例えば、ＡＶＣ画像ファイルフォーマットおよびＨＥＶＣ画像ファイルフォーマットが必要である。
ＩＳＯＢＭＦＦに基づくＶＶＣビデオコンテンツを記憶するためのファイルフォーマットであるＶＶＣビデオファイルフォーマットは、現在、ＭＰＥＧによって開発されている。ＶＶＣによりエンコードされた画像コンテンツを記憶しＩＳＯＢＭＦＦに基づくＶＶＣ画像ファイルフォーマットは、現在、ＭＰＥＧにより開発されている。
２．３ ＶＶＣにおけるピクチャ分割及びサブピクチャについて
ＶＶＣでは、１枚のピクチャは、１つ又は複数のタイル行と１つ又は複数のタイル列に分割される。タイルは、ピクチャをカバーする矩形領域のＣＴＵシーケンスである。タイルにおけるＣＴＵは、このタイルにおいてラスタースキャン順序でスキャンされる。
スライスは、ピクチャのタイル内の整数個の完全なタイル又は整数個の連続した完全なＣＴＵ行からなる。
２種類のスライスモード、即ち、ラスタースキャンスライスモードと矩形スライスモードはサポートされる。ラスタースキャンスライスモードでは、スライスは、ピクチャのタイルラスタースキャン中の完全なタイルシーケンスを含む。矩形スライスモードでは、スライスは、ピクチャの矩形領域を共同で形成する複数の完全なタイル、又はピクチャの矩形領域を共同で形成する１つのタイルの複数の連続した完全なＣＴＵ行を含む。矩形スライス内のタイルは、当該スライスに対応する矩形領域内で、タイルラスタースキャン順序でスキャンされる。
サブピクチャは、ピクチャの矩形領域を共同でカバーする１つ又は複数のスライスを含む。
２．３．１ サブピクチャの概念及び機能について
ＶＶＣでは、例えば、図４に示すように、各サブピクチャは、ピクチャの矩形領域を共同でカバーする１つ又は複数の完全な矩形スライスからなる。サブピクチャは、抽出可能（即ち、同一の画像の他のサブピクチャ及び復号化の順序での以前の画像の他のサブピクチャとは独立して符号化及び復号化される）又は抽出不可能であると限定されてもよい。サブピクチャが抽出可能であるか抽出不可能であるかにかかわらず、エンコーダは、各サブピクチャに対して個別にサブピクチャ境界を超えてループフィルタリング（デブロッキング、ＳＡＯと及びＡＬＦを含む）を適用するかどうかを制御することができる。
機能的には、サブピクチャは、ＨＥＶＣにおける動き制約付きタイルセット（ｍｏｔｉｏｎ－ｃｏｎｓｔｒａｉｎｅＤｔｉｌｅｓｅｔ、ＭＣＴＳ）に似ている。両方の何れも、例えばビューポートに関する３６０°ビデオストリーム最適化及び感心領域（ｒｅｇｉｏｎｏｆｉｎｔｅｒｅｓｔ、ＲＯＩ）アプリケーションなどの応用例について、独立してコーデックを行うこと、及び符号化・復号化されたピクチャシーケンスの矩形サブセットを抽出することが許容される。
３６０°ビデオストリーム（別名：全方位ビデオ）では、任意の特定の時点において、全方位ビデオ球全体のサブセット（即ち、現在のビューポート）のみがユーザに提示され、ユーザは、いつでも、彼／彼女の頭を回動させて視聴方向及び現在のビューポートを変更することができる。同時に、少なくともクライアント端末の現在のビューポートによってカバーされていない領域について、幾つかの低品質の表現を有することが望ましく、ユーザが突然彼／彼女の視聴方向を球面上の任意の位置に変更することを防止するように、ユーザに対してレンダリングされることを用意しておく。任意の所定の時点において、球面上の全方位ビデオの高品質表現は、ユーザに対するレンダリングが必要である現在のビューポートにのみ必要になる。このような最適化は、図４に示すように、全方位ビデオ全体の高品質表現をサブピクチャに適切な粒度で分割することで実現することができる。ここで、図４は、左側に位置する高分解能を持つ１２つのサブピクチャと、右側に位置する低分解能を持つ全方位ビデオの残りの１２つのサブピクチャとを有する。
別の代表的なサブピクチャによるビューポート関連３６０°ビデオ配信方式は、図５に示すように、完全なビデオの高分解能表現のみがサブピクチャで構成される一方で、完全なビデオの低分解能表現が、サブピクチャを使用せず、高分解能表現よりも少ない頻度のＲＡＰで符号化及び復号化することができる。クライアント端末において、低分解能の完全なビデオを受信するが、高分解能のビデオについては、現在のビューポートをカバーするサブピクチャのみを受信して復号化する。
２．３．２ サブピクチャとＭＣＴＳとの間の違いについて
サブピクチャとＭＣＴＳとの間には、幾つかの重要な設計上での違いがある。第１に、ピクチャの境界と同様に、ＶＶＣのサブピクチャ特徴は、符号化ブロックの動きベクトルがサブピクチャ外側へ指向することを許容する。この場合であっても、サブピクチャ境界においてサンプルパディングを適用することで、サブピクチャを抽出することができる。第２に、マージモード及びＶＶＣのデコーダ側の動き洗練の期間に、動きベクトルの選択及びエクスポートは、追加のバリエーションを導入する。ＭＣＴＳエンコーダ側において適用される非正統的な動き制約と比較して、より高いコーデック効率が可能になる。第３に、画像シーケンスから１つ又は複数の抽出可能なサブピクチャを抽出して、サブビットストリーム（コヒーレントビットストリームである）を作成する場合、ＳＨ（及びＰＨＮＡＬユニット（存在する場合））を書き換える必要がない。ＨＥＶＣ ＭＣＴＳベースのサブビットストリーム抽出において、ＳＨの書き換えが必要である。なお、ＳＰＳ及びＰＰＳは、ＨＥＶＣ ＭＣＴＳ抽出及びＶＶＣサブピクチャ抽出の両方において、書き換える必要がある。しかし、一般的に、１つのビットストリームには、幾つかのパラメータセットしかなく、各ピクチャは、少なくとも１つのスライスを有するため、ＳＨの書き換えは、アプリケーションシステムにとって大きな負担となる。第４に、１枚のピクチャ内の異なるサブピクチャのスライスは、異なるＮＡＬユニットタイプを有することができる。以下、より詳細に説明するように、これは、一般的に、ピクチャにおける混合ＮＡＬユニットタイプ又は混合サブピクチャタイプと称される特徴である。第５に、ＶＶＣがサブピクチャシーケンスのＨＲＤとレベル定義を規定するため、エンコーダは、抽出可能な各サブピクチャシーケンスのサブビットストリームの一貫性を確保することができる。
２．３．３ ピクチャの混合サブピクチャタイプについて
ＡＶＣ及びＨＥＶＣでは、１枚のピクチャにおける全てのＶＣＬ ＮＡＬユニットは、同一のＮＡＬユニットタイプを持つ必要がある。ＶＶＣは、ピクチャには異なるＶＣＬ ＮＡＬユニットタイプを持つサブピクチャが混在したというオプションを導入して、ピクチャレベルだけでなく、サブピクチャレベルでもランダムアクセスをサポートする。ＶＶＣでは、サブピクチャにおけるＶＣＬ ＮＡＬユニットは、依然として同一のＮＡＬユニットタイプを持つ必要がある。
ＩＲＡＰサブピクチャからのランダムアクセスの機能は、３６０°ビデオアプリケーションに有利である。図５に示すビューポートに依存する３６０°ビデオと同様な配信方式では、空間的に隣接するビューポートのコンテンツは大きく重なり合う、即ち、ビューポート方向が変化する間に、ビューポート内のサブピクチャのごく一部だけは新しいサブピクチャに入れ替えられるが、サブピクチャの大半はビューポート内に残る。ビューポートに新たに導入されたサブピクチャのシーケンスは、ＩＲＡＰスライスから開示されなければならないが、残りのサブピクチャがビューポートの変更中にフレーム間予測を実行することが許容される場合、全体的な伝送ビットレートの大幅な低減を達成することができる。
ピクチャが単一のタイプのＮＡＬユニットのみを含むか、又は複数のタイプを含むかの指示は、ピクチャの参照されるＰＰＳにおいて提供される（即ち、ｐｐｓ＿ｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｆｌａｇというフラグを使用する）。ピクチャは、ＩＲＡＰスライスを含むサブピクチャと後続スライスを含むサブピクチャから構成することができる。ピクチャには、ＮＡＬユニットタイプＲＡＳＬとＲＡＤＬの先行ピクチャスライスを含む、異なるＮＡＬユニットタイプの他の幾つかの組み合わせが存在することが可能である。これにより、異なるビットストリームから抽出された、ｏｐｅｎ－ＧＯＰ及びｃｌｏｓｅ－ＧＯＰコーデック構造を持つサブピクチャシーケンスを、１つビットストリームにマージすることができる。
２．３．４ サブピクチャのレイアウト及びＩＤシグナリングについて
ＶＶＣのサブピクチャのレイアウトは、ＳＰＳにおいて信号通知されるため、ＣＬＶＳにおいて変更しない。各サブピクチャが、その左上隅のＣＴＵの位置と複数のＣＴＵの幅及び高さで表現されるため、そのため、サブピクチャは、ＣＴＵ粒度でピクチャをカバーする矩形領域を確保する。ピクチャ内の各サブピクチャのインデックスは、ＳＰＳにおいて信号通知されるサブピクチャの順序で決定される。
ＳＨ又はＰＨを書き換えることなく、サブピクチャシーケンスを抽出しマージできるようにするために、ＶＶＣにおけるスライスアドレス指定方式は、サブピクチャＩＤ及びサブピクチャの特定のスライスインデックスに基づいて、スライスとサブピクチャとを関連付ける。ＳＨでは、スライスを含むサブピクチャのサブピクチャＩＤとサブピクチャレベルのスライスインデックスは信号通知される。なお、特定のサブピクチャのサブピクチャＩＤの値は、そのサブピクチャインデックスの値とは異なることがある。両方の間のマッピングは、ＳＰＳ又はＰＰＳ（両方はない）において信号通知される、若しくは、暗黙的に推測される。サブピクチャＩＤのマッピングが存在する場合、サブピクチャサブビットストリーム抽出処理の期間に、ＳＰＳ及びＰＰＳを書き換える際に、サブピクチャＩＤのマッピングの書き換え又は追加の必要がある。サブピクチャＩＤは、サブピクチャレベルのスライスインデックスと共に、復号化画像のＤＰＢタイムスリット内のスライスの最初の復号化されたＣＴＵの正確な位置をデコーダに対して指示する。サブビットストリームの抽出後に、サブピクチャのサブピクチャＩＤは変化しないが、サブピクチャインデックスは変化する可能性がある。サブピクチャのスライスにおける最初のＣＴＵのラスタースキャンＣＴＵアドレスが、元のビットストリームにおける値と比較して変化しても、対応するＳＨにおける変化しないサブピクチャＩＤとサブピクチャレベルのスライスインデックスにより、抽出されたサブビットストリームの復号化画像における各ＣＴＵの位置を正しく決定する。図６は、２つのサブピクチャと４つのスライスを含む例によって、サブピクチャＩＤ、サブピクチャインデックス及びサブピクチャレベルのスライスインデックスを使用するサブピクチャの抽出を示す。
サブピクチャの抽出と同様に、サブピクチャのシグナリングについて、異なるビットストリームが協調して生成される（例えば、異なるサブピクチャＩＤを使用するが、それ以外は、ＣＴＵの大きさ、クロマフォーマット、コーデックツールなどのＳＰＳ、ＰＰＳ及びＰＨパラメータを揃えることが多い）ことを前提として、ＳＰＳとＰＰＳのみを書き換えることで、異なるビットストリームからの複数のサブピクチャを単一のビットストリームにマージすることができる。
サブピクチャとスライスはそれぞれＳＰＳ及びＰＰＳにおいて独立して信号通知されるが、一貫性のあるビットストリームを形成するために、サブピクチャとスライスレイアウトの間には固有の相互制約がある。先ず、サブピクチャが存在するには、矩形スライスを使用するとともにラスタースキャンスライスを禁止する必要がる。次に、所定のサブピクチャのスライスは、復号化順序で連続したＮＡＬユニットである必要がる。これは、サブピクチャレイアウトが、ビットストリーム内の符号化・復号化されたスライスＮＡＬユニットの順序を制限することを意味する。
２．４ ピクチャインピクチャサービスについて
ピクチャインピクチャサービスは、高分解能のピクチャに低分解能のピクチャを含める機能を提供している。このようなサービスは、ユーザに対して２つのビデオを同時に表示することができるため、分解能の高い方のビデオを主ビデオとし、分解能の低い方のビデオを補足ビデオとする。このようなピクチャインピクチャサービスは、主ビデオが標識（ｓｉｇｎａｇｅ）ビデオで補足されることで、アクセシビリティサービスを提供するために用いられる。
ＶＶＣサブピクチャは、その抽出及びマージ特性を利用することで、ピクチャインピクチャサービスに用いられる。このようなサービスでは、主ビデオは、複数のサブピクチャを利用して符号化が行われ、複数のサブピクチャの１つは、補足ビデオと同じサイズで、補足ビデオを主ビデオに合成しようとする正確な位置に位置し、抽出可能に独立して符号化される。ユーザが補足ビデオを含むサービスのバージョンを見る場合に、図７に示すように、主ビデオビットストリームから主ビデオのピクチャインピクチャ領域に対応するサブピクチャが抽出され、補足ビデオビットストリームがその主ビデオビットストリームにおける位置にマージされる。図７は、ＶＶＣサブピクチャによるピクチャインピクチャ対応の例を示している。
この場合、主ビデオと補足ビデオのピクチャは、同一のビデオ特性を共有しなければならず、特にビット深度、サンプルアスペクト比、サイズ、フレームレート、色空間、伝送特性、クロマサンプル位置が同じでなければならない。主ビデオビットストリーム及び補足ビデオビットストリームは、各ピクチャにおいてＮＡＬユニットタイプを使用する必要はない。しかし、マージには、主ビットストリームと補足ビットストリームのピクチャが同じ順序で符号化・復号化されることが必要である。
本開示では、マージサブピクチャが必要であるため、主ビデオと補足ビデオにおいて使用されるサブピクチャＩＤは重複してはならない。補足ビデオビットストリームは、任意の他のタイル又はスライス分割を有せず、１つのサブピクチャのみで構成されても、サブピクチャ情報、特にサブピクチャＩＤ及びサブピクチャＩＤ長さを信号通知することで、補足ビデオビットストリームを主ビデオビットストリームにマージする必要がある。補足ビデオビットストリームのシグナリング通知用のスライスＮＡＬユニット内のサブピクチャシンタックスエレメントのサブピクチャＩＤ長さは、主ビデオビットストリームのシグナリング通知用のスライスＮＡＬユニット内のサブピクチャＩＤのサブピクチャＩＤ長さと同じでなければならない。また、ＰＰＳ分割情報を書き換えることなく、補足ビデオビットストリームと主ビデオビットストリームのマージを簡素化させるために、主ビデオの対応する領域において、１つのスライス及び１つのタイルのみを使用して補足ビデオを符号化することは有益である。主ビデオビットストリームと補助ビデオビットストリームは、ＳＰＳ、ＰＰＳ及びピクチャヘッダーにおいて使用される同一のコーデックツールをシグナリング通知しなければならない。これには、ブロック分割のための同一の最大許容サイズ、最小許容サイズ、及びＰＰＳにおいて指示される初期量子化パラメータと同じ値（ｐｐｓ＿ｉｎｉｔ＿ｑｐ＿ｍｉｎｕｓ２６シンタックスエレメントと同じ値）を使用することが含まれている。コーデックツールの使用は、スライスヘッダーレベルで変更可能である。
主ビットストリーム及び補足ビットストリームは、ＩＳＯＢＭＦＦに基づくメディアファイル内で利用可能な場合、これらは、２つの別々のファイルフォーマットトラックに記憶することができる。
３．問題点
ＩＳＯＢＭＦＦに基づくメディアファイルにおいてピクチャインピクチャをサポートする場合に、以下の問題点が指摘されている：
１）異なるファイルフォーマットトラックを使用してピクチャインピクチャ主ビットストリーム及び補足ビットストリームのそれぞれを記憶可能であるが、ＩＳＯＢＭＦＦに基づくメディアファイル内のこのようなトラックのペアを指示するためのメカニズムが欠如している。
２）ＶＶＣサブピクチャを使用してピクチャインピクチャの体験を実現可能であるが、例えば、上述したように、主ビデオにおける目標ピクチャインピクチャ領域を示す符号化ビデオデータユニットを補足ビデオの対応するビデオデータユニットに入れ替え可能ではない場合、他のデコーダ及び方法を利用してもよい。そのため、ＩＳＯＢＭＦＦに基づくメディアファイルにおいて、このような入れ替えが可能かどうかを指示する必要がある。
３）上述した入れ替えが可能である場合、クライアント端末では、主ビデオの各ピクチャにおける符号化・復号化されたビデオデータユニットのどれがターゲット図における画像領域を代表するかを知っていなければ、入れ替えを行うことができない。そのため、この場合、ＩＳＯＢＭＦＦに基づくメディアファイルにおいて、この情報を信号通知する必要がある。
４）コンテンツ選択の目的及び他の可能な目的のために、ＩＳＯＢＭＦＦに基づくメディアファイルにおいて主ビデオにおける目標ピクチャインピクチャ領域の位置及びサイズをシグナリング通知することは有用である。
４．例示的な実施形態
上述した問題点を解決するために、以下の概括的に説明する方法が開示されている。なお、本実施形態は、一般的な概念を説明するための例として、限定的に理解されるべきではない。更に、実施形態は、個別に適用してもよいし、任意の組み合わせで適用してもよい。便宜上、ピクチャインピクチャ体験を共同で提供する主ビットストリーム及び補足ビットストリームを担持する（carry）一対のトラックは、一対のピクチャインピクチャトラック又はピクチャインピクチャトラックのペアと称される。
１）最初の問題点を解決するために、トラックがトラックリファレンスを含み、かつ、トラックリファレンスによって参照されるトラックが一対のピクチャインピクチャトラックであることを指示するように、新しいトラックリファレンスタイプが定義される。
ａ．一実施形態では、このようなトラックリファレンスの新しいタイプは、特定の値に等しいトラックリファレンスタイプ、例えば、「ｐｉｐｓ」（「ピクチャインピクチャ補足ビットストリームを参照する」という意味）で指示されるとともに、該トラックリファレンスを含むトラックは、主ビットストリームを担持し、トラックリファレンスによって参照されるトラックは、補足ビットストリームを担持する。
ｂ．別の例では、このトラックリファレンスの新しいタイプは、特定の値に等しいのトラックリファレンスタイプ、例えば、「ｐｉｐｍ」（ピクチャインピクチャ主ビットストリームを参照する」という意味）で指示されるとともに、該トラックリファレンスを含むトラックは、補足ビットストリームを担持し、トラックリファレンスによって参照されるトラックは、主ビットストリームを担持する。
ｃ．更に別の一例では、上記のような２種類のトラックリファレンスタイプが定義される。
２）第１及び第２の問題点を解決するために、主ビットストリームを担持するトラックに含まれる２種類のトラックリファレンスの新しいタイプが定義され、その一方は、補足ビットストリームの対応するビデオデータユニットで主ビデオにおける目標ピクチャインピクチャ領域を示す符号化されたビデオデータユニットを入れ替え可能な一対のピクチャインピクチャトラックを指示し、他方は、このようなビデオデータユニットの入れ替えを可能にしない一対のピクチャインピクチャトラックを指示する。
ａ．一実施形態では、この２種類のトラックリファレンスの新しいタイプは、「ｐｐｓｒ」（「ビデオデータユニットの入れ替えが可能なピクチャインピクチャ補足ビットストリームを参照する」という意味）と「ｐｐｓｎ」（「ビデオデータユニットの入れ替えを可能にしないピクチャインピクチャ補足ビットストリーム」の意味）に等しいトラックリファレンスタイプ値で指示する。
３）或いは、第１及び第２の問題点を解決するために、補足ビットストリームを担持するトラックに含まれる２種類のトラックリファレンスの新しいタイプ定義され、その一方は、補足ビットストリームの対応するビデオデータユニットで主ビデオにおける目標ピクチャインピクチャ領域を示す符号化・復号化されたビデオデータユニットを入れ替え可能な一対のピクチャインピクチャトラックを指示し、他方は、このようなビデオデータユニットの入れ替えを可能にしない一対のピクチャインピクチャトラックを指示する。
ａ．一実施形態では、この２種類のトラックリファレンスの新しいタイプは、「ｐｐｍｒ」（「ビデオデータユニットの入れ替えが可能であるピクチャインピクチャ主ビットストリームを参照する」という意味）と「ｐｐｍｎ」（「ビデオデータユニットの入れ替えを可能にしないピクチャインピクチャ主ビットストリームを参照する」という意味）に等しいトラックリファレンスタイプ値で指示する。
４）或いは、第１及び第２の問題点を解決するために、上記の第２項及び第３項に記載されたように、前記４つの種類のトラックリファレンスの新しいタイプが定義される。
５）上述した４つの問題点を解決するために、エンティティグループ化の新しいタイプが定義される。以下は詳細に説明する。
ａ．エンティティグループ化の新しいタイプは、ピクチャインピクチャエンティティグループ化と名付けられ、そのｇｒｏｕｐｉｎｇ＿ｔｙｐｅが「ｐｉｎｐ」（又は異なる名称又は異なるグループ化タイプ値であるが、以下に説明するように、同様な機能を持つ）に等しい。
ｂ．一実施形態では、エンティティグループ内の各エンティティがビデオトラックでなければならないと規定する。
ｃ．ＰｉｃＩｎＰｉｃＥｎｔｉｔｙＧｒｏｕｐＢｏｘは、ＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘを拡張することで定義され、以下の情報のうちの少なくとも１つ又は複数を乗せる：
ｉ．主ビットストリームトラックの数がＮである。ＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘ内の最初のＮ个ｅｎｔｉｔｙ＿ｉｄ値で識別されるエンティティ（即ち、ここでのトラック）は、主ビットストリームトラックであり、エンティティＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘ内の他のｅｎｔｉｔｙ＿ｉｄ値で識別されるのは、補足ビットストリームトラックである。ピクチャインピクチャ体験を再生するために、主ビットストリームトラックにおける１つの主ビットストリームトラックが選択され、補足ビットストリームトラックにおける１つの補足ビットストリームトラックが選択される。
１．或いは、主のビットストリームトラックは、インデックスリストを介してＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘ内のＥｎｔｉｔｙ＿ｉｄ値リストにシグナリング通知され、エンティティグループ内の他のエンティティ／トラックは、補足のビットストリームトラックである。
２．或いは、主ビットストリームトラックは、ｔｒａｃｋ＿ｉｄ値リストを介してシグナリング通知され、エンティティグループ内の他のエンティティ／トラックは、補足ビットストリームトラックである。
ｉｉ．主ビデオ内の目標ピクチャインピクチャ領域を代表する符号化・復号化されたビデオデータユニットを補足ビデオ中対応のビデオデータユニット入れ替え可能かどうかを指示するための指示について。
１．一実施形態では、当該指示は、ｄａｔａ＿ｕｎｉｔｓ＿ｒｅｐｌａｃａｂｌｅと称される１ビットのフラグでシグナリング通知され、値１及び０は、それぞれ、このビデオデータユニットの入れ替えを可能にすること及び可能しないことを指示する。
ｉｉｉ．主ビデオの各ピクチャにおける符号化・復号化されたビデオデータユニットのどれが目標ピクチャインピクチャ領域を示すかを指示するための領域ＩＤリストについて。
１．一実施形態では、特定のビデオデコーダについて、領域ＩＤの特定のセマンティクスを明示的に規定する必要があると規定される。
ａ．一実施形態では、以下のように規定される：ＶＶＣの場合、領域ＩＤがサブピクチャＩＤであり、符号化・復号化されたビデオデータユニットがＶＣＬ ＮＡＬユニットである。主ビデオにおける目標ピクチャインピクチャ領域を示すＶＣＬ ＮＡＬユニットは、これらのサブピクチャＩＤを持つＶＣＬ ＮＡＬユニットであり、これらのサブピクチャＩＤは、補足ビデオの対応するＶＣＬ ＮＡＬユニットにおけるサブピクチャＩＤと同じである（一般的に、補足ビデオにおける１つ画面の全てのＶＣＬ ＮＡＬユニットは、明確に信号通知される同一のサブピクチャＩＤを共用し、この場合、領域ＩＤのリストには、領域ＩＤが１つしか存在しない）。
ｂ．一実施形態では、以下のように規定される：ＶＶＣの場合、ビデオデコーダに送信される前に、クライアント端末では、補足ビデオの対応するＶＣＬ ＮＡＬユニットを使用して、主ビデオにおける目標ピクチャインピクチャ領域を示す符号化・復号化されたビデオデータユニット（即ち、ＶＣＬ ＮＡＬユニット）を入れ替えるするように選択すると、対応するＶＣＬ ＮＡＬユニットの順序を変更することなく、各サブピクチャＩＤについて、主ビデオにおけるＶＣＬ ＮＡＬユニットを補足ビデオ中具有該サブピクチャＩＤの対応するＶＣＬ ＮＡＬユニットに入れ替える。
ｉｖ．補足ビデオを埋込／重畳するための主ビデオにおける位置及びサイズは、サイズの点で主ビデオよりも小さい。
１．一実施形態では、４つの値（ｘ、ｙ、幅、高さ）でシグナリング通知され、ｘ、ｙは、領域の左上隅の位置を指定し、幅及び高さは、領域の幅及び高さを指定する。単位は、輝度サンプル／ピクセルであってもよい。
２．一実施形態では、ｄａｔａ＿ｕｎｉｔｓ＿ｒｅｐｌａｃａｂｌｅが１に等しく、位置及びサイズの情報が存在する場合、該位置及びサイズは、主ビデオにおける目標ピクチャインピクチャ領域を正しく示すべきであると規定される。
３．一実施形態では、ｄａｔａ＿ｕｎｉｔｓ＿ｒｅｐｌａｃａｂｌｅが０に等しく、位置及びサイズの情報が存する場合、位置及びサイズの情報は、補足ビデオを埋め込んでカバーするための好適な領域（即ち、クライアント端末では、補足ビデオを主ビデオの異なる領域に重畳することを選択可能である）を指示すると規定される。
４．一実施形態では、ｄａｔａ＿ｕｎｉｔｓ＿ｒｅｐｌａｃａｂｌｅが０に等しく、位置及びサイズの情報が存在しない場合、どこで補足ビデオをカバーするかに関する情報又は推奨はなく、クライアントの選択に完全に依存すると規定される。
５．実施形態
以下は、第５項及び上記のセクション４において概括的に説明した幾つかのサブ項目の幾つかの例示的な実施形態の実施形態である。
これらの実施形態は、ＩＳＯＢＭＦＦに適用可能である。
５．１ ピクチャインピクチャエンティティグループ化について
５．１．１ 定義について
ピクチャインピクチャサービスは、空間分解能の低い方のビデオを空間分解能の高い方のビデオに含める機能を提供し、それぞれは、補足ビデオ及び主ビデオと呼ばれる。主ビデオを含むように指示されるトラックから１つのトラックを選択し、他のトラックから１つのトラック（補足ビデオを含む）を選択することで、ｇｒｏｕｐｉｎｇ＿ｔｙｐｅが「ｐｉｎｐ」に等しいの同一のエンティティグループ内のトラックは、ピクチャインピクチャサービスに対応するために用いられる。
ピクチャインピクチャエンティティグループ内の全てのエンティティは何れもビデオトラックであるべきである。
５．１．２ シンタックスについて
ａｌｉｇｎｅｄ（８）ｃｌａｓＳＰｉｃＩｎＰｉｃＥｎｔｉｔｙＧｒｏｕｐＢｏｘｅｘｔｅｎｄＳＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘ（「ｐｉｎｐ」，０，０）｛
ｕｎｓｉｇｎｅＤｉｎｔ（８）ｎｕｍ＿ｍａｉｎ＿ｖｉｄｅｏ＿ｔｒａｃｋｓ；
ｕｎｓｉｇｎｅＤｉｎｔ（１）ｄａｔａ＿ｕｎｉｔｓ＿ｒｅｐｌａｃａｂｌｅ；
ｕｎｓｉｇｎｅＤｉｎｔ（１）ｐｉｎｐ＿ｗｉｎｄｏｗ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ；
ｂｉｔ（６）ｒｅｓｅｒｖｅＤ＝０；
ｉｆ（ｄａｔａ＿ｕｎｉｔｓ＿ｒｅｐｌａｃａｂｌｅ）｛
ｕｎｓｉｇｎｅＤｉｎｔ（８）ｎｕｍ＿ｒｅｇｉｏｎ＿ｉｄｓ；
ｆｏｒ（ｉ＝０；ｉ＜ｎｕｍ＿ｒｅｇｉｏｎ＿ｉｄｓ；ｉ＋＋）
ｕｎｓｉｇｎｅＤｉｎｔ（１６）ｒｅｇｉｏｎ＿ｉｄ［ｉ］；
｝
ｉｆ（ｐｉｎｐ＿ｗｉｎｄｏｗ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ）｛
ｕｎｓｉｇｎｅＤｉｎｔ（１６）ｘ；
ｕｎｓｉｇｎｅＤｉｎｔ（１６）ｙ；
ｕｎｓｉｇｎｅＤｉｎｔ（１６）ｗｉｄｔｈ；
ｕｎｓｉｇｎｅＤｉｎｔ（１６）ｈｅｉｇｈｔ；
｝
｝
５．１．３ セマンティクスについて
ｎｕｍ＿ｍａｉｎ＿ｖｉｄｅｏ＿ｔｒａｃｋｓは、そのエンティティグループ内のピクチャインピクチャ主ビデオを担持するトラック数を指定する。
ｄａｔａ＿ｕｎｉｔｓ＿ｒｅｐｌａｃａｂｌｅは、主ビデオ内の、目標ピクチャインピクチャ領域を示す符号化・復号化されたビデオデータユニットが、補足ビデオの対応するビデオデータユニットで入れ替え可能かどうかを指示する。値１は、このようなビデオデータユニットの入れ替えを可能にすることを指示し、値０は、このようなビデオデータユニットの入れ替えを可能にしないことを指示する。
ｄａｔａ＿ｕｎｉｔｓ＿ｒｅｐｌａｃａｂｌｅが１に等しい場合、デコードのためにビデオデコーダに送信される前に、プレーヤは、補足ビデオに対応する符号化・復号化されたビデオデータユニットで主ビデオにおける目標ピクチャインピクチャ領域を示す符号化・復号化されたビデオデータユニットを入れ替えることを選択可能である。この場合、主ビデオにおける特定のピクチャについて、補足ビデオの対応するビデオデータユニットは、補足ビデオトラックにおける復号化時間同期サンプル内の符号化・復号化されたビデオデータユニットの全てである。ＶＶＣの場合、ビデオデコーダに送信される前に、クライアント端末では、主ビデオにおける目標ピクチャインピクチャ領域を示す符号化・復号化されたビデオデータユニット（即ち、ＶＣＬ ＮＡＬユニット）を補足ビデオにおける対応ＶＣＬ ＮＡＬユニットに入れ替えることを選択すると、各サブピクチャＩＤについて、対応ＶＣＬ ＮＡＬユニットの順序を変更することなく、主ビデオにおけるＶＣＬ ＮＡＬユニットが補足ビデオのける該サブピクチャＩＤを持つ対応ＶＣＬ ＮＡＬユニットに入れ替えられる。
ｐｉｎｐ＿ｗｉｎｄｏｗ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔが１に等しいことは、フィールドｘ、ｙ、幅及び高さが存在すると指定する。値０は、これらのフィールドが存在しないと指定する。
ｎｕｍ＿ｒｅｇｉｏｎ＿ｉｄｓは、後続のフィールドＲｅｇｉｏｎ＿ｉｄ［ｉ］の数を指定する。
ｒｅｇｉｏｎ＿ｉｄ［ｉ］は、目標ピクチャインピクチャ領域を示す符号化・復号化されたビデオデータユニットのｉ番目のＩＤを指定する。
特定のビデオデコーダについて、領域ＩＤの特定のセマンティクスを明示的に規定する必要がある。ＶＶＣの場合、領域ＩＤがサブピクチャＩＤであり、符号化・復号化されたビデオデータユニットがＶＣＬ ＮＡＬユニットである。主ビデオにおける目標ピクチャインピクチャ領域を示すＶＣＬ ＮＡＬユニットは、これらのサブピクチャＩＤを持つＶＣＬ ＮＡＬユニットであり、これらのサブピクチャＩＤは、補足ビデオの対応するＶＣＬ ＮＡＬユニット内のサブピクチャＩＤと同じである。
ｘは、主ビデオにおける目標ピクチャインピクチャ領域の左上隅に位置する符号化ビデオ画素（サンプル）の水平位置を指定する。単位は、ビデオ画素（サンプル）である。
ｙは、主ビデオにおける目標ピクチャインピクチャ領域の左上隅に位置する符号化ビデオ画素（サンプル）の垂直位置を指定する。単位は、ビデオ画素（サンプル）である。
幅は、主ビデオにおける目標ピクチャインピクチャ領域の幅を指定する。単位は、ビデオ画素（サンプル）である。
高さは、主ビデオにおける目標ピクチャインピクチャ領域の高さを指定する。単位は、ビデオ画素（サンプル）である。
【0058】
本開示の実施形態は、１種類のピクチャインピクチャに対応するためのファイルフォーマット設計に関する。本明細書で使用されるように、「ピクチャインピクチャ（ｐｉｃｔｕｒｅ－ｉｎ－ｐｉｃｔｕｒｅ、ＰｉＰ）サービス」は、空間分解能の低い方のビデオ（「補足ビデオ」又は「ＰｉＰビデオ」とも称される）を空間分解能の高い方のビデオに含める機能（「主ビデオ」とも称される）を提供している。
【0059】
図８は、本開示の幾つかの実施形態に係るビデオを処理するための方法８００のフロー図を示している。方法８００は、クライアント端末又はサーバにおいて実現可能である。本明細書において使用される「クライアント端末」という用語は、コンピュータネットワークとしてのクライアント端末－サーバモデルのサーバによって提供されるサービスにアクセスするコンピュータハードウェア又はソフトウェアの一部を指す場合がある。例えば、クライアント端末は、スマートフォン又はタブレットであってもよい。本明細書において使用される「サーバ」という用語は、演算機能を持つ装置を指す場合がある。この場合、クライアント端末は、ネットワークを介してサーバにアクセスする。サーバは、物理的なコンピュータ装置又は仮想的なコンピュータ装置であってもよい。
【0060】
図８に示すように、方法８００は、ブロック８０２から開始し、ブロック８０２において、第１ビデオのメディアファイルと第１ビデオのビットストリームとの間の変換を実行する。当該メディアファイルは、第１ビデオにおける目標ピクチャインピクチャ領域を示す第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含み、第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である。例えば、第１指示は、第１ビデオにおける領域を識別する領域識別（ＩＤ）のリストを含む。上記の例は、説明を目的とするものに過ぎないと理解されたい。本開示の範囲は、これらに限定されるものではない。
【0061】
提出された方法によれば、指示を採用して、第１ビデオにおける目標ピクチャインピクチャ領域を示す第１グループの符号化・復号化されたビデオデータユニットを指示する。当該第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である。これにより、提出された方法は、ＩＳＯＢＭＦＦに基づくメディアファイル内のピクチャインピクチャサービスに対応することを容易に可能にする。
【0062】
幾つかの実施形態では、第２ビデオの空間分解能が、第１ビデオの空間分解能よりも低い。つまり、第２ビデオが補足ビデオであり、第１ビデオが主ビデオである。
【0063】
幾つかの実施形態では、第１指示は、第１ビデオにおける領域を識別する領域識別（ＩＤ）のリストを含む。幾つかの実施形態では、領域ＩＤのリストにおける１つの領域ＩＤについて、第２グループの符号化・復号化されたビデオデータユニットのうち、前記領域ＩＤを持つ第２の符号化・復号化されたビデオデータユニットで、第１グループの符号化・復号化されたビデオデータユニットのうち、領域ＩＤを持つ第１の符号化・復号化されたビデオデータユニットを入れ替える。例えば、図９はピクチャインピクチャを提供する模式図を示している。図9に示すように、第１ビデオは、サブピクチャ（ｓｕｂｐｉｃ）ＩＤ００、０１、０２及び０３を有するサブ画面をふくんでもよい。例えば、領域ＩＤのリストにはサブピクチャＩＤ００を含む場合、第２ビデオ９２０におけるサブピクチャＩＤ００を有する符号化・復号化されたされたビデオデータユニットで、第１ビデオ９１０におけるサブピクチャＩＤ００を有する符号化・復号化されたビデオデータユニットを入れ替え可能である。
【0064】
このようにして、補足ビデオのビットストリームを主ビデオのビットストリームにマージすることができる。補足ビデオのビットストリーム及び主ビデオのビットストリームの両方ではなく、マージされたビットストリームのみを伝送又は復号化すればよい。これにより、伝送効率及び／又は復号化効率を有利に向上させることができる。
【0065】
幾つかの実施形態では、第１ビデオは、汎用ビデオ符号化方式（ＶＶＣ）で符号化・復号化されたものであり、領域識別のリストにおける領域ＩＤは、第１ビデオにおけるサブピクチャを識別するサブピクチャＩＤである。幾つかの実施形態では、第１グループの符号化・復号化されたビデオデータユニットは、ビデオデーデック層ネットワーク抽象化層（ＶＣＬ ＮＡＬ）ユニットを含み、第２グループの符号化・復号化されたビデオデータユニットは、ＶＣＬ ＮＡＬユニットを含む。
【0066】
幾つかの実施形態では、第１指示は、前記メディアファイルのデータ構成に含まれてもよい。例えば、データ構成は、「ｐｉｎｐ」エンティティグループであってもよい。つまり、当該データ構成は、新しいタイプのエンティティグループであり、その名称はピクチャインピクチャエンティティグループであり、その属性ｇｒｏｕｐｉｎｇ＿ｔｙｐｅが「ｐｉｎｐ」に等しい。幾つかの実施形態では、「ｐｉｎｐ」エンティティグループにおけるエンティティは、第１ビデオのビットストリームを担持するトラックである。上記の例は、説明を目的とするものに過ぎないと理解されたい。本開示の範囲は、これらに限定されるものではない。
【0067】
幾つかの実施形態では、データ構成は、第１ビデオのビットストリームを担持する１グループのトラックを指示するための第２指示を更に含んでもよい。一実施例では、第２指示は、当該１グループのトラックにおけるトラック数に等しい値を含んでもよい。例えば、第１ビデオのビットストリームを担持するトラックの数がＮである場合、指示は、データ構成における最初のＮ個のエンティティＩＤで識別されたトラックが第１ビデオのビットストリームを担持するトラックであり、残りのエンティティＩＤで識別されたトラックが第２ビデオのビットストリームを担持するトラックであることを指示する値Ｎであってもよい。或いは、第２指示は、１グループのトラックにおけるトラックの識別（ＩＤ）を指示するインデックスリストを含んでもよい。別の実施例では、第２指示は、１グループのトラックにおけるトラックのトラックＩＤのリストを含んでもよい。上記の例は、説明を目的とするものに過ぎないと理解されたい。本開示の範囲は、これらに限定されるものではない。
【0068】
幾つかの実施形態では、目標ピクチャインピクチャ領域のサイズは、前記第１ビデオのサイズよりも小さいものであってもよい。データ構成には、目標ピクチャインピクチャ領域の位置情報及びサイズ情報が更に含まれてもよい。一実施例では、位置情報は、目標ピクチャインピクチャ領域の左上隅の水平位置及び鉛直位置を指示してもよい。代替的又は追加的に、サイズ情報は、目標ピクチャインピクチャ領域の幅及び高さを指示してもよい。例えば、図１０は、目標ピクチャインピクチャ領域１００１の位置情報及びサイズ情報を示している。図１０に示すように、位置情報は、第１ビデオ１０１０における目標ピクチャインピクチャ領域１００１の水平位置Ｘ及び鉛直位置Ｙを指示してもよい。サイズ情報は、目標ピクチャインピクチャ領域１００１の幅１００２及び高さ１００３を含んでもよい。
【0069】
幾つかの実施形態では、メディアファイルは、第１グループの符号化・復号化されたビデオデータユニットが、第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能ではない旨を指示するための第３指示を含む場合、第２ビデオに対して第１ビデオにおける第１領域を決定することができる。第２ビデオは、第１領域における第１ビデオに重畳することができる。
【0070】
幾つかの実施形態では、メディアファイルは、目標ピクチャインピクチャ領域の位置情報とサイズ情報を更に含んでもよい。第１領域は、目標ピクチャインピクチャ領域に基づいて決定するものである。幾つかの実施形態では、位置情報は、目標ピクチャインピクチャ領域の左上隅の水平位置及び鉛直位置を指示してもよい。サイズ情報は、目標ピクチャインピクチャ領域の幅及び高さを指示してもよい。
【0071】
幾つかの実施形態では、変換は、メディアファイルを作成しビットストリームをメディアファイルに記憶することを含む。代替的又は追加的に、幾つかの実施形態では、変換は、メディアファイルを解析してビットストリームを再構成することを含む。
【0072】
幾つかの実施形態では、第１ビデオのビットストリームは、非一時的なコンピュータ読み取り可能記録媒体に記憶可能である。第１ビデオのビットストリームは、ビデオ処理装置において実行される方法で生成可能である。当該方法によれば、第１ビデオのメディアファイルと第１ビデオのビットストリームとの間の変換を実行する。当該メディアファイルは、第１ビデオにおける目標ピクチャインピクチャ領域を示す、第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含む。第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である。
【0073】
幾つかの実施形態では、第１ビデオのメディアファイルとビットストリームとの間の変換が実行される。当該メディアファイルは、第１ビデオにおける目標ピクチャインピクチャ領域を示す、第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含む。第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である。
【0074】
幾つかの実施形態では、第１ビデオのメディアファイルは、非一時的なコンピュータ読み取り可能記録媒体に記憶可能である。第１ビデオのメディアファイルは、ビデオ処理装置において実行される方法で生成可能である。当該方法によれば、第１ビデオのメディアファイルと第１ビデオのビットストリームとの間の変換を実行する。当該メディアファイルは、第１ビデオにおける目標ピクチャインピクチャ領域を示す、第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含む。第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である。
【0075】
幾つかの実施形態では、第１ビデオのメディアファイルとビットストリームとの間の変換が実行される。当該メディアファイルは、第１ビデオにおける目標ピクチャインピクチャ領域を示す、第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含む。第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である。
【0076】
本開示の実施形態は、以下の条項に基づいて説明可能であり、これらの条項に係る特徴は、任意の合理的な形態で組み合わせることができる。
【0077】
条項１．第１ビデオのメディアファイルと第１ビデオのビットストリームとの間の変換を実行するステップを含み、メディアファイルは、第１ビデオにおける目標ピクチャインピクチャ領域を示す第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含み、第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である、方法。
【0078】
条項２．第２ビデオの空間分解能が、第１ビデオの空間分解能よりも低い、条項１に記載の方法。
【0079】
条項３．第１指示は、第１ビデオにおける領域を識別する領域識別（ＩＤ）のリストを含む、条項１～２の何れか１つに記載の方法。
【0080】
条項４．領域ＩＤのリストにおける１つの領域ＩＤについて、第２グループの符号化・復号化されたビデオデータユニットのうち、領域ＩＤを持つ第２の符号化・復号化されたビデオデータユニットで、第１グループの符号化・復号化されたビデオデータユニットのうち、記領域ＩＤを持つ第１の符号化・復号化されたビデオデータユニットを入れ替えるステップを更に含む、条項３に記載の方法。
【0081】
条項５．第１ビデオは、汎用ビデオ符号化方式（ＶＶＣ）で符号化・復号化されたものであり、領域識別のリストにおける領域ＩＤは、第１ビデオにおけるサブピクチャを識別するサブピクチャＩＤである、条項３～４の何れか１つに記載の方法。
【0082】
条項６．第１グループの符号化・復号化されたビデオデータユニットは、ビデオコーデック層ネットワーク抽象化層（ＶＣＬ ＮＡＬ）ユニットを含み、第２グループの符号化・復号化されたビデオデータユニットは、ＶＣＬ ＮＡＬユニットを含む、条項１～５の何れか１つに記載の方法。
【0083】
条項７．第１指示は、メディアファイルのデータ構成に含まれる、条項１～６の何れか１つに記載の方法。
【0084】
条項８．データ構成は、「ｐｉｎｐ」エンティティグループである、条項７に記載の方法。
【0085】
条項９．「ｐｉｎｐ」エンティティグループにおけるエンティティは、第１ビデオのビットストリームを担持するトラックである、条項８に記載の方法。
【0086】
条項１０．データ構成は、第１ビデオのビットストリームを担持する１グループのトラックを指示するための第２指示を更に含む、条項７～９の何れか１つに記載の方法。
【0087】
条項１１．第２指示は、１グループのトラックにおけるトラック数に等しい値と、１グループのトラックにおけるトラックの識別（ＩＤ）を指示するインデックスリストと、１グループのトラックにおけるトラックのトラックＩＤのリストとの、うちの１つを含む、条項１０に記載の方法。
【0088】
条項１２．目標ピクチャインピクチャ領域のサイズは、第１ビデオのサイズよりも小さく、かつ、データ構成には、目標ピクチャインピクチャ領域の位置情報及びサイズ情報が更に含まれる、条項７～１１のいずれか１つに記載の方法。
【0089】
条項１３．位置情報は、目標ピクチャインピクチャ領域の左上隅の水平位置及び鉛直位置を指示し、サイズ情報は、目標ピクチャインピクチャ領域の幅及び高さを指示する、条項１２に記載の方法。
【0090】
条項１４．メディアファイルは、第１グループの符号化・復号化されたビデオデータユニットが、第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能ではない旨を指示するための第３指示を含む場合、第２ビデオに対して第１ビデオにおける第１領域を決定するステップと、第１領域において、第２ビデオを第１ビデオに重畳するステップと、を更に含む、条項１～２のいずれか１つに記載の方法。
【0091】
条項１５．メディアファイルは、目標ピクチャインピクチャ領域の位置情報とサイズ情報を更に含み、第１領域を決定することは、目標ピクチャインピクチャ領域に基づいて第１領域を決定するステップを含む、条項１４に記載の方法。
【0092】
条項１６．位置情報は、目標ピクチャインピクチャ領域の左上隅の水平位置及び鉛直位置を指示し、サイズ情報は、目標ピクチャインピクチャ領域の幅及び高さを指示する、条項１５に記載の方法。
【0093】
条項１７．変換は、メディアファイルを作成してビットストリームをメディアファイルに記憶することを含む、条項１～１６のいずれか１つに記載の方法。
【0094】
条項１８．変換は、メディアファイルを解析してビットストリームを再構成することを含む、条項１～１６のいずれか１つに記載の方法。
【0095】
条項１９．ビデオデータを処理するための装置であって、プロセッサと、指令を記憶した非一時的なメモリとを備え、指令がプロセッサによって実行されると、条項１～１８のいずれか１つに記載の方法をプロセッサに実行させる、装置。
【0096】
条項２０．条項１～１８のいずれか１つに記載の方法をプロセッサに実行させる指令を記憶するための非一時的なコンピュータ読み取り可能記憶媒体。
【0097】
条項２１．ビデオ処理装置において実行される方法で生成された第１ビデオのビットストリームを記憶し、方法は、第１ビデオのメディアファイルと第１ビデオのビットストリームとの間の変換を実行するステップを含み、メディアファイルは、第１ビデオにおける目標ピクチャインピクチャ領域を示す、第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含み、第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である、非一時的なコンピュータ読み取り可能記録媒体。
【0098】
条項２２．ビデオのビットストリームを記憶する方法であって、
第１ビデオのメディアファイルと第１ビデオのビットストリームとの間の変換を実行するステップ、ビットストリームを非一時的なコンピュータ読み取り可能記録媒体に記憶するステップ、を含み、メディアファイルは、第１ビデオにおける目標ピクチャインピクチャ領域を示す、第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含み、第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である、方法。
第１ビデオのメディアファイルと第１ビデオのビットストリームとの間の変換を実行するステップ、ビットストリームを非一時的なコンピュータ読み取り可能記録媒体に記憶するステップ、を含み、メディアファイルは、第１ビデオにおける目標ピクチャインピクチャ領域を示す、第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含み、第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である、方法。
【0099】
条項２３．ビデオ処理装置において実行される方法で生成された第１ビデオのメディアファイルを記憶し、方法は、メディアファイルと第１ビデオのビットストリームとの間の変換を実行するステップを含み、メディアファイルは、第１ビデオにおける目標ピクチャインピクチャ領域を示す第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含み、第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である、非一時的なコンピュータ読み取り可能記録媒体。
【0100】
条項２４．第１ビデオのメディアファイルを記憶するための方法であって、メディアファイルと第１ビデオのビットストリームとの間の変換を実行するステップ、及びメディアファイルを非一時的なコンピュータ読み取り可能記録媒体に記憶するステップを含み、メディアファイルは、第１ビデオにおける目標ピクチャインピクチャ領域を示す第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含み、第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である、方法。
【0101】
装置例
図１１は、本開示の各実施形態を実現可能なコンピュータ装置１１００のブロック図を示している。コンピュータ装置１１００は、ソース装置１１０（又はビデオエンコーダ１１４又は２００）又はターゲット装置１２０（又はビデオデコーダ１２４又は３００）として構成されてもよい、或いは、在ソース装置１１０（又はビデオエンコーダ１１４又は２００）又はターゲット装置１２０（又はビデオデコーダ１２４又は３００）に含まれてもよい。
図１１は、本開示の各実施形態を実現可能なコンピュータ装置１１００のブロック図を示している。コンピュータ装置１１００は、ソース装置１１０（又はビデオエンコーダ１１４又は２００）又はターゲット装置１２０（又はビデオデコーダ１２４又は３００）として構成されてもよい、或いは、在ソース装置１１０（又はビデオエンコーダ１１４又は２００）又はターゲット装置１２０（又はビデオデコーダ１２４又は３００）に含まれてもよい。
【0102】
図１１に示されたコンピュータ装置１１００は、説明を目的とするに過ぎず、本開示の実施形態の機能及び範囲についてのいかなる限定も示唆するものではないと理解されたい。
【0103】
図１１に示すように、コンピュータ装置１１００は、汎用コンピュータ装置１１００を含む。コンピュータ装置１１００は、少なくとも１つ又は複数のプロセッサ又は処理ユニット１１１０と、メモリ１１２０と、記憶装置１１３０と、１つ又は複数の通信ユニット１１４０と、１つ又は複数の入力装置１１５０と、１つ又は複数の出力装置１１６０を含んでもよい。
【0104】
幾つかの実施形態では、コンピュータ装置１１００は、演算機能を有する任意のユーザ端末又はサーバ端末として構成されてもよい。サーバ端末は、サービス事業者によって提供されるサーバ、大型コンピュータ装置などであってもよい。ユーザ端末は、例えば、携帯電話、ステーション、ユニット、デバイス、マルチメディアコンピュータ、マルチメディアタブレットコンピュータ、インターネットノード、コミュニケータ、デスクトップコンピュータ、ラップトップコンピュータ、ノートコンピュータ、ネットブックコンピュータ、パーソナル通信システム（ＰＣＳ）デバイス、パーソナルナビゲーションデバイス、パーソナルデジタルアシスタント（ＰＤＡ）、オーディオ／ビデオプレーヤ、デジタルカメラ／ビデオカメラ、ロケーターデバイス、テレビ受信機、ラジオ放送受信機、電子ペーパーデバイス、ゲームデバイス、又はこれらの任意の組み合わせ、並びにこれらのデバイスのアタッチメントや周辺機器又はその任意の組み合わせを含む、任意のタイプの移動端末、固定端末又は便携式端末であってもよい。コンピュータ装置１１００は、ユーザの任意のタイプのインターフェース（例えば「ウェアラブル」回路装置など）に対応可能であることが想定される。
【0105】
処理ユニット１１１０は、物理的なプロセッサ又は仮想的なプロセッサであってもよく、メモリ１１２０内に記憶するプログラムにより様々な処理を実現する。マルチプロセッサシステムでは、複数の処理ユニットがコンピュータ実行可能な指令を並列に実行して、コンピュータ装置１１００の並列処理能力を向上させる。処理ユニット１１１０は、中央処理装置（ＣＰＵ）、マイクロプロセッサ、コントローラ又はマイクロコントローラとも称される。
【0106】
コンピュータ装置１１００は、一般的に、様々なコンピュータ記憶媒体を備える。このような媒体は、例えば、揮発性媒体及び不揮発性媒体、又はリムーバブル媒体及び非リムーバブル媒体など、コンピュータ装置１１００によってアクセス可能な任意の媒体であってもよい。メモリ１１２０は、揮発性メモリ（例えば、レジスタ、キャッシュ、ランダムアクセスメモリ（ＲＡＭ））、不揮発性メモリ（例えば、読み出し専用メモリ（ＲＯＭ）、電気的に消去可能なプログラマブル読み出し専用メモリ（ＥＥＰＲＯＭ）又はフラッシュメモリ）又はこれらの任意の組み合わせであってもよい。記憶装置１１３０は、任意のリムーバブル又は不リムーバブル媒体であってもよく、例えば、メモリ、フラッシュドライバ、ディスクなどの機器読み取り可能な媒体、又は他の、情報及び／又はデータを記憶するために用いられ、且つ、コンピュータ装置１１００においてアクセス可能な媒体を含むことができる。
【0107】
コンピュータ装置１１００は、追加のリムーバブル／不リムーバブル記憶媒体、揮発性／不揮発性記憶媒体をさらに含んでもよい。図１１に示されていないが、リムーバブル不揮発性ディスクからの読み出し及び／又は書き込みのためのリムーバブル不揮発性ディスクのディスクドライバ、及びリムーバブル不揮発性ディスクからの読み出し及び／又は書き込みのためのリムーバブル不揮発性ディスクのディスクドライバを提供することができる。この場合、各ドライバは、１つ又は複数のデータ媒体インターフェースを介してバス（図示せず）に接続することができる。
【0108】
通信ユニット１１４０は通信媒体を介して与他のコンピュータ装置と通信する。また、コンピュータ装置１１００内のコンポーネントの機能は、通信接続を介して通信可能な単一のコンピューティングクラスタ又は複数のコンピューティングマシンによって実現することができる。従って、コンピュータ装置１１００は、ネットワーク化された環境で動作するために、１つ又は複数の他のサーバ、ネットワーク化パーソナルコンピュータ（ＰＣ）又は他の汎用ネットワークノードへの論理的接続を利用することができる。
【0109】
入力装置１１５０は、例えば、マウス、キーボード、トラックボール、音声入力装置などの様々な入力装置のうちの１つ又は複数であってもよい。出力装置１１６０は、例えば、ディスプレイ、スピーカ、プリンタなどの様々な出力装置のうちの１つ又は複数であってもよい。コンピュータ装置１１００は、通信ユニット１１４０を介して、１つ又は複数の外部装置（図示せず）と通信してもよく、外部装置は、例えば、記憶装置及び表示装置であり、コンピュータ装置１１００は、必要に応じて、ユーザがコンピュータ装置１１００に対して対話可能な１つ又は複数のデバイスと通信したり、コンピュータ装置１１００を１つ又は複数の他のコンピュータ装置と通信可能にさせる任意のデバイス（例えば、ネットワークカード、変復調機など）と通信したりすることができる。このような通信は、入出力（Ｉ／Ｏ）インターフェース（図示せず）を介して行われる。
【0110】
幾つかの実施形態では、コンピュータ装置１１００の幾つかの又は全てのコンポーネントは、単一のデバイスに集積されるものではなく、クラウドコンピューティングアーキテクチャに配置されるものであってもよい。クラウドコンピューティングアーキテクチャでは、コンポーネントは、遠隔で提供され、本開示に記述の機能を実現するように協働することができる。幾つかの実施形態では、クラウドコンピューティングは、コンピューティング、ソフトウェア、データアクセス及びストレージサービスを提供するが、これらのサービスを提供するシステム又はハードウェアの物理的な位置又は配置をエンドユーザが認識する必要はない。各実施形態では、クラウドコンピューティングは、適切なプロトコルを使用して、広域ネットワーク（例えば、インターネット）を介してサービスを提供する。例えば、クラウドコンピューティング事業者は、広域ネットワークを介して、ウェブブラウザ又は任意の他のコンピューティングコンポーネントを通じてアクセス可能なアプリケーションを提供する。クラウドコンピューティングアーキテクチャのソフトウェア又はコンポーネント及び対応するデータは、遠隔サーバに記憶することができる。クラウドコンピューティング環境におけるコンピューティングソースは、遠隔データセンタロケーションに集約又は分散することができる。クラウドコンピューティングインフラストラクチャは、ユーザにとっては単一のアクセスポイントとして動作するが、データセンタを介してサービスを提供することができる。従って、クラウドコンピューティングアーキテクチャは、遠隔地のサービス事業者から本明細書に記載された構成要素及び機能を提供するために用いることができる。或いは、従来のサーバによって提供されてもよく、又はクライアント端末装置にインストールされてもよい。
【0111】
本開示の実施形態では、コンピュータ装置１１００は、ビデオの符号化／復号化を実現するために用いることができる。メモリ１１２０は、１つ又は複数のプログラム指令を有する１つ又は複数のビデオコーデックモジュール１１２５を含んでもよい。これらのモジュールは、本明細書に記載された各実施形態の機能を実行するために、処理ユニット１１１０によってアクセス及び実行することができる。
【0112】
ビデオ符号化を実行する例示的な実施形態では、入力装置１１５０は、符号化される入力１１７０として、ビデオデータを受信することができる。ビデオデータは、符号化されたビットストリームを生成するように、例えばビデオコーデックモジュール１１２５によって処理することができる。符号化されたビットストリームは、出力１１８０として、出力装置１１６０を介して提供することができる。
【0113】
ビデオ復号化を実行する例示的な実施形態では、入力装置１１５０は、入力１１７０として符号化されたビットストリームを受信することができる。符号化されたビットストリームは、復号化されたビデオデータを生成するように、例えばビデオコーデックモジュール１１２５によって処理することができる。復号化されたビデオデータは、出力１１８０として、出力装置１１６０を介して提供することができる。
【0114】
本開示の好ましい実施形態を参照して本開示を詳細に示して説明していたが、当業者は、添付の特許請求の範囲によって定義される本願の精神および範囲から逸脱することなく、形態及び詳細に対して様々に変更可能であることを理解するであろう。これらの変更は、本願の範囲によってカバーされることが意図される。従って、本願の実施形態に関する上記の説明は、限定を意図するものではない。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【手続補正書】
【提出日】2024-03-27
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
ビデオ処理方法であって、第１ビデオのメディアファイルと前記第１ビデオのビットストリームとの間の変換を実行するステップを含み、
前記メディアファイルは、前記第１ビデオにおける目標ピクチャインピクチャ領域を示す第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含み、前記第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である、方法。
【請求項2】
前記第２ビデオの空間分解能が、前記第１ビデオの空間分解能よりも低い、請求項１に記載の方法。
【請求項3】
前記第１指示は、前記第１ビデオにおける領域を識別する領域識別（ＩＤ）のリストを含む、請求項１に記載の方法。
【請求項4】
前記方法は、前記領域ＩＤのリストにおける１つの領域ＩＤについて、前記第２グループの符号化・復号化されたビデオデータユニットのうち、前記領域ＩＤを持つ第２の符号化・復号化されたビデオデータユニットで、前記第１グループの符号化・復号化されたビデオデータユニットのうち、前記領域ＩＤを持つ第１の符号化・復号化されたビデオデータユニットを入れ替えるステップを更に含む、請求項３に記載の方法。
【請求項5】
前記第１ビデオは、汎用汎用ビデオ符号化方式（ＶＶＣ）で符号化・復号化されたものであり、前記領域識別のリストにおける領域ＩＤは、前記第１ビデオにおけるサブピクチャを識別するサブピクチャＩＤである、請求項３に記載の方法。
【請求項6】
前記第１グループの符号化・復号化されたビデオデータユニットは、ビデオコーデック層ネットワーク抽象化層（ＶＣＬ ＮＡＬ）ユニットを含み、前記第２グループの符号化・復号化されたビデオデータユニットは、ＶＣＬ ＮＡＬユニットを含む、請求項１に記載の方法。
【請求項7】
前記第１指示は、前記メディアファイルのデータ構成に含まれる、請求項１に記載の方法。
【請求項8】
前記データ構成は、「ｐｉｎｐ」エンティティグループである、請求項７に記載の方法。
【請求項9】
前記「ｐｉｎｐ」エンティティグループにおけるエンティティは、前記第１ビデオの前記ビットストリームを担持するトラックである、請求項８に記載の方法。
【請求項10】
前記データ構成は、前記第１ビデオの前記ビットストリームを担持する１グループのトラックを指示するための第２指示を更に含む、請求項７に記載の方法。
【請求項11】
前記第２指示は、前記１グループのトラックにおけるトラック数に等しい値と、
前記１グループのトラックにおけるトラックの識別（ＩＤ）を指示するインデックスリストと、
前記１グループのトラックにおけるトラックのトラックＩＤのリストと、のうちの１つを含む、請求項１０に記載の方法。
【請求項12】
前記目標ピクチャインピクチャ領域のサイズは、前記第１ビデオのサイズよりも小さく、かつ、前記データ構成には、前記目標ピクチャインピクチャ領域の位置情報及びサイズ情報が更に含まれる、請求項７に記載の方法。
【請求項13】
前記位置情報は、前記目標ピクチャインピクチャ領域の左上隅の水平位置及び鉛直位置を指示し、前記サイズ情報は、前記目標ピクチャインピクチャ領域の幅及び高さを指示する、請求項１２に記載の方法。
【請求項14】
前記方法は、前記メディアファイルは、前記第１グループの符号化・復号化されたビデオデータユニットが、前記第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能ではない旨を指示するための第３指示を含む場合、前記第２ビデオに対して第１ビデオにおける第１領域を決定するステップと、
第１領域において、前記第２ビデオを前記第１ビデオに重畳するステップと、を更に含む、請求項１に記載の方法。
【請求項15】
前記メディアファイルは、前記目標ピクチャインピクチャ領域の位置情報とサイズ情報を更に含み、前記第１領域を決定することは、前記目標ピクチャインピクチャ領域に基づいて前記第１領域を決定するステップを含む、請求項１４に記載の方法。
【請求項16】
前記位置情報は、前記目標ピクチャインピクチャ領域の左上隅の水平位置及び鉛直位置を指示し、前記サイズ情報は、前記目標ピクチャインピクチャ領域の幅及び高さを指示する、請求項１５に記載の方法。
【請求項17】
前記変換は、前記メディアファイルを作成して前記ビットストリームを前記メディアファイルに記憶することを含む、請求項１に記載の方法。
【請求項18】
前記変換は、前記メディアファイルを解析して前記ビットストリームを再構成することを含む、請求項１に記載の方法。
【請求項19】
ビデオデータ処理装置であって、プロセッサと、指令を有する非一時的なメモリとを備え、
前記指令は、前記プロセッサによって実行されると、前記プロセッサに請求項１～１８の何れか１項に記載の方法を実行させる、装置。
【請求項20】
請求項１～１８の何れか１項に記載の方法をプロセッサに実行させる指令を記憶する、非一時的なコンピュータ読み取り可能記憶媒体。
【請求項21】
非一時的なコンピュータ読み取り可能記録媒体であって、ビデオ処理装置において実行される方法で生成された第１ビデオのビットストリームを記憶し、
前記方法は、第１ビデオのメディアファイルと前記第１ビデオのビットストリームとの間の変換を実行するステップを含み、
前記メディアファイルは、前記第１ビデオにおける目標ピクチャインピクチャ領域を示す、第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含み、前記第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である、非一時的なコンピュータ読み取り可能記録媒体。
【請求項22】
ビデオのビットストリームを記憶する方法であって、第１ビデオのメディアファイルと前記第１ビデオのビットストリームとの間の変換を実行するステップと、
前記ビットストリームを非一時的なコンピュータ読み取り可能記録媒体に記憶するステップと、を含み、
前記メディアファイルは、前記第１ビデオにおける目標ピクチャインピクチャ領域を示す、第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含み、前記第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である、方法。
【請求項23】
非一時的なコンピュータ読み取り可能記録媒体であって、ビデオ処理装置において実行される方法で生成された第１ビデオのメディアファイルを記憶し、
前記方法は、前記メディアファイルと前記第１ビデオのビットストリームとの間の変換を実行するステップを含み、
前記メディアファイルは、前記第１ビデオにおける目標ピクチャインピクチャ領域を示す第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含み、前記第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である、非一時的なコンピュータ読み取り可能記録媒体。
【請求項24】
第１ビデオのメディアファイルを記憶するための方法であって、前記メディアファイルと前記第１ビデオのビットストリームとの間の変換を実行するステップ、及び
前記メディアファイルを非一時的なコンピュータ読み取り可能記録媒体に記憶するステップを含み、
前記メディアファイルは、前記第１ビデオにおける目標ピクチャインピクチャ領域を示す第１グループの符号化・復号化されたビデオデータユニットを指示するための第１指示を含み、前記第１グループの符号化・復号化されたビデオデータユニットは、第２ビデオに関連する第２グループの符号化・復号化されたビデオデータユニットで入れ替え可能である、方法。
【国際調査報告】