JP2008511261A - 効率的なビデオスライシング - Google Patents

Abstract

【解決手段】本開示は、複雑さの低減、帯域幅効率化、および誤り回復力を促進するビデオスライシング技術に向けられる。ビデオエンコーダは、ＲＭを、各論理送信ユニット（ＬＴＵ）の開始近くに配置する。これによって、各ビデオスライスの非常に小さな終了セグメントの殆どが、ＬＴＵ内に実質的に適合するようになる。ＬＴＵ境界における正確なＲＭの配置を必要とするのではなく、ビデオエンコーダは、近似アラインメント技術を適用する。ＲＭが、各ＬＴＵの開始近く、例えばＬＴＵ内の最初のＭＢの終わりに配置できるようにビデオスライスは符号化される。前のスライスからの最後のＭＢの一部は、次のＬＴＵへ移る。実際、ＬＴＵの損失は、現在のスライス全体に、前のスライスの極く一部を加えたものの損失となる。
【選択図】 図２

Description

本開示は、デジタルビデオ符号化に関し、特に、デジタルビデオフレームをスライスする技術に関する。

典型的なビデオエンコーダ実装では、送信中のデータ損失のインパクトを低減するために、エンコーダ側において、デジタルビデオフレームがビデオスライスへ分割される。ビデオスライスはそれぞれ独立して符号化されて復号される。誤りが検出される場合、デコーダは、破壊されたスライス内に、全てマクロブロック（ＭＢ）を隠蔽（conceal）する。隠蔽は、誤って復号されたＭＢの表示及び伝搬を防ぐ。そうしなければ、ユーザへ表示されるビデオの品質が低下しうる。

ビデオスライスは、一般に、誤りが検知された場合、同期を再設定するためにデコーダによって使用される再同期マーカ（ＲＭ：resynchronization marker）を用いて開始される。データ損失を最小にするために、ビデオスライスは、理想的には、ビデオ伝送システム内の最も少ない損失単位に相当する。この最も少ない損失単位は、通信チャンネルを介して送信される最も小さな情報単位である。無線システムでは、この最も小さな損失単位は、論理送信ユニット（ＬＴＵ：logical transmission unit）と呼ばれる。それは固定長又は可変長を持つ。

ビデオスライスがそれぞれＬＴＵのサイズならば、ＬＴＵ損失による如何なる誤りも、他のスライスに影響を与えずに、損失スライス内に局在化されるだろう。しかしながら、ビデオスライスとＬＴＵとの間の正確なアライメントを達成するのは難しい。特に、ＲＭは、ＭＢ境界にのみ配置することができ、ビデオフレーム内に任意に配置することはできない。その結果、エンコーダが、与えられたＬＴＵ内で正確に適合するようにスライスサイズを調節することは難しい。

ＬＴＵスライスアライメント用の１つの技術は、ＭＢの量子化ステップサイズを調節し、スライス長を調節するスライスレベルレート制御を含む。不運にも、この技術は、エンコーダ設計に著しい複雑さを加え、かつ必ずしも正確ではない。他の技術は、そのサイズが予め定めた長さを超えるまでスライスを符号化することと、次に、符号化されたビデオの終わりと、ＬＴＵの終わりとの間にパディングバイトを加えることとを含む。しかしながら、このアプローチは、帯域幅効率を低下させる。

本出願は、２００４年８月２３日に出願され、その全ての内容が参照により本明細書に組み込まれている米国仮出願６０／６０３，９７８号の利益を要求する。

一般に、本開示は、複雑さの低減、帯域幅効率化、及びおよび誤り回復力を促進するビデオスライシング技術に向けられる。この技術によれば、ビデオエンコーダは、ＲＭを、各論理送信ユニット（ＬＴＵ）の開始近くに配置する。これによって、各ビデオスライスの非常に小さな終了セグメントの殆どが、ＬＴＵ内に実質的に適合するようになる。

ビデオスライス及びＬＴＵの厳密なアライメントに要求されるような、ＬＴＵの開始における正確なＲＭ配置を必要とするのではなく、ビデオエンコーダは、近似アラインメント技術を適用する。この技術によれば、ＲＭが、各ＬＴＵの開始近く、例えばＬＴＵ内の最初のＭＢの終わりに配置できるようにビデオスライスは符号化される。よって、前のスライスからの最後のＭＢの一部は、次のＬＴＵ上へ移る。この場合、ＬＴＵの損失は、スライス全体に、前のスライスの極く一部、例えば１ＭＢを加えた損失となる。

前のスライスのように、損失したスライスの極く僅かな部分、例えば１ＭＢが次のＬＴＵへ運ばれるだろう。しかしながら、その部分は復号に使用されないだろう。この近似アラインメント技術は、正確なアライメント技術に比べて、損失データ内に単に１つのＭＢを追加するだけで、複雑さを著しく低減して達成することができる。ＬＴＵ境界にＲＭを正確に配置するか、あるいはＭＢ量子化ステップのスライスレベル制御を提供する必要性はない。これによって、複雑さを低減することができる。更に、スライス内にバイトをパディングする必要もない。これによって、帯域幅効率化を図ることができる。

１つの実施形態では、本開示はビデオ符号化方法を記述する。この方法は、論理送信ユニット（ＬＴＵ）のサイズを決定することと、ＬＴＵサイズと等価な目標ビデオスライスサイズを生成することと、そのサイズが、前記目標ビデオスライスサイズよりも大きくなるまで第１のビデオスライスを符号化することとを含む。この方法は更に、第１のビデオスライスのサイズと、目標ビデオスライスサイズとの差を判定するここと、第１のビデオスライスの終わりに再同期マーカ（ＲＭ）を挿入することと、目標ビデオスライスサイズを、ＬＴＵサイズから前記差を引いたものに等しくなるように更新することと、第２のビデオスライスを、そのサイズが、更新された目標ビデオスライスサイズよりも大きくなるまで符号化することとを含む。本開示はまた、そのような方法をプロセッサに実行させる命令を含むコンピュータ読取可能媒体を意図する。

別の実施形態では、本開示は、論理送信ユニット（ＬＴＵ）のサイズを推定する論理送信ユニット（ＬＴＵ）サイズ推定モジュールと、目標ビデオスライスサイズを決定するスライスサイズ決定モジュールと、目標ビデオスライスサイズよりもそのサイズが大きくなるまで第１のビデオスライスを符号化し、第１のビデオスライスのサイズと、目標ビデオスライスサイズとの差を判定するビデオスライスジェネレータと、第１のビデオスライスの終わりに、再同期マーカ（ＲＭ）を挿入することとを備えるビデオ符号化システムを記述する。スライスサイズ決定モジュールは、ＬＴＵサイズからこの差を引いたものに等しくなるように目標ビデオスライスサイズを更新する。ビデオスライスジェネレータは、更新された目標ビデオスライスサイズよりもそのサイズが大きくなるまで第２のビデオスライスを符号化する。

