JP2009510942A

JP2009510942A - テレビ電話のためのビデオパケット整形

Info

Publication number: JP2009510942A
Application number: JP2008533677A
Authority: JP
Inventors: リー、イエン−チ
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2005-09-29
Filing date: 2006-09-29
Publication date: 2009-03-12
Also published as: WO2007041319A2; KR100982155B1; US8102878B2; KR20080066002A; US20070071030A1; CN101313536B; EP1929720A2; CN101313536A; EP1929720B1; JP5661678B2; WO2007041319A3; JP2012170120A

Abstract

本開示は、テレビ電話のためのビデオパケット整形についての技術に関する。この技術は、オーディオ遅延を低減するためにオーディオパケットに優先付けするために使用することができる。チャンネル条件、過大なビデオコンテンツ、またはその両者がオーディオ送信における遅延を生じさせる可能性がある。逆方向リンク（ＲＬ）スループットが低下すると、ビデオパケットサイズはＲＬを圧倒してオーディオ遅延を増大させることができる。該ビデオパケットは過大な数のＭＡＣ・ＲＬＰパケットを消費し、連続するオーディオパケットの間の遅延を生じさせるかもしれない。各ビデオパケットのサイズは、オーディオパケットが実質的な遅延を伴わない送信のために優先付けされるように調節される。該ビデオパケットサイズは、チャンネル条件に基づいて制御されてもよい。該オーディオは、例えビデオがチャンネル条件に起因して遅延を受けるとしても、実質的遅延を伴わずに搬送されることができる。ビデオはチャンネル条件によって損なわれるかもしれないが、ビデオパケット整形は、ＶＴ参加者が円滑に口頭での会話を続行できることを保証する。
【選択図】図５

Description

本開示はテレビ電話（ＶＴ）に関し、更に特定すれば、ＶＴシステムにおける送信のために、オーディオおよびビデオパケットをアセンブルするための技術に関する。

背景

テレビ電話（ＶＴ）は、オーディオデータおよびビデオデータを担持したパケットのリアルタイム通信を含んでいる。各ＶＴ装置は、ビデオ捕捉装置またはビデオアーカイブからビデオを得て、ビデオパケットを発生させるビデオエンコーダを含んでいる。同様に、各ＶＴ装置におけるオーディオエンコーダは、マイクロホンまたはスピーチシンセサイザのようなオーディオ捕捉装置からオーディオを得て、オーディオパケットを発生させる。ビデオパケットおよびオーディオパケットは、無線リンクプロトコル（ＲＬＰ）待ち行列の中に配置される。媒体アクセス制御（ＭＡＣ）層モジュールは、ＲＬＰ待ち行列のコンテンツから媒体アクセス制御（ＭＡＣ）層パケットを発生させる。該ＭＡＣ層パケットは、もう一つのＶＴ装置への通信チャンネルを横切る送信のために、物理（ＰＨＹ）層パケットに変換される。

モバイルＶＴアプリケーションにおいて、ＶＴ装置は、ベースステーションから無線端末への無線順方向リンク（ＦＬ）（または「ダウンリンク」）を介して、物理層パケットを受信する。ＶＴ装置は、無線端末からベースステーションへの無線逆方向リンク（ＲＬ）（または「アップリンク」）を介して、ＰＨＹ層パケットを送信する。各ＶＴ装置は、受信されたＰＨＹ層およびＭＡＣ層パケットを変換し、該パケットペイロードをオーディオパケットおよびビデオパケットにアセンブルするために、ＰＨＹ層およびＭＡＣ層を含んでいる。ＶＴ装置内のビデオデコーダは、ディスプレイ装置を介してユーザに提示するために、ビデオデータをデコード化する。ＶＴ装置内のオーディオデコーダは、オーディオスピーカを介して提示するためにオーディオデータをデコード化する。

無線環境におけるモバイルＶＴは、困難な課題である可能性がある。無線チャンネル上でのデータレートは制限され、且つ経時的に変化する。例えば、ＣＤＭＡ２０００・１×ＥＶ−ＤＯリリース０ネットワークにおいて、該データレートは、無線受信可能エリア内での条件、または多重ＶＴユーザ間でのトラヒック混雑に起因して変化する可能性がある。加えて、データレートがゼロに落ちるとき、例えば送るべきデータが存在しないときには、合理的なデータレートへの復帰に時間を要する可能性がある。その結果、モバイルＶＴは望ましくないビデオおよびオーディオの遅延を受け易く、これはリアルタイムでの円滑なビデオ会議を実行する能力を徐々に害する可能性がある。

概要

一般に、本開示は、ＶＴ応用についてのビデオパケット整形のための技術に向けられている。ビデオパケット整形技術は、オーディオパケットを優先させて、オーディオ遅延を低下させるために使用することができる。チャンネル条件、過大なビデオコンテンツ、またはその両者は、オーディオパケットの送信において顕著な遅延を生じさせることができる。逆方向リンク（ＲＬ）スループットが減少すると、ビデオパケットサイズはＲＬを圧倒して、オーディオ遅延を増大させることができる。特に、ビデオパケットはＲＬＰ待ち行列を満たし、過大な数のＭＡＣ層パケットを消費して、オーディオパケットを担持するＭＡＣ層パケットの連続する送信間で遅延を生じるかもしれない。

本開示の技術に従えば、各ビデオパケットのサイズは、実質的遅延を伴わない送信のためにオーディオパケットが優先されるように調節される。特に、ＲＬＰ待ち行列に提示される各ビデオパケットのサイズは、オーディオの適時送信を保証するように制御される。例えば、各オーディオパケットが、ＲＬＰ待ち行列から得た次の利用可能なＭＡＣ層パケットと共に送ることができるように、ビデオパケットをサイズ設定してよい。このようにして、アプリケーション層におけるオーディオパケットのためのサービスの品質（ＱｏＳ）を提供することができる。

ビデオパケットサイズは、無線チャンネルのようなチャンネルの推定スループットに基づいて制御されてよい。該スループットは、現在の無線チャンネル送信レート、無線ベースステーション活動、または送信電力制限によって表されるような、チャンネル条件に基づいて推定されてよい。ＶＴ会議のオーディオ部分は、ビデオ部分がチャンネル条件による遅延を受け得るとしても、実質的な遅延なしに伝達されることができる。ビデオはチャンネル条件によって損なわれ得るが、ビデオパケット整形は、ＶＴ会議への参加者が円滑に口頭での会話を続行できることを保証する。

加えて、幾つかの実施形態において、ビデオパケット整形技術は更に、ビデオバッファー占有に基づく適応ソースレート制御を含んでよい。この場合に、優先付けされたオーディオパケット化の必要性を仮定すれば、ソースビデオコード化レートは、チャンネル条件が該ビデオコード化レートをサポートしないときには低下する。ビデオコード化レートは、例えば、ビデオバッファーに駐在するパケット化されていないビデオフレームデータの量に基づいて調節されてよい。

一つの実施形態において、本開示は、オーディオパケットを発生させること、無線チャンネルのスループットを予測すること、および該予測されたスループットに基づいて決定されたビデオパケットサイズを用いてビデオパケットを発生させることを含んでなる方法を提供する。

もう一つの実施形態において、本開示は、オーディオデータを生じるオーディオエンコーダ、該オーディオデータを受信してオーディオパケットを出力するオーディオバッファー、ビデオデータを発生するビデオエンコーダ、無線チャンネルのスループットを予測し、該予測されたスループットに基づいて決定されたビデオパケットサイズで前記ビデオデータからビデオパケットを発生させるパケタイザを含んでなるシステムを提供する。

追加の実施形態において、本開示は、プロセッサにオーディオパケットを発生させ、無線チャンネルのスループットを予測させ、該予測されたスループットに基づいて決定されたビデオパケットサイズでビデオパケットを発生させる命令を含んでなる、コンピュータ読み取り可能な媒体を提供する。

幾つかの実施形態において、ビデオパケットのサイズは、予測されたスループット、オーディオパケットのサイズ、および出力待ち行列の中にビデオパケットを配置する以前に該出力待ち行列の中にバッファーされたオーディオパケットを含むデータのサイズに基づいて決定される。該ビデオパケットは、オーディオパケットが、前記出力待ち行列のコンテンツから発生された次の利用可能なＭＡＣ層パケットの中に配置できるようにサイズ設定されてよい。

１以上の実施形態の詳細を、添付の図面および以下の説明において記載する。他の特徴、目的および利点は、該説明および図面、並びに特許請求の範囲から明らかであろう。

詳細な説明

図１は、ビデオのコード化およびデコード化システム１０を示すブロック図である。図１に示すように、システム１０は、送信チャンネル１６で接続されたエンコーダシステム１２およびデコーダシステム１４を含んでいる。エンコーダシステム１２は、第一のビデオ通信装置に関連しており、ビデオエンコーダ２０、オーディオエンコーダ２２、ビデオパケタイザ２４、リアルタイム移送プロトコル（ＲＴＰ）／ユーザデータグラムプロトコル（ＵＤＰ）／インターネットプロトコル（ＩＰ）／ポイントツーポイントプロトコル（ＰＰＰ）変換モジュール２６、無線リンクプロトコル（ＲＬＰ)待ち行列２８、ＭＡＣ層モジュール３０、およびＰＨＹ層モジュール３２を含んでいる。デコーダシステム１４は、もう一つのビデオ通信装置に関連しており、ＰＨＹ層モジュール３４、ＭＡＣ層モジュール３６、ＲＬＰ待ち行列３８、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール４０、ビデオデコーダ４２およびオーディオデコーダ４４を含んでいる。説明するように、パケタイザ２４は、オーディオパケット送信を優先させるようにチャンネル条件に基づいてビデオパケット整形を実行し、それによって過大なオーディオ遅延を回避する。

