特定のビデオコード化システムによれば、データ圧縮を実現するように、ビデオシーケンスにおける時間的冗長性を低減するために、動き推定及び動き補償を使用することができる。この場合、ビデオデータの予測ブロック、例えば、コード化されている現在ビデオブロックの値を予測するために使用できる別のビデオのピクチャ又はスライスからのブロックを識別する動きベクトルを生成することができる。予測ビデオブロックの値が現在ビデオブロックの値から減算されて、残差データのブロックを生成する。動き情報(例えば、動きベクトル、動きベクトルインデックス、予測方向、又は他の情報)が、残差データとともにビデオエンコーダからビデオデコーダに通信される。デコーダは、(動きベクトルに基づいて)同じ予測ブロックの位置を特定し、残差データを予測ブロックのデータと合成することにより、符号化されたビデオブロックを復元することができる。
マルチビュービデオコード化(MVC)は、ビデオデータの複数のビューをカプセル化するためのビデオコード化規格である。一般に、各ビューは、共通のシーンの対応するビデオデータが撮影された異なる視点又は角度に対応する。コード化されたビューは、ビデオデータの3次元(3D)表示器に使用することができる。例えば、2つのビュー(例えば、観察者の左眼のビュー及び右眼のビュー)は、光の異なる偏光を使用して同時に、又はほぼ同時に表示することができ、観察者の眼の各々がビューのそれぞれ1つを受け取るように、観察者はパッシブ偏光眼鏡を着用することができる。代替的に、観察者は、各眼を単独に遮断するアクティブ眼鏡を着用することができ、表示器は、眼鏡と同期して各眼の画像間を高速に交互することができる。
MVCでは、特定のビューの特定のピクチャはビューコンポーネントと呼ばれる。即ち、ビューのビューコンポーネントは、ビューの特定の時間インスタンスに対応する。マルチビューデータを取得するために使用される全てのカメラが、様々な視点から同じシーンを撮影するので、マルチビュービデオは、比較的大量のビュー間の統計的な依存性を含んでいる場合がある。そのような依存性は、合成された時間的予測及び/又はビュー間予測のために活用することができ、画像は時間的に近接する画像からだけでなく、他のビューからの対応する画像からも予測される。即ち、ビュー間予測は、同じアクセスユニット(アクセス単位)内(即ち、同じ時間インスタンスの内部)の画像間で実行することができる。
ビュー間予測は、一般に、別のビュー内のビューコンポーネントがインター予測参照であるように実現される。予測用の「動き」ベクトルを使用するのではなく、ビュー間予測は、動きベクトルと概念的に同様であるが、動きではなく置換を記述する「置換」ベクトルを利用する。潜在的なビュー間参照は、シーケンスパラメータセット(SPS)のMVC拡張内で通知され、インター予測参照又はビュー間予測参照のフレキシブルな順序付けを可能にする、参照ピクチャリスト構築プロセスによって修正することができる。
MVCビデオデータを含むビデオデータは、ビデオテレフォニ、記憶装置、ブロードキャスト、又はストリーミングなどのアプリケーションに対処する「ネットワークフレンドリ」なビデオ表現を提供するネットワークアブストラクションレイヤ(NAL)ユニットに編成することができる。例えば、ビデオエンコーダは、通常、ビデオデータの各ピクチャを1つ又は複数の単独で復号可能なスライスとして符号化する。スライスは、ネットワーク上の伝送用のNALユニットにパッケージ化することができる。ビデオコード化レイヤ(VCL)データを含むNALユニット(NAL単位)は、ピクチャ用のデータ又はピクチャのスライス用のデータを含むことができる。例えば、NALユニットは、コード化ブロックパターン(CBP)値、ブロックタイプ、コード化モード、(フレーム、スライス、ブロック、又はシーケンスなどの)コード化単位用の最大ブロックサイズ、又は他の情報などのシンタックス情報を含むことができる。
各NALユニットは、NALユニットに記憶されたデータのタイプを識別するヘッダを含む。例示的なMVCのNALユニットヘッダは、NALユニットが属するビューのビュー識別子と、NALユニットが(他のビューコンポーネントによる参照用の)ランダムアクセスポイントとして使用できる、所謂アンカーピクチャに属するかどうかと、NALユニットが他のビュー内のNALユニット用のビュー間予測に使用されるかどうかと、様々な他の情報とを示すシンタックス要素を含むことができる。本明細書に記載されたように、アンカーピクチャは、一般にランダムアクセスピクチャに該当する場合があり、それらの用語は互換的に使用することができる。即ち、「ランダムアクセス」は、一般に、ストリームの開始以外のポイントでビットストリームに対する復号プロセスを開始する行為を指す。ランダムアクセスピクチャは、一般に、イントラコード化スライス(Iスライス)のみを含んでいるピクチャに関係する。復号順序と出力順序の両方でランダムアクセスピクチャに続くコード化ピクチャは、復号順序又は出力順序のいずれかでランダムアクセスピクチャに先行するピクチャから予測されない。
一般に、アクセスユニットは、特定の時間インスタンスの全てのビューコンポーネントを含むことができる。特定のビューコンポーネントは、特定の時間インスタンスで特定のビューの全てのNALユニットを含む。MVCのNALユニットは、(NALユニットタイプを含む)1バイトのNALユニットヘッダを含んでいる場合があり、MVCのNALユニットヘッダ拡張部を更に含むことができる。
H.264/AVCはMVCサポートを含むが、H.264/AVCに対する現在のMVC拡張は、他のビデオコード化規格に対して幾つかの非効率性を含んでいる場合がある。更に、以下でより詳細に説明されるように、H.264/AVCから今度のHEVC規格などの他のコード化規格へのMVCの直接インポートは、実現可能ではない可能性がある。本開示の技法は、一般に、MVCと関係するNALユニット、MVCと関係するパラメータセットなどの形成に関する。本開示の特定の技法により、今度のHEVC規格用の効率的なMVCコード化が可能になる可能性がある。
図1は、マルチビューコード化において動きベクトル予測用の技法を利用できる、例示的なビデオの符号化及び復号のシステム10を示すブロック図である。図1に示されたように、システム10は、宛先機器14によって後で復号されるべき符号化ビデオデータを提供する発信源機器12を含む。詳細には、発信源機器12は、コンピュータ可読媒体16を介して宛先機器14にビデオデータを提供する。発信源機器12及び宛先機器14は、デスクトップコンピュータ、ノートブック(即ち、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、所謂「スマート」フォンなどの電話ハンドセット、所謂「スマート」パッド、テレビジョン、カメラ、表示装置、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミング機器などを含む、広範囲にわたる機器のいずれかを備えることができる。場合によっては、発信源機器12及び宛先機器14は、ワイヤレス通信用に装備することができる。
宛先機器14は、コンピュータ可読媒体16を介して、復号されるべき符号化ビデオデータを受信することができる。コンピュータ可読媒体16は、符号化ビデオデータを発信源機器12から宛先機器14に移動することが可能な任意のタイプの媒体又は機器を備えることができる。一例では、コンピュータ可読媒体16は、発信源機器12がリアルタイムで符号化ビデオデータを宛先機器14に直接送信することを可能にする通信媒体を備えることができる。
符号化ビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され、宛先機器14に送信することができる。通信媒体は、無線周波数(RF)スペクトル又は1つもしくは複数の物理伝送線路などの、任意のワイヤレス又は有線の通信媒体を備えることができる。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、又はインターネットなどのグローバルネットワークなどの、パケットベースネットワークの一部を形成することができる。通信媒体は、ルータ、スイッチ、基地局、又は、発信源機器12から宛先機器14への通信を容易にするために有用であり得る任意の他の機器を含むことができる。
幾つかの例では、符号化データは、出力インターフェース22から記憶装置に出力することができる。同様に、符号化データは、入力インターフェースにより記憶装置からアクセスすることができる。記憶装置には、ハードドライブ、ブルーレイ(登録商標)ディスク、DVD、CD−ROM、フラッシュメモリ、揮発性もしくは不揮発性のメモリ、又は符号化ビデオデータを記憶するための任意の他の適切なデジタル記憶媒体などの様々な分散された、又はローカルにアクセスされるデータ記憶媒体のいずれかが含まれ得る。更なる一例では、記憶装置は、発信源機器12によって生成された符号化ビデオを記憶できるファイルサーバ又は別の中間記憶装置に該当することができる。
宛先機器14は、ストリーミング又はダウンロードを介して、記憶装置からの記憶されたビデオデータにアクセスすることができる。ファイルサーバは、符号化ビデオデータを記憶し、その符号化ビデオデータを宛先機器14に送信することが可能な任意のタイプのサーバであり得る。例示的なファイルサーバには、(例えば、ウェブサイト用の)ウェブサーバ、FTPサーバ、ネットワーク接続記憶装置(NAS)機器、又はローカルディスクドライブが含まれる。宛先機器14は、インターネット接続を含む任意の標準データ接続を介して、符号化ビデオデータにアクセスすることができる。これには、ファイルサーバに記憶された符号化ビデオデータにアクセスするのに適した、ワイヤレスチャネル(例えば、Wi−Fi接続)、有線接続(例えば、DSL、ケーブルモデムなど)、又は両方の組合せが含まれ得る。記憶装置からの符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、又はそれらの組合せであり得る。
本開示の技法は、必ずしもワイヤレスの適用例又は設定に限定されるとは限らない。本技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、動的適応ストリーミングオーバーHTTP(DASH)などのインターネットストリーミングビデオ送信、データ記憶媒体に符号化されたデジタルビデオ、データ記憶媒体に記憶されたデジタルビデオの復号、又は他の適用例などの様々なマルチメディア適用例のいずれかをサポートするビデオコード化に適用することができる。幾つかの例では、システム10は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、及び/又はビデオテレフォニなどの適用例をサポートするために、一方向又は双方向のビデオ送信をサポートするように構成することができる。
図1の例では、発信源機器12は、ビデオ発信源18と、ビデオエンコーダ20と、出力インターフェース22とを含む。宛先機器14は、入力インターフェース28と、ビデオデコーダ30と、表示装置32とを含む。本開示によれば、発信源機器12のビデオエンコーダ20は、マルチビューコード化において動きベクトル予測用の技法を適用するように構成することができる。他の例では、発信源機器及び宛先機器は、他の構成要素又は装置を含むことができる。例えば、発信源機器12は、外部カメラなどの外部のビデオ発信源18からビデオデータを受信することができる。同様に、宛先機器14は、内蔵表示装置を含むのではなく、外部表示装置とインターフェースすることができる。
図1の図示されたシステム10は一例にすぎない。マルチビューコード化における動きベクトル予測のための技法は、任意のデジタルビデオの符号化及び/又は復号の機器によって実行することができる。一般に、本開示の技法はビデオ符号化機器によって実行されるが、本技法は、通常「コーデック」と呼ばれるビデオエンコーダ/デコーダによって実行することもできる。更に、本開示の技法は、ビデオプリプロセッサによって実行することもできる。発信源機器12及び宛先機器14は、発信源機器12が宛先機器14に送信するためのコード化ビデオデータを生成するようなコード化機器の例にすぎない。幾つかの例では、機器12、14の各々がビデオ符号化構成要素とビデオ復号構成要素とを含むように、機器12、14は、実質的に対称的な方式で動作することができる。従って、システム10は、例えば、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、又はビデオテレフォニのための、ビデオ機器12とビデオ機器14との間の一方向又は双方向のビデオ送信をサポートすることができる。
発信源機器12のビデオ発信源18には、ビデオカメラなどの撮像装置、以前に撮影されたビデオを含んでいるビデオアーカイブ、及び/又はビデオコンテンツプロバイダからビデオを受信するビデオフィードインターフェースが含まれ得る。更なる代替として、ビデオ発信源18は、発信源ビデオとしてのコンピュータグラフィックスベースのデータ、又はライブビデオ、アーカイブビデオ、及びコンピュータ生成ビデオの合成を生成することができる。場合によっては、ビデオ発信源18がビデオカメラである場合、発信源機器12及び宛先機器14は、所謂カメラ付き携帯電話又はビデオ電話を形成することができる。しかしながら、上述のように、本開示に記載された技法は、一般にビデオコード化に適用可能であり得るし、ワイヤレス及び/又は有線の適用例に適用することができる。各場合において、撮影されたビデオ、以前に撮影されたビデオ、又はコンピュータ生成ビデオは、ビデオエンコーダ20によって符号化することができる。次いで、符号化ビデオ情報は、出力インターフェース22によってコンピュータ可読媒体16に出力することができる。
コンピュータ可読媒体16には、ワイヤレス放送又は有線ネットワーク送信などの一時的媒体、若しくはハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、ブルーレイディスク、又は他のコンピュータ可読媒体などの記憶媒体(即ち、非一時的記憶媒体)が含まれ得る。幾つかの例では、ネットワークサーバ(図示せず)は、発信源機器12から符号化ビデオデータを受信し、例えば、ネットワーク送信を介して、その符号化ビデオデータを宛先機器14に提供することができる。同様に、ディスクスタンピング設備などの媒体製造設備のコンピュータ機器は、発信源機器12から符号化ビデオデータを受信し、その符号化ビデオデータを含んでいるディスクを製造することができる。従って、コンピュータ可読媒体16は、様々な例において、様々な形態の1つ又は複数のコンピュータ可読媒体を含むことが理解されよう。
宛先機器14の入力インターフェース28は、コンピュータ可読媒体16から情報を受信する。コンピュータ可読媒体16の情報は、ブロック及び他のコード化ユニット、例えば、GOPの特性及び/又は処理を記述するシンタックス要素を含む、ビデオエンコーダ20によって定義されたシンタックス情報を含むことができ、シンタックス情報はまた、ビデオデコーダ30によって使用される。表示装置32は、復号されたビデオデータをユーザに表示し、陰極線管(CRT)、液晶表示器(LCD)、プラズマ表示器、有機発光ダイオード(OLED)表示器、又は別のタイプの表示装置などの、様々な表示装置のいずれかを備えることができる。
ビデオエンコーダ20及びビデオデコーダ30は各々、適用可能な場合、1つ又は複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェア、又はそれらの任意の組合せなどの、様々な適切なエンコーダ回路又はデコーダ回路のいずれかとして実施することができる。ビデオエンコーダ20及びビデオデコーダ30の各々は、1つ又は複数のエンコーダ又はデコーダ内に含むことができ、それらのいずれも合成ビデオエンコーダ/デコーダ(コーデック)の一部として統合することができる。ビデオエンコーダ20及び/又はビデオデコーダ30を含む機器は、集積回路、マイクロプロセッサ、及び/又は携帯電話などのワイヤレス通信機器を備えることができる。
図1には示されていないが、幾つかの態様では、ビデオエンコーダ20及びビデオデコーダ30は、各々オーディオエンコーダ及びオーディオデコーダと統合することができ、適切なMUX−DEMUXユニット、又は他のハードウェア及びソフトウェアを含んで、共通のデータストリーム又は別個のデータストリーム内のオーディオとビデオの両方の符号化を処理することができる。適用可能な場合、MUX−DEMUXユニットは、ITU H.223マルチプレクサプロトコル、又はユーザデータグラムプロトコル(UDP)などの他のプロトコルに準拠することができる。
図1に示された例では、システム10はまた、ルータ36を有するサーバ/コンテンツ配信ネットワーク34を含む。幾つかの例では、発信源機器12は、上述のように、様々なワイヤレス送信及び/又は有線送信又は記憶媒体を介して、サーバ/コンテンツ配信ネットワーク34と通信することができる。更に、図1の例では別々に示されたが、幾つかの例では、発信源機器12とサーバ/コンテンツ配信ネットワーク34は同じ機器を備える。サーバ/コンテンツ配信ネットワーク34は、(発信源機器12のビデオエンコーダ20からの)コード化ビデオデータの1つ又は複数のバージョンを記憶することができ、そのようなコード化ビデオデータを宛先機器14及びビデオデコーダ30によるアクセスに利用できるようにすることができる。幾つかの例では、ルータ36は、コード化ビデオデータを宛先機器14に、要求されたフォーマットで提供することを担当することができる。
ビデオエンコーダ20及びビデオデコーダ30は、現在開発中の高効率ビデオコード化(HEVC)規格などのビデオコード化規格に従って動作することができ、HEVCテストモデル(HM)に準拠することができる。代替的に、ビデオエンコーダ20及びビデオデコーダ30は、代替的にMPEG−4、Part 10、高度ビデオコード化(AVC)と呼ばれるITU−T H.264規格などの他のプロプライエタリ規格又は業界規格、又はそのような規格の拡張に従って動作することができる。しかしながら、本開示の技法は、いかなる特定のコード化規格にも限定されない。ビデオコード化規格の他の例には、MPEG−2及びITU−T H.263が含まれる。
ITU−T H.264/MPEG−4(AVC)規格は、Joint Video Team(JVT)として知られる共同パートナーシップの成果として、ISO/IEC Moving Picture Experts Group(MPEG)とともにITU−T Video Coding Experts Group(VCEG)によって策定された。幾つかの態様では、本開示に記載された技法は、一般にH.264規格に準拠する機器に適用することができる。H.264規格は、ITU−T研究グループによる2005年3月付けのITU−T勧告H.264「Advanced Video Coding for generic audiovisual services」に記載されており、本明細書ではH.264規格又はH.264仕様、又はH.264/AVC規格若しくはH.264/AVC仕様と呼ぶ場合がある。Joint Video Team(JVT)は、H.264/MPEG−4 AVCに対する拡張に取り組み続けている。
JCT−VCは、HEVC規格の開発に取り組んでいる。HEVC規格化の活動は、HEVCテストモデル(HM)と呼ばれるビデオコード化機器の発展的モデルに基づく。HMは、例えば、ITU−T H.264/AVCに従う既存の機器に対して、ビデオコード化機器の幾つかの追加の能力を仮定する。例えば、H.264は9つのイントラ予測符号化モードを提供するが、HMは33個ものイントラ予測符号化モードを提供することができる。
一般に、HMの作業モデルは、ビデオピクチャが、ルーマサンプルとクロマサンプルの両方を含む、一連のツリーブロック又は最大コード化単位(LCU)に分割できることを記述する。ビットストリーム内のシンタックスデータは、画素の数に関して最大コード化単位であるLCU用のサイズを確定することができる。スライスは、コード化順序で幾つかの連続的なツリーブロックを含む。ピクチャは、1つ又は複数のスライスに区分することができる。各ツリーブロックは、4分木に従ってコード化単位(CU)に分割することができる。一般に、4分木データ構造はCUごとに1つのノードを含み、ルートノードはツリーブロックに対応する。CUが4つのサブCUに分割された場合、CUに対応するノードは4つのリーフノードを含み、リーフノードの各々はサブCUのうちの1つに対応する。
4分木データ構造の各ノードは、対応するCUにシンタックスデータを提供することができる。例えば、4分木内のノードは、そのノードに対応するCUがサブCUに分割されるかどうかを示す分割フラグを含むことができる。CU用のシンタックス要素は再帰的に定義することができ、CUがサブCUに分割されるかどうかに依存する場合がある。CUがこれ以上分割されない場合、そのCUはリーフCUと呼ばれる。本開示では、元のリーフCUの明示的分割が存在しない場合でも、リーフCUの4つのサブCUもリーフCUと呼ばれる。例えば、16×16サイズのCUがこれ以上分割されない場合、この16×16CUが決して分割されなくても、4つの8×8サブCUもリーフCUと呼ばれる。
CUは、CUがサイズ差異を有していないことを除いて、H.264規格のマクロブロックと同様の目的を有する。例えば、ツリーブロックは、(サブCUとも呼ばれる)4つの子ノードに分割することができ、各子ノードが今度は親ノードになり、別の4つの子ノードに分割することができる。4分木のリーフノードと呼ばれる、最後の分割されない子ノードは、リーフCUとも呼ばれるコード化ノードを備える。コード化ビットストリームに関連するシンタックスデータは、最大CU深さと呼ばれる、ツリーブロックを分割できる最大回数を確定することができ、また、コード化ノードの最小サイズを確定することもできる。それに応じて、ビットストリームは最小コード化ユニット(SCU)を確定することもできる。本開示は、HEVCのコンテキストにおけるCU、PU、もしくはTU、又は他の規格のコンテキストにおける同様のデータ構造(例えば、H.264/AVCにおけるマクロブロック及びそのサブブロック)のいずれかを指すために「ブロック」という用語を使用する。
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は、形状が正方形又は非正方形(例えば、矩形)であり得る。
HEVC規格は、異なるCUで異なる場合があるTUに従って、変換を可能にする。TUは、通常、区分されたLCU用に確定された所与のCU内のPUのサイズに基づいてサイズ決定されるが、常にそうであるとは限らない。TUは、通常、PUと同じサイズであるか又はPUよりも小さい。幾つかの例では、CUに対応する残差サンプルは、「残差4分木」(RQT)として知られる4分木構造を使用して、より小さい単位に再分割することができる。RQTのリーフノードは変換単位(TU)と呼ばれる場合がある。TUに関連する画素差分値は、変換されて変換係数を生成することができ、その変換係数は量子化することができる。
リーフCUは、1つ又は複数の予測単位(PU)を含むことができる。一般に、PUは、対応するCUの全部又は一部に対応する空間的エリアを表し、そのPU用の参照サンプルを取り出すためのデータを含むことができる。更に、PUは予測に関係するデータを含む。例えば、PUがイントラモードで符号化されるとき、PU用のデータは残差4分木(RQT)に含むことができ、RQTはPUに対応するTU用のイントラ予測モードを記述するデータを含むことができる。別の例として、PUがインターモードで符号化されるとき、PUは、PU用の1つ又は複数の動きベクトルを確定するデータを含むことができる。PU用の動きベクトルを確定するデータは、例えば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトル用の解像度(例えば、1/4画素精度もしくは1/8画素精度)、動きベクトルが指す参照ピクチャ、及び/又は動きベクトル用の参照ピクチャリスト(例えば、リスト0、リスト1、もしくはリストC)を記述することができる。
1つ又は複数のPUを有するリーフCUはまた、1つ又は複数の変換単位(TU)を含むことができる。変換ユニットは、上記で説明されたように、(TU4分木構造とも呼ばれる)RQTを使用して指定することができる。例えば、分割フラグは、リーフCUが4つの変換単位に分割されるかどうかを示すことができる。次いで、各変換ユニットは、更なるサブTUに更に分割することができる。TUがこれ以上分割されないとき、そのTUはリーフTUと呼ぶことができる。一般に、イントラコード化の場合、リーフCUに属する全てのリーフTUは、同じイントラ予測モードを共有する。即ち、一般に、リーフCUの全てのTUについて予測値を計算するように、同じイントラ予測モードが適用される。イントラコード化の場合、ビデオエンコーダ20は、イントラ予測モードを使用してリーフTUごとの残差値を、TUに対応するCUの一部と元のブロックとの間の差分として計算することができる。TUは、必ずしもPUのサイズに制限されるとは限らない。従って、TUはPUよりも大きく又は小さくなることができる。イントラコード化の場合、PUは、同じCU用の対応するリーフTUと同一位置とすることができる。幾つかの例では、リーフTUの最大サイズは、対応するリーフCUのサイズに該当する場合がある。
更に、リーフCUのTUはまた、残差4分木(RQT)と呼ばれる、それぞれの4分木データ構造に関連付けることができる。即ち、リーフCUは、リーフCUがどのようにTUに区分されるかを示す4分木を含むことができる。TU4分木のルートノードは、一般にリーフCUに対応し、CU4分木のルートノードは、一般にツリーブロック(又はLCU)に対応する。分割されないRQTのTUはリーフTUと呼ばれる。一般に、本開示は、特に明記しない限り、リーフCU及びリーフTUに言及するために、それぞれCU及びTUという用語を使用する。
ビデオシーケンスは、通常、一連のピクチャを含む。本明細書に記載されるように、「ピクチャ」と「フレーム」は互換的に使用することができる。即ち、ビデオデータを含んでいるピクチャは、ビデオフレーム又は単に「フレーム」と呼ばれる場合がある。ピクチャのグループ(GOP)は、一般に、ビデオピクチャのうちの一連の1つ又は複数を備える。GOPは、GOP内に含まれるピクチャの数を記述するシンタックスデータを、GOPのヘッダ内、ピクチャのうちの1つ又は複数のヘッダ内、又は他の場所に含むことができる。ピクチャの各スライスは、それぞれのスライス用の符号化モードを記述するスライスシンタックスデータを含むことができる。ビデオエンコーダ20は、通常、ビデオデータを符号化するために、個々のビデオスライス内のビデオブロックに対して動作する。ビデオブロックは、CU内のコード化ノードに対応することができる。ビデオブロックは、固定サイズ又は可変サイズを有することができ、指定されたコード化規格に従ってサイズが異なる場合がある。
一例として、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を指す。
本開示では、「N×N(NxN)」と「N×N(N by N)」は、垂直寸法及び水平寸法に関するビデオブロックの画素寸法、例えば、16×(x)16画素又は16×(by)16画素を指すために互換的に使用することができる。一般に、16×16ブロックは、垂直方向に16画素を有し(y=16)、水平方向に16画素を有する(x=16)。同様に、N×Nブロックは、一般に、垂直方向にN画素を有し、水平方向にN画素を有し、ここでNは非負整数値を表す。ブロック内の画素は行と列とに配置することができる。更に、ブロックは、必ずしも、水平方向に垂直方向と同じ数の画素を有する必要があるとは限らない。例えば、ブロックはN×M画素を備えることができ、ここでMは必ずしもNに等しいとは限らない。
CUのPUを使用したイントラ予測コード化又はインター予測コード化の後、ビデオエンコーダ20は、CUのTU用の残差データを計算することができる。PUは、(画素領域とも呼ばれる)空間領域において予測画素データを生成する方法又はモードを記述するシンタックスデータを備えることができ、TUは、変換、例えば、残差ビデオデータに対する離散コサイン変換(DCT)、整数変換、ウェーブレット変換、又は概念的に同様の変換の適用後、変換領域において係数を備えることができる。残差データは、符号化されていないピクチャの画素と、PUに対応する予測値との間の画素差分に対応することができる。ビデオエンコーダ20は、CU用の残差データを含むTUを形成し、次いで、TUを変換して、CU用の変換係数を生成することができる。
変換係数を生成する任意の変換の後、ビデオエンコーダ20は、変換係数の量子化を実行することができる。量子化は、一般に、係数を表すために使用されるデータの量をできるだけ低減するために変換係数を量子化するプロセスを指し、更なる圧縮を提供する。量子化プロセスは、係数の一部又は全部に関連するビット深さを低減することができる。例えば、量子化中にnビットの値をmビットの値に切り捨てることができ、ここでnはmよりも大きい。
量子化の後、ビデオエンコーダは変換係数を走査して、量子化変換係数を含む2次元行列から1次元ベクトルを生成することができる。走査は、より高いエネルギー(従ってより低い周波数)の係数をアレイの前方に配置し、より低いエネルギー(従ってより高い周波数)の係数をアレイの後方に配置するように設計することができる。幾つかの例では、ビデオエンコーダ20は、量子化変換係数を走査して、エントロピー符号化できるシリアル化ベクトルを生成するために、予め定義された走査順序を利用することができる。他の例では、ビデオエンコーダ20は適応走査を実行することができる。量子化変換係数を走査して1次元ベクトルを形成した後、ビデオエンコーダ20は、例えば、コンテキスト適応型可変長コード化(CAVLC)、コンテキスト適応型二値算術コード化(CABAC)、シンタックスベースコンテキスト適応型二値算術コード化(SBAC)、確率間隔区分エントロピー(PIPE)コード化、又は別のエントロピー符号化方法に従って、1次元ベクトルをエントロピー符号化することができる。ビデオエンコーダ20はまた、ビデオデータを復号する際にビデオデコーダ30が使用するための符号化ビデオデータに関連するシンタックス要素をエントロピー符号化することができる。
CABACを実行するために、ビデオエンコーダ20は、送信されるべきシンボルにコンテキストモデル内のコンテキストを割り当てることができる。コンテキストは、例えば、シンボルの近傍値が非0であるか否かに関係する場合がある。CAVLCを実行するために、ビデオエンコーダ20は、送信されるべきシンボル用の可変長コードを選択することができる。VLCにおけるコードワードは、比較的短いコードが優勢シンボルに対応し、より長いコードが劣勢シンボルに対応するように構築することができる。このようにして、VLCを使用すると、例えば、送信されるべきシンボルごとに等長コードワードを使用するよりも、ビット節約を実現することができる。確率判断は、シンボルに割り当てられるコンテキストに基づく場合がある。
ビデオエンコーダ20は更に、ブロックベースのシンタックスデータ、ピクチャベースのシンタックスデータ、及びGOPベースのシンタックスデータなどのシンタックスデータを、例えば、ピクチャヘッダ、ブロックヘッダ、スライスヘッダ、又はGOPヘッダの中でビデオデコーダ30に送ることができる。GOPシンタックスデータは、それぞれのGOP内のピクチャの数を記述することができ、ピクチャシンタックスデータは、対応するピクチャを符号化するために使用される符号化/予測モードを示すことができる。
幾つかの例では、ビデオデータを復号するときに使用できる特定のパラメータセットを、ビデオエンコーダ20は生成することができ、ビデオデコーダ30は受信することができる。例えば、パラメータセットは、(シーケンスパラメータセット(SPS)内の)シーケンスレベルヘッダ情報と、(ピクチャパラメータセット(PPS)内の)まれにしか変化しないピクチャレベルヘッダ情報とを含んでいる場合がある。パラメータセット(例えば、PPS及びSPS)がある場合、まれにしか変化しない情報をシーケンス(例えば、ピクチャのシーケンス)ごと又はピクチャごとに繰り返す必要はなく、従ってコード化効率を改善することができる。更に、パラメータセットを使用すると、重要なヘッダ情報の帯域外送信が可能になり、誤り耐性のための冗長送信の必要を回避することができる。帯域外送信の例では、補足強調情報(SEI)のNALユニットなどの他のNALユニットとは異なるチャネル上で、パラメータセットのNALユニットを送信することができる。
(SEIメッセージと呼ばれる)SEIのNALユニットは、VCLのNALユニットからのコード化ピクチャサンプルを復号するためには必要でないが、復号、表示、誤り耐性、及び他の目的に関係するプロセスを支援できる情報を含んでいる場合がある。SEIメッセージは、非VCLのNALユニットに含まれている場合がある。SEIメッセージは、幾つかの標準仕様の規範部分に含まれている場合があり、従って、標準準拠のデコーダ実施のために常に必須であるとは限らない。SEIメッセージは、シーケンスレベルのSEIメッセージ又はピクチャレベルのSEIメッセージであり得る。SVCの例ではスケーラビリティ情報SEIメッセージ、MVCではビュースケーラビリティ情報SEIメッセージなどのSEIメッセージ内に、何らかのシーケンスレベル情報が含まれている場合がある。
幾つかの例では、ビデオエンコーダ20は、H.264/AVCに対するMVC拡張に準拠するMVCビットストリームを符号化することができる。同様に、ビデオデコーダ30は、H.264/AVCに対するMVC拡張に準拠するMVCビットストリームを復号することができる。MVCの最新の共同ドラフトは、http://wftp3.itu.int/av−arch/jvt−site/2009_01_Geneva/JVT−AD007から公的に入手可能なJVT−AD007、「 ITU−T Rec.H.264|ISO/IEC 14496−10 Advanced Video Codingに対する編集者のドラフト改訂」、第30回JVTミーティング、ジュネーブ、スイス、2008年1月〜2月に記載されている。
H.264/AVCのスケーラブル拡張では、シンタックス要素は、NALユニットヘッダ拡張部に追加されて、複数の寸法でVCLのNALユニットの特性を記述するように、NALユニットヘッダを1バイトから4バイトに拡張することができる。従って、HEVC内のVCLのNALユニットは、H.264/AVC規格内のNALユニットヘッダよりも長いNALユニットヘッダを含むことができる。H.264/AVCに対するMVC拡張は、本開示では「MVC/AVC」と呼ばれる場合がある。
MVC/AVCのNALユニットは、NALユニットタイプを含む1バイトのNALユニットヘッダ、及びMVC/AVCのNALユニットヘッダ拡張部を含むことができる。一例として、MVC/AVCのNALユニットヘッダ拡張部は、以下の表1の中のシンタックス要素を含むことができる。
上記の表1では、idr_flag要素は、NALユニットが瞬時復号リフレッシュ(IDR)ピクチャに属するか、又は閉GOPランダムアクセスポイントとして使用できるビューIDR(V−IDR)ピクチャに属するかを示すことができる。例えば、IDRピクチャ、及び表示順序とビットストリーム順序の両方でそれに続く全てのピクチャは、ビットストリーム順序又は表示順序のいずれかで前のピクチャを復号することなしに正しく復号することができる。priority_id要素は、変化するネットワーク状態及び/又は(例えば、単一パス適応プロセスなどの)ビデオデコーダ30及び/又は表示装置32の能力に応じてビットストリームを変更する、ビットストリーム適応プロセスで使用することができる。view_id要素は、NALユニットが所属するビューのビュー識別子を示すために使用することができ、ビュー識別子は、例えば、ビュー間予測用にMVCデコーダの内部で、レンダリング用にデコーダの外部で使用することができる。幾つかの例では、view_idは、予め定義されたカメラIDに等しく設定することができ、比較的大きい場合がある。temporal_id要素は、特定のフレームレートに対応できる、現在のNALユニットの時間レベルを示すために使用することができる。
anchor_pic_flag要素は、NALユニットが開GOPランダムアクセスポイントとして使用できるアンカーピクチャに属するかどうかを示すために使用することができる。例えば、アンカーピクチャ、及び表示順序でそれに続く全てのピクチャは、復号順序(即ち、ビットストリーム順序)で前のピクチャを復号することなしに正しく復号することができ、従ってランダムアクセスポイントとして使用することができる。アンカーピクチャと非アンカーピクチャとは異なるビュー依存性を有することができ、それらの両方はSPS内で通知することができる。即ち、本明細書に記載されたように、ビュー依存性は、一般に、現在コード化されているビューが依存するビューを指す。言い換えれば、ビュー依存性は、現在コード化されているビューをどのビューから予測できるかを説明することができる。幾つかの例によれば、ビュー依存性は、SPSのMVC拡張において通知することができる。そのような例では、全てのビュー間予測は、SPSのMVC拡張によって指定された範囲内で行うことができる。inter_view_flag要素は、NALユニットが他のビュー内のNALユニット用のビュー間予測に使用されるかどうかを示すために使用することができる。
MVCビットストリームのベースビュー用の上記4バイトのNALユニットヘッダ情報を搬送するために、プレフィックスNALユニットをMVC内に定義することができる。MVCのコンテキストにおいて、ベースビューアクセスユニットは、特定のビューの現在時間インスタンスのVCLのNALユニット、及びベースビューアクセスユニット用のプレフィックスNALユニットを含むことができ、プレフィックスNALユニットはNALユニットヘッダのみを含んでいる場合がある。プレフィックスNALユニットが(例えば、単一ビューの復号などの)復号に必要でない場合、デコーダはプレフィックスNALユニットを無視及び/又は廃棄することができる。
SPSのMVC/AVC拡張に関して、MVCのSPSはビュー間予測の目的で使用できるビューを示すことができる。例えば、潜在的なビュー間参照は、SPSのMVC/AVC拡張において通知することができ、インター予測参照又はビュー間予測参照のフレキシブルな順序付けを可能にする参照ピクチャリストの構築プロセスによって修正することができる。例示的なMVC/AVCのSPSが下記の表2で説明される。
幾つかの例によれば、ビュー依存性は、SPSのMVC拡張において通知することができる。全てのビュー間予測は、SPSのMVC拡張によって指定された範囲内で行うことができる。即ち、SPSは、現在コード化されているビューによる予測の目的でどのビューを参照できるかを説明することができる。上記の表2では、num_anchor_refs_l0[i]要素は、リスト0(例えば、RefPicList0)用の初期化された参照ピクチャリスト内のビュー間予測用のビューコンポーネントの数を指定することができる。加えて、anchor_ref_l0[i][j]要素は、初期化されたRefPicList0内のビュー間予測用の第jのビューコンポーネントのview_idを指定することができる。num_anchor_refs_l1[i]要素は、リスト1(例えば、RefPicList1)用の初期化された参照ピクチャリスト内のビュー間予測用のビューコンポーネントの数を指定することができる。anchor_ref_l1[i][j]要素は、初期化されたRefPicList1内のビュー間予測用の第jのビューコンポーネントのview_idを指定することができる。num_non_anchor_refs_l0[i]要素は、初期化されたRefPicList0内のビュー間予測用のビューコンポーネントの数を指定することができる。non_anchor_ref_l0[i][j]要素は、初期化されたRefPicList0内のビュー間予測用の第jのビューコンポーネントのview_idを指定することができる。num_non_anchor_refs_l1[i]要素は、初期化されたRefPicList1内のビュー間予測用のビューコンポーネントの数を指定することができる。non_anchor_ref_l1[i][j]要素は、初期化されたRefPicList内のビュー間予測用の第jのビューコンポーネントのview_idを指定することができる。
初期化された、又は「初期の」参照ピクチャリストは、ビューコンポーネントをビュー間予測する目的で使用される最後の参照ピクチャリストと同じか又は異なる場合がある。即ち、特定の参照候補(即ち、ビュー間予測に使用できる参照ピクチャ)は、初期の参照ピクチャリスト(例えば、冗長なピクチャ)から削除することができる。加えて、以下でより詳細に記載されるように、参照候補は、初期の参照ピクチャリストから並べ替えられて、最後の参照ピクチャリストを形成することができる。
この例では、MVC/AVCによれば、アンカーピクチャ用のビュー依存性と非アンカーピクチャ用のビュー依存性は、別々に維持及び通知することができる。即ち、ビデオコーダは、合計4個の参照ピクチャリスト(例えば、非アンカーピクチャのリスト0、非アンカーピクチャのリスト1、アンカーピクチャのリスト0、アンカーピクチャのリスト1)を決定することができる。加えて、上記の表2に示されたように、ビデオデコーダ30にビュー依存性を示すために別の信号伝達が必要である。即ち、SPSは、anchor_refsとnon_anchor_refsの両方に信号伝達する別個のリスト0とリスト1とを含むことができる。
更に、表2によれば、非アンカービューコンポーネント用のビュー間依存性は、アンカービューコンポーネント用のビュー間依存性のサブセットである。即ち、例えば、アンカービューのビューコンポーネントは、ビュー3とビュー4などの2つ以上の他のビューから予測することができる。しかしながら、非アンカービューは、ビュー3(アンカービューのサブセット)のピクチャから予測することしかできない。このようにして、アンカービューコンポーネント用のビュー依存性と非アンカービューコンポーネント用のビュー依存性は、別々に維持することができる。
加えて、表2では、num_level_values_signalledは、コード化ビデオシーケンスに通知されたレベル値の数を指定することができる。level_idc[i]要素は、コード化ビデオシーケンスに通知された第iのレベル値を指定することができる。num_applicable_ops_minus1[i]プラス1要素は、level_idc[i]によって示されたレベルが適用される動作点の数を指定することができる。applicable_op_temporal_id[i][j]要素は、level_idc1[i]によって示されたレベルが適用される第jの動作点のtemporal_idを指定することができる。applicable_op_num_target_views_minus1[i][j]要素は、level_idc[i]によって示されたレベルが適用される第jの動作点用のターゲット出力ビューの数を指定することができる。applicable_op_target_view_id[i][j][k]要素は、level_idc[i]によって示されたレベルが適用される第jの動作点用の第kのターゲット出力ビューを指定することができる。applicable_op_num_views_minus1[i][j]要素は、level_idc[i]によって示されたレベルが適用される第jの動作点で、ターゲット出力ビューによって依存されるが、ターゲット出力ビューに属さないビューを含むビューの数を指定することができる。
従って、SPSのMVC拡張では、ビューごとに、参照ピクチャリスト0と参照ピクチャリスト1とを形成するために使用できるビューの数を通知することができる。加えて、SPSのMVC拡張で通知されたアンカーピクチャ用の予測関係は、同じビューの(SPSのMVC拡張で通知された)非アンカーピクチャ用の予測関係とは異なる場合がある。
以下でより詳細に記載されるように、ビデオエンコーダ20及びビデオデコーダ30は、参照ピクチャリストを構築するときに、時間予測参照とビュー予測参照とをフレキシブルに配置することができる。参照ピクチャセクションと冗長ピクチャメカニズムとをビュー寸法に拡張することができるので、フレキシブルな配列を可能にすると、潜在的なコード化効率ゲインだけでなく誤り耐性も提供される。一例では、ビデオエンコーダ20及び/又はビデオデコーダ30は、以下のステップに従って参照ピクチャリストを構築することができる。
1)他のビューからの参照ピクチャが考慮されないように、時間的(即ち、ビュー内)参照ピクチャ用の参照ピクチャリストを初期化する。
2)ピクチャがMVCのSPS拡張で発生する順序で、ビュー間参照ピクチャをリストの最後に追加する。
3)参照ピクチャリスト並べ替え(RPLR)プロセスをビュー内参照ピクチャとビュー間参照ピクチャの両方に適用する。ビュー間参照ピクチャは、MVCのSPS拡張で指定されたそれらのインデックス値により、RPLRコマンド内で識別することができる。
H.264/AVCはMVCサポートを含むが、H.264/AVCに対する現在のMVC拡張は、他のビデオコード化規格に対して幾つかの非効率性を含んでいる場合がある。更に、以下でより詳細に説明されるように、H.264/AVCから今度のHEVC規格などの他のコード化規格へのMVCの直接インポートは、実現可能でない可能性がある。本開示の技法は、一般に、MVCと関係するNALユニット、MVCと関係するパラメータセットなどの形成に関する。本開示の技法は、任意の特定のコード化規格に限定されないが、本開示の特定の技法は、今度のHEVC規格用の効率的なMVCコード化を可能にすることができる。
一例として、H.264/MVC規格は1024個までのビューをサポートし、NALユニットヘッダ内のビュー識別子(view_id)を使用して、NALユニットが属するビューを識別する。ビューIDは10ビットの長さなので、ビューIDの値により1000個を超える異なるビューを一意に識別することができる。しかしながら、多くの3次元(3D)ビデオアプリケーションは、かなり少ないビューしか必要としない。更に、ビュー合成を使用してより多くの(コード化を必要としない)ビューを生成する3Dビデオアプリケーションには、より少ないビューしか必要とされない可能性がある。MVC/AVC拡張によれば、NALユニットヘッダは、常に提供される10ビットのビューIDを含む。ビューIDは、NALユニットヘッダ用のビットの数を実質的に増加させる可能性があり、NALユニットヘッダはビットストリームの比較的大きな部分を占める。
本開示の態様によれば、ビュー順序インデックス(「view_order_index」又は「view_idx」)は、NALユニットヘッダの一部として通知することができる。即ち、ビュー順序インデックスをNALユニットヘッダの一部として、ビデオエンコーダ20は符号化し送信することができ、ビデオデコーダ30は受信し復号することができる。比較の目的で、ビュー順序インデックスは、H.264/AVCに対するMVC拡張(以下「MVC/AVC」)のNALユニットヘッダ内に通知されたビューIDと置き換わることができる。即ち、例えば、view_idxはNALユニットヘッダ内のview_idと置き換わることができる。
上記で説明されたように、MVCはビュー間予測を提供する。従って、参照用に使用されるビュー(即ち、他のビューを予測するために使用されるビュー)は、上記で説明されたように、参照するビューよりも前のコード化順序で発生しなければならない。ビュー順序は、一般に、アクセスユニット内のビューの順序付けを記述し、ビュー順序インデックスは、そのアクセスユニットのビュー順序における特定のビューを識別する。即ち、ビュー順序インデックスは、アクセスユニットの対応するビューコンポーネントの復号順序を記述する。
SPSは、ビュー用のビューID(view_ids)とビュー用のビュー順序インデックスとの間の関係を提供することができる。本開示の態様によれば、ビュー順序インデックスとSPS内のデータとを使用して、ビデオエンコーダ20及びビデオデコーダ30は、NALユニットヘッダ内のMVC/AVCの10ビットのview_idをビュー順序インデックスと置き換えることができる。例えば、ビュー順序インデックスは、(例えば、2ビット、3ビットなどの)10よりもかなり少ないビットを含む場合がある。ビュー順序インデックスとビューIDとの間の関係は、幾つかの関連する信号伝達を必要とする場合があるが、例えば、SPSでは、NALユニットヘッダは、通常そのような信号伝達よりもはるかに多いビットを消費する。従って、NALユニットヘッダのサイズを縮小することによって、本開示の技法は、MVC/AVCの方式上でビット節約を実現することができる。関係を示す情報は、例えば、ビュー順序インデックスの値にview_id値をマッピングするマッピングテーブルを備えることができる。このようにして、ビデオデコーダ30は、単にNALユニットヘッダ内のビュー順序インデックスの値を受信し、マッピングテーブルを使用してNALユニットのview_idを決定することができる。
本開示の幾つかの態様によれば、ビュー順序インデックスは、それがHEVCベースビューか、プロファイルか、又はMVCビットストリーム内でサポートされるビューの数かに応じて、動的な長さを有することができる。例えば、更なるビット節約は、2つだけのビューを含む(即ち、ステレオビデオ用の)MVCストリーム内で実現することができる。この例では、ビデオデコーダ30が常に第2のビュー(例えば、ビュー1)を復号する前に第1のビュー(例えば、ビュー0)を復号するので、ビュー順序インデックスは必要とされない可能性がある。即ち、本開示の幾つかの態様によれば、ベースビューは、0のデフォルトのビュー順序インデックスを割り当てることができ、従って通知される必要がない。
加えて、上述のビュー順序インデックスを使用するとき、MVC/AVCベースビューのベースビュー(例えば、ビュー0)のNALユニットの直前に含まれるプレフィックスNALユニットは、もはや必要とされない可能性がある。例えば、ビュー順序インデックスがベースビューについて常に0であり得るし、ベースビューの時間位置が(MCV/AVC内に含まれる)temporal_idを使用して決定できるので、ビデオデコーダ30は、ベースビュー用のプレフィックスNALユニットをもはや必要としない可能性がある。従って、ビデオエンコーダ20は、NALユニットヘッダ内のtemporal_idを通知することができ、temporal_idは、ビデオデコーダ30に必要な情報の全てを提供して、特定のビューコンポーネントを特定のビューと適切な時間位置とに関連付けることができる。
新HEVC規格に関して、本開示の態様によれば、プレフィックスNALユニットがHEVC準拠ベースビューに使用されないとき、HEVCベースビューのNALユニットヘッダにフラグを追加することができる。フラグは、(その特定のNALユニットの)ビューコンポーネントが、ビットストリームの他のビューのビューコンポーネントをインター予測するために使用できるかどうかを示すためのみに使用することができる。
加えて、本開示の態様によれば、ビュー順序インデックスは、(例えば、ピクチャの表示順序を示す)ピクチャ順序カウント(POC)値又は(例えば、ピクチャの復号順序を示す)フレーム値とともに使用されて、ビットストリームのビューコンポーネントを識別することができる。
別の例として、上記のように、MVC/AVCのSPSは、ビューごとに別々に依存ビュー(即ち、予測の目的で1つ又は複数の他のビューによって参照されるビュー)を示すことができる。例えば、MVC/AVCのNALユニットヘッダ内に含まれるanchor_pic_flagは、NALユニットが開GOPランダムアクセスポイントとして使用できるアンカーピクチャに属するかどうかを示すために使用することができる。MVC/AVCでは、上述のように、ビュー依存性は、アンカーピクチャと非アンカーピクチャに異なって通知される。従って、ビューごとに通知される依存ビューについて、4つの異なるカテゴリが考えられ、それらの各々は、ピクチャがアンカーピクチャ用かどうか、又はピクチャがリスト0用かもしくはリスト1用かによって差別化される。そのような設計は、そのような分界を維持するために比較的大きい数のビットを必要とするだけでなく、参照ピクチャリストの構築を複雑にする場合もある(例えば、各カテゴリは参照リストの構築及び並べ替えの間維持されなければならない)。
本開示の態様によれば、ビューコンポーネントがアンカーピクチャ用か又は非アンカーピクチャ用かにかかわらず、ビデオエンコーダ20は、通常全てのビューコンポーネントについてMVCビットストリームのビューごとにビュー依存性を通知することができる(ビデオデコーダ30はそのような信号伝達を受信することができる)。幾つかの例では、SPSは、NALユニットヘッダ内の情報に依存するのではなく、ビューコンポーネント用のビュー依存性の指示を含む。このようにして、ビデオエンコーダ20及びビデオデコーダ30は、MVC/AVCのNALユニットヘッダ内で使用されるanchor_pic_flagを使用しない場合がある。
通知された依存ビューのビューコンポーネントは、リスト0とリスト1の両方で参照ピクチャとして使用することができる。加えて、リスト0及びリスト1についての参照ピクチャリストの構築及び参照ピクチャリストの並べ替えは、アンカーピクチャ及び非アンカーピクチャへの通常信号伝達に基づく場合もある。幾つかの例では、シーケンスレベル、補足強調情報(SEI)メッセージは、非アンカーピクチャがアンカーピクチャとは異なるビュー依存性を有するときを示すために使用することができる。
従って、本開示の特定の態様は、MVC/AVCのアンカーピクチャ/非アンカーピクチャとリスト0/リスト1との信号伝達差異を削除すること、それによりビットストリームを簡略化すること、及び参照ピクチャリストの構築に関する。例えば、本開示の態様によれば、ビデオデコーダ30は、第1のビューの任意のビューコンポーネントについて、第1のビューのビューコンポーネントを予測するための1つ又は複数の参照ビューを示す参照ビュー情報を受信することができる。即ち、ビデオデコーダ30は、ビューのアンカーピクチャ用及び同様のビューの非アンカーピクチャ用のビュー依存性を示す参照ビュー情報を受信することができる。上述のように、参照ビュー情報は、例えば、各参照ビューに関連する(アクセスユニット内のビューの復号順序を示す)ビュー順序インデックスを含むことができる。
加えて、特定のビューの(アクセスユニットの)特定のピクチャを復号するとき、ビデオデコーダ30は、特定のピクチャと同じアクセスユニットから、及び参照ビュー情報によって示された参照ビューからの参照候補(例えば、特定のピクチャがそれから予測できるビューコンポーネント)を含むことができる。幾つかの例では、ビデオデコーダ30は、参照候補の数が参照ビューの数と等しくなるように、各参照ビューから参照ピクチャリストに参照候補を追加することができる。加えて、ビデオデコーダ30は、リスト1、リスト0、又は両方のいずれかに参照候補を追加することができる。次いで、ビデオデコーダ30は、参照ピクチャリスト内の参照ピクチャのうちの1つに基づいて、特定のピクチャを復号することができる。
更に別の例として、上述のように、priority_idは、MVC/AVC準拠ビットストリームのNALユニットヘッダに含まれる。priority_idは、特定のNALユニットの優先度の指示を提供する。より詳細には、各NALユニットは、慣例的に優先度値を割り当てられる。優先度値Pに対する要求に応答して、P以下の優先度値を有する全てのNALユニットが提供される(即ち、Pより大きいpriority_id値を有するNALユニットは廃棄される)。このようにして、より低い優先度値がより高い優先度を指定する。例えば、ビュー内の時間スケーラビリティについて、同じビューのNALユニットが異なる優先度を有する場合があることを理解されたい。
この優先度は、スケーラビリティの目的で使用することができる。例えば、(比較的低い品質の表示を形成するという犠牲を払って)最小量の帯域幅を消費するビデオデータを取り出すために、ビデオデコーダ30(又は、より一般的に宛先機器14)は、最も高い優先度のNALユニットだけが、発信源機器12/ビデオエンコーダ20などの発信源から送信されることを要求することができ、priority_idはより低い優先度のNALユニットをフィルタ処理して除くために使用することができる。幾つかの例では、サーバ/コンテンツ配信ネットワーク34のルータ36は、priority_idを使用して、比較的高い優先度のNALユニットをより低い優先度のNALユニットから分離することができる。(より高い帯域幅の消費という犠牲を払って)比較的高い品質の表示を生成するために、ビデオデコーダ30は、例えば、より高い優先度値を指定することによって、より低い優先度を有するNALユニットがより高い優先度のNALユニットを補足することを要求することができる。
本開示の態様によれば、NALユニットヘッダ内のpriority_idを通知するのではなく、ビデオエンコーダ20はSPS内のpriority_id値を提供することができる。即ち、特定の時間レベルを有するビューごとのpriority_idは、シーケンスレベルで通知することができる。加えて、本開示の態様によれば、単一パスの適応は、その適応に関連する信号伝達コンテキストが知られている限り可能であり得る。
上記で説明されたように、幾つかの例では、ビットストリームを宛先機器14に転送することを担当することができるルータ36は、SPSのpriority_id値を使用して特定のビューをフィルタ処理することができる。即ち、ルータ36は完全なビットストリームを受信することができるが、宛先機器14によって指定された優先度値以下のpriority_id値を有するNALユニットを含むサブビットストリームを抽出し、そのサブビットストリームを宛先機器に転送することができる。
更に別の例では、MVC/AVCによれば、単一パスの適応は、NALユニットヘッダ内の6ビットのpriority_idを必要とする。例えば、上記のように、MVC/AVCのSPSは、ビュースケーラビリティ用のビューレベル指示を含むことができる。即ち、MVCビットストリームの各ビューは、階層的にコード化し、数値のビューレベルを割り当てることができる。
本開示の態様によれば、SPSはビューレベル情報を含むことができる。従って、宛先機器14がサーバ/コンテンツ配信ネットワーク34からビューレベルVのビューを要求するとき、宛先機器14は、V以下のビューレベルを有する全てのビューを受信する。上述のpriority_id値の使用と同様に、サーバ/コンテンツ配信ネットワーク34のルータ36は、ビューレベルを使用して、クライアントが要求したビューレベル以下のビューレベルを有するビュー用のデータを含むサブビットストリームを抽出することができる。
本開示の他の態様は、より高いプロファイルのサブビットストリームをより低いプロファイルに準拠するビットストリームに変換する軽量トランスコード化プロセスに関する。そのようなトランスコード化プロセスは、例えば、サーバ/コンテンツ配信ネットワーク34によって実行することができる。本開示の態様によれば、トランスコード化は以下のステップで実行することができる。
1)SPS内のview_idx値とview_id値とを再マッピングする。
2)短い長さのview_idxでNALユニットヘッダをサイズ変更する。
例えば、自由視点テレビジョン(FVT)プロファイルのビットストリームが、ビューごとにview_idxがview_idに等しい32個のビューを含んでいると仮定されたい。この例では、ビットストリームは、0、4、8、12、16、20、24、28に等しいview_idxを有する8個のビューを含んでいるサブビットストリームを有する。このサブビットストリームは、view_id値が0及び4である2つのビューを含んでいるサブビットストリームを更に含む。
本開示の態様によれば、8ビューのサブビットストリーム用のview_idx値は、下記の表3に従って再マッピングすることができる。
本開示の態様によれば、2ビューのサブビットストリーム用のview_idx値は、下記の表4に従って再マッピングすることができる。
本開示の態様によれば、NALユニットヘッダ内のview_idxは、下記の表5に従って再マッピングすることができる。
代替として、上述の軽量トランスコード化プロセスは、準拠するビットストリームがビュー順序インデックス内のギャップを許す場合、view_idxの再マッピングを必要としない場合がある。
図2は、マルチビュービットストリームを符号化するための、本開示に記載された技法を実施できる例示的なビデオエンコーダ20を示すブロック図である。ビデオエンコーダ20は符号化されるべきビデオデータを受信する。図2の例では、ビデオエンコーダ20は、モード選択ユニット40と、加算器50と、変換処理ユニット52と、量子化ユニット54と、エントロピー符号化ユニット56と、参照ピクチャメモリ64とを含む。次に、モード選択ユニット40は、動き/視差推定ユニット42と、動き補償ユニット44と、イントラ予測ユニット46と、パーティションユニット48とを含む。
ビデオブロック復元のために、ビデオエンコーダ20はまた、逆量子化ユニット58と、逆変換処理ユニット60と、加算器62とを含む。ブロック境界をフィルタ処理して、復元されたビデオからブロッキネスアーティファクトを除去するデブロッキングフィルタ(図2に図示せず)も含むことができる。必要な場合、デブロッキングフィルタは、通常、加算器62の出力をフィルタ処理することになる。デブロッキングフィルタに加えて、(ループ内又はループ後の)追加ループフィルタも使用することができる。そのようなフィルタは、簡潔のために示されていないが、必要な場合、(ループ内フィルタとして)加算器50の出力をフィルタ処理することができる。
モード選択ユニット40は、1つ又は複数のビューからブロックの形態で未加工のビデオデータを受信することができる。モード選択ユニット40は、例えば、誤差結果に基づいてコード化モード、即ちイントラ又はインターのうちの1つを選択し、得られたイントラコード化ブロック又はインターコード化ブロックを、加算器50に提供して残差ブロックデータを生成し、加算器62に提供して参照ピクチャとして使用するための符号化ブロックを復元することができる。モード選択ユニット40はまた、動きベクトル、イントラモードインジケータ、パーティション情報、及び他のそのようなシンタックス情報などのシンタックス要素を、エントロピー符号化ユニット56に提供する。
動き/視差推定ユニット42と動き補償ユニット44は高度に統合できるが、概念的な目的のために別々に示される。動き/視差推定ユニット42によって実行される動き推定は、ビデオブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、例えば、現在ピクチャ(又は他のコード化単位)内のコード化されている現在ブロックに対する参照ピクチャ(又は他のコード化単位)内の予測ブロックに対する、現在ピクチャ内のビデオブロックのPUの変位を示すことができる。
予測ブロックは、絶対値差分和(SAD)、2乗差分和(SSD)、又は他の差分メトリックによって決定できる画素差分に関して、コード化されるべきブロックに厳密に一致することがわかるブロックである。幾つかの例では、ビデオエンコーダ20は、参照ピクチャバッファと呼ばれる場合もある参照ピクチャメモリ64に記憶された参照ピクチャのサブ整数画素位置の値を計算することができる。例えば、ビデオエンコーダ20は、参照ピクチャの1/4画素位置、1/8画素位置、又は他の分数画素位置の値を補間することができる。従って、動き/視差推定ユニット42は、フル画素位置及び分数画素位置に対する動き探索を実行し、分数画素精度で動きベクトルを出力することができる。
動き/視差推定ユニット42は、PUの位置を参照ピクチャの予測ブロックの位置と比較することによって、インターコード化スライス内のビデオブロックのPU用の動きベクトルを計算する。動き推定/視差ユニット42はまた、ビュー間予測を実行するように構成することができ、その場合、動き推定/視差ユニット42は、あるビューのピクチャ(例えば、ビュー0)のブロックと、参照ビューピクチャ(例えば、ビュー1)の対応するブロックとの間の変位ベクトルを計算することができる。一般に、動き/視差ベクトルについてのデータは、参照ピクチャリストと、参照ピクチャリストへのインデックス(ref_idx)と、水平成分と、垂直成分とを含むことができる。参照ピクチャは、第1の参照ピクチャリスト(リスト0)、第2の参照ピクチャリスト(リスト1)、又は合成参照ピクチャリスト(リストC)から選択することができ、それらの各々は、参照ピクチャメモリ64に記憶された1つ又は複数の参照ピクチャを識別する。合成リストに関して、ビデオエンコーダ20は、2つのリスト(即ち、リスト0及びリスト1)から合成リストに挿入(追加)されるべき項目を交互に選択する。項目が合成リスト内にすでに入れられているとき、POC数を検査することによって、ビデオエンコーダ20は、その項目を再び挿入することはできない。各リスト(即ち、リスト0又はリスト1)について、ビデオエンコーダ20は、参照インデックスの昇順に基づいて項目を選択することができる。
動き/視差推定ユニット42は、参照ピクチャの予測ブロックを識別する動き/視差ベクトルを生成し、エントロピー符号化ユニット56と動き補償ユニット44とに送ることができる。即ち、動き/視差推定ユニット42は、予測ブロックを含んでいる参照ピクチャリストを識別する動きベクトルデータと、予測ブロックのピクチャを識別する参照ピクチャリストへのインデックスと、識別されたピクチャ内の予測ブロックの位置を特定する水平成分及び垂直成分とを生成し、送ることができる。
動き補償ユニット44によって実行される動き補償は、動き/視差推定ユニット42によって決定された動き/視差ベクトルに基づいて、予測ブロックを取得又は生成することに関与することができる。この場合も、幾つかの例では、動き/視差推定ユニット42と動き補償ユニット44は機能的に統合することができる。現在ビデオブロックのPU用の動きベクトルを受信すると、動き補償ユニット44は、参照ピクチャリストのうちの1つにおいて動きベクトルが指す予測ブロックの位置を特定することができる。
加算器50は、以下で説明されるように、コード化されている現在ビデオブロックの画素値から予測ブロックの画素値を減算し、画素差分値を形成することによって、残差ビデオブロックを形成する。一般に、動き/視差推定ユニット42は、ルーマ成分に対して動き推定を実行し、動き補償ユニット44は、クロマ成分とルーマ成分の両方のためにルーマ成分に基づいて計算された動きベクトルを使用する。モード選択ユニット40はまた、ビデオスライスのビデオブロックを復号する際に、ビデオデコーダ30が使用するためのビデオブロックとビデオスライスとに関連するシンタックス要素を生成することができる。
イントラ予測ユニット46は、上述のように、動き/視差推定ユニット42及び動き補償ユニット44によって実行されるインター予測の代替として、現在ブロックをイントラ予測することができる。詳細には、イントラ予測ユニット46は、現在ブロックを符号化するために使用するイントラ予測モードを決定することができる。幾つかの例では、イントラ予測ユニット46は、例えば、別個の符号化パスの間、様々なイントラ予測モードを使用して現在ブロックを符号化することができ、イントラ予測ユニット46(又は、幾つかの例では、モード選択ユニット40)は、テストされたモードから使用するのに適切なイントラ予測モードを選択することができる。
例えば、イントラ予測ユニット46は、様々なテストされたイントラ予測モードについてのレート歪み分析を使用してレート歪み値を計算し、テストされたモードの中で最良のレート歪み特性を有するイントラ予測モードを選択することができる。レート歪み分析は、一般に、符号化ブロックと、符号化ブロックを生成するために符号化された元の符号化されていないブロックとの間の歪み(又は誤差)の量、及び符号化ブロックを生成するために使用されるビットレート(即ち、ビット数)を決定する。イントラ予測ユニット46は、どのイントラ予測モードがブロック用の最良のレート歪み値を呈するかを判断するために、様々な符号化ブロック用の歪み及びレートから比率を計算することができる。
ブロック用のイントラ予測モードを選択した後、イントラ予測ユニット46は、ブロック用に選択されたイントラ予測モードを示す情報を、エントロピー符号化ユニット56に提供することができる。エントロピー符号化ユニット56は、選択されたイントラ予測モードを示す情報を符号化することができる。ビデオエンコーダ20は、(コードワードマッピングテーブルとも呼ばれる)複数のイントラ予測モードインデックステーブル及び複数の修正されたイントラ予測モードインデックステーブルと、様々なブロック用の符号化コンテキストの定義と、最確イントラ予測モードの指示とを含む送信されたビットストリーム構成データの中に、コンテキストの各々について使用する、イントラ予測モードインデックステーブルと修正されたイントラ予測モードインデックステーブルとを含めることができる。
ビデオエンコーダ20は、コード化されている元のビデオブロックから、モード選択ユニット40からの予測データを減算することによって、残差ビデオブロックを形成する。加算器50は、この減算演算を実行する1つ又は複数の構成要素を代表する。変換処理ユニット52は、離散コサイン変換(DCT)又は概念的に同様の変換などの変換を残差ブロックに適用し、残差変換係数値を備えるビデオブロックを生成する。変換処理ユニット52は、DCTと概念的に同様である他の変換を実行することができる。ウェーブレット変換、整数変換、サブバンド変換又は他のタイプの変換も使用することができる。いずれの場合も、変換処理ユニット52は、変換を残差ブロックに適用し、残差変換係数のブロックを生成する。変換は、残差情報を画素値領域から、周波数領域などの変換領域に変換することができる。
変換処理ユニット52は、得られた変換係数を量子化ユニット54に送ることができる。量子化ユニット54は、変換係数を量子化してビットレートを更に低減する。量子化プロセスは、係数の一部又は全部に関連するビット深さを低減することができる。量子化の程度は、量子化パラメータを調整することによって修正することができる。幾つかの例では、量子化ユニット54は、次いで、量子化変換係数を含む行列の走査を実行することができる。代替として、エントロピー符号化ユニット56が走査を実行することができる。
量子化の後、エントロピー符号化ユニット56は、量子化変換係数をエントロピーコード化する。例えば、エントロピー符号化ユニット56は、コンテキスト適応型可変長コード化(CAVLC)、コンテキスト適応型二値算術コード化(CABAC)、シンタックスベースコンテキスト適応型二値算術コード化(SBAC)、確率間隔区分エントロピー(PIPE)コード化又は別のエントロピーコード化技法を実行することができる。コンテキストベースのエントロピーコード化の場合、コンテキストは近接ブロックに基づく場合がある。エントロピー符号化ユニット56によるエントロピーコード化の後、符号化ビットストリームは、別の機器(例えば、ビデオデコーダ30)に送信されるか、又は後で送信するかもしくは取り出すためにアーカイブすることができる。
逆量子化ユニット58及び逆変換処理ユニット60は、それぞれ逆量子化及び逆変換を適用して、例えば、参照ブロックとして後で使用するために、画素領域内の残差ブロックを復元する。動き補償ユニット44は、残差ブロックを参照ピクチャメモリ64のピクチャのうちの1つの予測ブロックに加算することによって、参照ブロックを計算することができる。動き補償ユニット44はまた、復元された残差ブロックに1つ又は複数の補間フィルタを適用して、動き推定において使用するサブ整数画素値を計算することができる。加算器62は、復元された残差ブロックを、動き補償ユニット44によって生成された動き補償予測ブロックに加算して、参照ピクチャメモリ64に記憶するための復元されたビデオブロックを生成する。復元されたビデオブロックは、後続ピクチャ内のブロックをインターコード化するために、動き/視差推定ユニット42及び動き補償ユニット44によって参照ブロックとして使用することができる。
ビデオエンコーダ20は、上述のように、幾つかのシンタックス要素を生成することができ、それらはエントロピー符号化ユニット56又はビデオエンコーダ20の別の符号化ユニットによって符号化することができる。幾つかの例では、ビデオエンコーダ20は、上述のように、MVCビットストリーム用のシンタックス要素を生成し符号化することができる。
上記のように、ビュー識別子はNALユニットヘッダ内に含まれて、NALユニットが属するビューを識別することができる。ビューIDは、NALユニットヘッダ用のビットの数を実質的に増加させる可能性があり、NALユニットヘッダはビットストリームの比較的大きな部分を占める。本開示の態様によれば、ビデオエンコーダ20は、NALユニットヘッダの一部としてビュー順序インデックスを通知することができる。即ち、ビデオエンコーダ20は、通常NALユニットヘッダ内に通知できるビューIDをビュー順序インデックスと置き換えることができる。ビュー順序インデックスは、アクセスユニットの対応するビューコンポーネントの復号順序を記述することができる。ビュー順序インデックスは、POC値又はフレーム値とともに使用されて、ビットストリームのビューコンポーネントを識別することができる。ビデオエンコーダ20はまた、ビュー用のビューIDとビュー用のビュー順序インデックスとの間の関係の指示を提供するSPSを生成することができる。例えば、ビデオエンコーダ20は、view_idの値をビュー順序インデックスの値にマッピングするマッピングテーブルを生成し、そのようなマッピングテーブルをSPS内に含めることができる。他の例では、ビデオエンコーダ20は、ビューIDとビュー順序インデックスとの間の関係を、代替の方式で示すことができる。
ビデオエンコーダ20はまた、通常、ベースビューの直前に含むことができるプレフィックスNALユニットの符号化を回避することができる。むしろ、ビデオエンコーダ20は、NALユニットヘッダ内のtemporal_idを通知することができ、temporal_idは、ビデオデコーダ30に必要な情報の全てを提供して、(例えば、0のデフォルトのベースビュー順序インデックスの場合)特定のビューコンポーネントを特定のビューと適切な時間位置とに関連付けることができる。幾つかの例では、ビデオエンコーダ20は、ベースビューのNALユニットヘッダにフラグを追加して、(その特定のNALユニットの)ビューコンポーネントがビットストリームの他のビューのビューコンポーネントをインター予測するために使用できるかどうかを示すことができる。
本開示の態様によれば、ビューコンポーネントがアンカーピクチャ用か又は非アンカーピクチャ用かにかかわらず、かつビューコンポーネントがリスト0に属するか又はリスト1に属するかにかかわらず、ビデオエンコーダ20は、通常全てのビューコンポーネントについて、ビューごとにビュー依存性を通知することができる。幾つかの例では、ビデオエンコーダ20は、アンカーピクチャ用と非アンカーピクチャ用とで異なるビュー依存性を識別する、SPS内の指示を含むことができる。
本開示の他の態様によれば、NALユニットヘッダ内のpriority_idを通知するのではなく、ビデオエンコーダ20はSPS内のpriority_id値を提供することができる。即ち、特定の時間レベルを有するビューごとのpriority_idは、シーケンスレベルで通知することができる。加えて、本開示の態様によれば、単一パスの適応は、その適応に関連する信号伝達コンテキストが知られている限り可能であり得る。加えて、ビデオエンコーダ20は、SPS内のビューレベル情報を通知することができる。
図3は、マルチビュービットストリームを復号するための、本開示に記載された技法を実施できる例示的なビデオデコーダ30を示すブロック図である。図3の例では、ビデオデコーダ30は、エントロピー復号ユニット80と、動き補償ユニット82及びイントラ予測ユニット84を有する予測ユニット81と、逆量子化ユニット86と、逆変換ユニット88と、加算器90と、参照ピクチャメモリ92とを含む。
復号プロセス中に、ビデオデコーダ30は、ビデオエンコーダ20から、符号化ビデオスライスのビデオブロックと関連するシンタックス要素とを表す符号化ビデオのビットストリームを受信する。ビデオデコーダ30のエントロピー復号ユニット80は、ビットストリームをエントロピー復号して、量子化係数と、動きベクトルと、他のシンタックス要素とを生成する。エントロピー復号ユニット80は、予測ユニット81に動きベクトルと他のシンタックス要素とを転送する。ビデオデコーダ30は、ビデオスライスレベル及び/又はビデオブロックレベルで、シンタックス要素を受信することができる。
例えば、ビデオデコーダ30は、NALユニットに記憶されたデータのタイプ(例えば、VCLデータ及び非VCLデータ)を識別するNALユニットヘッダを有するNALユニットの数を受信することができる。パラメータセットは、上述のSPS、PPS、又は他のパラメータセットなどのシーケンスレベルヘッダ情報を含んでいる場合がある。
本開示の態様によれば、ビデオデコーダ30は、NALユニットヘッダの一部としてビュー順序インデックスを受信することができる。即ち、ビデオデコーダ30は、通常NALユニットヘッダ内で通知できるビューIDではなく、ビュー順序インデックスを受信することができる。ビュー順序インデックスは、アクセスユニットの対応するビューコンポーネントの復号順序を記述することができる。加えて、ビデオデコーダ30は、受信されたビュー順序インデックスと対応するビューIDとの間の関係を示す情報を受信することができる。その情報は、例えば、view_idの値をビュー順序インデックスの値にマッピングするマッピングテーブルを含むことができる。このようにして、ビデオデコーダ30は、単にNALユニットヘッダ内のビュー順序インデックスの値を受信し、マッピングテーブルを使用してNALユニットのview_idを決定することができる。幾つかの例では、その関係情報はSPS内で受信することができる。ビデオデコーダ30はまた、POC値又はフレーム値(フレーム番号又はframe_num)とともにビュー順序インデックスを使用して、ビットストリームのビューコンポーネントを識別することができる。
幾つかの例では、本開示の態様によれば、ビデオデコーダ30は、通常ベースビューの直前に含むことができるプレフィックスNALユニットを受信することはできない。むしろ、ビデオデコーダ30は、NALユニットヘッダ内のtemporal_idを受信することができ、temporal_idは、ビデオデコーダ30に必要な情報の全てを提供して、(例えば、0のデフォルトのベースビュー順序インデックスの場合)特定のビューコンポーネントを特定のビューと適切な時間位置とに関連付けることができる。幾つかの例では、ビデオデコーダ30は、ベースビューのNALユニットヘッダ内のフラグを受信して、(その特定のNALユニットの)ビューコンポーネントがビットストリームの他のビューのビューコンポーネントをインター予測するために使用できるかどうかを示すことができる。
本開示の態様によれば、ビューコンポーネントがアンカーピクチャ用か又は非アンカーピクチャ用かにかかわらず、かつビューコンポーネントがリスト0に属するか又はリスト1に属するかにかかわらず、ビデオデコーダ30はまた、通常全てのビューコンポーネントについて、ビューごとにビュー依存性を受信することができる。幾つかの例では、ビデオデコーダ30は、アンカーピクチャ用と非アンカーピクチャ用とで異なるビュー依存性を識別するSPS内の指示を受信することができる。
本開示の他の態様によれば、NALユニットヘッダ内のpriority_idを通知するのではなく、ビデオエンコーダ20はSPS内のpriority_id値を提供することができる。加えて、本開示の態様によれば、単一パスの適応は、その適応に関連する信号伝達コンテキストが知られている限り可能であり得る。ビデオデコーダ30はまた、SPS内の特定のビューレベル情報を受信することができる。
ビデオスライスがイントラコード化(I)スライスとしてコード化されるとき、予測ユニット81のイントラ予測ユニット84は、通知されたイントラ予測モードと、現在ピクチャの、前に復号されたブロックからのデータとに基づいて、現在ビデオスライスのビデオブロック用の予測データを生成することができる。ピクチャがインターコード化された(即ちB、P又はGPB)スライスとしてコード化されるとき、予測ユニット81の動き補償ユニット82は、エントロピー復号ユニット80から受信された動きベクトルと他のシンタックス要素とに基づいて、現在ビデオスライスのビデオブロック用の予測ブロックを生成する。予測ブロックは、参照ピクチャリストのうちの1つの内部の参照ピクチャのうちの1つから生成することができる。ビデオデコーダ30は、参照ピクチャメモリ92に記憶された参照ピクチャに基づいて、デフォルトの構築技法を使用して、参照ピクチャリスト、リスト0及びリスト1(又は合成リスト、リストC)を構築することができる。
動き補償ユニット82は、動きベクトルと他のシンタックス要素とを解析することによって現在ビデオスライスのビデオブロック用の予測情報を決定し、その予測情報を使用して、復号されている現在ビデオブロック用の予測ブロックを生成する。例えば、動き補償ユニット82は、受信されたシンタックス要素の幾つかを使用して、ビデオスライスのビデオブロックをコード化するために使用される予測モード(例えば、イントラ予測又はインター予測)と、インター予測スライスタイプ(例えば、Bスライス、Pスライス、又はGPBスライス)と、スライス用の参照ピクチャリストのうちの1つ又は複数についての構築情報と、スライスの各インター符号化ビデオブロック用の動きベクトルと、スライスの各インターコード化ビデオブロック用のインター予測ステータスと、現在ビデオスライス内のビデオブロックを復号するための他の情報とを決定する。
逆量子化ユニット86は、ビットストリーム内で提供され、エントロピー復号ユニット80によって復号された量子化変換係数を逆量子化(inverse quantize)、即ち逆量子化(de-quantize)する。逆量子化プロセスは、ビデオスライス内のビデオブロックごとにビデオエンコーダ20によって計算される量子化パラメータを使用して量子化の程度を決定することと、同様に、適用すべき逆量子化の程度を決定することとを含むことができる。
逆変換処理ユニット88は、画素領域において残差ブロックを生成するために、逆変換、例えば、逆DCT、逆整数変換、又は概念的に同様の逆変換プロセスを変換係数に適用する。本開示の態様によれば、逆変換処理ユニット88は、変換が残差データに適用された方式を判断することができる。即ち、例えば、逆変換処理ユニット88は、受信されたビデオデータのブロックに関連する残差ルーマサンプルと残差クロマサンプルとに、変換(例えば、DCT、整数変換、ウェーブレット変換、又は1つ以上の他の変換)が適用された方式を表すRQTを判断することができる。
動き補償ユニット82が、動きベクトルと他のシンタックス要素とに基づいて現在ビデオブロック用の予測ブロックを生成した後、ビデオデコーダ30は、逆変換処理ユニット88からの残差ブロックを、動き補償ユニット82によって生成された対応する予測ブロックと加算することによって、復号されたビデオブロックを形成する。加算器90は、この加算演算を実行する1つ又は複数の構成要素を代表する。必要な場合、ブロッキネスアーティファクトを除去するために、デブロッキングフィルタも適用されて、復号されたブロックをフィルタ処理することができる。画素遷移を平滑化するか、又はさもなければビデオ品質を改善するために、(コード化ループ内又はコード化ループ後の)他のループフィルタも使用することができる。次いで、所与のピクチャ内の復号されたビデオブロックは、その後の動き補償に使用される参照ピクチャを記憶する参照ピクチャメモリ92に記憶される。参照ピクチャメモリ92はまた、図1の表示装置32などの表示装置上に後で提示するための、復号されたビデオを記憶する。
図4は、例示的なMVCの予測パターンを示す概念図である。図4の例では、8個のビューが示され、ビューごとに12個の時間位置が示される。一般に、図4内の各行はビューに対応し、各列は時間位置を示す。ビューの各々は、他のビューに対する相対的なカメラ位置を示すために使用できるビュー識別子(「view_id」)を使用して識別することができる。図4に示された例では、ビューIDは「S0」〜「S7」として示されているが、数字のビューIDも使用することができる。加えて、時間位置の各々は、ピクチャの表示順序を示すピクチャ順序カウント(POC)値を使用して識別することができる。図4に示された例では、POC値は「T0」〜「T11」として示されている。
MVCは、H.264/AVCデコーダによって復号可能である、所謂ベースビューを有し、ステレオビューペアはMVCによってサポートできるが、MVCは、3Dビデオ入力として3つ以上のビューをサポートすることができる。従って、MVCデコーダを有するクライアントのレンダラは、複数のビューを用いて3Dビデオコンテンツを予想することができる。
図4内のピクチャは、対応するピクチャがイントラコード化される(即ち、Iフレームである)か、又は一方向に(即ち、Pフレームとして)インターコード化されるか、又は複数の方向に(即ち、Bフレームとして)インターコード化されるかを指定する、文字を含む影付きブロックを使用して示される。一般に、予測は矢印によって示され、ここで矢印の終点のピクチャは、予測参照用に矢印の始点のオブジェクトを使用する。例えば、時間位置T0にあるビューS2のPフレームは、時間位置T0にあるビューS0のIフレームから予測される。図4に示されたピクチャの各々は、ビューコンポーネントと呼ばれる場合がある。即ち、ビューのビューコンポーネントは、ビューの特定の時間インスタンスに対応する。
シングルビュービデオ符号化の場合と同様に、マルチビュービデオシーケンスのピクチャは、異なる時間位置にあるピクチャに対して予測符号化することができる。例えば、時間位置T1にあるビューS0のbフレームは、時間位置T0にあるビューS0のIフレームからそのbフレームに向けられた矢印を有し、その矢印は、bフレームがIフレームから予測されることを示す。しかしながら、更に、マルチビュービデオ符号化のコンテキストにおいて、ピクチャはビュー間予測することができる。即ち、ビューコンポーネントは、参照用の他のビュー内のビューコンポーネントを使用することができる。MVCでは、例えば、別のビュー内のビューコンポーネントがインター予測参照であるかのように、ビュー間予測が実現される。潜在的なビュー間参照は、SPSのMVC拡張において通知することができ、インター予測参照又はビュー間予測参照のフレキシブルな順序付けを可能にする、参照ピクチャリストの構築プロセスによって修正することができる。
図4は、ビュー間予測の様々な例を提供する。図4の例では、ビューS1のピクチャは、ビューS1の異なる時間位置にあるピクチャから予測されるものとして、ならびに同じ時間位置にあるビューS0及びビューS2のピクチャのピクチャからビュー間予測されるものとして示されている。例えば、時間位置T1にあるビューS1のbフレームは、時間位置T0及びT2にあるビューS1のBフレームの各々、ならびに時間位置T1にあるビューS0及びビューS2のbフレームから予測される。
図4の例では、大文字「B」及び小文字「b」は、異なる符号化方法ではなく、ピクチャ間の異なる階層関係を示すものとする。一般に、大文字の「B」フレームは、小文字の「b」フレームよりも予測階層が比較的高い。図4はまた、異なるレベルの陰影を使用して予測階層における変形形態を示し、より大きい量の陰影の(即ち、比較的暗い)ピクチャは、より少ない陰影を有する(即ち、比較的明るい)ピクチャよりも予測階層が高い。例えば、図4内の全てのIフレームは完全陰影を用いて示されるが、Pフレームはいくぶん明るい陰影を有し、Bフレーム(及び小文字のbフレーム)は、互いに対して様々なレベルの陰影を有するが、Pフレーム及びIフレームの陰影よりも常に明るい。
一般に、階層が比較的高いピクチャが、階層が比較的低いピクチャの復号中に参照ピクチャとして使用できるように、予測階層が比較的高いピクチャは、階層が比較的低いピクチャを復号する前に復号されるべきであるという点で、予測階層はビュー順序インデックスに関係する。ビュー順序インデックスは、アクセスユニット内のビューコンポーネントの復号順序を示すインデックスである。ビュー順序インデックスは、SPSなどのパラメータセット内で暗示することができる。
このようにして、参照ピクチャとして使用されるピクチャは、その参照ピクチャを参照して符号化されたピクチャを復号する前に復号することができる。ビュー順序インデックスは、アクセスユニット内のビューコンポーネントの復号順序を示すインデックスである。MVC/AVCによれば、ビュー順序インデックスiごとに、対応するview_idが通知される。ビューコンポーネントの復号は、ビュー順序インデックスの昇順に従う。全てのビューが提示された場合、ビュー順序インデックスのセットは、0からビューの全数よりも1少ない数まで連続的に順序付けされたセットを備える。
幾つかの例では、全ビットストリームのサブセットが抽出されて、依然MVCに準拠するサブビットストリームを形成することができる。例えば、サーバによって提供されるサービス、1つ又は複数のクライアントのデコーダの容量、サポート、及び能力、及び/又は、1つ以上のクライアントの選好に基づいて、特定の適用例が必要とする場合がある、多くの可能なサブビットストリームが存在する。例えば、あるクライアントが3つのビューのみを必要とする場合があり、2つのシナリオがあり得る。一例では、あるクライアントは滑らかな観察エクスペリエンスを必要とし、view_id値S0、S1、及びS2のビューを選好することができ、別の他のクライアントはビュースケーラビリティを必要とし、view_id値S0、S2、及びS4のビューを選好することができる。これらのサブビットストリームの両方は、独立したMVCビットストリームとして復号することができ、同時にサポートすることができる。
一般に、カメラの場所、方向、及び、異なるビュー間の幾何学的関係は、ビューID又はビュー順序インデックスから推測することができる。この目的のために、内部と外部の両方のカメラパラメータは、マルチビュー収集情報SEIメッセージを使用するビットストリーム内に含むことできる。
上記のように、図4は8個のビュー(S0〜S7)を示すが、MVC/AVC拡張は1024個までのビューをサポートし、NALユニットヘッダ内のview_idを使用して、NALユニットが属するビューを識別する。本開示の態様によれば、ビュー順序インデックスは、NALユニットヘッダの一部として通知することができる。即ち、比較の目的で、ビュー順序インデックスは、MVC/AVC拡張のNALユニットヘッダ内で通知されるビューIDと置き換わることができる。ビュー順序は、一般に、アクセスユニット内のビューの順序付けを記述し、ビュー順序インデックスは、そのアクセスユニットのビュー順序における特定のビューを識別する。即ち、ビュー順序インデックスは、アクセスユニットの対応するビューコンポーネントの復号順序を記述する。
従って、本開示の態様によれば、SPSは、ビュー用のview_idとビュー用のビュー順序インデックスとの間の関係を提供することができる。ビュー順序インデックスとSPS内のデータとを使用して、ビデオエンコーダ20及びビデオデコーダ30は、NALユニットヘッダ内のMVC/AVCの10ビットのview_idをビュー順序インデックスによって置き換えることができ、このことはMVC/AVC方式上でビット節約につながる可能性がある。
ビュー用のview_idとビュー順序インデックスとの間の関係を提供するSPSの一例が、下記の表6に提供される。
表6に示された例では、太字で斜体のシンタックス要素は、MVC/AVCのSPSシンタックスからの逸脱、即ち、MVC/AVCのSPSシンタックスに対する修正を示す。例えば、表6に示されたSPSは、コード化ビデオシーケンス用のビュー間依存関係を指定する。SPSはまた、コード化ビデオシーケンス用の動作点のサブセット用のレベル値を指定する。コード化ビデオシーケンスによって参照される全てのSPSは、同一であるべきである。しかしながら、view_id[i]によって識別される幾つかのビューは、コード化ビデオシーケンス内に存在しない場合がある。加えて、SPSによって記述される幾つかのビュー又は時間サブセットは、元のコード化ビデオシーケンスから削除されている場合があり、従って、コード化ビデオシーケンス内に存在しない場合がある。しかしながら、SPS内の情報は、残りのビューと時間サブセットとに常に適用される可能性がある。
上記の表6では、num_views_minus1プラス1の要素は、コード化ビデオシーケンス内のコード化ビューの最大数を指定することができる。num_view_minus1の値は、両端値を含む0〜31の範囲内であり得る。幾つかの例では、コード化ビデオシーケンス内のビューの実際の数は、num_views_minus1プラス1よりも少ない場合がある。view_id[i]要素は、iに等しいビュー順序インデックスを有するビューのビュー識別子を指定することができる。view_level[i]要素は、iに等しいビュー順序インデックスを有するビューのview_levelを指定することができる。幾つかの例では、予め定義された値(VL)までのview_levelを有する全てのビューコンポーネントは、VLよりも大きいview_levelを有するいかなるビューコンポーネントも復号せずに、復号できる可能性がある。
本開示の態様によれば、num_ref_views[i]要素は、iに等しいビュー順序インデックスを有するビューコンポーネントを復号するとき、初期の参照ピクチャリストRefPicList0及びRefPicList1内のビュー間予測用のビューコンポーネントの数を指定することができる。num_ref_views[i]要素の値は、Min(15,num_views_minus1)よりも大きくない可能性がある。num_ref_views[0]の値は、0に等しい場合がある。加えて、本開示の態様によれば、ref_view_idx[i][j]要素は、iに等しいビュー順序インデックスを有するビューコンポーネントを復号するとき、初期の参照ピクチャリストRefPicList0及びRefPicList1内のビュー間予測用の第jのビューコンポーネントのビュー順序インデックスを指定することができる。ref_view_idx[i][j]の値は、両端値を含む0〜31の範囲内であり得る。
従って、本開示の様々な態様では、アンカーピクチャ用のビュー依存性と非アンカーピクチャ用のビュー依存性は、もはや別々に維持及び通知する必要はない可能性がある。即ち、ビデオエンコーダ20及び/又はビデオエンコーダ30は、アンカーピクチャ用、及び同様の非アンカーピクチャ用に、単一の参照ピクチャリストを使用(又は、2つの参照ピクチャリスト、リスト0とリスト1とを維持)することができる。このようにして、上記の表6に示されたように、ビデオデコーダ30にビュー依存性を示すために別の信号伝達は必要とされない。むしろ、SPSは、ビューコンポーネント用にリスト0とリスト1の両方を構築するために使用できるref_view_idxを含む。
本開示のそのような態様によれば、例えば、ビデオデコーダ30は、第1のビューの任意のビューコンポーネントについて、第1のビューのビューコンポーネントを予測するための1つ又は複数の参照ビューを示す参照ビュー情報を受信することができる。即ち、ビデオデコーダ30は、ビューのアンカーピクチャ用及び同様のビューの非アンカーピクチャ用のビュー依存性を示す参照ビュー情報を受信することができる。特定のビューの(アクセスユニットの)特定のピクチャを復号するとき、次いで、ビデオデコーダ30は、特定のピクチャと同じアクセスユニットからの、及び参照ビュー情報によって示された参照ビューからの参照候補(例えば、特定のピクチャがそれから予測できるビューコンポーネント)を含むことができる。幾つかの例では、ビデオデコーダ30は、参照候補の数が参照ビューの数と等しくなるように、各参照ビューから参照ピクチャリストに参照候補を追加することができる。加えて、ビデオデコーダ30は、リスト1、リスト0、又は両方のいずれかに参照候補を追加することができる。次いで、ビデオデコーダ30は、参照ピクチャリスト内の参照ピクチャのうちの1つに基づいて、特定のピクチャを復号することができる。
更に、表6によれば、非アンカービューコンポーネント用のビュー間依存性は、もはやアンカービューコンポーネント用のビュー間依存性のサブセットとしてSPS内に通知することはできない。むしろ、アンカービューのビューコンポーネントは、ビュー3及びビュー4などの2つ以上の他のビューから予測することができ、非アンカービューも、ビュー3及びビュー4のピクチャから予測することができる。更なる制限ビュー依存性制限が非アンカーピクチャに必要である場合、そのような制限は、SEIメッセージなどの補足信号伝達で提供することができる。
num_level_values_signalled_minus1プラス1要素は、コード化ビデオシーケンスに通知されたレベル値の数を指定することができる。num_level_values_signalled_minus1の値は、両端値を含む0〜63の範囲内であり得る。level_idc[i]要素は、コード化ビデオシーケンスに通知された第iのレベル値を指定することができる。num_applicable_ops_minus[i]プラス1要素は、level_idc[i]によって示されたレベルが適用される動作点の数を指定することができる。num_applicable_ops_minus[i]要素の値は、両端値を含む0〜1023の範囲内であり得る。applicable_op_temporal_id[i][j]要素は、level_idc[i]によって示されたレベルが適用される第jの動作点のtemporal_idを指定することができる。applicable_op_num_target_views_minus1[i][j]プラス1要素は、level_idc[i]によって示されたレベルが適用される第jの動作点用のターゲット出力ビューの数を指定することができる。applicable_op_num_target_views_minus1[i][j]要素の値は、両端値を含む0〜1023の範囲内であり得る。
applicable_op_target_view_idx[i][j][k]要素は、level_idc[i]によって示されたレベルが適用される第jの動作点用の第kのターゲット出力ビューのビュー順序インデックスを指定することができる。applicable_op_target_view_idx[i][j][k]要素の値は、両端値を含む0〜31の範囲内であり得る。applicable_op_num_views_minus1[i][j]プラス1は、level_idc[i]によって示されたレベルが適用される第jの動作点に対応するターゲット出力ビューを復号するために必要なビューの数を指定することができる。applicable_op_num_views_minus1によって指定されたビューの数は、サブビットストリーム抽出プロセスによって指定されたように、ターゲット出力ビューとターゲット出力ビューが依存するビューとを含むことができる。
別の例では、本開示の態様によれば、ref_view_idx[i][j]の値は、同じ時間インスタンス内のビューコンポーネントの復号順序に基づいて、iよりも小さくなることが必要とされる可能性がある。
ref_view_idx[i][j]は、(MVC/AVCに対して更なるビット節約のために)サイズを更に縮小することができる。例えば、更なるビット節約は、2つだけのビューを含む(即ち、ステレオビデオ用の)MVCストリーム内で実現することができる。この例では、ビデオデコーダ30が常に第2のビュー(例えば、ビュー1)を復号する前に第1のビュー(例えば、ビュー0)を復号できるので、ビュー順序インデックスは必要とされない可能性がある。例示的な縮小されたSPSが下記の表7に提供される。
表7に示された例では、ref_view_idx_diff_minus1[i][j]プラスi+1要素は、iに等しいビュー順序インデックスを有するビューコンポーネントを復号するとき、初期の参照ピクチャリストRefPicList0及びRefPicList1内のビュー間予測用の第jのビューコンポーネントのビュー順序インデックスを指定することができる。ref_view_idx_diff_minus1[i][j]要素の値は、両端値を含む0〜30−iの範囲内であり得る。
他の例も可能である。例えば、(上記の表6及び表7に示された例のように)SPS内にビュー依存性を通知するのではなく、ビュー依存性はPPS内に通知することができる。別の例では、ビュー依存性はSPS内に通知することができ、ビュー依存性は、更に、シーケンスパラメータセット内に通知されるビュー依存性の範囲内であるPPS内に通知することができる。例えば、SPSでは、依存ビュー(例えば、ビュー2)がビュー0とビュー1とに依存していると通知することができ、PPSでは、依存ビュー(例えば、ビュー2)がビュー0のみに依存していると通知することができる。
本開示の幾つかの態様によれば、参照ピクチャリストの構築及び並べ替えは、MVC/AVCから変更することができる。例えば、本開示の態様によれば、上述のビューインデックス(view_idx)は、参照ピクチャリストの構築及び/又は並べ替えの間使用することができる。例示的な参照ピクチャリストのMVC修正シンタックスが、下記の表8と表9とに提供される。
表8及び表9では、abs_diff_pic_num_minus1、long_term_pic_num、又はabs_diff_view_idx_minus1とともにmodification_of_pic_nums_idc要素は、参照ピクチャ又はビュー間専用参照コンポーネントのうちのどれが再マッピングされるかを指定することができる。例えば、abs_diff_view_idx_minus1プラス1要素は、参照ピクチャリスト内の現在インデックスに入れるべきビュー間参照インデックスと、ビュー間参照インデックスの予測値との間の絶対差を指定することができる。
別の例では、本開示の態様によれば、ビュー間参照のinter_view_indexは、直接通知することができる。そのような参照ピクチャリストのMVC修正シンタックスが、下記の表10と表11とに提供される。
表10及び表11では、ビュー間参照ピクチャは、次のようにinter_view_indexによって識別することができる。
ここで、CurrVOIdxは現在のビューコンポーネントのビュー順序インデックスである。現在ピクチャのPOC値が与えられると、POC及びVOIdxは、ビュー間参照ピクチャを識別するために使用することができる。
幾つかの例では、参照ピクチャリスト構築用のMVC復号プロセスは、Pスライス、SPスライス又はBスライスごとの復号プロセスの開始時に起動することができる。このプロセスの起動中、現在スライスと同じ値のview_idxを有する参照ピクチャのみを考慮することができる。復号された参照ピクチャは、「短期参照用に使用される」又は「長期参照用に使用される」とマークすることができる。短期参照ピクチャは、frame_num及びview_idxの値によって識別することができ、ビュー間参照ピクチャの場合、更にPicOrderCnt()によって識別することができる。長期参照ピクチャは長期フレームインデックスを割り当てられ、長期フレームインデックス、view_idxの値によって識別することができ、ビュー間参照ピクチャの場合、更にPicOrderCnt()によって識別することができる。
参照ピクチャに加えて、(非参照ピクチャであり、参照ピクチャマーキングプロセスの間マークされる可能性がない)ビュー間専用参照コンポーネントも、参照ピクチャリストに含むことができる。ビュー間専用参照コンポーネントは、view_idxの値及びPicOrderCnt()によって識別することができる。
参照ピクチャリスト構築プロセスの起動中、節8.2.4.1としてMVC/AVC内で識別される以下のプロセスは、
・短期参照ピクチャの各々への変数FrameNum、FrameNumWarp、及びPicNumの割り当てと、
・長期参照ピクチャの各々への変数LongTermPicNumの割り当てと
を指定するように起動することができる。
参照ピクチャ、及び、存在するときビュー間専用参照コンポーネントは、参照インデックスを介してアドレス指定される。参照インデックスは参照ピクチャリストへのインデックスである。Pスライス又はSPスライスを復号するとき、単一の参照ピクチャリストRefPicList0が存在する。Bスライスを復号するとき、RefPicList0に加えて、第2の独立した参照ピクチャリストRefPicList1が存在する。
スライスごとの復号プロセスの開始時に、参照ピクチャリストRefPicList0、及びBスライスの場合RefPicList1は、以下の順序付けされたステップによって指定されたように導出することができる。
1.MVC/AVCの節8.2.4.2で指定されたように、初期の参照ピクチャリストRefPicList0、及びBスライスの場合RefPicList1が導出される。
2.(下記の)節6.4.1で指定されたように、ビュー間参照ピクチャ又はビュー間専用参照コンポーネントが、初期の参照ピクチャリストRefPicList0、及びBスライスの場合RefPicList1に追加される。
3.(下記の)節6.4.2で指定されたように、ref_pic_list_modification_flag_l0が1に等しいとき、又はBスライスを復号時ref_pic_list_modification_flag_l1が1に等しいとき、参照ピクチャリストRefPicList0、及びBスライスの場合RefPicList1が修正される。
加えて、修正された参照ピクチャリストRefPicList0内の項目の数は、num_ref_idx_l0_active_minus1+1であり、Bスライスの場合、修正された参照ピクチャリストRefPicList1内の項目の数は、num_ref_idx_l1_active_minus1+1である。参照ピクチャ又はビュー間専用参照コンポーネントは、修正された参照ピクチャリストRefPicList0又はRefPicList1内の2つ以上のインデックスで表示することができる。
節6.4.1で指定されたプロセスの起動中、RefPicListX(Xは0又は1である)に追加されるビュー間予測参照は存在しない可能性がある。しかしながら、存在しないビュー間予測参照は、(下記の)節6.4.2で指定されたプロセスの起動後、修正されたRefPicListX内にない可能性がある。
一例では、ビュー間予測参照用の参照ピクチャリストについての初期化プロセスを含む節6.4.1が下記で説明される。
・このプロセスへの入力は、参照ピクチャリストRefPicListX(Xは0又は1である)、inter_view_flag、及び、seq_parameter_set_mvc_extension()から復号されたビュー依存性情報である。
・このプロセスの出力は、場合によっては修正された参照ピクチャリストRefPicListXであり、これはやはり初期の参照ピクチャリストRefPicListXと呼ばれる。
・iが現在スライス用のview_idxの値である場合、ビュー間参照ピクチャ及びビュー間専用参照コンポーネントは、下記に指定されたように参照ピクチャリストに追加される。
・両端値を含む0からnum_ref_views[i]−1までのビュー間参照インデックスjの値ごとに、jの昇順で、現在スライスと同じアクセスユニットからのref_view_idx[i][j]に等しいview_idxを有するビュー間予測参照が、RefPicListXに追加される。
一例では、参照ピクチャリストについての修正プロセスを含む節6.4.2が下記で説明される。
・このプロセスへの入力は、参照ピクチャリストRefPicList0であり、Bスライスを復号するときは、参照ピクチャリストRefPicList1でもある。
・このプロセスの出力は、場合によっては修正された参照ピクチャリストRefPicList0であり、Bスライスを復号するときは、場合によっては修正された参照ピクチャリストRefPicList1でもある。
・ref_pic_list_modification_flag_l0が1に等しいとき、以下の順序付けられたステップが指定される。
1.refIdxL0を参照ピクチャリストRefPicList0へのインデックスとする。refIdxL0が、最初に0に等しいように設定される。
2.対応するシンタックス要素modification_of_pic_nums_idcが、ビットストリーム内で発生する順序で処理される。これらのシンタックス要素の各々について、以下が適用される。
・modification_of_pic_nums_idcが0又は1に等しい場合、(下記の)節6.4.2.1で指定されたプロセスが、入力としてRefPicList0とrefIdxL0とを与えられて起動され、出力がRefPicList0とrefIdxL0とに割り当てられる。
・そうではなく、modification_of_pic_nums_idcが2に等しい場合、(下記の)節6.4.2.2で指定されたプロセスが、入力としてRefPicList0とrefIdxL0とを与えられて起動され、出力がRefPicList0とrefIdxL0とに割り当てられる。
・そうではなく、modification_of_pic_nums_idcが4又は5に等しい場合、(下記の)節6.4.2.3で指定されたプロセスが、入力としてRefPicList0とrefIdxL0とを与えられて起動され、出力がRefPicList0とrefIdxL0とに割り当てられる。
・そうではない(modification_of_pic_nums_idcが3に等しい)場合、参照ピクチャリストRefPicList0についての修正プロセスが終了する。
・ref_pic_list_modification_flag_l1が1に等しいとき、以下の順序付けられたステップが指定される。
1.refIdxL1を参照ピクチャリストRefPicList1へのインデックスとする。refIdxL1が、最初に0に等しいように設定される。
2.対応するシンタックス要素modification_of_pic_nums_idcが、ビットストリーム内で発生する順序で処理される。これらのシンタックス要素の各々について、以下が適用される。
・modification_of_pic_nums_idcが0又は1に等しい場合、(下記の)節6.4.2.1で指定されたプロセスが、入力としてRefPicList1とrefIdxL1とを与えられて起動され、出力がRefPicList1とrefIdxL1とに割り当てられる。
・そうではなく、modification_of_pic_nums_idcが2に等しい場合、(下記の)節6.4.2.2で指定されたプロセスが、入力としてRefPicList1とrefIdxL1とを与えられて起動され、出力がRefPicList1とrefIdxL1とに割り当てられる。
・そうではなく、modification_of_pic_nums_idcが4又は5に等しい場合、(下記の)節6.4.2.3で指定されたプロセスが、入力としてRefPicList1とrefIdxL1とを与えられて起動され、出力がRefPicList1とrefIdxL1とに割り当てられる。
・そうではない(modification_of_pic_nums_idcが3に等しい)場合、参照ピクチャリストRefPicList1についての修正プロセスが終了する。
一例では、インター予測用の短期参照ピクチャ用の参照ピクチャリストの修正プロセスを含む節6.4.2.1が下記で説明される。
・このプロセスへの入力は、インデックスrefIdxLX及び参照ピクチャリストRefPicListX(Xは0又は1である)である。
・このプロセスの出力は、増分されたインデックスrefIdxLX、及び修正された参照ピクチャリストRefPicListXである。
・変数picNumLXNoWrapが次のように導出される。
・modification_of_pic_nums_idcが0に等しい場合、
・そうではない(modification_of_pic_nums_idcが1に等しい)場合、
ここで、picNumLXPredは変数picNumLXNoWrap用の予測値である。この節で指定されたプロセスがスライス用に最初に起動されたとき(即ち、modification_of_pic_nums_idcがref_pic_list_modification()シンタックス内で0又は1に等しいことが最初に発生した場合)、picNumL0Pred及びpicNumL1Predは、最初にCurrPicNumに等しいように設定される。picNumLXNoWrapの各割り当て後、picNumLXNoWrapの値はpicNumLXPredに割り当てられる。
幾つかの例では、変数picNumLXは、以下の擬似コードによって指定されたように導出される。
ここで、picNumLXは、「短期参照用に使用される」とマークされた参照ピクチャのPicNumに等しい場合があり、「存在しない」とマークされた短期参照ピクチャのPicNumに等しくない場合がある。短期ピクチャ数picNumLXを有するピクチャをインデックス位置refIdxLXに配置し、他の任意の残りのピクチャの位置をリスト内の後のほうにシフトし、refIdxLXの値を増分するために、以下のプロセスを行うことができる。
ここで、関数viewIDX(refpic)は参照ピクチャrefpicのview_idxを返し、変数currViewIDXは現在スライスのview_idxに等しく、関数PicNumF(RefPicListX[cIdx])は次のように導出される。
・参照ピクチャRefPicListX[cIdx]が「短期参照用に使用される」とマークされる場合、PicNumF(RefPicListX[cIdx])はピクチャRefPicListX[cIdx]のPicNumである。
・そうでない(参照ピクチャRefPicListX[cIdx]が「短期参照用に使用される」とマークされない)場合、PicNumF(RefPicListX[cIdx])はMaxPicNumに等しい。
一例では、インター予測用の長期参照ピクチャ用の参照ピクチャリストの修正プロセスを含む節6.4.2.2が下記で説明される。
・このプロセスへの入力は、インデックスrefIdxLX(Xは0又は1である)及び参照ピクチャリストRefPicListXである。
・このプロセスの出力は、増分されたインデックスrefIdxLX、及び修正された参照ピクチャリストRefPicListXである。
・長期ピクチャ数long_term_pic_numを有するピクチャをインデックス位置refIdxLXに配置し、他の任意の残りのピクチャの位置をリスト内の後のほうにシフトし、refIdxLXの値を増分するために、以下の手順が行われる。
ここで、関数viewIDX(refpic)は参照ピクチャrefpicのview_idxを返し、変数currViewIDXは現在スライスのview_idxに等しく、関数LongTermPicNumF(RefPicListX[cIdx])は次のように導出することができる。
・参照ピクチャRefPicListX[cIdx]が「長期参照用に使用される」とマークされる場合、LongTermPicNumF(RefPicListX[cIdx])はピクチャRefPicListX[cIdx]のLongTermPicNumである。
・そうでない(参照ピクチャRefPicListX[cIdx]が「長期参照用に使用される」とマークされない)場合、LongTermPicNumF(RefPicListX[cIdx])は2*(MaxLongTermFlameIdx+1)に等しい。
一例では、ビュー間予測参照用の参照ピクチャリストの修正プロセスを含む節6.4.2.3が下記で説明される。
・このプロセスへの入力は、参照ピクチャリストRefPicListX(Xは0又は1である)及びこのリストへのインデックスrefIdxLXである。
・このプロセスの出力は、修正された参照ピクチャリストRefPicListX(Xは0又は1である)及び増分されたインデックスrefIdxLXである。
・currVOIdxを現在スライスの変数VOIdxとする。変数maxViewIdxはnum_ref_views[currVOIdx]に等しいように設定される。
・変数picInterViewIdxLXが次のように導出される。
・modification_of_pic_nums_idcが4に等しい場合、
ここで、picInterViewIdxLXPredは変数picInterViewIdxLX用の予測値である。この節で指定されたプロセスがスライスのRefPicList0又はRefPicList1用に最初に起動されたとき(即ち、modification_of_pic_nums_idcがref_pic_list_modification()シンタックス内で4又は5に等しいことが最初に発生した場合)、picInterViewIdxL0Pred及びpicInterViewIdxL1Predは、最初に−1に等しいように設定される。picInterViewIdxLXの各割り当て後、picInterViewIdxLXの値はpicInterViewIdxLXPredに割り当てられる。
ビットストリームは、picInterViewIdxLXが0以下であるか、又はpicInterViewIdxLXがmaxViewIdxよりも大きい結果になるデータを含んでいない場合がある。変数targetViewIDXは次のように導出することができる。
picInterViewIdxLXに等しいビュー間参照インデックスを有するビュー間予測参照をインデックス位置refIdxLXに配置し、他の任意の残りのピクチャの位置をリスト内の後のほうにシフトするために、以下の手順を行うことができる。
ここで、関数viewIDX(refpic)は参照ピクチャrefpicのview_idxを返し、変数currViewIDXは現在スライスのview_idxに等しく、変数currPOCは現在スライスのPicOrderCnt()に等しい。
幾つかの例では、参照ピクチャリストを合成するデフォルトのプロセスを使用することができる。例えば、デフォルトの参照ピクチャリスト合成プロセスは、参照ピクチャ(RefPicList0又はRefPicList1のいずれかから)が、合成されたリストに追加されている参照ピクチャの最初の発生であるかどうかを検査することを含むことができる。そのような検査を実行するために、(ビデオエンコーダ20又はビデオデコーダ30などの)ビデオコーダは、現在ピクチャCurrPicと、ビュー間参照ピクチャと時間参照ピクチャとを含むリスト内の任意のピクチャPicAとを比較することができる。比較は次のように行うことができる。
図5Aは、本開示の技法のうちの1つ又は複数の一実施形態において使用できるビットストリーム構造100の一例を示す概念図である。ビットストリーム100は、HEVC規格などのビデオコード化規格に準拠することができる。更に、幾つかの例では、ビットストリーム100はビデオコード化規格に対するMVC拡張に準拠することができる。
図5Aに示された例では、ビットストリーム100は複数のアクセスユニット102−1〜102−N(総称してアクセスユニット102)を含む。上記のように、アクセスユニット102は、ビュー104−1〜104−M(総称してビュー104)などの(ビューと呼ばれる)一組のビューコンポーネントを含むことができる。一般に、アクセスユニット102は、共通の時間インスタンス用の全てのデータ、例えば、ビューごとに1つのビューコンポーネント用のデータを含む。幾つかの例では、アクセスユニット102の各アクセスユニットは、同じ数のビュー104を含む。アクセスユニット102の各アクセスユニットを復号すると、ビューごとに1つの復号ピクチャをもたらすことができる。アクセスユニット102は、3次元ビデオ再生をレンダリングするために使用できる符号化ビデオデータを含んでいる場合がある。
図5Bは、図5Aのビットストリーム100の構造に含むことができるビュー104−Nの一例を示す概念図である。一般に、(アクセスユニット102−N内のビュー104などの)アクセスユニット内の各ビューコンポーネントは、一組のビデオエンコーダ/デコーダ(コーデック)レイヤ(VCL)NALユニットを含んでいる。即ち、図5Bに示された例では、ビュー104−Nは、固有の形態及び順序でNALユニット106−1〜106−3を含む。通常、ビューコンポーネントは、各アクセスユニットにおける第kのビューコンポーネントが同じビューに対応するように、各アクセスユニットにおいて同じ順序で配置される。他の例では、ビュー104−Nは、他の数のNALユニットを含む場合がある。
図5Cは、図5Bに示されたNALユニット106と同様な構造であり得る、例示的なNALユニット108を示す概念図である。NALユニット108は、一般に、NALユニットヘッダ110とペイロード112とを含む。加えて、NALユニットヘッダ110は、第1の部分114と、MVC/AVC拡張に準拠できるNALユニットヘッダ拡張部116とを含む。
例えば、第1の部分114は、ref_idc要素とNALユニットタイプ要素とを含む。ref_idc要素は、NALユニットが他のNALユニット用の参照として使用されるかどうかを示すことができる。例えば、00のref_idc値は、NALUのコンテンツが(将来の参照用に使用できる)記憶されたピクチャを復元するために使用されないことを示すことができる。そのようなNALUは、参照ピクチャの統合を危険にさらさずに廃棄することができる。00を超える値は、NALUの復号が参照ピクチャの統合を維持するために必要であることを示すことができる。NALユニットタイプ要素は、NALユニット108のパケットのタイプを示すことができる。
NALユニットヘッダ拡張部116は、一般に、IDRフラグ(IDR)と、優先度ID(priority_id)と、ビューID(view_id)と、時間ID(temporal_id)と、アンカーピクチャフラグ(APF)と、ビュー間フラグ(IVF)とを含む。上記の図1に関して記載されたように、IDRフラグは、NALユニット108が瞬時復号リフレッシュ(IDR)ピクチャに属するか、又は閉GOPランダムアクセスポイントとして使用できるビューIDR(V−IDR)ピクチャに属するかを示すことができる。priority_idは、変化するネットワーク状態ならびに/又は(例えば、単一パス適応プロセスなどの)ビデオデコーダ30及び/もしくは表示装置32の能力に応じてビットストリームを変更する、ビットストリーム適応プロセスで使用することができる。view_idは、NALユニットが属するビューのビュー識別子を示すために使用することができる。temporal_idは、特定のフレームレートに対応できる、現在のNALユニットの時間レベルを指示するために使用することができる。APFは、NALユニットが開GOPランダムアクセスポイントとして使用できるアンカーピクチャに属するかどうかを示すために使用することができる。IVFは、NALユニットが他のビュー内のNALユニット用のビュー間予測に使用されるかどうかを示すために使用することができる。
上記で説明されたように、MVC/AVCのview_idは10ビット長であり、1000個を超える異なるビューを一意に識別するために使用することができる。しかしながら、一般に、実際に符号化されるビューの数は、通常、1000ビューよりも幾つかの桁数少ない。例えば、図4は所与のMVCマルチメディアコンテンツ用の8個のビューを含む。NALユニットヘッダ110は全てのNALユニットに含まれるので、view_idはかなりの量のビットストリームを消費する可能性がある。図5Dに示された例に関して記載された本開示の態様は、NALユニットヘッダからview_idを除去することができ、それにより、MVCビデオデータをコード化するのに必要なビットの数を低減する。
図5Dは、図5Bに示されたNALユニット106と同様な構造であり得る、例示的なNALユニット120を示す概念図である。図5Dに示された例は、本開示の態様による例示的なNALユニットを示す。例えば、NALユニット120は、NALユニットヘッダ122とペイロード124とを含む。加えて、NALユニットヘッダは、第1の部分126とNALユニットヘッダ拡張部128とを含む。
図5Cに示された例と同様に、第1の部分126は、ref_idc要素とNALユニットタイプ要素とを含む。ref_idc要素は、NALユニットが他のNALユニット用の参照として使用されるかどうかを示すことができる。NALユニットタイプ要素は、NALユニット120のパケットのタイプを示すことができる。
しかしながら、図5Dの例で示されたように、NALユニットヘッダ拡張部128にview_idを含むのではなく、ビュー順序インデックスがNALユニットヘッダ122の一部として通知される。即ち、本開示の態様によれば、NALユニットヘッダ122のビュー順序インデックスは、NALユニットヘッダ110(図5C)に通知されるview_idと置き換わることができる。上記のように、ビュー順序は、一般に、アクセスユニット102(図5A)のうちの1つなどのアクセスユニット内のビューの順序付けを記述する。ビュー順序インデックスは、アクセスユニットのビュー順序において、ビュー104のうちの1つなどの特定のビューを示すことができる。即ち、ビュー順序インデックスは、アクセスユニットの対応するビューコンポーネントの復号順序を記述することができる。
拡張部128用の例示的なNALユニットヘッダのシンタックステーブルが、下記の表12で提供される。
図13に示された例では、0に等しいnon_idr_flagは、現在のアクセスユニットがIDRアクセスユニットであることを示すことができる。non_idr_flagの値は、アクセスユニットの全てのVCLのNALユニットについて同じであり得る。幾つかの例では、non_idr_flagは、5に等しいnal_unit_typeを有するベースビューのNALユニットの場合、0であると推論することができる。加えて、non_idr_flagは、1に等しいnal_unit_typeを有するベースビューのNALユニットの場合、1であると推論することができる。non_idr_flagが存在するNALユニットの場合、変数IdrPicFlagは、non_idr_flagが0に等しいときそのフラグを1に等しいように設定すること、及びnon_idr_flagが1に等しいときそのフラグを0に等しいように設定することによって、修正することができる。
加えて、1に等しいanchor_pic_flagは、現在のアクセスユニットがアンカーアクセスユニットであることを指定することができる。幾つかの例では、anchor_pic_flagは、1に等しいnal_unit_typeを有するベースビューのNALユニットの場合、0に等しいと推論することができ、4(クリーン復号リフレッシュ)に等しいnal_unit_typeを有するベースビューのNALユニットの場合、1であると推論することができる。
view_idxは、NALユニット用のビュー順序インデックスを指定することができる。一般に、同じ値のview_idxを有するNALユニットは同じビューに属する。20に等しいNALユニットタイプは、ベースビュー内にないビューコンポーネント用のNALユニットタイプを示すために使用することができる。
図5Cに示された例とは対照的に、表12の例に示されたように、priority_id、temporal_id、及びinter_view_flagは削除され、view_idはview_idxによって置き換えられている。幾つかの例では、下記の表13の例示的なNALユニットヘッダで示されたように、inter_view_flagは拡張部128から移動することができる。
表13に示された例では、0に等しいinter_view_flag要素は、現在のビューコンポーネントが現在のアクセスユニット内の任意の他のビューコンポーネントによるビュー間予測に使用されないことを示すことができる。1に等しいinter_view_flagは、現在のビューコンポーネントが現在のアクセスユニット内の他のビューコンポーネントによるビュー間予測に使用できることを示すことができる。inter_view_flagの値は、ビューコンポーネントの全てのVCLのNALユニットについて同じであり得る。
加えて、表13に示された例では、nal_unit_typeが1又は5に等しいとき、ビュー順序インデックスは0であると推論することができ、このビューコンポーネントのview_idはview_id[0]である。そのような例では、NALユニットヘッダ拡張部は必要とされない可能性がある。即ち、2つだけのビュー(即ち、ステレオビデオ用)を含むMVCストリームでは、(ビデオデコーダ30などの)デコーダが、常に第2のビュー(例えば、ビュー1)を復号する前に第1のビュー(例えば、ビュー0)を復号するので、ビュー順序インデックスは必要とされない可能性がある。
幾つかの例では、プレフィックスNALユニットは、もはやベースビュー(例えば、ビュー0)に必要とされない可能性がある。例えば、ビュー順序インデックスがベースビューについて常に0であり、ベースビューの時間位置がtemporal_idを使用して決定することができるので、ベースビュー用のプレフィックスNALユニットはもはや必要とされない可能性がある。従って、NALユニットヘッダ内のtemporal_idは、必要な情報の全てを提供して、特定のビューコンポーネントを特定のビューと適切な時間位置とに関連付ける。
表14は、NALユニットヘッダ拡張部を参照する別のNALユニットヘッダを含む。
表14に示された例では、0に等しいinter_view_flagは、現在のビューコンポーネントが現在のアクセスユニット内の任意の他のビューコンポーネントによるビュー間予測に使用されないことを示すことができる。1に等しいinter_view_flagは、現在のビューコンポーネントが現在のアクセスユニット内の他のビューコンポーネントによるビュー間予測に使用できることを示すことができる。inter_view_flagの値は、ビューコンポーネントの全てのVCLのNALユニットについて同じであり得る。加えて、nal_unit_header_mvc_extensionは、上記の表12で示された拡張部などの拡張部を参照する。
本開示の他の態様によれば、MVCビットストリーム用のNALユニットヘッダは、下記の表15に従って設計することができる。
表15に示された例では、NALユニットヘッダの形成は、例えば、nal_unit_typeに依存する場合がある。即ち、例えば、nal_unit_typeが20及びMVCのNALユニットに等しいとき、NALユニットは、上述のnon_idr_flagと、anchor_pic_flagと、view_idxとを含むことができる。従って、ステレオプロファイルの場合、NALユニットヘッダは、下記の表16に従って設計することができる。
更に別の例では、本開示の他の態様によれば、MVCビットストリーム用のNALユニットヘッダは、下記の表17に従って設計することができる。
図4に関して上述されたNALユニットヘッダの特定の構成にかかわらず、シーケンスパラメータセット(SPS)は、ビュー用のview_idsとビュー用のビュー順序インデックとの間の関係を提供することができる。従って、ビュー順序インデックスとSPS内のデータとを使用して、MVC/AVCの10ビットのview_idはNALユニットヘッダ内でビュー順序インデックスによって置き換えることができ、このことはMVC/AVC方式上でビット節約につながる可能性がある。ビュー順序インデックスは、POC値又はフレーム値(フレーム番号)とともに使用されて、ビットストリームのビューコンポーネントを識別することができる。例えば、図4に示されたビューコンポーネントのグリッドをカルテシアングリッドに関係付けて、ビュー順序インデックスは、特定のビューコンポーネントのy座標(例えば、S0、S1、S2、...)を提供することができ、POC値又はフレーム値は、特定のビューコンポーネントのx座標(例えば、T0、T1、T2、...)を提供することができる。このようにしてビューコンポーネントを識別することは、例えば、参照ピクチャリスト内に実施することができる。
本開示の他の態様によれば、MVCビットストリームのビューごとのビュー依存性は、ビューコンポーネントがアンカーピクチャ用か又は非アンカーピクチャ用かにかかわらず、通常全てのビューコンポーネントに通知することができる。幾つかの例では、SPSは、NALユニットヘッダ内の情報に依存するのではなく、ビューコンポーネント用のビュー依存性を含むことができる。このようにして、NALユニットヘッダ拡張部128内で使用されるanchor_pic_flagは、削除することができる。
この例では、図4に関して上述されたように、通知された依存ビューのビューコンポーネントは、リスト0とリスト1の両方において参照ピクチャとして使用することができる。加えて、リスト0及びリスト1についての参照ピクチャリストの構築及び参照ピクチャリストの並べ替えは、アンカーピクチャ用及び非アンカーピクチャ用の通常信号伝達に基づく場合もある。幾つかの例では、シーケンスレベル、補足強調情報(SEI)メッセージは、非アンカーピクチャがアンカーピクチャとは異なるビュー依存性を有するときを示すために使用することができる。
本開示の他の態様によれば、NALユニットヘッダ内のpriority_idを通知するのではなく、ビデオエンコーダ20はSPS内のpriority_id値を提供することができる。上記で説明されたように、幾つかの例では、ルータ36はSPSのpriority_id値を使用して、特定のビューをフィルタ処理することができる。即ち、ルータ36は完全なビットストリームを受信することができるが、宛先機器14によって指定された優先度値以下のpriority_id値を有するNALユニットを含むサブビットストリームを抽出し、そのサブビットストリームを宛先機器に転送することができる。
加えて、本開示の態様によれば、優先度適応メッセージは、適応を実行するために使用することができる。例えば、下記の表18は例示的な優先度適応SEIメッセージを示す
表18に示された例では、num_temporal_id_minus1プラス1は、MVCビットストリームのNALユニットの最も高いtemporal_idを示すことができる。1に等しいsame_priority_id_flag[i][j]要素は、temporal_id iとビュー順序インデックスjとを有するNALユニットのpriority_idが以前通知されたpriority_idに等しいことを示すことができ、それはj>0のときpriority_id[i][j−1]であり、又は、j=0及びi>0のときpriority_id[i−1][j]である。priority_id[i][j]要素は、iに等しいtemporal_idとjに等しいビュー順序インデックスとを有するNALユニット用の優先度識別子を指定することができる。priority_idのより低い値がより高い優先度を示すことができる。
適応は、NALユニットヘッダと、表18で示されたSEIメッセージなどのSEIメッセージとに基づく場合がある。例えば、適応プロセスは、NALユニットのtemporal_id及びview_idxがTID及びVIDXであり、ターゲットpriority_idがPIDであると仮定する場合がある。この例では、priority_id[TID][VIDX]はPIDよりも大きくなく、NALユニットは保持され、そうでない場合NALユニットはフィルタ処理して除かれる。
本例はSEIメッセージ内の優先度情報を記載するが、他の例では、SEIメッセージ内で通知されていると記載された情報は、MVCのSPSなどのパラメータセットのオプション部分として通知することができる。
図6は、マルチビュービットストリームを符号化する例示的な方法を示す流れ図である。図6に示された例は、全体的に、ビデオエンコーダ20(図1及び図2)によって実行されるものとして記載される。しかしながら、図6に関して記載されたプロセスは、様々な他のプロセッサ、処理ユニット、エンコーダ/デコーダ(コーデック)などのハードウェアベースのコード化ユニットなどによって遂行できることを理解されたい。
図6の例では、ビデオエンコーダ20は、複数のビューコンポーネント用のビデオデータを符号化することができる(140)。例えば、ビデオエンコーダ20は、複数の複数の異なるビューを符号化することができ、各ビューは、共通のシーンの対応するビデオデータがキャプチャされる異なる視点又は角度に対応する。上記のように、特定のビューの特定のピクチャはビューコンポーネントと呼ばれる。即ち、ビューのビューコンポーネントは、ビューの特定の時間インスタンスに対応する。
ビデオエンコーダ20はまた、ビューコンポーネントの復号順序の指示を含むNALユニットを形成することができる(142)。例えば、図5A〜図5Dに関して記載されたように、本開示の態様によれば、ビデオエンコーダ20は、ビューコンポーネントの復号順序の指示を提供するNALユニットヘッダ内で、ビュー順序インデックス(view_idx)の指示を提供することができる。一般に、同じ値のview_idxを有するNALユニットは同じビューに属する。
ビデオエンコーダ20はまた、NALユニットとは別に、ビュー識別子と復号順序との間の関係の指示を提供する情報を提供することができる(144)。幾つかの例では、ビデオエンコーダ20は、ビューのビュー識別子とビュー用のビュー順序インデックスとの間の関係を示す、SPSなどのパラメータセットを生成することができる。他の例では、ビデオエンコーダ20は、ビュー順序インデックスとビュー識別子との間の関係を、異なる方式で示すことができる。
ビュー順序インデックスと別個の情報とを使用して、ビデオエンコーダ20は、NALユニットヘッダ内に通常含まれる10ビットのビュー識別子を、ビュー順序インデックスによって置き換えることができ、これによりビット節約がもたらされる可能性がある。例えば、ビュー順序インデックスは、ビュー識別子よりもかなり少ないビットを含む可能性がある。ビデオエンコーダ20は、例えばSPS内でビュー順序インデックスとビュー識別子との間の関係を通知しなければならないが、NALユニットヘッダは、通常そのような信号伝達よりもはるかに多いビットを消費する。NALユニットヘッダ内のビュー識別子をビュー順序インデックスと置き換えると、NALユニットヘッダのサイズを縮小することができ、それにより、NALユニットヘッダ内のビュー識別子をコード化ことにわたってビット節約を実現する。
また、図6に関して図示及び記載されたステップは、一例として提供されたにすぎないことを理解されたい。即ち、図6の方法のステップは、必ずしも図6に示された順序で実行される必要があるとは限らず、より少ない、追加の、又は代替のステップを実行することができる。
図7は、マルチビュービットストリームを復号する例示的な方法を示す流れ図である。図7に示された例は、全体的に、ビデオデコーダ30(図1及び図3)によって実行されるものとして記載される。しかしながら、図7に関して記載されたプロセスは、様々な他のプロセッサ、処理ユニット、エンコーダ/デコーダ(コーデック)などのハードウェアベースのコード化ユニットなどによって遂行できることを理解されたい。
図7の例では、ビデオデコーダ30は、それぞれのビューコンポーネントの復号順序を示す情報を含むビューコンポーネントごとに、1つ又は複数のNALユニットを受信することができる(150)。本開示の態様によれば、図6に関して記載されたように、それぞれのビューコンポーネントの復号順序は、ビュー順序インデックスを使用して示すことができる。従って、ビデオデコーダ30は、ビューコンポーネントの復号順序の指示を提供する、NALユニットヘッダ内のビュー順序インデックス(view_idx)の指示を受信することができる。一般に、同じ値のview_idxを有するNALユニットは同じビューに属する。
ビデオデコーダ30はまた、ビュー識別子とビューコンポーネントの復号順序との間の関係を示す情報を受信することができる(152)。幾つかの例では、ビデオデコーダ30は、ビューのビュー識別子とビュー用のビュー順序インデックスとの間の関係を示す、SPSなどのパラメータセットを受信することができる。他の例では、ビデオデコーダ30は、ビュー順序インデックスとビュー識別子との間の関係の異なる指示を受信することができる。
ビデオデコーダ30はまた、受信された情報を使用して、マルチビュービデオデータを復号することができる。即ち、例えば、ビデオデコーダは、ビューの各々を復号し、受信された別個の情報を使用して適切なビュー識別子を決定することができる。次いで、ビデオデコーダ30は、例えば、表示装置32に、ビューを使用する3D表現を提示することができる。
また、図7に関して図示及び記載されたステップは、一例として提供されたにすぎないことを理解されたい。即ち、図7の方法のステップは必ずしも図7に示された順序で実行される必要があるとは限らず、より少ない、追加の、又は代替のステップを実行することができる。
図8は、マルチビュービットストリームを符号化する例示的な方法を示す流れ図である。図8に示された例は、全体的に、ビデオエンコーダ20(図1及び図2)によって実行されるものとして記載される。他の例では、図8に関して記載されたプロセスは、様々な他のプロセッサ、処理ユニット、エンコーダ/デコーダ(コーデック)などのハードウェアベースのコード化ユニットなどによって遂行することができる。図8の例では、ビデオデコーダ20は、第1のビューの任意のビューコンポーネントについて、第1のビューのビューコンポーネントを予測するための1つ又は複数の参照ビューを示す参照ビュー情報を決定することができる(160)。例えば、上記のように、特定のアクセスユニットの特定のビューコンポーネントがアンカーピクチャ(ランダムアクセスポイント)であるかどうか、又は特定のアクセスユニットの特定のビューコンポーネントが非アンカーピクチャであるかどうかにかかわらず、ビュー依存性は、ビューの全てのビューコンポーネントに同じ方式で通知することができる。幾つかの例では、参照ビュー情報は、参照ビューインデックス値(参照ビュー用のビュー順序インデックス値)を使用して、ビュー依存性を示すことができる。即ち、参照ビュー情報は、アクセスユニット内の参照ビューの復号順序を示すことができる、参照ビューごとの参照ビューインデックス値を含んでいる場合がある。他の例では、参照ビュー情報は、特定の参照ビューのビュー順序インデックスと、現在復号されているビューコンポーネントのビュー順序インデックスとの間の差分を示すことができる、参照ビューインデックス差分値を含んでいる場合がある。ビュー順序インデックス値が使用される例では、上述のように、ビデオエンコーダ20はまた、ビューのビュー順序インデックス値とビュー識別子との間の関係を示す追加情報を提供することができる。
ビデオエンコーダ20はまた、第1のビューにおいてアクセスユニット内の第1のビューコンポーネントを符号化するとき、第1のビューコンポーネントが属するアクセスユニットと、参照ビュー情報と、参照ビュー情報によって示された参照ビューの数とに基づいて、参照ピクチャリスト内に1つ又は複数の参照候補を含めることができる(162)。例えば、上述のように、ビデオエンコーダ20は、第1のビューコンポーネントを予測するための候補参照ピクチャを含む参照ピクチャリストを構築することができる(参照ピクチャは最終的な参照ピクチャリストから削除できるので、「候補」参照ピクチャである)。ビデオエンコーダ20は、第1のビューコンポーネントと同じアクセスユニットに属する(例えば、同じ時間インスタンスを有する)参照ビュー情報によって示された参照ビューの各々において、ビュー間候補参照ピクチャを識別することができる。ビデオエンコーダ20は、識別されたビューコンポーネントの全てを参照ピクチャリストに追加することができる。
従って、図8に示された例では、ビデオエンコーダ20は、現在符号化されているビューコンポーネントがアンカーピクチャか又は非アンカーピクチャかを顧慮せずに、参照ピクチャリストを構築することができる。更に、ビデオエンコーダ20は、候補参照ピクチャがリスト0に含まれるか又はリスト1に含まれるかを顧慮せずに、参照ピクチャリストを構築することができる。即ち、ビデオエンコーダ20は、同じ参照ビュー情報を使用して、参照ピクチャリスト0又は参照ピクチャリスト1を構築することができる。加えて、ビデオデコーダ20は、リスト0又は同様にリスト1の両方に、識別された参照候補を追加することができる。
ビデオエンコーダ20はまた、参照ピクチャリスト内の1つ又は複数の参照候補に基づいて、第1のビューコンポーネントを符号化することができる(164)。例えば、ビデオエンコーダ20は、参照ピクチャリスト内のビューコンポーネントを識別し、識別されたビューコンポーネントを使用して残差データを生成し、図2に関して上述されたように残差データを符号化することができる。ビデオエンコーダ20はまた、符号化されたビットストリーム内で決定された参照ビュー情報を、符号化された第1のビューコンポーネントに提供することができる(166)。
図8に関して図示及び記載されたステップは、一例として提供されたにすぎないことを理解されたい。即ち、図8の方法のステップは、必ずしも図8に示された順序で実行される必要があるとは限らず、より少ない、追加の、又は代替のステップを実行することができる。
図9は、マルチビュービットストリームを復号する例示的な方法を示す流れ図である。図9に示された例は、全体的に、ビデオデコーダ30(図1及び図3)によって実行されるものとして記載される。他の例では、図9に関して記載されたプロセスは、様々な他のプロセッサ、処理ユニット、エンコーダ/デコーダ(コーデック)などのハードウェアベースのコード化ユニットなどによって遂行することができる。
図9に示された例では、ビデオデコーダ30は、符号化されたビットストリームから、第1のビューの任意のビューコンポーネントについて、第1のビューのビューコンポーネントを予測するための1つ又は複数の参照ビューを示す参照ビュー情報を取得することができる(170)。例えば、図8に関して上述されたように、特定のアクセスユニットの特定のビューコンポーネントがアンカーピクチャ(ランダムアクセスポイント)であるかどうか、又は特定のアクセスユニットの特定のビューコンポーネントが非アンカーピクチャであるかどうかにかかわらず、ビュー依存性は、ビューの全てのビューコンポーネントに同じ方式で通知することができる。幾つかの例では、参照ビュー情報は、参照ビューインデックス値(参照ビュー用のビュー順序インデックス値)を使用して、ビュー依存性を示すことができる。即ち、参照ビュー情報は、アクセスユニット内の参照ビューの復号順序を示すことができる、参照ビューごとの参照ビューインデックス値を含んでいる場合がある。他の例では、参照ビュー情報は、特定の参照ビューのビュー順序インデックスと、現在復号されているビューコンポーネントのビュー順序インデックスとの間の差分を示すことができる、参照ビューインデックス差分値を含んでいる場合がある。ビュー順序インデックス値が使用される例では、上述のように、ビデオデコーダ30はまた、符号化されたビットストリームから、ビューのビュー順序インデックス値とビュー識別子との間の関係を示す追加情報を取得することができる。そのような情報はシーケンスレベルから取得することができる。
ビデオデコーダ30はまた、第1のビューにおいてアクセスユニット内の第1のビューコンポーネントを復号するとき、第1のビューコンポーネントが属するアクセスユニットと、参照ビュー情報と、参照ビュー情報によって示された参照ビューの数とに基づいて、参照ピクチャリスト内に1つ又は複数の参照候補を含めることができる(172)。例えば、上述のように、ビデオデコーダ30は、第1のビューコンポーネントを予測するための候補参照ピクチャを含む参照ピクチャリストを構築することができる。ビデオデコーダ30は、第1のビューコンポーネントと同じアクセスユニットに属する(例えば、同じ時間インスタンスを有する)参照ビュー情報によって示された参照ビューの各々において、ビュー間候補参照ピクチャを識別することができる。ビデオデコーダ30は、識別されたビューコンポーネントの全てを参照ピクチャリストに追加することができる。
従って、図9に示された例では、ビデオデコーダ30は、現在符号化されているビューコンポーネントがアンカーピクチャか又は非アンカーピクチャかを顧慮せずに、参照ピクチャリストを構築することができる。更に、ビデオデコーダ30は、候補参照ピクチャがリスト0に含まれるか又はリスト1に含まれるかを顧慮せずに、参照ピクチャリストを構築することができる。即ち、ビデオデコーダ30は、かつて符号化されたビットストリームからのみ取得された可能性がある同じ参照ビュー情報を使用して、参照ピクチャリスト0又は参照ピクチャリスト1を構築することができる。加えて、ビデオデコーダ30は、リスト0又は同様にリスト1の両方に、識別された参照候補を追加することができる。
ビデオデコーダ30はまた、参照ピクチャリスト内の1つ又は複数の参照候補に基づいて、第1のビューコンポーネントを復号することができる(174)。例えば、ビデオデコーダ20は、上記の図3に関して記載されたように、参照ピクチャリスト内のビューコンポーネントを識別し、識別されたビューコンポーネントを(符号化されたビットストリームからの)復号された残差データと合成して、ビューコンポーネントを生成することができる。
図9に関して図示及び記載されたステップは、一例として提供されたにすぎないことを理解されたい。即ち、図9の方法のステップは、必ずしも図9に示された順序で実行される必要があるとは限らず、より少ない、追加の、又は代替のステップを実行することができる。
本開示に関して記載された特定のシンタックス要素は、説明の目的で例示的な名称を提供されたが、本開示に記載された概念は、名称にかかわらず、より一般的に任意のシンタックス要素に適用可能であることを理解されたい。例えば、特定の態様が「ビュー順序インデックス」、「view_order_index」又は「view_idx」に言及するが、そのようなシンタックス要素は、将来のコード化規約において代替の名称を与えられる可能性があることを理解されたい。
本開示の特定の技法が新HEVC規格に関して記載されたが、本技法は任意の特定のコード化規格に限定されないことを理解されたい。即ち、本技法は、より一般的に、例えば、上述のように、より短い、かつ/又はより複雑でないNALユニット及びパラメータセットを介して、マルチビュービデオコード化におけるコード化効率を実現することに関する。
例に応じて、本明細書に記載された方法のうちのいずれかの特定の行為又はイベントは、異なるシーケンスで実行でき、一斉に付加、マージ、又は除外できる(例えば、全ての記載された行為又はイベントが方法の実践のために必要であるとは限らない)ことを理解されたい。更に、特定の例では、行為又はイベントは、順次ではなく、例えば、マルチスレッド処理、割込み処理、又は複数のプロセッサを介して同時に実行することができる。加えて、本開示の特定の態様は、明快にするために単一のモジュール又はユニットによって実行されるものとして記載されたが、本開示の技法は、ビデオコーダに関連するユニット又はモジュールの組合せによって実行できることを理解されたい。
1つ又は複数の例では、記載された機能は、ハードウェア、ソフトウェア、ファームウェア、又はそれらの任意の組合せに実施することができる。ソフトウェアに実施される場合、機能は、1つ又は複数の命令又はコードとしてコンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体を介して送信され、ハードウェアベースの処理ユニットによって実行することができる。コンピュータ可読媒体は、例えば、データ記憶媒体などの有形媒体、又は、例えば通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体に対応する、コンピュータ可読記憶媒体を含むことができる。
このようにして、コンピュータ可読媒体は、一般に、(1)非一時的である有形コンピュータ可読記憶媒体、又は、(2)信号もしくは搬送波などの通信媒体に対応することができる。データ記憶媒体は、本開示に記載された技法を実施するための命令、コード及び/又はデータ構造を取り出すために、1つもしくは複数のコンピュータ、又は1つもしくは複数のプロセッサによってアクセスできる任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含むことができる。
限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM、CD−ROMもしくは他の光ディスク記憶装置、磁気ディスク記憶装置もしくは他の磁気記憶装置、フラッシュメモリ、又は命令もしくはデータ構造の形態の所望のプログラムコードを記憶するために使用でき、コンピュータによってアクセスできる任意の他の媒体を備えることができる。同様に、いかなる接続も厳密にはコンピュータ可読媒体と称される。例えば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(DSL)、又は赤外線、無線、及びマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、又は他のリモート発信源から送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、又は赤外線、無線、及びマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。
しかしながら、コンピュータ可読記憶媒体及びデータ記憶媒体は、接続、搬送波、信号、又は他の一時的媒体を含まないが、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用するディスク(disk)及びディスク(disc)は、コンパクトディスク(disc)(CD)、レーザディスク(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピー(登録商標)ディスク(disk)及びブルーレイディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含まれるべきである。
命令は、1つ以上のデジタル信号プロセッサ(DSP)などの1つ以上のプロセッサ、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、又は他の等価な集積回路若しくはディスクリート論理回路によって実行することができる。従って、本明細書で使用する「プロセッサ」という用語は、前述の構造、又は本明細書に記載された技法の実施に適した任意の他の構造のいずれかを指すことができる。加えて、幾つかの態様では、本明細書に記載された機能は、符号化及び復号のために構成された専用のハードウェア及び/又はソフトウェアモジュールの内部に提供でき、又は合成コーデックに組み込むことができる。また、本技法は、1つ又は複数の回路又は論理要素に完全に実施することができる。
本開示の技法は、ワイヤレスハンドセット、集積回路(IC)、又は一組のIC(例えば、チップセット)を含む、多種多様な機器又は装置に実施することができる。開示された技法を実行するように構成された機器の機能的態様を強調するために、様々な構成要素、モジュール、又はユニットが本開示に記載されたが、それらの構成要素、モジュール、又はユニットは、必ずしも異なるハードウェアユニットによって実現する必要があるとは限らない。むしろ、上述のように、様々なユニットが、適切なソフトウェア及び/又はファームウェアとともに、上述された1つ又は複数のプロセッサを含んで、コーデックハードウェアユニットにおいて組み合わせることができるか、又は相互動作ハードウェアユニットの集合によって提供することができる。
本開示の様々な態様が記載された。これら及び他の態様は以下の特許請求の範囲内に入る。