JP5027222B2 - リバース・リンク状態に対するビデオ・レート適応化 - Google Patents

Description

本発明は、ビデオ・エンコーデイング（video encoding）に関し、更に詳細には、ビデオ・エンコーデイング・レート（video encoding rate）をリバース・リンク状態に適応させる技法に関する。

携帯電話は、マイクロフォン又はスピーチ・シンセサイザ、及びオーデイオ・パケット（又はフレーム）を生成するためのオーデイオ・エンコーダー（audio encoder）のようなオーデイオ・キャプチャ・デバイス（audio capture device）を含んでもよい。その電話は、無線リンク・プロトコル（ＲＬＰ）、媒体アクセス制御（ＭＡＣ）、及び物理（ＰＨＹ）層のような通信プロトコル層を用いてもよい。その電話は、ＲＬＰキュー（RLP queue）にオーデイオ・パケットを配置してもよい。ＭＡＣ層モジュールは、ＲＬＰキューのコンテンツからCＭＡＣ層パケットを生成してもよい。ＭＡＣ層パケットは、通信チャンネルによる他の通信装置への送信のためのＰＨＹ層パケットに変換されてもよい。

１つの態様は、アクセス端末におけるビデオ・フロー無線リンク・プロトコル（ＲＬＰ）キューのサイズに基づいてビデオ・スループットを推定すること、及びその推定されたビデオ・スループットを用いてビデオ・データをコード化することを備える方法に関する。

他の態様は、第１の時間ｔ_ｎにおける無線リンク・プロトコル（ＲＬＰ）層内のビデオ・キューの第１のサイズＶ_ｎをビデオ・フレーム・レートに基づいて判定すること、第２の時間ｔ_ｍにおけるビデオ・キューの第２のサイズＶ_ｍをオーデイオ・フレーム・レートに基づいて判定すること、第１のサイズＶ_ｎ又は第２のサイズＶ_ｍがゼロより大きい場合には、ビデオ・スループットを判定するために、第１のサイズＶ_ｎ、先行のビデオ・フレームに関連づけられるビデオ・キューの先行のサイズＶ_ｎ−１、先行のビデオ・フレーム・サイズＢ_ｎ−１、第１の時間ｔ_ｎ、ビデオ・キューの先行のサイズに関連づけられる時間ｔ_ｎ−１を用いること、第１のサイズＶ_ｎ及び第２のサイズＶ_ｍがゼロに等しい場合には、ビデオ・キュー・サイズがゼロより大きかった時のオーデイオ・フレーム・レートに基づいて、より早い時間ｔ _ｍ−１ をサーチすること、ビデオ・キュー・サイズがゼロより大きかった時のオーデイオ・フレーム・レートに基づいて、より早い時間ｔ _ｍ−１ を見出した後で、ビデオ・スループットＶＴＰを判定するために、オーデイオ・フレーム・レートに基づいたより早い時間ｔ _ｍ−１ におけるキュー・サイズＶ_ｍ−１、先行のビデオ・フレームに関連づけられるビデオ・キューの先行のサイズＶ_ｎ−１、先行のビデオ・フレーム・サイズＢ_ｎ−１、より早い時間ｔ_ｍ−１、及びビデオ・キューの先行のサイズに関連づけられる時間ｔ_ｎ−１を用いること、チャンネル制約ビデオ・フレーム・サイズを判定するために、判定されたビデオ・スループットを用いること、そして、ビデオ・エンコーデイング・レートを制御するためにチャンネル制約ビデオ・フレーム・サイズを用いることを備える方法に関する。

他の態様は、無線リンク・プロトコル（ＲＬＰ）層内のビデオ・キューのサイズを判定すること、媒体アクセス制御（ＭＡＣ）層からの電力ヘッドルーム限界を判定すること、ＭＡＣペイロード・サイズを判定するために、判定された電力ヘッドルーム限界を用いること、ビデオ・スループットを判定するために、判定されたＭＡＣペイロード・サイズ及び１つの期間においてどれくらいの送信機会がビデオに与えられるかについての推定を用いること、チャンネル制約ビオデオ・フレーム・サイズを判定するために、判定されたビデオ・スループット及びＲＬＰ層内のビデオ・キューの判定されたサイズを用いるいこと、そして、ビデオ・エンコーデイング・レートを制御するためにチャンネル制約ビデオ・フレーム・サイズを用いることを備える方法に関する。

他の態様は、１つの組の命令を記憶する機械読取り可能メモリを備える装置に関する。この命令は、ビデオ・フレーム・レートに基づき第１の時間ｔ_ｎにおける無線リンク・プロトコル（ＲＬＰ）層内のビデオ・キューの第１のサイズＶ_ｎを判定する、オーデイオ・フレーム・レートに基づいて第２の時間ｔｍの第２のサイズＶｍを判定する、第１のサイズＶ_ｎ又は第２のサイズＶ_ｍがゼロより大きい場合に、ビデオ・スループットＶＴＰを判定するために、第１のサイズＶｎ、先行のビデオ・フレームに関連づけられるビデオ・キューの先行のサイズＶｎ−１、先行のビデオ・フレーム・サイズＢｎ−１、第１の時間ｔｎ、及びビデオ・キューの先行のサイズに関連づけられる時間ｔｎ−１を用いる、第１のサイズＶ_ｎ及び第２のサイズＶ_ｍがゼロに等しい場合、ビデオ・キューがゼロより大きい時にオーデイオ・フレーム・レートに基づいて、より早い時間をサーチする、ビデオ・キュー・レートがゼロより大きかった時にオーデイオ・フレーム・レートに基づく、より早い時間を見出した後で、ビデオ・スループットＶＴＰを判定するために、オーデイオ・フレーム・レートに基づく、より早いキュー・サイズＶ_ｍ−１、先行のビデオ・フレームに関連づけられるビデオ・キューの先行のサイズＶ_ｎ−１、先行のビデオ・フレーム・サイズＢ_ｎ−１、より早い時間ｔ_ｍ−１、及びビデオ・キューの先行のサイズに関連づけられる時間_ｎ−１を用いる、チャンネル制約ビデオ・フレーム・サイズを判定するために、判定されたビデオ・スループットＶＴＰを用いる、そして、ビデオ・エンコーデイング・レートを制御するためにチャンネル制約ビデオ・フレーム・サイズを用いるように構成される。

他の態様は、１つの組の命令を記憶する機械読取り可能メモリを備える装置に関する。この命令は、無線リンク・プロトコル（ＲＬＰ）層内のビデオ・キューのサイズを判定する、媒体アクセス制御（ＭＡＣ）層から電力ヘッドルーム限界を判定する、ＭＡＣペイロード・サイズを判定するために、判定された電力ヘッドルーム限界を用いる、ビデオ・スループットを判定するために、判定されたＭＡＣペイロード・サイズ及び１つの期間においてどのくらいの送信機会がビデオに与えられるかについての推定を用いる、チャンネル制約ビデオ・フレーム・サイズを判定するために、判定されたビデオ・スループット及びＲＬＰ層内のビデオ・キューの判定されたサイズを用いる、ビデオ・エンコーデイング・レートを制御するためにチャンネル制約ビデオ・フレーム・サイズを用いるように構成される。

他の態様は、ビデオ・データを記憶するように構成された無線リンク・プロトコル（ＲＬＰ）層キューと、ＲＬＰビデオ・キューのサイズ及び媒体アクセス制御（ＭＡＣ）層からの電力ヘッドルーム限界を受信する、ＭＡＣペイロード・サイズを判定ために電力ヘッドルーム限界を用いる、ビデオ・スループットを判定するために、判定されたＭＡＣペイロード・サイズ及び１つの期間においてどのくらいの送信機会がビデオに与えられるかについての推定を用いる、そして、チャンネル制約ビデオ・フレーム・サイズを判定するために、判定されたビデオ・スループット及びＲＬＰ層内のビデオ・キューのサイズを用いるように構成された第１のユニットと、ビデオ・エンコーデイング・レートを制御するためにチャンネル制約ビデオ・サイズを用いるための第２のユニットと、及び、ビデオをコード化するためにビデオ・エンコーデイング・レートを用いるためのビデオ・エンコーダーとを備える装置に関する。

