JP5685683B2 - バイトアラインメント装置及びバイトアラインメント方法 - Google Patents

Description

本発明は、ブロック係数列を可変長符号化して得られるビットストリームに対してバイトアラインメントを行うための技術に関するものである。

近年、様々な環境において、高品質な映像情報の編集処理が行われるようになった。映像情報の編集処理とは、例えば、伝送路中の映像情報の認識処理、単一映像の編集処理、複数の映像の合成処理などである。このような映像情報の編集処理は、データセンターのサーバや個人のパーソナルコンピュータだけでなく、個人が所有する携帯端末や、ネットワーク家電、自動車内オーディオビジュアル装置、ネットワーク内のルータ等で行われることが想定される。ここで、映像情報の編集処理は、通常、MB群（すなわち、MBで構成されるMBライン、単独のMB、任意のMBのグループなど）を単位として行われる。したがって、映像情報の編集処理は、MB群に対応する映像ビットストリームを単位として行われる。

一方、映像ビットストリームは、H.264の場合、量子化されたブロック係数列を可変長符号化することにより生成される。すなわち、MB群に対応する映像ビットストリームは、MB群に属するブロック係数列の可変長符号化により、ビット単位での符号化情報として生成される。このように生成されたビットストリームは、符号化の対象とした映像信号情報（係数列情報）がバイト区切りの情報であったとしても、必ずしもバイト区切りにはならないことが知られている。

映像ビットストリームがバイト区切りでない場合は、映像ビットストリームのコピーやシークという、データ処理作業において、ビットシフト演算処理が必要となり、機器への負担が増えるという問題がある。

下記特許文献１は、H.264/AVCで用いられるスライスヘッダを用いて、フレーム単位のビットストリームをバイトアラインメントする方法について述べている。しかしながら、特許文献１の技術では、フレームのビットストリーム全体を対象としたスライスヘッダでのビット量調整を前提とするため、任意のMB群におけるバイトアラインメントを行うことができず、使用上の柔軟性に欠ける。また、一つのフレームに挿入可能なスライスヘッダ数には上限があるため、任意の箇所のMB群においてバイトアラインメントすることは難しいという問題もある。

[1]国際公開番号：ＷＯ２００９／０９３６４７

本発明は、前記の状況に鑑みてなされたものである。本発明の目的の一つは、ビットストリーム抽出処理におけるシフト演算処理を回避し、処理負荷を抑制することが可能な技術を提案することである。本発明のより具体的な目的は、MB中のブロックの係数列を調整することにより、MB群単位で符号化されるビットストリームのビット量を調整し、これによって、任意のMB群から生成されるビットストリームをバイトアラインメントする技術を提供することである。

前記した課題を解決する手段は、以下の項目のように記載できる。

（項目１）
ブロック係数列を可変長符号化して得られるビットストリームに対してバイトアラインメントを行うための装置であって、
基準係数列挿入部と、所望増加ビット量算出部と、調整係数列検索部と、調整係数列挿入部とを備えており、
前記基準係数列挿入部は、量子化されたブロック係数列のうちの高周波成分である調整係数列を、既定の基準係数列に置換する構成となっており、
前記所望増加ビット量算出部は、前記調整係数列が前記基準係数列に置換された前記ブロック係数列を可変長符号化して得られるビットストリームの符号量に基づいて、バイトアラインメントのために増加させるべきビット量を算出する構成となっており、
前記調整係数列検索部は、前記増加させるべきビット量に基づいて、前記基準係数列に置換されるべき適切な調整係数列を検索する構成となっており、
前記調整係数列挿入部は、検索された前記調整係数列を前記基準係数列に対応する高周波成分に挿入する構成となっている
バイトアラインメント装置。

（項目２）
さらにガード係数挿入部を備えており、
前記ガード係数挿入部は、前記ブロック係数列における前記高周波成分係数列よりも１次数だけ低周波側に位置する係数を、ガード係数に置換する構成となっており、
前記ガード係数は、前記ガード係数よりも低周波側の係数の値による、前記ビットストリームの符号量への影響を抑制するものである
項目１に記載のバイトアラインメント装置。

