JP2006217589A - ビデオ会議装置、装置、ビデオ会議システム、方法およびこの方法を実行するように適合された命令プログラムを含んだデバイス可読媒体または波形 - Google Patents

Abstract

【課題】トランスポートコントロールプロトコルを用いるマルチメディア通信チャンネルの適応型ビットレート調整。
【解決手段】対応する方法および命令プログラムを有するビデオ会議装置は、ビデオデータを生成するためのビデオコーデック、ビデオデータのTCPパケットを生成するためのビデオパケット生成装置、音声データを生成するための音声コーデック、音声データのパケットを生成するための音声パケット生成装置、TCPパケットを送信するための送信回路、レシーバで受信したビデオデータのTCPパケットの数を表すRTCPレシーバレポートを受信するための受信回路、および送信回路で送信したビデオデータのTCPパケット数とレシーバで受信したビデオデータのTCPパケット数との差異に基づいてすでに送信したがまだレシーバで受信していないビデオデータのTCPパケット数の推定値を生成し、その推定値に従ってビデオビットレートを制御するためのコントローラを含む。
【選択図】図２

Description

本発明は一般的にディジタルデータ送信のためのビットレート制御に関する。より具体的には、本発明はトランスポートコントロールプロトコル（TCP）を用いるマルチメディア通信チャンネルの適応型ビットレート調整に関する発明である。

インターネットビデオ会議などに用いられるマルチメディア通信チャネルは一般的に、ビデオデータパケットを通信するためにユーザデータグラムプロトコル（UDP）を利用する。UDPは、損失パケットの再送信をサポートしないので、リアルタイムデータ送信に適切である。リアルタイムマルチメディア通信チャネルの損失パケットの再送信に伴う遅延時間はレシーバで凍結したビデオや音声にカチッという音などの認識できる欠陥を発生させる。

しかし、UDPは非接続プロトコルだから、ネットワーク安全性の問題が生じる。多くの会社は企業のファイアウォールを通すUDP接続を許可しないのでUDPビデオ会議システムを使用できない。

米国特許出願公開第2004/0078478号明細書

しかし、もう一つトランスミッションコントロールプロトコル（TCP）というトランスポートプロトコルがある。しかしTCPは損失パケットを再送信するので、基本的にリアルタイムマルチメディア通信に適切ではない。TCPはさらに、通信チャンネルのビットレートを有効に変化させることによってネットワーク混雑制御も提供し、それにより混雑したネットワーク接続に接続しているすべてのチャンネルがネットワーク接続を共同使用できるように各々のチャンネルのビットレートを下げる。この混雑制御はマルチメディア通信に悪影響を及ぼす。例えば、もしビデオ会議アプリケーションがTCP混雑制御に許されるビットレートよりも高いビットレートで送信すれば、送信遅延が長くなる。ビットレートの差が１０％であれば、一時間のビデオ会議の終わりに遅延は６分となる。これは決してリアルタイムではない。

一般に、一つの態様において、本発明はビデオ会議装置を特徴とし、このビデオ会議装置は、あるビデオビットレートでビデオデータを生成するためのビデオコーデック、ビデオデータのトランスポートコントロールプロトコル（TCP）パケットを生成するためのビデオパケット生成装置、ある音声ビットレートで音声データを生成するための音声コーデック、音声データのパケットを生成するための音声パケット生成装置、ビデオデータのTCPパケットと音声データのパケットを送信するための送信回路、ビデオデータのTCPパケットを受信するレシーバで受信したビデオデータのTCPパケット数を表すリアルタイムトランスポートコントロールプロトコル（RTCP）のレシーバレポートを受信するための受信回路、および送信回路で送信したビデオデータのTCPパケット数とレシーバで受信したビデオデータのTCPパケット数との差異に基づいて送信回路ですでに送信したがまだレシーバで受信していないビデオデータのTCPパケット数の推定値を生成するため、そしてその推定値に従ってビデオビットレートを制御するためのコントローラを含む。

