(57)【要約】  アダプティブバッファリングの仕組みは、より効率的なメディア伝送およびバッファリングを可能とする。アダプティブバッファリングの仕組みの１つの側面では、バッファリングパラメータは、メディア再生コマンドまたは特定のメディアストリームに必要であるエンコード／コード変換の量などの異なったメディア特性に適合される。アダプティブバッファリングの仕組みのもう一つの側面では、バッファリングは、通信速度、パケットジッタ、または使用可能なバッファメモリの量などの異なった伝送またはメモリ条件に適合される。１つの例では、アダプティブバッファリングは、リアルタイムストリーミングプロトコル（ＲＴＳＰ）、および／または、リアルタイム伝送プロトコル（ＲＴＰ）および関連するリアルタイムコントロールプロトコル（ＲＴＣＰ）および／またはセッション記述プロトコル（ＳＤＰ）メッセージを使用することによりサポートされる。
2008527765.tif 000002
【特許請求の範囲】
【請求項１】
レンダリングエンドポイントにおいて使用される、新しいバッファ情報を特定するか、または、前記レンダリングエンドポイントにおいて使用される、現在のバッファ情報の特定を要求する、既に確立されたメディアセッションの間に、メッセージを送信するプロセッサを備えた、メディアサーバ。
【請求項２】
前記バッファ情報は、最小初期バッファフルネス値および最小バッファサイズ値の両方を含んだ、請求項１に記載のメディアサーバ。
【請求項３】
前記プロセッサは、前記レンダリングエンドポイントから受信したメディア再生要求に従い、前記バッファ情報を更新するメッセージを送信する、請求項１に記載のメディアサーバ。
【請求項４】
前記プロセッサは、前記メディア再生要求に関連したメディアを特定し、前記特定したメディアに対するコード化要求（coding requirements）を特定し、前記レンダリングエンドポイントに前記特定されたコード化要求に適合されたバッファパラメータを送信する、請求項３に記載のメディアサーバ。
【請求項５】
前記プロセッサは、前記メディアセッションの間、ネットワーク上において送信されるメディアに対し、利用可能な帯域幅または伝送速度における変化を特定し、そして、特定された利用可能な帯域幅または伝送速度の前記変化に適合されたバッファ情報を前記レンダリングエンドポイントに送信する、請求項１に記載のメディアサーバ。
【請求項６】
前記バッファ情報は、ジッタバッファパラメータおよび／またはプリデコーダバッファパラメータを含んだ、請求項１に記載のメディアサーバ。
【請求項７】
前記バッファ情報は、セッション記述プロトコル（ＳＤＰ）メッセージにおいて送信される、請求項１に記載のメディアサーバ。
【請求項８】
前記プロセッサは、前記レンダリングエンドポイントから受信した使用可能なバッファサイズメッセージに応じて、前記メディアセッションの間、動的にメディアコード変換（media transcoding）を調整する、請求項１に記載のメディアサーバ。
【請求項９】
リアルタイムストリーミングプロトコル（ＲＴＳＰ）またはリアルタイムコントロールプロトコル（ＲＴＣＰ）メッセージを使用して、前記レンダリングエンドポイントとバッファパラメータを交換する、請求項１に記載のメディアサーバ。
【請求項１０】
バッファパラメータを特定し、メディアをバッファリングするために、受信した前記バッファパラメータに従い、ローカルバッファを構成するメッセージを送受信するプロセッサを備えた、メディア処理装置。
【請求項１１】
前記プロセッサは、前記ローカルバッファが前記メディアのストリームをバッファリングしている間、受信された前記バッファパラメータに従い、前記ローカルバッファを動的に構成する、請求項１０に記載のメディア処理装置。
【請求項１２】
前記プロセッサは、前記メディアのストリームがバッファリングされている間、利用可能なローカルバッファスペースにおける変化を特定するメッセージを送信する、請求項１０に記載のメディア処理装置。
【請求項１３】
前記プロセッサは、前記利用可能なローカルバッファスペースにおいて特定された変化に動的に適合した新しいバッファパラメータを含んだメッセージを受信する、請求項１２に記載のメディア処理装置。
【請求項１４】
前記プロセッサは、ネットワーク受信レートにおけるパケットジッタまたは変動と関連づけられた前記ローカルバッファパラメータの変化を特定するサーバエンドポイントへメッセージを送信する、請求項１０に記載のメディア処理装置。
【請求項１５】
前記プロセッサは、前記ローカルバッファパラメータの特定された変化に適合した新しいバッファパラメータを、サーバエンドポイントから受信する、請求項１４に記載のメディア処理装置。
【請求項１６】
前記プロセッサは、最小プリデコーダバッファサイズ値および／または最小初期プリデコーダバッファフルネス値を特定するメッセージを受信する、請求項１０に記載のメディア処理装置。
【請求項１７】
前記プロセッサは、異なったメディア再生要求を前記サーバエンドポイントに送信し、前記メディア再生要求に対応する前記メディアに適合した、前記最小初期プリデコーダバッファサイズ値および／または前記最小初期プリデコーダバッファフルネス値を受信する、請求項１６に記載のメディア処理装置。
【請求項１８】
前記プロセッサにより送受信されるメッセージは、リアルタイムストリーミングプロトコル（ＲＴＳＰ）、および／または、リアルタイム伝送プロトコル（ＲＴＰ）および関連するリアルタイムコントロールプロトコル（ＲＴＣＰ）、および／または、セッション記述プロトコル（ＳＤＰ）メッセージである、請求項１０に記載のメディア処理装置。
【請求項１９】
受信された前記メッセージの少なくともいくつかは、新しいバッファパラメータと、前記新しいバッファパラメータを使用するべきメディアパケットを特定するパケットシーケンス番号とを含んだ、請求項１０に記載のメディア処理装置。
【請求項２０】
メディアストリームをバッファリングするためのバッファパラメータを特定するメッセージをエンドポイントと交換することと、
前記メディアストリームを前記エンドポイントに送信するか、または前記メディアストリームに関連したフィードバックを前記エンドポイントから受信することと、
前記メディアストリームにおける変化、または、前記メディアストリームの送信または受信に伴う条件の変化に適合した新しいバッファパラメータを含んだ新しいメッセージを前記エンドポイントと交換することと
を含んだ、バッファアダプテーションのための方法。
【請求項２１】
前記変化に適合した、最小バッファサイズ値および／または最小初期バッファフルネス値を送信または受信することを含んだ、請求項２０に記載の方法。
【請求項２２】
異なったメディア再生コマンドに対応した前記メディアストリームにおける変化に適合したバッファパラメータを送信または受信することを含んだ、請求項２０に記載の方法。
【請求項２３】
パケットジッタ、パケット遅延またはメディアのエンコードにおける変化に適合したデジタルバッファパラメータを送信または受信することを含んだ請求項２０に記載の方法。
【請求項２４】
使用可能なバッファスペースの量における変化を特定するメッセージを送信または受信することを含む請求項２０に記載の方法。
【請求項２５】
使用可能なバッファスペースの量における変化を特定するメッセージを送信または受信することと、次に、使用可能なバッファスペースにおける前記特定された変化に適合したバッファパラメータの送信または受信のいずれかを行うこととを含んだ請求項２０に記載の方法。
【請求項２６】
利用可能なジッタバッファスペースの量における変化を特定するメッセージの送信または受信を行うことを含んだ、請求項２４に記載の方法。
【請求項２７】
利用可能なプリデコーダバッファスペースの量における変化を特定するメッセージの送信または受信を行うことを含んだ、請求項２４に記載の方法。
【請求項２８】
使用可能なバッファスペースにおけるモニタされた変化に従い定期的に、または利用可能なバッファスペースのクエリメッセージへの応答として、使用可能なバッファスペースにおける特定された変化を送信することを含んだ請求項２４に記載の方法。
【請求項２９】
前記メッセージを交換するために、リアルタイムストリーミングプロトコル（ＲＴＳＰ）、リアルタイムコントロールプロトコル（ＲＴＣＰ）、またはセッション記述プロトコル（ＳＤＰ）を使用することを含んだ請求項２０に記載の方法。
【発明の詳細な説明】
【発明の詳細な説明】
【０００１】
［関連出願へのクロスリファレンス］
この出願は、２００４年１１月２４日に受理された米国仮出願番号６０／６３０，８５４の優先権を主張し、本明細書に参考として援用する。
【０００２】
［背景技術］
２つのデバイス間においてメディアを転送するとき、異なったバッファリングパラメータが使用される。例えば、バッファリングするメディアがサーバエンドポイント（serving endpoint）から受信されるとき、異なったジッタバッファ（jitter buffer）およびプリデコーダバッファパラメータ（pre-decoder buffer parameter）が、レンダリングエンドポイント（rendering endpoint）において使用されてもよい。レンダリングエンドポイントは、サーバエンドポイントに、「バッファサイズ」値を含んでいるバッファフルネス報告（Buffer Fullness Report）（ＢＦＲ）を送ってもよい。バッファサイズ値は、もしあれば、ジッタのサイズとプリデコードバッファのサイズとを含んでもよい。
【０００３】
しかしながら、他のバッファ情報もまた、メディアサーバエンドポイントとメディアレンダリングエンドポイントとの間で通信される必要があってもよい。例えば、特定の転送レート（Ｒ）のための、プリデコーダ（pre-decoder）バッファアンダフローおよびオーバフローを避けるために使用される、最小バッファサイズ（Ｂ）および最小初期バッファフルネスまたはフィルレベル（minimum initial buffer fullness or fill level）（Ｆ）がある。これはリーキーバケットモデル（leaky bucket model）と呼ばれる。
【０００４】
他のバッファパラメータが、メディアセッションの間、動的に変えられる必要があり得る、他の多くのシナリオがある。例えば、ワイヤレスホームネットワークの干渉および混線するトラフィックは、ジッタの量を、メディアサーバエンドポイントとメディアレンダリングエンドポイントの間でかなり異ならせることを引き起こし得る。従って、レンダリングエンドポイントは、効率的にこれらのジッタ変動を扱うためにジッタバッファサイズを変える必要があり得る。しかしながら、現在、レンダリングエンドポイントが、サーバエンドポイントへのこれらジッタバッファの変更を通信できる通信プロトコル／拡張は無い。
【０００５】
本発明は、従来技術に関連したこの問題および他の問題を扱う。
【０００６】
［発明の要約］
アダプティブバッファリングの仕組みにより、より効果的なメディア転送とバッファリングが可能になる。アダプティブバッファリングの仕組みの１つの側面として、バッファリングパラメータは、メディア再生コマンドなどの異なったメディアの特性、または特定のメディアストリームに必要であるエンコード／コード変換の量に適合させられる。アダプティブバッファリングの仕組みのもう一つの側面では、バッファリングは、通信速度、パケットジッタ、または使用可能なバッファメモリの量などの異なった伝送またはメモリ条件に適合させられる。１つの例では、アダプティブバッファリングは、リアルタイムストリーミングプロトコル（ＲＴＳＰ）、および／または、リアルタイム転送プロトコル（ＲＴＰ）および関連したリアルタイムコントロールプロトコル（ＲＴＣＰ）、および／または、セッション記述プロトコル（ＳＤＰ）メッセージを使用してサポートされる。
【０００７】
本発明の、上記および他の目的、特徴及び利点は、添付図面を参照して、以下の本発明の好適な実施例の詳細な説明から容易に、より明らかになる。
【０００８】
［詳細説明］
図１を参照して、サーバエンドポイント１２はメディア２０をレンダリングエンドポイント２４に提供する。デジタルメディアサーバエンドポイント１２のいくつかの例は、アドバンストセットトップボックス（ＡＳＴＢ）、デジタルビデオレコーダ（ＤＶＲ）、パソコンおよびノートパソコン、ハードディスクドライバを持つステレオおよびホームシアタ、ブロードキャストチューナ、カメラやカムコーダなどの動画および画像キャプチャデバイス、およびマルチメディア携帯電話機を含むが、これらに限定されない。レンダリングエンドポイント２４のいくつかの例は、テレビモニタ、ステレオおよびホームシアタ、パーソナルデジタルアシスタント（ＰＤＡ）、マルチメディア携帯電話機、ワイヤレスモニタ、ゲーム機、デジタルメディアアダプタ（ＤＭＡ）、または他のタイプのメディア出力装置も含むことができる。
【０００９】
サーバエンドポイント１２とレンダリングエンドポイント２４との接続２１は、有線またはワイヤレスのインターネットプロトコル（ＩＰ）ベースの通信プロトコルの任意のタイプを使用できる。例えば、接続２１は、ローカル・エリア・ネットワーク（ＬＡＮ）接続またはワイヤレス８０２．１１接続であってもよい。もちろん、他のタイプの有線またはワイヤレスの接続と通信プロトコルもまた使用できる。
【００１０】
サーバエンドポイント１２は、メディア１８をエンコードするプロセッサ１４を含み、レンダリングエンドポイント２４にエンコードされたメディアストリーム２０を送る。接続２１の上で伝送されるエンコードされたメディア２０は、ビデオ、オーディオ、イメージ、またはデジタルデータの任意のタイプであり得る。インターネットプロトコル（ＩＰ）ネットワークインタフェース、ワイヤレスのセルラーまたはＩＰベースのインタフェース、ユニバーサルシリアルバス（ＵＳＢ）インタフェースなどの、外部インタフェース１９から、メディア１８を受け取ることができる。
【００１１】
あるいはまた、サーバエンドポイント１２に接続されたまたは含まれた、カメラ、マイクロホン、または他のオーディオまたはビデオセンサから、メディア１８を受け取ってもよい。サーバエンドポイント１２は、メモリ１７にメディア１８を保存してもよし、単にインタフェース１９上で受け取ったメディア１８をレンダリングエンドポイント２４に転送してもよい。
【００１２】
レンダリングエンドポイント２４には、デジタルバッファ２８、および／または、プリデコーダバッファ３０があってもよい。また、これらのバッファは他の名前によっても示される。例えば、デジタルバッファは代わりにジッタバッファ、レシーババッファ、デジッタ（de-jitter）バッファ、再生バッファなどと呼ばれる。プリデコーダバッファ３０は、いくつかの例の名前を挙げると、代わりにデコーダバッファまたはメディアバッファと呼ばれる。以下での記述では、プリデコーダバッファ３０がメディアアダプテーションに使用される。例えば、メディアオーバフローおよびアンダフローを避けるのにプリデコーダバッファ３０を使用できるが、そうでなければ、メディアオーバフローおよびアンダフローは、メディアビットストリーム２０におけるビットレート変動のために起こり得る。メディア２０が接続２１の上で伝送されるとき、デジタルバッファ２８が、パケット伝送レート、パケットジッタ、またはパケット損失における変動を補う。
【００１３】
図１のデジタルバッファ２８およびプリデコーダバッファ３０は、論理的表現であり、別々のメモリデバイスの中に含まれてもよいし、または同じメモリデバイスまたはバッファ２６の中に含まれてもよい。実際のインプリメンテーションでは、特に可変ビットレート伝送において、別々のデジタルバッファ２８およびプリデコーダバッファ３０を持っていることは、最適とは言い得ない。しかしながら、説明の目的のために、プリデコーダバッファ２６およびデジタルバッファ２８の文脈で以下ではアダプティブバッファリングについて説明する。
【００１４】
［メディアアダプテーション］
サーバエンドポイント１２のプロセッサ１４とレンダリングエンドポイント２４のプロセッサ３２とは、それぞれ、変化するメディアおよび伝達の条件に適合したバッファパラメータ２２を交換する、バッファアダプテーションソフトウェア１６を操作する。また、プロセッサ１４は、異なったメディアまたは伝達の条件により、メディア１８のコード変換（trans-coding）を適合させてもよい。従って、レンダリングエンドポイント２４のプロセッサ３２は、サーバエンドポイント１２から受け取られた、適合したバッファパラメータ２２により、バッファ２６に関連したバッファパラメータを変えてもよい。そして、プロセッサ３２は、ディスプレイ画面、および／または、スピーカデバイスなどの出力装置３８にメディアを出力する前に、バッファ２６においてメディア２０をデコードするデコーダ３４を使用する。
【００１５】
図２は、さらに詳細に、図１に示されたプリデコーダバッファ３０に関連する２つの異なったバッファパラメータを示している。プリデコーダバッファ３０は、メディアオーバフローまたはアンダフローが起こらないことを保証するために、最小バッファサイズ（Ｂ）および最小初期バッファフルネス（Ｆ）を使用してもよい。例えば、サーバエンドポイント１２は、メッセージ２２で指定された関連したＢおよびＦ値が、リーキーバケットにおいて、エンコードされたメディアストリーム２０を含むような方法により、ライブメディアストリーム１８をエンコードしてもよい。
【００１６】
図１および２について言及すると、あらかじめエンコードされたメディアストリーム１８のケースでは、サーバエンドポイント１２はメッセージ２２のＢおよびＦ値を特定のレートＲに対して指定できる。さらに、サーバエンドポイント１２は、メディア１８の、様々な異なった（より低い）レートへのレート変換（trans-rating）をサポートしてもよい。この場合、メッセージ２２のＢおよびＦ値は、サーバエンドポイント１２によってサポートされたすべての異なったレートに対して、または最小のサポートされた値のみに対して、指定されてもよい。
【００１７】
最小バッファサイズ値Ｂおよび最小初期バッファフルネス値Ｆは、メディアセッションの間、メディアストリーム２０がサーバエンドポイント１２から送られて、レンダリングエンドポイント２４によりバッファリングされる間、指定され、動的に変えられてもよい。１つの例では、プリデコーダバッファ３０の動きは、仮想参照デコーダ（例えば、ＭＰＥＧ２  Ｖｉｄｅｏ  Ｂｕｆｆｅｒｉｎｇ  Ｖｅｒｉｆｉｅｒ−ＶＢＶ、Ｈ２６４／  ＡＶＣ−Ｇｅｎｅｒａｌｉｚｅｄ  Ｈｙｐｏｔｈｅｔｉｃａｌ  Ｒｅｆｅｒｅｎｃｅ  Ｄｅｃｏｄｅｒなど）により指定できる。
【００１８】
ビットストリーム設定（例えば、ＲＴＳＰ  ＳＥＴＵＰ要求を送る）時点のレンダリングエンドポイント２４は、まだメディアビットストリーム２０を受け取っておらず、特定のメディア制約条件に関する情報を持っていないことがあり得るので、バッファ値ＢおよびＦに関する知識は、持っていないこともある。また、プリデコーダバッファパラメータＢおよびＦは、ストリームの途中で変更できる。例えば、メディア１８は、定常ビットレート（Constant Bit Rate）（ＣＢＲ）または可変ビットレート（Variable Bit Rate）（ＶＢＲ）エンコーダを使用することでエンコードされてもよい。ＶＢＲエンコードの仕組みでは、メディアセッションの間、エンコードされたメディア２０は、変動するビットレートを持ってもよい。ＣＢＲによってエンコードされたメディアでさえ、変化するメディアビットレートを持ちうる。メディア転送、バッファリング、および再生を最適化するために、バッファパラメータＢおよびＦは、これらの変化するビットレートに対して、サーバエンドポイント１２により適合させられ、次いで、レンダリングエンドポイント２４に送られ得る。
【００１９】
異なったメディア制御操作のためのバッファパラメータを適合させる。
【００２０】
図３は、バッファパラメータが、どう異なったメディア再生操作に適合させられるかを、さらに詳細に示している。レンダリングエンドポイント２４からサーバエンドポイント１２に送られる、異なったＲＴＳＰ再生要求５４がある。これらの再生要求５４は、代わりにトリックモード要求と呼ぶことができ、どのようにまたはどのメディアフレームが接続２１上で伝送されるかを変更し得る、いかなるメディア操作も含むことができる。例えば、再生要求５４は、早送り、巻き戻し、スキップ、ポーズなどの操作を含むことが出来る。アダプティブバッファリングの仕組みは、これらの異なった再生要求５４に対して、バッファパラメータＢおよびＦを適合させることが出来る。
【００２１】
例えば、レンダリングエンドポイント２４は、ＲＴＳＰ  ＤＥＳＣＲＩＢＥメッセージ５０をサーバエンドポイント１２に送ることにより、メディアセッションを開始してもよい。サーバエンドポイント１２は、次に、特に初期最小バッファサイズＢ１および最小初期バッファフルネスＦ１を含んだＳＤＰ応答５２を送ってもよい。１つの特に注目すべき側面は、ＳＤＰ応答５２も、最小要求バッファサイズＢｍｉｎを含んでおり、また、最小初期バッファフルネスＦｍｉｎを含むことができるということである。ＳＤＰ応答５２はまた、メディアストリーム２０に関連している、転送情報、ビットレート、タイトル、作者などの他の情報を含んでもよい。
【００２２】
レンダリングエンドポイントは、サーバから、ＳＤＰ記述から、バッファパラメータに関する情報を得る。レンダリングエンドポイント２４は、バッファサイズ値と共に、それが最小バッファサイズ要求（Ｂｍｉｎ）を満たすなら、ＲＴＳＰ  ＳＥＴＵＰ要求を送ることができる。レンダリングエンドポイント２４は、サーバエンドポイント１２により指定された、最小要求バッファサイズ（Ｂｍｉｎ）と等しいかまたはより大きいバッファサイズとして、値を指定してもよい。
【００２３】
メディアセッションの間、この点以降、レンダリングエンドポイント２４は、範囲ヘッダおよび／またはスケールおよび／またはスピードヘッダを含んでよいＲＴＳＰ再生コマンド５４を送ってもよい。上で説明したように、ＲＴＳＰ再生コマンド５４は、代わりにトリックモードとも呼ばれる、早送り、巻き戻し、ポーズ、スキップなどの、メディア制御操作のいずれを含んでもよい。例えば、ＲＳＴＰ再生コマンド５４は、サーバエンドポイント１２に、メディアストリーム１８のおよそ途中までスキップするよう、要求してもよい。
【００２４】
従って、サーバエンドポイント１２内のプロセッサ１４は、要求された再生位置から、メディア１８を分析し、必要なら、新しいプリデコーダバッファ値Ｂ２および／またはＦ２を計算する。サーバエンドポイント１２は、次に、ＲＴＳＰ再生応答５６において、新しいデコーダバッファ値Ｂ２および／またはＦ２を、レンダリングエンドポイント２４に送る。レンダリングエンドポイント２４内のプロセッサ３２は、次に、新しいバッファパラメータＢ２および／またはＦ２により、バッファ２６を再構成する。
【００２５】
プロセッサ１４に、再生コマンド５４により、バッファ値ＢおよびＦを再調整させる、いくつかの要素がある。例えば、再生コマンド５４に対応したメディア１８の残量は、現在の最小バッファサイズＢ１より少ないかもしれない。このことにより、プロセッサ１４が、更新後の、より小さい最小バッファサイズＢ２を、レンダリングエンドポイント２４に送るかもしれない。
【００２６】
さらに、メディア再生コマンド５４において選択された位置におけるビデオフレームは、メディアストリーム１８内の現在位置におけるフレームよりも、より少ないデータ量を要求するか、より少ないデータ量にコード変換することができてもよい。例えば、選択された、中間のメディアストリーム位置のフレームは、メディアストリーム２０（例えば、戦闘の場面）の始めのフレームより、より少ないビデオ情報（例えば、一様な青空）を持ち得る。従って、新しく選択されたメディアストリーム位置において要求される最小初期バッファフルネスＦ２は、以前の最小初期バッファフルネスＦ１より少なくてもよい。
【００２７】
サーバエンドポイント１２内のプロセッサ１４は、最小バッファサイズＢおよび最小初期バッファフルネスＦの両方を、再生コマンド５４に対応させて決定し、次に、適合させたバッファパラメータＢ２およびＦ２を、ＲＳＴＰ再生応答５６に含める。このことにより、ユーザが新しい再生コマンドを送った後、再生の遅延は、より短くなり得る。例えば、より小さい特定された最小初期バッファフルネスＦは、メディア再生の前に、レンダリングエンドポイント２４により要求される初期バッファリングをより少なくし得る。
【００２８】
サーバエンドポイント１２は、再生コマンド５４に対し、どのようなＢおよび／またはＦパラメータを使用したらよいか決定することが出来ないかもしれないし、新しいプリデコーダ値も必要ではないと決定するかもしれない。これらの状況では、再生応答５６において、新しいＢおよび／またはＦバッファ値は、供給されない。もしサーバエンドポイント１２が、再生コマンド５４に対応して、ＢまたはＦ値のみが変えられるべきであると判断すると、対応する適合されたＢ２またはＦ２値のみが、応答５６において送信される。
【００２９】
サーバエンドポイント１２は、次いで、リアルタイム転送プロトコル（ＲＴＰ）などのプロトコルを使用し、メディアストリーム２０をパケットとして、レンダリングエンドポイント２４に送り始める。レンダリングエンドポイント２４は、次いで、バッファパラメータＢ２およびＦ２に応じて、受信されたメディアストリーム２０をバッファリングする。
【００３０】
［レートアダプテーション］
すぐ上で説明したバッファアダプテーションは、変化するメディアの特性に、バッファパラメータを適合させる。しかしながら、バッファアダプテーションはまた、変化する伝送条件に適応するためにも使用できる。例えば、ワイヤレスの、または、有線の伝送接続２１上において、メディア２０を伝送する間に、干渉に適応するために、バッファパラメータを適合させることも出来る。別の例では、バッファアダプテーションは、ベストエフォート型通信チャネルにおいて、変化する通信速度に適応してもよい。
【００３１】
さらに他の状況では、アダプティブバッファリングの仕組みは、レンダリングエンドポイント２４内の使用可能なバッファメモリの変更に、バッファパラメータを適合させてもよい。例えば、レンダリングエンドポイント２４には、特定の量の使用可能なバッファメモリがあってもよい。レンダリングエンドポイント２４には、メディアセッションの開始において、メディアセッションの間の別の時とは、異なった量の使用可能なバッファスペースがあってもよい。
【００３２】
バッファアダプテーションの仕組みは、より効率的なメディア転送を提供するために、使用可能なバッファスペースのこれらの変化にバッファパラメータを適合させる。例えば、転送レートは、より多くの利用可能なバッファスペースがあるときには、増加されてもよい。バッファアダプテーションは、また、メディアエンコードのタイプなどのモニタされたバッファ値に従って、単にバッファパラメータを変更するに留まらず、他のメディア操作を変えることもまた出来ることに注意することも重要である。
【００３３】
図４に言及すると、レンダリングエンドポイント２４内のデジタルバッファ２８は、通信チャネル２１における伝送変動を補うために使用される。例えば、デジタルバッファ２８は、メディア２０がサーバエンドポイント１２からレンダリングエンドポイント２４まで伝えられるときに、パケットジッタを補償するために使用され得る。前述の通り、デジタルバッファ２８およびプリデコーダバッファ３０は、論理的表現であり、共に同じバッファスペース２６の一部であってもよい。また、レンダリングエンドポイント２４は、ただ一つのデジタルバッファ２８またはプリデコーダバッファ３０によって構成されてもよいし、または両方によって構成されてもよいことが理解されるべきである。バッファ２８および／または３０のどのような組合せがレンダリングエンドポイント２４において使用されても、以下の説明では、総バッファサイズ７６を考慮に入れる。
【００３４】
サーバエンドポイント１２は、プロセッサ１４によって動作させられるか、または他のプロセッサによって動作させられる、ネットワークモニタ６０およびトランスコーダ６２を含んでもよい。ネットワークモニタ６０は、パケットジッタおよびパケット遅延などの異なった伝送パラメータに対して接続２１をモニタし、そして／または、ネットワーク条件に関してレンダリングエンドポイント２４からフィードバックを受け取る。トランスコーダ６２は、サーバエンドポイント１２とレンダリングエンドポイント２４との間で交換されたバッファリングパラメータにより、メディア１８をエンコードしてもよい。
【００３５】
この例では、第１のバッファサイズメッセージ６４Ａが、サーバエンドポイント１２からレンダリングエンドポイント２４に、またはレンダリングエンドポイント２４からサーバエンドポイント１２に送られる。バッファサイズメッセージ６４Ａは、総バッファサイズ値６６Ａ、プリデコーダサイズ値６８Ａ、および／または、デジタルバッファサイズ値７０Ａを含んでもよいバッファパラメータのどのような組合せも含むことができる。代わりに、または追加で、バッファサイズメッセージ６４Ａは、どのくらいのスペースが現在、総バッファ２６、デジタルバッファ２８、および／または、プリデコーダバッファ３０で利用可能であるかを示してもよい。
【００３６】
サーバエンドポイント１２は、どのくらいのメモリをバッファ２６、２８、および／または、３０に割り当てるかを示す、バッファサイズメッセージ６４Ａをレンダリングエンドポイント２４に送ってもよい。例えば、サーバエンドポイント１２は、メディア１８のタイプにより特定のバッファサイズ６６Ａ、６８Ａ、および／または、７０Ａを使用するようレンダリングエンドポイント２４に指示してもよい。
【００３７】
あるいはまた、レンダリングエンドポイント２４は、どれだけのバッファスペースが現在、バッファ２６、２８、および／または、３０においてサポートされているかを特定するバッファサイズメッセージ６４Ａを送ってもよい。そして、サーバエンドポイント１２は、メッセージ６４Ａにおいて特定されたバッファパラメータにより、異なった通信速度、および／または、エンコードアダプテーションを使用してもよい。例えば、トランスコーダ６２は、バッファサイズメッセージ６４Ａがデジタルバッファ２８はより小さいサイズであることを示すとき、より少ないエンコードされたメディア２０を生成するエンコーダを使用してもよい。また、サーバエンドポイント１２は、メッセージ６４Ａにおいて特定された使用可能なバッファスペースにより、異なった伝送またはビットレートでメディア２０を伝送してもよい。
【００３８】
さらに別の適用例では、サーバエンドポイント１２が、バッファサイズメッセージ６４Ａにおいて特定された使用可能なバッファサイズパラメータにより、プリデコーダバッファ値６８Ｂにおける、異なった最小バッファサイズＢ２、最小初期バッファフルネスＦ２を指定してもよい。別のシナリオでは、サーバエンドポイント１２は、バッファサイズメッセージ６４Ａで特定された使用可能なバッファサイズパラメータにより、新しいデジタルバッファサイズ値７０Ｂを送ってもよい。
【００３９】
また、バッファサイズメッセージ６４Ａおよび６４Ｂは、メディアセッション２０確立前または確立後に、送ることができ、サーバエンドポイント１２からまたはレンダリングエンドポイント２４から送ることができることに注意するべきである。さらに、現在のバッファ利用率または可用性がバッファ２６、２８、および／または、３０のどれかで変化するときはいつも、バッファサイズメッセージ６４は、例えば、レンダリングエンドポイント２４によって独自に送られてもよい。例えば、バッファの１つ内のデータが異なった既定のフルネス閾値より上昇するか、下回ったときはいつも、新しいバッファサイズメッセージ６４が、レンダリングエンドポイント２４により自動的に送られてもよい。あるいはまた、レンダリングエンドポイント２４は、バッファ値における変化にかかわらず定期的にバッファサイズメッセージ６４を送ってもよい。
【００４０】
さらに別の実施例では、サーバエンドポイント１２は、現在のバッファ値６６、６８、および／または、７０のいずれかを要求するメッセージをレンダリングエンドポイント２４に送ってもよい。レンダリングエンドポイント２４は、次に、サーバエンドポイント１２によって送られた要求メッセージへの応答として、バッファサイズメッセージ６４を送る。これは、例えば、サーバエンドポイント１２が、追加帯域幅が伝送メディアストリーム２０に対して利用可能であることを決定するとき、起こってもよい。しかしながら、サーバエンドポイント１２は、最初に、レンダリングエンドポイント２４が増加されたメディア伝送速度を扱うことができるくらいのバッファ容量を持っているか確かめる必要がある。あるいはまた、サーバエンドポイント１２は、ネットワークモニタ６０がジッタの増加を検出するとき、デジタルバッファ７２のサイズを増やすためにバッファサイズメッセージ６４をレンダリングエンドポイント２４に送ってもよい。
【００４１】
したがって、サーバエンドポイント１２およびレンダリングエンドポイント２４は、異なったメディア、ネットワーク、および／または、バッファサイズ条件に対応して、または以前にもう片方のエンドポイントから受け取られたバッファサイズメッセージにへの応答として、異なった時間に、独自にバッファサイズメッセージ６４を送ってもよい。これらは、もちろん、サーバエンドポイント１２またはレンダリングエンドポイント２４のいずれかによる、バッファサイズメッセージ６４の送信をうながしてもよい多数の異なったシナリオの、わずかな例である。
【００４２】
［通信プロトコル］
図５は、バッファパラメータを送信し、かつ要求するのに使用できる異なったプロトコルのいくつかを示している。１つのインプリメンテーションでは、バッファパラメータメッセージは、リアルタイムストリーミングプロトコル（ＲＴＳＰ）またはリアルタイムコントロールプロトコル（ＲＴＣＰ）要求８０を使用して送信されてもよい。また、ＲＴＳＰ  ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ、ＡＮＮＯＵＮＣＥ、またはＯＰＴＩＯＮＳ方式が、バッファパラメータへのどのような変化も送るのに使用されてもよい。
【００４３】
要求８０を受け取るエンドポイントは、ＲＴＳＰ、ＲＴＣＰ、またはセッション記述プロトコル（ＳＤＰ）応答９０により応答してもよい。代替の実施例では、レンダリングエンドポイント２４からＲＴＣＰバッファフルネス報告（ＢＦＲ）９６を使用することでバッファパラメータを送ってもよい。
【００４４】
レンダリングエンドポイント２４は、最小の、バッファサイズ要求を満たすバッファサイズ値８２を含むＲＴＳＰ  ＳＥＴＵＰ要求８０を送ることができる。レンダリングエンドポイント２４は、サーバエンドポイント１２によって指定された、最小要求バッファサイズに等しいか、または、より大きいバッファサイズ値８２を指定してもよい。もしレンダリングエンドポイント２４が、サーバエンドポイント１２によって指定された、絶対最小要求バッファサイズＢより小さいバッファサイズ値８２を指定したら、サーバエンドポイント１２は、ＳＥＴＵＰ要求８０を拒絶してもよいし、またはＲＴＳＰ  ＳＥＴＵＰ応答ヘッダ９０において最も少ない、サポートできるバッファパラメータ９１を指定してもよい。
【００４５】
上で説明したように、レンダリングエンドポイント２４は、バッファ２６のサイズ７６における変化を、サーバエンドポイント１２に信号を送るためにＲＴＳＰ  ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ／ＯＰＴＩＯＮＳ／ＡＮＮＯＵＮＣＥテクニックを使用できる。これはいくつかの異なった状況で起こってもよい。例えば、ジッタが増加したとき、レンダリングエンドポイント２４は、バッファ２８、３０、２６のサイズを増加させてもよい。また、レンダリングエンドポイント２４は、特定のトリックモードなどのメディア制御操作により、バッファ２８、３０、２６のサイズを増してもよい。
【００４６】
メモリが制約されたレンダリングエンドポイント２４は、追加のメモリが解放された（例えば、他のプロセスなどの完了のため）ことを示すメッセージ８０または９６を送ってもよい。サーバエンドポイント１２は、それに応じて、残っているメディア１８と利用可能なエンコーダとにより、応答メッセージ９０において、新しいバッファパラメータを送ってもよい。これにより、サーバエンドポイント１２は、より良いレートアダプテーションを提供できる。このシナリオのサブケースは、「増加するバッファサイズ」７６をサポートするレンダリングエンドポイント２４を含んでもよい。例えば、大きいメモリリソースを有するレンダリングエンドポイント２４（例えば、パーソナルコンピュータ）は、初めは、リアルタイムのメディア伝送より速い伝送を可能にするために、後に増加できるバッファサイズ７６を選択してもよい。
【００４７】
また、アダプティブバッファリングの仕組みのもう一つの側面では、応答メッセージ９０は、新しいバッファサイズ値９１が使用され始めるべきであるところで、メディアパケットに関連したＲＴＰシーケンス番号９２を含んでもよい。
【００４８】
他の実施例は、ＲＴＳＰ  ＧＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージ８０の使用を含んでもよい。ＧＥＴ＿ＰＡＲＡＭＴＥＲメッセージ８０は、レンダリングエンドポイント２４において現在のバッファサイズ７６を得るために、サーバエンドポイント１２によって使用されることが出来る。また、ＧＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージ８０は、現在伝送されているメディアストリームのために、サーバエンドポイント１２によって使用される現在のバッファパラメータを入手するために、レンダリングエンドポイント２４により使用される事も出来る。
【００４９】
上で説明したように、レンダリングエンドポイント２４における、総バッファサイズ７６、デジタルバッファ２８のための総デジタルバッファサイズ７０、プリデコーダバッファ３０のための総プリデコーダバッファサイズ６８も、また、ＲＴＰガイドラインで定義されるように、バッファファイル報告（Buffer File Report）（ＢＦＲ）ＲＴＣＰメッセージ９６の一部として、送ることが出来る。この場合、バッファ２６の総サイズを示すのに、追加のＲＴＣＰトランスポート層フィードバックメッセージを使用できる。また、レンダリングエンドポイント２４は、別々のデジタルバッファサイズ（ジッタバッファサイズ）７０とプリデコーダバッファサイズ６８（図４）とを指定できる。明白な規則が、どの現在のバッファパラメータを指定したらよいかを決定するために、レンダリングエンドポイント２４により使用され得る。
【００５０】
［ＳＤＰメディア属性］
１つの例におけるサーバエンドポイント１２は、最小バッファ要求を指定するために、以下のＳＤＰメディアレベル属性を使用できる。
【００５１】
ａ＝ ｐｒｅｄｅｃｂｕｆｓｉｚｅ．ｄｌｎａ．ｏｒｇ：＜値＞
これは、「デフォルト」／「推奨」のメディアストリームに対して、バイト単位で、必要な最小バッファサイズ（Ｂ）を指定する。
【００５２】
ａ＝Ｘ−ｍｉｎｉｎｉｔｉａｌｂｕｆｆｅｒｉｎｇ．ｄｌｎａ．ｏｒｇ：＜値＞
これは、レンダリングエンドポイントが、「デフォルト」／「推奨」のメディアストリームに対し提供するべき、最小初期バッファリング（Ｆ）を指定する。この値は、代わりに、時間単位で指定され得る。
【００５３】
ａ＝ａｄａｐｔａｔｉｏｎ−ｐｒｅｄｅｃｂｕｆｓｉｚｅ．ｄｌｎａ．ｏｒｇ：＜値＞
これは、メディアストリームを表現するレンダリングエンドポイントが、持たなければならない、バイト単位の、絶対最小バッファサイズ（Ｂｍｉｎ）を指定する。これは、サーバエンドポイントが、メディアストリームのレート変換をサポートするなら、あってもよい。レンダリングエンドポイント２４は、最初に、特定された推奨最小バッファサイズＢを使用してもよい。しかしながら、推奨最小バッファサイズＢが利用できないとき、レンダリングエンドポイント２４は、代わりに、絶対最小バッファサイズＢｍｉｎを使用できる。
【００５４】
ａ＝Ｘ−ａｂｓｍｉｎｉｔｉａｌｂｕｆｆｅｒｉｎｇ．ｄｌｎａ．ｏｒｇ：＜値＞
これは、ａ＝Ｘ−ａｂｓｍｉｎｂｕｆｓｉｚｅ．ｄｌｎａ．ｏｒｇ行の＜値＞により指定されたバッファサイズを使用するとき、レンダリングエンドポイント２４が提供するべき、バイト単位の、最小初期バッファリング（Ｆｍｉｎ）を指定する。この値は、代わりに、時間単位で指定され得る。この属性は、サーバエンドポイント１２がストリームのレート変換をサポートするなら、あってもよい。
【００５５】
［再生（ＰＬＡＹ）要求に対応して使用されるＲＴＳＰヘッダ］
Ｐｒｅｄｅｃ−Ｂｕｆｆｅｒ−Ｓｉｚｅ．ｄｌｎａ．ｏｒｇ：＜値＞
これは、サーバエンドポイント１２によって、レンダリングエンドポイント２４からの再生要求への応答として送られる、（＜値＞における）ＵＲＬにより指定されたメディアストリームに対して、バイト単位で、要求最小バッファサイズ（Ｂ）を指定する。
【００５６】
例えば、Ｐｒｅｄｅｃ−Ｂｕｆｆｅｒ−Ｓｉｚｅ：ｕｒｌ＝ｖｉｄｅｏ；ｓｉｚｅ＝７８２０００，ｕｒｌ＝ｖｉｄｅｏ；ｓｉｚｅ＝１８２４５
Ｉｎｉｔｉａｌ−Ｂｕｆｆｅｒｉｎｇ．ｄｌｎａ．ｏｒｇ：＜値＞
この値は、レンダリングエンドポイント２４からの要求に応答して、サーバエンドポイント１２により送られる、（＜値＞における）ＵＲＬにより指定されたメディアストリームに対して、レンダリングエンドポイント２４が提供するべき要求最小初期バッファリング（Ｆ）を、バイト単位でまたは時間単位で、指定する。
【００５７】
例えば、Ｉｎｉｔｉａｌ−Ｂｕｆｆｅｒｉｎｇ．ｄｌｎａ．ｏｒｇ：ｕｒｌ＝ｖｉｄｅｏ，ｔｉｍｅ＝１５００，ｕｒｌ＝ａｕｄｉｏ；ｔｉｍｅ＝１０００
［ＲＴＳＰ  ＳＥＴ＿ＰＡＲＡＭＥＴＥＲパラメータ］
ＰＭｉｎｂｕｆｓｉｚｅ．ｄｌｎａ．ｏｒｇ：＜値＞
このパラメータは、この時点以後にサーバエンドポイント１２により送られるメディアストリームに対して、バイト単位で、要求最小バッファサイズ（Ｂ）を指定する。
【００５８】
ＰＭｉｎｉｎｉｔｉａｌｂｕｆｆｅｒｉｎｇ．ｄｌｎａ．ｏｒｇ：＜値＞
このパラメータは、この時点以後にサーバエンドポイント１２により送られるメディアストリームに対して、レンダリングエンドポイント２４が提供するべき、要求最小初期バッファリング（Ｆ）をバイト単位で指定する。
【００５９】
ＢＦＲ−Ｓｉｚｅ．ｄｌｎａ．ｏｒｇ：＜値＞
これは、レンダリングエンドポイント２４における、デジタルバッファ２８、および／または、プリデコーダバッファ３０のサイズを指定する。
【００６０】
あるいはまた、上記のパラメータは、ＲＴＳＰ  ＯＰＴＩＯＮＳまたはＳＥＴ＿ＰＡＲＡＭＥＴＥＲまたはＡＮＮＯＵＮＣＥ方法を使用する代わりに、ＲＴＳＰヘッダを使用して送信され得る。
【００６１】
上で説明したシステムは、専用プロセッサシステム、マイクロコントローラ、プログラマブル論理デバイス、または操作のいくつかまたはすべてを実行するマイクロプロセッサを使用できる。上で説明した操作のいくつかが、ソフトウェアにより実装されてもよいし、他の操作がハードウェアにより実装されてもよい。
【００６２】
便宜上、操作は、様々な相互接続された機能ブロックまたは異なったソフトウェアモジュールとして記述されている。これは必要ではないが、しかしながら、これらの機能ブロックまたはモジュールが不明瞭な境界により、ただ一つの論理回路、プログラムまたは操作に同等に集められるケースがあってもよい。とにかく、フレキシブルなインタフェースの機能ブロックとソフトウェアモジュールまたは特徴は、それら自身により、またはハードウェアまたはソフトウェアのどちらかにおける他の操作との組合せにより、実装され得る。
【００６３】
本発明の原理を、その好適実施例において説明し示したので、本発明が構成と詳細とにおいて、そのような原理から逸脱せずに変更されてもよいのは、明らかであるべきである。私は、以下の請求項の精神および範囲に含まれるすべての修正および変更を請求する。
【図面の簡単な説明】
【００６４】
【図１】図１は、アダプティブバッファリングシステムの図である。
【図２】図２は、プリデコーダバッファの、より詳細なブロック図である。
【図３】図３は、バッファパラメータがどう異なったメディア再生コマンドに適合させられるかを示す図である。
【図４】図４は、デジタルおよび／またはプリデコーダバッファパラメータが、アダプティブバッファリングシステムを使用することでどう変化するかを示す図である。
【図５】図５は、アダプティブバッファリングシステムにおいて使用できる異なったメッセージプロトコルを示す図である。
【図３】
2008527765.tif 000003
【図４】
2008527765.tif 000004
【図５】
2008527765.tif 000005
【図１】
2008527765.tif 000006
【図２】
2008527765.tif 000007