(57)【要約】【課題】複数の視点からの画像を複数のエンコーダでエンコードする際に、エンコーダ間で全く情報やデータの授受を行わないエンコーダであっても、エンコード後のストリームが所定の制約に違反せず、定められた規格に準拠のストリームを生成することが可能な映像処理装置を提供する。【解決手段】複数の視点からの画像を符号化してストリームを出力する符号化部と、前記符号化部が符号化したストリームに対するデータ書き換え部と、を備え、前記符号化部は、基準視点のベース画像をエンコードしてベースストリームを出力するベースエンコーダと、前記基準視点とは異なる一以上の視点のディペンデント画像をエンコードしてディペンデントストリームを出力するディペンデントエンコーダと、を含み、前記データ書き換え部は、前記ベースエンコーダ及び／または前記ディペンデントエンコーダの出力に対してデータの書き換えを行う、映像処理装置が提供される。【選択図】図１
2012039312.tif 000002
【特許請求の範囲】
【請求項１】
複数の視点からの画像を符号化してストリームを出力する符号化部と、
前記符号化部が符号化したストリームに対するデータ書き換え部と、
を備え、
前記符号化部は、
基準視点のベース画像をエンコードしてベースストリームを出力するベースエンコーダと、
前記基準視点とは異なる一以上の視点のディペンデント画像をエンコードしてディペンデントストリームを出力するディペンデントエンコーダと、
を含み、
前記データ書き換え部は、前記ベースエンコーダ及び／または前記ディペンデントエンコーダの出力に対してデータの書き換えを行う、映像処理装置。
【請求項２】
前記データ書き換え部が書き換えるデータは、バッファ期間を示す情報である、請求項１に記載の映像処理装置。
【請求項３】
複数の視点からの画像を符号化する符号化部を備え、
前記符号化部は、視点ごとに設けた複数の視点からの画像をエンコードする複数のエンコーダを含み、
前記符号化部は、予め定められた規格を満たすためのレート制御上の所定の制約に基づいて前記複数のエンコーダによるエンコードを実行する、映像処理装置。
【請求項４】
前記所定の制約は、複数の視点からの画像を符号化した後のｔｒａｃｅ  ｒａｔｅが各画像のみのｔｒａｃｅ  ｒａｔｅを全て加算したもの以上であり、かつ、複数の視点からの画像を符号化した後のｃｐｂ  ｓｉｚｅが、各画像のみのｃｐｂ  ｓｉｚｅを全て加算したもの以上である、請求項３に記載の映像処理装置。
【請求項５】
前記符号化部は、ＧＯＰ（Ｇｒｏｕｐ  ｏｆ  Ｐｉｃｔｕｒｅ）の先頭においてバッファ期間を示す情報を符号化する時の符号化ピクチャバッファのビット占有量が常に所定の固定値以上になるように符号量を制御する、請求項４に記載の映像処理装置。
【請求項６】
前記所定の制約は、基準視点のベース画像と、追加画像のディペンデント画像のシンタックス上のｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅでバッファトレースして得られるｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙが、常に前記ベース画像と前記ディペンデント画像とを合わせたｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ以上の値であり、かつ、前記ベース画像と、前記ディペンデント画像との実際のｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅでバッファトレースして得られるｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙが、常に前記ベース画像と前記ディペンデント画像とを合わせたｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ以下の値である、請求項３に記載の映像処理装置。
【請求項７】
前記所定の制約は、前記ベース画像及び前記ディペンデント画像のシンタックス上の（ｔｒａｃｅ＿ｒａｔｅ／ｐｉｃｔｕｒｅ＿ｄｕｒａｔｉｏｎ）＊ｎの値が前記ベース画像及び前記ディペンデント画像の全てのアクセスユニットにおける前記ベース画像及び前記ディペンデント画像の符号量の和以上である関係を満たすことである、請求項６に記載の映像処理装置。
【請求項８】
前記所定の制約は、前記ベース画像と前記ディペンデント画像との内、符号量を使い込んでいる方のｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩを符号化する際のＣＰＢのビット占有量をｘ、符号量を使い込んでいる方のｔｒａｃｅ  ｒａｔｅをｔｒａｃｅ  ｒａｔｅ０、符号量を使い込んでいる方のｃｐｂ  ｓｉｚｅをｃｐｂ  ｓｉｚｅ０、符号量を使い込んでいない方のｔｒａｃｅ  ｒａｔｅをｔｒａｃｅ  ｒａｔｅ１、符号量を使い込んでいない方のｃｐｂ  ｓｉｚｅをｃｐｂ  ｓｉｚｅ１とした場合に、ｘ＞＝（ａｃｔｕａｌ  ｃｐｂ  ｓｉｚｅ１）＊（（ｂａｓｅ＋ｄｅｐｅｎｄｅｎｔのｓｙｎｔａｘ  ｔｒａｃｅ  ｒａｔｅ）／（ｓｙｎｔａｘ  ｔｒａｃｅ  ｒａｔｅ１）−１）を満たすことである、請求項６に記載の映像処理装置。
【請求項９】
前記所定の制約は、ｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩを符号化する際のＣＰＢのビット占有量を常に固定値以上とすることである、請求項３に記載の映像処理装置。
【請求項１０】
前記複数のエンコーダは、予め定められた規格を満たすための前記制約に基づいて符号化の際の符号量を制御する符号量制御部と、前記符号量制御部が制御する符号量に基づいて画像を符号化する符号化器と、を含む、請求項３に記載の映像処理装置。
【請求項１１】
前記符号化部の符号化により生成されるストリームに対してデータを書き換えて前記規格を満たすデータ書き換え部をさらに備える、請求項３に記載の映像処理装置。
【請求項１２】
前記データ書き換え部が書き換えるデータは、バッファ期間を示す情報である、請求項１１に記載の映像処理装置。
【請求項１３】
複数の視点からの画像を符号化してストリームを出力する符号化ステップと、
前記符号化ステップで符号化したストリームに対するデータ書き換えステップと、
を備え、
前記符号化ステップは、
基準視点のベース画像をエンコードしてベースストリームを出力するベースエンコードステップと、
前記基準視点とは異なる一以上の視点のディペンデント画像をエンコードしてディペンデントストリームを出力するディペンデントエンコードステップと、
を含み、
前記データ書き換えステップは、前記ベースエンコードステップ及び／または前記ディペンデントエンコードステップの出力に対してデータの書き換えを行う、映像処理方法。
【請求項１４】
複数の視点からの画像を符号化する符号化ステップを備え、
前記符号化ステップは、視点ごとに設けた複数の視点からの画像をエンコードする複数のエンコーダによるエンコードステップを含み、
前記符号化ステップは、予め定められた規格を満たすためのレート制御上の所定の制約に基づいて前記複数のエンコーダによるエンコードを実行する、映像処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、映像処理装置及び映像処理方法に関する。
【背景技術】
【０００２】
近年、画像情報をデジタルとして取り扱い、その際、効率の高い情報の伝送、蓄積を目的とし、画像情報特有の冗長性を利用して、離散コサイン変換等の直交変換と動き補償により圧縮する方式（例えば、ＭＰＥＧ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ））に準拠した装置が、放送局などの情報配信、及び一般家庭における情報受信の双方において普及しつつある。
【０００３】
さらに、近年ではＡＶＣ（Ａｄｖａｎｃｅｄ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ）（ＭＰＥＧ４  ｐａｒｔ１０、ＩＳＯ／ＩＥＣ  １４４９６−１０  ｜  ＩＴＵ−Ｔ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｕｎｉｏｎ  −  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ  Ｓｅｃｔｏｒ）  Ｈ．２６４）（以下、ＡＶＣ／Ｈ．２６４と称する）という標準の規格化が行われている。ＩＴＵ−Ｔと  ＩＳＯ／ＩＥＣ  の間で、共同でビデオ符号化の標準化を行う、ＪＶＴ（Ｊｏｉｎｔ  Ｖｉｄｅｏ  Ｔｅａｍ）という団体が設立され、この団体で規格化を進めている。Ｈ．２６４はＭＰＥＧ２やＭＰＥＧ４といった従来の符号化方式に比べ、その符号化および復号により多くの演算量が要求されるものの、より高い符号化効率が実現されることが知られている。
【０００４】
ＡＶＣ／Ｈ．２６４は、ＭＰＥＧ２やＭＰＥＧ４といった既存のビデオ符号化方式と比較して、倍以上の高い圧縮効率（符号化効率）を実現するが、その分、復号処理の処理量も飛躍的に増加する。また、画像の高画質化による画像データのデータ量の増大に伴い、復号処理の処理量はさらに増加する。しかしながら、例えば、伝送されてきた符号化データのビットストリームを順次復号する場合や、記録媒体に記録されている符号化データを読み出して復号し、画像を再生する場合のように、復号処理による遅延の許容範囲が少なく、高速に、かつ安定して復号処理を行うことが求められる場合がある。
【０００５】
映像の符号化に関する発明としては、例えば特許文献１、特許文献２に開示されたものがある。特許文献１には、複数のストリームを結合させて符号化する際に、編集点近傍の画像品質の劣化を可能な限り防止することができるように、ＶＢＲストリームにおける編集処理を制御することができる技術が開示されている。また、特許文献２には、複数のエンコーダを用いてベースバンド信号をエンコードして結合する技術が開示されており、１フレームを分割することなく、高速にエンコード処理を実行することができる点が開示されている。
【０００６】
このように、ＡＶＣ／Ｈ．２６４による符号化処理に関する技術がある一方で、ユーザに立体的な奥行きのある映像として知覚させるための立体視（３Ｄ）コンテンツを表示するための家庭用テレビの販売も本格的に開始され、これに伴って多くの３Ｄコンテンツの作成要望が高まってきている。３Ｄコンテンツの符号化方式の中には、ＭＶＣ（Ｍｕｌｔｉｖｉｅｗ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ；多視点映像符号化）という規格がＨ．２６４のバージョン１０で追加されている。ＭＶＣは、基本となるストリーム（ｂａｓｅストリーム）と、関連するストリーム（ｄｅｐｅｎｄｅｎｔストリーム）の符号化が行われる規格である。このように符号化することで、複数の視点で撮影された映像を、それぞれの視点からの映像を独立して扱うよりも効率的に圧縮することができる。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００７−５９９９６号公報
【特許文献２】特開２００８−６６８５１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ＭＶＣは、ＡＶＣ／Ｈ．２６４を拡張するものであるから、ＭＶＣエンコードに際しては既存のＡＶＣ／Ｈ．２６４によるエンコーダを流用することができる。既存のエンコーダを流用できれば、ＭＶＣエンコード専用のエンコーダを別途製作する必要が無いので、エンコーダの製造コストを抑えることができる。
【０００９】
しかし、ＭＶＣエンコード中にｂａｓｅ側とｄｅｐｅｎｄｅｎｔ側とで全く通信を行わないエンコーダから生成されたｂａｓｅおよびｄｅｐｅｎｄｅｎｔのストリームは、ＥＳレベルでｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩが制約を違反し、ＢＤ（Ｂｌｕ−ｌａｙ  Ｄｉｓｃ）  ＭＶＣ準拠のストリームとならない事があるという問題があった。
【００１０】
そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、複数の視点からの画像を複数のエンコーダでエンコードする際に、エンコーダ間で全く情報やデータの授受を行わないエンコーダであっても、エンコード後のストリームが所定の制約に違反せず、定められた規格に準拠のストリームを生成することが可能な、新規かつ改良された映像処理装置及び映像処理方法を提供することにある。
【課題を解決するための手段】
【００１１】
上記課題を解決するために、本発明のある観点によれば、複数の視点からの画像を符号化してストリームを出力する符号化部と、前記符号化部が符号化したストリームに対するデータ書き換え部と、を備え、前記符号化部は、基準視点のベース画像をエンコードしてベースストリームを出力するベースエンコーダと、前記基準視点とは異なる一以上の視点のディペンデント画像をエンコードしてディペンデントストリームを出力するディペンデントエンコーダと、を含み、前記データ書き換え部は、前記ベースエンコーダ及び／または前記ディペンデントエンコーダの出力に対してデータの書き換えを行う、映像処理装置が提供される。
【００１２】
前記データ書き換え部が書き換えるデータは、バッファ期間を示す情報であってもよい。
【００１３】
また、上記課題を解決するために、本発明の別の観点によれば、複数の視点からの画像を符号化する符号化部を備え、前記符号化部は、視点ごとに設けた複数の視点からの画像をエンコードする複数のエンコーダを含み、前記符号化部は、予め定められた規格を満たすためのレート制御上の所定の制約に基づいて前記複数のエンコーダによるエンコードを実行する、映像処理装置が提供される。
【００１４】
前記所定の制約は、複数の視点からの画像を符号化した後のｔｒａｃｅ  ｒａｔｅが各画像のみのｔｒａｃｅ  ｒａｔｅを全て加算したもの以上であり、かつ、複数の視点からの画像を符号化した後のｃｐｂ  ｓｉｚｅが、各画像のみのｃｐｂ  ｓｉｚｅを全て加算したもの以上であってもよい。
【００１５】
前記符号化部は、ＧＯＰ（Ｇｒｏｕｐ  ｏｆ  Ｐｉｃｔｕｒｅ）の先頭においてバッファ期間を示す情報を符号化する時の符号化ピクチャバッファのビット占有量が常に所定の固定値以上になるように符号量を制御してもよい。
【００１６】
前記所定の制約は、基準視点のベース画像と、追加画像のディペンデント画像のシンタックス上のｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅでバッファトレースして得られるｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙが、常に前記ベース画像と前記ディペンデント画像とを合わせたｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ以上の値であり、かつ、前記ベース画像と、前記ディペンデント画像との実際のｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅでバッファトレースして得られるｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙが、常に前記ベース画像と前記ディペンデント画像とを合わせたｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ以下の値であってもよい。
【００１７】
前記所定の制約は、前記ベース画像及び前記ディペンデント画像のシンタックス上の（ｔｒａｃｅ＿ｒａｔｅ／ｐｉｃｔｕｒｅ＿ｄｕｒａｔｉｏｎ）＊ｎの値が前記ベース画像及び前記ディペンデント画像の全てのアクセスユニットにおける前記ベース画像及び前記ディペンデント画像の符号量の和以上である関係を満たすことであってもよい。
【００１８】
前記所定の制約は、前記ベース画像と前記ディペンデント画像との内、符号量を使い込んでいる方のｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩを符号化する際のＣＰＢのビット占有量をｘ、符号量を使い込んでいる方のｔｒａｃｅ  ｒａｔｅをｔｒａｃｅ  ｒａｔｅ０、符号量を使い込んでいる方のｃｐｂ  ｓｉｚｅをｃｐｂ  ｓｉｚｅ０、符号量を使い込んでいない方のｔｒａｃｅ  ｒａｔｅをｔｒａｃｅ  ｒａｔｅ１、符号量を使い込んでいない方のｃｐｂ  ｓｉｚｅをｃｐｂ  ｓｉｚｅ１とした場合に、ｘ＞＝（ａｃｔｕａｌ  ｃｐｂ  ｓｉｚｅ１）＊（（ｂａｓｅ＋ｄｅｐｅｎｄｅｎｔのｓｙｎｔａｘ  ｔｒａｃｅ  ｒａｔｅ）／（ｓｙｎｔａｘ  ｔｒａｃｅ  ｒａｔｅ１）−１）を満たすことであってもよい。
【００１９】
前記所定の制約は、ｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩを符号化する際のＣＰＢのビット占有量を常に固定値以上とすることであってもよい。
【００２０】
前記複数のエンコーダは、予め定められた規格を満たすための前記制約に基づいて符号化の際の符号量を制御する符号量制御部と、前記符号量制御部が制御する符号量に基づいて画像を符号化する符号化器と、を含んでいてもよい。
【００２１】
前記符号化部の符号化により生成されるストリームに対してデータを書き換えて前記規格を満たすデータ書き換え部をさらに備えていてもよい。
【００２２】
前記データ書き換え部が書き換えるデータは、バッファ期間を示す情報であってもよい。
【００２３】
また、上記課題を解決するために、本発明の別の観点によれば、複数の視点からの画像を符号化してストリームを出力する符号化ステップと、前記符号化ステップで符号化したストリームに対するデータ書き換えステップと、を備え、前記符号化ステップは、基準視点のベース画像をエンコードしてベースストリームを出力するベースエンコードステップと、前記基準視点とは異なる一以上の視点のディペンデント画像をエンコードしてディペンデントストリームを出力するディペンデントエンコードステップと、を含み、前記データ書き換えステップは、前記ベースエンコードステップ及び／または前記ディペンデントエンコードステップの出力に対してデータの書き換えを行う、映像処理方法が提供される。
【００２４】
また、上記課題を解決するために、本発明の別の観点によれば、複数の視点からの画像を符号化する符号化ステップを備え、前記符号化ステップは、視点ごとに設けた複数の視点からの画像をエンコードする複数のエンコーダによるエンコードステップを含み、前記符号化ステップは、予め定められた規格を満たすためのレート制御上の所定の制約に基づいて前記複数のエンコーダによるエンコードを実行する、映像処理方法が提供される。
【発明の効果】
【００２５】
以上説明したように本発明によれば、複数の視点からの画像を複数のエンコーダでエンコードする際に、エンコーダ間で全く情報やデータの授受を行わないエンコーダであっても、エンコード後のストリームが所定の制約に違反せず、定められた規格に準拠のストリームを生成することが可能な、新規かつ改良された映像処理装置及び映像処理方法を提供することができる。
【図面の簡単な説明】
【００２６】
【図１】本発明の一実施形態にかかる映像処理装置１００の構成を示す説明図である。
【図２】図１に示したエンコーダユニット１２０の構成を示す説明図である。
【図３Ａ】時間とビット占有量（ｏｃｃｕｐａｎｃｙ）との関係をグラフで示す説明図である。
【図３Ｂ】時間とビット占有量（ｏｃｃｕｐａｎｃｙ）との関係をグラフで示す説明図である。
【図３Ｃ】時間とビット占有量（ｏｃｃｕｐａｎｃｙ）との関係をグラフで示す説明図である。
【図４Ａ】時間とビット占有量（ｏｃｃｕｐａｎｃｙ）との関係をグラフで示す説明図である。
【図４Ｂ】時間とビット占有量（ｏｃｃｕｐａｎｃｙ）との関係をグラフで示す説明図である。
【図５】本発明の一実施形態にかかる映像処理装置１００の動作について説明する流れ図である。
【図６】本発明の一実施形態にかかる映像処理装置１００の変形例の構成を示す説明図である。
【発明を実施するための形態】
【００２７】
以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００２８】
なお、説明は以下の順序で行うものとする。
＜１．本発明の一実施形態＞
［１−１．映像処理装置の構成］
［１−２．エンコーダユニットの構成］
［１−３．映像処理装置の動作］
＜２．まとめ＞
【００２９】
＜１．本発明の一実施形態＞
［１−１．映像処理装置の構成］
図１は、本発明の一実施形態にかかる映像処理装置１００の構成を示す説明図である。以下、図１を用いて本発明の一実施形態にかかる映像処理装置１００の構成について説明する。
【００３０】
図１に示したように、本発明の一実施形態にかかる映像処理装置１００は、ＣＰＵ１０１、１０７と、メモリ１０２、１０８、１１１と、ノースブリッジ１０３と、ＨＤＤ１０４と、サウスブリッジ１０５と、ＰＣＩバス１０６と、コントロールバス１０９と、ＰＣＩブリッジ１１０と、エンコーダユニット１２０と、データ書き換え部１３０と、を含んで構成される。
【００３１】
ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１０１は、ノースブリッジ１０３に接続され、例えば、ＨＤＤ（Ｈａｒｄ  ｄｉｓｋ  Ｄｒｉｖｅ）１０４に記憶されているデータの読み出しなどの処理を制御したり、ＣＰＵ１０７が実行する編集処理を制御するための制御信号やコマンドを生成して出力したりする。ノースブリッジ１０３は、ＰＣＩバス（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ／Ｉｎｔｅｒｆａｃｅ）１０６に接続され、例えば、ＣＰＵ１０１の制御に基づいて、サウスブリッジ１０５を介して、ＨＤＤ１０４に記憶されているデータの供給を受けて、ＰＣＩバス１０６、ＰＣＩブリッジ１１０を介して、メモリ１１１に供給する。また、ノースブリッジ１０３は、メモリ１０２とも接続されており、ＣＰＵ１０１の処理に必要なデータを授受する。
【００３２】
メモリ１０２は、ＣＰＵ１０１が実行する処理に必要なデータを保存する。サウスブリッジ１０５は、ＨＤＤ１０４のデータの書き込みおよび読み出しを制御する。ＨＤＤ１０４には、非圧縮のベースバンド信号が記憶される。
【００３３】
ＰＣＩブリッジ１１０は、メモリ１１１のデータの書き込みおよび読み出しを制御したり、エンコーダユニット１２０への非圧縮データの供給を制御したりするとともに、ＰＣＩバス１０６およびコントロールバス１０９のデータの授受を制御するものである。メモリ１１１は、ＰＣＩブリッジ１１０の制御に基づいて、ＨＤＤ１０４により読み出されたベースバンド信号や、エンコーダユニット１２０から供給される処理後の符号化データを記憶する。
【００３４】
ＣＰＵ１０７は、ノースブリッジ１０３、ＰＣＩバス１０６、ＰＣＩブリッジ１１０、および、コントロールバス１０９を介して、ＣＰＵ１０１から供給された制御信号やコマンドに従って、ＰＣＩブリッジ１１０、及びエンコーダユニット１２０が実行する処理を制御する。メモリ１０８は、ＣＰＵ１０７の処理に必要なデータを記憶する。
【００３５】
エンコーダユニット１２０は、ＣＰＵ１０７の制御の元、ＰＣＩブリッジ１１０から供給されるベースバンド信号に対してエンコード処理を実行して出力するものである。本実施形態では、エンコーダユニット１２０はＭＶＣエンコードを実行する。従って、図１に示したように、エンコーダユニット１２０は、Ｂａｓｅエンコーダ１２１と、Ｄｅｐｅｎｄｅｎｔエンコーダ１２２と、を含んで構成される。Ｂａｓｅエンコーダ１２１は、ＰＣＩブリッジ１１０から供給されるベースバンド信号の内、Ｂａｓｅ画像に対するエンコード処理を実行して、Ｂａｓｅストリームを出力するものである。そしてＤｅｐｅｎｄｅｎｔエンコーダ１２２は、ＰＣＩブリッジ１１０から供給されるベースバンド信号の内、Ｄｅｐｅｎｄｅｎｔ画像に対するエンコード処理を実行して、Ｄｅｐｅｎｄｅｎｔストリームを出力するものである。
【００３６】
Ｂａｓｅエンコーダ１２１と、Ｄｅｐｅｎｄｅｎｔエンコーダ１２２とは、それぞれＡＶＣ／Ｈ．２６４規格に準拠したエンコード処理を実行する。エンコーダユニット１２０は、Ｂａｓｅエンコーダ１２１と、Ｄｅｐｅｎｄｅｎｔエンコーダ１２２とが、それぞれエンコード処理を実行することでＢＤ  ＭＶＣ準拠のストリームを生成することができる。
【００３７】
エンコーダユニット１２０は、Ｂａｓｅエンコーダ１２１及びＤｅｐｅｎｄｅｎｔエンコーダ１２２が出力するストリームを、データ書き換え部１３０に供給する。また、エンコーダユニット１２０においては、Ｂａｓｅエンコーダ１２１とＤｅｐｅｎｄｅｎｔエンコーダ１２２との間では情報やデータの授受は行わない。従って、単にエンコーダユニット１２０がエンコード処理を実行すると、定められた規格に適合しないエンコード処理になってしまう場合がある。
【００３８】
従って、本実施形態にかかる映像処理装置１００では、Ｂａｓｅエンコーダ１２１とＤｅｐｅｎｄｅｎｔエンコーダ１２２との間では情報やデータの授受は行わないが、エンコーダユニット１２０は、定められた規格に適合するように制約を入れてエンコードする。このようにエンコーダユニット１２０において定められた規格に適合するように制約を入れてエンコードすることで、Ｂａｓｅエンコーダ１２１とＤｅｐｅｎｄｅｎｔエンコーダ１２２との間で情報やデータの授受は行わない場合でも適切なエンコード処理を実行することができる。この定められた規格や、エンコーダユニット１２０に課する制約については後に詳述する。
【００３９】
データ書き換え部１３０は、エンコーダユニット１２０から出力されるストリームに対して、定められた規格に適合するようにデータを書き換えて、出力するものである。定められた規格としては、例えばＢＤ  ＭＶＣがあり、データ書き換え部１３０は、ｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩの制約を満たしＢＤ  ＭＶＣ準拠のストリームとなるようにｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩの値を書き換えて出力する。
【００４０】
以上、図１を用いて本発明の一実施形態にかかる映像処理装置１００の構成について説明した。次に、本発明の一実施形態にかかる映像処理装置１００の動作について簡単に説明する。
【００４１】
ＨＤＤ１０４は、各種データを保存するためのものである。ＨＤＤ１０４には、Ｌｏｎｇ  ＧＯＰのＯｐｅｎ  ＧＯＰ方式で圧縮された、または、全てフレーム内符号化（Ｉｎｔｒａ圧縮）された符号化ストリームや、非圧縮のベースバンド信号が記憶されている。ＣＰＵ１０１は、図示しない操作入力部からユーザの操作入力を受け、ユーザの操作入力に基づいて、エンコード処理を実行するデータを決定するとともに、そのデータのデコードを行うか否かを決定する。
【００４２】
ＣＰＵ１０１は、処理されるベースバンド信号を、ノースブリッジ１０３、およびＰＣＩバス１０６を介して、ＰＣＩブリッジ１１０に供給するとともに、コマンドを生成する。そして、ＣＰＵ１０１は、エンコードに必要なパラメータがある場合は、そのパラメータとともに、生成されたコマンドを、ノースブリッジ１０３、ＰＣＩバス１０６、ＰＣＩブリッジ１１０、および、コントロールバス１０９を介して、ＣＰＵ１０７に供給する。
【００４３】
ＣＰＵ１０７は、ＰＣＩブリッジ１１０を制御して、ＨＤＤ１０４から供給されたベースバンド信号をメモリ１１１に保存させ、供給されたコマンドに基づいて、ＰＣＩブリッジ１１０を制御して、ベースバンド信号をエンコーダユニット１２０に供給させる。
【００４４】
ＣＰＵ１０７は、ＣＰＵ１０１から供給されたコマンドに基づいて、エンコーダユニット１２０を制御して、ＰＣＩブリッジ１１０からエンコーダユニット１２０に供給されるベースバンド信号のエンコード処理を実行させる。
【００４５】
ベースバンド信号の供給を受けたＢａｓｅエンコーダ１２１及びＤｅｐｅｎｄｅｎｔエンコーダ１２２は、ＣＰＵ１０７による制御に基づいて、それぞれＢａｓｅ画像とＤｅｐｅｎｄｅｎｔ画像のエンコード処理を実行する。Ｂａｓｅエンコーダ１２１及びＤｅｐｅｎｄｅｎｔエンコーダ１２２は、お互いに情報やデータの授受を実行しない。従って、Ｂａｓｅエンコーダ１２１及びＤｅｐｅｎｄｅｎｔエンコーダ１２２は、定められた規格に適合するように制約を入れてエンコードして、ストリームを出力する。
【００４６】
Ｂａｓｅエンコーダ１２１及びＤｅｐｅｎｄｅｎｔエンコーダ１２２からのストリームの供給を受けたデータ書き換え部１３０は、供給されたストリームに対して、定められた規格に適合するようにデータを書き換えて、出力するものである。定められた規格としては、上述したように、例えばＢＤ  ＭＶＣがあり、この場合、データ書き換え部１３０は、ｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩの制約を満たしＢＤ  ＭＶＣ準拠のストリームとなるようにｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩの値を書き換えて出力する。データ書き換え部１３０は、データを書き換えたストリームをＰＣＩブリッジ１１０に出力する。エンコーダユニット１２０でエンコードされ、データ書き換え部１３０でデータが定められた規格に適合するように書き換えられたストリームは、ＣＰＵ１０７の制御の元、ＰＣＩブリッジ１１０を介してメモリ１１１や、さらにＰＣＩバス１０６、ノースブリッジ１０３、サウスブリッジ１０５を介してＨＤＤ１０４に記録される。
【００４７】
ＣＰＵ１０７は、コントロールバス１０９、ＰＣＩブリッジ１１０、ＰＣＩバス１０６、および、ノースブリッジ１０３を介して、ＣＰＵ１０１に、供給されたコマンド処理に基づいたデータの処理が終了したことを通知する。ＣＰＵ１０１は、ノースブリッジ１０３、ＰＣＩバス１０６、および、ＰＣＩブリッジ１１０を介して、メモリ１１１から符号化ストリームを読み出し、ノースブリッジ１０３およびサウスブリッジ１０５を介して、ＨＤＤ１０４に格納させたり、図示しないインタフェースを介して、外部の機器などに出力させたりする。
【００４８】
以上、図１に示した映像処理装置１００の動作について説明した。次に、図１に示したエンコーダユニット１２０の構成について説明する。
【００４９】
［１−２．エンコーダユニットの構成］
図２は、図１に示したエンコーダユニット１２０の構成を示す説明図である。以下、図２を用いて、エンコーダユニット１２０の構成について説明する。
【００５０】
上述したように、エンコーダユニット１２０は、Ｂａｓｅエンコーダ１２１と、Ｄｅｐｅｎｄｅｎｔエンコーダ１２２と、を含んで構成される。Ｂａｓｅエンコーダ１２１は、ＰＣＩブリッジ１１０から供給されるベースバンド信号の内、Ｂａｓｅ画像に対するエンコード処理を実行して、Ｂａｓｅストリームを出力するものである。そしてＤｅｐｅｎｄｅｎｔエンコーダ１２２は、ＰＣＩブリッジ１１０から供給されるベースバンド信号の内、Ｄｅｐｅｎｄｅｎｔ画像に対するエンコード処理を実行して、Ｄｅｐｅｎｄｅｎｔストリームを出力するものである。
【００５１】
Ｂａｓｅエンコーダ１２１は、図２に示したように、符号量制御部１４１と、符号化器１４２と、を含んで構成される。また、Ｄｅｐｅｎｄｅｎｔエンコーダ１２２は、図２に示したように、符号量制御部１５１と、符号化器１５２と、を含んで構成される。
【００５２】
符号量制御部１４１、１５１は、画像の符号化の際の符号量の制御を実行する。符号量制御部１４１、１５１による符号量の制御については後述する。符号化器１４２、１５２は、それぞれ、符号量制御部１４１、１５１が制御する符号量に基づいて画像を符号化するものである。
【００５３】
図２に示したように、Ｂａｓｅエンコーダ１２１と、Ｄｅｐｅｎｄｅｎｔエンコーダ１２２とは、それぞれ独立してエンコードを実行し、Ｂａｓｅエンコーダ１２１と、Ｄｅｐｅｎｄｅｎｔエンコーダ１２２との間では情報やデータの授受は行われない。従って、単にエンコーダユニット１２０が、Ｂａｓｅエンコーダ１２１と、Ｄｅｐｅｎｄｅｎｔエンコーダ１２２とによってエンコード処理を実行すると、定められた規格に適合しないエンコード処理になってしまう場合がある。
【００５４】
ここで、制約に違反して定められた規格に適合しないエンコード処理になってしまう理由について、ｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩがＭＶＣの制約を違反する場合を例にあげて説明する。ＭＶＣでは、ｂａｓｅストリームのｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩは、ｂａｓｅストリームのみのｓｔｒｅａｍでＨＲＤ（Ｈｙｐｏｔｈｅｔｉｃａｌ  Ｒｅｆｅｒｅｎｃｅ  Ｄｅｃｏｄｅｒ：仮想参照デコーダ）  ｃｏｎｆｏｒｍａｎｃｅを満たすように符号化しなければならない。そして、ＨＲＤは、デコーダに入力する前のビットストリームを保存するＣＰＢ（Ｃｏｄｅｄ  Ｐｉｃｔｕｒｅ  Ｂｕｆｆｅｒ：符号化ピクチャバッファ）を規定している。ｄｅｐｅｎｄｅｎｔストリームのｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩは、ｍｖｃ  ｓｃａｌａｂｌｅ  ｎｅｓｔｉｎｇ  ＳＥＩにネストされていて、このネストされたｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩはｂａｓｅストリームとｄｅｐｅｎｄｅｎｔストリームとを合わせ場合のＨＲＤ  ｃｏｎｆｏｒｍａｎｃｅを満たす必要がある。
【００５５】
そのため、Ｂａｓｅエンコーダ１２１と、Ｄｅｐｅｎｄｅｎｔエンコーダ１２２との間で全く通信を行わないエンコーダユニット１２０では、互いの符号量がわからないため、ＨＲＤ  ｃｏｎｆｏｒｍａｎｃｅを満たせず、最悪の場合、アンダーフローする可能性がある。
【００５６】
また、ＢＤ  ＭＶＣには、ｂａｓｅストリームとｄｅｐｅｎｄｅｎｔストリームとに定義されているｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩは、ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄを除いて同一の値でなければならないという制約がある。また、ｄｅｐｅｎｄｅｎｔストリームのｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩは、ｄｅｐｅｎｄｅｎｔストリームのみのｓｔｒｅａｍでＨＲＤ  ｃｏｎｆｏｒｍａｎｃｅを満たすように符号化しなければならない。つまり、ｂａｓｅのみ、ｄｅｐｅｎｄｅｎｔのみ、ｂａｓｅ＋ｄｅｐｅｎｄｅｎｔの３つのＨＲＤ  ｃｏｎｆｏｒｍａｎｃｅを満たしつつ、かつ、ｎｅｓｔｉｎｇされているｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩの内容と、ｎｅｓｔｉｎｇされていないｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩの内容とが、ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄを除いて、同一の値でなければならない制約も必要である。Ｂａｓｅエンコーダ１２１と、Ｄｅｐｅｎｄｅｎｔエンコーダ１２２との間で全く通信を行わないエンコーダユニット１２０では、この制約も満たすことができない。
【００５７】
そこで本実施形態では、Ｂａｓｅエンコーダ１２１と、Ｄｅｐｅｎｄｅｎｔエンコーダ１２２との間で全く通信を行わないエンコーダユニット１２０で、ＢＤ  ＭＶＣ準拠となるストリームにするために必要な制約の実施例を列挙する。
【００５８】
まず全ての実施例に共通な以下の制約が必要となる。
【００５９】
（Ｂ＋Ｄのｔｒａｃｅ  ｒａｔｅ）＞＝ｂａｓｅのみのｔｒａｃｅ  ｒａｔｅ＋ｄｅｐｅｎｄｅｎｔのみのｔｒａｃｅ  ｒａｔｅ
・・・（式１）
【００６０】
（Ｂ＋Ｄのｃｐｂ  ｓｉｚｅ）＞＝ｂａｓｅのみのｃｐｂ  ｓｉｚｅ＋ｄｅｐｅｎｄｅｎｔのみのｃｐｂ  ｓｉｚｅ
・・・（式２）
【００６１】
ここで、「Ｂ＋Ｄのｔｒａｃｅ  ｒａｔｅ」及び「Ｂ＋Ｄのｃｐｂ  ｓｉｚｅ」は、それぞれ、ｂａｓｅとｄｅｐｅｎｄｅｔとを合わせた場合のｔｒａｃｅ  ｒａｔｅ及びｃｐｂ  ｓｉｚｅを意味する。ＢＤ  ＭＶＣの場合、ｂａｓｅのみのｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅは、「ＳＰＳ−＞ＶＵＩ−＞ｈｒｄ＿ｐａｒａｍｅｔｅｒｓ（）」で定義されている。ｄｅｐｅｎｄｎｅｔのみのｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅは「ＳｕｂｓｅｔＳＰＳ−＞ＳＰＳ−＞ＶＵＩ−＞ｈｒｄ＿ｐａｒａｍｅｔｅｒｓ（）」で定義されている。Ｂ＋Ｄのｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅは「ＳｕｂｓｅｔＳＰＳ−＞ｍｖｃ＿ｖｕｉ＿ｐａｒａｍｅｔｅｒｓ＿ｅｘｔｅｎｓｉｏｎ−＞  ｈｒｄ＿ｐａｒａｍｅｔｅｒｓ（）」で定義されている。
【００６２】
上記の制約があれば、ｂａｓｅのみとｄｅｐｅｎｄｅｎｔのみでＨＲＤ  ｃｏｎｆｏｒｍａｎｃｅを満たせると、ｂａｓｅとｄｅｐｅｎｄｅｔとを合わせたもの（ｂａｓｅ＋ｄｅｐｅｎｄｅｔ）もＨＲＤ  ｃｏｎｆｏｒｍａｎｃｅを満たすことができる。
【００６３】
ただし、この制約だけでは、ｂａｓｅのみ、ｄｅｐｅｎｄｅｎｔのみ、ｂａｓｅとｄｅｐｅｎｄｅｔとを合わせたもの（ｂａｓｅ＋ｄｅｐｅｎｄｅｔ）のＨＲＤ  ｃｏｎｆｏｒｍａｎｃｅは満たす事が可能だが、ｂａｓｅとｄｅｐｅｎｄｅｎｔの各ストリーム中の、同時刻のｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩの内容を、ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄを除いて同一の値にすることは保証できない。つまりＢＤ  ＭＶＣ準拠のストリームではないということになる。
【００６４】
よって、以下において、ＢＤ  ＭＶＣ準拠のストリームを生成するために、ｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩの制約を満たすための実施例を説明していく。各実施例の説明の前に、ｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩを符号化する時のＣＰＢのｂｉｔ占有量を「ｇｏｐ＿ｏｃｃｕｐａｎｃｙ」と定義する。なお、ｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩは、ＧＯＰ先頭で符号化されるものとする。
【００６５】
実施例１）ｇｏｐ＿ｏｃｃｕｐａｎｃｙ固定運用
この実施例１では、ｂａｓｅとｄｅｐｅｎｄｅｎｔの「ｇｏｐ＿ｏｃｃｕｐａｎｃｙ」を固定値にする。つまり、ｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩを符号化する時のＣＰＢのビット占有量が、常にある固定値以上になるように符号量制御する。例えば、以下のようなｔｒａｃｅ  ｒａｔｅ，ｃｐｂ  ｓｉｚｅの場合を考える。
・Ｂ＋Ｄのｔｒａｃｅ  ｒａｔｅ＝１０Ｍｂｐｓ，Ｂ＋Ｄのｃｐｂ  ｓｉｚｅ＝１０Ｍｂｉｔ
・ｂａｓｅのみのｔｒａｃｅ  ｒａｔｅ＝６Ｍｂｐｓ，ｃｐｂ  ｓｉｚｅ＝６Ｍｂｉｔ
・ｄｅｐｅｎｄｅｎｔのみのｔｒａｃｅ  ｒａｔｅ＝４Ｍｂｐｓ，ｃｐｂ  ｓｉｚｅ＝４Ｍｂｉｔ
【００６６】
ｂａｓｅとｄｅｐｅｎｄｅｔのｇｏｐ＿ｏｃｃｕｐａｎｃｙが、常にｃｐｂ  ｓｉｚｅ上限になるように符号量制御すれば、ｂａｓｅのみのｇｏｐ＿ｏｃｃｕｐａｎｃｙは６Ｍｂｉｔであり、ｄｅｐｅｎｄｅｎｔのみのｇｏｐ＿ｏｃｃｕｐａｎｃｙは４Ｍｂｉｔである。
【００６７】
そして、それぞれのｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩのｓｙｎｔａｘは以下の値となる。
・（ｂａｓｅ）ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＝９０Ｋ
・（ｂａｓｅ）ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｏｆｆｓｅ＝０
・（ｄｅｐｅｎｄｅｎｔ）ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＝９０Ｋ
・（ｄｅｐｅｎｄｅｎｔ）ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｏｆｆｓｅｔ＝０
【００６８】
この時、ｂａｓｅとｄｅｐｅｎｄｅｔとを合わせたｇｏｐ＿ｏｃｃｕｐａｎｃｙは１０Ｍｂｉｔとなっているので、
・（Ｂ＋Ｄ）ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＝９０Ｋ
・（Ｂ＋Ｄ）ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｏｆｆｓｅｔ＝０
となり、ｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩの制約を満たす事が出来る。
【００６９】
上述の例では、ｂａｓｅ、ｄｅｐｅｎｄｅｎｔ、ｂａｓｅ＋ｄｅｐｅｎｄｅｎｔのｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙが９０Ｋ（１秒）となるようなｇｏｐ＿ｏｃｃｕｐａｎｃｙを固定値で運用した。もちろん、一致させたいｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙの値に応じて、ｇｏｐ＿ｏｃｃｕｐａｎｃｙの値は変えることができる。
【００７０】
例えば、ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙを４５Ｋ（０．５秒）に一致させたい場合は、以下のようにｇｏｐ＿ｏｃｃｕｐａｎｃｙを制御すれば実現可能である。
・（ｂａｓｅのみの）ｇｏｐ＿ｏｃｃｕｐａｎｃｙ＝３Ｍｂｉｔ
・（ｄｅｐｅｎｄｅｎｔのみの）ｇｏｐ＿ｏｃｃｕｐａｎｃｙ＝２Ｍｂｉｔ
【００７１】
一致させるｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙはＧＯＰ単位で変更可能なので、奇数番目と偶数番目のＧＯＰで交互にｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙを変更してもよい。また、例えば、エンコード前にあらかじめｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｖａｌ＿ｄｅｌａｙ（固定値）を、ＧＯＰ単位である値にすると決めておいてもよい。このように決めておけば、ｂａｓｅとｄｅｐｅｎｄｅｎｔでエンコード中に通信しなくともＧＯＰ単位で自由にｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｖａｌ＿ｄｅｌａｙ（固定値）を変えることが出来るので、より自由度が向上する。
【００７２】
なお、この実施例１では、ｇｏｐ＿ｏｃｃｕｐａｎｃｙを固定値で運用するので、後述する実施例２のように、画像を符号化した後にデータ書き換え部１３０でｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩを書き換える必要はない。
【００７３】
実施例２）ｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩ書き換え運用
この実施例２は、実施例１のようにｇｏｐ＿ｏｃｃｕｐａｎｃｙは固定値にせずに、エンコーダユニット１２０でｂａｓｅとｄｅｐｅｎｄｅｎｔを符号化した後に、データ書き換え部１３０でｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩを書き換えてＢＤ  ＭＶＣ準拠となるような制約を入れて符号量制御する。
【００７４】
具体的には、ｂａｓｅとｄｅｐｅｎｄｅｎｔのｔｒａｃｅ  ｒａｔｅおよびｃｐｂ  ｓｉｚｅを２つ定義する。１つ目は、上記（式１）（式２）の符号量制御やＨＲＤ  ｃｏｎｆｏｒｍａｎｃｅに利用する実際のｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅである。２つ目は、ｓｙｎｔａｘ上のｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅで、実際のｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅよりも大きな値で定義する。
【００７５】
つまり、２つ目のｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅについては、ｂａｓｅは「ＳＰＳ−＞ＶＵＩ−＞ｈｒｄ＿ｐａｒａｍｅｔｅｒｓ（）」に定義して、ｄｅｐｅｎｄｅｎｔは「ＳｕｂｓｅｔＳＰＳ−＞ＳＰＳ−＞ＶＵＩ−＞ｈｒｄ＿ｐａｒａｍｅｔｅｒｓ（）」に定義する。
【００７６】
実際のｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅでＨＲＤ  ｃｏｎｆｏｒｍａｎｃｅが保証されていれば、ｓｙｎｔａｘ上のｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅの方が実際のｔｒａｃｅ  ｒａｔｅ及びｃｐｂ  ｓｉｚｅよりも大きな値ならば、ＨＲＤ  ｃｏｎｆｏｒｍａｎｃｅは保証される。
【００７７】
また、上記（式１）（式２）の関係が成り立てば、ｂａｓｅとｄｅｐｅｎｄｅｎｔを合わせたＨＲＤ  ｃｏｎｆｏｒｍａｎｃｅが保証される。ここで、ｂａｓｅとｄｅｐｅｎｄｅｎｔの「ｇｏｐ＿ｏｃｃｕｐａｎｃｙ」の取り得る範囲は、実際のｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅでバッファトレースして計算される値から、ｓｙｎｔａｘ上のｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅでバッファトレースして計算される値まで選択できる。この範囲でｂａｓｅのｇｏｐ＿ｏｃｃｕｐｙａｎｃｙ、ｄｅｐｅｎｄｅｎｔのｇｏｐ＿ｏｃｃｕｐｙａｎｃｙ、ｂａｓｅとｄｅｐｅｎｄｅｎｔとを合わせたｇｏｐ＿ｏｃｃｕｐｙａｎｃｙから計算されるｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙの値を同一に出来れば、ＨＲＤ  ｃｏｎｆｏｒｍａｎｃｅを保証しながら、ｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩの制約を満たす事も可能である。
【００７８】
エンコーダユニット１２０でｂａｓｅ画像とｄｅｐｅｎｄｅｎｔ画像をエンコードした後に、ｂａｓｅとｄｅｐｅｎｄｅｎｔとを合わせたｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅでバッファトレースして計算されるｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙの値が、ｂａｓｅとｄｅｐｅｎｄｅｎｔのｓｙｎｔａｘ上のｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅでバッファトレースして得られるｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ（上限値）と、ｂａｓｅとｄｅｐｅｎｄｅｎｔの実際のｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅでバッファトレースして得られるｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ（下限値）の範囲にあれば、ｂａｓｅとｄｅｐｅｎｄｅｎｔとを合わせたｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙとｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｏｆｆｓｅｔの値で、ｂａｓｅのｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩとｄｅｐｅｎｄｅｎｔのｍｖｃ  ｓｃａｌａｂｌｅ  ｎｅｓｔｉｎｇ  ＳＥＩにネストされたｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩのｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙとｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｏｆｆｓｅｔをデータ書き換え部１３０で書き換えると、ｂａｓｅ、ｄｅｐｅｎｄｅｎｔ、ｂａｓｅ＋ｄｅｐｅｎｄｅｎｔの全てのＨＲＤ  ｃｏｎｆｏｒｍａｎｃｅを保証しながら、ｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩの内容を、ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄを除いて、同一の値にする事ができる。つまりＢＤ  ＭＶＣ準拠のストリームを生成することができる。
【００７９】
よって、エンコーダユニット１２０に含まれる符号量制御部１４１、１５１でのｂａｓｅ画像及びｄｅｐｅｎｄｅｎｔ画像の符号量制御の際に以下の制約が必要となる。
【００８０】
（制約１）
ｂａｓｅ画像とｄｅｐｅｎｄｅｎｔ画像の、ｓｙｎｔａｘ上のｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅでバッファトレースして得られるｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙは、ｂａｓｅ画像＋ｄｅｐｅｎｄｅｎｔ画像のｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ以上の値であること。
【００８１】
（制約２）
ｂａｓｅ画像とｄｅｐｅｎｄｅｎｔ画像の実際のｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅでバッファトレースして得られるｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙはｂａｓｅ画像＋ｄｅｐｅｎｄｅｎｔ画像のｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ以下の値であること。
【００８２】
制約１に関しては、ｂａｓｅ画像とｄｅｐｅｎｄｅｎｔ画像のｓｙｎｔａｘ上のｔｒａｃｅ  ｒａｔｅでバッファトレースして計算されるｇｏｐ＿ｏｃｃｕｐａｎｃｙが、常にｓｙｎｔａｘ上のｃｐｂ  ｓｉｚｅとなっていればよい。ｇｏｐ＿ｏｃｃｕｐａｎｃｙがｓｙｎｔａｘ上のｃｐｂ  ｓｉｚｅと一致する場合が、ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙの上限値となる。
【００８３】
よって、アクセスユニットｎのｂａｓｅ画像、ｄｅｐｅｎｄｅｎｔ画像のｖｉｅｗ  ｃｏｍｐｏｎｅｎｔの符号量をｂ（ｎ）及びｄ（ｎ）、ＧＯＰの先頭のアクセスユニットをランダムアクセスユニットｒａｐ、１つのＧＯＰにおける画像の枚数をｇｏｐ＿ｎｕｍと仮定して、以下の制約を満たすようにｂａｓｅ画像とｄｅｐｅｎｄｅｎｔ画像の符号量を、符号量制御部１４１、１５１で制御すれば、制約１を満たす事ができる。
【００８４】
・ｂａｓｅのｓｙｎｔａｘ上の（ｔｒａｃｅ＿ｒａｔｅ／ｐｉｃｔｕｒｅ＿ｄｕｒａｔｉｏｎ）＞＝ｂ（ｒａｐ−１）
・ｂａｓｅのｓｙｎｔａｘ上の（ｔｒａｃｅ＿ｒａｔｅ／ｐｉｃｔｕｒｅ＿ｄｕｒａｔｉｏｎ）＊２＞＝ｂ（ｒａｐ−１）＋ｂ（ｒａｐ−２）
・・・
・ｂａｓｅのｓｙｎｔａｘ上の（ｔｒａｃｅ＿ｒａｔｅ／ｐｉｃｔｕｒｅ＿ｄｕｒａｔｉｏｎ）＊ｇｏｐ＿ｎｕｍ＞＝ｂ（ｒａｐ−１）＋…＋ｂ（ｒａｐ−ｇｏｐ＿ｎｕｍ）
【００８５】
・ｄｅｐｅｎｄｅｎｔのｓｙｎｔａｘ上の（ｔｒａｃｅ＿ｒａｔｅ／ｐｉｃｔｕｒｅ＿ｄｕｒａｔｉｏｎ）＞＝ｄ（ｒａｐ−１）
・ｄｅｐｅｎｄｅｎｔのｓｙｎｔａｘ上の（ｔｒａｃｅ＿ｒａｔｅ／ｐｉｃｔｕｒｅ＿ｄｕｒａｔｉｏｎ）＊２＞＝ｄ（ｒａｐ−１）  ＋  ｄ（ｒａｐ−２）  
・・・
・ｄｅｐｅｎｄｅｎｔのｓｙｎｔａｘ上の（ｔｒａｃｅ＿ｒａｔｅ／ｐｉｃｔｕｒｅ＿ｄｕｒａｔｉｏｎ）＊ｇｏｐ＿ｎｕｍ＞＝ｄ（ｒａｐ−１）＋…＋ｄ（ｒａｐ−ｇｏｐ＿ｎｕｍ）
【００８６】
また、ｂａｓｅ画像のｖｉｅｗ  ｃｏｍｐｏｎｅｎｔの符号量ｂ（ｎ）、ｄｅｐｅｎｄｅｎｔ画像のｖｉｅｗ  ｃｏｍｐｏｎｅｎｔの符号量ｄ（ｎ）は、バッファトレース時の引き抜き量に相当し、ｓｙｎｔａｘ上のｔｒａｃｅ＿ｒａｔｅ／ｐｉｃｔｕｒｅ＿ｄｕｒａｔｉｏｎが、１ピクチャあたりの流入量に相当する。
【００８７】
つまりｂａｓｅとｄｅｐｅｎｄｅｎｔの実際のｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅよりもｓｙｎｔａｘ上のｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅの方が十分に大きな値の場合、バッファトレース時の引き抜き量よりも流入量の方が十分大きい。従って、ｂａｓｅとｄｅｐｅｎｄｅｎｔの実際のｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅよりもｓｙｎｔａｘ上のｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅの方が十分に大きな値の場合には、実質的には、制約１による画質劣化はほとんど発生しない。
【００８８】
制約２に関しては、ワーストケースとして、ｂａｓｅまたはｄｅｐｅｎｄｅｎｔのどちらか一方が符号量を使い込んで、その結果としてｇｏｐ＿ｏｃｃｕｐａｎｃｙが下がり、もう一方の（符号量を使い込んでいない方の）ｇｏｐ＿ｏｃｃｕｐａｎｃｙは実際のｃｐｂ  ｓｉｚｅまで流入している場合に、この制約２が成り立てばよい。
【００８９】
このような状態がワーストケースとなる理由は、ｂａｓｅまたはｄｅｐｅｎｄｅｎｔのどちらか一方が符号量を使い込んでいるため、ｂａｓｅ＋ｄｅｐｅｎｄｅｎｔについてもｏｃｃｕｐａｎｃｙは下がりやすくなるからである。この時、もう一方のｏｃｃｕｐａｎｃｙは実際のｃｐｂ  ｓｉｚｅの上限まで流入しているので、実際のｔｒａｃｅ  ｒａｔｅからバッファトレースして計算されるｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙとしては最も大きな値となる。
【００９０】
つまり、このｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙよりもｂａｓｅ＋ｄｅｐｅｎｄｅｎｔのｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙの方が常に大きければ、制約２を満たす事ができる。ｂａｓｅおよびｄｅｐｅｎｄｅｎｔがどちらも符号量を使い込んでしまう場合は、ｂａｓｅ＋ｄｅｐｅｎｄｅｎｔのｏｃｃｕｐａｎｃｙはさらに下がるが、ｂａｓｅ及びｄｅｐｅｎｄｅｎｔの両方ともｏｃｃｕｐａｎｃｙが下がってしまうので、この場合は、制約２を満たすためのワーストケースとはならない。ワーストケースはｂａｓｅとｄｅｐｅｎｄｅｔのどちらか一方が符号量を使い込み、もう一方が実際のｃｐｂ  ｓｉｚｅまで流入しているケースである。
【００９１】
ここで、ｂａｓｅとｄｅｐｅｎｄｅｔの内、符号量を使い込んでいる方のｇｏｐ＿ｏｃｃｕｐａｎｃｙをｘ、符号量を使い込んでいる方のｔｒａｃｅ  ｒａｔｅをｔｒａｃｅ  ｒａｔｅ０、符号量を使い込んでいる方のｃｐｂ  ｓｉｚｅをｃｐｂ  ｓｉｚｅ０、符号量を使い込んでいない方のｔｒａｃｅ  ｒａｔｅをｔｒａｃｅ  ｒａｔｅ１、符号量を使い込んでいない方のｃｐｂ  ｓｉｚｅをｃｐｂ  ｓｉｚｅ１とする。この場合に、ｂａｓｅ＋ｄｅｐｅｎｄｅｎｔのｇｏｐ＿ｏｃｃｕｐａｎｃｙは、（ｘ＋ａｃｔｕａｌ  ｃｐｂ  ｓｉｚｅ１）となる。
【００９２】
ｂａｓｅ＋ｄｅｐｅｎｄｅｎｔのｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙは、（ａｃｔｕａｌ  ｃｐｂ  ｓｉｚｅ１＋ｘ）／（ｂａｓｅ＋ｄｅｐｅｎｄｅｎｔのｓｙｎｔａｘ  ｔｒａｃｅ  ｒａｔｅ）であり、ｂａｓｅとｄｅｐｅｎｄｅｔの内、符号量を使い込んでない方のｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙは、（ａｃｔｕａｌ  ｃｐｂ  ｓｉｚｅ１）／（ｓｙｎｔａｘ  ｔｒａｃｅ  ｒａｔｅ１）で表される。よって、制約２を守るためには、以下の式３が成り立つように符号量を制御する。
【００９３】
（ａｃｔｕａｌ  ｃｐｂ  ｓｉｚｅ１＋ｘ）／（ｂａｓｅ＋ｄｅｐｅｎｄｅｎｔのｓｙｎｔａｘ  ｔｒａｃｅ  ｒａｔｅ）＞＝（ａｃｔｕａｌ  ｃｐｂ  ｓｉｚｅ１）／（ｓｙｎｔａｘ  ｔｒａｃｅ  ｒａｔｅ１）・・・（式３）
【００９４】
図３Ａ〜図３Ｃは、時間とビット占有量（ｏｃｃｕｐａｎｃｙ）との関係の一例をグラフで示す説明図である。図３Ａは、ｂａｓｅとｄｅｐｅｎｄｅｔの内、符号量を使い込んでいる方の、時間とビット占有量（ｏｃｃｕｐａｎｃｙ）との関係の一例をグラフで示したものであり、図３Ｂは、ｂａｓｅとｄｅｐｅｎｄｅｔの内、符号量を使い込んでいない方の、時間とビット占有量（ｏｃｃｕｐａｎｃｙ）との関係の一例をグラフで示したものである。そして、図３Ｃは、ｂａｓｅ＋ｄｅｐｅｎｄｅｎｔの時間とビット占有量（ｏｃｃｕｐａｎｃｙ）との関係の一例をグラフで示したものである。
【００９５】
上記の数式３の、（ａｃｔｕａｌ  ｃｐｂ  ｓｉｚｅ１＋ｘ）／（ｂａｓｅ＋ｄｅｐｅｎｄｅｎｔのｓｙｎｔａｘ  ｔｒａｃｅ  ｒａｔｅ）は、図３Ｃのｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙに相当するものであり、（ａｃｔｕａｌ  ｃｐｂ  ｓｉｚｅ１）／（ｓｙｎｔａｘ  ｔｒａｃｅ  ｒａｔｅ１）は、図３Ｂのｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙに相当するものである。
【００９６】
この上記式３のｘを解くと、
ｘ＞＝（ａｃｔｕａｌ  ｃｐｂ  ｓｉｚｅ１）＊（（ｂａｓｅ＋ｄｅｐｅｎｄｅｎｔのｓｙｎｔａｘ  ｔｒａｃｅ  ｒａｔｅ）／（ｓｙｎｔａｘ  ｔｒａｃｅ  ｒａｔｅ１）−１）・・・（式４）
となる。従って、ｇｏｐ＿ｏｃｃｕｐａｎｃｙが常にｘの値以下にならないように符号量制御すれば、上述の制約２は満たされることとなる。
【００９７】
例として、ｓｙｎｔａｘ上のｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅが、ｂａｓｅ、ｄｅｐｅｎｄｅｎｔ、ｂａｓｅ＋ｄｅｐｅｎｄｅｎｔの全てで同じである場合は、上記式４からｘ＞＝０となるので、常に制約２は満たされることとなる。
【００９８】
また、他の例として、ｂａｓｅ＋ｄｅｐｅｎｄｅｎｔのｔｒａｃｅ  ｒａｔｅが１０Ｍｂｐｓであり、ｃｐｂ  ｓｉｚｅが１０Ｍｂｉｔであり、ｂａｓｅ及びｄｅｐｅｎｄｅｎｔのｓｙｎｔａｘ上のｔｒａｃｅ  ｒａｔｅが８Ｍｂｐｓ、ｃｐｂ  ｓｉｚｅが８Ｍｂｉｔ、実際のｔｒａｃｅ  ｒａｔｅが５Ｍｂｐｓ、ｃｐｂ  ｓｉｚｅが５Ｍｂｉｔであるとする。この場合、ｂａｓｅが符号量を使い込んでいると仮定すると、ｘ＞＝１．２５Ｍｂｉｔとなり、実際のｃｐｂ  ｓｉｚｅ＝５Ｍｂｉｔに対して、ｇｏｐ＿ｏｃｃｕｐａｎｃｙが２５％以下にならなければ符号量を割り当てる事ができる。
【００９９】
逆に、ｂａｓｅとｄｅｐｅｎｄｅｎｔの実際のｔｒａｃｅ  ｒａｔｅ，ｃｐｂ  ｓｉｚｅとｓｙｎｔａｘ上のｔｒａｃｅ  ｒａｔｅ，ｃｐｂ  ｓｉｚｅを同じにすると、式４からｘ＞＝実際のｃｐｂ  ｓｉｚｅ１となり、ＧＯＰを跨いで局所的に符号量を割り当てる事はできなくなる。これは、実施例１と同じ結果になる。
【０１００】
以上をまとめると、ｂａｓｅとｄｅｐｅｎｄｅｎｔの実際のｔｒａｃｅ  ｒａｔｅ及びｃｐｂ  ｓｉｚｅと、ｓｙｎｔａｘ上のｔｒａｃｅ  ｒａｔｅ及びｃｐｂ  ｓｉｚｅとが同じ場合は、ＧＯＰをまたいで局所的に符号量を割り当てる事はできない。これは、実施例１と同じことになる。
【０１０１】
また、ｂａｓｅとｄｅｐｅｎｄｅｎｔの実際のｔｒａｃｅ  ｒａｔｅ及びｃｐｂ  ｓｉｚｅよりも、ｓｙｎｔａｘ上のｔｒａｃｅ  ｒａｔｅ及びｃｐｂ  ｓｉｚｅが十分大きい場合は、ＧＯＰを跨いで局所的に符号量を割り当てる事ができる。両者を十分大きく離せば離すほど、ＧＯＰを跨いで局所的に符号量を割り当てる事ができる。
【０１０２】
さらに、ｂａｓｅとｄｅｐｅｎｄｅｎｔのｓｙｎｔａｘ上のｔｒａｃｅ  ｒａｔｅ及びｃｐｂ  ｓｉｚｅが、ｂａｓｅ＋ｄｅｐｅｎｄｅｎｔのｔｒａｃｅ  ｒａｔｅ及びｃｐｂ  ｓｉｚｅと同じになると、上述の制約２は無くなる。また、ｓｙｎｔａｘ上のｔｒａｃｅ  ｒａｔｅが全て同じ場合は、必ずｂａｓｅ＋ｄｅｐｅｎｄｅｎｔのｇｏｐ＿ｏｃｃｕｐａｎｃｙがｂａｓｅ、ｄｅｐｅｎｄｅｎｔそれぞれのｇｏｐ＿ｏｃｃｕｐａｎｃｙよりも小さくなるため、上述の制約１も無くなる。言い換えれば、ｂａｓｅとｄｅｐｅｎｄｅｎｔのｓｙｎｔａｘ上のｔｒａｃｅ  ｒａｔｅ及びｃｐｂ  ｓｉｚｅが、ｂａｓｅ＋ｄｅｐｅｎｄｅｎｔのｔｒａｃｅ  ｒａｔｅ及びｃｐｂ  ｓｉｚｅと同じであり、ｓｙｎｔａｘ上のｔｒａｃｅ  ｒａｔｅが全て同じである場合は、ＧＯＰを跨いで符号量を任意に割り当てる事が可能となる。
【０１０３】
実施例１では、ｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩを符号化するタイミングで、必ずＣＰＢのｂｉｔ占有量がある固定値以上になるように符号量制御する。従って、実施例１の場合は、局所的に符号量を多く割り当てる場合、ＧＯＰ単位でしか符号量を制御することができない。実施例１の場合はＧＯＰを跨いで局所的に符号量を多く割り当てられないため、符号量制御の自由度が制限される。例えば、ＧＯＰの前の画が、テクスチャがあったり、動きが激しかったりする等の理由で、符号量を多く割り当てて画質劣化を抑えたくても、この実施例１では符号量の割り当てが制限され、画質が劣化する場合がある。
【０１０４】
図４Ａ、図４Ｂは、時間とビット占有量（ｏｃｃｕｐａｎｃｙ）との関係の一例をグラフで示す説明図である。図４Ａは、本実施形態の実施例１を適用する前の時間とビット占有量（ｏｃｃｕｐａｎｃｙ）との関係の一例をグラフで示している。一方、図４Ｂは、本実施形態の実施例１を適用した後の時間とビット占有量（ｏｃｃｕｐａｎｃｙ）との関係の一例をグラフで示している。
【０１０５】
図４Ａ、図４Ｂに示したように、本実施形態の実施例１を適用すると、符号量の割り当てがＧＯＰの境界で制限される。従って実施例１では、符号量制御の自由度が制限されて、画質が劣化する場合がある。
【０１０６】
これに対して、実施例２はｂａｓｅ、ｄｅｐｅｎｄｅｎｔの実際のｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅよりも、ｓｙｎｔａｘ上のｔｒａｃｅ  ｒａｔｅとｃｐｂ  ｓｉｚｅが十分大きい値であれば、画質劣化にほとんど影響しない制約となる。
【０１０７】
従って、運用面を考慮すると本実施形態の実施例１を適用することが簡便であるが、符号量の割り当てがＧＯＰの境界で制限されるという制約がある。従って、画質劣化を招きたくない場合には、本実施形態の実施例２を適用することがより望ましい。
【０１０８】
以上、ｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩの制約を満たすための実施例について２つの例を挙げて説明した。次に、本発明の一実施形態にかかる映像処理装置１００の動作について説明する。
【０１０９】
［１−３．映像処理装置の動作］
図５は、本発明の一実施形態にかかる映像処理装置１００の動作について説明する流れ図である。図５に示した流れ図は、エンコーダユニット１２０によって、ｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩの制約を満たすように、ｂａｓｅ画像とｄｅｐｅｎｄｅｎｔ画像とをエンコードする際の映像処理装置１００の動作を示したものである。以下、図５を用いて本発明の一実施形態にかかる映像処理装置１００の動作について説明する。
【０１１０】
エンコーダユニット１２０によって、ｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩの制約を満たすように、ｂａｓｅ画像とｄｅｐｅｎｄｅｎｔ画像とをエンコードするには、ＣＰＵ１０７からエンコーダユニット１２０に対して、ｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩの制約を満たすための符号量制御を行う（ステップＳ１０１）。このステップＳ１０１における符号量制御は、具体的には、符号量制御部１４１、１５１に対して行われる。
【０１１１】
エンコーダユニット１２０は、ｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩの制約を満たすための符号量制御が行われると、エンコーダユニット１２０に供給されるｂａｓｅ画像とｄｅｐｅｎｄｅｎｔ画像とをエンコードする（ステップＳ１０２）。ｂａｓｅ画像については、ｂａｓｅエンコーダ１２１がエンコードを実行し、ｄｅｐｅｎｄｅｎｔ画像については、ｄｅｐｅｎｄｅｎｔエンコーダ１２２がエンコードを実行する。ｂａｓｅエンコーダ１２１及びｄｅｐｅｎｄｅｎｔエンコーダ１２２は、それぞれ独立してエンコードを実行し、ｂａｓｅエンコーダ１２１とｄｅｐｅｎｄｅｎｔエンコーダ１２２との間では情報やデータの授受は行われない。
【０１１２】
各エンコーダでは、ｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩの制約を満たすための制約に基づいて、ｂａｓｅ画像またはｄｅｐｅｎｄｅｎｔ画像のエンコードが実行される。ｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩの制約を満たすための制約に基づいて各エンコーダでエンコードを実行することで、Ｂａｓｅエンコーダ１２１とＤｅｐｅｎｄｅｎｔエンコーダ１２２との間で情報やデータの授受を行わなくても、所定の規格（例えばＢＤ  ＭＶＣ）に準拠したストリームを生成することができる。
【０１１３】
エンコーダユニット１２０がｂａｓｅ画像とｄｅｐｅｎｄｅｎｔ画像とをエンコードすると、データ書き換え部１３０は、エンコーダユニット１２０から出力されるストリームに対して、定められた規格に適合するようにデータを書き換えて、出力するものである。ここでは、定められた規格の例としてＢＤ  ＭＶＣを挙げる。データ書き換え部１３０は、ｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩの制約を満たしＢＤ  ＭＶＣ準拠のストリームとなるようにｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩの値を書き換えて出力する（ステップＳ１０３）。
【０１１４】
このように、ｂｕｆｆｅｒｉｎｇ  ｐｅｒｉｏｄ  ＳＥＩの制約を満たすための符号量制御を行ない、エンコード後にデータを書き換えることで、Ｂａｓｅエンコーダ１２１とＤｅｐｅｎｄｅｎｔエンコーダ１２２との間で情報やデータの授受を行わなくても、ＢＤ  ＭＶＣに準拠したストリームを生成することが出来る。
【０１１５】
また、Ｂａｓｅエンコーダ１２１とＤｅｐｅｎｄｅｎｔエンコーダ１２２との間で情報やデータの授受を行わなくても、ＢＤ  ＭＶＣに準拠したストリームを生成することができることで、既存のエンコーダに大きな変更を加える必要が無くなり、エンコーダユニットの製作コストを抑えることが可能になる。
【０１１６】
＜２．まとめ＞
以上説明したように本発明の一実施形態に係る映像処理装置１００によれば、複数の視点からの画像をエンコーダユニット１２０でエンコードする際に、エンコーダ間で情報の授受を行わずに並行してエンコード処理を実行する。そして、複数の視点からの画像をエンコードする際には、エンコーダユニット１２０は、所定の規格に適合するように制約を入れて符号量制御を行って、複数の視点からの画像をエンコードする。
【０１１７】
そして、複数の視点からの画像をエンコーダユニット１２０でエンコードしてストリームを生成する際に、所定の規格を準拠するようにデータを書き換える。
【０１１８】
このように、複数の視点からの画像を、複数のエンコーダでそれぞれ独立してエンコードを行ない、エンコード後にストリーム中のデータを書き換えることで、エンコーダ間で情報の授受を行わずに並行してエンコード処理する場合でも、所定の規格に適合するストリームを生成することが可能になる。
【０１１９】
以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。
【０１２０】
例えば、上記実施形態では、映像処理装置１００にはエンコーダユニット１２０のみを備える構成を説明したが、本発明はかかる例に限定されない。本発明に係る映像処理装置には、映像のエンコードを行うエンコーダユニットのみならず、エンコードされた映像をデコードするデコーダも備えていてもよい。
【０１２１】
また例えば、上記実施形態では、エンコーダユニット１２０にはＤｅｐｅｎｄｅｎｔエンコーダ１２２が１つだけ設けられている映像処理装置１００について説明したが、Ｄｅｐｅｎｄｅｎｔエンコーダの数は１つに限定されない。例えば、図６に示したように、Ｄｅｐｅｎｄｅｎｔエンコーダがエンコーダユニット１２０に３つ設けられていてもよく、それぞれのエンコーダが独立してエンコード処理を実行してもよい。
【符号の説明】
【０１２２】
１００    映像処理装置
１０１、１０７    ＣＰＵ
１０２、１０８、１１１    メモリ
１０３    ノースブリッジ
１０４    ＨＤＤ
１０５    サウスブリッジ
１０６    ＰＣＩバス
１０９    コントロールバス
１１０    ＰＣＩブリッジ
１２０    エンコーダユニット
１２１    Ｂａｓｅエンコーダ
１２２    Ｄｅｐｅｎｄｅｎｔエンコーダ
１３０    データ書き換え部
１４１、１５１    符号量制御部
１４２、１５２    符号化器
【図１】
2012039312.tif 000003
【図２】
2012039312.tif 000004
【図３Ａ】
2012039312.tif 000005
【図３Ｂ】
2012039312.tif 000006
【図３Ｃ】
2012039312.tif 000007
【図４Ａ】
2012039312.tif 000008
【図４Ｂ】
2012039312.tif 000009
【図５】
2012039312.tif 000010
【図６】
2012039312.tif 000011