更なる実施形態では、本開示は、デジタルビデオフレームをビデオスライスへ分割することと、各スライスの第１の部分が１つの第１の物理レイヤ論理送信ユニット（ＬＴＵ）内に存在し、高々１マクロブロック（ＭＢ）のサイズを持つ各スライスの第２の部分が第２の物理レイヤＬＴＵ内に存在するようにスライスの各々をサイジングすることとを含むビデオ符号化方法を記述する。

１つ又は複数の実施形態の詳細が、添附図面及び下記記述において説明される。他の特徴、目的および長所は、この記述と図面、及び特許請求の範囲から明白になるであろう。

図１は、ビデオ符号化及び復号システム１０を図示するブロック図である。図１に示すように、システム１０は、伝送チャネル１６によって接続されたエンコーダシステム１２とデコーダシステム１４とを含む。エンコーダシステム１２は、マルチプレクサ（ＭＵＸ）１８、ビデオエンコーダ２０、およびオーディオエンコーダ２２を含む。デコーダシステム１４は、デマルチプレクサ（ＤＥＭＵＸ）２６、ビデオデコーダ２８、およびオーディオデコーダ３０を含む。

システム１０は、例えばビデオ電話通信のために、双方向ビデオ送信を提供しうる。従って、相反する符号化と復号、ＭＵＸとＤＥＭＵＸの各コンポーネントが、チャネル１６の反対端上で提供されうる。いくつかの実施形態では、エンコーダシステム１２およびデコーダシステム１４は、ビデオストリーミング、ビデオ電話通信あるいはその両方のために装備された無線モバイル端末のようなビデオ通信デバイス内で具体化されうる。モバイル端末は、国際電気通信連合Ｈ．３２４Ｍ規格、あるいはＲＴＰ／ＵＤＰ／ＩＰのような他の規格に従ってビデオ電話通信をサポートする。

ビデオエンコーダ２０は、ＭＰＥＧ−４のような画像圧縮方法によって符号化されるビデオデータを生成する。国際電気通信連合（ＩＴＵ）Ｈ．２６３、ＩＴＵ Ｈ．２６４あるいはＭＰＥＧ２方法のような他の画像圧縮方法が使用されてもよい。オーディオエンコーダ２２は、ビデオデータを伴うオーディオデータを符号化する。

ＭＵＸ １８は、ビデオエンコーダ２０およびオーディオエンコーダ２２から適応レイヤビデオユニットおよびオーディオデータユニットを得る。ＭＵＸ １８は、ビデオデータおよびオーディオデータを多重化し、チャネル１６を経由した送信用の多重データユニットのシリーズを形成する。一例として、ＭＵＸ １８およびＤＥＭＵＸ ２６は、ＩＴＵによって公表されたＨ．２２３マルチプレクサプロトコルに従って動作しうる。しかしながら、ユーザデータグラムプロトコル（ＵＤＰ）のような他のプロトコルが使用されてもよい。

チャネル１６は、多重化された情報を、物理レイヤデータユニットとしてデコーダシステム１４へ搬送する。これは、論理送信ユニット（ＬＴＵ）と称される。チャンネル１６は、エンコーダシステム１２とデコーダシステム１４との間の任意の物理的接続でありうる。例えば、チャネル１６は、ローカルあるいは広域ネットワークのような有線接続かもしれない。あるいは、本明細書に記述しているように、チャネル１６は、例えばセルラ、衛星、又は光接続のような無線接続かもしれない。

ＤＥＭＵＸ ２６は、ＬＴＵから多重データユニットを識別し、多重レイヤデータユニットのコンテンツを非多重化し、ビデオ及びオーディオ適応レイヤデータユニットを生成する。適応レイヤデータユニットは、適応レイヤにおいて処理され、ビデオデータフレームが生成される。ビデオデコーダ２８は、アプリケーションレイヤにおいてビデオデータフレームを復号し、ディスプレイデバイスを駆動する際に使用されるビデオデータのストリームを生成する。ビデオデコーダ２８は、特に、ビデオデータフレーム内の個々のビデオスライスを復号する。オーディオデコーダ３０は、オーディオデータを復号し、オーディオを生成する。

本開示に従って、エンコーダシステム１２は、帯域幅効率化及び誤り回復力を提供する複雑さの少ないビデオスライシング技術を適用する。ビデオスライスとＬＴＵとの厳密なアラインメントに必要なように、ＬＴＵの開始にＲＭを正確に配置する必要はなく、エンコーダシステム１０は、近似アラインメント技術を適用する。この技術によれば、例えば、ＬＴＵ内の第１のＭＢの終わりにおいてのように、各ＬＴＵの開始近くにＲＭが配置されるようにビデオスライスが符号化される。この場合、前のスライスからの１つのＭＢは、次のＬＴＵへ移る。

近似アラインメント技術を使用して、ＬＴＵの損失は、実質的に、スライス全体に、例えば１ＭＢのような、前のスライスの極く一部を加えた損失となる。特に、各ＬＴＵは、現在のスライスの大部分が続く前のスライスの非常に小さな終了セグメントを含む。そして、現在のスライスは、前のスライスのように、次のＬＴＵへ移る小さな終了セグメントを有する。従って、スライスはそれぞれ、僅かにオーバラップしている２つの連続したＬＴＵ部分にまたがる。例えば１ＭＢのようなスライスの極く一部は、次のＬＴＵに移るであろうが、その部分は、前のＬＴＵが送信中に失われた場合、復号のために使用されないだろう。しかしながら、前のＬＴＵが失われないのであれば、この部分は、今までどおりフレーム完全性のために、復号に使用することができる。したがって、実際には、ＬＴＵの損失は、スライス全体の損失に、前のスライスからのＭＢの損失を加えたものとなる。

近似アラインメント技術は、本明細書で記載したとおり、正確なアライメント技術と比較して、単に１つの損失ＭＢをもたらすだけで、複雑さの大幅な低減が達成される。１つの追加損失ＭＢは、損失ＬＴＵに移る前のスライスからのＭＢである。この技術によれば、ＬＴＵ境界に正確にＲＭを配置する必要も、スライスレベルにおいてＭＢ量子化ステップを制御する必要もないので、エンコーダ実装の複雑さを低減する。更に、スライス内にバイトをパディングする必要もないので、より帯域幅効率化を図ることができる。

図２は、本開示に従った効率的なビデオスライシング技術を適用するビデオエンコーダシステム１２の実施形態を図示するブロック図である。ビデオエンコーダシステム１２は、例えばＨ．３２４Ｍビデオ会議のようなストリーミングビデオ又はビデオ電話通信の配信を含む様々なビデオアプリケーションをサポートしうる。図２に示すように、ビデオエンコーダシステム１２は、ＭＵＸ １８及びビデオエンコーダ２０を含んでいる。ビデオエンコーダ２０は、例えばビデオカメラ又はビデオアーカイブのようなビデオ入力デバイス２４からビデオを受け取るエンコーダエンジン２２を含む。エンコーダエンジン２２は、到来するビデオビットストリームから一連のマクロブロック（ＭＢ）を生成する。