一般に、もう一つの態様において、本発明は装置およびそれに対応する方法とコンピュータプログラムを特徴とする。装置は、あるビットレートでデータを生成するためのデータ生成装置、そのデータのトランスポートコントロールプロトコル（TCP）パケットを生成するためのパケット生成装置、データのTCPパケットを送信するための送信回路、および送信回路ですでに送信したがまだデータのTCPパケットを受信するレシーバで受信していないデータのTCPパケット数の推定値に従ってビットレートを制御するためのコントローラを含む。

特定のインプリメンテーションは、次の特徴を一つ以上含むことができる。コントローラは、初期化イベントが起きた後に送信回路で送信したデータのTCPパケットの数と、初期化イベント後にレシーバで受信したデータのTCPパケットの数、および送信回路で送信したがレシーバでまだ受信していないデータのTCPパケットの数の前の推定値に基づいて、すでに送信回路で送信したがまだレシーバで受信していないデータのTCPパケットの数の推定値を生成する。コントローラは、送信回路ですでに送信したがまだレシーバで受信していないデータのTCPパケットの数の推定値を生成するために、初期化イベント後に送信回路で送信したデータのTCPパケットの数および初期化イベント後にレシーバで受信したデータのTCPパケットの数との間の複数の差異値をそれぞれ異なった時間で決定し、そして差異値の中央値（median）、差異値の平均値（mean）、および差異値のモードから構成されるグループのうちの少なくとも一つに従って推定値を生成する。コントローラは、すでに送信回路で送信したがまだレシーバで受信していないデータのTCPパケットの数の推定値に従ってビットレートを制御するために、初期化イベント後に送信回路で送信したデータのTCPパケットの数と初期化イベント後にレシーバで受信したデータのTCPパケットの数との間の連続差分の第１所定数がすでに送信回路で送信したがまだレシーバで受信していないデータのTCPパケットの数の推定値の第１関数であるしきい値を超えるとビットレートを下げ、初期化イベント後に送信回路で送信したデータのTCPパケットの数と初期化イベント後にレシーバで受信したデータのTCPパケットの数との間の連続差分の第２所定数がすでに送信回路で送信したがまだレシーバで受信していないデータのTCPパケットの数の推定値の第２関数であるしきい値よりも低くなるとビットレートを上げ、そしてビットレートが所定の時間間隔で上がっていないときにはビットレートを上げる。すでに送信回路で送信したがまだレシーバで受信していないデータのTCPパケットの数の推定値に従ってビットレートを制御するために、コントローラはさらにすでに送信回路で送信したがまだレシーバで受信していないデータのTCPパケットの数の新しい推定値を生成し、その新しい推定値が推定値を囲む推定枠（estimate window）外にあるかどうかを判定し、その新しい推定値が推定値を囲む推定枠外にあるときには新しい推定値に従ってビットレートを制御し、そしてその新しい推定値が推定値を囲む推定枠内にあるときには推定値に従ってビットレートを制御する。装置はさらにレシーバで受信したデータのTCPパケットの数を表すデータパケットを受信するための受信回路を含む。レシーバで受信したデータのTCPパケットの数を表すデータパケットはリアルタイムトランスポートコントロールプロトコル（RTCP）のレシーバレポートパケットを含む。データ生成装置は、ビデオデータを符号化するためのビデオコーデック、および音声データを符号化するための音声コーデックからなるグループの少なくとも一つを含む。ビデオ会議システムはこの装置を含む。

一つ以上の実施例の詳細を添付の図面および以下に説明する。その他の特徴は説明および図面ならびに請求項から明確になる。

以下、本発明の実施形態を図面に基づいて説明する。

本発明の実施例は、トランスポートコントロールプロトコル（TCP）を用いるマルチメディア通信チャネルの適応型ビットレート調整を提供する。この明細書で開示する技術は、ビデオ会議やボイスオーバIP電話技術などのようなリアルタイム双方向のアプリケーションに特に役に立つが、片方向通信チャネルにも、より緩いレイテンシ要件を有する通信チャネルにも等しく適用できる。

