JP2007535881A - ストリーミングコンテントの適応レートシフティング装置、システムおよび方法 - Google Patents

Abstract

【課題】
【解決手段】 ストリーミングコンテントのレート適応シフトを行う装置であって、複数のストリームレット２１２を同時にリクエストするように構成されたエージェントコントローラモジュール４０２を具える。エージェントコントローラモジュール４０２は更に、ストリームレットリクエストと、順次の応答を連続的にモニタするよう構成されており、従って、より高品質あるいはより低品質のストリームレットをリクエストする。ステージングモジュール４０９は、ストリームレット２１２をステージして、コンテントプレーヤ４０８上で再生するためにストリームレット２１２を編集するように構成されている。システムは、データ通信ネットワーク１０６と、このデータ通信ネットワーク１０６に接続され、コンテントモジュール１１２を有し、コンテントを処理し、複数の高品質および低品質のストリームを生成するように構成されたコンテントサーバ１０２と、前記装置とを具える。方法は、複数のストリームレット２１２を同時にリクエストするステップと、ストリームレットリクエストと、順次の応答を連続的にモニタするステップと、従って高品質及び低品質のストリームレットをリクエストするステップと、ストリームレット２１２をステージして、コンテントプレーヤ４０８上で再生するためにストリームレット２１２を編集するステップと、を具える。
【選択図】 図１

Description

発明の背景
発明の属する技術分野
本発明は、インターネットなどのパケット交換ネットワーク上のビデオストリーミングに関し、特に、このようなネットワーク上でのストリーミングコンテントの適応レートシフティングに関する。

関連技術の説明
インターネットは、メディアファイルをエンドユーザに配信する好ましい方法に急速になりつつある。現在では、音楽あるいは映像を、コンピュータや、携帯電話、あるいは実質的にあらゆるネットワーク可能なデバイスにダウンロードすることが可能である。数多くの持ち運び可能なメディアプレーヤがネットワーク接続に装備されており、音楽や映像を奏することができる。この音楽あるいは映像ファイル（以下、「メディアファイル」という）は、メディアプレーヤまたはコンピュータに局部的に保存したり、サーバからストリーム、あるいはダウンロードすることができる。

「ストリーミングメディア」とは、データを受信するときに、リアルタイムでユーザにそのメディアを提供するのに十分なレートでコンテントを送出する技術を言う。このデータは、奏され、順次削除されるまで一時的にメモリに保存することができる。ユーザは、メディアファイルを完全にダウンロードするまで待つことなく、要求したコンテントを見ることに即時の満足を覚える。残念なことに、リアルタイムで提示するために受信できる音響／映像品質は、ユーザネットワーク接続が入手できる帯域によって制限されている。ストリーミングは、コンテントを要求時（予め記録されている）、あるいはライブ放送から送出するのに使用することができる。

代替的に、メディアファイルは、後に提示するように、ハードドライブや光ストレージなどの永続的なストレージデバイスにダウンロードして保存することができる。メディアファイルの完全なダウンロードは、ネットワーク接続によっては、多大な時間がかかることがある。しかし、一旦ダウンロードすると、このコンテントをいつでもどこでも繰り返して見ることができる。ダウンロード用に作成されたメディアファイルは、通常、リアルタイムで送出されるものより品質が高い音響／映像で符号化されている。ユーザは、メディアファイルを即座に見たり聞いたりしたいという傾向にあるので、一般的にこのオプションを好まない。

ストリーミングは、即座にコンテントにアクセスできるという利点を提供するが、目下のところ、同じコンテントのファイルをダウンロードすることに比べると品質を犠牲にしている。ストリーミングも、特別ベースでビューイングするための別のコンテントをユーザが選択する機会を提供しているが、ダウンロードは、特定のコンテント選択をコンテンツ全体を受信するか、全く受信しないかに制限された定義による。ダウンロードは又、巻戻し、早送り、および直接のシーク操作をサポートしているが、ストリーミングはこれらの機能を完全にサポートすることはできない。ストリーミングは又、ネットワークの欠陥あるいは輻輳に対して無防備である。

「プログレッシブダウンロード」と呼ばれるもう一つの技術は、上述した二つの技術の効果を組み合わせることを意図している。プログレッシブダウンロードが開始すると、メディアファイルのダウンロードが始まり、メディアプレーヤは、再生を開始するのに十分なファイルがダウンロードされるまで、再生が「追いつく」前にファイルの残りが完全にダウンロードされるであろうとの望みを持って、再生開始を待つ。この再生前の待機期間はネットワークの状態に実質的に依存することができ、従って、ネットワーク上でのメディア提示の問題を完全に、又は全体的に受け入れられる解決にはならない。

一般的に、データ消失量が変化するインターネットなどのネットワーク上でのデータ移送ストリーミングに関して、３つの基本的な目標がある。第１の目標は、信頼性である。多くのストリーミングソリューションは、データの送信にＴＣＰ接続か、あるいは「仮想回線」を用いている。ＴＣＰ接続は、データの部分が失われ、再送される場合でも、一のエンドポイントから送られてきたデータが行き先に送出されるように保証された送出機構を提供している。ＴＣＰ接続の連続性のみだれは、データがリアルタイムで送出されなければならない場合に、重大な結果になることがある。ネットワークアダプタがＴＣＰ接続の遅れあるいはロスを検出すると、アダプタは送信の試みをしばらくの間「バックオフ」して、その後ゆっくりと、元の送信ペースを再開する。この行動は、知覚輻輳を緩和するための試みである。このようなスローダウンは、ユーザの見るあるいは聞く経験に有害であるため、受け入れられない。

データ移送の第２の目標は、効率である。効率とは、コンテントストリームの送出にユーザが利用可能な帯域がどれだけ良く使用されているかという意味である。この測定は、ＴＣＰ接続の信頼性に直接関連する。ＴＣＰ接続の信頼性に問題があると、帯域使用のロスが生じる。効率の測定は、時に急激に変化し、ビュウイングの経験に大きな衝撃を与えることがある。

第３の目標は、待ち時間である。待ち時間とは、リクエストが発せられたときと、応答データが到着し始めたときの間のクライアントの観点からの、インターバルを測定した時間である。この値は、ネットワーク接続の信頼性と効率、および発信元が応答を準備するのに必要な処理時間によって影響を受ける。例えばビージーなあるいはオーバロードしたサーバはリクエストの処理により時間がかかる。特別なリクエストの開始時間に影響を与えるのと同様に、待ち時間は、ＴＣＰのネットワークスループットに有意に影響する。

上述した議論から、信頼性、効率、および待ち時間の問題を緩和する装置、システム及び方法の要求が存在することは明らかである。更に、このような装置、システム及び方法は、早送り、巻戻し、直接的なシーク、およびマルチストリームを検索する能力を伴う即時ビューイングを提供するものである。有利なことに、これらの装置、システム及び方法は、発信源と行き先間の多重接続を用いて、ネットワークの状態に応じてビットレートストリームを変化させることを要求している。

発明の概要
本発明は、この技術の現状に応答して開発されたものであり、特に、現在入手可能なコンテントストリーミングシステムでは完全に解決されていないこの技術における問題点と必要性に応じて開発されたものである。従って、本発明は、この技術における上述した欠点のほとんどあるいはすべてを克服する適応レートコンテントストリーミング用の装置、システムおよび方法を提供するように開発された。

