JP6233984B2 - マルチビュー・ビデオ符号化のための仮想参照デコーダ - Google Patents

Description

関連出願への相互参照
本願は、2007年4月17日に出願された米国仮出願第60/923,800号の利益を主張するものである。同仮出願はここにその全体において参照によって組み込まれる。

技術分野
本願は、圧縮ビデオ・システムにおけるマルチビュー・ビデオ符号化のための仮想参照デコーダに関する。

仮想参照デコーダ（HRD: hypothetical reference decoder）は、標準への準拠について、エンコードされたビットストリームを検証する役割を果たすので、圧縮ビデオ・システムにおいて貴重である。H.264/AVCのような符号化規格では、同規格のマルチビュー・ビデオ符号化（MVC: Multiview Video Coding）内において多数の相互運用点（interoperability point）がある。MVCは、デコーダが一つまたは複数のビューを同時にデコードすることを許容し、一つのビューのデコードは他のビューからの情報を必要とすることがありうる。H.264/AVC規格はHRDを定義する規則（要件、制約条件または動作仕様とも称される）をもつ。HRD準拠はH.264/MPEG-4 AVC規格の規範的部分である。どんなAVCビットストリームも、前記規則に従って構築されたHRDに準拠していなければならない。現在のところ、MVC HRDについて定義された規則はない。以前のHRDは、AVC内のMVCビットストリームのようなビットストリームを検証できるようにする十分な規則をもたなかった。

多くの場合において、圧縮されたビットストリームのビットレート変動が、エンコーダおよびデコーダにおけるバッファリング機構を使ってならされる必要がある。物理的バッファのサイズは有限であり、よってエンコーダは、バッファ制限内に収まるようビットレート変動を制約する。ビデオ符号化規格は特定のエンコーダまたはデコーダ・バッファリング機構を必須としてはおらず、所与のバッファ・サイズの仮想参照デコーダ（HRD）（またはバーチャル・バッファ検証器（VBV: Virtual Buffer Verifier））がバッファ・オーバーフローやアンダーフローを被ることなくビデオ・ビットストリームをデコードするようビットレートゆらぎを制御することをエンコーダに要求する。

HRDは理想化されたデコーダ・モデルに基づいている。HRDの目的は、符号化されたストリーム内において時間的なビットレートの変動に対する基本的なバッファリング制約条件を課すことである。これらの制約条件が今度はより高いレイヤーがストリームを多重化することを可能にし、コスト効率のよいデコーダがそれをリアルタイムでデコードすることを可能にする。しかしながら、本発明は、他のビデオ符号化モデルまたは規格に拡張されることができる。

本発明は、マルチビュー・ビデオ符号化（MVC）のための仮想参照デコーダ（HRD）を定義するいくつかの方法を提案する。

現行のH.264/MPEG-4 AVCベースのMVC実装では、参照ソフトウェアは、マルチビュー予測を、各ビューを単一のエンコーダでエンコードし、ビュー横断参照を考慮に入れることによって達成する。各ビューはそのもとの解像度でエンコーダによって別個のビットストリームとして符号化され、のちにすべてのビットストリームが組み合わされて単一のビットストリームを形成する。デコーダでは、ユーザーは一つまたは複数のビューをそのアプリケーションに基づいてデコードできる。現在の仕様では、MVCについてはHRD規則は定義されていない。

MVCにおいて、全部でN個の符号化されたビューがあるとする。デコーダは任意のM（1≦M≦N）個のビューを同時にデコードする柔軟性をもつことができる。M個のビューの各組み合わせが相互運用点（IOP: interoperability point）を表す。最良の柔軟性を許容するため、このカテゴリーにおいては、本発明は、MVC HRDがHRD制約条件を各IOPについて定義することを提案する。この解決策の問題は、(2N−1)にも上るあまりに多くの組み合わせがあるということである。MについてM≦32という制限が加えられたとしても、組み合わせの総数はまだ巨大である。本発明は、マルチビュー・ビデオ符号化についての仮想参照デコーダについての規則であって、各相互運用点について指定される規則を提供する方法を記述する。

