JP6419848B2 - 帯域幅最適化のための適応的データセグメント配信調停 - Google Patents

Description

＜優先権主張＞
この出願は、２０１４年６月３０日出願の米国仮出願第６２／０１９，３１９号に対し、優先権を主張する。

＜技術分野＞
以下は、一般に、インターネット又は他のネットワークを介した、メディアコンテンツのストリーミングに関する。更に詳しくは、以下の議論は、メディアプレーヤーデバイスが、ストリームに含まれる基礎のコンテンツの帯域幅を考慮することによって、適応的メディアストリームの配信を改善することを可能とするシステム、方法、及び、デバイスに関する。

メディアストリーミングは、視聴者に、テレビ、映画、及び、他のメディアコンテンツを配信する方法として、ますます一般的となっている。メディアストリームとは、典型的には、インターネット又は同様なネットワークを介して送信されることができる、デジタル化コンテンツのポイント・ツー・ポイント伝送である。メディアストリーミングは、しばしば、ビデオオンデマンド（ＶＯＤ）サービス、リモートストレージデジタルビデオレコーダ（ＲＳＤＶＲ）サービス、インターネットプロトコルテレビ（ＩＰＴＶ）サービス、プレイスシフトメディア視聴及び／又は任意の数の他の便利なサービスを促進するために用いられる。一般に、プレーヤーにストリームが配信され続けるので、メディアストリームは、リアルタイムで、視聴者に対して再生される。

しばしば、メディアコンテンツは、「ストリームレット（ｓｔｒｅａｍｌｅｔ）」又は、個別に要求され、特定のクライアントデバイスに、適応的に配信されることができる、より小さな他のセグメントファイルの複数の集合にエンコードされる。ネットワーク帯域幅、又は他の要因の変化が発生した場合、異なるパラメータ（例えば、より高いビットレート、又は、より低いビットレート）でエンコードされる将来のセグメントを要求することによって、クライアントデバイスは、変化に対して反応することができる。適応的メディアストリーミングは、典型的には、ストリーミングプロセスの多くを制御するために、メディアプレーヤークライアントに依存している。つまり、典型的には、要求され、プレーヤーに配信されるだろうストリームの次のセグメントを、サーバではなく、メディアプレーヤークライアントが決定する。適応的ストリーミングシステム、デバイス、及び、技術の幾つかの例は、米国特許公報第２００８／０１９５７４３号に記載されている。

ビデオストリーミングにおいて発生する一つの問題は、そのビデオコンテンツが、しばしば、ビデオ表示中にわたって、帯域幅の様々なレベルを消費することである。例えば、爆発を示す映画シーケンスは、同一のビットレート、フレームレート、及び、解像度でエンコードされたそれほど劇的ではないシーンよりも多くの帯域幅を消費することがある。なぜなら、爆発は、殆ど圧縮できないからである。つまり、ビデオ画像は、より均一なビデオシーンに用いられる画像よりも、より大きいダイナミックレンジを表示する。ビデオコンテンツの２つのセグメントが、同一のビットレート、フレームレート、及び、解像度でエンコードされても、その２つのセグメントのサイズは、エンコードされる基礎のビデオ画像の圧縮性に基づいて、様々なものとなり得る。基礎のデータの非圧縮性により、「低帯域幅」セグメントが比較的大量のデータを含むとき、特に、これらの変化は、視聴者経験の品質に影響を与え得る。

したがって、適応的ストリーミングプロセスをクライアントデバイスがより良く制御することを可能とするシステム、デバイス、及び、方法を作成することが望まれる。これら、及び、他の望ましいフィーチャ及び特性は、添付の図面及びこの背景技術の項と共に理解されるならば、後続の詳細な説明及び添付の請求項から明らかとなるだろう。

消費帯域幅を補償するためのメディアストリームセグメントデータのリクエストを適応するための方法、システム、及び、デバイスの幾つかの例が記述される。本明細書で記述するシステム及びプロセスの多くは、メディアプログラムの未来のセグメントを記述する予測データを、メディアストリームのデータセグメントのうちの幾つか又はそのうちのすべてにエンコードし、クライアントメディアプレーヤーが、これから来るメディアセグメントの相対的帯域幅消費を正確に予測できるようにする。特にダイナミックビデオシーケンスが、これから来る場合、メディアプレーヤーは、デマンドが増加することを認識し、それに応じて適応することができ得る。