他の態様は、無線リンク・プロトコル（ＲＬＰ）層内のビデオ・キューのサイズを判定するための手段と、媒体アクセス制御（ＭＡＣ）層から電力ヘッドルーム限界を判定するための手段と、ＭＡＣペイロード・サイズを判定するために、判定された電力ヘッドルーム限界を用いるための手段と、ビデオ・スループットを判定するために、判定されたＭＡＣペイロード・サイズ及び１つの期間においてどのくらいの送信機会がビデオに与えられるかについての推定を用いるための手段と、チャンネル制約ビデオ・フレーム・サイズを判定するために、判定されたビデオ・スループット及びＲＬＰ層内のビデオ・キューの判定されたサイズを用いるための手段と、ビデオ・エンコーデイング・レートを制御するためにチャンネル制約ビデオ・フレーム・サイズを用いるための手段とを備える装置に関する。

１つの又はそれより多い実施の形態の詳細が、添付図面及び下記の説明で提示される。

詳細な説明

図１は、ビデオ・エンコーデイング及びデコーデイング・システム１０を例示する。システム１０は、送信チャンネル１６を通じて（across）デコーダー・システム１４にデータを送るエンコーダー・システム１２を含む。エンコーダー・システム１２は、第１のビデオ通信装置内にあってもよく、そして、オーデイオ・ソース１７、ビデオ・ソース１８、ビデオ・エンコーダー２０、オーデイオ・エンコーダー２２、リアルタイム・トランスポート・プロトコル（ＲＴＰ）／ユーザ・データグラム・プロトコル（ＵＤＰ）／インターネット・プロトコル（ＩＰ）／ポイント・ツー・ポイント・プロトコル（ＰＰＰ）変換モジュール、無線リンク・プロトコル（ＲＬＰ）キュー（radio link protocol (RLP) queue）２８、ＭＡＣ層モジュール３０及び物理（ＰＨＹ）層モジュール３２を含んでもよい。デンコーダー・システム１２の他の実施の形態は、図１に示された要素に代えて又はそれに付加して他の要素を含んでもよい。エンコーダー・システム１２の他の実施の形態は、図１に示された要素より少ない要素を含んでもよい。

デコーダー・システム１４は、他のビデオ通信装置内にあってもよく、そして、ＰＨＹ層モジュール３４、ＭＡＣ層モジュール３６、ＲＬＰキュー３８、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール４０、ビデオ・デコーダー４２、オーデイオ・デコーダー４４、オーデイオ出力ユニット４６及びビデオ出力ユニット４８を含んでもよい。デコーダー・システム１４の他の実施の形態は、図１に示された要素に代えて又はそれに付加して他の要素を含んでもよい。デコーダー・システム１４の他の実施の形態は、図１に示されたものより少ない要素を含んでもよい。

システム１０は、例えば、送信チャンネル１６によるビデオ・テレフォニー（ＶＴ）のための双方向のビデオ及びオーデイオ送信を提供しうる。チャンネル１６の両端には、レシプロカル・エンコーデイング、デコーデイング及び変換モジュール（reciprocal encoding, decoding, and conversion modules）が設けられてもよい。いくつかの実施の形態では、エンコーダー・システム１２及びデコーダー・システム１４は、ビデオ・ストリーミング、ＶＴ、又は両方のために備えられた無線移動端末のようなビデオ通信装置内に具現されてもよい。移動端末は、ＲＴＰ、ＵＤＰ、ＩＰ、又はＰＰＰのようなパケット切替標準（packet-switched standards）に従ってＶＴをサポートしうる。

ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６は、オーデイオ・エンコーダー２２及びビデオ・エンコーダー２０から受信されたオーデイオ及びビデオ・データに適当なＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰヘッダー・データを付加する。ＲＴＰはＵＤＰのトップでラン（runs）し、一方、ＵＤＰはＩＰのトップでランし、そしてＩＰはＰＰＰのトップでランする。ＭＡＣ層モジュール３０は、ＲＬＰキュー２８のコンテンツからＭＡＣ ＲＬＰパケットを生成する。ＰＨＹ層モジュール３２は、ＭＡＣ ＲＬＰパケットをチャンネル１６による送信のためのＰＨＹ層パケットに変換する。

デコーデイング・システム１４のＰＨＹ層モジュール３４及びＭＡＣ層モジュール３６は、往復の態様（reciprocal manner）で動作する。ＰＨＹ層モジュール３４は、チャンネル１６から受信されたＰＨＹ層パケットをＭＡＣ ＲＬＰパケットに変換する。ＭＡＣ層モジュール３６は、ＭＡＣ ＲＬＰパケットをＲＬＰキュー３８内に置く。ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール４０は、ＲＬＰキュー３８内のデータからヘッダー情報をストリップ（strips）し、そして、ビデオ・デコーダー４２及びオーデイオ・デコーダー４４にそれぞれデリバリ（delivery）するためのビデオ及びオーデイオ・データをリアセンブル（reassembles）する。

システム１０は、コード分割多重アクセス（ＣＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、又は直交周波数分割多重化（ＯＦＤＭ）、又は他の適当な無線技術のような１つ又はそれより多い無線通信技術をサポートするように設計されてもよい。上記の無線通信技術は、種々の無線アクセス技術（radio access technologies）のうちの任意のものに従ってデリバーされ（delivered）されてもよい。例えば、ＣＤＭＡは、ｃｄｍａ２０００又は広帯域ＣＤＭＡ（ＷＣＤＭＡ）標準に従ってデリバーされてもよい。ＴＤＭＡは、移動通信のためのグローバル・システム（Global System for Mobile Communications (GSM)）標準に従ってデリバーされてもよい。ユニバーサル移動通信システム（ＵＭＴＳ)標準は、ＧＳＭ又はＷＣＤＭＡ動作を許容する。ＶＴ適用に対しては、システム１０は、ｃｄｍａ２００ １ｘＥＶ−ＤＯ、リリース０、改訂Ａ又は後続のＥＶ−ＤＯリリースのようなハイ・データ・レート（ＨＤＲ）技術をサポートするように設計されてもよい。

ビデオ・ソース１８は、１つの又はそれより多いビデオ・カメラ、１つの又はそれより多いビデオ・アーカイブ、又はビデオ・カメラ及びビデオ・アーカイブの組み合わせのようなビデオ・キャプチャ・デバイスであってもよい。ビデオ・エンコーダー２０は、ＭＰＥＧ−４のようなビデオ圧縮法に従ってコード化ビデオ・データを生成する。インターナショナル・コミュニケーション・ユニオン（ＩＴＵ）Ｈ．２６３、又はＭＰＥＧ−２法のような他のビデオ圧縮法が用いられてもよい。ビデオ・エンコーダー２０は、一般にＣＯＤＥＣ依存であるビデオ・ソース・レート制御・スキームを提供してもよい。例えば、ビデオ・エンコーダー２０は、ＭＰＥＧ４、ＩＴＵ Ｈ．２６３又はＩＴＵ Ｈ．２６４に従ってビデオ・エンコーデイングに適応化されてもよい。ビデオ・エンコーダー２０は、ＤＳＰ又は埋込み論理コアによって実装されてもよい。

オーデイオ・ソース１７は、マイクロフォン、又はスピーチ・シンセサイザ装置のようなオーデイオ・キャプチャ・デバイスであってもよい。オーデイオ・エンコーダー２２は、ビデオ・データを伴うようにオーデイオ・データをコード化してもよい。オーデイオ・データは、適応マルチレート狭帯域（ＡＭＲ−ＮＢ）のようなオーデイオ圧縮法又は他の技術に従ってコード化されてもよい。ＶＴ適用に対しては、ビデオは、ＶＴ会議の相手方を見ることができるようにし、また、オーデイオは、その相手方の話声が聞こえるようにするであろう。

動作においては、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６は、ビデオ・エンコーダー２０及びオーデイオ・エンコーダー２２からビデオ及びオーデイオ・データ・パケットを取得する。ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６は、適当なヘッダー情報をオーデイオ・パケットに付加しかつその結果のデータをＲＬＰキュー２８内に挿入する。同様に、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６は、適当なヘッダー情報をビデオ・パケットに付加しかつその結果のデータをＲＬＰキュー２８内に挿入する。ＭＡＣ層モジュール３０は、ＲＬＰキュー２８からデータを検索し、そして、ＭＡＣ層パケットを形成する。各ＭＡＣ層パケットは、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰヘッダー情報及びＲＬＰキュー２８に含まれているオーデイオ又はビデオ・パケット・データを搬送する。