適応レートコンテントストリーミング用装置には、必要なステップを機能的に実行するように構成された複数のモジュールを具える論理ユニットが設けられている。記載されている実施例中のこれらのモジュールは、複数のストリームレットを同時に要求するように構成したエージェントコントローラモジュールであって、このエージェントコントローラモジュールは更に、ストリームレットリクエストと、順次の応答を連続的にモニタするように構成されており、従って、より高いあるいはより低い品質のストリームレットを要求するモジュールと、このストリームレットをステージして、ストリームレットをコンテントプレーヤ上での再生用に編集するように構成したステージモジュールとを具える。

一の実施例では、この装置は更に、コンテントサーバとの多重伝送制御プロトコル（ＴＣＰ）接続を設定し、ビットレートが変化するストリームレットを要求するように構成されている。各ストリームレットは更に、コンテントファイルの一部を具えている。更に、エージェントコントローラモジュールは、ストリームレットリクエストからの応答に応じてパフォーマンスファクタを生成するように構成されている。

更なる実施例では、エージェントコントローラモジュールは、パフォーマンスファクタがスレッシュホールドより大きい場合に、より高品質のストリームレットにシフトアップするように構成されており、このエージェントコントローラモジュールは、ファクタの組み合わせに応じてより高品質の再生を保持できるか否かを決定する。このファクタは、ステージモジュールに保存された次いで入手可能なストリームレットの量と、最小安全マージンと、マージンの現在の先読みを含んでいても良い。

エージェントコントローラモジュールは、パフォーマンスファクタが第２のスレッシュホールドより小さい場合には、より低品質のストリームレットにシフトダウンするように構成することができる。また、エージェントコントローラモジュールは、更に、ストリームレットリクエストと、予めリクエストされたストリームレットを予測して、早送りしたり、ランダムスキップしたり、機能的に巻戻したりすることができるように構成されている。一の実施例では、エージェントコントローラモジュールは、最初に低品質のストリームレットをリクエストして、コンテントファイルの即時の再生を可能とし、次いでパフォーマンスファクタによって順次シフトアップするように構成されている。

本発明のシステムも、適応レートコンテントストリーミングに提示されている。特に、一の実施例では、このシステムは、データ通信ネットワークと、このデータ通信ネットワークに接続され、コンテントを処理して高品質及び低品質の複数のストリームを生成するように構成されたコンテントモジュールを有するコンテントサーバを具える。一実施例では、高品質及び低品質のストリームが各々複数のストリームレットを具えていても良い。

更なる実施例では、このシステムは又、複数のストリームレットを同時にリクエストするように構成され、このエージェントコントローラモジュールが更に、ストリームレットリクエストと順次の応答を連続的にモニタし、これによって、より高品質あるいはより低品質のストリームレットをリクエストするエージェントコントローラモジュールと、ストリームレットをステージして、再生用のストリームレットをコンテントプレーヤ上に編集するように構成したステージモジュールを具える。

本発明の方法も、適応レートコンテントストリーミング用に提示されている。開示されている実施例の方法は、実質的に、上述した装置及びシステムの動作に関して上記の機能を実施するのに必要なステップを具える。一の実施例では、この方法は複数のストリームレットを同時にリクエストするステップと、ストリームレットリクエストと順次の応答を連続的にモニタするステップと、これによってより高品質あるいはより低品質のストリームレットをリクエストするステップと、このストリームレットをステージして、コンテントプレーヤ上での再生用にストリームレットを編集するステップと、を具える。

さらなる実施例では、この方法はコンテントサーバとの多重伝送制御プロトコル（ＴＣＰ）接続を設定するステップと、ビットレートが変化するストリームレットをリクエストするステップとを具える。また、この方法は、ストリームレットリクエストからの応答に応じてパフォーマンスファクタを生成するステップと、このパフォーマンスファクタがあるスレッシュホールドより大きい場合により高品質のストリームレットにシフトアップするステップと、このより高品質の再生を保持することができるか否かを決定するステップとを具える。更に、この方法は、パフォーマンスファクタが第２のスレッシュホールドより低い場合に、より低品質のストリームレットにシフトダウンするステップを具える。

一実施例では、ストリームレットリクエストを予測するステップと、ストリームレットを予めリクエストして、早送り、ランダムスキップ、巻戻し機能を可能とするステップを具える。この方法は、最初に低品質のストリームレットをリクエストして、コンテントファイルの即時再生を可能とし、パフォーマンスファクタに従って、順次シフトアップするステップを具える。

本明細書を通して、特徴、利点あるいは同じ言語についての符号は、本発明によって実現されるすべての特徴と利点が本発明の一の実施例にあるべきである旨を意味するものではない。むしろ、この特徴および利点に関する言語は、実施例に関連して述べた特徴、利点又は特性が本発明の少なくとも一の実施例に含まれていることを意味すると理解すべきである。従って、本明細書を通しての特徴及び利点、および同様の言語に関する議論は、必須ではないが、同じ実施例を意味することがある。

更に、本発明の上述した特徴、利点および特徴は、一またはそれ以上の実施例においてあらゆる好適な態様で組み合わせることができる。関連分野における当業者は、本発明が一またはそれ以上の特定の実施例の特別な特徴又は利点なしで実行できることを認識するであろう。別の例では、本発明の全ての実施例に存在しないかもしれない、ある実施例において更なる特徴及び利点を認識することがある。

本発明のこれらの特徴及び利点は、以下の記載と請求項からより完全に明らかになるであろう、あるいは、ここに述べた本発明の実施によって学習することができる。

発明の詳細な説明
本明細書中に記載されている多くの機能ユニットは、その実装の独立性をより特定して強調するためにモジュールと表示されている。例えば、モジュールは、カスタムＶＬＳＩ回路やゲートアレイ、論理チップ、トランジスタ、またはその他の分散部品などのオフザシェルフ半導体を具えるハードウエア回路として実装することができる。モジュールは、フィールドプログラマブルゲートアレイ、プログラマブルアレイロジック、プログラマブルロジックデバイス、その他などのプログラマブルハードウェアデバイス中に実装することもできる。

モジュールは、様々なタイプのプロセッサによって実行するソフトウエア中に実装することもできる。実行可能なコードで同定されたモジュールは、例えば、目的、処理、あるいは機能として組織化することができるコンピュータ指示の一またはそれ以上の物理的あるいは論理ブロックを具えていても良い。それにもかかわらず、同定したモジュールの実行可能コードは、物理的に一緒に配置されていなくとも良いが、異なる位置に保存された異種の指示を具えていても良い。実行可能コードが論理的に一緒にある場合は、モジュールを具え、上述したモジュールの目的を実行する。

実際、実行可能なコードのモジュールは、単一の指示であっても、あるいは多数の指示であっても良く、いくつかの異なるコードセグメントに、異なるプログラム間に、またいくつかのメモリデバイスにわたって分散されていても良い。同様に、動作データを同定して、モジュール内に示すようにしても良く、何らかの好ましい形で実施して、いずれかの好適なタイプのデータ構造内に組織化しても良い。動作データは、単一のデータセットとして集めることができ、あるいは、異なるストレージデバイスを含む異なる場所に分配することもでき、システムまたはネットワーク上の単なる電気信号として少なくとも部分的に存在していても良い。