システム１０は、例えば、送信チャンネル１６を介したテレビ電話のための、二方向のビデオ送信およびオーディオ送信を提供してよい。従って、一般には逆コード化モジュール、デコード化モジュールおよび変換モジュールが、チャンネル１６の反対端に設けられてよい。幾つかの実施形態において、エンコーダシステム１２およびデコーダシステム１４は、ビデオストリーミング、テレビ電話またはその両者のために装備された無線モバイル端末のような、ビデオ通信装置内に実現されてよい。該モバイル端末は、ＲＴＰ、ＵＤＰ、ＩＰ、またはＰＰＰのようなパケット交換標準に従ってＶＴをサポートしてよい。ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュールは、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰヘッダデータを、オーディオエンコーダ２２およびビデオパケタイザ２４から受信した適切なオーディオおよびビデオデータに加え、該データをＲＬＰ待ち行列２の中に配置する。ＲＴＰはＵＤＰの頂部を走る一方、ＵＤＰはＩＰの頂部を走り、またＩＰはＰＰＰの頂部を走る。ＭＡＣ層モジュール３０は、ＲＬＰ待ち行列２８のコンテンツからＭＡＣ・ＲＬＰパケットを発生する。ＰＨＹ層モジュール３０は、ＭＡＣ・ＲＬＰパケットをＰＨＹ層パケットに変換する。

デコード化システムのＰＨＹ層モジュール３４およびＭＡＣ層モジュール３６は、逆の方法で動作する。ＰＨＹ層モジュールは、チャンネル１６から受信されたＰＨＹ層パケットを、ＭＡＣ・ＲＬＰパケットに変換する。ＭＡＣ層モジュール３６は、ＭＡＣ・ＲＬＰパケットをＲＬＰ待ち行列３８の中に配置する。ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール４０は、ＲＬＰ待ち行列３８中のデータからヘッダ情報を剥ぎ取り、それぞれビデオデコーダ４２およびオーディオデコーダ４４に配信するために、ビデオおよびオーディオデータを再アセンブルする。

システム１０は、コード分割多重接続（ＣＤＭＡ）、周波数分割多重接続（ＦＤＭＡ）、時間分割多重接続（ＴＤＭＡ）、または直交周波数分割多重化（ＯＦＤＭ）のような１以上の無線通信技術、またはもう一つの適切な無線技術をサポートするように設計されてよい。上記の無線通信技術は、種々の無線アクセス技術の何れかに従って配信されてよい。例えば、ＣＤＭＡは、ｃｄｍａ２０００または広帯域ＣＤＭＡ（ＷＣＤＭＡ）標準に従って配信されてよい。ＴＤＭＡは、モバイル通信のためのグローバルシステム（ＧＳＭ）標準に従って配信されてよい。ユニバーサルモバイル遠隔通信システム（ＵＭＴＳ）標準は、ＧＳＭまたはＷＣＤＭＡ動作を許容する。典型的には、ＶＴアプリケーションについて、システム１０は、ｃｄｍａ２００・１ｘＥＶ−ＤＯリリース０のような高データレート（ＨＤＲ)技術をサポートするように設計されるであろう。

ビデオエンコーダ２０は、ＭＰＥＧ−４のようなビデオ圧縮法に従ってコード化されたビデオデータを発生する。国際遠隔通信連合（ＩＴＵ）Ｈ．２６３、ＩＴＵ・Ｈ．２６４またはＭＰＥＧ−２法のような、他のビデオ圧縮方法が使用されてもよい。オーディオエンコーダ２２は、ビデオデータに付随させるためのオーディオデータをコード化する。当該ビデオは、ビデオカメラのようなビデオ捕捉装置から、またはビデオアーカイブから得られたものでよい。当該オーディオデータは、適合性多重レート狭帯域（ＡＭＲ−ＮＢ）のようなオーディオ圧縮方法、または他の技術に従ってコード化されてよい。オーディオは、マイクロホンのようなオーディオ捕捉装置から、またはスピーチシンセサイザ装置から得てもよい。ＶＴアプリケーションについて、ビデオはＶＴ会議への参加者が見るのを可能にし、またオーディオは参加者の話し声を聞くのを可能にするであろう。

動作において、ＴＲＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６は、ビデオエンコーダ２０およびオーディオエンコーダ２２からビデオおよびオーディオデータパケットを得る。ＴＲＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６は、適切なヘッダ情報をオーディオパケットに加え、この得られたデータをＲＬＰ待ち行列２８内に挿入する。同様に、ＴＲＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６は、適切なヘッダ情報をビデオパケットに加え、得られたデータをＲＬＰ待ち行列２８内に挿入する。ＭＡＣ層モジュール３０は、ＲＬＰ待ち行列２８からデータを検索し、ＭＡＣ層パケットを形成する。各ＭＡＣ層パケットは、ＴＲＰ／ＵＤＰ／ＩＰ／ＰＰＰヘッダ情報、並びにＲＬＰ待ち行列２８内に含まれるオーディオまたはビデオパケットデータを担持する。

オーディオパケットは、ビデオパケットとは独立に、ＲＬＰ待ち行列２８の中に挿入される。しかし、パケタイザ２４は、各オーディオパケットが次の利用可能なＭＡＣ層パケットによって運ばれることができるように、ＲＬＰ待ち行列２８に加えられるビデオパケットのサイズを制御する。幾つかの場合に、ＲＬＰ待ち行列２８のコンテンツから発生されたＭＡＣ層パケットは、ヘッダ情報およびビデオパケットデータだけを担持するであろう。他の場合、ＭＡＣ層パケットは、ヘッダ情報およびオーディオパケットデータだけを担持するであろう。多くの場合、ＭＡＣ層パケットは、ＲＬＰ待ち行列２８のコンテンツに依存して、ヘッダ情報、並びにオーディオパケットデータおよびビデオパケットデータを担持するであろう。ＭＡＣ層パケットは、無線リンクプロトコル（ＲＬＰ）に従って構成されてよく、ＭＡＣ・ＲＬＰパケットと称されてよい。ＰＨＹ層モジュール３２は、チャンネル１６を横切る送信のために、ＭＡＣ・ＲＬＰオーディオ-ビデオパケットをＰＨＹ層パケットに変換することを含んでよい。

チャンネル１６は、ＰＨＹ層パケットをデコーダシステム１４へと搬送する。チャンネル１６は、エンコーダシステム１２とデコーダシステム１４の間の如何なる物理的接続であってもよい。例えば、チャンネル１６は、ローカルエリアもしくは広域エリア有線ネットワークのような有線接続であってよい。或いは、ここで記載するように、チャンネル１６はセルラー接続、衛星接続または光接続のような無線接続であってよい。チャンネル条件は、有線および無線チャンネルについての問題であり得るが、無線チャンネル１６上で行われるモバイルＶＴアプリケーションについて特に問題が多い。

この開示に従えば、ビデオパケタイザ２４は、オーディオの送信を優先させるために、ＴＲＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６に与えられる各ビデオパケットのサイズを制御する。特に、ビデオパケットは、各パケットが次の利用可能なＭＡＣ層パケットによって収容され得るようにサイズ設定される。ビデオパケットの制御されたサイズ設定は、チャンネル条件、大きなビデオパケット、またはそれらの両者により生じるオーディオ遅延を防止する。オーディオパケットが利用可能なとき、それは、ＭＡＣ層モジュール３０により発生された次に利用可能なＭＡＣ・ＲＬＰパケットに含めるために、ＲＬＰ待ち行列の中に配置される。該オーディオパケットは、ＭＡＣ・ＲＬＰパケット内にオーディオパケットの配置のためのスペースを許容するようにサイズ設定された、ビデオパケットと組み合わされてよい。

ビデオパケタイザ２４は、それがチャンネル条件に基づいてビデオパケットサイズを調節できる意味において、チャンネル適合性であるように構成される。このようにして、エンコーダシステム１２は、チャンネル条件が劣悪であるときのオーディオ遅延を回避するために、オーディオパケットの送信を優先させることができる。同時に、ビデオパケタイザ２４は、オーディオの優先が、パケット化されつつあるビデオパケットを生じさせないことを保証できる。換言すれば、ビデオパケタイザ２４は、ビデオパケットを、１以上のオーディオパケットを次の利用可能なＭＡＣ・ＲＰＬパケットに含めることを許容するように充分に小さく、しかし、ＭＡＣ・ＲＬＰ中の過大なスペースを無駄にするほど小さくはないようにサイズ設定する。結局、ビデオパケタイザ２４は、オーディオパケットの優先順位付けおよびビデオパケットの効率的送信の両者をサポートしてよい。

デコーダシステム１４のＰＨＹ層モジュール３４は、ＰＨＹ層パケットからＭＡＣ層パケットを同定し、該コンテンツをＭＡＣ・ＲＬＰパケットの中に再アセンブルする。ＭＡＣ層モジュール３６は、次いで、ＭＡＣ・ＲＬＰパケットのコンテンツを再アセンブルして、ＲＬＰ待ち行列３８内に挿入するためのビデオおよびオーディオパケットを提供する。ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰモジュール４０は、添付のヘッダ情報を剥ぎ取り、ビデオパケットをビデオデコーダ４２へ、またオーディオパケットをオーディオデコーダ４４へと提供する。ビデオデコーダ４２は、ビデオデータフレームをデコード化して、表示装置を駆動する際に使用するためのビデオデータのストリームを生じる。オーディオデコーダ４４は、オーディオデータをデコード化して、例えばオーディオスピーカを介してユーザに提示するためのオーディオ情報を生じる。

上記で述べたように、ビデオパケタイザ２４は、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６に提示されるビデオパケットのサイズを制御するために設けられる。ビデオパケタイザ２４は、ＭＡＣ・ＰＬＰパケットにおけるオーディオパケットの送信を優先させ、またビデオパケットがＲＬＰ待ち行列２８を圧倒するのを防止するために、ビデオパケットのサイズを制御する。このようにして、ＶＴ会議のビデオ部分がチャンネル条件に起因して遅延を受け得るとしても、ＶＴ会議のオーディオ部分は、実質的な遅延を伴うことなく伝達されることができる。ビデオはチャンネル条件によって損なわれる可能性があるが、ビデオパケタイザ２４は、ＶＴ会議の参加者が言葉の会話を円滑に行うことができることを保証する。

ビデオパケタイザ２４により適用されるパケット整形技術は、オーディオパケットの優先送信を保証するために、１以上のルールを適用してよい。例えば、一つのルールに従えば、ＲＬＰ待ち行列２８のコンテンツから生じた丁度次の利用可能なＭＡＣ・ＲＬＰパケットにおいて送られるべきである。オーディオフレームは、第一の周期的間隔でオーディオデコーダ２２によって発生される。ＭＡＣ・ＲＬＰパケットは、第二の周期的間隔でＭＡＣ層モジュールによって発生される。与えられた間隔で発生されたオーディオフレームは、ＭＡＣ層モジュール３０により発生された次の利用可能なＭＡＣ・ＲＬＰパケットの中に配置されるべきである。オプションとして、幾つかの実施形態においては、ＲＬＰ待ち行列２８の合計出力待ち行列サイズは、オーディオパケットサイズと共に、一つのＭＡＣ・ＲＬＰパケットにおいて運ぶことができるべきである。