ビデオスライスジェネレータ２６は、エンコーダエンジン２２からのビデオビットストリームを、ビデオスライスに分割する。各ビデオスライスは、一連のＭＢを伝送する。それは数が異なるかもしれない。連続的なスライスを示すために、ビデオスライスジェネレータ２６はＲＭを挿入する。ＲＭは、選択されたＭＢの境界に挿入される。従って、与えられたビデオフレーム内で一連のスライスを形成するために、ビデオスライスジェネレータ２６は、選択されたＭＢ境界に、一連のＲＭを選択的に挿入する。

説明するように、スライスサイズ決定モジュール２８は、適切な位置においてスライスを生成するようにビデオスライスジェネレータ２６を導く。スライスサイズ決定モジュール２８は、ビデオスライスジェネレータ２６によって生成された前のスライスサイズと、ビデオＬＴＵサイズとを活用して、目標スライスサイズを生成する。ビデオスライスジェネレータ２６は、この目標スライスサイズを用いて次のスライスを生成する。

本開示では、用語「ＬＴＵ」およびビデオＬＴＵは、物理レイヤＬＴＵのビデオ部分を称するために、置き換え可能で使用されうる。しかしながら、物理レイヤＬＴＵは、通常、オーディオＬＴＵとして明示されうるオーディオ情報を含むと理解されるべきである。ビデオスライスのＬＴＵ境界とのアラインメントに関して、そのような境界は、物理レイヤＬＴＵ内でのオーディオＬＴＵおよびビデオＬＴＵの組合せを考慮しているかもしれないこと、また、そのような境界は、そのような組合せからの連続したＬＴＵ間の境界を指すかもしれないことが理解されるべきである。

適応レイヤモジュール３０は、ビデオスライスへ分割されたビデオフレームをビデオスライスジェネレータ２６から受け取り、ビデオ適応レイヤプロトコルデータユニット（ＡＬ−ＰＤＵ）を生成する。ＭＵＸ １８は、ビデオＡＬ−ＰＤＵを受け取り、それをオーディオエンコーダから受け取ったオーディオＡＬ−ＰＤＵと合成するＭＵＸエンジン３２と、無線モデム３４、無線周波数送信機／受信機（ＴＸ／ＲＸ）３５、およびアンテナ３６を経由して送信されるＭＵＸ ＰＤＵを生成するオーディオ適応レイヤモジュール（図示せず）とを含む。ＴＸ／ＲＸ ３５は、符号分割多元接続（ＣＤＭＡ）、広帯域ＣＤＭＡ（Ｗ−ＣＤＭＡ）、あるいは時分割多元接続（ＴＤＭＡ）のような様々な無線送信技術のうちの何れかに従ってラジオ周波数（ＲＦ）無線信号を送信するように構成されうる。

ＭＵＸ １８の内のビデオＬＴＵサイズ推定モジュール３８は、ＭＵＸエンジン３２によって生成された各ＭＵＸ ＰＤＵのビデオ部分のサイズ、および無線送信機３４によって生成された物理レイヤＬＴＵのサイズを追跡する。例えば、ＭＵＸエンジン３２は、各ＭＵＸ ＰＤＵ内のビデオ情報に対するオーディオ情報の比率の表示（ＡＵＤＩＯ：ＶＩＤＥＯ）を、ビデオＬＴＵサイズ推定モジュール３８に提供しうる。さらに、無線モデム３４は、空気インタフェースを通して送信されたＬＴＵの実際のサイズの表示を、ビデオＬＴＵサイズ推定モジュール３８に提供する。

これらのパラメータを使用して、ビデオＬＴＵサイズ推定モジュール３８は、各ＬＴＵのビデオ部分のサイズ、すなわち、ビデオＬＴＵサイズを推定する。いくつかの実装では、ＡＵＤＩＯ：ＶＩＤＥＯ比率及びＬＴＵサイズは共に固定されているかもしれない。他の実装では、ＬＴＵサイズは固定されているかもしれないが、例えば、可変レートオーディオ符号化が使用される場合には、ＡＵＤＩＯ：ＶＩＤＥＯ比率は変わりうる。いずれの場合も、ビデオ符号化システム１２は、物理レイヤ、ＭＵＸレイヤ、及びアプリケーションレイヤによって提供される情報に基づいてスライスサイズが決定されるユニークな伝送エンコーダクロスレイヤ設計を提供することが明らかである。

ビデオＬＴＵ推定モジュール３８は、ビデオエンコーダ２０内のスライスサイズ決定モジュール２８へ、ビデオＬＴＵサイズを通信する。従って、スライスサイズ決定モジュール２８は、ＭＵＸ １８の内のビデオＬＴＵサイズ推定モジュール３８から得られたビデオＬＴＵサイズと、ビデオスライスジェネレータ２６によって提供された前のスライスサイズとを使用して、目標スライスサイズを決定する。そして、スライスサイズ決定モジュール２８は、スライスを生成する際にビデオスライスジェネレータ２６によって使用される目標スライスサイズを生成する。これによって、ビデオフレーム内の適切なＭＢ境界にＲＭを挿入することが可能となる。

いくつかの実施形態では、物理レイヤＬＴＵはＷ−ＣＤＭＡ ＲＬＣ ＰＤＵでありうる。あるいは、物理レイヤＬＴＵは、例えばＣＤＭＡ２０００ １ｘ ＲＬＰ ＰＤＵ、ＣＤＭＡ２０００ １ｘ ＥＶ−ＤＯ ＲＬＰ ＰＤＵ、ＣＤＭＡ２０００ ＥＶ−ＤＶ ＲＬＰ ＰＤＵのような様々な異なる形式をとってもよい。ＭＵＸエンジン３２は、ＩＴＵ Ｈ．２２３のような多重化プロトコルに従ってＭＵＸ ＰＤＵを生成する。しかしながら、本明細書に記載の技術は、例えばＲＴＰ／ＵＤＰ／ＩＰ（Realtime Transport Protocol/User Datagram Protocol/Internet Protocol）を用いたＳＩＰベースのプロトコル及びＨ．３２３ビデオ電話通信プロトコルのようなその他のビデオ伝送プロトコルにも適用可能でありうる。

