(57)【要約】  多視点映像を符号化する画像符号化方法であって、テーブル（Ｔ１）を用いて、符号化処理のレベルを示すレベル信号（１２６）から、最大画面内画素数（１２７）と、非多視点符号化における参照候補画像の最大枚数である最大バッファサイズ（１２８）とを決定する決定ステップ（Ｓ１０１）と、前記最大画面内画素数（１２７）と、入力画像の画像サイズ（１２５）と、多視点映像符号化のスケールファクタとを用いて、ビュー間予測符号化に用いられる参照候補ビューの最大枚数である最大ビュー数（１２９）を算出する第１算出ステップ（Ｓ１０２）と、前記最大ビュー数（１２９）と、前記最大バッファサイズ（１２８）とを用いて、多視点映像符号化における参照候補画像の最大枚数であるＭＶＣ最大バッファサイズ（１３０）を算出する第２算出ステップ（Ｓ１０３）とを含む。
2014010192.tif 000002
【特許請求の範囲】
【請求項１】
多視点映像を符号化する画像符号化方法であって、
符号化処理のレベルと、画像符号化装置及び画像復号装置が処理可能な最大の画像の画素数を示す最大画面内画素数及び非多視点符号化における参照候補画像の最大枚数との関係を示すテーブルを用いて、前記符号化処理のレベルを示すレベル信号から、最大画面内画素数と、非多視点符号化における参照候補画像の最大枚数とを決定する決定ステップと、
前記最大画面内画素数と、入力画像の画像サイズと、多視点映像符号化のスケールファクタとを用いて、ビュー間予測符号化に用いられる参照候補ビューの最大枚数を算出する第１算出ステップと、
前記参照候補ビューの最大枚数と、前記非多視点符号化における参照候補画像の最大枚数とを用いて、多視点映像符号化における参照候補画像の最大枚数を算出する第２算出ステップとを含む
画像符号化方法。
【請求項２】
前記第１算出ステップでは、以下の数式を用いて、前記参照候補ビューの最大枚数を算出し、
ＭａｘＶｉｅｗ＝Ｆｌｏｏｒ（ｍｖｃＳｃａｌｅＦａｃｔｏｒ  ＊  ＭａｘＬｕｍａＦＳ  ／  （ＰｉｃＨｅｉｇｈｔ  ＊  ＰｉｃＷｉｄｔｈ））
ＭａｘＶｉｅｗは、前記参照候補ビューであり、
ｍｖｃＳｃａｌｅＦａｃｔｏｒは、前記スケールファクタであり、
ＭａｘＬｕｍａＦｓは、前記最大画面内画素数である
請求項１記載の画像符号化方法。
【請求項３】
前記第２算出ステップでは、以下の数式を用いて、前記多視点映像符号化における参照候補画像の最大枚数を算出し、
ＭｖｃＭａｘＤＰＢＳｉｚｅ  ＝  ＭａｘＶｉｅｗ  ＊  ＭａｘＤＰＢＳｉｚｅ
ＭｖｃＭａｘＤＰＢＳｉｚｅは、前記多視点映像符号化における参照候補画像の最大枚数であり、
ＭａｘＤＰＢＳｉｚｅは、前記非多視点符号化における参照候補画像の最大枚数である
請求項２記載の画像符号化方法。
【請求項４】
前記画像符号化方法は、さらに、
前記多視点映像符号化における参照候補画像の最大枚数を越えない範囲で、デコードピクチャバッファで使用される前記多視点映像符号化における参照候補画像の枚数を設定する設定ステップを含む
請求項１〜３のいずれか１項に記載の画像符号化方法。
【請求項５】
多視点映像符号化されたデータを復号する画像復号方法であって、
前記データから、多視点映像符号化における参照候補画像の枚数と、画像サイズとを取得する取得ステップと、
デコードピクチャバッファに、前記画像サイズのピクチャ領域を前記多視点映像符号化における参照候補画像の枚数確保するステップとを含む
画像復号方法。
【請求項６】
前記データに含まれる前記多視点映像符号化における参照候補画像の枚数は、
符号化処理のレベルと、画像符号化装置及び画像復号装置が処理可能な最大の画像の画素数を示す最大画面内画素数及び非多視点符号化における参照候補画像の最大枚数との関係を示すテーブルを用いて、前記符号化処理のレベルを示すレベル信号から、最大画面内画素数と、非多視点符号化における参照候補画像の最大枚数とを決定する決定ステップと、
前記最大画面内画素数と、入力画像の画像サイズと、多視点映像符号化のスケールファクタとを用いて、ビュー間予測符号化に用いられる参照候補ビューの最大枚数を算出する第１算出ステップと、
前記参照候補ビューの最大枚数と、前記非多視点符号化における参照候補画像の最大枚数とを用いて、前記多視点映像符号化における参照候補画像の最大枚数を算出する第２算出ステップと、
前記多視点映像符号化における参照候補画像の最大枚数を越えない範囲で、デコードピクチャバッファで使用される前記多視点映像符号化における参照候補画像の枚数を設定する設定ステップとによって設定される
請求項５記載の画像復号方法。
【請求項７】
多視点映像を符号化する画像符号化装置であって、
処理回路と、
前記処理回路からアクセス可能な記憶装置とを備え、
前記処理回路は、前記記憶装置を用いて、
符号化処理のレベルと、画像符号化装置及び画像復号装置が処理可能な最大の画像の画素数を示す最大画面内画素数及び非多視点符号化における参照候補画像の最大枚数との関係を示すテーブルを用いて、前記符号化処理のレベルを示すレベル信号から、最大画面内画素数と、非多視点符号化における参照候補画像の最大枚数とを決定する決定ステップと、
前記最大画面内画素数と、入力画像の画像サイズと、多視点映像符号化のスケールファクタとを用いて、ビュー間予測符号化に用いられる参照候補ビューの最大枚数を算出する第１算出ステップと、
前記参照候補ビューの最大枚数と、前記非多視点符号化における参照候補画像の最大枚数とを用いて、多視点映像符号化における参照候補画像の最大枚数を算出する第２算出ステップとを実行する
画像符号化装置。
【請求項８】
多視点映像符号化されたデータを復号する画像復号装置であって、
処理回路と、
前記処理回路からアクセス可能な記憶装置とを備え、
前記処理回路は、前記記憶装置を用いて、
前記データから、多視点映像符号化における参照候補画像の枚数と、画像サイズとを取得する取得ステップと、
デコードピクチャバッファに、前記画像サイズのピクチャ領域を前記多視点映像符号化における参照候補画像の枚数確保するステップとを実行する
画像復号装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像符号化方法及び画像復号方法に関する。
【背景技術】
【０００２】
動画像は複数のピクチャから構成されており、各ピクチャは所定数の画素からなる。動画像の符号化はピクチャ毎に行われ、各ピクチャの符号化は、ピクチャを区分するブロックを単位として行われる。【０００３】
一般に動画像の符号化では、時間方向及び空間方向の冗長性を削減することによって情報量の圧縮を行う。【０００４】
時間的な冗長性の削減を目的とするピクチャ間予測符号化では、符号化対象ピクチャに対する動きの検出及び動き補償を、時間的に符号化対象ピクチャの前方又は後方に位置するピクチャを参照してブロック単位で行うことにより予測情報を生成し、予測情報と符号化対象ピクチャの情報との差分を符号化する。ここで、符号化対象ピクチャに対して時間的に前方に位置するピクチャは、符号化対象ピクチャより表示時間が早いピクチャ（前方ピクチャ）であり、符号化対象ピクチャに対して時間的に後方に位置するピクチャは、符号化対象ピクチャにより表示時間が遅いピクチャ（後方ピクチャ）である。【０００５】
画像符号化方法（動画像符号化方法）の一つであり、ＩＳＯ／ＩＥＣ  １４４９６−１０  Ａｄｖａｎｃｅｄ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ（ＡＶＣ）で規定されるＭＰＥＧ−４  ＡＶＣ／Ｈ．２６４方式（以降、Ｈ．２６４方式と呼ぶ）では、符号化の対象となる符号化対象ピクチャに対して時間的に前方又は後方にある任意の２枚のピクチャを同時に参照して、符号化対象ピクチャに対する動き補償を行うことが可能である（例えば、非特許文献１参照）。そのため、Ｈ．２６４方式では、ピクチャ間予測符号化及びピクチャ間予測復号を行う場合、参照される可能性のある前方及び後方のピクチャ（以降、参照候補ピクチャと呼ぶ）を全てピクチャメモリに蓄積しておく必要がある。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】ＩＳＯ／ＩＥＣ  １４４９６−１０  「ＭＰＥＧ−４  Ｐａｒｔ１０  Ａｄｖａｎｃｅｄ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ」
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、このような画像符号化方法及び画像復号方法では、ピクチャメモリのメモリ領域を効率的に利用できることが望まれている。また、多視点映像符号化（ＭＶＣ：Ｍｕｌｔｉｖｉｅｗ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ）では、ビュー間参照が行われるため、このピクチャメモリの制御がより複雑化する。【０００８】
そこで、本発明は、多視点映像符号化又は多視点映像復号を行う画像符号化方法又は画像復号方法であって、メモリ領域を効率的に利用することができる画像符号化方法又は画像復号方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の一態様に係る画像符号化方法は、多視点映像を符号化する画像符号化方法であって、符号化処理のレベルと、画像符号化装置及び画像復号装置が処理可能な最大の画像の画素数を示す最大画面内画素数及び非多視点符号化における参照候補画像の最大枚数との関係を示すテーブルを用いて、前記符号化処理のレベルを示すレベル信号から、最大画面内画素数と、非多視点符号化における参照候補画像の最大枚数とを決定する決定ステップと、前記最大画面内画素数と、入力画像の画像サイズと、多視点映像符号化のスケールファクタとを用いて、ビュー間予測符号化に用いられる参照候補ビューの最大枚数を算出する第１算出ステップと、前記参照候補ビューの最大枚数と、前記非多視点符号化における参照候補画像の最大枚数とを用いて、多視点映像符号化における参照候補画像の最大枚数を算出する第２算出ステップとを含む。【００１０】
なお、これらの全般的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ−ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラム及び記録媒体の任意な組み合わせで実現されてもよい。
【発明の効果】
【００１１】
本発明は、多視点映像符号化又は多視点映像復号を行う画像符号化方法又は画像復号方法であって、メモリ領域を効率的に利用することができる画像符号化方法又は画像復号方法を提供できる。
【図面の簡単な説明】
【００１２】
【図１】図１は、ピクチャメモリの管理を説明するための図である。
【図２】図２は、レベル識別子と、最大画面内画素数及び最大バッファサイズとの対応関係を示すテーブルの一例を示す図である。
【図３】図３は、実施の形態１に係る画像符号化装置のブロック図である。
【図４】図４は、実施の形態１に係るＭＶＣエンコーダのブロック図である。
【図５】図５は、実施の形態１に係る各ビューの入力画像の一例を示す図である。
【図６】図６は、実施の形態１に係る、多視点映像符号化に対応したピクチャメモリの管理を説明するための図である。
【図７】図７は、実施の形態１に係る画像符号化処理のフローチャートである。
【図８】図８は、実施の形態１に係る、レベル識別子と、最大画面内画素数、最大バッファサイズ及びスケールファクタとの対応関係を示すテーブルの一例を示す図である。
【図９】図９は、実施の形態２に係る画像復号装置のブロック図である。
【図１０】図１０は、実施の形態２に係る画像復号処理のフローチャートである。
【図１１】図１１は、コンテンツ配信サービスを実現するコンテンツ供給システムの全体構成図である。
【図１２】図１２は、デジタル放送用システムの全体構成図である。
【図１３】図１３は、テレビの構成例を示すブロック図である。
【図１４】図１４は、光ディスクである記録メディアに情報の読み書きを行う情報再生／記録部の構成例を示すブロック図である。
【図１５】図１５は、光ディスクである記録メディアの構造例を示す図である。
【図１６Ａ】図１６Ａは、携帯電話の一例を示す図である。
【図１６Ｂ】図１６Ｂは、携帯電話の構成例を示すブロック図である。
【図１７】図１７は、多重化データの構成を示す図である。
【図１８】図１８は、各ストリームが多重化データにおいてどのように多重化されているかを模式的に示す図である。
【図１９】図１９は、ＰＥＳパケット列に、ビデオストリームがどのように格納されるかを更に詳しく示した図である。
【図２０】図２０は、多重化データにおけるＴＳパケットとソースパケットの構造を示す図である。
【図２１】図２１は、ＰＭＴのデータ構成を示す図である。
【図２２】図２２は、多重化データ情報の内部構成を示す図である。
【図２３】図２３は、ストリーム属性情報の内部構成を示す図である。
【図２４】図２４は、映像データを識別するステップを示す図である。
【図２５】図２５は、各実施の形態の動画像符号化方法および動画像復号化方法を実現する集積回路の構成例を示すブロック図である。
【図２６】図２６は、駆動周波数を切り替える構成を示す図である。
【図２７】図２７は、映像データを識別し、駆動周波数を切り替えるステップを示す図である。
【図２８】図２８は、映像データの規格と駆動周波数を対応づけたルックアップテーブルの一例を示す図である。
【図２９Ａ】図２９Ａは、信号処理部のモジュールを共有化する構成の一例を示す図である。
【図２９Ｂ】図２９Ｂは、信号処理部のモジュールを共有化する構成の他の一例を示す図である。
【発明を実施するための形態】
【００１３】
（本発明の基礎となった知見）
本発明者は、「背景技術」の欄において記載した、画像符号化方法及画像復号方法に関し、以下の問題が生じることを見出した。
【００１４】
Ｈ．２６４方式では、ピクチャ間予測符号化又はピクチャ間予測復号の際に参照されるピクチャ（参照ピクチャ）は、符号化又は復号の処理対象となる対象ピクチャのブロック毎に、ピクチャメモリに蓄積されている複数の処理済みのピクチャから選択される。例えば、対象ピクチャが、最大２枚のピクチャを参照可能なＢピクチャである場合は、ピクチャメモリに蓄積されている複数の処理済みのピクチャのうちから選択された最大２枚のピクチャが参照ピクチャとして用いられる。また、対象ピクチャが、１枚のピクチャのみ参照可能なＰピクチャである場合は、ピクチャメモリに蓄積されている複数の処理済みのピクチャのうちから選択された１枚のピクチャが参照ピクチャとして用いられる。
【００１５】
すなわち、Ｈ．２６４方式では、参照ピクチャの候補である参照候補ピクチャは、対象ピクチャがＰピクチャである場合もＢピクチャである場合も、ピクチャメモリに画像データが蓄積されている複数の処理済みのピクチャである。ここで、対象ピクチャのブロック毎に参照ピクチャは選択されるので、ピクチャ単位で考えると、参照ピクチャの枚数はＰピクチャ及びＢピクチャにかかわらず相当な数になる可能性がある。言い換えると、対象ピクチャに対する参照ピクチャの最大枚数は、対象ピクチャに対する参照候補ピクチャの数と等しい。
【００１６】
図１は、Ｈ．２６４方式に対応した具体的なピクチャメモリの管理を説明するための図である。この例では、ピクチャメモリに蓄積可能なピクチャの枚数は４である。つまり、参照される可能性のある参照候補ピクチャは、この４枚のピクチャから、処理対象である１枚のピクチャを除いた３枚のピクチャである。
【００１７】
例えば、図１に示すように、処理対象ピクチャであるピクチャＰ５を、ピクチャ間予測符号化又はピクチャ間予測復号する場合、参照候補ピクチャは、ピクチャメモリに画像データが蓄積されているピクチャＰ２〜Ｐ４である。ここで、ピクチャＰ１〜Ｐ５は、符号化順（復号順）に配列されており、各ピクチャＰ１〜Ｐ５は、この順に符号化又は復号される。
【００１８】
また、画像復号装置では、復号済みピクチャが、対象ピクチャに対するピクチャ間予測復号の際に参照される参照候補ピクチャ以外の復号済みピクチャ（つまり参照ピクチャとして用いられない復号済みピクチャ）であっても、その表示の順番が廻って来るまでは、表示待ちピクチャとしてその画像データをピクチャメモリに蓄積しておく必要がある。すなわち、ピクチャメモリ管理においては、表示待ちピクチャを考慮する必要があり、ピクチャメモリの記憶領域から、表示待ちピクチャの枚数分の領域を差し引いた領域が、参照候補ピクチャが利用可能な領域となる。ただし、以降の説明では、説明の便宜上、表示待ちピクチャが存在しないイントラピクチャ及びＰピクチャのみからなるビットストリーム（ＩＰＰＰＩＰＰＰＩＰＰＰ・・・など）を前提とする。これにより、表示待ちピクチャを考慮する必要がなくなる。ただし、後に説明する本実施の形態は表示待ちピクチャを含む場合にも適用可能であり、表示待ちピクチャを考慮していない記載から、本実施の形態が表示待ちピクチャを含まない場合に限定されていると解釈されてはならない。
【００１９】
以上の説明のように、各ブロックの符号化又は復号において参照されるピクチャ（参照ピクチャ）は、高々１枚又は２枚である。しかしながら、符号化対象ピクチャ内のブロック毎に、参照するピクチャが異なるため、符号化対象ピクチャ内のブロックが参照する可能性のある全ての復号済みピクチャ（参照候補ピクチャ）をピクチャメモリに蓄積しておく必要が生じる。
【００２０】
なお、画像符号化装置で参照候補ピクチャの数を自由に設定できるようにすると、画像復号装置に搭載すべきピクチャメモリの記憶領域の容量を決めることができない。そこで、Ｈ．２６４方式では、符号化レベルに応じて、ピクチャ間予測符号化及びピクチャ間予測復号の際に用いられる参照候補ピクチャの最大枚数に対する制限を設けている。これにより、画像復号装置は、当該画像復号装置に搭載すべきピクチャメモリの記憶領域の容量を予め知ることができる。
【００２１】
具体的には、符号化レベルに応じて、予め必要な記憶領域の容量（搭載すべきピクチャメモリの記憶容量）の値（ＭａｘＤｐｂＭｂｓ）が規格書で決められている。ここで、具体的には、ＭａｘＤｐｂＭｂｓは、予め必要な記憶領域の容量を、ブロック（マクロブロック）の数で表す。特定の符号化レベルに対応する画像復号装置（特定の符号化レベルを満たして符号化されたビットストリームを復号できる画像復号装置）は、規格書で指定された記憶容量を持つピクチャメモリを搭載していなければならない。規格書で指定された記憶容量のピクチャメモリを画像復号装置に搭載することにより、画像復号装置が、その符号化レベルに属する符号化データを破たんすることなく復号できることが保障される。つまり、Ｈ．２６４方式に対応した画像復号装置には、ＭａｘＤｐｂＭｂｓで指定される個数のブロック（マクロブロック）を蓄積できる容量のピクチャメモリが搭載される。
【００２２】
なお、Ｈ．２６４方式では、参照候補ピクチャの最大枚数（ＭａｘＤｐｂＦｒａｍｅｓ）は、以下の数式（式１）を用いて算出される。
【００２３】
ＭａｘＤｐｂＦｒａｍｅｓ  ＝  Ｍｉｎ（ＭａｘＤｐｂＭｂｓ  ／  （ＰｉｃＷｉｄｔｈＩｎＭｂｓ  ＊  ＦｒａｍｅＨｅｉｇｈｔＩｎＭｂｓ），  １６）      （式１）
【００２４】
ここで、ＰｉｃＷｉｄｔｈＩｎＭｂｓ、及びＦｒａｍｅＨｅｉｇｈｔＩｎＭｂｓは、符号化対象ピクチャの幅と高さをそれぞれマクロブロックの個数で示した値である。数式（式１）から明らかなように、ＭａｘＤｐｂＦｒａｍｅｓの上限値は１６で制限されているが、ＭａｘＤｐｂＦｒａｍｅｓの値は符号化対象ピクチャのサイズによって可変である。例えば、符号化対象ピクチャのサイズが大きければＭａｘＤｐｂＦｒａｍｅｓの値は小さい値となり、反対に、符号化対象ピクチャのサイズが小さければＭａｘＤｐｂＦｒａｍｅｓの値は大きい値となる。
【００２５】
Ｈ．２６４方式の画像符号化装置は、参照候補ピクチャの最大枚数（ＭａｘＤｐｂＦｒａｍｅｓ）を越えない範囲でピクチャ間予測符号化を行い、実際に符号化に用いられる参照候補ビクチャの枚数（ｍａｘ＿ｄｅｃ＿ｆｒａｍｅ＿ｂｕｆｆｅｒｉｎｇ）を符号化データに含めて画像復号装置に通知する。画像復号装置には、ＭａｘＤｐｂＭｂｓで指定される記憶容量を持つピクチャメモリが搭載されており、画像復号装置は、符号化データのピクチャサイズの領域（ピクチャバッファ）を、符号化データに含まれるｍａｘ＿ｄｅｃ＿ｆｒａｍｅ＿ｂｕｆｆｅｒｉｎｇ（≦ＭａｘＤｐｂＦｒａｍｅｓ）で示される枚数分だけ、その符号化データの復号処理のために確保する。
【００２６】
画像復号装置はハードウェアで実現されることがあるため、画像復号装置に搭載すべきピクチャメモリの記憶容量は予め決定されていなければならない。Ｈ．２６４方式では、参照候補ピクチャの最大枚数（ＭａｘＤｐｂＦｒａｍｅｓ）を、符号化データのピクチャサイズに応じた可変値とすることにより、メモリ領域を効率的に利用し、高画質符号化をはかることができる。
【００２７】
一方、現在標準化が進められている画像符号化方法であるＨｉｇｈ  Ｅｆｆｉｃｉｅｎｃｙ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ（以降、ＨＥＶＣ方式）においても、画像復号装置に搭載すべきピクチャメモリの記憶容量は予め決定されている。しかしながら、参照候補ピクチャの最大枚数（最大バッファサイズ：ＭａｘＤｐｂＳｉｚｅ）が固定されているので、符号化データのピクチャサイズに応じて、メモリ領域を効率的に利用することができない。
【００２８】
以下、課題について具体的に説明する。図２は、レベル識別子の値と、最大画面内画素数（ＭａｘＬｕｍａＦＳ）及び参照候補ピクチャの最大枚数（最大バッファサイズ：ＭａｘＤｐｂＳｉｚｅ）との対応関係を示すテーブルＴ１である。
【００２９】
レベル識別子で特定される各符号化レベルに対しては、固有の最大画面内画素数（ＭａｘＬｕｍａＦＳ）及び最大バッファサイズ（ＭａｘＤＰＢＳｉｚｅ）が設定されている。例えば、テーブルＴ１には、１２個の符号化レベルが示されており、各符号化レベルは、レベル識別子の値（１）〜（６）に対応している。また、レベル識別子の値（１）〜（６）はそれぞれ、最大画面内画素数（ＭａｘＬｕｍａＦＳ）の具体的数値及び最大バッファサイズ（ＭａｘＤＰＢＳｉｚｅ）の具体的数値に対応付けられている。
【００３０】
また、最大画面内画素数（ＭａｘＬｕｍａＦＳ）は、この画像符号化装置にて符号化可能であり、かつ符号化データを復号する画像復号装置にて復号可能である最大の入力画像（動画像）のサイズを示す。つまり、最大画面内画素数は、入力画像の縦画素数（ｈ）と横画素数（ｗ）との積の値の取り得る最大値を示す。
【００３１】
符号化レベルに応じて、最大蓄積画素数（画像復号装置に搭載すべきピクチャメモリの記憶容量）の値は、以下の数式（式２）で算出することができる。
【００３２】
最大蓄積画素数  ＝  ＭａｘＤｐｂＳｉｚｅ  ＊  ＭａｘＬｕｍａＦＳ        （式２）
【００３３】
したがって、Ｈ．２６４方式と同様に、符号化レベルに応じて、搭載すべきピクチャメモリの記憶容量は規定されており、画像復号装置は、当該画像復号装置に搭載すべきピクチャメモリの記憶領域の容量を予め知ることができる。しかしながら、Ｈ．２６４方式とは異なり、参照候補ピクチャの最大枚数（ＭａｘＤｐｂＳｉｚｅ）は、テーブルＴ１で固定値（６）として規定されているため、メモリ領域を効率的に利用することができない。
【００３４】
そして、多視点映像符号化（ＭＶＣ：Ｍｕｌｔｉｖｉｅｗ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ）を行う場合に、非効率的なメモリ管理の影響はより顕著になる。
【００３５】
以下の実施の形態では、特に多視点映像符号化（ＭＶＣ）を行う場合に、符号化データのピクチャサイズに応じて、メモリ領域を効率的に利用することを可能とする画像符号化方法及び画像復号方法について説明する。また、符号化データのピクチャサイズに応じて、メモリ領域を効率的に利用する画像符号化装置及び画像復号装置について説明する。
【００３６】
本発明の一態様に係る画像符号化方法は、多視点映像を符号化する画像符号化方法であって、符号化処理のレベルと、画像符号化装置及び画像復号装置が処理可能な最大の画像の画素数を示す最大画面内画素数及び非多視点符号化における参照候補画像の最大枚数との関係を示すテーブルを用いて、前記符号化処理のレベルを示すレベル信号から、最大画面内画素数と、非多視点符号化における参照候補画像の最大枚数とを決定する決定ステップと、前記最大画面内画素数と、入力画像の画像サイズと、多視点映像符号化のスケールファクタとを用いて、ビュー間予測符号化に用いられる参照候補ビューの最大枚数を算出する第１算出ステップと、前記参照候補ビューの最大枚数と、前記非多視点符号化における参照候補画像の最大枚数とを用いて、多視点映像符号化における参照候補画像の最大枚数を算出する第２算出ステップとを含む。
【００３７】
これによれば、当該画像符号化方法は、多視点映像符号化における参照候補ピクチャ（参照候補ビュー）の最大枚数を適切に算出することができる。また、当該画像符号化方法は、入力画像の画像サイズに応じて、ピクチャ間予測の参照候補ピクチャの枚数、又はビュー間予測の参照候補ビューの枚数を可変にできる。これにより、当該画像符号化方法は、メモリ領域を効率的に利用することができる。
【００３８】
例えば、前記第１算出ステップでは、以下の数式を用いて、前記参照候補ビューの最大枚数を算出し、
ＭａｘＶｉｅｗ＝Ｆｌｏｏｒ（ｍｖｃＳｃａｌｅＦａｃｔｏｒ  ＊  ＭａｘＬｕｍａＦＳ  ／  （ＰｉｃＨｅｉｇｈｔ  ＊  ＰｉｃＷｉｄｔｈ））
ＭａｘＶｉｅｗは、前記参照候補ビューであり、ｍｖｃＳｃａｌｅＦａｃｔｏｒは、前記スケールファクタであり、ＭａｘＬｕｍａＦｓは、前記最大画面内画素数であってもよい。
【００３９】
これによれば、当該画像符号化方法は、参照候補ビューの最大枚数を適切に算出することができる。
【００４０】
例えば、前記第２算出ステップでは、以下の数式を用いて、前記多視点映像符号化における参照候補画像の最大枚数を算出し、
ＭｖｃＭａｘＤＰＢＳｉｚｅ  ＝  ＭａｘＶｉｅｗ  ＊  ＭａｘＤＰＢＳｉｚｅ
ＭｖｃＭａｘＤＰＢＳｉｚｅは、前記多視点映像符号化における参照候補画像の最大枚数であり、ＭａｘＤＰＢＳｉｚｅは、前記非多視点符号化における参照候補画像の最大枚数であってもよい。
【００４１】
これによれば、当該画像符号化方法は、多視点映像符号化における参照候補画像の最大枚数を適切に算出することができる。
【００４２】
例えば、前記画像符号化方法は、さらに、前記多視点映像符号化における参照候補画像の最大枚数を越えない範囲で、デコードピクチャバッファで使用される前記多視点映像符号化における参照候補画像の枚数を設定する設定ステップを含んでもよい。
【００４３】
これによれば、当該画像符号化方法は、多視点映像符号化における参照候補画像の枚数を適切に設定することができる。
【００４４】
また、本発明の一態様に係る画像復号方法は、多視点映像符号化されたデータを復号する画像復号方法であって、前記データから、多視点映像符号化における参照候補画像の枚数と、画像サイズとを取得する取得ステップと、デコードピクチャバッファに、前記画像サイズのピクチャ領域を前記多視点映像符号化における参照候補画像の枚数確保するステップとを含む。
【００４５】
これによれば、当該画像復号方法は、メモリ領域を効率的に利用することができる。
【００４６】
例えば、前記データに含まれる前記多視点映像符号化における参照候補画像の枚数は、符号化処理のレベルと、画像符号化装置及び画像復号装置が処理可能な最大の画像の画素数を示す最大画面内画素数及び非多視点符号化における参照候補画像の最大枚数との関係を示すテーブルを用いて、前記符号化処理のレベルを示すレベル信号から、最大画面内画素数と、非多視点符号化における参照候補画像の最大枚数とを決定する決定ステップと、前記最大画面内画素数と、入力画像の画像サイズと、多視点映像符号化のスケールファクタとを用いて、ビュー間予測符号化に用いられる参照候補ビューの最大枚数を算出する第１算出ステップと、前記参照候補ビューの最大枚数と、前記非多視点符号化における参照候補画像の最大枚数とを用いて、前記多視点映像符号化における参照候補画像の最大枚数を算出する第２算出ステップと、前記多視点映像符号化における参照候補画像の最大枚数を越えない範囲で、デコードピクチャバッファで使用される前記多視点映像符号化における参照候補画像の枚数を設定する設定ステップとによって設定されてもよい。
【００４７】
これによれば、当該画像復号方法は、ビュー間予測の参照候補ビューの枚数が適切に設定されたデータを復号できる。
【００４８】
また、本発明の一態様に係る画像符号化装置は、多視点映像を符号化する画像符号化装置であって、処理回路と、前記処理回路からアクセス可能な記憶装置とを備え、前記処理回路は、前記記憶装置を用いて、符号化処理のレベルと、画像符号化装置及び画像復号装置が処理可能な最大の画像の画素数を示す最大画面内画素数及び非多視点符号化における参照候補画像の最大枚数との関係を示すテーブルを用いて、前記符号化処理のレベルを示すレベル信号から、最大画面内画素数と、非多視点符号化における参照候補画像の最大枚数とを決定する決定ステップと、前記最大画面内画素数と、入力画像の画像サイズと、多視点映像符号化のスケールファクタとを用いて、ビュー間予測符号化に用いられる参照候補ビューの最大枚数を算出する第１算出ステップと、前記参照候補ビューの最大枚数と、前記非多視点符号化における参照候補画像の最大枚数とを用いて、多視点映像符号化における参照候補画像の最大枚数を算出する第２算出ステップとを実行する。
【００４９】
これによれば、当該画像符号化装置は、多視点映像符号化における参照候補ピクチャ（参照候補ビュー）の最大枚数を適切に算出することができる。また、当該画像符号化装置は、入力画像の画像サイズに応じて、ピクチャ間予測の参照候補ピクチャの枚数、又はビュー間予測の参照候補ビューの枚数を可変にできる。これにより、当該画像符号化装置は、メモリ領域を効率的に利用することができる。
【００５０】
また、本発明の一態様に係る画像復号装置は、多視点映像符号化されたデータを復号する画像復号装置であって、処理回路と、前記処理回路からアクセス可能な記憶装置とを備え、前記処理回路は、前記記憶装置を用いて、前記データから、多視点映像符号化における参照候補画像の枚数と、画像サイズとを取得する取得ステップと、デコードピクチャバッファに、前記画像サイズのピクチャ領域を前記多視点映像符号化における参照候補画像の枚数確保するステップとを実行する。
【００５１】
これによれば、当該画像復号装置は、メモリ領域を効率的に利用することができる。
【００５２】
また、本発明の一態様に係る画像符号化復号装置は、前記画像符号化装置と、前記画像復号装置とを備えてもよい。
【００５３】
なお、これらの全般的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ−ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラム及び記録媒体の任意な組み合わせで実現されてもよい。
【００５４】
以下、本発明の実施の形態について、図面を参照しながら説明する。
【００５５】
なお、以下で説明する実施の形態は、いずれも本発明の一具体例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。
【００５６】
（実施の形態１）
図３は、本実施の形態に係る多視点映像符号化（ＭＶＣ）エンコーダを備えた画像符号化装置（動画像符号化装置）の構成を示すブロック図である。
【００５７】
図３に示す画像符号化装置１００は、入力画像制御部１０１、ＭＶＣエンコーダ１０２、レベル解析部１０３、最大ビュー数算出器１０４、及びＭＶＣ最大バッファサイズ算出器１０５を備えている。
【００５８】
入力画像制御部１０１は、ピクチャ毎に入力される入力画像信号１２１をビュー毎に記憶し、記憶した拡張ビュー画像１２２及びベースビュー画像１２３を、ＭＶＣエンコーダ１０２内の各ビューの符号化を担当する符号化部に送信する。また、入力画像制御部１０１は、入力画像のサイズを示す情報（画像サイズ１２５）を最大ビュー数算出器１０４に出力する。この画像サイズ１２５は、入力画像の縦画素数を示す情報（ＰｉｃＨｅｉｇｈｔ）と、入力画像の横画素数を示す横画素数情報（ＰｉｃＷｉｄｔｈ）とを含む。
【００５９】
ＭＶＣエンコーダ１０２は、入力された拡張ビュー画像１２２及びベースビュー画像１２３を多視点映像符号化することでＭＶＣビットストリーム１２４を生成する。
【００６０】
レベル解析部１０３は、ユーザ操作により入力された、符号化処理のレベルを示すレベル識別子の信号（レベル信号１２６）に基づいて、符号化処理可能な最大の画面内の画素数を示す情報である最大画面内画素数１２７（ＭａｘＬｕｍａＦＳ）、及び、参照候補ピクチャの最大枚数を示す最大バッファサイズ１２８（ＭａｘＤｐｂＳｉｚｅ）を決定する。なお、このレベル解析部１０３は、図２に示すテーブルＴ１の情報を有している。
【００６１】
最大ビュー数算出器１０４は、レベル解析部１０３から出力された最大画面内画素数１２７と、入力画像制御部１０１から出力された画像サイズ１２５と、多視点映像符号化のスケールファクタ（ｍｖｃＳｃａｌｅＦａｃｔｏｒ）とに基づいて、最大ビュー数１２９（ＭａｘＶｉｅｗ）を算出する。なお、最大ビュー数算出器１０４は、予めｍｖｃＳｃａｌｅＦａｃｔｏｒの値を有している。つまり、スケールファクタは、予め定められた係数である。
【００６２】
ＭＶＣ最大バッファサイズ算出器１０５は、レベル解析部１０３から出力された最大バッファサイズ１２８（ＭａｘＤｐｂＳｉｚｅ）と、最大ビュー数算出器１０４から出力された最大ビュー数１２９（ＭａｘＶｉｅｗ）とに基づいて、多視点映像符号化における参照候補ピクチャの最大枚数を示すＭＶＣ最大バッファサイズ１３０（多視点映像符号化における最大バッファサイズ：ＭｖｃＭａｘＤｐｂＳｉｚｅ）を算出し、算出されたＭＶＣ最大バッファサイズ１３０をＭＶＣエンコーダ１０２へ出力する。ＭｖｃＭａｘＤｐｂＳｉｚｅは、あるビューの符号化対象ピクチャ（符号化対象ビュー）に対してピクチャ間予測符号化又はピクチャ間予測復号を行う場合に、ピクチャバッファ（デコードピクチャバッファ：ＤＰＢ）に蓄積されている復号済みピクチャの最大枚数を示す値である。
【００６３】
なお、最大ビュー数算出器１０４及びＭＶＣ最大バッファサイズ算出器１０５は、入力データに基づいて実際に数値計算することにより出力データを算出及び出力してもよいし、代表的な入力データの値と、それに対応する出力データの値との対応関係を示すテーブルを予め保持しており、入力データの値に基づき当該テーブルを参照し、出力データを取得してもよい。
【００６４】
次に、ＭＶＣエンコーダ１０２の内部構成について説明する。図４は、ＭＶＣエンコーダ１０２の構成を示すブロック図である。
【００６５】
ＭＶＣエンコーダ１０２は、図４に示すように、ベースビュー符号化部１４２、拡張ビュー符号化部１４１、及びビュー多重化部１４３を備えている。
【００６６】
ベースビュー符号化部１４２は、多視点映像符号化を行わない通常の画像符号化装置と同様の機能を有し、ベースビュー画像１２３を符号化することでベースビュー符号化信号１５３を生成する。また、ベースビュー符号化部１４２は、ベースビュー符号化部１４２の内部で符号化された後、復号されることにより得られたベースビューの再構築ビュー画像１５１を拡張ビュー符号化部１４１に出力する。
【００６７】
拡張ビュー符号化部１４１は、再構築ビュー画像１５１を用いて入力画像制御部１０１から出力される拡張ビュー画像１２２を符号化することで拡張ビュー符号化信号１５２を生成する。具体的には、拡張ビュー符号化部１４１は、符号化対象ピクチャ（符号化対象拡張ビュー画像）に対して、既に符号化した拡張ビュー画像の再構築画像を用いたピクチャ間予測符号化と、ベースビュー画像１２３の再構築画像（再構築ビュー画像１５１）を用いたビュー間予測符号化との一方をブロック毎に選択して、拡張ビュー画像１２２を符号化する。
【００６８】
ビュー多重化部１４３は、各ビュー、すなわち、ベースビューと拡張ビューの符号化情報であるベースビュー符号化信号１５３と拡張ビュー符号化信号１５２とを多重化することで、多視点映像符号化されたビットストリームであるＭＶＣビットストリーム１２４を生成する。
【００６９】
なお、図４に示すＭＶＣエンコーダ１０２は、例として、ベースビュー及び拡張ビューの２つのビューを符号化しているが、拡張ビュー符号化部１４１を多段に結合することにより、２以上の拡張ビューを含む多視点映像の符号化を実現することができる。
【００７０】
図５は、ＭＶＣエンコーダ１０２における各ビューの入力画像の一例を示す。この入力画像は、１つのベースビューと２つの拡張ビューとを含む。ベースビュー（Ｖｉｅｗ１）、拡張ビュー（Ｖｉｅｗ２、Ｖｉｅｗ３）の画像解像度は同一である。一般的に、各ビューはわずかに違う視点から同時刻に撮影された画像であり、互いに相関を有している。それゆえ、あるビューの符号化において、他のビューを予測画像として利用することができる。多視点映像符号化は、現在、立体画像（３Ｄ）の符号化方法として用いられている。
【００７１】
多視点映像符号化は、拡張ビューの符号化を行う際、他のビューの再構築画像を参照画像として用いてピクチャ間予測を行うことにより、符号化効率を向上できる。なお、拡張ビューを符号化する際、他のビューの再構築画像を用いることをビュー間参照（予測）と呼ぶ。多視点映像画像符号化においては、通常の画像符号化で用いられる時間方向のピクチャ間予測（インター予測）の参照画像として、他のビューの再構築画像が用いられる。ただし、符号化対象画像と時間的に異なる他のビューの再構築画像を参照画像として用いることはできない。なお、画像符号化装置におけるビュー間予測と時間方向のピクチャ間予測（インター予測）との違いは、参照画像が異なるビューのピクチャであるか、同じビューの時間的に異なるピクチャであるかの違いしかなく、本質的な符号化方法は同じである。
【００７２】
ビュー間予測が用いられる場合には、参照するビューが選択される。図５に示す点線矢印は、ビュー間予測、及びピクチャ間予測の参照先を示している。拡張ビュー（Ｖｉｅｗ２）のビュー間予測では、ベースビュー（Ｖｉｅｗ１）が参照される。一方で、拡張ビュー（Ｖｉｅｗ３）のビュー間予測では、拡張ビュー（Ｖｉｅｗ２）が参照される。なお、ビュー間予測を行うか否かは、ブロック単位で切り替えられる。また、ビュー間の参照関係（符号化順序）は決まっているが、時間が異なれば、ビュー間の参照関係は異なってもよい。つまり、同時刻のビューにおいて、拡張ビュー（Ｖｉｅｗ２）が拡張ビュー（Ｖｉｅｗ３）を参照し、拡張ビュー（Ｖｉｅｗ３）が拡張ビュー（Ｖｉｅｗ２）を参照することは許されないが、ある時刻では、拡張ビュー（Ｖｉｅｗ２）が拡張ビュー（Ｖｉｅｗ３）を参照し、別な時刻では、拡張ビュー（Ｖｉｅｗ３）が拡張ビュー（Ｖｉｅｗ２）を参照することは許される。
【００７３】
図６は、多視点映像符号化に対応した具体的なピクチャメモリの管理を説明するための図である。なお、図５で説明したように、ビューを符号化する際、本来であればピクチャ間予測も選択することができるが、図６では、説明の便宜上、ビュー間予測のみが選択される場合を示している。すなわち、ここでは、ＭＶＣエンコーダ１０２が、ビュー間予測のみ用いると仮定している。図６は、ピクチャメモリに画像データを蓄積可能なピクチャ（ビュー）の枚数が４である場合を示している。つまり、この場合、参照される可能性のある参照候補ビューは、上記４枚のピクチャ（ビュー）から、符号化処理対象となる１枚のピクチャ（ビュー）を除いた３枚のピクチャ（ビュー）となる。
【００７４】
例えば、図６に示すようにＶｉｅｗ５を処理対象ピクチャとしてビュー間予測符号化又はビュー間予測復号を行う場合、参照候補ビューは、ピクチャメモリに画像データが蓄積されているＶｉｅｗ２〜Ｖｉｅｗ４である。
【００７５】
このように、符号化対象ピクチャ内のブロックごとに、参照するビューが異なるため、符号化対象ピクチャ内のブロックが参照する可能性のある全ての復号済みビュー（参照候補ビュー）をピクチャメモリに蓄積しておく必要が生じる。なお、参照候補ビューとは、当然ながらビュー間の参照関係に従い、符号化対象ピクチャが参照可能なビューでなければならない。
【００７６】
なお、画像符号化装置で参照候補ビューの数を自由に設定できるようにすると、画像復号装置に搭載すべきピクチャメモリの記憶領域の容量を決めることができない。そこで、ビュー間予測符号化及びビュー間予測復号の際に用いられる参照候補ビューの最大枚数（ＭａｘＶｉｅｗ）に対する制限を設ける必要がある。参照候補ビューの最大枚数（ＭａｘＶｉｅｗ）として、予め決められた所定の値を用いることが考えられる。しかしながら、実際に多視点映像符号化で用いられる可能性のあるビュー数は最大１０２４であり、参照候補ビューの最大枚数（ＭａｘＶｉｅｗ）を固定してしまうと、実際に多視点映像符号化で用いられるビュー数が少ないとメモリが無駄になるという問題あがる。また、実際に多視点映像符号化で用いられるビュー数が多いと参照候補ビューの数が少なくなることで高画質な符号化が行えないという問題がある。
【００７７】
また、図６のピクチャメモリ管理の説明では、説明の便宜上、ＭＶＣエンコーダ１０２はビュー間予測のみを選択するものと仮定したが、実際の多視点映像符号化では、符号化対象ピクチャ内のブロックごとに、参照候補ビューを用いたビュー間予測符号化と、参照候補ピクチャを用いたピクチャ間予測（インター予測）符号化との一方が選択され、選択された予測符号化が行われる。
【００７８】
したがって、多視点映像符号化における参照候補ピクチャの最大枚数であるＭＶＣ最大バッファサイズ１３０（多視点映像符号化における最大バッファサイズ：ＭｖｃＭａｘＤｐｂＳｉｚｅ）を適切に算出することが必要とされる。多視点映像符号化においても、画像復号装置に搭載すべきピクチャメモリの記憶容量は予め決められていなければならない。その限られたリソースの中で、参照候補ピクチャの最大枚数を増やし、より高画質な符号化を可能とすることが本実施の形態の目的の一つである。なお、多視点映像符号化における参照候補ピクチャとは、ビュー間予測符号化における参照候補ビューと、ピクチャ間予測（インター予測）符号化における参照候補ピクチャとを含んでいる。なお、ピクチャとビューとの画像サイズは等しい。
【００７９】
本実施の形態における画像符号化方法は、多視点映像符号化（ＭＶＣ）を行う場合に、符号化データのピクチャサイズに応じて、メモリ領域を効率的に利用できるようにＭｖｃＭａｘＤｐｂＳｉｚｅを決定する。
【００８０】
以下、画像符号化装置１００の動作の説明と合わせて、ＭｖｃＭａｘＤｐｂＳｉｚｅの決定の仕方について説明する。
【００８１】
図７は、本実施の形態に係る画像符号化装置１００による画像符号化処理のフローチャートである。
【００８２】
本実施の形態に係る画像符号化装置１００では、入力画像の符号化を行う前に、この画像符号化装置１００のメモリ等の構成、及び符号化データを復号する可能性のある画像復号装置のメモリ等の構成に基づいて、予め定義されている複数の符号化レベルの中から符号化条件として用いる符号化レベルが選択される。具体的には、上記符号化レベルの選択は、ユーザが上記テーブルＴ１を参照して行い、ユーザ操作により、選択されたレベルに対応するレベル識別子を示すレベル信号１２６が、レベル解析部１０３に入力される。
【００８３】
なお、テーブルＴ１には、最大蓄積画素数（搭載すべきピクチャメモリの記憶容量）に関する明示の記載はないが、多視点映像符号化ではない通常の符号化を行う場合には、数式（式２）に基づき、符号化レベルで必要な最大蓄積画素数の値を得ることができる。多視点映像符号化を行う場合には、数式（式３）に示すように、数式（式２）の最大蓄積画素数の値に多視点映像符号化のスケールファクタ（ｍｖｃＳｃａｌｅＦａｃｔｏｒ）を乗算した値が、多視点映像符号化の最大蓄積画素数である。なお、３Ｄ符号化では、右目用の画像を符号化するデコーダと左目用の画像を符号化するデコーダとを用いる２デコーダ構成が取られることが多く、一般的にはｍｖｃＳｃａｌｅＦａｃｔｏｒの値として２が用いられる。
【００８４】
最大蓄積画素数（多視点映像符号化時）
＝  ｍｖｃＳｃａｌｅＦａｃｔｏｒ  ＊  （ＭａｘＤｐｂＳｉｚｅ  ＊  ＭａｘＬｕｍａＦＳ）      （式３）
【００８５】
なお、最大蓄積画素数は、上記画像符号化装置１００に対応する画像復号装置の持つピクチャメモリが、どれだけの数の画素に対応する画像データを蓄積可能である必要があるかを示す。言い換えると、最大蓄積画素数は、ピクチャメモリに蓄積可能な画像データの最大量に相当する画素数を示す。例えば、上記画像符号化装置１００からの符号化ビットストリームを復号する画像復号装置のピクチャメモリには、参照候補ピクチャ、表示待ちの復号済みピクチャ、復号対象ピクチャ等のピクチャのデータが蓄積されるが、上記最大蓄積画素数は、これらのピクチャの画素の総数である。
【００８６】
この画像符号化装置１００では、ユーザの操作により、符号化レベルの選択が行われると、レベル信号１２６がレベル解析部１０３に入力される。そして、レベル解析部１０３は、内部に保持されている上記テーブルＴ１（図２参照）を参照して、ユーザにより選択された、上記レベル信号１２６が示す符号化レベルに応じて、最大画面内画素数１２７（ＭａｘＬｕｍａＦＳ）及び参照候補ピクチャの最大枚数（最大バッファサイズ１２８：ＭａｘＤｐｂＳｉｚｅ）を決定する（Ｓ１０１）。ここで、最大バッファサイズ１２８は、非多視点符号化（多視点符号化ではない通常の符号化）における参照候補画像の最大枚数を示す。最大画面内画素数１２７（ＭａｘＬｕｍａＦＳ）は最大ビュー数算出器１０４に入力され、最大バッファサイズ１２８（ＭａｘＤｐｂＳｉｚｅ）はＭＶＣ最大バッファサイズ算出器１０５に入力される。
【００８７】
そして、入力画像信号１２１の画像データがビュー毎に表示時間順で入力画像制御部１０１に入力されると、入力画像制御部１０１内の図示しない記憶部にはビューの各ピクチャに対応する画像データが順次格納される。そして、記憶部からは、格納された画像データが、ビュー毎に、ベースビュー画像１２３又は拡張ビュー画像１２２として、符号化順にＭＶＣエンコーダ１０２に出力される。このとき画像データは、ピクチャを構成するブロック毎にＭＶＣエンコーダ１０２に出力される。さらに、入力画像制御部１０１からは、入力画像のサイズを示す情報（画像サイズ１２５）が最大ビュー数算出器１０４に出力される。
【００８８】
なお、ここで、上記ブロックのサイズは可変であり、ピクチャ内にさまざまな大きさのブロックが混在してもよい。画像符号化装置１００での符号化処理は、ブロック単位で行われる。また、画像サイズ１２５は、上記のように、入力画像の縦画素数を示す情報（ＰｉｃＨｅｉｇｈｔ）と、入力画像の横画素数を示す横画素数情報（ＰｉｃＷｉｄｔｈ）とを含む。
【００８９】
最大ビュー数算出器１０４は、入力画像制御部１０１から出力された画像サイズ１２５と、レベル解析部１０３から出力された最大画面内画素数１２７（ＭａｘＬｕｍａＦＳ）とに基づいて、数式（式４）を用いて、ビュー間予測符号化及びビュー間予測復号の際に用いられる参照候補ビューの最大枚数（最大ビュー数１２９：ＭａｘＶｉｅｗ）を算出する（Ｓ１０２）。
【００９０】
ＭａｘＶｉｅｗ  ＝  Ｆｌｏｏｒ（ｍｖｃＳｃａｌｅＦａｃｔｏｒ  ＊  ＭａｘＬｕｍａＦＳ  ／  （ＰｉｃＨｅｉｇｈｔ  ＊  ＰｉｃＷｉｄｔｈ））    （式４）
【００９１】
ここで、最大ビュー数１２９は、参照候補ビューの最大数を示す。つまり、最大ビュー数１２９から符号化対象のビューを除いた数（ＭａｘＶｉｅｗ‐１）の参照候補ビューをビュー間予測に用いることができる。
【００９２】
数式（式４）から明らかなように、最大ビュー数１２９（ＭａｘＶｉｅｗ）は、画像サイズ１２５に応じて変動する値である。つまり、最大ビュー数１２９は、画像サイズ１２５が小さいときには、より大きな値となり、画像サイズ１２５が大きいときにはより小さい値となる。画像サイズ１２５の上限は、最大画面内画素数１２７（ＭａｘＬｕｍａＦＳ）で制限されるので、最大ビュー数１２９は、画像サイズ１２５が最大画面内画素数１２７（ＭａｘＬｕｍａＦＳ）と等しい場合に、最小値（ｍｖｃＳｃａｌｅＦａｃｔｏｒ）となる。最大ビュー数算出器１０４で算出された最大ビュー数１２９は、ＭＶＣ最大バッファサイズ算出器１０５に出力される。
【００９３】
なお、数式（式４）は、最大画面内画素数１２７（ＭａｘＬｕｍａＦＳ）を画像サイズ１２５（ＰｉｃＨｅｉｇｈｔ  ＊  ＰｉｃＷｉｄｔｈ）で除算している。これは、ピクチャメモリには１ピクチャあたり最大画面内画素数１２７（ＭａｘＬｕｍａＦＳ）の領域が存在するため、入力画像が蓄積できる限り、最大の蓄積枚数を確保することを意図している。しかしながら、除算は処理が複雑又は演算負荷が高いため、数式（式４）は、予め定義されたピクチャサイズ（ＬｕｍａＦＳ）を用いて、以下の数式又は論理式（（式４ａ），（式４ｂ））で代替されてもよい。
【００９４】
α  ＝  Ｆｌｏｏｒ  （ＭａｘＬｕｍａＦＳ／  ＬｕｍａＦＳ）
Ｉｆ  （ＰｉｃＨｅｉｇｈｔ  ＊  ＰｉｃＷｉｄｔｈ  ≦  ＬｕｍａＦＳ）
ＭａｘＶｉｅｗ  ＝  ｍｖｃＳｃａｌｅＦａｃｔｏｒ  ＊  ＭａｘＬｕｍａＦＳ  ＊  α        （式４ａ）
Ｅｌｓｅ
ＭａｘＶｉｅｗ  ＝  ｍｖｃＳｃａｌｅＦａｃｔｏｒ  ＊  ＭａｘＬｕｍａＦＳ        （式４ｂ）
【００９５】
ここで、αは、予め定義されたピクチャサイズ（ＬｕｍａＦＳ）に基づいて事前に定まる値であり、画像符号化装置及び画像復号装置が演算により動的に取得する必要はない。例えば、ピクチャサイズ（ＬｕｍａＦＳ）がＭａｘＬｕｍａＦＳの半分の大きさであった場合、αは２である。この場合、画像サイズ１２５（ＰｉｃＨｅｉｇｈｔ  ＊  ＰｉｃＷｉｄｔｈ）がＬｕｍａＦＳと同じか小さい場合、数式（式４ａ）のように（ｍｖｃＳｃａｌｅＦａｃｔｏｒ  ＊  ＭａｘＬｕｍａＦＳ）にαが乗算される。よって、この場合のＭａｘＶｉｅｗは、画像サイズ１２５（ＰｉｃＨｅｉｇｈｔ  ＊  ＰｉｃＷｉｄｔｈ）がＬｕｍａＦＳより大きい場合のＭａｘＶｉｅｗ（数式（式４ｂ））の２倍となる。なお、ピクチャサイズ（ＬｕｍａＦＳ）の決め方に応じて、αを３又は４などに設定することも可能である。さらに、ＬｕｍａＦＳの代わりにＬｕｍａＦＳ＿１、ＬｕｍａＦＳ＿２のように複数の異なる値を定義し、上記数式又は論理式（（式４ａ）及び（式４ｂ））を以下のように変形することも可能である。
【００９６】
α  ＝  Ｆｌｏｏｒ  （ＭａｘＬｕｍａＦＳ  ／  ＬｕｍａＦＳ＿１）
β  ＝  Ｆｌｏｏｒ  （ＭａｘＬｕｍａＦＳ  ／  ＬｕｍａＦＳ＿２）
Ｉｆ  （ＬｕｍａＦＳ＿２  ＜  ＰｉｃＨｅｉｇｈｔ  ＊  ＰｉｃＷｉｄｔｈ  ≦  ＬｕｍａＦＳ＿１）
ＭａｘＶｉｅｗ  ＝  ｍｖｃＳｃａｌｅＦａｃｔｏｒ  ＊  ＭａｘＬｕｍａＦＳ  ＊  α      （式４ｃ）
Ｅｌｓｅ  ｉｆ  （ＰｉｃＨｅｉｇｈｔ  ＊  ＰｉｃＷｉｄｔｈ  ≦  ＬｕｍａＦＳ＿２）
ＭａｘＶｉｅｗ  ＝  ｍｖｃＳｃａｌｅＦａｃｔｏｒ  ＊  ＭａｘＬｕｍａＦＳ  ＊  β        （式４ｄ）
Ｅｌｓｅ
ＭａｘＶｉｅｗ      ＝  ｍｖｃＳｃａｌｅＦａｃｔｏｒ  ＊  ＭａｘＬｕｍａＦＳ                （式４ｅ）
【００９７】
例えば、ピクチャサイズ（ＬｕｍａＦＳ＿１）がＭａｘＬｕｍａＦＳの半分の大きさであった場合、αは２であり、ピクチャサイズ（ＬｕｍａＦＳ＿２）がＭａｘＬｕｍａＦＳの４分の１の大きさであった場合、βは４である。画像サイズ１２５（ＰｉｃＨｅｉｇｈｔ  ＊  ＰｉｃＷｉｄｔｈ）がＬｕｍａＦＳ＿２より小さい場合、数式（式４ｄ）のように、（ｍｖｃＳｃａｌｅＦａｃｔｏｒ  ＊  ＭａｘＬｕｍａＦＳ）にβが乗算される。よって、この場合のＭａｘＶｉｅｗは、画像サイズ１２５（ＰｉｃＨｅｉｇｈｔ  ＊  ＰｉｃＷｉｄｔｈ）がＬｕｍａＦＳ＿１より大きい場合のＭａｘＶｉｅｗ（数式（式４ｅ））の４倍となる。なお、同様にして、ＬｕｍａＦＳとして３以上の異なる値を定義して、同様の処理を行うことができることは自明である。
【００９８】
また、ｍｖｃＳｃａｌｅＦａｃｔｏｒは、予め決められた固定値であり、最大ビュー数算出器１０４は内部にｍｖｃＳｃａｌｅＦａｃｔｏｒの値を保持している。本来、ｍｖｃＳｃａｌｅＦａｃｔｏｒの値は、多視点映像符号化のビュー数に応じて設定（例えばビュー数が多い場合は大きな値に設定）される。しかしながら、画像復号装置に搭載すべきピクチャメモリの記憶容量を予め決定するためにｍｖｃＳｃａｌｅＦａｃｔｏｒの値を可変とすることはできない。そこで、例えば、レベルに応じてｍｖｃＳｃａｌｅＦａｃｔｏｒの値を変えるようにしてもよい。具体的には、図２のテーブルＴ１を図８のように拡張し、レベル１〜３．１はｍｖｃＳｃａｌｅＦａｃｔｏｒとして２を用い、レベル４〜４．３はｍｖｃＳｃａｌｅＦａｃｔｏｒとして３を用い、レベル５以上はｍｖｃＳｃａｌｅＦａｃｔｏｒとして４を用いるようにしてもよい。この場合、レベル解析部１０３は、レベル識別子を示すレベル信号１２６に基づいて、対応するｍｖｃＳｃａｌｅＦａｃｔｏｒを最大ビュー数算出器１０４に出力する。
【００９９】
次に、ＭＶＣ最大バッファサイズ算出器１０５は、入力された最大ビュー数１２９（ＭａｘＶｉｅｗ）と、最大バッファサイズ１２８（ＭａｘＤＰＢＳｉｚｅ）とに基づいて、数式（式５）を用いて、多視点映像符号化における参照候補ピクチャの最大枚数であるＭＶＣ最大バッファサイズ１３０（多視点映像符号化における最大バッファサイズ：ＭｖｃＭａｘＤｐｂＳｉｚｅ）を算出する（Ｓ１０３）。
【０１００】
ＭｖｃＭａｘＤＰＢＳｉｚｅ  ＝  ＭａｘＶｉｅｗ  ＊  ＭａｘＤＰＢＳｉｚｅ        （式５）
【０１０１】
ＭＶＣ最大バッファサイズ１３０（ＭｖｃＭａｘＤＰＢＳｉｚｅ）とは、ピクチャメモリが蓄積すべきトータルの参照候補ピクチャ（又はビュー）の枚数を示す。なお、参照候補ピクチャ（又はビュー）は、入力画像制御部１０１から出力された画像サイズ１２５のピクチャサイズを有している。
【０１０２】
ＭＶＣ最大バッファサイズ算出器１０５から出力されたＭｖｃＭａｘＤＰＢＳｉｚｅは、ＭＶＣエンコーダ１０２に入力される。ＭＶＣエンコーダ１０２は、数式（式６）のようにＭｖｃＭａｘＤＰＢＳｉｚｅを越えない範囲で、多視点映像符号化する際、又は、符号化したデータをＭＶＣデコーダで復号をする際に使用するデコードピクチャバッファ（ＤＰＢ）のピクチャ（ビュー）数であるＤＰＢピクチャ（ビュー）数（ｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇ）を設定する（Ｓ１０４）。
【０１０３】
ｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇ  ≦  ＭｖｃＭａｘＤＰＢＳｉｚｅ      （式６）
【０１０４】
なお、ｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇの値をいくつに設定するかは画像符号化装置側に任されている。例えばｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇをＭｖｃＭａｘＤＰＢＳｉｚｅと同じ値に設定することにより、ピクチャ間予測の参照候補ピクチャ、及びビュー間予測の参照候補ビューの枚数が最大になるので、より高画質な符号化が期待できる。しかしながら、ｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇの値を大きく設定すると符号化処理は複雑化するので処理負荷は高くなるので、実際には、バランスを考慮してｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇの値が決定される。
【０１０５】
また、この画像符号化装置１００は、ｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇをピクチャ間予測の参照候補ピクチャに何枚割り当て、ビュー間予測の参照候補ビューに何枚割り当てるか決定することができる。ピクチャ間予測の参照候補ピクチャの枚数を減らし、ビュー間予測の参照候補ビューの枚数を増やしたり、また、その逆とすることも許される。例えば、ｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇの値が４８のとき、ビュー間予測の参照候補ビューの枚数を、符号化対象ビューを除いた７（＝８−１）に設定し、ピクチャ間予測の参照候補ピクチャの枚数を５（＝６−１）に設定することができる。また、例えば、ビュー間予測の参照候補ビューの枚数を１１（＝１２−１）に設定し、ピクチャ間予測の参照候補ピクチャの枚数を３（＝４−１）に設定することができる。また、例えば、ビュー間予測の参照候補ビューの枚数を５（＝６−１）に設定し、ピクチャ間予測の参照候補ピクチャの枚数を７（＝８−１）に設定することができる。
【０１０６】
なお、上記割り当てに用いるために、ＭＶＣ最大バッファサイズ算出器１０５は、ＭｖｃＭａｘＤＰＢＳｉｚｅと合わせて、ＭａｘＶｉｅｗ及びＭａｘＤＰＢＳｉｚｅをＭＶＣエンコーダ１０２に出力してもよい。さらに、ＭＶＣ最大バッファサイズ算出器１０５をＭＶＣエンコーダ１０２内部に設け、最大ビュー数算出器１０４が出力したＭａｘＶｉｅｗと、レベル解析部１０３が出力したＭａｘＤＰＢＳｉｚｅが直接ＭＶＣエンコーダ１０２に入力されてもよい。このような構成とすることにより、ＭＶＣエンコーダ１０２は、（ＭａｘＶｉｅｗ−１）を超えない範囲でビュー間予測の参照候補ビューの枚数を設定し、（ＭａｘＤＰＢＳｉｚｅ−１）を超えない範囲でピクチャ間予測の参照候補ピクチャの枚数を設定することが可能となる。
【０１０７】
次に、ＭＶＣエンコーダ１０２の多視点映像符号化の動作について説明する。
【０１０８】
入力画像制御部１０１から出力されたベースビュー画像１２３と拡張ビュー画像１２２は、対応する各ビューの符号化部に入力される。すなわち、ベースビュー画像１２３は、ベースビュー符号化部１４２に入力され、拡張ビュー画像１２２は拡張ビュー符号化部１４１に入力される。なお、図４に示すＭＶＣエンコーダ１０２は、例として、ベースビュー及び拡張ビューの２つのビューを符号化する構成であるが、拡張ビュー符号化部１４１を多段に結合することにより、２以上の拡張ビューを用いた多視点映像の符号化を実現することができる。
【０１０９】
ベースビュー符号化部１４２は、多視点映像符号化を行わない通常の画像符号化装置と同様の機能を有し、ベースビュー画像１２３を符号化する。また、ベースビュー符号化部１４２は、ベースビュー符号化部１４２の内部で符号化された後、復号されることにより得られたベースビューの再構築ビュー画像１５１を拡張ビュー符号化部１４１に出力する。
【０１１０】
拡張ビュー符号化部１４１は、再構築ビュー画像１５１を用いて入力画像制御部１０１から出力される拡張ビュー画像１２２をビュー間予測符号化する。なお、拡張ビュー符号化部１４１は、同一の拡張ビュー内のピクチャであって時間的に異なるピクチャの再構築画像を用いて、ピクチャ間予測（インター予測）符号化を行うことも可能である。どちらの符号化を用いるかは、ブロックごとに決定される。
【０１１１】
ビュー多重化部１４３は、各ビュー、すなわち、ベースビュー及び拡張ビューの符号化情報を多重化することで、多視点映像符号化されたビットストリームであるＭＶＣビットストリーム１２４を生成する。
【０１１２】
なお、ＭＶＣエンコーダ１０２は、ＭＶＣ最大バッファサイズ算出器１０４からＭｖｃＭａｘＤＰＢＳｉｚｅが入力されると、数式（式６）に従い、ｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇの値を決定する。そして、ＭＶＣエンコーダ１０２は、ＭＶＣエンコーダ１０２内部の図示しないピクチャメモリにおいて、画像サイズ１２５（ＰｉｃＨｅｉｇｈｔ  ＊  ＰｉｃＷｉｄｔｈ）の領域をｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇの数だけ確保する。確保された領域は、上述したように、ビュー間予測の参照候補ビューと、ピクチャ間予測の参照候補ピクチャとに割り当てられる。
【０１１３】
また、ＭＶＣエンコーダ１０２は、符号化の際に決定し、符号化に用いたｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇの値を、パラメータの一つとしてシーケンスパラメータセット（ＳＰＳ）に含めたビットストリームを生成する。シーケンスパラメータセットは、１枚以上のピクチャに共通に使用することが可能なヘッダに相当するパラメータセットである。シーケンスパラメータセットには、最大参照可能ピクチャ数、画像サイズ、及びビデオ表示情報（ＶＵＩ：Ｖｉｄｅｏ  Ｕｓａｂｉｌｉｔｙ  Ｉｎｆｏｒｍａｔｉｏｎ）などが含まれている。
【０１１４】
なお、ｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇの値は、ＳＰＳに限らずビデオパラメータセット（ＶＰＳ）などの他のパラメータセットに含まれてもよい。また、ｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇの値は、補足情報（ＳＥＩ：Ｓｕｐｐｌｅｍｅｎｔａｌ  Ｅｎｈａｎｃｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ）に含まれてもよい。この場合、ｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇの値は、ＳＥＩメッセージによって画像復号装置に通知される。
【０１１５】
以上のように、本実施の形態に係る画像符号化装置１００は、ピクチャメモリの記憶容量が予め決められている状況（例えば、数式（式３）など）において、多視点映像符号化における参照候補ピクチャ（ビュー）の最大枚数（ＭｖｃＭａｘＤｐｂＳｉｚｅ）を適切に算出することができる。また、画像符号化装置１００は、符号化データ（入力画像）のピクチャサイズに応じて、ピクチャ間予測の参照候補ピクチャの枚数、又はビュー間予測の参照候補ビューの枚数を可変とすることにより、メモリ領域を効率的に利用することができる。
【０１１６】
（実施の形態２）
次に、実施の形態２について説明する。
【０１１７】
図９は、本実施の形態に係るＭＶＣデコーダを備えた画像復号装置２００（動画像復号装置）の構成を示すブロック図である。この画像復号装置２００は、一つ以上のビューを含む多視点映像符号化されたＭＶＣビットストリーム２２１を受け、ＭＶＣデコーダでＭＶＣ復号化を行い、一つ以上の復号された出力画像２２５（ビュー）を表示装置等に出力する。例えば、この画像復号装置２００は、実施の形態１に係る画像符号化装置１００が符号化したＭＶＣビットストリーム１２４を復号する。
【０１１８】
画像復号装置２００は、入力されたＭＶＣビットストリーム２２１のヘッダ領域及びＳＰＳ領域に格納されたデータを取得し解析する符号列解析部２０１と、一つ以上のビューを含む符号化データ２２２を復号するＭＶＣデコーダ２０２とを具備する。
【０１１９】
符号列解析部２０１は、入力されたＭＶＣビットストリーム２２１のヘッダ領域及びＳＰＳ領域に格納されたデータを取得し解析する。ＳＰＳには、最大参照可能ピクチャ数、画像サイズ、及びビデオ表示情報（ＶＵＩ：Ｖｉｄｅｏ  Ｕｓａｂｉｌｉｔｙ  Ｉｎｆｏｒｍａｔｉｏｎ）などが含まれている。符号列解析部２０１は、例えば、ＶＵＩに含まれるｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇの値を取得する。なお、ＳＥＩメッセージが入力される場合には、符号列解析部２０１は、ＳＥＩメッセージに含まれる情報を解析し、必要な情報を取得する。
【０１２０】
ＭＶＣデコーダ２０２は、ＭＶＣビットストリーム２２１に含まれるベースビューの符号化データと拡張ビューの符号化データとをそれぞれ復号し、復号により得られた出力画像２２５（ビュー）を出力する。各ビューの復号処理においては、符号列解析部２０１から出力されたパラメータ情報と、ビットストリームのより下位レイヤ（スライスヘッダなど）に含まれ、ＭＶＣデコーダ２０２によって抽出されたパラメータ情報が、パラメータとして用いられる。符号列解析部２０１から出力されたパラメータ情報には、画像サイズ情報２２３（ＰｉｃＨｅｉｇｈｔ及びＰｉｃＷｉｄｔｈ）と、ＤＰＢピクチャ（ビュー）数２２４（ｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇ）とが含まれている。
【０１２１】
次に、この画像復号装置の動作について説明する。図１０は、画像復号装置２００による画像復号処理の流れを示すフローチャートである。
【０１２２】
この画像復号装置２００にＭＶＣビットストリーム２２１が入力されると、まず、符号列解析部２０１は、ＭＶＣビットストリーム２２４から画像サイズ２２３（ＰｉｃＨｅｉｇｈｔ及びＰｉｃＷｉｄｔｈ）、ＤＰＢピクチャ（ビュー）数２２４（ｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇ）、及び符号化データ２２２等の各種の情報を抽出する（Ｓ２０１）。抽出された画像サイズ情報２２３（ＰｉｃＨｅｉｇｈｔ及びＰｉｃＷｉｄｔｈ）と、ＤＰＢピクチャ（ビュー）数２２４（ｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇ）と、符号化データ２２２とは、ＭＶＣデコーダ２０２に出力される。なお、特に記載しないが、抽出されたその他の情報も、必要に応じてＭＶＣデコーダ２０２に出力される。
【０１２３】
ＭＶＣデコーダ２０２は、画像サイズ２２３（ＰｉｃＨｅｉｇｈｔ，  ＰｉｃＷｉｄｔｈ）と、ＤＰＢピクチャ（ビュー）数２２４（ｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇ）を受信すると、符号化データ２２２の復号処理に先立ち、図示しないピクチャメモリの領域確保を行う（Ｓ２０２）。具体的には、ＭＶＣデコーダ２０２は、ピクチャメモリ（ＤＰＢ）に、画像サイズ２２３（ＰｉｃＨｅｉｇｈｔ  ＊  ＰｉｃＷｉｄｔｈ）のピクチャ領域をｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇの値の枚数確保する。なお、画像復号装置２００は、上記テーブルＴ１（図２参照）のレベル識別子で特定される各符号化レベルのうち、サポートしている符号化レベルで必要とされる記憶容量のピクチャメモリを予め搭載している。すなわち、画像復号装置２００は、数式（式３）で与えられる最大蓄積画素数（多視点映像符号化時）の記憶容量を有するピクチャメモリを搭載している。
【０１２４】
既に説明したように、実施の形態１に係る画像符号化装置１００は、この最大蓄積画素数（多視点映像符号化時）を超えないように、多視点映像符号化時の最大バッファサイズ（ＭＶＣ最大バッファサイズ１３０：ＭｖｃＭａｘＤＰＢＳｉｚｅ）を決定している。多視点映像符号化時の最大バッファサイズ（ＭｖｃＭａｘＤＰＢＳｉｚｅ）とは、ピクチャメモリが蓄積すべきトータルの参照候補ピクチャ（又はビュー）の枚数を示す。そして、数式（式６）のように、ＭｖｃＭａｘＤＰＢＳｉｚｅを越えないようにｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇの値が画像符号化装置１００によって決定される。したがって、画像復号装置２００が、画像サイズ２２３（ＰｉｃＨｅｉｇｈｔ  ＊  ＰｉｃＷｉｄｔｈ）のピクチャ領域をｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇの値の枚数確保できることは、画像符号化装置１００によって保障されており、ＭＶＣデコーダ２０２は領域不足になることなくピクチャメモリの領域を確保できる。
【０１２５】
ピクチャメモリの領域確保が完了すると、ＭＶＣデコーダ２０２は、符号化データ２２２に含まれるベースビューの符号化データと拡張ビューの符号化データとをそれぞれ復号し、復号により得られた出力画像２２５（ビュー）を出力する。なお、復号処理に際しては、ピクチャメモリに参照候補ピクチャ（ビュー）、表示待ちの復号済みピクチャ、及び復号対象ピクチャ等のピクチャのデータがピクチャメモリに蓄積される。
【０１２６】
以上のように、本実施の形態に係る画像復号装置２００は、符号列解析部２０１により抽出された画像サイズ２２３（ＰｉｃＨｅｉｇｈｔ  ＊  ＰｉｃＷｉｄｔｈ）と、ｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇの値とに基づき、ピクチャバッファ（ＤＰＢ）の領域確保を行う。それにより、画像復号装置２００は、画像復号装置２００が搭載しているピクチャメモリの最大蓄積画素数（最大記憶容量）を越えずに、かつ、復号時に破たん（ピクチャバッファ不足等）することなくＭＶＣビットストリーム２２１を復号することができる。
【０１２７】
また、画像復号装置２００は、ピクチャメモリの記憶容量が一定の状況（例えば、数式（式３）など）において、多視点映像符号化における参照候補ピクチャ（ビュー）の最大枚数（ＭｖｃＭａｘＤｐｂＳｉｚｅ）を画像サイズに応じて適切に算出することができる画像符号化装置によって決定されたｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇを用いるため、本実施の形態に係る画像復号装置２００は、メモリ領域を効率的に利用することができる。
【０１２８】
以上、実施の形態に係る画像符号化装置に及び画像復号装置ついて説明したが、本発明は、この実施の形態に限定されるものではない。
【０１２９】
また、上記実施の形態に係る画像符号化装置及び画像復号装置に含まれる各処理部は典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又は全てを含むように１チップ化されてもよい。
【０１３０】
また、集積回路化はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後にプログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）、又はＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
【０１３１】
上記各実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵ又はプロセッサなどのプログラム実行部が、ハードディスク又は半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。
【０１３２】
言い換えると、画像符号化装置及び画像復号装置は、処理回路（ｐｒｏｃｅｓｓｉｎｇ  ｃｉｒｃｕｉｔｒｙ）と、当該処理回路に電気的に接続された（当該制御回路からアクセス可能な）記憶装置（ｓｔｏｒａｇｅ）とを備える。処理回路は、専用のハードウェア及びプログラム実行部の少なくとも一方を含む。また、記憶装置は、処理回路がプログラム実行部を含む場合には、当該プログラム実行部により実行されるソフトウェアプログラムを記憶する。処理回路は、記憶装置を用いて、上記実施の形態に係る画像符号化方法又は画像復号方法を実行する。
【０１３３】
さらに、本発明は上記ソフトウェアプログラムであってもよいし、上記プログラムが記録された非一時的なコンピュータ読み取り可能な記録媒体であってもよい。また、上記プログラムは、インターネット等の伝送媒体を介して流通させることができるのは言うまでもない。
【０１３４】
また、上記で用いた数字は、全て本発明を具体的に説明するために例示するものであり、本発明は例示された数字に制限されない。
【０１３５】
また、ブロック図における機能ブロックの分割は一例であり、複数の機能ブロックを一つの機能ブロックとして実現したり、一つの機能ブロックを複数に分割したり、一部の機能を他の機能ブロックに移してもよい。また、類似する機能を有する複数の機能ブロックの機能を単一のハードウェア又はソフトウェアが並列又は時分割に処理してもよい。
【０１３６】
また、上記の画像符号化方法又は画像復号方法に含まれるステップが実行される順序は、本発明を具体的に説明するために例示するためのものであり、上記以外の順序であってもよい。また、上記ステップの一部が、他のステップと同時（並列）に実行されてもよい。
【０１３７】
以上、本発明の一つ又は複数の態様に係る画像符号化装置及び画像復号装置について、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、本発明の一つ又は複数の態様の範囲内に含まれてもよい。
【０１３８】
（実施の形態３）
上記各実施の形態で示した動画像符号化方法（画像符号化方法）または動画像復号化方法（画像復号方法）の構成を実現するためのプログラムを記憶メディアに記録することにより、上記各実施の形態で示した処理を独立したコンピュータシステムにおいて簡単に実施することが可能となる。記憶メディアは、磁気ディスク、光ディスク、光磁気ディスク、ＩＣカード、半導体メモリ等、プログラムを記録できるものであればよい。
【０１３９】
さらにここで、上記各実施の形態で示した動画像符号化方法（画像符号化方法）や動画像復号化方法（画像復号方法）の応用例とそれを用いたシステムを説明する。当該システムは、画像符号化方法を用いた画像符号化装置、及び画像復号方法を用いた画像復号装置からなる画像符号化復号装置を有することを特徴とする。システムにおける他の構成について、場合に応じて適切に変更することができる。
【０１４０】
図１１は、コンテンツ配信サービスを実現するコンテンツ供給システムex１００の全体構成を示す図である。通信サービスの提供エリアを所望の大きさに分割し、各セル内にそれぞれ固定無線局である基地局ex１０６、ex１０７、ex１０８、ex１０９、ex１１０が設置されている。
【０１４１】
このコンテンツ供給システムex１００は、インターネットex１０１にインターネットサービスプロバイダex１０２および電話網ex１０４、および基地局ex１０６からex１１０を介して、コンピュータex１１１、ＰＤＡ（Personal Digital Assistant）ex１１２、カメラex１１３、携帯電話ex１１４、ゲーム機ex１１５などの各機器が接続される。
【０１４２】
しかし、コンテンツ供給システムex１００は図１１のような構成に限定されず、いずれかの要素を組合せて接続するようにしてもよい。また、固定無線局である基地局ex１０６からex１１０を介さずに、各機器が電話網ex１０４に直接接続されてもよい。また、各機器が近距離無線等を介して直接相互に接続されていてもよい。
【０１４３】
カメラex１１３はデジタルビデオカメラ等の動画撮影が可能な機器であり、カメラex１１６はデジタルカメラ等の静止画撮影、動画撮影が可能な機器である。また、携帯電話ex１１４は、ＧＳＭ（登録商標）（Global System for Mobile Communications）方式、ＣＤＭＡ（Code Division Multiple Access）方式、Ｗ−ＣＤＭＡ（Wideband-Code Division Multiple Access）方式、若しくはＬＴＥ（Long Term Evolution）方式、ＨＳＰＡ(High Speed Packet Access)の携帯電話機、またはＰＨＳ（Personal Handyphone System）等であり、いずれでも構わない。
【０１４４】
コンテンツ供給システムex１００では、カメラex１１３等が基地局ex１０９、電話網ex１０４を通じてストリーミングサーバex１０３に接続されることで、ライブ配信等が可能になる。ライブ配信では、ユーザがカメラex１１３を用いて撮影するコンテンツ（例えば、音楽ライブの映像等）に対して上記各実施の形態で説明したように符号化処理を行い（即ち、本発明の一態様に係る画像符号化装置として機能する）、ストリーミングサーバex１０３に送信する。一方、ストリーミングサーバex１０３は要求のあったクライアントに対して送信されたコンテンツデータをストリーム配信する。クライアントとしては、上記符号化処理されたデータを復号化することが可能な、コンピュータex１１１、ＰＤＡex１１２、カメラex１１３、携帯電話ex１１４、ゲーム機ex１１５等がある。配信されたデータを受信した各機器では、受信したデータを復号化処理して再生する（即ち、本発明の一態様に係る画像復号装置として機能する）。
【０１４５】
なお、撮影したデータの符号化処理はカメラex１１３で行っても、データの送信処理をするストリーミングサーバex１０３で行ってもよいし、互いに分担して行ってもよい。同様に配信されたデータの復号化処理はクライアントで行っても、ストリーミングサーバex１０３で行ってもよいし、互いに分担して行ってもよい。また、カメラex１１３に限らず、カメラex１１６で撮影した静止画像および／または動画像データを、コンピュータex１１１を介してストリーミングサーバex１０３に送信してもよい。この場合の符号化処理はカメラex１１６、コンピュータex１１１、ストリーミングサーバex１０３のいずれで行ってもよいし、互いに分担して行ってもよい。
【０１４６】
また、これら符号化・復号化処理は、一般的にコンピュータex１１１や各機器が有するＬＳＩex５００において処理する。ＬＳＩex５００は、ワンチップであっても複数チップからなる構成であってもよい。なお、動画像符号化・復号化用のソフトウェアをコンピュータex１１１等で読み取り可能な何らかの記録メディア（ＣＤ−ＲＯＭ、フレキシブルディスク、ハードディスクなど）に組み込み、そのソフトウェアを用いて符号化・復号化処理を行ってもよい。さらに、携帯電話ex１１４がカメラ付きである場合には、そのカメラで取得した動画データを送信してもよい。このときの動画データは携帯電話ex１１４が有するＬＳＩex５００で符号化処理されたデータである。
【０１４７】
また、ストリーミングサーバex１０３は複数のサーバや複数のコンピュータであって、データを分散して処理したり記録したり配信するものであってもよい。
【０１４８】
以上のようにして、コンテンツ供給システムex１００では、符号化されたデータをクライアントが受信して再生することができる。このようにコンテンツ供給システムex１００では、ユーザが送信した情報をリアルタイムでクライアントが受信して復号化し、再生することができ、特別な権利や設備を有さないユーザでも個人放送を実現できる。
【０１４９】
なお、コンテンツ供給システムex１００の例に限らず、図１２に示すように、デジタル放送用システムex２００にも、上記各実施の形態の少なくとも動画像符号化装置（画像符号化装置）または動画像復号化装置（画像復号装置）のいずれかを組み込むことができる。具体的には、放送局ex２０１では映像データに音楽データなどが多重化された多重化データが電波を介して通信または衛星ex２０２に伝送される。この映像データは上記各実施の形態で説明した動画像符号化方法により符号化されたデータである（即ち、本発明の一態様に係る画像符号化装置によって符号化されたデータである）。これを受けた放送衛星ex２０２は、放送用の電波を発信し、この電波を衛星放送の受信が可能な家庭のアンテナex２０４が受信する。受信した多重化データを、テレビ（受信機）ex３００またはセットトップボックス（ＳＴＢ）ex２１７等の装置が復号化して再生する（即ち、本発明の一態様に係る画像復号装置として機能する）。
【０１５０】
また、ＤＶＤ、ＢＤ等の記録メディアex２１５に記録した多重化データを読み取り復号化する、または記録メディアex２１５に映像信号を符号化し、さらに場合によっては音楽信号と多重化して書き込むリーダ／レコーダex２１８にも上記各実施の形態で示した動画像復号化装置または動画像符号化装置を実装することが可能である。この場合、再生された映像信号はモニタex２１９に表示され、多重化データが記録された記録メディアex２１５により他の装置やシステムにおいて映像信号を再生することができる。また、ケーブルテレビ用のケーブルex２０３または衛星／地上波放送のアンテナex２０４に接続されたセットトップボックスex２１７内に動画像復号化装置を実装し、これをテレビのモニタex２１９で表示してもよい。このときセットトップボックスではなく、テレビ内に動画像復号化装置を組み込んでもよい。
【０１５１】
図１３は、上記各実施の形態で説明した動画像復号化方法および動画像符号化方法を用いたテレビ（受信機）ex３００を示す図である。テレビex３００は、上記放送を受信するアンテナex２０４またはケーブルex２０３等を介して映像データに音声データが多重化された多重化データを取得、または出力するチューナex３０１と、受信した多重化データを復調する、または外部に送信する多重化データに変調する変調／復調部ex３０２と、復調した多重化データを映像データと、音声データとに分離する、または信号処理部ex３０６で符号化された映像データ、音声データを多重化する多重／分離部ex３０３を備える。
【０１５２】
また、テレビex３００は、音声データ、映像データそれぞれを復号化する、またはそれぞれの情報を符号化する音声信号処理部ex３０４、映像信号処理部ex３０５（本発明の一態様に係る画像符号化装置または画像復号装置として機能する）を有する信号処理部ex３０６と、復号化した音声信号を出力するスピーカex３０７、復号化した映像信号を表示するディスプレイ等の表示部ex３０８を有する出力部ex３０９とを有する。さらに、テレビex３００は、ユーザ操作の入力を受け付ける操作入力部ex３１２等を有するインタフェース部ex３１７を有する。さらに、テレビex３００は、各部を統括的に制御する制御部ex３１０、各部に電力を供給する電源回路部ex３１１を有する。インタフェース部ex３１７は、操作入力部ex３１２以外に、リーダ／レコーダex２１８等の外部機器と接続されるブリッジex３１３、ＳＤカード等の記録メディアex２１６を装着可能とするためのスロット部ex３１４、ハードディスク等の外部記録メディアと接続するためのドライバex３１５、電話網と接続するモデムex３１６等を有していてもよい。なお記録メディアex２１６は、格納する不揮発性／揮発性の半導体メモリ素子により電気的に情報の記録を可能としたものである。テレビex３００の各部は同期バスを介して互いに接続されている。
【０１５３】
まず、テレビex３００がアンテナex２０４等により外部から取得した多重化データを復号化し、再生する構成について説明する。テレビex３００は、リモートコントローラex２２０等からのユーザ操作を受け、ＣＰＵ等を有する制御部ex３１０の制御に基づいて、変調／復調部ex３０２で復調した多重化データを多重／分離部ex３０３で分離する。さらにテレビex３００は、分離した音声データを音声信号処理部ex３０４で復号化し、分離した映像データを映像信号処理部ex３０５で上記各実施の形態で説明した復号化方法を用いて復号化する。復号化した音声信号、映像信号は、それぞれ出力部ex３０９から外部に向けて出力される。出力する際には、音声信号と映像信号が同期して再生するよう、バッファex３１８、ex３１９等に一旦これらの信号を蓄積するとよい。また、テレビex３００は、放送等からではなく、磁気／光ディスク、ＳＤカード等の記録メディアex２１５、ex２１６から多重化データを読み出してもよい。次に、テレビex３００が音声信号や映像信号を符号化し、外部に送信または記録メディア等に書き込む構成について説明する。テレビex３００は、リモートコントローラex２２０等からのユーザ操作を受け、制御部ex３１０の制御に基づいて、音声信号処理部ex３０４で音声信号を符号化し、映像信号処理部ex３０５で映像信号を上記各実施の形態で説明した符号化方法を用いて符号化する。符号化した音声信号、映像信号は多重／分離部ex３０３で多重化され外部に出力される。多重化する際には、音声信号と映像信号が同期するように、バッファex３２０、ex３２１等に一旦これらの信号を蓄積するとよい。なお、バッファex３１８、ex３１９、ex３２０、ex３２１は図示しているように複数備えていてもよいし、１つ以上のバッファを共有する構成であってもよい。さらに、図示している以外に、例えば変調／復調部ex３０２や多重／分離部ex３０３の間等でもシステムのオーバフロー、アンダーフローを避ける緩衝材としてバッファにデータを蓄積することとしてもよい。
【０１５４】
また、テレビex３００は、放送等や記録メディア等から音声データ、映像データを取得する以外に、マイクやカメラのＡＶ入力を受け付ける構成を備え、それらから取得したデータに対して符号化処理を行ってもよい。なお、ここではテレビex３００は上記の符号化処理、多重化、および外部出力ができる構成として説明したが、これらの処理を行うことはできず、上記受信、復号化処理、外部出力のみが可能な構成であってもよい。
【０１５５】
また、リーダ／レコーダex２１８で記録メディアから多重化データを読み出す、または書き込む場合には、上記復号化処理または符号化処理はテレビex３００、リーダ／レコーダex２１８のいずれで行ってもよいし、テレビex３００とリーダ／レコーダex２１８が互いに分担して行ってもよい。
【０１５６】
一例として、光ディスクからデータの読み込みまたは書き込みをする場合の情報再生／記録部ex４００の構成を図１４に示す。情報再生／記録部ex４００は、以下に説明する要素ex４０１、ex４０２、ex４０３、ex４０４、ex４０５、ex４０６、ex４０７を備える。光ヘッドex４０１は、光ディスクである記録メディアex２１５の記録面にレーザスポットを照射して情報を書き込み、記録メディアex２１５の記録面からの反射光を検出して情報を読み込む。変調記録部ex４０２は、光ヘッドex４０１に内蔵された半導体レーザを電気的に駆動し記録データに応じてレーザ光の変調を行う。再生復調部ex４０３は、光ヘッドex４０１に内蔵されたフォトディテクタにより記録面からの反射光を電気的に検出した再生信号を増幅し、記録メディアex２１５に記録された信号成分を分離して復調し、必要な情報を再生する。バッファex４０４は、記録メディアex２１５に記録するための情報および記録メディアex２１５から再生した情報を一時的に保持する。ディスクモータex４０５は記録メディアex２１５を回転させる。サーボ制御部ex４０６は、ディスクモータex４０５の回転駆動を制御しながら光ヘッドex４０１を所定の情報トラックに移動させ、レーザスポットの追従処理を行う。システム制御部ex４０７は、情報再生／記録部ex４００全体の制御を行う。上記の読み出しや書き込みの処理はシステム制御部ex４０７が、バッファex４０４に保持された各種情報を利用し、また必要に応じて新たな情報の生成・追加を行うと共に、変調記録部ex４０２、再生復調部ex４０３、サーボ制御部ex４０６を協調動作させながら、光ヘッドex４０１を通して、情報の記録再生を行うことにより実現される。システム制御部ex４０７は例えばマイクロプロセッサで構成され、読み出し書き込みのプログラムを実行することでそれらの処理を実行する。
【０１５７】
以上では、光ヘッドex４０１はレーザスポットを照射するとして説明したが、近接場光を用いてより高密度な記録を行う構成であってもよい。
【０１５８】
図１５に光ディスクである記録メディアex２１５の模式図を示す。記録メディアex２１５の記録面には案内溝（グルーブ）がスパイラル状に形成され、情報トラックex２３０には、予めグルーブの形状の変化によってディスク上の絶対位置を示す番地情報が記録されている。この番地情報はデータを記録する単位である記録ブロックex２３１の位置を特定するための情報を含み、記録や再生を行う装置において情報トラックex２３０を再生し番地情報を読み取ることで記録ブロックを特定することができる。また、記録メディアex２１５は、データ記録領域ex２３３、内周領域ex２３２、外周領域ex２３４を含んでいる。ユーザデータを記録するために用いる領域がデータ記録領域ex２３３であり、データ記録領域ex２３３より内周または外周に配置されている内周領域ex２３２と外周領域ex２３４は、ユーザデータの記録以外の特定用途に用いられる。情報再生／記録部ex４００は、このような記録メディアex２１５のデータ記録領域ex２３３に対して、符号化された音声データ、映像データまたはそれらのデータを多重化した多重化データの読み書きを行う。
【０１５９】
以上では、１層のＤＶＤ、ＢＤ等の光ディスクを例に挙げ説明したが、これらに限ったものではなく、多層構造であって表面以外にも記録可能な光ディスクであってもよい。また、ディスクの同じ場所にさまざまな異なる波長の色の光を用いて情報を記録したり、さまざまな角度から異なる情報の層を記録したりなど、多次元的な記録／再生を行う構造の光ディスクであってもよい。
【０１６０】
また、デジタル放送用システムex２００において、アンテナex２０５を有する車ex２１０で衛星ex２０２等からデータを受信し、車ex２１０が有するカーナビゲーションex２１１等の表示装置に動画を再生することも可能である。なお、カーナビゲーションex２１１の構成は例えば図１３に示す構成のうち、ＧＰＳ受信部を加えた構成が考えられ、同様なことがコンピュータex１１１や携帯電話ex１１４等でも考えられる。
【０１６１】
図１６Ａは、上記実施の形態で説明した動画像復号化方法および動画像符号化方法を用いた携帯電話ex１１４を示す図である。携帯電話ex１１４は、基地局ex１１０との間で電波を送受信するためのアンテナex３５０、映像、静止画を撮ることが可能なカメラ部ex３６５、カメラ部ex３６５で撮像した映像、アンテナex３５０で受信した映像等が復号化されたデータを表示する液晶ディスプレイ等の表示部ex３５８を備える。携帯電話ex１１４は、さらに、操作キー部ex３６６を有する本体部、音声を出力するためのスピーカ等である音声出力部ex３５７、音声を入力するためのマイク等である音声入力部ex３５６、撮影した映像、静止画、録音した音声、または受信した映像、静止画、メール等の符号化されたデータもしくは復号化されたデータを保存するメモリ部ex３６７、又は同様にデータを保存する記録メディアとのインタフェース部であるスロット部ex３６４を備える。
【０１６２】
さらに、携帯電話ex１１４の構成例について、図１６Ｂを用いて説明する。携帯電話ex１１４は、表示部ex３５８及び操作キー部ex３６６を備えた本体部の各部を統括的に制御する主制御部ex３６０に対して、電源回路部ex３６１、操作入力制御部ex３６２、映像信号処理部ex３５５、カメラインタフェース部ex３６３、ＬＣＤ（Liquid Crystal Display）制御部ex３５９、変調／復調部ex３５２、多重／分離部ex３５３、音声信号処理部ex３５４、スロット部ex３６４、メモリ部ex３６７がバスex３７０を介して互いに接続されている。
【０１６３】
電源回路部ex３６１は、ユーザの操作により終話及び電源キーがオン状態にされると、バッテリパックから各部に対して電力を供給することにより携帯電話ex１１４を動作可能な状態に起動する。
【０１６４】
携帯電話ex１１４は、ＣＰＵ、ＲＯＭ、ＲＡＭ等を有する主制御部ex３６０の制御に基づいて、音声通話モード時に音声入力部ex３５６で収音した音声信号を音声信号処理部ex３５４でデジタル音声信号に変換し、これを変調／復調部ex３５２でスペクトラム拡散処理し、送信／受信部ex３５１でデジタルアナログ変換処理および周波数変換処理を施した後にアンテナex３５０を介して送信する。また携帯電話ex１１４は、音声通話モード時にアンテナex３５０を介して受信した受信データを増幅して周波数変換処理およびアナログデジタル変換処理を施し、変調／復調部ex３５２でスペクトラム逆拡散処理し、音声信号処理部ex３５４でアナログ音声信号に変換した後、これを音声出力部ex３５７から出力する。
【０１６５】
さらにデータ通信モード時に電子メールを送信する場合、本体部の操作キー部ex３６６等の操作によって入力された電子メールのテキストデータは操作入力制御部ex３６２を介して主制御部ex３６０に送出される。主制御部ex３６０は、テキストデータを変調／復調部ex３５２でスペクトラム拡散処理をし、送信／受信部ex３５１でデジタルアナログ変換処理および周波数変換処理を施した後にアンテナex３５０を介して基地局ex１１０へ送信する。電子メールを受信する場合は、受信したデータに対してこのほぼ逆の処理が行われ、表示部ex３５８に出力される。
【０１６６】
データ通信モード時に映像、静止画、または映像と音声を送信する場合、映像信号処理部ex３５５は、カメラ部ex３６５から供給された映像信号を上記各実施の形態で示した動画像符号化方法によって圧縮符号化し（即ち、本発明の一態様に係る画像符号化装置として機能する）、符号化された映像データを多重／分離部ex３５３に送出する。また、音声信号処理部ex３５４は、映像、静止画等をカメラ部ex３６５で撮像中に音声入力部ex３５６で収音した音声信号を符号化し、符号化された音声データを多重／分離部ex３５３に送出する。
【０１６７】
多重／分離部ex３５３は、映像信号処理部ex３５５から供給された符号化された映像データと音声信号処理部ex３５４から供給された符号化された音声データを所定の方式で多重化し、その結果得られる多重化データを変調／復調部（変調／復調回路部）ex３５２でスペクトラム拡散処理をし、送信／受信部ex３５１でデジタルアナログ変換処理及び周波数変換処理を施した後にアンテナex３５０を介して送信する。
【０１６８】
データ通信モード時にホームページ等にリンクされた動画像ファイルのデータを受信する場合、または映像およびもしくは音声が添付された電子メールを受信する場合、アンテナex３５０を介して受信された多重化データを復号化するために、多重／分離部ex３５３は、多重化データを分離することにより映像データのビットストリームと音声データのビットストリームとに分け、同期バスex３７０を介して符号化された映像データを映像信号処理部ex３５５に供給するとともに、符号化された音声データを音声信号処理部ex３５４に供給する。映像信号処理部ex３５５は、上記各実施の形態で示した動画像符号化方法に対応した動画像復号化方法によって復号化することにより映像信号を復号し（即ち、本発明の一態様に係る画像復号装置として機能する）、ＬＣＤ制御部ex３５９を介して表示部ex３５８から、例えばホームページにリンクされた動画像ファイルに含まれる映像、静止画が表示される。また音声信号処理部ex３５４は、音声信号を復号し、音声出力部ex３５７から音声が出力される。
【０１６９】
また、上記携帯電話ex１１４等の端末は、テレビex３００と同様に、符号化器・復号化器を両方持つ送受信型端末の他に、符号化器のみの送信端末、復号化器のみの受信端末という３通りの実装形式が考えられる。さらに、デジタル放送用システムex２００において、映像データに音楽データなどが多重化された多重化データを受信、送信するとして説明したが、音声データ以外に映像に関連する文字データなどが多重化されたデータであってもよいし、多重化データではなく映像データ自体であってもよい。
【０１７０】
このように、上記各実施の形態で示した動画像符号化方法あるいは動画像復号化方法を上述したいずれの機器・システムに用いることは可能であり、そうすることで、上記各実施の形態で説明した効果を得ることができる。
【０１７１】
また、本発明はかかる上記実施の形態に限定されるものではなく、本発明の範囲を逸脱することなく種々の変形または修正が可能である。
【０１７２】
（実施の形態４）
上記各実施の形態で示した動画像符号化方法または装置と、ＭＰＥＧ−２、ＭＰＥＧ４−ＡＶＣ、ＶＣ−１など異なる規格に準拠した動画像符号化方法または装置とを、必要に応じて適宜切替えることにより、映像データを生成することも可能である。
【０１７３】
ここで、それぞれ異なる規格に準拠する複数の映像データを生成した場合、復号する際に、それぞれの規格に対応した復号方法を選択する必要がある。しかしながら、復号する映像データが、どの規格に準拠するものであるか識別できないため、適切な復号方法を選択することができないという課題を生じる。
【０１７４】
この課題を解決するために、映像データに音声データなどを多重化した多重化データは、映像データがどの規格に準拠するものであるかを示す識別情報を含む構成とする。上記各実施の形態で示す動画像符号化方法または装置によって生成された映像データを含む多重化データの具体的な構成を以下説明する。多重化データは、ＭＰＥＧ−２トランスポートストリーム形式のデジタルストリームである。
【０１７５】
図１７は、多重化データの構成を示す図である。図１７に示すように多重化データは、ビデオストリーム、オーディオストリーム、プレゼンテーショングラフィックスストリーム（ＰＧ）、インタラクティブグラフィックスストリームのうち、１つ以上を多重化することで得られる。ビデオストリームは映画の主映像および副映像を、オーディオストリーム（ＩＧ）は映画の主音声部分とその主音声とミキシングする副音声を、プレゼンテーショングラフィックスストリームは、映画の字幕をそれぞれ示している。ここで主映像とは画面に表示される通常の映像を示し、副映像とは主映像の中に小さな画面で表示する映像のことである。また、インタラクティブグラフィックスストリームは、画面上にＧＵＩ部品を配置することにより作成される対話画面を示している。ビデオストリームは、上記各実施の形態で示した動画像符号化方法または装置、従来のＭＰＥＧ−２、ＭＰＥＧ４−ＡＶＣ、ＶＣ−１などの規格に準拠した動画像符号化方法または装置によって符号化されている。オーディオストリームは、ドルビーＡＣ−３、Ｄｏｌｂｙ  Ｄｉｇｉｔａｌ  Ｐｌｕｓ、ＭＬＰ、ＤＴＳ、ＤＴＳ−ＨＤ、または、リニアＰＣＭのなどの方式で符号化されている。
【０１７６】
多重化データに含まれる各ストリームはＰＩＤによって識別される。例えば、映画の映像に利用するビデオストリームには０ｘ１０１１が、オーディオストリームには０ｘ１１００から０ｘ１１１Ｆまでが、プレゼンテーショングラフィックスには０ｘ１２００から０ｘ１２１Ｆまでが、インタラクティブグラフィックスストリームには０ｘ１４００から０ｘ１４１Ｆまでが、映画の副映像に利用するビデオストリームには０ｘ１Ｂ００から０ｘ１Ｂ１Ｆまで、主音声とミキシングする副音声に利用するオーディオストリームには０ｘ１Ａ００から０ｘ１Ａ１Ｆが、それぞれ割り当てられている。
【０１７７】
図１８は、多重化データがどのように多重化されるかを模式的に示す図である。まず、複数のビデオフレームからなるビデオストリームex２３５、複数のオーディオフレームからなるオーディオストリームex２３８を、それぞれＰＥＳパケット列ex２３６およびex２３９に変換し、ＴＳパケットex２３７およびex２４０に変換する。同じくプレゼンテーショングラフィックスストリームex２４１およびインタラクティブグラフィックスex２４４のデータをそれぞれＰＥＳパケット列ex２４２およびex２４５に変換し、さらにＴＳパケットex２４３およびex２４６に変換する。多重化データex２４７はこれらのＴＳパケットを１本のストリームに多重化することで構成される。
【０１７８】
図１９は、ＰＥＳパケット列に、ビデオストリームがどのように格納されるかをさらに詳しく示している。図１９における第１段目はビデオストリームのビデオフレーム列を示す。第２段目は、ＰＥＳパケット列を示す。図１９の矢印ｙｙ１，ｙｙ２，ｙｙ３，ｙｙ４に示すように、ビデオストリームにおける複数のＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  ＵｎｉｔであるＩピクチャ、Ｂピクチャ、Ｐピクチャは、ピクチャ毎に分割され、ＰＥＳパケットのペイロードに格納される。各ＰＥＳパケットはＰＥＳヘッダを持ち、ＰＥＳヘッダには、ピクチャの表示時刻であるＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｔｉｍｅ−Ｓｔａｍｐ）やピクチャの復号時刻であるＤＴＳ（Ｄｅｃｏｄｉｎｇ  Ｔｉｍｅ−Ｓｔａｍｐ）が格納される。
【０１７９】
図２０は、多重化データに最終的に書き込まれるＴＳパケットの形式を示している。ＴＳパケットは、ストリームを識別するＰＩＤなどの情報を持つ４ＢｙｔｅのＴＳヘッダとデータを格納する１８４ＢｙｔｅのＴＳペイロードから構成される１８８Ｂｙｔｅ固定長のパケットであり、上記ＰＥＳパケットは分割されＴＳペイロードに格納される。ＢＤ−ＲＯＭの場合、ＴＳパケットには、４ＢｙｔｅのＴＰ＿Ｅｘｔｒａ＿Ｈｅａｄｅｒが付与され、１９２Ｂｙｔｅのソースパケットを構成し、多重化データに書き込まれる。ＴＰ＿Ｅｘｔｒａ＿ＨｅａｄｅｒにはＡＴＳ（Ａｒｒｉｖａｌ＿Ｔｉｍｅ＿Ｓｔａｍｐ）などの情報が記載される。ＡＴＳは当該ＴＳパケットのデコーダのＰＩＤフィルタへの転送開始時刻を示す。多重化データには図２０下段に示すようにソースパケットが並ぶこととなり、多重化データの先頭からインクリメントする番号はＳＰＮ（ソースパケットナンバー）と呼ばれる。
【０１８０】
また、多重化データに含まれるＴＳパケットには、映像・音声・字幕などの各ストリーム以外にもＰＡＴ（Ｐｒｏｇｒａｍ  Ａｓｓｏｃｉａｔｉｏｎ  Ｔａｂｌｅ）、ＰＭＴ（Ｐｒｏｇｒａｍ  Ｍａｐ  Ｔａｂｌｅ）、ＰＣＲ（Ｐｒｏｇｒａｍ  Ｃｌｏｃｋ  Ｒｅｆｅｒｅｎｃｅ）などがある。ＰＡＴは多重化データ中に利用されるＰＭＴのＰＩＤが何であるかを示し、ＰＡＴ自身のＰＩＤは０で登録される。ＰＭＴは、多重化データ中に含まれる映像・音声・字幕などの各ストリームのＰＩＤと各ＰＩＤに対応するストリームの属性情報を持ち、また多重化データに関する各種ディスクリプタを持つ。ディスクリプタには多重化データのコピーを許可・不許可を指示するコピーコントロール情報などがある。ＰＣＲは、ＡＴＳの時間軸であるＡＴＣ（Ａｒｒｉｖａｌ  Ｔｉｍｅ  Ｃｌｏｃｋ）とＰＴＳ・ＤＴＳの時間軸であるＳＴＣ（Ｓｙｓｔｅｍ  Ｔｉｍｅ  Ｃｌｏｃｋ）の同期を取るために、そのＰＣＲパケットがデコーダに転送されるＡＴＳに対応するＳＴＣ時間の情報を持つ。
【０１８１】
図２１はＰＭＴのデータ構造を詳しく説明する図である。ＰＭＴの先頭には、そのＰＭＴに含まれるデータの長さなどを記したＰＭＴヘッダが配置される。その後ろには、多重化データに関するディスクリプタが複数配置される。上記コピーコントロール情報などが、ディスクリプタとして記載される。ディスクリプタの後には、多重化データに含まれる各ストリームに関するストリーム情報が複数配置される。ストリーム情報は、ストリームの圧縮コーデックなどを識別するためストリームタイプ、ストリームのＰＩＤ、ストリームの属性情報（フレームレート、アスペクト比など）が記載されたストリームディスクリプタから構成される。ストリームディスクリプタは多重化データに存在するストリームの数だけ存在する。
【０１８２】
記録媒体などに記録する場合には、上記多重化データは、多重化データ情報ファイルと共に記録される。
【０１８３】
多重化データ情報ファイルは、図２２に示すように多重化データの管理情報であり、多重化データと１対１に対応し、多重化データ情報、ストリーム属性情報とエントリマップから構成される。
【０１８４】
多重化データ情報は図２２に示すようにシステムレート、再生開始時刻、再生終了時刻から構成されている。システムレートは多重化データの、後述するシステムターゲットデコーダのＰＩＤフィルタへの最大転送レートを示す。多重化データ中に含まれるＡＴＳの間隔はシステムレート以下になるように設定されている。再生開始時刻は多重化データの先頭のビデオフレームのＰＴＳであり、再生終了時刻は多重化データの終端のビデオフレームのＰＴＳに１フレーム分の再生間隔を足したものが設定される。
【０１８５】
ストリーム属性情報は図２３に示すように、多重化データに含まれる各ストリームについての属性情報が、ＰＩＤ毎に登録される。属性情報はビデオストリーム、オーディオストリーム、プレゼンテーショングラフィックスストリーム、インタラクティブグラフィックスストリーム毎に異なる情報を持つ。ビデオストリーム属性情報は、そのビデオストリームがどのような圧縮コーデックで圧縮されたか、ビデオストリームを構成する個々のピクチャデータの解像度がどれだけであるか、アスペクト比はどれだけであるか、フレームレートはどれだけであるかなどの情報を持つ。オーディオストリーム属性情報は、そのオーディオストリームがどのような圧縮コーデックで圧縮されたか、そのオーディオストリームに含まれるチャンネル数は何であるか、何の言語に対応するか、サンプリング周波数がどれだけであるかなどの情報を持つ。これらの情報は、プレーヤが再生する前のデコーダの初期化などに利用される。
【０１８６】
本実施の形態においては、上記多重化データのうち、ＰＭＴに含まれるストリームタイプを利用する。また、記録媒体に多重化データが記録されている場合には、多重化データ情報に含まれる、ビデオストリーム属性情報を利用する。具体的には、上記各実施の形態で示した動画像符号化方法または装置において、ＰＭＴに含まれるストリームタイプ、または、ビデオストリーム属性情報に対し、上記各実施の形態で示した動画像符号化方法または装置によって生成された映像データであることを示す固有の情報を設定するステップまたは手段を設ける。この構成により、上記各実施の形態で示した動画像符号化方法または装置によって生成した映像データと、他の規格に準拠する映像データとを識別することが可能になる。
【０１８７】
また、本実施の形態における動画像復号化方法のステップを図２４に示す。ステップexＳ１００において、多重化データからＰＭＴに含まれるストリームタイプ、または、多重化データ情報に含まれるビデオストリーム属性情報を取得する。次に、ステップexＳ１０１において、ストリームタイプ、または、ビデオストリーム属性情報が上記各実施の形態で示した動画像符号化方法または装置によって生成された多重化データであることを示しているか否かを判断する。そして、ストリームタイプ、または、ビデオストリーム属性情報が上記各実施の形態で示した動画像符号化方法または装置によって生成されたものであると判断された場合には、ステップexＳ１０２において、上記各実施の形態で示した動画像復号方法により復号を行う。また、ストリームタイプ、または、ビデオストリーム属性情報が、従来のＭＰＥＧ−２、ＭＰＥＧ４−ＡＶＣ、ＶＣ−１などの規格に準拠するものであることを示している場合には、ステップexＳ１０３において、従来の規格に準拠した動画像復号方法により復号を行う。
【０１８８】
このように、ストリームタイプ、または、ビデオストリーム属性情報に新たな固有値を設定することにより、復号する際に、上記各実施の形態で示した動画像復号化方法または装置で復号可能であるかを判断することができる。従って、異なる規格に準拠する多重化データが入力された場合であっても、適切な復号化方法または装置を選択することができるため、エラーを生じることなく復号することが可能となる。また、本実施の形態で示した動画像符号化方法または装置、または、動画像復号方法または装置を、上述したいずれの機器・システムに用いることも可能である。
【０１８９】
（実施の形態５）
上記各実施の形態で示した動画像符号化方法および装置、動画像復号化方法および装置は、典型的には集積回路であるＬＳＩで実現される。一例として、図２５に１チップ化されたＬＳＩex５００の構成を示す。ＬＳＩex５００は、以下に説明する要素ex５０１、ex５０２、ex５０３、ex５０４、ex５０５、ex５０６、ex５０７、ex５０８、ex５０９を備え、各要素はバスex５１０を介して接続している。電源回路部ex５０５は電源がオン状態の場合に各部に対して電力を供給することで動作可能な状態に起動する。
【０１９０】
例えば符号化処理を行う場合には、ＬＳＩex５００は、ＣＰＵex５０２、メモリコントローラex５０３、ストリームコントローラex５０４、駆動周波数制御部ex５１２等を有する制御部ex５０１の制御に基づいて、ＡＶ  Ｉ／Ｏex５０９によりマイクex１１７やカメラex１１３等からＡＶ信号を入力する。入力されたＡＶ信号は、一旦ＳＤＲＡＭ等の外部のメモリex５１１に蓄積される。制御部ex５０１の制御に基づいて、蓄積したデータは処理量や処理速度に応じて適宜複数回に分けるなどされ信号処理部ex５０７に送られ、信号処理部ex５０７において音声信号の符号化および／または映像信号の符号化が行われる。ここで映像信号の符号化処理は上記各実施の形態で説明した符号化処理である。信号処理部ex５０７ではさらに、場合により符号化された音声データと符号化された映像データを多重化するなどの処理を行い、ストリームＩ／Ｏex５０６から外部に出力する。この出力された多重化データは、基地局ex１０７に向けて送信されたり、または記録メディアex２１５に書き込まれたりする。なお、多重化する際には同期するよう、一旦バッファex５０８にデータを蓄積するとよい。
【０１９１】
なお、上記では、メモリex５１１がＬＳＩex５００の外部の構成として説明したが、ＬＳＩex５００の内部に含まれる構成であってもよい。バッファex５０８も１つに限ったものではなく、複数のバッファを備えていてもよい。また、ＬＳＩex５００は１チップ化されてもよいし、複数チップ化されてもよい。
【０１９２】
また、上記では、制御部ex５０１が、ＣＰＵex５０２、メモリコントローラex５０３、ストリームコントローラex５０４、駆動周波数制御部ex５１２等を有するとしているが、制御部ex５０１の構成は、この構成に限らない。例えば、信号処理部ex５０７がさらにＣＰＵを備える構成であってもよい。信号処理部ex５０７の内部にもＣＰＵを設けることにより、処理速度をより向上させることが可能になる。また、他の例として、ＣＰＵex５０２が信号処理部ex５０７、または信号処理部ex５０７の一部である例えば音声信号処理部を備える構成であってもよい。このような場合には、制御部ex５０１は、信号処理部ex５０７、またはその一部を有するＣＰＵex５０２を備える構成となる。
【０１９３】
なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
【０１９４】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路または汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。このようなプログラマブル・ロジック・デバイスは、典型的には、ソフトウェア又はファームウェアを構成するプログラムを、ロードする又はメモリ等から読み込むことで、上記各実施の形態で示した動画像符号化方法、又は動画像復号化方法を実行することができる。
【０１９５】
さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適応等が可能性としてありえる。
【０１９６】
（実施の形態６）
上記各実施の形態で示した動画像符号化方法または装置によって生成された映像データを復号する場合、従来のＭＰＥＧ−２、ＭＰＥＧ４−ＡＶＣ、ＶＣ−１などの規格に準拠する映像データを復号する場合に比べ、処理量が増加することが考えられる。そのため、ＬＳＩex５００において、従来の規格に準拠する映像データを復号する際のＣＰＵex５０２の駆動周波数よりも高い駆動周波数に設定する必要がある。しかし、駆動周波数を高くすると、消費電力が高くなるという課題が生じる。
【０１９７】
この課題を解決するために、テレビex３００、ＬＳＩex５００などの動画像復号化装置は、映像データがどの規格に準拠するものであるかを識別し、規格に応じて駆動周波数を切替える構成とする。図２６は、本実施の形態における構成ex８００を示している。駆動周波数切替え部ex８０３は、映像データが、上記各実施の形態で示した動画像符号化方法または装置によって生成されたものである場合には、駆動周波数を高く設定する。そして、上記各実施の形態で示した動画像復号化方法を実行する復号処理部ex８０１に対し、映像データを復号するよう指示する。一方、映像データが、従来の規格に準拠する映像データである場合には、映像データが、上記各実施の形態で示した動画像符号化方法または装置によって生成されたものである場合に比べ、駆動周波数を低く設定する。そして、従来の規格に準拠する復号処理部ex８０２に対し、映像データを復号するよう指示する。
【０１９８】
より具体的には、駆動周波数切替え部ex８０３は、図２５のＣＰＵex５０２と駆動周波数制御部ex５１２から構成される。また、上記各実施の形態で示した動画像復号化方法を実行する復号処理部ex８０１、および、従来の規格に準拠する復号処理部ex８０２は、図２５の信号処理部ex５０７に該当する。ＣＰＵex５０２は、映像データがどの規格に準拠するものであるかを識別する。そして、ＣＰＵex５０２からの信号に基づいて、駆動周波数制御部ex５１２は、駆動周波数を設定する。また、ＣＰＵex５０２からの信号に基づいて、信号処理部ex５０７は、映像データの復号を行う。ここで、映像データの識別には、例えば、実施の形態４で記載した識別情報を利用することが考えられる。識別情報に関しては、実施の形態４で記載したものに限られず、映像データがどの規格に準拠するか識別できる情報であればよい。例えば、映像データがテレビに利用されるものであるか、ディスクに利用されるものであるかなどを識別する外部信号に基づいて、映像データがどの規格に準拠するものであるか識別可能である場合には、このような外部信号に基づいて識別してもよい。また、ＣＰＵex５０２における駆動周波数の選択は、例えば、図２８のような映像データの規格と、駆動周波数とを対応付けたルックアップテーブルに基づいて行うことが考えられる。ルックアップテーブルを、バッファex５０８や、ＬＳＩの内部メモリに格納しておき、ＣＰＵex５０２がこのルックアップテーブルを参照することにより、駆動周波数を選択することが可能である。
【０１９９】
図２７は、本実施の形態の方法を実施するステップを示している。まず、ステップexＳ２００では、信号処理部ex５０７において、多重化データから識別情報を取得する。次に、ステップexＳ２０１では、ＣＰＵex５０２において、識別情報に基づいて映像データが上記各実施の形態で示した符号化方法または装置によって生成されたものであるか否かを識別する。映像データが上記各実施の形態で示した符号化方法または装置によって生成されたものである場合には、ステップexＳ２０２において、駆動周波数を高く設定する信号を、ＣＰＵex５０２が駆動周波数制御部ex５１２に送る。そして、駆動周波数制御部ex５１２において、高い駆動周波数に設定される。一方、従来のＭＰＥＧ−２、ＭＰＥＧ４−ＡＶＣ、ＶＣ−１などの規格に準拠する映像データであることを示している場合には、ステップexＳ２０３において、駆動周波数を低く設定する信号を、ＣＰＵex５０２が駆動周波数制御部ex５１２に送る。そして、駆動周波数制御部ex５１２において、映像データが上記各実施の形態で示した符号化方法または装置によって生成されたものである場合に比べ、低い駆動周波数に設定される。
【０２００】
さらに、駆動周波数の切替えに連動して、ＬＳＩex５００またはＬＳＩex５００を含む装置に与える電圧を変更することにより、省電力効果をより高めることが可能である。例えば、駆動周波数を低く設定する場合には、これに伴い、駆動周波数を高く設定している場合に比べ、ＬＳＩex５００またはＬＳＩex５００を含む装置に与える電圧を低く設定することが考えられる。
【０２０１】
また、駆動周波数の設定方法は、復号する際の処理量が大きい場合に、駆動周波数を高く設定し、復号する際の処理量が小さい場合に、駆動周波数を低く設定すればよく、上述した設定方法に限らない。例えば、ＭＰＥＧ４−ＡＶＣ規格に準拠する映像データを復号する処理量の方が、上記各実施の形態で示した動画像符号化方法または装置により生成された映像データを復号する処理量よりも大きい場合には、駆動周波数の設定を上述した場合の逆にすることが考えられる。
【０２０２】
さらに、駆動周波数の設定方法は、駆動周波数を低くする構成に限らない。例えば、識別情報が、上記各実施の形態で示した動画像符号化方法または装置によって生成された映像データであることを示している場合には、ＬＳＩex５００またはＬＳＩex５００を含む装置に与える電圧を高く設定し、従来のＭＰＥＧ−２、ＭＰＥＧ４−ＡＶＣ、ＶＣ−１などの規格に準拠する映像データであることを示している場合には、ＬＳＩex５００またはＬＳＩex５００を含む装置に与える電圧を低く設定することも考えられる。また、他の例としては、識別情報が、上記各実施の形態で示した動画像符号化方法または装置によって生成された映像データであることを示している場合には、ＣＰＵex５０２の駆動を停止させることなく、従来のＭＰＥＧ−２、ＭＰＥＧ４−ＡＶＣ、ＶＣ−１などの規格に準拠する映像データであることを示している場合には、処理に余裕があるため、ＣＰＵex５０２の駆動を一時停止させることも考えられる。識別情報が、上記各実施の形態で示した動画像符号化方法または装置によって生成された映像データであることを示している場合であっても、処理に余裕があれば、ＣＰＵex５０２の駆動を一時停止させることも考えられる。この場合は、従来のＭＰＥＧ−２、ＭＰＥＧ４−ＡＶＣ、ＶＣ−１などの規格に準拠する映像データであることを示している場合に比べて、停止時間を短く設定することが考えられる。
【０２０３】
このように、映像データが準拠する規格に応じて、駆動周波数を切替えることにより、省電力化を図ることが可能になる。また、電池を用いてＬＳＩex５００またはＬＳＩex５００を含む装置を駆動している場合には、省電力化に伴い、電池の寿命を長くすることが可能である。
【０２０４】
（実施の形態７）
テレビや、携帯電話など、上述した機器・システムには、異なる規格に準拠する複数の映像データが入力される場合がある。このように、異なる規格に準拠する複数の映像データが入力された場合にも復号できるようにするために、ＬＳＩex５００の信号処理部ex５０７が複数の規格に対応している必要がある。しかし、それぞれの規格に対応する信号処理部ex５０７を個別に用いると、ＬＳＩex５００の回路規模が大きくなり、また、コストが増加するという課題が生じる。
【０２０５】
この課題を解決するために、上記各実施の形態で示した動画像復号方法を実行するための復号処理部と、従来のＭＰＥＧ−２、ＭＰＥＧ４−ＡＶＣ、ＶＣ−１などの規格に準拠する復号処理部とを一部共有化する構成とする。この構成例を図２９Ａのex９００に示す。例えば、上記各実施の形態で示した動画像復号方法と、ＭＰＥＧ４−ＡＶＣ規格に準拠する動画像復号方法とは、エントロピー符号化、逆量子化、デブロッキング・フィルタ、動き補償などの処理において処理内容が一部共通する。共通する処理内容については、ＭＰＥＧ４−ＡＶＣ規格に対応する復号処理部ex９０２を共有し、ＭＰＥＧ４−ＡＶＣ規格に対応しない、本発明の一態様に特有の他の処理内容については、専用の復号処理部ex９０１を用いるという構成が考えられる。特に、本発明の一態様は、バッファ制御に特徴を有していることから、例えば、バッファ制御については専用の復号処理部ex９０１を用い、それ以外の逆量子化、エントロピー復号、デブロッキング・フィルタ、動き補償のいずれか、または、全ての処理については、復号処理部を共有することが考えられる。復号処理部の共有化に関しては、共通する処理内容については、上記各実施の形態で示した動画像復号化方法を実行するための復号処理部を共有し、ＭＰＥＧ４−ＡＶＣ規格に特有の処理内容については、専用の復号処理部を用いる構成であってもよい。
【０２０６】
また、処理を一部共有化する他の例を図２９Ｂのex１０００に示す。この例では、本発明の一態様に特有の処理内容に対応した専用の復号処理部ex１００１と、他の従来規格に特有の処理内容に対応した専用の復号処理部ex１００２と、本発明の一態様に係る動画像復号方法と他の従来規格の動画像復号方法とに共通する処理内容に対応した共用の復号処理部ex１００３とを用いる構成としている。ここで、専用の復号処理部ex１００１、ex１００２は、必ずしも本発明の一態様、または、他の従来規格に特有の処理内容に特化したものではなく、他の汎用処理を実行できるものであってもよい。また、本実施の形態の構成を、ＬＳＩex５００で実装することも可能である。
【０２０７】
このように、本発明の一態様に係る動画像復号方法と、従来の規格の動画像復号方法とで共通する処理内容について、復号処理部を共有することにより、ＬＳＩの回路規模を小さくし、かつ、コストを低減することが可能である。
【産業上の利用可能性】
【０２０８】
本発明は、画像符号化方法、画像復号方法、画像符号化装置及び画像復号装置に適用できる。また、本発明は、画像符号化装置を備える、テレビ、デジタルビデオレコーダー、カーナビゲーション、携帯電話、デジタルカメラ、及びデジタルビデオカメラ等の高解像度の情報表示機器又は撮像機器に利用可能である。
【符号の説明】
【０２０９】
１００  画像符号化装置
１０１  入力画像制御部
１０２  ＭＶＣエンコーダ
１０３  レベル解析部
１０４  最大ビュー数算出器
１０５  ＭＶＣ最大バッファサイズ算出器
１２１  入力画像信号
１２２  拡張ビュー画像
１２３  ベースビュー画像
１２４、２２１  ＭＶＣビットストリーム
１２５、２２３  画像サイズ
１２６  レベル信号
１２７  最大画面内画素数
１２８  最大バッファサイズ
１２９  最大ビュー数
１３０  ＭＶＣ最大バッファサイズ
１４１  拡張ビュー符号化部
１４２  ベースビュー符号化部
１４３  ビュー多重化部
１５１  再構築ビュー画像
１５２  拡張ビュー符号化信号
１５３  ベースビュー符号化信号
２００  画像復号装置
２０１  符号列解析部
２０２  ＭＶＣデコーダ
２２２  符号化データ
２２４  ＤＰＢピクチャ（ビュー）数
２２５  出力画像
【図１】
2014010192.tif 000003
【図２】
2014010192.tif 000004
【図３】
2014010192.tif 000005
【図４】
2014010192.tif 000006
【図５】
2014010192.tif 000007
【図６】
2014010192.tif 000008
【図７】
2014010192.tif 000009
【図８】
2014010192.tif 000010
【図９】
2014010192.tif 000011
【図１０】
2014010192.tif 000012
【図１１】
2014010192.tif 000013
【図１２】
2014010192.tif 000014
【図１３】
2014010192.tif 000015
【図１４】
2014010192.tif 000016
【図１５】
2014010192.tif 000017
【図１６Ａ】
2014010192.tif 000018
【図１６Ｂ】
2014010192.tif 000019
【図１７】
2014010192.tif 000020
【図１８】
2014010192.tif 000021
【図１９】
2014010192.tif 000022
【図２０】
2014010192.tif 000023
【図２１】
2014010192.tif 000024
【図２２】
2014010192.tif 000025
【図２３】
2014010192.tif 000026
【図２４】
2014010192.tif 000027
【図２５】
2014010192.tif 000028
【図２６】
2014010192.tif 000029
【図２７】
2014010192.tif 000030
【図２８】
2014010192.tif 000031
【図２９Ａ】
2014010192.tif 000032
【図２９Ｂ】
2014010192.tif 000033
【国際調査報告】
2014010192.tif 000034
2014010192.tif 000035
2014010192.tif 000036