ＶＴシーケンスの全てのパケットに関して種々のルールが適用されてよい。幾つかのビデオパケットは、本来的にオーディオおよびビデオが単一のＭＡＣ・ＲＬＰパケット中で運ばれることができることを保証するようなサイズであってよいが、他のビデオパケットはより大きくてよく、特にチャンネル条件が低下するときには、オーディオおよびビデオが一つのＭＡＣ・ＲＬＰパケット中で運ばれることができるのを保証するためにサイズの縮小を必要とするかもしれない。ＶＴシーケンスの全てのパケットに関して該技術を適用することにより、ビデオのコンテンツが膨大であったり、またはチャンネル帯域幅が実質的に制限されるときでも、充分なスピーチコミュニケーションを保証することができる。

ＲＬＰ待ち行列２８中への挿入のために、パケタイザ２４によってＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６に提示される各ビデオパケットのサイズは制御される。上記のルールは、拡張的なビデオコンテンツによる連続するＭＡＣ・ＲＬＰパケットの消費によって、オーディオパケットが遅延されないことを保証する。オーディオが利用可能であるときは代りに、ビデオエンコーダ２０からのビデオは、各ＭＡＣ・ＲＬＰパケットがオーディオおよびビデオを運ぶのを可能にするように選択されたサイズで、パケットに分割される。各オーディオフレームは、ＲＬＰ待ち行列２８に提供されるオーディオパケットとして使用されてよい。或いは、幾つかの実施形態においては、オーディオパケットは連続する間隔で提供される複数のオーディオフレームを束ねてもよい。

ビデオパケタイザ２４は、幾つかの実施形態においては、連続的なオーディオフレームの間で発生されたＭＡＣ層パケットの推定チャンネルスループットに基づいて、各ＭＡＣ層パケットのためのビデオパケットサイズを決定してよい。このスループットは、現在の無線チャンネル送信レート、無線ベースステーションの活動、および送信電力制限の１以上によって表されるような、チャンネル条件に基づいて推定されてよい。例えば、チャンネル条件は現在のＭＡＣ層データレート、逆活動（reverse activity；ＲＡ）ビット、および電力増幅器（ＰＡ）限界に基づいて決定されてよい。加えて、幾つかの実施形態において、ビデオエンコーダ２０は更に、ビデオバッファー占有率に基づく適合性ソースレート制御を含んでよい。この場合、優先されたオーディオパケット化の必要性を仮定すれば、前記チャンネル条件が当該ビデオコード化レートをサポートしないなら、ソースビデオコード化レートはビデオエンコーダ２０によって低減されてよい。

図２は、過大なビデオコンテンツ、または劣悪なチャンネル条件に起因したオーディオ遅延を示す図である。図２に示すように、オーディオエンコーダ２２はオーディオフレーム４６Ａ、４６Ｂ、４６Ｃ（纏めてフレーム４６という）を発生し、またビデオエンコーダ２０はビデオフレーム４８Ａ、４８Ｂ、４８Ｃ（纏めてフレーム４８という）を発生する。一連の連続的なＭＡＣ・ＲＬＰパケット５０Ａ〜５０Ｆ（纏めてＭＡＣ・ＲＬＰパケット５０という）は、フレーム４６および４８から誘導されたオーディオパケットおよびビデオパケット（これらはＲＬＰ待ち行列２８の中にバッファーされる）を搬送するために利用可能である。オーディオエンコーダ２２による第一のオーディオフレーム４６Ａの発生に続いて、ＭＡＣ層モジュール３０によって発生された次の利用可能なＭＡＣ・ＲＬＰパケットは、パケット５０Ｂである。パケット５０Ｃもまた、必要であれば、第一のオーディオフレーム４６Ａを運ぶために使用することができる。しかし、ＲＬＰ待ち行列２８のコンテンツがビデオパケットによって圧倒されるならば、オーディオフレーム４６Ａは長時間に亘って配信されないかもしれない。

各ＭＡＣ・ＲＬＰパケット５０は、ＲＬチャンネル条件情報から誘導された関連のデータレートを有している。良好なＲＬ条件下において、各ＭＡＣ・ＲＬＰパケット５０は、７６．８キロビット／秒（Ｋｂｐｓ）のデータレートを有する。しかしながら、劣悪なＲＬチャンネル条件下ではデータレートは変動し、１９．２Ｋｂｐｓ、または３８．４Ｋｂｐｓと低いことが多い。過大なビデオコンテンツ、劣悪なチャンネル条件、またはその両者は、オーディオパケットの送信における顕著な遅延を生じる可能性がある。過大なビデオパケットサイズは、特に低いデータレートに起因してＲＬスループットが低下するときには、ＲＬを圧倒してオーディオ遅延を増大させる可能性がある。

ビデオパケットは、未制御のままであれば、過大な量のＭＡＣ・ＲＬＰパケットスペースを消費してオーディオパケットの連続的送信の間に遅延を生じる可能性がある。幾つかの場合に、ビデオは幾つかの連続するＭＡＣ・ＲＬＰパケット５０を消費して、オーディオが即座に送信されるのを妨げるかもしれない。各ＭＡＣ・ＲＬＰパケット５０は、オーディオおよびビデオパケット情報の組込みのために、概ね２６．６７ｍｓのスペースを提供する。図２の例において、大きなビデオフレーム４８Ａは、オーディオフレーム４６Ａと実質的に同じ時に発生される。このシナリオにおいて、連続的なビデオフレーム４８Ａ、４８Ｂは、時間的には相互に１１３ｍｓで発生される。しかし、オーディオフレーム４６Ｂ，４６Ｃは、時間的には相互に僅か６０ｍｓで発生される。

良好なＲＬ条件の下でさえも、オーディオフレーム４６Ａのため、並びにオーディオフレーム４６Ｂおよび４６Ｃのためのオーディオパケットを組込むために不充分なスペースが存在し得る。代りに、ビデオフレーム４８Ａに関連したビデオパケットは、ＭＡＣ・ＲＬＰパケット５０Ｂ〜５０Ｆの殆どを消費し、顕著なオーディオ遅延を生じる可能性がある。この問題は、図２に示した劣悪なＲＬＰ条件の場合に示されるように、チャンネル条件が劣化するときには特に困難な問題である。種々のチャンネル条件下においてオーディオ遅延を緩和するために、図１のシステム１０は、ビデオフレーム３６から誘導されたビデオパケットのサイズを制御するビデオパケタイザ２４を組込んでいる。ＶＴシーケンスの全パケットに関してビデオ制限を適用することにより、ビデオパケタイザ２４は、ＶＴシーケンスに関連したオーディオが損なわれないことを保証することができる。

図３は、固定長ビデオパケット整形のための技術を示す図である。固定長ビデオパケット整形は、オーディオ遅延の問題に対する部分的な解決策を提示する。しかし、固定長ビデオパケット整形はチャンネル条件を考慮しない。結局、ＲＬスループットが減少するときには、ビデオは未だチャンネルを圧倒することができる。加えて、固定長パケット整形は、二つの連続するオーディオパケットの間のスループットを考慮せず、ビデオデータの過大パケット化または過小パケット化を生じる。

図３の例においては、ビデオパケットのサイズは、６０ｍｓ毎に、ビデオフレームを固定サイズの３００バイトパケット５２Ａ、５２Ｂ、５２Ｃ（纏めてビデオパケット５２という）に断片化することによって制御される。オーディオフレームは、６０ｍｓ毎に、固定サイズの９３バイトパケット５４Ａ、５４Ｂ、５４Ｃ（纏めてオーディオパケット５４という）に断片化される。ビデオパケット５２は、ＭＡＣ・ＲＬＰパケット５６内のオーディオデータパケット５４の直後に送信される。正常な動作条件下では、固定長ビデオパケット化は、ＭＡＣ・ＲＬＰパケット５６内のオーディオパケット５４の適時の送信を容易にする。

図３に示されたアプローチは、オーディオパケットが、良好なＲＬ条件下で遅延なく送信されることを保証する。しかし、ＲＬ条件が劣化すれば、固定された３００バイトのビデオパケット５２はＲＬを圧倒して、連続するオーディオパケット５４の間に遅延を生じることができる。ビデオパケット５２の固定長に起因して、ＲＬ条件における変化に反応する能力は存在しない。幾つかの場合に、良好なＲＬ条件下において、ビデオデータは過小パケット化されて、各ＭＡＣ・ＲＬＰパケットにより与えられるスペースの過小利用、および一般的なバンド幅の非効率性を生じる可能性がある。劣悪なＲＬ条件下において、ビデオパケット５２の固定されたサイズは、ＲＬにとっては処理するのに大き過ぎて、オーディオ遅延を生じる可能性がある。この理由で、この開示は、全体のＶＴシーケンスのためのオーディオ品質を維持するために、ビデオコンテンツまたは帯域幅に応答して適合可能なサイズを有する調節可能な長さのビデオパケットを提案する。

図４は、チャンネル適合性ビデオパケット整形のための技術を示す図である。図４の例においては、オーディオパケットが実質的な遅延を伴うことなく送信され得るように、ビデオパケットサイズはチャンネル条件に基づいて調節される。固定されたビデオパケットサイズの代りに、各ビデオパケットのサイズは、オーディオパケットのサイズおよびチャンネル条件に基づいてダイナミックに調節される。良好な条件下において、ビデオパケットサイズは増大し得るが、ビデオパケットがＲＬを圧倒してオーディオ遅延を導入するような点にまでは増大されない。劣悪なＲＬ条件下では、パケット化されて次の利用可能なＭＡＣ／ＲＬＰパケットの中に配置されるべきオーディオフレームのための余裕を提供するために、ビデオパケットはサイズが減少される。

