JP2001103475A

JP2001103475A - 可逆可変長コードを使用するエラーに強いビデオコーディング

Info

Publication number: JP2001103475A
Application number: JP2000234898A
Authority: JP
Inventors: Yuji Ito; 裕二伊藤
Original assignee: Texas Instruments Inc
Current assignee: Texas Instruments Inc
Priority date: 1999-08-02
Filing date: 2000-08-02
Publication date: 2001-04-13
Also published as: EP1075148A3; EP1075148A2; KR20010030046A

Abstract

(57)【要約】【課題】ＭＰＥＧのような動き補償圧縮ビデオにおける
エラーの問題を軽減する。【解決手段】付加的コードがインターリーブされた可逆
粗製コードによってエンコードされた動きベクトルによ
る、動き補償されたビデオのエンコーディング及びデコ
ーディングであり、粗製コードはコードワードの偶数ビ
ットを占め、付加的コードはコードワードの奇数ビット
を占める。好ましい実施の形態は、テクスチャデータか
ら区切られた動きベクトルデータを含み、それは、直前
の動きベクトルを予測子として使用することによって差
分的にエンコードされた動きベクトルを伴う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本出願は、ノイズのあるチャ
ンネル及びストーレジを介して送信するための情報エン
コーディングに関し、特に、エラーに強いエンコーディ
ングに関する。ノイズのあるチャンネルを介してデータ
を送信するときに生じるエラーを緩和する２つの一般的
方法がある。自動再送要求（ＡＲＱ）と前方向エラー訂
正（ＦＥＣ）である。ＡＲＱ型の緩和は、大きな遅延と
フィードバックチャンネルの欠如によって、ビデオのよ
うなマルチキャストあるいはリアルタイムアプリケーシ
ョンには適さない。そのような場合、デコーダができる
ことは、ある程度エラー訂正エンコーディングによって
保護されてはいるが、エラーによって崩壊したビットス
トリームをデコードするだけで、そのようなビットスト
リームから生成しなければならない。ＦＥＣは、エラー
訂正コード（例えば、リードソロモン）による緩和を提
供する。しかしながら、訂正不可能エラーは、更なる緩
和を要求する。

【発明が解決しようとする課題】一般に、ふつう使用さ
れているビデオ圧縮方法は、時間冗長を除去するブロッ
ク基準動き補償を有する。動き補償方法は、（マクロ）
ブロック動きベクトルと対応の量子化された残余（テク
スチャ）だけをエンコードし、動きベクトルと残余の可
変長コーディング（ＶＬＣ）は、コーディング効率を上
げる。しかし、可変長コーディングは、送信チャンネル
エラーに非常に敏感であり、訂正不可能エラーが生じる
と、デコーダは、エンコーダとの同期を簡単に失ってし
まう。動き補償のような、予測コーディング方法では、
更に事態が悪化する。なぜなら、ビデオフレーム内のエ
ラーは一連のビデオ全体に素早く伝わり、デコードされ
たビデオの品質を急速に劣化させる。訂正不可能エラー
にそのようなブロック基準ビデオ圧縮方法を適用する典
型的アプローチは、エラー訂正ステップ（例えば範囲外
動きベクトル、無効ＶＬＣ表エントリ、あるいはブロッ
ク内の残余の無効数）と、デコーダとエンコーダとの再
同期ステップと、訂正不可能データの代わりに以前に送
信された正しいデータを反復させることによってエラー
を隠匿するステップとを備える。例えば、ＭＰＥＧ１−
２を使用して圧縮されたビデオは、フレームのマクロブ
ロック（ＭＢ）の各スライスの頭に再同期マーカー（開
始コード）そ有して、訂正不可能エラーは、正しくデコ
ードされた再同期マーカーのすべてのデータに生じ、破
棄される。これは、ビデオストリームの質の低下を意味
し、特にＭＰＥＧのような予測圧縮方法にとっては手痛
い。