（項目３）
前記調整係数列検索部は、前記増加させるべきビット量に加えて、可変長符号化後のビットストリームの符号量に影響する要因に基づいて、前記適切な調整係数列を検索する構成となっている
項目１又は２に記載のバイトアラインメント装置。

（項目４）
さらに検索DBを備えており、
前記検索DBは、前記増加させるべきビット量、及び／又は、可変長符号化後のビットストリームの符号量に影響する要因に基づいて、前記適切な調整係数列を検索できる構成となっている
項目１〜３のいずれか１項に記載のバイトアラインメント装置。

（項目５）
項目１〜４のいずれか１項に記載のバイトアラインメント装置と、可変長符号化部とを備えており、
前記可変長符号化部は、前記バイトアラインメント装置によるバイトアラインメント処理の対象となる対象ブロックに隣接する隣接ブロックの係数列を可変長符号化する際には、
前記対象ブロックの符号化における予測モードの制限、及び／又は、符号化に用いる係数値の固定を行う構成となっている
ビットストリーム生成装置。

（項目６）
ブロック係数列を可変長符号化して得られるビットストリームに対してバイトアラインメントを行うために用いるビットストリーム生成方法であって、
量子化されたブロック係数列のうちの高周波成分である調整係数列を、既定の基準係数列に置換するステップと、
前記調整係数列が前記基準係数列に置換された前記ブロック係数列を可変長符号化して得られるビットストリームの符号量に基づいて、バイトアラインメントのために増加させるべきビット量を算出するステップと、
前記増加させるべきビット量に基づいて、前記基準係数列に置換されるべき適切な調整係数列を検索するステップと、
検索された前記調整係数列を前記基準係数列に対応する高周波成分に挿入するステップと
を備える、ビットストリーム生成方法。

（項目７）
項目６に記載の方法をコンピュータに実行させるためのコンピュータプログラム。

（項目８）
ブロック係数列によって構成されるデータ構造であって、
前記ブロック係数列における高周波成分係数は、可変長符号化後のビットストリームにおけるバイトアラインメントを行うための調整係数列とされており、
前記調整係数列よりも１次数だけ低周波側の係数には、ガード係数が挿入されており、
前記ガード係数は、このガード係数よりも低周波側にある低周波成分係数の値による、可変長符号化条件への影響を抑制するものとなっている
データ構造。

本発明によれば、任意のMB群から生成されるビットストリームをバイトアラインメントする技術を提供することができる。

本発明の第１実施形態におけるバイトアラインメント処理部を用いた符号化装置の概略的な構成を説明するためのブロック図である。 第１実施形態のバイトアラインメント処理部の概略的な構成を説明するためのブロック図である。 検索テーブルの構成を説明するための説明図である。 第１実施形態の符号化処理の全体的手順を説明するためのフローチャートである。 第１実施形態のバイトアラインメント処理の手順を説明するためのフローチャートである。 ブロック係数列について説明するための説明図である。 調整係数列の挿入について説明するための説明図である。 検索テーブルの生成手順を説明するためのフローチャートである。 第１実施形態のバイトアラインメント処理手順における符号化モードの制約ないし固定を説明するためのフローチャートである。図（ａ）は第１実施形態での調整対象ブロックを示す。図（ｂ）は第２実施形態での調整対象ブロックと、これに関連する符号化モードの制限ないし固定を示す。

以下、添付図面を参照しながら、本発明の第１実施形態に係る符号化システムについて説明する。

（本実施形態の構成）
まず、本実施形態の符号化システムが使用される符号化装置全体の概略的構成を、図１を参照しながら説明する。

このシステムは、整数精度変換部１と、量子化部２と、バイトアラインメント処理部３と、可変長符号化部４とから構成されている。以下、各要素について説明する。

（整数精度変換部）
整数精度変換部１は、ブロック係数列（フレーム内符号化の場合）またはブロック係数列の残差信号（フレーム間符号化の場合）が入力されるものである。なお、この明細書では、ブロック係数列とその残差信号との両者を含めてブロック係数列と総称する。整数精度変換部１は、実数精度の入力値を整数精度に変換するものであり、これは、従来のH.264での実装と同様に構成できるので、これについての詳しい説明は省略する。

