以下は、ビューポート対応ストリーミングのための適切な装置および可能なメカニズムをさらに詳細に説明する。この点に関して、図1および図2を最初に参照し、ここで、図1は、本発明の1つの実施形態によるコーデックを組み込むことができる、例示的な装置または電子デバイス50の概略ブロック図として、実例の実施形態によるビデオコーディングシステムのブロック図を示す。図2は、実例の実施形態による装置のレイアウトを示す。図1および図2の要素を次に説明する。
電子デバイス50は、例えば、ワイヤレス通信システムのモバイル端末またはユーザ機器であってもよい。それでも、本発明の実施形態は、ビデオイメージをエンコードおよびデコードすること、またはエンコードもしくはデコードすることを必要とし得る任意の電子デバイスまたは装置内で実行できることが理解されよう。
装置50は、デバイスを組み込み、保護するための筐体30を備えることができる。装置50は、液晶ディスプレイの形のディスプレイ32をさらに備えることができる。本発明の他の実施形態では、ディスプレイは、イメージまたはビデオを表示するのに適した任意の適切なディスプレイ技術であってもよい。装置50は、キーパッド34をさらに備えることができる。本発明の他の実施形態では、任意の適切なデータまたはユーザインターフェースメカニズムを採用することができる。例えば、ユーザインターフェースは、タッチセンサ式ディスプレイの一部として仮想キーボードまたはデータエントリシステムとして実行することができる。
装置は、デジタルまたはアナログ信号入力であってもよいマイクロフォン36または任意の適切なオーディオ入力を備えることができる。装置50は、オーディオ出力デバイスをさらに備えることができ、オーディオ出力デバイスは、本発明の実施形態では、イヤホン38、スピーカ、または、アナログオーディオもしくはデジタルオーディオ出力接続のいずれかの1つであってもよい。装置50は、バッテリも備えることができる(または本発明の他の実施形態では、デバイスは、太陽電池、燃料電池、もしくはクロックワークジェネレータなどの、任意の適切なモバイルエネルギーデバイスで電力供給することができる)。装置は、イメージおよび/またはビデオを記録またはキャプチャできるカメラをさらに備えることができる。装置50は、他のデバイスへの短距離見通し内通信のための赤外線ポートをさらに備えることができる。他の実施形態では、装置50は、例えば、Bluetoothワイヤレス接続またはUSB/ファイヤワイヤ有線接続などの、任意の適切な短距離通信ソリューションをさらに備えることができる。
装置50は、装置50を制御するためのコントローラ56、プロセッサ、またはプロセッサ回路機器を備えることができる。コントローラ56は、メモリ58に接続することができ、メモリ58は、本発明の実施形態では、イメージデータとオーディオデータの形で両方のデータを格納することができ、かつ/または、コントローラ56での実行のための命令も格納することができる。コントローラ56は、オーディオおよび/もしくはビデオデータのコーディングおよびデコーディングを実行すること、または、コントローラによって実行されるコーディングおよびデコーディングを支援することに適したコーデック回路機器54にさらに接続することができる。
装置50は、ユーザ情報を提供するための、ならびに、ネットワークにおけるユーザの認証および権限付与のための認証情報を提供するのに適した、例えば、UICCおよびUICCリーダといった、カードリーダ48およびスマートカード46をさらに備えることができる。
装置50は、コントローラに接続され、例えば、セルラー通信ネットワーク、ワイヤレス通信システム、またはワイヤレスローカルエリアネットワークとの通信のための、ワイヤレス通信信号を生成するのに適した、無線インターフェース回路機器52を備えることができる。装置50は、無線インターフェース回路機器52で生成された無線周波数信号を他の装置に伝送するための、および、他の装置から無線周波数信号を受け取るための、無線インターフェース回路機器52に接続されたアンテナ44をさらに備えることができる。
装置50は、個々のフレームを記録または検出できるカメラを備えることができ、個々のフレームは、その後、処理のためにコーデック54またはコントローラに渡される。装置は、伝送および/または格納の前に、別のデバイスから、処理のためのビデオイメージデータを受け取ることができる。装置50は、コーディング/デコーディングのためのイメージも、ワイヤレスで、または有線接続で受け取ることができる。上記で説明された装置50の構造要素は、対応する機能を実施するための手段の例を表す。
図3について、本発明の実施形態を利用できるシステムの例を示す。システム10は、1つまたは複数のネットワークを通じて通信できる複数の通信デバイスを備える。システム10は、(GSM、UMTS、CDMAネットワーク等などの)ワイヤレスセルラー電話ネットワーク、IEEE802.x規格のいずれかによって定義されたものなどのワイヤレスローカルエリアネットワーク(WLAN)、Bluetoothパーソナルエリアネットワーク、イーサネットローカルエリアネットワーク、トークンリングローカルエリアネットワーク、広域ネットワーク、およびインターネットを含むがこれらに限定されない、有線またはワイヤレスネットワークの任意の組合せを備えることができる。
システム10は、本発明の実施形態を実行するのに適した有線とワイヤレス両方の通信デバイス、および/または装置50を含むことができる。
例えば、図3に示されているシステムは、携帯電話ネットワーク11、およびインターネット28の表現を示す。インターネット28への接続は、長距離ワイヤレス接続、短距離ワイヤレス接続、ならびに、電話線、ケーブル線、電力線、および同様の通信経路を含むがこれらに限定されない様々な有線接続を含むことができるがこれらに限定されない。
システム10に示した実例の通信デバイスは、電子デバイスまたは装置50、パーソナルデジタルアシスタント(PDA)と携帯電話14の組合せ、PDA16、統合型メッセージングデバイス(IMD)18、デスクトップコンピュータ20、ノートブックコンピュータ22を含むことができるがこれらに限定されない。装置50は、据置型、または、移動している個人によって搬送されるとき、モバイルであってもよい。装置50は、車、トラック、タクシー、バス、列車、ボート、飛行機、自転車、モータサイクル、または、輸送の任意の同様の適切なモードを含むがこれらに限定されない輸送のモードでも位置することができる。
実施形態は、ディスプレイまたはワイヤレス能力を備えても備えなくてもよいセットトップボックス、すなわちデジタルTV受像器でも、エンコーダ/デコーダ実装形態のハードウェアもしくはソフトウェア、または組合せを備えるタブレットまたは(ラップトップ)パーソナルコンピュータ(PC)でも、様々なオペレーティングシステムでも、ならびに、ハードウェア/ソフトウェアベースのコーディングを提供するチップセット、プロセッサ、DSP、および/または組込型システムでも、実行することができる。
いくつかのまたはさらなる装置は、コールおよびメッセージを送ること、および受け取ること、ならびに、基地局24へのワイヤレス接続25を通じて、サービスプロバイダと通信することができる。基地局24は、携帯電話ネットワーク11とインターネット28との間の通信を可能にするネットワークサーバ26に接続することができる。システムは、追加の通信デバイス、および様々なタイプの通信デバイスを含むことができる。
通信デバイスは、符号分割多元接続(CDMA)、グローバルシステムフォーモバイルコミュニケーションズ(GSM)、ユニバーサル移動体通信システム(UMTS)、時間分割多重アクセス(TDMA)、周波数分割多重アクセス(FDMA)、トランスミッションコントロールプロトコル-インターネットプロトコル(TCP-IP)、ショートメッセージングサービス(SMS)、マルチメディアメッセージングサービス(MMS)、eメール、インスタントメッセージングサービス(IMS)、Bluetooth、IEEE802.11、および任意の同様のワイヤレス通信技術を含むがこれらに限定されない様々な伝送技術を使用して通信することができる。様々な本発明の実施形態を実行するのに関与する通信デバイスは、無線、赤外線、レーザ、ケーブル接続、および任意の適切な接続を含むがこれらに限定されない様々な媒体を使用して通信することができる。
テレコミュニケーションおよびデータネットワークでは、チャネルは、物理チャネルまたは論理チャネルを指すことができる。物理チャネルは、ワイヤなどの物理伝送媒体を指すことができ、その一方で、論理チャネルは、いくつかの論理チャネルを伝えることができる多重化媒体での論理接続を指すことができる。チャネルは、1つまたはいくつかのセンダ(またはトランスミッタ)から1つまたはいくつかのレシーバに、例えばビットストリームといった情報信号を伝えるために使用することができる。
MPEG-2トランスポートストリーム(TS:transport stream)は、ISO/IEC13818-1で、または同等に、ITU-T勧告H.222.0で指定され、多重化ストリームで、オーディオ、ビデオ、および他のメディア、ならびに、プログラムメタデータまたは他のメタデータを搬送するためのフォーマットである。パケット識別子(PID:packet identifier)は、TS内のエレメンタリストリーム(別名、パケット化エレメンタリストリーム)を識別するために使用される。したがって、MPEG-2 TS内の論理チャネルは、固有のPID値に対応するものとみなすことができる。
利用可能なメディアファイルフォーマット規格は、ISOベースメディアファイルフォーマット(ISO/IEC 14496-12、これは、ISOBMFFと略すことができる)、および、ISOBMFFから導出するNALユニット構造化ビデオ(ISO/IEC 14496-15)のためのファイルフォーマットを含む。
コンテナファイルフォーマットの例として、ISOBMFFのいくつかの概念、構造、および仕様を下記で説明し、コンテナファイルフォーマットに基づいて、実施形態を実行することができる。本発明の態様は、ISOBMFFに限定されず、むしろ、本発明を部分的または完全に実現できる1つの可能な基礎について説明される。
ISOベースメディアファイルフォーマットにおける基本的なビルディングブロックは、ボックスと呼ばれる。各ボックスは、ヘッダおよびペイロードを含む。ボックスヘッダは、ボックスのタイプ、およびバイトでのボックスのサイズを示す。ボックスは、他のボックスを含めることができ、ISOファイルフォーマットは、一定のタイプのボックス内でどのボックスタイプが許容されるかを指定する。さらに、いくつかのボックスの存在は、各ファイルにおいて必須であってもよい一方で、他のボックスの存在は、任意選択であってもよい。追加として、いくつかのボックスタイプについて、ファイル内に存在する2つ以上のボックスを含むことを許容できる。このように、ISOベースメディアファイルフォーマットは、ボックスの階層構造を指定するものとみなすことができる。
ファイルフォーマットのISOファミリによれば、ファイルは、ボックスにカプセル化されたメディアデータおよびメタデータを含む。各ボックスは、4キャラクタコード(4CC)で識別され、ボックスのタイプおよびサイズを知らせるヘッダで始まる。
ISOベースメディアファイルフォーマットに準拠するファイルでは、メディアデータは、メディアデータ‘mdat’ボックス内で提供することができ、ムービー‘moov’ボックスは、メタデータを含めるために使用することができる。場合によっては、ファイルを動作可能にするために、‘mdat’ボックスと‘moov’ボックスの両方が存在することが必要になることがある。ムービー‘moov’ボックスは、1つまたは複数のトラックを含むことができ、各トラックは、1つの対応するトラック‘trak’ボックス内にあってもよい。トラックは、メディア圧縮フォーマット(および、ISOベースメディアファイルフォーマットへのメディア圧縮フォーマットのカプセル化)に応じてフォーマットされたサンプルを指すメディアトラックを含む多くのタイプの1つであってもよい。
ムービーフラグメントは、例えば、レコーディングアプリケーションがクラッシュする、メモリ空間を使い果たす、または他の何らかの事故が発生した場合に、データを失わないように、例えばISOファイルにコンテンツを記録するときに、使用することができる。ムービーフラグメントがないと、ファイルの1つの連続エリア内に、例えばムービーボックスといった、全てのメタデータが書かれることをファイルフォーマットが必要とする可能性があるので、データ喪失が発生する可能性がある。さらに、ファイルを記録するとき、利用可能なストレージのサイズに対してムービーボックスをバッファするのに十分な量のメモリ空間(例えば、ランダムアクセスメモリRAM)がないことがあり、ムービーを閉じたときにムービーボックスのコンテンツの再計算が、非常に遅くなることがある。その上、ムービーフラグメントは、通常のISOファイルパーサを使用して、ファイルの同時の記録および再生を可能にすることができる。さらに、最初のバッファ期間が短くなると、ムービーフラグメントが使用されるときに、例えばファイルの同時受信および再生といった、先行ダウンロードが必要になることがあり、最初のムービーボックスは、同じメディアコンテンツを含むが、ムービーフラグメントなしで構築されたファイルと比較して、小さくなる。
ムービーフラグメント機能は、そうでなければムービーボックスの中にある可能性があるメタデータを、複数の部分に分割することを可能にすることができる。各部分は、トラックの一定期間に対応させることができる。言い換えれば、ムービーフラグメント機能は、ファイルメタデータおよびメディアデータをインターリーブすることを可能にすることができる。必然的に、ムービーボックスのサイズを制限し、上記で言及したユースケースを実現することができる。
いくつかの例では、ムービーフラグメントについてのメディアサンプルは、moovボックスと同じファイル内にある場合、mdatボックス内にあってもよい。それでも、ムービーフラグメントのメタデータに、moofボックスが提供されてもよい。moofボックスは、以前、moovボックス内にあった、一定期間の再生時間についての情報を含むことができる。moovボックスは、有効なムービーをそれ自体でさらに表すことができるが、さらに、同じファイル内の、ムービーフラグメントが続くことを示すmvexボックスを含むことができる。ムービーフラグメントは、結局moovボックスに関連付けられる存在を拡張することができる。
ムービーフラグメント内には、トラックあたりゼロから複数までのどこにでも含むトラックフラグメントのセットがあってもよい。トラックフラグメントは、今度は、実行するゼロから複数のトラックまでのどこにでも含むことができ、このドキュメントのそれぞれが、このトラックについてのサンプルの連続した実行である。これらの構造内で、多くのフィールドが任意選択であり、デフォルトにすることができる。moofボックスに含むことができるメタデータは、moovボックスに含むことができるメタデータのサブセットに限定することができ、場合によっては、それぞれにコード化することができる。moofボックスに含むことができるボックスに関する詳細は、ISOベースメディアファイルフォーマット仕様から見つけることができる。自己完結型ムービーフラグメントは、ファイル順で連続的なmoofボックスおよびmdatボックスからなるように定義することができ、ここで、mdatボックスは、(moofボックスがメタデータを提供する)ムービーフラグメントのサンプルを収め、他の任意のムービーフラグメントのサンプル(すなわち、他の任意のmoofボックス)を収めない。
トラック参照メカニズムは、トラックを互いに関連付けるために使用することができる。TrackReferenceBoxは、ボックスを含み、ボックスのそれぞれは、収めるトラックから他のトラックのセットへの参照を提供する。これらの参照は、収められたボックスのボックスタイプ(すなわち、ボックスの4キャラクタコード)でラベル付けされる。シンタックスは、以下のように指定することができる。
aligned(8) class TrackReferenceBox extends Box(‘tref’) {
TrackReferenceTypeBox [];
}
aligned(8) class TrackReferenceTypeBox (unsigned int(32) reference_type) extends Box(reference_type) {
unsigned int(32) track_IDs[];
}
track_IDsは、参照トラックのトラック識別子、または参照トラックグループのtrack_group_id値を提供する整数の配列として指定することができる。iがtrack_IDs[]配列に対する有効なインデックスであるtrack_IDs[i]の各値は、収めるトラックから、track_IDs[i]に等しいtrack_IDのトラックへの、または、track_IDs[i]に等しいtrack_group_idと、1に等しいTrackGroupTypeBoxのflagsフィールドの特定のビット(例えば最下位ビット)との両方を伴うトラックグループへの、参照を提供する整数である。track_group_id値が参照されるとき、トラック参照は、特定のトラック参照タイプの意味で別途述べられない限り、参照トラックグループの各トラックに個別に適用される。値0は、存在を許容されないこともある。
トラックグルーピングメカニズムは、トラックのグループの指示を可能にし、ここで、各グループは、特定の特性を共有するか、またはグループ内のトラックには、特定の関係がある。TrackGroupBoxは、TrackBoxに収めることができる。TrackGroupBoxは、TrackGroupTypeBoxから導出されたゼロ個以上のボックスを収める。特定の特性または関係は、収められたボックスのボックスタイプによって示される。収められたボックスは、識別子を含み、識別子は、同じトラックグループに属すトラックを推論するために使用することができる。収められたボックスの同じタイプをTrackGroupBox内に収め、これらの収められたボックス内に同じ識別子の値を保持するトラックは、同じトラックグループに属す。
ISOベースメディアファイルフォーマットは、サンプルグループ、時限メタデータトラック、およびサンプル補助情報という、特定のサンプルに関連付けることができる時限メタデータについての3つのメカニズムを収める。導出された仕様は、これらの3つのメカニズムの1つまたは複数を同様の機能に提供することができる。
AVCファイルフォーマットおよびSVCファイルフォーマットなどの、ISOベースメディアファイルフォーマットおよびその派生語におけるサンプルグルーピングは、グルーピング基準に基づいて、1つのサンプルグループのメンバになるようなトラック内の各サンプルの割当てと定義することができる。サンプルグルーピングにおけるサンプルグループは、連続サンプルであることに限定されず、非隣接サンプルを収めることができる。トラック内のサンプルに対して、2つ以上のサンプルグルーピングであり得るので、各サンプルグルーピングは、グルーピングのタイプを示すためにtypeフィールドを含むことができる。サンプルグルーピングは、2つのリンクしたデータ構造によって表すことができ、すなわち、(1)SampleToGroupBox(sbgpボックス)は、サンプルグループへのサンプルの割当てを表し、(2)SampleGroupDescriptionBox(sgpdボックス)は、グループのプロパティを記述する各サンプルグループについてのサンプルグループエントリを収める。異なるグルーピング基準に基づいた、SampleToGroupBoxおよびSampleGroupDescriptionBoxの複数のインスタンスがあり得る。これらは、グルーピングのタイプを示すために使用されるtypeフィールドで区別することができる。SampleToGroupBoxは、例えばグルーピングのサブタイプを示すために、使用することができるgrouping_type_parameterフィールドを含むことができる。
ISOベースメディアファイルフォーマット規格に対する修正案は、以下のようなコンパクトなサンプル対グループのマッピングを説明する。
ボックスタイプ:‘csgp’
コンテナ:SampleTableBoxまたはTrackFragmentBox
必須:なし
量:ゼロ以上
コンパクトなサンプル対グループボックスは、特に、繰り返しているパターンがある場合、および、特定のタイプのサンプルグループがほとんどないとき、サンプルからグループへのマッピングを表すための、よりコンパクトな方式を提供する。
設計は、それぞれがマッピング配列によって一回使用される、結合されたパターンのベクトルを使用し、マッピング配列は、このパターンの繰返しにサンプルの実行を関連付ける。これは、以下の例で示される。以下では、各文字は、異なるサンプルグループ記述インデックス値(場合によっては0)を表す。
トラックに以下の関連付けがある場合、第1のサンプルから始まる。
a b c b a b c b a b c x x a b c b a b d b
これらの関連付けは、以下で表されてもよい。
1. pattern_length=4;sample_count=11;
2. pattern_length=1;sample_count=2;
3. pattern_length=4;sample_count=6;
4. pattern_length=2;sample_count=2;
pattern=[
a b c b //長さ4のパターン1
x //長さ1のパターン2
a b c b //長さ4のパターン3
d b //長さ2のパターン4
] //pattern_lengthは、したがって、4+1+4+2=11である。
sample_count[i]がpattern_length[i]に等しいとき、パターンは、繰り返されない。
sample_count[i]が、pattern_length[i]より大きいとき、i番目のパターンのsample_group_description_index値が、sample_count[i]値をマップするために繰り返し使用される。これは、必ずしも、sample_count[i]がpattern_length[i]の倍数であるケースではなく、サイクルは、パターンの途中で終了してもよい。
1以上pattern_count以下の範囲内でのiの全ての値についてのsample_count[i]値のトータルが、トータルサンプルカウントより小さいとき、リーダは、もしあれば、SampleDescriptionGroupBoxにおいて定義されたデフォルトグループとの明示的なグループの関連付けのないサンプルを関連付けるべきであり、なければグループと関連付けない。
sample_count[i]値のトータルが、包含するTrackBoxまたはTrackFragmentBoxによって記述された実際のサンプルのトータルカウントより大きいのはエラーであり、リーダの挙動は、その後、定義されない。
シンタックス:
aligned(8) class CompactSampleToGroupBox
extends FullBox(‘csgp’, version, 0)
{
unsigned int(32) grouping_type; unsigned int(1) index_msb_indicates_fragment_local_description;
unsigned int(1) grouping_type_parameter_present;
unsigned int(6) field_size_minus_1;
if (grouping_type_parameter_present == 1) {
unsigned int(32) grouping_type_parameter;
}
unsigned int(32) pattern_count;
totalPatternLength=0;
for (i=1; i <= pattern_count; i++) {
unsigned int(32) pattern_length[i];
unsigned int(32) sample_count[i];
totalPatternLength += pattern_length[i];
}
for (j=1; j <= pattern_count; j++) {
for (k=1; k <= pattern_length[j]; k++) {
unsigned int(field_size) sample_group_description_index[j][k];
//このmsbは、fragment_localまたはglobalを示すことができる。
}
}
}
セマンティックス:
versionは、このボックスのバージョンを指定する整数であり、現在0である。
grouping_typeは、サンプルグルーピングのタイプ(すなわち、サンプルグループを形成するために使用される基準)を識別する整数であり、グルーピングタイプについての同じ値を伴うgrouping_typeのサンプルグループ記述テーブルにgrouping_typeをリンクする。grouping_type(および、使用される場合、grouping_type_parameter)についての同じ値を伴う‘csgp’または‘sbgp’の最大1回の発生が、トラックに対して存在する。
grouping_type_parameterは、グルーピングのサブタイプの指示である。
index_msb_indicates_fragment_local_descriptionは、このボックスが‘trak’ボックスの内部に現れるとき、ゼロでなければならないが、このボックスが‘traf’ボックスの内部に現れるとき、0または1であってよいフラグである。このフラグが1のとき、このフラグは、あらゆるsample_group_description_indexの最上位ビット(MSB:most significant bit)がインデックス番号の一部を形成しないことを示すが、代わりに、どの‘sgpd’ボックスの中で、グループ記述が見つかることになるかを示し、つまり、MSBが0の場合、インデックスは、‘trak’ボックスの‘sgpd’ボックスからグループ記述を識別し、MSBが1のとき、インデックスは、‘traf’ボックスの‘sgpd’ボックスからグループ記述を識別する。
field_sizeは、sample_group_description_index値の配列におけるエントリのビットでサイズを指定する整数であり、field_sizeは、値3、7、15、または31をとり、4、8、16、32というフィールドサイズをそれぞれ示す。フィールドサイズ4が使用される場合、各バイトは、entry[i]<<4+entry[i+1]という2つの値を収め、サイズが整数のバイトを満たさない場合、最後のバイトは、ゼロで埋められる。
pattern_countは、これに続くパターン配列内の関連付けられたパターンの長さを示す。含まれるsample_count値の合計は、マッピングされたサンプルの数を示す。
pattern_length[i]は、sample_group_description_index[j]値の第2の配列内のパターンに対応する。pattern_length[i]の各インスタンスは、0より大きい。
sample_count[i]は、i番目のパターンを使用するサンプルの数を指定する。sample_count[i]は、ゼロより大きく、sample_count[i]は、pattern_length[i]以上である。
sample_group_description_index[j][k]は、このグループ内のサンプルを記述するサンプルグループエントリのインデックスを示す整数である。インデックスは、1以上、SampleGroupDescriptionBoxにおけるサンプルグループエントリの数以下を範囲とするか、このサンプルがこのタイプのグループでないメンバであること示すために、値0をとる。
説明および実施形態では、サンプル対グループボックスまたはSampleToGroupBoxが参照されるとき、コンパクトなサンプル対グループボックスまたは同様のものを同等に使用することができる。
サブサンプルは、サンプルのバイトの連続範囲と定義することができる。サブサンプルについての情報は、SampleTableBoxおよび/またはTrackFragmentBox(es)に収めることができるSubSampleInformationBox(es)において示すことができる。サブサンプルの固有の定義は、所与のコーディングシステムのため、および/もしくは、(例えば、特定のサンプルエントリタイプといった)コーディングシステムの所与のカプセル化フォーマットのためのものであってもよく、ならびに/または、収めるSubSampleInformationBoxのflagsフィールドを使用してさらに指定することができる。例えば、HEVCについてのflagsフィールドの値は、SubSampleInformationBoxによってアドレス指定されたサブサンプルが、NALユニット、デコーディングユニット、タイル、コーディングツリーユニットロウ、スライス、またはコード化画像であることを示すことができる。2つ以上のSubSampleInformationBoxが、同じコンテナボックス内にあるとき、フラグの値は、これらのSubSampleInformationBoxesのそれぞれにおいて異なることが必要とされることがある。SubSampleInformationBoxのシンタックスは、以下のように指定することができる。
aligned(8) class SubSampleInformationBox
extends FullBox(‘subs’, version, flags) {
unsigned int(32) entry_count;
int i,j;
for (i=0; i < entry_count; i++) {
unsigned int(32) sample_delta;
unsigned int(16) subsample_count;
if (subsample_count > 0) {
for (j=0; j < subsample_count; j++) {
if(version == 1)
{
unsigned int(32) subsample_size;
}
else
{
unsigned int(16) subsample_size;
}
unsigned int(8) subsample_priority;
unsigned int(8) discardable;
unsigned int(32) codec_specific_parameters;
}
}
}
}
SubSampleInformationBoxのシンタックス要素の意味は、以下のように指定することができる。versionは、このボックスのバージョンを指定する整数である。entry_countは、以下のテーブルにおけるエントリの数を示す整数である。sample_deltaは、サブサンプル構造を含むサンプルを示す整数である。sample_deltaは、所望のサンプル番号と、以前のエントリにおいて示されたサンプル番号との間の、デコード順での、差としてコード化される。現在のエントリがトラック内の第1のエントリである場合、値は、サブサンプル情報を保持する第1のサンプルのサンプル番号を示し、すなわち、値は、サンプル番号とゼロ(0)との間の差である。現在のエントリが、先行する非空のトラックフラグメントを伴うトラックフラグメント内の第1のエントリである場合、値は、サブサンプル情報を保持する第1のサンプルのサンプル番号と、前のトラックフラグメント内の最後のサンプルのサンプル番号との間の差を示す。現在のエントリが、先行するトラックフラグメントがなにもないトラックフラグメント内の第1のエントリである場合、値は、サブサンプル情報を保持する第1のサンプルのサンプル番号を示し、すなわち、値は、サンプル番号とゼロ(0)との間の差である。これは、トラック内、またはトラックフラグメント内の第1のサンプルを記述する第1のエントリについてのsample_deltaが常に1であることを示唆する。subsample_countは、現在のサンプルについてのサブサンプルの数を指定する整数である。サブサンプル構造がない場合、このフィールドは、値0をとる。subsample_sizeは、現在のサブサンプルの、バイトでのサイズを指定する整数である。subsample_priorityは、各サブサンプルについての悪化優先度を指定する整数である。subsample_priorityの大きい方の値は、デコード後の品質に重要で、より大きなインパクトがあるサブサンプルを示す。0に等しいdiscardableは、現在のサンプルをデコードするのにサブサンプルが必要であることを意味し、一方で、1に等しいdiscardableは、現在のサンプルをデコードするのにサブサンプルが必要でないことを意味するが、例えば、サブサンプルが補足拡張情報(SEI:supplemental enhancement information)メッセージからなるといった拡張のために使用することができる。codec_specific_parameterは、使用中のコーデックおよび/またはそのカプセル化フォーマット(例えば、サンプルエントリタイプ)によって定義される。このような定義を利用できない場合、このフィールドは、0にセットされる。
Matroskaファイルフォーマットは、ビデオ、オーディオ、画像、またはサブタイトルトラックのいずれかを1つのファイルに格納することができる(がこれらに限定されない)。Matroskaは、ウェブMなどの、導出されたファイルフォーマットのための基本フォーマットとして使用することができる。Matroskaは、拡張可能バイナリメタ言語(EBML:Extensible Binary Meta Language)を基礎として使用する。EBMLは、XMLの原理によって着想をもたらされたバイナリおよびオクテット(バイト)適合型フォーマットを指定する。EBML自体は、バイナリマークアップの技法の一般化された記述である。Matroskaファイルは、EBML「ドキュメント」を作り上げる要素からなる。要素は、要素ID、要素のサイズについての記述子、およびバイナリデータ自体を組み込む。要素は、ネストすることができる。Matroskaのセグメント要素は、他の最上位(レベル1)要素のためのコンテナである。Matroskaファイルは、1つのセグメントを含むことができる(が、1つのセグメントから成ることに限定されない)。Matroskaファイル内のマルチメディアデータは、クラスタ(またはクラスタ要素)内に編成され、それぞれは、典型的には、数秒のマルチメディアデータを収める。クラスタは、BlockGroup要素を備え、BlockGroup要素は、ブロック要素を備える。Cues要素は、ランダムアクセスまたはシーキング(seeking)を支援することができ、シークポイントに対するファイルポインタ、またはそれぞれのタイムスタンプを含むことができるメタデータを備える。
ビデオコーデックは、入力ビデオを、格納/伝送に適した圧縮表現に変換するエンコーダ、および、圧縮ビデオ表現を復元して鑑賞可能形式に戻すことができるデコーダからなる。ビデオエンコーダおよび/またはビデオデコーダは、また、互いに別個のものであってもよく、すなわち、コーデックを形成する必要がない。典型的には、エンコーダは、よりコンパクトな形式で(すなわち、より低いビットレートで)ビデオを表すために、元のビデオシーケンス内のいくつかの情報を捨てる。
例えば、ITU-T H.263およびH.264の多くのエンコーダ実装形態といった、典型的なハイブリッドビデオエンコーダは、2つのフェーズでビデオ情報をエンコードする。第1に、例えば(コード化されているブロックに密接に対応する以前にコード化したビデオフレームの1つにおけるエリアを見つけ、示す)動き補償手段によって、または、(指定の手法でコード化されことになるブロックの周辺のピクセル値を使用する)空間的手段によって、一定の画像エリア(または「ブロック」)内のピクセル値が予測される。第2に、予測誤差、すなわち、ピクセルの予測ブロックと、ピクセルの元のブロックとの間の差がコード化される。これは、典型的には、指定の変換(例えば、離散コサイン変換(DCT:Discrete Cosine Transform)またはその変形物)を使用してピクセル値の差を変換すること、係数を量子化すること、および、量子化された係数をエントロピコーディングすることによって行われる。量子化処理の忠実度を変化させることによって、エンコーダは、ピクセル表現の正確さ(画像品質)と、結果として生じるコード化したビデオ表現のサイズ(ファイルサイズまたは伝送ビットレート)との間のバランスを制御することができる。
時間予測では、予測の出所は、以前にデコードした画像(別名、基準画像)である。イントラブロックコピー(IBC;別名 イントラブロックコピー予測)では、予測は、時間予測に同様に適用されるが、基準画像は現在の画像であり、以前にデコードされたサンプルだけしか、予測処理で参照することができない。インターレイヤまたはインタービュー予測を時間予測に同様に適用することができるが、基準画像は、別のスケーラブルレイヤから、または別のビューから、それぞれの、デコード画像である。ケースによっては、インター予測は、時間予測だけを指すことができることもあるが、他のケースでは、インター予測は、時間予測、ならびに、時間予測と同じまたは同様の処理で実施されることを条件として、イントラブロックコピー、インターレイヤ予測、およびインタービュー予測のいずれかを一括して指すことができる。インター予測または時間予測は、時には、動き補償または動き補償型予測を指すこともある。
インター予測は、時間予測、動き補償、または動き補償型予測を指すこともあるが、時間的冗長性を低減させる。インター予測では、予測の出所は、以前にデコードした画像である。イントラ予測は、同じ画像内の隣接ピクセルが相関関係にある可能性があるという事実を利用する。空間または変換ドメインでイントラ予測を実施することができ、すなわち、サンプル値または変換係数を予測することができる。イントラ予測は、典型的には、イントラコーディングで活用され、ここでは、インター予測は適用されない。
コーディング手順の1つの結果は、運動ベクトル、および量子化した変換係数などの、コーディングパラメータのセットである。空間的または時間的に隣のパラメータからパラメータが最初に予測される場合、多くのパラメータをより効率的にエントロピコーディングすることができる。例えば、空間的に隣の運動ベクトルから運動ベクトルを予測することができ、運動ベクトル予測器に対する差だけをコード化することができる。コーディングパラメータの予測、およびイントラ予測は、一括して、画像内予測と呼ばれることがある。
図4は、本発明の実施形態を用いるのに適したビデオエンコーダのブロック図を示す。図4は、2つのレイヤのためのエンコーダを提示するが、提示したエンコーダは、3つ以上のレイヤをエンコードするために同様に拡張できることが理解されよう。図4は、ベースレイヤのための第1のエンコーダセクション500、および、拡張レイヤのための第2のエンコーダセクション502を備えるビデオエンコーダの実施形態を示す。第1のエンコーダセクション500および第2のエンコーダセクション502のそれぞれは、入ってくる画像をエンコードするための同様の要素を備えることができる。エンコーダセクション500、502は、ピクセル予測器302、402、予測誤差エンコーダ303、403、および予測誤差デコーダ304、404を備えることができる。図4は、インター予測器306、406、イントラ予測器308、408、モード選択器310、410、フィルタ316、416、および参照フレームメモリ318、418を備えるものとして、ピクセル予測器302、402の実施形態も示す。第1のエンコーダセクション500のピクセル予測器302は、(イメージと、動き補償後の参照フレーム318との間の差を判定する)インター予測器306と、(現在のフレームまたは画像の既処理部分にだけ基づくイメージブロックについての予測を判定する)イントラ予測器308との両方でエンコードされることになるビデオストリームのベースレイヤイメージを受け取る300。インター予測器とイントラ予測器の両方の出力は、モード選択器310に渡される。イントラ予測器308は、2つ以上のイントラ予測モードを有することができる。したがって、各モードがイントラ予測を実施し、モード選択器310に予測信号を提供することができる。モード選択器310は、ベースレイヤ画像300のコピーも受け取る。これに対応して、第2のエンコーダセクション502のピクセル予測器402は、(イメージと、動き補償後の参照フレーム418との間の差を判定する)インター予測器406と、(現在のフレームまたは画像の既処理部分にだけ基づくイメージブロックについての予測を判定する)イントラ予測器408との両方でエンコードされることになるビデオストリームの拡張レイヤ画像を受け取る400。インター予測器とイントラ予測器の両方の出力は、モード選択器410に渡される。イントラ予測器408は、2つ以上のイントラ予測モードを有することができる。したがって、各モードがイントラ予測を実施し、モード選択器410に予測信号を提供することができる。モード選択器410は、拡張レイヤ画像400のコピーも受け取る。
現在のブロックをエンコードするために、どのエンコーディングモードを選択するかに応じて、インター予測器306、406の出力、または、任意選択のイントラ予測器モードのうちの1つの出力、または、モード選択器内のサーフェスエンコーダの出力が、モード選択器310、410の出力に渡される。モード選択器の出力は、第1の加算デバイス321、421に渡される。第1の加算デバイスは、予測誤差エンコーダ303、403に入力される第1の予測誤差信号320、420を生み出すために、ベースレイヤ画像300/拡張レイヤ画像400から、ピクセル予測器302、402の出力を減算することができる。
ピクセル予測器302、402は、イメージブロック312、412の予測表現と、予測誤差デコーダ304、404の出力338、438との組合せを、事前再構築器339、439からさらに受け取る。事前再構築イメージ314、414は、イントラ予測器308、408に、およびフィルタ316、416に、渡すことができる。事前表現を受け取ったフィルタ316、416は、事前表現をフィルタにかけ、参照フレームメモリ318、418に保存することができる最終再構築イメージ340、440を出力することができる。参照フレームメモリ318は、インター予測動作時に将来のベースレイヤ画像300を比較する基準イメージとして使用するために、インター予測器306に接続することができる。いくつかの実施形態による拡張レイヤのインターレイヤサンプル予測および/またはインターレイヤ動き情報予測の出所としてベースレイヤが選択され、示されることを条件として、参照フレームメモリ318は、インター予測動作時に将来の拡張レイヤ画像400を比較する基準イメージとして使用するために、インター予測器406に接続することもできる。その上、参照フレームメモリ418は、インター予測動作時に将来の拡張レイヤ画像400を比較する基準イメージとして使用するために、インター予測器406に接続することができる。
第1のエンコーダセクション500のフィルタ316からのフィルタリングパラメータは、いくつかの実施形態による拡張レイヤのフィルタリングパラメータを予測するための出所としてベースレイヤが選択され、示されることを条件として、第2のエンコーダセクション502に提供することができる。
予測誤差エンコーダ303、403は、変換ユニット342、442、および量子化器344、444を備える。変換ユニット342、442は、第1の予測誤差信号320、420を変換ドメインに変換する。変換は、例えば、DCT変換である。量子化器344、444は、量子化された係数を形成するために、例えばDCT係数といった変換ドメイン信号を量子化する。
予測誤差デコーダ304、404は、予測誤差エンコーダ303、403からの出力を受け取り、予測誤差エンコーダ303、403の逆の処理を実施して、デコードした予測誤差信号338、438を生み出し、デコードした予測誤差信号338、438は、第2の加算デバイス339、439でイメージブロック312、412の予測表現と結合されるとき、事前再構築イメージ314、414を生み出す。予測誤差デコーダは、変換信号を再構築するために、例えばDCT係数といった、量子化された係数値を逆量子化する逆量子化器361、461、および、再構築した変換信号への逆変換を実施する逆変換ユニット363、463を備えるものとみなすことができ、逆変換ユニット363、463の出力は、再構築されたブロックを収める。予測誤差デコーダは、さらにデコードした情報、および、フィルタパラメータに従って、再構築されたブロックをフィルタにかけることができるブロックフィルタも備えることができる。
エントロピエンコーダ330、430は、予測誤差エンコーダ303、403の出力を受け取り、誤差検出および訂正能力を提供するために、信号に対して適切なエントロピエンコーディング/可変長エンコーディングを実施することができる。エントロピエンコーダ330、430の出力は、例えばマルチプレクサ508によって、ビットストリームに挿入することができる。
H.264/AVC規格は、国際電気通信連合(ITU-T)のテレコミュニケーション標準化セクタのビデオコーディングエキスパートグループ(VCEG)と、国際標準化機構(ISO)/国際電気標準会議(IEC)のムービングピクチャエキスパートグループ(MPEG)とのジョイントビデオチーム(JVT)によって開発された。H.264/AVC規格は、両方の親標準化団体によって公開され、これは、ITU-T勧告H.264およびISO/IEC国際規格14496-10と呼ばれ、MPEG-4 Part10アドバンストビデオコーディング(AVC)としても知られる。新しい拡張または特徴を仕様に統合した、H.264/AVC規格の複数のバージョンが存在したことがあった。これらの拡張は、スケーラブルビデオコーディング(SVC)、およびマルチビュービデオコーディング(MVC)を含む。
高効率ビデオコーディング(H.265/HEVC、別名HEVC)規格のバージョン1は、VCEGおよびMPEGのジョイントコラボレーティブチーム-ビデオコーディング(JCT-VC)によって開発された。規格は、両方の上位の標準化団体によって公開され、これは、ITU-T勧告H.265およびISO/IEC国際規格23008-2と呼ばれ、MPEG-H Part2高効率ビデオコーディング(HEVC)としても知られる。H.265/HEVCの後のバージョンは、SHVC、MV-HEVC、REXT、3D-HEVC、およびSCCとそれぞれ略すことができるスケーラブル、マルチビュー、忠実度範囲拡張、3次元、および画面コンテンツコーディング拡張を含んでいた。
SHVC、MV-HEVC、および3D-HEVCは、HEVC規格のバージョン2の付録Fで指定された共通基本仕様を使用する。この共通の基礎は、例えば、インターレイヤ依存などのビットストリームのレイヤの特性、ならびに、インターレイヤ基準画像を含む基準画像リスト構築、および、マルチレイヤビットストリームのための画像オーダーカウント導出などのデコード処理、のいくつかを指定する、例えば高レベルシンタックスおよびセマンティックスを含む。付録Fは、HEVCの潜在的なその後のマルチレイヤ拡張でも使用することができる。ビデオエンコーダ、ビデオデコーダ、エンコード方法、デコード方法、ビットストリーム構造、および/または実施形態は、SHVCおよび/またはMV-HEVCなどの特定の拡張を参照にして以下で説明することができるとしても、これらは、全体的に、HEVCの任意のマルチレイヤ拡張に、および、さらにいっそう全体的に、任意のマルチレイヤビデオコード体系に適用できることを理解されたい。
多目的ビデオコーディング(VVC、H.266、またはH.266/VVC)規格の標準化は、ITU-TとMPEGとのジョイントビデオエキスパートチーム(JVET)において開始された。
H.264/AVCおよびHEVCのいくつかの主要な定義、ビットストリームおよびコーディング構造、ならびに概念が、実施形態を実行できるビデオエンコーダ、デコーダ、エンコード方法、デコード方法、およびビットストリーム構造の例として、本セクションで説明される。H.264/AVCの主要な定義、ビットストリームおよびコーディング構造、ならびに概念のいくつかは、HEVCにおけるものと同じであり、したがって、これらは、下記で一緒に説明される。本発明の態様は、H.264/AVCまたはHEVCに限定されず、むしろ、その最上位で本発明を部分的または完全に実現できる1つの可能な基礎について説明が行われる。H.264/AVCまたはHEVCの背景で下記において説明される多くの態様は、VVCに適用することができ、本発明の態様は、したがって、VVCに適用することができる。
多くの初期のビデオコーディング規格と同様に、ビットストリームシンタックスおよびセマンティックス、ならびに、誤差のないビットストリームのためのデコード処理が、H.264/AVCおよびHEVCで指定されている。エンコード処理は指定されていないが、エンコーダは、適合するビットストリームを生成しなければならない。ビットストリームおよびデコーダ適合は、仮想リファレンスデコーダ(HRD)で検証することができる。規格は、伝送エラーおよび喪失の対処に役立つコーディングツールを収めるが、エンコード時のツールの使用は任意選択であり、デコード処理は、誤ったビットストリームに対して指定されたことがない。
H.264/AVCまたはHEVCエンコーダへの入力、およびH.264/AVCまたはHEVCデコーダの出力のための基本ユニットは、それぞれ、画像である。エンコーダへの入力として与えられた画像は、ソース画像とも呼ぶことができ、デコーダによってデコードされた画像は、デコード画像と呼ぶことができる。
ソースおよびデコード画像は、サンプル配列の以下のセットの1つなどの、1つまたは複数のサンプル配列でそれぞれ構成される。
- 輝度(Y)のみ(モノクローム)
- 輝度および2つの彩度(YCbCrまたはYCgCo)
- 緑、青、および赤(GBR、RGBとしても知られる)
- 他の明示されていないモノクロームまたは三刺激カラーサンプリング(例えば、YZX、XYZとしても知られる)を表す配列
以下では、これらの配列は、使用中の実際の色彩表現方法に関わらず、輝度(またはLもしくはY)および彩度と呼ぶことができ、ここで、2つの彩度配列は、CbおよびCrと呼ぶことができる。使用中の実際の色彩表現方法は、例えば、H.264/AVCおよび/またはHEVCのビデオユーザビリティインフォメーション(VUI)シンタックスを使用して、例えばコード化ビットストリームで示すことができる。成分は、3つのサンプル配列(輝度および2つの彩度)の1つからの配列もしくは単一のサンプル、または、モノクロームフォーマットで画像を構成する配列、もしくは配列の単一のサンプルと定義することができる。
H.264/AVCおよびHEVCでは、画像は、フレームまたはフィールドであってもよい。フレームは、輝度サンプル、および場合によっては、対応する彩度サンプルの行列を含む。フィールドは、フレームの代替サンプル行のセットであり、ソース信号をインターレースするときに、エンコーダ入力として使用することができる。彩度サンプル配列は、なくてもよく(したがって、モノクロームサンプリングが使用中であってもよく)、または、輝度サンプル配列と比較するとき、彩度サンプル配列がサブサンプリングされてもよい。彩度フォーマットは、以下のように概説することができる。
-モノクロームサンプリングでは、ただ1つのサンプル配列があり、名目上は輝度配列とみなすことができる。
-4:2:0サンプリングでは、2つの彩度配列のそれぞれは、輝度配列の半分の高さおよび半分の幅を有する。
-4:2:2サンプリングでは、2つの彩度配列のそれぞれは、輝度配列の同じ高さおよび半分の幅を有する。
-4:4:4サンプリングでは、別個の色平面が使用中でないとき、2つの彩度配列のそれぞれは、輝度配列と同じ高さおよび幅を有する。
H.264/AVCおよびHEVCでは、別個の色平面としてのサンプル配列をビットストリームにコード化し、別々にコード化した色平面をビットストリームからそれぞれデコードすることができる。別個の色平面が使用中のとき、これらの1つ1つは、モノクロームサンプリングによる画像として(エンコーダおよび/またはデコーダによって)別々に処理される。
区画化は、セットの各要素が、サブセットの正確に1つの中にあるような、サブセットへのセットの分割と定義することができる。
HEVCエンコーディングおよび/またはデコーディングの動作を説明するとき、以下の用語を使用することがある。コーディングブロックは、コーディングブロックへのコーディングツリーブロックの分割が区画化になるような、Nのいくつかの値に対する、サンプルのN×Nのブロックと定義することができる。コーディングツリーブロック(CTB)は、コーディングツリーブロックへの成分の分割が区画化になるような、Nのいくつかの値に対する、サンプルのN×Nのブロックと定義することができる。コーディングツリーユニット(CTU)は、輝度サンプルのコーディングツリーブロック、3つのサンプル配列を有する画像の彩度サンプルの2つの対応するコーディングツリーブロック、または、モノクローム画像、もしくは、サンプルをコード化するために使用される3つの別個の色平面およびシンタックス構造を使用してコード化された画像のサンプルのコーディングツリーブロックと定義することができる。コーディングユニット(CU)は、輝度サンプルのコーディングブロック、3つのサンプル配列を有する画像の彩度サンプルの2つの対応するコーディングブロック、または、モノクローム画像、もしくは、サンプルをコード化するために使用される3つの別個の色平面およびシンタックス構造を使用してコード化された画像のサンプルのコーディングブロックと定義することができる。最大許容サイズのCUは、LCU(最大コーディングユニット)またはコーディングツリーユニット(CTU)と名付けることができ、ビデオ画像は、非重複LCUに分割される。
CUは、CU内のサンプルについての予測処理を定義する1つまたは複数の予測ユニット(PU)、および、前記CU内のサンプルについての予測誤差コーディング処理を定義する1つまたは複数の変換ユニット(TU)からなる。典型的には、CUは、可能なCUサイズの所定のセットから選択可能なサイズの、サンプルの正方形ブロックからなる。各PUおよびTUは、予測の細かさおよび予測誤差コーディング処理それぞれを向上させるために、より小さいPUおよびTUにさらに分けることができる。各PUは、このPU内のピクセルに対してどの種類の予測が適用されるかを定義する、PUに関連付けられた予測情報を保持することができる(例えば、インター予測PUについての運動ベクトル情報、および、イントラ予測PUについてのイントラ予測指向性情報)。
各TUは、(例えばDCT係数情報を含む)前記TU内のサンプルについての予測誤差デコード処理を記述する情報に関連付けることができる。典型的には、予測誤差コーディングが各CUに対して適用されるか否かが、CUレベルでシグナリングされる。CUに関連付けられた予測誤差残差がない場合、前記CUに対するTUがないとみなすことができる。CUへのイメージの分割、およびPUとTUへのCUの分割は、典型的には、これらのユニットの意図した構造をデコーダが再現できるビットストリームでシグナリングされる。
HEVCでは、画像は、タイルに区画化することができ、長方形であり、整数のLCUを収める。HEVCでは、タイルへの区画化は、規則的なグリッドを形成し、ここで、タイルの高さおよび幅は、最大で1つのLCUごとに互いに異なる。HEVCでは、スライスは、1つの独立スライスセグメントと、同じアクセスユニット内の(もしあれば)次の独立スライスセグメントの前にある(もしあれば)全てのその後の従属スライスセグメントと、に収められた整数のコーディングツリーユニットであると定義される。HEVCでは、スライスセグメントは、タイル走査時に連続して並べられ、単一のNALユニットに収められた、整数のコーディングツリーユニットであると定義される。スライスセグメントへの各画像の分割は、区画化である。HEVCでは、独立スライスセグメントは、スライスセグメントヘッダのシンタックス要素の値が、前にあるスライスセグメントについて値から推測されないスライスセグメントであると定義され、従属スライスセグメントは、スライスセグメントヘッダのいくつかのシンタックス要素の値が、デコード順で前にある独立スライスセグメントについての値から推測されるスライスセグメントであると定義される。HEVCでは、スライスヘッダは、現在のスライスセグメントであるか、または現在の従属スライスセグメントの前にある独立スライスセグメントである、独立スライスセグメントのスライスセグメントヘッダであると定義され、スライスセグメントヘッダは、スライスセグメント内で表された第1または全てのコーディングツリーユニットに関するデータ要素を収めるコード化したスライスセグメントの一部であると定義される。CUは、タイルが使用中でない場合、タイル内または画像内のLCUのラスター走査順で走査される。LCU内に、CUは、固有の走査順を保持する。
HEVCにおけるスライスセグメントレイヤRBSPは、以下のシンタックスを有する。
slice_segment_header()シンタックスは、以下のように始まる。
本明細書では、first_slice_segment_in_pic_flagおよびslice_segment_addressは、画像内のスライスセグメントの位置によって決まるが、他のシンタックス要素の値は、同じコード化画像の全ての独立スライスセグメントにおいて何度も変化しない。
運動制約タイルセット(MCTS:motion-constrained tile set)は、運動制約タイルセットの外側にあるサンプル値、および、運動制約タイルセットの外側にある1つまたは複数のサンプル値を使用して導出された断片的サンプル位置におけるサンプル値が、運動制約タイルセット内の任意のサンプルのインター予測のために使用されないように、エンコード時にインター予測処理が制限されるようなものである。追加として、MCTSのエンコーディングは、MCTSの外側にあるブロックから運動ベクトル候補が導出されないという手法で制約される。これは、HEVCの時間運動ベクトル予測を止めることによって、あるいは、TMVP候補、または、マージ時のTMVP候補、もしくは、MCTSの右下の最後の1つを除くMCTSの右側のタイル境界の直接左に位置するPUについてのAMVP候補リストの後にある任意の運動ベクトル予測候補、をエンコーダが使用できないようにすることによって、強制することができる。一般に、MCTSは、MCTSの外側にある、運動ベクトルなどの、任意のサンプル値およびコード化データから独立したタイルセットであると定義することができる。場合によっては、MCTSは、長方形エリアを形成するために必要とされることがある。文脈に応じて、MCTSは、画像内のタイルセットを、または、画像のシーケンス内のそれぞれのタイルセットを指すことがあることを理解されたい。それぞれのタイルセットは、画像のシーケンス内に配置されてもよいが、一般に、そうである必要はない。
インター予測で使用されるサンプル位置は、画像の対応する境界サンプルを指すために、画像の外側にある位置を別途満たすようなエンコードおよび/またはデコード処理によって満たせることに留意されたい。したがって、タイル境界が画像境界でもある場合、いくつかのユースケースでは、エンコーダは、サンプル位置を境界上に飽和させるので、運動ベクトルがこの境界を効果的に横切ること、または、この境界の外側にある位置を指す断片的サンプル補間を運動ベクトルが効果的に行うこと、を可能にすることができる。他のユースケースでは、特に、画像境界に隣接した場所に位置するビットストリームから、画像境界に隣接していない場所にタイルが位置する別のビットストリームに、コード化タイルを抽出できる場合、エンコーダは、いずれかのMCTS境界と同様に画像境界に運動ベクトルを制約することができる。
HEVCの時間運動制約タイルセットSEIメッセージは、ビットストリーム内の運動制約タイルセットの存在を示すために使用することができる。
MCTSについて、いくつかの例および実施形態を説明したものの、これらは、独立してデコード可能な時空ユニットの他の同様の概念を用いて同様に実現することができることを理解する必要がある。その上、このような時空ユニットのための運動制約は、上記のMCTSと同様に指定することができる。このような時空ユニットの例は、運動制約スライスおよび運動制約画像を含むがこれらに限定されない。運動制約スライスは、運動制約スライスの外側にあるシンタックスまたは導出された変数、運動制約スライスの外側にあるサンプル値、および運動制約スライスの外側にある1つまたは複数のサンプル値を使用して導出された断片的サンプル位置におけるサンプル値が、運動制約スライス内の任意のサンプルのインター予測のために使用されないように、エンコード時にインター予測処理が制約されるようなものである。運動制約画像は、画像境界を特別に考慮しない運動制約画像の外側にあるシンタックスまたは導出された変数、画像境界を特別に考慮しない運動制約画像の外側にあるサンプル値、および画像境界を特別に考慮しない運動制約画像の外側にある1つまたは複数のサンプル値を使用して導出された断片的サンプル位置におけるサンプル値が、運動制約画像内の任意のサンプルのインター予測のために使用されないように、エンコード時にインター予測処理が制約されるようなものである。画像境界についてのこのような特別な考慮は、例えば、画像境界内にあるはずの座標を満たすこと、および、予測処理時に利用不可能であるはずの画像境界の外側にあるブロックまたは運動ベクトルを推測すること、であってもよい。単一の時間インスタンスまたは単一の画像の文脈で句時空ユニットが使用されるとき、これは、コード化画像の一定のサブセット、および、デコードされたとき、デコード画像エリアの一定のサブセットに対応する空間ユニットとみなすことができる。
デコーダは、(エンコーダによって作り出され、圧縮表現で格納された動き情報または空間情報を使用して)ピクセルブロックの予測表現を形成するために、エンコーダと同様の予測手段、および、予測誤差デコーディング(空間ピクセルドメインにおける量子化された予測誤差信号を回復する予測誤差コーディングの逆の動作)、を適用することによって出力ビデオを再構築する。予測および予測誤差デコード手段を適用した後、デコーダは、出力ビデオフレームを形成するために、予測および予測誤差信号(ピクセル値)を合計する。デコーダ(およびエンコーダ)は、ビデオシーケンスにおけるこの次のフレームのための予測基準として、ディスプレイに出力ビデオを渡すこと、および/または出力ビデオを格納することを行う前に、出力ビデオの品質を改善するために、追加のフィルタリング手段も適用することができる。
フィルタリングは、例えば、非ブロック化、サンプルアダプティブオフセット(SAO:sample adaptive offset)、および/またはアダプティブループフィルタリング(ALF)のもう1つを含むことができる。H.264/AVCは、非ブロック化を含み、その一方で、HEVCは、非ブロック化とSAOの両方を含む。
典型的なビデオコーデックでは、動き情報は、予測ユニットなどの、各動き補償後のイメージブロックに関連付けられた運動ベクトルで示される。これらの運動ベクトルのそれぞれは、(エンコーダ側で)コード化される、または、(デコーダ側で)デコードされることになる画像内のイメージブロック、および、以前にコード化またはデコードされた画像のうちの1つにおける予測ソースブロックの変位を表す。運動ベクトルを効率的に表すために、これらは、典型的には、ブロック固有の予測運動ベクトルについて差別的にコード化される。典型的なビデオコーデックでは、予測運動ベクトルは所定の方式で作り出され、例えば、隣接ブロックのエンコードまたはデコードされた運動ベクトルのメジアンを計算する。運動ベクトル予測を作り出すための別の方法は、時間基準画像における隣接ブロックおよび/または同じ場所に位置するブロック、ならびに、運動ベクトル予測器として選ばれた候補のシグナリングから、候補予測のリストを生成することである。運動ベクトル値の予測に加えて、動き補償型予測のために、どの基準画像が使用されるかを予測することができ、この予測情報は、例えば、以前にコード化/デコードされた画像の参照インデックスによって、表すことができる。参照インデックスは、典型的には、時間基準画像内の隣接ブロックおよび/または同じ場所に位置するブロックから予測される。その上、典型的な高効率ビデオコーデックは、しばしば、マージング/マージモードと呼ばれる、追加の動き情報コーディング/デコーディングメカニズムを採用し、ここで、各利用可能な基準画像リストについての運動ベクトルおよび対応する基準画像インデックスを含む動きフィールド情報の全てが、どのような修正/訂正もなく、予測され、使用される。同様に、動きフィールド情報の予測は、時間基準画像内の隣接ブロックおよび/または同じ場所に位置するブロックの動きフィールド情報を使用して実行され、使用される動きフィールド情報は、利用可能な隣接ブロック/同じ場所に位置するブロックの動きフィールド情報で満たされた動きフィールド候補リストのリスト間でシグナリングされる。
典型的なビデオコーデックでは、動き補償後の予測残差は、最初に、(DCTのような)変換カーネルで変換され、次に、コード化される。この理由は、残差の間にいくつかの相関関係が依然として存在していることが多く、多くの場合、この相関関係を低減させ、より効率的なコーディングを提供するのに変換を役立てることができることである。
典型的なビデオエンコーダは、ラグランジュコスト関数を利用して、例えばブロックおよび関連付けられた運動ベクトルのための所望のコーディングモードといった、最適なコーディングモードを見つける。この種類のコスト関数は、重み係数λを使用して、不可逆コーディング方法による(正確なまたは推定される)イメージ歪み、および、イメージエリア内のピクセル値を表すのに必要な(正確なまたは推定される)量の情報を一緒に結びつける。
C=D+λR、 (1)
ここで、Cは、最小化されることになるラグランジュコストであり、Dは、モードおよび運動ベクトルを考慮したイメージ歪み(例えば平均2乗誤差)であり、および、Rは、(候補運動ベクトルを表すためのデータの量を含む)デコーダでイメージブロックを再構築するのに必要なデータを表すのに必要なビットの数である。
ビデオコーディング規格および仕様は、コード化スライスまたは同様のものにコード化画像をエンコーダが分割できるようにすることができる。スライス境界をまたぐ画像内予測は、典型的には、無効にされる。このように、スライスは、独立してデコード可能な部分にコード化画像を分けるための方式とみなすことができる。H.264/AVCおよびHEVCでは、スライス境界をまたぐ画像内予測を無効にすることができる。このように、スライスは、独立してデコード可能な部分にコード化画像を分けるための方式とみなすことができ、スライスは、したがって、しばしば、伝送のための基本ユニットとみなされる。多くの場合、エンコーダは、スライス境界をまたぐ画像内予測のどのタイプを止めるかをビットストリームで示すことができ、デコーダ動作は、例えば、どの予測ソースが利用可能であるかを推論するとき、この情報を考慮する。例えば、隣のCUからのサンプルは、隣のCUが異なるスライス内にある場合、イントラ予測に対して利用不可能とみなすことができる。
H.264/AVCまたはHEVCエンコーダの出力、およびH.264/AVCまたはHEVCデコーダの入力についての基本ユニットは、それぞれ、ネットワーク抽象化レイヤ(NAL:Network Abstraction Layer)ユニットである。パケット指向ネットワークでのトランスポート、または構造化ファイルへの格納のために、NALユニットをパケットまたは同様の構造にカプセル化することができる。フレーム構造を提供しない伝送またはストレージ環境のために、バイトストリームフォーマットがH.264/AVCおよびHEVCで指定されている。バイトストリームフォーマットは、各NALユニットの前にスタートコードを取り付けることによってNALユニットを互いに分離する。NALユニット境界の偽検出をなくすために、エンコーダは、バイト指向スタートコードエミュレーション防止アルゴリズムを実行し、このアルゴリズムは、スタートコードが別途発生した場合、NALユニットペイロードにエミュレーション防止バイトを追加する。パケットシステムとストリーム指向システムとの間の単純なゲートウェイ動作を可能にするために、バイトストリームフォーマットが使用中であるか否かに関わらず、スタートコードエミュレーション防止を常に実施することができる。NALユニットは、後に続くデータのタイプの指示を収めるシンタックス構造、および、エミュレーション防止バイトとともに必要に応じて散りばめられたRBSPの形のこのデータを収めるバイト、と定義することができる。ローバイトシーケンスペイロード(RBSP:raw byte sequence payload)は、NALユニット内にカプセル化された整数のバイトを収めるシンタックス構造と定義することができる。RBSPは空であるか、またはRBSPストップビットの前の、および0に等しいゼロ個以上のその後のビットの前の、シンタックス要素を収めるデータビットの文字列の形をしている。
NALユニットは、ヘッダおよびペイロードからなる。H.264/AVCおよびHEVCでは、NALユニットヘッダは、NALユニットのタイプを示す。
HEVCでは、2バイトのNALユニットヘッダが、全ての指定のNALユニットタイプのために使用される。NALユニットヘッダは、1つの予約ビット、6ビットのNALユニットタイプ指示、時間レベルについての3ビットのnuh_temporal_id_plus1指示(1以上であることを要求することができる)、および6ビットのnuh_layer_idシンタックス要素を収める。temporal_id_plus1シンタックス要素は、NALユニットについての時間識別子とみなすことができ、ゼロベースのTemporalId変数は、TemporalId=temporal_id_plus1-1のように導出することができる。省略形TIDは、TemporalId変数と区別なく使用することができる。0に等しいTemporalIdは、最小時間レベルに対応する。temporal_id_plus1の値は、2つのNALユニットヘッダバイトを伴うスタートコードエミュレーションを避けるために、ゼロ以外である必要がある。選択値以上のTemporalIdを有する全てのVCL NALユニットを除外し、他の全てのVCL NALユニットを含めることによって作り出されたビットストリームは、相変わらず適合する。必然的に、tid_valueに等しいTemporalIdを保持する画像は、インター予測基準としてtid_valueより大きいTemporalIdを保持するどの画像も使用しない。サブレイヤまたはテンポラルサブレイヤは、TemporalId変数の特定の値を伴うVCL NALユニット、および関連付けられた非VCL NALユニットからなる、時間スケーラブルビットストリームの時間スケーラブルレイヤ(または時間レイヤ、TL)であると定義することができる。nuh_layer_idは、スケーラビリティレイヤ識別子とみなすことができる。
NALユニットは、ビデオコーディングレイヤ(VCL:Video Coding Layer)NALユニット、および非VCL NALユニットにカテゴライズすることができる。VCL NALユニットは、典型的には、コード化スライスNALユニットである。HEVCでは、VCL NALユニットは、1つまたは複数のCUを表すシンタックス要素を収める。
HEVCでは、画像タイプについての省略形は、トレーリング(TRAIL)画像、テンポラルサブレイヤアクセス(TSA)、ステップワイズテンポラルサブレイヤアクセス(STSA)、ランダムアクセスデコーダブルリーディング(RADL)画像、ランダムアクセススキップリーディング(RASL:Random Access Skipped Leading)画像、ブロークンリンクアクセス(BLA)画像、インスタントデコーディングリフレッシュ(IDR:Instantaneous Decoding Refresh)画像、クリーンランダムアクセス(CRA:Clean Random Access)画像と定義することができる。いくつかの画像タイプは、上記のテーブルで示されるように、よりきめ細かくなる。例えば、BLA画像の3つのタイプ、すなわち、先頭画像のないBLA、デコード可能先頭画像のある(すなわちRASL画像のない)BLA、および、何らかの先頭画像があるBLAが指定される。
ランダムアクセスポイント(RAP:Random Access Point)画像は、ランダムアクセス画像またはイントラランダムアクセスポイント(IRAP:intra random access point)画像と呼ばれることもあるが、イントラコード化(intra-coded)イメージセグメントだけを含むことができる。さらに、RAP画像は、デコード順でRAP画像の前にあるどの画像のデコード処理も実施せずに正しくデコードできるようなものになるように、出力順でその後の画像を制約することができる。HEVCでは、IRAP画像は、BLA画像、CRA画像、またはIDR画像であってもよい。HEVCでは、活性化される必要があるときに必要なパラメータセットを利用できるという条件で、独立レイヤにおけるIRAP画像、および、デコード順で独立レイヤにおける全てのその後の非RASL画像を、デコード順でIRAP画像の前にあるどの画像のデコード処理も実施せずに正しくデコードすることができる。IRAP画像ではないイントラコード化スライスだけを収めるビットストリーム内の画像があってもよい。
HEVCでは、CRA画像が、デコード順でビットストリーム内の第1の画像であってもよく、または、ビットストリーム内の後の方に現れてもよい。HEVCにおけるCRA画像は、デコード順でCRA画像の後にあるが、出力順でCRA画像の前にある、いわゆる先頭画像を可能にする。先頭画像、いわゆるRASL画像のいくつかは、CRA画像の前にデコードされた画像を、基準として使用することができる。デコード順と出力順の両方でCRA画像の後にある画像は、CRA画像においてランダムアクセスが実施される場合、デコード可能であり、したがって、IDR画像のクリーンランダムアクセス機能と同様に、クリーンランダムアクセスが達成される。
CRA画像は、関連付けられたRADLまたはRASL画像を保持することができる。CRA画像が、デコード順でビットストリーム内の第1の画像であるとき、CRA画像は、デコード順で、コード化ビデオシーケンスの第1の画像であり、ビットストリーム内に存在しない画像への参照を、関連付けられたRASL画像が収めることができるので、どの関連付けられたRASL画像もデコーダによって出力されず、デコード可能でなくてもよい。
先頭画像は、出力順で、関連付けられたRAP画像の前にある画像である。関連付けられたRAP画像は、(存在する場合)デコード順で、前のRAP画像である。先頭画像は、RADL画像またはRASL画像である。
全てのRASL画像は、関連付けられたBLAまたはCRA画像の先頭画像である。関連付けられたRAP画像がBLA画像であるか、またはビットストリーム内の第1のコード化画像であるとき、ビットストリーム内に存在しない画像への参照を、RASL画像が収めることができるので、RASL画像は出力されず、正しくデコード可能でなくてもよい。それでも、RASL画像は、RASL画像の関連付けられたRAP画像の前のRAP画像からデコードが始まった場合、正しくデコードすることができる。RASL画像は、非RASL画像のデコード処理のための基準画像として使用されない。存在するとき、全てのRASL画像が、デコード順で、同じ関連付けられたRAP画像の全てのトレーリング画像の前にある。HEVC規格のいくつかの草案では、RASL画像は、タグドフォーディスカード(TFD)画像と呼ばれた。
全てのRADL画像は、先頭画像である。RADL画像は、同じ関連付けられたRAP画像のトレーリング画像のデコード処理のための基準画像として使用されない。存在するとき、全てのRADL画像は、デコード順で、同じ関連付けられたRAP画像の全てのトレーリング画像の前にある。RADL画像は、デコード順で、関連付けられたRAP画像の前にあるどの画像も参照せず、したがって、関連付けられたRAP画像からデコードが始まるとき、正しくデコードすることができる。
CRA画像から始まるビットストリームの一部が別のビットストリームに含まれるとき、CRA画像に関連付けられたRASL画像は、RASL画像の基準画像のいくつかが、結合されたビットストリーム内にない可能性があるので、正しくデコードできない可能性がある。このような接合動作を単純にするために、NALユニットタイプのCRA画像は、これがBLA画像であることを示すように変更することができる。BLA画像に関連付けられたRASL画像は、正しくデコード可能でなくてもよく、したがって、出力/表示されない。さらに、BLA画像に関連付けられたRASL画像は、デコードから省略されてもよい。
BLA画像が、デコード順でビットストリーム内の第1の画像であってもよく、または、ビットストリーム内の後の方に現れてもよい。各BLA画像は、新しいコード化ビデオシーケンスを始め、IDR画像のような、デコード処理に対する同様の効果を有する。それでも、BLA画像は、非空の基準画像セットを指定するシンタックス要素を収める。BLA画像が、BLA_W_LPに等しいnal_unit_typeを含むとき、BLA画像は、関連付けられたRASL画像を保持することができ、RASL画像は、ビットストリーム内に存在しない画像への参照を収めることができるので、デコーダによって出力されず、デコード可能でなくてもよい。BLA画像が、BLA_W_LPに等しいnal_unit_typeを保持するとき、このBLA画像は、関連付けられたRADL画像も保持することができ、RADL画像は、デコードされるものと指定される。BLA画像が、BLA_W_DLPに等しいnal_unit_typeを保持するとき、BLA画像は、関連付けられたRASL画像を含まないが、関連付けられたRADL画像を保持することができ、RADL画像は、デコードされるものと指定される。BLA画像が、BLA_N_LPに等しいnal_unit_typeを保持するとき、BLA画像は、どの関連付けられた先頭画像も保持しない。
IDR_N_LPに等しいnal_unit_typeを保持するIDR画像は、ビットストリーム内に存在する関連付けられた先頭画像を保持しない。IDR_W_LPに等しいnal_unit_typeを保持するIDR画像は、ビットストリーム内に存在する関連付けられたRASL画像を保持しないが、ビットストリーム内に、関連付けられたRADL画像を保持することができる。
nal_unit_typeの値が、TRAIL_N、TSA_N、STSA_N、RADL_N、RASL_N、RSV_VCL_N10、RSV_VCL_N12、またはRSV_VCL_N14に等しいとき、デコード画像は、同じテンポラルサブレイヤの他のどの画像のための基準としても使用されない。すなわち、HEVCでは、nal_unit_typeの値が、TRAIL_N、TSA_N、STSA_N、RADL_N、RASL_N、RSV_VCL_N10、RSV_VCL_N12、またはRSV_VCL_N14に等しいとき、デコード画像は、TemporalIdの同じ値を伴ういずれかの画像のRefPicSetStCurrBefore、RefPicSetStCurrAfter、およびRefPicSetLtCurrのどれにも含まれない。TRAIL_N、TSA_N、STSA_N、RADL_N、RASL_N、RSV_VCL_N10、RSV_VCL_N12、またはRSV_VCL_N14に等しいnal_unit_typeを伴うコード化画像は、TemporalIdの同じ値を伴う他の画像のデコード能力に影響を及ぼさずに捨てることができる。
トレーリング画像は、出力順で、関連付けられたRAP画像の後にある画像と定義することができる。トレーリング画像であるどの画像も、RADL_N、RADL_R、RASL_N、またはRASL_Rに等しいnal_unit_typeを保持しない。先頭画像である任意の画像は、デコード順で、同じRAP画像に関連付けられた全てのトレーリング画像の前にあるように制約することができる。RASL画像は、BLA_W_DLPまたはBLA_N_LPに等しいnal_unit_typeを保持するBLA画像に関連付けられたビットストリーム内に存在しない。RADL画像は、BLA_N_LPに等しいnal_unit_typeを保持するBLA画像に関連付けられた、または、IDR_N_LPに等しいnal_unit_typeを保持するIDR画像に関連付けられたビットストリーム内に存在しない。CRAまたはBLA画像に関連付けられたいずれかのRASL画像は、出力順で、CRAまたはBLA画像に関連付けられたいずれかのRADL画像の前にあるように制約することができる。CRA画像に関連付けられたいずれかのRASL画像は、デコード順でCRA画像の前にある他のいずれかのRAP画像の、出力順で後にあるように制約することができる。
HEVCでは、テンポラルサブレイヤ切替えポイントを示すために使用することができるTSAおよびSTSA画像タイプという2つの画像タイプがある。TSAまたはSTSA画像(排他的)およびTSAまたはSTSA画像がN+1に等しいTemporalIdを保持するまで、NまでのTemporalIdを伴うテンポラルサブレイヤがデコードされた場合、TSAまたはSTSA画像は、N+1に等しいTemporalIdを保持する(デコード順で)全てのその後の画像のデコードを可能にする。TSA画像タイプは、TSA画像自体、および、デコード順でTSA画像の後にある同じサブレイヤ内の全ての画像に制限を課すことができる。これらの画像のどれも、デコード順でTSA画像の前にある同じサブレイヤ内のいずれかの画像からのインター予測を使用することができない。TSA定義は、デコード順でTSA画像の後にある高い方のサブレイヤ内の画像に制限をさらに課すことができる。これらの画像のどれも、TSA画像と同じまたは高い方のサブレイヤに画像が属す場合、デコード順でTSA画像の前にあるこの画像を参照することができない。TSA画像は、0より大きいTemporalIdを保持する。STSAは、TSA画像と同様であるが、デコード順でSTSA画像の後にある高い方のサブレイヤ内の画像に制限を課さず、したがって、STSA画像があるサブレイヤへのアップスイッチだけを可能にする。ネストされた時間スケーラビリティでは、0より大きいTemporalIdを伴う全ての(トレーリング)画像に、TSA画像とラベル付けすることができる。
非VCL NALユニットは、例えば、シーケンスパラメータセット、画像パラメータセット、補足拡張情報(SEI)NALユニット、アクセスユニットデリミタ、エンドオブシーケンスNALユニット、エンドオブビットストリームNALユニット、またはフィラーデータNALユニット、というタイプの1つであってもよい。パラメータセットは、デコード画像の再構築に必要であることがあり、その一方で、他の非VCL NALユニットの多くは、デコードしたサンプル値の再構築には必要でない。
コード化ビデオシーケンスを通じて変化しないままのパラメータが、シーケンスパラメータセットに含まれてもよい。デコード処理によって必要とされることがあるパラメータに加えて、シーケンスパラメータセットは、任意選択として、ビデオユーザビリティインフォメーション(VUI:video usability information)を収めることができ、VUIは、バッファリング、画像出力タイミング、レンダリング、およびリソース確保に重要になり得るパラメータを含む。HEVCでは、シーケンスパラメータセットRBSPは、1つもしくは複数の画像パラメータセットRBSP、または、バッファ期間SEIメッセージを収める1つもしくは複数のSEI NALユニットによって参照することができるパラメータを含む。画像パラメータセットは、いくつかのコード化画像内で変化しない可能性が高いようなパラメータを収める。画像パラメータセットRBSPは、1つまたは複数のコード化画像のコード化スライスNALユニットによって参照することができるパラメータを含むことができる。
HEVCでは、ビデオパラメータセット(VPS:video parameter set)は、各スライスセグメントヘッダ内で見つかるシンタックス要素によって参照されるPPS内で見つかるシンタックス要素によって参照されるSPS内で見つかるシンタックス要素のコンテンツによって決定されたものとして、ゼロ個以上のコード化ビデオシーケンス全体に適用されるシンタックス要素を収めるシンタックス構造と定義することができる。
ビデオパラメータセットRBSPは、1つまたは複数のシーケンスパラメータセットRBSPによって参照することができるパラメータを含むことができる。
ビデオパラメータセット(VPS)、シーケンスパラメータセット(SPS:sequence parameter set)、および画像パラメータセット(PPS:picture parameter set)の間の関係および階層は、以下のように記述することができる。VPSは、パラメータセット階層における、ならびに、スケーラビリティおよび/または3Dビデオの文脈における、SPSより上の1つのレベルにある。VPSは、コード化ビデオシーケンス全体における全ての(スケーラビリティまたはビュー)レイヤにわたる全てのスライスに共通のパラメータを含むことができる。SPSは、コード化ビデオシーケンス全体における特定の(スケーラビリティまたはビュー)レイヤにおける全てのスライスに共通のパラメータを含み、複数の(スケーラビリティまたはビュー)レイヤによって共有されてもよい。PPSは、特定のレイヤ表現(1つのアクセスユニットにおける1つのスケーラビリティまたはビューレイヤの表現)における全てのスライスに共通のパラメータを含み、複数のレイヤ表現内の全てのスライスによって共有される可能性が高い。
VPSは、ビットストリーム内のレイヤの依存関係についての情報、および、コード化ビデオシーケンス全体における全ての(スケーラビリティまたはビュー)レイヤにわたる全てのスライスに適用可能な他の多くの情報を提供することができる。VPSは、2つの部品、ベースVPSおよびVPS拡張を備えるものとみなすことができ、ここで、VPS拡張は、任意選択として、存在してもよい。
アクセス、またはセッション交渉の容易さなど、伝送エラーに対する許容範囲以外の目的のために、帯域外伝送、シグナリング、またはストレージを、追加または代替として、使用することができる。例えば、ISOベースメディアファイルフォーマットに適合するファイル内のトラックのサンプルエントリは、パラメータセットを含むことができるが、ビットストリーム内のコード化データは、ファイル内の他の場所に、または別のファイルに格納される。(例えば、ビットストリームに伴うものを示す)ビットストリームに伴う句は、帯域外データがビットストリームに関連付けられる手法で、帯域外伝送、シグナリング、またはストレージを参照するために、請求項および説明される実施形態で使用することができる。ビットストリームに伴う句デコーディングまたは同様のものは、ビットストリームに関連付けられた(帯域外伝送、シグナリング、またはストレージから取得することができる)参照される帯域外データのデコーディングを指すことができる。
SEI NALユニットは、1つまたは複数のSEIメッセージを収めることができ、メッセージは、出力画像のデコードには必要ないが、画像出力タイミング、レンダリング、誤差検出、エラー隠蔽、およびリソース確保などの、関連した処理を支援することができる。いくつかのSEIメッセージがH.264/AVCおよびHEVCにおいて指定され、ユーザデータEIメッセージは、組織および会社が独自の使用のためにSEIメッセージを指定することを可能にする。H.264/AVCおよびHEVCは、指定のSEIメッセージについてのシンタックスおよびセマンティックスを収めるが、受け手においてメッセージをハンドリングするための処理は定義されない。必然的に、エンコーダは、SEIメッセージを作り出すときに、H.264/AVC規格またはHEVC規格に従う必要があり、H.264/AVC規格またはHEVC規格に適合するデコーダは、それぞれ、出力順の適合のためにSEIメッセージを処理する必要がない。SEIメッセージのシンタックスおよびセマンティックスをH.264/AVCおよびHEVCに含める理由の1つは、異なるシステム仕様が、補足情報を同様に解釈し、したがって、一緒に使えるようにすることである。システム仕様は、エンコードエンドと、デコードエンドの両方において特定のSEIメッセージの使用を要求でき、追加として、受け手において特定のSEIメッセージをハンドリングするための処理を指定できることが意図される。
HEVCでは、2つのタイプのSEINALユニット、すなわち、サフィックスSEI NALユニットおよびプレフィックスSEI NALユニットがあり、互いに異なるnal_unit_type値を保持する。サフィックスSEI NALユニットに収められたSEIメッセージは、サフィックスSEI NALユニットの、デコード順で前にあるVCL NALユニットに関連付けられる。プレフィックスSEI NALユニットに収められたSEIメッセージは、プレフィックス SEI NALユニットの、デコード順で後にあるVCL NALユニットに関連付けられる。
コード化画像は、画像のコード化表現である。
HEVCでは、コード化画像は、画像の全てのコーディングツリーユニットを収める画像のコード化表現と定義することができる。HEVCでは、アクセスユニット(AU)は、指定の分類ルールに従って互いに関連付けられたNALユニットのセットと定義することができ、デコード順で連続しており、nuh_layer_idのいずれかの特定の値を伴う最大1つの画像を収める。コード化画像のVCL NALユニットを収めることに加えて、アクセスユニットは、非VCL NALユニットも収めることができる。前記指定の分類ルールは、例えば、同じアクセスユニットへの同じ出力時間または画像出力カウント値に画像を関連付けることができる。
ビットストリームは、1つまたは複数のコード化ビデオシーケンスを形成するコード化画像の表現および関連付けられたデータを形成する、NALユニットストリームまたはバイトストリームの形のビットのシーケンスと定義することができる。第1のビットストリームは、同じファイル、または通信プロトコルの同じ接続などで、同じ論理チャネル内の第2のビットストリームの前にあってもよい。(ビデオコーディングの文脈における)エレメンタリストリームは、1つまたは複数のビットストリームのシーケンスと定義することができる。第1のビットストリームの終端は、固有のNALユニットで示すことができ、固有のNALユニットは、エンドオブビットストリーム(EOB)NALユニットと呼ぶことができ、ビットストリームの最後のNALユニットである。HEVCおよびその現在の草案の拡張では、EOB NALユニットは、0に等しいnuh_layer_idを含む必要がある。
コード化ビデオシーケンスは、独立してデコード可能であり、別のコード化ビデオシーケンス、またはビットストリームの終端、もしくはシーケンスNALユニットの終端が後に続くような、デコード順でのコード化画像のシーケンスと定義することができる。
HEVCでは、コード化ビデオシーケンスは、(上記の仕様への)追加または代替として、エンドオブシーケンス(EOS)NALユニットと呼ぶことができる固有のNALユニットが、ビットストリーム内に現れ、0に等しいnuh_layer_idを含むとき、終端に指定することができる。
グループオブピクチャーズ(GOP:group of pictures)およびその特性は、以下のように定義することができる。GOPは、前のどの画像がデコードされたかに関わらずデコードすることができる。オープンGOPは、オープンGOPの最初のイントラ画像からデコードが始まるとき、出力順で最初のイントラ画像の前にある画像を正しくデコードできない可能性があるような画像のグループである。言い換えれば、オープンGOPの画像は、(インター予測において)、前のGOPに属す画像を参照することができる。HEVCデコーダは、固有のNALユニットタイプであるCRA NALユニットタイプを、そのコード化スライスのために使用できるので、オープンGOPを始めるイントラ画像を認識することができる。クローズドGOPは、クローズドGOPの最初のイントラ画像からデコードが始まるとき、全ての画像を正しくデコードできるような画像のグループである。言い換えれば、クローズドGOP内の画像は、前のGOP内のどの画像も参照しない。H.264/AVCおよびHEVCでは、クローズドGOPは、IDR画像から始めることができる。HEVCでは、クローズドGOPは、また、BLA_W_RADLまたはBLA_N_LP画像から始めることができる。オープンGOPコーディング構造は、基準画像の選択の柔軟性が大きくなるので、クローズドGOPコーディング構造と比較して、圧縮時に、より効率的である可能性がある。
デコード画像バッファ(DPB:Decoded Picture Buffer)は、エンコーダで、および/またはデコーダで使用することができる。インター予測時の参照のために、および、デコード画像を出力順で並べ替えるために、デコード画像をバッファする2つの理由がある。H.264/AVCおよびHEVCが、基準画像のマーク、および出力の並べ替えの両方に多くの柔軟性をもたらすので、基準画像のバッファ、および出力画像のバッファのための別個のバッファは、メモリリソースの無駄になり得る。したがって、DPBは、基準画像および出力の並べ替えのための、統合デコード画像バッファ処理を含むことができる。デコード画像は、基準としてもはや使用されなくなり、出力する必要がなくなったとき、DPBから削除することができる。
スケーラブルビデオコーディングは、例えば、異なるビットレート、解像度、またはフレームレートで、1つのビットストリームがコンテンツの複数の表現を収めることができるコーディング構造を参照することができる。これらのケースでは、レシーバは、その特性(例えば、表示デバイスに最もよく一致する解像度)に応じて、所望の表現を抽出することができる。代替として、サーバまたはネットワーク要素は、例えば、ネットワーク特性、またはレシーバの処理能力に応じて、レシーバに伝送されることになるビットストリームの一部を抽出することができる。スケーラブルビットストリームの一定部分だけをデコードすることによって、意味のあるデコード後の表現を生み出すことができる。スケーラブルビットストリームは、典型的には、利用可能な最低品質ビデオを提供する「ベースレイヤ」、および、低い方のレイヤとともに受け取り、デコードしたときのビデオ品質を拡張する1つまたは複数の拡張レイヤからなる。拡張レイヤのためのコード化効率を改善するために、このレイヤのコード化表現は、典型的には、低い方のレイヤによって決まる。例えば、拡張レイヤの動き情報およびモード情報は、低い方のレイヤから予測することができる。低い方のレイヤのピクセルデータは、拡張レイヤのための予測を作り出すために使用することができる。
いくつかのスケーラブルビデオコード体系では、ビデオ信号を、ベースレイヤおよび1つまたは複数の拡張レイヤにエンコードすることができる。拡張レイヤは、例えば、時間解像度(すなわち、フレームレート)、空間解像度、または単に、別のレイヤもしくはその一部によって表されるビデオコンテンツの品質を、拡張することができる。各レイヤは、その全ての従属レイヤとともに、例えば、一定の空間解像度、時間解像度、および品質レベルでの、ビデオ信号の1つの表現である。本ドキュメントでは、スケーラブルレイヤを、その従属レイヤの全てとともに、「スケーラブルレイヤ表現」と呼ぶ。スケーラブルレイヤ表現に対応するスケーラブルビットストリームの一部は、一定の忠実度で元の信号の表現を生み出すために、抽出し、デコードすることができる。
スケーラビリティモードまたはスケーラビリティ次元は、以下を含むことができるがこれらに限定されない
- 品質スケーラビリティ:ベースレイヤ画像は、拡張レイヤ画像より低い品質でコード化され、これは、例えば、拡張レイヤにおける量子化パラメータ値より大きい,ベースレイヤにおける量子化パラメータ値(すなわち、変換係数量子化のための、より大きい量子化ステップサイズ)を使用して、達成することができる。品質スケーラビリティは、下記で説明されるように、細かい粒度もしくは細かい細かさのスケーラビリティ(FGS)、中程度の粒度もしくは中程度の細かさのスケーラビリティ(MGS)、および/または粗い粒度もしくは粗い細かさのスケーラビリティ(CGS)に、さらにカテゴライズすることができる。
- 空間スケーラビリティ:ベースレイヤ画像は、拡張レイヤ画像より低い解像度でコード化される(すなわち、より少ないサンプルを含む)。空間スケーラビリティおよび品質スケーラビリティ、特にその粗い粒度のスケーラビリティタイプは、時には、スケーラビリティの同じタイプとみなすことができる。
- ビュースケーラビリティ、これは、マルチビューコーディングとさらに呼ぶことができる。ベースレイヤは第1のビューを表し、その一方で、拡張レイヤは第2のビューを表す。ビューは、1つのカメラまたは視点を表す画像のシーケンスと定義することができる。ビューは、立体的または2ビュービデオにおいて、1つのビデオシーケンスまたはビューは、左目に提示される一方、平行ビューは、右目に提示されるものとみなすことができる。
- 深度スケーラビリティ、これは、深度拡張コーディングとさらに呼ぶことができる。ビットストリームのレイヤまたはいくつかのレイヤは、テクスチャビューを表すことができる一方で、他の1つまたは複数のレイヤは、深度ビューを表すことができる。
スケーラビリティタイプの多くは結合し、一緒に適用できることを理解されたい。
用語レイヤは、スケーラビリティのいずれかのタイプの文脈で使用することができ,ビュースケーラビリティおよび深度拡張を含む。拡張レイヤは、SNR、空間、マルチビュー、および/または深度拡張など、拡張のいずれかのタイプを指すことができる。ベースレイヤは、ベースビュー、SNR/空間スケーラビリティのためのベースレイヤ、または、深度拡張型ビデオコーディングのためのテクスチャベースビューなどのベースビデオシーケンスのいずれかのタイプを指すことができる。
センダ、ゲートウェイ、クライアント、または別のエンティティは、スケーラブルビデオビットストリームの伝送されたレイヤおよび/またはサブレイヤを選択することができる。用語レイヤ抽出、レイヤの抽出、またはレイヤダウンスイッチングは、センダ、ゲートウェイ、クライアント、または別のエンティティが受け取ったビットストリームで利用可能なものより少ないレイヤを伝送することを指すことができる。レイヤアップスイッチングは、センダ、ゲートウェイ、クライアント、または別のエンティティによってレイヤアップスイッチングより前に伝送されるものと比較して追加のレイヤを伝送すること、すなわち、レイヤダウンスイッチングにおいて早期に伝送をやめた1つまたは複数のレイヤの伝送を再開すること、を指すことができる。レイヤダウンスイッチングおよび/またはアップスイッチングと同様に、センダ、ゲートウェイ、クライアント、または別のエンティティは、テンポラルサブレイヤのダウンスイッチングおよび/またはアップスイッチングを実施することができる。センダ、ゲートウェイ、クライアント、または別のエンティティも、レイヤおよびサブレイヤダウンスイッチングおよび/またはアップスイッチングの両方を実施することができる。レイヤおよびサブレイヤダウンスイッチングおよび/またはアップスイッチングは、同じアクセスユニットもしくは同様のもので(すなわち同時に仮想的に)実行することができ、または、異なるアクセスユニットもしくは同様のもので(すなわち別個の時間に仮想的に)実行することができる。
(信号対ノイズまたはSNRとしても知られる)品質スケーラビリティ、および/または空間スケーラビリティのためのスケーラブルビデオエンコーダを以下のように実行することができる。ベースレイヤに対して、従来の非スケーラブルビデオエンコーダおよびデコーダを使用することができる。ベースレイヤの再構築/デコードされた画像は、拡張レイヤのための基準画像バッファおよび/または基準画像リストに含まれる。空間スケーラビリティの場合、再構築/デコードされたベースレイヤ画像は、拡張レイヤ画像のための基準画像リストへの再構築/デコードされたベースレイヤ画像の挿入より前にアップサンプリングすることができる。ベースレイヤデコード画像は、拡張レイヤのデコードされた基準画像と同様に、拡張レイヤ画像のコーディング/デコーディングのための基準画像リストに挿入することができる。必然的に、エンコーダは、インター予測基準としてベースレイヤ基準画像を選び、コード化ビットストリーム内の基準画像インデックスを用いたベースレイヤ基準画像の使用を示すことができる。デコーダは、拡張レイヤのためのインター予測基準としてベースレイヤ画像が使用されるビットストリームから、例えば基準画像インデックスから、デコードする。拡張レイヤのための予測基準として、デコードされたベースレイヤ画像が使用されるとき、デコードされたベースレイヤ画像は、インターレイヤ基準画像と呼ばれる。
前段落は、拡張レイヤおよびベースレイヤを伴う2つのスケーラビリティレイヤを伴うスケーラブルビデオコーデックを説明したが、3つ以上のレイヤを含むスケーラビリティ階層内の任意の2つのレイヤに、説明を一般化できることを理解する必要がある。この場合、第2の拡張レイヤは、エンコードおよび/またはデコード処理時に第1の拡張レイヤによって決めることができ、第1の拡張レイヤは、したがって、第2の拡張レイヤのエンコードおよび/またはデコードのためのベースレイヤとみなすことができる。さらに、拡張レイヤの基準画像バッファまたは基準画像リスト内の2つ以上のレイヤからのインターレイヤ基準画像があってもよく、これらのインターレイヤ基準画像のそれぞれは、エンコードおよび/またはデコードされている拡張レイヤのためのベースレイヤまたは基準レイヤ内にあるものとみなすことができることを理解する必要がある。さらに、代わりにまたは追加として、基準レイヤ画像アップサンプリング以外のタイプのインターレイヤ処理が行われてもよいことを理解する必要がある。例えば、基準レイヤ画像のサンプルのビット深度は、拡張レイヤのビット深度にコンバートすることができ、および/または、サンプル値は、基準レイヤの色空間から拡張レイヤの色空間へのマッピングを受けることができる。
スケーラブルビデオコーディングおよび/またはデコーディング方式は、マルチループコーディングおよび/またはデコーディングを使用することができ、以下のように特徴付けることができる。エンコード/デコード時、ベースレイヤ画像は、同じレイヤ内の、コード/デコード順でその後の画像のための動き補償基準画像として、あるいは、インターレイヤ(またはインタービューもしくはインター構成要素)予測のための基準として使用するために、再構築/デコードすることができる。再構築/デコードされたベースレイヤ画像は、DPBに格納することができる。拡張レイヤ画像は、同様に、同じレイヤ内の、コード/デコード順でその後の画像のための動き補償基準画像として、あるいは、もしあれば、より高い拡張レイヤのためのインターレイヤ(またはインタービューもしくはインター構成要素)予測のための基準として使用するために再構築/デコードすることができる。再構築/デコードされたサンプル値に加えて、ベース/基準レイヤのシンタックス要素値、またはベース/基準レイヤのシンタックス要素値から導出された変数を、インターレイヤ/インター構成要素/インタービュー予測において使用することができる。
インターレイヤ予測は、(エンコードまたはデコードされている)現在の画像のレイヤとは異なるレイヤからの、基準画像のデータ要素(例えば、サンプル値または運動ベクトル)によって決まる手法での予測と定義することができる。多くのタイプのインターレイヤ予測が存在し、スケーラブルビデオエンコーダ/デコーダにおいて適用することができる。インターレイヤ予測の利用可能なタイプは、例えば、ビットストリーム内のどのビットストリームもしくは特定のレイヤがエンコードされているか、または、ビットストリーム内のビットストリームもしくは特定のレイヤを示すコーディングプロフィールを、適合させるためにいつデコードするかに従って、コーディングプロフィールによって決めることができる。代替としてまたは追加として、インターレイヤ予測の利用可能なタイプは、使用されているスケーラビリティのタイプ、またはスケーラブルコーデックのタイプ、またはビデオコーディング規格補正(例えば、SHVC、MV-HEVC、もしくは3D-HEVC)によって決めることができる。
直接基準レイヤは、レイヤが直接基準レイヤである別のレイヤのインターレイヤ予測のために使用することができるレイヤと定義することができる。直接予測レイヤは、別のレイヤが直接基準レイヤであるレイヤと定義することができる。間接基準レイヤは、第2のレイヤの直接基準レイヤでなく、レイヤが間接基準レイヤである第2のレイヤの直接基準レイヤ、または直接基準レイヤの間接基準レイヤである第3のレイヤの直接基準レイヤであるレイヤと定義することができる。間接予測レイヤは、別のレイヤが間接基準レイヤであるレイヤと定義することができる。独立レイヤは、直接基準レイヤのないレイヤと定義することができる。言い換えれば、独立レイヤは、インターレイヤ予測を使用して予測されない。非ベースレイヤは、ベースレイヤ以外の任意のレイヤと定義することができ、ベースレイヤは、ビットストリーム内の最低レイヤと定義することができる。独立非ベースレイヤは、独立レイヤと非ベースレイヤの両方であるレイヤと定義することができる。
MVCと同様に、MV-HEVCでは、インタービュー基準画像は、コード化またはデコードされている現在の画像の基準画像リストに含めることができる。SHVCは、(H.264/AVCのSVC拡張とは異なる)マルチループデコード動作を使用することができる。SHVCは、参照インデックスベースアプローチを使用するものとみなすことができ、すなわち、インターレイヤ基準画像は、(上記で説明されたように)コード化またはデコードされている現在の画像の1つまたは複数の基準画像リストに含めることができる。
拡張レイヤコーディングについて、HEVCベースレイヤの概念およびコーディングツールは、SHVC、MV-HEVC、および/または同様のもので使用することができる。それでも、追加のインターレイヤ予測ツールは、拡張レイヤを効率的にコード化するために基準レイヤ内の(再構築画像サンプルおよび動きパラメータ、別名動き情報を含む)既にコード化されたデータを用いるが、SHVC、MV-HEVC、および/または同様のコーデックに統合することができる。
成分画像は、入力画像全体の表現に対応するような、含んでいる(デコード)コード化画像の一部と定義することができる。成分画像に加えて、含んでいる(デコード)コード化画像は、別の成分画像などの他のデータを含むことができる。
フレームパッキングは、2つ以上の入力画像を出力画像に配置することを含むものと定義することができ、入力画像は、(入力)成分フレームまたは成分画像と呼ぶことができる。一般に、フレームパッキングは、成分フレームのいずれかの特定のタイプに限定されず、または、成分フレームは、互いに特定の関係を有している必要はない。多くの場合、フレームパッキングは、立体ビデオクリップの成分フレームを単一の画像シーケンスに配置するために使用される。配置することは、出力画像内の空間的に重複していないエリア内に入力画像を置くことを含むことができる。例えば、サイドバイサイド配置では、2つの入力画像は、互いに隣接して出力画像内に水平に置かれる。配置することは、2つ以上の成分フレーム区画に1つまたは複数の入力画像を区画化すること、および、出力画像内の空間的に重複していないエリア内に成分フレーム区画を置くことも含むことができる。出力画像、またはフレームパッキングされた出力画像のシーケンスは、例えばビデオエンコーダによって、ビットストリームにエンコードすることができる。ビットストリームは、例えばビデオデコーダによって、デコードすることができる。デコード後のデコーダまたは処理後動作は、例えば表示のために、デコード画像からデコードされた成分フレームを抽出することができる。
用語360度ビデオまたは仮想現実(VR)ビデオは、区別なく使用することができる。これらは、一般に、典型的な表示配置内に単一の時点におけるビデオの一部だけが表示されるような大きい視野を提供するビデオコンテンツを指すことができる。例えば、VRビデオは、例えば約100度の視野を表示する能力があってもよいヘッドマウントディスプレイ(HMD)で鑑賞することができる。表示されることになるVRビデオコンテンツの空間サブセットは、HMDの方向に基づいて選択することができる。別の例では、典型的なフラットパネル鑑賞環境が想定され、例えば40度までの視野を表示することができる。広いFOVコンテンツ(例えばフィッシュアイ)をこのようなディスプレイに表示するとき、画像全体ではなく、空間サブセットを表示するのが好ましいことがある。
MPEG全方向メディアフォーマット(ISO/IEC 23090-2)は、仮想現実(VR)システム規格である。OMAFは、(ISOBMFFから導出されたファイルフォーマットと、DASHおよびMPEGメディアトランスポートのためのストリーミングフォーマットの両方を含む)メディアフォーマットを定義する。OMAFバージョン1は、360°ビデオ、イメージ、およびオーディオ、ならびに、関連付けられた時限テキストをサポートし、3自由度(3DoF)コンテンツの利用(consumption)を容易にし、全方向コンテンツでカバーされた任意の方位および高度範囲および傾き角度でビューポートを選択できるが、コンテンツは、鑑賞位置のどの平行移動の変化にも適合されないことを意味する。さらに下記で説明されるビューポート依存型ストリーミングシナリオも、3DoFのために設計されてきたが、異なる数の自由度に適合させることができる。
OMAFバージョン2の標準化が進行中である。OMAFv2は、複数の視点、オーバーレイ、サブ画像構成物、および上半身の動きだけにざっと限定される鑑賞空間を伴う6自由度のサポートのような特徴を含めることが計画されている。
視点は、そこからユーザがシーンを鑑賞するポイントまたは空間と定義することができ、通常、カメラ位置に対応する。わずかな頭の運動は、異なる視点を意味しない。鑑賞位置は、そこからユーザがシーンを鑑賞する鑑賞空間内の位置と定義することができる。鑑賞空間は、イメージおよびビデオのレンダリングを行うことができ、VR体験が有効な鑑賞位置の3D空間と定義することができる。
MPEG全方向メディアフォーマット(OMAF)を、図5を参照することによって以下で説明する。現実世界の視聴覚シーン(A)は、オーディオセンサ、ならびに、複数のレンズおよびセンサを伴うカメラのセット、またはカメラデバイスでキャプチャされる。獲得すると、デジタルイメージ/ビデオのセット(Bi)およびオーディオ(Ba)の信号のセットを生じる。カメラ/レンズは、典型的には、カメラセットまたはカメラデバイスの中心点の周りの全方向をカバーし、したがって、360度ビデオのという名前である。
オーディオは、多くの種々のマイクロフォン構成を使用してキャプチャし、チャネルベース信号、静的または動的(すなわち3Dシーンを通って動く)オブジェクト信号、およびシーンベース信号(例えば、高次アンビソニックス)を含むいくつかの異なるコンテンツフォーマットとして格納することができる。チャネルベース信号は、典型的には、CICPにおいて定義されたラウドスピーカレイアウトの1つに適合する。全方向メディアアプリケーションでは、レンダリングされた没入型オーディオプログラムのラウドスピーカレイアウト信号は、ヘッドホンを介した提示のためにバイナローライズされる(binaraulized)。
同じ時間インスタンスの画像(Bi)は、パック画像(D)にステッチされ、投影され、マッピングされる。
モノスコーピック360度ビデオについて、1つの時間インスタンスの入力イメージは、1つのビューを表す投影画像を生成するためにステッチされる。モノスコーピックコンテンツのためのイメージステッチ、投影、および領域単位(region-wise)パッキング処理の内訳が、図6aで示され、以下のように説明される。入力イメージ(Bi)は、3次元投影構造にステッチされて投影され、3次元投影構造は、例えば、ユニット球体であってもよい。投影構造は、平面またはその一部などの、1つまたは複数の表面を含むとみなすことができる。投影構造は、キャプチャされたVR画像/ビデオコンテンツが投影され、それぞれの投影画像を形成することができる1つまたは複数の表面からなる3次元構造と定義することができる。投影構造上のイメージデータは、2次元投影画像(C)上にさらに配置される。用語投影は、投影されたフレーム上に入力イメージのセットを投影する処理と定義することができる。例えば、エクイレクタングラ投影(ERP)フォーマット、およびキューブマップ投影(CMP)フォーマットを含む、投影画像の表現フォーマットの事前定義されたセットがあってもよい。投影画像が球体全体をカバーするとみなすことができる。
任意選択として、次に、パック画像上に投影画像をマッピングするために、領域単位パッキングが適用される。領域単位パッキングが適用されない場合、パック画像は投影画像と同一であり、この画像は、イメージ/ビデオエンコーディングへの入力として与えられる。そうでなければ、投影画像の領域は、パック画像内の各領域の位置、形状、およびサイズを示すことによって、パック画像(D)上にマッピングされ、パック画像(D)は、イメージ/ビデオエンコーディングへの入力として与えられる。用語領域単位パッキングは、パック画像に投影画像をマッピングする処理と定義することができる。用語パック画像は、投影画像の領域単位パッキングから生じる画像と定義することができる。
立体360度ビデオの場合、1つの時間インスタンスの入力イメージは、1つが各目のためのものである、2つのビューを表す投影画像を生成するためにステッチされる。図6bに関して下記で説明されるように、両方のビューを同じパック画像にマッピングし、従来の2Dビデオエンコーダでエンコードすることができる。代替として、投影画像の各ビューは、独自のパック画像にマッピングすることができ、この場合、イメージステッチ、投影、および領域単位パッキングは、図6aとともに上記で説明されたようなものである。左ビューまたは右ビューのパック画像のシーケンスは、独立してコード化するか、またはマルチビュービデオエンコーダを使用するとき、他のビューから予測することができる。
両方のビューが同じパック画像にマッピングされる立体コンテンツのための画像ステッチ、投影、および領域単位パッキング処理の内訳が、図6bで示され、以下のように説明される。入力イメージ(Bi)は、1つが各目のためのものである、2つの3次元投影構造にステッチされ、投影される。各投影構造上のイメージデータは、球体全体をカバーする2次元投影画像上にさらに配置される(左目のためのCL、右目のためのCR)。左ビュー画像および右ビュー画像を同じ投影画像にパッキングするために、フレームパッキングが適用される。任意選択として、次に、パック画像に投影画像をパッキングするために領域単位パッキングが適用され、パック画像(D)は、イメージ/ビデオエンコーディングへの入力として与えられる。領域単位パッキングが適用されない場合、パック画像は投影画像と同一であり、この画像は、イメージ/ビデオエンコーディングへの入力として与えられる。
画像ステッチ、投影、および領域単位パッキング処理は、例えば、投影構造の異なる方向に対して、同じコンテンツの異なるバージョンを作り出すために、同じソース画像に対して何度も実行することができる。同様に、領域単位パッキング処理は、エンコードされることになるパック画像の2つ以上のシーケンスを作り出すために、同じ投影画像から何度も実施することができる。
360度パノラマコンテンツ(すなわち、イメージおよびビデオ)は、イメージングデバイスのキャプチャ位置の周囲の完全な360度視野を水平にカバーする。垂直視野は変化してもよく、例えば180度であってもよい。360度視野を水平に、および180度視野を垂直にカバーするパノラマイメージは、2D画像を形成するために垂直にカットすることができる境界シリンダにマップすることができる球体で表すことができる(このタイプの投影は、エクイレクタングラ投影として知られる)。モノスコーピックエクイレクタングラパノラマ画像を形成する処理が、図7に示されている。複数のレンズおよびセンサを伴うカメラアレイまたはカメラデバイスのフィッシュアイイメージなどの入力イメージのセットが、球体イメージ上にステッチされる。球体イメージは、(上面および下面のない)シリンダ上にさらに投影される。シリンダは、2次元投影フレームを形成するために展開される。実際には、本ステップの1つまたは複数はマージすることができ、例えば、入力イメージは、球体上への中間投影なく、シリンダ上に直接投影することができる。エクイレクタングラパノラマのための投影構造は、単一の表面を備えるシリンダとみなすことができる。
一般に、360度コンテンツは、多面体(すなわち、平らな多角形の面、一直線の縁、およびシャープな角または頂点を収める3次元固体オブジェクト、例えば、キューブまたは角錐)、シリンダ(エクイレクタングラ投影を用いて上記で説明したような、シリンダ上に球体イメージを投影することによる)、シリンダ(球体上に最初に投影することなく直接的に)、円錐等などの、種々のタイプの固体の幾何学構造にマップし、その後、2次元イメージ平面に広げることができる。
場合によっては、360度水平視野を伴うが、180度未満の垂直視野を伴うパノラマコンテンツは、パノラマ投影の特殊なケースとみなすことができ、ここで、球体の極エリアは、2次元イメージ平面にマップされてこなかった。場合によっては、パノラマイメージは、360度未満の水平視野および180度までの垂直視野を保持することができるが、パノラマ投影フォーマットの特性を別途保持する。
領域単位パック情報は、ビットストリーム内の、またはビットストリームに伴うメタデータとしてエンコードすることができる。例えば、パック情報は、初めの方で説明したように、例えば投影画像からパック画像へなど、事前定義されるか、示されたソースフォーマットから、パッキングされたフレームフォーマットへの、領域単位マッピングを含むことができる。
長方形領域単位パッキングメタデータを次に説明する。各領域について、メタデータは、投影画像内の長方形、パック画像内のそれぞれの長方形、ならびに、90度、180度、もしくは270度ごとの回転の任意選択の変換、ならびに/または、水平および/もしくは垂直ミラーリングを定義する。長方形は、例えば、左上隅および右下隅の位置で示すことができる。マッピングは、リサンプリングを含むことができる。それぞれの長方形のサイズは、投影画像およびパック画像で異なってもよいので、メカニズムは、領域単位リサンプリングを暗示する。
数ある中でも、領域単位パッキングは、以下の使用シナリオのためのシグナリングを提供する。
- ビューポート独立型投影のための追加の圧縮は、球体全体にわたる、より大きい統一性を達成するために、種々の領域のサンプリングの密度を高めることによって達成される。例えば、ERPの上部および下部をオーバーサンプリングし、領域単位パッキングを適用して、これらを水平にダウンサンプリングすることができる。
- 適応性のある手法で、キューブマップ投影などの平面ベースの投影フォーマットの面を配置すること。
- ビューポート独立型投影フォーマットを使用して、ビューポート依存型ビットストリームを生成すること。例えば、ERPの領域、またはCMPの面は、異なるサンプリング密度を有することができ、基礎をなす投影構造は、異なる方向を有することができる。
- エクストラクタトラックで表されたパック画像の領域を示すこと。これは、異なる解像度のビットストリームからタイルをエクストラクタトラックが収集するときに必要である。
OMAFは、画像ステッチ、投影、および領域単位パッキングの省略を可能にし、これらのキャプチャされたフォーマットでイメージ/ビデオデータをエンコードする。この場合、イメージDは、イメージBiと同じとみなされ、時間インスタンスあたりの限られた数のフィッシュアイイメージがエンコードされる。
オーディオについて、キャプチャされた信号が本来、没入型および全方向型なので、ステッチ処理は不要である。
ステッチされた画像(D)は、コード化イメージ(Ei)、またはコード化ビデオビットストリーム(Ev)としてエンコードされる。キャプチャされたオーディオ(Ba)は、オーディオビットストリーム(Ea)としてエンコードされる。コード化イメージ、ビデオ、および/またはオーディオは、次に、特定のメディアコンテナファイルフォーマットに応じて、ファイル再生のためのメディアファイル(F)、またはストリーミングのための初期化セグメントおよびメディアセグメントのシーケンス(Fs)に構成される。本明細書では、メディアコンテナファイルフォーマットは、ISOベースメディアファイルフォーマットである。ファイルエンカプスレータは、デコードされたパック画像のレンダリングを支援する投影および領域単位パック情報などの、ファイルまたはセグメントへのメタデータも含む。
ファイル内のメタデータは、以下を含むことができる。
- 投影画像の投影フォーマット、
- フィッシュアイビデオパラメータ、
- パック画像でカバーされる球体表面のエリア、
- グローバル座標軸に対する投影画像に対応する投影構造の方向、
- 領域単位パック情報、および
- 領域単位品質ランキング(任意選択)。
セグメントFsは、プレーヤへの配信メカニズムを使用して配信される。
ファイルエンカプスレータが出力するファイル(F)は、ファイルデカプスレータが入力するファイル(F’)と同一である。ファイルデカプスレータは、ファイル(F’)または受け取ったセグメント(F’s)を処理し、コード化ビットストリーム(E’a、E’v、および/またはE’i)を抽出し、メタデータをパースする。オーディオ、ビデオ、および/または画像は、次に、デコードされた信号(オーディオのためのB’a、およびイメージ/ビデオのためのD’)にデコードされる。デコードされたパック画像(D’)は、現在鑑賞方向またはビューポート、ならびに、ファイルからパースされた投影、球体カバレッジ、投影構造方向、および領域単位パッキングメタデータに基づいて、ヘッドマウントディスプレイまたは他の任意の表示デバイスの画面に投影される。同様に、デコードされたオーディオ(B’a)は、現在鑑賞方向に応じて、例えばヘッドホンを通じて、レンダリングされる。現在鑑賞方向は、ヘッドトラッキングによって、および、また、場合によっては、視線追跡機能によって判定される。デコードされたビデオおよびオーディオ信号の適切な部分をレンダリングするためのレンダラによって使用されるのに加えて、現在鑑賞方向は、デコード最適化のためにビデオおよびオーディオデコーダによっても使用され得る。
上記で説明した処理は、ライブユースケースとオンデマンドユースケースの両方に適用可能である。
人間の目は、360度空間全体を鑑賞することができず、最大水平および垂直FoV(HHFoV、HVFoV)に限定される。また、HMDデバイスには、水平および垂直方向の360度空間全体のサブセット(DHFoV、DVFoV)を鑑賞することしかできないという技術的限界がある。
任意の時点で、HMD上のアプリケーションでレンダリングされたビデオが、360度ビデオの一部をレンダリングする。この部分は、ここでは、ビューポートと定義される。ビューポートは、レンダリングディスプレイによって表示された全方向ビデオ内に表された360世界上のウィンドウである。ビューポートは、代替として、表示およびユーザによる鑑賞に適した全方向イメージまたはビデオの領域と定義することができる。
ビューポートサイズは、HMDの視野に対応させることができるか、またはアプリケーションに応じて、より小さいサイズを保持することもできる。分かりやすくするために、任意の所与の時点にユーザが鑑賞する360度空間の一部を、1次ビューポートと定義する。
OMAFの座標系は、ユニット球体、および3つの座標軸、すなわち、X(後ろから前の)軸、Y(横方向、片側から片側の)軸、およびZ(垂直、上方への)軸からなり、ここで、3つの軸は、球体の中心で交差する。球体上の点の位置は、1組の球体座標の方位(φ)および高度(θ)で識別される。図8は、X、Y、およびZ座標軸と、球体座標の方位(φ)および高度(θ)との関係を指定する。
鑑賞方向は、ユーザが視聴覚コンテンツを利用する方向を特徴付ける、イメージまたはビデオの場合、ビューポートの方向を特徴付ける、方位、高度、および傾き角の三重項と定義することができる。
図9は、球体画像から、コンテンツオーサリングで使用できるパック画像へのコンバージョン、および、パック画像から、OMAFプレーヤで使用できるレンダリングされることになる球体画像への対応するコンバージョンを示す。この節における例は、投影された全方向ビデオトラック内に現れるパック画像について説明される。同様の説明をイメージアイテムのために導出することができる。
コンテンツオーサリングは、以下の順序のステップを含むことができる。
- 入力として提供されるソース画像は、a)に示されたように、グローバル座標軸ごとにユニット球体上の球体画像を生成するためにステッチされる。
- ユニット球体は、次に、b)に示されたように、グローバル座標軸に対して回転される。ローカル座標軸からグローバル座標軸にコンバートするための回転の量は、RotationBoxで示された回転角で指定される。ユニット球体のローカル座標軸は、回転させた座標系の軸である。RotationBoxがないのは、ローカル座標軸がグローバル座標軸と同じであることを示す。
- c)に示したように、回転させたユニット球体上の球体画像は、次に、例えばエクイレクタングラ投影を使用して、2次元投影画像にコンバートされる。立体コンテンツの空間パッキングが適用されるとき、2つのビューのための2つの球体画像は、2つの成分画像にコンバートされ、その後、2つの成分画像を1つの投影画像にパッキングするために、フレームパッキングが適用される。
- 長方形領域単位パッキングは、投影画像からパック画像を取得するために適用することができる。パッキングの1つの例が、c)およびd)に描写されている。c)における破線の長方形は、投影画像の上に投影領域を示し、d)におけるそれぞれのエリアは、対応するパック領域を示す。この例では、投影領域1および3は、水平にダウンサンプリングされるが、投影領域2は、その元の解像度で保たれる。
CoverageInformationBoxは、コンテンツカバレッジ、すなわち、球体のどの部分がパック画像でカバーされるかを、示すために使用することができる。
a)に示された、レンダリングで使用されるユニット球体に、d)におけるものなどの、パック画像のサンプル位置をマップするために、OMAFプレーヤは、以下の順序のステップを実施することができる。
- d)におけるものなどのパック画像は、ビデオトラックまたはイメージアイテムからの画像のデコードの結果として取得される。
- 必要なら、パック画像の彩度サンプル配列は、パック画像の輝度サンプル配列の解像度にアップサンプリングされ、色空間コンバージョンも実施することができる。
- 領域単位パッキングが示される場合、パック画像のサンプル位置は、c)におけるものなどの、それぞれの投影画像のサンプル位置にコンバートされる。そうでなければ、投影画像は、パック画像と同一である。
- 投影画像の空間フレームパッキングが示される場合、投影画像のサンプル位置は、投影画像のそれぞれの成分画像のサンプル位置にコンバートされる。そうでなければ、投影画像の成分画像は、投影画像と同一である。
- 投影画像の成分画像のサンプル位置は、使用されている全方向投影フォーマットに指定されるような、ローカル座標軸に対する球体座標にコンバートされる。結果として生じるサンプル位置は、b)に描写された球体画像に対応する。
- 回転が示される場合、ローカル座標軸に対する球体座標は、グローバル座標軸に対する球体座標にコンバートされる。そうでなければ、グローバル座標軸は、ローカル座標軸と同一である。
タイルまたはサブ画像トラックまたは同様のもののメタデータをシグナリングするために、任意の既知の方法を使用することができる。例えば、領域単位パッキングボックス、および/または、2Dもしくは球体領域単位品質ランキングボックスが、360°ビデオの各タイルまたはサブ画像トラックのために存在してもよい。別の例では、メタデータが、容積測定ビデオの各タイルまたはサブ画像トラックのために存在してもよい。
領域単位品質ランキングメタデータが、ビデオまたはイメージビットストリーム内に、またはとともに存在してもよい。品質ランキング領域の品質ランキング値は、同じビットストリームもしくは同じトラックの他の品質ランキング領域、または、他のトラックの品質ランキング領域に関するものであってもよい。領域単位品質ランキングメタデータは、MPEG全方向メディアフォーマットの一部として指定される、例えばSphereRegionQualityRankingBoxまたは2DRegionQualityRankingBoxを使用することによって、示すことができる。SphereRegionQualityRankingBoxは、球体領域、すなわち、球体ドメイン上で定義された領域に関する品質ランキング値を提供し、一方で、2DRegionQualityRankingBoxは、デコード画像上の長方形領域(および潜在的に、長方形領域のどれにもカバーされない全てのエリアをカバーする残余領域)に関する品質ランキング値を提供する。品質ランキング値は、品質ランキング領域の相対品質順を示す。品質ランキング領域Aが、品質ランキング領域Bの値より小さいゼロ以外の品質ランキング値を保持するとき、品質ランキング領域Aは、品質ランキング領域Bより品質が高い。品質ランキング値がゼロ以外のとき、示された品質ランキング領域全体の中の画像品質は、ほぼ不変であると定義することができる。一般に、品質ランキング球体または2D領域の境界は、領域単位パッキングメタデータにおいて指定された、パック領域の境界、または投影領域の境界と一致してもまたはしなくてもよい。
H.264/AVCおよびHEVCのためのISO/IEC14496-15で指定されたエクストラクタは、参照によりNALユニットデータを抽出するトラックのコンパクトなフォーメーションを可能にする。エクストラクタは、NALユニットのような構造である。NALユニットのような構造は、任意のNALユニットのようなNALユニットヘッダおよびNALユニットペイロードを含めるために指定することができるが、(NALユニットに必要な)スタートコードエミュレーション防止が、NALユニットのような構造に採用されていない可能性がある。HEVCについて、エクストラクタは、1つまたは複数のコンストラクタを収める。サンプルコンストラクタは、別のトラックのサンプルから、NALユニットデータを参照により抽出する。直列コンストラクタは、NALユニットデータを含む。エクストラクタを必要とするファイルリーダによってエクストラクタが処理されるとき、エクストラクタは、収められたコンストラクタをその出現順に分解するときに生じるバイトで論理的に置き替えられる。ネストされた抽出が許可されることはなく、例えば、サンプルコンストラクタによって参照されるバイトは、エクストラクタを収めず、エクストラクタは、別のエクストラクタを直接的または間接的に参照しない。エクストラクタは、タイプ「scal」のトラック参照によって、現在のトラックから、または、エクストラクタが常駐するトラックにリンクされた別のトラックから、データを抽出するための1つまたは複数のコンストラクタを収めることができる。
分解されたエクストラクタのバイトは、以下の1つである。
a)1つの全体NALユニット。アグリゲータが参照されるとき、含まれるバイトと参照されるバイトの両方がコピーされることに留意されたい。
b)2つ以上の全体NALユニット。
両方のケースで、分解されたエクストラクタのバイトは、有効長さフィールドおよびNALユニットヘッダで始まる。
サンプルコンストラクタのバイトは、示された「scal」トラック参照を通じて参照されたトラック内の単一の識別されたサンプルからのみコピーされる。適合は、サンプル番号でカウントしたオフセットが後に続く、デコード時間についてのもの、すなわち、時間対サンプルテーブルのみを使用することである。エクストラクタは、メディアレベルの概念であり、したがって、いずれかの編集リストを考慮する前に、宛先トラックに適用される。(それでも、通常、2つのトラック内の編集リストが同一であると予期される)。
以下のシンタックスを使用することができる。
class aligned(8) Extractor () {
NALUnitHeader();
do {
unsigned int(8) constructor_type;
if( constructor_type == 0 )
SampleConstructor();
else if( constructor_type == 2 )
InlineConstructor();
} while( !EndOfNALUnit() )
}
セマンティックスは、以下のように定義することができる。
- NALUnitHeader():HEVC NALユニットの最初の2バイト。例えば、49に等しいnal_unit_typeといった、特定のnal_unit_type値が、エクストラクタを示す。
- constructor_typeは、使用されているコンストラクタを指定する。
- EndOfNALUnit()は、より多くのデータがこのエクストラクタ内で続くとき0(偽)を返し、そうでなければ、1(真)を返す関数である。
サンプルコンストラクタ(SampleConstructor)は、以下のシンタックスを含むことができる。
class aligned(8) SampleConstructor () {
unsigned int(8) track_ref_index;
signed int(8) sample_offset;
unsigned int((lengthSizeMinusOne+1)*8)
data_offset;
unsigned int((lengthSizeMinusOne+1)*8)
data_length;
}
track_ref_indexは、データを抽出するソーストラックを識別する。track_ref_indexは、タイプ「scal」のトラック参照のインデックスである。第1のトラック参照は、インデックス値1を保持し、値0は予約される。
データが抽出されるこのトラック内のサンプルは、時間的に適合されるか、またはメディアデコードタイムライン内の前の最も近くにある、すなわち、時間対サンプルテーブルだけを使用して、サンプルがエクストラクタを収めるsample_offsetによって指定されたオフセットによって調節される。sample_offsetは、情報の出所として使用されることになるリンクしたトラック内のサンプルの相対インデックスを与える。サンプル0(ゼロ)は、エクストラクタを収めるサンプルのデコード時間と比較して、同じ、または前の最も近くにあるデコード時間を伴うサンプルであり、サンプル1(1)は、次のサンプルであり、サンプル-1(マイナス1)は、前のサンプルである、などである。
data_offset:コピーすることになる参照サンプル内の第1のバイトのオフセット。抽出が、このサンプル内のデータの第1のバイトで始まる場合、オフセットは値0をとる。
data_length:コピーすることになるバイト数。
直列コンストラクタのシンタックスは、以下のように指定することができる。
class aligned(8) InlineConstructor () {
unsigned int(8) length;
unsigned int(8) inline_data[length];
}
length:このフィールドの後にあるInlineConstructorに属すバイト数。
inline_data:直列コンストラクタを分解したときに返されることになるデータバイト。
ISO/IEC14496-15で指定されたタイルトラックは、1つまたは複数の時間的な運動制約タイルセットをトラックとして格納することを可能にする。タイルトラックが、HEVCベースレイヤのタイルを収めるとき、サンプルエントリタイプ「hvt1」が使用される。タイルトラックが、非ベースレイヤのタイルを収めるとき、サンプルエントリタイプ「lht1」が使用される。タイルトラックのサンプルは、1つまたは複数の完全なスライスセグメント内の1つまたは複数の完全なタイルからなる。タイルトラックは、このタイルトラックと同じレイヤのVCL NALユニットを含む他のどのタイルトラックからも独立している。タイルトラックは、タイルベーストラックへの「tbas」トラック参照を行う。タイルベーストラックは、VCL NALユニットを含まない。タイルベーストラックは、タイルトラックへの「sabt」トラック参照を使用して並べたタイルを示す。タイルベーストラック内のサンプルに対応するHEVCコード化画像は、トラック参照順で、「sabt」トラック参照によって示されたトラックの時間適合したサンプルからコード化データを収集することによって再構築することができる。したがって、参照により参照されるタイルトラックのコード化ビデオデータをタイルベーストラックが含むことがわかる。
サブ画像は、コンテンツ制作側でのビデオエンコーディングの前に空間サブセットに分けられた、元のビデオコンテンツの空間サブセットを表す画像と定義することができる。サブイメージビットストリームは、コンテンツ制作側でのビデオエンコーディングの前に空間サブセットに分けられた、元のビデオコンテンツの空間サブセットを表すビットストリームと定義することができる。サブ画像トラックは、同じ元のビデオコンテンツから生じた他のトラックへの空間的な関係を伴い、サブイメージビットストリームを表す、トラックと定義することができる。サブ画像トラックは、ISO/IEC14496-15におけるHEVCのために定義された「hvc1」または「hev1」などの、従来のトラックフォーマットに適合する。サブ画像トラックを生成するためのアプローチでは、ソース画像シーケンスは、エンコーディングの前にサブ画像シーケンスに分けられる。サブ画像シーケンスは、次に、HEVCメインプロフィールビットストリームなどの、単一レイヤビットストリームとして、他のサブ画像シーケンスから独立してエンコードされる。コード化された単一レイヤビットストリームは、サブ画像トラックにカプセル化される。サブ画像トラックのためのビットストリームは、後で定義されるように、運動制約画像でエンコードすることができる。サブ画像トラックを生成するための別のアプローチでは、ソース画像シーケンスは、運動制約タイルセットでビットストリームにエンコードされ、MCTSシーケンスは、ビットストリームから抽出され、サブ画像トラックは、例えばスライスヘッダ修正を通じて、適合するビットストリームにMCTSシーケンスをコンバートすること、および、生成されたビットストリームをトラックにカプセル化することによって生成される。このように生成されたサブ画像トラックは、運動制約画像を含む。
コレクタトラックは、他のトラックからMCTSまたはサブ画像を暗示的または明示的に抽出するトラックと定義することができる。ファイルリーダによって分解されると、コレクタトラックは、HEVCまたはH.266/VVCなどの、ビデオコーデック仕様に適合するビットストリームを表すことができる。コレクタトラックは、例えば、コード化画像シーケンスを形成するために、MCTSまたはサブ画像を抽出することができ、ここで、MCTSまたはサブ画像は、グリッドに配置される。例えば、コレクタトラックが2つのMCTSまたはサブ画像を抽出するとき、これらは、MCTSまたはサブ画像の2×1グリッドに配置することができる。タイルベーストラックは、コレクタトラックとみなすことができ、他のトラックからMCTSまたはサブ画像を抽出するエクストラクタトラックは、コレクタトラックとみなすことができる。コレクタトラックは、コレクショントラックとさらに呼ぶことができる。コレクタトラックを抽出するための出所であるトラックは、コレクションアイテムトラックと呼ぶことができる。
過度の数のエクストラクタトラックを作り出さないようにするために(例えば、高解像度タイルと低解像度タイルとのそれぞれの組合せのためのエクストラクタトラックを作り出さないようにするために)、抽出のための代替であるトラックは、以下で説明されるメカニズムでグループ化することができる。同様に、同じコンテンツの異なるビットレートバージョンを表す一緒に並べられたタイルトラックに対して、同じタイルベーストラックを使用できるようにするために、以下のメカニズムを使用することができる。
ファイルライタは、例えば「alte」トラックグループと呼ばれるトラックグループが、抽出のための出所として使用されることになる代替であるトラックを収めることをファイル内で示す。
「alte」グループについての識別子は、トラックについての識別子と同じ番号を付けた空間からとることができる。言い換えれば、「alte」グループについての識別子は、トラック識別子の値全てとは異なることが必要になることがある。必然的に、「alte」トラックグループ識別子は、トラック識別子が従来使用される場所で使用することができる。特に、「alte」トラックグループ識別子は、抽出のための出所を示すトラック参照として使用することができる。
このボックスによって形成されたトラックグループのメンバは、抽出のための出所として使用されることになる代替である。「alte」に等しいtrack_group_typeを伴うトラックグループのメンバは、「scal」または「sabt」トラック参照のための出所として使用されることになる代替である。Track_ref_4ccに等しいreference_typeのTrackReferenceTypeBoxは、トラックID値に加えて、またはトラックID値の代わりに、同じalte_track_ref_4cc値を収める「alte」トラックグループのtrack_group_id値をリストアップすることができる。例えば、エクストラクタトラックは、「scal」トラック参照を通じて、個々のトラックに加えて、または個々のトラックの代わりに、「alte」トラックグループを指すことができる。「alte」トラックグループの任意の単一のトラックが、抽出に適した出所である。抽出のためのソーストラックは、同期サンプル、またはタイプ1もしくは2のSAPサンプルを、切り替えられたトラックが保持する位置において変化してもよい。
ユニフォームリソースアイデンティファイア(URI:uniform resource identifier)は、リソースの名前を識別するために使用されるキャラクタの文字列と定義することができる。このような識別は、特定のプロトコルを使用した、ネットワークでのリソースの表現との相互作用を可能にする。URIは、URIのための具体的なシンタックスおよび関連付けられたプロトコルを指定する方式を通じて定義される。ユニフォームリソースロケータ(URL:uniform resource locator)およびユニフォームリソースネーム(URN:uniform resource name)は、URIの形式である。URLは、ウェブリソースを識別し、リソースの表現に作用する、またはリソースの表現を取得する手段を指定するURIと定義することができ、リソースの主要なアクセスメカニズムとネットワーク位置の両方を指定する。URNは、特定の名前空間における名前でリソースを識別するURIと定義することができる。URNは、リソースの位置、またはリソースにアクセスするやり方を示唆することなく、リソースを識別するために使用することができる。
多くのビデオ通信または伝送システム、トランスポートメカニズム、およびマルチメディアコンテナファイルフォーマットが、異なるトラックまたはセッションなどについての別個の論理チャネルのコード化データを互いに関連付けるための手段を提供する。例えば、同じアクセスユニットのコード化データを一緒に関連付けるためのメカニズムがある。例えば、デコード時間または出力時間は、コンテナファイルフォーマットまたはトランスポートメカニズムで提供することができ、同じデコード時間または出力時間を伴うコード化データは、アクセスユニットを形成するとみなすことができる。
最近、ハイパーテキストトランスファプロトコル(HTTP:Hypertext Transfer Protocol)が、ビデオストリーミングアプリケーションにおいてなど、インターネットでのリアルタイムマルチメディアコンテンツの配信のために広く使用されてきた。ユーザデータグラムプロトコル(UDP)でのリアルタイムトランスポートプロトコル(RTP)の使用と異なり、HTTPは構成しやすく、典型的には、ファイアウォールおよびネットワークアドレストランスレータ(NAT)の横断を許可され、これは、マルチメディアストリーミングアプリケーションにとって魅力的にする。
標準化プロジェクトが実行されてきただけでなく、Microsoft(R)Smooth Streaming、Apple(R)Adaptive HTTP Live Streaming、およびAdobe(R)Dynamic Streamingなどの、HTTPでのアダプティブストリーミングのためのいくつかの市販のソリューションも売り出されてきた。第3世代パートナーシッププロジェクト(3GPP)パケット交換型ストリーミング(PSS)サービスのリリース9(3GPP TS26.234リリース9:「Transparent end-to-end packet-switched streaming service (PSS);protocols and codecs」)で、アダプティブHTTPストリーミング(AHS)が最初に標準化された。MPEGは、MPEG DASH規格(ISO/IEC23009-1:「Dynamic adaptive streaming over HTTP(DASH)-Part 1: Media presentation description and segment formats」、国際規格、第2版、2014年)のための出発点として、3GPP AHSリリース9を利用した。3GPPは、MPEGと通信するアダプティブHTTPストリーミングに取り組み続け、3GP-DASH(Dynamic Adaptive Streaming over HTTP;3GPP TS26.247:「Transparent end-to-end packet-switched streaming Service(PSS);Progressive download and dynamic adaptive Streaming over HTTP(3GP-DASH)」を公開した。MPEG DASHおよび3GP-DASHは、互いに技術的に近く、したがって、一括して、DASHと呼ぶことができる。MPEG-DASHと同様のストリーミングシステムは、IETF RFC8216で指定された、例えばHTTP Live Streaming(別名HLS)を含む。実施形態を実行できるビデオストリーミングシステムの例を全て提供する、前記アダプティブストリーミングシステムの詳細な説明のために、上記の標準ドキュメントを参照する。本発明の態様は、上記の標準ドキュメントに限定されず、むしろ、本発明を部分的にまたは完全に実現できることに加えて、1つの可能な基礎について説明される。
DASHでは、マルチメディアコンテンツは、HTTPサーバに格納することができ、HTTPを使用して配信することができる。コンテンツは、利用可能コンテンツの目録、コンテンツの様々な代替、代替のURLアドレス、および他の特性を記述するメディアプレゼンテーションディスクリプション(MPD)、ならびに、単一のまたは複数のファイルにチャンクの形の実際のマルチメディアビットストリームを収めるセグメント、という2つの部分でサーバに格納することができる。MDPは、HTTPでダイナミックアダプティブストリーミングをクライアントが確立するのに必要な情報を提供する。MPDは、GETセグメントリクエストを行うための、各セグメントのHTTP-ユニフォームリソースロケータ(URL)などの、メディアプレゼンテーションを記述する情報を収める。コンテンツを再生するために、DASHクライアントは、例えば、HTTP、eメール、サムドライブ、ブロードキャスト、または他のトランスポート方法を使用することによって、MPDを取得することができる。MPDをパースすることによって、DASHクライアントは、プログラムタイミング、メディアコンテンツ可用性、メディアタイプ、解像度、最小および最大帯域幅、ならびに、マルチメディア構成要素の様々なエンコードされた代替の存在、アクセシビリティ特徴および必要なデジタル著作権管理(DRM)、ネットワーク上のメディアコンポーネントロケーション、ならびに他のコンテンツ特性を認識するようになることができる。この情報を使用して、DASHクライアントは、適切なエンコードされた代替を選択し、例えばHTTP GETリクエストを使用してセグメントをフェッチすることによって、コンテンツをストリームし始めることができる。ネットワークスループットの変化を可能にするための適切なバッファリングの後、クライアントは、その後のセグメントをフェッチし続け、ネットワーク帯域幅の変動をさらに監視することができる。クライアントは、十分なバッファを維持するために、(より低い、または、より高いビットレートで)異なる代替のセグメントをフェッチすることによって、利用可能な帯域幅にどのように適合させるべきかを決めることができる。
DASHの文脈では、以下の定義を使用することができる。メディアコンテンツ構成要素またはメディア構成要素は、メディアストリームに個別にエンコードすることができる、割り当てられたメディア構成要素タイプを伴うメディアコンテンツの1つの連続構成要素と定義することができる。メディアコンテンツは、1つのメディアコンテンツ期間、またはメディアコンテンツ期間の連続シーケンスと定義することができる。メディアコンテンツ構成要素タイプは、オーディオ、ビデオ、またはテキストなどの、メディアコンテンツの単一のタイプと定義することができる。メディアストリームは、メディアコンテンツ構成要素のエンコードバージョンと定義することができる。
DASHでは、以下のようにメディアプレゼンテーションを構造化するために、階層型データモデルが使用される。メディアプレゼンテーションは、1つまたは複数の期間のシーケンスからなり、各期間は、1つまたは複数のグループを収め、各グループは、1つまたは複数の適合セットを収め、各適合セットは、1つまたは複数の表現を収め、各表現は、1つまたは複数のセグメントからなる。グループは、同時に提示されることが期待されない適合セットのコレクションと定義することができる。適合セットは、1つまたはいくつかのメディアコンテンツ構成要素の入替え可能なエンコードバージョンのセットと定義することができる。表現は、エンコード選択肢ごと、例えば、ビットレート、解像度、言語、コーデック等によって典型的に異なるメディアコンテンツまたはそのサブセットの代替選択肢の1つである。セグメントは、一定期間のメディアデータ、および含まれるメディアコンテンツをデコードし、提示するためのメタデータを収める。セグメントは、URIによって識別され、典型的には、HTTP GETリクエストでリクエストすることができる。セグメントは、HTTP-URLに関連付けられたデータの1つの単位、および任意選択として、MPDによって指定されたバイト範囲と定義することができる。
初期化セグメントは、メディアセグメント内にカプセル化されたメディアストリームを提示するのに必要なメタデータを収めるセグメントと定義することができる。ISOBMFFベースのセグメントフォーマットでは、初期化セグメントは、任意のサンプルのためのメタデータを含まないことがあるムービーボックス(「moov」)を含むことができ、すなわち、サンプルのための任意のメタデータは、「moof」ボックス内で提供される。
メディアセグメントは、通常のスピードでの再生のための一定期間のメディアデータを収め、このような期間は、メディアセグメント期間またはセグメント期間と呼ばれる。コンテンツ制作者またはサービスプロバイダは、サービスの所望の特性に応じてセグメント期間を選択することができる。例えば、短い終端間レイテンシを達成するために、ライブサービスでは、比較的短いセグメント期間を使用することができる。なぜなら、セグメント期間は、典型的には、セグメントがDASHのためのメディアデータの生成の個別のユニットであるので、DASHクライアントによって知覚される終端間レイテンシの下限であるからである。コンテンツ生成は、典型的には、メディアデータの全セグメントをサーバが利用できるような手法で行われる。さらに、多くのクライアント実装形態が、GETリクエストのためのユニットとしてセグメントを使用する。このように、ライブサービスのための典型的な配置では、メディアセグメントの全期間を利用でき、エンコードして、セグメントにカプセル化できるときだけ、DASHクライアントによってセグメントをリクエストすることができる。オンデマンドサービスについては、セグメント期間の選択についての種々の戦略を使用することができる。
例えば、複数の部分でセグメントをダウンロードできるようにするために、セグメントをサブセグメントに、さらに区画化することができる。サブセグメントは、完全なアクセスユニットを収めるために必要になることがある。サブセグメントは、各サブセグメントについてのプレゼンテーション時間範囲とバイト範囲をマップするための情報を収めるセグメントインデックスボックスによってインデックスを付けることができる。セグメントインデックスボックスは、セグメントの期間およびバイトオフセットをシグナリングすることによって、セグメント内のサブセグメントおよびストリームアクセスポイントも記述することができる。DASHクライアントは、バイト範囲HTTPリクエストを使用して特定のサブセグメントのためのHTTP GETリクエストを行うために、セグメントインデックスボックスから取得した情報を使用することができる。比較的長いセグメント期間が使用される場合、サブセグメントは、ビットレート適合に対して適度かつ柔軟なHTTPレスポンスのサイズを保つために使用することができる。セグメントのインデックス情報は、このセグメントの始めの単一のボックス内に置くこと、または、セグメント内の多くのインデックス付けしたボックスの間に拡散させることができる。階層型、デイジーチェーン、およびハイブリッド型など、拡散についての種々の方法が可能である。この技法は、セグメントの始めに大きいボックスを追加するのを避けることができ、したがって、可能性のある初期ダウンロード遅延を防ぐことができる。
上記に説明したように、DASHおよび他の同様のストリーミングシステムは、マルチメディアストリーミングアプリケーションのためのプロトコルおよび/またはフォーマットを提供する。VRビデオのストリーミングビットレートを低減させるためのストリーミングにおける最近の傾向は、ビューポート依存型配信と呼ぶことができ、以下のように説明することができる。1次ビューポート(すなわち、現在の鑑賞方向)をカバーする360度ビデオコンテンツのサブセットは、最高の品質/解像度で伝送され、一方で、360度ビデオの残りは、より低い品質/解像度で伝送される。
ビューポート対応ストリーミングは、タイルベースのエンコーディングおよびストリーミングアプローチを通じて実現することができる。これらのアプローチでは、360度コンテンツは、種々のエンコーディングからのビューポートの選択的なストリーミングを可能にする手法でエンコードされ、利用可能になる。
ビューポート固有エンコーディング/パッキングでは、360度イメージコンテンツは、1次ビューポートに重点(例えば、より大きい空間的エリア)を置いた同じフレームにパッキングされる。コンテンツのいくつかのバージョンは、異なる1次ビューポート方向および/またはFOVのために作り出される。ビューポート固有エンコーディング/パッキングは、非対称投影(別名、ビューポート依存型投影)を通じて達成することができ、ビューポートエリアは、最大サンプリング密度でエンコードされ、残りの360シーンは、ビューポートエリアから非ビューポートエリアへとサンプリング密度が徐々に減少する方式で投影される。再投影された非ビューポートエリアは、ビューポートエリアと同じイメージ平面にパッキングされる。領域単位混合品質アプローチでは、ビューポートエリアは、最高画像品質でエンコードされ、一方で、他のエリアは、より低い品質でエンコードされる。領域単位混合解像度アプローチでは、ビューポート独立型投影が適用され、投影される2D画像は、ビューポートが最高2D解像度から生じ、他のエリアがより低い2D解像度から生じるという手法で、投影される2D画像のエンコーディングの前に領域単位にリサンプリングされる。
タイルベースのビューポート依存型ストリーミングアプローチでは、投影画像は、運動制約タイルセット(MCTS)としてコード化されたタイルに区画化される。タイルベースのビューポート対応ストリーミング方式は、以下のようにカテゴライズすることができる。
- 領域単位混合品質(RWMQ)360°ビデオ:コンテンツのいくつかのバージョンは、同じタイルグリッド上のMCTSを使用してエンコードされ、各バージョンは、異なるビットレートおよび画像品質を伴う。プレーヤは、ビューポートをカバーするMCTSの品質が、他の受け取ったMCTSの品質より高くなるように、どのバージョンを受け取るかをMCTSベースで選択する。
- ビューポート+360°ビデオ:ビューポートをカバーする完全低解像度全方向画像および高解像度タイルのためのMCTSを受け取る。
- 領域単位混合解像度(RWMR)360°ビデオ:タイルは複数の解像度でエンコードされる。プレーヤは、ビューポートをカバーする高解像度タイルと、残りのエリアのための低解像度タイルとの組合せを選択する。
クライアント主導ビットストリームリライティングまたはエクストラクタ主導サブ画像マージングが使用中であるかどうかに関わらず、これら全てのアプローチを適用できることに留意されたい。さらに、これら全てのアプローチでは、タイル(または、その保護帯域)は、事前処理またはエンコーディング時に選択された量だけ重複してもよい。
全ての上述のビューポート依存型ストリーミングアプローチは、クライアント主導ビットストリームリライティング(別名、レイトバインディング)で、または、作者主導MCTSマージング(別名、アーリーバインディング)で、実現することができる。レイトバインディングでは、プレーヤは、受け取ることになるMCTSシーケンスを選択し、受け取ったMCTSを単一のビットストリームに組み合わせるために、受け取ったビデオデータの一部を必要に応じて選択的に書き換え(例えば、パラメータセットおよびスライスセグメントヘッダを書き換える必要があることがある)、単一のビットストリームをデコードする。アーリーバインディングは、受け取ったビデオデータの一部を必要に応じて書き換えるため、デコードされることになる単一のビットストリームにMCTSをマージするため、および場合によっては、受け取ることになるMCTSシーケンスの選択のための、作者主導情報の使用を指す。初期およびレイトバインディングとの間のアプローチが存在し得る。例えば、作者が誘導することなく、受け取ることになるMCTSシーケンスをプレーヤに選択させることができる可能性がある一方で、作者主導アプローチは、MCTSマージングおよびヘッダリライティングのために使用される。アーリーバインディングアプローチは、エクストラクタ主導アプローチおよびタイルトラックアプローチを含み、これらは、後で説明する。
タイルトラックアプローチでは、1つまたは複数の運動制約タイルセットシーケンスがビットストリームから抽出され、各抽出された運動制約タイルセットシーケンスは、タイルトラック(例えば、HEVCタイルトラック)としてファイルに格納される。タイルベーストラック(例えば、HEVCタイルベーストラック)を生成し、ファイルに格納することができる。タイルベーストラックは、タイルトラックから運動制約タイルセットを暗示的に収集することによってビットストリームを表す。レシーバ側では、ストリームされることになるタイルトラックは、鑑賞方向に基づいて選択することができる。クライアントは、全方向コンテンツ全体をカバーするタイルトラックを受け取ることができる。残りの360度ビデオをカバーする品質または解像度と比較して、より良い品質またはより高い解像度タイルトラックを、現在のビューポートのために受け取ることができる。タイルベーストラックは、タイルトラックへのトラック参照を含むことができ、および/または、タイルトラックは、タイルベーストラックへのトラック参照を含むことができる。例えば、HEVCでは、タイルベーストラックからタイルトラックを参照するために使用される「sabt」トラック参照が使用され、タイル順は、「sabt」トラック参照によって収められたタイルトラックの順序で示される。さらに、HEVCでは、タイルトラックは、タイルベーストラックへの「tbas」トラック参照を保持する。
エクストラクタ主導アプローチでは、1つまたは複数の運動制約タイルセットシーケンスがビットストリームから抽出され、各抽出された運動制約タイルセットシーケンスは、独自の準拠したビットストリーム(例えば、HEVCビットストリーム)になるように修正され、(例えば、HEVCのための変換されないサンプルエントリタイプ「hvc1」を伴う)サブ画像トラックとしてファイルに格納される。1つまたは複数のエクストラクタトラック(例えば、HEVCエクストラクタトラック)を生成し、ファイルに格納することができる。エクストラクタトラックは、サブ画像トラックから運動制約タイルセットを(例えば、HEVCエクストラクタによって)明示的に抽出することによってビットストリームを表す。レシーバ側では、ストリームされることになるサブ画像トラックは、鑑賞方向に基づいて選択することができる。クライアントは、全方向コンテンツ全体をカバーするサブ画像トラックを受け取ることができる。残りの360度ビデオをカバーする品質または解像度と比較して、より良い品質またはより高い解像度のサブ画像トラックを、現在のビューポートのために受け取ることができる。
特にHEVCの文脈で、タイルトラックアプローチおよびエクストラクタ主導アプローチが詳細に説明されているとはいえ、これらは、他のコーデック、および、タイルトラックまたはエクストラクタと同様の概念に適用されることを理解する必要がある。その上、タイルトラックとエクストラクタ主導アプローチとの組合せまたは混合が可能である。例えば、このような混合は、タイルトラックアプローチに基づくことができるが、タイルベーストラックは、クライアントのための書換え動作のためのガイダンスを収めることができ、例えば、タイルベーストラックは、書き換えられたスライスまたはタイルグループヘッダを含むことができる。
MCTSベースのコンテンツエンコーディングに対する代替として、タイルベースのビューポート依存型ストリーミングのためのコンテンツオーサリングを、以下のように説明される、サブ画像ベースのコンテンツオーサリングを用いて実現することができる。(エンコード前の)事前処理は、非圧縮画像をサブ画像に区画化することを含む。同じ非圧縮サブ画像シーケンスのいくつかのサブ画像ビットストリームは、例えば、同じ解像度だが、異なる品質およびビットレートで、エンコードされる。エンコーディングは、全方向ビデオを表す準拠したビットストリームへのコード化されたサブイメージビットストリームのマージを可能にする手法で制約することができる。例えば、画像の外側にあるサンプル位置がインター予測処理で参照されない手法で運動ベクトルを選択することによって、デコード画像境界の外側にあるサンプルへの依存をエンコード時に避けることができる。各サブ画像ビットストリームは、サブ画像トラックとしてカプセル化することができ、異なるサブ画像位置のサブ画像トラックをマージする1つまたは複数のエクストラクタトラックを追加として形成することができる。タイルトラックベースのアプローチを対象とする場合、各サブ画像ビットストリームは、MCTSシーケンスになるように修正されて、タイルトラックとしてファイルに格納され、1つまたは複数のタイルベーストラックが、タイルトラックのために作り出される。
タイルベースのビューポート依存型ストリーミングアプローチは、例えばプレーヤが動かすデバイスおよびオペレーティングシステムの能力に応じて、MCTSシーケンスごとに単一のデコーダインスタンスもしくは1つのデコーダインスタンス(または場合によっては、間の何か、例えば、同じ解像度のMCTSごとに1つのデコーダインスタンス)を実行することによって実現することができる。単一のデコーダインスタンスの使用は、レイトバインディングまたはアーリーバインディングによって可能にすることができる。複数のデコーダインスタンスを容易にするために、エクストラクタ主導アプローチは、修正することなく、コーディングフォーマットまたは規格に準拠したサブ画像トラックを使用することができる。他のアプローチは、適合ビットストリームを構築するために、イメージセグメントヘッダ、パラメータセット、および/もしくは同様の情報をクライアント側で書き換えること、または、他のコード化ビデオデータが存在しなくてもMCTSシーケンスをデコードすることができるデコーダ実装形態を保持すること、を行う必要がある可能性がある。
タイルトラックアプローチおよびエクストラクタ主導アプローチそれぞれで、タイルトラックまたはサブ画像トラックをカプセル化し、参照するための少なくとも2つのアプローチがあり得る。
- タイルベーストラックまたはエクストラクタトラックからトラック識別子を参照すること。
○ タイルトラックアプローチについて、各ビットストリームのタイルトラックおよびタイルベーストラックを独自のファイルにカプセル化することができ、同じトラック識別子を(例えば、同じコンテンツの異なるビットレートバージョンを表す)全てのファイルで使用する。言い換えれば、同じトラック識別子の値は、これら全てのファイルで同じタイルグリッド位置の各タイルトラックに対して使用される。このように、タイルベーストラックは、全てのファイルで同一であり、一緒に並べられたタイルトラックのいずれか1つを受け取ることができる。
○ エクストラクタ主導アプローチについて、同じ解像度だが異なるビットレートの同じコンテンツのサブ画像トラックのそれぞれを、独自のファイル内にカプセル化することができ、同じトラック識別子を(例えば、同じコンテンツの異なるビットレートバージョンを表す)全てのファイルで使用することができ、したがって、エクストラクタトラックからのトラック参照は、受け取ったサブ画像トラックのいずれかのビットレートバージョンに正しく分解する。
- タイルベーストラックまたはエクストラクタトラックからタイルグループ識別子を参照すること。いくつかのファイルは、上記で説明したトラック識別子ベースの参照で必要とされ、トラック識別子ベースの参照は、例えばファイル再生のためのトラック識別子ベースの参照の使用をいくぶん厄介なものにする可能性がある。オプションは、全てのタイルまたはサブ画像トラックを異なるトラック識別子で同じファイルに格納することになるが、その後、適合するビットストリームを形成するタイルまたはサブ画像トラックの各組合せのために、別個のタイルベーストラックまたはエクストラクタトラックが、それぞれ必要とされる可能性がある。過度の数のタイルベーストラックまたはエクストラクタトラックを作り出さないようにするために(例えば、高解像度タイルと低解像度タイルとの各組合せのためのエクストラクタトラックを作り出さないようにするために)、抽出のための代替であるトラックは、以下で説明されるメカニズムでグループ化することができる。同様に、同じコンテンツの異なるビットレートバージョンを表す一緒に並べられたタイルトラックのために同じタイルベーストラックを使用できるようにするために、以下のメカニズムを使用することができる。
ファイルライタは、例えば「alte」トラックグループと呼ばれるトラックグループが、抽出のための出所として使用されることになる代替であるトラックを収めることをファイルで示す。
「alte」グループについての識別子は、トラックについての識別子と同じ番号を付けた空間からとることができる。言い換えれば、「alte」グループについての識別子は、トラック識別子の値全てとは異なることが必要になることがある。必然的に、「alte」トラックグループ識別子は、トラック識別子が従来使用される場所で使用することができる。特に、「alte」トラックグループ識別子は、抽出のための出所を示すトラック参照として使用することができる。
このボックスによって形成されたトラックグループのメンバは、抽出のための出所として使用されることになる代替である。「alte」に等しいtrack_group_typeを伴うトラックグループのメンバは、「scal」または「sabt」トラック参照のための出所として使用されることになる代替である。Track_ref_4ccに等しいreference_typeのTrackReferenceTypeBoxは、トラックID値に加えて、またはトラックID値の代わりに、同じalte_track_ref_4cc値を収める「alte」トラックグループのtrack_group_id値をリストアップすることができる。例えば、エクストラクタトラックは、「scal」トラック参照を通じて、個々のトラックに加えて、または個々のトラックの代わりに、「alte」トラックグループを指すことができる。「alte」トラックグループの任意の単一のトラックが、抽出に適した出所である。プレーヤまたはファイルリーダまたは同様のものは、同期サンプル、またはタイプ1もしくは2のSAPサンプルを、切り替えられたトラックが保持する位置で抽出のためのソーストラックを変更することができる。
RWMQ方法では、各画像サイズおよび各タイルグリッドあたりの1つのエクストラクタトラックが十分である。360°+ビューポートビデオおよびRWMRビデオでは、1つのエクストラクタトラックが、各個別の鑑賞方向に必要とされることがある。
ストリーミングセッション中、ユーザは、再生をいつでも休止することができる。再生を休止すると、ユーザは、辺りを見回し、休止時に有効であったビューポートの外側に行くことができる。このようなケースが、ビューポート依存型ストリーミングで起こるとき、ビューポート外の領域は、より低い品質/解像度になる。この現象は、ユーザの体感をかなり悪化させる。休止状態の間、高品質での全360度球体の表示に十分な帯域幅および時間があるが、現在の360度球体フレームインスタンスを高品質/解像度で効率的に検索/デコード/再生するためのシグナリングメカニズムがない。その上、高解像度の完全な360度画像は、デコード能力を超える可能性がある。例えば、表示解像度は、6K ERP解像度から生じるビューポートに適していることがあるが、デコード容量は、4Kまでしかないことがある。
その上、再生システムが単一のデコーダインスタンスを有する場合、休止した時間インスタンスに対応する完全な360度球体のために、コード化タイルまたは同様のものをプレーヤが何らかの方法で検索およびデコードしたとしても、デコーダの内部状態は、現在、事前休止状態時とは完全に異なる。ビューアが再生を再び始めると、プレーヤは、そのデコーダ状態を再確立するために、(例えば最後のビデオセグメントの)前のランダムアクセス位置から再び始めて、以前のコード化画像コンテンツを再デコードする必要がある。これは、不必要なデコード動作を生み出し、再生のスタート前に予期せぬ遅延を引き起こすことさえある。
OMAF v2は、異なる全方向コンテンツソースを定義するための関係メカニズムも提供し、これは、視点と呼ばれる。格納およびエンコードの効率のために、時間単位の長いメディア(サブ)セグメントが好ましいと仮定すると、ユーザが1つの視点から別の視点に切り替えるとき、新しい視点コンテンツへの切替え動作を実施する前に、プレーヤが完全なメディアセグメントをダウンロードする必要があるので、帯域幅が無駄になる。
ここで、上記の問題を少なくとも部分的に回避するための、デコーダの再生休止中のコンテンツ検索のための改善された方法を紹介する。
図10に示すような、一態様による方法は、少なくとも第1の表現および第2の表現にビデオメディアコンテンツをエンコードすること(1000)を含み、第1の表現が、1つまたは複数の切替え可能インターコード化画像を含むようにエンコードされ(1002)、デコード順で切替え可能インターコード化画像の前にある画像が、デコード順で切替え可能インターコード化画像の後にあるどの切替え不能画像に対する基準画像としても使用されないという第1の特性を切替え可能インターコード化画像が有し、第2の表現が、第1の表現の切替え可能インターコード化画像と適合した1つまたは複数のデコーダリセット画像を含むようにエンコードされ(1004)、第2の表現のフレームレートが、第1の表現のフレームレート以下であり、第1および第2の表現の解像度が等しい。
実施形態において、表現という用語は、ビットストリームという用語と交換可能に用いることができるか、または送達および/もしくは記憶のためのビットストリームのカプセル化とみなすことができる。
1つの実施形態によれば、切替え可能画像は、デコード順でゼロ個以上前の切替え可能インターコード化画像および/または前のランダムアクセス画像からのみ切替え可能画像が予測されるという第2の特性を有することができる。
1つの実施形態によれば、デコード順で前の切替え可能インターコード化画像および/または前のランダムアクセス画像のうち、デコード順で後ろにある方からのみ切替え可能インターコード化画像が予測されるという第2の特性を切替え可能インターコード化画像が有することは、例えばコーディング規格において予め定義されており、かつ/またはビットストリームの中でもしくはそれとともに(例えば、エンコーダによって)示され、かつ/またはビットストリームからもしくはそれとともに(例えば、デコーダによって)デコードされる。第2の特性は、切替え可能インターコード化画像をデコーダリセット画像と置き換え、デコーダリセット画像から開始して第1の表現をデコードすることを可能にする。
1つの実施形態によれば、前の切替え可能インターコード化画像または前のランダムアクセス画像のうち、レコード順で後ろにある方における、またはその後の、デコード順でゼロ個以上前の画像からのみ切替え可能インターコード化画像が予測されるという第2の特性を切替え可能インターコード化画像が有することは、例えばコーディング規格において予め定義されており、かつ/またはビットストリームの中でもしくはそれとともに(例えば、エンコーダによって)示され、かつ/またはビットストリームからもしくはそれとともに(例えば、デコーダによって)デコードされる。第2の特性は、切替え可能インターコード化画像をデコーダリセット画像と置き換え、デコーダリセット画像から開始して第1の表現をデコードすることを可能にする。
1つの実施形態によれば、デコード順でゼロ個以上前の切替え可能インターコード化画像および/または前のランダムアクセス画像からのみ切替え可能インターコード化画像が予測されるという第2の特性を切替え可能インターコード化画像が有することは、例えばコーディング規格において予め定義されており、かつ/またはビットストリームの中でもしくはそれとともに(例えば、エンコーダによって)示され、かつ/またはビットストリームからもしくはそれとともに(例えば、デコーダによって)デコードされる。第2の特性は、切替え可能インターコード化画像を対応するデコーダリセット画像と置き換えることによって第1の表現をデコードすることを可能にし、置き換えは、少なくとも、基準画像のうちの1つまたは複数がデコードされていない切替え可能インターコード化画像について実行される。
このため、切替え可能インターコード化画像を第1の表現に導入し、デコーダリセット画像を第2の表現に導入する等の特定のエンコーダ制約を有する同じコンテンツ表現の複数のエンコードされた表現を提供する、新規のビデオエンコーディング方法を紹介する。デコーダリセット画像を切替え可能画像と適合させることは、多くのコーディングシステムにおいて、それらの画像について同じ画像オーダーカウント(POC)またはPOCの同じ下位ビットを示すことを含むことができ、それによって、それらの画像はいずれも、デコード順で後ろにある画像からのインター予測において交換可能に参照することができる。
1つの実施形態によれば、デコード順で切替え可能インターコード化画像の前にある全ての画像が、デコード順で切替え可能インターコード化画像の後にある全ての画像に対し、出力順で前にあるという第3の特性を切替え可能インターコード化画像が有することは、例えばコーディング規格において予め定義されており、かつ/またはビットストリームの中でもしくはそれとともに(例えば、エンコーダによって)示され、かつ/またはビットストリームからもしくはそれとともに(例えば、デコーダによって)デコードされる。第3の特性は、切替え可能インターコード化画像に対応するデコーダリセット画像からデコーディングが開始するとき、「全」達成可能画像レートが、画像のフリーズまたはスタッタリングなしで達成されることを暗に意味する。
1つの実施形態によれば、切替え可能インターコード化画像自体、およびデコード順で切替え可能インターコード化画像の前にある全ての画像の双方が、デコード順で切替え可能インターコード化画像の後にある全ての画像に対し、出力順で前にあるという第3の特性を切替え可能インターコード化画像が有することは、例えばコーディング規格において予め定義されており、かつ/またはビットストリームの中でもしくはそれとともに(例えば、エンコーダによって)示され、かつ/またはビットストリームからもしくはそれとともに(例えば、デコーダによって)デコードされる。第3の特性は、切替え可能インターコード化画像に対応するデコーダリセット画像からデコーディングが開始するとき、「全」達成可能画像レートが、画像のフリーズまたはスタッタリングなしで達成されること、およびデコーダリセット画像が出力順において第1の画像であることを暗に意味する。
1つの実施形態によれば、画像が切替え可能インターコード化画像であるという指示を、エンコーダはビットストリームの中でもしくはそれとともに指示し、および/またはデコーダはビットストリームからもしくはそれとともにデコードする。指示は、例えば、限定ではないが、特定のNALユニットタイプ値および/または特定のSEIメッセージとすることができる。特定のNALユニットタイプ値は、例えば、関連画像がトレーリング画像であること、ならびに、上記で説明した、第1の特性と第2および第3の特性のうちのゼロ個以上とがビットストリームにおいて守られることを示す。
1つの実施形態によれば、特定の画像に関連付けられた第1、第2および第3の特性のうちの1つまたは複数を示す1つまたは複数の指示を、エンコーダはビットストリームの中でもしくはそれとともに指示し、および/またはデコーダはビットストリームからもしくはそれとともにデコードする。指示は、例えば、特定のSEIメッセージ内に含めることができる。
1つの実施形態によれば、方法は、切替え可能インターコード化画像を周期的にコード化することをさらに含む。例えば、ネスト化された時間スケーラビリティを用いた階層的インターコーディングにおいて、各グループオブピクチャ(GOP)におけるキー画像(すなわち、0に等しいTemporalIdを有する画像)は、切替え可能画像としてエンコードすることができる。
1つの実施形態によれば、デコーダリセット画像は、ランダムアクセス画像タイプとしてエンコードされる。1つの実施形態によれば、デコーダリセット画像は、先頭画像がないことを暗に意味するようにランダムアクセス画像タイプとしてエンコードされる。1つの実施形態において、デコーダリセット画像は、ブロークンリンクアクセス(BLA:Broken Link Access)画像の後に先頭画像がないBLA画像タイプであるか、または、インデペンデントデコーディングリフレッシュ(IDR:Independent Decoding Refresh)画像である。例えば、HEVCにおいて、デコーダリセット画像は、デコード順でBLA画像に先頭画像が続かないことを示す、nal_unit_typeがBLA_N_LPに等しいブロークンリンクアクセス(BLA)画像としてエンコードすることができる。いくつかのビデオコーデック実装において、上記と類似の機能を提供する他の画像またはNALユニットタイプが存在し得る。例えば、H.266/VVCの草案によるエンコーディング方式において、デコーダリセット画像は、画像オーダーカウントを含み、コード化ビデオシーケンスを開始し、このためデコーダリセット画像として十分なインデペンデントデコーディングリフレッシュ(IDR)画像としてエンコードすることができる。
1つの実施形態によれば、デコーダリセット画像は、デコーダリセット画像からのデコーディングの開始時にデコード可能である場合もまたは可能でない場合もある、先頭画像を有する場合もまたは有しない場合もあるランダムアクセス画像タイプとしてエンコードされる。1つの実施形態において、エンコーディングは、デコーダリセット画像について先頭画像がエンコードされないように制約される。別の実施形態において、エンコーディングは、デコーダリセット画像についてRASL画像等がエンコードされないように制約される。
1つの実施形態によれば、デコーダリセット画像は、イントラコード化画像としてエンコードされるが、例えば、トレーリング画像タイプ(例えば、HEVCのTRAIL画像)を有することができる。エンコーディングは、ランダムアクセス画像についても同様の制約となるように制約され、すなわち、出力順において後にある画像が、デコード順でデコーダリセット画像の前にある任意の画像のデコーディング処理を行うことなく正しくデコードされることが可能であるようにエンコードされる。1つの実施形態において、エンコーディングは、デコーダリセット画像について先頭画像がエンコードされないように制約される。別の実施形態において、エンコーディングは、デコーダリセット画像についてRASL画像等がエンコードされないように制約される。
図11は、特に、デコーダリセット画像がBLA画像である事例における、デコーダリセット画像について上記で説明したエンコーディング制約および関係を例示する。しかしながら、図11は、「BLA」を、任意の他のタイプのデコーダリセット画像と、または通常、デコーダリセット画像という用語と置き換えても同様に適用可能であることを理解する必要がある。図11において、第1の表現は、「従来のビットストリーム」と呼ばれ、第2の表現は、「BLAビットストリーム」と呼ばれる。図11は、デコード順で切替え可能インターコード化画像の前にある画像が、デコード順で切替え可能インターコード化画像の後にあるどの切替え不能画像に対する基準画像としても使用されない方式を示す。換言すれば、切替え可能画像を「越える」予測が無効にされる。図11は、第2の表現のデコーダリセット画像(BLA)を第1の表現の切替え可能画像と適合させる方式も示す。第2の表現のフレームレートは、第1の表現において用いられる実際のコンテンツフレームレート以下であり、好ましくは整数倍である。図11において「P/B」でマーク付けされた画像は、任意のタイプとすることができる。そのような画像は、例えば、単予測(P)、双予測(B)、またはイントラ予測(I)コード化イメージセグメントを含むことができる。
1つの実施形態によれば、方法は、第1の表現の画像の前の第2の表現のデコーダリセット画像をデコードするとき、画像品質の改善の観点から第2の表現のコーディングパラメータを調整することをさらに含む。
そのようなコーディングパラメータ調整は、例えば、以下のようなマルチパスエンコーディングを通じて達成することができる。
- デコーダリセット画像をエンコードした後、従来のビットストリーム(すなわち、第1の表現)の画像の前のデコーダリセット画像がデコードされる。
- 従来のビットストリームのデコード画像の歪みメトリックが導出される。例えば、以下のもの、すなわち、(複数の画像にわたる)平均PSNR、画像単位のPSNR、ピークサンプル単位絶対差(peak sample-wise absolute difference)のうちの1つまたは複数を導出することができる。
- 歪みメトリックが、所定の制限未満の歪みを示す場合、デコーダリセット画像のパラメータが十分であると判断することができる。
- そうでない場合、コーディングパラメータ決定を調整することができる。例えば、より低い量子化パラメータを用いることができ、レート歪み最適化のラムダ値を、忠実度をより優先するように選択することができ、および/または(レート制御が用いられているとき)デコーダリセット画像のために、より高いビットレートターゲットを選択することができる。次に、デコーダリセット画像は、再び、調整されたコーディングパラメータ決定を用いてエンコードされる。
デコーダリセット画像をエンコードするとき、エンコーディングのための入力画像は、従来のエンコーディングにおいても用いられる同じ非圧縮画像とすることができるが、従来のビットストリームからデコードされた切替え可能画像に対する歪みメトリックを導出することができる。このため、エンコーダは、デコードされた切替え可能画像に対する歪みを最小限にするように試みる。
1つの実施形態によれば、方法は、ビットストリームの中でもしくはそれとともに、および/またはビットストリームをカプセル化する表現のためのメタデータの中で、デコード時のビットストリームまたは表現の間の切替えに対する、表現のビットストリームまたはコンテンツの適性を示すことをさらに含む。
1つの実施形態において、ビットストリームの中でもしくはそれとともに、および/またはビットストリームをカプセル化する表現のためのメタデータの中で、
- 第2の表現のユニットがデコーダリセット画像を含むこと、
- デコーダリセット画像と、それに続く、デコード順でデコーダリセット画像に対応する切替え可能インターコード化画像の後にある、第1の表現における画像とから、連結ビットストリームを形成することができること、および、
- 連結されたビットストリームはデコード可能であり、表示のために満足のいく品質を有すること、
が示される。
デコーダリセット画像を備える第2の表現のユニットは、例えば、限定ではないが、セグメント、サブセグメント、またはファイルフォーマットサンプルとすることができる。指示は、ビットストリームおよび/またはメタデータの中でまたはそれとともに、いずれのユニットが指示の範囲内にあるかを示すことができるか、またはいずれのユニットが範囲内にあるかは、予め定義もしくは推測することができる。例えば、サブセグメントあたり単一のデコーダリセット画像があり、このため、指示をサブセグメントベースで適用することができることを仮定することができる。
このため、ファイル生成器またはサーバ等のエンコーダまたは中間装置は、それぞれ、デコーダまたはプレーヤに送信される第1および第2の表現におけるエンコードされた第1および第2のビットストリームを提供する。第1および第2の表現は、例えば、ISOベースメディアファイルフォーマットトラックにおいて、またはDASH表現として送信することができる。
ISOベースメディアファイルフォーマットトラックが用いられる場合、そのようなトラフィック間の切替えメカニズムに対するコンテンツの適性を示すファイルフォーマットレベルシグナリングメカニズムを用いることができる。例えば、画像切替え対応ビットストリーム(すなわち、第2の表現)を搬送するトラックから、従来のビットストリーム(すなわち、第1の表現)を搬送するトラックへの特定のタイプ(例えば‘dren’)のトラック参照を用いることができる。別の例では、画像切替え対応ビットストリーム(すなわち、第2の表現)を搬送するトラックから、従来のビットストリーム(すなわち、第1の表現)を搬送するトラックを含む、特定のタイプのトラックグループを用いることができる。トラックは、例えば、トラックのサンプルエントリにおける特定のボックスとして、例えばトラックレベル指示を含めることによって、画像切替え対応ビットストリームを搬送することを示すことができる。
DASH表現が用いられる場合、そのような表現間の切替えメカニズムに対するコンテンツの適性を示すシステムレベルDASHシグナリングメカニズムを用いることができる。この目的で、DASHプロトコルベースのメカニズムを以下のように提供することができる。
- 画像切替え対応表現(すなわち、第2の表現)のためのDASH MPDにおける新たな属性が、前記第2の表現を、例えば休止状態における低品質のタイル表現画像と置き換えるために用いることができることを示し、デコーダリセットが従来の表現(すなわち、第1の表現)のデコーディングを継続することを可能にするために定義される。
- 属性は、例えば@decoderResetEnableと呼ぶことができ、以下のように定義することができる。
- @decoderResetEnable:
○ この表現がリセット画像を提供する従来の表現を指定する、Representation@id属性の値の空白類で区切られたリスト。画像は、本発明において(「コンテンツエンコーディング」セクションにおいて)定義されるようにエンコードされ、単一のデコーダインスタンスを利用することができる。
○
上記のシグナリングにおいて、@decoderResetEnable属性は例として与えられ、DASHプロトコルは例として選択されることに留意されたい。システムレベルシグナリングを満たし、コンテンツエンコーディング方法の適性を示す、任意の名前またはプロトコルが利用され得る。
図12は、@decoderResetEnable属性または任意の等価な指示の使用を示す。図12は、図11の用語を用いるが、図11の記載において説明されるように、他の用語にも同様に当てはまる。@decoderResetEnable属性は、矢印によって示されるように、コード化画像の連結シーケンスをデコードすることができ、デコードの結果として適切な画像品質が得られることを示す。このため、メディアサーバが、例えば限定ではないが、休止状態中およびプレイ状態への遷移中に、そのような表現切替え動作に対する、エンコードされた表現の適性をシグナリングすることができるように、DASHシグナリングメカニズムが定義される。休止状態中、デコーダリセット画像、すなわち図12におけるBLA画像をデコードすることができる。再生を再開するとき、@decoderResetEnableまたは任意の等価な指示が、プレーヤに、デコーダリセット画像に対応する切替え可能インターコード化画像に続く従来のビットストリーム内の画像からデコーディングが継続できることを示す。
上記において、ファイルフォーマットおよびDASHシグナリングメカニズムが、それぞれ、画像切替え対応トラックまたは表現から従来のトラックまたは表現への指示として定義されている。実施形態は、反対方向の、すなわち、それぞれ従来のトラックまたは表現から、画像切替え対応トラックまたは表現まで、反対方向の参照を用いて同様に実現され得ることを理解する必要がある。
別の態様は、少なくとも第1のビットストリームまたは表現、および第1の表現と第2の表現との間の切替えに対するコンテンツの適性に関する指示を受け取ったときのプレーヤの動作に関する。
図13に示すように、動作は、エンコードされたビデオメディアコンテンツの第1の表現に対応する少なくとも1つのビットストリームを受け取ること(1300)であって、第1の表現が、1つまたは複数の切替え可能インターコード化画像を含み、デコード順で切替え可能画像の前にある画像が、デコード順で切替え可能画像の後にあるどの切替え不能画像に対する基準画像としても使用されないという第1の特性を切替え可能インターコード化画像が有する、受け取ることと、少なくとも1つのビットストリームからまたはそれとともに、デコード時に第1の表現と第2の表現との間で切り替えることの適性についての指示を受け取ること(1302)であって、第2の表現が、第1の表現の切替え可能インターコード化画像と適合した1つまたは複数のデコーダリセット画像を含み、第2の表現のフレームレートが、第1の表現のフレームレート以下であり、第1および第2の表現の解像度が等しい、受け取ることと、第2の表現の少なくとも1つのデコーダリセット画像を受け取ること(1304)と、第1の表現の画像の前の第2の表現の少なくとも1つのデコーダリセット画像をデコードすること(1306)と、を含むことができる。
1つの実施形態によれば、方法は、デコードされた第1の表現の再生時の休止に応答して、第2の表現の少なくとも1つのデコーダリセット画像をリクエストすることをさらに含む。リクエストすることは、例えば、第2の表現の少なくとも1つのデコーダリセット画像を含む(サブ)セグメントのためのHTTP GETリクエストを発行することを含むことができる。
このため、例えば、再生デバイスのユーザからのコマンドによって再生が休止するとき、プレーヤは、DASH MPD等の指示においてシグナリングされる時間単位の対応するデコーダリセット画像をリクエストし、デコーダリセット画像をデコードし、デコードされた高品質デコーダリセット画像で360°の球体を更新する。
デコーダリセット画像は、(それらの各々が新たなコード化ビデオシーケンスを開始する際)デコーダをリセットするため、例えばデコーダリソースおよびバッファに関する問題を生じることなく同じデコーダインスタンスを用いてデコードすることができる。デコード時の第1の表現および第2の表現の間の切替えに対する、表現のコンテンツの適性に関する指示を受け取ることによって、プレーヤは、休止状態中に高品質360°ビデオ画像ディスプレイを可能にすることに成功し、デコーダリソースおよびバッファに実質的な影響を及ぼすことなく再生を開始することにも成功することができる。
1つの実施形態によれば、方法は、再生の再開に応答して、再開に実質的にタイムリに対応するデコーダリセット画像をデコードすることと、再開に実質的にタイムリに対応するデコーダリセット画像と一時的に適合した、第1の表現の切替え可能インターコード化画像の、デコード順で後にある第1の表現の画像をデコードすることに切り替えることとをさらに含む。
再生が再開すると、プレーヤは、再開に対応して実質的にタイムリにデコーダリセット画像をデコードする。デコーダリセット画像は、再生の再開にタイムリに続く次のデコーダリセット画像とすることができる。他方で、前にデコードされたデコーダリセット画像が再生再開に時間的に十分近い場合、これを第1の表現への切替えポイントとして用いることもできる。次に、プレーヤは、切替えポイントとして用いられるデコーダリセット画像と時間的に適合された切替え可能画像に続く画像から、従来の表現(第1の表現)のデコーディングを継続する。
実施形態は、上記で第1の表現および第2の表現と関連して説明された。実施形態は、各々が第1の表現に類似した表現の第1のセット、および各々が第2の表現に類似し、各々が、表現の第1のセット間の対応する表現を有する、表現の第2のセットにも同様に当てはまる。実施形態は、表現の第1のセット間の選択された表現、および表現の第2のセット間の対応する表現にペアごとに適用することができる。例えば、実施形態は、上記で説明したように、例えばビューポートに依存したストリーミングを達成するために、複数のタイルトラック、サブ画像トラック等が受け取られるときに当てはまる。
1つの実施形態によれば、方法は、デコードされた第1の表現の再生時の休止に応答して、デコーダバッファサイズおよび/または利用可能な帯域幅の制限に応じて、第2の表現の複数のデコーダリセット画像をリクエストすることをさらに含む。
1つの実施形態によれば、方法は、デコードされた表現の第1のセットの再生時の休止に応答して、デコーダバッファサイズおよび/または利用可能な帯域幅の制限に応じて、第2の表現の第2のセットから複数のデコーダリセット画像をリクエストすることをさらに含む。例えば、現在のビューポートをカバーするデコーダリセット画像は、タイルまたはサブ画像トラック等を搬送する表現の第2のセットからリクエストすることができる。
このため、プレーヤは、休止状態中に、利用可能なバッファサイズに基づいて、または定義された帯域幅利用ポリシに基づいて、コンテンツカバレッジ全体(例えば、360°)をカバーする高品質タイルをフェッチすることによって、休止持続時間を利用することができる。高品質タイルは、表現の第2のセットに含めることができる。高品質タイルは、例えば、表現の第2のセットにカプセル化されたサブ画像トラックにおけるランダムアクセス画像とすることができるか、または例えば、表現の第2のセットにカプセル化されたタイルトラックに封入されたランダムアクセス画像のタイルもしくはタイルセットとすることができる。プレーヤは、まず、高品質のプリフェッチされたタイルをデコードおよび再生し、特定のビューポートを有する通常の再生動作を再開するとき、プレーヤは、ビューポートについて高品質コンテンツをリクエストし、ビューポートに基づく360°球体の残りの部分について低品質をリクエストすることを開始する。
休止状態中、プレーヤは、以下のポリシを用いてプリフェッチを開始することもできる。
- まず、現在のビューポートについて高品質タイルをプリフェッチし、次に、休止されたビューポートの周りの、閾値によって定義することができる拡大されたエリアについてプリフェッチする。
- HMD/注視方向に対応する、または例えば休止状態中の何気ない動き(casual motion)の後の「着陸方向(landing orientation)」における、ビューポートの「低速プリフェッチ」。これは、ユーザが着陸方向点から再生を開始することを予期することができるため、ユーザの動きを追跡し、低速でデータをプリフェッチすることを可能にする。
1つの実施形態によれば、方法は、ビューポート切替えに応答して、第2の表現の少なくとも1つのデコーダリセット画像をリクエストすることをさらに含む。リクエストすることは、例えば、第2の表現の少なくとも1つのデコーダリセット画像を含む(サブ)セグメントのためのHTTP GETリクエストを発行することを含むことができる。
1つの実施形態によれば、方法は、第1のビューポートから第2のビューポートへの切替え時に第1の表現から第2の表現への切替えを適用することをさらに含む。このため、プレーヤが1つのビューポートから別のビューポートに切り替えるとき、DASHシグナリングメカニズム等の上述したシグナリング、およびプレーヤ動作を適用することができる。デコーダリセット画像は、ビューポートの1つのメディア(サブ)セグメントから別のビューポートの別のメディア(サブ)セグメントへの高速な遷移を可能にし、このため、ビューポート切替え処理中の低レイテンシで効率的な帯域幅利用を可能にする。この実施形態は、例えば、比較的頻繁なデコーダリセット画像を有する第2の表現を提供することによってビューポート依存のストリーミングにおけるビュー方向切替えへの高速なレスポンスを達成できるようにしながら、例えば、第1の表現における比較的大きなランダムアクセス画像間隔を用いてより良好な圧縮性能を達成することを可能にすることができる。別のビューポートに切り替えるとき、そのビューポートをカバーするデコーダリセット画像が最初に受け取られ、デコードされ、その後に、デコード順でデコーダリセット画像に続く第1の表現(表現の第1のセット)の画像が続く。
1つの実施形態によれば、方法は、視点切替えに応答して、第2の表現の少なくとも1つのデコーダリセット画像をリクエストすることをさらに含む。リクエストすることは、例えば、(切替え先の)宛先視点の第2の表現の少なくとも1つのデコーダリセット画像を含む(サブ)セグメントのためのHTTP GETリクエストを発行することを含むことができる。プレーヤは、デコーダリセット画像に対応する切替え可能インターコード化画像に後続する宛先視点の第1の表現のコード化画像をカバーする別のリクエストを発行することができる。
1つの実施形態によれば、方法は、第1の視点から第2の表現の視点への切替え時に第1の表現から第2の表現への切替えを適用することをさらに含む。このため、プレーヤが1つの視点から別の視点に切り替えるとき、DASHシグナリングメカニズム等の上述したシグナリング、およびプレーヤ動作を適用することができる。デコーダリセット画像は、1つの視点のメディアセグメントから別の視点の別のメディアセグメントへの高速な遷移を可能にし、このため、視点切替え処理中の低レイテンシで効率的な帯域幅利用を可能にする。
実施形態は、例えばISO/IEC14496-15においてHEVCについて定義されているように、エクストラクタと結合することができるが、エクストラクタは切替え可能画像およびリセット画像のイメージセグメント(例えばスライス)の混合を必ずしも可能にしないという制約を伴う。なぜなら、前記画像タイプのイメージセグメントヘッダ(例えばスライスヘッダ)が互いに異なるためである。実施形態によるシグナリングは、それぞれ、従来の画像およびリセット画像から、サブ画像トラック/表現を抽出する、従来の画像およびリセット画像のものであるエクストラクタトラック/表現の対間で示すことができる。
いくつかのビデオコーディングフォーマットまたは規格は、切替え可能画像およびリセット画像から生じるイメージセグメントの混合を可能にすることができる。そのような場合、表現の第1の組および表現の第2の組から生じる、一緒に並んだタイルトラック、サブ画像トラック等の各セットは、例えば上記の‘alte’トラックグループを用いて互いの代わりになるように示すことができる。エクストラクタトラックは、表現の第1のセットおよび第2のセットからの、一緒に並べられたイメージセグメントのトラックグループを指すことができる。プレーヤは、イメージセグメントベースで(例えばサブ画像またはタイルベースで)、イメージセグメントが切替え可能インターコード化画像から生じるか、または対応するデコーダリセット画像から生じるかを選択することができる。
1つの実施形態によれば、ネットワークに基づくメディア処理エンティティは、ストリーミングセッション中に実質的に瞬時に(すなわち、オンザフライで)デコーダリセット画像を生成し、異なる表現間のシームレスな切替えを可能にすることができる。そのようなエンティティは、MPEG NBMPまたは同様の規格に準拠することができる。そのような場合、DASH@decoderResetEnableフラグは、表現におけるそのようなデコーダリセット画像の存在を示すことができる。実施形態は、大きな利点を提供することができる。例えば、プレーヤは、説明された実施形態を利用し、休止状態中の高品質な360°ビデオ画像ディスプレイを可能にし、また、デコーダリソースおよびバッファに対する影響を最小限にしながら再生を開始することに成功することができる。説明された実施形態を実現するには単一のデコーダインスタンスで十分とすることができ、この際、@decoderResetEnableDASH属性のパースおよび解釈等、シグナリングを解釈する能力を除いて、プレーヤ側に追加のデコーダ制約はセットされない。@decoderResetEnable等の適切なシグナリングを用いて、プレーヤは、非ストリームアクセスポイント位置において、関連する表現が、示された従来の表現のデコーディングの開始のためにデコーディングをリセットするのに適していることを理解することができる。さらに、実施形態は、全方向ビデオ再生が休止され、次に再開されるときの、より良好なユーザ体験を提供する。また、デコーダ状態適合のために不要なメディアデータ転送を削除することによって、ネットワークリソースがより良好に利用される。
図14は、本発明の実施形態を用いるのに適したビデオデコーダのブロック図を示す。図14は、2層デコーダの構造を示すが、デコーディング動作は、単層デコーダにおいて同様に用いることができることが理解されよう。
ビデオデコーダ550は、ベースレイヤのための第1のデコーダセクション552と、予測レイヤのための第2のデコーダセクション554を含む。ブロック556は、ベースレイヤ画像に関する情報を第1のデコーダセクション552に送達し、予測レイヤ画像に関する情報を第2のデコーダセクション554に送達するためのデマルチプレクサを示す。参照符号P’nは、イメージブロックの予測表現を表す。参照符号D’nは、再構築された予測誤差信号を表す。ブロック704、804は、事前再構築イメージ(I’n)を示す。参照符号R’nは、最終再構築イメージを表す。ブロック703、803は、逆変換(T-1)を示す。ブロック702、802は、逆等化(Q-1)を示す。ブロック701、801は、エントロピデコーディング(E-1)を示す。ブロック705、805は、参照フレームメモリ(RFM)を示す。ブロック706、806は、予測(P)(インター予測またはイントラ予測)を示す。ブロック707、807は、フィルタリング(F)を示す。ブロック708、808を用いて、デコードされた予測誤差情報を予測ベースレイヤ/予測レイヤイメージと組み合わせて、事前再構築イメージ(I’n)を取得することができる。予備の再構成およびフィルタリングされたベースレイヤイメージを第1のデコーダセクション552から出力することができ(709)、予備の再構成およびフィルタリングされたベースレイヤイメージを第1のデコーダセクション554から出力することができる(809)。
ここで、デコーダは、プレーヤ、レシーバ、ゲートウェイ、デマルチプレクサおよび/またはデコーダ等のデコーディング動作を実行することが可能な任意の動作ユニットをカバーするように解釈されるべきである。
図15は、様々な実施形態を実施することができる例示的なマルチメディア通信システムのグラフィック表現である。データソース1510は、アナログ、非圧縮デジタル、もしくは圧縮デジタルフォーマット、またはこれらのフォーマットの任意の組合せでソース信号を提供する。エンコーダ1520は、データフォーマット変換および/またはソース信号のフィルタリング等の前処理を含むかまたはこれと接続することができる。エンコーダ1520は、ソース信号を、コード化されたメディアビットストリームにエンコードする。デコードされるビットストリームは、仮想的に任意のタイプのネットワーク内に位置するリモートデバイスから直接または間接的に受信することができることに留意されたい。さらに、ビットストリームは、ローカルハードウェアまたはソフトウェアから受信することができる。エンコーダ1520は、オーディオおよびビデオ等の2つ以上のメディアタイプをエンコードすることが可能である場合があるか、または異なるメディアタイプのソース信号をコード化するために2つ以上のエンコーダ1520が必要とされる場合がある。エンコーダ1520は、グラフィックおよびテキスト等の、合成して生成された入力を得る場合もあり、または合成メディアのコード化ビットストリームを生成することが可能である場合がある。以下において、説明を簡単にするために、1つのメディアタイプの1つのコード化されたメディアビットストリームの処理のみが検討される。しかしながら、通常、リアルタイムブロードキャストサービスは、いくつかのストリーム(通常、少なくとも1つのオーディオ、ビデオ、およびテキスト字幕ストリーム)を含むことに留意されたい。また、システムは、多くのエンコーダを含むことができるが、図において、一般性を損なうことなく、説明を簡単にするために1つのエンコーダ1520のみが表されることを理解されたい。さらに、本明細書に含まれる本文および例は、エンコーディング処理を詳細に説明する場合があるが、当業者であれば、同じ概念および原理が対応するデコーディング処理にも当てはまり、逆もまた同様であることを理解するであろうことを理解されたい。
コード化されたメディアビットストリームは、ストレージ1530に転送することができる。ストレージ1530は、コード化されたメディアビットストリームを記憶するための任意のタイプのマスメモリを備えることができる。ストレージ1530におけるコード化されたメディアビットストリームのフォーマットは、基本的な自己完結型のビットストリームフォーマットとすることができるか、または1つもしくは複数のコード化されたメディアビットストリームは、コンテナファイル内にカプセル化することができるか、またはコード化されたメディアビットストリームは、DASH(または類似のストリーミングシステム)に適したセグメントフォーマット内にカプセル化し、セグメントのシーケンスとして記憶することができる。1つまたは複数のメディアビットストリームがコンテナファイル内にカプセル化される場合、ファイル生成器(図に示されていない)を用いて、1つまたは複数のメディアビットストリームをファイルに記憶し、ファイルフォーマットメタデータを生成することができ、ファイルフォーマットメタデータもファイルに記憶することができる。エンコーダ1520もしくはストレージ1530はファイル生成器を備えることができるか、またはファイル生成器はエンコーダ1520もしくはストレージ1530のいずれかに作動的に取り付けることができる。いくつかのシステムは、「ライブ」動作し、すなわち、ストレージを省き、コード化されたメディアビットストリームをエンコーダ1520からセンダ1540に直接転送する。次に、コード化されたメディアビットストリームは、必要に応じてサーバとも呼ばれるセンダ1540に転送することができる。伝送において用いられるフォーマットは、基本的な自己完結型のビットストリームフォーマット、パケットストリームフォーマット、DASH(または類似のストリーミングシステム)に適したセグメントフォーマットとすることができるか、または1つもしくは複数のコード化されたメディアビットストリームがコンテナファイル内にカプセル化されてもよい。エンコーダ1520、ストレージ1530、およびサーバ1540は、同じ物理的デバイス内に存在してもよく、または別個のデバイスに含まれてもよい。エンコーダ1520およびサーバ1540は、ライブリアルコンテンツとともに動作することができ、この場合、コード化されたメディアビットストリームは、通常、永久的に記憶されるのではなく、処理遅延、転送遅延、およびコード化されたメディアビットレートの変動を平滑化するために、短い期間コンテンツエンコーダ1520および/またはサーバ1540にバッファリングされる。
サーバ1540は、通信プロトコルスタックを用いてコード化されたメディアビットストリームを送信する。スタックは、限定ではないが、リアルタイムトランスポートプロトコル(RTP)、ユーザデータグラムプロトコル(UDP)、ハイパーテキストトランスファプロトコル(HTTP)、伝送制御プロトコル(TCP)、およびインターネットプロトコル(IP)のうちの1つまたは複数を含むことができる。通信プロトコルスタックがパケット指向であるとき、サーバ1540は、コード化されたメディアビットストリームをパケット内にカプセル化する。例えば、RTPが用いられるとき、サーバ1540は、RTPペイロードフォーマットに従って、コード化されたメディアビットストリームをRTPパケット内にカプセル化する。通常、各メディアタイプは、専用のRTPペイロードフォーマットを有する。ここでもまた、システムは、2つ以上のサーバ1540を含むことができるが、簡単にするために、以下の説明は、1つのサーバ1540のみを検討することに留意されたい。
メディアコンテンツがストレージ1530のために、またはデータをセンダ1540に入力するためにコンテナファイル内にカプセル化される場合、センダ1540は、「送信ファイルパーサ」(図には示されていない)を含むことができるか、またはこれに作動的に取り付けることができる。特に、コンテナファイルがそのまま送信されるのではなく、含まれるコード化されたメディアビットストリームのうちの少なくとも1つが通信プロトコルを介したトランスポートのためにカプセル化される場合、送信ファイルパーサは、通信プロトコルを介して伝達されることになるコード化されたメディアビットストリームの適切な部分を特定する。送信ファイルパーサは、パケットヘッダおよびペイロード等の通信プロトコルのための正しいフォーマットの生成も支援することができる。マルチメディアコンテナファイルは、通信プロトコルにおける、含まれるメディアビットストリームのうちの少なくとも1つのカプセル化のための、ISOBMFFにおけるヒントトラック等のカプセル化命令を含むことができる。
サーバ1540は、通信ネットワークを通じてゲートウェイ1550に接続される場合もまたは接続されない場合もあり、通信ネットワークは、例えば、CDN、インターネットおよび/または1つもしくは複数のアクセスネットワークの組合せとすることができる。ゲートウェイは、さらにまたは代替的に、中央ボックスと呼ばれる場合がある。DASHについて、ゲートウェイは、(CDNの)エッジサーバまたはウェブプロキシとすることができる。システムは、通常、任意の数のゲートウェイ等を含むことができるが、簡単にするために、以下の説明は、1つのゲートウェイ1550のみを検討することに留意されたい。ゲートウェイ1550は、1つの通信プロトコルスタックに従うパケットストリームの別の通信プロトコルスタックへの変換、データストリームのマージおよびフォーキング、ならびにダウンリンクおよび/またはレシーバ能力に従ったデータストリームの操作、例えば、優勢なダウンリンクネットワーク条件に従った転送ストリームのビットレートの制御等の様々なタイプの機能を実行することができる。様々な実施形態において、ゲートウェイ1550はサーバーエンティティとすることができる。
システムは、通常、送信された信号を受信し、復調し、脱カプセル化(de-capsulating)してコード化されたメディアビットストリームに入れることが可能な1つまたは複数のレシーバ1560を備える。コード化されたメディアビットストリームは、記録ストレージ1570に転送することができる。記録ストレージ1570は、コード化されたメディアビットストリームを記憶するための任意のタイプのマスメモリを備えることができる。記録ストレージ1570は、代替的にまたはさらに、ランダムアクセスメモリ等の計算メモリを備えることができる。記録ストレージ1570におけるコード化されたメディアビットストリームのフォーマットは、基本的な自己充足型のビットストリームフォーマットとすることができるか、または1つもしくは複数のコード化されたメディアビットストリームは、コンテナファイル内にカプセル化することができる。互いに関連付けられたオーディオストリームおよびビデオストリーム等の複数のコード化されたメディアビットストリームが存在する場合、コンテナファイルが通常用いられ、レシーバ1560は、入力ストリームからコンテナファイルを生成するコンテナファイル生成器を含むかまたはこれに取り付けられる。いくつかのシステムは、「ライブ」で動作し、すなわち、記録ストレージ1570を省き、コード化されたメディアビットストリームをレシーバ1560からデコーダ1580に直接転送する。いくつかのシステムでは、記録されたストリームのうちの最も近時の部分、例えば、記録されたストリームのうちの最も近時の10分の抜粋のみが記録ストレージ1570に維持されるのに対し、任意のより早期に記録されたデータは、記録ストレージ1570から破棄される。
コード化されたメディアビットストリームは、記録ストレージ1570からデコーダ1580に転送することができる。互いに関連付けられ、コンテナファイル内にカプセル化された、オーディオストリームおよびビデオストリーム等の多くのコード化されたメディアビットストリームが存在する場合、または単一のメディアビットストリームが、より容易なアクセスのためにコンテナファイル内にカプセル化される場合、ファイルパーサ(図には示されていない)を用いて、コンテナファイルから、各コード化されたメディアビットストリームを脱カプセル化する。記録ストレージ1570またはデコーダ1580は、ファイルパーサを備えることができるか、またはファイルパーサは、記録ストレージ1570またはデコーダ1580のいずれかに取り付けられる。また、システムは、多くのデコーダを含むことができるが、ここでは、一般性を損なうことなく、説明を簡単にするために1つのデコーダ1570のみが論じられることを理解されたい。
コード化されたメディアビットストリームは、デコーダ1570によってさらに処理することができ、デコーダ1570の出力は、1つまたは複数の非圧縮メディアストリームである。最終的に、レンダラ1590は、例えば、ラウドスピーカまたはディスプレイを用いて、非圧縮メディアストリームを再現することができる。レシーバ1560、記録ストレージ1570、デコーダ1570およびレンダラ590は、同じ物理的デバイス内に存在してもよく、または別個のデバイスに含まれてもよい。
センダ1540および/またはゲートウェイ1550は、例えば、360°ビデオコンテンツの異なるビューポート間の切替え、ビュー切替え、ビットレート適合および/または高速始動のために異なる表現間の切替えを行うように構成することができ、および/またはセンダ1540および/もしくはゲートウェイ1550は、送信された表現を選択するように構成することができる。異なる表現間での切替えは、レシーバ1560のリクエストに対する応答、またはビットストリームが伝達されるネットワークのスループット等の優勢な条件等の複数の理由で行うことができる。換言すれば、レシーバ1560は、表現間の切替えを始動することができる。レシーバからのリクエストは、例えば、以前と異なる表現からのセグメントまたはサブセグメントのリクエスト、送信されたスケーラビリティレイヤおよび/もしくはサブレイヤの変更のリクエスト、または従来のものと比較して異なる能力を有するレンダリングデバイスの変更とすることができる。セグメントのためのリクエストは、HTTP GETリクエストとすることができる。セグメントのためのリクエストは、バイト範囲を有するHTTP GETリクエストとすることができる。さらにまたは代替的に、ビットレート調節またはビットレート適合は、例えば、ストリーミングサービスのいわゆる高速始動を提供するために用いることができ、ここで、送信されるストリームのビットレートは、再生を即座に開始し、偶発的なパケット遅延および/または再送信を許容するバッファ占有レベルを達成するために、ストリーミングの開始後またはランダムアクセス後のチャネルビットレートよりも低い。ビットレート適合は、様々な順序で生じる複数の表現またはレイヤアップスイッチングおよび表現またはレイヤダウンスイッチング動作を含むことができる。
デコーダ1580は、例えば、360°ビデオコンテンツの異なるビューポート間の切替えのための異なる表現間の切替え、視点切替え、ビットレート適合および/または高速始動を行うように構成することができ、および/またはデコーダ1580は、送信された表現を選択するように構成することができる。異なる表現間での切替えは、高速デコーディング動作の達成、または例えばビットレートの観点での、ビットストリームが伝達されるネットワークのスループット等の優勢な条件への送信ビットストリームの適合等の複数の理由で行うことができる。このため、デコーダは、第1の表現と第3の表現との間のビットレート適合を実行するために、第2の表現の少なくとも1つのデコーダリセット画像をリクエストするための手段をさらに備えることができる。デコーダ1580を備えるデバイスがマルチタスクを行っており、ビデオビットストリームをデコードする以外の目的で計算リソースを使用する場合、より高速なデコーディング動作が必要とされ得る。別の例では、コンテンツが、通常の再生速度よりも高速なペースで、例えば従来のリアルタイム再生レートよりも2倍または3倍高速で再生されるとき、より高速なデコーディングが必要とされ得る。
上記において、例えば、セグメントフォーマットに関して、ISOBMFFに関連するいくつかの実施形態が説明された。実施形態は、ISOBMFFと類似の能力および/または構造を有するMatroska等の任意の他のファイルフォーマットで同様に実現され得ることを理解する必要がある。
上記において、エンコーダを参照して例示的な実施形態が説明されたが、結果として得られるビットストリームおよびデコーダは、それらの中に対応する要素を有することができることが理解される必要がある。同様に、デコーダを参照して例示的な実施形態が説明されたが、エンコーダは、デコーダによってデコードされるビットストリームを生成するための構造および/またはコンピュータプログラムを有することができることが理解される必要がある。
上記で説明された本発明の実施形態は、関与する処理の理解を助けるために、別個のエンコーダおよびデコーダ装置の観点でコーデックを説明している。しかしながら、装置、構造および動作は、単一のエンコーダ-デコーダ装置/構造/動作として実施することができることが理解されよう。さらに、コーダおよびデコーダは、いくつかまたは全ての共通要素を共有し得ることが可能である。
上記の例は、電子デバイス内のコーデック内で動作する本発明の実施形態を記載しているが、特許請求の範囲において定義される発明は、任意のビデオコーデックの一部として実施することができることが理解されよう。このため、例えば、本発明の実施形態は、固定のまたは有線通信経路を介したビデオコーディングを実施することができるビデオコーデックにおいて実施することができる。
このため、ユーザ機器は、上記の本発明の実施形態において説明されたもの等のビデオコーデックを含むことができる。ユーザ機器という用語は、携帯電話、携帯データ処理デバイス、または携帯ウェブブラウザ等の任意の適切なタイプの無線ユーザ機器をカバーするように意図されることが理解されるべきである。
さらに、公衆陸上移動体ネットワーク(PLMN)の要素は、上記で説明したビデオコーデックも含むことができる。
一般に、本発明の様々な実施形態は、ハードウェアもしくは専用回路、ソフトウェア、ロジック、または、それらの任意の組合せにおいて実施することができる。例えば、いくつかの態様は、ハードウェアで実施されてもよく、一方、他の態様は、コントローラ、マイクロプロセッサ、または他のコンピューティングデバイスによって実行することができるファームウェアまたはソフトウェアにおいて実施されてもよい。しかしながら、本発明は、これらに限定されない。本発明の様々な態様は、ブロック図、フローチャート、または他の図表現を使用して図示および説明される場合があるが、ここに記載されたこれらのブロック、装置、システム、技術または方法は、非限定的な例として、ハードウェア、ソフトウェア、ファームウェア、専用回路もしくはロジック、汎用ハードウェアもしくはコントローラまたは他のコンピューティングデバイス、あるいは、それらのいくつかの組合せにおいて実施することができることがよく理解される。
本発明の実施形態は、プロセッサエンティティ内等のモバイルデバイスのデータプロセッサにより実行可能なコンピュータソフトウェアによって、もしくはハードウェアによって、またはソフトウェアおよびハードウェアの組合せによって実施することができる。さらに、これに関して、図のような論理フローの任意のブロックがプログラムステップ、もしくは相互接続された論理回路、ブロックおよび機能、またはプログラムステップおよび論理回路、ブロックおよび機能の組合せを表すことができることに留意されたい。ソフトウェアは、メモリチップ、またはプロセッサ内で実施されたメモリブロック等の物理媒体、ハードディスクまたはフロッピーディスク等の磁気媒体、ならびに例えばDVDおよびそのデータバリアント、CD等の光学媒体に格納することができる。
メモリは、ローカル技術環境に適している任意のタイプのものとすることができ、半導体ベースのメモリデバイス、磁気メモリデバイスおよびシステム、光メモリデバイスおよびシステム、固定メモリならびにリムーバブルメモリ等の任意の適切なデータストレージ技術を用いて実施することができる。データプロセッサは、ローカル技術環境に適している任意のタイプのものとすることができ、非限定的な例として、汎用コンピュータ、専用コンピュータ、マイクロプロセッサ、デジタル信号プロセッサ(DSP)およびマルチコアプロセッサアーキテクチャに基づくプロセッサのうちの1つまたは複数を含むことができる。
本発明の実施形態は、集積回路モジュール等の様々なコンポーネントで実施することができる。集積回路の設計は、概して高度に自動化された処理である。ロジックレベルの設計を、半導体基板にエッチングして形成される準備ができた半導体回路設計に変換するために複雑で処理能力の高いソフトウェアツールが利用可能である。
カリフォルニア州マウンテンビューのシノプシス社(Synopsys,Inc.)、カリフォルニア州サンノゼのケイデンスデザイン社(CadenceDesign)等が提供するプログラムは、十分に確立された設計ルールおよび事前に保存された設計モジュールのライブラリを使用して、半導体チップ上で、自動的に導体を配線し、部品を配置する。半導体回路の設計が完了すると、標準化された電子フォーマット(例えば、Opus、GDSII等)の結果として得られる設計を、製造のための半導体製造施設または「ファブ」に送信することができる。
前述の説明は、例示的かつ非限定的な例として、本発明の例示的な実施形態の十分かつ詳細な説明を提供するものである。しかしながら、添付の図面および添付の特許請求の範囲と併せて読めば、上記の説明を考慮して、当業者には様々な修正および適合が明らかになるであろう。しかしながら、本発明の教示の全てのそのような変更および類似の変更は、依然として本発明の範囲内に含まれる。