(57)【要約】  待ちモード及び動的モードに従って、サーバからクライアントバッファを有するクライアントへのデータパケット送信を制御する技術が開示される。待ちモードは、現在のビットレートで符号化されたデータを含むパケットがクライアントバッファに到達するまで実行され、それ以外の場合に動的モードが実行される。待ちモードにおいて、より低いビットレートへのダウンスイッチは可能であるが、より高いビットレートへのアップスイッチは使用不可である。動的モードにおいて、現在のビットレートで符号化されたデータを含むパケットが最初にクライアントバッファに到達した時にクライアントバッファ内に含まれるデータ量に部分的に基づいて制御されるパケットのビットレートを調整することにより、アップスイッチ及びダウンスイッチの双方が可能である。２つのモードは、不必要なレート切り替えを回避する助けとなる。
2008537393.tif 000002
【特許請求の範囲】
【請求項１】
サーバ（１０５）からクライアントバッファ（１５５）を有するクライアント（１１５）への、可変ビットレート・データのパケット送信を制御する方法であり、前記クライアントバッファの状態に基づいて、前記サーバが、送信される可変ビットレート・データの種々のバージョンのストリームの間で切り替えを行なう方法であって、
送信する可変ビットレート・データの初期バージョンのストリームを選択するステップ（２０２）と、
前記クライアントバッファ内のデータ量を表す値（ＰＴ）を追跡するステップ（２０４）と、
前記選択されたバージョンのストリーム内の、送信される可変ビットレート・データの一部分のビットレート（ＢＲ）を判定するステップ（２０６）と、
送信される可変ビットレート・データの前記一部分の前記ビットレート（ＢＲ）と、前記クライアントバッファ内の前記データ量を表す前記値（ＰＴ）との組合せに基づいて、種々の平均ビットレートを有する前記種々のバージョンのストリームへの切り替えを制御するステップ（２１２）と、
を有する方法。
【請求項２】
切り替えを制御する前記ステップ（２１２）は、
送信される可変ビットレート・データの次の部分のビットレート（ＢＲNEXT）が平均ビットレート（ＢＲAVE）を超える場合に、一般により高いビットレートを有するバージョンの前記ストリームへの切り替えを遅延させるステップ（３１０）を含む、請求項１記載の方法。
【請求項３】
切り替えを制御する前記ステップ（２１２）は、
送信される可変ビットレート・データの次の部分のビットレート（ＢＲNEXT）が平均ビットレート（ＢＲAVE）を超える場合に、一般により低いビットレートを有するバージョンの前記ストリームへの切り替えを促進するステップ（３１４）を含む、請求項１記載の方法。
【請求項４】
切り替えを制御する前記ステップ（２１２）は、
送信される可変ビットレート・データの次の部分のビットレート（ＢＲNEXT）が平均ビットレート（ＢＲAVE）を下回る場合に、一般により高いビットレートを有するバージョンの前記ストリームへの切り替えを促進するステップ（３１０）を含む、請求項１記載の方法。
【請求項５】
前記サーバ（１０５）は、前記クライアントバッファに既に存在するデータに１つ以上の閾値を適用することにより、前記クライアントバッファ（１５５）の現在の状態に基づいて、前記種々のバージョンのストリームへの切り替えを制御し、
切り替えを制御する前記ステップ（２１２）は、
送信される可変ビットレート・データの前記一部分の前記ビットレート（ＢＲ）に基づいて前記１つ以上の閾値を動的に調整すること（３０６）と、
前記クライアントバッファ（１１５）内の前記データ量を表す前記値（ＰＴ）に１つ以上の調整可能な閾値を適用することにより、前記クライアントバッファ（１５５）の前記現在の状態に基づいて、前記異なるバージョンのストリームへ切り替えるか否かを判定することと、
を含む、請求項１記載の方法。
【請求項６】
前記１つ以上の閾値は、アップスイッチ閾値（ＰＴUP）とダウンスイッチ閾値（ＰＴDOWN）とのうち少なくとも一方を含む、請求項５記載の方法。
【請求項７】
前記１つ以上閾値を動的に調整する前記ステップ（３０６）は、
前記可変ビットレート・データの平均ビットレート（ＢＲAVE）を判定するステップと、
送信される可変ビットレート・データの次の部分のビットレート（ＢＲNEXT）と、前記可変ビットレート・データの平均ビットレート（ＢＲAVE）と、の比較に基づいて、前記アップスイッチ閾値（ＰＴUP）及び前記ダウンスイッチ閾値（ＰＴDOWN）を選択的に調整するステップ（３０６）と、
を含む、請求項６記載の方法。
【請求項８】
前記アップスイッチ閾値（ＰＴUP）及び前記ダウンスイッチ閾値（ＰＴDOWN）を選択的に調整する前記ステップ（３０６）は、
可変ビットレート・データの前記次の部分の前記ビットレート（ＢＲNEXT）が前記平均ビットレート（ＢＲAVE）を超える場合に、前記アップスイッチ閾値及び前記ダウンスイッチ閾値を増加するステップ（３０６）と、
前記可変ビットレート・データの前記次の部分の前記ビットレート（ＢＲNEXT）が前記平均ビットレート（ＢＲAVE）を下回るとともに、前記アップスイッチ閾値が前記ダウンスイッチ閾値を超える場合に、前記アップスイッチ閾値を減少するステップ（３０６）と、
を含む、請求項７記載の方法。
【請求項９】
可変ビットレート・データの前記次の部分の前記ビットレートが前記平均ビットレートを超える場合に、前記アップスイッチ閾値（ＰＴUP）及び前記ダウンスイッチ閾値（ＰＴDOWN）を増加する前記ステップは、
可変ビットレート・データの前記次の部分の前記ビットレートを判定するステップ（３０２）と、
可変ビットレート・データの前記次の部分の前記ビットレートの前記平均ビットレートに対する比（Ｆ）を計算するステップ（３０４）と、
前記アップスイッチ閾値（ＰＴUP）及び前記ダウンスイッチ閾値（ＰＴDOWN）を前記比と乗算すること（３０６）により前記閾値を増加するステップと、
を含む、請求項８記載の方法。
【請求項１０】
前記アップスイッチ閾値（ＰＴUP）を減少する前記ステップは、
可変ビットレート・データの前記次の部分の前記ビットレートを判定するステップ（３０２）と、
可変ビットレート・データの前記次の部分の前記ビットレートの前記平均ビットレートに対する比（Ｆ）を計算するステップ（３０４）と、
前記アップスイッチ閾値を前記比と乗算すること（３０６）により前記閾値を減少するステップと、
新しいアップスイッチ閾値として使用するために前記減少したアップスイッチ閾値及び前記ダウンスイッチ閾値のうち大きい方を選択するステップ（３１０）と、
を含む、請求項８記載の方法。
【請求項１１】
前記平均ビットレート（ＢＲAVE）は、送信される全てのバージョンの前記ストリームの平均ビットレートを表す、請求項２から１２のいずれか１項に記載の方法。
【請求項１２】
前記平均ビットレート（ＢＲAVE）は、送信される前記バージョンの前記ストリーム内の既に送信されたデータの平均ビットレートを表す、請求項２から１２のいずれか１項に記載の方法。
【請求項１３】
前記クライアントバッファのデータと関連付けられる前記値は、前記データの再生の長さ（ＰＴ）を表す、請求項１から１２のいずれか１項に記載の方法。
【請求項１４】
前記クライアントバッファのデータと関連付けられる前記値は、前記データのバッファ書込みレベルを表す、請求項１から１３のいずれか１項に記載の方法。
【請求項１５】
コンピュータプログラム製品がコンピュータシステム上で実行する場合、請求項１から１４のいずれか１項に記載のステップを実行するためのプログラムコード部分を有するコンピュータプログラム製品。
【請求項１６】
前記コンピュータプログラム製品は、コンピュータ可読記録媒体に格納される、請求項１５記載のコンピュータプログラム製品。
【請求項１７】
コンピュータプロセッサ及び前記プロセッサに結合されたメモリを備え、
当該メモリは、請求項１から１４のいずれか１項に記載のステップを実行できる１つ以上のプログラムと共に符号化される、装置。
【請求項１８】
サーバ（１０５）からクライアントバッファ（１５５）を有するクライアント（１１５）への可変ビットレート・データのパケット送信を制御する装置（４００）であり、前記サーバが前記クライアントバッファの状態に基づいて送信される可変ビットレート・データの種々のバージョンのストリーム間で切り替えを行なう装置であって、
送信のために可変ビットレート・データの初期バージョンのストリームを選択する予想可変ビットレートストリーム送信制御器（４０２）と、
前記クライアントバッファ内のデータ量を表す値を追跡するクライアントバッファ・モニタ（４０４）と、
前記選択されたバージョンの前記ストリーム内の送信される可変ビットレート・データの一部分のビットレート（ＢＲ）を判定する可変ビットレート判定ユニット（４０６）と、
を備え、
予想可変ビットレートストリーム送信制御器（４０２）は、送信される可変ビットレート・データの前記一部分の前記ビットレート（ＢＲ）と組み合わせて前記クライアントバッファ内の前記データ量を表す前記値（ＰＴ）に基づいて、種々の平均ビットレートを有する前記種々のバージョンのストリームへの切り替えを制御する装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データの通信に関し、特にストリーミングデータパケット送信を制御する技術に関する。
【背景技術】
【０００２】
パケットベースのインターネットプロトコル（ＩＰ：Internet Protocol）ネットワーク等の通信インフラストラクチャを介して、サーバからクライアントに送信されるデータ量は増加しつつある。普及しつつある１つの特定のアプリケーションは、マルチメディアストリーミングである。しかし、そのようなサービスを広範囲に採用する前に、信頼性のあるデータストリームの提供に対する改善が必要となる。例えば、ＩＰネットワークとユーザのクライアントデバイスとの間のデータ送信リンクレートが変動しやすいため、ユーザへのデータ配信における外乱は、エンドユーザにおける再生時の深刻な劣化、すなわちユーザにより確認されるメディアの品質の低下を招くだろう。特に、再生（すなわち、マルチメディア・アプリケーション又はプレーヤによるマルチメディアファイルの表示）の進行中、マルチメディア・アプリケーションにより取り出されるデータパケットがクライアントデバイスに十分に供給されることが重要である。
【０００３】
多くの場合、パケット送信レートは、通信リンクの帯域幅に依存するため（あるいは、パケット送信レートを変更することは少なくとも実用的でないため）変更不可能である。しかし、データがユーザの出力装置に供給されるレート（速度）は変更される必要がある。通常、ストリーミングアプリケーションの場合、そのような調整は「ストリーム切り替え」を使用して達成される。ストリーム切り替えにより、特定のビデオシーケンス等の同一のメディアコンテンツは、異なるビットレートで事前に符号化され、サーバに格納される。従って、種々のバージョンの同一ストリームが利用可能である。送信中、サーバは、ネットワークの現在利用可能な帯域幅及びクライアントバッファの状態に基づいて、最適なデータビットレートを有する特定のバージョンを選択する。サーバにより採用される切り替えロジックは、別のバージョンのストリームに切り替えるか否か及びその切り替えの時期を決定する。いわゆる「ダウンスイッチ」の場合、ストリームは、より低い符号化ビットレートのバージョンに切り替えられる。「アップスイッチ」の場合、より高い符号化ビットレートのバージョンに切り替えられる。多くの実現例において、切り替えの基準は、クライアントバッファ状態に対して規定された所定の閾値を採用する。一例において、閾値は、クライアントバッファ内のデータ量をバイトで表すバッファ書込みレベルに基づく。別の例において、閾値は、クライアントバッファ中の格納されたメディアの再生の長さ（ＰＴ）に基づく。再生の長さは、既にクライアントバッファ内にあるデータがユーザに対して再生されるのにかかる時間を秒で表す。本明細書において、バッファ書込みレベル又は他の適切なパラメータが使用されてもよいが、再生の長さに関する例を説明する。
【０００４】
クライアントバッファの状態を判定する従来の技術は、リアルタイム転送制御プロトコル（ＲＴＣＰ：Real Time Transport Control Protocol）受信者レポート（ＲＲ：Receiver Report）内の情報を利用する。クライアントバッファ内の次のシーケンス番号（ＮＳＮ：Next Sequence Number）又はバッファリングされた最も古いシーケンス番号（ＯＢＳＮ：Oldest Buffered Sequence Number）、並びにクライアントバッファ内の最大の受信シーケンス番号（ＨＲＳＮ：Highest Received Sequence Number）に関する情報はＲＲと共に含まれ、ＨＲＳＮからＮＳＮ／ＯＢＳＮまでの範囲内の各パケットのサイズが周知であるため、その情報は消費されたバッファ空間を判定するために使用される。クライアントバッファ内の空きスペースが好適なクライアントバッファ書込みレベルを下回る場合、異なるバージョンのストリームが選択される。例えば、バッファの再生の長さ（ＰＴ）が所定の最小閾値（ＰＴDOWN）を下回る場合、バッファが空になる危険性が起こる。すなわち、クライアントバッファが空になるため、ユーザにストリームするデータが存在しない。その結果、再生はフリーズする。この時、十分な量の追加のデータがクライアントバッファに追加されてユーザにより採用される出力装置へのストリームを再開できるまで、通常、ユーザに対して表示された最後の画像がフリーズされる。すなわち、クライアントバッファの「再バッファリング（rebuffering）」が必要とされる。再バッファリングは、ユーザの立場からすると非常に煩わしい。
【０００５】
クライアントバッファが空になっていくために起こる再バッファリングの可能性を回避するために、サーバは、クライアントバッファ内の再生の長さ（ＰＴ）が閾値ＰＴDOWNを下回る時期を検出し、クライアントバッファが完全に空になることを防止しようとする際にビットレートを調整する（すなわち、異なるビットレートを有するバージョンのストリームを選択する）。更に詳細には、サーバは、ダウンスイッチ、すなわちより低いビットレートストリームへの切り替えを実行する。アップスイッチではなくダウンスイッチが実行される理由は、クライアントバッファが徐々に空になっていく理由がサーバとクライアントバッファとの間のリンクレートが予想より低速なことであるからである。すなわち、有効な帯域幅は、現在使用されているビットレートに対して必要な帯域幅より小さい。その結果、データは、クライアントバッファがユーザの出力装置にデータを供給するレートと同一のレートでクライアントバッファにより受信されない。従って、データが十分に読み込まれた状態であるべきクライアントバッファは徐々に空になっていく。より低いビットレートに切り替えることにより、クライアントバッファはより低速でディスプレイユニットにデータを供給し、より多くの時間をかけてデータをサーバから受信することを可能にする。これにより、クライアントバッファが完全に空になるのを防止する。ユーザの立場からすると、メディアストリームの品質はダウンスイッチのために低下する。例えば、ビデオストリームの表示画像のサイズが小さくなり、画像の解像度が低下し、あるいは画像においてより大きな歪みが観察される。しかし、これは再バッファリング中に発生する上述の再生のフリーズより好ましい。
【０００６】
一方、バッファの再生（ＰＴ）の長さが所定の最大閾値（ＰＴUP）を超える場合、バッファがオーバフローする危険性が発生する。すなわち、クライアントバッファが一杯になるため、追加のパケットに対する空間が存在しない。通常、クライアントバッファにより受信されるがクライアントバッファには格納されないパケットはサーバにより再送出されないため、それらパケットのデータはユーザの出力装置に転送されない。クライアントバッファがパケットを再び格納できるようになると、データストリームは新しいパケットを含んで再開する。ユーザの立場からすると、ストリームが先へ跳ぶため、コンテンツは突然失われる。フィルム又は映画の場合、対話部分が失われ、ユーザが物語の筋を把握できなくなる。音楽の場合、単に曲が先へ跳ぶ。明らかに、これはユーザの立場からすると非常に煩わしい。
【０００７】
クライアントバッファのオーバフローのために起こるストリームの中断を回避するために、サーバは、クライアントバッファ内の再生の長さ（ＰＴ）が閾値ＰＴUPを超える時期を検出し、アップスイッチ、すなわちより高いビットレートストリームへの切り替えを実行する。ダウンスイッチではなくアップスイッチが実行される理由は、クライアントバッファが一杯になっていく主な理由がサーバとクライアントバッファとの間のリンクレートが予想より高速なことであるからである。すなわち、有効な帯域幅は、現在使用されているビットレートに対して必要な帯域幅より大きい。その結果、データは、クライアントバッファがユーザの出力装置にデータを供給するレートより高速なレートでクライアントバッファにより受信される。従って、クライアントバッファはオーバフローする。より高いビットレートへ切り替えることにより、クライアントバッファはより高速で出力装置にデータを供給し、クライアントバッファがオーバフローするのを防止する。ユーザの立場からすると、メディアストリームの品質はアップスイッチのために向上する。例えば、ビデオストリームの表示画像のサイズは大きくなり、あるいは画像の解像度は大きくなる。従って、アップスイッチは、ストリームの中断を防止するのを助長し、メディア品質を向上する。それらは双方ともユーザにとって利点である。
【０００８】
アップスイッチ及びダウンスイッチを実行する簡単なロジックは、以下のように表される：
If PT ＞ PTUP then
Perform up-switch
else if PT ＜ PTDOWN
Perform down-switch
end if
【０００９】
それら閾値の適切な選択は、ユーザのメディアの印象全体にとって重要である。ダウンスイッチを実行するのが遅すぎる場合、再バッファリングイベントが起こる。アップスイッチを実行するのが遅すぎる場合、ユーザは必要な品質より低い品質のメディアを受信し、上述のように、データストリームの中断がバッファオーバフローの結果として発生する可能性がある。同様に、ダウンスイッチが必要以上に早く実行される場合、ユーザは必要な品質より低い品質のメディアを受信する。アップスイッチが必要以上に早く実行される場合、ダウンスイッチがすぐに要求され、メディアの品質の煩わしい変動を招く。これら問題を回避するために、複数のダウンスイッチ閾値及び複数のアップスイッチ閾値が潜在的に使用される。再生の長さが減少し、バッファが空になっていくと、バッファ量は各々がダウンスイッチをトリガする一連のダウンスイッチ閾値を下回る。これに対し、バッファのオーバフローに向かって再生の長さが増加すると、バッファ量は各々がアップスイッチをトリガする一連のアップスイッチ閾値を超える。
【００１０】
しかし、切り替えが発生し、新しいビットレートを有するストリームが送信された後、その切り替えがクライアントバッファの再生の長さに影響を与えるまでに時間がかかる。まず、新しいレートで符号化されたデータを含む第１のパケットがクライアントバッファに到達するまでの送信遅延がある。この期間中、クライアントバッファ中の格納されたメディアの再生の長さは新しいレートにより影響を受けない。従って、再生の長さがバッファのオーバフローに向かって増加していた場合、再生の長さは増加し続ける。それに対し、再生の長さが減少し、バッファが空になっていく場合、再生の長さは減少し続ける。また、第１のパケットが新しいビットレートで到着した後でも、再生の長さは最初はゆっくりと変化するだけである。例えば、先のビットレートでデータと共に送出されたいくつかのパケットが存在する可能性があるが、それらはクライアントバッファによりまだ受信されていない。従って、切り替え条件は依然として有効である場合が多く、不必要である場合が多いいくつかの切り替えが第１の切り替えに続く。第１のダウンスイッチの場合、いくつかの更なるダウンスイッチが実行される可能性があり、必要なビットレートより非常に遅いストリームビットレートを結果として与える。多くの場合、ダウンスイッチは、最小ストリームビットレートが選択されるまで停止しない。この挙動の結果、ユーザにとって必要以上に低いメディアストリーム品質を与える。アップスイッチの場合、いくつかの更なるアップスイッチが発生する可能性があり、多くの場合に可能な最大レートである高すぎるストリームビットレートを結果として与える。従って、現在利用可能なネットワーク帯域幅と比較して非常に高すぎるストリームビットレートが得られ、一連のダウンスイッチをトリガする。
【００１１】
その結果、頻繁に起こるストリーム品質の煩わしい変動がユーザにより観察される。更に、非常に高すぎるビットレートが選択された場合、後続のダウンスイッチは十分に迅速に実行されず、煩わしい再バッファリングイベント及び再生のフリーズを招く。同様に、非常に低すぎるビットレートが選択された場合、後続のアップスイッチは十分に迅速に実行されず、煩わしいバッファオーバフロー及び関連するデータの損失を招く。単一のアップスイッチ閾値及び単一のダウンスイッチ閾値を使用しても、特にそれら閾値が近接しすぎて設定される場合には、その種の問題は発生する。
【００１２】
可変ビットレートを有するメディアコンテンツを送信する場合、更なる問題が発生する。従来、マルチメディアストリームの事前に符号化された各バージョンは単一のビットレートを有するため、既に説明したように、サーバがより高速又はより低速である異なるストリームに切り替える場合、ストリームのビットレートのみが変化する。しかし、いくつかの例において、特に大きなメディアファイルの格納及び送信に対応するために、変動するビットレートをストリームに提供するのが適切である。換言すると、各バージョンのストリームは、１つのビットレートの部分及び別のビットレートの他の部分を有してもよい。特定のバージョンのストリームの個々のセクションに対するビットレートは、個々のセクションのコンテンツに基づいて選択されるのが好ましい。例えば、ストリームの一部分は非常に静的であってもよく、低ビットレートでコンテンツを適切に取り込むことを可能にする。その後、より動的なコンテンツを適切に取り込むために、より高いビットレートが必要とされる。マルチメディアストリームの各部分のビットレートをストリームのその部分の動的なコンテンツに基づいて設定することにより、ファイル全体のサイズは減少するが、依然としてコンテンツを適切に搬送する。
【発明の開示】
【発明が解決しようとする課題】
【００１３】
従来のストリーム切り替え技術を可変ビットレートストリームに適用する場合、種々の問題が発生する。特に、ストリームのビットレートの変更は上述の問題を複雑にし、より頻繁に不必要な切り替えを招く。これは、ユーザにとって更なる煩わしさの原因になり、帯域幅を浪費することが多い。
【００１４】
従って、より安定した信頼性の高いコンテンツをユーザに提供するために、可変ビットレート・データのストリーム切り替えを制御する改善された技術が必要とされるため、本発明は主にその技術に関する。
【課題を解決するための手段】
【００１５】
本発明は、サーバからクライアントバッファを有するクライアントへの可変ビットレート・データのパケット送信を制御する方法に組み込まれてもよい。サーバは、クライアントバッファの状態に基づいて送信される可変ビットレート・データの種々のバージョンのストリーム間で切り替えを行なう。方法によると、可変ビットレート・データの初期バージョンのストリームが送信のために選択され、クライアントバッファ内のデータ量を表す値（ＰＴ）が追跡される。選択されたバージョンのストリーム内で送信される可変ビットレート・データの一部分のビットレート（ＢＲ：Bit Rate）が判定される。種々の平均ビットレートを有する種々のバージョンのストリームへの切り替えは、送信される可変ビットレート・データの一部分のビットレート（ＢＲ）と組み合わせてクライアントバッファ内のデータ量を表す値（ＰＴ）に基づいてサーバにより制御される。
【００１６】
一例において、送信されるデータの次の連続した部分のビットレート（ＢＲNEXT）が判定される。ＢＲNEXTが平均ビットレート（ＢＲAVE）を超える場合、切り替えを制御するステップが実行され、一般により高いビットレートを有するバージョンのストリームへの切り替えを遅延させる。すなわち、アップスイッチが遅延される。
【００１７】
別の例において、ＢＲNEXTが平均ビットレート（ＢＲAVE）を超える場合、切り替えを制御するステップが実行され、一般により低いビットレートを有するバージョンのストリームへの切り替えを促進する。すなわち、ダウンスイッチが促進される。
【００１８】
更に別の例において、ＢＲNEXTが平均ビットレート（ＢＲAVE）を下回る場合、切り替えを制御するステップが実行され、一般により高いビットレートを有するバージョンのストリームへの切り替えを促進する。すなわち、アップスイッチが促進される。
【００１９】
好適な一実現例において、サーバは、既にクライアントバッファにあるデータに１つ以上の閾値を適用することにより、クライアントバッファの現在の状態に基づいて、種々のバージョンのストリームへの切り替えを制御する。送信される可変ビットレート・データの一部分のビットレート（ＢＲ）に基づいて１つ以上の閾値を動的に調整し、クライアントバッファ内のデータ量を表す値（ＰＴ）に１つ以上の調整可能な閾値を適用することで、異なるバージョンのストリームへの切り替えを行なうかを判定することにより、切り替えを制御するステップは実行される。
【００２０】
好適な実現例の一例において、１つ以上の閾値はアップスイッチ閾値（ＰＴUP）及びダウンスイッチ閾値（ＰＴDOWN）を含む。１つ以上の閾値を動的に調整するステップは、可変ビットレート・データの平均ビットレート（ＢＲAVE）を判定し、送信される可変ビットレート・データの次の部分のビットレート（ＢＲNEXT）と可変ビットレート・データの平均ビットレート（ＢＲAVE）との比較に基づいてアップスイッチ閾値（ＰＴUP）及びダウンスイッチ閾値（ＰＴDOWN）を選択的に調整することにより実行される。アップスイッチ閾値及びダウンスイッチ閾値を選択的に調整するステップは、可変ビットレート・データの次の部分のビットレート（ＢＲNEXT）が平均ビットレート（ＢＲAVE）を超える場合にアップスイッチ閾値（ＰＴUP）及びダウンスイッチ閾値（ＰＴDOWN）を増加するステップを含む。アップスイッチ閾値及びダウンスイッチ閾値を選択的に調整するステップは、可変ビットレート・データの次の部分のビットレート（ＢＲNEXT）が平均ビットレート（ＢＲAVE）を下回るとともに、アップスイッチ閾値（ＰＴUP）がダウンスイッチ閾値（ＰＴDOWN）を超える場合に、アップスイッチ閾値（ＰＴUP）を減少するステップを更に含む。換言すると、ＰＴUPは、ＰＴDOWNを下回る場合には下方修正されない。
【００２１】
好適な実現例において、可変ビットレート・データの次の部分のビットレート（ＢＲNEXT）が平均ビットレート（ＢＲAVE）を超える場合にアップスイッチ閾値（ＰＴUP）及びダウンスイッチ閾値（ＰＴDOWN）を増加するステップは、可変ビットレート・データの次の部分のビットレート（ＢＲNEXT）を判定し、可変ビットレート・データの次の部分のビットレート（ＢＲNEXT）の平均ビットレート（ＢＲAVE）に対する比（Ｆ）を計算することにより実行される。アップスイッチ閾値（ＰＴUP）及びダウンスイッチ閾値（ＰＴDOWN）は比（Ｆ）と乗算され、それにより閾値を増加する。アップスイッチ閾値（ＰＴUP）を減少するステップは、可変ビットレート・データの次の部分のビットレート（ＢＲNEXT）を判定し、可変ビットレート・データの次の部分のビットレート（ＢＲNEXT）の平均ビットレート（ＢＲAVE）に対する比（Ｆ）を計算することにより実行される。アップスイッチ閾値（ＰＴUP）は比（Ｆ）と乗算され、それにより閾値を減少する。減少したアップスイッチ閾値（ＰＴUP＊Ｆ）及びダウンスイッチ閾値（ＰＴDOWN）のうち大きい方が、新しいアップスイッチ閾値として使用するために選択される。
【００２２】
種々の実現例において、クライアントバッファ内のデータ量を表す値は、データの再生の長さ（ＰＴ）又はバッファ書込みレベルを表す。平均ビットレート（ＢＲAVE）は、送信されるバージョンのストリーム全体にわたる平均ビットレートを表してもよく、あるいは送信されるバージョンのストリーム内で既に送信されたデータの平均ビットレートを表してもよい。
【００２３】
実現例によって、クライアントは移動電話等の移動通信端末であってもよい。それに加えて又はその代わりに、サーバは、サーバとネットワークとの間のリンクが無線であってもよいように移動通信端末に組み込まれてもよい。更に、本発明による方法は、サーバとクライアントとの間に配置される１つ以上の中間ネットワークノード（プロキシ等）により実行されてもよい。方法は、クライアントバッファ（又はクライアントの構成によっては複数のクライアントバッファ）に複数のデータストリームをバッファリングする構成において利用されてもよい。
【００２４】
本発明は、コンピュータ可読記録媒体に格納されるコンピュータプログラム製品に組み込まれてもよい。コンピュータプログラム製品は、コンピュータシステム上で実行する場合、上記方法の任意のステップを実行するプログラムコード部分を含む。
【００２５】
本発明は、コンピュータプロセッサ及びプロセッサに結合されたメモリを具備する装置を更に含んでもよい。ここで、メモリは、上記方法の任意のステップを実行できる１つ以上のプログラムと共に符号化される。
【００２６】
更に別の実施形態において、本発明は、サーバからクライアントバッファを有するクライアントへの可変ビットレート・データのパケット送信を制御する装置に関する。サーバは、クライアントバッファの状態に基づいて送信される可変ビットレート・データの種々のバージョンのストリーム間で切り替えを行なう。装置は、送信するために可変ビットレート・データの初期バージョンのストリームを選択する予想可変ビットレートストリーム送信制御器と、クライアントバッファ内のデータ量を表す値を追跡するクライアントバッファモニタと、選択されたバージョンのストリーム内の送信される可変ビットレート・データの一部分のビットレート（ＢＲ）を判定する可変ビットレート判定ユニットとを備え、予想可変ビットレートストリーム送信制御器は、送信される可変ビットレート・データの一部分のビットレート（ＢＲ）と組み合わせてクライアントバッファ内のデータ量を表す値（ＰＴ）に基づいて、種々の平均ビットレートを有する種々のバージョンのストリームへの切り替えを制御する。
【００２７】
装置は、ネットワークサーバと無線端末との少なくともいずれか等の、固定又は移動ネットワーク・コンポーネントとして構成されてもよい。更に装置は、プロキシ等の中間ネットワークノードにより構成されてもよい。
【発明を実施するための最良の形態】
【００２８】
以下において、図示される実施形態を参照して本発明を説明する。
【００２９】
以下において、本発明を完全に理解するために、特定のステップの順序及び種々の構成等の特定の詳細を説明の目的で示すがそれに限定されない。本発明がそれら特定の詳細とは異なる他の実施形態において実現されてもよいことは、当業者には明らかとなるだろう。更に、以下に説明される機能は、プログラムされたマイクロプロセッサ又は汎用コンピュータと共に機能するソフトウェアと、特定用途向け集積回路（ＡＳＩＣ：Application Specific Integrated Circuit）との少なくともいずれかを使用して実現してもよいことが、当業者には理解されるだろう。また、本発明は、方法として主に説明されるが、コンピュータプロセッサ及びプロセッサに結合されたメモリを具備するシステム又は装置、並びにコンピュータプログラム製品に組み込まれてもよいことが更に理解されるだろう。尚、メモリは、本明細書において開示される方法を実行できる１つ以上のプログラムと共に符号化される。
【００３０】
図１は、本発明に関連して使用されるアーキテクチャの例１００を示し、ＩＰネットワーク１１０等の通信経路を介してクライアント１１５と結合されてもよいサーバ１０５を含む。サーバは、ＲＴＰ（Real time Transport Protocol：リアルタイム転送プロトコル）ｏｖｅｒ ＵＤＰ、又は、マルチメディアデータのリアルタイム送信を管理する（ＵＤＰ−ユーザデータグラムプロトコル等のトランスポート層プロトコルを使用して）他のデータ転送プロトコル等のストリーミング標準を使用するＲＰＴ／ＵＤＰモジュール１２５を介して、ある特定のメディアコンテンツ（例えば、マルチメディアデータファイル）にアクセスし、送信するメディアコンテンツモジュール１２０を含む。パケットは、パブリック・ネットワーク１３０（例えばインターネットであるが、サーバがオペレータ・ネットワーク１３５に直接結合される場合、外部パブリック・ネットワークは不要である）に送信され、パブリック・ネットワーク１３０は、それに結合された移動通信オペレータ「有線」ネットワーク等のオペレータ・ネットワーク１３５にパケットを配信する。
【００３１】
オペレータ・ネットワーク１３５は、サーバ１０５とクライアント１１５との間の通信リンクを提供するコアネットワーク１４０を含む。オプションとしてバッファを有してもよいコアネットワーク１４０は、無線送信機１５０による送信の前に、無線アクセスネットワーク（ＲＡＮ：Radio Access Network）１４５内のバッファ（ＳＧＳＮ又はＲＮＣのバッファ等）にバッファリングするためにＲＴＰ／ＵＤＰモジュール１２５から受信したパケットを提供する。コアネットワーク１４０（バッファリングが利用される場合）及びＲＡＮ１４５のバッファは直列に配置され、ネットワークバッファを構成する。
【００３２】
クライアント１１５は、無線送信機１５０により送信されるパケットをクライアントバッファ１５５において受信する。パケットは、メディア・アプリケーションモジュール１６５（又はマルチメディアプレーヤ）に配信して使用するためにクライアントバッファ１５５からＲＴＰ／ＵＤＰモジュール１６０に転送される。この応用例の目的のために、「パケット送信レート」という表現は、サーバ１０５からＩＰネットワーク１１０へのパケットの送信のレート（速度）を示し、「リンクレート」という表現は、ＩＰネットワーク１１０からクライアント１１５へのパケットの送信のレートを示し、「コンテンツレート」という表現は、データがメディア・アプリケーションモジュール１６５による再生のためにクライアントバッファ１５５からメディア・アプリケーションモジュール１６５に転送されるレートを示す。
【００３３】
図２を参照すると、例えば図１のシステムにより実行されてもよい本発明の方法の実施形態２００を示す。方法は、図１のサーバ１０５等のサーバにより実行されるのが好ましいが、任意の他の適切なネットワーク・コンポーネントにより実行されてもよい。以下の説明において、サーバが方法のステップを実行すると仮定する。ステップ２０２で開始すると、サーバは、送信のために可変ビットレート・データの初期バージョンのストリームを選択する。ストリームの初期バージョンは、一般に異なる事前符号化送信レートを有する種々のバージョンのストリームのグループから従来技術に従って選択される。例えば、第１のストリームは、１メガビット（Ｍｂｉｔ）／秒のビットレートで開始してもよく、第２のストリームは２Ｍｂｉｔ／秒のビットレートで開始してもよい。ストリーム自体が可変ビットレートを有するため、同様に、各バージョンのストリームも可変ビットレートを有する。従って、いずれのバージョンのストリームが選択されても、ストリーム内で符号化されたデータのビットレートは変化する。例えば、第１のバージョンのストリームは１０秒後に２Ｍｂｉｔ／秒のビットレートに切り替わってもよく、第２のバージョンのストリームは１０秒後に３メガビットＭｂｉｔ／秒のビットレートに切り替わってもよい。すなわち、双方のバージョンのストリームは、１０秒後に１Ｍｂｉｔ／秒増加する事前符号化ビットレートを有する。
【００３４】
単一ビットストリームの３つのバ−ジョンの例を図３に示す。各バージョンのストリームは、時間と共に変動するビットレートを有する。全てのバージョンは互いに同期する。すなわち、全てのビットレートは同時に増加するか又は同時に減少する。しかし、種々のバージョンのストリームの平均ビットレートは互いに異なる。サーバは、種々のバージョンのストリーム間で切り替えを行なうことによりアップスイッチ及びダウンスイッチを実行する。図３の例において、３つのバージョンのストリームのみを示す。通常、より多くのバージョンが事前に格納される。また、この例において、最大ビットレートのバージョン２０５のストリームの最小ビットレートは、次のバージョン２０７のストリームの最大ビットレートより高速である。同様に、バージョン２０５のストリームの最小ビットレートは、バージョン２０９の最大ビットレートより高速である。しかし、これに限定されない。多くの場合、ビットレートのオーバラップが存在する。この例において、レートの変化は円滑であるように示される。すなわち、レートは、最大値まで円滑に増加し、その後円滑に減少する。しかし、これに限定されない。多くの例において、ビットレートは不連続に変化する。すなわち、レートは、１つのレベル（例えば１Ｍｂｉｔ／秒）から異なるレベル（例えば２Ｍｂｉｔ／秒）に急激に変化する。
【００３５】
図２に戻ると、ステップ２０２において、選択されたバージョンのストリームは、バージョンのストリームから事前符号化データを取得し、その事前符号化データをデータパケットに置くことによりサーバからクライアントに送信される。データパケットは、所定のパケット送信レートでクライアントに送信される。尚、送信されるストリーム内の可変ビットレート・データのビットレートの変化は、通常、帯域幅を考慮して判定されるパケット送信レートの変化を必要としない。同様に、１つのバージョンのストリームを別のバージョンに対して選択することは、通常、パケット送信の変更を伴わない。
【００３６】
ステップ２０４において、サーバは、現在クライアントバッファ内にあるデータ量を表す値を追跡する。これもまた、従来技術に従って実行されてもよい。一例において、クライアントバッファがＲＴＣＰプロトコルに従って実現される場合、サーバは、クライアントバッファからフィードバックを受信する。フィードバックはＮＳＮ／ＯＢＳＮ及びＨＲＳＮデータフィールドを含み、クライアントバッファのデータ量はそのフィードバックから判定される。上述のように、クライアントバッファのデータ量は、例えば再生の長さ（ＰＴ）、クライアントバッファ書込みレベル又は他の適切な値によって表されてもよい。以下の説明において、再生の長さ（ＰＴ）を使用していくつかの例を説明する。
【００３７】
ステップ２０６において、サーバは送信される可変ビットレート・データの一部分のビットレート（ＢＲ）を判定する。サーバが検査するのは、送信されるデータの次の連続した部分であるのが好ましい。すなわち、サーバは送信されるデータの次の部分のビットレートを表す値（ＢＲNEXT）を判定する。データの次の部分は、例えば送信される所定の秒数分のデータに対して規定されてもよく、あるいはデータの次の事前設定済み変更までに送信されるデータからのデータの部分として規定されてもよい。例えば、可変ビットレート・データの事前符号化ストリームが別のビットレートに切り替わるまでの次の１２秒間現在のビットレートを維持する場合、データの次の部分は次の１２秒間分のデータを含む。
【００３８】
図４は、送信される可変ビットレート・データのストリームの一例であるバージョン２０８を示す。ストリームは、ＢＲ#1、ＢＲ#2、ＢＲ#3、ＢＲ#4等で示される種々のビットレートの部分を含む。ＢＲ#1及びＢＲ#3は、例えば双方とも１Ｍｂｉｔ／秒であってもよく、ＢＲ#2及びＢＲ#4は、例えば双方とも２Ｍｂｉｔ／秒であってもよい。図示するように、部分は、異なる長さ、すなわち異なる期間であってもよい。この例において、矢印２１０は現在送信されているデータに対応するストリーム内の地点を示す。従って、データの次の部分は地点２１０で開始するデータである。そのデータのレートはＢＲ#2である。データの次の部分がデータの次の事前設定済み変更までに送信されるデータからのデータの部分に対して規定される場合、ＢＲNEXTは単純にＢＲ#2である。あるいは、データの次の部分が送信される所定の秒数分のデータに対して規定される場合、データの次の部分は２つ以上の異なるビットレートを含んでもよい。この場合、サーバは、ＢＲNEXTとして使用するために第１のビットレートを単純に選択するように構成されてもよく、あるいはＢＲNEXTとして使用するために所定の期間にわたる平均ビットレートＢＲAVEを計算するように構成されてもよい。いずれの場合においても、送信されるデータのある部分のビットレートを表す値は、図２のステップ２０６において判定される。
【００３９】
図２のステップ２１２において、サーバは、現在クライアントバッファ内にあるデータ量を表す値（ＰＴ）及び送信される可変ビットレート・データの部分のビットレート（ＢＲ）に基づいて、種々の平均ビットレートを有する種々のバージョンのストリームへの切り替えを制御する。例えばサーバは、ＰＴ及びＢＲNEXTの双方に基づいてアップスイッチ及びダウンスイッチを制御する。ＰＴに加えて送信されるデータのビットレートを考慮することにより、サーバは、固定レート切り替え閾値のみを採用する従来のシステムにおいて発生する多くの不必要なレート切り替えを回避できる。
【００４０】
ＢＲNEXTがＢＲAVEを超える場合、クライアントバッファの状態の変化によるアップスイッチは遅延されるのが好ましい。換言すると、クライアントバッファ内の再生の長さの増加が一般により速い送信レートを有する異なるバージョンのストリームへの切り替えをトリガする場合、その切り替えは遅延される。可変ビットレートがいずれにしても増加することになっているストリームの地点の前に、アップスイッチがサーバにより実行される場合、アップスイッチは逆効果であり、補正のダウンスイッチを必要とする可能性がある。この点に関して、可変ビットレートストリームのビットレートが増加するストリームの地点の前にアップスイッチを実行することにより、２つのビットレートの増加が順に発生する。その結果、ビットレートは必要以上に大きくなり、バッファが空になる可能性を防止するために補正のダウンスイッチをトリガする可能性が高い。可変ビットレート・データのビットレートがいずれにしても増加することになっている状況においてアップスイッチを遅延させることにより、サーバは不必要なアップスイッチ及びそれに後続する補正のダウンスイッチを回避する。それにより、より安定したレベルのメディア品質をエンドユーザに提供する。
【００４１】
また、ＢＲNEXTがＢＲAVEを超える場合、クライアントバッファの状態の変化によるダウンスイッチが促進されるのが好ましい。換言すると、クライアントバッファ内の再生の長さの減少が一般により遅い送信レートを有する異なるバージョンのストリームへの切り替えをトリガした場合、可変ビットレートが増加することになっている時にその切り替えは促進される。送信されるデータのビットレートが増加することになっている状況においてダウンスイッチを促進することにより、サーバは再バッファリングイベントの可能性を防止するのを助長する。一方、ストリーム自体のビットレートを増加することによりバッファが空になっていくのを加速すると仮定すると、サーバが可変ビットレート・データ内のビットレートの増加を予想しなかった場合、再生の長さが従来の固定ダウンスイッチ閾値（ＰＴDOWN）を下回ることによりダウンスイッチをトリガするのでは再バッファリングを防止するには遅すぎる可能性がある。
【００４２】
ＢＲNEXTがＢＲAVEを下回る場合、クライアントバッファの状態の変化によるアップスイッチが促進されるのが好ましい。換言すると、クライアントバッファ内の再生の長さの増加が一般により速い送信レートを有する異なるバージョンのストリームへの切り替えをトリガする場合、可変ビットレートが減少することになっている時にその切り替えは促進される。送信されるデータのビットレートが減少することになっている状況においてアップスイッチを促進することにより、サーバはオーバフローイベントの可能性を防止するのを助長する。一方、ストリーム自体のビットレートを減少することによりバッファのオーバフローを加速すると仮定すると、サーバが可変ビットレート・データ内のビットレートの減少を予想しなかった場合、再生の長さが従来の固定アップスイッチ閾値（ＰＴUP）を上回ることによりアップスイッチをトリガするのではバッファオーバフローを防止するには遅すぎる可能性がある。更に、促進されたアップスイッチは、改善されたメディア品質をより迅速にユーザに提供する。
【００４３】
しかし、ＢＲNEXTがＢＲAVEを下回る場合、クライアントバッファの状態の変化によるダウンスイッチは遅延されない（また、促進されない）のが好ましい。その場合、ダウンスイッチは、従来の固定ダウンスイッチ閾値（ＰＴDOWN）に基づいてトリガされるのが好ましい。可変ビットレート・データのビットレートがいずれにしてもすぐに減少することになっているということを考慮して、ダウンスイッチが潜在的に遅延されるが、本発明の好適な実現例において、バッファが空になる危険性を回避するためにダウンスイッチは実行されない。
【００４４】
次に図５を参照して、図２のステップ２１２において使用する可変ビットレートロジックの好適な実現例を説明する。ステップ３００で開始すると、サーバはＰＴUP及びＰＴDOWNに対する値を判定する。ＰＴUP及びＰＴDOWNは、所定の固定アップスイッチ閾値及び固定ダウンスイッチ閾値であってもよく、従来の技術に従って設定されてもよい。ステップ３０２において、サーバは、ＢＲNEXT及びＢＲAVEに対する値を判定する。ＢＲNEXTは、送信されるデータと関連する符号化ビットレートを検査することにより判定され、サーバ内に格納されるか又はサーバによりアクセスできる。一例において、ＢＲAVEは、既に送信された（種々のビットレートで符号化されたデータを含むパケットが送信される期間中に）データの符号化ビットレートのレコードを検査することにより計算される。実際の平均を計算するために、ルーチン計算が使用されてもよい。第２の例において、ストリーム全体に対するＢＲAVE値は、事前に計算され、格納されてもよい（個々のストリームがストリーミングセッションの開始前に符号化されるため、個々のＢＲAVE値は再生前に個々のストリームに対して判定されてもよい）。換言すると、第２の例において、ＢＲAVEは、既に送信されたデータの部分のみの平均ビットレートではなく、ストリーム全体にわたる平均を表す。すなわちＢＲAVEは、例えば図３に示される平均ビットレートである。
【００４５】
ステップ３０４において、サーバは、ＢＲNEXTのＢＲAVEに対する比を表す値Ｆ、すなわちＦ＝ＢＲNEXT／ＢＲAVEを計算する。従って、ＢＲNEXTがＢＲAVEを超える場合、Ｆは１．０より大きい。ＢＲNEXTがＢＲAVEを下回る場合、Ｆは１．０より小さい。ＢＲNEXTがＢＲAVEと等しい場合、Ｆは１．０と等しい。送信されたデータが存在しない（そのため、ＢＲAVEの現在の値が存在しない）場合、Ｆは単純に１．０に設定される。データの現在のストリーム内に送信されるデータが残っておらず、ＢＲNEXTに対する現在の値が存在しない場合、Ｆは送信されるデータの次のストリームと関連して使用するために１．０に再設定されるのが好ましい。
【００４６】
ステップ３０６において、サーバは、ＰＴUPにＦを乗算した値、すなわちＰＴUP＊Ｆと等しくなるように調整可能なアップスイッチ閾値（ＰＴUP-ADJ）を設定し、ＰＴDOWNにＦを乗算した値、すなわちＰＴDOWN＊Ｆと等しくなるように調整可能なダウンスイッチ閾値（ＰＴDOWN-ADJ）を設定する。従って、ＢＲNEXTがＢＲAVEを超える場合、ＰＴUP-ADJはＰＴUPより大きく、ＰＴDOWN-ADJはＰＴDOWNより大きい。従来、ＢＲNEXTがＢＲAVEを下回る場合、ＰＴUP-ADJはＰＴUPより小さく、ＰＴDOWN-ADJはＰＴDOWNより小さい。
【００４７】
それら閾値を図６に示す。図６は、図１のクライアントバッファ１１５を示すブロック図である。図６の例において、調整可能な閾値は対応する固定閾値より大きい。尚、ＰＴUP-ADJがクライアントバッファの最大値（ＭＡＸ）より大きくなるように計算される状況は潜在的に発生する。これは、ＢＲNEXTがＢＲAVEより非常に大きく、Ｆに対して大きい値を与える場合に発生する可能性がある。この場合、ＰＴUP-ADJは、単純にＭＡＸと等しくなるように設定されるか又は他のより小さいデフォルト値に設定される。発生する可能性は非常に少ないが、Ｆに対する値が非常に大きいためにＰＴDOWN-ADJがＭＡＸより大きくなるように計算される場合、ＰＴDOWN-ADJは、ＰＴUP-ADJが設定されるデフォルト値より小さいあるデフォルト値に設定されるのが好ましく、それによりＰＴDOWN-ADJがＰＴUP-ADJより小さいことを保証する。
【００４８】
図５を参照すると、ステップ３０８において、サーバは図２のステップ２０４で追跡されたＰＴに対する値、すなわちクライアントバッファ内に既に含まれるデータの現在の再生の長さを判定し始める。判定ステップ３１０において、ＰＴがＰＴDOWNより大きく、且つＰＴがＰＴUP-ADJより大きい場合、ステップ３１２においてアップスイッチがトリガされる。それ以外の場合、判定ステップ３１４が実行される。ステップ３１４において、ＰＴがＰＴDOWNより小さいか又はＰＴがＰＴDOWN-ADJより小さい場合、ステップ３１６においてダウンスイッチがトリガされる。
【００４９】
判定ステップ３１０及び３１４のロジックは、以下のように表される：
If PT ＞ PTDOWN AND PT ＞ PTUP-ADJ then
Perform up-switch
else
if PT ＜ PTDOWN OR PT ＜ PTDOWN-ADJ
Perform down-switch
end if
式中、上述したように以下の通りである。
PTUP-ADJ = PTUP*F  かつ
PTDOWN-ADJ = PTDOWN*F
【００５０】
従って、ＰＴがＰＴDOWNを超えると仮定すると、クライアントバッファの現在の再生の長さ（ＰＴ）が調整可能なアップスイッチ閾値（ＰＴUP-ADJ）を超える場合、アップスイッチはトリガされる。ＰＴがＰＴDOWNを超えるという条件は、ダウンスイッチがより適切である状況において不適切なアップスイッチを防止する。固定アップスイッチ閾値ではなく調整可能なアップスイッチ閾値に基づいてアップスイッチをトリガすることにより、サーバは、クライアントバッファの現在の状態（ＰＴにより表される）を考慮し、（アップスイッチ閾値の調整を介して）可変ビットレート・データストリーム内のビットレートの変化を予想する。これは、他の不適切なアップスイッチを防止するのを助長する。
【００５１】
調整可能なアップスイッチ閾値が最初は固定アップスイッチ閾値に全く等しい場合の一例を考慮する。クライアントバッファの再生の長さが閾値レベルを超える場合、アップスイッチは実行される。可変ビットレート・データのビットレートが増加することになっている場合、調整可能なアップスイッチ閾値は固定閾値より大きくなるように増加される。この時、再生の長さが新しいより大きな閾値を超える場合、更なるアップスイッチが実行される。換言すると、図１と関連して説明したように、より大きな閾値を超えるため、アップスイッチがトリガされるのは更に困難になり、遅延が保証される状況において更なるアップスイッチを遅延する。次に、調整可能なアップスイッチ閾値が固定アップスイッチ閾値と等しくなるように再び初期設定され、且つ可変ビットレート・データのビットレートが減少することになっている場合の一例を考慮する。この場合、調整可能なアップスイッチ閾値は固定閾値より小さくなる。この時、上述のように、アップスイッチがトリガされるのがより容易になり、保証される状況において更なるアップスイッチを促進する。
【００５２】
次にダウンスイッチを考慮すると、クライアントバッファの現在の再生の長さ（ＰＴ）が固定閾値ＰＴDOWN又は調整可能なダウンスイッチ閾値（ＰＴDOWN-ADJ）を下回る場合、ダウンスイッチはトリガされる。換言すると、ＰＴが２つのダウンスイッチ閾値の大きい方を下回る場合、ダウンスイッチはトリガされる。ダウンスイッチが遅延されるのを防止して、再バッファリングイベントを防止するのを助長するために、固定閾値はダウンスイッチをトリガするのに使用される。しかし、ダウンスイッチは促進される。これは、ＰＴが調整可能なダウンスイッチ閾値を下回る場合に発生する。上述のように、調整可能なダウンスイッチ閾値は、固定ダウンスイッチ閾値を上回っても下回ってもよい。固定閾値を下回る場合、固定閾値がいずれにしてもダウンスイッチをすぐにトリガするために使用されるため、調整可能なダウンスイッチ閾値は不要である。しかし、調整可能なダウンスイッチ閾値が固定ダウンスイッチ閾値を超える場合、調整可能なダウンスイッチ閾値は促進されたダウンスイッチをトリガできる。すなわち、上述のように、ダウンスイッチがトリガされるのがより容易になり、保証される状況において更なるダウンスイッチを促進する。
【００５３】
判定ステップ３１０及び３１４の条件がいずれも真でない場合、ステップ３０２に戻る。ＢＲNEXT及びＢＲAVEの値は変更を反映するために更新され、調整可能な閾値は調整され、ＰＴに対する最新の値は種々の閾値に適用するために入力される。
【００５４】
種々のバージョンの事前符号化ストリーム間で切り替えを行なうことにより、パケットを使用するシステムにおいてデータの送信レート全体を調整する技術の方法の実現例を説明した。パケット送信レートは、通信リンクの帯域幅に依存するため通常変更されない。しかし、他の実現例において、パケット送信レートは、例えば適応技術を使用して変更されてもよい。
【００５５】
主に方法の実現例を参照して本発明を説明したが、装置の実現例も本発明の一部である。図７は、装置の実現例を高レベルに示す。簡単に説明すると、図１のサーバ１０５の一部であってもよいネットワーク・コンポーネント４００は、送信するために可変ビットレート・データの初期バージョンのストリームを選択する（２０２）予想可変ビットレートストリーム送信制御器（４０２）を含む。クライアントバッファモニタ（４０４）は、クライアントバッファ内のデータ量を表す値を追跡する。可変ビットレート判定ユニット（４０６）は、選択されたバージョンのストリーム内の送信される可変ビットレート・データの一部分のビットレート（ＢＲ）を判定する。予想可変ビットレートストリーム送信制御器（４０２）は、送信される可変ビットレート・データの一部分のビットレート（ＢＲ）と組み合わせてクライアントバッファ内のデータ量を表す値（ＰＴ）に基づいて、種々の平均ビットレートを有する種々のバージョンのストリームへの切り替えを制御する。すなわち制御器４０２は、可変ビットレートストリームのビットレートの変化を予想し、それに従ってアップスイッチ及びダウンスイッチを制御する。
【００５６】
当業者には理解されるように、本発明及び本発明に関連する技術は、クライアントバッファのオーバフローを回避することによりマルチメディアストリーミング等のアプリケーションに対してエンドユーザが知覚する体験を向上する。更に、ＲＲ及び送信者レポート内のデータに基づく推定を含むクライアントバッファ書込みレベルを判定するために使用できる種々の技術が存在し、１つ以上のクライアントへの送信のために同時にバッファリングされる複数のデータパケットストリームと共に本発明が実現されてもよいことは、当業者には理解されるだろう。
【００５７】
本発明は、ネットワーク端末及びネットワークノード等の種々のネットワーク・コンポーネントにおいて実現されてもよく、また種々のネットワーク・コンポーネントにより実現されてもよいことが当業者には更に理解されるだろう。特に本発明は、移動端末、プロキシ（送信経路を分ける）及び固定端末により実現されてもよい。
【００５８】
特定の実施形態に関して本発明を説明したが、本発明は、本明細書において図示され、説明された特定の実施形態に限定されないことが当業者には理解されるだろう。従って、好適な実施形態に関連して本発明を説明したが、本開示は単なる例示であることが理解される。本発明は、添付の請求の範囲の範囲によってのみ限定されることが意図される。
【図面の簡単な説明】
【００５９】
【図１】本発明を理解し、実現するのに有用な通信システムを示す概略図である。
【図２】本発明の方法の実施形態の概要を提供する処理フローチャートである。
【図３】可変ビットレート・データの種々のバージョンのストリームを示し、特に種々のバージョンのストリームの種々の平均ビットレートを示すグラフである。
【図４】可変ビットレート・データの単一ストリームを示し、特にストリームの種々の部分のビットレートを示すブロック図である。
【図５】本発明の可変ビットレートロジックの実現例を示す処理フローチャートである。
【図６】クライアントバッファを示し、特に本発明により採用される種々の閾値を示すブロック図である。
【図７】本発明のサーバコンポーネントの装置の実現例を示すブロック図である。
【図１】
2008537393.tif 000003
【図２】
2008537393.tif 000004
【図３】
2008537393.tif 000005
【図４】
2008537393.tif 000006
【図５】
2008537393.tif 000007
【図６】
2008537393.tif 000008
【図７】
2008537393.tif 000009
【国際調査報告】
2008537393.tif 000010
2008537393.tif 000011