国際電気通信連合電気通信標準化部門(International Telecommunication Union Telecommunication Standardization Sector:ITU−T)研究グループ16(Study Group 16:SG16)作業班3(Working Party 3:WP3)と、国際標準化機構/国際電気標準会議(International Organization for Standardization/International Electrotechnical Commission:ISO/IEC)合同専門委員会1/小委員会29/作業グループ11(Joint Technical Committee 1/Subcommittee 29/Working Group 11:JTC1/SC29/WG11)とのビデオ符号化に関する共同作業チーム(Joint Collaborative Team on Video Coding:JCT−VC)は、高効率ビデオ符号化規格(High Efficiency Video Coding standard:HEVC)と呼ばれるビデオ符号化規格に関する標準化の取り組みを開始した。HEVCは、ブロックに基づく符号化を使用する。
図1Aは、ビデオが符号化される電子デバイス102の一構成を示すブロック図である。なお、電子デバイス102内に含まれるものとして示されるエレメントの1つまたはそれ以上は、ハードウェア、ソフトウェア、または両方の組み合わせにおいて実現されてもよい。たとえば、電子デバイス102は、ハードウェア、ソフトウェア、または両方の組み合わせにおいて実現されるエンコーダ108を含む。たとえば、エンコーダ108は回路、集積回路、特定用途向け集積回路(application−specific integrated circuit:ASIC)、実行可能な命令を有するメモリと電子通信を行うプロセッサ、ファームウェア、フィールドプログラマブルゲート配列(field−programmable gate array:FPGA)など、またはその組み合わせとして実現されてもよい。いくつかの構成において、エンコーダ108は高効率ビデオ符号化(HEVC)コーダであってもよい。
電子デバイス102はサプライヤ104を含んでもよい。サプライヤ104は、ピクチャまたは画像データ(例、ビデオ)をソース106としてエンコーダ108に提供してもよい。サプライヤ104の例は、画像センサ、メモリ、通信インタフェース、ネットワークインタフェース、無線受信機、ポートなどを含む。
ソース106は、イントラフレーム予測モジュールおよび再構築バッファ110に提供されてもよい。加えてソース106は、動き推定および動き補償モジュール136と、減算モジュール116とに提供されてもよい。
イントラフレーム予測モジュールおよび再構築バッファ110は、ソース106および再構築データ150に基づいて、イントラモード情報128およびイントラ信号112を生成してもよい。動き推定および動き補償モジュール136は、ソース106および参照ピクチャバッファ166の信号168に基づいて、インターモード情報138およびインター信号114を生成してもよい。参照ピクチャバッファ166の信号168は、参照ピクチャバッファ166に保存される1つまたはそれ以上の参照ピクチャからのデータを含んでもよい。
エンコーダ108は、モードに従ってイントラ信号112とインター信号114との間で選択を行ってもよい。イントラ信号112は、イントラ符号化モードにおいてピクチャ内の空間的特徴を利用するために用いられてもよい。インター信号114は、インター符号化モードにおいてピクチャ間の時間的特徴を利用するために用いられてもよい。イントラ符号化モードで、イントラ信号112が減算モジュール116に提供されてもよく、かつイントラモード情報128がエントロピー符号化モジュール130に提供されてもよい。インター符号化モードで、インター信号114が減算モジュール116に提供されてもよく、かつインターモード情報138がエントロピー符号化モジュール130に提供されてもよい。 予測残差118を生成するために、減算モジュール116において(モードによって)イントラ信号112またはインター信号114のいずれかがソース106から減算される。予測残差118は変換モジュール120に提供される。変換モジュール120は予測残差118を圧縮して変換信号122を生成してもよく、変換信号122は量子化モジュール124に提供される。量子化モジュール124は変換信号122を量子化して、変換および量子化係数(transformed and quantized coefficients:TQC)126を生成する。
TQC126は、エントロピー符号化モジュール130および逆量子化モジュール140に提供される。逆量子化モジュール140は、TQC126に対して逆量子化を行って逆量子化信号142を生成し、逆量子化信号142は逆変換モジュール144に提供される。逆変換モジュール144は、逆量子化信号142を展開して展開信号146を生成し、展開信号146は再構築モジュール148に提供される。
再構築モジュール148は、展開信号146に基づいて再構築データ150を生成してもよい。たとえば、再構築モジュール148は(修正された)ピクチャを再構築してもよい。再構築データ150は、デブロッキングフィルタ152と、イントラ予測モジュールおよび再構築バッファ110とに提供されてもよい。デブロッキングフィルタ152は、再構築データ150に基づいてフィルタ信号154を生成してもよい。
フィルタ信号154は、サンプル適応オフセット(sample adaptive offset:SAO)モジュール156に提供されてもよい。SAOモジュール156は、エントロピー符号化モジュール130に提供されるSAO情報158と、適応ループフィルタ(adaptive loop filter:ALF)162に提供されるSAO信号160とを生成してもよい。ALF162はALF信号164を生成し、ALF信号164は参照ピクチャバッファ166に提供される。ALF信号164は、参照ピクチャとして用いられる1つまたはそれ以上のピクチャからのデータを含んでもよい。場合によっては、ALF162が省略されてもよい。
エントロピー符号化モジュール130は、TQC126を符号化してビットストリーム134を生成してもよい。上述のとおり、TQC126はエントロピー符号化の前に1D配列に変換されてもよい。加えて、エントロピー符号化モジュール130は、CAVLCまたはCABACを用いてTQC126を符号化してもよい。特に、エントロピー符号化モジュール130は、イントラモード情報128、インターモード情報138およびSAO情報158のうちの1つまたはそれ以上に基づいて、TQC126を符号化してもよい。ビットストリーム134は、符号化ピクチャデータを含んでもよい。
たとえばHEVCなどのビデオ圧縮に伴われる量子化は、ある範囲の値を単一の量子値に圧縮することによって達成される不可逆圧縮技術である。量子化パラメータ(quantization parameter:QP)は、再構築されたビデオの品質および圧縮比の両方に基づいて量子化を行うために用いられる、予め定義されたスケーリングパラメータである。所与のブロックの特徴をブロックサイズおよびブロックの色情報に基づいて表すために、HEVCにおいてブロックタイプが定められる。QP、解像度情報およびブロックタイプは、エントロピー符号化の前に定められてもよい。たとえば、電子デバイス102(例、エンコーダ108)がQP、解像度情報およびブロックタイプを定めてもよく、これらの情報がエントロピー符号化モジュール130に提供されてもよい。
エントロピー符号化モジュール130は、TQC126のブロックに基づいてブロックサイズを定めてもよい。たとえば、ブロックサイズはTQCのブロックの1つのディメンジョンに沿ったTQC126の数であってもよい。言換えると、TQCのブロック内のTQC126の数は、ブロックサイズの2乗に等しくてもよい。加えて、ブロックは正方形でなくてもよく、ここでTQC126の数はブロックの高さ掛ける幅である。たとえば、ブロックサイズは、TQCのブロック内のTQC126の数の平方根として定めてもよい。解像度は、画素幅掛ける画素高さとして定義されてもよい。解像度情報は、ピクチャの幅、ピクチャの高さ、またはその両方に対する画素数を含んでもよい。ブロックサイズは、TQCの2Dブロックの1つのディメンジョンに沿ったTQCの数として定義されてもよい。
いくつかの構成において、ビットストリーム134は別の電子デバイスに送信されてもよい。たとえば、ビットストリーム134は通信インタフェース、ネットワークインタフェース、無線送信機、ポートなどに提供されてもよい。たとえば、ビットストリーム134はローカルエリアネットワーク(Local Area Network:LAN)、インターネット、携帯電話基地局などを介して別の電子デバイスに送信されてもよい。付加的または代替的に、ビットストリーム134は電子デバイス102のメモリに保存されてもよい。
図2Bは、高効率ビデオ符号化(HEVC)デコーダであってもよいデコーダ272を含む電子デバイス270の一構成を示すブロック図である。デコーダ272およびデコーダ272内に含まれるものとして示されるエレメントの1つまたはそれ以上は、ハードウェア、ソフトウェア、または両方の組み合わせにおいて実現されてもよい。デコーダ272は、復号のためのビットストリーム234(例、ビットストリーム234に含まれる1つまたはそれ以上の符号化ピクチャ)を受信してもよい。いくつかの構成において、受信されるビットストリーム234は、たとえば受信スライスヘッダ、受信ピクチャパラメータセット(picture parameter set:PPS)、受信バッファ記述情報、分類インジケータなどの受信オーバーヘッド情報を含んでもよい。
ビットストリーム234からの受信シンボル(例、符号化TQC)は、エントロピー復号モジュール274によってエントロピー復号されてもよい。このエントロピー復号によって、動き情報信号298と、復号された変換および量子化係数(TQC)278とが生成されてもよい。
動き情報信号298は、動き補償モジュール294において、フレームメモリ290からの復号ピクチャ292の一部と組み合わされてもよく、動き補償モジュール294はインターフレーム予測信号296を生成してもよい。復号された変換および量子化係数(TQC)278は、逆量子化および逆変換モジュール280によって逆量子化および逆変換されることによって、復号残差信号282を生成してもよい。加算モジュール207によって復号残差信号282を予測信号205に加えて、結合信号284を生成してもよい。予測信号205は、動き補償モジュール294によって生成されるインターフレーム予測信号296か、またはイントラフレーム予測モジュール201によって生成されるイントラフレーム予測信号203のいずれかから選択される信号であってもよい。いくつかの構成において、この信号選択はビットストリーム234に基づいて(例、制御されて)いてもよい。
イントラフレーム予測信号203は、(たとえば現フレーム内の)結合信号284からの、以前に復号された情報から予測されてもよい。結合信号284はさらに、デブロッキングフィルタ286によってフィルタ処理されてもよい。結果として得られるフィルタ信号288は、サンプル適応オフセット(SAO)モジュール231に提供されてもよい。フィルタ信号288と、エントロピー復号モジュール274からの情報239とに基づいて、SAOモジュール231はSAO信号235を生成してもよく、SAO信号235は適応ループフィルタ(adaptive loop filter:ALF)233に提供される。ALF233はALF信号237を生成し、ALF信号237はフレームメモリ290に提供される。ALF信号237は、参照ピクチャとして用いられる1つまたはそれ以上のピクチャからのデータを含んでもよい。ALF信号237はフレームメモリ290に書込まれてもよい。結果として得られるALF信号237は、復号ピクチャを含んでもよい。場合によっては、ALF233が省略されてもよい。
フレームメモリ290は、復号ピクチャバッファ(decoded picture buffer:DPB)を含んでもよい。フレームメモリ290はさらに、復号ピクチャに対応するオーバーヘッド情報を含んでもよい。たとえば、フレームメモリ290は、スライスヘッダ、ピクチャパラメータセット(PPS)情報、サイクルパラメータ、バッファ記述情報などを含んでもよい。これらの情報の1つまたはそれ以上が、コーダ(例、エンコーダ108)からシグナリングされてもよい。
フレームメモリ290は、1つまたはそれ以上の復号ピクチャ292を動き補償モジュール294に提供してもよい。さらに、フレームメモリ290は1つまたはそれ以上の復号ピクチャ292を提供してもよく、その復号ピクチャ292はデコーダ272から出力されてもよい。1つまたはそれ以上の復号ピクチャ292は、たとえばディスプレイに提示されたり、メモリに保存されたり、別のデバイスに送信されたりしてもよい。
図1Bは、電子デバイス702上のビデオエンコーダ782の一構成を示すブロック図である。図1Bのビデオエンコーダ782は、図1Aのビデオエンコーダ108の一構成であってもよい。ビデオエンコーダ782は、エンハンスメントレイヤエンコーダ706と、ベースレイヤエンコーダ709と、解像度アップスケーリングブロック770と、出力インタフェース780とを含んでもよい。本明細書に記載されるとおり、たとえば図1Bのビデオエンコーダは、スケーラブルビデオ符号化およびマルチビュービデオ符号化に対して好適である。
エンハンスメントレイヤエンコーダ706は、入力ピクチャ704を受信するビデオ入力781を含んでもよい。ビデオ入力781の出力は、予測選択750の出力を受信する加算器/減算器783に提供されてもよい。加算器/減算器783の出力は、変換および量子化ブロック752に提供されてもよい。変換および量子化ブロック752の出力は、エントロピー符号化748ブロックならびにスケーリングおよび逆変換ブロック772に提供されてもよい。エントロピー符号化748が行われた後、エントロピー符号化ブロック748の出力は、出力インタフェース780に提供されてもよい。出力インタフェース780は、符号化ベースレイヤビデオビットストリーム707と、符号化エンハンスメントレイヤビデオビットストリーム710との両方を出力してもよい。
スケーリングおよび逆変換ブロック772の出力は、加算器779に提供されてもよい。加算器779はさらに、予測選択750の出力を受信してもよい。加算器779の出力は、デブロッキングブロック751に提供されてもよい。デブロッキングブロック751の出力は、参照バッファ794に提供されてもよい。参照バッファ794の出力は、動き補償ブロック754に提供されてもよい。動き補償ブロック754の出力は、予測選択750に提供されてもよい。参照バッファ794の出力は、イントラ予測因子756にも提供されてもよい。イントラ予測因子756の出力は、予測選択750に提供されてもよい。予測選択750はさらに、解像度アップスケーリングブロック770の出力を受信してもよい。
ベースレイヤエンコーダ709は、ダウンサンプリングされた入力ピクチャ、または別の画像と組み合わせるために好適なその他の画像内容、または代替ビュー入力ピクチャもしくは同じ入力ピクチャ703(すなわち、エンハンスメントレイヤエンコーダ706が受信する入力ピクチャ704と同じ入力ピクチャ)を受信するビデオ入力762を含んでもよい。ビデオ入力762の出力は、符号化予測ループ764に提供されてもよい。エントロピー符号化766は、符号化予測ループ764の出力に提供されてもよい。符号化予測ループ764の出力は、参照バッファ768にも提供されてもよい。参照バッファ768は、符号化予測ループ764にフィードバックを提供してもよい。参照バッファ768の出力は、解像度アップスケーリングブロック770にも提供されてもよい。エントロピー符号化766が行われたとき、その出力が出力インタフェース780に提供されてもよい。
図2Bは、電子デバイス802上のビデオデコーダ812の一構成を示すブロック図である。図2Bのビデオデコーダ812は、図2Aのビデオデコーダ272の一構成であってもよい。ビデオデコーダ812は、エンハンスメントレイヤデコーダ815と、ベースレイヤデコーダ813とを含んでもよい。加えてビデオデコーダ812は、インタフェース889と、解像度アップスケーリング870とを含んでもよい。本明細書に記載されるとおり、たとえば図2Bのビデオデコーダは、スケーラブルビデオ符号化およびマルチビュービデオ符号化に対して好適である。
インタフェース889は、符号化ビデオストリーム885を受信してもよい。符号化ビデオストリーム885は、ベースレイヤ符号化ビデオストリームと、エンハンスメントレイヤ符号化ビデオストリームとからなっていてもよい。これら2つのストリームは別々に送られても、一緒に送られてもよい。インタフェース889は、符号化ビデオストリーム885の一部またはすべてを、ベースレイヤデコーダ813内のエントロピー復号ブロック886に提供してもよい。エントロピー復号ブロック886の出力は、復号予測ループ887に提供されてもよい。復号予測ループ887の出力は、参照バッファ888に提供されてもよい。参照バッファは、復号予測ループ887にフィードバックを提供してもよい。加えて参照バッファ888は、復号ベースレイヤビデオストリーム884を出力してもよい。
加えてインタフェース889は、符号化ビデオストリーム885の一部またはすべてを、エンハンスメントレイヤデコーダ815内のエントロピー復号ブロック890に提供してもよい。エントロピー復号ブロック890の出力は、逆量子化ブロック891に提供されてもよい。逆量子化ブロック891の出力は、加算器892に提供されてもよい。加算器892は、逆量子化ブロック891の出力と、予測選択ブロック895の出力とを加算してもよい。加算器892の出力は、デブロッキングブロック893に提供されてもよい。デブロッキングブロック893の出力は、参照バッファ894に提供されてもよい。参照バッファ894は、復号エンハンスメントレイヤビデオストリーム882を出力してもよい。参照バッファ894の出力は、イントラ予測因子897にも提供されてもよい。エンハンスメントレイヤデコーダ815は、動き補償896を含んでもよい。動き補償896は、解像度アップスケーリング870の後に行われてもよい。予測選択ブロック895は、イントラ予測因子897の出力と、動き補償896の出力とを受信してもよい。
図3Aは、エンコーダ308およびデコーダ372の一実施例を示すブロック図である。この実施例においては、電子デバイスA302および電子デバイスB370が示される。しかし、いくつかの構成においては、電子デバイスA302および電子デバイスB370に関して記載された特徴および機能が単一の電子デバイス内に組み合わされてもよいことが留意されるべきである。
電子デバイスA302はエンコーダ308を含む。エンコーダ308は、ハードウェア、ソフトウェア、または両方の組み合わせにおいて実現されてもよい。一構成において、エンコーダ308は高効率ビデオ符号化(HEVC)コーダであってもよい。他のコーダが同様に用いられてもよい。電子デバイスA302はソース306を得てもよい。いくつかの構成において、ソース306は、画像センサを用いて電子デバイスA302に捕捉されても、メモリから検索されても、別の電子デバイスから受信されてもよい。
エンコーダ308はソース306を符号化してビットストリーム334を生成してもよい。たとえば、エンコーダ308はソース306内の一連のピクチャ(例、ビデオ)を符号化してもよい。エンコーダ308は、図1Aに関連して上述したエンコーダ108と類似のものであってもよい。
ビットストリーム334は、ソース306に基づく符号化ピクチャデータを含んでもよい。いくつかの構成において、ビットストリーム334はさらに、たとえばスライスヘッダ情報、PPS情報などのオーバーヘッドデータを含んでもよい。ソース306内の付加的なピクチャが符号化されるために、ビットストリーム334は1つまたはそれ以上の符号化ピクチャを含んでもよい。
ビットストリーム334はデコーダ372に提供されてもよい。一実施例において、ビットストリーム334は、有線または無線リンクを用いて電子デバイスB370に送信されてもよい。場合によっては、この送信が、たとえばインターネットまたはローカルエリアネットワーク(LAN)などのネットワークを通じて行われてもよい。図3Aに示されるとおり、デコーダ372は、電子デバイスA302のエンコーダ308とは別に電子デバイスB370上に実現されてもよい。しかし、いくつかの構成においては、エンコーダ308とデコーダ372とが同じ電子デバイス上に実現されてもよいことに留意すべきである。エンコーダ308とデコーダ372とが同じ電子デバイス上に実現される実施においては、たとえばビットストリーム334はバスを通じてデコーダ372に提供されてもよいし、デコーダ372による検索のためにメモリに保存されてもよい。デコーダ372は、復号ピクチャ392出力を提供してもよい。
デコーダ372は、ハードウェア、ソフトウェア、または両方の組み合わせにおいて実現されてもよい。一構成において、デコーダ372は高効率ビデオ符号化(HEVC)デコーダであってもよい。他のデコーダが同様に用いられてもよい。デコーダ372は、図2Aに関連して上述したデコーダ272と類似のものであってもよい。
図3Bは、エンコーダ(ecoder)908およびデコーダ972の別の実施例を示すブロック図である。この実施例においては、電子デバイスA902および電子デバイスB970が示される。しかし、いくつかの構成においては、電子デバイスA902および電子デバイスB970に関して記載された特徴および機能が単一の電子デバイス内に組み合わされてもよいことが留意されるべきである。
電子デバイスA902はエンコーダ908を含む。エンコーダ908は、ベースレイヤエンコーダ910と、エンハンスメントレイヤエンコーダ920とを含んでもよい。ビデオエンコーダ908は、スケーラブルビデオ符号化およびマルチビュービデオ符号化に対して好適である。エンコーダ908は、ハードウェア、ソフトウェア、または両方の組み合わせにおいて実現されてもよい。一構成において、エンコーダ908は、スケーラブルおよび/またはマルチビューを含む高効率ビデオ符号化(HEVC)コーダであってもよい。他のコーダが同様に用いられてもよい。電子デバイスA902はソース906を得てもよい。いくつかの構成において、ソース906は、画像センサを用いて電子デバイスA902に捕捉されても、メモリから検索されても、別の電子デバイスから受信されてもよい。
エンコーダ908はソース906を符号化して、ベースレイヤビットストリーム934およびエンハンスメントレイヤビットストリーム936を生成してもよい。たとえば、エンコーダ908はソース906内の一連のピクチャ(例、ビデオ)を符号化してもよい。特に、品質スケーラビリティとしても公知であるSNRスケーラビリティに対するスケーラブルビデオ符号化に対しては、ベースレイヤおよびエンハンスメントレイヤエンコーダに同じソース906が提供されてもよい。特に、空間スケーラビリティに対するスケーラブルビデオ符号化に対しては、ベースレイヤエンコーダにはダウンサンプリングされたソースが用いられてもよい。特に、マルチビュー符号化に対しては、ベースレイヤエンコーダおよびエンハンスメントレイヤエンコーダに異なるビューソースが用いられてもよい。エンコーダ908は、図1Bに関連して上述したエンコーダ782と類似のものであってもよい。
ビットストリーム934、936は、ソース906に基づく符号化ピクチャデータを含んでもよい。いくつかの構成において、ビットストリーム934、936はさらに、たとえばスライスヘッダ情報、PPS情報などのオーバーヘッドデータを含んでもよい。ソース906内の付加的なピクチャが符号化されるために、ビットストリーム934、936は1つまたはそれ以上の符号化ピクチャを含んでもよい。
ビットストリーム934、936は、デコーダ972に提供されてもよい。デコーダ972は、ベースレイヤデコーダ980と、エンハンスメントレイヤデコーダ990とを含んでもよい。ビデオデコーダ972は、スケーラブルビデオ復号およびマルチビュービデオ復号に対して好適である。一実施例において、ビットストリーム934、936は、有線または無線リンクを用いて電子デバイスB970に送信されてもよい。場合によっては、この送信が、たとえばインターネットまたはローカルエリアネットワーク(LAN)などのネットワークを通じて行われてもよい。図3Bに示されるとおり、デコーダ972は、電子デバイスA902のエンコーダ908とは別に電子デバイスB970上に実現されてもよい。しかし、いくつかの構成においては、エンコーダ908とデコーダ972とが同じ電子デバイス上に実現されてもよいことに留意すべきである。エンコーダ908とデコーダ972とが同じ電子デバイス上に実現される実施においては、たとえばビットストリーム934、936は、バスを通じてデコーダ972に提供されてもよいし、デコーダ972による検索のためにメモリに保存されてもよい。デコーダ972は、出力として復号ベースレイヤ992および復号エンハンスメントレイヤピクチャ(単数または複数)994を提供してもよい。
デコーダ972は、ハードウェア、ソフトウェア、または両方の組み合わせにおいて実現されてもよい。一構成において、デコーダ972は、スケーラブルおよび/またはマルチビューを含む高効率ビデオ符号化(HEVC)デコーダであってもよい。他のデコーダが同様に用いられてもよい。デコーダ972は、図2Bに関連して上述したデコーダ812と類似のものであってもよい。
図4は、電子デバイス409において使用されるさまざまなコンポーネントを示す。電子デバイス409は、電子デバイスの1つまたはそれ以上として実現されてもよい。たとえば、電子デバイス409は、図1Aおよび図1Bに関連して上述した電子デバイス102、図2Aおよび図2Bに関連して上述した電子デバイス270、またはその両方として実現されてもよい。
電子デバイス409は、電子デバイス409の動作を制御するプロセッサ417を含む。プロセッサ417は、CPUと呼ばれることもある。リードオンリメモリ(read−only memory:ROM)、ランダムアクセスメモリ(random access memory:RAM)の両方、または情報を保存する任意のタイプのデバイスを含むメモリ411は、プロセッサ417に命令413a(例、実行可能な命令)およびデータ415aを提供する。メモリ411の一部は、不揮発性ランダムアクセスメモリ(non−volatile random access memory:NVRAM)をさらに含んでもよい。メモリ411は、プロセッサ417と電子通信していてもよい。
加えて、プロセッサ417内にも命令413bおよびデータ415bが存在してもよい。プロセッサ417にロードされた命令413bおよび/またはデータ415bはさらに、プロセッサ417による実行または処理のためにロードされた、メモリ411からの命令413aおよび/またはデータ415aを含んでもよい。本明細書において開示される1つまたはそれ以上の技術を実現するために、プロセッサ417によって命令413bが実行されてもよい。
電子デバイス409は、他の電子デバイスと通信するための1つまたはそれ以上の通信インタフェース419を含んでもよい。通信インタフェース419は、有線通信技術、無線通信技術、またはその両方に基づいていてもよい。通信インタフェース419の例は、シリアルポート、パラレルポート、ユニバーサルシリアルバス(Universal Serial Bus:USB)、イーサネット(登録商標)アダプタ、IEEE1394バスインタフェース、小型コンピュータシステムインタフェース(small computer system interface:SCSI)バスインタフェース、赤外線(infrared:IR)通信ポート、Bluetooth(登録商標)無線通信アダプタ、および第3世代パートナーシッププロジェクト(3rd Generation Partnership Project:3GPP)仕様に従う無線トランシーバなどを含む。
電子デバイス409は、1つまたはそれ以上の出力デバイス423および1つまたはそれ以上の入力デバイス421を含んでもよい。出力デバイス423の例は、スピーカ、プリンタなどを含む。電子デバイス409に含まれる1つのタイプの出力デバイスは、ディスプレイデバイス425である。本明細書において開示される構成とともに使用されるディスプレイデバイス425は、たとえば陰極線管(cathode ray tube:CRT)、液晶ディスプレイ(liquid crystal display:LCD)、発光ダイオード(light−emitting diode:LED)、気体プラズマ、またはエレクトロルミネセンスなど、任意の好適な画像投影技術を用いてもよい。メモリ411に保存されたデータを、ディスプレイ425において示されるテキスト、グラフィックス、および/または動画に(適宜)変換するために、ディスプレイコントローラ427が提供されてもよい。入力デバイス421の例は、キーボード、マウス、マイクロホン、リモートコントロールデバイス、ボタン、ジョイスティック、トラックボール、タッチパッド、タッチスクリーン、ライトペンなどを含む。
電子デバイス409のさまざまなコンポーネントは、バスシステム429によってともに結合されており、バスシステム429は、データバスに加えて電力バス、制御信号バスおよびステータス信号バスを含んでもよい。しかし、明瞭にするために、図4においてはさまざまなバスがバスシステム429として示される。図4に示される電子デバイス409は、特定のコンポーネントのリストではなく、機能ブロック図である。
「コンピュータ読取り可能媒体」という用語は、コンピュータまたはプロセッサによるアクセスが可能なあらゆる利用可能な媒体を示す。本明細書において用いられる「コンピュータ読取り可能媒体」という用語は、非一時的かつ有形なコンピュータおよび/またはプロセッサ読取り可能媒体を示してもよい。限定ではなく例として、コンピュータ読取り可能媒体またはプロセッサ読取り可能媒体は、RAM、ROM、EEPROM、CD−ROMもしくはその他の光ディスク記憶装置、磁気ディスク記憶装置もしくはその他の磁気記憶装置、または、命令もしくはデータ構造の形の所望のプログラムコードを保有もしくは保存するために使用でき、かつコンピュータもしくはプロセッサによるアクセスが可能なあらゆるその他の媒体を含んでもよい。本明細書において用いられるディスク(Disk)およびディスク(disc)は、コンパクトディスク(compact disc:CD)、レーザディスク、光ディスク、デジタル多用途ディスク(digital versatile disc:DVD)、フロッピーディスク、およびBlu−ray(登録商標)ディスクを含み、ここでディスク(disks)は通常データを磁気的に再生するのに対し、ディスク(discs)はデータをレーザによって光学的に再生する。デコーダおよび/またはエンコーダに対するコードが、コンピュータ読取り可能媒体に保存されてもよい。
複数の符号化ツリーブロック(例、本明細書においては一般的にブロックと呼ぶ)を含む入力ピクチャは、1つまたはいくつかのスライスに分割されてもよい。エンコーダおよびデコーダにおいて用いられる参照ピクチャが同じであり、かつデブロッキングフィルタ処理がスライス境界を越えた情報を使用しないとき、あるスライスが表すピクチャの区域内のサンプルの値は、他のスライスからのデータを使用することなく適切に復号されてもよい。したがって、あるスライスに対するエントロピー復号およびブロック再構築は、他のスライスに依存しない。特に、エントロピー符号化状態は、各スライスの最初にリセットされてもよい。エントロピー復号および再構築の両方に対する近傍の利用可能性を定めるとき、他のスライスのデータは利用不可能とマーク付けされてもよい。スライスは、並行してエントロピー復号および再構築されてもよい。スライスの境界を越えたイントラ予測および動きベクトル予測は許可されないことが好ましい。これに対し、デブロッキングフィルタ処理は、スライス境界を越えた情報を使用してもよい。
図5は、水平方向に11ブロック、鉛直方向に9ブロックを含む例示的ビデオピクチャ500を示す(9つの例示的ブロックが501〜509とラベル付けされる)。図5は、3つの例示的スライスを示す。すなわち、「SLICE#0」と表示される第1のスライス520、「SLICE#1」と表示される第2のスライス530、および「SLICE#2」と表示される第3のスライス540である。デコーダは、3つのスライス520、530、540を並行して復号および再構築してもよい。各々のスライスは、連続的な態様で走査線の順序で送信されてもよい。各スライスに対する復号/再構築プロセスの開始時に、コンテキストモデルは初期化またはリセットされ、他のスライスのブロックは、エントロピー復号およびブロック再構築の両方に対して利用不可能とマーク付けされる。コンテキストモデルは一般的に、エントロピーエンコーダおよび/またはデコーダの状態を表す。よって、たとえば「SLICE#1」内の503とラベル付けされたブロックなどのブロックに対して、「SLICE#0」内のブロック(たとえば501および502とラベル付けされたブロック)は、コンテキストモデル選択にも再構築にも使用されない。一方で、たとえば「SLICE#1」内の505とラベル付けされたブロックなどのブロックに対して、「SLICE#1」内の他のブロック(たとえば503および504とラベル付けされたブロック)は、コンテキストモデル選択または再構築のために使用されてもよい。したがって、エントロピー復号およびブロック再構築は、スライス内で連続的に進行する。スライスがフレキシブルブロック順序付け(flexible block ordering:FMO)を用いるものと定められない限り、スライス内のブロックはラスタスキャン順に処理される。
図6を参照すると、タイル技術は、画像を(正方形を含む)矩形領域のセットに分割する。各タイル内のブロック(いくつかのシステムにおいては、代替的に最大符号化ユニットまたは符号化ツリーブロックと呼ばれる)は、ラスタスキャン順に符号化および復号される。タイルの配列も、同様にラスタスキャン順に符号化および復号される。したがって、任意の好適な数の列境界(例、0またはそれ以上)が存在してもよく、かつ任意の好適な数の行境界(例、0またはそれ以上)が存在してもよい。よって、フレームはたとえば図6に示される1つのスライスなどの、1つまたはそれ以上のスライスを定めてもよい。いくつかの実施形態において、異なるタイルに位置するブロックは、イントラ予測、動き補償、エントロピー符号化コンテキスト選択、または近傍ブロック情報に依拠するその他のプロセスに利用できない。
図7を参照すると、画像を3つの矩形の列のセットに分割するタイル技術が示される。各タイル内のブロック(いくつかのシステムにおいては、代替的に最大符号化ユニットまたは符号化ツリーブロックと呼ばれる)は、ラスタスキャン順に符号化および復号される。タイルも同様に、ラスタスキャン順に符号化および復号される。タイルのスキャン順において1つまたはそれ以上のスライスが定められてもよい。各々のスライスは独立に復号可能である。たとえば、スライス1はブロック1〜9を含むものと定められてもよく、スライス2はブロック10〜28を含むものと定められてもよく、スライス3は3つのタイルにまたがるブロック29〜126を含むものと定められてもよい。タイルの使用によって、フレームのより局部的領域でデータを処理することによって、符号化効率が高まる。
場合によっては、ビデオ符号化は任意にタイルを含まないことがあり、任意にビデオのフレームに対するウェーブフロント符号化/復号パターンの使用を含むことが理解されるべきである。この態様で、ビデオの1つまたはそれ以上のライン(たとえば、マクロブロック(または代替的に符号化ツリーブロック)の1つまたはそれ以上の行の複数のグループなどであって、ウェーブフロントサブストリームを表すその各々のグループが、並行する態様で符号化/復号されてもよい。一般的に、ビデオの分割は、任意の好適な態様で構築されてもよい。
ビデオ符号化規格はしばしば、限られた周波数帯域幅および/または限られた記憶容量を伴うチャネルを通じた送信のために、ビデオデータを圧縮する。これらのビデオ符号化規格は、より効果的にフレームを符号化および復号するために、たとえばイントラ予測、空間ドメインから周波数ドメインへの変換、量子化、エントロピー符号化、動き推定、および動き補償など、複数の符号化段階を含んでもよい。符号化および復号段階の多くは、計算が過度に複雑である。
ビデオのビットストリームは、一般的にネットワーク抽象化レイヤ(NAL)ユニットと呼ばれる論理データパケットに入れられるシンタックス構造を含んでもよい。各NALユニットは、関連するデータペイロードの目的を識別するための、たとえば2バイトNALユニットヘッダ(例、16ビット)などのNALユニットヘッダを含む。たとえば、各符号化スライス(および/またはピクチャ)は、1つまたはそれ以上のスライス(および/またはピクチャ)NALユニットにおいて符号化されてもよい。たとえば補足エンハンスメント情報、時間サブレイヤアクセス(temporal sub−layer access:TSA)ピクチャの符号化スライス、段階的時間サブレイヤアクセス(step−wise temporal sub−layer access:STSA)ピクチャの符号化スライス、符号化スライス非TSA、非STSAトレイリングピクチャ、ブロークンリンクアクセスピクチャの符号化スライス、瞬時復号リフレッシュピクチャの符号化スライス、クリーンランダムアクセスピクチャの符号化スライス、ランダムアクセス復号可能リーディングピクチャの符号化スライス、ランダムアクセススキップリーディングピクチャの符号化スライス、ビデオパラメータセット、シーケンスパラメータセット、ピクチャパラメータセット、アクセスユニットデリミタ、シーケンスの最後、ビットストリームの最後、フィラーデータ、および/またはシーケンスエンハンスメント情報メッセージなど、他のカテゴリのデータに対して、他のNALユニットが含まれてもよい。下の表1は、NALユニットコードおよびNALユニットタイプクラスの一例を示すものである。所望に応じて、他のNALユニットタイプが含まれてもよい。加えて、表1に示されるNALユニットに対するNALユニットタイプ値の入れ替えおよび再割り当てが行われることが理解されるべきである。さらに、付加的なNALユニットタイプが追加されてもよい。さらに、いくつかのNALユニットタイプが除去されてもよい。
NALは、ピクチャの内容を表すビデオ符号化レイヤ(video coding layer:VCL)データを、さまざまなトランスポートレイヤ上にマップする能力を提供する。NALユニットは、それぞれ符号化ピクチャまたはその他の関連データを含むかどうかによって、VCLおよび非VCL NALユニットに分類されてもよい。B.ブロス(Bros)、W−J.ハン(Han)、J−R.オーム(Ohm)、G.J.サリバン(Sullivan)、およびT−.ウィーガンド(Wiegand)、「高効率ビデオ符号化(HEVC)テキスト仕様ドラフト8(High efficiency video coding(HEVC)text specification draft 8)」、JCTVC−J10003、ストックホルム(Stockholm)、2012年7月は、本明細書においてその全体が引用により援用される。B.ブロス、W−J.ハン、J−R.オーム、G.J.サリバン、ワン(Wang)、およびT−.ウィーガンド、「高効率ビデオ符号化(HEVC)テキスト仕様ドラフト10(DFISおよび最終コメント招請に対するもの)(High efficiency video coding(HEVC)text specification draft 10(for DFIS & Last Call))」、JCTVC−J10003_v34、ジュネーブ(Geneva)、2013年1月は、本明細書においてその全体が引用により援用される。B.ブロス、W−J.ハン、J−R.オーム、G.J.サリバン、ワン、およびT−.ウィーガンド、「高効率ビデオ符号化(HEVC)テキスト仕様ドラフト10(High efficiency video coding(HEVC)text specification draft 10)」、JCTVC−L1003、ジュネーブ、2013年1月は、本明細書においてその全体が引用により援用される。
ランダムアクセスおよびビットストリームスプライシングを可能にするために、IDRアクセスユニットはイントラピクチャ、すなわちNALユニットストリームにおけるあらゆる前のピクチャを復号することなく復号される符号化ピクチャを含む。加えて、IDRアクセスユニットの存在は、ビットストリーム中の後続ピクチャが、IDRアクセスユニットに復号のために含まれるイントラピクチャより前のピクチャに対する参照を必要としないことを示す。
IDRアクセスユニットは、Iスライスのみを含むIDRピクチャを参照してもよく、IDRピクチャはビットストリームにおいて復号順で第1のピクチャであってもよいし、ビットストリームにおいて後で出現してもよい。各IDRピクチャは、復号順で符号化ビデオシーケンス(coded video sequence:CVS)の第1のピクチャである。IDRピクチャに対する各VCL NALユニットのnal_unit_typeがIDR_W_RADLに等しいとき、そのIDRピクチャは関連RADLピクチャを有してもよい。IDRピクチャに対する各VCL NALユニットのnal_unit_typeがIDR_N_LPに等しいとき、そのIDRピクチャは関連リーディングピクチャを何ら有さない。IDRピクチャは関連RASLピクチャを有さない。
BLAアクセスユニットは、Iスライスのみを含むBLAピクチャを参照してもよく、BLAピクチャはビットストリームにおいて復号順で第1のピクチャであってもよいし、ビットストリームにおいて後で出現してもよい。各BLAピクチャは新たなCVSを開始してもよく、復号プロセスに対してIDRピクチャと同じ効果を有する。しかし、BLAピクチャは空でないRPSを指定するシンタックスエレメントを含む。BLAピクチャに対する各VCL NALユニットのnal_unit_typeがBLA_W_LPに等しいとき、そのBLAピクチャは関連RASLピクチャを有してもよく、その関連RASLピクチャはデコーダから出力されず、かつビットストリームに存在しないピクチャに対する参照を含むかもしれないために復号可能でないことがある。BLAピクチャに対する各VCL NALユニットのnal_unit_typeがBLA_W_LPに等しいとき、そのBLAピクチャはさらに関連RADLピクチャを有してもよく、その関連RADLピクチャは復号されるよう指定されている。BLAピクチャに対する各VCL NALユニットのnal_unit_typeがBLA_W_RADLに等しいとき、そのBLAピクチャは関連RASLピクチャを有さないが、関連RADLピクチャを有してもよい。BLAピクチャに対する各VCL NALユニットのnal_unit_typeがBLA_N_LPに等しいとき、そのBLAピクチャは関連リーディングピクチャを何ら有さない。
クリーンランダムアクセス(clean random access:CRA)ピクチャシンタックスは、ランダムアクセスポイント(random access point:RAP)の位置、すなわちデコーダがビットストリームのより早い位置に出現していた任意のピクチャを復号する必要なくピクチャの復号の開始を成功させることができるビットストリーム内の位置における、イントラピクチャの使用を指定する。ランダムアクセスの支援によって、効果的なチャネル切換え、シーク動作、および動的ストリーミングサービスが可能になる。復号順でCRAピクチャに後続し、かつ表示順(出力順)でCRAピクチャに先行するいくつかのピクチャは、CRAピクチャにおける復号開始のときにデコーダにおいて利用不可能なピクチャに対するインターピクチャ予測参照を含んでいてもよい。これらの復号不可能なピクチャは、CRAポイントにおいて復号プロセスを開始するデコーダによって廃棄される。こうした復号不可能なピクチャは、ランダムアクセススキップリーディング(random access skipped leading:RASL)ピクチャとして識別される。異なる元の符号化ビットストリームからのスプライスポイントの位置は、ブロークンリンクアクセス(broken link access:BLA)ピクチャによって示されてもよい。ビットストリームスプライシング動作は、一方のビットストリームにおけるCRAピクチャのNALユニットタイプを、BLAピクチャを示す値に変更し、他方のビットストリームにおけるRAPピクチャの位置に新たなビットストリームを連結することによって行われてもよい。RAPピクチャはIDR、CRAまたはBLAピクチャであってもよく、ビットストリームにおいてCRAおよびBLAピクチャの両方の後にRASLピクチャが続いてもよく(BLAピクチャに対して用いられるNALユニットタイプの特定の値に依存する)、他方のビットストリームにおけるRAPピクチャの位置に新たなビットストリームを連結する。BLAピクチャに関連する任意のRASLピクチャは、スプライシング動作のためにビットストリームに実際には存在しないピクチャに対する参照を含むため、デコーダによって廃棄される。復号順でRAPピクチャに後続でき、かつ出力順でRAPピクチャに先行できる他のタイプのピクチャは、ランダムアクセス復号可能リーディングピクチャ(random access decodable leading picture:RADL)であり、このピクチャは復号順でRAPピクチャに先行する任意のピクチャに対する参照を含有できない。RASLおよびRADLピクチャは、集合的にリーディングピクチャ(leading pictures:LP)と呼ばれる。復号順および出力順の両方でRAPピクチャに後続するピクチャはトレイリングピクチャとして公知であり、このピクチャはインターピクチャ予測のためのLPに対する参照を含有できない。
複数参照ピクチャ管理に対して、ビットストリーム内の残りのピクチャを復号するために、復号ピクチャバッファ(DPB)(図1Aの参照ピクチャバッファ166および図2Aのフレームメモリ290を参照)には以前復号されたピクチャの特定のセットが存在する必要がある。これらのピクチャを識別するために、各スライスヘッダにおいてピクチャ順序カウント(picture order count:POC)識別子が送信される。pic_order_cnt_lsbシンタックスエレメントは、現ピクチャに対するピクチャ順序カウントをMaxPicOrderCntLsbで割った余りを示す。pic_order_cnt_lsbシンタックスエレメントの長さは、log2_max_pic_order_cnt_lsb_minus4+4ビットである。pic_order_cnt_lsbの値は、両端値を含めて0からMaxPicOrderCntLsb−1までの範囲内である。log2_max_pic_order_cnt_lsb_minus4は、次のとおりにピクチャ順序カウントに対する復号プロセスにおいて用いられる変数MaxPicOrderCntLsbの値を示す。
MaxPicOrderCntLsb=2(log2_max_pic_order_cnt_lsb_minus4+4)(0−1)
log2_max_pic_order_cnt_lsb_minus4の値は、両端値を含めて0から12の範囲内である。
参照ピクチャセット(Reference picture set:RPS)とは、あるピクチャに関連する参照ピクチャのセットであり、復号順で関連ピクチャの前にある、関連ピクチャまたは復号順で関連ピクチャに後続する任意のピクチャのインター予測に用いられるすべての参照ピクチャからなる。図8は、時間予測構造に対する例示的なPOC値、復号順、およびRPSを示す。この実施例において示されるRPS値は、RPSに対する実際のPOC値を示す。他の場合には、POC値の代わりに、現ピクチャのPOCに関するピクチャのPOC値の差と、参照されるピクチャが現ピクチャおよび参照によって使用されるか否かをシグナリングするインジケータとがRPSに保存されてもよい。
IDRピクチャは、復号のためにいかなる以前のピクチャも必要としないため、pic_order_cnt_lsbシンタックスエレメントに対するピクチャ順序カウントは0であると推測されてもよく、よってビットストリームのビットレートが低減する。デコーダ順でピクチャにおける第1のスライスは、first_slice_in_pic_flagが1に等しく設定されることによってシグナリングされる。その結果、1に等しい値を有するシンタックスエレメントfirst_slice_in_pic_flagは、2つまたはそれ以上のIDRピクチャが連続して送られる場合に、IDRピクチャの開始を識別する境界の役割をする。しかし、場合によっては、ビデオレイヤにおいて連続するIDRピクチャに属するスライスを区別することができない。第1のこうした場合とは、デコーダにパケットがばらばらの順序で到着するときである。第2のこうした場合とは、IDRピクチャの第1のスライスを含むパケットが失われたときである。加えて、符号化ビデオシーケンスのすべてのピクチャがIDRピクチャとしてイントラ符号化によってシグナリングされるとき(例、すべてイントラのプロファイルを用いるとき)、すべてのピクチャのpic_order_cnt_lsb値が0となる。よって、デコーダが特定のIDRピクチャと別のIDRピクチャとを識別できるようにするために、システムは各々に対して異なるpic_order_cnt_lsb値をシグナリングする必要がある。加えて、IDRピクチャと類似であり、かつIスライスのみを有するBLAピクチャは、pic_order_cnt_lsbエレメントに対して非ゼロ値をシグナリングできる。
図9を参照すると、ビットストリームの復号におけるデコーダの頑強性を増すために、IDRピクチャに対してpic_order_cnt_lsbシンタックスエレメントをシグナリングする必要がある。図9に示されるスライスヘッダの実施形態において、pic_order_cnt_lsbは、現ピクチャに対するピクチャ順序カウントをMaxPicOrderCntLsbで割った余りを示す。pic_order_cnt_lsbシンタックスエレメントの長さは、log2_max_pic_order_cnt_lsb_minus4+4ビットである。pic_order_cnt_lsbの値は、両端値を含めて0からMaxPicOrderCntLsb−1までの範囲内である。
代替的な技術は、BLAピクチャに対してpic_order_cnt_lsbシンタックスエレメントをシグナリングしないことを含み、よってIDRシグナリングと整合させるためにその値を0であると推測する。その結果、IdrPicFlag導出は、好ましくはBLAをも含むように変更される。加えて、IdrPicFlagは好ましくはIdrBlaPicFlagと再命名される。加えて、好ましくはPicOrderCntValの算出がBLAピクチャに対して修正される。代替的には、IdrPicFlagを維持しながら、新たなフラグIdrBlaPicFlagが含まれてもよい。
一般的に、もしそのピクチャがIDRピクチャであれば、IdrPicFlagは真または1である。そうでなければ、IdrPicFlagは偽または0である。1つの場合に、変数IdrPicFlagは、IdrPicFlag=(nal_unit_type==IDR_W_RADL||nal_unit_type==IDR_N_LP)と示され、ここでnal_unit_typeはNALユニットタイプを示す。
一般的に、もしそのピクチャがIDRピクチャまたはBLAピクチャであれば、IdrBlaPicFlagは真または1である。そうでなければ、IdrBlaPicFlagは偽または0である。1つの場合に、変数IdrBlaPicFlagは、IdrBlaPicFlag=(nal_unit_type==IDR_W_RADL||nal_unit_type==IDR_N_LP||nal_unit_type==BLA_W_LP||nal_unit_type==BLA_W_LP||nal_unit_type==BLA_N_LP)と示され、ここでnal_unit_typeはNALユニットタイプを示す。
この代替的な技術が用いられる理由は、BLAピクチャがIスライスのみを含み、かつビットストリームにおいて復号順で第1のピクチャであるから、またはBLAピクチャがビットストリームにおいて後で出現するからである。前述したとおり、各BLAピクチャは新たな符号化ビデオシーケンスを開始し、復号プロセスに対してIDRピクチャと同じ効果を有する。その結果として、BLAおよびIDRピクチャに対してpic_order_cnt_lsb値をシグナリングする一貫したやり方を有することによって、それらのピクチャがデコーダによって類似の態様で処理されることが可能になる。
図10を参照すると、ビットストリームの復号ならびにIDRおよびBLAピクチャの処理におけるデコーダの一貫性を増すために、IDRピクチャまたはBLAピクチャ以外のピクチャ(例、!IdrBLAPicFlag)のスライスヘッダにおいてpic_order_cnt_lsbシンタックスエレメントがシグナリングされてもよい。
図11を参照すると、ビットストリームの復号ならびにIDRおよびBLAピクチャの処理におけるデコーダの一貫性を増すために、IDRピクチャまたはBLAピクチャ以外のピクチャ(例、!IdrBLAPicFlag)のスライスヘッダにおいてpic_order_cnt_lsbシンタックスエレメントがシグナリングされてもよい。スライスヘッダの残りの部分は、IDRピクチャ以外のピクチャ(例、!IdrPicFlag)に対してシグナリングされてもよい。よって、スライスヘッダの残りの部分は、BLAピクチャに対してシグナリングされてもよい。
図12を参照すると、pic_order_cnt_lsbシンタックスエレメントは、スライスヘッダの最初にあってもよい。pic_order_cnt_lsbフィールドがスライスヘッダの最初にあることによって、スライスの他のシンタックスエレメントを構文解析する前に、そのスライスがどのピクチャに属するかを理解するために、スライスヘッダにおいてそのフィールドを最初にチェックすることがより容易に可能になる。このことは、ピクチャがばらばらの順序で到着するか、および/または失われる可能性のある環境において有用である。
スケーラブルビデオ符号化とは、1つまたはそれ以上のサブセットビットストリームをさらに含むビデオビットストリームを符号化する技術である。サブセットビデオビットストリームは、サブセットビットストリームに必要とされる帯域幅を低減させるために、より大きなビデオからパケットを落とすことによって導出されてもよい。サブセットビットストリームは、より低い空間解像度(より小さいスクリーン)、より低い時間解像度(より低いフレームレート)、またはより低品質のビデオ信号を表してもよい。たとえば、ビデオビットストリームは5つのサブセットビットストリームを含んでもよく、各々のサブセットビットストリームはベースビットストリームに付加的な内容を与える。ハンヌクセラ(Hannuksela)ら、「高効率ビデオ符号化(HEVC)のスケーラブル拡張のためのテストモデル(Test Model for Scalable Extensions of High Efficiency Video Coding(HEVC))」JCTVC−L0453、上海(Shanghai)、2012年10月は、本明細書においてその全体が引用により援用される。チェン(Chen)ら、「SHVCドラフトテキスト1(SHVC Draft Text 1)」、JCTVC−L1008、ジュネーブ、2013年3月は、本明細書においてその全体が引用により援用される。付加的な説明は、J.チェン、J.ボイス(Boyce)、Y.イェ(Ye)、M.M.ハンヌクセラ、「SHVCドラフトテキスト2(SHVC Draft Text 2)」、JCTVC−M1008、仁川(Incheon)、2013年5月;G.テック(Tech)、K.ウェグナー(Wegner)、Y.チェン、M.ハンヌクセラ、J.ボイス、「MV−HEVCドラフトテキスト4(MV−HEVC Draft Text 4)(ISO/IEC 23008−2:201x/PDAM2)」、JCTVC−D1004、仁川、2013年5月;J.チェン、J.ボイス、Y.イェ、M ハンヌクセラ、SHVCドラフト3(SHVC Draft 3)、JCTVC−N1008、ウィーン(Vienna)、2013年8月;およびY.チェン、Y.−K.ワン、A.K.ラマスブロマニアン(Ramasubromanian)、MV−HEVC/SHVC HLS:クロスレイヤPOCアライメント(Cross−layer POC Alignment)、JCTVC−N0244、ウィーン、2013年7月に記載されており、その文献の各々は本明細書においてその全体が引用により援用される。
マルチビュービデオ符号化とは、代替ビューを表す1つまたはそれ以上の他のビットストリームをも含むビデオビットストリームを符号化する技術である。たとえば、多重ビューは立体ビデオのための一対のビューであってもよい。たとえば、多重ビューは異なる視点からの同じシーンの多重ビューを表してもよい。一般的に、多重ビューは大量のインタービュー統計的依存性を含む。なぜなら、それらの画像は異なる視点からの同じシーンの画像だからである。したがって、時間およびインタービュー予測を組み合わせることによって、効率的なマルチビュー符号化を達成できる。たとえば、時間的に関係するフレームだけでなく、近傍の視点のフレームからも効率的にフレームが予測されてもよい。ハンヌクセラら、「スケーラブルおよびマルチビュー拡張のための共通仕様テキスト(Common specification text for scalable and multi−view extensions)」、JCTVC−L0452、ジュネーブ、2013年1月は、本明細書においてその全体が引用により援用される。テックら、「MV−HEVCドラフトテキスト3(MV−HEVC Draft Text 3)(ISO/IEC 23008−2:201x/PDAM2)」、JCT3V−C1004_d3、ジュネーブ、2013年1月は、本明細書においてその全体が引用により援用される。G.テック、K.ウェグナー、Y.チェン、M.ハンヌクセラ、J.ボイス、「MV−HEVCドラフトテキスト5(MV−HEVC Draft Text 5)(ISO/IEC 203008−2:201x/PDAM2)」、JCTVC−E1004、ウィーン、2013年8月は、本明細書においてその全体が引用により援用される。
図13を参照すると、ビデオパラメータセットは、ビデオシーケンスに関係する内容を記述するシンタックスである。ビデオパラメータセットシンタックスは、多くのシンタックスエレメントによって示され、そのシンタックスエレメントのいくつかを以下に説明する。
vps_extension_offsetは、NALユニットの最初から始まる、VPS NALユニット内の固定長符号化情報の次のセットのバイトオフセットを示す。非ベースレイヤまたはビューに対するVPS情報は、VPS NALユニットのバイトアライメントされた位置から始まっていてもよく、セッションネゴシエーションおよび/または能力交換に対する固定長符号化情報を有する。vps_extension_offsetによって示されるバイトオフセットは、次いでエントロピー復号の必要なくVPS NALユニット内の情報を位置付けてその情報にアクセスすることを助ける。
vps_extension_flagが0に等しいことは、VPS RBSPシンタックス構造にvps_extension()シンタックス構造が存在しないことを示す。vps_extension_flagが1に等しいことは、VPS RBSPシンタックス構造にvps_extension()シンタックス構造が存在することを示す。vps_max_layers_minus1が0より大きいとき、vps_extension_flagは1に等しい。
vps_extension2_flagが0に等しいことは、VPS RBSPシンタックス構造にvps_extension_data_flagシンタックスエレメントが存在しないことを示す。デコーダは、VPS NALユニット内のvps_extension2_flagに対する値1に続くデータを無視してもよい。
JCTVC−M1008およびJCT3VD−1004には、以下の制約が含まれる。符号化ピクチャに対するnal_unit_type値nalUnitTypeAがIDR_W_DLP、IDR_N_LP、BLA_W_LP、BLA_W_DLP、またはBLA_N_LPに等しいとき、同じアクセスユニットのすべての符号化ピクチャのすべてのVCL NALユニットに対して、nal_unit_type値がnalUnitTypeAに等しくなる。
アクセスユニット(AU)は、ネットワーク抽象化レイヤ(NAL)ユニットのセットを示し、それらのネットワーク抽象化レイヤ(NAL)ユニットは、指定された分類規則に従って互いに関連付けられており、かつ復号順に連続しており、かつ同じ出力時間に関連するすべての符号化ピクチャのビデオ符号化レイヤ(VCL)NALユニットと、VCL NALユニットに関連する非VCL NALユニットとを含む。ベースレイヤとは、すべてのVCL NALユニットのnuh_layer_idが0に等しいレイヤのことである。符号化ピクチャとはピクチャの符号化表現であって、特定の値のnuh_layer_idを有するVCL NALユニットを含み、かつそのピクチャのすべての符号化ツリーユニットを含む。場合によっては、符号化ピクチャがレイヤコンポーネントと呼ばれることもある。
図14Aは、第2のエンハンスメントレイヤ(EL2)942bがベースレイヤ(BL)944および第1のエンハンスメントレイヤ(EL1)942aよりも低いピクチャレートを有するときの、符号化ピクチャに対するレイヤのネットワーク抽象化レイヤ(NAL)ユニットおよびアクセスユニット(AU)に対する構造およびタイミングを示すブロック図である。EL1符号化ピクチャのNALユニット953aは、第1のエンハンスメントレイヤ(EL1)942aに沿って示される。EL2符号化ピクチャのNALユニット953bは、第2のエンハンスメントレイヤ(EL2)942bに沿って示される。ベースレイヤ符号化ピクチャのNALユニット953cは、ベースレイヤ(BL)944に沿って示される。
時間t1において、EL1符号化ピクチャのNALユニット953a、EL2符号化ピクチャのNALユニット953b、およびベースレイヤ符号化ピクチャのNALユニット953cは、アクセスユニット(AU)955aの一部である。時間t2において、EL1符号化ピクチャのNALユニット953a、およびベースレイヤ符号化ピクチャのNALユニット953cは、アクセスユニット(AU)955bの一部である。時間t3において、EL1符号化ピクチャのNALユニット953a、EL2符号化ピクチャのNALユニット953b、およびベースレイヤ符号化ピクチャのNALユニット953cは、アクセスユニット(AU)955cの一部である。時間t4において、EL1符号化ピクチャのNALユニット953a、およびベースレイヤ符号化ピクチャのNALユニット953cは、アクセスユニット(AU)955dの一部である。
図14Bは、ベースレイヤ(BL)1044が第1のエンハンスメントレイヤ(EL1)1042aおよび第2のエンハンスメントレイヤ(EL2)1042bよりも低いピクチャレートを有するときの、符号化ピクチャに対するレイヤのネットワーク抽象化レイヤ(NAL)ユニットおよびアクセスユニット(AU)に対する構造およびタイミングを示すブロック図である。EL1符号化ピクチャのNALユニット1053aは、第1のエンハンスメントレイヤ(EL1)1042aに沿って示される。EL2符号化ピクチャのNALユニット1053bは、第2のエンハンスメントレイヤ(EL2)1042bに沿って示される。ベースレイヤ符号化ピクチャのNALユニット1053cは、ベースレイヤ(BL)1044に沿って示される。
時間t1において、EL1符号化ピクチャのNALユニット1053a、EL2符号化ピクチャのNALユニット1053b、およびベースレイヤ符号化ピクチャのNALユニット1053cは、アクセスユニット(AU)1055aの一部である。時間t2において、EL1符号化ピクチャのNALユニット1053a、およびEL2符号化ピクチャのNALユニット1053bは、アクセスユニット(AU)1055bの一部である。時間t3において、EL1符号化ピクチャのNALユニット1053a、EL2符号化ピクチャのNALユニット1053b、およびベースレイヤ符号化ピクチャのNALユニット1053cは、アクセスユニット(AU)1055cの一部である。時間t4において、EL1符号化ピクチャのNALユニット1053a、およびEL1符号化ピクチャのNALユニット1053bは、アクセスユニット(AU)1055dの一部である。
図15を参照すると、NALユニットタイプに対するこの制約が図示される。異なるタイプのIDRピクチャ(例、IDR_W_RADL、IDR_N_LP)およびBLAピクチャ(BLA_W_LP、BLA_W_RADLまたはBLA_N_LP)に対して、ベースレイヤ(例、ベースレイヤ0)に関してエンハンスメントレイヤ(例、エンハンスメントレイヤ1、2、3、4)の各々に対して制約が実施される。したがって、もしベースレイヤのピクチャがIDRまたはBLAピクチャのいずれかであれば、同じPicOrderCntValに対するエンハンスメントレイヤの各々も同様に、対応するIDRまたはBLAピクチャである。
ベースレイヤおよびエンハンスメントレイヤ(単数または複数)の使用は、同じビデオストリーム内で一対(またはそれ以上)のビデオストリームを同時放送するために用いられてもよい。この態様で、たとえばベースレイヤ0およびエンハンスメントレイヤ1が第1のビデオストリームであってもよく、エンハンスメントレイヤ2、エンハンスメントレイヤ3、およびエンハンスメントレイヤ4が第2のビデオストリームであってもよい。たとえば、2つのビデオストリームは同じビデオ内容を有するが、異なるベースレイヤおよびエンハンスメントレイヤに対して異なるビットレートを用いてもよい。加えて、それらのビデオストリームは、異なるベースレイヤに対して異なる符号化アルゴリズム(例、HEVC/AVC)を用いてもよい。この態様で、エンハンスメントレイヤ2はエンハンスメントレイヤ1にもベースレイヤ0にも依存しない。加えて、エンハンスメントレイヤ3およびエンハンスメントレイヤ4は、エンハンスメントレイヤ1にもベースレイヤ0にも依存しない。エンハンスメントレイヤ3はエンハンスメントレイヤ2に依存してもよく、エンハンスメントレイヤ4はエンハンスメントレイヤ3およびエンハンスメントレイヤ2の両方に依存してもよい。好ましくは、エンハンスメントレイヤはより小さい番号を有するエンハンスメントレイヤにのみ依存してもよく、より大きい番号を有するエンハンスメントレイヤには依存しない方がよい。
各レイヤに対して、そのレイヤが他のどのレイヤに直接依存するかを示すために、直接依存性フラグを用いて、この特定のエンハンスメントレイヤ依存性がシグナリングされる。たとえばdirect_dependency_flag[1][j]={1}は、エンハンスメントレイヤ1がベースレイヤ0に依存することを示す。たとえばdirect_dependency_flag[2][j]={0,0}は、エンハンスメントレイヤ2が別のレイヤに依存しないことを示す。たとえばdirect_dependency_flag[3][j]={0,0,1}は、エンハンスメントレイヤ3がベースレイヤ0に依存せず、かつエンハンスメントレイヤ1に依存せず、かつエンハンスメントレイヤ2に依存することを示す。たとえばdirect_dependency_flag[4][j]={0,0,1,1}は、エンハンスメントレイヤ4がベースレイヤ0に依存せず、かつエンハンスメントレイヤ1に依存せず、かつエンハンスメントレイヤ2に依存でき、かつエンハンスメントレイヤ3に依存できることを示す。同時放送構成の可能性によって、同時放送構成が用いられるときにIDRおよびBLA周波数が異なることを可能にするために、direct_dependency_flag[i][j]に対する制約が再定義されてもよい。言換えると、IDRおよびBLAの制約は同時放送ストリームの各々に対して制限されてもよいが、同時放送ストリームの各々に対して互いに独立していてもよい。
図16を参照すると、2つのビデオストリームの同時放送が示され、第1のビデオストリームはベースレイヤ0およびエンハンスメントレイヤ1を含み、第2のビデオストリームはエンハンスメントレイヤ2、エンハンスメントレイヤ3、およびエンハンスメントレイヤ4を含む。図示されるとおり、第1のビデオストリームは、PicOrderCntValBの値を有するPicOrderCntValに対するIDR/BLAピクチャの対応する対600、610を含むのに対し、第2のビデオストリームは、PicOrderCntValBの同じ値を有するPicOrderCntValに対するIDR/BLAピクチャの対応するセット620、630、640を含まない。図示されるとおり、第2のビデオストリームはIDR/BLAピクチャの対応するセット650、660、670を含むのに対し、第1のビデオストリームはIDR/BLAピクチャの対応する対680、690を含まない。
図16を参照すると、この柔軟性は特に、たとえばVPS拡張におけるレイヤに対してシグナリングされるdirect_dependency_flag[i][j]値を考慮することなどによって達成されてもよい。各レイヤに対して、すなわちそのレイヤが独立であるか(例、0)、または別のレイヤに依存するか(例、1)に対して変数IndepLayer[i]が定められてもよい。このIndepLayer[i]は次のとおりに導出されてもよい。
したがって、図16に示される実施例に対して、ベースレイヤ0およびエンハンスメントレイヤ2はどちらも独立レイヤである。代替的に、付加的なシンタックスIndepLayer[i]を用いずに、NumDirectRefLayers[i]から独立レイヤが推測されてもよい。たとえば、NumDirectRefLayers[i]が0に等しいとき、IndepLayer[i]は1に等しくなる。さらに、NumDirectRefLayers[i]が0に等しくないとき、IndepLayer[i]は0に等しくなる。
シンタックスにおいて、レイヤの識別子を示すnuh_layer_idは、「特定のPicOrderCntVal値を有し、かつ特定のCVS内にある符号化ピクチャに対するnal_unit_type値nalUnitTypeAがIDR_W_RADL、IDR_N_LP、BLA_W_LP、BLA_W_RADL、またはBLA_N_LPに等しいとき、nal_unit_type値は、同じ特定のPicOrderCntVal値を有し、かつ同じ特定のCVS内にあるすべての符号化ピクチャのすべてのVCL NALユニットに対してnalUnitTypeAに等しくなる」から、前述の同時放送実施形態を可能にするために修正されたセマンティクスに修正される必要がある。nal_unit_typeに対するセマンティクスは、所望に応じて任意の態様で修正されてもよい。
図17を参照すると、ビデオストリームは、ベースレイヤおよび1つまたはそれ以上のエンハンスメントレイヤ(EL1/EL2/EL3)を含んでもよい。各時間(T1/T2/T3/T4/...)に対して別個のアクセスユニットが存在し、そのアクセスユニット内にベースレイヤおよび/またはエンハンスメントレイヤ(単数または複数)に対する符号化ピクチャが存在する。たとえば時間=T1において、対応するアクセスユニットはベースレイヤ、第1のエンハンスメントレイヤ、第2のエンハンスメントレイヤ、および第3のエンハンスメントレイヤに対する符号化ピクチャを含む。たとえば時間=T3において、対応するアクセスユニットは、ベースレイヤおよび第2のエンハンスメントレイヤに対する符号化ピクチャを含むが、第1のエンハンスメントレイヤに対する符号化ピクチャも、第3のエンハンスメントレイヤに対する符号化ピクチャも含まない。たとえば時間T=5において、対応するアクセスユニットは、第1のエンハンスメントレイヤ、第2のエンハンスメントレイヤ、第3のエンハンスメントレイヤに対する符号化ピクチャを含むが、ベースレイヤに対する符号化ピクチャを含まない。符号化ピクチャは、たとえばIDRピクチャ、BLAピクチャ、CRAピクチャ、非IDRピクチャ、非BLAピクチャ、非CRAピクチャ、トレイリングピクチャ、および/またはリーディングピクチャなどであってもよい。J.チェン、J.ボイス、Y.イェ、M ハンヌクセラ、SHVCドラフト3(SHVC Draft 3)、JCTVC−N1008、ウィーン、2013年8月は、セクションF.8.1.1内に適合要件を含んでおり、ビットストリーム適合の要件は、PicOrderCntValがアクセスユニット内で変化しないことである。言換えると、同じアクセスユニット内の各符号化ピクチャは、同じPicOrderCntValを有する。さらに、ベースレイヤ(nuh_layer_id=0)に含まれるIDRピクチャのPicOrderCntValは、0に設定されるか、または0であると推測される。しかし、非ベースレイヤ(nuh_layer_id>0)に対する非IDRピクチャおよびIDRピクチャは、スライスセグメントヘッダにおけるslice_pic_order_cnt_lsbシンタックスエレメントとしてシグナリングされたPOC LSB値を有してもよく、次いでこの値を用いてPicOrderCntValの値が導出される。PicOrderCntValは最上位ビット(most significant bit:MSB)および最下位ビット(least significant bit:LSB)から導出され、ここでLSBがビットストリームにおいてシグナリングされる。たとえばエンハンスメントレイヤの符号化ピクチャなどに対して、LSBは0としてシグナリングされるが、PicOrderCntValは0でないかもしれない。なぜなら、MSBはビットストリーム内で直接シグナリングされるのではなく、ビットストリームから定められるからである。したがって、ベースレイヤのIDRのPicOrderCntValが0であるものとしてシグナリングまたは推測されるときを含み、PicOrderCntValは同じであるがMSBはシンタックス内でシグナリングされないことを保証する方法でシグナルされる、同じアクセスユニット内のすべての符号化ピクチャをもつことが望ましい。
G.テック、K.ウェグナー、Y.チェン、M.ハンヌクセラ、J.ボイス、「MV−HEVCドラフトテキスト5(MV−HEVC Draft Text 5)(ISO/IEC 203008−2:201x/PDAM2)」、JCTVC−E1004、ウィーン、2013年8月;J.チェン、J.ボイス、Y.イェ、M ハンヌクセラ、SHVCドラフト3(SHVC Draft 3)、JCTVC−N1008、ウィーン、2013年8月;およびY.チェン、Y.−K.ワン、A.K.ラマスブロマニアン、MV−HEVC/SHVC HLS:クロスレイヤPOCアライメント(Cross−layer POC Alignment)、JCTVC−N0244、ウィーン、2013年7月は、以下のシンタックスおよびセマンティクスを定義する。
表2
poc_reset_flagが1に等しいことは、現ピクチャに対する導出ピクチャ順序カウントが0に等しいことを示す。poc_reset_flagが0に等しいことは、現ピクチャに対する導出ピクチャ順序カウントが0に等しいことも、等しくないこともあることを示す。ビットストリーム適合の要件は、cross_layer_irap_aligned_flagが1に等しいときに、poc_reset_flagの値が0に等しくなることである。存在しないとき、poc_reset_flagの値は0に等しいと推測される。
slice_segment_headerにおいてシグナリングされるpoc_reset_flagが1に等しいとき、その値は、異なるレイヤの符号化ピクチャのピクチャ順序カウントが適合していない可能性があることを示す。次いで、その不適合を改善するために2つの規則が適用される。第1の規則は、復号ピクチャバッファ内にあり、かつ現ピクチャと同じレイヤに属する各ピクチャのPicOrderCntValをPicOrderCntValだけデクリメントすることである。第2の規則は、PicOrderCntValを0に等しく設定することである。この態様で、もし現PicOrderCntValが0に設定されれば(例、対応するベースレイヤは0のPicOrderCntValを有するIDR画像であり、エンハンスメントレイヤの対応する符号化ピクチャのPicOrderCntValを0に設定することが望ましい)、復号ピクチャバッファのその他のピクチャにそのデクリメントされた量が適用されることにより、それらのピクチャが互いの相対的アライメントを維持する。
しかし、アクセスユニット内のすべての符号化ピクチャに対するPicOrderCntValが同じになることを確実にするために、上の2つの規則では不十分である。このため、現ピクチャに対するpoc_reset_flagが1に等しいときに、0に等しいTemporalIdと、現ピクチャのnuh_layer_idに等しいnuh_layer_idとを有し、かつRASLピクチャでも、RADLピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャであるprevTid0PicのPicOrderCntValの変更が必要とされる。
上記の第1の規則により、現ピクチャのスライスセグメントヘッダにおいてpoc_reset_flagが1に等しくなるようにシグナリングされるときに、現ピクチャと同じレイヤに属するDPB内の各ピクチャのPicOrderCntValのみが現ピクチャに対して算出されたPicOrderCntValだけデクリメントされる。しかし、後続ピクチャのPOCを算出するとき、およびビットストリーム適合に対してprevTid0PicのPicOrderCntlValが使用されるため、poc_reset_flagが1に等しくなるようにシグナリングされるときに、このPicOrderCntValも現ピクチャに対して算出されたPicOrderCntValだけその値をデクリメントすることによって修正する必要がある。これが必要な理由は、場合によってはDPBがprevTid0Pic、すなわち0に等しいTemporalIdと、現ピクチャのnuh_layer_idに等しいnuh_layer_idとを有し、かつRASLピクチャでも、RADLピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャを含まないことがあるからである。たとえば、TemporalIdが0に等しいピクチャがIDRまたはCRAピクチャとして符号化され、かつ低い頻度でしか符号化されないとき、DPB内にprevTid0Picがないことがある。この場合、prevTid0PicはDPB内にないかもしれないが、prevTid0PicのPicOrderCntlValのLSBおよびMSB値は復号プロセスの間追跡されている。この場合、MV−HEVCテキストドラフトJCT3V−E1004およびSHVCテキストドラフトJCTVC−N1008における現在の動作によって、prevTiod0PicのPicOrderCntlValの値が、現ピクチャにおいてリセットされたPOCに対して補償されなくなる。
prevTid0PicのPicOrderCntValの変更を説明したが、意図されるのは、現ピクチャに対してpoc_reset_flagが1に等しくなるようにシグナリングされるときに、以下のタイプのピクチャに対して、PicOrderCntVal値を現ピクチャに対して算出されたPicOrderCntValだけデクリメントすることによってPicOrderCntVal値を同様に補償することが行われるべきだということである。
DPBに存在しないかもしれないが、他の後続ピクチャのPicOrderCntValを正確に算出するために必要とされるPicOrderCntValを有する、任意のピクチャ、
デクリメントすることによって補償される前に、現ピクチャのPicOrderCntValと同じ相対的オフセットを有する値を有することが必要とされるPicOrderCntValを有する、任意のピクチャ。
こうしてこの技術は、現ピクチャのスライスセグメントヘッダにおいてpoc_reset_flagが1に等しくなるようにシグナリングされるときに、上述のとおりのピクチャのPicOrderCntValを、現ピクチャに対して算出されたPicOrderCntValだけデクリメントすることによって、そのPicOrderCntlValを補償する。
加えて、prevTid0PicのPicOrderCntValに関する動作を補正するために、PicOrderCntlVal導出に対する変更が含まれてもよい。
図18を参照すると、レイヤの符号化ピクチャのセットのTemporalIdが例示的に示される。たとえば、符号化ピクチャAはTemporalId=0を有してもよく、かつ符号化ピクチャAは符号化ピクチャB、C、D、E、およびFに対するprevTid0Picである。同様に、prevTid0Picピクチャの役割をするAのPicOrderCntValは、符号化ピクチャB、C、D、E、およびFのPicOrderCntValの算出のために用いられてもよい。たとえば、こうした符号化ピクチャを復号するときに、符号化ピクチャB、C、D、E、および/またはFに対するPicOrderCntValを算出するときに、符号化ピクチャAはDPB内にないことがある。ピクチャAはDPB内に存在しないかもしれないが、ピクチャB、C、D、E、およびFのPicOrderCntValの正確な算出を可能にするように、ピクチャAのPicOrderCntValはデコーダによって追跡されている。したがって、AすなわちprevTid0PicピクチャのPicOrderCntValを適切な態様でデクリメントすることが望ましい。
このデクリメントに加えて、slice_pic_order_cnt_lsbの代わりに導出されたPicOrderCntVal &(MaxPicOrderCntLsb−1)を使用するように、参照ピクチャセットに対する復号プロセスを変更してもよい。poc_reset_flagが1に等しい場合、導出PicOrderCntValはリセットされるため、リセットされた可能性のあるPOCの正しいLSB値を使用するために、この変更が必要である。
さらに、現ピクチャが1に等しいNoRaslOutputFlagを有するIRAPピクチャでないときに、復号ピクチャバッファにおけるこうした変更を説明するために、変数prevPicOrderCntLsbおよびprevPicOrderCntMsbが以下のとおりに導出される。第1に、prevTid0Picは、0に等しいTemporalIdと、現ピクチャのnuh_layer_idに等しいnuh_layer_idとを有し、かつRASLピクチャでも、RADLピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャであるものとし、かつprevPicOrderCntはprevTid0PicのPicOrderCntValに等しいものとする。第2に、変数prevPicOrderCntLsbをprevPicOrderCnt &(MaxPicOrderCntLsb−1)に等しく設定する。第3に、変数prevPicOrderCntMsbをprevPicOrderCnt−prevPicOrderCntLsbに等しく設定する。したがって、PicOrderCntValが0に設定されるとき、新たなPicOrderCntVal値からLSB値を導出することが望ましい。
ピクチャ順序カウントを含む復号プロセスは、現ピクチャのピクチャ順序カウントPicOrderCntValである出力を提供する。ピクチャ順序カウントは、ピクチャの識別、マージモードにおける動きパラメータの導出および動きベクトル予測、ならびにデコーダ適合性チェックのために使用される。各符号化ピクチャは、PicOrderCntValと示されるピクチャ順序カウント変数に関連付けられる。
現ピクチャが1に等しいNoRaslOutputFlagを有するIRAPピクチャでないとき、変数prevPicOrderCntLsbおよびprevPicOrderCntMsbは次のとおりに導出される。
(1)prevTid0Picは、0に等しいTemporalIdと、現ピクチャのnuh_layer_idに等しいnuh_layer_idとを有し、かつRASLピクチャでも、RADLピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャであるものとし、かつprevPicOrderCntはprevTid0PicのPicOrderCntValに等しいものとする。
(2)変数prevPicOrderCntLsbを、prevPicOrderCnt &(MaxPicOrderCntLsb−1)に等しく設定する。
(3)変数prevPicOrderCntMsbを、prevPicOrderCnt−prevPicOrderCntLsbに等しく設定する。
現ピクチャの変数PicOrderCntMsbは、次のとおりに導出される。
(1)もし現ピクチャが1に等しいNoRaslOutputFlagを有するIRAPピクチャであれば、PicOrderCntMsbを0に等しく設定する。
(2)そうでないときは、PicOrderCntMsbを次のとおりに導出する。
PicOrderCntValは、次のとおりに導出される。PicOrderCntVal=PicOrderCntMsb+slice_pic_order_cnt_lsb。なお、すべてのIDRピクチャのPicOrderCntValは0に等しくなる。なぜなら、IDRピクチャに対するslice_pic_order_cnt_lsbは0であると推測され、prevPicOrderCntLsbおよびprevPicOrderCntMsbはどちらも0に等しく設定されるからである。
poc_reset_flagが1に等しいとき、以下のステップがリストされる順序で適用される。
(1)DPB内にあり、かつ現ピクチャと同じレイヤに属する各ピクチャのPicOrderCntValを、PicOrderCntValだけデクリメントする。
(2)0に等しいTemporalIdと、現ピクチャのnuh_layer_idに等しいnuh_layer_idとを有し、かつRASLピクチャでも、RADLピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャであるprevTid0PicのPicOrderCntValを、PicOrderCntValだけデクリメントする。
(3)現ピクチャのRPS内の短期参照ピクチャのPicOrderCntValを、PicOrderCntValだけデクリメントする。
(4)PicOrderCntValを0に等しく設定する。
PicOrderCntValの値は、両端値を含めて−231から231−1までの範囲内となる。1つのCVSにおいて、同じレイヤ内の任意の2つの符号化ピクチャに対するPicOrderCntVal値は、同じにならない。
関数PicOrderCnt(picX)は、PicOrderCnt(picX)=ピクチャpicXのPicOrderCntValと指定される。
関数DiffPicOrderCnt(picA,picB)は、DiffPicOrderCnt(picA,picB)=PicOrderCnt(picA)−PicOrderCnt(picB)と指定される。
ビットストリームは、復号プロセスに用いられるDiffPicOrderCnt(picA,picB)の値が両端値を含めて−215から215−1までの範囲にないような値をもたらすデータは含まない。なお、Xが現ピクチャであるとし、YおよびZが同じシーケンス内の2つの他のピクチャであるとするとき、DiffPicOrderCnt(X,Y)およびDiffPicOrderCnt(X,Z)の両方が正であるか、または両方が負であるときは、YおよびZがXからみて同じ出力順方向にあるものと考えられる。
状況によっては、復号ピクチャバッファに典型的に含まれる1つまたはそれ以上のピクチャが、たとえばピクチャの送信におけるエラーなどの結果として、復号ピクチャバッファの一部になっていないことがある。上に示したとおり、復号エラーを減らし、かつさまざまなピクチャのPicOrderCntVal間の正しい相対的関係を維持するために、こうした状況に適応するために、選択されたprevPicOrderCntをPicOrderCntValだけデクリメントすることが望ましい。
参照ピクチャセットに対する復号プロセスも同様に修正されてもよく、このプロセスは、スライスヘッダの復号の後、任意の符号化ユニットの復号より前、かつスライスに対する参照ピクチャリスト構築のための復号プロセスより前に、ピクチャ当り1回呼び出される。このプロセスの結果として、復号ピクチャバッファ内の1つまたはそれ以上の参照ピクチャが「参照に使用せず」または「長期参照に使用」とマーク付けされてもよい。このマーク付けは同じ値のnuh_layer_idを有するピクチャのみをマーク付けするものであり、現ピクチャと異なるnuh_layer_idを有する任意のピクチャはマーク付けしない。RPSは、現在および将来の符号化ピクチャの復号プロセスにおいて用いられる参照ピクチャの絶対記述である。RPSに含まれるすべての参照ピクチャが明示的にリストされるという意味において、RPSシグナリングは明示的である。
DPB内の復号ピクチャは「参照に使用せず」、「短期参照に使用」、または「長期参照に使用」とマーク付けされるが、復号プロセスの動作中のあらゆる所与の瞬間に、これら3つのうちの1つしかマーク付けされない。これらのマーク付けのうちの1つをあるピクチャに割り当てることによって、適用可能なときにこれらのマーク付けのうちの別のものが暗示的に除去される。ピクチャが「参照に使用」とマーク付けされていることが示されるとき、このことはピクチャが「短期参照に使用」または「長期参照に使用」とマーク付けされている(ただし両方ではない)ことを集合的に示す。
変数currPicLayerIdは、現ピクチャのnuh_layer_idとなるように設定される。
現ピクチャが、1に等しいNoRaslOutputFlagを有するIRAPピクチャであるとき、(もしあれば)現在DPB内に存在するcurrPicLayerIdに等しいnuh_layer_idを有するすべての参照ピクチャが「参照に使用せず」とマーク付けされる。
短期参照ピクチャは、それらのピクチャのPicOrderCntVal値によって識別される。長期参照ピクチャは、それらのピクチャのPicOrderCntVal値またはそれらのピクチャのslice_pic_order_cnt_lsb値のいずれかによって識別される。
RPSを導出するために、ピクチャ順序カウント値の5つのリストが構築される。これら5つのリストは、それぞれNumPocStCurrBefore、NumPocStCurrAfter、NumPocStFoll、NumPocLtCurr、およびNumPocLtFollのエレメント数を有するPocStCurrBefore、PocStCurrAfter、PocStFoll、PocLtCurr、およびPocLtFollである。これら5つのリストおよび5つの変数は、次のとおりに導出される。
もし現ピクチャがIDRピクチャであれば、PocStCurrBefore、PocStCurrAfter、PocStFoll、PocLtCurr、およびPocLtFollはすべて空になるように設定され、かつNumPocStCurrBefore、NumPocStCurrAfter、NumPocStFoll、NumPocLtCurr、およびNumPocLtFollはすべて0に等しく設定される。
そうでないときは、以下が適用される。
ここで、PicOrderCntValは現ピクチャのピクチャ順序カウントである。CurrRpsIdxの値が、両端値を含めて0からnum_short_term_ref_pic_sets−1までの範囲内にあることは、アクティブSPSからの候補短期RPSが用いられていることを示し、ここでCurrRpsIdxは、アクティブSPSにおいてシグナリングされる候補短期RPSのリストに入る候補短期RPSのインデックスである。CurrRpsIdxがnum_short_term_ref_pic_setsに等しいことは、現ピクチャの短期RPSがスライスヘッダにおいて直接シグナリングされることを示す。
両端値を含めて0からNumPocLtCurr−1までの範囲内の各iに対して、CurrDeltaPocMsbPresentFlag[i]が1に等しいとき、次の条件が適用されることがビットストリーム適合の要件である。
PocLtCurr[i]がPocStCurrBefore[j]に等しくなるような、両端値を含めて0からNumPocStCurrBefore−1までの範囲内のjは存在しない。
PocLtCurr[i]がPocStCurrAfter[j]に等しくなるような、両端値を含めて0からNumPocStCurrAfter−1までの範囲内のjは存在しない。
PocLtCurr[i]がPocStFoll[j]に等しくなるような、両端値を含めて0からNumPocStFoll−1までの範囲内のjは存在しない。
jがiに等しくないとき、PocLtCurr[i]がPocLtCurr[j]に等しくなるような、両端値を含めて0からNumPocLtCurr−1までの範囲内のjは存在しない。
両端値を含めて0からNumPocLtFoll−1までの範囲内の各iに対して、FollDeltaPocMsbPresentFlag[i]が1に等しいとき、次の条件が適用されることがビットストリーム適合の要件である。
PocLtFoll[i]がPocStCurrBefore[j]に等しくなるような、両端値を含めて0からNumPocStCurrBefore−1までの範囲内のjは存在しない。
PocLtFoll[i]がPocStCurrAfter[j]に等しくなるような、両端値を含めて0からNumPocStCurrAfter−1までの範囲内のjは存在しない。
PocLtFoll[i]がPocStFoll[j]に等しくなるような、両端値を含めて0からNumPocStFoll−1までの範囲内のjは存在しない。
jがiに等しくないとき、PocLtFoll[i]がPocLtFoll[j]に等しくなるような、両端値を含めて0からNumPocLtFoll−1までの範囲内のjは存在しない。
PocLtFoll[i]がPocLtCurr[j]に等しくなるような、両端値を含めて0からNumPocLtCurr−1までの範囲内のjは存在しない。
両端値を含めて0からNumPocLtCurr−1までの範囲内の各iに対して、CurrDeltaPocMsbPresentFlag[i]が0に等しいとき、次の条件が適用されることがビットストリーム適合の要件である。
PocLtCurr[i]が(PocStCurrBefore[j]&(MaxPicOrderCntLsb−1))に等しくなるような、両端値を含めて0からNumPocStCurrBefore−1までの範囲内のjは存在しない。
PocLtCurr[i]が(PocStCurrAfter[j]&(MaxPicOrderCntLsb−1))に等しくなるような、両端値を含めて0からNumPocStCurrAfter−1までの範囲内のjは存在しない。
PocLtCurr[i]が(PocStFoll[j]&(MaxPicOrderCntLsb−1))に等しくなるような、両端値を含めて0からNumPocStFoll−1までの範囲内のjは存在しない。
jがiに等しくないとき、PocLtCurr[i]が(PocLtCurr[j]&(MaxPicOrderCntLsb−1))に等しくなるような、両端値を含めて0からNumPocLtCurr−1までの範囲内のjは存在しない。
両端値を含めて0からNumPocLtFoll−1までの範囲内の各iに対して、FollDeltaPocMsbPresentFlag[i]が0に等しいとき、次の条件が適用されることがビットストリーム適合の要件である。
PocLtFoll[i]が(PocStCurrBefore[j]&(MaxPicOrderCntLsb−1))に等しくなるような、両端値を含めて0からNumPocStCurrBefore−1までの範囲内のjは存在しない。
PocLtFoll[i]が(PocStCurrAfter[j]&(MaxPicOrderCntLsb−1))に等しくなるような、両端値を含めて0からNumPocStCurrAfter−1までの範囲内のjは存在しない。
PocLtFoll[i]が(PocStFoll[j]&(MaxPicOrderCntLsb−1))に等しくなるような、両端値を含めて0からNumPocStFoll−1までの範囲内のjは存在しない。
jがiに等しくないとき、PocLtFoll[i]が(PocLtFoll[j]&(MaxPicOrderCntLsb−1))に等しくなるような、両端値を含めて0からNumPocLtFoll−1までの範囲内のjは存在しない。
PocLtFoll[i]が(PocLtCurr[j]&(MaxPicOrderCntLsb−1))に等しくなるような、両端値を含めて0からNumPocLtCurr−1までの範囲内のjは存在しない。
変数NumPicTotalCurrが導出される。NumPicTotalCurrの値に対して以下が適用されることが、ビットストリーム適合の要件である。
nuh_layer_idが0に等しく、かつ現ピクチャがBLAピクチャまたはCRAピクチャであるとき、NumPicTotalCurrの値は0に等しくなる。
そうでなければ、現ピクチャがPまたはBスライスを含むとき、NumPicTotalCurrの値は0に等しくならない。
現ピクチャのRPSは、5つのRPSリストからなる。すなわち、RefPicSetStCurrBefore、RefPicSetStCurrAfter、RefPicSetStFoll、RefPicSetLtCurr、およびRefPicSetLtFollである。RefPicSetStCurrBefore、RefPicSetStCurrAfter、およびRefPicSetStFollは、集合的に短期RPSと呼ばれる。RefPicSetLtCurrおよびRefPicSetLtFollは、集合的に長期RPSと呼ばれる。RefPicSetStCurrBefore、RefPicSetStCurrAfter、およびRefPicSetLtCurrは、現ピクチャと、復号順で現ピクチャに続く1つまたはそれ以上のピクチャとのインター予測に用いられるすべての参照ピクチャを含む。RefPicSetStFollおよびRefPicSetLtFollは、現ピクチャのインター予測には用いられないが、復号順で現ピクチャに続く1つまたはそれ以上のピクチャに対するインター予測に用いられるすべての参照ピクチャからなる。
RPSおよびピクチャのマーク付けに対する導出プロセスは、以下の順序ステップに従って行われる。
以下が適用される。
(2)RefPicSetLtCurrおよびRefPicSetLtFollに含まれ、かつnuh_layer_idがcurrPicLayerIdに等しいすべての参照ピクチャは、「長期参照に使用」とマーク付けされる。
(3)以下が適用される。
(4)RefPicSetLtCurr、RefPicSetLtFoll、RefPicSetStCurrBefore、RefPicSetStCurrAfter、またはRefPicSetStFollに含まれず、かつnuh_layer_idがcurrPicLayerIdに等しいDPB内のすべての参照ピクチャは、「参照に使用せず」とマーク付けされる。
RPSリストには、対応するピクチャがDPBに存在しないために「参照ピクチャなし」に等しい1つまたはそれ以上のエントリが存在してもよい。RefPicSetStFollまたはRefPicSetLtFoll内の「参照ピクチャなし」に等しいエントリは、無視されるべきである。RefPicSetStCurrBefore、RefPicSetStCurrAfter、またはRefPicSetLtCurr内の「参照ピクチャなし」に等しい各エントリに対しては、意図的でないピクチャの損失が推測されるべきである。あるピクチャが、5つのRPSリストの2つ以上に含まれることはできない。本明細書に記載される特徴またはエレメントのいずれかが所望に応じて省略されたり、別様に異なる態様で組み換えられたりすることが理解されるべきである。
次に、もういくつかの変形実施形態を説明する。1つの例示的実施形態においては、PicOrderCntValのリセットをシグナリングするためにpoc_reset_flagをシグナリングする代わりに、表(3)に示されるとおりに2つの別個のフラグpoc_msb_reset_flagおよびpoc_lsb_reset_flagがシグナリングされてもよい。
表(3)
poc_msb_reset_flagが1に等しいことは、現ピクチャに対する導出ピクチャ順序カウントのMSB値が0に等しいことを示してもよい。poc_msb_reset_flagが0に等しいことは、現ピクチャに対する導出ピクチャ順序カウントのMSB値が0に等しいことも、等しくないこともあることを示してもよい。
存在しないとき、poc_msb_reset_flagの値は0に等しいと推測されてもよい。
poc_lsb_reset_flagが1に等しいことは、現ピクチャに対する導出ピクチャ順序カウントが0に等しいことを示してもよい。poc_lsb_reset_flagが0に等しいことは、現ピクチャに対する導出ピクチャ順序カウントが0に等しいことも、等しくないこともあることを示してもよい。
存在しないとき、poc_lsb_reset_flagの値は0に等しいと推測されてもよい。
poc_msb_reset_flagの値が0に等しいとき、poc_lsb_reset_flagの値は0に等しいことが要求されてもよい。
次いで、PicOrderCntValに対する復号プロセスが次のとおりに修正されてもよい。
現ピクチャが1に等しいNoRaslOutputFlagを有するIRAPピクチャではないとき、変数prevPicOrderCntLsbおよびprevPicOrderCntMsbは、以下のとおりに導出される。第1に、prevTid0Picは、0に等しいTemporalIdと、現ピクチャのnuh_layer_idに等しいnuh_layer_idとを有し、かつRASLピクチャでも、RADLピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャであるものとし、かつprevPicOrderCntはprevTid0PicのPicOrderCntValに等しいものとする。第2に、変数prevPicOrderCntLsbをprevPicOrderCnt &(MaxPicOrderCntLsb−1)に等しく設定する。第3に、変数prevPicOrderCntMsbをprevPicOrderCnt−prevPicOrderCntLsbに等しく設定する。したがって、PicOrderCntValが0に設定されるとき、新たなPicOrderCntVal値からLSB値を導出することが望ましい。
ピクチャ順序カウントを含む復号プロセスは、現ピクチャのピクチャ順序カウントPicOrderCntValである出力を提供する。ピクチャ順序カウントは、ピクチャの識別、マージモードにおける動きパラメータの導出および動きベクトル予測、ならびにデコーダ適合性チェックのために使用される。各符号化ピクチャは、PicOrderCntValと示されるピクチャ順序カウント変数に関連付けられる。
現ピクチャが1に等しいNoRaslOutputFlagを有するIRAPピクチャではないとき、変数prevPicOrderCntLsbおよびprevPicOrderCntMsbは、以下のとおりに導出される。
(1)prevTid0Picは、0に等しいTemporalIdと、現ピクチャのnuh_layer_idに等しいnuh_layer_idとを有し、かつRASLピクチャでも、RADLピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャであるものとし、かつprevPicOrderCntはprevTid0PicのPicOrderCntValに等しいものとする。
(2)変数prevPicOrderCntLsbを、prevPicOrderCnt &(MaxPicOrderCntLsb−1)に等しく設定する。
(3)変数prevPicOrderCntMsbを、prevPicOrderCnt−prevPicOrderCntLsbに等しく設定する。
現ピクチャの変数PicOrderCntMsbは、次のとおりに導出される。
(1)もし現ピクチャが1に等しいNoRaslOutputFlagを有するIRAPピクチャであれば、PicOrderCntMsbを0に等しく設定する。
(2)そうでないときは、PicOrderCntMsbを次のとおりに導出する。
PicOrderCntValは、次のとおりに導出される。PicOrderCntVal=(poc_msb_reset_flag?0:PicOrderCntMsb)+(poc_lsb_reset_flag?0:slice_pic_order_cnt_lsb)。
なお、0に等しいnuh_layer_idを有するすべてのIDRピクチャのPicOrderCntValは0に等しくなる。なぜなら、IDRピクチャに対するslice_pic_order_cnt_lsbは0であると推測され、prevPicOrderCntLsbおよびprevPicOrderCntMsbはどちらも0に等しく設定されるからである。
poc_reset_flagが1に等しいときは、以下のステップが適用される。
(1)poc_msb_reset_flagが1に等しいとき、DPB内にあり、かつ現ピクチャと同じレイヤに属する各ピクチャのPicOrderCntValを、PicOrderCntMsbだけデクリメントする。
(2)poc_msb_reset_flagが1に等しいとき、0に等しいTemporalIdと、現ピクチャのnuh_layer_idに等しいnuh_layer_idとを有し、かつRASLピクチャでも、RADLピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャであるprevTid0PicのPicOrderCntValを、PicOrderCntMsbだけデクリメントする。
(3)poc_msb_reset_flagが1に等しいとき、現ピクチャのRPS内の短期参照ピクチャのPicOrderCntValを、PicOrderCntMsbだけデクリメントする。
(4)poc_lsb_reset_flagが1に等しいとき、DPB内にあり、かつ現ピクチャと同じレイヤに属する各ピクチャのPicOrderCntValを、slice_pic_order_cnt_lsbだけデクリメントする。
(5)poc_lsb_reset_flagが1に等しいとき、0に等しいTemporalIdと、現ピクチャのnuh_layer_idに等しいnuh_layer_idとを有し、かつRASLピクチャでも、RADLピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャであるprevTid0PicのPicOrderCntValを、slice_pic_order_cnt_lsbだけデクリメントする。
(6)poc_lsb_reset_flagが等しいとき、現ピクチャのRPS内の短期参照ピクチャのPicOrderCntValを、slice_pic_order_cnt_lsbだけデクリメントする。
PicOrderCntValの値は、両端値を含めて−231から231−1までの範囲内となる。1つのCVSにおいて、同じレイヤ内の任意の2つの符号化ピクチャに対するPicOrderCntVal値は、同じにならない。
関数PicOrderCnt(picX)は、PicOrderCnt(picX)=ピクチャpicXのPicOrderCntValと指定される。
関数DiffPicOrderCnt(picA,picB)は、DiffPicOrderCnt(picA,picB)=PicOrderCnt(picA)−PicOrderCnt(picB)と指定される。
ビットストリームは、復号プロセスに用いられるDiffPicOrderCnt(picA,picB)の値が両端値を含めて−215から215−1までの範囲にないような値をもたらすデータは含まない。なお、Xが現ピクチャであるとし、YおよびZが同じシーケンス内の2つの他のピクチャであるとするとき、DiffPicOrderCnt(X,Y)およびDiffPicOrderCnt(X,Z)の両方が正であるか、または両方が負であるときは、YおよびZがXからみて同じ出力順方向にあるものと考えられる。
次に、別の変形実施形態を説明する。1つの例示的実施形態においては、クロスレイヤPOCアライメントを達成するために、32ビットPOCデクリメント値がシグナリングされてもよい。たとえば、表(4)に示されるとおり、この32ビットPOCデクリメント値は、ベースレイヤIDRピクチャのスライスヘッダ拡張においてシグナリングされてもよい。
表(4)
「slice_segment_header_extension_length」は、slice_segment_header_extension_length自身をシグナリングするために用いられるビットを含まない、スライスセグメントヘッダ拡張データの長さをバイト数で示してもよい。nuh_layer_idおよびcross_layer_irap_aligned_flagの両方が0に等しいとき、IDR_W_RADLおよびIDR_N_LP NALユニットに対するslice_segment_header_extension_lengthは4以上になることが、ビットストリーム適合の要件である。slice_segment_header_extension_lengthの値は、両端値を含めて0から256までの範囲内となる。
「poc_decrement」は、現ピクチャに対して用いられるべきピクチャ順序カウントデクリメントを示してもよい。存在しないとき、poc_decrementの値は0に等しいと推測される。
次いで、PicOrderCntValに対する復号プロセスが次のとおりに修正されてもよい。
現ピクチャが1に等しいNoRaslOutputFlagを有するIRAPピクチャではないとき、変数prevPicOrderCntLsbおよびprevPicOrderCntMsbは、以下のとおりに導出される。第1に、prevTid0Picは、0に等しいTemporalIdと、現ピクチャのnuh_layer_idに等しいnuh_layer_idとを有し、かつRASLピクチャでも、RADLピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャであるものとし、かつprevPicOrderCntはprevTid0PicのPicOrderCntValに等しいものとする。第2に、変数prevPicOrderCntLsbをprevPicOrderCnt &(MaxPicOrderCntLsb−1)に等しく設定する。第3に、変数prevPicOrderCntMsbをprevPicOrderCnt−prevPicOrderCntLsbに等しく設定する。したがって、PicOrderCntValが0に設定されるとき、新たなPicOrderCntVal値からLSB値を導出することが望ましい。
ピクチャ順序カウントを含む復号プロセスは、現ピクチャのピクチャ順序カウントPicOrderCntValである出力を提供する。ピクチャ順序カウントは、ピクチャの識別、マージモードにおける動きパラメータの導出および動きベクトル予測、ならびにデコーダ適合性チェックのために使用される。各符号化ピクチャは、PicOrderCntValと示されるピクチャ順序カウント変数に関連付けられる。
現ピクチャが1に等しいNoRaslOutputFlagを有するIRAPピクチャではないとき、変数prevPicOrderCntLsbおよびprevPicOrderCntMsbは、以下のとおりに導出される。
(1)prevTid0Picは、0に等しいTemporalIdと、現ピクチャのnuh_layer_idに等しいnuh_layer_idとを有し、かつRASLピクチャでも、RADLピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャであるものとし、かつprevPicOrderCntはprevTid0PicのPicOrderCntValに等しいものとする。
(2)変数prevPicOrderCntLsbを、prevPicOrderCnt &(MaxPicOrderCntLsb−1)に等しく設定する。
(3)変数prevPicOrderCntMsbを、prevPicOrderCnt−prevPicOrderCntLsbに等しく設定する。
現ピクチャの変数PicOrderCntMsbは、次のとおりに導出される。
(1)もし現ピクチャが1に等しいNoRaslOutputFlagを有するIRAPピクチャであれば、PicOrderCntMsbを0に等しく設定する。
(2)そうでないときは、PicOrderCntMsbを次のとおりに導出する。
PicOrderCntValは、次のとおりに導出される。PicOrderCntVal=PicOrderCntMsb+slice_pic_order_cnt_lsb。
なお、すべてのIDRピクチャのPicOrderCntValは0に等しくなる。なぜなら、IDRピクチャに対するslice_pic_order_cnt_lsbは0であると推測され、prevPicOrderCntLsbおよびprevPicOrderCntMsbはどちらも0に等しく設定されるからである。
poc_reset_flagが1に等しいとき、以下のステップが適用される。
(1)DPB内にある各ピクチャのPicOrderCntValを、poc_decrementだけデクリメントする。
(2)0に等しいTemporalIdと、現ピクチャのnuh_layer_idに等しいnuh_layer_idとを有し、かつRASLピクチャでも、RADLピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャであるprevTid0PicのPicOrderCntValを、poc_decrementだけデクリメントする。
PicOrderCntValの値は、両端値を含めて−231から231−1までの範囲内となる。1つのCVSにおいて、同じレイヤ内の任意の2つの符号化ピクチャに対するPicOrderCntVal値は、同じにならない。
関数PicOrderCnt(picX)は、PicOrderCnt(picX)=ピクチャpicXのPicOrderCntValと指定される。
関数DiffPicOrderCnt(picA,picB)は、DiffPicOrderCnt(picA,picB)=PicOrderCnt(picA)−PicOrderCnt(picB)と指定される。
ビットストリームは、復号プロセスに用いられるDiffPicOrderCnt(picA,picB)の値が両端値を含めて−215から215−1までの範囲にないような値をもたらすデータは含まない。なお、Xが現ピクチャであるとし、YおよびZが同じシーケンス内の2つの他のピクチャであるとするとき、DiffPicOrderCnt(X,Y)およびDiffPicOrderCnt(X,Z)の両方が正であるか、または両方が負であるときは、YおよびZがXからみて同じ出力順方向にあるものと考えられる。
上述のすべての実施形態において、現ピクチャに対するビットストリーム適合性をチェックするときには、0に等しいTemporalIdと、現ピクチャのnuh_layer_idに等しいnuh_layer_idとを有し、かつRASLピクチャでも、RADLピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャであるprevTid0Picの、(デクリメントによって)修正されたPicOrderCntVal値が用いられる。
さらに別の代替的実施形態においては、標準仕様に対するビットストリームの適合を確認するために、以下のプロセスが行われてもよい。
この明細書に従う符号化データのビットストリームは、この従属節に示されるすべての要件を満たす。
ビットストリームは、この付加文書以外のこの明細書において示されるシンタックス、セマンティクス、および制約に従って構築される。
ビットストリーム内の第1の符号化ピクチャはIRAPピクチャ、すなわちIDRピクチャ、CRAピクチャまたはBLAピクチャである。
従属節C.1に示されるとおり、ビットストリームの適合性が、HRDによってテストされる。
現ピクチャの各々に対して、変数maxPicOrderCntおよびminPicOrderCntを、以下のピクチャのPicOrderCntVal値のそれぞれ最大値および最小値に等しく設定する。
現ピクチャ。
0に等しいTemporalIdを有し、かつRASLピクチャでも、RADLピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャ。このピクチャのPicOrderCntlValは、次のとおりに導出される。
(1)現ピクチャに対するpoc_reset_flagが1に等しいとき、0に等しいTemporalIdを有し、かつRASLピクチャでも、RADLピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャのPicOrderCntValを、現ピクチャのPicOrderCntValだけデクリメントする。
(2)現ピクチャに対するpoc_msb_reset_flagが1に等しいとき、0に等しいTemporalIdを有し、かつRASLピクチャでも、RADLピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャのPicOrderCntValを、現ピクチャのPicOrderCntMsbだけデクリメントする。
(3)現ピクチャに対するpoc_lsb_reset_flagが1に等しいとき、0に等しいTemporalIdを有し、かつRASLピクチャでも、RADLピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャのPicOrderCntValを、現ピクチャのslice_pic_order_cnt_lsbだけデクリメントする。
(4)poc_decrement値が0より大きいとき、0に等しいTemporalIdを有し、かつRASLピクチャでも、RADLピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャのPicOrderCntValを、poc_decrement_valueだけデクリメントする。
(5)JCTVC−L1003文書に記載されるとおりにピクチャ順序カウントの復号プロセスに基づいてdecrValue値を算出した後に、現ピクチャのPicOrderCntValをdecrValue値だけデクリメントしたとき、次いで、0に等しいTemporalIdを有し、かつRASLピクチャでも、RADLピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャのPicOrderCntValを、decrValue値だけデクリメントする。
現ピクチャのRPS内の短期参照ピクチャ。
currPicが現ピクチャであるとき、1に等しいPicOutputFlagと、AuCpbRemovalTime[currPic]より小さいAuCpbRemovalTime[n]と、AuCpbRemovalTime[currPic]以上のDpbOutputTime[n]とを有するすべてのピクチャn。
現ピクチャの各々に対して、maxPicOrderCnt−minPicOrderCntの値がMaxPicOrderCntLsb/2より小さくなることが、ビットストリーム適合の要件である。
前述の明細書において使用されている用語および表現は、限定ではなく説明のための用語として用いられるものであり、こうした用語および表現の使用において、図示および記載される特徴の均等物またはその特徴の一部を除外することは意図されておらず、本発明の範囲は以下の請求項によってのみ定義および限定されることが認識される。