この明細書を通じて、「一の実施例」、「実施例」あるいは同様の用語は、特別な特徴、構造あるいは実施例に関連して記載された特徴が本発明の少なくとも一の実施例に含まれていることを意味する。従って、この明細書を通じて「一の実施例中」、「実施例中」といったフレーズ、および同様の用語の存在は、必然ではないが、すべて同じ実施例を意味している。

信号生成媒体の意味は、信号を生成することができ、信号を生成させることができ、あるいはデジタル処理装置上の機械で読み取り可能な指示のプログラムを実行させることができるあらゆる形をとることができる。信号生成媒体は、送信ライン、コンパクトディスク、デジタルビデオディスク、磁気テープ、ベルヌイドライブ、磁気ディスク、パンチカード、フラッシュメモリ、集積回路、あるいはその他のデジタル処理装置メモリデバイスによって実施することができる。

更に、上述した特徴、構造あるいは本発明の特徴は、一又はそれ以上の実施例中であらゆる好適な態様で組み合わせることができる。以下の説明において、プログラミングの例、ソフトウエアモジュール、ユーザ選択、ネットワーク取引、データベース検索要求、データベース構造、ハードウエアモジュール、ハードウエア回路、ハードウエアチップ、その他といった様々な特別な詳細が記載されており、本発明の実施例の全体的な理解を提供している。しかしながら、関連分野における当業者は、一又はそれ以上のこの特別な詳細がなくても、あるいはその他の方法、構成要素、材料、その他を用いて実施することができるであろう。その他の場合、よく知られた構造、材料あるいは動作は、本発明の態様を不明確にするのを避けるために、示されていないか、あるいは詳細に説明されていない。

図１は、本発明に係るストリーミングコンテントの動的なレートシフトを行うシステム１００の一実施例を示す概略ブロック図である。一の実施例では、システム１００は、コンテントサーバ１０２と、エンドユーザ１０４を具える。コンテントサーバ１０２とエンドユーザ局１０４は、データ通信ネットワークで接続することができる。データ通信ネットワークは、インターネット１０６と、インターネット１０６への接続１０８を具える。代替的に、コンテントサーバ１０２とエンドユーザ１０４は、共通のローカルエリアネットワーク、ワイヤレスエリアネットワーク、セルラネットワーク、バーチャルローカルエリアネットワーク、その他の上に配置しても良い。エンドユーザ局１０４は、パーソナルコンピュータ（ＰＣ）、ネットワークを介して通信するように構成された娯楽システム、あるいは、コンテントを提示するように構成された持ち運び可能な電子デバイスを具えていても良い。

図に示す実施例では、システム１００は又、パブリッシャ１１０と、ウエブサーバ１１６を具える。パブリッシャ１１０は、コンテントの製造者あるいは頒布者であってもよい。例えば、ストリームされるコンテントが、テレビジョンプログラムの放送である場合、パブリッシャ１１０は、ＮＢＣ（登録商標）あるいはＭＴＶ（登録商標）などのテレビジョンまたはケーブルネットワークチャンネルであってもよい。コンテントは、インターネット１０６を介してコンテントサーバ１０２に送信され、ここでこのコンテントがコンテントモジュール１１２によって受信される。コンテントモジュール１１２は、コンテントを受信し、処理し、保存するように構成されている。一の実施例では、処理したコンテントは、エンドユーザ局１０４でそのコンテントを奏するように構成されたクライアントモジュール１１４によってアクセスされる。更なる実施例では、クライアントモジュール１１４は、複数の位置からのコンテントストリームの異なる部分を同時に受信するように構成されている。例えば、クライアントモジュール１１４は、複数のウエブサーバ１１６のいずれかからコンテントを要求して受信することができる。

図２ａは、コンテントファイル２００の一実施例をグラフィカルに示す概略ブロック図である。一の実施例では、コンテントファイル２００は、パブリッシャ１１０によって配信される。コンテントファイル２００は、テレビジョン放送、スポーツイベント、映画、音楽、コンサート、その他を具えていてもよい。コンテントファイル２００は、ライブまたはアーカイブコンテントであっても良い。コンテントファイル２００は、非圧縮ビデオと音響、あるいは、代替的にビデオまたは音響であっても良い。更に、コンテントファイル２００は、圧縮されていても良い。圧縮コンテントファイル２００の例には、限定するものではないが、ＤｉｖＸ（登録商標）、Windows Media Video 9（登録商標）、 Quicktime 6.5 Sorenson 3（登録商標）、またはQuicktime 6.5/MPEG-4（登録商標）で符号化したコンテントがあっても良い。

図２ｂは、品質の度合いと帯域が変化する複数のストリーム２０２の一実施例を示す概略ブロック図である。一の実施例では、複数のストリーム２０２は、低品質ストリーム２０４と、中品質ストリーム２０６と、高品質ストリーム２０８を具える。各ストリーム２０４、２０６、２０８は、符号化され、変化するビットレートに圧縮されたコンテントファイル２００のコピーである。例えば、低品質ストリーム２０４は符号化され、秒当たり１００キロビット（ｋｂｐｓ）のビットレートに圧縮され、中品質ストリーム２０６は符号化され秒当たり２００キロビット（ｋｂｐｓ）のビットレートに圧縮され、及び高品質ストリーム２０８は符号化され秒当たり６００キロビット（ｋｂｐｓ）のビットレートに圧縮されている。

図２ｃは、複数のストリームレット２１２に分割されたストリーム２１０の一実施例を示す概略ブロック図である。ここに用いられているように、ストリームレットとは、コンテントファイル２００の何らかのサイズの部分を意味する。各ストリームレット２１２は、独立したメディア対象物として封入されたストリーム２１０に含まれるコンテントの部分を具えている。ストリームレット２１２内のコンテントは、ストリーム２１０内に含まれているコンテントの開始に関連する独自の時間インデックスを有する。一の実施例では、各ストリームレット２１２内に含まれるコンテントが２秒の期間を有する。例えば、ストリームレット０は、コンテント再生開始を表す００：００の時間インデックスを有しており、ストリームレット１は、００：０２の時間インデックス、などを有していても良い。代替的に、ストリームレット２１２の期間は、ストリーム２１０内のコンテントの全再生期間より小さいいずれの期間であっても良い。更なる実施例では、ストリームレット２１２は、時間インデックスに変えて、ファイルサイズによって分割することもできる。

図３は、本発明にかかるコンテントモジュール１１２の一実施例をより詳細に示す概略ブロック図である。コンテントモジュール１１２は、ストリームモジュール３０２と、ストリームレットモジュール３０４と、エンコーダモジュール３０６と、ストリームレットデータベース３０８と、ウエブサーバ１１６を具える。一の実施例では、ストリームモジュール３０２は、パブリッシャ１１０からコンテントファイル２００を受領し、品質が異なる複数のストリーム２０２を生成するように構成されている。パブリッシャからのオリジナルのコンテントファイル２００は、デジタルのフォームであり、例えば、２ｍｂｐｓなどの高ビットレートを有するコンテントを具えていても良い。コンテントは、インターネット１０６を介してパブリッシャ１１０からコンテントモジュール１１２へ送信される。このようなデータ送信は、この分野では良く知られており、ここでは、更なる議論は不要である。代替的に、コンテントは、入手した放送を具えていてもよい。

