(57)【要約】ＭＰＥＧビデオデータにおけるＤＣＴ係数の可変長復号が、標準のプロセッサ（４００）と小さなルックアップテーブル（ＬＵＴ５３０）とを使用して実行される。上記プロセッサは、入力されたビットストリーム（ＢＳ）の一部に対して整数／浮動小数点変換を実行する（５２０）。このステップにより、コードブックにおいては普通であるような多数の先行する零を伴う長いコードワードが、浮動少数点の結果（ＦＰ）の指数及び仮数フィールド（ＥＸＰ、ＭＡＮ）により圧縮された形態で表される。関連するビットが抽出されて、上記ＬＵＴをアドレス指定するインデックス（ＩＸ）として使用される。これは、面倒なビット指向のロジックを回避する一方、さもなければ同じコードブックを表すために必要とされるであろう非常に大きなＬＵＴも回避する。このように、全ＬＵＴはキャッシュメモリ（４１０）内に存在し得る。VLIWプロセッサ構成においては、一つのトークンの復号は、先行するトークン（又は複数のトークン）の逆走査及び逆量子化ステップとパイプライン化される。
2005506777.tif 000002
【特許請求の範囲】
【請求項１】
可変長符号化ビットストリームを復号する方法において、該ビットストリームは異なる長さのトークンの連結を有し、前記符号化ビットストリームの連続する部分から復号値を得るためにルックアップテーブルが使用され、前記符号化ビットストリームにおける長いトークンは同一の先行する文字（“１”又は“０”）の列により特徴付けられ、前記符号化ビットストリームの前記部分は前記ルックアップテーブル用のインデックスを得るために前処理され、該前処理のステップは、実効的に前記列を前記先行する文字の列の長さを表す固定長のフィールドと置換して、前記インデックスを前記トークンの最大長より少ないビットを用いて規定することを特徴とする方法。
【請求項２】
請求項１に記載の方法において、前記各トークンが単一のルックアップ処理により復号されることを特徴とする方法。
【請求項３】
請求項２に記載の方法において、前記トークンの前記前処理は指数＋仮数フォーマットへの変換を含むことを特徴とする方法。
【請求項４】
請求項３に記載の方法において、該方法が、
（ａ）前記符号化ビットストリーム内で発生し得るトークンに対応する復号値を含むエントリを有するようなルックアップテーブル（ＬＵＴ）を設けるステップと、
（ｂ）前記符号化ビットストリームの一部を入力するステップと、
（ｃ）前記入力された部分を指数及び仮数成分に変換するステップと、
（ｄ）前記指数及び仮数の部分を前記ルックアップテーブル（ＬＵＴ）内の特定のエントリを識別するためのインデックスとして使用して、前記符号化ビットストリームの前記入力された部分に含まれる可変長符号化トークンに対応する復号値を抽出するステップと、
（ｅ）前記ＬＵＴのエントリを使用して次の可変長トークンの開始位置を識別すると共に、前記ビットストリームの更なる部分を必要なだけ読み取りながらステップ（ｃ）及び（ｄ）を繰り返して、終了トークンが復号されるまで連続するトークンを復号するステップと、
を有することを特徴とする方法。
【請求項５】
請求項２、３又は４に記載の方法において、前記可変長トークンは前記指数及び仮数フォーマットへの変換に先立ち選択的に反転されて、先行する“１”を伴うトークンを先行する“０”を伴うトークンに変換することを特徴とする方法。
【請求項６】
請求項１ないし５の何れか一項に記載の方法において、複数のルックアップテーブルが設けられ、前記ビットストリームの復号される部分の所定の特徴に応じて選択されることを特徴とする方法。
【請求項７】
請求項１ないし６の何れか一項に記載の方法において、所定の整数／浮動小数点変換演算を有するプログラマブルプロセッサを用いて実行され、前記前処理ステップが前記ビットストリームの一部を前記所定の演算を使用して整数から浮動小数点フォーマットに変換するステップを含んでいることを特徴とする方法。
【請求項８】
請求項１ないし７の何れか一項に記載の方法において、或るトークンの復号が前に復号された値の後続の処理ステップと同時に実行されるようにパイプライン処理が実施されることを特徴とする方法。
【請求項９】
請求項１ないし８の何れか一項に記載の方法において、次のトークンの開始位置が前記ＬＵＴの各エントリ内のトークン長フィールドから導出されることを特徴とする方法。
【請求項１０】
請求項１ないし９の何れか一項に記載の方法において、前記ＬＵＴのエントリが当該方法の後続の処理を変更するために使用されるような制御フラグを含んでいることを特徴とする方法。
【請求項１１】
可変長符号化ビットストリームを復号する装置において、該ビットストリームは異なる長さのトークンの連結を有し、前記符号化ビットストリームにおける長いトークンは同一の先行する文字（“１”又は“０”）の列により特徴付けられ、当該装置が、
−  ルックアップテーブルを記憶する手段と、
−  前記符号化ビットストリームを表すデータの連続する部分を入力する手段と、
−  前記入力されたデータに応答して前記テーブルをアドレス指定し、これにより前記符号化ビットストリームの連続する部分から復号値を得る手段と、
−  前記符号化ビットストリームの前記部分を前処理して前記ルックアップテーブル用のインデックスを得る手段であって、該前処理のステップが、実効的に前記列を前記先行する文字の列の長さを表す固定長のフィールドと置換して、前記インデックスを前記トークンの最大長より少ないビットを用いて規定するような手段と、
を有していることを特徴とする装置。
【請求項１２】
請求項１１に記載の装置において、前記各トークンが単一のルックアップ処理により復号されることを特徴とする装置。
【請求項１３】
請求項１２に記載の装置において、前記トークンの前記前処理は指数＋仮数フォーマットへの変換を含むことを特徴とする装置。
【請求項１４】
請求項１３に記載の装置において、前記前処理する手段が、
（ａ）前記入力された部分を指数及び仮数成分に変換する手段と、
（ｂ）前記指数及び仮数の部分を前記ルックアップテーブル（ＬＵＴ）内の特定のエントリを識別するためのインデックスとして使用して、前記符号化ビットストリームの前記入力された部分に含まれる可変長符号化トークンに対応する復号値を抽出する手段と、
（ｃ）前記ＬＵＴのエントリを使用して次の可変長トークンの開始位置を識別すると手段と、
を有し、前記（ａ）及び（ｂ）の手段は、終了トークンが復号されるまで連続するトークンを復号するよう繰り返し動作するように構成されていることを特徴とする装置。
【請求項１５】
請求項１２、１３又は１４に記載の装置において、前記前処理する手段は、前記可変長トークンを前記指数及び仮数フォーマットへの変換に先立ち選択的に反転して、先行する“１”を伴うトークンを先行する“０”を伴うトークンに変換するように動作することを特徴とする装置。
【請求項１６】
請求項１１ないし１５の何れか一項に記載の装置において、前記アドレス指定する手段により前記ビットストリームの復号される部分の所定の特徴に応じて選択される複数のルックアップテーブルが設けられることを特徴とする装置。
【請求項１７】
請求項１１ないし１６の何れか一項に記載の装置において、前記手段は所定の整数／浮動小数点変換演算を有するプログラマブルプロセッサにより実施化され、前記前処理が前記ビットストリームの一部の前記所定の演算を使用いた整数から浮動小数点フォーマットへの変換を含んでいることを特徴とする装置。
【請求項１８】
請求項１１ないし１７の何れか一項に記載の装置において、或るトークンの復号が前に復号された値の後続の処理ステップと同時に実行されるようにパイプライン処理が実施されることを特徴とする装置。
【請求項１９】
請求項１１ないし１８の何れか一項に記載の装置において、次のトークンの開始位置が、動作時に、前記ＬＵＴの各エントリ内のトークン長フィールドから導出されることを特徴とする装置。
【請求項２０】
請求項１１ないし１９の何れか一項に記載の装置において、前記ＬＵＴのエントリが、動作中の当該装置の後続の処理を変更するために使用されるような制御フラグを含んでいることを特徴とする装置。
【請求項２１】
プログラマブルプロセッサに、請求項１ないし１０の何れか一項に記載の方法のステップを実行させるか、又は請求項１１ないし２０の何れか一項に記載の装置を実施化させるようなプログラム命令が記録された記録担体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、可変長コードを使用して符号化されたデジタルデータストリームを復号する方法及び装置に関する。本発明は、ＭＰＥＧストリームのような圧縮されたビデオビットストリームを汎用マイクロプロセッサ又はＤＳＰ（デジタル信号プロセッサ）チップを用いて復号する場合に特別な用途を有する。本発明は、テキスト、オーディオ及び音声圧縮を含むような一連の環境においてデータ圧縮に使用される可変長符号化方法にも等しく適用することができる。本説明は、例示のみとしてＭＰＥＧ復号を参照する。
【背景技術】
【０００２】
ＭＰＥＧビデオ圧縮規格は、動画シーケンスを描くために必要とされるデータの量（及び、結果として伝送ビットレート）を低減するために動き補償ブロック型変換符号化を使用する。ＭＰＥＧ画像フレームの構築ブロックはマクロブロックであり、斯かるマクロブロック内ではピクセルデータが８ｘ８ピクセルのブロックで符号化される。輝度及びクロミナンスデータは別のブロックとして処理される。
【０００３】
通常、典型的な画像の隣接ピクセルは高度に相関される傾向にある。ＭＰＥＧ符号化は、ランダムさを、ＤＣＴ係数として知られている少数の相関除去されたパラメータに集中させるために、各ブロックに離散コサイン変換（ＤＣＴ）を適用する。次いで、８ｘ８マトリクスの係数は、予め規定されたビットレート及びビデオ品質パラメータの境界内で、符号化のために要するビットの数を低減し、特には、ＤＣＴ係数のうちの可能な限り多くを零に低減するために量子化される。
【０００４】
ランレングス符号化の効率的な使用を可能にするために、８ｘ８マトリクスの６４個の係数は“ジグザグ”又は他の走査パターンにより値のシーケンスに再配列され、これにより零及び小さな値の係数が大きな値の１の係数に後続する傾向となるようにし、該シーケンスを零がランレングス（連続する零の数）とレベル（零のランに続く最初の非零の値）とを表す一対の数により表されるように符号化する。これらの対は可変長符号化（ＶＬＣ）と呼ばれる処理により、最も確率の高い発生のものには最短のコードが付与される一方、最も確率の低い発生のものには最長のコードが付与されるように（コードワード）符号化された“ハフマン”符号化トークンに変換される。特に発生しそうにないトークンはエスケープシーケンス（ＥＳＣ）で符号化される。また、当該シーケンスにおける加重係数により後続されない全ての零は、完全に削除され、エンドオブブロック（ＥＯＢ）トークンにより置換される。従って、ビデオの固定サイズのアレイは、可変長のビットのストリーム（典型的には元のサイズの僅かな割合）に変換される。
【０００５】
予測可能な伝送レート及び／又はビデオ品質を維持するために更なる特徴も使用されるが、これらの詳細は当該出願のためには必要がない。ＭＰＥＧの動きに関係する特徴も、当該改善されたＶＬＤには関係しないので説明されていない。
【０００６】
ビットストリームの復号は、一般的に、符号化に使用されるステップの逆処理を使用する。フレーム間デコーダは、入力ストリームバッファ、可変長デコーダ（ＶＬＤ）、逆量子化器、逆離散コサイン変換（IDCT）及び出力インターフェースを必要とする。しかしながら、再生ビデオレートを固定する必要があるので、時間の制約が存在する。ＶＬＤはソフトウェア型ＭＰＥＧデコーダで実施化するのは高価となる。というのは、斯かるＶＬＤは、可変長コードからＤＣＴ係数への入力ビットレートまでもの速度における変換を伴う、ビット単位で動作しなければならないからである。ＶＬＤデコーダは、可変長コード間の境界がランダムであり整列されていないので、全てのビットを調べる必要がある。ハードウェアデコーダはビット毎に動作するように設計することができるものの、汎用プロセッサは８、１６、３２又は６４ビットの固定のグループに対して動作するように設計されており、これらの境界を考慮しない演算は極端に非効率的となる。
【０００７】
処理の障害を克服するための既知の方法は、例えば、並列処理、専用のロジックアレイ、又は頻繁に使用されるデータの非常に高速なメモリへのキャッシュ処理を使用することである。しかしながら、これらの解決策はＭＰＥＧストリーム復号に対する最も有効な解決策を提供するものではない。というのは、これら解決策は、キャッシュの機能停止（ストール）及びエスケープシーケンスのような低い確率の事象の結果を克服しないからである。並列処理は、ＶＬＤデコーダの場合は困難である。何故なら、各トークンの復号は、当該トークンの開始位置が、最初は長さが未知であるような前のトークンの復号により決定されるまでは開始することができないからである。
【０００８】
共にＬＳＩロジックコーポレーションに譲渡された米国特許第6,101,221号及び米国特許第6,122,316号は、目的に沿って設計された（“ハードウェア型の”）ＭＰＥＧデコーダシステムを記載している。特に、最初の文献は種々のステートマシンによる“シンボル抽出”を記載している。ＶＬＤのためのデータの記憶のために“浮動小数点”レジスタが使用されると言われているが、これはレジスタのサイズを参照しているだけで、本発明に関連して以下に述べる前処理との如何なる類似性も参照してはいないと理解される。特に、“シンボル抽出器”又はＶＬＤは“ＣＰＵの相互作用なしで”動作するように設計されている。トライメディアTM1100及びTM1200 VLIWプロセッサのような幾つかの高性能プロセッサは、専用のＶＬＤハードウェアを含んでいるが、他のものはそうではない。
【０００９】
ＭＰＥＧ復号処理の当該部分の実施化に関する更なる提案が、IEICEトランザクション、ファンダメンタルズ、第E84-A巻、第１２号（２００１年１２月）、第3146〜3151頁の“ソフトウェアMPEG-2デコーダ用の逆量子化による並列可変長復号”においてDaiji Ishii他によりなされている。この提案においては、一時にビットストリームの１７ビットを用いてＶＬＥトークンを復号するためにルックアップテーブル（ＬＵＴ）が使用される。第１テーブルは、短いトークンの同時的対（これらが見付かった場合）を復号するために使用される。第２テーブルは長いトークンを復号するために使用される。長いトークンは一般的に１又は０のランで開始するので、２１７のエントリを有するテーブルは実際には必要がないことを認識して、上記第２ＬＵＴは、複数の小さなテーブルに分割される。
【００１０】
分割されたＬＵＴを使用する処理の詳細について、Ishii他は、単にReza Hashemian：IEEEトランザクション、コンシューマエレクトロニクス、第４０巻、第３号、第３４５〜３５２頁、１９９４年８月の“メモリ効率的ハフマン復号の設計及びハードウェア構成”を参照している。Hashemianは、４ビットの小さな“クラスタ”が第１副テーブル（該テーブルのエントリは、所望の復号値又は他の副テーブルへのポインタの何れかを明らかにする）に対するインデックスとしてどの様に使用されるか、及びビットストリームのどれだけ多くの更なるビットが上記他のテーブルにアクセスするためのインデックスとして使用されるべきかを説明している。上記の他の副テーブルは再び所望の出力、又は更なる他の副テーブルに対する参照を生じ得る。この処理は、必要とされるＬＵＴの全体のサイズの大幅な低減を達成するが、特にソフトウェアの実施化に変換される場合に、かなり面倒である。上記Ishiiの文献には、上記第２ＬＵＴが“１つの長いコードワードの１つのルックアップ動作による復号を可能にする”と述べられている。しかしながら、Hashemianにより実際に提案された処理を参照すれば、ビットストリームの内容に依存して、単一のトークンを復号するのに１、２、３又は４回さえのルックアップが必要とされることは明らかである。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
本発明の目的は、ＶＬＤ機能のための改良された方法及び装置であって、特には、利用可能な汎用マイクロプロセッサ又はＤＳＰのプログラミングにより専用のハードウェア無しで効率的に実施化することが可能なものを提供することにある。
【課題を解決するための手段】
【００１２】
本発明の一態様によれば、可変長符号化ビットストリームを復号する方法であって、該ビットストリームは異なる長さのトークンの連結を有し、前記符号化ビットストリームの連続する部分から復号値を得るためにルックアップテーブルが使用され、前記符号化ビットストリームにおける長いトークンは同一の先行する文字（“１”又は“０”）の列により特徴付けられ、前記符号化ビットストリームの前記部分は前記ルックアップテーブル用のインデックスを得るために前処理され、該前処理のステップは、実効的に前記列を前記先行する文字の列の長さを表す固定長のフィールドと置換して、前記インデックスを前記トークンの最大長より少ないビットを用いて規定することを特徴とするような方法が提供される。ルックアップテーブルは原理的によく知られているが、最長のトークンを直接復号するのに要するテーブルのサイズは、非常に大きい。典型的な処理システムは自身の高性能を達成するためにキャッシュメモリに依存する一方、上記のような大きなテーブルは斯かるキャッシュ内に存在するには大きすぎるので、ルックアップ方法は許容可能な性能を果たさないであろう。
【００１３】
発明者は、典型的なＶＬＣコードブックはトークンの最大長により暗示される数値範囲の僅かな割合しか占有せず、斯かるコードブックの非常に効果的な“圧縮”を時には実施することができることに気が付いた。この場合、復号ステップは、特に徹底的な計算ではなく比較的小さなルックアップテーブルで実行することができ、典型的なコードブックにおける長いトークンは同一の文字の列（特には多くの先行する零）により特徴付けられる。このような場合において、発明者は、上述したような圧縮効果を、現代のプロセッサ内の最適化されたハードウェアにより既に得られている浮動小数点変換を用いて達成することができると共に、単一のルックアップ処理により実行することができることに気が付いた。
【００１４】
従って、前記トークンの前処理は指数＋仮数フォーマットへの変換を有することができる。他の例として、上記前処理は他の手段により同一の先行するシンボルのカウントを導出するステップを有することができる。異なるプロセッサは、これらのオプションを異なる程度にサポートし、実施化の選択に影響を与える。
【００１５】
好ましい実施例において、本方法は、
（ａ）前記符号化ビットストリーム内で発生し得るトークンに対応する復号値を含むエントリを有するようなルックアップテーブル（ＬＵＴ）を設けるステップと、
（ｂ）前記符号化ビットストリームの一部を入力するステップと、
（ｃ）前記入力された部分を指数及び仮数成分に変換するステップと、
（ｄ）前記指数及び仮数の部分を前記ルックアップテーブル（ＬＵＴ）内の特定のエントリを識別するためのインデックスとして使用して、前記符号化ビットストリームの前記入力された部分に含まれる可変長符号化トークンに対応する復号値を抽出するステップと、
（ｅ）前記ＬＵＴのエントリを使用して次の可変長トークンの開始位置を識別すると共に、前記ビットストリームの更なる部分を必要なだけ読み取りながらステップ（ｃ）及び（ｄ）を繰り返して、終了トークンが復号されるまで連続するトークンを復号するステップと、
を有する。
【００１６】
上記可変長トークンは指数及び仮数フォーマットへの変換に先立ち選択的に反転して、先行する“１”を伴うトークンを先行する“０”を伴うトークンに変換することができる。
【００１７】
前処理は、復号されるビットストリーム部分の特徴に従い異なるように実行することができる。また、上記ビットストリームの復号される部分の所定の特徴に応じて選択される複数のルックアップテーブルを設けることができる。
【００１８】
ＭＰＥＧにおいては、例えば、幾つかの可変長コードは先行する“零”というよりは先行する“１”を用いて符号化される。前記浮動小数点変換は、上記トークンを変換器に入力する前に反転すれば、依然として使用することができる。このような場合において使用するために、トークンの組の特性に応じて別個のルックアップテーブルを設けることもできる。
【００１９】
プログラマブルプロセッサを使用することができる。斯かるプログラマブルプロセッサはパイプライン化された処理を含むことができ、該処理においては、復号の異なる処理が同時に実行される。該プログラマブルプロセッサは所定の整数／浮動小数点変換演算を有することができ、その場合において、前記前処理ステップは前記ビットストリームの一部を上記所定の演算を使用して整数から浮動小数点フォーマットに変換するステップを含む。
【００２０】
一実施例においては、一つのトークンの復号が前に復号された値の後続の処理ステップと同時に実行されるようにパイプライン処理が実施される。復号ステップの簡単なパイプライン化は可変長コードの場合は可能ではない。何故なら、各トークンの位置が、前のトークンが復号されるまで分からないからである。例えばＭＰＥＧデコーダにおいては、各ＤＣＴ係数の再配列及び逆量子化を、次のトークンの復号と同時に開始することができる。
【００２１】
上記ＬＵＴのエントリから抽出された復号値は、当該ビットストリームの更なる処理を決定し、最終的な復号値を得るために使用することができる。例えば、ＭＰＥＧ ＶＬＣにおいては、復号されるべきトークンはエスケープトークンであり得、このトークンは復号値が、当該ビットストリーム自身内の該エスケープトークンに続いて見つけられるであろうことを意味する。
【００２２】
本方法は、ＬＵＴエントリから抽出された復号値をビットストリームの更なる部分に応答して変更するステップを更に有することができる。例えばＭＰＥＧ ＶＬＣにおいては、殆どのトークンは、ランレベル対のレベル成分が否定されるべきことを示す符号ビットで終了する。該符号ビットをＬＵＴインデックスとは別に扱えば、テーブルのサイズを半分にすることが可能になる。
【００２３】
次のトークンの開始位置は、各ＬＵＴエントリ内のトークン長フィールドから導出することができる。また、各ＬＵＴエントリは、当該方法の後続の処理を変更するために使用される制御フラグを含むことができる。
【００２４】
更に、本発明は可変長符号化ビットストリームを復号する装置であって、上述した及び更に添付請求項に記載された本発明による方法のステップを実行するように構成された手段を有するような装置を提供する。
【００２５】
本発明の利点は、汎用プロセッサハードウェアの適切なプログラミングにより実施化することができる一方、必要なプログラミングコードから別途供給することができる点にある。従って、本発明は更に、プログラマブルプロセッサに上述した本発明の方法のステップを実施させるプログラム命令が記録された記録担体又はデータ記憶の他の装置も提供する。
【発明を実施するための最良の形態】
【００２６】
以下、本発明の実施例を、添付図面を参照して例示として詳細に説明する。
【００２７】
本発明の実施例を詳細に説明する前に、本発明は用途が図面における構成及び記載又は図示の細部に限定されるものではないと理解されるべきである。本発明は、種々の他の態様で実施することもできる。また、ここで使用される語句及び用語は説明の目的のためのもので、限定するものと見なしてはならないと理解すべきである。
【００２８】
本発明は、ＣＤ−ＲＯＭ及びＤＶＤ媒体に記録され又は有線若しくは無線チャンネルにより伝送されるようなＭＰＥＧビデオデータストリーム用の標準のデコーダの場合において説明されるであろう。ＭＰＥＧビデオ仕様（ITU-T H.262）は、ＭＰＥＧ符号化されたビデオデータを伸張するために要する機能を正確に規定しているが、どの様に実施化されるべきか詳細には規定しておらず、これは製造者に任されている。
【００２９】
ＭＰＥＧ仕様によれば、動画シーケンスを処理するために２つの重要な符号化技術が使用される。即ち、フレーム内符号化及び非フレーム内（フレーム間）符号化である。両型式のフレームは、当該ビデオシーケンスの各個別画像内に含まれる情報に対して実行される種々の損失のある及び無損失の圧縮技術を採用している。非フレーム内符号化は、更に、動き推定を用いた予測のような画像間の時間的可干渉性を利用し、予測（Ｐ）フレーム及び双方向予測（Ｂ）フレームを発生する。本発明は動きの特徴に関係はないので、非フレーム内符号化の属性はこれ以上詳細には説明しないであろう。
【００３０】
図１はＭＰＥＧデコーダのステップを示し、ビットストリームバッファ１００、可変長デコーダ（ＶＬＤ）１１０、逆走査（ＩＳ）及び逆量子化器（ＩＱ）１２０、逆離散コサイン変換(IDCT)１３０、動き補償器（ＭＣ）１４０及び出力インターフェース１５０を有している。該デコーダは、専用のハードウェアで、又はプロセッサにより一連の処理ステップとして、又は両者の組み合わせにより実施化することができる。本開示は、これらのステップ、特にＶＬＤ及びＩＳ／ＩＱステップが、マイクロプロセッサ（もっとも、該マイクロプロセッサはＶＬＩＷ又は画像処理用に最適化された他のプロセッサとすることもできる）をプログラミングすることにより実施化されると仮定している。
【００３１】
図示したステップの動作は下記の通りである：
・  １００における入力ビットストリームバッファ処理は、ビデオストリームを入力すると共に、時間柔軟性のある行列を形成して後続の処理ステップが該ビデオを入力ビデオレートとは相違するレートで復号するのを可能にするためのものである。この時点で、オーディオ及び他のデータは分離し、自身のデータに導くことができる。
・  １１０における可変長復号は、可変長ＭＰＥＧトークンを、量子化されたＤＣＴ係数のような対応する値に変換するためのものである。
・  １２０における逆量子化は、選択された量子化及びスケールファクタマトリクスの値に従ってＤＣＴ係数の実際の値を求め、逆走査ステップは、トークンのストリームから所定のシーケンス（通常はジグザグ）に従って係数マトリクスを再形成する。
・  逆離散コサイン変換ステップ１３０は、ＤＣＴ係数を、斯かる係数が表すピクセル値のブロックに再生するためのものである。
・  当該画像が非イントラ符号化されている場合、動き補償が１４０において実行されて、復号されたピクセル値に当該画像シーケンスにおける隣接する画像からの値を組み合わせる。
・  １５０においては出力インターフェース処理が行われて、当該ビデオを、例えばメモリ内の二次元ビデオ画像又はデジタルビデオストリームのような適切なフォーマットで表す。
【００３２】
図２は、ＶＬＤ１００がどの様な処理を可変長トークン２０１〜２１２の例示的ビットストリーム２００に対して実行して、これらトークンをランレングス及びレベルのシーケンス２２０に変換し、次いで逆走査関数ＩＳを使用して、これらシーケンスを逆“ジグザグ”走査して８ｘ８係数マトリクス２３０を得、次いで斯かるマトリクスを逆量子化器（ＩＱ）に渡さねばならないかを示している。
【００３３】
入力ビットストリーム２００は単に１及び０の列を有している。所望の係数のブロック２３０は一連の１２のトークン２０１ないし２１２により表される。トークンの境界が示されているが、デコーダは、最初は斯かる境界が何処にあるか分からず、各係数のブロックを表すために幾つのトークンが存在するかも分からない。しかしながら、当該シーケンスの始点は前後状況から分かり、前のトークンが一旦認識（少なくとも部分的に復号）されたら各トークンは見付けることができる。ＭＰＥＧ仕様H.262はテーブルB.14を有し、該テーブルは、この例におけるトークン及び斯かるトークンの意味を定義している。他のテーブルB.15及びB.16は異なる状況における使用のために設けられている。
【００３４】
図示の例において、ＶＬＤ処理１１０は、トークン２０１〜２１２を復号された係数シーケンス２２０に変換し、ブロック２３０を規定されたジグザグシーケンス（図に矢印で示される）で走査する。トークン２０１〜２１０は、各々、（量子化された）値８、４、４、等の単一の係数を表す。一方、トークン２１１は、１により後続される１２の零のランを表す。最後の非零係数の後には４１個の零が存在し、これらは全て特別な“ブロック終了”コードＥＯＢを有するトークン２１２により表される。最も一般的な値及びランは前記テーブルに規定された自身のトークンを有し、トークンの長さは、値が典型的な画像において余り一般的でなくなるにつれて増加する。一層希な値又はランは、特別な“エスケープ”トークン（ＥＳＣ）に続いて、明示的に表すことができる。ＭＰＥＧテーブルＢ１４における最長のトークンは、１６ビット長に符号ビットを足したものである。当該例においては、各々が少なくとも４ビットに量子化された６４の係数が、可変長コードにより６１ビットのみに圧縮されている。圧縮の正確な程度は、画像の内容及び適用される量子化の程度に依存する。
【００３５】
動き推定はエンコーダ側では特に挑戦的なものであるが、ＶＬＤ１１０はソフトウェア型構成のデコーダにおける典型的に最も計算的に厳しい部分である。というのは、ＶＬＤはビット毎に動作するからである。汎用プロセッサは、可変長トークン間の境界がランダムであり、メモリ内のバイト及びワード境界に整列されていない場合、ビットストリームの全ビットを監視するようには適応されていない。ＶＬＤプロセッサ１１０は、８ｘ８係数マトリクスを再形成するために、ＭＰＥＧ規格に規定されているように、各トークンに対応する係数データを生成するために入力ビットレートまでもの速度で動作しなければならない。
【００３６】
従来、斯かる速度でＶＬＤを実行することを要するアルゴリズムは、プロセッサに対する付加を低減するためにハードウェアでサポートされていた（もっとも、プロセッサへの付加が問題とならない場合はソフトウェア構成が使用される）。スループットを増加させる１つの方法は、複雑な高速ロジック関数、ステアリングロジック及び並列処理を使用することである。斯様な一例は米国特許第6,101,221号に示され、該特許は可変長トークンがクロックサイクル毎に復号されるような速度で、可変長オブジェクトを有する固定長データワードを復号するシステム及び方法を記載している。該例は、複数のレジスタ及び複雑なデータステアリングロジックを並列構成のマルチプレクサ及びIDCTプロセッサとの組み合わせで使用して処理を効果的にパイプライン化することにより、デコーダのスループット率の増加を達成している。多くの可変長トークンを同時に処理することによりデコーダのスループットを増加させても、係数のランレングス及びレベルデータを可変長トークンから導出する方法及び装置に対しては何の改善もなされない。この技術のソフトウェア構成は推奨されておらず実施可能でもない。
【００３７】
図３は汎用プロセッサ４００を示し、該プロセッサは自身とプロセッサメモリ４２０との間にキャッシュ４１０を採用している。ＣＰＵ４００は、ＰＣワークステーションの主プロセッサでもよく、又はＭＰＥＧ復号専用の又はビデオ処理全般を専門とする補助プロセッサでもよい。上記プロセッサ及びメモリは、他の例として、ＤＶＤプレーヤ又はゲームコンソールのような専用ＭＰＥＧプレーヤの一部を形成することもできる。ＣＰＵ４００は、少なくともＶＬＤ処理を実行するものと仮定するが、好ましくは、図１の復号処理全体が該プレーヤ内で実行されるものとする。これを説明するために、該図はビデオビットストリームＩＮ４３０が当該プロセッサに入力されるのを示している。もっとも、メモリへのＤＭＡ転送のように、データを入力するための他の方法でも充分であろう。同様に、上記メモリから出力されるビデオ出力ＯＵＴ４４０が示されている。もっとも、実際には該データを読み取り、フォーマットし、及び出力するためのプロセッサの相互作用が必要であろう。動作時において、プログラム、入力データ及びＣＰＵにより発生された復号画像は主メモリ４２０に保持される。しかしながら、良く知られているように、頻繁に使用されるデータ又は処理ステップは、斯かるデータ又は処理ステップが遅いメモリ４２０から得られるよりも優先的に、上記キャッシュから取り出される（利用可能な場合）。ここで述べるＶＬＤ処理を実施化するための当該プロセッサ用のプログラムコード（命令）は、事前にインストールされる（ファームウェア）か、又はＣＤ−ＲＯＭ若しくはフロッピーディスク４５０等の記録担体で別途供給することもできる。キャッシュの使用は、さもなければ主メモリの限られた帯域幅により悪化される当該プロセッサの能力を解放する。
【００３８】
前述したように、ＭＰＥＧ仕様は、ＶＬＣトークン及び斯かるトークンの対応するＤＣＴ係数ランレングス及びレベル値を定義するようなテーブルを規定している（ITU-T推奨H.262のテーブルB.12及びB.16）。トークンを直接復号する１つの方法は、上記ＭＰＥＧテーブルをメモリ内に完全にルックアップテーブルとして再生することである。該テーブルは各トークン値に対するエントリを含み、ランレングス、レベル及び当該トークンの長さ（次のトークンの始点を識別するために）を規定する。ＬＵＴは、原理的に演算及び論理処理の代替として良く知られている。残念ながら、ＭＰＥＧ可変長トークンのサイズは１６ビット（別途処理することができる符号ビットが加わる）までであり得る。斯様なテーブルを全体としてキャッシュメモリに記憶することは、２１６、即ち６５５３６エントリのキャッシュ長、を必要とする。各エントリのサイズは少なくとも２バイト、多分それ以上であろう。斯様に大きなテーブルは、大きさ故に魅力的ではなく、多くの冗長情報及び空きのエントリを有する。もっと深刻には、斯様に大きなテーブルは如何なる時点においても上記キャッシュメモリ４１０内に完全に存在することはありそうにもなく、キャッシュミス及び処理の停止の発生確率が非常に高く、キャッシュの利点を損なう。従って、ルックアップテーブルの使用は表面的には魅力的であるが、斯様な構成の性能は実際には要件を満たさない。
【００３９】
以下の段落は、一見したところ必要であろうよりも少ない量の処理及び小さなＬＵＴを使用して、可変長トークンを該トークンの対応するランレングス及びレベル値に変換する改善された方法及び装置を開示する。これは、自身で有益であるのみならず、実際のコンピュータシステムにおけるキャッシュの機能停止（ストール）又はクリア（フラッシュ）のような事象により生じる滑らかな復号の中断を低減する場合にも有益である。更なる段落は、適用例を提供して、該新たな方法及び装置を如何にしてVLIWアーキテクチャのビデオプロセッサに適用することができるか、及びビデオ処理関数の効率的なパイプライン化が如何にして効率的なＭＰＥＧデコーダを提供するかを示す。
【００４０】
図４は、改善されたＶＬＤ処理の概念図を示し、該処理は入力ステップ５１０と、トークン圧縮ステップ５２０と、テーブルルックアップステップ５３０とを有している。入力ビットストリームを含むバイトのストリームが５００において入力され、新たなトークンで開始するデータの塊が５１５において圧縮ステップ５２０に読み込まれ、復号された長さ及びレベル値又はＥＯＢ及びＥＳＣ信号がＬＵＴ５３０から読み出される。エスケープ及び符号ビットの処理は簡略化のために省略されているが、実施化するのは簡単である。次のトークンに対する入力ステップ５１０は、５４５において、ルックアップテーブル５３０から読み出されたトークン長の値に応じてビット毎に制御される。
【００４１】
以下の表１は、テーブルエントリのフォーマットの一例を示し、該テーブルの幅は限定されるものではないが３２ビットとして示されている。
【００４２】
【表１】
2005506777.tif 000003
【００４３】
ＥＯＢ及びＥＳＣコードは別個のフラグに復号され、勿論、他のフラグもＭＰＥＧ又は別の符号化システムにおいて設けることができる。
【００４４】
本例では、レベル値は単に後続の処理のために実際のレベルの２倍として記憶される。即ち、レベルの２倍の値は、逆量子化のためにＭＰＥＧにより指定される演算関数において実際に必要とされる。符号フラグは別個に復号され、全体の結果の否定が必要とされるかを決定するために調べられるが、これも当該演算を実際に簡素化した。同様の態様で、ランレベルも後続の処理ステップに適合するように修正されている。該ＬＵＴエントリ内容を当該処理に適合するように適応化させる他の形態も使用することができ、掲示した例に限られるものではない。上記テーブルエントリの各バイトは完全には使用されていないが、当該データを密に詰めると、異なるコンポーネントをほぐす場合にオーバーヘッドを生じる。トークンの圧縮ステップ（以下に更に詳細に説明する）により、上記ＬＵＴにおけるエントリの数が、個々のエントリの大きさが大きな問題とならないようなレベルに低減される。
【００４５】
トークン圧縮ステップ５２０の実施可能性及び性質は、ＶＬＣコードブック（トークンの集合）の構造に依存する。或る場合には、少々の創作的思考及びオプションとしての何らかの前又は後処理が必要とされ得る。ＭＰＥＧ ＤＣＴ係数テーブルB.14及びB.15の場合、トークンは大部分は０と１１の間の先行する零を有すると共に、２ないし６ビットのコード長に加えて符号ビットを有する。この場合、特定の例外は後述する態様で処理されると仮定して、効果的なトークン圧縮は、入力ストリームからの一群のビットの、指数及び仮数フォーマットの数を与えるような簡単な浮動小数点変換により実施することができる。これは、僅かな再調整の後、ＤＣＴ係数の小さなルックアップテーブルを索引付けして対応するランレングス及びレベルを得るのに適したフォーマットの短いトークンを生じる。上記テーブルは、テーブルエントリが、これらエントリをアドレス指定する指数値にとり合致したものとなるように構築することができる。これは、テーブルの始めが決して使用されないことを意味し得る。何故なら、指数の選択された部分は、復号しているコードシーケンスにおける先行する零のカウントの範囲に対して決して零でないからである。この場合、使用するテーブルのベースアドレスをオフセットするように選択して、実際に生じる最小の指数値が、当該テーブルにおける浪費スペース又は上記インデックスに更なる演算を実行して該インデックスに当該テーブルの適切な部分をアドレス指定させることなしに、該テーブルの最初のメモリロケーションをアドレス指定するようにする。
【００４６】
再符号化を達成するために使用される典型的な装置は、浮動小数点（２４又はそれ以上のビットの）レジスタ、整数／浮動小数点変換ブロック及びシフトレジスタである。インテル社のペンティアム（登録商標）シリーズのようなプロセッサは、勿論、浮動小数点ユニットを含んでいる。特注ＩＣ内でさえ、浮動小数点ユニットを、引用文献に示されるタイプの特別なＶＬＤハードウェアブロックを開発及び試験しなければならないことなく、“在庫”設計として含めることができる。
【００４７】
図５は、本実施例におけるトークン圧縮処理５２０の動作をビットレベルで示している。以下のステップは、整数及び浮動小数点数表現のフォーマットに関する標準の規約を用いて、標準のマイクロプロセッサ内で概ね直接的に実施することができる。
・  復号されるのを待つビットストリームの入力１６ビット“ＢＳ”（１以上の可変長トークンを含む）が、零で充填された３２ビットレジスタ“INT 32”の上位側半部に１６ビットワードとして入力される。最大トークン長は１６ビット足す符号ビットであるから、該レジスタは少なくとも１つの完全なトークン（ＴＫ１）を含むが、恐らくは後続の（複数の）トークン（ＴＫ２等）の幾らかも同様に含む。図示の例においては、ＴＫ１＝“0000101”に符号ビットｓ＝０が後続したものとなる。
・  次に、該レジスタの内容に浮動小数点変換を実行して（無符号整数／浮動小数点）、結果“ＦＰ”を得る。この時点で、IEEE規約に従い、当該トークンの先行する零の数は対応する指数値ＥＸＰに変換され、最初の“１”を除く残りのビットは固定仮数部ＭＡＮにシフトされる。図示の例では、最初の“１”は無符号整数INT 32のビット２７で出現しているので、指数は２７とする。かくして、規約により、IEEEフォーマットの指数フィールドは１２７＋２７＝１５４、即ち二進では10011010となる。プロセッサが選択を行う場合、選択される変換のモードは切り下げを行うものであるべきであり、切り上げを行うと、長いトークンが復号されている場合に有効ビットを変化させ得る。
・  結果“ＦＰ”から、上記指数（当該トークンの先行する零の数を識別する）の最下位側４ビットと上記仮数部の上位５ビット（当該トークンの最初の“１”に後続する５ビットに等しい）とを組み合わせて９ビットのインデックス値“ＩＸ”を形成する。
・  上記９ビットワード“ＩＸ”をＬＵＴに対するインデックスとして使用して、表１に示す形態の４バイトエントリ（ＥＯＢ、ＥＳＣ、ＬＶＬ、ＬＥＮ）を抽出する。
・  ＥＯＢ及びＥＳＣを適切に処理する。他のコードに関しては、入力ビットストリームＢＳの符号ビットをＬＶＬにシフト入力して、復号されたレベル値を完成させる。
【００４８】
結果は、長さが１６ビットまでのトークンは丁度９ビット長のインデックスに再符号化されるということである。仮数部の選択された５ビットは時には次のトークンの４ビットまでを含む場合があることに注意されたい。これは、このような場合のＬＵＴエントリが、次のトークンの４ビットの値に無関係に同一となるように保証することにより対処される。２９における全体のＬＵＴ、即ち最大で５１２のエントリをアクセスするために、９ビットしか必要とされないので、高速且つ低減されたメモリ要件という利点が得られる。更に、ＭＰＥＧ“復号テーブル零”仕様によれば、先行する零の数は１１を超えることはできないので、インデックスの指数（上位）部は、実際に、可能性のある１６バンクのうちの１２のみに限定され、全ての符号化エントリをサポートするために３８４のＬＵＴエントリしか必要とされないことを意味する。このテーブルの大きさは、ストールに頼ること無しに、キャッシュにより容易に扱うことができる。ＭＰＥＧ復号の該部分は、演算的に厳しいので、キャッシュメモリ内に存在する斯様な小さなＬＵＴ（約１ｋバイト）の効果的な使用は、スループットの大幅な増加となる。符号ビットは別個に処理されるので、ＬＵＴの大きさには影響を与えない。もっとも、キャッシュが充分に大きい場合は符号ビットを同時に処理しても良い。
【００４９】
同じ原理が、他の符号化構造に対しても、追加の前及び／又は後処理を伴って又は斯かる処理無しで当てはまる。上記例は、ＭＰＥＧの“復号テーブル零”（ITU-T H.262におけるB14）に当てはまる。しかしながら、ＭＰＥＧ係数の“復号テーブル１”エントリ（テーブルB15）の場合は、先行する零のトークンの中に、複数の先行する“１”を伴う幾つかのトークンが存在する。斯様な数の浮動小数点変換は、トークン空間の圧縮とはならないであろう。しかしながら、この矛盾を克服するために、例えば４等の先行する１の閾的数をチェックするために簡単な追加のテストが実行され、もしそうなら、当該可変長トークンをビット反転し、先行する零エントリを扱うものとは別のＬＵＴを使用する。このように、ＭＰＥＧ ＤＣＴ係数テーブルB15は、単一のテーブルでない場合は、１対の圧縮されたテーブルにより記述することができる。更に、本原理は、“復号テーブル零”エントリに関して上述した例に対してビットの異なる選択及びシフトを要するのみで、異なる量の先行する零及びコード長にも拡張される。
【００５０】
好ましい実施例においては、ビットストリーム内で連結された２つのトークンが、有効なトークン内における最長のランよりも長い“０”のランとなり得るような場合を防止するためにも、追加の前処理が適用される。ITU-T H.262テーブルは、“開始コードエミュレーション”として知られている問題を防止するために、全て零のシンボルは含んでいない。しかしながら、例えばテーブルB.15は、完全に９つの“１”からなるトークン（９個の“１”足す符号＝“１”）を含んでおり、該トークンには複数の“１”で始まる他のトークンが後続し得る。これらが上述したように反転されると、これは上述したように多くの零のシンボルがＬＵＴインデックスとして使用するための指数及び仮数フォーマットに変換されることになる。これを浮動小数点に直接変換すると、トークンの非常に大多数を復号するのに要する範囲を超えた指数となる。これらの状況のために大きなテーブルを設けるというよりは、該好ましい実施例は、浮動小数点変換を実行する前に、値INT32の適切なビットを強制的に設定するステップを含む。この強制された“１”ビットは、指数が予測される範囲外となるのを防止する。ＭＰＥＧ−２の表B.14及びB.15の例においては、この強制ステップは、前の段落で説明したように先行する“１”で始まるシンボルを反転した後でのみ適用される。８ビットのオール零トークン長（反転後で符号ビットはカウントしていない）を伴うＭＰＥＧ−２表B.15の場合は、マスク0x00800000を用いて簡単なＯＲ演算を実行して９番目のビット（INT32におけるビット２３）を“１”に強制設定する。
【００５１】
INT32の元の値は、ビットがシフトされ次のトークンの部分として解釈される場合に使用するために保存されねばならないことが分かる。さもなければ、上記のビットの強制が、次のトークンの復号を駄目にするであろう。
【００５２】
当業者であれば、これらのビット強制又は他の技術を、異なるコードテーブル用のデコーダを設計する場合に、指数部が範囲外になるような場合を捕捉するために適応化することができる。また、先行する“０”の数を既知の範囲内に制限するために充分なビットを強制設定することにより、損なわれたビットストリームに対して保護することも有効である。トークンを損なうのを防止するために、上記の強制設定されるビットは、通常は、有効なビットストリームで予測される先行する零の最大長よりも、最大のトークン長に配置されねばならない。これは、誤ったトークンが範囲外のインデックスを生じるのを防止するために、より大きなテーブルを設けることを要する。しかしながら、テーブルの該追加の部分は非常に希にしかアクセスされないので、通常の動作においてはキャッシュの占有又はキャッシュミスの頻度に影響を与えることはない。エラーが検出された場合は、復号は総合的に混乱するから、キャッシュミスは些細な事柄である。
【００５３】
上述した反転及び別個のテーブルの代わりに、“先行する１”のトークンの群を符号付き浮動小数点処理の使用により処理することも可能である。もっとも、明確な速度の利点を否定するかも知れないような追加のビットレベルでの処理が必要とされ得る。
【００５４】
実用的な実施例に関しては、高性能プロセッサ、特定の演算の並列実行又は“パイプライン処理”の使用が通常は魅力的である。以下に説明するように、発明者は、明らか障害にも拘わらず、ソフトウェアに基づいたＭＰＥＧデコーダにおいてパイプライン処理するための都合のよい条件を見付けた。ビデオ用途の好適なプロセッサアーキテクチャはVLIW（超長命令語）プロセッサである。もっとも、ＭＰＥＧ復号をサポートする機能を持つ如何なる並列アーキテクチャでも充分である。
【００５５】
図６は、例示としてのVLIWプロセッサの命令操作部のブロック図を示し、該プロセッサは単一の命令キャッシュ（ＩＣ）７００と、５つの発行スロット（Issue Slot）ＩＳ１〜ＩＳ５ ７１０と、５つの機能ユニット組“SFU1”〜“SFU5”７２０とを有し、各機能ユニット組は選択された機能ユニット“ＦＵ１”〜“ＦＵ１１”を含んでいる。整数算術演算、浮動小数点、シフト及びメモリ等の異なるタイプの演算に対しては異なるタイプの機能ユニットが存在する。典型的には、上記機能ユニットは、可能性のある機能の部分集合のみを含む、或る程度特化されたものであろう。例えば、１つ又は２つのユニットは分岐機能を提供することができ、他のものはメモリインターフェース機能を提供することができ、他のものは浮動小数点演算を提供することができる。
【００５６】
下記の表２は、当該例のVLIWアーキテクチャ用の機能ユニットの混合を示している。斯かる機能の正確な性質は、本発明の理解にとっては重要ではない。
【００５７】
【表２】
2005506777.tif 000004
【００５８】
図６は、命令キャッシュから命令を実際に実行する機能ユニットまでの命令の流れを表している。このプロセッサ用のコンパイラは、各タイムスロットにおいて演算を５つのグループで発生する。従って、５つまでの演算が適切な発行スロットへ同時に送出される。コンパイルの間において、上記コンパイラは最大の並列処理が達成されるように演算を編成しようとするが、所要の入力データが前の命令の実行から得られる前に命令をスケジュールすることはできない。このスケジューリングの問題はレイテンシ（待ち時間）の結果であり得る。命令のレイテンシとは、該命令の実行時から結果が利用可能となるまでの遅れである。殆どのプロセッサは、２クロックサイクル以上のレイテンシを呈する演算を有し、結果として、幾つかの演算は、続くクロックサイクルで開始する命令によっては使用することができない。
【００５９】
コンパイラを補助するために、幾つかのタスクを同時に処理することが、例えば同じ演算を幾つかのデータ項目に対して一度に実行することができる（ループ展開）。しかしながら、ＭＰＥＧビットストリーム可変長トークンの復号の場合、トークン間の境界の位置が未知であるので、第１トークンの殆どが復号されてしまうまで、第２可変長トークンの復号を開始することは不可能である。この問題は、提案された構成例においては、以下の例に示すようにＶＬＤ、ＩＳ及びＩＱ処理をパイプライン化はするが、異なる係数に対してのものとすることにより回避される。
【００６０】
図７は、適切なコンパイルにより、プロセッサの最大の利用が如何にして達成されるかを示している。３パス処理が採用され、これによりＶＬＤ、ＩＳ及びＩＱ処理は、コードの３つのラン内で全て完了する。
【００６１】
下記の表３は、３つのパスでのパイプライン化されたＶＬＤ、ＩＳ及びＩＱ処理が如何にして１０個のVLIWの５スロットサイクル内に組み込まれるかを示し、この例では可能な５０のうちの６プロセッササイクルのみが不使用となって、プロセッサ資源の非常に効率的な利用が得られている。
【００６２】
【表３】
2005506777.tif 000005
【００６３】
各演算の前の数は、当該処理ステップを経るパスに関するもので、図７の左側にも示されている通りである。図示の命令シーケンスは、内部分岐無しでループとして動作するように設計されており、３つのトークンを一度に処理する。当該コードのもっと一般化されたバージョンが、バッファのアンダーフロー、ＥＯＢ及びエスケープの場合に対処するために設けられ、ループに戻るか又はＥＯＢシンボルの後で完全に離脱するかの何れかである。
【００６４】
トークン圧縮及びＬＵＴを使用するＶＬＤと、VLIWのパイプラインアーキテクチャとの組み合わせは、効果的且つ高速なＭＰＥＧデコーダを提供する。斯様なアーキテクチャは、モーションフレーム及びオーディオの再生及び同期等の全範囲のＭＰＥＧ仕様の使用もサポートする。当業者であれば、上述した装置の原理の範囲内で多数の変形例が可能であることを理解するであろう。従って、ここで解説された実施例は理解を補助するための例として提示されたものであって、請求項に記載される本発明の趣旨及び範囲を限定しようとするものではないと理解されるであろう。更に、当業者であれば、本発明がオーディオ、ビデオ、音声及び一般のデータ圧縮における種々のアプリケーションにおいて、可変長コードを復号する如何なる他の方法又は装置にも適用することができることを理解するであろう。
【図面の簡単な説明】
【００６５】
【図１】図１は、本発明による可変長デコーダ（ＶＬＤ）を組み込んだＭＰＥＧビデオデコーダの機能ブロック図である。
【図２】図２は、図１のＶＬＤに入る可変長トークンのシーケンスの一例、及び所望の係数の復号されたシーケンスを示す。
【図３】図３は、図１のデコーダを実施化するために使用される汎用プロセッサの概略ブロック図である。
【図４】図４は、図１のデコーダにおけるＶＬＤ処理を図式的に示し、ルックアップテーブル（ＬＵＴ）は“トークン圧縮”ステップにより先行されている。
【図５】図５は、図４の処理におけるトークン圧縮ステップの動作を示している。
【図６】図６は、図４のＶＬＤ処理を含む幾つかのＭＰＥＧビデオ処理演算をパイプライン化するのに適した例示的なVLIWプロセッサアーキテクチャの命令操作部のブロック図である。
【図７】図７は、適切なコンパイルにより、パイプラインビデオプロセッサの最大の利用が、ＶＬＤ処理をＭＰＥＧデコーダ処理における他のステップとのパイプライン処理により如何に達成されるかを示す。
【図１】
2005506777.tif 000006
【図７】
2005506777.tif 000007
【国際公開パンフレット】
2005506777.tif 000008
2005506777.tif 000009
2005506777.tif 000010
2005506777.tif 000011
2005506777.tif 000012
2005506777.tif 000013
2005506777.tif 000014
2005506777.tif 000015
2005506777.tif 000016
2005506777.tif 000017
2005506777.tif 000018
2005506777.tif 000019
2005506777.tif 000020
2005506777.tif 000021
2005506777.tif 000022
2005506777.tif 000023
2005506777.tif 000024
2005506777.tif 000025
2005506777.tif 000026
2005506777.tif 000027
2005506777.tif 000028
2005506777.tif 000029
2005506777.tif 000030
2005506777.tif 000031
2005506777.tif 000032
2005506777.tif 000033
2005506777.tif 000034
2005506777.tif 000035
2005506777.tif 000036
2005506777.tif 000037
【国際公開パンフレット（コレクトバージョン）】
2005506777.tif 000038
【国際調査報告】
2005506777.tif 000039
2005506777.tif 000040