JP4142652B2 - 映像符号化装置 - Google Patents

Description

本発明はデジタル映像符号化技術に関して、特に、DCT変換と動き補償及び予測により映像符号化を遂行する符号化装置に関する。

映像符号化装置で、特に、可変長符号化器は映像圧縮／復号標準が進むにつれて、その回路構成及び制御方法が益々複雑になっている。例えば、MPEG-4を利用して映像を符号化する場合、エラー耐性を強化するためにデータ分割モードを使う場合に、あるビデオパケット内でマクロブロックのテクスチャと二つのヘッダーをそれぞれ種類別に出すべきである。この時、可変長符号化器が単純にマクロブロック単位でヘッダーとテクスチャを別々に出す構造では、使用者がビデオパケットを構成するためには複雑な制御を通さなければならず、映像符号化装置を制御するCPUの負荷増加になる問題が生じる。

図１は、従来技術による符号化器のブロック図であって、MPEG-4に対する実施例である。図１を参照すると、符号化器（１００）は、動き予測（Motion Estimation：以下、MEと言う）ブロック（１０１）、動き補償（Motion Compensation：以下、MCと言う）ブロック（１０２）、離散コサイン変換／量子化（Discrete Cosine Transform/Quantization：以下DCT/Qと言う）ブロック（１０３ａ）、AC/DC予測（AC/DC Prediction：以下ADPと言う）ブロック（１０４）、可変長符号化（Variable Length Coding：以下VLCと言う）ブロック（１０５）、及び逆離散コサイン変換／逆量子化（Inverse DCT/Inverse Q：以下IQ/IDCTと言う）ブロック（１０３ｂ）を含む。

MEブロック（１０１）は、過去フレームに対して現在フレームの動きを予測する作業を遂行する。結果は動きベクターで出し、これはマクロブロックまたはブロック毎に過去フレームに比べてどの方向にどのくらい移動したのかを示す。このような、動き予測を利用すると、時間的な繰り返しを除去して符号量を減らすことができる。上記マクロブロックは１６×１６個の画素単位で構成され、４個の輝度ブロックと２個の色差ブロックで構成される。よって、計６個のブロックを含み、これらブロックは８×８個の画素で構成される。

MCブロック（１０２）は、MC（−）（MC minus）（１０２ａ）とMC（＋）（MC plus）（１０２ｂ）の二種類に仕分けされる。MC（−）（１０２ａ）は、現在フレームで過去フレームからの動き予測結果を抜く作業であって、時間的な繰り返しが除去されたフレームデータの結果がでる。また、MC（＋）（１０２ｂ）は、以後に説明されるIQ/IDCT部（１０３ｂ）の結果にMC（−）（１０２）で使われた過去フレームを加える作業で、最終的に復号器で見られる映像が得られる。この映像は次のフレームを符号化する時過去フレームに活用される。
DCT/Qブロック（１０３ａ）は空間領域の映像データを周波数領域のデータに変えて、その結果がより少ない種類の値を持つように量子化を遂行する。
ADPブロック（１０４）は、現在ブロックのAC/DC係数に対して、周辺ブロックのAC/DC係数から差分値を求む。これは空間的な連続性を利用して符号量を削減しようとする目的である。

VLCブロック（１０５）はADPが完了した係数を可変長符号化して、最終的に符号化されたビットストリームを発生させる。この時、ビットストリームは所定個数のマクロブロックに対するデータを含んだビデオパケットで構成される。
IQ/IDCTブロック（１０３ｂ）はDCT/Qが終わった係数に対して逆量子化を遂行して、その結果をまた空間領域のデータに変える。IQ/IDCT直後の映像がMC（−）直後の映像と違う点は、IQ/IDCT直後の映像はDCT/Qブロック（１０３ａ）とADPブロック（１０４）の量子化／逆量子化によってデータが損失されることもできるということである。データが損失された映像を求めるのは復号器と同じ環境を作るためである。