図１はインターネットのようなネットワーク１０２と通信しているビデオ会議システム１００を示す。しかし、本発明の実施例をネットワークビデオ会議に関して説明しているけれども、この明細書で開示する技術はネットワークまたは直接リンクで他の片方向および双方向通信アプリケーションにも等しく適用できる。

ビデオ会議システム１００は、例えばビデオ会議用カメラからのビデオ信号を提供するビデオソース１０４、ビデオ信号をビデオデータとして符号化するためのビデオコーデック１０６、およびビデオデータのTCPパケットを生成するためのビデオパケット生成装置１０８を含む。ビデオ会議システム１００はさらに、例えばマイクからの音声信号を提供する音声ソース１１０、音声信号を音声データとして符号化するための音声コーデック１１２、および音声データのTCPパケットを生成するための音声パケット生成装置１１４を含む。ビデオ会議システム１００はさらに、ビデオおよび音声TCPパケットを送信するイサネットポートのような一つ以上の送信回路１１６、ネットワーク１０２からデータおよびコントロールパケットを受信するための一つ以上の受信回路１１８、およびビデオ会議システム１００を制御するためのコントローラ１２０を含む。

図２は、本発明の好適な実施例によるビデオ会議システム１００のための適応型ビットレート制御プロセス２００を示す。プロセス２００をビデオデータビットレートを制御することに関して説明しているが、プロセス２００はオーディオデータビットレートまたはオディオおよびビデオソース、コーデックなどのようなデータ生成装置で生成するあらゆるディジタルデータのためのビットレートを制御することに等しく適用できる。コントローラ１２０はプロセス２００の２つのインスタンスを同時に実行するのが好ましい。プロセス２００の１つのインスタンスはビデオデータのビットレートを制御し、それと同時にもう１つのインスタンスはオーディオデータのビットレートを制御する。

ビデオ会議中、例えばビデオソオース１０４のようなソースは、例えばビデオ信号のようなデータ信号を生成する（ステップ２０２）。例えばビデオコーデック１０６のようなコーデックは、あるビデオビットレートでビデオデータを生成するためにビデオを符号化する（ステップ２０４）。例えばビデオパケット生成装置１０８のようなパケット生成装置はビデオデータのTCPパケットを生成する（ステップ２０６）。送信回路１１６はビデオデータのTCPパケットを送信する（ステップ２０８）。

コントローラ１２０は、送信中のビデオデータのTCPパケットの数、つまり送信回路１１６ですでに送信したが、たとえば他のビデオ会議システムなどのパケットを受信するレシーバでまだ受信していないビデオデータのTCPパケットの数を推定する（ステップ２１０）。現在送信中のTCPビデオパケットの数を確実に判定できないので、推定値が使用される。コントローラ１２０は、送信中のビデオデータのTCPパケットの数の推定値に従ってビデオデータのビットレートを制御する（ステップ２１２）。

図３は、現在送信中のTCPビデオパケット数の推定値に基づいてビデオデータのビットレートを制御するためのプロセス３００を示す。コントローラ１２０は、送信回路１１６で送信したビデオデータのTCPパケットの数とレシーバで受信したビデオデータのTCPパケット数との間の差DIFFを、好ましくはある所定期間の間に、判定する。

レシーバで受信した（ビデオ）データのTCPパケットの数を、好ましくはレシーバで送信して受信回路１１８で受信したリアルタイムトランスポートコントロールプロトコル（RTCP）のレシーバレポートパケットとしてレシーバから受け取る。ビデオ会議システム１００で送信したビデオデータのTCPパケットの数をビデオ会議システムから受け取る。好適な実施例において、RTCPのレポート間隔は２秒で、パケット数のカウントは例えば現在のビデオ会議セッションの開始のような初期化イベントから始まる。