図に示す実施例では、複数のストリーム２０２が、低品質のストリーム２０４と、中品質のストリーム２０６と、高品質のストリーム２０８を具えていても良い。代替的に、複数のストリーム２０２が、エンドユーザの帯域を受け入れるのに必要と思われる数のストリームを具えていても良い。ストリームレットモジュール３０４は、ストリームモジュールから複数のストリーム２０２を受信して、各ストリームが複数のストリームレット２１２を具えている複数のストリーム３１２を生成するように構成されている。図２ｃに関連して記載したとおり、各ストリームレット２１２は、ストリームの予め規定した部分を具えていても良い。エンコーダモジュール３０６は、複数のストリーム３１２からの各ストリームレットを符号化して、このストリームレットをストリームレットデータベース３０８に保存するように構成されている。符号化モジュール３０６は、ＤｉｖＸ（登録商標）、Windows Media Video 9（登録商標）、 Quicktime 6.5 Sorenson 3（登録商標）、またはQuicktime 6.5/MPEG-4（登録商標）などの符号化スキームを用いることができる。代替的に、カスタム符号化スキームを使用するようにしても良い。

コンテントモジュール１１２は、又、メタデータモジュール３１２とメタデータデータベース３１４を含んでいても良い。一の実施例では、メタデータは、静的な検索可能なコンテント情報を具える。例えば、メタデータは、限定するものではないが、コンテントのエア日付、タイトル、女優、俳優、長さ、エピソード名を具える。メタデータは、パブリッシャ１１０によって生成され、エンドユーザの環境を決定するように構成されている。一の実施例では、パブリッシャ１００は、メニュー、サムネイル、サイドバー、広告、その他を含むコンテントに関するエンドユーザのナビゲーション環境を規定することもできる。更に、パブリッシャ１１０は、早送り、巻戻し、ポーズ、および演奏などのコンテントファイル２００で使用する機能を規定することができる。メタデータモジュール３１２は、パブリッシャ１１０からメタデータを受信して、このメタデータをメタデータデータベース３１４に保存するように構成されている。更なる実施例では、メタデータモジュール３１２は、クライアントモジュール１１４とインターフェースをとるように構成されており、クライアントモジュール１１４が複数のメタデータ基準の少なくともひとつに基づいてコンテントを検索できるようにしている。更に、メタデータは自動プロセスあるいは手動での定義を介してコンテントモジュール１１２によって発生することができる。

ストリームレット２１２が一旦受信され、処理されると、クライアントモジュール１１４は、ＨＴＴＰを用いてウエブサーバ１１６からストリームレット２１２を要求することができる。クライアント側で開始するこのようなリクエストの使用には、ファイヤーウオールの追加の構成は必要ない。更に、クライアントモジュール１１４が、このリクエストを開始するので、ウエブサーバ１１６に必要なのはリクエストのあったストリームレットを取り出して提供することのみである。更なる実施例では、クライアントモジュール１１４を、複数のウエブサーバ３１０からストリームレット２１２を取り出すように構成することができる。各ウエブサーバ１１６は、インターネット１０６上の様々な位置に配置することができる。ストリームレット２１２は本質的には静的ファイルである。このように、クライアントモジュール１１４は、ストリームレット２１２を取り出すのに、特化したメディアサーバや、サーバ側のインテリジェンスを必要としていない。ストリームレット２１２は、ウエブサーバ１１６によって提供されるか、あるいは、インターネットサービスプロバイダ（ＩＳＰｓ）、あるいはその他のネットワークインフラストラクチュアオペレータのキャッシュサーバに記憶して、キャッシュサーバによって保存することができる。キャッシュサーバの使用は当業者にはよく知られており、ここではこれ以上説明しない。従って、いずれかの特定の場所におけるウェブサーバ１１６のクライアントモジュール１１４の大量のリクエストによって妨害されることのない、高度にスケーラブルなソリューションが提供される。

図４は、本発明に係るクライアントモジュール１１４の一実施例をグラフィカルで示す概略ブロック図である。クライアントモジュール１１４は、エージェントコントローラモジュール４０２と、ストリームレットキャッシュモジュール４０４と、ネットワークコントローラモジュール４０６とを具える。一の実施例では、エージェントコントローラモジュール４０２は、ビューワ４０８とインターフェースを取り、ビューワ４０８へストリームレット２１２を送信するように構成されている。更なる実施例では、クライアントモジュール１１４は、複数のエージェントコントローラモジュール４０２を具えている。各エージェントコントローラモジュール４０２は、一のビューワ４０８とインターフェースを取るように構成することができる。代替的に、エージェントコントローラモジュール４０２は、複数のビューワ４０８とインターフェースを取るように構成することができる。ビューワ４０８は、ＰＣあるいは手動電子デバイス上で動作しているメディアプレーヤ（図示せず）であっても良い。

エージェントコントローラモジュール４０２は、ビューワ４０８に送信するストリームレットの品質レベルを選択するように構成されている。エージェントコントローラモジュール４０２は、各要求されたストリームレットの連続的な受信時間の間の時間インターバルの継続的観察に基づいてより低品質、あるいはより高品質ストリームをリクエストする。より高品質またはより低品質ストリームを要求する方法を、図７を参照して以下により詳しく述べる。

エージェントコントローラモジュール４０２は、ビューワ４０８からのユーザコマンドを受信するように構成されている。このようなコマンドには、演奏、早送り、巻戻し、ポーズ、停止が含まれている。一の実施例では、エージェントコントローラモジュール４０２は、ストリームレットキャッシュモジュール４０４からストリームレット２１２を要求し、この受信したストリームレット２１２をステージモジュール４０９で編集する。ステージモジュール４０９は、再生時間を上げるためにストリームレット２１２を編集するように構成することができる。図に示す実施例では、ストリームレット２１２は、０，１，２，３，４、その他の番号がついている。しかしながら、各ストリームレット２１２は、独自のファイル名で同定することができる。

更に、エージェントコントローラモジュール４０２は、ストリームレット２１２のリクエストと、予めリクエストしたストリームレット２１２を予測するように構成することができる。ストリームレット２１２を予めリクエストすることによって、ユーザは、コンテントを通して早送り、ランダムスキップ、あるいは巻戻しを行い、バッファの遅れが生じることがない。更なる実施例においては、エージェントコントローラモジュール４０２は、コンテントの全演奏時間以内で３０秒の時間インデックスインターバルに対応するストリームレット２１２を要求することができる。代替的に、エージェントコントローラモジュール４０２は、時間インデックスの長さ以下のインターバルでストリームレットを要求することができる。このことは、スタート時あるいはコンテントファイル２００を早送りするときに、バッファの待ち時間無しの「高速スタート」能力を可能にする。更なる実施例では、エージェントコントローラモジュール４０２は、コンテント内の、あるいは見るべき新しいコンテントを選択するエンドユーザ１０４を見越したその他のコンテント内の、特定のインデックスポイントに対応するストリームレット２１２を予め要求するように構成することができる。