図２は、従来技術による映像符号化装置のブロック図として、符号化器（１００）、メモリー部（２０４、２０５）、中央処理装置（CPU）（２０１）及びメインメモリー部（２０２）、データバス（２０３）で構成される。
符号化器（１００）は、MEブロック（１０１）で構成される動き予測部分及びMCブロック（１０２）、DCT/IDCTブロック（１０３）、ADPブロック（１０４）、VLCブロック（１０５）で構成されるテクスチャ符号化部分とで分けられて、上記二つの部分は、お互いに独立的に動作することができる。然し、テクスチャ符号化の為にはMEが遂行された後に出る動きベクターが必要である。
MEブロック（１０１）での動き予測はマクロブロック単位で動作が構成される。その間テクスチャ符号化部分（１０２、１０３、１０４、１０５）ではブロック単位の動作が６回繰り返される。
メモリー部（２０４、２０５）は、テクスチャ符号化のための必要なデータを貯蔵して、中央処理装置（CPU）（２０１）及びメインメモリー部（２０２）は、残りブロックの動作を制御するためである。
データバス（２０３）は、符号化器（１００）と外部メモリーのデータを受け渡す。

図３は、図２の符号化器をパイプライン構造で利用してＮ個のマクロブロックで構成されるフレームを符号化する方法を示す。
先に、マクロブロック０に対するMEが遂行される。この時は、マクロブロック０に対する動きベクターがないから、マクロブロック０のテクスチャ符号化の遂行ができない。
次に、マクロブロック１に対するMEが遂行される間、マクロブロック０に対する動きベクターが出ていて、同時に、マクロブロック０に対するテクスチャ符号化が遂行されることができる。このような方式で符号化を行うことで最後のマクロブロックではMEは動作しなく、テクスチャ符号化だけ動作するようになる。

図４は、従来技術によるVLC部の詳細ブロック図である。
符号化されたマクロブロックはそのマクロブロックの特性を示すヘッダーと実際の映像データが含まれたテクスチャとで構成される。
ヘッダー符号化制御部（header_ctrl）（３０６）はヘッダー符号化の制御を行う。
ヘッダーロムテーブル（mb_rom）（３０７）はヘッダーを符号化することに必要な様々なテーブルを含む。
ヘッダーメモリー（hmem）（３０５）はヘッダーの符号化結果を貯蔵する。
テクスチャ符号化制御部（texture_ctrl）（３０２）は、テクスチャ符号化の制御を行う。
テクスチャロムテーブル（ac_rom）（３０３）は、テクスチャを符号化することに必要な様々なテーブルを含む。
テクスチャメモリー（tmem）（３０１）は、テクスチャの符号化結果を貯蔵する。
VLCレジスター部（VLC_reg）（３０４）は、ヘッダー及びテクスチャ符号化に必要な様々な設定等をCPU（２０１）から受けてテクスチャ符号化制御部（texture_ctrl）（３０２）とヘッダー符号化制御部（header_ctrl）（３０６）に伝達し、また、テクスチャ符号化制御部（texture_ctrl）（３０２）とヘッダー符号化制御部（header_ctrl）（３０６）から符号化の結果、どの程度多くのビット量が生じているかの情報を受けてCPU（２０１）へ伝達する。

図５は、データ分割された時のVP（ビデオパケット）符号化過程を示す。ここで、ビデオパケットは１個またはその以上のマクロブロックを括る単位で、マクロブロックデータ外に最前部にビット列固定長符号（再同期マーカー）があり、それに引き継いでフレームヘッダー情報の一部が繰り返されてエラー耐性を強化させる。また、データ分割はビデオパケット内で重要なヘッダー情報を前部に位置させるモードで、ヘッダーは重要度によってヘッダー１とヘッダー２に仕分けされて、その間には特定ビット列で構成されるマーカーが挿入される。
先に、再同期マーカーとビデオパケットヘッダーを挿入する（Ｓ１００）。
次に、マクロブロックの符号化を遂行する（Ｓ１１０）。符号化が終わると、ヘッダーメモリー（hmem）（３０５）にはヘッダー１とヘッダー２のビットストリームが貯蔵され、テクスチャメモリー（tmem）（３０１）には、テクスチャのビットストリームが貯蔵される。
次に、ヘッダー１、ヘッダー２、テクスチャビットストリームをそれぞれメインメモリー（２０２）上で別途の空間に貯蔵する（Ｓｌ１２乃至Ｓ１１６）。これらは、ビデオパケット内のすべてのマクロブロックを符号化した後、ヘッダー１はヘッダー１同士に、ヘッダー２はヘッダー２同士に、テクスチャはテクスチャ同士に合致させるためにそれぞれ独立した空間を要する。

