JP5659154B2 - クライアント側ストリームスイッチング - Google Patents

Description

本発明は、クライアント側ストリームスイッチングに関する。

一般の人が、コンピュータで使用するためにネットワーク上のメディアコンテンツにアクセスすることはますます普通のことになってきた。特に、インターネットは、多岐に利用できるデジタルコンテンツのダウンロードおよびストリーミングを容易にした。多くの人が、通常はユーザが制御できない予定に基づいてユーザにメディアを押し付ける、無線受信、ケーブル伝送、衛星音声／ビデオ、および他の分散ソースなどの従来のコンテンツ配信方法に頼らずにストリーミングメディアを検出し、取り出し、楽しむためにネットワークアクセスを使用している。

インターネット上でのストリーミングメディアに関する１つの具体的な問題は、ある人のコンピュータとホストとの間の帯域幅が制限されていることである。多くの人が、ストリーミングメディア受信時の望ましくない遅延またはメディアのストリームの再生中の中断を経験している。コンピュータへのメディアのストリームの受信を早める１つの解決策は、そのメディアのストリームに関連するビットレートを削減することによってなど、メディアの質を下げることである。しかし、多くの場合、人は、ネットワーク接続帯域幅に基づいて変わる可能性がある質が可能な限り最高であるメディアのストリームを所望する。したがって、人がストリーミングメディアの受信中に望ましくないと気付く中断を削減しつつ、ストリーミングメディアの質を改善することが望ましい。

詳細な説明は、添付の図を参照して行う。図中、参照番号の最左の数字（複数の場合がある）は、その参照番号が最初に示される図を識別する。異なる図中の同じ参照番号が、類似する、または同一の項目を示す。

クライアント側ストリームスイッチングの１つまたは複数の実施形態が実装できる実例となるコンピューティング環境を示す絵図である。 本開示の１つまたは複数の実施形態によるストリームスイッチングの実例となるプロセスの流れ図である。 本開示のいくつかの実施形態に従って帯域幅を監視し、ビットレートを選択する実例となるプロセスの流れ図である。 本開示の１つまたは複数の実施形態に従って第1のストリームから第２のストリームに移行する実例となるプロセスの流れ図である。 本開示の１つまたは複数の実施形態に従ってクライアントにとって理想的なビットレートを決定し、記憶する実例となるプロセスの流れ図である。 本開示のいくつかの実施形態に従ってクライアント上のストリーミングを監視するために、実例となるユーザインタフェースを含む環境を示す。 本開示のいくつかの実施形態に従って、可変ビットレート（ＶＢＲ）のメディアのストリームの部分の複雑度を決定するためにメディアのストリームを分析するための実例となるチャートを示す。 本開示の１つまたは複数の実施形態に従ってクライアントへのストリーミングを調整するために、複雑度データを有するメディアのストリームの分析を使用する実例となるプロセスの流れ図である。 図１のホストサーバと関連するモジュールの１つまたは複数の実施形態の実例となるブロック図を示す。

（概要）
ユーザがストリーミングメディアを受信するとき、一般に、ユーザは中断のない高品質のメディアストリームを所望する。しかし、ホストとクライアントの間のネットワーク接続の帯域幅を含めた多くの要因が、高品質であるだけではなく、中断もないメディアのストリームをユーザに提供することを困難にすることがある。本開示の実施形態によれば、中断されないまたは実質的に中断されないメディアのストリームを保証できる、第１のビットレートのメディアストリームがユーザに送信できる。次に、ホストは、ユーザが中断されないメディアのストリームを受信する間にストリームの質を調整するために、他の考えられる要因の中でも将来の帯域幅の測定値に基づいてさらに高いまたはさらに低いビットレートにそのメディアのストリームを移行することができる。

本明細書に説明するように、メディアストリームは可変ビットレート（ＶＢＲ）または固定ビットレート（ＦＢＲ）を有することができる。ＶＢＲは、平均または中央のビットレート値など、メディアのストリームを表すビットレート値を含む。ＶＢＲのメディアのストリームでは、メディアのストリームの部分がより高いまたはより低いビットレート値を有することがある。たとえば、ビデオのアクションシーンが複雑な部分であり、高ビットレート値を含むことがある。一方、風景、背景等に変化がほとんどない別のシーンは複雑ではなく、低ビットレート値を有することがある。対照的に、ＦＢＲのメディアのストリームは、一定のビットレート値を有する。ＦＢＲストリームは、一般に、メディアのストリームの複雑度に基づいてメディアの質のレベルを調整し、したがってビットレートを一定に保つためにきわめて複雑な部分の間に質を下げる。本明細書に説明するように、ビットレートは、特別の定めがない限りＶＢＲまたはＦＢＲのどちらであってもよい。

説明のため、クライアント側ストリームスイッチングは、ウェブサイトをサポートするホストから音声および／またはビデオをストリーミングするという状況で説明する。この状況の実例となる実装形態を以下に提供する。ただし、説明するコンテンツスタイルの検出技法は、他の状況で実装できる。さらに、示されるアーキテクチャによって実施されるようにクライアント側ストリームスイッチングを実装するために、他の分散構成を使用することもできる。

（実例となるシステムアーキテクチャ）
図１は、クライアント側ストリームスイッチングの１つまたは複数の実施形態が実装できる実例となるコンピューティング環境１００を示す絵図である。環境１００では、ホスト１０２は、ネットワーク１０６を経由してクライアント１０４と通信できる。実施形態では、ホスト１０２が、ユーザ１０８へのプレイバックのために、クライアント１０４にストリーミングメディアを送信できる。

１つまたは複数の実施形態によれば、ホスト１０２は、おそらくクラスタ内にまたはサーバファームとして配列される１台または複数のサーバ１１０（１）、．．．１１０（Ｎ）を含むことができる。ホスト１０２は、ウェブサーバまたは別のタイプの情報サーバである場合がある。ホスト１０２をサポートするために、他のサーバアーキテクチャを使用することもできる。ホスト１０２は多くのユーザからの要求を処理し、応答して、クライアント１０４でレンダリングできる多様なデータのストリームを供給することができる。いくつかの実施形態では、ホスト１０２は、オンライン小売業者、エンターテインメントサイト、音声および／またはビデオ配布サイト、情報サイト、ソーシャルネットワーキングサイト、ブログサイト、ニュースおよびエンターテインメントサイト等々を含めた、ユーザ対話をサポートするウェブサーバである。

実例となる実施形態では、ホスト１０２は、メディアデータベース１１２のホストとなるウェブサーバを表す。メディアデータベース１１２は、ユーザ１０８へのプレイバックのために、ホスト１０２からネットワーク１０６を経由してクライアント１０４に送信できるメディアの集合体を格納する。用語「メディア」は、ネットワーク１０６を介してホスト１０２からクライアント１０４にストリーミングできる、映画、テレビ番組、プレビュー、個人のビデオ録画、音楽、ニュース、または他のあらゆるタイプのビデオおよび／または音声など、ユーザ１０８にストリーミングできる任意のビデオおよび／または音声を含む。

図１では、ホスト１０２は、メディアデータベース１１２のコンテンツをユーザ１０８に送信するためにストリーミングモジュール１１４を含むことができる。いくつかの実施形態では、ストリーミングモジュール１１４は、ユーザ１０８へのビデオの表示を可能にする１台または複数のビデオレンダリング装置を含むことができる。さらに、ストリーミングモジュール１１４は、メディアデータベース１１２のコンテンツを記憶するための１つまたは複数のバッファを管理できる。１つまたは複数の実施形態では、ストリーミングモジュール１１４はストリーミング待ち行列１１６と対話し、バッファを管理する、コンテンツを記憶する、またはそれ以外の場合、ストリーミングモジュール１１４によって処理されるメディアデータベース１１２からのメディアを維持することができる。

１つまたは複数の実施形態によれば、移行モジュール１１８はストリーミング待ち行列１１６と対話し、第１のビットレートでのメディアのストリームから第２のビットレートでのメディアのストリームに移行できる。たとえば、および制限なく、第１のビットレートでのメディアのストリームが、６００ｋｂｐｓで符号化されたビデオクリップであることがあり、一方、第２のビットレートでのメディアのストリームが、９００ｋｂｐｓで符号化された同じクリップであることがある。したがって、質（ピクセル、解像度、音声圧縮等）は異なる可能性があるが、そのメディアのストリームのコンテンツは同じである可能性がある。移行モジュール１１８によって、ホスト１０２は、ユーザ１０８へのプレイバックのために中断されないまたは実質的に中断されない、クライアント１０４へのメディアのストリームを維持しながら、第１ビットレートでのメディアのストリームから第２のビットレートでのメディアのストリームへの連続ストリーミング移行を容易にさせることができる。

ヒューリスティックモジュール１２０は、移行モジュール１１８によって提供される移行プロセス、および／またはストリーミングモジュール１１４によって提供されるストリーミングプロセスを手助けするためにデータを提供できる。たとえば、ヒューリスティックモジュール１２０は、クライアント１０４が中断されないストリーミングコンテンツを受信できるようにするために、メディアデータベース１１２からのストリーミングメディアでのバッファの充填をいつ開始するのかを判定できる。いくつかの実施形態では、ヒューリスティックモジュール１２０は、他の考えられる要因の中でもネットワーク１０６の測定された帯域幅に基づいて、ストリーミングメディアにとって理想的なビットレートを決定できる。ヒューリスティックモジュール１２０は、測定された帯域幅に基づいて、ユーザ１０８に最高のビットレートのメディアストリームを提供するためにメディアコンテンツのビットレートの選択を動的に制御できる。