諸単独ビューのHRDパラメータによって導出される諸ビュー組み合わせのHRDパラメータを示す図である。 マルチビュー・ビデオ符号化エンコーダを示す図である。 マルチビュー・ビデオ符号化デコーダを示す図である。 カテゴリー１のMVCエンコード・プロセスについてビデオ使用可能性情報（Video Usability Information）を示す図である。 カテゴリー１のMVCデコード・プロセスについてビデオ使用可能性情報を示す図である。 カテゴリー１のマルチビュー・ネスティングSEIエンコード・プロセスを示す図である。 カテゴリー１のマルチビュー・ネスティングSEIデコード・プロセスを示す図である。 カテゴリー２のMVCエンコード・プロセスについてビデオ使用可能性情報を示す図である。 カテゴリー２のMVCデコード・プロセスについてビデオ使用可能性情報を示す図である。 カテゴリー２および３のマルチビュー・ネスティングSEIエンコード・プロセスを示す図である。 カテゴリー２および３のマルチビュー・ネスティングSEIデコード・プロセスを示す図である。 カテゴリー３のMVCエンコード・プロセスについてビデオ使用可能性情報を示す図である。 カテゴリー３のMVCデコード・プロセスについてビデオ使用可能性情報を示す図である。

現行のH.264/MPEG-4 AVC参照実装では、HRD関係のパラメータがシーケンス・パラメータ・セット（SPS: sequence parameter set）およびSEIメッセージ内に置かれる。

SPSは表１に示されるようなシンタックス構造、VUIパラメータを含む。

シンタックス要素num_units_in_tick、time_scale、fixed_frame_rate_flagおよびlow_delay_hrd_flagおよびシンタックス構造HRDパラメータが、表２に示すようなシンタックス構造VUIパラメータ内に置かれる。

シンタックス構造HRD_parametersは、バッファ・サイズおよびビットレート等を指定するシンタックスを含む。

バッファ周期SEI（buffer period SEI）およびピクチャー・タイミングSEI（picture timing SEI）は、ピクチャーをデコードする前の初期の符号化されたピクチャーのバッファ除去遅延と、各ピクチャーのタイミングを導出するための諸パラメータとを指定した。

現行のAVC実装、SPS内に置かれたHRD関係のパラメータに基づいて、バッファリング周期SEIおよびピクチャー・タイムSEI内に置かれる諸パラメータと組み合わせて、HRD関係制約条件のセットがH.264/MPEG-4 AVCについて定義される。

しかしながら、現行のAVC実装は、HRDパラメータの一つのセットをサポートするのみである。これはMVCビットストリームに含まれる複数IOPにフィットしない。

現行のH.264/MPEG-4 AVCベースのMVC実装では、参照ソフトウェアは、各ビューを単一のエンコーダを用いてエンコードし、ビュー横断参照を考慮に入れることによって、マルチビュー予測を達成する。各ビューはエンコーダによって、そのもとの解像度で別個のビットストリームとして符号化され、のちにすべてのビットストリームが組み合わされて単一のビットストリームを形成する。デコーダでは、ユーザーは一つまたは複数のビューをそのアプリケーションに基づいてデコードできる。MVCエンコーダおよびデコーダの図がそれぞれ図２および図３に示されている。

現行の仕様では、MVCについて定義されたHRD規則はない。

記述される実施形態の多くは、H.264/MPEG-4 AVCベースのMVC実装のフレームワークを使う。同様の発想は、他のビデオ符号化規格にも適用できる。たとえば、一つまたは複数の動作点（operating point）（相互運用点のような）について特定のパラメータを指定する機能は、H.264/MPEG-4 AVC規格以外の規格にも適用できる。

三つの別個のクラスの実装が記述される。

Ａ．MVCにおける各相互運用可能点についてのHRD規則の規定
MVCにおいて、全部でN個の符号化されたビューがあるとする。デコーダは任意のM（1≦M≦N）個のビューを同時にデコードする柔軟性をもつことができる。M個のビューの各組み合わせは相互運用点（IOP: interoperability point）を表す。最良の柔軟性を許容するため、このカテゴリーにおいて、本発明は、MVC HRDがHRD制約条件を各IOPについて定義することを提案する。この解決策の問題は、(2N−1)にも上るあまりに多くの組み合わせがあるということである。MについてM≦32という制限が加えられたとしても、組み合わせの総数はまだ巨大である。

この解決策の実施形態を以下に呈示する。

