(57)【要約】【課題】  ビデオデコーダにおける誤り隠蔽を効率化する。【解決手段】  ここで開示される誤り隠蔽技術は、ビットストリームの誤りを隠蔽するために、エンコーダの動作によらずに、デコーダによって既存の情報を利用することに関するものである。既存の情報の例としては、たとえば、直前の参照フレーム、直前の参照フレームのマクロブロック情報、などがある。ここで記載されるシステムの別の側面は、デコーダがきれいな形で伝送誤りから回復する機能を高めるためにエンコーダ側が行うことのできる措置に関するものである。エンコーダ側が行うことのできる措置の例としては、イントラ遍歴およびＧＯＢヘッダ送信がある。これらのエンコーダ側技術は結果を大いに改善するものの、ここに記載されるシステムに厳密に必要なものではない。【選択図】図１
2006060813.tif 000002
【特許請求の範囲】
【請求項１】
フレームのすべてのマクロブロックを失われたマクロブロックと指定し、
前記フレームが復号されるにつれて、復号が成功した各マクロブロックを良好マクロブロックと指定し、
誤りが検出された場合、以前の同期点以降に受信された各マクロブロックを改めて失われたマクロブロックと指定し、
前記誤りのあとにくる同期点においてエンコーダと再同期する、
ことを含むことを特徴とする、複数の同期点を有するビデオ信号を復号する方法。
【請求項２】
前記同期点が、フレーム、ブロックグループ、マクロブロック、ネットワーク適応層単位からなる群から選択されることを特徴とする、請求項１記載の方法。
【請求項３】
フレーム全体の復号時に、失われたマクロブロックと指定されている各マクロブロックを再構築する、
ことをさらに含むことを特徴とする、請求項１記載の方法。
【請求項４】
失われたマクロブロックとして指定された各マクロブロックの前記再構築が：
前記失われたマクロブロックについてのマクロブロック情報を以前のフレームの対応するマクロブロックについてのマクロブロック情報の値に設定することを特徴とする、請求項３記載の方法。
【請求項５】
前記マクロブロック情報が：
当該マクロブロックがインター符号化されたものかイントラ符号化されたものかと、
当該マクロブロックがインター符号化されたものである場合にはその動きベクトルとを含むことを特徴とする、請求項４記載の方法。
【請求項６】
失われたマクロブロックとして指定された各マクロブロックの前記再構築が、
前記失われたマクロブロックが最も最近のフレームを基準としてインター符号化されていた場合、前記再構築されるマクロブロックの動きベクトルを前記最も最近のフレームの対応するマクロブロックの動きベクトルに設定し、前記再構築されるマクロブロックの係数を０に設定し、
前記失われたマクロブロックが最も最近のフレーム以外の以前のフレームを基準としてインター符号化されていたか、前記失われたマクロブロックがイントラ符号化されていた場合、前記再構築されるマクロブロックを直前のフレームにおける対応するマクロブロックの値に設定する、
ことをさらに含むことを特徴とする、請求項４記載の方法。
【請求項７】
前記再構築されるマクロブロックのためのフレーム全体のイントラ更新を要求することをさらに含むことを特徴とする、請求項３記載の方法。
【請求項８】
イントラ遍歴更新が備わっている場合にはフレーム全体のイントラ更新が要求されないことを特徴とする、請求項７記載の方法。
【請求項９】
請求項８記載の方法であって、イントラ遍歴更新が備わっているかどうかの判定を、
失われたマクロブロックについて失われたとマークされる時点でタイムスタンプを記録し、
前記マクロブロックに対するイントラ更新が受信されたときに前記タイムスタンプを改めてセットし、
各フレームの終わりに各マクロブロックの前記タイムスタンプを検査し、所定の期間より長い間失われたとマークされていたマクロブロックがあればフレーム全体の高速更新を要求する、という方法に従って行うことをさらに含むことを特徴とする方法。
【請求項１０】
フレームのすべてのマクロブロックを失われたマクロブロックと指定し、
前記フレームが復号されるにつれて、復号が成功した各マクロブロックを良好マクロブロックと指定し、
所定の誤りビット列を受信することによって誤りが検出された場合、参照フレームの更新をやめる、
ことを含むことを特徴とする、ビデオ信号を復号する方法。
【請求項１１】
前記所定の誤りビット列が、ブリッジ、ゲートウェイおよび多地点接続装置からなる群から選ばれる要素中に存在するデータリンク層監視手段によって当該ビットストリーム中に挿入されることを特徴とする、請求項１０記載の方法。
【請求項１２】
前記所定の誤りビット列が、一つのビデオデコーダが対応している複数のビデオコーデックのうちの一つ以上に対する誤りを生成するよう設計されていることを特徴とする、請求項１０記載の方法。
【請求項１３】
フレームのすべてのマクロブロックを失われたマクロブロックと指定し、
前記フレームが復号されるにつれて、復号が成功した各マクロブロックを良好マクロブロックと指定し、
誤りが検出された場合、以前の同期点以降に受信された各マクロブロックを改めて失われたマクロブロックと指定し、
前記誤りのあとにくる同期点においてエンコーダと再同期する、
ことを含むことを特徴とするビデオ復号方法を実装するよう構成されたビデオデコーダ。
【請求項１４】
前記同期点が、フレーム、ブロックグループ、マクロブロック、ネットワーク適応層単位からなる群から選択されることを特徴とする、請求項１３記載のビデオデコーダ。
【請求項１５】
前記ビデオ復号方法が：
フレーム全体の復号時に、失われたマクロブロックと指定されている各マクロブロックを再構築する、
ことをさらに含むことを特徴とする、請求項１３記載のビデオデコーダ。
【請求項１６】
失われたマクロブロックとして指定された各マクロブロックの前記再構築が：
前記失われたマクロブロックについてのマクロブロック情報を以前のフレームの対応するマクロブロックについてのマクロブロック情報の値に設定することを特徴とする、請求項１５記載のビデオデコーダ。
【請求項１７】
前記マクロブロック情報が、
当該マクロブロックがインター符号化されたものかイントラ符号化されたものかと、
当該マクロブロックがインター符号化されたものである場合にはその動きベクトルとを含むことを特徴とする、請求項１６記載のビデオデコーダ。
【請求項１８】
失われたマクロブロックとして指定された各マクロブロックの前記再構築が、
前記失われたマクロブロックが最も最近のフレームを基準としてインター符号化されていた場合、前記再構築されるマクロブロックの動きベクトルを前記最も最近のフレームの対応するマクロブロックの動きベクトルに設定し、前記再構築されるマクロブロックの係数を０に設定し、
前記失われたマクロブロックが最も最近のフレーム以外の以前のフレームを基準としてインター符号化されていたか、前記失われたマクロブロックがイントラ符号化されていた場合、前記再構築されるマクロブロックを直前のフレームにおける対応するマクロブロックの値に設定する、
ことをさらに含むことを特徴とする、請求項１６記載のビデオデコーダ。
【請求項１９】
前記ビデオ復号方法が、前記再構築されるマクロブロックのためのフレーム全体のイントラ更新を要求することをさらに含むことを特徴とする、請求項１５記載のビデオデコーダ。
【請求項２０】
イントラ遍歴更新が備わっている場合にはフレーム全体のイントラ更新が要求されないことを特徴とする、請求項１９記載のビデオデコーダ。
【請求項２１】
請求項２０記載のビデオデコーダであって、前記ビデオ復号方法が、イントラ遍歴更新が備わっているかどうかの判定を、
失われたマクロブロックについて失われたとマークされる時点でタイムスタンプを記録し、
前記マクロブロックに対するイントラ更新が受信されたときに前記タイムスタンプを改めてセットし、
各フレームの終わりに各マクロブロックの前記タイムスタンプを検査し、所定の期間より長い間失われたとマークされていたマクロブロックがあればフレーム全体の高速更新を要求する、という方法に従って行うことをさらに含むことを特徴とするビデオデコーダ。
【請求項２２】
フレームのすべてのマクロブロックを失われたマクロブロックと指定し、
前記フレームが復号されるにつれて、復号が成功した各マクロブロックを良好マクロブロックと指定し、
所定の誤りビット列を受信することによって誤りが検出された場合、参照フレームの更新をやめる、
ことを含むことを特徴とするビデオ復号方法を実装するよう構成されているビデオデコーダ。
【請求項２３】
前記所定の誤りビット列が、ブリッジ、ゲートウェイおよび多地点接続装置からなる群から選ばれる要素中に存在するデータリンク層監視手段によって当該ビットストリーム中に挿入されることを特徴とする、請求項２２記載のビデオデコーダ。
【請求項２４】
前記所定の誤りビット列が、一つのビデオデコーダが対応している複数のビデオコーデックのうちの一つ以上に対する誤りを生成するよう設計されていることを特徴とする、請求項２２記載のビデオデコーダ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般にはビデオ通信に、より詳細にはビデオビットストリームにおける誤りを検出し、隠蔽する方法に関するものである。
【背景技術】
【０００２】
ビデオ画像のデジタル化はますますその重要性を増してきている。世界規模での通信（たとえばテレビ会議）に加え、デジタルビデオ録画のためのビデオ画像のデジタル化もまたますます一般的になってきた。これらの応用分野のそれぞれにおいて、ビデオ情報は、電話線、ＩＳＤＮ、ＤＳＬ、無線周波のような電気通信接続を通じて伝送され、ＤＶＤ、ＳＶＣＤのようなさまざまなメディア装置上に記録される。多くの場合、送信や記録の際にはビデオビットストリームに誤りが導入されやすい。
【０００３】
ビデオデータの効率的な送信、受信、記録は典型的にはそのビデオデータをエンコードし、圧縮することを必要とする。もとになるビデオ信号をエンコードし、圧縮するにはさまざまな手法と規格が存在している。いくつかの規格は、テレビ会議の応用分野で広範に用いられるＩＴＵ−Ｔ勧告Ｈ．２６１、Ｈ．２６３、Ｈ．２６４のように、特定の応用分野のために設計されている。加えて、動画像専門家グループ（Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ’  Ｇｒｏｕｐ）によって制定された規格（ＭＰＥＧ−２、ＭＰＥＧ−４）は家庭用電子機器その他の応用分野において幅広い応用を見出している。これらの規格のそれぞれは、その全体を引用することによって組み込まれる。
【０００４】
いずれの場合でも、デジタル画像は個々のピクセルの格子からなっている。典型的には画像全体が一度に処理されるのではなく、ブロックに分割されて個別に処理される。各ブロックは所定の数のルミナンスまたはルーマのピクセル（一般的な言い方をするとピクセルの明るさを指定する）および所定の数のクロミナンスまたはクロマ（一般的な言い方をするとピクセルの色を指定する）の長方形の格子からなる。所定の数のブロックが組み合わされてマクロブロックとなり、たいていの体系ではこれが処理の基本単位をなす。処理単位のこの階層構造について、下記でも一部の側面については述べるが、処理する画像のブロックベースの処理の方法および技術は一般に当業者には既知であり、よってここで詳細に繰り返すことはしない。
【０００５】
画像データのマクロブロックのエンコードは、二つの基本的な技法のうちの一方の変形によって行いうる。たとえば、「イントラ」符号化を用いれば、原マクロブロックは、以前のフレームの対応するマクロブロックのような履歴データを参照することなくエンコードされる。また、「インター」符号化を用いれば、画像データのマクロブロックは、当該マクロブロックと、以前のフレームの対応するマクロブロックのような基準となるデータのマクロブロックとの間の差としてエンコードされる。これら二つの基本方式にはさまざまな変形が当業者には知られており、よってここで詳細を議論することはしない。一般に、データのマクロブロックを記述するのに、ビット数が最も少なくてすむようなエンコード技術を選択することが望ましい。典型的にはイントラ符号化は同じブロックを表現するのにずっと多くのビットを必要とし、そのため一般にはインター符号化が好まれている。
【０００６】
テレビ会議の「通話」は典型的には二つの技術のうちの一方を使ってかけられる。伝統的には回線交換ネットワーク（たとえばＩＳＤＮ電話線）が使われてきた。典型的にはこれらの通話は、国際電気通信連合（ＩＴＵ：Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｕｎｉｏｎ）勧告Ｈ．３２０の“Ｎａｒｒｏｗ−Ｂａｎｄ  Ｖｉｓｕａｌ  Ｔｅｌｅｐｈｏｎｅ  Ｓｙｓｔｅｍｓ  Ａｎｄ  Ｔｅｒｍｉｎａｌ  Ｅｑｕｉｐｍｅｎｔ”〔ナローバンドのテレビ電話システムおよび端末装置〕に従ってかけられる。より最近では、インターネットのようなパケット交換ネットワークがテレビ会議により広く使われるようになった。パケット交換によるマルチメディア通信プロトコルにはさまざまなものがあるが、その一つの例がＩＴＵ勧告Ｈ．３２３の“Ｐａｃｋｅｔ−ｂａｓｅｄ  Ｍｕｌｔｉｍｅｄｉａ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍｓ”〔パケットベースのマルチメディア通信システム〕である。これらの勧告はそれぞれ、その全体を引用することによってここに組み込まれる。ここでの説明はこれら二つのプロトコルのいずれかに関するものであるが、本発明はこれらのプロトコルだけに限定されるものではないことを注意しておく。
【０００７】
いずれかの技術を用いて送信されるビデオ通話は、多くの場合、送信中に誤りを受ける可能性がある。伝統的には、デコーダがビットストリームの誤りを検出した場合には二つの選択肢がある。第一の選択肢は、表示を凍結して送信側に高速の更新を要求することである。送信側はそのような要求を受けてイントラフレームを送る。受信側の表示は、そのイントラフレームが受信されるまで凍結されたままとなる。画面が凍結しているこうした時間はユーザーの印象を悪くする。第二の選択肢は、高速の更新を要求しはするが、誤りを含むフレームの表示を続けることである。要求されたイントラフレームが到着するまでは、明るい色のブロック、黒のブロック、あるいはスクランブルされた画像など、画像乱れが続く。そのような乱れは典型的にはユーザーに、表示の凍結以上にひどい印象を与えるので、テレビ会議業界におけるこれまでの慣用は、オプション１、すなわち表示の凍結を選ぶことによって誤りを隠すことであった。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、上述した二つの選択肢はいずれも望ましいものではない。よって、当業界で必要とされているのは、ユーザーに乱れているとの印象を与える度合いがより少ない、これに代わるビデオ伝送の誤り隠蔽技術である。したがって、本発明が指向するのは一般には、ビデオの誤りを隠蔽し、視覚上の乱れを低減または解消し、イントラ更新フレームによって起こされる視覚上の乱れの効果を低減または解消するための方法に向けられている。テレビ会議システムの場合について説明されているが、ここに記載される概念はあらゆるビデオ符号化および復号の応用分野について同じように適応可能である。
【課題を解決するための手段】
【０００９】
ここで開示される誤り隠蔽技術は、ビットストリームの誤りを隠蔽するために、エンコーダの動作によらずに、デコーダによって既存の情報を利用することに関するものである。既存の情報の例としては、たとえば、直前の参照フレーム、直前の参照フレームのマクロブロック情報、などがある。ここで記載されるシステムの別の側面は、デコーダがきれいな形で伝送誤りから回復する機能を高めるためにエンコーダ側が行うことのできる措置に関するものである。エンコーダ側が行うことのできる措置の例としては、イントラ遍歴（ｉｎｔｒａ  ｗａｌｋ  ａｒｏｕｎｄ）およびＧＯＢヘッダ送信がある。これらのエンコーダ側技術は結果を大いに改善するものの、ここに記載されるシステムに厳密に必要なものではない。
【発明の効果】
【００１０】
ここに開示されるシステムには多くの利点があるが、それは以下の詳細な説明をさらに参照することで明らかとなるであろう。たとえば、本システムは完全に規格に基づいており、したがって既存の端末、ゲートウェイ、多地点接続装置も含めて規格に準拠したいかなるテレビ会議システムとも互換性がある。さらに、本システムはＨ．２６１、Ｈ．２６３、Ｈ．２６４規格のいずれを使ってエンコードされたビデオにも対応できる。ここに記載されるシステムはまた実装が容易で、Ｈ．２６４デコーダの場合は特にそうである。さらに、上で述べたように、ここに記載されるエンコーダ側、デコーダ側の機能強化をともに有することが好ましいとはいえ、デコーダ側だけでもユーザーの印象を著しく改善することができる。ここに記載されるシステムのさらなる利点としては、符号化効率への影響が無視できるほどであること、追加的に必要となる計算が最小限となることが挙げられる。
【発明を実施するための最良の形態】
【００１１】
先に簡単に触れたように、ビデオストリームの伝送には本質的に二つの方法がある。ＩＳＤＮネットワーク上でのビットの流れと、ＩＰネットワーク上でのパケットの流れである。いずれもデコーダが同期がとれなくなるような誤りを生じることがある。そうした誤りをうまく隠蔽するには、三つの重要なステップがある。第一に、デコーダは、誤りの影響をできる限り映像中の小さな領域に制限する必要がある。第二に、デコーダは既存の情報を用いて復号がうまくいかなかった領域を修正しなければならない。第三に、必要ならデコーダは遠方にあるエンコーダに接触して、該デコーダをエンコーダと再同期させるための欠けている情報を送ってもらってもよい。エンコーダ側は、イントラ遍歴または比較的高頻度でのキーフレームの送信といった方法によってこの第三のステップを不要にすることもできる。
【００１２】
ひとたび誤りが検出されたら、デコーダが復号処理を続けられるためには、デコーダは再同期する必要がある。ビットストリーム中には、デコーダが再同期できる四つの異なる点がある。第一の同期点はフレームレベルのものである。フレームレベルの同期を用いることで、デコーダは現在復号中のフレームはあきらめて、映像開始コード（Ｐｉｃｔｕｒｅ  Ｓｔａｒｔ  Ｃｏｄｅ）をさがすことによって次のフレームへと進む。
【００１３】
第二の同期点は、Ｈ．２６１およびＨ．２６３ビデオビットストリームでのみ利用できるものである。Ｈ．２６１またはＨ．２６３を使ってエンコードされるビデオフレームはブロックグループ（ＧＯＢ：ｇｒｏｕｐ  ｏｆ  ｂｌｏｃｋｓ）に分割される。そのＧＯＢヘッダが同期点として使うことができる。誤りが検出されると、直前のＧＯＢヘッダから次のＧＯＢヘッダまでの映像部分が失われる。映像の残りの部分は無傷である。Ｈ．２６３ビデオビットストリームでのＧＯＢレベルの同期の場合、一つの問題は、Ｈ．２６３規格はエンコーダ側がＧＯＢヘッダを送ることを要求していないということである。ＧＯＢヘッダの送信は認められているものの、負荷を減らし、それによりデータレートを改善するために省略されるのがしばしばである。ＧＯＢレベルの同期がＨ．２６３できちんと動作するためには、エンコーダが少なくともいくつかのＧＯＢヘッダを送信することが必要である。Ｈ．２６１を使ってエンコードされたビデオは常にＧＯＢヘッダを含んでおり、ここに記載される技術は従来システムではうまく動作する。
【００１４】
第三の同期点でのマクロブロックレベルの同期もまた、Ｈ．２６１およびＨ．２６３でコーダでのみ利用できる。生のビットストリームからマクロブロックレベルでの同期をとるには簡単な方法はないが、ビットがパケットとして受信された場合には、パケットヘッダがマクロブロック情報についての情報を含んでいる。ただし、このパケットヘッダ内の情報は、レガシーシステムがパケットヘッダに正しい情報を与えていない可能性があるため、実際上は信頼できない。
【００１５】
第四の同期点はＨ．２６４ビットストリームのみで利用できるもので、ネットワーク適応層単位（ＮＡＬＵ：Ｎｅｔｗｏｒｋ  Ａｄａｐｔａｔｉｏｎ  Ｌａｙｅｒ  Ｕｎｉｔ）レベルの同期である。Ｈ．２６４ビットストリームでは、マクロブロックはＮＡＬＵで複数のグループにまとめられる。一つのフレームに属する各ＮＡＬＵはどのような順序で送ってもよい。これは、Ｈ．２６４デコーダがＮＡＬＵレベルでの同期ができることを要求する。ＧＯＢの場合と同様、ＮＡＬＵが失われても影響を受けるのは映像の一部だけである。
【００１６】
最も一般的に用いられる同期点はフレームの先頭である。他の同期ポイントを全く使わないと、誤りがフレームの先頭付近で検出された場合に、フレームのほとんど全体を修復する必要が生じることになる。よって、できるところでは追加的な同期点を用いるのがよい。マクロブロックレベルの再同期は信頼できないと考えられるので、Ｈ．２６１およびＨ．２６３システムにとっての最善の選択肢はＧＯＢレベルの再同期である。Ｈ．２６４についてはＮＡＬＵレベルの同期が好ましい。
【００１７】
いずれの場合でも、フレームを復号する前に、すべてのマクロブロックが「失われた」マクロブロックとしてマークされる。そのフレームの復号が進むにつれて、うまく復号できたマクロブロックは「失われた」マクロブロックから「良好」マクロブロックへと変更されていく。ここで、「マクロブロック」というのはデコーダ基準枠内でのピクセルの領域（表示上のある特定の領域に対応する）を指している。
【００１８】
誤りが起こったときにただちに検出されるかどうかは不確かなので、ビットストリームの誤りが検出されると、最後の同期点以後に復号された全マクロブロックも疑わしく、改めて「失われた」とマークするのがよい。このような状況で「失われた」とマークする必要のあるマクロブロックの数を減らす技法についてはのちに述べる。ひとたびフレーム全体が復号されると、「失われた」とマークされたままになっているマクロブロックをすべて再構築する必要がある。次の擬似コードは、イントラフレーム中のこれら「失われた」マクロブロックを再構築する方法を記述したものである。
【００１９】
Ｎ＝０；
ｄｏ
｛
ｉｆ（Ｎ番目のＭＢが「失われた」）
｛
ｓｅｔ  現ＭＢＩｎｆｏ＝直前のフレームのＮ番目のＭＢＩｎｆｏ
ｉｆ（（現ＭＢＩｎｆｏ−＞ＭＢＴｙｐｅがＩＮＴＥＲ）＆＆
（現ＭＢＩｎｆｏ−＞ＲｅｆｅｒｅｎｃｅＦｒａｍｅＮｕｍが最も最近のフレーム））
｛
ｓｅｔ  現ＭＢの動きベクトル＝直前のフレームのＮ番目のＭＢの動きベクトル；
ｓｅｔ  現ＭＢの係数＝係数なし；
ＭｏｔｉｏｎＣｏｍｐ（現ＭＢ）；
｝
ｅｌｓｅ  ／／ＭＢＴｙｐｅがＩＮＴＲＡであるか、予測フレームが最も最近のフレームでない場合
｛
直前のフレームからＭＢをコピー；
｝
｝
｝ｗｈｉｌｅ（＋＋Ｎ＜フレーム中のＭＢの総数）
この擬似コードによって実行される動作は次のようにまとめられる。このルーチンはあるフレームのマクロブロックを一つ一つ見ていく。あるマクロブロックが「失われた」であれば、そのマクロブロック情報（たとえば、そのマクロブロックがインター符号化されたのかイントラ符号化されたのか？、インター符号化だとしたら動きベクトルは？）は直前のフレームの対応するマクロブロックの値に設定される。（マクロブロックについてはコーデックにも別の情報が保持されているかもしれないが、これは本発明の関連では必要ではない。）もし現マクロブロックがインター符号化されたマクロブロックであり、参照フレームが最も最近のフレームであった場合、現マクロブロックの動きベクトルは直前のフレームの対応するマクロブロックのものに設定され、現マクロブロックの係数は０に設定される。次に、当該マクロブロックは動き補償アルゴリズムを使って再構築される。該ブロックは本質的には、直前のフレームから動き補償を延長することによって外挿される。
【００２０】
あるいはもし、現マクロブロックがイントラ符号化されているか、予測フレームが最も最近のフレームでない場合、マクロブロック全体は直前のフレームにおける対応するマクロブロックからコピーされる。このように、イントラ符号化フレームに対しては再構築は行われない。イントラフレームを復号中にビットストリーム誤りが検出されたときには、デコーダは表示を凍結して高速の更新を要求する。こうする理由は、イントラフレームが送られるのが通常の場合では次の三つのうちのいずれかの状況しかないことによる：（１）通話の開始時点において、（２）発信源が変わったとき、（３）エンコード解像度が変わったとき。デコーダは、有効な解像度と有効な参照フレームを確立するためにこのイントラフレームをもつことが必要である。
【００２１】
上述した再構築は「失われた」マクロブロックに対してかなりよくはたらく。しかし、デコーダによって使われる参照マクロブロックはエンコーダが当該ブロックをエンコードする際に参照フレームとして使ったものとは違っている。この相違は時間がたつとともに悪くなる。よって、再構築されたマクロブロックのイントラ更新が要求される。これは二つの方法で実現できる。一つの方法では、デコーダはエンコーダにフレーム全体の高速更新要求を送る。これは典型的なエンコーダには何の変更も要求しない。もう一つの方法では、再構築されたマクロブロックのイントラ更新が、エンコーダ上のイントラ遍歴を使って実装されうる。この機構についてのちに説明するが、これはエンコーダ側に若干の簡単な変更を要求する。
【００２２】
フレーム全体の高速更新は視覚的には乱れて見えるが、あらゆる既存のエンコーダで利用できる。エンコーダ側がイントラ遍歴を作動させられるかどうかに関わりなくデコーダが動作できるようにするため、以下の仕掛けを使って、エンコーダ側がイントラ遍歴に対応しておりイントラ遍歴が有効になっていれば全フレームのイントラ要求が送られないことを保証するようにすることができる。マクロブロックが「失われた」とマークされるとき、そのマクロブロックについて時刻が記録される。イントラモードでマクロブロックが更新されるときにはそのタイムスタンプは更新される。各フレームの終わりで全マクロブロックについてのタイムスタンプが検査される。いずれかのマクロブロックがＮ秒を超えて「失われた」とマークされていたら、全フレームの高速更新要求が遠方のエンコーダに送られる。もしエンコーダがイントラ遍歴を実装していたら、マクロブロックはそのＮ秒の期間の間に更新されていたはずであるから、全フレームの高速更新が要求されることはなくなる。
【００２３】
エンコーダ上でのイントラ遍歴のスピードは、もし実装されていれば、Ｎから導けるので、エンコーダが遍歴を実際に送るときにはデコーダは高速更新を要求しないはずである。Ｎは好ましくはエンコードされるビデオストリームの種類、すなわち解像度およびフレームレートを反映したものとする。たとえば、コンピュータプレゼンテーションを送信するのに使われるような高解像度、低フレームレートのビデオではＮの値は比較的高めであるのがよく、おそらくは２０秒のオーダーであろう。また、テレビ会議の参加者の動画を送信する際に使われるようなより低解像度でより高フレームレートのビデオについては、Ｎは比較的高めの値であるのがよく、１０秒程度のオーダーが好ましい。高速更新要求があまりたくさん送られないことを保証するため、最初の高速更新要求が送られるときにＭ秒期限のタイマーを始動させる。タイマーの期間内にはそれ以上は高速更新要求は送られない。Ｍはシステムパフォーマンスが最適となるよう調整するのがよく、値１０が最適な結果を与えるものと信じられている。
【００２４】
好ましい方法は、イントラ遍歴（または同等の更新プロセス）に対応したエンコーダを備えることである。イントラ遍歴とは、エンコーダがフレームあたり数マクロブロックを選んでイントラマクロブロックとして符号化されるようにする処理である。フレームごとに異なるマクロブロックが選ばれるので、ある期間にわたって見ると、フレーム内の全マクロブロックが少なくとも一度はイントラ符号化されることになる。その後もこの処理が継続的に繰り返される。この技術の基本的な概要は次のようなものである。
【００２５】
当該フレームの各マクロブロックを符号化するのに必要な期間をＴとする。するとフレームあたりイントラ符号化されるマクロブロックの数（Ｎｉｎｔｒａ）はＮｍｂ／（Ｆｒ＊Ｔ）となる。ここで、Ｎｍｂはフレームあたりのマクロブロックの総数、Ｆｒは所与のビットレートに対する名目フレームレートである。フレームレートはチューニングルーチンから動的に得ることもできるし、所与のビットレートについて固定値として定義することもできる。フレームレートが動的に計算される場合、そのフレームレートの値を変えるのはフレーム全体の遍歴が終わったあとでのみとすることが重要である。
【００２６】
例として、ＣＩＦ規格の３８４ｋｂｐｓでの通話の名目フレームレートは１５となる。（共通中間フォーマットＣＩＦはルミナンス・ピクセルで３５２×２８８の解像度に相当する。）遍歴期間Ｔは、イントラ遍歴についてのデコーダ側の期待に合わせて１０秒に設定する。すると、Ｎｉｎｔｒａ＝３９６／（１５＊１０）＝２．６４となる。小数点以下を切り上げると、フレームごとにイントラ符号化するべきマクロブロックの数は３となる。
【００２７】
Ｈ．２６４ではイントラ遍歴のマクロブロックは、参照フレームを使わないように符号化される。すなわち、これらのマクロブロックは、いかなるインター・マクロブロックもその予測の基本として使うことはできないということであり、したがってこれらのマクロブロックは制約されたイントラとして符号化する必要がある。Ｈ．２６４におけるイントラ遍歴の詳細については、Ｊｏｈｎ  Ｓｉｅｖｅｒｓによる“Ｉｍｐｒｏｖｅｄ  Ｉｎｔｒａ  Ｂｌｏｃｋ  Ｗａｌｋ  Ａｒｏｕｎｄ  Ｒｅｆｒｅｓｈ  ｆｏｒ  Ｈ．２６４”と題する米国特許出願第１０／７９９，８２９号において説明されており、その全体は参照によってここに組み込まれる。
【００２８】
デコーダの再同期を助けるエンコーダ側の別の改良は、フレームあたりいくつかのＧＯＢヘッダを送るというものである。上述したように、Ｈ．２６３においてはＧＯＢヘッダの送信は必須ではなく、多くのエンコーダは負荷を減らしてデータレートを改善するためにこれらのビットを消去している。ここで述べている改良の目的のためには、ＧＯＢヘッダを全部送る必要はない。ＩＰネットワークでは、ビットストリームの誤りはほとんど全部がパケット損失のためである。したがって、どのパケットについても最初の同期点があるだけで相当な恩恵になる。あるパケットが失われたときに、その後いずれかのパケットにおいてスキップされるビット数を最小にするため、同期点はパケットの先頭にできるだけ近いのがよい。どれか一つのパケット内に二つ以上のＧＯＢ開始点があるような場合、ＧＯＢヘッダにとって最善の場所は、これらのＧＯＢのうちの最初のものの先頭である。パケット境界はＧＯＢの境界に対応するとは限らない。
【００２９】
上述したように、ビットストリームの誤りがただちに検出されることは常に可能であるとは限らない。よって、誤りが検出されたときには、直前の同期点以後に受信された全マクロブロックは「失われた」ものと想定することが一般に望ましい。直前の同期点に立ち戻ることが、「不良」マクロブロックがしかるべき隠蔽を受けずに表示されるのを確実に防ぐ唯一の方法である。この方法は安全ではあるが、一部の良好なマクロブロックまで「失われた」とマークされてしまうためあまり効率的とは言えない。デコーダが誤りが起こった時点でただちに検出することができれば、復号できたマクロブロックはみな良好であると考えることができる。よって、デコーダは直前の同期点にまで引き返す必要がなくなり、ビットストリーム誤りによって引き起こされる影響はより限定的な範囲になる。（Ｈ．２６１およびＨ．２６３については、同期点はＧＯＢヘッダ、Ｈ．２６４については同期点はＮＡＬＵ境界である。）
Ｈ．３２０の通話においては、Ｈ．２６１／Ｈ．２６３ビットは５１２ビットのフレームとして送られる。各フレームは同期ビット、当該フレームが埋め草であるか本物のデータであるかを指示するフラグ、４９２ビットのデータ本体、誤り検出および誤り訂正のための１８ビットの符号からなる。末尾にこの１８ビットの符号を使っていることで、誤りはしばしば検出され、時には訂正までされる。この符号は時に間違って、誤りがないとか、誤りがすべて訂正されたと判断することもあるが、当該フレーム中に未訂正の誤りがあることがわかっていることもしばしばである。もしデータリンク符号が未訂正の誤りがあるとわかっているフレームを破棄したりそのまま先に伝えたりすれば、ビデオデコーダはすぐには誤りが発生したことに気づかないかもしれない。誤りに気づくまで、デコーダは参照フレームに更新を適用し続け、その過程で一般にはその参照フレームを劣化させてしまう。
【００３０】
デコーダとしては、明らかにおかしいビットを受信するほうが、その誤ったビットによって参照フレームを劣化させないようにできるのでずっと好都合である。この理由により、データリンク層は、フレーム内に未訂正誤りがあるとわかっているときには、そのフレームをビデオデコーダにも誤っているとわかるようなビット列で置き換えるのがよい。データリンク層のこの監視は、端末間に位置する、たとえばブリッジ、ゲートウェイ、多地点接続装置（ＭＣＵ）といったものを含むネットワーク構成要素のうちのいくつに設けてあってもよい。ビットストリームの誤りを発見するそのような装置はビデオエンコーダやデコーダのないネットワーク装置であることもあるので、前記データリンク符号はどのビデオエンコード規格が使われているかはわからなくてもいいようにしておくことが好ましい。よって、Ｈ．２６１、Ｈ．２６３、Ｈ．２６４について機能するような一つのビット列を有することが望ましい。
【００３１】
そのようなビット列の一つが図１に示されている。このビット列は少なくとも６３個の０（すなわち、０の繰り返しが６２回より多い）、次いで一つの１、そして２２個の０、次いで列１０１１１、次いで１０個の０、次いで一つの１を含んでいる。そのフレーム内の残りのビットは「擬似開始コード」を避けるためにみな１とするのがよい。それ以外のビットが各圧縮アルゴリズムでどのように解釈されるかについて次に述べる。
【００３２】
Ｈ．２６１ビットストリームについては、先頭にこれほどたくさんの０があることで、デコーダは、映像開始コードまたはＧＯＢ開始コードに遭遇することを期待しているのでない限り、確実に誤りを検出する。最初の４８個の０が過ぎたあと、デコーダは少なくとも１５個のさらなる０と、一つの１、そして四つの０に遭遇するが、これは映像開始コードをなす。次の１２個の０は映像ヘッダの残りと解釈される。（ＰＴＹＰＥの最後のビットは１であるべきなのだが、大昔に間違ったビットを送っていたコーデックがあったため、そのビットをチェックしないデコーダもある。）この時点で、デコーダはＧＯＢ開始コードをみつけることを期待している。これは１５個の０と一つの１からなる。だがその代わりに１の前に０は六つしかなく、コーデックはもう一つの誤りを検出することになる。デコーダは２２個の０を使って同期をさがす。最初の７ビットをスキップしたのち、ＧＯＢ開始コードをなす１５個の０と一つの１をみつける。次いで遭遇する０１１１は、ＧＯＢの数が７であることを示している。このあとには５ビットのＧＱＵＡＮＴ値がくる。ＧＱＵＡＮＴが０なのは不正なので、デコーダはまた誤りを検出する。ここにはこれ以上もう映像開始コードまたはＧＯＢ開始コードと間違われるほど長い０の列はない。
【００３３】
Ｈ．２６３では、先頭にこれほどたくさんの０があることで、デコーダは、映像開始コードまたはＧＯＢ開始コードまたはスライス開始コードに遭遇することを期待しているのでない限り、確実に誤りを検出する。最初の４７個の０が過ぎたあと、デコーダは１６個の０と、一つの１、そして五つの０に遭遇するが、これは映像開始コードをなす。このあとの９番目のビットは１であると期待されているが、デコーダは０に遭遇するので、誤りを検出する。デコーダは２２個の０を使って同期をさがす。最初の６ビットをスキップしたのち、ＧＯＢ開始コードまたはスライス開始コードをなす１６個の０と一つの１をみつける。次の０１１１０という５ビットは、ＧＯＢの数が１４であることを示している。次の４ビットはＧＯＢサブビットストリーム指示子（ＧＳＢＩ：ＧＯＢ  Ｓｕｂ−ｂｉｔｓｔｒｅａｍ  Ｉｎｄｉｃａｔｏｒ）およびＧＯＢフレームＩＤ（ＧＦＩＤ：ＧＯＢ  Ｆｒａｍｅ  ＩＤ）に使われる。それに続くのは５ビットのＧＱＵＡＮＴ値である。値０は不正なので、デコーダはまた誤りを検出する。ここにはこれ以上もう映像開始コードまたはスライス開始コードまたはＧＯＢ開始コードと間違われるほど長い０の列はない。
【００３４】
最後に、Ｈ．２６４エンコーダを使うと、最初の３２ビットのあと、このビット列は３１個の０と一つの１がくるが、これは同期コードである。デコーダはこの同期コードが期待されていた配列に合わなければ誤りを検出する。いずれにせよ、デコーダはこの同期コードに従って配列の期待値を設定する。デコーダは次いで三つのバイト０、０、２（２２個の０ビット、一つの１、一つの０）に遭遇するが、これは不正なビット列である。デコーダはこのビットストリーム内ではこれ以上の同期コードには遭遇しない。
【００３５】
Ｈ．３２３のビデオ通話においては、各パケットは通し番号を含んでいる。これらの通し番号を使って、失われたパケットがあるかどうかを判断することができる。各Ｈ．２６４ＮＡＬＵは一つのパケットに納まり、十分なコンテキスト情報も含んでいるので、ビデオデコーダに欠失パケットについて伝えてやる必要はない。Ｈ．２６１およびＨ．２６３の場合は、ビデオデコーダが次のパケットのビットの解釈を誤らないよう、欠けているパケットまたはパケット列を無効なビット列で置き換えることが望ましい。パケットヘッダがどの圧縮アルゴリズムが使われているかを示しているので、全部のアルゴリズムで無効になるビット列を使う必要はない（そのようなビット列を使うことも可能ではあるが）。一般に、使われている圧縮アルゴリズム専用のビット列を使うことが好ましい。好適なビット列のいくつかの例を次に記す。
【００３６】
Ｈ．２６１で使うのに好適なそのような無効ビット列の一つを図２に示している。これは１６個の０、次いでビット列１００１１、次いで５個の０、そして最後に１で閉じる。これはＧＮ＝３でＧＱＵＡＮＴ＝０のＧＯＢヘッダと解釈される。ＧＱＵＡＮＴの値は０は認められないので、誤りが検出される。ビット列が１で終わっているのは、これらのビットと後続の何らかのビットの組み合わせで擬似開始コードが生じるのを防ぐためである。
【００３７】
Ｈ．２６３で使うのに好適なそのようなもう一つのビット列を図３に示している。これは１７個の０、次いでビット列１００１１、次いで１０個の０、一個の１からなる。これはＧＮ＝６、ＧＳＢＩ＝０、ＧＦＩＤ＝０、ＧＱＵＡＮＴ＝０のＧＯＢヘッダと解釈される。ＧＱＵＡＮＴの値は０は認められないので、誤りが検出される。ビット列が１で終わっているのは、これらのビットと後続の何らかのビットの組み合わせで擬似開始コードが生じるのを防ぐためである。このビット列はＨ．２６１にも使えることを注意しておく。
【００３８】
本発明はここでは代表例としての実施形態を参照しつつ説明されてきた。当業者には、より広い本発明の精神および範囲から外れることなくさまざまな修正がなしうることが明らかであろう。さらに、本発明は特定の環境における、特定の応用分野のための実装との関連で記述されてきたが、本発明の有用性がそれに限られるものではなく、本発明が多くの環境および実装において有益に用いうることは当業者なら認識することであろう。以上の説明および図面はしたがって、限定的な意味ではなく、解説のためのものと見なされるべきである。
【図面の簡単な説明】
【００３９】
【図１】Ｈ．３２０ビデオ通話において使う汎用誤りビット列を示す図である。
【図２】Ｈ．２６１コーデックを使ったＨ．３２０ビデオ通話において使う誤りビット列を示す図である。
【図３】Ｈ．２６３コーデックを使ったＨ．３２０ビデオ通話において使う誤りビット列を示す図である。
【図１】
2006060813.tif 000003
【図２】
2006060813.tif 000004
【図３】
2006060813.tif 000005