様々な実施形態は、異なるビデオ品質を有する複数のメディアストリームから選択される一連のセグメントから構成される受信メディアプログラムを処理するために、プロセッサとメモリとを有するクライアントデバイスによって実行可能な方法を提供する。この方法は、適切には：第１の品質を有する第１のメディアストリームからビデオプログラムの第１のセグメントをリクエスト、又は、取得することであって、第１のセグメントは、同一のメディアプログラムの未来のセグメントの帯域幅消費を記述する予測データを含む、ことと；視聴者に、再生のためのビデオプログラムの第１のセグメントをレンダリングすることと；予測データに少なくとも部分的に基づいて、ビデオプログラムの第２のセグメントを選択することであって、同一のメディアプログラムの未来のセグメントの帯域幅消費が、クライアントデバイスに利用可能な帯域幅量を超えるだろうことを予測データが示す場合には、選択することは、同一のメディアプログラムのより品質の低いメディアストリームから第２のセグメントを選択することを含む、ことと、を含む。

他の実施形態は、携帯電話、パーソナルコンピュータ、タブレットコンピュータ、ビデオゲームプレーヤー及び／又は他のメディアプレーヤーデバイスを提供する。メディアプレーヤーデバイスは、適切には、ネットワークへのインタフェースと、プログラミング命令を格納するように構成されたメモリと、プロセッサとを含む。プロセッサは、異なるビデオ品質を有する複数のメディアストリームから選択される一連のセグメントからなる受信メディアプログラムを処理するために、メモリに格納されたプログラミング命令を実行するようにプログラミングされ、又は、構成され、プロセッサは、第１の品質を有する第１のメディアストリームからビデオプログラムの第１のセグメントを要求、又は、取得し、第１のセグメントは、同一メディアプログラムの未来のセグメントの帯域幅消費を記述する予測データを含み、同一メディアプログラムの未来のセグメントの帯域幅消費が、クライアントデバイスに利用可能な帯域幅量を超えるだろうことを予測データが示す場合、同一メディアプログラムのより品質の低いメディアストリームから第２のセグメントを選択することによって、予測データに少なくとも部分的に基づいて、プロセッサは、ビデオプログラムの第２のセグメントを更に選択する。

更なる及び別のフィーチャ、態様、他の実施形態と共に、これらのフィーチャは、ここにより詳細に記述される。

例示的実施形態が、ここに、以下の図面と共に記述され、同様な参照番号は、同様な要素を示す。

データネットワークを介して、予測データと共に、適応的メディアストリームを提供するための例示的システムのブロック図である。 予測データを有する一連のデータセグメントの図である。 予測データを考慮するために、セグメントデータのリクエストを適応するための例示的プロセスのフローチャートである。 予測データを用いて、ネットワーク上の帯域幅を共有するための例示的プロセスの図である。

本発明の以下の詳細な説明は、その性質上単なる例示であり、本発明、又は、本発明の用途及び用法を限定することは意図していない。更に、前述の背景技術又は以下の詳細な説明に提示されるいかなる理論によっても拘束されるとする意図はない。

様々な実施形態は、メディアセグメントにエンコードされる予測データの使用を介して、メディアストリームの性能を改善することができる。予測データは、これから来るメディアコンテンツによって消費される可能性の高い帯域幅の指示を与える。高帯域幅のシーケンス（例えば、爆発）が来るだろうことをメディアプレーヤーが知っている場合、より品質の低いセグメントを要求することによって、また、それらの帯域幅消費を減少するために、及び／又は、適切な他の操作を行うために、ネットワーク上の他のデバイスにリクエストすることによって、これに適応することができる。メディアセグメントに予測データをエンコードすることによって、メディアプレーヤーは、帯域幅のこれから来る変化に予め適応することが出来、それによって、ネットワーク帯域幅の過消費を防止し、ユーザ経験を改善することができる。

上記したように、多くの適応的メディアエンコードスキームが、一定期間（例えば、一実施形態においては、２秒など）を表すメディアコンテンツのセグメントをエンコードする。各セグメントは、共通の期間を表すが、基礎のメディアコンテンツにおける差（例えば、画像データの圧縮性）は、個々のエンコードされたメディアセグメントのサイズにおける実質的な差を結果として生じることがある。爆発シーンの２秒を表す「低品質」のメディアセグメントは、例えば、より静的な画像が、より高いビットレート、フレームレート、解像度及び／又は他の品質パラメータでエンコードされたとしても、より静的な画像の２秒を表すセグメントよりも大きなデータファイルとなるだろう。これらの差は、基礎のデータのダイナミックレンジから帰結し、今度は、画像データの圧縮性に大きく影響を与えることができる。セグメントサイズにおけるこれらの違いは、メディアストリームが１以上のメディアプレーヤーに提供されるとき、帯域幅消費にかなり提供を与えることができる。

しかしながら、メディアプレーヤーが、セグメントをリクエストする前に、実際の、又は、相対的なセグメントサイズを知っている場合、メディアプレーヤーは、ネットワーク上の１以上のメディアプレーヤーに対するサービスの質を保持する必要があるなら、より良い、又は、より悪い品質のセグメントを適応的にリクエストすることができる。この結果、様々な実施形態は、これから来るメディアセグメントの実際の又は相対的なサイズをメディアプレーヤーが正確に予測し、これに応じて反応することを可能とする１以上のメディアセグメントに、予測データをエンコードする。

