国際標準化機構(ISO)ベースメディアファイルフォーマット(ISOBMFF)およびISOベースメディアファイルフォーマットから派生したファイルフォーマットは、ビデオコンテンツの記憶のために設計されている。ISOBMFFは、符号化ビデオデータおよび関連するメタデータを記憶するネストされた「ボックス」のセットで定義される。たとえば、メディアデータボックスは、1つまたは複数のサンプルを含み得る。サンプルの各々は、アクセスユニット内の1つまたは複数のピクチャの符号化ビデオデータを含み得る。
ISOBMFFファイルのボックスは、トラックボックスを含む。各トラックボックスは、それぞれのトラックに属するサンプルを指定し得る。たとえば、第1のトラックボックスは、第1のトラックに属するサンプルを指定し、第2のトラックボックスは、第2のトラックに属するサンプルを指定し、以下同様であり得る。したがって、ファイルのトラックは、サンプルのファイルレベルのグループと見なされ得る。いくつかのトラックについて、ISOBMFFファイルを処理するデバイスは、ファイル内の他のトラックのサンプルに記憶されている符号化ビデオデータを解釈または復号せずにISOBMFFファイルのトラックに関する異なるアクションを実行することがある。たとえば、デバイスは、別のトラックのサンプルをビデオデコーダに転送しながら、あるトラックのサンプルを破棄することができる。
高効率ビデオコーディング(HEVC)およびレイヤードHEVC(L-HEVC)ビデオコーディング規格は、レイヤおよびサブレイヤの概念を定義する。マルチビューコーディングでは、異なるレイヤのピクチャは、異なるビューのピクチャに対応し得る。スケーラブルビデオコーディングでは、異なる非ベースレイヤのピクチャは、信号対雑音比(SNR)エンハンスメントデータ、空間的エンハンスメントデータ、および/または時間的エンハンスメントデータなど、様々なタイプのエンハンスメントを含むピクチャに対応し得る。時間サブレイヤは、レイヤ内のピクチャのサブセットである。時間スケーラビリティを提供するために、時間サブレイヤを使用することができる。
符号化ビデオデータは、シーケンス終了(EOS)ネットワークアブストラクションレイヤ(NAL)ユニットおよびビットストリーム終了(EOB)NALユニットを含み得る。EOS NALユニットは、コード化ビデオシーケンス(CVS)の終了をマークする。したがって、ビデオデコーダは、EOS NALユニットに基づいて、CVSが終了したと判断し得る。一般に、CVSは、一連のアクセスユニットである。HEVCでは、CVSは、復号順序で、NoRaslOutputFlagが1に等しいIRAPアクセスユニットである任意の後続のアクセスユニットまでの、しかしそれを含まないすべての後続のアクセスユニットを含む、NoRaslOutputFlagが1に等しいIRAPアクセスユニットと、次いでNoRaslOutputFlagが1に等しい非IRAPアクセスユニットである0個以上のアクセスユニットとからなるアクセスユニットのシーケンスである。
EOB NALユニットは、ビットストリームの終了をマークする。したがって、ビデオデコーダは、EOB NALユニットに基づいて、ビットストリームが終了したと判断し得る。ビットストリームは、1つまたは複数のCVSを形成するコード化ピクチャおよび関連データの表現を形成する、NALユニットストリームまたはバイトストリームの形式のビットのシーケンスである。NALユニットストリームは、NALユニットのシーケンスである。バイトストリームは、(たとえば、HEVCの付属書類Bに指定されているような)スタートコードプレフィックスおよびNALユニットを含むNALユニットストリームのカプセル化である。
EOS NALユニットおよびEOB NALユニットに関連するいくつかの問題は、異なる時間サブレイヤに関連するNALユニットがファイルの異なるトラックにあるときに生じ得る。たとえば、EOS NALユニットまたはEOB NALユニットを含むトラックが破棄された場合(たとえば、トラックに関連する時間サブレイヤが転送または復号されないので)、CVSまたはビットストリームが終了したとき、ビデオデコーダには不明瞭である場合がある。さらに、トラックを破棄することから生じるビットストリームは、ビデオコーディング規格の要件に準拠しない可能性がある。ビデオコーディング規格の要件に準拠するビットストリームを復号するように構成されたビデオデコーダは、ビデオコーディング規格の要件に準拠しないビットストリームを復号することができない可能性がある。
本開示の技法は、これらの問題に対処し得る。たとえば、本開示の技法によれば、デバイスは、ファイルの第1のトラックにおいて、ビットストリームのCVSについての第1のEOS NALユニットを生成し得る。言い換えれば、デバイスは、ファイルの第1のトラックに、CVSの第1のEOS NALユニットを含め得る。第1のEOS NALユニットは、CVSの第1のアクセスユニットにある。この例では、デバイスは、ファイルの第2のトラックに、CVSについての第2のEOS NALユニットを生成し得る。言い換えれば、デバイスは、ファイルの第2のトラックに、CVSの第2のEOS NALユニットを含め得る。第2のEOS NALユニットは、CVSの第2のアクセスユニットにある。この例では、第1のアクセスユニットおよび第2のアクセスユニットは、異なる時間サブレイヤに属してもよい。このようにして、異なるトラック内の複数のEOS NALユニットを可能にすることによって、トラックのうちの1つまたは複数なしで生成されたビットストリームが依然として準拠するビットストリームであり得る。
別の例では、本開示の技法によれば、デバイスは、ファイルの第1のトラックにおいて、ビットストリームのCVSについての第1のEOB NALユニットを生成し得る。言い換えれば、デバイスは、ファイルの第1のトラックに、CVSについての第1のEOB NALユニットを含め得る。第1のEOB NALユニットは、CVSの第1のアクセスユニットにある。この例では、デバイスは、ファイルの第2のトラックに、ビットストリームのCVSについての第2のEOB NALユニットを生成し得る。言い換えれば、デバイスは、ファイルの第2のトラックに、CVSについての第2のEOB NALユニットを含め得る。第2のEOB NALユニットは、CVSの第2のアクセスユニットにある。このように、異なるトラック内の複数のEOB NALユニットを可能にすることによって、トラックのうちの1つまたは複数がないファイルから生成されたビットストリームが依然として準拠するビットストリームであり得る。したがって、本開示の技法は、ファイルの複数のトラックに記憶されたビットストリームを復号するビデオデコーダの能力を向上させ得る。さらに、ファイルレベルからトラックを抽出するデバイスは、オンザフライでEOSおよびEOB NALユニットをチェックし、生成する必要なく、トラック内のビットストリームが適切なEOSおよびEOB NALユニットを有することが保証され得るので、本開示の技法は、そのようなデバイスの動作を加速することができる。
本開示では、「第1」、「第2」、「第3」などの順序の用語は、必ずしも順序内の位置の指標ではなく、むしろ単に同じものの異なるインスタンスを区別するために使用され得る。
図1は、本開示で説明する技法を使用し得る例示的なビデオ符号化および復号システム10を示すブロック図である。図1に示されたように、システム10は、後で宛先デバイス14によって復号されるべき符号化ビデオデータを生成するソースデバイス12を含む。ソースデバイス12および宛先デバイス14は、デスクトップコンピュータ、ノートブック(すなわち、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲーミングコンソール、ビデオストリーミングデバイスなどを含む、広範囲のデバイスのうちのいずれかを備える場合がある。場合によっては、ソースデバイス12および宛先デバイス14は、ワイヤレス通信用に装備される場合がある。したがって、ソースデバイス12および宛先デバイス14は、ワイヤレス通信デバイスと見なされ得る。ソースデバイス12および宛先デバイス14は、ビデオデバイスと見なされてもよい。
図1の例では、ソースデバイス12は、ビデオソース18、ビデオエンコーダ20、および出力インターフェース22を含む。場合によっては、出力インターフェース22は、変調器/復調器(モデム)および/または送信機を含み得る。出力インターフェース22が、符号化されたビデオ情報をコンピュータ可読媒体16に出力し得る。出力インターフェース22は、様々なタイプの構成要素またはデバイスを備え得る。たとえば、出力インターフェース22は、ワイヤレス送信機、モデム、有線ネットワーキング構成要素(たとえば、イーサネット(登録商標)カード)、または別の物理的な構成要素を備え得る。出力インターフェース22がワイヤレス送信機を備える例では、出力インターフェース22は、4G、4G-LTE、LTE Advanced、5Gなどのセルラー通信規格に従って変調される、符号化ビデオデータなどのデータを送信するように構成され得る。出力インターフェース22がワイヤレス送信機を備えるいくつかの例では、出力インターフェース22は、IEEE 802.11仕様、IEEE 802.15仕様(たとえば、ZigBee(商標))、Bluetooth(登録商標)規格などの他のワイヤレス規格に従って変調される、符号化ビデオデータなどのデータを送信するように構成され得る。いくつかの例では、出力インターフェース22の回路は、ビデオエンコーダ20の回路および/またはソースデバイス12の他の構成要素に組み込まれる。たとえば、ビデオエンコーダ20および出力インターフェース22は、システムオンチップ(SoC)の一部であり得る。SoCは、汎用マイクロプロセッサ、グラフィックス処理装置などの、他の構成要素も含み得る。
ソースデバイス12において、ビデオソース18は、ビデオキャプチャデバイス、たとえば、ビデオカメラ、以前キャプチャされたビデオを含むビデオアーカイブ、ビデオコンテンツプロバイダからビデオを受信するビデオフィードインターフェース、および/もしくはソースビデオとしてコンピュータグラフィックスデータを生成するためのコンピュータグラフィックスシステム、またはそのようなソースの組合せなどのソースを含む場合がある。しかしながら、本開示において記載される技法は、ビデオコーディング全般に適用可能な場合があり、ワイヤレス用途および/または有線用途に適用される場合がある。
ビデオエンコーダ20は、キャプチャされた、あらかじめキャプチャされた、またはコンピュータ生成されたビデオを符号化することができる。いくつかの例では、ソースデバイス12は、ソースデバイス12の出力インターフェース22を介して符号化ビデオデータを宛先デバイス14へ直接送信する。符号化ビデオデータは、同様に(または、代替的に)、復号および/または再生のための宛先デバイス14または他のデバイスによる後のアクセスのために、ストレージデバイス33に記憶される場合がある。
宛先デバイス14は、入力インターフェース28、ビデオデコーダ30、およびディスプレイデバイス32を含む。さらに、図1の例では、宛先デバイス14は、記憶媒体29と、ファイルパーシングユニット31とを含む。場合によっては、入力インターフェース28は、受信機および/またはモデムを含む場合がある。宛先デバイス14の入力インターフェース28は、リンク16を通じて符号化ビデオデータを受信する。リンク16を通じて通信された、またはストレージデバイス33上に提供された符号化ビデオデータは、ビデオデータを復号する際にビデオデコーダ30などのビデオデコーダによって使用するための、ビデオエンコーダ20によって生成された様々なシンタックス要素を含み得る。そのようなシンタックス要素は、通信媒体上で送信された、記憶媒体に記憶された、またはファイルサーバに記憶された、符号化ビデオデータとともに含まれ得る。
宛先デバイス14の入力インターフェース28は、コンピュータ可読媒体16からデータを受信する。入力インターフェース28は、様々なタイプの構成要素またはデバイスを備え得る。たとえば、入力インターフェース28は、ワイヤレス受信機、モデム、有線ネットワーキング構成要素(たとえば、イーサネット(登録商標)カード)、または別の物理的な構成要素を備え得る。入力インターフェース28がワイヤレス受信機を備える例では、入力インターフェース28は、4G、4G-LTE、LTE Advanced、5Gなどのセルラー通信規格に従って変調される、ビットストリームなどのデータを受信するように構成され得る。入力インターフェース28がワイヤレス受信機を備えるいくつかの例では、入力インターフェース28は、IEEE 802.11仕様、IEEE 802.15仕様(たとえば、ZigBee(商標))、Bluetooth(登録商標)規格などの他のワイヤレス規格に従って変調される、ビットストリームなどのデータを受信するように構成され得る。いくつかの例では、入力インターフェース28の回路は、ビデオデコーダ30の回路および/または宛先デバイス14の他の構成要素に組み込まれ得る。たとえば、ビデオデコーダ30および入力インターフェース28は、SoCの一部であり得る。SoCは、汎用マイクロプロセッサ、グラフィックス処理装置などの、他の構成要素も含み得る。
ディスプレイデバイス32は、宛先デバイス14と一体であることがあり、または宛先デバイス14の外部にあることがある。いくつかの例では、宛先デバイス14は、一体化されたディスプレイデバイスを含むことがあり、また、外部ディスプレイデバイスとインターフェースするように構成されることがある。他の例では、宛先デバイス14はディスプレイデバイスであり得る。一般に、ディスプレイデバイス32は、復号されたビデオデータをユーザに表示し、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスなどの、様々なディスプレイデバイスのいずれかを備え得る。
ビデオエンコーダ20およびビデオデコーダ30は、各々、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなどの、適用可能な場合、固定関数および/またはプログラマブル回路を含む、様々な適切なエンコーダまたはデコーダ回路のいずれかとして実装される場合がある。技法が部分的にソフトウェアで実装されるとき、デバイスは、好適な非一時的コンピュータ可読媒体にソフトウェアのための命令を記憶してよく、本開示の技法を実行するための1つまたは複数のプロセッサを使用してハードウェアで命令を実行してよい。ビデオエンコーダ20およびビデオデコーダ30の各々は、1つまたは複数のエンコーダまたはデコーダに含まれることがあり、そのいずれもが、それぞれのデバイスにおいて複合エンコーダ/デコーダ(コーデック)の一部として統合されることがある。
宛先デバイス14は、リンク16を介して、復号されるべき符号化ビデオデータを受信することができる。リンク16は、ソースデバイス12から宛先デバイス14に符号化ビデオデータを移動することが可能な任意のタイプの媒体またはデバイスを備える場合がある。一例では、リンク16は、ソースデバイス12がリアルタイムで宛先デバイス14に直接符号化ビデオデータを送信することを可能にするために、通信媒体を備える場合がある。符号化ビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され、宛先デバイス14に送信される場合がある。通信媒体は、無線周波数(RF)スペクトルまたは1つもしくは複数の物理伝送線路などの、任意のワイヤレスまたは有線の通信媒体を備える場合がある。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなどの、パケットベースネットワークの一部を形成する場合がある。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイス12から宛先デバイス14への通信を容易にするために有用であり得る任意の他の機器を含む場合がある。
いくつかの例では、出力インターフェース22は、符号化データをストレージデバイス33に出力する。同様に、入力インターフェース28は、ストレージデバイス33からの符号化データにアクセスし得る。ストレージデバイス33は、ハードドライブ、Blu-ray(登録商標)ディスク、DVD、CD-ROM、フラッシュメモリ、揮発性もしくは不揮発性メモリ、または、符号化ビデオデータを記憶するための任意の他の適切なデジタル記憶媒体などの、様々な分散されたまたはローカルでアクセスされるデータ記憶媒体のいずれかを含み得る。さらなる例では、ストレージデバイス33は、ソースデバイス12によって生成された符号化ビデオを保持し得るファイルサーバまたは別の中間ストレージデバイスに対応し得る。宛先デバイス14は、ストリーミングまたはダウンロードを介して、ストレージデバイス33からの記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化ビデオデータを記憶し、その符号化ビデオデータを宛先デバイス14に送信することが可能な任意のタイプのサーバであり得る。例示的なファイルサーバは、(たとえば、ウェブサイトのための)ウェブサーバ、ファイル転送プロトコル(FTP)サーバ、ネットワーク接続ストレージ(NAS)デバイス、またはローカルディスクドライブを含む。宛先デバイス14は、インターネット接続を含む任意の標準的なデータ接続を介して、符号化ビデオデータにアクセスすることができる。これは、ファイルサーバに記憶された符号化ビデオデータにアクセスするのに適した、ワイヤレスチャネル(たとえば、Wi-Fi接続)、有線接続(たとえば、DSL、ケーブルモデムなど)、または両方の組合せを含み得る。ストレージデバイス33からの符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、または両方の組合せであり得る。
本開示の技法は、ワイヤレスの適用例または設定に必ずしも限定されるとは限らない。技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、たとえばインターネットを介したストリーミングビデオ送信、データ記憶媒体に記憶するためのデジタルビデオデータの符号化、データ記憶媒体に記憶されたデジタルビデオデータの復号、または他の用途などの、様々なマルチメディア用途のうちのいずれかをサポートするビデオコーディングに適用される場合がある。いくつかの例では、システム10は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および/またはビデオ電話などの適用例をサポートするために、一方向または双方向のビデオ送信をサポートするように構成され得る。
さらに、図1の例では、システム10は、ファイル生成デバイス34を含む。ファイル生成デバイス34は、ソースデバイス12によって生成された符号化ビデオデータを受信し得る。ファイル生成デバイス34は、符号化ビデオデータを含むファイルを生成し得る。宛先デバイス14は、ファイル生成デバイス34によって生成されたファイルを受信し得る。様々な例では、ファイル生成デバイス34は、様々なタイプのコンピューティングデバイスを含み得る。たとえば、ファイル生成デバイス34は、ビデオ符号化デバイス、メディアアウェアネットワーク要素(MANE:Media Aware Network Element)、サーバコンピューティングデバイス、パーソナルコンピューティングデバイス、専用コンピューティングデバイス、商用コンピューティングデバイス、または別のタイプのコンピューティングデバイスを備え得る。いくつかの例では、ファイル生成デバイス34は、コンテンツ配信ネットワークの一部である。ファイル生成デバイス34は、ソースデバイス12からリンク16などのチャネルを介して符号化ビデオデータを受信し得る。さらに、宛先デバイス14は、ファイル生成デバイス34からリンク16などのチャネルを介してファイルを受信し得る。ファイル生成デバイス34は、ビデオデバイスと見なされてよい。図1の例に示すように、ファイル生成デバイス34は、符号化ビデオコンテンツを含むファイルを記憶するように構成されたメモリ36を備え得る。
他の例では、ソースデバイス12または別のコンピューティングデバイスが、符号化ビデオデータを含むファイルを生成し得る。しかしながら、説明を容易にするために、本開示は、ファイルを生成するものとしてファイル生成デバイス34を説明する。とはいえ、そのような説明が全般にコンピューティングデバイスに適用可能であることを理解されたい。
いくつかの例では、MANE、サーバ、または他のタイプのデバイスは、本開示の技法に従って生成されたファイルを記憶するように構成されたメモリを備え得る。このデバイスは、たとえば、ファイルからシンタックス要素を取得することによってファイルを処理し、ファイル内の特定のコンテンツを宛先デバイス14など別のデバイスに転送するなど、様々な目的のために取得されたシンタックス要素を使用することができる。
ビデオエンコーダ20およびビデオデコーダ30は、ITU-T H.265、高効率ビデオコーディング(HEVC)規格、またはその拡張などのビデオ圧縮規格に従って動作し得る。HEVC規格は、ISO/IEC23008-2とも呼ばれることもある。ITU-Tビデオコーディングエキスパートグループ(VCEG)およびISO/IECモーションピクチャエキスパートグループ(MPEG)のビデオコーディング共同研究部会(JCT-VC)によって、HEVCの設計が確定された。ビデオエンコーダ20およびビデオデコーダ30は、これらの規格または他の規格の1つまたは複数に従って動作することができる。そのような他のビデオコーディング規格は、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、そのスケーラブルビデオコーディング(SVC)拡張とマルチビュービデオコーディング(MVC)拡張とを含むITU-T H.264またはISO/IEC MPEG-4 AVCを含む。いくつかの例では、ビデオエンコーダ20およびビデオデコーダ30は、代替的に、MPEG-4、Part 10、Advanced Video Coding(AVC)と呼ばれるITU-T H.264規格、またはそのような規格の拡張などの、他の独自規格または業界規格に従って動作する。しかしながら、本開示の技法は、いかなる特定のコーディング規格にも限定されない。
一般に、HEVCでは、ビデオフレームまたはピクチャが、輝度サンプルと彩度サンプルの両方を含む一連のツリーブロックまたは最大コーディング単位(LCU)に分割されてもよい。ツリーブロックは、コーディングツリーユニット(CTU)とも呼ばれ得る。ツリーブロックは、H.264/AVC規格のマクロブロックと同様の目的を有する。スライスは、コーディング順にいくつかの連続するツリーブロックを含む。ビデオフレームまたはピクチャは、1つまたは複数のスライスに区分されてもよい。各ツリーブロックは、4分木に従ってコーディングユニット(CU)に分割されてもよい。たとえば、ツリーブロックは、4分木のルートノードとして、4つの子ノードに分割されてもよく、各子ノードは、次に、親ノードになり、別の4つの子ノードに分割されてもよい。最後の、分割されていない子ノードは、4分木のリーフノードとして、コーディングノード、すなわちコード化ビデオブロックを備える。コード化ビットストリームに関連付けられたシンタックスデータは、ツリーブロックが分割され得る最大回数を定義してもよく、また、コーディングノードの最小サイズを定義してもよい。
CUは、コーディングノードと、コーディングノードに関連付けられた予測ユニット(PU)および変換ユニット(TU)とを含む。CUのサイズは、コーディングノードのサイズに対応し、形状が正方形でなければならない。CUのサイズは、8×8ピクセルから、最大64×64ピクセルまたはそれ以上のツリーブロックのサイズまでの範囲であってもよい。各CUは、1つまたは複数のPUと1つまたは複数のTUとを含んでもよい。CUに関連付けられたシンタックスデータは、たとえば、1つまたは複数のPUへのCUの区分を記述してもよい。区分モードは、CUがスキップもしくは直接モードで符号化されているか、イントラ予測モードで符号化されているか、またはインター予測モードで符号化されているかに応じて異なり得る。PUは、形状が非正方形であるように区分されてよい。CUに関連付けられたシンタックスデータはまた、たとえば、4分木に従った1つまたは複数のTUへのCUの区分化を記述してもよい。TUは、形状が正方形または非正方形であり得る。
HEVC規格は、CUによって異なり得る、TUに従う変換を可能にする。TUは、典型的には、区分されたLCUのために定義された所与のCU内のPUのサイズに基づいてサイズが決められるが、これは、必ずしもそうでないことがある。TUは通常、PUと同じサイズであるか、またはPUよりも小さい。いくつかの例では、CUに対応する残差サンプルは、「残差4分木」(RQT:residual quad tree)と呼ばれる4分木構造を使用して、より小さいユニットに再分割され得る。RQTのリーフノードは、TUと呼ばれることがある。TUに関連付けられたピクセル差分値は、量子化されてもよい変換係数を生成するために変換されてもよい。
一般に、PUは、予測プロセスに関連するデータを含む。たとえば、PUがイントラモード符号化されるとき、PUは、PUのイントラ予測モードを記述するデータを含み得る。別の例として、PUがインターモード符号化されるとき、PUは、PUの動きベクトルを定義するデータを含み得る。PUの動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの解像度(たとえば、1/4ピクセル精度または1/8ピクセル精度)、動きベクトルが指す参照ピクチャ、および/または動きベクトルのための参照ピクチャリスト(たとえば、リスト0、リスト1)を記述し得る。
一般に、TUは、変換および量子化プロセスのために使用される。1つまたは複数のPUを有する所与のCUはまた、1つまたは複数のTUを含み得る。予測に続いて、ビデオエンコーダ20は、PUに対応する残差値を計算することができる。残差値は、ピクセル差分値を備え、ピクセル差分値は、エントロピーコーディングのためのシリアライズ化された変換係数を生成するために、変換係数に変換され、量子化され、TUを使用して走査されてもよい。本開示は、典型的には、CUのコーディングノード(すなわち、コーディングブロック)を指すために「ビデオブロック」という用語を使用する。いくつかの特定の場合には、本開示はまた、コーディングノードとPUおよびTUとを含むツリーブロック、すなわち、LCUまたはCUを指すために「ビデオブロック」という用語を使用することがある。
ビデオシーケンスは、典型的には、一連のビデオフレームまたはピクチャを含む。ピクチャの各スライスは、それぞれのスライスの符号化モードを記述するスライス構文データを含んでもよい。ビデオエンコーダ20は通常、ビデオデータを符号化するために、個々のビデオスライス内のビデオブロック上で動作する。ビデオブロックは、CU内のコーディングノードに対応する場合がある。ビデオブロックは固定サイズまたは可変サイズを有してもよく、指定されたコーディング規格に従ってサイズが異なってもよい。
CUのPUを使用するイントラ予測またはインター予測コーディングに続いて、ビデオエンコーダ20は、CUのTUのための残差データを計算してもよい。PUは、空間領域(ピクセル領域とも呼ばれる)におけるピクセルデータを備えてもよく、TUは、残差ビデオデータへの変換、たとえば、離散コサイン変換(DCT:discrete cosine transform)、整数変換、ウェーブレット変換、または概念的に同様の変換の適用に続いて、変換領域における係数を備えてもよい。残差データは、符号化されていないピクチャのピクセルと、PUに対応する予測値との間のピクセル差に対応してもよい。ビデオエンコーダ20は、CUのための残差データを含むTUを形成し、次いで、CUのための変換係数を生成するためにTUを変換してもよい。
変換係数を生成するための任意の変換に続いて、ビデオエンコーダ20は、変換係数の量子化を実行し得る。量子化は、一般に、係数を表すために使用されるデータの量をできる限り低減するために変換係数が量子化され、さらなる圧縮が行われるプロセスを指す。量子化プロセスは、係数の一部またはすべてに関連付けられたビット深度を低減することができる。
量子化された変換係数を走査して1次元ベクトルを形成した後、ビデオエンコーダ20は、たとえば、コンテキスト適応型可変長コーディング(CAVLC)、コンテキスト適応型バイナリ算術コーディング(CABAC)、シンタックスベースのコンテキスト適応型バイナリ算術コーディング(SBAC)、確率間隔区分化エントロピー(PIPE)コーディング、または別のエントロピー符号化方法に従って、1次元ベクトルをエントロピー符号化することができる。ビデオエンコーダ20はまた、ビデオデータを復号する上でビデオデコーダ30によって使用するための符号化ビデオデータに関連付けられたシンタックス要素をエントロピー符号化してもよい。
ビデオエンコーダ20は、コーディングされたピクチャの表現および関連するデータを形成するビットのシーケンスを含むビットストリームを出力することができる。「ビットストリーム」という用語は、ネットワークアブストラクションレイヤ(NAL)ユニットストリーム(たとえば、NALユニットのシーケンス)またはバイトストリーム(たとえば、HEVC規格の附属書類Bによって指定されているように、スタートコードプレフィックスおよびNALユニットを含むNALユニットストリームのカプセル化)のいずれかを指すために使用される総称であり得る。NALユニットは、NALユニットにおけるデータのタイプの指示と、必要に応じてエミュレーション防止ビットを散在させたローバイトシーケンスペイロード(RBSP)の形式による、そのデータを含むバイトとを含むシンタックス構造である。NALユニットの各々は、NALユニットヘッダを含むことができ、RBSPをカプセル化し得る。NALユニットヘッダは、NALユニットタイプコードを示すシンタックス要素を含む場合がある。NALユニットのNALユニットヘッダによって指定されるNALユニットタイプコードは、NALユニットのタイプを示す。RBSPは、NALユニット内にカプセル化されている整数個のバイトを含むシンタックス構造であり得る。いくつかの事例では、RBSPは0個のビットを含む。
様々なタイプのNALユニットは、様々なタイプのRBSPをカプセル化することができる。たとえば、第1のタイプのNALユニットはピクチャパラメータセット(PPS)のためのRBSPをカプセル化することがあり、第2のタイプのNALユニットはスライスセグメントのためのRBSPをカプセル化することがあり、第3のタイプのNALユニットは補足強化情報(SEI)のためのRBSPをカプセル化することがあり、以下同様である。ビデオコーディングデータに対してRBSPをカプセル化するNALユニットは(パラメータセットおよびSEIメッセージに対するRBSPとは対照的に)、ビデオコーディングレイヤ(VCL)NALユニットと呼ばれることがある。パラメータセット(たとえば、ビデオパラメータセット(VPS)、シーケンスパラメータセット(SPS)、PPS、または他のタイプのパラメータセット)を含むNALユニットは、パラメータセットNALユニットと呼ばれ得る。
本開示は、セグメントスライスのRBSPをコード化スライスNALユニットとしてカプセル化するNALユニットを指すことがある。HEVCで定義されているように、スライスセグメントは、タイル走査において連続的に順序付けられ単一のNALユニットに含まれている、整数個のCTUである。対照的に、HEVCでは、スライスは、1つの独立スライスセグメントに含まれ、同じアクセスユニット内に次の独立スライスセグメントが(もしあれば)それに先行するすべての後続の従属スライスセグメントが(もしあれば)それらに含まれる、整数個のCTUであり得る。独立スライスセグメントは、スライスセグメントヘッダのシンタックス要素の値が、先行するスライスセグメントの値から推論されないスライスセグメントである。従属スライスセグメントは、スライスセグメントヘッダのいくつかのシンタックス要素の値が、復号順序で先行する独立スライスセグメントの値から推論されるスライスセグメントである。コード化スライスNALユニットのRBSPは、スライスセグメントヘッダおよびスライスデータを含み得る。スライスセグメントヘッダは、スライスセグメント内に表された第1のCTUまたはすべてのCTUに関するデータ要素を含むコード化スライスセグメントの一部である。スライスヘッダは、現在のスライスセグメントである独立スライスセグメントの、または復号順序で現在の従属スライスセグメントに先行する直近の独立スライスセグメントの、スライスセグメントヘッダである。
ビデオデコーダ30は、ビデオエンコーダ20によって生成されたビットストリームを受信し得る。加えて、ビデオデコーダ30は、ビットストリームを構文解析してビットストリームからシンタックス要素を取得し得る。ビデオデコーダ30は、ビットストリームから取得されたシンタックス要素に少なくとも部分的に基づいて、ビデオデータのピクチャを再構築することができる。ビデオデータを再構築するためのプロセスは、全般に、ビデオエンコーダ20によって実行されるプロセスの逆であり得る。たとえば、ビデオデコーダ30は、PUの動きベクトルを使用して、現在のCUのPUの予測ブロックを決定し得る。加えて、ビデオデコーダ30は、現在のCUのTUの係数ブロックを逆量子化し得る。ビデオデコーダ30は、係数ブロックに対して逆変換を実行して、現在のCUのTUの変換ブロックを再構築し得る。ビデオデコーダ30は、現在のCUのPUの予測ブロックのサンプルを、現在のCUのTUの変換ブロックの対応するサンプルに加算することによって、現在のCUのコーディングブロックを再構築し得る。ピクチャのCUごとにコーディングブロックを再構築することによって、ビデオデコーダ30はピクチャを再構築し得る。
上記で説明したように、ビデオエンコーダ20は、一連のNALユニットを備えるビットストリームを生成し得る。マルチレイヤビデオコーディングでは、ビットストリームの異なるNALユニットは、ビットストリームの異なるレイヤに関連し得る。レイヤは、同じレイヤ識別子を有するVCL NALユニットおよび関連する非VCL NALユニットのセットとして定義され得る。たとえば、NALユニットは、ヘッダ(すなわち、NALユニットヘッダ)およびペイロード(たとえば、RBSP)を含み得る。NALユニットヘッダは、レイヤ識別子シンタックス要素(たとえば、HEVCにおけるnuh_layer_idシンタックス要素)を含み得る。異なる値を指定するレイヤ識別子シンタックス要素を有するNALユニットは、ビットストリームの異なる「レイヤ」に属する。したがって、マルチレイヤコーディング(たとえば、MV-HEVC、SVC、またはSHVC)において、NALユニットのレイヤ識別子シンタックス要素は、NALユニットのレイヤ識別子(すなわち、レイヤID)を指定する。
レイヤは、マルチビュービデオコーディングにおけるビューと等価であり得る。マルチビュービデオコーディングでは、レイヤは、異なる時間インスタンスを有する同じレイヤのすべてのビューコンポーネントを含むことができる。マルチレイヤビデオコーディングにおいて、「アクセスユニット」という用語は、同じ時間インスタンスに対応するピクチャのセットを指し得る。たとえば、アクセスユニット内のすべてのピクチャは、同じ出力時間を有し得る。したがって、「ビューコンポーネント」は、単一のアクセスユニットの中のビューのコード化表現であり得る。
いくつかの例では、ビューコンポーネントは、テクスチャビューコンポーネント(すなわち、テクスチャピクチャ)または深度ビューコンポーネント(すなわち、深度ピクチャ)を含み得る。マルチビュービデオコーディングのいくつかの例では、レイヤは、特定のビューのコード化深度ピクチャ、または特定のビューのコード化テクスチャピクチャのいずれかを含むが、深度ピクチャおよびテクスチャピクチャの両方を含まない。マルチビュービデオコーディングの他の例では、レイヤは、特定のビューのテクスチャビューコンポーネントと深度ビューコンポーネントの両方を含む。
スケーラブルビデオコーディングのコンテキストでは、レイヤは、通常、他のレイヤの中のコード化ピクチャとは異なるビデオ特性を有するコード化ピクチャに対応する。そのようなビデオ特性は、通常、空間解像度および品質レベル(たとえば、信号対雑音比)を含む。
ビットストリームのそれぞれのレイヤごとに、下位レイヤの中のデータは、いかなる上位レイヤの中のデータも参照せずに復号され得る。スケーラブルビデオコーディングでは、たとえば、ベースレイヤの中のデータは、エンハンスメントレイヤの中のデータを参照せずに復号され得る。一般に、NALユニットは、単一のレイヤのデータのみをカプセル化し得る。したがって、ビットストリームの残りの最上位レイヤ(たとえば、最も高いレイヤ識別子に関連付けられたレイヤ)のデータをカプセル化するNALユニットは、ビットストリームの残りのレイヤの中のデータの復号可能性に影響を及ぼすことなくビットストリームから除去され得る。マルチビューコーディングでは、上位レイヤは、追加のビューコンポーネントを含み得る。スケーラブルビデオコーディングでは、上位レイヤは、信号対雑音比(SNR)エンハンスメントデータ、空間エンハンスメントデータ、および/または時間エンハンスメントデータを含み得る。マルチレイヤビデオコーディングでは、ビデオデコーダがいかなる他のレイヤのデータも参照せずにレイヤの中のピクチャを復号できる場合、そのレイヤは「ベースレイヤ」と呼ばれることがある。HEVCおよび他のビデオコーディング仕様では、NALユニットがベースレイヤにある場合、NALユニットのレイヤ識別子は0に等しい。NALユニットがマルチレイヤコーディングにおけるベースレイヤに関係しない場合、NALユニットのレイヤ識別子は非0値を有し得る。
スケーラブルビデオコーディングでは、ベースレイヤ以外のレイヤは、「エンハンスメントレイヤ」と呼ばれることがあり、ビットストリームから復号されたビデオデータの視覚的品質を向上させる情報を提供し得る。スケーラブルビデオコーディングは、空間解像度、信号対雑音比(すなわち、品質)、または時間的なレートを向上させることができる。
マルチレイヤビデオコーディングは、レイヤ間予測をサポートし得る。レイヤ間予測は、HEVCおよび他のビデオコーディング仕様において使用されるインター予測と類似しており、同じシンタックス要素を使用し得る。しかしながら、ビデオコーダが現在の(PUなどの)ビデオユニットに対してレイヤ間予測を実行するとき、ビデオコーダは、現在のビデオユニットと同じアクセスユニットの中にあるが異なるレイヤの中にあるピクチャを、参照ピクチャとして使用し得る。対照的に、従来のインター予測は、異なるアクセスユニットの中のピクチャしか参照ピクチャとして使用しない。非ベースレイヤのうちの1つの中のピクチャをコーディングするとき、ビデオコーダは、ピクチャが異なるレイヤの中にあるがビデオコーダが現在コーディングしているピクチャと同じ時間インスタンス(すなわち、アクセスユニット)内にある場合、そのピクチャを参照ピクチャリストに追加し得る。
さらに、レイヤ内のいくつかのピクチャは、同じレイヤ内の他のピクチャを参照せずに復号され得る。したがって、レイヤのいくつかのピクチャのデータをカプセル化するNALユニットは、レイヤの中の他のピクチャの復号可能性に影響を及ぼすことなくビットストリームから除去され得る。そのようなピクチャのデータをカプセル化するNALユニットを除去すると、ビットストリームのフレームレートが低下し得る。レイヤ内の他のピクチャを参照せずに復号され得る、レイヤ内のピクチャのサブセットは、本明細書で「サブレイヤ」、「時間レイヤ」、または「時間サブレイヤ」と呼ばれることがある。したがって、特定の時間レベルを有するピクチャグループをサブレイヤ(すなわち、時間レイヤ)として定義することによって、時間スケーラビリティが1つのレイヤ内で達成され得る。
NALユニットは、時間識別子(たとえば、HEVCにおけるtemporal_id)シンタックス要素を含み得る。NALユニットの時間識別子シンタックス要素は、NALユニットの時間識別子を指定する。NALユニットの時間識別子は、NALユニットが関連する時間サブレイヤを識別する。したがって、ビットストリームのレイヤの各時間サブレイヤは、異なる時間識別子に関連付けられ得る。第1のNALユニットの時間識別子が第2のNALユニットの時間識別子よりも小さい場合、第1のNALユニットによってカプセル化されるデータは、第2のNALユニットによってカプセル化されるデータを参照せずに復号され得る。
図2は、ピクチャの例示的なコーディング依存性を示すブロック図である。図2の例では、CVSはピクチャ50、52、54、56、および58を含む。ピクチャ50、52、54、56、および58の各々は、それぞれのアクセスユニット(AU)内にある。図2の例では、ピクチャ50、52、54、56、および58が同じレイヤにあると仮定している。ピクチャ50および58は、CVS内の任意の他のピクチャに依存しない。ピクチャ54は、ピクチャ50および58に依存する。言い換えれば、最初にピクチャ50および58を復号することなく、ピクチャ54を復号することはできない。たとえば、ピクチャ54内のブロックのモーションパラメータは、ピクチャ50および58内のブロックを識別し得る。ピクチャ52および56は、ピクチャ50、54、および58に依存する。
時間スケーリングでは、ピクチャ50および58を復号するビデオデコーダ30の能力に影響を及ぼすことなく、ピクチャ52、54、および56をビットストリームから除去することができる。したがって、ピクチャ50および58は、第1の時間サブレイヤ(すなわち、時間サブレイヤ0)を形成する。ピクチャ52および56は、ピクチャ54を復号するビデオデコーダ30の能力に影響を与えることなく除去することができるが、ピクチャ54を復号するビデオデコーダ30の能力に影響を及ぼすことなく、ピクチャ50および58をビットストリームから除去することはできない。したがって、ピクチャ54は、第2の時間サブレイヤ(すなわち、時間サブレイヤ1)を形成する。ピクチャ52および56は、ピクチャ50、54、および58に依存し、したがって、第3の時間サブレイヤ(すなわち、時間サブレイヤ2)を形成する。
HEVCで定義されているように、CVSは、復号順序で、NoRaslOutputFlagが1に等しいイントラランダムアクセスポイント(IRAP)アクセスユニット(AU)である任意の後続のアクセスユニットまでの、しかしそれを含まないすべての後続のアクセスユニットを含む、NoRaslOutputFlagが1に等しいイントラランダムアクセスポイント(IRAP)アクセスユニットと、次いでNoRaslOutputFlagが1に等しい非IRAPアクセスユニットである0個以上のアクセスユニットとからなるアクセスユニット(AU)のシーケンスである。IRAPアクセスユニットは、瞬間復号リフレッシュ(IDR)アクセスユニット、切断リンクアクセス(BLA)アクセスユニット、またはクリーンランダムアクセス(CRA)アクセスユニットであってもよい。NoRaslOutputFlagの値は、各IDRアクセスユニット、各BLAアクセスユニット、および各CRAアクセスユニットについて、1に等しく、これは、復号順序でビットストリーム内の第1のアクセスユニットであり、復号順序でシーケンス終了NALユニットに続く第1のアクセスユニットであり、または1に等しいHandleCraAsBlaFlagを有する。
さらに、HEVCにおいて、CRAピクチャは、各VCL NALユニットがCRA_NUTに等しいnal_unit_typeを有するIRAPピクチャである。HEVCでは、CRAピクチャはIスライスのみを含み、復号順序でビットストリーム内で第1のピクチャであってよく、またはビットストリーム内で後に現れてもよい。CRAピクチャは、関連するRADLピクチャおよびRASLピクチャを有し得る。CRAピクチャが1に等しいNoRaslOutputFlagを有するとき、関連するRASLピクチャは、ビットストリームに存在しないピクチャへの参照を含む可能性があるとき、復号可能ではないので、デコーダによって出力されない。クリーンランダムアクセス(CRA)アクセスユニットは、nuh_layer_idが0に等しいコード化ピクチャがCRAピクチャであるアクセスユニットである。
HEVCでは、IRAPピクチャは、各VCL NALユニットがBLA_W_LPからRSV_IRAP_VCL23までの範囲のnal_unit_typeを有するコード化ピクチャである。IRAPピクチャはIスライスのみを含み、BLAピクチャ、CRAピクチャまたはIDRピクチャであってもよい。復号順序においてビットストリーム内の第1のピクチャは、IRAPピクチャでなければならない。必須のパラメータセットが、それらがアクティブにされる必要があるときに利用可能である場合、IRAPピクチャおよび復号順序において後続するすべての非RASLピクチャは、復号順序においてIRAPピクチャに先行するピクチャの復号プロセスを実行することなく、正しく復号され得る。IRAPピクチャでないIスライスのみを含むビットストリーム内に、ピクチャが存在することがある。IRAPアクセスユニットは、nuh_layer_idが0に等しいコード化ピクチャがIRAPピクチャであるアクセスユニットである。
HEVCで定義されるように、切断リンクアクセス(BLA)アクセスユニットは、nuh_layer_idが0に等しいコード化ピクチャがBLAピクチャであるアクセスユニットである。BLAピクチャは、各VCL NALユニットがBLA_W_LP、BLA_W_RADL、またはBLA_N_LPに等しいnal_unit_typeを有するIRAPピクチャである。
次に、ファイルフォーマットとファイルフォーマット標準について簡単に説明する。ファイルフォーマット標準は、ISOベースのメディアファイルフォーマット(ISOBMFF、ISO/IEC14496-12、以下「ISO/IEC14996-12」)と、MPEG-4ファイルフォーマット(ISO/IEC14496-15)、3GPPファイルフォーマット(3GPP TS 26.244)、およびAVCのファイルフォーマットを含むISO/IEC14496-15(ISO/IEC14496-15、以下「ISO/IEC14996-15」)およびその拡張、ならびにHEVCのファイルフォーマットおよびその拡張を含むISOBMFFから派生した他のファイルフォーマット標準とを含む。ISO/IEC14496-12は、ISOベースメディアファイルフォーマットを指定する。他のドキュメントは、特定のアプリケーションのISOベースメディアファイルフォーマットを拡張する。たとえば、ISO/IEC14496-15は、ISOベースメディアファイルフォーマットでのNALユニット構造化ビデオのキャリッジを記述する。H.264/AVCおよびHEVC、ならびにそれらの拡張は、NALユニット構造化ビデオの例である。ISO/IEC14496-15は、H.264/AVC NALユニットのキャリッジを記述するセクションを含む。さらに、ISO/IEC14496-15のセクション8は、HEVC NALユニットのキャリッジを記述する。したがって、ISO/IEC14496-15のセクション8は、HEVCファイルフォーマットを記述すると言われている。第114回MPEG会議の後、いくつかの国の機関から受け取ったコメントに基づいて、ISO/IEC14496-15草案仕様の新版に適用されるISO/IEC14496-15へのいくつかの変更を含む決定文書が作成された。この決定文書は、「MPEG出力文書N15297」と呼ばれる。
ISOBMFFは、AVCファイルフォーマットなど、多くのコーデックカプセル化フォーマット用の、ならびにMPEG-4ファイルフォーマット、3GPPファイルフォーマット(3GP)、およびDVBファイルフォーマットなど、多くのマルチメディアコンテナフォーマット用の基礎として使用される。オーディオやビデオなどの連続的なメディアに加えて、画像などの静的メディア、ならびにメタデータが、ISOBMFFに準拠するファイルに記憶され得る。ISOBMFFに従って構造化されたファイルは、ローカルメディアファイル再生、リモートファイルのプログレッシブダウンロード、動的適応ストリーミングオーバーHTTP(DASH)用のセグメント、ストリームされるべきコンテンツ用のコンテナおよびそのパケット化命令、ならびに受信されたリアルタイムメディアストリームの記録を含む、多くの目的のために使用され得る。したがって、当初は記憶のために設計されたが、ISOBMFFは、ストリーミングのために、たとえば、プログレッシブダウンロードまたはDASHのために、貴重であることが証明されている。ストリーミングの場合、ISOBMFFにおいて定義されるムービーフラグメントが使用され得る。オーディオおよびビデオなどの連続するメディアに加えて、ISOBMFFに準拠するファイルは、画像などの静的メディア、ならびにメタデータも記憶し得る。
HEVCファイルフォーマットに準拠するファイルは、ボックスと呼ばれる一連のオブジェクトを含み得る。ボックスは、一意のタイプの識別子および長さによって定義されたオブジェクト指向のビルディングブロックであってもよい。ボックスは、4文字のコード化ボックスタイプ、ボックスのバイトカウント、およびペイロードを含む、ISOBMFF内の基本シンタックス構造である。言い換えれば、ボックスは、コード化ボックスタイプ、ボックスのバイトカウント、およびペイロードを含むシンタックス構造であり得る。いくつかの事例では、HEVCファイルフォーマットに準拠するファイル内のすべてのデータがボックス内に含まれていてもよく、ボックス内にないファイル内にデータが存在しなくてもよい。したがって、ISOBMFFファイルはボックスのシーケンスからなり、ボックスは他のボックスを含んでよい。たとえば、ボックスのペイロードは、1つまたは複数の追加のボックスを含み得る。図5および図6は、本開示の他の場所で詳細に説明されており、本開示の1つまたは複数の技法に従って、ファイル内の例示的ボックスを示す。
ISOBMFFに準拠するファイルは、様々なタイプのボックスを含み得る。たとえば、ISOBMFFに準拠するファイルは、ファイルタイプボックス、メディアデータボックス、ムービーボックス、ムービーフラグメントボックスなどを含み得る。この例では、ファイルタイプボックスは、ファイルタイプおよび互換性情報を含む。メディアデータボックスは、サンプル(たとえば、コード化ピクチャ)を含み得る。ムービーボックス(「moov」)は、ファイル内に存在する連続するメディアストリームのメタデータを含む。連続するメディアストリームの各々は、ファイルにトラックとして表され得る。たとえば、ムービーボックスは、ムービーに関するメタデータ(たとえば、サンプル間の論理的関係およびタイミング関係、ならびにサンプルの位置へのポインタ)を含み得る。ムービーボックスは、いくつかのタイプのサブボックスを含み得る。ムービーボックス内のサブボックスは、1つまたは複数のトラックボックスを含み得る。トラックボックスは、ムービーの個々のトラックに関する情報を含み得る。トラックボックスは、単一のトラックの全体的な情報を指定するトラックヘッダボックスを含み得る。さらに、トラックボックスは、メディア情報ボックスを含むメディアボックスを含み得る。メディア情報ボックスは、トラック内のメディアサンプルのデータインデックス付けを含むサンプルテーブルボックスを含み得る。サンプルテーブルボックス内の情報は、サンプルを時間的に突き止め、トラックのサンプルの各々について、タイプ、サイズ、コンテナ、およびそのサンプルのそのコンテナへのオフセットを決定するために使用され得る。したがって、トラック用のメタデータは、トラックボックス(「trak」)の中に封入され、トラックのメディアコンテンツは、メディアデータボックス(「mdat」)の中に封入されるか、または別個のファイルの中に直接封入されるかのいずれかである。トラック用のメディアコンテンツは、オーディオアクセスユニットまたはビデオアクセスユニットなどの、サンプルのシーケンスを備え得るか、またはサンプルのシーケンスからなる。
ISOBMFFは、以下のタイプのトラック、すなわち、エレメンタリメディアストリームを含むメディアトラック、メディア送信命令を含むか、または受信パケットストリームを表すかのいずれかであるヒントトラック、および時間同期されたメタデータを備える時限メタデータトラックを指定する。各トラックのメタデータは、サンプル記述エントリのリストを含み、各々、トラックで使用されるコーディングまたはカプセル化フォーマットおよびそのフォーマットを処理するために使用される初期化データを提供する。各サンプルは、トラックのサンプル記述エントリのうちの1つに関連付けられる。
ISOBMFFは、様々なメカニズムを伴うサンプル固有メタデータを指定することを可能にする。サンプルテーブルボックス(「stbl」)内の固有のボックスは共通のニーズに応じるために規格化されている。たとえば、トラックのランダムアクセスサンプルを列挙するために、同期サンプルボックス(「stss」)が使用される。サンプルグルーピング機構は、4文字グルーピングタイプによるサンプルを、ファイルの中でサンプルグループ記述エントリとして指定された同じ属性を共有するサンプルのグループにマッピングすることを可能にする。いくつかのグルーピングタイプがISOBMFFにおいて指定されている。サンプルテーブルボックスは、トラック内のメディアサンプルのすべての時間およびデータインデックス付けを含む、サンプルテーブルを含む。サンプルテーブルボックス内のテーブルを使用して、サンプルを時間的に突き止め、そのタイプ(たとえば、Iフレームかどうか)を決定し、それらのサイズ、コンテナ、およびそのコンテナへのオフセットを決定することができる。
たとえば、同期サンプルボックス(「stss」)は、サンプルテーブルボックス内のボックスである。同期サンプルボックスは、トラックのランダムアクセスサンプルを列挙するために使用される。本開示は、同期サンプルとして同期サンプルボックスによって列挙されたサンプルを参照し得る。別の例では、サンプルグルーピング機構は、4文字グルーピングタイプによるサンプルを、ファイルの中でサンプルグループ記述エントリとして指定された同じ属性を共有するサンプルのグループにマッピングすることを可能にする。いくつかのグルーピングタイプが、ISOBMFFにおいて指定されている。
ISOBMFF仕様は、DASHとともに使用するために6つのタイプのストリームアクセスポイント(SAP:Stream Access Point)を指定する。第1の2つのSAPタイプ(タイプ1および2)は、H.264/AVCおよびHEVCにおけるIDRピクチャに対応する。第3のSAPタイプ(タイプ3)は、オープンGOPランダムアクセスポイント、したがって、HEVCにおけるBLAピクチャまたはCRAピクチャに対応する。第4のSAPタイプ(タイプ4)は、GDRランダムアクセスポイントに対応する。
ムービーフラグメントボックスはトップレベルのボックスである。各ムービーフラグメントボックスは、以前ムービーボックス内にあった情報を提供する。ムービーフラグメントボックスは、1つまたは複数のトラックフラグメント(「traf」)ボックスを含み得る。ムービーフラグメント内には、トラックごとに0個以上のトラックフラグメントのセットがある。トラックフラグメントは次に、0個以上のトラックランを含み、その各々は、そのトラックについてのサンプルの連続するランを記録する。たとえば、各トラックランは、復号順序など、ある順序で連続するピクチャのサンプルを含み得る。トラックフラグメントボックスは、14996-12仕様で定義され、1つまたは複数のトラックフラグメントのメタデータを含む。たとえば、トラックフラグメントボックスは、トラックID、基本データオフセット、サンプル記述インデックス、デフォルトサンプル持続時間、デフォルトサンプルサイズ、およびデフォルトサンプルフラグを示すトラックフラグメントヘッダボックスを含み得る。トラックフラグメントボックスは、1つまたは複数のトラックフラグメントランボックスを含み得、各々、トラックの連続するサンプルのセットを記録する。たとえば、トラックフラグメントボックスは、サンプルカウント、データオフセット、サンプルフラグ、サンプル持続時間、サンプルサイズ、サンプル構成時間オフセットなどを示すシンタックス要素を含み得る。これらの構造内では、多くのフィールドはオプションであり、デフォルト設定にすることができる。
サンプルテーブルボックスは、1つまたは複数のSampleToGroupボックスおよび1つまたは複数のサンプルグループ記述ボックス(すなわち、SampleGroupDescriptionボックス)を含み得る。SampleToGroupボックスを使用して、サンプルが属するサンプルグループを、サンプルグループの関連する記述とともに決定し得る。言い換えれば、SampleToGroupボックスは、サンプルが属するグループを示し得る。SampleToGroupボックスは、「sbgp」のボックスタイプを有し得る。SampleToGroupボックスは、グルーピングタイプ要素(たとえば、grouping_type)を含み得る。いくつかの事例では、本開示では、ボックスの要素はシンタックス要素とも呼ばれ得る。グルーピングタイプ要素は、サンプルグルーピングのタイプ(すなわち、サンプルグループを形成するために使用される基準)を識別する整数であり得る。さらに、SampleToGroupボックスは、1つまたは複数のエントリ(すなわち、サンプルグループエントリ)を含み得る。SampleToGroupボックス内の各サンプルグループエントリは、トラック内の連続的なサンプルの異なる重複しないシリーズと関連付けられ得る。各サンプルグループエントリは、サンプルカウント要素(たとえば、sample_count)およびグループ記述インデックス要素(たとえば、group_description_index)を示し得る。サンプルグループエントリのサンプルカウント要素は、サンプルグループエントリに関連付けられたサンプルの数を示し得る。言い換えれば、サンプルグループエントリのサンプルカウント要素は、同じサンプルグループ記述子を有する連続するサンプルの数を与える整数であり得る。グループ記述インデックス要素は、SampleGroupDescriptionボックス内の、サンプルグループエントリに関連付けられたサンプルの記述を含むグループ記述エントリを識別し得る。複数のサンプルグループエントリのグループ記述インデックス要素は、同じSampleGroupDescriptionボックスを識別し得る。
ISO/IEC23008-2(すなわち、HEVCの仕様およびそのマルチレイヤ拡張)では、EOB NALユニットがアクセスユニット(AU)内に存在するとき、そのユニットは、AU内の最後のNALユニットであり、EOS NALユニットがAU内に存在するとき、存在する場合はそのEOS NALユニットを除くAU内のすべてのNALユニットに先行すると制限される。
ISO/IEC14496-15の第8節および第9節において指定されているHEVCのファイルフォーマットおよびその拡張では、第9節のいわゆるレイヤードHEVC(L-HEVC)ファイルフォーマットは、HEVCのマルチレイヤ拡張のビデオビットストリームの記憶を指定する。L-HEVCファイルフォーマットによれば、HEVCまたはL-HEVCビットストリームの時間サブレイヤ(単にサブレイヤとも呼ばれる)は、2つ以上のトラックに記憶されてもよい。
しかしながら、HEVCまたはL-HEVCビットストリームのサブレイヤを記憶する現在の設計は、1つまたは複数の問題を有する。たとえば、HEVCまたはL-HEVCビットストリームのCVS内にあり、複数のトラックに記憶された異なるサブレイヤに属するAUについて、EOB NALユニットが、最も高いTemporalIdを有するピクチャを含む1つまたは複数のAUに含まれることのみが可能とされている場合、そのトラックが使用されていないとき、EOB NALユニットが失われる可能性がある。これは、再構成されたビットストリーム内の次のAUがクリーンランダムアクセス(CRA)ピクチャを含む場合、問題となり得、ビットストリーム内のCRAピクチャの直前のEOB NALユニットの存在が、そのようなEOB NALユニットが存在しないときとは異なる、そのCRAピクチャについての異なる復号プロセスを必要とし、その結果、間違った復号結果が生じ、ユーザエクスペリエンスを混乱させる可能性がある。
一方、HEVCまたはL-HEVCビットストリームの同じCVS内にあり、複数のトラックに記憶された異なるサブレイヤに属するAUについて、EOB NALユニットが、最も低いTemporalIdおよび/または最も高いTemporalIdよりも小さい他のTemporalIdの1つもしくは複数を有するピクチャを含む1つまたは複数のAUに含まれることのみが可能とされている場合、ビットストリーム再構築プロセスにおいて、EOB NALユニットが再構築されたビットストリーム内のCVSの最後のAUの終わりに配置されることを確実にするために、並べ替えプロセスが常に必要とされ、さもなければ、再構築されたビットストリームは準拠していない。さらに、この場合、ベースレイヤがHEVC(たとえば、AVC)以外のコーデックによってコーディングされている場合、EOB NALユニットが破棄される必要があり、新しいEOB NALユニット(すなわち、HEVC EOB NALユニット)が生成される必要があり得る。上記と同様の問題がEOS NALユニットに適用されることがある。
上述の問題に対処するために、以下で説明する技法が提案される。態様のうちのいくつかは独立して適用されてもよく、技法のうちのいくつかは組み合わせて適用されてもよい。これらの技法は、HEVCおよびレイヤードHEVCの文脈で説明されているが、AVCおよびそのレイヤード拡張など、時間スケーラビリティサポートを有する他のコーデックに適用され得る。
本開示の第1の例示的な技法によれば、HEVCまたはL-HEVCビットストリームの同じCVS内にあり、複数のトラックに記憶された異なるサブレイヤに属するAUについて、EOS NALユニットは、そのようなトラック内の同じCVS内にある最後のAUの一部として、2つ以上のトラック内(たとえば、トラックの各々)に存在することが可能となる。本開示の第2の例示的な技法によれば、HEVCまたはL-HEVCビットストリームの同じCVS内にあり、複数のトラックに記憶された異なるサブレイヤに属するAUについて、トラックのうちの2つ以上がそれぞれのサンプル内にEOS NALユニットを含むとき、EOS NALユニットのうちの1つのみが、最後の再構築ビットストリームにおけるこれらのアクセスユニットの最後(復号時間が最も長いもの)に保持され、これらのアクセスユニットの最後の、そのEOB NALユニット(存在する場合)を除く、すべてのNALユニットの後に配置されるものとし、他のEOS NALユニットは破棄される。
たとえば、ファイルは、第1のトラックおよび第2のトラックを含み得る。この例では、第1のトラックは、ビットストリームのレイヤの第1の時間サブレイヤを含み、第2のトラックは、ビットストリームの同じレイヤの第2の時間サブレイヤを含み得る。さらに、この例では、第1のトラックは、第1のEOS NALユニットを含み、第2のトラックは、第2のEOS NALユニットを含み得る。この例では、本開示の第2の例示的な技法に従って、デバイス(たとえば、ファイルパーシングユニット31)が、ファイルから、第1および第2の時間サブレイヤを含むビットストリームを抽出するとき、デバイスは、第1のEOS NALユニットまたは第2のEOS NALユニットのうちのどちらか後のアクセスユニット内にある方をビットストリームに含めることができ、他方のEOS NALユニットを破棄し得る。しかしながら、デバイスがファイルから第1または第2の時間サブレイヤのうちの1つのみを含むビットストリームを抽出する事例では、デバイスは、(含まれる時間サブレイヤの任意のEOS NALユニットを含む)含まれる時間サブレイヤの各NALユニットを含み得、(他の時間サブレイヤの任意のEOS NALユニットを含む)他方の時間サブレイヤのNALユニットのいずれも含まない。
したがって、いくつかの例では、ファイル生成デバイス34またはソースデバイス12などのデバイスは、ビデオコンテンツの記憶のためのファイルの第1のトラックに、(たとえば、HEVCビットストリームなど)ビットストリームのCVSについての第1のEOS NALユニットを含み得る。この例では、第1のEOS NALユニットは、CVSの第1のアクセスユニットにある。さらに、この例では、デバイスは、ファイルの第2のトラックに、CVSについての第2のEOS NALユニットを含み得る。この例では、第2のEOS NALユニットは、CVSの第2のアクセスユニットにある。この例では、第2のEOS NALユニットは、第1のEOS NALユニットとは異なる。第1のアクセスユニットおよび第2のアクセスユニットは、異なる時間サブレイヤに属してもよい。この例のいくつかの事例では、第1のトラックは、CVSについてのビットストリームのアクセスユニットの第1のセットを含み、第1のアクセスユニットは、アクセスユニットの第1のセットの順序で最後のアクセスユニットである。さらに、この例のいくつかの事例では、第2のトラックは、CVSについてのビットストリームのアクセスユニットの第2のセットを含み、第2のアクセスユニットは、アクセスユニットの第2のセットの順序で最後のアクセスユニットである。
別の例では、宛先デバイス14などのデバイス(たとえば、宛先デバイス14のファイルパーシングユニット31など)は、第1のトラックおよび第2のトラックを含むファイルを受信し得る。この例では、第1のトラックは、ビットストリーム(たとえば、HEVCビットストリーム)のCVSの第1のアクセスユニットを含む。第2のトラックは、CVSの第2のアクセスユニットを含む。この例では、第1のアクセスユニットは、第1のEOS NALユニットを含み、第2のアクセスユニットは、第2のEOS NALユニットを含む。第1のアクセスユニットおよび第2のアクセスユニットは、異なる時間サブレイヤに属する。ファイルは、第1および第2のトラックに加えてトラックを含み得、ビットストリームは、追加のレイヤおよび時間サブレイヤを含み得る。この例では、デバイスは、第1のEOS NALユニットに関連する時間と第2のEOS NALユニットに関連する時間との比較に基づいて、第1のEOS NALユニットを出力し、第2のEOS NALユニットを破棄し得る。したがって、ファイルから再構築されたビットストリームは、第1のEOS NALユニットを含み得るが、第2のEOS NALユニットを含まないことがある。いくつかの例では、デバイスは、第1のアクセスユニットに関連する復号時間と、第2のアクセスユニットに関連する復号時間とを比較する。デバイスは、第1のEOS NALユニットおよび第2のEOS NALユニットのうちのどちらか後の復号時間に関連するアクセスユニット内にある方を保持し、他方のEOS NALユニットを破棄し得る。たとえば、第1のアクセスユニットが第2のアクセスユニットよりも後の復号時間に関連付けられていることに基づいて、デバイスは、第1のEOS NALユニットを保持し、第2のEOS NALユニットを破棄し得る。したがって、この例では、最後の再構築ビットストリームは、存在する場合はEOB NALユニットを除いて、CVSの順序で最後のアクセスユニットのすべてのNALユニットの後の位置に第1のEOS NALユニットを含み得る。
この例のいくつかの事例では、第1のトラックは、CVSについてのビットストリームのアクセスユニットの第1のセットを含み、第1のアクセスユニットは、アクセスユニットの第1のセットの順序で最後のアクセスユニットである。さらに、そのような事例では、第2のトラックは、CVSについてのビットストリームのアクセスユニットの第2のセットを含み、第2のアクセスユニットは、アクセスユニットの第2のセットの順序で最後のアクセスユニットである。この例のいくつかの事例では、デバイス(たとえば、ファイルパーシングユニット31)は、第1のトラック内のCVSのNALユニットをビデオデコーダ30に出力し得る。さらに、デバイス(たとえば、ファイルパーシングユニット31)は、第2トラック内のCVSのNALユニットをビデオデコーダ30に出力し得る。ビデオデコーダ30は、第1または第2のトラックのうちの少なくとも1つにおけるCVSのNALユニットに基づいて、CVSのピクチャを復号し得る。
いくつかの例では、デバイスは、第1のアクセスユニットが第1のEOS NALユニットを含むことに基づいて、第1のトラックに記憶されたCVSの後続のNALユニットが存在しないことを決定し得る。この例では、デバイスは、第2のアクセスユニットが第2のEOS NALユニットを含むことに基づいて、第2のトラックに記憶されたCVSの後続のNALユニットが存在しないことを決定し得る。
本開示の第3の例示的な技法によれば、HEVCまたはL-HEVCビットストリームの同じCVS内にあり、複数のトラックに記憶された異なるサブレイヤに属するAUについて、EOB NALユニットは、そのようなトラック内の同じCVS内にある最後のAUの一部として、2つ以上のトラック内(たとえば、トラックの各々)に存在することが可能となる。たとえば、ファイルは、第1のトラックおよび第2のトラックを含み得る。この例では、第1のトラックは、ビットストリームのレイヤの第1の時間サブレイヤを含み、第2のトラックは、ビットストリームの同じレイヤの第2の時間サブレイヤを含み得る。さらに、この例では、本開示の第3の例示的な技法に従って、第1のトラックは、第1のEOB NALユニットを含み、第2のトラックは、第2のEOB NALユニットを含み得る。
本開示の第4の例示的な技法によれば、HEVCまたはL-HEVCビットストリームの同じCVS内にあり、複数のトラックに記憶された異なるサブレイヤに属するAUについて、トラックのうちの2つ以上がそれぞれのサンプル内にEOB NALユニットを含むとき、EOB NALユニットのうちの1つのみが、最後の再構築ビットストリームに保持され、これらのアクセスユニットの最後の終わりに配置されるものとし、他のEOB NALユニットは破棄される。たとえば、ファイルは、第1のトラックおよび第2のトラックを含み得る。この例では、第1のトラックは、ビットストリームのレイヤの第1の時間サブレイヤを含み、第2のトラックは、ビットストリームの同じレイヤの第2の時間サブレイヤを含み得る。ファイルは、第1および第2のトラックに加えてトラックを含み得、ビットストリームは、追加のレイヤおよび時間サブレイヤを含み得る。さらに、この例では、第1のトラックは、第1のEOB NALユニットを含み、第2のトラックは、第2のEOB NALユニットを含み得る。この例では、本開示の第4の例示的な技法に従って、デバイス(たとえば、ファイルパーシングユニット31)が、ファイルから、第1および第2の時間サブレイヤを含むビットストリームを抽出するとき、デバイスは、第1のEOB NALユニットまたは第2のEOB NALユニットのうちのどちらか後のアクセスユニット内にある方をビットストリームに含めることができ、他方のEOB NALユニットを破棄し得る。しかしながら、デバイスがファイルから第1または第2の時間サブレイヤのうちの1つのみを含むビットストリームを抽出する事例では、デバイスは、(含まれる時間サブレイヤの任意のEOB NALユニットを含む)含まれる時間サブレイヤの各NALユニットを含み得、(他の時間サブレイヤの任意のEOB NALユニットを含む)他の時間サブレイヤのNALユニットのいずれも含まない。
一例では、ファイル生成デバイス34またはソースデバイス12などのデバイスは、ビデオコンテンツの記憶のためのファイルの第1のトラックに、(たとえば、HEVCビットストリームなど)ビットストリームのCVSについての第1のEOB NALユニットを含み得る。この例では、第1のEOB NALユニットは、CVSの第1のアクセスユニットにある。さらに、この例では、デバイスは、ファイルの第2のトラックに、CVSについての第2のEOB NALユニットを含み得る。この例では、第2のEOB NALユニットは、CVSの第2のアクセスユニットにある。この例では、第2のEOB NALユニットは、第1のEOB NALユニットとは異なる。この例では、第1のアクセスユニットおよび第2のアクセスユニットは、異なる時間サブレイヤに属する。この例のいくつかの事例では、第1のトラックは、ビットストリームのアクセスユニットの第1のセットを含み、第1のアクセスユニットは、アクセスユニットの第1のセットの順序で最後のアクセスユニットであり、第2のトラックは、ビットストリームのアクセスユニットの第2のセットを含み、第2のアクセスユニットは、アクセスユニットの第2のセットの順序で最後のアクセスユニットである。
別の例では、宛先デバイス14などのデバイス(たとえば、宛先デバイス14のファイルパーシングユニット31など)は、第1のトラックおよび第2のトラックを含むファイルを受信する。この例では、第1のトラックは、ビットストリーム(たとえば、HEVCビットストリーム)のCVSの第1のアクセスユニットを含む。第2のトラックは、CVSの第2のアクセスユニットを含む。この例では、第1のアクセスユニットは、第1のEOB NALユニットを含み、第2のアクセスユニットは、第2のEOB NALユニットを含み、第1のアクセスユニットおよび第2のアクセスユニットは、異なる時間サブレイヤに属し、デバイスは、第1のEOB NALユニットを出力し、第2のEOB NALユニットを破棄する。デバイスは、CVSの最後のアクセスユニットのすべてのNALユニットの後の位置に第1のEOB NALユニットを含み得る。いくつかの例では、デバイスは、第1のアクセスユニットに関連する復号時間と、第2のアクセスユニットに関連する復号時間とを比較し得る。そのような例では、デバイスは、第1のEOB NALユニットおよび第2のEOB NALユニットのうちのどちらか後の復号時間に関連するアクセスユニット内にある方を保持し、他方のEOB NALユニットを破棄し得る。たとえば、第1のアクセスユニットが第2のアクセスユニットよりも後の復号時間に関連付けられていることに基づいて、デバイスは、第1のEOB NALユニットを保持し、第2のEOB NALユニットを破棄し得る。
この例のいくつかの事例では、デバイス(たとえば、ファイルパーシングユニット31)は、第1のトラック内のCVSのNALユニットをビデオデコーダ30に出力し得る。さらに、デバイス(たとえば、ファイルパーシングユニット31)は、第2のトラック内のCVSのNALユニットをビデオデコーダ30に出力し得る。ビデオデコーダ30は、第1または第2のトラックのうちの少なくとも1つにおけるCVSのNALユニットに基づいて、CVSのピクチャを復号し得る。
図3は、本開示において記載される技法を実施することができる例示的なビデオエンコーダ20を示すブロック図である。ビデオエンコーダ20は、本開示で説明したファイルフォーマット技法を使用して記憶され得るビデオデータを生成するように構成されたビデオコーダの一例を表す。ビデオエンコーダ20は、シングルビュー、マルチビュー、スケーラブル、3D、および他のタイプのビデオデータを出力するように構成され得る。ビデオエンコーダ20は、ビデオを後処理エンティティ127に出力するように構成されてよい。後処理エンティティ127は、MANE、またはビデオエンコーダ20からの符号化ビデオデータを処理してよいスプライシング/エディティングデバイスなど、ビデオエンティティの一例を表すように意図されている。いくつかの事例では、後処理エンティティ127は、ネットワークエンティティの一例であってよい。いくつかのビデオ符号化システムでは、後処理エンティティ127およびビデオエンコーダ20は、別々のデバイスの部分であってよいが、他の事例では、後処理エンティティ127に関して説明される機能は、ビデオエンコーダ20を備える同じデバイスによって実行されてもよい。後処理エンティティ127は、ビデオデバイスであってもよい。いくつかの例では、後処理エンティティ127は、図1のファイル生成デバイス34と同じであってもよい。
処理回路はビデオエンコーダ20を含み、ビデオエンコーダ20は、本開示において説明される例示的な技法のうちの1つまたは複数を実行するように構成される。たとえば、ビデオエンコーダ20は集積回路を含み、図3に示される様々なユニットは、回路バスと相互接続されるハードウェア回路ブロックとして形成され得る。これらのハードウェア回路ブロックは別個の回路ブロックであってよく、またはユニットのうちの2つ以上が共通のハードウェア回路ブロックへと組み合わされてよい。ハードウェア回路ブロックは、算術論理演算装置(ALU)、初等関数演算装置(EFU)、ならびに、AND、OR、NAND、NOR、XOR、XNOR、および他の同様の論理ブロックなどの論理ブロックなどの、演算ブロックを形成する電気的構成要素の組合せとして形成され得る。
いくつかの例では、図3に示されるユニットのうちの1つまたは複数は、処理回路上で実行されるソフトウェアユニットであり得る。そのような例では、これらのソフトウェアユニットのためのオブジェクトコードがメモリに記憶される。オペレーティングシステムは、ビデオエンコーダ20に、オブジェクトコードを取り出させ、オブジェクトコードを実行させることができ、オブジェクトコードは、ビデオエンコーダ20に、例示的な技法を実施するための動作を実行させる。いくつかの例では、ソフトウェアユニットは、ビデオエンコーダ20が起動時に実行するファームウェアであり得る。したがって、ビデオエンコーダ20は、例示的な技法を実行するハードウェアを有する構造的構成要素であり、または、ハードウェアを例示的な技法の実行専用にするためのハードウェア上で実行されるソフトウェア/ファームウェアを有する。
ビデオエンコーダ20は、ビデオスライス内のビデオブロックのイントラコーディングおよびインターコーディングを実施することができる。イントラコーディングは、所与のビデオフレームまたはピクチャ内のビデオの空間冗長性を低減または除去するために空間予測に依拠する。インターコーディングは、ビデオシーケンスの隣接するフレームまたはピクチャ内のビデオにおける時間冗長性を低減または除去するために時間予測に依存する。イントラモード(Iモード)は、いくつかの空間ベースの圧縮モードのうちのいずれかを指す場合がある。単方向予測(Pモード)または双方向予測(Bモード)などのインターモードは、いくつかの時間ベースの圧縮モードのうちのいずれかを指し得る。
図3の例では、ビデオエンコーダ20は、区分ユニット135と、予測処理ユニット141と、フィルタユニット163と、参照ピクチャメモリ164と、加算器150と、変換処理ユニット152と、量子化ユニット154と、エントロピー符号化ユニット156とを含む。予測処理ユニット141は、動き推定ユニット142と、動き補償ユニット144と、イントラ予測処理ユニット146とを含む。ビデオブロック再構築の場合、ビデオエンコーダ20はまた、逆量子化ユニット158と、逆変換処理ユニット160と、加算器162とを含む。フィルタユニット163は、デブロッキングフィルタ、適応ループフィルタ(ALF)、およびサンプル適応オフセット(SAO)フィルタなどの、1つまたは複数のループフィルタを表すことを意図している。フィルタユニット163がループ内フィルタであるものとして図3に示されるが、他の構成では、フィルタユニット163はループ後フィルタとして実装されてよい。
ビデオエンコーダ20のビデオデータメモリ165は、ビデオエンコーダ20の構成要素によって符号化されるべきビデオデータを記憶することができる。ビデオデータメモリ165の中に記憶されるビデオデータは、たとえば、ビデオソース18から取得され得る。参照ピクチャメモリ164は、たとえば、イントラコーディングモードまたはインターコーディングモードにおいて、ビデオエンコーダ20によってビデオデータを符号化する際に使用するための参照ビデオデータを記憶する参照ピクチャメモリであってもよい。ビデオデータメモリ165および参照ピクチャメモリ164は、同期DRAM(SDRAM)、磁気抵抗RAM(MRAM)、抵抗RAM(RRAM(登録商標))、または他のタイプのメモリデバイスを含む、ダイナミックランダムアクセスメモリ(DRAM)などの、様々なメモリデバイスのいずれかによって形成され得る。ビデオデータメモリ165および参照ピクチャメモリ164は、同じメモリデバイスまたは別個のメモリデバイスによって与えられ得る。様々な例では、ビデオデータメモリ165は、ビデオエンコーダ20の他の構成要素とともにオンチップであってよく、またはそれらの構成要素に対してオフチップであってもよい。
図3に示されたように、ビデオエンコーダ20は、ビデオデータを受信し、区分ユニット135は、ビデオブロックにデータを区分する。この区分はまた、スライス、またはもっと大きい他の単位への区分、ならびに、たとえば、LCUおよびCUの4分木構造によるビデオブロック区分を含んでもよい。ビデオエンコーダ20は、概して、符号化されるべきビデオスライス内のビデオブロックを符号化する構成要素を示す。スライスは、複数のビデオブロックに分割され得る。予測処理ユニット141は、エラー結果(たとえば、コーディングレートおよびひずみのレベル)に基づいて、現在ビデオブロックのために、複数のイントラコーディングモードのうちの1つまたは複数のインターコーディングモードのうちの1つなどの、複数の可能なコーディングモードのうちの1つを選択することができる。予測処理ユニット141は、残差ブロックデータを生成するために加算器150に、および、参照ピクチャとして使用するための符号化されたブロックを再構築するために加算器162に、得られたイントラコーディングまたはインターコーディングされたブロックを提供し得る。
予測処理ユニット141内のイントラ予測処理ユニット146は、空間圧縮を実現するために、コーディングされるべき現在ブロックと同じフレームまたはスライス内の1つまたは複数の隣接ブロックに対する現在ビデオブロックのイントラ予測コーディングを実施することができる。予測処理ユニット141内の動き推定ユニット142および動き補償ユニット144は、時間的圧縮を提供するために、1つまたは複数の参照ピクチャ内の1つまたは複数の予測ブロックに対する現在のビデオブロックのインター予測コーディングを実行する。
動き推定ユニット142は、ビデオシーケンス用の所定のパターンに従って、ビデオスライス用のインター予測モードを決定するように構成される場合がある。所定のパターンは、シーケンスの中のビデオスライスを、Pスライス、Bスライス、またはGPBスライスとして指定し得る。動き推定ユニット142および動き補償ユニット144は高度に集積され得るが、概念的な目的のために別々に図示される。動き推定ユニット142によって実行される動き推定は、ビデオブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、参照ピクチャ内の予測ブロックに対する現在のビデオフレームまたはピクチャ内のビデオブロックのPUの変位を示し得る。
予測ブロックは、絶対差分和(SAD)、2乗差分和(SSD)、または他の差分メトリックによって決定され得るピクセル差分に関して、コーディングされるべきビデオブロックのPUと厳密に一致することが判明したブロックである。いくつかの例では、ビデオエンコーダ20は、参照ピクチャメモリ164に記憶された参照ピクチャのサブ整数ピクセル位置の値を計算し得る。たとえば、ビデオエンコーダ20は、参照ピクチャの1/4ピクセル位置、1/8ピクセル位置、または他の分数のピクセル位置の値を補間し得る。したがって、動き推定ユニット142は、フルピクセル位置および分数ピクセル位置に対して動き探索を実行し、分数ピクセル精度で動きベクトルを出力し得る。
動き推定ユニット142は、PUの位置を参照ピクチャの予測ブロックの位置と比較することによって、インターコーディングされたスライス中のビデオブロックのPUの動きベクトルを計算する。参照ピクチャは、第1の参照ピクチャリスト(リスト0)または第2の参照ピクチャリスト(リスト1)から選択されることがあり、それらの各々が、参照ピクチャメモリ164に記憶された1つまたは複数の参照ピクチャを特定する。動き推定ユニット142は、計算された動きベクトルを決定することができるシンタックス要素をエントロピー符号化ユニット156および動き補償ユニット144に送る。
動き補償ユニット144によって実行される動き補償は、場合によっては、サブピクセル精度への補間を実行する動き推定によって決定される動きベクトルに基づいて、予測ブロックをフェッチまたは生成することを伴い得る。現在ビデオブロックのPUに対する動きベクトルを受信すると、動き補償ユニット144は、参照ピクチャリストのうちの1つの中で動きベクトルが指す予測ブロックの位置を特定し得る。ビデオエンコーダ20は、コーディングされている現在ビデオブロックのピクセル値から予測ブロックのピクセル値を減算し、ピクセル差分値を形成することによって、残差ビデオブロックを形成し得る。ピクセル差分値は、ブロックに対する残差データを形成し、ルーマ差分成分とクロマ差分成分の両方を含む場合がある。加算器150は、この減算演算を実施する1つまたは複数の構成要素を表す。動き補償ユニット144は、ビデオスライスのビデオブロックを復号する際にビデオデコーダ30によって使用するための、ビデオブロックおよびビデオスライスに関連付けられたシンタックス要素を生成することもできる。
イントラ予測処理ユニット146は、上記で説明したように、動き推定ユニット142および動き補償ユニット144によって実行されるインター予測の代替として、現在ブロックをイントラ予測し得る。具体的には、イントラ予測処理ユニット146は、現在ブロックを符号化するために使用するイントラ予測モードを決定することができる。いくつかの例では、イントラ予測処理ユニット146は、たとえば、別個の符号化パスの間、様々なイントラ予測モードを使用して現在のブロックを符号化してよく、イントラ予測処理ユニット146は、試験されたモードから、使用するための適切なイントラ予測モードを選択することができる。たとえば、イントラ予測処理ユニット146は、様々なテストされたイントラ予測モードに対してレートひずみ分析を使用してレートひずみ値を計算し、テストされたモードの中から最良のレートひずみ特性を有するイントラ予測モードを選択することができる。レートひずみ分析は、一般に、符号化されたブロックと、符号化されたブロックを生成するために符号化された、元の符号化されていないブロックとの間のひずみ(または誤差)の量、ならびに符号化されたブロックを生成するために使用されるビットレート(すなわち、ビット数)を決定する。イントラ予測処理ユニット146は、どのイントラ予測モードがブロックのための最良のレートひずみ値を表すかを判定するために、様々な符号化されたブロックに関するひずみおよびレートから比を計算することができる。
いずれの場合も、ブロック用のイントラ予測モードを選択した後、イントラ予測処理ユニット146は、エントロピー符号化ユニット156にブロック用の選択されたイントラ予測モードを示す情報を提供することができる。エントロピー符号化ユニット156は、本開示の技法に従って選択されたイントラ予測モードを示す情報を符号化することができる。ビデオエンコーダ20は、(コードワードマッピングテーブルとも呼ばれる)複数のイントラ予測モードインデックステーブルおよび複数の修正されたイントラ予測モードインデックステーブルを含む場合がある送信されたビットストリーム構成データの中に、コンテキストの各々のために使用する、様々なブロックのための符号化コンテキストの定義と、最も可能性の高いイントラ予測モードの指示と、イントラ予測モードインデックステーブルと、修正されたイントラ予測モードインデックステーブルとを含める場合がある。
予測処理ユニット141が、インター予測またはイントラ予測のいずれかによって現在のビデオブロックのための予測ブロックを生成した後、ビデオエンコーダ20は、現在のビデオブロックから予測ブロックを減算することによって、残差ビデオブロックを形成し得る。残差ブロック内の残差ビデオデータは、1つまたは複数のTUに含められ、変換処理ユニット152に適用される場合がある。変換処理ユニット152は、離散コサイン変換(DCT)または概念的に同様の変換などの変換を使用して、残差ビデオデータを残差変換係数に変換する。変換処理ユニット152は、残差ビデオデータをピクセル領域から周波数領域などの変換領域に変換することができる。
変換処理ユニット152は、得られた変換係数を量子化ユニット154に送ることができる。量子化ユニット154は、ビットレートをさらに低減するために変換係数を量子化する。量子化プロセスは、係数の一部またはすべてに関連付けられたビット深度を低減することができる。量子化の程度は、量子化パラメータを調整することによって変更され得る。いくつかの例では、量子化ユニット154は次いで、量子化変換係数を含む行列の走査を実行し得る。代替として、エントロピー符号化ユニット156が走査を実施する場合がある。
量子化に続いて、エントロピー符号化ユニット156は、量子化された変換係数を表すシンタックス要素をエントロピー符号化し得る。たとえば、エントロピー符号化ユニット156は、コンテキスト適応型可変長コーディング(CAVLC)、コンテキスト適応型バイナリ算術コーディング(CABAC)、シンタックスベースコンテキスト適応型バイナリ算術コーディング(SBAC)、確率間隔区分化エントロピー(PIPE)コーディング、または別のエントロピー符号化の方法もしくは技法を実施することができる。エントロピー符号化ユニット156によるエントロピー符号化に続いて、符号化ビットストリームは、ビデオデコーダ30に送信されるか、または後の送信もしくはビデオデコーダ30による取出しのためにアーカイブされる場合がある。エントロピー符号化ユニット156は、コーディングされている現在ビデオスライスの動きベクトルおよび他のシンタックス要素をエントロピー符号化することもできる。
逆量子化ユニット158および逆変換処理ユニット160は、参照ピクチャの参照ブロックとして後で使用するための、ピクセル領域における残差ブロックを再構築するために、それぞれ、逆量子化および逆変換を適用する。動き補償ユニット144は、参照ピクチャリストのうちの1つの中の参照ピクチャのうちの1つの予測ブロックに残差ブロックを加算することによって、参照ブロックを計算し得る。動き補償ユニット144はまた、動き推定において使用するためのサブ整数ピクセル値を計算するために、再構築された残差ブロックに1つまたは複数の補間フィルタを適用し得る。加算器162は、参照ピクチャメモリ164に記憶するための参照ブロックを生成するために、動き補償ユニット144によって生成された動き補償された予測ブロックに再構築残差ブロックを加算し得る。参照ブロックは、後続のビデオフレームまたはピクチャの中のブロックをインター予測するための参照ブロックとして、動き推定ユニット142および動き補償ユニット144によって使用され得る。
本開示の技法に従って、後処理エンティティ127は、ビデオエンコーダ20によって生成された符号化されたビデオコンテンツを記憶するためのファイルを生成し得る。後処理エンティティ127は、本開示の技法のいずれかに従ってファイルを生成し得る。たとえば、後処理エンティティ127は、ファイルの第1のトラックに、ビットストリームのCVSについての第1のEOS NALユニットを含め、ファイルの第2のトラックに、CVSについての第2のEOS NALユニットを含め得る。いくつかの例では、後処理エンティティ127は、ファイルの第1のトラックに、ビットストリームのCVSについての第1のEOB NALユニットを含め、ファイルの第2のトラックに、ビットストリームのCVSについての第2のEOB NALユニットを含め得る。
図4は、本開示において記載される技法を実施することができる例示的なビデオデコーダ30を示すブロック図である。図4のビデオデコーダ30は、本開示で説明したファイルフォーマット技法を使用して記憶され得るビデオデータを復号するように構成されたビデオデコーダの一例を表す。
処理回路はビデオデコーダ30を含み、ビデオデコーダ30は、本開示において説明される例示的な技法のうちの1つまたは複数を実行するように構成される。たとえば、ビデオデコーダ30は集積回路を含み、図4に示される様々なユニットは、回路バスと相互接続されるハードウェア回路ブロックとして形成され得る。これらのハードウェア回路ブロックは別個の回路ブロックであってよく、またはユニットのうちの2つ以上が共通のハードウェア回路ブロックへと組み合わされてよい。ハードウェア回路ブロックは、算術論理演算装置(ALU)、初等関数演算装置(EFU)、ならびに、AND、OR、NAND、NOR、XOR、XNOR、および他の同様の論理ブロックなどの論理ブロックなどの、演算ブロックを形成する電気的構成要素の組合せとして形成され得る。
いくつかの例では、図4に示されるユニットのうちの1つまたは複数は、処理回路上で実行されるソフトウェアユニットであり得る。そのような例では、これらのソフトウェアユニットのためのオブジェクトコードがメモリに記憶される。オペレーティングシステムは、ビデオデコーダ30に、オブジェクトコードを取り出させ、オブジェクトコードを実行させることができ、オブジェクトコードは、ビデオデコーダ30に、例示的な技法を実施するための動作を実行させる。いくつかの例では、ソフトウェアユニットは、ビデオデコーダ30が起動時に実行するファームウェアであり得る。したがって、ビデオデコーダ30は、例示的な技法を実行するハードウェアを有する構造的構成要素であり、または、ハードウェアを例示的な技法の実行専用にするためのハードウェア上で実行されるソフトウェア/ファームウェアを有する。
ビデオデコーダ30は、シングルビュー、マルチビュー、スケーラブル、3D、および他のタイプのビデオデータを復号するように構成され得る。図4の例では、ビデオデコーダ30は、エントロピー復号ユニット180、予測処理ユニット181、逆量子化ユニット186、逆変換処理ユニット188、加算器190、フィルタユニット191、および参照ピクチャメモリ192を含む。予測処理ユニット181は、動き補償ユニット182およびイントラ予測処理ユニット184を含む。ビデオデコーダ30は、いくつかの例では、図3からのビデオエンコーダ20に関して記載された符号化パスとは全体的に逆の復号パスを実施することができる。
コード化ピクチャバッファ(CPB)179は、ビットストリームの符号化ビデオデータ(たとえば、NALユニット)を受信し、記憶することができる。CPB179に記憶されたビデオデータは、たとえば、図1のリンク16から、たとえば、カメラなどのローカルビデオソースから、ビデオデータの有線もしくはワイヤレスネットワーク通信を介して、または物理データ記憶媒体にアクセスすることによって取得され得る。CPB179は、符号化されたビデオビットストリームからの符号化ビデオデータを記憶するビデオデータメモリを形成し得る。参照ピクチャメモリ192は、たとえば、イントラコーディングモードまたはインターコーディングモードにおいて、ビデオデコーダ30によってビデオデータを復号する際に使用するための参照ビデオデータを記憶する参照ピクチャメモリであってもよい。CPB179および参照ピクチャメモリ192は、シンクロナスDRAM(SDRAM)を含むダイナミックランダムアクセスメモリ(DRAM)、磁気抵抗RAM(MRAM)、抵抗RAM(RRAM(登録商標))、または他のタイプのメモリデバイスなどの、様々なメモリデバイスのいずれかによって形成され得る。CPB179および参照ピクチャメモリ192は、同じメモリデバイスまたは別個のメモリデバイスによって備えられてよい。様々な例では、CPB179は、ビデオデコーダ30の他のコンポーネントとともにオンチップであってよく、またはそれらのコンポーネントに対してオフチップであってよい。
復号プロセスの間に、ビデオデコーダ30は、ビデオエンコーダ20から、符号化ビデオスライスのビデオブロックおよび関連するシンタックス要素を表す符号化ビデオビットストリームを受信する。図4の例では、ビデオデコーダ30は、ファイルを構文解析してコード化ビデオビットストリームを抽出するファイルパーシングユニット177から符号化ビデオビットストリームを受信し得る。いくつかの例では、ファイルパーシングユニット177は、ファイルをネットワークエンティティ129から受信し得る。たとえば、ネットワークエンティティ129は、上記で説明した技法のうちの1つまたは複数を実装するように構成されたサーバ、MANE、ビデオエディタ/スライサ、または他のそのようなデバイスであってよい。ネットワークエンティティ129は、ビデオエンコーダ20のようなビデオエンコーダを含んでもよく、含まなくてもよい。本開示で説明する技法のうちのいくつかは、ネットワークエンティティ129が符号化ビデオビットストリームをビデオデコーダ30に送信する前に、ネットワークエンティティ129によって実装されてもよい。いくつかのビデオ復号システムでは、ネットワークエンティティ129およびビデオデコーダ30は、別々のデバイスの部分であってよいが、他の事例では、ネットワークエンティティ129に関して説明される機能は、ビデオデコーダ30を備える同じデバイスによって実行されてもよい。ネットワークエンティティ129は、ビデオデバイスと見なされてよい。
さらに、いくつかの例では、ネットワークエンティティ129は、図1のファイル生成デバイス34である。ファイルパーシングユニット177は、宛先デバイス14の一部として、または宛先デバイスとは別個のデバイスとして実装することができる。いくつかの例では、ネットワークエンティティ129およびファイルパーシングユニット177は、同じデバイスによって実装される。ファイルパーシングユニット177は、本開示の様々な技法を実施し得る。たとえば、ファイルパーシングユニット177は、第1のトラックおよび第2のトラックを含むファイルを受信し得る。この例では、第1のトラックは、ビットストリームのCVSの第1のアクセスユニットを含み、第2のトラックは、CVSの第2のアクセスユニットを含む。第1のアクセスユニットは、第1のEOS NALユニットを含み、第2のアクセスユニットは、第2のEOS NALユニットを含み得る。いくつかの例では、ファイルから最後のビットストリームを抽出する一環として、ファイルパーシングユニット177は、最後のビットストリームにおいて、第1のEOS NALユニットまたは第2のEOS NALユニットのうちのどちらか後の復号時間に関連する方を出力し得る。たとえば、第1のEOS NALユニットに関連する復号時間と第2のEOS NALユニットに関連する復号時間との比較に基づいて、第1のEOS NALユニットに関連する復号時間が後になることを明らかにし、ファイルパーシングユニット177は、第1のEOS NALユニットを出力し(最後のビットストリームに含め)、第2のEOS NALユニットを破棄し得る。ファイルパーシングユニット177は、第1のトラックにおけるCVSのNALユニットをビデオデコーダ30に出力し、第2のトラックにおけるCVSのNALユニットをビデオデコーダ30に出力し得る。
別の例では、ファイルパーシングユニット177は、第1のトラックおよび第2のトラックを含むファイルを受信し得る。この例では、第1のトラックは、ビットストリームのCVSの第1のアクセスユニットを含み、第2のトラックは、CVSの第2のアクセスユニットを含む。第1のアクセスユニットは、第1のEOB NALユニットを含み、第2のアクセスユニットは、第2のEOB NALユニットを含み得る。いくつかの例では、ファイルから最後のビットストリームを抽出する一環として、ファイルパーシングユニット177は、最後のビットストリームにおいて、第1のEOB NALユニットを出力し、第2のEOB NALユニットを破棄し得る。この例では、ファイルパーシングユニット177は、最後のビットストリーム内に第1のトラックと第2のトラックの両方のNALユニットを含め得る。たとえば、ファイルパーシングユニット177は、第1のトラックにおけるCVSのNALユニットをビデオデコーダ30に出力し、第2のトラックにおけるCVSのNALユニットをビデオデコーダ30に出力し得る。いくつかの例では、ファイルパーシングユニット177は、第1のEOB NALユニットまたは第2のEOB NALユニットのうちのどちらか後の時間に関連する方を出力し得る。たとえば、第1のEOB NALユニットに関連する時間と第2のEOB NALユニットに関連する時間との比較に基づいて、第1のEOB NALユニットに関連する時間が後になることを明らかにし、ファイルパーシングユニット177は、第1のEOB NALユニットを出力し、第2のEOB NALユニットを破棄し得、その逆も同様である。
ビデオデコーダ30のエントロピー復号ユニット180は、ビットストリームの特定のシンタックス要素をエントロピー復号して、量子化係数、動きベクトル、および他のシンタックス要素を生成する。エントロピー復号ユニット180は、予測処理ユニット181に動きベクトルおよび他のシンタックス要素を転送する。ビデオデコーダ30は、ビデオスライスレベルおよび/またはビデオブロックレベルにおいてシンタックス要素を受信することができる。
ビデオスライスがイントラコード化(I)スライスとしてコーディングされたとき、予測処理ユニット181のイントラ予測処理ユニット184は、合図されたイントラ予測モードと、現在のフレームまたはピクチャの以前に復号されたブロックからのデータとに基づいて、現在のビデオスライスのビデオブロックのための予測データを生成してもよい。ビデオフレームがインターコード化(すなわち、BまたはP)スライスとしてコーディングされたとき、予測処理ユニット181の動き補償ユニット182は、エントロピー復号ユニット180から受信した動きベクトルと他のシンタックス要素とに基づいて、現在のビデオスライスのビデオブロックのための予測ブロックを生成する。予測ブロックは、参照ピクチャリストのうちの1つ内の参照ピクチャのうちの1つから生成されてもよい。ビデオデコーダ30は、参照ピクチャメモリ192内に記憶された参照ピクチャに基づいて、デフォルトの構築技術を使用して、参照フレームリスト、リスト0およびリスト1を構築してもよい。
動き補償ユニット182は、動きベクトルを決定し、他のシンタックス要素を取得することによって、現在のビデオスライスのビデオブロックのための予測情報を決定し、予測情報を使用して、復号されている現在ビデオブロックのための予測ブロックを生成する。たとえば、動き補償ユニット182は、受信されたシンタックス要素のうちのいくつかを使用して、現在ビデオスライス内のビデオブロックを復号するために、ビデオスライスのビデオブロックをコーディングするために使用される予測モード(たとえば、イントラ予測またはインター予測)、インター予測スライスタイプ(たとえば、BスライスまたはPスライス)、スライス用の参照ピクチャリストのうちの1つまたは複数のための構築情報、スライスのインター符号化ビデオブロックごとの動きベクトル、スライスのインターコード化ビデオブロックごとのインター予測状態、および他の情報を決定する。
動き補償ユニット182は、補間フィルタに基づいて補間を実行することもできる。動き補償ユニット182は、ビデオブロックの符号化中にビデオエンコーダ20によって使用されたような補間フィルタを使用して、参照ブロックのサブ整数ピクセル用の補間値を計算することができる。この場合には、動き補償ユニット182は、受信したシンタックス要素からビデオエンコーダ20によって使用された補間フィルタを決定し、予測ブロックを生成するために補間フィルタを使用してもよい。
逆量子化ユニット186は、ビットストリーム中で与えられ、エントロピー復号ユニット180によって復号された量子化された変換係数を逆量子化(inverse quantize)、すなわち逆量子化(de-quantize)する。逆量子化プロセスは、量子化の程度を決定し、同様に、適用されるべき逆量子化の程度を決定するために、ビデオスライス内のビデオブロックごとの、ビデオエンコーダ20によって計算された量子化パラメータの使用を含む場合がある。逆変換処理ユニット188は、ピクセル領域内の残差ブロックを生成するために、逆変換、たとえば、逆DCT、逆整数変換、または概念的に同様の逆変換プロセスを変換係数に適用する。
動き補償ユニット182が、動きベクトルと他のシンタックス要素とに基づいて現在ビデオブロックのための予測ブロックを生成した後、ビデオデコーダ30は、逆変換処理ユニット188からの残差ブロックを、動き補償ユニット182によって生成された対応する予測ブロックと加算することによって、復号されたビデオブロックを形成する。加算器190は、この加算演算を実行する1つまたは複数の構成要素を表す。必要に応じて、(コーディングループ内またはコーディングループ後のいずれかの)ループフィルタもまた、ピクセル遷移を平滑化するため、またはさもなければビデオ品質を改善するために使用されてよい。フィルタユニット191は、デブロッキングフィルタ、適応ループフィルタ(ALF)、およびサンプル適応オフセット(SAO)フィルタなど、1つまたは複数のループフィルタを表すことを意図している。フィルタユニット191がループ内フィルタであるものとして図4に示されるが、他の構成では、フィルタユニット191はループ後フィルタとして実装されてよい。所与のフレームまたはピクチャ内の復号されたビデオブロックは次いで、参照ピクチャメモリ192内に記憶され、参照ピクチャメモリ192は、後続の動き補償のために使用される参照ピクチャを記憶する。参照ピクチャメモリ192はまた、図1のディスプレイデバイス32などのディスプレイデバイス上で後に提示するための、復号されたビデオデータを記憶する。したがって、参照ピクチャメモリ192は、ビデオデータを記憶するように構成された1つまたは複数のデータ記憶媒体の一例であってもよい。
図5は、本開示の1つまたは複数の技法による、ファイル300の例示的な構造を示す概念図である。図5の例では、ファイル300は、ムービーボックス302および複数のメディアデータボックス304を含む。同じファイルの中にあるものとして図5の例で示されるが、他の例では、ムービーボックス302およびメディアデータボックス304が別個のファイルの中にあってよい。先に指摘したように、ボックスは、固有タイプ識別子および長さによって規定されるオブジェクト指向ビルディングブロックであり得る。たとえば、ボックスは、4文字コード化ボックスタイプ、ボックスのバイトカウント、およびペイロードを含む、ISOBMFFにおける基本シンタックス構造であり得る。
ムービーボックス302は、ファイル300のトラック用のメタデータを含み得る。ファイル300の各トラックは、メディアデータの連続ストリームを備え得る。メディアデータボックス304の各々は、1つまたは複数のサンプル305を含み得る。サンプル305の各々は、オーディオアクセスユニットまたはビデオアクセスユニットを備え得る。本開示における他の場所で説明されるように、各アクセスユニットは、マルチビューコーディング(たとえば、MV-HEVCおよび3D-HEVC)およびスケーラブルビデオコーディング(たとえば、SHVC)における複数のコード化ピクチャを備え得る。たとえば、アクセスユニットは、レイヤごとに1つまたは複数のコード化ピクチャを含み得る。
さらに、図5の例では、ムービーボックス302は、トラックボックス306を含む。トラックボックス306は、ファイル300のトラック用のメタデータを封入し得る。他の例では、ムービーボックス302は、ファイル300の異なるトラックのための複数のトラックボックスを含み得る。トラックボックス306は、メディアボックス307を含む。メディアボックス307は、トラック内のメディアデータについての情報を宣言するすべてのオブジェクトを含み得る。メディアボックス307は、メディア情報ボックス308を含む。メディア情報ボックス308は、トラックのメディアの特性情報を宣言するすべてのオブジェクトを含み得る。メディア情報ボックス308は、サンプルテーブルボックス309を含む。サンプルテーブルボックス309は、サンプル固有メタデータを指定し得る。
図5の例では、サンプルテーブルボックス309は、少なくとも1つのSampleToGroupボックス310および少なくとも1つのSampleGroupDescriptionボックス312を含む。したがって、サンプルテーブルボックス309は、「コンテナボックス」の事例である。他の例では、サンプルテーブルボックス309は、SampleToGroupボックス310、およびSampleGroupDescriptionボックス312に加えて他のボックスを含んでよく、かつ/または複数のSampleToGroupボックスおよびSampleGroupDescriptionボックスを含んでよい。SampleToGroupボックス310は、サンプル(たとえば、サンプル305のうちの特定のサンプル)をサンプルのグループにマッピングし得る。SampleGroupDescriptionボックス312は、サンプルのグループ(すなわち、サンプルグループ)の中のサンプルによって共有される特性を指定し得る。
さらに、図5の例では、SampleToGroupボックス310は、grouping_typeシンタックス要素313(すなわち、グルーピングタイプシンタックス要素)、entry_countシンタックス要素314(すなわち、エントリカウントシンタックス要素)、および1つまたは複数のサンプルグループエントリ315を含む。entry_countシンタックス要素314は、サンプルグループエントリ315の数を示す。サンプルグループエントリ315の各々は、sample_countシンタックス要素316(すなわち、サンプルカウントシンタックス要素)およびgroup_description_indexシンタックス要素317(すなわち、グループ記述インデックスシンタックス要素)を含む。sample_countシンタックス要素316は、sample_countシンタックス要素316を含むサンプルグループエントリに関連するいくつかのサンプルを示し得る。group_description_indexシンタックス要素317は、group_description_indexシンタックス要素317を含むサンプルグループエントリに関連するサンプルの記述を含むグループ記述エントリを、SampleGroupDescriptionボックス(たとえば、SampleGroupDescriptionボックス312)内で識別し得る。
追加として、図5の例では、SampleGroupDescriptionボックス312は、grouping_typeシンタックス要素320、entry_countシンタックス要素322、および1つまたは複数のグループ記述エントリ324を含む。entry_countシンタックス要素322は、SampleGroupDescriptionボックスの中のグループ記述エントリ324の数を示す。
さらに、図5の例では、サンプルテーブルボックス308は、チャンクオフセットボックス326、sample to chunkボックス328、およびサンプルサイズボックス330を含む。サンプルは「チャンク」内のファイルにクラスタ化されている。チャンクの各々は、ファイル内の連続する一連のビットであってもよい。チャンクオフセットボックス326は、トラックのサンプルを含むチャンクの開始位置および/またはオフセットを指定するデータを含む。このようにして、ファイルは、サンプル、およびサンプル中のNALユニットをトラックと関連付けることができる。異なるトラックボックスは、異なるチャンクオフセットボックスを含む。したがって、それぞれのトラックごとに、デバイスは、それぞれのトラックのチャンクオフセットボックスに基づいて、ファイルのどのチャンクがそれぞれのトラックのサンプルを含むかを決定し得る。ISOBMFF14496-12の第8.7.4節に記載されているように、デバイスは、sample to chunkボックス328内のデータを使用して、トラックのサンプル、サンプルの位置、および関連するサンプルの説明を含むチャンクを見つけるために使用可能なデータを含み得るテーブルを構築し得る。ISOBMFF14496-12の第8.7.3節に記載されているように、サンプルサイズボックス330は、トラック内のサンプルのサイズを指定し得る。
図5の例では、トラックボックス306(すなわち、第1のトラックボックス)は、第1のトラックに関するメタデータを含み得る。さらに、ファイル300は、トラックボックス306の構造と類似の構造を有する第2のトラックボックス(視覚的簡素化のために図5の例には示されていない)を含み得る。第2のトラックボックスは、第2のトラックに関するメタデータを含み得る。本開示の1つまたは複数の技法によれば、第1のトラックのメディアデータボックス内のサンプルは、あるCVSについてのEOS NALユニットを含み、第2のトラックのメディアデータボックス内のサンプルは、同じCVSについてのEOS NALユニットを含み得る。さらに、本開示の1つまたは複数の技法によれば、第1のトラックのメディアデータボックス内のサンプルは、あるCVSについてのEOB NALユニットを含み、第2のトラックのメディアデータボックス内のサンプルは、同じCVSについてのEOB NALユニットを含み得る。
図6は、本開示の1つまたは複数の技法による、ファイル450の例示的な構造を示す概念図である。図6の例では、ファイル450は、1つまたは複数のムービーフラグメントボックス452および複数のメディアデータボックス454を含む。同じファイルの中にあるものとして図6の例で示されるが、他の例では、ムービーフラグメントボックス452およびメディアデータボックス454が別個のファイルの中にあってよい。メディアデータボックス454の各々は、1つまたは複数のサンプル456を含み得る。一部または全部のサンプル456は、ビデオコンテンツのそれぞれのピクチャを含み得る。ムービーフラグメントボックスの各々は、ムービーフラグメントに対応する。各ムービーフラグメントは、トラックフラグメントのセットを備え得る。トラック当たり0個以上のトラックフラグメントがあり得る。
図6の例では、ムービーフラグメントボックス452は、対応するムービーフラグメントに関する情報を提供する。そのような情報は、以前にムービーボックス302などのムービーボックスの中にあったことになる。ムービーフラグメントボックス452は、トラックフラグメントボックス458を含み得る。トラックフラグメントボックス458は、トラックフラグメントに対応し、トラックフラグメントについての情報を提供する。
たとえば、図6の例では、トラックフラグメントボックス458は、トラックフラグメントボックス458に対応するトラックフラグメントについての情報を含む、1つまたは複数のSampleToGroupボックス462および1つまたは複数のSampleGroupDescriptionボックス464を含み得る。したがって、トラックフラグメントボックス458は、「コンテナボックス」のインスタンスである。
さらに、図6の例では、SampleToGroupボックス462は、grouping_typeシンタックス要素470(すなわち、グルーピングタイプシンタックス要素)、entry_countシンタックス要素471(すなわち、エントリカウントシンタックス要素)、および1つまたは複数のサンプルグループエントリ472を含む。entry_countシンタックス要素471は、サンプルグループエントリ472の数を示す。サンプルグループエントリ472の各々は、sample_countシンタックス要素473(すなわち、サンプルカウントシンタックス要素)およびgroup_description_indexシンタックス要素474(すなわち、グループ記述インデックスシンタックス要素)を含む。sample_countシンタックス要素473は、sample_countシンタックス要素473を含むサンプルグループエントリに関連するいくつかのサンプルを示し得る。group_description_indexシンタックス要素474は、group_description_indexシンタックス要素474を含むサンプルグループエントリに関連するサンプルの記述を含むグループ記述エントリを、SampleGroupDescriptionボックス(たとえば、SampleGroupDescriptionボックス464)内で識別し得る。
追加として、図6の例では、SampleGroupDescriptionボックス464は、grouping_typeシンタックス要素480、entry_countシンタックス要素482、および1つまたは複数のグループ記述エントリ484を含む。entry_countシンタックス要素482は、SampleGroupDescriptionボックス464の中のグループ記述エントリ484の数を示す。
図6の例では、トラックフラグメントボックス458はまた、チャンクオフセットボックス486、sample to chunkボックス490、およびサンプルサイズボックス492を含む。チャンクオフセットボックス486、sample to chunkボックス490、およびサンプルサイズボックス492は、図5のチャンクオフセットボックス326、sample to chunkボックス328、およびサンプルサイズボックス330と同じシンタックスおよびセマンティクスを有し得る。
図6の例では、トラックフラグメントボックス458(すなわち、第1のトラックボックス)は、第1のトラックのセグメントに関するメタデータを含み得る。さらに、ファイル300は、トラックフラグメントボックス458の構造と同様の構造を有する第2のトラックフラグメントボックス(すなわち、第2のトラックボックス、視覚的簡素化のために図6の例には示されていない)を含み得る。第2のトラックフラグメントボックスは、第2トラックのセグメントに関するメタデータを含み得る。本開示の1つまたは複数の技法によれば、第1のトラックのセグメントのメディアデータボックス内のサンプルは、あるCVSについてのEOS NALユニットを含み、第2のトラックのセグメントのメディアデータボックス内のサンプルは、同じCVSについてのEOS NALユニットを含み得る。さらに、本開示の1つまたは複数の技法によれば、第1のトラックのメディアデータボックス内のサンプルは、あるCVSについてのEOB NALユニットを含み、第2のトラックのメディアデータボックス内のサンプルは、同じCVSについてのEOB NALユニットを含み得る。
図7は、本開示の1つまたは複数の技法による、ファイルの複数のトラックにおけるEOS NALユニットの例を示す概念図である。図7の例では、ファイルは2つのトラック、トラック1およびトラック2を含む。さらに、図7の例では、トラック1は、第1のサブレイヤ(すなわち、サブレイヤ0)のNALユニットを含み、トラック2は、第2のサブレイヤ(すなわち、サブレイヤ1)のNALユニットを含む。図7の例に示すサブレイヤ0およびサブレイヤ1の部分は、同じCVSに属する。
本開示の1つまたは複数の技法によれば、EOS NALユニットは、ファイルのトラックのうちの2つ以上(すなわち、トラック1およびトラック2)に存在する。さらに、本開示の1つまたは複数の技法によれば、各それぞれのトラックについて、それぞれのトラック内のEOS NALユニットは、CVS内にある最後のAUの一部である。たとえば、EOS NALユニット500は、CVSにあるトラック1の最後のAUにあり、EOS NALユニット502は、CVSにあるトラック2の最後のAUにある。
図8は、本開示の1つまたは複数の技法による、ファイルの複数のトラックにおけるEOB NALユニットの例を示す概念図である。図8の例では、ファイルは2つのトラック、トラック1およびトラック2を含む。さらに、図8の例では、トラック1は、第1のサブレイヤ(すなわち、サブレイヤ0)のNALユニットを含み、トラック2は、第2のサブレイヤ(すなわち、サブレイヤ1)のNALユニットを含む。図8の例に示すサブレイヤ0およびサブレイヤ1の部分は、同じビットストリームに属する。
本開示の1つまたは複数の技法によれば、EOB NALユニットは、ファイルのトラックのうちの2つ以上(すなわち、トラック1およびトラック2)に存在する。さらに、本開示の1つまたは複数の技法によれば、各それぞれのトラックについて、それぞれのトラック内のEOB NALユニットは、ビットストリーム内にある最後のAUの一部である。たとえば、EOB NALユニット520は、ビットストリームにあるトラック1の最後のAUにあり、EOB NALユニット522は、ビットストリームにあるトラック2の最後のAUにある。
図9Aは、本開示の1つまたは複数の技法による、複数のトラックにEOS NALユニットを含むファイルを生成するための例示的な動作を示すフローチャートである。本開示のフローチャートは例である。本開示の技法による他の例では、動作は、より多数の、少数の、または異なるアクションを含むことがあり、または異なる順序でアクションを含むことがある。
図9Aの例では、コンピューティングデバイス(たとえば、ソースデバイス12(図1)、ファイル生成デバイス34(図1)、後処理エンティティ127(図3)、または別のデバイス)は、ファイルの第1のトラックに、ビットストリームのCVSについての第1のEOS NALユニットを含め得る(600)。第1のEOS NALユニットは、CVSの第1のアクセスユニットにある。ファイルのトラック内にNALユニット(たとえば、第1のEOS NALユニット)を含めるために、デバイスは、サンプル305(図5)またはサンプル456(図6)のいずれかなど、サンプル内にNALユニットを含め得る。いくつかの事例では、デバイスは、メディアデータボックス304(図5)またはメディアデータボックス454(図6)などのメディアデータボックスにサンプルを記憶する。他の事例では、デバイスは、サンプルをメディアデータボックス内にカプセル化せずに、サンプルをファイルに直接記憶する。サンプルは「チャンク」内のファイルにクラスタ化されている。さらに、デバイスは、トラックのトラックボックス内にサンプルテーブルボックスを生成し得る。サンプルテーブルボックスは、チャンクオフセットボックス(たとえば、識別子「stco」または「co64」を有するボックス)を含む。あるトラックのチャンクオフセットボックス(すなわち、あるトラックのトラックボックス内のサンプルテーブルボックス内のチャンクオフセットボックス)は、トラックのサンプルを含むチャンクの開始位置および/またはオフセットを指定するデータを含む。したがって、第1のEOS NALユニットなどのNALユニットを含むチャンクを示すために、チャンクオフセットボックスを生成することによって、ファイル生成デバイス34は、トラック内にNALユニットを含めることができる。チャンクオフセットボックスは、ファイルの先頭に対するチャンクの開始位置および/またはオフセットを指定し得る。トラックのサンプルテーブルボックスは、Sample To Chunkボックス(たとえば、識別子「stsc」を有するボックス)も含み得る。デバイスは、Sample To Chunkボックスを使用して、どのサンプルがどのチャンクにあるかを示すテーブルを構築し得る。たとえば、テーブルは、サンプル20〜30がチャンク2内にあることを示し得る。さらに、トラックのサンプルテーブルボックスは、サンプルサイズボックス(たとえば、識別子「stsz」または「stz2」のボックス)を含む。ISOBMFF14996-12の第8.5.3.1節に記載されているように、デバイスは、トラック内のサンプルのサイズを示すテーブルを生成するために、サンプルサイズボックス内の情報を使用し得る。さらに、各サンプルは、サンプル中の各NALユニットのサイズを示すデータを含み得る。
さらに、図9Aの例では、コンピューティングデバイスは、ファイルの第2のトラックに、CVSについての第2のEOS NALユニットを含め得る(602)。図9Aの例では、第2のEOS NALユニットは、CVSの第2のアクセスユニットにある。第2のEOS NALユニットは、第1のEOS NALユニットとは異なる。言い換えれば、第1のEOS NALユニットと第2のEOS NALユニットとは別個のEOS NALユニットである。この例では、第1のアクセスユニットおよび第2のアクセスユニットは、異なる時間サブレイヤに属してもよい。アクセスユニット内のコード化ピクチャが時間サブレイヤに属する場合、アクセスユニットは、時間サブレイヤに属し得る。第1のアクセスユニットおよび第2のアクセスユニットは、異なる復号時間に関連付けられる。
一例では、コンピューティングデバイスは(たとえば、ビデオエンコーダ20から)ビットストリームを受信し得る。この例では、ビットストリームは、第1のEOS NALユニットを含むが、第2のEOS NALユニットは含まない。したがって、この例では、ビットストリームを受信した後、コンピューティングデバイスは、第2のEOS NALユニットを生成し、第2のEOS NALユニットを第2のトラックに含め得る。
第2のEOS NALユニットを第2のトラックに含めるために、デバイスは、第2のEOS NALユニットを含むサンプルボックスを指定するサンプルテーブルボックスを第2のトラックのトラックボックス内に生成し得る。
いくつかの例では、第1のトラックは、CVSについてのビットストリームのアクセスユニットの第1のセットを含み、第1のアクセスユニットは、アクセスユニットの第1のセットの順序で最後のアクセスユニットである。さらに、第2のトラックは、CVSについてのビットストリームのアクセスユニットの第2のセットを含み、第2のアクセスユニットは、アクセスユニットの第2のセットの順序で最後のアクセスユニットである。したがって、この例では、(たとえば、HEVCまたはL-HEVCビットストリームなど)ビットストリームの同じCVS内にあり、複数のトラックに記憶された異なるサブレイヤに属するAUについて、EOS NALユニットは、そのようなトラック内の同じCVS内にある最後のAUの一部として、2つ以上のトラック内(たとえば、トラックの各々)に存在することが可能となる。
図9Bは、本開示の1つまたは複数の技法による、複数のトラックにEOS NALユニットを含むファイルを処理するための例示的な動作を示すフローチャートである。図9Bの例では、コンピューティングデバイス(たとえば、宛先デバイス14(図1)、ファイルパーシングユニット177(図4)、または別のコンピューティングデバイス)は、第1のトラックおよび第2のトラックを含むファイルを受信する(620)。いくつかの例では、ネットワークインターフェース、ディスクドライブ、プロセッサ、またはコンピューティングデバイスの他の構成要素がファイルを受信する。第1のトラックは、ビットストリーム(たとえば、HEVCまたはL-HEVCビットストリーム)のCVSの第1のアクセスユニットを含む。第2のトラックは、CVSの第2のアクセスユニットを含む。図9Bの例では、第1のアクセスユニットは、第1のEOS NALユニットを含み、第2のアクセスユニットは、第2のEOS NALユニットを含む。第2のEOS NALユニットは、第1のEOS NALユニットとは異なる。言い換えれば、第1のEOS NALユニットと第2のEOS NALユニットとは別個のEOS NALユニットである。この例では、第1のアクセスユニットおよび第2のアクセスユニットは、異なる時間サブレイヤに属してもよい。第1のアクセスユニットおよび第2のアクセスユニットは、異なる復号時間に関連付けられる。
図9Bの例に示すように、コンピューティングデバイスは、第1のEOS NALユニットに関連する時間と第2のEOS NALユニットに関連する時間との比較に基づいて、第1のEOS NALユニットを出力し、第2のEOS NALユニットを破棄し得る(622)。いくつかの例では、ネットワークインターフェース、ディスクドライブ、プロセッサ、またはコンピューティングデバイスの他の構成要素が第1のEOS NALユニットを出力する。いくつかの例では、第1のEOS NALユニットが、第2のEOS NALユニットに関連する復号時間よりも長い(すなわち、遅い)復号時間に関連付けられていると決定することに基づいて、コンピューティングデバイスは、ファイル内のNALユニットから再構築されたビットストリームの一部として、第1のEOS NALユニットを出力する。さらに、いくつかの例では、第1のEOS NALユニットが、第2のEOS NALユニットに関連する復号時間よりも長い(すなわち、遅い)復号時間に関連付けられていると決定することに基づいて、コンピューティングデバイスは、第2のEOS NALユニットを破棄する。したがって、この例では、同じビットストリーム内にあり、複数のトラックに記憶された異なるサブレイヤに属するAUについて、トラックのうちの2つ以上がEOS NALユニットを含むとき、EOS NALユニットのうちの1つのみが最後の再構築ビットストリームにおいて保持され、他方のEOS NALユニットは破棄される。コンピューティングデバイスは、最後の再構築ビットストリームにおける、EOB NALユニット(存在する場合)を除いて、すべてのNALユニットの後に、保持されたEOS NALユニットを配置し得る。この例では、EOS NALユニットに関連する復号時間は、EOS NALユニットが属するアクセスユニットの復号時間であり得る。
様々な例では、コンピューティングデバイスは、様々な追加のアクションを実行し得る。たとえば、コンピューティングデバイスは、第1のトラックにおけるCVSのNALユニットをビデオデコーダ30などのビデオデコーダに出力し、第2のトラックにおけるCVSのNALユニットをビデオデコーダに出力し得る。ビデオデコーダは、第1または第2のトラックのうちの少なくとも1つにおけるCVSのNALユニットに基づいて、CVSのピクチャを復号し得る。いくつかの例では、コンピューティングデバイスは、第1のEOS NALユニットを含む第1のアクセスユニットに基づいて、第1のトラックにおけるCVSの後続のNALユニットが存在しないことを決定し得る。たとえば、第1のEOS NALユニットの存在は、第1のトラックに記憶されたCVSの後続のアクセスユニットが存在しないことをコンピューティングデバイスに示し得る。さらに、コンピューティングデバイスは、第2のEOS NALユニットを含む第2のアクセスユニットに基づいて、第2のトラックにおけるCVSの後続のアクセスユニットが存在しないことを決定し得る。たとえば、第2のEOS NALユニットの存在は、第2のトラックに記憶されたCVSの後続のアクセスユニットが存在しないことをコンピューティングデバイスに示し得る。
図10Aは、本開示の1つまたは複数の技法による、複数のトラックにEOB NALユニットを含むファイルを生成するための例示的な動作を示すフローチャートである。図10Aの例では、コンピューティングデバイス(たとえば、ソースデバイス12(図1)、ファイル生成デバイス34(図1)、後処理エンティティ127(図3)、または別のコンピューティングデバイス)は、ファイルの第1のトラックに、ビットストリームのCVSについての第1のEOB NALユニットを含める(650)。図10Aの例では、第1のEOB NALユニットは、CVSの第1のアクセスユニットにある。第1のEOB NALユニットを第1のトラックに含めるために、デバイスは、第1のEOB NALユニットを含むサンプルボックスを指定するサンプルテーブルボックスを第1のトラックのトラックボックス内に生成し得る。
さらに、図10Aの例では、コンピューティングデバイスは、ファイルの第2のトラックに、ビットストリームのCVSについての第2のEOB NALユニットを含める(652)。第2のEOB NALユニットは、CVSの第2のアクセスユニットにある。第2のEOB NALユニットは、第1のEOB NALユニットとは異なる。言い換えれば、第1のEOB NALユニットと第2のEOB NALユニットとは別個のEOB NALユニットである。第1のアクセスユニットおよび第2のアクセスユニットは、異なる復号時間に関連付けられる。この例では、第1のアクセスユニットおよび第2のアクセスユニットは、異なる時間サブレイヤに属する。第1のEOB NALユニットを第1のトラックに含めるために、デバイスは、第1のEOB NALユニットを含むサンプルボックスを指定するサンプルテーブルボックスを第1のトラックのトラックボックス内に生成し得る。
一例では、コンピューティングデバイスは(たとえば、ビデオエンコーダ20から)ビットストリームを受信し得る。この例では、ビットストリームは、第1のEOB NALユニットを含むが、第2のEOB NALユニットは含まない。したがって、この例では、ビットストリームを受信した後、コンピューティングデバイスは、第2のEOB NALユニットを生成し、第2のEOB NALユニットを第2のトラックに含め得る。
図10Bは、本開示の1つまたは複数の技法による、複数のトラックにEOB NALユニットを含むファイルを処理するための例示的な動作を示すフローチャートである。図10Bの例では、コンピューティングデバイス(たとえば、宛先デバイス14(図1)、ファイルパーシングユニット177(図4)、または別のコンピューティングデバイス)は、第1のトラックおよび第2のトラックを含むファイルを受信し得る(670)。いくつかの例では、ネットワークインターフェース、ディスクドライブ、プロセッサ、またはコンピューティングデバイスの他の構成要素がファイルを受信する。第1のトラックは、ビットストリームのCVSの第1のアクセスユニットを含み、第2のトラックは、CVSの第2のアクセスユニットを含む。図10Bの例では、第1のアクセスユニットは、第1のEOB NALユニットを含み、第2のアクセスユニットは、第2のEOB NALユニットを含む。第2のEOB NALユニットは、第1のEOB NALユニットとは異なる。言い換えれば、第1のEOB NALユニットと第2のEOB NALユニットとは別個のEOB NALユニットである。この例では、第1のアクセスユニットおよび第2のアクセスユニットは、異なる時間サブレイヤに属してもよい。第1のアクセスユニットおよび第2のアクセスユニットは、異なる復号時間に関連付けられる。
さらに、図10Bの例では、コンピューティングデバイスは、第1のEOB NALユニットを(たとえば、ビデオデコーダ30などのビデオデコーダに)出力し、第2のEOB NALユニットを破棄する(672)。いくつかの例では、ネットワークインターフェース、ディスクドライブ、プロセッサ、またはコンピューティングデバイスの他の構成要素が第1のEOB NALユニットを出力する。いくつかの例では、コンピューティングデバイスは、ファイル内のNALユニットから再構築されたビットストリームの一部として第1のEOB NALユニットを出力する。いくつかの例では、第1のアクセスユニットが、第2のアクセスユニットに関連する復号時間よりも長い(すなわち、遅い)復号時間に関連付けられていると決定することに基づいて、コンピューティングデバイスは、第2のEOB NALユニットを破棄する。したがって、この例では、ビットストリームの同じCVS内にあり、複数のトラックに記憶された異なるサブレイヤに属するアクセスユニットについて、トラックのうちの2つ以上がEOB NALユニットを含むとき、EOB NALユニットのうちの1つのみが最後の再構築ビットストリームにおいて保持され、他のEOB NALユニットは破棄される。コンピューティングデバイスは、保持されたEOB NALユニットを、最後の再構築ビットストリーム内のアクセスユニットの最後の終わりに配置し得る。この例では、EOB NALユニットに関連する復号時間は、EOB NALユニットが属するアクセスユニットの復号時間であり得る。
様々な例では、コンピューティングデバイスは、様々な追加のアクションを実行し得る。たとえば、コンピューティングデバイスは、第1のトラックにおけるCVSのNALユニットをビデオデコーダ30などのビデオデコーダに出力し、第2のトラックにおけるCVSのNALユニットをビデオデコーダに出力し得る。ビデオデコーダは、第1または第2のトラックのうちの少なくとも1つにおけるCVSのNALユニットに基づいて、CVSのピクチャを復号し得る。いくつかの例では、コンピューティングデバイスは、第1のEOB NALユニットを含む第1のアクセスユニットに基づいて、第1のトラックに記憶されたビットストリームの後続のNALユニットが存在しないことを決定し得る。さらに、コンピューティングデバイスは、第2のEOB NALユニットを含む第2のアクセスユニットに基づいて、第2のトラックに記憶されたビットストリームの後続のNALユニットが存在しないことを決定し得る。
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つもしくは複数のプロセッサを含む、相互動作可能なハードウェアユニットの集合によって提供されてよい。
様々な例が記載されている。これらおよび他の例は、以下の特許請求の範囲内に入る。