ビューのすべての組み合わせは、AVC-HRD規則への次の修正において組み合わされる。表３はAVC規格から取られており、AVC-HRDに関係する。AVC規格の表への追加はイタリック体フォントを使って示されている。新しいSEIメッセージであるマルチビュー・ネスティングSEI（multiview nesting SEI）が表４で導入される。VUIエンコードおよびデコード過程のフローチャートがそれぞれ図４および図５に示される。マルチビュー・ネスティングSEIエンコードおよびデコード過程のフローチャートはそれぞれ図６および図７に示される。

１．VUIパラメータ：見て取れるように、表３は、AVC規格におけるVUIパラメータのシンタックスが変数「profile_idc」を試験する「if‐then」文を導入することによって修正されていることを示している。「profile_idc」が「MVC」に等しければ、一つまたは複数の点（すなわちIOP）を試験するためにループが一回または複数回実行される。「profile_idc」が「MVC」に等しくない場合、「AVC」が関連する規格であると想定され、（既存のAVC-HRD規則を使って）AVC準拠について一つの点を試験するために「else」が実行される。行30〜60は「profile_idc」がMVCである場合に実行され、そうでない場合には行63〜88が実行される。変数「num_view_combinations_minus1」〔ビュー組み合わせ数マイナス１〕（行30）はループ中のIOPの数を与える。メイン・ループ内において、各IOPについてのサブ・ループ（行33〜34）はそのIOPに関連付けられたview_idを与える。各サブ・ループについて、「num_views_minus1[i]」〔ビュー数マイナス１〕（行32）はi番目のIOPに関連付けられたビューの数を与え、「view_id[i][j]」（行34）はi番目のIOPのj番目のビューのview_idを与える。行35〜59はi番目のIOPについてのシンタックスを与える。あるMVCビットストリームについて、(2N−1)個までのIOPがあることができる。これは、AVCストリームについての単一の検査点（checking point）と比較される。

２．新しいSEIメッセージ、マルチビュー・ネスティングSEIが表４で定義される。マルチビュー・ネスティングSEIメッセージは、アクセス・ユニットに関する。マルチビュー・ネストSEIメッセージは、一つにして唯一のSEIメッセージを含んでいる。これはネストされたSEIメッセージと称される。ネストされたSEIメッセージが適用される範囲は、行2〜10からのシンタックスによって示される。

「num_view_combinations_minus1」、「num_views_minus1[i]」および「view_id[i][j]」はVUIパラメータにおけるものと同じ意味を共有する。

３．バッファリング周期SEIメッセージおよびピクチャー・タイミングSEIメッセージ（これらはAVCの一部である）は、マルチビュー・ネスティングSEIメッセージに埋め込まれたSEIメッセージ・ペイロードとして実装されることができる。バッファリング周期SEIおよびピクチャー・タイミングSEIのシンタックスは、AVCと同じままである。AVC互換ビューのためのバッファリング周期SEIメッセージおよびピクチャー・タイミングSEIメッセージは、マルチビュー・ネスティングSEIにおいてネストされてはならない。これは、AVC互換性を許容する。

num_view_combinations_minus1に1を足したものは、このhrd_parameters()を含むSPSにおける同じseq_parameter_set_idを参照するビットストリームによってサポートされるビュー組み合わせの数を示す。
num_views_minus1[i]は、i番目のIOPに関連付けられたビューの数を示す。
view_id[i][j]はi番目のIOPのj番目のビューのview_idを示す。
timing_info_present_flag[i]はi番目のIOPのtiming_info_present_flag値を指定する。
num_units_in_tick[i]はi番目のIOPのnum_units_in_tick値を指定する。
time_scale[i]はi番目のIOPのtime_scale値を指定する。
fixed_frame_rate_flag[i]はi番目のIOPのfixed_frame_rate_flag値を指定する。
nal_hrd_parameters_present_flag[i]はi番目のIOPのnal_hrd_parameters_present_flag値を指定する。
vcl_hrd_parameters_present_flag[i]はi番目のIOPのvcl_hrd_parameters_present_flag値を指定する。
low_delay_hrd_flag[i]はi番目のIOPのlow_delay_hrd_flag値を指定する。
pic_struct_present_flag[i]はi番目のIOPのpic_struct_present_flag値を指定する。