（量子化部）
量子化部２は、整数精度変換されたブロック係数列を量子化する機能要素である。この量子化部２も、従来のH.264での実装と同様に構成できるので、これについての詳しい説明は省略する。

（バイトアラインメント処理部）
バイトアラインメント処理部３は、本発明のバイトアラインメント装置の一実施形態に対応する機能要素である。

本実施形態のバイトアラインメント処理部３は、図２に示すように、基準係数列挿入部３１と、所望増加ビット量算出部３２と、調整係数列検索部３３と、調整係数列挿入部３４と、ガード係数挿入部３５と、検索DB３６とを備えている。

基準係数列挿入部３１は、量子化されたブロック係数列のうちの高周波成分である調整用の係数列（後述のTailCoeff）を、既定の基準係数列に置換する構成となっている。

所望増加ビット量算出部３２は、調整用の係数列が基準係数列に置換された状態のブロック係数列を可変長符号化して得られるビットストリームの符号量に基づいて、バイトアラインメントのために増加させるべきビット量を算出する構成となっている。

調整係数列検索部３３は、増加させるべきビット量に基づいて、基準係数列（高周波成分係数列）に置換されるべき適切な調整係数列を検索する構成となっている。さらに、本実施形態の調整係数列検索部３３は、増加させるべきビット量に加えて、可変長符号化後のビットストリームの符号量に影響する要因（後述）に基づいて、適切な調整係数列を検索する構成となっている。

調整係数列挿入部３４は、検索された調整係数列を、基準係数列に対応する高周波成分に挿入する構成となっている。

ガード係数挿入部３５は、ブロック係数列における高周波成分係数列よりも１次数だけ低周波側に位置する係数を、ガード係数（以下GuardCoeffということがある）に置換する構成となっている。GuardCoeffには固定係数値（本例では絶対値2以上の係数）を挿入する。ここで、ガード係数とは、ガード係数よりも低周波側の係数の値による、ビットストリームの符号量への影響を抑制するものである（後述）。ガード係数の位置は、ガード係数の挿入時には既に分かっているものとする。ガード係数の位置の探索については後述する。

検索DB３６は、増加させるべきビット量、及び／又は、可変長符号化後のビットストリームの符号量に影響する要因に基づいて、適切な調整係数列を検索できる構成となっている。本実施形態の検索DB３６は、具体的にはテーブル構造となっている（図３参照）が、DBの構造には特に制約はない。本明細書では、検索DBを検索テーブルと称することがある。本実施形態では、ビットストリーム符号量に影響するパラメータの一部を検索テーブルの検索キーとし、残りのパラメータを固定値としている。

本実施形態のバイトアラインメント処理部３の詳しい構成については、本実施形態の動作として後述する。

（可変長符号化部）
可変長符号化部４は、各ブロックの係数列に対して、可変長符号化を行う機能要素である。

本実施形態の可変長符号化部４は、「バイトアラインメント装置によるバイトアラインメント処理の対象となる対象ブロックに隣接する隣接ブロックの係数列を可変長符号化する際には、対象ブロックの符号化における予測モードの制限、及び／又は、符号化に用いる係数値の固定を行う構成」となっている。この点を除き、本実施形態の可変長符号化部４は、例えばH.264における、CAVLC（Context Adaptive Variable Length Coding）を用いた可変長符号化部と同様に構成することができる。

本実施形態の可変長符号化部４の詳しい構成についても、本実施形態の動作として後述する。

（本実施形態におけるビットストリーム生成手順）
以下、本実施形態におけるビットストリーム生成手順を、図４をさらに参照しながら説明する。なお、以下の例では、バイトアラインメントの対象となるMB群を、MBが一列に配置されて構成されたMBラインとする。また、本例において係数調整の対象とするブロックは、MBラインにおける最終MBの最終ブロックとする（図９（ｂ）参照）。