オーデイオ・パケットは、ビデオ・パケットとは独立にＲＬＰキュー２８に挿入されてもよい。ある場合には、ＲＬＰキュー２８のコンテンツから生成されるＭＡＣ層パケットは、ヘッダー情報とビデオ・パケット・データだけを搬送するであろう。他の場合には、そのＭＡＣ層パケットは、ヘッダー情報とオーデイオ・パケット・データだけを搬送するであろう。

ある場合には、そのＭＡＣ層パケットは、ＲＬＰキュー２８のコンテンツに依存して、ヘッダー情報、オーデイオ・パケット・データ、及びビデオ・パケット・データを搬送するであろう。そのＭＡＣ層パケットは、無線リンク・プロトコル（ＲＬＰ）に従って構成されてよく、かつＭＡＣ ＲＬＰパケットと呼ばれてもよい。ＰＨＹ層モジュール３２は、ＭＡＣ ＲＬＰオーデイオ―ビデオ・パケットをチャンネル１６を通じての送信のためのＰＨＹ層パケットに変換する。

チャンネル１６は、ＰＨＹ層パケットをデコーダー・システム１４に搬送する。例えば、チャンネル１６は、ローカル又はワイドエリア・ワイヤード・ネットワーク（local or wide-area wired network）のようなワイヤード・コネクション（wired connection）でありうる。あるいは、ここに記述されるように、チャンネル１６は、セルラー（cellular）、サテライト（satellite）又は光（optical）チャンネルのようなワイヤレス・チャンネル（wireless channel）であってもよい。

チャンネル状態はワイヤード及びワイヤレス・チャンネルにとって問題となりうるが、チャンネル状態がフェーデイング及び混雑によって悪化しうるワイヤレス・チャンネル１６で行われる移動ＶＴ適用にとっては特に問題となる。例えば、チャンネル１６は、チャンネル状態に従って変化するスループット（throughput）を有するリバース・リンク（ＲＬ）によって特徴づけられてもよい。スループットは、現在のワイヤレス・チャンネル送信レート、ワイヤレス・ベース・ステーション・アクテイビテイ（wireless base station activity）、及び送信電力制限の１つ又はそれより多くによって表されるように、チャンネル状態に基づいて評価されてもよい。例えば、チャンネル状態は、現在のＭＡＣ層データ・レート、リバース・アクテイビテイ・ビット（reverse activity bit (RAB)）、及びパワー・アンプリファイア（ＰＡ）リミット（power amplifier (PA) limit）に基づいて判定されてもよい。

ビデオ・エンコーダー２０は、コード化されたビデオの量をターゲット・エンコデイング・レート（target encoding rate）に対して表わす仮想ビデオ・バッファ（virtual video buffer）を維持してもよい。ターゲット・エンコーデイング・レートは、チャンネル１６で送信されるビデオ・パケットに対して特定された最大エンコーデイング・レートであってもよい。ビデオ・エンコーダー２０は、ビデオ・ソース１８からのビデオの実際のエンコーデイング・レートを制御してもよい。

デコーダー・システム１４のＰＨＹ層モジュール３４は、ＰＨＹ層パケットからのＭＡＣ層パケットを識別し、そして、そのコンテンツをＭＡＣ ＲＬＰパケット内にリアセンブル（reassembles）する。ＭＡＣ層モジュール３６は、ＲＬＰキュー３８に挿入するためのビデオ及びオーデイオ・パケットを提供するために、ＭＡＣ ＲＬＰパケットのコンテンツをリセンブルする。ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰモジュール４０は、添付のヘッダー情報を除去し、そして、ビデオ・パケットをビデオ・デコーダー４２に、そしてオーデイオ・パケットをオーデイオ・デコーダー４４に提供する。

ビデオ・デコーダー４２は、デイスプレイ装置を駆動するのに使用するためのビデオ・データのストリームを生成するためにビデオ・データ・フレームをデコードする。オーデイオ・デコーダー４４は、例えばオーデイオ・スピーカでユーザに提供するためのオーデイオ情報を生成するためにオーデイオ・データをデコードする。

ビデオ・テレフォニー（ＶＴ）とは、システム１２及び１４のような少なくとも２つの装置間でのオーデイオ及びビデオ・データを搬送するパケットの実時間通信のことである。第１のＶＴ装置１２は、ビデオ・カメラ又はビデオ・アーカイブのようなビデオ・キャプチャ装置１８からビデオを取得し、ビデオ・パケットを生成するビデオ・エンコーダー２０を含む。同様に、ＶＴ装置１２におけるオーデイオ・エンコーダーは、マイクロフォン又はスピーチ・シンセサイザのようなオーデイオ・キャプチャ装置１７からオーデイオを取得し、そして、オーデイオ・パケットを生成する。ビデオ・パケット及びオーデイオ・パケットは、ＲＬＰキュー２８内に配置される。ＭＡＣ層モジュール３０は、ＲＬＰキュー２８のコンテンツからＭＡＣ層パケットを生成する。ＭＡＣ層パケットは、通信チャンネル１６で第２のＶＴ装置１４に送信するためのＰＨＹ層パケットに変換される。

移動ＶＴ適用では、ＶＴ装置（無線端末）が、ベース・ステーションから無線フォワード・リンク（ＦＬ）（すなわち、「ダウンリンク」（“downlink”）によってＰＨＹ層パケットを受信する。ＶＴ装置は、ベース・ステーションに無線リバース・リンク（ＲＬ）（すなわち、「アップリンク」（“uplink”）によってＰＨＹ層パケットを送信する。各ＶＴ装置は、受信されたＰＨＹ及びＭＡＣ層パケットを変換しかつパケット・ペイロード（packet payloads）をオーデイオ・パケット及びビデオ・パケットにリアセンブル（reassemble）するためのＰＨＹ及びＭＡＣ層を含む。ＶＴ装置内のビデオ・デコーダー４２は、デイスプレイ装置（ビデオ出力）４８によってユーザに提示するためにビデオ・データをデコードする。オーデイオ・デコーダー４４は、オーデイオ・スピーカ（オーデイオ出力）４６による出力のためにオーデイオ・データをデコードする。

無線環境における移動ＶＴは、無線チャンネルにおけるデータ・レートが制限されかつ時間と共に変化しうるから、挑戦的となりうる。例えば、ＣＤＭＡ２０００ １ｘ ＥＶ−ＤＯリリース０又はリビジョンＡネットワークでは、データ・レートは、無線カバレージ・エリア内のチャンネル状態又は多数のＶＴユーザ間のトラフィック混雑に基因して変化しうる。チャンネル状態、過剰なビデオ・コンテンツ、又は両方が、ビデオの送信に大きな遅延を生じさせる可能性がある。例えば、ＲＬスループットが減少されると、ビデオ送信がＲＬを圧倒し、ビデオ送信遅延を増加させる可能性がある。その結果、移動ＶＴは、実時間でのスムーズなテレビ会議（video conferencing）を提供する能力を阻害する望ましくないビデオ及び（又は）オーデイオ遅延を受ける可能性がある。

下記の説明は、ある範囲のチャンネル状態にわたってビデオ遅延を減少させるために、ＶＴのような適用に対するビデオ・レート適応（ソース・ビデオのエンコーデイング・レートを制御する）のための技法を提供する。ビデオ・ソース・レート適応化はチャンネル適応（channel-adaptive）と呼ばれることもある。この技法は、ビデオ・ソース・エンコーデイング・レートがチャンネル状態又は過剰なビデオ・コンテンツ又は複雑性に基因して低下された場合に空間的及び時間的品質の低下を軽減するのに効果的でありうる。