【０００２】圧縮されたビデオは、典型的には、ハフマ
ンコードのような可変長コード（ＶＬＣ）表を使用して
コード化される。圧縮されたビデオデータがノイズのあ
る通信チャンネルを介して送信されると、チャンエルエ
ラーにより崩壊する。ＶＬＣ表は、ビットエラーに特に
敏感であることがわかる。というのは、ビットエラーに
より、１つのコードワードが、異なる長さの別のコード
として間違って解釈されて、エラーが検出されないから
である。これにより、デコーダはエンコーダとの同期を
失う。エラーは、最後には、無効ＶＬＣ表エントリによ
って検出されるが、ふつう、エラーが検出されるビット
ストリーム内の位置は、エラーが生じた位置と同じでは
ない。従って、デコーダがエラーを検出した場合、次の
再同期マーカーを捜して、これと、前の再同期マーカー
との間のすべてのデータを破棄しなければならない。こ
のように、たった１つのビットエラーが、時には、かな
りの量のデータ損失を招き、これが公知のコーディング
方式の問題となっている。ゴロムライスコード（S. W.
Golomb, “Run-length encodings,” IEEE Trans. Inf.
Theory, vol. IT-12, 399-401ページ, 1966年 7月、及
びR.F. Rice, “some practical universal noiseless
coding techniques, “Tech. Rep. JPL-79-22, Jet Pro
pulsion Laboratory, パサディナ, カリフォルニア、19
79年 3月）が、無損失画像圧縮に適用されてきた。M.
J. Weinberger, G. Seroussi, G. Sapiro, “LOCO-1:
A low complexity, context based lossless image com
pression algorithm,” Proc 1996 IEEE Data Comp. Co
nf., スノーバード、ユタ、140-149ページ、1996年 4月
を参照。これらのビデオ圧縮及び復圧縮方法は、特別な
集積回路またはプログラム可能デジタル信号プロセッサ
又はマイクロプロセッサで実現することができる。

【０００３】

【課題を解決するための手段】本発明は、動きベクトル
をエンコードするのに可逆可変長コード（ＲＶＬＣ）を
使用することによって、ＭＰＥＧのような動き補償圧縮
ビデオにおけるエラーの問題を軽減する。これらのＲＶ
ＬＣは、粗製コード（値の範囲を示す）と付加的ビット
（値の範囲を伴う値を示す）がインターリーブされた構
造を持ち、粗製コードは可逆性を提供する。好ましい実
施の形態によれば、データパケット内マクロブロック用
の動きベクトルデータとテクスチャ（残余）データとの
間の再同期ワードとはデータが仕切りされ、これによ
り、直前の動きベクトルを予測子として使用することに
よって簡単な差分動きベクトルエンコーディングを行う
ことができる。これは、より良好な性能という利点を有
する。

【０００４】

【実施例】データ仕切り法ＭＰＥＧのような動き補償圧縮のための高いエラー隠匿
特性は、データ仕切りを使用することによって達成でき
る。２つの連続する再同期マーカーの間のデータから成
る「ビデオパケット」を考える。データ仕切りアプロー
チにおいては、各ビデオパケット内の動きデータとテク
スチャ（ＤＣＴ）データが、ビットストリームにおい
て、別々にエンコードされる。別の再同期ワード（動き
再同期ワード）が動きデータとＤＣＴＤデータとの間に
埋め込まれて、動きデータの終了とＤＣＴデータの開始
を示す。このデータ仕切りにより、デコーダは、ＤＣＴ
データが検出不可能エラーによって崩壊していても、動
きデータを使用することができる。これは、圧縮ビデオ
データのパケット内の訂正不能エラーを、わずかの付加
的オーバヘッドにより、部分的に回復することができる
という利点を提供する。デコードされた動きベクトルを
適用することによって動き補償の使用によって可能とな
るエラー隠匿は、デコードされたビデオの質をずっと良
好にする。これは、対象基準圧縮にも及び、対象形状デ
ータは、形状再同期ワードによって動きデータとテクス
チャデータから区別することができる。

【０００５】データ仕切りを使用する場合、ビデオパケ
ット内のデータは、図６a-cに示されたように組織され
る。図６aは、２つの再同期マーカーの間の領域を示
し、図６b, cは、動きデータ領域とテクスチャデータ領
域を、例として、詳しく示す。特に、第１領域（”Resy
nch Marker”）は、再同期マーカーであり、第２領
域（”MB No.”）は、第１マクロブロック（１６ｘ１６
ブロックの画素）のフレーム内の番号であり、第３領域
（”QP”）は、ビデオパケット内のテクスチャデータ
（ＤＣＴ係数）を量子化するのに使用されるデフォルト
量子化パラメータであり、第４領域（”Motion Dat
a”）は、動きデータであり、第５領域（”Motion Resy
nch Word”）は、動きデータとテクスチャデータとの間
の再同期マーカーであり、第６領域（”DCT Data”）
は、テクスチャデータであり、最後の領域（”Resynch
Marker”）は、終端再同期マーカーである。尚、再同期
マーカーは、２３個の連続する０を有して、これらの再
同期ワードは、１９９８年２月６日に同時出願の米国特
許第０９/０１９，７８７号に記載されている検索プロ
セスによって生成することができる。