図に転じて、最初に図１を参照すると、ネットワーク１２５を介して複数の接続１３１、１３２、１３３を用いて、クライアントデバイス１２０へメディアストリームを適応的に配信するための例示的システム１００が示される。システム１００は、適切には、エンコーダ１０２とメディアサーバ１１４とを含む。図１に示される様々なコンポーネントは、共通のサービスプロバイダによって共同して提供されても良く、又は、異なるサービスプロバイダが、システム１００の異なるコンポーネントを提供するために、連携して動作しても良い。テレビネットワーク又は他のコンテンツプロバイダは、例えば、適切なフォーマットで既にエンコードされたコンテンツを提供することができ、それによって、幾つかの実装においては、個別のエンコーダ１０２の必要性を除去する。同様に、ユニキャスト及び／又はマルチキャストホスティングは、必要に応じて、任意の種類のコンテンツ配信ネットワーク（ＣＤＮ）又は他のサービス１１４によって実行されることができる。

エンコーダ１０２は、メディアプログラム１０４を１以上の適応的ストリーム１０５Ａ−Ｃにエンコードできる任意のデバイス又はサービスである。図１に示される例示的実施形態においては、エンコーダ１０２は、全体として同一のメディアプログラム１０４をそれぞれが表す複数のストリーム１０５Ａ−Ｃを生成するためにプログラムされるデジタルコンピュータシステムである。典型的には、それぞれのストリーム１０５Ａ−Ｃは、「ストリームレット」又は他の個々にアドレス指定可能なデータファイルにおけるプログラムのほんの一部を表す、より小さなセグメント１０６からなる。典型的には、異なるストリーム１０５Ａ−Ｃのセグメント１０６が、共通の時間インデックスに基づいて、相互に交換可能であるように、各ストリーム１０５Ａ−Ｃがエンコードされる。つまり、クライアントメディアプレーヤー１２０は、ネットワーク状態又は他のリソースが変化しても、シームレスな再生を継続するために、異なるストリーム１０５Ａ−Ｃからのセグメント１０６をミックス及びマッチすることができる。リソースが、制約を受けるようになる場合、プレーヤー１２０は、より低い品質のセグメント１０６をリクエストすることができる。逆に、リソースが十分にある場合、より高い品質のセグメント１０６がリクエストされることができる。メディアプレーヤー１２０は、典型的には、特定の時間に発生する特定の条件に適切ないかなる集合１０５からも、データセグメントを単純にリクエストすることにより、条件保証として、異なる品質レベル１０６間の「アップシフト」及び「ダウンシフト」をすることができる。

一般に、各ストリーム１０５をなすセグメント１０６の集合は、インターネット又は他のネットワーク１２５上で配信するために、コンテンツ配信ネットワーク（ＣＤＮ）又は他のサーバ１１４上に格納される。典型的には、１以上のクライアントデバイス１２０上で実行するメディアプレーヤーアプリケーション１３０は、メディアプログラム１０４を取得し、再生するために、必要な場合、適切なセグメント１０６を選択するために、インテリジェントロジックを含む。上記したように、ネットワーク１２５を介した配信において、変化するネットワーク又は他の条件を反映するために、より大きい帯域幅セグメント１０６が、より狭い帯域幅セグメント１０６とシームレスにミックスされることができるように、セグメント１０６は、ストリーム１０５間で交換可能であっても良い。幾つかの実装においては、プレーヤー自体が必要に応じてセグメント１０６を要求できるように、メディアプレーヤー１３０は、利用可能なセグメントのダイジェスト又は他の記述を最初に取得する。しばしば、そのようなリクエストは、ネットワーク１２５上で容易にルーティングでき、従来のＣＤＮ又は他のウェブ型サーバ１１０によって提供されることが出来る、従来のハイパーテキスト・トランスポート・プロトコル（ＨＴＴＰ）構成を用いて、処理されることができる。

上記したように、集合１０５Ａ−Ｃにおけるセグメント１０６のうちの幾つか又はその全ては、１以上のこれから来るメディアセグメント１０６のサイズを示す予測データ１０７を提供するためにエンコードされる。様々な実施形態においては、予測データ１０７は、望ましいレベルの解像度を提供する１以上のデータビットを有するように、実装されても良い。例えば、単一のビットは、未来のセグメント１０６が「狭い」又は「広い」帯域幅であることを示すことができるか、又は、そのビットは、特に広い帯域幅のセグメント１０６が来るときを示すためのフラグとして用いられることができる。追加的なビットは、これから来るセグメント１０６の実際のサイズのエンコードされた表示までの、任意の解像度のレベルを提供するのに使用されることができる。例示的実施形態においては、１６個の異なる帯域幅レベルを示すのに４ビットが用いられ、他の実施形態は、異なるレベルの解像度に対してより少ないビット又はより多いビットを用いることができ、及び／又は、解像度のレベルは、望まれる場合には、動作中、適応されることができる。

