(57)【特許請求の範囲】
【請求項１】
入力画像データをフレーム又はフィールドを表すピクチャ単位で分割して、複数の画像データに振り分ける振り分け手段と、
前記振り分け手段によって振り分けられた複数の画像データをそれぞれ画面内符号化により符号化する複数の符号化手段と、
前記複数の符号化手段によってそれぞれ符号化された複数の画像データを結合して結合画像データを生成する結合手段と、
前記振り分け手段による振り分けに関する情報に基づいて、前記結合手段により結合される前の前記複数の画像データ、または前記結合画像データから所定のヘッダを検出するヘッダ検出手段と、
前記ヘッダ検出手段によって検出された所定のヘッダを修正するヘッダ修正手段と、
前記ヘッダ修正手段による修正が施された後の前記結合画像データを符号化ストリームとして出力する出力手段とを有し、
前記複数の符号化手段は、ピクチャ番号がリセットされる画面内符号化ピクチャを生成する第１の符号化器と、前記ピクチャ番号がリセットされない画面内符号化ピクチャを生成する第２の符号化器とを具備し、
前記結合手段は、前記第１の符号化器によって符号化された画像データと前記第２の符号化器によって符号化された画像データとを交互に結合させ、
前記ヘッダ修正手段は、前記第２の符号化器によって符号化された画像データの前記所定のヘッダに含まれる前記ピクチャ番号を修正することを特徴とする符号化装置。
【請求項２】
前記ヘッダ検出手段は、仮想バッファのレベルを示すヘッダを検出し、
前記ヘッダ修正手段は、前記仮想バッファのレベルを示すヘッダを前記符号化ストリームの仮想バッファのレベルに整合させるように修正することを特徴とする請求項１に記載の符号化装置。
【請求項３】
入力されたパラメータに基づいて、前記複数の符号化手段の仮想バッファの容量を設定する設定手段をさらに有することを特徴とする請求項１に記載の符号化装置。
【請求項４】
前記振り分け手段は、前記第１の符号化器及び前記第２の符号化器に対して、前記入力画像データをピクチャ単位で１枚毎交互に振り分けを行うとともに、各ピクチャを前記第１の符号化器及び前記第２の符号化器のどちらに振り分けたかを示す情報を出力することを特徴とする請求項１に記載の符号化装置。
【請求項５】
前記振り分け手段は、前記入力画像データの先頭にダミーピクチャを付加して前記第２の符号化器に出力し、
前記第２の符号化器は、前記ダミーピクチャを、前記ピクチャ番号がリセットされる画面内符号化により符号化するものの、符号化後の前記ダミーピクチャを前記結合画像データに含めないように制御することを特徴とする請求項４に記載の符号化装置。
【請求項６】
前記複数の画像データ及び前記符号化ストリームは、Ｈ．２６４に準拠していることを特徴とする請求項１〜５の何れか１項に記載の符号化装置。
【請求項７】
入力画像データをフレーム又はフィールドを表すピクチャ単位で分割して、複数の画像データに振り分ける振り分け工程と、
前記振り分け工程において振り分けられた複数の画像データをそれぞれ画面内符号化により複数の符号化手段を用いて符号化する符号化工程と、
前記複数の符号化手段によってそれぞれ符号化された複数の画像データを結合して結合画像データを生成する結合工程と、
前記振り分け工程における振り分けに関する情報に基づいて、前記結合工程において結合される前の前記複数の画像データ、または前記結合画像データから所定のヘッダを検出するヘッダ検出工程と、
前記ヘッダ検出工程において検出された所定のヘッダを修正するヘッダ修正工程と、
前記ヘッダ修正工程による修正が施された後の前記結合画像データを符号化ストリームとして出力する出力工程とを有し、
前記複数の符号化手段は、ピクチャ番号がリセットされる画面内符号化ピクチャを生成する第１の符号化器と、前記ピクチャ番号がリセットされない画面内符号化ピクチャを生成する第２の符号化器とを具備し、
前記結合工程では、前記第１の符号化器によって符号化された画像データと前記第２の符号化器によって符号化された画像データとを交互に結合し、
前記ヘッダ修正工程では、前記第２の符号化器によって符号化された画像データの前記所定のヘッダに含まれる前記ピクチャ番号を修正することを特徴とする符号化方法。
【請求項８】
入力画像データをフレーム又はフィールドを表すピクチャ単位で分割して、複数の画像データに振り分ける振り分け工程と、
前記振り分け工程において振り分けられた複数の画像データをそれぞれ画面内符号化により複数の符号化手段を用いて符号化する符号化工程と、
前記複数の符号化手段によってそれぞれ符号化された複数の画像データを結合して結合画像データを生成する結合工程と、
前記振り分け工程における振り分けに関する情報に基づいて、前記結合工程において結合される前の前記複数の画像データ、または前記結合画像データから所定のヘッダを検出するヘッダ検出工程と、
前記ヘッダ検出工程において検出された所定のヘッダを修正するヘッダ修正工程と、
前記ヘッダ修正工程による修正が施された後の前記結合画像データを符号化ストリームとして出力する出力工程とをコンピュータに実行させ、
前記複数の符号化手段は、ピクチャ番号がリセットされる画面内符号化ピクチャを生成する第１の符号化器と、前記ピクチャ番号がリセットされない画面内符号化ピクチャを生成する第２の符号化器とを具備し、
前記結合工程では、前記第１の符号化器によって符号化された画像データと前記第２の符号化器によって符号化された画像データとを交互に結合し、
前記ヘッダ修正工程では、前記第２の符号化器によって符号化された画像データの前記所定のヘッダに含まれる前記ピクチャ番号を修正することを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は符号化装置、符号化方法及びプログラムに関し、特に、複数の符号化器を用いて符号化処理を行うために用いて好適な技術に関する。
【背景技術】
【０００２】
ＭＰＥＧやＨ．２６４に代表される動画圧縮技術では、動画像の時間的冗長性、あるいは空間的冗長性を利用してデータ量を削減して符号化している。ここで、時間的冗長性とは、圧縮対象である現画像（以下、現ピクチャ）に対する時間的に前あるいは後の画像との相似性のことであり、この相似性を利用して前後の画像との差分を符号化することによりデータ量を圧縮する。このように時間的冗長性を用いて符号化する方法は、一般に画面間予測符号化と呼ばれている。
【０００３】
一方、空間的冗長性とは、１枚の自然画像内での冗長性のことであり、この冗長性を利用して圧縮する。また、ＭＰＥＧよりも新しい技術であるＨ．２６４においては、現ピクチャ内での相似性をも利用して、より圧縮効率を高めている。このように空間的冗長性を用いて符号化する方法は、一般に画面内予測符号化と呼ばれている。
【０００４】
画面間予測符号化では、画素間の差分を取るために元画像（参照画像）が必要であり、画面間予測符号化された画像のみでは復号できない。一方、画面内予測符号化では、画面内の画素間の差分を取るので画面内予測符号化された画像は単体で復号が可能である。
【０００５】
また、圧縮効率は、一般的に画面間予測符号化の方が高く、画面間予測符号化された画像は、次の画像の参照画像になる場合は即座に復号される。ところが、画面間予測符号化された画像を参照画像として順次使用することにより誤差が蓄積して画質が悪くなっていく傾向がある。そこで、符号化誤差の蓄積を防ぐために定期的に画面内予測符号化する画像を挿入しており、画面内予測符号化する画像の挿入単位は、一般的にＧＯＰ（Group of Pictures）と呼ばれている。このＧＯＰ単位は、圧縮効率を考慮し、ある程度の時間（０．５秒程度）以上に設定するのが一般的である。
【０００６】
また、編集をしやすくしたり、前述したような誤差が蓄積される影響を抑えたりするために、ＧＯＰ間での相関性を低く（あるいは相関性がないように）設定して符号化する場合が多い。そのため、処理スピードを向上させるために複数の符号化器を用いて並列処理を行う場合は、前後の相関性の低いＧＯＰ単位で行う。その際に問題となるのは、内部保持しなければならないデータ量及び並列処理で生成した圧縮データの接続方法である。これらの問題を解決するために、ＪＰＥＧと同じように全て画面内予測符号化のみでエンコードするか、あるいは特許文献１に記載されているような方法がある。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００８−３１１８２４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、特許文献１に開示された従来技術では、Ｈ．２６４で規定されている仮想デコーダバッファを破綻させないよう並列処理するために、並列処理を前提とした特殊な符号化器を複数用いる必要がある。したがって、既存の符号化器を流用できず、コストが多く掛かってしまうという問題がある。
【０００９】
本発明は前述の問題点に鑑み、一般の符号化器を用いて仮想デコーダバッファを破綻させないように並列に符号化処理を行うことができるようにすることを目的としている。
【課題を解決するための手段】
【００１０】
本発明の符号化装置は、入力画像データをフレーム又はフィールドを表すピクチャ単位で分割して、複数の画像データに振り分ける振り分け手段と、前記振り分け手段によって振り分けられた複数の画像データをそれぞれ画面内符号化により符号化する複数の符号化手段と、前記複数の符号化手段によってそれぞれ符号化された複数の画像データを結合して結合画像データを生成する結合手段と、前記振り分け手段による振り分けに関する情報に基づいて、前記結合手段により結合される前の前記複数の画像データ、または前記結合画像データから所定のヘッダを検出するヘッダ検出手段と、前記ヘッダ検出手段によって検出された所定のヘッダを修正するヘッダ修正手段と、前記ヘッダ修正手段による修正が施された後の前記結合画像データを符号化ストリームとして出力する出力手段とを有し、前記複数の符号化手段は、ピクチャ番号がリセットされる画面内符号化ピクチャを生成する第１の符号化器と、前記ピクチャ番号がリセットされない画面内符号化ピクチャを生成する第２の符号化器とを具備し、前記結合手段は、前記第１の符号化器によって符号化された画像データと前記第２の符号化器によって符号化された画像データとを交互に結合させ、前記ヘッダ修正手段は、前記第２の符号化器によって符号化された画像データの前記所定のヘッダに含まれる前記ピクチャ番号を修正することを特徴とする。
【発明の効果】
【００１１】
本発明によれば、特殊な符号化器を使用しないようにして、仮想デコーダバッファを破綻させないように並列処理することができる。
【図面の簡単な説明】
【００１２】
【図１】第１の実施形態に係る符号化装置の概略構成例を示すブロック図である。
【図２】第１の実施形態における符号化処理の動作の概要を説明する図である。
【図３】第２の実施形態における符号化処理の動作の概要を説明する図である。
【図４】第３の実施形態における符号化処理の動作の概要を説明する図である。
【図５】第４の実施形態に係る符号化装置の概略構成例を示すブロック図である。
【図６】Ｈ．２６４で規定されているレベルとストリームのバッファサイズとの関係を示す図である。
【図７】第５の実施形態に係る符号化装置の概略構成例を示すブロック図である。
【図８】第５の実施形態における符号化処理の動作の概要を説明する図である。
【発明を実施するための形態】
【００１３】
（第１の実施形態）
以下、図面を参照しながら、本発明の第１の実施形態による、複数の符号化器を並列に用いて符号化処理の性能を向上させる例について説明する。本実施形態では、２つの符号化器の並列動作について説明する。また、符号化方式はＨ．２６４に準拠したものであり、時間的に前後の画像とは独立して単独符号化できる画面内符号化を用いているものとする。
【００１４】
図１は、本実施形態に係る符号化装置１００の概略構成例を示すブロック図である。
図１において、入力端子１０１は、符号化ストリームの圧縮条件等を外部から指示する入力パラメータを入力する。符号化パラメータ設定部１０２は、入力端子１０１から入力された入力パラメータを設定する。
【００１５】
レート制御部１０３は、後述する第１の符号化器１０６及び第２の符号化器１０７の符号量を制御する。メモリ１０４は符号化対象となる入力画像データを格納するメモリである。画像振り分け部１０５は、メモリ１０４に格納された入力画像データをピクチャ単位で分割し、所定のタイミングで第１の符号化器１０６または第２の符号化器１０７に振り分けるためのものである。
【００１６】
符号化部１０８は、符号化ストリームを生成する複数の符号化器を備えており、本実施形態では、第１の符号化器１０６及び第２の符号化器１０７を備えている。ストリーム結合部１０９は、第１の符号化器１０６または第２の符号化器１０７から出力される２つのストリームを結合するためのものである。ヘッダ検出部１１０は、ストリーム結合部１０９により結合されたストリーム（結合画像データ）から所定のヘッダを検出するためのものである。ヘッダ修正部１１１は、検出したヘッダを所定の値に書き換えるためのものである。出力端子１１２は、最終的に得られる合成ストリーム（出力画像データ）を外部に出力するためのものである。
【００１７】
図２は、本実施形態における符号化処理の動作の概要を説明する図である。
図２に示す入力動画像２００は、横軸を時間軸としてピクチャ単位で表現されており、ダミーピクチャ２０１が入力動画像２００の先頭に付加されている。ストリーム２０２は、第１の符号化器１０６の符号化処理によって生成されるストリームを示している。また、ストリーム２０３は、第２の符号化器１０７の符号化処理によって生成されるストリームを示している。ダミーピクチャ２０４は、ダミーピクチャ２０１が第２の符号化器１０７において符号化された符号化ピクチャである。合成ストリーム２０５は、生成されたストリーム２０２、２０３を合成したものである。
【００１８】
次に、図１を参照しながら、本実施形態における処理の流れを説明する。
最初に、合成ストリームの生成条件となる入力パラメータが入力端子１０１から入力される。ここで、入力パラメータとは、具体的には、画像サイズやターゲットとするビットレートの設定といった、外部から指示する必要があるパラメータのことである。この入力パラメータは、符号化処理を開始する時に設定される。例えばカメラ等で使用する場合、カメラの撮影モードや記録メディアの性能に応じて入力パラメータが変更される。
【００１９】
次に、符号化パラメータ設定部１０２は、入力パラメータの指示内容を符号化部１０８内の第１の符号化器１０６及び第２の符号化器１０７へ設定できる形式に変換して伝送する。また、入力パラメータのうち、最終的なターゲットビットレートに関してはレート制御部１０３へ設定する。
【００２０】
前述した手順により符号化するための設定が完了すると、メモリ１０４に格納された入力画像データが画像振り分け部１０５へ入力される。画像振り分け部１０５は、入力された入力画像データをピクチャ単位で１枚毎交互に第１の符号化器１０６と第２の符号化器１０７とへ振り分けて出力する。また、画像振り分け部１０５は、どのように入力画像データを振り分けたかを示す情報をヘッダ検出部１１０へ送る。この振り分けに関する情報は、例えば各ピクチャを第１の符号化器１０６及び第２の符号化器１０７のどちらに振り分けたかを示す情報である。
【００２１】
第１の符号化器１０６及び第２の符号化器１０７には、それぞれ時間的に１枚ずつピクチャが飛ばされたデータが入力される。第１の符号化器１０６及び第２の符号化器１０７では、それらのデータを連続した動画像と認識して符号化パラメータに従って画面内符号化処理を行う。なお、第１の符号化器１０６及び第２の符号化器１０７は、並列処理するために特別な構成を備えている必要はなく、それぞれの出力は、単独でもＨ．２６４に準拠するものとする。
【００２２】
ストリーム結合部１０９は、符号化部１０８から出力された２つの符号化ストリームをピクチャ単位で１枚毎交互に結合して１つのストリームに結合する。なお、本実施形態では、画面内符号化のみを用いているため、ストリームの結合順序は入力順序と同じである。そして、ストリーム結合部１０９は、結合したストリームのビット量の情報をレート制御部１０３へ送る。レート制御部１０３は、入力パラメータで指示されたターゲットビットレートと実際に生成したビット量とから、第１の符号化器１０６及び第２の符号化器１０７を制御し、所望のビットレートに近づくようにする。
【００２３】
なお、この段階の結合ストリームは単純に結合されただけなので、このままではＨ．２６４の規格を満たすものとなっていない。そこで本実施形態では、ヘッダ検出部１１０は、ストリーム結合部１０９にて結合された結合ストリーム内の所定のヘッダの位置を画像の振り分け情報に基づいて検出する。本実施形態では結合後のストリームに対してヘッダを検出しているが、結合前のそれぞれのストリームに対して行ってもよい。ヘッダ検出部１１０で検出されたヘッダ情報は、結合ストリームとともにヘッダ修正部１１１へ送られ、ヘッダ修正部１１１は特定のヘッダ部分を書き換える。ヘッダ修正部１１１は、結合することによって矛盾が生じている結合ストリーム内部のヘッダ情報を修正することにより、Ｈ．２６４に準拠した合成ストリームを生成する。
【００２４】
次に、図２を参照しながら詳細な動作を説明する。
まず、画像振り分け部１０５は、メモリ１０４に格納されている入力動画像の先頭にダミーピクチャ２０１を付加して図２に示す入力動画像２００を生成する。そして、画像振り分け部１０５は、図２に示すように、偶数番号のピクチャを第１の符号化器１０６へ振り分け、奇数番号のピクチャを第２の符号化器１０７へ振り分ける。
【００２５】
各々のピクチャは、第１の符号化器１０６及び第２の符号化器１０７にて符号化されることになるが、図２に示すように、並列処理しているため、入力画像に対して処理時間は２倍確保できる。つまり、所望のピクチャレートよりも半分程度の処理能力しかもたない符号化器を用いても、所望のピクチャレートで符号化を実現することができる。
【００２６】
Ｈ．２６４では、符号化する際に、必ず先頭にＩＤＲ（Instantaneous Decoding Refresh）ピクチャ（以下、ＩＤＲ）という特別なピクチャを必要とする。このＩＤＲは、画面内符号化においてＩピクチャの中でも特別なピクチャであり、ほとんど全ての符号化器で処理するピクチャは先頭がＩＤＲとなる。
【００２７】
また、ＩＤＲは、ストリームの途中でも任意の位置に出現させることが可能であり、ＩＤＲ同士の識別子がヘッダに付加されている。１つの符号化器内にＩＤＲが出現するような場合は、必ず識別子が異なるように識別子が付加されるが、複数の符号化器を用いる場合は、識別子が重なってしまう可能性がある。なお、片方の符号化器でＩＤＲを使用しない設定とした場合でも先頭には必ずＩＤＲを入れなければならないので、その時点で識別子が重なってしまう可能性がある。この結果、２つのストリームをそのまま結合してしまうと、識別子が重複してしまう可能性がある。
【００２８】
そこで、ストリーム結合部１０９でストリームを結合した後に、ヘッダ修正部１１１にて識別子を強制的に変更する手法も考えられる。ところが、Ｈ．２６４では、ＩＤＲの識別子に対しては、ゴロム符号化という前後のデータにより符号長が変わってしまう可変長符号化が施されているため、符号化後に識別子を修正することは非常に困難である。
【００２９】
そこで本実施形態では、画像振り分け部１０５は、図２に示すように、予め先頭に入力データではないダミーピクチャ２０１を付加する。そして、第１の符号化器１０６又は第２の符号化器１０７は、先頭のダミーピクチャを画面内符号化により符号化するものの、符号化後のダミーピクチャ２０４をストリーム結合部１０９によって結合されるストリームに含めないように制御する。このようにすることによって、修正が困難なＩＤＲの識別子を取得することを不要にする。図２に示すように、合成ストリーム２０５内のデータの並びでは、先頭のダミーピクチャ２０４はダミーデータなので含まれていない。
【００３０】
また、本実施形態では、第１の符号化器１０６が行う画面内符号化のピクチャは全てＩＤＲとし、第２の符号化器１０７が行う画面内符号化のピクチャは先頭以外すべてＩピクチャとしている。ＩＤＲとＩピクチャとの相違点は、前述した識別子だけでなく、ピクチャ内のヘッダに書かれるframe＿numというピクチャの番号を示すパラメータもある。Ｈ．２６４においては、frame＿numはＩピクチャでカウントアップされ、ＩＤＲがくるとリセットしなければならないと規定されている。
【００３１】
このように、第１の符号化器１０６から出力される全てのＩＤＲ内のヘッダのframe＿numは０である。これに対して第２の符号化器１０７から出力される先頭以外の全てのＩピクチャ内のヘッダのframe＿numは、先頭以外にＩＤＲが存在しないため、０からカウントアップされている。したがって、ストリーム結合部１０９にてストリームを結合した段階では、Ｉピクチャ間にＩＤＲが存在しているにも関わらずframe＿numがカウントアップしており、エラーストリームの状態となる。
【００３２】
そこで、本実施形態では、ストリーム結合部１０９で２つのストリームを結合した後に、ヘッダ検出部１１０でframe＿numを含んでいるヘッダを検出する。その際、ＩＤＲのframe＿numは常に０なので検出する必要はなく、画像振り分け部１０５から出力された情報を用いて第２の符号化器１０７で生成されたＩピクチャのframe＿numを含むヘッダを検出するように動作する。
【００３３】
そして、ヘッダ検出部１１０は検出したヘッダ情報をヘッダ修正部１１１へ送り、ヘッダ修正部１１１は、合成ストリーム中のＩピクチャのframe＿numの値を修正する。前述したように、ＩＤＲのframe＿numは０であり、図２の合成ストリーム２０５に示すように、ＩピクチャとＩＤＲとが入れ子状態になっているため、Ｉピクチャのframe＿numは全て０に修正される。このように、Ｉピクチャのframe＿numの値を変更して整合を取るためにカウンタを持つ必要がなく、常に０に置き換えるだけでよい。なお、frame＿numはゴロム符号化されておらず、０に置き換えることによる不都合は発生しない。
【００３４】
また、Ｈ．２６４に準拠した合成ストリームを得るためには、仮想デコーダに内蔵されているストリームバッファ（仮想バッファ）を管理する必要がある。このストリームバッファはストリームを生成するレベルによって規定されているものであり、図６に示すようにレベルによって異なっている。なお、このストリームバッファの容量は、さらに他の条件によって変化するが、各レベル同士の比率は常に一定である。本実施形態においては、ストリームバッファの容量が他の条件により変化しても処理自体は影響ないため、他の条件による容量の変化に関する詳細な説明は省略する。
【００３５】
本実施形態の第１の符号化器１０６及び第２の符号化器１０７は、一般的な符号化器と同様に、あるレベルを設定すると、そのレベルで規定されているストリームバッファを破綻させないようにストリームを生成する。例えば、どちらの符号化器もレベル４でストリームを生成する場合、図６に示すようにバッファのサイズは２５０００となる。
【００３６】
しかしながら、それぞれ生成するストリームはレベル４を満たしていたとしても、合成後のストリームは２つのストリームを合体したものであるため、規格を満たさなくなる場合がある。つまり、２つのストリームを１つ合成にした時点で、ストリームバッファの必要量が２倍になる可能性がある。そこで、ヘッダ検出部１１０は、レベルを指定しているヘッダを検出し、ヘッダ修正部１１１は、合成ストリームのストリームバッファをストリームバッファが破綻しないレベルへと書き換える。
【００３７】
例えば、レベル４で生成したストリーム同士を合成する場合、ストリームバッファを２倍以上持つレベル４．１以上に書き換える。なお、レベルの情報に関してもゴロム符号化されていないので、書き換えによる不都合は発生しない。図６に示したレベルの例では、ストリームバッファについて説明したが、レベルはストリームバッファだけでなく、ピクチャレートも規定されている。ピクチャレートについてもストリームバッファと同様に合成ストリームが２倍のレートが必要となるので、それを満たすようなレベルへと変更する必要がある。
【００３８】
以上のように本実施形態によれば、特殊な符号化器を用意することなく符号化処理の並列化が可能となる。
【００３９】
（第２の実施形態）
以下、図３を参照しながら本発明の第２の実施形態について説明する。なお、本実施形態に係る符号化装置の構成については、第１の実施形態と同様であるため、説明は省略する。
【００４０】
図３は、本実施形態における符号化処理の動作の概要を説明する図である。なお、図２と同様のものについては同一の符号を付している。
図３におけるストリーム３００は、第１の符号化器１０６の符号化処理により生成されるストリームを示している。また、合成ストリーム３０１は、第１の符号化器１０６で生成されたストリーム３００と、第２の符号化器１０７で生成されたストリーム２０３とを合成したストリームである。
【００４１】
本実施形態において、第１の符号化器１０６では、第２の符号化器１０７と同様に、入力画像の先頭ピクチャのみＩＤＲとし、以降のピクチャはＩピクチャとして符号化する。なお、合成の手順は第１の実施形態と同様である。その結果、合成ストリーム３０１は、先頭のみＩＤＲという形式となる。
【００４２】
また、第１の符号化器１０６及び第２の符号化器１０７においてそれぞれ個別にframe＿numがインクリメントされる。したがって、合成ストリーム３０１は同じframe＿numを持つピクチャが存在することとなり、エラーストリームの状態となる。
【００４３】
本実施形態によれば、図３に示すように、Ｉ４とＩ５、Ｉ６とＩ７、Ｉ８とＩ９のように偶数番号から始まるピクチャと次の奇数番のピクチャのframe＿numが一致することになる。第１の実施形態では、１ピクチャおきにＩＤＲピクチャとなるので、Ｉピクチャのframe＿numの値を０にすればよいが、この場合はＩＤＲピクチャは先頭のみなので、frame＿numの値を０にするとエラーストリームとなってしまう。
【００４４】
そこで本実施形態では、ヘッダ修正部１１１にカウンタ機能を持たせて、合成ストリーム３０１のframe＿numの値を、エンコード順にインクリメントさせた値に修正する。以上により、特殊な符号化器を用意することなく符号化処理の並列化が可能となる。
【００４５】
（第３の実施形態）
以下、図４を参照しながら本発明の第３の実施形態について説明する。なお、本実施形態に係る符号化装置の構成については、第１の実施形態と同様であるため、説明は省略する。
【００４６】
図４は、本実施形態における符号化処理の動作の概要を説明する図である。なお、図２と同様のものについては同一の符号を付している。
図４において、動画像４００は、横軸を時間軸としてピクチャ単位で表現されている。本実施形態では、動画像４００の先頭ピクチャ４０１はダミーピクチャではなく、ダミーピクチャが先頭に付加されていない。
【００４７】
ストリーム４０２は、第２の符号化器１０７の符号化処理により生成されるストリームを示している。符号化ピクチャ４０３は、第２の符号化器１０７において符号化された先頭のピクチャである。また、合成ストリーム４０４は、第１の符号化器１０６で生成されたストリーム２０２と第２の符号化器１０７で生成されたストリーム４０２とを合成したストリームである。
【００４８】
本実施形態では、図４に示すように、第１の符号化器１０６及び第２の符号化器１０７のどちらも入力画像を全てＩＤＲピクチャとして符号化する。また、第１及び第２の実施形態と異なり、前述したように入力画像の先頭ピクチャ４０１はダミーピクチャである必要はない。したがって、合成ストリーム４０４は、入力画像の先頭ピクチャ４０１を含んだ全ての符号化ピクチャによって構成される。
【００４９】
ここで、合成ストリーム４０４の全てのＩＤＲピクチャのヘッダには識別ＩＤが付加されている。前述したように、識別ＩＤは、第１及び第２の実施形態で修正したframe＿numとは異なり、可変長符号化方式であるゴロム符号化がなされている。同じ識別ＩＤを持つＩＤＲピクチャが同一ストリーム内に存在すると、Ｈ．２６４の規格に違反することになり、さらに識別ＩＤが可変長符号化されているので修正は困難である。
【００５０】
そこで本実施形態では、符号化パラメータ設定部１０２から与えられる入力パラメータに従って、第１の符号化器１０６及び第２の符号化器１０７にＩＤＲピクチャの識別ＩＤを設定する。この場合、入力パラメータには識別ＩＤの振り分け情報が含まれるようにする。
【００５１】
また、識別ＩＤの値自体はＨ．２６４で規定されているものではない。このため、任意の識別ＩＤをＩＤＲに付加した場合でも、第１の符号化器１０６及び第２の符号化器１０７が出力するそれぞれのストリームは、第１及び第２の実施形態と同様に、Ｈ．２６４に準拠するようになる。なお、frame＿numに関しては、ＩＤＲのframe＿numは常に０であることが規定されているので、変更する必要はない。また、本実施形態の場合は、結合ストリームで修正するヘッダは、レベルの部分のみでよい。以上のように本実施形態によれば、特殊な符号化器を用意することなく符号化処理の並列化が可能となる。
【００５２】
（第４の実施形態）
以下、図５及び図６を参照しながら本発明の第４の実施形態について説明する。
図５は、本実施形態に係る符号化装置５００の概略構成例を示すブロック図である。なお、図１と同様の構成については、同一の番号を付しており、その説明は省略する。
図５において、符号化部５０３を構成する第１の符号化器５０１及び第２の符号化器５０２は、ストリームバッファを制御する機能を備えている。また、本実施形態に係る符号化装置５００は、レート制御部が不要である点で、第１〜第３の実施形態と異なる。
【００５３】
第１〜第３の実施形態と同様に、合成ストリームを生成する際は、ストリームバッファを破綻させる可能性を考慮する必要がある。そのため、第１の符号化器及び第２の符号化器に設定するレベルに対して制限が出てくる。例えば、最終結果である合成ストリームをレベル４．１にしたい場合、図６に示すように、第１の符号化器及び第２の符号化器に設定する最高値はレベル４である。
【００５４】
しかしながら、実際にはレベル４．１ではストリームバッファの容量を６２５００まで許容している。一方、第１の符号化器及び第２の符号化器は、その半分の３１２５０までバッファを使用できるが、レベル４ではストリームバッファの容量は２５０００である。このように２つの符号化器を足しても５００００までしか使用しないことになり、効率上ロスが発生する。
【００５５】
そこで本実施形態では、符号化パラメータ設定部１０２は、入力パラメータに従って第１の符号化器５０１及び第２の符号化器５０２のストリームバッファの容量を設定する。例えば、上述したように合成ストリームをレベル４．１にしたい場合、本実施形態では、第１の符号化器５０１及び第２の符号化器５０２にもレベル４．１と設定する。そして、第１の符号化器５０１及び第２の符号化器５０２では、使用するストリームバッファの容量を、６２５００の半分である３１２５０に設定する。
【００５６】
この結果、レベル４．１にて規定される最大値の６２５００までストリームバッファを使用することが可能となり、レベル４．１を満たす合成ストリームを生成することができる。さらに、第１の符号化器５０１及び第２の符号化器５０２で生成されたストリームバッファのレベルは４．１となっているので、ヘッダ修正部１１１は、合成ストリームに関してレベルを修正する必要がなくなる。また、それ以外については第１〜第３の実施形態と同様である。以上のように本実施形態によれば、特殊な符号化器を用意することなく符号化処理の並列化が可能となる。
【００５７】
（第５の実施形態）
以下、図７及び図８を参照しながら本発明の第５の実施形態について説明する。
図７は、本実施形態に係る符号化装置７００の概略構成例を示すブロック図である。なお、図１と同様の構成については、同一の番号を付しており、その説明は省略する。
図７において、符号化部７０１は、並列処理するためのｎ個の符号化器から構成されている。
【００５８】
図８は、本実施形態における符号化処理の動作の概要を説明する図である。
図８における入力動画像８００は、横軸を時間軸としてピクチャ単位で表現されており、ｎ−１個のダミーピクチャ８０１が入力動画像８００の先頭に付加されている。ストリーム８０２は、第１の符号化器における符号化処理によって生成されるストリームを示している。ダミーピクチャ８０３は、入力動画像８００の１番目のダミーピクチャが第２の符号化器において符号化された結果として先頭に位置する符号化ピクチャである。ダミーピクチャ８０４は、入力動画像８００の２番目のダミーピクチャが第３の符号化器において符号化された結果として先頭に位置する符号化ピクチャである。さらに、ダミーピクチャ８０５は、入力動画像８００のｎ−１番目のダミーピクチャが第ｎの符号化器において符号化された結果として先頭に位置する符号化ピクチャである。合成ストリーム８０６は、各符号化器で生成された全てのストリームを合成したストリームである。
【００５９】
以下、図８を参照しながら詳細な動作を説明する。なお、基本的な処理手順は第１の実施形態と同様である。
本実施形態では、画像振り分け部１０５が入力画像に付加するダミーピクチャの個数は並列処理する符号化器の数より１少ない数となる。これにより、第１の符号化器は、ダミーピクチャではないｎ番目のピクチャから処理することとなる。第１の実施形態では、２並列なので処理時間を１／２に短縮できるが、本実施形態では、処理時間を１／ｎに短縮できることになる。
【００６０】
そして、第２〜第ｎの符号化器では、ダミーピクチャから符号化処理を開始する。この結果、各符号化器で符号化処理されたダミーピクチャは、不必要なものであるため、結合する際に取り除かれ、ｎ番目のピクチャから始まる合成ストリーム８０６が生成される。
【００６１】
以上のように本実施形態によれば、ｎ個の並列処理を行う場合でも適用可能である。また、本実施形態では、第１の実施形態と同様の処理をｎ個の並列処理により行う例について説明したが、第２〜第４の実施形態で説明した処理でも同様に適用できる。
【００６２】
（その他の実施形態）
上述した全ての実施形態において画像の単位をピクチャと表現しているが、このピクチャという単位は、プログレッシブ動画におけるフレーム、インターレース動画におけるフィールドのどちらにも適用可能である。
【００６３】
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【符号の説明】
【００６４】
１０５  画像振り分け部
１０６  第１の符号化器
１０７  第２の符号化器
１０９  ストリーム結合部
１１０  ヘッダ検出部
１１１  ヘッダ修正部
【図１】
0005967866.tif 000002
【図２】
0005967866.tif 000003
【図３】
0005967866.tif 000004
【図４】
0005967866.tif 000005
【図５】
0005967866.tif 000006
【図６】
0005967866.tif 000007
【図７】
0005967866.tif 000008
【図８】
0005967866.tif 000009