【０００６】図６bは、パケット内の各マクロブロック
に対する、ＣＯＤ領域と、ＭＣＢＰＣ領域と、ＭＶ領域
とから成る動きデータ領域を示す。ＣＯＤ領域は、マク
ロブロックがコード化されているかスキップされたかを
示す（ＣＯＤ＝０マクロブロックはコード化され、ＣＯ
Ｄ＝１マクロブロックはスキップされる）。ＭＣＢＰＣ
領域は、（１）マクロブロックのモードと、（２）マク
ロブロック内のどの色光度がコード化され、どれがスキ
ップされるかを示す。モードは、現在のマクロブロック
がＩＮＴＲＡ（動き補償なし）、ＩＮＴＥＲ（１つの１
６ｘ１６動きベクトルで動き補償される）、ＩＮＴＥＲ
４Ｖ（４つの８ｘ８動きベクトルで動き補償される）の
どれでコード化されるかを示す。もちろん、もし、マク
ロブロックがコード化されないことをＣＯＤが示せば、
ＭＣＢＰＣ領域は存在しない。ＭＶ領域は、実際の動き
ベクトルデータであり、ベクトルは１つか４つである。
この場合も、マクロブロックがコード化されないことを
ＣＯＤが示せば、ＭＶ領域は存在しない。図６cは、各
マクロブロックに対する、ＣＢＰＹ領域とＤＱＵＡＮＴ
領域とから成るテクスチャ（ＤＣＴデータ）領域の後
に、各マクロブロックに対するＤＣＴデータが続く様子
を示す。ＣＢＰＹ領域は、マクロブロックのうちどの輝
度ブロックがコード化され、どれがスキップされるかを
示す。ＤＱＵＡＮＴ領域は、マクロブロックに対する量
子化値を計算スルタメノデフォルト量子化器値（ＱＰ）
に対する差分インクリメントを示す。ＤＣＴ領域は、マ
クロブロックのラン長さエンコードされた量子化ＤＣＴ
係数値である。

【０００７】ヘッダを伴う可逆ＶＬＣ図７は、好ましい実施の形態による、ヘッダとＲＶＬＣ
を使うデータとを備えたビデオパケット内のビットスト
リームのシンタクスである。Resynch Marker,MB No., Q
P, Motion Resynchr Word領域は、図６aと同じである。
Motion VectorData領域は、図６bと同様に、動きベクト
ルデータＭＶ１，ＭＶ２，．．．ＭＶｎから成り、DCT
Header Data領域は、図６cのＣＢＰＹ１，ＤＱＵＡＮＴ
１，．．．ＣＢＰＹn, ＤＱＵＡＮＴnから成り、DCT Da
ta領域は、図６cのＤＣＴ１，ＤＣＴ２，．．．，ＤＣ
Ｔnから成る。Header Data領域は、各マクロブロックに
対する組み合わされたＣＯＤとＭＣＢＰＣデータ用の１
つのＲＶＬＣエントリから成り（図６bを参照）、Heade
r Resynchronization Wordは、Motion Resynchronizati
on Wordと同様な、一義的にデコードされりワードであ
る。このように、ＲＶＬＣエントリの連なりが、Header
Data, Motion Vector Data, DCT Header Data, DCT Da
ta領域に生じる。もちろん、各領域は、以下に詳細に述
べるように、それ自身のＲＶＬＣ表を持っている。ＲＶ
ＬＣのいずれかをデコードしている間にエラーがデコー
ダによって検出されると、デコーダは次の再同期ワード
を探す（Header Resync. Word又はMotionResync. Word
又はResync. Marker）。そして、ＲＶＬＣデータを逆向
きにデコードする。ここで、以下に示される４つの可能
性のあるケースの１つが生じ、デコーダは、以下の図で
ハッチを入れて示されたビットストリームの適当な部分
を破棄することにする。尚、逆向きデコーディングの
際、有効データであるかどうかの通常のチェックに加え
て、もし、前方向デコードされ且つ後方向デコードされ
たデータが、両方向デコードが明らかなエラーなしに行
われたにもかかわらず、一致しない場合は、デコーダは
ビットストリームにフラグを立てる。

【０００８】１）別々のエラーが検出された点：デー
タがエラーなしのＭＢが使用される。前方向デコード及
び後方向デコードにおけるエラー検出点の間のデータが
破棄される（図１のハッチ部分）。２）交差エラー検出点：データがエラーなしのＭＢが
使用される。前方向デコード及び後方向デコードにおけ
るエラー検出点の間のデータが破棄される（図２のハッ
チ部分）。３）エラーが１方向で検出される：データが崩壊して
いるＭＢが破棄される（図３のハッチ部分）。前方向で
エラーがなく、逆方向でエラーがある場合も、同様に扱
われる。４）同じＭＢ内でエラーが検出される：崩壊したＭＢ
だけが破棄される（図４のハッチ部分）。ＲＶＬＣと逆
向き（後方向）デコーディングを使用する上記すべての
場合において、デコーダは、エラーにないビットストリ
ームの大部分を救うことができる。