コントローラ１２０はさらにネットワーク１０２で送信中であるビデオデータの送信したパケットの数Dを推定する（ステップ３０４）。推定値Dは、前の５０個のDIFFの値の中央値として計算されるのが好ましいが、違う数のDIFFの値を使用できるうえ、中央値の代わりに平均値、モード、またはDIFFの値の違う関数を使用することもできる。

しかし、初期化時にはDIFFの値の数が不十分である。７つのDIFFの値が計算されるまでDIFFの最初の値が使用されるのが好ましい。それからDIFFの５０個の値が計算されるまでDIFFのすべての値の中央値が使用される。

ネットワーク１０２のスピードが遅い場合には、Dの最初のいくつかの推定値が大きすぎる可能性がある、例えば最初のビデオビットレートがネットワーク１０２の平均ビットレートを遥かに超えるとき。従って、最初のビデオビットレートはビデオ会議システム１００で送信したビデオデータの平均のパケットの大きさSに基づいた値に最初限定されるのが好ましい。好適な実施例では、もし平均のパケットの大きさがKビットを超えれば、K=40,000であるとしてビットレートはDS<KになるまでK/DSで下げられる。言うまでもなく、Kとして他の値も使用できる。

プロセス３００はDの値の安定性によってメリットがある。従って、好適な実施例では、Dの新しい値が計算されると、それはDの前の値と比較される。Dの新しい値がDの前の値を囲む推定枠内に入るならば、Dの新しい値は捨てられ、Dの前値が使用される。推定値枠はD±DIFFの一つの標準偏差であるのが好ましい。DIFFの標準偏差はDIFFの前の５０の値の中央値絶対偏差（median absolute deviation）として計算されるのが好ましいが、他の計算方法も使用できる。

プロセス３００は送信中のビデオデータパケットの標準偏差SDevを推定する(ステップ３０６)。標準偏差SDevはDIFFの前の５０の値の中央値絶対偏差として計算されるのが好ましいが、他の計算方法も使用できる。しかし、初期化時にはDIFFの値の数が不十分である。７つのDIFFのサンプルが受信されるまで標準偏差SDevはDIFFの最高と最低の値の平均値として計算されるのが好ましいが、他の計算方法も使用できる。その後、標準偏差SDevは上記に説明したように計算される。

その後、プロセス３００はDIFFとDの値に従ってビデオデータのビットレートを制御する。特に、プロセス３００はDIFFのM連続値がDの関数であるしきい値を超えるとビットレートを下げ、DIFFのN連続値がDの関数であるしきい値よりも低くなるとビットレートを上げる。以下に詳しく述べるように、複数のしきい値を使用できる。

プロセス３００はしきい値ごとにカウンターIを維持する。４つのしきい値に対して、プロセス３００はカウンターI1、I2、I3、およびI4を維持する。プロセス３００はさらにビデオビットレート調整がなされていないレシーバレポートの数を数えるカウンターI5も維持するのが好ましい。

あるDIFFの値がDの値と標準偏差SDevの２倍の合計を超えるならば（ステップ３０８）、コントローラ１２０はカウンタI1をインクリメントする（ステップ３１０）。もしI1=3、つまり３つの連続したRTCPレシーバレポートに対してDIFF>D+2SDevであるならば（ステップ３１２）、コントローラ１２０はビデオビットレートを下げる（ステップ３１４）。その低下分は２０％であるのが好ましいが、他の値も使用できる。

ビデオビットレートを変えた後だけれども送信中のビデオデータのTCPパケットの数を改めて推定するよりも前に、プロセス３００は、好ましくは２つのRTCPレシーバレポートを飛ばして（ステップ３１８）、ある所定の期間待つ。プロセス３００はさらにビデオビットレートを変えてからすべてのカウンタI1、I2、I3、I4、およびI5をリセットする（ステップ３１８）。プロセス３００は次にステップ３０２で再開する。