ビデオ・ソース・エンコーデイング・レート制御の性能は、例えば、移動無線ＶＴシステムにおける送信者と受信者との間のビデオ送信の遅延であるエンド・ツー・エンド遅延（end-to-end delay）によって評価されうる。エンド・ツー・エンド遅延は、バッファリング及び送信遅延、空間的視覚品質、スキップされるビデオ・フレームの数、帯域幅の不十分な利用を示すエンコーダー・バッファ・アンダーフロー（encoder buffer underflow）、スレーム・スキッピング（frame skipping）を生じさせるエンコーダー・バッファ・オーバーフロー（encoder buffer overflow）、デコードするデータが無くかつデイスプレイ・レフレッシュが少ないことを示すデコーダー・バッファ・アンダーフロー（decoder buffer underflow）、失われたデータを示すデコーダー・バッファ・オーバーフロー（decoder buffer overflow）、受信機デイスプレイ・リフレッシュ・レート、オーデイオ−ビデオ同期化、エンコーダー側のピーク信号対雑音比（ＰＳＮＲ）、及び第１のイントラ（Ｉ）フレームに従う初期バッファ遅延を含みうる。

ビデオ・テレフォニー（ＶＴ）は、ＣＤＭＡ２０００ １ｘ ＥＶ−ＤＯ リビジョンＡネットワークに対する重要な適用でありうる。ＥＶ−ＤＯリビジョンＡは、フォワード・リンク（ＦＬ）（ダウンリンク）上で３．１Ｍｂｐｓまでの、そしてＲＰ（アップリンク）上で１．８Ｍｂｐｓまでのデータ・レートを与えうる。ＥＶ−ＤＯ リビジョンＡはまた、イントラ及びインター・ユーザ・サービス品質（intra- and inter-user quality of service）（ＱｏＳ）をサポートする。イントラ・ユーザＱｏＳは、オーデイオ・データにビデオ・データより高い優先度を与え、これにより、チャンネル状態が低下する場合にビデオ遅延と引き換えにしてオーデイオ遅延を減少させる。ＥＶ−ＤＯリリース０ネットワークと比較して、ＥＶ−ＤＯ リビジョンＡのより相称的な、より高いデータ・レート及びＱｏＳサポートは、帯域幅需要が大きい遅延感応性のトラフィックを搬送するのにより好適で、かつ総体的なＶＴ品質を向上させることができる。

ＥＶ−ＤＯ リビジョンＡは、ＶＴトラフィックに適合するユニークな特徴を提供するが、１つの挑戦的な問題は、根底のチャンネル状態が悪くなった場合における過剰なビデオ遅延でありうる。これは通常、ＶＴ移動装置ユーザがフェーデッド・チャンネル（faded channels）を経験したりあるいはセクタのエッジに移動してヘッドルーム（headroom）を制限された場合に生ずる。イントラ・ユーザＱｏＳがサポートされているので、オーデイオが供されかつビデオよりも高いレートで送信されるであろう。ビデオを送信するための帯域幅が無いという瞬間がありうる。従って、リソースがオーデイオ・データから自由にされるまで又はチャンネル状態が改善した後まで、ビデオ・データは、バッファ内にキューされる（queued）であろう。

図２Ａ及び２Ｂは、ＲＬチャンネル状態が悪い場合の増加したビデオ遅延を示すシミュレートしたデータ（simulated data）を例示する。このシミュレーションは、４８ｋｂｐｓ、１５フレーム・パー・セコンド（ｆｐｓ）ＭＰＥＧ−４圧縮ビデオ及びエンハンスド・バリアブル・レート・コーダー（enhanced variable rate coder (EVRC)）でコード化されたビデオを３−フレーム・バンドリング（3-frame bundling）と一緒にＥＶ−ＤＯリビジョンＡ ＲＬチャンネル・エミュレーター上で送る。ＦＬも付加的なビデオ遅延を生じさせるが、ＦＬ問題はＲＬとは独立である。下記のＲＬレート適応化技法は、総体的なエンド・ツーエンド・ビデオ遅延を改善するのを助長する。

図２Ａは、このシミュレーションにおける異なるチャンネル状態を示す。このシミュレーションでは、ネットワーク負荷は軽い、すなわち、同じセクタ内のユーザは少ない。このシミュレーションでは、ＶＴフローに対するＭＡＣ層デザインは、セクタ・ローデイングには反応しない。これは、アクセス端末が電力ヘッドルーム（power headroom ）を制限されていなければ、ＲＬリソ−ス割り当てが４８ｋｂｐｓビデオ送信を保証するであろうことを意味する。電力ヘッドルームが制限される（又はＲＬ状態が悪化する）ときには、ＭＡＣ層３０は、ビデオ・データの前にオーデイオ・データを送信する。異なるチャンネル状態が、図２Ａにおける異なるスロー・フェーデイング状況によってシミュレートされる。図２Ａにおける状態２は、チャンネルＡ時間変化シャドー（Channel-A time-varying shadow）を用いており、これは、約３キロメートル・パ・アワー（ｋｍｐｈ）でゆっくり移動するアクセス端末（ＡＴ）をシミュレートする。このＡＴがフェーデイング・エリア（fading areas）に入ると、ＡＴがそれぞれ約１０ｋｍｐｈ及び１２０ｋｍｐｈでより速く移動する状態４及び６と比較して、より長い時間、そこに留まろうとするであろう。これらのシミュレーションは、ソフト・ハンドオフ（soft handoff）を伴って及び伴わずに行われた。通常、ソフト・ハンドオフを伴わないチャンネル状態は、ソフト・ハンドオフを伴ったものより悪い。

図２Ｂは、オーデイオ及びビデオが図２Ａのテスト・チャンネル状態で送信される場合のオーデイオ及びビデオ遅延を示す。図２Ｂが示すように、オーデイオ遅延は、全てのチャンネル状態に対してそれほど増加しない。これは、ＥＶ−ＤＯリビジョンＡリバース・リンクによってサポートされるＱｏＳがビデオよりもオーデイオ・データに対して優先送信を与えるからである。ＲＬ帯域幅が減少すると、ＲＬは最初にオーデイオ・データに使用可能なリソースを割当て、そして次に、ビデオ・データ送信に残りのリソースを割当てるであろう。ＲＬ状態が悪い場合には、オーデイオ・データは、リソース（又は帯域幅）のほとんどを用いるが、ビデオ・データは、送信キュー（又はビデオ・フローＲＬＰキュー２８）内にバッファされる（buffered）されるであろう。結果として、ビデオ遅延は図２Ｂに示されているように顕著に増加する。

このシミュレーションは、オーデイオ及びビデオを、５分間、送ることによってデータを収集した。遅延は、各ビデオ・フレームに対して測定さる。状態２〜５の場合では、ビデオは、平均で２秒までの長い遅延を有する。９５％における累積遅延分布は、１２．５秒までと同程度の高さとなりうる。これらの値は、ＲＬＰキューがビデオ・データを記憶するための限定のない物理メモリを有すると仮定した、５分間の実験時間の結果である。

時間が２０分まで増加された場合には、これらの値はさらに悪くなったであろう。すなわち、ＡＴが４８ｋｂｐｓビデオ送信を支えることができないので、ビデオ・フローＲＬＰキューは、大きくなるであろう。これは、実時間ＶＴ適用にとっては容認できない。主な理由は、ビデオ・エンコーダー２０がチャンネル劣化を知らずに、４８ｋｂｐｓビデオを生成してＲＬで送り続けることである。ＲＬは、チャンネルフェーデイング時に、このような高いレートでビデオ・データをサポートできないので、ビデオ・データのほとんどがバッファされる（buffered）であろう。このバッファリング（buffering）が遅延を生じさせる。

従って、ビデオ・データがバッファされるのを回避してビデオ遅延を少なくするためにＲＰがサポートできることに整合するように、ビデオ・エンコーデイング・レートを調整することが非常に望ましい。９５％でのビデオ遅延ターゲットは２００ｍｓでありうる。

下記の記述は、ビデオ会議（video conferencing）やビデオ・シェアリング（video sharing）のようなビデオ・テレフォニー適用のための新しいビデオ・レート適応化技法を説明する。これらの技法は、ＣＤＭＡ２０００ ＥＶ−ＤＯリビジョンＡネットワークで説明されるが、他のタイプのネットワークが使用されてもよい。これらの技法は、ＲＬでチャンネル状態が劣化する場合における増加したビデオ遅延の問題に対処する。