次に、ビデオパケット終了可否を決める為に（Ｓ１１８）、ビデオパケットの一番目マクロブロック以後にヘッダー１、ヘッダー２、及びテクスチャのビットストリームが総体でどのくらい出ているかを計算して、その値が予め決めたビデオパケットの目標長さ値より大きくなるとビデオパケットを終了する事に決める。
ビデオパケットが終了するとステップＳｌ２２へ、終了しないとステップＳ１１０へそれぞれ分岐される。上記ステップＳｌ２２では、現在ビデオパケットに該当されるマクロブロック等からヘッダー１、ヘッダー２、テクスチャのパッキング過程を遂行する。
最終的に、ステップＳｌ２４ではビデオパケット（VP）ストリームをフェッチする。
以上から明らかなように、従来技術によると、マクロブロック符号化の結果で生じたヘッダー及びテクスチャビットストリームを使用者が併合しなければならないので、それだけCPUの負荷が余計にかかるようになる。特に、データ分割の場合ビデオパケット内のすべてのマクロブロックに対してヘッダー１、ヘッダー２、テクスチャをそれぞれ保管し、途中にビデオパケットが終わる毎に使用者がそれらを一つでパッキングする作業を行わなければならない。そのパッキング作業は多量のビートシフト及びメモリー入出力をし、CPUの負荷を増加させる。このような問題は従来技術の符号化装置では符号化方法を異にしても根本的に解決することができない。

従って、本発明が解決しようとする技術的課題は、MPEG-1、2、4またはH.261、H.263のように代表的なデジタル映像データ圧縮／復号標準を具現する映像符号化装置を制御するCPUの負荷を減らすことである。

上記の技術的課題を達成するために、本発明による映像符号化装置は、DCT変換と動き補償及び予測を通じて映像符号化を遂行する映像符号化装置において、現在マクロブロックの絶対偏差平均値（MAD）を求める動き補償（MC）ブロック、上記絶対偏差平均値（MAD）と量子化係数（QP）を基に現在マクロブロックの符号化後のビット量を予測してビデオパケットのパッキング可否を制御する制御部及び現在マクロブロックの符号化を遂行したとき、上記パッキングが可の場合にビデオパケットのパッキングを遂行する可変長符号化（VLC）ブロックを含むことを特徴とする。
本発明と本発明の動作での利点及び本発明の実施によって達成される目的を充分に理解するため、本発明の望ましい実施例を例示する添付図面及び添付図面に記載した内容を参照することができる。

本発明によると、第一に、VLCでパッキング、すなわちヘッダー（データ分割された場合はヘッダー１とヘッダー２）、そしてテクスチャを併合する過程を完璧に支援することでCPUの負荷を減らすことができる。
第二は、マクロブロックの符号化終了またはビデオパケットの符号化終了の後VLCメモリーの追加的な読み取り／書き込み、シフト、論理演算などが要求されないためCPUの負荷を減らすことができる。
第三は、符号化装置の制御が単純になる。使用者はマクロブロックまたはビデオパケットの符号化が終了した後、hmemの内容を単純にメインメモリー（MAIN_MEM）にフェッチすればよい。
第四は、データ分割された場合、パッキングを支援するためにビデオパケット内の多数マクロブロックのデータを一度にtmemとhmemとに貯蔵するとオーバーフローが起きる可能性を排除することができない。ところが、（式１）を利用してマクロブロックのビット量を予め予測すると、オーバーフローが発生する確率を１０万分の１以下の水準に低減することができる。オーバーフローが発生すると２個マクロブロック程の符号化時間が更にかかるが、これはパッキング支援で減ったCPU負荷に比べて殆ど無視し得る水準である。

以下、添付した図面を参照して本発明の望ましい実施例を説明する。
図６は、本発明による映像符号化装置のブロック図である。
図６を参照すると、本発明による映像符号化装置は符号化器（４００）、メモリー部（４０４、４０５）、中央処理装置（CPU）（４０１）及びメインメモリー部（４０２）、データバス（４０３）とで構成され、これらは図２の従来技術による映像符号化装置での符号化器（１００）、メモリー部（２０４、２０５）、中央処理装置（CPU）（２０１）及びメインメモリー部（２０２）、データバス（２０３）と等しい機能を遂行する。ただ、異なる点は、VLCブロック（４０６）がパッキングが可能になるように改善されたものであり、MCブロック（４０９）が絶対偏差平均値（MAD：Mean Absolute Difference）を求めて出力するということである。