（図４のステップＳＡ−１〜３）
まず、符号化前の映像信号の入力を受け付け、その係数列を整数精度に変換する。さらに、整数精度に変換された係数列を量子化する。ここまでの処理は通常のH.264と同様でよいので、詳しい説明は省略する。

（図４のステップＳＡ−４〜５）
ついで、本実施形態のバイトアラインメント処理部３を用いたバイトアラインメント処理の手順を、図５をさらに参照しながら説明する。

（図５のステップＳＢ−０）
可変長符号化部４は、「係数列の調整を行うブロック（対象ブロック）を除く各ブロック」について、可変長符号化を行う。その結果得られるビットストリームの合計ビット数により、対象ブロックを除くMBラインのビットストリームのビット量を得ることができる。このビット量と、対象ブロック係数列の符号化によるビットストリームの符号量とを加算することにより、MBライン全体のビットストリームの符号量を取得することができる。この符号量が、バイトアラインメント処理の基準となる。

（図５のステップＳＢ−１）
まず、バイトアラインメント処理部３は、量子化部２から、対象ブロックについての量子化処理が行われたブロック係数列を取得する。ここで、ブロック係数列の例を、図６を参照しながら補足して説明する。H.264では、１枚の画像を構成するフレーム１００が、複数のMBライン１０１〜１０ｎで構成されており、各MBラインは、複数のMBで構成されている（図６（ａ）参照）。そして、各MBは、複数のブロックにより構成されている（図６（ｂ）参照）。H.264では、各ブロックは、４×４画素形成されている。図６では、各ブロックに１〜１６のインデックスを付している。そして、量子化により、各インデックスに対応する量子化された係数値を特定することができる。このような各インデックスの係数値を、ジグザグスキャン（図６（ｃ）参照）することによって、ブロックにおける係数列を生成することができる（図６（ｄ）参照）。図６（ｄ）に示す数字は、係数のインデックスを示しており、係数値を示すものではない。図６（ｄ）において、１１番の係数インデックスが、後述するガード係数となっており、それよりも高周波側（図６において右側）の係数列が、調整のために置換される係数列（以下TailCoeffということがある）であり、それよりも低周波側（図６において左側）の係数列が、信号の内容を示す係数列（以下LeftPartCoeffということがある）である。なお、本例において係数列を調整する対象となるブロックのインデックス番号は１６である（図６（ｂ）参照）。

（図５のステップＳＢ−２）
ついで、基準係数列挿入部３１は、前記したTailCoeffを、予め準備しておいた基準係数列（以下BaseCoeffということがある）に置換する。本実施形態では、基準係数列として、（0,0,0,0,0）という値が用いられている。これは、CAVLCにおいては、（0,0,0,0,0）という係数列を用いたときに、符号化後のビット量を最小とすることができるためである。

（図５のステップＳＢ−３）
ついで、当該ブロック係数列の符号化が、初期のTailCoeffを置換した後の最初のものであるかどうかを確認する。すなわち、当該ブロック係数列の可変長符号化は、バイトアラインメントのために２度行われる。１度目は、TailCoeffを基準係数列で置き換えた係数列を可変長符号化し、２度目は、TailCoeffを調整係数列で置き換えた係数列を可変長符号化する。ここでの判定がYesであればステップＳＢ−４に進む。

（図５のステップＳＢ−４及びＳＢ−５）
ついで、TailCoeffをBaseCoeffに置換し、置換後の係数列を用いて、可変長符号化部４により可変長符号化を行う。

（図５のステップＳＢ−６及びＳＢ−７）
つぎに、所望増加ビット量算出部３２は、可変長符号化により得られた対象ブロックの符号量と、ステップＳＢ−０で取得していた符号量とを合計して得られた符号量（つまりMBライン全体の符号量）をＸとし、８を法とするＸの剰余量、つまりX mod 8を計算する。そして、この剰余量と８との差を算出する。その結果が、ビットストリームのビット数についての所望増加量となる。