しかし、もしステップ３０８でDIFF≦D+2SDevであれば、確実にカウンタI1が連続的にDIFF>D+2SDevであるRTCPレシーバレポートのみを数えるようにカウンタI1はゼロにリセットされる（ステップ３２０）。

あるDIFFの値がDの値と標準偏差SDevの合計を超える場合には(ステップ３２２)、コントローラ１２０はカウンタI2をインクリメントする（ステップ３２４）。もしI2=5、つまり５つの連続したRTCPレシーバレポーットに対してDIFF>D+SDevであるならば（ステップ３２６）、コントローラ１２０はビデオビットレートを下げ（ステップ３１４）、２つのRTCPレポートを飛ばして（ステップ３１６）、カウンタIをリセットする（ステップ３１８）。その後プロセス３００はステップ３０２で再開する。その低下分は２０％であるのが好ましいが、他の値も使用できる。

しかし、もしステップ３２２でDIFF≦D+SDevであれば、確実にカウンタI2が連続的にDIFF>D+SDevであるRTCPレシーバレポートのみを数えるようにカウンタI2はゼロにリセットされる（ステップ３２８）。

あるDIFFの値はDの値を超える場合には(ステップ３３０)、コントローラ１２０はカウンタI3をインクリメントする（ステップ３３２）。もしI3=9、つまり９つの連続したRTCPレシーバレポートに対してDIFF>Dであるならば（ステップ３３４）、コントローラ１２０はビデオビットレートを下げ（ステップ３１４）、２つのRTCPレポートを飛ばして（ステップ３１６）、カウンタIをリセットする（ステップ３１８）。その後プロセス３００はステップ３０２で再開する。その低下分は２０％であるのが好ましいが、他の値も使用できる。

しかし、もしステップ３３０でDIFF≦Dであれば、確実にカウンタI3が連続的にDIFF>DであるRTCPレシーバレポートのみを数えるようにカウンタI3はゼロにリセットされる（ステップ３３６）。

あるDIFFの値がDの値を下回る場合には(ステップ３３８)、コントローラ１２０はカウンタI4をインクリメントする（ステップ３４０）。もしI4=6、つまり６つの連続したRTCPレシーバレポートに対してDIFF<Dであるならば（ステップ３４２）、コントローラ１２０はビデオビットレートを上げ（ステップ３４４）、２つのRTCPレポートを飛ばして（ステップ３１６）、カウンタIをリセットする（ステップ３１８）。プロセス３００はその後ステップ３０２で再開する。その増加分は１０％であるのが好ましいが、他の値も使用できる。

しかし、もしステップ３３８でDIFF≧Dであれば、確実にカウンタI4が連続的にDIFF<DであるRTCPレシーバレポートのみを数えるようにカウンタI4はゼロにリセットされる（ステップ３４６）。

確実にビデオビットレートが不要に低い値で安定しないように、もしJの連続DIFF値に対して（つまりJのRTCPレシーバレポートパケットに対して）ビデオビットレートには変化がなければ、コントローラ１２０はビデオビットレートを上げる。J=16であって増加分は１０％であるのが好ましいが、他の値も使用できる。従って、あるRTCPレシーバレポートに対してビデオビットレート調整がなければ、プロセス３００はカウンタI5をインクリメントする（ステップ３４８）。もしI5=16、つまり１６の連続したRTCPレシーバレポートに対してビデオビットレート調整がなければ（ステップ３５０）、コントローラ１２０はビデオビットレートを上げ（ステップ３４４）、２つのRTCPレポートを飛ばして（ステップ３１６）、カウンタIをリセットする（ステップ３１８）。その増加分は１０％であるのが好ましいが、他の値も使用できる。プロセス３００はその後ステップ３０２で再開する。

プロセス３００は、例えば有意義な動きを含むビデオであるi-frameを送信する際のようなビデオデータのバーストを処分するためのバースト認識ルーチンを含んでいるのが好ましい。このようなバーストが起きると、コントローラ１２０はビデオビットレートを半分にし、プロセス３００を再開する前に３つのRTCPレシーバレポートパケットに対してその値を維持する。