上記絶対偏差平均値（MAD）は、一つのマクロブロックに対して現在フレームのデータと動き予測されたデータの差分値の構成でマクロブロックを計算した後、それぞれのピクセルの絶対値を全て併合して２５６で割った値であって、一般的に、この値が大きい程符号化されたビットストリームの長さが長くなる。
図面符号４１１は、MCブロック（４０９）で求められたMAD値であって、図面符号４１２は現在マクロブロックに適用される量子化係数（QP）値として、以後に記述するようにMAD値とQP値は、現在マクロブロックが符号化された後のビット量を予測することに使われる。また、図面符号４１３は、現在マクロブロックを符号化する以前に、VLCブロック（４０６）に供給されるパッキング可否を示す情報として、１であると現在マクロブロックでパッキングを遂行して、０であると遂行しない。参照で、上記QPは既に知られているように、量子化率を決める制御アルゴリズムによって決めることができる。

図７は、本発明によるVLCブロックの詳細ブロック図である。
ヘッダーロムテーブル（mb_rom）（５０８）は、ヘッダーの符号化に必要な様々なテーブルを含む。
ヘッダーメモリー（hmem）（５０６）は、ヘッダーの符号化結果を保存し、データ分割可否によってヘッダー１とヘッダー２とに区分されることもある。
テクスチャ符号化制御部（texture_ctrl）（５０２）は、テクスチャ符号化の制御を行う。
テクスチャロムテーブル（ac_rom）（５０３）は、テクスチャの符号化に必要様々なテーブルを含む。
テクスチャメモリー（tmem）（５０１）は、テクスチャの符号化結果を貯蔵する。
パッキング実行部（pack_ctrl）（５０４）は、ヘッダーとテクスチャのパッキングを担当する。上記パッキングはヘッダーメモリー（hmem）（５０６）及び／又はテクスチャメモリー（tmem）（５０１）から一定の単位でデータを読み出し次第にヘッダーメモリー（hmem）（５０６）に再び書き込む過程である。

パッキングを遂行する場合は次の二つの種類がある。
第一は、マクロブロック符号化のスタート前にCPU（４０１）からパッキング可否に対する制御信号、即ち、PEN値（４１３）を通じて該マクロブロックの符号化が終わった次第にパッキングを行うと言う命令を受けた場合。
第二は、マクロブロック符号化を遂行する途中にテクスチャメモリー（tmem）（５０１）またはヘッダーメモリー（hmem）（５０６）でオーバーフローが発生した場合。
VLCレジスター部（VLC_reg）（５０５）は、ヘッダー及びテクスチャ符号化に必要な様々な設定をCPU（４０１）から受け、テクスチャ符号化制御部（texture_ctrl）（５０２）、パッキング実行部（pack_ctrl）（５０４）（５０４）、ヘッダー符号化制御部（header_ctrl）（５０７）へ伝達する。

図８は、本発明によるパッキング実行部（pack_ctrl）の詳細ブロック図である。図８を参照すると、パッキング実行部（pack_ctrl）はパッキング実行制御部（pack control）（６０１）、パッキング演算部（pshifter）（６０２）、テクスチャメモリー制御部（texture memory control）（６０５）、及びヘッダーメモリー制御部（header memory control）とで構成される。
パッキング実行制御部（pack control）（６０１）は、パッキング実行部（pack_ctrl）（５０４）の全体的な制御を担当する。ここで、VLCレジスター部（VLC_reg）（５０５）から入力されるpack_en信号は、PEN値（４１３）と等しい値としてパッキング遂行の可否を示す。
また、ヘッダー符号化制御部（header_ctrl）（５０７）から入力されるhend信号は、現在マクロブロックのヘッダー符号化が完了したことを示す信号で、hoverflow信号は、ヘッダー符号化の中にオーバーフローが発生してpack_enと係わらずに、強制的にパッキングが進行されるべきであることを示す信号である。

