[0023]動きベクトル制限は、動きベクトルのx成分またはy成分のうちの少なくとも1つを値の範囲内に限定することを指す。このようにして、動きベクトル制限は、現在のブロックをインター予測するために使用され得る参照ピクチャのブロックを制限する。たとえば、y成分が一定の範囲内に制限される場合、y成分範囲の外にある参照ピクチャ中の任意のブロックは、現在のブロックをインター予測するために使用され得ない。一般に、動きベクトル制限は、より詳細に説明するように、ビュー間またはレイヤ間参照ピクチャであり得る参照ピクチャのサブ部分を指すように動きベクトルの範囲を限定するために使用され得る。
[0024]動きベクトル制限が有用であり得る様々な理由があり得る。一例として、動きベクトル制限は、現在のブロックをインター予測するためにアクセスされる必要がある参照ピクチャのデータの量を減らすことができ、これのことは、メモリ帯域幅効率を高める。たとえば、制限範囲外に存在するブロックのビデオデータは、現在のブロックをインター予測するためにアクセスされる必要はないことがある。
[0025]別の例として、動きベクトル制限は、並列復号を可能にし得る。たとえば、マルチビュービデオコーディングまたはスケーラブルビデオコーディングでは、従属ビューまたはレイヤ中のピクチャが、参照ビューまたはレイヤ(たとえば、ベースビューまたはレイヤ)中のピクチャによりインター予測(たとえば、ビュー間予測またはレイヤ間予測)され得る。動きベクトル制限がない場合、ビデオデコーダは、従属ビューまたはレイヤのピクチャを再構成する前に、参照ビューまたはレイヤのピクチャ全体を再構成する必要があり得る。この理由で、従属ビューまたはレイヤのピクチャを再構成する前に参照ビューまたはレイヤのピクチャ全体を再構成する必要を回避するために、動きベクトル制限が望まれ得る。
[0026]その上、動きベクトル制限がある場合、ビデオデコーダは、参照ビューまたはレイヤのピクチャと並列に、従属ビューまたはレイヤのピクチャを再構成することが可能であり得る。たとえば、動きベクトル制限が、従属ビューまたはレイヤのピクチャ中の任意のブロックについての動きベクトルのy成分が参照ビューまたはレイヤ(たとえば、ベースビューまたはレイヤ)中でTh(Thは、y成分制限を定義する)を超えることができないと定義すると仮定する。言い換えれば、現在のブロックが、従属ビューまたはレイヤのピクチャ中の(x,y)に位置する場合、参照ビューまたはレイヤのピクチャ中の(x,y+Th)以上に位置するブロックのみが、現在のブロックをインター予測するために使用され得る。
[0027]この例では、ビデオデコーダが参照ビューまたはレイヤのピクチャをy+Thブロックまで再構成した後、ビデオデコーダは、参照ビューまたはレイヤのピクチャと並列に従属ビューまたはレイヤのピクチャを再構成することができる。これの理由は、参照ビューまたはレイヤのピクチャ中のy+Thブロックの後のいかなるブロックも、「y」のy成分値を有する従属ビューまたはレイヤのピクチャ中のブロックをインター予測するために使用され得ないことである。この意味で、動きベクトル制限は、並列復号遅延(すなわち、ビデオデコーダが従属ビューまたはレイヤのピクチャの再構成を開始し得る前に再構成されなければならない参照ビューまたはレイヤのピクチャの行の数)を定義することができる。いくつかの例では、参照ビューまたはレイヤのピクチャを再構成する際に使用されるフィルタ処理のタイプに基づいて、ビデオデコーダは、y+Th行の後の行中のいくつかのブロックが再構成されるまで、従属ビューまたはレイヤのピクチャの再構成を開始することが可能ではないことがある。
[0028]しかしながら、動きベクトル制限を使用することに伴う問題があり得る。たとえば、多くの場合、ビデオエンコーダは、現在のブロックの実際の動きベクトルの情報(たとえば、シンタックス要素)をシグナリングしないことがある。代わりに、ビデオエンコーダは、ビデオデコーダが動きベクトルを導出する際の導出元となる情報(たとえば、シンタックス要素)をシグナリングすることがある。一例として、ビデオエンコーダは、現在のブロックの動きベクトルの情報をシグナリングするのではなく、マージ/スキップモードまたは高度動きベクトル予測(AMVP:advanced motion vector prediction)モードの一部として、候補動きベクトル予測子のリストへのインデックスをシグナリングし得る。ビデオデコーダは、受信されたインデックスに基づいて、候補動きベクトル予測子のリストから動きベクトル予測子を選択し、動きベクトル予測子に基づいて、現在のブロックについての動きベクトルを導出することができる。これらの例のうちのいくつかでは、動きベクトルを導出する際に、動きベクトル制限に違反する動きベクトルをビデオデコーダが導出することが考えられ得る。
[0029]たとえば、マージ/スキップモードでは、ビデオデコーダは、動きベクトル予測子の動きベクトルを採用する(すなわち、現在のブロックの動きベクトルを動きベクトル予測子に等しくセットする)。現在のブロックの動きベクトルが動きベクトル予測子に等しくセットされた場合に、それ、動きベクトルが現在のブロックの動きベクトル制限に準拠する保証がないことがある。
[0030]別の例として、AMVPモードでは、ビデオデコーダは、選択された動きベクトル予測子とベストマッチ探索から決定された動きベクトルとの間の動きベクトル差分(MVD)を受信する。ビデオデコーダは、現在のブロックについての動きベクトルを導出するために、選択された動きベクトル予測子にMVDを加算する。しかしながら、いくつかの例では、動きベクトル予測子にMVDを加算することによって、得られる導出された動きベクトルが動きベクトル制限に違反することが考えられ得る。
[0031]以下でより詳細に説明する時間的動きベクトル予測子(TMVP)の場合など、動きベクトル制限を使用するときに存在する他のそのような問題があり得る。以下でより詳細に説明するように、動きベクトル制限を使用するときに、特定の参照ピクチャリストを指す動きベクトル予測子についてのすべてのMVDが0であることを示すMVDフラグに伴う問題もあり得る。
[0032]ビデオデコーダが動きベクトルを導出するために使用するビットストリーム中の情報が、導出された動きベクトルが動きベクトル制限に違反しないことを確実にすることを、本開示で説明する技法は確実にし得る。一例として、マージ/スキップモードの場合、本技法は、現在のブロックについての動きベクトルとして採用された場合に、導出された動きベクトルに動きベクトル制限に違反させることになる動きベクトル予測子についての候補動きベクトル予測子のリストへのインデックスをビットストリームが含まないことを確実にし得る。別の例として、AMVPモードの場合、本技法は、動きベクトル予測子に加算されたときに、得られる導出された動きベクトルに動きベクトル制限に準拠させるMVDをビットストリームが含むことを確実にし得る。
[0033]並列復号の一部として動きベクトル制限を使用することに伴う問題または懸念もあり得る。いくつかの技法は、2つのマクロブロック行の固定値に並列復号遅延をセットすることができる。しかしながら、いくつかの最近のビデオコーディング規格は、マクロブロックに依存せず、代わりに、ツリーブロックの階層構造または最大コーディングユニット(LCU)もしくはコーディングツリーユニット(CTU)を使用する。各ツリーブロックは、4分木に従ってコーディングユニット(CU)に分割され得る。たとえば、4分木のルートノードとしてのツリーブロックは、4つの子ノードに分割され得、各子ノードは、次に、親ノードとなり、別の4つの子ノードに分割され得る。4分木のリーフノードとしての、最終的な、分割されていない子ノードは、コーディングノード(すなわち、コーディングされたビデオブロック)を備える。したがって、「マクロブロック」を使用する圧縮技法からの「行」の概念は、マクロブロックの代わりにツリーブロックを使用する技法にはうまく当てはまらないことがある。
[0034]実際、そのような階層構造を利用するビデオコーディング規格には、マクロブロック行からブロック行への単純な拡張がないことがある。言い換えれば、ツリーブロック階層構造を使用するビデオコーディング技法には、2つのマクロブロック行の並列復号遅延の単純な方法がないことがある。
[0035]動きベクトル制限をいくつかのマクロブロック行に固定することの限界を克服するために、いくつかの技法は、たとえば、LCU行のユニットにおける動きベクトル制限をシグナリングする。しかしながら、ビデオデコーダは、並列復号をいつ開始すべきか(たとえば、並列復号遅延)を決定するためにビデオデコーダが利用することができる値にLCU行のユニットを変換する必要が依然としてあり得る。
[0036]一例として、ビデオデコーダは、LCUサイズに基づいて、並列復号をいつ開始すべきかを決定するためにビデオデコーダが利用することができる値にLCU行を変換する必要があり得る。しかしながら、あらゆるビデオデコーダが、並列復号のためにビデオデコーダが利用することができる値にLCU行を変換し得る統一的方法がないことがあり、結果的に、異なるビデオデコーダが異なる量の並列復号遅延を決定することになり得る。異なるビデオデコーダが異なる量の並列復号遅延を決定することは、復号の非効率、および場合によっては復号エラーをもたらし得る。
[0037]いくつかの例では、本開示で説明する技法は、コーディングユニットサイズで並列復号遅延をシグナリングし得る。この形では、あらゆるビデオデコーダが並列復号遅延を決定することが可能であり得る一貫した方法があり得る。たとえば、ビデオデコーダは、並列復号がいつ開始できるかを決定するために利用され得る値に受信済み並列復号遅延情報をさらに変換する必要がないことがある。
[0038]図1は、本開示で説明する技法を利用し得る例示的なビデオ符号化および復号システム10を示すブロック図である。図1に示すように、システム10は、宛先デバイス14によって後で復号されるべき符号化されたビデオデータを生成するソースデバイス12を含む。ソースデバイス12および宛先デバイス14は、デスクトップコンピュータ、ノートブック(すなわち、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスのいずれかを備え得る。場合によっては、ソースデバイス12および宛先デバイス14は、ワイヤレス通信に対応し得る。
[0039]宛先デバイス14は、リンク16を介して、復号されるべき符号化されたビデオデータを受信し得る。リンク16は、ソースデバイス12から宛先デバイス14に符号化されたビデオデータを移すことが可能な任意のタイプの媒体またはデバイスを備えることができる。一例では、リンク16は、ソースデバイス12が、符号化されたビデオデータをリアルタイムに宛先デバイス14に直接送信できるようにする通信媒体を備えることができる。符号化されたビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され、宛先デバイス14に送信され得る。通信媒体は、無線周波数(RF)スペクトルまたは1つもしくは複数の物理伝送線路など、任意のワイヤレスまたはワイヤード通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークのような、パケットベースネットワークの一部を形成し得る。通信媒体は、ソースデバイス12から宛先デバイス14への通信を支援するために有用であり得るルータ、スイッチ、基地局、または任意の他の機器を含み得る。
[0040]代替的に、符号化されたデータは、出力インターフェース22からストレージデバイス34に出力され得る。同様に、符号化されたデータは、入力インターフェースによってストレージデバイス34からアクセスされ得る。ストレージデバイス34は、ハードドライブ、Blu−ray(登録商標)ディスク、DVD、CD−ROM、フラッシュメモリ、揮発性もしくは不揮発性メモリ、または符号化されたビデオデータを記憶するための任意の他の好適なデジタル記憶媒体など、様々な分散したまたはローカルでアクセスされるデータ記憶媒体のいずれかを含み得る。さらなる一例では、ストレージデバイス34は、ソースデバイス12によって生成された符号化されたビデオを保持できるファイルサーバまたは別の中間ストレージデバイスに対応し得る。宛先デバイス14は、ストリーミングまたはダウンロードを介して、ストレージデバイス34から、記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化されたビデオデータを記憶し、その符号化されたビデオデータを宛先デバイス14に送信することが可能な任意のタイプのサーバであり得る。例示的なファイルサーバとしては、(たとえば、ウェブサイト用の)ウェブサーバ、FTPサーバ、ネットワーク接続ストレージ(NAS)デバイス、またはローカルディスクドライブがある。宛先デバイス14は、インターネット接続を含む任意の標準的なデータ接続を通じて、符号化されたビデオデータにアクセスし得る。これは、ファイルサーバに記憶された符号化されたビデオデータにアクセスするのに適しているワイヤレスチャネル(たとえば、Wi−Fi(登録商標)接続)、ワイヤード接続(たとえば、DSL、ケーブルモデムなど)、または両方の組合せを含むことができる。ストレージデバイス34からの符号化されたビデオデータの送信は、ストリーミング送信、ダウンロード送信、または両方の組合せであり得る。
[0041]本開示の技法は、必ずしもワイヤレス適用例または設定に限定されるとは限らない。本技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、たとえばインターネットを介したストリーミングビデオ送信、データ記憶媒体に記憶するためのデジタルビデオの符号化、データ記憶媒体に記憶されたデジタルビデオの復号、または他の適用例など、様々なマルチメディア適用例のいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、システム10は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および/またはビデオテレフォニーなどの適用例をサポートするために、一方向または双方向のビデオ送信をサポートするように構成され得る。
[0042]図1の例では、ソースデバイス12は、ビデオソース18と、ビデオエンコーダ20と、出力インターフェース22とを含む。場合によっては、出力インターフェース22は変調器/復調器(モデム)および/または送信機を含み得る。ソースデバイス12において、ビデオソース18は、たとえばビデオカメラなどのビデオキャプチャデバイス、以前にキャプチャされたビデオを含んでいるビデオアーカイブ、ビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェース、および/もしくはソースビデオとしてコンピュータグラフィックスデータを生成するためのコンピュータグラフィックスシステムなどのソース、またはそのようなソースの組合せを含み得る。一例として、ビデオソース18がビデオカメラである場合、ソースデバイス12および宛先デバイス14は、いわゆるカメラ付き携帯電話またはビデオ電話を形成し得る。ただし、本開示で説明する技法は、概してビデオコーディングに適用可能であり得、ワイヤレスおよび/またはワイヤード適用例に適用され得る。
[0043]キャプチャされたビデオ、以前にキャプチャされたビデオ、またはコンピュータ生成されたビデオは、ビデオエンコーダ20によって符号化され得る。符号化されたビデオデータは、ソースデバイス12の出力インターフェース22を介して宛先デバイス14に直接送信され得る。符号化されたビデオデータは、さらに(または代替的に)、復号および/または再生のための宛先デバイス14または他のデバイスによる後のアクセスのためにストレージデバイス34上に記憶され得る。
[0044]宛先デバイス14は、入力インターフェース28と、ビデオデコーダ30と、ディスプレイデバイス32とを含む。場合によっては、入力インターフェース28は、受信機および/またはモデムを含み得る。宛先デバイス14の入力インターフェース28は、リンク16を介して、符号化されたビデオデータを受信する。リンク16を介して通信され、またはストレージデバイス34上に提供された符号化されたビデオデータは、ビデオデータを復号する際にビデオデコーダ30などのビデオデコーダが使用するための、ビデオエンコーダ20によって生成された様々なシンタックス要素を含み得る。そのようなシンタックス要素は、通信媒体上で送信され記憶媒体上に記憶される符号化されたビデオデータとともに含まれ得、またはファイルサーバを記憶した。本開示では、ビットストリーム中の「情報」という用語は、シンタックス要素を含むビットストリーム中の任意の情報を一般的に指すために使用される。
[0045]ディスプレイデバイス32は、宛先デバイス14と一体化されること、またはその外部に存在することがある。いくつかの例では、宛先デバイス14は、一体型ディスプレイデバイスを含むことができ、また、外部ディスプレイデバイスとインターフェースするように構成され得る。他の例では、宛先デバイス14はディスプレイデバイスであり得る。一般に、ディスプレイデバイス32は、復号されたビデオデータをユーザに対して表示し、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスなど、様々なディスプレイデバイスのいずれかを備え得る。
[0046]ビデオエンコーダ20およびビデオデコーダ30は、代替的にMPEG−4、Part10、アドバンストビデオコーディング(AVC)と呼ばれるITU−T H.264規格などのビデオ圧縮規格、またはそのような規格の拡張に従って動作し得る。代替的に、ビデオエンコーダ20およびビデオデコーダ30は、高効率ビデオコーディング(HEVC)規格などの他のプロプライエタリ規格または業界規格に従って動作し得、HEVCテストモデル(HM:HEVC Test Model)に準拠し得る。ただし、本開示の技法は、いかなる特定のコーディング規格にも限定されない。ビデオ圧縮規格の他の例には、MPEG−2およびITU−T H.263がある。
[0047]図1には示されていないが、いくつかの態様では、ビデオエンコーダ20およびビデオデコーダ30は、それぞれオーディオエンコーダおよびオーディオデコーダと統合されてよく、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理するために、適切なMUX−DEMUXユニット、または他のハードウェアおよびソフトウェアを含んでもよい。適用可能な場合、いくつかの例では、MUX−DEMUXユニットは、ITU H.223マルチプレクサプロトコル、またはユーザデータグラムプロトコル(UDP)などの他のプロトコルに準拠し得る。
[0048]ビデオエンコーダ20およびビデオデコーダ30はそれぞれ、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなどの様々な適切なエンコーダ回路のいずれかとして実装され得る。本技法が部分的にソフトウェアで実装されるとき、デバイスは、好適な非一時的コンピュータ可読媒体にソフトウェアの命令を記憶し、本開示の技法を実行するために1つまたは複数のプロセッサを使用してハードウェアでその命令を実行し得る。
[0049]ビデオエンコーダ20およびビデオデコーダ30の各々は1つまたは複数のエンコーダまたはデコーダ中に含まれてよく、そのいずれも、それぞれのデバイスにおいて複合エンコーダ/デコーダ(コーデック)の一部として統合されてよい。一例として、デバイスはビデオデコーダ30を含むことができ、デバイスの一例は集積回路(IC)であり、デバイスの別の例はマイクロプロセッサである。別の例として、デバイスはビデオデコーダ30を含むことができ、デバイスの一例はワイヤレス通信デバイスである。ビデオエンコーダ20は同様に、IC、マイクロプロセッサで、またはワイヤレス通信デバイスで形成され得る。
[0050]ITU−T Video Coding Experts Group(VCEG)とISO/IEC Motion Picture Experts Group(MPEG)とのJoint Collaboration Team on Video Coding(JCT−VC)によって開発された新しいビデオコーディング規格、すなわち、高効率ビデオコーディング(HEVC)がある。HEVC規格化の取り組みは、HEVCテストモデル(HM)と呼ばれるビデオコーディングデバイスの発展的モデルに基づく。HMは、たとえば、ITU−T H.264/AVCに従う既存のデバイスに対してビデオコーディングデバイスのいくつかの追加の能力を仮定する。たとえば、H.264は9つのイントラ予測符号化モードを提供するが、HMは33個ものイントラ予測符号化モードを提供し得る。
[0051]これ以降HEVC WD9と呼ばれる、HEVCの最新のワーキングドラフト(WD)が、http://phenix.int−evry.fr/jct/doc_end_user/documents/11_Shanghai/wg11/JCTVC−K1003−v13.zipから入手可能である。「HEVC Working Draft 10」または「WD10」と呼ばれるHEVC規格の別の最近のドラフトは、文書JCTVC−L1003v34、Brossら、「High efficiency video coding (HEVC) text specification draft 10 (for FDIS & Last Call)」、ITU−T SG16 WP3とISO/IEC JTC1/SC29/WG11とのJoint Collaborative Team on Video Coding(JCT−VC)、第12回会合:ジュネーブ、スイス、2013年1月14〜23日に記載されており、この文書は、http://phenix.int−evry.fr/jct/doc_end_user/documents/12_Geneva/wg11/JCTVC−L1003−v34.zipからダウンロード可能である。HEVC規格のさらに別のドラフトは、本明細書で「WD10改訂」と呼ばれ、Brossら、「Editors’ proposed corrections to HEVC version 1」、ITU−T SG16 WP3とISO/IEC JTC1/SC29/WG11とのJoint Collaborative Team on Video Coding(JCT−VC)、第13回会合、仁川、韓国、2013年4月に記載されており、この文書は、http://phenix.int−evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC−M0432−v3.zipから入手可能である。HEVC WD9、WD10、およびWD10改訂の内容全体が参照により本明細書に組み込まれる。
[0052]概して、HMのワーキングモデルは、ビデオフレームまたはピクチャが、ルーマサンプルとクロマサンプルの両方を含む一連のツリーブロックまたは最大コーディングユニット(LCU)に分割され得ることを記載している。ツリーブロックは、H.264規格のマクロブロックと同様の目的を有し得る。スライスは、コーディング順序でいくつかの連続するツリーブロックを含む。ビデオフレームまたはピクチャは、1つまたは複数のスライスに区分され得る。各ツリーブロックは、4分木に従ってコーディングユニット(CU)に分割され得る。たとえば、4分木のルートノードとしてのツリーブロックは、4つの子ノードに分割され得、各子ノードは、次に、親ノードとなり、別の4つの子ノードに分割され得る。4分木のリーフノードとしての、最終的な、分割されていない子ノードは、コーディングノード(すなわち、コーディングされたビデオブロック)を備える。コーディングされたビットストリームに関連するシンタックスデータは、ツリーブロックが分割され得る最大回数を定義し得、コーディングノードの最小サイズをも定義し得る。
[0053]CUは、コーディングノードと、コーディングノードに関連する予測ユニット(PU)および変換ユニット(TU)とを含む。CUのサイズは、コーディングノードのサイズに対応し、形状が正方形でなければならない。CUのサイズは、8×8ピクセルから最大64×64以上のピクセルをもつツリーブロックのサイズまでに及び得る。各CUは、1つまたは複数のPUと、1つまたは複数のTUとを含み得る。CUに関連するシンタックスデータは、たとえば、CUを1つまたは複数のPUに区分することを記述し得る。区分モードは、CUが、スキップモード符号化もしくはダイレクトモード符号化されるか、イントラ予測モード符号化されるか、またはインター予測モード符号化されるかによって異なり得る。PUは、形状が非正方形になるように区分され得る。CUに関連するシンタックスデータは、たとえば、4分木に従って、CUを1つまたは複数のTUに区分することも記述し得る。TUは、形状が正方形または非正方形であり得る。
[0054]HEVC規格は、CUごとに異なり得るTUに従う変換を可能にする。TUは、一般に、区分されたLCUについて定義された所与のCU内のPUのサイズに基づいてサイズ決定されるが、常にそうであるとは限らない。TUは、通常、PUと同じサイズであるか、またはPUよりも小さい。いくつかの例では、CUに対応する残差サンプルは、「残差4分木」(RQT:residual quad tree)として知られる4分木構造を使用して、より小さいユニットに再分割され得る。RQTのリーフノードは変換ユニット(TU)と呼ばれることがある。TUに関連するピクセル差分値は、変換係数を生成するように変換されてよく、その変換係数は量子化され得る。
[0055]一般に、PUは、予測プロセスに関係するデータを含む。たとえば、PUがイントラモード符号化(イントラ予測)されるとき、PUは、PUについてのイントラ予測モードを記述するデータを含み得る。別の例として、PUがインターモード符号化(インター予測)されるとき、PUは、PUについての動きベクトルを定義するデータを含み得る。PUについての動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの解像度(たとえば、1/4ピクセル精度もしくは1/8ピクセル精度)、動きベクトルが指す参照ピクチャ、および/または動きベクトルの参照ピクチャリスト(たとえば、リスト0(L0)もしくはリスト1(L1))を記述し得る。リスト0およびリスト1は、それぞれRefPicList0およびRefPicList1と呼ばれることがある。
[0056]概して、TUは、変換プロセスと量子化プロセスとのために使用される。1つまたは複数のPUを有する所与のCUは、1つまたは複数の変換ユニット(TU)を含む場合もある。予測の後に、ビデオエンコーダ20は、PUに対応する残差値を計算し得る。残差値は、エントロピーコーディングのためのシリアル化変換係数を生成するために、TUを使用して変換係数に変換され、量子化され、走査され得るピクセル差分値を備える。本開示は、一般に、CUのコーディングノードを指すために「ビデオブロック」という用語を使用する。いくつかの特定の場合において、本開示は、コーディングノードとPUとTUとを含む、ツリーブロック、すなわち、LCUまたはCUを指すために「ビデオブロック」という用語を使用する場合もある。
[0057]たとえば、現在開発中の高効率ビデオコーディング(HEVC)規格に従うビデオコーディングでは、(ピクチャとも呼ばれる)ビデオフレームがコーディングユニット(CU)と予測ユニット(PU)と変換ユニット(TU)とに区分され得る。CUは、概して、ビデオ圧縮のために様々なコーディングツールが適用される基本ユニットとして働く画像領域を指す。CUは、一般に正方形の形状を有し、たとえば、ITU−T H.264などの他のビデオコーディング規格の下でのいわゆる「マクロブロック」と同様であると見なされ得る。
[0058]より良いコーディング効率を達成するために、CUは、それが含んでいるビデオデータに応じて可変サイズを有し得る。すなわち、CUは、より小さいブロックまたはサブCUに区分または「分割」され得、その各々はCUと呼ばれることもある。さらに、サブCUに分割されない各CUは、それぞれ、CUの予測および変換のために1つまたは複数のPUとTUとにさらに区分され得る。
[0059]PUは、H.264などの他のビデオコーディング規格の下でのいわゆるブロックのパーティションと同様であると見なされ得る。PUは、「残差」係数を生成するためにブロックについての予測が実行されるベースである。CUの残差係数は、CUのビデオデータと、CUの1つまたは複数のPUを使用して決定されたCUについての予測データとの間の差を表す。詳細には、1つまたは複数のPUは、CUが予測のためにどのように区分されるかを指定し、CUの各パーティション内に含まれているビデオデータを予測するためにどの予測モードが使用されるかを指定する。
[0060]CUの1つまたは複数のTUは、CUのための残差変換係数のブロックを生成するために、ブロックにどの変換が適用されるかに基づいて、CUの残差係数のブロックのパーティションを指定する。1つまたは複数のTUはまた、適用される変換のタイプに関連し得る。変換は、残差係数をピクセル領域または空間領域から周波数領域などの変換領域に変換する。さらに、1つまたは複数のTUは、量子化残差変換係数のブロックを生成するために残差変換係数の得られたブロックにどの量子化が適用されるかに基づいてパラメータを指定し得る。残差変換係数は、場合によっては、係数を表すために使用されるデータの量を低減するために量子化され得る。
[0061]CUは、一般に、Yとして示される1つのルミナンス成分とUおよびVとして示される2つのクロミナンス成分とを含む。言い換えれば、サブCUにさらに分割されない所与のCUは、Y成分とU成分とV成分とを含み得、その各々は、前に説明したように、CUの予測および変換のために1つまたは複数のPUとTUとにさらに区分され得る。たとえば、ビデオサンプリングフォーマットに応じて、サンプルの数で表されるU成分およびV成分のサイズは、Y成分のサイズと同じであるかまたはそれとは異なり得る。したがって、予測、変換、および量子化に関して上記で説明した技法は、所与のCUのY成分、U成分およびV成分の各々について実行され得る。
[0062]CUを符号化するために、CUの1つまたは複数のPUに基づいて、CUのための1つまたは複数の予測子が最初に導出される。予測子は、CUについての予測データを含んでいる参照ブロックであり、前に説明したように、CUのための対応するPUに基づいて導出される。たとえば、PUは、予測データが決定される際の対象となるCUのパーティションと、予測データを決定するために使用される予測モードとを示す。予測子は、イントラ(I)予測(すなわち、空間的予測)モードまたはインター(PまたはB)予測(すなわち、時間的予測)モードのいずれかを通して導出され得る。したがって、いくつかのCUは、同じフレーム中の隣接参照ブロックまたはCUに対する空間的予測を使用してイントラコーディング(I)され得るが、他のCUは、他のフレーム中の参照ブロックまたはCUに対してインターコーディング(PまたはB)され得る。
[0063]CUの1つまたは複数のPUに基づいて1つまたは複数の予測子を識別するときに、1つまたは複数のPUに対応するCUの元のビデオデータと1つまたは複数の予測子中に含まれているCUについての予測データとの間の差が計算される。予測残差とも呼ばれるこの差は、残差係数を備え、前に説明したように、1つまたは複数のPUと1つまたは複数の予測子とによって指定されたCUの部分間のピクセル差分を指す。残差係数は、概して、1つまたは複数のPUoCUに対応する2次元(2D)アレイに構成される。
[0064]さらなる圧縮を達成するために、予測残差は、概して、たとえば、離散コサイン変換(DCT)、整数変換、カルーネンレーベ(Karhunen-Loeve)(K−L)変換、または別の変換を使用して変換される。変換は、同じく前に説明したように、空間領域中の予測残差、すなわち、残差係数を変換領域、たとえば、周波数領域中の残差変換係数に変換する。変換係数はまた、概して、CUの1つまたは複数のTUに対応する2Dアレイに構成される。さらなる圧縮のために、残差変換係数は、同じく前に説明したように、場合によっては、係数を表すために使用されるデータの量を低減するために量子化され得る。
[0065]またさらなる圧縮を達成するために、エントロピーコーダは、コンテキスト適応型可変長コーディング(CAVLC:Context Adaptive Variable Length Coding)、コンテキスト適応型バイナリ算術コーディング(CABAC)、確率間隔区分エントロピーコーディング(PIPE:Probability Interval Partitioning Entropy Coding)、または別のエントロピーコーディング方法を使用して、得られた残差変換係数を後で符号化する。エントロピーコーディングは、他のCUと比較して、係数によって表される、CUのビデオデータに固有の統計的冗長性を低減または除去することによって、このさらなる圧縮を達成し得る。
[0066]ビデオシーケンスは、一般に、一連のビデオフレームまたはピクチャを含む。ピクチャグループ(GOP)は、一般に、ビデオピクチャのうちの一連の1つまたは複数を備える。GOPは、GOP中に含まれるいくつかのピクチャを記述するシンタックスデータを、GOPのヘッダ中、ピクチャのうちの1つもしくは複数のヘッダ中、または他の場所に含み得る。ピクチャの各スライスは、それぞれのスライスのための符号化モードを記述するスライスシンタックスデータを含み得る。ビデオエンコーダ20は、通常、ビデオデータを符号化するために、個々のビデオスライス内のビデオブロックに対して動作する。ビデオブロックは、CU内のコーディングノードに対応し得る。ビデオブロックは、固定サイズまたは可変サイズを有し得、指定のコーディング規格に応じてサイズが異なり得る。
[0067]一例として、HMは、様々なPUサイズでの予測をサポートする。特定のCUのサイズが2N×2Nであると仮定すると、HMは、2N×2NまたはN×NのPUサイズでのイントラ予測をサポートし、2N×2N、2N×N、N×2N、またはN×Nの対称的なPUサイズでのインター予測をサポートする。HMはまた、2N×nU、2N×nD、nL×2N、およびnR×2NのPUサイズでのインター予測のための非対称区分をサポートする。非対称区分では、CUの一方向は区分されないが、他の方向は25%と75%とに区分される。25%の区分に対応するCUの部分は、「n」とその後ろに付く「Up」、「Down」、「Left」、または「Right」という表示によって示される。したがって、たとえば、「2N×nU」は、上部の2N×0.5N PUと下部の2N×1.5N PUとで水平方向に区分された2N×2N CUを指す。
[0068]本開示では、「N×N(NxN)」および「N×N(N by N)」は、垂直寸法および水平寸法に関するビデオブロックのピクセル寸法、たとえば、16×16(16x16)ピクセルまたは16×16(16 by 16)ピクセルを指すために互換的に使用され得る。一般的に、16×16ブロックは、垂直方向に16個のピクセルを有し(y=16)、水平方向に16個のピクセルを有する(x=16)。同様に、N×Nブロックは、概して、垂直方向にN個のピクセルを有し、水平方向にN個のピクセルを有し、ここでNは非負整数値を表す。ブロック中のピクセルは行と列とに構成され得る。その上、ブロックは、必ずしも、水平方向において垂直方向と同じ数のピクセルを有する必要はない。たとえば、ブロックはN×Mピクセルを備えてよく、この場合に、Mは必ずしもNに等しいとは限らない。
[0069]CUのPUを使用したイントラ予測コーディングまたはインター予測コーディングの後に、ビデオエンコーダ20は、CUのTUのための残差データを計算し得る。PUは、(ピクセル領域とも呼ばれる)空間領域においてピクセルデータを備え得、TUは、変換、たとえば、残差ビデオデータへの離散コサイン変換(DCT)、整数変換、ウェーブレット変換、または概念的に同様の変換の適用後に、変換領域において係数を備え得る。残差データは、符号化されていないピクチャのピクセルと、PUに対応する予測値との間のピクセル差分に対応し得る。ビデオエンコーダ20は、CUのための残差データを含むTUを形成し、次いで、CU用の変換係数を生成するために、TUを変換することができる。
[0070]変換係数を生成するための任意の変換の後に、ビデオエンコーダ20は、変換係数の量子化を実施し得る。量子化は、概して、係数を表すために使用されるデータの量をできるだけ低減するために変換係数が量子化され、さらなる圧縮を行うプロセスを指す。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。たとえば、量子化中にnビット値がmビット値に切り捨てられてよく、ここでnはmよりも大きい。
[0071]いくつかの例では、ビデオエンコーダ20は、エントロピー符号化され得るシリアル化ベクトルを生成するために、量子化変換係数を走査するためにあらかじめ定義された走査順序を利用し得る。他の例では、ビデオエンコーダ20は適応走査を実行し得る。量子化変換係数を走査して1次元ベクトルを形成した後に、ビデオエンコーダ20は、たとえば、コンテキスト適応型可変長コーディング(CAVLC)、コンテキスト適応型バイナリ算術コーディング(CABAC)、シンタックスベースコンテキスト適応型バイナリ算術コーディング(SBAC:syntax-based context-adaptive binary arithmetic coding)、確率間隔区分エントロピー(PIPE)コーディング、または別のエントロピー符号化方法に従って1次元ベクトルをエントロピー符号化し得る。ビデオエンコーダ20はまた、ビデオデータを復号する際にビデオデコーダ30が使用するための符号化されたビデオデータ(たとえば、符号化されたビデオデータに関連する情報)に関連するシンタックス要素をエントロピー符号化し得る。
[0072]CABACを実行するために、ビデオエンコーダ20は、送信されるべきシンボルに、コンテキストモデル内のコンテキストを割り当て得る。コンテキストは、たとえば、シンボルの隣接値が非0であるか否かに関係し得る。CAVLCを実行するために、ビデオエンコーダ20は、送信されるべきシンボルの可変長コードを選択し得る。VLCにおけるコードワードは、比較的短いコードが優勢シンボルに対応し、より長いコードが劣勢シンボルに対応するように構成され得る。このようにして、VLCを使用すると、たとえば、送信されるべき各シンボルのために等長コードワードを使用するよりも、ビット節約を実現し得る。確率決定は、シンボルに割り当てられたコンテキストに基づくことができる。
[0073]ビデオエンコーダ20およびビデオデコーダ30は、本開示で説明する技法を実装するように構成され得る。ビデオエンコーダ20およびビデオデコーダ30は、一般にビデオコーダと呼ばれることがある。本開示の例では、ビデオコーダは、動きベクトル範囲および行/列遅延のうちの少なくとも1つを決定することができ、決定に基づいてブロックをインター予測することができる。いくつかの例では、ビデオコーダは、1つまたは複数の制約に基づいて、異なるビュー中のピクチャおよび異なるレイヤ中のピクチャのうちの少なくとも1つにアクセスすることができ、アクセスされたピクチャに基づいて、ブロックをビュー間またはレイヤ間予測することができる。
[0074]たとえば、上記はHEVC規格に関する技法について説明した。本開示は、高効率ビデオコーディング(HEVC)規格と、SHVCと呼ばれることがあるスケーラブルビデオコーディング(SVC)ならびにMV−HEVCおよび3DV−HEVCと呼ばれることがあるマルチビュービデオコーディング(MVC、3DV)のようなHEVCの拡張とに関係し得る。ただし、本開示で説明する技法は、任意の特定の規格に限定されると見なされるべきではなく、任意の規格または任意の拡張の説明は、単に例示のために提供されている。
[0075]ビデオコーディング規格は、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)拡張とを含む(ISO/IEC MPEG−4 AVCとしても知られる)ITU−T H.264を含む。マルチビュービデオコーディング(MVC)はH.264/AVCの拡張である。MVC拡張の最近の公的に入手可能な共同ドラフトは、「Advanced video coding for generic audiovisual services」、ITU−T勧告H.264、2010年3月に記載されている。MVC拡張のさらに最近の公的に入手可能な共同ドラフトは、「Advanced video coding for generic audiovisual services」、ITU−T勧告H.264、2011年6月に記載されている。MVC拡張の現在の共同ドラフトは、2012年1月時点で承認されている。
[0076]本開示では、「マルチビュービデオコーディング」という句は、完全に書かれたときには、一般的に、マルチビューが存在するビデオコーディングを指す。頭文字MVCは、より具体的に、H.264/AVCのMVC拡張またはHEVCのMVC拡張(HEVCベースのMVCまたはMV−HEVC)を指すために使用され得る。他のマルチビュービデオコーディング技法が、HEVCの3DV拡張(HEVCベースの3DVまたは3DV−HEVC)において説明されている。
[0077]本開示で説明する技法は、マルチビュービデオコーディングならびにスケーラブルビデオコーディングに適用可能である。たとえば、HEVC規格が最近確定されており、HEVC規格の拡張ならびにHEVCに基づく規格についての議論が進行中である。マルチビュービデオコーディングの場合、HEVC規格の拡張は、MV−HEVC(深度のないマルチビュー)と3D−HEVC(深度のあるマルチビュー)とを含む。また、3DV規格はHEVC規格に基づく。スケーラブルビデオコーディングの場合、HEVC規格の拡張はSHVCを含む。本開示で説明する技法は、これらの規格のすべてに適用可能であり、概して、規格に基づくかどうかにかかわらず、ビデオコーディングのための任意の技法に適用可能である。
[0078]マルチビュービデオコーディングでは、複数のピクチャをそれぞれ含む複数の異なるビューが存在する。ビューのうちの1つはベースビューと呼ばれ、他のビューは従属ビューと呼ばれる。ビデオエンコーダ20またはビデオデコーダ30は、ベースビュー中のピクチャを、従属ビュー中のピクチャをインター予測するために利用することがあるが、ビデオエンコーダ20またはビデオデコーダ30は、従属ビュー中のピクチャを、ベースビュー中のピクチャをインター予測するために利用することはない。ビデオエンコーダ20またはビデオデコーダ30は、従属ビュー中のピクチャを、別の従属ビュー中のピクチャをインター予測するために利用することがある。言い換えれば、ビデオエンコーダ20またはビデオデコーダ30は、ベースビュー中のピクチャを別のビュー中のピクチャによりインター予測することはないが、従属ビュー中のピクチャを他のビュー(すなわち、ベースビューまたは他の従属ビュー)中のピクチャによりインター予測することがある。ピクチャが別のビュー中のピクチャによりインター予測されるとき、他のビュー中のピクチャは、ビュー間参照ピクチャと呼ばれる。
[0079]ビデオエンコーダ20またはビデオデコーダ30がベースビュー中のピクチャをベースビュー中の別のピクチャによりインター予測することがあり、同様に、ビデオエンコーダ20またはビデオデコーダ30が従属ビュー中のピクチャを同じ従属ビュー中の別のピクチャによりインター予測することがあることを理解されたい。これらの場合、インター予測に使用されるピクチャは、インター予測されているピクチャと同じビュー中にあるので、インター予測に使用されるピクチャは、ビュー間参照ピクチャではない。
[0080]スケーラブルビューコーディングでは、複数のレイヤが存在する。レイヤのうちの1つはベースレイヤと呼ばれ、他のレイヤはエンハンスメントレイヤと呼ばれる。マルチビュービデオコーディングと同様に、ビデオエンコーダ20またはビデオデコーダ30は、ベースレイヤ中のピクチャを、エンハンスメントレイヤ中のピクチャをインター予測するために利用することがあるが、ビデオエンコーダ20またはビデオデコーダ30は、エンハンスメントレイヤ中のピクチャを、ベースレイヤ中のピクチャをインター予測するために利用することはない。ビデオエンコーダ20またはビデオデコーダ30は、インター予測されているピクチャがインター予測に使用されるピクチャよりも上位のレイヤにある限り、エンハンスメントレイヤ中のピクチャを、別のエンハンスメントレイヤ中のピクチャをインターピクチャするために利用することがある。言い換えれば、スケーラブルビデオコーディングは、上位レイヤからのピクチャが下位レイヤからのピクチャによりインター予測され得るが、下位レイヤからのピクチャが上位レイヤからのピクチャによりインター予測され得ない階層コーディング手法と見なされ得る。しかしながら、場合によっては、下位レイヤからのピクチャは上位レイヤからのピクチャによりインター予測され得る。ベースレイヤは最下位レイヤであり、したがって、上位レイヤ中のピクチャがベースレイヤ中のピクチャをインター予測するために使用されることはない。ピクチャが別のレイヤ中のピクチャによりインター予測されるとき、他のレイヤ中のピクチャは、レイヤ間参照ピクチャと呼ばれる。
[0081]マルチビュービデオコーディングと同様に、ビデオエンコーダ20またはビデオデコーダ30がベースレイヤ中のピクチャをベースレイヤ中の別のピクチャによりインター予測することがあり、同様に、ビデオエンコーダ20またはビデオデコーダ30がエンハンスメントレイヤ中のピクチャを同じエンハンスメントレイヤ中の別のピクチャによりインター予測することがあることを理解されたい。これらの場合、インター予測に使用されるピクチャは、インター予測されているピクチャと同じレイヤ中にあるので、インター予測に使用されるピクチャは、レイヤ間参照ピクチャではない。
[0082]図2は、例示的なマルチビュービデオコーディング(MVC)復号順序を示すグラフ図である。図2は、MVCビットストリーム構造の例を示す。たとえば、典型的なMVC復号順序(すなわち、ビットストリーム順序)が図2に示されている。復号順序の構成は時間優先コーディングと呼ばれる。各アクセスユニットは、1つの出力時間インスタンスのためのすべてのビューのコーディングされたピクチャを含むように定義される。図2に示す復号順序は出力順序または表示順序と同じではないことがあることを理解されたい。
[0083]図2では、S0〜S7はそれぞれ、マルチビュービデオの異なるビューを指す。T0〜T8はそれぞれ、1つの出力時間インスタンスを表す。アクセスユニットは、1つの出力時間インスタンスについてのすべてのビューのコーディングされたピクチャを含み得る。たとえば、第1のアクセスユニットは、時間インスタンスT0についてのビューS0〜S7(すなわち、ピクチャ0〜7)のすべてを含み、第2のアクセスユニットは、時間インスタンスT1についてのビューS0〜S7(すなわち、ピクチャ8〜15)のすべてを含み、以下同様である。
[0084]図2では、ビューの各々はピクチャのセットを含む。たとえば、ビューS0はピクチャ0、8、16、24、32、40、48、56、および64のセットを含み、ビューS1はピクチャ1、9、17、25、33、41、49、57、および65のセットを含み、以下同様である。いくつかの例では、ビューの各ピクチャは2つのコンポーネントを含み、一方のコンポーネントはテクスチャビューコンポーネントと呼ばれ、他方のコンポーネントは深度ビューコンポーネントと呼ばれる。ビュー内のテクスチャビューコンポーネントおよび深度ビューコンポーネントは、互いに対応すると見なされ得る。たとえば、ビューのテクスチャビューコンポーネントは、そのビューの深度ビューコンポーネントに対応すると見なされ得、その逆も同様である(すなわち、深度ビューコンポーネントはセット中のそれのテクスチャビューコンポーネントに対応し、その逆も同様である)。本開示で使用する、テクスチャビューコンポーネントと、対応する深度ビューコンポーネントとは、単一のアクセスユニットの同じビューの一部であると見なされ得る。
[0085]テクスチャビューコンポーネントは、表示される実際の画像コンテンツを含む。たとえば、テクスチャビューコンポーネントは、ルーマ(Y)成分と、クロマ(CbおよびCr)成分とを含み得る。深度ビューコンポーネントは、それの対応するテクスチャビューコンポーネント中のピクセルの相対深度を示し得る。一例として、深度ビューコンポーネントは、ルーマ値のみを含むグレースケール画像と同様であり得る。言い換えれば、深度ビューコンポーネントは、任意の画像コンテンツを伝達するのではなく、テクスチャビューコンポーネント中のピクセルの相対深度の測定値を提供することができる。
[0086]たとえば、深度ビューコンポーネント中のピクセルについてのピクセル値は、0〜255の範囲にあり得る(たとえば、8ビット値)。いくつかの例では、より小さいピクセル値は、ピクセルが閲覧者の観点からより近いことを示すことができ、より大きいピクセル値は、ピクセルが閲覧者の観点からより遠いことを示すことができる。また、この8ビット値はグレースケールにマッピングし得る。たとえば、より小さいピクセル値は明るいピクセルにマッピングし、ここで0値は純粋に白いピクセルにマッピングする一方、より大きいピクセル値は暗いピクセルにマッピングし、ここで255の値は黒いピクセルにマッピングし、中間にあるピクセル値は異なるグレーレベルにマッピングする。したがって、ピクセルの深度を示すピクセル値は、ルーマ成分のみ(たとえば、グレースケールにマッピングする8ビット値)を必要とし得る。
[0087]深度を識別するためにルーマ値(たとえば、強度値)のみを使用する深度ビューコンポーネントは、例示のために提供され、限定するものと見なされるべきではない。いくつかの例では、テクスチャビューコンポーネント中のピクセルの相対深度を示すために任意の技法が利用され得る。
[0088]あらゆる例において深度ビューコンポーネントが必要であるとは限らない。たとえば、マルチビュービデオコーディングのいくつかの例では、深度ビューコンポーネントは存在しない。これらの例では、テクスチャビューコンポーネントとピクチャとは同義語であり得る。
[0089]マルチビュービデオコーディングによれば、テクスチャビューコンポーネントは、同じビュー中のテクスチャビューコンポーネントから、または1つもしくは複数の異なるビュー中のテクスチャビューコンポーネントからインター予測される。テクスチャビューコンポーネントは、「ビデオブロック」と呼ばれ、H.264コンテキストでは一般に「マクロブロック」と呼ばれる、ビデオデータのブロック中でコーディングされ得る。HEVC規格など、他のビデオコーディング規格は、ビデオブロックをツリーブロックまたはコーディングユニット(CU)と呼ぶ場合がある。
[0090]図2は、時間優先コーディングの一例を示しているが、いくつかの例では、図4に関してより詳細に説明するように、ピクチャが並列に符号化または復号されることが考えられ得る。たとえば、ビューS1の第1のピクチャ(たとえば、テクスチャビューコンポーネント、および場合によっては深度ビューコンポーネント)は、ビューS0の第1のピクチャによりインター予測され得る。たとえば、ビューS1の第1のピクチャ中のブロックは、ビューS0の第1のピクチャ中のブロックを予測ブロックとして使用することができ、ここでビューS1の第1のピクチャ中のブロックについての動きベクトルは、ビューS0の第1のピクチャ中の予測ブロックを指す。この意味で、ビューS0中の第1のピクチャは、インター予測の目的上、ビューS1中の第1のピクチャのための参照ピクチャであり得る。
[0091]場合によっては、ビューS1の第1のピクチャ中のブロックをビューS0の第1のピクチャ中のブロックによりインター予測するために、ビデオデコーダ30は、ビューS1の第1のピクチャの再構成を開始する前に(すなわち、ビューS1の第1のピクチャを復号する前に)、ビューS0の第1のピクチャを完全に再構成する(すなわち、ビューS0の第1のピクチャを完全に復号する)ことがある。並列復号では、ビデオデコーダ30は、ビューS0の第1のピクチャの復号と並列にビューS1の第1のピクチャの復号を開始することがある。
[0092]一般に、並列復号は、動きベクトル制限の概念に基づく。動きベクトル制限は、ブロックについての動きベクトルのx成分またはy成分のうちの少なくとも1つ(および場合によっては両方)に対する制限を指す。一例として、動きベクトル制限は、動きベクトル成分の範囲を定義し得る。
[0093]動きベクトル成分の定義された範囲の外にある参照ピクチャ中の任意のブロックは、現在のブロックをインター予測するために使用され得ない。一例として、動きベクトル制限は、y成分しきい値(Th)を定義し得る。この例では、現在のピクチャ中の任意のブロックについての動きベクトルのy成分は、Thよりも大きくなり得ない。これは、現在のピクチャ中のブロックに対して、垂直距離がThを超える参照ピクチャ中の任意のブロックは、現在のピクチャ中のブロックをインター予測するために使用され得ないことを意味する。
[0094]より詳細に説明するように、本開示で説明する技法は、ブロックについての導出された動きベクトルが動きベクトル制限に準拠することを確実にすることができる。たとえば、ビデオエンコーダ20は、ビデオデコーダ30が現在のブロックについての動きベクトルを導出する方法を定義する情報を含むビットストリームを出力用に生成することができる。本技法は、ビデオエンコーダ20がビットストリーム中に出力用に生成することができる情報を、ビデオデコーダ30がビットストリーム中の情報に基づいて現在のブロックについての動きベクトルを導出するときに、動きベクトル制限に違反する動きベクトルをビデオデコーダ30が導出しないように、制約することができる。言い換えれば、導出された動きベクトルが動きベクトル制限に準拠することを情報が確実にするように、ビットストリームは制約される。
[0095]その上、より詳細に説明するように、ビデオエンコーダ20によって出力用に生成されたビットストリームは、受信された値をさらに変換する必要なしにピクチャの並列復号をいつ開始すべきかを決定する目的でビデオデコーダ30が利用することができるユニットにおける並列復号遅延を指定する情報を含むことができる。たとえば、ビデオデコーダ30は、HEVCビデオコーディング技法の階層構造が必ずしも行に対応するとは限らないので、並列復号遅延が行のユニットにある場合に、ピクチャの並列復号をいつ開始すべきかを決定することが可能ではないことがある。より詳細に説明するように、ビデオエンコーダ20は、コーディングユニットサイズ(たとえば、LCUサイズ、最小コーディングユニット(SCU)サイズ)または固定サイズに基づいて、並列復号遅延を示す情報をシグナリングすることができる。
[0096]図3は、マルチビュービデオコーディング用の構造を示す概念図である。図3は、マルチビュービデオコーディング構造を示す。たとえば、図3に、マルチビュービデオコーディング用の典型的なマルチビュービデオコーディング予測(各ビュー内のピクチャ間予測とビュー間予測の両方を含む)構造が示され、ここでは矢印によって予測が示され、矢印の終点のオブジェクトは、予測参照のために矢印の始点のオブジェクトを使用する。マルチビュービデオコーディングでは、H.264/AVC動き補償のシンタックスを使用するが、異なるビュー中のピクチャが参照ピクチャとして使用されることを可能にする視差動き補償によって、ビュー間予測がサポートされる。
[0097]2つのビューのコーディングは、マルチビュービデオコーディングによってもサポートされる可能性があり、マルチビュービデオコーディングの利点の1つは、ビデオエンコーダ20が3Dビデオ入力として3つ以上のビューをとらえることができ、ビデオデコーダ30がそのようなマルチビュー表現を復号することができることである。したがって、ビデオデコーダ30のようなビデオデコーダをもつ任意のレンダラは、3つ以上のビューをもつ3Dビデオコンテンツを予想し得る。
[0098]マルチビュービデオコーディングでは、同じアクセスユニット中の(すなわち、同じ時間インスタンスをもつ)ピクチャ間でビュー間予測が可能になる。非ベースビューのうちの1つ中のピクチャをコーディングするとき、ピクチャが異なるビュー中にあるが同じ時間インスタンスをもつ場合、そのピクチャは参照ピクチャリストに追加され得る。ビュー間予測参照ピクチャは、任意のインター予測参照ピクチャと同様に、参照ピクチャリストの任意の位置に置かれ得る。ビュー間予測参照ピクチャが動き補償に使用されるとき、対応する動きベクトルは「視差動きベクトル」と呼ばれる。
[0099]図3では、ビューS0はベースビューと見なされ得、他のビューS1〜S7は従属ビューと見なされ得る。たとえば、ビューS0は、ビューS0中のピクチャが別のビュー中のピクチャによりビュー間予測されないので、ベースビューであり得る。しかしながら、ビューS0中のピクチャは、ビューS0中の他のピクチャによりインター予測され得る。他のビューは、これらの他のビュー中の少なくとも1つのピクチャがビュー間予測されるので、従属ビューであり得る。たとえば、ビューS1中の第1のピクチャは、ビューS0中の第1のピクチャおよびビューS2中の第1のピクチャによりビュー間予測される。従属ビュー中のいくつかのピクチャが同じビュー中の他のピクチャによりインター予測され得ることを理解されたい。
[0100]たとえば、「インター予測」という用語は、現在のピクチャ中のブロックが参照ピクチャ中のブロック(たとえば、参照ピクチャ中の予測ブロック)に基づいて予測される場合を指す。現在のピクチャ中のブロックについての動きベクトルは、参照ピクチャ中のブロックを指す。マルチビュービデオコーディングでは、参照ピクチャは、現在のピクチャと同じビュー中にあるピクチャまたは別のビュー中にあるピクチャであり得る。参照ピクチャが別のビュー中にある場合、参照ピクチャと現在のピクチャとは同じアクセスユニット中にある。たとえば、前述のように、アクセスユニットは、同じ時間インスタンスについての異なるビューのピクチャを含み、別のビュー中の参照ピクチャは、現在のピクチャと同じアクセスユニット中にあることが必要とされ得る。
[0101]参照ピクチャが現在のピクチャとは別のビュー中にあるとき、他のビュー中の参照ピクチャを指す動きベクトルは、視差動きベクトルと呼ばれる。また、参照ピクチャが現在のピクチャとは別のビュー中にあるとき、現在のピクチャ中のブロックは、ビュー間予測されると呼ばれ得る。言い換えれば、ビュー間予測では、現在のピクチャ中のブロックが、現在のピクチャを含むビュー以外のビュー中にある参照ピクチャ中のブロックを指す視差動きベクトルによりビュー間予測される。
[0102]インター予測(すなわち、ビュー間予測または同じビュー中のピクチャによるインター予測)を実行するために、ビデオエンコーダ20およびビデオデコーダ30は、1つまたは2つの参照ピクチャリスト(RefPicList0およびRefPicList1と呼ばれる)を構成することができる。ビデオエンコーダ20およびビデオデコーダ30は、参照ピクチャリスト中で識別されたピクチャをインター予測目的に利用することができる。本開示で説明する技法では、ビュー間参照ピクチャ(すなわち、符号化または復号されている現在のピクチャのビュー以外のビュー中にある参照ピクチャ)が、参照ピクチャリスト内の任意のロケーションに挿入され得る。ビデオエンコーダ20およびビデオデコーダ30が参照ピクチャリストを構成した(すなわち、RefPicList0とRefPicList1とを構成した)後、参照ピクチャリストへの参照インデックスが、参照ピクチャリスト中に含まれる任意の参照ピクチャを識別することができる。
[0103]たとえば、双予測ピクチャ(Bピクチャ)の場合、ビデオエンコーダ20は、双予測ピクチャを符号化するために使用された参照ピクチャを識別するRefPicList0へのインデックスとRefPicList1へのインデックスとをシグナリングすることができる。ビデオデコーダ30は、現在のピクチャを復号する(たとえば、再構成する)ために必要とした参照ピクチャ(RefPicList0からの1つおよびRefPicList1からの1つ)を決定するためにインデックスを利用することができる。単方向予測ピクチャ(Pピクチャ)の場合、ビデオエンコーダ20は、単方向予測ピクチャを符号化するために使用された参照ピクチャを識別するRefPicList0もしくはRefPicList1のうちの1つへのインデックス、またはRefPicList0へのインデックスのみ(その場合、ビデオデコーダ30はRefPicList1を再構成することはない)をシグナリングすることができる。ビデオデコーダ30は、現在のピクチャを復号する(たとえば、再構成する)ために必要とされる参照ピクチャを決定するためにインデックスを利用することができる。
[0104]一般に、Bピクチャ(双予測ピクチャ)の第1または第2の参照ピクチャリストについての参照ピクチャリスト構成は、2つのステップ、すなわち参照ピクチャリスト初期化と、参照ピクチャリスト並べ替え(修正)とを含む。参照ピクチャリスト初期化は、参照ピクチャメモリ(復号ピクチャバッファ(DPB)としても知られる)中の参照ピクチャを、POC(ピクチャの表示順で整列されるピクチャ順序カウント)値の順序に基づいてリストに入れる明示的機構である。参照ピクチャリスト並べ替え機構は、参照ピクチャリスト初期化中にリストに入れられたピクチャの位置を任意の新しい位置に修正すること、または参照ピクチャメモリ中の任意の参照ピクチャを、そのピクチャが初期化リストに属さなくても、任意の位置に入れることができる。参照ピクチャリスト並べ替え(修正)後のいくつかのピクチャは、リスト中のはるかに離れた位置に入れられる場合がある。ただし、ピクチャの位置が、リストのアクティブ参照ピクチャの数を超える場合、ピクチャは、最終参照ピクチャリストのエントリとは見なされない。アクティブ参照ピクチャの数は、各リスト用のスライスヘッダに入れてシグナリングされ得る。
[0105]図4は、2つのビューのための並列コーディングプロセスの一例を示すフロー図である。図4は、補足エンハンスメント情報(SEI)の並列コーディング(たとえば、復号)情報を示す。H.264/AVCのMVC拡張では、並列復号をサポートするSEIメッセージがある。ビューコンポーネントごとに、1つのマクロブロックを復号するとき、現在のビューと参照ビューとの2つの間に少なくとも2つのマクロブロック(MB)行遅延があることが考慮される。追加MB行のユニットにおける追加遅延が、各ビューおよびそれの参照ビューの各々についてSEIメッセージでシグナリングされる。このSEIメッセージの使用の一例が図4に示されている。
[0106]図4は、第2のビュー(ビュー1)のピクチャ42の復号と並列な第1のビュー(ビュー0)のピクチャ40の復号を示す。この例では、ピクチャ40は、ピクチャ42に対する参照ピクチャである(すなわち、ピクチャ40のブロックは、ピクチャ42のブロックをインター予測、特にビュー間予測するために使用される)。また、図4は、ピクチャ40がプロセッサP0によって復号されていることと、ピクチャ42がプロセッサP1によって復号されていることとを示す。プロセッサP0およびP1への言及は、ピクチャ40とピクチャ42とを復号するために実行した処理アルゴリズムを示すことである。プロセッサP0およびP1は、ビデオデコーダ30の一部であり得る。言い換えれば、図4は、ピクチャ40とピクチャ42とを並列に復号するビデオデコーダ30の一例を示している。
[0107]時間44において、ビデオデコーダ30は、復号プロセスを開始するが、ピクチャ42については、ビデオデコーダ30がピクチャ42の第1の行の復号を開始する前に遅延がある。たとえば、図4では、並列復号遅延は、マクロブロックの2行である。前述のように、いくつかの技法は、少なくとも、2行の復号遅延を必要とし得る。ビデオエンコーダ20は、SEIメッセージ中で正確な復号遅延をビデオデコーダ30にシグナリングすることができる。
[0108]時間46において、ビデオデコーダ30は、ピクチャ40のマクロブロックの第1の行を再構成するために、ピクチャ40のマクロブロックの第1の行を復号する。時間48において、ビデオデコーダ30は、ピクチャ40のマクロブロックの再構成された第1の行を、ビデオデコーダ30の復号ピクチャバッファ(DPB)に記憶する。時間50において、ビデオデコーダ30は、ピクチャ40のマクロブロックの第2の行を再構成するために、第2の行を復号する。時間52において、ビデオデコーダ30は、ピクチャ40のマクロブロックの再構成された第2の行を、ビデオデコーダ30のDPBに記憶する。また、時間52において、ビデオデコーダ30は、ピクチャ42の並列復号が開始できることを決定する。たとえば、第1の処理アルゴリズム(プロセッサP0)は、第2の処理アルゴリズム(プロセッサP1)に、(たとえば、プロセッサP1に制御信号「ビュー1通知」を送ることによって)ピクチャ42の並列復号が開始できることを通知する。
[0109]時間54において、ビデオデコーダ30は、ピクチャ40の第3の行を再構成するために、ピクチャ40の第3の行を復号し、並列に(たとえば、同時に)、ピクチャ42の第1の行を再構成するために、ピクチャ42の第1の行を復号する。時間56において、ビデオデコーダ30は、ピクチャ40の再構成された第3の行をDPBに記憶する。図示されていないが、ビデオデコーダ30は、ピクチャ42の再構成された第1の行をDPBに記憶することもできる。
[0110]また、時間56において、プロセッサP0はプロセッサP1に、ピクチャ42の次の行の復号が開始できることを通知する。時間58において、ビデオデコーダ30は、ピクチャ40の第4の行を再構成するために、ピクチャ40の第4の行を復号し、並列に(たとえば、同時に)、ピクチャ42の第2の行を再構成するために、ピクチャ42の第2の行を復号する。ビデオデコーダ30は、ピクチャ40とピクチャ42とを再構成するために、これらのステップを繰り返す。このようにして、ビデオデコーダ30は、ビューからの1つのピクチャ(たとえば、ビュー0のピクチャ40)が別のビューからの別のピクチャ(たとえば、ビュー1のピクチャ42)のための参照ピクチャである、異なるビューからの2つのピクチャの並列復号を実施することができる。
[0111]いくつかの例では、動きベクトル制限は並列復号を促進する。図4に示す例では、ピクチャ42中のブロックについての動きベクトルは、ピクチャ42中のブロックについての動きベクトルのy成分が1行の距離よりも大きくなり得ないように制限され得る。一例として、図4では、ビデオデコーダ30は、ピクチャ40の第3の行の復号と並列にピクチャ42の第1の行の復号を開始する(すなわち、ビデオデコーダ30は、ピクチャ42の第1の行を復号する前にピクチャ40の2行が再構成されるまで待機しなければならない)。この例では、ピクチャ42の第1の行中のブロックについての動きベクトルが、ピクチャ40の第2の行の後にあるブロックを指している場合、ビデオデコーダ30がピクチャ40のその行をまだ復号していないことがあるので、復号エラーがあり得る。動きベクトル制限がある場合、ビデオエンコーダ20は、ブロックのy成分が1行の距離よりも大きいピクチャ42のブロックについての動きベクトル値をビデオデコーダ30にシグナリングすることはない。
[0112]図4に示す例では、動きベクトル制限はピクチャ42についての動きベクトルのy成分についての1行であり得る。このようにして、ビデオデコーダ30がピクチャ40の第2の行を再構成した後、ビデオデコーダ30は、ピクチャ42中のブロックが、垂直距離がブロックから1行を超える参照ピクチャ中の任意のブロックを指さないので、ピクチャ42の復号を開始することが可能であり得る。したがって、動きベクトル制限は、並列復号遅延を示すものと見なされ得る。以下でより詳細に説明するように、いくつかの例では、ビデオデコーダ30によって実行されるフィルタ処理に基づいて、ビデオデコーダ30は、現在のピクチャ(たとえば、ピクチャ42)の再構成を開始する前に、参照ピクチャ(たとえば、ピクチャ40)の追加の行を再構成する必要があり得る。
[0113]図4の上記の例では、ビデオエンコーダ20およびビデオデコーダ30は、H.264/AVCのMVC拡張に従って機能し得る。しかしながら、動きベクトル制限および並列復号遅延に関係する技法が、HEVCベースのビデオコーディング技法に拡張されるとき、いくつかの問題があり得る。たとえば、異なるビューに参照ピクチャがあるときに動きベクトル制限を実施することに伴ういくつかの問題があることがあり、HEVCコーディング構造により並列復号遅延を示すための技法を利用することに伴ういくつかの問題があり得る。さらに、上記の例はマルチビュービデオコーディングについて説明されているが、本開示で説明する技法は、HEVCのスケーラブル拡張(たとえば、SHVC)を含むスケーラブルビデオコーディングにも拡張され得る。
[0114]スケーラブルビデオコーディング(SVC)では、多重レイヤがあり得る。最下位レベルにあるレイヤはベースレイヤ(BL)としてのみ働き、最上位レベルにあるレイヤはエンハンスメントレイヤ(EL)としてのみ働き得る。中間にあるすべてのレイヤは、ELとBLの両方として働き得る。たとえば、中間にあるレイヤは、それの下のレイヤのためのELであり、同時にそれの上のレイヤのためのBLとしてのものであり得る。説明を簡単にするために、本開示は、現在の技法を示す際に、BLおよびELという2つのレイヤがあることを仮定する。本開示で説明する技法は多重レイヤを伴う場合にも適用可能であることに留意されたい。
[0115]たとえば、上記の例は、従属ビューからのピクチャの現在のブロックが別のビュー(たとえば、ベースビュー)中の参照ピクチャによりインター予測されるビュー間予測の概念について説明した。いくつかの例では、レイヤ間予測において、エンハンスメントレイヤからのピクチャの現在のブロックが、別のレイヤ(たとえば、ベースレイヤ)中の参照ピクチャによりインター予測される。本開示で説明する技法では、動きベクトル制限および並列復号がスケーラブルビデオコーディング技法にも利用され得る。たとえば、レイヤ間ピクチャ(たとえば、ベースレイヤピクチャ)を指すエンハンスメントレイヤピクチャのブロックについての動きベクトル制限があり得る。また、2つのレイヤを並列復号する場合で、図4に関して上述した方法と同様の方法でインター予測目的(たとえば、レイヤ間予測目的)のために一方のレイヤが他方のレイヤを使用することが考えられ得る。
[0116]前述のように、マルチビュービデオコーディングの場合、異なるHEVCベースのマルチビュービデオコーディング拡張に関する進行中の議論がある。1つの例は、HEVCの3DV拡張であり、別の例は、HEVCのMV拡張である。たとえば、MPEGは、HEVCに基づいて3DVおよびMVの規格を開発しており、3DVおよびMVの規格に対して、規格化の取り組みの一部は、HEVCに基づくマルチビュービデオコーデックの規格化も含む。HEVCベースの3DVおよびMVでは、異なるビューからの再構成されたビューコンポーネントに基づくビュー間予測が有効にされる。
[0117]HEVCベースの3DVとHEVCベースのMVとの間の差異の1つは、ハイレベルシンタックスのみ(HLSのみ)という要件である。たとえば、AVCでは、マルチビュー拡張が、拡張が「HLSのみ」という要件を実際に満たすように行われた。「HLSのみ」という要件は、AVC中のマクロブロックレベルにおけるモジュールが再設計される必要がなく、マルチビュービデオコーディング(MVC)に完全に再使用され得ないように、MVCにおいてハイレベルシンタックス(HLS)の変更しか存在しないことを保証する。
[0118]このHLSのみ要件は、MV−HEVCに拡張されるが、3DV−HEVCには拡張されない。たとえば、MV−HEVC規格の1つの要件は、MV−HEVCがHEVC規格に対して、HLSのみ要件を満たすことであり得る。3DV−HEVC規格は、HLSのみ変更を必要としないことがある。3DV−HEVCはHLSのみ変更を必要としないが、HEVC規格に対してHLSのみ変更が行われた場合、結果は、3DV−HEVCに依然として準拠し得る。言い換えれば、「HLSのみ」という要件は、HEVCのMVC/3DV拡張に対して、また、マルチループ復号が受け入れ可能であると考えられる場合には、HEVCのスケーラブルビデオコーディング(SVC)拡張(SHVC)に対しても満たされ得ることが可能である。
[0119]ビュー間予測を可能にするために、最低限の、および場合によっては、必ずしも必要ではないが、HLSの変更が、以下のピクチャ識別目的のためのものであり、ここで参照ピクチャリストの構成および標識は、特定のビュー中のピクチャを識別することが可能である必要がある。たとえば、マルチビュービデオコーディングの場合、参照ピクチャリスト(RefPicList0およびRefPicList1)の一方または両方は、ビュー間ピクチャ(すなわち、符号化または復号されているピクチャと同じビュー中にないピクチャ)またはレイヤ間ピクチャ(すなわち、符号化または復号されているピクチャと同じレイヤ中にないピクチャ)を含み得る。
[0120]HLSの変更が、H.264/MVCにおける「HLSのみ」という要件を満たすには十分ではない場合、ローレベルコーディングモジュールが、HEVCのローレベルコーディングモジュールの構成目的とされていない機能を実施する必要がある(たとえば、無動きに関するスケーリングを処理する)状況に決して遭遇することがないように、他の制約、仮定が行われる。そのような制約、修正、および仮定は以下の通りである。(1)コロケートされたピクチャがビュー間(のみ)参照ピクチャである場合、時間的ダイレクトモードを無効にする、(2)ビュー間(のみ)参照ピクチャを、短期の、空間的ダイレクト関連ではないものと見なし、暗黙的重み付け予測を無効にする。
[0121]HLSのみHEVC拡張の1つの例は、MV−HEVCであり、MV−HEVCの最新のワーキングドラフトは、JCT3V−B1004、「MV−HEVC Draft Text 2」、G.Tech、K.Wegner、Y.Chen、M.Hannukselaであり、これはhttp://phenix.it−sudparis.eu/jct2/doc_end_user/documents/2_Shanghai/wg11/JCT3V−B1004−v1.zipで入手可能であり、その内容全体が参照により本明細書に組み込まれる。
[0122]本開示は、Nakagamiらによる「MV−HEVC:Vertical length restriction of inter−view vector for HEVC simple 3D extension」と題するJCT3V−B0037も参照し、これはhttp://phenix.it−sudparis.eu/jct2/doc_end_user/current_document.php?id=225から入手可能であり、その内容全体が参照により組み込まれる。JCT3V−B0037では、メモリ帯域幅要件を緩和し、デコーダをより並列に使いやすくするために、MV−HEVCにおける動きベクトルのポインティングを、垂直方向のベースビュー参照フレームに制限することが示唆されている。この制限は、次のようなSPSにおいてシグナリングされるフラグによって示されることが示唆されている。
(profile_idc==「マルチビューサポートプロファイル」)の場合
[0123]動きベクトル制限は並列復号に関して上述されているが、動きベクトル制限は、他の追加の、独立した理由により有用であり得る。言い換えれば、いくつかの例では、ビデオデコーダ30が並列復号を実施するように構成されない場合でも、動きベクトル制限は有用であるか、または望ましいことがある。
[0124]一例として、動きベクトル制限は、メモリ帯域幅の低減(たとえば、メモリアクセスおよび/またはアクセスされる必要のあるデータの量を低減すること)に有用であり得る。たとえば、動きベクトル制限がある場合、現在のピクチャを符号化または復号するために、ビデオエンコーダ20またはビデオデコーダ30が参照ピクチャからアクセスする必要があるデータの量は低減され得る。メモリ帯域幅は、予測ピクセルごとの参照ピクチャからのアクセスされるピクセルの数に基づいて推定され得る。たとえば、参照ピクチャ中でアクセスされるピクセルの数の低減により、メモリ帯域幅はより低くなる。多くの使用事例では、メモリ帯域幅はボトルネックと見なされることがあり、最悪ケースに備えたメモリ帯域幅の低減は有利と見なされ得る。たとえば、本技法は、他の技法と比べて、メモリアクセスを単純化、低減、または除去することができる。
[0125]たとえば、別のビュー中のピクチャを指す動きベクトルの垂直成分が制約されるとき、参照ビューピクチャのピクセルにアクセスすることによって必要とされるメモリ帯域幅は低減され得る。一例として、垂直成分(すなわち、動きベクトルのy成分)がより小さい値に制限される場合、補間目的のためにブロックの外の垂直方向における任意のピクセルにアクセスする必要はないことがある。
[0126]たとえば、ブロックについての動きベクトルは、参照ピクチャ中の整数ピクセルを指さず、代わりに、サブ整数ピクセル(ペルと呼ばれる)を指すことがある。ビデオエンコーダ20およびビデオデコーダ30は、これらのサブ整数ピクセルまたはペルを、参照ピクチャ中の隣接整数ピクセルのピクセル値を補間することによって生成する。たとえば、ビデオエンコーダ20およびビデオデコーダ30は、サブ整数ピクセルを補間するためにDPBから、動きベクトルによって指されるブロックの外に及ぶピクセルについてのピクセル値を含む、参照ピクチャについてのピクセル値にアクセスする。動きベクトル制限がある場合、ビデオエンコーダ20およびビデオデコーダ30は、補間のために動きベクトルが制限されるエリアの外に存在するピクセルについてのピクセル値にアクセスする必要はないことがあり、このことは、ビデオエンコーダ20およびビデオデコーダ30がそれぞれのDPBから取り出す必要があるデータの量を低減し、それによりメモリ帯域幅低減を促進する。
[0127]それでも、動きベクトルが動きベクトル制限に違反しないことを確実にするために、追加の態様が考慮される必要があり得る。たとえば、ビデオエンコーダ20は、ビデオデコーダ30がブロックについての動きベクトルを決定するために使用するブロックについての動きベクトルのx成分およびy成分をシグナリングしないことがある。代わりに、ビデオエンコーダ20は、ビデオデコーダ30が動きベクトルを導出するために使用する情報をシグナリングすることがある。
[0128]たとえば、ビデオデコーダ30は、マージ/スキップモードおよび高度動きベクトル予測(AMVP)モードの一部として、動きベクトル予測子に基づいて、現在のブロックについての動きベクトルを導出することができる。マージ/スキップモードおよびAMVPモードでは、ビデオエンコーダ20は、現在のブロックについての動きベクトルをシグナリングしないことがあるが、代わりに候補動きベクトル予測子のリストへのインデックスをシグナリングし得る。ビデオデコーダ30は、現在のブロックについての動きベクトルを、候補動きベクトル予測子のリストへのインデックスによって識別された動きベクトル予測子から導出することができる。
[0129]たとえば、マージ/スキップモードおよびAMVPモードでは、ビデオエンコーダ20およびビデオデコーダ30はそれぞれ、候補動きベクトル予測子のリストを構成する。ビデオエンコーダ20およびビデオデコーダ30は、候補動きベクトル予測子のそれぞれのリストを構成するために、リスト中で識別された候補動きベクトル予測子がビデオエンコーダ20とビデオデコーダ30の両方にとって同じになるように、実質的に同様の技法を実施することができる。
[0130]マージ/スキップモードおよびAMVPモードでは、ビデオエンコーダ20およびビデオデコーダ30は、隣接ブロックの動き情報に基づいて候補動きベクトル予測子のリストを構成する。隣接ブロックの例としては、空間的隣接ブロックおよび時間的隣接ブロックがある。空間的隣接ブロックは、現在のブロックに隣接し、現在のブロックと同じピクチャ中にあるブロックを指す。時間的隣接ブロックは、現在のブロックに隣接するが、別のピクチャ中にあるブロックを指す。現在のブロックについての動きベクトル予測子であり得る空間的隣接ブロックについての動きベクトルは、空間的動きベクトル予測子(SMVP)と呼ばれる。現在のブロックについての動きベクトル予測子であり得る時間的隣接ブロックについての動きベクトルは、時間的動きベクトル予測子(TMVP)と呼ばれる。
[0131]マージ/スキップモードまたはAMVPモードの両方では、ビデオエンコーダ20は、ビデオデコーダ30が受信する候補動きベクトル予測子のリストへのインデックスをシグナリングする。次いでビデオデコーダ30は、候補動きベクトル予測子のリストへのシグナリングされたインデックスから動き情報(たとえば、参照ピクチャおよび1つまたは複数の動きベクトル)を識別し、識別された動き情報に基づいて、現在のブロックについての動きベクトルを決定する。
[0132]たとえば、マージ/スキップモードでは、ビデオデコーダ30は、候補動きベクトル予測子のリストへのインデックスを受信し、シグナリングされたインデックスに基づいて、候補動きベクトル予測子のリストに記憶された動き情報を識別する。ビデオデコーダ30は、識別された動き情報から参照ピクチャリストと、参照インデックスと、動きベクトルとを決定する。次いでビデオデコーダ30は、識別された動き情報からの決定された参照ピクチャリストと、参照インデックスと、動きベクトルとを、現在のブロックについての動き情報として採用する。言い換えれば、現在のブロックは、候補動きベクトル予測子のリストへのインデックスによって識別されたブロックの動き情報を継承する。このようにして、ビデオデコーダ30は、動きベクトル予測子に基づいて現在のブロックについての動きベクトルを導出する(たとえば、ビデオデコーダ30は、現在のブロックについての動きベクトルを動きベクトル予測子に等しくセットする)。
[0133]いくつかの例では、マージ/スキップモードにおいて、候補動きベクトル予測子のリストへのインデックスによって識別されたブロックが時間的隣接ブロックを指す場合、ビデオデコーダ30は、この動きベクトル候補に関連する動き情報を採用することはない。ビデオデコーダ30は、参照ピクチャリストへの参照インデックスを決定する(たとえば、参照ピクチャリストの一方または両方へのインデックス0を選択する)ために、任意の既知の技法または開発されることになる任意の技法を利用することができる。本開示では、時間的隣接ブロックについての動きベクトルが動きベクトル予測子として使用されるときに、参照ピクチャリストへの参照インデックスとしてデフォルトインデックス(たとえば、インデックス0)が使用されるときなど、参照ピクチャリストに対するいくつかの制約があり得る。
[0134]このようにして、ビデオデコーダ30は、マージ/スキップモードにおいて現在のブロックについての動き情報を決定することができる。マージモードでは、ビデオデコーダ30はまた、現在のブロックと決定された動き情報によって指されるブロックとの間の残差データを受信することができ、ビデオデコーダ30は、現在のブロックのピクセル値を決定するために、残差データを利用することができる。スキップモードでは、ビデオデコーダ30は、現在のブロックと決定された動き情報によって指されるブロックとの間の残差データを受信することはない。この例では、ビデオデコーダ30は、残差データが0であると仮定する(すなわち、現在のブロックのピクセル値を、決定された情報によって指されるブロックのピクセル値に等しくなるようにセットする)ことができる。
[0135]AMVPモードはマージ/スキップモードと同様であり得るが、ビデオデコーダ30は、候補動きベクトル予測子のリストへのインデックスを受信することに加えて、ビデオエンコーダ20からの参照ピクチャリストについての参照インデックス値と動きベクトル差分とを受信することもできる。動きベクトル差分(MVD)は、候補動きベクトル予測子のリストへのインデックスによって識別されたブロックの動きベクトルと別の動きベクトル(たとえば、ビデオエンコーダ20によってベストマッチ探索に基づいて発見された動きベクトル)との間の動きベクトルの差であり得る。
[0136]たとえば、ビデオデコーダ30は、候補動きベクトル予測子のリストへのインデックスによって識別されたブロックの動きベクトルを決定することができる。ビデオデコーダ30は、現在のブロックについての動きベクトルを決定するために、候補動きベクトル予測子のリストへのインデックスによって識別されたブロックの動きベクトルの値を、シグナリングされた動きベクトル差分により加算または減算することができる。加えて、ビデオデコーダ30は、参照ピクチャリストを示すシグナリングされた情報およびその参照ピクチャリストへのシグナリングされたインデックスに基づいて、決定された動きベクトルが指す参照ピクチャを決定することができる。このようにして、ビデオデコーダ30は、AMVPモードにおいて現在のブロックについての動き情報を決定することができる。
[0137]前述のように、マージ/スキップモードおよびAMVPモードの場合、ビデオエンコーダ20およびビデオデコーダ30は、候補動きベクトル予測子のリストを構成する。以下では、候補動きベクトル予測子のリストを構成する例示的な方法について説明する。いくつかの例では、ビデオエンコーダ20およびビデオデコーダ30は、時間的隣接ブロックの動き情報が候補動きベクトル予測子のリスト中に含まれるべきである場合に、ピクチャ順序カウント(POC)値に基づいて時間的隣接ブロックの動きベクトル情報をスケーリングすることができる。
[0138]以下では、どの時間的動きベクトル予測子が候補動きベクトル予測子のリスト中に含むべきかをビデオエンコーダ20およびビデオデコーダ30が決定し得る方法に関するいくつかの説明を行う。時間的動きベクトル予測子(TMVP)を得るために、ビデオエンコーダ20およびビデオデコーダ30は最初に、コロケートされたピクチャを識別することができる。現在のピクチャがBスライス(たとえば、双予測スライス)である場合、ビデオエンコーダ20は、コロケートされたピクチャがどの参照ピクチャリストからのものであるか(たとえば、コロケートされたピクチャがRefPicList0からのものであるか、それともRefPicList1からのものであるか)を示すために、スライスヘッダ中でcollocated_from_l0_flagをシグナリングすることができる。ビデオデコーダ30は、コロケートされたピクチャがどの参照ピクチャからのものであるかを、スライスヘッダ中でシグナリングされたcollocated_from_l0_flagに基づいて決定することができる。
[0139]参照ピクチャリストが識別された後、ビデオエンコーダ20は、スライスヘッダ中のcollocated_ref_idxシンタックス要素が、識別された参照ピクチャリスト中のピクチャを識別することになることをシグナリングすることができる。collocated_ref_idxシンタックス要素は、ビデオエンコーダ20がビットストリーム中でシグナリングし得る情報の一例である。ビデオデコーダ30は、collocated_ref_idxシンタックス要素に基づいて、識別された参照ピクチャリスト中でピクチャを識別することができ、ここでこのcollocated_ref_idxシンタックス要素は、ビデオデコーダ30が受信するビットストリーム中の情報の一例である。
[0140]ビデオエンコーダ20およびビデオデコーダ30は、コロケートされたピクチャをチェックすることによって、コロケートされた予測ユニット(PU)を識別することができる。コロケートされたPUは、コロケートされた領域の右下PU(たとえば、BRブロック)、またはいわゆる「中央3」もしくはCRブロック(すなわち、コロケートされた領域の中央の右下PU)のいずれかであり得る。
[0141]ルーマロケーション(xP,yP)が、現在のピクチャの左上ルーマサンプルに対して現在のルーマ予測ブロックの左上サンプルを指定し、変数nPbWおよびnPbHが、それぞれ、ルーマ予測ブロックの幅および高さを指定すると仮定すると、BRブロックおよび中央3またはCRブロックは次のように定義され得る。
− コロケートされた領域の右下PU:
− (yP>>Log2CtbSizeY)が(yPRb>>Log2CtbSizeY)に等しく、xPRbがpic_width_in_luma_samples未満である場合、以下が当てはまる。
− コロケートされたPUは、colPicによって指定されたコロケートされたピクチャ内の((xPRb>>4)<<4,(yPRb>>4)<<4)によって与えられた修正ロケーションをカバーするルーマ予測ブロックを指定する。
− 中央3:
− 変数であるコロケートされたPUは、colPic内の((xPCtr>>4)<<4,(yPCtr>>4)<<4)によって与えられた修正ロケーションをカバーするルーマ予測ブロックを指定する。
[0142]いくつかの例では、ビデオエンコーダ20およびビデオデコーダ30が、AMVPまたはマージ/スキップモードで動き候補を生成するために上記のプロセスによって動きベクトルを識別したとき、ビデオエンコーダ20およびビデオデコーダ30は、(POC値によって反映された)時間的ロケーションに基づいて動きベクトルをスケーリングすることができる。HEVCでは、シーケンスパラメータセット(SPS)は、フラグsps_temporal_mvp_enable_flagを含み、スライスヘッダは、sps_temporal_mvp_enable_flagが1に等しいとき、フラグpic_temporal_mvp_enable_flagを含む。ある特定のピクチャに対してpic_temporal_mvp_enable_flagとtemporal_idの両方が0に等しいとき、復号順序においてその特定のピクチャの前にあるピクチャからの動きベクトルは、特定のピクチャ、または復号順序で特定のピクチャの後にあるピクチャの復号において、時間的動きベクトル予測子として使用されない。
[0143]動きベクトル制限を使用するとき、マージ/スキップモードまたはAMVPモードのいずれかにおいて動きベクトル予測子を使用する導出された動きベクトルが動きベクトル制限に準拠することを確実にすることに伴ういくつかの問題があり得る。たとえば、マージ/スキップモードにおいて、現在のブロックについての動きベクトルが動きベクトル予測子に等しくセットされた場合に、現在のブロックについての動きベクトルが動きベクトル制限に違反することが考えられ得る。別の例として、AMVPモードにおいて、動きベクトル予測子が動きベクトル差分により加算または減算された場合に、得られる導出された動きベクトルが動きベクトル制限に違反することが考えられ得る。以下でより詳細に説明する動きベクトル制限を使用することに伴う他の問題があり得る。
[0144]さらに、並列復号技法がHEVCベースのマルチビュービデオコーディング技法に拡張されるとき、いくつかの問題があり得る。たとえば、前述のように、H.264/AVCのMVC拡張の場合、ビデオエンコーダ20は、SEIメッセージ中で並列復号遅延情報をシグナリングし、並列復号される遅延は少なくとも2行である。しかしながら、HEVCベースの技法のコーディングユニットの階層構造が予定され、MV−HEVC、3DV−HEVC、またはSHVCには、マクロブロック行からブロック行への単純な拡張はない。
[0145]また、JCT3V−B0037において説明されている技法では、ビデオエンコーダは、垂直視差動きベクトル範囲(すなわち、y成分のための動きベクトル制限)をシグナリングし得る。しかしながら、LCU行の遅延を決定することは、ビデオデコーダにとって単純ではないことがある。ビデオデコーダは、一例として、LCUサイズに基づいて、LCU行遅延を計算する必要があり得る。言い換えれば、LCU行の値は、参照ピクチャとしてビュー間またはレイヤ間ピクチャを使用するピクチャの並列復号をいつ開始すべきかを決定するためにビデオデコーダ30が利用することができる値ではないことがあり、LCUサイズに基づく値にLCU行の値を追加的に変換することは、ビデオデコーダ30にとって、ピクチャの並列復号をいつ開始すべきかを決定するために必要とされ得る。しかしながら、LCU行に関して動きベクトル制限がシグナリングされる例には、ピクチャの並列復号をいつ開始すべきかを決定する統一的方法はないことがある。したがって、異なるビデオデコーダは異なる時間に並列復号を開始することがあり、これは復号エラーをもたらす可能性がある。
[0146]以下では、本開示による技法について説明する。たとえば、上記の問題および関連する問題、たとえば、動きベクトル制限に違反する動きベクトルを導出することに対処するためのマージ/スキップモードおよびAMVPモードについての様々な技法が提案した。本開示はまた、並列復号をいつ開始すべきかを決定するためにLCU行に依存することの上記限界に対処する、並列復号を改良するための技法について説明する。
[0147]特に、本開示は最初に、動きベクトル制限が利用されるときのメモリ帯域幅低減に関係する技法について説明する。次いで本開示は、並列復号のサポートに関係する技法について説明する。動きベクトル制限が利用されるときのメモリ帯域幅低減についての本開示で説明する技法は、並列復号についての本開示で説明する技法とは別個であり得ることを理解されたい。言い換えれば、ビデオデコーダ30が並列復号用に構成されていない場合でも、ビデオデコーダ30は依然として、本開示で説明するメモリ帯域幅低減技法を利用することができ、その逆も同様である。
[0148]前述のように、動きベクトル制限の1つの潜在的利益は、メモリ帯域幅低減である。たとえば、動きベクトル制限の利益は、参照ピクチャ(すなわち、現在のピクチャのブロックをインター予測するためにブロックが使用されるピクチャ)がビュー間参照ピクチャまたはレイヤ間参照ピクチャである例において実現され得るが、本開示で説明する技法はそのように限定されない。たとえば、動きベクトル制限は、ビュー間またはレイヤ間参照ピクチャのサブ部分(たとえば、ピクチャ全体よりも小さい部分)を指すように動きベクトルの範囲を制限する。垂直視差動きベクトルが制約されるとき、ピクチャのピクセルにアクセスするために必要とされるメモリ帯域幅が低減され得る。言い換えれば、別のビュー中のピクチャを指す(すなわち、ビュー間参照ピクチャを指す)動きベクトルの範囲y成分が制限される場合、ビュー間参照ピクチャを記憶しているDPBから取り出される必要のあるデータの量が低減され得る。たとえば、範囲垂直成分が比較的小さい値に制限される場合、ビデオエンコーダ20およびビデオデコーダ30は、補間目的のために動きベクトルによって指されるブロックのDPB出力に記憶されたビュー間参照ピクチャのピクセルのピクセル値にアクセスする必要はないことがある。同じことは、ビュー間参照ピクチャではなくレイヤ間参照ピクチャが使用される場合にも当てはまり得る。
[0149]説明しやすいように、動きベクトル制限によるメモリ帯域幅低減についての本開示で説明する技法は、参照ピクチャがビュー間またはレイヤ間参照ピクチャである例に関して説明される。さらに、いくつかの例では、HEVCに基づくスケーラブルビデオコーディング(SHVC)の場合、レイヤ間参照ピクチャを指す動きベクトルの一方または両方の成分(水平および垂直)は、常に0に制限され得る。いくつかの例では、HEVCに基づくマルチビュービデオコーディング(MV−HEVCまたは3DV−HEVC)の場合、ビュー間参照ピクチャを指す動きベクトルのための動きベクトル制限は選択可能であってよく、ビュー間参照ピクチャを指す動きベクトルのための制限範囲は選択可能であってよい。
[0150]前述のように、ビュー間またはレイヤ間参照ピクチャに関する動きベクトル制限を使用する問題のうちの1つは、動きベクトル予測子から導出された動きベクトルが動きベクトル制限に違反し得ることである。本開示で説明する技法によれば、ビデオエンコーダ20が出力用に生成し、ビデオデコーダ30が(すなわち、リンク16を介して、またはストレージデバイス34を介して)受信するビットストリームは、現在のブロックについての導出された動きベクトルが動きベクトル制限に違反しないように制約され得る。言い換えれば、導出された動きベクトルが動きベクトル制限に準拠することを情報が確実にするように、ビットストリームは制約される。
[0151]たとえば、本開示で説明する技法では、ビットストリームは、動きベクトルに動きベクトル制限を満たさないようにさせることになる、ビデオデコーダ30によるレイヤ間またはビュー間参照ピクチャでの動き補償に使用されることになる、動きベクトルまたは動きベクトルを形成する(すなわち、導出する)ために使用される他のシンタックスを含まないものする。言い換えれば、ビットストリームは、現在のブロックについての動きベクトルを動きベクトル予測子から導出するための情報を含み、ここで動きベクトルは、ビュー間またはレイヤ間参照ピクチャを指し、ここで動きベクトル制限は、ビュー間またはレイヤ間参照ピクチャのサブ部分を指すように動きベクトルの範囲を制限する。たとえば、動きベクトル成分(すなわち、水平成分すなわちx成分および/または垂直成分すなわちy成分)の一方または両方がビデオデコーダ30による動き補償のために0に制限される場合、ビットストリームは、動きベクトルの水平成分および/または垂直成分を非0にさせる、動きベクトルまたは動きベクトルを導出するためのシンタックスを含むことはない。
[0152]この例では、動きベクトルの範囲が0に制限され、このことは、導出された動きベクトルが、動きベクトル制限に準拠するように0の値を有しなければならないことを意味する。たとえば、動きベクトル制限は、ビュー間またはレイヤ間参照ピクチャのサブ部分を指すように動きベクトルを制限し、この例では、ビュー間またはレイヤ間参照ピクチャのサブ部分は、0の動きベクトルとなるように指されるものである。言い換えれば、動きベクトル制限は、ビュー間またはレイヤ間参照ピクチャ中の、現在のブロックが現在のピクチャに位置するのと同じ位置に位置するブロックのみを指すように動きベクトルを制限する。
[0153]ビデオデコーダ30は、マージ/スキップモードまたはAMVPモードにおいて動きベクトル予測子から動きベクトルを導出することができる。本開示で説明する技法では、参照ピクチャがビュー間またはレイヤ間参照ピクチャであるときに、マージ/スキップモードまたはAMVPモードにおいて導出された動きベクトルが動きベクトル制限に違反するような形で、ビデオデコーダ30に動きベクトル予測子から動きベクトルを導出させる情報(たとえば、シンタックス要素)をビットストリームが含むことはない。
[0154]たとえば、マージ/スキップモードでは、動き補償に使用されることになるマージ候補を識別するための候補動きベクトル予測子のリストへのマージインデックスを、ビデオエンコーダ20は出力用の生成されたビットストリーム中に含め、ビデオデコーダ30はビットストリームから受信する。候補動きベクトル予測子のリストへのインデックスにより、ビデオデコーダ30は、参照ピクチャリストと、参照ピクチャリストへのインデックスと、動きベクトルとを含む動き情報を決定することができる。
[0155]マージ/スキップモードでは、ビデオデコーダ30は、選択された動きベクトル予測子の動き情報を採用する(すなわち、動きベクトルを導出するために動きベクトル予測子に等しく動きベクトルをセットする)。この例では、ビデオエンコーダ20は、候補動きベクトル予測子のリストへのインデックスが、ビュー間またはレイヤ間参照ピクチャについての参照ピクチャリストへのインデックスを識別するかどうかを決定することができる。候補動きベクトル予測子のリストへのインデックスが、ビュー間またはレイヤ間参照ピクチャを指す動き情報を識別する場合、ビデオエンコーダ20は、候補動きベクトル予測子のリストへのインデックスによって識別された動きベクトル(すなわち、動きベクトル予測子)が動きベクトル制限に違反しているか、それとも動きベクトル制限に準拠しているかを決定することができる。動きベクトル予測子が動きベクトル制限に違反しているとビデオエンコーダ20が決定した場合、ビデオエンコーダ20は、動きベクトル制限に違反する導出された動きベクトルをもたらすことになる動きベクトル予測子をビデオデコーダ30に選択させることになる候補動きベクトル予測子のリストへのインデックスを含めることを回避すること(すなわち、含めないこと)ができる。
[0156]このようにして、マージ/スキップモードの場合、ビデオデコーダ30が受信するビットストリームおよびビデオエンコーダ20が出力用に生成するビットストリームは、動きベクトル制限に違反する現在のブロックについての動きベクトルをビデオデコーダ30に導出させる情報を含むことはない。動きベクトル制限は、動きベクトルがビュー間またはレイヤ間参照ピクチャを指すときのためのものであり得る。たとえば、候補動きベクトル予測子のリストへのインデックスによって識別される動き情報の動きベクトルは、マージモードにおいて制限を満たさなければならない。一例として、制限は、SHVCの場合のように、水平成分と垂直成分の両方が0であるというものであり得る。
[0157]言い換えれば、ビデオエンコーダ20は、値が動きベクトル制限に準拠する、動きベクトルを導出するために使用される、動きベクトル予測子を識別する候補動きベクトル予測子のリストへのインデックスを決定することができる。これは、ビデオ復号30が動きベクトルを導出するために動きベクトル予測子に等しく動きベクトルをセットすることになるからである。したがって、動きベクトルが値を採用する動きベクトル予測子は、動きベクトル制限に準拠することが必要とされる。ビデオエンコーダ20は、候補動きベクトル予測子のリストへのインデックスを出力用に生成することができ、ビデオデコーダ30が受信するビットストリーム中の情報は、候補動きベクトル予測子のリストへのインデックスを含む。
[0158]前述のように、AMVPは、マージ/スキップモードとは若干異なり得る。たとえば、マージ/スキップモードと同様に、ビデオエンコーダ20は、ビデオデコーダ30が動きベクトル予測子を選択する際の選択元となる候補動きベクトル予測子のリストへのインデックスをシグナリングし得る。マージ/スキップモードとは異なり、AMVPモードでは、ビデオデコーダ30は、現在のブロックについての動きベクトルとして、動きベクトル予測子を採用しない。代わりに、ビデオエンコーダ20は、ビットストリーム中で動きベクトル差分もシグナリングし、ビデオデコーダ30は、現在のブロックについての動きベクトルを導出するために、動きベクトル差分により動きベクトル予測子を加算または減算する。また、マージ/スキップモードとは異なり、AMVPモードでは、ビデオデコーダ30は、動きベクトル予測子の参照ピクチャリストおよび参照ピクチャリストインデックスを、参照ピクチャリストおよび参照ピクチャリストインデックスとして採用しない。代わりに、ビデオエンコーダ20は、参照ピクチャリストを識別し、参照ピクチャリストへのインデックスを識別する情報をシグナリングする。この情報から、ビデオデコーダ30は、現在のブロックについての動き情報を決定する。
[0159]AMVPモードでは、ビデオエンコーダ20は、ビデオエンコーダ20によって識別される参照ピクチャリストへの、ビデオエンコーダ20がシグナリングすべき参照ピクチャリストインデックスが、ビュー間またはレイヤ間参照ピクチャを識別するかどうかを決定することができる。参照ピクチャリストインデックスがビュー間またはレイヤ間参照ピクチャを識別する場合、ビデオエンコーダ20は、動きベクトル差分が動きベクトル予測子に加算された、または動きベクトル予測子から減算されたときに、導出された動きベクトルが動きベクトル制限に準拠するような動きベクトル差分をシグナリングし得る。
[0160]言い換えれば、ビデオエンコーダ20は、動きベクトルを導出するために使用される動きベクトル予測子を識別する候補動きベクトル予測子のリストへのインデックスを決定することができ、動きベクトル差分が動きベクトル予測子に加算されたときに、得られる動きベクトルが動きベクトル制限に準拠するように、動きベクトル差分を決定することができる。
[0161]ビデオエンコーダ20は、候補動きベクトル予測子のリストへのインデックスを出力用に生成することができ、ビデオデコーダ30が受信するビットストリーム中の情報は、候補動きベクトル予測子のリストへのインデックスを含む。ビデオエンコーダ20はまた、動きベクトル差分を出力用に生成することができ、ビデオデコーダ30が受信するビットストリーム中の情報は、動きベクトル差分を含む。
[0162]ビデオデコーダ30は、動きベクトルを導出するために使用される動きベクトル予測子を識別する候補動きベクトル予測子のリストへのインデックスを、受信されたビットストリームから決定することができ、値が、動きベクトル差分が動きベクトル予測子に加算されたときに、得られる動きベクトルが動きベクトル制限に準拠するようなものである動きベクトル差分を、受信されたビットストリームから決定することができる。ビデオデコーダ30は、動きベクトル予測子と動きベクトル差分とを加算することによって、動きベクトルを導出することができる。
[0163]ここでも、AMVPモードでは、候補動きベクトル予測子のリストへのインデックスが、動きベクトル予測子を選択するために使用され、参照ピクチャリストを識別する情報および参照ピクチャリストへの参照ピクチャリストインデックスを識別する情報も、参照ピクチャを選択するためにシグナリングされる。本開示で説明する技法では、ビデオエンコーダ20は、選択された参照ピクチャがビュー間またはレイヤ間参照ピクチャであるかどうかを決定することができる。選択された参照ピクチャがビュー間またはレイヤ間参照ピクチャである場合、ビデオエンコーダ20は、候補動きベクトル予測子のリストへのインデックスを介して選択された動きベクトル予測子に加算されたとき、または動きベクトル予測子から減算されたときに、動きベクトル制限に準拠する動きベクトルをビデオデコーダ30に導出させる動きベクトル差分を決定することができる。
[0164]一例として、レイヤ間参照ピクチャを指すブロックについての動きベクトルが0である(すなわち、x成分とy成分の両方が0である)ことを動きベクトル制限が要求すると仮定する。また、ビデオエンコーダ20が、候補動きベクトル予測子のリストへのインデックスを決定しており、ビデオデコーダ30が、候補動きベクトル予測子のリストへのインデックスから動きベクトル予測子(MVP)を識別したと仮定する。この例では、AMVPモードにおいて、ビデオエンコーダ20は、動きベクトル差分(MVD)がMVPに加算されたときに、得られる動きベクトルが0に等しくなる(すなわち、MVDのx成分がMVPのx成分の負であり、MVDのy成分がMVPのy成分の負である)ようなMVDをシグナリングすることができる。
[0165]このようにして、AMVPの場合、ビデオデコーダ30が受信するビットストリームおよびビデオエンコーダ20が出力用に生成するビットストリームは、動きベクトル制限に違反する現在のブロックについての動きベクトルをビデオデコーダ30に導出させる情報を含むことはない。動きベクトル制限は、動きベクトルがビュー間またはレイヤ間参照ピクチャを指すときのためのものであり得る。たとえば、動きベクトル差分は、導出された動きベクトルが動きベクトル制限に準拠するように動きベクトル予測子を補償することができる。言い換えれば、本開示で説明する技法では、合わせると動きベクトル制限を満たさないMVPおよびMVDがビットストリーム中に存在すべきではなく、ここでビットストリーム中の候補動きベクトル予測子のリストへのインデックスはMVPを識別し、ここでMVDはビットストリーム中に含まれる。
[0166]マージ/スキップモードおよびAMVPで動きベクトル制限を使用するとき、対処される必要があるいくつかの特別の場合があり得る。マージ/スキップモードでは、TMVPに関するさらなる制約が必要とされることがあり、AMVPモードでは、ビットストリーム中に含まれるフラグに関するさらなる制約が必要とされることがある。次に、各々についてより詳しく説明する。
[0167]前述のように、ビデオエンコーダ20およびビデオデコーダ30は、空間的隣接ブロックと時間的隣接ブロックとを含む隣接ブロックの動き情報に基づいて、候補動きベクトル予測子のリストを構成する。時間的隣接ブロックの動きベクトルは、時間的動きベクトル予測子(TMVP)と呼ばれる。空間的隣接ブロック(すなわち、SMVP)からの動きベクトル予測子の場合、空間的隣接ブロックが現在のブロックと同じピクチャ中にあるので、それらが指す参照ピクチャがピクチャの参照ピクチャリスト中で識別されるという保証がある。また、空間的隣接ブロックについての動きベクトルがビュー間またはレイヤ間参照ピクチャを指す場合、空間的隣接ブロックについての動きベクトルが動きベクトル制限に適合するという保証がある。
[0168]しかしながら、時間的隣接ブロックの動きベクトルの場合、動きベクトルが現在のピクチャの参照ピクチャリストのうちの1つにおける参照ピクチャを指すという保証はないことがある。さらに、時間的隣接ブロックについての動きベクトルが動きベクトル制限に違反することがある。
[0169]AMVPモードでは、参照ピクチャリストおよび参照インデックスがシグナリングされるので、TMVPが選択された場合でも、導出された動きベクトルは依然として、現在のピクチャの参照ピクチャリスト中で利用可能なピクチャを参照することになる。また、AMVPモードでは、TMVPが動きベクトル制限に違反する場合、動きベクトル差分は、導出された動きベクトルが動きベクトル制限に準拠するように、TMVPを補償することができる。
[0170]マージ/スキップモードでは、そのような制御がない(たとえば、TMVPが動きベクトル制限に違反する場合にTMVPを補償する方法がない)ことがある。したがって、マージ/スキップモードでは、TMVP(たとえば、時間的マージ候補)を選択することは、ビュー間またはレイヤ間参照ピクチャではない長期参照ピクチャを指す動きベクトルを時間的隣接ブロック(すなわち、コロケートされたブロック)が含み得るので、外部、動きベクトル範囲という動きベクトルをもたらす(すなわち、視差動きベクトルまたは別のレイヤを指す動きベクトルが動きベクトル制限に違反する)ことがある。
[0171]たとえば、マージ/スキップモードでは、TMVPが選択された場合、ビデオエンコーダ20およびビデオデコーダ30は、参照ピクチャリストと参照ピクチャリストインデックスとを決定する必要があり得る。マージ/スキップモードでは、ビデオエンコーダ20およびビデオデコーダ30は、TMVPの参照ピクチャリストと参照ピクチャリストインデックスとを使用するのではなく、デフォルト参照ピクチャリストとデフォルトインデックス(たとえば、HEVCにおけるインデックス0)とを利用することができる。TMVPに使用されるデフォルトインデックスは、デフォルトインデックスが必ずしもインデックス0に限定される必要はないので、TMVP参照インデックスと呼ばれることがある。
[0172]TMVPが動きベクトル制限に準拠することを確実にする1つの技法は、動きベクトルが動きベクトル範囲内に収まるように、ビデオエンコーダ20およびビデオデコーダ30が動きベクトルクリッピングを実施することである。しかしながら、そのようなTMVPクリッピングは、上述のハイレベルシンタックスのみ(HLSのみ)変更では許容されないピクチャのブロックレベルでのビデオコーディング変更を必要とすることになる。言い換えれば、TMVPクリッピングは、3DV−HEVCではうまく機能するが、MV−HEVCまたはSHVCではうまく機能しないことがある。
[0173]ブロックレベルの変更を回避し、HLSのみ要件に準拠するために、TMVPが動きベクトル制限の違反を引き起こさないように、参照ピクチャリストおよび/またはどのピクチャがインター予測に使用され得るかに対する追加の制約があり得る。一例として、ビデオエンコーダ20およびビデオデコーダ30は、ビュー間参照ピクチャではない通常の時間的長期参照ピクチャを、ビュー間予測を使用する任意のビュー(すなわち、任意のピクチャ)に使用することはない。同じことは、レイヤ間参照ピクチャでのレイヤ間予測を任意のレイヤに使用する任意のピクチャにも当てはまり得る。別の例として、ビデオエンコーダ20およびビデオデコーダ30がTMVP中に別のピクチャのためにコロケートされたピクチャ(たとえば、時間的ピクチャ)として使用する任意のピクチャは、長期参照(時間的)ピクチャを、それの参照ピクチャリストのうちのいずれの中にも有することができない。
[0174]別の例として、ビデオエンコーダ20およびビデオデコーダ30は、ビュー間またはレイヤ間参照ピクチャ(たとえば、ベースビューまたはベースレイヤからの参照ピクチャ)を、TMVP参照インデックスに等しい参照インデックスを有する参照ピクチャリスト中に含めることはない。たとえば、前述のように、TMVPについてのデフォルト参照インデックスはHEVCにおいて0(すなわち、参照ピクチャリスト中の最初のエントリ)である。いくつかの例では、ビデオエンコーダ20およびビデオデコーダ30は、ビュー間またはレイヤ間参照ピクチャを、参照ピクチャリストの0の参照インデックス中に含めることはない。
[0175]また別の例として、ビデオエンコーダ20およびビデオデコーダ30は、候補動きベクトル予測子のリストにTMVPを含めることを回避することができる。たとえば、ビデオエンコーダ20およびビデオデコーダ30は、動きベクトル制限が適用され、参照ピクチャリストのTMVP参照インデックス(たとえば、HEVCにおける0のインデックス)がビュー間またはレイヤ間参照ピクチャ(たとえば、ベースビュー中またはベースレイヤ中のピクチャ)を識別する場合、TMVPを無効にすることができる。
[0176]マージ/スキップモードについてのTMVPに対処するための上記技法は、単に例示のために提供されている。これらの技法は、別の技法とともに使用されること、または別個に使用されることがある。
[0177]AMVPモードの場合、動きベクトル差分(MVD)制御に関する追加の制約があり得る。前述のように、動きベクトル(たとえば、ベストマッチ探索を使用して発見されたもの)と動きベクトル予測子(MVP)との間の動きベクトル差分(MVD)を、ビデオエンコーダ20はシグナリングし、ビデオデコーダ30は受信する。HEVC規格は、RefPicList1中で識別されたピクチャについてのMVDがシグナリングされず、0であると推測されることを示すmvd_l1_zero_flagシンタックス要素を使用する。言い換えれば、mvd_l1_zero_flagが真(たとえば、デジタルの1)である場合、ビデオデコーダ30は、参照ピクチャがRefPicList1中にある場合に、MVDは0であると決定する。この場合、MVDは0であると推測されるので、導出された動きベクトルはMVPに等しい。
[0178]しかしながら、動きベクトル制限が有効化されている場合、動きベクトル制限に違反するMVPの成分を補償するためにMVDを使用する必要があり得る。たとえば、垂直MV成分が制限されることになる場合、ビデオデコーダ30がMVPの場合によっては大きい垂直成分をMVDにより補償して、垂直方向における最終的な導出された動きベクトルが動きベクトル制限を満たすようにすることが可能であるべきである。したがって、いくつかの例では、ビデオエンコーダ20は、動きベクトル制限が有効化されているときには常にMVDをシグナリングすることができ、mvd_l1_zero_flagは、動きベクトル制限により有効化されることはない。
[0179]したがって、いくつかの例では、mvd_l1_zero_flagに対する追加の制約が必要とされ得る。たとえば、mvd_l1_zero_flagは、ビュー間予測を使用する任意のビューコンポーネント(たとえば、テクスチャビューコンポーネントまたは深度ビューコンポーネント)について、常に0に等しくなるように制約され得る。別の例として、動きベクトル制限が有効化されている場合、ビデオエンコーダ20およびビデオデコーダ30は、mvd_l1_zero_flagの値を0に等しいと推測することができ、ビットストリーム中でmvd_l1_zero_flagの値を、ビデオエンコーダ20がシグナリングすることはなく、ビデオデコーダ30が受信することはない。 別の例として、mvd_l1_zero_flagは依然としてシグナリングされるが、無効化された値(たとえば、0)を伴うことがある。
[0180]別の例として、本技法は逆を適用し得る。たとえば、mvd_l1_zero_flagが真であるべきである場合、動きベクトル制限は有効化されることはない。言い換えれば、ビデオエンコーダ20は、mvd_l1_zero_flagが真である場合に、動きベクトル制限が有効化されていることを示す動きベクトル制限フラグをシグナリングすることはなく、mvd_l1_zero_flagが偽である場合にのみ、動きベクトル制限が有効化されていることを示す動きベクトル制限フラグをシグナリングすることができる。
[0181]ビデオエンコーダ20は、以下の方法で、mvd_l1_zero_flagが偽である場合にのみ、動きベクトル制限が有効化されていることを示すフラグをシグナリングする条件を実装し得る。
(profile_idc=「マルチビューサポートプロファイル」&&mvd_l1_zero_flag==偽)の場合
[0182]別の例として、単純化された技法は、動きベクトル制限が有効化されているときに、(AMVPモードにおける)明示的にシグナリングされる参照インデックスがビュー間またはレイヤ間参照ピクチャを指すことはできないというものであり得る。たとえば、AMVPモードでは、ビデオエンコーダ20は、動きベクトル制限が有効化されているかどうかを決定することができる。動きベクトル制限が有効化されている場合、ビデオエンコーダ20は、ビュー間またはレイヤ間参照ピクチャを指さない参照ピクチャリストへの参照インデックスを決定することができる。この例では、ビデオエンコーダ20がビュー間またはレイヤ間参照ピクチャを選択しないことになるので、mvd_l1_zero_flagは0に等しくなるように制約されなくてよい。したがって、導出された動きベクトルはビュー間またはレイヤ間参照ピクチャを指さないことになり、ここで動きベクトル制限は適用可能ではないことがある。
[0183]すぐ上の例示的な技法は、参照インデックスに対して制約的であると見なされ得る。この例では、ビデオエンコーダ20は、(負の垂直値成分は、参照ビューについてのすでに再構成されたブロックを指し得るので)絶対値または代替的に正の値のみを動きベクトル制限要件と比較することができる。動きベクトルが動きベクトル制限の条件で満たされない場合のみ、ビュー間またはレイヤ間参照ピクチャ(たとえば、ベースビューまたはベースレイヤ)を指す参照インデックスは、使用することが許されない。たとえば、mvd_l1_zero_flagが1に等しく、参照インデックスがビュー間またはレイヤ間参照ピクチャを指す場合の導出された動きベクトルが動きベクトル制限ルールに適合することが考えられ得る。mvd_l1_zero_flagが真である場合でも、導出された動きベクトルが動きベクトル制限ルールに適合する場合には、ビデオエンコーダ20は、ビュー間またはレイヤ間参照ピクチャを指す参照インデックスを選択することができる。
[0184]前述のように、マルチビュービデオコーディングの場合、動きベクトル制限の使用は、選択可能であってよく、動きベクトル制限が有効化されていることを示すフラグまたは他のシンタックス要素によりビットストリーム中で示され得る。スケーラブルビデオコーディングの場合、動きベクトル制限は、永続的に有効化されることがあり、いくつかの例では、動きベクトル制限要件は、導出された動きベクトルが0ベクトルである(たとえば、動きベクトルがレイヤ間参照ピクチャを指す場合に、導出された動きベクトルの水平(x)成分および垂直(y)成分が両方とも0に等しい)というものであり得る。
[0185]上述した例示的なMVD制御技法は、スケーラブルビデオコーディング技法(たとえば、SHVC)でも使用され得る。たとえば、動きベクトルが制約的である(たとえば、動きベクトル制限が使用されている)場合、ビデオエンコーダ20は、導出された動きベクトルが制約を満たす(たとえば、MV=MVD+MVP=0)ようにMVDによる動きベクトル予測子の補償を可能にするために、mvd_l1_zero_flagを0にセットすることができる。言い換えれば、ビデオエンコーダ20は、動きベクトル制限に違反する導出された動きベクトルをもたらすMVPとMVDとの組合せを回避することができる。
[0186]別の例として、ビデオエンコーダ20は、mvd_l1_zero_flagが有効化されている場合に、導出された動きベクトルに動きベクトル制限に違反させることになる動きベクトル予測子の選択を回避することができる。たとえば、mvd_l1_zero_flagが有効化されている場合、ビデオエンコーダ20は、制約(すなわち、動きベクトル制限)を満たすことができる動きベクトル予測子(たとえば、AMVP候補)のみを選択することができる。
[0187]たとえば、1つの例は、レイヤ間参照ピクチャについて、インター予測を形成するために使用されるMVを0に制限することができる。これは、AMVPモードの場合にMV=MVP+MVDが0であることを意味する。前述のように、ビデオデコーダ30は、ビデオエンコーダ20によってシグナリングされ、ビデオデコーダ30によって受信されたMVPインデックス(すなわち、候補動きベクトル予測子のリストへのインデックス)に基づいてMVPを決定する。参照リストL1(すなわち、RefPicList1)の場合、参照インデックスがレイヤ間参照ピクチャを指すとき、MVは0に等しくなるべきであるので、有効化されたmvd_l1_zero_flagにより、ビデオエンコーダ20は、値が0である(すなわち、水平成分および垂直成分が0に等しい)動きベクトル予測子を指す候補動きベクトル予測子のリストへのインデックスのみを選択することができる。このようにして、有効化されているmvd_l1_zero_flagから、MVDは0に等しいと推測されるので、MVPが0に等しいので、導出された動きベクトルは0に等しくなる(すなわち、MV=MVP+MVD、およびMVP=0、およびMVD=0、したがってMV=0)。したがって、ビデオエンコーダ20は、有効化されたmvd_l1_zero_flagと、レイヤ間参照ピクチャについて0に制約されたMVとにより、非0のAMVP候補(すなわち、MVPは0に等しくない)を使用するレイヤ間参照ピクチャを指す参照インデックスについて、MVPインデックス(すなわち、候補動きベクトル予測子のリストへのインデックス)を使用およびシグナリングすることはない。
[0188]別の例として、MV制約(すなわち、動きベクトル制限)を使用するレイヤについてmvd_l1_zero_flagが無効化される(0としてシグナリングされる)こともある。また別の例として、ビデオエンコーダ20は、ビュー間またはレイヤ間(たとえば、ベースビュー/レイヤ)についてのみmvd_l1_zero_flagをシグナリングすることができ、MV制約のあるエンハンスメントビュー/レイヤについて、mvd_l1_zero_flagシグナリングは省略されてよく、mvd_l1_zero_flagの値は0であると推測される。
[0189]別の例として、ビデオエンコーダ20は、参照ピクチャリストL1(RefPicList)が少なくとも1つのビュー間/レイヤ間参照ピクチャを含む場合、MV制約のあるエンハンスメントビュー/レイヤについて、0であるか、または0であると推測されるmvd_l1_zero_flagのみをシグナリングすることができる。また別の例として、ビデオエンコーダ20およびビデオデコーダ30は、参照ピクチャに従って別様にmvd_l1_zero_flagを扱うことができる。たとえば、参照ピクチャがビュー間/レイヤ間ピクチャである場合、mvd_l1_zero_flagに関係なく、ビデオエンコーダ20は常にMVD値をシグナリングすることができる。
[0190]同様の特徴はMVC拡張にも適用され得る。また、MVは、上記の例において0以外の他の値に対して制約的であってよく、制約は、垂直MV成分、水平MV成分、または両方について行われ得る。言い換えれば、動きベクトル制限は、導出された動きベクトルが非0値に制限されることを要求し得る。また、制限は、y成分のみ、x成分のみに適用可能であること、またはx成分とy成分の両方に適用可能であることがある。さらに、一方の成分の制限は必ずしも、他方の成分の制限に等しくなる必要はない。
[0191]一般に、いくつかの例では、ビデオエンコーダ20は、参照ピクチャリスト(たとえば、RefPicList1)中のピクチャについての動きベクトル差分が0ではないことをフラグの値(たとえば、mvd_l1_zero_flag)が常に示すことを決定することがあり、フラグの値を出力用に生成することがある。ビデオデコーダ30の観点から、ビデオデコーダ30は、参照ピクチャリスト中で参照ピクチャリスト(たとえば、RefPicList1)中で識別されたピクチャについての動きベクトル差分が0であるかどうかを示すフラグ値(たとえば、mvd_l1_zero_flag)を、受信されたビットストリームから決定し、参照ピクチャリスト中のピクチャについての動きベクトル差分が0ではないことをフラグ値が常に示すことを決定し得る。
[0192]いくつかの例では、動きベクトル制限では、ビュー間またはレイヤ間参照ピクチャ(たとえば、ベースビューまたはベースレイヤ参照ピクチャ)の配置は、TMVPに関して上述したビュー間またはレイヤ間参照ピクチャの配置に加えて、メモリ帯域幅低減に影響を与え得る。たとえば、メモリ帯域幅低減にとって重要なケースは、最悪ケースシナリオであり得る。あるいは、ビデオデコーダ30にとって、何らかの他の非最悪ケース条件が考慮される場合でも、最悪ケースの実装は依然として考慮される必要があることがあり、さもなければ、実際の単純化またはメモリ帯域幅低減は達成されないことがある。この目的で、動きベクトル制限(たとえば、マルチビュービデオコーディングの場合の視差動きベクトル範囲またはスケーラブルビデオコーディングの場合のレイヤ間動きベクトル範囲)から恩恵を受けるために、動きベクトル制限が適用されるときに、参照ピクチャに対するいくつかの制約があり得る。
[0193]たとえば、ビュー間予測を使用しないビューの各ビューコンポーネント(すなわち、テクスチャビューコンポーネントまたは深度ビューコンポーネント)についての異なる時間的参照ピクチャの最大数がmaxNumTempPics0であると仮定し、ビュー間予測によりコーディングされた各ビューコンポーネントについての異なる時間的参照ピクチャの最大数がmaxNumTempPics1であると仮定する。いくつかの例では、maxNumTempPics0はmaxNumTempPics1以下となるべきである。
[0194]そのため、ビュー間またはレイヤ間参照ピクチャ(たとえば、ベースビューまたはベースレイヤ参照ピクチャ)を指す動きベクトルの制限垂直成分による実際のメモリ帯域幅低減を行うためには、そのビュー間またはレイヤ間参照ピクチャは、少なくとも1つの参照リストに存在する必要があり得る。そうではなく、ビュー間またはレイヤ間参照ピクチャが参照ピクチャリストに挿入されていない場合、たとえば、他の時間的参照ピクチャが代わりに使用され得る場合、ビュー間またはレイヤ間参照ピクチャを指す動きベクトルのための動きベクトル制限は、この例では参照リスト中に参照ピクチャとしてすべての時間的ピクチャを有することになる最悪ケースに対処しない。
[0195]言い換えれば、動きベクトル制限が有効化されている場合、メモリ帯域幅低減などの動きベクトル制限の利益は、ビュー間またはレイヤ間参照ピクチャが参照ピクチャリストのうちの1つ中に含まれている場合にのみ実現可能であり得る。そうでない場合、参照ピクチャリスト中のすべてのピクチャは時間的ピクチャとなり、動きベクトル制限は適用可能ではなくなる。したがって、いくつかの例では、動きベクトル制限が有効化されている場合、ビデオエンコーダ20およびビデオデコーダ30は、少なくとも1つのビュー間またはレイヤ間参照ピクチャを参照ピクチャリストのうちの1つ中に含めることを必要とするように構成され得る。
[0196]参照ピクチャリストに対する1つの例示的な制約として、非ベースビューまたはレイヤ(たとえば、従属ビューまたは従属/エンハンスメントレイヤ)のすべてのビューコンポーネントは、最大で2つの時間的参照ピクチャと1つのビュー間またはレイヤ間参照ピクチャ(たとえば、ベースビューまたはベースレイヤ)とを有する。参照ピクチャリストに対する別の例示的な制約として、非ベースビューまたはレイヤのすべてのビューコンポーネントは、最大で2つの時間的参照ピクチャを有し、(1つのビュー間またはレイヤ間参照ピクチャにより)ビュー間またはレイヤ間予測されるビューコンポーネントもあれば、ビュー間またはレイヤ間予測されないビューコンポーネントもある。
[0197]前述のように、マルチビューコーディングの場合、動きベクトル制限の使用は選択可能であり得る。いくつかの例では、メモリアクセスを容易にするために、LCUごとにピクセルメモリが構成されているときは特に、視差動きベクトルが0の垂直成分を有するときに(または有するときにのみ)メモリ帯域幅低減の利益があり得る。視差動きベクトル範囲のシグナリングの単純化のために、いくつかの例では、ビデオエンコーダ20は、補足エンハンスメント情報(SEI)メッセージ、シーケンスパラメータセット、ビデオパラメータセット、またはビデオユーザビリティ情報(VUI:video usability information)メッセージ中で、視差動きベクトルのy成分が0に制限されることを示すフラグをシグナリングすることができる。
[0198]以下の擬似コードは、視差動きベクトルのy成分が0に制限されることを示すフラグをSEIメッセージ中に含めるための方法を示す。
[0199]1に等しいzero_vertical_disparity_mv_flagは、0に等しい垂直成分を視差動きベクトルが常に有することを示す。0に等しいzero_vertical_disparity_mv_flagは、0に等しくない垂直成分を視差動きベクトルが有し得ることを示す。
[0200]video_parameter_set_idは、ビュー間従属関係情報を含むビデオパラメータセットを指定する。video_parameter_set_idの値は、並列復号情報SEIメッセージを含むアクセスユニットのコーディングされたピクチャのビューコンポーネントによって参照されるvideo_parameter_set_idの値に等しいものとする。
[0201]pdi_init_delay_ctb_vertical_minus3およびpdi_init_delay_ctb_horizontal_minus2は、アクティブビデオパラメータセット識別子で指定されるようなビュー間予測を使用するコーディングされたビューコンポーネントによってビュー間参照に使用されないものとする任意の参照ビューコンポーネント中の利用不可能な参照エリアが、現在のSEIメッセージ中に含まれるシンタックス要素video_parameter_set_idに等しいことを指定する。
[0202]変数horCtbは次のように導出される。horCtb=pdi_init_delay_ctb_horizontal_minus2?pdi_init_delay_ctb_horizontal_minus2+2+(CtbAddrInRS%PicWidthInCtbsY):0。変数verCtbは次のように導出される。verCtb=CtbAddrInRS/PicWidthInCtbsY+pdi_init_delay_ctb_vertical_minus3+3。
[0203]pdi_init_delay_ctb_vertical_minus3は、存在しないときには−1と推測され、または同等に、verCtbは、CtbAddrInRS/PicWidthInCtbsY+2と推測される。
[0204]このようにして、ビットストリーム制約ルールは、以下の制限セットとして公式化され得る。(たとえば、マージ/スキップまたはAMVPモードから参照インデックスによって識別される)レイヤ間/ビュー間参照ピクチャでの動き補償に使用されるべき動きベクトルに対する制限がある場合、マージ/スキップモードが使用される場合には、動きベクトル制限を満たさない動きベクトルをもたらすことになるマージ/スキップインデックス(すなわち、マージ/スキップモードでの候補動きベクトル予測子のリストへのインデックス)を、またはAMVPモードが使用される場合には、動きベクトル制限を満たさない動きベクトルをもたらすことになるMVPインデックス(すなわち、AMVPモードでの候補動きベクトル予測子のリストへのインデックス)およびMVDを、ビットストリームは含むことはない(たとえば、含まないものとする)。さらに、MV=MVP+MVDが参照リストL1(RefPicList1)についてのMV制約(すなわち、動きベクトル制限)を満たすように非0のMVDを有することが必要とされ得るので、ビットストリームは、mvd_l1_zero_flagについて(このフラグが無効化されていることを意味して)非0値を含むことはない(たとえば、含まないものとする)。
[0205]たとえば、動きベクトルの一方または両方の成分がレイヤ間/ビュー間参照ピクチャについて0になるように制限される場合、マージモードの場合には、非0の動きベクトルもしくは動きベクトル成分をもたらすことになるマージインデックスを、またはAMVPモードの場合には、非0の動きベクトルもしくは動きベクトル成分をもたらすことになるMVPインデックスおよびMVDを、ビットストリームは含むことはない(たとえば、含まないものとする)。さらに、MV=MVP+MVDが参照リストL1(RefPicList1)について0に等しくなるように非0のMVDを有することが必要とされ得るので、ビットストリームは、mvd_l1_zero_flagについて(このフラグが無効化されていることを意味して)非0値を含むことはない(たとえば、含まないものとする)。
[0206]上述の制約の一部または全部は、ビットストリームに存在するシンタックス要素(たとえば、情報)に課せられ得る。たとえば、ビットストリームについての制約ルールは次のように公式化され得る。あらゆる参照ピクチャリストRefPicListXについて、Xは0または1のいずれかであり、マージインデックス(merge_idx)、MVPインデックス(mvp_lX_flag)、参照インデックス(ref_idx_lX)、MVD(MvdLX)、およびmvd_l1_zero_flagはMVに、動きベクトル制限を満たす動きベクトル成分、たとえば、いずれも0に等しい成分(たとえば、SHVCの場合)を提供するものとする。
[0207]言い換えれば、ビデオエンコーダ20およびビデオデコーダ30はそれぞれ、候補動きベクトル予測子のリストを構成することができる。マージ/スキップモードでは、ビデオエンコーダ20は、値が動きベクトル制限に準拠する、動きベクトルを導出するために使用される、動きベクトル予測子を識別する候補動きベクトル予測子のリストへのインデックスを決定することができ、候補動きベクトル予測子のリストへのインデックスを出力用に生成する。マージ/スキップモードでは、ビデオデコーダ30は、動きベクトルを導出するために使用される動きベクトル予測子を識別する候補動きベクトル予測子のリストへのインデックスを、受信されたビットストリームから決定することができる。この例では、ビデオデコーダ30は、動きベクトル予測子に等しく動きベクトルをセットすることができ、その上、動きベクトル予測子は、動きベクトル制限に準拠している。
[0208]AMVPモードの場合、ビデオエンコーダ20は、動きベクトルを導出するために使用される動きベクトル予測子を識別する候補動きベクトル予測子のリストへのインデックスを決定することができる。ビデオエンコーダ20は、動きベクトル差分が動きベクトル予測子に加算されたときに、得られる動きベクトルが動きベクトル制限に準拠するように、動きベクトル差分を決定することもできる。ビデオエンコーダ20は、候補動きベクトル予測子のリストへのインデックスと動きベクトル差分とを出力用に生成することもできる。AMVPモードでは、ビデオデコーダ30は、動きベクトルを導出するために使用される動きベクトル予測子を識別する候補動きベクトル予測子のリストへのインデックスを、受信されたビットストリームから決定することができ、その値が、動きベクトル差分が動きベクトルに加算されて、得られる動きベクトルが動きベクトル制限に準拠するようなものである動きベクトル差分を、受信されたビットストリームから決定する。ビデオデコーダ30は、動きベクトル予測子と動きベクトル差分とを加算することによって、動きベクトルを導出することができる。
[0209]説明はすべて、HLSのみソリューション(ブロックレベルでの変更がない)またはブロックレベルでの変更が許容されるHLSソリューションとして実現されるHEVC SVC拡張に有効である。ベースレイヤコーデックは、HEVC、AVC、MPEG−2などであり得る。制限は、垂直動きベクトル(MV)成分、水平MV成分、または両方に適用されることがあり、また、参照リストL0(RefPicList0)、参照リストL1(RefPicList1)、または両方を含み得る。しかしながら、SVCの場合、レイヤ間参照ピクチャを指すMVの両方の成分について、0の動きベクトルとする制限は、使用事例のうちの1つである。
[0210]したがって、いくつかの例では、ビデオエンコーダ20は、現在のブロックについての動きベクトルを動きベクトル予測子から導出するための、導出された動きベクトルが動きベクトル制限に準拠することを確実にする情報を決定するように構成され得る。これらの例では、動きベクトルは、ビュー間またはレイヤ間参照ピクチャ(たとえば、現在のブロックを含むピクチャに対する別のビューまたはレイヤ中のピクチャ)を指し得る。また、動きベクトル制限は、ビュー間またはレイヤ間参照ピクチャを指す動きベクトルに関連付けられる。
[0211]ビデオエンコーダ20は、情報に基づいて、現在のブロックについての動きベクトルを導出し、導出された動きベクトルに基づいて、現在のブロックをビュー間またはレイヤ間予測復号することができる。ビデオエンコーダ20はまた、動きベクトルを導出するための決定された情報を出力用に生成することもできる。
[0212]いくつかの例では、ビデオデコーダ30は、現在のブロックについての動きベクトルを動きベクトル予測子から導出するための情報を含むビットストリームを受信するように構成され得る。上記と同様に、動きベクトルは、ビュー間またはレイヤ間参照ピクチャを指し、動きベクトル制限は、ビュー間またはレイヤ間参照ピクチャを指す動きベクトルに関連付けられる。本開示で説明する技法では、ビットストリーム中の情報は、導出された動きベクトルが動きベクトル制限に準拠することを確実にする。
[0213]本開示で説明する技法では、ビデオデコーダ30は、ビットストリーム中の情報に基づいて、現在のブロックについての動きベクトルを導出することができる。ビデオデコーダ30はまた、導出された動きベクトルに基づいて、現在のブロックをビュー間またはレイヤ間予測復号することができる。
[0214]上記では、メモリ帯域幅低減のための動きベクトル制限に関して説明した。以下では、並列復号に関する技法について説明する。メモリ帯域幅低減のための動きベクトル制限に関して説明した技法は必ずしも、並列復号とともに使用される必要はない。言い換えれば、ビデオエンコーダ20およびビデオデコーダ30は、ビデオエンコーダ20およびビデオデコーダ30が並列復号を実施しない場合でも、動きベクトル制限を実施するように構成され得る。
[0215]前述のように、いくつかの技法は、並列復号遅延を示すためにマクロブロック行に依存している。しかしながら、マクロブロック行に依存することは、HEVCベースのビデオコーディング技法にとって実現可能ではないことがある。また、いくつかの技法は、LCU行における並列復号遅延をシグナリングしたが、そのような値は依然として、並列復号をいつ開始すべきかをビデオデコーダ30が決定できるように、LCUサイズに基づいて変換される必要があった。
[0216]たとえば、いくつかの技法は(たとえば、JCT3V−B0037において)動きベクトル制限を直接シグナリングした。動きベクトル制限のこの直接シグナリングは、動きベクトル成分の値の制限をシグナリングすることを意味する。そのような技法は、動きベクトル成分の値の制限をLCU行のユニットに変換することを必要とする可能性が非常に高く、このことは、一例として、LCUサイズに基づいてLCU行遅延が計算されることが依然として必要となるので、問題があり得る。
[0217]いくつかの例では、本開示で説明する技法によれば、ブロックサイズに基づくユニットにおける動きベクトル制限情報を、ビデオエンコーダ20はシグナリングすることができ、ビデオデコーダ30は受信することができる。動きベクトル制限情報に基づいて、ビデオデコーダ30は、並列復号をいつ開始すべきかを決定することができる。一例として、ビデオエンコーダ20は、ブロックサイズのユニットにおける動きベクトル制限の垂直動きベクトル範囲を出力用に生成することができ、ビデオデコーダ30は、ブロックサイズのユニットにおける動きベクトル制限の垂直動きベクトル範囲を、受信されたビットストリームから決定することができる。ブロックサイズのユニットは、最大コーディングユニットの高さおよび最小コーディングユニットの高さのユニットの1つを備え得る。ビデオデコーダ30は、垂直動きベクトル範囲に基づいて、ビュー間またはレイヤ間参照ピクチャと現在のブロックを含む現在のピクチャとを並列復号することができる。
[0218]たとえば、動きベクトル制限は、水平および垂直成分についての値の範囲を定義し得る。一例では、最大コーディングユニット(LCU)の高さまたは幅のユニットにおける垂直動きベクトル範囲または水平動きベクトル範囲(たとえば、垂直もしくは水平視差動きベクトル範囲またはレイヤ間参照ピクチャについての垂直もしくは水平動きベクトル範囲)を、ビデオエンコーダ20はシグナリングすることができ、ビデオデコーダ30は受信することができる。別の例として、最小コーディングユニット(SCU)のユニットにおける動きベクトル制限を、ビデオエンコーダ20はシグナリングすることができ、ビデオデコーダ30は受信することができる。また別の例として、4のユニットにおける動きベクトル制限を、ビデオエンコーダ20はシグナリングすることができ、ビデオデコーダ30は受信することができる。
[0219]いくつかの例では、垂直動きベクトル範囲が0に等しいか、またはほぼ0であることを動きベクトル制限が示す(0に等しいか、または0よりも小さい(たとえば、LCUの高さよりも小さい)垂直成分を動きベクトルが常に有することを意味する)場合のみ、ビデオエンコーダ20は水平動きベクトル範囲をシグナリングすることができる。いくつかの例では、ビデオエンコーダ20は常に水平動きベクトル範囲をシグナリングすることができる。
[0220]いくつかの例では、ビデオエンコーダ20がLCU行遅延を直接シグナリングすること考えられ得る。LCU行遅延は垂直遅延を示す。これらの例では、ビデオエンコーダ20がLCU行遅延をシグナリングするとき、ビデオエンコーダ20はLCU列遅延も直接シグナリングすることができる。LCU列遅延は水平遅延を示す。これらの例では、ビデオデコーダ30は、LCU行(垂直)遅延とLCU列(水平)遅延とをビットストリームから直接受信することができる。一例として、動きベクトル(たとえば、視差動きベクトルまたはレイヤ間参照ピクチャを指す動きベクトル)が通常小さい(たとえば、垂直成分では0および水平成分では−2)と見なされる場合、LCU行遅延は1にされてよく、LCU列遅延も同じくらい小さくされ得る(たとえば、1または2)。
[0221]上記の例では、ビデオエンコーダ20は、行または列に関する並列復号遅延(たとえば、LCU行遅延およびLCU列遅延)を直接シグナリングすることができる。行または列に関する並列復号遅延を直接シグナリングすることによって、動きベクトル成分に基づく動き制限を行または列に変換することは必要ではなくなることがある。言い換えれば、ビデオエンコーダ20は、LCU行遅延とLCU列遅延とをシグナリングする際に、LCUサイズまたはブロックのサイズをすでに考慮していることがある。
[0222]上記の例は、動きベクトル制限(たとえば、x成分およびy成分についての動きベクトル範囲またはLCU行もしくは列遅延)のシグナリングについて説明している。いくつかの例では、補足エンハンスメント情報(SEI)メッセージ中で動きベクトル制限を、ビデオエンコーダ20はシグナリングすることができ、ビデオデコーダ30は受信することができる。いくつかの例では、ビデオパラメータセット中で動きベクトル制限を、ビデオエンコーダ20はシグナリングすることができ、ビデオデコーダ30は受信することができる。いくつかの例では、シーケンスパラメータセット中で動きベクトル制限を、ビデオエンコーダ20はシグナリングすることができ、ビデオデコーダ30は受信することができる。いくつかの例では、ビデオユーザビリティ情報(VUI)メッセージ中で動きベクトル制限を、ビデオエンコーダ20はシグナリングすることができ、ビデオデコーダ30は受信することができる。
[0223]以下では、並列復号情報をシグナリングするための例示的な技法について説明する。たとえば、以下では、並列復号を実施するための例示的な擬似コードと擬似コードのためのセマンティクスとを提供する。これらの技法は、別個に、または連携して実施され得る。また、並列復号情報に関する以下で提供される例は、限定するものと見なされるべきではなく、単に例示のために提供される。さらに、説明しやすいように、本技法はマルチビュービデオコーディングに関して説明されるが、そのような技法はスケーラブルビデオコーディング技法にも拡張され得る。たとえば、説明が「ビュー間参照」などの用語を使用する場合、その用語はレイヤ間参照に置き換えられ得る。言い換えれば、ビュー間参照のための技法は、レイヤ間参照にも拡張され得る。
[0224]並列復号情報SEIメッセージシンタックスが以下で証明される。
[0225]video_parameter_set_idは、ビュー間またはレイヤ間従属関係情報を含むビデオパラメータセットを指定する。video_parameter_set_idの値は、並列復号情報SEIメッセージを含むアクセスユニットのコーディングされたピクチャのビューコンポーネントまたはレイヤコンポーネントによって参照されるvideo_parameter_set_idの値に等しいものとする。
[0226]pdi_init_delay_ctb_vertical_minus2およびpdi_init_delay_ctb_horizontal_minus2は、アクティブビデオパラメータセット識別子で指定されるようなビュー間またはレイヤ間予測を使用するコーディングされたビューコンポーネントによってビュー間またはレイヤ間参照に使用されないものとする任意の参照ビューコンポーネントまたはレイヤピクチャ中の利用不可能な参照エリアが、現在のSEIメッセージ中に含まれるシンタックス要素video_parameter_set_idに等しいことを指定する。
[0227]変数horCtbは次のように導出される。horCtb=pdi_init_delay_ctb_horizontal_minus2?pdi_init_delay_ctb_horizontal_minus2+2+(CtbAddrInRS%PicWidthInCtbsY):0。
[0228]変数verCtbは次のように導出される。
verCtb=CtbAddrInRS/PicWidthInCtbsY+pdi_init_delay_ctb_vertical_minus2+2。
[0229]refCtbAddrのrefCtbアドレスは次のように導出される。
refCtbAddr=Min(horCtb,PicWidthInCtbsY)+verCtb*PicWidthInCtbsY。
[0230]利用不可能な参照エリアは、refCtbAddr以上のコーディングツリーブロックアドレスすべてを含む。コーディングされたビューコンポーネントを復号するとき、参照ビューのビューコンポーネントからの利用不可能な参照エリアからのサンプルは、ビュー間またはレイヤ間予測プロセスによって参照されないものとする。
[0231]pdi_init_delay_ctb_vertical_minus2の値は、両端値を含む0〜PicHeightInCtbsY−2の範囲内とする。pdi_init_delay_ctb_horizontal_minus2の値は、両端値を含む0〜PicWidthInCtbsY−2の範囲内とする。
[0232]pdi_init_delay_ctb_horizontal_minus2が0に等しいとき、verCtb未満の垂直アドレスを有するLCU行中の任意のLCU(コーディングツリーブロック)が、ビュー間またはレイヤ間予測に使用され得る。垂直LCU行遅延は、2以上であり得る(たとえば、2以上とする)。水平LCU列遅延は、適用可能な場合、2以上であり得る(たとえば、2以上とする)。
[0233]いくつかの例では、各ビューが同じLCU(コーディングツリーブロック)サイズを有するという制約が必要とされ得る。ビューが異なるLCUサイズを有するとき、最大LCUサイズが上記導出に適用され得る。そのような最大LCUサイズは、ビデオパラメータセット拡張でシグナリングされ得る。
[0234]現在のLCUを復号するとき、水平視差動きベクトルが非常に小さいと仮定すると、ビデオデコーダ30は、コロケートされたLCUを必要とし得る。しかしながら、コロケートされたLCUを利用可能にするために、コロケートされたLCUの下、右および右下のLCUが、少なくともデブロッキングフィルタ処理される必要があり得る。それを可能にするために、上記LCUのうちの下および右のLCUが(たとえば、動き補償および/またはイントラ予測によって)予測される必要があり得る。この場合、少なくとも2つのLCU行遅延および2つのLCU列遅延が必要とされ得る。言い換えれば、サンプル適応オフセット(SAO:Sample Adaptive Offset)フィルタ処理およびデブロッキングフィルタ処理などのループ内フィルタ処理を可能にするために、ビデオデコーダ30は、現在のピクチャの並列復号を開始する前に、ビュー間またはレイヤ間参照ピクチャの追加の行が再構成されるまで待機する必要があり得る。
[0235]いくつかの例では、ビデオエンコーダ20は、pdi_init_delay_ctb_vertical_minus2が2に等しいときのみ、pdi_init_delay_ctb_horizontal_minus2をシグナリングすることができる。別の例として、ビデオエンコーダ20は、次のように垂直LCU行遅延をシグナリングするだけであり得る。
[0236]verCtb=CtbAddrInRS/PicWidthInCtbsY+pdi_init_delay_ctb_vertical_minus3+3。
[0237]利用不可能な参照エリアは、座標(0,(verCtb*PicWidthInCtbsY))を左上隅とし、座標(PicWidthInSamples,PicHeightInSamples)を右下隅とする方形エリアである。コーディングされたビューコンポーネントを復号するとき、参照ビューのビューコンポーネントからの利用不可能な参照エリアからのサンプルは、ビュー間またはレイヤ間予測プロセスによって参照されることはない(たとえば、参照されないものとする)。
[0238]いくつかの例では、ビデオエンコーダ20は、ラスタ走査順序でLCU遅延を指定するpdi_init_delay_ctb_rs_addressをシグナリングすることができる。いくつかの例では、ビデオエンコーダ20は、pdi_init_delay_ctb_rs_address_minusctbwidthをシグナリングし得る。これらの例では、pdi_init_delay_ctb_rs_address_minusctbwidth+PicWidthInCtbsYは、ラスタ走査順序でLCU遅延を示す。
[0239]いくつかの例では、ビデオエンコーダ20は、各ビューの参照ビューまたはレイヤのすべてについてビューごとに別個にpdi_init_delay_ctb_vertical_minus2とpdi_init_delay_ctb_horizontal_minus2とをシグナリングすることができる。いくつかの例では、ビデオエンコーダ20は、ビュー間またはレイヤ間予測を使用する各ビューまたはレイヤの参照ビューまたはレイヤごとに別個にpdi_init_delay_ctb_vertical_minus2とpdi_init_delay_ctb_horizontal_minus2とをシグナリングすることができる。たとえば、次の通りである。
[0240]いくつかの例では、上記のケースすべてについて、pdi_init_delay_ctb_horizontal_minus1はシグナリングされず、0に等しいと推測される。いくつかの例では、video_parameter_set_idは固定長、たとえばu(4)としてシグナリングされ得る。
[0241]ピクセル再構成(たとえば、動き補償およびイントラ予測を含む)のみがLCUごとに行われる必要がある一方、デブロッキングはブロックごとに(すなわち、8×8ブロック)ごとに行われてよく、サンプル適応オフセット(SAO)フィルタ処理はラインごとに行われてよいと仮定されるとき、LCU遅延は大幅に減少し得る。たとえば、ビデオエンコーダ20が垂直LCU行遅延のみをシグナリングするとき、最小行遅延は2である。ビデオエンコーダ20が垂直LCU行遅延と水平LCU列遅延の両方をシグナリングするとき、最小行遅延は1であり、最小LCU列遅延も1である。後者の場合、シンタックスは次のように修正され得る。
[0242]セマンティクスは同様であるが、verCtbおよびhorCtbの計算は次のように若干修正され得る。変数horCtbは次のように導出される。horCtb=pdi_init_delay_ctb_horizontal_minus1?pdi_init_delay_ctb_horizontal_minus1+1+(CtbAddrInRS%PicWidthInCtbsY):0。変数verCtbは次のように導出される。
verCtb=CtbAddrInRS/PicWidthInCtbsY+pdi_init_delay_ctb_vertical_minus1+1。
[0243]以下では、異なるLCUサイズを有する並列復号情報SEIメッセージが以下で説明されることについて説明する。この例は、並列復号情報SEIメッセージについての選択肢のうちの1つと同様であるが、様々なコーディングされたビューコンポーネント中の異なるCTUサイズに対する追加のサポートがある。さらに、例は、SEIメッセージに関して説明されるが、本技法はVUIシンタックス要素に拡張され得る。
[0244]並列復号情報SEIメッセージシンタックスが以下で提供される。
[0245]並列復号情報SEIメッセージは、アクセスユニットに関連付けられ得る。SEIメッセージ中でシグナリングされる情報は、SEIメッセージが関連付けられるアクセスユニットから始まり、もっぱら、同じタイプのSEIメッセージを含む、復号順序で次のアクセスユニットまで、またはコーディングされたビデオシーケンスの終わりまでのうち、復号順序で早い方までの、すべてのアクセスユニットに適用される。並列復号情報SEIメッセージ中で並列復号情報がシグナリングされるいくつかのビューコンポーネントが、コーディングされたビデオシーケンスに存在しない場合があることを理解されたい。
[0246]video_parameter_set_idは、ビュー間またはレイヤ間従属関係情報を含むビデオパラメータセットを指定する。video_parameter_set_idの値は、並列復号情報SEIメッセージを含むアクセスユニットのコーディングされたピクチャのビューコンポーネントによって参照されるvideo_parameter_set_idの値に等しいことがある(たとえば、等しいものとする)。
[0247]変数refLog2CtbSizeY、refPicWidthInCtbsY[i][j]およびrefPicHeightInCtbsY[i][j]は、コーディングされたビューコンポーネントiのj番目の参照ビューのビューコンポーネントについて、それぞれ、Log2CtbSizeY、PicWidthInCtbsYおよびPicHeightInCtbsYに等しくセットされ得る。
[0248]pdi_init_delay_ctu_vertical_minus2[i][j]およびpdi_init_delay_ctu_horizontal_minus2[i][j]は、video_parameter_set_idによって識別されるアクティブビデオパラメータセットで指定されるビュー間またはレイヤ間予測を使用するi番目のコーディングされたビューコンポーネントによってビュー間参照に使用されることのない(たとえば、使用されないものとする)i番目のコーディングされたビューコンポーネントのj番目の参照ビューコンポーネント中の利用不可能な参照エリアを指定する。pdi_unit_delay_ctu_vertical_minus2[i][j]の範囲は、両端値を含む0〜refPicHeightInCtbs−3であり得る(たとえば、両端値を含む0〜refPicHeightInCtbs−3とする)。pdi_unit_delay_ctu_horizontal_minus2[i][j]の範囲は、両端値を含む0〜refPicWidthInCtbs−3であり得る(たとえば、両端値を含む0〜refPicWidthInCtbs−3とする)。
[0249]いくつかの例では、ビデオエンコーダ20は、単一のシンタックス要素pdi_init_delay_ctu_minus2[i][j]をシグナリングすることがあり、pdi_init_delay_ctu_vertical_minus2[i][j]およびpdi_init_delay_ctu_horizontal_minus2[i][j]をシグナリングすることはない。これらの例では、ビデオデコーダ30は次のように、pdi_init_delay_ctu_vertical_minus2[i][j]およびpdi_init_delay_ctu_horizontal_minus2[i][j]の値をpdi_init_delay_ctu_minus2[i][j]から導出することができる。pdi_init_delay_ctu_horizontal_minus2[i][j]=pdi_init_delay_ctu_minus2[i][j]%refPicWidthInCtbsおよびpdi_init_delay_ctu_vertical_minus2[i][j]=pdi_init_delay_ctu_minus2[i][j]/refPicWidthInCtbs。
[0250]変数horCtb[i][j]は次のように導出される。horCtb[i][j]=pdi_init_delay_ctu_horizontal_minus2[i][j]?pdi_init_delay_ctu_horizontal_minus2[i][j]+2:0。変数verCtb[i][j]は次のように導出される。verCtb[i][j]=pdi_init_delay_ctu_vertical_minus2[i][j]?pdi_init_delay_ctu_vertical_minus2[i][j]+2:0。
[0251]変数ctbAddrは次のように導出される。
(Log2CtbSizeY<refLog2CtbSizeY)の場合、
ctbAddr=CtbAddrInRS>>((refLog2CtbSizeY−Log2CtbSizeY)*2))
それ以外の場合、
ctbAddr=CtbAddrInRS<<((Log2CtbSizeY−refLog2CtbSizeY)*2)
[0252]refCtb[i][j]のアドレスを示す変数refCtbAddr[i][j]は次のように導出される。refCtbAddr[i][j]=horCtb[i][j]+verCtb[i][j]*refPicWidthInCtbsY[i][j]+ctbAddr。
[0253]コーディングされたビューコンポーネントiのj番目の参照ビュー中の利用不可能な参照エリアは、アドレスがrefCtbAddr[i][j]以上であるすべてのコーディングツリーユニットを含む。i番目のコーディングされたビューコンポーネントを復号するとき、コーディングされたビューコンポーネントiのj番目の参照ビューのビューコンポーネントからの利用不可能な参照エリアからのサンプルは、ビュー間またはレイヤ間予測プロセスによって参照されることはない(たとえば、参照されないものとする)。
[0254]図5は、本開示で説明する技法を実装し得る例示的なビデオエンコーダ20を示すブロック図である。ビデオエンコーダ20は、ビデオスライス内のビデオブロックのイントラコーディングとインターコーディングとを実行することができる。イントラコーディングは、所与のビデオフレームまたはピクチャ内のビデオの空間的冗長性を低減または除去するために、空間的予測に依拠する。インターコーディングは、ビデオシーケンスの隣接フレームまたはピクチャ内のビデオの時間的冗長性を低減または除去するために、時間的予測に依拠する。イントラモード(Iモード(登録商標))は、いくつかの空間ベースの圧縮モードのいずれかを指し得る。単方向予測(Pモード)または双予測(Bモード)などのインターモードは、いくつかの時間ベースの圧縮モードのいずれかを指し得る。ビデオエンコーダ20はまた、ビュー間予測コーディングとレイヤ間予測コーディングとを実行することができ、この場合にビデオエンコーダ20は、他のビューまたはレイヤについてのブロックをインター予測に使用する。
[0255]図5の例では、ビデオエンコーダ20は、区分ユニット350と、予測処理ユニット410と、参照ピクチャメモリ640と、加算器500と、変換処理ユニット520と、量子化処理ユニット540と、エントロピー符号化ユニット560とを含む。参照ピクチャメモリ640は、復号ピクチャバッファ(DPB)の一例である。予測処理ユニット410は、動き推定ユニット420と、動き補償ユニット440と、イントラ予測ユニット460とを含む。ビデオブロック再構成のために、ビデオエンコーダ20はまた、逆量子化処理ユニット580と、逆変換処理ユニット600と、加算器620とを含む。再構成されたビデオからブロッキネスアーティファクトを除去するためにブロック境界をフィルタ処理するデブロッキングフィルタ(図5に図示せず)も含まれ得る。所望される場合、デブロッキングフィルタは、一般に、加算器620の出力をフィルタ処理することになる。デブロッキングフィルタに加えて、(ループ内またはループ後の)追加ループフィルタも使用され得る。
[0256]図5に示すように、ビデオエンコーダ20はビデオデータを受信し、区分ユニット350はデータをビデオブロックに区分する。この区分は、たとえば、LCUおよびCUの4分木構造に応じて、スライス、タイル、または他のより大きいユニットへの区分、ならびにビデオブロック区分をも含み得る。ビデオエンコーダ20は、概して、符号化されるべきビデオスライス内のビデオブロックを符号化する構成要素を示す。スライスは、複数のビデオブロックに(および、場合によっては、タイルと呼ばれるビデオブロックのセットに)分割され得る。予測処理ユニット410は、誤差結果(たとえばコーディングレートおよびひずみのレベル)に基づいて現在のビデオブロックについて、複数のイントラコーディングモードのうちの1つ、または複数のインターコーディングモードのうちの1つなど、複数の可能なコーディングモードのうちの1つを選択することができる。予測処理ユニット410は、得られたイントラコーディングされたブロックまたはインターコーディングされたブロックを、残差ブロックデータを生成するために加算器500に与え、参照ピクチャとして使用するための符号化されたブロックを再構成するために加算器620に与え得る。
[0257]予測処理ユニット410内のイントラ予測ユニット460は、空間圧縮を行うために、コーディングされるべき現在のブロックと同じフレームまたはスライス中の1つまたは複数の隣接ブロックに対する現在のビデオブロックのイントラ予測コーディングを実行し得る。予測処理ユニット410内の動き推定ユニット420および動き補償ユニット440は、時間圧縮を行うために、1つまたは複数の参照ピクチャ中の1つまたは複数の予測ブロックに対する現在のビデオブロックのインター予測コーディングを実行する。
[0258]動き推定ユニット420は、ビデオシーケンスの所定のパターンに従ってビデオスライスのためのインター予測モードを決定するように構成され得る。動き推定ユニット420と動き補償ユニット440とは、高度に統合され得るが、概念的な目的のために別々に示してある。動き推定ユニット420によって実行される動き推定は、ビデオブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、参照ピクチャ内の予測ブロックに対する現在のビデオフレームまたはピクチャ内のビデオブロックのPUの変位を示し得る。動き推定ユニット420はまた、動きベクトル差分(MVD)を決定するために動きベクトル予測子を決定し得る。
[0259]予測ブロックは、絶対値差分和(SAD)、差分2乗和(SSD)、または他の差分尺度によって決定され得るピクセル差分に関して、コーディングされるべきビデオブロックのPUに厳密に一致することがわかるブロックである。いくつかの例では、ビデオエンコーダ20は、参照ピクチャメモリ640に記憶された参照ピクチャのサブ整数ピクセル位置の値を計算し得る。たとえば、ビデオエンコーダ20は、参照ピクチャの1/4ピクセル位置、1/8ピクセル位置、または他の分数ピクセル位置の値を補間し得る。したがって、動き推定ユニット420は、フルピクセル位置と分数ピクセル位置とに対する動き探索を実行し、分数ピクセル精度で動きベクトルを出力し得る。
[0260]動き推定ユニット420は、PUの位置を参照ピクチャの予測ブロックの位置と比較することによって、インターコーディングされたスライスにおけるビデオブロックのPUについての動きベクトルを計算する。参照ピクチャは、第1の参照ピクチャリスト(リスト0またはRefPicList0)または第2の参照ピクチャリスト(リスト1またはRefPicList1)から選択されてよく、それらの参照ピクチャリストの各々は、参照ピクチャメモリ640に記憶された1つまたは複数の参照ピクチャを識別する。動き推定ユニット420は、エントロピー符号化ユニット56と動き補償ユニット440とに計算された動きベクトルを送る。動き推定ユニット420は、計算された動きベクトル予測子とMVDとをエントロピー符号化ユニット560に送り得る。
[0261]動き補償ユニット440によって実行される動き補償は、動き推定によって決定された動きベクトルに基づいて予測ブロックをフェッチまたは生成すること、場合によってはサブピクセル精度への補間を実行することを伴い得る。現在のビデオブロックのPUについての動きベクトルを受信すると、動き補償ユニット440は、動きベクトルが参照ピクチャリストのうちの1つにおいて指す予測ブロックの位置を特定し得る。ビデオエンコーダ20は、コーディングされている現在のビデオブロックのピクセル値から予測ブロックのピクセル値を減算し、ピクセル差分値を形成することによって残差ビデオブロックを形成する。ピクセル差分値は、ブロックの残差データを形成し、ルーマ差分成分とクロマ差分成分の両方を含み得る。加算器500は、この減算演算を実行する1つまたは複数の構成要素を表す。動き補償ユニット440はまた、ビデオスライスのビデオブロックを復号する際にビデオデコーダ30が使用するための、ビデオブロックとビデオスライスとに関連するシンタックス要素(たとえば、情報)を生成することができる。
[0262]イントラ予測ユニット460は、前述のように、動き推定ユニット420と動き補償ユニット440とによって実行されるインター予測の代替として、現在のブロックをイントラ予測し得る。特に、イントラ予測ユニット460は、現在のブロックを符号化するために使用すべきイントラ予測モードを決定し得る。いくつかの例では、イントラ予測ユニット460は、たとえば、別個の符号化パス中に、様々なイントラ予測モードを使用して現在のブロックを符号化することができ、イントラ予測ユニット460は、テストされたモードから使用するのに適切なイントラ予測モードを選択することができる。たとえば、イントラ予測ユニット460は、様々なテストされたイントラ予測モードのためのレートひずみ分析を使用してレートひずみ値を計算し、テストされたモードの中で最良のレートひずみ特性を有するイントラ予測モードを選択し得る。レートひずみ分析は、概して、符号化されたブロックと、符号化されたブロックを生成するために符号化された元の符号化されていないブロックとの間のひずみ(または誤差)の量、ならびに符号化されたブロックを生成するために使用されるビットレート(すなわち、ビット数)を決定する。イントラ予測ユニット460は、どのイントラ予測モードがブロックについて最良のレートひずみ値を呈するかを決定するために、様々な符号化されたブロックのひずみおよびレートから比率を計算し得る。
[0263]いずれの場合も、ブロックのイントラ予測モードを選択した後に、イントラ予測ユニット460は、ブロックについての選択されたイントラ予測モードを示す情報をエントロピー符号化ユニット560に提供し得る。エントロピー符号化ユニット560は、本開示の技法に従って、選択されたイントラ予測モードを示す情報を符号化し得る。ビデオエンコーダ20は、送信ビットストリーム中に、複数のイントラ予測モードインデックステーブルおよび複数の変更されたイントラ予測モードインデックステーブル(コードワードマッピングテーブルとも呼ばれる)と、様々なブロックの符号化コンテキストの定義と、コンテキストの各々について使用すべき、最確イントラ予測モード、イントラ予測モードインデックステーブル、および変更されたイントラ予測モードインデックステーブルの指示とを含み得る構成データを含め得る。
[0264]予測処理ユニット410が、インター予測またはイントラ予測のいずれかを介して、現在のビデオブロックのための予測ブロックを生成した後、ビデオエンコーダ20は、現在のビデオブロックから予測ブロックを減算することによって残差ビデオブロックを形成する。残差ブロック中の残差ビデオデータは、1つまたは複数のTU中に含まれ、変換処理ユニット520に適用され得る。変換処理ユニット520は、離散コサイン変換(DCT)または概念的に同様の変換などの変換を使用して、残差ビデオデータを残差変換係数に変換する。変換処理ユニット520は、残差ビデオデータをピクセル領域から周波数領域などの変換領域に変換し得る。
[0265]変換処理ユニット520は、得られた変換係数を量子化処理ユニット540に送り得る。量子化処理ユニット540は、ビットレートをさらに低減するために変換係数を量子化する。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって変更され得る。いくつかの例では、量子化処理ユニット540は、次いで、量子化変換係数を含む行列の走査を実行し得る。代替的に、エントロピー符号化ユニット560が走査を実行し得る。
[0266]量子化の後に、エントロピー符号化ユニット560は、量子化変換係数をエントロピー符号化する。たとえば、エントロピー符号化ユニット560は、コンテキスト適応型可変長コーディング(CAVLC)、コンテキスト適応型バイナリ算術コーディング(CABAC)、シンタックスベースコンテキスト適応型バイナリ算術コーディング(SBAC)、確率間隔区分エントロピー(PIPE)コーディングまたは別のエントロピー符号化方法もしくは技法を実行し得る。エントロピー符号化ユニット560によるエントロピー符号化の後に、符号化されたビットストリームは、ビデオデコーダ30に送信されるか、またはビデオデコーダ30が後で送信するかもしくは取り出すためにアーカイブされ得る。エントロピー符号化ユニット560はまた、コーディングされている現在のビデオスライスについての動きベクトルと他のシンタックス要素とをエントロピー符号化することができる。
[0267]逆量子化処理ユニット580および逆変換処理ユニット600は、参照ピクチャの参照ブロックとして後で使用する目的でピクセル領域において残差ブロックを再構成するために、それぞれ逆量子化および逆変換を適用する。動き補償ユニット440は、参照ピクチャリストのうちの1つ内の参照ピクチャのうちの1つの予測ブロックに残差ブロックを加算することによって参照ブロックを計算し得る。動き補償ユニット440はまた、動き推定において使用するためのサブ整数ピクセル値を計算するために、再構成された残差ブロックに1つまたは複数の補間フィルタを適用し得る。加算器620は、参照ピクチャメモリ640に記憶するための参照ブロックを生成するために、再構成された残差ブロックを動き補償ユニット440によって生成された動き補償予測ブロックに加算する。参照ブロックは、後続のビデオフレームまたはピクチャ中のブロックをインター予測するために、動き推定ユニット420と動き補償ユニット440とによって参照ブロックとして使用され得る。
[0268]いくつかの例では、予測処理ユニット410は、本開示で説明する技法を実装するように構成され得る。ただし、本開示で説明する技法は、そのように限定されない。いくつかの例では、ビデオエンコーダ20内の1つまたは複数の他のユニットとともに、予測処理ユニット410は、本開示で説明する技法を実装するように構成され得る。いくつかの例では、処理ユニット(図5に図示せず)は、本開示で説明する技法を実装するように構成され得る。言い換えれば、ビデオエンコーダ20は、1つまたは複数のプロセッサを含むことができ、本開示で説明する例示的な技法を実装するように構成され得る。
[0269]たとえば、ビデオエンコーダ20は(たとえば、予測処理ユニット410を介して)、ビデオデコーダ30が受信するビットストリーム中でシグナリングされる情報が、動きベクトル制限に準拠する動きベクトルをビデオデコーダ30に導出させることを確実にし得る。一例として、マージ/スキップモードの場合、ビデオエンコーダ20は、値が動きベクトル制限に準拠する、動きベクトルを導出するために使用される、動きベクトル予測子を識別する候補動きベクトル予測子のリストへのインデックスなどの情報を決定することができる。別の例として、AMVPモードの場合、ビデオエンコーダ20は、動きベクトルを導出するために使用される動きベクトル予測子を識別する候補動きベクトル予測子のリストへのインデックスを決定することができる。ビデオエンコーダ20は、動きベクトル差分が動きベクトル予測子に加算されたときに、得られる動きベクトルが動きベクトル制限に準拠するように、動きベクトル差分を決定することもできる。マージ/スキップモードおよびAMVPモードの例では、ビデオエンコーダ20は、候補動きベクトル予測子のリストへのインデックスを出力用に生成することができる。AMVPモードの場合、ビデオエンコーダ20は、動きベクトル差分を出力用に生成することもできる。
[0270]いくつかの例では、ビデオエンコーダ20は、参照ピクチャ中のピクチャについての動きベクトル差分が0ではないことをフラグの値(たとえば、mvd_l1_zero_flag)が常に示すことを決定することがある。ビデオエンコーダ20は、ビットストリーム中にフラグの値を出力用に生成することもできる。
[0271]並列復号の場合、ビデオエンコーダ20は、ブロックサイズのユニットにおける動きベクトル制限の垂直動きベクトル範囲を出力することができる。たとえば、動きベクトル制限は、垂直動きベクトル範囲および水平動きベクトル範囲のうちの少なくとも1つを含むことができる。これらの例では、ブロックサイズのユニットは、垂直ベクトル範囲の最大コーディングユニットの高さおよび最小コーディングユニットの高さのユニットならびに水平ベクトル範囲の最大コーディングユニットの幅および最小コーディングユニットの幅のユニットの1つであり得る。
[0272]いくつかの例では、ビデオエンコーダ20は、現在のブロックによってビュー間またはレイヤ間参照に使用され得ない、第1のビュー間またはレイヤ間参照ピクチャを含む任意のビュー間または任意のレイヤ間参照ピクチャ中の利用不可能な参照エリアを決定することができる。これらの例では、ビデオエンコーダ20は、現在のブロックについての動きベクトルを、動きベクトルが任意のビュー間またはレイヤ間参照ピクチャ中の利用不可能な参照エリアを指さないように、決定された利用不可能なエリアに基づいて導出することができる。ビデオエンコーダ20はまた、利用不可能な参照エリアを示す情報を出力用に生成するように構成され得る。一例として、ビデオエンコーダ20は、ラスタ走査順序で利用不可能な参照エリアを示す情報を出力用に生成することができる。
[0273]図6は、本開示で説明する技法を実装し得る例示的なビデオデコーダ30を示すブロック図である。図6の例では、ビデオデコーダ30は、エントロピー復号ユニット800と、予測処理ユニット810と、逆量子化処理ユニット860と、逆変換ユニット880と、加算器900と、参照ピクチャメモリ920とを含む。参照ピクチャメモリ920は、復号ピクチャバッファ(DPB)の一例である。予測処理ユニット810は、動き補償ユニット820と、イントラ予測ユニット840とを含む。ビデオデコーダ30は、いくつかの例では、図5のビデオエンコーダ20に関して説明した符号化パスとは概して逆の復号パスを実行し得る。
[0274]いくつかの例では、予測処理ユニット810は、本開示で説明する技法を実装するように構成され得る。ただし、本開示で説明する技法は、そのように限定されない。いくつかの例では、予測処理ユニット810は、ビデオデコーダ30内の1つまたは複数の他のユニットとともに、本開示で説明する技法を実装するように構成され得る。いくつかの例では、処理ユニット(図6に図示せず)は、本開示で説明する技法を実装するように構成され得る。
[0275]復号プロセス中に、ビデオデコーダ30は、ビデオエンコーダ20から、符号化されたビデオスライスのビデオブロックと、関連するシンタックス要素とを表す符号化されたビデオビットストリームを受信する。ビデオデコーダ30のエントロピー復号ユニット800は、量子化係数と、動きベクトルと、他のシンタックス要素とを生成するためにビットストリームをエントロピー復号する。エントロピー復号ユニット800は、動きベクトルと他のシンタックス要素とを予測処理ユニット810に転送する。ビデオデコーダ30は、ビデオスライスレベルおよび/またはビデオブロックレベルでシンタックス要素を受信し得る。
[0276]ビデオスライスがイントラコーディングされた(I)スライスとしてコーディングされるとき、予測処理ユニット810のイントラ予測ユニット840は、シグナリングされたイントラ予測モードと、現在のフレームまたはピクチャの、前に復号されたブロックからのデータとに基づいて、現在のビデオスライスのビデオブロックのための予測データを生成し得る。ビデオフレームがインターコーディングされた(すなわち、B、PまたはGPB)スライスとしてコーディングされるとき、予測処理ユニット810の動き補償ユニット820は、エントロピー復号ユニット800から受信された動きベクトルおよび他のシンタックス要素に基づいて、現在のビデオスライスのビデオブロックのための予測ブロックを生成する。予測ブロックは、参照ピクチャリストのうちの1つ内の参照ピクチャのうちの1つから生成され得る。ビデオデコーダ30は、参照ピクチャメモリ920に記憶された参照ピクチャに基づいて、デフォルトの構成技法または任意の他の技法を使用して、参照フレームリスト、すなわち、リスト0とリスト1とを構成し得る。
[0277]動き補償ユニット820は、動きベクトルと他のシンタックス要素とを解析することによって現在のビデオスライスのビデオブロックについての予測情報を決定し、復号されている現在のビデオブロックのための予測ブロックを生成するために、予測情報を使用する。たとえば、動き補償ユニット820は、ビデオスライスのビデオブロックをコーディングするために使用される予測モード(たとえば、イントラまたはインター予測)と、インター予測スライスタイプ(たとえば、Bスライス、Pスライス、またはGPBスライス)と、スライスの参照ピクチャリストのうちの1つまたは複数のための構成情報と、スライスの各インター符号化されたビデオブロックについての動きベクトルと、スライスの各インターコーディングされたビデオブロックについてのインター予測ステータスと、現在のビデオスライス中のビデオブロックを復号するための他の情報とを決定するために、受信されたシンタックス要素のいくつかを使用する。
[0278]動き補償ユニット820はまた、補間フィルタに基づいて補間を実行し得る。動き補償ユニット820は、参照ブロックのサブ整数ピクセルのための補間された値を計算するために、ビデオブロックの符号化中にビデオエンコーダ20によって使用された補間フィルタを使用し得る。この場合、動き補償ユニット820は、受信されたシンタックス要素からビデオエンコーダ20によって使用された補間フィルタを決定し、予測ブロックを生成するために、その補間フィルタを使用し得る。
[0279]逆量子化処理ユニット860は、ビットストリーム中で与えられ、エントロピー復号ユニット800によって復号された、量子化変換係数を逆量子化(inverse quantize)、すなわち、逆量子化(de-quantize)する。逆量子化プロセスは、量子化の程度を決定するために、同様に、適用されるべき逆量子化の程度を決定するために、ビデオスライス中の各ビデオブロックについてビデオエンコーダ20によって計算される量子化パラメータを使用することを含み得る。逆変換処理ユニット880は、ピクセル領域において残差ブロックを生成するために、逆変換、たとえば、逆DCT、逆整数変換、または概念的に同様の逆変換プロセスを変換係数に適用する。
[0280]動き補償ユニット820が、動きベクトルと他のシンタックス要素とに基づいて現在のビデオブロックのための予測ブロックを生成した後に、ビデオデコーダ30は、逆変換処理ユニット880からの残差ブロックを動き補償ユニット820によって生成された対応する予測ブロックと加算することによって、復号されたビデオブロックを形成する。加算器900は、この加算演算を実行する1つまたは複数の構成要素を表す。所望される場合、ブロッキネスアーティファクトを除去するために復号されたブロックをフィルタ処理するデブロッキングフィルタも適用され得る。ピクセル遷移を平滑化するために、または場合によってはビデオ品質を改善するために、(コーディングループ内またはコーディングループ後のいずれかの)他のループフィルタも使用され得る。所与のフレームまたはピクチャ中の復号されたビデオブロックは、次いで、その後の動き補償のために使用される参照ピクチャを記憶する参照ピクチャメモリ920に記憶される。参照ピクチャメモリ920はまた、図4のディスプレイデバイス32などのディスプレイデバイス上での後の提示のために、復号されたビデオを記憶する。
[0281]このようにして、ビデオデコーダ30は、本開示で説明する例示的な技法を実装するように構成されたビデオデコーダの一例である。たとえば、ビデオデコーダ30は、1つまたは複数のプロセッサを含むことができ、本開示で説明する例示的な技法を実装するように構成され得る。
[0282]たとえば、ビデオデコーダ30は、動きベクトル制限に準拠することを確実にされる動きベクトル予測子から動きベクトルを導出することができる。たとえば、マージ/スキップモードでは、ビデオデコーダ30は、動きベクトル予測子に等しく動きベクトルをセットするので、動きベクトル予測子は、動きベクトル制限に準拠することが必要とされる。AMVPモードでは、ビデオデコーダ30は、値が、動きベクトル差分が動きベクトル予測子に加算されたときに、得られる動きベクトルが動きベクトル制限に準拠するようなものである動きベクトル差分を、ビットストリームから決定する。この例では、ビデオデコーダ30は、動きベクトル予測子と動きベクトル差分とを加算することによって、動きベクトルを導出することができる。
[0283]いくつかの例では、ビデオデコーダ30は、ブロックサイズの動きベクトル制限の垂直動きベクトル範囲を、受信されたビットストリームから決定することができる。ビデオデコーダ30は、垂直動きベクトル範囲に基づいて、ビュー間またはレイヤ間参照ピクチャと現在のブロックを含む現在のピクチャとを並列復号することができる。
[0284]また、いくつかの例では、ビデオデコーダ30は、現在のブロックによってビュー間またはレイヤ間参照に使用され得ない任意のビュー間または任意のレイヤ間参照ピクチャ中の利用不可能な参照エリアを、受信されたビットストリームから決定することができる。これらの例では、ビデオデコーダ30は、現在のブロックについての動きベクトルを、動きベクトルが任意のビュー間または任意のレイヤ間参照ピクチャ中の利用不可能な参照エリアを指さないように、ビットストリーム中の情報に基づいて導出することができる。一例として、ビデオデコーダ30は、ラスタ走査順序で利用不可能な参照エリアを決定することができる。
[0285]図7は、本開示で説明する技法によるビュー間またはレイヤ間ビデオ復号の例示的な動作を示すフローチャートである。例示のために、本技法は、ビデオデコーダ30に関して説明される。たとえば、ビデオデコーダ30は、現在のブロックについての動きベクトルを動きベクトル予測子から導出するための情報を含むビットストリームを受信する(1000)ことができる。動きベクトルは、ビュー間またはレイヤ間参照ピクチャを指し得る。ビットストリームから受信された情報が、導出された動きベクトルが動きベクトル制限に準拠することを確実にし得るように、ビットストリームは制約され得る。また、動きベクトル制限は、ビュー間またはレイヤ間参照ピクチャのサブ部分を指すように動きベクトルの範囲を制限する。
[0286]ビデオデコーダ30は、ビットストリーム中の情報に基づいて、現在のブロックについての動きベクトルを導出する(1002)ことができる。ビデオデコーダ30は、導出された動きベクトルに基づいて、現在のブロックをビュー間またはレイヤ間予測復号する(1004)ことができる。
[0287]図8は、本開示で説明する技法によるビュー間またはレイヤ間ビデオ符号化の例示的な動作を示すフローチャートである。例示のために、本技法は、ビデオデコーダ30に関して説明される。たとえば、ビデオエンコーダ20は、現在のブロックについての動きベクトルを動きベクトル予測子から導出するために使用される、導出された動きベクトルが動きベクトル制限に準拠することを確実にする情報を決定する(1006)ことができる。上記と同様に、動きベクトルは、ビュー間またはレイヤ間参照ピクチャを指し、動きベクトル制限は、ビュー間またはレイヤ間参照ピクチャのサブ部分を指すように動きベクトルの範囲を制限する。
[0288]ビデオエンコーダ20は、情報に基づいて、現在のブロックについての動きベクトルを導出する(1008)ことができる。ビデオエンコーダ20は、導出された動きベクトルに基づいて、現在のブロックをビュー間またはレイヤ間予測符号化する(1010)ことができる。ビデオエンコーダ20は、動きベクトルを導出するための決定された情報を出力用に生成する(1012)ことができる。
[0289]1つまたは複数の例では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、またはコンピュータ可読媒体を介して送信され、ハードウェアベースの処理ユニットによって実行されてよい。コンピュータ可読媒体は、たとえば、データ記憶媒体などの有形媒体、または、たとえば通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体に対応する、コンピュータ可読記憶媒体を含むことができる。このようにして、コンピュータ可読媒体は、一般に、(1)非一時的である有形コンピュータ可読記憶媒体、または、(2)信号もしくは搬送波などの通信媒体に対応することができる。データ記憶媒体は、本開示で説明した技法を実装するための命令、コードおよび/またはデータ構造を取り出すために、1つもしくは複数のコンピュータ、または1つもしくは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含むことができる。
[0290]限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM(登録商標)、CD−ROMまたは他の光ディスクストレージ、磁気ディスクストレージ、または他の磁気ストレージデバイス、フラッシュメモリ、あるいは、命令またはデータ構造の形態の所望のプログラムコードを記憶するために使用されコンピュータによってアクセスされ得る、任意の他の媒体を備え得る。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含まないが、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピー(登録商標)ディスク(disk)およびBlu−rayディスク(disc)を含み、ここでディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザーで光学的に再生する。上記の組合せも、コンピュータ可読媒体の範囲内に含まれるべきである。
[0291]命令は、1つもしくは複数のデジタル信号プロセッサ(DSP)などの1つもしくは複数のプロセッサ、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、または他の等価な集積回路もしくはディスクリート論理回路によって実行され得る。したがって、本明細書で使用される「プロセッサ」という用語は、前述の構造、または本明細書で説明した技法の実装に適した任意の他の構造のいずれかを指し得る。さらに、いくつかの態様では、本明細書で説明した機能は、符号化および復号のために構成された専用のハードウェアおよび/またはソフトウェアモジュール内に設けられる場合があるか、または複合コーデックに組み込まれる場合がある。また、本技法は、1つまたは複数の回路または論理要素において完全に実装され得る。
[0292]本開示の技法は、ワイヤレスハンドセット、集積回路(IC)、もしくはICのセット(たとえば、チップセット)を含む、多種多様なデバイスまたは装置において実装され得る。本開示では、開示される技法を実行するように構成されたデバイスの機能的態様を強調するために様々な構成要素、モジュール、またはユニットが説明されたが、それらの構成要素、モジュール、またはユニットは、必ずしも異なるハードウェアユニットによって実現する必要があるとは限らない。むしろ、前述のように、適切なソフトウェアおよび/またはファームウェアとともに、様々なユニットがコーデックハードウェアユニットにおいて組み合わせられ得るか、または前述のような1つもしくは複数のプロセッサを含む、相互動作可能なハードウェアユニットの集合体よって設けられ得る。
[0293]様々な例について説明してきた。これら例および他の例は、以下の特許請求の範囲内にある。