発明は、ディジタル電子回路機構、またはハードウェア、ファームウェア、ソフトウェア、またはそれらの組み合わせで実現できる。発明の装置は、プログラマブルプロセッサで実行するように例えば記憶装置などデバイス可読媒体に有形的に含まれたコンピュータプログラム製品に実現できる。および発明の方法ステップは、入力データに操作しおよび出力を生成することによって発明の機能を実行するための命令のプログラムを実行するプログラマブルプロセッサで実行できる。発明は、データストレージシステムとの間でデータおよび命令を送受信するように接続された少なくとも一つのプログラマブルプロセッサ、少なくとも一つの入力装置、および少なくとも一つの出力装置を含むプログラマブルシステムで実行可能な一つ以上のプログラムに都合よく実現できる。各コンピュータプログラムは高レベルの手続き型またはオブジェクト指向型プログラミング言語、または望むならばアセンブリあるいはマシン言語で実現できる。いずれにしても、言語はコンパイルされた言語または解釈された言語でいい。例として、適切なプロセッサとしては汎用および専用のマイクロプロセッサを共に使用できる。一般的に、プロセッサは読み取り専用メモリおよび／またはランダムアクセスメモリから命令およびデータを受け取る。一般的に、コンピュータはデータファイルを格納するための大容量記憶装置を一つ以上含んでいる。そうした装置としては、内部ハードディスクおよびリムーバブルディスクのような磁気ディスク、光磁気ディスク、および光ディスクなどがある。コンピュータプログラム命令およびデータを有形的に実施するのに適した記憶装置としては、あらゆる形の不揮発性メモリがあり、例としてEPROM、EEPROM、およびフラッシュメモリ素子のような半導体メモリ素子、内部ハードディスクおよびリムーバブルディスクのような磁気ディスク、光磁気ディスク、およびCD-ROMなどがある。上記のいずれもASIC（用途特定向け集積回路）によって補足またはASICに組み込むことができる。

発明のいくつかの実施例を説明してきた。しかし、発明の精神および範囲から逸脱しない限りにおいてさまざまな修正を行なえることがわかるだろう。したがって、他の実施例は下記の請求項の範囲内に入るものとする。

図１は、インターネットなどのようなネットワークに通信しているビデオ会議システムを示す。 図２は、本発明の好適な実施例による図１のビデオ会議システムのための適応型ビットレート制御プロセスを示す。 図３は、現在送信中のTCPビデオパケット数の推定値に基づいてビデオデータのビットレートを制御するためのプロセスを示す。

符号の説明

100 ビデオ会議システム
102 ネットワーク
104 ビデオソース
106 ビデオコーデック
108 パケット生成装置
110 音声ソース
112 音声コーデック
114 パケット生成装置
116 送信回路
118 受信回路
120 コントローラ
202 データ信号を生成
204 ある特定のビットレートでデータを生成するための例えばビデオなどデータ信号を符号化
206 データのTCPパケットを生成
208 データのTCPパケットを送信
210 送信中のTCPパケット数を推定
212 推定値に基づいてビットレートを制御
302 SDevを推定
304 Dを推定
306 DIFFを判定
314 ビットレートを下げる
316 ２つのレポートを飛ばす
318 I1, I2, I3, I4, I5をリセット
344 ビットレートを上げる

Claims (20)

1. あるビデオビットレートでビデオデータを生成するためのビデオコーデックと、
   ビデオデータのトランスポートコントロールプロトコル（TCP）パケットを生成するためのビデオパケット生成装置と、
   ある音声ビットレートで音声データを生成するための音声コーデックと、
   音声データのパケットを生成するための音声パケット生成装置と、
   ビデオデータのTCPパケットと音声データのパケットを送信するための送信回路と、
   ビデオデータのTCPパケットを受信するレシーバで受信したビデオデータのTCPパケット数を表すリアルタイムトランスポートコントロールプロトコル（RTCP）のレシーバレポートを受信するための受信回路、および
   コントローラを含み、コントローラは、
   送信回路で送信したビデオデータのTCPパケット数とレシーバで受信したビデオデータのTCPパケット数との差異に基づいて送信回路ですでに送信したがレシーバでまだ受信していないビデオデータのTCPパケット数の推定値を生成し、
   その推定値に従ってビデオビットレートを制御する、
   ビデオ会議装置。