図４に示すように、オーディオフレーム５８Ａ、５８Ｂ、５８Ｃ（纏めてオーディオフレーム５８という）が利用可能であるとき、ビデオフレーム６０Ａ、６０Ｂ、６０Ｃ（纏めてビデオフレーム６０という）は、それぞれのオーディオフレームが次の利用可能なＭＡＣ・ＲＬＰパケット６２Ａ、６２Ｂ、６２Ｃ（纏めてＭＡＣ・ＲＬＰパケット６２という）の中に配置され得るようにサイズ設定される。図４に矢印で示すように、各オーディオフレーム５８はパケット化され、次いで、ＭＡＣ層モジュール３０によって発生された次の利用可能なＭＡＣ・ＲＬＰパケットの中に含めるためにＲＬＰ待ち行列の中に配置され、オーディオパケットの送信の間の過大な遅延を排除する。参照番号６４Ａ、６４Ｂ、６４Ｃ（纏めて６４という）は、ビデオパケットデータと共に、それぞれのＭＡＣ・ＲＬＰパケット６２内に配置されたオーディオパケットを表す。参照番号６６Ａ〜６６Ｆ（纏めて６６という）は、オーディオパケットを伴ってまたは伴わずに、それぞれのＭＡＣ・ＲＬＰパケット６２内に配置されたビデオパケットを表す。図４に示すように、各ＭＡＣ・ＲＬＰパケットは、ＲＬＰ待ち行列２８のコンテンツに依存して、オーディオのみ、ビデオのみ、またはオーディオおよびビデオの両者を搬送してよい。しかし、各オーディオパケット間隔において、ビデオパケット６２は、次の利用可能なＭＡＣ・ＲＬＰパケット６２の中へのオーディオパケット６４の組込みを許容するようにサイズ設定される。

とりわけ、例えばチャンネル条件に起因して利用可能なＲＬレートが低下するに伴って、オーディオパケット５８のサイズは、ＭＡＣ・ＲＬＰパケット６２のサイズに対して相対的に増大する。換言すれば、ＲＬレートが低下するに伴って、ビデオパケットサイズが減少するので、各オーディオパケット５８はＭＡＣ・ＲＬＰパケット６２のより大きな部分を消費する。逆に、各ビデオパケット６０は、ＲＬレートが減少するに伴ってダイナミックに調節され、それがＭＡＣ・ＲＬＰパケット６２のより小さい部分を消費するようになっている。この方法において、ビデオパケット６９は、次の利用可能なＭＡＣ・ＲＬＰパケット６２内での各オーディオパケット５８の配置を許容するようにサイズ設定される。その結果は、オーディオ遅延を低減するように、オーディオに対してビデオよりも高い優先度が与えられることである。

図５は、本開示の一実施形態に従って、チャンネル適合性ビデオパケット整形技術を実施するためのビデオ／オーディオコード化システム１２を示すブロック図である。図５に示すように、コード化システム１２は、ビデオエンコーダ２０、オーディオエンコーダ２２、ビデオバッファー６８、オーディオバッファー７０、ペイロードサイズ推定器７２および帯域幅効率的なパケタイザ７４を含むビデオパケタイザ２４、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６、ＲＬＰ待ち行列２８、並びに逆トラヒックチャンネル（ＲＴＣ）ＭＡＣユニット７６を含んでいる。ＲＴＣ・ＭＡＣユニット７６は、ＲＬ上での送信を行う通信装置が従うべき手順を提供するために、ＲＴＣ・ＭＡＣプロトコル３１４を実施する。便宜上の理由で、ＭＡＣ層モジュール３０およびＰＨＹ層モジュール３２は図５には示されていない。説明するように、ペイロードサイズ推定器７２は、１以上の入力に基づいて、各ビデオパケットのサイズを制御する。この入力はチャンネル条件、ＲＬＰ待ち行列特性、およびオーディオパケットのサイズおよび状態に関連してよい。帯域幅効率的パケタイザ７４は、最小ビデオパケットサイズに服するペイロードサイズ推定器により特定された推定ペイロードサイズに基づいて、ビデオパケットを発生する。

ビデオバッファー６８は、ビデオエンコーダ２０から受信したビデオ情報をバッファーし、該ビデオ情報をビデオパケタイザ２４に伝達する。オーディオバッファー７０は、オーディオエンコーダ２２からオーディオフレーム情報を受信して、該情報をＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６へと伝達する。オーディオパケットおよびビデオパケットは、相互に独立してＲＬＰ待ち行列２９の中に挿入される：ビデオパケタイザ２４により作製されるビデオパケットのサイズは、ＭＡＣ層モジュール３０（図５には示さず）によって作製された次の利用可能なＭＡＣ・ＲＬＰパケットの中に、オーディオパケットのための充分なスペースが存在することを保証する。特に、ＲＬＰ待ち行列２８は、ビデオパケットで圧倒されず、該ＲＬＰ待ち行列の中のオーディオパケットが次のＭＡＣ・ＲＬＰパケットと共に送られ得ることを保証する。

図５の例において、ペイロードサイズ推定器７２は、オーディオパケットタイマー、オーディオ優先値ＭＡＣＰｒｅｄＮｕｍｂｅｒＰｌｕｓ、ＲＬＰ待ち行列サイズ、およびチャンネル情報を含む幾つかの入力を受信する。オーディオパケットタイマーは、オーディオ情報がオーディオバッファー７０において現在利用可能であるかどうかを示し、もしそうであれば、各オーディオフレームが配信されるタイミングを示す。オーディオフレームが２０ｍｓ毎の間隔で配信されるならば、該オーディオパケットタイマーは、オーディオフレームが利用可能であるときは２０ｍｓに設定されるであろう。幾つかの実施形態において、オーディオバッファー７０は、単一のＩＰパケットの中への組み込みのために、連続するオーディオフレームを束ねるように構成されてよい。この場合、オーディオパケットタイマーは、前記オーディオパケットに束ねられたフレームの数に対応して、複数であってよい。換言すれば、該オーディオパケットタイマーは、束ねられたフレームの数に比例または関連する値を有してよい。例えば、三つのオーディオフレームが束ねられるとすれば、オーディオタイマーは６０ｍｓに設定されてよい。従って、オーディオパケットタイマーはまた、ＲＴＰ／ＵＤ／ＩＰ／ＰＰＰモジュール２６を介してＲＬＰ待ち行列２８の中に挿入するために、オーディオバッファー７０によって発生されるオーディオパケットのサイズを指示する。

オーディオ優先値ＭＡＣＰｒｅｄＮｕｍｂｅｒＰｌｕｓは、オーディオおよびビデオの相対的な優先度を定義し、従ってオーディオおよびビデオに伴う遅延に影響する。例えば、ＭＡＣＰｒｅｄＮｕｍｂｅｒＰｌｕｓは、優先値が小さいほどオーディオ遅延が低いように設定される。従って、ＭＡＣＰｒｅｄＮｕｍｂｅｒＰｌｕｓが増大するに伴って、オーディオ遅延は増大し、ビデオ遅延は減少する。逆に、ＭＡＣＰｒｅｄＮｕｍｂｅｒＰｌｕｓが減少するに伴って、オーディオ遅延は減少し、ビデオ遅延は増大する。従って、オーディオ遅延は、オーディオ優先値ＭＡＣＰｒｅｄＮｕｍｂｅｒＰｌｕｓに追随する。ペイロードサイズ推定器７２は、ＭＡＣＰｒｅｄＮｕｍｂｅｒＰｌｕｓを使用して各ビデオパケットのサイズを制御し、以下で更に詳述するように、記載されたオーディオパケット遅延をもたらす。

ペイロードサイズ推定器７２により受信されたＲＬＰ待ち行列サイズは、ＲＬＰ待ち行列２８の中にバッファーされている現在のデータのサイズを表す。ペイロードサイズ推定器７２は、該ＲＬＰ待ち行列サイズを使用してビデオパケットのサイズを制御する。もし、ＲＬＰ待ち行列２８が比較的満杯であれば、ペイロードサイズ推定器７２は、ビデオパケットのサイズを低い方に調節して、ＲＬが圧倒されて過大なオーディオ遅延を生じるのを回避する。ＲＬＰ待ち行列２８の満杯度が低ければ、ペイロードサイズ推定器７２は、未だオーディオパケットのための充分なスペースを提供しながら、ビデオパケットのサイズを増大することができる。ＲＬＰ待ち行列サイズを用いれば、ペイロードサイズ推定器７２は、ＲＬＰ待ち行列２８の満杯度の関数として、ビデオパケットサイズをダイナミックに調節することができる。待ち行列の満杯度は、過大なビデオコンテンツ、チャンネル条件の劣化、またはそれらの両方を示してよい。ＲＬＰ待ち行列サイズの使用は、ペイロードサイズ推定器７２が、ビデオコンテンツの過剰ロードまたはチャンネル条件の変化に反応できる方法の一つである。

ペイロードサイズ推定器７２はまた、ＲＴＣ・ＭＡＣユニット７６によって提供されるチャンネル情報をモニターすることにより、より直接的にチャンネル条件の変化に反応してもよい。ＲＴＣ・ＭＡＣユニット７６は、現在のＭＡＣ・ＲＬレート、組合されたＲＡビット、およびヘッドルーム制限のようなチャンネル特性に関連する情報を発生させる。ＭＡＣ・ＲＬレートは、ＲＬ上で利用可能な現在の送信レートを指示する。ＲＡビットは、関連の無線ベースステーションがビジーであるかどうかを指示する逆使用率ビットである。ヘッドルーム制限は、現在の送信電力に基づいて、送信において使用が許容される最大レートを示してよい。ＲＡビットは、ベースステーションの不活動のためにＲＬが混雑しているか、または利用可能でないときを指示する。ＰＡ限界は、送信電力ヘッドルームを表し、またチャンネル条件が劣化したときを指示する。

種々の入力に基づいて、ペイロードサイズ推定器７２は、ペイロードサイズ推定値を発生させる。ＭＡＣＰｒｅｄＮｕｍＰｌｕｓ優先度の値が、オーディオは高い優先度を与えられることを特定するならば、該ペイロードサイズ推定値は、オーディオパケットが次の利用可能なＭＡＣ・ＲＬＰパケットの中に含められるように選択される。帯域幅効率的なパケタイザ７４は、ビデオバッファー６８からビデオを受信し、ペイロードサイズ推定器７２によって特定されたペイロードサイズ推定値および最小ビデオパケットサイズに基づいて、ビデオをパケット化する。最小ビデオパケットサイズは、パケタイザ２４によって発生されるビデオパケットの最小サイズを表す。実際に、最小ビデオパケットサイズは、ビデオパケットサイズの細分性および帯域幅効率を制御する。より小さい最小ビデオパケットサイズ値の場合、ビデオパケット整形は、オーディオを適応させることによりオーディオ遅延を回避することに関してより効果的であるが、帯域幅効率は低い。より大きな最小ビデオパケットサイズ値の場合、ビデオパケット整形はオーディオ遅延を回避することにおいて効率的ではないが、より大きな帯域幅効率を提供する。