また、テクスチャ符号化制御部（texture_ctrl）（５０２）から入力されるtend信号は、現在マクロブロックのテクスチャ符号化の完了を示す信号であり、toverflow信号は、テクスチャ符号化の中にオーバーフローが発生してpack_en信号と係わらずに強制的にパッキングが進行されるべきであることを示す信号である。
パッキング実行制御部（pack control）（６０１）は、pack_en、toverflow、またはhoverflow信号が１であるとtend信号とhend信号を通じてヘッダー及びテクスチャ符号化がそれぞれ完了したかを確認し、完了すると、p_start信号でパッキングを行うように命令する。
パッキング演算部（pshifter）（６０２）は、実際にパッキングを遂行する。ヘッダー符号化制御部（header_ctrl）（５０７）からh1_start_pos、h1_end_pos、h2_start_pos、h2_end_pos信号が入力され、順番に現在マクロブロックでヘッダー１（データ分割されない場合はヘッダー）のスタート位置、ヘッダー１（データ分割されない場合はヘッダー）の終了位置、ヘッダー２のスタート位置、ヘッダー２の終了位置を意味する。h2_start_posとh2_end_pos信号の値はデータ分割された場合のみ有効である。

図８で‘_pos’で終わる信号は、テクスチャメモリー（tmem）（５０１）またはヘッダーメモリー（hmem）（５０６）上でビット単位の位置を示す信号である。テクスチャ符号化制御部（texture_ctrl）（５０２）からt_start_pos、t_end_pos信号が入力され、順番に現在マクロブロックでテクスチャのスタート位置、テクスチャの終了位置を意味する。
パッキング演算部（pshifter）（６０２）は、シフト＆マージ（shift&merge）ブロック（６０３）とレジスターファイルブロック（register file）（６０４）ブロックとで構成される。
シフト＆マージブロック（６０３）は、テクスチャメモリー（tmem）（５０１）及び／またはヘッダーメモリー（hmem）（５０６）から出た二つの３２bit単位をそれぞれ適切にシフトし、マージしてパッキングされた新しい一つの３２bit単位を生ずるブロックである。

レジスターファイルブロック（６０４）は、pre_h1_start_pos、pre_h2_start_pos、pre_t_start_pos信号を蓄積するのに、データ分割された場合にだけ使われる。
pre_h1_start_posは、ヘッダーメモリー（hmem）（５０６）上でビデオパケットの一番目マクロブロックに対するヘッダー１のスタート位置である。pre_h2_start_posはヘッダーメモリー（hmem）（５０６）上でビデオパケットの一番目マクロブロックに対するヘッダー２のスタート位置である。
pre_t_start_posは、テクスチャメモリー（tmem）（５０１）上でビデオパケットの一番目マクロブロックに対するテクスチャスタート位置である。データ分割された場合には、ビデオパケットに含まれたすべてのマクロブロックの符号化されたデータをパッキングすべきであるから、レジスターファイルブロック（６０４）に保存された内容が必要である。
テクスチャメモリー制御部（６０５）は、テクスチャメモリー（tmem）（５０１）でパッキングに必要なデータをパッキング演算部（pshifter）（６０２）に送るブロックである。
ヘッダーメモリー制御部（６０６）は、ヘッダーメモリー（hmem）（５０６）でパッキングに必要なデータをパッキング演算部（pshifter）（６０２）に送り、パッキングされたデータを再びヘッダーメモリー（hmem）（５０６）に記録するブロックである。万一、パッキングされたデータでヘッダーメモリー（hmem）（５０６）がフルになると、テクスチャメモリー（tmem）に引き続き記録する。

図９は、データ分割されない場合のパッキングの実施例を示す。
h1_start_posとt_start_posは、それぞれヘッダーとテクスチュアの書き込み開始位置（bit単位）を示す。マクロブロックの符号化が始まって、ヘッダーとテクスチュアがそれぞれ全て符号化されると、h1_end_posとt_end_posは、それぞれヘッダーとテクスチュアの終了位置を示す。そしてパッキングが完了するとp_end_posはヘッダーとテクスチュアとがパッキングされた後、マクロブロックデータの終わりを示す。
データ分割されない場合は、すべてのマクロブロック毎にパッキングが遂行するようにCPU（４０１）から命令を受ける。例として、hmemとtmemは３２bit幅を持つメモリーであって、それぞれ１２８ワードまたは４０９６ビットを貯蔵することができる。
h1_start_posは０〜４０９５の値を持ち、過去マクロブロックストリームの終了位置によって０〜３１間の値が入るように進む。t_start_posも０〜４０９５の値を持ち、符号化結果の書き込む空間を最大限確保することができるように０を入れる。符号化が終わるとh1_start_posとp_end_posを参照して符号化されたストリームをフェッチすることができる。