１つの提案される方法は、ＥＶ−ＤＯリビジョンＡ ＲＬの特徴を考慮しかつビデオ・エンコーダー２０に送られるＭＡＣ層３０及びＲＬＰ層２８からの情報を用いる層間最適化設計（cross-layer optimization design）である。ビデオ・エンコーダー２０は、ＲＬ状態をモニタしかつそれのエンコーデイング・レートをチャンネル状態に従って調整するために、この情報を用いる。

ＲＬＰキューがビデオ・データを記憶するために無制限の物理的メモリを有すると仮定して、この方法は平均ビデオ遅延を９４％までだけ効果的に減少させることができ、かつ、９５パーセンタイル（percentile）遅延（デコーダー４２がエンコーダー２０によって送信されるビデオ・パケットの９５％を受信する遅延値）が、異なるチャンネル状態に対して９８％までだけ改善されうることを、シミュレーション結果は示している。更に、実効ビデオ・スループットは、４キロビット・パー・セカンド（ｋｂｐｓ）までだけ増加されうる。この提案された方法の計算量は少ないので、計算に限度のある（computation-limited）モバイル・デバイスに実装可能である。

ビデオ遅延と下層情報との間の相関関係
図３は、（ａ）レームが生成された時間による各フレームのビデオ遅延（ミリセカンドでありかつ１００で割られた）と（ｂ）下層情報、例えば、ＲＬＰ層からのビデオ・フローＲＬＰキュー・サイズ（バイトでありかつ１００で割られた）及びＭＡＣ層からの電力ヘッドルーム限界（power headroom limitation）との間の相関関係を示す。電力ヘッドルーム限界は、デシベル（ｄＢｓ）で測定され、かつ、ＭＡＣ層パケットの最大可能ペイロード・サイズ（maximum possible payload size）を限定する。電力ヘッドルーム限界値が低くければ低いほど、最大可能ペイロード・サイズは小さくなり、従って、スループットが低くなる。ヘッドルーム限界は、現在の送信電力に基づいて、送信で使用されるのを許容される最大レートを示してもよい。ＰＡ限界は、送信電力ヘッドルームを表し、かつチャンネル状態が劣化した時を示す。

図３は、ビデオ・フローＲＬＰキュー・サイズとビデオ遅延との間の強い相関関係を示す。ＲＬＰキュー・サイズが増加すると、図３におけるｘ軸に沿った2.62、2.8及び2.9あたりの時間のように、ビデオ遅延も増加する。

電力ヘッドルーム限界とビデオ遅延との間にも強い相関関係がある。電力ヘッドルーム限界が、図３において丸で囲って示されているよう、１０ｄＢ以下の場合には、ビデオ遅延が増加する。電力ヘッドルームが低ければ低いほど、ビデオ遅延は大きくなる。これらの観察に基づいて、ビデオ・フローＲＬＰキュー・サイズ及び電力ヘッドルーム限界は、ビデオ・レート適応化のための非常に有効な情報であるように思われる。

ＥＶ−ＤＯリビジョンＡ ＲＬ ＭＡＣパラメータを用いた ビデオ・レート適応化
ビデオ遅延を減少させるための２つの異なるビデオ・レート適応化技法が説明される。両方の方法とも、ＭＡＣ及びＲＬＰのような下層からの情報を用いる。どちらの技法も、下層からどのような情報が得られるかに応じて、異なる遅延性能をもって適用されうる。

第１の技法は、ビデオ・フローＲＬＰキュー・サイズだけに基づく。第２の技法は、ビデオ・フローＲＬＰキュー・サイズと電力ヘッドルーム限界との両方に基づく改良されたバージョンである。第２の技法は、第１の技法の欠点に対処し、（第２の改良された手法では、より信頼性の高い情報が入手可能であり、正確なビデオ・スループット推定を得ようとして第１の手法のように多くのことを行う必要がないから）計算量（computation complexity）は少ないが、有効ビデオ・スループットを犠牲にすることなく良好な遅延性能を有する。

すべての情報が準備できるのを待たずに、どの情報が入手可能であるかに基づいて、どちらかの技法を実施してもよい。より多い情報が入手可能である場合には、第２の技法は遅延特性を更に改良することができる。一般に、レート適応化は、ビデオ・フロー・キュー・サイズ及び電力ヘッドルーム限界に加えて、下層からの全ての可能な情報を用いることができる。より正確で柔軟なレート適応化を許容するために、より多くのＭＡＣ情報がビデオ・エンコーダー２０に送られてもよい。下記の記述は、レート適応化を行うための例として、キュー・サイズ及びヘッドルーム限界をどのように利用するかに焦点を合わせる。

第１のレート適応化技法
レート適応化には２つの異なる制約がありうる。第１の可能な制約は、ビット・レート制約でありうるが、これは、チャンネル１６がより高いレートを与えることができる場合でさえ、４８Ｋｂｐｓビデオ・データ・レートを保証することができる。あるシステム又はネットワークは、このビット・レート制約を有していないことがありうる。第２の制約は、チャンネル制約であり、これは、現在のチャンネル状態に基づいてビデオ・レートを制限するであろう。

図４は、第１のレート適応化技法を、構造及びデータ・フローの例で示す。ビデオ・エンコーダー４００は、ビデオ・レート制御ユニット４０２からのビデオ・エンコーデイング・レートを用いてビデオ・ソース４０１からのビデオ・データをコード化する。ビデオ・エンコーダー４００は、コード化ビデオ・データをＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰユニット４０６に送り、ユニット４０６はビデオ・フローＲＬＰキュー４１０にビデオ・パケットを送る。ビデオ・フローＲＬＰキュー４１０は、リバース・トラフィック・チャンネルＭＡＣ（ＲＴＣＭＡＣ）４１２にビデオ・パケットを送る。ＲＴＣＭＡＣは、チャンネル１６のＲＬで送信するために通信装置が従う手続を提供するためのプロトコルを実行する。

大きいビデオ・フローＲＬＰキュー・サイズは、ビデオ・データが長い遅延を有することを示しうる。ビデオ・エンコーダー４００及び（又は）図４における他のユニットは、ビデオ・フローＲＬＰキュー・サイズを頻繁にモニタしかつ必要な場合にビデオ・エンコーデイング・レートを調整しうる。

ビデオ・レートを調整するための１つの方法は、瞬時のＲＬＰキュー・サイズを見て、そのサイズが閾値を超えた時に１つのフレームをスキップ（skip）することである。この手法は、スキップされるフレームが多すぎることがありえ、グレースフル・ビデオ品質デグラデーション（graceful video quality degradation）を提供しないことがありうる。より良好な手法は、現在のフレーム・サイズを判定するために用いることができる入手可能なビデオ・スループットを推定するためのビデオＲＬＰの第１次統計（first-order statistics）を見ることである。

ビデオ・エンコーダー４００は、フレーム・バイ・フレーム（frame-by-frame basis）に各フレームに対してビットを割当てうる（すなわちフレーム・サイズを判定しうる）。例えば、１５ｆｐｓビデオでは、フレーム・サイズ情報ユニット４０４が、６６ｍｓ毎に、各フレームのサイズを決定しうる。ＲＬが電力ヘッドルームを制限されておらず、かつ、セクタがロード（loaded）されていない場合には、フレーム・サイズ・インフォ・ユニット４０４が、ターゲット・ビット・レート制約４１４に基づいてフレーム・サイズを割当てる。そうでない場合には、チャンネル制約フレーム・サイズ推定ユニット４０８は、生成すべきかつＲＬを圧倒しないデータの量を知る必要がある。従って、チャンネル制約フレーム・サイズ推定ユニット４０８は、ＲＬが２つの連続したビデオ・フレーム間で処理できるデータの最大量を推定する。推定誤差はビデオ・フローＲＬＰキュー・サイズに反映されるであろう、そして、これは、チャンネル制約フレーム・サイズ推定ユニット４０８が次のフレームのフレーム・サイズを決定する場合に斟酌されるであろう。

ステップ１：ビデオ・フローＲＬＰキュー・サイズを取得する
チャンネル制約フレーム・サイズ推定ユニット４０８は、ビデオ・フローＲＬＰキュー・サイズＶを検索するために周期的にＲＬＰ層に問合せるであろう。