【０００９】ＲＶＬＣの設計好ましい実施の形態によるパラメタ化ＲＶＬＣは、画像
データのコード化において生じる確立密度関数（pdfs）
用近似最適として知られる公知の非可逆ＶＬＣと同様の
コード長分布を有する。前記ＲＶＬＣはパラメタ化され
て、広範囲のpdfsに適合するようになり、従来の（非可
逆）可変長コードの効率を保持したままで、２方向デコ
ーディングの利点を得ることができる。まず、ゴロムラ
イス(Golomb-Rice)コードとしての同じ長さの分布を備
えた可逆コードは、最近、背景の項で述べたように、無
損失画像コーディングアプリケーションにおける予測エ
ラーのコーディングに適用されてきた。ゴロムライスコ
ードは、指数関数的に分布する非負の整数のコーディン
グ用に近似的に最適であり、整数nを、商と剰余として
記述する。簡単に言えば、除数はたいてい２のべき乗、
即ち、２^kであり、kによってパラメタ化される。商は、
任意の大きさで、単項で表される。剰余は、[0,2^k-1]の
範囲で束縛され、kビットを使用する２進形式で表され
る。例えば、k＝２のゴロムライスコードでは、数９
は、110 01として表される。コードワードの「プレフィ
ックス」１１０は、９/２²の商を値２を持つものとす
る。「サフィックス」０１は、剰余の２ビット２進数で
ある。以下の表２は、パラメータkの２つの選択用の最
初の数個の整数のためのゴロムリアスコードを示す。

【００１０】等しい長さの可逆コードを得るには、単
に、各ゴロムライスコードワードのプレフィックスを、
１つの“１”で始まり１つの“１”で終わり、その他の
すべてのビットが“０”であるプレフィックスで置換す
ればよい。例外は、プレフィックスの長さが１である場
合であり、その場合は、“０”に設定される。ＲＶＬＣ
におけるサフィックスは、対応のボロムライスコードに
おけるサフィックスと同じである。これらの規則に従っ
て構成されたＲＶＬＣは、表１において、k=1及び k=2
の時のものが示されており、表から明らかなように、Ｒ
ＶＬＣと対応のゴロムライスコードの長さ分布は等し
い。コードワード全体に対して、対称的であるのはプレ
フィックスだけであるが、これらのコードは、簡単に、
双方向でデコードすることができる。なぜなら、コード
ワードの非可逆部分は固定長だからである。

【００１１】各長さ当たりのコードワードの数が一定で
あるゴロムライスコードに対して、所与の長さ当たりの
コードワードの数が、長さと共に指数関数的に増加する
コードを構成することも可能である。そのようなコード
を使用するラン長さの圧縮は、Teuholaの論文(J. Teuho
la, “A compression method for clustered bit-vecto
rs,” Information Processing Letters, vol. pp308-3
11ページ、１９７８年１０月)に記載され、そこでは、
「指数関数的ゴロム」コーディングという用語が使用さ
れ得ている。指数関数的ゴロムコードは、典型的指数関
数的pdfsよりピークが高くテールが広いpdfsに適合す
る。そのような pdfは、量子化された画像変換において
生じるラン長さがコード化されたデータに非常に良く適
合する。指数関数的ゴロムは、コードワードのサフィッ
クス内のビット数kに従ってパラメタ化することができ
る。表２は、k=1,2のときの指数関数的ゴロムコードを
示す。間接的にではあるが、指数関数的ゴロムコードと
同じ長さ分布を持つ可逆コードを構成することが可能で
ある。これをするには、やはり、プレフィクスの最初と
最後のビットは“１”であるという条件が必要である。
前記と同様に、長さ１のプレフィックスは“０”に設定
される。最初と最後のビットを除いて、プレフィックス
内のすべての奇数番目のビットは“０”でなければなら
ない。例えば、長さ５のすべてのプレフィックスにおい
て、第３ビットは“０”であり、第１と第５ビットは
“１”である。偶数番目のビットは任意に変えることが
でき、奇数ｌの長さのプレフィックス２^(l-1)/2が可能
である。コードを構成する際、各プレフィックスは、長
さｋの明示的サフィックス２^kと連結される。表２は、
これらの規則に従って構成されたＲＶＬＣを示す。ま
た、明らかなように、ＲＶＬＣの長さ分布は、対応の可
逆コードの長さ分布と同様である。

【００１２】

【００１３】