図１０は、データ分割された場合のパッキングの実施例を示す。ここで、符号化するビデオパケットは三つのマクロブロックになる。
h1_start_pos、h2_start_pos、t_start_posは、それぞれ三番目マクロブロック、すなわちビデオパケットの最後のマクロブロックのヘッダー１、ヘッダー２とテクスチュアが使われ始める位置（bit単位）を示す。
pre_h1_start_pos、pre_h2_start_pos、pre_t_start_posは、それぞれビデオパケットの初マクロブロックのヘッダー１、ヘッダー２とテクスチュアが書き込みし始める位置として、パッキングする時利用される。
h1_end_pos、h2_end_pos、t_end_posは、それぞれビデオパケットの最後のマクロブロックのヘッダー１、ヘッダー２とテクスチュアが書き込まれた最後の位置である。
図１０は、一番目、二番目マクロブロックはPEN値（４Ｂ）を０とし、また三番目、すなわちビデオパケットの最後のマクロブロックでPEN値（４１３）を１として符号化した場合である。ビデオパケットの最後のマクロブロックのヘッダー１、ヘッダー２とテクスチュアの符号化が終わると３個マクロブロックのヘッダー１、ヘッダー２、テクスチュアが順番にパッキングされる。
万一、三番目マクロブロックを符号化する間tmemでオーバーフローが発生すると、PEN値（４１３）に構わずに一番目と二番目マクロブロックだけ強制にパッキングされて、VLCが修了される。
データ分割された場合は、次の３種類のオーバーフローが発生することがある。
h1 overflow：ヘッダー１の符号化結果がh2_start_pos（ヘッダー２のスタートアドレス）を超過する場合。
h2 overflow：ヘッダー２の符号化結果がhmemの大きさを超過する場合。
t overflow：テクスチュアの符号化結果がtmemの大きさを超過する場合。

図１１は、データ分割された時の本発明によるビデオパケットの符号化過程を示す。
ステップＳ２００で、再同期マーカーとビデオパケットヘッダーを挿入する。
ステップＳ２１０では現在マクロブロックの符号化結果に、ビットストリームの長さ、即ちマクロブロックビット量を予測する。
上記マクロブロックビット量は次のように（式２）予測される。
（式２）
bit_est = 140 × (MAD/QP) + offset
ここで、bit_estは予測されるビット量であり、１４０は実験的に得られた値である。offsetは、０以上の値として、この値が高いほど実際に出るビット量がbit_estより小さい確率が大きくなる（具体的な数値は図１３で説明される。）
offsetが大きいほど実際ビット量がbit_estより大きくなる確率が減って、オーバーフローをより確実に防止することができるが、ビット量予測が実際より増加する傾向が現われることもある。（式２）でMAD値とQPは既に他のブロックで求められた値であって、別に求める必要がない値である。

ステップＳ２１２では、ビデオパケットパッキング可否を決めることにっいて、現在ビデオパケットの長さに該予測値を加えた値が予め決めたビデオパケット長さより大きいとか、次のマクロブロックまでビデオパケットに包含させる場合、hmemまたはtmemでオーバーフローが生じると予想されると、PEN値（４１３）を１で設定して現在マクロブロックでパッキングを遂行してビデオパケットを仕上げる。
ステップＳ２１４では、実際にマクロブロック符号化が遂行される。
ステップＳ２１６では、現在マクロブロックがビデオパケットの終わりであると、ステップＳ２１８に分岐し、そうではなければステップＳ２１０に分岐する。
ステップＳ２１８では、完成されたビデオパケットストリームをメインメモリー部（４０２）にフェッチする。

