(57)【要約】符号器と、推定フレーム・サイズ及び最初の固定目標パケット・サイズに基づいて一つのフレームについてどれだけのパケットが生成されるかを最初に推定するパケット交換ビデオ・アセンブラーを持つデバイス。その後、更新パケット・サイズはパケット毎またはスライス毎基準で再計算される。ビデオ・アセンブラーは３−段階の処理を含む。第一段階はビデオ系列の符号化の有無にかかわらずフレーム・サイズを推定し、そこでは第一段階が符号化を含む場合には、符号化データはシミュレーション・ビットストリームに詰込まれる。第二段階は目標パケット・サイズ、推定フレーム・サイズ及び構成モードを使用してパケットの数を推定する。第三段階は各ＭＢを予備符号化する１−ＭＢ予測手法を使用して動的にパケット・サイズを更新する。代わりの実施例では、現在のマクロブロックの符号化が第三段階の間に行われるとき、第三段階は予測機能をオフにする。
2010505367.tif 000002
【特許請求の範囲】
【請求項１】
符号化ビデオ・データを造出するためにビデオ系列を符号化する働きをする符号器、及び符号化ビデオ・データが実際のビットストリームに詰込まれる間に、パケット毎基準で、少なくとも推定フレーム・サイズ及びパケットの数に基づいてフレームについて生成されるフレームの数を推定し、そして更新パケット・サイズを繰返し計算することによって符号化ビデオ・データを動的に調整されたパケットにパケット化する働きをするパケット交換ビデオ・アセンブラー；及び
実際のビットストリームを伝送するための送信器
を具備するパケット交換ビデオ電話通信デバイス。
【請求項２】
パケット交換ビデオ・アセンブラーは構成モード、推定フレーム・サイズ及び最初の固定目標パケット・サイズに基づいてパケットの数を決定する；そしてパケットの数及び推定フレーム・サイズに基づいて新しい目標パケット・サイズを計算する働きをする、請求項１記載のデバイス。
【請求項３】
パケット交換ビデオ・アセンブラーは符号化データをシミュレーション・ビットストリームに詰込むことによって推定フレーム・サイズを推定する働きをする、請求項２記載のデバイス。
【請求項４】
パケット交換ビデオ・アセンブラーはシミュレーション再同期マーカーまたはシミュレーション・スライス・ヘッダーをシミュレーション・ビットストリームに挿入することによって推定フレーム・サイズを推定する働きをする、請求項３記載のデバイス。
【請求項５】
パケット交換ビデオ・アセンブラーは符号化データの現在のマクロブロックを実際のビットストリームに詰込む；符号化ビデオ・データにおいて一つのマクロブロックを予測する；現在のパケット・サイズのサイズを表す計数と一つのマクロブロックのサイズを表す計数の所定の部分を加えた結果が更新されたパケット・サイズを越えるか否かを評価する；そしてその結果が更新されたパケット・サイズを越えるとき、そしてパケット計数がパケットの数より少ないならば、実際の再同期マーカーまたは実際のスライス・ヘッダーを一つのマクロブロックの前に挿入し、そして更新されたパケット・サイズを再計算する働きをする、請求項４記載のデバイス。
【請求項６】
パケット交換ビデオ・アセンブラーは符号化ビデオ・データの現在のマクロブロックについて非ゼロ係数（ＮＺＣ）の数を計算し、そして総フレームＮＺＣを形成するためにフレーム中の各マクロブロックについてＮＺＣ数を累算することによって推定フレーム・サイズを推定する働きをする、請求項２記載のデバイス。
【請求項７】
パケット交換ビデオ・アセンブラーは次式
estimated_frame_size = 
alpha*total_frame NZC + previous_non-texture_size
に基づいて推定フレーム・サイズを推定する働きをし、
ここでアルファ（alpha）は
alpha = 
(previous_frame_size - previous_non-texture_size)/
previous_total_frame_NZC
であり、そして前の非テクスチャー・サイズは前のフレームにおける非テクスチャー・ビットを表す計数である；前のフレーム・サイズは前のフレームの実際のフレーム・サイズである；そして前の総フレームＮＺＣは前のフレームの総フレームＮＺＣである、請求項６記載のデバイス。
【請求項８】
パケット交換ビデオ・アセンブラーは、符号化データの現在のマクロブロックの実際のビットストリームへの詰込みの後、一つのマクロブロックを予測する；現在のパケット・サイズを表す計数と所定の係数で乗算した一つのマクロブロックのＮＺＣの計数を加えた結果が更新されたパケット・サイズより大きいかどうかを評価する；そしてその結果が更新されたパケット・サイズを越え、且つパケット計数がパケットの数より少なければ、実際の再同期マーカーまたは実際のスライス・ヘッダーを一つのマクロブロックの前に挿入し、そして更新されたパケット・サイズを再計算する働きをする、請求項７記載のデバイス。
【請求項９】
パケット交換ビデオ・アセンブラーは
estimated_frame_size = alpha* desired_total_frame_NZC +
previous_non-texture_size
に基づいて推定フレーム・サイズを推定する働きをし、ここで
alpha = previous_frame_size - previous_non-texture_size)/
previous_total_frame_NZCそして、
前の非テクスチャー・サイズは前のフレームにおける非テクスチャー・ビットを表す計数である；前のフレーム・サイズは前のフレームの実際のフレーム・サイズである；前の総フレームＮＺＣは前のフレームの総非ゼロ係数（ＮＺＣ）の累算を表す計数である；そして所望の総フレームＮＺＣはフレームの総非ゼロ係数（ＮＺＣ）を同定する最初の固定値である、請求項１記載のデバイス。
【請求項１０】
パケット交換ビデオ・アセンブラーは最大量子化パラメータについてフレームの非ゼロ係数（ＮＺＣ）の総数を表す総フレームＮＺＣ値を計算する；そしてパケットの数（パケット数は構成モードの関数である）で除算した総フレームＮＺＣの丸めた（四捨五入した）結果に基づいて非ゼロ係数（ＮＺＣ）の目標パケットの数を表す目標パケットＮＺＣ値を計算する働きをする、請求項９記載のデバイス。
【請求項１１】
パケット交換ビデオ・アセンブラーは、現在のマクロブロックを符号化し、現在のマクロブロックについて非ゼロ係数（ＮＺＣ）の数を計算し、そして現在のマクロブロックを実際のビットストリームに詰込んだ後、現在のパケットの非ゼロ係数（ＮＺＣ）を表す計数が更新パケットＮＺＣ値より大きいかどうかを評価する；そしてその結果が更新パケットＮＺＣ値を越え、且つパケット計数がパケットの数より小さければ、再同期マーカーまたはスライス・ヘッダーを次のマクロブロックの前に挿入し、そして更新パケットＮＺＣ値を再計算する働きをする、請求項１０記載のデバイス。
【請求項１２】
実行に際して
符号化ビデオ・データを造出するためにビデオ系列を符号化する；
推定フレーム・サイズに基づくフレームについて生成されるべきパケットの数を推定する；そして
符号化ビデオ・データが実際のビットストリームに詰込まれる間、少なくとも推定フレーム・サイズ及びパケットの数に基づいて、パケット毎基準で、更新されたパケット・サイズを繰返し計算する
働きをするプログラム命令を持つプログラム・コード。
【請求項１３】
パケットの数を推定する働きをするプログラム命令は実行に際してパケットの数の計算を変える構成モードを決定する；そして構成モードのためのパケットの数及び推定フレーム・サイズに基づいて新しい目標パケット・サイズを計算する働きをするプログラム命令を含む、請求項１２記載のプログラム・コード。
【請求項１４】
符号化データをシミュレーション・ビットストリームに詰込むことによって推定フレーム・サイズを推定する働きをするプログラム命令をさらに含む、請求項１３記載のプログラム・コード。
【請求項１５】
推定フレーム・サイズを推定する働きをするプログラム命令は実行に際してシミュレーション再同期マーカーまたはシミュレーション・スライス・ヘッダーをシミュレーション・ビットストリームに挿入する働きをするプログラム命令を含む、請求項１４記載のプログラム・コード。
【請求項１６】
プログラム命令は符号化データの現在のマクロブロックを実際のビットストリームに詰込む；符号化ビデオ・データにおいて一つのマクロブロックを予測する；現在のパケット・サイズのサイズを表す計数と一つのマクロブロックのサイズを表す計数の所定の部分を加えた結果が更新されたパケット・サイズを越えるか否かを評価する；そしてその結果が更新されたパケット・サイズを越えるとき、そしてパケット計数がパケットの数より小さければ、マクロブロックの前に実際の再同期マーカーまたは実際のスライス・ヘッダーを挿入し、そして更新されたパケット・サイズを再計算するさらに働きをする、請求項１５記載のプログラム・コード。
【請求項１７】
プログラム命令は符号化ビデオ・データの現在のマクロブロックについて非ゼロ係数（ＮＺＣ）の数を計算し、そして総フレームＮＺＣを形成するためにフレーム中の各マクロブロックについてＮＺＣの数を累算することによって推定フレーム・サイズを推定するさらに働きをする、請求項１３記載のプログラム・コード。
【請求項１８】
推定フレーム・サイズを推定する働きをするプログラム命令は実行に際して
estimated_frame_size = alpha*total_frame NZC + previous_non-texture_size
に基づいて推定フレーム・サイズを計算する働きをするプログラム命令を含み、
ここでアルファ（alpha）は
alpha = (previous_frame_size - previous_non-texture_size)/
previous_total_frame_NZC
であり、そして前の非テクスチャー・サイズは前のフレームにおける非テクスチャー・ビットを表す計数である；前のフレーム・サイズは前のフレームの実際のフレーム・サイズである；そして前の総フレームＮＺＣは前のフレームの総フレームＮＺＣである、請求項１７記載のプログラム・コード。
【請求項１９】
プログラム命令は、符号化データの現在のマクロブロックの実際のビットストリームへの詰込みの後、一つのマクロブロックを予測する；現在のパケット・サイズを表す計数と所定の係数で乗算した一つのマクロブロックのＮＺＣの計数を加えた結果が更新されたパケット・サイズより大きいかどうかを評価する；そしてその結果が更新されたパケット・サイズを越え、且つパケット計数がパケットの数より少なければ、実際の再同期マーカーまたは実際のスライス・ヘッダーを一つのマクロブロックの前に挿入し、そして更新されたパケット・サイズを再計算する働きをするプログラム命令をさらに含む、請求項１８記載のプログラム命令。
【請求項２０】
プログラム命令は実行に際して
estimated_frame_size = alpha* desired total_frame_NZC +
previous_non-texture_size
に基づいて推定フレーム・サイズを推定する働きをするプログラム命令をさらに含み、ここで
alpha = previous_frame_size - previous_non-texture_size)/
previous_total_frame_NZC、
そして前の非テクスチャー・サイズは前のフレームにおける非テクスチャー・ビットを表す計数である；前のフレーム・サイズは前のフレームの実際のフレーム・サイズである；前の総フレームＮＺＣは前のフレームの総非ゼロ係数（ＮＺＣ）の累算を表す計数である；そして所望の総フレームＮＺＣはフレームの総非ゼロ係数（ＮＺＣ）を同定する最初の固定値である、請求項１２記載のプログラム命令。
【請求項２１】
プログラム命令は実行に際して最大量子化パラメータについてフレームの非ゼロ係数（ＮＺＣ）の総数を表す総フレームＮＺＣ値を計算する；そしてパケットの数（パケット数は構成モードの関数である）で除算した総フレームＮＺＣ値の丸めた（四捨五入した）結果に基づいて非ゼロ係数（ＮＺＣ）の目標パケットの数を表す目標パケットＮＺＣ値を計算する働きをするプログラム命令をさらに含む、請求項２０記載のプログラム命令。
【請求項２２】
プログラム命令は実行に際して、現在のマクロブロックを符号化し、現在のマクロブロックについていくつかの非ゼロ係数（ＮＺＣ）を計算し、そして現在のマクロブロックを実際のビットストリームに詰込んだ後、現在のパケットの非ゼロ係数（ＮＺＣ）を表す計数が更新パケットＮＺＣ値より大きいかどうかを評価する；そしてその結果が更新パケットＮＺＣ値を越え、且つパケット計数がパケットの数より小さければ、再同期マーカーまたはスライス・ヘッダーを次のマクロブロックの前に挿入し、そして更新パケットＮＺＣ値を再計算する働きをするプログラム命令をさらに含む、請求項２１記載のプログラム命令。
【請求項２３】
最大量子化パラメータはＭＰＥＧ−４ビデオ符号化標準フォーマットまたはＨ．２６３ビデオ符号化標準フォーマットにおける符号化ビデオ・データについては３１、そしてＨ．２６４ビデオ符号化標準フォーマットおける符号化ビデオ・データについては５２である、請求項２１記載のプログラム命令。
【請求項２４】
符号化ビデオ・データを造出するためビデオ系列を符号化するための符号化手段；
推定フレーム・サイズに基づいてフレームについて生成されるべきパケットの数を推定し、そして符号化ビデオ・データが実際のビットストリームに詰込まれる間、少なくとも推定フレーム・サイズ及びパケットの数に基づいて、パケット毎基準で、更新パケット・サイズを繰り返し計算することによって符号化ビデオ・データを動的に調整されたパケットに組立てる（assembling）ためのビデオ組立手段（video assembling means）；及び
実際のビットストリームを伝送するための伝送手段
を具備するパケット交換ビデオ電話通信デバイス。
【請求項２５】
ビデオ組立手段は構成モード、推定フレーム・サイズ及最初の固定目標パケット・サイズに基づいてパケットの数を決定するための決定手段；及びパケットの数及び推定フレーム・サイズに基づいて新しい目標パケット・サイズを計算するための計算手段を含む、請求項２４記載のデバイス。
【請求項２６】
ビデオ組立手段は符号化データをシミュレーション・ビットストリームに詰込むことによって推定フレームを推定するための推定手段を含む、請求項２５記載のデバイス。
【請求項２７】
推定手段はシミュレーション・ビットストリームにシミュレーション同期マーカーまたはシミュレーション・スライス・ヘッダーを挿入するための挿入手段を含む、請求項２６記載のデバイス。
【請求項２８】
ビデオ組立手段は符号化データの現在のマクロブロックを実際のビットストリームに詰込むための詰込手段；符号化ビデオ・データにおいて一つのマクロブロックを予測するための予測手段；現在のパケット・サイズのサイズを表す計数と一つのマクロブロックのサイズを表す計数の所定の部分を加えた結果が更新されたパケット・サイズを越えるか否かを評価するための評価手段；及びその結果が更新されたパケット・サイズを越えるとき、そしてパケット計数がパケットの数より小さければ、マクロブロックの前に実際の再同期マーカーまたは実際のスライス・ヘッダーを挿入するための挿入手段を含む、請求項２７記載のデバイス。
【請求項２９】
ビデオ組立手段は符号化ビデオ・データの現在のマクロブロックについて非ゼロ係数（ＮＺＣ）の数を計算し、そして総フレームＮＺＣを形成するためにフレーム中の各マクロブロックについてＮＺＣ数を累算することによって推定フレーム・サイズを推定するための推定手段を具備する、請求項２５記載のデバイス。
【請求項３０】
推定フレーム・サイズを推定するための推定手段は
estimated_frame_size = alpha*total_frame NZC + previous_non-texture_size
に基づいて推定フレーム・サイズを計算し、
ここでアルファ（alpha）は
alpha = (previous_frame_size - previous_non-texture_size)/
previous_total_frame_NZC
であり、そして前の非テクスチャー・サイズは前のフレームにおける非テクスチャー・ビットを表す計数である；前のフレーム・サイズは前のフレームの実際のフレーム・サイズである；そして前の総フレームＮＺＣは前のフレームの総フレームＮＺＣである、請求項２９記載のデバイス。
【請求項３１】
ビデオ組立手段は、符号化データの現在のマクロブロックの実際のビットストリームへの詰込みの後、一つのマクロブロックを予測するための予測手段；現在のパケット・サイズを表す計数と所定の係数で乗算した一つのマクロブロックのＮＺＣの計数を加えた結果が更新されたパケット・サイズより大きいかどうかを評価するための評価手段；その結果が更新されたパケット・サイズを越えたとき、実際の再同期マーカーまたは実際のスライス・ヘッダーを一つのマクロブロックの前に挿入するための挿入手段；及びその結果が更新されたパケット・サイズを越えたとき、且つパケット計数がパケットの数より少なければ、更新されたパケット・サイズを再計算するための再計算手段を具備する、請求項３０記載のデバイス。
【請求項３２】
ビデオ組立手段は
estimated_frame_size = alpha* desired_total_frame_NZC +
previous_non-texture_size
に基づいて推定フレーム・サイズを推定するための推定手段を具備し、ここで
alpha = previous_frame_size - previous_non-texture_size)/
previous_total_frame_NZC、
そして前の非テクスチャー・サイズは前のフレームにおける非テクスチャー・ビットを表す計数である；前のフレーム・サイズは前のフレームの実際のフレーム・サイズである；前の総フレームＮＺＣは前のフレームの総非ゼロ係数（ＮＺＣ）を表す計数である；そして所望の総フレームＮＺＣはフレームの総非ゼロ係数（ＮＺＣ）を同定する最初の固定値である、請求項３１記載のデバイス。
【請求項３３】
ビデオ組立手段は最大量子化パラメータについてフレームの非ゼロ係数（ＮＺＣ）の総数を表す総フレームＮＺＣ値を計算するための計算手段；及びパケットの数（パケット数は構成モードの関数である）で除算した総フレームＮＺＣの丸めた（四捨五入した）結果に基づいて非ゼロ係数（ＮＺＣ）の目標パケットの数を表す目標パケットＮＺＣ値を計算するための計算手段を具備する、請求項２４記載のデバイス。
【請求項３４】
ビデオ組立手段は、現在のマクロブロックを符号化し、現在のマクロブロックについていくつかの非ゼロ係数（ＮＺＣ）を計算し、そして現在のマクロブロックを実際のビットストリームに詰込んだ後、現在のパケットの非ゼロ係数（ＮＺＣ）を表す計数が更新パケットＮＺＣより大きいかどうかを評価するための評価手段；その結果が更新パケットＮＺＣ値を越えたとき、再同期マーカーまたはスライス・ヘッダーを次のマクロブロックの前に挿入するための挿入手段、及びその結果が更新パケットＮＺＣ値を越えたとき、且つパケット計数がパケットの数より小さければ、更新パケットＮＺＣ値を再計算するための再計算手段を具備する、請求項３３記載のデバイス。
【請求項３５】
最大量子化パラメータはＭＰＥＧ−４ビデオ符号化標準フォーマットまたはＨ．２６３ビデオ符号化標準フォーマットにおける符号化ビデオ・データについては３１、そしてＨ．２６４ビデオ符号化標準フォーマットおける符号化ビデオ・データについては５２である、請求項３４記載のデバイス。
【請求項３６】
デバイスはセルラー電話、無線電話、衛星電話また画像獲得能力を持つ他のモバイル／無線通信デバイスの一つを具備する、請求項２４記載のデバイス。
【請求項３７】
符号化ビデオ・データを造出するためにビデオ系列を符号化するするステップ；及び
符号化ビデオ・データが実際のビットストリームに詰込まれる間、パケット毎基準で、少なくとも推定フレーム・サイズ及びパケットの数に基づいてフレームについて生成されるフレームの数を推定することによって符号化ビデオ・データを動的に調整するステップ
を含む方法。
【請求項３８】
動的に調整するステップは構成モード、推定フレーム・サイズ及び最初の固定目標パケット・サイズに基づいてパケットの数を決定するステップ；及びパケットの数及び推定フレーム・サイズに基づいて新しい目標パケット・サイズを計算するステップを含む、請求項３７記載の方法。
【請求項３９】
動的に調整するステップは符号化データをシミュレーション・ビットストリームに詰込むことによって推定フレーム・サイズを推定することを含む、請求項３８記載の方法。
【請求項４０】
フレーム・サイズを推定するための推定ステップはシミュレーション再同期マーカーまたはシミュレーション・スライス・ヘッダーをシミュレーション・ビットストリームに挿入するステップを含む、請求項３９記載の方法。
【請求項４１】
動的に調整するステップは符号化データの現在のマクロブロックを実際のビットストリームに詰込むステップ；符号化ビデオ・データにおいて一つのマクロブロックを予測するステップ；現在のパケット・サイズのサイズを表す計数と一つのマクロブロックのサイズを表す計数の所定の部分を加えた結果が更新されたパケット・サイズを越えるか否かを評価するステップ；その結果が更新されたパケット・サイズを越えるとき、一つのマクロブロックの前に実際の再同期マーカーまたは実際のスライス・ヘッダーを挿入するステップ；及びその結果が更新されたパケット・サイズを越えるとき、且つパケット計数がパケットの数より小さければ、更新されたパケット・サイズを再計算するステップを含む、請求項４０記載の方法。
【請求項４２】
動的に調整するステップは符号化ビデオ・データの現在のマクロブロックについて非ゼロ係数（ＮＺＣ）の数を計算し、そして総フレームＮＺＣを形成するためにフレーム中の各マクロブロックについてＮＺＣ数を累算することによって推定フレーム・サイズを推定するステップを含む、請求項３８記載の方法。
【請求項４３】
推定フレーム・サイズを推定するための推定ステップは次式
estimated_frame_size = alpha*total_frame NZC + previous_non-texture_size
に基づいて推定フレーム・サイズを計算し、
ここでアルファ（alpha）は
alpha = (previous_frame_size - previous_non-texture_size)/
previous_total_frame_NZC
によって定義され、そして前の非テクスチャー・サイズは前のフレームにおける非テクスチャー・ビットを表す計数である；前のフレーム・サイズは前のフレームの実際のフレーム・サイズである；そして前の総フレームＮＺＣは前のフレームの総フレームＮＺＣである、請求項４２記載の方法。
【請求項４４】
動的に調整するステップは、符号化データの現在のマクロブロックの実際のビットストリームへの詰込みの後、一つのマクロブロックを予測するステップ；現在のパケット・サイズを表す計数と所定の係数で乗算した一つのマクロブロックのＮＺＣの計数を加えた結果が更新されたパケット・サイズより大きいかどうかを評価するステップ；その結果が更新されたパケット・サイズを越えたとき、実際の再同期マーカーまたは実際のスライス・ヘッダーを一つのマクロブロックの前に挿入するステップ；及びその結果が更新されたパケット・サイズを越えたとき、且つパケット計数がパケットの数より少なければ、更新されたパケット・サイズを再計算するステップを含む、請求項４３記載の方法。
【請求項４５】
動的に調整するステップは
estimated_frame_size = alpha* desired_total_frame_NZC +
previous_non-texture_size
に基づいて推定フレーム・サイズを推定するステップを含み、ここで
alpha = previous_frame_size - previous_non-texture_size)/
previous_total_frame_NZC、
そして前の非テクスチャー・サイズは前のフレームにおける非テクスチャー・ビットを表す計数である；前のフレーム・サイズは前のフレームの実際のフレーム・サイズである；前の総フレームＮＺＣは前のフレームの総非ゼロ係数（ＮＺＣ）を表す計数である；そして所望の総フレームＮＺＣはフレームの総非ゼロ係数（ＮＺＣ）を同定する最初の固定値である、請求項３７記載の方法。
【請求項４６】
動的に調整するステップは最大量子化パラメータについてフレームの非ゼロ係数（ＮＺＣ）の総数を表す総フレームＮＺＣ値を計算するステップ；及びパケットの数（パケット数は構成モードの関数である）で除算した総フレームＮＺＣの丸めた（四捨五入した）結果に基づいて非ゼロ係数（ＮＺＣ）の目標パケットの数を表す目標パケットＮＺＣ値を計算するステップを含む、請求項４５記載の方法。
【請求項４７】
動的に調整するステップは、現在のマクロブロックを符号化し、現在のマクロブロックについていくつかの非ゼロ係数（ＮＺＣ）を計算し、そして現在のマクロブロックを実際のビットストリームに詰込んだ後、現在のパケットの非ゼロ係数（ＮＺＣ）を表す計数が更新パケットＮＺＣより大きいかどうかを評価するステップ；その結果が更新パケットＮＺＣ値を越えたとき、且つパケット計数がパケットの数より小さければ、再同期マーカーまたはスライス・ヘッダーを次のマクロブロックの前に挿入するステップ、及びその結果が更新パケットＮＺＣ値を越えたとき、且つパケット計数がパケットの数より小さければ、更新パケットＮＺＣ値を再計算するステップ含む、請求項４６記載の方法。
【請求項４８】
最大量子化パラメータはＭＰＥＧ−４ビデオ符号化標準フォーマットまたはＨ．２６３ビデオ符号化標準フォーマットにおける符号化ビデオ・データについては３１、そしてＨ．２６４ビデオ符号化標準フォーマットおける符号化ビデオ・データについては５２である、請求項４７記載の方法。
【請求項４９】
マクロブロックを持つ符号化ビデオ・データを造出するためにビデオ系列を符号化する働きをするマクロブロック符号化モジュール；及び符号化ビデオ・データが実際のビットストリームに詰込まれる間、スライス毎基準で、更新パケット・サイズ（更新パケット・サイズは最初の固定目標フレーム・サイズとパケットの推定数から得られた推定フレーム・サイズの関数である）を繰返し計算することによって符号化ビデオ・データを動的に調整されたパケットにパケット化する働きをするパケット交換ビデオ・アセンブラーを具備する符号器。
【請求項５０】
推定フレームは符号化ビデオ・データをシミュレーション・ビットストリームに詰込み、そしてシミュレーション再同期マーカーまたはシミュレーション・スライス・マーカーを挿入することによって計算される、請求項４９記載の符号器。
【発明の詳細な説明】
【技術分野】
【０００１】
１．［発明の分野］
この発明はパケット交換ビデオ電話通信アプリケーションにおいてビデオ・パケット化に関する。
【背景技術】
【０００２】
２．［背景］
ビデオ・スライスは一般的に誤りが検出されたとき同期を回復するために復号器（decoder）によって使用される再同期マーカー（resynchronization marker：ＲＭ）またはスライス・ヘッダーによって起動する。特に、ＲＭは一般にただマクロブロック（ＭＢ）境界に置かれ、そしてビデオ・フレームの中に任意に置くことができない。このように、一以上のＭＢが厳密に或るパケット中で適合するように、ビデオ・スライス・サイズを調整することは符号器（encoder）にとって難しい。
【０００３】
ビデオ・スライス整列のための一つの技術はスライス長を調整するためにＭＢの量子化ステップ・サイズを調整するスライス・レベル・レート制御を含む。不幸にも、この技術は符号器設計が非常に複雑さになり、そして必ずしも正確であるとは限らない。別の技術はそのサイズが所定の長さを越えるまでスライスを符号化し、その後符号化ビデオの終端とスライスの終端の間にパディング・バイトを加えることを必要とする。しかしながら、この手法は帯域幅効率を損ねる。
【０００４】
伝統的な方法は生成されたビットの数が所定のサイズを越えるとき一つのビデオ・パケットを作成する。このように、一つのフレームにおいて最後のわずかのバイトのビデオ・データに不必要な誤り保護を行っている間、伝送のために追加のＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰオーバーヘッドを必要とする多くの小さなビデオ・パケットを持つことは問題がある。どのくらいのビットが見捨てられるかを推定するために予測手法が使用されるにしても、伝統的な方法は小さなパケットをまだ完全に避けることができない。
【０００５】
ビットストリームを再符号化することは問題を解決しないであろう。その代りに、再符号化は所定のサイズに適合する最適解を見付けるのに多数の符号化の実行を必要とする。更に、再符号化はモバイル・デバイス・アプリケーションに扱いやすい実施手法ではない。
【０００６】
ビデオ・パケット化はパケット交換（ＰＳ）ビデオ・アプリケーションにおける挑戦問題であった（それはパケット化効率と誤り回復の背反性を包含するので）。ビデオ・パケットを送ることはＲＴＰ／ＵＤＰ／ＩＰヘッダーを含む４０バイトのオーバーヘッドを必要とする。パケットが小さければ、データ・レートに対するオーバーヘッドは高く、従ってそれは帯域幅に関して非能率的である。例えば、パケットが４０バイトのビデオ・データで送られるならば、そのオーバーヘッドは１００％である。そのような場合には、帯域幅に関して非能率的なパケット化を避けるためにビデオ符号器が十分なデータ量を持つビデオ・パケットを生成することが非常に望ましい。
【０００７】
大抵のビデオ・パケット化手法（以降、「元のパケット化手法」（original packetization approach）とする）では、所定のビデオ・パケット・サイズが通常指定され、そしてビデオ符号器はこのパケット・サイズの付近の全てのビデオ・パケットを生成しようとするであろう。そうする一つの方法は生成されたビデオ・データが所定のパケット・サイズを越えるかどうかを調べることである。イエス（yes）であれば、ビデオ符号器は再同期マーカー（ＲＭ）を挿入することによってビデオ・スライスを作成するであろう。しかしながら、元のパケット化手法は全てのビデオ・パケットが所定のパケット・サイズを持つであろうことを保証できない。非常にしばしば、いくつかの非常に小さなサイズのパケットがビデオ・フレームの終端で生成されるであろう。すなわち、元のパケット化手法はこのように効率的なパケット化を行うことができず、帯域幅は最後の数バイトを不必要に保護している間にしばしば浪費される。目標パケット・サイズとして１２０バイトを使用して元のパケット化手法を使った結果は図１に示されている。すぐに分かるように、多くの小さなパケット（強調のために円で示される）は元のパケット化手法について生成される。
【０００８】
所定のビデオ・パケット・サイズは通常に指定され、そして符号器は生成されたビデオ・データが所定のパケット・サイズを越えるかどうかを調べる。符号化が最後のＭ（例えば、Ｍ＝５）ＭＢに達するかどうかを調べるようないくつかの経験則的手法が使用される。イエス（yes）であれば、データ量が所定のビデオ・パケット・サイズを越えたとしても、ビデオ符号器はビデオ・パケットを生成しない。このように、経験則的手法はモバイル・デバイス・アプリケーションに使い易い実施手法ではなく、そしてまた正確なパケット・サイズを得ることができない。目標パケット・サイズとして１２０バイトを使用して経験則的パケット化手法を使った結果は図１Ｂに示される。すぐに分かるように、多くの小さなパケット（強調のために円で示される）が経験則的手法について生成される。
【発明の概要】
【０００９】
前記のことを考慮して、一つのフレームにおける最後の数バイトのビデオ・データに不必要な誤り保護を行う間、伝送のために追加ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰオーバーヘッドを必要とする多くの小ビデオ・パケットを持つことの問題を解決することが本発明の目的である。
【００１０】
見合った誤り回復を行いながらパケット化効率を向上させるためにどんな小さなパケットでも回避することが本発明の目的である。
【００１１】
パケットの数を減少させ、そして帯域幅利用を向上させることは本発明のさらなる目的である。
【００１２】
パケットの数を減少させ、そしてＷＣＤＭＡ回路交換に基づくビデオ電話通信（ＶＴ）のためにＭＰＥＧ４、Ｈ．２６３、Ｈ．２６４及び／またはＨ．２３３によるパケット化において帯域幅利用を向上させることが本発明のさらなる目的である。
【００１３】
パケット交換（ＰＳ）ビデオ電話通信（ＶＴ）アプリケーションのためにビデオ・フレームを（おおまかに）等しいサイズのパケットに分割することが本発明の目的である。
【００１４】
どんな小さなパケットも回避するために見合った誤り回復を行いながらパケット化効率を向上させるＭＰＥＧ４ビデオの再同期マーカー、またはＨ．２６３ビデオのスライス・ヘッダーを置くところを正確に推定することが本発明の目的である。
【００１５】
前述の目的を考慮して、本発明は符号化ビデオ・データを造出するためにビデオ系列を符号化する働きをする符号器及び符号化ビデオ・データが実際のビットストリームにパケット化される間に、パケット毎基準で、少なくとも推定フレーム・サイズ及びパケットの数に基づいてフレームについて生成されるべきパケットの数を推定し、且つ更新パケット・サイズを繰返し計算することによって符号化ビデオ・データを動的に調整されたパケットにパケット化する働きをするパケット交換ビデオ・アッセンブラーを具備するパケット交換ビデオ電話通信デバイスによって実行される。デバイスはまた実際のビットストリームを伝送するための送信器を含む。
【００１６】
パケット交換ビデオ・アッセンブラーは３段階の処理を含む。第一の段階は符号化マクロブロックをシミュレーション・ビットストリームに詰込んで、或いは詰込まないで推定フレームを推定する。第二の段階は推定フレーム・サイズ、目標サイズ及び構成（configuration）モードを使用してパケットの数を決定する。第三の段階は、マクロブロックが第一の段階において符号化されるとき、ビットストリームに詰込む間に１マクロブロック予測を使ってパケット毎またはスライス毎の基準でパケット・サイズを動的に更新する。
【００１７】
本発明の別の形態はプロセッサーによる実行の際、符号化ビデオ・データを造出するためビデオ系列を符号化する働きをするプログラム命令を持つプログラム・コードを提供することである。プログラム命令は推定フレーム・サイズに基づいてフレームについて生成されるいくつかのパケットを推定する働き；及び符号化ビデオ・データが実際のビットストリームにパケット化される間に、パケット毎基準で、少なくとも推定フレーム・サイズ及びパケットの数に基づいて、更新パケット・サイズを繰返し計算する働きをする。
【００１８】
本発明のなおさらなる形態は：符号化ビデオ・データを造出するビデオ系列を符号化するステップ；及びフレームについて生成されるパケットの数を推定し、そして符号化ビデオ・データが実際のビットストリームにパケット化される間に、パケット毎基準で、少なくとも推定フレーム・サイズ及びパケットの数に基づいて、更新パケット・サイズを繰り返し計算することによって符号化ビデオ・データのパケットを動的に調整するステップを含む。
【００１９】
本発明のなおさらなる形態はマクロブロックを持つ符号化ビデオ・データを造出するためビデオ系列を符号化する働きをするマクロブロック符号化モジュール；及び
符号化ビデオ・データが実際のビットストリームに詰込まれる間に、スライス毎基準で、更新パケット・サイズ（更新パケット・サイズは固定初期目標サイズ及び推定パケット数から得られた推定フレーム・サイズの関数である）を繰返し計算することによって符号化ビデオ・データを動的に調整されたパケットにパケット化する働きをするパケット交換ビデオ・アセンブラーを提供することである。
【００２０】
本発明の特徴は最初にどのくらいのパケットが（推定）フレーム・サイズ及び最初の固定目標パケット・サイズに基づいて一つのフレームについて生成されるべきかを推定することである。そして、新しい目標パケット・サイズが計算され、それはフレーム毎基準で実行される。従って、固定目標パケット・サイズを使用する代りに、新しい目標パケット・サイズが残りのパケットについて動的に更新される。
【００２１】
本発明の別の特徴はフレーム・サイズ情報が利用可能でないならば、非ゼロＤＣＴ係数の数の関数である情報がフレーム・サイズを推定するために使用されることである。
【００２２】
本発明の更なる特徴は各パケットのサイズがシミュレーション・ビットストリーム及び／または実際のビットストリームにおいておおよそ等しくなるように、再同期マーカー（ＲＭ）をどこに置くかをプログラム・コードが決定することである。その方法はまた各マクロブロック（ＭＢ）を予備符号化する、またはしない１ＭＢ予測手法を採用する。
【００２３】
前記の発明の概要は、発明の好ましい実施例の次の詳細な説明と同様に、付随の図と共に読まれるとき、さらによく理解されるであろう。発明を例示するために、やがて参照される実施例が図に示される。しかしながら、本発明は示された正確な配置に制限されないことは理解されるべきである。
【図面の簡単な説明】
【００２４】
【図１Ａ】１２０バイトの目標パケット・サイズを使用する元のパッケージ化手法に関するビデオ・パケット・サイズ対パケットの数のグラフを例示する。
【図１Ｂ】１２０バイトの目標パケット・サイズを使用する経験則的パッケージ化手法に関するビデオ・パケット・サイズ対パケットの数のグラフを例示する。
【図２】本発明によるパケット交換ビデオ電話通信デバイスの一般的なブロック図を例示する。
【図３】本発明によるパケット交換ビデオ・アセンブラーの一般的なブロック図を例示する。
【図４Ａ】本発明によるフレーム・サイズ推定（ＦＳＥ）処理のフローチャートを例示する。
【図４Ｂ】本発明によるフレーム・サイズ推定（ＦＳＥ）処理のフローチャートを例示する。
【図５】本発明によるパケットの数決定（ＮＰＤ）処理のフローチャートを例示する。
【図６Ａ】本発明によるビデオ・パケット化（ＶＰ）処理のフローチャートを例示する。
【図６Ｂ】本発明によるビデオ・パケット化（ＶＰ）処理のフローチャートを例示する。
【図７】本発明による代りのパケット・ビデオ・アセンブラーの一般的なブロック図を例示する
【図８】本発明による代りのフレーム・サイズ推定処理（ＦＳＥ）処理のフローチャートを例示する。
【図９Ａ】本発明による代りのビデオ・パケット化（ＶＰ）処理のフローチャートを例示する。
【図９Ｂ】本発明による代りのビデオ・パケット化（ＶＰ）処理のフローチャートを例示する。
【図１０】本発明によるなおさらなる代りのパケット・ビデオ・アセンブラーの一般的なブロック図を例示する。
【図１１】本発明によるなおさらなる代りのフレーム・サイズ（ＦＳＥ）処理のフローチャートを例示する。
【図１２】本発明による別のパケットの数決定（ＮＰＤ）処理のフローチャートを例示する。
【図１３Ａ】本発明によるなおさらなる代りのビデオ・パケット化（ＶＰ）処理のフローチャートを例示する。
【図１３Ｂ】本発明によるなおさらなる代りのビデオ・パケット化（ＶＰ）処理のフローチャートを例示する。
【図１４Ａ】図３のフレーム・サイズ推定モジュールの一般的なブロック図を例示する。
【図１４Ｂ】図７のフレーム・サイズ推定モジュールの一般的なブロック図を例示する。
【図１５Ａ】図３のパケットの数決定モジュールの一般的なブロック図を例示する。
【図１５Ｂ】図１０のパケットの数決定モジュールの一般的なブロック図を例示する。
【図１６】図３のビデオ・パッケージ化モジュールの一般的なブロック図を例示する。
【図１７Ａ】カルフォーン（Carphone）系列及び１２０バイトの目標パケット・サイズを使用する元のパッケージ化手法に関するバイトにおけるビデオ・パケット・サイズ対パケットの数のグラフを例示する。
【図１７Ｂ】図３の実施例においてカルフォーン系列を使用するバイト単位のビデオ・パケット・サイズ対パケットの数のグラフを例示する。
【図１７Ｃ】図７の実施例においてカルフォーン系列を使用するバイト単位のビデオ・パケット・サイズ対パケットの数のグラフを例示する。
【図１７Ｄ】図１０の実施例においてカルフォーン系列を使用するバイト単位のビデオ・パケット・サイズ対パケットの数のグラフを例示する。
【発明を実施するための形態】
【００２５】
［望ましい実施例の詳細な記載］
この発明は多くの異なる形における実施例が可能ではあるが、この仕様及び付随の図は発明の使用の例としていくつかの形を開示するだけである。本発明はそのように記述された実施例に制限されることを意図してなく、そして発明の範囲は付加された請求項において指摘されるであろう。
【００２６】
本発明によるパケット交換ビデオ電話通信デバイスの好ましい実施例はビデオ・パケット化への特定の応用として下で示される。パケット交換ビデオ電話通信デバイスはモバイル無線またはセルラー電話といった携帯用またはモバイル・デバイスである。しかしながら、本発明はまたパケット交換ビデオ電話通信アプリケーションを持つ計算デバイスを含めて他の型式のデバイスにも適応されることは当業者によって理解されるであろう。パケット交換ビデオ電話通信デバイスはＭＰＥＧ−４ビデオ、Ｈ．２６３及びＨ．２６４ビデオ及び広帯域符号分割多元アクセス（ＷＣＤＭＡ）回路交換テレビ電話（ＶＴ）のパケット化の基本であるＨ．２２３を含む。
【００２７】
さて図を詳細に参照すると、同じ数字が全体にわたって同じ要素を指示するために使用され、図２では一般に１０で示された、本発明によるパケット交換ビデオ電話通信デバイスが示されている。
【００２８】
パケット交換ビデオ電話通信デバイス１０はビデオ入力１２、及び獲得されたビデオ画像及び系列を符号化するために働く符号化エンジン１６を持つ符号器１４を含む。符号化エンジン１６は符号化ビデオ系列をビットストリームにパケット化するパケット交換ビデオ・アセンブラー３０をその中に埋込んでいた。パケット交換ビデオ・アセンブラー３０の出力はＭＰＥＧ−４ビデオ、Ｈ．２６３及びＨ．２６４ビデオ及び広帯域符号分割多元アクセス（ＷＣＤＭＡ）回路交換テレビ電話（ＶＴ）のパケット化の基本であるＨ．２２３と互換可能なパケット交換ビデオ電話通信信号に適応する通信媒体上のビットストリームの通信のための送信器／受信器２６に連結される。
【００２９】
一般的に、パケット交換ビデオ・アセンブラー３０は符号化エンジン１６に埋込まれ、そこではスライスが符号化の間に決定される。「符号化の間に」（during encoding）は符号化エンジン１６がフレームについてＭＢ符号化モジュール１８においてマクロブロック（ＭＢ）の符号化データ（例えば、動きベクトル及び量子化係数）を符号化し、そして符号化ＭＢデータをビットストリームに入れることをここでは意味する。このように、符号化エンジン１６は本発明に基づいて所定の目標サイズにビデオ・スライスを生成する能力を持ち、且つプログラム命令を持つプロセッサーである。
【００３０】
パケット交換ビデオ電話通信デバイス１０はまた、簡単にするために、符号化エンジン１６の出力信号と連結され、且つ／または結合されて示されるオーディオ入力２２を含む。詳細な説明はこの文中でＭＰＥＧ−４ビデオ、Ｈ．２６３及びＨ．２６４ビデオ及び広帯域符号分割多元アクセス（ＷＣＤＭＡ）回路交換テレビ電話（ＶＴ）のパケット化の基本であるＨ．２２３と互換可能なビデオ・パケット化形態、またはパケット交換ビデオ電話通信信号に対して主として行われる。
【００３１】
ここで図３を参照すると、パケット交換ビデオ・アセンブラー３０は、一般に、パケット数決定モジュール５０Ａの最初の目標パケット・サイズに基づいて、どれだけのパケットが現在のフレームについて生成されるべきかを見出すために配置されるフレーム・サイズ推定モジュール４０Ａ、パケット数決定モジュール５０Ａ及びビデオ・パケット化モジュール６０Ａを具備する。しかしながら、実際のフレーム・サイズを知らずに、生成されるべきパケットの数は決められない。さらに、パケット交換ビデオ・アセンブラー３０はフレーム・サイズ推定モジュール４０Ａにおいてフレーム・サイズを推定するために配置される。最終的に、ビデオ・パケット化モジュール６０Ａは符号化ビデオ系列をパケット化するために推定フレーム・サイズとパケット数決定の両方を使用する。
【００３２】
これらの二つのモジュール（フレーム・サイズ推定モジュール４０Ａ及びパケット数決定モジュール５０Ａ）はビデオ・パケット化モジュール６０Ａによってビデオ・パケット化を強固にするために重要である。パケットの数がパケット数決定モジュール５０Ａによって決定された後、パケット交換ビデオ・アセンブラー３０はビデオ・パケット化モジュール６０Ａによって実行される、実際のビデオ・パケット化（ＶＰ）処理１５０（図６）において目標フレーム・サイズを再計算する。
【００３３】
図１４Ａで最もよく分かるように、フレーム・サイズ推定モジュール４０Ａはビットストリーム詰込器４２、フレーム・サイズ推定器４４及び再同期マーカー挿入器４６を含む。図１５Ａで最もよく分かるように、パケット数決定モジュール５０Ａはパケット数計算器５２及び目標パケット・サイズ調整器５４を含む。目標パケット・サイズ調整器５４はモジュール４０Ａのフレーム・サイズ推定器４４からの推定フレーム・サイズに基づいて新しい目標パケット・サイズを計算する。パケット数計算器５２は推定フレーム・サイズ、目標パケット・サイズ及び構成モードに基づいてパケットの数を決定する。ビデオ・パケット化モジュール６０Ａはビットストリーム詰込器６２、再同期マーカー分配器６４及びパケット・サイズ調整器６６を含む。再同期マーカー分配器６４は各パケットのサイズがおおよそ同じか、または範囲内にあるように再同期マーカーまたはスライス・ヘッダーを挿入する。
【００３４】
その範囲は一般に１００と１５０バイトの間にある。パケット・サイズ調整器６６は動的に１ＭＢ予測を使用して目標パケット・サイズ（更新パケット・サイズ）を動的に更新する。典型的実施例において、ＭＢ[ｉ＋１]として表した次の（予測）ＭＢの一部に付加された現在のパケット・サイズの結果は更新パケット・サイズと比較される。一旦、その結果が更新パケット・サイズより大きくなると、再同期化マーカーが再同期マーカー分配器６４によって挿入され、そして更新パケット・サイズが再計算される。更新パケット・サイズが現在のパケット・サイズ及び１予測マクロブロックＭＢ[ｉ＋１]の一部の結果より小さくなるまで、ＭＢはビットストリームに詰込まれる。
【００３５】
第二に、生成されるべきパケットの数が分かった後、再同期化マーカー（ＲＭ）はフレーム中の各ビデオ・パケットのサイズがおおよそ同じになるようにフレーム内に分配される。これは実際のビデオ・パケット化処理１５０の間にトラッキング及び更新処理を必要とするであろう。トラッキングは前に言及したようにどれだけのバイトが生成されたかを追跡する。しかしながら、バイト単位で、またはＮＺＣ（非ゼロ係数の数）で一以上のＭＢを予測する追加ステップは情報の利用可能性（availability）及びアルゴリズムに依存する。更新処理はビデオ・パケット化が残りのパケットのサイズを均等に分配できるようにフレーム・サイズ（全ＮＺＣ量）及び前のパケットのサイズに従って目標ビデオ・サイズ（バイト単位で、またはＮＺＣで）再計算する。
【００３６】
方法１
一般に、パケット交換ビデオ・アセンブラー３０はバイトをパケットに一様に分配するためにビデオ・パケット化について３段階の処理を実行する３−モジュール、フレーム・サイズ推定モジュール４０Ａ、パケット数決定モジュール５０Ａ及びビデオ・パケット化モジュール６０Ａを含む。フレーム・サイズ推定モジュール４０Ａは最初の目標パケット・サイズ及び埋込みデータを符号化エンジン１６から受取る。パケット数決定モジュール５０Ａは同様に目標パケット・サイズ及び推定フレーム・サイズをパケット数決定モジュール５０Ａから受取る。 フレーム・サイズ推定モジュール４０Ａはまた推定フレーム・サイズ及びＭＢサイズ・アレイをビデオ・パケット化モジュール６０Ａへ送る。パケット数決定モジュール５０Ａはビデオ・パケット化モジュール６０Ａへパケットの数、及びバイト単位で新しい目標パケット・サイズを送る。
【００３７】
図４Ａ、４Ｂ、５及び６Ａ−６Ｂを参照すると、パケット交換ビデオ・アセンブラー３０によって実行される３段階処理が示されている。段階１において、フレーム・サイズ推定（ＦＳＥ）処理１００がフレーム・サイズ推定モジュール４０Ａによって行われる。段階２において、パケット数決定処理１３０がパケット数決定モジュール５０Ａによって行われる。段階３において、ビデオ・パケット化（ＶＰ）処理１５０がビデオ・パケット化モジュール６０Ａによって行われる。段階１では、図４Ａ−４Ｂで最もよく分かるように、ＦＳＥ処理１００はフレームについて生成されるべきパケットの数を決定する（図５の処理１３０におけるステップ１３８）ために最初に実際のビットストリーム詰込みを経過する（ステップＳ１０８）ことによってフレーム・サイズを推定する（ステップＳ１１４）。この推定フレーム・サイズ（ステップＳ１１４）は単に実際のフレーム・サイズから数バイト差だけの非常に正確なフレーム・サイズを与える。この正確なフレーム・サイズ推定に関して、段階２におけるパケットの数（ステップＳ１３８）はフレームについて確実に生成される。その上、ビットストリームを詰込む間（ステップＳ１５８）、段階３のＶＰ処理では、どれだけのビットが（おおよそ）生成されるかの推定（ステップＳ１６０、１６２）及びこの情報は使用すべきパケット・サイズを再推定する（ステップＳ１７０）ビデオ・パケット化に役立つ。
【００３８】
さらに、フレーム・サイズ推定（ＦＳＥ）処理１００（段階１）の詳細はここでさらに詳細に述べる。ＦＳＥ処理１００はステップＳ１０１Ｂにおいてバイト単位で（所与の）最初の目標パケット・サイズを仮定し、そして動きベクトル及び量子化係数といった各ＭＢに関する符号化データはＳ１０１Ａで記憶された。ステップ１０２は次のパラメータを初期化する：。
【００３９】
MB_Size_Array［ＭＢの全体数］= 0；
current_packet_size = 0；
estimated_frame_size = 0.
ステップＳ１０２はステップＳ１０４が続き、そこではカウンターｉが０に設定される。ステップＳ１０４はステップＳ１０６が続き、そこではカウンターｉがＭＢの総数より少ないかどうかの判定が行われる。その判定が「イエス」であるならば、ＦＳＥ処理１００は最初に符号化エンジン１６からステップＳ１０１Ａで各ＭＢについて符号化データを使用してステップＳ１０８でＭＢ[ｉ]の実際のビットストリーム詰込みを経過する。このように、シミュレーション・ビットストリームが造出される。ステップＳ１０８はステップＳ１１０が続き、そこではＭＢサイズ・アレイ[ｉ]がＭＢ[ｉ]のビットストリームのサイズに等しく設定される。ステップＳ１１０はステップＳ１１２が続き、そこでは現在のパケット・サイズは
current_packet_size += MB_Size_Array[i] または
current_packet_size = current_packet_size + MB_Size_Array[i]
として計算される。一般に、現在のパケット・サイズがリセットされるまで、その数式は各ＭＢ[ｉ] について現在のパケット・サイズを累算する。
【００４０】
ステップＳ１１２はステップＳ１１４が続き、そこでは推定フレーム・サイズが累算される。推定フレーム・サイズを計算するステップＳ１１４の数式は
estimated_frame_size += MB_Size_Array[i] または
estimated_frame_size += MB_Size_Array[i] + estimated_frame_size
として定義される。
【００４１】
ステップＳ１１４におけるこの推定フレーム・サイズは取得された実際のフレーム・サイズと数バイト差だけの非常に正確なフレーム・サイズを与える。この正確なフレーム・サイズ推定によって、後で詳細に述べられる（段階２）パケット数決定（ＮＰＤ）処理１３０においてパケットの数は確実にフレームについて生成される。
【００４２】
その上、（段階３）どれだけのビットが（おおよそ）生成されるかの推定においてビットストリームを詰込む間、この情報は使用されるパケット・サイズを再推定するビデオ・パケット化に役立つ。
【００４３】
再びＦＳＥ処理１００に戻ると、ステップＳ１１４はステップＳ１１６が続き、そこでは現在のスライス・サイズが目標パケット・サイズより大きい、或いは等しい（＞＝）かどうかの判定が行われる。このように、現在のスライス・サイズが目標パケット・サイズより大きいか、等しく（＞＝）、もしくはカウンターｉがＭＢの数以下（＜）になるまで、ステップＳ１０６、Ｓ１０８、Ｓ１１０、Ｓ１１２及びＳ１１４は繰返される。（最初の目標パケット・サイズＳ１０１Ｂは符号化エンジン１６から送られる。）
最初の目標パケット・サイズは符号化の前に指定／定義される。即ち、ユーザー／アプリケーションは、例えば、１２０バイトの目標サイズを指定する。最初の目標パケット・サイズの使用は段階１の間さらに正確なＦＳＥ処理１００を行う。段階１において、再同期マーカー（ＲＭ）挿入はＲＭがビットを含むのでフレーム・サイズ推定モジュールをさらに正確にするためである。さらに、ＲＭを挿入することによって、動きベクトル予測及び空間予測がスライス境界にわたって中断されねばならないので符号化処理は僅かに変更されるであろう。段階１におけるスライス決定は最終結果ではなく、むしろ段階３におけるビデオ・スライスが実際のビットストリームのアセンブリのためにフレーム・サイズ推定をいかに正確にするかというおおよその考え方（シミュレーション）である。
【００４４】
ステップＳ１１６に戻ると、ステップＳ１１６において判定が「ノー」であるならば、ＦＳＥ処理１００はステップＳ１２２においてカウンターｉを一（１）だけ更新し、そしてステップＳ１０６に戻り、そこでは推定フレーム・サイズは一以上のＭＢをビットストリームに詰込むことによってＭＢについて累算される。
【００４５】
逆に、判定が「イエス」（スライスまたパケット・サイズの終端）であるならば、ＦＳＥ処理１００はステップＳ１１８において再同期マーカー（ＲＭ）またはスライス・マーカーを挿入するであろう。ＲＭは次のＭＢの初めに挿入される。ステップＳ１１８はステップＳ１２０が続き、そこでは現在のパケット・サイズがゼロ（０）に等しく設定される。ステップＳ１２０はステップＳ１２２に続き、そこではカウンターｉは一（１）だけ増分され、そして詰込みを繰返すためにＳ１０６（図４Ａ）に戻る。そうでなければ、ステップＳ１０６において、判定が「ノー」（もはやＭＢを意味しない）であるならば、ＦＳＥ処理１００は終わる。
【００４６】
ここで図５に戻ると、（段階２）パケット数決定モジュール５０Ａによるパケット数決定（ＮＰＤ）処理１３０が説明される。ステップＳ１３１Ｂに示した最初の目標パケット・サイズはバイト単位で与えられ、そしてステップＳ１３１Ｃに示した推定フレーム・サイズは上の段階１において計算された。ステップＳ１３１Ａに示した構成は構成モードにおいてユーザー／アプリケーションによって設定される。その構成は帯域幅効率モード及び誤り回復モードを含む。ＮＰＤ処理１３０はステップＳ１３２と共に始まり、そこでは構成が帯域幅効率モードに同等である（＝）かどうかの判定が行われる。ステップＳ１３２の判定が「イエス」であるならば、ステップＳ１３２はステップＳ１３４が続き、そこではパケットの数が
number_of_packet =
FLOOR(estimated_frame_size / target_packet_size )；
によって定義され、ここでＦＬＯＯＲ関数は演算（）の結果を次の整数へ下方に丸める（四捨五入する）ことと同じである。ステップＳ１３４はステップＳ１４０が続き、そこでは新しい目標パケット・サイズが次式によって定義される：
new_target_packet_size = 
ROUND(estimated_frame_size / number_of_packet )；
ここでＲＯＵＮＤ関数は演算（）の結果を丸める。
【００４７】
一方、ステップＳ１３２の判定が「ノー」であるならば、ステップＳ１３２はステップＳ１３６が続き、そこでは構成が誤り回復モードに設定されるかどうかの判定が行われる。ステップＳ１３６において、判定が「イエス」であるならば、ステップＳ１３６はステップＳ１３８が続き、そこではパケットの数が
number_of_packet = 
ROUND(estimated_frame_size / target_packet_size )
によって定義される。ステップＳ１３８はステップＳ１４０が続き、そこでは上で述べたように新しい目標パケット・サイズが計算される。その後、ＮＰＤ処理は終わる。
【００４８】
さて、図６Ａ６Ｂに戻ると、（段階３）ビデオ・パケット化（ＶＰ）処理１５０が示されている。ＶＰ処理１５０においてデータは符号化エンジン１６によって符号化され、そして各ＭＢに関する符号化データとして送られたと仮定する。ステップＳ１５１Ｅに示した推定フレーム・サイズ及びＭＢサイズ・アレイＳ１５１Ｃは段階１におけるＦＳＥ処理１００から得られる。パケットの数Ｓ１５１Ｄ及び新しい目標パケット・サイズＳ１５１Ａは選択された構成モードについて段階２のＮＰＤ処理１３０において計算された。
【００４９】
ＶＰ処理１５０はステップＳ１５２において次のパラメータを初期化することで始まる：
current_packet_size = 0 ;
updated_packet_size = new_target_packet_size ;
accumulated_frame_size = 0 ;及び
packet_count = 0 。
【００５０】
ステップＳ１５２はステップＳ１５４が続き、そこではカウンターｉがゼロ（０）に設定される。ステップＳ１５４はステップＳ１５６が続き、そこではカウンターｉがＭＢの数より小さい（＜）かどうかの判定が行われる。ステップＳ１５６における判定が「イエス」であるならば、ステップＳ１５６はステップＳ１５８が続き、そこでは符号化データが現実のビットストリームに詰込まれる。ステップＳ１５８はステップ１６０が続き、そこでは現在のパケット・サイズは
current_packet_size +=上記からのMB[i]のサイズ；または
current_packet_size = current_packet_size + MB[i]のサイズ；
によって定義され；そしてステップＳ１６２における累計フレーム・サイズは
accumulated_frame_size += MB_Size_Array[i]；または
accumulated_frame_size = accumulated_frame_size + MB_Size_Array[i]
によって定義される。
【００５１】
ステップＳ１６２はステップＳ１６４が続き、そこでは
current_packet_size + (MB_Size_Array[i+1]/2) > 
updated_packet_size
であるかどうかの判定が行われ、ここでＭＢ_Ｓｉｚｅ_Ａｒｒａｙ[ｉ＋１]はＭＢ[ｉ＋１]として表される次のＭＢのサイズである。現在のパケット・サイズに次のＭＢ[ｉ＋１]のＭＢサイズ・アレイのサイズの一部を加えた結果は更新されたパケット・サイズと比較される。典型的な実施例では、ＭＢサイズ・アレイのサイズの一部は２分の１である。ステップＳ１６４の判定が「イエス」であるならば、ステップＳ１６４はステップＳ１６６が続き、そこでは
packet_count < number_of_packet -1
かどうかの判定が行われる。ステップＳ１６４及びステップＳ１６６のいずれか、または両方における判定が「ノー」であるならば、ステップＳ１６４またはＳ１６６はステップＳ１７６が続き、そこではカウンターｉは１だけ増分され、 そしてステップ１５８における次のＭＢ[ｉ]のビットストリームへの詰込みはカウンターｉがＭＢの全数（もはやＭＢを意味しない）より少なく（＜）ない限り継続する。
【００５２】
ステップＳ１６４及びステップＳ１６６のおける判定が両方とも「イエス」であるならば、ステップＳ１６６はステップＳ１６８が続き、そこでは再同期マーカー（ＲＭ）またはスライス・ヘッダーが挿入される。ステップＳ１６８はステップＳ１７０が続き、そこではパケット・サイズの更新が（更新パケット・サイズ）が計算され、そして
updated_packet_size = ( estimated_frame_size - accumulated_frame_size ) /
( number_of_packets - packet_count - 1 )
によって定義される。
【００５３】
ステップＳ１７０はステップＳ１７２が続き、そこでは現在のパケット・サイズがゼロ（０）に設定され、そしてステップＳ１７４において、パケット計数が１だけ増分される。ステップＳ１７４はステップＳ１７６が続き、そこではカウンターｉが増分される。ステップＳ１７６はステップＳ１５６（図６Ａ）に戻る。ステップＳ１５６における判定が「ノー」（もはやＭＢを意味しない）であるならば、 処理１５０は終わる。
【００５４】
方法２
第二の方法は段階１におけるビットストリーム詰込みが限られた計算能力のためにフレーム・サイズを推定するのに使用できないとき使用される。段階１におけるビットストリーム詰込みを通じて走らせる代りに、全体の非ゼロ係数の情報がフレーム・サイズ推定器モジュール４０Ｂにおいてフレーム・サイズを推定するために使用される。各ＭＢのサイズは未知であるから（方法１と異なる）、第二の方法はどれだけの非ゼロ係数（ＺＮＣ）が各ＭＢについて生成されるかの追跡を続け、そして一つのＭＢ予測をするためにこの情報を使用する。
【００５５】
ここで図７を参照すると、代わりのパケット交換ビデオ・アセンブラー３０'が示されている。フレーム・サイズ推定モジュール４０ＢはＮＺＣ数計算器１４２及びフレーム・サイズ推定器１４４を含む。ＮＺＣ数計算器１４２はどれだけのＮＺＣが符号化データを用いて符号化エンジン１６から生成されるかの追跡を続ける。最初の目標パケット・サイズはパケット数決定モジュール５０Ｂに送られる。推定フレーム・サイズはパケット数決定モジュール５０Ｂへフレーム・サイズ推定モジュール４０Ｂから送られる。さらに、ビデオ・パケット化モジュール６０Ｂは計算されたＭＢ ＮＣＺアレイをフレーム・サイズ推定モジュール４０Ｂから受取る。一方、パケット数決定モジュール５０Ｂはパケットの数及びバイト単位で新しい目標パケット・サイズをビデオ・パケット化モジュール６０Ｂへ提供する。
【００５６】
ここで図７を参照すると、フレーム・サイズ推定モジュール４０Ｂによって行われる（段階１）フレーム・サイズ推定（ＦＳＥ）処理２００が示されている。ＦＳＥ処理２００において、ビデオ入力系列は符号化エンジン１６によって符号化されていたと仮定される。ＦＳＥ処理２００は初期化ステップＳ２０２によって始まり、そこでは次のパラメータが初期化される：
MB_NCZ_Array[MBの総数] = 0； 
total_frame_NZC = 0；及び
estimated_frame_size = 0；
ここで総フレームＮＺＣはフレームにおけるＮＺＣの総数を得るために各ＭＢのＮＺＣの累算である。基本的に、それは全てのＭＢ_ＮＺＣ_Ａｒｒａｙ[ｉ]を加えることに等しい。
【００５７】
ステップＳ２０２はステップＳ２０４が続き、そこではパラメータ・アルファ（alpha）は
alpha =
(prev_fra m e_s ize - prev_non_texture_size)/
prev_total_frame_NZC
によって定義され、ここでprev_frame_sizeは前のフレームから生成された実際のサイズであり、prev_total_frame_NZCは前のフレームの総フレームＮＺＣであり、そしてprev_non_texture_sizeは前のフレームの非テクスチャー（non-texture）ＮＺＣである。さらに明確にいえば、現在のフレームに関するステップＳ２１４からの値は最初にステップＳ２１８及びＳ２７１で使用される。一旦、現在のフレームが完結し、且つ符号器が次のフレームに移動すると、ステップＳ２１４からのこの値はそのあと次のフレームに関するprev_total_frame_NZC として使用される。prev_non_texture_sizeの値は一旦現在のフレームが完結すると現在のフレームに関する図９ＡのステップＳ２６２における累算の非テクスチャー・サイズと同じである。このように、現在のフレームが完結しているとき、符号器は次のフレームに移動し、そしてステップＳ２６２からの値はprev_non_texture_sizeに使用されるであろう。
【００５８】
一般に、アルファはテクスチャー・ビットの比率であり、それはその内容及び非ゼロ係数（ＮＺＣ）計数である。アルファは比率及び非テクスチャー・ビットが前のフレームから同じであるという仮定に基づいてサイズ（estimated_frame_size ）を推定するのに使用される。下記で与えられる記述から分かるように、現在のフレームの総フレームＮＺＣはステップＳ２１４で計算されるであろう。このように、現在のフレームの総フレームＮＺＣは結果を形成するためにアルファで乗算される。その結果は現在のフレームについてステップＳ２１８（下記で述べる）においてフレーム・サイズを推定するためにステップＳ２６２で以前に累算されていた前のフレームの非テクスチャー・ビットに加算される。
【００５９】
ステップＳ２０４はステップＳ２０６が続き、そこではカウンターｉがゼロ（０）に設定される。ステップＳ２０６はステップＳ２０８が続き、そこではカウンターｉがＭＢの総数より少ないか否か（＜）の判定が行われる。判定が「イエス」であるならば、ステップＳ２０８はステップＳ２１０が続き、そこではＭＢ[ｉ]の非ゼロ係数（ＮＺＣ）の数が計算される。ステップＳ２０１で示した符号化ＭＢは符号化エンジン１６から提供される。ステップＳ２１０はステップＳ２１２が続き、そこでは
MB_NZC_Array[i] = MB[i]のＮＺＣの数 
である。ステップＳ２１２はステップＳ２１４が続き、そこでは
total_frame_NZC += MB_NZC_Array[i] または
total_frame_NZC = total_frame_NZC + MB_NZC_Array[i]
である。
【００６０】
ステップＳ２１４はステップＳ２１６が続き、そこではカウンターｉがＭＢより大きくなるまで、カウンターｉは１だけ増分され、そしてステップＳ２０８に戻る。ステップＳ２０８における判定が「ノー」（もはやＭＢを意味しない）であるならば、ステップＳ２０８はステップＳ２１８が続き、そこでは推定フレーム・サイズが決定され、そして
estimated_frame_size = alpha*total_frame_NZC + prev_non_texture_size
によって定義される。その後、ＦＳＥ処理は終わる。
【００６１】
方法２において、 （段階２）パケット数決定（ＮＰＤ）処理は図５で説明したＮＰＤ処理１３０と同じである。しかしながら、推定フレーム・サイズは図８のステップＳ２１８で計算された推定フレーム・サイズである。
【００６２】
ここで図９を参照して（段階３）ビデオ・パケット化（ＶＰ）処理２５０が述べられる。各ＭＢの符号化データはステップＳ２５１Ｂで提供される。ステップＳ２５１ＣにおけるＭＢ ＮＺＣアレイ及びステップＳ２５１Ｅにおける総フレームＮＺＣは段階１（図８）またはフレーム・サイズ推定モジュール４０Ｂから提供される。ステップＳ２５１Ｄにおけるパケットの数及びステップＳ２５１Ａにおける新しい目標パケット・サイズは段階２（図５）またはパケット数決定モジュール５０Ｂから提供される。ＶＰ処理２５０はステップＳ２５２で始まり、そこでは次のパラメータが初期化される：
current_packet_size = 0；
updated_packet_size = new_target_packet_size；
accumulated_frame_nzc = 0；
accumulated_non_texture_size = 0；
packet_count = 0。
【００６３】
ステップＳ２５２はステップＳ２５４が続き、そこではカウンターｉがゼロ（０）に設定される。ステップＳ２５４はステップＳ２５６が続き、そこではカウンターｉがＭＢの数より少ないか否か（＜）の判定が行われる。ステップＳ２５６における判定が「イエス」であるならば、ステップＳ２５６はステップＳ２５８（見かけ的に示される）が続き、そこでは符号化データがビットストリームに詰込まれる。ステップＳ２５８は詰込みがパケット交換ビデオ・アセンブラー３０' によって行われず、符号化エンジン１６において行われることを示すために見かけ的に示される。ステップＳ２５８はステップＳ２６０が続き、そこでは現在のパケット・サイズは
current_packet_size + = 上記からのMB[i] のサイズ
によって定義され、そしてステップＳ２６２における累算された非テクスチャー・サイズは
accumulated_non_texture_size + = MB[i] の非テクスチャーのサイズ
によって定義される。
【００６４】
ステップＳ２２はステップＳ２６４が続き、そこでは累算フレームＮＺＣは
accumulated_frame_NZC += MB NZC Array[i]
によって定義され、ここでMB NZC Array[ｉ] はステップＳ２５１Ｃにおいて段階１から示される。
【００６５】
ステップＳ２６４はステップＳ２６６が続き、そこでは
(current_packet_size + (MB_NZC_Array[i+1]*8/2)) > updated_packet_size
か否かの判定が行われ、ここでMB NZC array[i+1]はＭＢ[ｉ+１]として表される次のＭＢにおけるＮＺＣの数である。ステップＳ２６６における判定が「イエス」であるならば、ステップＳ２６６はステップＳ２６８が続き、そこでは
packet_count < number_of_packets -1
か否かの判定が行われる。ステップＳ２６６及びステップＳ２６８のいずれか、または両方における判定が「ノー」であるならば、ステップＳ２６６またはＳ２６８はステップＳ２８０が続き、そこではカウンターｉは１だけ増分され、 そしてステップＳ２５８における次のＭＢ[ｉ]のビットストリームへの詰込みはカウンターｉがＭＢの総数（もはやＭＢを意味しない）より少なく（＜）ない限り継続する。
【００６６】
ステップＳ２６６及びステップＳ２６８のおける判定が両方とも「イエス」であるならば、ステップＳ２６８はステップＳ２７０が続き、そこでは再同期マーカー（ＲＭ）またはスライス・ヘッダーが挿入される。ステップＳ２７０はステップＳ２７２が続き、そこでは残りのフレーム・サイズが計算され、そして
remaining_frame_size =
alpha*(total_frame_NZC - accumulated_frame_NZC) +
max(prev_non_texture_size - accumulated_non_texture_size), 0))
によって定義され、ここでaccumulated_non_texture_sizeはどれだけのバイトが非テクスチャー部分で生成され、従って更新されたかの計数である。時折、累算非テクスチャー・サイズは前のフレームの非テクスチャー計数（prev_non_texture_size）より大きい。前のフレームの非テクスチャー計数またはサイズからの累算非テクスチャー・サイズの減算はよくない結果をもたらす。この状態が起こるとき、その結果は例えばｍａｘ演算を使用することによってゼロ（０）に設定される。
【００６７】
ステップＳ２７２はステップＳ２７４が続き、そこでは更新されたパケット・サイズが計算され、そして
updated_packet_size = remaining_frame_size /
(number_of_packets - packet_count - 1 );
によって定義される。
【００６８】
ステップＳ２７４はステップＳ２７６が続き、そこでは現在のパケット・サイズがゼロ（０）に設定され、そしてステップＳ２７８において、パケット計数が１だけ増分される。ステップＳ２７８はステップＳ２８０が続き、そこではカウンターｉが増分される。ステップＳ２８０はステップＳ２５６（図９Ａ）に戻る。ステップＳ２５６における判定が「ノー」（もはやＮＢを意味しない）であるならば、処理２５０は終わる。他の場合には、ステップＳ２５８において符号化データを詰込んで始まる処理が繰返される。
【００６９】
方法３
第三の方法は符号化エンジンによる符号化処理の間にビデオ・パケット化を実行する。従って、第三の方法は符号化処理の最中にビデオ・パケットを急いで（on-the-fly）作成する所を決定する必要がある。第三の方法はビットストリーム詰込みが符号化処理と共に行われなければならないとき、特に適している。同様に、それはスライスが作成されなければならないが、 内部予測ができなくされるとき、Ｈ．２６３及びＨ．２６４フォーマットについて使用される。
【００７０】
（段階１）ＦＳＥ処理３００において、非ゼロ係数（ＮＺＣ）の数は方法２と同様に前もって知られていない。このように、符号化が始まる前に、ＦＳＥ処理３００は「所望の総ＮＺＣ」に依存する。同様に、各ＭＢのＮＺＣは前もって知られていないので、予測は停止される。
【００７１】
図１０に、パケット・ビデオ・アセンブラー３０" の代わりの実施例が示されている。フレーム・サイズ推定モジュール４０Ｃは符号化エンジン１６中のレート制御器（示されない）によって提供される所望の総フレームＮＺＣを受取り、レート制御器はフレームが符号化される前にフレーム・サイズを決定する。フレーム・サイズはそれから所望のフレームＮＺＣに変換される。初めに、この所望のフレームＮＺＣは同じＮＺＣのフレームを生成するために符号化処理に導くために使用される。（我々はさらにこの発明にその情報を使用する。）フレーム・サイズ推定モジュール４０Ｃはパケット数決定モジュール５０Ｃに送られる推定フレーム・サイズを決定する。同じくフレーム・サイズ推定モジュール４０Ｃはまたパケット数決定モジュール５０Ｃ及びビデオ・パケット化モジュール６０Ｃの両方に送られる総フレームＮＺＣを決定する。パケット数決定モジュール５０Ｃは最初の目標パケット・サイズを受取り、そして目標パケットＮＺＣ及びパケットの数をビデオ・パケット化モジュール６０Ｃに出力する。
【００７２】
ここで図１１を参照すると、（段階１）フレーム・サイズ推定（ＦＳＥ）処理３００がここで述べられる。所望の総フレームＮＺＣのパラメータはステップＳ３０１Ａで提供される。ＦＳＥ処理３００はステップＳ３０２で始まり、そこではアルファは
alpha=
prev_frame_size - prev_non_texture_size)/prev_total_frame_NZC
として計算され、ここでprev_frame_size、prev_total_frame_NZCは前のフレームについて決定される。パラメータのアルファは以前に述べられた。ステップＳ３０２はステップＳ３０が続き、そこでは
desired_total_frame_NZC < max QP を使用するframe_NZC
であるか否かの判定が行われ、ここでＱＰは量子化パラメータまたはＭＢの量子化ステップ・サイズである。
【００７３】
所望の総フレームＮＺＣは符号化エンジン１６における符号化処理に導くための目標であることを注目すべきである。所望の総フレームＮＺＣを生成するために、各ＭＢの量子化パラメータ（ＱＰ）は変化する。しかしながら、最大許容ＱＰ（例えば、ＭＰＥＧ４及びＨ．２６３ビデオ符号化規格では３１、そしてＨ．２６３規格では５２）が使用されるときさえ、所望の総フレームＮＺＣがまだ満たされるない状況がある。その代りに、さらに多くのＮＺＣが存在する。そのような場合には、各ＭＢに使用されるＱＰは最大になるであろう。その結果、所望の総フレームＮＺＣは使用されない。その代りに、符号化規格では最大許容ＱＰを使用する総フレームＮＺＣが使用される。この情報はフレーム解析をすることによって通常利用可能である。
【００７４】
再びステップＳ３０４に戻って、ステップＳ３０４における判定が「イエス」であるならば、ステップＳ３０４はステップＳ３０６が続き、そこでは総フレームＮＺＣは
total_frame_nzc = max QPを使用するframe_nzc
として計算される。ステップＳ３０６はＳ３０８が続き、そこでは推定フレーム・サイズは
estimated_frame_size = alpha* desired_total_frame_nzc + 
prev_non_texture_size
に基づいて計算される。
【００７５】
再びステップＳ３０４に戻って、ステップＳ３０４における判定が「ノー」であるならば、ステップＳ３０４はステップＳ３０８が続き、そこでは推定フレーム・サイズが計算される。ステップＳ３０８の後、処理３００は終わる。
【００７６】
図１２を参照して、パケット数決定モジュール５０Ｃ（図１５Ｂ）によって行われる（段階２）パケット数決定（ＮＰＤ）処理３３０が示される。ステップＳ３３１Ｂに示したバイト単位で目標パケット・サイズが与えられ、そしてステップＳ３３１Ｃに示した推定フレーム・サイズはステップＳ３０８で段階１において計算された。ステップＳ３３１Ａに示した構成は構成モードによって設定される。その構成は帯域幅効率モード及び誤り回復モードを含む。ＮＰＤ処理３３０はステップＳ３３２で始まり、そこでは構成＝帯域幅効率モードであるか否かの判定が行われる。ステップＳ３３２の判定が「イエス」であるならば、ステップＳ３３２はステップ３３４が続き、そこではパケットの数は
number_of_packets = 
FLOOR(estimated_frame_size / target_packet_size )
によって定義され、ここでＦＬＯＯＲ関数は演算（）の結果を次の整数に下方に丸める（四捨五入する）ことと同じである。ステップＳ３３４はステップ３３６が続き、そこでは目標パケットＮＺＣは目標パケットＮＺＣ調整器１５４によって計算され、そして
target_packet_NZC =
ROUND(total_frame_NZC / number_of_packets )
によって定義され、ここでＲＯＵＮＤ関数は演算（）の結果の丸め（四捨五入）である。
【００７７】
一方、ステップＳ３３２における判定が「ノー」であるならば、ステップＳ３３２はステップ３３６が続き、そこではその構成が誤り回復モードに設定されるか否かの判定が行われる。ステップ３３６における判定が「イエス」であるならば、ステップＳ３３６はステップ３３８が続き、そこではパケットの数がパケット数計算器１５２よって計算され、そして
number_of_packets = 
ROUND(estimated_frame_size / target_packet_size)
によって定義される。ステップＳ３３８はステップ３４０が続き、そこでは目標パケットＮＺＣが前に述べたように計算される。その後、ＮＰＤ処理は終わる。
【００７８】
ここで図１３Ａ及び１３Ｂを参照して、（段階３）ビデオ・パケット化（ＶＰ）処理３５０がここに詳細に述べられる。総フレームＮＺＣ Ｓ３５１Ｂは段階１（図１１）またはフレーム・サイズ推定モジュール４０Ｃから提供される。ステップＳ３５１Ｃにおけるパケットの数及びステップＳ３５１Ａにおける目標パケットＮＺＣは段階２またはパケット数決定モジュール５０Ｃから提供される。ＶＰ処理３５０はステップＳ３５２で始まり、次のパラメータが初期化される： 
current_packet_NZC = 0；
updated_packet_NZC = target_packet_NZC；
accumulated_frame_NZC = 0；及び
packet_count = 0。
【００７９】
ステップＳ３５２はステップ３５４が続き、そこではカウンターｉがゼロ（０）に設定される。ステップＳ３５４はステップＳ３５６が続き、そこではカウンターｉがＭＢの数より小さい（＜）か否かの判定が行われる。ステップＳ３５６における判定が「イエス」であるならば、ステップＳ３５６はステップＳ３５８（見かけ的に示される）が続き、そこではＭＢ[ｉ]が符号化エンジン１６によって符号化され、そして非ゼロ係数（ＮＺＣ）の数が計算される。ステップＳ３５８はステップＳ３５９（見かけ的に示される）が続き、そこではＭＢ[ｉ] の符号化データが符号化エンジン１６によってビットストリームに詰込まれる。ステップＳ３５８及びＳ３５９は符号化及び詰込みがパケット交換ビデオ・アセンブラー３０" によって行われず、符号化エンジン１６において行われることを示すために見かけ的に示される。ステップＳ３５９はステップＳ３６０が続き、そこでは累算フレームＮＺＣが
accumulated_frame_NZC + = MB[i]のNZCの数；または
accumulated_frame_NZC + = accumulated_frame_NZC + 
MB[i]のNZCの数
によって定義される。
【００８０】
ステップＳ３６０はステップＳ３６１が続き、そこでは現在のパケットＮＺＣが
current_packet_NZC + = MB[i]のNZCの数；または
current_packet_NZC + = current_packet_NZC +
MB[i]のNZCの数
によって計算されるステップＳ３６１はステップＳ３６２が続き、そこでは
current_packet_NZC > updated_packet_NZC
であるか否かの判定が行われる。ステップＳ３６２における判定が「イエス」であるならば、ステップＳ３６２はステップＳ３６４が続き、そこでは
packet_count < number_of_packets -1
であるか否かの判定が行われる。ステップＳ３６２及びステップＳ３６４のいずれか、または両方における判定が「ノー」であるならば、ステップＳ３６２またはＳ３６４はステップＳ３７６が続き、そこではカウンターｉは１だけ増分され、 そしてステップＳ３５８における次のＭＢ[ｉ]の符号化は、ＮＺＣ係数の計算と同様に、カウンターｉがＭＢの総数（もはやＭＢを意味しない）より小さく（＜）ない限り継続する。
【００８１】
ステップＳ３６２及びステップＳ３６４における判定が両方「イエス」であるならば、ステップＳ３６４はステップＳ３６６が続き、そこでは再同期マーカー（ＲＭ）またはスライス・ヘッダーが挿入される。ステップＳ３６６はステップＳ３６８が続き、そこでは残りのフレームＮＺＣが計算され、そして
remaining_frame_size = 
frame_NZC - accumulated_frame_NZC
によって定義される。
【００８２】
ステップＳ３６８はステップＳ３７０が続き、そこでは更新されたパケットＮＺＣが計算され、そして
updated_packet_NZC = remaining_frame_NZC /
(number_of_packets - packet_count - 1) 
によって定義される。
【００８３】
ステップＳ３７０はステップＳ３７２が続き、そこでは現在のパケットＮＺＣがゼロ（０）に設定され、そしてパケット計数が１だけ増分される。ステップＳ３７４はステップＳ３７６が続き、そこではカウンターｉが増分される。ステップＳ３７６はステップＳ３５６（図１３Ａ）に戻る。ステップＳ３５６における判定が「ノー」（もはやＭＢを意味しない）であるならば、処理３５０は終わる。
【００８４】
シミュレーション結果
図１７Ａ−１７Ｄは元の方法（図１７Ａ）、方法１（図１７Ｂ）、方法２（図１７Ｃ）、及び方法３（図１７Ｄ）によるカルフォーン系列（Carphone sequence）を使用してシミュレーション結果を例示する。シミュレーション結果は方法１、２及び３の有効性を例示する。パケット・サイズが所定のパケット・サイズを越えるとき、元の方法はビデオ・パケットを作成する。シミュレーション結果は多くの小さなパケットが生成されることを示す。いくつかの小さなパケットは１０バイトより小さいサイズを持つ。このように、帯域幅は非常に浪費される。
【００８５】
方法１については、シミュレーション結果におけるパケット・サイズは殆どが１２０バイト程度である。その変動は１００バイトから１５０バイトの間である。これはフレーム・サイズが通常は１２０バイトの倍数でないからである。例えば、フレーム・サイズが４００バイトのとき３個の１２０バイト・パケットと１個の４０バイト・パケットの代わりに３個の１３３バイト・パケットを持つことがさらに良い。４０バイトのオーバーヘッドを持つ残りの４０バイトを保護することはあまり意味をなさない。
【００８６】
方法２については、フレーム・サイズはＮＺＣを用いて推定されるので、方法１におけるほど正確ではない。しかしながら、その精度はパケット・サイズ分布が方法１と非常に類似するように十分まだ適正である。さらに、方法２について、計算の複雑さは帯域幅効率パケット化を行っているかぎり減少する。方法３について、ビデオ・パケット化がパケット・サイズを計算することによってできないので、分布はさらに広くなる。その決定はＮＺＣ領域で行われる。しかしながら、方法３に関してさえも、元の方法と比較したとき、小さなパケットの造出は減少する。
【００８７】
表１は各方法について生成されたパケットの数を示すシミュレーション結果の説明である。
【表１】
2010505367.tif 000003
【００８８】
ここに示した３−段階処理及びデバイスはパケットの数を減少させ、且つ帯域幅利用を向上させることが当業者に理解されるであろう。さらに、３−段階処理はビデオ・フレームを（おおまかに）等しいサイズのパケットに分割し、そして動的にパケット・サイズを更新する。
【００８９】
発明の実施例の前述の説明は例示及び説明の目的のために提示されてきた。それは完全であること、及び開示された明確な形態に発明を制限することを意図するものではなく、そして変更及び変形は前述の教示を考慮して可能であり、或いは発明の実施から取得される。その実施例は考慮される特定の使用に適している様々な実施例において、及び様々な変更によって当業者が発明を利用することができる発明の原理及びその実際のアプリケーションを説明するために選択され、且つ記述された。発明の範囲はここに付随した請求項及びそれと同等なものによって規定されることが望まれる。
【００９０】
Appendix
Pseudo Code Approach 1
Stage 1: Frame Size Estimation
Given:
Target_Packet_Size in bytes
Encoded data for each MB such as motion vectors and quantized coefficients
Initialize:
MB_Size_Array[total number of MB] to be zero
current_packet_size = 0;
estimated_frame_size = 0;
Frame Size Estimation Algorithm:
For (i=0; i<total number of MB; i++)
{
Pack the encoded data of MB[i] into bitstream
MB_Size_Array[i] = the size of the bitstream of MB[i]
current_packet_size += MB_Size_Array[i] ;
estimated_frame_size += MB_Size_Array[i] ;
If (the current slice size >= Target_Packet_Size)
{
Insert a Resynchronization Marker or Slice header;
current_packet_size = 0;
}
}
Stage 2: Number of Packets Determination
Given:
Target_Packet_Size in bytes
estimated_frame_size from Step 1
configuration (bandwidth efficient or error resilient mode)
Number of Packet Determination Algorithm:
If (configuration == bandwidth efficient mode)
{
number_of_packet =
FLOOR(estimated_frame_size / target_packet_size);
}
Else if (configuration == error resilient mode)
{
number_of_packet =
ROUND(estimated_frame_size / target_packet_size);
}
new_target_packet_size =
ROUND(estimated_frame_size / number_of_packet);
Stage 3: Video Packetization
Given:
Encoded data for each MB
estimated_frame_size from Step 1
MB_Size_Array  from Step 1
number_of_packet  from Step 2
new_target_packet_size  from Step 2
Initialize:
current_packet_size = 0;
updated_packet_size = new_target_packet_size;
accumulated_frame_size = 0;
packet_count = 0;
Video Packetization Algorithm:
For (i=0; i<total numberof MB; i++)
{
Pack the encoded data of MB[i] into bitstream
current_packet_size += size of MB[i] from above;
accumulated_frame_size += MB_Size_Array[i];(NOTE:from Step 1)
If ((current_packet_size + (MB_Size_Array[i+1 ]/2)) >
updated_packet_size) &&
(packet_count < number_of_packet -1 ))
{
Insert a Resynchronization Marker or Slice header;
updated_packet_size=(estimated_frame_size
-            accumulated_frame_size) /
(number_of_packet - packet_count - 1);
current_packet_size = 0;
packet_count += 1 ;
}
Pseudo Code Approach 2
Stage 1: Frame Size Estimation
Given:
Encoded data for each MB
Initialize:
MB_NCZ_Array[total number of MB] to be zero
total_frame_NZC = 0;
estimated_frame_size = 0;
alpha=
(prev_frame_size - prev_non_texture_size)/prev_total_frame_NZC ;
Frame Size Estimation Algorithm:
For (i=0; i<total number of MB; i++)
{
Calculate the number of non-zero coefficient for MB[i];
MB_NZC_Array[i] = the NZC of MB[i];
total_frame_NZC += MB_NZC_Array[i];
}
estimated_frame_size
= alpha*total_frame_NZC + prev_non_texture_size;
Stage 2: Number of Packet Determination
Given:
target_packet_size in bytes
estimated_frame_size from Step 1
configuration (bandwidth efficient or error resilient mode)
Number of Packet Determination Algorithm:
If (configuration == bandwidth efficient mode)
{
number_of_packet =
FLOOR(estimated_frame_size / target_packet_size);
}
Else if (configuration == error resilient mode)
{
number_of_packet =
ROUND(estimated_frame_size / target_packet_size);
}
new_target_packet_size =
ROUND(estimated_frame_size / number_of_packet);
Stage 3: Video Packetization
Given:
Encoded data for each MB
MB_NZC_Array   from Step 1
total_frame_nzc  from Step 1
number_of_packet  from Step 2
new_target_packet_size  from Step 2
Initialize :
current_packet_size = 0;
updated_packet_size = new_target_packet_size;
accumulated_frame_nzc = 0;
accumulated_non_texture_size = 0;
packet_count = 0;
Video Packetization Algorithm:
For (i=0; i<total numberof MB; i++)
{
Pack the encoded data of MB[i] into bitstream
current_packet_size += size of MB[i] from above;
accumulated_non_texture_size+=size of non-texture of MB[i]; 
accumulated_frame_NZC += M B_NZC_Array[i] ;
If ((current_packet_size + (MB_NZC_Array[i+1 ]*8/2)) > 
updated_packet_size) &&
(packet_count < number_of_packet -1 ))
{
Insert a Resynchronization Marker or Slice header;
remaining_frame_size =
alpha*(total_frame_nzc- accumulated_frame_NZC) +
max(prev_non_textu re_s ize -
accumulated_non_texture_size), 0));
updated_packet_size = remaining_frame_size /
(number_of_packet - packet_count - 1 );
current_packet_size = 0;
packet_count += 1 ;
}
}
Pseudo Code Approach 3
Stage 1: Frame Size Estimation
Given:
desired_total_frame_nzc
Initialize:
alpha=
(prev_frame_size - prev_non_texture_size)/prev_tota l_frame_NZC ;
Frame Size Estimation Algorithm:
If (desired_total_frame_nzc < frame_nzc using max QP)
{
total_frame_nzc = frame_nzc using max QP;
}
estimated_frame_size = alpha* desired_total_frame_nzc +
prev_non_texture_size;
Stage 2: Number of Packet Determination
Given:
target_packet_size in bytes
estimated_frame_size from Step 1
total_frame_nzc from Step 1
configuration (bandwidth efficient or error resilient mode)
Number of Packet Determination Algorithm:
If (configuration == bandwidth efficient mode)
{
number_of_packet =
FLOOR(estimated_frame_size / target_packet_size);
}
Else if (configuration == error resilient mode)
{
number_of_packet =
ROUND(estimated_frame_size / target_packet_size);
}
target_packet_nzc = ROUND(total_frame_nzc / number_of_packet);
Stage 3: Video Packetization
Given:
Encoded data for each MB
total_frame_nzc  from Step 1
number_of_packet  from Step 2
target_packet_nzc  from Step 2
Initialize:
updated_packet_nzc = target_packet_nzc;
current_packet_nzc = 0;
accumulated_frame_nzc = 0;
packet_count = 0;
Video Packetization Algorithm:
For (i=0; i<total number of MB; i++)
{
Encode MB[i] and calculate number of non-zero coefficients;
Pack the encoded data of MB[i] into bitstream;
accumulated_frame_NZC += number of nzc of MB[i] from above;
current_packet_nzc += number of nzc of MB[i];
If ((current_packet_nzc > updated_packet_nzc) &&
(packet_count < number_of_packet -1 ))
{
Insert a Resynchronization Marker or Slice header;
remaining_frame_nzc = total_frame_nzc - accumulated_frame_NZC; 
updated_packet_nzc = remaining_frame_nzc /
(number_of_packet - packet_count - 1 );
current_packet_nzc = 0;
packet_count + = 1 ; 
}
}
【図１Ａ】
2010505367.tif 000004
【図１Ｂ】
2010505367.tif 000005
【図２】
2010505367.tif 000006
【図３】
2010505367.tif 000007
【図４Ａ】
2010505367.tif 000008
【図４Ｂ】
2010505367.tif 000009
【図５】
2010505367.tif 000010
【図６Ａ】
2010505367.tif 000011
【図６Ｂ】
2010505367.tif 000012
【図７】
2010505367.tif 000013
【図８】
2010505367.tif 000014
【図９Ａ】
2010505367.tif 000015
【図９Ｂ】
2010505367.tif 000016
【図１０】
2010505367.tif 000017
【図１１】
2010505367.tif 000018
【図１２】
2010505367.tif 000019
【図１３Ａ】
2010505367.tif 000020
【図１３Ｂ】
2010505367.tif 000021
【図１４Ａ】
2010505367.tif 000022
【図１４Ｂ】
2010505367.tif 000023
【図１５Ａ】
2010505367.tif 000024
【図１５Ｂ】
2010505367.tif 000025
【図１６】
2010505367.tif 000026
【図１７Ａ】
2010505367.tif 000027
【図１７Ｂ】
2010505367.tif 000028
【図１７Ｃ】
2010505367.tif 000029
【図１７Ｄ】
2010505367.tif 000030
【国際調査報告】
2010505367.tif 000031
2010505367.tif 000032