ホーム > 特許ランキング > ＢＹＴＥＤＡＮＣＥ ＩＮＣ．
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2025-01-24
(54)【発明の名称】ビデオ処理の方法、装置及び媒体
(51)【国際特許分類】
H04N 21/236 20110101AFI20250117BHJP
H04N 21/2665 20110101ALI20250117BHJP
【ＦＩ】
H04N21/236
H04N21/2665
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2024541640
(86)(22)【出願日】2023-01-11
(85)【翻訳文提出日】2024-08-02
(86)【国際出願番号】 US2023060470
(87)【国際公開番号】W WO2023137321
(87)【国際公開日】2023-07-20
(31)【優先権主張番号】63/298,461
(32)【優先日】2022-01-11
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】520477474
【氏名又は名称】バイトダンス インコーポレイテッド
【氏名又は名称原語表記】ＢＹＴＥＤＡＮＣＥ ＩＮＣ．
【住所又は居所原語表記】１２６５５ Ｗｅｓｔ Ｊｅｆｆｅｒｓｏｎ Ｂｏｕｌｅｖａｒｄ， Ｓｉｘｔｈ Ｆｌｏｏｒ， Ｓｕｉｔｅ Ｎｏ． １３７ Ｌｏｓ Ａｎｇｅｌｅｓ， Ｃａｌｉｆｏｒｎｉａ ９００６６ Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ
(74)【代理人】
【識別番号】110004381
【氏名又は名称】弁理士法人ＩＴＯＨ
(72)【発明者】
【氏名】ワン，イエ－クォイ
【テーマコード（参考）】
5C164
【Ｆターム（参考）】
5C164FA06
5C164MB13S
5C164SB11P
5C164SC04P
(57)【要約】
本開示の実施形態は、ビデオ処理のためのソリューションを提供する。ビデオ処理方法が提案される。前記方法は、ビデオのビットストリームと前記ビデオのメディアファイルとの間の転換を実行するステップを含み、ここで、前記メディアファイルは、サンプルのセットを含む外部ストリームトラックを含み、前記サンプルのセットについてのサンプルエントリのサンプルエントリタイプは、制限付きスキームに基づいてカプセル化され、前記サンプルエントリは、前記制限付きスキームに関連付けられた指示を含み、前記指示の値は、前記サンプルのセット内のサンプルが前記外部ストリームトラックの複数のコード化画像を含むことが許可されることを示す。
【特許請求の範囲】
【請求項1】
ビデオ処理方法であって、ビデオのビットストリームと前記ビデオのメディアファイルとの間の転換を実行するステップを含み、
ここで、前記メディアファイルは、サンプルのセットを含む外部ストリームトラックを含み、前記サンプルのセットについてのサンプルエントリのサンプルエントリタイプは、制限付きスキームに基づいてカプセル化され、前記サンプルエントリは、前記制限付きスキームに関連付けられた指示を含み、前記指示の値は、前記サンプルのセット内のサンプルが前記外部ストリームトラックの複数のコード化画像を含むことが許可されることを示す、方法。
【請求項2】
前記サンプルエントリタイプは、オリジナルサンプルエントリタイプである、請求項１に記載の方法。
【請求項3】
前記サンプルエントリは、前記制限付きスキームに関する情報を含む第１のデータ構造を含み、前記第１のデータ構造は、前記制限付きスキームを識別する第２のデータ構造を含み、前記指示は、前記第２のデータ構造内の第１のフィールドを含む、請求項１又は２のいずれか一項に記載の方法。
【請求項4】
前記第１のデータ構造は、制限付きスキーム情報ボックスであり、前記第２のデータ構造は、スキームタイプボックスであり、前記第１のフィールドは、スキームタイプフィールドである、請求項３に記載の方法。
【請求項5】
前記第１のフィールドの値は所定のコードに等しい、請求項３又は４のいずれか一項に記載の方法。
【請求項6】
前記制限付きスキームの統一資源識別子（ＵＲＩ）は、前記メディアファイルに存在しない、請求項１から５のいずれか一項に記載の方法。
【請求項7】
前記サンプルエントリは、前記制限付きスキームに関する情報を含む第１のデータ構造を含み、前記第１のデータ構造は、前記制限付きスキームを識別する第２のデータ構造を含み、前記第２のデータ構造内のフラグフィールドの最下位ビットの値は０に等しい、請求項１から６のいずれか一項に記載の方法。
【請求項8】
前記第１のデータ構造は、制限付きスキーム情報ボックスであり、前記第２のデータ構造は、スキームタイプボックスである、請求項７に記載の方法。
【請求項9】
前記サンプルエントリタイプは、所定のサンプルエントリコードでカプセル化される、請求項１から８のいずれか一項に記載の方法。
【請求項10】
前記サンプルエントリは、前記制限付きスキームに関する情報を含む第１のデータ構造を含み、前記第１のデータ構造は、前記サンプルエントリタイプを記憶する第３のデータ構造を含む、請求項１から９のいずれか一項に記載の方法。
【請求項11】
前記第１のデータ構造は、制限付きスキーム情報ボックスであり、前記第３のデータ構造は、オリジナルフォーマットボックスである、請求項１０に記載の方法。
【請求項12】
前記メディアファイルは、前記外部ストリームトラックに関連付けられた情報を含む第４のデータ構造を含む、請求項１から１１のいずれか一項に記載の方法。
【請求項13】
前記第４のデータ構造は、前記外部ストリームトラックに関連付けられたメインストリームトラックのトラックアイデンティティ（ＩＤ）を示すフィールド、
前記外部ストリームトラックにおけるサンプル内のコード化画像の最大許容数を示すフィールド、
前記外部ストリームトラックにおける各サンプル内の最初のコード化画像がイントラランダムアクセスポイント（ＩＲＡＰ）画像であるか否かを示すフィールドであって、前記最初のコード化画像がそれぞれのサンプル内の最初の位置にある、フィールド、
前記外部ストリームトラックにおける各サンプルがそれぞれのサンプル内のコード化画像のデコーディングに必要な全てのパラメータセットを含むか否かを示すフィールド、又は、
前記外部ストリームトラックにおける各サンプルついて、デコーディングプロセスが前記ＥＤＲＡＰ画像から開始されるときに、前記外部ストリームトラックに関連付けられたメインストリームトラックにおける対応する拡張従属ランダムアクセスポイント（ＥＤＲＡＰ）画像の先頭画像がデコード可能か否かを示すフィールド、
のうちの少なくとも１つを含む、請求項１２に記載の方法。
【請求項14】
前記第４のデータ構造は、外部ストリーム情報ボックスである、請求項１から１３のいずれか一項に記載の方法。
【請求項15】
前記メディアファイルは、国際標準化機構（ＩＳＯ）ベースのメディアファイルフォーマットである、請求項１から１４のいずれか一項に記載の方法。
【請求項16】
前記転換は、前記メディアファイルを生成し、前記ビットストリームを前記メディアファイルに記憶することを含む、請求項１から１５のいずれか一項に記載の方法。
【請求項17】
前記転換は、前記メディアファイルを解析して前記ビットストリームを再構築することを含む、請求項１から１５のいずれか一項に記載の方法。
【請求項18】
プロセッサと命令が記録された非一時的メモリとを含む、ビデオデータを処理する装置であって、前記命令は前記プロセッサによって実行されると、前記プロセッサに請求項１から１７のいずれか一項に記載の方法を実行させる、装置。
【請求項19】
プロセッサに請求項１から１７のいずれか一項に記載の方法を実行させる命令を記憶する非一時的なコンピュータ読み取り可能な記憶媒体。
【請求項20】
ビデオ処理装置によって実行される方法によって生成されたビデオのビットストリームを格納する非一時的なコンピュータ読み取り可能な記録媒体であって、前記方法は、前記ビットストリームと前記ビデオのメディアファイルとの間の転換を実行するステップを含み、
ここで、前記メディアファイルは、サンプルのセットを含む外部ストリームトラックを含み、前記サンプルのセットについてのサンプルエントリのサンプルエントリタイプは、制限付きスキームに基づいてカプセル化され、前記サンプルエントリは、前記制限付きスキームに関連付けられた指示を含み、前記指示の値は、前記サンプルのセット内のサンプルが前記外部ストリームトラックの複数のコード化画像を含むことが許可されることを示す、方法。
【請求項21】
ビデオのビットストリームを記憶する方法であって、前記ビットストリームと前記ビデオのメディアファイルとの間の転換を実行するステップと、
前記ビットストリームを非一時的なコンピュータ読み取り可能な記録媒体に記憶するステップと、を含み、
ここで、前記メディアファイルは、サンプルのセットを含む外部ストリームトラックを含み、前記サンプルのセットについてのサンプルエントリのサンプルエントリタイプは、制限付きスキームに基づいてカプセル化され、前記サンプルエントリは、前記制限付きスキームに関連付けられた指示を含み、前記指示の値は、前記サンプルのセット内のサンプルが前記外部ストリームトラックの複数のコード化画像を含むことが許可されることを示す、方法。
【請求項22】
ビデオ処理装置によって実行される方法によって生成されたビデオのメディアファイルを記憶する非一時的な非一時的なコンピュータ読み取り可能な記録媒体であって、前記方法は、前記ビデオのビットストリームと前記メディアファイルとの間の転換を実行するステップを含み、
ここで、前記メディアファイルは、サンプルのセットを含む外部ストリームトラックを含み、前記サンプルのセットについてのサンプルエントリのサンプルエントリタイプは、制限付きスキームに基づいてカプセル化され、前記サンプルエントリは、前記制限付きスキームに関連付けられた指示を含み、前記指示の値は、前記サンプルのセット内のサンプルが前記外部ストリームトラックの複数のコード化画像を含むことが許可されることを示す、非一時的なコンピュータ読み取り可能な記録媒体。
【請求項23】
ビデオのメディアファイルを記憶する方法であって、前記ビデオのビットストリームと前記メディアファイルとの間の転換を実行するステップと、
前記メディアファイルを非一時的なコンピュータ読み取り可能な記録媒体に記憶するステップと、を含み、
ここで、前記メディアファイルは、サンプルのセットを含む外部ストリームトラックを含み、前記サンプルのセットについてのサンプルエントリのサンプルエントリタイプは、制限付きスキームに基づいてカプセル化され、前記サンプルエントリは、前記制限付きスキームに関連付けられた指示を含み、前記指示の値は、前記サンプルのセット内のサンプルが前記外部ストリームトラックの複数のコード化画像を含むことが許可されることを示す、方法。
【発明の詳細な説明】
【技術分野】
【0001】
本出願は、２０２２年１月１１日に出願された米国仮出願第63/298,461号の優先権の利益を主張し、その全内容は、参照により本明細書に明示的に組み込まれる。
【0002】
本開示の実施形態は、一般的にはビデオ処理技術に関し、より具体的には、メディアファイル内の外部ストリームトラックのシグナリングに関する。
【背景技術】
【0003】
メディアストリーミングアプリケーションは、通常、インターネットプロトコル（ＩＰ）、伝送制御プロトコル（ＴＣＰ）、及びハイパーテキスト転送プロトコル（ＨＴＴＰ）トランスポートメソッドに基づいており、通常はＩＳＯベースメディアファイルルフォーマット（ＩＳＯＢＭＦＦ）などのファイルフォーマットに依存している。このようなストリーミングシステムの１つが、ＨＴＴＰ経由の動的アダプティブストリーミング（ＤＡＳＨ）である。ＤＡＳＨでは、マルチメディアコンテンツのビデオ及び／又はオーディオデータに対して複数の表現が存在し得、異なる表現は異なるコーディング特性（例：ビデオコーディング規格の異なるプロファイル又はレベル、異なるビットレート、異なる空間解像度など)に対応し得る。さらに、拡張従属ランダムアクセスポイント（ＥＤＲＡＰ）画像ベースのビデオコーディング及びストリーミングが提案されている。したがって、外部ストリームトラックのシグナリングについて研究する価値がある。
【発明の概要】
【0004】
本開示の実施形態、ビデオ処理のためのソリューションを提供する。
【0005】
第１の態様では、ビデオ処理方法が提案される。前記方法は、ビデオのビットストリームと前記ビデオのメディアファイルとの間の転換を実行するステップを含み、ここで、前記メディアファイルは、サンプルのセットを含む外部ストリームトラックを含み、前記サンプルのセットについてのサンプルエントリのサンプルエントリタイプは、制限付きスキームに基づいてカプセル化され、前記サンプルエントリは、前記制限付きスキームに関連付けられた指示を含み、前記指示の値は、前記サンプルのセット内のサンプルが前記外部ストリームトラックの複数のコード化画像を含むことが許可されることを示す。
【0006】
本開示の第１の態様による方法によれば、新しい制限スキームが、外部ストリームトラックにおけるサンプルが複数のコード化画像を含むことが許可されることを示すために採用される。従来のソリューションと比較して、提案された方法は、ＥＤＲＡＰベースの技術をより効率的にサポートできるという利点がある。
【0007】
第２の態様では、ビデオデータを処理する装置が提案される。前記ビデオデータを処理する装置は、プロセッサと、命令が記録された非一時的メモリとを含む。前記命令は前記プロセッサによって実行されると、前記プロセッサに本開示の第１の態様による方法を実行させる。
【0008】
第３の態様では、非一時的なコンピュータ読み取り可能な記憶媒体が提案される。前記非一時的なコンピュータ読み取り可能な記憶媒体は、プロセッサに本開示の第１の態様による方法を実行させる命令を記憶する。
【0009】
第４の態様では、別の非一時的なコンピュータ読み取り可能な記録媒体が提案される。前記非一時的なコンピュータ読み取り可能な記録媒体は、ビデオ処理装置によって実行される方法によって生成されたビデオのビットストリームを記憶する。前記方法は、前記ビットストリームと前記ビデオのメディアファイルとの間の転換を実行するステップを含み、ここで、前記メディアファイルは、サンプルのセットを含む外部ストリームトラックを含み、前記サンプルのセットについてのサンプルエントリのサンプルエントリタイプは、制限付きスキームに基づいてカプセル化され、前記サンプルエントリは、前記制限付きスキームに関連付けられた指示を含み、前記指示の値は、前記サンプルのセット内のサンプルが前記外部ストリームトラックの複数のコード化画像を含むことが許可されることを示す。
【0010】
第５の態様では、ビデオのビットストリームを記憶する方法が提案される。前記方法は、前記ビットストリームと前記ビデオのメディアファイルとの間の転換を実行するステップと、前記ビットストリームを非一時的なコンピュータ読み取り可能な記録媒体に記憶するステップとを含み、ここで、前記メディアファイルは、サンプルのセットを含む外部ストリームトラックを含み、前記サンプルのセットについてのサンプルエントリのサンプルエントリタイプは、制限付きスキームに基づいてカプセル化され、前記サンプルエントリは、前記制限付きスキームに関連付けられた指示を含み、前記指示の値は、前記サンプルのセット内のサンプルが前記外部ストリームトラックの複数のコード化画像を含むことが許可されることを示す。
【0011】
第６の態様では、別の非一時的なコンピュータ読み取り可能な記録媒体が提案される。前記非一時的なコンピュータ読み取り可能な記録媒体は、ビデオ処理装置によって実行される方法によって生成されたビデオのメディアファイルを記憶する。前記方法は、前記ビデオのビットストリームと前記メディアファイルとの間の転換を実行するステップを含み、ここで、前記メディアファイルは、サンプルのセットを含む外部ストリームトラックを含み、前記サンプルのセットについてのサンプルエントリのサンプルエントリタイプは、制限付きスキームに基づいてカプセル化され、前記サンプルエントリは、前記制限付きスキームに関連付けられた指示を含み、前記指示の値は、前記サンプルのセット内のサンプルが前記外部ストリームトラックの複数のコード化画像を含むことが許可されることを示す。
【0012】
第７の態様では、ビデオのメディアファイルを記憶する方法が提案される。前記方法は、前記ビデオのビットストリームと前記メディアファイルとの間の転換を実行するステップと、前記メディアファイルを非一時的なコンピュータ読み取り可能な記録媒体に記憶するステップとを含み、ここで、前記メディアファイルは、サンプルのセットを含む外部ストリームトラックを含み、前記サンプルのセットについてのサンプルエントリのサンプルエントリタイプは、制限付きスキームに基づいてカプセル化され、前記サンプルエントリは、前記制限付きスキームに関連付けられた指示を含み、前記指示の値は、前記サンプルのセット内のサンプルが前記外部ストリームトラックの複数のコード化画像を含むことが許可されることを示す。
【0013】
この発明の内容は、詳細な説明でさらに詳しく説明する概念の選択を簡略化した形で紹介するために提供される。この発明の内容は、請求された主題の主要な特徴又は本質的な特徴を特定することを意図したものではなく、請求された主題の範囲を制限するために使用されることも意図されていない。
【図面の簡単な説明】
【0014】
添付の図面を参照した以下の詳細な説明により、本開示の実施形態の上記及びその他の目的、特徴、及び利点がより明らかになる。本開示の例示的な実施形態において、同じ参照番号は通常、同じ構成要素を指す。
【0015】
【図1】本開示のいくつかの実施形態による例示的なビデオコーディングシステムのブロック図を示す。
【0016】
【図2】本開示のいくつかの実施形態による例示的なビデオエンコーダのブロック図を示す。
【0017】
【図3】本開示のいくつかの実施形態による例示的なビデオデコーダのブロック図を示す。
【0018】
【図4】ランダムアクセスポイント（ＲＡＰ）の概念を示すための図である。
【0019】
【図5】ＲＡＰの概念を示す別の図である。
【0020】
【図6】従属ランダムアクセスポイント（ＤＲＡＰ）概念を示す図である。
【0021】
【図7】ＤＲＡＰの概念を示す別の図である。
【0022】
【図8】拡張従属ランダムアクセスポイント（ＥＤＲＡＰ）の概念を示す図である。
【0023】
【図9】ＥＤＲＡＰの概念を示すための別の図である。
【0024】
【図10】ＥＤＲＡＰベースのビデオストリーミングを示す図である。
【0025】
【図11】ＥＤＲＡＰベースのビデオストリーミングを示すための別の図である。
【0026】
【図12】本開示のいくつかの実施形態によるビデオ処理方法のフローチャートを示す。
【0027】
【図13】本開示の様々な実施形態を具現できるコンピューティングデバイスのブロック図を示す。
【0028】
図面全体を通じて、同一又は類似の参照番号は通常、同一又は類似の要素を指す。
【発明を実施するための形態】
【0029】
次に、いくつかの実施形態を参照して、本開示の原理を説明する。これらの実施形態は、説明のみを目的として記載されており、当業者が本開示を理解し具現するのを助けるものであり、本開示の範囲に関していかなる限定も示唆するものではないことを理解すべきである。本明細書に記載の開示は、以下に記載する方法以外にも様々な方式で具現されることができる。
【0030】
以下の説明及び特許請求の範囲において、別段の定義がない限り、本明細書で使用される全ての技術用語及び科学用語は、本開示が属する技術分野の当業者によって一般に理解されるのと同じ意味を有する。
【0031】
本開示における「一つの実施形態」、「一実施形態」、「例示的な実施形態」などへの言及は、記載される実施形態が特定の特徴、構造、又は特性を含み得ることを示すが、必ずしも全ての実施形態が特定の特徴、構造、又は特性を含むとは限らない。また、そのような語句は必ずしも同じ実施形態を指しているわけではない。さらに、特定の特徴、構造、又は特性が例示的な実施形態に関連して説明される場合、明示的に記載されているか否かにかかわらず、他の実施形態に関連してそのような特徴、構造、又は特性に影響を与えることは当業者の知識の範囲内であることが指摘される。
【0032】
「第１の」及び「第２の」などの用語は、本明細書では様々な要素を説明するために使用され得るが、これらの要素はこれらの用語によって限定されるべきではないことを理解すべきである。これらの用語は、ある要素を別の要素と区別するためにのみ使用される。例えば、例示的な実施形態の範囲から逸脱することなく、第１の要素が第２の要素と呼ばれ得、同様に、第２の要素が第１の要素と呼ばれ得る。本明細書で使用されるように、「及び／又は」という用語には、列挙された用語の１つ又は複数のあらゆる組み合わせが含まれる。
【0033】
本明細書で使用される用語は、特定の実施形態を説明することのみを目的としており、例示的な実施形態を限定することを意図したものではない。本明細書で使用されるように、単数形「a（一つの）」、「an（一つの）」、及び「the（その）」は、文脈上明らかに別段の指示がない限り、複数形も含むものとする。「含む」、「備える」、「有する」、「持つ」、「含有する」及び／又は「包含する」という用語は、本明細書で使用される場合、記載された特徴、要素、及び／又は構成要素などの存在を指定するが、１つ又は複数の他の特徴、要素、構成要素及び／又はそれらの組み合わせの存在又は追加を排除するものではないことがさらに理解されるであろう。
【0034】
例示的な環境
図１は、本開示の技術を利用し得る例示的なビデオコーディングシステム１００を示すブロック図である。図示されるように、ビデオコーディングシステム１００は、ソースデバイス１１０と、宛先デバイス１２０とを含み得る。ソースデバイス１１０は、ビデオエンコーディングデバイスとも呼ばれ得、宛先デバイス１２０は、ビデオデコーディングデバイスとも呼ばれ得る。動作中、ソースデバイス１１０は、エンコードされたビデオデータを生成するように構成することができ、宛先デバイス１２０は、ソースデバイス１１０によって生成されたエンコードされたビデオデータをデコードするように構成することができる。ソースデバイス１１０は、ビデオソース１１２と、ビデオエンコーダ１１４と、入力／出力（Ｉ／Ｏ）インターフェース１１６とを含み得る。
図１は、本開示の技術を利用し得る例示的なビデオコーディングシステム１００を示すブロック図である。図示されるように、ビデオコーディングシステム１００は、ソースデバイス１１０と、宛先デバイス１２０とを含み得る。ソースデバイス１１０は、ビデオエンコーディングデバイスとも呼ばれ得、宛先デバイス１２０は、ビデオデコーディングデバイスとも呼ばれ得る。動作中、ソースデバイス１１０は、エンコードされたビデオデータを生成するように構成することができ、宛先デバイス１２０は、ソースデバイス１１０によって生成されたエンコードされたビデオデータをデコードするように構成することができる。ソースデバイス１１０は、ビデオソース１１２と、ビデオエンコーダ１１４と、入力／出力（Ｉ／Ｏ）インターフェース１１６とを含み得る。
【0035】
ビデオソース１１２は、ビデオキャプチャデバイスなどのソースを含み得る。ビデオキャプチャデバイスの例には、ビデオコンテンツプロバイダからビデオデータを受信するインターフェース、ビデオデータを生成するコンピュータグラフィックスシステム、及び／又はそれらの組み合わせが含まれるが、これらに限定されない。
【0036】
ビデオデータは、１つ又は複数の画像を含み得る。ビデオエンコーダ１１４は、ビデオソース１１２からのビデオデータをエンコードしてビットストリームを生成する。ビットストリームには、ビデオデータのコード化表現を形成する一連のビットが含まれ得る。ビットストリームには、コード化画像及び関連データが含まれ得る。コード化画像は、画像のコード化表現である。関連データには、シーケンスパラメータセット、画像パラメータセット、及び他の構文構造が含まれ得る。Ｉ／Ｏインターフェース１１６は、変調器/復調器及び／又は送信機を含み得る。エンコードされたビデオデータは、Ｉ／Ｏインターフェース１１６を介してネットワーク１３０Ａを通して宛先デバイス１２０に直接送信され得る。エンコードされたビデオデータは、宛先デバイス１２０によるアクセスのために記憶媒体/サーバ１３０Ｂに記憶されても良い。
【0037】
宛先デバイス１２０は、Ｉ／Ｏインターフェース１２６と、ビデオデコーダ１２４と、表示デバイス１２２とを含み得る。Ｉ／Ｏインターフェース１２６は、受信機及び／又はモデムを含み得る。Ｉ／Ｏインターフェース１２６は、ソースデバイス１１０又は記憶媒体／サーバ１３０Ｂからエンコードされたビデオデータを取得し得る。ビデオデコーダ１２４は、エンコードされたビデオデータをデコードし得る。表示デバイス１２２は、デコードされたビデオデータをユーザに表示し得る。表示デバイス１２２は、宛先デバイス１２０と一体化されて得、或いは外部表示デバイスとインターフェースするように構成された宛先デバイス１２０の外部にあり得る。
【0038】
ビデオエンコーダ１１４及びビデオデコーダ１２４は、High Efficiency Video Coding（高効率ビデオコーディング、ＨＥＶＣ）規格、Versatile Video Coding（多用途ビデオコーディング、ＶＶＣ）規格及び他の現在の及び／又はさらなる規格などのビデオ圧縮規格に従って動作し得る。
【0039】
【0040】
ビデオエンコーダ２００は、本開示の技術のいずれか又は全てを具現するように構成され得る。図２の例では、ビデオエンコーダ２００は複数の機能コンポーネントを含む。本開示で説明される技術は、ビデオエンコーダ２００の様々なコンポーネント間で共有され得る。いくつかの例では、プロセッサは、本開示で説明された技術のいずれか又は全てを実行するように構成され得る。
【0041】
いくつかの実施形態では、ビデオエンコーダ２００は、分割ユニット２０１と、モード選択ユニット２０３、動き推定ユニット２０４、動き補償ユニット２０５及びイントラ予測ユニット２０６を含み得る予測ユニット２０２と、残差生成ユニット２０７と、変換ユニット２０８と、量子化ユニット２０９と、逆量子化ユニット２１０と、逆変換ユニット２１１と、再構築ユニット２１２と、バッファ２１３と、エントロピーエンコーディングユニット２１４とを含み得る。
【0042】
他の例では、ビデオエンコーダ２００は、より多くの、より少ない、又は異なる機能コンポーネントを含み得る。一例では、予測ユニット２０２は、イントラブロックコピー（ＩＢＣ）ユニットを含み得る。ＩＢＣユニットは、少なくとも１つの参照画像が現在のビデオブロックが位置する画像であるＩＢＣモードで予測を実行し得る。
【0043】
さらに、動き推定ユニット２０４及び動き補償ユニット２０５などのいくつかの構成要素は統合され得るが、図２の例では説明の目的で別々に表されている。
【0044】
分割ユニット２０１は、画像を１つ又は複数のビデオブロックに分割し得る。ビデオエンコーダ２００及びビデオデコーダ３００は、多様なビデオブロックサイズをサポートし得る。
【0045】
モード選択ユニット２０３は、例えば、エラー結果に基づいて、イントラ又はインターのコーディングモードのうちの１つを選択し、その結果から得られるイントラコード化又はインターコード化されたブロックを、残差ブロックデータを生成するように残差生成ユニット２０７に提供し、エンコードされたブロックを再構築して参照画像として使用するように再構築ユニット２１２に提供し得る。いくつかの例では、モード選択ユニット２０３は、予測がインター予測信号及びイントラ予測信号に基づくイントラ及びインター予測の組み合わせ（ＣＩＩＰ）モードを選択し得る。モード選択ユニット２０３は、インター予測の場合、ブロックの動きベクトルの解像度（例：サブピクセル又は整数ピクセル精度）を選択してもよい。
【0046】
現在のビデオブロックに対してインター予測を実行するために、動き推定ユニット２０４は、バッファ２１３からの１つ又は複数の参照フレームを現在のビデオブロックと比較することで現在のビデオブロックの動き情報を生成し得る。動き補償ユニット２０５は、現在のビデオブロックに関連付けられた画像以外のバッファ２１３からの画像の動き情報及びデコードされたサンプルに基づいて、現在のビデオブロックの予測ビデオブロックを決定し得る。
【0047】
動き推定ユニット２０４及び動き補償ユニット２０５は、例えば、現在のビデオブロックがＩスライス、Ｐスライス、又はＢスライスのいずれにあるかに応じて、現在のビデオブロックに対して異なる演算を実行し得る。本明細書で使用されるように、「Ｉスライス」は、マクロブロックから構成される画像の一部を指し得、その全てが同じ画像内のマクロブロックに基づいている。さらに、本明細書で使用されるように、いくつかの態様では、「Ｐスライス」及び「Ｂスライス」は、同じ画像内のマクロブロックに依存しないマクロブロックから構成される画像の部分を指し得る。
【0048】
いくつかの例では、動き推定ユニット２０４は、現在のビデオブロックに対して単方向予測を実行し得、動き推定ユニット２０４は、現在のビデオブロックの参照ビデオブロックについてのリスト０又はリスト１の参照画像を探し得る。次に、動き推定ユニット２０４は、参照ビデオブロックを含むリスト０又はリスト１内の参照画像を示す参照インデックスと、現在のビデオブロックと参照ビデオブロックとの間の空間的変位を示す動きベクトルとを生成し得る。動き推定ユニット２０４は、参照インデックス、予測方向指示子、及び動きベクトルを現在のビデオブロックの動き情報として出力し得る。動き補償ユニット２０５は、現在のビデオブロックの動き情報によって示される参照ビデオブロックに基づいて、現在のビデオブロックの予測ビデオブロックを生成し得る。
【0049】
代替的に、他の例では、動き推定ユニット２０４は、現在のビデオブロックに対して双方向予測を実行し得る。動き推定ユニット２０４は、現在のビデオブロックの参照ビデオブロックについてのリスト０内の参照画像を探してもよいし、現在のビデオブロックの別の参照ビデオブロックについてのリスト１内の参照画像を探してもよい。次に、動き推定ユニット２０４は、参照ビデオブロックを含むリスト０及びリスト１内の参照画像を示す参照インデックスと、参照ビデオブロックと現在のビデオブロックとの間の空間的変位を示す動きベクトルとを生成し得る。動き推定ユニット２０４は、現在のビデオブロックの参照インデックス及び動きベクトルを現在のビデオブロックの動き情報として出力し得る。動き補償ユニット２０５は、現在のビデオブロックの動き情報によって示される参照ビデオブロックに基づいて、現在のビデオブロックの予測ビデオブロックを生成し得る。
【0050】
いくつかの例では、動き推定ユニット２０４は、デコーダのデコーディング処理のためのフルセットの動き情報を出力し得る。代替的に、いくつかの実施形態では、動き推定ユニット２０４は、別のビデオブロックの動き情報を参照して現在のビデオブロックの動き情報をシグナリングし得る。例えば、動き推定ユニット２０４は、現在のビデオブロックの動き情報が隣接するビデオブロックの動き情報と十分に類似していると決定し得る。
【0051】
一例では、動き推定ユニット２０４は、現在のビデオブロックに関連付けられた構文構造において、現在のビデオブロックが別のビデオブロックと同じ動き情報を有することをビデオデコーダ３００に示す値を示し得る。
【0052】
別の例では、動き推定ユニット２０４は、現在のビデオブロックに関連付けられた構文構造において、別のビデオブロック及び動きベクトル差分（ＭＶＤ）を識別し得る。動きベクトル差分は、現在のビデオブロックの動きベクトルと、指示されたビデオブロックの動きベクトルとの間の差分を示す。ビデオデコーダ３００は、指示されたビデオブロックの動きベクトル及び動きベクトル差分を使用して現在のビデオブロックの動きベクトルを決定し得る。
【0053】
上で論じたように、ビデオエンコーダ２００は、動きベクトルを予測的にシグナリングし得る。ビデオエンコーダ２００によって具現され得る予測シグナリング技術の２つの例には、アドバンスト動きベクトル予測（ＡＭＶＰ）とマージモードシグナリングとが含まれる。
【0054】
イントラ予測ユニット２０６は、現在のビデオブロックに対してイントラ予測を実行し得る。イントラ予測ユニット２０６が現在のビデオブロックに対してイントラ予測を実行するとき、イントラ予測ユニット２０６は、同じ画像内の他のビデオブロックのデコードされたサンプルに基づいて、現在のビデオブロックについての予測データを生成し得る。現在のビデオブロックについての予測データには、予測されたビデオブロック及び様々な構文要素が含まれ得る。
【0055】
残差生成ユニット２０７は、現在のビデオブロックから現在のビデオブロックの予測ビデオブロックを減算する（例：マイナス記号によって示される）ことで、現在のビデオブロックについての残差データを生成し得る。現在のビデオブロックの残差データは、現在のビデオブロック内のサンプルの異なるサンプル成分に対応する残差ビデオブロックを含み得る。
【0056】
他の例では、例えばスキップモードにおいて、現在のビデオブロックについての残差データが存在しなくてもよいし、残差生成ユニット２０７は減算演算を実行しなくてもよい。
【0057】
変換処理ユニット２０８は、現在のビデオブロックに関連付けられた残差ビデオブロックに１つ又は複数の変換を適用することによって、現在のビデオブロックについての１つ又は複数の変換係数ビデオブロックを生成し得る。
【0058】
変換処理ユニット２０８が現在のビデオブロックに関連付けられた変換係数ビデオブロックを生成した後、量子化ユニット２０９は、現在のビデオブロックに関連付けられた１つ又は複数の量子化パラメータ（ＱＰ）値に基づいて、現在のビデオブロックに関連付けられた変換係数ビデオブロックを量子化し得る。
【0059】
逆量子化ユニット２１０及び逆変換ユニット２１１は、それぞれ、変換係数ビデオブロックに逆量子化及び逆変換を適用して、変換係数ビデオブロックから残差ビデオブロックを再構築し得る。再構築ユニット２１２は、再構築された残差ビデオブロックを、予測ユニット２０２によって生成された１つ又は複数の予測ビデオブロックからの対応するサンプルに追加して、バッファ２１３に記憶するために現在のビデオブロックに関連付けられた再構築ビデオブロックを生成し得る。
【0060】
再構築ユニット２１２がビデオブロックを再構築した後、ループフィルタリング動作が実行されて、ビデオブロック内のビデオブロッキングアーティファクトを低減し得る。
【0061】
エントロピーエンコーディングユニット２１４は、ビデオエンコーダ２００の他の機能コンポーネントからデータを受信し得る。エントロピーエンコーディングユニット２１４がデータを受信すると、エントロピーエンコーディングユニット２１４は、１つ又は複数のエントロピーエンコーディング動作を実行して、エントロピーエンコード化データを生成し、エントロピーエンコード化データを含むビットストリームを出力し得る。
【0062】
【0063】
ビデオデコーダ３００は、本開示の技術のいずれか又は全てを実行するように構成され得る。図３の例では、ビデオデコーダ３００は複数の機能コンポーネントを含む。本開示で説明される技術は、ビデオデコーダ３００の様々なコンポーネント間で共有され得る。いくつかの例では、プロセッサは、本開示で説明された技術のいずれか又は全てを実行するように構成され得る。
【0064】
図３の例では、ビデオデコーダ３００は、エントロピーデコーディングユニット３０１と、動き補償ユニット３０２と、イントラ予測ユニット３０３と、逆量子化ユニット３０４と、逆変換ユニット３０５と、再構築ユニット３０６と、バッファ３０７とを含む。ビデオデコーダ３００は、いくつかの例では、ビデオエンコーダ２００に関して説明したエンコーディングパスと一般に逆のデコーディングパスを実行し得る。
【0065】
エントロピーデコーディングユニット３０１は、エンコードされたビットストリームを取り戻し得る。エンコードされたビットストリームは、エントロピーコード化されたビデオデータ（例：ビデオデータのエンコードされたブロック）を含み得る。エントロピーデコーディングユニット３０１は、エントロピーコード化されたビデオデータをデコードし得、エントロピーデコードされたビデオデータから、動き補償ユニット３０２は、動きベクトル、動きベクトル精度、参照画像リストインデックス及び他の動き情報を含む動き情報を決定し得る。動き補償ユニット３０２は、例えば、ＡＭＶＰ及びマージモードを実行することによってそのような情報を決定し得る。ＡＭＶＰが使用され、隣接するＰＢ及び参照画像からのデータに基づいた最もあり得るいくつかの候補の導出を含む。動き情報には、通常、水平及び垂直動きベクトル変位値、１つ又は２つの参照画像インデックス、及びＢスライス内の予測領域の場合は、どの参照画像リストが各インデックスに関連付けられているかの識別が含まれる。本明細書で使用されるように、いくつかの態様では、「マージモード」は、空間的又は時間的に隣接するブロックから動き情報を導出することを指し得る。
【0066】
動き補償ユニット３０２は、おそらく補間フィルタに基づいて補間を実行しながら、動き補償されたブロックを生成し得る。サブピクセル精度で使用される補間フィルタの識別子が構文要素に含まれ得る。
【0067】
動き補償ユニット３０２は、ビデオブロックのエンコーディング中にビデオエンコーダ２００によって使用される補間フィルタを使用して、参照ブロックのサブ整数ピクセルについての補間値を計算し得る。動き補償ユニット３０２は、受信した構文情報に従ってビデオエンコーダ２００によって使用される補間フィルタを決定し、その補間フィルタを使用して予測ブロックを生成し得る。
【0068】
動き補償ユニット３０２は、構文情報の少なくとも一部を使用して、エンコードされたビデオシーケンスのフレーム及び／又はスライスをエンコードするために使用されるブロックのサイズ、エンコードされたビデオシーケンスの画像の各マクロブロックがどのように分割されるかを説明するパーティション情報、各パーティションがどのようにエンコードされるかを示すモード、各インターエンコードされたブロックの１つ又は複数の参照フレーム(及び参照フレームリスト)、及びエンコードされたビデオシーケンスをデコードするその他の情報を決定し得る。本明細書で使用されるように、いくつかの態様では、「スライス」は、エントロピーコーディング、信号予測、及び残差信号再構築に関して、同じ画像の他のスライスから独立してデコードできるデータ構造を指し得る。スライスは、画像全体又は画像の領域のいずれかになり得る。
【0069】
イントラ予測ユニット３０３は、例えばビットストリームで受信されたイントラ予測モードを使用して、空間的に隣接するブロックから予測ブロックを形成し得る。逆量子化ユニット３０４は、ビットストリームで提供され、エントロピーデコーディングユニット３０１によってデコードされた量子化ビデオブロック係数を逆量子化、即ち量子化解除する。逆変換ユニット３０５は、逆変換を適用する。
【0070】
再構築ユニット３０６は、例えば、残差ブロックと、動き補償ユニット３０２又はイントラ予測ユニット３０３によって生成された対応する予測ブロックとを加算することで、デコードされたブロックを取得し得る。必要に応じて、デブロッキングフィルタが適用されて、ブロックアーティファクトを除去するよう、デコードされたブロックをフィルタリングしてもよい。次に、デコードされたビデオブロックはバッファ３０７に記憶され、バッファ３０７は、後続の動き補償／イントラ予測のための参照ブロックを提供し、また、表示デバイス上にプレゼンテーションするためのデコードされたビデオも生成する。
【0071】
本開示のいくつかの例示的な実施形態について以下に詳細に説明することにする。本明細書では理解を容易にするためにセクション見出しが使用されているが、セクションで開示される実施形態をそのセクションのみに限定するものではないことを理解すべきである。さらに、特定の実施形態が多用途ビデオコーディング又は他の特定のビデオコーデックを参照して説明されるが、開示された技術は他のビデオコーディング技術にも適用可能である。さらに、いくつかの実施形態はビデオコーディングステップを詳細に説明するが、コーディングを元に戻す対応するデコーディングステップはデコーダによって実施されることが理解されるであろう。さらに、ビデオ処理という用語には、ビデオコーディング又は圧縮、ビデオデコーディング又は解凍、及びビデオピクセルを１つの圧縮フォーマットから別の圧縮フォーマット又は異なる圧縮ビットレートで表現するビデオトランスコーディングが包含される。
1. 概要
この開示は、メディアファイルフォーマットに関する。具体的には、適切なサンプルエントリタイプを持つ外部ストリームトラック（ＥＳＴ）のシグナリングに関するものであって、ＥＳＴ内の１つのサンプルに複数のコード化画像を含めることが可能になる。ＥＳＴは、メインストリームトラック（ＭＳＴ）内の拡張従属ランダムアクセスポイント（ＥＤＲＡＰ）画像からのランダムアクセスに必要な外部画像を提供する。これらのアイデアは、ＩＳＯベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ）及びＩＳＯＢＭＦＦから派生したファイルフォーマットなど、任意のメディアファイルフォーマットに従ってメディアファイルに個別に、又は様々な組み合わせで適用され得る。
2. 背景
2.1 ビデオコーディング規格
ビデオコーディング規格は、主によく知られているITU-T及びISO/IEC規格の開発を通じて進化している。ITU-TはH.261とH.263を策定し、ISO/IECはMPEG-1とMPEG-4 Visualを策定し、この２つの組織は共同でH.262/MPEG-2 Video、H.264/MPEG-4 Advanced Video Coding(ＡＶＣ)、及びH.265/ＨＥＶＣ規格を策定した。H.262以降、ビデオコーディング規格は、時間予測及び変換コーディングが利用されるハイブリッドビデオコーディング構造に基づいている。ＨＥＶＣを超える将来のビデオコーディング技術を探求するために、２０１５年にＶＣＥＧとＭＰＥＧによって共同ビデオ探索チーム（Joint Video Exploration Team、ＪＶＥＴ）が設立された。それ以来、多くの新しい方法がＪＶＥＴに採用され、共同探索モデル（Joint Exploration Model、ＪＥＭ）と呼ばれる参照ソフトウェアに取り入れられている。ＪＶＥＴは、Versatile Video Coding（ＶＶＣ)プロジェクトが正式に開始されたときに、共同ビデオ専門家チーム（Joint Video Experts Team、ＪＶＥＴ）に改名された。ＶＶＣは、ＨＥＶＣと比較して５０％のビットレート削減を目標とし、２０２０年7月１日に終了したＪＶＥＴの第１９回会議で最終決定された新しいコーディング規格である。
多用途ビデオコーディング（Versatile Video Coding、ＶＶＣ）規格（ITU-T H.266 | ISO/IEC 23090-3）と関連する多用途補足拡張情報（ＶＳＥＩ）規格（ITU-T H.274 | ISO/IEC 23002-7）は、テレビ放送、ビデオ会議、ストレージメディアからの再生などの従来の用途だけでなく、アダプティブビットレートストリーミング、ビデオ領域の抽、複数のコード化ビデオビットストリームからのコンテンツの合成及びマージング、マルチビュービデオ、スケーラブルな階層化コーディング、ビューポート適応型３６０°イマーシブメディアなどの新しい高度な用途も含め、最大限に幅広いアプリケーションで使用されるように設計されている。
2.2 ファイルフォーマット規格
メディアストリーミングアプリケーションは、通常、ＩＰ、ＴＣＰ、及びＨＴＴＰトランスポートメソッドに基づいており、通常はＩＳＯベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ）などのファイルフォーマットに依存する。このようなストリーミングシステムの１つが、ＨＴＴＰ経由の動的アダプティブストリーミング（ＤＡＳＨ）である。ＩＳＯＢＭＦＦ及びＤＡＳＨでビデオフォーマットを使用する場合、ＡＶＣファイルフォーマット及びＨＥＶＣファイルフォーマットなどのビデオフォーマットに特有のファイルフォーマット仕様が、ＩＳＯＢＭＦＦトラック及びＤＡＳＨ表現とセグメントでのビデオコンテンツのカプセル化に必要になり得る。ビデオビットストリームに関する重要な情報、例えばプロファイル、階層、レベル、その他多くの情報は、コンテンツ選択の目的で、例えばストリーミングセッションの開始時の初期化及びストリーミングセッション中のストリーム適応の両方での適切なメディアセグメントの選択のために、ファイルフォーマットレベルのメタデータ及び／又はＤＡＳＨメディアプレゼンテーション記述（ＭＰＤ）として公開されるべきである場合がある。同様に、ＩＳＯＢＭＦＦでイメージフォーマットを使用する場合は、ＡＶＣイメージファイルフォーマット及びＨＥＶＣイメージファイルフォーマットなど、イメージフォーマットに特有のファイルフォーマット仕様が必要になり得る。
2.3 ランダムアクセスとＨＥＶＣ及びＶＶＣにおけるそのサポート
ランダムアクセスとは、デコード順でビットストリームの最初の画像ではない画像からビットストリームのアクセスとデコーディングを開始することを指す。ブロードキャスト／マルチキャスト及びマルチパーティビデオ会議でのチューニングとチャンネル切り替え、ローカル再生とストリーミングでのシーキング、及びストリーミングでのストリーム適応をサポートするには、ビットストリームに頻繁なランダムアクセスポイントを含める必要があり、これは通常、イントラコーディング画像であるが、インターコード化画像である場合もある（例：段階的なデコーディング更新の場合)。
ＨＥＶＣには、ＮＡＬユニットタイプを通じたＮＡＬユニットヘッダー内のイントラランダムアクセスポイント（ＩＲＡＰ）画像のシグナリングが含まれる。３種類のＩＲＡＰ画像、つまり、瞬時デコーダリフレッシュ（ＩＤＲ）、クリーンランダムアクセス（ＣＲＡ）、及び切れたリンクアクセス（ＢＬＡ）画像がサポートされている。ＩＤＲ画像は、現在のグループオブピクチャ（ＧＯＰ）より前の画像を参照しないように画像間予測構造を制約しており、従来はクローズドＧＯＰランダムアクセスポイントと呼ばれている。ＣＲＡ画像は、特定の画像が、ランダムアクセスの場合には全て破棄される現在のＧＯＰより前の画像を参照可能にすることでより制限的でない。ＣＲＡ画像は従来、オープンＧＯＰランダムアクセスポイントと呼ばれている。ＢＬＡ画像は通常、ストリーム切り替え中など、ＣＲＡ画像での２つのビットストリーム又はその一部のスプライシングから生じる。ＩＲＡＰ画像のより良いシステム使用を可能にするために、合計６つの異なるＮＡＬユニットが、ＩＲＡＰ画像の特性をシグナリングするために定義されており、これは、ＨＴＴＰ経由の動的アダプティブ ストリーミング（ＤＡＳＨ）でのランダムアクセスサポートに利用される、ＩＳＯベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ）で定義されているストリームアクセスポイントタイプとよりよくマッチさせるために使用され得る。
ＶＶＣは、３種類のＩＲＡＰ画像、２種類のＩＤＲ画像（１種類はＲＡＤＬ画像が関連付けられ、又はもう１種類はＲＡＤＬ画像が関連付けられていない)、及び１種類のＣＲＡ画像をサポートしている。これらは基本的にＨＥＶＣと同じである。ＨＥＶＣにおけるＢＬＡ画像タイプは、主に次の２つの理由によりＶＶＣには含まれていない。ｉ）ＢＬＡ画像の基本機能は、ＣＲＡ画像及びシーケンス終了ＮＡＬユニットによって実現でき、シーケンス終了ＮＡＬユニットの存在は、後続の画像がシングルレイヤービットストリームで新しいＣＶＳを開始することを示す。ｉｉ）ＶＶＣの開発中、ＮＡＬユニットヘッダーでＮＡＬユニットタイプフィールドに６ビットではなく５ビットを使用して示されているように、ＨＥＶＣよりも少ないＮＡＬユニットタイプを指定することが望まれる。
ＶＶＣとＨＥＶＣのランダムアクセスサポートにおけるもう１つの重要な違いは、ＶＶＣではより規範的な方式でＧＤＲがサポートされていることである。ＧＤＲでは、ビットストリームのデコーディングはインターコード化画像から開始でき、最初は画像領域全体を正しくデコードできる、いくつかの画像の後には画像領域全体が正しくなる。ＡＶＣとＨＥＶＣもＧＤＲをサポートしており、ＧＤＲランダムアクセスポイント及びリカバリポイントのシグナリングにリカバリポイントＳＥＩメッセージを使用している。ＶＶＣでは、ＧＤＲ画像を示すために新しいＮＡＬユニットタイプが指定され、リカバリポイントは画像ヘッダー構文構造でシグナリングされる。ＣＶＳとビットストリームはＧＤＲ画像から開始することが許可される。これは、ビットストリーム全体に、単一のイントラコード化画像がなく、インターコード化画像のみが含まれることが許可されることを意味する。このようにＧＤＲサポートを指定することの主な利点は、ＧＤＲに適合した行動を提供することである。ＧＤＲは、エンコーダが、画像全体のイントラコーディングとは対照的に、複数の画像にイントラコード化スライス又はブロックを分散させることでビットストリームのビットレートを平滑化するのを可能にし、これにより、エンドツーエンド遅延を大幅に削減可能になり、ワイヤレスディスプレイ、オンラインゲーム、ドローンベースのアプリケーションなどの超低遅延アプリケーションが普及するにつれて、これは以前よりも重要視されるようになった。
ＶＶＣにおける別のＧＤＲ関連特徴は、仮想境界シグナリングである。ＧＤＲ画像とそのリカバリポイント間の画像におけるリフレッシュされた領域（即ち、正しくデコードされた領域）とリフレッシュされていない領域との境界は、仮想境界としてシグナリングされ得、通知されると、境界を越えるループ内フィルタリングは適用されないため、境界又はその近くの一部のサンプルのデコーディングミスマッチは発生しない。これは、アプリケーションがＧＤＲプロセス中に正しくデコードされた領域を表示することを決定した場合に役立つ。
ＩＲＡＰ画像とＧＤＲ画像は、まとめてランダムアクセスポイント（ＲＡＰ）画像と呼ばれる。
2.4 拡張従属ランダムアクセスポイント（ＥＤＲＡＰ）ベースのビデオコーディング、ストレージ及びストリーミング
2.4.1 概念及び規格サポート
ＥＤＲＡＰベースのビデオコーディング、ストレージ及びストリーミングの概念を以下の図４～１１を参照して説明する。
図４及び図５は、ランダムアクセスポイント（ＲＡＰ）の既存の概念を示す図である。アプリケーション（例：アダプティブストリーミング）は、例えば、ＲＡＰ期間１秒又は２秒など、ランダムアクセスポイント（ＲＡＰ）の頻度を決定する。従来、ＲＡＰは、図４に示すように、ＩＲＡＰ画像のコーディングによって提供される。ＲＡＰ画像間の非キー画像についてのインター予測参照は示されておらず、出力順序は左から右であることに注意されたい。ＣＲＡ６からランダムアクセスする場合、デコーダは、図５に示すように、画像を受信し、正しくデコードする。
図６及び図７は、従属ランダムアクセスポイント（ＤＲＡＰ）の概念を示す図である。ＤＲＡＰアプローチは、図６に示すように、ＤＲＡＰ画像(及び後続の画像)がインター予測のために前のＩＲＡＰ画像を参照するのを許可することで向上されたコーディング効率を提供する。ＲＡＰ画像間の非キー画像についてのインター予測は示されておらず、出力順序は左から右であることに注意されたい。ＤＲＡＰ６からランダムアクセスする場合、デコーダは図７に示すように画像を受信し、正しくデコードする。
図８及び図９は、拡張従属ランダムアクセスポイント（ＥＤＲＡＰ）の概念を示す図である。ＥＤＲＡＰアプローチは、図８に示すように、ＥＤＲＡＰ画像（及び後続の画像）が以前のＲＡＰ画像（ＩＲＡＰ又はＥＤＲＡＰ)のいくつかを参照するのを許可することでもう少し柔軟性を提供する。ＲＡＰ画像間の非キー画像についてのインター予測は示されておらず、出力順序は左から右であることに注意されたい。ＥＤＲＡＰ６からランダムアクセスする場合、デコーダは図９に示すように画像を受信し、正しくデコードする。
図１０及び図１１は、ＥＤＲＡＰベースのビデオストリーミングを示す図である。ＥＤＲＡＰ６から始まるセグメントからランダムアクセス、又は該セグメントに切り替えると、デコーダは図１１に示すようにセグメントを受信してデコードする。
ＥＤＲＡＰベースのビデオコーディングは、ＶＳＥＩ規格の開発中の修正に含まれるＥＤＲＡＰ指示ＳＥＩメッセージによってサポートされ、ストレージ部分は、ＩＳＯＢＭＦＦ規格の開発中の修正に含まれるＥＤＲＡＰサンプルグループ及び関連する外部ストリームトラック参照によってサポートされ、ストリーミング部分は、ＤＡＳＨ規格の開発中の修正に含まれるメインストリーム表現（ＭＳＲ）記述子及び外部ストリーム表現（ＥＳＲ）記述子によってサポートされる。
2.4.2 ＥＤＲＡＰ指示ＳＥＩメッセージ
ＶＳＥＩ規格についての修正は開発中である。この修正の最新ドラフト仕様には、ＥＤＲＡＰ指示ＳＥＩメッセージの仕様が含まれている。
ＥＤＲＡＰ指示ＳＥＩメッセージの構文とセマンティクスは次のとおりである。
拡張ＤＲＡＰ（ＥＤＲＡＰ）指示ＳＥＩメッセージに関連付けられた画像は、ＥＤＲＡＰ画像と呼ばれる。
ＥＤＲＡＰ指示ＳＥＩメッセージが存在する場合、このサブ条項で指定されている画像順序及び画像参照に関する制約が適用されることを示す。これらの制約により、デコーダは、同じＣＬＶＳ内にあり、かつedrap_ref_rap_id[ i ]構文要素によって識別されるデコード順のＩＲＡＰ又はＥＤＲＡＰ画像のリストで構成されるreferenceablePicturesのリストを除いて、同じレイヤー内の他の任意の画像をデコードする必要なく、同じレイヤーにあるＥＤＲＡＰ画像及びデコード順と出力順の両方でそれの後に続く画像を適切にデコードできる。
全て適用されるものとする、ＥＤＲＡＰ指示ＳＥＩメッセージの存在によって示される制約は、次のとおりである。
－ ＥＤＲＡＰ画像は、トレーリング画像である。
－ ＥＤＲＡＰ画像は、０に等しい時間的サブレイヤー識別子を有する。
－ ＥＤＲＡＰ画像は、referenceablePicturesを除き、参照画像リストのアクティブエントリにおける同じレイヤー内の画像を含まない。
－ 同じレイヤーにあり、かつデコード順と出力順の両方でＥＤＲＡＰ画像の後に続く任意の画像は、referenceablePicturesを除き、その参照画像リストのアクティブエントリに、同じレイヤーにあり、かつデコード順又は出力順でＥＤＲＡＰ画像に先行する画像を含まない。
－ リストreferenceablePictures内の任意の画像は、その参照画像リストのアクティブエントリに、同じレイヤーにあり、かつリストreferenceablePictures内の前の位置にある画像ではない画像を含まない。
注 － その結果、referenceablePictures内の最初の画像は、ＩＲＡＰ画像ではなくＥＤＲＡＰ画像であっても、その参照画像リストのアクティブエントリに同じレイヤーからの任意の画像を含まない。
edrap_rap_id_minus1プラス１は、ＥＤＲＡＰ画像のＲＡＰ画像識別子（RapPicIdとして表記）を指定する。
各ＩＲＡＰ又はＥＤＲＡＰ画像には、RapPicId値が関連付けられている。ＩＲＡＰ画像のRapPicId値は０に等しいと推論される。同じＩＲＡＰ画像に関連付けられている任意の２つのＥＤＲＡＰ画像についてのRapPicId値は異なるものとする。
edrap_leading_pictures_decodable_flagが１に等しい場合、次の制約の両方が適用されることを指定する。
－ 同じレイヤーにあり、かつデコード順でＥＤＲＡＰ画像の後に続く任意の画像は、出力順で、同じレイヤーにあり、かつデコード順でＥＤＲＡＰ画像に先行する画像の後に続くものとする。
－ 同じレイヤーにあり、かつデコード順でＥＤＲＡＰ画像の後に続き、出力順でＥＤＲＡＰ画像に先行する任意の画像は、その参照画像リストのアクティブエントリに、referenceablePicturesを除き、同じレイヤーにあり、かつデコード順でＥＤＲＡＰに先行する任意の画像を含まないものとする。
edrap_leading_pictures_decodable_flagが０に等しい場合、このような制約は課されない。
edrap_reserved_zero_12bitsは、この仕様のこのバージョンに準拠するビットストリームでは０に等しいものとする。edrap_reserved_zero_12bitsの他の値は、ITU-T | ISO/IECによる将来の使用のために予備されている。デコーダは、edrap_reserved_zero_12bitsの値を無視するものとする。
edrap_num_ref_rap_pics_minus1プラス１は、ＥＤＲＡＰ画像と同じＣＬＶＳ内にあり、かつＥＤＲＡＰ画像の参照画像リストのアクティブエントリに含まれ得るＩＲＡＰ又はＥＤＲＡＰ画像の数を示す。
edrap_ref_rap_id[ i ]は、ＥＤＲＡＰ画像の参照画像リストのアクティブエントリに含まれ得るi番目のＲＡＰ画像のRapPicIdを示す。i番目のＲＡＰ画像は、現在のＥＤＲＡＰ画像に関連付けられたＩＲＡＰ画像、又は現在のＥＤＲＡＰ画像と同じＩＲＡＰ画像に関連付けられたＥＤＲＡＰ画像のいずれかであるものとする。
2.4.3 ＥＤＲＡＰサンプルグループ及び関連する外部ストリームトラック参照
ＩＳＯＢＭＦＦ規格の修正が開発中である。この修正の最新ドラフト仕様には、ＥＤＲＡＰサンプルグループ及び関連する外部ストリームトラック参照の仕様が含まれている。
これら２つのＩＳＯＢＭＦＦ特徴の仕様は次のとおりである。
3.1 定義
外部基本ストリーム
外部画像を備えるアクセスユニットを含むエレメンタリーストリーム
外部画像
ＥＳＴにおける外部エレメンタリーストリームにある画像で、ＭＳＴにおける特定のＥＤＲＡＰ画像からランダムアクセスするときに、ＭＳＴにおけるエレメンタリーストリームのデコーディングにおいてインター予測参照に必要な画像
外部ストリームトラック（ＥＳＴ）
外部エレメンタリーストリームを含むトラック
メインストリームトラック（ＭＳＴ）ビデオエレメンタリーストリームを含むトラック
3.2 略語
ＥＤＲＡＰ 拡張従属ランダムアクセスポイント
ＥＳＴ 外部ストリームトラック
ＭＳＴ メインストリームトラック
8.3.3.4 関連する外部ストリームトラック参照
タイプ「aest」（「関連付けられた外部ストリームトラック」を意味する）のトラック参照が、ＥＳＴを参照するＭＳＴに含まれ得る。
ＭＳＴにタイプ「aest」のトラック参照がある場合、以下が適用される。
－ ＭＳＴには、ＥＤＲＡＰ画像を含む少なくとも１つのサンプルがあるものとする。
－ ＥＤＲＡＰ画像を含むＭＳＴにおける各サンプルsampleAに対して、sampleAと同じデコード時間を持つ関連ＥＳＴにおける１つのサンプルsampleBのみが存在するものとし、sampleBから開始して、関連付けられたＥＳＴにおける連続したサンプルには、sampleAに含まれるＥＤＲＡＰ画像からランダムアクセスするときに必要な全ての外部画像が排他的に含まれているものとする。
ＥＳＴ内の全てのサンプルは、同期（sync）サンプルとして識別されるものとする。ＥＳＴトラックヘッダーフラグでは、track_in_movieとtrack_in_previewの両方が０に設定されるものとする。
10.11 拡張ＤＲＡＰ（ＥＤＲＡＰ）サンプルグループ
10.11.1 定義
このサンプルグループは、サブ条項10.8で指定されているＤＲＡＰサンプルグループに似ているが、より柔軟なクロスＲＡＰ参照を可能にする。
ＥＤＲＡＰサンプルは、ＥＤＲＡＰサンプルに先行する最も近い初期サンプルと、ＥＤＲＡＰサンプルよりもデコード順序が早い１つ以上の他の識別されたＥＤＲＡＰサンプルが参照に利用可能な場合、その後デコード順と出力順の全てのサンプルが正しくデコードされ得るサンプルである。
初期サンプルは、同期サンプル又はＳＡＰサンプルグループによってそのようにマークされたＳＡＰタイプ１、２又は３のＳＡＰサンプルである。例えば、ファイル内の３２番目のサンプルがＩピクチャで構成される初期サンプルである場合、４８番目のサンプルはＰピクチャで構成され、ＥＤＲＡＰサンプルグループのメンバーとしてマークされ得、これにより、最初に３２番目のサンプルをデコードし（サンプル３３～４７は無視）、次に４８番目のサンプルからデコードを続けることで、４８番目のサンプルでランダムアクセスを実行できることを示す。
注：ＥＤＲＡＰサンプルは、タイプ１、２及び３のＳＡＰサンプルと組み合わせてのみ使用できる。これは、先行するＳＡＰサンプルと、ＥＤＲＡＰサンプルよりもデコード順序が早い０個以上の他の識別されたＥＤＲＡＰサンプルを、ＥＤＲＡＰサンプル及びデコード順と出力順でＥＤＲＡＰサンプルの後に続くサンプルと連結（concatenating）することにより、デコード可能なサンプルシーケンスを作成する機能を有効にするためである。
サンプルは、次の条件が満たされる場合にのみ、ＥＤＲＡＰサンプルグループのメンバーになることができる。
－ ＥＤＲＡＰサンプルは、最も近い先行する初期サンプルと、ＥＤＲＡＰサンプルよりもデコード順序が早い１つ以上の他の識別されたＥＤＲＡＰサンプルのみを参照する。
－ ＥＤＲＡＰサンプルと、デコード順及び出力順でＥＤＲＡＰサンプルに続く全てのサンプルは、Syncサンプル又はＳＡＰサンプルグループとしてマークされたタイプ１、２又は３の最も近い先行ＳＡＰサンプルをデコードした後、及びデコード順でＥＤＲＡＰサンプルより前の０個以上の他の識別されたＥＤＲＡＰサンプルをデコードした後に、ＥＤＲＡＰサンプルでデコードを開始すると、正しくデコードされ得る。
10.11.2 構文
10.11.3 セマンティクス
edrap_typeは非負整数である。edrap_typeが１から３の範囲にある場合、最も近い先行ＳＡＰ又は他のＥＤＲＡＰサンプルに依存していなかったら、ＥＤＲＡＰサンプルが対応したであろうSAP_type（付録Iで指定）を示す。その他のタイプの値は予備されている。
num_ref_edrap_picsは、ＥＤＲＡＰサンプルよりもデコード順序が早く、ＥＤＲＡＰサンプルからデコードを開始するときに、ＥＤＲＡＰサンプル及びデコード順と出力順の両方でＥＤＲＡＰサンプルの後に続く全てのサンプルを正しくデコードできるようにするための参照に必要である、他のＥＤＲＡＰサンプルの数を示す。
reservedは０に等しいものとする。このサブ条項のセマンティクスは、予備済みのものが０に等しいサンプルグループ記述エントリにのみ適用される。パーサーは、このサンプルグループを解析するときに、予備済みのものが０より大きいサンプルグループ記述エントリを許可し、無視するものとする。
ref_edrap_idx_delta[i]は、このＥＤＲＡＰサンプルのサンプルグループインデックス（即ち、デコード順でこのサンプルグループ内の全てのサンプルのリストへのインデックス）と、ＥＤＲＡＰサンプルよりもデコード順が早く、このＥＤＲＡＰサンプルからデコードを開始するときに、ＥＤＲＡＰサンプル及びデコード順と出力順の両方でＥＤＲＡＰサンプルの後に続く全てのサンプルを正しくデコードできるようにするための参照に必要である、i番目のRAPサンプルのサンプルグループインデックスとの差を示す。
ＩＳＯＢＭＦＦでのサンプルエントリタイプ変換
ＩＳＯＢＭＦＦには、保護されるコンテンツ又はレンダリング前に特別なポストデコーダ処理要件を必要とするタイプのコンテンツのサンプルエントリの変換を可能にする特徴が含まれている。このようなポストデコーダ処理要件の例には、立体視ビデオサポートのフレームパッキング及び全方向又は３６０度ビデオサポートについての投影が含まれる。
ファイル作成者がプレーヤー又はレンダラーで特定のアクションを必要とする状況に対処するために、ＩＳＯＢＭＦＦには、プレーヤーが単にファイルを検査するだけでビットストリームのレンダリングの要件を見つけることを可能にし、さらなる処理が必要なファイルをレガシープレイヤー（legacy players）がデコードしてレンダリングするのを阻止するメカニズムが含まれている。このメカニズムは、任意のタイプのビデオコーデックに適用される。
このメカニズムは、サンプルエントリが汎用サンプルエントリ「encv」、「enca」などの背後に隠され、暗号化又はカプセル化されたメディアを示すコンテンツ保護変換に似ている。制限されたビデオの類似メカニズムでは、汎用サンプルエントリ「resv」による変換を使用する。この方法は、コンテンツを正しく表示するプレーヤーのみがデコードすべきである場合に適用され得る。
制限されたサンプルエントリ変換と関連するシグナリングは、次のように指定される。
2.5.1 制限されたサンプルエントリ変換
制限されたサンプルエントリは、次の変換手順が適用されたサンプルエントリとして定義される。
1) サンプルエントリの４文字コードが、制限されたビデオを意味するサンプルエントリコード「resv」に置き換えられる。
2) サンプル記述にRestrictedSchemeInfoBoxが追加され、他の全てのボックスは変更されない。
3) オリジナルサンプルエントリタイプは、RestrictedSchemeInfoBoxに含まれるOriginalFormatBox内に保存される。
RestrictedSchemeInfoBoxは、識別子「sinf」の代わりに「rinf」を使用する点を除いて、ProtectionSchemeInfoBoxとまったく同じ形式でフォーマットされる（下記参照）。
オリジナルサンプルエントリタイプは、（暗号化されたメディアについてのProtectionSchemeInfoBoxと同じ方式で）RestrictedSchemeInfoBoxに位置するOriginalFormatBoxに含まれている。
制限の正確な性質はSchemeTypeBoxで定義され、そのスキームに必要なデータは、また 、保護情報と類似的にSchemeInformationBoxに保存される。
制限及び保護は同時に適用され得る。変換の順序は、サンプルエントリの４文字コードに従う。例えば、サンプルエントリタイプが「resv」の場合、上記の変換を元に戻すと、サンプルエントリタイプが「encv」になり、メディアが保護されていることを示す。
ファイル作成者が、レガシープレイヤーによるファイルの再生を妨げずにアドバイス情報のみを提供したい場合、４文字コードを変換せずに、RestrictedSchemeInfoBoxがサンプルエントリ内に配置され得る。この場合、OriginalFormatBoxを含める必要はない。
2.5.2 制限付きスキーム情報ボックス
2.5.2.1 定義
ボックスタイプ： 「rinf」
コンテナー： 制限されたサンプルエントリ又はサンプルエントリ
必須: 制限されたサンプルエントリの場合ははい、それ以外の場合はいいえ
数量: ０又は１
RestrictedSchemeInfoBoxには、適用される制限スキームとそのパラメータの両方を理解するために必要な全ての情報が含まれている。また、メディアのオリジナル（変換されていない）サンプルエントリタイプも記録される。RestrictedSchemeInfoBoxはコンテナボックスである。制限されたストリームを示すコード（即ち、「resv」）を使用するサンプルエントリでは必須である。
制限されたサンプルエントリで使用する場合、このボックスには、オリジナルサンプルエントリタイプを記録するOriginalFormatBoxとSchemeTypeBoxが含まれるものとする。制限スキームによっては、SchemeInformationBoxが必要になり得る。
2.5.2.2 構文
2.5.3 スキームタイプボックス
2.5.3.1 定義
ボックスタイプ： 「schm」
コンテナー： ProtectionSchemeInfoBox、RestrictedSchemeInfoBox、又はSRTPProcessBox
必須: いいえ
数量: 「sinf」では保護構造に応じて０又は１。「rinf」及び「srpp」ででは正確に１。
SchemeTypeBoxは、保護又は制限スキームを識別する。
2.5.3.2 構文
2.5.3.3 セマンティクス
scheme_typeは、保護又は制限スキームを定義するコードで、通常は４文字コードとして表される。
scheme_versionは、スキームのバージョンである（コンテンツの作成に使用される）。
scheme_URIは、システムにスキームがインストールされていない場合にユーザをＷｅｂページに案内するオプションを許す絶対ＵＲＩである。
2.5.4 スキーム情報ボックス
2.5.4.1 定義
ボックスタイプ： 「schi」
コンテナー： ProtectionSchemeInfoBox、RestrictedSchemeInfoBox、又はSRTPProcessBox
必須: いいえ
数量: ０又は１
SchemeInformationBoxは、使用されているスキームによってのみ解釈されるコンテナボックスである。暗号化又は制限システムに必要な任意の情報はここに保存される。このボックスのコンテンツは、SchemeTypeBoxで宣言されたスキームによってタイプ及びフォーマットが定義される一連のボックスである。
2.5.4.2 構文
2.5.5 オリジナルフォーマットボックス
2.5.5.1 定義
ボックスタイプ： 「frma」
コンテナー： ProtectionSchemeInfoBox、RestrictedSchemeInfoBox、又はCompleteTrackInfoBox
必須: 保護されたサンプルエントリ、制限されたサンプルエントリ、又は不完全なトラックについてのサンプルエントリで使用される場合、はい。
数量: 正確に１。
OriginalFormatBoxには、変換されていないオリジナルサンプル記述の４文字コードが含まれる。
2.5.5.2 構文
2.5.5.3 セマンティクス
data_フォーマットは、変換されていないオリジナルサンプルエントリの４文字コードである（例:ストリームに保護又は制限されたMPEG-4ビジュアルマテリアルが含まれている場合は、「mp4v」）。
3. 問題点
ＥＤＲＡＰベースのビデオコーディング、ストレージ、ストリーミングのストレージ部分についての既存の設計に関係する問題が１つある。外部ストリームトラック（ＥＳＴ）のサンプルには、複数のコード化画像があり得る。したがって、通常のビデオサンプルエントリタイプ（例：ＶＣＣサンプルエントリタイプ又はＨＥＶＣサンプルエントリタイプ）をＥＳＴに使用すると、各サンプルにコード化画像が１つだけ含まれるものとするという通常の要件に違反することになる。
4. 詳細なソリューション
上記の問題を解決するために、以下に要約するような方法が開示される。これらのソリューションは、一般的な概念を説明するための例として考慮されるべきであり、狭義に解釈されるべきではない。さらに、これらのソリューションは、個別に適用されるか、又は任意の方式で組み合わせて適用され得る。
1) 一例では、通常のビデオサンプルエントリタイプを隠すために、新しい制限付きスキームタイプ（例：「aest」）を使用するサンプルエントリタイプ変換。次の１つ以上が適用される。
a. サンプルエントリの４文字コードは、サンプルエントリコード「resv」である。
b. 通常のビデオサンプルエントリタイプは、RestrictedSchemeInfoBoxに含まれるOriginalFormatBox内に保存される。
c. RestrictedSchemeInfoBoxにあるSchemeTypeBox内のscheme_typeフィールドは、トラックにおけるサンプルに複数のコード化画像が含まれ得ることを示す値に等しい。
i. 一例では、scheme_typeフィールドの値は「aest」に等しい。
d. SchemeTypeBoxのフラグフィールドのBit 0は０に等しく、（flags & 0x000001）の値が０に等しくなる。
e. 一例では、さらに、ＥＳＴに関連する情報を含むために、例えば、EsternalStreamInfoBoxという新しいボックスが指定される。新しいボックスには、次のフィールドが１つ以上含まれ得る。
i. ＥＳＴに関連付けられたメインストリームトラック（ＭＳＴ）のトラックＩＤを示すフィールド。
ii. ＥＳＴにおける任意のサンプル内のコード化画像の最大数を示すフィールド。
iii. ＥＳＴにおける各サンプルの最初のコード化画像がＩＲＡＰ画像であるか否かを示すフィールド。
iv. ＥＳＴにおける各サンプルに、サンプル内のコード化画像のデコーディングに必要な全てのパラメータセットが含まれているか否かを示すフィールド。
v. ＥＳＴ内の各サンプルに対して、ＥＤＲＡＰ指示ＳＥＩメッセージ内の対応するedrap_leading_pictures_decodable_flagが１に等しい場合に、関連付けられたＭＳＴ内の対応するＥＤＲＡＰ画像が制約を満たすか否かを示すフィールド。
5. 実施形態
（外１）
5.1 第１の実施形態
この実施形態は、項目1.e及びその全てのサブ項目を除く項目１及びその全てのサブ項目を対象とする。
8.3.3.4 関連する外部ストリームトラック参照
タイプ「aest」（「関連する外部ストリームトラック」を意味する）のトラック参照は、ＥＳＴを参照するＭＳＴに含まれ得る。
ＭＳＴにタイプ「aest」のトラック参照がある場合、以下が適用される。
－ ＭＳＴは、ＥＤＲＡＰ画像を含むサンプルを少なくとも１つ有するべきである。
－ ＥＤＲＡＰ画像を含むＭＳＴ内の各サンプルsampleAに対して、関連するＥＳＴ内にsampleAと同じデコード時間を持つサンプルsampleBが１つだけ存在するものとし、sampleBから開始して、関連するＥＳＴ内の多数の連続したサンプルには、sampleAに含まれるＥＤＲＡＰ画像からランダムアクセスするときに必要な全ての外部画像が排他的に含まれるものとする。
ＥＳＴ内の全てのサンプルは、同期サンプルとして識別されるものとする。ＥＳＴトラックヘッダーフラグでは、track_in_movieとtrack_in_previewの両方が０に設定されるものとする。
ＥＳＴごとに、次のように制限付きスキームが使用されるものとする。
1) サンプルエントリの４文字コードは、サンプルエントリコード「resv」である。
2) 通常のビデオサンプルエントリタイプは、RestrictedSchemeInfoBoxに含まれるOriginalFormatBox内に保存される。
3) RestrictedSchemeInfoBoxにあるSchemeTypeBoxのスキームタイプフィールドは「aest」に等しく、トラック内のサンプルに複数のコード化画像が含まれ得ることを示す。
4) SchemeTypeBoxのフラグフィールドのBit 0は０に等しく、（flags & 0x000001）の値が０に等しくなる。
1. 概要
この開示は、メディアファイルフォーマットに関する。具体的には、適切なサンプルエントリタイプを持つ外部ストリームトラック（ＥＳＴ）のシグナリングに関するものであって、ＥＳＴ内の１つのサンプルに複数のコード化画像を含めることが可能になる。ＥＳＴは、メインストリームトラック（ＭＳＴ）内の拡張従属ランダムアクセスポイント（ＥＤＲＡＰ）画像からのランダムアクセスに必要な外部画像を提供する。これらのアイデアは、ＩＳＯベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ）及びＩＳＯＢＭＦＦから派生したファイルフォーマットなど、任意のメディアファイルフォーマットに従ってメディアファイルに個別に、又は様々な組み合わせで適用され得る。
2. 背景
2.1 ビデオコーディング規格
ビデオコーディング規格は、主によく知られているITU-T及びISO/IEC規格の開発を通じて進化している。ITU-TはH.261とH.263を策定し、ISO/IECはMPEG-1とMPEG-4 Visualを策定し、この２つの組織は共同でH.262/MPEG-2 Video、H.264/MPEG-4 Advanced Video Coding(ＡＶＣ)、及びH.265/ＨＥＶＣ規格を策定した。H.262以降、ビデオコーディング規格は、時間予測及び変換コーディングが利用されるハイブリッドビデオコーディング構造に基づいている。ＨＥＶＣを超える将来のビデオコーディング技術を探求するために、２０１５年にＶＣＥＧとＭＰＥＧによって共同ビデオ探索チーム（Joint Video Exploration Team、ＪＶＥＴ）が設立された。それ以来、多くの新しい方法がＪＶＥＴに採用され、共同探索モデル（Joint Exploration Model、ＪＥＭ）と呼ばれる参照ソフトウェアに取り入れられている。ＪＶＥＴは、Versatile Video Coding（ＶＶＣ)プロジェクトが正式に開始されたときに、共同ビデオ専門家チーム（Joint Video Experts Team、ＪＶＥＴ）に改名された。ＶＶＣは、ＨＥＶＣと比較して５０％のビットレート削減を目標とし、２０２０年7月１日に終了したＪＶＥＴの第１９回会議で最終決定された新しいコーディング規格である。
多用途ビデオコーディング（Versatile Video Coding、ＶＶＣ）規格（ITU-T H.266 | ISO/IEC 23090-3）と関連する多用途補足拡張情報（ＶＳＥＩ）規格（ITU-T H.274 | ISO/IEC 23002-7）は、テレビ放送、ビデオ会議、ストレージメディアからの再生などの従来の用途だけでなく、アダプティブビットレートストリーミング、ビデオ領域の抽、複数のコード化ビデオビットストリームからのコンテンツの合成及びマージング、マルチビュービデオ、スケーラブルな階層化コーディング、ビューポート適応型３６０°イマーシブメディアなどの新しい高度な用途も含め、最大限に幅広いアプリケーションで使用されるように設計されている。
2.2 ファイルフォーマット規格
メディアストリーミングアプリケーションは、通常、ＩＰ、ＴＣＰ、及びＨＴＴＰトランスポートメソッドに基づいており、通常はＩＳＯベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ）などのファイルフォーマットに依存する。このようなストリーミングシステムの１つが、ＨＴＴＰ経由の動的アダプティブストリーミング（ＤＡＳＨ）である。ＩＳＯＢＭＦＦ及びＤＡＳＨでビデオフォーマットを使用する場合、ＡＶＣファイルフォーマット及びＨＥＶＣファイルフォーマットなどのビデオフォーマットに特有のファイルフォーマット仕様が、ＩＳＯＢＭＦＦトラック及びＤＡＳＨ表現とセグメントでのビデオコンテンツのカプセル化に必要になり得る。ビデオビットストリームに関する重要な情報、例えばプロファイル、階層、レベル、その他多くの情報は、コンテンツ選択の目的で、例えばストリーミングセッションの開始時の初期化及びストリーミングセッション中のストリーム適応の両方での適切なメディアセグメントの選択のために、ファイルフォーマットレベルのメタデータ及び／又はＤＡＳＨメディアプレゼンテーション記述（ＭＰＤ）として公開されるべきである場合がある。同様に、ＩＳＯＢＭＦＦでイメージフォーマットを使用する場合は、ＡＶＣイメージファイルフォーマット及びＨＥＶＣイメージファイルフォーマットなど、イメージフォーマットに特有のファイルフォーマット仕様が必要になり得る。
2.3 ランダムアクセスとＨＥＶＣ及びＶＶＣにおけるそのサポート
ランダムアクセスとは、デコード順でビットストリームの最初の画像ではない画像からビットストリームのアクセスとデコーディングを開始することを指す。ブロードキャスト／マルチキャスト及びマルチパーティビデオ会議でのチューニングとチャンネル切り替え、ローカル再生とストリーミングでのシーキング、及びストリーミングでのストリーム適応をサポートするには、ビットストリームに頻繁なランダムアクセスポイントを含める必要があり、これは通常、イントラコーディング画像であるが、インターコード化画像である場合もある（例：段階的なデコーディング更新の場合)。
ＨＥＶＣには、ＮＡＬユニットタイプを通じたＮＡＬユニットヘッダー内のイントラランダムアクセスポイント（ＩＲＡＰ）画像のシグナリングが含まれる。３種類のＩＲＡＰ画像、つまり、瞬時デコーダリフレッシュ（ＩＤＲ）、クリーンランダムアクセス（ＣＲＡ）、及び切れたリンクアクセス（ＢＬＡ）画像がサポートされている。ＩＤＲ画像は、現在のグループオブピクチャ（ＧＯＰ）より前の画像を参照しないように画像間予測構造を制約しており、従来はクローズドＧＯＰランダムアクセスポイントと呼ばれている。ＣＲＡ画像は、特定の画像が、ランダムアクセスの場合には全て破棄される現在のＧＯＰより前の画像を参照可能にすることでより制限的でない。ＣＲＡ画像は従来、オープンＧＯＰランダムアクセスポイントと呼ばれている。ＢＬＡ画像は通常、ストリーム切り替え中など、ＣＲＡ画像での２つのビットストリーム又はその一部のスプライシングから生じる。ＩＲＡＰ画像のより良いシステム使用を可能にするために、合計６つの異なるＮＡＬユニットが、ＩＲＡＰ画像の特性をシグナリングするために定義されており、これは、ＨＴＴＰ経由の動的アダプティブ ストリーミング（ＤＡＳＨ）でのランダムアクセスサポートに利用される、ＩＳＯベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ）で定義されているストリームアクセスポイントタイプとよりよくマッチさせるために使用され得る。
ＶＶＣは、３種類のＩＲＡＰ画像、２種類のＩＤＲ画像（１種類はＲＡＤＬ画像が関連付けられ、又はもう１種類はＲＡＤＬ画像が関連付けられていない)、及び１種類のＣＲＡ画像をサポートしている。これらは基本的にＨＥＶＣと同じである。ＨＥＶＣにおけるＢＬＡ画像タイプは、主に次の２つの理由によりＶＶＣには含まれていない。ｉ）ＢＬＡ画像の基本機能は、ＣＲＡ画像及びシーケンス終了ＮＡＬユニットによって実現でき、シーケンス終了ＮＡＬユニットの存在は、後続の画像がシングルレイヤービットストリームで新しいＣＶＳを開始することを示す。ｉｉ）ＶＶＣの開発中、ＮＡＬユニットヘッダーでＮＡＬユニットタイプフィールドに６ビットではなく５ビットを使用して示されているように、ＨＥＶＣよりも少ないＮＡＬユニットタイプを指定することが望まれる。
ＶＶＣとＨＥＶＣのランダムアクセスサポートにおけるもう１つの重要な違いは、ＶＶＣではより規範的な方式でＧＤＲがサポートされていることである。ＧＤＲでは、ビットストリームのデコーディングはインターコード化画像から開始でき、最初は画像領域全体を正しくデコードできる、いくつかの画像の後には画像領域全体が正しくなる。ＡＶＣとＨＥＶＣもＧＤＲをサポートしており、ＧＤＲランダムアクセスポイント及びリカバリポイントのシグナリングにリカバリポイントＳＥＩメッセージを使用している。ＶＶＣでは、ＧＤＲ画像を示すために新しいＮＡＬユニットタイプが指定され、リカバリポイントは画像ヘッダー構文構造でシグナリングされる。ＣＶＳとビットストリームはＧＤＲ画像から開始することが許可される。これは、ビットストリーム全体に、単一のイントラコード化画像がなく、インターコード化画像のみが含まれることが許可されることを意味する。このようにＧＤＲサポートを指定することの主な利点は、ＧＤＲに適合した行動を提供することである。ＧＤＲは、エンコーダが、画像全体のイントラコーディングとは対照的に、複数の画像にイントラコード化スライス又はブロックを分散させることでビットストリームのビットレートを平滑化するのを可能にし、これにより、エンドツーエンド遅延を大幅に削減可能になり、ワイヤレスディスプレイ、オンラインゲーム、ドローンベースのアプリケーションなどの超低遅延アプリケーションが普及するにつれて、これは以前よりも重要視されるようになった。
ＶＶＣにおける別のＧＤＲ関連特徴は、仮想境界シグナリングである。ＧＤＲ画像とそのリカバリポイント間の画像におけるリフレッシュされた領域（即ち、正しくデコードされた領域）とリフレッシュされていない領域との境界は、仮想境界としてシグナリングされ得、通知されると、境界を越えるループ内フィルタリングは適用されないため、境界又はその近くの一部のサンプルのデコーディングミスマッチは発生しない。これは、アプリケーションがＧＤＲプロセス中に正しくデコードされた領域を表示することを決定した場合に役立つ。
ＩＲＡＰ画像とＧＤＲ画像は、まとめてランダムアクセスポイント（ＲＡＰ）画像と呼ばれる。
2.4 拡張従属ランダムアクセスポイント（ＥＤＲＡＰ）ベースのビデオコーディング、ストレージ及びストリーミング
2.4.1 概念及び規格サポート
ＥＤＲＡＰベースのビデオコーディング、ストレージ及びストリーミングの概念を以下の図４～１１を参照して説明する。
図４及び図５は、ランダムアクセスポイント（ＲＡＰ）の既存の概念を示す図である。アプリケーション（例：アダプティブストリーミング）は、例えば、ＲＡＰ期間１秒又は２秒など、ランダムアクセスポイント（ＲＡＰ）の頻度を決定する。従来、ＲＡＰは、図４に示すように、ＩＲＡＰ画像のコーディングによって提供される。ＲＡＰ画像間の非キー画像についてのインター予測参照は示されておらず、出力順序は左から右であることに注意されたい。ＣＲＡ６からランダムアクセスする場合、デコーダは、図５に示すように、画像を受信し、正しくデコードする。
図６及び図７は、従属ランダムアクセスポイント（ＤＲＡＰ）の概念を示す図である。ＤＲＡＰアプローチは、図６に示すように、ＤＲＡＰ画像(及び後続の画像)がインター予測のために前のＩＲＡＰ画像を参照するのを許可することで向上されたコーディング効率を提供する。ＲＡＰ画像間の非キー画像についてのインター予測は示されておらず、出力順序は左から右であることに注意されたい。ＤＲＡＰ６からランダムアクセスする場合、デコーダは図７に示すように画像を受信し、正しくデコードする。
図８及び図９は、拡張従属ランダムアクセスポイント（ＥＤＲＡＰ）の概念を示す図である。ＥＤＲＡＰアプローチは、図８に示すように、ＥＤＲＡＰ画像（及び後続の画像）が以前のＲＡＰ画像（ＩＲＡＰ又はＥＤＲＡＰ)のいくつかを参照するのを許可することでもう少し柔軟性を提供する。ＲＡＰ画像間の非キー画像についてのインター予測は示されておらず、出力順序は左から右であることに注意されたい。ＥＤＲＡＰ６からランダムアクセスする場合、デコーダは図９に示すように画像を受信し、正しくデコードする。
図１０及び図１１は、ＥＤＲＡＰベースのビデオストリーミングを示す図である。ＥＤＲＡＰ６から始まるセグメントからランダムアクセス、又は該セグメントに切り替えると、デコーダは図１１に示すようにセグメントを受信してデコードする。
ＥＤＲＡＰベースのビデオコーディングは、ＶＳＥＩ規格の開発中の修正に含まれるＥＤＲＡＰ指示ＳＥＩメッセージによってサポートされ、ストレージ部分は、ＩＳＯＢＭＦＦ規格の開発中の修正に含まれるＥＤＲＡＰサンプルグループ及び関連する外部ストリームトラック参照によってサポートされ、ストリーミング部分は、ＤＡＳＨ規格の開発中の修正に含まれるメインストリーム表現（ＭＳＲ）記述子及び外部ストリーム表現（ＥＳＲ）記述子によってサポートされる。
2.4.2 ＥＤＲＡＰ指示ＳＥＩメッセージ
ＶＳＥＩ規格についての修正は開発中である。この修正の最新ドラフト仕様には、ＥＤＲＡＰ指示ＳＥＩメッセージの仕様が含まれている。
ＥＤＲＡＰ指示ＳＥＩメッセージの構文とセマンティクスは次のとおりである。
【表1】
ＥＤＲＡＰ指示ＳＥＩメッセージが存在する場合、このサブ条項で指定されている画像順序及び画像参照に関する制約が適用されることを示す。これらの制約により、デコーダは、同じＣＬＶＳ内にあり、かつedrap_ref_rap_id[ i ]構文要素によって識別されるデコード順のＩＲＡＰ又はＥＤＲＡＰ画像のリストで構成されるreferenceablePicturesのリストを除いて、同じレイヤー内の他の任意の画像をデコードする必要なく、同じレイヤーにあるＥＤＲＡＰ画像及びデコード順と出力順の両方でそれの後に続く画像を適切にデコードできる。
全て適用されるものとする、ＥＤＲＡＰ指示ＳＥＩメッセージの存在によって示される制約は、次のとおりである。
－ ＥＤＲＡＰ画像は、トレーリング画像である。
－ ＥＤＲＡＰ画像は、０に等しい時間的サブレイヤー識別子を有する。
－ ＥＤＲＡＰ画像は、referenceablePicturesを除き、参照画像リストのアクティブエントリにおける同じレイヤー内の画像を含まない。
－ 同じレイヤーにあり、かつデコード順と出力順の両方でＥＤＲＡＰ画像の後に続く任意の画像は、referenceablePicturesを除き、その参照画像リストのアクティブエントリに、同じレイヤーにあり、かつデコード順又は出力順でＥＤＲＡＰ画像に先行する画像を含まない。
－ リストreferenceablePictures内の任意の画像は、その参照画像リストのアクティブエントリに、同じレイヤーにあり、かつリストreferenceablePictures内の前の位置にある画像ではない画像を含まない。
注 － その結果、referenceablePictures内の最初の画像は、ＩＲＡＰ画像ではなくＥＤＲＡＰ画像であっても、その参照画像リストのアクティブエントリに同じレイヤーからの任意の画像を含まない。
edrap_rap_id_minus1プラス１は、ＥＤＲＡＰ画像のＲＡＰ画像識別子（RapPicIdとして表記）を指定する。
各ＩＲＡＰ又はＥＤＲＡＰ画像には、RapPicId値が関連付けられている。ＩＲＡＰ画像のRapPicId値は０に等しいと推論される。同じＩＲＡＰ画像に関連付けられている任意の２つのＥＤＲＡＰ画像についてのRapPicId値は異なるものとする。
edrap_leading_pictures_decodable_flagが１に等しい場合、次の制約の両方が適用されることを指定する。
－ 同じレイヤーにあり、かつデコード順でＥＤＲＡＰ画像の後に続く任意の画像は、出力順で、同じレイヤーにあり、かつデコード順でＥＤＲＡＰ画像に先行する画像の後に続くものとする。
－ 同じレイヤーにあり、かつデコード順でＥＤＲＡＰ画像の後に続き、出力順でＥＤＲＡＰ画像に先行する任意の画像は、その参照画像リストのアクティブエントリに、referenceablePicturesを除き、同じレイヤーにあり、かつデコード順でＥＤＲＡＰに先行する任意の画像を含まないものとする。
edrap_leading_pictures_decodable_flagが０に等しい場合、このような制約は課されない。
edrap_reserved_zero_12bitsは、この仕様のこのバージョンに準拠するビットストリームでは０に等しいものとする。edrap_reserved_zero_12bitsの他の値は、ITU-T | ISO/IECによる将来の使用のために予備されている。デコーダは、edrap_reserved_zero_12bitsの値を無視するものとする。
edrap_num_ref_rap_pics_minus1プラス１は、ＥＤＲＡＰ画像と同じＣＬＶＳ内にあり、かつＥＤＲＡＰ画像の参照画像リストのアクティブエントリに含まれ得るＩＲＡＰ又はＥＤＲＡＰ画像の数を示す。
edrap_ref_rap_id[ i ]は、ＥＤＲＡＰ画像の参照画像リストのアクティブエントリに含まれ得るi番目のＲＡＰ画像のRapPicIdを示す。i番目のＲＡＰ画像は、現在のＥＤＲＡＰ画像に関連付けられたＩＲＡＰ画像、又は現在のＥＤＲＡＰ画像と同じＩＲＡＰ画像に関連付けられたＥＤＲＡＰ画像のいずれかであるものとする。
2.4.3 ＥＤＲＡＰサンプルグループ及び関連する外部ストリームトラック参照
ＩＳＯＢＭＦＦ規格の修正が開発中である。この修正の最新ドラフト仕様には、ＥＤＲＡＰサンプルグループ及び関連する外部ストリームトラック参照の仕様が含まれている。
これら２つのＩＳＯＢＭＦＦ特徴の仕様は次のとおりである。
3.1 定義
外部基本ストリーム
外部画像を備えるアクセスユニットを含むエレメンタリーストリーム
外部画像
ＥＳＴにおける外部エレメンタリーストリームにある画像で、ＭＳＴにおける特定のＥＤＲＡＰ画像からランダムアクセスするときに、ＭＳＴにおけるエレメンタリーストリームのデコーディングにおいてインター予測参照に必要な画像
外部ストリームトラック（ＥＳＴ）
外部エレメンタリーストリームを含むトラック
メインストリームトラック（ＭＳＴ）ビデオエレメンタリーストリームを含むトラック
3.2 略語
ＥＤＲＡＰ 拡張従属ランダムアクセスポイント
ＥＳＴ 外部ストリームトラック
ＭＳＴ メインストリームトラック
8.3.3.4 関連する外部ストリームトラック参照
タイプ「aest」（「関連付けられた外部ストリームトラック」を意味する）のトラック参照が、ＥＳＴを参照するＭＳＴに含まれ得る。
ＭＳＴにタイプ「aest」のトラック参照がある場合、以下が適用される。
－ ＭＳＴには、ＥＤＲＡＰ画像を含む少なくとも１つのサンプルがあるものとする。
－ ＥＤＲＡＰ画像を含むＭＳＴにおける各サンプルsampleAに対して、sampleAと同じデコード時間を持つ関連ＥＳＴにおける１つのサンプルsampleBのみが存在するものとし、sampleBから開始して、関連付けられたＥＳＴにおける連続したサンプルには、sampleAに含まれるＥＤＲＡＰ画像からランダムアクセスするときに必要な全ての外部画像が排他的に含まれているものとする。
ＥＳＴ内の全てのサンプルは、同期（sync）サンプルとして識別されるものとする。ＥＳＴトラックヘッダーフラグでは、track_in_movieとtrack_in_previewの両方が０に設定されるものとする。
10.11 拡張ＤＲＡＰ（ＥＤＲＡＰ）サンプルグループ
10.11.1 定義
このサンプルグループは、サブ条項10.8で指定されているＤＲＡＰサンプルグループに似ているが、より柔軟なクロスＲＡＰ参照を可能にする。
ＥＤＲＡＰサンプルは、ＥＤＲＡＰサンプルに先行する最も近い初期サンプルと、ＥＤＲＡＰサンプルよりもデコード順序が早い１つ以上の他の識別されたＥＤＲＡＰサンプルが参照に利用可能な場合、その後デコード順と出力順の全てのサンプルが正しくデコードされ得るサンプルである。
初期サンプルは、同期サンプル又はＳＡＰサンプルグループによってそのようにマークされたＳＡＰタイプ１、２又は３のＳＡＰサンプルである。例えば、ファイル内の３２番目のサンプルがＩピクチャで構成される初期サンプルである場合、４８番目のサンプルはＰピクチャで構成され、ＥＤＲＡＰサンプルグループのメンバーとしてマークされ得、これにより、最初に３２番目のサンプルをデコードし（サンプル３３～４７は無視）、次に４８番目のサンプルからデコードを続けることで、４８番目のサンプルでランダムアクセスを実行できることを示す。
注：ＥＤＲＡＰサンプルは、タイプ１、２及び３のＳＡＰサンプルと組み合わせてのみ使用できる。これは、先行するＳＡＰサンプルと、ＥＤＲＡＰサンプルよりもデコード順序が早い０個以上の他の識別されたＥＤＲＡＰサンプルを、ＥＤＲＡＰサンプル及びデコード順と出力順でＥＤＲＡＰサンプルの後に続くサンプルと連結（concatenating）することにより、デコード可能なサンプルシーケンスを作成する機能を有効にするためである。
サンプルは、次の条件が満たされる場合にのみ、ＥＤＲＡＰサンプルグループのメンバーになることができる。
－ ＥＤＲＡＰサンプルは、最も近い先行する初期サンプルと、ＥＤＲＡＰサンプルよりもデコード順序が早い１つ以上の他の識別されたＥＤＲＡＰサンプルのみを参照する。
－ ＥＤＲＡＰサンプルと、デコード順及び出力順でＥＤＲＡＰサンプルに続く全てのサンプルは、Syncサンプル又はＳＡＰサンプルグループとしてマークされたタイプ１、２又は３の最も近い先行ＳＡＰサンプルをデコードした後、及びデコード順でＥＤＲＡＰサンプルより前の０個以上の他の識別されたＥＤＲＡＰサンプルをデコードした後に、ＥＤＲＡＰサンプルでデコードを開始すると、正しくデコードされ得る。
10.11.2 構文
【数1】
edrap_typeは非負整数である。edrap_typeが１から３の範囲にある場合、最も近い先行ＳＡＰ又は他のＥＤＲＡＰサンプルに依存していなかったら、ＥＤＲＡＰサンプルが対応したであろうSAP_type（付録Iで指定）を示す。その他のタイプの値は予備されている。
num_ref_edrap_picsは、ＥＤＲＡＰサンプルよりもデコード順序が早く、ＥＤＲＡＰサンプルからデコードを開始するときに、ＥＤＲＡＰサンプル及びデコード順と出力順の両方でＥＤＲＡＰサンプルの後に続く全てのサンプルを正しくデコードできるようにするための参照に必要である、他のＥＤＲＡＰサンプルの数を示す。
reservedは０に等しいものとする。このサブ条項のセマンティクスは、予備済みのものが０に等しいサンプルグループ記述エントリにのみ適用される。パーサーは、このサンプルグループを解析するときに、予備済みのものが０より大きいサンプルグループ記述エントリを許可し、無視するものとする。
ref_edrap_idx_delta[i]は、このＥＤＲＡＰサンプルのサンプルグループインデックス（即ち、デコード順でこのサンプルグループ内の全てのサンプルのリストへのインデックス）と、ＥＤＲＡＰサンプルよりもデコード順が早く、このＥＤＲＡＰサンプルからデコードを開始するときに、ＥＤＲＡＰサンプル及びデコード順と出力順の両方でＥＤＲＡＰサンプルの後に続く全てのサンプルを正しくデコードできるようにするための参照に必要である、i番目のRAPサンプルのサンプルグループインデックスとの差を示す。
ＩＳＯＢＭＦＦでのサンプルエントリタイプ変換
ＩＳＯＢＭＦＦには、保護されるコンテンツ又はレンダリング前に特別なポストデコーダ処理要件を必要とするタイプのコンテンツのサンプルエントリの変換を可能にする特徴が含まれている。このようなポストデコーダ処理要件の例には、立体視ビデオサポートのフレームパッキング及び全方向又は３６０度ビデオサポートについての投影が含まれる。
ファイル作成者がプレーヤー又はレンダラーで特定のアクションを必要とする状況に対処するために、ＩＳＯＢＭＦＦには、プレーヤーが単にファイルを検査するだけでビットストリームのレンダリングの要件を見つけることを可能にし、さらなる処理が必要なファイルをレガシープレイヤー（legacy players）がデコードしてレンダリングするのを阻止するメカニズムが含まれている。このメカニズムは、任意のタイプのビデオコーデックに適用される。
このメカニズムは、サンプルエントリが汎用サンプルエントリ「encv」、「enca」などの背後に隠され、暗号化又はカプセル化されたメディアを示すコンテンツ保護変換に似ている。制限されたビデオの類似メカニズムでは、汎用サンプルエントリ「resv」による変換を使用する。この方法は、コンテンツを正しく表示するプレーヤーのみがデコードすべきである場合に適用され得る。
制限されたサンプルエントリ変換と関連するシグナリングは、次のように指定される。
2.5.1 制限されたサンプルエントリ変換
制限されたサンプルエントリは、次の変換手順が適用されたサンプルエントリとして定義される。
1) サンプルエントリの４文字コードが、制限されたビデオを意味するサンプルエントリコード「resv」に置き換えられる。
2) サンプル記述にRestrictedSchemeInfoBoxが追加され、他の全てのボックスは変更されない。
3) オリジナルサンプルエントリタイプは、RestrictedSchemeInfoBoxに含まれるOriginalFormatBox内に保存される。
RestrictedSchemeInfoBoxは、識別子「sinf」の代わりに「rinf」を使用する点を除いて、ProtectionSchemeInfoBoxとまったく同じ形式でフォーマットされる（下記参照）。
オリジナルサンプルエントリタイプは、（暗号化されたメディアについてのProtectionSchemeInfoBoxと同じ方式で）RestrictedSchemeInfoBoxに位置するOriginalFormatBoxに含まれている。
制限の正確な性質はSchemeTypeBoxで定義され、そのスキームに必要なデータは、また 、保護情報と類似的にSchemeInformationBoxに保存される。
制限及び保護は同時に適用され得る。変換の順序は、サンプルエントリの４文字コードに従う。例えば、サンプルエントリタイプが「resv」の場合、上記の変換を元に戻すと、サンプルエントリタイプが「encv」になり、メディアが保護されていることを示す。
ファイル作成者が、レガシープレイヤーによるファイルの再生を妨げずにアドバイス情報のみを提供したい場合、４文字コードを変換せずに、RestrictedSchemeInfoBoxがサンプルエントリ内に配置され得る。この場合、OriginalFormatBoxを含める必要はない。
2.5.2 制限付きスキーム情報ボックス
2.5.2.1 定義
ボックスタイプ： 「rinf」
コンテナー： 制限されたサンプルエントリ又はサンプルエントリ
必須: 制限されたサンプルエントリの場合ははい、それ以外の場合はいいえ
数量: ０又は１
RestrictedSchemeInfoBoxには、適用される制限スキームとそのパラメータの両方を理解するために必要な全ての情報が含まれている。また、メディアのオリジナル（変換されていない）サンプルエントリタイプも記録される。RestrictedSchemeInfoBoxはコンテナボックスである。制限されたストリームを示すコード（即ち、「resv」）を使用するサンプルエントリでは必須である。
制限されたサンプルエントリで使用する場合、このボックスには、オリジナルサンプルエントリタイプを記録するOriginalFormatBoxとSchemeTypeBoxが含まれるものとする。制限スキームによっては、SchemeInformationBoxが必要になり得る。
2.5.2.2 構文
【数2】
2.5.3.1 定義
ボックスタイプ： 「schm」
コンテナー： ProtectionSchemeInfoBox、RestrictedSchemeInfoBox、又はSRTPProcessBox
必須: いいえ
数量: 「sinf」では保護構造に応じて０又は１。「rinf」及び「srpp」ででは正確に１。
SchemeTypeBoxは、保護又は制限スキームを識別する。
2.5.3.2 構文
【数3】
scheme_typeは、保護又は制限スキームを定義するコードで、通常は４文字コードとして表される。
scheme_versionは、スキームのバージョンである（コンテンツの作成に使用される）。
scheme_URIは、システムにスキームがインストールされていない場合にユーザをＷｅｂページに案内するオプションを許す絶対ＵＲＩである。
2.5.4 スキーム情報ボックス
2.5.4.1 定義
ボックスタイプ： 「schi」
コンテナー： ProtectionSchemeInfoBox、RestrictedSchemeInfoBox、又はSRTPProcessBox
必須: いいえ
数量: ０又は１
SchemeInformationBoxは、使用されているスキームによってのみ解釈されるコンテナボックスである。暗号化又は制限システムに必要な任意の情報はここに保存される。このボックスのコンテンツは、SchemeTypeBoxで宣言されたスキームによってタイプ及びフォーマットが定義される一連のボックスである。
2.5.4.2 構文
【数4】
2.5.5.1 定義
ボックスタイプ： 「frma」
コンテナー： ProtectionSchemeInfoBox、RestrictedSchemeInfoBox、又はCompleteTrackInfoBox
必須: 保護されたサンプルエントリ、制限されたサンプルエントリ、又は不完全なトラックについてのサンプルエントリで使用される場合、はい。
数量: 正確に１。
OriginalFormatBoxには、変換されていないオリジナルサンプル記述の４文字コードが含まれる。
2.5.5.2 構文
【数5】
data_フォーマットは、変換されていないオリジナルサンプルエントリの４文字コードである（例:ストリームに保護又は制限されたMPEG-4ビジュアルマテリアルが含まれている場合は、「mp4v」）。
3. 問題点
ＥＤＲＡＰベースのビデオコーディング、ストレージ、ストリーミングのストレージ部分についての既存の設計に関係する問題が１つある。外部ストリームトラック（ＥＳＴ）のサンプルには、複数のコード化画像があり得る。したがって、通常のビデオサンプルエントリタイプ（例：ＶＣＣサンプルエントリタイプ又はＨＥＶＣサンプルエントリタイプ）をＥＳＴに使用すると、各サンプルにコード化画像が１つだけ含まれるものとするという通常の要件に違反することになる。
4. 詳細なソリューション
上記の問題を解決するために、以下に要約するような方法が開示される。これらのソリューションは、一般的な概念を説明するための例として考慮されるべきであり、狭義に解釈されるべきではない。さらに、これらのソリューションは、個別に適用されるか、又は任意の方式で組み合わせて適用され得る。
1) 一例では、通常のビデオサンプルエントリタイプを隠すために、新しい制限付きスキームタイプ（例：「aest」）を使用するサンプルエントリタイプ変換。次の１つ以上が適用される。
a. サンプルエントリの４文字コードは、サンプルエントリコード「resv」である。
b. 通常のビデオサンプルエントリタイプは、RestrictedSchemeInfoBoxに含まれるOriginalFormatBox内に保存される。
c. RestrictedSchemeInfoBoxにあるSchemeTypeBox内のscheme_typeフィールドは、トラックにおけるサンプルに複数のコード化画像が含まれ得ることを示す値に等しい。
i. 一例では、scheme_typeフィールドの値は「aest」に等しい。
d. SchemeTypeBoxのフラグフィールドのBit 0は０に等しく、（flags & 0x000001）の値が０に等しくなる。
e. 一例では、さらに、ＥＳＴに関連する情報を含むために、例えば、EsternalStreamInfoBoxという新しいボックスが指定される。新しいボックスには、次のフィールドが１つ以上含まれ得る。
i. ＥＳＴに関連付けられたメインストリームトラック（ＭＳＴ）のトラックＩＤを示すフィールド。
ii. ＥＳＴにおける任意のサンプル内のコード化画像の最大数を示すフィールド。
iii. ＥＳＴにおける各サンプルの最初のコード化画像がＩＲＡＰ画像であるか否かを示すフィールド。
iv. ＥＳＴにおける各サンプルに、サンプル内のコード化画像のデコーディングに必要な全てのパラメータセットが含まれているか否かを示すフィールド。
v. ＥＳＴ内の各サンプルに対して、ＥＤＲＡＰ指示ＳＥＩメッセージ内の対応するedrap_leading_pictures_decodable_flagが１に等しい場合に、関連付けられたＭＳＴ内の対応するＥＤＲＡＰ画像が制約を満たすか否かを示すフィールド。
5. 実施形態
（外１）
この実施形態は、項目1.e及びその全てのサブ項目を除く項目１及びその全てのサブ項目を対象とする。
8.3.3.4 関連する外部ストリームトラック参照
タイプ「aest」（「関連する外部ストリームトラック」を意味する）のトラック参照は、ＥＳＴを参照するＭＳＴに含まれ得る。
ＭＳＴにタイプ「aest」のトラック参照がある場合、以下が適用される。
－ ＭＳＴは、ＥＤＲＡＰ画像を含むサンプルを少なくとも１つ有するべきである。
－ ＥＤＲＡＰ画像を含むＭＳＴ内の各サンプルsampleAに対して、関連するＥＳＴ内にsampleAと同じデコード時間を持つサンプルsampleBが１つだけ存在するものとし、sampleBから開始して、関連するＥＳＴ内の多数の連続したサンプルには、sampleAに含まれるＥＤＲＡＰ画像からランダムアクセスするときに必要な全ての外部画像が排他的に含まれるものとする。
ＥＳＴ内の全てのサンプルは、同期サンプルとして識別されるものとする。ＥＳＴトラックヘッダーフラグでは、track_in_movieとtrack_in_previewの両方が０に設定されるものとする。
ＥＳＴごとに、次のように制限付きスキームが使用されるものとする。
1) サンプルエントリの４文字コードは、サンプルエントリコード「resv」である。
2) 通常のビデオサンプルエントリタイプは、RestrictedSchemeInfoBoxに含まれるOriginalFormatBox内に保存される。
3) RestrictedSchemeInfoBoxにあるSchemeTypeBoxのスキームタイプフィールドは「aest」に等しく、トラック内のサンプルに複数のコード化画像が含まれ得ることを示す。
4) SchemeTypeBoxのフラグフィールドのBit 0は０に等しく、（flags & 0x000001）の値が０に等しくなる。
【0072】
メディアファイル内の外部ストリームトラックのシグナリングに関連する本開示の実施形態のさらなる詳細を以下で説明する。本開示の実施形態は、一般的な概念を説明するための例として考えるべきであり、狭義に解釈されるべきではない。さらに、これらの実施形態は、個別にか、又は任意の方式で組み合わせて適用され得る。
【0073】
本明細書で使用されるように、「サンプル」という用語は、単一の時間に関連付けられた全てのデータを指し得る。「サンプルエントリ」という用語は、トラックにおけるいくつかのサンプルのフォーマットを定義及び記述する構造を指し得る。「トラック」という用語は、関連するサンプルのタイミングシーケンスを指し得る。「ボックス」という用語は、一意のタイプ識別子及び長さによって定義されるオブジェクト指向のビルディングブロックを指し得る。
【0074】
図１２は、本開示のいくつかの実施形態によるビデオ処理の方法１２００のフローチャートを示す。方法１２００は、クライアント又はサーバで具現され得る。ここで使用される「クライアント」という用語は、コンピュータネットワークのクライアントサーバモデルの一部としてサーバによって提供されるサービスにアクセスするコンピューターハードウェア又はソフトウェアを指し得る。例として、クライアントはスマートフォン又はタブレットである。ここで使用される「サーバ」という用語は、コンピューティングの能力があるデバイスを指し得、その場合、クライアントはネットワークを通ってサービスにアクセスする。サーバは、物理的なコンピューティングデバイス又は仮想的なコンピューティングデバイスであり得る。
【0075】
図１２に示すように、１２０２では、ビデオのビットストリームと前記ビデオのメディアファイルとの間の転換が実行される。メディアファイルは、ファイルフォーマット（例：国際標準化機構（ＩＳＯ）ベースのメディアファイルフォーマット）のコンテキストでメディアコンテンツの有界又は無界のプレゼンテーションを確立するデータの収集である。いくつかの実施形態では、転換は、メディアファイルを生成し、ビットストリームをメディアファイルに記憶することを含み得る。追加的に又は代替的に、転換は、メディアファイルを解析してビットストリームを再構築することを含み得る。
【0076】
いくつかの実施形態では、メディアファイルは、外部ストリームトラックを含む。例えば、ＥＤＲＡＰベースのビデオ処理のコンテキストでは、外部ストリームトラックは対応するメインストリームトラックによって参照され得る。外部ストリームトラックはサンプルのセットを含む。サンプルのセットについてのサンプルエントリのサンプルエントリタイプは、制限付きスキームに基づいてカプセル化される。限定ではなく例として、制限付きスキームを使用したサンプルエントリ変換を適用してサンプルエントリタイプを非表示にし得る。サンプルエントリタイプは、サンプルエントリのオリジナルサンプルエントリタイプであり得る。サンプルエントリタイプは、サンプルエントリの現在のサンプルエントリタイプなど、他の任意のサンプルエントリタイプであり得ることを理解すべきである。本開示の範囲は、この点に限定されない。
【0077】
その上、前記サンプルエントリは、前記制限付きスキームに関連付けられた指示を含み、前記指示の値は、前記サンプルのセット内のサンプルが前記外部ストリームトラックの複数のコード化画像を含むことが許可されることを示す。限定ではなく例として、前記サンプルエントリは、制限付きスキームに関する情報を含む第１のデータ構造（例：制限付きスキーム情報ボックス、RestrictedSchemeInfoBoxとも表記）を含み得る。前記第１のデータ構造は、前記制限付きスキームを識別する第２のデータ構造（例：スキームタイプボックス、SchemeTypeBoxとも表記）を含み得る。
【0078】
さらに、前記指示は、第２のデータ構造内の第１のフィールド（例：スキームタイプフィールド、scheme_type fieldとも表記）を含み得る。一例では、第１のフィールドの値は、「aest」などの所定のコードに等しくてよい。トラックに対して、所定の値に等しいスキームタイプフィールドを持つ制限付きスキームが使用されている場合、サンプルエントリに関連付けられたサンプルには、オリジナルトラックの複数のサンプルが含まれ得る。所定のコードは、例えば「spkt」など、他の任意の適切なコードであり得ることを理解すべきてある。また、上記の解説及び／又は例は、説明の目的でのみ記載されていることを理解すべきである。本開示の範囲は、この点に限定されない。
【0079】
上記を考慮して、新しい制限付きスキームが、外部ストリームトラックにおけるサンプルに複数のコード化画像を含めることが許されることを示すために採用される。従来のソリューションと比較して、提案された方法は、ＥＤＲＡＰベースの技術をより効率的にサポートできるという利点がある。
【0080】
いくつかの実施形態では、制限付きスキームの統一資源識別子（ＵＲＩ）がメディアファイルに存在しなくてよい。例えば、サンプルエントリは、制限付きスキームに関する情報を含む第１のデータ構造（例：制限付きスキーム情報ボックス）を含み得、第１のデータ構造は、制限付きスキームを識別する第２のデータ構造（例：スキームタイプボックス）を含み得る。第２のデータ構造内のフラグフィールドの最下位ビット（即ち、Bit 0）の値は０に等しくてよい。
【0081】
いくつかの実施形態では、サンプルエントリタイプは、「resv」などの所定のサンプルエントリコードでカプセル化され得る。追加的に、前記サンプルエントリは、制限付きスキームに関する情報を含む第１のデータ構造（例：制限付きスキーム情報ボックス）を含み得る。前記第１のデータ構造は、前記サンプルエントリタイプを記憶する第３のデータ構造（例：オリジナルフォーマットボックス、OriginalFormatBoxとも表記）を含み得る。
【0082】
いくつかの追加的又は代替的の実施形態では、メディアファイルは、外部ストリームトラックに関連付けられた情報を含む第４のデータ構造（例：外部ストリーム情報ボックス、EsternalStreamInfoBoxとも表記）を含み得る。限定ではなく例として、第４のデータ構造は、（１）前記外部ストリームトラックに関連付けられたメインストリームトラックのトラックアイデンティティ（ＩＤ）を示すフィールド、（２）前記外部ストリームトラックにおけるサンプル内のコード化画像の最大許容数を示すフィールド、（３）前記外部ストリームトラックにおける各サンプル内の最初のコード化画像がイントラランダムアクセスポイント（ＩＲＡＰ）画像であり得るか否かを示すフィールドであって、前記最初のコード化画像がそれぞれのサンプル内の最初の位置にある、フィールド、（４）前記外部ストリームトラックにおける各サンプルがそれぞれのサンプル内のコード化画像のデコーディングに必要な全てのパラメータセットを含むか否かを示すフィールド、又は、（５）前記外部ストリームトラックについて、デコーディングプロセスがＥＤＲＡＰ画像から開始されるときに、前記外部ストリームトラックに関連付けられたメインストリームトラックにおける対応するＥＤＲＡＰ画像の先頭画像がデコード可能か否かを示すフィールドとのうちの少なくとも１つを含み得る。
【0083】
いくつかの実施形態では、以下の２つの制約が満たされる場合、外部ストリームトラックに関連付けられたメインストリームトラックにおける対応するＥＤＲＡＰ画像の先頭画像は、デコーディングプロセスがＥＤＲＡＰ画像から開始されるときにデコード可能である。（１）同じレイヤーにあり、かつデコード順でＥＤＲＡＰ画像の後に続く任意の画像は、出力順で、同じレイヤーにあり、かつデコード順でＥＤＲＡＰ画像に先行する画像の後に続くものとする。（２）同じレイヤーにあり、かつデコード順でＥＤＲＡＰ画像の後に続き、出力順でＥＤＲＡＰ画像に先行する任意の画像は、その参照画像リストのアクティブエントリに、referenceablePicturesを除き、同じレイヤーにあり、デコード順でＥＤＲＡＰ画像に先行する任意の画像を含まないものとする。
【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】
図１３に示すように、コンピューティングデバイス１３００は、汎用コンピューティングデバイス１３００を含む。コンピューティングデバイス１３００は、少なくとも１つ又は複数のプロセッサ又は処理ユニット１３１０と、メモリ１３２０と、記憶ユニット１３３０と、１つ又は複数の通信ユニット１３４０と、１つ又は複数の入力デバイス１３５０と、１つ又は複数の出力デバイス１３６０とを含み得る。
【0115】
いくつかの実施形態では、コンピューティングデバイス１３００は、コンピューティング能力を有する任意のユーザ端末又はサーバ端末として具現され得る。前記サーバ端末は、サービスプロバイダが提供するサーバや大規模コンピューティングデバイスなどであり得る。前記ユーザ端末は、例えば、携帯電話、ステーション、ユニット、デバイス、マルチメディアコンピュータ、マルチメディアタブレット、インターネットノード、コミュニケータ、デスクトップコンピュータ、ラップトップコンピュータ、ノートブックコンピュータ、ネットブックコンピュータ、タブレットコンピュータ、パーソナルコミュニケーションシステム(ＰＣＳ)デバイス、パーソナルナビゲーションデバイス、携帯情報端末(ＰＤＡ)、オーディオ/ビデオプレーヤー、デジタルカメラ/ビデオカメラ、測位デバイス、テレビ受信機、ラジオ放送受信機、電子ブックデバイス、ゲームデバイス、又はそれらの任意の組み合わせ（これらのデバイスのアクセサリ及び周辺機器、又はそれらの任意の組み合わせを含む）を含む、任意のタイプの移動端末、固定端末、又は携帯端末であり得る。コンピューティングデバイス１３００は、ユーザに対する任意のタイプのインターフェース（「ウェアラブル」回路など）をサポートできることが考えられる。
【0116】
処理ユニット１３１０は、物理又は仮想プロセッサであり得、メモリ１３２０に記憶されたプログラムに基づいて様々なプロセスを具現することができる。マルチプロセッサシステムでは、コンピューティングデバイス１３００の並列処理能力を向上させるために、複数の処理ユニットがコンピュータ実行可能命令を並列に実行する。処理ユニット１３１０は、中央処理ユニット（ＣＰＵ）、マイクロプロセッサ、コントローラ又はマイクロコントローラと呼ばれても良い。
【0117】
コンピューティングデバイス１３００は、通常、様々なコンピュータ記憶媒体を含む。このような媒体は、揮発性及び不揮発性媒体、又は取り外し可能及び取り外し不可能な媒体を含むがこれらに限定されない、コンピューティングデバイス１３００によってアクセス可能な任意の媒体であり得る。メモリ１３２０は、揮発性メモリ（例えば、レジスタ、キャッシュ、ランダムアクセスメモリ（ＲＡＭ））、不揮発性メモリ（例えば、読み取り専用メモリ（ＲＯＭ）、電気的に消去可能なプログラム可能な読み取り専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリ）、又はそれらの任意の組み合わせであり得る。記憶ユニット１３３０は、任意の取り外し可能又は取り外し不可能な媒体であり得、情報及び／又はデータを記憶するために使用でき、コンピューティングデバイス１３００でアクセスできる、メモリ、フラッシュメモリドライブ、磁気ディスク又は別の他の媒体などの機械読み取り可能な媒体を含み得る。
【0118】
コンピューティングデバイス１３００は、追加の取り外し可能／取り外し不可能、揮発性／不揮発性メモリ媒体をさらに含み得る。なお、図１３には示していないが、着脱可能な不揮発性磁気ディスクの読み書きを行う磁気ディスクドライブや、着脱可能な不揮発性光ディスクの読み書きを行う光ディスクドライブを提供することが可能である。このような場合、各ドライブは、１つ又は複数のデータ媒体インターフェースを介してバス(図示せず)に接続され得る。
【0119】
通信ユニット１３４０は、通信媒体を介してさらなるコンピューティングデバイスと通信する。その上、コンピューティングデバイス１３００内のコンポーネントの機能は、通信接続を介して通信できる単一のコンピューティングクラスタ又は複数のコンピューティングマシンによって具現され得る。したがって、コンピューティングデバイス１３００は、１つ又は複数の他のサーバ、ネットワーク化されたパーソナルコンピュータ（ＰＣ）、又はさらなる一般的なネットワークノードとの論理接続を使用して、ネットワーク化された環境で動作することができる。
【0120】
入力デバイス１３５０は、マウス、キーボード、トラッキングボール、音声入力デバイスなどの様々な入力デバイスのうちの１つ又は複数であり得る。出力デバイス１３６０は、ディスプレイ、ラウドスピーカ、プリンタなどの様々な出力デバイスのうちの１つ又は複数であり得る。通信ユニット１３４０によって、コンピューティングデバイス１３００は、記憶デバイス及び表示デバイスなどの１つ又は複数の外部デバイス（図示せず）とさらに通信することができ、１つ又は複数のデバイスにより、ユーザがコンピューティングデバイス１３００と対話可能にするか、又は、必要に応じて、任意のデバイス（ネットワークカード、モデムなど）により、コンピューティングデバイス１３００が１つ又は複数の他のコンピューティングデバイスと通信可能にする。このような通信は、入力／出力(Ｉ／Ｏ)インターフェース(図示せず)を介して実行され得る。
【0121】
いくつかの実施形態では、単一のデバイスに統合される代わりに、コンピューティングデバイス１３００のいくつかの又は全てのコンポーネントがクラウドコンピューティングアーキテクチャに配置され得る。クラウドコンピューティングアーキテクチャでは、コンポーネントは遠隔的に提供され、連携して本開示で説明される機能を実施し得る。いくつかの実施形態では、クラウドコンピューティングは、コンピューティング、ソフトウェア、データアクセス及びストレージサービスを提供し、これらのサービスを提供するシステム又はハードウェアの物理的な位置又は構成をエンドユーザが認識する必要はない。様々な実施形態において、クラウドコンピューティングは、適切なプロトコルを使用して広域ネットワーク（インターネットなど）を介してサービスを提供する。例えば、クラウドコンピューティングプロバイダーは、Ｗｅｂブラウザ又はその他のコンピューティングコンポーネントを通じてアクセスできる広域ネットワーク経由でアプリケーションを提供する。クラウドコンピューティングアーキテクチャのソフトウェア又はコンポーネント及び対応するデータは、遠隔地にあるサーバに保存され得る。クラウドコンピューティング環境におけるコンピューティングリソースは、リモートデータセンターの場所に併合又は分散され得る。クラウドコンピューティングインフラストラクチャは、ユーザにとって単一のアクセスポイントとして動作するが、共有データセンターを通じてサービスを提供し得る。したがって、クラウドコンピューティングアーキテクチャを使用して、本明細書で説明されるコンポーネント及び機能を遠隔地にあるサービスプロバイダから提供し得る。代替的に、それらは従来のサーバから提供されるか、又はクライアントデバイスに直接又はその他の方法でインストールされ得る。
【0122】
コンピューティングデバイス１３００は、本開示の実施形態においてビデオエンコーディング／デコーディングを具現するために使用され得る。メモリ１３２０は、１つ又は複数のプログラム命令を有する１つ又は複数のビデオ処理モジュール１３２５を含み得る。これらのモジュールは、本明細書で説明される様々な実施形態の機能を実行するように、処理ユニット１３１０によってアクセス可能かつ実行可能である。
【0123】
ビデオエンコーディングを実行する例示的な実施形態では、入力デバイス１３５０は、エンコードされるビデオデータを入力１３７０として受信し得る。ビデオデータは、例えば、ビデオ処理モジュール１３２５によって処理されて、エンコードされたビットストリームを生成し得る。エンコードされたビットストリームは、出力デバイス１３６０を介して出力１３８０として提供され得る。
【0124】
ビデオデコーディングを実行する例示的な実施形態では、入力デバイス１３５０は、エンコードされたビットストリームを入力１３７０として受信し得る。エンコードされたビットストリームは、例えば、ビデオ処理モジュール１３２５によって処理されて、デコードされたビデオデータを生成し得る。デコードされたビデオデータは、出力デバイス１３６０を介して出力１３８０として提供され得る。
【0125】
本開示は、その好ましい実施形態を参照して特に図示及び説明されたが、添付の特許請求の範囲によって定義される本出願の精神及び範囲から逸脱することなく、形態及び詳細における様々な変更を行うことができることが当業者には理解されるであろう。このような変形は、本出願の範囲に含まれるものとする。したがって、本出願の実施形態に関する前述の説明は限定することを意図したものではない。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【手続補正書】
【提出日】2024-09-11
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
ビデオ処理方法であって、ビデオのビットストリームと前記ビデオのメディアファイルとの間の転換を実行するステップを含み、
前記メディアファイルは、サンプルのセットを含む外部ストリームトラックを含み、前記サンプルのセットについてのサンプルエントリのサンプルエントリタイプは、制限付きスキームに基づいてカプセル化され、前記サンプルエントリは、前記制限付きスキームに関連付けられた指示を含み、前記指示の値は、前記サンプルのセット内のサンプルが前記外部ストリームトラックの複数のコード化画像を含むことが許可されることを示す、方法。
【請求項2】
前記サンプルエントリタイプは、オリジナルサンプルエントリタイプである、請求項１に記載の方法。
【請求項3】
前記サンプルエントリは、前記制限付きスキームに関する情報を含む第１のデータ構造を含み、前記第１のデータ構造は、前記制限付きスキームを識別する第２のデータ構造を含み、前記指示は、前記第２のデータ構造内の第１のフィールドを含む、請求項１に記載の方法。
【請求項4】
前記第１のデータ構造は、制限付きスキーム情報ボックスであり、前記第２のデータ構造は、スキームタイプボックスであり、前記第１のフィールドは、スキームタイプフィールドである、請求項３に記載の方法。
【請求項5】
前記第１のフィールドの値は所定のコードに等しい、請求項３に記載の方法。
【請求項6】
前記制限付きスキームの統一資源識別子（ＵＲＩ）は、前記メディアファイルに存在しない、請求項１に記載の方法。
【請求項7】
前記サンプルエントリは、前記制限付きスキームに関する情報を含む第１のデータ構造を含み、前記第１のデータ構造は、前記制限付きスキームを識別する第２のデータ構造を含み、前記第２のデータ構造内のフラグフィールドの最下位ビットの値は０に等しい、請求項１に記載の方法。
【請求項8】
前記第１のデータ構造は、制限付きスキーム情報ボックスであり、前記第２のデータ構造は、スキームタイプボックスである、請求項７に記載の方法。
【請求項9】
前記サンプルエントリタイプは、所定のサンプルエントリコードでカプセル化される、請求項１に記載の方法。
【請求項10】
前記サンプルエントリは、前記制限付きスキームに関する情報を含む第１のデータ構造を含み、前記第１のデータ構造は、前記サンプルエントリタイプを記憶する第３のデータ構造を含む、請求項１に記載の方法。
【請求項11】
前記メディアファイルは、前記外部ストリームトラックに関連付けられた情報を含む第４のデータ構造を含む、請求項１に記載の方法。
【請求項12】
前記メディアファイルは、国際標準化機構（ＩＳＯ）ベースのメディアファイルフォーマットである、請求項１に記載の方法。
【請求項13】
前記転換は、前記メディアファイルを生成し、前記ビットストリームを前記メディアファイルに記憶することを含む、請求項１に記載の方法。
【請求項14】
前記転換は、前記メディアファイルを解析して前記ビットストリームを再構築することを含む、請求項１に記載の方法。
【請求項15】
プロセッサと命令が記録された非一時的メモリとを含む、ビデオデータを処理する装置であって、前記命令は前記プロセッサによって実行されると、前記プロセッサに請求項１から１４のいずれか一項に記載の方法を実行させる、装置。
【請求項16】
プロセッサに請求項１から１４のいずれか一項に記載の方法を実行させる命令を記憶する非一時的なコンピュータ読み取り可能な記憶媒体。
【請求項17】
ビデオのメディアファイルを記憶する方法であって、前記ビデオのビットストリームと前記メディアファイルとの間の転換を実行するステップと、
前記メディアファイルを非一時的なコンピュータ読み取り可能な記録媒体に記憶するステップと、を含み、
前記メディアファイルは、サンプルのセットを含む外部ストリームトラックを含み、前記サンプルのセットについてのサンプルエントリのサンプルエントリタイプは、制限付きスキームに基づいてカプセル化され、前記サンプルエントリは、前記制限付きスキームに関連付けられた指示を含み、前記指示の値は、前記サンプルのセット内のサンプルが前記外部ストリームトラックの複数のコード化画像を含むことが許可されることを示す、方法。
【国際調査報告】