図１２は、（式２）を導く上で根拠になった実験資料として、マクロブロック当たりビット量とMAD/QP値との関係を示す。マクロブロック毎に差があるがマクロブロックのビット量はMAD/QP値にほぼ比例することが分かる。
図１３は、（式２）のoffset値によって、マクロブロックの実際ビット量がbit_estより小さい確率がどのように変わるかを示し、offsetが５０である場合は約９５．０％、７０である場合は約９８．１％、１００である場合は約９９．４％である。
目標とするビデオパケットの長さがtmemまたはhmemの大きさと殆ど類似すると、このoffset値を充分に大きく供給して実際にオーバーフローが発生する場合を最小化することができる。
目標とするビデオパケットの長さがtmemまたはhmemの大きさより充分に小さいと、offset値を５０程度のみ取ってもオーバーフローが殆ど発生しないようにすることができる。

図１４は、データ分割された場合、本発明によるVLCオーバーフロー処理過程を示す。
Ｎ番目マクロブロックを符号化する途中にオーバーフローが発生すると、（Ｎ−１）番目マクロブロックまで符号化されたヘッダー１、ヘッダー２、テクスチャをパッキングし、そのマクロブロックの動作を終える。
万一、オーバーフローが発生した時、（Ｎ＋１）番目マクロブロックの動き予測（ME）が進行していると、その動作が終わるまで待たなければならない。
次の過程は、Ｎ番目マクロブロックを符号化することでMC部（４０９）とME部（４１０）のメモリー及びレジスターの内容が（Ｎ＋１）番目マクロブロックに合致するように入っているので、Ｎ番目マクロブロックの動き予測をもう一度遂行する必要がある。
その後、（Ｎ＋１）番目マクロブロックの動き予測とＮ番目マクロブロックのテクスチャコーディング（TC: texture coding）が同時になる正常な状態で開始することになる。

よって、VLCオーバーフローが一回発生する時毎に、二つマクロブロックの符号化のための時間が追加される。ところが、tmemの大きさをビデオパケットが要る最大の大きさより約２００bit程大きく取っても、オーバーフローが発生する確率は１０万分の２以下に維持されて殆ど影響がない。（ビデオパケットに含まれるマクロブロックの平均個数を１５個で仮定した場合）tmemの大きさをもっと大きく取るとオーバーフロー確率はもっと減る。
非常に珍しい場合だが、データ分割されない場合に、符号化途中hmemまたはtmemでオーバーフローが発生すると、符号化装置はそのまま動作を中止する。そのようになると、中止された時点で符号化を進行したマクロブロックのデータはパッキングされない状態で残る。そのように中止されたマクロブロックは殆どnoiseに近い映像になる確率が高くなり、量子化係数を高くし次第次の符号化を再実行することができる。

従来技術による符号化器のブロック図である。 従来技術による映像符号化装置のブロック図である。 図２の符号化器をパイプライン構造を用いてＮ個のマクロブロックになるフレームを符号化する方法のフローチャートである。 従来技術によるVLC部の詳細ブロック図である。 データが分割された時、VP（ビデオパケット）符号化過程を示すフローチヤートである。 本発明による映像符号化装置のブロック図である。 本発明によるVLCブロックの詳細ブロック図である。 本発明によるパッキング実行部（pack_ctrl）の詳細ブロック図である。 データ分割になってない場合のパッキングの実施例を示す。 データ分割になった場合のパッキングの実施例を示す。 データ分割された時の本発明によるビデオパケットの符号化過程を示すフローチャートである。 （式２）を導く基になった実験資料である。 （式２）のoffset値によって、マクロブロックの実際ビット量がbit_estより小さくなる確率がどのように変化するかを示す図である。 データ分割された場合、本発明によるVLCオーバーフロー処理過程を示すフローチャートである。

符号の説明

４００・・・符号化器、４０１・・・CPU、４０２・・・メインメモリー部、４０４，４０５・・・メモリー部、４０６・・・VLCブロック、４０９・・・MCブロック、４１１・・・MAD値、４１２・・・QP値、４１３・・・PEN値。

Claims (8)

1. DCT変換と動き補償及び予測を通じて映像符号化を遂行する映像符号化装置において、
   現在マクロブロックの絶対偏差平均値（MAD）を求める動き補償（MC）ブロック；
   上記絶対偏差平均値（MAD）と量子化係数（QP）を基に現在マクロブロックの符号化後のビット量を予測してビデオパケットのパッキング可否を制御する制御部；及び
   現在マクロブロックの符号化を遂行したとき、上記パッキングが可の場合にビデオパケットのパッキングを遂行する可変長符号化（VLC）ブロックを含むことを特徴とする映像符号化装置。