2. あるビットレートでデータを生成するためのデータ生成装置と、
   データのトランスポートコントロールプロトコル（TCP）パケットを生成するためのパケット生成装置と、
   データのTCPパケットを送信するための送信回路、および
   送信回路ですでに送信したがデータのTCPパケットを受信するレシーバでまだ受信していないデータのTCPパケット数の推定値に従ってビットレートを制御するコントローラ、
   を含む装置。
3. コントローラは、
   初期化イベント後に送信回路で送信したデータのTCPパケット数と、
   初期化イベント後にレシーバで受信したデータのTCPパケット数と、
   送信回路ですでに送信したがレシーバでまだ受信していないデータのTCPパケット数の以前の推定値と、
   に基づいて送信回路ですでに送信したがレシーバでまだ受信していないデータのTCPパケット数の推定値を生成する、請求項２に記載の装置。
4. 送信回路ですでに送信したがレシーバでまだ受信していないデータのTCPパケット数の推定値を生成するために、コントローラは、
   初期化イベント後に送信回路で送信したデータのTCPパケットの数と初期化イベント後にレシーバで受信したデータのTCPパケットの数との間の複数の差異値をそれぞれ異なった時間に判定し、
   差異値の中央値、
   差異値の平均値、および
   差異値のモード
   から構成されるグループからの少なくとも一つに従って推定値を生成する、
   請求項３に記載の装置。
5. 送信回路ですでに送信したがレシーバでまだ受信していないデータのTCPパケット数の推定値に従ってビットレートを制御するために、コントローラは、
   初期化イベント後に送信回路で送信したデータのTCPパケットの数と初期化イベント後にレシーバで受信したデータのTCPパケットの数との間の連続差異値（consecutive differences）の第１所定数がすでに送信回路で送信したがレシーバでまだ受信していないデータのTCPパケットの数の推定値の第１関数であるしきい値を超えるとビットレートを下げ、
   初期化イベント後に送信回路で送信したデータのTCPパケットの数と初期化イベント後にレシーバで受信したデータのTCPパケットの数との間の連続差異値の第２所定数がすでに送信回路で送信したがレシーバでまだ受信していないデータのTCPパケットの数の推定値の第２関数であるしきい値よりも低くなるとビットレートを上げ、そして
   ビットレートがある所定の時間間隔の間上がっていないときにはビットレートを上げる、
   請求項２に記載の装置。
6. 送信回路ですでに送信したがレシーバでまだ受信していないデータのTCPパケット数の推定値に従ってビットレートを制御するために、コントローラはさらに、
   すでに送信回路で送信したがレシーバでまだ受信していないデータのTCPパケットの数の新しい推定値を生成し、
   その新しい推定値が推定値を囲む推定枠外にあるかどうかを判定し、
   その新しい推定値が推定値を囲む推定枠外にあるときには新しい推定値に基づいてビットレートを制御し、そして
   その新しい推定値が推定値を囲む推定枠内にあるときには推定値に基づいてビットレートを制御する、
   請求項５に記載の装置。
7. レシーバで受信したデータのTCPパケット数を表すデータのパケットを受信するための受信回路、
   をさらに含む、請求項２に記載の装置。
8. レシーバで受信したデータのTCPパケット数を表すデータのパケットは
   リアルタイムトランスポートコントロールプロトコル（RTCP）のレシーバレポートパケットを含む、請求項７に記載の装置。