図５に更に示すように、ビデオエンコーダ２０は、ビデオバッファー６８からのビデオバッファー占有値に応答するように構成されてよい。特に、幾つかの実施形態において、ビデオエンコーダ２０は、ビデオバッファー占有率に基づいて、適合性ソースレート制御特徴を提供する。ビデオバッファー６８が比較的満杯であるとき、ビデオエンコーダ２０は、ビデオコード化レートを低下させることによって応答する。ビデオバッファー６８の満杯度が低いとき、ビデオエンコーダ２０は、ソースビデオコード化レートを増大させる。このようにして、チャンネル条件が現在のビデオコード化レートをサポートできないならばビデオコード化レートは低下される。この適合性ソースレート制御特徴は任意であるが、幾つかの応用においては望ましいものである可能性がある。

例示の目的で、追加の実施上の詳細を説明する。斯かる詳細は例示的と看做されるべきであり、この開示に広く具体化され且つ記載された技術を制限するものではない。ｃｄｍａ２０００１ｘＥＶ−ＤＯＲｅｌ．０の実施のために、ＲＬスループットはチャンネル条件に基づいて推定することができる。３ＧＰＰ２の明細Ｃ．Ｓ００２４−Ａ（ＴＩＡＩＳ−８５６−Ａとも称する）は、第１１頁〜第１４３頁、表１１．９．６．１において、Ｋｂｐｓでの送信レートで表された異なるチャンネル条件を与えられたＭＡＣ・ＲＬＰパケットについて、バイトでの最小および最大ペイロードサイズを特定している。表１１．９．６．１を下記に再現する。

上記の表における各送信レベルが指標値で表されるならば、オーディオおよびビデオを含む各ＭＡＣ・ＲＬＰパケットの最大ペイロードサイズは次の通りである：
最大ペイロードサイズ＝２^{ｉｎｄｅｘ＋4}−３
上記表現については、指標値１、２、３、４および５が、それぞれ、９．６、１９．２、３８．４、７６．８および１５３．６Ｋｂｐｓの送信レートレベルに割り当てられる。

図６は、チャンネル条件の範囲に亘るチャンネル適応性ビデオパケット整形を示す図である。図６に示すように、オーディオフレーム５８Ａ、５８Ｂ、５８Ｃ（纏めてオーディオフレーム５８という）、ＭＡＣ・ＲＬＰパケット６２Ａ〜６２Ｆ（纏めてＭＡＣ・ＲＬＰパケット６２という）は、各々、関連のＲＬ送信レートを有し、またそれらの送信レートに対応して、異なる最大ペイロードサイズを搬送することができる。例えば、ＭＡＣ・ＲＬＰパケット６２Ａ、６２Ｃおよび６２Ｄは３８．４ＫｂｐｓのＲＬ送信レートを有し、各々が１２５バイトの最大ペイロードサイズを搬送することができる。ＭＡＣ・ＲＬＰパケット６２Ｂは、７６．８ＫｂｐｓのＲＬ送信レートを有し、２５３バイトの最大ペイロードサイズを搬送することができる。ＭＡＣ・ＲＬＰパケット６２Ｅおよび６２Ｆは１９．２ＫｂｐｓのＲＬ送信レートを有し、各々が６１バイトの最大ペイロードサイズを搬送することができる。

一つの例示的実施形態において、ペイロードサイズ推定器７２の動作は、シュードコードにおけるアルゴリズムとして表現することができる。該アルゴリズムは以下の入力に依存する：即ち、ＲＡ・Ｂｉｔ、ＰＡ限界、ＲＬレート、ＲＬＰＱｕｅｕｅＳｉｚｅ、ＡｕｄｉｏＰａｃｋｅｔＳｉｚｅ、およびＭＡＣＰｒｅｄＮｕｍｂｅｒＰｌｕｓである。これらの入力は図５にも示されている。ＡｕｄｉｏＰａｃｋｅｔＳｉｚｅは、ペイロードサイズ推定器７２に適用されるオーディオパケットタイマーから誘導されてよい。先に述べたように、組合されたＲＡビットは、ベースステーション活動の状態を示す逆活動ビットであり、ＰＡ限界は、電力要件によって課される送信電力ヘッドルーム制限を表し、チャンネル条件が劣化したときには、ＲＬレートがＲＬの送信レートであり、ＲＬＰＱｕｅｕｅＳｉｚｅはＲＬＰ待ち行列２８の満杯度を示し、ＡｕｄｉｏＰａｃｋｅｔＳｉｚｅは現在のオーディオパケット、即ち、次の利用可能なＭＡＣ・ＲＬＰパケットに加えられるべきオーディオパケットを示す。ＭＡＣＰｒｅｄＮｕｍｂｅｒＰｌｕｓは、オーディオパケット vs.ビデオパケットに与えられるべき相対的優先度を示す。該アルゴリズムの出力は、ＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅである。

該アルゴリズムの初期化のために、ＭＡＣＰｒｅｄＮｕｍｂｅｒは次のように設定される：
ＭＡＣＰｒｅｄＮｕｍｂｅｒ
＝ｆｌｏｏｒ（（ＡｕｄｉｏＦｒａｍｅｓＢｕｎｄｌｅｄ＊ＡｕｄｉｏＦｒａｍｅＩｎｔｅｒｖａｌ）／２６．６７）＋１＋ＭＡＣＰｒｅｄＮｕｍｂｅｒＰｌｕｓ
ＭａｃＰｒｅｄＮｕｍｂｅｒは、単一のオーディオフレームまたは束ねられたオーディオフレームの組を含むパケットを運ぶために必要な、ＭＡＣ・ＲＬＰパケットの数を表す。ＡｕｄｉｏＦｒａｍｅＩｎｔｅｒｖａｌは、オーディオフレームの間の時間間隔を表す。値２６．６７は、各ＭＡＣ・ＲＬＰパケットのために配分された時間である。従って、もし三つのオーディオフレームが束ねられ、該オーディオフレーム間隔が２０ｍｓであれば、ＭＡＣＰｒｅｄＮｕｍｂｅｒＰｌｕｓはゼロであり、高いオーディオ優先度を示し、従ってＭＡＣＰｒｅｄＮｕｍｂｅｒは３である。これは、それについてビデオペイロードサイズが予測されるであろうＭＡＣ・ＲＰＬパケットの予測された数が３であることを意味する。

全ての束ねられたオーディオパケットについて、束ねられたオーディオパケットを送信した後に、ペイロードサイズ推定器７２は、ＭＡＣオーディオスループット決定を行う。ＭＡＣスループット決定は、以下の擬似コードにより指示されるように進行してよい：
MACThroughput = 0;
MACRateIncrease = 1 - RABit;
MACPredRate = CurRate;
for (i = 0; i < MACPredNumber; i++)
{
MACPredRate = MIN(MIN(MACPredRate + MACRateIncrease, 4),
PALimit);
MACThroughput += (2^{MACPredRate+4}-3);
}
上記ＭＡＣスループット決定において、ＭＡＣＴｈｒｏｕｇｈｐｕｔは、オーディオ送信のために必要とされるスループットであり、Ｍａｃｒａｔｅｉｎｃｒｅａｓｅは、ＭＡＣ・ＲＬレートが逆活動に基づいて増大されるかどうかを示し、ＣｕｒＲａｔｅは現在のＭＡＣ・ＲＬレートであり、ＭＡＣＰｒｅｄＲａｔｅは、指標値として表されたＭＡＣ・ＲＬレートにおける増加の量である。上記で示したように、ＭＡＣＴｈｒｏｕｇｈｐｕｔは、三つの予測されたＭＡＣ・ＲＬＰパケットの各々のために利用可能な最大ペイロードサイズである。

各ＭＡＣ・ＲＬＰパケットについて、最大ペイロードサイズＭＡＣＴｈｒｏｕｇｈｐｕｔが与えられると、ビデオペイロードサイズ推定器７２は、最大ビデオペイロードサイズ（ＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅ）を次のようにして予測する：
VideoPayloadSize = MAX(MACThroughput - RLPQueueSize, 0)
VideoPayloadSize = MAX(VideoPayloadSize - 2*AudioPacketSize - 45, 0),
ここで、ＲＬＰＱｕｅｕｅＳｉｚｅは、ＲＬＰ待ち行列２８の満杯度を示し、またＡｕｄｉｏＰａｃｋｅｔＳｉｚｅは、次のＭＡＣ・ＲＬＰパケットに加えられるべきオーディオパケットのサイズを表す。値４５は、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６によって導入されたヘッダ情報の、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰオーバーヘッドを説明するバイトにおける固定された数である。この固定されたオーバーヘッド数の値は、他の実施においては異なることができる。

図７は、チャンネル条件の範囲に亘るチャンネル適合性ビデオパケット整形を詳細に示す図である。ペイロードサイズ推定器７２は、一部はＲＬ送信レートによって表される変化するチャンネル条件に適合されて、ＲＬＰ待ち行列２８のコンテンツからＭＡＣ層モジュール３０によって発生されるＭＡＣ・ＲＬＰパケットの中に組込むために提示されたビデオパケットペイロードのサイズを調節する。図７の例において、オーディオフレームは６０ｍｓの間隔で発生される。この場合、次の三つのＭＡＣ・ＲＬＰパケットにおける利用可能なペイロードサイズに関する決定は、６０ｍｓ毎に行われる。

図７に示した最初の決定ポイント７８において、現在のＭＡＣ・ＲＬレートは３８．４Ｋｂｐｓを表すように３にインデックスされ、ＲＡビットはゼロに設定され、ＰＡ限界は４に等しく、ＲＬＰ待ち行列はＸ１バイトを含む。この場合、上記式に従えば、次の三つのＭＡＣ・ＲＬＰパケットの各々のスループットは２５３バイトと推定される。従って、次の三つのＭＡＣ・ＲＬＰパケットに亘る全体のスループットは、２５３＋２５３＋２５３バイトから、既にＲＬＰ待ち行列２８に配置されたコンテンツＸ１をマイナスしたものである。従って、第一の決定ポイント５０におけるＭＡＣＴｈｒｏｕｇｈｐｕｔは、２５３＋２５３＋２５３−Ｘ１バイトである。