timing_info_present_flag、num_units_in_tick、time_scale、nal_hrd_parameters_present_flag、vcl_hrd_parameters_present_flag、low_delay_hrd_flagおよびpic_struct_present_flagはAVCにおけるのと同じ意味をもつ。

all_view_combinations_in_au_flagが1に等しいことは、ネストされたSEIメッセージがアクセス・ユニット（access unit）のすべてのビュー組み合わせに適用されることを示す。
all_view_combinations_in_au_flagが0に等しいことは、ネストされるSEIメッセージの適用可能な範囲がシンタックス要素num_view_combinations_minus1、num_views_minus1[i]およびview_id[i][j]によって伝達されることを示す。
num_view_combinations_minus1に1を足したものは、ビットストリームによってサポートされるビュー組み合わせの数を示す。
num_views_minus1[i]は、i番目のIOPに関連付けられたビューの数を示す。
view_id[i][j]はi番目のIOPのj番目のビューのview_idを示す。

Ｂ．IOPのあるセットについてのみのHRD規則の規定
このカテゴリーでは、IOPのあるセットについてMVC HRDを定義し、このセットからIOPの他の諸セットを導出することが提案される。一つの実施形態は、MVC HRDは可能な各単独ビューをデコードするためのHRD制約条件を定義するのみで、二つ以上のビューをデコードするためのHRDパラメータは関連する単独ビュー・パラメータから導出されるという提案である。このアプローチは、第一のアプローチよりも少数のパラメータを送ることを許容するが、導出のための一層の複雑さを追加する。

この解決策の実施形態を以下に呈示する。

HRDは各ビューについて定義される。送るHRDパラメータのセットの最大数はMである。ここで、M＝1,…,Nである。よって、N個のビューがあれば、この実施形態はHRDパラメータのN個のセットを送ることになる。VUIエンコードおよびデコード過程のフローチャートがそれぞれ図８および図９に示されている。そして、マルチビュー・ネスティングSEIエンコードおよびデコード過程のフローチャートがそれぞれ図１０および図１１に示されている。

１．VUIパラメータ：見て取れるように、は、AVC規格におけるVUIパラメータのシンタックスが変数「profile_idc」を試験する「if‐then」文を導入することによって修正されていることを示している。「profile_idc」が「MVC」に等しければ、一つまたは複数の点を試験するためにループが一回または複数回実行される。「profile_idc」が「MVC」に等しくない場合、「AVC」が関連する規格であると想定され、（既存のAVC-HRD規則を使って）AVC準拠について一つの点を試験するために「else」が実行される。行30〜58は「profile_idc」がMVCである場合に実行され、そうでない場合には行61〜85が実行される。変数「num_view_ minus1」（行30）はループ中のビューの数を与える。「view_id[i]」（行32）はi番目のビューのview_idを与える。行33〜58はi番目のビューについてのシンタックスを与える。あるMVCビットストリームについて、M（M＝1,…,N）個までのビューがあることができる。これは、AVCストリームについての単一の検査点（checking point）と比較される。

２．新しいSEIメッセージ、マルチビュー・ネスティングSEIが表６で定義される。マルチビュー・ネスティングSEIメッセージは、アクセス・ユニットに関する。マルチビュー・ネスティングSEIメッセージは、一つにして唯一のSEIメッセージを含んでいる。これはネストされたSEIメッセージと称される。ネストされたSEIメッセージが適用される範囲は、行2〜7からのシンタックスによって示される。

「num_views_minus1」および「view_id[i]」は、VUIパラメータにおけるものと同じ意味を共有する。

３．バッファリング周期SEIメッセージおよびピクチャー・タイミングSEIメッセージは、マルチビュー・ネスティングSEIメッセージに埋め込まれたSEIメッセージ・ペイロードとしてであることができる。バッファリング周期SEIおよびピクチャー・タイミングSEIのシンタックスは、AVCと同じままである。AVC互換ビューのためのバッファリング周期SEIメッセージおよびピクチャー・タイミングSEIメッセージは、マルチビュー・ネスティングSEIにおいてネストされてはならない。

各IOP（ビュー組み合わせ）のHRDパラメータは、そのIOPに関連付けられた諸ビューのHRDパラメータによって導出される。例が図１に与えられている。