（図５のステップＳＢ−８）
ついで、得られた所望増加量と、他の係数特性とを用いて、検索テーブル３６から、TailCoeffに挿入されるべき調整係数列を検索して取得する。すなわち、検索テーブル３６においては、増加ビット量に影響する各要因（本例では所望増加ビット量、LeftPartTotalCoeff、NeighborTotalCoeff）に基づいて、適切な調整係数列を検索できるようになっている。この検索についてはさらに後述する。

なお、ガード係数の位置（つまりGuardIndex）は、図８に示す検索テーブルの生成時に取得されるが、これについても後述する。

ここで、係数列の説明に用いられる用語について、下記表１に示す。

また、可変長符号化における符号化テーブルの選択要因となるパラメータと、本実施形態における措置とを下記表２に示す。

（図５のステップＳＢ−３，ＳＢ−９，ＳＢ−５）
ついで、手順は再びステップＳＢ−３に戻り、その後ステップＳＢ−９に進む。さらに、調整係数列挿入部３４は、検索テーブルから得られた調整係数列を、TailCoeffに挿入する。調整係数列が挿入されたブロック係数列に対して可変長符号化を行い、得られたビットストリームを出力する。このようにして得られたビットストリームを用いて、MBラインのビットストリームを構成することにより、バイトアラインメントを実行することができる。

本実施形態では、前記のようにして、バイトアラインメントを、簡便な手段で、実現することができる。さらに、任意のMBに属するブロックを対象として、前記したバイトアラインメントの処理を実行することができる。

また、本実施形態では、ブロック係数列にガード係数を挿入したので、TailCoeffを調整係数列に置換しても、符号化条件への影響を抑制できるという利点もある。ただし、CAVLCを前提にすると、ガード係数の値は２又は３となる。この点は後述する。

ここで、ガード係数挿入の利点について補足説明する。

実際の可変長符号化の際には、TotalCoeffとTrailingOnesの組合せであるCoeffTokenパラメータも符号化されるので、その符号量が全体ビットストリームの符号量に影響する。ガード係数挿入により、TailCoeffの変更によるCoeffTokenパラメータの符号量への影響を抑制することができる。但し、CoeffTokenの符号化テーブルは、隣接ブロックの非ゼロ係数個数の平均値（NeighborTotalCoeff）により決定するため、係数列全体が同一でも、NeighborTotalCoeffに応じてCoeffTokenの符号量は異なる。よって、あるLeftPartCoeffに対してあるビット量増加を実現するTailCoeffが存在する場合でも、NeighborTotalCoeffが異なると、同一のTailCoeffであっても、所望のビット量増加を実現することは出来ない。以上から、NeighborTotalCoeffが同じ（CoeffTokenを符号化するテーブルが同じ）であるならば、上記パラメータ設定により、LeftPartCoeffとTailCoeffを独立に考えることが可能となり、TailCoeffの係数列調整によって、それ以外の係数列（LeftPartCoeff，GuardCoeff）の符号化に影響を与えることなく1から7ビットの増加量を制御することが可能となる。

（図４のステップＳＡ−６）
ついで、バイトアラインメント処理が行われたブロック係数列の可変長符号化により生成されたビットストリームを出力する。これらの処理自体は従来と同様でよいので、詳しい説明は省略する。

（図４のステップＳＡ−７：検索テーブル生成手順）
次に、図８を参照して、調整係数列を検索するための検索テーブルの生成手順について説明する。なお、検索テーブルの生成は、前記した調整係数列の検索よりも前に行われる。

（図８のＳＣ−１）
まず、前提として、GuardCoeffの値は２又は３に設定し、以下で使用する絶対値Ａは３以下とする。また、ガード係数の位置（GuardIndex）は、この段階では任意の値であるが、この例では高周波側の値（本例では１６）から順次検証していき、１〜７ビットのビット量増減値に対応できるGuardIndex（本実施形態では１１）をみつける。以下、これらの理由を補足する。