予測データ１０７によって予測される距離は、特定の実装により、任意のレベルで設定されることができる。プレーヤーアプリケーション１３０が、セグメント１０６を受信し、セグメントに含まれる予測データ１０７を解析し、予測セグメント１０６に対するリクエストを行う前に、予測データ１０７を考慮することができるように、予測データ１０７は、十分なリード時間を提供すべきである。他の実施形態は、望まれるに従い、より多い、又は、より少ないリード時間を提供することができるが、例示的実施形態においては、データ１０７は、ストリーム１０５の未来について約１０秒など（例えば、約５つの２秒メディアセグメント）を予測しても良い。

予測データ１０７は、利用可能な品質ストリーム１０５のそれぞれに属するセグメント１０６にエンコードされても良い。メディアプレーヤー１３０が、ストリーム１０５間でシフトするとしても、予測帯域幅消費は、少なくとも相対的な意味で依然有用であろう。つまり、異なるストリーム１０５は、異なるビットレート又は他の品質パラメータにおいてエンコードされることができるが、同一のストリーム１０５内での異なるセグメント１０６の相対的な帯域幅消費は、メディアプレーヤーが、異なるストリーム１０５のセグメント１０６間でシフトしても、多くの場合、依然予測可能であろう。

図１は、単一のサーバ１１４のみを示しているが、多くの実装は、ネットワーク１２５に渡って配置されるデバイス１２０への便利な配信のために、任意の数のサーバ１１４に渡って、ストリーム１０５及び／又はセグメント１０６を拡散することができる。複数のデータ接続１３１、１３２、１３３は、特定の実施形態に依存して、共通のサーバ１１４又は異なるサーバ１１４で確立されることができる。

各クライアントデバイス１２０は、ネットワーク１２５を介して、ストリーミングメディアコンテンツを受信することができる任意の種類のデバイスである。様々な実施形態においては、クライアントデバイス１２０は、携帯電話又は他の携帯デバイス、メディアプレーヤーアプリケーション１３０を実行するコンピュータシステム、タブレットもしくはノートブックコンピュータ、ビデオゲームプレーヤー、スタンドアロンメディアプレーヤー、テレビもしくはテレビ受信機、ビデオレコーダ及び／又は、任意の数の他の消費者制御デバイスで、実装されることができる。その結果、各クライアントデバイス１２０は、典型的には、関連したメモリ１３５又は他のデータストレージと共に、従来のプロセッサ１３４などを有する、消費者所有及び操作デバイスである。クライアントデバイス１２０は、また、望まれるように、ユーザ相互作用、ネットワークアクセス、及び、他の入出力フィーチャ用の適切なインタフェース１３６を含む。様々なクライアントデバイス１２０は、消費者電子機器、又は、パーソナルコンピューティング製品などに従来見られる任意の従来のハードウェア又はソフトウェア機能を有して実装されてもよい。

上記したように、各クライアントデバイス１２０は、視聴者に提示されるプログラム１０４に関連した異なるストリーム１０５Ａ−Ｃの任意のものに属するセグメント１０６を適応的にリクエストすることができる自体のメディアプレーヤーソフトウェア１３０を典型的には実行する。異なるパラメータを用いてエンコードされたセグメント１０６をリクエストすることにより、メディアクライアント１３０に提供されるメディアストストリームは、「オンザフライ（リアルタイム）」に調整されることができる。条件が決めるように、各メディアプレーヤー１３０Ａ−Ｃは、より低い帯域幅セグメント１０６をリクエストすることによって、異なるサーバ１１４又はＣＤＮにセグメントリクエストを再配送することによって、又は、必要に応じて、他の操作を行うことによって、システムリソースへの要求を減少することができる。更なる実施形態においては、必要なデータが、より効率的に、かつタイムリーに配信されることができるように、メディアプレーヤー１３０は、サーバ１１４への様々な接続１３１、１３２、１３３を管理することができる。図１は、クライアントデバイス１２０Ａへのセグメント１０６を提供する３つの接続１３１Ａ、１３２Ａ及び１３３Ａならびに、クライアントデバイス１２０Ｂへのセグメント１０６を提供する単一の接続１３１Ｂを示し；他の実施形態は、共有帯域幅内で動作する任意の数のクライアントデバイス１２０を組み込んでも良く、それぞれは、任意の数のデータソース１１４への任意の数の接続１３１、１３２、１３３を有する。