2. 請求項１に記載された映像符号化装置において、
   上記制御部は下記の（式１）によって現在マクロブロックのビット量を予測して、現在ビデオパケットで過去マクロブロックまでビット量の合計にbit_estを加えた値が予め決めたビデオパケットの目標長さより大きくなる場合にビデオパケットのパッキングを可とすることを特徴とする映像符号化装置。
   （式１）
   bit_est = k × (MAD/QP) + offset
   ここで、bit_estは予測されるビット量で、ｋは実験的に求められた定数であり、offsetはマクロブロックが予測されたビット量以内に符号化される確率を調節する変数である。
3. 請求項１に記載された映像符号化装置において、
   上記可変長符号化（VLC）ブロックは、ヘッダー符号化の制御を担当するヘッダー符号化制御部（header_ctrl）；
   ヘッダーを符号化するのに必要な様々なテーブルを含むヘッダーロムテーブル（mb_rom）；
   ヘッダーの符号化結果を貯蔵するヘッダーメモリー（hmem）；
   テクスチャ符号化の制御を担当するテクスチャ符号化制御部（texture_ctrl）；
   テクスチャを符号化するのに必要なさまざまなテーブルを含むテクスチャロムテーブル（ac_rom）；
   テクスチャの符号化結果を貯蔵するテクスチャメモリー（tmem）；
   ヘッダーとテクスチャの符号化結果のパッキングを担当するパッキング実行部（pack_ctrl）；及び
   ヘッダー及びテクスチャ符号化に必要な様々な設定を貯蔵するVLCレジスター部（VLC_reg）を含むことを特徴とする映像符号化装置。
4. 請求項３に記載された映像符号化装置において、
   上記パッキング実行部（pack_ctrl）は、
   上記パッキング実行部（pack_ctrl）の全体的な制御を担当するパッキング実行制御部（pack control）；
   パッキングを実際に遂行するパッキング演算部（pshifter）；
   テクスチャメモリー（tmem）でパッキングに必要なデータをパッキング演算部（pshifter）に供給するテクスチャメモリー制御部（texture memory control）；及び
   ヘッダーメモリー（hmem）でパッキングに必要なデータをパッキング演算部（pshifter）に供給し、パッキングされたデータを更にヘッダーメモリー（hmem）に記録するヘッダーメモリー制御部（header memory control）を含むことを特徴とする映像符号化装置。
5. 請求項４に記載された映像符号化装置において、
   上記パッキング実行制御部（pack control）は
   上記パッキングが可である場合、現在マクロブロックのテクスチャ符号化中にテクスチャメモリー（tmem）がオーバーフローした場合、または現在マクロブロックのヘッダー符号化中にヘッダーメモリー（hmem）がオーバーフローした場合、ヘッダー及びテクスチャ符号化がそれぞれ完了されたのかを確認して、完了するとパッキング演算部（pshifter）にパッキングを開始させることを特徴とする映像符号化装置。
6. 請求項１乃至請求項５のいずれか１項に記載された映像符号化装置において、
   データ分割されないビデオパケットの場合には現在マクロブロックの符号化されたデータをパッキングしてヘッダーメモリー（hmem）に記録することを特徴とする映像符号化装置。
7. 請求項１乃至請求項６のいずれか１項に記載された映像符号化装置において、
   データ分割されたビデオパケットの場合には現在ビデオパケットに含まれたすべてのマクロブロックの符号化されたデータをパッキングしてヘッダーメモリー（hmem）に記録することを特徴とする映像符号化装置。
8. 請求項７に記載された映像符号化装置において、
   Ｎ番目マクロブロックのテクスチャ符号化を進行する間にテクスチャメモリー（tmem）またはヘッダーメモリー（hmem）にオーバーフローが発生する場合に、
   現在ビデオパケットに対してビデオパケットのスタートマクロブロックから（Ｎ−１）番目マクロブロックまで強制にパッキングを遂行し；
   Ｎ番目マクロブロックに対する動き予測を再遂行し；
   Ｎ番目マクロブロックのテクスチャ符号化と（Ｎ＋１）番目マクロブロックに対する動き予測を同時に遂行することを特徴とする映像符号化装置。

Images