１つまたは複数の実施形態によれば、ストリーミングモジュール１１４、移行モジュール１１８、およびヒューリスティックモジュール１２０の内の１つまたは複数が、クライアント１０４上で実装できる。クライアント１０４は、ストリーミングモジュール１１４の機能の少なくとも一部を含むことができる。たとえば、クライアント１０４は、ユーザ１０８へのプレイバックのためにメディアのストリームを受信し、そのメディアのストリームを出力するためのレンダリングソフトウェアを含むアプリケーションを含むことができる。さらに、クライアント１０４は、第１のメディアのストリームと第２のメディアのストリームの間で移行するための移行モジュール１１８を含むことができる。いくつかの実施形態では、ヒューリスティックモジュール１２０の機能のすべてまたは一部が、クライアント１０４上に実装できる。たとえば、ヒューリスティックモジュール１２０の、理想的なビットレートを計算する機能は、ネットワーク１０６の帯域幅のクライアント側の測定によりストリーミングメディアにとっての理想的なビットレートを決定できるようにするために、クライアント１０４上に実装できる。

図１のネットワーク１０６は、ローカルエリアネットワーク（「ＬＡＮ」）、ワイドエリアネットワーク（「ＷＡＮ」）等のより大きなネットワーク、またはインターネットなどのネットワークの集合体であることがある。ＴＣＰ／ＩＰなどのネットワーク通信用のプロトコルは、コンピュータネットワークの当業者によく知られており、本明細書に説明するネットワーク接続を実施するために使用できる。当業者は、本書に開示する概念が、関連文書および付随するファイル、スクリプト、およびデータベースを格納するサーバを接続するローカルエリアネットワークまたはワイドエリアネットワーク、あるいは音声ファイルまたはビデオファイル、文書、スクリプト、データベース等へのアクセスを提供するセットトップボックスまたは他の情報機器を含む放送通信ネットワーク等の、他の対話型環境でも使用できることを認識する。

前記に説明したように、クライアント１０４は、ホスト１０２からメディアコンテンツを受信できる。クライアントは、コンピュータ１０４（１）、（受信機を介して）テレビ１０４（２）、携帯電話１０４（３）（たとえば、スマートフォン等）、携帯情報端末（ＰＤＡ）１０４（Ｍ）、またはホスト１０２からストリーミングメディアを受信し、ユーザ１０８による使用のためのそのストリーミングメディアを表示する、および／または送ることのできる他の装置を含むことができる。たとえば、クライアント１０４がセットトップボックス、ゲーム機等であることもある。

示されるように、各クライアント１０４（１）、．．．１０４（Ｍ）には、データおよびアプリケーションを記憶し、データを処理するために１台または複数のプロセッサ１２２、およびメモリ１２４が備えられている。メモリ１２４は、ホスト１０２から受信されるストリーミングメディアなどのデータを記憶するために１つまたは複数のバッファ１２６を含むことができる。いくつかの実施形態によれば、プレゼンテーションアプリケーション１２８はメモリ１２４内に記憶され、ホスト１０２からストリーミングメディアを提供するためにプロセッサ１２２上で実行する。このプレゼンテーションアプリケーション１２８は、クライアント１０４の関連ディスプレイ上で、ホスト１０２によって供給されるストリーミングメディア１３０をレンダリングできる。たとえば、プレゼンテーションアプリケーション１２８は、ストリーミングメディア１３０を処理し、再生することができるメディアストリーミングプラグインで構成されたブラウザであることがある。いくつかの実施形態では、プレゼンテーションアプリケーション１２８は、ストリーミングモジュール１１４、移行モジュール１１８、および／またはヒューリスティックモジュール１２０の内のすべてまたは一部を含んでよい。

いくつかの実施形態では、ホスト１０２およびクライアント１０４の構成は、ウェブをベースにしたシステムとして構成できるか、あるいは他の可能性の中でも、ケーブルテレビヘッドエンドおよびテレビのセットトップボックスの環境、対応するリモートサービスプロバイダのあるデジタルビデオレコーダ、モバイル機器および対応するリモートサービスプロバイダなどのデジタルビデオレコーダなどの他のタイプのクライアント／サーバをベースにした通信および関連アプリケーション論理が使用できる。ユーザ１０８がホスト１０２にアクセスするとき、クライアント１０４は、たとえばユニフォームリソースロケータ（ＵＲＬ）等の形を取る要求を、サーバ１１０（１）から（Ｎ）に提出する。要求を受け取ると、サーバ１１０（１）〜（Ｎ）は、ストリーミングメディアをクライアント１０４に返す。

（実例となる動作）
図２は、本開示の１つまたは複数の実施形態によるストリームスイッチングの実例となるプロセス２００の流れ図である。プロセス２００は、論理フローグラフ内のブロックの集合体として示されている。論理フローグラフは、ハードウェア、ソフトウェア、またはその組み合わせで実装できる一連の動作を表す。ソフトウェアとの関連では、ブロックは、１つまたは複数のプロセッサによって実行されると、列挙された動作を実行するためのコンピュータ実行可能命令を表している。一般に、コンピュータ実行可能命令は、特定の機能を実行する、または特定の抽象データタイプを実施する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含む。動作を説明する順序は、制限として解釈されることを意図されておらず、プロセスを実施するために、任意の数の説明されるブロックが任意の順序で、および／または並列で結合できる。説明のために、プロセス２００は、図１の環境１００を参照して説明する。プロセス２００に加えて、本開示全体で説明する他のプロセスは相応して解釈されるものとする。

プロセス２００は、第１の接続速度で、ネットワーク１０６を経由してホスト１０２とクライアント１０４の間の接続を開始することによって、２０２で開始できる。たとえば、より多くの、またはより少ないビットレートを含めた他のビットレートが使用できるが、ストリーミングモジュール１１４は、５００ｋｂｐｓ、１０００ｋｂｐｓ、および１５００ｋｂｐｓ等の異なるビットレートで符号化されるストリーミングメディアを提供できる。２０２で、クライアント１０４は、ホスト１０２との接続を確立し、第１のビットレートでのストリーミングメディアの受信を可能にする。

１つまたは複数の実施形態によれば、２０４で、ホスト１０２はクライアント１０４に第１のビットレートでストリーミングメディアを送信し、バッファ１２６の内の１つなどの初期バッファを充填することができる。第１の活動モニタ２０６は、第１のビットレートを有する第１のストリーム２０８、および第２のビットレートを有する第２のストリーム２１０と関連する活動のグラフ表示を含む。第１のストリーム２０８および第２のストリーム２１０と関連する、実例となる活動は、それぞれ第１のグラフ２１２および第２のグラフ２１４に表される。第１のグラフ２１２および第２のグラフ２１４は、ｙ軸の充填レベル（つまり、バッファ内のデータの量）およびｘ軸の時間を含み、メディアの各ストリームのバッファ活動を描くために使用される。第１のグラフ２１２に示すように、クライアント１０２の初期バッファは、動作２０４によってストリームメディアで充填される。初期バッファ充填２１６は、動作２０４の間の経時的なストリーミングメディアの実例となる充填レベルを表す。

２１８で、初期バッファ充填レベルが動作２０４から初期バッファ容量に達するとき、プレゼンテーションアプリケーション１２８が、第１のストリーム２０８の再生を開始する。２２０で、より大きいバッファが開始され、ホスト１０２からのストリーミングデータで充填され得る。そのより大きいバッファは、初期バッファよりも高い容量を含む、バッファ１２６の内の１つであることがある。いくつかの実施形態では、より大きいバッファは初期バッファと同じバッファであってよいが、より大きい容量をもってよい。第２の活動モニタ２２２は、ストリーミングメディアを記憶する大きいバッファを表す、初期バッファ充填２１６に図示される初期バッファの容量を超える、より大きいバッファ充填２２４を示す。アクティブインジケータ２２６は、第１のストリーム２０８が、動作２１８でストリーミングメディアを提供するために使用されることを示す。

いくつかの実施形態によれば、２２８で第２の接続速度が、クライアント１０４とホスト１０２の間で開始できる。たとえば、ホスト１０２は、ホストとクライアント１０４の間のネットワーク１０６によって提供される帯域幅が、第１のストリーム２０８のビットレートよりも高いビットレートを有するメディアの第２のストリーム２１０のストリーミングをサポートするほど十分に大きく、したがってユーザ１０８へのより高品質のメディアのストリームの出力を可能にすると判定できる。代わりに、ホスト１０２は、帯域幅が圧縮され、中断されないメディアのストリームをサポートするために、第１のストリーム２０８のビットレートよりも低いビットレートを有する第２のストリーム２１０のストリーミングだけをサポートできると判定できる。したがって、ホスト１０２は、２２８でクライアント１０４への伝送のために第２のストリーム２１０を構成し、開始できる。