予測データ１０７は、任意の方法で使用されることができる。幾つかの実装においては、各クライアントデバイス１２０Ａ−Ｂは、データ１０７の使用により、より正確に、ネットワーク帯域幅に対する自体の未来のデマンドを予測することができる。帯域幅が制限される、例えば、これから来るコンテンツが、追加の帯域幅を要求するだろうことをデバイス１２０上のメディアプレーヤーが認識する場合、メディアプレーヤーは、より低い品質のストリーム１０５からセグメント１０６をリクエストすることにより、帯域幅の過負荷を予め防止することができる。逆に、メディアプレーヤー１３０は、条件が保証する場合には、より高い品質のストリーム１０５からセグメント１０６をリクエストすることにより、追加の帯域幅及び／又はより圧縮可能な未来のコンテンツを利用することができる。クライアントデバイス１２０は、したがって、セグメント１０６を選択する際、又は、ストリーム１０５間でシフトする際に通常考慮する任意の他の要因に加え、コンテンツ自体の帯域幅デマンドを考慮することができる。

更なる実施形態は、同一の共有帯域幅内で動作する他のクライアントデバイス１２０と、予測データ１０７を追加的に、又は、交互に共有することができる。複数のクライアントデバイス１２０が、同一のＬＡＮ上で、又は、同一のホーム内で動作しているならば、例えば、これらのデバイスは、必要に応じて、（例えば、ＬＡＮ上のお互いを認識することにより、ネットワーク１２５上のサービスに問い合わせることにより、任意の種類の発見プロトコルを介して、などで）相互に配置することができ、任意の方法で、これから来る帯域幅消費の兆候１４１を共有することができる。あるデバイス１２０Ａが、予測データ１０７を介して、高帯域幅データセグメントが、次に来ることを知るようになった場合、例えば、これから来る高帯域幅コンテンツの余地を作るために、共有帯域幅内で動作する他のデバイス１２０Ｂが「減速（ｔｈｒｏｔｔｌｅ ｂａｃｋ ）」することをリクエストするために、そのデバイス１２０Ａは、ローカルネットワーク上で兆候１４１を送信することができる。これらの兆候１４１は、ＬＡＮ又は他の共有ネットワーク空間上での伝送のために、任意の方法でフォーマット化されることができる。幾つかの実施形態においては、他のデバイス１２０が識別されていない、又は、それらの特定のアドレスが知られていなくても、ＬＡＮ又は他のネットワーク上で、兆候１４１は、同報として送信されることができる。兆候１４１を受信するデバイス１２０は、兆候１４１を送信したデバイス１２０を支援するために、その自体の帯域幅消費を（例えば、より低い品質のセグメント１０６をリクエストすることにより）減少するために、プログラムされてもよい。兆候１４１は、幾つかの実施形態において、予測データ１０７として同一の情報を提供することができ；他の実施形態は、受信セグメント１０６を提供する予測データ１０７よりも低いレベルの解像度で、フラグなどとして、兆候１４１を単純に提供しても良い。等価な実施形態は、任意の方法で改変されることができる。

図２は、それぞれ、予測データ１０７Ａ−Ｎを含む、一連のシーケンシャルメディアセグメント１０６Ａ−Ｎの例示的表現を示す。各予測データ１０７は、未来のセグメントの帯域幅を記述する数値的表現を含む。この例においては、予測データは、未来において「Ｎ」個のセグメントである、メディアセグメントの実際の又は相対的サイズを示す。上記したように、「Ｎ」は、実施形態及び望まれるリード時間量に依存して、１から１０又はそれ以上の任意の整数値を表すことができる。他の実施形態は、セグメント１０６内の任意の数のデータビットを用いた予測データ１０７を表しても良い。単一のビットは、例えば、これから来る帯域幅消費を示すフラグとして用いられることができ、又は、任意の数の追加的ビットは、解像度の追加的なレベルを提供するために用いられることができる。図２は、ストリーム１０５において各セグメント１０６にエンコードされる予測データ１０７を示しているが、他の実施形態は、望まれるならば、部分集合のみ（例えば、２、３、５、１０などのセグメントごと）において、予測データ１０７を提供してもよい。更に他の実施形態は、（例えば、広い帯域幅コンテンツがやってくるときのみ、又は、帯域幅の大きな変化がやってくるときのみ、など）必要に応じて、予測データ１０７を提供することができる。図２は、未来への固定された数のセグメント１０６の帯域幅を常に示す予測データ１０７を示すが、他の実施形態は、データ１０７における２つの兆候を提供することができ：第１の値が帯域幅消費を表し、第２の値が未来への時間又はセグメント１０６の数を示す。この第２の値は、今にも起こりそうな帯域幅消費、又は、望まれるなら、更なる柔軟性のための複数の「警告」を提供するために用いられることができる。予測データ１０７は、任意の方法で、エンコードされ、又は、表現されても良く、等価な実施形態は、任意の他の方法で、データセグメント１０６内に予測データ１０７を実装することができる。

