(57)【要約】  可変長コードを使用するスケーラブルビデオコーディングにおいて空間的及びクオリティエンハンスメント情報をコード化する方法が提供される。従来のシステムは、非スケーラブルビデオコーディングでしか可変長コードを使用できない。本発明では、各情報ブロックに対するコード化ブロックパターン、有効性パス及び洗練パスを、全て、異なる形式の可変長コードによりコード化することができる。本発明は、実際のシンボル確率に動的に適応される可変長さのエンコーダー／デコーダーも提供する。本発明のエンコーダー／デコーダは、各記号がコード化される回数をカウントする。これらカウントに基づいて、エンコーダー／デコーダは、コードワードを形成するときに、どれほど多くのシンボルをグループ編成すべきかを選択する。エンコーダは、これらのカウントを使用して、使用すべき特定のコードワードを選択する。
2009510962.tif 000002
【特許請求の範囲】
【請求項１】
ビットストリームからの圧縮データをデコードする方法であって、
前記ビットストリームから少なくとも１つのシンボルを含むシンボルベクトルを表わすコードワードをフェッチするステップと、
可変長コードを使用して前記コードワードをデコードするステップであって、該コードワードのデコードにより少なくとも１つのシンボルを含むシンボルベクトルを生じさせるステップと、
前記シンボルベクトルからの前記少なくとも１つのシンボルをバッファに追加するステップと、
以前にデコードされたシンボルの確率分布に少なくとも部分的に基づいて前記可変長コードを更新するステップと、
前記バッファから次のシンボルを返送するステップと、
を含むことを特徴とする方法。
【請求項２】
前記可変長コードを更新する前に、前記バッファに追加されたシンボルを反映するようにシンボルカウンタを更新するステップと、
以前にデコードされたシンボルの確率分布を決定する際に前記シンボルカウンタを使用するステップと、
を更に含む、請求項１に記載の方法。
【請求項３】
前記ビットストリームから前記コードワードをフェッチする前に、前記バッファが空であるか否かを決定するステップと、
前記バッファが空である場合に、前記コードワードをフェッチすることに進むステップと、
前記バッファが空でない場合には、前記バッファから前記次のシンボルを直ちに返送し、前記コードワードをデコードせず、シンボルを追加し、又は現在の可変長コードを更新するステップと、
を更に含む、請求項１に記載の方法。
【請求項４】
前記コードワードをデコードした後に、第１の値を有する要求されたシンボルの確率が、第２の特定の値を有するシンボルの確率より大きいか否かを決定するステップと、
前記第１の値を有するシンボルの確率が、前記第２の値を有するシンボルの確率より大きい場合には、前記シンボルベクトルを反転させるステップと、
を更に含む、請求項１に記載の方法。
【請求項５】
前記ビットストリームから前記コードワードをフェッチする前に、前記可変長コードに対応するシンボルベクトルにおけるシンボルの数を決定するステップと、
前記シンボルの数が、処理されるべく残っているシンボルの数より大きいか否かを決定するステップと、
前記シンボルの数が、処理されるべく残っているシンボルの数より大きい場合に、シンボルベクトルにおけるシンボルの数が、処理されるべく残っているシンボルの数より大きくないところの新たな可変長コードを与えるステップと、
を更に含む、請求項１に記載の方法。
【請求項６】
前記更新された可変長コードが、以前にデコードされたシンボルの確率分布に対して利用可能な可変長コードからシンボル当たり最小のビットを所有するように選択される、請求項１に記載の方法。
【請求項７】
前記可変長コードが周期的に更新されるだけである、請求項１に記載の方法。
【請求項８】
前記周期が、前記可変長コードの１又はそれ以上の以前の更新において選択された可変長コードに少なくとも部分的に基づいて決定される、請求項７に記載の方法。
【請求項９】
前記可変長コードの更新が、ビットストリームにおける明確な信号によりトリガされるか、又は、ソースデータの推定特性によりトリガされる、請求項１に記載の方法。
【請求項１０】
前記可変長コードは、デコードされるシンボルの数が所定閾値に到達するまで更新されない、請求項１に記載の方法。
【請求項１１】
前記シンボルカウンタは、周期的に、又は、１若しくはそれ以上のシンボルカウンタが所定閾値に到達するときに、倍率ファクタによりスケーリングされる、請求項２に記載の方法。
【請求項１２】
ビットストリームからの圧縮データをデコードするためのコンピュータプログラム製品であって、
前記ビットストリームから少なくとも１つのシンボルを含むシンボルベクトルを表わすコードワードをフェッチするコンピュータコードと、
可変長コードを使用してコードワードをデコードするためのコンピュータコードであって、該コードワードのデコードにより少なくとも１つのシンボルを含むシンボルベクトルを生じさせるコンピュータコードと、
前記シンボルベクトルからの前記少なくとも１つのシンボルをバッファに追加するコンピュータコードと、
以前にデコードされたシンボルの確率分布に少なくとも部分的に基づいて前記可変長コードを更新するコンピュータコードと、
前記バッファから次のシンボルを返送するコンピュータコードと、
を具備することを特徴とするコンピュータプログラム製品。
【請求項１３】
前記可変長コードを更新する前に、前記バッファに追加されたシンボルを反映するようにシンボルカウンタを更新するコンピュータコードと、
前記シンボルカウンタを使用して以前にデコードされたシンボルの確率分布を決定する際に前記シンボルカウンタを使用するコンピュータコードと、
を更に具備する、請求項１２に記載のコンピュータプログラム製品。
【請求項１４】
前記ビットストリームから前記コードワードをフェッチする前に、前記バッファが空であるか否かを決定するコンピュータコードと、
前記バッファが空である場合に、前記コードワードをフェッチすることに進むコンピュータコードと、
前記バッファが空でない場合に、前記バッファから次のシンボルを直ちに返送し、前記コードワードをデコードせず、シンボルを追加し、又は、現在の可変長コードを更新するコンピュータコードと、
を更に具備する、請求項１２に記載のコンピュータプログラム製品。
【請求項１５】
前記コードワードをデコードした後に、第１の値を有する要求されたシンボルの確率が、第２の特定の値を有するシンボルの確率より大きいか否かを決定するコンピュータコードと、
前記第１の値を有するシンボルの確率が、前記第２の値を有するシンボルの確率より大きい場合に、シンボルベクトルを反転させるコンピュータコードと、
を更に具備する、請求項１２に記載のコンピュータプログラム製品。
【請求項１６】
前記ビットストリームから前記コードワードをフェッチする前に、前記可変長コードに対応するシンボルベクトルにおけるシンボルの数を決定するコンピュータコードと、
前記シンボルの数が、処理されるべく残っているシンボルの数より大きいか否かを決定するコンピュータコードと、
前記シンボルの数が、処理されるべく残っているシンボルの数より大きい場合に、シンボルベクトルにおけるシンボルの数が、処理されるべく残っているシンボルの数より大きくないところの新たな可変長コードを与えるコンピュータコードと、
を更に具備する、請求項１２に記載のコンピュータプログラム製品。
【請求項１７】
前記更新された可変長コードが、以前にデコードされたシンボルの確率分布に対して利用可能な可変長コードからシンボル当たり最小のビットを有するように選択される、請求項１２に記載のコンピュータプログラム製品。
【請求項１８】
前記可変長コードが周期的に更新される、請求項１２に記載のコンピュータプログラム製品。
【請求項１９】
前記周期は、可変長コードの１又はそれ以上の以前の更新において選択された可変長コードに少なくとも部分的に基づいて決定される、請求項１８に記載のコンピュータプログラム製品。
【請求項２０】
前記可変長コードは、デコードされるシンボルの数が所定閾値に到達するまで更新されない、請求項１２に記載のコンピュータプログラム製品。
【請求項２１】
前記シンボルカウンタが、周期的に、又は、１若しくはそれ以上のシンボルカウンタが所定閾値に到達するときに、倍率ファクタによりスケーリングされる、請求項１２に記載のコンピュータプログラム製品。
【請求項２２】
プロセッサと、
前記プロセッサに動作可能に接続され、ビットストリームからの圧縮データをデコードするためのコンピュータプログラム製品を含むメモリユニットと、
を具備し、
前記コンピュータプログラム製品が、
前記ビットストリームから少なくとも１つのシンボルを含むシンボルベクトルを表わすコードワードをフェッチするコンピュータコードと、
可変長コードを使用して前記コードワードをデコードするためのコンピュータコードであって、該コードワードのデコードにより少なくとも１つのシンボルを含むシンボルベクトルを生じさせるコンピュータコードと、
前記シンボルベクトルからの前記少なくとも１つのシンボルをバッファに追加するコンピュータコードと、
以前にデコードされたシンボルの確率分布に少なくとも部分的に基づいて前記可変長コードを更新するコンピュータコードと、
前記バッファから次のシンボルを返送するコンピュータコードと、
を含む、
ことを特徴とする電子装置。
【請求項２３】
前記コンピュータプログラム製品が、更に、
前記可変長コードを更新する前に、前記バッファに追加されたシンボルを反映するようにシンボルカウンタを更新するコンピュータコードと、
以前にデコードされたシンボルの確率分布を決定する際に、前記シンボルカウンタを使用するコンピュータコードと、
を含む請求項２２に記載の電子装置。
【請求項２４】
前記コンピュータプログラム製品が、更に、
前記ビットストリームから前記コードワードをフェッチする前に、前記バッファが空であるか否かを決定するコンピュータコードと、
前記バッファが空である場合に、前記コードワードをフェッチすることに進むコンピュータコードと、
前記バッファが空でない場合に、前記バッファから次のシンボルを直ちに返送し、前記コードワードをデコードせず、シンボルを追加し、又は、現在の可変長コードを更新するコンピュータコードと、
を含む請求項２２に記載の電子装置。
【請求項２５】
前記コンピュータプログラム製品が、更に、
前記コードワードをデコードした後に、第１の値を有する要求されたシンボルの確率が、第２の特定の値を有するシンボルの確率より大きいか否かを決定するコンピュータコードと、
前記第１の値を有するシンボルの確率が、前記第２の値を有するシンボルの確率より大きい場合に、シンボルベクトルを反転させるコンピュータコードと、
を含む請求項２２に記載の電子装置。
【請求項２６】
前記コンピュータプログラム製品が、更に、
ビットストリームからコードワードをフェッチする前に、前記可変長コードに対応するシンボルベクトルにおけるシンボルの数を決定するコンピュータコードと、
前記シンボルの数が、処理されるべく残っているシンボルの数より大きいか否かを決定するコンピュータコードと、
前記シンボルの数が、処理されるべく残っているシンボルの数より大きい場合に、シンボルベクトルにおけるシンボルの数が、処理されるべく残っているシンボルの数より大きくないところの新たな可変長コードを与えるためのコンピュータコードと、
を含む請求項２２に記載の電子装置。
【請求項２７】
前記更新された可変長コードが、以前にデコードされたシンボルの確率分布に対して利用可能な可変長コードからシンボル当たり最小のビットを有するように選択される、請求項２２に記載の電子装置。
【請求項２８】
前記可変長コードが周期的に更新される、請求項２２に記載の電子装置。
【請求項２９】
前記周期は、可変長コードの１又はそれ以上の以前の更新において選択された可変長コードに少なくとも部分的に基づいて決定される、請求項２８に記載の電子装置。
【請求項３０】
前記可変長コードは、デコードされるシンボルの数が所定閾値に到達するまで更新されない、請求項２２に記載の電子装置。
【請求項３１】
前記シンボルカウンタが、周期的に、又は、１若しくはそれ以上のシンボルカウンタが所定閾値に到達するときに、倍率ファクタによりスケーリングされる、請求項２２に記載の電子装置。
【請求項３２】
ビットストリームにおいて送信するためのデータをエンコードする方法であって、
エンコードすべき複数のシンボルを検査するステップと、
該複数のシンボルのうちの少なくとも１つを表わすようにコードワードを選択するステップであって、前記複数のシンボルの各々が以前にエンコードされたインスタンスの数に少なくとも基づいて前記コードワードを選択するステップと、
を含むことを特徴とする方法。
【請求項３３】
前記コードワードの長さは、前記複数のシンボルの各々が以前にエンコードされたインスタンスの数に少なくとも部分的に基づく、請求項３２に記載の方法。
【請求項３４】
ビットストリームに対するデータをエンコードする方法であって、
シンボルをバッファに追加するステップと、
前記バッファにおけるシンボルの数が可変長コードに対するシンボルベクトルにおけるシンボルの数に等しいか否かを決定するステップと、
前記バッファにおけるシンボルの数が前記シンボルベクトルにおけるシンボルの数に等しい場合には、
前記バッファにおいてシンボルからシンボルベクトルを形成し、
前記可変長コードを使用して前記シンボルベクトルをエンコードし、
前記バッファをフラッシュし、
以前にエンコードされたシンボルの確率分布に少なくとも部分的に基づいて前記可変長コードを更新する、というステップと、
を含むことを特徴とする方法。
【請求項３５】
前記可変長コードを更新する前に、前記バッファに追加されたシンボルを反映するようにシンボルカウンタを更新するステップと、
以前にエンコードされたシンボルの確率分布を決定する際に前記シンボルカウンタを使用するステップと、
を更に含む、請求項３４に記載の方法。
【請求項３６】
前記可変長コードを使用して前記シンボルベクトルをエンコードする前に、第１の値を有するシンボルの確率が、第２の値を有するシンボルの確率より大きいか否かを決定するステップと、
前記第１の値を有するシンボルの確率が、前記第２の値を有するシンボルの確率より大きい場合には、シンボルベクトルを反転させるステップと、
を更に含む、請求項３４に記載の方法。
【請求項３７】
前記バッファにおけるシンボルの数が可変長コードに対するシンボルベクトルにおけるシンボルの数に等しいか否かを決定する前に、更に別のシンボルがエンコードされるべく残っているか否かを決定するステップと、
更に別のシンボルがエンコードされるべく残っていない場合には、シンボルベクトルにおけるシンボルの数が前記バッファにおけるシンボルの数より大きくないところの新たな可変長コードを与えるステップと、
を更に含む、請求項３４に記載の方法。
【請求項３８】
前記更新された可変長コードが、以前にエンコードされたシンボルの確率分布に対して利用可能な可変長コードからシンボル当たり最小のビットを所有するように選択される、請求項３４に記載の方法。
【請求項３９】
前記可変長コードが周期的に更新されるだけである、請求項３４に記載の方法。
【請求項４０】
前記周期は、前記可変長コードの１又はそれ以上の以前の更新において選択された可変長コードに少なくとも部分的に基づいて決定される、請求項３９に記載の方法。
【請求項４１】
前記可変長コードの更新は、前記ビットストリームにおける明確な信号によりトリガされるか、又は、ソースデータの推定特性によりトリガされる、請求項３４に記載の方法。
【請求項４２】
前記可変長コードは、エンコードされるシンボルの数が所定閾値に到達するまで更新されない、請求項４０に記載の方法。
【請求項４３】
前記シンボルカウンタが、周期的に、又は、１若しくはそれ以上のシンボルカウンタが所定閾値に到達するとき、倍率ファクタによりスケーリングされる、請求項３５に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、チャンネルコーディング及びデータ圧縮、並びにスケーラブルビデオコーディングに係る。より詳細には、本発明は、微粒度スケーラブルビデオコーディングにおけるコーディングに係る。本発明は、主として、ビデオコーディングに使用するように構成されるが、他の形式のデータ圧縮、例えば、スピーチ／オーディオ及びスチール映像圧縮についても実施することができる。
【背景技術】
【０００２】
ＭＰＥＧ−１、Ｈ．２６１／２６３／２６４のような従来のビデオコーディング規格は、「固定ＱＰエンコーディング」と通常称される所与のクオリティ設定、又はレートコントロールメカニズムの使用による比較的一定のビットレートのいずれかでビデオをエンコードする。ビデオを異なるクオリティで送信し又はデコードする必要がある場合には、最初にデータをデコードし、次いで、適当な設定を使用して再エンコードしなければならない。低遅延のリアルタイムアプリケーションのようなあるシナリオでは、この「トランスコーディング」手順を実現できないことがある。
【０００３】
同様に、従来のビデオコーディング規格は、特定の空間的解像度でビデオをエンコードする。ビデオを低い解像度で送信し又はデコードする必要がある場合には、最初にデータをデコードし、空間的にスケーリングし、次いで、再エンコードしなければならない。この場合も、このようなトランスコーディングは、あるシナリオでは実現不能である。
【０００４】
スケーラブルビデオコーディングは、「ベースレイヤ」をある最小クオリティでエンコードし、次いで、エンハンスメント情報をエンコードして、クオリティを最大レベルへ上昇することにより、この問題を克服する。エンハンスメント情報を完全に含ませるか又は除外することにより「ベース」クオリティと「最大」クオリティとの間で選択を行なうのに加えて、エンハンスメント情報を、しばしば、個別のポイントにおいて裁断し、「ベース」レイヤと「最大」エンハンスメントレイヤとの間の中間クオリティを許すことができる。クオリティエンハンスメントのために、情報を、しばしば、個別（しかし、接近した間隔）のポイントで裁断し、「ベース」と「最大」との間の中間クオリティを達成できるようにすることで、付加的な融通性を与えることができる。個別の裁断ポイントが接近した間隔となる場合には、スケーラビリティが「微粒状」と称され、ここから「微粒状スケーラビリティ」（ＦＧＳ）という語が導出される。
【０００５】
Ｈ．２６４／ＡＶＣへの現在のスケーラブル拡張は、空間的及びクオリティエンハンスメント情報をデコードするときに、演算コーダの一形式であるＣＡＢＡＣを使用する。ＣＡＢＡＣは、可変長コード（ＶＬＣ）に対する別のエントロピーコーディング方法である。ＣＡＢＡＣは、一般に、コーディング効率の利点を有するが、デコーダの複雑さが増す等、それに関連した多数の欠点もあることが明らかである。更に、Ｈ．２６４／ＡＶＣへの現在のスケーラブル拡張に対してＶＬＣ代替手段は提供されていない。非スケーラブルＨ．２６４／ＡＶＣ規格は、ＣＡＢＡＣ及びＶＬＣの両方をサポートし、その各々が利点と欠点を有することが認められ、特定のアプリケーションに最も適した方法を選択することができる。
【０００６】
更に、スケーラブルビデオコーディングでは、微粒状スケーラビリティ情報は、可変長コード又は演算コーディングを使用してビットストリームへコード化することができる。演算コーディングに代わって可変長コードを使用するときには、コーディング効率を改善することが望まれる。従来、値は、独立フラグとしてコード化されるか、又は固定長さグループへ収集されて、コンテクスト適応性でないＶＬＣを使用してエンコードされるかのいずれかであった。
【０００７】
可変長コードは、発生する確率の高い記号には短いコードワードが指定され、発生する確率の低い記号には長いコードワードが指定されるように設計される。より詳細には、確率ｐ(υ)＝２-kをもつ記号υには、長さｋビットのコードワードが指定される。
【０００８】
可変長コードテーブルを設計するのに使用される確率分布が、特定ビットストリームにおける実際の記号確率に一致しないときには、可変長コードの圧縮効率が低下する。このような「確率不一致」に貢献するファクタは、一般的に、２つある。第１に、実際の記号確率は、前もって分らず、したがって、可変長コードは、ある形式の一般化された「トレーニングデータ」を使用して設計されねばならない。この問題を克服するための技術は、ビットストリームヘッダにおいてコードテーブルを送信するか、又は多数の予め設計された可変長コードのどれがソースデータに最も正確に一致するか信号することを含む。第２に、記号確率は、前もって分るが、ｋが整数値に制限されるために、ｐ(υ)＝２-kに対応しないことがある。これは、構造的な制限であり、多数の記号をグループ編成して、各々の考えられるグループに１つのコードワードを指定することにより、しばしば、克服される。例えば、バイナリーのケースでは、２つの記号０及び１を対でグループ編成し、考えられる組み合せ００、０１、１０、１１を生じさせることができる。ｋにも同じ整数制約があるので、これは、確率式の精度を実際上２倍にする。
【０００９】
上述した「ワークアラウンド(work-around)」技術は、従来知られているが、しばしば非実用的である。例えば、確率分布が著しい局部的変動（例えば、ビデオコーディングにおいてあるフレームから別のフレームへ）を受ける場合には、最適なＶＬＣテーブルをビットストリームへコーディングすることに関連したオーバーヘッドが大きくなり過ぎることがある。他のケースでは、確率分布を正確に表わすために合成する必要のある記号の数が、デコードされるべき記号の数を越えることがあるか、又は望ましからぬ複雑さをデコーディング経路に付加することがある。上述した制約を克服する上で助けとなるように、演算コーディングを使用することができる。例えば、ＣＡＢＡＣのような演算コーダは、ビットストリームシグナリングが要求されないように記号確率に自己適応し、このようなコーダは、記号確率の限定セットを受けない（即ち、式ｐ(υ)＝２-kにおいてｋが整数であるように制約されない）。しかしながら、演算コーディングは、それ自身の欠点がある。これは、一般に、上述した他のシステムより複雑であり、デコーディング時に「先を読む」必要性が、データを裁断して有効なデコーダ状態を維持するのを困難にする。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
それ故、可変長コード（即ち、複雑さが少なく、瞬時にデコード可能であり／容易に裁断可能である）と、演算コーディング（即ち、自己適応性で且つ記号確率を良好にモデリングできる）の両方の肯定的特性を示すエントロピーコーディングメカニズムを有することが望まれる。
【課題を解決するための手段】
【００１１】
本発明は、可変長コード（ＶＬＣ）を使用するときにコーディング効率の改善を与える。又、本発明は、ソースデータの特性の変化に自動的に適応する能力をシステムに与える。既存のＶＬＣベースの解決策と比して、本発明は、記号（シンボル）確率に動的に適応し、ビットストリームにおいてＶＬＣテーブルを明確に指定する必要がない。又、本発明は、記号間の相関を利用する多数の既存のＶＬＣベースの解決策に比して、独立変数をコード化するときにコーディング効率利得を与える。更に、本発明の解決策の内部状態は、従来の演算コーディング解決策のケースより簡単である。各コードワードは、将来の値とは独立してデコード可能であり、これは、例えば、変更されたバッファをビットストリームに「リライト」する必要なく、ビットストリームを裁断することができる。
【００１２】
本発明は、可変長コードを使用するときにＦＧＳレイヤに対するコーディング効率を改善するための方法を提供する。コード化ブロックパターン（ＣＢＰ）をデコードするときには、使用されるべき可変長さコーディングは、それに対応するベースレイヤＣＢＰにおける１と０の数と、コード化されているブロックの確率とに依存する。コード化されているブロックの確率は、以前に観察されたＣＢＰに基づく。コード化ブロックフラグ（ＣＢＦ）をデコードするときには、単一のコードワードが、多数のＣＢＦを表わすようにデコードされる。使用する可変長さコーディングは、以前のＣＢＦ値の確率が１であることに依存する。ブロック終了（ＥＯＢ）フラグをデコードするときには、１より大きな大きさ及び／又はブロック内の最大の大きさをもつブロック内の係数の数を表わすのに「不法記号」が使用される。洗練ビットをデコードするときには、１つ以上の洗練ビットのグループが単一のＶＬＣコードワードからデコードされ、ここで、使用するＶＬＣは、以前に観察された洗練値に基づく。
【００１３】
本発明は、例えば、Ｃ／Ｃ＋＋又はアッセンブリ言語のような通常のプログラミング言語を使用するソフトウェアで直接的に実施することができる。又、本発明は、ハードウェアでも実施できると共に、広範囲な種々の消費者向け装置に使用することができる。
【００１４】
又、本発明は、可変長コードを使用して空間的及びクオリティ（ＦＧＳ）エンハンスメント情報をデコードするための方法も提供する。本発明は、スケーラブルビデオコーディングにＶＬＣを使用する解決策で、これまでには存在しない解決策を提供する。ＶＬＣの使用は、計算効率に若干のロスを伴うが（約１０％程度の）、このロスは、コーダの複雑さの改善により相殺される。実際に、エンハンスメントレイヤに対して観察されたトレードオフは、非スケーラブルＨ．２６４／ＡＶＣ規格に対して既に受け容れられているトレードオフに極めて類似している。
【００１５】
本発明のこれら及び他の効果並びに特徴は、そのオペレーションの編成及び仕方と共に、多数の図面にわたって同じ要素が同じ番号で示された添付図面を参照してなされた以下の詳細な説明から明らかとなろう。
【発明を実施するための最良の形態】
【００１６】
一般に、クオリティエンハンスメント情報は、コード化ブロックパターン、有効性(significance)パス及び洗練(refinement)パスの３つのカテゴリーに分割できる。コード化ブロックパターンでは、各マクロブロック（ＭＢ）、又はマクロブロックの領域、例えば、８ｘ８領域「サブＭＢ」に対して「コード化フラグ」がデコードされる。フラグをデコードする必要があるのは、全ての下位レイヤにおける対応マクロブロックの「コード化フラグ」がゼロであった場合、即ちベースレイヤ又は他の下位レイヤにおいてＭＢがコード化されなかった場合だけである。ここに含まれる説明及び実施例は、特に、デコーディングプロセスについて述べるものであるが、当業者であれば、同じコンセプト及び原理をそれに対応するエンコーディングプロセスにも適用でき、その逆も言えることが容易に理解されよう。
【００１７】
「コード化」としてフラグの立てられたＭＢ（又はサブＭＢ）については、ＭＢ（又はサブＭＢ）内の各４ｘ４ブロックに対するコード化ブロックパターンがデコードされる。ＭＢの各８ｘ８領域には、例えば、４つの４ｘ４ブロックがある。４ｘ４ブロックのどれが、エンコードされるべき係数を含むかを指示するために、バイナリー数を使用することができる。数字０１０１は、左上の４ｘ４ブロックが、デコードされるべき係数をもたず、右上の４ｘ４ブロックがエンコードされ、左下がエンコードされず、右下がエンコードされたことを指示できる。４ｘ４ブロックがベースレイヤにおいてコード化されたとして既にフラグが立てられた場合には、ＣＢＰ値がデコードされない。それ故、非スケーラブルＨ．２６４／ＡＶＣとは異なり、ＣＢＰにおけるビットの数が変化し得る。前記例を使用すると、右下の４ｘ４ブロックがベースレイヤにおいて既にエンコードされた場合には、ＣＢＰの最後のビットが不必要となり、ＣＢＰは、０１０となる。
【００１８】
ＶＬＣは、ＣＢＰをデコードするのに使用される。使用する特定のＶＬＣは、ＣＢＰにおけるビットの数に依存する。それ故、ＶＬＣは、コンテクスト（即ち、使用するＶＬＣ）がベースレイヤのＣＢＰにより与えられる「コンテクスト適応性」（ＣＡＶＬＣ）である。又、コンテクスト判断は、ベース及び／又はエンハンスメントレイヤにおける空間的に隣接するブロックのＣＢＰにより影響される。又、コンテクスト判断は、その少なくとも一部分が、隣接ブロックにおけるコード化係数の個数に基づくか、又はエンハンスメントレイヤの隣接ブロックにおけるコード化係数の位置に基づくことも考えられる。
【００１９】
使用するＶＬＣは、注文設計されてもよいし、又はＧｏｌｏｍｂコードのような「構造化」ＶＬＣを含んでもよい。Ｇｏｌｏｍｂコードは、値の確率の簡単なモデルに基づいた可変長コードで、小さな値の方が大きな値より見込みが高い。有効性ビットは、全ての下位レイヤにおいて係数がゼロであり、即ちそれが現在レイヤまでデコードされなかったときに、デコードされる。有効性ビットは、係数がゼロであるか非ゼロであるかを指示する。係数が非ゼロである場合には、符号及び大きさが続く。
【００２０】
本発明では、ゼロの数（即ち、ラン）が、次の有効性係数の前にエンコードされる。例えば、ベースレイヤが値１０１００１を含み、エンハンスメントレイヤが値１０２０１１を含む場合には、第１、第３及び第６の係数が、有効性ビットをデコードする目的で無視される。というのは、それらは、ベースレイヤにおいて非ゼロだからである。したがって、デコードされるべき値は、００１である。このケースでは、非ゼロ値までのゼロの「ラン」が２である。「スキャン位置」という語は、ここでは、ランが始まるところの係数のインデックスとして定義される。前記の例では、第１係数が無視され、したがって、デコードされる第１のゼロ値は、スキャン位置２にある。又、「ラン」をデコードするのに使用されるＶＬＣも、コンテクスト適応であり、スキャン位置、ベースレイヤにおいてコード化される係数の個数（前記例では３）、ベースレイヤにおいてコード化される最後の係数のインデックス（前記例では６）、又はこれら３つの組み合せに依存する。又、本発明は、ＶＬＣが構造化されないもの（即ち、任意のＶＬＣが選択される場合）を含むと共に、Ｇｏｌｏｍｂコードやスタート・ステップ・ストップコードのような「構造化」ＶＬＣが使用されるより狭い状況を含むことに注意されたい。
【００２１】
本発明の特定の実施形態では、最適なＶＬＣへのコンテクスト基準のマッピングがビットストリームからデコードされる。これは、例えば、スライス当たり１つでもよいし（スライスヘッダーにおいて）又はフレーム当たり１つでもよい。「スキャン位置＃１については、ｋ＝１でＧｏｌｏｍｂコードを使用し」、「スキャン位置＃２については、ｋ＝１でＧｏｌｏｍｂコードを使用し」、「スキャン位置＃３については、ｋ＝２でＧｏｌｏｍｂコードを使用し」、等々を指定することができる。どのコンテクスト基準がどのＶＬＣへマップするかの決定は、エンコーディングの前にデータを「予めスキャニングする」か、又は以前にエンコードされたデータ（例えば、以前のフレーム）の統計値を使用することにより、遂行することができる。デコードされるべきビットストリームは、実質上いかなる形式のネットワーク内に位置するリモート装置からでも受け取れることに注意されたい。更に、ビットストリームは、ローカルハードウェア又はソフトウェアから受け取ることもできる。
【００２２】
本発明の更に別の実施形態では、ＶＬＣへのコンテクスト基準のマッピングは、効率的な仕方でコード化される。これを達成するために、考えられるＶＬＣが規則的に順序付けされる。例えば、考えられるＶＬＣは、「最大ピーク付き」確率分布（第１記号値に高いピーク）から「最小ピーク付き」又は平坦分布まで順序付けすることができる。ＶＬＣそれ自体にはインデックスが与えられる。例えば、第１のＶＬＣは、パラメータｋ＝１を伴うＧｏｌｏｍｂコードであり、第２のＶＬＣは、パラメータｋ＝２を伴うＧｏｌｏｍｂコードであり、等々である。ＶＬＣがコンテクスト選択基準の単調な（増加又は減少する）関数であるよう強制することにより、コード化効率に全体的な改善が得られる。ＶＬＣ選択の最適化に若干のロスがあっても、この効率が生じる。前記例を使用すると、スキャン位置１、２及び３に使用されたＶＬＣは、各々、１、１及び２であり、これは、１１２と書き表すことができる。１２１のようなシーケンスは、単調ではないので、許されない。関数が単調な性質であるために、スタートＶＬＣと、ステップの位置をデコードするだけでよい。例えば、値「１１２」を明確にデコードするのではなく、スタートＶＬＣ（１）をデコードし、それに続いて、次のレベルへのステップまでの値の数をデコードすることができる。
【００２３】
上述した実施形態は、２つ以上のコンテクスト選択基準が存在する状況へと拡張することができる。これは、マッピング関数を２（又は‘ｎ’）次元テーブルとして描き、各次元に沿って単調性を強いることにより達成できる。別の例では、ＶＬＣは、スキャン位置と、最後の非ゼロベースレイヤ係数の位置との両方に基づいて選択される。このケースでは、最適なＶＬＣのマッピングは、例えば、次の通りである。
１１２
２２２
１２２
【００２４】
このテーブルにおいて、第１の行は、最後の非ゼロベースレイヤ係数（ＬＮＺＢＣ）が位置１にあるケースに対応し、第２の行は、ＬＮＺＢＣが位置２にあるケースに対応し、等々となる。各行は、単調に増加するが、第１の列は、そうではないことに注意されたい。この制約を強制することにより、テーブルは、次のように書き直すことができる。
１１２
２２２
２２２
【００２５】
或いは又、次のようになる。
１１２
１２２
１２２
【００２６】
この状況において、ランレベルコーディングを各次元に沿って適用することができる。例えば、第１の行は、上述したようにデコードすることができる。スタート位置は、各列をデコードするときに第１の行から使用することができる。これは、実施時に、マトリクスの左上角を除くほとんどの値のコーディングを回避する。
【００２７】
本発明の更に別の実施形態では、ブロック終了（ＥＯＢ）マーカーを使用して、所与のブロックに対する有効性パスにデコードを必要とする係数がそれ以上ないことを指示する。ＥＯＢは、有効性ビットをデコードするときに、別の考えられるラン長さ（概念的な値−１を伴う）として処理される。
【００２８】
構造化ＶＬＣの場合、最低値付き記号は、最も高い確率をもたねばならない。あるケースでは、ＥＯＢは、実際に、全ての記号の最も高い確率を有するが、常にそうではない。これは、ＶＬＣにおけるＥＯＢ記号位置を指示するビットストリーム（例えば、スライスヘッダー）値からデコードを行なうことで克服できる。これは、一度行うことができ、又は更なるコーディング効率利得を得るために、コンテクスト選択基準の幾つか又は全部について一度行うことができる。例えば、スキャン位置ごとに一度デコードすることができる。ＶＬＣマッピングについて上述したようにＥＯＢ記号位置をデコードするために同じ単調制約及びデコード方法が適用されてもよい。更に別の実施形態では、ＥＯＢ記号は、あるコンテクスト基準に対して非常に低い確率を有するものとして指定される。コーディング効率を改善するために、このような「低確率」ＥＯＢ記号の数を指示する個別記号をデコードすることができる。次いで、残りのＥＯＢ記号のデコーディングが、上述したように続く。
【００２９】
前記説明は、終了値の符号も大きさも考慮せずに、有効性係数の位置をデコードすることに向けられた。一般に、ほとんどの値は、大きさが０又は１である。２ないし４の大きさも考えられる。
【００３０】
コーディング効率を改善する１つの方法は、有効性ビットを２つのパスに分割することである。第１のパスでは、大きさがデコードされない。実際に、位置情報及び符号フラグのみがデコードされる。有効性係数の大きさは、１であると仮定する。第２のパスでは、高い大きさをもつ係数の位置がエンコードされる。例えば、値００１００−３１０をデコードすべき場合には、値００１００−１１０が最初にデコードされる。この状況では、大きさが１の３つの有効性係数がある。次いで、第２のパスでは、「２」がデコードされ、これは、単位大きさ係数の第２のものが、実際に、より大きな大きさ（このケースでは、３の大きさ）を有することを示す。より大きな大きさの係数の位置を識別した後、正確な大きさ（例えば、２、３又は４）がデコードされる。この目的のために１つの固定ＶＬＣを使用することができる。本発明の別の実施形態では、このＶＬＣそれ自体は、コンテクスト適応性であり、スキャン位置、単位大きさ値の数、デッドゾーンサイズ、エンハンスメントレイヤ番号、他のファクタ及びこのようなファクタの組み合せのような基準に基づいて選択される。本発明の別の実施形態では、プロセスが繰り返され、大きさ２の係数が第２パスにおいてデコードされ、大きさ３の係数が第３パスにおいてデコードされ、大きさ４の係数が第４パスにおいてデコードされる。この反復プロセスは、各サイクルにおける大きさ情報をデコードする必要性を排除する。
【００３１】
最後に、洗練ビットは、下位レイヤにおいて係数が非ゼロであるときに送信される。洗練ビットは、大きさ及び符号情報を含む。洗練ビットは、固定サイズのロットにグループ編成される。本発明の１つの特定の実施形態では、洗練ビットが、３のロットにグループ編成されるが、他のサイズを使用してもよい。例えば、３ビットグループでは、洗練ビットが０００１１０１００１である場合、これは、［０００］［１１０］［１００］［１］へとグループ編成される。最後のセットは、３より少ない値を含むことに注意されたい。バイナリー値に対応する記号は、次いで、ＶＬＣを使用してエンコードされる。前記例では、記号０、６、４及び１がエンコードされる。
【００３２】
記号をエンコードするのに使用されるＶＬＣは、ビットストリームからデコードされるか、以前にデコードされたデータから推定されるか、又はＦＧＳレイヤ番号に基づくものとされる。考えられるＶＬＣは、ゼロの確率が減少する順に構造化される。例えば、ゼロの確率が高いことを反映するＶＬＣでは、最も短いコードワードを使用して、値０００を表わし、次に最も短いコードワードを、値００１、０１０、１００、等に使用する。ゼロ記号の最低確率は、記号及びコードワードが等価であるときの５０％ケースである。
【００３３】
最後の記号がエンコードされると、効率のロスが僅かであるからフラグのみが使用される（ＶＬＣは使用されない）。又、最後のコードワードを詰め込むか、又は異なるＶＬＣ（他の値に使用されるＶＬＣに基づいて選択された）を使用することが考えられる。
【００３４】
符号ビットは、上述したのと同様にエンコードされる。しかしながら、符号ビットについては２つのケースしかない。即ち、分布は、第１のエンハンスメントレイヤに対しゼロに向かってスキューする傾向となるか、又はその後のエンハンスメントレイヤに対し５０％が１で、５０％が０に向かう傾向となる。それ故、ＶＬＣは、エンハンスメントレイヤ番号に依存する。５０／５０ケースでは、値がグループ編成されるのではなく、フラグがエンコードされる。
【００３５】
本発明では、空間的エンハンスメント情報のエンコーディングは、一般に、Ｈ．２６４／ＡＶＣのもとでの通常の非スケーラブルエンコーディングと同様である。しかしながら、空間的なアップサンプル情報をエンコードするときには、付加的な及び／又は異なるＶＬＣを使用することができ、使用するコンテクストは、空間的な隣接部ではなく、下位レイヤ情報に基づくことができる。
【００３６】
【数１】
2009510962.tif 000003
【００３７】
テーブル１(ａ)−１(ｃ)は、３つの例示的なＶＬＣコードワードテーブルを示す。この状態において、コードワードは、より多くのゼロを含む記号ベクトルが、より短いコードワードを有するように選択される。各コードワードテーブルに対するＲ対ｐ(０)の対応プロットが図１に示されている。
【表１】
2009510962.tif 000004
【００３８】
本発明によれば、ｐ(０)の各値における最適なＶＬＣは、記号当たり最小のビット、即ち図１に示す曲線の下限を生じるＶＬＣである。これは、マッピングテーブル（テーブル２）で表わすことができ、又は次の関数で近似することができる。
【表２】
2009510962.tif 000005
【００３９】
前記例は、３つのＶＬＣを使用して本発明の概念を示すが、その手順は、異なる数のＶＬＣを使用して、又はＮの他の値をもつＶＬＣを使用して、又はテーブル１(ａ)−１(ｃ)に用いたものとは異なるコードワードを伴うＶＬＣに対して、繰り返すことができる。
【００４０】
一実施形態では、本発明は、Ｈ．２６４／ＡＶＣにおいて微粒状スケーラビリティ情報のデコーディングに適用される。Ｈ．２６４／ＡＶＣによれば、微粒状スケーラビリティ情報は、２つのパスでデコードされる。第１に、「有効性パス」は、ベースレイヤ又は以前のエンハンスメントレイヤにおいてコード化されていない全ての係数を考慮する。第２に、「洗練パス」は、残りの係数、即ち以前のレイヤにおいてコード化された係数の精度を改善する。この実施形態では、洗練ビットが１である確率は、ｐ(１)であり、洗練ビットがゼロである確率は、ｐ(０)である。
【００４１】
図１のグラフは、デコードされる記号が互いに独立していると仮定する。換言すれば、次の記号の確率分布は、現在記号の値に基づいてコンディショニングすることができない。独立性についてのこの仮定は、本質的に、ＦＧＳコーディングにおける洗練ビットについて言えることである。対照的に、可変長さコーディングのための従来のシステムは、記号間の相関を利用することに向けられ、それ故、独立した値をコード化するときには限定使用となる。
【００４２】
互いに独立であるが、洗練ビットは、スキューした確率分布を示し、即ちｐ(０)及びｐ(１)の値は、しばしば等しくない。この実施形態では、ｐ(１)及びｐ(０)の値は、以前にデコードされた洗練ビットを観察することにより決定される。又、これらの値は、ビットストリームへ明確にコード化することができる。
【００４３】
例えば、テーブル２を使用することにより適当なＶＬＣを決定すると、通常のＶＬＣエンコーディング／デコーディングプロセスを続けることができる。デコーディングプロセスが図２に示されている。図２のステップ２００において、記号が要求される。ステップ２１０において、バッファが空であるかどうか決定される。バッファが空でない場合には、使用すべき次の記号が２２０においてバッファから返送され、２３０において、記号が出力される。バッファが空である場合には、２４０において、コードワードがビットストリームからフェッチされる。ステップ２５０では、コードワードが、現在ＶＬＣを使用してデコードされる。これは、記号ベクトルを生じさせる。ステップ２６０において、記号ベクトルからの記号がバッファに追加される。ステップ２７０では、記号カウントが更新される。ステップ２８０では、現在ＶＬＣが更新され、システムは、上述したように、ステップ２２０及び２３０へ進む。
【００４４】
図３は、図２に示されたプロセスに対して現在ＶＬＣを更新するためのプロセスを示すフローチャートである。ステップ３００において、ｃｏｕｎｔ(０)＜２ｃｏｕｎｔ(１)であるかどうか決定される。ｃｏｕｎｔ(０)＜２ｃｏｕｎｔ(１)である場合には、ステップ３１０において、Ｋが０にセットされる。ｃｏｕｎｔ(０)が２ｃｏｕｎｔ(１)以上である場合には、ステップ３２０において、ｃｏｕｎｔ(０)＜７ｃｏｕｎｔ(１)であるかどうか決定される。ｃｏｕｎｔ(０)＜７ｃｏｕｎｔ(１)である場合には、ステップ３３０において、Ｋが１にセットされる。ｃｏｕｎｔ(０)が７ｃｏｕｎｔ(１)以上である場合には、ステップ３４０において、Ｋが２にセットされる。
【００４５】
実際のソース圧縮システムに使用するための本発明の種々の実施形態の実施に含まれる多数の細部について以下に述べる。コーダが自己適応するために、ＶＬＣ選択を「更新」しなければならない。換言すれば、Ｋの値は、上述したテーブル又は方式の方法を使用して再計算しなければならない。最適なコーディング効率を得るために、この「更新」は、図２に示すように、各コードワードがデコードされた後に行わねばならない。しかしながら、あるケースでは（例えば、複雑さを低減するために）、例えば、各２番目又は各３番目のコードワードをデコードした後に更新を行うように、更新の頻度を減少することが望まれる。この「更新の頻度」は、前もって設計されてもよいし、ビットストリームにおいて明確に指示されてもよいし、又はコーディング履歴に基づいて推定されてもよい。例えば、「更新の頻度」は、選択されたＶＬＣの変化の観察をどれほど頻繁に行なうかに基づいて動的に変更されてもよい。
【００４６】
４番目の記号ごとに更新を行うケースが図４に示されている。ステップ４００において、［ｃｏｕｎｔ(０)＋ｃｏｕｎｔ(１)］％４＝０であるかどうか決定され、「％」は、モジュラス演算子である。もしそうでなければ、更新は行われない。値がゼロに等しくない場合には、行われるステップは、図３に示すものと実質的に同一である。
【００４７】
最初に、確率測定は、限定された数の観察に基づく。これは、準最適なＶＬＣが選択される見込みを高める。この問題を克服するために、ＶＬＣを指定する「初期値」を、観察される記号の数がある限界に到達するまで、使用することができる。この限界に到達した後に、上述した通常の更新手順が行われる。ＶＬＣを指定する「初期値」は、前もって設計されてもよいし、ビット流において指示されてもよい。これは、図５に示されている。図５のステップ５００において、［ｃｏｕｎｔ(０)＋ｃｏｕｎｔ(１)］が、記号の閾値数としてセットされた８より大きいかどうか最初に決定される。この閾値を越えない場合には、更新が行われない。閾値を越える場合には、プロセスは、図３に示したものと実質的に同様に進行する。図４に示すプロセスもこの状況において実施することができる。
【００４８】
図１におけるｐ(０)の確率は、ｐ(０)＝０．５で開始することに注意されたい。換言すれば、ｐ(０)≧ｐ(１)のケースを示している。記号確率は、デコーダにおいて測定されるので、デコーダは、そのようなケースであるかどうか知っており、ｐ(０)＜ｐ(１)の場合にそれらをデコードした後に記号ベクトルを「ビットフリップ」する。それ故、図１のプロットは、ｐ(０)＝０．５に対して対称的であると考えることができる。これが図６に示されている。図６のプロセスは、図２と実質的に同じであるが、ステップ２５０の後に、ｃｏｕｎｔ(１)＞ｃｏｕｎｔ(０)であるかどうか決定される。もしそうであれば、記号ベクトルは、ステップ２６０へ進む前にステップ６１０で反転される。
【００４９】
【数２】
2009510962.tif 000006
【００５０】
バイナリーのケースでバッファをフラッシュするのに使用されるＶＬＣを決定するために、図１で始めて、Ｎが現在ＶＬＣに対するＮの値以上であるところの全ての曲線を除外する。例えば、現在ＶＬＣがＶＬＣ２である場合には、ＶＬＣ２が除外され、ＶＬＣ０とＶＬＣ１を残す。次いで、ｐ(０)の値が、残りの曲線の下限と比較され、バッファをフラッシュするための最適なＶＬＣを決定する。デコーダは、通常のＶＬＣを使用して「全」コードワードをデコードすべきか、又は異なるＶＬＣを使用してバッファフラッシュを処理すべきか知っているとすれば、ビットストリームを処理することができる。
【００５１】
デコーダは、処理されるべく残っている記号の数を現在ＶＬＣに対するＮの値と比較することにより２つのケースのいずれを適用するか決定できる。Ｎが残りの記号の数以下である場合には、「全」コードワードがデコードされる。さもなければ、バッファフラッシュがデコードされる。このプロセスが図７に示されている。図７は、図６と実質的に同じであるが、ステップ２１０の後に、ステップ７００において、Ｎが残りの記号の数を越えるかどうか決定される。Ｎがこの数を越える場合には、ステップ２４０へ進む前に、ステップ７１０において、現在ＶＬＣが更新され、Ｎが残りの記号の数より大きいＶＬＣを除外する。
【００５２】
デコードされるべく残っている記号の数を使用することは、多数の他の可変長さコーディングから区別される本発明の別の重要な特徴である。この数は、ビットストリームから明確にデコードされてもよいし、設計時定数であってもよいし、又はビットストリーム内の他の情報から推測されてもよい。
【００５３】
ビデオデータを含むビットストリームからのＦＧＳ情報をデコードするために本発明が使用される一実施形態では、フラッシュプロセスは、情報が周期的に整列されるように行うことができる。例えば、フラッシュプロセスは、各４ｘ４ブロック又は各マクロブロックの終りに行なわれる。これもビデオデータを含むビットストリームからのＦＧＳ情報をデコードすることを伴う別の実施形態では、フラッシュプロセスは、シンタックスエレメントの形式が変化するたびに行なわれる。例えば、全ての洗練ビットがコード化された後に、フラッシュが行われ、その後、符号情報が続き、その後、別のフラッシュが行われてもよい。
【００５４】
これもビデオデータを含むビットストリームからのＦＧＳ情報をデコードすることを伴う更に別の実施形態では、デコーダの状態が周期的にリセットされ、例えば、スライス当たりに一度、又はビデオデータのフレーム当たりに一度、リセットされる。
【００５５】
更に別の実施形態では、フラッシングの周期はコーダのリセット間隔に等しく、実際上、フラッシングが行われないことを意味する。例えば、種々のシンタックスエレメントがフラッシングなしにインターリーブされるか、又は多数のブックからの情報がフラッシングないしにコード化される。
【００５６】
フラッシングプロセスの結果として、準最適なＶＬＣが、一部分の時間、使用される。一般的に、コーディング効率のロスは、小さい。これは、バッファサイズＮも小さいことと相まって、演算コーディングに比して、バッファをかなり頻繁にフラッシュできることを意味する。例えば、ビデオコーディングでは、バッファは、ブロック（おそらく１６個未満の記号）ごとにフラッシュすることができる。その結果、コーディング効率利益の多くは、演算コーディングに関連しているが、バッファフラッシングの頻度が高いために、ビットストリームの裁断を、より正確に制御できるようになる。
【００５７】
【数３】
2009510962.tif 000007
【００５８】
本発明の基本的な構成は、非バイナリー記号アルファベット、即ちアルファベットにおける３つ以上の記号に適用できる。例えば、３進のケースでは、２次元プロットが３次元表面となる。しかしながら、アルファベットのサイズが増大するにつれて、最適なＶＬＣを選択するための関数がより複雑になることに注意されたい。
【００５９】
別の実施形態では、本発明は、コード化ブロックパターンのデコーディングに適用される。コード化ブロックパターンは、デコードされるべき値を含むマクロブロック内の空間的領域を指定する。例えば、Ｈ．２６４／ＡＶＣでは、ＣＢＰは、１６ｘ１６マクロブロック内のどの８ｘ８ブロックがデコードされるべき値を含むか指定する。
【００６０】
本発明によれば、デコードされるべき値を含むブロックの確率がｐ(１)であり、デコードされるべき値を含まないブロックの確率がｐ(０)である。この実施形態では、ｐ(１)及びｐ(０)の値は、以前にデコードされたＣＢＰ値を観察することにより決定される。又、これらの値は、ビットストリームへと明確にコード化することができる。
【００６１】
本発明のこの実施形態では、完全なＣＢＰを形成するのに充分なバイナリー値が読み取られるまで、コードワードがビットストリームからデコードされる。例えば、１６ｘ１６マクロブロック及び８ｘ８ブロックのケースでは、ＣＢＰに４ビットがある。それゆえ、考えられるＶＬＣがテーブル１(ａ)及びテーブル１(ｂ)から引き出され、ＶＬＣ０が選択された場合には、４つのコードワードを読み取ることが必要になる。ＶＬＣ１が選択された場合には、１つのコードワードを読み取るだけでよい。
【００６２】
更に別の実施形態では、本発明は、対応するベースレイヤマクロブロックのＣＢＰがデコーディングプロセスに使用されるようなコード化ブロックパターンのデコーディングに適用される。エンハンスメントレイヤマクロブロックのＣＢＰは、２つの部分に仕切られる。第１部分（ＣＢＰ０）は、ベースレイヤＣＢＰの対応ビットがゼロであるところのブロックに対してエンハンスメントレイヤＣＢＰビットを含む。第２部分（ＣＢＰ１）は、ベースレイヤＣＢＰの対応ビットが１であるときに残りのエンハンスメントレイヤＣＢＰビットを含む。例えば、ベースレイヤＣＢＰが０００１であり、エンハンスメントレイヤＣＢＰが１１０１である場合には、ＣＢＰ０は、エンハンスメントレイヤＣＢＰの最初の３ビットを含み、即ちＣＢＰ０＝１１０であり、ＣＢＰ１は、残りのビットを含み、即ちＣＢＰ１＝１である。
【００６３】
確率ｐ(０)及びｐ(１)は、ＣＢＰ０に対して個別に維持され（ｐ0(０)及びｐ0(１)で示す）、ＣＢＰ１に対して個別に維持される（ｐ1(０)及びｐ1(１)で示す）。最適なＶＬＣは、ＣＢＰ０及びＣＢＰ１の各々に対して別々に決定され、ＣＢＰ０及びＣＢＰ１のデコーディングは、独立して進められる。
【００６４】
本発明の別の実施形態では、ＣＢＰをＣＢＰ０及びＣＢＰ１に分割すべきかどうかの判断は動的に行われる。例えば、コスト関数を使用して、ＣＢＰ０、ＣＢＰ１及び非セグメント化ＣＢＰの各々をデコードするのに必要なビット数を推定することができる。コスト関数への１つの入力は、ｐk(０)の値を含む。ＣＢＰ０を表わすための推定ビット数と、ＣＢＰ１を表わすための推定ビット数との和が、非セグメント化ＣＢＰをデコードするのに必要な推定ビット数より低い場合には、ＣＢＰ０及びＣＢＰ１の値が独立してデコードされる。さもなければ、非セグメント化ＣＢＰがデコードされる。
【００６５】
別の実施形態では、本発明は、コード化ブロックフラグ（ＣＢＦ）のでコーディングに適用される。ＣＢＦは、マクロブロック内の領域が、デコードされるべき値を含むかどうか指示する。Ｈ．２６４／ＡＶＣに対する既存のＦＧＳでは、ＣＢＦが独立してデコードされる。しかしながら、コーディング効率利得は、ＣＢＰについて、多数のＣＢＦを同時にデコードすることにより実現することができる。以前のＣＢＦがゼロであるか１であるかの確率が測定され、この情報を使用して、デコーディングのためのＶＬＣを選択する。これは、ＣＢＰに対するケースと同様に遂行される。ビットフリッピングも使用される。
【００６６】
一実施形態では、ＣＢＦ値のベクトルをコード化するときに、ベースレイヤにおける対応ブロックからのＣＢＦを使用して、使用すべきＶＬＣを決定する。別の実施形態では、ベースレイヤにおける対応ブロックからのＣＢＦ値を使用して、エンハンスメントレイヤＣＢＦをセグメント化する。例えば、ＣＢＰと同様に、値ＣＢＦ０及びＣＢＦ１を形成することができ、ＣＢＦ０は、ベースレイヤＣＢＦがゼロであるところのエンハンスメントレイヤＣＢＦ値を含み、ＣＢＦ１は、ベースレイヤＣＢＦが１であるところのエンハンスメントレイヤＣＢＦ値を含む。これらのセグメント化ＣＢＦ値は、例えば、セグメント化ＣＢＰをコード化する方法と実質的に同一の方法を使用して、個々にコード化することができる。
【００６７】
別の実施形態では、本発明は、Ｈ．２６４／ＡＶＣにおけるＦＧＳ情報のデコーディングに適用され、より詳細には、有効性パスにおけるブロック終了（ＥＯＢ）マーカーのデコーディングに適用される。現在、Ｈ．２６４／ＡＶＣは、単一ＥＯＢ記号を使用して、非ゼロ値がブロックに残っているかどうか指示する。本発明は、多数のＥＯＢ記号の使用を伴い、使用されるＥＯＢ記号の幾つか又は全部は、有効性パス中に「有効性」として指定されたブロックからの係数の大きさに関する情報を指示する。この情報は、大きさが１より大きいブロック内の係数の数を含む。或いは又、この情報は、有効性パスにおいてデコードされる係数の最大の大きさを含んでもよい。又、この情報は、これらアイテムの両方の組み合せを含むこともできる。
【００６８】
１より大きな大きさ（ｘ）及び有効性パスでデコードされた係数の最大大きさ（ｙ）をもつブロック内の係数の数は、ＥＯＢoffset＝１６ｙ＋ｘのような分離可能な一次関数を使用して結合することができる。この状況において、デコーディングプロセスでは、ｙ＝ＥＯＢoffset／１６、及びｘ＝ＥＯＢoffset％１６であり、即ちｘは、ＥＯＢoffsetを１６で除算したときの残余である。あるケースでは、一次関数の結合が使用される。例えば、ｙ＜４の場合には、ＥＯＢoffset＝２ｘ＋ｙ％２であり、さもなければ、ＥＯＢoffset＝１６ｙ＋ｘである。
【００６９】
デコードされる係数の数（ｚ）も一次式に組み込むことができる。例えば、一実施形態において、ｙ＜４の場合には、ＥＯＢoffset＝２(ｘ−１)＋ｙ％２であり、さもなければ、ＥＯＢoffset＝ｚ(ｙ−２)＋ｘ−１である。それ故、デコーディングプロセスでは、ＥＯＢoffset＜２ｚの場合には、ｘ＝(ＥＯＢoffset／２)＋１、ｙ＝(ＥＯＢoffset％２)＋２であり、さもなければ、ｘ＝(ＥＯＢoffset％ｚ)＋１、ｙ＝(ＥＯＢoffset／ｚ)＋２である。
【００７０】
それ故、本発明は、（１）１つのＥＯＢ記号を使用して、有効性パスでデコードされた係数がどれも１より大きな大きさをもたないブロックの終りを指示し、（２）残りのＥＯＢ記号がブロック終了状態を指示するだけでなく、更に、１より大きな大きさ及び最大の大きさをもつ係数の数も指示するような特定のケースをカバーする。
【００７１】
本発明の一実施形態において、大きさ情報を含むＥＯＢマーカーとして使用される実際の記号は、任意であるが、デコーダに知られている。例えば、これらのマーカーは、コーデックの設計中に固定することもできるし、又はビットストリームにおいて明確に指示することもできる。このケースでは、デコードされた記号は、マッピングテーブルに位置される。記号のインデックスは、前記式に使用されるＥＯＢoffsetの値を与える。例えば、記号「９」がデコードされる場合には、以下のテーブル３の例によれば、ＥＯＢoffset＝１である。前記一次式の使用により、ｘ及びｙの値を決定することができる。
【表３】
2009510962.tif 000008
【００７２】
本発明の１つの特定の実施形態において、大きさ情報を組み込んだＥＯＢ記号が連続する。このケースでは、記号をデコードした後に、第１のＥＯＢ記号が、そのデコードされた記号から差し引かれ、ＥＯＢoffsetを与える。ＥＯＢの連続値の例がテーブル４に示されている。このケースでは、ＥＯＢ記号「９」がデコードされた場合に、値「６」が差し引かれて、ＥＯＢoffset＝３を与える。
【表４】
2009510962.tif 000009
【００７３】
本発明の別の実施形態では、大きさ情報を含むＥＯＢ記号は、連続的であるだけでなく、第１の「不法」ラン長さからスタートする。例えば、ブロックが１６個の係数を含むが、１０個の係数が既に処理されている場合には、次の非ゼロ値までのゼロの最大「ラン」が５である。長さが６以上の「ラン」の発生が考えられない場合には、６個以上の記号が「不法」と考えられる。この状況では、大きさ情報を含むＥＯＢ記号は、６からスタートして順次に番号付けされる。この実施形態では、所与のＥＯＢoffsetに使用される記号がブロックごとに変化してもよい。
【００７４】
本発明の別の実施形態では、ＥＯＢを指示し且つ１より大きな大きさを指示しない記号は、第１の不法記号により境界定めされる。例えば、１より大きな大きさがなく且つ２つの係数がコード化されるべくブロック内に残っているＥＯＢを指示するのに記号「５」が指定される（したがって、「３」が第１の不法記号である）場合には、１より大きな大きさの係数をもたないＥＯＢを指示するのに「５」ではなく記号「３」が使用される。
【００７５】
本発明の更に別の実施形態では、１より大きな大きさを示す第１のＥＯＢ記号は、コード化されるべく残っている係数の数が、１より大きな大きさの係数をもたないＥＯＢを示す記号を越えるかどうかに基づいて、１だけシフトされる。例えば、１より大きな大きさがなく且つ５個未満の係数がコード化されるべく残っているＥＯＢを意味するために記号「５」が指定される場合には、テーブル４の「ＥＯＢ記号」列の値が１だけ増加される。
【００７６】
図８及び９は、本発明を実施できる１つの代表的な移動電話１２を示す。しかしながら、本発明は、１つの特定形式の移動電話１２又は他の電子装置に限定されないことを理解されたい。むしろ、本発明は、実質上いかなる形式の電子装置に組み込むこともでき、これらは、ラップトップ及びデスクトップコンピュータ、パーソナルデジタルアシスタント、一体化メッセージング装置、プリンタ、スキャナ、ファックスマシン、及び他の装置を含むが、それらに限定されない。
【００７７】
図８及び９の移動電話１２は、ハウジング３０、液晶ディスプレイの形態のディスプレイ３２、キーパッド３４、マイクロホン３６、イヤホン３８、バッテリ４０、赤外線ポート４２、アンテナ４４、本発明の一実施形態によるＵＩＣＣの形態のスマートカード４６、カードリーダー４８、無線インターフェイス回路５２、コーデック回路５４、コントローラ５６、及びメモリ５８を含む。個々の回路及びエレメントは、全て、例えば、ノキアの範囲の移動電話においてこの技術で良く知られた形式のものである。
【００７８】
本発明は、ネットワーク環境内でコンピュータにより実行されるプログラムコードのようなコンピュータ実行可能なインストラクションを含むプログラム製品により一実施形態で具現化される方法ステップの一般的状況において説明された。
【００７９】
一般に、プログラムモジュールは、特定のタスクを実行するか又は特定のアブストラクトデータ形式を具現化するルーチン、プログラム、オブジェクト、コンポーネント、データ構造、等を含む。コンピュータ実行可能なインストラクション、関連データ構造、及びプログラムモジュールは、ここに開示する方法のステップを実行するためのプログラムコードの例を表わす。このような実行可能なインストラクション又は関連データ構造の特定シーケンスは、このようなステップにおいて説明されるファンクションを具現化するための対応するアクションの例を示す。
【００８０】
本発明のソフトウェア及びウェブの具現化は、種々のデータベースサーチステップ、相関ステップ、比較ステップ、及び判断ステップを実行するためのルールベースのロジック及び他のロジックを伴う標準的なプログラミング技術で達成することができる。又、この説明及び特許請求の範囲で使用する「コンポーネント」及び「モジュール」という語は、１行以上のソフトウェアコードを使用する具現化、及び／又はハードウェア具現化、及び／又は手動入力を受け取るための装置を包含することに注意されたい。
【００８１】
本発明の実施形態の以上の説明は、例示及び説明のためのものである。これは、本発明を余すところなく説明するものでもないし、又、ここに開示した正確な形態に制限するものでもなく、前記教示に鑑み又は本発明を実施することから、種々の変更や修正が可能であろう。前記実施形態は、本発明の原理及びその実際の応用を説明するために選択され、記述されたもので、当業者であれば、種々の実施形態において本発明を利用し、且つ意図された特定の用途に適するように種々の変更をなすことができるであろう。
【図面の簡単な説明】
【００８２】
【図１】各記号に必要なビットの数を、３つの異なる可変長コードに対してデコードされるべき値を含まないブロックの確率と比較するグラフである。
【図２】本発明の一般的なエンコード／デコードプロセスを示すフローチャートである。
【図３】図２のフローチャートにおいて現在の可変長コードを更新するための第１の例示的プロセスを示すフローチャートである。
【図４】図２のフローチャートにおいて現在の可変長コードを更新するための第２の例示的プロセスを示すフローチャートで、各４つ目のコードワードの後に更新を行うところを示すフローチャートである。
【図５】図２のフローチャートにおいて現在の可変長コードを更新するための第３の例示的プロセスを示すフローチャートで、観察された記号の数が８を越えるまで可変長コードの初期値を指定するところを示すフローチャートである。
【図６】ｐ(０)＜ｐ(１)である場合にシステムがデコードの後に記号ベクトルを「ビットフリップ」する本発明のエンコード／デコードプロセスを示すフローチャートである。
【図７】エンコード／デコードプロセスにバッファフラッシュが含まれた本発明のエンコード／デコードプロセスを示すフローチャートである。
【図８】本発明の原理を組み込むことのできる電子装置の斜視図である。
【図９】図８の電子装置の回路を示す図である。
【図１】
2009510962.tif 000010
【図２】
2009510962.tif 000011
【図３】
2009510962.tif 000012
【図４】
2009510962.tif 000013
【図５】
2009510962.tif 000014
【図６】
2009510962.tif 000015
【図７】
2009510962.tif 000016
【図８】
2009510962.tif 000017
【図９】
2009510962.tif 000018
【国際調査報告】
2009510962.tif 000019
2009510962.tif 000020
2009510962.tif 000021