9. データ生成装置は、
   ビデオデータを符号化するためのビデオコーデック、および
   音声データを符号化するための音声コーデック、
   からなるグループからの少なくとも一つを含む、請求項２に記載の装置。
10. 請求項２に記載の装置を含むビデオ会議システム。
11. あるビットレートでデータを生成するステップと、
    データのトランスポートコントロールプロトコル（TCP）パケットを生成するステップと、
    データのTCPパケットを送信するステップと、
    送信回路ですでに送信したがデータのTCPパケットを受信するレシーバでまだ受信していないデータのTCPパケット数の推定値に従ってビットレートを制御するステップと、
    を含む方法。
12. 送信回路ですでに送信したがレシーバでまだ受信していないデータのTCPパケット数の推定値を、
    初期化イベント後に送信回路で送信したデータのTCPパケット数と、
    初期化イベント後にレシーバで受信したデータのTCPパケット数と、
    送信回路ですでに送信したがレシーバでまだ受信していないデータのTCPパケット数の以前の推定値と、
    に基づいて生成するステップをさらに含む、請求項１１に記載の方法。
13. すでに送信したがレシーバでまだ受信していないデータのTCPパケット数の推定値を生成するステップは、
    初期化イベント後に送信回路で送信したデータのTCPパケットの数と初期化イベント後にレシーバで受信したデータのTCPパケットの数との間の複数の差異値をそれぞれ異なった時間に判定するステップと、
    差異値の中央値、
    差異値の平均値、および
    差異値のモード
    からなるグループからの少なくとも一つに従って推定値を生成するステップと、
    を含む、請求項１２に記載の方法。
14. すでに送信したがレシーバでまだ受信していないデータのTCPパケット数の推定値に従ってビットレートを制御するステップは、
    初期化イベント後に送信したデータのTCPパケットの数と初期化イベント後にレシーバで受信したデータのTCPパケットの数との間の連続差異値の第１所定数がすでに送信したがまだレシーバで受信していないデータのTCPパケットの数の推定値の第１関数であるしきい値を超えるとビットレートを下げるステップと、
    初期化イベント後に送信したデータのTCPパケットの数と初期化イベント後にレシーバで受信したデータのTCPパケットの数との間の連続差異値の第２所定数がすでに送信したがまだレシーバで受信していないデータのTCPパケットの数の推定値の第２関数であるしきい値よりも低くなるとビットレートを上げるステップと、
    ビットレートがある所定の時間間隔の間上がっていないときにはビットレートを上げるステップ、
    とを含む、請求項１１に記載の方法。
15. すでに送信したがTCPパケットを受信するレシーバでまだ受信していないデータのTCPパケット数の推定値に従ってビットレートを制御するステップは、
    すでに送信したがまだレシーバで受信していないデータのTCPパケットの数の新しい推定値を生成するステップ、
    その新しい推定値が推定値を囲む推定枠外にあるかどうかを判定するステップ、
    その新しい推定値が推定値を囲む推定枠外にあるときには新しい推定値に基づいてビットレートを制御するステップと、
    その新しい推定値が推定値を囲む推定枠内にあるときには推定値に基づいてビットレートを制御するステップと、
    をさらに含む、請求項１４に記載の方法。
16. レシーバで受信したデータのTCPパケット数を表すデータのパケットを受信するステップをさらに含む、請求項１１に記載の方法。
17. レシーバで受信したデータのTCPパケット数を表すデータのパケットは、
    リアルタイムトランスポートコントロールプロトコル（RTCP）のレシーバレポートパケット、
    を含む、請求項１６に記載の方法。
18. データは、ビデオデータまたは音声データの少なくとも一つを含む請求項１６に記載の方法。
19. デバイスで実行可能でしかも請求項１１に記載の方法を実行するように適合された命令プログラムを含んだデバイス可読媒体または波形（waveform）。
20. 請求項１２に記載の方法を実行するように適合されたデバイスで実行可能な命令プログラムを含んだデバイス可読媒体または波形（waveform）。

Images