num_views_minus1は、ビットストリーム中のビューの総数を示す。
view_id[i]はi番目のビューのview_idを示す。
timing_info_present_flag[i]はi番目のビューのtiming_info_present_flag値を指定する。
num_units_in_tick[i]はi番目のビューのnum_units_in_tick値を指定する。
time_scale[i]はi番目のIOPのtime_scale値を指定する。
fixed_frame_rate_flag[i]はi番目のビューのfixed_frame_rate_flag値を指定する。
nal_hrd_parameters_present_flag[i]はi番目のビューのnal_hrd_parameters_present_flag値を指定する。
vcl_hrd_parameters_present_flag[i]はi番目のビューのvcl_hrd_parameters_present_flag値を指定する。
low_delay_hrd_flag[i]はi番目のビューのlow_delay_hrd_flag値を指定する。
pic_struct_present_flag[i]はi番目のビューのpic_struct_present_flag値を指定する。

timing_info_present_flag、num_units_in_tick、time_scale、nal_hrd_parameters_present_flag、vcl_hrd_parameters_present_flag、low_delay_hrd_flagおよびpic_struct_present_flagはAVCにおけるのと同じ意味をもつ。

all_views_in_au_flagが1に等しいことは、ネストされたSEIメッセージがアクセス・ユニットのすべてのビューに適用されることを示す。all_views_ in_au_flagが0に等しいことは、ネストされるSEIメッセージの適用可能な範囲がシンタックス要素num_views _minus1およびview_id[i]によって伝達されることを示す。
num_views_minus1に1を足したものは、ビットストリームによってサポートされるビューの数を示す。
view_id[i]はi番目のビューのview_idを示す。

Ｃ．最悪ケースについてのHRD規則の規定
このカテゴリーでは、M（M＝1,…,N）個のビューをデコードする最悪ケースについてのHRD制約条件のみを定義することが提案される。最悪ケースは、たとえば、最大バッファ・サイズ、最長遅延、最高ビットレート、任意のM個のビューを伝送することの最多ビット消費などを要求するケースである。よって、各MビューをデコードするためにHRDパラメータの一つのセットを定義することができるだけである。すなわち、最悪ケースの単独ビューについてHRDパラメータのセットと、最悪ケースの2ビュー組み合わせについてのHRDパラメータのセット等、最悪ケースのN−1ビュー組み合わせについてのHRDパラメータのセットまでと、（最悪ケースの）Nビュー組み合わせについてのHRDパラメータのセットを定義する。全部で、NセットのHRDパラメータを定義するだけであり、これらが1、2、…N個までのビューについてHRD準拠を試験するために使われる。このアプローチの不都合な点は、一つの特定の場合が必要としうるよりも高い制約条件を送ることを要求するということである。しかし、すべてのHRDパラメータを送るためのビットを節約することができ、パラメータの導出もない。

この解決策の実施形態を下記に呈示する。

送るHRDパラメータのセットの最大数はMである。ここで、M＝1,…,Nである。VUIエンコードおよびデコード過程のフローチャートがそれぞれ図１２および図１３に示されている。

１．VUIパラメータ：見て取れるように、表７は、AVC規格におけるVUIパラメータのシンタックスが変数「profile_idc」を試験する「if‐then」文を導入することによって修正されていることを示している。「profile_idc」が「MVC」に等しければ、一つまたは複数の点を試験するためにループが一回または複数回実行される。「profile_idc」が「MVC」に等しくない場合、「AVC」が関連する規格であると想定され、（既存のAVC-HRD規則を使って）AVC準拠について一つの点を試験するために「else」が実行される。行30〜57は「profile_idc」がMVCである場合に実行され、そうでない場合には行60〜84が実行される。変数「num_view_ minus1」（行30）はビットストリーム中のビューの数を与える。行32〜56は、(num_views_minus1+1)個のビューのうちの任意のi個のビューをデコードすることの最高のHRD制約条件に関連付けられたHRD関係のパラメータについてのシンタックスを与える。

表７が表５と異なっていることに注意されたい。たとえば、表５の行32を参照すると、「view_id[i]」と記載している。