２３０で、第２のストリームは、クライアント１０４上に常駐するバッファ１２６の内の１つなど、初期バッファの充填を開始できる。第３の活動モニタ２３２は、削減された大きいバッファ充填２３４の監視を続ける第１のグラフを示す。一方、第２のグラフ２１４は、第２のストリーム２１０によって提供される初期バッファと関連する第２の初期バッファ充填２３６を示す。プレゼンテーションアプリケーション１２８は、第３の活動モニタ２３２の下でアクティブインジケータ２２６によって示されるように、２３０で第１のストリームを再生し続けることができる。

２３８で、プレゼンテーションアプリケーション１２８は、第２の初期バッファ充填レベルが動作２３０から初期の容量に達するときに、第２のストリーム２１０の再生を開始する。２４０で、第２の大きいバッファが開始され、ホスト１０２からのストリーミングデータで充填される。第２の大きいバッファ２２０は、より高い容量を含み、第２のストリームによって提供されるデータを記憶する、バッファ１２６の内の１つであってよい。たとえば、より大きいバッファは初期バッファと同じバッファであってよいが、より大きい容量をもってよい。第４の活動モニタ２４２は、ゼロバイトの充填レベルまで削減されたとして第１のストリーム２０８を描く、空の大きいバッファ充填２４４を示す。一方、第２のグラフ２１４は、第２のより大きいバッファ充填２４６を示す。アクティブインジケータ２２６は、第２のストリーム２１０が、動作２３８でストリーミングメディアを提供するために使用されることを示す。

プロセス２００は、一般に第２のストリーム２１０を、第１のストリーム２０８のビットレートよりも高いビットレートを有するとして説明するが、このプロセスは、第１のストリームのビットレートから第２のストリームに関連するより低いビットレートに移行することによっても動作できる。したがって、プロセス２００は、一般に、第１のビットレートの第１のストリームから第２のビットレートの第２のストリームへの移行を示し、そこでは第２のビットレートが第１のビットレートよりも高いまたは低いことがある。

図３は、本開示のいくつかの実施形態に従って帯域幅を監視し、ビットレートを選択する実例となるプロセス３００の流れ図である。プロセス３００の動作を説明する順序は、制限として解釈されることを意図されておらず、プロセスを実施するために、任意の数の説明されるブロックが任意の順序で、および／または並列で結合できる。説明のために、プロセス３００は、図１の環境１００を参照して説明する。

３０２で、ホスト１０２は、ネットワーク１０６を経由してクライアント１０４との接続を開始する。いくつかの実施形態では、ホスト１０２は、以前の帯域幅決定を使用してネットワーク接続を分析することによって、または他の既知の技法によって等、接続の帯域幅を決定できる。３０４で、ホスト１０２は、クライアント１０４に常駐する初期バッファを満たすために第１ビットレートでメディアをストリーミングできる。上記に説明したように、ホスト１０２は単一のコンテンツのために多くの異なるビットレートで符号化されたメディアのストリームを含むことができる。ストリーミングモジュール１１４は、中断されないまたは実質的に中断されないメディアのストリームを維持しつつ、最高品質のメディアを提供するために、クライアント１０４へストリーミングのためのメディアの考えられる最高のビットレートを選択できる。いくつかの実施形態では、第１のメディアのストリームは、メディアの中断されないまたは実質的に中断されないストリーミングを保証するために、相対的に低いビットレート値を含むことがある。たとえば、ホスト１０２がそのメディアのストリームの４つの符号化ビットレートバージョンを有する場合、ホストは、動作３０４の間にクライアント１０４へ最低のまたは２番目に低いメディアのビットレートストリームを送信できる。初期バッファは、メディアの第１のストリームの時間またはデータサイズに基づいた所定の容量を含むことができる。いくつかの実施形態では、初期バッファは第１のメディアのストリームの２秒から５秒を含むことがある。一方、他の量のストリーミングメディアは、メディアのタイプ（たとえば音声および／またはビデオ）およびメディアの解像度（たとえば低解像度、高解像度等）に応じて初期のバッッファに記憶できる。

いくつかの実施形態では、ホスト１０２は３０４で、クライアント１０４とのネットワーク接続の帯域幅を計算できる。たとえば、ホスト１０２は、クライアント１０４が既知のデータサイズをもつ初期バッファを充填するためにどのくらいの時間を要するのかを決定できる。計算された帯域幅は、以下により詳細に説明する、第２のビットレートを選択するために使用できる理想的なビットレートを決定するために使用できる。

１つまたは複数の実施形態によれば、３０６で、第１のメディアのストリームがユーザ１０８に出力される。たとえば、クライアント１０４は、いったん初期バッファが容量まで充填されると、初期バッファ内に記憶されるデータを使用して第１のメディアのストリームを再生できる。いくつかの実施形態では、クライアント１０４は、初期バッファがいっぱいになるまでメディアを再生できず、それによってユーザがプレゼンテーションアプリケーション１２８上での中断されないまたは実質的に中断されないメディアのストリーミングを経験することを保証する。したがって、初期バッファのサイズは、いったんユーザがメディアのストリームの出力の受信を開始すると、ユーザ１０８によってメディアの中断されないまたは実質的に中断されないメディアのストリーミングの受信を保証するために選択される。

３０８で、ホスト１０２は、クライアント１０４の上に常駐するより大きいバッファを充填するために、第１のビットレートでメディアをストリーミングできる。そのより大きいバッファは、初期バッファとしてデータを記憶するが、より大きい容量をもつ同じバッファであることがある。たとえば、初期バッファは、ストリームが動作３０６でいつ再生できるのかを示すための閾値決定であることがある。代わりに、そのより大きいバッファは、初期バッファとは異なるバッファであることもある。構成に関わらず、初期バッファおよびより大きいバッファは、クライアント１０４がユーザに中断されないまたは実質的に中断されないメディアのストリームを提供できるようにする。動作３０４と同様に、ホスト１０２は、３０８でクライアント１０４とのネットワーク接続の帯域幅を計算できる。プロセス３００のいくつかの実施形態では、帯域幅は、動作３０４、動作３０８または両方で計算できる。

３１０で、ホスト１０２は、上記に説明したように、バッファ充填速度の測定に加えて、またはバッファ充填速度を測定することなく、システム帯域幅チェックを使用して帯域幅を周期的に計算できる。たとえば、ホスト１０２は、クライアント１０４に既知のデータサイズを有するデータのパケットを送信できる。クライアント１０４は、そのデータのパケットのそれぞれを受信すると、ホスト１０２にメッセージを返し、したがってホストがホストとクライアントの間のネットワーク接続の帯域幅を計算できるようにする。帯域幅を計算する他の既知の技法は、ホスト１０２によって使用され得る。帯域幅の計算は、周期的に、または所定のイベントの後に固定された間隔で発生できる。たとえば、帯域幅の計算は毎秒１回または複数回発生し、ネットワーク帯域幅を連続して監視できる。

１つまたは複数の実施形態によれば、ホスト１０２は、３１２でストリームのビットレートを加速するかどうかを決定する。ビットレートは、測定された帯域幅がメディアの使用可能なより高いビットレートストリームをサポートする場合、加速できる。３１２で決定されるようにより高いビットレートが実現可能である場合、ホスト１０２は、ステップ３１４でバッファ充填レベルのステータスを決定できる。たとえば、クライアント１０４はより大きいバッファのバッファ充填レベルを監視できる。より大きいバッファが低充填レベルまたは削減充填レベルを含む場合は、バッファは最終的に空で実行し、メディアのストリームの望ましくない中断を引き起すことがある。バッファ充填レベルが相対的に低い場合、プロセス３００は、３１６で、ビットレートを減速することを先制して決定できる。

いくつかの実施形態では、バッファ充填レベルは、ウォーターマークと呼ばれる所定の最小閾値を有することがある。ホスト１０２は、クライアント１０４を介してバッファ充填レベルを監視し、いつバッファ充填レベルがウォーターマークを下回るのかを判定する。いくつかの実施形態では、ヒューリスティックモジュール１２０がバッファの活動の統計分析を実施し、バッファの充填レベルがゼロバイトに近づく可能性があるかどうかを判定する。たとえば、クライアントは、バッファ充填レベルがウォーターマークを下回った後に、バッファの充填レベルの連続スナップショットとして周期的なサンプルを採取できる。バッファ充填レベルの減少を示す連続周期サンプルは、クライアント１０４への減速されたビットレートストリームのストリーミングを開始するためにホスト１０２を始動できる。しかし、統計分析が、バッファ充填レベルが空で動作しないと判定した場合、ビットレートは変化しないままとなることがあり、プロセス３００は、動作３０６において等、第１のビットレートでストリーミングを続行できる。

３１８で、ホスト１０２は、バッファ１２６の内の1つで記憶し、初期バッファを充填するために、クライアント１０４への新しいビットレートを有するメディアをストリーミングできる。新しいビットレートは、他の考えられる要因の中でもホスト１０２とクライアント１０４の間のネットワーク接続の帯域幅に基づいて、図１のヒューリスティックモジュール１２０によって選択され得る。たとえば、ホスト１０２は、帯域幅がより高いビットレートをサポートできる（つまり、動作３１２での決定が「はい」である）のか、または帯域幅が現在のストリームビットレートをサポートできず、ビットレートを引き下げる必要がある（つまり、動作３１６での決定が「はい」である）のかを判定できる。