Ｗ−ＣＤＭＡ又はＣＤＭＡ２０００を用いたＭＰＥＧ−４無線送信の場合、ＲＬＣ ＰＤＵ又はＲＬＰ ＰＤＵが、送信中に損失を被る最小のユニットである。例えば、Ｗ−ＣＤＭＡ ＲＬＣ−ＰＤＵは、長さ１６０バイトであり、２０ミリ秒毎に送信される。ＬＴＵのサイズにおおよそ等しいビデオスライスを生成するために、ＬＴＵサイズは既知でなければならない。いくつかの実装では、ＬＴＵサイズは時間にわたって変動するかもしれず、下にある伝送プロトコル／物理レイヤが、ビデオエンコーダ２０にＬＴＵサイズを通知する必要がある。その目的のために、ビデオＬＴＵサイズ推定器３８は、個々のビデオＬＴＵのサイズを推定し、この情報を、ビデオエンコーダ２０内のスライスサイズ決定モジュール２８に通信する。

ビデオＬＴＵサイズ推定器３８は、様々な方法で実装されうる。Ｗ−ＣＤＭＡ上のいくつかの回路切替ビデオアプリケーションでは、ＬＴＵサイズは一定で、常に１６０バイトである。一例として、オーディオ符号化が、１２．２Ｋｂｐｓのレートで動作する場合、ビデオによって使用することができるバイト数は１２４バイトである。従って、この場合、ビデオＬＴＵサイズは１２４バイトである。オーディオ符号化レートが変化する場合、ビデオＬＴＵサイズは変化する。いずれの場合も、ビデオＬＴＵサイズ推定器３８は、ビデオスライス操作を行なうために、この情報をビデオエンコーダ２０まで渡す。ＣＤＭＡ２０００ １ｘのようなパケット交換ネットワークの場合、各ＲＬＰ−ＰＤＵのためにビデオＬＴＵサイズを動的に決定することが必要かもしれない。ビデオ会議サービスのために３ＧＰＰ２によって検討されているように、ヘッダーオーバヘッドが取り除かれる場合、ビデオＬＴＵサイズの動的な判定は容易になるかもしれない。

上述したように、ＬＴＵサイズ情報を物理レイヤからＭＵＸ １８へ渡し、ビデオＬＴＵサイズ情報をＭＵＸ １８からビデオエンコーダ２０へ渡すことによって、ビデオエンコーダシステム１２は、効率的なビデオスライシングを促進するユニークな伝送エンコーダクロスレイヤ設計を提供する。このクロスレイヤ設計に従って、トランスポートレイヤは、ＲＭを効率的に配置するために、追加情報をビデオエンコーダ２０に渡す。その結果、不正確ではあるが、ビデオスライスとビデオＬＴＵとの近似のアライメントが得られる。

本明細書に記述する技術は、汎用マイクロプロセッサー、デジタルシグナルプロセッサー（ＤＳＰ）、特定用途向けＩＣ（ＡＳＩＣ）、フィールドプログラム可能なゲートアレー（ＦＰＧＡ）、あるいはその他の等価ロジックデバイス内で実施されうる。例えば、ビデオエンコーダシステム１２、及びそのコンポーネントは、デジタルシグナルプロセッサー（ＤＳＰ）あるいはその他の処理デバイス上で動作するエンコード処理、すなわち符号化／復号（ＣＯＤＥＣ）処理の一部として実施されるかもしれない。従って、モジュールと記述されたコンポーネントは、そのような処理のプログラム可能な特徴を形成しうる。ビデオエンコーダシステム１２は、専用のハードウェア、ソフトウェア、ファームウェア、あるいはこれらの組合せと同様に、命令及びデータを格納するための専用メモリを有しうる。ソフトウェアとして実施される場合、これら技術は、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）、電気消去可能プログラマブル読出し専用メモリ（ＥＥＰＲＯＭ）、ＦＬＡＳＨメモリ等のようなコンピュータ読取可能媒体上の命令として具体化されうる。これら命令は、１つ又は複数のプロセッサに、本開示で記述された機能のある局面を実行させる。

図３、図４および図５は、本明細書で記述された近似アラインメント技術に対する比較の目的のために、異なるビデオスライシング技術を図示するブロック図である。図３は、ビデオＬＴＵ境界へのＲＭの正確なアラインメントを必要とし、結果として、１つのビデオＬＴＵが損失した場合に、１つのスライスのみが損失する技術を例示している。このアプローチは、実装が極めて複雑になる。図４は、ビデオＬＴＵ境界にＲＭをアライメントするのに何の努力もなされない技術を例示している。代わりに、ＲＭは、各ビデオＬＴＵにドリフトする傾向にあり、結果として、１つのビデオＬＴＵが損失した場合に、多数のスライスを損失する。図５は、各スライスの終わりにおいてパディングバイトを用いることにより、固定スライスがビデオＬＴＵにアライメントされるスライシング技術を例示している。この場合、パディングバイトは、著しい帯域幅非能率を生む。

図３の例では、スライスは、最も小さな損失単位、すなわちビデオＬＴＵと正確にアライメントされる。しかしながら、図３のアプローチを実現するために、ビデオエンコーダは、ビデオビットストリーム上のＬＴＵ境界を知り、配置しなければならない。そして更に、２つのＬＴＵ境界の間に同じサイズのスライスを生成しなければならない。しかしながら、そのような実装を達成するのは非常に難しく、かつ高価である。特に、ＲＭは、ＭＢ境界に挿入されねばならないし、ビットストリーム内の任意のバイト位置に配置することができない。この制約により、エンコーダが各スライスのサイズを制御するのは難しい。スライスの目標サイズがＫである場合、エンコーダは通常、ＭＢ境界にＲＭを挿入する必要性のために、正確なサイズＫのスライスを生成することができない。

図３に示すように、正確なアラインメントのために、ＲＭ ４２，４４，４６は、それぞれビデオＬＴＵ５４，５６，５８の始まりを指定しているビデオＬＴＵ境界４８，５０，５２にそれぞれ正確に配置される。連続したビデオデータフレームは、前のビデオデータフィールドの終わりを示すビデオオブジェクトプレーン（ＶＯＰ）フィールド６０，６２によって境界付けられる。正確なアラインメントによって、１つのＬＴＵの損失は、１つのビデオスライスの損失となる。図３の例では、例えば、ビデオＬＴＵ ５６の損失は、ＭＢ５５からＭＢ７２、すなわち［５５，７２］を含む対応するビデオスライスの損失となる。前のビデオＬＴＵ ５４にアライメントされたスライスと、次のビデオＬＴＵ ５８にアライメントされたスライスとは、完全なままであり、復号することが可能である。一方、損失したビデオＬＴＵ５６にアライメントされたスライスのＭＢ［５５，７２］は、デコーダによって隠蔽される。

実装をより単純にするために、ビデオエンコーダは、目標サイズＫにおいてスライスを符号化するが、Ｋより大きいスライスサイズも許可するように構成されうる。図４に示すように、そのような実装は、ビデオＲＬＣ境界７０，７２，７４それぞれからドリフトする傾向にあるＲＭ ６４，６６，６８が配置される結果となる。このドリフトは、参照番号７６、７８、８０によって表わされる。図４の例では、１つのビデオＬＴＵが損失した場合、損失したビデオＬＴＵの境界に遭遇する２つのスライスからデータが失われるだろう。従って、図４のアプローチは、無線ネットワーキングのような、特に誤りがちなアプリケーションで、顕著な性能劣化となる。

他のいくつかの実装は、図５に示すように、ビデオＬＴＵサイズＫよりも小さいビデオスライスを生成し、更に、次のＲＭが次のビデオＬＴＵの始まりにおいて正確に配置されるように各スライスにパディングバイトを加える。図５に示すように、ＲＭ ８２，８４は、連続したビデオＬＴＵ ９０，９２，９４の境界８６，８８のそれぞれに正確に配置される。しかしながら、各スライスのサイズは、ビデオＬＴＵサイズ未満になるように選択される。従って、スライスはそれぞれ、符号化されたビデオの終わりと、次のビデオＬＴＵ境界との間の空間を埋めるためにパディングバイト９６，９８，１００を含んでいる。当然、このアプローチは、デコーダによって利用されないパディングバイトが存在するので、帯域幅における非効率である。さらに、このアプローチは、エンコーダ実装を複雑にする傾向がある。特に、現在のスライスサイズがビデオＬＴＵサイズＫを超過しているとエンコーダが判定すると、１ＭＢ戻り、スライスを生成し、新たなスライスを開始し、更に、次のＭＢを再符号化する必要がある。

更なる解決策は、量子化パラメータ（ＱＰ）と呼ばれ、異なる量子化ステップサイズ用に各ＭＢに費やされる正確なビット数を正確に推定するレート制御アルゴリズムの使用を含む。スライスレベルレート制御技術は、各スライスに含まれるＭＢの数と、このＭＢについて対応するＱＰとの最良の組合せの決定を試みる。明らかに、このアプローチは計算費用が高くなる。更に、このアプローチは、ビデオＬＴＵサイズＫに近いビデオスライスのみを生成する。特に、可変サイズをもってしても、ＭＢ境界は、ビデオＬＴＵ境界上に必ずしも正確に来るとは限らないだろう。この場合、パディングバイトの使用はまだ避けられない。従って、レート制御アルゴリズムは、実装の複雑さと、帯域幅非能率との両方を示す。

図６および図７は、本開示に従うスライスとＬＴＵとの近似アラインメントに基づいたビデオスライシング技術を例示するブロック図である。図６および図７内に示すビデオスライシング技術は、図２のビデオエンコーダシステム１２内に実装されうる。一般に、ビデオスライシング技術は、誤り回復力と帯域幅効率化との両方を達成しながら、さほど複雑ではない実装で済む。上述したように、ビデオスライシング技術は、ＲＭのビデオＬＴＵ境界との正確なアラインメントを必要としない。従って、１つのスライスは、１つのビデオＬＴＵに正確にフィットする必要はない。代わりに、ＲＭが個々のビデオＬＴＵの始まり近くに配置されるように各ビデオスライス作成される。従って、スライスレベルにおいて、正確なアライメント、あるいはタイトなレート制御を行う必要はなく、エンコーダ実装の複雑さが低減される結果となる。

図６は、ビデオＬＴＵ境界に対するスライス及びＲＭの配置に関するビデオスライシング技術を示す。図６は、ビデオＬＴＵ １０２，１０４，１０６，１０８、ビデオＬＴＵ境界１１０，１１２，１１４、及びＲＭ １１６，１１８，１２０を示す。スライスはそれぞれ１つのＲＭから次のＲＭまで及ぶ。図６に示すように、個々のビデオＬＴＵの始まりは、前のスライスの小さな終了セグメント１２２，１２４，１２６を含んでいる。そして、現在のスライスの大部分は、各ビデオＬＴＵ １０２，１０４，１０６内の前のスライスの小さな終了セグメント１２２，１２４，１２６に続く。前のスライスと同様、現在のスライスは、次のビデオＬＴＵへ伸びる小さな終了セグメントを含んでいる。従って、ビデオＬＴＵはそれぞれ、前のスライスからの少しのデータと、現在のスライスからの殆どのデータとを含んでいる。

スライスとＬＴＵとの間の正確なアラインメントが必要とされる図３の例と比較した場合、図６のビデオのスライシングアプローチは、スライス（ＲＭからＲＭへ）とＬＴＵ（ＬＴＵ境界からＬＴＵ境界へ）との間の近似アラインメントを生むことと見なすことができる。各スライスについては、スライスの小さな終了セグメントが、次のビデオＬＴＵへ移るように、目標スライスサイズが選択される。そして、次のＲＭは、その終了セグメントの終わりで規定されるＭＢ境界に容易に挿入される。したがって、一般には、１つのＭＢの一部のみが、次のビデオＬＴＵへ移るだろう。

図７は、ＬＴＵが損失した場合に隠蔽されねばならないＭＢ数に関して、図６の近似アライメント技術のパフォーマンスを例示する。図７に示すように、１つのビデオＬＴＵ１０６の損失は、１つのスライスを失うこととほぼ等価である。このスライスの非常に小さな終了セグメント１２６は、次のＬＴＵ１０８へ運ばれる。これは、損失されることなく、正確に受け取られる。しかしながら、デコーダはスライスを独立して復号するので、この小さな終了セグメント１２６は、復号に使用されないだろう。したがって、実際には、ビデオＬＴＵ１０６にまたがるスライス全体は、この小さな終了セグメント１２６とともに失われる。損失したＬＴＵ１０６とともに１つのスライス全体を失うなうことに加えて、ＬＴＵ１０４内の前のスライスからの非常に小さい終了セグメント１２４もまた失われるだろう。なぜなら、この終了セグメントは、現在のＬＴＵ１０６に移るからである。しかしながら、前のスライスの残りは、完全であり、復号することができる。典型的な実装では、次のＬＴＵへ移されるスライスの終了セグメントは、１つのＭＢの一部のみとなるであろう。

図３の正確なアラインメントアプローチと比較して、図６および図７によって例示された近似アラインメントアプローチは、比較的良好な帯域幅効率および誤り回復力を備え、複雑さを低減する。図３の例では、正確なアラインメントアプローチは、ＬＴＵが失われた場合、５５から７２までのＭＢ（ＭＢ［５５，７２］）が失われるという結果になる。明らかに、図７に示すように、近似アラインメントアプローチによって、１つのＭＢ、すなわちＭＢ［５４，７２］のうちのＭＢ５４、しか追加損失しないという結果になる。この追加損失ＭＢは、現在のビデオＬＴＵ１０６に移行する前のスライスの終了セグメントからのＭＢである。したがって、本開示で記述した近似アラインメントアプローチを使用することの犠牲は、１つの追加ＭＢの損失のみである。しかしながら、この犠牲は、実装複雑さの低減と、帯域幅効率化とによって補われる。

動作時には、ＬＴＵ誤りが検知された場合、損失したビデオＬＴＵ１０６の前のビデオＬＴＵ１０４における前のスライスの全てが喪失（drop）されないことを保証するために、デコーダシステム１４は、エンコーダシステム１２によって適用される近似アライメントアプローチに敏感であるように構成されるべきである。いくつかの実施形態では、デコーダシステム１４は、近似アラインメントアプローチに従って生成されるスライスを取り扱うよう具体的に構成されうる。他の実施形態では、エンコーダシステム１２およびデコーダシステム１４は、エンコーダシステムが近似アライメントアプローチを使用しており、デコーダシステムはそれに従って自分自身を構成すべきであることを明示する制御情報を交換しうる。更なる代案として、いくつかのエンコーダシステム１２およびデコーダシステム１４は、上述したような近似アライメント、正確なアライメント、パディング、又はスライスレベルレート制御技術を切り換えるオペレーションモードを提供するように構成されうる。

図８は、本開示に従ったビデオスライスサイズの計算を例示するブロック図である。図８に示すように、近似アライメントビデオスライス技術を実行するために、エンコーダシステム１２は、Ｋ（ｎ）で表される各ＬＴＵのサイズを取得する。ここでｎは、空気インタフェースによって送信される一連のＬＴＵにおける各ビデオＬＴＵの位置を示すインデクスである。エンコーダシステム１２は、到来するビデオビットストリームのビットを符号化し、符号化されたビット数が、現在の目標スライスサイズＴ（ｎ）を越える場合には、ビデオスライスを生成する。ここで、ｎは、一連のスライスにおける各スライスの位置を示すインデクスである。

しかしながら、この技術によれば、スライスの目標スライスサイズＴ（ｎ）は、Ｋ（ｎ）に等しくなく、正確なアライメントを必要とするだろう。再度述べるように、ＭＢ境界にＲＭを挿入する必要により、スライスとビデオＬＴＵとの正確なアラインメントは困難である。代わりに、次のＬＴＵ境界の後、例えば、ビデオＬＴＵ境界の１ＭＢ以内に、次のＲＭが直ちに表れることを保証するために、スライスが生成される毎に目標スライスサイズが調整される。言いかえれば、ＬＴＵ境界にＲＭをそれぞれ配置する必要はないが、ＬＴＵ境界の１ＭＢ以内にあるべきである。この処理は、ＲＭがＬＴＵ境界に配置されねばならない技術に比べて複雑さを低減し、ＲＭが常に境界に十分近いことを保証し、パディングバイトの必要性をも回避する。

目標スライスサイズＴ（ｎ）の調整は、実際に符号化された前のスライスサイズＬと、前の目標スライスサイズＴ（ｎ）との差を計算し、この差を、Ｋ（ｎ）から引くことによって実現される。図８に示すように、目標スライスサイズＴ（ｎ）の調整は、

によって行われる。上記式では、Ｔ（ｎ）は現在の目標スライスサイズ、Ｋ（ｎ）は現在のビデオＬＴＵサイズ、ｄ（ｎ−１）は、実際に符号化された前のスライスサイズと、前の目標スライスサイズとの差である。この値は、エンコーダシステム１２によって生成される各スライスのために再計算される。

図８に関連して上述したスライスサイズ計算は、以下の中間コードによって表すことができる。

図９は、本開示に従ったビデオスライシング技術の動作を図示するフロー図である。このビデオスライシング技術は、図２のビデオスライスジェネレータ２６、スライスサイズ決定モジュール２８、およびビデオＬＴＵサイズ推定器３８のような様々なコンポーネントを用いて実現されうる。このフロー図は、一般に、上記の中間コードによって表わされる動作と結果を追跡する。図９に示すように、この技術は、現在のビデオＬＴＵのサイズＫを取得すること（１２６）と、目標スライスサイズＴを生成すること（１２８）とを含む。先ず、フレームにおける第１のスライスについて、目標スライスサイズＴが、ＬＴＵサイズＫに等しくなるように設定される（１２８）。ビデオＬＴＵサイズＫは、ビデオＬＴＵサイズ推定器３８から取得される（図２）。ビデオスライシング処理は、符号化されるビデオフレームが存在する限り繰り返される（１３０）。特に、この処理は、フレームからフレームへと進む（１３２）。与えられたフレーム内では、この処理は、利用可能なフレーム内に、符号化される更なるＭＢが存在する限り繰り返される（１３４）。従って、この処理は、フレーム内のＭＢからＭＢへと進む（１３６）。

与えられたフレームおよびＭＢについて、このビデオスライシング技術は、現在のスライスサイズＬが、目標スライスサイズＴよりも大きいか、又は等しいかを判定する（１３８）。現在のスライスサイズＬは、与えられたスライスについて既に符号化されたＭＢの数によって決定される。従って、実際のスライスサイズＬは、符号化される各ＭＢとともに増加するだろう。先ず、目標スライスサイズＴは、現在のＬＴＵサイズＫと等しくなるだろう（１２８）。現在のスライスサイズＬが、その目標スライスサイズＴとなるか、または超えるのであれば（１３８）、処理は、現在のスライスサイズＬと、目標スライスサイズＴとの差ｄを判定する（１４０）。現在のスライスサイズＬが、目標スライスサイズＴと等しくなく、超えもしない場合、処理は、ＭＢを符号化し（１４２）、現在のスライスサイズＬを更新し（１４４）、更なるＭＢを処理することに戻る（１３４）ことを継続する。

この処理は、次に、目標スライスサイズＴが、次のビデオＬＴＵのサイズＫと差ｄとの差に等しくなるように調整する（１４６）。このようにして、目標スライスサイズＴは、ループによって、次のパスのために調整される。特に、次の目標スライスサイズＴは、前のスライスの終了セグメントのサイズと等しい量、つまり量ｄ、ＬＴＵサイズＫよりも小さくなるであろう。この時点で、処理は、現在のスライスの終わりに達する。したがって、この処理は、次のパスのために現在のスライスサイズＬをリセットし（１４８）、スライスの終わりにＲＭを挿入し、新たなスライスを開始する（１５０）。現在のスライスサイズＬを更新すると（１４４）、この処理は、もしも利用可能であれば、利用可能なビデオフレームにおける更なるＭＢの処理に戻る。

現在のスライスサイズＬが、目標スライスサイズＴになることも、それを超えもしない場合、与えられたフレーム内で処理される更なるＭＢは存在せず、この処理は、フレームの終わりに達する。この場合、この処理は、フレームの終わりにおけるスライスのみについてパディングバイトを挿入し、利用可能な残りのスライスを埋める。しかしながら、これは、スライスＬＴＵアライメント処理のために、各ビデオスライス内にパディングバイトを配置することとは対象的である。パディングバイトを挿入する代わりに、次のフレームからのデータが、スライスへ挿入されることもある。前のフレームからのデータを含んでいるスライス内で、次のフレームからのデータを挿入するこのアプローチの結果、１フレームの遅れが生じうる。しかしながら、この遅れは、帯域幅効率化とのトレードオフによって正当に理由付けされうる。

本開示に従って、ビデオエンコーダシステム１２は、ビデオエンコーダ２０と、下部レイヤ、すなわちＭＵＸ１８及びモデム３４との間のクロスレイヤ設計を実現する。このように、ビデオエンコーダ２０は、ビットストリームがどのように分割され、トランスポートレイヤ内のＬＴＵへ多重化されるのかを決定する。特に、各スライスのサイズは、下部レイヤから提供される。スライスサイズは、ビデオデータがオーディオデータとどのように多重化されるかに依存して変わりうる。さらに、この技術は、ＬＴＵが損失される前に得られた有用なデータを破棄しないように、ビデオデコーダ１８が、この具体的な符号化アプローチを知っていると仮定する。

広範な実験による予備結果は、ビデオスライシングのための近似アライメント技術を用いることによって、損失するＭＢの数が、スライスとＬＴＵ境界との間のドリフトをもたらす既存の技術と比較して２６％乃至３２％低減されることを示す。この既存の技術によれば、ビデオエンコーダは、１２０バイトの固定目標スライスサイズを設定するだろう。そして、現在のスライスサイズが１２０バイトを超える場合、ビデオは、現在のスライスを終了し、新しいスライスを開始するだろう。上述したように、そのような既存技術は、著しいドリフトをもたらす結果となりうる。本明細書で説明した近似アライメント技術によって得られる改良点は、顕著であり、上述したように、損失するＭＢを２６％乃至３２％低減する。

様々な実施形態が記述された。これら実施形態およびその他の実施形態は、特許請求の範囲内である。

図１は、ビデオ／オーディオ符号化及び復号システムを図示するブロック図である。 図２は、本開示に従ったビデオスライシング技術を適用するビデオエンコーダシステムを図示するブロック図である。 図３は、異なるビデオスライシング技術を図示するブロック図である。 図４は、異なるビデオスライシング技術を図示するブロック図である。 図５は、異なるビデオスライシング技術を図示するブロック図である。 図６は、本開示に従ったビデオスライシング技術を図示するブロック図である。 図７は、本開示に従ったビデオスライシング技術を図示するブロック図である。 図８は、本開示に従ったビデオスライスサイズの計算を例示するブロック図である。 図９は、本開示に従ったビデオスライシング技術の動作を例示するフローチャートである。

Claims (39)

1. ビデオ論理送信ユニット（ＬＴＵ）のサイズを決定することと、
   目標ビデオスライスサイズを生成することと、
   第１のビデオスライスを、前記第１のビデオスライスのサイズが前記目標ビデオスライスサイズよりも大きくなるまで符号化することと、
   前記第１のビデオスライスのサイズと、前記目標ビデオスライスサイズとの差を計算することと、
   前記第１のビデオスライスの終わりに再同期マーカ（ＲＭ）を挿入することと、
   前記目標ビデオスライスサイズを、前記ビデオＬＴＵのサイズから前記差を引いたものに等しくなるように更新することと、
   第２のビデオスライスを、前記第２のビデオスライスのサイズが、前記更新された目標ビデオスライスサイズよりも大きくなるまで符号化することとを備えるビデオ符号化方法。
2. 目標ビデオスライスサイズを生成することは、前記ビデオＬＴＵサイズと等価な目標ビデオスライスサイズを生成することを含む請求項１の方法。
3. ビデオフレーム内の複数のビデオスライスに対し前記計算、挿入、更新、及び符号化する動作を繰り返すことを更に備える請求項１の方法。
4. 前記ビデオＬＴＵサイズを決定することは、ビデオ部分及びオーディオ部分を含む物理レイヤＬＴＵのサイズを決定することと、前記オーディオ部分に対する前記ビデオ部分の比率を決定することと、前記物理レイヤＬＴＵのサイズと前記比率とに基づいて、前記ビデオＬＴＵサイズを決定することとを含む請求項１の方法。
5. 物理レイヤＬＴＵサイズを、ビデオ通信デバイス内の多重化レイヤへ渡すことと、
   前記多重化レイヤから、前記ビデオ通信デバイス内の符号化レイヤへ前記ビデオＬＴＵサイズを渡すこととを更に備える請求項１の方法。
6. 前記ＲＭを挿入することは、マクロブロック（ＭＢ）境界に前記ＲＭを挿入することを含む請求項１の方法。
7. 前記差は、１マクロブロック（ＭＢ）未満のサイズである請求項１の方法。
8. 前記第１のビデオスライスと前記第２のビデオスライスとに、実質的にパディングバイトを入れないことを更に備える請求項１の方法。
9. 前記ＲＭを挿入することは、前記ＲＭを、連続するビデオＬＴＵの間の境界に対応する位置に、あるいはその位置の後ろに挿入することを含む請求項１の方法。
10. ビデオスライスに含まれる情報を前記オーディオ情報とともに多重化して、複数の多重化プロトコルデータユニット（ＭＵＸ ＰＤＵ）を生成することを更に備える請求項１の方法。
11. 前記第１のビデオスライスの第１の部分は、第１の物理レイヤＬＴＵ内に存在し、前記第２のビデオスライスの第１の部分は、第２の物理レイヤＬＴＵ内に存在する請求項１の方法。
12. 前記第１のビデオスライスの前記第２の部分は、１マクロブロック（ＭＢ）未満のサイズである請求項１１の方法。
13. ビデオ論理送信ユニット（ＬＴＵ）のサイズを推定するビデオ論理送信ユニット（ＬＴＵ）サイズ推定モジュールと、
    目標ビデオスライスサイズを決定するスライスサイズ決定モジュールと、
    第１のビデオスライスのサイズが、前記目標ビデオスライスサイズより大きいか、又は等しくなるまで前記第１のビデオスライスを符号化するビデオスライスジェネレータであって、前記第１のビデオスライスのサイズと、前記目標ビデオスライスサイズとの差を計算し、前記第１のビデオスライスの終わりに、再同期マーカ（ＲＭ）を挿入するビデオスライスジェネレータとを備え、
    前記スライスサイズ決定モジュールは、前記ビデオＬＴＵサイズから前記差を引いたものに等しくなるように前記目標ビデオスライスサイズを更新し、
    前記ビデオスライスジェネレータは、第２のビデオスライスのサイズが、前記更新された目標ビデオスライスサイズより大きいか、又は等しくなるまで前記第２のビデオスライスを符号化するビデオ符号化システム。