一の実施例では、ストリームレットキャッシュモジュール４０４は、エージェントコントローラモジュール４０２からのストリームレット２１２リクエストを受信するように構成されている。リクエストを受信したら、ストリームレットキャッシュモジュール４０４は、まず、ストリームレットキャッシュ４１０をチェックして、ストリームレット２１２が存在するかどうかを確認する。更なる実施例では、ストリームレットキャッシュモジュール４０４は、複数のエージェントコントローラモジュール４０２からのストリームレット２１２リクエストを操作する。代替的に、ストリームレットキャッシュモジュール４０４は、各エージェントコントローラモジュール４０２用に提供されている。リクエストのあったストリームレット２１２がストリームレットキャッシュ４１０に存在しないのであれば、そのリクエストをネットワークコントローラモジュール４０６に引き渡す。早送りと巻戻し能力を可能とするために、ストリームレットキャッシュモジュール４０４は、ストリームレット２１２を見た後、ストリームレットキャッシュ４１０に特定の時間、複数のストリームレット２１２を保存するように構成されている。しかしながら、ストリームレット２１２が一旦削除されると、ウェブサーバ１１６から再度リクエストされる。

ネットワークコントローラモジュール４０６は、ストリームレットキャッシュモジュール４０４からのストリームレットリクエストを受信して、ウエブサーバ１１６、あるいはその他の遠隔ストリームレット２１２データベース（図示せず）への接続を開にするように構成されている。一の実施例では、ネットワークコントローラモジュール４０６が、ウエブサーバ１１６へのＴＣＰ／ＩＰ接続を開にして、リクエストしたストリームレット２１２についての標準ＨＴＴＰ ＧＥＴリクエストを発生する。リクエストされたストリームレット２１２を受信すると、ネットワークコントローラモジュール４０６は、ストリームレット２１２を、ストリームレットキャッシュモジュール４０４へ通過させる。ここで、ストリームレットはストリームレットキャッシュ４１０に保存される。更なる実施例では、ネットワークコントローラモジュール４０６は、複数のストリームレット２１２を同時に処理し、リクエストするように構成されている。ネットワークコントローラモジュール４０６は、また、複数のストリームレットをリクエストするように構成されており、ここでは、各ストリームレット２１２は、多数の部分において順次リクエストされる。

更なる実施例では、ストリームレットリクエストは、いずれかのストリームレットファイルのリクエスト片を具えていても良い。ストリームレット２１２をより小さな片または部分に分けることで、潜在的に効率が高くなり、所定の瞬間に帯域を共有している複数の全ストリームレットリクエストに関連する問題を解決するものでもあり、有益である。このことは、ストリームレット２１２片に対する並列ＴＣＰ／ＩＰ接続を使用することによって達成される。この結果、効率とネットワークロスの問題が解決され、ストリームレットはより有用で予測可能なタイミングで到着する。

一の実施例では、クライアントモジュール１１４が、クライアントモジュール１１４とウエブサーバ１１６またはウエブキャッシュとの間で多数のＴＣＰ接続を使用するように構成されている。キャッシュの介入は、クライアントに分かりやすいか、あるいは、クライアントによってフォワードキャッシュとして構成される。「並列取り出し」と呼ばれるやり方で一以上のストリームレット２１２を、同時に、あるいはストリームレット２１２の一以上の部分を同時にリクエストすることによって、効率が大きく上がり、待ち時間が事実上少なくなる。更なる実施例では、クライアントモジュールは、最大３つの現在のストリームレット２１２リクエストを可能にする。クライアントモジュール１１４は、追加の開放ＴＣＰ接続を、別の接続が切れた場合の入手可能なスペアとして維持している。ストリームレット２１２リクエストは、すべての開接続の間で回転して、特定の接続がすべてスロースタートまたは閉モードに入らないように、ＴＣＰフローロジックを維持している。ネットワークコントローラモジュール４０６が複数部分においてストリームレット２１２をリクエストした場合、相互に独立したＴＣＰ／ＩＰ接続のリクエストされた各パートによって、ネットワークコントローラモジュール４０６は、この部分を組み立てなおして、クライアントモジュール１１４の他の全ての構成要素による使用のために完全なストリームレット２１２を提供する。

ＴＣＰ接続が完全に切れた場合は、新しいリクエストが同じストリームレット２１２の別の接続に送られる。更なる実施例では、リクエストが時宜を得て満足されていない場合、冗長リクエストを同じストリームレット２１２の別の接続に送るようにしても良い。第１のストリームレットリクエストの応答が、冗長リクエストの応答の前に届いた場合は、冗長リクエストは中断することができる。冗長リクエストの応答が、第１のリクエスト応答の前に届いた場合は、第１のリクエストを中断することができる。

いくつかのストリームレット２１２リクエストを、単一のＴＣＰ接続に送ることができ、同じ接続に沿ったマッチングオーダ中にフローバックへの応答が生じる。このことは、第１のリクエストの待ち時間を除いて、全てを少なくする。多数の応答が常に送信されているので、第１のリクエスト後の各々の新しいストリームレット２１２の応答の処理待ち時間は、性能についての要因ではない。この技術は、「パイプライニング」業界において知られている。パイプライニングは、リクエスト待ち時間のほとんどの効果を取り除くことによって、リクエスト−応答処理に効率を提供する。しかしながら、パイプライニングは、非常に無防備である。送信の遅れは、全ての応答に影響する。単一のＴＣＰ接続が切れた場合、現在のリクエストと応答の全てが失われる。パイプライニングは、リクエスト間に一連の従属性を生じさせる。

多数のＴＣＰ接続は、クライアントモジュール１１４とウエブサーバ１１６との間に開かれており、各ストリームレット２１２リクエストの独立性を維持しながら、パイプライニングの待ち時間を低減する効率の利益を達成する。いくつかのストリームレット２１２リクエストが、相互に明確なＴＣＰ接続に送られている各リクエストと共に、同時に送られる。この技術は、「バーチャルパイプライニング」と呼ばれており、本発明の革新である。多数の応答は、同時に移動状態にあり、クライアントモジュール１１４とウエブサーバ１１６間の通信帯域が常に使用されていることを確実にしている。バーチャルパイプライニングは、伝統的なパイプライニングの無防備性をなくしている。一の応答における遅れ、あるいは完全な失敗は、その他の応答の送信に影響しない。なぜなら、各応答が独立したＴＣＰ接続を占めているからである。多数の応答のうちの一つによって使用されていない送信帯域は（遅れによるものであっても、ＴＣＰ接続の失敗によるものであっても）、その他の現在の応答によって使用することができる。

単一のストリームレット２１２リクエストは、全ストリームレット２１２用に発行されるものであってもよく、あるいは、ストリームレットの各異なる部分について多数リクエストを発行しても良い。幾つかの部分でこのストリームレットがリクエストされると、その部分がクライアントモジュール１１４ストリームレットによって再結合される。

最大にした帯域使用と応答時間の間で正しいバランスを維持するためには、クライアントモジュール１１４が以前にある現在のストリームレットリクエストの一つに対する応答を完全に受信する前の、ウエブサーバ１１６が応答を送信しないような時間に、新しいストリームレットリクエストの発行が、行われなくてはならない。例えば、ストリームレット２１２が現在リクエストされている場合、クライアントモジュール１１４は、前記３つの応答のうちの一つが、完全に受信され、”out of the pipe”になる少し前に次のリクエストを発しなければならない。言い換えると、リクエストタイミングを調整して、３つの応答を通過中に維持する。４つの応答間での帯域の共有は、その他の３つの応答のネット応答時間を減少させる。タイミングの調整は、観察によって動的に計算しても良く、このように調整されたリクエストタイミングは効率と応答時間の正しいバランスを維持する。