いくつかの実施形態では、ヒューリスティックモジュール１２０は、メディアの高品質を維持しつつ、ユーザ１０８へのメディアの中断されないまたは実質的に中断されないストリーミングを提供するために、ストリームにとって最も適した使用可能なビットレートを選択できる。たとえば、ホスト１０２は、Ａ、Ｂ、Ｃ、ＤおよびＥとして示される５つの異なるビットレートで符号化される1個のメディアを含むことがあり、その場合「Ａ」が最低のビットレートで、「Ｅ」が最高のビットレートである。クライアント１０４は、最初に３０６でビットレート「Ｃ」でストリームを再生できる。次に、バッファ充填レベルが、ウォーターマークを下回ることがある。ヒューリスティックモジュール１２０は、ビットレートが、動作３０４、３０８、および３１０の内の１つまたは複数で測定された帯域幅に基づいて、ビットレート「Ａ」またはビットレート「Ｂ」のどちらかに調整されるべきであると判定できる。いくつかの実施形態では、ヒューリスティックモジュール１２０は、新しいビットレートを選択するために使用できる理想的なビットレートを選択的に決定できる。その新しいビットレートは、使用できる次の大きさのビットレート（現在のビットレートよりも高いか、または低いかのどちらか）ではないことがあり、したがってホスト１０２は次に高いまたは次に低いビットレートを有さない別のビットレートにジャンプできる。

３２０で、いったん初期バッファがいっぱいになると、クライアント１０４は新しいビットレートを有するメディアの新しいストリームを再生する。３２２で、３０８での動作と同様に、より大きいバッファがその新しいビットレートを有するストリーミングメディアで充填される。プロセス３００では、無期限に帯域幅の監視および動作３１０〜３２２でのビットレートへの調整を続けることができる。

図４は、本開示の１つまたは複数の実施形態に従って第１のストリームから第２のストリームに移行する実例となるプロセスの流れ図である。プロセス４００の動作を説明する順序は、制限として解釈されることを意図されておらず、プロセスを実施するために、任意の数の説明されるブロックが任意の順序で、および／または並列で結合できる。

１つまたは複数の実施形態によれば、４０２で、ホスト１０２は第１のビットレートでメディアをストリーミングする。４０４で、ホスト１０２は、ユーザにより質の高いメディアを提供することによって、あるいはメディアのストリーム中の考えられる中断を削減するまたは排除するためにより低い質のメディアを提供することによって、第２のビットレートがユーザ経験の改善を実現できると判定できる。４０６で、ヒューリスティックモジュール１２０は、移行実行時を決定し、その移行実行時の間バッファを充填するために第２のメディアのストリームを先へ進めることができる。たとえば、１：１２．００（ｍ：ｓｓ）の実行時で見られるストリームがユーザに送信されることがある。第２ビットレートのメディアのストリームを開始する前に初期バッファを充填するために、ヒューリスティックモジュール１２０は、第２の初期バッファを充填するために必要な時間等々の要因に基づいて、１：１４．００から１：１７．００までのストリーム実行時の範囲がバッファにロードされる必要があると判定できる。この例では、ホストは、初期バッファを充填し、次いでメディアのストリームの中断が最小限の状態で、またはまったく知覚できない状態で、第1のビットレートストリームから第２のビットレートストリームへの移行を同期させるには２秒（２．００）を有するはずである。

４０８では、ホスト１０２は第２のビットレートで初期のバッファを充填する。４１０で、ホストは、第２のビットレートストリームが、第１のビットレートストリームと同期するために休止する必要があるかどうかを判定する。第２のストリームは、第１のビットレートストリームが第２のストリームの開始時間に追いつくまで、４１２でストリーミングモジュール１１４によって休止される。ただし、第２のストリームが休止を必要としない場合には、ホスト１０２は４１４で、第２のストリームが遅延しているかどうかを判定できる。第２のストリームが遅延している場合、４１６で、ストリーミングモジュール１１４は、初期バッファが第２のビットレートストリームで充填されるまで、第１のストリームを休止できる。いくつかの実施形態では、第２のビットレートストリームで充填するために初期バッファにより多くの時間を与えることによって動作４１６の発生を最小限に抑えるために、ヒューリスティックモジュール１２０を調整することができ、したがってユーザ１０８へのメディアの中断の尤度を最小限に抑える。いくつかの実施形態では、ヒューリスティックモジュール１２０は、以前のバッファ充填速度等の履歴データを使用し、ストリーム充填遅延を予測できる。たとえば、以前の充填速度のサンプルは、メディアの第１のストリームからメディアの第２のストリームへの中断されない移行を実施するために必要な将来の充填速度を演算するために記憶し、分析し、使用することができ、したがってストリーム充填の遅延を回避する。

１つまたは複数の実施形態によれば、４１８で、移行モジュール１１８は、クライアント１０４が第１ビットレートのメディアのストリームから第２ビットレートのメディアのストリームへ移行できるようにする。移行モジュール１１８は、中断を引き起こさずに考えられる最長の時間の間、ユーザ１０８に最高のビットレートを提供できる。たとえば、クライアント１０４がより低いビットレートにダウンロードするとき、より高いビットレートストリームが使用できなくなる（つまり、第１のストリームのためのより大きいバッファがゼロバイトまで削減される）までより高いビットレートのストリーム（第１ビットレート）がクライアントに提供することができ、使用できなくなった時点で同期していたより低いビットレートのストリームへの移行が発生することがある。

いくつかの実施形態では、移行モジュール１１８は、ある期間に渡って第１のストリームを第２のストリームにクロスフェードさせ、第１のストリームから第２のストリームに徐々に移行できる。クロスフェードは、第１のストリームから第２のストリームへのユーザが知覚可能な変化を減少させることができる。移行モジュール１１８は、第２のレンダリング装置を第１のレンダリング装置の上に重ね合わせることによってストリームをクロスフェードさせることができ、その場合、第１のレンダリング装置は、第２のレンダリング装置が徐々に明るくなる間に徐々に薄暗くなっていく。さらにまたは代わりに、移行モジュール１１８は、１つまたは複数のクロスフェードを使用して音声を移行できる。たとえば、ビデオは、２台のレンダリング装置を使用して薄暗くする／明るくすることができる。一方、音声は入力源での音量を調整し、音声のフェードイン／フェードアウト効果を生じさせることによってクロスフェードできる。追加の実施形態では、クロスフェードは、第１のストリームの最後および第２のストリームの最初が実行時において正確に同時ではないときに、中断されないメディアのストリームを提供する上で役立つことができる。

図５は、本開示の１つまたは複数の実施形態に従って、クライアントのために理想的なビットレートを決定し、記憶する実例となるプロセス５００の流れ図である。プロセス５００の動作を説明する順序は、制限として解釈されることを意図されておらず、プロセスを実施するために、任意の数の説明されるブロックが任意の順序で、および／または並列で結合できる。

ホスト１０２は、ユーザ１０８への出力のために、メディアデータベース１１２からクライアント１０４に多くの異なる個数のメディアを提供できる。ユーザがウェブサイトをナビゲートし、異なるソースのメディアをプレビューするときなど、ユーザ１０８は、しばしば多くの個数のメディアを受信することを所望することがある。プロセス５００では、ホスト１０２が、通常は、確立されたネットワーク接続を使用して異なるメディアコンテンツをストリーミングする連続セッションの間に、以前のストリーミング活動を、ユーザ１０８のための最高のビットレートのストリーミングメディアに提供できるようにする。

５０２で、ホスト１０２は、メディアのストリームのビットレートを決定するために、第１のコンテンツの第１のメディアのストリームを監視できる。５０４で、ホストは、ネットワーク接続の帯域幅をチェックできる。たとえば、ホスト１０２は、動作５０２からのビットレートが受け入れ可能であるか検証することができる、あるいはホストは理想的なビットレートを決定できる。理想的なビットレートは、動作５０２で決定されるビットレートであることもあれば、あるいは理想的なビットレートはホスト１０２とクライアント１０４間の以前の対話に基づく新しいビットレートであることもある。５０６では、ホスト１０２はクライアント１０４へのストリーミングメディアにとって理想的なビットレートを記憶できる。最後に、５０８で、ホスト１０２は、クライアント１０４に対する第１のコンテンツの新しいメディアのストリームを、理想的なビットレートでまたは理想的なビットレート近くで開始できる。

（実例となる分析ツール）
図６は、本開示のいくつかの実施形態に従って、クライアント上でのストリーミングを監視するために、実例となるユーザインタフェース６０２を含む実施形態６００を示す。ユーザインタフェース６０２は、ホスト１０２からクライアント１０４に送信される１つまたは複数のメディアのストリームを監視するために使用できる。ユーザインタフェース６０２は、（たとえばユーザ１０８による）クライアント１０４とのユーザ対話および／またはホストとクライアント間のストリーミング活動を監視し、分析するためのホスト１０２とのユーザ対話を可能にできる。