図５Ａは、ビデオ・フローＲＬＰキュー・サイズを取得するためのＲＬＰ層に対するアプリケーション層問合せの頻度を示しており、この頻度はオーデイオ・フレーム・レート（２０ｍｓ毎の）及びビデオ・フレーム・レート（１５ｆｐｓでコード化される場合には６６ｍｓ毎の）に基づく。図５Ａにおけるビデー・フレーム・レートは、ビデオ・エンコーダー４００がサイズＢ_ｎ−１のフレームｎ−１をコード化するための期間である。チャンネル制約フレーム・サイズ推定ユニット４０８は、オーデイオ・タイマー及びビデオ・タイマーに基づいて問合わせられる情報を分離してもよい。ＲＬＰキュー・サイズがオーデイオ・タイマーに基づいて問合わせられる場合には、チャンネル制約フレーム・サイズ推定ユニット４０８は、キュー・サイズ及び問合わせられた時間を（Ｖ_ｍ、ｔ_ｍ）として記録／記憶することができる。オーデイオ・タイマーは、通常２０ｍｓ毎であるが、どんなスピーチ・エンコーダーが用いられるかに応じて、１０ｍｓ又は３０ｍｓであってもよい。

ＲＬＰキュー・サイズがビデオ・タイマーに基づいて問合される場合には、チャンネル制約フレーム・サイズ推定ユニット４０８は、図５Ａに示されているように、キュー・サイズ及び問合せ時間を（Ｖ_ｎ、ｔ_ｎ）として記録／記憶しうる。ビデオ・タイマーは、２つの連続したフレームの間の時間間隔であり、フレーム・レートに基づいている。１５ｆｐｓビデオ・フレームの場合には、ビデオ・タイマーは６６ｍｓ毎である。

チャンネル制約フレーム・サイズ推定ユニット４０８がビデオ・タイマーを用いてＲＬＰキュー・サイズを問合せるだけである場合には、Ｖ_ｎはゼロとなることができ、そして、チャンネル制約フレーム・サイズ推定ユニット４０８は、ＲＬがｔ_ｎ及びｔ_ｎ−１の間にキュー４１０における送信をいつ終了するかを知ることはないであろう。従って、チャンネル・スループットが過小評価されうる。これが、より頻繁にＲＬＰキュー・サイズを問合せるためにオーデイオ・タイマーを用いる理由である。ＲＬＰ層に対するより頻繁な問合せを許容することにより、チャンネル制約フレーム・サイズ推定ユニット４０８は、ＲＬＰキュー４１０が空になった場合に、追跡することができる。

Ｖｘ及びｔｘを見出すための方法は、下記のように表されうる。

if (V_n > 0) or (V_m > 0)
V_x = V_n; t_x = t_n;
else
i=1;
loop
{
if ((t_m-i > t_n-1) and (V_m-i > 0)) or (t_m-i <= t_n-1)
{
V_x = V_m-i+1; t_x = t_m-i+1;
ループを完了して停止する;
}
else i=i+1;
}
（Ｖ_ｘ、ｔ_ｘ）は、下記のように、ビデオ・スループットを計算するために用いられるであろう。図５Ａは、オーデイオ・タイマーに基づいた３つの問合せだけを示す。これは、１５ｆｐｓのフレーム・レートに基づく。7.5ｆｐｓ又は５ｆｐｓのようなより低いフレーム・レートが用いられる場合には、より多くの問合せがあることになり、かつ、上記のプロセスは、より包括的（generic）になるように修正されるべきである。上記の方法は、Ｖ_ｎがゼロである場合にＲＬＰビデオ・キュー４１０がゼロとなる時点をサーチするためである。Ｖ_ｎがゼロでない場合には、チャンネル制約フレーム・サイズ推定ユニット４０８は、ｔ_ｎを時間ｔ_ｘとして使用し、かつ、チャンネルが時間ｔ_ｎ−１で生成されたデータをフラッシュアウト（flush out）することができないから、ビデオ・スループット（上記の）を推定することになる。

図５Ｂ〜図５Ｅは、上記の方法を用いてＲＬＰキュー・サイズを判定する例を示す。図５Ｂでは、この方法は、（Ｖ_ｎ＞０）又は（Ｖ_ｍ＞０）であるかを判定する。Ｖ_ｍ＞０であるので、この方法は、Ｖ_ｘ＝Ｖ_ｎ及びｔ_ｘ＝ｔ_ｎと設定する。なぜなら、ｔ_ｎは、ＲＬＰキュー・サイズがゼロとなる時間であるから。これは、チャンネルがｔ_ｎ−１とｔ_ｎとの間で５５０バイトを消費することを意味する。

図５Ｃでは、この方法は、（Ｖ_ｎ＞０）又は（Ｖ_ｍ＞０）であるかを判定する。答えはノー（no）であり、これは、ＲＬＰキュー・サイズがＶｍより早くゼロになることを意味する。この場合には、この方法は、Ｖ_ｘ＝Ｖ_ｎ；ｔ_ｘ＝ｔ_ｎと設定することができない。この方法は、ＲＬＰキュー・サイズがいつゼロになるかを見出す必要はない。この方法は、ＲＬＰキュー・サイズがいつゼロになるかを見出すために、Ｖ_ｍからそれより早い全ての時間Ｖ_ｍ−１、Ｖ_ｍ−２までをサーチする。この方法は、ｉ＝１と設定する。この方法は、Ｖ_ｍ−ｉ（ただし、ｉ＝１）がゼロに等しいか否かを判定する。Ｖ_ｍ−ｉが１５０バイトであるから、答えはノー（no）である。この方法は、ｔ_ｍはＲＬＰキュー・サイズがゼロになる時間であることを知る。そして、この方法は、Ｖ_ｘ＝Ｖ_ｍ及びｔ_ｘ＝ｔ_ｍと設定することができる（ただし、この場合には、ｍ−ｉ＋１＝ｍである）。

図５Ｄでは、この方法は、（Ｖ_ｎ＞０）又は（Ｖ_ｍ＞０）であるかを判定する。答えはノー（no）であり、これは、ＲＬＰキュー・サイズがＶ_ｍよりも早くゼロになることを意味する。この場合には、この方法は、Ｖ_ｘ＝Ｖ_ｎ；ｔ_ｘ＝ｔ_ｎと設定することができない。この方法は、ＲＬＰキュー・サイズがいつゼロになるかを判定する必要がある。この方法は、ＲＬＰキュー・サイズがいつゼロになるかを見出すために、Ｖ_ｍからそれより早い全ての時間Ｖ_ｍ−１、Ｖ_ｍ−２までサーチする。この方法は、ｉ＝１と設定する。この方法は、Ｖ_ｍ−ｉ（ただし、ｉ＝１）がゼロに等しいか否かを判定する。答えはイエス（yes）であり、この方法はｉを１だけ増加する。そこで、ｉ＝２となる。この方法は、Ｖ_ｍ−ｉ（ただし、ｉ＝２）がゼロに等しいか否かを判定する。答えはノー（no）であり、Ｖ_ｍ−ｉは２５０バイトである。それで、この方法は、ｔｍ−１（ただし、ｍ−ｉ＋１＝ｍ−１）はＲＬＰキュー・サイズがゼロになる時間であることを知る。そして、この方法は、Ｖ_ｘ＝Ｖ_ｍ−１；ｔ_ｘ＝ｔ_ｍ−１と設定できる。

図５Ｅでは、この方法は、（Ｖ_ｎ＞０）又は（Ｖ_ｍ＞０）であるかを判定する。答えはノー（no）であり、これは、ＲＬＰキュー・サイズがＶｍよりも早くゼロになることを意味する。この場合には、この方法は、Ｖ_ｘ＝Ｖ_ｎ；ｔ_ｘ＝ｔ_ｎと設定することができない。この方法は、ＲＬＰがいつゼロになるかを判定する必要がある。この方法は、ＲＬＰキュー・サイズがいつゼロになるかを見出すために、Ｖｍからそれより早い全ての時間Ｖ_ｍ−１、Ｖ_ｍ−２までサーチする。この方法は、ｉ＝１と設定する。この方法は、Ｖ_ｍ−ｉ（ただし、ｉ＝１）がゼロに等しいか否かを判定する。答えはイエス（yes）であり、この方法は、ｉを１だけ増加する。そこで、ｉ＝２となる。この方法は、Ｖ_ｍ−ｉ（ただし、ｉ＝２）がゼロに等しいか否かを判定する。答えはイエス（yes）であり、この方法は、ｉを１だけ増加する。そこで、ｉ＝３となる。そこで、ｔ_ｍ−ｉは、ｔ_ｎ−１よりも早い。これは、この方法が、２つのビデオ・フレームの間における全てのＲＬＰキュー・サイズをチェックしたことを意味する。この場合には、この方法は、Ｖ_ｘ＝Ｖ_ｍ−２；ｔ_ｘ＝ｔ_ｍ−２（ただし、ｉ＋１＝ｍ−２）と設定するであろう。