以下の概略フローチャート図は、論理フローチャート図を一般的に説明するものである。図に示す順序および名称をつけたステップは、本発明の方法の一実施例を示すものである。機能、論理、あるいは効果において図に示す方法の一またはそれ以上のステップ、またはステップの部分と同じであるその他のステップおよび方法を考えることができる。更に、使用されているフォーマットとシンボルは、この方法の論旨ステップを説明するためのものであり、この方法の範囲を限定するためのものではないと理解するべきである。様々な形の矢印とラインとがフローチャート図に使用されているが、これらは対応する方法の範囲を限定するものではないと理解するべきである。実際、いくつかの矢印あるいはその他のコネクタがこの方法の論理フローのみを示すのに使用されている。例えば、ある矢印は、図に示す方法の数えられたステップ間の特定されない期間についての待ち時間またはモニタ時間を示している。更に、特定の方法が生じる順序は、図に示す対応するステップの順番に厳密に合致している、あるいは合致していない。

図５は、本発明による処理コンテントについての方法５００の一実施例を示す概略フローチャート図である。一の実施例では、方法５００は、ステップ５０２で開始し、ステップ５０４でコンテントモジュール１１２が、パブリッシャ１１０からコンテントを受信する。コンテント受信ステップ５０４は、コンテントファイル２００のデジタルコピーを受信するステップ５０４か、あるいはコンテントファイル２００の物理的コピーのデジタル化するステップを具える。代替的に、コンテント受信ステップ５０４は、ラジオまたはテレビジョン放送を捕捉するステップを具えていても良い。受信ステップ５０４がなされると、ストリームモジュール３０２は、各々の品質が異なる複数のストリーム２０２を生成する（ステップ５０６）。この品質は予め決められていても良いし、あるいは、エンドユーザの帯域によって、または予め指定されたパブリッシャのガイドラインに応じて自動的に設定することもできる。

ストリームレットモジュール３０４は、ストリーム２０２を受信して、複数のストリームレットを生成する（ステップ５０８）。一の実施例では、ストリームレット生成ステップ５０８は、ストリーム２０２を複数の２秒のストリームレット２１２に分割するステップを具える。代替的に、ストリームレットがストリーム２０２の長さ以下であるか、あるいは同じ長さを有していても良い。次いで、エンコーダモジュール３０６が圧縮アルゴリズムに応じてストリームレットを符号化する（ステップ５１０）。更なる実施例では、このアルゴリズムが、ＷＭＶ９（登録商標）などのプロプリエタリコデックを具える。次いで、エンコーダモジュール３０６は、ストリームレットデータベース３０８中の符号化したストリームレットを保存する（ステップ５１２）。保存ステップ５１２がなされると、ウエブサーバ１１６が、そのストリームレットをサーバ処理する（ステップ５１４）。一の実施例では、ストリームレットのサービングステップ５１４は、クライアントモジュール１１４からストリームレットリクエストを受信するステップと、ストリームレットデータベース３０８からこのリクエストしたストリームレットを取り出すステップと、クライアントモジュール１１４へストリームレットを順次送信するステップとを具える。そして、方法５００は終了する（ステップ５１６）。

図６は、本発明に係る複数のストリームレットを見るための方法６００の一実施例を示す概略フローチャート図である。方法６００がスタートすると、エージェントコントロールモジュール４０２が提供され（ステップ６０４）、ビューワ４０８に関連して、ステージモジュール４０９が提供される。ついで、 エージェントコントローラモジュール４０２が、ストリームレットキャッシュモジュール４０４からストリームレットを同時にリクエストする（ステップ６０６）。代替的に、エージェントコントローラモジュール４０２は、ストリームレットキャッシュモジュール４０４から複数のストリームレットを同時にリクエストしても良い（ステップ６０６）。ストリームレットがストリームレットキャッシュ４１０に局地的に保存される（ステップ６０８）と、ストリームレットキャッシュモジュール４０４はストリームレットを取り出して（ステップ６１０）、このストリームレットをエージェントコントローラモジュール４０２に送る。ストリームレットを取り出す（ステップ６１０）、あるいは受信すると、エージェントコントローラモジュール４０２は、より高品質あるいはより低品質のストリーム２０２へシフトするべきかどうかの決定を行う（ステップ６１１）。この決定については、図７を参照して以下により詳細に述べる。

一の実施例では、次いで、ステージモジュール４０９がストリームレットを正しい順序に編集し（ステップ６１２）、エージェントコントローラモジュール４０２がストリームレットをビューワ４０８に配信する（ステップ６１４）。更なる実施例では、エンドユーザへのストリームレット送出ステップ６１４が、ビューワ４０８上で映像及び／又は音響ストリームレットを奏するステップを具える。ストリームレットが局地的に保存されない場合（ステップ６０８）は、ストリームレットリクエストが、ネットワークコントローラモジュール４０６に進む。次いで、ネットワークコントローラモジュール４０６が、ウエブサーバ１１６からストリームレットをリクエストする（ステップ６１６）。ストリームレットが受信されると、ネットワークコントローラモジュール４０６は、ストリームレットをストリームレットキャッシュモジュール４０４へ進める。ストリームレットキャッシュモジュール４０４は、ストリームレットを保存する（ステップ６１８）。代替的に、次いでストリームレットキャッシュモジュール４０４は、ストリームレットを保存して（ステップ６１８）、そのストリームレットをエージェントコントローラモジュール４０２に進め、その後方法６００が、上記の動作６１０から続けられる。

図７を参照すると、本発明による適応レートシフティングコンテントストリーミング環境内でストリームレットをリクエストする方法７００の一実施例を示す概略フローチャート図が示されている。方法７００は、図６の動作６１１としての一実施例に使用することができる。方法７００がスタートし、エージェントコントローラモジュール４０２が図６を参照して上述したようなストリームレットを受信する（ステップ７０４）。エージェントコントローラモジュール４０２は、次いで、リクエストしたストリームレットの受信時間をモニタする（ステップ７０６）。一の実施例では、エージェントコントローラモジュール４０２は、各ストリームレット応答についての順次受信した時間の間の時間インターバルΔをモニタする。対応するリクエストの順番に関連するこの応答の順番は、関係しない。

ネットワーク行動の特徴は、時に非常に突然に変動するので、所定のΔはどれも別のΔから実質的に変化することがある。この変動を補償するために、エージェントコントローラモジュール４０２は、再生長さＳのストリームレットについてｎ個のサンプルの窓全域のパフォーマンス率ｒを計算する（ステップ７０８）。一の実施例では、パフォーマンス率ｒは、次の式を用いて計算される。

多数の同時ストリームレットを処理するため、およびパフォーマンス率ｒの代表値をよりよく判定するために、エージェントコントロールモジュール４０２は、相乗平均を計算するかあるいは代替的に、サイズｍの窓全域の等価平均アルゴリズムを計算し、パフォーマンスファクタφを得る：

再生品質をアップシフトする（ステップ７１０）かどうかについての方針決定は、φ_{ｃｕｒｒｅｎｔ}をトリガスレッシュホールドΘ_ｕｐと比較することによって開始する。

