JP3714935B2 - 改善されたハフマンデコーディング方法及び装置 - Google Patents
改善されたハフマンデコーディング方法及び装置 Download PDFInfo
- Publication number
- JP3714935B2 JP3714935B2 JP2003038864A JP2003038864A JP3714935B2 JP 3714935 B2 JP3714935 B2 JP 3714935B2 JP 2003038864 A JP2003038864 A JP 2003038864A JP 2003038864 A JP2003038864 A JP 2003038864A JP 3714935 B2 JP3714935 B2 JP 3714935B2
- Authority
- JP
- Japan
- Prior art keywords
- entry
- node
- value
- index
- accessed
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
- H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
- H03M7/40—Conversion to or from variable length codes, e.g. Shannon-Fano code, Huffman code, Morse code
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
- H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
- H03M7/40—Conversion to or from variable length codes, e.g. Shannon-Fano code, Huffman code, Morse code
- H03M7/42—Conversion to or from variable length codes, e.g. Shannon-Fano code, Huffman code, Morse code using table look-up for the coding or decoding process, e.g. using read-only memory
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Compression, Expansion, Code Conversion, And Decoders (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は改善されたハフマンデコーディング方法及び装置に係り、特に、ハフマンコーディングの基本原理である２進木から生成された一次元ルックアップテーブルの効率良い構成と、プロセシング効率を高めるための数値演算技法とを用いてハフマンデコーディングを行うハフマンデコーディング方法及び装置に関する。
【０００２】
【従来の技術】
ハフマンコードが有する固有な特徴により、従来の２進木を用いたハフマンデコーディング技法は、最大検索時間及び平均検索時間の偏差の側面で極めて効率良い方法として見なされてきている。しかし、既存の２進木に基づく検索方法によれば、検索に必要な資料構造を生成するために、連結リストに基づく２進木を構成する複雑な過程を行わなければならず、且つ、２進木検索においてノード間の移動のために行う比較及び分岐構文はプロセッサーの動作中にパイプラインの流れを妨げてハフマンデコーダの処理速度を落とす主な原因となっている。
【０００３】
以下、添付した図面に基づき、従来のハフマンデコーディング装置の構成及び動作と、その装置において行われる従来のハフマンデコーディング方法について説明する。
【０００４】
図１は、従来のハフマンデコーディング装置の概略的なブロック図であって、入力バッファ１１０、サーチエンジン１２０、ハフマンルックアップテーブル１３０及び出力バッファ１４０を備えてなる。
【０００５】
図２は、図１に示された装置において行われる既存の条件分岐構文に基づくハフマンデコーダのデコーディング方法を説明するためのフローチャートである。
【０００６】
図３は、従来の方式による２進ハフマン木の構造を示し、ノード３１０、３２２、３３０、３３２、３４２、３４２、３４４、３４６、３５６は、次のノードに分岐される中間ノードであり、ノード３２０、３４０、３４６、３５０、３５２、３５４、３６０、３６２は、実際の戻し値を有する端末ノードである。
【０００７】
表１は、図３に示された２進ハフマン木のコードブックを示している。
【表１】
【０００８】
図４Ａ及び図４Ｂは、従来の２進木ハフマンデコーディング方法によるハフマンテーブルのメモリ構造を示している。図４Ａ及び図４Ｂに示されたように、従来のハフマンテーブルでは、３つのメモリ空間を用いる。図４Ａに示されたように、中間ノードの場合には割り当てられた３つのメモリ空間のうち中間のメモリ空間にはヌル値が貯蔵され、左側のメモリ空間には子ノードのうち左側ノードのアドレスが貯蔵され、右側のメモリ空間には子ノードのうち左側ノードのアドレスが貯蔵される。また、図４Ｂに示されたように、端末ノードの場合には、割り当てられた３つのメモリ空間のうち中間のメモリ空間には該当ノードの内部値、すなわち実際の戻し値が貯蔵され、左側及び右側のメモリ空間にはヌル値が貯蔵される。
【０００９】
以下では、図３、図４及び図５と図２のフローチャートとを結び付けて従来の技術による２進木構造のハフマンテーブルを用いたハフマンデコーダのデコーディング方法について説明する。
【００１０】
ステップ２１０はデコーディングの開始段階であって、ハフマンデコーダに入力される符号化されたビットストリームの符号に基づき図３に示されたハフマン木の根ノード、すなわち、中間ノード３１０に該当するエントリにアクセスする。
【００１１】
ステップ２２０は比較及び分岐構文であって、ステップ２１０においてアクセスされたエントリに該当するノードが中間ノードであるか、それとも端末ノードであるかを判断する。
【００１２】
ステップ２３０においては、ステップ２２０においてアクセスされたエントリに該当するノードが端末ノードであると判断された場合、端末ノードに割り当てられた３つのメモリ空間のうち中間のメモリ空間に貯蔵された値を実際に戻すデコーディングされたコードワード値として出力する。
【００１３】
ステップ２４０においては、ステップ２２０においてアクセスされたハフマン木のアドレスに該当するノードが中間ノードであると判断された場合、ビットストリームから入力された１ビットの値が’０’である場合にはステップ２５０へ進み、’１’である場合にはステップ２６０へ進む。
【００１４】
ステップ２５０においては、現在ノードに割り当てられた３つのメモリ空間のうち左側のメモリ空間に貯蔵されたアドレスに該当するエントリにアクセスし、ステップ２２０へ進む。
【００１５】
ステップ２６０においては、現在ノードに割り当てられた３つのメモリ空間のうち右側のメモリ空間に貯蔵されたアドレスにアクセスし、ステップ２２０へ進む。
【００１６】
以下、図２及び図５に基づき、前記従来のハフマンデコーディング方法により符号化された入力ビットストリーム’１１１０１００．．．．’をデコーディングする過程について説明する。ステップ２１０はデコーディングの開始段階であって、ハフマン２進木のルートアドレスに該当する図５に示されたハフマンテーブルのアドレス’１’に該当するエントリにアクセスする。
【００１７】
ステップ２２０において、アクセスされたエントリのノードが中間ノードであるか、それとも端末ノードであるかを判断する。図５を参照すれば、アドレス’１’に該当するノードに該当する３つのメモリ空間のうち中間のメモリ空間に貯蔵された値は’ヌル’であり、左側のメモリ空間には’４’が貯蔵されており、右側のメモリ空間には’７’が貯蔵されている。従って、ステップ２２０においては、アドレス’１’に該当するノードが図４Ａに示された中間ノードであると判断し、ステップ２４０へ進む。
【００１８】
ステップ２４０においては、入力されたビットストリーム’１１１０１００’の符号化された最初のコードワードの最初のビット’１’を入力され、入力されるビットnew_digit()が’１’であるため、ステップ２６０へ進む。
【００１９】
ステップ２６０においては、現在アドレス’１’の右側アドレス’２’、すなわち、現在ノードの右側のメモリ空間に貯蔵されたアドレス’７’に該当するエントリにアクセスし、ステップ２２０へ進む。
【００２０】
ステップ２２０においては、ハフマンテーブルのアドレス’７’に該当するノードが中間ノードであるか、それとも端末ノードであるかを判断する。図５を参照すれば、アドレス’７’に該当するノードに該当する３つのメモリ空間のうち中間のメモリ空間に貯蔵された値は’ヌル’であり、左側のメモリ空間には’１０’が貯蔵されており、右側のメモリ空間には’１３’が貯蔵されている。従って、ステップ２２０においてはアドレス’７’に該当するノードが図４Ａに示された中間ノードであると判断し、ステップ２４０へ進む。
【００２１】
ステップ２４０においては、入力されたビットストリーム’１１１０１００’の最初のコードワードの２番目のビット’１’を入力され、入力されるビットnew_digit()が’１’であるため、ステップ２６０へ進む。
【００２２】
ステップ２６０においては、現在アドレス’７’の右側アドレス’８’、すなわち、現在ノードの右側のメモリ空間に貯蔵されたアドレス’１３’に該当するエントリにアクセスし、ステップ２２０へ進む。
【００２３】
ステップ２２０においては、ハフマンテーブルのアドレス’１３’に該当するノードが中間ノードであるか、それとも端末ノードであるかを判断する。図５を参照すれば、アドレス’１’に該当するノードに該当する３つのメモリ空間のうち中間のメモリ空間に貯蔵された値は’ヌル’であり、左側のメモリ空間には’２２’が貯蔵されており、右側のメモリ空間には’２５’が貯蔵されている。従って、ステップ２２０においては、アドレス’１３’に該当するノードが図４Ａに示された中間ノードであると判断し、ステップ２４０へ進む。
【００２４】
ステップ２４０においては、入力されたビットストリーム’１１１０１００’の最初のコードワードの３番目のビット’１’を入力され、入力されるビットnew_digit()が’１’であるため、ステップ２６０へ進む。
【００２５】
ステップ２６０においては、現在アドレス’１３’の右側アドレス’１４’、すなわち現在ノードの右側のメモリ空間に貯蔵されたアドレス’２５’に該当するエントリにアクセスし、ステップ２２０へ進む。
【００２６】
ステップ２２０においては、ハフマンテーブルのアドレス’２５’に該当するノードが中間ノードであるか、それとも端末ノードであるかを判断する。図５を参照すれば、アドレス’２５’に該当するノードに割当する３つのメモリ空間のうち中間のメモリ空間に貯蔵された値は’４’であり、左側のメモリ空間には’ヌル’が貯蔵されており、右側のメモリ空間には’ヌル’が貯蔵されている。従って、ステップ２２０においてはアドレス２５に該当するノードが図４Ｂに示された端末ノードであると判断し、ステップ２３０へ進む。
【００２７】
ステップ２３０においては、アドレス’２５’に該当するノードに割り当てられた３つのメモリ空間のうち中間のメモリ空間に貯蔵された値’４’をデコーディングされたコードワード値として出力する。
【００２８】
従って、入力されたビットストリーム’１１１０１００’の最初のコードワード’１１１’に対するデコーディングされたコードワード’４’を求め、ビットストリーム’１１１０１００’の２番目のコードワードに対するデコーディングを再開する。
【００２９】
デコーディングされたコードワード値’４’を求める過程と同様に、ステップ２１０においては、デコーディングの開始段階としてハフマン２進木のルートアドレスに該当するハフマンテーブルのアドレス’１’に該当するエントリにアクセスし、ステップ２２０へ進む。
【００３０】
ステップ２２０において、アクセスされたハフマンテーブルのアドレス’１’に該当するノードが中間ノードであるか、それとも端末ノードであるかを判断し、アドレス’１’に該当するノードに該当する３つのメモリ空間のうち中間のメモリ空間に貯蔵された値は’ヌル’であり、左側のメモリ空間には’４’が貯蔵されており、右側のメモリ空間には’７’が貯蔵されている。従って、ステップ２２０においてはアドレス’１’に該当するノードが図４Ａに示された中間ノードであると判断し、ステップ２４０へ進む。
【００３１】
従って、ステップ２４０へ進んで入力されたビットストリーム’１１１０１００’の２番目のコードワードの最初のビット’０’を入力され、入力されたビットnew_digit()が’０’であるため、ステップ２５０へ進む。
【００３２】
ステップ２５０においては、現在アドレス’１’の左側アドレス’０’、すなわち、現在ノードの左側のメモリ空間に貯蔵されたアドレス’４’に該当するエントリにアクセスし、ステップ２２０へ進む。
【００３３】
ステップ２２０においては、ハフマンテーブルのアドレス’４’に該当するノードが中間ノードであるか、それとも端末ノードであるかを判断する。図５を参照すれば、アドレス’４’に該当するノードの３つのメモリ空間のうち中間のメモリ空間に貯蔵された値は’６０’であり、左側のメモリ空間には’ヌル’値が貯蔵されており、右側のメモリ空間には’ヌル’値が貯蔵されている。従って、ステップ２２０においてはアドレス’４’に該当するノードが図４Ｂに示された端末ノードであると判断し、ステップ２３０へ進む。
【００３４】
ステップ２３０においては、アドレス’４’に該当するノードに割り当てられた３つのメモリ空間のうち中間のメモリ空間に貯蔵された値’６０’をビットストリーム’１１１０１００’の２番目のコードワード’０’に対するデコーディングされたコードワード値として出力する。
【００３５】
このような方式により、ハフマンデコーダに入力される符号化されたビットストリーム’１１１０１００’の３番目のコードワード’１００’に対するデコーディングされたコードワード値’５９’を出力し、ビットストリーム’１１１０１００．．．．’に対するデコーディングされたコードワード値’４，６０，５９．．．．’値を求める。
【００３６】
このように、従来の２進木に基づくハフマンデコーディング方法は、検索に必要な資料構造を生成するために連結リストに基づく２進木を構成する複雑な過程を行わなければならず、特に、２進木検索に当たって、ノード間の移動のために行う比較及び分岐構文はプロセッサーの動作中にパイプラインの流れを妨げて処理速度の効率を落とし、従来のハフマンデコーディング方法によるルックアップテーブルは各ノードごとに３つのメモリ空間を用いるために、メモリ空間を過度に消費するといった問題点がある。
【００３７】
【発明が解決しようとする課題】
本発明が解決しようとする技術的な課題は、従来のハフマンデコーディング過程においてプロセシング効率を落とす’比較及び分岐’命令を省いてハフマンデコーダの処理速度を高め、且つ、要求されるメモリ空間を狭める改善されたハフマンデコーディング方法を提供するところにある。
【００３８】
本発明が解決しようとする他の技術的な課題は、従来のハフマンデコーディング過程においてプロセシング効率を落とす’比較及び分岐’命令を省いてハフマンデコーダの処理速度を高め、且つ、要求されるメモリ空間を狭める前記改善されたハフマンデコーディング方法を行う改善されたハフマンデコーディングシステムを提供するところにある。
【００３９】
【課題を解決するための手段】
前記課題を解決するために、本発明による改善されたハフマンデコーディング方法は、エントリとしてインデックス情報と内部値とを有するルックアップテーブルを用いて符号化されたビットストリームをデコーディングする方法であって、（ａ）前記符号化されたビットストリームを受信するステップと、（ｂ）前記受信されたビットストリームの一部ビットよりなるコードワードのうちの最初のビットからインデックス情報を求め、前記インデックス情報に対応する前記ルックアップテーブルのエントリにアクセスするステップと、（ｃ）前記アクセスされたエントリの内部値に基づき前記エントリの種類を判断するステップと、（ｄ）前記判断されたエントリのノードが端末ノードと判断される場合、前記ルックアップテーブルの内部値を前記コードワードのデコーディングされたコードワードに出力するステップと、を含むことを特徴とする。
【００４０】
好ましくは、本発明による改善されたハフマンデコーディング方法は、アクセスされたエントリの内部値の符号に基づき前記エントリが中間ノードに該当するか、それとも端末ノードに該当するかを判断することを特徴とする。
【００４１】
好ましくは、本発明による改善されたハフマンデコーディング方法は、前記アクセスされたエントリが中間ノードであると判断される場合、前記現在エントリのインデックス値、前記アクセスされたエントリの内部値、及び前記コードワードのうちの次のビット値に基づき、次にアクセスするエントリのインデックス値を計算することを特徴とする。
【００４２】
前記他の課題を解決するために、本発明による改善されたハフマンデコーディング装置は、符号化されたビットストリームをデコーディングするためのプロセッサーと、前記プロセッサーに結合され、前記デコーディングと関わるルックアップテーブルが貯蔵されたメモリと、を備え、前記ルックアップテーブルは２進木のノードに対応するインデックス情報と内部値を有するエントリを備え、前記エントリに該当する前記２進木のノードの種類は前記エントリと関わって貯蔵された内部値に基づき決定され、前記ノードの種類が端末ノードの場合、前記エントリの内部値は前記ビットストリームの所定のコードワードに対するデコーディングされたコードワードであることを特徴とする。
【００４３】
好ましくは、本発明による改善されたハフマンデコーディング装置は、エントリと関わって貯蔵された内部値は、前記エントリに該当するノードの種類によって符号を異にすることを特徴とする。
【００４４】
好ましくは、本発明による改善されたハフマンデコーディング装置は、前記エントリに該当するノードが中間ノードである場合、前記エントリの内部値は現在エントリに該当する中間ノードと次にアクセスするノードとの相対的な距離値であることを特徴とする。なお、符号化されたビットストリームは、例えば、ＭＰＥＧ規格、ＪＰＥＧ規格及びＨ．２６規格のうちいずれか一つにより符号化されたものである。
【００４５】
【発明の実施の形態】
以下、添付した図面に基づき、本発明による改善されたハフマンデコーディング方法について詳細に説明する。
【００４６】
図６は、本発明による改善されたハフマンデコーディング方法を実現するためのルックアップテーブルの再構成による効率良い一次元ルックアップテーブルの構成過程を示している。
【００４７】
テーブルの変換過程は、同一検索段階別に２進木のノードをグループ化し、表１に示されたコードワードの大きさ順に左側から右側へと一次元配列させることによりなされる。図６に示されたルックアップテーブルの生成に際し、各ノードは中間ノードの場合には現在ノードの位置を基準として次に移動するノードの相対的な距離を内部値として貯蔵し、端末ノードの場合には実際の戻し値を内部値として貯蔵する。
【００４８】
前記一次元配列は、図６に示されたように、連結リストによる動的な資料構造の生成無しに、直列配列された静的なルックアップテーブルの構成を有する。
【００４９】
以下、図６に基づき、一次元ルックアップテーブルの作成過程について詳細に説明する。
【００５０】
図６の２進木の各ノードには上位レイヤから下位レイヤに、すなわち、レイヤ−０、レイヤ−１、レイヤ−２、レイヤ−３、レイヤ−４、レイヤ−５の順番にインデックス番号が付され、そして各レイヤ内においては各ノードに対して順次的なインデックス番号が付される。本発明による実施の形態においては、図６に示されたように、兄弟ノードには隣接したインデックス番号が付される。この実施の形態においては、同じレイヤ内においては左側から右側へとインデックス番号が付されるが、選択的に、同じレイヤ内においては右側から左側へとインデックス番号が付されても良い。
【００５１】
図６において、インデックス番号０，４，７，８，９，１０，１２，１３．．．が付された端末ノードには、表１に示されたコードワードの大きさによって左側から右側へと実際の戻し値’６０’，’５９’，’４’，’６１’，’５８’，’６２’，’５７’及び’６３’が割り当てられる。
【００５２】
一方、インデックス番号１，２，３，５，６，１１，．．．が付された中間ノードには現在ノードと次の移動するノードとの相対的な距離値が貯蔵される。この実施の形態においては、インデックス番号１，２，３，５，６，１１が付された中間ノードには現在ノードのインデックス番号と子ノードのうち左側ノードのインデックス番号との差分値、すなわち、’−１’，’−２’，’−３’，’−３’，’−４’，’−１’が各々貯蔵される。
【００５３】
図７は、図６に示されたテーブルの再構成法により構成された一次元ルックアップテーブルを示している。再構成された一次元ルックアップテーブルは、前記２進木の各ノードに付されたインデックス番号及びインデックス番号を結び付けて貯蔵した各ノードの内部値を含む。
【００５４】
ルックアップテーブルに貯蔵された各ノードの内部値は、中間ノードの場合には現在ノードと次の移動するノードとの相対的な距離値、この実施の形態の場合に現在ノードのインデックス番号と子ノードのうち左側ノードのインデックス番号との差分値であるために、常に負の値を有する。これに対し、端末ノードの場合には戻し値を貯蔵するために、正の値を有する。
【００５５】
この実施の形態においては、中間ノードの場合、現在ノードと子ノードのうち左側ノードとのインデックス番号の差分値を有するが、選択的に、右側ノードのインデックス番号との差分値を貯蔵するなど、他の形の相対的な距離値を貯蔵するようにしても良い。
【００５６】
図７に示された一次元ルックアップテーブルにおいて、’左側ノード：０’、’右側ノード：１’で表わされた列は図８に示された最終的なルックアップテーブルには含まれず、テーブルを生成する中間過程を表わす。これらは、検索過程で移動する検索アドレス値を表わし、符号化されたビットストリームから読み込まれたビットデータと連動して各々の場合、次に移動する検索段階のノードのインデックス番号を表示する。
【００５７】
従来の２進木ハフマンルックアップテーブルの場合には、検索を行うためのルックアップテーブルは各ノードに対して、各ノードに該当するデータ値、左側または右側ノードに分岐時に移動するためのアドレス値の３つの構成要素を有していなければならないため、２進木の各々のノードに対して３つのメモリ空間を必要とする。
【００５８】
これに対し、図８は、本発明による最終的なルックアップテーブルを示しており、中間ノードの場合に現在ノードを基準として他の移動するノードの相対的な距離値のみを有しており、端末ノードの場合に戻す結果値、すなわち、戻し値のみを有する。また、これら２値は図７の太線にて示されたように、常に排他的に発せられるため、図８に示されたように、一次元空間上に配列できる。従って、既存のルックアップテーブルに比べてメモリの使用空間が１／３に狭まる。
【００５９】
図９は、図８に示された本発明による一次元ルックアップテーブルを用いてハフマンデコーディングを行う方法を説明するためのフローチャートである。
【００６０】
ステップ９１０は、本発明による一次元ルックアップテーブルを用いてデコーディングを開始する段階であって、ハフマンデコーダに入力される符号化されたビットストリームの所定のコードワードの最初のビット値をインデックス情報として用いて 図８のルックアップテーブルのエントリにアクセスする。
【００６１】
ステップ９２０においては、ステップ９１０においてアクセスされたエントリに該当する現在ノードが中間ノードであるか、それとも端末ノードであるかを判断する。この実施の形態においては、該当エントリの内部値が正の値であるか、それとも負の値であるかによってノードの種類を判別する。ステップ９２０においては、該当エントリに貯蔵された内部値が正の値である場合、現在ノードを端末ノードであると判断してステップ９３０へ進み、前記内部値が負の値である場合、現在ノードを中間ノードであると判断してステップ９４０へ進む。
【００６２】
ステップ９３０においては、ステップ９２０において現在ノードを端末ノードであると判断した場合、現在エントリの内部値を実際の戻し値として出力する。
【００６３】
ステップ９４０においては、ステップ９２０において現在ノードが中間ノードであると判断された場合、下記式［数２］によって新しいインデックス値を計算し、ルックアップテーブルにおいて計算されたインデックス値に該当するエントリにアクセスする。
【数２】
（式中、右側のindexは現在エントリに該当するインデックス番号であり、data(index)は現在エントリに内部値として貯蔵された現在ノードと次に移動するノードとの相対的な距離であり、new_digit()は次のビット値を意味する。）
【００６４】
この実施の形態においては、前記相対的な距離値は現在ノードのインデックス番号と現在ノードの子ノードのうち左側ノードのインデックス番号との差分値である。
【００６５】
以下、図８の一次元ルックアップテーブル及び図９のフローチャートを結び付けて、ハフマンデコーダに入力される符号化されたビットストリームのうち’１１１０１００’をデコーディングする過程について説明する。
【００６６】
ステップ９１０はデコーディングの開始段階であって、ハフマンデコーダに入力される符号化されたビットストリーム’１１１０１００’の最初のコードワードの最初のビット’１’をインデックス情報として用いて図８のルックアップテーブルのエントリにアクセスする。ここでは、所定の戻し値に対応するコードワードがビットストリーム’１１１０１００’の最初のビットから始まると仮定する。
【００６７】
ステップ９２０においては、ステップ９１０においてアクセスされた現在エントリ、すなわち、図８のルックアップテーブルのインデックス値’１’を有するエントリに該当するノードの内部値の符号によって現在ノードが中間ノードであるか、それとも端末ノードであるかを判断する。この実施の形態においては、ステップ９２０においてはインデックス値’１’を有するエントリの内部値が負の値’−１’であるため、現在ノードを中間ノードであると判断し、ステップ９４０へ進む。
【００６８】
ステップ９４０においては、前記式［数２］によって新しいインデックス値を計算し、計算されたインデックス値に基づき新しいエントリにアクセスし、ステップ９２０へ進む。この実施の形態においては、data(index)はインデックス番号１−２の結果値であり、new_digit()はデコーディングしようとするビットストリーム’１１１０１００’の次のビット値’１’であるため、新しいインデックス値は
【数３】
となる。
【００６９】
従って、ステップ９４０においては、インデックス値’３’に該当するエントリにアクセスし、ステップ９２０へ進む。
【００７０】
ステップ９２０においては、ステップ９４０においてアクセスされた現在エントリ、すなわち、図８のルックアップテーブルのインデックス値’３’に該当するエントリのノードが中間ノードであるか、それとも端末ノードであるかを判断する。ステップ９２０においては、エントリの内部値’−３’が負の値であるため、現在ノードを中間ノードであると判断し、ステップ９４０へ再び進む。
【００７１】
ステップ９４０においては、前記式［数２］によって新しいインデックス値を計算する。new_digit()はデコーディングしようとするビットストリーム’１１１０１００’の最初のコードワードの２番目のビット値’１’であるため、新しいインデックス値は、
【数４】
となる。
【００７２】
従って、インデックス値’７’に該当するエントリにアクセスし、ステップ９２０へ進む。
【００７３】
ステップ９２０においては、ステップ９４０においてアクセスされた現在エントリ、すなわち、図８のルックアップテーブルのインデックス７に該当するエントリのノードが中間ノードであるか、それとも端末ノードであるかを判断する。ステップ９２０においては、現在エントリの内部値が正の値であるため、現在ノードを端末ノードであると判断し、ステップ９３０へ進む。
【００７４】
ステップ９３０においては、インデックス７に該当するエントリの内部値’４’を実際の戻し値、すなわち、デコーディングされたコードワードとして出力し、符号化されたビットストリーム’１１１０１００’のうち最初のビットセット、すなわち、コードワード’１１１’に対するデコーディング段階を終え、２番目のコードワードに対するデコーディングを再開する。
【００７５】
ステップ９１０においては、ビットストリーム’１１１０１００’の２番目のコードワードの最初のビット’０’をインデックス情報として用いて図８のルックアップテーブルのエントリにアクセスする。
【００７６】
ステップ９２０においては、ステップ９１０においてアクセスされたインデックス０に該当するエントリの内部値が正の値であるため、現在ノードを端末ノードであると判断し、ステップ９３０へ進む。
【００７７】
ステップ９３０においては、インデックス０に該当するエントリの内部値’６０’をデコーディングされたコードワードとして出力し、符号化されたビットストリーム’１１１０１００’のうち２番目のコードワード’０’に対するデコーディング段階を終え、３番目のコードワードに対するデコーディングを再開する。
【００７８】
ステップ９１０においては、ビットストリーム’１１１０１００’の３番目のコードワードの最初のビット’１’をインデックス情報として用いて図８のルックアップテーブルのエントリにアクセスする。
【００７９】
ステップ９２０においては、ステップ９１０においてアクセスされた現在エントリ、すなわち、インデックス１に該当するエントリの内部値’−１’が負の値であるため、現在ノードを中間ノードであると判断してステップ９４０へ進む。
【００８０】
ステップ９４０においては、前記式［数２］によって新しいインデックス値を計算する。new_digit()はデコーディングしようとするビットストリーム’１１１０１００’の次のビット値’０’であるため、新しいインデックス値は、
【数５】
となる。
【００８１】
従って、インデックス値’２’に該当するエントリにアクセスし、ステップ９２０へ進む。
【００８２】
ステップ９２０においては、ステップ９４０においてアクセスされた現在エントリ、すなわち、図８のルックアップテーブルのインデックス２に該当するエントリのノードが中間ノードであるか、それとも端末ノードであるかを判断する。この実施の形態においては、現在エントリの内部値’−２’が負の値であるため、現在ノードを中間ノードであると判断してステップ９４０へ進む。
【００８３】
ステップ９４０においては、前記式［数２］によって新しいインデックス値を計算する。new_digit()はデコーディングしようとするビットストリーム’１１１０１００’の３番目のコードワードの２番目のビット値が’０’であるため、前記式［数２］によれば、新しいインデックス値は
【数６】
となる。
【００８４】
従って、インデックス値’４’に該当するエントリにアクセスし、ステップ９２０へ進む。
【００８５】
ステップ９２０においては、ステップ９４０においてアクセスされた現在エントリ、すなわち、図８のルックアップテーブルのインデックス４に該当するエントリのノードが中間ノードであるか、それとも端末ノードであるかを判断する。ステップ９２０においては、現在エントリの内部値’５９’が正の値であるため、現在ノードを端末ノードであると判断し、ステップ９３０へ進む。
【００８６】
ステップ９３０においては、現在エントリの内部値’５９’を符号化されたビットストリーム’１１１０１００’の３番目のコードワード’１００’のデコーディングされたコードワードとして出力する。
【００８７】
このような方式により、符号化されたビットストリーム’１１１０１００’の３つのコードワードに対するデコーディングを行い、デコーディングされたコードワード’４，６０，５９’を結果値として出力する。
【００８８】
このように、既存の２進木に基づくハフマンデコーディング方法と、本発明による改善されたハフマンデコーディング方法とを比較すれば、本発明によるハフマンデコーディング方法においては、符号化されたビットストリームから入力された１ビットのデータを直接的にルックアップテーブルのエントリへのアクセス、すなわち、アドレス値の演算に適用することにより、既存のハフマンデコーディング方法でノード間の移動のために存在していた条件文が除去可能になり、一層向上されたプロセシング効率が得られる。
【００８９】
表２は、本発明の改善されたハフマンデコーディング方法による結果と、既存の順次的な検索方式に基づくハフマンデコーディング方法の結果とを示している。
【表２】
表２から明らかなように、任意のＭＰＥＧ−２ ＡＡＣ（ａｄｖａｎｃｅｄ ａｕｄｉｏ ｃｏｄｉｎｇ）テストファイルを試験すれば、ハフマンコードの種類によって最小３０％から最大７７７％の性能の向上がもたらされる。また、平均検索回数の側面でも、本発明によるハフマンデコーディング方法は、通常の順次的な検索方式のハフマンデコーダに比べて約７５％の性能の向上を示している。
【００９０】
表３は、同じ測定条件下で６種の相異なるＭＰＥＧ−２ ＡＡＣテストファイルを用いて測定を行った結果を示している。
【表３】
【００９１】
表３から明らかなように、本発明による改善されたハフマンデコーディング方法は、既存の順次的な検索方式のハフマンデコーディング方法に比べて、ファイルの種類によって最小２４％から最高７７６％の検索速度の向上をもたらす。
【００９２】
本発明は上述した実施の形態に限定されることなく、本発明の思想内であれば、当業者による変形が可能であるということは言うまでもない。
【００９３】
本発明はまた、コンピュータにて読取り可能な記録媒体にコンピュータにて読取り可能なコードとして具現可能である。コンピュータにて読取り可能な記録媒体はコンピュータシステムによって読取り可能なデータが貯蔵されるあらゆる種類の記録装置を含む。コンピュータにて読取り可能な記録媒体の例としては、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、ハードディスク、フロッピー（登録商標）ディスク、フラッシュメモリ、光データ貯蔵装置などがあり、またキャリアウェーブ（例えば、インターネットを介した伝送）の形で具現されるものも含む。尚、コンピュータにて読取り可能な記録媒体は、ネットワークに連結されたコンピュータシステムに分散され、分散方式によりコンピュータにて読取り可能なコードとして貯蔵されて実行できる。
【００９４】
【発明の効果】
上述したように、本発明による改善されたハフマンデコーディング方法及び装置によれば、従来２進木検索に必要であった’比較及び分岐’演算を除くことにより検索速度を向上でき、且つ、ルックアップテーブルの構成のためのメモリ空間も、既存の’比較及び分岐’構文において用いられるテーブルの１／３だけでも実現できる。
【図面の簡単な説明】
【図１】 従来のハフマンデコーディング装置の概略的なブロック図である。
【図２】 図１に示された装置において行われる従来のハフマンデコーディング方法を説明するためのフローチャートである。
【図３】 ハフマンデコーディング方法に用いられる２進木構造を示す図面である。
【図４Ａ】 従来のハフマンデコーディング方法に用いられる各々のノードに対応するハフマンテーブルのメモリ空間を示す図面である。
【図４Ｂ】 従来のハフマンデコーディング方法に用いられる各々のノードに対応するハフマンテーブルのメモリ空間を示す図面である。
【図５】 従来のハフマンデコーディング方法に用いられるハフマンテーブルである。
【図６】 本発明による一次元ルックアップテーブルの作成過程を示す図面である。
【図７】 本発明による一次元ルックアップテーブルの作成過程を示す表である。
【図８】 本発明によるデコーディング方法に用いられる一次元ルックアップテーブルである。
【図９】 本発明による、数値演算に基づく改善されたハフマンデコーディング方法を説明するためのフローチャートである。
【符号の説明】
９１０、９２０、９３０、９４０ ステップ
【発明の属する技術分野】
本発明は改善されたハフマンデコーディング方法及び装置に係り、特に、ハフマンコーディングの基本原理である２進木から生成された一次元ルックアップテーブルの効率良い構成と、プロセシング効率を高めるための数値演算技法とを用いてハフマンデコーディングを行うハフマンデコーディング方法及び装置に関する。
【０００２】
【従来の技術】
ハフマンコードが有する固有な特徴により、従来の２進木を用いたハフマンデコーディング技法は、最大検索時間及び平均検索時間の偏差の側面で極めて効率良い方法として見なされてきている。しかし、既存の２進木に基づく検索方法によれば、検索に必要な資料構造を生成するために、連結リストに基づく２進木を構成する複雑な過程を行わなければならず、且つ、２進木検索においてノード間の移動のために行う比較及び分岐構文はプロセッサーの動作中にパイプラインの流れを妨げてハフマンデコーダの処理速度を落とす主な原因となっている。
【０００３】
以下、添付した図面に基づき、従来のハフマンデコーディング装置の構成及び動作と、その装置において行われる従来のハフマンデコーディング方法について説明する。
【０００４】
図１は、従来のハフマンデコーディング装置の概略的なブロック図であって、入力バッファ１１０、サーチエンジン１２０、ハフマンルックアップテーブル１３０及び出力バッファ１４０を備えてなる。
【０００５】
図２は、図１に示された装置において行われる既存の条件分岐構文に基づくハフマンデコーダのデコーディング方法を説明するためのフローチャートである。
【０００６】
図３は、従来の方式による２進ハフマン木の構造を示し、ノード３１０、３２２、３３０、３３２、３４２、３４２、３４４、３４６、３５６は、次のノードに分岐される中間ノードであり、ノード３２０、３４０、３４６、３５０、３５２、３５４、３６０、３６２は、実際の戻し値を有する端末ノードである。
【０００７】
表１は、図３に示された２進ハフマン木のコードブックを示している。
【表１】
図４Ａ及び図４Ｂは、従来の２進木ハフマンデコーディング方法によるハフマンテーブルのメモリ構造を示している。図４Ａ及び図４Ｂに示されたように、従来のハフマンテーブルでは、３つのメモリ空間を用いる。図４Ａに示されたように、中間ノードの場合には割り当てられた３つのメモリ空間のうち中間のメモリ空間にはヌル値が貯蔵され、左側のメモリ空間には子ノードのうち左側ノードのアドレスが貯蔵され、右側のメモリ空間には子ノードのうち左側ノードのアドレスが貯蔵される。また、図４Ｂに示されたように、端末ノードの場合には、割り当てられた３つのメモリ空間のうち中間のメモリ空間には該当ノードの内部値、すなわち実際の戻し値が貯蔵され、左側及び右側のメモリ空間にはヌル値が貯蔵される。
【０００９】
以下では、図３、図４及び図５と図２のフローチャートとを結び付けて従来の技術による２進木構造のハフマンテーブルを用いたハフマンデコーダのデコーディング方法について説明する。
【００１０】
ステップ２１０はデコーディングの開始段階であって、ハフマンデコーダに入力される符号化されたビットストリームの符号に基づき図３に示されたハフマン木の根ノード、すなわち、中間ノード３１０に該当するエントリにアクセスする。
【００１１】
ステップ２２０は比較及び分岐構文であって、ステップ２１０においてアクセスされたエントリに該当するノードが中間ノードであるか、それとも端末ノードであるかを判断する。
【００１２】
ステップ２３０においては、ステップ２２０においてアクセスされたエントリに該当するノードが端末ノードであると判断された場合、端末ノードに割り当てられた３つのメモリ空間のうち中間のメモリ空間に貯蔵された値を実際に戻すデコーディングされたコードワード値として出力する。
【００１３】
ステップ２４０においては、ステップ２２０においてアクセスされたハフマン木のアドレスに該当するノードが中間ノードであると判断された場合、ビットストリームから入力された１ビットの値が’０’である場合にはステップ２５０へ進み、’１’である場合にはステップ２６０へ進む。
【００１４】
ステップ２５０においては、現在ノードに割り当てられた３つのメモリ空間のうち左側のメモリ空間に貯蔵されたアドレスに該当するエントリにアクセスし、ステップ２２０へ進む。
【００１５】
ステップ２６０においては、現在ノードに割り当てられた３つのメモリ空間のうち右側のメモリ空間に貯蔵されたアドレスにアクセスし、ステップ２２０へ進む。
【００１６】
以下、図２及び図５に基づき、前記従来のハフマンデコーディング方法により符号化された入力ビットストリーム’１１１０１００．．．．’をデコーディングする過程について説明する。ステップ２１０はデコーディングの開始段階であって、ハフマン２進木のルートアドレスに該当する図５に示されたハフマンテーブルのアドレス’１’に該当するエントリにアクセスする。
【００１７】
ステップ２２０において、アクセスされたエントリのノードが中間ノードであるか、それとも端末ノードであるかを判断する。図５を参照すれば、アドレス’１’に該当するノードに該当する３つのメモリ空間のうち中間のメモリ空間に貯蔵された値は’ヌル’であり、左側のメモリ空間には’４’が貯蔵されており、右側のメモリ空間には’７’が貯蔵されている。従って、ステップ２２０においては、アドレス’１’に該当するノードが図４Ａに示された中間ノードであると判断し、ステップ２４０へ進む。
【００１８】
ステップ２４０においては、入力されたビットストリーム’１１１０１００’の符号化された最初のコードワードの最初のビット’１’を入力され、入力されるビットnew_digit()が’１’であるため、ステップ２６０へ進む。
【００１９】
ステップ２６０においては、現在アドレス’１’の右側アドレス’２’、すなわち、現在ノードの右側のメモリ空間に貯蔵されたアドレス’７’に該当するエントリにアクセスし、ステップ２２０へ進む。
【００２０】
ステップ２２０においては、ハフマンテーブルのアドレス’７’に該当するノードが中間ノードであるか、それとも端末ノードであるかを判断する。図５を参照すれば、アドレス’７’に該当するノードに該当する３つのメモリ空間のうち中間のメモリ空間に貯蔵された値は’ヌル’であり、左側のメモリ空間には’１０’が貯蔵されており、右側のメモリ空間には’１３’が貯蔵されている。従って、ステップ２２０においてはアドレス’７’に該当するノードが図４Ａに示された中間ノードであると判断し、ステップ２４０へ進む。
【００２１】
ステップ２４０においては、入力されたビットストリーム’１１１０１００’の最初のコードワードの２番目のビット’１’を入力され、入力されるビットnew_digit()が’１’であるため、ステップ２６０へ進む。
【００２２】
ステップ２６０においては、現在アドレス’７’の右側アドレス’８’、すなわち、現在ノードの右側のメモリ空間に貯蔵されたアドレス’１３’に該当するエントリにアクセスし、ステップ２２０へ進む。
【００２３】
ステップ２２０においては、ハフマンテーブルのアドレス’１３’に該当するノードが中間ノードであるか、それとも端末ノードであるかを判断する。図５を参照すれば、アドレス’１’に該当するノードに該当する３つのメモリ空間のうち中間のメモリ空間に貯蔵された値は’ヌル’であり、左側のメモリ空間には’２２’が貯蔵されており、右側のメモリ空間には’２５’が貯蔵されている。従って、ステップ２２０においては、アドレス’１３’に該当するノードが図４Ａに示された中間ノードであると判断し、ステップ２４０へ進む。
【００２４】
ステップ２４０においては、入力されたビットストリーム’１１１０１００’の最初のコードワードの３番目のビット’１’を入力され、入力されるビットnew_digit()が’１’であるため、ステップ２６０へ進む。
【００２５】
ステップ２６０においては、現在アドレス’１３’の右側アドレス’１４’、すなわち現在ノードの右側のメモリ空間に貯蔵されたアドレス’２５’に該当するエントリにアクセスし、ステップ２２０へ進む。
【００２６】
ステップ２２０においては、ハフマンテーブルのアドレス’２５’に該当するノードが中間ノードであるか、それとも端末ノードであるかを判断する。図５を参照すれば、アドレス’２５’に該当するノードに割当する３つのメモリ空間のうち中間のメモリ空間に貯蔵された値は’４’であり、左側のメモリ空間には’ヌル’が貯蔵されており、右側のメモリ空間には’ヌル’が貯蔵されている。従って、ステップ２２０においてはアドレス２５に該当するノードが図４Ｂに示された端末ノードであると判断し、ステップ２３０へ進む。
【００２７】
ステップ２３０においては、アドレス’２５’に該当するノードに割り当てられた３つのメモリ空間のうち中間のメモリ空間に貯蔵された値’４’をデコーディングされたコードワード値として出力する。
【００２８】
従って、入力されたビットストリーム’１１１０１００’の最初のコードワード’１１１’に対するデコーディングされたコードワード’４’を求め、ビットストリーム’１１１０１００’の２番目のコードワードに対するデコーディングを再開する。
【００２９】
デコーディングされたコードワード値’４’を求める過程と同様に、ステップ２１０においては、デコーディングの開始段階としてハフマン２進木のルートアドレスに該当するハフマンテーブルのアドレス’１’に該当するエントリにアクセスし、ステップ２２０へ進む。
【００３０】
ステップ２２０において、アクセスされたハフマンテーブルのアドレス’１’に該当するノードが中間ノードであるか、それとも端末ノードであるかを判断し、アドレス’１’に該当するノードに該当する３つのメモリ空間のうち中間のメモリ空間に貯蔵された値は’ヌル’であり、左側のメモリ空間には’４’が貯蔵されており、右側のメモリ空間には’７’が貯蔵されている。従って、ステップ２２０においてはアドレス’１’に該当するノードが図４Ａに示された中間ノードであると判断し、ステップ２４０へ進む。
【００３１】
従って、ステップ２４０へ進んで入力されたビットストリーム’１１１０１００’の２番目のコードワードの最初のビット’０’を入力され、入力されたビットnew_digit()が’０’であるため、ステップ２５０へ進む。
【００３２】
ステップ２５０においては、現在アドレス’１’の左側アドレス’０’、すなわち、現在ノードの左側のメモリ空間に貯蔵されたアドレス’４’に該当するエントリにアクセスし、ステップ２２０へ進む。
【００３３】
ステップ２２０においては、ハフマンテーブルのアドレス’４’に該当するノードが中間ノードであるか、それとも端末ノードであるかを判断する。図５を参照すれば、アドレス’４’に該当するノードの３つのメモリ空間のうち中間のメモリ空間に貯蔵された値は’６０’であり、左側のメモリ空間には’ヌル’値が貯蔵されており、右側のメモリ空間には’ヌル’値が貯蔵されている。従って、ステップ２２０においてはアドレス’４’に該当するノードが図４Ｂに示された端末ノードであると判断し、ステップ２３０へ進む。
【００３４】
ステップ２３０においては、アドレス’４’に該当するノードに割り当てられた３つのメモリ空間のうち中間のメモリ空間に貯蔵された値’６０’をビットストリーム’１１１０１００’の２番目のコードワード’０’に対するデコーディングされたコードワード値として出力する。
【００３５】
このような方式により、ハフマンデコーダに入力される符号化されたビットストリーム’１１１０１００’の３番目のコードワード’１００’に対するデコーディングされたコードワード値’５９’を出力し、ビットストリーム’１１１０１００．．．．’に対するデコーディングされたコードワード値’４，６０，５９．．．．’値を求める。
【００３６】
このように、従来の２進木に基づくハフマンデコーディング方法は、検索に必要な資料構造を生成するために連結リストに基づく２進木を構成する複雑な過程を行わなければならず、特に、２進木検索に当たって、ノード間の移動のために行う比較及び分岐構文はプロセッサーの動作中にパイプラインの流れを妨げて処理速度の効率を落とし、従来のハフマンデコーディング方法によるルックアップテーブルは各ノードごとに３つのメモリ空間を用いるために、メモリ空間を過度に消費するといった問題点がある。
【００３７】
【発明が解決しようとする課題】
本発明が解決しようとする技術的な課題は、従来のハフマンデコーディング過程においてプロセシング効率を落とす’比較及び分岐’命令を省いてハフマンデコーダの処理速度を高め、且つ、要求されるメモリ空間を狭める改善されたハフマンデコーディング方法を提供するところにある。
【００３８】
本発明が解決しようとする他の技術的な課題は、従来のハフマンデコーディング過程においてプロセシング効率を落とす’比較及び分岐’命令を省いてハフマンデコーダの処理速度を高め、且つ、要求されるメモリ空間を狭める前記改善されたハフマンデコーディング方法を行う改善されたハフマンデコーディングシステムを提供するところにある。
【００３９】
【課題を解決するための手段】
前記課題を解決するために、本発明による改善されたハフマンデコーディング方法は、エントリとしてインデックス情報と内部値とを有するルックアップテーブルを用いて符号化されたビットストリームをデコーディングする方法であって、（ａ）前記符号化されたビットストリームを受信するステップと、（ｂ）前記受信されたビットストリームの一部ビットよりなるコードワードのうちの最初のビットからインデックス情報を求め、前記インデックス情報に対応する前記ルックアップテーブルのエントリにアクセスするステップと、（ｃ）前記アクセスされたエントリの内部値に基づき前記エントリの種類を判断するステップと、（ｄ）前記判断されたエントリのノードが端末ノードと判断される場合、前記ルックアップテーブルの内部値を前記コードワードのデコーディングされたコードワードに出力するステップと、を含むことを特徴とする。
【００４０】
好ましくは、本発明による改善されたハフマンデコーディング方法は、アクセスされたエントリの内部値の符号に基づき前記エントリが中間ノードに該当するか、それとも端末ノードに該当するかを判断することを特徴とする。
【００４１】
好ましくは、本発明による改善されたハフマンデコーディング方法は、前記アクセスされたエントリが中間ノードであると判断される場合、前記現在エントリのインデックス値、前記アクセスされたエントリの内部値、及び前記コードワードのうちの次のビット値に基づき、次にアクセスするエントリのインデックス値を計算することを特徴とする。
【００４２】
前記他の課題を解決するために、本発明による改善されたハフマンデコーディング装置は、符号化されたビットストリームをデコーディングするためのプロセッサーと、前記プロセッサーに結合され、前記デコーディングと関わるルックアップテーブルが貯蔵されたメモリと、を備え、前記ルックアップテーブルは２進木のノードに対応するインデックス情報と内部値を有するエントリを備え、前記エントリに該当する前記２進木のノードの種類は前記エントリと関わって貯蔵された内部値に基づき決定され、前記ノードの種類が端末ノードの場合、前記エントリの内部値は前記ビットストリームの所定のコードワードに対するデコーディングされたコードワードであることを特徴とする。
【００４３】
好ましくは、本発明による改善されたハフマンデコーディング装置は、エントリと関わって貯蔵された内部値は、前記エントリに該当するノードの種類によって符号を異にすることを特徴とする。
【００４４】
好ましくは、本発明による改善されたハフマンデコーディング装置は、前記エントリに該当するノードが中間ノードである場合、前記エントリの内部値は現在エントリに該当する中間ノードと次にアクセスするノードとの相対的な距離値であることを特徴とする。なお、符号化されたビットストリームは、例えば、ＭＰＥＧ規格、ＪＰＥＧ規格及びＨ．２６規格のうちいずれか一つにより符号化されたものである。
【００４５】
【発明の実施の形態】
以下、添付した図面に基づき、本発明による改善されたハフマンデコーディング方法について詳細に説明する。
【００４６】
図６は、本発明による改善されたハフマンデコーディング方法を実現するためのルックアップテーブルの再構成による効率良い一次元ルックアップテーブルの構成過程を示している。
【００４７】
テーブルの変換過程は、同一検索段階別に２進木のノードをグループ化し、表１に示されたコードワードの大きさ順に左側から右側へと一次元配列させることによりなされる。図６に示されたルックアップテーブルの生成に際し、各ノードは中間ノードの場合には現在ノードの位置を基準として次に移動するノードの相対的な距離を内部値として貯蔵し、端末ノードの場合には実際の戻し値を内部値として貯蔵する。
【００４８】
前記一次元配列は、図６に示されたように、連結リストによる動的な資料構造の生成無しに、直列配列された静的なルックアップテーブルの構成を有する。
【００４９】
以下、図６に基づき、一次元ルックアップテーブルの作成過程について詳細に説明する。
【００５０】
図６の２進木の各ノードには上位レイヤから下位レイヤに、すなわち、レイヤ−０、レイヤ−１、レイヤ−２、レイヤ−３、レイヤ−４、レイヤ−５の順番にインデックス番号が付され、そして各レイヤ内においては各ノードに対して順次的なインデックス番号が付される。本発明による実施の形態においては、図６に示されたように、兄弟ノードには隣接したインデックス番号が付される。この実施の形態においては、同じレイヤ内においては左側から右側へとインデックス番号が付されるが、選択的に、同じレイヤ内においては右側から左側へとインデックス番号が付されても良い。
【００５１】
図６において、インデックス番号０，４，７，８，９，１０，１２，１３．．．が付された端末ノードには、表１に示されたコードワードの大きさによって左側から右側へと実際の戻し値’６０’，’５９’，’４’，’６１’，’５８’，’６２’，’５７’及び’６３’が割り当てられる。
【００５２】
一方、インデックス番号１，２，３，５，６，１１，．．．が付された中間ノードには現在ノードと次の移動するノードとの相対的な距離値が貯蔵される。この実施の形態においては、インデックス番号１，２，３，５，６，１１が付された中間ノードには現在ノードのインデックス番号と子ノードのうち左側ノードのインデックス番号との差分値、すなわち、’−１’，’−２’，’−３’，’−３’，’−４’，’−１’が各々貯蔵される。
【００５３】
図７は、図６に示されたテーブルの再構成法により構成された一次元ルックアップテーブルを示している。再構成された一次元ルックアップテーブルは、前記２進木の各ノードに付されたインデックス番号及びインデックス番号を結び付けて貯蔵した各ノードの内部値を含む。
【００５４】
ルックアップテーブルに貯蔵された各ノードの内部値は、中間ノードの場合には現在ノードと次の移動するノードとの相対的な距離値、この実施の形態の場合に現在ノードのインデックス番号と子ノードのうち左側ノードのインデックス番号との差分値であるために、常に負の値を有する。これに対し、端末ノードの場合には戻し値を貯蔵するために、正の値を有する。
【００５５】
この実施の形態においては、中間ノードの場合、現在ノードと子ノードのうち左側ノードとのインデックス番号の差分値を有するが、選択的に、右側ノードのインデックス番号との差分値を貯蔵するなど、他の形の相対的な距離値を貯蔵するようにしても良い。
【００５６】
図７に示された一次元ルックアップテーブルにおいて、’左側ノード：０’、’右側ノード：１’で表わされた列は図８に示された最終的なルックアップテーブルには含まれず、テーブルを生成する中間過程を表わす。これらは、検索過程で移動する検索アドレス値を表わし、符号化されたビットストリームから読み込まれたビットデータと連動して各々の場合、次に移動する検索段階のノードのインデックス番号を表示する。
【００５７】
従来の２進木ハフマンルックアップテーブルの場合には、検索を行うためのルックアップテーブルは各ノードに対して、各ノードに該当するデータ値、左側または右側ノードに分岐時に移動するためのアドレス値の３つの構成要素を有していなければならないため、２進木の各々のノードに対して３つのメモリ空間を必要とする。
【００５８】
これに対し、図８は、本発明による最終的なルックアップテーブルを示しており、中間ノードの場合に現在ノードを基準として他の移動するノードの相対的な距離値のみを有しており、端末ノードの場合に戻す結果値、すなわち、戻し値のみを有する。また、これら２値は図７の太線にて示されたように、常に排他的に発せられるため、図８に示されたように、一次元空間上に配列できる。従って、既存のルックアップテーブルに比べてメモリの使用空間が１／３に狭まる。
【００５９】
図９は、図８に示された本発明による一次元ルックアップテーブルを用いてハフマンデコーディングを行う方法を説明するためのフローチャートである。
【００６０】
ステップ９１０は、本発明による一次元ルックアップテーブルを用いてデコーディングを開始する段階であって、ハフマンデコーダに入力される符号化されたビットストリームの所定のコードワードの最初のビット値をインデックス情報として用いて 図８のルックアップテーブルのエントリにアクセスする。
【００６１】
ステップ９２０においては、ステップ９１０においてアクセスされたエントリに該当する現在ノードが中間ノードであるか、それとも端末ノードであるかを判断する。この実施の形態においては、該当エントリの内部値が正の値であるか、それとも負の値であるかによってノードの種類を判別する。ステップ９２０においては、該当エントリに貯蔵された内部値が正の値である場合、現在ノードを端末ノードであると判断してステップ９３０へ進み、前記内部値が負の値である場合、現在ノードを中間ノードであると判断してステップ９４０へ進む。
【００６２】
ステップ９３０においては、ステップ９２０において現在ノードを端末ノードであると判断した場合、現在エントリの内部値を実際の戻し値として出力する。
【００６３】
ステップ９４０においては、ステップ９２０において現在ノードが中間ノードであると判断された場合、下記式［数２］によって新しいインデックス値を計算し、ルックアップテーブルにおいて計算されたインデックス値に該当するエントリにアクセスする。
【数２】
【００６４】
この実施の形態においては、前記相対的な距離値は現在ノードのインデックス番号と現在ノードの子ノードのうち左側ノードのインデックス番号との差分値である。
【００６５】
以下、図８の一次元ルックアップテーブル及び図９のフローチャートを結び付けて、ハフマンデコーダに入力される符号化されたビットストリームのうち’１１１０１００’をデコーディングする過程について説明する。
【００６６】
ステップ９１０はデコーディングの開始段階であって、ハフマンデコーダに入力される符号化されたビットストリーム’１１１０１００’の最初のコードワードの最初のビット’１’をインデックス情報として用いて図８のルックアップテーブルのエントリにアクセスする。ここでは、所定の戻し値に対応するコードワードがビットストリーム’１１１０１００’の最初のビットから始まると仮定する。
【００６７】
ステップ９２０においては、ステップ９１０においてアクセスされた現在エントリ、すなわち、図８のルックアップテーブルのインデックス値’１’を有するエントリに該当するノードの内部値の符号によって現在ノードが中間ノードであるか、それとも端末ノードであるかを判断する。この実施の形態においては、ステップ９２０においてはインデックス値’１’を有するエントリの内部値が負の値’−１’であるため、現在ノードを中間ノードであると判断し、ステップ９４０へ進む。
【００６８】
ステップ９４０においては、前記式［数２］によって新しいインデックス値を計算し、計算されたインデックス値に基づき新しいエントリにアクセスし、ステップ９２０へ進む。この実施の形態においては、data(index)はインデックス番号１−２の結果値であり、new_digit()はデコーディングしようとするビットストリーム’１１１０１００’の次のビット値’１’であるため、新しいインデックス値は
【数３】
【００６９】
従って、ステップ９４０においては、インデックス値’３’に該当するエントリにアクセスし、ステップ９２０へ進む。
【００７０】
ステップ９２０においては、ステップ９４０においてアクセスされた現在エントリ、すなわち、図８のルックアップテーブルのインデックス値’３’に該当するエントリのノードが中間ノードであるか、それとも端末ノードであるかを判断する。ステップ９２０においては、エントリの内部値’−３’が負の値であるため、現在ノードを中間ノードであると判断し、ステップ９４０へ再び進む。
【００７１】
ステップ９４０においては、前記式［数２］によって新しいインデックス値を計算する。new_digit()はデコーディングしようとするビットストリーム’１１１０１００’の最初のコードワードの２番目のビット値’１’であるため、新しいインデックス値は、
【数４】
【００７２】
従って、インデックス値’７’に該当するエントリにアクセスし、ステップ９２０へ進む。
【００７３】
ステップ９２０においては、ステップ９４０においてアクセスされた現在エントリ、すなわち、図８のルックアップテーブルのインデックス７に該当するエントリのノードが中間ノードであるか、それとも端末ノードであるかを判断する。ステップ９２０においては、現在エントリの内部値が正の値であるため、現在ノードを端末ノードであると判断し、ステップ９３０へ進む。
【００７４】
ステップ９３０においては、インデックス７に該当するエントリの内部値’４’を実際の戻し値、すなわち、デコーディングされたコードワードとして出力し、符号化されたビットストリーム’１１１０１００’のうち最初のビットセット、すなわち、コードワード’１１１’に対するデコーディング段階を終え、２番目のコードワードに対するデコーディングを再開する。
【００７５】
ステップ９１０においては、ビットストリーム’１１１０１００’の２番目のコードワードの最初のビット’０’をインデックス情報として用いて図８のルックアップテーブルのエントリにアクセスする。
【００７６】
ステップ９２０においては、ステップ９１０においてアクセスされたインデックス０に該当するエントリの内部値が正の値であるため、現在ノードを端末ノードであると判断し、ステップ９３０へ進む。
【００７７】
ステップ９３０においては、インデックス０に該当するエントリの内部値’６０’をデコーディングされたコードワードとして出力し、符号化されたビットストリーム’１１１０１００’のうち２番目のコードワード’０’に対するデコーディング段階を終え、３番目のコードワードに対するデコーディングを再開する。
【００７８】
ステップ９１０においては、ビットストリーム’１１１０１００’の３番目のコードワードの最初のビット’１’をインデックス情報として用いて図８のルックアップテーブルのエントリにアクセスする。
【００７９】
ステップ９２０においては、ステップ９１０においてアクセスされた現在エントリ、すなわち、インデックス１に該当するエントリの内部値’−１’が負の値であるため、現在ノードを中間ノードであると判断してステップ９４０へ進む。
【００８０】
ステップ９４０においては、前記式［数２］によって新しいインデックス値を計算する。new_digit()はデコーディングしようとするビットストリーム’１１１０１００’の次のビット値’０’であるため、新しいインデックス値は、
【数５】
【００８１】
従って、インデックス値’２’に該当するエントリにアクセスし、ステップ９２０へ進む。
【００８２】
ステップ９２０においては、ステップ９４０においてアクセスされた現在エントリ、すなわち、図８のルックアップテーブルのインデックス２に該当するエントリのノードが中間ノードであるか、それとも端末ノードであるかを判断する。この実施の形態においては、現在エントリの内部値’−２’が負の値であるため、現在ノードを中間ノードであると判断してステップ９４０へ進む。
【００８３】
ステップ９４０においては、前記式［数２］によって新しいインデックス値を計算する。new_digit()はデコーディングしようとするビットストリーム’１１１０１００’の３番目のコードワードの２番目のビット値が’０’であるため、前記式［数２］によれば、新しいインデックス値は
【数６】
【００８４】
従って、インデックス値’４’に該当するエントリにアクセスし、ステップ９２０へ進む。
【００８５】
ステップ９２０においては、ステップ９４０においてアクセスされた現在エントリ、すなわち、図８のルックアップテーブルのインデックス４に該当するエントリのノードが中間ノードであるか、それとも端末ノードであるかを判断する。ステップ９２０においては、現在エントリの内部値’５９’が正の値であるため、現在ノードを端末ノードであると判断し、ステップ９３０へ進む。
【００８６】
ステップ９３０においては、現在エントリの内部値’５９’を符号化されたビットストリーム’１１１０１００’の３番目のコードワード’１００’のデコーディングされたコードワードとして出力する。
【００８７】
このような方式により、符号化されたビットストリーム’１１１０１００’の３つのコードワードに対するデコーディングを行い、デコーディングされたコードワード’４，６０，５９’を結果値として出力する。
【００８８】
このように、既存の２進木に基づくハフマンデコーディング方法と、本発明による改善されたハフマンデコーディング方法とを比較すれば、本発明によるハフマンデコーディング方法においては、符号化されたビットストリームから入力された１ビットのデータを直接的にルックアップテーブルのエントリへのアクセス、すなわち、アドレス値の演算に適用することにより、既存のハフマンデコーディング方法でノード間の移動のために存在していた条件文が除去可能になり、一層向上されたプロセシング効率が得られる。
【００８９】
表２は、本発明の改善されたハフマンデコーディング方法による結果と、既存の順次的な検索方式に基づくハフマンデコーディング方法の結果とを示している。
【表２】
【００９０】
表３は、同じ測定条件下で６種の相異なるＭＰＥＧ−２ ＡＡＣテストファイルを用いて測定を行った結果を示している。
【表３】
表３から明らかなように、本発明による改善されたハフマンデコーディング方法は、既存の順次的な検索方式のハフマンデコーディング方法に比べて、ファイルの種類によって最小２４％から最高７７６％の検索速度の向上をもたらす。
【００９２】
本発明は上述した実施の形態に限定されることなく、本発明の思想内であれば、当業者による変形が可能であるということは言うまでもない。
【００９３】
本発明はまた、コンピュータにて読取り可能な記録媒体にコンピュータにて読取り可能なコードとして具現可能である。コンピュータにて読取り可能な記録媒体はコンピュータシステムによって読取り可能なデータが貯蔵されるあらゆる種類の記録装置を含む。コンピュータにて読取り可能な記録媒体の例としては、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、ハードディスク、フロッピー（登録商標）ディスク、フラッシュメモリ、光データ貯蔵装置などがあり、またキャリアウェーブ（例えば、インターネットを介した伝送）の形で具現されるものも含む。尚、コンピュータにて読取り可能な記録媒体は、ネットワークに連結されたコンピュータシステムに分散され、分散方式によりコンピュータにて読取り可能なコードとして貯蔵されて実行できる。
【００９４】
【発明の効果】
上述したように、本発明による改善されたハフマンデコーディング方法及び装置によれば、従来２進木検索に必要であった’比較及び分岐’演算を除くことにより検索速度を向上でき、且つ、ルックアップテーブルの構成のためのメモリ空間も、既存の’比較及び分岐’構文において用いられるテーブルの１／３だけでも実現できる。
【図面の簡単な説明】
【図１】 従来のハフマンデコーディング装置の概略的なブロック図である。
【図２】 図１に示された装置において行われる従来のハフマンデコーディング方法を説明するためのフローチャートである。
【図３】 ハフマンデコーディング方法に用いられる２進木構造を示す図面である。
【図４Ａ】 従来のハフマンデコーディング方法に用いられる各々のノードに対応するハフマンテーブルのメモリ空間を示す図面である。
【図４Ｂ】 従来のハフマンデコーディング方法に用いられる各々のノードに対応するハフマンテーブルのメモリ空間を示す図面である。
【図５】 従来のハフマンデコーディング方法に用いられるハフマンテーブルである。
【図６】 本発明による一次元ルックアップテーブルの作成過程を示す図面である。
【図７】 本発明による一次元ルックアップテーブルの作成過程を示す表である。
【図８】 本発明によるデコーディング方法に用いられる一次元ルックアップテーブルである。
【図９】 本発明による、数値演算に基づく改善されたハフマンデコーディング方法を説明するためのフローチャートである。
【符号の説明】
９１０、９２０、９３０、９４０ ステップ
Claims (15)
- エントリとしてインデックス情報と内部値とを有するルックアップテーブルを用いて符号化されたビットストリームをデコーディングする方法であって、
（ａ）前記符号化されたビットストリームを受信するステップと、
（ｂ）前記受信されたビットストリームの一部ビットよりなるコードワードのうちの最初のビットからインデックス情報を求め、前記インデックス情報に対応する前記ルックアップテーブルのエントリにアクセスするステップと、
（ｃ）前記アクセスされたエントリの内部値に基づき前記エントリの種類を判断するステップと、
（ｄ）前記判断されたエントリのノードが端末ノードと判断される場合、前記ルックアップテーブルの内部値を前記コードワードのデコーディングされたコードワードに出力するステップと、を含むことを特徴とするデコーディング方法。 - 前記ステップ（ｃ）は、前記アクセスされたエントリの内部値の符号に基づき前記エントリが中間ノードに該当するか、それとも端末ノードに該当するかを判断することを特徴とする請求項１に記載のデコーディング方法。
- （ｅ）前記ステップ（ｃ）において、前記アクセスされたエントリが中間ノードであると判断される場合、前記現在エントリのインデックス値、前記アクセスされたエントリの内部値、及び前記コードワードのうちの次のビット値に基づき、次にアクセスするエントリのインデックス値を計算することを特徴とする請求項１または２に記載のデコーディング方法。
- 前記次にアクセスするエントリのインデックス値は下記式［数１］により計算され、計算されたインデックス値を用いて対応する前記ルックアップテーブルのエントリにアクセスするステップをさらに含むことを特徴とする請求項３に記載のデコーディング方法。
- 前記現在エントリの内部値は、現在ノードと次に移動するノードとの相対的な距離値であることを特徴とする請求項３または４に記載のデコーディング方法。
- 前記次にアクセスするエントリは、現在エントリに該当するノードの子ノードのうち左側ノードに該当するエントリであり、前記現在エントリの内部値は、現在エントリのインデックス値と前記左側ノードに該当するエントリのインデックス値との差分値である相対的な距離であることを特徴とする請求項３または４に記載のデコーディング方法。
- 次にアクセスするエントリのインデックス値を、前記現在のインデックス値、前記内部値の絶対値、及びコードワードの次のビット値の和値により計算することを特徴とする請求項３に記載のデコーディング方法。
- 前記ステップ（ｃ）は、（ｃ１）前記計算されたインデックスに対応する前記ルックアップテーブルのエントリの内部値に基づき前記アクセスされたエントリが中間ノードに該当するか、それとも端末ノードに該当するかを判断するステップをさらに含むことを特徴とする請求項３に記載のデコーディング方法。
- 前記符号化されたビットストリームは、ＭＰＥＧ規格、ＪＰＥＧ規格及びＨ．２６ｘ規格のうちのいずれか一つにより符号化されたことを特徴とする請求項１に記載のデコーディング方法。
- 前記ルックアップテーブルは、２進木から生成されたことを特徴とする請求項１に記載のデコーディング方法。
- 符号化されたビットストリームを２進木検索によりデコーディングするためのデコーディング装置であって、
前記符号化されたビットストリームをデコーディングするためのプロセッサーと、
前記プロセッサーに結合され、前記デコーディングと関わるルックアップテーブルが貯蔵されたメモリと、を備え、
前記ルックアップテーブルは前記２進木のノードに対応するインデックス情報と内部値を有するエントリを備え、前記エントリに該当する前記２進木のノードの種類は前記エントリと関わって貯蔵された内部値に基づき決定され、前記ノードの種類が端末ノードの場合、前記エントリの内部値は前記ビットストリームの所定のコードワードに対するデコーディングされたコードワードであることを特徴とするデコーディング装置。 - 前記エントリと関わって貯蔵された内部値は、前記エントリに該当するノードの種類によって符号を異にすることを特徴とする請求項１１に記載のデコーディング装置。
- 前記エントリに該当するノードが中間ノードである場合、前記エントリの内部値は、現在エントリに該当する中間ノードと次にアクセスするノードとの相対的な距離値であることを特徴とする請求項１１または１２に記載のデコーディング装置。
- 次にアクセスするエントリは現在エントリに該当するノードの子ノードのうち左側ノードに該当するエントリであり、前記相対的な距離値は、現在エントリのインデックス値と前記左側ノードに該当するエントリのインデックス値との差分値であることを特徴とする請求項１３に記載のデコーディング装置。
- 前記符号化されたビットストリームは、ＭＰＥＧ規格、ＪＰＥＧ及びＨ．２６ｘ規格のうちのいずれか一つにより符号化されたことを特徴とする請求項１１に記載のデコーディング装置。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR2002-010981 | 2002-02-28 | ||
| KR10-2002-0010981A KR100484137B1 (ko) | 2002-02-28 | 2002-02-28 | 개선된 허프만 디코딩 방법 및 장치 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003273748A JP2003273748A (ja) | 2003-09-26 |
| JP3714935B2 true JP3714935B2 (ja) | 2005-11-09 |
Family
ID=36753915
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003038864A Expired - Fee Related JP3714935B2 (ja) | 2002-02-28 | 2003-02-17 | 改善されたハフマンデコーディング方法及び装置 |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US6741191B2 (ja) |
| EP (1) | EP1341314A3 (ja) |
| JP (1) | JP3714935B2 (ja) |
| KR (1) | KR100484137B1 (ja) |
| CN (1) | CN1254921C (ja) |
Families Citing this family (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100468742B1 (ko) * | 2002-06-26 | 2005-01-29 | 삼성전자주식회사 | 이진 검색 기법을 이용한 ｊｐｅｇ 허프만 테이블 디코더및 그 방법 |
| EP1645037B1 (en) * | 2003-09-02 | 2017-05-24 | HMD Global Oy | Huffman decoding |
| US6839005B1 (en) * | 2003-11-07 | 2005-01-04 | Broadcom Corporation | Low memory and MIPS efficient technique for decoding Huffman codes using multi-stage, multi-bits lookup at different levels |
| KR100959532B1 (ko) | 2003-12-18 | 2010-05-27 | 엘지전자 주식회사 | Ｃａｖｌｃ 복호 방법 |
| US6975253B1 (en) * | 2004-08-06 | 2005-12-13 | Analog Devices, Inc. | System and method for static Huffman decoding |
| JP2006178013A (ja) * | 2004-12-20 | 2006-07-06 | Canon Inc | データベース作成装置及び方法 |
| US20060190251A1 (en) * | 2005-02-24 | 2006-08-24 | Johannes Sandvall | Memory usage in a multiprocessor system |
| EP1908287A4 (en) * | 2005-07-20 | 2011-02-16 | Humax Co Ltd | CODIER AND DECODER |
| KR100840757B1 (ko) | 2006-02-28 | 2008-06-23 | 노키아 코포레이션 | 허프만 부호화 및 복호화 |
| CN101072034B (zh) * | 2007-06-12 | 2010-06-02 | 华为技术有限公司 | 一种变长解码方法及其装置 |
| TW201143306A (en) * | 2010-05-19 | 2011-12-01 | Hon Hai Prec Ind Co Ltd | Method for storing information of nodes in a huffman tree and method for decoding data using an array of the huffman tree |
| CN102938685A (zh) * | 2012-11-15 | 2013-02-20 | 大连理工大学 | 一种基于变长编码的无线传感器网络数据压缩方法 |
| CN104283567B (zh) * | 2013-07-02 | 2018-07-03 | 北京四维图新科技股份有限公司 | 一种名称数据的压缩、解压缩方法及设备 |
| US9086871B2 (en) | 2013-09-26 | 2015-07-21 | International Business Machines Corporation | Reordering the output of recirculated transactions within a pipeline |
| CN104717499B (zh) * | 2015-03-31 | 2018-06-05 | 豪威科技(上海)有限公司 | 一种霍夫曼表的存储方法及用于jpeg的霍夫曼解码方法 |
| WO2017009996A1 (ja) * | 2015-07-16 | 2017-01-19 | 三菱電機株式会社 | 情報処理装置、情報処理方法及びプログラム |
| CN107797541B (zh) * | 2016-08-29 | 2020-11-10 | 河北百亚信息科技有限公司 | 基于智能家居环境中ZigBee固件升级的镜像文件轻便解压算法 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6292114B1 (en) * | 1999-06-10 | 2001-09-18 | Intel Corporation | Efficient memory mapping of a huffman coded list suitable for bit-serial decoding |
| EP1069691A1 (en) * | 1999-06-15 | 2001-01-17 | STMicroelectronics S.r.l. | Decoding method for a Huffman code |
| US6307489B1 (en) * | 2000-03-15 | 2001-10-23 | Robert Allen Freking | Fast and small serial huffman decoder for decoding at an optimally high rate |
| US6636167B1 (en) * | 2000-10-31 | 2003-10-21 | Intel Corporation | Method of generating Huffman code length information |
-
2002
- 2002-02-28 KR KR10-2002-0010981A patent/KR100484137B1/ko not_active IP Right Cessation
-
2003
- 2003-02-06 US US10/359,089 patent/US6741191B2/en not_active Expired - Lifetime
- 2003-02-17 JP JP2003038864A patent/JP3714935B2/ja not_active Expired - Fee Related
- 2003-02-28 CN CNB03106762XA patent/CN1254921C/zh not_active Expired - Fee Related
- 2003-02-28 EP EP20030251215 patent/EP1341314A3/en not_active Ceased
Also Published As
| Publication number | Publication date |
|---|---|
| CN1254921C (zh) | 2006-05-03 |
| JP2003273748A (ja) | 2003-09-26 |
| CN1441555A (zh) | 2003-09-10 |
| EP1341314A3 (en) | 2006-01-04 |
| US6741191B2 (en) | 2004-05-25 |
| KR100484137B1 (ko) | 2005-04-18 |
| US20030174076A1 (en) | 2003-09-18 |
| EP1341314A2 (en) | 2003-09-03 |
| KR20030071327A (ko) | 2003-09-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3714935B2 (ja) | 改善されたハフマンデコーディング方法及び装置 | |
| US5363098A (en) | Byte aligned data compression | |
| US9235651B2 (en) | Data retrieval apparatus, data storage method and data retrieval method | |
| US6167159A (en) | Triangle mesh compression | |
| US10153780B2 (en) | Coding method, decoding method, coder, and decoder | |
| Wu | Notes on design and implementation of compressed bit vectors | |
| JP3778087B2 (ja) | データ符号化装置及びデータ復号装置 | |
| CN110943744B (zh) | 数据压缩、解压缩以及基于数据压缩和解压缩的处理方法及装置 | |
| KR20030040567A (ko) | 허프만 디코딩을 수행하는 방법 | |
| US9665590B2 (en) | Bitmap compression for fast searches and updates | |
| CN116594572B (zh) | 浮点数流式数据压缩方法、装置、计算机设备及介质 | |
| JP4267707B2 (ja) | データフローアーキテクチャにおけるビットストリングのｎ−ウェイ処理 | |
| CN116089663A (zh) | 一种规则表达式匹配方法、装置及计算机可读存储介质 | |
| US7205915B2 (en) | Method of decoding variable length prefix codes | |
| Cannane et al. | General‐purpose compression for efficient retrieval | |
| US20120319875A1 (en) | Method for storing node information of huffman tree and corresponding decoding method | |
| US6108633A (en) | Audio decoder core constants ROM optimization | |
| US9697899B1 (en) | Parallel deflate decoding method and apparatus | |
| JP2000339332A (ja) | 検索インデックスを記録した媒体、検索インデックス更新方法、その装置、そのプログラムを記録した媒体 | |
| CN111431539A (zh) | 一种神经网络数据的压缩方法、装置及计算机可读存储介质 | |
| JP2011033806A (ja) | 言語モデル圧縮装置、言語モデルのアクセス装置、言語モデル圧縮方法、言語モデルのアクセス方法、言語モデル圧縮プログラム、言語モデルのアクセスプログラム | |
| WO2015151444A1 (ja) | データ構造、情報処理装置、情報処理方法、及びプログラム記録媒体 | |
| JP2006162774A (ja) | 信号処理装置 | |
| JP3565147B2 (ja) | 復号装置 | |
| US7065606B2 (en) | Controller architecture for memory mapping |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040622 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040922 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050405 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050701 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050726 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050823 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080902 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090902 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100902 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110902 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120902 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130902 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |