(57)【要約】本開示は、テレビ電話（ＶＴ）用途向けビデオソースレート制御のための技術に関する。ソースビデオ符号化レートは、ビデオのフレームに関して利用可能な符号化ビットの数を規定するフレームバジェットのデュアルバッファベースの推定を使用して制御されることができる。デュアルバッファベースの推定技術は、物理ビデオバッファのフルネスと仮想ビデオバッファのフルネスとを追跡することができる。そのとき、ソースビデオ符号化レートは、結果として得られたフレームバジェットに基づいて制御される。仮想バッファの内容は目標符号化レートによって課される制約に依存し、一方、物理バッファの内容は様々なチャネルの状態によって課される制約に依存する。物理ビデオバッファのフルネスの考慮は、ビデオソースレート制御技術がチャネル適応できることを可能にする。仮想ビデオバッファのフルネスの考慮により、ビデオソースレート制御技術はチャネルを圧倒する可能性のある過剰なビデオを符号化することを避けることが可能になる。
2009514448.tif 000002
【特許請求の範囲】
【請求項１】
符号化されたビデオを物理ビデオバッファに追加することと、
チャネルによる送信のために前記物理ビデオバッファから前記符号化されたビデオのパケットを除去することと、
目標符号化レートに対する前記符号化されたビデオの量を表す仮想ビデオバッファを保守することと、
前記物理ビデオバッファのフルネスおよび前記仮想ビデオバッファのフルネスに基づいて前記ビデオの実際の符号化レートを制御することと
を備える方法。
【請求項２】
前記チャネルは様々なチャネルの状態を呈し、さらに前記方法は前記様々なチャネルの状態に応答して時間にわたって前記物理ビデオバッファから様々な量の前記符号化されたビデオを除去する請求項１に記載の方法。
【請求項３】
実際の符号化レートを制御することは、前記物理ビデオバッファの前記フルネスおよび前記仮想ビデオバッファの前記フルネスのうちの最大がスキップ閾値以上である場合にビデオフレームの符号化をスキップすることを含む請求項１に記載の方法。
【請求項４】
前記物理ビデオバッファの前記フルネスおよび前記仮想ビデオバッファの前記フルネスのうちの最大が前記スキップ閾値未満である場合に前記ビデオのフレームに関して利用可能な符号化ビットの数を規定するフレームバジェットを推定することと、前記フレームバジェットに基づいて前記実際の符号化レートを制御することとをさらに備える請求項３に記載の方法。
【請求項５】
フレームバジェットを推定することは、目標ビットレート、目標フレームレート、前記物理ビデオバッファの前記フルネス、前記仮想ビデオバッファの前記フルネス、および前記スキップ閾値に基づいて前記符号化ビットの数を推定することを含む請求項４に記載の方法。
【請求項６】
以下の式に実質的に基づいて前記仮想ビデオバッファの前記フルネスを決定すること：
【数１】
2009514448.tif 000013
ここで、Ｗｎはビデオフレームｎに関する前記仮想ビデオバッファの前記フルネスであり、Ｗｎ−１はビデオフレームｎ−１に関する前記仮想ビデオバッファの前記フルネスであり、Ｂｎ−１はビデオフレームｎ−１に割り当てられた前記実際の符号化ビットであり、Ｒは前記目標ビットレートであり、Ｆは前記目標フレームレートである、
以下の式に実質的に従って前記実際の符号化レートを決定すること：
【数２】
2009514448.tif 000014
ここで、Ｘｎ＞Ｚ*Ｍの場合はΔ＝Ｘｎ／Ｆであり、Ｘｎ＜＝Ｚ*Ｍの場合はΔ＝Ｘｎ−Ｚ*Ｍであり、Ｖｎはビデオフレームｎに関する前記物理ビデオバッファの前記フルネスであり、ｗは正の整数であり、Ｍは前記スキップ閾値であり、Ｚは係数である
をさらに備える請求項５に記載の方法。
【請求項７】
前記物理ビデオバッファの前記フルネスおよび前記仮想ビデオバッファの前記フルネスのうちの最大が前記スキップ閾値未満である場合に前記ビデオのフレームに関して利用可能な符号化ビットの数を規定するフレームバジェットを推定することと、前記フレームバジェットに基づいて前記実際の符号化レートを制御することとをさらに備える請求項１に記載の方法。
【請求項８】
フレームバジェットを推定することは、目標ビットレート、目標フレームレート、前記物理ビデオバッファの前記フルネス、前記仮想ビデオバッファの前記フルネス、および前記スキップ閾値に基づいて前記符号化ビットの数を推定することを含む請求項７に記載の方法。
【請求項９】
以下の式に実質的に基づいて前記仮想ビデオバッファの前記フルネスを決定すること：
【数３】
2009514448.tif 000015
ここで、Ｗｎはビデオフレームｎに関する前記仮想ビデオバッファの前記フルネスであり、Ｗｎ−１はビデオフレームｎ−１に関する前記仮想ビデオバッファの前記フルネスであり、Ｂｎ−１はビデオフレームｎ−１に割り当てられた前記実際の符号化ビットであり、Ｒは前記目標ビットレートであり、Ｆは前記目標フレームレートである、
以下の式に実質的に従って前記実際の符号化レートを決定すること：
【数４】
2009514448.tif 000016
ここで、Ｘｎ＞Ｚ*Ｍの場合はΔ＝Ｘｎ／Ｆであり、Ｘｎ＜＝Ｚ*Ｍの場合はΔ＝Ｘｎ−Ｚ*Ｍであり、Ｖｎはビデオフレームｎに関する前記物理ビデオバッファの前記フルネスであり、ｗは正の整数であり、Ｍは前記スキップ閾値であり、Ｚは係数である
をさらに備える請求項８に記載の方法。
【請求項１０】
前記チャネルは無線チャネルであり、前記方法は、
前記無線チャネルのスループットを推定することと、
前記推定されたスループットに基づいて決定されたビデオパケットサイズを用いて前記物理ビデオバッファからビデオパケットを生成することと
をさらに備える請求項１に記載の方法。
【請求項１１】
オーディオパケットを生成することをさらに備え、ここにおいて前記ビデオパケットサイズは、前記推定されたスループット、および前記オーディオパケットのサイズに基づいて決定される請求項１０に記載の方法。
【請求項１２】
前記オーディオパケットおよび前記ビデオパケットに基づいて物理レイヤパケットを生成することと、移動体無線テレビ電話会議をサポートするためのリモートデバイスに前記物理レイヤパケットを送信することとをさらに備える請求項１１に記載の方法。
【請求項１３】
前記物理レイヤパケットはｃｄｍａ２０００  １ｘ  ＥＶ−ＤＯ  Ｒｅｌｅａｓｅ０規格に実質的に従う請求項１２に記載の方法。
【請求項１４】
前記実際の符号化レートに基づいて前記ビデオのフレームに関して利用可能な符号化ビットの数を規定するフレームバジェットを推定することと、
前記フレームバジェットに基づいて前記フレーム内のマクロブロックにロー領域値を割り当てることと
をさらに備える請求項１に記載の方法。
【請求項１５】
前記マクロブロックのそれぞれに符号化ビットの数を割り当てるために前記ロー領域値を対応する量子化パラメータ（ＱＰ）値にマップすることをさらに備える請求項１４に記載の方法。
【請求項１６】
前記符号化されたビデオの少なくとも一部が閾値を超える期間のあいだ前記物理ビデオバッファ内にあったときに前記物理ビデオバッファから前記符号化されたビデオの前記一部をドロップすることをさらに備える請求項１に記載の方法。
【請求項１７】
ビデオ符号器と、
前記ビデオ符号器によって符号化されたビデオを記憶する物理ビデオバッファと、
チャネルによる送信のために前記物理ビデオバッファから前記符号化されたビデオを除去するパケットシェーパと、
目標符号化レートに対する前記符号化されたビデオの量を表す仮想ビデオバッファと、
前記物理ビデオバッファのフルネスおよび前記仮想ビデオバッファのフルネスに基づいて前記ビデオの実際の符号化レートを制御するコントローラと
を備えるシステム。
【請求項１８】
前記チャネルは様々なチャネルの状態を呈し、前記パケットシェーパは前記様々なチャネルの状態に応答して時間にわたって前記物理ビデオバッファから様々な量の前記符号化されたビデオを除去する請求項１７に記載のシステム。
【請求項１９】
前記コントローラは、前記物理ビデオバッファの前記フルネスおよび前記仮想ビデオバッファの前記フルネスのうちの最大がスキップ閾値以上である場合にビデオフレームの符号化をスキップする請求項１７に記載のシステム。
【請求項２０】
前記コントローラは、前記物理ビデオバッファの前記フルネスおよび前記仮想ビデオバッファの前記フルネスのうちの最大が前記スキップ閾値未満である場合に前記ビデオのフレームに関して利用可能な符号化ビットの数を規定するフレームバジェットを推定し、前記フレームバジェットに基づいて前記実際の符号化レートを制御する請求項１９に記載のシステム。
【請求項２１】
前記コントローラは、目標ビットレート、目標フレームレート、前記物理ビデオバッファの前記フルネス、前記仮想ビデオバッファの前記フルネス、および前記スキップ閾値に基づいて前記フレームバジェットを推定する請求項２０に記載のシステム。
【請求項２２】
前記コントローラは、
以下の式に実質的に基づいて前記仮想ビデオバッファの前記フルネスを決定する：
【数５】
2009514448.tif 000017
ここで、Ｗｎはビデオフレームｎに対する前記仮想ビデオバッファの前記フルネスであり、Ｗｎ−１はビデオフレームｎ−１に対する前記仮想ビデオバッファの前記フルネスであり、Ｂｎ−１はビデオフレームｎ−１に割り当てられた前記実際の符号化ビットであり、Ｒは前記目標ビットレートであり、Ｆは前記目標フレームレートである、
以下の式に実質的に従って前記実際の符号化レートを決定する：
【数６】
2009514448.tif 000018
ここで、Ｘｎ＞Ｚ*Ｍの場合はΔ＝Ｘｎ／Ｆであり、Ｘｎ＜＝Ｚ*Ｍの場合はΔ＝Ｘｎ−Ｚ*Ｍであり、Ｖｎはビデオフレームｎに関する前記物理ビデオバッファの前記フルネスであり、ｗは正の整数であり、Ｍは前記スキップ閾値であり、Ｚは係数である
請求項２１に記載のシステム。
【請求項２３】
前記コントローラは、前記物理ビデオバッファの前記フルネスおよび前記仮想ビデオバッファの前記フルネスのうちの最大が前記スキップ閾値未満である場合に前記ビデオのフレームに関して利用可能な符号化ビットの数を規定するフレームバジェットを推定し、前記フレームバジェットに基づいて前記実際の符号化レートを制御する請求項１７に記載のシステム。
【請求項２４】
前記コントローラは、目標ビットレート、目標フレームレート、前記物理ビデオバッファの前記フルネス、前記仮想ビデオバッファの前記フルネス、および前記スキップ閾値に基づいて前記フレームバジェットを推定する請求項２３に記載のシステム。
【請求項２５】
前記コントローラは、
以下の式に実質的に基づいて前記仮想ビデオバッファの前記フルネスを決定する：
【数７】
2009514448.tif 000019
ここで、Ｗｎはビデオフレームｎに対する前記仮想ビデオバッファの前記フルネスであり、Ｗｎ−１はビデオフレームｎ−１に対する前記仮想ビデオバッファの前記フルネスであり、Ｂｎ−１はビデオフレームｎ−１に割り当てられた前記実際の符号化ビットであり、Ｒは前記目標ビットレートであり、Ｆは前記目標フレームレートである、
以下の式に実質的に従って前記実際の符号化レートを決定する：
【数８】
2009514448.tif 000020
ここで、Ｘｎ＞Ｚ*Ｍの場合はΔ＝Ｘｎ／Ｆであり、Ｘｎ＜＝Ｚ*Ｍの場合はΔ＝Ｘｎ−Ｚ*Ｍであり、Ｖｎはビデオフレームｎに対する前記物理ビデオバッファの前記フルネスであり、ｗは正の整数であり、Ｍは前記スキップ閾値であり、Ｚは係数である
請求項２４に記載のシステム。
【請求項２６】
前記チャネルは無線チャネルである、ここにおいて、前記パケットシェーパは前記無線チャネルのスループットを推定し、前記推定されたスループットに基づいて決定されたビデオパケットサイズを用いて前記物理ビデオバッファからビデオパケットを生成する請求項１７に記載のシステム。
【請求項２７】
オーディオパケットを生成するオーディオ符号器をさらに備える、ここにおいて前記ビデオパケットサイズは、前記推定されたスループット、および前記オーディオパケットのサイズに基づいて決定される請求項２６に記載のシステム。
【請求項２８】
前記オーディオパケットおよび前記ビデオパケットに基づいて物理レイヤパケットを生成し、移動体無線テレビ電話会議をサポートするためのリモートデバイスに前記物理レイヤパケットを送信する物理レイヤモジュールをさらに備える請求項２７に記載のシステム。
【請求項２９】
前記物理レイヤパケットはｃｄｍａ２０００  １ｘ  ＥＶ−ＤＯ  Ｒｅｌｅａｓｅ０規格に実質的に従う請求項２８に記載のシステム。
【請求項３０】
前記コントローラは、
前記実際の符号化レートに基づいて前記ビデオのフレームに関して利用可能な符号化ビットの数を規定するフレームバジェットを推定し、
前記フレームバジェットに基づいて前記フレーム内のマクロブロックにロー領域値を割り当てる
請求項１７に記載のシステム。
【請求項３１】
前記コントローラは、前記マクロブロックのそれぞれに符号化ビットの数を割り当てるために前記ロー領域値を対応する量子化パラメータ（ＱＰ）値にマップする請求項３０に記載のシステム。
【請求項３２】
前記物理ビデオバッファは、前記符号化されたビデオの少なくとも一部が閾値を超える期間のあいだ前記物理ビデオバッファ内にあったときに前記物理ビデオバッファから前記符号化されたビデオの前記一部をドロップする請求項１７に記載のシステム。
【請求項３３】
ビデオを符号化するための手段と、
前記符号化されたビデオを記憶するための物理ビデオバッファ手段と、
チャネルによる送信のために前記物理ビデオバッファ手段からの前記符号化されたビデオからビデオパケットを生成するためのパケットシェーピング手段と、
目標符号化レートに対する前記符号化されたビデオの量を表す仮想ビデオバッファを保守するための仮想バッファ手段と、
前記物理ビデオバッファのフルネスおよび前記仮想ビデオバッファのフルネスに基づいて前記ビデオの実際の符号化レートを制御するための制御手段と
を備えるシステム。
【請求項３４】
前記チャネルは様々なチャネルの状態を呈し、前記パケットシェーピング手段は前記様々なチャネルの状態に応答して時間にわたって前記物理ビデオバッファから様々な量の前記符号化されたビデオを除去する請求項３３に記載のシステム。
【請求項３５】
前記制御手段は、前記物理ビデオバッファの前記フルネスおよび前記仮想ビデオバッファの前記フルネスのうちの最大がスキップ閾値以上である場合にビデオフレームの符号化をスキップするための手段を含む請求項３３に記載のシステム。
【請求項３６】
前記制御手段は、前記物理ビデオバッファの前記フルネスおよび前記仮想ビデオバッファの前記フルネスのうちの最大が前記スキップ閾値未満である場合に前記ビデオのフレームに関して利用可能な符号化ビットの数を規定するフレームバジェットを推定するための手段と、前記フレームバジェットに基づいて前記実際の符号化レートを制御するための手段とを含む請求項３５に記載のシステム。
【請求項３７】
フレームバジェットを推定するための前記手段は、目標ビットレート、目標フレームレート、前記物理ビデオバッファの前記フルネス、前記仮想ビデオバッファの前記フルネス、および前記スキップ閾値に基づいて前記符号化ビットの数を推定するための手段を含む請求項３６に記載のシステム。
【請求項３８】
前記チャネルは無線チャネルであり、前記パケットシェーピング手段は、前記無線チャネルのスループットを推定するための手段と、前記推定されたスループットに基づいて決定されたビデオパケットサイズを用いて前記物理ビデオバッファからビデオパケットを生成するための手段とを含む請求項３３に記載のシステム。
【請求項３９】
オーディオパケットを生成するための手段をさらに備える、ここにおいて前記パケットシェーピング手段は、前記推定されたスループット、および前記オーディオパケットのサイズに基づいて前記ビデオパケットサイズを決定する請求項３８に記載のシステム。
【請求項４０】
前記オーディオパケットおよび前記ビデオパケットに基づいて物理レイヤパケットを生成するための手段と、移動体無線テレビ電話会議をサポートするためのリモートデバイスに前記物理レイヤパケットを送信するための手段とをさらに備える請求項３８に記載のシステム。
【請求項４１】
前記物理レイヤパケットはｃｄｍａ２０００  １ｘ  ＥＶ−ＤＯ  Ｒｅｌｅａｓｅ０規格に実質的に従う請求項４０に記載のシステム。
【請求項４２】
前記制御手段は、
前記実際の符号化レートに基づいて前記ビデオのフレームに関して利用可能な符号化ビットの数を規定するフレームバジェットを推定するための手段と、
前記フレームバジェットに基づいて前記フレーム内のマクロブロックにロー領域値を割り当てるための手段と、
前記マクロブロックのそれぞれに符号化ビットの数を割り当てるために前記ロー領域値を対応する量子化パラメータ（ＱＰ）値にマップするための手段と
を含む請求項３３に記載のシステム。
【請求項４３】
前記符号化されたビデオの少なくとも一部が閾値を超える期間のあいだ前記物理ビデオバッファ手段内にあったときに前記物理ビデオバッファ手段から前記符号化されたビデオの前記一部をドロップするための手段をさらに備える請求項３３に記載のシステム。
【請求項４４】
１つまたはそれより多くのプロセッサに
符号化されたビデオを物理ビデオバッファに追加させ、
チャネルによる送信のために前記物理ビデオバッファから前記符号化されたビデオのパケットを除去させ、
目標符号化レートに対する前記符号化されたビデオの量を表す仮想ビデオバッファを保守させ、
前記物理ビデオバッファのフルネスおよび前記仮想ビデオバッファのフルネスに基づいて前記ビデオの実際の符号化レートを制御させる
ための複数の命令を備えるコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示はテレビ電話（ＶＴ）に関し、より具体的には、ＶＴシステムにおけるビデオソースレート制御のための技術に関する。
【背景技術】
【０００２】
本願は、２００５年１０月２７日に出願された米国仮出願第６０／７３１，６１４号の利益(benefit)を主張するものである。
【０００３】
テレビ電話（ＶＴ）は、オーディオおよびビデオデータを搬送するパケットのリアルタイム通信を伴う。ＶＴデバイスは、ビデオカメラまたはビデオアーカイブなどのビデオキャプチャ(capture)デバイスからビデオを取得し、ビデオパケットを生成するビデオ符号器を含む。同様に、ＶＴデバイスにおけるオーディオ符号器は、マイクロホンまたは音声合成装置(synthesizer)などのオーディオキャプチャデバイスからオーディオを取得し、オーディオパケットを生成する。ビデオパケットおよびオーディオパケットは、無線リンクプロトコル（radio link protocol）（ＲＬＰ）キューに置かれる。媒体アクセス制御（ＭＡＣ）レイヤモジュールは、ＲＬＰキューの内容から媒体アクセス制御（ＭＡＣ）レイヤパケットを生成する。ＭＡＣレイヤパケットは、別のＶＴデバイスへの通信チャネルにわたる送信のために物理（ＰＨＹ）レイヤパケットに変換される。
【０００４】
移動体ＶＴアプリケーションにおいて、ＶＴデバイスは、基地局から無線端末としてのＶＴデバイスへの無線順方向リンク（ＦＬ）（または「ダウンリンク」）を介して物理レイヤパケットを受信する。ＶＴデバイスは、無線逆方向リンク（ＲＬ）（または「アップリンク」）を介して基地局にＰＨＹレイヤパケットを送信する。各ＶＴデバイスは、受信ＰＨＹおよびＭＡＣレイヤパケットを変換し、パケットペイロードをオーディオパケットおよびビデオパケットにリアセンブルリアセンブルする(reassemble)ためのＰＨＹおよびＭＡＣレイヤを含む。ＶＴデバイス内のビデオ復号器は、ディスプレイデバイスを介したユーザへの表示のためにビデオデータを復号する。ＶＴデバイス内のオーディオ復号器は、オーディオスピーカを介した出力のためにオーディオデータを復号する。
【０００５】
無線環境内の移動体ＶＴは困難である可能性がある。無線チャネル上のデータレートは制限され、時間と共に変わる。例えば、ＣＤＭＡ２０００  １ｘ  ＥＶ−ＤＯ  Ｒｅｌｅａｓｅ０ネットワークにおいて、データレートは、無線カバレージエリア内のチャネルの状態、またはマルチプル(multiple)ＶＴユーザ間のトラヒック混雑が原因で変わる可能性がある。さらに、例えば送信すべきデータがないとき等、データレートが０に落ちるとき、妥当なデータレートへの復帰(recovery)は時間を要する可能性がある。結果として、移動体ＶＴは望ましくないビデオおよびオーディオ遅延の影響を受けやすい可能性があり、それはリアルタイムの円滑なテレビ会議を持続する能力を害する(undermines)。
【発明の開示】
【０００６】
［発明の概要］
概して、本開示は、ＶＴ用途向けのビデオソースレート制御のための技術に関する。チャネルの状態、過剰なビデオ内容、またはそれら両方はビデオの送信の大きな遅延を引き起こす可能性がある。例えば逆方向リンク（ＲＬ）のスループットが減少されると、ビデオはＲＬを圧倒し(overwhelm)、ビデオ送信遅延を大きくする可能性がある。本開示は、ある範囲のチャネルの状態にわたってビデオ遅延を減少させるためにソースビデオの符号化レートを制御するための技術を提供する。この意味で、ビデオソースレート制御技術はチャネル適応できる(channel-adaptive)ものである。この技術は、ビデオソースの符号化レートがチャネルの状態または過剰なビデオ内容もしくは複雑性が原因で減少されるとき、空間的および時間的品質の劣化を減少させることに有効である可能性がある。
【０００７】
一部の実施形態において、ソースビデオの符号化レートは、ビデオのフレームに関して利用可能な符号化ビットの数を規定する(defines)フレームバジェット（budget）のデュアルバッファ（dual-buffer）ベースの推定を使用して制御される。デュアルバッファベースの推定技術は、閾値に対する物理ビデオバッファのフルネス(fullness)と仮想ビデオバッファのフルネスとを追跡する(track)ことができる。そのとき、ソースビデオの符号化レートは、結果として得られたフレームバジェットに基づいて制御される。仮想ビデオバッファの内容は目標符号化レートによって課されるビットの制約に依存し、一方、物理ビデオバッファの内容は、例えば、ＲＬのスループット等の、様々なチャネルの状態によって課されるチャネル制約に依存する。
【０００８】
物理ビデオバッファのフルネスの考慮は、ビデオソースレート制御技術がチャネル適応できることを可能にする。物理ビデオバッファ内の符号化されたビデオの量は少なくとも部分的に、チャネルが追加的なビデオパケットに適応できるレートの関数である。仮想ビデオバッファのフルネスの考慮は、ビデオソースレート制御技術がチャネルを圧倒する可能性がある過剰なビデオを符号化することを避けることを可能にする。
【０００９】
ビデオソースレート制御技術は、チャネルの状態に基づいて物理ビデオバッファから抽出されるビデオパケットのサイズを制御するチャネル適応ビデオパケットシェーピング技術と併せて使用されることができる。チャネルの状態は、フレームバジェットを公式化すること(formulating)に使用するためのチャネルの状態の間接的な指示を提供する、物理ビデオバッファから除去されるビデオの量に影響を与える。いったんフレームバジェットが確立されると、フレームバジェットの一部を各フレーム内の個々のビデオブロックに割り当てるためにビデオブロックバジェット（video block budget）がロー領域（rho domain）において推定されることもできる。
【００１０】
一実施形態において、本開示は、物理ビデオバッファに符号化されたビデオを追加することと、チャネルによる送信のために物理ビデオバッファから符号化されたビデオのパケットを除去することと、目標符号化レートに対する符号化されたビデオの量を表す仮想ビデオバッファを保守することと、物理ビデオバッファのフルネスおよび仮想ビデオバッファのフルネスに基づいてビデオの実際の符号化レートを制御することとを備える方法を提供する。
【００１１】
本開示は、１つまたはそれより多くのプロセッサにそのような方法を実行させるための複数の命令を有するコンピュータ可読媒体も想定する。例えば、本開示は、１つまたはそれより多くのプロセッサに、物理ビデオバッファに符号化されたビデオを追加させ、チャネルによる送信のために物理ビデオバッファから符号化されたビデオのパケットを除去させ、目標符号化レートに対する符号化されたビデオの量を表す仮想ビデオバッファを保守させ、物理ビデオバッファのフルネスおよび仮想ビデオバッファのフルネスに基づいてビデオの実際の符号化レートを制御させるための複数の命令を備えるコンピュータ可読媒体も提供する。
【００１２】
別の実施形態において、本開示は、ビデオ符号器と、ビデオ符号器によって符号化されたビデオを記憶する物理ビデオバッファと、チャネルによる送信のために物理ビデオバッファから符号化されたビデオを除去するパケットシェーパ(shaper)と、目標符号化レートに対する符号化されたビデオの量を表す仮想ビデオバッファと、物理ビデオバッファのフルネスおよび仮想ビデオバッファのフルネスに基づいてビデオの実際の符号化レートを制御するコントローラとを備えるシステムを提供する。
【００１３】
１つまたは複数の実施形態の詳細が添付の図面および以下の記述において説明される。その他の機能、目的、および利点はこれらの記述および図面から、ならびに特許請求の範囲から明らかになるであろう。
【００１４】
［詳細な説明］
図１は、ビデオ符号化および復号システム１０を示すブロック図である。図１に示されるように、システム１０は、送信チャネル１６によって接続された符号器システム１２および復号器システム１４を含む。図１の例において、符号器システム１２は第１のビデオ通信デバイスに関連付けられ、オーディオソース１７と、ビデオソース１８と、ビデオ符号器２０と、オーディオ符号器２２と、ビデオパケットシェーパ２４と、リアルタイムトランスポートプロトコル（ＲＴＰ）／ユーザデータグラムプロトコル（ＵＤＰ）／インターネットプロトコル（ＩＰ）／ポイントツーポイントプロトコル（ＰＰＰ）変換モジュール２６と、無線リンクプロトコル（ＲＬＰ）キュー２８と、ＭＡＣレイヤモジュール３０と、物理（ＰＨＹ）レイヤモジュール３２とを含む。復号器システム１４は別のビデオ通信デバイスに関連付けられ、ＰＨＹレイヤモジュール３４と、ＭＡＣレイヤモジュール３６と、ＲＬＰキュー３８と、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール４０と、ビデオ復号器４２と、オーディオ復号器４４と、オーディオ出力デバイス４６と、ビデオ出力デバイス４８とを含む。
【００１５】
説明されるように、ビデオ符号器２０は、例えばＣＤＭＡ２０００  １ｘ  ＥＶ−ＤＯ  Ｒｅｌｅａｓｅ０ネットワークにおいて存在するチャネルスループット条件などの様々なチャネルスループット条件の下でビデオ遅延を減少するためにチャネル適応ビデオソースレート制御を提供する。逆方向リンク（ＲＬ）のスループットはＥＶ−ＤＯ  Ｒｅｌｅａｓｅ０ネットワーク内のビデオ遅延における重要な要因である。ビデオ符号器２０は、少なくとも部分的にＲＬのスループットの関数としてビデオソース符号化レートを制御することができる。ビデオ符号器２０は、例えば５００ミリ秒未満の、低いエンドツーエンド(end-to-end)遅延の要求を有する環境において有用である可能性がある。エンドツーエンド遅延は、例えば移動体無線ＶＴシステムにおける送信者と受信者の間のビデオの送信における遅延を指す。本開示において説明されるチャネル適応ソースレート制御は、無線チャネルのような、可変ビットレート（ＶＢＲ）送信チャネルまたは固定ビットレート（ＣＢＲ）送信チャネルのいずれかで動作しているときに空間的な表示品質と時間的な表示品質の間の折り合いを付けながらビデオ送信のエンドツーエンド遅延を適応可能に制御することができる。
【００１６】
ビデオ符号器２０は、ビデオソース符号化レートがチャネルの状態、または過剰なビデオ内容もしくは複雑性が原因で減少されるときに空間的および時間的品質の劣化を小さくすることに有効である可能性がある。既存のレート制御スキーム(schemes)は、空間的ビデオ品質と時間的ビデオ品質の間の妥当なトレードオフを伴う望ましいエンドツーエンド遅延をサポートしない。例えば、小さい固定ビデオバッファサイズの使用は、結果的に、スキップされるフレームの大きなパーセンテージとなり、ぎくしゃくした(jerky)動きおよび低い空間的な表示品質をもたらす可能性がある。逆に、大きなビデオバッファサイズの使用はより良好な空間的品質をもたらすことができるが、しかし、エンドユーザを混乱させ、いらだたせる可能性のある、より大きな可変的な遅延を生じさせる傾向がある。
【００１７】
概して、ビデオソース符号化レート制御の性能は、バッファ遅延および送信遅延を含むエンドツーエンド遅延と、空間的な表示品質と、スキップされたビデオフレームの数と、帯域幅の過小利用(underutilization)を示す符号器バッファアンダーフロー(underflow)と、フレームのスキップを発生させる符号器のバッファオーバフローと、復号すべきデータがないことおよびより少ないディスプレイリフレッシュを示す復号器のバッファアンダーフローと、失われたデータを示す復号器バッファオーバフローと、受信機ディスプレイリフレッシュレートと、オーディオビデオ同期と、符号器側ピーク信号対雑音比（ＰＳＮＲ）と、第１のイントラ(intra)（Ｉ）フレームに後続する初期バッファ遅延とを参照することによって評価されることができる。
【００１８】
本開示によるビデオ符号器２０は、ビデオのフレームに関して利用可能な符号化ビットの数を規定するフレームバジェットの推定のためにデュアルバッファベースのスキームを使用することができる。デュアルバッファベースの推定技術は、閾値に対する物理ビデオバッファのフルネスと仮想ビデオバッファのフルネスとを追跡することができる。そのとき、ソースビデオ符号化レートが、結果として得られたフレームバジェットに基づいて制御される。仮想ビデオバッファの内容は目標符号化レートによって課されるビット制約に依存し、一方、物理ビデオバッファの内容は様々なチャネルの状態によって課されるチャネルの制約、例えば、逆方向リンク（ＲＬ）のスループットに依存する。このようにして、ビデオ符号器２０は、少ないフレームのスキップおよび良好な空間的品質と共に、指定された(specified)目標符号化レートおよび指定されたエンドツーエンド遅延をサポートすることができる可能性がある。
【００１９】
一部の実施形態において、ビデオ符号器２０は、チャネルの状態に基づいてビデオパケットシェーピングを実行するビデオパケットシェーパ２４と共に作動することができる。例えば、ビデオパケットシェーパ２４は、チャネルの状態に少なくとも部分的に基づくパケットサイズでビデオをパケット化することができる。一部の実施形態において、ビデオパケットシェーパは、過度のオーディオ遅延を避けるためにビデオパケット送信よりもオーディオパケット送信を優先させることができる。ビデオパケットシェーパ２４は、チャネル１６による送信のために物理ビデオバッファからビデオパケットが除去されるレートとビデオパケットのサイズとを制御することができる。
【００２０】
そして今度は、ビデオパケットのサイズおよびレートが物理ビデオバッファのフルネスに影響を与える。悪い(poor)チャネルの状態に対して、ＲＬを圧倒することを避けるために、ビデオパケットのサイズとビデオパケットが生成されるレートとがビデオパケットシェーパ２４によって小さくされることができる。より良好なチャネルの状態に関して、ビデオパケットのサイズとビデオパケットが生成されるレートとがビデオパケットシェーパ２４によって増加されることができる。ビデオ符号器２０は仮想ビデオバッファフルネスと共に物理ビデオバッファフルネスを監視し、チャネルの状態およびビット制約に従って符号化レートを適応可能に制御する。
【００２１】
システム１０は、例えば、送信チャネル１６を介したテレビ電話のために双方向ビデオおよびオーディオ送信を提供することができる。したがって、概して相互(reciprocal)符号化、復号、および変換モジュールが、チャネル１６の両端に提供されることができる。一部の実施形態において、符号器システム１２および復号器システム１４は、ビデオストリーミング、テレビ電話、またはそれら両方のために装備された無線移動体端末などのビデオ通信デバイス内に具現化されることができる。移動体端末は、ＲＴＰ、ＵＤＰ、ＩＰ、またはＰＰＰなどのパケット交換規格に従ってＶＴをサポートすることができる。
【００２２】
ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュールは、オーディオ符号器２２およびビデオパケットシェーパ２４から受信されたオーディオおよびビデオデータに適切なＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰヘッダを追加し、当該データをＲＬＰキュー２８に置く。ＲＴＰはＵＤＰ上で動作する一方、ＵＤＰはＩＰ上で動作し、ＩＰはＰＰＰ上で動作する。ＭＡＣレイヤモジュール３０は、ＲＬＰキュー２８の内容からＭＡＣ  ＲＬＰパケットを生成する。ＰＨＹレイヤモジュール３２は、ＭＡＣ  ＲＬＰパケットをチャネル１６による送信のためにＰＨＹレイヤパケットに変換する。
【００２３】
復号システム１４のＰＨＹレイヤモジュール３４およびＭＡＣレイヤモジュール３６は互恵的な(reciprocal)やり方で動作する。ＰＨＹレイヤモジュール３４は、チャネル１６から受信されたＰＨＹレイヤパケットをＭＡＣ  ＲＬＰパケットに変換する。ＭＡＣレイヤモジュール３６は、ＭＡＣ  ＲＬＰパケットをＲＬＰキュー３８に置く。ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール４０は、ＲＬＰキュー３８内のデータからヘッダ情報を除去し、ビデオ復号器４２およびオーディオ復号器４４にそれぞれ送達するためのビデオデータおよびオーディオデータをリアセンブルする。
【００２４】
システム１０は、符号分割多元接続（ＣＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、時分割多元接続（ＴＤＭＡ）、もしくは直交周波数分割多重（ＯＦＤＭ）などの１つもしくはそれより多くの無線通信技術、または別の好適な無線技術をサポートするように設計されることができる。上記の無線通信テクノロジーは、種々の無線接続技術のうちの任意のものに従って送達されることができる。例えば、ＣＤＭＡは、ｃｄｍａ２０００または広帯域ＣＤＭＡ（ＷＣＤＭＡ）規格に従って送達されることができる。ＴＤＭＡは、移動体通信用グローバルシステム（Global System for Mobile Communications）（ＧＳＭ）規格に従って送達されることができる。ユニバーサル移動体通信システム（Universal Mobile Telecommunication System）（ＵＭＴＳ）規格はＧＳＭまたはＷＣＤＭＡの動作を許す。概して、ＶＴアプリケーションに関して、システム１０は、ｃｄｍａ２０００  １ｘ  ＥＶ−ＤＯ  Ｒｅｌｅａｓｅ０またはその後のＥＶ−ＤＯのリリースなどの高データレート（high data rate）（ＨＤＲ）テクノロジーをサポートするように設計される。
【００２５】
ビデオ符号器２０は、ＭＰＥＧ−４などのビデオ圧縮方法に従って符号化されたビデオデータを生成する。国際電気通信連合（ＩＴＵ）Ｈ．２６３、ＩＴＵ  Ｈ．２６４、またはＭＰＥＧ−２の方法などのその他のビデオ圧縮方法が使用されることができる。オーディオ符号器２２は、ビデオデータに付随するようにオーディオデータを符号化する。ビデオソース１８は、１つもしくはそれより多くのビデオカメラ、１つもしくはそれより多くのビデオアーカイブ、またはビデオカメラとビデオアーカイブとの組合せなどのビデオキャプチャデバイスであってよい。
【００２６】
オーディオデータは、アダプティブマルチレート・ナローバンド（adaptive multi-rate narrow band）（ＡＭＲ−ＮＢ）、またはその他の技術などのオーディオ圧縮方法に従って符号化されることができる。オーディオソース１７は、マイクロホンまたは音声合成装置などのオーディオキャプチャデバイスであってよい。ＶＴアプリケーションに関して、ビデオはＶＴ会議の参加者が見ることを可能にし、オーディオはその参加者の話し声が聞かれることができるようにする。
【００２７】
動作中、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６は、ビデオ符号器２０およびオーディオ符号器２２からビデオデータパケットおよびオーディオデータパケットを取得する。上述のように、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６は、オーディオパケットに適切なヘッダ情報を追加し、結果として得られたデータをＲＬＰキュー２８に挿入する。同様に、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６は、ビデオパケットに適切なヘッダ情報を追加し、結果として得られたデータをＲＬＰキュー２８に挿入する。ＭＡＣレイヤモジュール３０はＲＬＰキュー２８からデータを取り出し(retrieves)、ＭＡＣレイヤパケットを形成する。各ＭＡＣレイヤパケットは、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰヘッダ情報と、ＲＬＰキュー２８に含まれるオーディオまたはビデオパケットデータとを搬送する。
【００２８】
オーディオパケットはビデオパケットとは独立にＲＬＰキュー２８に挿入される。しかし、パケットシェーパ２４は、各オーディオパケットが次の利用可能なＭＡＣレイヤパケットによって搬送されることができるようにＲＬＰキュー２８に追加されるビデオパケットのサイズを制御する。場合によっては、ＲＬＰキュー２８の内容から生成されるＭＡＣレイヤパケットは、ヘッダ情報およびビデオパケットデータだけを搬送する。その他の場合、ＭＡＣレイヤパケットは、ヘッダ情報およびオーディオパケットデータだけを搬送する。
【００２９】
多くの場合、ＭＡＣレイヤパケットは、ＲＬＰキュー２８の内容に応じてヘッダ情報、オーディオパケットデータ、およびビデオパケットデータを搬送する。ＭＡＣレイヤパケットは、無線リンクプロトコル（ＲＬＰ）に従って構成されることができ、ＭＡＣ  ＲＬＰパケットと呼ばれる場合がある。ＰＨＹレイヤモジュール３２は、ＭＡＣ  ＲＬＰオーディオビデオパケットをチャネル１６を介した送信のためにＰＨＹレイヤパケットに変換する。
【００３０】
チャネル１６は、ＰＨＹレイヤパケットを復号器システム１４に搬送する。チャネル１６は、符号器システム１２と復号器システム１４の間の任意の物理的接続であってよい。例えば、チャネル１６は、ローカルまたは広域有線ネットワークなどの有線接続であってよい。代替的に、本明細書において説明されるように、チャネル１６は、セルラ、衛星、または光接続などの無線接続であってよい。チャネルの状態は、有線および無線チャネルに関する問題である可能性があるが、チャネルの状態がフェージング(fading)および混雑(congestion)のために悪くなる可能性がある無線チャネル１６を介して実行される移動体ＶＴアプリケーションに関して特に問題が多い。
【００３１】
本開示によれば、ビデオ符号器２０は、ビデオソース１８からのビデオを符号化し、符号化されたビデオを物理ビデオバッファに追加する。ビデオパケットシェーパ２４は、物理ビデオバッファ内のビデオ内容をパケット化し、チャネル１６を介した送信のために物理ビデオバッファから符号化されたビデオのパケットを除去する。ビデオパケットシェーパ２４が物理ビデオバッファからビデオパケットを除去するレートと、パケットのサイズとは、チャネル１６に関連するチャネルの状態に部分的に依存する。例えば、チャネル１６は、チャネルの状態に従って変わるスループットを有する逆方向リンク（ＲＬ）によって特徴付けられることができる。
【００３２】
ビデオ符号器２０は、目標符号化レートに対する符号化されたビデオの量を表す仮想ビデオバッファを保守する。目標符号化レートは、チャネル１６を介して送信されるビデオパケットに対して指定される最大符号化レートであってよい。ビデオ符号器２０は、物理ビデオバッファのフルネスおよび仮想ビデオバッファのフルネスに基づいてビデオソース１８からのビデオの実際の符号化レートを制御する。物理ビデオバッファのフルネスの考慮は、ビデオ符号器２０によって適用されるビデオソースレート制御がチャネル適応できることを可能にする。物理ビデオバッファ内のビデオの量は部分的に、チャネルが追加的なビデオパケットに適応するレートの関数である。最大目標符号化レートが与えられたとすると、仮想ビデオバッファのフルネスの考慮は、ビデオ符号器２０によって適用されるビデオソースレート制御技術がチャネルを圧倒する可能性のある過剰なビデオの符号化を避けることを可能にする。
【００３３】
ビデオパケットシェーパ２４は、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６に提供される各ビデオパケットのサイズを制御する。ビデオパケットシェーパ２４は、物理ビデオバッファ内のビデオをパケット化し、チャネル１６を介した送信のためにビデオパケットを除去する任意のパケタイザ（packetizer）であってよい。しかし一部の実施形態において、ビデオソースレート制御技術は、チャネルの状態に部分的に基づいて物理ビデオバッファから抽出されるビデオパケットのサイズを制御し、オーディオ符号器２２からのオーディオパケットの送信を優先するチャネル適応ビデオパケットシェーピング技術と共に使用されることができる。
【００３４】
例えば、ビデオパケットシェーパ２４は、各オーディオパケットが次の利用可能なＭＡＣレイヤパケットによって収容されることができるようにビデオパケットのサイズを決める(size)ことができる。ビデオパケットの制御されたサイズ決定は、チャネルの状態、大きなビデオパケット、またはそれらの両方によって引き起こされるオーディオの遅延を防止する。オーディオパケットが利用可能であるとき、そのオーディオパケットは、ＭＡＣレイヤモジュール３０によって生成される次の利用可能なＭＡＣ  ＲＬＰパケットに含めるためにＲＬＰキューに置かれる。オーディオパケットは、オーディオパケットをＭＡＣ  ＲＬＰパケット内に置くためのスペースを与えるようにサイズ決めされたビデオパケットと結合されることができる。オーディオを優先することによって、ＶＴ会議のオーディオ部分は、たとえビデオ部分がチャネルの状態が原因で遅延を被る可能性があるとしても実質的な遅延なしに送信されることができる。チャネルの状態によりビデオがそこなわれる(compromised)可能性があるが、ビデオパケットシェーパ２４はオーディオを優先して、ＶＴ会議の参加者が言葉による会話を円滑に継続することがやはり可能であることを保証する。
【００３５】
ビデオパケットシェーパ２４は、そのビデオパケットシェーパ２４がチャネルの状態に基づいてビデオパケットサイズを調整することができるという意味でチャネル適応できるように構成されることができる。このように、符号器システム１２はオーディオパケットの送信を優先して、チャネルの状態が悪いときにオーディオの遅延を回避することができる。同時に、ビデオパケットシェーパ２４は、オーディオを優先した結果、十分にパケット化されていない(under-packetized) ビデオパケットにならないことを保証することができる。換言すれば、ビデオパケットシェーパ２４は、次の利用可能なＭＡＣ  ＲＬＰパケットに１つまたはそれより多くのオーディオパケットを含めることを可能にするのに十分なだけ小さく、しかしＭＡＣ  ＲＬＰパケット内の余分なスペースが無駄にされるほどには小さくないようにビデオパケットをサイズ決めする。その結果、ビデオパケットシェーパ２４は、オーディオパケットの優先、およびビデオパケットの効率的な送信の両方をサポートすることができる。チャネル適応ビデオパケットシェーピングが適用されと、オーディオデータに与えられるより高い優先度は、より大きなビデオの遅延を代償として行われることができる。ビデオの遅延は、逆方向リンク（ＲＬ）のスループットが減少されると増加する。過剰なビデオの遅延を防止するために、本開示によれば、ビデオソースレートがチャネルのスループットの関数として制御される。
【００３６】
復号器システム１４のＰＨＹレイヤモジュール３４は、ＰＨＹレイヤパケットからＭＡＣレイヤパケットを識別し、内容をＭＡＣ  ＲＬＰパケットにリアセンブルする。次に、ＭＡＣレイヤモジュール３６がＭＡＣ  ＲＬＰパケットの内容をリアセンブルして、ＲＬＰキュー３８に挿入するためのビデオパケットおよびオーディオパケットを提供する。ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰモジュール４０は、付随のヘッダ情報を除去し、ビデオパケットをビデオ復号器４２に提供し、オーディオパケットをオーディオ復号器４４に提供する。ビデオ復号器４２はビデオデータフレームを復号して、ディスプレイデバイスの駆動に使用するためにビデオデータのストリームを生成する。オーディオ復号器４４はオーディオデータを復号して、例えばオーディオスピーカを介してユーザに示すためのオーディオ情報を生成する。
【００３７】
上述したように、ビデオパケットシェーパ２４は、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６に提出されるビデオパケットのサイズを制御する。具体的には、ビデオパケットシェーパ２４は、ＭＡＣ  ＲＬＰパケットにおいてオーディオパケットの送信を優先するためにビデオパケットのサイズを制御し、ビデオパケットがＲＬＰキュー２８を圧倒することを防止するように構成されることができる。このようにして、ＶＴ会議のオーディオ部分は、たとえビデオ部分がチャネルの状態が原因で遅延を被る可能性があるとしても実質的な遅延なしに送信されることができる。ビデオはチャネルの状態によりそこなわれる可能性があるが、ビデオパケットシェーパ２４は、ＶＴ会議の参加者が言葉による会話を円滑に継続することがやはり可能であることを保証する。
【００３８】
ビデオパケットシェーパ２４によって適用されるパケットシェーピング技術は、オーディオパケットの優先された送信を保証するための１つまたはそれより多くの規則を適用することができる。例えば１つの規則によれば、オーディオパケットは、ＲＬＰキュー２８の内容から生成された直ぐ次の利用可能なＭＡＣ  ＲＬＰパケットで送信されるべきである。オーディオフレームは、第１の周期的間隔(intervals)でオーディオ符号器２２によって生成される。ＭＡＣ  ＲＬＰパケットは、第２の周期的間隔でＭＡＣレイヤモジュール３０によって生成される。与えられた間隔で生成されたオーディオフレームは、ＭＡＣレイヤモジュール３０によって生成される次の利用可能なＭＡＣ  ＲＬＰパケット中に置かれるべきである。一部の実施形態において、オプションとして、ＲＬＰキュー２８の総出力キューサイズはオーディオパケットサイズと一緒に、１つのＭＡＣ  ＲＬＰパケットで搬送されることができるべきである。
【００３９】
種々の規則が、ＶＴシーケンスのあらゆるパケットに対して適用されることができる。一部のビデオパケットはオーディオおよびビデオが単一のＭＡＣ  ＲＬＰパケットで搬送されることができることを保証するやり方で本質的にサイズ決めされることができるが、その他のビデオパケットはより大きく、それで、特に、チャネルの状態が悪化するときにオーディオおよびビデオが単一のＭＡＣ  ＲＬＰパケットで搬送されることができることを保証するためにサイズの削減を必要とする可能性がある。ＶＴシーケンスのあらゆるパケットに対してこれらの技術を適用することによって、たとえビデオの内容が大きいか、またはチャネルの帯域幅が実質的に制限されるとしても満足できる音声通信が保証されることができる。
【００４０】
ビデオパケットシェーパ２４は、ＲＬＰキュー２８への挿入のためにＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６に提出される各ビデオパケットのサイズを制御する。ビデオパケットシェーパ２４は、大きなビデオ内容による連続的なＭＡＣ  ＲＬＰパケットの消費が原因でオーディオパケットが遅延されないことを保証することができる。その代わりに、オーディオが利用可能なとき、ビデオ符号器２０からのビデオは、各ＭＡＣ  ＲＬＰパケットがオーディオおよびビデオを搬送することを可能にするように選択されたサイズでパケットに分割される。各オーディオフレームは、ＲＬＰキュー２８に提供されるオーディオパケットとして使用されることができる。その代りに、一部の実施形態において、オーディオパケットは、連続的な間隔で提供されるマルチプルオーディオフレームをまとめる(bundle)ことができる。
【００４１】
一部の実施形態において、ビデオパケットシェーパ２４は、連続するオーディオフレームの間に生成されるＭＡＣレイヤパケットに関する推定されたチャネルのスループットに基づいて、各ＭＡＣレイヤに対するビデオパケットサイズを決定することができる。スループットは、現在の無線チャネルの送信レート、無線基地局の働き、および送信電力の制限のうちの１つまたはそれより多くのものによって表されるチャネルの状態に基づいて推定されることができる。例えば、チャネルの状態は、現在のＭＡＣレイヤのデータレート、リバースアクティビティ（ＲＡ）ビット（reverse activity (RA) bit）、および電力増幅器（ＰＡ）の制限に基づいて決定されることができる。本開示によれば、ビデオ符号器２０は、物理ビデオバッファのフルネスに部分的に基づいて適応(adaptive)ソースレート制御を適用する。この場合、ソースビデオ符号化レートは、チャネルの状態が当該ビデオ符号化レートをサポートしない場合、ビデオ符号器２０によって小さくされることができる。
【００４２】
図２は、ビデオソースレート制御を実装するビデオ符号化システム１０を示すブロック図である。図２に示されるように、ビデオ符号器２０は、ビデオ符号化エンジン５０、物理ビデオバッファ５２、およびビデオレートコントローラ５４を含む。ビデオ符号化エンジン５０は、ビデオソース１８からビデオデータを取得し、ビデオレートコントローラ５４によって制御されたレートでビデオデータを符号化する。次に、ビデオ符号化エンジン５０は符号化されたビデオを物理ビデオバッファ５２に置く。ビデオパケットシェーパ２４は、ビデオバッファ５２からビデオデータを除去し、チャネル１６を介した送信のためにビデオデータをパケット化する。ビデオパケットのサイズは部分的に、ＲＬのスループットなどのチャネル１６のチャネルの状態の関数であることができる。ビデオレートコントローラ５４は、物理ビデオバッファ５２のフルネスを監視し、フルネスに少なくとも部分的に基づいて、ビデオ符号化エンジン５０によって適用されるビデオ符号化レートを制御する。
【００４３】
符号化レートは、物理ビデオバッファ５２の現在のフルネスに従ってフレーム毎に更新されることができる。さらに、説明されるように、ビデオレートコントローラ５４は仮想ビデオバッファを保守することができる。このようにして、ビデオレートコントローラ５４は、ビデオのフレームに関して利用可能な符号化ビットの数を規定するフレームバジェットのデュアルバッファベースの推定を使用してソースビデオ符号化レートを制御することができる。デュアルバッファベースの推定技術は、閾値に対する仮想ビデオバッファのフルネスと物理ビデオバッファ５２のフルネスとを追跡する。そのとき、ビデオレートコントローラ５４は、結果として得られたフレームバジェットに基づいてソースビデオ符号化レートを制御する。
【００４４】
仮想ビデオバッファの内容が目標符号化レートによって課されるビットの制約に依存し、一方、物理ビデオバッファ５２の内容は、例えば、ＲＬのスループット等、様々なチャネルの状態によって課されるチャネルの制約に依存する。仮想ビデオバッファのサイズは、ＲＬのスループットに従ってスケールされる(scaled)ことができる。物理ビデオバッファ５２のフルネスの考慮は、ビデオソースレート制御技術がチャネル適応できることを可能にする。物理ビデオバッファ５２内のビデオの量は部分的に、チャネル１６が追加的なビデオパケットに適応するレートの関数である。仮想ビデオバッファのフルネスの考慮は、ビデオレートコントローラ５４がチャネル１６を圧倒する可能性がある過剰なビデオを符号化することを避けることを可能にする。仮想ビデオバッファのフルネスは、例えば目標ビットレートおよび目標フレームレート等を含む目標符号化レートの関数であることができる。実際には、仮想ビデオバッファは、フレームビット割り当ておよび／またはフレームスキップ(skipping)を制御するために使用されることができる。
【００４５】
ビデオ符号器２０は、いくつかの望ましい機能を提供することができる。例えば、ビデオ符号器２０は、概してＣＯＤＥＣ独立であるビデオソースレート制御スキームを提供することができる。例えば、ビデオ符号器２０は、ＭＰＥＧ４、ＩＴＵ  Ｈ．２６３、またはＩＴＵ  Ｈ．２６４に従うビデオ符号化に適合されることができる。さらに、ビデオ符号器２０は、ＤＳＰまたは埋込み型(embedded)論理コア内の簡単な実装をされることができる可能性がある。一部の実施形態において、ビデオ符号器２０は、例えば、ロー領域においてビデオブロックレート制御を適用する等、モデルベースのレート制御を適用することができる。例えば、いったんフレームビットバジェット（frame bit budget）が特定のビデオフレームに対して設定されると、当該フレームビットバジェットは、ロー領域レート制御を使用してフレーム内の、例えば、マクロブロック(macroblocks)（ＭＢｓ）等の、ビデオブロックの間に割り当てられることができる。そのとき、個々のＭＢｓに関するロー領域値は、量子化パラメータ（ＱＰ）値にマップされることができる。
【００４６】
図３は、ビデオソースレート制御がデュアルバッファベースのフレームバジェット推定を使用する図２のビデオ符号化システム１０の例示的実施形態を示すブロック図である。図３に示されるように、ビデオ符号化エンジン５０は、ビデオソース１８からビデオを取得し、例えばＭＰＥＧ４またはその他の符号化技術に従って符号化されたビデオデータのビットストリームを生成する。符号化されたビデオは物理ビデオバッファ５２に置かれる。図３の例において、ビデオレートコントローラ５４は、レート制御ユニット５６、バッファ情報ユニット５８、および仮想ビデオバッファ６０を含む。バッファ情報ユニット５８は、ビデオパケットシェーパ２４によって物理ビデオバッファから除去されるビデオパケットのサイズの関数である物理ビデオバッファ５２のフルネスを監視する。そしてまた、ビデオパケットのサイズは、ＲＬのスループットなどのチャネルの制約の関数である。さらに、バッファ情報ユニット５８は、ビデオ符号器２０によって符号化されるビデオの量の関数である仮想ビデオバッファ６０のフルネスと、目標ビットレートおよび目標フレームレートを含む目標符号化レートなどのビットレートの制約とを監視する。
【００４７】
物理ビデオバッファ５２のフルネスおよび仮想ビデオバッファ６０のフルネスに基づいて、バッファ情報ユニット５８はレート制御ユニット５６による分析のためのバッファ値を生成する。一部の実施形態において、バッファ情報ユニット５８は、物理ビデオバッファフルネスおよび仮想ビデオバッファフルネスのうちの最大をレート制御ユニット５６に提供されるバッファ値として生成することができる。物理ビデオバッファフルネスまたは仮想ビデオバッファフルネスは、仮想ビデオバッファ６０よりも物理ビデオバッファ５２を優先するか、またはその逆を優先するための係数によって重みづけされることができる。最初に、レート制御ユニット５６は、バッファ情報ユニット５８から受信されたバッファ値をスキップ閾値(skipping threshold)Ｔｓｋｉｐと比較することができる。
【００４８】
バッファ値がスキップ閾値Ｔｓｋｉｐ以上である場合、レート制御ユニット５６は、ビデオ符号化エンジン５０に次のビデオフレームの符号化をスキップするように命じる。この場合、次のフレームが符号化されないのでフレームバジェットを決定する必要はない。バッファ値がスキップ閾値Ｔｓｋｉｐ未満である場合、レート制御ユニット５６は、次のフレームを符号化するためにビデオ符号化エンジン５０によって使用されるべきフレームバジェットを決定する。フレームバジェットは、次のビデオフレームを符号化するために割り当てられる符号化ビット数を規定する。
【００４９】
フレームビットバジェット、すなわち、フレーム全体に対するビットの数を推定することに加えて、レート制御ユニット５６は、ビデオブロックバジェットも推定することができる。ビデオブロックバジェットは、フレーム内の、例えば、マクロブロック（ＭＢ）等の、各ビデオブロックに割り当てられる符号化ビットの数を規定する。フレームバジェットは、ビデオブロックに対して等しく割り当てられることができるか、またはビデオブロックバジェットスキームに基づいて割り当てられることができる。例えば、ビデオブロックバジェットは、各ＭＢに関して量子化パラメータ（ＱＰ）へのＭＢのビットバジェットおよびフレームのＭＢレベルのパラメトリックロー領域マッピング（MB-level parametric rho-domain mapping）を適用することができる。一部の実施形態において、各ＭＢ  ＱＰは、一様なイントラフレームの空間的品質を維持するために後処理される(post-processed)ことができる。可能なスキップされるＭＢｓのＱＰｓが、準拠したＭＰＥＧ−４ビットストリームを生成するために考慮されることができる。
【００５０】
一部の実施形態において、物理ビデオバッファ５２は、ビデオデータが閾値を超える期間のあいだバッファ内に存在する場合に当該ビデオデータをドロップするように構成されることができる。例えば、ビデオデータの特定のフレームがビデオ符号化エンジン５０によってビデオバッファ５２に置かれた後、その特定のフレームは、悪いチャネルの状態が原因で長期間物理ビデオバッファ内に残る可能性がある。この場合、より多くの符号化されたビデオがビデオ符号化エンジン５０から利用できる可能性があるが、物理ビデオバッファ５２内に利用可能なスペースがない可能性がある。新しく符号化されたデータを収容するために、物理ビデオバッファ５２は、例えば、先入れ先ドロップ(first-in-first-dropped)ベースで最も古いビデオデータをドロップするように構成されることができる。ビデオデータをドロップすることは、単に、ビデオデータを破棄すること(discarding)、当該ビデオデータによって前に占有されていたバッファスペースを新しく符号化されたビデオデータで上書きすることを伴う可能性がある。ドロップされたデータは、データのフレーム、または例えばバイトで測定されたある所定の量のデータであってよい。
【００５１】
ビデオデータは、それが閾値を超える期間のあいだ物理ビデオバッファ５２内にあった場合にドロップされることができる。その代りに、物理ビデオバッファ５２からビデオデータをドロップするための基準は、閾値を超える時間と、追加のビデオデータが符号化されている最中であるという符号化エンジン５０からの指示の両方を含む可能性があり、それは物理ビデオバッファ内のスペースを要求する。いずれの場合も、物理ビデオバッファ５２内のビデオデータの少なくとも一部分が、新しく符号化されたビデオデータのためのスペースを空けるためにドロップされる。ビデオデータをドロップすることと共に、物理ビデオバッファ５２はフィードバックを符号化エンジン５０に提供し、、ビデオデータがドロップされることを示すことができる。該フィードバックに応答して、符号化エンジン５０は符号化プロセスにおいて初期エラー制御技術を適用し、ドロップされたビデオデータのビデオ品質に対する影響を和らげることができる。
【００５２】
図４は、チャネル適応ビデオパケットシェーピングを実装するオーディオ／ビデオ符号化システム内の図２のビデオ符号化システム１０の統合を示すブロック図である。上述のように、チャネル適応ビデオソースレート制御は、任意のビデオパケット化スキームと共に使用されることができる。しかし、一部の用途において、チャネル適応ビデオソースレート制御を、上述のようにチャネル１６を介した送信に関してビデオよりもオーディオを優先するビデオパケットシェーピングスキームなどのチャネル適応ビデオパケットシェーピングスキームと共に適用することが望ましい可能性がある。
【００５３】
図４に示されるように、ビデオパケットシェーパ２４は、物理ビデオバッファ５２からビデオデータを除去し、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６に送達するためにビデオデータをパケット化する。この場合もまた、各パケットのサイズが、ビデオパケットシェーパ２４によって受信されたＲＬＰキューサイズおよびチャネル情報によって明らかにされるチャネルの状態に従って決定されることができる。オーディオ符号器２２は、オーディオ符号化エンジン６１およびオーディオバッファ／バンドラ(bundler)６２を含む。オーディオ符号化エンジン６１は、オーディオソースから受信されたオーディオを符号化する。オーディオバッファ／バンドラ６２は、オーディオ符号化エンジン６１からオーディオデータを受信し、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６に送達するためのオーディオフレームを生成する。ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６は、チャネル１６を介した送信のためにＭＡＣ  ＲＬＰパケットをＲＬＰキュー２８内に置く。
【００５４】
逆方向トラヒックチャネル（ＲＴＣ）ＭＡＣユニット６４はＲＴＣ  ＭＡＣプロトコルを実行して、チャネル１６の逆方向リンク（ＲＬ）を介して送信するために通信デバイスによって遵守される手順を提供する。便宜上、ＭＡＣレイヤモジュール３０およびＰＨＹレイヤモジュール３２は図４に示されていない。ビデオパケットシェーパ２４は、１つまたはそれより多くの入力に基づいて各ビデオパケットのサイズを制御する。該入力は、チャネルの状態と、ＲＬＰキューの特性と、オーディオパケットのサイズおよび状態とに関連する可能性がある。ビデオパケットシェーパ２４は、入力に基づいて推定されたサイズを用いてビデオパケットを生成する。ビデオパケットサイズは最小サイズになりやすい。
【００５５】
ビデオバッファ５２は、ビデオ符号器２０から受信されたビデオ情報をバッファし(buffers)、ビデオパケットシェーパ２４によるパケット化のためにビデオ情報を記憶する。オーディオバッファ６２は、オーディオ符号器２２から受信されたオーディオフレーム情報をバッファし、その情報をＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６に渡す(passes)。オーディオおよびビデオパケットは互いから独立してＲＬＰキュー２８に挿入される。ビデオパケットシェーパ２４によって生成されるビデオパケットのサイズは、ＭＡＣレイヤモジュール３０（図４に示されていない）によって生成される次の利用可能なＭＡＣ  ＲＬＰパケット中にオーディオパケットのための十分なスペースが存在することを保証するように制御されることができる。具体的には、ＲＬＰキュー２８はビデオパケットによって圧倒されず、ＲＬＰキュー内のオーディオパケットが次のＭＡＣ  ＲＬＰパケットによって送信されることができることを保証する。
【００５６】
図４の例において、ビデオパケットシェーパ２４は、オーディオパケットタイマ、オーディオの優先順位の値、ＲＬＰキューサイズ、およびチャネル情報を含むいくつかの入力を受信することができる。オーディオパケットタイマは、オーディオ情報がオーディオバッファ６２において現在利用可能であるかどうか、および利用可能である場合には各オーディフレームが送達されるタイミングを示す。例えばオーディオフレームが２０ｍｓ毎の間隔で送達される場合、オーディオパケットタイマは、オーディオフレームが利用可能であるときは２０ｍｓに設定される。一部の実施形態において、オーディオバッファ６２は、単一のパケットに組み込むために連続的なオーディオフレームをまとめるように構成されることができる。この場合、オーディオパケットタイマは、該オーディオパケットにまとめられるフレームの数に対応する倍数(multiple)であることができる。換言すれば、オーディオパケットタイマは、まとめられるフレームの該数に比例またはそうでなければ関連する値を有することができる。例えば３つのオーディオフレームがまとめられる場合、オーディオタイマは６０ｍｓに設定されることができる。したがって、オーディオパケットタイマは、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６を介してＲＬＰキュー２８に挿入するためにオーディオバッファ６２によって生成されるオーディオパケットのサイズも示す。
【００５７】
オーディオの優先順位の値は、オーディオおよびビデオの相対的優先度を規定し、したがって、オーディオおよびビデオに関連する遅延に影響を与える。例えば、オーディオの優先順位の値は、優先順位の値が小さいと、それだけ一層オーディオの遅延が少なくなるように定められることができる。したがって、オーディオの優先順位の値が増加するにつれて、オーディオの遅延が増加し、ビデオの遅延が減少する。反対に、オーディオの優先順位の値が減少するにつれて、オーディオの遅延が減少し、ビデオの遅延が増加する。したがって、オーディオの遅延は、オーディオの優先順位の値を追跡する。以下でより詳細に説明されるように、ビデオパケットシェーパ２４は、オーディオの優先順位の値を使用して各ビデオパケットのサイズを制御することができ、規定された(prescribed)オーディオパケットの遅延をもたらすことができる。
【００５８】
ビデオパケットシェーパ２４によって受信されるＲＬＰキューサイズは、ＲＬＰキュー２８にバッファされた現在のデータのサイズを表す。ビデオパケットシェーパ２４は、ＲＬＰキューサイズを使用してビデオパケットのサイズを制御する。ＲＬＰキュー２８が比較的満杯(full)である場合、ビデオパケットシェーパ２４は、ＲＬを圧倒することおよび過度のオーディオの遅延を生じさせることを防止するためにビデオパケットのサイズを小さくするように調整することができる。ＲＬＰキュー２８がより空いている場合、ビデオパケットシェーパ２４は、オーディオパケットのための十分なスペースを依然として提供しながらビデオパケットのサイズを増加させることができる。ＲＬＰキューサイズを用いて、ビデオパケットシェーパ２４は、ビデオパケットサイズをＲＬＰキュー２８のフルネスの関数として動的に調整することができる。ＲＬＰキューのフルネスは、過剰なビデオ内容、チャネルの状態の悪化、またはそれらの両方を示す可能性がある。ＲＬＰキューサイズの使用は、ビデオパケットシェーパ２４がビデオ内容の過負荷またはチャネルの状態の変化に反応する(react)ことができるやり方のうちの１つである。
【００５９】
ビデオパケットシェーパ２４は、逆方向トラヒックチャネル（ＲＴＣ）ＭＡＣユニット６４によって提供されるチャネル情報を監視することによってチャネルの状態の変化により直接的に反応することもできる。ＲＴＣ  ＭＡＣユニット６４は、現在のＭＡＣ  ＲＬレート、結合されたＲＡビット、およびヘッドルームの制限などのチャネル特性に関連する情報を生成する。ＭＡＣ  ＲＬレートは、ＲＬ上で利用可能な現在の送信レートを示す。ＲＡビットはリバース(reverse)アクティビティ(activity)ビットであり、それは関連する無線基地局が混雑している(busy)かどうかを示す。ヘッドルームの制限は、現在の送信電力に基づいて、送信において使用されることが許される最大レートを示すことができる。ＲＡビットは、基地局の不活動(inactivity)が原因でＲＬが混雑しているかまたは利用不可能である時を示す。ＰＡの制限は送信電力ヘッドルームを表し、そしてチャネルの状態が悪化した時を示す。
【００６０】
様々な入力に基づいて、ビデオパケットシェーパ２４は、ペイロードサイズの推定値を生成する。ペイロードサイズの推定値は、オーディオの優先順位の値が、オーディオが高い優先度を与えられるべきであることを指定する場合、オーディオパケットが次の利用可能なＭＡＣ  ＲＬＰパケットに含まれることを可能にするように選択される。ビデオパケットシェーパ２４は、ビデオバッファ５２からビデオを受信し、ペイロードサイズ推定および最小ビデオパケットサイズに基づいてビデオをパケット化する。最小ビデオパケットサイズは、ビデオパケットシェーパ２４によって生成されるべきビデオパケットの最小サイズを表す。実際は、最小ビデオパケットサイズは、ビデオパケットサイズの粒度(granularity)および帯域幅効率を制御する。より小さな最小ビデオパケットサイズの値に関して、ビデオパケットシェーピングは、オーディオに適応し、それによってオーディオの遅延を防止するという点においてより有効であるが、帯域幅の効率はより低い。より大きな最小ビデオパケットサイズの値に関しては、ビデオパケットシェーピングは、オーディオの遅延を防止することにおいてより有効性が低いが、より高い帯域幅効率を提供する。
【００６１】
図４にさらに示されるように、ビデオ符号器２０はビデオレートコントローラ５４を含むように構成され、それは物理ビデオバッファ５２からの物理ビデオバッファのフルネスの値に対応する。ビデオ符号器２０は、ビデオバッファのフルネスに基づいて適応ソースレート制御機能(feature)を提供する。ビデオバッファ５２が比較的満杯であるとき、ビデオレートコントローラ５４は、ビデオ符号化エンジン５０によって適用されるビデオ符号化レートを下げることによって応じる。ビデオバッファ５２がより空いているとき、ビデオレートコントローラ５４はソースビデオ符号化レートを上げる。このようにして、ビデオ符号化レートは、チャネルの状態が現在のビデオ符号化レートをサポートできない場合に下げられる。本明細書において説明されるように、チャネル適応ソースレート制御機能は、デュアルバッファフレームバジェット推定技術として実装されることができる。デュアルバッファフレームバジェット推定技術のさらなる詳細が以下で説明される。
【００６２】
概して、ビデオレートコントローラ５４は、ビデオレートコントローラによって保守される物理ビデオバッファ５２および仮想ビデオバッファの状態に基づいてビデオソース符号化レートを制御する。物理ビデオバッファ５２は、ビデオ符号化エンジン５０によって符号化されたビデオのフレームを受信する。仮想ビデオバッファ６０（図３）は、目標符号化レートに対する符号化されたビデオの量を示すためにフレーム毎に更新される。目標符号化レートは、目標ビットレートＲおよび目標フレームレートＦによって特徴付けられることができる。目標ビットレートＲの例は秒当り２４キロビット（Ｋｂｐｓ）である。目標フレームレートの例は秒当り７．５フレーム（ｆｐｓ）である。仮想バッファのフルネスの値は、以下の式によって表されることができる：
【数９】
2009514448.tif 000003
【００６３】
ここで、Ｗｎは符号化されたビデオフレームｎにおける仮想バッファのフルネスであり、Ｗｎ−１はフレームｎ−１における仮想バッファのフルネスであり、Ｂｎ−１はフレームｎ−１を符号化するためにビデオ符号化エンジン５０によって使用された符号化ビット(coding bits)の実際の数であり、Ｒは目標ビットレートであり、Ｆは目標符号化レートである。式（１）は、０またはＷｎ−１＋Ｂｎ−１−Ｒ／Ｆのいずれかのうちの最大を生成する。値Ｗｎ−１＋Ｂｎ−１−Ｒ／Ｆが負である場合、符号化されたビデオの量は比較的少ない。
【００６４】
バッファ情報ユニット５８（図３）は、仮想ビデオバッファ６０および物理ビデオバッファ５２のフルネスに基づいてバッファ値Ｘｎを生成する。例えば、バッファ値Ｘｎは、以下の式によって表されることができる：
【数１０】
2009514448.tif 000004
【００６５】
ここで、係数ｗは正の整数であり、Ｖｎはフレームｎにおける物理ビデオバッファ５２のフルネスを表す。係数ｗは、物理ビデオバッファのフルネス対仮想ビデオバッファのフルネスに対して与えられるべき重み(weight)を決定する重みづけ(weighting)値である。式（２）は、ｗ*ＶｎまたはＷｎのうちの大きいほうをバッファ値Ｘｎとして生成する。
【００６６】
レート制御ユニット５６は、バッファ値Ｘｎを使用して次のフレームをスキップするかどうかを決定する。具体的には、バッファ値Ｘｎがスキップ閾値Ｔｓｋｉｐ以上（すなわちＸｎ＞＝Ｔｓｋｉｐ）である場合、レート制御ユニット５６は、ビデオ符号化エンジン５０に次のフレームｎ＋１の符号化をスキップするように命じる。Ｘｎがスキップ閾値Ｔｓｋｉｐ以上であるとき、ビデオ符号器２０が、仮想ビデオバッファのフルネスによって明示されるそのビットの制約を超える恐れがあるか、または物理ビデオバッファ５２が、例えばチャネルの状態等のために、満杯になり過ぎているか、のいずれかである。例えば、チャネルの状態が悪い場合、ビデオパケットシェーパ２４は、物理ビデオバッファ５２から除去されるビデオパケットのサイズを小さくすること、および／またはパケットが除去されるレートを下げること、を行うことができる。この場合、ビデオ符号器２０によって適用される符号化レートを下げる必要がある。チャネル適応ビデオパケットシェーピングは、チャネルの状態とビデオソースレート制御との橋渡しをする(bridges)インターフェースを提供する。バッファ値Ｘｎは、チャネルの状態情報をビデオバッファフルネスに変換し、それはチャネルのスループットの間接的な表示を提供する。
【００６７】
バッファ値Ｘｎがスキップ閾値Ｔｓｋｉｐ未満（すなわちＸｎ＜Ｔｓｋｉｐ）である場合、レート制御ユニット５６（図３）は、次のフレームを符号化するために割り当てられるビットの数を規定するフレームバジェットを決定する。レート制御ユニット５６は、以下の式に従ってフレームｎに対するフレームバジェットＢｎを決定することができる：
【数１１】
2009514448.tif 000005
【００６８】
ここで、Ｘｎ＞Ｚ*Ｔｓｋｉｐの場合はΔ＝Ｘｎ／Ｆであり、Ｘｎ＜＝Ｚ*Ｍの場合はΔ＝Ｘｎ−Ｚ*Ｔｓｋｉｐであり、Ｚは係数である。概して、デルタ値（delta value）Δは、バッファのフルネス（ＷｎまたはＶｎ）、フレームレート（Ｆ）、およびチャネルのスループット（Ｒ）の関数である。値Ｒ、目標ビットレートはチャネルのスループットを表す。値Ｆ、目標フレームレートは、フレームが送信されることができるレートを表す。値Ｒ／Ｆ、すなわち、フレームレートで割られたチャネルのスループットＲは、フレーム当りのチャネルスループットを表す。
【００６９】
バッファ値がスキップ閾値ＴｓｋｉｐのＺ倍より大きい場合、適用できる仮想または物理バッファは比較的満杯である。この場合、バッファ値ＸｎはフレームレートＦによって割られ、その結果が、目標ビットレートを目標フレームレートで割ったものであるＲ／Ｆから引かれる。概して、このΔの値（＝Ｘｎ／Ｆ）は、ビデオ符号化エンジン５０によって適用される符号化レートの減少をもたらす。バッファ値がスキップ閾値ＴｓｋｉｐのＺ倍以下である場合、適用可能な仮想または物理バッファはより多くの符号化されたビデオを収容するのに十分なスペースを有する。この場合、スキップ閾値ＴｓｋｉｐをＺ倍した積のバッファ値がバッファ値Ｘｎから引かれる。概して、このΔの値（＝Ｘｎ−Ｚ*Ｔｓｋｉｐ）は、ビデオ符号化エンジン５０によって適用される符号化レートの増加をもたらす。
【００７０】
例として、１つの実装において、以下の要求が、ビデオ符号器２０によって適用されるビデオソースレート制御に適用されることができる。チャネルのビットレートＲが４８Ｋｂｐｓ（６０００バイト／秒）であり、フレームレートが１５ｆｐｓである場合、対応するフレームバジェットは４８００００／１５＝３２００ビット＝４００バイトである。０．４から０．６秒の最大エンドツーエンド(end-to-end)遅延の要求（例えば、４００から６００ｍｓ、およびより具体的には５００ｍｓ）を仮定すると、物理ビデオバッファの遅延の要求は２００ミリ秒（ｍｓ）以下である。この場合、仮想ビデオバッファ６０のサイズは１２００バイト（２００ｍｓ*６０００バイト／秒）に設定されることができる。上記の要求を満たすために、ビデオソースレート制御の設計は、あらゆるフレームに関して１２００バイト未満である物理ビデオバッファフルネスを有するべきである。さらに、物理ビデオバッファ５２の符号器バッファ(buffering)遅延は、あらゆるフレームに対して２００ｍｓ未満であるべきである。
【００７１】
ビデオ符号器２０は、ＲＬのスループットが減ると、ビデオ符号化レートを下げるが、しかしＲＬのスループットに対する過大または過小な反応(over- or under-reaction)を防止するためにＲＬのスループットにグレイスフルに(gracefully)適合する。理想的には、物理ビデオバッファ５２中において、バッファオーバフローが全くないかまたはバッファオーバフローが最小限であるだけでなく、バッファアンダーフローも全くないかまたはバッファアンダーフローも最小限であるべきである。バッファアンダーフローは帯域幅の過小利用を示す一方、バッファオーバフローは、その結果としてフレームがスキップされる、すなわち、符号化されたビデオフレームを収容するのに十分なスペースが物理ビデオバッファ５２にないと、フレームの符号化がスキップされる。本明細書に記載のデュアルバッファベースのレート制御スキームを用いて、エンドツーエンドビデオ遅延は、空間的品質を改善しながら減少されることができる。このようにして、帯域幅の与えられた量で符号化品質を実質的に最大化するための良好なバランスが達成されることができる。例えば５００ｍｓ未満等の厳しい低エンドツーエンド遅延要求は、フレームスキップ(skipping)が少なくかつバッファアンダーフローが全くないか最小であることにより満足されることができる。
【００７２】
仮想ビデオバッファ６０は、バッファベースのビット割り当ておよびフレームスキップを使用することによって遅延要求を満足することを助ける。物理ビデオバッファ５２は、チャネルの状態へのビデオ符号化レートの適応を可能にする。上記の式（１）〜（３）にしたがい、チャネルの状態が良好なとき、仮想ビデオバッファのフルネスの値Ｗｎがレート制御のために使用される。チャネルの状態が悪いとき、ＲＴＰレイヤからの物理ビデオバッファのフルネスの値Ｖｎが符号化レートを下げるために使用される。このようにして、時間と共に変動するチャネルのスループットが原因である様々なチャネルの状態の下で割り当てられたフレームバジェットを満たすことができる。ＭＢレベルのレート制御は、レート制御の精度を改善するための別の機能として働く。そのような機能を用いて、全体的なエンドツーエンドの表示品質が与えられたビットレートに関して改善されることができ、例えば、ＶＴアプリケーションにおいて、またはその他のアプリケーションにおいてより有効なオーディオ・ビデオ通信をサポートする。
【００７３】
図５は、ビデオソースレート制御のための技術を示す流れ図である。図５の例において、ビデオ符号化エンジン５０は、ビデオフレームｎ−１を符号化し（７０）、物理ビデオバッファ５２に符号化されたビデオフレームを追加する（７２）。レート制御ユニット５６は、例えば式（１）に従って次のフレームｎに関して仮想バッファ７４を更新し、新しい仮想バッファのフルネスの値Ｗｎを生成する（７４）。仮想ビデオバッファの更新において、Ｂｎ−１は、物理ビデオバッファ５２に追加されたフレームｎ−１を符号化するためにビデオ符号化エンジン５０によって使用されたビットの量である。バッファ情報ユニット５８は、物理ビデオバッファのフルネスの値Ｖｎを決定し（７６）、仮想ビデオバッファのフルネスの値Ｗｎを決定する（７８）。レート制御ユニット５６は、物理ビデオバッファのフルネスの値Ｖｎおよび仮想ビデオバッファのフルネスの値Ｗｎに基づいてビデオ符号化エンジン５０のビデオ符号化レートを制御する（８０）。次に、プロセスは、符号化されるべき次のフレームに進み（８２）、繰り返す。
【００７４】
図６は、ビデオソースレート制御のための技術をより詳細に示す流れ図である。図６の例において、ビデオ符号化エンジン５０は、ビデオフレームｎ−１を符号化し（８４）、物理ビデオバッファ５２に符号化されたビデオフレームを追加する（８６）。レート制御ユニット５６は、例えば式（１）に従って次のフレームｎに関して仮想バッファ７４を更新し、新しい仮想バッファのフルネスの値Ｗｎを生成する（８８）。バッファ情報ユニット５８は、物理ビデオバッファのフルネスの値Ｖｎを決定し（９０）、仮想ビデオバッファのフルネスの値Ｗｎを決定する（９２）。レート制御ユニット５６は、バッファ情報ユニット５８からバッファ値Ｘｎを受信する。バッファ値Ｘｎ＝ｍａｘ（ｗ*Ｖｎ，Ｗｎ）であり、ｗは重みづけ係数である。これは上記の式（２）に対応する。ｍａｘ（ｗ*Ｖｎ，Ｗｎ）がスキップ閾値Ｔｓｋｉｐ以上である場合（９４）、レート制御ユニット５６は、ビデオ符号化エンジン５０に次のフレームｎの符号化をスキップするように命じる（９６）。次のフレームｎをスキップすると、プロセスはスキップされたフレームの後の次のフレームに進み（１０１）、繰り返す。
【００７５】
ｍａｘ（ｗ*Ｖｎ，Ｗｎ）がスキップ閾値Ｔｓｋｉｐに等しくないか、あるいはそれより大きくない場合（９４）、レート制御ユニット５６は、目標符号化レート、例えば目標ビットレートＲおよび目標フレームレートＦ、物理ビデオバッファのフルネスの値Ｖｎ、仮想ビデオバッファのフルネスの値Ｗｎ、ならびにスキップ閾値Ｔｓｋｉｐに基づいて次のフレームに対するフレームバジェットを推定する（９８）。具体的には、レート制御ユニット５６は、次のフレームを符号化するために利用可能なビットの数を規定するフレームバジェットＢｎを決定するために上記の式（３）を適用することができる。フレームバジェットを決定すると、レート制御ユニット５６は、符号化されるべきフレーム内のビデオブロック、例えばマクロブロック（ＭＢ）に等しくフレームバジェットのビットを割り当てるようにビデオ符号化エンジン５０に指示する(direct)ことができる。その代り、フレームバジェットのビットは、ロー領域のＭＢビット割り当てを使用して割り当てられることができる（９９）。そのとき、各ＭＢへのロー領域ＭＢビット割り当ては、対応するＱＰ値にマップされることができる（１００）。現在のフレームに関して符号化レートが決定されると、プロセスは次のフレームに進み（１０１）、繰り返す。
【００７６】
本開示に記載の技術は、汎用マイクロプロセッサ、ディジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、またはその他の同等の論理デバイス内に実装されることができる。例えば、ビデオ符号器システム１２ならびにそのビデオ符号器システム１２のコンポーネントおよびモジュールは、ディジタル信号プロセッサ（ＤＳＰ）、マイクロプロセッサ、埋込み型コア、またはその他の処理デバイス上で実行される符号化プロセス、または符号化／復号（ＣＯＤＥＣ）プロセスの部分として実装されることができる。したがって、モジュールとして説明されるコンポーネントは、符号化プロセスのプログラム可能な機能あるいはハードウェアコンポーネント、または別個のプロセスを形成する可能性がある。
【００７７】
一部の実施形態において、符号化機能は、異なるハードウェアコンポーネントの間で分割されることができる。例えば、フレームレベルのレート制御は埋込み型論理コアで実行されることができ、ＭＢレベルのレート制御はＤＳＰで実行されることができる。例として、目標ビットレート（Ｒ  Ｋｂｐｓ）およびフレームレート（Ｆ  ｆｐｓ）が与えられたとして、埋込み型論理コア内のフレームレベルのレート制御は、各フレームを符号化した後にレート制御モデルパラメータ、例えばロー領域モデルパラメータを更新することと、次のフレームに関するフレームバジェットＢを推定することと、例えばローテーブルまたはローパラメトリック方程式（rho parametric equation）のいずれかを介してバジェットからローへのマッピングおよびローからＱＰへのマッピングを使用してフレームバジェットをフレームＱＰ（例えば、１から３１）にマップすることとを伴う可能性がある。
【００７８】
フレームＱＰに関する任意の追加的な制約を含む、ＱＰ値の後処理時に、埋込み型論理コアは、フレームＱＰ、ローバジェット（rho budget）、および新しいモデルパラメータをＤＳＰに送る。次に、ＤＳＰは、ローからＱＰへのマッピングを使用して各ＭＢに関するＱＰを計算し、ＱＰ値の後処理を実行する。ＤＳＰは、ＭＢデルタＱＰ値（MB delta QP value）が＋２および−２以内であるという規則と、ＭＢのＱＰｓに関する任意の追加的な制約とを守ることができる。ＭＢを符号化した後にロー領域モデルパラメータを更新すると、ＤＳＰは、適用可能なビデオフレーム内のその他のＭＢｓに関するプロセスを繰り返す。ＭＢの符号化が完了した後、プロセスは、埋込み型論理コアに戻って符号化されるべき次のビデオフレームを処理する。
【００７９】
ビデオ符号器システム１２は、命令およびデータを記憶するための専用メモリ、ならびに専用ハードウェア、ソフトウェア、ファームウェア、またはそれらの組合せを有することができる。ソフトウェアで実装される場合、本技術は、ランダムアクセスメモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）、電気的に消去可能なプログラマブル読出し専用メモリ（electrically erasable programmable read-only memory）（ＥＥＰＲＯＭ）、フラッシュメモリなどのコンピュータ可読媒体上の命令として具現化されることができる。命令は、１つまたはそれより多くのプロセッサに本開示に記載の機能(functionality)の特定の観点を実行させる。
【００８０】
ここで、例示的なビデオパケットシェーパ２４のさらなる詳細が説明される。以下の説明は、本開示に記載のビデオソースレート制御技術と共に役立つことができるビデオパケットシェーピング技術の例を提供する。しかし、本開示によるビデオソースレート制御のための技術は、種々のパケットシェーピング技術のうちの任意のものと共に実施されることができる。したがって、以下の詳細は例示の目的で提供され、本開示において概括的に具現化され、説明されるビデオソースレート制御技術の限定とみなされるべきでない。
【００８１】
この例において、ビデオパケットシェーパ２４は、オーディオの送信を優先するために、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６（図１および４）に提供される各ビデオパケットのサイズを制御する。具体的には、ビデオパケットは、各オーディオパケットが次の利用可能なＭＡＣレイヤパケットによって収容されることができるようにサイズ決めされる。ビデオパケットの制御されたサイズ決定は、チャネルの状態、大きなビデオパケット、またはそれらの両方によって引き起こされるオーディオの遅延を防止する。オーディオパケットが利用可能であるとき、そのオーディオパケットは、ＭＡＣレイヤモジュール３０によって生成される次の利用可能なＭＡＣ  ＲＬＰパケットに含めるためにＲＬＰキューに置かれる。オーディオパケットは、オーディオパケットをＭＡＣ  ＲＬＰパケット内に置くためのスペースを与えるようにサイズ決めされたビデオパケットと結合されることができる。
【００８２】
ビデオパケットシェーパ２４は、そのビデオパケットシェーパ２４がチャネルの状態に基づいてビデオパケットサイズを調整することができるという意味でチャネル適応できるように構成される。このように、符号器システム１２はオーディオパケットの送信を優先して、チャネルの状態が悪いときにオーディオの遅延を防止することができる。同時に、ビデオパケットシェーパ２４は、オーディオを優先することがビデオパケットが十分にパケット化されない結果にならないことを保証することができる。換言すれば、ビデオパケットシェーパ２４は、次の利用可能なＭＡＣ  ＲＬＰパケットに１つまたはそれより多くのオーディオパケットを含むことを可能にするのに十分なだけ小さく、しかしＭＡＣ  ＲＬＰパケット内の法外なスペースが無駄にされるほど小さくないようにビデオパケットをサイズ決めする。その結果、ビデオパケットシェーパ２４は、オーディオパケットの優先、およびビデオパケットの効率的な送信の両方をサポートすることができる。
【００８３】
上述されたように、ビデオパケットシェーパ２４は、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６に提出されるビデオパケットのサイズを制御するために提供される。ビデオパケットシェーパ２４は、ＭＡＣ  ＲＬＰパケットにおいてオーディオパケットの送信を優先するためにビデオパケットのサイズを制御し、ビデオパケットがＲＬＰキュー２８を圧倒することを防止する。このようにして、ＶＴ会議のオーディオ部分は、たとえビデオ部分がチャネルの状態が原因で遅延を被る可能性があるとしても実質的な遅延なしに搬送されることができる。ビデオはチャネルの状態によってそこなわれる可能性があるが、ビデオパケットシェーパ２４は、ＶＴ会議の参加者が言葉による会話を円滑に継続することがやはり可能であることを保証する。
【００８４】
ビデオパケットシェーパ２４によって適用されるパケットシェーピング技術は、オーディオパケットの優先された送信を保証するための１つまたはそれより多くの規則を適用することができる。例えば１つの規則によれば、オーディオパケットは、ＲＬＰキュー２８の内容から生成された直ぐ次の利用可能なＭＡＣ  ＲＬＰパケットで送信されるべきである。オーディオフレームは、第１の周期的間隔でオーディオ符号器２２によって生成される。ＭＡＣ  ＲＬＰパケットは、第２の周期的間隔でＭＡＣレイヤモジュール３０によって生成される。与えられた間隔で生成されたオーディオフレームは、ＭＡＣレイヤモジュール３０によって生成される次の利用可能なＭＡＣ  ＲＬＰパケットに置かれるべきである。一部の実施形態において、オプションとして、ＲＬＰキュー２８の総出力キューサイズがオーディオパケットサイズと一緒に１つのＭＡＣ  ＲＬＰパケットで搬送されることができるべきである。
【００８５】
ＶＴシーケンスのあらゆるパケットに関して種々の規則が適用されることができる。一部のビデオパケットはオーディオおよびビデオが単一のＭＡＣ  ＲＬＰパケットで搬送されることができることを保証するやり方で本質的にサイズ決めされることができるが、その他のビデオパケットはより大きくてもよく、特にチャネルの状態が悪化するときにオーディオおよびビデオが単一のＭＡＣ  ＲＬＰパケットで搬送されることができることを保証するためにサイズの削減を必要とする可能性がある。ＶＴシーケンスのあらゆるパケットに関してこれらの技術を適用することによって、たとえビデオの内容がエキスパンシブ(expansive)であるか、またはチャネルの帯域幅が実質的に制限されるとしても満足できる音声通信が保証されることができる。
【００８６】
ＲＬＰキュー２８に挿入するためにパケットシェーパ２４によってＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６に提出される各ビデオパケットのサイズが制御される。上記の規則は、大きなビデオ内容による連続的なＭＡＣ  ＲＬＰパケットの消費が原因でオーディオパケットが遅延されないことを保証する。そうではなく、オーディオが利用可能なとき、ビデオ符号器２０からのビデオは、各ＭＡＣ  ＲＬＰパケットがオーディオおよびビデオを搬送することを可能にするように選択されたサイズでパケットに分割される。各オーディオフレームは、ＲＬＰキュー２８に提供されるオーディオパケットとして使用されることができる。その代り、一部の実施形態において、オーディオパケットは、連続的な間隔で提供されるマルチプルオーディオフレームをまとめることができる。
【００８７】
一部の実施形態において、ビデオパケットシェーパ２４は、連続するオーディオフレームの間に生成されるＭＡＣレイヤパケットに関する推定されたチャネルのスループットに基づいて各ＭＡＣレイヤパケットに対するビデオパケットサイズを決定することができる。スループットは、現在の無線チャネルの送信レート、無線基地局アクティビティ(activity)、および送信電力の制限のうちの１つまたはそれより多くのものによって表されるチャネルの状態に基づいて推定されることができる。例えば、チャネルの状態は、現在のＭＡＣレイヤのデータレート、リバースアクティビティ（ＲＡ）ビット、および電力増幅器（ＰＡ）の制限に基づいて決定されることができる。さらに、一部の実施形態において、ビデオ符号器２０は、ビデオバッファの占有率に基づいた適応ソースレート制御をさらに含むことができる。この場合、オーディオのパケット化を優先する必要があると仮定すると、ソースビデオ符号化レートが、チャネルの状態が当該ビデオ符号化レートをサポートしない場合にビデオ符号器２０によって小さくされることができる。
【００８８】
オーディオ符号器２２はオーディオフレームを生成し、ビデオ符号器２０はビデオフレームを生成する。一連の連続的なＭＡＣ  ＲＬＰパケットが、ＲＬＰキュー２８にバッファされる、フレームから導出されるオーディオパケットおよびビデオパケットを搬送するために利用できる。オーディオ符号器２２による第１のオーディオフレームの生成に続いて、ＭＡＣレイヤモジュール３０によって生成される次の利用可能なＭＡＣ  ＲＬＰパケットが当該第１のオーディオフレームを搬送する。必要に応じて、第２のパケットも第１のオーディオフレームを搬送するために使用されることができる。しかし、ＲＬＰキュー２８の内容がビデオパケットにより圧倒されている場合、第１のオーディオフレームは長期間のあいだ送達されることができない。
【００８９】
各ＭＡＣ  ＲＬＰパケットは、ＲＬチャネルの状態情報から導出された関連するデータレートを有する。良好なＲＬの状態の下で、各ＭＡＣ  ＲＬＰパケットは７６．８キロビット毎秒（Ｋｂｐｓ）のデータレートを搬送する可能性がある。しかし、悪いＲＬチャネルの状態の下では、データレートは変動し、低いことが多く、例えば１９．２Ｋｂｐｓまたは３８．４Ｋｂｐｓである。過剰なビデオ内容、悪いチャネルの状態、またはそれら両方はオーディオパケットの送信の大きな遅延を引き起こす可能性がある。過大なビデオパケットサイズはＲＬを圧倒し、特にＲＬのスループットが低いデータレートが原因で小さくされるときにオーディオの遅延を増加させる可能性がある。
【００９０】
制御されない場合、ビデオパケットは過剰な量のＭＡＣ  ＲＬＰパケットのスペースを消費し、オーディオパケットの連続的な送信の間の遅延をもたらす可能性がある。場合によっては、ビデオは、いくつかの連続するＭＡＣ  ＲＬＰパケットを消費し、オーディオが速やかに送信されることを妨げる可能性がある。各ＭＡＣ  ＲＬＰパケットは、オーディオおよびビデオパケット情報を組み込むために約２６．６７ｍｓのスペースを提供する。大きなビデオフレームがオーディオフレームと実質的に同時に生成される場合を考える。このシナリオにおいて、連続するビデオフレームは時間的に互いに１３３ｍｓの間隔で生成されると仮定する。しかし、連続するオーディオフレームは時間的に互いにたった６０ｍｓの間隔で生成される。
【００９１】
良好なＲＬの状態の下でさえ、第１のオーディオフレームに関する、ならびに第２のおよび第３のオーディオフレームに関するオーディオパケットを組み込むための十分なスペースが存在しない可能性がある。それどころか、大きなビデオフレームに関連するビデオパケットがＭＡＣ  ＲＬＰパケットのほとんどを消費し、大きなオーディオの遅延をもたらす可能性がある。この問題は、ＲＬの状態が悪い場合のようにチャネルの状態が悪化するときに特に困難である。様々なチャネルの状態の下でオーディオの遅延を軽減するために、図１のシステム１０はビデオパケットシェーパ２４を組み込むことができ、それはビデオフレームから導出されるビデオパケットのサイズを制御する。ＶＴシーケンスのあらゆるパケットに関してビデオの制限を適用することによって、ビデオパケットシェーパ２４は、ＶＴシーケンスに関連するオーディオがそこなわれないことを保証することができる。
【００９２】
固定長ビデオパケットシェーピングは、オーディオの遅延の問題への部分的な解決策を提供する。しかし、固定長ビデオパケットシェーピングはチャネルの状態を考慮しない。その結果、ビデオは、ＲＬのスループットが小さくされるときにやはりチャネルを圧倒する可能性がある。さらに、固定長ビデオパケットシェーピングは、２つの連続するオーディオパケットの間のスループットを考慮せず、ビデオデータの過大なまたは過小なパケット化をもたらす。
【００９３】
固定長ビデオパケットシェーピングに関して、ビデオパケットのサイズは、ビデオフレームを６０ｍｓ毎に固定サイズのパケット（例えば、３００バイト）に分割することによって制御される。オーディオフレームも、例えば６０ｍｓ毎に固定サイズのパケットに分割される。ビデオパケットは、ＭＡＣ  ＲＬＰパケット内のオーディオデータパケットの直後に送信される。通常の運転状態の下で、固定長ビデオパケット化は、ＭＡＣ  ＲＬＰパケット内のオーディオパケットの適時の送信を促進する。
【００９４】
固定長ビデオパケットシェーピングアプローチは、オーディオパケットが良好なＲＬの状態の下で遅延なしに送信されることを保証する。しかし、ＲＬの状態が悪化する場合、固定長ビデオパケットがＲＬを圧倒し、連続するオーディオパケットの間の遅延をもたらす可能性がある。ビデオパケットの固定長が原因で、ＲＬの状態の変化に反応する能力がない。場合によっては、良好なＲＬの状態の下で、ビデオデータは十分にパケット化されず、各ＭＡＣ  ＲＬＰパケットによって提供されるスペースの過小利用と、全体的な帯域幅の非効率とをもたらす可能性がある。悪いＲＬの状態の下で、ビデオパケットの固定サイズはＲＬには大き過ぎて処理しきれず、オーディオの遅延をもたらす可能性がある。この理由で、ＶＴシーケンス全体に対して高品質のオーディオを維持するためにビデオ内容または帯域幅に応じて適応可能なサイズを有する、調整可能な長さのビデオパケットを生成するために、チャネル適応ビデオパケットシェーピングが提供されることができる。
【００９５】
チャネル適応ビデオパケットシェーピングに関して、ビデオパケットサイズは、オーディオパケットが実質的な遅延なしに送信されることができるようにチャネルの状態に基づいて調整される。固定ビデオパケットサイズの代わりに、各ビデオパケットのサイズは、オーディオパケットのサイズおよびチャネルの状態に基づいて動的に調整される。良好なＲＬの状態の下で、ビデオパケットサイズは大きくされることができるが、ビデオパケットがＲＬを圧倒し、オーディオの遅延をもたらすところまでは大きくされない。悪いＲＬの状態の下で、パケット化されて次に利用可能なＭＡＣ  ＲＬＰパケットに置かれるオーディオフレームのためのスペースを提供するためにビデオパケットはサイズを小さくされる。
【００９６】
オーディオフレームが利用可能であるとき、ビデオフレームは、それぞれのオーディオフレームが次に利用可能なＭＡＣ  ＲＬＰパケットに置かれることができるようにサイズ決めされる。各オーディオフレームはパケット化され、次に、ＭＡＣレイヤモジュール３０によって生成される次の利用可能なＭＡＣ  ＲＬＰパケットの中に含むためにＲＬＰキュー２８中に置かれ、オーディオパケットの送信の間の過剰な遅延を排除する。各ＭＡＣ  ＲＬＰパケットは、ＲＬＰキュー２８の内容に依存して、オーディオだけ、ビデオだけ、またはオーディオおよびビデオの両方を搬送することができる。しかし、各オーディオパケットの間隔で、ビデオパケットは、オーディオパケットを次の利用可能なＭＡＣ  ＲＬＰパケットに組み込むことを可能にするようにサイズ決めされる。
【００９７】
特に、利用可能なＲＬレートが例えばチャネルの状態が原因で小さくされるとき、オーディオパケットのサイズは、ＭＡＣ  ＲＬＰパケットのサイズに比較して大きくなる。換言すると、各オーディオパケットは、ビデオパケットのサイズが小さくされるので、ＲＬレートが減るときにＭＡＣ  ＲＬＰパケットのより大きな割合を消費する。逆に、各ビデオパケットのサイズは、ＲＬレートが減るときにそのビデオパケットがＭＡＣ  ＲＬＰパケットのより小さな割合を消費するように動的に調整される。このようにして、ビデオパケットは、オーディオパケットを次の利用可能なＭＡＣ  ＲＬＰパケット内に置くことを可能にするようにサイズ決めされる。結果は、オーディオの遅延を減らすためにオーディオがビデオよりも高い優先度を与えられることである。
【００９８】
ＲＴＣ  ＭＡＣユニット６４（図４）は、ＲＴＣ  ＭＡＣプロトコルを実行して、ＲＬを介して送信するために通信デバイスによって遵守される手順を提供するように構成されることができる。特定の実施形態において、ビデオパケットシェーパ２４は、１つまたは複数の入力に基づいて各ビデオパケットのサイズを制御するペイロードサイズエスティメータ(estimator)を含むことができる。入力は、チャネルの状態と、ＲＬＰキューの特性と、オーディオパケットのサイズおよび状態とに関連する可能性がある。特定の実施形態において、ビデオパケットシェーパ２４は、最小ビデオパケットサイズに従った、ペイロードサイズエスティメータによって特定された推定されたペイロードサイズに基づいたビデオパケットを生成する帯域幅効率の良いパケタイザも含むことができる。
【００９９】
ビデオバッファ５２は、ビデオ符号器２０から受信されたビデオ情報をバッファし、ビデオパケットシェーパ２４にビデオ情報を渡す。オーディオバッファ６２は、オーディオ符号器２２から受信されたオーディオフレーム情報をバッファし、その情報をＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６に渡す。オーディオおよびビデオパケットは互いに独立にＲＬＰキュー２８に挿入される。ビデオパケットシェーパ２４によって生成されるビデオパケットのサイズは、ＭＡＣレイヤモジュール３０によって生成される次の利用可能なＭＡＣ  ＲＬＰパケットにオーディオパケットのための十分なスペースが存在することを保証する。具体的には、ＲＬＰキュー２８はビデオパケットで圧倒されず、ＲＬＰキュー内のオーディオパケットが次のＭＡＣ  ＲＬＰパケットによって送信されることができることを保証する。
【０１００】
この例において、ビデオパケットシェーパ２４のペイロードサイズエスティメータは、チャネル情報、ＲＬＰキューサイズ、オーディオの優先順位値ＡＣＰｒｅｄＮｕｍｂｅｒＰｌｕｓ、オーディオパケットタイマを含むいくつかの入力を受信する。オーディオパケットタイマは、オーディオ情報がオーディオバッファ６２において現在利用可能であるかどうか、および利用可能である場合には各オーディフレームが送達されるタイミングを示す。例えばオーディオフレームが２０ｍｓ毎の間隔で送達される場合、オーディオパケットタイマは、オーディオフレームが利用可能であるときは２０ｍｓに設定される。一部の実施形態において、オーディオバッファ６２は、単一のパケットに組み込むために連続的なオーディオフレームをまとめるように構成されることができる。この場合、オーディオパケットタイマは、オーディオパケットにまとめられるフレーム数に対応する倍数(multiple)であることができる。換言すれば、オーディオパケットタイマは、まとめられるフレーム数に比例するかまたは、そうでなければ関連する値を有することができる。例えば３つのオーディオフレームがまとめられる場合、オーディオタイマは６０ｍｓに設定されることができる。したがって、オーディオパケットタイマは、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰモジュール２６を介してＲＬＰキュー２８に挿入するためにオーディオバッファ６２によって生成されるオーディオパケットのサイズも示す。
【０１０１】
オーディオの優先順位値ＭＡＣＰｒｅｄＮｕｍｂｅｒＰｌｕｓは、オーディオおよびビデオの相対的優先度を規定し、したがって、オーディオおよびビデオに関連する遅延に影響を与える。例えば、ＭＡＣＰｒｅｄＮｕｍｂｅｒＰｌｕｓは、優先順位値が小さいほどオーディオの遅延が少ないように定められることができる。したがって、ＭＡＣＰｒｅｄＮｕｍｂｅｒＰｌｕｓが増加するにつれて、オーディオの遅延が増加し、ビデオの遅延が減少する。反対に、ＭＡＣＰｒｅｄＮｕｍｂｅｒＰｌｕｓが減少するにつれて、オーディオの遅延が減少し、ビデオの遅延が増加する。したがって、オーディオの遅延は、オーディオの優先順位値ＭＡＣＰｒｅｄＮｕｍｂｅｒＰｌｕｓを追跡する。以下でより詳細に説明されるように、パケットシェーパ２４のペイロードサイズエスティメータは、ＭＡＣＰｒｅｄＮｕｍｂｅｒＰｌｕｓ値を使用して各ビデオパケットのサイズを制御し、規定されたオーディオパケット遅延をもたらす。
【０１０２】
ペイロードサイズエスティメータによって受信されるＲＬＰキューサイズは、ＲＬＰキュー２８にバッファされている現在のデータのサイズを示す。ペイロードサイズエスティメータは、ＲＬＰキューサイズを使用してビデオパケットのサイズを制御する。ＲＬＰキュー２８が比較的満杯である場合、ペイロードサイズエスティメータは、ＲＬを圧倒することおよび過度のオーディオの遅延を発生させることを防止するためにビデオパケットのサイズを小さくなるように調整することができる。ＲＬＰキュー２８がより空いている(less full)場合、ペイロードサイズエスティメータは、オーディオパケットのための十分なスペースをなおも提供しながらビデオパケットのサイズを増加させることができる。ＲＬＰキューサイズを用いて、ペイロードサイズエスティメータは、ビデオパケットサイズを、ＲＬＰキュー２８のフルネスの関数として動的に調整することができる。キューのフルネスは、過剰なビデオ内容、チャネルの状態の悪化、またはそれらの両方を示す可能性がある。ＲＬＰキューサイズの使用は、ペイロードサイズエスティメータがビデオ内容の過負荷またはチャネルの状態の変化に反応することができるやり方のうちの１つである。
【０１０３】
ビデオパケットシェーパ２４のペイロードサイズエスティメータは、ＲＴＣ  ＭＡＣユニット６４によって提供されるチャネル情報を監視することによってチャネルの状態の変化により直接的に反応することもできる。ＲＴＣ  ＭＡＣユニット６４は、ヘッドルームの制限、結合されたＲＡビット、現在のＭＡＣ  ＲＬレートなどのチャネル特性に関連する情報を生成する。ＭＡＣ  ＲＬレートは、ＲＬ上で利用可能な現在の送信レートを示す。ＲＡビットはリバースアクティビティビットであり、それは、関連する無線基地局が混雑しているかどうかを示す。ヘッドルームの制限は、現在の送信電力に基づいて送信において使用されることが許される最大レートを示すことができる。ＲＡビットは、基地局の不活動が原因でＲＬが混雑しているかまたは利用できないときを示す。ＰＡの制限は、送信電力のヘッドルームを示し、チャネルの状態が悪化したときを示す。
【０１０４】
様々な入力に基づいて、ビデオパケットシェーパ２４のペイロードサイズエスティメータは、ペイロードサイズの推定値を生成する。ペイロードサイズの推定値は、オーディオが高い優先度を与えられるべきであることを、ＭＡＣＰｒｅｄＮｕｍＰｌｕｓ優先度値が指定する場合、オーディオパケットが次の利用可能なＭＡＣ  ＲＬＰパケットに含まれることを可能にするように選択される。ビデオパケットシェーパ２４の帯域幅効率の良いパケタイザは、ビデオバッファ５２からビデオを受信し、最小ビデオパケットサイズおよび該ペイロードサイズエスティメータにより指定されたペイロードサイズの推定に基づいてビデオをパケット化する。最小ビデオパケットサイズは、ビデオパケットシェーパ２４によって生成されるべきビデオパケットの最小サイズを示す。実際は、最小ビデオパケットサイズは、ビデオパケットサイズの粒度および帯域幅の効率を制御する。より小さな最小ビデオパケットサイズの値に対して、ビデオパケットシェーピングは、オーディオに適応し、それによってオーディオの遅延を防止するという点においてより有効であるが、帯域幅の効率はより低い。より大きな最小ビデオパケットサイズの値に関して、ビデオパケットシェーピングは、オーディオの遅延を防止することにおいてより有効性が低いが、より高い帯域幅の効率を提供する。
【０１０５】
さらなる実装の詳細が例示の目的で説明される。この場合もやはり、そのような詳細は例示的とみなされるべきであり、本開示において概括的に具現化され、説明される技術の限定とみなされるべきでない。ｃｄｍａ２０００  １ｘ  ＥＶ−ＤＯ  Ｒｅｌ．０の実装に関して、ＲＬのスループットはチャネルの状態に基づいて推定されることができる。３ＧＰＰ２  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｃ．Ｓ００２４−Ａ（ＴＩＡ  ＩＳ−８５６−Ａとも呼ばれる）、１１−１４３ページ、表１１．９．６．１は、Ｋｂｐｓを単位とする送信レートによって(in terms of)表された様々なチャネルの状態を与えられたＭＡＣ  ＲＬＰパケットに関してバイトを単位とする最小および最大ペイロードサイズを規定する。表１１．９．６．１が以下に再現される。
【表１】
2009514448.tif 000006
【０１０６】
上記の表における各送信レベルがインデックス値として表される場合、オーディオおよびビデオの両方を含む各ＭＡＣ  ＲＬＰパケットの最大ペイロードサイズは以下のようになる。
【数１２】
2009514448.tif 000007
【０１０７】
上記の式に関して、インデックス値１、２、３、４、および５が、送信レートのレベル９．６、１９．２、３８．４、７６．８、および１５３．６Ｋｂｐｓに対してそれぞれ割り当てられる。
【０１０８】
オーディオフレームおよびビデオフレームはパケット化され、ＭＡＣ  ＲＬＰパケットに含まれる。ＭＡＣ  ＲＬＰパケットは、それぞれ関連するＲＬ送信レートを有し、それらの送信レートに対応する異なる最大ペイロードサイズを搬送することができる。例えば、一部のＭＡＣ  ＲＬＰパケットは、３８．４ＫｂｐｓのＲＬ送信レートを有することができ、それぞれ１２５バイトの最大ペイロードサイズを搬送することができる。その他のＭＡＣ  ＲＬＰパケットは、７６．８ＫｂｐｓのＲＬ送信レートを有することができ、２５３バイトの最大ペイロードサイズを搬送することができる可能性がある。さらにその他のＭＡＣ  ＲＬＰパケットは、１９．２ＫｂｐｓのＲＬ送信レートを有することができ、それぞれ６１バイトの最大ペイロードサイズを搬送することができる。
【０１０９】
例示的実施形態において、ビデオパケットシェーパ２４のペイロードサイズエスティメータの動作は、擬似コード(pseudo code)のアルゴリズムとして表されることができる。該アルゴリズムは、以下の入力に依存する：ＲＡビット、ＰＡの制限、ＲＬレート、ＲＬＰＱｕｅｕｅＳｉｚｅ、ＡｕｄｉｏＰａｃｋｅｔＳｉｚｅ、およびＭＡＣＰｒｅｄＮｕｍｂｅｒＰｌｕｓに依存する。ＡｕｄｉｏＰａｃｋｅｔＳｉｚｅは、ビデオパケットシェーパ２４に適用されたオーディオパケットタイマから導出されることができる。上述のように、結合されたＲＡビットは基地局アクティビティの状態を示すリバースアクティビティビットであり、ＰＡの制限は電力要求によって課せられる送信電力ヘッドルーム制限を示し、チャネルの状態が悪化したときを示し、ＲＬレートはＲＬの送信レートであり、ＲＬＰＱｕｅｕｅＳｉｚｅはＲＬＰキュー２８のフルネスを示し、ＡｕｄｉｏＰａｃｋｅｔＳｉｚｅは現在のオーディオパケット、すなわち次の利用可能なＭＡＣ  ＲＬＰパケットに追加されるべきオーディオパケットのサイズを示す。ＭＡＣＰｒｅｄＮｕｍｂｅｒＰｌｕｓは、ビデオパケットに対するオーディオパケットに与えられるべき相対的な優先度を示す。アルゴリズムの出力はＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅである。
【０１１０】
アルゴリズムの初期化のために、値ＭＡＣＰｒｅｄＮｕｍｂｅｒは以下のように設定される：
【数１３】
2009514448.tif 000008
【０１１１】
ＭａｃＰｒｅｄＮｕｍｂｅｒは、単一のオーディオフレームまたはまとめられたオーディオフレームの集合を含むパケットを搬送するために必要なＭＡＣ  ＲＬＰパケットの数を表す。ＡｕｄｉｏＦｒａｍｅＩｎｔｅｒｖａｌはオーディオフレーム間の時間間隔を表す。値２６．６７は、各ＭＡＣ  ＲＬＰパケットに対して割り当てられる時間である。したがって、３つのオーディオフレームがまとめられ、オーディオフレームの間隔が２０ｍｓであり、ＭＡＣＰｒｅｄＮｕｍｂｅｒＰｌｕｓが０であり、高いオーディオの優先度を示す場合、ＭＡＣＰｒｅｄＮｕｍｂｅｒは３である。これは、ビデオペイロードサイズが推定されるＭＡＣ  ＲＬＰパケットの予測される数が３であることを意味する。
【０１１２】
あらゆるまとめられたオーディオパケットに関して、まとめられたオーディオパケットを送信した後、ビデオパケットシェーパ２４のペイロードサイズエスティメータはＭＡＣオーディオスループット決定を行う。ＭＡＣスループット決定は以下の擬似コードによって示されるように進行することができる：
【数１４】
2009514448.tif 000009
【０１１３】
上記のＭＡＣスループット決定において、ＭＡＣＴｈｒｏｕｇｈｐｕｔはオーディオ送信に必要とされるスループット値であり、ＭＡＣＲａｔｅＩｎｃｒｅａｓｅは、リバースアクティビティに基づいてＭＡＣ  ＲＬレートが増やされるどうかを示し、ＣｕｒＲａｔｅは現在のＭＡＣ  ＲＬレートであり、ＭＡＣＰｒｅｄＲａｔｅはインデックス値として表される、ＭＡＣ  ＲＬレートの増加の量である。上で示されたように、ＭＡＣＴｈｒｏｕｇｈｐｕｔは、３つの予測されたＭＡＣ  ＲＬＰパケットのそれぞれに関して利用可能な最大ペイロードサイズである。
【０１１４】
各ＭＡＣ  ＲＬＰパケットについて最大ペイロードサイズＭＡＣＴｈｒｏｕｇｈｐｕｔが与えられたとすると、ビデオペイロードサイズエスティメータは以下のように最大ビデオペイロードサイズ（ＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅ）を推定する：
【数１５】
2009514448.tif 000010
【０１１５】
ここで、ＲＬＰＱｕｅｕｅＳｉｚｅはＲＬＰキュー２８のフルネスを示し、ＡｕｄｉｏＰａｃｋｅｔＳｉｚｅは次のＭＡＣ  ＲＬＰパケットに追加されるオーディオパケットのサイズを表す。値４５は、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６によって導入されるヘッダ情報のＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰオーバヘッドを説明する(account for)バイトを単位とする固定の数である。この固定のオーバヘッドの数の値は、その他の実装では異なる可能性がある。
【０１１６】
ある範囲のチャネルの状態に渡るチャネル適応ビデオパケットシェーピングに関して、ビデオパケットシェーパ２４のペイロードサイズエスティメータは、ＲＬＰキュー２８の内容からＭＡＣレイヤモジュール３０によって生成されるＭＡＣ  ＲＬＰパケットに組み込むために提供されるビデオパケットペイロードのサイズを調整するために、ＲＬ送信レートによって部分的に示される、変化中のチャネルの状態に適合する。一例において、オーディオフレームは６０ｍｓの間隔で生成される。この場合、６０ｍｓ毎に、次の３つのＭＡＣ  ＲＬＰパケット内の利用可能なペイロードサイズに関する判断がなされる。
【０１１７】
第１の決定点(decision point)において、現在のＭＡＣ  ＲＬレートが３８．４Ｋｂｐｓを表すために３とインデックス付けされ、ＲＡビットは０に設定され、ＰＡの制限は４に等しく、ＲＬＰキューはＸ１バイトを含む。この場合、上記の式に従って、次の３つのＭＡＣ  ＲＬＰパケットのそれぞれに関するスループットは２５３バイトであると推定される。したがって、次の３つのＭＡＣ  ＲＬＰパケットに渡る全体的なスループットは、２５３＋２５３＋２５３バイトから既にＲＬＰキュー２８に置かれている内容Ｘ１を引いたものである。したがって第１の決定点５０におけるＭＡＣＴｈｒｏｕｇｈｐｕｔの値は２５３＋２５３＋２５３−Ｘ１バイトである。
【０１１８】
６０ｍｓ後の第２の決定点において、現在のＲＬレートはやはり３でインデックス付けされ(indexed)、ＰＡ制限は４であるが、ＲＡビットは０ではなく１に設定される。この場合、ＲＡビットは基地局が混雑していることを示し、次の３つのＭＡＣ  ＲＬＰパケットにわたって減じられたスループットの予測をもたらす。具体的には、予測されるスループットＭＡＣＴｈｒｏｕｇｈｐｕｔは１２５＋１２５＋１２５−Ｘ２バイトであり、ここでＸ２は第２の決定点８０の時点のＲＬＰキュー２８の内容を表す。
【０１１９】
第２の決定点から６０ｍｓ後の第３の決定点において、ＲＡビットは０であるが、ＲＬレートは２のインデックス値（１９．２Ｋｂｐｓ）に落ちており(has dropped)、ＰＡ制限は２のインデックス値に落ちている。その結果、次の３つのＭＡＣ  ＲＬＰパケットにわたる全体的スループットＭＡＣＴｈｒｏｕｇｈｐｕｔは６１＋６１＋６１−Ｘ３バイトに下がり、ここでＸ３は第３の決定点８２の時点のＲＬＰキュー２８の内容を表す。
【０１２０】
ＭＡＣＴｈｒｏｕｇｈｐｕｔが減らされると、ビデオパケットのために利用可能なスペースも、オーディオパケットの優先の結果として減らされる。この場合、ビデオパケットシェーパ２４のペイロードサイズエスティメータが、パケット化のためのビデオペイロードの推定されたサイズを小さくする。しかし、ＭＡＣＴｈｒｏｕｇｈｐｕｔが増加すると、ペイロードサイズエスティメータは、推定されたビデオペイロードサイズを大きくすることによって応じる。このように、ビデオパケットシェーパ２４はオーディオパケットを優先するだけでなく、帯域幅効率の良いビデオパケット化もサポートする。
【０１２１】
この例においては、一度に３つのＭＡＣ  ＲＬＰパケットに関する判断がなされる。しかし、その他の実施形態においては、より積極的な判断プロセスが適用されることができる。例えば、ＭＡＣＴｈｒｏｕｇｈｐｕｔの推定に関する判断が２０ｍｓ毎になされることができる。第１の２０ｍｓの間隔において、３つのＭＡＣ  ＲＬＰパケットに関する判断がなされることができる。次に、第２の２０ｍｓの間隔において、３つの連続するＭＡＣ  ＲＬＰパケットの集合のうちの残りの２つのＭＡＣ  ＲＬＰパケットに関する判断がなされることができる。最後に、次の２０ｍｓの間隔の間に３つのパケットの集合内の最後のＭＡＣ  ＲＬＰパケットに関する判断がなされることができる。この場合、判断は６０ｍｓ間隔の過程に渡ってなされ、チャネルの状態またはＲＬＰキューのフルネスに発生した可能性のある任意の変化に関して２０ｍｓ毎に更新される。６０ｍｓ後、プロセスは次の６０ｍｓの間に次の３つのＭＡＣ  ＲＬＰパケットに関して繰り返し、反復して継続する。
【０１２２】
いったんＭＡＣＴｈｒｏｕｇｈｐｕｔが推定されると、ビデオペイロードサイズエスティメータは、上で説明されたようにＭＡＣＴｈｒｏｕｇｈｐｕｔの値が与えられた場合に収容されることができるビデオペイロードサイズを推定する。そのとき、帯域幅効率の良いパケタイザは、推定ビデオペイロードサイズおよび最小ビデオパケットサイズを使用して、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６に提出するためのビデオパケットを生成する。ここで、ビデオパケットシェーパ２４の帯域幅効率の良い(bandwidth efficient)パケタイザの動作がより詳細に説明される。
【０１２３】
概して、ビデオパケット化は、ＭＰＥＧ４ビデオ符号化が使用される場合、２０００年１１月付けのＮｅｔｗｏｒｋ  Ｗｏｒｋｉｎｇ  Ｇｒｏｕｐ  Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔ（ＲＦＣ）３０１６に従うべきであり、またはＩＴＵ  Ｈ．２６３ビデオ符号化が使用される場合、１９９７年９月付けのＲＦＣ２１９０、もしくは１９９８年１０月付けのＲＦＣ２４２９に従うべきである。ＲＦＣ３０１６は、ＭＰＥＧ４ストリームに関するＲＴＰペイロードフォーマットを概説する。ＲＦＣ２４２９は１９９８年版のＩＴＵ  Ｈ．２６３ストリームに関するＲＴＰペイロードフォーマットを概説し、ＲＦＣ２１９０は初版のＩＴＵ  Ｈ．２６３ストリームに関するＲＴＰフォーマットを概説する。
【０１２４】
ＲＦＣ３０１６は、ビデオパケットが（ａ）ビデオオブジェクトプレーン（video object plane）（ＶＯＰ）ヘッダまたはビデオパケット（ＶＰ）ヘッダから始まる必要があり、それらのヘッダのいずれかが存在する場合に（ｂ）２つ以上のＶＰヘッダを含むことができ、以上の規則が満足される場合に（ｃ）いかなるＶＯＰヘッダおよびＶＰヘッダも中に含まないビデオデータだけを含むことができ、（ｄ）２つのビデオフレームにまたがるデータを含むことはできないことを規定する。ＲＦＣ２１９０は、ビデオパケットが（ａ）ピクチャスタートコード（picture start code）（ＰＳＣ）またはグループオブブロック（group of blocks）（ＧＯＢ）で始まる必要があり、（ｂ）ＧＯＢヘッダまたは完全なＧＯＢを有する必要はなく、（ｃ）ＧＯＢがバイト整列されている(byte-aligned)必要はないことを規定する。ＲＦＣ２４２９は、ビデオパケットが（ａ）バイト整列されたＰＳＣ、ＧＯＢヘッダ、スライスヘッダ、およびエンドオブスライス（ＥＯＳ）マーカ（end of slice (EOS) marker）から始まることができ、（ｂ）いかなる同期符号でも始まらないがビデオパケットの中間の同期符号を許す後続（Follow-on）パケットであることができることを規定する。
【０１２５】
上記の要求が与えられたとすると、ビデオ符号器２０は、ＭＰＥＧ４に関してＶＯＰｓおよびＶＰｓの形態で、またはＨ．２６３に関してＰＳＣｓ、ＧＯＢｓ、およびＳＳＣｓの形態でビデオデータをビデオバッファ５２に挿入するように構成されることができる。ＭＰＥＧ４に従う符号器はＶＯＰまたはＶＰｓの単位でデータを生成する。Ｈ．２６３符号器は、ＧＯＢｓがバイト整列されるようにしてＰＳＣｓ、ＧＯＢｓ、またはＳＳＣｓの単位でデータを生成する。ＲＦＣ２１９０が使用されるとき、モードＡがデフォルトである。
【０１２６】
例示的実施形態において、ビデオパケットシェーパ２４の帯域幅効率の良いパケタイザの動作は、以下の入力を使用するアルゴリズムとして表されることができる：ＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒ、ＥｓｔｉｍａｔｅｄＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅ、ｍｉｎＶＰＳｉｚｅ。ＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒはビデオバッファ５２内のビデオのサイズを表す。ＥｓｔｉｍａｔｅｄＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅは、ビデオパケットシェーパ２４のペイロードサイズエスティメータによって決定された推定されたビデオパケットサイズを表す。値ｍｉｎＶＰｓｉｚｅは、ビデオパケットシェーパ２４によって生成されるべき最小ビデオパケットサイズであり、粒度および帯域幅効率を制御する働きをする。帯域幅効率の良いパケット化アルゴリズムの出力は、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６に提出するための１つまたは複数のビデオパケットである。例示的実施形態において、帯域幅効率の良いパケタイザの動作は以下の擬似コードによって表される：
【数１６】
2009514448.tif 000011
【数１７】
2009514448.tif 000012
【０１２７】
上記の擬似コードによって表されるように、ビデオパケットシェーパ２４の帯域幅効率の良いパケタイザは、ペイロードサイズエスティメータによって提供されたＥｓｔｉｍａｔｅｄＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅと、ｍｉｎＶＰＳｉｚｅとに基づいてビデオパケットを生成する。ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅは、ビデオパケットの生成中の任意の時点でまだ利用可能なペイロードの量を表す。最初に、ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅは、ビデオペイロードサイズエスティメータによって与えられたＥｓｔｉｍａｔｅｄＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅ全体に等しい。ＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅは、パケット内のビデオペイロードの実際のサイズを表し、最初に０に設定される。ＶｉｄｅｏＰａｙｌｏａｄＤａｔａ［］は、ビデオバッファ５２内のビデオデータセグメントのアレイを識別する。
【０１２８】
最初に、帯域幅効率の良いパケタイザは、ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅがｍｉｎＶＰＳｉｚｅ／２未満であるかどうかを決定する。ｍｉｎＶＰＳｉｚｅ／２未満である場合、ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅは０に設定される。その代りに、ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅがｍｉｎＶＰＳｉｚｅ未満である場合、ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅの値はｍｉｎＶＰＳｉｚｅに等しく設定される。次に、ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅが０に等しいか、またはＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒがヌル(null)である場合、次の利用可能なＭＡＣ  ＲＬＰパケットにスペースが残っていないか、またはビデオバッファ５２内にビデオがないかのいずれかであるのでプロセスはリセットされる。
【０１２９】
ＶｉｄｅｏＩｎＢｕｆｆｅｒが値ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅにｍｉｎＶＰＳｉｚｅを加えた値以上である場合、次に、帯域幅効率の良いパケタイザはＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅがｍｉｎＶＰｓｉｚｅ／２以上であるかどうかを決定する。ｍｉｎＶＰｓｉｚｅ／２以上である場合、帯域幅効率の良いパケタイザは、ＲＦＣ３０１６またはＲＦＣ２４２９が適用可能かどうかを決定する。ＲＦＣ３０１６もＲＦＣ２４２９も適用されない場合、帯域幅効率の良いパケタイザは、ＲＦＣ２１９０が適用可能かどうか、すなわち初版のＩＴＵ  Ｈ．２６３用のＲＴＰペイロードフォーマットが適用されるかどうかを決定する。
【０１３０】
ＲＦＣ３０１６またはＲＦＣ２４２９が適用される場合、帯域幅効率の良いパケタイザは、ＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒによって特定される入力バッファに、開始アドレスＶｉｄｅｏＰａｙｌｏａｄＤａｔａおよびオフセットＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅによって決定されるビデオバッファ５２からのビデオをコピー（ｍｅｍｃｐｙ）する。初め、ＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅは０に設定される。ビデオバッファ５２からコピーされるビデオの量はＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅに等しく、それは最初にＥｓｔｉｍａｔｅｄＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅに設定される。次に、帯域幅効率の良いパケタイザは、ＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅをＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅに等しいように調整する。次に、帯域幅効率の良いパケタイザは、オフセットＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅによって識別されるアドレスに、ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅにより決定される量のビデオデータを、入力バッファからコピーする。そのとき、ＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒの内容がパケット化のために分割される。
【０１３１】
ＲＦＣ２１９０が適用される場合、帯域幅効率の良いパケタイザは、ＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒによって識別される入力バッファに、開始アドレスＶｉｄｅｏＰａｙｌｏａｄＤａｔａおよびオフセットＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅによって決定されるビデオバッファ５２からのビデオをコピー（ｍｅｍｃｐｙ）する。この場合もやはり、最初に、ＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅが０に設定される。ビデオバッファ５２からコピーされるビデオの量は、ＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒのサイズに等しい。次に、ＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅがＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒのサイズに等しくされる。
【０１３２】
ＲＦＣ３０１６／ＲＦＣ２４２９の操作またはＲＦＣ２１９０の操作のいずれかを出ると、次に、帯域幅効率の良いパケタイザは、ＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅの現在の値に等しいペイロードサイズを用いてＶｉｄｅｏＰａｙｌｏａｄＤａｔａからＶｉｄｅｏＰａｃｋｅｔを生成する。次に、値ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅが０に設定される。この時点で、ビデオパケットは、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６に提出するために帯域幅効率の良いパケタイザによって生成されている。ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅがｍｉｎＶＰＳｉｚｅ以上であり、ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅが０でなく、ＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒがヌルではなく、ＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒのサイズがＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅ＋ｍｉｎＶＰＳｉｚｅ未満である場合、帯域幅効率の良いパケタイザは、アドレスＶｉｄｅｏＰａｙｌｏａｄＤａｔａにＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅのオフセットを足したものを使用してデータをバッファ５２からＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒにコピーする。この場合、コピーされるデータの量はＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅに等しい。次に、帯域幅効率の良いパケタイザは、ＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅをＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒのサイズに等しいように設定する。
【０１３３】
次に、ビデオパケットシェーパ２４の帯域幅効率の良いパケタイザは、ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅを、ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅからＶｉｄｅｏＢｕｆｆｅｒＳｉｚｅを引いたものと０とのうちの最大に等しいように設定する。ＶｉｄｅｏＢｕｆｆｅｒＳｉｚｅはビデオバッファ５２のサイズを表す。ビデオバッファ５２内にさらなるデータがないか、または現在のタイムスタンプ（ＴＳ）が次のＴＳと異なるか、またはＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅが０であるか、またはＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒが断片化される(fragmented)場合、帯域幅効率の良いパケタイザは、ＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅのペイロードサイズを用いてＶｉｄｅｏＰａｙｌｏａｄＤａｔａから１つのＶｉｄｅｏＰａｃｋｅｔを生成し、ＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅを０に設定する。そうでない場合、帯域幅効率の良いパケタイザは、ビデオバッファ５２内のスライスユニット、あるいはＧＯＢ、次のフレームを、それらの任意のものがある場合、取得するようにＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒを設定し、またはビデオバッファ内にさらなるデータがない場合はＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒをヌルに設定する。
【０１３４】
チャネル適応ビデオパケットシェーピングの例として、オーディオバッファ６２がオーディオパケットを生成すると仮定する。ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰモジュール２６は、オーディオパケットをＲＬＰキュー２８に追加する。ビデオパケットシェーパ２４のペイロードサイズエスティメータは、ＲＬＰキューサイズ、オーディオビデオ優先度値、およびチャネルの状態を決定する。それらの決定に基づいて、ビデオパケットシェーパ２４のペイロードサイズエスティメータは、生成されるべき次のビデオパケットのペイロードサイズを推定する。帯域幅効率の良いパケタイザは、推定されたペイロードサイズおよび最小ビデオパケットサイズに基づいてビデオパケットを生成し、ビデオパケットをサイズ決めする。帯域幅効率の良いパケタイザは、ビデオパケットをＲＬＰキュー２８に追加する。ＭＡＣレイヤモジュール３０は、ＲＬＰキュー２８の内容からＭＡＣ  ＲＬＰパケットを生成する。
【０１３５】
本開示に記載の技術は、汎用マイクロプロセッサ、ディジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、またはその他の同等の論理デバイス内に実装されることができる。例えば、ビデオ符号器システム１２、ビデオ復号器システム１４、ならびにそれらのシステムのコンポーネントおよびモジュールは、ディジタル信号プロセッサ（ＤＳＰ）またはその他の処理デバイス上で実行される符号化プロセス、または符号化／復号（ＣＯＤＥＣ）プロセスの部分として実装されることができる。したがって、モジュールとして説明されるコンポーネントは、そのようなプロセスのプログラム可能な機能、または別個のプロセスを形成する可能性がある。
【０１３６】
ビデオ符号器システム１２は、命令およびデータを記憶するための専用メモリ、ならびに専用ハードウェア、ソフトウェア、ファームウェア、またはそれらの組合せを有することができる。ソフトウェアで実装される場合、本技術は、１つまたはそれより多くのプロセッサによって実行可能な命令として具現化されることができる。命令は、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）、電気的消去可能プログラマブル読み出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリ、磁気または光データ記憶装置などのコンピュータ可読媒体上に記憶されることができる。命令は、１つまたは複数のプロセッサに本開示に記載の機能の特定の態様を実行させる。
【０１３７】
種々の実施形態が説明された。これらのおよびその他の実施形態は上記の特許請求の範囲の範囲に含まれる。
【図面の簡単な説明】
【０１３８】
【図１】ＶＴ用途向けのオーディオ／ビデオ符号化および復号システムを示すブロック図。
【図２】ビデオソースレート制御を実装するビデオ符号化システムを示すブロック図。
【図３】デュアルバッファベースのフレームバジェット推定を使用する、ビデオソースレート制御を用いる図２のビデオ符号化システムの例示的実施形態を示すブロック図。
【図４】チャネル適応ビデオパケットシェーピングを実装するオーディオ／ビデオ符号化システム内の図２のビデオ符号化システムの統合を示すブロック図。
【図５】ビデオソースレート制御のための技術を示す流れ図。
【図６】ビデオソースレート制御のための技術をより詳細に示す流れ図。
【図１】
2009514448.tif 000021
【図２】
2009514448.tif 000022
【図３】
2009514448.tif 000023
【図４】
2009514448.tif 000024
【図５】
2009514448.tif 000025
【図６】
2009514448.tif 000026
【国際調査報告】
2009514448.tif 000027
2009514448.tif 000028
2009514448.tif 000029
2009514448.tif 000030
2009514448.tif 000031
2009514448.tif 000032
2009514448.tif 000033