１つまたは複数の実施形態によれば、ユーザインタフェース６０２は、第１のストリームを監視するための第１のグラフ６０４、および第２のストリームを監視するための第２のグラフ６０６を含む。他の実施形態では、ホストによってクライアントに提供されるメディアのストリームを監視するために、ユーザインタフェース６０２内により多くのまたはより少ないグラフが実装できる。いくつかの実施形態では、第１のグラフおよび第２のグラフはウォーターマーク６０８を表示できる。たとえば、ウォーターマーク６０８は、クライアントに提供されるメディアのおストリームについてビットレートが引き下げられるべきかどうかを判定するために、図３の動作３１４で使用できる。

環境６００では、第１のグラフ６０４の部分６１０が、説明のため追加の詳細を示すために拡大されている。その部分６１０は、より大きいバッファがウォーターマーク６０８を下回るときのグラフを示す。動作３１４に関して上記に説明したように、ヒューリスティックモジュール１２０が、バッファの活動の統計分析を実施し、バッファの充填レベルがゼロバイトに達する可能性があるかどうかを判定する。たとえば、クライアントは、バッファ充填レベルがウォーターマークを下回った後のバッファの充填レベルの周期的なサンプル６１２を採取できる。連続周期サンプル６１２（１）、．．．、６１２（ｎ）は、クライアント１０４へのビットレートが削減された状態でメディアのストリームのストリーミングの開始するためにホスト１０２を開始できる。第１のグラフ６０４は、周期的なサンプル６１２の活動に出力を提供するために第１のカウンタ６１４を含むことができる。たとえば、第１のカウンタ６１４は、周期的なサンプル６１４から判定されるように、バッファ充填レベルの連続減少の数をカウントできる。同様に、第２のカウンタ６１６は、第２のストリームおよび第２のグラフと関連付けることができる。

６１８で、ユーザインタフェースは、ホスト１０２とクライアント１０４の間のネットワーク接続の測定された帯域幅を出力できる。たとえば、測定された帯域幅は、動作３０４、３０８、および／または３１０でホスト１０２によって取得され得る。さらに、ユーザインタフェース６０２は、経時的にユーザ１０８に表示されるフレーム数を含むフレームグラフ６２０を表示できる。いくつかの実施形態では、ユーザインタフェース６０２はユーザ入力を含むことがある。たとえば、ユーザ入力は、ユーザが、新しいビットレートストリームの開始に必要な点６１２の数を選択できるようにする。ユーザ入力は、ユーザが帯域幅６１８も入力できるようにもする。

（実例となるストリーム複雑度分析）
図７は、本開示のいくつかの実施形態に従ってメディアのストリームを分析し、可変ビットレート（ＶＢＲ）のメディアのストリームの部分の複雑度を決定するために実例となるチャート７００を示す。チャート７００は、時間値７０４上で描かれる複雑度評価７０２を含む。複雑度７０２は、ビットレート値と関連付けることができる。

いくつかの実施形態によれば、メディアのストリームは経時的に複雑度を決定するために分析できる。たとえば、ヒューリスティックモジュール１２０は、メディアのストリームのための複雑度情報を含むストリーム複雑度ファイルを作成できる。いくつかの実施形態では、ストリーム複雑度ファイルは、ホスト１０２からクライアント１０４に送信され、クライアントがメディアのストリームの将来の部分の複雑度を決定できるようにする。代わりにまたはさらに、ホスト１０２はそのストリーム複雑度ファイルを使用し、クライアントに送信されるメディアのストリーミングの態様を調整することができ、これでユーザ１０８に中断されないストリーミングメディアを提供できる。

複雑度情報は、チャート７００上でＶＢＲ線７０６として描くことができる。上記に説明したように、ＶＢＲのメディアのストリームは、中央ビットレート値または平均ビットレート値であることがある指定ビットレート７０８を含むことがある。指定ビットレート値７０８は、チャート７００上に描かれることがある。いくつかの実施形態では、帯域幅線７１０はチャート７００上に表すことができる。帯域幅線７１０は、図１のホスト１０２とクライアント１０４間のネットワーク接続のビットレート容量を表すことができる。

ＶＢＲ線７０６の分析が、第１の複雑な部分７１２および第２の複雑な部分７１４などの複雑な部分を示すことがある。複雑な部分７１２、７１４は、メディアのストリームのためのビットレートが、指定ビットレート値よりも高い部分を含むことがある。いくつかの実施例では、ホスト１０２からのストリーミングメディアによってバッファ１２６が充填され得るよりも速く、メディアのストリーミングがユーザ１０８に出力できるため、複雑な部分７１２、７１４は、バッファ充填の枯渇を生じさせることがある帯域幅線７１０よりも高いビットレートを含むことがある。複雑な部分７１２、７１４が、バッファ容量がサポートできるよりも長い持続時間を有する場合、バッファは、ホスト１０２またはクライアント１０４による追加の処置なしに使い切られることがある。

さらに、ＶＢＲ線７０６は、第１の低複雑度部分７１６および第２の低複雑度部分７１８などの低い複雑度の部分を示すことができる。低複雑度部分７１６、７１８がホスト１０２からクライアント１０４にストリーミングされるとき、メディアのストリームがユーザ１０８にプレイバックされるよりも速く、バッファ１２６は充填することができ、したがって低充填レベルを有するバッファの補充を可能にする。いくつかの実施形態では、バッファ１２６は、図２のプロセス２００を使用してビットレート値を調整しなくても、中断されないメディアのストリーミングを可能にするほど十分なメディアのストリームを記憶できる。しかしながら、いくつかの実施形態では、第２の複雑な部分７１４などの複雑な部分の長い持続時間が、ストリーミングモジュール１１４または移行モジュール１１８によって追加の処置が講じられずにクライアント１０４にストリーミングされるとき、バッファは使い切られる可能性がある。

１つまたは複数の実施形態によれば、ヒューリスティックモジュール１２０は、複雑度対時間を有するＶＢＲ線７０６によって表される情報を含むストリーム複雑度ファイルを生成できる。たとえば、ファイルは毎秒または別の期間など、メディアのストリームの期間の間ビットレート値を含むことができる。いくつかの実施形態では、ストリーム複雑度ファイルは、第１のビットレートのメディアのストリームを第２のビットレートのメディアのストリームにいつ移行すべきかを判定するために、移行モジュール１１８によって使用され得る。たとえば、ストリーム複雑度ファイルを分析すると、時間が第２の複雑な部分７１４の開始に一致するときに、移行モジュール１１８は第１のビットレートから第２のビットレートへの移行を生じさせる結果となる。一方、バッファ１２６は、第１の複雑な部分７１２のストリーミング中に第１のビットレートを持続するほど十分に大きいことがある。

いくつかの実施形態では、ストリーミングモジュールは、ストリーム複雑度ファイルの分析に基づいてバッファ１２６の容量を拡大できる。たとえば、拡大されたバッファ容量は、第２の低複雑度部分７１８の間のストリーミングメディアで充填することができ、バッファが、バッファの充填レベルをゼロバイトのデータにまたは別の最小閾値まで使い切ることなく、第２の複雑な部分７１４の間にストリーミングメディアを提供できるようにする。いくつかの実施形態では、バッファサイズの拡大と第２のビットレートのメディアのストリームへの移行を組み合わせることによって、中断されないメディアのストリームのユーザ１０８への出力が可能になる。

１つまたは複数の実施形態によれば、ストリーム複雑度ファイルは、メディアのストリームがユーザ１０８にプレイバックされている間にＶＢＲ線７０６を周期的に参照することによってメディアをストリーミングする間に使用できる。ストリーム時間７２０は、チャート７００に含まれることがある。出力時間は、メディアのストリームがユーザにプレイバックされる時間であることもあれば、それは、メディアのストリームがバッファ１２６を充填するために使用される時間であることもある。説明のため、ストリーム時間７２０は、バッファ１２６を充填するためにメディアのストリームが使用される時間として説明する。参考までに、ストリーム時間７２０の前の時間値７０４は過去の時間７２２である。一方ストリーム時間後の時間は将来の時間７２４である。

将来時間ウィンドウ７２６が、チャート７００に含まれることがある。将来時間ウィンドウ７２６は、将来の時間７２４でのＶＢＲ線７０６を監視するために使用できる。いくつかの実施形態では、将来時間ウィンドウ７２６は、バッファ容量に対応するストリーム時間に対して将来の時間に選択できる。たとえば、バッファ容量が３０秒のストリーミングメディアである場合、他のバッファ容量および将来時間ウィンドウ値が使用できるが、将来時間ウィンドウ７２６は、１５秒から４５秒の持続時間など、３０秒の前後のＶＢＲ線７０６のセグメントを含むことができる。いくつかの実施形態では、移行モジュール１１８は、将来時間ウィンドウ内の情報を使用して、第１のビットレートから第２のビットレートへの移行を生じさせることができる。さらにまたは代わりに、ストリーミングモジュール１１４は、将来時間ウィンドウ７２６に基づいてバッファ容量を拡大できる。