２．バッファリング周期SEIメッセージおよびピクチャー・タイミングSEIメッセージは、マルチビュー・ネスティングSEIメッセージに埋め込まれたSEIメッセージ・ペイロードとしてであることができる。マルチビュー・ネスティングSEIメッセージのシンタックスは、表６で定義されたものを共有できる。ネストするバッファリング周期およびピクチャー・タイミングSEIメッセージは、ビットストリーム中で送るビューの総数のうち任意の(num_views_minus1+1)個のビューをデコードすることの最高のHRD制約条件に関連付けられている。バッファリグ周期SEIおよびピクチャー・タイミングSEIのシンタックスは、AVCと同じままである。AVC互換ビューのためのバッファリング周期SEIメッセージおよびピクチャー・タイミングSEIメッセージは、マルチビュー・ネスティングSEIにおいてネストされてはならない。

num_views_minus1は、ビットストリーム中のビューの総数を示す。
timing_info_present_flag[i]はi個のビューをデコードするためのtiming_info_present_flag値を指定する。
num_units_in_tick[i]はi個のビューをデコードするためのnum_units_in_tick値を指定する。
time_scale[i]はi個のビューをデコードするためのtime_scale値を指定する。
fixed_frame_rate_flag[i]はi個のビューをデコードするためのfixed_frame_rate_flag値を指定する。
nal_hrd_parameters_present_flag[i]はi個のビューをデコードするためのnal_hrd_parameters_present_flag値を指定する。
vcl_hrd_parameters_present_flag[i]はi個のビューをデコードするためのvcl_hrd_parameters_present_flag値を指定する。
low_delay_hrd_flag[i]はi個のビューをデコードするためのlow_delay_hrd_flag値を指定する。
pic_struct_present_flag[i]はi個のビューをデコードするためのpic_struct_present_flag値を指定する。

パラメータtiming_info_present_flag、num_units_in_tick、time_scale、nal_hrd_parameters_present_flag、vcl_hrd_parameters_present_flag、low_delay_hrd_flagおよびpic_struct_present_flagはAVCにおけるのと同じ意味をもつ。

図４ないし図１３は、同定される特定のシンタックスを書き込むまたは読み出すためのさまざまなフローチャートを示している。

本稿では、たとえばMVCのためのHRDの記述を書き込むおよび／または読み込むための規則を提供するいくつかの実装が記載されている。これはHRDがMVCにおいて定義され、使用されることを許容する。

しかしながら、記載された実装の諸特徴および諸側面は他の実装のためにも適応されてもよい。たとえば、上に示したように、他の規格のために上記の機能を使ってHRDが提供されてもよい。さらに、HRDは、上記の実施形態の変形を使ってMVCのために提供されてもよい。そのような変形は、たとえば、他の高レベル・シンタックスを使う、高レベルでないシンタックスを使う、他のIOPのためのHRDパラメータを提供する実装を含みうる。したがって、本稿に記載されている諸実装は、本稿に記載される三つの主要な実装の一つを実装するH.264のための高レベル・シンタックスのコンテキストで記載されているかもしれないが、そのような記述は決して本願の特徴および概念をそのような実装またはコンテキストに限定するものと解釈するべきではない。

本稿で記載された実装はたとえば、方法もしくはプロセス、装置またはソフトウェア・プログラムにおいて実装されうる。たとえ単一の形の実装のコンテキストでのみ論じられていたとしても（たとえば方法としてのみ論じられていたとしても）、論じられている実装または特徴は他の形（たとえば装置またはプログラム）においても実装されうる。装置は、たとえば、適切なハードウェア、ソフトウェアおよびファームウェアにおいて実装されうる。方法はたとえば、コンピュータまたは他の処理装置などのような装置において実装されてもよい。さらに、方法は、処理装置または他の装置によって実行される命令によって実装されてもよく、そのような命令は、たとえばDVDまたは他のコンピュータ可読記憶デバイスのようなコンピュータ可読媒体上、あるいは集積回路上に記憶されてもよい。

当業者には明白なはずであるが、実装はまた、たとえば記憶または伝送されうる情報を担持するようフォーマットされた信号を生成してもよい。該情報はたとえば、方法を実行するための命令、あるいは記載された実装の一つによって生成されるデータを含んでもよい。たとえば、信号は、記述された実施形態のシンタックスを書き込むまたは読み出すための規則をデータとして担持するよう、あるいは記載された実施形態によって書き込まれる実際のシンタックスをデータとして担持するようフォーマットされてもよい。

さらに、多くの実装が、エンコーダおよびデコーダの一方または両方において実装されうる。