【００１４】完全なコードワード票の設計は、以下のよ
うに行う。１．最もふつうに生じるイベントの確率表を作る。２．各ｋについて、対応のＲＶＬＣ表からのコードワ
ードをイベントに割り当て、高い確率のイベントに短い
コードワードをマップする。次に、最短平均長さである
ｋを選択する。この方法を使用して、（１）ヘッダデータ（ＣＯＤ＋Ｍ
ＣＢＰＣ）（ＩＮＴＲＡ，ＩＮＴＥＲフレームの両方に
対して）、（２）動きベクトルデータ、（３）ＩＮＴＲ
ＡフレームＤＣＴデータ、（４）ＩＮＴＥＲフレームＤ
ＣＴデータのそれぞれに対して、ＲＶＬＣが設計され
た。２つのクラスのＲＶＬＣを使用する。第１クラスの
ＲＶＬＣは、ヘッダ情報（ＣＯＤ＋ＭＣＢＰＣ）をコー
ド化するのに使用される。１つのＲＶＬＣはＩＮＴＲＡ
フレームに使用され、１つがＩＮＴＥＲフレームに使用
される。これらｈ、下の表３及び表４に示される。

【００１５】

【００１６】

【００１７】第２クラスのＲＶＬＣは、パラメータkに
よってパラメタ化することができ、量子化されたＤＣＴ
係数のエントロピコーディング、及び、動きベクトルデ
ータのコーディングに使用される。表７は、ＤＣＴ係数
に対してk=1及び k=2のときに最もふつうに生じるイベ
ントと、コードワードを示す。表中、最終ビット“s”
は、レベルの符号を示し、”０“は正、”１“は負であ
る。残りのイベントは、図５に示されたように、固定長
コード（ＦＬＣ）でコード化される。

【００１８】

【００１９】

【００２０】

【００２１】前記好ましい実施の形態が使用した好まし
い実施の形態のＲＶＬＣは、好ましい実施の形態のシン
タクス内にあり、そこにおいて、動きデータは、ヘッダ
データと動きベクトルデータとの仕切られ、Header Res
ynchronization Wordによって分けられている。好まし
い実施の形態のＲＶＬＣは、図６cのＤＣＴデータ（Ｄ
ＣＴ１，ＤＣＴ２，．．．ＤＣＴn）用の表７のコード
を使用することによって、図６aにおけるようなデータ
仕切りを伴って使用することもできる。更に、ＲＶＬＣ
は、ＣＢＰＹプラスＤＱＵＡＮＴ領域をコード化するの
に使用することができる。別の実施の形態は、分離され
たヘッダデータとヘッダ再同期ワードを使用することな
しに、表８のＲＶＬＣを、動きベクトルデータのために
使用する。最後に、その他の再同期マーカー用に、他の
ＲＶＬＣを類似の方法で作ることができる。例えば、以
下の表９乃至１１は、前記表４及び７及び８の他のバー
ジョンである。

【００２２】

【００２３】

【００２４】

【００２５】対象物基準圧縮前記ＲＶＬＣ及びビットストリームシンタクスは、領域
（典型的には、動きデータの前にある）に対象物形状デ
ータを含むだけで、また、所望すれば、形状データを動
きデータから分離する Shape Resynchronization Word
を伴って、対象物基準圧縮に拡張することができる。更なる好ましい実施の形態更なる好ましい実施の形態は、テクスチャデータから分
離されたより重要な動きベクトルデータを伴う可逆可変
長コードを使用し、動きベクトル予測子の現在の状態
（動きベクトル予測子状態と呼ばれる）を運ぶ新規シン
タクスエレメントを加える。これは、前方向デコーディ
ング及び後方向デコーディングにとって、動きベクトル
が正しくデコードされたかどうかを確認するのに役立
つ。動きベクトル予測子状態エレメントの数は、チャン
ネル条件に依存し、エラーレートが高くなると、それだ
け多くのエレメントが使用される。特に、２つのタピプ
のビデオパケットがある。Ｉ−ＶＯＰ用のintraビデオ
パケットと、非intraＶＯＰ用のinterビデオパケットで
ある。図８は、非intraＶＯＰにおけるinterビデオパケ
ットの構造を示す。尚、intraビデオパケットのコーデ
ィングは、ＭＰＥＧ−４ＶＭ７．０と同じでよい。各パ
ケットの頭の圧縮データにパケットヘッダが挿入され
る。パケットヘッダは、一義的１７ビット再同期マーカ
ー（図８における”Resync. Marker”で、0000 0000 00
00 0000 1でよい）から成り、その後に、現在のマクロ
ブロック番号（”MB No.”であり、ＶＯＰ内のマクロブ
ロックの数は最大で２^N）を示すＮビットと、量子化パ
ラメータ（”QP”）用５ビットと、ヘッダ拡張コードが
続く。動きデータ及びテクスチャヘッダ以外のすべての
シンタクスエレメントは、ＶＭ７．０におけるのと同じ
でよい。