ＲＬＰキュー・サイズを用いるこの方法では、Ｖ_ｘ及びｔ_ｘを判定する基本的概念は、Ｖ_ｎがゼロである場合に、ＲＬＰキュー・サイズがいつゼロになるかをサーチすることである。これは、Ｖ_ｎがゼロである場合には、この方法は、ＲＬがいつ全てのデータを送信するかを知ることがなく、従って、推定はチャンネル帯域幅を過小評価する可能性があるからである。Ｖ_ｎがゼロでない場合には、この方法は、ｔｎを時間として用いてビデオ・スループットを推定することができるにすぎない。

ステップ２：ビデオ・スループットを推定する
１つのフレームが、エンコーデイング前の時間ｔ_ｎにおける現在のフレームに時間ｔ_ｎ−１において送られた最後の時間以来のビデオ・スループットは、チャンネル制約フレーム・サイズ推定ユニット４０８によって、数１のようにして推定されうる。

ただし、Ｂ_ｎ−１は、フレームｎ−１のサイズである。ｔ_ｘは、Ｖ_ｎがゼロでない場合に、ビデオ・フローＲＬＰキュー・サイズが空に又はｔ_ｎに等しくなった時間である。

ステップ３：チャンネル制約最大フレーム・サイズを判定する
ビデオ・スループットＶＴＰが推定された後で、チャンネルが変化しないと仮定して、チャンネル制約フレーム・サイズ推定ユニット４０８は、ＲＬが提供できる最大スレーム・サイズを、数２のようにして判定する。

ただし、Ｆは、フレーム・レートである。Ａ（ＶＴＰ）は、ビデオ・エンコーダー４００がどの程度チャンネルに反応するかを制御するための調整係数である。Ａ（ＶＴＰ）は、推定ビデオ・スループットの関数でありうる。Ａ（ＶＴＰ）は、先行のビデオ・フレームが小さかった場合に有効であり、ＶＴＰは、チャンネル１６の真の帯域幅を過小評価する。Ａ（ＶＴＰ）は、異なる適用からの異なる遅延制約に従ってビデオ遅延を制御するためにも用いられうる。例えば、ビデオ会議は、より小さい値のＡ（ＶＴＰ）を用いることができるが、ビデオ・シェアリング適用（video sharing application）は、より大きい値を用いることができる。Ａ（ＶＴＰ）は、定数又は変数でありうる。Ａ（ＶＴＰ）の一例は、１００バイトである。

ステップ４：ターゲット・フレーム・サイズを判定する
フレーム・サイズ情報ユニット４０４は、フレームｎのターゲット・フレーム・サイズを、数３のようにして判定することができる。

ただし、数４は、平均ビデオ・ビット・レートを制御するために用いられる、サイズＷｎを有する仮想バッファ４１６によって制約されたフレーム・サイズである。仮想バッファ４１６は、プロセッサによって実行されるメモリ及びソフトウエアによって実装されうる。Ｂ_minは、良好な画像品質を保証するために制御される最小フレーム・サイズである。

チャンネル制約フレーム・サイズが小さすぎる場合には、フレーム・サイズ情報ユニット４０４は、劣悪な画像を生成して帯域幅を無駄にせずに、このフレームをスキップするであろう。

フレーム・サイズ情報ユニット４０４は、ビデオ・レートを判定するために、ビデオオ・レート制御ユニット４０２にターゲット・フレーム・サイズを送る。ビデオ・レートは、時間周期（例えば、６６ｍｓ）当たりのビデオ・データ・フレーム・サイズに等しい。

第１のレート適応化技法はビデオ遅延を十分に減少することができるが、考えられる問題点は、チャンネル・グラデーション（channel degradation）がＲＬＰキュー４１０にバッファされるビデオ・データを生じさせた後にだけ、作用することである。この技法は、ＲＬＰキュー４１０に既にバッファされたフレームに対しても長い遅延を生ずることがありうる。

第２のレート適応化技法
図６は、構造及びデータ・フローの複数の例で第２のレート適応化技法を示す。第２のレート適応化技法では、チャンネル制約ビデオ・スループット推定ユニット６０８は、ビデオ・スループットを推定するために、ＭＡＣ層６１２からの付加的な情報（例えば、パワー・アンプリファイア（ＰＡ）ヘッドルーム限界）（power amplifier (PA) headroom limitation）を用いる。この第２の技法は、ビデオ・フローＲＬＰキュー・サイズの第１次統計（first-order statistics）によるのではなくて、電力ヘッドルーム限界に基づいてビデオ・スループットを積極的に推定（予測）する。ＭＡＣ層６１２は、ＭＡＣパケットのペイロード・サイズ（payload size）を判定するための限界係数として電力ヘッドルーム限界を用いる。電力ヘッドルーム限界は２つの連続したビデオ・フレームの間では大きくは変化しないので、チャンネル制約ビデオ・スループット推定ユニット６０８も、ビデオ・スループットを推定するために電力ヘッドルーム限界を用いることができる。

あるいは、ユニット６０８が、フレームをコード化する前に瞬時ＭＡＣペイロード・サイズを知る場合には、そのユニット６０８は、ビデオ・スループットを予測するために瞬時ＭＡＣペイロード・サイズを用いることができる。このようにして、ユニット６０８は、ＲＬを圧倒する過剰なデータを送ることを回避するための積極的な方法でフレーム・サイズをより正確に判定することができる。

ステップ１：電力ヘッドルーム限界及びビデオ・フロー・サイズを取得する
チャンネル制約ビデオ・スループット推定ユニット６０８は、ビデオ・フロー・キュー・サイズを取得するためにＲＬＰ層に問合せる、また、電力ヘッドルーム限界を取得するためにＭＡＣ層６１２に問合せる。問合せ頻度は、毎６６ｍｓでありうる。この第２のレート適応化技法では、オーデイオ・タイマーを用いる必要はない。ユニット６０８は、電力ヘッドルーム限界及びビデオ・フローＲＬＰキュー・サイズを記憶しうる。

ステップ２：テーブル・ルックアップに基づいてＭＡＣペイロード・サイズを取得する
ＭＡＣ層６１２は、テーブル・ルックアップによってＭＡＣペイロード・サイズを判定しうる。ＭＡＣ層６１２は、電力ヘッドルーム限界を最大ペイロード・サイズに変換するために、図７Ａ及び図７Ｂに示されているようなテーブルを維持しうる。この変換は、次のステップにおいて最大ビデオ・スループットを判定するためにも用いることができる。この変換は、ＭＡＣ層６１２自体でも行われることができる、すなわち、ＭＡＣ層６１２は、電力ヘッドルーム限定ペイロード・サイズをアプリケーション層に送ることができる。図７Ａは、電力ヘッドルーム限界（最左欄）及びＭＡＣペイロード・サイズに対する変換テーブルを示す。実効データ・レートも、異なるターミネーション・ターゲット（termination targets）に対して示されている。

図７Ａのテーブルは、一例である。ターミネーション・ターゲット及び送信モード（ハイ・キャパシテイ（ＨｉＣａｐ）又はロー・ラテンシイ（low latency）（ＬｏＬａｔ））に応じて、ペイロード・サイズを決定するためにＭＡＣで用いられる他のテーブルが存在しうる。図７Ｂは，電力ヘッドルーム限界に基づく他のペイロード・サイズ変換を示す。

ステップ３：ビデオ・スループットを推定する
チャンネル制約ビデオ・スループット推定ユニット６０８は、下記のようにビデオ・スループットを予測することができる。

