"ブロック係数列を可変長符号化して得られるビットストリームに対してバイトアラインメントを行うための装置であって、基準係数列挿入部と、所望増加ビット量算出部と、調整係数列検索部と、調整係数列挿入部とを備えており、前記基準係数列挿入部は、量子化されたブロック係数列のうちの高周波成分である調整係数列を、既定の基準係数列に置換する構成となっており、前記所望増加ビット量算出部は、前記調整係数列が前記基準係数列に置換された前記ブロック係数列を可変長符号化して得られるビットストリームの符号量に基づいて、バイトアラインメントのために増加させるべきビット量を算出する構成となっており、前記調整係数列検索部は、前記増加させるべきビット量に基づいて、前記基準係数列に置換されるべき適切な調整係数列を検索する構成となっており、前記調整係数列挿入部は、検索された前記調整係数列を前記基準係数列に対応する高周波成分に挿入する構成となっているバイトアラインメント装置。さらにガード係数挿入部を備えており、前記ガード係数挿入部は、前記ブロック係数列における前記高周波成分係数列よりも1次数だけ低周波側に位置する係数を、ガード係数に置換する構成となっており、前記ガード係数は、前記ガード係数よりも低周波側の係数の値による、前記ビットストリームの符号量への影響を抑制するものである請求項1に記載のバイトアラインメント装置。前記調整係数列検索部は、前記増加させるべきビット量に加えて、可変長符号化後のビットストリームの符号量に影響する要因に基づいて、前記適切な調整係数列を検索する構成となっている請求項1又は2に記載のバイトアラインメント装置。さらに検索DBを備えており、前記検索DBは、前記増加させるべきビット量、及び/又は、可変長符号化後のビットストリームの符号量に影響する要因に基づいて、前記適切な調整係数列を検索できる構成となっている請求項1~3のいずれか1項に記載のバイトアラインメント装置。請求項1~4のいずれか1項に記載のバイトアラインメント装置と、可変長符号化部とを備えており、前記可変長符号化部は、前記バイトアラインメント装置によるバイトアラインメント処理の対象となる対象ブロックに隣接する隣接ブロックの係数列を可変長符号化する際には、前記対象ブロックの符号化における予測モードの制限、及び/又は、符号化に用いる係数値の固定を行う構成となっているビットストリーム生成装置。ブロック係数列を可変長符号化して得られるビットストリームに対してバイトアラインメントを行うために用いるビットストリーム生成方法であって、量子化されたブロック係数列のうちの高周波成分である調整係数列を、既定の基準係数列に置換するステップと、前記調整係数列が前記基準係数列に置換された前記ブロック係数列を可変長符号化して得られるビットストリームの符号量に基づいて、バイトアラインメントのために増加させるべきビット量を算出するステップと、前記増加させるべきビット量に基づいて、前記基準係数列に置換されるべき適切な調整係数列を検索するステップと、検索された前記調整係数列を前記基準係数列に対応する高周波成分に挿入するステップとを備える、ビットストリーム生成方法。請求項6に記載の方法をコンピュータに実行させるためのコンピュータプログラム。ブロック係数列によって構成されるデータ構造であって、前記ブロック係数列における高周波成分係数は、可変長符号化後のビットストリームにおけるバイトアラインメントを行うための調整係数列とされており、前記調整係数列よりも1次数だけ低周波側の係数には、ガード係数が挿入されており、前記ガード係数は、このガード係数よりも低周波側にある低周波成分係数の値による、可変長符号化条件への影響を抑制するものとなっているデータ構造。本発明は、前記の状況に鑑みてなされたものである。本発明の目的の一つは、ビットストリーム抽出処理におけるシフト演算処理を回避し、処理負荷を抑制することが可能な技術を提案することである。本発明のより具体的な目的は、MB中のブロックの係数列を調整することにより、MB群単位で符号化されるビットストリームのビット量を調整し、これによって、任意のMB群から生成されるビットストリームをバイトアラインメントする技術を提供することである。前記した課題を解決する手段は、以下の項目のように記載できる。項目1ブロック係数列を可変長符号化して得られるビットストリームに対してバイトアラインメントを行うための装置であって、基準係数列挿入部と、所望増加ビット量算出部と、調整係数列検索部と、調整係数列挿入部とを備えており、前記基準係数列挿入部は、量子化されたブロック係数列のうちの高周波成分である調整係数列を、既定の基準係数列に置換する構成となっており、前記所望増加ビット量算出部は、前記調整係数列が前記基準係数列に置換された前記ブロック係数列を可変長符号化して得られるビットストリームの符号量に基づいて、バイトアラインメントのために増加させるべきビット量を算出する構成となっており、前記調整係数列検索部は、前記増加させるべきビット量に基づいて、前記基準係数列に置換されるべき適切な調整係数列を検索する構成となっており、前記調整係数列挿入部は、検索された前記調整係数列を前記基準係数列に対応する高周波成分に挿入する構成となっているバイトアラインメント装置。項目2さらにガード係数挿入部を備えており、前記ガード係数挿入部は、前記ブロック係数列における前記高周波成分係数列よりも1次数だけ低周波側に位置する係数を、ガード係数に置換する構成となっており、前記ガード係数は、前記ガード係数よりも低周波側の係数の値による、前記ビットストリームの符号量への影響を抑制するものである項目1に記載のバイトアラインメント装置。項目3前記調整係数列検索部は、前記増加させるべきビット量に加えて、可変長符号化後のビットストリームの符号量に影響する要因に基づいて、前記適切な調整係数列を検索する構成となっている項目1又は2に記載のバイトアラインメント装置。項目4さらに検索DBを備えており、前記検索DBは、前記増加させるべきビット量、及び/又は、可変長符号化後のビットストリームの符号量に影響する要因に基づいて、前記適切な調整係数列を検索できる構成となっている項目1~3のいずれか1項に記載のバイトアラインメント装置。項目5項目1~4のいずれか1項に記載のバイトアラインメント装置と、可変長符号化部とを備えており、前記可変長符号化部は、前記バイトアラインメント装置によるバイトアラインメント処理の対象となる対象ブロックに隣接する隣接ブロックの係数列を可変長符号化する際には、前記対象ブロックの符号化における予測モードの制限、及び/又は、符号化に用いる係数値の固定を行う構成となっているビットストリーム生成装置。項目6ブロック係数列を可変長符号化して得られるビットストリームに対してバイトアラインメントを行うために用いるビットストリーム生成方法であって、量子化されたブロック係数列のうちの高周波成分である調整係数列を、既定の基準係数列に置換するステップと、前記調整係数列が前記基準係数列に置換された前記ブロック係数列を可変長符号化して得られるビットストリームの符号量に基づいて、バイトアラインメントのために増加させるべきビット量を算出するステップと、前記増加させるべきビット量に基づいて、前記基準係数列に置換されるべき適切な調整係数列を検索するステップと、検索された前記調整係数列を前記基準係数列に対応する高周波成分に挿入するステップとを備える、ビットストリーム生成方法。項目7項目6に記載の方法をコンピュータに実行させるためのコンピュータプログラム。項目8ブロック係数列によって構成されるデータ構造であって、前記ブロック係数列における高周波成分係数は、可変長符号化後のビットストリームにおけるバイトアラインメントを行うための調整係数列とされており、前記調整係数列よりも1次数だけ低周波側の係数には、ガード係数が挿入されており、前記ガード係数は、このガード係数よりも低周波側にある低周波成分係数の値による、可変長符号化条件への影響を抑制するものとなっているデータ構造。本発明によれば、任意のMB群から生成されるビットストリームをバイトアラインメントする技術を提供することができる。以下、添付図面を参照しながら、本発明の第1実施形態に係る符号化システムについて説明する。本実施形態の構成まず、本実施形態の符号化システムが使用される符号化装置全体の概略的構成を、図1を参照しながら説明する。このシステムは、整数精度変換部1と、量子化部2と、バイトアラインメント処理部3と、可変長符号化部4とから構成されている。以下、各要素について説明する。整数精度変換部整数精度変換部1は、ブロック係数列フレーム内符号化の場合またはブロック係数列の残差信号フレーム間符号化の場合が入力されるものである。なお、この明細書では、ブロック係数列とその残差信号との両者を含めてブロック係数列と総称する。整数精度変換部1は、実数精度の入力値を整数精度に変換するものであり、これは、従来のH264での実装と同様に構成できるので、これについての詳しい説明は省略する。量子化部量子化部2は、整数精度変換されたブロック係数列を量子化する機能要素である。この量子化部2も、従来のH264での実装と同様に構成できるので、これについての詳しい説明は省略する。バイトアラインメント処理部バイトアラインメント処理部3は、本発明のバイトアラインメント装置の一実施形態に対応する機能要素である。本実施形態のバイトアラインメント処理部3は、図2に示すように、基準係数列挿入部31と、所望増加ビット量算出部32と、調整係数列検索部33と、調整係数列挿入部34と、ガード係数挿入部35と、検索DB36とを備えている。基準係数列挿入部31は、量子化されたブロック係数列のうちの高周波成分である調整用の係数列後述のTailCoeffを、既定の基準係数列に置換する構成となっている。所望増加ビット量算出部32は、調整用の係数列が基準係数列に置換された状態のブロック係数列を可変長符号化して得られるビットストリームの符号量に基づいて、バイトアラインメントのために増加させるべきビット量を算出する構成となっている。調整係数列検索部33は、増加させるべきビット量に基づいて、基準係数列高周波成分係数列に置換されるべき適切な調整係数列を検索する構成となっている。さらに、本実施形態の調整係数列検索部33は、増加させるべきビット量に加えて、可変長符号化後のビットストリームの符号量に影響する要因後述に基づいて、適切な調整係数列を検索する構成となっている。調整係数列挿入部34は、検索された調整係数列を、基準係数列に対応する高周波成分に挿入する構成となっている。ガード係数挿入部35は、ブロック係数列における高周波成分係数列よりも1次数だけ低周波側に位置する係数を、ガード係数以下GuardCoeffということがあるに置換する構成となっている。GuardCoeffには固定係数値本例では絶対値2以上の係数を挿入する。ここで、ガード係数とは、ガード係数よりも低周波側の係数の値による、ビットストリームの符号量への影響を抑制するものである後述。ガード係数の位置は、ガード係数の挿入時には既に分かっているものとする。ガード係数の位置の探索については後述する。検索DB36は、増加させるべきビット量、及び/又は、可変長符号化後のビットストリームの符号量に影響する要因に基づいて、適切な調整係数列を検索できる構成となっている。本実施形態の検索DB36は、具体的にはテーブル構造となっている図3参照が、DBの構造には特に制約はない。本明細書では、検索DBを検索テーブルと称することがある。本実施形態では、ビットストリーム符号量に影響するパラメータの一部を検索テーブルの検索キーとし、残りのパラメータを固定値としている。本実施形態のバイトアラインメント処理部3の詳しい構成については、本実施形態の動作として後述する。可変長符号化部可変長符号化部4は、各ブロックの係数列に対して、可変長符号化を行う機能要素である。本実施形態の可変長符号化部4は、バイトアラインメント装置によるバイトアラインメント処理の対象となる対象ブロックに隣接する隣接ブロックの係数列を可変長符号化する際には、対象ブロックの符号化における予測モードの制限、及び/又は、符号化に用いる係数値の固定を行う構成となっている。この点を除き、本実施形態の可変長符号化部4は、例えばH264における、CAVLCContextAdaptiveVariableLengthCodingを用いた可変長符号化部と同様に構成することができる。本実施形態の可変長符号化部4の詳しい構成についても、本実施形態の動作として後述する。本実施形態におけるビットストリーム生成手順以下、本実施形態におけるビットストリーム生成手順を、図4をさらに参照しながら説明する。なお、以下の例では、バイトアラインメントの対象となるMB群を、MBが一列に配置されて構成されたMBラインとする。また、本例において係数調整の対象とするブロックは、MBラインにおける最終MBの最終ブロックとする図9b参照。図4のステップSA-1~3まず、符号化前の映像信号の入力を受け付け、その係数列を整数精度に変換する。さらに、整数精度に変換された係数列を量子化する。ここまでの処理は通常のH264と同様でよいので、詳しい説明は省略する。図4のステップSA-4~5ついで、本実施形態のバイトアラインメント処理部3を用いたバイトアラインメント処理の手順を、図5をさらに参照しながら説明する。図5のステップSB-0可変長符号化部4は、係数列の調整を行うブロック対象ブロックを除く各ブロックについて、可変長符号化を行う。その結果得られるビットストリームの合計ビット数により、対象ブロックを除くMBラインのビットストリームのビット量を得ることができる。このビット量と、対象ブロック係数列の符号化によるビットストリームの符号量とを加算することにより、MBライン全体のビットストリームの符号量を取得することができる。この符号量が、バイトアラインメント処理の基準となる。図5のステップSB-1まず、バイトアラインメント処理部3は、量子化部2から、対象ブロックについての量子化処理が行われたブロック係数列を取得する。ここで、ブロック係数列の例を、図6を参照しながら補足して説明する。H264では、1枚の画像を構成するフレーム100が、複数のMBライン101~10nで構成されており、各MBラインは、複数のMBで構成されている図6a参照。そして、各MBは、複数のブロックにより構成されている図6b参照。H264では、各ブロックは、4×4画素形成されている。図6では、各ブロックに1~16のインデックスを付している。そして、量子化により、各インデックスに対応する量子化された係数値を特定することができる。このような各インデックスの係数値を、ジグザグスキャン図6c参照することによって、ブロックにおける係数列を生成することができる図6d参照。図6dに示す数字は、係数のインデックスを示しており、係数値を示すものではない。図6dにおいて、11番の係数インデックスが、後述するガード係数となっており、それよりも高周波側図6において右側の係数列が、調整のために置換される係数列以下TailCoeffということがあるであり、それよりも低周波側図6において左側の係数列が、信号の内容を示す係数列以下LeftPartCoeffということがあるである。なお、本例において係数列を調整する対象となるブロックのインデックス番号は16である図6b参照。図5のステップSB-2ついで、基準係数列挿入部31は、前記したTailCoeffを、予め準備しておいた基準係数列以下BaseCoeffということがあるに置換する。本実施形態では、基準係数列として、00000という値が用いられている。これは、CAVLCにおいては、00000という係数列を用いたときに、符号化後のビット量を最小とすることができるためである。図5のステップSB-3ついで、当該ブロック係数列の符号化が、初期のTailCoeffを置換した後の最初のものであるかどうかを確認する。すなわち、当該ブロック係数列の可変長符号化は、バイトアラインメントのために2度行われる。1度目は、TailCoeffを基準係数列で置き換えた係数列を可変長符号化し、2度目は、TailCoeffを調整係数列で置き換えた係数列を可変長符号化する。ここでの判定がYesであればステップSB-4に進む。図5のステップSB-4及びSB-5ついで、TailCoeffをBaseCoeffに置換し、置換後の係数列を用いて、可変長符号化部4により可変長符号化を行う。図5のステップSB-6及びSB-7つぎに、所望増加ビット量算出部32は、可変長符号化により得られた対象ブロックの符号量と、ステップSB-0で取得していた符号量とを合計して得られた符号量つまりMBライン全体の符号量をXとし、8を法とするXの剰余量、つまりXmod8を計算する。そして、この剰余量と8との差を算出する。その結果が、ビットストリームのビット数についての所望増加量となる。図5のステップSB-8ついで、得られた所望増加量と、他の係数特性とを用いて、検索テーブル36から、TailCoeffに挿入されるべき調整係数列を検索して取得する。すなわち、検索テーブル36においては、増加ビット量に影響する各要因本例では所望増加ビット量、LeftPartTotalCoeff、NeighborTotalCoeffに基づいて、適切な調整係数列を検索できるようになっている。この検索についてはさらに後述する。なお、ガード係数の位置つまりGuardIndexは、図8に示す検索テーブルの生成時に取得されるが、これについても後述する。ここで、係数列の説明に用いられる用語について、下記表1に示す。また、可変長符号化における符号化テーブルの選択要因となるパラメータと、本実施形態における措置とを下記表2に示す。図5のステップSB-3,SB-9,SB-5ついで、手順は再びステップSB-3に戻り、その後ステップSB-9に進む。さらに、調整係数列挿入部34は、検索テーブルから得られた調整係数列を、TailCoeffに挿入する。調整係数列が挿入されたブロック係数列に対して可変長符号化を行い、得られたビットストリームを出力する。このようにして得られたビットストリームを用いて、MBラインのビットストリームを構成することにより、バイトアラインメントを実行することができる。本実施形態では、前記のようにして、バイトアラインメントを、簡便な手段で、実現することができる。さらに、任意のMBに属するブロックを対象として、前記したバイトアラインメントの処理を実行することができる。また、本実施形態では、ブロック係数列にガード係数を挿入したので、TailCoeffを調整係数列に置換しても、符号化条件への影響を抑制できるという利点もある。ただし、CAVLCを前提にすると、ガード係数の値は2又は3となる。この点は後述する。ここで、ガード係数挿入の利点について補足説明する。実際の可変長符号化の際には、TotalCoeffとTrailingOnesの組合せであるCoeffTokenパラメータも符号化されるので、その符号量が全体ビットストリームの符号量に影響する。ガード係数挿入により、TailCoeffの変更によるCoeffTokenパラメータの符号量への影響を抑制することができる。但し、CoeffTokenの符号化テーブルは、隣接ブロックの非ゼロ係数個数の平均値NeighborTotalCoeffにより決定するため、係数列全体が同一でも、NeighborTotalCoeffに応じてCoeffTokenの符号量は異なる。よって、あるLeftPartCoeffに対してあるビット量増加を実現するTailCoeffが存在する場合でも、NeighborTotalCoeffが異なると、同一のTailCoeffであっても、所望のビット量増加を実現することは出来ない。以上から、NeighborTotalCoeffが同じCoeffTokenを符号化するテーブルが同じであるならば、上記パラメータ設定により、LeftPartCoeffとTailCoeffを独立に考えることが可能となり、TailCoeffの係数列調整によって、それ以外の係数列LeftPartCoeff,GuardCoeffの符号化に影響を与えることなく1から7ビットの増加量を制御することが可能となる。図4のステップSA-6ついで、バイトアラインメント処理が行われたブロック係数列の可変長符号化により生成されたビットストリームを出力する。これらの処理自体は従来と同様でよいので、詳しい説明は省略する。図4のステップSA-7:検索テーブル生成手順次に、図8を参照して、調整係数列を検索するための検索テーブルの生成手順について説明する。なお、検索テーブルの生成は、前記した調整係数列の検索よりも前に行われる。図8のSC-1まず、前提として、GuardCoeffの値は2又は3に設定し、以下で使用する絶対値Aは3以下とする。また、ガード係数の位置GuardIndexは、この段階では任意の値であるが、この例では高周波側の値本例では16から順次検証していき、1~7ビットのビット量増減値に対応できるGuardIndex本実施形態では11をみつける。以下、これらの理由を補足する。TailCoeffの数値定義域の絶対値Aの値を3以下とすること:理由TailCoeffの絶対値の大きさによって、LeftPartCoeffのLevelに使用される符号化テーブルが変化するため、本設定値によりこれを抑制する。Levelの符号化テーブルはレベル値の絶対値の大きさが036122448を閾値として変化するため、LeftPartCoeffのLevelに使用される符号化テーブルをTailCoeffの調整と無関係にするためには、TailCoeffの係数値の絶対値の大きさが全て、前記閾値のうち3以下である必要がある。GuardCoeffの値は、絶対値2以上の係数とすること理由本設定により、TrailingOnesTrailingOnesFlagRunBeforeパラメータの符号量をLeftPartCoeffとTailCoeffで独立することが出来る。絶対値0および1の場合、TrailingOnesTrailingOnesFlagRunBeforeの判定の際に、LeftPartCoeffの係数も対象とする可能性がある。そこで、GuardCoeffに絶対値2以上の係数を置くことでこれを抑制することができる。GuardIndexの値は11最低周波の係数インデックスを1とした場合であること。理由この設定値は、以下の説明する検索テーブルの生成に伴って得られるものである。詳しくは図8に示す通りであるが、以下において、概要を説明する。すなわち、上記二つの条件である、GuardCoeffが2、絶対値Aが3以下という設定の下、ブロック係数列末尾つまり右端の位置からGuardIndexの探索を始める。この場合、いかなる入力の組み合わせに対しても、1から7ビット全ての調整が可能なTailCoeffを生成できるGuardIndexが、GuardIndex11のとき初めて見つかる。後述する処理負荷軽減および高速化を目的とした、事前生成によるTailCoeff検索テーブルの使用時においては、いかなる入力の組み合わせに対しても、1から7ビット全ての調整が可能なTailCoeffの生成が必要となるため、GuardIndexの値として11は好ましいと言える。但し、例えばある入力係数列に対しては、GuardIndexが4のときに、1256ビットを調整することができ、GuardIndexが5のときに、2357ビットを調整することができるということも想定される。つまり、必要な調整ビット量に応じて、GuardIndexを切り替えて使用することも可能である。このため、GuardIndexの設定値としては、運用実装方法によって適切な値を設定することができる。また、本例のFixedTailTotalCoeffは2に設定される。なお、以下ではまず、LeftPartTotalCoeff図7参照を全て0とする。ここでは、LeftPartTotalCoeffは、検索テーブル作成のために任意に設定できることが前提である。図8のSC-2及びSC-3LeftPartTotalCoeffの値が0からLeftPartTotalCoeffがとりうる最大値GuardIndex位置に依存するまでの全てのケースにおいて、調整係数列の生成を行うため、LeftPartTotalCoeffがGuardIndexよりも小さい場合は、非ゼロ係数個数がLeftPartTotalCoeffとなるようなLeftPartCoeffを適宜に設定し、CAVLCの既定のテーブルインデックスを0とする。なお、このインデックスの最大値は、CAVLCにおいて3である。図8のSC-4及びSC-5CAVLCのテーブルインデックスが4より小さいときは、TailCoeffにBaseCoeffを設定して、可変長符号化を行う。そして、この符号化後のビット量をBaseCodeSizeとする。図8のSC-6ついで、絶対値Aとなる整数値をTailCoeffの各要素とした場合の、すべての組み合わせについて、ブロック係数列を可変長符号化する。つまり、33333から、33333までの全ての組み合わせについて可変長符号化を行い、そのときの符号量をArrangeCodeSizeとする。そして、ArrangeCodeSizeBaseCodeSizemod8の値を、IncreaseCodeSizeとする。図8のSC-7ついで、IncreaseCodeSizeとTailCoeffで構成される組を出力する。図8のSC-8TailTotalCoeffがFixedTailTotalCoeffと同じで且つ、IncreaseCodeSizeの1~7ビット全てを満たすTailCoeffが存在するか判定する。判定がYesであればステップSC-9に進む。なお、本例では、FixedTailTotalCoeffの値は2に固定される。つまり、非ゼロ係数個数が2以外の調整係数列は破棄されることになる。ここで、TailTotalCoeffをFixedTailTotalCoeffに固定するのは、以下の理由による。すなわち、可変長符号化のためのテーブルVLCテーブルは、TailCoeffによって変わる他の要因も存在する。TotalCoeffは、LeftPartTotalCoeffとGuardTotalCoeffとTailTotalCoeffとの和であり、GuardTotalCoeffは本例では1になる。よって、TailTotalCoeffを固定することにより、TotalCoeffに関してはLeftPartTotalCoeffの影響だけを考慮すれば良い。LeftPartTotalCoeffは検索テーブルの索引となる。図8のSC-9ついで、IncreaseCodeSizeとTailCoeffで構成される組調整係数列候補が、IncreaseCodeSizeの1~7ビット各々において、複数ある場合には、画質劣化への影響を考慮し以下の基準のもと、一つの調整係数列を選択する。これらの基準を採用したのは、視覚的な影響をなるべく低減させるためである。係数列レベル値の加算合計が低い。係数がより高周波成分である。図8のSC-10ついで、LeftPartTotalCoeffVLCTableIndexIncreaseCodeSizeTailCoeffからなる組を、検索テーブルに登録する。図8のSC-11ついで、VLCのTableIndexに1を加えて、ステップSC-4に戻る。図8のSC-12ステップSC-8での判断がNoであれば、いかなる入力の組み合わせに対しても、1から7ビット全ての調整が可能なTailCoeffの生成を必要とする条件を満たしていないため、検索テーブルを破棄し、GuardIndex及びFixedTailTotalCoeffのいずれかを再設定する。GuardIndexの再設定を行う場合は、本実施形態では、GuardIndexの値を一つ少なくする。この繰り返しにより、GuardIndexの適切な値を探索することができる。図8のSC-13ステップSC-4での判断がNoであれば、LeftPartTotalCoeffに1を加えて、ステップSC-2に戻る。これを繰り返すことにより、全てのLeftPartTotalCoeffについて、対応した検索テーブルを生成することができる。以上の処理により、図3に示す検索テーブルを生成することができる。第2実施形態次に、第2実施形態に係るバイトアラインメント手順を、図9をさらに参照して説明する。前記した第1実施形態では、バイトアラインメントを行うブロックつまり対象ブロックを、MB中の最終ブロックとしていた図9a参照。この場合は、対象ブロックを参照するブロックがないので、前記した係数列調整を行なっても、参照不一致による画質劣化の恐れはない。しなしながら、仮に、最終ブロック以外のブロックをバイトアラインメントの対象とした場合には、このブロックを参照するブロックがあるために、参照情報の制限ないし固定が必要となる。ただし、これらの制限及び固定は、これらのブロックの符号化モードがintra4x4である場合にのみ必要となる。以降の説明では、図9bに示すb11ブロックが係数列調整の対象であると仮定する。すると、これに隣接するb12右隣接、b15下隣接、b16斜め下隣接のブロックについては、図9bに示すような、符号化モードの固定ないし制限が必要となる。さらに、b12とb15のブロックについては、b11のTotalCoeffが固定値であると仮定して符号化を行い、符号化条件の不整合を防止している。なお、本発明は、前記した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変更を加え得るものである。例えば、前記した各構成要素は、機能ブロックとして存在していればよく、独立したハードウエアとして存在しなくても良い。また、実装方法としては、ハードウエアを用いてもコンピュータソフトウエアを用いても良い。さらに、本発明における一つの機能要素が複数の機能要素の集合によって実現されても良く、本発明における複数の機能要素が一つの機能要素により実現されても良い。また、本発明を構成する各機能要素は、離散して存在しても良い。離散して存在する場合には、例えばネットワークを介して必要なデータを受け渡すことができる。各部の内部における各機能も、同様に、離散して存在することが可能である。例えば、グリッドコンピューティングやクラウドコンピューティングを用いて、本実施形態における各機能要素あるいはその一部分を実現することも可能である。"