・TailCoeffの数値定義域の絶対値Aの値を3以下とすること：
（理由）TailCoeffの絶対値の大きさによって、LeftPartCoeffのLevelに使用される符号化テーブルが変化するため、本設定値によりこれを抑制する。Levelの符号化テーブルはレベル値の絶対値の大きさが0,3,6,12,24,48を閾値として変化するため、LeftPartCoeffのLevelに使用される符号化テーブルをTailCoeffの調整と無関係にするためには、TailCoeffの係数値の絶対値の大きさが全て、前記閾値のうち3以下である必要がある。

・GuardCoeffの値は、絶対値2以上の係数とすること
（理由）本設定により、TrailingOnes, TrailingOnesFlag, RunBeforeパラメータの符号量をLeftPartCoeffとTailCoeffで独立することが出来る。絶対値０および１の場合、TrailingOnes, TrailingOnesFlag, RunBeforeの判定の際に、LeftPartCoeffの係数も対象とする可能性がある。そこで、GuardCoeffに絶対値２以上の係数を置くことでこれを抑制することができる。

・GuardIndexの値は11（最低 周波の係数インデックスを１とした場合）であること。
（理由）この設定値は、以下の説明する検索テーブルの生成に伴って得られるものである。詳しくは図８に示す通りであるが、以下において、概要を説明する。すなわち、上記二つの条件である、GuardCoeffが2、絶対値Aが3以下という設定の下、ブロック係数列末尾（つまり右端）の位置からGuardIndexの探索を始める。この場合、いかなる入力の組み合わせに対しても、1から7ビット全ての調整が可能なTailCoeffを生成できるGuardIndexが、GuardIndex=11のとき初めて見つかる。後述する処理負荷軽減および高速化を目的とした、事前生成によるTailCoeff検索テーブルの使用時においては、いかなる入力の組み合わせに対しても、1から7ビット全ての調整が可能なTailCoeffの生成が必要となるため、 GuardIndexの値として11は好ましいと言える。但し、例えばある入力係数列に対しては、GuardIndex が4のときに、1, 2, 5, 6ビットを調整することができ、GuardIndex が5のときに、2, 3, 5, 7ビットを調整することができるということも想定される。つまり、必要な調整ビット量に応じて、GuardIndexを切り替えて使用することも可能である。このため、GuardIndexの設定値としては、運用（実装）方法によって適切な値を設定することができる。

また、本例のFixedTailTotalCoeffは２に設定される。

なお、以下ではまず、LeftPartTotalCoeff（図７参照）を全て０とする。ここでは、LeftPartTotalCoeffは、検索テーブル作成のために任意に設定できることが前提である。

（図８のＳＣ−２及びＳＣ−３）
LeftPartTotalCoeffの値が「0からLeftPartTotalCoeff がとりうる最大値（GuardIndex位置に依存する）まで」の全てのケースにおいて、調整係数列の生成を行うため、LeftPartTotalCoeffがGuardIndexよりも小さい場合は、非ゼロ係数個数がLeftPartTotalCoeffとなるようなLeftPartCoeffを適宜に設定し、CAVLCの既定のテーブルインデックスを０とする。なお、このインデックスの最大値は、CAVLCにおいて３である。

（図８のＳＣ−４及びＳＣ−５）
CAVLCのテーブルインデックスが４より小さいときは、TailCoeffにBaseCoeffを設定して、可変長符号化を行う。そして、この符号化後のビット量をBaseCodeSizeとする。

（図８のＳＣ−６）
ついで、絶対値Ａとなる整数値をTailCoeffの各要素とした場合の、すべての組み合わせについて、ブロック係数列を可変長符号化する。つまり、（-3,-3,-3,-3,-3）から、（3,3,3,3,3）までの全ての組み合わせについて可変長符号化を行い、そのときの符号量をArrangeCodeSizeとする。そして、（ArrangeCodeSize - BaseCodeSize） mod 8の値を、IncreaseCodeSizeとする。

（図８のＳＣ−７）
ついで、IncreaseCodeSizeとTailCoeffで構成される組を出力する。