【００２６】図９は、動きデータ領域の構造を示し、図
１０は、動きベクトル用の可変長コードのアセンブリを
示し、そこでは、”motion_type_flag”が１６ｘ１６マ
クロブロック動き補償を、８ｘ８ブロック動き補償から
区別している。可逆デコーディングを可能にするため
に、ビデオパケット内の最後のマクロブロックは、”sk
ipped macroblock”としてはコード化されない。表１２
は、mv_vlcコーディングを示す。元々、各mv_vlcは、２
つの部分、粗製コードと付加コードとから成る。粗製コ
ードは、偶数番目ビットに現れ、“０”、“１１”、
“１０１”のように可逆であり、一方、付加コードは、
奇数番号のビットの連なりである。このようにして、mv
_vlcは、一義的に構成することができる。また、ＶＬＣ
のデコードの方向がどちらであっても、偶数番目のビッ
ト内の粗製コードを探すことによってコード境界を捜す
ことができる。好ましい実施の形態において、粗製コー
ドは２方向デコーディングを可能にするマーカーである
だけでなく、ラフな情報、即ち、ＶＬＣによって表現さ
れるべき値の範囲を担持する意味のあるコードでもあ
る。

【００２７】動きベクトルコーディングのシンタクス
は、以下のとおりである。ここにおいて、mv_vlc（水平）及びmv_vlc（垂直）は、
表１２から取られ、１乃至２７ビット持つことができ、
motion_type_flagは、図１０に示されたように、１ビッ
トである。動きデータのシンタクスは、以下のとおりである。ここ
において、最初のMB_Incは実施にはMB-Inc+1であり、MV
s_Motion typeは、図１０におけると同様に、１６ｘ１
６動き補償と８ｘ８動き補償との間の区別をし、MB_Inc
は１乃至１３ビット有し、motion_markerは、”1100 00
00 0000 00001”の１７ビットである。MB_Incは、ＶＭ
７．０で使用されるＣＯＤの代わりをする。MB-Incは、
以前にコード化されたマクロブロックから、いくつのマ
クロブロックがスキップされるか、すなわち、インクリ
メントされるかを示す。表１３は、MB_Inc ＶＬＣコー
ドを示す。尚、パケット内のMV_Inc（”first_MB_Inc”
として区別されている）は、パケット内のどのマクロブ
ロックが最初にコード化されるかを示す。first_MB_Inc
は、表１３についてもコード化されるので、その値は、
以前にコード化されたマクロブロックがパケット内の m
acroblock_numberによって指定されるもの(MB_N0.)に対
応するという仮定の上で、実際のインクリメントプラス
１を意味する。

【００２８】エラーが広がるのを防止するために、１次
元動き予測が使用される。”MV predictor status”
は、ＭＶ予測子の水平及び垂直成分の値を表す。ＭＶ予
測子状態は、先行するMB_Inc=“000”によって知らされ
るＶＬＣを使用して１６ｘ１６動き補償モードとしてコ
ード化される。イベント即ちMB_Inc=“000”の直前のマ
クロブロックのＭＶ予測子においてその値がコード化さ
れる。motion_markerの直前の少なくとも１つのＭＶ状
態が、両方向におけるデコーディングを可能とするため
に挿入されなければならず、ＭＶ予測子は、必要なだけ
置かれて、エラーに対する耐性を高める。図１１は、動
きベクトルの予測コーディングのための規則を示す。各
水平及び垂直成分に対してＭＶ予測子が１つだけ使用さ
れる。ＭＶ予測子は、スキップされるマクロブロックと
してリセットされることはない。１６ｘ１６動き補償の
ＭＶは、エラー隠匿のために、intraマクロブロックの
ためにもコード化される。このＭＶは、テクスチャデー
タがデコードできない場合に、動き補償信号を得るため
に使用される。動きベクトル差異ＭＶＤ（０，０）が、
このモードのために、コア実験でコード化される。