14. 前記スライスサイズ決定モジュールは、前記ビデオＬＴＵサイズと等価な前記目標ビデオスライスサイズを決定する請求項１３のシステム。
15. 前記ビデオＬＴＵサイズ推定モジュールは、ビデオ部分及びオーディオ部分を含む物理レイヤＬＴＵのサイズを決定し、前記オーディオ部分に対する前記ビデオ部分の比率を決定し、前記物理レイヤＬＴＵのサイズと前記比率とに基づいて、前記ビデオＬＴＵサイズを推定する請求項１３のシステム。
16. 前記ビデオＬＴＵサイズ推定モジュールは、前記システム内の多重化レイヤ内に存在する請求項１５のシステム。
17. 前記ビデオＬＴＵサイズ推定モジュールは、前記システム内のモデムから前記物理レイヤＬＴＵのサイズを取得する請求項１５のシステム。
18. 前記ビデオＬＴＵサイズ推定モジュールは、前記システム内の多重化エンジンから前記比率を取得する請求項１５のシステム。
19. 前記ビデオＬＴＵサイズ推定モジュールは、前記システム内の多重化レイヤ内に存在し、
    前記多重化レイヤから、前記システムの符号化レイヤ内の前記スライスサイズ決定モジュールへ前記ビデオＬＴＵサイズを渡す請求項１３のシステム。
20. 前記ビデオスライスジェネレータは、マクロブロック（ＭＢ）境界に前記ＲＭを挿入する請求項１３のシステム。
21. 前記差は、１マクロブロック（ＭＢ）未満のサイズである請求項１３のシステム。
22. 前記ビデオスライスジェネレータは、前記第１のビデオスライスと前記第２のビデオスライスとに、実質的にパディングバイトを入れない請求項１３のシステム。
23. 前記ビデオスライスジェネレータは、前記ＲＭを、連続するビデオＬＴＵの間の境界に対応する位置に、あるいはその位置の後ろに挿入する請求項１３のシステム。
24. ビデオスライスに含まれる情報を前記オーディオ情報とともに多重化して、複数の多重化プロトコルデータユニット（ＭＵＸ ＰＤＵ）を生成する多重化エンジンを更に備える請求項１３のシステム。
25. 前記ビデオスライスジェネレータは、前記第１のビデオスライスの第１の部分が第１の物理レイヤＬＴＵ内に存在し、前記第２のビデオスライスの第１の部分が第２の物理レイヤＬＴＵ内に存在するように前記ＲＭを挿入する請求項１３のシステム。
26. 前記第１のビデオスライスの前記第２の部分は、１マクロブロック（ＭＢ）未満のサイズである請求項２５のシステム。
27. ビデオ論理送信ユニット（ＬＴＵ）のサイズを決定し、
    目標ビデオスライスサイズを生成し、
    第１のビデオスライスを、前記第１のビデオスライスのサイズが前記目標ビデオスライスサイズよりも大きくなるまで符号化し、
    前記第１のビデオスライスのサイズと、前記目標ビデオスライスサイズとの差を計算し、
    前記第１のビデオスライスの終わりに再同期マーカ（ＲＭ）を挿入し、
    前記目標ビデオスライスサイズを、前記ビデオＬＴＵのサイズから前記差を引いたものに等しくなるように更新し、
    第２のビデオスライスを、前記第２のビデオスライスのサイズが、前記更新された目標ビデオスライスサイズよりも大きくなるまで符号化するようプロセッサに実行させる命令を備えたコンピュータ読取可能媒体。
28. 前記生成された目標ビデオスライスサイズは、前記ビデオＬＴＵサイズと等価である請求項２７のコンピュータ読取可能媒体。
29. ビデオフレーム内の複数のビデオスライスに対し前記計算、挿入、更新、及び符号化する動作を繰り返すよう前記プロセッサに実行させる命令を更に備える請求項２７のコンピュータ読取可能媒体。
30. ビデオ部分及びオーディオ部分を含む物理レイヤＬＴＵのサイズを決定し、
    前記オーディオ部分に対する前記ビデオ部分の比率を決定し、
    前記物理レイヤＬＴＵのサイズと前記比率とに基づいて、前記ビデオＬＴＵサイズを決定するよう前記プロセッサに実行させる命令を更に備える請求項２７のコンピュータ読取可能媒体。
31. マクロブロック（ＭＢ）境界に前記ＲＭを挿入するよう前記プロセッサに実行させる命令を更に備える請求項２７のコンピュータ読取可能媒体。
32. 前記差は、１マクロブロック（ＭＢ）未満のサイズである請求項２７のコンピュータ読取可能媒体。
33. 前記第１のビデオスライスと前記第２のビデオスライスとに、実質的にパディングバイトを入れないよう前記プロセッサに実行させる命令を更に備える請求項２７のコンピュータ読取可能媒体。
34. 前記ＲＭを、連続するビデオＬＴＵの間の境界に対応する位置の後ろに挿入するよう前記プロセッサに実行させる命令を更に備える請求項２７のコンピュータ読取可能媒体。
35. 前記第１のビデオスライスの第１の部分が第１の物理レイヤＬＴＵ内に存在し、前記第２のビデオスライスの第１の部分が第２の物理レイヤＬＴＵ内に存在するように前記ＲＭを挿入するよう前記プロセッサに実行させる命令を更に備える請求項２７のコンピュータ読取可能媒体。
36. 前記第１のビデオスライスの第２の部分は、１マクロブロック（ＭＢ）未満のサイズである請求項３５のコンピュータ読取可能媒体。
37. ビデオ論理送信ユニット（ＬＴＵ）のサイズを決定する手段と、
    目標ビデオスライスサイズを生成する手段と、
    第１のビデオスライスを、前記第１のビデオスライスのサイズが前記目標ビデオスライスサイズよりも大きくなるまで符号化する手段と、
    前記第１のビデオスライスのサイズと、前記目標ビデオスライスサイズとの差を計算する手段と、
    前記第１のビデオスライスの終わりに再同期マーカ（ＲＭ）を挿入する手段と、
    前記目標ビデオスライスサイズを、前記ＬＴＵのサイズから前記差を引いたものに等しくなるように更新する手段と、
    第２のビデオスライスを、前記第２のビデオスライスのサイズが、前記更新された目標ビデオスライスサイズよりも大きくなるまで符号化する手段とを備えるビデオ符号化システム。
38. デジタルビデオフレームをビデオスライスへ分割することと、
    各スライスの第１の部分が第１の物理レイヤ論理送信ユニット（ＬＴＵ）内に存在し、各スライスの第２の部分が第２の物理レイヤＬＴＵ内に存在し、前記第２の部分が、高々１マクロブロック（ＭＢ）のサイズであるように前記スライスの各々をサイジングすることとを備えるビデオ符号化方法。
39. デジタルビデオフレームをビデオスライスへ分割する手段と、
    各スライスの第１の部分が第１の物理レイヤ論理送信ユニット（ＬＴＵ）内に存在し、各スライスの第２の部分が第２の物理レイヤＬＴＵ内に存在し、 前記第２の部分が、高々１マクロブロック（ＭＢ）のサイズであるように前記スライスの各々をサイジングする手段とを備えるビデオ符号化システム。

Images