（図８のＳＣ−８）
TailTotalCoeffがFixedTailTotalCoeffと同じで且つ、IncreaseCodeSizeの1〜７ビット全てを満たすTailCoeffが存在するか判定する。判定がYesであればステップＳＣ−９に進む。なお、本例では、FixedTailTotalCoeffの値は２に固定される。つまり、非ゼロ係数個数が２以外の調整係数列は破棄されることになる。ここで、TailTotalCoeffをFixedTailTotalCoeffに固定するのは、以下の理由による。すなわち、可変長符号化のためのテーブル（VLCテーブル）は、TailCoeffによって変わる（他の要因も存在する）。TotalCoeffは、LeftPartTotalCoeffとGuardTotalCoeffとTailTotalCoeffとの和であり、GuardTotalCoeffは本例では１になる。よって、TailTotalCoeffを固定することにより、TotalCoeffに関してはLeftPartTotalCoeffの影響だけを考慮すれば良い。LeftPartTotalCoeffは検索テーブルの索引となる。

（図８のＳＣ−９）
ついで、IncreaseCodeSizeとTailCoeffで構成される組（調整係数列候補）が、IncreaseCodeSizeの1〜７ビット各々において、複数ある場合には、画質劣化への影響を考慮し以下の基準のもと、一つの調整係数列を選択する。これらの基準を採用したのは、視覚的な影響をなるべく低減させるためである。

・係数列レベル値の加算合計が低い。
・係数がより高周波成分である。

（図８のＳＣ−１０）
ついで、LeftPartTotalCoeff, VLCTableIndex, IncreaseCodeSize, TailCoeffからなる組を、検索テーブルに登録する。

（図８のＳＣ−１１）
ついで、VLCのTableIndexに１を加えて、ステップＳＣ−４に戻る。

（図８のＳＣ−１２）
ステップＳＣ−８での判断がNoであれば、いかなる入力の組み合わせに対しても、1から7ビット全ての調整が可能なTailCoeffの生成を必要とする条件を満たしていないため、検索テーブルを破棄し、GuardIndex及びFixedTailTotalCoeffのいずれかを再設定する。GuardIndexの再設定を行う場合は、本実施形態では、GuardIndexの値を一つ少なくする。この繰り返しにより、GuardIndexの適切な値を探索することができる。

（図８のＳＣ−１３）
ステップＳＣ−４での判断がNoであれば、LeftPartTotalCoeffに１を加えて、ステップＳＣ−２に戻る。これを繰り返すことにより、全てのLeftPartTotalCoeffについて、対応した検索テーブルを生成することができる。

以上の処理により、図３に示す検索テーブルを生成することができる。

（第２実施形態）
次に、第２実施形態に係るバイトアラインメント手順を、図９をさらに参照して説明する。

前記した第１実施形態では、バイトアラインメントを行うブロック（つまり対象ブロック）を、MB中の最終ブロックとしていた（図９（ａ）参照）。この場合は、対象ブロックを参照するブロックがないので、前記した係数列調整を行なっても、参照不一致による画質劣化の恐れはない。

しなしながら、仮に、最終ブロック以外のブロックをバイトアラインメントの対象とした場合には、このブロックを参照するブロックがあるために、参照情報の制限ないし固定が必要となる。ただし、これらの制限及び固定は、これらのブロックの符号化モードがintra 4x4である場合にのみ必要となる。

以降の説明では、図９（ｂ）に示すｂ１１ブロックが係数列調整の対象であると仮定する。すると、これに隣接するｂ１２（右隣接）、ｂ１５（下隣接）、ｂ１６（斜め下隣接）のブロックについては、図９（ｂ）に示すような、符号化モードの固定ないし制限が必要となる。さらに、ｂ１２とｂ１５のブロックについては、ｂ１１のTotalCoeffが固定値であると仮定して符号化を行い、符号化条件の不整合を防止している。

なお、本発明は、前記した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変更を加え得るものである。

例えば、前記した各構成要素は、機能ブロックとして存在していればよく、独立したハードウエアとして存在しなくても良い。また、実装方法としては、ハードウエアを用いてもコンピュータソフトウエアを用いても良い。さらに、本発明における一つの機能要素が複数の機能要素の集合によって実現されても良く、本発明における複数の機能要素が一つの機能要素により実現されても良い。

