一般に、本開示は、階層化高効率ビデオコーディング(L-HEVC:Layered High Efficiency Video Coding)ビットストリームなどの、符号化ビデオデータのマルチレイヤビットストリームを記憶するためのファイルを生成および処理するための技法に関する。マルチレイヤビットストリームは、複数のレイヤを備える。各レイヤは、異なる出力時間において出現する符号化ピクチャのシーケンスを備える。スケーラブルビデオコーディングの場合、マルチレイヤビットストリームのレイヤは、ベースレイヤおよび1つまたは複数のエンハンスメントレイヤを含み得る。ベースレイヤは、エンハンスメントレイヤのいずれも参照することなく復号可能である。エンハンスメントレイヤは、ベースレイヤのピクチャを空間的または時間的に拡張し得る。たとえば、エンハンスメントレイヤは、フレームレートがベースレイヤよりも高くてよい。したがって、エンハンスメントレイヤは、ある出力時間に対する符号化ピクチャを含み得、ベースレイヤは、その出力時間に対する符号化ピクチャを含まない。マルチレイヤビットストリームの第1のレイヤが、ある出力時間における符号化ピクチャを含み、マルチレイヤビットストリームの第2のレイヤが、その出力時間に対する符号化ピクチャを含まない場合、第1のレイヤにおける符号化ピクチャは、第2のレイヤにおける符号化ピクチャと位置合わせされていないと言われる。マルチビュービデオコーディングでは、マルチレイヤビットストリームのレイヤは、異なるビューにおける符号化ピクチャに対応し得る。
マルチレイヤビットストリームの動作点は、マルチレイヤビットストリームの中の1つまたは複数のレイヤのセット、および最大時間識別子によって規定され得る。たとえば、特定の動作点が、マルチレイヤビットストリームの中のレイヤの全セットのうちの特定のサブセット、およびマルチレイヤビットストリームの中の最大時間識別子以下の最大時間識別子として規定され得る。マルチレイヤビットストリームの動作点における符号化ピクチャは、動作点にないマルチレイヤビットストリームの符号化ピクチャを復号することなく復号され得る。
動作点は、様々な理由で有用である。たとえば、デバイスは、マルチレイヤビットストリームの特定の動作点をクライアントデバイスへ転送することを選んでよいが、動作点にないマルチレイヤビットストリームの部分を転送しなくてよい。その結果、転送されるデータの量が低減され得る。このことは、帯域幅が制約された環境において望ましいことがある。さらに、同じマルチレイヤビットストリームの異なる動作点は、異なるデコーダ機能が実行されることを必要とし得る。したがって、デコーダが、マルチレイヤビットストリームの第1の動作点を復号できるが、同じマルチレイヤビットストリームの第2の動作点を復号できない場合、第1の動作点にはない、第2の動作点におけるマルチレイヤビットストリームのデータを送ることは無駄であり得る。
国際標準化機構(ISO)ベースメディアファイルフォーマットは、オーディオデータやビデオデータなどのメディアデータの記憶用のファイルフォーマットである。ISOベースメディアファイルフォーマットは、特定のシナリオ向けに拡張されている。たとえば、L-HEVCビットストリームの記憶向けにISOベースメディアファイルフォーマットを拡張するための取組みが進行中である。ISOベースメディアファイルフォーマットでは、メディアデータは、1つまたは複数のトラックに編成され得る。さらに、ISOベースメディアファイルフォーマットおよびそれの拡張では、「サンプル」という用語は、ビデオアクセスユニットまたはオーディオアクセスユニットなどのメディアアクセスユニットに適用される。しかしながら、コーデックレベルにおいて、「サンプル」という用語は、ピクセルのカラー成分の値に適用され得る。ビデオアクセスユニットは、同じ出力時間を有する1つまたは複数の符号化ピクチャを含み得る。異なるトラックは、マルチレイヤビットストリームの異なるレイヤの符号化ピクチャを備えるサンプルを含み得る。いくつかの事例では、トラックは、マルチレイヤビットストリームの2つ以上のレイヤの符号化ピクチャを備えるサンプルを含み得る。他の事例では、トラックは、マルチレイヤビットストリームの単一のレイヤのコード化ピクチャしか含まないサンプルを含み得る。
ISOベースメディアファイルフォーマットは、サンプルをグルーピングして「サンプルグループ」にするためのメカニズムを提供する。たとえば、ISOベースメディアファイルフォーマットは、互いの内側でネストされ得る「ボックス」と呼ばれるデータ構造として構造化される。ファイルのボックスは、ファイルのトラック用のトラックボックスを含み得る。トラック用のトラックボックスは、トラックに関するメタデータを含む。たとえば、トラックボックスは、その各々がサンプルグループの記述を含む、サンプルグループ記述エントリのセットを含むサンプル記述ボックスを含み得る。追加として、トラック用のトラックボックスは、トラックの中のサンプルのセットを示すとともに、サンプルグループ記述エントリボックスの中のサンプルグループ記述エントリのインデックスを指定し、それによって、示されたサンプルが属するサンプルグループを指定する、サンプルツーグループ(sample-to-group)ボックスを含み得る。
L-HEVC用のISOベースメディアファイルフォーマットの拡張のドラフトは、動作点情報サンプルグループを提供する。動作点情報サンプルグループに属するサンプルは、動作点の符号化ピクチャを備えるサンプルを含む。動作点情報サンプルグループに対するサンプルグループ記述エントリは、動作点の出力レイヤセット、動作点の最大時間識別子、ならびに動作点に対するプロファイル、ティア、およびレベル情報の任意の組合せなどの、動作点に関する情報を指定し得る。ファイルの中で動作点情報サンプルグループを指定することは、L-HEVCデータなどの、その下にある符号化ビデオデータを解釈することを必要とせずに、デバイスがファイルから動作点を抽出することを可能にし得る。したがって、上記のことは、デバイスを簡略化し得、応答性を高め得る。
L-HEVC用のISOベースメディアファイルフォーマットの拡張のドラフトは、ファイルの中のサンプルツーグループボックスおよびサンプルグループ記述ボックスが、ファイルの1つのトラック(すなわち、動作点参照トラック)のみに対してメタデータに含まれることを規定する。上述のように、トラック用のトラックボックスの中のサンプルツーグループボックスは、トラックの中のサンプルを指定する。しかしながら、やはり上述のように、マルチレイヤビットストリームのレイヤは異なるトラックに含まれることがあり、レイヤは位置合わせされていない符号化ピクチャを含むことがある。したがって、追加トラックの特定のサンプルが動作点情報サンプルグループの中にあることを、動作点参照トラック用のトラックボックスの中のサンプルツーグループボックスは示すことができないことがある。たとえば、動作点参照トラックが出力時間1、3、および5においてサンプルを含み、追加トラックが出力時間1、2、3、4、5、および6においてサンプルを含むとき、出力時間6における追加トラックのサンプルにおける符号化ピクチャが、動作点サンプルグループが対応する動作点の間違いなく一部であるにもかかわらず、サンプルツーグループボックスは、出力時間6における追加トラックのサンプルが動作点サンプルグループの一部であることを規定できないことがある。その結果、デバイスは、ファイルから動作点を正しく抽出できるかもしれない。本開示では、トラックがサンプルグループに属するサンプルを含むとき、トラックは、そのサンプルグループを含むと言われてよい。
本開示は、この問題に対処する様々な技法を説明する。たとえば、1つまたは複数の追加トラックのうちの各それぞれの追加トラックのそれぞれのサンプルごとに、デバイスは、それぞれのサンプルを動作点情報サンプルグループの一部と見なすべきかどうかを決定し得る。この例では、それぞれの追加トラックの中のそれぞれのサンプルと時間的にコロケートされているサンプルを動作点参照トラックが含むことに基づいて、それぞれの追加トラックの中のそれぞれのサンプルは、動作点情報サンプルグループの一部と見なされる。さらに、この例では、それぞれの追加トラックの中のそれぞれのサンプルと時間的にコロケートされているサンプルを動作点参照トラックが含まないことに基づいて、それぞれの追加トラックの中のそれぞれのサンプルは、それぞれの追加トラックのそれぞれのサンプルよりも前の、動作点参照トラックの中の最終サンプルの動作点情報サンプルグループの一部と見なされる。したがって、前の段落の例では、出力時間6における追加トラックのサンプルは、動作点サンプルグループの一部と見なされることになる。
図1は、本開示の技法を利用し得る例示的なビデオコーディングシステム10を示すブロック図である。本明細書で使用する「ビデオコーダ」という用語は、ビデオエンコーダとビデオデコーダの両方を総称的に指す。本開示では、「ビデオコーディング」または「コーディング」という用語は、ビデオ符号化またはビデオ復号を総称的に指すことがある。
図1に示すように、ビデオコーディングシステム10は、ソースデバイス12および宛先デバイス14を含む。ソースデバイス12は、符号化ビデオデータを生成する。したがって、ソースデバイス12は、ビデオ符号化デバイスまたはビデオ符号化装置と呼ばれることがある。宛先デバイス14は、ソースデバイス12によって生成された符号化ビデオデータを復号し得る。したがって、宛先デバイス14は、ビデオ復号デバイスまたはビデオ復号装置と呼ばれることがある。ソースデバイス12および宛先デバイス14は、ビデオコーディングデバイスまたはビデオコーディング装置の例であり得る。本開示は、ビデオデータを処理するデバイスを指すために、「ビデオ処理デバイス」という用語を使用し得る。ソースデバイス12および宛先デバイス14は、ビデオ処理デバイスの例である。他のタイプのビデオ処理デバイスは、MPEG-2データストリームなどのメディアデータをマルチプレクスおよびデマルチプレクスするデバイスを含む。
ソースデバイス12および宛先デバイス14は、デスクトップコンピュータ、モバイルコンピューティングデバイス、ノートブック(たとえば、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、車載コンピュータなどを含む、広範囲のデバイスを備え得る。
宛先デバイス14は、ソースデバイス12からチャネル16を介して符号化ビデオデータを受信し得る。チャネル16は、ソースデバイス12から宛先デバイス14に符号化ビデオデータを移動させることが可能な、1つまたは複数の媒体またはデバイスを備え得る。一例では、チャネル16は、ソースデバイス12が符号化ビデオデータをリアルタイムで宛先デバイス14へ直接送信することを可能にする、1つまたは複数の通信媒体を備え得る。この例では、ソースデバイス12は、ワイヤレス通信プロトコルなどの通信規格に従って符号化ビデオデータを変調し得、被変調ビデオデータを宛先デバイス14へ送信し得る。1つまたは複数の通信媒体は、無線周波数(RF)スペクトルまたは1つもしくは複数の物理伝送線路などの、ワイヤレスおよび/または有線の通信媒体を含み得る。1つまたは複数の通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはグローバルネットワーク(たとえば、インターネット)などの、パケットベースネットワークの一部を形成し得る。1つまたは複数の通信媒体は、ルータ、スイッチ、基地局、またはソースデバイス12から宛先デバイス14への通信を容易にする他の機器を含み得る。
別の例では、チャネル16は、ソースデバイス12によって生成された符号化ビデオデータを記憶する記憶媒体を含み得る。この例では、宛先デバイス14は、たとえば、ディスクアクセスまたはカードアクセスを介して記憶媒体にアクセスし得る。記憶媒体は、Blu-ray(登録商標)ディスク、DVD、CD-ROM、フラッシュメモリ、または符号化ビデオデータを記憶するための他の好適なデジタル記憶媒体などの、ローカルにアクセスされる様々なデータ記憶媒体を含み得る。
さらなる例では、チャネル16は、ファイルサーバ、またはソースデバイス12によって生成された符号化ビデオデータを記憶する別の中間記憶デバイスを含み得る。この例では、宛先デバイス14は、ファイルサーバまたは他の中間記憶デバイスにおいて記憶された符号化ビデオデータに、ストリーミングまたはダウンロードを介してアクセスし得る。ファイルサーバは、符号化ビデオデータを記憶し、符号化ビデオデータを宛先デバイス14へ送信することが可能なタイプのサーバであってよい。例示的なファイルサーバは、(たとえば、ウェブサイト用の)ウェブサーバ、ファイル転送プロトコル(FTP)サーバ、ネットワーク接続ストレージ(NAS)デバイス、およびローカルディスクドライブを含む。ファイルサーバは、本開示の技法に従って生成されるファイルの中に記憶された符号化ビデオデータをストリーミングし得る。
宛先デバイス14は、インターネット接続などの標準的なデータ接続を通じて、符号化ビデオデータにアクセスし得る。例示的なタイプのデータ接続は、ファイルサーバに記憶された符号化ビデオデータにアクセスするのに適した、ワイヤレスチャネル(たとえば、Wi-Fi接続)、有線接続(たとえば、DSL、ケーブルモデムなど)、または両方の組合せを含み得る。ファイルサーバからの符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、または両方の組合せであってよい。
本開示の技法は、ワイヤレスの用途または設定に限定されない。技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、たとえば、インターネットを介したストリーミングビデオ送信、データ記憶媒体に記憶するためのビデオデータの符号化、データ記憶媒体に記憶されたビデオデータの復号、または他の用途などの、様々なマルチメディア用途をサポートするビデオコーディングに適用され得る。いくつかの例では、ビデオコーディングシステム10は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および/またはビデオ電話などの用途をサポートするために、単方向または双方向のビデオ送信をサポートするように構成され得る。
図1に示すビデオコーディングシステム10は例にすぎず、本開示の技法は、符号化デバイスと復号デバイスとの間の任意のデータ通信を必ずしも含むとは限らないビデオコーディングの設定(たとえば、ビデオ符号化またはビデオ復号)に適用され得る。他の例では、データは、ローカルメモリからの取出し、ネットワークを介したストリーミングなどが行われる。ビデオ符号化デバイスは、データを符号化し得るとともにメモリに記憶し得、かつ/またはビデオ復号デバイスは、データをメモリから取り出し得るとともに復号し得る。多くの例では、互いに通信しないが、単にデータをメモリへ符号化し、かつ/またはデータをメモリから取り出し復号するデバイスによって、符号化および復号が実行される。
図1の例では、ソースデバイス12は、ビデオソース18、ビデオエンコーダ20、および出力インターフェース22を含む。いくつかの例では、出力インターフェース22は、変調器/復調器(モデム)および/または送信機を含み得る。ビデオソース18は、ビデオキャプチャデバイス、たとえば、ビデオカメラ、以前にキャプチャされたビデオデータを含むビデオアーカイブ、ビデオデータをビデオコンテンツプロバイダから受信するためのビデオフィードインターフェース、および/もしくはビデオデータを生成するためのコンピュータグラフィックスシステム、またはビデオデータのそのようなソースの組合せを含み得る。
ビデオエンコーダ20は、ビデオソース18からのビデオデータを符号化し得る。いくつかの例では、ソースデバイス12は、出力インターフェース22を介して符号化ビデオデータを宛先デバイス14へ直接送信する。他の例では、符号化ビデオデータはまた、復号および/または再生のために宛先デバイス14によって後でアクセスできるように、記憶媒体またはファイルサーバの中へ記憶され得る。
図1の例では、宛先デバイス14は、入力インターフェース28、ビデオデコーダ30、およびディスプレイデバイス32を含む。いくつかの例では、入力インターフェース28は、受信機および/またはモデムを含む。入力インターフェース28は、チャネル16を介して符号化ビデオデータを受信し得る。ディスプレイデバイス32は、宛先デバイス14と統合されてよく、または宛先デバイス14の外部にあってもよい。一般に、ディスプレイデバイス32は、復号されたビデオデータを表示する。ディスプレイデバイス32は、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスなどの、様々なディスプレイデバイスを備え得る。
ビデオエンコーダ20およびビデオデコーダ30は各々、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、個別論理回路、ハードウェア、またはそれらの任意の組合せなどの、様々な好適な回路構成のいずれかとして実装され得る。技法が部分的にソフトウェアで実装される場合、デバイスは、ソフトウェアのための命令を、好適な非一時的コンピュータ可読記憶媒体に記憶してよく、1つまたは複数のプロセッサを使用するハードウェアにおいて命令を実行して、本開示の技法を実行し得る。上記のもの(ハードウェア、ソフトウェア、ハードウェアとソフトウェアの組合せなどを含む)のいずれもが、1つまたは複数のプロセッサであると見なされてよい。ビデオエンコーダ20およびビデオデコーダ30の各々は、1つまたは複数のエンコーダまたはデコーダに含まれてよく、それらのいずれかが、それぞれのデバイスの中の複合エンコーダ/デコーダ(コーデック)の一部として統合されてよい。
本開示は、全般に、ビデオエンコーダ20がいくつかの情報をビデオデコーダ30などの別のデバイスへ「シグナリングすること」または「送信すること」に言及することがある。「シグナリングすること」または「送信すること」という用語は、概して、シンタックス要素、および/または圧縮ビデオデータを復号するために使用される他のデータの通信を指すことがある。そのような通信は、リアルタイムで、またはほぼリアルタイムで行われてよい。代替的に、そのような通信は、ある時間の範囲にわたって行われてよく、たとえば、符号化の時点において符号化ビットストリームの中のシンタックス要素をコンピュータ可読記憶媒体に記憶するときに行われる場合があり、次いで、この媒体に記憶された後の任意の時点において、復号デバイスによってシンタックス要素が取り出されてよい。
さらに、図1の例では、ビデオコーディングシステム10は、ファイル生成デバイス34を含む。ファイル生成デバイス34は、ソースデバイス12によって生成された符号化ビデオデータを受信し得る。ファイル生成デバイス34は、符号化ビデオデータを含むファイルを生成し得る。宛先デバイス14は、ファイル生成デバイス34によって生成されたファイルを受信し得る。様々な例では、ソースデバイス12および/またはファイル生成デバイス34は、様々なタイプのコンピューティングデバイスを含み得る。たとえば、ソースデバイス12および/またはファイル生成デバイス34は、ビデオ符号化デバイス、メディアアウェアネットワーク要素(MANE:Media Aware Network Element)、サーバコンピューティングデバイス、パーソナルコンピューティングデバイス、専用コンピューティングデバイス、商用コンピューティングデバイス、または別のタイプのコンピューティングデバイスを備え得る。いくつかの例では、ファイル生成デバイス34は、コンテンツ配信ネットワークの一部である。ソースデバイス12および/またはファイル生成デバイス34は、ソースデバイス12からリンク16などのチャネルを介して符号化ビデオデータを受信し得る。さらに、宛先デバイス14は、ファイル生成デバイス34からリンク16などのチャネルを介してファイルを受信し得る。ファイル生成デバイス34は、ビデオデバイスと見なされてよい。図1の例に示すように、ファイル生成デバイス34は、符号化ビデオコンテンツを含むファイルを記憶するように構成されたメモリ31を備え得る。
いくつかの例では、ソースデバイス12または別のコンピューティングデバイスが、符号化ビデオデータを含むファイルを生成し得る。説明を簡単にするために、本開示は、ファイルを生成するものとしてソースデバイス12またはファイル生成デバイス34を説明することがある。とはいえ、そのような説明が全般にコンピューティングデバイスに適用可能であることを理解されたい。
本開示で説明する技法は、特定のビデオコーディング規格に関係しないビデオコーディング技法を含む、様々なビデオコーディング規格とともに使用され得る。ビデオコーディング規格の例は、そのスケーラブルビデオコーディング(SVC)拡張およびマルチビュービデオコーディング(MVC)拡張を含む、ITU-T H.261、ISO/IEC MPEG-1 Visual、ITU-T H.262またはISO/IEC MPEG-2 Visual、ITU-T H.263、ISO/IEC MPEG-4 Visual、およびITU-T H.264(ISO/IEC MPEG-4 AVCとも呼ばれる)を含む。いくつかの例では、ビデオエンコーダ20およびビデオデコーダ30は、HEVC規格などのビデオ圧縮規格に従って動作する。ベースのHEVC規格に加えて、HEVCのためのスケーラブルビデオコーディング拡張、マルチビュービデオコーディング拡張、および3Dコーディング拡張を創り出すための取組みが進行中である。HEVC、MV-HEVCという名称のHEVCへのマルチビュー拡張、およびSHVCという名称のHEVCへのスケーラブル拡張が、ITU-Tビデオコーディングエキスパートグループ(VCEG)とISO/IECモーションピクチャエキスパートグループ(MPEG)とのビデオコーディング共同研究部会(JCT-VC)によって、最近確定されている。HEVC規格は、Rec. ITU-T H.265 | ISO/IEC23008 2と呼ばれることもある。
ITU-T SG 16 WP 3とISO/IEC JTC 1/SC 29/WG 11とのJCT-VCの第18回会合、札幌、日本、2014年6月30日〜7月9日に関する、「Draft high efficiency video coding (HEVC) version 2, combined format range extensions (RExt), scalability (SHVC), and multi-view (MV-HEVC) extensions」と題するHEVCドラフト仕様(JCTVC-R1013_v6)(以下で「JCTVC-R1013」または「Rec. ITU-T H.265 | ISO/IEC23008 2」と呼ぶ)は、http://phenix.int-evry.fr/jct/doc_end_user/documents/18_Sapporo/wg11/JCTVC-R1013-v6.zipから入手可能である。MV-HEVCは、Rec. ITU-T H.265 | ISO/IEC23008 2のAnnex Gとして組み込まれている。SHVCは、Rec. ITU-T H.265 | ISO/IEC23008 2のAnnex Hとして組み込まれている。
HEVCおよび他のビデオコーディング規格では、ビデオシーケンスは、通常、一連のピクチャを含む。ピクチャは、「フレーム」と呼ばれることもある。ピクチャは、1つまたは複数のサンプルアレイを含み得る。たとえば、ピクチャは、SL、SCb、およびSCrと示される3つのサンプルアレイを含み得る。SLは、ルーマサンプルの2次元アレイ(すなわち、ブロック)である。SCbは、Cbクロミナンスサンプルの2次元アレイである。SCrは、Crクロミナンスサンプルの2次元アレイである。クロミナンスサンプルは、本明細書で「クロマ」サンプルと呼ばれることもある。他の事例では、ピクチャはモノクロームであってよく、ルーマサンプルのアレイしか含まないことがある。
ピクチャの符号化表現を生成するために、ビデオエンコーダ20は、コーディングツリーユニット(CTU:coding tree unit)のセットを生成し得る。CTUの各々は、ルーマサンプルのコーディングツリーブロック、クロマサンプルの2つの対応するコーディングツリーブロック、およびコーディングツリーブロックのサンプルをコーディングするために使用されるシンタックス構造であり得る。コーディングツリーブロックは、サンプルのN×Nブロックであり得る。CTUは、「ツリーブロック」または「最大コーディングユニット」(LCU:largest coding unit)と呼ばれることもある。HEVCのCTUは、H.264/AVCなどの他の規格のマクロブロックと概して類似し得る。しかしながら、CTUは、必ずしも特定のサイズに限定されるとは限らず、1つまたは複数のコーディングユニット(CU)を含み得る。スライスは、ラスタ走査順序などの走査順序で連続的に順序付けられた整数個のCTUを含み得る。本開示では、「コード化ピクチャ」または「符号化ピクチャ」という用語は、ピクチャのすべてのコーディングツリーユニットを含む、ピクチャのコード化表現を指すことがある。
コード化CTUを生成するために、ビデオエンコーダ20は、CTUのコーディングツリーブロック上で4分木区分を再帰的に実行してコーディングツリーブロックをコーディングブロックに分割し得、したがって、「コーディングツリーユニット」という名前である。コーディングブロックは、サンプルのN×Nブロックである。CUは、ルーマサンプルアレイ、Cbサンプルアレイ、およびCrサンプルアレイを有するピクチャの、ルーマサンプルのコーディングブロック、およびクロマサンプルの2つの対応するコーディングブロック、ならびにコーディングブロックのサンプルをコーディングするために使用されるシンタックス構造であり得る。モノクロピクチャ、または3つの別個のカラープレーンを有するピクチャでは、CUは、単一のコーディングブロック、およびコーディングブロックのサンプルをコーディングするために使用されるシンタックス構造を備え得る。
ビデオエンコーダ20は、CUのコーディングブロックを1つまたは複数の予測ブロックに区分し得る。予測ブロックは、同じ予測が適用されるサンプルの長方形(すなわち、正方形または非正方形)のブロックであり得る。CUの予測ユニット(PU)は、ピクチャの、ルーマサンプルの予測ブロック、クロマサンプルの2つの対応する予測ブロック、および予測ブロックサンプルを予測するために使用されるシンタックス構造であり得る。ビデオエンコーダ20は、CUの各PUのルーマ予測ブロック、Cb予測ブロック、およびCr予測ブロックに対する、予測ルーマブロック、予測Cbブロック、および予測Crブロックを生成し得る。モノクロピクチャ、または3つの別個のカラープレーンを有するピクチャでは、PUは、単一の予測ブロック、および予測ブロックを予測するために使用されるシンタックス構造を備え得る。
ビデオエンコーダ20は、PUの予測ブロックを生成するためにイントラ予測またはインター予測を使用し得る。ビデオエンコーダ20がPUの予測ブロックを生成するためにイントラ予測を使用する場合、ビデオエンコーダ20は、PUに関連するピクチャの復号サンプルに基づいて、PUの予測ブロックを生成し得る。ビデオエンコーダ20がPUの予測ブロックを生成するためにインター予測を使用する場合、ビデオエンコーダ20は、PUに関連するピクチャ以外の1つまたは複数のピクチャの復号サンプルに基づいて、PUの予測ブロックを生成し得る。
ビデオエンコーダ20がCUの1つまたは複数のPUの予測ブロックを生成した後、ビデオエンコーダ20は、CUの残差ブロックを生成し得る。CUの残差ブロックの中の各サンプルは、CUのPUに対する予測ブロックの中のサンプルとCUのコーディングブロックの中の対応するサンプルとの差分を示す。たとえば、ビデオエンコーダ20は、CUのルーマ残差ブロックを生成し得る。CUのルーマ残差ブロックの中の各サンプルは、CUのPUの予測ルーマブロックの中のルーマサンプルとCUのルーマコーディングブロックの中の対応するサンプルとの差分を示す。加えて、ビデオエンコーダ20は、CUのCb残差ブロックを生成し得る。CUのCb残差ブロックの中の各サンプルは、CUのPUの予測Cbブロックの中のCbサンプルとCUのCbコーディングブロックの中の対応するサンプルとの差分を示し得る。ビデオエンコーダ20はまた、CUのCr残差ブロックを生成し得る。CUのCr残差ブロックの中の各サンプルは、CUのPUの予測Crブロックの中のCrサンプルとCUのCrコーディングブロックの中の対応するサンプルとの差分を示し得る。
さらに、ビデオエンコーダ20は、4分木区分を使用してCUの残差ブロックを1つまたは複数の変換ブロックに分解し得る。変換ブロックは、同じ変換が適用されるサンプルの長方形ブロックであり得る。CUの変換ユニット(TU)は、ルーマサンプルの変換ブロック、クロマサンプルの2つの対応する変換ブロック、および変換ブロックサンプルを変換するために使用されるシンタックス構造であり得る。したがって、CUの各TUは、ルーマ変換ブロック、Cb変換ブロック、およびCr変換ブロックに関連し得る。TUに関連するルーマ変換ブロックは、CUのルーマ残差ブロックのサブブロックであり得る。Cb変換ブロックは、CUのCb残差ブロックのサブブロックであり得る。Cr変換ブロックは、CUのCr残差ブロックのサブブロックであり得る。モノクロピクチャ、または3つの別個のカラープレーンを有するピクチャでは、TUは、単一の変換ブロック、および変換ブロックのサンプルを変換するために使用されるシンタックス構造を備え得る。
ビデオエンコーダ20は、1つまたは複数の変換をTUに対する変換ブロックに適用して、TUの係数ブロックを生成し得る。たとえば、ビデオエンコーダ20は、1つまたは複数の変換をTUに対するルーマ変換ブロックに適用して、TUに対するルーマ係数ブロックを生成し得る。ビデオエンコーダ20は、1つまたは複数の変換をTUのCb変換ブロックに適用して、TUに対するCb係数ブロックを生成し得る。ビデオエンコーダ20は、1つまたは複数の変換をTUのCr変換ブロックに適用して、TUに対するCr係数ブロックを生成し得る。係数ブロックは、変換係数の2次元アレイであり得る。変換係数は、スカラー量であり得る。
係数ブロックを生成した後、ビデオエンコーダ20は、係数ブロックを量子化し得る。量子化は、概して、変換係数を表すために使用されるデータの量をできる限り減らすために変換係数が量子化され、さらなる圧縮をもたらすプロセスを指す。ビデオエンコーダ20が係数ブロックを量子化した後、ビデオエンコーダ20は、量子化変換係数を示すシンタックス要素をエントロピー符号化し得る。たとえば、ビデオエンコーダ20は、量子化変換係数を示すシンタックス要素に対してコンテキスト適応型バイナリ算術コーディング(CABAC)を実行し得る。ビデオエンコーダ20は、エントロピー符号化されたシンタックス要素をビットストリームの中に出力し得る。
ビデオエンコーダ20は、コード化ピクチャの表現および関連するデータを形成するビットのシーケンスを含む、ビットストリームを出力し得る。ビットストリームは、ネットワークアブストラクションレイヤ(NAL:network abstraction layer)ユニットのシーケンスを備え得る。NALユニットの各々は、NALユニットヘッダを含み、ローバイトシーケンスペイロード(RBSP:raw byte sequence payload)をカプセル化する。NALユニットヘッダは、NALユニットタイプコードを示すシンタックス要素を含み得る。NALユニットのNALユニットヘッダによって指定されるNALユニットタイプコードは、NALユニットのタイプを示す。RBSPは、NALユニット内にカプセル化されている整数個のバイトを含むシンタックス構造であり得る。いくつかの事例では、RBSPは0個のビットを含む。
異なるタイプのNALユニットは、異なるタイプのRBSPをカプセル化し得る。たとえば、異なるタイプのNALユニットは、ビデオパラメータセット(VPS:video parameter set)、シーケンスパラメータセット(SPS:sequence parameter set)、ピクチャパラメータセット(PPS:picture parameter set)、コード化スライス、補足エンハンスメント情報(SEI:supplemental enhancement information)などに対して、異なるRBSPをカプセル化し得る。たとえば、第1のタイプのNALユニットはPPSに対してRBSPをカプセル化してよく、第2のタイプのNALユニットはコード化スライスに対してRBSPをカプセル化してよく、第3のタイプのNALユニットは補足エンハンスメント情報(SEI)に対してRBSPをカプセル化してよく、以下同様である。ビデオコーディングデータに対してRBSPをカプセル化するNALユニットは(パラメータセットおよびSEIメッセージに対するRBSPとは対照的に)、ビデオコーディングレイヤ(VCL)NALユニットと呼ばれることがある。たとえば、JCTVC-R1013は、VCL NALユニットという用語が、コード化スライスセグメントNALユニット、およびJCTVC-R1013においてVCL NALユニットとして分類されるnal_unit_typeの予約済み値を有する、NALユニットのサブセットに対する包括的な用語であると定義する。SEIは、VCL NALユニットからのコード化ピクチャのサンプルを復号するのに必要でない情報を含む。
図1の例では、ビデオデコーダ30は、ビデオエンコーダ20によって生成されたビットストリームを受信する。いくつかの例では、宛先デバイス14または別のデバイスがファイルからビットストリームを取得した後、ビデオデコーダ30はビットストリームを受信する。加えて、ビデオデコーダ30は、ビットストリームからシンタックス要素を取得するために、ビットストリームを構文解析し得る。ビデオデコーダ30は、ビットストリームから取得されたシンタックス要素に少なくとも部分的に基づいて、ビデオデータのピクチャを再構成し得る。ビデオデータを再構成するためのプロセスは、概して、ビデオエンコーダ20によって実行されるプロセスの逆であり得る。たとえば、ビデオデコーダ30は、イントラ予測またはインター予測を使用して、現在CUのPUの予測ブロックを決定し得る。加えて、ビデオデコーダ30は、現在CUのTUの係数ブロックを逆量子化し得る。ビデオデコーダ30は、係数ブロックに対して逆変換を実行して、現在CUのTUに対する変換ブロックを再構成し得る。ビデオデコーダ30は、現在CUのPUの予測ブロックのサンプルを、現在CUのTUに対する変換ブロックの対応するサンプルに加算することによって、現在CUのコーディングブロックを再構成し得る。ピクチャのCUごとにコーディングブロックを再構成することによって、ビデオデコーダ30はピクチャを再構成し得る。
上記で簡略に示したように、NALユニットは、ビデオパラメータセット(VPS)、シーケンスパラメータセット(SPS)、ピクチャパラメータセット(PPS)に対してRBSPをカプセル化し得る。VPSは、0個以上のコード化ビデオシーケンス(CVS:coded video sequence)全体に適用されるシンタックス要素を備えるシンタックス構造である。SPSも、0個以上のCVS全体に適用されるシンタックス要素を備えるシンタックス構造である。SPSは、SPSがアクティブであるときにアクティブであるVPSを識別するシンタックス要素を含み得る。したがって、VPSのシンタックス要素は、SPSのシンタックス要素よりも全般に適用可能であり得る。PPSは、0個以上のコード化ピクチャに適用されるシンタックス要素を備えるシンタックス構造である。PPSは、PPSがアクティブであるときにアクティブであるSPSを識別するシンタックス要素を含み得る。スライスのスライスヘッダは、スライスがコーディングされているときにアクティブであるPPSを示すシンタックス要素を含み得る。
「アクセスユニット」という用語は、同じ時間インスタンスに対応するピクチャのセットを指すために使用され得る。したがって、ビデオデータは、経時的に出現する一連のアクセスユニットとして概念化されてよい。「ビューコンポーネント」は、単一のアクセスユニットの中のビューのコード化表現であり得る。本開示では、「ビュー」は、同じビュー識別子に関連付けられたビューコンポーネントのシーケンスを指すことがある。いくつかの例では、ビューコンポーネントは、テクスチャビューコンポーネント(すなわち、テクスチャピクチャ)または深度ビューコンポーネント(すなわち、深度ピクチャ)であり得る。
MV-HEVCおよびSHVCでは、ビデオエンコーダは、一連のNALユニットを備えるビットストリームを生成し得る。ビットストリームの異なるNALユニットは、ビットストリームの異なるレイヤに関連し得る。レイヤは、同じレイヤ識別子を有するVCL NALユニットおよび関連する非VCL NALユニットのセットとして定義され得る。レイヤは、マルチビュービデオコーディングにおけるビューと等価であり得る。マルチビュービデオコーディングでは、レイヤは、異なる時間インスタンスを有する同じレイヤのすべてのビューコンポーネントを含むことができる。各ビューコンポーネントは、特定の時間インスタンスにおける特定のビューに属するビデオシーンのコード化ピクチャであり得る。マルチビュービデオコーディングまたは3次元ビデオコーディングのいくつかの例では、レイヤは、特定のビューのすべてのコード化深度ピクチャ、または特定のビューのコード化テクスチャピクチャのいずれかを含み得る。3Dビデオコーディングの他の例では、レイヤは、特定のビューのテクスチャビューコンポーネントと深度ビューコンポーネントの両方を含み得る。同様に、スケーラブルビデオコーディングのコンテキストでは、レイヤは、通常、他のレイヤの中のコード化ピクチャとは異なるビデオ特性を有するコード化ピクチャに対応する。そのようなビデオ特性は、通常、空間解像度および品質レベル(たとえば、信号対雑音比)を含む。HEVCおよびその拡張では、特定の時間レベルを有するピクチャグループをサブレイヤとして定義することによって、時間スケーラビリティが1つのレイヤ内で達成され得る。
ビットストリームのそれぞれのレイヤごとに、下位レイヤの中のデータは、いかなる上位レイヤの中のデータも参照せずに復号され得る。スケーラブルビデオコーディングでは、たとえば、ベースレイヤの中のデータは、エンハンスメントレイヤの中のデータを参照せずに復号され得る。一般に、NALユニットは、単一のレイヤのデータのみをカプセル化し得る。したがって、ビットストリームの残りの最上位レイヤのデータをカプセル化するNALユニットは、ビットストリームの残りのレイヤの中のデータの復号可能性に影響を及ぼすことなくビットストリームから除去され得る。マルチビューコーディングでは、上位レイヤは、追加のビューコンポーネントを含み得る。SHVCでは、上位レイヤは、信号対雑音比(SNR)エンハンスメントデータ、空間エンハンスメントデータ、および/または時間エンハンスメントデータを含み得る。MV-HEVCおよびSHVCでは、ビデオデコーダがいかなる他のレイヤのデータも参照せずにレイヤの中のピクチャを復号できる場合、そのレイヤは「ベースレイヤ」と呼ばれることがある。ベースレイヤは、HEVCベース仕様(たとえば、Rec. ITU-T H.265 | ISO/IEC23008 2)に準拠し得る。
スケーラブルビデオコーディングでは、ベースレイヤ以外のレイヤは、「エンハンスメントレイヤ」と呼ばれることがあり、ビットストリームから復号されたビデオデータの視覚的品質を向上させる情報を提供し得る。スケーラブルビデオコーディングは、空間解像度、信号対雑音比(すなわち、品質)、または時間的なレートを向上させることができる。スケーラブルビデオコーディング(たとえば、SHVC)では、「レイヤ表現」は、単一のアクセスユニットにおける空間レイヤのコード化表現であり得る。説明を簡単にするために、本開示は、ビューコンポーネントおよび/またはレイヤ表現を「ビューコンポーネント/レイヤ表現」または単に「ピクチャ」と呼ぶことがある。
マルチビューコーディングは、ビュー間予測をサポートする。ビュー間予測は、HEVCにおいて使用されるインター予測と類似であり、同じシンタックス要素を使用し得る。しかしながら、ビデオコーダが現在の(PUなどの)ビデオユニットに対してビュー間予測を実行するとき、ビデオエンコーダ20は、現在のビデオユニットと同じアクセスユニットの中にあるが異なるビューの中にあるピクチャを、参照ピクチャとして使用し得る。対照的に、従来のインター予測は、異なるアクセスユニットの中のピクチャしか参照ピクチャとして使用しない。
マルチビューコーディングでは、ビデオデコーダ(たとえば、ビデオデコーダ30)がいかなる他のビューの中のピクチャも参照せずにビューの中のピクチャを復号できる場合、そのビューは「ベースビュー」と呼ばれることがある。非ベースビューのうちの1つの中のピクチャをコーディングするとき、(ビデオエンコーダ20またはビデオデコーダ30などの)ビデオコーダは、ピクチャが異なるビューの中にあるがビデオコーダが現在コーディングしているピクチャと同じ時間インスタンス(すなわち、アクセスユニット)内にある場合、そのピクチャを参照ピクチャリストに追加し得る。他のインター予測参照ピクチャのように、ビデオコーダは、参照ピクチャリストの任意の位置にビュー間予測参照ピクチャを挿入し得る。
たとえば、NALユニットは、ヘッダ(すなわち、NALユニットヘッダ)およびペイロード(たとえば、RBSP)を含み得る。NALユニットヘッダは、nuh_layer_idシンタックス要素と呼ばれることもあるnuh_reserved_zero_6bitsシンタックス要素を含み得る。異なる値を指定するnuh_layer_idシンタックス要素を有するNALユニットは、ビットストリームの異なる「レイヤ」に属する。したがって、マルチビューコーディング、MV-HEVC、SVC、またはSHVCでは、NALユニットのnuh_layer_idシンタックス要素は、NALユニットのレイヤ識別子(すなわち、レイヤID)を指定する。NALユニットがマルチビューコーディング、MV-HEVC、またはSHVCにおけるベースレイヤに関係する場合、NALユニットのnuh_layer_idシンタックス要素は0に等しい。ビットストリームのベースレイヤの中のデータは、ビットストリームのいかなる他のレイヤの中のデータも参照せずに復号され得る。NALユニットがマルチビューコーディング、MV-HEVC、またはSHVCにおけるベースレイヤに関係しない場合、nuh_layer_idシンタックス要素は非0値を有し得る。マルチビューコーディングでは、ビットストリームの異なるレイヤは、異なるビューに対応し得る。SVCまたはSHVCでは、ベースレイヤ以外のレイヤは、「エンハンスメントレイヤ」と呼ばれることがあり、ビットストリームから復号されるビデオデータの視覚的品質を向上させる情報を提供し得る。
さらに、レイヤ内のいくつかのピクチャは、同じレイヤ内の他のピクチャを参照せずに復号され得る。したがって、レイヤのいくつかのピクチャのデータをカプセル化するNALユニットは、レイヤの中の他のピクチャの復号可能性に影響を及ぼすことなくビットストリームから除去され得る。そのようなピクチャのデータをカプセル化するNALユニットを除去すると、ビットストリームのフレームレートが低下し得る。レイヤ内の他のピクチャを参照せずに復号され得る、レイヤ内のピクチャのサブセットは、本明細書で「サブレイヤ」または「時間サブレイヤ」と呼ばれることがある。
NALユニットは、temporal_idシンタックス要素を含み得る。NALユニットのtemporal_idシンタックス要素は、NALユニットの時間識別子を指定する。NALユニットの時間識別子は、NALユニットが関連する時間サブレイヤを識別する。したがって、ビットストリームの各時間サブレイヤは、異なる時間識別子に関連付けられ得る。第1のNALユニットの時間識別子が第2のNALユニットの時間識別子よりも小さい場合、第1のNALユニットによってカプセル化されるデータは、第2のNALユニットによってカプセル化されるデータを参照せずに復号され得る。
ビットストリームは、複数の動作点に関連し得る。いくつかの例では、ビットストリームの各動作点は、レイヤ識別子のセット(すなわち、nuh_reserved_zero_6bits値のセット)および時間識別子に関連付けられ得る。レイヤ識別子のセットはOpLayerIdSetとして示されることがあり、時間識別子はTemporalIDとして示されることがある。NALユニットのレイヤ識別子がレイヤ識別子の動作点のセットの中にあり、NALユニットの時間識別子が動作点の時間識別子以下である場合、NALユニットは動作点に関連する。したがって、動作点は、サブビットストリーム抽出プロセスへの入力として別のビットストリーム、ターゲット最大TemporalID、およびターゲットレイヤ識別子リストを用いて、サブビットストリーム抽出プロセスの動作によって別のビットストリームから作成されたビットストリームであり得る。動作点は、動作点に関連する各NALユニットを含み得る。動作点は、動作点に関連しないVCL NALユニットを含まない。
出力レイヤセット(OLS:output layer set)は、VPSの中で指定されたレイヤセットのうちの1つのレイヤからなるレイヤのセットであり、ここで、レイヤのセットの中の1つまたは複数のレイヤは、出力レイヤであるものと示される。詳細には、layer_set_idx_for_ols_minus1[i]シンタックス要素+1が、i番目の出力レイヤセットのインデックスを指定する。1に等しいoutput_layer_flag[i][j]シンタックス要素は、i番目のOLSの中のj番目のレイヤが出力レイヤであることを規定する。0に等しいoutput_layer_flag[i][j]シンタックス要素は、i番目のOLSの中のj番目のレイヤが出力レイヤでないことを規定する。
HEVCおよび他のビデオコーディング規格は、プロファイル、ティア、およびレベルを規定する。プロファイル、ティア、およびレベルは、ビットストリームへの制約、したがって、ビットストリームを復号するために必要とされる機能への制限を規定する。プロファイル、ティア、およびレベルはまた、個々のデコーダの実装形態の間の相互運用性ポイントを示すために使用され得る。各プロファイルは、そのプロファイルに準拠するすべてのビデオデコーダによってサポートされるアルゴリズム的機能および制限のサブセットを規定する。ビデオエンコーダは、プロファイルにおいてサポートされるすべての機能を利用する必要はない。
ティアの各レベルは、シンタックス要素および変数が有し得る値への制限のセットを規定し得る。ティアおよびレベル定義の同じセットが、すべてのプロファイルとともに使用され得るが、個々の実装形態は、サポートされるプロファイルごとに、異なるティアを、またティア内で異なるレベルをサポートし得る。所与のプロファイルに対して、ティアのレベルは、概して、特定のデコーダ処理負荷およびメモリ能力に対応し得る。ビデオデコーダの機能は、特定のプロファイル、ティア、およびレベルの制約に準拠するビデオストリームを復号するための能力に関して規定され得る。そのようなプロファイルごとに、そのプロファイルのためにサポートされるティアおよびレベルも表され得る。いくつかのビデオデコーダは、特定のプロファイル、ティア、またはレベルを復号できないことがある。
HEVCでは、プロファイル、ティア、およびレベルは、シンタックス構造のprofile_tier_level( )シンタックス構造によってシグナリングされ得る。profile_tier_level( )シンタックス構造は、VPSおよび/またはSPSに含まれ得る。profile_tier_level( )シンタックス構造は、general_profile_idcシンタックス要素、general_tier_flagシンタックス要素、およびgeneral_level_idcシンタックス要素を含み得る。general_profile_idcシンタックス要素は、CVSが準拠するプロファイルを示し得る。general_tier_flagシンタックス要素は、general_level_idcシンタックス要素の解釈のためのティアコンテキストを示し得る。general_level_idcシンタックス要素は、CVSが準拠するレベルを示し得る。これらのシンタックス要素に対する他の値は、予約済みであり得る。
ビデオデコーダの機能は、プロファイル、ティア、およびレベルの制約に準拠するビデオストリームを復号するための能力に関して規定され得る。そのようなプロファイルごとに、そのプロファイルのためにサポートされるティアおよびレベルも表され得る。いくつかの例では、ビデオデコーダは、HEVCにおいて規定された値の間のgeneral_profile_idcシンタックス要素の予約済み値が、規定されたプロファイルの間の中間能力を示すとは推測しない。しかしながら、ビデオデコーダは、HEVCにおいて規定された値の間のgeneral_tier_flagシンタックス要素の特定の値に関連するgeneral_level_idcシンタックス要素の予約済み値が、ティアの規定されたレベルの間の中間能力を示すと推測し得る。
ファイルフォーマット規格は、ISOベースメディアファイルフォーマット(ISOBMFF、ISO/IEC14496-12)、ならびにMPEG-4ファイルフォーマット(ISO/IEC14496-15)、3GPPファイルフォーマット(3GPP TS26.244)、およびAVCファイルフォーマット(ISO/IEC14496-15)を含む、ISOBMFFから導出される他の規格を含む。ISO/IEC14496-12および14496-15に関する新版のドラフトテキストは、それぞれ、http://phenix.int-evry.fr/mpeg/doc_end_user/documents/111_Geneva/wg11/w15177-v6-w15177.zipおよびhttp://phenix.int-evry.fr/mpeg/doc_end_user/documents/112_Warsaw/wg11/w15479-v2-w15479.zipにおいて入手可能である。
ISOBMFFは、AVCファイルフォーマットなどの多くのコーデックカプセル化フォーマット用、ならびにMPEG-4ファイルフォーマット、3GPPファイルフォーマット(3GPP)、およびDVBファイルフォーマットなどの多くのマルチメディアコンテナフォーマット用の基礎として使用される。当初は記憶用に設計されたが、ISOBMFFは、ストリーミング用に、たとえば、プログレッシブダウンロード用またはDASH用に、非常に有益であることが証明されている。ストリーミングの場合、ISOBMFFにおいて定義されるムービーフラグメントが使用され得る。
オーディオやビデオなどの連続的なメディアに加えて、画像などの静的メディア、ならびにメタデータが、ISOBMFFに準拠するファイルに記憶され得る。ISOBMFFに従って構造化されたファイルは、ローカルメディアファイル再生、リモートファイルのプログレッシブダウンロード、動的適応ストリーミングオーバーHTTP(DASH)用のセグメント、ストリームされるべきコンテンツ用のコンテナおよびそのパケット化命令、ならびに受信されたリアルタイムメディアストリームの記録を含む、多くの目的のために使用され得る。
ボックスとは、ISOBMFFにおける基本シンタックス構造である。ボックスは、4文字コード化ボックスタイプ、ボックスのバイトカウント、およびペイロードを含む。ISOBMFFファイルはボックスのシーケンスからなり、ボックスは他のボックスを含んでよい。ムービーボックス(「moov」)は、各々がファイルの中でトラックとして表される、ファイルの中に存在している連続的なメディアストリーム用のメタデータを含む。トラック用のメタデータは、トラックボックス(「trak」)の中に封入され、トラックのメディアコンテンツは、メディアデータボックス(「mdat」)の中に封入されるか、または別個のファイルの中に直接封入されるかのいずれかである。トラック用のメディアコンテンツは、オーディオアクセスユニットまたはビデオアクセスユニットなどの、サンプルのシーケンスを備え得るか、またはサンプルのシーケンスからなり得る。
ISOBMFFは、以下のタイプのトラック、すなわち、エレメンタリメディアストリームを含むメディアトラック、メディア送信命令を含むか、または受信パケットストリームを表すかのいずれかであるヒントトラック、および時間同期されたメタデータを備える時限メタデータトラックを規定する。トラックごとのメタデータは、トラックにおいて使用されるコーディングフォーマットまたはカプセル化フォーマットおよびそのフォーマットを処理するために必要とされる初期化データを各々が提供する、サンプル記述エントリのリストを含む。各サンプルは、トラックのサンプル記述エントリのうちの1つに関連付けられる。
ISOBMFFは、様々なメカニズムを伴うサンプル固有メタデータを規定することを可能にする。たとえば、トラックボックスは、サンプルテーブル(「stbl」)ボックスを含む。トラックのサンプルテーブルボックスは、トラックのメディアサンプルのすべての時間およびデータインデックス付けを含む、サンプルテーブルを含む。サンプルテーブルは、トラックの特定のサンプルに対するサンプルエントリを含む。トラックのサンプルは、サンプルに適用可能なサンプルエントリを識別するシンタックス要素を含み得る。したがって、デバイスがサンプルを処理しているとき(たとえば、サンプルの符号化ピクチャを復号すること、サンプルを転送すること、サンプルを抽出することなどを準備しているとき)、デバイスは、サンプルをどのように処理すべきかを決定するために、サンプルテーブルボックスの中のサンプルエントリに戻って参照できる場合がある。
より詳細には、サンプルテーブルボックスは、サンプル記述(「stbl」)ボックスを含み得る。サンプル記述ボックスは、使用されるコーディングタイプについての詳細な情報、およびその復号にとって必要とされる任意の初期化情報を含み得る。このことを達成するために、サンプル記述ボックスは、サンプルエントリボックス(すなわち、サンプルエントリ)のセットを含む。以下のコードは、ISOBMFFの中のボックスの、サンプルエントリおよびサンプル記述ボックスクラスを定義する。
aligned(8) abstract class SampleEntry (unsigned int(32) format)
extends Box(format){
const unsigned int(8)[6] reserved = 0;
unsigned int(16) data_reference_index;
}
aligned(8) class SampleDescriptionBox (unsigned int(32) handler_type)
extends FullBox('stsd', version, 0){
int i ;
unsigned int(32) entry_count;
for (i = 1 ; i <= entry_count ; i++){
SampleEntry(); // SampleEntryから導出されるクラスのインスタンス
}
}
ISOBMFFでは、サンプルエントリクラスは、特定のメディアタイプに対して拡張されている抽象クラスである。たとえば、VisualSampleEntryクラスは、SampleEntryクラスを拡張し、ビデオデータに関する情報を含む。同様に、AudioSampleEntryクラスは、SampleEntryクラスを拡張し、オーディオデータに関する情報を含む。以下のコードは、ISOBMFFにおけるAudioSampleEntryクラスを定義する。
class VisualSampleEntry(codingname) extends SampleEntry (codingname){
unsigned int(16) pre_defined = 0;
const unsigned int(16) reserved = 0;
unsigned int(32)[3] pre_defined = 0;
unsigned int(16) width;
unsigned int(16) height;
template unsigned int(32) horizresolution = 0x00480000; // 72dpi
template unsigned int(32) vertresolution = 0x00480000; // 72dpi
const unsigned int(32) reserved = 0;
template unsigned int(16) frame_count = 1;
string[32] compressorname;
template unsigned int(16) depth = 0x0018;
int(16) pre_defined = -1;
// 仕様から導出される他のボックス
CleanApertureBox clap; //随意
PixelAspectRatioBox pasp; //随意
}
さらに、VisualSampleEntryクラスは、特定のコーデック用のデータを定義することなどの、さらにより特定の目的のために拡張され得る。たとえば、以下のコードは、VisualSampleEntryクラスを拡張するとともにHEVCに特有の情報を含む、HEVCSampleEntryクラスを定義する。
class HEVCSampleEntry() extends VisualSampleEntry ('hvc1' or 'hev1'){
HEVCConfigurationBox config;
MPEG4BitRateBox (); //随意
MPEG4ExtensionDescriptorsBox (); //随意
Box extra_boxes[]; //随意
}
上のコードに示すように、HEVCSampleEntryクラスは、HEVCConfigurationBoxクラスのインスタンスを含む。HEVCConfigurationBoxは、HEVCDecoderConfigurationRecordクラスのインスタンスを含む。HEVCDecoderConfigurationRecordクラスのインスタンスは、HEVCDecoderConfigurationRecordのインスタンスを含むサンプルエントリが適用されるべきサンプルにおけるコード化ピクチャを復号するためにデコーダが使用し得る情報を規定するシンタックス要素を含み得る。
さらに、VisualSampleEntryクラスを拡張するとともにL-HEVCに特有の情報を含む、LHEVCSampleEntryクラスが定義されている。LHEVCSampleEntryは、HEVC互換でないトラックの中で使用され得る。たとえば、ファイルのトラックがマルチレイヤビットストリームのベースレイヤしか含まない場合、トラックは、HEVCSampleEntryクラスのインスタンスを含み得る。ただし、この例では、マルチレイヤビットストリームの他のレイヤを搬送するファイルの他のトラックは、LHEVCSampleEntryクラスのインスタンスを含み得る。下のコードに示すように、LHEVCSampleEntryクラスは、LHEVCConfigurationBoxのインスタンスを含み、LHEVCConfigurationBoxは、LHEVCDecoderConfigurationRecordボックスを含む。
class LHEVCConfigurationBox extends Box('lhvC') {
LHEVCDecoderConfigurationRecord() LHEVCConfig;
}
class HEVCLHVCSampleEntry() extends HEVCSampleEntry() {
LHEVCConfigurationBox lhvcconfig;
}
// トラックがHEVC互換でない場合にこれを使用する。
class LHEVCSampleEntry() extends VisualSampleEntry ('lhv1', or 'lhe1') {
LHEVCConfigurationBox lhvcconfig;
MPEG4ExtensionDescriptorsBox (); //随意
}
サンプルテーブルボックス(「stbl」)内の特定のボックスは、共通の必要性に応じるように規格化されている。たとえば、トラックのランダムアクセスサンプルを列挙するために、Syncサンプルボックス(「stss」)が使用される。サンプルグルーピングメカニズムは、4文字グルーピングタイプによるサンプルを、ファイルの中でサンプルグループ記述エントリとして規定された同じ属性を共有するサンプルのグループにマッピングすることを可能にする。いくつかのグルーピングタイプが、ISOBMFFにおいて規定されている。
別の例示的なサンプルグループは、レイヤ情報(「linf」)サンプルグループである。レイヤ情報サンプルグループに対するサンプルグループ記述エントリは、トラックが含むレイヤおよびサブレイヤのリストを備える。レイヤのコード化ピクチャを含むトラックの各サンプルは、トラックの「linf」サンプルグループの一部であり得る。トラック用のサンプルグループ記述ボックスの中に1つまたは複数の「linf」サンプルグループエントリがあり得る。しかしながら、L-HEVCデータを含むトラックごとに1つの「linf」サンプルグループ記述エントリがあることが要件であり得る。以下のことは、「linf」サンプルグループに対するサンプルグループ記述エントリのためのシンタックスおよびセマンティクスを提供する。
9.8.2.2 シンタックス
class LayerInfoGroupEntry extends VisualSampleGroupEntry ('linf')) {
unsigned int (2) reserved;
unsigned int (6) num_layers_in_track;
for (i=0; i<num_layers_in_track; i++) {
unsigned int (4) reserved;
unsigned int (6) layer_id;
unsigned int (3) min_sub_layer_id;
unsigned int (3) max_sub_layer_id;
}
}
9.8.2.3 セマンティクス
num_layers_in_track:このサンプルグループに関連するこのトラックの任意のサンプルにおいて搬送されるレイヤの数。
layer_id:関連するサンプルにおいて搬送されるレイヤに対するレイヤID。このフィールドのインスタンスは、ループの中で昇順でなければならない。
min_sub_layer_id:トラック内のレイヤの中のサブレイヤに対する最小TemporalId値。
1.max_sub_layer_id:トラック内のレイヤの中のサブレイヤに対する最大TemporalId値。
2.このトラックの中で搬送されるレイヤのレイヤID、および他のトラックの中で搬送され、このトラックの中で搬送されるレイヤによって直接または間接的に参照されるレイヤのレイヤIDのリストを、layerListとする。layerListの中のレイヤIDは、レイヤID値の昇順で順序付けられる。たとえば、レイヤIDが4または5であるレイヤをこのトラックが搬送し、それらが0および1に等しいレイヤIDを有するレイヤを参照すると想定すると、このトラックに関連するlayerListは{0,1,4,5}である。
ISOBMFF仕様は、DASHとともに使用するために6つのタイプのストリームアクセスポイント(SAP:Stream Access Point)を規定する。最初の2つのSAPタイプ(タイプ1および2)は、H.264/AVCおよびHEVCにおける瞬時復号リフレッシュ(IDR:Instantaneous Decoding Refresh)ピクチャに対応する。第3のSAPタイプ(タイプ3)は、オープンピクチャグループ(GOP:Group of Pictures)ランダムアクセスポイント、したがって、HEVCにおけるブロークンリンクアクセス(BLA:Broken Link Access)ピクチャまたはクリーンランダムアクセス(CRA:Clean Random Access)ピクチャに対応する。第4のSAPタイプ(タイプ4)は、GDRランダムアクセスポイントに対応する。
ファイルフォーマットにおいて、L-HEVCレイヤの記憶のための14496-15に関する現在のドラフト仕様では、ファイルの中のビットストリームにとって利用可能な動作点のリストは、ビットストリームを搬送するトラックのうちの1つの中でシグナリングされる動作点(「oinf」)サンプルグループを使用して記述される。動作点サンプルグループは、本明細書で「動作点情報サンプルグループ」と呼ばれることもある。アプリケーションは、「oref」トラック参照に追従することによって、そのトラックを見つけることができる。簡単のために、「oinf」サンプルグループを含むトラックは、「oref」トラックとも呼ばれる。「oinf」サンプルグループは1つのトラックの中だけでシグナリングされるが、L-HEVCレイヤの記憶のための14496-15に関する現在のドラフト仕様では、「oinf」サンプルグループの範囲は、L-HEVCコード化データを搬送するすべてのトラックをカバーする。サンプルグループを使用して動作点のリストをシグナリングすることは、動作点のリストが時間次元において全体のビットストリームをカバーし得ないような結果となる。2つ以上の「oinf」サンプルグループが存在してよく、各サンプルグループはサンプルの異なるセットを含む。
図2は、「oinf」サンプルグループのカバレージの一例を示す概念図である。図2は、L-HEVCレイヤの記憶のための14496-15に関する現在のドラフト仕様による、2つの「oinf」サンプルグループ(40および42)のカバレージを示す。図2の例に示すように、サンプルグループ40およびサンプルグループ42は各々、トラック01、トラック02、およびトラック03の中のサンプルを含む。図2の例では、トラック01はベースレイヤ(BL)を含む。トラック02はエレメンタリストリームEL1を含み、エレメンタリストリームEL1は1つまたは複数のレイヤを含んでよい。トラック03はエレメンタリストリームEL2を含み、エレメンタリストリームEL2は1つまたは複数の追加のレイヤを含んでよい。図2の例では、各それぞれの影付きの長方形は、それぞれの単一のサンプルに対応する。トラック01は、図2における「oref」トラックである。他の例では、ベースレイヤを搬送するトラック以外のトラックが「oref」トラックであってよい。動作点参照トラックの各それぞれのサンプルおよび追加トラックの各それぞれのサンプルは、同じ時間インスタンスに対応する1つまたは複数の符号化ピクチャを備えるそれぞれのアクセスユニットを備える。
いくつかのアクセスユニット(または、いくつかの復号時間インスタンス)に対してNALユニットが一部のトラックの中にあるが他のトラックの中にはないという意味で、異なるトラックの中のサンプルが位置合わせされていないとき、動作点をシグナリングする上記の技法は問題があり得る。動作点はサンプルグループを使用してファイルレベルにおいてシグナリングされるので、時間次元において、サンプルグループは、サンプルグループを含むトラックの中に存在するサンプル、すなわち、多くともいくらかの範囲を伴う復号時間を有するサンプルしか含むことができない。したがって、特定のトラックの中のサンプルグループによって明瞭に規定され得る範囲の外部の復号時間を有するサンプルが、他のトラックの中にあり得る。問題の詳細が以下のテキストで説明される。
たとえば、ビットストリームの中のレイヤのフレームレートまたはピクチャレートが異なり、BLとは異なるトラックの中でELが搬送されるとき、ELを搬送するトラックの中にいかなる「oinf」サンプルグループによってもカバーされないサンプルがあり、ELを搬送するトラックの中に「oinf」サンプルグループのいずれの復号時間範囲内にもないサンプルがあり得る。たとえば、ELのフレームレートがBLのフレームレートの2倍であるとき、ELを搬送するトラックの中にいかなる「oinf」サンプルグループによってもカバーされないサンプルがある。
図3は、異なるフレームレートまたはピクチャレートを有するレイヤをトラックが含むときに起こる、例示的な問題を示す。図3の例では、ビットストリームは、ベースレイヤおよび1つまたは複数のエンハンスメントレイヤを含む。動作点参照トラック(すなわち、「oref」トラック)はベースレイヤを含み、1つまたは複数の追加トラックのうちの各それぞれのトラックは、1つまたは複数のエンハンスメントレイヤのうちのそれぞれのエンハンスメントレイヤを含む。詳細には、図3において、トラック01はベースレイヤを含み、トラック02はエンハンスメントレイヤ(図3でEL1として示す)を含む。
図3の例では、ファイルは、第1の「oinf」サンプルグループ46および第2の「oinf」サンプルグループ48を含む。ある「oinf」サンプルグループから別の「oinf」サンプルグループへのグルーピング移行点において、第1の「oinf」サンプルグループの最終サンプルと第2の「oinf」サンプルグループの最初のサンプルとの間の復号時間を有する、トラック02の中のサンプル50は、時間的にコロケートされたサンプルをトラック01の中に有さず、いかなる「oinf」サンプルグループにも属しない。
したがって、図3の例および他の例では、ファイルの中のビットストリームにおいて利用可能な動作点は、動作点参照トラック(たとえば、図3におけるトラック01)の中でシグナリングされる第1の動作点情報サンプルグループ(たとえば、図3における「oinf」サンプルグループ46)を使用して、ファイルの中に記述される。第1の動作点情報サンプルグループは、動作点参照トラックの中のサンプルの第1のセットを備える。さらに、動作点参照トラックは、動作点参照トラックの中のサンプルの第2のセットを備える第2の動作点サンプルグループを含む。この例では、サンプルの第1のセットの中で最も遅い復号時間を有するサンプル(たとえば、図3におけるサンプル52)の復号時間と、サンプルの第2のセットの中で最も早い復号時間を有するサンプル(たとえば、図3におけるサンプル54)の復号時間との間の復号時間において出現するサンプルが、動作点参照トラックの中にない。さらに、サンプルの第1のセットの中で最も遅い復号時間を有するサンプルの復号時間と、サンプルの第2のセットの中で最も早い復号時間を有するサンプルの復号時間との間の復号時間を有する1つまたは複数のサンプル(たとえば、図3におけるサンプル50)が、1つまたは複数の追加トラックのうちの特定の追加トラック(たとえば、図3におけるトラック02)の中にある。いくつかの事例では、特定の追加トラック(たとえば、図3におけるトラック02)は、フレームレートが動作点参照トラックよりも高い。
トラックヘッダの中でトラック参照が規定されるとトラック参照が変更できないので、「oinf」サンプルグループを含む指定された「oref」トラックが、「oref」トラック参照に追従することによって見つけられるという事実は、ビットストリーム全体に対して、「oinf」サンプルグループを含むことができるトラックが1つしかあり得ないという結果となる。「oinf」サンプルグループを含むことができるトラックのこの固定の設計、および「oinf」サンプルグループを含むトラックの中に存在するサンプルしか「oinf」サンプルグループが含むことができないという事実に起因して、いくらかの時間期間において「oref」トラックの中にサンプルがない場合、「oref」トラック以外のトラックの中のいくつかのサンプルは、いかなる「oinf」サンプルグループにも属しないことがある。
図4は、「oref」トラックがいくらかの時間期間にわたってサンプルを有しないときに起こる例示的な問題を示す。図4の例では、ファイルは、第1の「oinf」サンプルグループ56および第2の「oinf」サンプルグループ58を含む。図4の例に示すように、「oref」トラックにおけるサンプルがない時間期間での「oref」トラック以外のトラックの中のすべてのサンプル60は、いかなる「oinf」サンプルグループにも属さない。追加として、図4に示すように、「oref」トラックがトラックヘッダの中で「oref」トラック参照によって規定されると「oref」トラックが変更できないので、トラック02の中の「oinf」サンプルグループを有する可能性がない。
本開示は、上記の問題を解決するためのいくつかの技法を提案する。技法のうちのいくつかは独立に適用されてよく、技法のうちのいくつかは組み合わせて適用されてよい。技法は、上記で説明した問題を解決することに加えた理由のために有益であり得る。
本開示の第1の技法によれば、「oref」トラックでないトラックの中のサンプルに対して以下のことが適用され得る。
a.「oref」トラック以外のトラックの中のサンプルは、「oref」トラックの中のその時間的にコロケートされたサンプルと同じ「oinf」サンプルグループの一部である。トラックの中の特定のサンプルに対して、別のトラックの中の時間的にコロケートされたサンプルは、この特定のサンプルの復号時間と同じ復号時間を有するサンプルである。
b.「oref」トラック以外のトラックの中のサンプルspAが「oref」トラックの中の時間的にコロケートされたサンプルを有しない場合、サンプルは、spAよりも前の、「oref」トラックの中の最終サンプルの「oinf」サンプルグループの一部と見なされる。このプロセスは再帰的に適用され得る。代替または追加として、この場合、サンプルは、spAよりも後の、「oref」トラックの中の最初のサンプルの「oinf」サンプルグループの一部と見なされる。
サンプル50が「oref」トラック(すなわち、トラック01)以外のトラック(すなわち、トラック02)の中にあり、「oref」トラックの中の時間的にコロケートされたサンプルを有しないので、上の記述を適用することによって、図3のサンプル50は「oinf」サンプルグループ46の中に含められる。したがって、サンプル50は、サンプル50よりも前の最終サンプル(すなわち、サンプル52)の「oinf」サンプルグループの一部と見なされる。同様に、図4のサンプルでは、サンプル60は、「oref」トラック(すなわち、トラック01)以外のトラック(すなわち、トラック02)の中にあり、「oref」トラックの中の時間的にコロケートされたサンプルを有しない。したがって、サンプル60は、サンプル60よりも前の、「oref」トラックの最終サンプルの「oinf」サンプルグループの一部と見なされる。
したがって、第1の技法の一例では、ソースデバイス12、ファイル生成デバイス34、または別のデバイスなどのデバイスは、ファイルの中に動作点参照トラックを生成し得る。概して、トラックを生成することは、トラックのサンプルおよび/またはトラックのメタデータなどのデータを、ファイルの中に記憶することを備え得る。動作点参照トラックを生成することの一部として、デバイスは、ファイルの中のビットストリームにとって利用可能な動作点を記述する動作点情報サンプルグループを、動作点参照トラックの中でシグナリングし得る。概して、サンプルグループをシグナリングすることは、サンプルグループのサンプルを示すサンプルツーグループボックスおよびサンプルグループを記述するサンプルグループ記述エントリを、ファイルに記憶することを備え得る。さらに、デバイスは、ファイルの中に1つまたは複数の追加トラックを生成し得る。動作点情報サンプルグループは、追加トラックのいずれの中でもシグナリングされない。さらに、それぞれの追加トラックの中のそれぞれのサンプルと時間的にコロケートされているサンプルを動作点参照トラックが含むことに基づいて、それぞれの追加トラックの中のそれぞれのサンプルは、動作点情報サンプルグループの一部と見なされる。それぞれの追加トラックの中のそれぞれのサンプルと時間的にコロケートされているサンプルを動作点参照トラックが含まないことに基づいて、それぞれの追加トラックの中のそれぞれのサンプルは、それぞれの追加トラックのそれぞれのサンプルよりも前の、動作点参照トラックの中の最終サンプルの動作点情報サンプルグループの一部と見なされる。
同様に、第1の技法の一例では、宛先デバイス14、MANE、または別のデバイスなどのデバイスは、ファイルの中の動作点参照トラックを取得し得る。動作点参照トラックなどのデータを取得することは、データを読み取ること、データを構文解析すること、またはデータを入手、獲得、もしくは所有するためのいくつかのアクションを別の方法で実行することを備え得る。ファイルの中のビットストリームにとって利用可能な動作点が、動作点参照トラックの中でシグナリングされる動作点情報サンプルグループを使用してファイルの中に記述される。さらに、デバイスは、ファイルの中の1つまたは複数の追加トラックを取得し得る。動作点情報サンプルグループは、追加トラックのいずれの中でもシグナリングされない。1つまたは複数の追加トラックのうちの各それぞれの追加トラックのそれぞれのサンプルごとに、デバイスは、それぞれのサンプルを動作点情報サンプルグループの一部と見なすべきかどうかを決定し得る。それぞれの追加トラックの中のそれぞれのサンプルと時間的にコロケートされているサンプルを動作点参照トラックが含むことに基づいて、それぞれの追加トラックの中のそれぞれのサンプルは、動作点情報サンプルグループの一部と見なされる。それぞれの追加トラックの中のそれぞれのサンプルと時間的にコロケートされているサンプルを動作点参照トラックが含まないことに基づいて、それぞれの追加トラックの中のそれぞれのサンプルは、それぞれの追加トラックのそれぞれのサンプルよりも前の、動作点参照トラックの中の最終サンプルの動作点情報サンプルグループの一部と見なされる。さらに、いくつかの例では、デバイスは、ビットストリームから動作点を抽出するサブビットストリーム抽出プロセスを実行し得る。
以下のこのテキストは、第1の技法の例示的な実装形態を説明する。本開示全体にわたって、現在のL-HEVCファイルフォーマット(たとえば、14496-15に関する現在のドラフト仕様)への挿入は、<ins>...</ins>タグで囲まれ(たとえば、<ins>追加テキスト</ins>)、除去されるテキストは、<dlt>...</dlt>タグで囲まれる(たとえば、<dlt>削除テキスト</dlt>)。
9.8.1 動作点情報サンプルグループ
9.8.1.1 定義
ボックスタイプ:「oinf」。
コンテナ:「oref」タイプ参照トラックのSampleGroupDescriptionBox(「sgpd」)。
必須性:L-HEVCビットストリームの唯一無二のトラックにおいて必須である。
数量:1つまたは複数の「oinf」サンプルグループエントリ。
アプリケーションは、動作点情報サンプルグループ(「oinf」)を使用することによって、所与のサンプルにとって関連する異なる動作点およびそれらの構造について通知される。各動作点は、出力レイヤセット、最大T-ID値、ならびにプロファイル、レベル、およびティアのシグナリングに関係する。これらのすべての情報は、「oinf」サンプルグループによって取り込まれる。これらの情報とは別に、このサンプルグループは、レイヤ、L-HEVCビットストリームの中でコーディングされるスケーラビリティのタイプ、および所与のスケーラビリティタイプに対して任意の特定のレイヤに関する次元識別子の間の、依存情報も提供する。
L-HEVCビットストリームのすべてのトラックに対して、「oinf」サンプルグループを搬送するこのセットのうち、ただ1つのトラックがなければならない。L-HEVCビットストリームのすべてのトラックは、「oinf」サンプルグループを搬送するトラックへのタイプ「oref」のトラック参照を有しなければならない。
いくつかのVPSがL-HEVCビットストリームの中に存在するとき、いくつかの動作点情報サンプルグループを宣言することが必要とされ得る。単一のVPSしか存在しないもっと一般のケースの場合、ISO/IEC14496-12において定義されるデフォルトのサンプルグループメカニズムを使用し、動作点情報サンプルグループを各トラックフラグメントの中で宣言するのではなくトラックサンプルテーブルの中に含めることが推奨される。
<ins>トラックの中の特定のサンプルに対して、別のトラックの中の時間的にコロケートされたサンプルは、この特定のサンプルの復号時間と同じ復号時間を有するサンプルである。
「oref」トラック以外のトラックに対して、以下のことが適用される。
- 「oref」トラック以外のトラックの中のサンプルは、「oref」トラックの中のその時間的にコロケートされたサンプルと同じ「oinf」サンプルグループの一部である。
- 「oref」トラック以外のトラックの中のサンプルspAが「oref」トラックの中の時間的にコロケートされたサンプルを有しない場合、サンプルは、spAよりも前の、「oref」トラックの中の最終サンプルの「oinf」サンプルグループの一部と見なされる。このプロセスは再帰的に適用され得る。</ins>
本開示の第2の技法によれば、「oref」トラック参照を使用して「oinf」サンプルグループを含むトラックを決定する代わりに、「oinf」サンプルグループを含むトラックがレイヤ情報(「linf」)サンプルグループの中で示される。このことにより、「oinf」サンプルグループが異なる時間期間にわたって異なるトラックの中に存在することが可能になり得る。
たとえば、図4を参照すると、トラック01用およびトラック02用のサンプルグループ記述ボックスは各々、トラック01およびトラック02に関連する「oinf」サンプルグループを含むトラックのそれぞれのトラック識別子を指定する、それぞれの「oinf」トラック識別子要素を含むそれぞれの「linf」サンプルグループ記述エントリを含み得る。さらに、図4において、トラック02用の「linf」サンプルグループ記述エントリの中の「oinf」トラック識別子要素は、トラック02が「oinf」サンプルグループを含むことを示し得る。したがって、トラック02の「oinf」サンプルグループはサンプル56を含み得る。しかしながら、第1のトラックの中の各サンプルが第2のトラックの中のそれぞれのサンプルと位置合わせされており、「oinf」サンプルグループが第2のトラックに対して規定される場合、「oinf」サンプルグループが第1のトラックの中で直接規定されるよりも、第1のトラックが第2のトラックの「oinf」サンプルグループを指すほうが、より効率的であり得る。
したがって、第2の技法の一例では、ソースデバイス12または別のデバイスなどのデバイスは、ファイルの中に第1のトラックを生成し得る。この例では、第1のトラックは、レイヤ情報サンプルグループに対するサンプルグループ記述エントリを含む。追加として、この例では、デバイスは、ファイルの中に第2のトラックを生成する。第2のトラックは、ファイルの中のビットストリームにとって利用可能な動作点を列挙する、動作点情報サンプルグループに対するサンプルグループ記述エントリを含む。この例では、デバイスは、動作点情報サンプルグループに対するサンプルグループ記述エントリを含むものとして第2のトラックを識別するために、第1のトラックの中で示されるデータを使用し得る。
第2の技法の別の例では、宛先デバイス14または別のデバイスなどのデバイスは、ファイルの中の第1のトラックを取得する。第1のトラックは、レイヤ情報サンプルグループに対するサンプルグループ記述エントリを含む。追加として、デバイスは、ファイルの中の第2のトラックを取得する。この例では、第2のトラックは、ファイルの中のビットストリームにとって利用可能な動作点を列挙する、動作点情報サンプルグループに対するサンプルグループ記述エントリを含む。さらに、この例では、デバイスは、動作点情報サンプルグループに対するサンプルグループ記述エントリを含むものとして第2のトラックを識別するために、第1のトラックの中で示されるデータを使用し得る。
第3の技法では、「oinf」サンプルグループおよび「linf」サンプルグループは、同じ「oinf」サンプルグループに属するサンプルが同じ「linf」サンプルグループにも属するように、時間的に位置合わせされる。たとえば、上記で説明した第2の技法に基づくと、「linf」サンプルグループlAに属するトラックtAの中のサンプルsA、および「linf」サンプルグループlBに属するトラックtBの中のサンプルsBごとに、sAおよびsBが時間的にコロケートされており、トラックtAの中にあり同様に「linf」サンプルグループlAに属するサンプルsCがトラックtBの中にあるサンプルsDと時間的にコロケートされている場合に、サンプルsDが「linf」サンプルグループlBに属さなければならないことは、ファイルフォーマットへの要件または制約であり得る。その上、「oref」サンプルグループoAに属するトラックtAの中のサンプルsA、および「oref」サンプルグループoBに属するトラックtBの中のサンプルsBごとに、sAおよびsBが時間的にコロケートされており、トラックtAの中にあり同様に「oref」サンプルグループoAに属するサンプルsCがトラックtBの中にあるサンプルsDと時間的にコロケートされている場合に、サンプルsDが「oref」サンプルグループoBに属さなければならないことは、ファイルフォーマットへの要件または制約であり得る。
したがって、第3の技法の一例では、ソースデバイス12または別のデバイスなどのデバイスは、ファイルの中に第1のトラックを生成し得る。この例では、第1のトラックは、レイヤ情報サンプルグループに対するサンプルグループ記述エントリを含む。追加として、この例では、デバイスは、ファイルの中に第2のトラックを生成する。この例では、第2のトラックは、ファイルの中のビットストリームにとって利用可能な動作点を列挙する、動作点情報サンプルグループに対するサンプルグループ記述エントリを含む。この例では、レイヤ情報サンプルグループおよび動作点情報サンプルグループは、動作点情報サンプルグループに属するサンプルが同じレイヤ情報サンプルグループにも属するように、時間的に位置合わせされる。
同様に、第3の技法の一例では、宛先デバイス14または別のデバイスなどのデバイスは、ファイルの中の第1のトラックを取得し得る。この例では、第1のトラックは、レイヤ情報サンプルグループに対するサンプルグループ記述エントリを含む。追加として、この例では、デバイスは、ファイルの中の第2のトラックを取得する。この例では、第2のトラックは、ファイルの中のビットストリームにとって利用可能な動作点を列挙する、動作点情報サンプルグループに対するサンプルグループ記述エントリを含む。この例では、レイヤ情報サンプルグループおよび動作点情報サンプルグループは、動作点情報サンプルグループに属するサンプルが同じレイヤ情報サンプルグループにも属するように、時間的に位置合わせされる。
以下のテキストは、上記で説明した第2および第3の技法のための実装形態について、14496-15に関する現在のドラフト仕様への変更を示す。
9.8.1 動作点情報サンプルグループ
9.8.1.1 定義
ボックスタイプ:「oinf」。
コンテナ:「oref」タイプ参照トラックのSampleGroupDescriptionBox(「sgpd」)。
必須性:L-HEVCビットストリームの唯一無二のトラックにおいて必須である。
数量:1つまたは複数の「oinf」サンプルグループエントリ。
アプリケーションは、動作点情報サンプルグループ(「oinf」)を使用することによって、所与のサンプルにとって関連する異なる動作点およびそれらの構造について通知される。各動作点は、出力レイヤセット、最大T-ID値、ならびにプロファイル、レベル、およびティアのシグナリングに関係する。これらのすべての情報は、「oinf」サンプルグループによって取り込まれる。これらの情報とは別に、このサンプルグループは、レイヤ、L-HEVCビットストリームの中でコーディングされるスケーラビリティのタイプ、および所与のスケーラビリティタイプに対して任意の特定のレイヤに関する次元識別子の間の、依存情報も提供する。
<dlt>L-HEVCビットストリームのすべてのトラックに対して、「oinf」サンプルグループを搬送するこのセットのうち、ただ1つのトラックがなければならない。L-HEVCビットストリームのすべてのトラックは、「oinf」サンプルグループを搬送するトラックへのタイプ「oref」のトラック参照を有しなければならない。</dlt>
<ins>「oinf」サンプルグループを搬送するトラックは、レイヤ情報(「linf」)サンプルグループの中でシグナリングされるoinf_track_idフィールドによって識別される。「linf」サンプルグループおよび「oinf」サンプルグループは、同じ「oinf」サンプルグループに属するサンプルが同じ「linf」サンプルグループにも属するように、時間的に位置合わせされる。</ins>
いくつかのVPSがL-HEVCビットストリームの中に存在するとき、いくつかの動作点情報サンプルグループを宣言することが必要とされ得る。単一のVPSしか存在しないもっと一般のケースの場合、ISO/IEC14496-12において定義されるデフォルトのサンプルグループメカニズムを使用し、動作点情報サンプルグループを各トラックフラグメントの中で宣言するのではなくトラックサンプルテーブルの中に含めることが推奨される。
9.8.2 レイヤ情報サンプルグループ
9.8.2.1 定義
ボックスタイプ:「linf」。
コンテナ:SampleGroupDescriptionBox(「sgpd」)。
必須性:すべてのL-HEVCトラックにおいて必須である。
数量:1つまたは複数の「linf」サンプルグループエントリ。
トラックが搬送するレイヤおよびサブレイヤのリストは、レイヤ情報サンプルグループの中でシグナリングされる。すべてのL-HEVCトラックは、「linf」サンプルグループを搬送しなければならない。
9.8.2.2 シンタックス
class LayerInfoGroupEntry extends VisualSampleGroupEntry ('linf')) {
unsigned int (2) reserved;
unsigned int (6) num_layers_in_track;
for (i=0; i<num_layers_in_track; i++) {
unsigned int (4) reserved;
unsigned int (6) layer_id;
unsigned int (3) min_sub_layer_id;
unsigned int (3) max_sub_layer_id;
}
<ins>unsigned int (32) oinf_track_id;</ins>
}
9.8.2.3 セマンティクス
num_layers_in_track:このサンプルグループに関連するこのトラックの任意のサンプルにおいて搬送されるレイヤの数。
layer_id:関連するサンプルにおいて搬送されるレイヤに対するレイヤID。このフィールドのインスタンスは、ループの中で昇順でなければならない。
min_sub_layer_id:トラック内のレイヤの中のサブレイヤに対する最小TemporalId値。
max_sub_layer_id:トラック内のレイヤの中のサブレイヤに対する最大TemporalId値。
<ins>oinf_track_id:関連する「oinf」サンプルグループを含むトラックのトラックID。</ins>
第4の技法では、トラックに対して「ダミー」サンプルエントリが生成され得る。「ダミー」サンプルエントリは、トラックの中のいかなるサンプルにも適用可能でなく、このトラックの中のレイヤに依存するレイヤを含むいくつかの他のトラックのみによって使用され得るパラメータセットを含み得る。いくつかの例では、「ダミー」サンプルエントリは、「oinf」ボックスの中でシグナリングされる動作点または動作点を指すインデックス値を記述する情報を含む。したがって、図4の例では、トラック01用のサンプルテーブルボックスは、「ダミー」サンプルエントリを含み得、ファイルを解釈するデバイスは、トラック02を解釈するときにトラック01の「ダミー」サンプルエントリを参照し得る。
第4の技法の一例では、ソースデバイス12または別のデバイスなどのデバイスは、ファイルの中に1つまたは複数のトラックを生成する。追加として、この例では、デバイスは、ファイルの中に追加トラックを生成する。この例では、追加トラックは、追加トラックの中のいかなるサンプルにも適用可能でない特定のサンプルエントリを含む。この例では、特定のサンプルエントリは、追加トラックの中のレイヤに依存するレイヤを含む1つまたは複数のトラックのみによって使用され得るパラメータセットを含む。
同様に、第4の技法の一例では、宛先デバイス14または別のデバイスなどのデバイスは、ファイルの中の1つまたは複数のトラックを取得する。追加として、この例では、デバイスは、ファイルの中の追加トラックを取得する。この例では、追加トラックは、追加トラックの中のいかなるサンプルにも適用可能でない特定のサンプルエントリを含む。さらに、この例では、特定のサンプルエントリは、追加トラックの中のレイヤに依存するレイヤを含む1つまたは複数のトラックのみによって使用され得るパラメータセットを含む。
第5の技法では、動作点のリストは、サンプルグループを通じてシグナリングされない。代わりに、動作点のリストは、「oref」トラック内のそれ自体のボックス(たとえば、「oinf」ボックス)の中でシグナリングされる。たとえば、上述のように、トラックのサンプルテーブルボックスは、トラックのそれぞれのサンプルに関する情報を含むサンプルエントリを含み得る。L-HEVC用のISOベースメディアファイルフォーマットの拡張のドラフトでは、サンプルエントリは、LHEVCDecoderConfigurationRecordクラスのインスタンスを含み得る。第5の技法の一例によれば、各トラックのサンプルエントリは、「oinf」ボックスの中でシグナリングされる動作点のリストへのインデックスのリストを含み得る。サンプルエントリにおける動作点のリストは、サンプルエントリが適用されるサンプルに適用される動作点のリストである。
したがって、第5の技法の一例では、ファイルを生成することの一部として、デバイス(たとえば、ソースデバイス12または別のデバイス)は、ファイルの中のビットストリームにとって利用可能な動作点を列挙する動作点情報サンプルグループを指定するサンプルグループ記述エントリを含む、トラック内のボックスの中の動作点のリストをシグナリングし得る。この例では、ボックスが属するタイプのボックスは、動作点情報サンプルグループを規定するサンプルグループ記述エントリを含むためだけに指定される。同様に、第5の技法の別の例では、ファイルを生成することの一部として、デバイス(たとえば、宛先デバイス14または別のデバイス)は、ファイルの中のビットストリームにとって利用可能な動作点を列挙する動作点情報サンプルグループを指定するサンプルグループ記述エントリを含む、トラック内のボックスの中の動作点のリストを取得し得る。この例では、ボックスが属するタイプのボックスは、動作点サンプルグループを規定するサンプルグループ記述エントリを含めるためだけに指定される。
以下のテキストは、第5の技法を実施するための、14496-15に関する現在のドラフト仕様への例示的な変更を示す。
9.6.3 デコーダ構成レコード
第8.3.3.1節において定義されるデコーダ構成レコードが、L-HEVCストリームまたはHEVCストリームのいずれかとして解釈され得るストリームに対して使用されるとき、HEVCデコーダ構成レコードは、HEVC互換のベースレイヤに適用されなければならず、HEVCベースレイヤを復号するために必要とされるパラメータセットのみを含むべきである。
LHEVCDecoderConfigurationRecordのシンタックスは以下の通りである。
aligned(8) class LHEVCDecoderConfigurationRecord {
unsigned int(8) configurationVersion = 1; bit(4) reserved ='1111'b;
unsigned int(12) min_spatial_segmentation_idc;
bit(6) reserved ='111111'b;
unsigned int(2) parallelismType;
bit(2) reserved ='11'b;
bit(3) numTemporalLayers;
bit(1) temporalIdNested;
unsigned int(2) lengthSizeMinusOne;
unsigned int(8) numOfArrays;
for (j=0; j < numOfArrays; j++) {
bit(1) array_completeness;
unsigned int(1) reserved = 0;
unsigned int(6) NAL_unit_type;
unsigned int(16) numNalus;
for (i=0; i< numNalus; i++) {
unsigned int(16) nalUnitLength;
bit(8*nalUnitLength) nalUnit;
}
}
<ins>unsigned int(16) numOfAvailableOPs;
for (j=0; j < numOfAvailableOPs; j++) {
unsigned int(16) op_idx;</ins>
}
}
LHEVCDecoderConfigurationRecordおよびHEVCDecoderConfigurationRecordと共通のフィールドのセマンティクスは、変更されないままである。
注釈 トラックは2つ以上の出力レイヤセットを表してよい。
注釈 トラックの中に含まれる補助ピクチャレイヤごとに、補助ピクチャレイヤの特性を規定する、深度補助ピクチャレイヤのための深度表現情報SEIメッセージなどの宣言型SEIメッセージを含むSEI NALユニットをnalUnit内に含めることを推奨する。
<ins>num_operating_points:このサンプルエントリが適用されるサンプルに適用される動作点の数を与える。
op_idx:「oinf」ボックスの中でシグナリングされる動作点のリストへのインデックスを与える。</ins>
本開示はいくつかの技法を提案する。これらの技法のうちのいくつかは独立に適用されてよく、技法のうちのいくつかは組み合わせて適用されてよい。
ファイルを生成または処理するための本開示の技法は、ソースデバイス12、宛先デバイス14、または別のデバイスによって実行され得る。たとえば、デバイスは、ソースデバイス12から符号化ビデオデータを受信し得、符号化ビデオデータに基づいてファイルを生成し得る。同様に、デバイスは、ファイルを受信および処理し得る。このデバイスが、ファイルからの符号化ビデオデータを宛先デバイス14に提供してもよい。
図5は、例示的なビデオエンコーダ20を示すブロック図である。図5は、説明のために提供され、本開示において広く例示および説明するような技法の限定と見なされるべきでない。説明のために、本開示は、HEVCコーディングのコンテキストにおいてビデオエンコーダ20を説明する。ただし、本開示の技法は、他のコーディング規格または方法に適用可能であり得る。
図5の例では、ビデオエンコーダ20は、予測処理ユニット100、ビデオデータメモリ101、残差生成ユニット102、変換処理ユニット104、量子化ユニット106、逆量子化ユニット108、逆変換処理ユニット110、再構成ユニット112、フィルタユニット114、復号ピクチャバッファ116、およびエントロピー符号化ユニット118を含む。予測処理ユニット100は、インター予測処理ユニット120およびイントラ予測処理ユニット126を含む。インター予測処理ユニット120は、動き推定ユニットおよび動き補償ユニット(図示せず)を含む。他の例では、ビデオエンコーダ20は、より多数の、より少数の、または異なる機能構成要素を含んでよい。
ビデオデータメモリ101は、ビデオエンコーダ20の構成要素によって符号化されるべきビデオデータを記憶し得る。ビデオデータメモリ101に記憶されるビデオデータは、たとえば、ビデオソース18から取得され得る。復号ピクチャバッファ116は、たとえば、イントラコーディングモードまたはインターコーディングモードにおいて、ビデオエンコーダ20によってビデオデータを符号化する際に使用するための参照ビデオデータを記憶する参照ピクチャメモリであり得る。ビデオデータメモリ101および復号ピクチャバッファ116は、シンクロナスDRAM(SDRAM)を含むダイナミックランダムアクセスメモリ(DRAM)、磁気抵抗RAM(MRAM)、抵抗型RAM(RRAM(登録商標))、または他のタイプのメモリデバイスなどの、様々なメモリデバイスのいずれかによって形成され得る。ビデオデータメモリ101および復号ピクチャバッファ116は、同じメモリデバイスまたは別個のメモリデバイスによって設けられてよい。様々な例では、ビデオデータメモリ101は、ビデオエンコーダ20の他の構成要素とともにオンチップであってよく、またはそれらの構成要素に対してオフチップであってもよい。
ビデオエンコーダ20は、ビデオデータを受け取る。ビデオエンコーダ20は、ビデオデータのピクチャのスライスの中の各CTUを符号化し得る。CTUの各々は、ピクチャの等しいサイズのルーマコーディングツリーブロック(CTB:coding tree block)および対応するCTBに関連し得る。CTUを符号化することの一部として、予測処理ユニット100は、4分木区分を実行して、CTUのCTBを次第に小さくなるブロックに分割し得る。より小さいブロックは、CUのコーディングブロックであり得る。たとえば、予測処理ユニット100は、CTUに関連するCTBを4つの等しいサイズのサブブロックに区分し得、サブブロックのうちの1つまたは複数を4つの等しいサイズのサブサブブロックに区分し得、以下同様である。
ビデオエンコーダ20は、CTUのCUを符号化して、CUの符号化表現(すなわち、コード化CU)を生成し得る。CUを符号化することの一部として、予測処理ユニット100は、CUに関連するコーディングブロックを、CUの1つまたは複数のPUの間で区分し得る。したがって、各PUは、ルーマ予測ブロックおよび対応するクロマ予測ブロックに関連し得る。インター予測処理ユニット120は、CUの各PUに対してインター予測を実行することによって、PUに対する予測データを生成し得る。PUに対する予測データは、PUの予測ブロックおよびPUに対する動き情報を含み得る。イントラ予測処理ユニット126は、PUに対してイントラ予測を実行することによって、PUに対する予測データを生成し得る。PUに対する予測データは、PUの予測ブロックおよび様々なシンタックス要素を含み得る。イントラ予測処理ユニット126は、Iスライス、Pスライス、およびBスライスの中のPUに対して、イントラ予測を実行し得る。
予測処理ユニット100は、PUに対してインター予測処理ユニット120によって生成された予測データ、またはPUに対してイントラ予測処理ユニット126によって生成された予測データの中から、CUのPUに対する予測データを選択し得る。いくつかの例では、予測処理ユニット100は、予測データのセットのレート/ひずみメトリックに基づいて、CUのPUに対する予測データを選択する。選択された予測データの予測ブロックは、本明細書で選択予測ブロック(selected predictive block)と呼ばれることがある。残差生成ユニット102は、CUに対するコーディングブロックおよびCUのPUに対する選択予測ブロックに基づいて、CUに対する残差ブロックを生成し得る。
変換処理ユニット104は、4分木区分を実行して、CUに関連する残差ブロックをCUのTUに関連する変換ブロックに区分し得る。TUは、ルーマ変換ブロックおよび2つのクロマ変換ブロックに関連し得る。CUのTUのルーマ変換ブロックおよびクロマ変換ブロックのサイズおよび位置は、CUのPUの予測ブロックのサイズおよび位置に基づいても基づかなくてもよい。
変換処理ユニット104は、TUの変換ブロックに1つまたは複数の変換を適用することによって、CUのTUごとに変換係数ブロックを生成し得る。変換処理ユニット104は、TUに関連する変換ブロックに様々な変換を適用し得る。たとえば、変換処理ユニット104は、離散コサイン変換(DCT)、方向変換、または概念的に類似の変換を、変換ブロックに適用し得る。いくつかの例では、変換処理ユニット104は、変換ブロックに変換を適用しない。そのような例では、変換ブロックは、変換係数ブロックとして扱われてよい。
量子化ユニット106は、係数ブロックの中の変換係数を量子化し得る。量子化プロセスは、変換係数の一部または全部に関連するビット深度を低減し得る。
逆量子化ユニット108および逆変換処理ユニット110は、それぞれ、逆量子化および逆変換を係数ブロックに適用して、係数ブロックから残差ブロックを再構成し得る。再構成ユニット112は、予測処理ユニット100によって生成された1つまたは複数の予測ブロックからの対応するサンプルに、再構成された残差ブロックを加算して、TUに関連する再構成された変換ブロックを生成し得る。このようにしてCUのTUごとに変換ブロックを再構成することによって、ビデオエンコーダ20は、CUのコーディングブロックを再構成し得る。
フィルタユニット114は、1つまたは複数のデブロッキング動作を実行して、CUに関連するコーディングブロックにおけるブロッキングアーティファクトを低減し得る。フィルタユニット114が、再構成されたコーディングブロックに対して1つまたは複数のデブロッキング動作を実行した後、復号ピクチャバッファ116は、再構成されたコーディングブロックを記憶し得る。インター予測処理ユニット120は、他のピクチャのPUに対してインター予測を実行するために、再構成されたコーディングブロックを含む参照ピクチャを使用し得る。加えて、イントラ予測処理ユニット126は、CUと同じピクチャの中の他のPUに対してイントラ予測を実行するために、復号ピクチャバッファ116の中の再構成されたコーディングブロックを使用し得る。
エントロピー符号化ユニット118は、ビデオエンコーダ20の他の機能構成要素からデータを受け取り得る。たとえば、エントロピー符号化ユニット118は、量子化ユニット106から係数ブロックを受け取ってよく、予測処理ユニット100からシンタックス要素を受け取ってよい。エントロピー符号化ユニット118は、データに対して1つまたは複数のエントロピー符号化動作を実行して、エントロピー符号化データを生成し得る。たとえば、エントロピー符号化ユニット118は、CABAC動作、コンテキスト適応型可変長コーディング(CAVLC)動作、可変長対可変長(V2V)コーディング動作、シンタックスベースコンテキスト適応型バイナリ算術コーディング(SBAC)動作、確率区間区分エントロピー(PIPE)コーディング動作、指数ゴロム符号化動作、または別のタイプのエントロピー符号化動作を、データに対して実行し得る。ビデオエンコーダ20は、エントロピー符号化ユニット118によって生成されたエントロピー符号化データを含むビットストリームを出力し得る。たとえば、ビットストリームは、CUに対するRQTを表すデータを含み得る。
さらに、図5の例では、ファイル処理ユニット128が、ビデオエンコーダ20によって生成されたビットストリームを取得し得る。ファイル処理ユニット128は、ソースデバイス12、ファイル生成デバイス34、コンテンツ配信ネットワークデバイス、または別のタイプのデバイスなどの、デバイスの1つまたは複数のプロセッサによって実装され得る。ファイル処理ユニット128は、ビデオエンコーダ20によって生成されたビットストリームを記憶するファイルを生成し得る。コンピュータ可読媒体130は、ファイル処理ユニット128によって生成されたファイルを受け取り得る。いくつかの例では、コンピュータ可読媒体130は、メモリ、光ディスク、磁気ディスク、またはコンピューティングデバイスがそこからデータを読み取ることができる他のタイプの非一時的記憶媒体などの、コンピュータ可読記憶媒体を備える。コンピュータ可読媒体130がコンピュータ可読記憶媒体を備えるいくつかの例では、コンピュータ可読記憶媒体は、ソースデバイス12、ファイル生成デバイス34、コンテンツ配信ネットワークデバイス、または別のタイプのデバイスなどの、デバイスの一部を形成し得る。いくつかの例では、コンピュータ可読媒体130は、光ファイバー、通信ケーブル、電磁波、またはコンピューティングデバイスがそこからデータを読み取ることができる他のタイプの媒体などの、コンピュータ可読通信媒体を備える。
本開示の技法によれば、ファイル処理ユニット128は、ファイルの中に動作点参照トラックを生成し得る。動作点参照トラックを生成することの一部として、ファイル処理ユニット128は、ファイルの中のビットストリームにとって利用可能な動作点を記述する動作点情報サンプルグループを、動作点参照トラックの中でシグナリングし得る。追加として、ファイルを生成することの一部として、ファイル処理ユニット128は、ファイルの中に1つまたは複数の追加トラックを生成し得る。この例では、動作点情報サンプルグループは、追加トラックのいずれの中でもシグナリングされない。さらに、それぞれの追加トラックの中のそれぞれのサンプルと時間的にコロケートされているサンプルを動作点参照トラックが含むことに基づいて、ファイル処理ユニット128は、それぞれの追加トラックの中のそれぞれのサンプルを、動作点情報サンプルグループの一部と見なし得る。その上、それぞれの追加トラックの中のそれぞれのサンプルと時間的にコロケートされているサンプルを動作点参照トラックが含まないことに基づいて、ファイル処理ユニット128は、それぞれの追加トラックの中のそれぞれのサンプルを、それぞれの追加トラックのそれぞれのサンプルよりも前の、動作点参照トラックの中の最終サンプルの動作点情報サンプルグループの一部と見なし得る。
図6は、例示的なビデオデコーダ30を示すブロック図である。図6は、説明のために提供され、本開示において広く例示および説明するような技法の限定ではない。説明のために、本開示は、HEVCコーディングのコンテキストにおいてビデオデコーダ30を説明する。ただし、本開示の技法は、他のコーディング規格または方法に適用可能であり得る。
図6の例では、ビデオデコーダ30は、エントロピー復号ユニット150、ビデオデータメモリ151、予測処理ユニット152、逆量子化ユニット154、逆変換処理ユニット156、再構成ユニット158、フィルタユニット160、および復号ピクチャバッファ162を含む。予測処理ユニット152は、動き補償ユニット164およびイントラ予測処理ユニット166を含む。他の例では、ビデオデコーダ30は、より多数の、より少数の、または異なる機能構成要素を含んでよい。
ビデオデータメモリ151は、ビデオデコーダ30の構成要素によって復号されるべき符号化ビデオビットストリームなどのビデオデータを記憶し得る。ビデオデータメモリ151に記憶されるビデオデータは、たとえば、チャネル16から、たとえば、カメラなどのローカルビデオソースから、ビデオデータの有線ネットワーク通信もしくはワイヤレスネットワーク通信を介して、または物理データ記憶媒体にアクセスすることによって、取得され得る。ビデオデータメモリ151は、符号化ビデオビットストリームからの符号化ビデオデータを記憶するコード化ピクチャバッファ(CPB)を形成し得る。復号ピクチャバッファ162は、たとえば、イントラコーディングモードまたはインターコーディングモードにおいて、ビデオデコーダ30によってビデオデータを復号する際に使用するための参照ビデオデータを記憶する参照ピクチャメモリであり得る。ビデオデータメモリ151および復号ピクチャバッファ162は、シンクロナスDRAM(SDRAM)を含むダイナミックランダムアクセスメモリ(DRAM)、磁気抵抗RAM(MRAM)、抵抗型RAM(RRAM(登録商標))、または他のタイプのメモリデバイスなどの、様々なメモリデバイスのいずれかによって形成され得る。ビデオデータメモリ151および復号ピクチャバッファ162は、同じメモリデバイスまたは別個のメモリデバイスによって設けられてよい。様々な例では、ビデオデータメモリ151は、ビデオデコーダ30の他の構成要素とともにオンチップであってよく、またはそれらの構成要素に対してオフチップであってもよい。
ビデオデータメモリ151は、ビットストリームの符号化ビデオデータ(たとえば、NALユニット)を受け取り記憶する。エントロピー復号ユニット150は、CPBから符号化ビデオデータ(たとえば、NALユニット)を受け取るとともにNALユニットを構文解析して、シンタックス要素を取得し得る。エントロピー復号ユニット150は、NALユニットの中のエントロピー符号化シンタックス要素をエントロピー復号し得る。予測処理ユニット152、逆量子化ユニット154、逆変換処理ユニット156、再構成ユニット158、およびフィルタユニット160は、ビットストリームから抽出されたシンタックス要素に基づいて、復号ビデオデータを生成し得る。エントロピー復号ユニット150は、エントロピー符号化ユニット118のプロセスとは概して逆のプロセスを実行し得る。
ビットストリームからシンタックス要素を取得することに加えて、ビデオデコーダ30は、区分されていないCUに対して再構成動作を実行し得る。CUに対して再構成動作を実行するために、ビデオデコーダ30は、CUの各TUに対して再構成動作を実行し得る。CUのTUごとに再構成動作を実行することによって、ビデオデコーダ30は、CUの残差ブロックを再構成し得る。
CUのTUに対して再構成動作を実行することの一部として、逆量子化ユニット154は、TUに関連する係数ブロックを逆量子化(inverse quantize)、すなわち逆量子化(de-quantize)し得る。逆量子化ユニット154が係数ブロックを逆量子化した後、逆変換処理ユニット156は、係数ブロックに1つまたは複数の逆変換を適用して、TUに関連する残差ブロックを生成し得る。たとえば、逆変換処理ユニット156は、逆DCT、逆整数変換、逆カルーネンレーベ変換(KLT:Karhunen-Loeve transform)、逆回転変換、逆方向変換、または別の逆変換を係数ブロックに適用し得る。
PUがイントラ予測を使用して符号化されている場合、イントラ予測処理ユニット166は、イントラ予測を実行してPUの予測ブロックを生成し得る。イントラ予測処理ユニット166は、イントラ予測モードを使用して、空間的に隣接するブロックのサンプルに基づいてPUの予測ブロックを生成し得る。イントラ予測処理ユニット166は、ビットストリームから取得された1つまたは複数のシンタックス要素に基づいて、PU用のイントラ予測モードを決定し得る。
PUがインター予測を使用して符号化されている場合、エントロピー復号ユニット150は、PUに対する動き情報を決定し得る。動き補償ユニット164は、PUの動き情報に基づいて、1つまたは複数の参照ブロックを決定し得る。動き補償ユニット164は、1つまたは複数の参照ブロックに基づいて、PUに対する予測ブロック(たとえば、予測ルーマブロック、予測Cbブロック、および予測Crブロック)を生成し得る。
再構成ユニット158は、CUのTUに対する変換ブロック(たとえば、ルーマ変換ブロック、Cb変換ブロック、およびCr変換ブロック)、およびCUのPUの予測ブロック(たとえば、ルーマブロック、Cbブロック、およびCrブロック)、すなわちイントラ予測データまたはインター予測データのいずれかを適宜使用して、CUに対するコーディングブロック(たとえば、ルーマコーディングブロック、Cbコーディングブロック、およびCrコーディングブロック)を再構成し得る。たとえば、再構成ユニット158は、予測ブロック(たとえば、ルーマ予測ブロック、Cb予測ブロック、およびCr予測ブロック)の対応するサンプルに、変換ブロック(たとえば、ルーマ変換ブロック、Cb変換ブロック、およびCr変換ブロック)のサンプルを加算して、CUのコーディングブロック(たとえば、ルーマコーディングブロック、Cbコーディングブロック、およびCrコーディングブロック)を再構成し得る。
フィルタユニット160は、デブロッキング動作を実行して、CUのコーディングブロックに関連するブロッキングアーティファクトを低減し得る。ビデオデコーダ30は、CUのコーディングブロックを復号ピクチャバッファ162に記憶し得る。復号ピクチャバッファ162は、後続の動き補償、イントラ予測、および図1のディスプレイデバイス32などのディスプレイデバイス上での提示のために、参照ピクチャを提供し得る。たとえば、ビデオデコーダ30は、復号ピクチャバッファ162の中のブロックに基づいて、他のCUのPUに対してイントラ予測動作またはインター予測動作を実行し得る。
図6の例では、コンピュータ可読媒体148は、メモリ、光ディスク、磁気ディスク、またはコンピューティングデバイスがそこからデータを読み取ることができる他のタイプの非一時的記憶媒体などの、コンピュータ可読記憶媒体を備える。コンピュータ可読媒体148がコンピュータ可読記憶媒体を備えるいくつかの例では、コンピュータ可読記憶媒体は、ソースデバイス12、ファイル生成デバイス34、コンテンツ配信ネットワークデバイス、または別のタイプのデバイスなどの、デバイスの一部を形成し得る。いくつかの例では、コンピュータ可読媒体148は、光ファイバー、通信ケーブル、電磁波、またはコンピューティングデバイスがそこからデータを読み取ることができる他のタイプの媒体などの、コンピュータ可読通信媒体を備える。
さらに、図6の例では、ファイル処理ユニット149が、コンピュータ可読媒体148からファイルまたはファイルの部分を受け取る。ファイル処理ユニット149は、宛先デバイス14、MANE、コンテンツ配信ネットワークデバイス、または別のタイプのデバイスなどの、デバイスの1つまたは複数のプロセッサによって実装され得る。
ファイル処理ユニット149は、ファイルを処理し得る。たとえば、ファイル処理ユニット149は、ファイルからNALユニットを取得し得る。図6の例では、ビデオデコーダ30によって受け取られる符号化ビデオビットストリームは、ファイルから取得されたNALユニットを備え得る。
本開示の技法によれば、ファイル処理ユニット149は、ファイルの中の動作点参照トラックを取得し得る。ファイルの中のビットストリームにとって利用可能な動作点が、動作点参照トラックの中でシグナリングされる動作点情報サンプルグループを使用してファイルの中に記述される。さらに、ファイル処理ユニット149は、ファイルの中の1つまたは複数の追加トラックを取得し得る。動作点情報サンプルグループは、追加トラックのいずれの中でもシグナリングされない。さらに、1つまたは複数の追加トラックのうちの各それぞれの追加トラックのそれぞれのサンプルごとに、ファイル処理ユニット149は、それぞれのサンプルを動作点情報サンプルグループの一部と見なすべきかどうかを決定し得る。それぞれの追加トラックの中のそれぞれのサンプルと時間的にコロケートされているサンプルを動作点参照トラックが含むことに基づいて、ファイル処理ユニット149は、それぞれの追加トラックの中のそれぞれのサンプルを、動作点情報サンプルグループの一部と見なし得る。それぞれの追加トラックの中のそれぞれのサンプルと時間的にコロケートされているサンプルを動作点参照トラックが含まないことに基づいて、ファイル処理ユニット149は、それぞれの追加トラックの中のそれぞれのサンプルを、それぞれの追加トラックのそれぞれのサンプルよりも前の、動作点参照トラックの中の最終サンプルの動作点情報サンプルグループの一部と見なし得る。さらに、ファイル処理ユニット149は、ビットストリームから動作点を抽出するサブビットストリーム抽出プロセスを実行し得る。
図7は、本開示の1つまたは複数の技法による、ファイル300の例示的な構造を示すブロック図である。ファイル300は、ソースデバイス12(図1)、ファイル生成デバイス34(図1)、宛先デバイス14(図1)、ファイル処理ユニット128(図5)、MANE、コンテンツ配信ネットワークデバイス、または他のタイプのデバイスもしくはユニットなどの、様々なデバイスによって生成および処理され得る。図7の例では、ファイル300は、ムービーボックス302および複数のメディアデータボックス304を含む。同じファイルの中にあるものとして図7の例で示されるが、他の例では、ムービーボックス302およびメディアデータボックス304が別個のファイルの中にあってよい。先に指摘したように、ボックスは、固有タイプ識別子および長さによって規定されるオブジェクト指向ビルディングブロックであり得る。たとえば、ボックスは、4文字コード化ボックスタイプ、ボックスのバイトカウント、およびペイロードを含む、ISOBMFFにおける基本シンタックス構造であり得る。
ムービーボックス302は、ファイル300のトラック用のメタデータを含み得る。ファイル300の各トラックは、メディアデータの連続ストリームを備え得る。メディアデータボックス304の各々は、1つまたは複数のサンプル305を含み得る。サンプル305の各々は、オーディオアクセスユニットまたはビデオアクセスユニットを備え得る。本開示における他の場所で説明されるように、各アクセスユニットは、マルチビューコーディング(たとえば、MV-HEVCおよび3D-HEVC)およびスケーラブルビデオコーディング(たとえば、SHVC)における複数のコード化ピクチャを備え得る。たとえば、アクセスユニットは、レイヤごとに1つまたは複数のコード化ピクチャを含み得る。
さらに、図7の例では、ムービーボックス302は、トラックボックス306を含む。トラックボックス306は、ファイル300のトラック用のメタデータを封入し得る。他の例では、ムービーボックス302は、ファイル300の異なるトラックのための複数のトラックボックスを含み得る。トラックボックス306は、メディアボックス307を含む。メディアボックス307は、トラック内のメディアデータについての情報を宣言するすべてのオブジェクトを含み得る。メディアボックス307は、メディア情報ボックス308を含む。メディア情報ボックス308は、トラックのメディアの特性情報を宣言するすべてのオブジェクトを含み得る。メディア情報ボックス308は、サンプルテーブルボックス309を含む。サンプルテーブルボックス309は、サンプル固有メタデータを規定し得る。サンプルテーブルボックス309は、0個以上のSampleToGroupボックスおよび0個以上のSampleGroupDescriptionボックスを含み得る。
図7の例では、サンプルテーブルボックス309は、サンプル記述ボックス310を含み得る。追加として、サンプルテーブルボックス309は、0個以上のSampleToGroupボックスおよび0個以上のSampleGroupDescriptionボックスを含み得る。詳細には、図7の例では、サンプルテーブルボックス309は、SampleToGroupボックス311およびSampleGroupDescriptionボックス312を含む。他の例では、サンプルテーブルボックス309は、サンプル記述ボックス310、SampleToGroupボックス311、およびSampleGroupDescriptionボックス312に加えて他のボックスを含んでよく、かつ/または複数のSampleToGroupボックスおよびSampleGroupDescriptionボックスを含んでよい。SampleToGroupボックス311は、サンプル(たとえば、サンプル305のうちの特定のサンプル)をサンプルのグループにマッピングし得る。SampleGroupDescriptionボックス312は、サンプルのグループ(すなわち、サンプルグループ)の中のサンプルによって共有される特性を規定し得る。サンプル記述ボックス310は、トラック用のサンプルエントリ315のセットを備える。サンプル(たとえば、サンプル305のうちの1つ)は、サンプルに適用可能であるものとしてサンプルエントリ315のうちの1つを示すシンタックス要素を含み得る。
さらに、図7の例では、SampleToGroupボックス311は、grouping_typeシンタックス要素313(すなわち、グルーピングタイプシンタックス要素)、entry_countシンタックス要素316(すなわち、エントリカウントシンタックス要素)、および1つまたは複数のサンプルグループエントリ318を含む。grouping_typeシンタックス要素313は、サンプルグルーピングのタイプ(すなわち、サンプルグループを形成するために使用される基準)を識別するとともに、グルーピングタイプに対して同じ値を有するそのサンプルグループ記述テーブルにそれをリンクさせる整数である。いくつかの例では、grouping_typeシンタックス要素313に対して同じ値を有するSampleToGroupボックス311の多くて1つの出現が、トラックに対して存在しなければならない。
entry_countシンタックス要素316は、サンプルグループエントリ318の数を示す。サンプルグループエントリ318の各々は、sample_countシンタックス要素324(すなわち、サンプルカウントシンタックス要素)およびgroup_description_indexシンタックス要素326(すなわち、グループ記述インデックスシンタックス要素)を含む。sample_countシンタックス要素324は、sample_countシンタックス要素324を含むサンプルグループエントリに関連するいくつかのサンプルを示し得る。group_description_indexシンタックス要素326は、group_description_indexシンタックス要素326を含むサンプルグループエントリに関連するサンプルの記述を含むグループ記述エントリを、SampleGroupDescriptionボックス(たとえば、SampleGroupDescriptionボックス312)内で識別し得る。group_description_indexシンタックス要素326は、1からSampleGroupDescriptionボックス312の中のサンプルグループエントリの数までにわたり得る。値0を有するgroup_description_indexシンタックス要素326は、サンプルがgrouping_typeシンタックス要素313によって示されるタイプのどのグループのメンバーでもないことを示す。
追加として、図7の例では、SampleGroupDescriptionボックス312は、grouping_typeシンタックス要素328、entry_countシンタックス要素330、および1つまたは複数のグループ記述エントリ332を含む。grouping_typeシンタックス要素328は、SampleGroupDescriptionボックス312に関連するSampleToGroupボックス(たとえば、SampleToGroupボックス311)を識別する整数である。entry_countシンタックス要素330は、SampleGroupDescriptionボックスの中のグループ記述エントリ332の数を示す。グループ記述エントリ332の各々は、サンプルグループの記述を含み得る。たとえば、グループ記述エントリ332は、「oinf」サンプルグループに対するサンプルグループ記述エントリを含み得る。
本開示の第1の技法によれば、ファイル300の追加トラックの中のそれぞれのサンプルと時間的にコロケートされているサンプルをファイル300の動作点参照トラックが含むことに基づいて、ファイル300を解釈するデバイスは、それぞれの追加トラックの中のそれぞれのサンプルを、SampleGroupDescriptionボックス312の中のグループ記述エントリ332のうちのサンプルグループ記述エントリによって記述された動作点情報サンプルグループの一部であるものと見なし得る。その上、それぞれの追加トラックの中のそれぞれのサンプルと時間的にコロケートされているサンプルを動作点参照トラックが含まないことに基づいて、デバイスは、それぞれの追加トラックの中のそれぞれのサンプルを、それぞれの追加トラックのそれぞれのサンプルよりも前の、動作点参照トラックの中の最終サンプルの動作点情報サンプルグループの一部と見なし得る。
図8は、本開示の1つまたは複数の技法による、ファイル450の例示的な構造を示す概念図である。ファイル450は、ソースデバイス12(図1)、ファイル生成デバイス34(図1)、宛先デバイス14(図1)、ファイル処理ユニット149(図6)、MANE、コンテンツ配信ネットワークデバイス、または他のタイプのデバイスもしくはユニットなどの、様々なデバイスによって生成および処理され得る。図8の例では、ファイル450は、1つまたは複数のムービーフラグメントボックス452および複数のメディアデータボックス454を含む。同じファイルの中にあるものとして図8の例で示されるが、他の例では、ムービーフラグメントボックス452およびメディアデータボックス454が別個のファイルの中にあってよい。メディアデータボックス454の各々は、1つまたは複数のサンプル456を含み得る。ムービーフラグメントボックスの各々は、ムービーフラグメントに対応する。各ムービーフラグメントは、トラックフラグメントのセットを備え得る。トラック当たり0個以上のトラックフラグメントがあり得る。
図8の例では、ムービーフラグメントボックス452は、対応するムービーフラグメントに関する情報を提供する。そのような情報は、以前にムービーボックス302などのムービーボックスの中にあったことになる。ムービーフラグメントボックス452は、トラックフラグメントボックス458を含み得る。トラックフラグメントボックス458は、トラックフラグメントに対応し、トラックフラグメントについての情報を提供する。
たとえば、図8の例では、トラックフラグメントボックス458は、トラックフラグメントボックス458に対応するトラックフラグメントについての情報を含む、1つまたは複数のSampleToGroupボックス462および1つまたは複数のSampleGroupDescriptionボックス464を含み得る。
さらに、図8の例では、トラックフラグメントボックス458は、サンプル記述ボックス460、0個以上のSampleToGroupボックス、および0個以上のSampleGroupDescriptionボックスを含み得る。図8の例では、トラックフラグメントボックス458は、トラックフラグメントボックス458に対応するトラックフラグメントについての情報を含む、SampleToGroupボックス462およびSampleGroupDescriptionボックス464を含む。
サンプル記述ボックス460は、トラックフラグメントに対するサンプルエントリ466のセットを備える。サンプルエントリ466のうちの各それぞれのサンプルエントリは、トラックの1つまたは複数のサンプルに適用される。図8の例では、サンプルエントリ466のセットは、サンプルエントリ466Aを含む。
SampleToGroupボックス462は、grouping_typeシンタックス要素470(すなわち、グルーピングタイプシンタックス要素)、entry_countシンタックス要素474(すなわち、エントリカウントシンタックス要素)、および1つまたは複数のサンプルグループエントリ476を含む。サンプルグループエントリ476の各々は、sample_countシンタックス要素482(すなわち、サンプルカウントシンタックス要素)およびgroup_description_indexシンタックス要素484(すなわち、グループ記述インデックスシンタックス要素)を含む。grouping_typeシンタックス要素470、entry_countシンタックス要素474、sample_countシンタックス要素482、およびgroup_description_index484は、図7の例に関して説明した対応するシンタックス要素と同じセマンティクスを有し得る。
追加として、図8の例では、SampleGroupDescriptionボックス464は、grouping_typeシンタックス要素486、entry_countシンタックス要素488、および1つまたは複数のグループ記述エントリ490を含む。grouping_typeシンタックス要素486、entry_countシンタックス要素488、およびグループ記述エントリ490は、図7の例に関して説明した対応するシンタックス要素およびシンタックス構造と同じセマンティクスを有し得る。たとえば、グループ記述エントリ332は、「oinf」サンプルグループに対するサンプルグループ記述エントリを含み得る。
本開示の第1の技法によれば、ファイル450の追加トラックの中のそれぞれのサンプルと時間的にコロケートされているサンプルをファイル450の動作点参照トラックが含むことに基づいて、ファイル450を解釈するデバイスは、それぞれの追加トラックの中のそれぞれのサンプルを、SampleGroupDescriptionボックス464の中のグループ記述エントリ490のうちのサンプルグループ記述エントリによって記述された動作点情報サンプルグループの一部であるものと見なし得る。その上、それぞれの追加トラックの中のそれぞれのサンプルと時間的にコロケートされているサンプルを動作点参照トラックが含まないことに基づいて、デバイスは、それぞれの追加トラックの中のそれぞれのサンプルを、それぞれの追加トラックのそれぞれのサンプルよりも前の、動作点参照トラックの中の最終サンプルの動作点情報サンプルグループの一部と見なし得る。
図9は、本開示の1つまたは複数の技法による、ダミーサンプルエントリを含むファイル500の例示的な構造を示すブロック図である。ファイル500は、ソースデバイス12(図1)、ファイル生成デバイス34(図1)、宛先デバイス14(図1)、ファイル処理ユニット128(図5)、MANE、コンテンツ配信ネットワークデバイス、または他のタイプのデバイスもしくはユニットなどの、様々なデバイスによって生成および処理され得る。図9の例では、ファイル500は、ムービーボックス502、サンプル505を含むメディアデータボックス504、トラックボックス506、メディアボックス507、メディア情報ボックス508、ならびにサンプル記述ボックス510、SampleToGroupボックス511、およびSampleGroupDescriptionボックス512を含むサンプルテーブルボックス509を含み得る。さらに、図9の例では、サンプル記述ボックス510は、サンプルエントリ515A〜515N(総称して、「サンプルエントリ515」)を含み得る。これらのボックスは、図7の例に関して上記で説明した対応するボックスと類似の構造およびセマンティクスを有し得る。しかしながら、本開示の第4の例示的な技法によれば、サンプル記述ボックス510は、ダミーサンプルエントリ518を含み得る。ダミーサンプルエントリ518は、トラックボックス506に対応するトラックのいかなるサンプルにも適用可能でないが、トラックボックス506に対応するトラックにおけるレイヤに依存するレイヤを含む他のトラックのみによって使用されるパラメータセットを含み得る。たとえば、ダミーサンプルエントリ518は、動作点を記述する情報を含み得る。図8において提供されるものと同様の例が、サンプル記述ボックス460がダミーサンプルエントリを含む場合に行われてよい。
図10は、本開示の1つまたは複数の技法による、サンプルエントリが動作点インデックスを含むファイル550の例示的な構造を示すブロック図である。ファイル550は、ソースデバイス12(図1)、ファイル生成デバイス34(図1)、宛先デバイス14(図1)、ファイル処理ユニット128(図5)、MANE、コンテンツ配信ネットワークデバイス、または他のタイプのデバイスもしくはユニットなどの、様々なデバイスによって生成および処理され得る。図10の例では、ファイル550は、ムービーボックス552、サンプル555を含むメディアデータボックス554、トラックボックス556、メディアボックス557、メディア情報ボックス558、ならびにサンプル記述ボックス560、SampleToGroupボックス561、およびSampleGroupDescriptionボックス562を含むサンプルテーブルボックス559を含み得る。さらに、図10の例では、サンプル記述ボックス560は、サンプルエントリ565A〜565N(総称して、「サンプルエントリ565」)を含み得る。これらのボックスは、図7の例に関して上記で説明した対応するボックスと類似の構造およびセマンティクスを有し得る。
さらに、いくつかの例では、サンプルエントリ565は、LHEVCDecoderConfigurationRecordクラスのインスタンスを含み得る。たとえば、図10の例では、サンプルエントリ565Aは、LHEVCDecoderConfigurationRecord568を含み得る。上記で説明した本開示の第5の例示的な技法によれば、LHEVCDecoderConfigurationRecord568は、1つまたは複数の動作点インデックスシンタックス要素570(たとえば、op_idx)を含み得る。各それぞれの動作点インデックスシンタックス要素は、「oinf」ボックスの中でシグナリングされる動作点のリストへのインデックスを与える。したがって、デバイスは、サンプルのサンプルエントリに基づいて、サンプルによって含められる符号化ピクチャの動作点を決定できる場合がある。図8において提供されるものと同様の例が、サンプルエントリ466が動作点インデックスを含む場合に行われてよい。
図11は、本開示の技法による、ファイルを処理するためのデバイスの例示的な動作を示すフローチャートである。本開示のフローチャートは、例として提供される。他の例では、異なるアクションが実行されてよく、またはアクションが異なる順序で、もしくは並行して実行されてよい。図11の例は、ソースデバイス12(図1)、ファイル生成デバイス34(図1)、ファイル処理ユニット128(図5)、ファイルサーバ、ストリーミングデバイス、MANE、または別のタイプのデバイスもしくはユニットなどの、様々なタイプのデバイスによって実行され得る。
図11の例では、デバイスは、ファイルの中に動作点参照トラックを生成する(600)。トラックを生成することは、トラックに属するサンプルを示すデータを含むトラックボックスを生成することを備え得る。動作点参照トラックを生成することの一部として、デバイスは、ファイルの中のビットストリームにとって利用可能な動作点を記述する動作点情報サンプルグループを、動作点参照トラックの中でシグナリングし得る(602)。いくつかの例では、デバイスは、ビットストリームを生成するためにビデオデータを符号化し得る。追加として、図11の例では、デバイスは、ファイルの中に1つまたは複数の追加トラックを生成し得る(604)。図11の例では、動作点情報サンプルグループは、追加トラックのいずれの中でもシグナリングされない。さらに、それぞれの追加トラックの中のそれぞれのサンプルと時間的にコロケートされているサンプルを動作点参照トラックが含むことに基づいて、それぞれの追加トラックの中のそれぞれのサンプルは、動作点情報サンプルグループの一部と見なされる。それぞれの追加トラックの中のそれぞれのサンプルと時間的にコロケートされているサンプルを動作点参照トラックが含まないことに基づいて、それぞれの追加トラックの中のそれぞれのサンプルは、それぞれの追加トラックのそれぞれのサンプルよりも前の、動作点参照トラックの中の最終サンプルの動作点情報サンプルグループの一部と見なされる。
さらに、図11の例に示すように、いくつかの例では、動作点情報サンプルグループをシグナリングすることの一部として、デバイスは、SampleGroupDescriptionボックス312またはSampleGroupDescriptionボックス464などのサンプルグループ記述ボックスをファイルの中に生成し得る(606)。サンプルグループ記述ボックスは、動作点に対する出力レイヤセット、動作点に対する最大時間識別子、ならびに動作点に対するプロファイル、レベル、およびティアのシグナリングを指定する、サンプルグループ記述エントリ(たとえば、グループ記述エントリ332または490のうちの1つ)を含む。さらに、デバイスは、動作点情報サンプルグループの中のサンプルのセットを指定するとともにサンプルグループ記述ボックスの中のサンプルグループ記述エントリのインデックスを指定するサンプルツーグループボックス(たとえば、SampleToGroupボックス311、462)を、ファイルの中に生成し得る(608)。
図12は、本開示の技法による、ファイルを処理するためのデバイスの例示的な動作を示すフローチャートである。図12の例は、宛先デバイス14、ファイル生成デバイス、ファイルサーバ、ストリーミングデバイス、MANE、または別のタイプのデバイスなどの、様々なタイプのデバイスによって実行され得る。
図12の例では、デバイスは、ファイルの中の動作点参照トラックを取得し得る(650)。ファイルの中のビットストリームにとって利用可能な動作点が、動作点参照トラックの中でシグナリングされる動作点情報サンプルグループを使用してファイルの中に記述される。さらに、図12の例では、デバイスは、ファイルの中の1つまたは複数の追加トラックを取得し得る(652)。動作点情報サンプルグループは、追加トラックのいずれの中でもシグナリングされない。
1つまたは複数の追加トラックのうちの各それぞれの追加トラックのそれぞれのサンプルごとに、デバイスは、それぞれのサンプルを動作点情報サンプルグループの一部と見なすべきかどうかを決定し得る(654)。それぞれの追加トラックの中のそれぞれのサンプルと時間的にコロケートされているサンプルを動作点参照トラックが含むことに基づいて、それぞれの追加トラックの中のそれぞれのサンプルは、動作点情報サンプルグループの一部と見なされる。それぞれの追加トラックの中のそれぞれのサンプルと時間的にコロケートされているサンプルを動作点参照トラックが含まないことに基づいて、それぞれの追加トラックの中のそれぞれのサンプルは、それぞれの追加トラックのそれぞれのサンプルよりも前の、動作点参照トラックの中の最終サンプルの動作点情報サンプルグループの一部と見なされる。
さらに、図12の例では、デバイスは、ビットストリームから動作点を抽出するサブビットストリーム抽出プロセスを実行し得る(656)。いくつかの例では、デバイスは、抽出された動作点の符号化ピクチャを含まないビットストリームのサンプルを送信することなく、抽出された動作点の符号化ピクチャを含むサンプルを送信し得る。いくつかの例では、デバイスは、抽出された動作点の符号化ピクチャを含むサンプルをファイルに記憶することなく、抽出された動作点の符号化ピクチャを含むサンプルを記憶する新たなファイルを生成し得る。いくつかの例では、デバイスは、動作点のビデオデータを復号し得る。たとえば、デバイスは、L-HEVCなどのビデオコーデックを使用して、動作点の符号化ピクチャを復号し得る。
さらに、図12の例に示すように、いくつかの例では、動作点参照トラックを取得することの一部として、デバイスは、SampleGroupDescriptionボックス312またはSampleGroupDescriptionボックス464などのサンプルグループ記述ボックスを、ファイルから取得し得る(658)。サンプルグループ記述ボックスは、動作点に対する出力レイヤセット、動作点に対する最大時間識別子、ならびに動作点に対するプロファイル、レベル、およびティアのシグナリングを指定する、サンプルグループ記述エントリ(たとえば、グループ記述エントリ332または490のうちの1つ)を含む。追加として、デバイスは、動作点情報サンプルグループの中のサンプルのセットを指定するとともにサンプルグループ記述ボックスの中のサンプルグループ記述エントリのインデックスを指定するサンプルツーグループボックス(たとえば、SampleToGroupボックス311、462)を、ファイルから取得し得る(660)。
本明細書で説明した技法のすべてが、個別に使用されても組み合わせて使用されてもよいことを理解されたい。例に応じて、本明細書で説明した技法のいずれかのいくつかの行為またはイベントが、異なるシーケンスで実行されてよく、一緒に追加、統合、または省略されてよい(たとえば、説明したすべての行為またはイベントが技法の実践のために必要であるとは限らない)ことを認識されたい。その上、いくつかの例では、行為またはイベントは、順次的にではなく、たとえば、マルチスレッド処理、割込み処理、またはマルチプロセッサを通じて、同時に実行されてよい。加えて、明快のために本開示のいくつかの態様は単一のモジュールまたはユニットによって実行されるものとして説明されるが、本開示の技法がビデオコーダに関連するユニットまたはモジュールの組合せによって実行され得ることを理解されたい。処理回路は、様々な方法でデータ記憶媒体に結合され得る。たとえば、処理回路は、内部のデバイス相互接続部、有線もしくはワイヤレスのネットワーク接続、または別の通信媒体を介して、データ記憶媒体に結合されてよい。
本開示のいくつかの態様は、例示のためにHEVC規格に関して説明されている。しかしながら、本開示で説明した技法は、まだ開発されていない他の標準的またはプロプライエタリなビデオコーディングプロセスを含む、他のビデオコーディングプロセスにとって有用であり得る。
ビデオエンコーダ20(図1および図5)および/またはビデオデコーダ30(図1および図6)は、一般に、ビデオコーダと呼ばれることがある。同様に、ビデオコーディングは、適用可能な場合、ビデオ符号化またはビデオ復号を指すことがある。
技法の様々な態様の特定の組合せが上記で説明されたが、これらの組合せは、単に本開示で説明する技法の例を示すために提供される。したがって、本開示の技法は、これらの例示的な組合せに限定されるべきではなく、本開示で説明した技法の様々な態様の考えられる任意の組合せを包含し得る。
1つまたは複数の例では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、1つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶されるかまたはコンピュータ可読媒体を介して送信されてよく、ハードウェアベースの処理ユニットによって実行されてよい。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に相当するコンピュータ可読記憶媒体、または、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体を含み得る。このようにして、コンピュータ可読媒体は、概して、(1)非一時的である有形コンピュータ可読記憶媒体、または(2)信号もしくは搬送波などの通信媒体に相当し得る。データ記憶媒体は、本開示で説明した技法の実装のための命令、コード、および/またはデータ構造を取り出すために、1つもしくは複数のコンピュータまたは1つもしくは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であってよい。コンピュータプログラム製品がコンピュータ可読媒体を含んでよい。
限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気記憶デバイス、フラッシュメモリ、または命令もしくはデータ構造の形態の所望のプログラムコードを記憶するために使用され得るとともにコンピュータによってアクセスされ得る任意の他の媒体を備えることができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。ただし、コンピュータ可読記憶媒体およびデータ記憶媒体が、接続、搬送波、信号、または他の一時的媒体を含まず、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピーディスク(disk)、およびBlu-ray(登録商標)レイディスク(disc)を含み、ここで、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、レーザを用いてデータを光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含まれるべきである。
命令は、1つもしくは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、または他の等価な集積論理回路構成もしくは個別論理回路構成などの、1つまたは複数のプロセッサによって実行され得る。したがって、本明細書で使用する「プロセッサ」という用語は、上記の構造、または本明細書で説明した技法の実装に適した任意の他の構造のいずれかを指すことがある。加えて、いくつかの態様では、本明細書で説明した機能は、符号化および復号のために構成された専用のハードウェアモジュール内および/またはソフトウェアモジュール内で提供されてよく、あるいは複合コーデックに組み込まれてよい。また、技法は、1つまたは複数の回路または論理要素で完全に実装され得る。
本開示の技法は、ワイヤレスハンドセット、集積回路(IC)またはICのセット(たとえば、チップセット)を含む、多種多様なデバイスまたは装置において実装され得る。開示する技法を実行するように構成されたデバイスの機能的態様を強調するために、様々な構成要素、モジュール、またはユニットが本開示で説明されたが、それらの構成要素、モジュール、またはユニットは、必ずしも異なるハードウェアユニットによる実現を必要とするとは限らない。むしろ、上記で説明したように、様々なユニットが、好適なソフトウェアおよび/またはファームウェアとともに上記で説明したような1つまたは複数のプロセッサを含む、コーデックハードウェアユニットにおいて組み合わせられるか、または相互動作可能なハードウェアユニットの集合によって提供され得る。
様々な例が説明されている。これらおよび他の例は、以下の特許請求の範囲内に入る。