図３は、メディアデバイス１２０によって実行される、メディアプレーヤーアプリケーション１３０又は他のロジックによって実行可能な例示的プロセス３００を示す。様々な実施形態においては、プロセス３００は、メモリ１３５に常駐し、メディアデバイス１２０のプロセッサ１３４によって実行されるソフトウェア又はファームウェアで実装される。他の実施形態は、任意の他の方法で、プロセス３００を実装しても良い。

図３に示されるように、メディアプレーヤー１２０は、望まれるならば、１以上のメディア接続１３１、１３２、１３３を適切に確立する（機能３０２）。上記議論は、３つの同時接続を参照するが、他の実施形態は、単一の接続のみ用いても良く、又は、任意の数の追加的な接続１３１−１３３が、望まれるならば、確立されてもよい。各接続は、メディアストリームのセグメント１０６をメディアプレーヤー１２０がリクエストすることを可能とする（機能３０４）。上記したように、各セグメント１０６は、リクエストされたメディアストリームの一定時間部分をエンコードする個別のデータファイルとして提供される。このエンコードされたメディアコンテンツは、望まれるならば、視聴者への再生のために、抽出され、デコードされ、レンダリングされることができる（機能３０６）。追加的なセグメント１０６は、メディアストリームの再生が完了するまで、リクエストされる（機能３０８）。

メディアプレーヤーデバイス１２０は、現在のリソース及び条件に適切なメディアストリームのセグメント１０６を適切に選択し、リクエストする（機能３１０）。従来の適応的ストリーミングアプリケーションにおいては、次のセグメント１０６は、典型的には、ネットワーク帯域幅、利用可能な処理リソース、及び、必要に応じて、他の要因に基づいて、様々な品質（つまり、様々なサイズ）のセグメント１０６から選択される。１以上の受信セグメント１０６は、予測データ１０７を含むが、この追加の情報は、また、未来のセグメント１０６をリクエストしていると考えることもできる。相対的に広い帯域幅セグメント１０６が来ることを予測データ１０７が示している場合、メディアプレーヤー１３０は、そのようにすることが適切ならば、より低い品質のセグメント１０６を予めリクエストしたいかもしれない。異なる品質に変更するか否かの判断は、任意の数の要因に基づくことができる。幾つかの実施形態においては、利用可能な帯域幅の量が、予測される未来の消費より少ない場合、切り替えが起こり；つまり、予測帯域幅が、現在利用可能な（又は、利用可能と予測される）帯域幅の量を超える場合、ダウンシフトが保証されるだろう。アップ及びダウンシフトの他の実施形態は、現在の性能、過去又は現在の帯域幅振動、及び／又は、必要に応じて、他の要因を考慮することができる。幾つかの実施形態が、これから来る広い帯域幅シーンの通知の際に、自動的にダウンシフトすることができる一方、他の実施形態は、現在又は予測帯域幅利用性を考慮することができ、予測消費が予測利用性を超える場合、ダウンシフトのみを考慮することができるだろう。幾つかの実装は、また、望まれるなら、予測できないネットワーク揺らぎ又は他の条件について、ある量の帯域幅を保存したいと思うかもしれない。

幾つかの実装において、プレーヤー１３０は、ユーザ経験に対し、視認できるショックを防止するために、より低い品質のストリーム１０５に次第に移行してもよい。つまり、高品質セグメント１０６からかなり低品質なセグメント１０６へすぐにジャンプするのではなく、プレーヤー１３０は、ユーザ経験を円滑にするために、中間的品質レベル１０５からのセグメント１０６をリクエストするかもしれない。

予測データ１０７は、また、上記したように、メディアプレーヤーデバイス１２０Ａ−Ｂ間で共有されることができる。様々な実施形態において、各メディアプレーヤー１２０は、他のプレーヤー１２０が、同一のネットワーク上で動作している、又は、現在のプレーヤー１２０と帯域幅を共有していると認識することができる。そのような場合、予測データ１０７は、プレーヤー１２０間で、共有されることができ、予測データ１０７に基づく他の指示１４１は、交換されることができ、あるプレーヤー１２０が、これから来る広帯域幅ビデオシーンを有している場合、より負荷の大きいプレーヤー１２０を支援するために、他のプレーヤー１２０は、共有帯域幅の消費を予め減少させることができるようにする。ある視聴者が、例えば、かなりダイナミックなアクションシーケンスを有するショーを見ており、同一のデータネットワーク上の他の視聴者が、相対的に静的なニュースショーなどを見ている場合、アクションシーケンスを見ている視聴者が、より圧縮可能なコンテンツを見ている視聴者と比較して、より大きな割合の共有帯域幅を受信できるように、２つのプレーヤー１２０は協働することができる。