６０ｍｓ後の第二の決定ポイント８０において、現在のＲＬレートは再度３にインデックスされ、ＰＡ限界は４であるが、ＲＡビットは０ではなく１に設定される。この場合、ＲＡビットは、ベースステーションがビジーであり、次の三つのＭＡＣ・ＲＬＰパケットに亘る低下したスループットの予測をもたらす。特に、予測されたスループットＭＡＣＴｈｒｏｕｇｈｐｕｔは、１２５＋１２５＋１２５−Ｘ２バイトであり、ここでのＸ２は、第二の決定ポイント８０の時点におけるＲＬＰ待ち行列２８のコンテンツを表す。

第二の決定ポイント７８から６０ｍｓ後の第三の決定ポイント８２において、ＲＡビットは０であるが、ＲＬレートは２のインデックス値（１９．２Ｋｂｐｓ）に低下しており、ＰＡ限界は２のインデックス値に低下している。結局、次の三つのＭＡＣ・ＲＬＰパケットに亘る全体のスループットＭＡＣＴｈｒｏｕｇｈｐｕｔは、６１＋６１＋６１−Ｘ３バイトであり、ここでのＸ３は第三の決定ポイント８２の時点でのＲＬＰ待ち行列２８のコンテンツを表す。

ＭＡＣＴｈｒｏｕｇｈｐｕｔが低下すると、オーディオパケットの優先度の結果として、ビデオパケットのために利用可能なスペースもまた減少する。この場合、ペイロードサイズ推定器７２は、パケット化のためのビデオペイロードの推定サイズを減少させる。ＭＡＣＴｈｒｏｕｇｈｐｕｔが増大するとき、ペイロードサイズ推定器７２は、推定されたビデオペイロードサイズを増大することによって応答する。このようにして、ビデオパケタイザ２４は、オーディオパケットを優先させるだけでなく、帯域幅効率的なビデオパケット化を支援する。

図７の例において、決定は三つのＭＡＣ・ＲＬＰパケットについて一度に行われる。しかし、他の実施形態においては、より積極的な決定プロセスが適用されてよい。例えば、ＭＡＣＴｈｒｏｕｇｈｐｕｔの推定のための決定は、２０ｍｓ毎に行われてよい。最初の２０ｍｓ間隔においては、三つのＭＡＣ・ＲＬＰパケットについての決定が行われてよい。次いで、第二の２０ｍｓ間隔において、三つの連続的なＭＡＣ・ＲＬＰパケットの組における残りの二つのＭＡＣ・ＲＬＰパケットについての決定が行われてよい。最後に、次の２０ｍｓ間隔の間に、三つのパケット組における最後のＭＡＣ・ＲＬＰパケットについての決定が行われてよい。この場合、決定は、６０ｍｓ間隔のコースに亘って行われ、チャンネル条件またはＲＬＰ待ち行列の満杯度において生じた可能性のある何れかの変化について２０ｍｓ毎に更新される。６０ｍｓ後に、当該プロセスは次の６０ｍｓおよび次の三つのＭＡＣ・ＲＬＰパケットについて反復され、繰り返し続けられる。

ＭＡＣＴｈｒｏｕｇｈｐｕｔが推定されたら、与えられたビデオペイロードサイズ推定器７２が、上記で説明したように、与えられたＭＡＣＴｈｒｏｕｇｈｐｕｔ値を収容できるビデオペイロードサイズを推定する。次いで、帯域幅効率的パケタイザ７４は、この推定されたビデオペイロードサイズおよび最小ビデオパケットサイズ値を使用して、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６に提示するためのビデオパケットを発生する。次に、帯域幅効率的パケタイザ７４の動作を更に詳細に説明する。

一般に、ビデオパケット化は、もしＭＰＥＧ４ビデオコードかが使用されるならば、２０００年１１月付のコメントについてのネットワーク作業グループ要求（ＲＦＣ）３０１６に従うべきであり、或いは、もしＩＴＵＨ．２６３ビデオコード化が使用されるならば、１９９７年９月付けのＲＦＣ２１９０または１９９８年１０月付けのＲＦＣ２４２９に従うべきである。ＲＦＣ３０１６は、ＭＰＥＧ４ストリームについてのＲＴＰペイロードフォーマットを概説している。ＲＦＣ２４２９は、ＩＴＵＨ．２６３ストリームの１９９８年版についてのＲＴＰペイロードフォーマットを概説しており、またＲＦＣ２１９０は、ＩＴＵＨ．２６３ストリームの初版についてのＲＴＰペイロードフォーマットを概説しておいる。

ＲＦＣ３０１６は、ビデオパケットが、（ａ）ビデオオブジェクト平面（ＶＯＰ）ヘッダまたはビデオパケット（ＶＰ）ヘッダを用いて開始しなければならず（これらの何れかが存在するとき）、（ｂ）以前のルールが満たされれば１以上のＶＰヘッダを含むことができ、（ｃ）ＶＯＰおよびＶＰヘッダの何れも伴わないビデオデータのみをその中に含むことができ、また（ｄ）二つのビデオフレームに亘ってデータを含むことができないことを特定している。ＲＦＣ２１９０は、ビデオパケットが、（ａ）映像開始コード（ＰＳＣ）またはブロックの群（ＧＯＢ）を用いて開始しなければならず、（ｂ）ＧＯＢヘッダまたは完全なＧＯＢを持たなければならないことはなく、（ｃ）ＧＯＢバイト整列されねばならないことはないことを特定している。ＲＦＣ２４２９は、ビデオパケットが、（ａ）バイト整列されたＰＳＣ、ＧＯＢヘッダ、スライスヘッダ、およびスライスの末端（ＥＯＳ）マーカーを用いて開始することができ、また（ｂ）如何なる同期コードを用いても開始しないが、ビデオパケットの中央に同期コードを許容するフローオンパケットであることができる旨を特定している。

上記の要件が与えられれば、ビデオエンコーダ２０は、ビデオデータを、ＭＰＥＧ４についてはＶＯＳおよびＶＰ、或いはＨ．２６３についてはＰＳＣ、ＧＯＢ、およびＳＳＣの形態で、ビデオバッファー６８の中に挿入するように構成されてよい。ＭＰＥＧ４に従うエンコーダは、ＶＯＰまたはＶＰのユニットにおいてデータを発生する。Ｈ．２６３エンコーダは、ＰＳＣ、ＧＯＢまたはＳＳＣのユニットにおいてデータを発生し、ＧＯＢはバイト整列される。ＲＦＣ２１９０が使用されるときは、モードＡがデフォルトである。

例示的実施形態において、帯域幅効率的パケタイザ６０の動作は、以下の入力を使用するアルゴリズムとして表現することができる：即ち、ＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒ、ＥｓｔｉｍａｔｅｄＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅ、ｍｉｎＶＰＳｉｚｅである。ＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒは、ビデオバッファー６８におけるビデオのサイズを表す。ＥｓｔｉｍａｔｅｄＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅは、ペイロードサイズ推定器７２によって決定された推定ビデオペイロードサイズを表す。値ｍｉｎＶＰｓｉｚｅは、パケタイザ６０によって発生されるべき最小ビデオパケットサイズであり、細分性および帯域効率を制御するように働く。帯域効率的パケット化アルゴリズムの出力は、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６に提示するための１以上のビデオパケットである。一つの例示的実施形態において、帯域幅効率的パケタイザ７４の動作は、以下の擬似コードによって表される：

上記の擬似コードによって表されるように、帯域幅効率的パケタイザ７４は、ペイロードサイズ推定器７２によって与えられるＥｓｔｉｍａｔｅｄＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅおよびｍｉｎＶＰＳｉｚｅに基づいて、ビデオパケットを生じる。ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅは、ビデオパケットを発生している間の如何なる時点においても利用可能なペイロードの量を表す。最初に、ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅは、ビデオペイロードサイズ推定器７２によって与えられる全体のＥｓｔｉｍａｔｅｄＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅに等しい。ＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅは、パケットにおけるビデオペイロードの実際のサイズを表し、最初はゼロに設定される。ＶｉｄｅｏＰａｙｌｏａｄＤａｔａ［］は、ビデオバッファー６８におけるビデオデータ切片のアレイを同定する。

パケタイザ７４は、先ず、ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅがｍｉｎＶＰＳｉｚｅ／２よりも小さいかどうかを決定する。もしそうならば、ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅはゼロに設定される。或いは、ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅがｍｉｎＶＰＳｉｚｅよりも小さければ、ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅの値は、ｍｉｎＶＰＳｉｚｅに等しく設定される。次いで、ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅがゼロに等しく、またはＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒがゼロであれば、次の利用可能なＭＡＣ・ＲＬＰパケットの中にスペースが残っていないか、またはビデオバッファー６８の中にビデオが残っていないので、該プロセスはリセットされる。

ＶｉｄｅｏＩｎＢｕｆｆｅｒのサイズが、ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅプラスｍｉｎＶＰＳｉｚｅよりも大きいか、またはこれに等しければ、パケタイザ７４は次に、ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅがｍｉｎＶＰｓｉｚｅ／２よりも大きいかまたはこれに等しいかどうかを決定する。もしそうであれば、パケタイザ７４は、ＲＦＣ３０１６またはＲＦＣ２４２９が利用可能であるかどうかを決定する。ＲＦＣ３０１６またはＲＦＣ２４２９が何れも該当しなければ、パケタイザ７４は、ＲＦＣ２１９０が利用可能であるかどうか、即ち、ＩＴＵＨ．２６３の初版のためのＲＴＰペイロードフォーマットが当てはまるかどうかを決定する。

ＲＦＣ３０１６またはＲＦＣ２４２９が該当すれば、パケタイザ７４は、開始アドレスＶｉｄｅｏＰａｙｌｏａｄＤａｔａおよびオフセットＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅによって決定されるように、ビデオバッファー６８から、ＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒによって同定される入力バッファへとビデオをコピー（ｍｅｍｃｐｙ）する。最初に、ＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅはゼロに設定される。ビデオバッファー６８からコピーされたビデオの量は、ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅに等しく、これは最初にＥｓｔｉｍａｔｅｄＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅに設定される。次いで、パケタイザ７４は、ＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅを、ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅに等しくなるように調節する。次に、パケタイザ７４は、ビデオデータを入力バッファーから、ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅによって決定された量で、オフセットＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄサイズによって同定されたアドレスへとコピーする。ＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒのコンテンツは、次いでパケット化のために断片化される。