【００２９】macroblock_type(MB_type)用シンタクスは
以下のとおりである。ここにおいて、ＭＣＢＰＣは、表１４における１乃至８
ビットを有し、ＣＢＰＹひゃＶＭ７．０におけると同様
に２乃至６ビット有し、dquantは、ＶＭ７．０における
と同様に２ビット有する。以下のエラー条件下でのデコ
ーディング動作のために、デコーダは次の再同期点、re
synch marker又はcommon state code （即ち、２３ビッ
トの“０”＋“１”）のいずれかで、ビットストリーム
において先に出会う方において再同期する。（１）違法ＶＬＣが受信される。（２）１つのブロックで、６４個以上のＤＣＴ係数が
デコードされる。（３）一貫性のないヘッダ情報（即ち、範囲外のＱ
Ｐ，範囲外のMB_numberなど）（４） resynch marker又はVOP状態コードが崩壊して
いる。（５）現在のパケット内のマクロブロックをデコード
している間にエラーが検出されないが、デコーダによっ
て保持される現在のマクロブロックカウントが現在のパ
ケットヘッダのＮＭＢと適合しない。（ＮＭＢは、ビデ
オパケット内のマクロブロックの数を示し、現在のビデ
オパケットと次のビデオパケットとの間のマクロブロッ
ク番号（MB No.）内の差異として計算される。

【００３０】後続のパケットが再同期の前に失われた場
合は、それらのパケットは、スキップされたマクロブロ
ックによって置きかえられる。エラーがテクスチャデー
タ部で検出され（且つ動き部ではエラーが検出されな
い）場合、ＮＭＢ動きベクトルを使用して動き補償を行
う。そのパケット内のすべてのマクロブロックのテクス
チャ部分は破棄され、デコーダは、次のresync marker
に再同期する。ビットストリームの動き部でもテクスチ
ャ部でもエラーが検出されないが、現在のパケットのす
べてのマクロブロックをデコードした後で再同期マーカ
ーが見つからない場合、エラーのフラグを立てて、現在
パケット内のすべてのマクロブロックのテクスチャ部だ
けが破棄される。その場合も、ＮＭＢマクロブロックに
対しては、補償が適用される。MBA[k]が現在のパケット
内の第１マクロブロックの番号を示し、MBA[k+1]が次の
パケット内の第１マクロブロックの番号を示すとする。
パケットの動き部でもテクスチャ部でもエラーが検出さ
れない場合、付加的チェックが行われ、次の再同期マー
カーが正しく見つけられる。この場合、MBA[k+1]-MBA
[k]がＮＭＢに等しいかどうかチェックする。等しくな
ければ、次のビデオパケット（MBA[k+1]に対応するパケ
ット）内のデータを破棄する。従来のデータ仕切りで
は、動きデータ部内でエラーが検出されると、デコーダ
はパケット全体を破棄し、次に正しく読まれた resync
marker又は VOP開始コードに再同期する。一方、ここに
提案される方法のデコーダは、以下のセクションで記載
されるようにＭＶ回復を行い、回復されたＭＶを訴えて
(suing),動き補償を行う。

【００３１】このプロセスを例として示す。動きデータ
のシーケンスは、以下のとおりであるとする。ここにおいては、簡単にするために、ＭＶの水平成分だ
けが扱われ、MB_Incは考慮されない。この動きデータ領
域において実際にコード化されるのは７つの動きベクト
ルであり、これらは、動きベクトル差分（ＭＶＤ）、動
きベクトル予測子（Ｐ）、及び実際の動きベクトル（Ｍ
Ｖ）として表現される。最後のＭＶ値（即ち、この例で
は、ＭＶ[7]=24）がＭＶ予測子状態として記憶されるこ
ととする。この情報は、前方向デコーディングにおける
と同様に後方向デコーディングにおいて使用される。前
方向ディコーディングにおいて前方向ディコーディングにおいて

【００３２】上記において、ＭＶＤはビットストリーム
から得られる。ＭＶＤ及びパケットの頭において０であ
ると仮定されるP[0]は、前方向デコーディングにおいて
ＭＶを構成することができ、一方、予測子状態として埋
め込まれるべきＭＶＤも、後方向デコーディングにおい
てＭＶを回復することができる。、このようにして、Ｍ
Ｖは、両方向において正しくデコードすることができ
る。次に、MB No.1においてエラーが発生し、ＭＶＤデ
ータ”1101001” が“1101011”に変わったと仮定す
る。デコーダは、これらの間違ったビットをMVD[1]=-7
に翻訳する。こうして、デコーダでは、次のようなＭＶ
が得られる。

【００３３】尚、８つのうちの１つのビットエラーによ
って、ＭＶはスポイルされ、そのエラーはまだ検出され
ていない。この例では、間違ってビットが間違ったＶＬ
Ｃコードワードとして解釈される可能性が高い。このよ
うに、エラーは、ＶＬＣコーディング文脈において、検
出されずに広がることがある。好ましい実施の形態によ
ると、これらのＭＶは次のようにコード化される。１つ
のエントリランがＭＶ予測子状態を意味する。好ましい実施の形態によるデコーダは、３つのステップ
で動作する。エラー検出と、再同期と、エラー回復及び
エラー隠匿とである。これらのステップは、上記例と同
じ位置でビットエラーが生じるとして、次のように表現
される。

