(57)【要約】パケットに基づくネットワーク上のクライアントに符号化されたビデオデータのストリームを提供する技術が記載されている。システムはネットワークの許容量における変動に適用することによってビデオストリームのビットレートを最大化することができる。該技術は送信された符号化されたビデオデータのビットレートの適用がビデオシーケンスの場面変化時に生じるように設定されることを特徴とする。この方法では、ビデオシーケンスの知覚品質が向上する或いは低下するときに場面変化において「隠されて」いるように視聴者に対する中断が最小化される。該技術は階層的に符号化されたビデオデータに適用されるように説明されるが、ネットワーク状況に適用する他の符号化技術に同等に適用されてもよい。【選択図】図５
2004536525.tif 000002
【特許請求の範囲】
【請求項１】
マルチメディアサーバ（２０２）を動作する方法であって、
前記マルチメディアサーバ（２０２）の出力にビデオシーケンスを表現するビデオデータのストリームを提供することとであって、該マルチメディアサーバ（２０２）の該出力がパケットベースのネットワーク（２０３）に接続されていることと、
前記ビデオシーケンスでの場面変化の発生を判断するために前記ビデオデータの特性を測定することと、
前記ネットワーク（２０３）で使用可能な帯域幅を検出することと、
ビデオデータのストリームのビットレートを変えることと、を備え、
前記ビデオデータのビットレートの変動が前記ネットワーク（２０３）の容量の変動に反応して、及び優先的に前記ビデオシーケンスの場面変化とともに発生するように制御されることを特徴とする方法。
【請求項２】
前記使用可能な帯域幅の減少の検出時に、前記ビデオデータのビットレートは減速される、請求項１記載のマルチメディアサーバ（２０２）を動作する方法。
【請求項３】
前記ビデオデータのビットレートは、前記使用可能な帯域幅のすべてが使用されていることを確実にするために定期的に増加される、請求項１記載のマルチメディアサーバ（２０２）を動作する方法。
【請求項４】
ビデオデータの前記ストリームは、複数の階層的に符号化された層から構成される、請求項１乃至請求項３記載のマルチメディアサーバ（２０２）を動作する方法。
【請求項５】
前記ビデオデータのビットレートは、出力ポートに転送されたデータのストリームから層を追加または削除することにより変えられる、請求項４記載のマルチメディアサーバ（２０２）を動作する方法。
【請求項６】
どの層が出力ポートに転送されたデータのストリームから追加または削除されるべきかを判断するために、前記ビデオシーケンスの総合的な質に対する各層の客観的な品質の貢献が測定される、請求項４または請求項５記載のマルチメディアサーバ（２０２）を動作する方法。
【請求項７】
ビデオデータの前記ストリームは、それぞれが異なるビットレートで符号化されている複数の独立して符号化されたフローから構成される、請求項１乃至請求項３記載のマルチメディアサーバ２０２を動作する方法。
【請求項８】
前記ビデオデータのビットレートは、独立して符号化されたフローの間で切り替えることによって変えられる、請求項７記載のマルチメディアサーバ（２０２）を動作する方法。
【請求項９】
ビデオデータのソース２０１がデータベースに符号化された形式で記憶される、請求項１乃至請求項８のいずれか１項に記載のマルチメディアサーバ２０２を動作する方法。
【請求項１０】
ビデオデータのソース２０１がリアルタイムで符号化される、請求項１乃至請求項８のいずれか１項に記載のマルチメディアサーバ２０２を動作する方法。
【請求項１１】
ビットレートの変化が発生するのを適切とするためなどのネットワークの容量の変動を検出すると、前記サーバは場面の変化の検出を試みるために所定の時間待機し、このような場面の変化が該所定の時間内に検出されると、ビットレートの変更が場面の変化時に引き起こされるが、場面の変化が該所定の時間内に検出されない場合には、ビットレートの変更が該所定の時間の満了時に引き起こされる、請求項１乃至請求項１０のいずれか１項に記載のマルチメディアサーバ２０２を動作する方法。
【請求項１２】
ビットレートの変化が発生するのを適切とするためなどのネットワークの容量の変動を検出すると、前記サーバは所定の時間内に場面の変化があるかどうかを判断し、該所定の時間内にこのような場面の変化があると判断される場合、ビットレートの変更が場面の変化時に引き起こされるが、該所定の時間内に場面の変化がないと判断される場合には、ビットレートの変更がこのような判断がなされた実質的に直後に引き起こされる、請求項１乃至請求項１１のいずれか１項に記載のマルチメディアサーバ２０２を動作する方法。
【請求項１３】
前記メディアサーバの出力にビデオデータのストリームを提供する前に、場面の変化が発生するビデオデータの中での位置を決定するためにビデオデータを処理し、場面変化がビデオデータのストリームに沿ったどんなポイントにても所定の時間内に発生するかどうかを可能にするためにこの情報を入手可能にする工程をさらに含む、請求項１２記載の方法。
【請求項１４】
ソース（３０１）からビデオシーケンスを表現するビデオデータを読み取るための読取装置（３０２）と、
前記ビデオシーケンス内の場面の変化を検出するための場面変化検出器（６０４）と、
前記読取装置から出力ポートに前記ビデオデータが転送される速度を制御するビットレートコントローラ（６０７）であって、該出力ポートはパケットネットワーク（２０３）上のクライアント（２０４）と通信することができるものと、
マルチメディアサーバ（２０２）とパケットネットワーク上のクライアント（２０４）の間の使用可能な帯域幅を検出するための手段（６０８）をさらに備えるメディアサーバと、を備えるマルチメディアサーバ（２０２）であって、
前記ビットレートコントローラ（６０７）は、前記場面変化検出器（６０４）により検出される場面変化と優先的に相関して、検出された帯域幅に依存して前記出力ポートに転送されるビデオデータのビットレートを変えるように構成されていることを特徴とするマルチメディアサーバ（２０２）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はパケットネットワークでのビデオストリーミングの分野にあり、特にネットワークの輻輳に応じたデータの適応伝送に関する。
【背景技術】
【０００２】
近年、インターネットでは、ライブで配信される、あるいは事前に記録されていたソースからのどちらかの主にストリーミングされた視聴覚コンテンツの形を取るリアルタイムマルチメディアの伝送が一般化してきている。さらにストリーミングと会議開催などの従来の形式のマルチメディアには、インターネットマルチチャネルテレビ及び複雑なイマーシブ(immersive)環境などのようなより豊富なコンテンツを有するアプリケーションが続いて来ている。このトラフィックの増加がネットワークに負担を課すため、ネットワークの安定性が維持されなければならない場合に輻輳(congestion)に対応するようにアプリケーションプログラムを設計することが望ましい。ネットワークの状態を監視し、出力ビットレートを使用可能な帯域幅に合わせて調整することが望ましい。
【０００３】
適応出力ビットレートを有することにはユーザにとってより直接的な優位点があり、それが、ネットワークが許可する最高の可能伝送ビットレートが使用されるため、ユーザがつねに最良の可能な画質を受け取るという点である。適応品質ビデオストリーミングに対する数多くのアプローチがあり、その内の１つが階層コーディング（coding）である。この技術では、オリジナルのビデオデータは層と呼ばれる多くのディスクリート（discreet）ストリームに符号化され、第１の層は相対的に質が悪い基本データから構成され、連続する層は、使用可能な帯域幅に応じて画質を高めるために層を追加できる、あるいは層を取り去ることができるようにさらに詳細な情報を表している。
【発明の開示】
【０００４】
あるセッションに使用可能なビットレートは送信される層の数の大幅な変動を受けるため、品質のばらつきは、層が追加または削除されるにつれて復号された画像で発生する。層が頻繁に追加または削除されると、品質のばらつきが視聴者にとって気がかりになり得る。
【０００５】
本発明の第１の実施形態においては、マルチメディアサーバを動作する方法が提供され、該方法は、
ビデオシーケンスを表すビデオデータのストリームを前記マルチメディアサーバの出力に提供することであって、該メディアサーバの該出力がパケットベースのネットワークに接続されていることと、
前記ビデオシーケンスにおける場面変化の発生を判断するために前記ビデオデータの特性を測定することと、
前記ネットワーク上で使用可能な帯域幅を検出することと、
ビデオデータのストリームのビットレートを変えることと、
を備え、
該方法は、前記ビデオデータのビットレートの変動が制御されて、前記ネットワーク（２０３）の容量の変動に反応して、及び優先的に前記ビデオシーケンスの場面変化とともに、発生することを特徴とする。
【０００６】
ここで優先的に使用される用語は、（さらに詳しく後述される）特定の状況において、ビデオストリームのビットレートを変える前にビデオシーケンスで発生する場面の変化を待機することが実践的ではない可能性があり、このような状況では、ビットレートは場面の変化に対応しないビデオストリームの中のポイントで変更されることを示すことを意味する。
【０００７】
用語「場面変化（または場面の変化）」は、実際の場面の変化があろうとなかろうと通常場面の変化時に発生するような１つまたは非常に少ないフレームの空間内でのビデオシーケンスの突然の変化を指すことが意図されている。
【０００８】
本発明の実施形態は、以下の図面を参照して例示としてのみによってここに説明される。
【発明を実施するための最良の形態】
【０００９】
既知の階層ストリーミング技術のためのクライアント／サーバ構成は図１に示されている。外部放送から「ライブで」送られてよいか、あるいは事前に圧縮され、データベースに記憶されてよい圧縮視聴覚データ２０１にアクセスできるメディアサーバ２０２が提供される。該データソース２０１はメディアサーバ２０２と同じ構内にあり、イントラネットを介してリンクされてよい。メディアサーバ２０２は、インターネット２０３にアクセスできる適切なサーバコンピュータ上で動作する。
【００１０】
これまでクライアント２０４と呼ばれていた、インターネット２０３にアクセスできるように適切に構成されたＰＣ上で動作しているビデオビューワは、インターネット２０３を介してメディアサーバ２０２に接続してよく、したがってクライアント２０４はコンテンツにアクセスできる。適切なＰＣ端末が使用される。
【００１１】
層化ビデオ圧縮は、Ｈ．２６３の１９９８で達成されるが、同等にＭＰＥＧ４などの他のコーデック(codec)であってよい。階層内の各層は、図２を参照して説明されるように、個々のピクチャの質を改善し、それらの解像度を高め、追加ピクチャを含めて全体的なピクチャレートを増加することができるように符号化される。図２はＨ．２６３スケラブル(scalable)層化コーダでのピクチャ間の典型的な依存性を描いており、ボックスは層ごとのフレームを表し、矢印はフレーム間の依存性を示している。最下行はオリジナルのコーディングされていないフレームを示している。次の行は層１のフレームレートの半分でコーディングされる階層の最下層（層０）を示している。層０のフレームは、従来のビデオ圧縮におけるように過去に符号化されたフレームから予測される。層１内のフレームは層１で過去に符号化されたフレーム、及び存在する場合には、一時的に同時の層０符号化フレームから予測されてよい。層２の中のフレームは層２の中で過去に符号化されたフレーム、及び存在する場合には一時的に同時の層１または層０符号化フレームから予測されてよい。Ｈ．２６３の仕様は１５の層に対応する。本実施形態では、サーバとクライアントのソフトウェアは使用可能な層の数で制限されないが、この場合データベースは４つの層を含むビデオストリームで生成されている。
【００１２】
図３はメディアサーバ２０１のアーキテクチャを示している。本実施形態では、視聴覚ソースは圧縮されたビデオデータのデータベース３０１であり、メディアサーバ２０１はデータベースから圧縮されたデータを読み取り、それをパケット化し、配信するのを担当している。データは、音声、ビデオまたはラミュレーションデータなどのリアルタイムデータを送信するアプリケーションに適したエンドツーエンド(end-to-end)ネットワークトランスポート機能を提供するリアルタイムトランスポートプロトコル（ＲＴＰ）に従って配信される。ＲＴＰはリソース予約に対処せず、リアルタイムサービスのサービスの質を保証しない。データトランスポートはデータ配信の監視を可能にし、最小の制御と識別機能性を提供するためにコントロールプロトコル（ＲＴＣＰ）によって増強される。ＲＴＰとＲＴＣＰは下にあるトランスポート層とネットワーク層とは無関係になるように設計されている。メディアサーバ２０１は４つの主要な構成要素を有している。つまり、データベース読取装置３０２、ビデオＲＴＰパケッタイザ（ｐａｃｋｅｔｉｓｅｒ）３０３、音声ＲＴＰパケッタイザ３０５、及びネットワークインタフェース３０４である。ビデオデータと音声データはデータベース３０１に圧縮されたビットのファイルとして記憶される。データベース読取装置３０２は該圧縮された音声とビデオをデータベース３０１から検索し、同期する。
【００１３】
音声データとビデオデータは次にＲＴＰパケッタイザ３０３、３０５に送信される。音声情報とビデオ情報は、ユーザデータグラムプロトコル（ＵＤＰ）とリアルタイムトランスポートプロトコル（ＲＴＰ）パケット化を使用してＩＰネットワーク上で送信される。ＵＤＰは伝送エラーを検出するためにチェックサム(checksum)を提供するが、データの配信は保証しない。つまり、パケットは失われたり、複製されたり、並べ替えられる可能性がある。ＲＴＰは、ペイロード型識別、シーケンスナンバリング、タイムスタンプ、及び配信監視などのエンドツーエンド配信サービスを提供する。ＲＴＰパケッタイザ３０３、３０５はＲＴＰヘッダを取り付け、またビデオパケットの場合では、パケット損失からのいくらかの保護を提供するＨ．２６３ペイロードヘッダを取り付ける。ペイロードヘッダは、圧縮されたビットストリームを復号することによって獲得される運動ベクトル予測値などのビデオストリームに対して特定した情報を含んでいる。
【００１４】
データがデータベース３０１から読み取られる速度は、図４にてさらに詳細に図示されるネットワークインタフェース３０４から制御される。図４を参照して、ビデオデータのためのネットワークインタフェース３０４の構成がここで説明される。パケットナンバリングモジュール４０１は、データの各パケットに番号を割り当てる。これらのパケット番号は、パケットを復号のために必要とされるシーケンスの中にアセンブル(assemble)するためにクライアントによって使用される。たとえ伝送速度が一定であっても、ピクチャを圧縮することにより生成されるビット数は一般的には一定ではない。新しい場面の第１のピクチャは通常、動きまたは詳細がほとんどないピクチャより多数のビットを生成するだろう。符号化プロセスは、一定のビットレートでの伝送に備えてこれらの変動を円滑化するために出力データバッファとともに制御戦略を使用するだろう。層化されたコーディングの場合、各層は、それが満たさなければならない独自の一定ビットレートの制約を有しているために、独自の制御戦略とバッファを有している。これらのバッファのそれぞれでの遅延は一定ではなく、層ごとに同じにはならないだろう。したがって、層の間の遅延の変動はデータのソースで導入される。ネットワーク全体での伝送はこの遅延変動を増加させる可能性がある。したがって、クライアントがそれが受信するパケットを復号のために必要とされる順序に並べることができることを確実にするためにパケットナンバリング方式が必要とされる。この方式は、層のすべて、及びそれが実際に受信する層のパケット損失のすべてを受信しないクライアントのケースを取り扱うように要求される。
【００１５】
各層はセッションハンドラ(session handler)４０３、４０５、４０７、４０９によって別個のＩＰアドレスで独立したＲＴＰセッションとして送信される。データが送信される速度は、所定の時間期間内に正しい番号が送信されることを確実にするために層０のバイトをカウントする転送速度制御モジュール４０２によって制御される。他の層の送信速度は円滑化され、先入れ先出し（ＦＩＦＯ）バッファ要素４０４、４０６、４０８を使用して層０のレートに固定される。
【００１６】
ここで既知の階層ストリーミング技術のクライアント２０４が図５を参照して説明される。符号化されたデータの各層に関連する各ＲＴＰ／ＲＴＣＰセッションはネットワークからＲＴＰパケットを受信することを担当するクライアントでセッションハンドラ５０１、５０２、５０３、５０４を有する。それから、パケットはソース非多重化(demultiplex)モジュール５０５に渡される。これはすべての層とすべてのソースからパケットを受信し、ソースによってそれらを非多重化し、それらをそのソースのブレンダ(blender)モジュール５０６、５０７にルーティングする。
【００１７】
ブレンダモジュール５０６、５０７はすべての層からのパケットを、それらがネットワークから受信された順序で、あるソースから受信する。これはパケット到着間ジッタ(jitter)またはパケット損失のために復号化に必要とされる順序ではない可能性がある。ブレンダモジュール５０６、５０７は各層からのパケットを順番に並べるためにＲＴＰヘッダ内でパケット番号を使用し、次にすべての層からのパケットを互いに結合する。ブレンダモジュール５０６、５０７の出力は復号のための正しい順序であるパケットの単一ストリームである。これは、メディアサーバ２０２のパケットナンバリングモジュール４０１から出てくるのと同じ順序である。
【００１８】
次に、パケットは、パケットが音声サンプルの２０ｍｓブロックまたはビデオピクチャに復号されるデコーダ５０８、５０９に送信される。ピクチャの場合、これらはディスプレイ５０８上でウィンドウにレンダリングされる(rendered)。
【００１９】
セッションハンドラ５０１〜５０４がパケットの損失を報告する輻輳(congestion)マネージャ５１１も設けられている。パケットが相次いで失われ、ネットワーク輻輳を示す場合、輻輳マネージャ５１１は圧縮されたデータの最高層を担当するセッションハンドラに指示して、ＲＴＰ／ＲＴＣＰセッションを終了する。輻輳マネージャ５１１は、ネットワークに使用可能な帯域幅があるかどうかを試験するために適当なセッションハンドラを介して層の実験的な接合を周期的に命令する。この実験が成功すると、つまり各層のパケットの実質的にすべてがクライアントに到達している場合には、新しい層が採用される。このようにして最大使用可能帯域幅が採用される。
【００２０】
ネットワーク帯域幅が変動するにつれて輻輳マネージャ５０９が速やかに削除及び復元する層を指示することが可能である。これは視聴者にとってはうるさい場合があるため、シフトを「隠す」方法が採用される。前述された層化符号化方法が採用され、それによって層を削除または追加する場合には、切り替えがビデオデータの場面変化の間に優先的に発生するようになる。ビデオシーンは、通常、ビデオコンテンツ内での大きな変化を示さないビデオシーケンス内の連続フレームの数として知覚される。ビデオシーンまたはショットの中ではカメラ動作が固定されてもよいし、或いはパン(panning)、ズーム、トラッキング等のような数多くの相対的に均一な変化を示してもよい。場面変化はカメラ動作の急激な遷移または漸次的な遷移として認識されてよい。ビデオシーケンス内の場面を識別するために、輝度と色のレベルだけではなく運動エネルギーのレベルも単一の場面内の連続するフレームの間ではそれほど変化しないと仮定される。場面境界識別の技法はピクセルの差分表現、運動ベクトル、及びブロックマッチング技法を含む。したがって、一時的に隣接するフレームのコンテンツにおける非常に突然の変化は場面の変化として表示されるだろう。つまり、このような変化が実際には場面変化にまったく関係しない可能性があるが、例えば代わりに大きな前景オブジェクトが急に視野に入ってきた結果である可能性があると考えられるのは明らかである。しかしながら、それにも関わらずこのような突然の変化はセッション層を追加または削除する妥当な場所であり、したがって用語「場面変化」はあるフレームから別のフレームへのフレームコンテンツにおけるこのような大きな変化をカバーすることになる。
【００２１】
図６は、ネットワーク内の輻輳を検出し、場面変化に層の追加または削除の特別な条件も課すシステムを描いている。サーバ６０１は図１のメディアサーバ２０２の構成要素を備え、装置６０３はやはり図１に示されているクライアント２０４の構成要素を備えている。視聴覚ソースからのビデオデータは、ビデオシーケンスを場面に分割するコンテンツアナライザ６０４にも渡される。分割されたビデオは次に、各構成要素層が提供する場面の知覚品質に対する寄与を評価する客観的品質評価モジュール（ＯＱＡＭ）６０５に渡される。
【００２２】
これらの結果は次に層間適応化モジュール（ＩＬＡＭ）６０７に渡される。ＩＬＡＭ６０７の機能とは、セッションの知覚品質を最大化する層の数を継続的に計算することである。ＩＬＡＭ６０７は、ネットワーク２０３でセッションに使用可能な帯域幅に関して報告する送信者輻輳マネージャ６０８からの入力も受信する。送信者輻輳マネージャ６０８は、受信されたパケットの数に関してクライアント輻輳マネージャ６０９からフィードバックを受信する。これが送信されたパケットの数と一致すると、帯域幅は現在の伝送速度であることが既知である。パケットが失われている場合には、セッションに使用可能な帯域幅は伝送速度未満であり、この場合、送信者輻輳マネージャ６０８はＩＬＡＭ６０７に対し、層を削除する必要がある旨を知らせる。
【００２３】
どの層を削除する必要があるのかを選択するために、ＩＬＡＭ６０７は、ＯＱＡＭ６０５によって計算されるように完全な画像の質に対するその寄与に、層により必要とされる帯域幅を結合する。ＩＬＡＭ６０７は帯域幅／質値のすべてに関して徹底調査を実行する。ＩＬＡＭ６０７が、ある特定の場面からどの層を削除すべきかを選択したとき、削除のタイミングはその特定の場面の伝送と一致するように優先的に設定される。このようにして、品質における削除は場面変化とともに発生し、こうして品質変化が場面の最中に発生した場合よりも視聴者にとってはるかに気付きにくい。事前に設定された時間期間パケットが失われなかった場合には、送信者輻輳マネージャ６０８は、使用可能な帯域幅のすべてが使用されているかどうかを試験するためにＩＬＡＭ６０７に対して層に加えるように要求する。この実験中にパケットが失われると、新規に追加された層が維持される。追加層を用いたこの実験のプロセスは、パケットの大きな割合が失われるまで続行され、この場合システムは、使用可能な帯域幅のすべてが利用されていると確信できる。再び、層の導入のタイミングは場面が変化すると優先的に発生するように設定される。
【００２４】
所定のビットレート割り当てのもとでは、知覚された質のレベルは場面内で大きく変化しないが、特にコンテンツ特徴（空間エネルギーと運動エネルギー）が以後の場面の間で大きく変化するときには、場面のカットにより知覚品質にかなりの変化が引き起こされる。結果として、ストリーム内の層の数のリスケジューリングを正当化してよいそれらの連続する場面について対応する品質スコアの大きな差異もあるだろう。
【００２５】
本発明の使用は階層符号化方式に制限されない。本発明は、ネットワーク容量の変動に対処するための伝送ビットレートの適応が行われるどんな符号化技術での使用にも適している。例えば、本発明は、高ビットレートから低ビットレートへ、あるいは低ビットレートから高ビットレートへ符号化されたデータストリームがトランスコードされる(transcoded)トランスコーディングシステムに適用されてもよい。本発明は、符号化されたビデオシーケンスにおける場面変化時に発生するように遷移を調整することにより、出力ビットレートがネットワークの状態に反応してシフトするときに視聴者に対する影響を削減するのに適しているだろう。本発明が適用されてよい適応ビデオストリーミング技術の別の例は、異なるビットレートの複数の独立したビデオストリームが送信される場合である。この場合には、クライアントはセッション帯域幅に基づいてどのストリームを受け入れるのかを選ぶ。クライアントは、帯域幅の変動につれて、あるストリームから別のストリームに切り替えてもよい。つまり、本発明は、切り替えが符号化されたビデオストリームの中の場面変化に一致するように調整されることを確実にする。
【００２６】
当然のことながら、場面の変化がかなり離れているので、場面の変化の間以外にあるビットレートから別のビットレートに切り替えることが有利となるときもある可能性がある。例えば、その内容が参照によりここに組み込まれる同時係属の欧州特許出願第００３１５９４．７号に記載されているように、例えば異なるビットレートの複数の独立したビデオストリームがメディアサーバによってクライアントへの伝送に使用できる場合を考える。このような場合、サーバは毎秒５００ｋｂｉｔというビットレートで第１のストリームを、毎秒１５００ｋｂｉｔというビットレートで第２のさらに質の高いストリームを送信することができる。クライアントは、サーバが１０００ｋｂｉｔ／ｓの伝送速度で第１ストリームを送信することを最初に要求してもよい。ネットワークが輻輳しておらず、送信されたパケットのすべてがクライアントにより無事に受信されると、クライアントは毎秒５００ｋｂｉｔという速度でバッファからデータを削除するにすぎないため、クライアントにある受信バッファが毎秒５００ｋｂｉｔという速度でデータの充填を開始する。例えばこの速度でバッファを充填してから１０秒後、クライアントは１０秒に値するデータのバッファを有し、その時点でクライアントはサーバからさらに速いビットレートでのビデオデータの第２ストリームの受信を試みることができると判断してよく、したがってこの趣旨でサーバに対し適切な要求を送信する。しかしながら、サーバが、クライアントが５Ｍｂｙｔｅｓサイズの受信バッファを有していることを認識している場合には、サーバは受信バッファがオーバフローし、クライアントに問題を引き起こす前に少なくともさらに１５０秒間毎秒１０００ｋｂｉｔの速度で第１のストリームからデータの送信を続行してよいと理解している。したがって、サーバは指定の期間待機し、この間隔の間に場面変化が発生するかどうかを確かめようとしてもよい。もしそうならば、第２のさらに高いビットレートの信号への切り替えは場面の変化が発生するまで行われない。もちろん、決められた期間内に場面の変化がない場合には、いずれにせよサーバはさらに高い速度に切り替わる。この例では、ただ１０秒という期間だけが待機時間として適切と見なされる。
【００２７】
場面の変化が指定された期間内に発生するかどうかを確かめるためにただ待機し、このような場面の変化が検出されない場合期間の終わりに切り替える代わりに、代替の方法では送信されるビデオを事前に分析し（これが事前に記憶されたビデオデータにのみ適用し、ライブビデオには適応しないことは明らかである）、いつ場面の変化が発生するのかに注目することに注意せよ。このような場合には、サーバはクライアントからのストリーム切り替えの要求を受信すると、所定の期間内に適切な場面の変化が発生するかどうかを確かめ、発生しない場合には新しいビットストリームにただちに切り替えるために調査することができるだろう。
【００２８】
本例では、さらに高速のビットストリームへの切り替え時、クライアントは、データがクライアントによって受信バッファから引き出される速度に対応する毎秒１５００ｋｂｉｔという伝送速度を要求した可能性がある。このような場合、送信されたパケットのすべてがクライアントによって無事に受信される限り、１０秒というバッファサイズは不変のままであるべきである。しかしながら、ネットワークでの輻輳時、ある割合のパケットがクライアントに到達できない可能性がある。このような場合には、サーバはＲＴＣＰを介してこれについて警告を受けるだろう。輻輳が十分に厳しい場合には、サーバは、バッファが空になり、クライアントによって表示されるビデオの中断を発生させる危険にさらされていると推論してよい。これを防止するために、サーバはさらに低速のビットレートストリームに切り替え戻してよい。どのくらいの数のパケットが失われているのかに関する通知を介して、サーバはバッファが空になるまでにどのくらいの時間がかかるのかを推論できる。このときには、サーバは場面の変化が発生するかどうか確かめるために待機することができ、そうなればその時点で新しいストリームが切り替えられるだろう。クライアントが、その受信バッファが持続不可能な速度で空になっていることを検出すると新しいストリームが切り替えられることを単に要求することも可能であることに注意せよ。
【００２９】
実際にはバッファ内のデータの量がバッファ内のデータの量の変化の速度より重要ではないことに注意せよ。したがって、サーバまたはクライアントのどちらかがあるビットストリームから別のビットストリームに変更するかどうか（あるいは第１の例では層を追加するか、削除するか）を判断するために測定するのがこの量であることが好ましい。
【図面の簡単な説明】
【００３０】
【図１】コンテンツベースのストリーム間セッション帯域幅共用アーキテクチャの概略図である。
【図２】層化したコーディングシステムにおけるパケットの順序を示している。
【図３】メディアサーバの図である。
【図４】図３において示されているメディアサーバのネットワークインタフェースの図である。
【図５】クライアントの図である。
【図６】本発明の第１の実施形態によるクライアントの図である。
【図１】
2004536525.tif 000003
【図２】
2004536525.tif 000004
【図３】
2004536525.tif 000005
【図４】
2004536525.tif 000006
【図５】
2004536525.tif 000007
【図６】
2004536525.tif 000008
【国際公開パンフレット】
2004536525.tif 000009
2004536525.tif 000010
2004536525.tif 000011
2004536525.tif 000012
2004536525.tif 000013
2004536525.tif 000014
2004536525.tif 000015
2004536525.tif 000016
2004536525.tif 000017
2004536525.tif 000018
2004536525.tif 000019
2004536525.tif 000020
2004536525.tif 000021
2004536525.tif 000022
2004536525.tif 000023
2004536525.tif 000024
2004536525.tif 000025
2004536525.tif 000026
【国際調査報告】
2004536525.tif 000027
2004536525.tif 000028
2004536525.tif 000029