(57)【要約】【課題】  エンド−トゥ−エンド輻輳制御を備える、無線ネットワークにおけるＭＰＥＧ−４ライブユニキャストビデオストリーミングシステムにおいて、ストリーミングサーバ１１はクライアント１２へ、ＲＴＰ／ＵＤＰプロトコルをもちいてリアルタイムビデオストリーミングを提供する。【解決手段】  ＲＴＰ／ＲＴＣＰ転送機構はパケットの送信／再送信だけでなく、データのセグメント化／逆セグメント化および、パケット化および逆パケット化をも扱う。ビットレート適合プロトコルおよび、ネットワーク帯域幅ポーリングプロトコルは自動的かつ動的に、利用可能なネットワーク帯域幅に基づいてデータビットレート／送信ビットレートを調整できる。それゆえ、絶えることのないライブビデオストリーミングサービスが保証される。【選択図】      図１
2004187286.tif 000002
【特許請求の範囲】
【請求項１】
利用可能なネットワーク帯域幅に基づいて自動的にかつダイナミックにデータビットレート／送信ビットレートを調整することができる、エンド−トゥ−エンド輻輳制御機構を備えた、無線ネットワークにおいて使用されるＭＰＥＧ−４ライブユニキャストビデオストリーミングシステムで、
（１）レート適応型ＭＰＥＧ−４シンプルプロファイルエンコーダは、
ａ．ＭＰＥＧ−４シンプルプロファイルライブビデオデータを生成し、
ｂ．ライブビデオデータをＨＴＴＰ／ＴＣＰによってＬＡＮを通じてストリーミングサーバへ送り、
ｃ．符号化ビットレートをストリーミングサーバからの要求に従って調整し、そして、
（２）ストリーミングサーバは、
ａ．ＨＴＴＰ／ＴＣＰによって、ＬＡＮを通じてレート適応型ＭＰＥＧ−４シンプルプロファイルエンコーダからライブＭＰＥＧ−４ビデオデータを受信するためのデータ受信モジュールを備え、
ｂ．ストリーミングセッションを扱うＲＴＳＰサーバモジュールを備え、
ｃ．ＲＴＣＰが再送信要求と応答を転送するために実行され、ＧＯＶ単位でＭＰＥＧ−４データをセグメント化し、各ＧＯＶをＲＴＰパケットのペイロードとしてパケット化し、そして、それらＲＴＰ／ＵＤＰパケットを各ＧＯＶのビットレートに基づいて無線ネットワークを通じてクライアントへ送る、ＲＴＰ／ＲＴＣＰ転送機構サーバモジュールを備え、
ｄ．ビットレート制御の決定はレート適応型ＭＰＥＧ−４シンプルプロファイルエンコーダへと転送され、ストリーミングサーバにクライアントと共にビットレート制御タスクを実行させる、ビットレート適合プロトコル及びネットワーク帯域幅ポーリングプロトコルを実行するためのビットレートアダプタ（サーバ）モジュールを備え、
ｅ．ＭＰＥＧ−４ＧＯＶデータを蓄積するためのデータリンクバッファ（サーバ）を備え、
（３）クライアントは、
ａ．受信したＭＰＥＧ−４ＧＯＶデータを復号し、画像を表示するためのレート適応型ＭＰＥＧ−４シンプルプロファイルデコーダを備え、
ｂ．ストリーミングセッションを扱うＲＴＳＰクライアントモジュールを備え、
ｃ．ＲＴＣＰが再送信要求と応答を転送するために実行され、ＲＴＰ／ＵＤＰパケットを無線ネットワークを通じてストリーミングサーバから受信し、ＲＴＰパケットのペイロードをＧＯＶに逆パケット化し、そして、ＧＯＶをＭＰＥＧ−４ビデオストリームに逆セグメント化するためのＲＴＰ／ＲＴＣＰ転送機構クライアントを備え、
ｄ．ビットレート制御の決定はストリーミングサーバへと転送され、クライアントにストリーミングサーバと共にビットレート制御タスクを実行させる、ネットワーク帯域幅ポーリングプロトコル及びビットレート適合プロトコルを実行するためのビットレートアダプタ（クライアント）モジュールを備え、
ｅ．ＧＯＶデータを蓄積し、自身の状態を監視し、ビットレート制御情報を取得し、その情報をビットレートアダプタ（クライアント）モジュールに転送するためのデータリンクバッファ（クライアント）を備えている。
【請求項２】
ＭＰＥＧ−４シンプルプロファイルビデオストリームデータが、ＧＯＶビットレートやＧＯＶ存続時間、ＧＯＶサイズなどの関連情報と共にＧＯＶのリンクとして蓄積されていて、
ＧＯＶ挿入やＧＯＶ読み出し、ＧＯＶ検索のようなインタフェースが他のモジュールに開かれていて、
ＧＯＶ読み出しの速度がＧＯＶ挿入の速度よりも遅い場合、バッファ状態をリセットすること及び残りの未読ＧＯＶを落とすことによる読み書きポインタの再同期化と共に、古い未読のＧＯＶへの上書きが許可される、
請求項１記載のストリーミングサーバにおいて使用されるデータリンクバッファ（サーバ）。
【請求項３】
各ＧＯＶがＲＴＰパケットにセグメント化及びパケット化され、そして一つのＲＴＰパケットが一つのＵＤＰパケットのペイロードとして格納され、データビットレートに基づき無線ネットワークを通じてクライアントへ送信され、そして、
すべての可能な再送信要求は、要求情報を含むＲＴＣＰパケットをロードするＵＤＰ接続を通じてクライアントから受信され、
再送信要求を受信した際に、要求されたＧＯＶはデータリンクバッファ（サーバ）の周辺で検索され、発見された場合は、要求されたデータあるいはＧＯＶ全体はＲＴＰパケットを使用してクライアントへできる限り早く再送信されるか、さもなければ、ＲＴＣＰチャンネルを通じて再送信禁止の非承認通知がクライアントへ返送される、
請求項１記載のストリーミングサーバにおいて使用されるＲＴＰ／ＲＴＣＰ転送機構サーバ。
【請求項４】
ビットレート制御情報がクライアントから受信され、帯域幅ポーリングがクライアントと協同して実行され、
ビットレートの決定がＴＣＰ接続を通じてレート適応型ＭＰＥＧ−４シンプルプロファイルエンコーダへ転送される、
請求項１記載のストリーミングサーバにおいて使用されるビットレートアダプタ（サーバ）。
【請求項５】
ＭＰＥＧ−４シンプルプロファイルビデオストリームデータが、ＧＯＶビットレート、ＧＯＶ存続期間、ＧＯＶサイズ等の関連情報と共にＧＯＶのリンクとして蓄積され、そして
ＧＯＶの挿入、空ＧＯＶの挿入、不完全ＧＯＶのデータ挿入、ＧＯＶの読出し、およびＧＯＶの検索のようなインタフェースは他のモジュールに開かれていて、
ＧＯＶの読出し速度がＧＯＶ挿入の速度よりも遅い場合、バッファ状態のリセット及び残りの未読ＧＯＶを落とすことによる、読み書きポインタの再同期と共に、古い未読ＧＯＶへの上書きが許可されて、そして
不完全なＧＯＶが確認されて、再送信要求はＲＴＰ／ＲＴＣＰ転送機構クライアントに送信され、再送信データがＲＴＰ／ＲＴＣＰ転送機構クライアントによって時間通りに挿入された場合、不完全なＧＯＶは完全なＧＯＶへ再生され、
現在のバッファ状態が取得され、ビットレート適合プロトコルに基づいてビットレートアダプタ(クライアント)に送信される、
請求項１記載のクライアントにおいて使用されるデータリンクバッファ(クライアント)。
【請求項６】
ＲＴＰパケットがＵＤＰ接続によって無線ネットワークを通じて受信され、ＧＯＶへの逆セグメント化及び逆パケット化がされ、
パケット損失あるいはパケットのシーケンス違反に関して、不完全ＧＯＶあるいは空ＧＯＶはデータリンクバッファ（クライアント）に挿入され、
全ての可能な再送信要求はデータリンクバッファ（クライアント）から受信され、要求情報を含んだＲＴＣＰパケットをロードするＵＤＰ接続を通じてＲＴＰ／ＲＴＣＰ転送機構サーバへ転送され、
再送信データの受信時に、特定のＧＯＶがデータリンクバッファ（クライアント）の付近で検索され、そして見つかった場合、再送信データあるいはＧＯＶ全体はリンク中のそれぞれの位置に挿入され、そして、
再送信禁止のＲＴＣＰパケットが受信された場合、これ以上の再送信要求を禁じるためにデータリンクバッファ（クライアント）内の特定のＧＯＶに再送信禁止フラグが設定される、
請求項１記載のストリーミングサーバにおいて使用されるＲＴＰ／ＲＴＣＰ転送機構クライアント。
【請求項７】
ビットレート制御情報がデータリンクバッファ（クライアント）から受信され、ビットレート決定がなされ、ＴＣＰ接続を通じてストリーミングサーバ中のビットレートアダプタ（サーバ）へ転送され、
ネットワーク帯域幅ポーリングプロトコルに基づいて、ストリーミングサーバ中のビットレートアダプタ（サーバ）と共に作業するようポーリング処理が開始され、
ストリーミングサーバとクライアントの間の、初期ストリーミングビットレートに関するオートネゴシエーションは、ネットワーク帯域幅ポーリングプロトコルを使用することによりストリーミングサーバ内のビットレートアダプタ（サーバ）で開始される、
請求項１記載のクライアントにおいて使用されるビットレートアダプタ（クライアント）。
【請求項８】
別途のフィールドが逆パケット化及び逆セグメンテーションのために規定されている、
請求項３記載のＲＴＰ／ＲＴＣＰ転送機構サーバ及び、請求項６記載のＲＴＰ／ＲＴＣＰ転送機構クライアントにおいて使用される拡張されたＲＴＰパケット構造。
【請求項９】
別途のフィールドが再送信のために規定されている、
請求項３記載のＲＴＰ／ＲＴＣＰ転送機構サーバ及び、請求項６記載のＲＴＰ／ＲＴＣＰ転送機構クライアントにおいて使用されるユーザアプリケーションＲＴＣＰ構造。
【請求項１０】
一つのＧＯＶが、一つのＧＯＶノードの中に関連情報と共に保存されている、
請求項２記載のデータリンクバッファ（サーバ）及び、請求項５記載のデータリンクバッファ（クライアント）において使用されるＧＯＶノード構造。
【請求項１１】
請求項５記載のデータリンクバッファ（クライアント）、請求項６記載のＲＴＰ／ＲＴＣＰ転送機構クライアント及び、請求項３記載のＲＴＰ／ＲＴＣＰ転送機構サーバにおいて使用される再送信機構。
【請求項１２】
請求項４記載のビットレートアダプタ（サーバ）及び、請求項７記載のビットレートアダプタ（クライアント）において使用されるネットワーク帯域幅ポーリングプロトコル。
【請求項１３】
請求項５記載のデータリンクバッファ（クライアント）、請求項４記載のビットレートアダプタ（サーバ）及び、請求項７記載のビットレートアダプタ（クライアント）において使用されるビットレート適合プロトコル。
【請求項１４】
決定スライディングウィンドウの実行を含む、請求項１３記載のビットレート適合プロトコルにおいて使用される、ビットレート決定ルール。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、利用可能なネットワーク帯域幅に基づいて、自動的かつダイナミック（動的）にデータビットレート／トランスミッションビットレートを調整できる、エンド−トゥ−エンド輻輳制御を備えた無線ネットワークにおけるＭＰＥＧ−４ライブユニキャストビデオストリーミングシステムの具現化に関係するものである。
【背景技術】
【０００２】
インターネット技術の成功及びウェブ上のマルチメディア情報への需要増加に基づいて、インターネットによるビデオストリーミングが学界及び産業界で注目を集めている。
【０００３】
従来、ビデオファイルはインターネットからダウンロードされ、ローカルで再生されていた。しかしファイル全体を転送した場合、非常に長く、受け入れがたい転送時間及び再生待ち時間をもたらしていた。また、ライブストリーミングはサポートされていなかった。
【０００４】
近年、ＤＳＬ（デジタル加入者回線）やケーブルモデム等の広帯域ネットワークの出現に伴い、インターネットによるリアルタイムビデオストリーミングが広く受け入れられ、展開されている。リアルタイムビデオストリーミングにおいて、ライブビデオ、あるいは蓄積されたビデオ映像はクライアントの要望に応じて、インターネットを介してサーバからクライアントに配信される。データ受信時にクライアントは配信された映像をリアルタイムで再生する。
【０００５】
リアルタイムビデオストリーミングにはいくつかの重要分野がある。それらは例えば、映像圧縮、アプリケーション層ＱｏＳ（クォリティーオブサービス）制御、連続メディア配信サービス、ストリーミングサーバ、メディア同期化機構、ストリーミングメディア用のプロトコル等である。一般的に、リアルタイムビデオストリーミングには帯域幅、遅延及び損失等についての要件がある。例えば、映像データはクライアントのもとで連続的に再生されなければならない。データが時間通りに到着しない場合、遅延あるいは損失したデータを待つために、再生は一時停止しなければならなくなり、それはユーザをいらだたせることになる。
【０００６】
しかしながら現在の最良のインターネット環境でも、ストリーミング映像に対していっさいＱｏＳ保証をしていない。一つの解決法として、ネットワークからのＱｏＳサポートを全く必要とせずに、パケット損失及び転送遅延の発生時に輻輳回避及び映像クォリティーの最大化を実現する、アプリケーション層ＱｏＳ制御がある。映像ストリーミングにおいて、一般的なアプリケーション層輻輳制御はレート制御の形態をとり、ビデオストリームのビットレートが利用可能なネットワーク帯域幅に合わせられる。
【０００７】
一般的に利用されるレート制御方式の一つとしてＲＡＰ（レート適応プロトコル）があり、これは、エンド−トゥ−エンドＴＣＰフレンドリーである。映像データはＴＣＰ接続を通じて配信される。ＴＣＰ受信確認フィードバックには、ＲＴＴ（往復時間）及びパケット損失率等の情報が含まれる。そして推定された現在のネットワーク帯域幅により、予め蓄積されたビデオストリームの送信データビットレートが調整される。
【０００８】
もう一つのレート制御方式は受信側のレート制御で、主にマルチキャスティングスケーラブルビデオストリームに使用される。スケーラブルビデオにはいくつかの層があり、それぞれの層がマルチキャストツリー中の１チャンネルに対応している。輻輳が検出されると、受信側は受信レートの削減につながる層を一つ落とし、送信側はレート制御には関与しない。
【０００９】
さて、多くのプロトコルがクライアントとストリーミングサーバとの間の通信用に設計され、標準化されている。当然、ＩＰはインターネットビデオストリーミング用のネットワーク層プロトコルとして働く。ＴＣＰの再送信機能は、遅延に関して厳しい条件を要求するビデオストリーミングアプリケーションにとって受け入れがたい遅延を常にもたらすので、今ではＵＤＰがビデオストリーミング用の転送プロトコルとして一般的に採用されている。
【００１０】
加えて、ＲＴＰ／ＲＴＣＰ（リアルタイムトランスポートプロトコル／リアルタイムコントロールプロトコル）はリアルタイムアプリケーションをサポートするためのＵＤＰ上で、エンド−トゥ−エンド転送機能を提供するために設計された。更には、ＲＴＳＰ（リアルタイムストリーミングプロトコル）は定められたセッションにおけるマルチメディアデータの配信を制御するためのメッセージや手段を定義する。
【００１１】
無線ネットワークの爆発的な発展に伴い、多くの人々がインターネットにアクセスするために無線ＬＡＮや携帯電話やＰＤＡを使用している。しかしながら有線ネットワークと比較すると、無線リンクはエラーが起こりやすく、帯域幅が限られていて、時変がある。ＭＰＥＧ−４技術の柔軟性及び効率のおかげで無線ネットワークを通じてのビデオストリーミング、特にライブビデオストリーミングが実現した。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
以上の点を考慮し、本願発明は最良のネットワーク環境を通じてストリーミングサーバに連続的なビデオストリーミングサービスを提供させ、無線ネットワークにおけるＭＰＥＧ−４ライブユニキャストビデオストリーミングシステムで利用される、ネットワーク帯域幅／ビットレート適合方法を提供することを目的とする。
【００１３】
また本願発明は、ＲＴＰ／ＲＴＣＰ／ＵＤＰやＲＴＳＰとともに利用され、クライアントがリアルタイムでデータを受信し、データを正確にデコードできるようにする、パケット化、再送信、ビットレート調整等を含む、リアルタイムストリーミング方法を提供することを他の目的とする。
【課題を解決するための手段】
【００１４】
上記課題を解決するために、ダウンリンク（ストリーミングチャンネル）としてはＵＤＰ（ユーザデータグラムプロトコル、ＲＦＣ７６８）を採用し、アップリンク（メッセージングチャンネル）としてはＴＣＰ（送信制御プロトコル、ＲＦＣ７９３）を採用する。本発明は、図１に示す、ＭＰＥＧ−４シンプルプロファイルビデオデータの転送データ構造を提供する。
【００１５】
ここで、（１）レート適応型ＭＰＥＧ−４シンプルプロファイルエンコーダ（本発明の対象外）
ａ）ＭＰＥＧ−４シンプルプロファイルライブビデオデータを生成し、
ｂ）ＬＡＮ（Local Area Network）を通じてストリーミングサーバへライブビデオデータを流し、
ｃ）ストリーミングサーバからの要求に応じて符号化ビットレートを調整する。
【００１６】
（２）ＬＡＮ
ａ）レート適応型ＭＰＥＧ−４シンプルプロファイルエンコーダとストリーミングサーバを接続する。
【００１７】
（３）ストリーミングサーバ
ａ）ＬＡＮを通じてレート適応型ＭＰＥＧ−４シンプルプロファイルエンコーダからライブＭＰＥＧ−４ビデオデータを受信するデータ受信モジュールを有し、
ｂ）セッション制御を行うＲＴＳＰ（リアルタイムストリーミングプロトコル、ＲＦＣ２３２６）サーバモジュールを有し、
ｃ）ＧＯＶ（グループオブビデオオブジェクトプレーン）の境界でＭＰＥＧ−４データをセグメント化し、ＲＴＰ（リアルタイムトランスポートプロトコル、ＲＦＣ１８８９）パケットのペイロードとして各ＧＯＶをパケット化し、各ＧＯＶデータビットレートに応じて、無線ネットワークを通じてクライアントへ前記ＲＴＰ／ＵＤＰパケットを送信し、再送信要求を受信するようＲＴＣＰ（リアルタイムコントロールプロトコル、ＲＦＣ１８８９）が実行されるデータ送信モジュールを有し、
ｄ）ビットレート適合プロトコルとネットワーク帯域幅ポーリングプロトコルを実行し、ストリーミングサーバにクライアントからのフィードバック情報を受信させ、エンコーダに転送するビットレート制御の決定を行なわせる、ビットレートアダプタモジュールを有し、
ｅ）レート適応型ＭＰＥＧ−４シンプルプロファイルエンコーダから受信したＧＯＶデータを蓄えるデータリンクバッファを有する。
【００１８】
（４）レート適応型ＭＰＥＧ−４シンプルプロファイルデコーダ（本発明の対象外）
ａ）クライアントのアプリケーション中に存在し、
ｂ）受信したＭＰＥＧ−４シンプルプロファイルライブビデオデータをデコードし、
ｃ）デコードした画像を復元する。
【００１９】
（５）クライアント
ａ）無線ネットワーク（インターネット）を通じて、ストリーミングサーバからライブＭＰＥＧ−４ビデオデータを受信し、
ｂ）セッション制御を行うＲＴＳＰ（リアルタイムストリーミングプロトコル、ＲＦＣ２３２６）クライアントモジュールを有し、
ｃ）無線ネットワーク（インターネット）を通じてストリーミングサーバからＲＴＰ／ＵＤＰパケットを受信し、ＲＴＰ（リアルタイムトランスポートプロトコル、ＲＦＣ１８８９）パケットのペイロードから各ＧＯＶを逆パケット化し、ＭＰＥＧ−４データを元のＧＯＶ（グループオブビデオオブジェクトプレーン）に逆セグメント化し、ＭＰＥＧ−４ビデオストリームを再構築し、再送信要求を送信するためにＲＴＣＰ（リアルタイムコントロールプロトコル、ＲＦＣ１８８９）が実行されるデータ転送モジュール（ＲＴＰ／ＲＴＣＰ転送機構クライアント）を有し、
ｄ）ストリーミングサーバへビットレート制御情報をフィードバックするために、ビットレート適合プロトコルとネットワーク帯域幅ポーリングプロトコルを実行する、ビットレートアダプタモジュールを有し、
ｅ）受信したＧＯＶデータを蓄え、そのバッファリング状態を監視し、更に集めたバッファリング状態の情報をビットレートアダプタモジュールに送信するデータリンクバッファを有する。
【００２０】
本発明によれば、初期のストリーミングビットレートは二つの方法によって決定される。すなわち、
（１）クライアント側で、ＧＵＩ（グラフィックユーザインタフェース）を通じてユーザによって手動で設定される、あるいは、
（２）ネットワーク帯域幅ポーリングプロトコルを備えたストリーミングサーバ及びクライアントのオートネゴシエーションによる。
【００２１】
更に、本発明によれば、利用可能なネットワーク帯域幅に対するビットレートの適合は二つの側面からなる。すなわち、
（１）ネットワーク状況の悪化あるいはデコーダの不十分な処理能力による符号化ビットレートの減少、及び
（２）良好なネットワーク状況による符号化ビットレートの増加。
【００２２】
本発明の好ましい実施例によれば、レート適応型ＭＰＥＧ−４シンプルプロファイルエンコーダによって生成されたビットストリームは、まず初めにＨＴＴＰ／ＴＣＰ接続を通じて、ＧＯＶ単位でストリーミングサーバに送信される。
【００２３】
本実施例では、ＧＯＶが自身のビットレートに基づきネットワーク上に放出される前に、ストリーミングサーバにおけるデータ送信モジュールが、ＧＯＶをセグメント化及びパケット化する。
【００２４】
また、本発明の好ましい実施例によれば、クライアントのデータ送信モジュールが入来するＲＴＰ／ＵＤＰパケットを受信した場合、各ＧＯＶ、言い換えると、アクセスユニットの再構築、を開始する。それから、復元されたＧＯＶはクライアントのデータリンクバッファに挿入される。
【００２５】
本発明の好ましい実施例によれば、ＲＴＰ／ＵＤＰパケットの送信中にパケット損失が生じた場合、空のＧＯＶあるいは部分的に復元されたＧＯＶ（不完全なＧＯＶ）はデータリンクバッファに挿入される。
【００２６】
本発明の好ましい実施例によれば、データリンクバッファはＧＯＶあるいはＧＯＶの一部分の再送信の必要があるか否かをチェックする。再送信チェックは完全に復元したＧＯＶを挿入したあとに引き続き行なわれる。再送信要求はデータリンクバッファからデータ送信モジュールへ送られ、その後、ＲＴＣＰ／ＵＤＰパケットによりストリーミングサーバへ送信される。
【００２７】
本実施例によれば、ＧＯＶあるいはＧＯＶの一部分の再送信は一度だけ行える。本実施例によれば、ストリーミングサーバのデータリンクバッファ内に存在している上記のＧＯＶのみが再送信可能である。
【００２８】
本発明の好ましい実施例によれば、レート適応型ＭＰＥＧ−４シンプルプロファイルデコーダは、再送信によって復元されたものも含む、完全に復元されたＧＯＶを、データリンクバッファから取り出す。
【００２９】
本発明の好ましい実施例によれば、クライアント内のデータリンクバッファは現在の自身の状態を得て、その情報をクライアント内のビットレートアダプタモジュールに送信する。デコーダがデータリンクバッファから正常にＧＯＶを取り出す毎にこの動作が行なわれる。
【００３０】
本発明の好ましい実施例によれば、クライアント内のビットレートアダプタモジュールはビットレート制御情報を評価する。そして、ＴＣＰ接続を通じてストリーミングサーバ内のビットレートアダプタモジュールにその情報を送信する。
【００３１】
本発明の好ましい実施例によれば、ストリーミングサーバ内のビットレートアダプタモジュールは、クライアント内のビットレートアダプタモジュールからの情報に基づいてビットレート調整の決定を行う。次のＧＯＶの符号化ビットレートを調整するために、対応するコマンドがレート適応型ＭＰＥＧ−４シンプルプロファイルエンコーダへ送られる。
【００３２】
本発明の好ましい実施例によれば、クライアント内のビットレートアダプタモジュールとストリーミングサーバ内のビットレートアダプタモジュールは、ＵＤＰ接続を一時的に行なうことによりネットワーク帯域幅ポーリングプロトコルを使用した初期ストリーミングビットレートを取り決める。
【００３３】
実施例によれば、ネットワーク帯域幅ポーリングプロセスはデータストリーミング処理中にポーリングタイマーによって開始される。クライアント内のビットレートアダプタモジュールとストリーミングサーバ内のビットレートアダプタモジュールは、ＵＤＰ接続を一時的に行なうことにより、現在のネットワーク帯域幅がどれだけ現在のストリーミングビットレートを超えているかを取り決める。
【００３４】
本発明の好ましい実施例によれば、ユーザはＧＵＩ（グラフィックユーザインタフェース）を通じてストリーミングセッションを制御する。スタート、ストップなどのコマンドはＲＴＳＰ／ＴＣＰ接続によって送られる。
【００３５】
本発明の本質、原理や実用性は、以下の詳細な説明を、図面を参照しながら読むことで更に明らかになる。
【発明を実施するための最良の形態】
【００３６】
本発明によるエンド−トゥ−エンド輻輳制御を備えた、無線ネットワークにおけるＭＰＥＧ−４ライブユニキャストビデオストリーミングシステムの実施例は、図面を参照して以下に詳細に述べられる。
【００３７】
本実施例におけるストリーミングサーバ、クライアント（レート適応型ＭＰＥＧ−４シンプルプロファイルデコーダを含む）及びレート適応型ＭＰＥＧ−４シンプルプロファイルエンコーダは、以下に述べる処理を実行することができる情報処理装置を有する。これらの情報処理装置とは、いわゆる汎用コンピュータ、ワークステーション及びパソコンのみならず、デジタル家電のようなネットワークに接続できる情報処理装置、ＰＤＡのようなポータブルターミナル、及び携帯電話をも含む。以下に述べられる処理はソフトウェアによって実行されても良く、部分的にハードウェアユニットによって実行されても良い。
【００３８】
図１は、本発明のＭＰＥＧ−４ライブユニキャストビデオストリーミングシステムが適用される、無線ＭＰＥＧ−４ストリーミングシステムを概略的に示した図である。図面を参照すると、本システムはＭＰＥＧ−４データを符号化するレート適応型ＭＰＥＧ−４シンプルプロファイルエンコーダ１０、エンコーダ１０からＭＰＥＧ−４データを受信してクライアント１２に送信するストリーミングサーバ１１及び、ＭＰＥＧ−４データを受信してデコードするクライアント１２を包含する。エンコーダ１０とストリーミングサーバ１１はＬＡＮ１４を通じて接続されている。クライアント１２とストリーミングサーバ１１は無線ネットワーク１５を通じて接続されている。
【００３９】
図２は、ＲＴＳＰのセッション処理を概略的に示した図である。ストリーミングサーバ１１とクライアント１２の間のＲＴＳＰセッション処理は以下のメッセージによりＲＦＣ２３２６に完全に準拠している。
【００４０】
【数１】
2004187286.tif 000003
【００４１】
初めに、ＲＴＳＰクライアント２５は、セッションセットアップを求めるセットアップメッセージ（ＳＥＴＵＰ）をＲＴＳＰサーバ２１に送信する。ＲＴＳＰクライアント２５がアクティブＡＣＫ（応答）を受け取ると、ＲＴＰ／ＲＴＣＰ転送機構クライアントのオブジェクトを作成し、ストリーミングの開始を求めるプレイメッセージ（ＰＬＡＹ）をＲＴＳＰサーバ２１に送信する。そして、ＲＴＳＰサーバ２１は、ストリーミングサービスを提供するためにＲＴＰ／ＲＴＣＰ転送機構サーバ２２にオブジェクトを例示する。
【００４２】
セッション中、ＲＴＳＰサーバ２１及びＲＴＳＰクライアント２５のいずれもがキープアライブメッセージとして動作するゲットパラメータメッセージ（ＧＥＴ  ＰＡＲＡＭＥＴＥＲ）を送ることで、互いの状態を感知する必要がある。セッションの最後には、ＲＴＳＰクライアント２５はセッションを終了させるためにティアダウンメッセージ（ＴＥＡＲＤＯＷＮ）を送信する。
【００４３】
図３は、ＲＴＰ／ＲＴＣＰ転送機構の概略図である。本発明はクライアント側のデータリンクバッファ２８とストリーミングサーバ側のデータリンクバッファ２４、両方のデータリンクバッファに、パケット損失の復旧の促進を要求し、ＧＯＶデータのデコーダ１３への継続的な転送を確保している。ストリーミングサーバ１１において、ＧＯＶは最初に断片化され、ＲＴＰ／ＲＴＣＰ転送機構サーバ２２によってＲＴＰパケットに載せ替えられて、クライアント１２に送信される。クライアント１２において、ＲＴＰ／ＲＴＣＰ転送機構クライアント２６はＧＯＶ  ＲＴＰデータを抽出し、ＧＯＶに組み立てる。そして、これをクライアント側のデータリンクバッファ２８に挿入する。以下は、各構成要素の主な機能をまとめたものである。
【００４４】
（１）データリンクバッファ（サーバ）２４
ａ．送信と再送信のためにＧＯＶを蓄積する。
（２）ＲＴＰ／ＲＴＣＰ転送機構サーバ２２
ａ．ＧＯＶデータの送信／再送信を行う。
ｂ．ＣＲＴＰ（サーバ）、ＣＲＴＣＰ（サーバ）、ロガー（サーバ）及びプッシュタイマを備える。
（３）ＣＲＴＰ（サーバ）３０
ａ．関連するＧＯＶ情報からＲＴＰヘッダを構築する。
ｂ．ＲＴＰ／ＵＤＰ接続を行う。
ｃ．パケット送信を行う。
ｄ．パケット再送信を行う。
（４）ＣＲＴＣＰ（サーバ）３１
ａ．再送信要求を受信する。
ｂ．いかなる再送信禁止通知にも応答する。
（５）ロガー（サーバ）３２
ａ．パケット送信タイミングを記録する。
ｂ．エラー情報の履歴をとる。
（６）プッシュタイマ３３
ａ．ストリーミングビットレートを制御する。
【００４５】
（７）データリンクバッファ（クライアント）２８
ａ．ＲＴＰ／ＲＴＣＰ転送機構クライアントからのＧＯＶを蓄積する。
ｂ．ＧＯＶをデコーダに受け渡す。
（８）ＲＴＰ／ＲＴＣＰ転送機構クライアント２６
ａ．ＧＯＶデータ受信を行う。
ｂ．ＣＲＴＰ（クライアント）、ＣＲＴＣＰ（クライアント）及びロガー（クライアント）を備える。
（９）ＣＲＴＰ（クライアント）３４
ａ．ＲＴＰ／ＵＤＰ接続、データ受信を行う。
ｂ．全てのＲＴＰヘッダを判断し、ＲＴＰペイロードデータを抽出する。
ｃ．ＧＯＶを再構築する。
（１０）ＣＲＴＣＰ（クライアント）３５
ａ．再送信要求を送信する。
ｂ．いかなる再送信禁止通知も受信する。
（１１）ロガー（クライアント）３６
ａ．ＲＴＰパケットの到着タイミングを記録する。
ｂ．エラー情報の履歴をとる。
【００４６】
図４は、ＲＴＰ／ＲＴＣＰ転送機構間における通常のデータ送信の概略を示した図である。
【００４７】
（１）ストリーミングサーバ１１側
ａ．（エンコーダ１０から）ＧＯＶビットレート、ＧＯＶ存続時間及びＧＯＶサイズ等の関連情報と共に、未処理のＧＯＶが、データリンクバッファ（サーバ）２４に挿入される。
ｂ．新たに挿入されるＧＯＶをその関連する情報と共に蓄積するために、新たなメモリノードが割り当てられる。
ｃ．ＲＴＰ／ＲＴＣＰ転送機構サーバ２２はデータリンクバッファ（サーバ）２４から一つＧＯＶノードを取得する。
ｄ．ＲＴＰ／ＲＴＣＰ転送機構サーバ２２はＧＯＶビットレート、ＧＯＶサイズ及びＲＴＰパケットサイズに基づいて、ＲＴＰパケット存続時間を算出する。
ｅ．ＲＴＰ／ＲＴＣＰ転送機構サーバ２２はＲＴＰパケット存続時間に応じてプッシュタイマ３３をセットする。
ｆ．プッシュタイマ３３が始動すると、ＧＯＶビットレートに基づいてミリ秒タイマによって決定された間隔で、拡張ＲＴＰパケット（ＧＯＶのフラグメント）がクライアント１２に送信される。
【００４８】
（２）クライアント１２側
ａ．ＲＴＰ／ＲＴＣＰ転送機構クライアント２６はＧＯＶデータを含むＲＴＰパケットを受信する。
ｂ．ＲＴＰ／ＲＴＣＰ転送機構クライアント２６はＧＯＶの再構築を試みる。
ｃ．ＲＴＰ／ＲＴＣＰ転送機構クライアント２６は正常に復元されたＧＯＶをデータリンクバッファ（クライアント）２８に挿入する。
ｄ．データリンクバッファ（クライアント）２８は全体あるいは部分的に再送信される必要のある如何なるＧＯＶもチェックし、ＲＴＰ／ＲＴＣＰ転送機構クライアント２６にその要求を送る。
ｅ．再送信要求はＲＴＰ／ＲＴＣＰ転送機構間で実行される。
【００４９】
図５は、ＲＴＰ／ＲＴＣＰ転送機構間におけるデータ再送信の概略図である。一般的に、再送信には二つの形式がある。すなわち、単一のＲＴＰパケットの再送信とＧＯＶ全体の再送信とである。対応する要求（再送信要求）はＣＲＴＣＰ３１，３５によって行われ、それはＲＴＣＰプロトコルを実現する。各再送信要求では、ＧＯＶシーケンスナンバとそのＲＴＰパケットシーケンスナンバがＲＴＣＰパケットのフィールドとして定義される。
【００５０】
このようなＲＴＣＰ要求を受信した際、指定されたＧＯＶが新たなＧＯＶによって書き換えられずにデータリンクバッファ（サーバ）２４内に存在する限り、ストリーミングサーバ１１はデータリンクバッファ（サーバ）２４から、指定されたＧＯＶの取り出しを試みる。ＧＯＶ全体のＲＴＣＰ要求に対して、ストリーミングサーバ１１は、複数のＲＴＰパケットの状態で、クライアント１２にできる限り早く、指定されたＧＯＶを送ろうとする。
【００５１】
単一のＲＴＰパケットのＲＴＣＰ要求に対して、ストリーミングサーバ１１は対応するデータの塊を、ＲＴＰシーケンスナンバに基づき指定されたＧＯＶから取り出す。それから、ストリーミングサーバ１１はできる限り早く、対応するデータの塊を一つのＲＴＰパケットでクライアント１２へ送る。
【００５２】
一つのＧＯＶに複数のＲＴＰパケット損失があった場合、これらＲＴＰパケットの再送信要求は一つずつ行われる。しかしながら、指定されたＧＯＶが既にデータリンクバッファ（サーバ）２４内に存在しなかった場合、すなわち、指定されたＧＯＶが新しいＧＯＶによって書き換えられていた場合、ストリーミングサーバ１１はＲＴＣＰパケットを通じてクライアント１２に、再送信禁止メッセージを応答する。一度、クライアント１２がそのようなメッセージを受信すると、再送信が失敗し、再送信要求が再発行されないことを示すため、クライアント１２は、データリンクバッファ（クライアント）２８内の対応するＧＯＶに対して再送信禁止フラグを立てる。
【００５３】
再送信ＲＴＰパケットは通常のＲＴＰパケットと同様に処理される。再送信データはデータリンクバッファ（クライアント）２８内の対応するＧＯＶがデコーダ１３への転送を待っている限り、この対応するＧＯＶに挿入される。再送信されるべき全てのＧＯＶをチェックしているのが、データリンクバッファ（クライアント）２８である。この処理は新たな完全に復元されたＧＯＶの挿入によって、開始される。更に、通常の送信に影響しすぎることがないよう、同じＧＯＶデータに対する再送信要求の数は制限される。これは再送信がネットワーク帯域幅を使い果たしてしまうためであり、例えば再送信パケットが失われた場合は、ｎ回以下とされる。
【００５４】
図６は、拡張ＲＴＰパケットの構造を示す図である。本発明のＲＴＰパケットは、ＧＯＶのパケット化および逆パケット化に役立つ、いくつかの追加ヘッダフィールドにより拡張されている。下に示す表１は、拡張ＲＴＰパケット中の全てのフィールドを説明するものである。
【００５５】
【表１】
2004187286.tif 000004
【００５６】
図７は、ユーザアプリケーションＲＴＣＰパケットの構造を示す図である。ＲＴＣＰは失われたＲＴＰパケットの再送信要求を送信するために利用される。表２は、ユーザアプリケーションＲＴＣＰパケット中の全てのフィールドを示すものである。
【００５７】
【表２】
2004187286.tif 000005
【００５８】
図８は、ＲＴＰ／ＲＴＣＰ転送機構サーバ２２の処理動作の概略を示したフローチャートである。ＲＴＰ／ＲＴＣＰ転送機構サーバ２２は各ＧＯＶのＲＴＰパケットへのセグメント化及びパケット化の役割を担い、これらのＲＴＰパケットを無線ネットワーク１５を通じてクライアント１２に送信する。
【００５９】
クライアント１２において、ＧＯＶデータを含むＲＴＰパケットは、各ＲＴＰパケット中の参照番号、すなわち、ＴｘＧＯＶＳｅｑＮｕｍ、Ｃｒ、Ｔｒによって完全なＧＯＶに再構築される。ＵＤＰパケットは失われていたり、順序が狂って到着する可能性があるので、ＲＴＰ／ＲＴＣＰ転送機構２６はこの問題に対処する必要がある。
【００６０】
ＲＧ（ＲＴＰ  ＧＯＶ）には３つの種類、すなわち、ＮｅｗＲＧ、ＭｉｄｄｌｅＲＧ、ＬａｓｔＲＧがある。ここで、ＮｅｗＲＧはＧＯＶの初めのフラグメントであり、ＬａｓｔＲＧはＧＯＶの最後のフラグメントであり、残るＲＧはＭｉｄｄｌｅＲＧである。図９は、ＲＧ（ＲＴＰ  ＧＯＶ）を有する完全なＧＯＶの構造を示す図である。
【００６１】
クライアント１２に届くＲＴＰパケットには３つの状況が考えられる。すなわち、ＲＴＰパケットが、現在のＧＯＶに属する場合と、現在のＧＯＶ以前に受信されたＧＯＶに属する場合、あるいは現在のＧＯＶのあとに受信されるＧＯＶに属している場合とが考えられる。この３つの状況に対応して、３つのＲＧ、すなわち、CurrentInSeqＲＧ、LaggingＲＧおよび、LeadingＲＧを定義している。図１０は、上記３つのＲＧの分類を示したものである。
【００６２】
図１１は、ＲＴＰ／ＲＴＣＰ転送機構クライアント２６の処理動作を示した動作説明図である。図１２は、ＲＴＰパケット受信時の、ＲＴＰ／ＲＴＣＰ転送機構クライアント２６の、９つの異なる主要処理をあげた動作説明図である。
【００６３】
通常の送信時には、ＮｅｗＲＧが初めに、次にＭｉｄｄｌｅＲＧが、そして最後にＬａｓｔＲＧが到着し、この場合は全てのＲＧがCurrentInSeqＲＧに分類される。つまり、ケース１，４，７がこれに対応する。例えば、CurrentInSeqＲＧのＬａｓｔＲＧが失われた場合、ＲＴＰ／ＲＴＣＰ転送機構クライアント２６は現在のＧＯＶをクローズすることなくＮｅｗＲＧを受信する。従って、ＲＴＰ／ＲＴＣＰ転送機構クライアント２６はＮｅｗＲＧパケットを処理する前に、不完全なフラグを立てることで現在のＧＯＶを終了させ、現在のＧＯＶをデータリンクバッファ（クライアント）２８に挿入する必要がある。更には、ＧＯＶが一つのＲＧパケットしか持たないといった特例についても対処の必要がある。
【００６４】
本発明のビットレート制御機構は二つのカテゴリに分けられる。一つは、ネットワーク帯域幅の減少に対処するものである。もう一つは、現在のストリーミング状態が比較的良好で、データビットレートをネットワーク帯域幅に合わせるように上昇させることが可能な場合に、現在のネットワーク帯域幅を調査するものである。ビットレート制御の決定は、パケット損失率、パケット送信遅れ、パケット再送信率およびパケット再送信時におけるパケットの正常な到達率の統計的な情報を反映したデータリンクバッファ（クライアント）２８の状態に応じて変化する。
【００６５】
本発明において、データリンクバッファ（クライアント）２８は、ＧＯＶデータの蓄積、ビットレート制御情報の取得及び再送信要求の発行の役割を果たしている。データリンクバッファ（クライアント）２８の基本的特性はＧＯＶノードのリンクであり、それは以下に定義されるとおりである。
【００６６】
【数２】
2004187286.tif 000006
【００６７】
その上、データリンクバッファ（クライアント）２８には４つの基本インタフェースがある。
（１）ＲｅａｄＧＯＶ（）
データリンクバッファ（クライアント）２８から一つのＧＯＶを読み出すために、デコーダ１３へ開かれるインタフェース。
（２）ＩｎｓｅｒｔＧＯＶ（）
一つの新しく受信したＧＯＶを挿入するために、ＲＴＰ／ＲＴＣＰ転送機構クライアント２６へ開かれるインタフェース。
（３）ＩｎｓｅｒｔＢｌａｎｋＧＯＶ（）
データを持たない空のＧＯＶをデータリンクバッファ（クライアント）２８中に挿入するために、ＲＴＰ／ＲＴＣＰ転送機構クライアント２６へ開かれるインタフェース。
（４）ＩｎｓｅｒｔＧＯＶＲＴＰＰａｃｋｅｔ（）
あるＧＯＶに属する一つのＲＴＰパケットペイロードをデータリンクバッファ（クライアント）２８中に挿入するために、ＲＴＰ／ＲＴＣＰ転送機構クライアント２６へ開かれるインタフェース。
【００６８】
本発明では、ＧＯＶには３つの基本的なタイプがある。
（１）CompleteＧＯＶ（完全なＧＯＶ）
ＲＴＰ／ＲＴＣＰ転送機構クライアント２６によって、順序通り、完全、正常、かつ、時間通りに受信できたＲＴＰパケットのＧＯＶにあたり、ＲＴＰ／ＲＴＣＰ転送機構クライアント２６によって正常に再構築されるもの。CompleteＧＯＶは、ＩｎｓｅｒｔＧＯＶ（）のインタフェースを通じて、CompleteＧＯＶノードとしてデータリンクバッファ（クライアント）２８中に直接挿入される。データリンクバッファ（クライアント）２８中にあり、デコーダ１３によってまだ読み取られていない全てのCompleteＧＯＶの存続時間の合計は、残存ＧＯＶ再生時間と呼ばれる。
（２）IncompleteＧＯＶ（不完全なＧＯＶ）
パケット損失や長い送信遅れにより部分的に受信されたＲＴＰパケットのＧＯＶにあたる。ＲＴＰ／ＲＴＣＰ転送機構クライアント２６は、いくらかのデータが不足しているＧＯＶのみ再構築可能であり、ＩｎｓｅｒｔＧＯＶ（）のインタフェースを通じてIncompleteＧＯＶをデータリンクバッファ（クライアント）２８中に挿入する。システムは可能である場合（もとのＧＯＶがデータリンクバッファ（サーバ）２４中に存在する場合）に限り、失われたＲＴＰパケットを再送信することによって、IncompleteＧＯＶの、不足しているデータを追って復元させようとする。再送信が成功して、不足していたデータがＩｎｓｅｒｔＧＯＶＲＴＰＰａｃｋｅｔ（）のインタフェースを通じて復元できた場合、IncompleteＧＯＶはCompleteＧＯＶへと復元され、その存続時間は次の計算において残存ＧＯＶ再生時間に加算される。
（３）BlankＧＯＶ（空のＧＯＶ）
ＲＴＰ／ＲＴＣＰ転送機構クライアント２６によって、次にくるＧＯＶは受信されたものの、そのＲＴＰパケットが受信されていないＧＯＶにあたる。受信したＧＯＶの順序を保つため、ＲＴＰ／ＲＴＣＰ転送機構クライアント２６はBlankＧＯＶを作成し、ＩｎｓｅｒｔＢｌａｎｋＧＯＶ（）のインタフェースを通じてこれをデータリンクバッファ（クライアント）２８中に挿入する。BlankＧＯＶはデータリンクバッファ（クライアント）２８中のあるべき場所に存在し、その後、もとのＧＯＶ全体を再送信することによって（もとのＧＯＶがデータリンクバッファ（サーバ）２４中に存在する限り）復元される。再送信が成功して、不足していたデータがＩｎｓｅｒｔＧＯＶＲＴＰＰａｃｋｅｔ（）のインタフェースを通じて復元された場合、BlankＧＯＶはCompleteＧＯＶへと復元され、その存続時間は次の計算において残存ＧＯＶ再生時間に加算される。
【００６９】
本発明によれば、デコーダ１３がデータリンクバッファ（クライアント）２８からＧＯＶを取り出すときに、ビットレート制御情報の取得が開始される一方、ＲＴＰ／ＲＴＣＰ転送機構クライアント２６がデータリンクバッファ（クライアント）２８へＧＯＶを挿入するときに、再送信の確認が開始される。
【００７０】
図１３は、データリンクバッファ（クライアント）２８におけるＧＯＶ挿入の処理を示すフローチャートであり、それに対して図１４は、データリンクバッファ（クライアント）２８におけるＧＯＶ読み出しの処理を示すフローチャートである。図１５は、本発明におけるビットレート制御メッセージの流れを示すタイムシーケンス図であり、図１６は、本発明における再送信メッセージの流れを示すタイムシーケンス図である。
【００７１】
図１７は、ビットレート制御決定の処理を示す図である。主な要因はデータリンクバッファ（クライアント）２８内の合計残存ＧＯＶ再生時間であり、言い換えると、新しく入来したデータを考慮せず、現在バッファされたＧＯＶだけに基づいて、デコーダ１３がどのくらい長く再生するのかということである。CompleteＧＯＶ（完全なＧＯＶ）、IncompleteＧＯＶ（不完全なＧＯＶ）そしてBlankＧＯＶ（空ＧＯＶ）のうちで、完全なＧＯＶ（すなわち、正しく復元されたＧＯＶ）だけが、合計残存ＧＯＶ再生時間の計算の際に有効なＧＯＶであると見なされる。
【００７２】
最終的に、変動性のビットレート制御を実現するデータバッファ監視機構は、以下のようなスライディングウィンドウ監視システムである。初めに、データリンクバッファ（クライアント）２８中の再生時間によって測られた、バッファレベルの上限、中間及び下限値が規定される。これらのバッファレベルは決定スライディングウィンドウを構築し、そのなかで初期再生時間／現在の再生時間が中間値となるよう設定される。合計残存ＧＯＶ再生時間が上限と下限の間に入っている場合、ネットワーク帯域幅は許容範囲内である、すなわち、現在のストリーミングビットレートをサポートするのに充分であると言える。このような場合符号化ビットレートを調整する必要はない。
【００７３】
合計残存ＧＯＶ再生時間が（上限、中間］の範囲内である場合、これはデータリンクバッファ（クライアント）２８中で時々、ＧＯＶの出力レート（エンコーダ１０のデータ取得による）がＧＯＶの到着レート（データが到着するネットワーク１５による）より遅い事を意味し、言い換えると、デコーダ１３のデコードレートがデータビットレートより遅いことを意味する。
【００７４】
合計残存ＧＯＶ再生時間が上限に等しいかあるいは超える場合は、デコーダ１３のデコードレートが遅すぎることを意味する。デコーダ１３に負荷を与え過ぎないためには、ネットワーク帯域幅の安定状態に関わらず、エンコーダ１０の符号化ビットレートを、デコーダ１３の処理能力に適合するような段階まで減少させる必要がある。
【００７５】
一方で、合計残存ＧＯＶ再生時間が［中間、下限）の範囲内である場合、データリンクバッファ（クライアント）２８中では時々ＧＯＶの出力レート（エンコーダ１０のデータ取得による）がＧＯＶの到着レート（データが到着するネットワーク１５による）より速いことを意味し、言い換えると、パケット損失が生じているか、送信遅れが少し長いことを意味する。従って、再送信が必要である。
【００７６】
合計残存ＧＯＶ再生時間が下限と等しいかあるいは下まわる場合は、ネットワーク１５が現在のデータビットレートをこれ以上維持できないことを意味し、それは頻出するパケット損失あるいは長い送信遅れのどちらかによる。このような場合にデコーダ１３のデータ不足を防ぐためには、エンコーダ１０の符号化ビットレートを、ネットワーク１５の処理能力に適合するような段階まで減少させる必要がある。
【００７７】
デコーダ１３は、その処理能力の問題を解決するために容易に高性能機へアップグレードできるため、本発明におけるビットレート制御機構は、物理的には制御できないネットワーク環境悪化の場合に主に焦点を合わせている。パケット損失が起こったり、あるいはパケット送信遅れが１ＧＯＶ再生時間よりも長い場合、あるいは、期待されるＧＯＶの欠乏につながるどんな理由でも、現在のバッファレベル（合計残存ＧＯＶ再生時間）は下がるであろう。
【００７８】
例えば、再生開始時にバッファレベルは中間の値に設定されている。パケット損失が起きた場合、期待されるＧＯＶが時間通りに到達しないため、デコーダ１３がデータリンクバッファ２８から一つＧＯＶを取ると、バッファレベルは（中間値−１）に下がる。失われたパケットが時間通りに再送信できた場合、バッファレベルは中間値に戻る。しかし、そうでない場合、すなわち失われたパケットが時間通りに再送信できない場合、そして更なるパケット損失が起きた場合、デコーダ１３がＧＯＶを取り出したあとの空きを埋めるために、新しいＧＯＶが時間通りに来ないため、バッファレベルは下がり続ける。
【００７９】
バッファレベルが下限まで達した場合、現在の（過ぎた）ネットワーク帯域幅が現在のデータビットレートをサポートできなかったと言える。従って、その状況をエンコーダ１０にフィードバックし、現在の下限を新たな中間値として設定し、新たな中間値と比較して予め定義されたステップ（距離）を有する、新たな上限と下限を設定することで、決定ウィンドウを下方へ移動する。更に状況が悪化した場合、同様の下方修正が続けられる。
【００８０】
ライブストリーミングシステムでは、データリンクバッファ２８は復号処理を一時停止あるいは停止させることなしには再び満たされないため、０下限に到達した、すなわち、データリンクバッファ２８中に完全なＧＯＶがもう無い場合には、データリンクバッファ２８を満たすために、復号処理を一時停止あるいは停止することは避けられない。このような場合、バッファ決定レベルは初期値にリセットされ、それによって、データリンクバッファ２８は初期の中間値まで満たされ、それから再生が再開される。
【００８１】
ビットレート制御の主なプロセスは下記のように、簡単に示すことができる。
（１）現在の残存ＧＯＶ再生時間をデータリンクバッファ２８に取得し、
（２）現在の残存ＧＯＶ再生時間を現在の決定スライディングウィンドウと比較し、
（３）上の結果に基づいて決定し、
（４）符号化ビットレートを変更する必要がある場合、エンコーダ１０へメッセージを送信し、決定スライディングウィンドウを調整してポーリングタイマをリセットする、または変更する必要がない場合、現在の状況を記憶しておいてポーリングタイマが動作を開始したかを調査する。
（５）ポーリングタイマが動作を開始した場合、ポーリングを開始する。
（６）ポーリングを停止し、ポーリングタイマをリセットする。
（７）ポーリングが成功した場合、符号化ビットレートを変更する。
（８）（１）からの動作を繰り返す。
【００８２】
図１８は、ビットレート制御機構の基本的な定義の実例を示す図である。図１９は、ビットレート制御機構の通常の再生シナリオの実例を示す図である。図２０は、ビットレート制御機構のネットワーク環境悪化時のシナリオの実例を示す図である。図２１は、ビットレート制御機構におけるデコーダの不十分な処理能力シナリオの実例を示す図である。
【００８３】
本発明において、ポーリング処理は次のデータビットレートの有効性を確かめるよう設計されている。現在のネットワークストリーミングの状況が比較的良好であり、その状況をある期間維持できた場合、ネットワーク帯域幅は現在のデータビットレートよりもかなり大きい。
【００８４】
ネットワーク帯域幅のポーリングはポーリングタイマによって動作が開始される。ポーリング処理の間、通常のストリーミングは継続されるため、ポーリングおよび現在のストリーミングは同じ帯域幅を共有する。それ故、ポーリングビットレートは次のデータビットレートと現在のデータビットレートとの差分として設定される。ポーリングはビットレートアダプタ（クライアント）２７とビットレートアダプタ（サーバ）２３によって実行され、ビットレートアダプタ（サーバ）２３はポーリングビットレートに基づいて、ＲＴＰパケットをビットレートアダプタ（クライアント）２７に送る。
【００８５】
ポーリングが現在のストリーミング状態に影響する場合、あるいはポーリングのパケット損失レートが閾値を超える場合、ネットワーク帯域幅は次のデータビットレートをサポートできない。そうでなければ、符号化ビットレートを次の段階へと高めることができる。更に、ポーリングの状態が再び良好な場合、最大符号化ビットレートに到達するまでポーリング処理は繰り返し行なわれる。
【００８６】
ポーリングの原理は、残存ＧＯＶ再生時間が充分な期間（例えば３０秒）、特定のスライディングウィンドウ中にある場合に、ポーリングは、ネットワークがより高いビットレートをサポートできるかどうかを確認するというものである。ポーリングタイマが動作を開始する以前にスライディングウィンドウが調整された場合、ポーリングタイマは直ちにリセットされる。図２２は、ポーリング処理を示すタイムシーケンス図である。
【００８７】
ポーリングには、初期ストリーミングビットレートを自動設定するためのものもある。これもビットレートアダプタ（クライアント）２７とビットレートアダプタ（サーバ）２３との間のネゴシエーションによって行なわれる。ポーリングはビットレートステージリストの中間レベルから始まる。ポーリングが失敗した場合、次のポーリングのために一段低いビットレートが自動的に選択される。一方、ポーリングが成功した場合は、次のポーリングのために一段高いビットレートが自動的に選択される。
【００８８】
これらの処理は、その段階のポーリングは成功しているが、一段高いビットレートでのポーリングが失敗する、というビットレート段階が見つかるまで繰り返される。そして、このビットレート段階は初期ストリーミングビットレートとして設定される。図２３は、オートネゴシエーション手続きを示す図である。
【図面の簡単な説明】
【００８９】
【図１】本発明のシステム構造を示す図である。
【図２】ＲＴＳＰセッション処理の概略を示す図である。
【図３】ＲＴＰ／ＲＴＣＰ転送機構の概略を示す図である。
【図４】ＲＴＰ／ＲＴＣＰ転送機構間における通常のデータ送信の概略を示す図である。
【図５】ＲＴＰ／ＲＴＣＰ転送機構間におけるデータ再送信の概略を示す図である。
【図６】拡張ＲＴＰパケットの構造を示す図である。
【図７】ユーザアプリケーションＲＴＣＰパケットの構造を示す図である。
【図８】ＲＴＰ／ＲＴＣＰ転送機構サーバの処理動作の概略を示すフローチャートである。
【図９】ＲＧ（ＲＴＰ  ＧＯＶ）を有する完全なＧＯＶの構造を示す図である。
【図１０】ＵＤＰのシーケンス違反に関する、３つの異なるＲＧの分類を示す図である。
【図１１】ＲＴＰ／ＲＴＣＰ転送機構クライアントの処理動作を示す動作説明図である。
【図１２】ＲＴＰパケットを受信した際の、ＲＴＰ／ＲＴＣＰ転送機構クライアントの９つの異なる主要な処理をあげた動作説明図である。
【図１３】データリンクバッファ（クライアント）へのＧＯＶ挿入の処理を示すフローチャートである。
【図１４】データリンクバッファ（クライアント）へのＧＯＶ読み込みの処理を示すフローチャートである。
【図１５】本発明におけるビットレート制御メッセージの流れを示すタイムシーケンス図である。
【図１６】本発明における再送信メッセージの流れを示すタイムシーケンス図である。
【図１７】ビットレート制御決定の処理を示す図である。
【図１８】ビットレート制御機構の基本的な定義の実例を示す図である。
【図１９】ビットレート制御機構の通常の再生シナリオの実例を示す図である。
【図２０】ビットレート制御機構のネットワーク状況悪化時のシナリオの実例を示す図である。
【図２１】ビットレート制御機構におけるデコーダの不十分な処理能力シナリオの実例を示す図である。
【図２２】ポーリング処理を示すタイムシーケンス図である。
【図２３】オートネゴシエーション手続きを示す図である。
【符号の説明】
【００９０】
１０  レート適応型ＭＰＥＧ−４シンプルプロファイルエンコーダ
１１  ストリーミングサーバ
１２  クライアント
１３  レート適応型ＭＰＥＧ−４シンプルプロファイルデコーダ
１４  ＬＡＮ
１５  ネットワーク
２０  データ受信機（サーバ）
２１  ＲＴＳＰサーバ
２２  ＲＴＰ／ＲＴＣＰ転送機構サーバ
２３  ビットレートアダプタ（サーバ）
２４  データリンクバッファ（サーバ）
２５  ＲＴＳＰクライアント
２６  ＲＴＰ／ＲＴＣＰ転送機構クライアント
２７  ビットレートアダプタ（クライアント）
２８  データリンクバッファ（クライアント）
【図１】
2004187286.tif 000007
【図２】
2004187286.tif 000008
【図３】
2004187286.tif 000009
【図４】
2004187286.tif 000010
【図５】
2004187286.tif 000011
【図６】
2004187286.tif 000012
【図７】
2004187286.tif 000013
【図８】
2004187286.tif 000014
【図９】
2004187286.tif 000015
【図１０】
2004187286.tif 000016
【図１１】
2004187286.tif 000017
【図１２】
2004187286.tif 000018
【図１３】
2004187286.tif 000019
【図１４】
2004187286.tif 000020
【図１５】
2004187286.tif 000021
【図１６】
2004187286.tif 000022
【図１７】
2004187286.tif 000023
【図１８】
2004187286.tif 000024
【図１９】
2004187286.tif 000025
【図２０】
2004187286.tif 000026
【図２１】
2004187286.tif 000027
【図２２】
2004187286.tif 000028
【図２３】
2004187286.tif 000029
【外国語明細書】
１．Title of Invention
An MPEG-4 LIVE UNICAST VIDEO STREAMING SYSTEM IN WIRELESS NETWORK WITH END-TO-END BITRATE-BASED CONGESTION CONTROL
２．Detailed Description of Invention
1.Field of the Invention
The present invention relates to the realization of an MPEG-4 Live Unicast Video Streaming System in wireless network with end-to-end congestion control, which can automatically and dynamically adjust the data-bitrate/transmission-bitrate according to the available network bandwidth.
2.Description of the Related Art
Due to the success of the Internet technology and increasing demand for multimedia information on the web, streaming video over the Internet has becoming a key topic in academia and industry. 
Conventionally, video files are downloaded from the Internet and played back locally. But full file transfer introduces very long, unacceptable transfer time and playback latency. No live streaming is supported. 
Recently, with the emergence of wideband network, such as DSL (the Digital Subscriber Loop), cable modems, etc., real-time video streaming over the Internet is widely accepted and deployed. In real-time video streaming, live video or stored video is streamed across the Internet from the server to the client in response to a client's request. The client plays back the incoming video in real time when the data is received. There are several key areas of real-time video streaming such as video compression, application-layer QoS (Quality of Service) control, continuous media distribution services, streaming servers, media synchronization mechanisms, protocols for streaming media, etc. Typically, real-time video streaming has bandwidth, delay, and loss requirements. For instance, video data must be played back continuously at the Client. If the data does not arrive in time, the playback probably has to be paused to wait for the delayed or lost data, which is annoying to the user. However, the current best-effort Internet does not offer any QoS guarantees to streaming video. One solution is the application-layer QoS control, which does not require any QoS support from the network, to avoid congestion and maximize video quality in the presence of packet loss and transmission delay. For video streaming, typical application-layer congestion control takes the form of Rate Control, which attempts to match the bitrate of the video stream to the available network bandwidth. 
One popular Rate Control is RAP (Rate Adaptation Protocol), which is end-to-end TCP-friendly. Video data is streamed through TCP connection. In the feedback TCP Acknowledgement, there is the information of RTT (Round-Trip Time), packet loss ratio, etc. Then an estimated current network bandwidth is achieved to adjust the sending data bitrate of a pre-stored video stream.
Another popular Rate Control is Receiver-Based Rate Control, which is mainly used in multicasting scalable video streams. There are several layers in the scalable video and each layer corresponds to one channel in the multicast tree. When congestion is detected, a receiver drops a layer resulting in a reduction of its receiving rate whereas the sender does not participate in Rate Control.
Now quite a few protocols have been designed and standardized for communication between clients and streaming servers. Obviously, IP serves as the network-layer protocol for the Internet video streaming. Since TCP's retransmission feature always introduces delays that are not acceptable for video streaming applications with stringent delay requirements, UDP is now typically employed as the transport protocol for video streaming. In addition, RTP/RTCP (Real-time Transport Protocol/Real-Time Control Protocol) is designed to provide end-to-end transport functions on top of UDP for supporting real-time applications. Moreover, RTSP (Real Time Streaming Protocol) defines the messages and procedures to control the delivery of the multimedia data during an established session.
With the explosive development on wireless network, more and more people are now using wireless LAN or even their hand-phones and PDAs to access Internet. However, compared to the wired network, wireless links are more error-prone, bandwidth-limited and time varying. Thanks to the flexibility and efficiency of MPEG-4 technology, Video streaming through wireless network becomes available, especially for live video streaming.
3.Summary of the Invention
In view of the foregoing, it is an object of the present invention to provide a network bandwidth/bitrate adaptation method, for use in an MPEG-4 Live Unicast Video Streaming system in wireless network, that allows the Streaming Server to provide continuous video streaming service over best-effort network. At the same time, it is another object of the present invention to provide a real-time streaming method including packetization, retransmission, bitrate adjustment, etc., for use with RTP/RTCP/UDP and RTSP, that allows the Client to receive data in real-time and decode data properly.
To solve the above problems, it is provided that the downlink (streaming channel) adopts UDP (User Datagram Protocol, RFC768) and the uplink (messaging channel) adopts TCP (Transmission Control Protocol, RFC793). The present invention provides the architecture of transporting MPEG-4 Simple Profile Video data, which is shown in FIG. 1, wherein,
(１)A Rate Adaptive MPEG-4 Simple Profile Encoder, which is out of         the scope of this invention
(a.)Generates the MPEG-4 Simple Profile live video data,
(b.)Pushes live video data to the Streaming Server through LAN (Local Area Network),
(c.)Adjusts the encoding bitrate in accordance with the request from the Streaming Server,
(２)A LAN (Local Area Network)
(a.)Connects the Rate Adaptive MPEG-4 Simple Profile Encoder and the Streaming Server,
(３)A Streaming Server
(a.)Has a Data Receiver module to receive live MPEG-4 video data from the Rate Adaptive MPEG-4 Simple Profile Encoder through LAN,
(b.)Has a RTSP (Real Time Streaming Protocol, RFC2326) Server module, which performs the session control,
(c.)Has a Data Transmission module (the RTP/RTCP Transport Engine Server), which segmentizes the MPEG-4 data on the boundary of GOV (Group of Video Object Plane), packetizes each GOV as the payload of RTP (Real Time Transport Protocol, RFC1889) packets, and pushes those RTP/UDP packets to the Client through the wireless network according to each GOV data bitrate, whereas RTCP (Real Time Control Protocol, RFC1889) is implemented to receive the retransmission request,
(d.)Has a Bitrate Adapter module, which implements the Bitrate Adaptation protocol and Network Bandwidth Polling protocol, to allow the Streaming Server to receive feedback information from the Client and make the decision on bitrate control that is to be forwarded to the Encoder,
(e.)Has a Data Link Buffer, which is to store the GOV data that is received from the Rate Adaptive MPEG-4 Simple Profile Encoder,
(４)A Rate Adaptive MPEG-4 Simple Profile Decoder, which is out of the scope of this invention
(a.)Resides in the Client application,
(b.)Decodes the received MPEG-4 Simple Profile live video data,
(c.)Renders decoded pictures,
(５)A Client
(a.)Receives live MPEG-4 video data from the Streaming Server through wireless network (Internet),
(b.)Has a RTSP (Real Time Streaming Protocol, RFC2326) Client module, which performs the session control,
(c.)Has a Data Transmission module (the RTP/RTCP Transport Engine Client), which receives the RTP/UDP packets from the Streaming Server through the wireless network (Internet), depacketizes each GOV from the payload of RTP (Real Time Transport Protocol, RFC1889) packets, desegmentizes the MPEG-4 data back to GOV (Group of Video Object Plane), and reconstructs the MPEG-4 video stream, whereas RTCP (Real Time Control Protocol, RFC1889) is implemented to send the retransmission request,
(d.)Has a Bitrate Adapter module, which implements the Bitrate Adaptation protocol and Network Bandwidth Polling protocol, to feedback bitrate control information to the Streaming Server,
(e.)Has a Data Link Buffer, which is to store the received GOV data and monitor the buffering status of itself, as well as forward the collected buffer state information to the Bitrate Adapter module.
According to the present invention, the initial streaming bitrate is to be decided by two ways, that is
(１)Manually configured at the Client by the user through a GUI, or        
(２)Auto-negotiated by the Streaming Server and the Client with the Network Bandwidth Polling protocol.
Furthermore, in the present invention, the bitrate adaptation to the available network bandwidth consists of two aspects, that is
(１)Decrease of encoding bitrate due to network deterioration or decoder's poor throughput, and
(２)Increase of encoding bitrate due to health network condition.
In a preferred embodiment of the present invention, the Bit-stream, which is generated by the Rate Adaptive MPEG-4 Simple Profile Encoder, is firstly sent to the Streaming Server through HTTP/TCP connection with one GOV by one GOV.
The embodiment allows the Data Transmission module in the Streaming Server to segmentize and packetize the GOVs before the GOVs are put on the network according to their bitrate.
In a preferred embodiment of the present invention, if the Data Transmission module in the Client receives the incoming RTP/UDP packets, it starts the reconstruction of each GOV, in other words, the Access Unit. Then the recovered GOV is to be inserted into the Data Link Buffer in the Client.
In a preferred embodiment of the present invention, if packet loss occurs during the transmission of RTP/UDP packets, the blank GOV(s) or partially recovered GOV(s) (incomplete GOV(s)) is (are) to be inserted into the Data Link Buffer.
In a preferred embodiment of the present invention, it is the Data Link Buffer that checks whether it is necessary for a GOV or part of a GOV to be retransmitted. The retransmission checking is triggered by the insertion of a fully recovered GOV. Retransmission requests are to be passed to the Data Transmission module from the Data Link Buffer; then transmitted to the Streaming Server by the RTCP/UDP packets.
The embodiment allows the retransmission of a GOV or part of a GOV to be tried for only once.
The embodiment allows only those GOVs that are still in the Streaming Server's Data Link Buffer to be retransmitted.
In a preferred embodiment of the present invention, the Adaptive Rate MPEG-4 Simple Profile Decoder takes fully recovered GOVs, including those that are recovered by retransmission, from the Data Link Buffer.
In a preferred embodiment of the present invention, the Data Link Buffer in the Client collects its own current status and forwards that information to the Bitrate Adapter module in the Client. This is triggered each time when the Decoder successfully takes out a GOV from the Data Link Buffer.
In a preferred embodiment of the present invention, the Bitrate Adapter module in the Client evaluates the Bitrate Control Information; then forwards that information to its counterpart in the Streaming Server through TCP connection.
In a preferred embodiment of the present invention, the Bitrate Adapter module in the Streaming Server makes the decision on bitrate adjustment based on the information from its counterpart in the Client. Corresponding command is to be sent to the Adaptive Rate MPEG-4 Simple Profile Encoder to adjust the next GOV's encoding bitrate.
In a preferred embodiment of the present invention, the Bitrate Adapter module in the Client and its counterpart in the Streaming Server are to negotiate the initial streaming bitrate using Network Bandwidth Polling protocol by temporarily opening a UDP connection.
The embodiment allows the Network Bandwidth Polling process to be triggered by a Polling Timer during the data streaming procedure. The Bitrate Adapter module in the Client and its counterpart in the Streaming Server are to negotiate how far the current network bandwidth is over the current streaming bitrate by temporarily opening a UDP connection.
In a preferred embodiment of the present invention, a user controls the streaming session through GUI (Graphic User Interface). Commands such as Start, Stop, etc., are transported by RTSP/TCP connection.
The nature, principle and utility of the invention will become more apparent from the following detailed description when read in conjunction with the accompanying drawings.
4. Description of the Preferred Embodiments
An embodiment of an MPEG-4 Live Unicast Video Streaming System in wireless network with end-to-end congestion control according to the present invention will be described in detail below with reference to the drawings.
A Streaming Server, a Client (including a Rate Adaptive MPEG-4 Simple Profile Decoder), and a Rate Adaptive MPEG-4 Simple Profile Encoder included in this embodiment use information-processing devices that can execute the process described below.  Those information-processing devices include so-called general-purpose computers, workstations, and personal computers, as well as network connectable information-processing devices such as digital home electric appliances, portable terminals such as PDAs, and cellular phones.  It should be noted that the process described below may be performed by a software product and that a part of process may be done on a hardware unit.
FIG.1 is a diagram schematically showing the overview of a wireless MPEG-4 streaming system to which the MPEG-4 Live Unicast Video Streaming System according to the present invention is applied.  Referring to the figure, the system comprises a Rate Adaptive MPEG-4 Simple Profile Encoder that encodes MPEG-4 data, a Streaming Server that receives MPEG-4 data from the Encoder and sends it to the Client, and a Client that receives MPEG-4 data and decodes it. The Encoder and the Streaming Server are connected via a LAN. The Client and the Streaming Server are connected via a wireless network.
FIG. 2 is a diagram schematically showing the overview of the session procedure of RTSP. The RTSP session procedure between the Streaming Server and the Client is fully conforming to RFC2326 with the following messages.
2004187286.tif 000030
The RTSP Client initially sends the SETUP message to the RTSP Server asking for a session setup. If the RTSP Client gets active ACK, it creates the object of RTP/RTCP Transport Engine Client and sends PLAY message to the RTSP Server asking for start of the streaming. The RTSP Server then instantiates the RTP/RTCP Transport Engine Server object to provide the streaming service. During the session, both of the RTSP Server and RTSP Client need to sense the counterpart's status by sending GET PARAMETER messages to act as Keep Alive messages. At the end of the session, the RTSP Client sends the TEARDOWN message to terminate the session.
FIG. 3 is a diagram schematically showing the overview of the RTP/RTCP Transport Engine. The present invention requires the Data Link Buffer at both Client and Streaming Server sides to facilitate recovery of packet losses and ensure the constant flow of GOV data to the Decoder. At the Streaming Server, a GOV is firstly fragmented and encapsulated into RTP packets by the RTP/RTCP Transport Engine Server; then sent to the Client. At the Client, the RTP/RTCP Transport Engine Client extracts the GOV RTP data and assembles them into a GOV; then inserts it into the Client's Data Link Buffer. The followings summarize the main functionality of each component.
(１)Data Link Buffer (Server)
a.Stores GOVs for transmission and retransmission,
(２)RTP/RTCP Transport Engine Server
a.Handles transmission/retransmission of GOV data,
b.Includes CRTP (Server), CRTCP (Server), Logger (Server), and Push Timer,
(３)CRTP (Server)
a.Constructs the RTP Header from the related GOV information,
b.Handles RTP/UDP connection,
c.Handles packet transmission,
d.Handles packet retransmission,
(４)CRTCP (Server)
a.Receives retransmission request,
b.Replies any retransmission-forbidden notice,
(５)Logger (Server)
a.Records packet transmission timing,
b.Logs error information,
(６)Push Timer
a.Controls streaming bitrate,
(７)Data Link Buffer (Client)
a.Stores GOVs that are from RTP/RTCP Transport Engine Client,
b.Passes GOVs to the Decoder,
(８)RTP/RTCP Transport Engine Client
a.Handles GOV data receiving,
b.Includes CRTP (Client), CRTCP (Client), and Logger (Client),
(９)CRTP (Client)
a.Handles RTP/UDP connection and data receiving,
b.Interprets RTP Header and extracts RTP payload data,
c.Reconstructs GOV,
(１０)CRTCP (Client)
a.Sends out retransmission request,
b.Receives any retransmission-forbidden notice,
(１１)Logger (Client)
a.Records RTP packet arrival timing,
b.Logs Error information.
FIG.4 is a diagram schematically showing the overview of the normal data transmission between the RTP/RTCP Transport Engines, wherein,
(１)At the Streaming Server side
a.Raw GOV (from the Encoder) is inserted into the Data Link Buffer (Server) with related information such as GOV bitrate, GOV duration, GOV size, etc,
b.A new memory node is allocated to store the newly inserted GOV with its related information,
c.RTP/RTCP Transport Engine Server takes one GOV node from the Data Link Buffer (Server),
d.RTP/RTCP Transport Engine Server calculates the RTP packet duration according to the GOV bitrate, GOV size, and RTP packet size,
e.RTP/RTCP Transport Engine Server sets the Push Timer,
f.When the Push Timer triggers, extended RTP packet (fragment of GOV) is sent to the Client,
(２)At the Client side
a.RTP/RTCP Transport Engine Client receives RTP packets containing GOV data,
b.RTP/RTCP Transport Engine Client try to reconstruct the GOV,
c.RTP/RTCP Transport Engine Client inserts the successfully recovered GOV into the Data Link Buffer (Client),
d.Data Link Buffer (Client) checks for any GOV that needs to be retransmitted wholly or partially and passes the request to the RTP/RTCP Transport Engine Client.
e.Retransmission requests are proceeded between the RTP/RTCP Transport Engines.
FIG.5 is a diagram schematically showing the overview of the data retransmission between the RTP/RTCP Transport Engines. In general, there are two types of retransmission, i.e., the retransmission of single RTP packet and the retransmission of a whole GOV. The corresponding requests are handled by CRTCP, which realizes RTCP protocol. In each retransmission request, the GOV sequence number and its RTP packet sequence number are defined as the fields of RTCP packet. Upon receiving such RTCP request, the Streaming Server will try to retrieve the designated GOV from the Data Link Buffer (Server) as long as the designated GOV is still there without being overwritten by new GOV. For request of whole GOV, the Streaming Server will try to push the designated GOV to the Client as soon as possible in multiple RTP packets. For request of single RTP packet, the Streaming Server takes out the corresponding chunk of data from the designated GOV according to the RTP sequence number. Then the Streaming Server pushes the corresponding chunk of data to the Client in one RTP packet as soon as possible. In the case of multiple RTP packets losses of one GOV, the retransmission requests of those RTP packets will be issued one by one. However, if the designated GOV is no longer existing in the Data Link Buffer (Server), i.e., being overwritten by some new GOVs, the Streaming Server will reply a retransmission-forbidden message to the Client through a RTCP packet. Once the Client receives such a reply, it marks up a retransmission-forbidden flag of the corresponding GOV in the Data Link Buffer (Client) to indicate that retransmission is failed and no retransmission request should be re-issued. Retransmission RTP packet is processed as same as normal RTP packet is. The retransmitted data will be inserted into the corresponding GOV in the Data Link Buffer (Client) as long as it is still waiting for the Decoder's taking out. It is the Data Link Buffer (Client) that checks for any GOVs needing to be retransmitted. The process is triggered by the insertion of a new fully recovered GOV. Furthermore, in order not to affect the normal transmission too much, the number of retransmission request for the same GOV data should be limited, e.g., less than n times, in the case of retransmission packet being lost, since retransmission will consume the network bandwidth as well.
FIG.6 is a diagram showing the structure of the Extended RTP Packet. The RTP packet in the present invention is extended with several additional header fields to help packetize and depacketize the GOV. Table 1. explains all the fields in the Extended RTP packet, which is shown below.
2004187286.tif 000031
FIG.7 is a diagram showing the structure of the User Application RTCP Packet. RTCP is used to send the retransmission requests for the lost RTP packets. Table 2 shows all the fields in the User Application RTCP packet as follows.
2004187286.tif 000032
FIG.8 is an operation flowchart schematically showing the operation of a RTP/RTCP Transport Engine Server. A RTP/RTCP Transport Engine Server is responsible for segmentize and packetize GOV into RTP packets and push those RTP packets to the Client through the wireless network.
At the Client, RTP packets that contain GOV data are reassembled into a whole GOV by the help of the reference numbers in each RTP packet, i.e., TxGOVSeqNum, Cr, and Tr. Because UDP packet may be lost or arrive at the destination by out-of-sequence, the RTP/RTCP Transport Engine has to handle the proceeding problems. There are three types of RG (RTP GOV), i.e., New RG, Middle RG, and Last RG, whereas New RG is the first fragment of the GOV, Last RG is the last fragment of the GOV, and the rest RGs are Middle RGs. FIG. 9 is a diagram showing the structure of a complete GOV with RG (RTP GOV). There are three cases for a RTP packet arriving at the Client, i.e., the RTP packet belongs to the current expected GOV, or the GOV that should have been received before the current expected GOV, or the GOV that should be received after the current expected GOV. Correspondingly, we have three RG definitions, i.e., CurrentInSeqRG, LaggingRG, and LeadingRG. FIG. 10 shows the classification of the above three RGs.
FIG. 11 is an operation diagram showing the processing operation of a RTP/RTCP Transport Engine Client. FIG. 12 is an operation diagram listing the main nine different processes of a RTP/RTCP Transport Engine Client upon receiving a RTP packet. In a normal transmission, a New RG should arrive at first followed by some Middle RGs, and finally a Last RG, wherein, all of the RGs should fall in the CurrentInSeqRG category, i.e., cases of 1, 4, and 7. For instance, if the Last RG of a CurrentInSeqRG is lost, the RTP/RTCP Transport Engine Client will receive a New RG without closing the current GOV. Therefore, it must close the current GOV with the incomplete Flag being set and insert the current GOV into the Data Link Buffer (Client) before it goes to handle the New RG packet. Furthermore, a special case that a GOV only has one RG packet must be handled.
The Bitrate Control Mechanism in the current invention is divided into two categories, i.e., the one to deal with the scenario that the network BW (Bandwidth) is decreasing and another one to poll the current network BW when the current streaming status is quite satisfactory so that the data bitrate could be possibly increased to match the network BW. The decision of Bitrate Control is dependent on the status of the Data Link Buffer (Client), which reflects the statistical information of Packet Loss Rate, Packet Transmission Delay, Packet Retransmission Rate, and Successful Packet Retransmission Rate.
In the current invention, the Data Link Buffer (Client) is responsible for storing GOV data, collecting the Bitrate Control Information, and issuing retransmission request. The basic attribute of the Data Link Buffer (Client) is a link of GOV nodes, which is defined as the following.
2004187286.tif 000033
Moreover, there are four basic interfaces in the Data Link Buffer (Client).
(１)ReadGOV ()
This is the interface that is exposed to the Decoder for reading one GOV from the Data Link Buffer (Client).
(２)InsertGOV ()
This is the interface that is exposed to the RTP/RTCP Transport Engine Client for inserting one newly received GOV.
(３)InsertBlankGOV ()
This is the interface that is exposed to the RTP/RTCP Transport Engine Client for inserting a blank GOV that has no data into the buffer.
(４)InsertGOVRTPPacket ()
This is the interface that is exposed to the RTP/RTCP Transport Engine Client for inserting one RTP packet payload that belongs to a certain GOV into the buffer.
In the current invention, there are three basic types of GOV, wherein,
(１)Complete GOV
Refers to those GOVs whose RTP packets can be received by the RTP/RTCP Transport Engine Client in-sequence, fully, correctly and in time ; therefore, it can be reconstructed by the RTP/RTCP Transport Engine Client successfully. Complete GOV is directly inserted into the Data Link Buffer (Client) as a Complete GOV node through the interface of InsertGOV(). The sum of duration of all the Complete GOVs in the Data Link Buffer (Client), which have not been read by the Decoder, is called the Remaining GOV Playback Time.
(２)Incomplete GOV
Refers to those GOVs whose RTP packets are received partially due to the Packet Loss or long transmission delay. The RTP/RTCP Transport Engine Client can only reconstruct a GOV with some data being absent and insert the Incomplete GOV into the Data Link Buffer (Client) through the interface of InsertGOV(). The system will try to recover the absent data of the Incomplete GOV later by retransmitting those lost RTP packets if possible (as long as the original GOV is still in  the Data Link Buffer (Server)). If retransmission is successful and the absent data is recovered through the interface of InsertGOVRTPPacket(), the Incomplete GOV is recovered to Complete GOV and its duration will be added into the Remaining GOV Playback Time in the next calculation.
(３)Blank GOV
Refers to those GOVs whose RTP packets are not received but whose following GOV(s) is (are) received by the RTP/RTCP Transport Engine. In order to keep the sequence of the received GOVs, the RTP/RTCP Transport Engine Client will create a Blank GOV and insert it into the Data Link Buffer (Client) through the interface of InsertBlankGOV().  A Blank GOV resides at its should-be position in the link and is recovered by retransmitting the whole original GOV later (as long as the original GOV is still in the Data Link Buffer (Server)). If retransmission is successful and the absent data is recovered through the interface of InsertGOVRTPPacket(), the Blank GOV is recovered to Complete GOV and its duration will be added into the Remaining GOV Playback Time in the next calculation.
In the current invention, the collecting of Bitrate Control information is triggered when the Decoder is taking a GOV out of the Data Link Buffer (Client) whereas the checking of retransmission tryouts is triggered when the RTP/RTCP Transport Engine Client is inserting a GOV into the Data Link Buffer (Client).
FIG. 13 is a flowchart showing the process of GOV insertion in the Data Link Buffer (Client), whereas FIG. 14 is a flowchart showing the process of GOV reading in the Data Link Buffer (Client). FIG. 15 is a time sequence diagram showing the Bitrate Control message flows in the current invention, whereas FIG. 16 is a time sequence diagram showing the Retransmission message flows in the current invention.
FIG. 17 is a diagram showing the process of making Bitrate Control Decision. The key factor is the Total Remaining GOV Playback Time in the Data Link Buffer (Client), in other words, how long will the Decoder play back only based on the current buffered GOVs without considering any new incoming data. Among Complete GOV, Incomplete GOV, and Blank GOV, only Complete GOV (i.e., correctly recovered GOV) is considered as effective GOV when calculating the Total Remaining GOV Playback Time. The data buffer monitoring scheme, which ultimately realizes the variable bitrate control, is a Sliding Window Monitoring system. At first, the Upperbound, the Middlevalue, and the Lowerbound buffer levels are defined, which are measured by the playback time in the buffer. Those buffer levels construct the Decision Sliding Window, in which the initial playback time/current playback time is set to be the Middlevalue. When the Total Remaining GOV Playback Time falls in between the Upperbound and the Lowerbound, the network bandwidth is said to be acceptable, i.e., good enough to support the current streaming bitrate. There is no necessary to adjust the encoding bitrate for such case. If the Total Remaining GOV Playback Time is in the region of (Upperbound, Middlevalue], it means that sometimes in the buffer, the GOV leaving rate (caused by Encoder taking data) is slower than the GOV arriving rate (caused by network data arriving in), in other words, the Decoder's decoding rate is slower than the data bitrate. If the Total Remaining GOV Playback Time is equal or over the Upperbound, it means that the Decoder's decoding rate is too slow. In order to prevent the Decoder from overload, we have to decrease the Encoder's encoding bitrate to a reasonable stage to match the Decoder's throughput regardless of the health state of the network bandwidth. On the other hand, if the Total Remaining GOV Playback Time is in the region of [Middlevalue, Lowerbound), it means that sometimes in the buffer, the GOV leaving rate (caused by Encoder taking data) is faster than the GOV arriving rate (caused by network data arriving in), in other words, packet loss happens or the transmission delay is a bit long. So retransmission is necessary. If the Total Remaining GOV Playback Time is equal or below the Lowerbound, it means that the network cannot sustain the current data bitrate any more, either because of frequent packet loss or long transmission delay. In order to prevent the Decoder from hungry of data, we have to decrease the Encoder's encoding bitrate to a reasonable stage to match the network throughput.
As the Decoder can be easily upgraded to a high performance machine to solve its throughput bottleneck, the Bitrate Control mechanism in the current invention mainly focus on the network deterioration case, which physically is out of our control. If the packet loss happens or packet transmission delay is longer than one GOV playback time, or any reason that will result in the absence of the expected GOV, the current buffer level (the Total Remaining GOV Playback Time) will drop. For instance, when a playback starts, the buffer level is set at the Middlebvalue. If packet loss happens, the buffer level will drop to (Middlevalue  1) after the Decoder takes one GOV from the buffer as the expected GOV cannot arrive on time. If the lost packet can be retransmitted in time, the buffer level will go back to Middlevalue. But if not, and more packet losses occur, the buffer level will continuously drop because there is no new GOV coming in time to fill up the vacancies after the Decoder takes out GOVs. If it reaches the Lowerbound, we conclude that the current (past) network bandwidth cannot support the current data bitrate. We feed back the decision to the Encoder and move the Decision Window downwards by setting the current Lowerbound as the next-to-be Middlevalue and setting the next-to-be Upperbound and Lowerbound with the predefined Steps (Distances) compared to the next-to-be Middlevalue. If the situation becomes worse, the same downward adjustment will continue. Because in live streaming system, the buffer cannot be re-filled without pausing or stopping the decoding process, it is unavoidable that the decoding process must be paused or stopped in order to re-fill the buffer when the 0 Lowerbound is reached, i.e., there is no Complete GOV in the buffer any more. For such case, the buffer decision levels will be reset to the initial values, whereby the buffer must be re-filled to the initial Middlevalue then the playback can be resumed.
The main process of Bitrate Control can be simply described as below:
(１)Collect the Current Remaining GOV Playback Time in the buffer,
(２)Compare the Current Remaining GOV Playback Time to the current Decision Sliding Window,
(３)Make decision,
(４)If need to change the encoding bitrate, then send the message to the Encoder, adjust the Decision Sliding Window, and reset the Polling timer; otherwise remember the current state and check whether the Polling timer is triggered,
(５)If the Polling timer is triggered, start Polling,
(６)Stop Polling and reset the Polling timer,
(７)If Polling succeeds, change the encoding bitrate,
(８)Repeat from step (1).
FIG.17 is a diagram showing the process of Making Bitrate Control Decision.
FIG.18 is an illustrative diagram showing the basic definitions of the Bitrate Control mechanism. FIG.19 is an illustrative diagram showing the normal playback scenario of the Bitrate Control mechanism. FIG.20 is an illustrative diagram showing the network deterioration scenario of the Bitrate Control mechanism. FIG.21 is an illustrative diagram showing the Decoder's poor throughput scenario of the Bitrate Control mechanism.
In the current invention, the Polling process is designed to verify the availability of the next data bitrate stage. If the performance of the current network streaming is quite satisfactory and it has been lasted for a certain period, the network BW is much probably higher than the current data bitrate. The network bandwidth polling is triggered by the Polling Timer. Since during the Polling procedure the normal streaming is kept on, the Polling and the current streaming will share the same bandwidth. Therefore, The Polling bitrate is set as the difference between the next data bitrate stage and the current data bitrate. The Polling is handled by the BitrateAdapter (Client) and the BitrateAdapter (Server), whereas the BitrateAdapter (Server) pushes RTP packets to the BitrateAdapter (Client) according to the Polling bitrate. If the Polling affects the current streaming performance or the packet loss rate of the Polling exceeds a threshold, the network BW cannot support the next data bitrate stage. Otherwise, the encoding bitrate can be increased to the next higher stage. Moreover, if the condition of the Polling is met again, the Polling process will be conducted repeatedly until the maximum encoding bitrate is reached.
The principle of Polling is that if the Remaining GOV Playback Time has been in a certain Sliding Window for a period long enough (e.g., 30 seconds), the polling should be processed to check whether the network can support higher bitrate. If before the Polling Timer is triggered, the Sliding Window is adjusted, then the Polling Timer should be reset immediately. FIG. 22 is a time sequence diagram showing the polling process.
There is another kind of polling for auto-setting the initial streaming bitrate. This is also done by the negotiation between the BitrateAdapter (Client) and the BitrateAdapter (Server). The polling will start at the middle level in the bitrate stage list. If the polling is failed, then the next lower bitrate stage will be automatically chosen for the next polling. On the other hand, if the polling is successful, the next higher bitrate stage will be automatically chosen for the next polling. These procedures will repeat until a bitrate stage is found whereby the polling on itself is successful but the polling on the next higher bitrate of it is failed. This bitrate stage then is set as the initial streaming bitrate. FIG. 23 is a diagram showing the auto-negotiation procedure.
３．Brief Description of Drawings
In the accompanying drawings:
FIG.1 is a diagram showing the system architecture of the present invention;
FIG.2 is a diagram showing the overview of the RTSP session procedure;
FIG.3 is a diagram showing the overview of the RTP/RTCP Transport Engine;
FIG.4 is a diagram showing the overview of the normal data transmission between the RTP/RTCP Transport Engines;
FIG.5 is a diagram showing the overview of the data retransmission between the RTP/RTCP Transport Engines;
FIG.6 is a diagram showing the structure of the Extended RTP Packet;
FIG.7 is a diagram showing the structure of the User Application RTCP Packet;
FIG.8 is an operation flowchart schematically showing the processing operation of a RTP/RTCP Transport Engine Server;
FIG.9 is a diagram showing the structure of a complete GOV with RG (RTP GOV);
FIG.10 is a diagram showing the classification of three different RGs regarding the UDP out-of-sequence problem.
FIG.11 is an operation diagram showing the processing operation of a RTP/RTCP Transport Engine Client;
FIG.12 is an operation diagram listing the main nine different processes of a RTP/RTCP Transport Engine Client upon receiving a RTP packet;
FIG.13 is a flowchart showing the process of GOV insertion in the Data Link Buffer (Client);
FIG.14 is a flowchart showing the process of GOV reading in the Data Link Buffer (Client);
FIG.15 is a time sequence diagram showing the Bitrate Control message flows in the current invention;
FIG.16 is a time sequence diagram showing the Retransmission message flows in the current invention;
FIG.17 is a diagram showing the process of making Bitrate Control Decision;
FIG.18 is an illustrative diagram showing the basic definitions of the Bitrate Control mechanism;
FIG.19 is an illustrative diagram showing the normal playback scenario of the Bitrate Control mechanism;
FIG.20 is an illustrative diagram showing the network deterioration scenario of the Bitrate Control mechanism;
FIG.21 is an illustrative diagram showing the Decoder's poor throughput scenario of the Bitrate Control mechanism;
FIG.22 is a time sequence diagram showing the polling process;
FIG.23 is a diagram showing the auto-negotiation procedure.
In the accompanying tables:
Table 1 explains all the fields in the Extended RTP packet;
Table 2 explains all the fields in the User Application RTCP packet.
1.An MPEG-4 Live Unicast Video Streaming System for use in wireless network including an end-to-end congestion control mechanism that can automatically and dynamically adjust the data-bitrate/transmission-bitrate according to the available network bandwidth, wherein,
(1)A Rate Adaptive MPEG-4 Simple Profile Encoder
a.Generates the MPEG-4 Simple Profile live video data,
b.Pushes live video data to the Streaming Server by HTTP/TCP through LAN,
c.Adjust the encoding bitrate in accordance with the requirement from the Streaming Server, and
(2)A Streaming Server
a.Has a Data Receiver module to receive live MPEG-4 video data by HTTP/TCP from the Rate Adaptive MPEG-4 Simple Profile Encoder through LAN,
b.Has a RTSP Server module to handle the streaming session,
c.Has a RTP/RTCP Transport Engine Server module to segmentize the MPEG-4 data on the base of GOV, packetize each GOV as the payload of RTP packets, and pushes those RTP/UDP packets to the Client through wireless network  according to the bitrate of each GOV, whereas RTCP is implemented for transporting retransmission request and reply,
d.Has a Bitrate Adapter (Server) module to implement the Bitrate  Adaptation protocol and Network Bandwidth Polling protocol to allow the Streaming Server to proceed bitrate control tasks with the Client, whereas the bitrate control decision is to be forwarded to the Rate Adaptive MPEG-4 Simple Profile Encoder,
e.Has a Data Link Buffer (Server) to store the MPEG-4 GOV data,
(３)A Client
a.Has a Rate Adaptive MPEG-4 Simple Profile Decoder to decode the received MPEG-4 GOV data and render the pictures,
b.Has a RTSP Client module to handle the streaming session,
c.Has a RTP/RTCP Transport Engine Client to receive the RTP/UDP packets from the Streaming Server through wireless network, depacketize the payload of RTP packets to GOV, and desegmentize GOVs to MPEG-4 video stream, whereas RTCP is implemented for transporting retransmission request and reply,
d.Has a Bitrate Adapter (Client) module to implement the Bitrate Adaptation protocol and Network Bandwidth Polling protocol to allow the Client to proceed bitrate control taskswith the Streaming Server, whereas the bitrate control decision is to be forwarded to the Streaming Server,
e.Has a Data Link Buffer (Client) to store GOV data, monitor its own status, collect the bitrate control information, and forward the information to the Bitrate Adapter (Client) module.
2.The Data Link Buffer (Server) for use in a Streaming Server according to claim1,
wherein, the MPEG-4 Simple Profile video stream data is stored in as a link of GOVs with the related information such as GOV bitrate, GOV duration, GOV size, etc, and
wherein, interfaces such as inserting a GOV, reading out a GOV, and searching a GOV are exposed for other modules, and
wherein, if the speed of GOV reading is slower than the speed of GOV inserting, overwriting the old unread GOV is allowed with resynchronization of the Read and Write pointers by resetting the buffer status and dropping the rest unread GOVs.
3.The RTP/RTCP Transport Engine Server for use in a Streaming Server according to claim 1,
wherein, each GOV is segmentized and packetized into RTP packets, and then one RTP packet is packed as the payload of one UDP packet and is pushed to the Client through the wireless network according to the data bitrate, and
wherein, any possible retransmission request is received from the Client through UDP connection, which loads the RTCP packet contain the request information, and 
wherein, upon receiving the retransmission request, the required GOV is to be searched around the Data Link Buffer (Server), and if it is found, the required data or the whole GOV is to be retransmitted to the Client using RTP packets as soon as possible, otherwise, a negative acknowledgement of Forbidden-Retransmission is to be returned to the Client through RTCP channel.
4.The Bitrate Adapter (Server) for use in a Streaming Server according to claim 1,
wherein, bitrate control information is received from the Client, and bandwidth polling is proceeded with the cooperation of the Client, and
wherein, bitrate decision is forwarded to a Rate Adaptive MPEG-4 Simple Profile Encoder through TCP connection.
5.The Data Link Buffer (Client) for use in a Client according to claim 1,
wherein, the MPEG-4 Simple Profile video stream data is stored in as a link of GOVs with the related information such as GOV bitrate, GOV duration, GOV size, etc, and
wherein, interfaces such as inserting a GOV, inserting a Blank GOV, inserting data of an incomplete GOV, reading out a GOV, and searching a GOV are exposed for other modules, and
wherein, if the speed of GOV reading is slower than the speed of GOV inserting, overwriting the old unread GOV is allowed with resynchronization of the Read and Write pointers by resetting the buffer status and dropping the rest unread GOVs, and
wherein, Incomplete GOV is verified and retransmission request is sent to a RTP/RTCP Transport Engine Client, and if retransmitted data can be inserted in by the RTP/RTCP Transport Engine Client in time, Incomplete GOV is recovered to be Complete GOV, and 
wherein, current buffer status is collected and sent to a Bitrate Adapter (Client) according to the Bitrate Adaptation protocol.
6.The RTP/RTCP Transport Engine Client for use in a Streaming Server according to claim 1,
wherein, RTP packets are received by UDP connection through wireless network and then desegmentized and depacketized into GOV, and
wherein, upon packet loss or packet out-of-sequence, Incomplete GOV or Blank GOV is inserted to the Data Link Buffer (Client),
wherein, any possible retransmission request is received from the Data Link Buffer (Client), and then is forwarded to the RTP/RTCP Transport Engine Server through UDP connection, which loads the RTCP packet contain the request information, and 
wherein, upon receiving the retransmitted data, the specified GOV is to be searched around the Data Link Buffer (Client), and if it is found, the retransmitted data or the whole GOV is to be inserted to its position in the link, and
wherein, if Forbidden-Retransmission RTCP packet is received, the Forbidden-Retransmission flag of the specified GOV in the Data Link Buffer (Client) is to be set to forbid further retransmission request.
7.The Bitrate Adapter (Client) for use in a Client according to claim 1,
wherein, bitrate control information is received from the Data Link Buffer (Client), and bitrate decision is made and forwarded to a Bitrate Adapter (Server) in a Streaming Server through TCP connection, and 
wherein, according to the Network Bandwidth Polling protocol, a polling process is activated to work with a Bitrate Adapter (Server) in a Streaming Server, and 
wherein, an auto-negotiation on the initial streaming bitrate between a Streaming Server and a Client is initiated to work with a Bitrate Adapter (Server) in the Streaming Server by using the Network Bandwidth Polling protocol.
8.The extended RTP packet structure for use in a RTP/RTCP Transport Engine Server according to claim 3, and in a RTP/RTCP Transport Engine Client according to claim 6,
wherein, additional fields are defined for depacketization and desegmentation.
9.The user application RTCP structure for use in a RTP/RTCP Transport Engine Server according to claim 3, and in a RTP/RTCP Transport Engine Client according to claim 6,
wherein, additional fields are defined for retransmission.
10.The GOV node structure for use in a Data Link Buffer (Server) according to claim 2, and in a Data Link Buffer (Client) according to claim 5
wherein, one GOV is stored in one GOV node with some related information.
11.The retransmission mechanism for use in a Data Link Buffer (Client) according to claim 5, in a RTP/RTCP Transport Engine Client according to claim 6, and in a RTP/RTCP Transport Engine Server according to claim 3.
12.The Network Bandwidth Polling protocol for use in a Bitrate Adapter (Server) according to claim 4 and a Bitrate Adapter (Client) according to claim 7.
13.The Bitrate Adaptation protocol for use in a Data Link Buffer (Client) according to claim 5, a Bitrate Adapter (Server) according to claim 4 and a Bitrate Adapter (Client) according to claim 7.
14.The Bitrate Decision Rule with implementation of the Decision Sliding Window for use in a Bitrate Adaptation Protocol according to claim 13.
１．Abstract
With end-to-end congestion control, in an MPEG-4 Live Unicast Video Streaming System in wireless network, a Streaming Server provides real-time video-streaming to a Client by using RTP/UDP protocol. RTP/RTCP Transport Engines handle the segmentization / desegmentization and packetization / depacketizaiton of the data as well as the transmission/retransmission of the packets. A Bitrate Adaptation protocol and a Network Bandwidth Polling protocol can automatically and dynamically adjust the data-bitrate/transmission-bitrate according to the available network bandwidth; so that the continuous live video-streaming service is promised.
２．Representative Drawing
Figure.1
2004187286.tif 000034
2004187286.tif 000035
2004187286.tif 000036
2004187286.tif 000037
2004187286.tif 000038
2004187286.tif 000039
2004187286.tif 000040
2004187286.tif 000041
2004187286.tif 000042
2004187286.tif 000043
2004187286.tif 000044
2004187286.tif 000045
2004187286.tif 000046
2004187286.tif 000047
2004187286.tif 000048
2004187286.tif 000049
2004187286.tif 000050
2004187286.tif 000051
2004187286.tif 000052
2004187286.tif 000053
2004187286.tif 000054
2004187286.tif 000055
2004187286.tif 000056