ＲＦＣ２１９０が当てはまるならば、パケタイザ７４は、出発アドレスＶｉｄｅｏＰａｙｌｏａｄＤａｔａおよびオフセットＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅによって決定されるように、ビデオバッファーからＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒによって同定される入力バッファーへとビデオをコピーする（ｍｅｍｃｐｙ）。ここでも、ＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅは最初にゼロに設定される。ビデオバッファー６８からコピーされたビデオの量は、ＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒのサイズに等しい。次いで、ＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅは、ＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒのサイズに等しくされる。

ＲＦＣ３０１６／ＲＦＣ２４２９動作またはＲＦＣ２１９０動作の何れかを出るとき、パケタイザ７４は次いで、ＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅの現在の値に等しいペイロードサイズで、ＶｉｄｅｏＰａｙｌｏａｄＤａｔａからＶｉｄｅｏＰａｃｋｅｔを発生させる。次いで、ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅの値はゼロに設定される。この点において、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６に提示するために、ビデオパケットはパケタイザ７４によって既に発生されている。ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅがｍｉｎＶＰＳｉｚｅよりも小さくなく、ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅはゼロに等しくなく、ＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒはゼロであり、ＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒのサイズはＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅ＋ｍｉｎＶＰＳｉｚｅ以上でないならば、パケタイザ７４は、アドレスＶｉｄｅｏＰａｙｌｏａｄＤａｔａプラスＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅのオフセットを使用して、バッファー６８からＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒへとデータをコピーする。この場合、コピーされるデータの量はＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅに等しい。次いで、パケタイザ７４は、ＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅをＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒのサイズに等しく設定する。

パケタイザ７４は、次に、ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅを、ＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅマイナスＶｉｄｅｏＢｕｆｆｅｒＳｉｚｅの最大値、およびゼロに設定する。ＶｉｄｅｏＢｕｆｆｅｒＳｉｚｅは、ビデオバッファー６８のサイズを表す。ビデオバッファー６８の中にそれ以上データが存在しなければ、または現在の時刻（ＴＳ）が次のＴＳに等しくなければ、またはＲｅｍａｉｎｉｎｇＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅがゼロに等しければ、またはＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒが断片化されれば、パケット７４は、ＶｉｄｅｏＰａｙｌｏａｄＤａｔａから、ＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅのペイロードサイズを備えた一つのＶｉｄｅｏＰａｃｋｅｔを発生させ、またＶｉｄｅｏＰａｙｌｏａｄＳｉｚｅをゼロに設定する。或いは、ビデオバッファー中にデータが幾つか存在し、またはゼロでそれ以上のデータが存在しなければ、パケタイザ７４は、次のフレームＧＯＢ、またはビデオバッファー６８中のスライスユニットを取得するように、ＶｉｄｅｏＤａｔａＩｎＢｕｆｆｅｒを設定する。

図８は、本開示の一実施形態に従ったチャンネル適合性ビデオパケット整形のための技術を示すフロー図である。図８に示すように、オーディオバッファー７０はオーディオパケットを発生する（８４）。ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰモジュール２６は、オーディオパケットをＲＬＰ待ち行列２８に加える（８６）。ペイロードサイズ推定器７２は、ＲＬＰ待ち行列サイズを決定し（８８）、オーディオ／ビデオ優先値を決定し（９０）、またチャンネル条件を決定する（９２）。これらの決定に基づいて、ペイロードサイズ予測器７２は、発生されるべき次のビデオパケットのペイロードサイズを予測する（９４）。帯域幅効率的パケタイザ７４はビデオパケットを発生させ（９６）、また推定されたペイロードサイズおよび最小ビデオパケットサイズに基づいてビデオパケットのサイズを設定する（９８）。帯域幅効率的パケタイザ７４は、ビデオパケットをＲＬＰ待ち行列２８に加える（１００）。ＭＡＣ層モジュール３０は、ＲＬＰ待ち行列２８のコンテンツからＭＡＣ・ＲＬＰパケットを発生する（１０２）。

この開示に記載されるチャンネル適応性ビデオパケット整形は、より高いオーディオデータ優先度をサポートする。チャンネル適応性ビデオパケット整形がなければ、オーディオは、大きなビデオパケットによって屡々遅延される。この開示に記載されたパケット整形技術に従うビデオフレームの断片化は、次の利用可能なＭＡＣ・ＲＬＰパケット中で送信されるべきオーディオパケットのためのスペースを提供する。固定長さのビデオパケットサイズ設定は多くの場合にオーディオ遅延を低下させることができるが、このようなアプローチはチャンネル条件に適合せず、帯域幅消費に関して非効率的であり得る。チャンネル適合性ビデオパケット整形は、オーディオおよびビデオデータを優先付けするための融通性を提供する。オーディオ／ビデオ優先値（ＭＡＣＰｒｅｄＮｕｍｂｅｒＰｌｕｓ）および最小ビデオパケットサイズ（ｍｉｎＶＰＳｉｚｅ）は、オーディオ優先およびビデオ優先の間の望ましいトレードオフを達成するように特定することができる。

加えて、チャンネル適合性パケット整形は、ほぼ一定のオーディオ遅延特性を提供して、劣悪なチャンネル条件にもかかわらず円滑なオーディオ変換をもたらすことができる。幾つかの場合、オーディオ遅延特性はビデオを伴わない特性に匹敵し得るものである。ビデオスループットは、オーディオスループットおよびチャンネル条件に適合可能である。特に、ビデオスループットは、利用可能な帯域幅に従って適合的に変化されることができ、またビデオスループットは、オーディオスループットが減少するときに増加することができる。有利なことに、チャンネル適合性ビデオパケット整形は低い複雑さで実施され易く、幾つかの実施形態では、この開示に示されるように、僅かなラインのコードを必要とするに過ぎない。また、殆どの実施形態において、デコード化システム１４を改変する必要はない。

この開示に記載された技術は、一般的目的のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、アプリケーション特異的集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、または他の等価な論理装置内で実施されてよい。例えば、ビデオエンコーダシステム１２、並びにその部品およびモジュールは、デジタル信号プロセッサ（ＤＳＰ）または他の処理装置上で実行されるコード化プロセス、またはコード化／デコード化（ＣＯＤＥＣ）プロセスの一部として実施されてよい。従って、モジュールとして記載された部品は、斯かるプロセスまたは別のプロセスのプログラム可能な特徴を形成してもよい。ビデオエンコーダシステム１２は、命令およびデータを保存するための専用のメモリー、並びに専用のハードウエア、ソフトウエア、ファームウエア、またはそれらの組合せを有してよい。ソフトウエアにおいて実施されるときは、当該技術は、ランダムアクセスメモリー（ＲＡＭ）、リードオンリーメモリー（ＲＯＭ）、不揮発性ランダムアクセスメモリー（ＮＶＲＡＭ）、電気的に消去可能なプログラマブルリードオンリーメモリー（ＥＥＰＲＯＭ）、フラッシュメモリー等のような、コンピュータ読み取り可能な媒体上の命令として実現される。これらの命令は、１以上のプロセッサに対して、この開示に記載された機能の一定の側面を実行させる。

種々の実施形態を説明してきた。これら実施形態および他の実施形態は、特許請求の範囲内に含まれるものである。

図１は、ＶＴアプリケーションのためのビデオ／オーディオコード化およびデコード化システムを示すブロック図である。図２は、過大なビデオコンテンツ、劣悪なチャンネル状態、またはその両者によるオーディオ遅延を示す図である。図３は、固定長さのビデオパケット整形のための技術を示す図である。図４は、チャンネル適合ビデオパケット整形のための技術を示す図である。図５は、チャンネル適合ビデオパケット整形技術を実施する、ビデオ／オーディオコード化システムを示すブロック図である。図６は、チャンネル条件の範囲に亘るチャンネル適合ビデオパケット整形を示す図である。図７は、チャンネル条件の範囲に亘るチャンネル適合ビデオパケット整形をより詳細に示す図である。図８は、チャンネル適合ビデオパケット整形のための技術を示すフロー図である。

Claims

