ビデオ圧縮方法
【課題】各ブロックがピクセルの配列を有する少なくとも１つのブロックを有する少なくとも１つのフレームを有するビデオデータを圧縮する方法を提供する。
【解決手段】各ブロックのピクセルを係数に変換し、これらの係数の最適な送信順序を作成する。データビットストリームを区画して各パーティションを独立に符号化することにより、圧縮ビデオデータの処理速度を最適化する。各所与のブロックに関連した少なくとも１つのメトリックに応じて、各所与の複数のピクセル又はピクセルブロックの補間方法を選択することにより端数ピクセル動きを予測し、ブロックごとに方法を変える。現在のフレームの直前のフレームよりも前のフレームを、データ送信中の品質損失を小さくするための唯一の基準フレームとして使用して、現在のフレームのエラー回復を高度化する。
【解決手段】各ブロックのピクセルを係数に変換し、これらの係数の最適な送信順序を作成する。データビットストリームを区画して各パーティションを独立に符号化することにより、圧縮ビデオデータの処理速度を最適化する。各所与のブロックに関連した少なくとも１つのメトリックに応じて、各所与の複数のピクセル又はピクセルブロックの補間方法を選択することにより端数ピクセル動きを予測し、ブロックごとに方法を変える。現在のフレームの直前のフレームよりも前のフレームを、データ送信中の品質損失を小さくするための唯一の基準フレームとして使用して、現在のフレームのエラー回復を高度化する。
【発明の詳細な説明】
【技術分野】
【０００１】
［関連出願］
本出願は、２００３年５月１２日に出願された米国仮特許出願第６０／４６９，１８７号及び２００３年１１月１４日に出願された米国特許出願第１０／７１３，８０７号の優先権を主張する。
【０００２】
本発明は、ビデオデータに関し、より詳細には、できるだけ効率的な方法でビデオデータの符号化、復号、圧縮、及び送信を行う方法及びシステムに関する。
【背景技術】
【０００３】
データの送信は、通例、帯域幅及びスループットの制限によって制約を受ける。微少な時間で無限の情報量を送信することも受信することもできない。送信中の情報の量及び品質を最大にするために、場合により、情報は、圧縮又は符号化されて送信され、受信時に伸張又は復号される。
【０００４】
データ圧縮が不可欠である１つの分野は、ビデオデータの送信である。通常のテキストは、膨大でない限り、容易且つ高速に送信される。しかしながら、ビデオデータは、色の側面、明度の側面、及び多くの場合ステレオ音響情報の側面を含む可能性がある。短いビデオクリップであっても、定義するのに大量のデータが必要とされる。このようなデータの送信及び符号化は、できるだけ効率的でなければならない。すなわち、送信するのに必要な情報をできるだけ少なくしなければならない。
【０００５】
ビデオ圧縮は、データ圧縮の一般的な技法のサブセットである。データ圧縮によって、信号は、より小さな数字の集合にスクイーズ又は圧縮される。これらの数字は、したがって、ハードドライブを占める空間が小さくなるか、又は、ネットワーク上で送信に要する時間が少なくなる。これらの数字が再び使用される前に、伸張アルゴリズムが適用されて、その数字列は、その元の（又は少なくとも類似の）形に展開される。
【０００６】
記憶もしくは送信される数字列に適用できる圧縮比又はスクイーズ量を増加させるために、ビデオ圧縮は、信号が、デジタル化されたビデオとして発生していることが知られているという事実を利用する。ビデオ及びオーディオの大幅な圧縮は非可逆アルゴリズムを考えられる。その理由は、非可逆アルゴリズムが元の情報の或る部分を廃棄するか又は失い、再現された数字列は元の数字列とは正確には一致しないからである。我々がビデオ及びオーディオを鑑賞する精度は、デジタル化プロセスの解像度と比較して完全でないことから、これは許容することができる。ビデオ信号は、僅かに歪む場合があるが、それにもかかわらず認識することが可能である。圧縮アルゴリズムが、最小の歪み又は損失で元の信号を忠実に再現できる程度は、アルゴリズムの成功の尺度である。
【０００７】
技術的な問題及び機器のコストを含めて、ビデオ信号及びオーディオ信号を圧縮するもっともな理由が多数ある。１つの最優先の問題は、データ送信コストである。インターネットは、２１世紀の事実上のデータ搬送プラットフォームに成熟するにつれて、ビデオテープ、フィルム、放送等のアナログメディアは、インターネット技術及びインターネット関連技術の上に構築されたデジタルメディアインフラストラクチャに取って代わられることになろう。このデジタルインフラストラクチャにより、必要に応じて、地球上のどの２つのコンピューティングマシン間でもデータを転送することが可能になる。しかしながら、このデータを送信できる速度は多数の要因に依存する。極端な場合、百年以上も前に敷設され、アナログ音声通信を対象とした銅線が、モデム技術（モデム（modem）は、モジュレーション（変調（Modulation））／ディモジュレーション（復調（DEModulation））の略語である）と共に使用されて、毎秒９６００ビット程度の低速でデータが送信される。同様の速度は、携帯電話等の無線ネットワーク上で音声を運ぶのにも使用される。最近、ケーブルモデム技術、ＤＳＬ技術、及び衛星技術が、６桁のデータレート（１００，０００ビット／秒から１００万ビット／秒）をホームユーザにもたらしている。ハイエンドアプリケーションの場合、光ファイバによって、データレートをギガビットの範囲（毎秒数十億ビット）及びそれを超える範囲にすることが可能である。
【０００８】
所与のアプリケーションに利用可能なデータレートがいかなるものであっても、データの送信には、お金がかかる。現在のところ、１メガバイト（８００万ビット）をインターネット上で送信するコストは、通例、小さなボリュームの５セントあたりから、安い場合は極端に大きなボリュームの１セント程度のコストがかかる（この価格は、受信端でのコストを含んでいない）。したがって、或る場所から別の場所へ１メガバイトのデータを搬送するコストは、常に、１ペニーよりも高い。
【０００９】
ビデオデータ圧縮の分野では、多くの研究が行われてきた。本出願の譲受人である、ニューヨーク州クリフトンパークのOn2 Technologies（当初はDuck Corporationとして知られていた）は、既にＶＰ３やＶＰ５等のコーデックを製造してきており、Microsoft Corporationは、ＭＰＥＧ等の符号を作成してきた。既存のビデオコーデックの特徴のいくつかには、動きベクトルの離散コサイン変換圧縮、エントロピー符号化、及び差分符号化が含まれる。また、従来のコーデックは、基準フレームを利用し、データパケットが喪失又は破損した場合に、基準フレームを参照することによってそのデータを取り出すことができるようにしている。これらの特徴及びこれらの特徴に伴う問題のすべてについて、以下でより詳細に解説することにする。
【００１０】
ＤＣＴ（離散コサイン変換（Discrete Cosine Transform））に基づくビデオ圧縮システムでは、８×８のピクセルブロック又は予測エラー信号データが、１組の６４個の周波数係数（１つのＤＣ値及び６３個のＡＣ値）に変換される。これら６４個の周波数係数は、その後、量子化されて１組のトークンに変換される。
【００１１】
通常、高周波のＡＣ係数ほど、大きさが小さくなり、したがって、次の量子化で非ゼロになる可能性は小さくなる（すなわち、ゼロになる可能性が高くなる）。その結果、トークン化の前に、それら係数は、多くの場合、最も低い周波数係数（ＤＣ値）から開始して最も高周波のＡＣ係数で終了する昇順に配列される。この走査順序は、時に、「ジグザグ順序」と呼ばれることがあり、その始点に非ゼロ値を集め、終点に向かうにつれてゼロを集める傾向があり、そうすることによって、より効率的な圧縮を容易にする。
【００１２】
しかしながら、この固定された走査順序は、最適になることがほとんどない。たとえば、インターレースされたビデオ素材を符号化する場合、一定の高周波係数は、はるかに顕著である。このことは従来技術に反映され、この従来技術では、インターレースされたビデオを符号化する時に代替的な走査順序を指令するコーデックが使用される例（たとえば、ＭＰＥＧ−２）が存在する。
【００１３】
特定のハードウェアデバイス用にコーデックを最適化する場合、そのデバイスが複数のタスクを並列に実行するのに提供できるあらゆる設備が十分に利用されることを確かめること、及び、復号プロセスの個々の部分がボトルネックとなる範囲を制限することが重要である。
【００１４】
本発明のビットストリームは、ほとんどの他のビデオコーデックと共通して、概して言えば、エントロピー符号化されたトークンを含むものとして説明することができる。このエントロピー符号化されたトークンは、プリディクタ（predictor）トークン又はＰトークン、及び、予測エラートークン又はＥトークンの２つの主要なカテゴリーに分割することができる。Ｐトークンは、画像のブロック又は領域を符号化するのに使用される方法又はモードを記述するトークンであり、或るフレームと別のフレームとの間の動きを記述するトークンである。Ｅトークンは、不完全な予測の結果生じたあらゆる残差を符号化するのに使用される。
【００１５】
エントロピー符号化は、ビットストリームにおける特定のＰトークン又はＥトークンの表現が、ビットストリームにおけるそのトークンの周波数、又は、そのトークンが特定の位置に現れる尤度に従って最適化されるプロセスである。たとえば、非常に頻繁に現れるトークンは、まれにしか現れないトークンよりも少ないビット数を使用して表される。
【００１６】
最も一般的なエントロピー符号化技法の２つは、ハフマン符号化及び算術符号化である。ハフマン符号化では、各トークンは、可変長のビットパターン（又は符号）によって表される。算術符号化は、計算がより複雑な技法ではあるが、各トークンについて多数のビット全体を使用する制約が除去されている。算術符号化器を使用すると、１ビットの１／２の平均コストで非常に一般的なトークンを符号化することが完全に可能である。
【００１７】
多くのマルチメディアデバイスは、エントロピー符号化のタスクによく適合したコプロセッサユニット、及び、より多目的のメインプロセッサを有する。その結果、並列化のために、ビットストリームの符号化又は復号のプロセスは、多くの場合、エントロピーに関連したタスクと、エントロピーに関連しないタスクとに分割される。しかしながら、所与のビットクリップの場合、データレートが増加するにつれて、符号化／復号するトークン数が急激に上昇し、エントロピー符号化がボトルネックになる場合がある。
【００１８】
従来のビットストリームでは、エントロピー符号化の計算負荷を再分散させて、このボトルネックを取り除くことは非常に困難である。特に、復号側では、通常は、トークンが符号化された順序で１度に１つずつトークンを復号しなければならない。また、フレームレベル以外の方法又はエントロピー符号化（たとえば、ハフマン符号化及び算術符号化）を混在させることもきわめて困難である。
【００１９】
慣例により、現代のほとんどのビデオコーデックは、差分符号化方式を使用して、動きベクトルの（ｘ，ｙ）成分を符号化する。すなわち、各ベクトルは、前のベクトルを基準にして符号化される。たとえば、２つのベクトル（７，３）及び（８，４）を考える。この場合、第２のベクトルは（１，１）、すなわち（７＋１，３＋１）として符号化されることになる。
【００２０】
この方式は、動きベクトルが符号化されるほとんどのブロック又は領域が、その近傍の動きと類似した動きを示す場合によく機能する。これは、多くの場合、たとえばパンする時に当てはまることを示すことができる。しかしながら、動きフィールドが不規則である場合、又は、異なる動き特性を有する背景領域と前景領域との間での遷移が頻繁である場合に、この方式はあまりよく機能しない。
【００２１】
現代のほとんどのビデオコーデックにとって、動き予測は、圧縮プロセスの重要な部分である。動き予測は、画像の物体又は領域の動きが、１つ又は複数のフレームにわたってモデル化され、１つ又は複数の「動きベクトル」が、この動きを表すためのビットストリームで送信されるプロセスである。ほとんどの場合、画像内の動きを完全にモデル化することはできず、そこで、動き情報に加えて残差信号を符号化することが必要である。
【００２２】
基本的に、各動きベクトルは、符号化される現在のフレームの領域と類似した、前に符号化されたフレームの領域を指し示す。残差信号は、各ピクセルの予測値を、現在のフレームの実際の値から差し引くことによって得られる。
【００２３】
現代の多くのビデオコーデックは、たとえば、１／２ピクセル又は１／４ピクセルの動き推定といったサブピクセル精度に対して動き予測のサポートを提供することによりこのプロセスを拡張している。端数ピクセルデータ点を作成するには、実際の（すなわち、フルピクセルアラインされた（full pixel aligned））データ点に適用される或る形態の補間関数又は補間フィルタを使用することが必要である。
【００２４】
初期のコーデックは、一般に、本明細書に添付した図１に示すような簡単な双１次補間を使用していた。この例では、Ａ、Ｂ、Ｃ、及びＤが、フルピクセルアラインされたデータ点であり、ｘ、ｙ、及びｚが、１／２ピクセルアラインされた点である。点ｘは、Ｘ方向に１／２ピクセルアラインされ、方程式：
ｘ＝（Ａ＋Ｂ／２） （１）
を使用して計算することができる。
点ｙは、Ｙ方向に１／２ピクセルアラインされ、方程式：
ｙ＝（Ａ＋Ｃ／２） （２）
を使用して計算することができる。
点ｚは、Ｘ及びＹの双方で１／２ピクセルアラインされ、方程式：
ｚ＝（Ａ＋Ｂ＋Ｃ＋Ｄ／２） （３）
を使用して計算することができる。
【００２５】
後のコーデックは、画像がぼける傾向を少なくする、双３次フィルタ等のより複雑な補間フィルタの使用に向かう傾向がある。図２に示す例では、ｘは、２つのフルピクセルアラインされた点ＢとＣとの間の中点にある１／２ピクセル点である。双３次フィルタに対して整数近似を使用すると、ｘは、方程式：
ｘ＝（−Ａ＋９Ｂ＋９Ｃ−Ｄ）／１６
を使用して計算することができる。
【００２６】
上記に示した双３次フィルタ等のフィルタは、よりシャープに見える結果を生成する傾向があるが、いくつかのフレームにわたってそれらフィルタが繰り返し適用されると、場合によっては、誤ったテキスチャや誤った輪郭等の不快な人工物となる可能性がある。
【００２７】
ビデオコーデックは、多くの場合、ビットストリームのエラーの影響を極端に受けやすいので、信頼性のないデータリンク又は問題の多いデータリンク上で圧縮ビデオデータを送信する場合、データが喪失又は破損したときの回復のためのメカニズムが存在することは重要である。
【００２８】
このようなリンクの信頼性のあるデータ送信のためのさまざまな技法及びプロトコルが存在し、これらは、通常、エラーの検出、及び、再送又は一定のタイプのエラーの訂正を可能にする追加データビットの使用のいずれかに依拠する。多くの状況では、これら既存の技法は十分である。しかし、制限された帯域幅のリンク上でビデオ会議を行う場合、上述した手法のいずれも理想的ではない。喪失したデータパケットの再送は、端末間の遅延の増加を引き起こす可能性があるので実用的でない場合がある一方、誤り訂正ビット又は誤り訂正パケットの使用は、帯域幅がすでに厳しく制限されている状況では受け入れられない場合がある。
【００２９】
代替的な手法は、単に、復号器においてエラーを検出し、そのエラーを符号化器に報告することである。符号化器は、その後、回復フレームを復号器へ送信することができる。この手法は、リンク上のエラーレートが非常に高い場合、たとえば、１０フレーム〜２０フレームごとに２つ以上のエラーがある場合に、適切でないおそれがあることに留意されたい。
【００３０】
最も簡単な形態の回復フレームは、キーフレーム（又はイントラオンリーフレーム（intra-only-frame））である。これは、前のフレーム又は前のフレームのデータに何ら依存関係を有しないフレームである。キーフレームに関連した問題は、それらキーフレームが、通例、比較的大きいということである。
【発明の開示】
【発明が解決しようとする課題】
【００３１】
本発明の目的は、効率的で信頼性のあるビデオ圧縮方法及びコーデックを提供することである。
【００３２】
本発明の別の目的は、適応性のある方法で離散コサイン変換を実行できるビデオ圧縮方法及びコーデックを提供することである。
【００３３】
本発明の別の目的は、使用されるハードウェアデバイスの資源を最適化するエントロピー符号化を実行するビデオ圧縮方法及びコーデックを提供することである。
【００３４】
本発明の別の目的は、動きベクトル符号化を高度化するビデオ圧縮方法及びコーデックを提供することである。
【００３５】
本発明の別の目的は、端数ピクセル動き予測を正確且つ効率的に実行するビデオ圧縮方法及びコーデックを提供することである。
【００３６】
本発明の別の目的は、ビデオ会議の環境であっても、エラー回復を効率的に実行するビデオ圧縮方法及びコーデックを提供することである。
【課題を解決するための手段】
【００３７】
本発明により上記の又は他の目的が達成され、本発明は、各ブロックがピクセルの配列を有する少なくとも１つのブロックを有する少なくとも１つのフレームを有するビデオデータを圧縮する方法である。本発明の方法は、以下のステップの少なくとも１つを含む。Ｉ）各ブロックのピクセルを係数に変換して、係数の最適な送信順序を作成するステップ、ＩＩ）データのビットストリームを区画して各パーティションを独立に符号化することにより、圧縮されたビデオデータを処理する速度を最適化するステップ、ＩＩＩ）所与の各ブロックに関連した少なくとも１つのメトリックに応じて所与の各複数のピクセルの補間方法を選択することにより、端数ピクセル動きを予測するステップ、及び、ＩＶ）現在のフレームの直前のフレームよりも前のフレームを唯一の基準フレームとして使用して現在のフレームのエラー回復を高度化するステップであって、それによって、データ送信中の品質損失を小さくする、現在のフレームのエラー回復を高度化するステップ。
【００３８】
本発明の係数の再配列の態様に関して、本方法は、各ブロックのピクセルを、各係数が係数位置及び値を有する係数に変換し、各係数位置に関連した位置の値を求める。次に、係数の最適な送信順序が、各係数位置の位置の値に基づいて作成され、係数は、そのようにして求められた順序で送信される。好ましくは、係数の送信順序は、ビデオデータの各フレームについて動的に再配列される。変換ステップは、好ましくは、ピクセルを離散コサイン変換係数に変換する。係数の送信順序は、係数と共に送信してもよい。好ましくは、各ブロックは、同じ個数の係数及び係数位置を有し、それぞれの対応する各係数位置は、ブロックごとに同じ各情報を運ぶ。
【００３９】
送信されるデータ量を削減するために、係数順序データの送信は、或るフレームから次のフレームへ係数順序が変更したものに制限してもよい。これに代えて又はこれに加えて、送信順序は係数の帯域に統合してもよい。各帯域は、上記で求められた数のランクによって編成された複数の係数を有する。この場合、帯域情報のみを係数と共に送信してもよい。好ましくは、係数が或るフレームから次のフレームにおいて帯域を変更した場合に、帯域情報のみが送信される。別の代替的なものとして、すべての帯域情報を常に送信してもよい。
【００４０】
係数を再配列することは、キーフレームを提供することも含むことができる。本発明の方法は、常に完全に自己符号化され、前のフレームからの情報も前のフレームに関する情報も必要としないこのようなキーフレームを提供してもよい。このような場合、符号化器は、所与のフレームがキーフレームであるかどうかを判断する。所与のフレームがキーフレームであると判断された場合、そのキーフレームの係数の送信順序全体が送信される。所与のフレームがキーフレームでないと判断された場合、前のフレームからこの所与のフレームにおいて係数の送信順序が変化したもののみが送信される。
【００４１】
上述したように、本発明は、データビットストリームを区画して各パーティションを独立に符号化することにより、圧縮ビデオデータの処理速度を最適化することを検討する。具体的には、本発明は、ビデオデータを少なくとも２つのデータパーティションに分割し、各データパーティションについて最適なエントロピー符号化方法を選択する。したがって、選択されたエントロピー符号化方法は、各データパーティションにそれぞれ適用される。１つの実施の形態では、ビデオデータは、プリディクタトークンデータパーティション及びエラートークンデータパーティションに分割される。好ましくは、各データパーティションは、ハフマン符号化及び算術符号化等の異なるエントロピー符号化方法を受ける。異なるデータパーティションのさまざまな復号プロセスは、非同期且つ／又は独立に実行してもよい。これは、ハードウェアに少なくとも２つのサブプロセッサを設けることによって行ってもよく、或るデータパーティションは或るサブプロセッサによって復号され、別のデータパーティションは別のサブプロセッサによって復号される。所与のデータパーティションにどのエントロピー符号化方法が使用されるかの判断は、その所与のデータパーティションのサイズに基づいてもよい。
【００４２】
本方法及びコーデックの１つの好ましい実施の形態では、プリディクタトークンデータパーティションは読み出されて、プリディクタブロックに変換される。エラートークンデータパーティションも読み出されて、係数及びそこからエラーブロックに変換される。プリディクタブロック及びエラーブロックは合計されて、画像ブロックが形成される。上述したように、少なくとも２つのサブプロセッサを設けることが好ましく、これらのステップのいくつかは、或るサブプロセッサで実行され、ステップの残りは別のサブプロセッサで実行される。具体的には、エラートークンデータパーティションを読み出すステップ、及び、エラートークンデータパーティションを係数に変換するステップは、好ましくは、高速エントロピー最適化サブプロセッサによって実行され、他のステップは、好ましくは、汎用サブプロセッサによって実行される。
【００４３】
本発明の方法は、データ及びコードのキャッシュミスを回避するようにビットストリームの復号器の性能を最適化する。コードキャッシュに適合できる個数の、復号器のコードの異なる関数がコードキャッシュに記憶される。このステップからのコードは、データキャッシュに適合できる個数のブロックについて実行される。復号器のコードの次の１組の異なる関数及び次に収集され、このプロセスは、ビットストリームのすべてが読み出され、データブロックのそれぞれが生成されるまで繰り返される。
【００４４】
ビットストリームの復号器の性能を最適化する別の態様は、各サブタスクを別々のプロセッサへ割り当てることによってサブプロセッサの利用を最適化するものである。好ましくは、ビットストリームからエラートークンを読み出して、それらエラートークンを係数に変換する、復号器の部分は、高速エントロピー最適化サブプロセッサで実行される。ビットストリームからプリディクタトークンを読み出して、これらのトークンからフィルタリングされたプリディクタブロックを構築する、復号器の部分は、メモリへの高速アクセスを有するサブプロセッサで実行される。上記ステップからの変換係数をエラー信号に変換する、復号器の部分は、変換符号化器の最適化された実施態様を有するサブプロセッサで実行され、プリディクタブロックをエラー信号に加える、復号器の部分は、動き補償に最適化されたサブプロセッサで実行される。
【００４５】
ビデオデータは、２つのデータパーティションに分割してもよい。第１のデータパーティションはフレームの第１のエリアを表し、第２のデータパーティションはフレームの第２のエリアを表す（たとえば、上半分及び下半分、又は、左半分及び右半分）。或いは、ビデオデータは、３つのデータパーティションに分割してもよい。各データパーティションは、それぞれ、フレームのレベル情報、彩度情報、及び色相情報を表す。別の変形では、これら３つのデータパーティションは、それぞれ、フレームのシアン情報、マゼンタ情報、及びイエロー情報を表すことができる。
【００４６】
前述したように、本発明は、各所与のブロックに関連した少なくとも１つのメトリックに応じて各所与の複数のピクセルの補間方法を選択することにより、端数ピクセル動きを予測する態様を含む。具体的には、符号化する所与の複数のピクセルに関連した少なくとも１つのメトリックの値が求められ、その所与の複数のピクセルを符号化する補間方法が、求められた少なくとも１つのメトリックの値に応じて選択される。このようにして選択された補間方法は、符号化する所与の複数のピクセルに適用される。このプロセスは、次の各複数のピクセルについて繰り返されるステップである。少なくとも１つのメトリックは、動きベクトル長及び複雑度因子の少なくとも１つとしてもよい。補間方法には、双１次補間、双３次補間、２次補間、及びＢスプライン補間が含まれ得る。所与の複数のピクセルは、フレーム全体としてもよいし、フレームのサブ部分としてもよい。所与の複数のピクセルに関連した動きベクトル長が、所定の長さ値よりも小さいと判断され、且つ、所与の複数のピクセルに関連した複雑度因子が、所定の複雑度値よりも大きいと判断された場合、双３次補間が選択される。所定の長さ値及び所定の複雑度値は、好ましくは、所与の個数の複数のピクセルについて１回設定され、且つ、フレームごとに１回設定される。
【００４７】
複雑度因子は、好ましくは、所与の複数のピクセルの分散であり、次のように計算される。
Ｃ＝（ｎΣｘｉ２−（Σｘｉ）２）／ｎ２ （４）
【００４８】
上述したように、本発明は、現在のフレームの直前のフレームよりも前のフレームを、データ送信中の品質損失を少なくするための唯一の参照フレームとして使用して、現在のフレームのエラー回復を高度化することを含む。具体的には、本発明は、喪失又は破損したパケットを引き起こす、ライン上の送信に関連した品質損失を少なくするために、最後のフレームよりも前に符号化されたフレームを、所与のフレームの唯一の基準フレームとして使用することを含む。このステップは、周期的（Ｆフレームごと）及び任意（或る他の判定基準に基づいて）の少なくとも１つに制限される。
【００４９】
本発明のこの態様は、特に、ビデオ会議によく適合する。具体的には、ビデオ会議の各当事者は、ビデオデータのフレームを圧縮し、パケットの喪失又は破損が検出可能なようにマーキングされたパケットで、圧縮されたビデオデータを他の当事者へ送信する。パケットが喪失又は破損したことをいずれかの当事者が検出した場合に、検出した当事者は、送信した当事者に信号で伝え、それによって、残りの当事者のすべてがすでに受信に成功して復号している基準フレームを使用して符号化された更新フレームが送信される。
【００５０】
本発明は、好ましくは、以下のように基準フレームを使用することができる。ビデオフレームの一定の間隔Ｆを符号化器が選択して、復号器へ送信することができる。Ｆ番目のフレームごとにフレームが、前の符号化されたＦ番目のフレームのみを基準に使用して符号化される。Ｆ番目でないあらゆるフレームは、その前のフレームを基準として使用して符号化される。ビデオの各フレームは、喪失及び破損が検出可能なように、復号器へ送信される。これらのステップのすべては、好ましくは、符号化器で行われる。復号器側では、符号化されたビデオデータが符号化器から受信され、復号器によって復号される。パケットが喪失し、喪失したパケットがＦ番目でないフレームに関連したものである場合、復号器は、次のＦ番目のフレームが喪失したパケットを回復するのを待つ。
【００５１】
別の代替形態として、本発明は、現在のフレームを、この符号化されたフレーム及び前の符号化されたフレームから取得された統計値のメトリックによって求められた周囲の品質よりも高い品質で、周期的及び任意の少なくとも１つで符号化し、符号化された現在のフレームを、２次的な基準フレームとしてのその後のフレームによる使用のために記憶する。
【発明を実施するための最良の形態】
【００５２】
本発明のいくつかの異なる態様を以下に説明することにする。
【００５３】
＜動的な係数の再配列（Dynamic Coefficient Reordering）＞
ＤＣＴ（離散コサイン変換）に基づくビデオ圧縮システムでは、８×８のピクセルブロック又は予測エラー信号データが、１組の６４個の周波数係数（１つのＤＣ値及び６３個のＡＣ値）に変換される。これら６４個の周波数係数は、その後、量子化されて１組のトークンに変換される。
【００５４】
通常、高周波のＡＣ係数ほど、大きさが小さくなり、したがって、次の量子化で非ゼロになる可能性は小さくなる。その結果、トークン化の前に、それら係数は、多くの場合、最も低い周波数係数（ＤＣ値）から開始して最も高周波のＡＣ係数で終了する昇順に配列される。この走査順序は、時に、「ジグザグ順序」と呼ばれることがあり、その始点に非ゼロ値を集め、終点に向かうにつれてゼロ値を集める傾向があり、そうすることによって、より効率的な圧縮を容易にする。
【００５５】
しかしながら、この固定された走査順序は、最適になることがほとんどない。たとえば、インターレースされたビデオ素材を符号化する時、一定の高周波係数は、はるかに顕著である。このことは従来技術に反映され、この従来技術では、インターレースされたビデオを符号化する時に代替的な走査順序を指令するコーデックが使用される例（たとえば、ＭＰＥＧ−２）が存在する。
【００５６】
本発明の一態様は、特定のデータセットの特性をより最適に反映するように係数が符号化される走査順序を、コーデックが最適にカスタマイズできる方法である。
【００５７】
本発明によれば、コーデックは、１つ又は複数のビデオフレームにおいて、ＤＣＴ係数のそれぞれについてゼロ値対非ゼロ値の分布の記録を保持する。この記録は、非ゼロになる可能性が高い係数がリストに先に現れるカスタムな走査順序を作成するのに使用される。
【００５８】
コーデックは、各係数について非ゼロ値の平均的な大きさ等の付加情報をオプションとして照合することができ、これを使用して走査順序をさらに最適化することができる。
【００５９】
新しいカスタム走査順序を送信するオーバーヘッド又は前に送信された走査順序を更新するオーバーヘッドは、場合によっては、改善された係数符号化効率から得られた利益を打ち消すおそれがある。したがって、更新がネットに利益を提供するかどうかを判断するのにコスト利益分析が必要となる場合がある。
【００６０】
この分析の結果に影響を与える主要な要因は、更新コスト、符号化されるブロック数（したがって、係数の個数）、及び新たな走査順序が標準的な走査順序又は前に符号化された走査順序のいずれかから逸脱する程度である。
【００６１】
８×８要素のＤＣＴの場合、「完全な」カスタム走査順序（すなわち、６４個の係数の１つ１つにつき新たな位置）を符号化するには、３８４ビット（それぞれ６４個の係数×６ビット）が必要となる。このコストは、符号化されるブロック数（したがって、係数の個数）が非常に大きくない限り、又は、最適な走査順序がデフォルト走査順序（これは、標準的な走査順序又は前に符号化された走査順序のいずれかである）と大幅に異ならない限り、法外なものとなる可能性がある。この記述の背後にある理論的根拠は、デフォルト走査順序がカスタム走査順序と類似している場合、各ブロックの符号化に確保される平均ビット数が小さくなる可能性があり、したがって、走査順序を更新するオーバーヘッドを正当化するには多数のブロックを符号化しなければならないということである。逆に、デフォルト走査順序がカスタム走査順序と異なる場合、ブロックあたりの平均節減は高くなる可能性がある。
【００６２】
この状況を改善する簡単な方法は、走査順序に対する変更のみを符号化することである。たとえば、各係数について、その係数が走査順序において自身の位置を変更したかどうかを示すビットを符号化し、次いで、適切な場合は、その新しい位置を示すビットを符号化する。これは、通常、更新コストが低くなるが、ここでの最悪の場合のシナリオは、新たな走査順序がすべての係数について異なる場合である。この場合、更新コストは４４８ビット（６４×７）となる。
【００６３】
このような手法の魅力的な態様は、カスタム走査順序とデフォルト走査順序とが最も類似している場合に更新コストが最小となり（したがって、ブロックごとの可能性のあるコスト削減は、その最小のものとなる）、それらの走査順序が最も異なる場合に最高となることである。
【００６４】
この状況は、個々の係数又は係数の対のレベルの「コスト利益」を考えることによってさらに改善することができる。たとえば、２つの係数が走査順序において互いに隣接しており、非ゼロ値の尤度がその双方でほとんど同一である場合を考える。それら２つの係数の一方又は他方の非ゼロ値の個数に小さな変化があると、それら２つの係数は、カスタム走査順序において場所を交換する可能性がある。この変化を符号化することは、（上記更新モデルを仮定した場合に）１４ビットのコストで双方の係数の走査位置を更新することを意味する。しかしながら、達成される節減はごく僅かとなる場合がある。
【００６５】
この問題は、特に、高い順序のＡＣ係数について該当する。この点で、非ゼロ値の周波数は、通常、非常に低く、きわめて小さな変化であっても、走査順序における係数の位置は大幅に変更される可能性がある。
【００６６】
カスタム走査順序の計算の基礎を、各係数についての単にゼロ対非ゼロの分布に置くことは確かに実現可能であるが、該当する他の要因がある。前述したように、これらの要因の１つは、非ゼロ値の平均的な大きさである。もう１つは、場合により、１つ又は複数の係数の値の間に正の相関が存在する場合があることである。たとえば、低い順序の「完全に水平な」ＡＣ係数と高い順序の「完全に水平な」係数との間である。このような場合、非ゼロ値の広がりに大幅な相違がない限り、非ゼロ値はその元の順序（最も低い周波数から最も高い周波数）に維持することが好ましい場合がある。
【００６７】
本発明のこの態様の好ましい実施態様は、このような問題に対処するのに幾分助けとなると同時に、走査順序の更新コストをさらに削減する。
【００６８】
カスタム走査順序を作成する手順は、概略的には以下の通りである。
・ＤＣ係数は常に最初（位置０）に符号化される。
・ＡＣ係数を、各係数の非ゼロである値の比率に基づいて降順に並べる。
・順序リストを１６個の可変サイズの帯域に分割する（表１参照）。
・各帯域内において、ジグザグ走査順序に再配列する。
【００６９】
表１に示すような１６個の帯域への再分化は、或る範囲の異なる試験クリップを用いた経験的な観測に基づいており、必ずしも最適ではないことに留意されたい。
【００７０】
【表１】
表１：好ましい走査順序の係数帯域
【００７１】
経験的な実験は、更新コストが考慮される前であっても、この帯域ストラテジーが、単に非ゼロである値の比率に基づく走査順序を使用して得られた結果と通例は同程度の良好な結果、又は、多くの場合それよりも良好な結果を与えることを示している。
【００７２】
第２の利点は、走査順序の更新コストが大きく削減されるということである。その理由は、値が或る帯域から別の帯域へ移動される場合にしか、その値を更新する必要がないからである。さらに、帯域内の変更の符号化には４ビットしか必要とされない。
【００７３】
好ましい実施態様で使用される最終的な最適化は、いくつかの係数が他の係数よりもはるかに頻繁に帯域を変更するという観察結果に基づいている。たとえば、高い順序のＡＣ係数は、低い順序の係数よりも帯域を変更する頻度は低いという傾向を有する。
【００７４】
特定の係数が、たとえば、時間の２％しか更新されない場合、その係数が所与のフレームにおいて更新されるかどうかを示すのに１ビットを使用することは無駄である。算術符号化技法を使用して、経験的に求められた更新確率を各係数に割り当てることにより、係数あたり実質的に１ビット未満の平均更新コストを得ることが可能である。
【００７５】
以下の「Ｃ」コードセグメントは、本発明のこの態様の好ましい実施態様をサポートする詳細を与えるものである。
// 収集されたゼロ／非ゼロ周波数データを使用して新たな「好ましい」走査順序を
// 実現する
void CalculateScanOrder( CP_INSTANCE *cpi)
{
UINT32 i, j, k;
UINT32 Sum;
UINT32 tmp[2];
UINT32 NzValue[BLOCK_SIZE][2];
UINT32 GroupStartPoint, GroupEndPoint;
// 各係数について、非ゼロであった値の比率を０〜２５５からの
// 拡大縮小された数字として計算する
for ( i=1; i<BLOCK_SIZE; i++ )
{
Sum = cpi->FrameNzCount[i][0] + cpi->FrameNzCount[i][1];
if ( Sum )
NzValue[i][0] = (cpi->FrameNzCount[i][1]*255)/Sum;
else
NzValue[i][0] = 0;
NzValue[i][1] = i;
}
// 降順にソートする
for ( i=1; i<BLOCK_SIZE-1; i++ )
{
for ( j=i+1; j>1; j--)
{
if ( NzValue[j][0] > NzValue[j-1][0] )
{
// それらを交換する
tmp[0] = NzValue[j-1][0];
tmp[1] = NzValue[j-1][1];
NzValue[j-1][0] = NzValue[j][0];
NzValue[j-1][1] = NzValue[j][1];
NzValue[j][0] = tmp[0];
NzValue[j][1] = tmp[1];
}
}
}
// 帯域に分割し、次いで、各帯域内において、ジグザグ走査位置に基づいて
// 昇順に再ソートする
GroupEndPoint = 0;
for ( k=0; k<SCAN_ORDER_BANDS; k++ )
{
GroupStartPoint = GroupEndPoint + 1;
GroupEndPoint = EndPointLookup[k];
for ( i=GroupStartPoint; i<GroupEndPoint; i++ )
{
for ( j=i+1; j>GroupStartPoint; j-- )
{
if ( NzValue[j][1] < NzValue[j-1][1] )
{
// それらを交換する
tmp[0] = NzValue[j-1][0];
tmp[1] = NzValue[j-1][1];
NzValue[j-1][0] = NzValue[j][0];
NzValue[j-1][1] = NzValue[j][1];
NzValue[j][0] = tmp[0];
NzValue[j][1] = tmp[1];
}
}
}
// 各係数インデックス（coef index）について、その帯域番号に印を付ける
for ( i=GroupStartPoint; i<=GroupEndPoint; i++ )
{
// 各係数の新たな走査帯域番号に留意する
// NzValue[i][1]は従来のジグザグ順序の係数の位置であり、
// iは新たな走査順序の位置であり、kは帯域番号である。
cpi->NewScanOrderBands[NzValue[i][1]] = k;
}
}
}
// この構造体は、（従来のジグザグ順序の）ｄｃｔ係数のそれぞれについての
// （１〜２５５の範囲に拡大縮小された）走査順序更新確率を与える。
// これらの値は、関数「nDecodeBool()」に渡され、結果が０（FALSE）である
// 確率を示す。
//
const UINT8 ScanBandUpdateProbs[BLOCK_SIZE] =
{
255, 132, 132, 159, 153, 151, 161, 170,
164, 162, 136, 110, 103, 114, 129, 118,
124, 125, 132, 136, 114, 110, 142, 135,
134, 123, 143, 126, 153, 183, 166, 161,
171, 180, 179, 164, 203, 218, 225, 217,
215, 206, 203, 217, 229, 241, 248, 243,
253, 255, 253, 255, 255, 255, 255, 255,
255, 255, 255, 255, 255, 255, 255, 255
};
// 走査順序に対する更新がこのフレームに利用可能である場合、この更新を読み出す。
void UpdateScanOrder( PB_INSTANCE *pbi )
{
// 走査順序が更新されているのはこのフレームか？
if ( nDecodeBool( 128 ))
{
// 更新された走査帯域で読み出す
for ( i = 1; i < BLOCK_SIZE; i++ )
{
// この係数の帯域は更新されたか？
if ( nDecodeBool( ScanBandUpdateProbs[i] ))
{
pbi->ScanBands[i] = VP6_bitread( SCAN_BAND_UPDATE_BITS );
}
}
// 新たな走査順序を走査帯域データから構築する
BuildScanOrder( pbi, pbi->ScanBands );
}
}
// １組の走査帯域データからカスタム走査順序を構築する
void BuildScanOrder( PB_INSTANCE *pbi, UINT8 *ScanBands )
{
UINT32 i, j;
UINT32 ScanOrderIndex = 1;
// ＤＣは一定である。
pbi->ModifiedScanOrder[0] = 0;
// 各帯域内において、（係数の元の「ジグザグ」操作順序位置の点で）
// 係数が昇順である走査順序を作成する
for ( i = 0; i < SCAN_ORDER_BANDS; i++ )
{
for ( j = 1; j < BLOCK_SIZE; j++ )
{
if ( ScanBands[j] == i )
{
pbi->ModifiedScanOrder[ScanOrderIndex] = j;
ScanOrderIndex++;
【００７６】
＜独立したビットストリームパーティションを使用した、符号化器及び復号器の最適化の容易化、及び、混在モードエントロピー符号化の使用＞
特定のハードウェアデバイス用にコーデックを最適化する場合、そのデバイスが複数のタスクを並列に実行するのに提供できるあらゆる設備が十分に利用されることを確かめること、及び、復号プロセスの個々の部分がボトルネックとなる範囲を制限することが重要である。
【００７７】
本発明のビットストリームは、ほとんどの他のビデオコーデックと共通して、概して言えば、エントロピー符号化されたトークンを含むものとして説明することができる。このエントロピー符号化されたトークンは、２つの主要なカテゴリーに分割することができる。
プリディクタトークン（以下、Ｐトークンと呼ぶ）。たとえば、画像のブロック又は領域を符号化するのに使用される方法又はモードを記述するトークンであり、或るフレームと別のフレームとの間の動きを記述するトークンである。
予測エラー信号トークン（以下、Ｅトークンと呼ぶ）。これらは、不完全な予測の結果生じたあらゆる残差を符号化するのに使用される。
【００７８】
エントロピー符号化は、ビットストリームにおける特定のＰトークン又はＥトークンの表現が、ビットストリームにおけるそのトークンの周波数、又は、そのトークンが特定の位置に現れる尤度に従って最適化されるプロセスである。たとえば、非常に頻繁に現れるトークンは、まれにしか現れないトークンよりも少ないビット数を使用して表される。
【００７９】
最も一般的なエントロピー符号化技法の２つは、ハフマン符号化及び算術符号化である。ハフマン符号化では、各トークンは、可変長のビットパターン（又は符号）によって表される。算術符号化は、計算がより複雑な技法ではあるが、各トークンについて多数のビット全体を使用する制約が除去されている。算術符号化器を使用すると、たとえば、１ビットの１／２の平均コストで非常に一般的なトークンを符号化することが完全に可能である。
【００８０】
多くのマルチメディアデバイスは、エントロピー符号化のタスクによく適合したコプロセッサユニット、及び、より多目的のメインプロセッサを有する。その結果、並列化のために、ビットストリームの符号化又は復号のプロセスは、多くの場合、エントロピーに関連したタスクと、エントロピーに関連しないタスクとに分割される。
【００８１】
しかしながら、所与のビデオクリップの場合、データレートが増加するにつれて、符号化／復号するトークン数が急激に上昇し、エントロピー符号化がボトルネックになる場合がある。
【００８２】
従来のビットストリームでは、エントロピー符号化の計算負荷を再分散させて、このボトルネックを取り除くことは非常に困難である。特に、復号側では、通常は、トークンが符号化された順序で１度に１つずつトークンを復号しなければならない。また、フレームレベル以外の方法又はエントロピー符号化（たとえば、ハフマン符号化及び算術符号化）を混在させることもきわめて困難である。
【００８３】
本発明のこの態様は、エントロピー符号化の計算負荷を再分散することを容易にし、且つ、ビットストリームに対する構造的な変更を通じて混在モードのエントロピー符号化の使用を容易にするように設計された方法である。
【００８４】
本方法によれば、ビットストリームの各フレームは、完全に独立した２つ又は３つ以上のデータパーティションに分割される。これらのパーティションは、並列に書き込むこともできるし、並列に読み出すこともでき、同じエントロピー符号化メカニズムを使用するように制約されない。これによって、高いビットレートでエントロピーに関連したボトルネックを回避するように符号化プロセス又は復号プロセスを最適化することが容易になる。
【００８５】
単一のフレーム内でハフマン技法及び算術技法の双方又はそれら２つを混在させたものが使用できることによって、符号化器には、達成される圧縮量と計算複雑度との間のトレードオフをより良く最適化する機能が与えられる。たとえば、フレームの計画されたサイズが所与のしきい値を超えている場合、符号化器は、そのパーティションの１つ又は複数において、複雑さが少なくなったハフマン方法を使用するように構成することができる。
【００８６】
本発明のこの態様の特定の実施態様は、１つ又は２つのいずれかのメインデータパーティションの使用をサポートする。これに加えて、小さなヘッダパーティションがある。
【００８７】
単一のデータパーティションを使用する場合、コーデックは従来通りに振る舞う。Ｐトークン及びＥトークンの双方が、単一のデータパーティションで独自の算術符号化器を使用して符号化される。本方法は、オーバーヘッドがわずかに低い（フレームあたり数ビット）が、柔軟性が少ない。
【００８８】
たとえば、
パーティション１
（ブロック１） Ｐ，Ｐ，Ｅ，Ｅ，Ｅ
（ブロック２） Ｐ，Ｅ，Ｅ
（ブロック３） Ｐ，Ｅ，Ｅ，Ｅ，Ｅ
【００８９】
一方、第２のケースでは、Ｐトークン及びＥトークンは、別々のパーティションに書き込まれる。
【００９０】
たとえば、
パーティション１ パーティション２
（ブロック１） ＰＰ ＥＥＥ
（ブロック２） Ｐ ＥＥ
（ブロック３） Ｐ ＥＥＥＥ
第１のパーティションのサイズは、データレートによって等しく変化する傾向はなく、比較的小さい。したがって、このパーティションは、常に、算術符号化器を使用して符号化される。第２のパーティションは、算術符号化器を使用して符号化することもできるし、ハフマン符号化器を使用して符号化することもできる。
【００９１】
第２のパーティションに対するハブマン符号化又は算術符号化の選択は、フレームレベルの信号で伝えることができる。好ましい実施態様では、この選択は、ターゲット復号器のプラットフォームの性能及びフレームの計画されたビットサイズに依存する。具体的には、フレームサイズがしきい値数を超える場合において、復号器が実時間でフレームを復号する問題を有するという危険性があるときは、ハフマン方法が使用される。
【００９２】
符号化器の性能も、実時間符号化が要件である場合に問題となる可能性がある。しかし、キーフレーム（より大きくなる傾向があり、他のフレームに依存しない）は例外になり得るとして、エントロピー符号化のコストは、通例、符号化器の全体の計算コストのより小さな一部分となる。
【００９３】
以下の「Ｃ」コードセグメントは、本発明のこの態様の好ましい実施態様をサポートする詳細を与えるものである。
// この関数は、算術符号化された１つのデータパーティション、算術符号化された
// ２つのデータパーティション、又は、算術符号化された１つのデータパーティ
// ション及び１つのハフマンデータパーティションのいずれかを使用して、
// フレーム用の符号化されたビデオデータを梱包する。
//
// 引数「cpi」は、主符号化器インスタンスデータ構造体へのポインタである。
void PackCodedVideo( CP_INSTANCE *cpi )
{
UINT32 PartitionTwoOffset;
BOOL_CODER *bc = &cpi->bc; // 算術符号化器インスタンスデータ構造体
BOOL_CODER *bc2 = &cpi->bc2; // 第２の算術符号化器インスタンス構造体
PB_INSTANCE *pbi = &cpi->pb; // 復号器インスタンスデータ構造体
// ヘッダパーティションに使用される生のバッファｉ／ｏを初期化する
InitAddRawBitsToBuffer( &cpi->RawBuffer, pbi->DataOutputPtr );
// 算術符号化器及び／又はハフマン符号化器を起動する
// ２つのデータパーティションを使用している場合…
if ( pbi->MultiStream || (pbi->VpProfile == SIMPLE_PROFILE))
{
// 第１の算術符号化器を起動する。生のヘッダバイトを考慮する。
VP6_StartEncode( bc, (pbi->DataOutputPtr + ((KeyFrame)? 4:3)));
// 第２の算術パーティション又はハフマンパーティションのいずれかを作成する
// これは、保持バッファ「cpi->OutputBuffer2」に最初に書き込まれる
if ( pbi->UseHuffman )
InitAddRawBitsToBuffer ( &pbi->HuffBuffer, cpi->OutputBuffer2 );
else
VP6_StartEncode( bc2, cpi->OutputBuffer2 );
}
// 算術符号化器を使用して符号化された単一のデータパーティションのみを使用している
else
{
// 算術符号化器を起動する。生のヘッダバイトを考慮する。
VP6_StartEncode( bc, (pbi->DataOutputInPtr + ((KeyFrame)? 2:1))); }
…
…
// サイズを含むフレームヘッダ情報を書き出す。
WriteFrameHeader( … );
…
…
if ( pbi->UseHuffman )
PackHuffmanCoeffs( … );
else
PackArithmeticCoeffs( … );
// 第１のデータパーティションに使用された算術符号化器インスタンスを停止する
VP6_StopEncode( bc );
// データパーティションへのオフセットを算出し、それらオフセットを、
//生のヘッダパーティションにおけるこの情報用に予約された空間に書き込む
//
// ２つのデータパーティションを使用している場合…
if ( pbi->MultiStream || (pbi->VpProfile == SIMPLE_PROFILE))
{
// バッファの始点から第１のデータパーティションへのオフセット
PartitionTwoOffset = 4 + bc->pos;
// オフセットを第２のデータパーティションパーティションに書き込む。
AddRawBitsToBuffer( &cpi->RawBuffer, PartitionTwoOffset, 16 );
// 第２のデータパーティションにハフマンが使用された場合…
if ( pbi->UseHuffman )
{
// ハフマン符号化された出力パーティション用のバッファをフラッシュする
EndAddRawBitsToBuffer( &pbi->HuffBuffer );
…
// ハフマン符号化されたデータを保持バッファから出力バッファへ
// コピーする
memcpy( &cpi->RawBuffer.Buffer[ PartitionTwoOffset ],
pbi->HuffBuffer.Buffer, pbi->HuffBuffer.pos );
}
else
{
// 第２のデータパーティションによって使用された
// 算術符号化器インスタンスを停止する。
VP6_StopEncode( bc2 );
…
// 第２のパーティションによって使用された保持バッファの内容を
// 出力バッファへコピーする
memcpy( &pbi->DataOutputInPtr[ PartitionTwoOffset ],
bc2.buffer, bc2.pos);
}
}
// ヘッダに使用された生のビット符号化器を停止してフラッシュする
EndAddRawBitsToBuffer( &cpi->RawBuffer );
}
// この関数は、２つのデータパーティションを使用する場合に符号化ストラテジーを選択するためにコールされる。
void SelectMultiStreamMethod( CP_INSTANCE *cpi)
{
// フレームにおけるトークンの分布から収集された情報を使用して
// フレームの見積もりコスト（シャノンエントロピー）を計算する。
// あらゆるモード情報及び動きベクトル情報を符号化するための、
// 前に計算されたコスト見積もりを算入する
EstimatedFrameCost = VP6_ShannonCost( cpi ) + ModeMvCost;
// 第２のデータパーティションにハフマン符号化を使用して下がるかどうかを判断する
if ( EstimatedFrameCost > HuffmanCodingThereshold )
pbi->UseHuffman = TRUE;
else
pbi->UseHuffman = FALSE;
【００９４】
＜複数のフィルタを使用した、ビデオコーデックの端数ピクセル動き予測の高度化＞
現代のほとんどのビデオコーデックにとって、動き予測は、圧縮プロセスの重要な部分である。動き予測は、画像の物体又は領域の動きが、１つ又は複数のフレームにわたってモデル化され、１つ又は複数の「動きベクトル」が、この動きを表すためのビットストリームで送信されるプロセスである。ほとんどの場合、画像内の動きを完全にモデル化することはできず、そこで、動き情報に加えて残差信号を符号化することが必要である。
【００９５】
基本的に、各動きベクトルは、符号化される現在のフレームの領域と類似した、前に符号化されたフレームの領域を指し示す。残差信号は、各ピクセルの予測値を、現在のフレームの実際の値から差し引くことによって得られる。
【００９６】
現代の多くのビデオコーデックは、サブピクセル精度に対して動き予測をサポートすることによりこのプロセスを拡張している。たとえば、１／２ピクセル又は１／４ピクセルの動き推定である。端数ピクセルデータ点を作成するには、実際の（すなわち、フルピクセルアラインされた）データ点に適用される或る形態の補間関数又は補間フィルタを使用することが必要である。
【００９７】
初期のコーデックは、一般に、簡単な双１次補間を使用していた。
Ａ ｘ Ｂ
ｙ ｚ
Ｃ Ｄ
【００９８】
この例では、Ａ、Ｂ、Ｃ、及びＤが、フルピクセルアラインされたデータ点であり、ｘ、ｙ、及びｚが、１／２ピクセルアラインされた点である。点ｘは、Ｘ方向に１／２ピクセルアラインされ、公式：ｘ＝（Ａ＋Ｂ／２）を使用して計算することができる。点ｙは、Ｙ方向に１／２ピクセルアラインされ、公式：ｙ＝（Ａ＋Ｃ／２）を使用して計算することができる。点ｚは、Ｘ及びＹの双方で１／２ピクセルアラインされ、公式：ｚ＝（Ａ＋Ｂ＋Ｃ＋Ｄ／２）を使用して計算することができる。
【００９９】
後のコーデックは、画像がぼける傾向を少なくする、双３次フィルタ等のより複雑な補間フィルタの使用に向かう傾向がある。以下の例では、ｘは、２つのフルピクセルアラインされた点ＢとＣとの間の中点にある１／２ピクセル点である。双３次フィルタに対して整数近似を使用すると、ｘは、公式：ｘ＝（−Ａ＋９Ｂ＋９Ｃ−Ｄ）／１６を使用して計算することができる。
Ａ Ｂ ｘ Ｃ Ｄ
【０１００】
上記に示した双３次フィルタ等のフィルタは、よりシャープに見える結果を生成する傾向があるが、いくつかのフレームにわたってそれらフィルタが繰り返し適用されると、場合によっては、誤ったテキスチャや誤った輪郭等の不快な人工物となる可能性がある。
【０１０１】
本発明のこの態様は、コーデックが、フィルタリング技法を混在させたものを使用して、より最適な端数ピクセルプリディクタを作成でき、クリップレベル、フレームレベル、ブロックレベル、又は個々のピクセルレベルでもこれらの方法から選択を行える方法である。
【０１０２】
好ましい実施態様では、ブロックレベルで、双１次フィルタリングのみを使用するのか、双３次フィルタリングのみを使用するのか、それとも選択を可能にするのかの選択をフレーム単位で行うことができる。
【０１０３】
ブロックレベル又は領域レベルでの選択は、ビットストリーム内の明示的なシグナリングビットによって行うことができるが、好ましい実施態様では、ビットストリームにおいてすでに利用可能な文脈情報を使用し、且つ、フィルタリングされることになる、フルピクセルアラインされたデータ値に適用された複雑度メトリックによって、この選択は行われる。
【０１０４】
動きプリディクタの品質が不十分な状況（たとえば、前のフレームの再構築においてブロックの良好な予測を見つけることができなかった場合）では、双１次フィルタリングは、多くの場合、最善の選択肢となる。具体的には、予測が不十分である場合、双３次フィルタのシャープ化特性は、残差信号の高周波の内容の増加につながる場合があり、符号化をより困難にする場合がある。
【０１０５】
明示的なシグナリングビットがビットストリームにない場合、不十分な予測品質との相関の程度をより大きくしたりより小さくしたりする文脈的に利用可能なさまざまな値を示すことができる。これら値の最も単純なものの１つは、動きベクトル長（motion vector length）である。具体的には、予測の品質は、動きベクトル長の増加と共に劣化する傾向がある。別の可能な指標は、動きフィールドの滑らかさ（すなわち、近傍のブロックの動きベクトルがどれだけ類似しているか）である。
【０１０６】
また、双１次フィルタリングは、ベクトルの選択に信頼性がない（たとえば、画像があまり詳細でなく、類似したエラースコアを有する多くの候補ベクトルがある）状況においてより良い選択肢となる傾向がある。特に、比較的平坦で特徴のない領域に対して多くのフレームにわたり双３次フィルタを繰り返し適用すると、不要な人工物が生み出される場合がある。
【０１０７】
好ましい実施態様では、フィルタリング方法を選ぶ際に２つの因子が考慮される。第１の因子は、動きベクトルの長さである。第２の因子は、フィルタリングされることになる１組のフルピクセルアラインされたデータ点を解析することによって計算される複雑度メトリックＣである。
【０１０８】
双３次フィルタリングは、以下のテスト条件が共に満たされる場合にのみ使用される。
１．動きベクトルが、Ｘ及びＹの双方でしきい値Ｌよりも短い。
２．複雑度Ｃが、しきい値Ｔよりも大きい。
【０１０９】
好ましい実施態様では、Ｃは、公式：
Ｃ＝（ｎΣｘｉ２−（Σｘｉ）２）／ｎ２
に従って計算された１組のｎ個のデータ点ｘｉの分散である。
【０１１０】
好ましい実施態様では、複雑度しきい値Ｔ及び動きベクトル長しきい値Ｌは、フレームごとに１回の割合で、符号化器が設定することができる。
【０１１１】
以下の「Ｃ」コードセグメントは、本発明のこの態様の好ましい実施態様をサポートする詳細を与えるものである。
PredictBlockFunction( … )
{
…
…
if ( pbi->PredictionFilterMode == AUTO_SELECT_PM )
{
// ベクトルがＸ又はＹにおいてしきい値長よりも大きい場合に双１次を使用する
if ( (( abs(pbi->mbi.Mv[bp].x ) > BicMvSizeLimit ||
(( abs(pbi->mbi.Mv[bp].y ) > BicMvSizeLimit))
{
FilterBlockBilinear( … );
}
else
{
// 複雑度メトリック（分散）を計算する。
// 注意：性能の理由から、分散関数は１６個のデータ点
// （８×８ブロックのＸ及びＹの１つおきの点）のみを検査する
Var = Var16Point( DataPtr, Stride );
// 複雑度が所与のしきい値よりも大きい場合には、双３次を使用し、
// そうでない場合には、双１次を使用する
if ( Var >= pbi->PredictionFilterVarThresh )
FilterBlockBilcubic( … )
else
FilterBlockBilinear( … )
}
}
…
…
}
UINT32 Var16Point ( UINT8 *DataPtr, INT32 Stride )
{
UINT32 i, j;
UINT32 XSum=0, XXSum=0;
UINT8 *DiffPtr = DataPtr;
// Ｘ及びＹの１つおきの点を使用する
for ( i = 0; i < BLOCK_HEIGHT_WIDTH; i += 2 )
{
for ( j = 0; j < BLOCK_HEIGHT_WIDTH; j += 2 )
{
XSum += DiffPtr[j];
XXSum += DiffPtr[j] * DiffPtr[j];
}
// ブロックの次の行へステップする
DiffPtr += (SourceStride << 1)
}
// 適合しないメトリックとして母分散を計算する
return(((XXSum*16)-(XSum*XSum))/256);
【０１１２】
＜高度化された動きベクトル符号化＞
慣例により、現代のほとんどのビデオコーデックは、差分符号化方式を使用して、動きベクトルの（ｘ，ｙ）成分を符号化する。すなわち、各ベクトルは、前のベクトルを基準にして符号化される。たとえば、２つのベクトル（７，３）及び（８，４）を考える。この場合、第２のベクトルは（１，１）、すなわち（７＋１，３＋１）として符号化されることになる。
【０１１３】
この方式は、動きベクトルが符号化されるほとんどのブロック又は領域が、その近傍の動きと類似した動きを示す場合によく機能する。これは、多くの場合、たとえばパンする時に当てはまることを示すことができる。しかしながら、動きフィールドが不規則である場合、又は、異なる動き特性を有する背景領域と前景領域との間での遷移が頻繁である場合に、この方式はあまりよく機能しない。
【０１１４】
本発明のこの態様は、差分符号化の利点を保持すると同時に不規則なフィールド及び背景前景遷移の許容範囲がより大きな、動きベクトルを符号化するための代替的なストラテジーである。
【０１１５】
本発明によれば、コーデックは、動きベクトルを符号化できる基準になる２つ又は３つ以上の基準ベクトルを保持する。コーデックは、ビットストリーム内の明示的なシグナリングビットを介してこれらの基準ベクトルを切り換えることができるが、好ましい実施態様では、この決定は、符号化方法、及び、ブロックのすぐ隣のブロックによって使用される動きベクトルに基づく。
【０１１６】
好ましい実施態様では、ブロックは、イントラブロック（intra block）（前のどのフレームにも依存しない）として符号化することもできるし、前のフレームの再構成又は周期的にしか更新されない代替的な基準フレームのいずれかに依存するインターブロック（inter block）として符号化することもできる。
【０１１７】
前のフレームの再構成又は代替的な基準フレームを基準にして符号化する場合、本発明は、以下の符号化モードの選択肢をサポートする。
・動きベクトルなし（すなわち、暗黙的な（０，０）ベクトル）で符号化する。
・「最も近い」近傍と同じベクトルを使用して符号化する。
・「次に最も近い」近傍と同じベクトルを使用して符号化する。
・新たな動きベクトルを使用して符号化する。
【０１１８】
最も近い近傍又は次に最も近い近傍を定義する際、現在のブロックと同じ基準フレームを基準にして符号化されたブロック及び非ゼロの動きベクトルで符号化されたブロックのみが考慮される。他のすべてのブロックは無視される。
【０１１９】
次に最も近い近傍を定義する際、最も近い近傍と同じベクトルで符号化されたブロックも無視される。
【０１２０】
新たな動きベクトルを符号化する際、コーデックは、（０，０）ベクトル又は最も近いベクトルを基準ベクトルとして使用することができる。好ましい実施態様では、最も近いベクトルが得られたブロックが、現在のブロックのすぐ左のブロック又はすぐ上のブロックのいずれかである場合に、その最も近いベクトルが使用される（ブロックは、左から右へ及び上から下へ符号化されるものと仮定する）。他のすべての場合には、新たなベクトルは（０，０）を基準にして符号化される。
【０１２１】
基本的な方法のいくつかの拡張が可能である。最も近い近傍及び次に最も近い近傍が、それぞれ現在のブロックのすぐ左のブロック及びすぐ上のブロックである場合、それら２つから得られた或る種の合成ベクトルを、新たなベクトルを符号化するための基準として使用することができる。あるいは、「最も近い」はｘ成分を予測するのに使用することができ、「次に最も近い」はｙ成分を予測するのに使用することができる。
【０１２２】
別の可能な拡張は、ここでも、最も近い又は次に最も近いが、現在のブロックのすぐ左のブロック及びすぐ上のブロックであると仮定して、最も近いベクトルと次に最も近いベクトルとが類似していない場合を特別に考慮したものである。このような場合、最も近いベクトル及び次に最も近いベクトルは、ｘ、ｙ、又はｘ及びｙの双方の基準値として０に戻る。
【０１２３】
本方法は、規則的な動きフィールド又はゆっくりと変化する動きフィールドがある場合に、単純な差分符号化の利益を保持する。しかしながら、特別な「ベクトルのない」モード、「最も近い」モード、及び「次に最も近いモード」を使用することは、前景と背景との間の遷移をより効率的に符号化するのに役立ち、複数の符号化の起点を自動的に切り換えることができることによって、本方法の不規則な動きフィールドの許容範囲は、より大きくなる。
【０１２４】
以下の「Ｃ」コードセグメントは、本発明のこの態様の好ましい実施態様をサポートする詳細を与えるものである。
// この関数は、現在のブロックについて、限定的な（qualifying）最も近い近傍
// 及び次に最も近い近傍があるかどうか、それらの動きベクトルは何であるか、
// 並びに最も近い近傍がどれだけ接近しているかを判断する。
//
void VP6_FindNearestandNextNearest( PB_INSTANCE *pbi,
UINT32 MBrow,
UINT32 MBcol,
UINT8 ReferenceFrame,
INT32 *Type )
{
int i;
UINT32 OffsetMB;
UINT32 BaseMB = MBOffset( MBrow, MBcol );
MOTION_VECTOR ThisMv;
// デフォルト結果を設定する
*Type = NONEAREST_MACROBLOCK;
// 限定的な「最も近い」ブロックを探索する
for ( i=0; i<12; i++ )
{
OffsetMB = pbi->mvNearOffset[i] + BaseMB;
// ブロックは同じ基準フレームを基準にして符号化されたか？
if ( VP6_Mode2Frame[pbi->predictionMode[OffsetMB]] != ReferenceFrame )
continue;
// 動きベクトルがもしあれば、その動きベクトルは何を使用したか
ThisMv.x = pbi->MBMotionVector[OffsetMB].x;
ThisMv.y = pbi->MBMotionVector[OffsetMB].y;
// それが非ゼロであった場合、限定的な近傍を有する
if ( ThisMv.x || ThisMv.y )
{
Nearest.x = ThisMv.x;
Nearest.y = ThisMv.y;
*Type = NONEAR_MACROBLOCK;
break;
}
}
pbi->mbi.NearestMvIndex = i;
// 限定的な「次に最も近い」ブロックを探索する
for ( i=i+1; i<12; i++ )
{
OffsetMB = pbi->mvNearOffset[i] + BaseMB;
// ブロックは同じ基準フレームを基準にして符号化されたか？
if ( VP6_Mode2Frame[pbi->predictionMode[OffsetMB]] != ReferenceFrame )
continue;
// 動きベクトルがもしあれば、その動きベクトルは何を使用したか
ThisMv.x = pbi->MBMotionVector[OffsetMB].x;
ThisMv.y = pbi->MBMotionVector[OffsetMB].y;
// このベクトルが「最も近い」ベクトルと同じである場合、このベクトルを無視する
if ((ThisMv.x == Nearest.x) && (ThisMv.y == Nearest.y))
continue;
// それが非ゼロであった場合、限定的な近傍を有する
if ( ThisMv.x || ThisMv.y )
{
NextNearest.x = ThisMv.x;
NextNearest.y = ThisMv.y;
*Type = MACROBLOCK;
break;
【０１２５】
＜エラー回復における代替的な基準フレームの使用＞
ビデオコーデックは、多くの場合、ビットストリームのエラーの影響を極端に受けやすいので、信頼性のないデータリンク上で圧縮ビデオデータを送信する場合、データが喪失又は破損したときの回復のためのメカニズムが存在することは重要である。
【０１２６】
このようなリンクの信頼性のあるデータ送信のためのさまざまな技法及びプロトコルが存在し、これらは、通常、エラーの検出、及び、再送又は一定のタイプのエラーの訂正を可能にする追加データビットの使用のいずれかに依拠する。
【０１２７】
多くの状況では、これら既存の技法は十分である。しかし、制限された帯域幅のリンク上でビデオ会議を行う場合、上述した手法のいずれも理想的ではない。喪失したデータパケットの再送は、端末間の遅延の増加を引き起こす可能性があるので実用的でない場合がある一方、誤り訂正ビット又は誤り訂正パケットの使用は、帯域幅がすでに厳しく制限されている状況では受け入れられない場合がある。
【０１２８】
代替的な手法は、単に、復号器においてエラーを検出し、そのエラーを符号化器に報告することである。符号化器は、その後、回復フレームを復号器へ送信することができる。この手法は、リンク上のエラーレートが非常に高い場合、適切でないおそれがあることに留意されたい。たとえば、１０フレーム〜２０フレームごとに２つ以上のエラーがある場合である。
【０１２９】
最も簡単な形態の回復フレームは、キーフレーム（又はイントラオンリーフレーム）である。これは、前のフレーム又は前のフレームのデータに何ら依存関係を有しないフレームである。キーフレームに関連した問題は、それらキーフレームが、通例、比較的大きいということである。
【０１３０】
発明５の対象は、コーデックが、回復フレームのより効率的な符号化のための開始点として使用できる１つ又は複数の追加された基準フレーム（前に符号化されたフレームの再構成以外）を保持するメカニズムである。
【０１３１】
本発明の好ましい実施態様では、コーデックは、キーフレームが存在する時は常に、且つ、オプションとしてそれ以外の時に、フレームヘッダのフラグビットを介して更新される第２の基準フレームを保持する。たとえば、符号化器は、「Ｘ」秒ごとに１回又はエラー回復フレームが符号化される時は常に第２の基準フレームを更新することを選択することができる。
【０１３２】
第２の基準フレームの内容が、少なくともいくつかの点で現在のフレームの内容と類似しているという条件で、この第２の基準フレームを基準にした差分符号化は、キーフレームを符号化するよりもはるかに安価になる可能性がある。
【０１３３】
１つ又は複数の代替的な基準フレームを使用して、圧縮品質又は圧縮効率を高めることができるいくつかの方法がある。従来技術に含まれる１つの明らかな使用は、２つ又は３つ以上の異なるシーン間を行ったり来たりするビデオシーケンスにおいてである。たとえば、ビデオがインタビューする側とインタビューされる側との間で行ったり来たりするインタビューを考える。各カメラアングル用のベースラインとして別々の基準フレームを記憶することにより、これらの間を行ったり来たりするコストを大きく削減することができ、特に、シーンが大幅に異なる場合に大きく削減することができる。
【０１３４】
本発明は、代替的な基準フレームをこのように使用する選択肢を有するが、本発明の対象は、ビデオにゆっくりとした漸進的変化がある状況において、周期的に更新された代替的な基準フレームを使用して、圧縮されたビデオの品質を高めることである。この良い例はゆっくりとしたパン、ズーム、又はトラッキングショットである。
【０１３５】
本発明のこの態様によれば、ゆっくりとしたパン又は他のこのようなゆっくりとした漸進的変化の間、符号化器は、周囲のフレームよりもきわめて高い品質で符号化され、且つ、第２の又は代替的な基準フレームの更新を引き起こすフレームを周期的に挿入する。
【０１３６】
これらの高い品質の「第２の基準の更新」フレームの目的は、最後のキーフレーム以来又は最後の第２の基準の更新以来、次第に喪失してきた細部を元に戻すこと、及び、後続のフレームのインターフレーム予測のより良い基礎を提供することである。品質（したがってデータレート）を周期的に引き上げると同時に第２の基準フレームを更新するこのストラテジーは、いくつかの状況では、単にすべてのフレームを同様の品質で符号化することよりもはるかに良好なコスト／品質トレードオフを提供することを示すことができる。
【０１３７】
第２の基準の更新の適切な間隔、及び、品質又はデータレートを増加させるべき量を決定するための方法は、有効な実施態様の中心となる。
【０１３８】
本発明のこの態様の好ましい実施態様では、いくつかの因子が考慮される。これらの因子には、以下のものが含まれる。
・動きの速度の指標として、数個の先行フレームにおける動きベクトルの平均振幅。
・動きフィールドが相関する程度。たとえば、動きベクトルがすべてかなり類似している。
・前の数フレームにおける前のフレームの再構成に優先して、第２の基準フレームがプリディクタとして使用された程度。
・周囲の品質又は量子化器の設定。
【０１３９】
使用された動きベクトルの平均振幅が高い場合（高速の動きを示す）、第２の基準の更新間隔及び品質ブースト（quality boost）はともに減少する。逆に、動きがゆっくりとしている場合、より大きな品質ブースト及びより長い間隔が使用される。
【０１４０】
動きフィールドが高い相関を有する場合、すなわち、類似した動きベクトルが多数ある場合、第２の基準フレームの更新のための品質ブーストは増加する。逆に、動きフィールドの相関が乏しい場合、ブーストの程度は減少する。
【０１４１】
第２の基準フレームが、前のフレームの再構成に優先して、プリディクタとして頻繁に使用されている場合、品質ブーストは増加する。逆に、第２の基準フレームが頻繁に使用されない場合、品質ブーストは減少する。
【０１４２】
また、品質ブーストの程度は、周囲の品質にも或る程度依存し、周囲の品質が低い場合には大きなブーストが使用され、周囲の品質が高い場合には小さなブーストが使用される。
【０１４３】
以下の擬似コードは、本発明のこの態様の好ましい実施態様の詳細をより与えるものである。
【０１４４】
各フレームについて
１／４ピクセル単位で指定されたＸ及びＹの動きベクトル成分の平均振幅（ＡｖＸ及びＡｖＹ）を計算する。
ＭｏｔｉｏｎＳｐｅｅｄ（動きの速度）＝ＡｖＸ及びＡｖＹの大きい方
Ｘ及びＹの動きベクトル成分の分散数（ＶａｒｉａｎｃｅＸ（分散Ｘ）及びＶａｒｉａｎｃｅＹ（分散Ｙ））を計算する
ＭａｘＶａｒｉａｎｃｅ（最大分散）＝ＶａｒｉａｎｃｅＸ及びＶａｒｉａｎｃｅＹの大きい方
ＭｏｔｉｏｎＣｏｍｐｌｅｘｉｔｙ（動きの複雑度）＝ＭｏｔｉｏｎＳｐｅｅｄ＋（ＶａｒｉａｎｃｅＸ／４）＋（ＶａｒｉａｎｃｅＹ／４）
第２の基準フレームの更新がまさにこのフレームである場合
そのフレームの予測された品質インデックス（実際には量子化器の設定）に基づいてデータレート％ブースト数（Ｂｏｏｓｔ）を計算する。これは、最高品質の＋０％と、品質レベルが非常に低い時の＋１２５０％との範囲とすることができる。
ＢｏｏｓｔにＭｏｔｉｏｎＳｐｅｅｄ訂正係数（correction factor）を乗算する。ここで、この係数は、ＭｏｔｉｏｎＳｐｅｅｄが非常に小さい値である場合の１と、ＭｏｔｉｏｎＳｐｅｅｄが大きな値である場合の０との間で変化することができる。
第２の基準フレームが前の数フレームで使用された程度に基づいて、さらに別の訂正係数をＢｏｏｓｔに適用する。この別の訂正係数は、第２の基準フレームが前の数フレームで全く使用されなかった場合の１／１６から、第２の基準フレームが符号化されたブロックの１５％以上に使用された場合の１まで変化することができる。
次に、一連のテストが適用されて、先に進むかどうか、及び、計算された％ブーストで第２の基準フレームを更新するかどうかが判断される。
【０１４５】
主なテストは次の通りである。
（Ｂｏｏｓｔ＞ＭｉｎＢｏｏｓｔＴｒｅｓｈｏｌｄ）且つ
（ＭｏｔｉｏｎＳｐｅｅｄ＜ＭａｘＭｏｔｉｏｎＳｐｅｅｄＴｈｒｅｓｈｏｌｄ）且つ
（ＭａｘＶａｒｉａｎｃｅ＜ＭａｘＶａｒｉａｎｃｅＴｈｒｅｓｈｏｌｄ）
ここで、ＭｉｎＢｏｏｓｔＴｒｅｓｈｏｌｄ、ＭａｘＭｏｔｉｏｎＳｐｅｅｄＴｈｒｅｓｈｏｌｄ、及びＭａｘＶａｒｉａｎｃｅＴｈｒｅｓｈｏｌｄは構成可能なパラメータである。
【０１４６】
本発明は、複数の特別な「動き再利用」モードを有する。これらの「動き再利用」モードは、或るブロックの動きベクトルが、その近くにある近傍のブロックの１つによって使用された動きベクトルと同じである場合に、当該或るブロックの動きベクトルをより安価に符号化することを可能にするものである。これらのモードの使用がしきい値レベル未満に下がる場合を減らすためのさらなるテストが適用される。
【０１４７】
ブーストを適用して第２の基準フレームを更新する決定がなされた場合、フレームデータレート目標値をベースライン値＋Ｂｏｏｓｔ％に設定し、計算し、ＭｏｔｉｏｎＳｐｅｅｄに基づく次の更新までの間隔。
【０１４８】
ブーストを適用せず、第２の基準フレームを更新しない決定がなされた場合、０％のデータレートブーストで通常通りフレームを更新する。
【０１４９】
それ以外の場合、第２の基準フレームの更新は行われるべきではない。
【０１５０】
第２の基準フレームが最後に更新された時に適用されたブーストのレベル及び現在の更新間隔を考慮した、削減されたフレームデータレート目標値（負のブースト）を計算する。
【０１５１】
＜再構成エラーメトリックを使用した、端数ピクセル予測を作成するための代替的な方法の選択＞
現代の多くのビデオコーデックは、サブピクセル精度に対する動きの予測をサポートする。たとえば、１／２ピクセル又は１／４ピクセルの動き推定である。端数ピクセルデータ点を作成するには、実際の（すなわち、フルピクセルアラインされた）データ点に適用される或る形態の補間関数又は補間フィルタを使用することが必要である。
【０１５２】
初期のコーデックは、一般に、簡単な双１次補間を使用していた。
Ａ ｘ Ｂ
ｙ ｚ
Ｃ Ｄ
【０１５３】
この例では、Ａ、Ｂ、Ｃ、及びＤが、フルピクセルアラインされたデータ点であり、ｘ、ｙ、及びｚが、１／２ピクセルアラインされた点である。
＊点ｘは、Ｘ方向に１／２ピクセルアラインされ、公式（Ａ＋Ｂ／２）を使用して計算される。
＊点ｙは、Ｙ方向に１／２ピクセルアラインされ、公式（Ａ＋Ｃ／２）を使用して計算される。
＊点ｚは、Ｘ及びＹの双方で１／２ピクセルアラインされ、公式（Ａ＋Ｂ＋Ｃ＋Ｄ／２）を使用して計算される。
【０１５４】
後のコーデックは、画像がぼける傾向を少なくする、双３次フィルタ等のより複雑な補間フィルタの使用に向かう傾向がある。以下の例では、「ｘ」は、２つのフルピクセルアラインされた点ＢとＣとの間の中点にある１／２ピクセル点である。ｘは、公式（−Ａ＋９Ｂ＋９Ｃ−Ｄ）／１６を使用して計算することができる。
Ａ Ｂ ｘ Ｃ Ｄ
【０１５５】
上記に示した双３次フィルタ等のフィルタは、よりシャープな結果を生成する傾向があるが、いくつかのフレームにわたってそれらフィルタが繰り返し適用されると、時に、テキスチャの誇張や誤った輪郭等の不快な人工物となる可能性がある。
【０１５６】
本発明のこの態様は、コーデックが、双１次フィルタリング及び双３次フィルタリングの混在したものを使用して、より最適な端数ピクセルプリディクタを計算することができ、フレームレベル、又は、動きベクトルが適用される個々のブロックもしくは領域のレベルのいずれかでこれらの方法を選択することができる方法である。
【０１５７】
ブロックレベル又は領域レベルでの選択は、ビットストリーム内のシグナリングビットによって行うことができるが、好ましい実施態様では、この選択は、フィルタリングされることになる前の再構成された画像の１組のピクセルに適用された複雑度メトリックによって行われる。
【０１５８】
本方法によれば、しきい値「Ｔ」よりも大きな複雑度スコアを有するブロック又は領域は、双３次方法を使用してフィルタリングされるのに対して、これより低い複雑度スコアを有するブロック又は領域は、双１次方法を使用してフィルタリングされる。
【０１５９】
好ましい実施態様では、複雑度メトリックは、フィルタリングされる１組の「ｎ」個のフルピクセルアラインされたデータ点の分散である。ここで、分散は次のように定義される。
（ｎ？ｘ２−（？ｘ）２）／ｎ２
【０１６０】
好ましい実施態様では、しきい値「Ｔ」は、フレームごとに１回更新することができる。
【技術分野】
【０００１】
［関連出願］
本出願は、２００３年５月１２日に出願された米国仮特許出願第６０／４６９，１８７号及び２００３年１１月１４日に出願された米国特許出願第１０／７１３，８０７号の優先権を主張する。
【０００２】
本発明は、ビデオデータに関し、より詳細には、できるだけ効率的な方法でビデオデータの符号化、復号、圧縮、及び送信を行う方法及びシステムに関する。
【背景技術】
【０００３】
データの送信は、通例、帯域幅及びスループットの制限によって制約を受ける。微少な時間で無限の情報量を送信することも受信することもできない。送信中の情報の量及び品質を最大にするために、場合により、情報は、圧縮又は符号化されて送信され、受信時に伸張又は復号される。
【０００４】
データ圧縮が不可欠である１つの分野は、ビデオデータの送信である。通常のテキストは、膨大でない限り、容易且つ高速に送信される。しかしながら、ビデオデータは、色の側面、明度の側面、及び多くの場合ステレオ音響情報の側面を含む可能性がある。短いビデオクリップであっても、定義するのに大量のデータが必要とされる。このようなデータの送信及び符号化は、できるだけ効率的でなければならない。すなわち、送信するのに必要な情報をできるだけ少なくしなければならない。
【０００５】
ビデオ圧縮は、データ圧縮の一般的な技法のサブセットである。データ圧縮によって、信号は、より小さな数字の集合にスクイーズ又は圧縮される。これらの数字は、したがって、ハードドライブを占める空間が小さくなるか、又は、ネットワーク上で送信に要する時間が少なくなる。これらの数字が再び使用される前に、伸張アルゴリズムが適用されて、その数字列は、その元の（又は少なくとも類似の）形に展開される。
【０００６】
記憶もしくは送信される数字列に適用できる圧縮比又はスクイーズ量を増加させるために、ビデオ圧縮は、信号が、デジタル化されたビデオとして発生していることが知られているという事実を利用する。ビデオ及びオーディオの大幅な圧縮は非可逆アルゴリズムを考えられる。その理由は、非可逆アルゴリズムが元の情報の或る部分を廃棄するか又は失い、再現された数字列は元の数字列とは正確には一致しないからである。我々がビデオ及びオーディオを鑑賞する精度は、デジタル化プロセスの解像度と比較して完全でないことから、これは許容することができる。ビデオ信号は、僅かに歪む場合があるが、それにもかかわらず認識することが可能である。圧縮アルゴリズムが、最小の歪み又は損失で元の信号を忠実に再現できる程度は、アルゴリズムの成功の尺度である。
【０００７】
技術的な問題及び機器のコストを含めて、ビデオ信号及びオーディオ信号を圧縮するもっともな理由が多数ある。１つの最優先の問題は、データ送信コストである。インターネットは、２１世紀の事実上のデータ搬送プラットフォームに成熟するにつれて、ビデオテープ、フィルム、放送等のアナログメディアは、インターネット技術及びインターネット関連技術の上に構築されたデジタルメディアインフラストラクチャに取って代わられることになろう。このデジタルインフラストラクチャにより、必要に応じて、地球上のどの２つのコンピューティングマシン間でもデータを転送することが可能になる。しかしながら、このデータを送信できる速度は多数の要因に依存する。極端な場合、百年以上も前に敷設され、アナログ音声通信を対象とした銅線が、モデム技術（モデム（modem）は、モジュレーション（変調（Modulation））／ディモジュレーション（復調（DEModulation））の略語である）と共に使用されて、毎秒９６００ビット程度の低速でデータが送信される。同様の速度は、携帯電話等の無線ネットワーク上で音声を運ぶのにも使用される。最近、ケーブルモデム技術、ＤＳＬ技術、及び衛星技術が、６桁のデータレート（１００，０００ビット／秒から１００万ビット／秒）をホームユーザにもたらしている。ハイエンドアプリケーションの場合、光ファイバによって、データレートをギガビットの範囲（毎秒数十億ビット）及びそれを超える範囲にすることが可能である。
【０００８】
所与のアプリケーションに利用可能なデータレートがいかなるものであっても、データの送信には、お金がかかる。現在のところ、１メガバイト（８００万ビット）をインターネット上で送信するコストは、通例、小さなボリュームの５セントあたりから、安い場合は極端に大きなボリュームの１セント程度のコストがかかる（この価格は、受信端でのコストを含んでいない）。したがって、或る場所から別の場所へ１メガバイトのデータを搬送するコストは、常に、１ペニーよりも高い。
【０００９】
ビデオデータ圧縮の分野では、多くの研究が行われてきた。本出願の譲受人である、ニューヨーク州クリフトンパークのOn2 Technologies（当初はDuck Corporationとして知られていた）は、既にＶＰ３やＶＰ５等のコーデックを製造してきており、Microsoft Corporationは、ＭＰＥＧ等の符号を作成してきた。既存のビデオコーデックの特徴のいくつかには、動きベクトルの離散コサイン変換圧縮、エントロピー符号化、及び差分符号化が含まれる。また、従来のコーデックは、基準フレームを利用し、データパケットが喪失又は破損した場合に、基準フレームを参照することによってそのデータを取り出すことができるようにしている。これらの特徴及びこれらの特徴に伴う問題のすべてについて、以下でより詳細に解説することにする。
【００１０】
ＤＣＴ（離散コサイン変換（Discrete Cosine Transform））に基づくビデオ圧縮システムでは、８×８のピクセルブロック又は予測エラー信号データが、１組の６４個の周波数係数（１つのＤＣ値及び６３個のＡＣ値）に変換される。これら６４個の周波数係数は、その後、量子化されて１組のトークンに変換される。
【００１１】
通常、高周波のＡＣ係数ほど、大きさが小さくなり、したがって、次の量子化で非ゼロになる可能性は小さくなる（すなわち、ゼロになる可能性が高くなる）。その結果、トークン化の前に、それら係数は、多くの場合、最も低い周波数係数（ＤＣ値）から開始して最も高周波のＡＣ係数で終了する昇順に配列される。この走査順序は、時に、「ジグザグ順序」と呼ばれることがあり、その始点に非ゼロ値を集め、終点に向かうにつれてゼロを集める傾向があり、そうすることによって、より効率的な圧縮を容易にする。
【００１２】
しかしながら、この固定された走査順序は、最適になることがほとんどない。たとえば、インターレースされたビデオ素材を符号化する場合、一定の高周波係数は、はるかに顕著である。このことは従来技術に反映され、この従来技術では、インターレースされたビデオを符号化する時に代替的な走査順序を指令するコーデックが使用される例（たとえば、ＭＰＥＧ−２）が存在する。
【００１３】
特定のハードウェアデバイス用にコーデックを最適化する場合、そのデバイスが複数のタスクを並列に実行するのに提供できるあらゆる設備が十分に利用されることを確かめること、及び、復号プロセスの個々の部分がボトルネックとなる範囲を制限することが重要である。
【００１４】
本発明のビットストリームは、ほとんどの他のビデオコーデックと共通して、概して言えば、エントロピー符号化されたトークンを含むものとして説明することができる。このエントロピー符号化されたトークンは、プリディクタ（predictor）トークン又はＰトークン、及び、予測エラートークン又はＥトークンの２つの主要なカテゴリーに分割することができる。Ｐトークンは、画像のブロック又は領域を符号化するのに使用される方法又はモードを記述するトークンであり、或るフレームと別のフレームとの間の動きを記述するトークンである。Ｅトークンは、不完全な予測の結果生じたあらゆる残差を符号化するのに使用される。
【００１５】
エントロピー符号化は、ビットストリームにおける特定のＰトークン又はＥトークンの表現が、ビットストリームにおけるそのトークンの周波数、又は、そのトークンが特定の位置に現れる尤度に従って最適化されるプロセスである。たとえば、非常に頻繁に現れるトークンは、まれにしか現れないトークンよりも少ないビット数を使用して表される。
【００１６】
最も一般的なエントロピー符号化技法の２つは、ハフマン符号化及び算術符号化である。ハフマン符号化では、各トークンは、可変長のビットパターン（又は符号）によって表される。算術符号化は、計算がより複雑な技法ではあるが、各トークンについて多数のビット全体を使用する制約が除去されている。算術符号化器を使用すると、１ビットの１／２の平均コストで非常に一般的なトークンを符号化することが完全に可能である。
【００１７】
多くのマルチメディアデバイスは、エントロピー符号化のタスクによく適合したコプロセッサユニット、及び、より多目的のメインプロセッサを有する。その結果、並列化のために、ビットストリームの符号化又は復号のプロセスは、多くの場合、エントロピーに関連したタスクと、エントロピーに関連しないタスクとに分割される。しかしながら、所与のビットクリップの場合、データレートが増加するにつれて、符号化／復号するトークン数が急激に上昇し、エントロピー符号化がボトルネックになる場合がある。
【００１８】
従来のビットストリームでは、エントロピー符号化の計算負荷を再分散させて、このボトルネックを取り除くことは非常に困難である。特に、復号側では、通常は、トークンが符号化された順序で１度に１つずつトークンを復号しなければならない。また、フレームレベル以外の方法又はエントロピー符号化（たとえば、ハフマン符号化及び算術符号化）を混在させることもきわめて困難である。
【００１９】
慣例により、現代のほとんどのビデオコーデックは、差分符号化方式を使用して、動きベクトルの（ｘ，ｙ）成分を符号化する。すなわち、各ベクトルは、前のベクトルを基準にして符号化される。たとえば、２つのベクトル（７，３）及び（８，４）を考える。この場合、第２のベクトルは（１，１）、すなわち（７＋１，３＋１）として符号化されることになる。
【００２０】
この方式は、動きベクトルが符号化されるほとんどのブロック又は領域が、その近傍の動きと類似した動きを示す場合によく機能する。これは、多くの場合、たとえばパンする時に当てはまることを示すことができる。しかしながら、動きフィールドが不規則である場合、又は、異なる動き特性を有する背景領域と前景領域との間での遷移が頻繁である場合に、この方式はあまりよく機能しない。
【００２１】
現代のほとんどのビデオコーデックにとって、動き予測は、圧縮プロセスの重要な部分である。動き予測は、画像の物体又は領域の動きが、１つ又は複数のフレームにわたってモデル化され、１つ又は複数の「動きベクトル」が、この動きを表すためのビットストリームで送信されるプロセスである。ほとんどの場合、画像内の動きを完全にモデル化することはできず、そこで、動き情報に加えて残差信号を符号化することが必要である。
【００２２】
基本的に、各動きベクトルは、符号化される現在のフレームの領域と類似した、前に符号化されたフレームの領域を指し示す。残差信号は、各ピクセルの予測値を、現在のフレームの実際の値から差し引くことによって得られる。
【００２３】
現代の多くのビデオコーデックは、たとえば、１／２ピクセル又は１／４ピクセルの動き推定といったサブピクセル精度に対して動き予測のサポートを提供することによりこのプロセスを拡張している。端数ピクセルデータ点を作成するには、実際の（すなわち、フルピクセルアラインされた（full pixel aligned））データ点に適用される或る形態の補間関数又は補間フィルタを使用することが必要である。
【００２４】
初期のコーデックは、一般に、本明細書に添付した図１に示すような簡単な双１次補間を使用していた。この例では、Ａ、Ｂ、Ｃ、及びＤが、フルピクセルアラインされたデータ点であり、ｘ、ｙ、及びｚが、１／２ピクセルアラインされた点である。点ｘは、Ｘ方向に１／２ピクセルアラインされ、方程式：
ｘ＝（Ａ＋Ｂ／２） （１）
を使用して計算することができる。
点ｙは、Ｙ方向に１／２ピクセルアラインされ、方程式：
ｙ＝（Ａ＋Ｃ／２） （２）
を使用して計算することができる。
点ｚは、Ｘ及びＹの双方で１／２ピクセルアラインされ、方程式：
ｚ＝（Ａ＋Ｂ＋Ｃ＋Ｄ／２） （３）
を使用して計算することができる。
【００２５】
後のコーデックは、画像がぼける傾向を少なくする、双３次フィルタ等のより複雑な補間フィルタの使用に向かう傾向がある。図２に示す例では、ｘは、２つのフルピクセルアラインされた点ＢとＣとの間の中点にある１／２ピクセル点である。双３次フィルタに対して整数近似を使用すると、ｘは、方程式：
ｘ＝（−Ａ＋９Ｂ＋９Ｃ−Ｄ）／１６
を使用して計算することができる。
【００２６】
上記に示した双３次フィルタ等のフィルタは、よりシャープに見える結果を生成する傾向があるが、いくつかのフレームにわたってそれらフィルタが繰り返し適用されると、場合によっては、誤ったテキスチャや誤った輪郭等の不快な人工物となる可能性がある。
【００２７】
ビデオコーデックは、多くの場合、ビットストリームのエラーの影響を極端に受けやすいので、信頼性のないデータリンク又は問題の多いデータリンク上で圧縮ビデオデータを送信する場合、データが喪失又は破損したときの回復のためのメカニズムが存在することは重要である。
【００２８】
このようなリンクの信頼性のあるデータ送信のためのさまざまな技法及びプロトコルが存在し、これらは、通常、エラーの検出、及び、再送又は一定のタイプのエラーの訂正を可能にする追加データビットの使用のいずれかに依拠する。多くの状況では、これら既存の技法は十分である。しかし、制限された帯域幅のリンク上でビデオ会議を行う場合、上述した手法のいずれも理想的ではない。喪失したデータパケットの再送は、端末間の遅延の増加を引き起こす可能性があるので実用的でない場合がある一方、誤り訂正ビット又は誤り訂正パケットの使用は、帯域幅がすでに厳しく制限されている状況では受け入れられない場合がある。
【００２９】
代替的な手法は、単に、復号器においてエラーを検出し、そのエラーを符号化器に報告することである。符号化器は、その後、回復フレームを復号器へ送信することができる。この手法は、リンク上のエラーレートが非常に高い場合、たとえば、１０フレーム〜２０フレームごとに２つ以上のエラーがある場合に、適切でないおそれがあることに留意されたい。
【００３０】
最も簡単な形態の回復フレームは、キーフレーム（又はイントラオンリーフレーム（intra-only-frame））である。これは、前のフレーム又は前のフレームのデータに何ら依存関係を有しないフレームである。キーフレームに関連した問題は、それらキーフレームが、通例、比較的大きいということである。
【発明の開示】
【発明が解決しようとする課題】
【００３１】
本発明の目的は、効率的で信頼性のあるビデオ圧縮方法及びコーデックを提供することである。
【００３２】
本発明の別の目的は、適応性のある方法で離散コサイン変換を実行できるビデオ圧縮方法及びコーデックを提供することである。
【００３３】
本発明の別の目的は、使用されるハードウェアデバイスの資源を最適化するエントロピー符号化を実行するビデオ圧縮方法及びコーデックを提供することである。
【００３４】
本発明の別の目的は、動きベクトル符号化を高度化するビデオ圧縮方法及びコーデックを提供することである。
【００３５】
本発明の別の目的は、端数ピクセル動き予測を正確且つ効率的に実行するビデオ圧縮方法及びコーデックを提供することである。
【００３６】
本発明の別の目的は、ビデオ会議の環境であっても、エラー回復を効率的に実行するビデオ圧縮方法及びコーデックを提供することである。
【課題を解決するための手段】
【００３７】
本発明により上記の又は他の目的が達成され、本発明は、各ブロックがピクセルの配列を有する少なくとも１つのブロックを有する少なくとも１つのフレームを有するビデオデータを圧縮する方法である。本発明の方法は、以下のステップの少なくとも１つを含む。Ｉ）各ブロックのピクセルを係数に変換して、係数の最適な送信順序を作成するステップ、ＩＩ）データのビットストリームを区画して各パーティションを独立に符号化することにより、圧縮されたビデオデータを処理する速度を最適化するステップ、ＩＩＩ）所与の各ブロックに関連した少なくとも１つのメトリックに応じて所与の各複数のピクセルの補間方法を選択することにより、端数ピクセル動きを予測するステップ、及び、ＩＶ）現在のフレームの直前のフレームよりも前のフレームを唯一の基準フレームとして使用して現在のフレームのエラー回復を高度化するステップであって、それによって、データ送信中の品質損失を小さくする、現在のフレームのエラー回復を高度化するステップ。
【００３８】
本発明の係数の再配列の態様に関して、本方法は、各ブロックのピクセルを、各係数が係数位置及び値を有する係数に変換し、各係数位置に関連した位置の値を求める。次に、係数の最適な送信順序が、各係数位置の位置の値に基づいて作成され、係数は、そのようにして求められた順序で送信される。好ましくは、係数の送信順序は、ビデオデータの各フレームについて動的に再配列される。変換ステップは、好ましくは、ピクセルを離散コサイン変換係数に変換する。係数の送信順序は、係数と共に送信してもよい。好ましくは、各ブロックは、同じ個数の係数及び係数位置を有し、それぞれの対応する各係数位置は、ブロックごとに同じ各情報を運ぶ。
【００３９】
送信されるデータ量を削減するために、係数順序データの送信は、或るフレームから次のフレームへ係数順序が変更したものに制限してもよい。これに代えて又はこれに加えて、送信順序は係数の帯域に統合してもよい。各帯域は、上記で求められた数のランクによって編成された複数の係数を有する。この場合、帯域情報のみを係数と共に送信してもよい。好ましくは、係数が或るフレームから次のフレームにおいて帯域を変更した場合に、帯域情報のみが送信される。別の代替的なものとして、すべての帯域情報を常に送信してもよい。
【００４０】
係数を再配列することは、キーフレームを提供することも含むことができる。本発明の方法は、常に完全に自己符号化され、前のフレームからの情報も前のフレームに関する情報も必要としないこのようなキーフレームを提供してもよい。このような場合、符号化器は、所与のフレームがキーフレームであるかどうかを判断する。所与のフレームがキーフレームであると判断された場合、そのキーフレームの係数の送信順序全体が送信される。所与のフレームがキーフレームでないと判断された場合、前のフレームからこの所与のフレームにおいて係数の送信順序が変化したもののみが送信される。
【００４１】
上述したように、本発明は、データビットストリームを区画して各パーティションを独立に符号化することにより、圧縮ビデオデータの処理速度を最適化することを検討する。具体的には、本発明は、ビデオデータを少なくとも２つのデータパーティションに分割し、各データパーティションについて最適なエントロピー符号化方法を選択する。したがって、選択されたエントロピー符号化方法は、各データパーティションにそれぞれ適用される。１つの実施の形態では、ビデオデータは、プリディクタトークンデータパーティション及びエラートークンデータパーティションに分割される。好ましくは、各データパーティションは、ハフマン符号化及び算術符号化等の異なるエントロピー符号化方法を受ける。異なるデータパーティションのさまざまな復号プロセスは、非同期且つ／又は独立に実行してもよい。これは、ハードウェアに少なくとも２つのサブプロセッサを設けることによって行ってもよく、或るデータパーティションは或るサブプロセッサによって復号され、別のデータパーティションは別のサブプロセッサによって復号される。所与のデータパーティションにどのエントロピー符号化方法が使用されるかの判断は、その所与のデータパーティションのサイズに基づいてもよい。
【００４２】
本方法及びコーデックの１つの好ましい実施の形態では、プリディクタトークンデータパーティションは読み出されて、プリディクタブロックに変換される。エラートークンデータパーティションも読み出されて、係数及びそこからエラーブロックに変換される。プリディクタブロック及びエラーブロックは合計されて、画像ブロックが形成される。上述したように、少なくとも２つのサブプロセッサを設けることが好ましく、これらのステップのいくつかは、或るサブプロセッサで実行され、ステップの残りは別のサブプロセッサで実行される。具体的には、エラートークンデータパーティションを読み出すステップ、及び、エラートークンデータパーティションを係数に変換するステップは、好ましくは、高速エントロピー最適化サブプロセッサによって実行され、他のステップは、好ましくは、汎用サブプロセッサによって実行される。
【００４３】
本発明の方法は、データ及びコードのキャッシュミスを回避するようにビットストリームの復号器の性能を最適化する。コードキャッシュに適合できる個数の、復号器のコードの異なる関数がコードキャッシュに記憶される。このステップからのコードは、データキャッシュに適合できる個数のブロックについて実行される。復号器のコードの次の１組の異なる関数及び次に収集され、このプロセスは、ビットストリームのすべてが読み出され、データブロックのそれぞれが生成されるまで繰り返される。
【００４４】
ビットストリームの復号器の性能を最適化する別の態様は、各サブタスクを別々のプロセッサへ割り当てることによってサブプロセッサの利用を最適化するものである。好ましくは、ビットストリームからエラートークンを読み出して、それらエラートークンを係数に変換する、復号器の部分は、高速エントロピー最適化サブプロセッサで実行される。ビットストリームからプリディクタトークンを読み出して、これらのトークンからフィルタリングされたプリディクタブロックを構築する、復号器の部分は、メモリへの高速アクセスを有するサブプロセッサで実行される。上記ステップからの変換係数をエラー信号に変換する、復号器の部分は、変換符号化器の最適化された実施態様を有するサブプロセッサで実行され、プリディクタブロックをエラー信号に加える、復号器の部分は、動き補償に最適化されたサブプロセッサで実行される。
【００４５】
ビデオデータは、２つのデータパーティションに分割してもよい。第１のデータパーティションはフレームの第１のエリアを表し、第２のデータパーティションはフレームの第２のエリアを表す（たとえば、上半分及び下半分、又は、左半分及び右半分）。或いは、ビデオデータは、３つのデータパーティションに分割してもよい。各データパーティションは、それぞれ、フレームのレベル情報、彩度情報、及び色相情報を表す。別の変形では、これら３つのデータパーティションは、それぞれ、フレームのシアン情報、マゼンタ情報、及びイエロー情報を表すことができる。
【００４６】
前述したように、本発明は、各所与のブロックに関連した少なくとも１つのメトリックに応じて各所与の複数のピクセルの補間方法を選択することにより、端数ピクセル動きを予測する態様を含む。具体的には、符号化する所与の複数のピクセルに関連した少なくとも１つのメトリックの値が求められ、その所与の複数のピクセルを符号化する補間方法が、求められた少なくとも１つのメトリックの値に応じて選択される。このようにして選択された補間方法は、符号化する所与の複数のピクセルに適用される。このプロセスは、次の各複数のピクセルについて繰り返されるステップである。少なくとも１つのメトリックは、動きベクトル長及び複雑度因子の少なくとも１つとしてもよい。補間方法には、双１次補間、双３次補間、２次補間、及びＢスプライン補間が含まれ得る。所与の複数のピクセルは、フレーム全体としてもよいし、フレームのサブ部分としてもよい。所与の複数のピクセルに関連した動きベクトル長が、所定の長さ値よりも小さいと判断され、且つ、所与の複数のピクセルに関連した複雑度因子が、所定の複雑度値よりも大きいと判断された場合、双３次補間が選択される。所定の長さ値及び所定の複雑度値は、好ましくは、所与の個数の複数のピクセルについて１回設定され、且つ、フレームごとに１回設定される。
【００４７】
複雑度因子は、好ましくは、所与の複数のピクセルの分散であり、次のように計算される。
Ｃ＝（ｎΣｘｉ２−（Σｘｉ）２）／ｎ２ （４）
【００４８】
上述したように、本発明は、現在のフレームの直前のフレームよりも前のフレームを、データ送信中の品質損失を少なくするための唯一の参照フレームとして使用して、現在のフレームのエラー回復を高度化することを含む。具体的には、本発明は、喪失又は破損したパケットを引き起こす、ライン上の送信に関連した品質損失を少なくするために、最後のフレームよりも前に符号化されたフレームを、所与のフレームの唯一の基準フレームとして使用することを含む。このステップは、周期的（Ｆフレームごと）及び任意（或る他の判定基準に基づいて）の少なくとも１つに制限される。
【００４９】
本発明のこの態様は、特に、ビデオ会議によく適合する。具体的には、ビデオ会議の各当事者は、ビデオデータのフレームを圧縮し、パケットの喪失又は破損が検出可能なようにマーキングされたパケットで、圧縮されたビデオデータを他の当事者へ送信する。パケットが喪失又は破損したことをいずれかの当事者が検出した場合に、検出した当事者は、送信した当事者に信号で伝え、それによって、残りの当事者のすべてがすでに受信に成功して復号している基準フレームを使用して符号化された更新フレームが送信される。
【００５０】
本発明は、好ましくは、以下のように基準フレームを使用することができる。ビデオフレームの一定の間隔Ｆを符号化器が選択して、復号器へ送信することができる。Ｆ番目のフレームごとにフレームが、前の符号化されたＦ番目のフレームのみを基準に使用して符号化される。Ｆ番目でないあらゆるフレームは、その前のフレームを基準として使用して符号化される。ビデオの各フレームは、喪失及び破損が検出可能なように、復号器へ送信される。これらのステップのすべては、好ましくは、符号化器で行われる。復号器側では、符号化されたビデオデータが符号化器から受信され、復号器によって復号される。パケットが喪失し、喪失したパケットがＦ番目でないフレームに関連したものである場合、復号器は、次のＦ番目のフレームが喪失したパケットを回復するのを待つ。
【００５１】
別の代替形態として、本発明は、現在のフレームを、この符号化されたフレーム及び前の符号化されたフレームから取得された統計値のメトリックによって求められた周囲の品質よりも高い品質で、周期的及び任意の少なくとも１つで符号化し、符号化された現在のフレームを、２次的な基準フレームとしてのその後のフレームによる使用のために記憶する。
【発明を実施するための最良の形態】
【００５２】
本発明のいくつかの異なる態様を以下に説明することにする。
【００５３】
＜動的な係数の再配列（Dynamic Coefficient Reordering）＞
ＤＣＴ（離散コサイン変換）に基づくビデオ圧縮システムでは、８×８のピクセルブロック又は予測エラー信号データが、１組の６４個の周波数係数（１つのＤＣ値及び６３個のＡＣ値）に変換される。これら６４個の周波数係数は、その後、量子化されて１組のトークンに変換される。
【００５４】
通常、高周波のＡＣ係数ほど、大きさが小さくなり、したがって、次の量子化で非ゼロになる可能性は小さくなる。その結果、トークン化の前に、それら係数は、多くの場合、最も低い周波数係数（ＤＣ値）から開始して最も高周波のＡＣ係数で終了する昇順に配列される。この走査順序は、時に、「ジグザグ順序」と呼ばれることがあり、その始点に非ゼロ値を集め、終点に向かうにつれてゼロ値を集める傾向があり、そうすることによって、より効率的な圧縮を容易にする。
【００５５】
しかしながら、この固定された走査順序は、最適になることがほとんどない。たとえば、インターレースされたビデオ素材を符号化する時、一定の高周波係数は、はるかに顕著である。このことは従来技術に反映され、この従来技術では、インターレースされたビデオを符号化する時に代替的な走査順序を指令するコーデックが使用される例（たとえば、ＭＰＥＧ−２）が存在する。
【００５６】
本発明の一態様は、特定のデータセットの特性をより最適に反映するように係数が符号化される走査順序を、コーデックが最適にカスタマイズできる方法である。
【００５７】
本発明によれば、コーデックは、１つ又は複数のビデオフレームにおいて、ＤＣＴ係数のそれぞれについてゼロ値対非ゼロ値の分布の記録を保持する。この記録は、非ゼロになる可能性が高い係数がリストに先に現れるカスタムな走査順序を作成するのに使用される。
【００５８】
コーデックは、各係数について非ゼロ値の平均的な大きさ等の付加情報をオプションとして照合することができ、これを使用して走査順序をさらに最適化することができる。
【００５９】
新しいカスタム走査順序を送信するオーバーヘッド又は前に送信された走査順序を更新するオーバーヘッドは、場合によっては、改善された係数符号化効率から得られた利益を打ち消すおそれがある。したがって、更新がネットに利益を提供するかどうかを判断するのにコスト利益分析が必要となる場合がある。
【００６０】
この分析の結果に影響を与える主要な要因は、更新コスト、符号化されるブロック数（したがって、係数の個数）、及び新たな走査順序が標準的な走査順序又は前に符号化された走査順序のいずれかから逸脱する程度である。
【００６１】
８×８要素のＤＣＴの場合、「完全な」カスタム走査順序（すなわち、６４個の係数の１つ１つにつき新たな位置）を符号化するには、３８４ビット（それぞれ６４個の係数×６ビット）が必要となる。このコストは、符号化されるブロック数（したがって、係数の個数）が非常に大きくない限り、又は、最適な走査順序がデフォルト走査順序（これは、標準的な走査順序又は前に符号化された走査順序のいずれかである）と大幅に異ならない限り、法外なものとなる可能性がある。この記述の背後にある理論的根拠は、デフォルト走査順序がカスタム走査順序と類似している場合、各ブロックの符号化に確保される平均ビット数が小さくなる可能性があり、したがって、走査順序を更新するオーバーヘッドを正当化するには多数のブロックを符号化しなければならないということである。逆に、デフォルト走査順序がカスタム走査順序と異なる場合、ブロックあたりの平均節減は高くなる可能性がある。
【００６２】
この状況を改善する簡単な方法は、走査順序に対する変更のみを符号化することである。たとえば、各係数について、その係数が走査順序において自身の位置を変更したかどうかを示すビットを符号化し、次いで、適切な場合は、その新しい位置を示すビットを符号化する。これは、通常、更新コストが低くなるが、ここでの最悪の場合のシナリオは、新たな走査順序がすべての係数について異なる場合である。この場合、更新コストは４４８ビット（６４×７）となる。
【００６３】
このような手法の魅力的な態様は、カスタム走査順序とデフォルト走査順序とが最も類似している場合に更新コストが最小となり（したがって、ブロックごとの可能性のあるコスト削減は、その最小のものとなる）、それらの走査順序が最も異なる場合に最高となることである。
【００６４】
この状況は、個々の係数又は係数の対のレベルの「コスト利益」を考えることによってさらに改善することができる。たとえば、２つの係数が走査順序において互いに隣接しており、非ゼロ値の尤度がその双方でほとんど同一である場合を考える。それら２つの係数の一方又は他方の非ゼロ値の個数に小さな変化があると、それら２つの係数は、カスタム走査順序において場所を交換する可能性がある。この変化を符号化することは、（上記更新モデルを仮定した場合に）１４ビットのコストで双方の係数の走査位置を更新することを意味する。しかしながら、達成される節減はごく僅かとなる場合がある。
【００６５】
この問題は、特に、高い順序のＡＣ係数について該当する。この点で、非ゼロ値の周波数は、通常、非常に低く、きわめて小さな変化であっても、走査順序における係数の位置は大幅に変更される可能性がある。
【００６６】
カスタム走査順序の計算の基礎を、各係数についての単にゼロ対非ゼロの分布に置くことは確かに実現可能であるが、該当する他の要因がある。前述したように、これらの要因の１つは、非ゼロ値の平均的な大きさである。もう１つは、場合により、１つ又は複数の係数の値の間に正の相関が存在する場合があることである。たとえば、低い順序の「完全に水平な」ＡＣ係数と高い順序の「完全に水平な」係数との間である。このような場合、非ゼロ値の広がりに大幅な相違がない限り、非ゼロ値はその元の順序（最も低い周波数から最も高い周波数）に維持することが好ましい場合がある。
【００６７】
本発明のこの態様の好ましい実施態様は、このような問題に対処するのに幾分助けとなると同時に、走査順序の更新コストをさらに削減する。
【００６８】
カスタム走査順序を作成する手順は、概略的には以下の通りである。
・ＤＣ係数は常に最初（位置０）に符号化される。
・ＡＣ係数を、各係数の非ゼロである値の比率に基づいて降順に並べる。
・順序リストを１６個の可変サイズの帯域に分割する（表１参照）。
・各帯域内において、ジグザグ走査順序に再配列する。
【００６９】
表１に示すような１６個の帯域への再分化は、或る範囲の異なる試験クリップを用いた経験的な観測に基づいており、必ずしも最適ではないことに留意されたい。
【００７０】
【表１】
表１：好ましい走査順序の係数帯域
【００７１】
経験的な実験は、更新コストが考慮される前であっても、この帯域ストラテジーが、単に非ゼロである値の比率に基づく走査順序を使用して得られた結果と通例は同程度の良好な結果、又は、多くの場合それよりも良好な結果を与えることを示している。
【００７２】
第２の利点は、走査順序の更新コストが大きく削減されるということである。その理由は、値が或る帯域から別の帯域へ移動される場合にしか、その値を更新する必要がないからである。さらに、帯域内の変更の符号化には４ビットしか必要とされない。
【００７３】
好ましい実施態様で使用される最終的な最適化は、いくつかの係数が他の係数よりもはるかに頻繁に帯域を変更するという観察結果に基づいている。たとえば、高い順序のＡＣ係数は、低い順序の係数よりも帯域を変更する頻度は低いという傾向を有する。
【００７４】
特定の係数が、たとえば、時間の２％しか更新されない場合、その係数が所与のフレームにおいて更新されるかどうかを示すのに１ビットを使用することは無駄である。算術符号化技法を使用して、経験的に求められた更新確率を各係数に割り当てることにより、係数あたり実質的に１ビット未満の平均更新コストを得ることが可能である。
【００７５】
以下の「Ｃ」コードセグメントは、本発明のこの態様の好ましい実施態様をサポートする詳細を与えるものである。
// 収集されたゼロ／非ゼロ周波数データを使用して新たな「好ましい」走査順序を
// 実現する
void CalculateScanOrder( CP_INSTANCE *cpi)
{
UINT32 i, j, k;
UINT32 Sum;
UINT32 tmp[2];
UINT32 NzValue[BLOCK_SIZE][2];
UINT32 GroupStartPoint, GroupEndPoint;
// 各係数について、非ゼロであった値の比率を０〜２５５からの
// 拡大縮小された数字として計算する
for ( i=1; i<BLOCK_SIZE; i++ )
{
Sum = cpi->FrameNzCount[i][0] + cpi->FrameNzCount[i][1];
if ( Sum )
NzValue[i][0] = (cpi->FrameNzCount[i][1]*255)/Sum;
else
NzValue[i][0] = 0;
NzValue[i][1] = i;
}
// 降順にソートする
for ( i=1; i<BLOCK_SIZE-1; i++ )
{
for ( j=i+1; j>1; j--)
{
if ( NzValue[j][0] > NzValue[j-1][0] )
{
// それらを交換する
tmp[0] = NzValue[j-1][0];
tmp[1] = NzValue[j-1][1];
NzValue[j-1][0] = NzValue[j][0];
NzValue[j-1][1] = NzValue[j][1];
NzValue[j][0] = tmp[0];
NzValue[j][1] = tmp[1];
}
}
}
// 帯域に分割し、次いで、各帯域内において、ジグザグ走査位置に基づいて
// 昇順に再ソートする
GroupEndPoint = 0;
for ( k=0; k<SCAN_ORDER_BANDS; k++ )
{
GroupStartPoint = GroupEndPoint + 1;
GroupEndPoint = EndPointLookup[k];
for ( i=GroupStartPoint; i<GroupEndPoint; i++ )
{
for ( j=i+1; j>GroupStartPoint; j-- )
{
if ( NzValue[j][1] < NzValue[j-1][1] )
{
// それらを交換する
tmp[0] = NzValue[j-1][0];
tmp[1] = NzValue[j-1][1];
NzValue[j-1][0] = NzValue[j][0];
NzValue[j-1][1] = NzValue[j][1];
NzValue[j][0] = tmp[0];
NzValue[j][1] = tmp[1];
}
}
}
// 各係数インデックス（coef index）について、その帯域番号に印を付ける
for ( i=GroupStartPoint; i<=GroupEndPoint; i++ )
{
// 各係数の新たな走査帯域番号に留意する
// NzValue[i][1]は従来のジグザグ順序の係数の位置であり、
// iは新たな走査順序の位置であり、kは帯域番号である。
cpi->NewScanOrderBands[NzValue[i][1]] = k;
}
}
}
// この構造体は、（従来のジグザグ順序の）ｄｃｔ係数のそれぞれについての
// （１〜２５５の範囲に拡大縮小された）走査順序更新確率を与える。
// これらの値は、関数「nDecodeBool()」に渡され、結果が０（FALSE）である
// 確率を示す。
//
const UINT8 ScanBandUpdateProbs[BLOCK_SIZE] =
{
255, 132, 132, 159, 153, 151, 161, 170,
164, 162, 136, 110, 103, 114, 129, 118,
124, 125, 132, 136, 114, 110, 142, 135,
134, 123, 143, 126, 153, 183, 166, 161,
171, 180, 179, 164, 203, 218, 225, 217,
215, 206, 203, 217, 229, 241, 248, 243,
253, 255, 253, 255, 255, 255, 255, 255,
255, 255, 255, 255, 255, 255, 255, 255
};
// 走査順序に対する更新がこのフレームに利用可能である場合、この更新を読み出す。
void UpdateScanOrder( PB_INSTANCE *pbi )
{
// 走査順序が更新されているのはこのフレームか？
if ( nDecodeBool( 128 ))
{
// 更新された走査帯域で読み出す
for ( i = 1; i < BLOCK_SIZE; i++ )
{
// この係数の帯域は更新されたか？
if ( nDecodeBool( ScanBandUpdateProbs[i] ))
{
pbi->ScanBands[i] = VP6_bitread( SCAN_BAND_UPDATE_BITS );
}
}
// 新たな走査順序を走査帯域データから構築する
BuildScanOrder( pbi, pbi->ScanBands );
}
}
// １組の走査帯域データからカスタム走査順序を構築する
void BuildScanOrder( PB_INSTANCE *pbi, UINT8 *ScanBands )
{
UINT32 i, j;
UINT32 ScanOrderIndex = 1;
// ＤＣは一定である。
pbi->ModifiedScanOrder[0] = 0;
// 各帯域内において、（係数の元の「ジグザグ」操作順序位置の点で）
// 係数が昇順である走査順序を作成する
for ( i = 0; i < SCAN_ORDER_BANDS; i++ )
{
for ( j = 1; j < BLOCK_SIZE; j++ )
{
if ( ScanBands[j] == i )
{
pbi->ModifiedScanOrder[ScanOrderIndex] = j;
ScanOrderIndex++;
【００７６】
＜独立したビットストリームパーティションを使用した、符号化器及び復号器の最適化の容易化、及び、混在モードエントロピー符号化の使用＞
特定のハードウェアデバイス用にコーデックを最適化する場合、そのデバイスが複数のタスクを並列に実行するのに提供できるあらゆる設備が十分に利用されることを確かめること、及び、復号プロセスの個々の部分がボトルネックとなる範囲を制限することが重要である。
【００７７】
本発明のビットストリームは、ほとんどの他のビデオコーデックと共通して、概して言えば、エントロピー符号化されたトークンを含むものとして説明することができる。このエントロピー符号化されたトークンは、２つの主要なカテゴリーに分割することができる。
プリディクタトークン（以下、Ｐトークンと呼ぶ）。たとえば、画像のブロック又は領域を符号化するのに使用される方法又はモードを記述するトークンであり、或るフレームと別のフレームとの間の動きを記述するトークンである。
予測エラー信号トークン（以下、Ｅトークンと呼ぶ）。これらは、不完全な予測の結果生じたあらゆる残差を符号化するのに使用される。
【００７８】
エントロピー符号化は、ビットストリームにおける特定のＰトークン又はＥトークンの表現が、ビットストリームにおけるそのトークンの周波数、又は、そのトークンが特定の位置に現れる尤度に従って最適化されるプロセスである。たとえば、非常に頻繁に現れるトークンは、まれにしか現れないトークンよりも少ないビット数を使用して表される。
【００７９】
最も一般的なエントロピー符号化技法の２つは、ハフマン符号化及び算術符号化である。ハフマン符号化では、各トークンは、可変長のビットパターン（又は符号）によって表される。算術符号化は、計算がより複雑な技法ではあるが、各トークンについて多数のビット全体を使用する制約が除去されている。算術符号化器を使用すると、たとえば、１ビットの１／２の平均コストで非常に一般的なトークンを符号化することが完全に可能である。
【００８０】
多くのマルチメディアデバイスは、エントロピー符号化のタスクによく適合したコプロセッサユニット、及び、より多目的のメインプロセッサを有する。その結果、並列化のために、ビットストリームの符号化又は復号のプロセスは、多くの場合、エントロピーに関連したタスクと、エントロピーに関連しないタスクとに分割される。
【００８１】
しかしながら、所与のビデオクリップの場合、データレートが増加するにつれて、符号化／復号するトークン数が急激に上昇し、エントロピー符号化がボトルネックになる場合がある。
【００８２】
従来のビットストリームでは、エントロピー符号化の計算負荷を再分散させて、このボトルネックを取り除くことは非常に困難である。特に、復号側では、通常は、トークンが符号化された順序で１度に１つずつトークンを復号しなければならない。また、フレームレベル以外の方法又はエントロピー符号化（たとえば、ハフマン符号化及び算術符号化）を混在させることもきわめて困難である。
【００８３】
本発明のこの態様は、エントロピー符号化の計算負荷を再分散することを容易にし、且つ、ビットストリームに対する構造的な変更を通じて混在モードのエントロピー符号化の使用を容易にするように設計された方法である。
【００８４】
本方法によれば、ビットストリームの各フレームは、完全に独立した２つ又は３つ以上のデータパーティションに分割される。これらのパーティションは、並列に書き込むこともできるし、並列に読み出すこともでき、同じエントロピー符号化メカニズムを使用するように制約されない。これによって、高いビットレートでエントロピーに関連したボトルネックを回避するように符号化プロセス又は復号プロセスを最適化することが容易になる。
【００８５】
単一のフレーム内でハフマン技法及び算術技法の双方又はそれら２つを混在させたものが使用できることによって、符号化器には、達成される圧縮量と計算複雑度との間のトレードオフをより良く最適化する機能が与えられる。たとえば、フレームの計画されたサイズが所与のしきい値を超えている場合、符号化器は、そのパーティションの１つ又は複数において、複雑さが少なくなったハフマン方法を使用するように構成することができる。
【００８６】
本発明のこの態様の特定の実施態様は、１つ又は２つのいずれかのメインデータパーティションの使用をサポートする。これに加えて、小さなヘッダパーティションがある。
【００８７】
単一のデータパーティションを使用する場合、コーデックは従来通りに振る舞う。Ｐトークン及びＥトークンの双方が、単一のデータパーティションで独自の算術符号化器を使用して符号化される。本方法は、オーバーヘッドがわずかに低い（フレームあたり数ビット）が、柔軟性が少ない。
【００８８】
たとえば、
パーティション１
（ブロック１） Ｐ，Ｐ，Ｅ，Ｅ，Ｅ
（ブロック２） Ｐ，Ｅ，Ｅ
（ブロック３） Ｐ，Ｅ，Ｅ，Ｅ，Ｅ
【００８９】
一方、第２のケースでは、Ｐトークン及びＥトークンは、別々のパーティションに書き込まれる。
【００９０】
たとえば、
パーティション１ パーティション２
（ブロック１） ＰＰ ＥＥＥ
（ブロック２） Ｐ ＥＥ
（ブロック３） Ｐ ＥＥＥＥ
第１のパーティションのサイズは、データレートによって等しく変化する傾向はなく、比較的小さい。したがって、このパーティションは、常に、算術符号化器を使用して符号化される。第２のパーティションは、算術符号化器を使用して符号化することもできるし、ハフマン符号化器を使用して符号化することもできる。
【００９１】
第２のパーティションに対するハブマン符号化又は算術符号化の選択は、フレームレベルの信号で伝えることができる。好ましい実施態様では、この選択は、ターゲット復号器のプラットフォームの性能及びフレームの計画されたビットサイズに依存する。具体的には、フレームサイズがしきい値数を超える場合において、復号器が実時間でフレームを復号する問題を有するという危険性があるときは、ハフマン方法が使用される。
【００９２】
符号化器の性能も、実時間符号化が要件である場合に問題となる可能性がある。しかし、キーフレーム（より大きくなる傾向があり、他のフレームに依存しない）は例外になり得るとして、エントロピー符号化のコストは、通例、符号化器の全体の計算コストのより小さな一部分となる。
【００９３】
以下の「Ｃ」コードセグメントは、本発明のこの態様の好ましい実施態様をサポートする詳細を与えるものである。
// この関数は、算術符号化された１つのデータパーティション、算術符号化された
// ２つのデータパーティション、又は、算術符号化された１つのデータパーティ
// ション及び１つのハフマンデータパーティションのいずれかを使用して、
// フレーム用の符号化されたビデオデータを梱包する。
//
// 引数「cpi」は、主符号化器インスタンスデータ構造体へのポインタである。
void PackCodedVideo( CP_INSTANCE *cpi )
{
UINT32 PartitionTwoOffset;
BOOL_CODER *bc = &cpi->bc; // 算術符号化器インスタンスデータ構造体
BOOL_CODER *bc2 = &cpi->bc2; // 第２の算術符号化器インスタンス構造体
PB_INSTANCE *pbi = &cpi->pb; // 復号器インスタンスデータ構造体
// ヘッダパーティションに使用される生のバッファｉ／ｏを初期化する
InitAddRawBitsToBuffer( &cpi->RawBuffer, pbi->DataOutputPtr );
// 算術符号化器及び／又はハフマン符号化器を起動する
// ２つのデータパーティションを使用している場合…
if ( pbi->MultiStream || (pbi->VpProfile == SIMPLE_PROFILE))
{
// 第１の算術符号化器を起動する。生のヘッダバイトを考慮する。
VP6_StartEncode( bc, (pbi->DataOutputPtr + ((KeyFrame)? 4:3)));
// 第２の算術パーティション又はハフマンパーティションのいずれかを作成する
// これは、保持バッファ「cpi->OutputBuffer2」に最初に書き込まれる
if ( pbi->UseHuffman )
InitAddRawBitsToBuffer ( &pbi->HuffBuffer, cpi->OutputBuffer2 );
else
VP6_StartEncode( bc2, cpi->OutputBuffer2 );
}
// 算術符号化器を使用して符号化された単一のデータパーティションのみを使用している
else
{
// 算術符号化器を起動する。生のヘッダバイトを考慮する。
VP6_StartEncode( bc, (pbi->DataOutputInPtr + ((KeyFrame)? 2:1))); }
…
…
// サイズを含むフレームヘッダ情報を書き出す。
WriteFrameHeader( … );
…
…
if ( pbi->UseHuffman )
PackHuffmanCoeffs( … );
else
PackArithmeticCoeffs( … );
// 第１のデータパーティションに使用された算術符号化器インスタンスを停止する
VP6_StopEncode( bc );
// データパーティションへのオフセットを算出し、それらオフセットを、
//生のヘッダパーティションにおけるこの情報用に予約された空間に書き込む
//
// ２つのデータパーティションを使用している場合…
if ( pbi->MultiStream || (pbi->VpProfile == SIMPLE_PROFILE))
{
// バッファの始点から第１のデータパーティションへのオフセット
PartitionTwoOffset = 4 + bc->pos;
// オフセットを第２のデータパーティションパーティションに書き込む。
AddRawBitsToBuffer( &cpi->RawBuffer, PartitionTwoOffset, 16 );
// 第２のデータパーティションにハフマンが使用された場合…
if ( pbi->UseHuffman )
{
// ハフマン符号化された出力パーティション用のバッファをフラッシュする
EndAddRawBitsToBuffer( &pbi->HuffBuffer );
…
// ハフマン符号化されたデータを保持バッファから出力バッファへ
// コピーする
memcpy( &cpi->RawBuffer.Buffer[ PartitionTwoOffset ],
pbi->HuffBuffer.Buffer, pbi->HuffBuffer.pos );
}
else
{
// 第２のデータパーティションによって使用された
// 算術符号化器インスタンスを停止する。
VP6_StopEncode( bc2 );
…
// 第２のパーティションによって使用された保持バッファの内容を
// 出力バッファへコピーする
memcpy( &pbi->DataOutputInPtr[ PartitionTwoOffset ],
bc2.buffer, bc2.pos);
}
}
// ヘッダに使用された生のビット符号化器を停止してフラッシュする
EndAddRawBitsToBuffer( &cpi->RawBuffer );
}
// この関数は、２つのデータパーティションを使用する場合に符号化ストラテジーを選択するためにコールされる。
void SelectMultiStreamMethod( CP_INSTANCE *cpi)
{
// フレームにおけるトークンの分布から収集された情報を使用して
// フレームの見積もりコスト（シャノンエントロピー）を計算する。
// あらゆるモード情報及び動きベクトル情報を符号化するための、
// 前に計算されたコスト見積もりを算入する
EstimatedFrameCost = VP6_ShannonCost( cpi ) + ModeMvCost;
// 第２のデータパーティションにハフマン符号化を使用して下がるかどうかを判断する
if ( EstimatedFrameCost > HuffmanCodingThereshold )
pbi->UseHuffman = TRUE;
else
pbi->UseHuffman = FALSE;
【００９４】
＜複数のフィルタを使用した、ビデオコーデックの端数ピクセル動き予測の高度化＞
現代のほとんどのビデオコーデックにとって、動き予測は、圧縮プロセスの重要な部分である。動き予測は、画像の物体又は領域の動きが、１つ又は複数のフレームにわたってモデル化され、１つ又は複数の「動きベクトル」が、この動きを表すためのビットストリームで送信されるプロセスである。ほとんどの場合、画像内の動きを完全にモデル化することはできず、そこで、動き情報に加えて残差信号を符号化することが必要である。
【００９５】
基本的に、各動きベクトルは、符号化される現在のフレームの領域と類似した、前に符号化されたフレームの領域を指し示す。残差信号は、各ピクセルの予測値を、現在のフレームの実際の値から差し引くことによって得られる。
【００９６】
現代の多くのビデオコーデックは、サブピクセル精度に対して動き予測をサポートすることによりこのプロセスを拡張している。たとえば、１／２ピクセル又は１／４ピクセルの動き推定である。端数ピクセルデータ点を作成するには、実際の（すなわち、フルピクセルアラインされた）データ点に適用される或る形態の補間関数又は補間フィルタを使用することが必要である。
【００９７】
初期のコーデックは、一般に、簡単な双１次補間を使用していた。
Ａ ｘ Ｂ
ｙ ｚ
Ｃ Ｄ
【００９８】
この例では、Ａ、Ｂ、Ｃ、及びＤが、フルピクセルアラインされたデータ点であり、ｘ、ｙ、及びｚが、１／２ピクセルアラインされた点である。点ｘは、Ｘ方向に１／２ピクセルアラインされ、公式：ｘ＝（Ａ＋Ｂ／２）を使用して計算することができる。点ｙは、Ｙ方向に１／２ピクセルアラインされ、公式：ｙ＝（Ａ＋Ｃ／２）を使用して計算することができる。点ｚは、Ｘ及びＹの双方で１／２ピクセルアラインされ、公式：ｚ＝（Ａ＋Ｂ＋Ｃ＋Ｄ／２）を使用して計算することができる。
【００９９】
後のコーデックは、画像がぼける傾向を少なくする、双３次フィルタ等のより複雑な補間フィルタの使用に向かう傾向がある。以下の例では、ｘは、２つのフルピクセルアラインされた点ＢとＣとの間の中点にある１／２ピクセル点である。双３次フィルタに対して整数近似を使用すると、ｘは、公式：ｘ＝（−Ａ＋９Ｂ＋９Ｃ−Ｄ）／１６を使用して計算することができる。
Ａ Ｂ ｘ Ｃ Ｄ
【０１００】
上記に示した双３次フィルタ等のフィルタは、よりシャープに見える結果を生成する傾向があるが、いくつかのフレームにわたってそれらフィルタが繰り返し適用されると、場合によっては、誤ったテキスチャや誤った輪郭等の不快な人工物となる可能性がある。
【０１０１】
本発明のこの態様は、コーデックが、フィルタリング技法を混在させたものを使用して、より最適な端数ピクセルプリディクタを作成でき、クリップレベル、フレームレベル、ブロックレベル、又は個々のピクセルレベルでもこれらの方法から選択を行える方法である。
【０１０２】
好ましい実施態様では、ブロックレベルで、双１次フィルタリングのみを使用するのか、双３次フィルタリングのみを使用するのか、それとも選択を可能にするのかの選択をフレーム単位で行うことができる。
【０１０３】
ブロックレベル又は領域レベルでの選択は、ビットストリーム内の明示的なシグナリングビットによって行うことができるが、好ましい実施態様では、ビットストリームにおいてすでに利用可能な文脈情報を使用し、且つ、フィルタリングされることになる、フルピクセルアラインされたデータ値に適用された複雑度メトリックによって、この選択は行われる。
【０１０４】
動きプリディクタの品質が不十分な状況（たとえば、前のフレームの再構築においてブロックの良好な予測を見つけることができなかった場合）では、双１次フィルタリングは、多くの場合、最善の選択肢となる。具体的には、予測が不十分である場合、双３次フィルタのシャープ化特性は、残差信号の高周波の内容の増加につながる場合があり、符号化をより困難にする場合がある。
【０１０５】
明示的なシグナリングビットがビットストリームにない場合、不十分な予測品質との相関の程度をより大きくしたりより小さくしたりする文脈的に利用可能なさまざまな値を示すことができる。これら値の最も単純なものの１つは、動きベクトル長（motion vector length）である。具体的には、予測の品質は、動きベクトル長の増加と共に劣化する傾向がある。別の可能な指標は、動きフィールドの滑らかさ（すなわち、近傍のブロックの動きベクトルがどれだけ類似しているか）である。
【０１０６】
また、双１次フィルタリングは、ベクトルの選択に信頼性がない（たとえば、画像があまり詳細でなく、類似したエラースコアを有する多くの候補ベクトルがある）状況においてより良い選択肢となる傾向がある。特に、比較的平坦で特徴のない領域に対して多くのフレームにわたり双３次フィルタを繰り返し適用すると、不要な人工物が生み出される場合がある。
【０１０７】
好ましい実施態様では、フィルタリング方法を選ぶ際に２つの因子が考慮される。第１の因子は、動きベクトルの長さである。第２の因子は、フィルタリングされることになる１組のフルピクセルアラインされたデータ点を解析することによって計算される複雑度メトリックＣである。
【０１０８】
双３次フィルタリングは、以下のテスト条件が共に満たされる場合にのみ使用される。
１．動きベクトルが、Ｘ及びＹの双方でしきい値Ｌよりも短い。
２．複雑度Ｃが、しきい値Ｔよりも大きい。
【０１０９】
好ましい実施態様では、Ｃは、公式：
Ｃ＝（ｎΣｘｉ２−（Σｘｉ）２）／ｎ２
に従って計算された１組のｎ個のデータ点ｘｉの分散である。
【０１１０】
好ましい実施態様では、複雑度しきい値Ｔ及び動きベクトル長しきい値Ｌは、フレームごとに１回の割合で、符号化器が設定することができる。
【０１１１】
以下の「Ｃ」コードセグメントは、本発明のこの態様の好ましい実施態様をサポートする詳細を与えるものである。
PredictBlockFunction( … )
{
…
…
if ( pbi->PredictionFilterMode == AUTO_SELECT_PM )
{
// ベクトルがＸ又はＹにおいてしきい値長よりも大きい場合に双１次を使用する
if ( (( abs(pbi->mbi.Mv[bp].x ) > BicMvSizeLimit ||
(( abs(pbi->mbi.Mv[bp].y ) > BicMvSizeLimit))
{
FilterBlockBilinear( … );
}
else
{
// 複雑度メトリック（分散）を計算する。
// 注意：性能の理由から、分散関数は１６個のデータ点
// （８×８ブロックのＸ及びＹの１つおきの点）のみを検査する
Var = Var16Point( DataPtr, Stride );
// 複雑度が所与のしきい値よりも大きい場合には、双３次を使用し、
// そうでない場合には、双１次を使用する
if ( Var >= pbi->PredictionFilterVarThresh )
FilterBlockBilcubic( … )
else
FilterBlockBilinear( … )
}
}
…
…
}
UINT32 Var16Point ( UINT8 *DataPtr, INT32 Stride )
{
UINT32 i, j;
UINT32 XSum=0, XXSum=0;
UINT8 *DiffPtr = DataPtr;
// Ｘ及びＹの１つおきの点を使用する
for ( i = 0; i < BLOCK_HEIGHT_WIDTH; i += 2 )
{
for ( j = 0; j < BLOCK_HEIGHT_WIDTH; j += 2 )
{
XSum += DiffPtr[j];
XXSum += DiffPtr[j] * DiffPtr[j];
}
// ブロックの次の行へステップする
DiffPtr += (SourceStride << 1)
}
// 適合しないメトリックとして母分散を計算する
return(((XXSum*16)-(XSum*XSum))/256);
【０１１２】
＜高度化された動きベクトル符号化＞
慣例により、現代のほとんどのビデオコーデックは、差分符号化方式を使用して、動きベクトルの（ｘ，ｙ）成分を符号化する。すなわち、各ベクトルは、前のベクトルを基準にして符号化される。たとえば、２つのベクトル（７，３）及び（８，４）を考える。この場合、第２のベクトルは（１，１）、すなわち（７＋１，３＋１）として符号化されることになる。
【０１１３】
この方式は、動きベクトルが符号化されるほとんどのブロック又は領域が、その近傍の動きと類似した動きを示す場合によく機能する。これは、多くの場合、たとえばパンする時に当てはまることを示すことができる。しかしながら、動きフィールドが不規則である場合、又は、異なる動き特性を有する背景領域と前景領域との間での遷移が頻繁である場合に、この方式はあまりよく機能しない。
【０１１４】
本発明のこの態様は、差分符号化の利点を保持すると同時に不規則なフィールド及び背景前景遷移の許容範囲がより大きな、動きベクトルを符号化するための代替的なストラテジーである。
【０１１５】
本発明によれば、コーデックは、動きベクトルを符号化できる基準になる２つ又は３つ以上の基準ベクトルを保持する。コーデックは、ビットストリーム内の明示的なシグナリングビットを介してこれらの基準ベクトルを切り換えることができるが、好ましい実施態様では、この決定は、符号化方法、及び、ブロックのすぐ隣のブロックによって使用される動きベクトルに基づく。
【０１１６】
好ましい実施態様では、ブロックは、イントラブロック（intra block）（前のどのフレームにも依存しない）として符号化することもできるし、前のフレームの再構成又は周期的にしか更新されない代替的な基準フレームのいずれかに依存するインターブロック（inter block）として符号化することもできる。
【０１１７】
前のフレームの再構成又は代替的な基準フレームを基準にして符号化する場合、本発明は、以下の符号化モードの選択肢をサポートする。
・動きベクトルなし（すなわち、暗黙的な（０，０）ベクトル）で符号化する。
・「最も近い」近傍と同じベクトルを使用して符号化する。
・「次に最も近い」近傍と同じベクトルを使用して符号化する。
・新たな動きベクトルを使用して符号化する。
【０１１８】
最も近い近傍又は次に最も近い近傍を定義する際、現在のブロックと同じ基準フレームを基準にして符号化されたブロック及び非ゼロの動きベクトルで符号化されたブロックのみが考慮される。他のすべてのブロックは無視される。
【０１１９】
次に最も近い近傍を定義する際、最も近い近傍と同じベクトルで符号化されたブロックも無視される。
【０１２０】
新たな動きベクトルを符号化する際、コーデックは、（０，０）ベクトル又は最も近いベクトルを基準ベクトルとして使用することができる。好ましい実施態様では、最も近いベクトルが得られたブロックが、現在のブロックのすぐ左のブロック又はすぐ上のブロックのいずれかである場合に、その最も近いベクトルが使用される（ブロックは、左から右へ及び上から下へ符号化されるものと仮定する）。他のすべての場合には、新たなベクトルは（０，０）を基準にして符号化される。
【０１２１】
基本的な方法のいくつかの拡張が可能である。最も近い近傍及び次に最も近い近傍が、それぞれ現在のブロックのすぐ左のブロック及びすぐ上のブロックである場合、それら２つから得られた或る種の合成ベクトルを、新たなベクトルを符号化するための基準として使用することができる。あるいは、「最も近い」はｘ成分を予測するのに使用することができ、「次に最も近い」はｙ成分を予測するのに使用することができる。
【０１２２】
別の可能な拡張は、ここでも、最も近い又は次に最も近いが、現在のブロックのすぐ左のブロック及びすぐ上のブロックであると仮定して、最も近いベクトルと次に最も近いベクトルとが類似していない場合を特別に考慮したものである。このような場合、最も近いベクトル及び次に最も近いベクトルは、ｘ、ｙ、又はｘ及びｙの双方の基準値として０に戻る。
【０１２３】
本方法は、規則的な動きフィールド又はゆっくりと変化する動きフィールドがある場合に、単純な差分符号化の利益を保持する。しかしながら、特別な「ベクトルのない」モード、「最も近い」モード、及び「次に最も近いモード」を使用することは、前景と背景との間の遷移をより効率的に符号化するのに役立ち、複数の符号化の起点を自動的に切り換えることができることによって、本方法の不規則な動きフィールドの許容範囲は、より大きくなる。
【０１２４】
以下の「Ｃ」コードセグメントは、本発明のこの態様の好ましい実施態様をサポートする詳細を与えるものである。
// この関数は、現在のブロックについて、限定的な（qualifying）最も近い近傍
// 及び次に最も近い近傍があるかどうか、それらの動きベクトルは何であるか、
// 並びに最も近い近傍がどれだけ接近しているかを判断する。
//
void VP6_FindNearestandNextNearest( PB_INSTANCE *pbi,
UINT32 MBrow,
UINT32 MBcol,
UINT8 ReferenceFrame,
INT32 *Type )
{
int i;
UINT32 OffsetMB;
UINT32 BaseMB = MBOffset( MBrow, MBcol );
MOTION_VECTOR ThisMv;
// デフォルト結果を設定する
*Type = NONEAREST_MACROBLOCK;
// 限定的な「最も近い」ブロックを探索する
for ( i=0; i<12; i++ )
{
OffsetMB = pbi->mvNearOffset[i] + BaseMB;
// ブロックは同じ基準フレームを基準にして符号化されたか？
if ( VP6_Mode2Frame[pbi->predictionMode[OffsetMB]] != ReferenceFrame )
continue;
// 動きベクトルがもしあれば、その動きベクトルは何を使用したか
ThisMv.x = pbi->MBMotionVector[OffsetMB].x;
ThisMv.y = pbi->MBMotionVector[OffsetMB].y;
// それが非ゼロであった場合、限定的な近傍を有する
if ( ThisMv.x || ThisMv.y )
{
Nearest.x = ThisMv.x;
Nearest.y = ThisMv.y;
*Type = NONEAR_MACROBLOCK;
break;
}
}
pbi->mbi.NearestMvIndex = i;
// 限定的な「次に最も近い」ブロックを探索する
for ( i=i+1; i<12; i++ )
{
OffsetMB = pbi->mvNearOffset[i] + BaseMB;
// ブロックは同じ基準フレームを基準にして符号化されたか？
if ( VP6_Mode2Frame[pbi->predictionMode[OffsetMB]] != ReferenceFrame )
continue;
// 動きベクトルがもしあれば、その動きベクトルは何を使用したか
ThisMv.x = pbi->MBMotionVector[OffsetMB].x;
ThisMv.y = pbi->MBMotionVector[OffsetMB].y;
// このベクトルが「最も近い」ベクトルと同じである場合、このベクトルを無視する
if ((ThisMv.x == Nearest.x) && (ThisMv.y == Nearest.y))
continue;
// それが非ゼロであった場合、限定的な近傍を有する
if ( ThisMv.x || ThisMv.y )
{
NextNearest.x = ThisMv.x;
NextNearest.y = ThisMv.y;
*Type = MACROBLOCK;
break;
【０１２５】
＜エラー回復における代替的な基準フレームの使用＞
ビデオコーデックは、多くの場合、ビットストリームのエラーの影響を極端に受けやすいので、信頼性のないデータリンク上で圧縮ビデオデータを送信する場合、データが喪失又は破損したときの回復のためのメカニズムが存在することは重要である。
【０１２６】
このようなリンクの信頼性のあるデータ送信のためのさまざまな技法及びプロトコルが存在し、これらは、通常、エラーの検出、及び、再送又は一定のタイプのエラーの訂正を可能にする追加データビットの使用のいずれかに依拠する。
【０１２７】
多くの状況では、これら既存の技法は十分である。しかし、制限された帯域幅のリンク上でビデオ会議を行う場合、上述した手法のいずれも理想的ではない。喪失したデータパケットの再送は、端末間の遅延の増加を引き起こす可能性があるので実用的でない場合がある一方、誤り訂正ビット又は誤り訂正パケットの使用は、帯域幅がすでに厳しく制限されている状況では受け入れられない場合がある。
【０１２８】
代替的な手法は、単に、復号器においてエラーを検出し、そのエラーを符号化器に報告することである。符号化器は、その後、回復フレームを復号器へ送信することができる。この手法は、リンク上のエラーレートが非常に高い場合、適切でないおそれがあることに留意されたい。たとえば、１０フレーム〜２０フレームごとに２つ以上のエラーがある場合である。
【０１２９】
最も簡単な形態の回復フレームは、キーフレーム（又はイントラオンリーフレーム）である。これは、前のフレーム又は前のフレームのデータに何ら依存関係を有しないフレームである。キーフレームに関連した問題は、それらキーフレームが、通例、比較的大きいということである。
【０１３０】
発明５の対象は、コーデックが、回復フレームのより効率的な符号化のための開始点として使用できる１つ又は複数の追加された基準フレーム（前に符号化されたフレームの再構成以外）を保持するメカニズムである。
【０１３１】
本発明の好ましい実施態様では、コーデックは、キーフレームが存在する時は常に、且つ、オプションとしてそれ以外の時に、フレームヘッダのフラグビットを介して更新される第２の基準フレームを保持する。たとえば、符号化器は、「Ｘ」秒ごとに１回又はエラー回復フレームが符号化される時は常に第２の基準フレームを更新することを選択することができる。
【０１３２】
第２の基準フレームの内容が、少なくともいくつかの点で現在のフレームの内容と類似しているという条件で、この第２の基準フレームを基準にした差分符号化は、キーフレームを符号化するよりもはるかに安価になる可能性がある。
【０１３３】
１つ又は複数の代替的な基準フレームを使用して、圧縮品質又は圧縮効率を高めることができるいくつかの方法がある。従来技術に含まれる１つの明らかな使用は、２つ又は３つ以上の異なるシーン間を行ったり来たりするビデオシーケンスにおいてである。たとえば、ビデオがインタビューする側とインタビューされる側との間で行ったり来たりするインタビューを考える。各カメラアングル用のベースラインとして別々の基準フレームを記憶することにより、これらの間を行ったり来たりするコストを大きく削減することができ、特に、シーンが大幅に異なる場合に大きく削減することができる。
【０１３４】
本発明は、代替的な基準フレームをこのように使用する選択肢を有するが、本発明の対象は、ビデオにゆっくりとした漸進的変化がある状況において、周期的に更新された代替的な基準フレームを使用して、圧縮されたビデオの品質を高めることである。この良い例はゆっくりとしたパン、ズーム、又はトラッキングショットである。
【０１３５】
本発明のこの態様によれば、ゆっくりとしたパン又は他のこのようなゆっくりとした漸進的変化の間、符号化器は、周囲のフレームよりもきわめて高い品質で符号化され、且つ、第２の又は代替的な基準フレームの更新を引き起こすフレームを周期的に挿入する。
【０１３６】
これらの高い品質の「第２の基準の更新」フレームの目的は、最後のキーフレーム以来又は最後の第２の基準の更新以来、次第に喪失してきた細部を元に戻すこと、及び、後続のフレームのインターフレーム予測のより良い基礎を提供することである。品質（したがってデータレート）を周期的に引き上げると同時に第２の基準フレームを更新するこのストラテジーは、いくつかの状況では、単にすべてのフレームを同様の品質で符号化することよりもはるかに良好なコスト／品質トレードオフを提供することを示すことができる。
【０１３７】
第２の基準の更新の適切な間隔、及び、品質又はデータレートを増加させるべき量を決定するための方法は、有効な実施態様の中心となる。
【０１３８】
本発明のこの態様の好ましい実施態様では、いくつかの因子が考慮される。これらの因子には、以下のものが含まれる。
・動きの速度の指標として、数個の先行フレームにおける動きベクトルの平均振幅。
・動きフィールドが相関する程度。たとえば、動きベクトルがすべてかなり類似している。
・前の数フレームにおける前のフレームの再構成に優先して、第２の基準フレームがプリディクタとして使用された程度。
・周囲の品質又は量子化器の設定。
【０１３９】
使用された動きベクトルの平均振幅が高い場合（高速の動きを示す）、第２の基準の更新間隔及び品質ブースト（quality boost）はともに減少する。逆に、動きがゆっくりとしている場合、より大きな品質ブースト及びより長い間隔が使用される。
【０１４０】
動きフィールドが高い相関を有する場合、すなわち、類似した動きベクトルが多数ある場合、第２の基準フレームの更新のための品質ブーストは増加する。逆に、動きフィールドの相関が乏しい場合、ブーストの程度は減少する。
【０１４１】
第２の基準フレームが、前のフレームの再構成に優先して、プリディクタとして頻繁に使用されている場合、品質ブーストは増加する。逆に、第２の基準フレームが頻繁に使用されない場合、品質ブーストは減少する。
【０１４２】
また、品質ブーストの程度は、周囲の品質にも或る程度依存し、周囲の品質が低い場合には大きなブーストが使用され、周囲の品質が高い場合には小さなブーストが使用される。
【０１４３】
以下の擬似コードは、本発明のこの態様の好ましい実施態様の詳細をより与えるものである。
【０１４４】
各フレームについて
１／４ピクセル単位で指定されたＸ及びＹの動きベクトル成分の平均振幅（ＡｖＸ及びＡｖＹ）を計算する。
ＭｏｔｉｏｎＳｐｅｅｄ（動きの速度）＝ＡｖＸ及びＡｖＹの大きい方
Ｘ及びＹの動きベクトル成分の分散数（ＶａｒｉａｎｃｅＸ（分散Ｘ）及びＶａｒｉａｎｃｅＹ（分散Ｙ））を計算する
ＭａｘＶａｒｉａｎｃｅ（最大分散）＝ＶａｒｉａｎｃｅＸ及びＶａｒｉａｎｃｅＹの大きい方
ＭｏｔｉｏｎＣｏｍｐｌｅｘｉｔｙ（動きの複雑度）＝ＭｏｔｉｏｎＳｐｅｅｄ＋（ＶａｒｉａｎｃｅＸ／４）＋（ＶａｒｉａｎｃｅＹ／４）
第２の基準フレームの更新がまさにこのフレームである場合
そのフレームの予測された品質インデックス（実際には量子化器の設定）に基づいてデータレート％ブースト数（Ｂｏｏｓｔ）を計算する。これは、最高品質の＋０％と、品質レベルが非常に低い時の＋１２５０％との範囲とすることができる。
ＢｏｏｓｔにＭｏｔｉｏｎＳｐｅｅｄ訂正係数（correction factor）を乗算する。ここで、この係数は、ＭｏｔｉｏｎＳｐｅｅｄが非常に小さい値である場合の１と、ＭｏｔｉｏｎＳｐｅｅｄが大きな値である場合の０との間で変化することができる。
第２の基準フレームが前の数フレームで使用された程度に基づいて、さらに別の訂正係数をＢｏｏｓｔに適用する。この別の訂正係数は、第２の基準フレームが前の数フレームで全く使用されなかった場合の１／１６から、第２の基準フレームが符号化されたブロックの１５％以上に使用された場合の１まで変化することができる。
次に、一連のテストが適用されて、先に進むかどうか、及び、計算された％ブーストで第２の基準フレームを更新するかどうかが判断される。
【０１４５】
主なテストは次の通りである。
（Ｂｏｏｓｔ＞ＭｉｎＢｏｏｓｔＴｒｅｓｈｏｌｄ）且つ
（ＭｏｔｉｏｎＳｐｅｅｄ＜ＭａｘＭｏｔｉｏｎＳｐｅｅｄＴｈｒｅｓｈｏｌｄ）且つ
（ＭａｘＶａｒｉａｎｃｅ＜ＭａｘＶａｒｉａｎｃｅＴｈｒｅｓｈｏｌｄ）
ここで、ＭｉｎＢｏｏｓｔＴｒｅｓｈｏｌｄ、ＭａｘＭｏｔｉｏｎＳｐｅｅｄＴｈｒｅｓｈｏｌｄ、及びＭａｘＶａｒｉａｎｃｅＴｈｒｅｓｈｏｌｄは構成可能なパラメータである。
【０１４６】
本発明は、複数の特別な「動き再利用」モードを有する。これらの「動き再利用」モードは、或るブロックの動きベクトルが、その近くにある近傍のブロックの１つによって使用された動きベクトルと同じである場合に、当該或るブロックの動きベクトルをより安価に符号化することを可能にするものである。これらのモードの使用がしきい値レベル未満に下がる場合を減らすためのさらなるテストが適用される。
【０１４７】
ブーストを適用して第２の基準フレームを更新する決定がなされた場合、フレームデータレート目標値をベースライン値＋Ｂｏｏｓｔ％に設定し、計算し、ＭｏｔｉｏｎＳｐｅｅｄに基づく次の更新までの間隔。
【０１４８】
ブーストを適用せず、第２の基準フレームを更新しない決定がなされた場合、０％のデータレートブーストで通常通りフレームを更新する。
【０１４９】
それ以外の場合、第２の基準フレームの更新は行われるべきではない。
【０１５０】
第２の基準フレームが最後に更新された時に適用されたブーストのレベル及び現在の更新間隔を考慮した、削減されたフレームデータレート目標値（負のブースト）を計算する。
【０１５１】
＜再構成エラーメトリックを使用した、端数ピクセル予測を作成するための代替的な方法の選択＞
現代の多くのビデオコーデックは、サブピクセル精度に対する動きの予測をサポートする。たとえば、１／２ピクセル又は１／４ピクセルの動き推定である。端数ピクセルデータ点を作成するには、実際の（すなわち、フルピクセルアラインされた）データ点に適用される或る形態の補間関数又は補間フィルタを使用することが必要である。
【０１５２】
初期のコーデックは、一般に、簡単な双１次補間を使用していた。
Ａ ｘ Ｂ
ｙ ｚ
Ｃ Ｄ
【０１５３】
この例では、Ａ、Ｂ、Ｃ、及びＤが、フルピクセルアラインされたデータ点であり、ｘ、ｙ、及びｚが、１／２ピクセルアラインされた点である。
＊点ｘは、Ｘ方向に１／２ピクセルアラインされ、公式（Ａ＋Ｂ／２）を使用して計算される。
＊点ｙは、Ｙ方向に１／２ピクセルアラインされ、公式（Ａ＋Ｃ／２）を使用して計算される。
＊点ｚは、Ｘ及びＹの双方で１／２ピクセルアラインされ、公式（Ａ＋Ｂ＋Ｃ＋Ｄ／２）を使用して計算される。
【０１５４】
後のコーデックは、画像がぼける傾向を少なくする、双３次フィルタ等のより複雑な補間フィルタの使用に向かう傾向がある。以下の例では、「ｘ」は、２つのフルピクセルアラインされた点ＢとＣとの間の中点にある１／２ピクセル点である。ｘは、公式（−Ａ＋９Ｂ＋９Ｃ−Ｄ）／１６を使用して計算することができる。
Ａ Ｂ ｘ Ｃ Ｄ
【０１５５】
上記に示した双３次フィルタ等のフィルタは、よりシャープな結果を生成する傾向があるが、いくつかのフレームにわたってそれらフィルタが繰り返し適用されると、時に、テキスチャの誇張や誤った輪郭等の不快な人工物となる可能性がある。
【０１５６】
本発明のこの態様は、コーデックが、双１次フィルタリング及び双３次フィルタリングの混在したものを使用して、より最適な端数ピクセルプリディクタを計算することができ、フレームレベル、又は、動きベクトルが適用される個々のブロックもしくは領域のレベルのいずれかでこれらの方法を選択することができる方法である。
【０１５７】
ブロックレベル又は領域レベルでの選択は、ビットストリーム内のシグナリングビットによって行うことができるが、好ましい実施態様では、この選択は、フィルタリングされることになる前の再構成された画像の１組のピクセルに適用された複雑度メトリックによって行われる。
【０１５８】
本方法によれば、しきい値「Ｔ」よりも大きな複雑度スコアを有するブロック又は領域は、双３次方法を使用してフィルタリングされるのに対して、これより低い複雑度スコアを有するブロック又は領域は、双１次方法を使用してフィルタリングされる。
【０１５９】
好ましい実施態様では、複雑度メトリックは、フィルタリングされる１組の「ｎ」個のフルピクセルアラインされたデータ点の分散である。ここで、分散は次のように定義される。
（ｎ？ｘ２−（？ｘ）２）／ｎ２
【０１６０】
好ましい実施態様では、しきい値「Ｔ」は、フレームごとに１回更新することができる。
【特許請求の範囲】
【請求項１】
各ブロックがピクセルの配列を有する少なくとも１つのブロックを有する少なくとも１つのフレームを有するビデオデータを圧縮する方法であって、
Ｉ）各ブロックの前記ピクセルを係数に変換して、該係数の最適な送信順序を作成するステップと、
ＩＩ）前記データのビットストリームを区画して各パーティションを独立に符号化することにより、圧縮されたビデオデータを処理する速度を最適化するステップと、
ＩＩＩ）所与の各ブロックに関連した少なくとも１つのメトリックに応じて所与の各複数のピクセルの補間方法を選択することにより、端数ピクセル動きを予測するステップと、
ＩＶ）現在のフレームの直前のフレームよりも前のフレームを唯一の基準フレームとして使用して前記現在のフレームのエラー回復を高度化するステップであって、それによって、データ送信中の品質損失を小さくする、前記現在のフレームのエラー回復を高度化するステップと
の少なくとも１つを含む、ビデオデータを圧縮する方法。
【請求項２】
ステップＩは、
ａ）各ブロックの前記ピクセルを、各係数が係数位置及び値を有する係数に変換するステップと、
ｂ）各係数位置に関連した位置の値を求めるステップと、
ｃ）前記ステップｂ）で求められた各係数位置の前記位置の値に基づいて、係数の最適な送信順序を作成するステップと、
ｄ）前記ステップｃ）で求められた前記順序で前記係数を送信するステップと
をさらに含む、請求項１に記載の、ビデオデータを圧縮する方法。
【請求項３】
前記ステップＩは、ｅ）ビデオデータの各フレームについて前記ステップｃ）の前記係数の送信順序を動的に再配列するステップ、をさらに含む、請求項２に記載の、ビデオデータを圧縮する方法。
【請求項４】
前記変換するステップａ）は、離散コサイン変換係数に前記ピクセルを変換する、請求項２に記載の、ビデオデータを圧縮する方法。
【請求項５】
前記ステップＩは、前記ステップｃ）で求められた前記係数の送信順序を、前記ステップｄ）で送信される前記係数と共に送信するステップ、をさらに含む、請求項２に記載の、ビデオデータを圧縮する方法。
【請求項６】
各ブロックは、同じ個数の係数及び係数位置を有する、請求項２に記載の、ビデオデータを圧縮する方法。
【請求項７】
それぞれの対応する各係数位置は、ブロックごとに同じ情報を伝達する、請求項２に記載の、ビデオデータを圧縮する方法。
【請求項８】
前記ステップＩは、係数順序のデータの前記送信を、或るフレームから次のフレームにおいて前記係数順序が変化したものに限定するステップ、をさらに含む、請求項５に記載の、ビデオデータを圧縮する方法。
【請求項９】
前記ステップＩは、
ｉ）各帯域がステップｂ）で求められた数のランクによって編成された複数の係数を有する係数の帯域に、ステップｃ）の前記係数の送信順序を統合するステップと、
ｉｉ）帯域情報のみを、ステップｄ）で送信される前記係数と共に送信するステップと
をさらに含む、請求項２に記載の、ビデオデータを圧縮する方法。
【請求項１０】
前記ステップｉｉ）は、係数が或るフレームから次のフレームにおいて帯域を変更した場合に帯域情報のみを送信するステップ、をさらに含む、請求項９に記載の、ビデオデータを圧縮する方法。
【請求項１１】
前記ステップｉｉ）は、すべての帯域情報を常に送信するステップ、をさらに含む、請求項９に記載の、ビデオデータを圧縮する方法。
【請求項１２】
前記ステップＩは、常に完全に自己符号化され、且つ、前のフレームからの情報又は前のフレームに関する情報を必要としないキーフレームを提供するステップ、をさらに含む、請求項２に記載の、ビデオデータを圧縮する方法。
【請求項１３】
前記ステップＩは、
所与のフレームがキーフレームであるかどうかを判断するステップと、
前記所与のフレームがキーフレームであると判断された場合に、該キーフレームの前記係数の送信順序全体を送信するステップと、
前記所与のフレームがキーフレームでないと判断された場合に、前記前のフレームから前記所与のフレームにおける、前記係数の送信順序の変化したもののみを送信するステップと
をさらに含む、請求項１２に記載の、ビデオデータを圧縮する方法。
【請求項１４】
ステップＩＩは、
ａ）前記ビデオデータを少なくとも２つのデータパーティションに分割するステップ、
ｂ）各データパーティションについて最適なエントロピー符号化方法を選択するステップ、
ｃ）ステップｂ）で選択された前記エントロピー符号化方法を各データパーティションにそれぞれ適用するステップ、
をさらに含む、請求項１に記載の、ビデオデータを圧縮する方法。
【請求項１５】
ステップａ）は、前記ビデオデータを、プリディクタトークンデータパーティション及びエラートークンデータパーティションに分割するステップ、をさらに含む、請求項１４に記載の、ビデオデータを圧縮する方法。
【請求項１６】
各データパーティションは、ステップｂ）で異なるエントロピー符号化方法を選択している、請求項１４に記載の、ビデオデータを圧縮する方法。
【請求項１７】
ステップｂ）で選択された前記エントロピー符号化方法は、ハフマン符号化及び算術符号化を含む、請求項１４に記載の、ビデオデータを圧縮する方法。
【請求項１８】
前記データパーティションを非同期に復号するステップ、をさらに含む、請求項１４に記載の、ビデオデータを圧縮する方法。
【請求項１９】
少なくとも２つのサブプロセッサを設けるステップ、をさらに含み、或るデータパーティションは或るサブプロセッサによって復号され、別のデータパーティションは別のサブプロセッサによって復号される、請求項１８に記載の、ビデオデータを圧縮する方法。
【請求項２０】
前記選択するステップｂ）は、前記所与のデータパーティションのサイズに基づいて実行される、請求項１４に記載の、ビデオデータを圧縮する方法。
【請求項２１】
前記ステップＩＩは、
ｉ）前記プリディクタトークンデータパーティションを読み出すステップと、
ｉｉ）前記プリディクタトークンデータパーティションをプリディクタブロックに変換するステップと、
ｉｉｉ）前記エラートークンデータパーティションを読み出すステップと、
ｉｖ）前記エラートークンデータパーティションを係数に変換するステップと、
ｖ）前記係数をエラーブロックに変換するステップと、
ｖｉ）前記プリディクタブロック及び前記エラーブロックを追加するステップであって、それによって、画像ブロックを形成する、前記プリディクタブロック及び前記エラーブロックを追加するステップと
をさらに含む、請求項１５に記載の、ビデオデータを圧縮する方法。
【請求項２２】
前記ステップＩＩは、少なくとも２つのサブプロセッサを設けるステップ、をさらに含み、ステップｉ）〜ステップｖｉ）の少なくとも１つは或るサブプロセッサで実行され、ステップｉ）〜ステップｖｉ）の残りは別のサブプロセッサで実行される、請求項２１に記載の、ビデオデータを圧縮する方法。
【請求項２３】
ステップｉｉｉ）及びステップｉｖ）は、高速エントロピー最適化サブプロセッサによって実行され、ステップｉ）、ステップｉｉ）、ステップｖ）、及びステップｖｉ）は、汎用サブプロセッサによって実行される、請求項２２に記載の、ビデオデータを圧縮する方法。
【請求項２４】
データ及びコードのキャッシュミスを回避する、請求項１４に記載の方法に従って生成されたビットストリームの復号器の性能を最適化するための方法であって、該最適化方法は、
ｉ）前記コードキャッシュに適合できる個数の、前記復号器のコードの異なる関数を記憶するステップ、
ｉｉ）前記データキャッシュに適合できる個数のブロックについてステップｉ）からの前記コードを実行するステップ、
ｉｉｉ）前記復号器のコードの次の１組の異なる関数を収集するステップ、
ｉｖ）前記ビットストリームのすべてが読み出されて、前記データブロックのそれぞれが生成されるまで、ステップｉ）〜ステップｉｉｉ）を繰り返すステップ、
を含む、生成されたビットストリームの復号器の性能を最適化するための方法。
【請求項２５】
各サブタスクを別々のプロセッサに割り当てることによって、サブプロセッサの利用を最適化する、請求項１４に従って生成されたビットストリームの復号器の性能を最適化するための方法であって、
ｉ）前記ビットストリームからエラートークンを読み出して、該エラートークンを係数に変換する、前記復号器の部分を、高速エントロピー最適化サブプロセッサで実行するステップと、
ｉｉ）前記ビットストリームから前記プリディクタトークンを読み出して、これらのトークンからフィルタリングされたプリディクタブロックを構築する、前記復号器の部分を、メモリへの高速アクセスを有するサブプロセッサで実行するステップと、
ｉｉｉ）ステップｉ）からの前記変換係数をエラー信号に変換する、前記復号器の部分を、前記変換符号化器の最適化された実施態様を有するサブプロセッサで実行するステップと、
ｉｖ）ステップｉｉ）からの前記プリディクタブロックをステップｉｉｉ）からの前記エラー信号に加える、前記復号器の部分を、動き補償に最適化されたサブプロセッサで実行するステップと
を含む、生成されたビットストリームの復号器の性能を最適化するための方法。
【請求項２６】
前記分割するステップａ）は、前記ビデオデータを２つのデータパーティションに分割するステップ、をさらに含み、第１のデータパーティションは前記フレームの第１のエリアを表し、第２のデータパーティションは前記フレームの第２のエリアを表す、請求項１４に記載の、ビデオデータを圧縮する方法。
【請求項２７】
前記第１のデータパーティションは前記フレームの上半分を表し、前記第２のデータパーティションは前記フレームの下半分を表す、請求項２６に記載の、ビデオデータを圧縮する方法。
【請求項２８】
前記第１のデータパーティションは前記フレームの左半分を表し、前記第２のデータパーティションは前記フレームの右半分を表す、請求項２６に記載の、ビデオデータを圧縮する方法。
【請求項２９】
前記分割するステップａ）は、前記ビデオデータを３つのデータパーティションに分割するステップ、をさらに含み、各データパーティションは、それぞれ、前記フレームのレベル情報、彩度情報、及び色相情報を表す、請求項１４に記載の、ビデオデータを圧縮する方法。
【請求項３０】
前記分割するステップａ）は、前記ビデオデータを３つのデータパーティションに分割するステップ、をさらに含み、各データパーティションは、それぞれ、前記フレームのシアン情報、マゼンタ情報、及びイエロー情報を表す、請求項１４に記載の、ビデオデータを圧縮する方法。
【請求項３１】
ステップＩＩＩは、
ａ）符号化する所与の複数のピクセルに関連した前記少なくとも１つのメトリックの値を求めるステップと、
ｂ）ステップａ）で求められた前記少なくとも１つのメトリックの前記値に応じて、前記所与の複数のピクセルを符号化する補間方法を選択するステップと、
ｃ）ステップｂ）で選択された前記補間方法を、符号化する前記所与の複数のピクセルに適用するステップと、
ｄ）次に続く各複数のピクセルについてステップａ）〜ステップｃ）を繰り返すステップと
をさらに含む、請求項１に記載の、ビデオデータを圧縮する方法。
【請求項３２】
前記少なくとも１つのメトリックは、動きベクトル長及び複雑度因子の少なくとも１つである、請求項３１に記載の、ビデオデータを圧縮する方法。
【請求項３３】
前記ステップｂ）は、双１次補間、双３次補間、２次補間、及びＢスプライン補間から成っている群から補間方法を選択する、請求項３１に記載の、ビデオデータを圧縮する方法。
【請求項３４】
前記所与の複数のピクセルはフレーム全体である、請求項３１に記載の、ビデオデータを圧縮する方法。
【請求項３５】
ステップａ）は、
ｉ）前記所与の複数のピクセルに関連した動きベクトル長が、所定の長さ値よりも小さいかどうかを判断するステップと、
ｉｉ）前記所与の複数のピクセルに関連した複雑度因子が、所定の複雑度の値よりも大きいかどうかを判断するステップと
をさらに含む、請求項３１に記載の、ビデオデータを圧縮する方法。
【請求項３６】
前記所与の複数のピクセルに関連した前記動きベクトル長が、前記所定の長さ値よりも小さく、且つ、前記所与の複数のピクセルに関連した前記複雑度因子が、前記所定の複雑度の値よりも大きい場合に、ステップｂ）で選択される前記補間方法は双３次補間である、請求項３５に記載の、ビデオデータを圧縮する方法。
【請求項３７】
前記所定の長さ値及び前記所定の複雑度の値を、所与の個数の複数のピクセルについて１回設定するステップ、をさらに含む、請求項３５に記載の、ビデオデータを圧縮する方法。
【請求項３８】
前記設定するステップはフレームごとに１回実行される、請求項３７に記載の、ビデオデータを圧縮する方法。
【請求項３９】
ステップｉｉ）の前記複雑度因子は、前記所与の複数のピクセルの分散である、請求項３５に記載の、ビデオデータを圧縮する方法。
【請求項４０】
請求項３９に従ってビデオデータの動きを予測する方法であって、前記分散は、以下の方程式
Ｃ＝（ｎΣｘｉ２−（Σｘｉ）２）／ｎ２
に従って計算される、ビデオデータの動きを予測する方法。
【請求項４１】
前記ステップＩＶは、
ａ）喪失又は破損したパケットを引き起こす、ライン上の送信に関連した品質損失を少なくするために、最後のフレームの前に符号化されたフレームを、所与のフレームの唯一の基準フレームとして使用するステップと、
ｂ）ステップａ）の前記適用を、周期的及び任意の少なくとも１つに制限するステップと
をさらに含む、請求項１に記載の、ビデオデータを圧縮する方法。
【請求項４２】
ステップａ）及びステップｂ）をビデオ会議に適用するステップ、をさらに含む、請求項４１に記載の、ビデオデータを圧縮する方法。
【請求項４３】
ｃ）ビデオ会議の各当事者にビデオデータのフレームを圧縮させるステップと、
ｄ）前記ビデオ会議の各当事者に、前記圧縮されたビデオデータを、パケットの喪失又は破損が検出可能なようにマーキングされたパケットで他の当事者へ送信させるステップと、
ｅ）パケットが喪失又は破損したことをいずれかの当事者が検出する場合に、送信する当事者に信号で伝えることを前記検出する当事者に行わせるステップであって、それによって、残りの当事者のすべてがすでに受信に成功して復号している基準フレームを使用して符号化された更新フレームを送信する、送信する当事者に信号で伝えることを前記検出する当事者に行わせるステップと
をさらに含む、請求項４２に記載の、ビデオデータを圧縮する方法。
【請求項４４】
ｉ）ビデオフレームの一定の間隔Ｆを選択するステップと、
ｉｉ）この一定の間隔Ｆを前記復号器へ送信するステップと、
ｉｉｉ）Ｆ番目のフレームごとにフレームを、その前の符号化されたＦ番目のフレームのみを基準に使用して符号化するステップと、
ｉｖ）Ｆ番目でないあらゆるフレームを、その前のフレームを基準として使用して符号化するステップと、
ｖ）ビデオの各フレームを前記復号器へ送信し、それにより喪失及び破損が検出可能なようにするステップと
をさらに含む、請求項４１に記載の、ビデオデータを圧縮する方法。
【請求項４５】
前記ステップｉ）〜前記ステップｖ）は前記符号化器で行われる、請求項４４に記載の、ビデオデータを圧縮する方法。
【請求項４６】
ｖｉ）符号化されたビデオデータを前記符号化器から受信するステップと、
ｖｉｉ）前記ビデオを前記復号器で復号するステップと、
ｖｉｉｉ）パケットが喪失し、前記喪失したパケットがＦ番目でないフレームに関連したものである場合、次のＦ番目のフレームが前記喪失したパケットを回復するのを待つステップと
をさらに含む、請求項４５に記載の、ビデオデータを圧縮する方法。
【請求項４７】
前記ステップＩＶは、
現在のフレームを、この符号化されたフレーム及び前の符号化されたフレームから取得された統計値のメトリックによって求められた任意の品質よりも高い品質で、周期的及び任意の少なくとも１つで符号化するステップと、
前記符号化された現在のフレームを、２次的な基準フレームとしてのその後のフレームによる使用のために記憶するステップと
をさらに含む、請求項１に記載の、ビデオデータを圧縮する方法。
【請求項４８】
所与のフレームの前記ブロックは、前の符号化されたフレームの類似のサイズのブロックとの差分として符号化され、以下のステップ、すなわち、
ａ）或る前の符号化されたフレームにおける、符号化される前記ブロックと最も良く整合する前記ブロックを見つけるステップと、
ｂ）周囲の８ブロックのいずれが、ステップａ）で選択された前記ブロックと結合された場合に、符号化を試みている前記ブロックと最も近い整合を提供するかを判断するステップと、
ｃ）ステップａ）で選択された前記ブロックに関するメトリック、前記前の符号化されたフレーム、及び前記ブロックと係数を求めるために符号化される前記ブロックとの間に間隔をおく動きベクトルを使用するステップと
をさらに含む、請求項１に記載の、ビデオデータを圧縮する方法。
【請求項４９】
所与のフレームの前記ブロックは、前の符号化されたフレームにおける類似のサイズのブロックとの差分として符号化され、以下のステップ、すなわち、
ａ）或る前の符号化されたフレームにおける、符号化される前記ブロックと最も良く整合する前記ブロックを見つけるステップと、
ｂ）その最も良いブロックから離れた最も良い端数ピクセルステップを求めるステップと。
ｃ）前記ソースブロックとその最も良く整合するブロックとの間の、前記行及び列における前記差分から作成される動きベクトルを計算するステップと。
ｄ）符号化する時を判断するためのアルゴリズムを使用するステップであって、
全く動きベクトルを符号化しない、
近くの動きベクトルを参照することにより前記動きベクトルを符号化する、
前記動きベクトルを直接符号化する、
近くの動きベクトルからの差分ベクトルとして前記動きベクトルを符号化する、
時を判断するためのアルゴリズムを使用するステップと、
ｅ）前記動きベクトル又は前記差分ベクトルを送信するステップと
を含む、請求項１に記載の、ビデオデータを圧縮する方法。
【請求項５０】
左の前記ブロックが動きベクトルを有する場合には、そのブロックの前記動きベクトルから動きベクトルを差分符号化し、又は、上の前記ブロックが動きベクトルを有するが、該動きベクトルは有しない場合には、そのブロックの前記動きベクトルを差分符号化し、それ以外の場合には、前記動きベクトルを直接符号化するステップ、をさらに含む、請求項４９に記載の、ビデオデータを圧縮する方法。
【請求項５１】
平均又は重み付け平均を通じて前記左のブロックの動きベクトル及び前記上のブロックの動きベクトルを結合することによって計算される合成動きベクトルからの差分符号化を行うステップ、をさらに含む、請求項４９に記載の、ビデオデータを圧縮する方法。
【請求項５２】
前記左のブロックの前記動きベクトルからの差分として前記行を符号化し、前記上のブロックとの差分として前記列を符号化する、請求項４９に記載の、ビデオデータを圧縮する方法。
【請求項５３】
前記左のブロックの前記動きベクトル及び前記上のブロックの前記動きベクトルが類似していると判断された場合、前記上のブロック又は前記左のブロックとの差分として前記動きベクトルのみを符号化する、請求項５１に記載の、ビデオデータを圧縮する方法。
【請求項１】
各ブロックがピクセルの配列を有する少なくとも１つのブロックを有する少なくとも１つのフレームを有するビデオデータを圧縮する方法であって、
Ｉ）各ブロックの前記ピクセルを係数に変換して、該係数の最適な送信順序を作成するステップと、
ＩＩ）前記データのビットストリームを区画して各パーティションを独立に符号化することにより、圧縮されたビデオデータを処理する速度を最適化するステップと、
ＩＩＩ）所与の各ブロックに関連した少なくとも１つのメトリックに応じて所与の各複数のピクセルの補間方法を選択することにより、端数ピクセル動きを予測するステップと、
ＩＶ）現在のフレームの直前のフレームよりも前のフレームを唯一の基準フレームとして使用して前記現在のフレームのエラー回復を高度化するステップであって、それによって、データ送信中の品質損失を小さくする、前記現在のフレームのエラー回復を高度化するステップと
の少なくとも１つを含む、ビデオデータを圧縮する方法。
【請求項２】
ステップＩは、
ａ）各ブロックの前記ピクセルを、各係数が係数位置及び値を有する係数に変換するステップと、
ｂ）各係数位置に関連した位置の値を求めるステップと、
ｃ）前記ステップｂ）で求められた各係数位置の前記位置の値に基づいて、係数の最適な送信順序を作成するステップと、
ｄ）前記ステップｃ）で求められた前記順序で前記係数を送信するステップと
をさらに含む、請求項１に記載の、ビデオデータを圧縮する方法。
【請求項３】
前記ステップＩは、ｅ）ビデオデータの各フレームについて前記ステップｃ）の前記係数の送信順序を動的に再配列するステップ、をさらに含む、請求項２に記載の、ビデオデータを圧縮する方法。
【請求項４】
前記変換するステップａ）は、離散コサイン変換係数に前記ピクセルを変換する、請求項２に記載の、ビデオデータを圧縮する方法。
【請求項５】
前記ステップＩは、前記ステップｃ）で求められた前記係数の送信順序を、前記ステップｄ）で送信される前記係数と共に送信するステップ、をさらに含む、請求項２に記載の、ビデオデータを圧縮する方法。
【請求項６】
各ブロックは、同じ個数の係数及び係数位置を有する、請求項２に記載の、ビデオデータを圧縮する方法。
【請求項７】
それぞれの対応する各係数位置は、ブロックごとに同じ情報を伝達する、請求項２に記載の、ビデオデータを圧縮する方法。
【請求項８】
前記ステップＩは、係数順序のデータの前記送信を、或るフレームから次のフレームにおいて前記係数順序が変化したものに限定するステップ、をさらに含む、請求項５に記載の、ビデオデータを圧縮する方法。
【請求項９】
前記ステップＩは、
ｉ）各帯域がステップｂ）で求められた数のランクによって編成された複数の係数を有する係数の帯域に、ステップｃ）の前記係数の送信順序を統合するステップと、
ｉｉ）帯域情報のみを、ステップｄ）で送信される前記係数と共に送信するステップと
をさらに含む、請求項２に記載の、ビデオデータを圧縮する方法。
【請求項１０】
前記ステップｉｉ）は、係数が或るフレームから次のフレームにおいて帯域を変更した場合に帯域情報のみを送信するステップ、をさらに含む、請求項９に記載の、ビデオデータを圧縮する方法。
【請求項１１】
前記ステップｉｉ）は、すべての帯域情報を常に送信するステップ、をさらに含む、請求項９に記載の、ビデオデータを圧縮する方法。
【請求項１２】
前記ステップＩは、常に完全に自己符号化され、且つ、前のフレームからの情報又は前のフレームに関する情報を必要としないキーフレームを提供するステップ、をさらに含む、請求項２に記載の、ビデオデータを圧縮する方法。
【請求項１３】
前記ステップＩは、
所与のフレームがキーフレームであるかどうかを判断するステップと、
前記所与のフレームがキーフレームであると判断された場合に、該キーフレームの前記係数の送信順序全体を送信するステップと、
前記所与のフレームがキーフレームでないと判断された場合に、前記前のフレームから前記所与のフレームにおける、前記係数の送信順序の変化したもののみを送信するステップと
をさらに含む、請求項１２に記載の、ビデオデータを圧縮する方法。
【請求項１４】
ステップＩＩは、
ａ）前記ビデオデータを少なくとも２つのデータパーティションに分割するステップ、
ｂ）各データパーティションについて最適なエントロピー符号化方法を選択するステップ、
ｃ）ステップｂ）で選択された前記エントロピー符号化方法を各データパーティションにそれぞれ適用するステップ、
をさらに含む、請求項１に記載の、ビデオデータを圧縮する方法。
【請求項１５】
ステップａ）は、前記ビデオデータを、プリディクタトークンデータパーティション及びエラートークンデータパーティションに分割するステップ、をさらに含む、請求項１４に記載の、ビデオデータを圧縮する方法。
【請求項１６】
各データパーティションは、ステップｂ）で異なるエントロピー符号化方法を選択している、請求項１４に記載の、ビデオデータを圧縮する方法。
【請求項１７】
ステップｂ）で選択された前記エントロピー符号化方法は、ハフマン符号化及び算術符号化を含む、請求項１４に記載の、ビデオデータを圧縮する方法。
【請求項１８】
前記データパーティションを非同期に復号するステップ、をさらに含む、請求項１４に記載の、ビデオデータを圧縮する方法。
【請求項１９】
少なくとも２つのサブプロセッサを設けるステップ、をさらに含み、或るデータパーティションは或るサブプロセッサによって復号され、別のデータパーティションは別のサブプロセッサによって復号される、請求項１８に記載の、ビデオデータを圧縮する方法。
【請求項２０】
前記選択するステップｂ）は、前記所与のデータパーティションのサイズに基づいて実行される、請求項１４に記載の、ビデオデータを圧縮する方法。
【請求項２１】
前記ステップＩＩは、
ｉ）前記プリディクタトークンデータパーティションを読み出すステップと、
ｉｉ）前記プリディクタトークンデータパーティションをプリディクタブロックに変換するステップと、
ｉｉｉ）前記エラートークンデータパーティションを読み出すステップと、
ｉｖ）前記エラートークンデータパーティションを係数に変換するステップと、
ｖ）前記係数をエラーブロックに変換するステップと、
ｖｉ）前記プリディクタブロック及び前記エラーブロックを追加するステップであって、それによって、画像ブロックを形成する、前記プリディクタブロック及び前記エラーブロックを追加するステップと
をさらに含む、請求項１５に記載の、ビデオデータを圧縮する方法。
【請求項２２】
前記ステップＩＩは、少なくとも２つのサブプロセッサを設けるステップ、をさらに含み、ステップｉ）〜ステップｖｉ）の少なくとも１つは或るサブプロセッサで実行され、ステップｉ）〜ステップｖｉ）の残りは別のサブプロセッサで実行される、請求項２１に記載の、ビデオデータを圧縮する方法。
【請求項２３】
ステップｉｉｉ）及びステップｉｖ）は、高速エントロピー最適化サブプロセッサによって実行され、ステップｉ）、ステップｉｉ）、ステップｖ）、及びステップｖｉ）は、汎用サブプロセッサによって実行される、請求項２２に記載の、ビデオデータを圧縮する方法。
【請求項２４】
データ及びコードのキャッシュミスを回避する、請求項１４に記載の方法に従って生成されたビットストリームの復号器の性能を最適化するための方法であって、該最適化方法は、
ｉ）前記コードキャッシュに適合できる個数の、前記復号器のコードの異なる関数を記憶するステップ、
ｉｉ）前記データキャッシュに適合できる個数のブロックについてステップｉ）からの前記コードを実行するステップ、
ｉｉｉ）前記復号器のコードの次の１組の異なる関数を収集するステップ、
ｉｖ）前記ビットストリームのすべてが読み出されて、前記データブロックのそれぞれが生成されるまで、ステップｉ）〜ステップｉｉｉ）を繰り返すステップ、
を含む、生成されたビットストリームの復号器の性能を最適化するための方法。
【請求項２５】
各サブタスクを別々のプロセッサに割り当てることによって、サブプロセッサの利用を最適化する、請求項１４に従って生成されたビットストリームの復号器の性能を最適化するための方法であって、
ｉ）前記ビットストリームからエラートークンを読み出して、該エラートークンを係数に変換する、前記復号器の部分を、高速エントロピー最適化サブプロセッサで実行するステップと、
ｉｉ）前記ビットストリームから前記プリディクタトークンを読み出して、これらのトークンからフィルタリングされたプリディクタブロックを構築する、前記復号器の部分を、メモリへの高速アクセスを有するサブプロセッサで実行するステップと、
ｉｉｉ）ステップｉ）からの前記変換係数をエラー信号に変換する、前記復号器の部分を、前記変換符号化器の最適化された実施態様を有するサブプロセッサで実行するステップと、
ｉｖ）ステップｉｉ）からの前記プリディクタブロックをステップｉｉｉ）からの前記エラー信号に加える、前記復号器の部分を、動き補償に最適化されたサブプロセッサで実行するステップと
を含む、生成されたビットストリームの復号器の性能を最適化するための方法。
【請求項２６】
前記分割するステップａ）は、前記ビデオデータを２つのデータパーティションに分割するステップ、をさらに含み、第１のデータパーティションは前記フレームの第１のエリアを表し、第２のデータパーティションは前記フレームの第２のエリアを表す、請求項１４に記載の、ビデオデータを圧縮する方法。
【請求項２７】
前記第１のデータパーティションは前記フレームの上半分を表し、前記第２のデータパーティションは前記フレームの下半分を表す、請求項２６に記載の、ビデオデータを圧縮する方法。
【請求項２８】
前記第１のデータパーティションは前記フレームの左半分を表し、前記第２のデータパーティションは前記フレームの右半分を表す、請求項２６に記載の、ビデオデータを圧縮する方法。
【請求項２９】
前記分割するステップａ）は、前記ビデオデータを３つのデータパーティションに分割するステップ、をさらに含み、各データパーティションは、それぞれ、前記フレームのレベル情報、彩度情報、及び色相情報を表す、請求項１４に記載の、ビデオデータを圧縮する方法。
【請求項３０】
前記分割するステップａ）は、前記ビデオデータを３つのデータパーティションに分割するステップ、をさらに含み、各データパーティションは、それぞれ、前記フレームのシアン情報、マゼンタ情報、及びイエロー情報を表す、請求項１４に記載の、ビデオデータを圧縮する方法。
【請求項３１】
ステップＩＩＩは、
ａ）符号化する所与の複数のピクセルに関連した前記少なくとも１つのメトリックの値を求めるステップと、
ｂ）ステップａ）で求められた前記少なくとも１つのメトリックの前記値に応じて、前記所与の複数のピクセルを符号化する補間方法を選択するステップと、
ｃ）ステップｂ）で選択された前記補間方法を、符号化する前記所与の複数のピクセルに適用するステップと、
ｄ）次に続く各複数のピクセルについてステップａ）〜ステップｃ）を繰り返すステップと
をさらに含む、請求項１に記載の、ビデオデータを圧縮する方法。
【請求項３２】
前記少なくとも１つのメトリックは、動きベクトル長及び複雑度因子の少なくとも１つである、請求項３１に記載の、ビデオデータを圧縮する方法。
【請求項３３】
前記ステップｂ）は、双１次補間、双３次補間、２次補間、及びＢスプライン補間から成っている群から補間方法を選択する、請求項３１に記載の、ビデオデータを圧縮する方法。
【請求項３４】
前記所与の複数のピクセルはフレーム全体である、請求項３１に記載の、ビデオデータを圧縮する方法。
【請求項３５】
ステップａ）は、
ｉ）前記所与の複数のピクセルに関連した動きベクトル長が、所定の長さ値よりも小さいかどうかを判断するステップと、
ｉｉ）前記所与の複数のピクセルに関連した複雑度因子が、所定の複雑度の値よりも大きいかどうかを判断するステップと
をさらに含む、請求項３１に記載の、ビデオデータを圧縮する方法。
【請求項３６】
前記所与の複数のピクセルに関連した前記動きベクトル長が、前記所定の長さ値よりも小さく、且つ、前記所与の複数のピクセルに関連した前記複雑度因子が、前記所定の複雑度の値よりも大きい場合に、ステップｂ）で選択される前記補間方法は双３次補間である、請求項３５に記載の、ビデオデータを圧縮する方法。
【請求項３７】
前記所定の長さ値及び前記所定の複雑度の値を、所与の個数の複数のピクセルについて１回設定するステップ、をさらに含む、請求項３５に記載の、ビデオデータを圧縮する方法。
【請求項３８】
前記設定するステップはフレームごとに１回実行される、請求項３７に記載の、ビデオデータを圧縮する方法。
【請求項３９】
ステップｉｉ）の前記複雑度因子は、前記所与の複数のピクセルの分散である、請求項３５に記載の、ビデオデータを圧縮する方法。
【請求項４０】
請求項３９に従ってビデオデータの動きを予測する方法であって、前記分散は、以下の方程式
Ｃ＝（ｎΣｘｉ２−（Σｘｉ）２）／ｎ２
に従って計算される、ビデオデータの動きを予測する方法。
【請求項４１】
前記ステップＩＶは、
ａ）喪失又は破損したパケットを引き起こす、ライン上の送信に関連した品質損失を少なくするために、最後のフレームの前に符号化されたフレームを、所与のフレームの唯一の基準フレームとして使用するステップと、
ｂ）ステップａ）の前記適用を、周期的及び任意の少なくとも１つに制限するステップと
をさらに含む、請求項１に記載の、ビデオデータを圧縮する方法。
【請求項４２】
ステップａ）及びステップｂ）をビデオ会議に適用するステップ、をさらに含む、請求項４１に記載の、ビデオデータを圧縮する方法。
【請求項４３】
ｃ）ビデオ会議の各当事者にビデオデータのフレームを圧縮させるステップと、
ｄ）前記ビデオ会議の各当事者に、前記圧縮されたビデオデータを、パケットの喪失又は破損が検出可能なようにマーキングされたパケットで他の当事者へ送信させるステップと、
ｅ）パケットが喪失又は破損したことをいずれかの当事者が検出する場合に、送信する当事者に信号で伝えることを前記検出する当事者に行わせるステップであって、それによって、残りの当事者のすべてがすでに受信に成功して復号している基準フレームを使用して符号化された更新フレームを送信する、送信する当事者に信号で伝えることを前記検出する当事者に行わせるステップと
をさらに含む、請求項４２に記載の、ビデオデータを圧縮する方法。
【請求項４４】
ｉ）ビデオフレームの一定の間隔Ｆを選択するステップと、
ｉｉ）この一定の間隔Ｆを前記復号器へ送信するステップと、
ｉｉｉ）Ｆ番目のフレームごとにフレームを、その前の符号化されたＦ番目のフレームのみを基準に使用して符号化するステップと、
ｉｖ）Ｆ番目でないあらゆるフレームを、その前のフレームを基準として使用して符号化するステップと、
ｖ）ビデオの各フレームを前記復号器へ送信し、それにより喪失及び破損が検出可能なようにするステップと
をさらに含む、請求項４１に記載の、ビデオデータを圧縮する方法。
【請求項４５】
前記ステップｉ）〜前記ステップｖ）は前記符号化器で行われる、請求項４４に記載の、ビデオデータを圧縮する方法。
【請求項４６】
ｖｉ）符号化されたビデオデータを前記符号化器から受信するステップと、
ｖｉｉ）前記ビデオを前記復号器で復号するステップと、
ｖｉｉｉ）パケットが喪失し、前記喪失したパケットがＦ番目でないフレームに関連したものである場合、次のＦ番目のフレームが前記喪失したパケットを回復するのを待つステップと
をさらに含む、請求項４５に記載の、ビデオデータを圧縮する方法。
【請求項４７】
前記ステップＩＶは、
現在のフレームを、この符号化されたフレーム及び前の符号化されたフレームから取得された統計値のメトリックによって求められた任意の品質よりも高い品質で、周期的及び任意の少なくとも１つで符号化するステップと、
前記符号化された現在のフレームを、２次的な基準フレームとしてのその後のフレームによる使用のために記憶するステップと
をさらに含む、請求項１に記載の、ビデオデータを圧縮する方法。
【請求項４８】
所与のフレームの前記ブロックは、前の符号化されたフレームの類似のサイズのブロックとの差分として符号化され、以下のステップ、すなわち、
ａ）或る前の符号化されたフレームにおける、符号化される前記ブロックと最も良く整合する前記ブロックを見つけるステップと、
ｂ）周囲の８ブロックのいずれが、ステップａ）で選択された前記ブロックと結合された場合に、符号化を試みている前記ブロックと最も近い整合を提供するかを判断するステップと、
ｃ）ステップａ）で選択された前記ブロックに関するメトリック、前記前の符号化されたフレーム、及び前記ブロックと係数を求めるために符号化される前記ブロックとの間に間隔をおく動きベクトルを使用するステップと
をさらに含む、請求項１に記載の、ビデオデータを圧縮する方法。
【請求項４９】
所与のフレームの前記ブロックは、前の符号化されたフレームにおける類似のサイズのブロックとの差分として符号化され、以下のステップ、すなわち、
ａ）或る前の符号化されたフレームにおける、符号化される前記ブロックと最も良く整合する前記ブロックを見つけるステップと、
ｂ）その最も良いブロックから離れた最も良い端数ピクセルステップを求めるステップと。
ｃ）前記ソースブロックとその最も良く整合するブロックとの間の、前記行及び列における前記差分から作成される動きベクトルを計算するステップと。
ｄ）符号化する時を判断するためのアルゴリズムを使用するステップであって、
全く動きベクトルを符号化しない、
近くの動きベクトルを参照することにより前記動きベクトルを符号化する、
前記動きベクトルを直接符号化する、
近くの動きベクトルからの差分ベクトルとして前記動きベクトルを符号化する、
時を判断するためのアルゴリズムを使用するステップと、
ｅ）前記動きベクトル又は前記差分ベクトルを送信するステップと
を含む、請求項１に記載の、ビデオデータを圧縮する方法。
【請求項５０】
左の前記ブロックが動きベクトルを有する場合には、そのブロックの前記動きベクトルから動きベクトルを差分符号化し、又は、上の前記ブロックが動きベクトルを有するが、該動きベクトルは有しない場合には、そのブロックの前記動きベクトルを差分符号化し、それ以外の場合には、前記動きベクトルを直接符号化するステップ、をさらに含む、請求項４９に記載の、ビデオデータを圧縮する方法。
【請求項５１】
平均又は重み付け平均を通じて前記左のブロックの動きベクトル及び前記上のブロックの動きベクトルを結合することによって計算される合成動きベクトルからの差分符号化を行うステップ、をさらに含む、請求項４９に記載の、ビデオデータを圧縮する方法。
【請求項５２】
前記左のブロックの前記動きベクトルからの差分として前記行を符号化し、前記上のブロックとの差分として前記列を符号化する、請求項４９に記載の、ビデオデータを圧縮する方法。
【請求項５３】
前記左のブロックの前記動きベクトル及び前記上のブロックの前記動きベクトルが類似していると判断された場合、前記上のブロック又は前記左のブロックとの差分として前記動きベクトルのみを符号化する、請求項５１に記載の、ビデオデータを圧縮する方法。
【公開番号】特開２０１１−５００９０（Ｐ２０１１−５００９０Ａ）
【公開日】平成２３年３月１０日（２０１１．３．１０）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１０−２３９０１８（Ｐ２０１０−２３９０１８）
【出願日】平成２２年１０月２５日（２０１０．１０．２５）
【分割の表示】特願２０１０−１２１００８（Ｐ２０１０−１２１００８）の分割
【原出願日】平成１６年５月１２日（２００４．５．１２）
【出願人】（５０２２０８３９７）グーグル インコーポレイテッド (161)
【Ｆターム（参考）】
【公開日】平成２３年３月１０日（２０１１．３．１０）
【国際特許分類】
【出願番号】特願２０１０−２３９０１８（Ｐ２０１０−２３９０１８）
【出願日】平成２２年１０月２５日（２０１０．１０．２５）
【分割の表示】特願２０１０−１２１００８（Ｐ２０１０−１２１００８）の分割
【原出願日】平成１６年５月１２日（２００４．５．１２）
【出願人】（５０２２０８３９７）グーグル インコーポレイテッド (161)
【Ｆターム（参考）】
[ Back to top ]