(57)【要約】【課題】本発明は高速のCAVLCのためのH.２６４デコーディング方法に関し、特に効率が優れているデコーダーを低周波数設計が可能となるように、CAVLCブロックを最小時間で係数の値を求めるために、多数のテーブルを効率的に探し、かつ早く探す方法に関する。【解決手段】本発明の高速のCAVLCのためのH.２６４デコーディング方法は、CAVLCのためのH.２６４デコーディング方法において、１番目に入力されたビットである「０」から最初の「１」のビットの直前までの「０」の個数を求めて、ローインデックスの値を求める第１段階と、前記最初の「１」のビットを示すフィックスインデックスを求める第２段階と、前記ローインデックスとフィックスインデックスを除外したビット列を示すコラムインデックスの値を求める第３段階と、前記ローインデックスの値とコラムインデックスの値に対応する全体係数の値とT１s(Trailing_ones)の値を求める第４段階と、を含めていることを特徴とする。【選択図】図２
2007049670.tif 000002
【特許請求の範囲】
【請求項１】
CAVLCのためのH.２６４デコーディング方法において、
１番目に入力されたビットである「０」から最初の「１」のビットの直前までの「０」の個数を求めて、
ローインデックスの値を求める第１段階と、
前記最初の「１」のビットを示すフイックスインデックスを求める第２段階と、
前記ローインデックスとフイックスインデックスを除外したビット列を示すコラムインデックスの値を求める第３段階と、
前記ローインデックスの値とコラムインデックスの値に対応する全体係数の値とT１s(Trailing_ones)の値を求める第４段階と、を含めていることを特徴とする、高速のCAVLCのためのH.２６４デコーディング方法。
【請求項２】
前記第１段階は、
１番目のビットが「０」であるかを判断するA段階と、
前記A段階で１番目のビットが「０」ではないと、ローインデックスの値を「０」と決め、１番目のビットが「０」であると、２番目のビットにシフトするB段階と、
前記B段階で２番目のビットが「０」であるかを判断するC段階と、
前記C段階で２番目のビットが「０」ではないと、ローインデックスの値を１と決め、２番目のビットが「０」であると、３番目のビットにシフトするD段階と、
前記のような方法で続けて、n番目のビットが「０」ではないと、ローインデックスの値をn-１と決めて、n番目のビットが「０」であると、n+１番目のビットにシフトするE段階とを含めていることを特徴とする、請求項１に記載された高速のCAVLCのためのH.２６４デコーディング方法。
【請求項３】
前記第１段階で、入力ビット列を最大１５個で切り分けて、１５個のビットを２個のビット列で区分し、「０」の個数を求めることを特徴とする、請求項１に記載された高速のCAVLCのためのH.２６４デコーディング方法。
【請求項４】
前記第１段階で入力ビット列を最大１３個で切り分けて、１３個のビットを２個のビット列で区分し、「０」の個数を求めることを特徴とする、請求項１に記載された高速のCAVLCのためのH.２６４デコーディング方法。
【請求項５】
前記第１段階で入力ビット列を最大１０個で切り分けて、１０個のビットを２個のビット列で区分し、「０」の個数を求めることを特徴とする、請求項１に記載された高速のCAVLCのためのH.２６４デコーディング方法。
【請求項６】
前記第１段階で入力ビット列を最大８個で切り分けて、８個のビットを２個のビット列で区分し、「０」の個数を求めることを特徴とする、請求項１に記載された高速のCAVLCのためのH.２６４デコーディング方法。
【請求項７】
前記「０」の個数を求めるのは、２個のビット列のそれぞれの合計を遂行して求めることを特徴とする、請求項３乃至６のいずれか１つに記載された高速のCAVLCのためのH.２６４デコーディング方法。
【請求項８】
前記「０」の個数を求めるのは、２個のビット列をそれぞれ「０」と比較して求めることを特徴とする、請求項３乃至６のいずれかの１つに記載された高速のCAVLCのためのH.２６４デコーディング方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は高速のCAVLC(Context Adaptive Variable Length Coding)のためのH.２６４デコーディング方法に関し、特に効率が優れているデコーダーを低周波数設計が可能となるように、CAVLCブロックを最小時間で係数の値を求めるために、多数のテーブルを効率的に探し、かつ早く探す方法に関する。
【背景技術】
【０００２】
超高速インターネット時代には、一般加入者の電話線とIP(Internet Protocol)ネットワークを利用するVOD（Video On Demand）方式を利用することにおいて、HDTVの場合は４〜６Mbps級を利用して試験サービスを実施している。これからは２６MbpsのVDSLが普及されることに伴って、HDTV放送の送信速度が１９.３Mpbsであることを考慮すると通信網の限界が消えることとなる。
【０００３】
最近では、放送と通信の仕分けが曖昧なデジタルマルチメディア放送(DMB：Digital Multimedia Broadcast)が浮び上がっている。それぞれは既に高速広帯域のマルチメディア情報サービスを一番早く提供し、かつ安く提供することができる媒体となっている。
【０００４】
H.２６４のコーディング方式は、大きくは、CAVLCと、CABAC(Context-based Adaptive Binary Arithmetic Codes)とで分類される。現在、H.２６４ ベースラインとX プロファイルではCAVLCを使っており、メインプロファイルではCAVLCとCABACとの両方を使っている。
【０００５】
CAVLCは、大きくは、４段階で進行して係数の値を求めることができる。１番目はT１s (Trailing_ones)と全体係数(Total coefficient)を求めて、全体的な４×４ブロックの模様を予測し、２番目はレベル値を求めて、３番目は全体ゼロ(total zero)の値を求める。更に、４番目はランビフォアー（Run Before）を求めて、実質的な係数の値を得ることができる。
【０００６】
図１は従来のH.２６４のナム（Num）VLC０に関するテーブルである。 CAVLCの実現において、多量の計算値が要求される部分をよく見ると、CAVLCの１番目の段階であるT１sと全体係数を求めるために入力されているビット列とを比較して、テーブルと一致する位置を探す。 H.２６４には、T１sと全体係数を求めるためのテーブルは全体で４個が存在し、図１はこれらの中での１つを示すものである。
【０００７】
一般的に、CAVLCをソフトウェアで処理したり、一般的なCAVLCハードウェアで処理すると、次のような例を通じてパラメーターを抽出しなければならない。
【０００８】
現在、デコーダーの入力でビット列が、「０００００００００１１１００・・・・・・・・」で入力されると仮定する。H.２６４標準で全体係数を求めるテーブルの中で図１が選択されたら(テーブルの選択は周辺のマクロブロックの全体係数の個数で決める)、図１に構成されたテーブルのビット列の種類は全体で６２個である。この例においてビット列を図１のテーブルのビット列と比較を遂行しなければならない。ソフトウェア処理の際、１つのビットずつシフト（shift）を遂行して比較すると、ハードウェア処理の際にも多くの比較を遂行しなければならない。更に改善された方法においては、入力されたビット列の「０」の個数を把握するために、カウンター(counter)を遂行した後、リーディングゼロ(上記の例では、「０」の個数は「９」)の個数を把握すると、図１でリーディングゼロと個数が一致するビット列を探す。これによって探されたビット列は殆ど複数個が存在し、前記「０」を除外した残りのビットを一致させ、一致された結果値の位置にT１sと全体係数を求める。
【０００９】
「０」の個数を把握するためには、ルーチン（routine）にビットをシフトさせながら、ビットが「１」が出るまで持続的にカウンティングを遂行することに伴って、全体の「０」の個数を把握するのに所要時間が多く掛かり、把握された「０」の個数をテーブルでサーチ(search)するのに多くの計算及び時間が必要となる。上記のように一般的な方法でテーブルのサーチを遂行し、パターン(pattern)を一致させると、多くの計算及び多くの時間が必要となって、全体的にH.２６４デコーダーの性能低下の要因となる問題点がある。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
従って、本発明は前記問題点を解決するために、効率が優れているデコーダーを低周波数設計が可能となるように、CAVLCブロックを最小時間で係数の値を求めるために、多数のテーブルを効率的に探し、かつ早く探す方法を提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明はCAVLCのためのH.２６４デコーディング方法において、１番目に入力されたビットである「０」から最初の「１」のビットの直前までの「０」の個数を求めて、ローインデックス（Row Index）の値を求める第１段階と、前記最初の「１」のビットを示すフィックスインデックス（Fix Index）を求める第２段階と、前記ローインデックスとフィックスインデックスを除外したビット列を示すコラムインデックス（Column Index）の値を求める第３段階と、前記ローインデックスの値とコラムインデックスの値に対応する全体係数の値とT１s(Trailing_ones)の値を求める第４段階と、を含む高速のCAVLCのためのH.２６４デコーディング方法を提供する。
【００１２】
具体的には、第１段階は、１番目のビットが「０」であるかを判断するA段階と、A段階で１番目のビットが「０」ではないと、ローインデックスの値を「０」と決め、１番目のビットが「０」であると、２番目のビットにシフト(shift)するB段階と、B段階で２番目のビットが「０」であるかを判断するC段階と、C段階で２番目のビットが「０」ではないと、ローインデックスの値を１と決め、２番目のビットが「０」であると、３番目のビットにシフトするD段階と、のような方法で続けて、n番目のビットが「０」ではないと、ローインデックスの値をn-１と決めて、n番目のビットが「０」であると、n+１番目のビットにシフトするE段階とを含めている。
【００１３】
より具体的には、１段階では、入力ビット列を最大１５個で切り分けて、１５個のビットを２個のビット列で区分し、「０」の個数を求める。または、第１段階で入力ビット列を最大１３個で切り分けて、１３個のビットを２個のビット列で区分し、「０」の個数を求める。あるいは、第１段階で入力ビット列を最大１０個で切り分けて、１０個のビットを２個のビット列で区分し、「０」の個数を求める。あるいは、第１段階で入力ビット列を最大８個で切り分けて、８個のビットを２個のビット列で区分し、「０」の個数を求める。
【００１４】
「０」の個数は、２個のビット列のそれぞれの合計を遂行して求めるか、あるいは２個のビット列をそれぞれ「０」と比較して求める。
【発明の効果】
【００１５】
以上のように、本発明による高速のCAVLCのためのH.２６４デコーディング方法は、それぞれのブロックを計算する時間を最小化し、ハードウェアの複雑性を最小化して、低周波数で最大の性能を発揮することができる。また、既存のテーブルを変形し、入力ビット列を意味のあるビット列に分けて、H.２６４デコーダーの性能を極大化することによって、CAVLCの計算時間を最小化することができる。 
【発明を実施するための最良の形態】
【００１６】
以下、本発明の実施例に関する構成及びその作用を添付した図面を参照しながら詳しく説明する。
【００１７】
図２は本発明の高速のCAVLCストリーム構造を示した図である。H.２６４のCAVLCの入力ビット列を分析して示したもので、本発明ではこれを利用して、図１の全体係数(Total coefficient)とT１s(Trailing_ones)を求めるテーブルを図５のように高速テーブルに変更する。次は、高速のCAVLCを遂行するために、入力ビット列の形式と高速テーブルに関して説明する。
【００１８】
図３は本発明の高速サーチNum-VLC０のテーブルを示した図である。入力ビット列の形式は、大きく３つの種類で分類される。１番目はローインデックス、２番目はフィックスインデックスで、３番目はコラムインデックスである。１番目ローインデックスは、１番目に入力されたビットである「０」ビットから最初の「１」のビットの直前までのビット列である。この際、ローインデックスの値は、１番目のビットから「１」が出る直前までの「０」の個数の値で定義する。
【００１９】
図１において、それぞれのビット列を詳しく見ると、１番目フィックスインデックスは、「０」を含めたビット列で１個以上の「１」を含めており、上記の場合を除外するとビット列が１つのビットのビット列となる。結局、全てのH.２６４のCAVLCの入力ビット列は、１個以上の「１」を含めている。３番目はコラムインデックスである。１番目のローインデックスとフィックスインデックスを除外したビット列を示している。上記のように構成すると、図１のテーブルを図３、及び図５のように構成することができ、これらを詳しく説明すると次のようである。
【００２０】
図３では、ローインデックスを除いて、出ることができる全てのビット列が、リーディングゼロ(１番目のビットから「１」が出る直前までの「０」の個数の値で定義される)の個数によって図１を基盤として整理されている。ローインデックスから出るリーディングゼロの値が１１個であると仮定すると、ローインデックスを除外したフィックスインデックスとコラムインデックスのビット列は、全体で８種類のビット列(「１０００」、「１００１」、「１０１０」、「１０１１」、「１１００」、「１１０１」、「１１１０」、「１１１１」)が存在する。これは、図１においてリーディングゼロの個数が１１個である時の値を追跡して見ればよく分かる。上記のように、リーディングゼロによって全体で８種類のビット列を示したのが図３のテーブルである。
【００２１】
更に詳しく見ると、８種類のビット列において１番目のビットは、常に「１」の値を有するフィックスインデックスであり、残り部分のビット列は「０」から「７」までの値を順次有している。順次有する値が、図４のコラムインデックスとなる。結論的に、図５においてローインデックスの値はリーディングゼロの値となり、コラムインデックスの値はリーディングゼロとフィックスインデックスを除外した値である。図５においてローインデックスとコラムインデックスの位置のテーブルを参照して見ると、全体係数とT１sの値が存在するが、これらを利用してCAVLCを遂行すれば良い。
【００２２】
例えば、「０００００１１１０１・・・・・・・・」が入力で入って来るビット列で、全体係数とT１sの値を求める。１番目にリーディングゼロの個数を求める。リーディングゼロの個数は「５」である。リーディングゼロの個数が「５」であると、後に出るビット列のビット数は３個になる。この例において３個のビット数は「１１１」となる。このビット列の中で、フィックスインデックスの「１」を削除すると、「１１」になる。結局、図４においてローインデックスの値はリーディングゼロの個数である「５」となり、コラムインデックスの値は「３」となって、図５において全体係数の値は「２」となり、T１sの値は「０」となる。
【００２３】
図４は本発明のリーディングゼロを求める１つの例を示した図である。 H.２６４デコーディング遂行の際は、CAVLC処理ブロックがH.２６４の他のブロック(IDCT、INTRA Prediction．．．．．)よりも多くの処理時間が必要となる。そういうことで、H.２６４デコーディングの性能を高めるためには、少しのハードウェア複雑性は増加しても、短い時間にCAVLC結果値を得ることが、H.２６４デコーダーの側面では更に効率的である。リーディングゼロを求めることは、図３のローインデックスの値を求めるためのことである。
【００２４】
リーディングゼロを求めるための一般的な方法は、入力で送信される１番目のビットから、「０」であるか「１」であるかを判断し、ビット列を再びシフトして、次のビットが「０」であるか「１」であるかを判断し、リーディングゼロの値を求めることができる。従来の技術である図１において、リーディングゼロの値は最大１５個のビットを有している。そういうことにより、本発明では入力ビット列の中で、１番目のビットから１５番目のビットまでのビット列のリーディングゼロの値を求めれば良い。最大のビット列を選択する方法をテーブル毎に区分して見ると次のようである。
【００２５】
図５は本発明の高速のCAVLCを遂行するために図１を変形したテーブルであり、図６は本発明のH.２６４のナムVLC１に関するテーブルである。更に、図７は本発明の高速のCAVLCを遂行するために図６を変形したテーブルであり、図８は本発明のH.２６４のナムVLC２に関するテーブルである。また、図９は本発明の高速のCAVLCを遂行するために図８を変形したテーブルであり、図１０は本発明のH.２６４のクロマ（Chroma）DC ナムVLCに関するテーブルである。また、図１１は本発明の高速のCAVLCを遂行するために図１０を変形したテーブルである。
【００２６】
図５、図７、図９、及び図１１において、ローインデックスの最後の値を見ると、現在のテーブルが最大に幾つのリーディングゼロを有することができるかが分かる。図５では、リーディングゼロの個数が最大１４個であり、図７では、リーディングゼロの個数が最大１２個であり、図９では、リーディングゼロの個数が最大９個であり、図１１では、リーディングゼロの個数が最大７個である。図５、図７、図９、及び図１１のテーブルの中でどれを選択するかは、現在CAVLCを遂行するマクロブロックを基準として、前記マクロブロックと左側マクロブロック係数の個数で決定する。結論的に、図５のテーブルを参照して見ると、入力されたビット列の中で、１５個までのビットが来ることができ、図７のテーブルを参照して見ると、入力されたビット列の中で、１３個までのビットが来ることができる。また、図９が選択されると、最大のビット列は１０個であり、図１１が選択されると、最大のビット列は８個である。上記のように、最大のビット列ほどのビット数を有して、下記のようにリーディングゼロを求める。次の例は、図５のテーブル参照時の例である。
【００２７】
１５個のビット(０番目のビットから１４番目のビット)を２個のビット列に分ける。１番目のビット列は、０番目のビットから７番目のビットまでのビット列である。２番目のビット列は、８番目のビットから１４番目のビットまでのビット列である。まず、０番目のビットから７番目のビットまでの合計を求めるか、「０」より大きいかを比較する。また、８番目のビットから１４番目のビットまでの合計を求めるか、「０」より大きいかを比較する。
【００２８】
もし、０番目のビットから７番目のビットまでの合計が「０」より大きいであったり、「０」と比較した値が「０」より大きいと、１番目のビット列の中に「１」が含まれているので、１番目のビット列を持ってリーディングゼロを求めれば良い。結局、８番目のビットから１４番目までのビット列は無視する。もし、０番目のビットから７番目のビットまでの合計が「０」であったり、「０」と比較した値が「０」であると、８番目のビットから１４番目までのビット列を持ってリーディングゼロのビットを求める。このように１個のビット列が決まると、上記のような同じ方法で二つに分けられ、上記の方法を連続的に遂行すると、図４のようにリーディングゼロの値を有する。
【００２９】
図１２は本発明の全体係数とT１sを求めるためのブロックダイアグラムである。現在の入力で入って来るビット列は、リーディングゼロブロック、フィックスインデックスブロック、及びコラムインデックスブロックと分けられる。また、図５、図７、図９、及び図１１のテーブルを内部のメモリーであるROMテーブルにそれぞれ割り当てて保存する。ビット列の結果値を利用して、ローインデックスとコラムインデックスを求め、ROMテーブルに代入すれば、全体係数とT１sを得ることができる。
【００３０】
以上で説明した内容で、本発明が属する技術の当業者なら、本発明の技術思想を離脱しない範囲で、多様な変更、及び修正が可能であることが分かる。従って、本発明の技術的範囲は、実施例として記載した内容だけに限定されるのではなく、特許請求の範囲により決めなければならない。
【図面の簡単な説明】
【００３１】
【図１】従来のH.２６４のナムVLCOに関するテーブルである。
【図２】本発明の高速のCAVLCストリーム構造を示す図である。
【図３】本発明の高速サーチナムVLC０のテーブルを示す図である。
【図４】本発明のリーディングゼロを求める１つの例を示す図である。
【図５】本発明の高速のCAVLCを遂行するために図１を変形したテーブルである。
【図６】本発明のH.２６４のナムVLC１に関するテーブルである。
【図７】本発明の高速のCAVLCを遂行するために図６を変形したテーブルである。
【図８】本発明のH.２６４のナムVLC２に関するテーブルである。
【図９】本発明の高速のCAVLCを遂行するために図８を変形したテーブルである。
【図１０】本発明のH.２６４のクロマDC Num-VLCに関するテーブルである。
【図１１】本発明の高速のCAVLCを遂行するために図１０を変形したテーブルである。
【図１２】本発明の全体係数とT１sを求めるためのブロックダイアグラムである。
【図１】
2007049670.tif 000003
【図２】
2007049670.tif 000004
【図３】
2007049670.tif 000005
【図４】
2007049670.tif 000006
【図５】
2007049670.tif 000007
【図６】
2007049670.tif 000008
【図７】
2007049670.tif 000009
【図８】
2007049670.tif 000010
【図９】
2007049670.tif 000011
【図１０】
2007049670.tif 000012
【図１１】
2007049670.tif 000013
【図１２】
2007049670.tif 000014