であれば、次により高品質のストリームへのアップシフトが考えられる（ステップ７１６）。一の実施例では、トリガスレッシュホールドΘ_ｕｐが、現在の先読みマージン（すなわち、現在の再生時間インデックスで表示するステージングモジュール４０９によってシーケンシャルに編集された連続的に入手可能なストリームレットの量）に関連するファクタの組み合わせと、最小安全マージンとによって決定される。一の実施例では、最小安全マージンは、２４秒である。先読みマージンが小さいほど、Θ_ｕｐが大きく、より大きな先読みマージンが、ネットワークの混乱に耐えるように設定されるまでアップシフティングを止めることになる。エージェントコントローラモジュール４０２が、品質のアップシフトを保持することができる（ステップ７１６）のであれば、エージェントコントローラモジュール４０２は、品質をアップシフトさせて（ステップ７１７）、順次より高品質のストリームをリクエストする。より高品質ストリームの使用が保持可能かどうかの決定（ステップ７１６）は、より高品質ストリームの性能ファクタφ_{ｈｉｇｈｅｒ}の見積もりを、Θ_ｕｐと比較することによって行われる。

であれば、より高品質のストリームの使用が保持可能であると考えられる。より高いストリームレートが保持可能であるかどうかの決定（ステップ７１６）が「ｎｏ」である場合、エージェントコントロールモジュール４０２は、ストリーム品質のアップシフト（ステップ７１７）を試みないであろう。ストリームの終りに達すると（ステップ７１４）、方法６１８が終了する（ステップ７１６）。

アップシフト７１０を試みるべきかどうかの決定が「ｎｏ」である場合、ダウンシフトを行うべきかどうかの決定（ステップ７１２）が行われる。一の実施例では、トリガスレッシュホールドΘ_ｄｏｗｎはΘ_ｕｐと同様の方法で決定される。φ_{ｃｕｒｒｅｎｔ}＞Θ_ｄｏｗｎであれば、ストリーム品質が適当であり、エージェントコントローラモジュール４０２は、ストリーム品質をダウンシフトしない（ステップ７１８）。しかしながら、

であれば、エージェントコントロールモジュール４０２は、ストリーム品質をダウンシフトする（ステップ７１８）。ストリームの終りに届かない場合（ステップ７１４）、エージェントコントローラモジュール４０２は、リクエストを開始して、より低品質のストリームレットを受信して（ステップ７０４）、方法６１８を再度開始する。もちろん、上述の式とアルゴリズムは、説明のためだけのものであり、代替のストリームレットモニタリングソリューションによって置き換えることができる。

本発明は、その精神あるいは本質的な特徴から外れることなく、その他の特定の形で実施することができる。上述した実施例は、全ての点において説明だけのためのものであり、限定するものではないと考えるべきである。本発明の範囲は、従って、上述の説明によってではなく、請求の範囲によって示される。請求の範囲の意味するところおよび均等の範囲内にある全ての変更は、その範囲内に包含されるものである。

本発明の利点を容易に理解できるようにするために、上記に簡単に述べた本発明のより特定の記述を、添付図面に記載されている特別な実施例を参照して示す。これらの図面は、本発明の典型的な実施例のみを示すものであり、その範囲を限定すると考えられるものではないと理解され、本発明は、添付図面の使用を通じての更なる特定や詳細によって記載され、説明される。
図１は、本発明に係るストリーミングコンテントの適応レートをシフトするシステムの一実施例を示す概略ブロック図である； 図２ａは、本発明によるコンテントファイルの一実施例をグラフィカルに示す概略ブロック図である。 図２ｂは、本発明にかかる品質および帯域の変化の度合いを有する複数のストリームの一実施例を示す概略ブロック図である。 図２ｃは、本発明によって複数のストリームレットに分割されたストリームの一実施例を示す概略ブロック図である。 図３は、本発明によるコンテントモジュールの一実施例を示す概略ブロック図である。 図４は、本発明によるクライアントモジュールの一実施例をグラフィカルに示す概略ブロック図である。 図５は、本発明によるコンテント処理方法の一実施例を示すフローチャートである。 図６は、本発明による複数のストリームレットの再生方法の一実施例を示すフローチャートである。 図７は、本発明による適応レートコンテントストリーミング環境内にあるストリームレットをリクエストする方法の一実施例を示すフローチャートである。

Claims (34)

1. 適応レートコンテントストリーミング装置において、当該装置が：
   少なくとも複数のストリームレットの部分を同時にリクエストするように構成されたエージェントコントローラモジュールであって；
   当該エージェントコントローラモジュールがストリームレットリクエストへの順次の応答処理を連続的にモニタするように更に構成されており、この応答処理に応じて、より高品質あるいはより低品質のストリームレットをリクエストするエージェントコントローラモジュールと；
   ストリームレットをステージして、コンテントプレーヤで再生するストリームレットを編集するように構成したステージモジュールと；
   を具えることを特徴とする装置。
2. 請求項１に記載の装置において、前記エージェントコントローラモジュールが、コンテントサーバとの多数の伝送制御プロトコル（ＴＣＰ）接続を設定し、ビットレートが変化するストリームレットをリクエストするように構成されていることを特徴とする装置。
3. 請求項１に記載の装置において、各ストリームレットが更に、コンテントファイルの一部を具えることを特徴とする装置。
4. 請求項１に記載の装置において、前記ストリームレットがハイパーテキスト送信プロトコルファイルを具えることを特徴とする装置。
5. 請求項３に記載の装置において、エージェントコントローラモジュールが、ストリームレットリクエストへの応答によってパフォーマンスファクタを生成するように構成されていることを特徴とする装置。
6. 請求項４に記載の装置において、エージェントコントローラモジュールが、前記パフォーマンスファクタが選択したスレッシュホールドより高いときに、より高品質のストリームレットへアップシフトするように構成されており、前記エージェントコントローラモジュールが、ファクタの組み合わせによってより高品質の再生が保持できるかどうかを決定することを特徴とする装置。
7. 請求項５に記載の装置において、前記ファクタの組み合わせが、前記ステージングモジュールに保存されている連続的に入手可能なストリームレットの量と、最小安全マージンと、現在の先読みマージンからなる群から選択されることを特徴とする装置。
8. 請求項４に記載の装置において、前記エージェントコントローラモジュールが、前記パフォーマンスファクタが第２の選択されたスレッシュホールド以下であるときに、より低品質のストリームレットにダウンシフトするように構成されていることを特徴とする装置。
9. 請求項１に記載の装置において、前記エージェントコントローラモジュールが更に、ストリームレットリクエストと、ストリームレットプレリクエストを予想して、早送り、ランダムスキップ、および巻き戻し機能が可能であるように構成したことを特徴とする装置。
10. 請求項１に記載の装置において、前記エージェントコントローラモジュールが、最初に低品質のストリームレットをリクエストしてコンテントファイルの簡単な再生を可能とし、パフォーマンスファクタに従って順次アップシフトするように構成されていることを特徴とする装置。
11. 適応レートコンテントストリーミングシステムにおいて、当該システムが：
    データ通信ネットワークと；
    前記データ通信ネットワークに接続され、コンテントを処理し、複数の高品質及び低品質のストリームを生成するように構成されたコンテントモジュールを有するコンテントサーバと；
    各々が複数のストリームレットを具える前記高品質及び低品質のストリームと；
    少なくとも複数のストリームレットの部分を同時にリクエストするように構成したエージェントコントローラモジュールと；
    更にストリームレットリクエストに対する順次の応答の進行を連続的にモニタし、この応答の進行に従って、より高品質あるいはより低品質のストリームレットをリクエストするように構成された前記エージェントコントローラモジュールと；
    前記ストリームレットをステージして、コンテントプレーヤ上で再生するストリームレットに編集するステージモジュールと；
    を具えることを特徴とするシステム。