図４は、予測情報１０７を共有するための例示的プロセス４００の図を示す。図４に示されるように、各クライアントデバイス１２０Ａ−Ｂは、適切には、セグメント１０６をリクエストし（機能４０２Ａ−Ｂ）、サーバ１１４からリクエストしたセグメントを受信する（機能４０３Ａ−Ｂ）。各クライアント１２０Ａ−Ｂは、相対的に広帯域幅のシーケンスが、近い未来にやってくるか否かを識別するために、配信されたセグメント１０６内に含まれる予測データ１０７を処理する（それぞれ、機能４０５Ａ−Ｂ）。そうならば、送信プレーヤー１２０が、近い未来に、追加の帯域幅を消費することを意図していることを示すために、通知４０６Ａ−Ｂが、他のプレーヤーに送信されることができる。通知４０６Ａ−Ｂは、必要に応じて、上記した兆候１４１に対応しても良い。ここに述べたように、予測データ１０７は、プレーヤー１２０間でルーチンとして共有されることができ；プレーヤーは、望まれるならば、これから来る帯域幅の兆候を頻繁に交換することができ、又は、プレーヤー１２０が、追加の帯域幅をすぐに必要であることを認識したときにのみ、通知４０６Ａ−Ｂは、交互に発生することができる。帯域幅通知４０６Ａ−Ｂは、ＬＡＮ又は他の基礎の共有ネットワークトポロジーと互換性のある任意のプロトコルで、アドレス指定された、又は、同報されたネットワークパケットとして、フォーマットされてもよい。

各メディアプレーヤー１２０Ａ−Ｂは、そのとき利用可能なネットワーク帯域幅、そのとき利用可能なコンピューティングリソース、以前にリクエストされたセグメント１０６から取得した予測データ１０７、及び／又は、共有ネットワーク上で動作する他のメディアプレーヤー１２０によって提供される任意の予測データ１０７、もしくは、他の兆候１４１などの要因に基づいて、これから来るデータセグメント１０６を選択する（機能４０８Ａ−Ｂ）。これから来る帯域幅のニーズについてのこの追加の情報は、必要に応じて、利用可能な帯域幅に合致するセグメント１０６に対して、各メディアプレーヤー１２０がより正確な選択をする（機能４１０Ａ−Ｂ）ことを可能とする。選択されたメディアセグメント１０６は、したがって、望まれるならば、メディアサーバ１１４又は他の適切なソースからリクエストされることができる（機能４０２Ｃ−Ｄ）。

したがって、上記の議論は、未来のメディアセグメントについての予測データのエンコード及び配信を介して、１以上の適応型メディアストリームの配信を改善するための、幾つかの異なるシステム、デバイス、及び、方法を考慮する。これらの一般的な概念は、任意の数の、代替ではあるが、等価な実施形態を生成するために、望まれるように、拡張され、又は、改変されてもよい。

語句「例示的」は、任意の数の代替形態を有することができる一例、インスタンス、又は、図説を表すために、本明細書において用いられる。例示的として本明細書に記述された任意の実装は、他の実装に対し、必ずしも、好適な、又は、利点のあるものとして解釈される必要はない。幾つかの例示的実施形態が、上記詳細な説明に提示されたが、多くの代替ではあるが、等価な変形例が存在し、本明細書で提示した例は、多少なりとも、本発明の範囲、応用性、又は構成を限定することは意図していない、ことは理解されるべきである。逆に、様々な変更は、請求項及びその法的な均等物の範囲から逸脱することなく、記述された機能、及び、要素の配置において行われることができる。

Claims (15)

1. 異なるビデオ品質を有する複数のメディアストリームから選択された一連のセグメントからなる受信されたメディアプログラムを処理するために、クライアントデバイスによって実行可能な方法であって、
   ネットワークを介してサーバから、第１の品質を有する第１のメディアストリームからのビデオプログラムの一連のセグメントの内の１つの第１のセグメントをリクエストして受信することであって、前記サーバから受信した前記第１のセグメントは、同一のメディアプログラムの未来のセグメントの帯域幅消費を記述する予測データを含む、ことと、
   視聴者への再生のために、前記ビデオプログラムの前記第１のセグメントをレンダリングすることと、
   前記第１のセグメントと共に受信した前記予測データに少なくとも部分的に基づいて、前記ビデオプログラムの前記未来のセグメントに対する複数の異なるビデオ品質の内の１つのビデオ品質を適応的に選択することであって、前記選択することは、前記同一メディアプログラムの前記未来のセグメントの前記帯域幅消費が、前記クライアントデバイスに利用可能な帯域幅の量を超えるだろうことを、前記予測データが示す場合に、前記同一メディアプログラムの前記複数のメディアストリームの内のより低い品質のメディアストリームから前記未来のセグメントの前記ビデオ品質を選択すること、を含み、
   前記ネットワークを介して前記サーバから、前記選択したビデオ品質を有する前記未来のセグメントをリクエストすることと、
   を含む方法。