さらに、本発明によって他の実装が考えられている。たとえば、開示されている実装のさまざまな特徴を組み合わせ、削除し、修正しまたは補足することによって、追加的な実装が作り出されてもよい。

以上の記述はさまざまな実装のいくつかを提供する。それは網羅的であることは意図されておらず、単に数多くの可能な実装のうちの少数の短い記述を提供するものである。

Claims (17)

1. ビットストリームからマルチビュー・ビデオを復号する方法であって、
   前記ビットストリームからマルチビュー・ビデオ符号化における１つの相互運用点に関連付けられた１つ以上のビューのビュー情報にアクセスするステップであって、前記ビットストリームは、複数の相互運用点を含み、前記１つの相互運用点は、前記複数の相互運用点の第１のサブセットに含まれ、前記ビュー情報は、前記１つの相互運用点に関連付けられたビューの数および前記１つ以上のビューの各々に対するビュー識別子を示し、前記１つの相互運用点は、前記１つ以上のビューに対応する、前記アクセスするステップと、
   複数のＨＲＤ（仮想参照デコーダ）制約条件が前記ビットストリームに含まれ、前記ＨＲＤ制約条件の各々は、少なくともバッファ・サイズ、ビットレート、初期の符号化されたピクチャーのバッファ除去遅延およびピクチャーのタイミング情報によって規定され、
   前記複数の相互運用点の前記第１のサブセットについて前記複数のＨＲＤ制約条件のうちの第１のＨＲＤ制約条件が前記ビットストリームにおいて規定されている、前記方法。
2. 前記複数の相互運用点の第２のサブセットについて前記複数のＨＲＤ制約条件のうちの第２のＨＲＤ制約条件が前記ビットストリームにおいて規定されている、請求項１に記載の方法。
3. 前記複数の相互運用点の各々について前記複数のＨＤＲ制約条件のうちの１つのＨＲＤ制約条件が前記ビットストリームにおいて規定され、前記複数の相互運用点の第１のサブセットは、個々の相互運用点のうちの一つに対応する、請求項１に記載の方法。
4. 個々のビューの各々について前記複数のＨＤＲ制約条件のうちの１つのＨＲＤ制約条件が前記ビットストリームにおいて規定され、一つを超えるビューを有する１つの相互運用点について１つのＨＲＤ制約条件を決定するために個々のビューについて前記複数のＨＲＤ制約条件が使用され、前記複数の相互運用点の前記第１のサブセットは、前記個々のビューのうちの一つに対応する、請求項１に記載の方法。
5. 前記複数の相互運用点の前記第１のサブセットについて最悪ケースのＨＲＤ制約条件がビットストリームにおいて規定され、前記最悪ケースのＨＲＤ制約条件は、前記複数の相互運用点の前記第１のサブセットに対して必要な最大のバッファ・サイズ、最長遅延、最高ビットレート、および最多ビット消費の少なくとも一つに対応し、前記複数の前記相互運用点の前記第１のサブセットは、同一の数のビューを有する、請求項１に記載の方法。
6. マルチビュー・ビデオをビットストリームに符号化する方法であって、
   １つの相互運用点に関連付けられた１つ以上のビューのビュー情報にアクセスするステップであって、前記ビュー情報は、前記１つの相互運用点に関連付けられたビューの数および前記１つ以上のビューの各々に対するビュー識別子を示し、前記１つの相互運用点は、前記１つ以上のビューに対応する、前記アクセスするステップと、
   決定されたビューのビュー情報を前記ビットストリームに書き込むステップであって、前記ビットストリームは、複数の相互運用点を含み、前記１つの相互運用点は、前記複数の相互運用点の第１のサブセットに含まれ、
   複数のＨＲＤ（仮想参照デコーダ）制約条件を前記ビットストリームにおいて規定するステップであって、前記ＨＲＤ制約条件の各々は、少なくともバッファ・サイズ、ビットレート、初期の符号化されたピクチャーのバッファ除去遅延、およびピクチャーのタイミング情報によって規定され、
   前記複数の相互運用点の前記第１のサブセットについて前記複数のＨＲＤ制約条件のうちの第１のＨＲＤ制約条件が前記ビットストリームにおいて規定されている、前記方法。