また、本発明を構成する各機能要素は、離散して存在しても良い。離散して存在する場合には、例えばネットワークを介して必要なデータを受け渡すことができる。各部の内部における各機能も、同様に、離散して存在することが可能である。例えば、グリッドコンピューティングやクラウドコンピューティングを用いて、本実施形態における各機能要素あるいはその一部分を実現することも可能である。

１ 整数精度変換部
２ 量子化部
３ バイトアラインメント処理部
３１ 基準係数列挿入部
３２ 所望増加ビット量算出部
３３ 調整係数列検索部
３４ 調整係数列挿入部
３５ ガード係数挿入部
３６ 検索テーブル（検索DB）
４ 可変長符号化部

Claims (7)

1. ブロック係数列を可変長符号化して得られるビットストリームに対してバイトアラインメントを行うための装置であって、
   基準係数列挿入部と、所望増加ビット量算出部と、調整係数列検索部と、調整係数列挿入部とを備えており、
   前記基準係数列挿入部は、量子化されたブロック係数列のうちの高周波成分である調整係数列を、既定の基準係数列に置換する構成となっており、
   前記所望増加ビット量算出部は、前記調整係数列が前記基準係数列に置換された前記ブロック係数列を可変長符号化して得られるビットストリームの符号量に基づいて、バイトアラインメントのために増加させるべきビット量を算出する構成となっており、
   前記調整係数列検索部は、前記増加させるべきビット量に基づいて、前記基準係数列に置換されるべき適切な調整係数列を検索する構成となっており、
   前記調整係数列挿入部は、検索された前記調整係数列を前記基準係数列に対応する高周波成分に挿入する構成となっている
   バイトアラインメント装置。
2. さらにガード係数挿入部を備えており、
   前記ガード係数挿入部は、前記ブロック係数列における前記高周波成分係数列よりも１次数だけ低周波側に位置する係数を、ガード係数に置換する構成となっており、
   前記ガード係数は、前記ガード係数よりも低周波側の係数の値による、前記ビットストリームの符号量への影響を抑制するものである
   請求項１に記載のバイトアラインメント装置。
3. 前記調整係数列検索部は、前記増加させるべきビット量に加えて、可変長符号化後のビットストリームの符号量に影響する要因に基づいて、前記適切な調整係数列を検索する構成となっている
   請求項１又は２に記載のバイトアラインメント装置。
4. さらに検索DBを備えており、
   前記検索DBは、前記増加させるべきビット量、及び／又は、可変長符号化後のビットストリームの符号量に影響する要因に基づいて、前記適切な調整係数列を検索できる構成となっている
   請求項１〜３のいずれか１項に記載のバイトアラインメント装置。
5. 請求項１〜４のいずれか１項に記載のバイトアラインメント装置と、可変長符号化部とを備えており、
   前記可変長符号化部は、前記バイトアラインメント装置によるバイトアラインメント処理の対象となる対象ブロックに隣接する隣接ブロックの係数列を可変長符号化する際には、
   前記対象ブロックの符号化における予測モードの制限、及び／又は、符号化に用いる係数値の固定を行う構成となっている
   ビットストリーム生成装置。
6. ブロック係数列を可変長符号化して得られるビットストリームに対してバイトアラインメントを行うために用いるビットストリーム生成方法であって、
   量子化されたブロック係数列のうちの高周波成分である調整係数列を、既定の基準係数列に置換するステップと、
   前記調整係数列が前記基準係数列に置換された前記ブロック係数列を可変長符号化して得られるビットストリームの符号量に基づいて、バイトアラインメントのために増加させるべきビット量を算出するステップと、
   前記増加させるべきビット量に基づいて、前記基準係数列に置換されるべき適切な調整係数列を検索するステップと、
   検索された前記調整係数列を前記基準係数列に対応する高周波成分に挿入するステップと
   を備える、ビットストリーム生成方法。
7. 請求項６に記載の方法をコンピュータに実行させるためのコンピュータプログラム。