2. 前記予測データは、前記未来のセグメントのサイズを示す、請求項１に記載の方法。
3. 前記未来のセグメントにエンコードされたコンテンツが、前記第１のセグメントにエンコードされた前記コンテンツほどは圧縮できない場合に、前記予測データによって示される前記未来のセグメントの前記サイズは、より大きいものである、請求項２に記載の方法。
4. 前記選択することは、利用可能な帯域幅の量を決定することと、前記予測データに基づいて、予測帯域幅に対して、利用可能な帯域幅について決定された量を比較することと、を含む、請求項１に記載の方法。
5. 前記選択することは、前記予測データに基づく予測帯域幅の前記量が、利用可能な帯域幅の前記量を超える場合に、より低い品質のメディアストリームから前記未来のセグメントの前記ビデオ品質を選択することを含む、請求項４に記載の方法。
6. 前記ネットワーク上に前記予測データの兆候を送信し、それによって、前記クライアントデバイスが、ネットワーク帯域幅に対するより大きなニーズを予測することを、前記ネットワーク上で動作する他のメディアプレーヤーデバイスに示す、ことを更に含む、請求項１に記載の方法。
7. 前記選択することは、前記同一のネットワーク上で動作する異なるクライアントデバイスから受信される兆候に基づいて、前記メディアストリームの前記未来のセグメントに対する後続のリクエストを適応することを含む、請求項１に記載の方法。
8. 前記兆候は、前記同一のネットワーク上で動作する前記異なるクライアントデバイスが、追加の帯域幅を必要とすることを示す、請求項７に記載の方法。
9. 前記後続のリクエストを前記適応することは、より低い品質のストリームから前記未来のセグメントをリクエストし、それによって、前記異なるクライアントデバイスのために、前記同一のネットワークの帯域幅を保存する、ことを含む、請求項８に記載の方法。
10. 前記クライアントデバイスは、プロセッサとメモリとを含み、前記プロセッサは前記リクエストすること、レンダリングすること、及び、選択することを実行するようにプログラムされる、請求項１に記載の方法。
11. メディアプレーヤーデバイスであって、
    ネットワークへのインタフェースと、
    プログラミング命令を格納するように構成されたメモリと、
    ネットワークを介してサーバから利用可能な異なるビデオ品質を有する複数のメディアストリームから選択された一連のセグメントからなる受信されたメディアプログラムを処理するために、前記メモリに格納された前記プログラミング命令を実行するように構成されたプロセッサと、を備え、
    前記プロセッサは、第１の品質を有する第１のメディアストリームからのビデオプログラムの第１のセグメントに対する、前記ネットワークを介した前記サーバへのリクエストを発行し、前記ビデオプログラムの前記第１のセグメントを前記サーバから受信し、前記サーバから受信した前記第１のセグメントは、同一のメディアプログラムの未来のセグメントの帯域幅消費を記述する予測データを含み、前記同一のメディアプログラムの前記未来のセグメントの前記帯域幅消費が、クライアントデバイスに利用可能な帯域幅の量を超えるだろうことを、前記予測データが示す場合、前記同一のメディアプログラムのより低い品質のメディアストリームを選択することによって、前記プロセッサは、前記予測データに少なくとも部分的に基づいて、前記ビデオプログラムの前記未来のセグメントのビデオ品質を適応的に更に選択し、前記プロセッサは、適応的に選択された前記ビデオ品質を有する前記メディアストリームから前記未来のセグメントをリクエストする、ことを特徴とするメディアプレーヤーデバイス。
12. 前記未来のセグメントにエンコードされるコンテンツが、前記第１のセグメントにエンコードされるコンテンツほどは圧縮できない場合に、前記予測データによって示される前記未来のセグメントのサイズは、より大きいものである、請求項１１に記載のメディアプレーヤーデバイス。
13. 利用可能な帯域幅の量を決定することによって、及び、利用可能な帯域幅の前記決定された量を、前記予測データに基づく予測帯域幅と比較することによって、前記未来のセグメントの前記品質が選択される、請求項１１に記載のメディアプレーヤーデバイス。
14. 前記同一のネットワーク上で動作する異なるクライアントデバイスが、追加の帯域幅を必要とすることを示す、前記同一のネットワーク上で動作する前記異なるクライアントデバイスから受信された兆候に基づいて、前記メディアストリームの前記未来のセグメントの前記品質が選択される、請求項１１に記載のメディアプレーヤーデバイス。
15. 前記プロセッサは、より低い品質のストリームからの前記未来のセグメントをリクエストすることによって、前記兆候に応答し、それによって、前記異なるクライアントデバイスのために、前記同一のネットワーク上の帯域幅を保存する、請求項１４に記載のメディアプレーヤーデバイス。