7. 前記複数の相互運用点の第２のサブセットについて前記複数のＨＲＤ制約条件のうちの第２のＨＲＤ制約条件が前記ビットストリームにおいて規定されている、請求項６に記載の方法。
8. 前記複数の相互運用点の各々について前記複数のＨＤＲ制約条件のうちの１つのＨＲＤ制約条件が前記ビットストリームにおいて規定され、前記複数の相互運用点の第１のサブセットは、個々の相互運用点のうちの一つに対応する、請求項６に記載の方法。
9. 個々のビューの各々について前記複数のＨＤＲ制約条件のうちの１つのＨＲＤ制約条件が前記ビットストリームにおいて規定され、一つを超えるビューを有する１つの相互運用点について１つのＨＲＤ制約条件を決定するために個々のビューについて前記複数のＨＲＤ制約条件が使用され、前記複数の相互運用点の前記第１のサブセットは、前記個々のビューのうちの一つに対応する、請求項６に記載の方法。
10. 前記複数の相互運用点の前記第１のサブセットについて最悪ケースのＨＲＤ制約条件がビットストリームにおいて規定され、前記最悪ケースのＨＲＤ制約条件は、前記複数の相互運用点の前記第１のサブセットに対して必要な最大のバッファ・サイズ、最長遅延、最高ビットレート、および最多ビット消費のうちの少なくとも一つによって規定され、前記複数の前記相互運用点の前記第１のサブセットは、同一の数のビューを有する、請求項６に記載の方法。
11. マルチビュー・ビデオのためのデータを送信する方法であって、
    ビットストリーム内の１つの相互運用点に関連付けられた１つ以上のビューのビュー情報を送信するステップであって、前記ビットストリームは、複数の相互運用点を含み、前記１つの相互運用点は、前記複数の相互運用点の第１のサブセットに含まれ、前記ビュー情報は、前記１つの相互運用点に関連付けられたビューの数および前記１つ以上のビューの各々に対するビュー識別子を示し、前記１つの相互運用点は、前記１つ以上のビューに対応する、前記送信するステップと、
    複数のＨＲＤ（仮想参照デコーダ）制約条件を送信するステップであって、前記複数のＨＲＤ制約条件の各々は、少なくともバッファ・サイズ、ビットレート、初期の符号化されたピクチャーのバッファ除去遅延、およびピクチャーのタイミング情報によって規定される、前記送信するステップと、を含み、
    前記複数の相互運用点の前記第１のサブセットについて前記複数のＨＲＤ制約条件のうちの第１のＨＲＤ制約条件が送信される、前記方法。
12. 前記複数の相互運用点の第２のサブセットについて前記複数のＨＲＤ制約条件のうちの第２のＨＲＤ制約条件が前記ビットストリームにおいて規定されている、請求項１１に記載の方法。
13. 前記複数の相互運用点の各々について前記複数のＨＤＲ制約条件のうちの１つのＨＲＤ制約条件が前記ビットストリームにおいて規定され、前記複数の相互運用点の前記第１のサブセットは、複数の相互運用点のうちの一つに対応する、請求項１１に記載の方法。
14. 個々のビューの各々について前記複数のＨＤＲ制約条件のうちの１つのＨＲＤ制約条件が前記ビットストリームにおいて規定され、一つを超えるビューを有する１つの相互運用点について１つのＨＲＤ制約条件を決定するために個々のビューについて前記複数のＨＲＤ制約条件が使用され、前記複数の相互運用点の前記第１のサブセットは、前記個々のビューのうちの一つに対応する、請求項１１に記載の方法。
15. 前記複数の相互運用点の前記第１のサブセットについて最悪ケースのＨＲＤ制約条件がビットストリームにおいて規定され、前記最悪ケースのＨＲＤ制約条件は、前記複数の相互運用点の前記第１のサブセットに対して必要な最大のバッファ・サイズ、最長遅延、最高ビットレート、および最多ビット消費のうちの少なくとも一つによって規定され、前記複数の前記相互運用点の前記第１のサブセットは、同一の数のビューを有する、請求項１１に記載の方法。
16. 請求項１〜１５のいずれか１項に記載の方法を実行するように構成された一つ以上のプロセッサを含む装置。
17. 請求項１〜１５のいずれか１項に記載の方法を実行する命令を記憶した非一時的コンピュータ読み取り可能媒体。