オーディオパケットを発生させることと；
無線チャンネルのスループットを推定することと；
該推定されたスループットに基づいて決定されたビデオパケットサイズを備えたビデオパケットを発生させることと
を含んでなる方法。
請求項１に記載の方法であって、前記ビデオパケットサイズは、前記推定されたスループットおよび前記オーディオパケットのサイズに基づいて決定される方法。
請求項１に記載の方法であって、更に、前記オーディオパケットおよび前記ビデオパケットを出力待ち行列の中に配置することを含んでなり、前記ビデオパケットサイズは前記推定されたスループット、前記オーディオパケットのサイズ、および前記ビデオパケットの前記出力待ち行列の中への配置に先立って前記出力待ち行列の中にバッファーされたデータのサイズに基づいて決定される方法。
請求項１に記載の方法であって、更に、前記オーディオパケットおよび前記ビデオパケットを出力待ち行列の中に配置することと、前記出力待ち行列のコンテンツの少なくとも幾つかに基づいて、媒体アクセス制御（ＭＡＣ）層パケットを発生させることを含んでなる方法。
請求項１に記載の方法であって、更に、第一の周期的間隔でオーディオフレームを受信することと、第二の周期的間隔で媒体アクセス制御（ＭＡＣ）層パケットを発生させることを含んでなり、オーディオパケットを発生させることは、前記オーディオフレームの各々のためのオーディオパケットを発生させること、および該オーディオパケットを次の利用可能なＭＡＣ層パケットに加えることを含む方法。
請求項１に記載の方法であって、更に、第一の周期的間隔でオーディオフレームを受信することと、第二の周期的間隔で媒体アクセス制御（ＭＡＣ）層パケットを発生させることを含んでなり、オーディオパケットを発生させることは、少なくとも二つの前記オーディオフレームを束ねるオーディオパケットを発生させること、および該オーディオパケットを次の利用可能なＭＡＣ層パケットに加えることを含む方法。
請求項１に記載の方法であって、更に、出力待ち行列にオーディオパケットおよびビデオパケットを配置することと、前記出力待ち行列のコンテンツの少なくとも幾つかに基づいて媒体アクセス制御（ＭＡＣ）層パケットを発生させることを含んでなり、前記ビデオパケットサイズは前記オーディオパケットのサイズ、前記予測されたスループット、および前記出力待ち行列の中への前記ビデオパケットの配置に先立って前記出力待ち行列の中にバッファーされたデータのサイズに基づいている方法。
請求項１に記載の方法であって、更に、１以上の現在の無線チャンネル送信レート、無線ベースステーションの活動、および相威信電力制限に基づいて前記スループットを予測することを含んでなる方法。
請求項１に記載の方法であって、前記ビデオパケットサイズは、前記無線チャンネル上での前記オーディオパケットの送信における実質的遅延を回避するために充分に小さい方法。
請求項１に記載の方法であって、更に、複数のビデオフレームを受信することと、パケット化されないビデオフレームデータの量に基づいてビデオコード化レートを調節することを含んでなる方法。
請求項１に記載の方法であって、前記ビデオパケットサイズは、少なくとも一部は、ビデオパケットに対するオーディオパケットの優先性を付与する優先値に基づいて決定され、また与えられた予測スループットについての前記ビデオパケットサイズは、前記優先値が減少するに伴って増大する方法。
請求項１に記載の方法であって、前記ビデオパケットサイズは最小ビデオパケットサイズ以上である方法。
請求項１に記載の方法であって、更に、前記オーディオパケットおよび前記ビデオパケットに基づいて物理層パケットを発生させることと、モバイル無線テレビ電話会議をサポートするために該物理層パケットを遠隔装置に送信することを含んでなる方法。
請求項１２に記載の方法であって、前記物理層パケットは、実質的にｃｄｍａ２０００・１×ＥＶ−ＤＯリリース０標準に従う方法。
オーディオパケットを発生させるオーディオエンコーダと；
前記オーディオデータを受信してオーディオパケットを出力するオーディオバッファーと；
ビデオデータを発生するビデオエンコーダと；
無線チャンネルのスループットを推定し、該推定されたスループットに基づいて決定されたビデオパケットサイズを備えた前記前記ビデオデータから、ビデオパケットを発生するパケタイザと
を含んでなるシステム。
請求項１４に記載のシステムであって、前記ビデオパケットサイズは、前記推定スループットおよび前記オーディオパケットのサイズに基づいて決定されるシステム。
請求項１４に記載のシステムであって、更に、オーディオパケットおよびビデオパケットを受信する出力待ち行列を具備し、前記ビデオパケットサイズは、前記推定スループット、オーディオパケットのサイズ、および前記ビデオパケットの前記出力待ち行列の中への配置に先立って前記出力待ち行列内にバッファーされたデータのサイズに基づいて決定されるシステム。
請求項１４に記載のシステムであって、更に、オーディオパケットおよびビデオパケットを受信する出力待ち行列と、前記出力待ち行列のコンテンツの少なくとも幾つかに基づいてＭＡＣ層パケットを発生する媒体アクセス制御（ＭＡＣ）層モジュールを具備するシステム。
請求項１４に記載のシステムであって、前記オーディオバッファは、第一の周期的間隔でオーディオフレームを受信し、該オーディオフレームの各々についてオーディオパケットを発生し、また前記ＭＡＣ層モジュールは、第二の周期的間隔で媒体アクセス制御（ＭＡＣ）層パケットを発生し、次の利用可能なＭＡＣ層パケットに前記オーディオパケットを加えるシステム。
請求項１４に記載のシステムであって、前記オーディオバッファーは、第一の周期的間隔でオーディオフレームを受信し、該オーディオフレームの少なくとも二つを束ねてオーディオパケットを形成し、前記ＭＡＣ層モジュールは、第二の周期的間隔で媒体アクセス制御（ＭＡＣ）層パケットを発生し、次の利用可能なＭＡＣ層パケットに前記オーディオパケットを加えるシステム。
請求項１４に記載のシステムであって、前記パケタイザは、１以上の現在の無線チャンネル送信レート、無線ベースステーション活動、および送信電力制限に基づいて、前記スループットを推定するシステム。
請求項１４に記載のシステムであって、前記ビデオパケットサイズは、前記無線チャンネル上での前記オーディオパケットの送信における実質的遅延を回避するために充分に小さいシステム。
請求項１４に記載のシステムであって、前記ビデオエンコーダは、複数のビデオフレームを発生し、またパケット化されていないビデオフレームデータの量に基づいてビデオコード化レートを調節するシステム。
請求項１４に記載のシステムであって、前記パケタイザは、少なくとも一部は、前記ビデオパケットに対する前記オーディオパケットへの優先性を与える優先値に基づいてビデオパケットサイズを決定し、与えられた推定スループットについての前記ビデオパケットサイズは前記優先値が減少するに伴って増大するシステム。
請求項１４に記載のシステムであって、前記ビデオパケットサイズが最小ビデオパケットサイズ以上であるシステム。
請求項１に記載のシステムであって、更に、前記オーディオパケットおよびビデオパケットに基づいて物理層パケットを発生し、モバイル無線テレビ電話会議をサポートするために、該物理層パケットを遠隔装置へと送信する物理層モジュールを含んでなる装置。
請求項２５に記載のシステムであって、前記物理層パケットが、実質的にｃｄｍａ２０００・１×ＥＶ−ＤＯリリース０標準に従うシステム。
コンピュータ読み取り可能な媒体であって、プロセッサに対して、
オーディオパケットを発生させ；
無線チャンネルのスループットを推定させ；また
該推定されたスループットに基づいて決定されたビデオパケットサイズを備えたビデオパケットを発生させる
ための命令を含んでなる媒体。
請求項２７に記載のコンピュータ読み取り可能な媒体であって、更に、前記予測されたスリープットおよび前記オーディオパケットのサイズに基づいて、プロセッサにビデオパケットサイズを決定させるための命令を含んでなる媒体。
請求項２７に記載のコンピュータ読み取り可能な媒体であって、更に、前記予測されたスループットおよび前記オーディオパケットのサイズに基づいて、プロセッサに対し、前記オーディオパケットおよび前記ビデオパケットを出力待ち行列の中に配置させるための命令を含んでなり、前記ビデオパケットサイズは前記推定スループット、前記オーディオパケットのサイズ、および前記出力待ち行列における前記ビデオパケットの配置に先立って前記出力待ち行列中にバッファーされたデータのサイズに基づいて決定される媒体。
請求項２７に記載のコンピュータ読み取り可能な媒体であって、更に、プロセッサに対して、前記オーディオパケットおよびビデオパケットを出力待ち行列の中に配置させ、且つ前記出力待ち行列のコンテンツの少なくとも幾つかに基づいて媒体アクセス制御（ＭＡＣ）層パケットを発生させるための命令を含んでなる媒体。
請求項２７に記載のコンピュータ読み取り可能な媒体であって、更に、プロセッサに対して、第一の周期的間隔でオーディオフレームを受信させ、且つ第二の周期的間隔で媒体アクセス制御（ＭＡＣ）層パケットを発生させるための命令を含んでなり、オーディオパケットの発生が、前記オーディオフレームの各々のためのオーディオパケットの発生を含んでおり、また該オーディオパケットを次の利用可能なＭＡＣ層パケットに追加する媒体。
請求項２７に記載のコンピュータ読み取り可能な媒体であって、更に、プロセッサに対して第一の周期的間隔でオーディオフレームを受信させ、且つ第二の周期的間隔で媒体アクセス制御（ＭＡＣ）層パケットを発生させるための命令を含んでなり、オーディオパケットの発生は少なくとも二つのオーディオフレームを束ねるオーディオパケットの発生を含み、また該オーディオパケットを次の利用可能なＭＡＣ層パケットに追加する媒体。
請求項２７に記載のコンピュータ読み取り可能な媒体であって、更に、プロセッサに対して、現在の無線チャンネル送信レート、無線ベースステーション活動、および送信電力ｋ制限の１以上に基づいてスループットを推定させるための命令を含んでなる媒体。
請求項２７に記載のコンピュータ読み取り可能な媒体であって、前記ビデオパケットサイズは、前記無線チャンネル上での前記オーディオパケットの送信における実質的な遅延を回避するために充分に小さい媒体。
請求項２７に記載のコンピュータ読み取り可能な媒体であって、更に、前記プロセッサに対して、複数のビデオフレームを受信させ、且つパケット化されないビデオフレームデータの量に基づいてビデオコード化レートを調節させるための命令を含んでなる媒体。
請求項２７に記載のコンピュータ読み取り可能な媒体であって、前記ビデオパケットサイズは、少なくとも一部は、前記オーディオパケットに対して前記ビデオパケットを凌駕する優先性を付与する優先値に基づいて決定され、与えられた推定スループットについての前記ビデオパケットサイズは、前記優先値が減少するに伴って増大する媒体。
請求項２７に記載のコンピュータ読み取り可能な媒体であって、前記ビデオパケットサイズが最小ビデオパケットサイズ以上である媒体。
請求項２７に記載のコンピュータ読み取り可能な媒体であって、更に、プロセッサに対して、前記オーディオパケットおよび前記ビデオパケットに基づいて物理層パケットを発生させ、且つモバイル無線テレビ電話会議をサポートする遠隔装置へと前記物理層パケットを送信させるための命令を含んでなる媒体。
請求項３８に記載のコンピュータ読み取り可能な媒体であって、前記物理層パケットが、ｃｄｍａ２０００・１×ＥＶ−ＤＯリリース０標準に従う媒体。
オーディオパケットを発生させるための手段と；
無線チャンネルのスループットを推定するための手段と；
該推定されたスループットに基づいて決定されたビデオパケットサイズを備えたビデオパケットを発生させるための手段と
を含んでなるシステム。
請求項４０に記載のシステムであって、前記ビデオパケットサイズが、前記推定されたスループットおよび前記オーディオパケットのサイズに基づいて決定されるシステム。
請求項４０に記載のシステムであって、更に、前記オーディオパケットおよび前記ビデオパケットを出力待ち行列の中に配置するための手段を含んでなり、前記ビデオパケットサイズは、前記推定されたスループット、前記オーディオパケットのサイズ、および前記出力待ち行列の中への前記ビデオパケットの配置するに先立って前記出力待ち行列中にバッファーされたデータのサイズに基づいて決定されるシステム。