【００３４】ステップ１．実際のデコーディングにおけ
るＭＶ予測子がＭＶ予測子状態と異なる場合にエラーが
検出される。この例では、実際のデコーディングにおけ
るＭＶ予測子は１６であり、一方、ＭＶ予測子状態は３
０である。尚、違法ＶＬＣコードワードが見つかった場
合にもエラーが検出される。ステップ２．ひとたびエラーが検出されると、デコーダ
は、モニタマーカーを探すことによって、再同期点を探
す。

【００３５】ステップ３．モニタマーカの直前のＭＶ予
測子状態において逆方向デコーディングが開始される。
このプロセスは、次の２つのイベントのうちいずれかが
生じるまで続く。（１）ＭＶ予測子状態が逆方向デコー
ディングにおけるＭＶ予測子と異なる。（２）プロセス
が、エラーの検出されたＭＢに到達する（このＭＶは処
理されない）。逆方向デコーディングが終了すると、回
復されたデータは正しい情報として記憶される。ステップ４．前方向デコーディングにおいてＭＶ予測子
状態によって確認されていないデータは、浄化されなけ
ればならない。この具体的な例において、ＭＶは０にリ
セットされる。尚、このプロセスは、更なる調査に基づ
いて最適化してもよい。動きデータに続くテクスチャデータは、そのように扱わ
なければならない。エラー隠匿によって処理されたＭＢ
に対応する予測エラー信号は破棄される。ただし、ＭＢ
がintraコード化され、正しくデコードされたものであ
れば、そのＭＢは、そのＭＢに対する動きデータが首尾
よく回復されたとしても、intraＭＢとして表現され
る。

【００３６】

【００３７】

【００３８】（関連出願）本出願は、１９９９年８月２
日出願の米国仮特許出願第60/146,888号からの優先権を
主張する。１９９８年３月１８日出願の共願の米国特許
出願第09/040,676号（ドケット２５８０２）は、関連主
題を開示する。これらの出願の出願人は同一人物であ
る。

【００３９】以上の説明に関して更に以下の項を開示す
る。（１）マクロブロック動きベクトルとテクスチャデータ
とを含むパケットを備えたタイプの動き補償ビデオであ
って、（a）可逆粗製コードプラスインターリーブされ
た付加的コードビットを含むコードワードによってエン
コードされた動きベクトルを備えるビデオ。（２）第１項記載のビデオであって、（a）動きベクト
ル成分が、先行する動きベクトル成分の予測子と共に差
分的にエンコードされることを特徴とするビデオ。（３）第２項記載のビデオであって、（a）動きベクト
ル成分コードワードが表１２に記載されているものであ
ることを特徴とするビデオ。（４）第１項記載のビデオであって、（a）粗製コード
が値の範囲を示し、（b）付加的ビットが値の範囲を伴
う値を示すことを特徴とするビデオ。（５）マクロブロック動きベクトルとテクスチャデータ
とを含むパケットを備えたタイプの動き補償ビデオのた
めのデコーダであって、（a）可逆粗製コードプラスイ
ンターリーブされた付加的コードビットを含むコードワ
ードによってエンコードされた動きベクトルを検出すべ
く動作するデコーダを備えるデコーダ。（６）マクロブロック動きベクトルとテクスチャデータ
とを含むパケットを備えたタイプの動き補償ビデオのた
めのエンコーダであって、(a)可逆粗製コードプラスイ
ンターリーブされた付加的コードビットを含むコードワ
ードによって動きベクトルをエンコードすべく動作する
デコーダを備えるエンコーダ。

【図面の簡単な説明】

【図１】可逆コーディングを伴うエラー検出を示す。

【図２】可逆コーディングを伴うエラー検出を示す。

【図３】可逆コーディングを伴うエラー検出を示す。

【図４】可逆コーディングを伴うエラー検出を示す。

【図５】固定長コード表である。

【図６】a乃至cは、データ仕切り用ビットストリームシ
ンタクスを示す。

【図７】データ及びヘッダ仕切り用ビットストリームシ
ンタクスを示す。

【図８】別のビットストリームシンタクスを示す。

【図９】別のビットストリームシンタクスを示す。

【図１０】動きベクトルコーディングを示す。

【図１１】動きベクトル予測を示す。

Claims

【特許請求の範囲】

【請求項１】マクロブロック動きベクトルとテクスチャ
データとを含むパケットを備えた動き補償ビデオであっ
て、（ａ）可逆粗製コードプラスインターリーブされた付
加的コードビットを含むコードワードによってエンコー
ドされた動きベクトルを備えるビデオ。