12. 請求項１１に記載のシステムにおいて、前記エージェントコントローラモジュールが前記コンテントサーバと複数の伝送制御プロトコル（ＴＣＰ）接続を設定し、ビットレートが変化するスリームレットをリクエストするように構成されていることを特徴とするシステム。
13. 請求項１１に記載のシステムにおいて、各ストリームレットが更に、コンテントファイルの一部を具えることを特徴とするシステム。
14. 請求項１３に記載のシステムにおいて、前記エージェントコントローラモジュールが、前記ストリームレットリクエストへの応答によってパフォーマンスファクタを生成するように構成されていることを特徴とするシステム。
15. 請求項１４に記載のシステムにおいて、前記エージェントコントローラモジュールが、前記パフォーマンスファクタが選択したスレッシュホールドより大きいときに、より高品質のストリームレットにアップシフトするように構成されており、前記エージェントコントローラモジュールが、より高品質の再生がファクタの組み合わせに応じて保持できるかどうかを決定することを特徴とするシステム。
16. 請求項１５に記載のシステムにおいて、前記ファクタの組み合わせが、前記ステージモジュール内に保存されている連続的に入手可能なストリームレットの量、最小安全マージン、および現在の先読みマージンからなる群から選択されることを特徴とするシステム。
17. 請求項１４に記載のシステムにおいて、前記エージェントコントローラモジュールが、前記パフォーマンスファクタが第２の選択されたスレッシュホールド以下であるときに、より低品質のストリームレットにダウンシフトするように構成されていることを特徴とするシステム。
18. 請求項１１に記載のシステムにおいて、前記エージェントコントローラモジュールが更に、ストリームレットリクエストと、ストリームレットプレリクエストを予想して、早送り、ランダムスキップ、および巻き戻し機能が可能であるように構成したことを特徴とするシステム。
19. 請求項１１に記載のシステムにおいて、前記エージェントコントローラモジュールが、最初に低品質のストリームレットをリクエストしてコンテントファイルの簡単な再生を可能とし、パフォーマンスファクタに従って順次アップシフトするように構成されていることを特徴とするシステム。
20. レート適応ストリームを表示する方法において、当該方法が：
    少なくとも複数のストリームレットの部分を同時にリクエストするステップと；
    ストリームレットリクエストに続く応答の進行を連続的にモニタして、当該応答の進行に従って、より高品質あるいはより低品質のストリームレットをリクエストするステップと；
    前記ストリームレットをステージし、コンテントプレーヤ上での再生用に前記ストリームレットを編集するステップと；
    を具えることを特徴とする方法。
21. 請求項２０に記載の方法が更に、コンテントサーバとの多数の伝送制御プロトコル（ＴＣＰ）接続を設定するステップと、ビットレートが変化するストリームレットをリクエストするステップとを具えることを特徴とする方法。
22. 請求項２０に記載の方法が更に、ストリームレットリクエストからの応答に従ってパフォーマンスファクタを生成するステップを具えることを特徴とする方法。
23. 請求項２０に記載の方法が更に、前記パフォーマンスファクタが選択されたスレッシュホールドより大きいときに、より高品質のストリームレットにアップシフトするステップと、前記より高品質の再生が保持できるかどうかを決定するステップを具えることを特徴とする方法。
24. 請求項２０に記載の方法が更に、前記パフォーマンスファクタが第２の選択されたスレッシュホールドより小さいときに、より低品質のストリームレットにダウンシフトするステップを具えることを特徴とする方法。
25. 請求項２０に記載の方法が更に、ストリームレットリクエストと、早送り、ランダムスキップ、および巻戻し機能を可能にする予めリクエストしているストリームレットを予測するステップを具えることを特徴とする方法。
26. 請求項２０に記載の方法が更に、コンテントファイルの簡易再生を可能にする低品質のストリームレットを最初にリクエストするステップと、前記パフォーマンスファクタに応じて順次アップシフトするステップとを具えることを特徴とする方法。
27. レート適応コンテントストリームを表示するための動作を実行するように構成されたコンピュータで読み取り可能なコードを具えるコンピュータで読み取り可能なストレージ媒体において、前記動作が：
    少なくとも複数のストリームレットの部分を同時にリクエストする動作と；
    ストリームレットのリクエストに対する順次の応答の進行を連続的にモニタし、当該応答の進行に応じて、より高品質のストリームレットか、あるいはより低品質のストリームレットをリクエストする動作と；
    前記ストリームレットをステージして、コンテントプレーヤ上での再生用に当該ストリームレットを編集する動作と；
    を具えることを特徴とするコンピュータで読み取り可能なストレージ媒体。
28. 請求項２７に記載のコンピュータで読み取り可能なストレージ媒体において、前記動作が更に、コンテントサーバとの多数の伝送制御プロトコル（ＴＣＰ）接続を設定する動作と、ビットレートが変化するストリームレットをリクエストする動作とを具えることを特徴とするコンピュータで読み取り可能なストレージ媒体。
29. 請求項２７に記載のコンピュータで読み取り可能なストレージ媒体において、前記動作が更に、ストリームレットリクエストからの応答によってパフォーマンスファクタを生成する動作を具えることを特徴とするコンピュータで読み取り可能なストレージ媒体。
30. 請求項２７に記載のコンピュータで読み取り可能なストレージ媒体において、前記動作が更に、前記パフォーマンスファクタがスレッシュホールドより大きいときに、より高品質のストリームレットにアップシフトする動作と、前記より高品質の再生が保持できるかどうかを決定する動作とを具えることを特徴とするコンピュータで読み取り可能なストレージ媒体。
31. 請求項２７に記載のコンピュータで読み取り可能なストレージ媒体において、前記動作が更に、前記パフォーマンスファクタが第２のスレッシュホールドより小さいときに、より低品質のストリームレットにダウンシフトする動作を具えることを特徴とする方法。
32. 請求項２７に記載のコンピュータで読み取り可能なストレージ媒体において、前記動作が更に、ストリームレットリクエストと、早送り、ランダムスキップ、および巻き戻し機能を可能にする、予めリクエストしているストリームレットを予測する動作を具えることを特徴とするコンピュータで読み取り可能なストレージ媒体。
33. 請求項２７に記載のコンピュータで読み取り可能なストレージ媒体において、前記動作が更に、コンテントファイルの簡易再生を可能にする低品質のストリームレットを最初にリクエストする動作と、前記パフォーマンスファクタに応じて順次アップシフトする動作とを具えることを特徴とするコンピュータで読み取り可能なストレージ媒体。
34. レート適応コンテントストリームを表示する装置において、当該装置が：
    少なくとも複数のストリームレットの部分を同時にリクエストする手段と；
    ストリームレットのリクエストに続く応答の進行を連続的にモニタし、当該応答の進行に応じて、より高品質のストリームレットか、あるいはより低品質のストリームレットをリクエストする手段と；
    前記ストリームレットをステージして、コンテントプレーヤ上での再生用に当該ストリームレットを編集する手段と；
    を具えることを特徴とする装置。

Images