(57)【特許請求の範囲】
【請求項１】
参照ピクチャセット（ＲＰＳ）を含む高効率動画像符号化方式（ＨＥＶＣ）の動画シーケンスの符号化方法（１０００）であって、
前記ＲＰＳをシーケンス・パラメータ・セット（ＳＰＳ）内に復号順に配列し（１００１）、
インター予測を前記ＳＰＳに含まれる前記ＲＰＳの現ＲＰＳのために利用する場合、前記現ＲＰＳは復号順で前記現ＲＰＳの直前のＲＰＳからインター予測されると推定し、
インター予測を前記動画シーケンスの現ピクチャのＲＰＳのために利用するかどうかを判定し（１００２）、
前記現ピクチャの前記ＲＰＳのために明示的ＲＰＳ送信が利用されるかどうかを判定し（１００３）、
インター予測及び明示的ＲＰＳ送信が前記現ピクチャの前記ＲＰＳのインター予測のために利用される場合にのみ、前記現ピクチャの前記ＲＰＳをインター予測するために利用されるべき前記ＳＰＳ内に含まれるＲＰＳを示す情報（１２２０）を符号化する（１００４）
ことを含む方法。
【請求項２】
前記ＳＰＳ内に配列された前記ＲＰＳのうちの少なくとも１つのＲＰＳは、復号順で前記少なくとも１つのＲＰＳの直前のＲＰＳからインター予測される、請求項１に記載の方法。
【請求項３】
前記ＳＰＳ内に含まれる各ＲＰＳに対してインデックスを割り当てることを更に含み、
前記インデックスは０から前記ＳＰＳ内に含まれるＲＰＳ数−１の範囲の値を取り、前記現ピクチャの前記ＲＰＳをインター予測するために使用されるべきＲＰＳを示す前記情報は、前記現ピクチャの前記ＲＰＳのインデックスとインター予測に利用される前記ＲＰＳのインデックスとの間の差分を特定する、請求項１または２に記載の方法。
【請求項４】
明示的ＲＰＳ送信が利用されるかどうかの前記判定（１００３）は、前記現ピクチャの前記ＲＰＳのインデックスが、前記ＳＰＳ内に含まれるＲＰＳの数と等しいかどうかの判定を含む、請求項１に記載の方法。
【請求項５】
明示的ＲＰＳ送信が利用されるかどうかの前記判定（１００３）は、前記現ピクチャの前記ＲＰＳが、前記現ピクチャのスライスヘッダ内で符号化されているかどうかの判定を含む、請求項１乃至３のいずれか１項に記載の方法。
【請求項６】
コンピュータプログラムコードを含むコンピュータプログラム（１２０３）であって、前記コンピュータプログラムコードは、プロセッサ（１２０１）上で実行された場合に、請求項１乃至５のいずれか１項に記載の方法を実行するように適合されている、コンピュータプログラム。
【請求項７】
請求項６に記載のコンピュータプログラム（１２０３）を記憶したコンピュータ可読記憶媒体（１２０２）。
【請求項８】
参照ピクチャセット（ＲＰＳ）を含む高効率動画像符号化方式（ＨＥＶＣ）の動画シーケンスの復号方法（１１００）であって、
復号順に配列された前記ＲＰＳを含むシーケンス・パラメータ・セット（ＳＰＳ）を受信し（１１０１）、
インター予測を前記ＳＰＳに含まれる前記ＲＰＳの現ＲＰＳのために利用する場合、前記現ＲＰＳは復号順で前記現ＲＰＳの直前のＲＰＳからインター予測されると推定し、
インター予測を前記動画シーケンスの現ピクチャのＲＰＳのために利用するかどうかを判定し（１００２）、
前記現ピクチャの前記ＲＰＳのために明示的ＲＰＳ送信が利用されるかどうかを判定し（１１０３）、
インター予測及び明示的ＲＰＳ送信が前記現ピクチャの前記ＲＰＳのインター予測のために利用される場合にのみ、前記現ピクチャの前記ＲＰＳをインター予測するために利用されるべき前記ＳＰＳ内に含まれるＲＰＳを示す情報を受信する（１１０４）、
ことを含む方法。
【請求項９】
復号順で直前のＲＰＳから少なくとも１つのＲＰＳをインター予測することを更に含む、請求項８に記載の方法。
【請求項１０】
前記ＳＰＳ内に含まれる各ＲＰＳに対してインデックスが割り当てられ、
前記インデックスは０から前記ＳＰＳ内に含まれるＲＰＳ数−１の範囲を取り、前記現ピクチャの前記ＲＰＳをインター予測するために使用されるべきＲＰＳを示す前記情報は、前記現ピクチャの前記ＲＰＳのインデックスとインター予測に利用される前記ＲＰＳのインデックスとの間の差分を特定する、請求項８又は９に記載の方法。
【請求項１１】
明示的ＲＰＳ送信が利用されるかどうかの前記判定（１１０３）は、前記現ピクチャの前記ＲＰＳのインデックスが、前記ＳＰＳ内に含まれるＲＰＳの数と等しいかどうかの判定を含む、請求項８に記載の方法。
【請求項１２】
明示的ＲＰＳ送信が利用されるかどうかの前記判定（１１０３）は、前記現ピクチャの前記ＲＰＳが、前記現ピクチャのスライスヘッダ内で符号化されているかどうかの判定を含む、請求項８乃至１０のいずれか１項に記載の方法。
【請求項１３】
コンピュータプログラムコードを含むコンピュータプログラム（１２１３）であって、前記コンピュータプログラムコードは、プロセッサ（１２１１）上で実行された場合に、請求項８乃至１２のいずれか１項に記載の方法を実行するように適合されている、コンピュータプログラム。
【請求項１４】
請求項１３に記載のコンピュータプログラム（１２１３）を記憶したコンピュータ可読記憶媒体（１２１２）。
【請求項１５】
参照ピクチャセット（ＲＰＳ）を含む高効率動画像符号化方式（ＨＥＶＣ）の動画シーケンスを符号化するエンコーダ（１２００）であって、プロセッサ（１２０１）及び前記プロセッサにより実行可能な命令を含むメモリ（１２０２）とを備え、
前記ＲＰＳを復号順にシーケンス・パラメータ・セット（ＳＰＳ）内に配列し、
インター予測を前記ＳＰＳに含まれる前記ＲＰＳの現ＲＰＳのために利用する場合、前記現ＲＰＳは復号順で前記現ＲＰＳの直前のＲＰＳからインター予測されると推定し、
インター予測を前記動画シーケンスの現ピクチャのＲＰＳのために利用するかどうかを判定し（１００２）、
前記現ピクチャの前記ＲＰＳのために明示的ＲＰＳ送信が利用されるかどうかを判定し、
インター予測及び明示的ＲＰＳ送信が前記現ピクチャの前記ＲＰＳのインター予測のために利用される場合にのみ、前記現ピクチャの前記ＲＰＳをインター予測するために利用されるべき前記ＳＰＳ内に含まれるＲＰＳを示す情報（１２２０）を符号化する
ように動作可能であるエンコーダ。
【請求項１６】
前記ＳＰＳ内に配列された前記ＲＰＳのうちの少なくとも１つのＲＰＳは、復号順で前記少なくとも１つのＲＰＳの直前のＲＰＳからインター予測される、請求項１５に記載のエンコーダ。
【請求項１７】
前記ＳＰＳ内に含まれる各ＲＰＳに対してインデックスを割り当てるように更に動作可能であって、
前記インデックスは０から前記ＳＰＳ内に含まれるＲＰＳ数−１の範囲の値を取り、前記現ピクチャの前記ＲＰＳをインター予測するために使用されるべきＲＰＳを示す前記情報は、前記現ピクチャの前記ＲＰＳのインデックスとインター予測に利用される前記ＲＰＳのインデックスとの間の差分を特定する、請求項１５又は１６に記載のエンコーダ。
【請求項１８】
前記現ピクチャの前記ＲＰＳのインデックスが、前記ＳＰＳ内に含まれるＲＰＳの数と等しいかどうかを判定することにより、明示的ＲＰＳ送信が利用されるかどうかを判定するように更に動作可能である、請求項１５に記載のエンコーダ。
【請求項１９】
前記現ピクチャの前記ＲＰＳが、前記現ピクチャのスライスヘッダ内で符号化されているかどうかを判定することにより、明示的ＲＰＳ送信が利用されるかどうかを判定するように更に動作可能である、請求項１５乃至１７のいずれか１項に記載のエンコーダ。
【請求項２０】
参照ピクチャセット（ＲＰＳ）を含む高効率動画像符号化方式（ＨＥＶＣ）の動画シーケンスを復号するためのデコーダ（１２１０）であって、プロセッサ（１２１１）及び前記プロセッサにより実行可能な命令を含むメモリ（１２１２）とを備え、
復号順に配列された前記ＲＰＳを含むシーケンス・パラメータ・セット（ＳＰＳ）を受信し、
インター予測を前記ＳＰＳに含まれる前記ＲＰＳの現ＲＰＳのために利用する場合、前記現ＲＰＳは復号順で前記現ＲＰＳの直前のＲＰＳからインター予測されると推定し、
インター予測を前記動画シーケンスの現ピクチャのＲＰＳのために利用するかどうかを判定し（１００２）、
前記現ピクチャの前記ＲＰＳのために明示的ＲＰＳ送信が利用されるかどうかを判定し、
インター予測及び明示的ＲＰＳ送信が前記現ピクチャの前記ＲＰＳのインター予測のために利用される場合にのみ、前記現ピクチャの前記ＲＰＳをインター予測するために利用されるべき前記ＳＰＳ内に含まれるＲＰＳを示す情報（１２２０）を受信する
ように動作可能であるデコーダ。
【請求項２１】
復号順で直前のＲＰＳから少なくとも１つのＲＰＳをインター予測するように更に動作可能である、請求項２０に記載のデコーダ。
【請求項２２】
前記ＳＰＳ内に含まれる各ＲＰＳに対してインデックスが割り当てられ、
前記インデックスは０から前記ＳＰＳ内に含まれるＲＰＳ数−１の範囲の値を取り、前記現ピクチャの前記ＲＰＳをインター予測するために使用されるべきＲＰＳを示す前記情報は、前記現ピクチャの前記ＲＰＳのインデックスとインター予測に利用される前記ＲＰＳのインデックスとの間の差分を特定する、請求項２０又は２１に記載のデコーダ。
【請求項２３】
前記現ピクチャの前記ＲＰＳのインデックスが、前記ＳＰＳ内に含まれるＲＰＳの数と等しいかどうかを判定することにより、明示的ＲＰＳ送信が利用されるかどうかを判定するように更に動作可能である、請求項２０に記載のデコーダ。
【請求項２４】
前記現ピクチャの前記ＲＰＳが、前記現ピクチャのスライスヘッダ内で符号化されているかどうかを判定することにより、明示的ＲＰＳ送信が利用されるかどうかを判定するように更に動作可能である、請求項２０乃至２２のいずれか１項に記載のデコーダ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、参照ピクチャセット（ＲＰＳ）を含む動画シーケンスの符号化方法、ＲＰＳを含む動画シーケンスの復号方法、対応するコンピュータプログラム及びコンピュータプログラム製品、対応するエンコーダ及び対応するデコーダに関連する。
【背景技術】
【０００２】
高効率動画符号化（ＨＥＶＣ）は、ＪＣＴ−ＶＣ（Joint Collaborative Team - Video Coding）において現在策定されている新しい動画像符号化規格である。ＪＣＴ−ＶＣは、ＭＰＥＧ（the Moving Picture Experts Group）とＩＴＵ−Ｔ（the Telecommunication Standardization Sector of the International Telecommunication Union）との間の共同プロジェクトである。現在、委員会草案は、ＨＥＶＣを従来の動画像符号化規格、特にＨ．２６４／ＡＶＣよりも遙かに効率的なものにするための多数の新しいツールを含めることを定めている。
【０００３】
ＨＥＶＣはインター予測のために複数の参照ピクチャを利用するハイブリッドコーデックである。ＨＥＶＣは、ピクチャマーキング処理を含み、そこでは参照ピクチャに「短期参照に使用」、「長期参照に使用」または「参照に未使用」とマーキングすることができる。「参照に未使用」とマーキングされた場合、当該参照ピクチャは非参照ピクチャとなり、もはやインター予測のために利用することはできない。「参照に未使用」とマーキングされたピクチャを、短期或いは長期参照用に使用されるものとして後で再マーキングすることはできない。
【０００４】
ＨＥＶＣにおけるマーキング処理は、ＲＰＳにより制御される。ＲＰＳは参照ピクチャを識別するピクチャ識別子のセットである。ＲＰＳは各スライス内で送信され、ＲＰＳ内で指定された参照ピクチャはデコーダ・ピクチャ・バッファ（ＤＰＢ）内に保持され、「短期参照に使用」または「長期参照に使用」とマーキングされる。
【０００５】
例えば、ＲＰＳ情報は「−４、−６、４」といった値を含んでも良い。これは、現ピクチャが、数字−４が現在を表しているので、（表示順で）４フレーム前のピクチャから予測、即ち画素をコピーできることを意味する。また、６フレーム前のピクチャと、４フレーム先のピクチャから予測することもできる。このように、デコーダは上述の３つの画像を除いた全ての画像をバッファから破棄することができる。ピクチャを破棄することはデコーダにとっては負担のかかる方法である。実際には、デコーダはこれらの画像を、表示されるまで保持していても良いが、インター予測に再び用いられることはない。簡単のため、本明細書の以降の記載では、デコーダがこれらの画像を破棄できるものとして説明する。
【０００６】
時に、ＲＰＳに含まれる情報はむしろ長くなり得る。例えば、以下のＲＰＳは、ＨＥＶＣの規格策定においてテスト目的で使用された：「−３、−２、１、２、５、６」。この例のＲＰＳを符号化するには最大３３ビット必要となるであろうが、特に非常に低ビットレートの画像や小さいサイズの画像にとっては、これは顕著な量である。
【０００７】
１つの鍵となる見解は、ＲＰＳは典型的には、完全にランダムではない。むしろ、それらは何度も何度も再利用することができる。例えば、ＨＥＶＣ規格策定においてテスト目的で使用されコンフィグレーションファイルから１８個の画像のシーケンスについて考える。
【０００８】
ＨＥＶＣのピクチャは、フルＰＯＣ値としても知られるピクチャ・オーダ・カウント（ＰＯＣ）値（PicOrderCntVal）により識別される。これらの数は、ピクチャの出力順序を表しており、或いは表示順序としても引用される。即ち、ＰＯＣ＝５７のピクチャは、ＰＯＣ＝５６のピクチャの直後に表示されるであろう。しかしながら、画像は必ずしも表示順序で送信されるわけではない。例えば、エンコーダはＰＯＣ＝０のピクチャを最初に送信し、その後ＰＯＣ＝８、続いてＰＯＣ＝４といった具合で送信するかもしれない。デコーダはピクチャの順序を記録し、正しい順序で表示しなければならない。ＨＥＶＣ規格策定における例では、１８ピクチャは図１に示す順序で送信されている。
【０００９】
図１から分かるように、いくつかのＲＰＳは何回か送信されている。例えば、ＰＯＣ＝６について送信されたＲＰＳ（−２、−４、−６、２）は、ＰＯＣ＝１４のものと同一である。よって、規格はスライスヘッダでＲＰＳを送信するのに加えて、シーケンス・パラメータ・セット（ＳＰＳ）でＲＰＳを送信することを許可している。ＳＰＳは、全てのスライスについて送信する必要のないデータを含む。典型的に、ＳＰＳはシーケンス毎に１回だけ送信されるか、或いは、ランダムアクセスの可能性が希望される度に送信される。例えば、ビットストリームがブロードキャストされた場合、ＳＰＳを毎秒送信すれば足りるであろう。これによりチャネルを毎秒切り替えることが可能になるためである。なお、チャネルを毎秒切り替えることを可能とするために、クリーン・ランダム・アクセス（ＣＲＡ）ピクチャや瞬時復号更新（ＩＤＲ）ピクチャは、毎秒送信されなければならないことに注意すべきである。ＣＲＡピクチャは先行ピクチャからは予測されないピクチャであって、出力順序でＣＲＡピクチャに続くピクチャは、出力順序でＣＲＡピクチャよりも前のピクチャから予測を行わない。ＩＤＲピクチャはＣＲＡピクチャであって、復号順序でＩＤＲピクチャに続くピクチャは、復号順序でＩＤＲより前のピクチャを参照しないものである。
【００１０】
ＳＰＳでは、図１に例示するような繰り返し用いられるＲＰＳを８つ指定することができ、図２に示すようにそれらにインデックスを割り当てることができる。スライスヘッダで送信される情報は、図３に示すように、ＳＰＳ内のＲＰＳインデックスを引用するだけでよい。ＲＰＳインデックスを利用することで、ＲＰＳそのものを送信する場合よりも必要とされるビット数が少なくなる。
【００１１】
この目的を達成するために、図３に示すようにＲＰＳインデックスを使用することはＲＰＳを送信するために必要とされるビット数を大きく削減する。これは、データの大部分はＳＰＳで代わりに送信され、しかも、あまり頻繁ではないからである。また、ＲＰＳ情報を更に圧縮することも可能である。図１の２つの行を比較すると、それらの類似性に気づくはずである。例えば、ＰＯＣ＝１のＲＰＳの全ての数字は、５を加算すればＰＯＣ＝６のＲＰＳの対応する数字と一致する。即ち、ＰＯＣ＝１のＲＰＳの第１の値「−１」は、−６＋５と一致する。第２の値「１」は−４＋５に一致する。第３の値「３」は−２＋５と一致する。唯一の例外は、ＰＯＣ＝１のＲＰＳの最後の値「５」である。ＰＯＣ＝６のＲＰＳに「０」を必要とするが、画像はそれ自体から予測することはできない。
【００１２】
結局のところ、図１の全てのＲＰＳは他のＲＰＳから予測することができる。これは、例えば図１のＲＰＳデータのようなＳＰＳ内のＲＰＳデータの記述に以下の方法をもたらすものである。
【００１３】
−各行、即ちＲＰＳについて、他のどのＲＰＳからインター予測が実行されるかが特定される。例えば、先行ＲＰＳからの予測は、ＳＰＳ内のパラメータであるdelta_idx_minus1（図４の短期ＲＰＳシンタックスを参照）内で値「−１」を送信することにより指示される。
【００１４】
−そして、加算すべき値、例えば「５」をＳＰＳ内のパラメータであるdelta_rps_sign and abs_delta_rps_minus1の値（図４の短期ＲＰＳシンタックスを参照）を使用して送信する
【００１５】
このようにしてＲＰＳ情報を送信することにより、多くのビットを節約することができる。節約されたビット量は、ＨＥＶＣ参照ピクチャ構造をテストするために利用されたコンフィグレーションファイルの旧バージョンについて測定された、ＳＰＳでＲＰＳを送信するために利用されるビットの約５０％である。ＳＰＳデータは動画ビットストリームデータ全体のうちの非常に少ない部分であるため、全体的な効果は５０％より小さいが、データの圧縮効率は依然として重要である。
【００１６】
典型的に、ＲＰＳはＳＰＳ内で１度だけ送信され、後に続くスライスは単にどのＲＰＳを使用するべきかをＲＰＳインデックスを利用して指定するだけである。しかしながら、エンコーダはＳＰＳ内にないＲＰＳを使用したい場合がある。その場合、当該エンコーダは上記のようにスライス内でＲＰＳを明示的に送信するオプションを有している。インター予測が使用されるか、或いは、ＲＰＳが値毎に符号化されるかは、図４に示す短期ＲＰＳの一部であるパラメータinter_ref_pic_set_prediction_flagを使用して各ＲＰＳについてシグナリングされる。もし、inter_ref_pic_set_prediction_flagの値が０である場合、送信ＲＰＳの値毎の方法が使用され、０で無い場合はＲＰＳシグナリングのためにインター予測が使用される。
【発明の概要】
【００１７】
本発明の目的は、上記の技術及び先行技術に対する改良された代替手段を提供することである。
【００１８】
より詳細には、本発明の目的は、ＲＰＳシグナリングの改良された方法を提供することにある。
【００１９】
本発明のこれら及び他の目的は、独立請求項により規定される発明の異なる側面により実現される。発明の実施形態は、従属請求項により特徴付けられる。
【００２０】
発明の第１の側面によれば、動画シーケンスの符号化方法が提供される。当該動画シーケンスはＲＰＳ、特に短期ＲＰＳを含む。当該方法は、前記ＲＰＳをデータ構造内に送信順に配列し、前記動画シーケンスの現ピクチャのＲＰＳのために明示的ＲＰＳ送信が利用されるかどうかを判定し、前記明示的ＲＰＳ送信が利用される場合にのみ、前記現ピクチャの前記ＲＰＳを予測するために利用されるべき前記データ構造内に含まれるＲＰＳを示す情報を符号化することを含む。
【００２１】
発明の第２の側面によれば、コンピュータプログラムが提供される。当該コンピュータプログラムはコンピュータプログラムコードを含む。コンピュータプログラムコードは、プロセッサにより実行された場合に、発明の第１の側面に対応する方法を実行するように適合されている。
【００２２】
発明の第３の側面によれば、コンピュータプログラム製品が提供される。当該コンピュータプログラム製品は、コンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体は発明の第２の側面に対応するコンピュータプログラムを記憶している。
【００２３】
発明の第４の側面によれば、動画シーケンスの復号方法が提供される。当該動画シーケンスは、ＲＰＳ、特に短期ＲＰＳを含む。当該方法は、送信順に配列された前記ＲＰＳを含むデータ構造を受信し、前記動画シーケンスの現ピクチャのＲＰＳのために明示的ＲＰＳ送信が利用されるかどうかを判定し、前記明示的ＲＰＳ送信が利用される場合にのみ、前記現ピクチャの前記ＲＰＳを予測するために利用されるべき前記データ構造内に含まれるＲＰＳを示す情報を受信することを含む。
【００２４】
発明の第５の側面によれば、コンピュータプログラムが提供される。当該コンピュータプログラムはコンピュータプログラムコードを含む。コンピュータプログラムコードは、プロセッサにより実行された場合に、発明の第４の側面に対応する方法を実行するように適合されている。
【００２５】
発明の第６の側面によれば、コンピュータプログラム製品が提供される。当該コンピュータプログラム製品は、コンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体は発明の第５の側面に対応するコンピュータプログラムを記憶している。
【００２６】
発明の第７の側面によれば、動画シーケンスを符号化するためのエンコーダが提供される。当該動画シーケンスはＲＰＳ、特に短期ＲＰＳを含む。当該エンコーダは、プロセッサとメモリとを備える。メモリはプロセッサにより実行可能な命令を含み、それによりエンコーダは、前記ＲＰＳを送信順にデータ構造内に配列し、前記動画シーケンスの現ピクチャのＲＰＳのために明示的ＲＰＳ送信が利用されるかどうかを判定し、前記明示的ＲＰＳ送信が利用される場合にのみ、前記現ピクチャの前記ＲＰＳを予測するために利用されるべき前記データ構造内に含まれるＲＰＳを示す情報を符号化するように動作可能である。
【００２７】
発明の第８の側面によれば、動画シーケンスを復号するためのデコーダが提供される。当該動画シーケンスはＲＰＳ、特に短期ＲＰＳを含む。当該デコーダは、プロセッサとメモリとを備える。メモリはプロセッサにより実行可能な命令を含み、それによりデコーダは、送信順に配列された前記ＲＰＳを含むデータ構造を受信し、前記動画シーケンスの現ピクチャのＲＰＳのために明示的ＲＰＳ送信が利用されるかどうかを判定し、前記明示的ＲＰＳ送信が利用される場合にのみ、前記現ピクチャの前記ＲＰＳを予測するために利用されるべき前記データ構造内に含まれるＲＰＳを示す情報を受信するように動作可能である。
【００２８】
発明は、ＲＰＳ、特に短期ＲＰＳの符号化及びシグナリングがＲＰＳのインター予測を利用してより効率的に実行できることの理解を活用するものである。このために、ＲＰＳはＳＰＳのようなデータ構造において送信順に配列される。明示的送信が現ピクチャのＲＰＳについて利用される場合にのみ、現ピクチャのＲＰＳを予測するために利用されるべきデータ構造内に含まれるＲＰＳを示す情報をエンコーダからデコーダへ、その情報を符号化することによりシグナリングする。換言すると、送信順序で配列されたＲＰＳのうちのどのＲＰＳが予測に使用されるべきかを記述する情報は、動画シーケンスの復号のためにそれが必要とされる場合にのみシグナリングされる。その情報は現ピクチャのＲＰＳ、特に短期ＲＰＳ内で符号化されてもよい。発明の実施形態は、現ピクチャのＲＰＳがＳＰＳ内でシグナリングされたＲＰＳから予測可能である点で利益がある。それにより、ＲＰＳのシグナリングに必要とされるビット数を削減でき、結果として符号化されたビデオシーケンスのビットレートも削減できる。さらに、ＲＰＳの符号化及びシグナリングの提案方法は、技術分野において公知の技術よりも複雑性が低い。
【００２９】
本明細書の全体を通して、情報要素、パラメータ、値等の情報は、通信ネットワークを介してエンコーダからデコーダへ符号化・シグナリングされ、或いは送信されることが理解されよう。そのような情報は結果的にデコーダで受信されて復号され、また、その後に復号処理において用いられても良い。
【００３０】
発明の実施形態によれば、方法は更にインター予測を前記現ピクチャの前記ＲＰＳのために利用するかどうかを判定することを更に含み、前記現ピクチャの前記ＲＰＳを予測するために利用されるべき前記データ構造内に含まれるＲＰＳを示す前記情報は、前記明示的ＲＰＳ送信とインター予測とが利用される場合にのみ符号化される。即ち、明示的に送信されたＲＰＳのためにインター予測が利用される場合にのみ、データ構造内に含まれるどのＲＰＳがインター予測に用いられるかを特定する情報がデコーダへシグナリングされるのである。明示的に送信されたＲＰＳが値毎に符号化される場合、即ち、インター予測を利用しない場合、当該情報は符号化されてシグナリングされることはない。インター予測を利用するかどうかは、例えばエンコーダからデコーダへパラメータを使ってシグナリングされても良い。このことは、ＲＰＳをシグナリングするための全ての選択肢が考慮される点、及び、ＲＰＳシグナリングに必要なビット数が削減される点で利益がある。
【００３１】
発明の実施形態によれば、データ構造の符号化には、少なくとも１つのＲＰＳを送信順序で該少なくとも１つのＲＰＳの直前のＲＰＳから予測することが含まれる。特に、これは明示的ＲＰＳ送信が利用されない場合に適用される。データ構造内に含まれるＲＰＳを、送信順で該ＲＰＳに先行するＲＰＳのようなデータ構造内に含まれる別のＲＰＳから予測することは、ＲＰＳのシグナリングに必要とされるビット数を削減できる点で利益がある。インター予測は、送信順の第１のＲＰＳには利用できないことが理解されよう。インター予測の利用の代替方法として、ＲＰＳは値毎に符号化されても良い。
【００３２】
発明の実施形態によれば、方法は、データ構造内に含まれる各ＲＰＳに対してインデックスを割り当てることを更に含み、現ピクチャのＲＰＳを予測するために使用されるべきＲＰＳを示す情報は、現ピクチャのＲＰＳのインデックスと予測に利用されるＲＰＳのインデックスとの間の差分を特定する。どのＲＰＳがインター予測に使用されるのかを指定する情報のこの符号化方法は、当該情報を伝達するために必要とされるビット数を削減できる点で、特に可変長符号化（ＶＬＣ）を採用する場合に利益がある。例えば、ＨＥＶＣパラメータdelta_idx_minus1を利用してこの情報が符号化されても良い。delta_idx_minus1は図４に示す短期ＲＰＳシンタックスの一部である。
【００３３】
発明の実施形態によれば、データ構造はＳＰＳである。
【００３４】
発明の実施形態によれば、明示的ＲＰＳ送信が利用されるかどうかの判定は、現ピクチャのＲＰＳのインデックスが、ＳＰＳ内に含まれるＲＰＳの数と等しいかどうかの判定を含む。この方法は、明示的ＲＰＳ送信が利用されたかどうかを判定する上で効果的な方法である。というのも、ＳＰＳに含まれるＲＰＳ、特に短期ＲＰＳの数はＳＰＳ内でシグナリングされ、ゆえにエンコーダとデコーダの両方には既知だからである。
【００３５】
発明の実施形態によれば、明示的ＲＰＳ送信が利用されるかどうかの判定は、現ピクチャのＲＰＳが、現ピクチャのスライスヘッダ内で符号化されているかどうかの判定を含む。この方法は、明示的ＲＰＳ送信が利用されたか否かを判定する代替的方法である。このため、ＲＰＳがスライスヘッダ内で符号化されているかどうかをチェックするために、スライスヘッダが検査される。
【００３６】
本発明の利点が、ある場合において発明の第１または第４の側面の実施形態を参照して記述されていたとしても、対応する理由付けは発明の他の実施形態にも適用されるものである。
【００３７】
発明の更なる目的、特徴、利点は以下の詳細な記述、図面及び特許請求の範囲の記載から明らかとなるであろう。当業者であれば、発明の異なる特徴を、以下に記載する実施形態以外の実施形態を生成するために組み合わせ可能であることを理解するであろう。
【００３８】
発明の上記特徴及び利点は、追加的な目的と同様、以下の図面を参酌し、以下の発明の実施形態の例示的でかつ非制限的な記述からより理解されるであろう。
【００３９】
全ての図面は概略的なものであって、必ずしもスケーリングを必要とせず、全般的に発明を理解するために必要な部分のみを示している。他の部分は省略されてもよいし、或いは、単に提案されてもよい。
【図面の簡単な説明】
【００４０】
【図１】ＲＰＳの例を示す図。
【図２】ＳＰＳ内の例示的ＲＰＳの符号化を示す図。
【図３】スライスヘッダ内の例示的ＲＰＳの符号化を示す図。
【図４】短期ＲＰＳの既知のシンタックスを示す図。
【図５】発明の実施形態に対応する、厳格な送信順序における例示的なピクチャシーケンスを示す図。
【図６】発明の実施形態に対応する、厳格でない送信順序における例示的なピクチャシーケンスを示す図。
【図７】発明の実施形態に対応する、ＳＰＳ内の例示的ＲＰＳの送信順序での符号を示す図。
【図８】発明の実施形態に対応する、提案に係る短期ＲＰＳシンタックスを示す図。
【図９】発明の実施形態に対応する、ビットストリームを示す図。
【図１０】発明の実施形態に対応する、ＲＰＳの符号化方法を示す図。
【図１１】発明の実施形態に対応する、ＲＰＳの復号方法を示す図。
【図１２】発明の実施形態に対応する、エンコーダ及びデコーダを示す図。
【発明を実施するための形態】
【００４１】
本発明は、発明の所定の実施形態を示す添付の図面を参照して以下により詳細に記述される。しかしながら、本発明は多くの異なる形態において実施されてもよく、ここで説明する実施形態に限定して解釈されるべきではない。むしろ、これらの実施形態は本開示を緻密で完全なものとするために例示目的で提供されたものであり、当業者に発明の範囲を十分に伝えるものであろう。
【００４２】
ＲＰＳシグナリングの提案に係る方法は、ＲＰＳをＳＰＳのようなデータ構造として、送信順に配列することに基づくものである。異なる種別の送信順序が存在するが、特に厳格な送信順序であるグループ・オブ・ピクチャ（ＧＯＰ）的な送信順序や、一般的な送信順序がある。以下では、厳格な送信順序を図５を参照して記述する。図５は１６ピクチャのシーケンスを示す。
【００４３】
厳格な送信順序では、ＲＰＳは使用される順序と完全に同一順序で符号化される。即ち、図５に示す順序であり、送信するＲＰＳが無くなるまではこの順序で画像が復号される。即ち、復号順序でもある。（ＰＯＣ＝１７のピクチャは、１２行のＲＰＳを再利用し、ＰＯＣ＝１８のピクチャは、１３行のＲＰＳを再利用し、ＰＯＣ＝１９のピクチャは、１４行のＲＰＳを再利用し、ＰＯＣ＝２０のピクチャは、１５行のＲＰＳを再利用し、ＰＯＣ＝２１のピクチャは、１２行のＲＰＳを再利用する等）。この場合、先行する行、即ちＲＰＳからの予測が有効であることが保証される。
【００４４】
しかしながら、これは十分条件ではあるが、必要条件ではない。先行するＲＰＳ行からの予測を許容する厳格でない他の送信順序が存在する。一つの方法は、ＧＯＰの順序を変えることである。予測に利用可能なピクチャはＧＯＰ内の位置により主に判定されるので、所定のＧＯＰの第１のＲＰＳを、先行するＧＯＰの最後のＲＰＳから予測することが可能となる場合がある。例えば、図６に示す順序では可能となる。図６では、ＳＰＳ内の第２のＧＯＰグループは、先行する（第１の）ＧＯＰグループよりも低いＧＯＰ番号を有しているので、インデックス４（ＧＯＰ＝０）の行は、インデックス３の行から予測することができる。
【００４５】
送信順序による送信の代替的な定義は、以下のようになる。もしＲＰＳ ＢがＲＰＳ Ａに続いて送信され、ＲＰＳ Ａを利用するピクチャＸとＲＰＳ Ｂを利用するピクチャＹとがあってピクチャＹは復号順序でピクチャＸに続くピクチャである場合に、ＲＰＳ Ａは、ＲＰＳ Ｂと関連する送信順序において送信されると言える。
【００４６】
送信順序による格納について、類似の定義は以下のようになる。もしＲＰＳ ＢのインデックスがＲＰＳ Ａのインデックスより１大きく、ＲＰＳ Ａを利用するピクチャＸとＲＰＳ Ｂを利用するピクチャＹがあって、ピクチャＹは復号順序でピクチャＸに続くピクチャである場合、ＲＰＳ Ａは、ＲＰＳ Ｂと関連する送信順で格納されると言える。
【００４７】
さらに、ＲＰＳの符号化及びシグナリングの処理は、ＲＰＳが明示的に送信されるか、或いは、黙示的に送信されるかに依存する。もし、ＲＰＳがシーケンス毎１回、或いは、毎秒１回、ＳＰＳのようなデータ構造において送信されるとすると、（大半の場合にフレームを参照する）各スライスはＳＰＳ内のＲＰＳ行、即ち、ＲＰＳインデックスを参照することができる。これは、黙示的なＲＰＳインデックス送信と呼ばれる。
【００４８】
或いは、ＲＰＳをスライスヘッダにおいて直接に送信することもできる。これは明示的ＲＰＳ送信と呼ばれ、デコーダがＳＰＳ内のＲＰＳを利用できない場合や、アクティブなＳＰＳ内に含まれないＲＰＳを使用したい場合に利用される。
【００４９】
上述のように、ＲＰＳの符号化には２つの選択肢があるが、明示的ＲＰＳ送信を使用する場合、インター予測や値毎のアプローチ（value-by-value approach）を利用した符号化となる。もし、インター予測を利用する場合、どのＲＰＳ、或いは、データ構造におけるＲＰＳリストのどの行から予測を行うかを特定することが重要である。エンコーダはどのフレームに対しても明示的にＲＰＳを符号化することを選択できるので、デコーダはどの行がもっとも可能性があるのかを知ることができない。よって、インター予測が明示的ＲＰＳ送信で利用される場合、データ構造に含まれるＲＰＳの１つを識別する情報、即ち、ＳＰＳが必要となる。当該情報はパラメータdelta_idx_minus1内でシグナリングされても良い。
【００５０】
しかしながら、これがＳＰＳ内のＲＰＳを符号化する場合には当てはまらないことは、見解として自明ではない。ＲＰＳが送信順序で送信される条件下では、各ＲＰＳについて、ＳＰＳ内の第１のＲＰＳは別として、ＲＰＳに直接に先行するＲＰＳは当該ＲＰＳについて利用が可能な全ての画像を、先行フレーム自体を除き、含んでいなければならない。結果として、ＳＰＳ内のＲＰＳを符号化する場合、可変のdelta_idx_minus1は０に等しく、送信する必要がない。
【００５１】
この見解を更に明らかとするために、図２のＲＰＳを再び図７に示す。ここではＰＯＣ番号とデルタＰＯＣが書き出されている。デルタＰＯＣは、先行するＰＯＣ番号と現ＰＯＣ番号との差分である。
【００５２】
図７を参照すると、エンコーダはＰＯＣ＝０の第１のピクチャを送信しなければならないであろう。当該第１のピクチャはイントラピクチャであって、先行するどのピクチャからも予測できない。第２のピクチャ、即ち図７の第１の行は、ＰＯＣ＝８であり、デルタＰＯＣ＝０−８＝−８である。ＰＯＣ＝０以外に送信されるピクチャは存在しないので、ＰＯＣ＝８が参照できるピクチャはＰＯＣ＝０のものだけである。よって、−８はＲＰＳ内でのみ可能となる値である。
【００５３】
ここで、２番目に送信されたＰＯＣ＝４のピクチャについて検討する。利用可能な２つのみのピクチャは、デルタＰＯＣ＝４で表されるＰＯＣ＝８の先行画像と、ＰＯＣ＝０の第１の画像である。もし、それが先行ピクチャでなければ、先行ＲＰＳ内で利用可能でなければならない。さもなくば、デコーダはそれを破棄するであろう。よって、第２のピクチャは、先行するＲＰＳ（−８のみである）から導出可能なＰＯＣ値を持っていなければならない。デルタＰＯＣ＝４をその値に加算すると、−４となる。これはＲＰＳ内の第２の値である。
【００５４】
よって、もしＲＰＳが送信順序にて格納されるならば、全てのＲＰＳはａ）先行ＲＰＳ内の値にデルタＰＯＣを加算した先行ＲＰＳから再構成、或いは、予測が可能であるか、或いは、ｂ）デルタＰＯＣ自体でなければならない、ことは明白であろう。
【００５５】
もしこれが当てはまらない場合、即ち、値がａ）でもｂ）でもない場合、先行するＲＰＳのいずれの値からも値を予測可能ではなく、デコーダはピクチャを破棄し、そのピクチャを参照することができない。唯一の例外は先行ピクチャであって、これは先行ＲＰＳ内には含まれない。というのも、当該ピクチャをそれ自体から予測することはなく、その場合は確実にｂ）に該当するからである。
【００５６】
この理由により、以下が明らかとなる。もし、ＲＰＳが配列され、ＳＰＳ内の送信順序で符号化されれば、パラメータdelta_idx_minus1は省略されてもよく、複雑性とビットの両方を抑えることができる。しかしながら、ＲＰＳを明示的に送信する場合、インター予測のために当該ＲＰＳを使用すべくＳＰＳ内のいずれのＲＰＳにアクセスすることは望ましい。この場合、予測のためのＲＰＳはdelta_idx_minus1を利用してシグナリングされる。よって、インター予測との関連で明示的ＲＰＳ送信が利用されるかどうかを確認することが提案される。もし、明示的ＲＰＳ送信が利用される場合、インター予測が実行され、delta_idx_minus1が送信されるが、それ以外の場合には省略される。
【００５７】
delta_idx_minus1をシグナリングするかどうかの問題は、インター予測が利用される場合にのみ発生する点に注意すべきである。このことは、図４の短期ＲＰＳシンタックスから理解できよう。３行目のif文
if( inter_ref_pic_set_prediction_flag )
は、インター予測が利用されるか否かを確認している。このため、if文において真と評価された場合、即ち、インター予測が利用される場合にのみ、delta_idx_minus1が送信される。
【００５８】
ＲＰＳの符号化及びシグナリングの提案方法は、特に明示的送信や黙示的送信の観点で、図８の短期ＲＰＳシンタックスに反映されている。
【００５９】
図８に示す短期ＲＰＳシンタックスでは、新たなif文が導入されている。
if( idx == num_short_term_ref_pic_sets )
【００６０】
このif文において真と評価された場合、明示的ＲＰＳ送信が現ピクチャについて利用され、デコーダはdelta_idx_minus1を復号しなければならない。一方、偽と評価された場合、ＲＰＳはＳＰＳでシグナリングされたＲＰＳのうちの１つであって、delta_idx_minus1は０に等しいと推測される。即ち、直前のＲＰＳからのインター予測が実施される。図４に示す既知の短期ＲＰＳに対応して、delta_idx_minus1をシグナリングするか否かの問題が、インター予測を用いる場合にのみ生ずる。このことは、図８の提案に係る短期ＲＰＳの３行目のif文から分かる。これは、図４に示す既知の短期ＲＰＳのif文と同一である。
【００６１】
より詳細には、ＳＰＳが例えばシーケンス毎１回、又は、毎秒１回生成される場合、及び、エンコーダが明示的ＲＰＳ送信を採用する場合に、現ピクチャのスライスヘッダのために任意に、という両方の場合について図８に示すシンタックスに対応する処理が実行される。第１の場合、インデックスの値は０からnum_short_term_ref_pic_sets - 1, の間の値、即ち、ＳＰＳでシグナリングされた短期ＲＰＳの数から１を引いた数で変化する。第２の場合、明示的ＲＰＳ送信が利用され、インデックスの値はnum_short_term_ref_pic_setと等しい。このように、if文により実行されるように、idxをnum_short_term_ref_pic_setと比較することにより、明示的ＲＰＳ送信を使用するかどうかを判定することができる。
【００６２】
代替的に、ＳＰＳ生成の間にコールされる場合に０に等しく（即ち、上記の第１の場合）、スライスヘッダの生成の間にコールされる場合に１に等しいother_parameterという別のパラメータに基づき、発明の実施形態を予想できるかもしれない。その場合、対応するif文は以下のようになる。
if( other_parameter )
【００６３】
更なる代替案として、ＳＰＳが生成される場合に、短期ＲＰＳを生成するためのある機能が実行され、スライスヘッダが生成される場合に別の機能が実行されても良い。このために、第１の機能はパラメータdelta_idx_minus1の送受信を行わないであろうが、第２の機能はパラメータdelta_idx_minus1の送受信を行うであろう。
【００６４】
一見して、提案に係る図８の短期ＲＰＳシンタックスは、部分的には４行目の余計なif文のために図４に示す現在の規格と比較して複雑性が増しているように見える。しかしながら、delta_idx_minus1の値を復号することは、if文を評価することに比べてより複雑である。また、大半のピクチャには非明示的ＲＰＳ送信が利用されるので、追加的なif文が実行されることは滅多にない。
【００６５】
発明をより明確化するために、図９を参照して発明の例示的な実施形態についてここで説明する。図９はビットストリーム９００が、ＳＰＳ９０１と、３枚のスライス、スライス２（９０２）、スライス３（９０３）、スライス４（９０４）とを含む場合を示している。ビットストリーム９００は図９には示されていない追加要素を含んでいてもよい。
【００６６】
ＳＰＳ９０１は、とりわけ５つのＲＰＳ９０５を含んでいる。ＲＰＳは、値毎のコーディングによりＳＰＳにおいて送信することができ、ＲＰＳ内の値の数が少ない場合に、これは多くの場合において最も効率的な方法である。例えば、ＲＰＳのリスト９０５における第１のＲＰＳ（｛−８｝）は値毎に以下のように送信できる。
inter_ref_set_prediction_flag = 0
num_negative_pics = 1
num_positive_pics  = 0
delta_poc_s0_minus1[0] = 8
used_by_cur_flag[0] = 1
【００６７】
或いは、ＳＰＳ内のＲＰＳは、例えば、ＲＰＳのリスト９０５における第２のＲＰＳ（｛−４、４｝）でインター予測を利用して送信することができる。ＲＰＳはＳＰＳ９０１内で、非明示的にシグナリングされ、インター予測は前の行から実行され本例では単一値｛−８｝のみを含むので、どのＲＰＳから予測するかを記述する情報をシグナリングする必要はない。よって、第２のＲＰＳは以下のように送信される。
inter_ref_set_prediction_flag = 1
delta_rps_sign = 0
abs_delta_rps_minus1 = 3
【００６８】
デコーダは第２のＲＰＳを以下のように再構成することができる。まず、deltaRps = ( 1 - 2 * delta_rps_sign ) * ( abs_delta_rps_minus1 + 1 ) = 4 が計算され、値{-8}に加算され(第１のＲＰＳ)、結果−４となる。これが第２のＲＰＳの第１の値となる。第２のＲＰＳの第２の値は、delta_rpsの値そのもの(delta_rps = 4)となる。このように、第２のＲＰＳは｛−４、４｝として再構成される。ここでdelta_idx_minus1は第２のＲＰＳについて送信されない点を強調しておく。これは、０と予測されるためである。
【００６９】
対応して、ＳＰＳ９０１内のＲＰＳリスト９０５の残りのＲＰＳを、上述のように値毎或いはインター予測を用いて送信することができる。例えば、第３のＲＰＳ｛−２、−４、−６、２｝はインター予測を用いてシグナリングしてもよく、第４のＲＰＳ｛−１、１、３、５、７｝は値毎にシグナリングしても良い。
【００７０】
更に、図９に示すビットストリーム９００を参照すると、スライス２（９０２）はＲＰＳの黙示的送信を示す。このためにスライス２（９０２）は点線９０９で示す情報を含む。当該情報は、ＲＰＳインデックス「＃１」のようにしてＲＰＳのリスト９０５内のどのＲＰＳを使用するかを示している。このように、エンコーダは、スライス２（９０２）についてＳＰＳ９０１内のＲＰＳのリスト９０５からのＲＰＳを使用すべきことを指示するために以下を送信する。
short_term_ref_pic_set_sps_flag = 1
また、インデックス「＃１」を有するリスト９０５内の第２のＲＰＳを使用すべきことを指示するために以下を送信する。
short_term_ref_pic_set_idx = 1
【００７１】
更なる例として、ビットストリーム９００内で送信されるスライス３（９０３）は、ＳＰＳ９０１内のシグナリングされたＲＰＳのリスト９０５からのいずれのＲＰＳも使用できないと推測される。しかし、その代わりにＲＰＳ９０７を明示的にシグナリングしている。明示的なシグナリングには２つの方法があり、本例ではスライス３（９０３）は値毎のコーディングを用いている。即ち、エンコーダは、ＲＰＳ９０７（｛−２、２、６｝をシグナリングするために、以下を送信する。
【００７２】
inter_ref_set_prediction_flag = 0
num_negative_pics = 1
num_positive_pics  = 2
delta_poc_s0_minus1[0] = 1
used_by_cur_flag[0] = 1
delta_poc_s1_minus1[0] = 1
used_by_cur_flag[0] = 1
delta_poc_s1_minus1[1] = 3
used_by_cur_flag[1] = 1
【００７３】
このセットにおいて負のピクチャの数は１（−２）であり、正のピクチャ数は２（２と６）である。負の値は０（delta_poc_s0[0] = 2）に対して符号化され、第１の正の値は同様に符号化される。最後に、２つの正の値の差分（６−２＝４）が符号化される（delta_poc_s1[1] = 4）。
【００７４】
明示的符号化の他の方法は、ビットストリーム９００のスライス４（９０４）を参照して説明される。スライス４（９０４）はインター予測を利用する。しかし、ＲＰＳは明示的に送信されるので、ＲＰＳのリスト９０５内のどのＲＰＳが予測に使用されるかを示す点線９１０の情報９０８が提供されなければならない。本例では、ＲＰＳインデックス＃２（９０８）として示される。よって、スライス４（９０４）内で以下が送信される。
inter_ref_set_prediction_flag = 1
delta_idx_minus1 = 2
num_negative_pics = 1
num_positive_pics  = 0
delta_poc_s0_minus1[0] = 8
used_by_cur_flag[0] = 1
【００７５】
デコーダは RefRpsIdxを
RefRpsIdx = stRpsIdx - ( delta_idx_minus1 + 1 )
として計算することができる。
【００７６】
本例では、ＳＰＳ９０１内のＲＰＳのリスト９０５は、５つのＲＰＳを含んでいる。よって、stRpsIdxの値は５に等しく、RefRPSIdxの値は5 - (2 + 1) = 2として評価される。これは、第３のＲＰＳ（{-2, -4, -6, 2}）のインデックスである。スライス４（９０４）の場合、どのＲＰＳから予測を行うかを示すためにdelta_idx_minus1が送信されなければならない。ＲＰＳインデックス９０８に加えて、どのように予測するかを記述する情報がシグナリングされる（予測データ９０８）。
【００７７】
以下では、図９に示す例をデコーダについて説明する。デコーダは最初にＲＰＳのリスト９０５を含むＳＰＳ９０１を受信する。リスト９０５に含まれるＲＰＳは、値毎またはインター予測を利用して受信することができる。例えば、第１のＲＰＳ（｛−８｝）は、以下を受信することにより値毎に受信される。
inter_ref_set_prediction_flag = 0
num_negative_pics = 1
num_positive_pics = 0
delta_poc_s0_minus1[0] = 8
used_by_cur_flag[0] = 1
【００７８】
一方、第２のＲＰＳ（｛−４、４｝）はインター予測を利用して受信されても良い。しかしながら、ＲＰＳはＳＰＳ９０１内に含まれるので、ＲＰＳは明示的に受信されず、よってdelta_idx_minus1も受信されない。従って、第２のＲＰＳについてデコーダにより以下が受信される。
inter_ref_set_prediction_flag = 1
delta_rps_sign = 0
abs_delta_rps_minus1 = 3
【００７９】
デコーダはdeltaRps = ( 1 - 2*delta_rps_sign ) * ( abs_delta_rps_minus1 + 1 ) = 4を再構成し、(第１のＲＰＳの)値({−８})に加算する。その結果−４が得られるが、これが第２のＲＰＳの第１の値となる。第２のＲＰＳの第２の値はdelta_rpsの値そのものである（４）。よって、ＲＰＳは{−４、４}として予測される。ＳＰＳ９０１内でシグナリングされる他のＲＰＳは、上述のように値毎またはインター予測を利用して受信される。
【００８０】
スライス２（９０２）については、ＳＰＳ９０１内のＲＰＳのリスト９０５における第２のＲＰＳを指し示す（９０９）ＲＰＳインデックス９０６（＃１）を受信することにより、ＲＰＳが黙示的に受信される。スライス３（９０３）は符号化された値毎にＲＰＳ９０７を明示的に送信する。
【００８１】
スライス４（９０４）のＲＰＳはインター予測を利用して明示的に受信される。よって、インター予測のために利用されるべきＲＰＳのリスト９０５におけるＲＰＳを示す情報９０８が受信される。また、予測方法を記述する情報（予測データ９０８）も受信される。この場合、delta_idx_minus1を受信する必要があり、以下の情報はデコーダにより受信される。
inter_ref_set_prediction_flag = 1
delta_idx_minus1 = 2
num_negative_pics = 1
num_positive_pics  = 0
delta_poc_s0_minus1[0] = 8
used_by_cur_flag[0] = 1
ここで強調すべきは、スライス４（９０４）のＲＰＳをインター予測を利用して明示的に受信するためには、delta_idx_minus1を受信することが必要な点である。
【００８２】
図１０は、ＲＰＳを含む動画シーケンスを符号化する方法の実施形態を示している。方法１０００は、ステップ１００１でＳＰＳのようなデータ構造において送信順序でＲＰＳを配列し、当該データ構造を送信することから開始する。続いてステップ１００２ではインター予測が利用されるか否かが判定される。これは、上述のように、或いは技術分野において公知であるように、例えばinter_ref_set_prediction_flagを用いることにより実行しても良い。もしインター予測が利用される場合（ステップ１００２でＹＥＳ）、ステップ１００３では、明示的ＲＰＳ送信が動画シーケンスの現ピクチャのＲＰＳについて使用されるかどうか、即ち、ＲＰＳが現ピクチャのスライスヘッダ内でシグナリングされるかどうかが判定される。もし、明示的送信が使用される場合、即ち、ＲＰＳが現ピクチャのスライスヘッダ内でシグナリングされる場合は、ステップ１００４で、delta_idx_minus1のような、現ピクチャのＲＰＳを予測するために利用されるデータ構造内に含まれるＲＰＳを示す情報が符号化され、送信される。この情報は明示的ＲＰＳ送信が利用される場合にのみ送信され（ステップ１００４）、それ以外の場合は送信されない（ステップ１００５）。同様に、ステップ１００２においてインター予測が利用されない場合（ステップ１００２でＮＯ）、delta_idx_minus1のような現ピクチャのＲＰＳを予測するために利用されるべきデータ構造内に含まれるＲＰＳを示す情報は、シグナリングされない。本発明の実施形態は、図１０に示すステップの順序で実行される場合に限定されるわけではない。例えば、発明の実施形態は、動画シーケンスの現ピクチャのＲＰＳについて明示的ＲＰＳ送信が利用されるかどうか、即ち、ＲＰＳが現ピクチャのスライスヘッダ内でシグナリングされるかどうかを最初に決定し、その後でインター予測を利用するかどうかを決定しても良い。
【００８３】
図１１には、ＲＰＳを含む動画シーケンスの復号方法の実施形態が示される。方法１１００はステップ１１０１において、送信順序で配列されたＲＰＳを含むデータ構造を受信し、ステップ１１０２においてインター予測を利用するかどうかを判定する。これは、例えば上述のようにinter_ref_set_prediction_flagを調べることによって実施しても良い。もし、インター予測を利用する場合（ステップ１１０２でＹＥＳ）、ステップ１１０３において明示的ＲＰＳ送信が動画シーケンスの現ピクチャのＲＰＳについて使用されているかどうか、即ち、現ピクチャのスライスヘッダ内でＲＰＳがシグナリングされているかどうかを判定する。もし明示的送信が利用されている、即ち、ＲＰＳが現ピクチャのスライスヘッダ内でシグナリングされている場合、ステップ１１０４において、delta_idx_minus1のような現ピクチャのＲＰＳを予測するために利用されるべきデータ構造内に含まれるＲＰＳを示す情報が受信される。この情報は明示的ＲＰＳ送信が利用される場合にのみ受信され（ステップ１１０４）、それ以外の場合は受信されない（ステップ１１０５）。もし情報が、現ピクチャのＲＰＳのインデックスと予測に使用されるＲＰＳのインデックスとの間の差分を規定するdelta_idx_minus1の場合、delta_idx_minus1はむしろ０と解釈される（ステップ１１０５）。即ち、先行ＲＰＳがインター予測に使用される。もしステップ１１０２でインター予測が利用されない場合（ステップ１１０２でＮＯ）、delta_idx_minus1のような現ピクチャのＲＰＳを予測するために利用されるべきデータ構造内に含まれるＲＰＳを示す情報は、受信されない。本発明の実施形態は、図１１に示すステップの順序で実行される場合に限定されるわけではない。例えば、発明の実施形態は、動画シーケンスの現ピクチャのＲＰＳについて明示的ＲＰＳ送信が利用されるかどうか、即ち、ＲＰＳが現ピクチャのスライスヘッダ内でシグナリングされるかどうかを最初に決定し、その後でインター予測を利用するかどうかを決定しても良い。
【００８４】
図１２は、ＲＰＳを含む動画シーケンスを符号化するエンコーダの実施形態と、ＲＰＳを含む動画シーケンスを復号するデコーダの実施形態とを示す図である。
【００８５】
エンコーダ１２００は、プロセッサ１２０１と、プロセッサ１２０１により実行可能な命令１２０３を含むメモリ１２０２とを有する。これにより、エンコーダ１２００はデータ構造内で送信順序でＲＰＳを配列し、動画シーケンスの現ピクチャのＲＰＳのために明示的ＲＰＳ送信を使用するかどうかを判定し、明示的ＲＰＳ送信が使用される場合にのみ、delta_idx_minus1のような現ピクチャのＲＰＳを予測するために利用されるべきデータ構造内に含まれるＲＰＳを示す情報１２２０を符号化する、ように動作可能である。
【００８６】
デコーダ１２１０はプロセッサ１２１１と、プロセッサ１２１１により実行可能な命令１２１３を含むメモリ１２１２とを有する。これにより、デコーダ１２１０は送信順序で配列されたＲＰＳを含むデータ構造を受信し、動画シーケンスの現ピクチャのＲＰＳのために明示的ＲＰＳ送信を使用するかどうかを判定し、明示的ＲＰＳ送信が使用される場合にのみ、delta_idx_minus1のような現ピクチャのＲＰＳを予測するために利用されるべきデータ構造内に含まれるＲＰＳを示す情報１２２０を受信する、ように動作可能である。
【００８７】
ここに記述する実施形態は動画のエンコーダとデコーダとに関連するとともに、ビットストリームのパーサー、トランスコーダ、ネットワークノードなどにも関連する。エンコーダ及びデコーダの実施形態は、ビデオカメラ、ディスプレイ、タブレット、デジタルテレビ受信機、ネットワークノードなどのような装置として実現することができる。図１２では、パラメータdelta_idx_minus1が送信される場合を示したが、本発明の実施形態ではdelta_idx_minus1は明示的ＲＰＳ送信が利用される場合にのみ送信されるものであることを理解すべきである。
【００８８】
delta_idx_minus1の利用は、本明細書の全体を通して、インター予測に利用するＲＰＳをどのように指定するかの単なる例示に過ぎないことを理解すべきである。また、他のシグナリング手法を用いることが可能な点も当業者には自明である。この点について、delta_idx_minus1の参照はどのようなものであっても、どのＲＰＳから予測するかのインジケータとして理解されるべきである。
【００８９】
本実施形態ではＲＰＳをＳＰＳの一部として記述したが、ＲＰＳは他のデータ構造、例えばＰＰＳや他のパラメータセットに含まれても良い。
【００９０】
図１２を参照して説明したエンコーダ１２００の代替として、エンコーダの実施形態は、データ構造内で送信順序でＲＰＳを配列し、動画シーケンスの現ピクチャのＲＰＳのために明示的ＲＰＳ送信を使用するかどうかを判定し、明示的ＲＰＳ送信が使用される場合にのみ、delta_idx_minus1のような現ピクチャのＲＰＳを予測するために利用されるべきデータ構造内に含まれるＲＰＳを示す情報１２２０を符号化するように構成された手段を含んでもよい。
【００９１】
更なる代替として、エンコーダの実施形態は、データ構造内で送信順序でＲＰＳを配列する手段、動画シーケンスの現ピクチャのＲＰＳのために明示的ＲＰＳ送信を使用するかどうかを判定する手段、明示的ＲＰＳ送信が使用される場合にのみ、delta_idx_minus1のような現ピクチャのＲＰＳを予測するために利用されるべきデータ構造内に含まれるＲＰＳを示す情報１２２０を符号化する手段を含んでもよい。
【００９２】
図１２を参照して説明したデコーダ１２１０の代替として、デコーダの実施形態は、送信順序で配列されたＲＰＳを含むデータ構造を受信し、動画シーケンスの現ピクチャのＲＰＳのために明示的ＲＰＳ送信を使用するかどうかを判定し、明示的ＲＰＳ送信が使用される場合にのみ、delta_idx_minus1のような現ピクチャのＲＰＳを予測するために利用されるべきデータ構造内に含まれるＲＰＳを示す情報１２２０を受信するように構成された手段を含んでもよい。
【００９３】
更なる代替として、デコーダの実施形態は、送信順序で配列されたＲＰＳを含むデータ構造を受信する手段、動画シーケンスの現ピクチャのＲＰＳのために明示的ＲＰＳ送信を使用するかどうかを判定する手段、明示的ＲＰＳ送信が使用される場合にのみ、delta_idx_minus1のような現ピクチャのＲＰＳを予測するために利用されるべきデータ構造内に含まれるＲＰＳを示す情報１２２０を受信する手段を含んでもよい。
【００９４】
当業者であれば、上述の実施形態が決して本発明を限定するものでないことを理解するであろう。それどころか、特許請求の範囲の記載の範囲内で多くの修正、変形が可能である。
【図１】
0005872739.tif 000002
【図２】
0005872739.tif 000003
【図３】
0005872739.tif 000004
【図４】
0005872739.tif 000005
【図５】
0005872739.tif 000006
【図６】
0005872739.tif 000007
【図７】
0005872739.tif 000008
【図８】
0005872739.tif 000009
【図９】
0005872739.tif 000010
【図１０】
0005872739.tif 000011
【図１１】
0005872739.tif 000012
【図１２】
0005872739.tif 000013