VTP=Payload_Size*TX_Opportunities
TX_Opportunitiesは、毎６６ｍｓに、どのくらいの送信機会が与えられるかの推定である。TX_Opportunitiesは、現在のＭＡＣデザイン、３−インターレース構造（3-interlace structure）のようなＲＬ特性、及びオーデイオ・データを考慮して判定される。例えば、TX_Opportunitiesは、３であってもよいが、他の値が用いられてもよい。

ステップ４：チャンネル制約最大フレーム・サイズを判定する
チャンネル制約ビデオ・スループット推定ユニット６０８は、チャンネル制約最大フレーム・サイズを数５で判定することができる。

ステップ５：ターゲット・フレーム・サイズを判定する
フレーム・サイズ情報ユニット６０４は、現在のフレームに対するターゲット・サイズを、数６のように判定しうる。

第２のレート適応化技法は、同等のビデオ・スループットに対して、より小さいビデオ遅延を有する。これは、電力ヘッドルーム限界を用いることが、ビデオ・スループットをより良好に推定できることを意味する。第２のレート適応化技法は、多くの場合に対して、９５％における２００ｍｓの遅延ターゲットを満たしうる。

本明細書に記述された技法は、汎用マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ），書替え可能ゲートアレイ（ＦＰＧＡ）、又は他の同等の論理デバイス内で実行されうる。例えば、ビデオ・エンコーダー・システム１２、及びそれのコンポーネントとモジュールは、デジタル信号プロセッサ（ＤＳＰ）、マイクロプロセッサ、埋込みコア、又は他の処理装置で走行するエンコーデイング・プロセス、すなわちコーデイング／デコーデイング（ＣＯＤＥＣ）プロセスの部分として実装されうる。従って、モジュールとして記述されたコンポーネントは、ハードウエア・コンポーネント又はエンコーデイング・プロセス、又は独立のプロセスのプログラム可能な特徴を形成してもよい。

いくつかの実施の形態では、エンコーデイング機能は、異なるハードウエア・コンポーネント間で分割されてもよい。例えば、フレームレベル・レート制御は、埋込み論理コアで行われてもよく、また、ＭＢレベル・レート制御は、ＤＳＰで行われてもよい。例示として、ターゲット・ビット・レート（Ｒ Ｋｂｐｓ）及びフレーム・レート（Ｆ ｆｐｓ）を仮定すると、埋込み論理コア内でのフレームレベル・レート制御は、各フレームをコード化し、次のフレームに対するフレーム・バジェットＢ（frame budget B）を推定し、そして例えばｒｈｏテーブル又はｒｈｏパラメトリック方程式（either a rho table or a rho parametric equation）により、バジェット・ツー・ｒｈｏ及びｒｈｏ・ツー・ＱＰマッピング（budget-to-rho and rho-to-QP mappings）を用いてフレーム・バジェット（frame budget）をフレームＱＰにマッピング（例えば、１対３１）した後で、レート制御モデル・パラメータ、例えば、ｒｈｏドメイン・モデル・パラメーター（rho domain model parameters）を更新することを含んでもよい。

フレームＱＰに対する付加的な制約を含めて、ＱＰ値の後処理が完了すると、埋込み論理コアは、フレームＱＰ、ｒｈｏバジェット（rho budget）及び新しいモデル・パラメータをＤＳＰに送る。ＤＳＰは、ｒｈｏ・ツー・ＱＰマッピング（rho-to-QP mapping）を用いて各ＭＢに対するＱＰを計算し、そしてＱＰ値の後処理を行う。ＤＳＰは、ＭＢ ＱＰ（複数）に対する付加的な制約と共に、ＭＢデルタＱＰ値が＋２及び−２内であるというルールを保持できる。ＭＢをコード化した後でｒｈｏドメイン・モデル・パラメーター（rho domain model parameters）の更新を完了すると、ＤＳＰは、適用可能なビデオ・フレーム内の他のＭＢ（複数）に対するプロセスを反復する。ＭＢコード化が完了した後で、プロセスは、コード化されるべき次のビデオ・フレームを処理するために、埋込み論理コアに戻る。

ビデオ・エンコーダー・システム１２は、専用のハードウエア、ソフトウエア、ファームウエア、又はそれらの組み合わせと共に、命令及びデータを記憶するための専用メモリを有してもよい。ソフトウエアで実装される場合には、これらの技法は、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）、電気的に消去可能なプログラム可能読取り専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリ、等のようなコンピュータ読取り可能媒体上で命令として具現されてもよい。その命令は、本明細書で記述された機能性のある態様を１つの又はそれより多いプロセッサに行わせる。

本明細書で記述された技法は、汎用マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、書替え可能ゲートアレイ（ＦＰＧＡ）、又は他の同等の論理デバイス内で実装されてもよい。例えば、ビデオ・エンコーダー・システム１２、ビデオ・デコーダー・システム１４、及び関連するコンポーネント及びモジュールは、デジタル信号プロセッサ（ＤＳＰ）又は他の処理装置で走行するエンコーデイング・プロセス、又はコーデイング／デコーデイング・プロセスの部分として実装されてもよい。従って、モジュールとして記述されたコンポーネントは、このようなプロセス、又は独立のプロセスのプログラム可能な特徴を形成してもよい。

ビデオ・エンコーダー・システム１２は、専用のハードウエア、ソフトウエア、ファームウエア、又はそれらの組み合わせと共に、命令及びデータを記憶するための専用メモリを有してよい。ソフトウエアで実装される場合には、これらの技法は、１つの又はそれより多いプロセッサによって実行可能な命令として具現されてもよい。その命令は、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）、電気的に消去可能なプログラム可能読取り専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリ、磁気的又は光学的データ記憶装置、等のようなコンピュータ読取り可能媒体上に記憶されてよい。その命令は、本明細書で記述された機能性のある態様を１つの又はそれより多いプロセッサに行わせる。

種々の実施の形態が記述された。これらの及び他の実施の形態は、請求項の範囲内にある。

ビデオ・エンコーデイング及びデコーデイング・システムを例示する。 リバース・リンク（ＲＬ）状態が悪い場合の増加したビデオ遅延を示すシミュレートしたデータ（simulated data）を例示する。 リバース・リンク（ＲＬ）状態が悪い場合の増加したビデオ遅延を示すシミュレートしたデータ（simulated data）を例示する。 （ａ）各フレームのビデオ遅延と（ｂ）下層情報との間の相関関係を例示する。 構造及びデータ流れの例で第１のレート適応化技法を例示する。 ビデオ・フローＲＬＰキュー・サイズを得るための下層へのアプリケーション層問合せの頻度を例示しており、前記頻度がオーデイオ・フレーム・レート及びビデオ・フレーム・レートに基づく。 ＲＬＰキュー・サイズを判定する例を例示する。 ＲＬＰキュー・サイズを判定する例を例示する。 ＲＬＰキュー・サイズを判定する例を例示する。 ＲＬＰキュー・サイズを判定する例を例示する。 構造及びデータ・フローの例で第２のレート適応化技法を例示する。 電力ヘッドルーム限界を最大ペイロード・サイズに変換するためのテーブルを例示する。 電力ヘッドルーム限界を最大ペイロード・サイズに変換するためのテーブルを例示する。

Claims (33)

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. 無線リンク・プロトコル（ＲＬＰ）層内のビデオ・キューのサイズを判定するための手段と、
    媒体アクセス制御（ＭＡＣ）層から送信電力ヘッドルーム限界を判定するための手段と、
    ＭＡＣペイロード・サイズを判定するために、前記判定された送信電力ヘッドルーム限界を用いるための手段と、
    推定されたビデオ・スループットを判定するために、前記判定されたＭＡＣペイロード・サイズ及び１つの期間において前記ビデオにどのくらいの送信機会が与えられるかについての推定を用いるための手段と、
    チャンネル制約ビデオ・フレーム・サイズを判定するために、前記推定されたビデオ・スループット及び前記ＲＬＰ層内のビデオ・キューの前記判定されたサイズを用いるための手段と、
    ビデオ・エンコーデイング・レートを制御するために前記チャンネル制約ビデオ・フレーム・サイズを用いるための手段と、
    を備える装置。

Images