図８は、本開示の１つまたは複数の実施形態に従って、クライアントへのストリーミングを調整するために複雑度データを有するメディアのストリームの分析を使用する、実例となるプロセス８００の流れ図である。プロセス８００の動作を説明する順序は、制限として解釈されることを意図されておらず、プロセスを実施するために、任意の数の説明されるブロックが任意の順序で、および／または並列で結合できる。説明のために、プロセス８００は、図１の環境１００を参照して説明する。

いくつかの実施形態によれば、８０２で、ヒューリスティックモジュール１２０は、可変ビットレート（ＶＢＲ）のメディアのストリームのためのストリーム複雑度ファイルを生成できる。たとえば、ヒューリスティックモジュール１２０は、メディアデータベース１１２内のメディアのストリームの符号化ごとにストリーム複雑度ファイルを作成できる。８０４で、ヒューリスティックモジュール１２０は、図７の第１の複雑な部分７１２および第２の複雑な部分７１４など、複雑な部分の位置をストリームの中で突き止めるためにストリーム複雑度ファイルを分析できる。動作８０４がメディアのストリームについて一度発生することもあれば、動作８０４が将来時間ウィンドウ７２６を使用することによってメディアのストリームについて周期的に発生することもある。

複雑な部分が８０６で位置付けられる場合、移行モジュール１１８は８０８でビットレートを調整できる。ただし、複雑な部分が動作８０６で位置付けられない場合、プロセス８００では動作８０４に戻り、ホスト１０２からクライアント１０４にメディアをストリーミングする間に、ストリーム複雑度ファイルを分析できる。動作８０８に戻ると、移行モジュール１１８は、ビットレート調整が必要であると判定し、８１０で新しいビットレートで新しいストリームを移行できる。新しいストリームは、動作８０２でヒューリスティックモジュールによって生成できる新しいストリーム複雑度ファイルを含むことができる。

いくつかの実施形態では、ストリーミングモジュール１１４は、８１２でバッファ容量を調整するべきかどうかを判定できる。たとえば、ストリーム複雑度ファイルは、拡大されたバッファが、新しいビットレートの新しいストリームに移行しなくても、ユーザ１０８への中断されないストリーミングメディアを提供できるようにすることを示すことができる。ストリーミングモジュール１１４は、８１４で複雑な部分を収容するために拡大されたバッファを充填できる。代わりに、ストリーミングモジュールは、動作８１２でバッファ容量を調整できず、プロセス８００は、動作８０４でストリーム複雑度ファイルを分析することによって続行できる。

拡大されたバッファが動作８１４で充填される、または移行モジュール１１８が動作８１０で新しいビットレートの新しいストリームに移行する場合、いったん複雑な部分がホスト１０２からクライアント１０４にストリーミングされてしまうと、プロセス８１６はバッファ容量および／またはメディアのストリームを以前の設定値に戻すことができる。たとえば、プロセス８００は、いったん複雑な部分がクライアントにストリーミングされてしまうと、動作８１８でより高いビットレートのメディアのストリームに戻ることによって、ユーザへの最高の質のメディアのストリームを提供できるようにする。最後に、プロセス８００は、プロセスが周期的なループを使用して、ストリーム複雑度モジュールでデータを実装し、ユーザ１０８へのプレイバックのために中断されないストリーミングメディアを提供するときなど、ストリーム複雑度ファイルを分析するために動作８０４に戻ることができる。

いくつかの実施形態では、ヒューリスティックモジュール１２０は、動作８１０にとっての理想的なビットレートを決定するためにストリーム複雑度ファイルを分析できる。たとえば、ヒューリスティックモジュール１２０は、ネットワーク接続の帯域幅でストリーム複雑度ファイルのデータを処理し、メディアのストリームのＶＢＲ実行時中にバッファ充填レベルの多様なシナリオを作成できる。この分析は、バッファ充填を使い切らない理想的なビットレートを選択できるようにする。さらに、分析は、バッファ充填を使い切るのを回避するために実施できるバッファ容量拡大を決定できる。上記に説明したように、１つまたは複数の実施形態では、拡大バッファ容量を使用することによって、新しいビットレートに切り替えることによって、または両方によって、ストリーミングモジュール１１４が中断されないストリーミングメディアを提供できるようにする。

（実例となる動作）
図９は、図１のホストサーバ１０２と関連するモジュールの１つまたは複数の実施形態の実例となるアーキテクチャ９００のブロック図を示す。アーキテクチャ９００は、１台または複数のプロセッサ９０２、およびその１台または複数のプロセッサ９０２によって実行可能である命令を格納するメモリ９０４を含む。

いくつかの実施形態に従って、ストリーミングモジュール１１４は、ストリーミングマネージャ９０６を含むことができる。ストリーミングマネージャ９０６は、符号化された異なるビットレートでストリーミングメディアを提供し、メディアデータベース１１２および／またはストリーミング待ち行列１１６に常駐することができる。いくつかの実施形態では、ストリーミングマネージャ９０６は、メディアをストリーミングする前に損失の多いメディアファイル等のメディアを修正し、したがってメディアコンテンツのインスタンスごとに複数のファイルを維持する必要性を削除することができる。

動作３０４、３０８、および３１０で説明したような、ホスト１０２とクライアント１０４間のネットワーク接続の帯域幅を計算するために、帯域幅計算機９０８が使用できる。レンダリングモジュール９１０は、プレゼンテーションアプリケーション１２８によるプレイバックのためにクライアント１０４に視覚出力または聴覚出力を提供できる。バッファモジュール９１２は、バッファ１２６等のクライアント上でのバッファ活動を監視する、および／または分析することができる。

いくつかの実施形態では、移行モジュール１１８は、ホスト１０２に、ユーザ１０８へのプレイバックのためのクライアント１０４への中断されないメディアのストリームを維持しつつ連続ストリームを第１のメディアのストリームから第２のメディアのストリームに移行させるために、移行マネージャ９１４を含むことができる。移行マネージャは、メディアのストリームで中断を引き起こすことなく可能な限り最長の時間の間ユーザに最高のビットレートを提供するように構成できる。クロスフェードモジュール９１６は、第２のビデオレンダリング装置を明るくしつつ、レンダリングモジュール９１０によって提供される第１のビデオレンダリング装置を薄暗くすることによってなど、徐々に音声および／または映像をクロスフェードするために使用できる。

１つまたは複数の実施形態では、ヒューリスティックモジュール１２０は、統計アナライザ９１８を含むことができる。統計アナライザ９１８は、バッファの活動の統計分析を実施し、バッファの充填レベルがゼロバイトに達する可能性があるかどうかを判定できる。たとえば、統計アナライザは、バッファ充填レベルがウォーターマークを下回った後のバッファの充填レベルの周期的なサンプルを分析できる。ビットレートセレクタ９２０は、ネットワーク１０６の測定された帯域幅に基づいてストリーミングメディアにとって理想的なビットレートを決定できる。ヒューリスティックモジュール１２０は、メディアコンテンツのビットレートの選択を動的に制御することができ、他の要因の中でも測定された帯域幅に基づいてユーザ１０８に最高ビットレートのメディアのストリームを提供し、したがってあらゆるインスタンスで隣接するビットレートを選択するのではなく、理想的なビットレートを選択できる。実行時計算機９２２は、初期バッファを充填するための時間を含めた第２のストリームに移行するために必要な時間に基づいて、第２のストリームのための将来の実行時での実行時開始を計算できる。複雑度アナライザ９２４は、メディアの可変ビットレートストリームに基づいてストリーム複雑度ファイルを作成できる。さらに、複雑度モジュールは、理想的なビットレートまたは拡大バッファ容量の選択を可能にし、メディアのストリームが、さもなければバッファを使い切る可能性のある複雑な部分を含むときに、ユーザ１０８に中断されないストリーミングメディアを提供できるようにする。

第１節。クライアントとホストの間でメディアをストリーミングする方法は、
バッファを、初期ビットレートで初期の容量まで、第１のメディアのストリームで充填することと、
バッファが初期容量に達したときに、第１のメディアのストリームを再生することと、
第１のメディアのストリームを再生するのと同時により大きい容量までバッファを充填することと、
バッファのバッファ充填レベルステータスを決定することと、
バッファのバッファ充填レベルステータスがウォーターマークを下回るときに、第１のメディアのストリームの初期ビットレートよりも低い、代替ビットレートを有する第３のメディアのストリームに切り替えることと、
を含む。

第２節。第１節に記載の方法は、さらに
クライアントとホストの間の帯域幅を決定することと、
帯域幅が、第１のメディアのストリームの初期ビットレートよりも高い代替ビットレートをサポートするときに、その代替ビットレートを有する第２のメディアのストリームに切り替えることと、
を含む。

第３節。第３のメディアのストリームに切り替えることは、バッファが空になるまで第１のメディアのストリームを再生することを含み、第２のメディアのストリームに切り替えることは、第２のバッファの初期容量に到達したときに第２のメディアのストリームを再生することを含む、第１節に記載の方法。

第４節。第２のメディアのストリームおよび第３のメディアのストリームの内の少なくとも１つに切り替えることが、クライアントへの実質的に中断されないメディアのストリームを提供しつつ、先制して発生する、第１節に記載の方法。

第５節。帯域幅が、初期バッファの充填速度またはシステム帯域幅チェックの内の少なくとも１つによって決定される、第１節に記載の方法。

第６節。第１節に記載の方法は、さらに、大きいバッファから第１のメディアのストリームを再生するのと同時に第２の初期バッファを充填することを含む。

第７節。第１節に記載の方法は、さらに、帯域幅またはバッファ充填レベルステータスの内の少なくとも１つに基づいて理想的なビットレートを決定することを含み、その理想的なビットレートは、複数の選択可能なビットレート値から第２のメディアのストリームまたはメディアの第３のストリームを選択するために使用される。

第８節。第７節に記載の方法は、さらに、理想的なビットレート値を記憶し、メディアコンテンツの以降のストリームの初期ビットレートを予測することを含む。

第９節。コンテンツをストリーミングする方法であって、この方法は、
コンテンツをストリーミングするために使用されるネットワーク接続の帯域幅を決定することと、
第１のストリームのバッファを分析し、バッファ充填ステータスを決定することと、
帯域幅が、第２のビットレートでの第２のストリームの中断されない伝送を可能にし、第２のビットレートが第１のビットレートよりも高いときに、または
バッファ充填ステータスが、ゼロバイトより大きいウォーターマークを下回り、第２のビットレートが第１のビットレート未満であるときに、
第１のビットレートでの第１のストリームを、第２のビットレートでの第２のストリームに切り替えることと、
を含む。

第１０節。第１のストリームから第２のストリームへ切り替えることが、実質的に中断されないストリーミングコンテンツの移行を含む、第９節に記載の方法。

第１１節。第１のストリームから第２のストリームへの切り替えが、
第１のストリームの第１のビデオレンダリング装置を薄暗くし、同時に第２のストリームの第２のビデオレンダリング装置を明るくすること、または
第１のストリームの第１の音声信号をフェードアウトし、同時に第２のストリームの第２の音声信号をフェードインすること、
の内の少なくとも１つを含む、第１０節に記載の方法。

第１２節。１つまたは複数のコンピュータ可読媒体は、１または複数のプロセッサ上で実行されるときに、
第１のメディアのストリームを、ネットワーク接続を通して、第１のビットレートのバッファへ送信する動作と、
バッファの減少するバッファ充填レベルおよびネットワーク接続の過剰な帯域幅容量の内の少なくとも１つを決定する動作と、
初期バッファ容量を充填するために、第１のビットレートで第２のバッファまでネットワーク接続を通して第２のメディアのストリームを開始する動作と、
第２のストリームの初期バッファ容量がいっぱいのときに、第１のビットレートの第１のメディアのストリームからの出力を、第２のビットレートの第２のメディアのストリームに移行する動作と、
を含む動作を実施するためのコンピュータ実行可能命令を記憶する。

第１３節。第１２節に記載の１つまたは複数のコンピュータ可読媒体は、さらに、減少するバッファ充填レベルまたは帯域幅の内の少なくとも１つに基づいて理想的なビットレートを決定することを含み、その理想的なビットレートは第２のビットレートを選択するために使用される。

第１４節。第２のビットレートが、所定のビッレート値のグループから選択される、第１３節に記載の１つまたは複数のコンピュータ可読媒体。

第１５節。第１のビットレートからの出力を第２のビットレートに移送することが、第１のメディアのストリームを処理する第１のレンダリングモジュールの出力、および第２のメディアのストリームを処理する第２のレンダリングモジュールの出力をクロスフェードすることを含む、第１２節に記載の１つまたは複数のコンピュータ可読媒体。

第１６節。第２のビットレートへの移行が、最も長い持続時間の間、クライアントに出力される最高のビットレートを保存するために開始される、第１２節に記載の１つまたは複数のコンピュータ可読媒体。

第１７節。第２のビットレートでストリーミングメディアを開始することが、第２のビットレートを有するメディアのストリームのための将来の実行時開始時間を選択することを含み、将来の実行時開始時間が、初期バッファ容量がいっぱいである瞬間の第１のストリームの実行時に等しい、または実行時よりも遅い、第１２節に記載の１つまたは複数のコンピュータ可読媒体。

第１８節。減少するバッファ充填を決定することが、バッファ充填がいつウォーターマークを下回るのかを決定すること、およびバッファ充填レベルの周期的なサンプルを分析することを含む、第１２節に記載の１つまたは複数のコンピュータ可読媒体。

第１９節。システムは、
プロセッサと、
プロセッサによって実行可能な命令を有するメモリと、
を備え、そのメモリが、
複数のビットレートでメディアのストリームに選択的にアクセスし、クライアントにメディアのストリームの内の少なくとも１つを送信するためのストリーミングモジュールと、
クライアントにとってのメディアのストリームの理想的なビットレートを決定し、その理想的なビットレートへの移行をいつ開始すべきかを決定するためのヒューリスティックモジュールと、
メディアのストリームの初期ビットレートから理想的なビットレートへ移行するための移行モジュールと、
を含む。

第２０節。ストリーミングモジュールは、さらに初期ビットレートを有するメディアのストリームを出力するための第１のレンダリングモジュールと、第２のビットレートを有するメディアのストリームを出力するための第２のレンダリングモジュールとを含む、第１９節に記載のシステム。

第２１節。移行モジュールが、第１のレンダリングモジュールの出力を、第２のレンダリングモジュールの出力でクロスフェードする、第２０節に記載のシステム。

第２２節。ヒューリスティックモジュールが、
ホストとクライアントの間のネットワーク接続の帯域幅を測定すること、または
初期ビットレートのバッファがゼロバイトに達するかどうかを判定するためにバッファ充填レベルを監視することと、
の内の少なくとも１つによって理想的なビットレートを決定する、第１９節に記載のシステム。

第２３節。ストリーミングモジュールが、初期ビットレートのメディアのストリームの第１のバッファ、および理想的なビットレートでのメディアのストリームの第２のバッファを制御するためのバッファリングモジュールを含み、バッファリングモジュールがウォーターマークを下回るバッファ充填値を有するときに警報を提供するように構成され、警告が理想的なビットレートでメディアのストリームを開始する、第１９節に記載のシステム。

第２４節。バッファを監視する方法は、
バッファ容量未満、またはバッファ容量に等しい充填レベルを有するバッファから初期ビットレートでメディアをストリーミングすることと、
バッファの充填レベルを周期的に監視することと、
充填レベルがウォーターマークを下回ったときに、充填レベルの複数の周期的なサンプルを格納することと、
複数の周期的なサンプルを分析し、初期ビットレートに比してより低いビットレートへの移行が、中断されないメディアのストリームを提供するために必要であるかどうかを判定することと、
を含む。

第２５節。第２４節に記載の方法は、さらに、複数の周期的なサンプルに基づいてより低いビットレート値を決定することを含む。

第２６節。第２４節に記載の方法は、さらに、
初期ビットレートに比してより低いビットレートへの移送が必要なときに、より低いビットレートでメディアのストリームを開始し、初期バッファ充填レベルがゼロに達する前に、第２のバッファ初期容量を充填することと、
初期バッファの充填レベルがゼロバイトに到達したときに、第２のバッファから第２のメディアのストリームを再生することと、
を含む。

第２７節。ストリーミングコンテンツの間で移行する方法であって、その方法は、
第１のメディアのストリームの第１のビデオレンダリング装置を薄暗くし、第２のメディアのストリームの第２のビデオレンダリング装置を明るくすること、または
第１のメディアのストリームの第１の音声信号をフェードアウトし、第２のメディアのストリームの第２の音声信号をフェードインすること、
の内の少なくとも１つによって、第１のビットレートでホストから受信された第１のメディアのストリームから、第２のビットレートでホストから受信された第２のメディアのストリームに移行することと、
を含む。

第２８節。第１のビデオレンダリング装置を薄暗くし、第２のビデオレンダリング装置を明るくすることが同時に発生し、第１の音声信号をフェードアウトすることおよび第２の音声信号をフェードインすることが同時に発生する、第２７節に記載の方法。

第２９節。第１のビデオレンダリング装置および第２のビデオレンダリング装置が、オーバレイとして配置される、第２７節に記載の方法。

第３０節。ストリーミングコンテンツを分析する方法であって、この方法は、
可変ビットレートを有するメディアのストリームを、ビットレート指定で入手することと、
メディアのストリームのためのストリーム複雑度データをマッピングするために、メディアのストリームの持続時間の期間ごとにビットレートを決定することと、
ストリーム複雑度データを保存することと、
ストリーム複雑度データを分析し、クライアントがメディアのストリームをプレイバックするときに、複雑な部分がプレイバックバッファを使い切るかどうかを判定することと、
ストリーム複雑度データの分析が、複雑な部分を含み、クライアントに、
指定されたビットレートに比してより低い平均ビットレートを有する第２のメディアのストリームへ移行する、または
初期バッファ容量より大きいバッファ容量を充填するためにバッファ容量を拡大し、クライアントが複雑な部分をプレイバックするときにバッファの枯渇を防止する、
ことの少なくとも１つを行うように信号で知らせることと、
を含む。

第３１節。ストリーム複雑度データを分析することが、
メディアのストリームを送信するために使用されるネットワーク接続の帯域幅を測定することと、
ストリーム複雑度データの部分ごとに予想バッファ枯渇速度を推定することと、
バッファの枯渇および帯域幅に基づいてバッファ補充をシミュレーションし、クライアントがメディアのストリームをプレイバックするときに、複雑な部分がバッファを使い切るかどうかを判定することと、
を含む、第３０節に記載の方法。

第３２節。指定ビットレートに比して低い平均ビットレートを有する第２のメディアのストリームへの移行が、ストリーミングコンテンツの実質的に中断されない出力を提供することを含む、第３０節に記載の方法。

第３３節。バッファ容量を拡大することが、
複雑な部分の持続時間および複雑度に基づいて理想的なバッファ容量を計算することと、
バッファが、メディアのストリームの複雑な部分に達する前に理想的なバッファ容量をストリーミングデータで充填することと、
を含む、第３０節に記載の方法。

第３４節。１つまたは複数のコンピュータ可読媒体は、１台または複数のプロセッサ上で実行されるときに、
可変ビットレートを有するメディアのストリームにアクセスする動作と、
アクセスしたメディアのストリームの期間ごとに複雑度値を記憶する動作と、
記憶された複雑度値を、メディアのストリームに関連する複雑度ファイルに出力する動作と、
を含む動作を実施するための、コンピュータ実行可能命令を記憶する。

第３５節。第３４節に記載の１つまたは複数のコンピュータ可読媒体は、さらに、１台または複数のプロセッサ上で実行されるときに、アクセスされたメディアのストリームの期間ごとの複雑度評価を作成することを含む動作を実施するための命令を記憶し、複雑度評価は、期間ごとの平均ビットレートを含む。

第３６節。第３４節に記載の１つまたは複数のコンピュータ可読媒体は、さらに、１台または複数のプロセッサ上で実行されるときに、メディアのストリームの１つまたは複数の連続期間が、ネットワーク接続の帯域幅よりも大きい代表的なビットレートを有する複雑な部分を識別することを含む動作を実施するための命令を記憶し、その複雑な部分のメディアのストリームを出力すると、現在のバッファ容量でのバッファは使い切られることになるはずである。

第３７節。第３４節に記載の１つまたは複数のコンピュータ可読媒体は、さらに、１台または複数のプロセッサ上で実行されるときに、メディアのストリームとともにクライアントに記憶されている複雑度値を送信することを含む動作を実施するための命令を記憶する。

第３８節。第３４節に記載の１つまたは複数のコンピュータ可読媒体は、さらに、１台または複数のプロセッサ上で実行されるときに、
複数のビットレート値のために各メディアのストリームにアクセスすることと、
複数のビットレート値のためにアクセスされた各メディアのストリームの期間ごとに複雑度値を記憶することと、
各メディアのストリームと関連する複数の複雑度ファイルに記憶された複雑度値を出力することと、
を含む動作を実施するための命令を記憶する。

第３９節。複雑度値がビットレート値である、第３４節に記載の、１つまたは複数のコンピュータ可読媒体。

第４０節。方法は、
可変ビットレート指定を有するメディアのストリームと関連する複雑度ファイルを受信し、複雑度ファイルがそのメディアのストリームの部分ごとのビットレート値を含むことと、
メディアのストリームを受信するために使用されるネットワーク接続と関連する帯域幅を決定することと、
複雑度ファイルに基づいてメディアのストリームのバッファ枯渇セグメントの位置を突き止め、その複雑度のために、バッファ枯渇セグメントが帯域幅でのバッファの枯渇を引き起こす可能性があることと、
を含む。

第４１節。複雑度ファイルに基づいてメディアのストリームのバッファ枯渇セグメントの位置を突き止めることが、メディアのストリームの将来の部分を表す将来のビットレートを予測するための時間チェックで周期的に発生し、その将来のビットレートが、バッファが、将来の部分のストリーミングの間の帯域幅で使い切られる可能性があるかどうかを判定するために使用される、第４０節に記載の方法。

第４２節。将来の部分がバッファの容量に基づいて選択される、だい４１節に記載の方法。

第４３節。複雑度ファイルに基づいてメディアのストリームのバッファ枯渇セグメントの位置を突き止めることがユーザへのメディアのストリームのプレイバック前に発生する、第４０節に記載の方法。

第４４節。第４３節に記載の方法は、さらに、新しいビットレートストリームが、バッファの枯渇のシミュレーションを引き起こす可能性があるかどうかを判定するためにバッファの枯渇を引き起こすセグメント上で、新しいメディアのストリームの新しいビットレート値を使用してユーザへのプレイバックをシミュレーションすることを含む。

第４５節。第４０節に記載の方法は、さらに、クライアントにストリーミングされるときに、帯域幅に基づいてバッファの枯渇を回避する、メディアのストリームを表す理想的なビットレートを決定することを含む。

第４６節。第４５節に記載の方法は、さらに、可変ビットレート指定を有するメディアのストリームから、メディアのストリームを表す理想的なビットレートを有するメディアのストリームへ移行することを含む。

第４７節。移行することが、
音声をクロスフェードさせること、または
可変ビットレートを有するメディアのストリームを出力するために第１のビデオレンダリング装置を薄暗くし、同時に理想的なビットレートを有するメディアのストリームを出力するために第２のビデオレンダリング装置を明るくすることと、
の内の少なくとも１つを含む、第４６節に記載の方法。

第４８節。第４０節に記載の方法は、さらに、バッファの枯渇を引き起こすセグメントのプレイバックの前に、バッファを拡大することをさらに含む。

第４９節。バッファを拡大することが、バッファ枯渇セグメントのプレイバックの前に拡大されたバッファを充填することを含み、拡大されたバッファがバッファの枯渇を妨げ、メディアのストリームの実質的に中断されないプレイバックを可能にする、第４８節に記載の方法。

結論
主題は特定の構造上の特長、および/または方法論的行動に特定の言語で説明してきたが、添付請求項に定義される主題が、必ずしも説明された特定の特長または動作に制限されていないことが理解されるべきである。むしろ、特定の特長及び動作は、請求項を実施する実例となる形式として開示されている。

Claims (5)

1. クライアントとホストの間でメディアをストリーミングする方法であって、
   初期ビットレートで前記ホストから受信する第１のメディアのストリームで、前記クライアントの第１のバッファを前記第１のバッファの初期容量まで充填することと、
   前記第１のバッファの充填レベルステータスを監視することと、
   前記第１のバッファの前記充填レベルステータスが前記第１のバッファの初期容量に達したときに前記第１のメディアのストリームを再生することと、
   前記第１のメディアのストリームを再生するのと同時に、より大きい容量まで前記第１のバッファを充填することと、
   前記第１のバッファから前記第１のメディアのストリームを再生させるのと同時に、前記第１のメディアのストリームと同一のコンテンツである第２のメディアのストリームを前記第１のメディアのストリームの前記初期ビットレートよりも低い代替ビットレートで前記ホストから受信し、前記第１のバッファとは異なる、前記クライアントの第２のバッファを、前記第２のバッファの初期容量まで充填することと、
   前記第１のバッファの前記充填レベルステータスが所定の最小閾値を下回るときに、前記第２のバッファからの前記第２のメディアのストリームを再生するために前記第２のメディアのストリームへ切り替えることと
   を含むことを特徴とする方法。
2. 前記第１のバッファの前記充填レベルステータスが前記第１のバッファの初期容量より大きい容量まで満たされているときに、
   前記クライアントと前記ホストの間で帯域幅を決定することと、
   前記帯域幅が、前記第１のメディアのストリームの前記初期ビットレートよりも高い代替ビットレートをサポートするとき、前記第１のメディアのストリームの前記初期ビットレートよりも高い代替ビットレートを有する第３のメディアのストリームを再生するために前記第３のメディアのストリームに切り替えることと
   をさらに含むことを特徴とする請求項１に記載の方法。
3. 前記第１のバッファの前記充填レベルステータスが前記所定の最小閾値を下回るときに、
   前記第１のバッファの前記充填レベルステータスがゼロバイトになるまで前記第１のメディアのストリームを再生させ、その後、前記第２のバッファからの前記第２のメディアのストリームを再生するために前記第２のメディアのストリームに切り替えることと
   をさらに含むことを特徴とする請求項１に記載の方法。
4. 実質的に中断されないメディアのストリームを前記クライアントに提供しつつ、前記第２のメディアのストリーム、および前記第３のメディアのストリームの内の少なくとも１つに切り替えることが、前記第１のバッファの前記充填レベルステータスがゼロバイトになる前に発生することを特徴とする請求項２に記載の方法。
5. 前記帯域幅または前記第１のバッファの前記充填レベルステータスの内の少なくとも１つに基づいてビットレートを決定することをさらに含み、前記ビットレートが、複数の選択可能ビットレート値から、前記第１のバッファの前記充填レベルステータスが所定の最小閾値を下回るときに前記第２のメディアのストリーム、または、前記帯域幅が前記第１のメディアのストリームの前記初期ビットレートよりも高い代替ビットレートをサポートするとき前記第３のメディアのストリームを、選択するために使用されることを特徴とする請求項２に記載の方法。

Images