ストリーミングビデオデータの早送り再生または巻き戻し再生をシミュレートする方法
【課題】満足度を高めるための、ストリーミングビデオデータの早送り再生または巻き戻し再生をシミュレートする方法を提供する。
【解決手段】ストリーミングビデオデータをストリーミングレートで受信するステップと、受信した前記ストリーミングビデオデータを後に通常速度に対応する再生レートで再生するためにバッファに記憶するステップと、記憶されている前記ストリーミングビデオデータを通常速度よりも速い速度でバッファから再生するステップと、ストリーミングレートが再生レートよりも低いアンダーフロー状態についてバッファを監視するステップと、アンダーフロー状態の検出に基づき、記憶されているストリーミングビデオデータ間におけるバッファに所定のビデオクリップを挿入するステップとを実行する。
【解決手段】ストリーミングビデオデータをストリーミングレートで受信するステップと、受信した前記ストリーミングビデオデータを後に通常速度に対応する再生レートで再生するためにバッファに記憶するステップと、記憶されている前記ストリーミングビデオデータを通常速度よりも速い速度でバッファから再生するステップと、ストリーミングレートが再生レートよりも低いアンダーフロー状態についてバッファを監視するステップと、アンダーフロー状態の検出に基づき、記憶されているストリーミングビデオデータ間におけるバッファに所定のビデオクリップを挿入するステップとを実行する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ストリーミングビデオデータの早送り再生または巻き戻し再生をシミュレートする方法に関する。
【0002】
著作権
本願明細書の開示内容の一部は著作権保護を目的とする資料を含む。著作権の所有者は、特許商標庁に申請または記録されている限りにおいて、特許明細書またはその開示のいずれかによるファクシミリの複製に対しては異議を申し立てない。しかしながらそれ以外に関しては全ての所有権は完全に保有される。
【0003】
関連出願の相互参照
本願は、いずれの発明の名称も"A Multi-Source and Resilient Video Streaming System for Peer-to-Peer Networks"であり、また本願と発明者が同一である、2005年8月12日付で出願されたUS仮出願60/708,020(整理番号2005P14442US)および2005年12月12日付で出願されたUS仮出願60/749,730(整理番号2005P22668US)の利益を主張するものであり、また参照によりそれらを本願の一部とする。
【背景技術】
【0004】
セットトップボックス(STB)は、テレビ受像機がTV番組の再生および記録のようなサービスに関してサービスプロバイダネットワークへのユーザインタフェースとなることを可能にするデバイスである。STBのパーソナルビデオレコーダ(PVR)機能を使用することにより、ユーザは放送されたコンテンツを後で視聴するために記録することができる。
【0005】
ビデオ・オン・デマンド(VoD)システムにより、ユーザは特定のTV番組または他のビデオコンテンツの再生、また場合によってはSTBを使用したそれらの記録を要求することができる。典型的なVoDシステムにおいては、ユーザはSTBを使用して集中型のサービスプロバイダのネットワークに接続することができ、またサービスプロバイダによって提供された利用可能なコンテンツのセレクションを検索するために電子番組表(EPG)を使用し、視聴のために番組を選択することができる。ビデオデータは典型的には、ストリーミングデータとしてサービスプロバイダのネットワークを介してユーザのSTBへと伝送される。
【0006】
また一般的に、ピア・ツー・ピアネットワークによりユーザは同一のネットワークプロトコルおよびソフトウェアを共有し、ユーザを相互に接続することができ、またユーザそれぞれのリソースに直接的にアクセスすることができる。例えば、サービスプロバイダはピア・ツー・ピアネットワークを提供し、コンピュータユーザは自身のコンピュータをそのネットワークに接続し、ユーザそれぞれのリソース、例えばディジタルコンテンツファイルに直接的にアクセスすることができる。サービスプロバイダはピア・ツー・ピアネットワークを提供し、他のデバイス、例えばSTBのユーザは自身のデバイスをそのネットワークに接続し、ビデオコンテンツおよびTV番組が記憶されているユーザそれぞれのリソースに直接的にアクセスすることができる。加入者コミュニティピア・ツー・ピアネットワークにより加入者のコミュニティは相互に直接的にリソースにアクセスすることができる。ユーザは1つまたは複数のピアからデータを典型的にはストリーミングデータとして受信することにより、データをダウンロードすることができる。
【0007】
サービスプロバイダのネットワークの恒常的に増加している帯域幅および復元力のある要求は1つの挑戦であるが、慣例のストリーミングソリューションではこれらの要求を維持ですることはできない。図1に示されているような現在のVoDソリューションは典型的には、映画タイトルの簡素なセレクションを提供し、期間限定で、例えば24時間の間、プレミアムコンテンツのみをキャッシュすることができる。しかしながら、VoDシステムの加入者が見たいコンテンツを選択することができ、またコンテンツを見たいときにそのコンテンツを選択できたならば(すなわちオン・デマンド)、VoDアプローチはより頻繁に使用されることになるであろう。これにより顧客満足度は高まり、またサービスプロバイダに関しては収入が増え、チャーンが減ることになる。
【発明の概要】
【発明が解決しようとする課題】
【0008】
本発明の課題は、顧客満足度を高めるための、ストリーミングビデオデータの早送り再生または巻き戻し再生をシミュレートする方法を提供することである。
【課題を解決するための手段】
【0009】
この課題は、ストリーミングビデオデータの早送り再生または巻き戻し再生をシミュレートする方法が、ストリーミングビデオデータをストリーミングレートで受信するステップを有し、受信したストリーミングビデオデータを後に通常速度に対応する再生レートで再生するためにバッファに記憶するステップを有し、記憶されているストリーミングビデオデータを通常速度よりも速い速度でバッファから再生するステップを有し、ストリーミングレートが再生レートよりも低いアンダーフロー状態についてバッファを監視するステップを有し、アンダーフロー状態の検出に基づき、記憶されているストリーミングビデオデータ間におけるバッファに所定のビデオクリップを挿入するステップを有することによって解決される。
【0010】
また、ストリーミングビデオデータの早送り再生または巻き戻し再生をシミュレートする方法が、ストリーミングレートでビデオファイルからストリーミングビデオデータを受信するステップを有し、通常の視聴速度に対応する通常の再生レートで後に再生するために、受信したストリーミングビデオデータをバッファに記憶するステップを有し、スピードアップされた視聴速度に対応するスピードアップされた再生レートでの早送り再生のための命令を受信するステップを有し、ビデオファイルにおけるジャンプポイントから始まるストリーミングビデオデータを受信し、スピードアップされた再生レートでの再生をシミュレートするために、記憶されているストリーミングビデオデータをバッファから通常の再生速度よりも速い再生レートで再生するステップを有することによって解決される。
【0011】
殊にVoDシステムを拡大するために、本発明はSTB間のピア・ツー・ピア(p2p)ネットワークに関する。各STBは特定の実施形態によればネットワークのノードである。さらには、本発明の特定の実施形態はVoD・ツー・ピア(V2P)と称されるマルチソースストリーミング技術に関し、このマルチソースストリーミング技術によりサービスプロバイダのネットワーク内のあらゆるピアSTBはネットワーク内の他のSTBからビデオコンテンツを取得し視聴することができる。したがって本発明によるその種のV2Pネットワークは事実上加入者コミュニティのためのVoDシステムとなり、このVoDシステムにおいてはいずれのメンバーも他のいずれかのメンバーによってダウンロードおよび/または記録されたコンテンツを取得し視聴することができる。
【0012】
典型的には、加入者コミュニティはSTBのセットを含んでいるので、V2PはSTBからのコンテンツのオン・デマンドの視聴を可能にするマルチソースビデオストリーミングシステムである。本発明の原理により設計されているV2Pシステムのアーキテクチャをこのアーキテクチャの各構成要素の説明も合わせて説明する。そのようなV2Pシステムは、復元力があり(resilient)且つ高品質のビデオストリーミングに対して責任を負う。
【0013】
特定の実施形態によれば、本発明はサービスプロバイダの加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを供給するシステムを提供する。システムは、ダウンロード可能および記録可能なコンテンツを供給するよう動作するサービスプロバイダを含み、このコンテンツはダウンロードまたは記録された後にストリーミングデータとして供給することができる。またシステムは、サービスプロバイダと関連し、且つテレビ受像機との接続に適したデバイスの加入者コミュニティピア・ツー・ピアネットワークを含む。さらにシステムは、サービスプロバイダの加入者コミュニティピア・ツー・ピアネットワークにおけるノードである受信器と、能動的な供給側およびバックアップ的な供給側を含む供給側のセットとを含む。各供給側はサービスプロバイダの加入者コミュニティピア・ツー・ピアネットワークにおけるノードであり、各供給側はサービスプロバイダもしくは1つまたは複数の他のノードからコンテンツをダウンロードおよび/または記録した後にオン・デマンドストリーミングデータを供給するよう機能する。受信器は、この受信器による要求に応じて供給側のセットにおける1つまたは複数の供給側からストリーミングされたデータを受信するよう機能する。
【0014】
別の特定の実施形態によれば、本発明はサービスプロバイダの加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを供給する方法を提供する。本方法は、加入者コミュニティピア・ツー・ピアネットワークをサービスプロバイダの加入者に提供するステップと、ダウンロードおよび/または記録され、続けてストリーミングデータとしてオン・デマンドで供給される、ダウンロード可能および記録可能なコンテンツを提供するステップと、加入者コミュニティピア・ツー・ピアネットワークと関連する検索エンジンを提供するステップとを有する。本方法は、加入者を加入者コミュニティピア・ツー・ピアネットワークに接続するステップと、加入者コミュニティピア・ツー・ピアネットワークに接続されている他の加入者によって先行してダウンロードまたは記録されたコンテンツを検索し、1つまたは複数の他の加入者からストリーミングデータとしてそのようなダウンロードおよび/または記録されたコンテンツをオン・デマンドで受信するために、各加入者に検索エンジンの使用を許可するステップとを有する。
【0015】
さらに別の特定の実施形態によれば、本発明は加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを受信するシステムを提供する。システムは加入者コミュニティピア・ツー・ピアネットワークと、この加入者コミュニティピア・ツー・ピアネットワークにおけるノードであるストリーミングデータの受信器と、ストリーミングデータの供給側のセットとを有する。供給側のセットは能動的な供給側のセットとバックアップ的な供給側のセットとを有し、供給側のセットにおける各供給側は加入者コミュニティピア・ツー・ピアネットワークにおけるノードである。ストリーミングデータは複数のブロックを含む。オン・デマンドで受信されるべきストリーミングデータの各ブロックに関して、受信器は、FECエンコーディング・オーバヘッド比を使用し、このFECエンコーディング・オーバヘッド比を用いてFECエンコーディングされたブロックの個別に割り当てられた少なくとも1つの小部分を個別に割り当てられたデータレートで送信することを各能動的な供給側にシグナリグし、FECエンコーディングされたブロックのセグメントを受信し、ここで各セグメントは個別に割り当てられた小部分の少なくとも一部を表し、FECエンコーディングされたブロックをセグメントの集合体に基づきデコーディングし、このデコーディングされたブロックをバッファに記憶し、各能動的な供給側とのネットワークコネクションの性能を監視し、結果としてオーバーフローまたはアンダーフローが生じることになる状態を検出するためにバッファを監視し、ネットワークコネクションの性能およびバッファの状態に基づいて、バッファがオーバーフローまたはアンダーフローに達することを回避するために品質適合を実施する。
【0016】
別の特定の実施形態によれば、本発明は加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを受信する方法を提供する。本方法は、加入者コミュニティピア・ツー・ピアネットワークにおける候補供給側のセットから能動的な供給側のセットとなるべき供給側のセットを選択し、候補供給側のセットからバックアップ的な供給側のセットとなるべき別の供給側のセットを選択するステップを有する。本方法は、受信されるべきストリーミングデータの各ブロックに関して、FECエンコーディング・オーバヘッド比を使用するステップを有し、このFECエンコーディング・オーバヘッド比を用いてFECエンコーディングされたブロックの個別に割り当てられた少なくとも1つの小部分を個別に割り当てられたデータレートで送信することを各能動的な供給側にシグナリグするステップを有し、FECエンコーディングされたブロックのセグメントを受信するステップを有し、ここで各セグメントは個別に割り当てられた小部分の少なくとも一部を表し、FECエンコーディングされたブロックをセグメントの集合体に基づきデコーディングし、このデコーディングされたブロックをバッファに記憶するステップを有し、各能動的な供給側とのネットワークコネクションの性能を監視するステップを有し、結果としてオーバーフローまたはアンダーフローが生じることになる状態を検出するためにバッファを監視するステップを有し、ネットワークコネクションの性能およびバッファの状態に基づいて、バッファがオーバーフローまたはアンダーフローに達することを回避するために品質適合を実施するステップを有する。
【0017】
別の特定の実施形態によれば、本発明は加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを供給するシステムを提供する。システムは加入者コミュニティピア・ツー・ピアネットワークにおけるノードである受信器と、ストリーミングデータを有する供給側のセットとを含み、供給側のセットにおける各供給側は加入者コミュニティピア・ツー・ピアネットワークにおけるノードである。ストリーミングデータは複数のブロックを含み、またストリーミングデータの各ブロックに関して、各供給側は、使用されるべきFECエンコーディング・オーバヘッド比を表す受信器からの信号、個別に割り当てられたデータレート、またFECエンコーディング・オーバヘッド比を使用したブロックのFECエンコーディングにより生じるFECエンコーディングされたブロックの個別に割り当てられた小部分を受信し、またFECエンコーディングされたブロックの割り当てられた小部分の少なくとも一部を個別に割り当てられたデータレートで送信するよう動作する。
【0018】
別の特定の実施形態によれば、本発明は加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを供給する方法を提供する。加入者コミュニティピア・ツー・ピアネットワークにおいて受信器によって受信されるべきストリーミングデータの各ブロックに関して、本方法は、使用されるべきFECエンコーディング・オーバヘッド比を表す受信器からの信号、個別に割り当てられたデータレート、またFECエンコーディング・オーバヘッド比を使用したブロックのFECエンコーディングにより生じるFECエンコーディングされたブロックの個別に割り当てられた小部分の受信、またFECエンコーディングされたブロックの割り当てられた小部分の少なくとも一部を個別に割り当てられたデータレートでの受信器への送信を含む。
【0019】
別の特定の実施形態によれば、本発明はストリーミングビデオデータの早送り再生または巻き戻し再生をシミュレートするための方法を提供する。本方法は、ストリーミングレートでストリーミングビデオデータを受信するステップと、通常の速度に対応する再生レートで後に再生するために受信したストリーミングビデオデータをバッファに記憶するステップと、通常の速度よりも速い速度でバッファから記憶されているストリーミングビデオデータを再生するステップとを有する。本方法はまた、アンダーフロー状態についてバッファを監視するステップを有し、ここでストリーミングレートは再生レートよりも低く、またアンダーフロー状態の検出に基づき、事前に求められたビデオクリップを記憶されているストリーミングビデオデータ間におけるバッファに挿入するステップを有する。
【0020】
さらに別の特定の実施形態によれば、本発明はストリーミングビデオデータの早送り再生または巻き戻し再生をシミュレートするための方法を提供する。本方法は、ストリーミングレートでビデオファイルからストリーミングビデオデータを受信するステップと、通常の視聴速度に対応する通常の再生レートで後に再生するために受信したストリーミングビデオデータをバッファに記憶するステップと、スピードアップされた視聴速度に対応するスピードアップされた再生レートでの早送り再生のための命令を受信するステップとを有する。本方法はまた、ビデオファイルにおけるジャンプポイントから始まるストリーミングビデオデータを受信するステップと、スピードアップされた再生レートでの再生をシミュレートするために、記憶されているストリーミングビデオデータをバッファから通常の再生速度よりも速い再生レートで再生するステップを含む。
【0021】
本発明のこれらの特定の実施形態および他の特定の実施形態を以下ではより詳細に説明する。
【0022】
本明細書に組み込まれ、また本明細書の一部をなす添付の図面は本発明の種々の実施形態を示し、また以下の説明と関連してそれらの実施形態の説明に使用される。便宜上、全ての図面を通して同一の構成要素または同様の構成要素には同一の参照番号が付されている。
【図面の簡単な説明】
【0023】
【図1】慣例のビデオ・オン・デマンド(VoD)サービスを実施するためのシステムを示す。
【図2】ピア・ツー・ピアネットワークによって提供される付加的なコンテンツを用いて、慣例のビデオ・オン・デマンド(VoD)サービスを拡大するためのシステムの実施形態を示す。
【図3】ロングテールを表すグラフを示す。
【図4】VoD・ツー・ピア(V2P)システムの実施形態を示す。
【図5】V2Pシステムを使用してストリーミングセッションを実施するための方法のフローチャートを示す。
【図6】V2Pシステムの1つの実施形態を表すブロック図を示す。
【図7】ピア選択順位方程式のグラフを示す。
【図8】ストリーム管理モジュールの詳細を含む、V2P受信器を表すブロック図を示す。
【図9】動的バッファ管理技術がバッファオーバーフローまたはアンダーフローをどのようにして回避することができるかを表すグラフを示す。
【図10】バッファ管理スキーマを表すグラフを示す。
【図11】コネクション監視に使用される単純なバイナリツリーを示す。
【図12】一連のMPEGフレームを示す。
【図13】早送り動作をシミュレートするためにビデオデータ間に挿入されたビデオクリップを示す。
【図14】V2Pシステムの1つの実施形態を表すブロック図を示す。
【図15】V2Pシステムを評価するための例示的なセットアップを示す。
【図16】高帯域幅環境において実施されているV2Pシステムを示す。
【図17】V2Pシステムの1つの実施形態を表すブロック図を示す。
【図18】TV視聴行動およびロングテールを表すグラフを示す。
【図19A】V2Pシステムが標準画質(SD)品質で供給することができる、並行するストリームの数を表すグラフを示す。
【図19B】V2PシステムがSD品質で供給することができる、ストリームの最大数または累積数を表すグラフを示す。
【図20A】V2Pシステムが準DVD品質で供給することができる、並行するストリームの数を表すグラフを示す。
【図20B】V2Pシステムが準DVD品質で供給することができる、並行するストリームの数を表すグラフを示す。
【図21A】V2Pシステムが準DVD品質で供給することができる、並行するストリームの数を表すグラフを示す。
【図21B】V2Pシステムが準DVD品質で供給することができる、並行するストリームの数を表すグラフを示す。
【図22】V2Pシステムの保存の側面を表すグラフを示す。
【図23】共通のビデオフレームを識別するための方法を説明するフローチャートである。
【発明を実施するための形態】
【0024】
上述したように、殊にVoDシステムを拡大するために、本発明はSTB間のピア・ツー・ピア(p2p)ネットワークに関する。各STBは特定の実施形態によればネットワークのノードである。さらには、本発明の特定の実施形態はVoD・ツー・ピア(V2P)と称されるマルチソースストリーミング技術に関し、このマルチソースストリーミング技術によりサービスプロバイダのネットワーク内のあらゆるピアSTBはネットワーク内の他のSTBからビデオコンテンツを取得し視聴することができる。したがって本発明によるその種のV2Pネットワークは事実上加入者コミュニティのためのVoDシステムとなり、このVoDシステムにおいてはいずれのメンバーも他のいずれかのメンバーによってダウンロードおよび/または記録されたコンテンツを取得し視聴することができる。
【0025】
典型的には、加入者コミュニティはSTBのセットを含んでいるので、V2PはSTBからのコンテンツのオン・デマンドの視聴を可能にするマルチソースビデオストリーミングシステムである。本発明の原理により設計されているV2Pシステムのアーキテクチャをこのアーキテクチャの各構成要素の説明も合わせて説明する。そのようなV2Pシステムは、復元力があり且つ高品質のビデオストリーミングに対して責任を負う。
【0026】
有利には、サービスプロバイダが提供するV2Pサービスにより、このサービスプロバイダによって管理されているp2pネットワーク全体への違法的なビデオ配布を阻止することができる。殊に、サービスプロバイダは加入者STBによって記録されるコンテンツをサービスプロバイダによって提供されるコンテンツに制限することができるので、新たなビデオコンテンツをSTBに導入するメカニズムは存在しない(すなわち加入者が関与している限りシステムは閉じられている)。ピアSTB間でのビデオコンテンツのそれ以降の共有は、サービスプロバイダの顧客(加入者)であるSTPピアの閉じられたコミュニティに制限されている。コンテンツの違法な共有が行われることなく、いずれかのパーソナルコンピュータ(PC)または他の適切なデバイスをp2pネットワークに接続できるようにこのp2pネットワークを拡張することができる。
【0027】
本発明によればサービスプロバイダに関しては、サービスプロバイダの加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを提供するシステムおよび方法の種々の実施形態が考えられる。サービスプロバイダの加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを提供するシステムの1つの実施形態は、テレビ受像機と接続されるよう適合されたデバイスの加入者コミュニティピア・ツー・ピアネットワークと、ダウンロードまたは記録された後にストリーミングデータとして供給できるダウンロード可能および記録可能なコンテンツを提供するサービスプロバイダとを含む。このシステムにおいてはコンテンツの受信器とコンテンツを提供するストリーミングデータの供給側のセットとが存在し、この供給側には能動的な供給側とバックアップ的な供給側が含まれる。各供給側は、サービスプロバイダもしくは1つまたは複数の他のノードからコンテンツをダウンロードまたは記録した後にオン・デマンドストリーミングデータを供給するよう機能する。その種のシステムにおける受信器は、この受信器による要求に応じて供給側のセットにおける1つまたは複数の供給側からストリーミングされたデータを受信するよう機能する。受信器および供給側はそれぞれ加入者コミュニティピア・ツー・ピアネットワークにおけるノードであり、また各ノードとしてセットトップボックス、またはテレビ受像機およびサービスプロバイダのネットワークに接続されるよう適合されている他のデバイスが考えられる。サービスプロバイダは加入者コミュニティにおけるノードによってダウンロードまたは記録可能なオーディオデータ、ビデオデータまたはその両方のようなコンテンツを供給し、またこのダウンロードまたは記録可能なコンテンツを供給側として動作するノードからストリーミングデータとして供給することができる。
【0028】
種々の実施形態によれば、そのようなシステムを検索エンジンによって向上させることができ、この検索エンジンによりユーザはコンテンツブラウザを使用してコンテンツを検索し、またコンテンツ推薦によって推薦されるコンテンツを受信することができる。別の実施形態によれば、このシステムをさらにインセンティブマネージャによって向上させることができ、このインセンティブマネージャはストリーミングセッションへの関与に関してコンテンツの所有者、サービスプロバイダおよび供給側に報酬を与える。別の実施形態によれば、このシステムを付加的にディジタル権利マネージャによって向上させることができ、このディジタル権利マネージャはコンテンツの違法な配布を阻止する。
【0029】
前述との関連において、特定の実施形態によれば、本発明はサービスプロバイダの加入者に対して加入者コミュニティピア・ツー・ピアネットワークを提供し、加入者をこのネットワークに接続した後に、サービスプロバイダの加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを提供する方法に関する。本方法は、ダウンロードおよび/または記録され、続けてストリーミングデータとしてオン・デマンドで供給することができる、ダウンロード可能および記録可能なコンテンツの提供を含む。また本方法は、加入者コミュニティピア・ツー・ピアネットワークと関連した検索エンジンの提供と、各加入者による検索エンジンの使用およびオン・デマンドで選択されたデータの受信の許可を含む。殊に、加入者は加入者コミュニティピア・ツー・ピアネットワークに接続されている他の加入者によって先行してダウンロードまたは記録されたコンテンツを検索するために検索エンジンを使用する。続いて、加入者はそのようなダウンロードおよび/または記録されたコンテンツをストリーミングデータとして1つまたは複数の他の加入者からオン・デマンドで受信する。
【0030】
コンテンツのオン・デマンドの受信に関して、本発明の種々の実施形態は加入者コミュニティピア・ツー・ピアネットワークにおける1つまたは複数の供給側からストリーミングデータをオン・デマンドで受信するためのシステムおよび方法を提供する。そのようなシステムは受信器として機能するノードと、ストリーミングデータの供給側として機能するノードのセットと包含し、このノードのセットには能動的な供給側およびバックアップ的な供給側が含まれる。換言すれば、受信器ならびに供給側のセットにおける各供給側は加入者コミュニティピア・ツー・ピアネットワークにおけるノードである。そのようなシステムにおける受信器はオーディオデータ、ビデオデータまたは両方を含むストリーミングデータを受信する。受信すべきストリーミングデータの各ブロックに関して、受信器はFECエンコーディング・オーバヘッド比を使用し、また各能動的な供給側に個別に割り当てられたデータレートで、FECエンコーディング・オーバヘッド比を使用してFECエンコーディングされたブロックの個別に割り当てられた小部分を送信することをシグナリングする。受信器はFECエンコーディングされたブロックのセグメントを受信し、セグメントの集合体に基づきFECエンコーディングされたブロックをデコーディングし、またデコーディングされたブロックをバッファに記憶する。ここで各セグメントは個別に割り当てられた小部分の一部を表す。受信器は能動的な供給側をそれぞれ有しているネットワークコネクションの性能を監視し、また結果としてオーバーフローまたはアンダーフローが生じる状態を検出するためにバッファを監視する。コネクションの性能およびバッファの状態に基づき、受信器はバッファのアンダーフローまたはオーバーフローへの到達を回避するために品質適合を実施する。監視によりストリーミングセッションの中間における供給側の障害またはコンテンツの削除が検出され、またこの供給側の障害およびコンテンツの削除を処理するために、能動的なセットに付加的なバックアップピア、能動的な供給側の間でのレートの再分布およびFECエンコーディング・オーバヘッド調整のような一連の技術が使用される。
【0031】
既述のように、各受信器および各供給側は加入者コミュニティピア・ツー・ピアネットワークにおけるノードであり、またその種の各デバイスをテレビ受像機およびサービスプロバイダのネットワークに接続されるよう適合させることができる。換言すれば、その種のデバイスは種々の実施形態に応じてセットトップボックス、パーソナルコンピュータまたはモバイル装置でよい。各デバイスは受信器、供給側またはその両方として機能することができる。供給側は1つまたは複数のメトリクスのあらゆる組み合わせに基づき選択される。このメトリクスには供給側の供給状態または受信状態、利用可能なアップリンク帯域幅、処理能力、信頼性記録(reliability history)、パス待ち時間、パケット損失および公平性が含まれる。供給側の信頼性記録は特定の実施形態に応じて、デバイス故障率、ネットワーク接続時間およびコンテンツアベイラビリティを基礎とする。公平性はロードバランシングおよび先行の選択記録を基礎とする。
【0032】
特定の実施形態によれば、その種のシステムにおける受信器は、各能動的な供給側とのネットワークコネクションの性能の監視に基づいてストリーミングセッションに適合されるよう機能する。このようなネットワークコネクションの性能には、供給側がネットワークの不安定性、デバイス故障、またはストリーミングデータとして供給すべきコンテンツの削除を経験したか否かの検出を含む。また受信器は他の供給側から実際に受信したストリーミングデータのメトリクスに基づいて各ネットワークコネクションの性能を受動的に監視するよう機能する。また受信器は、目下のバッファサイズ、目下の再生レートおよび目下のストリーミングレートを含むバッファの監視に基づいてストリーミングセッションを適合させる。必要に応じて受信器は能動的な供給側間のレート分布、供給側のセットまたはFECエンコーディングパラメータを動的に調整することができる。受信器は新たなデータレートを割り当てることによって、または新たなブロックの小部分を割り当てることによって、能動的な供給側間のレート分布を調整するよう機能する。受信器は種々の実施形態に応じて、能動的な供給側を付加または除去することによって、バックアップ的な供給側を能動的な供給側のセットに付加することによって、またはバックアップ的な供給側のセットに供給側を付加することによって能動的な供給側のセットを調整することができる。受信器は新たなFECエンコーディング・オーバヘッド比または新たなFECエンコーディングスキーマを使用することによって、FECエンコーディングパラメータを調整することができる。FECエンコーディング・オーバヘッド比を使用することによって、受信器は供給側によって使用されるべきFECエンコーディング・オーバヘッド比を1つのブロックの後続のFECエンコーディングにおいてセットすることができるか、単純に、FECエンコーディング・オーバヘッド比を使用してFECエンコーディングされている事前エンコーディングされたブロックを選択するよう供給側にシグナリングすることができる。
【0033】
その種のシステムにおける受信器は特定の実施形態に応じて、能動的な供給側のセット間でストリーミングデータのソースとして使用されるべきメディアファイルの複数の個々のコピーにおける共通の始点も求める。受信器は期間を規定し、また各能動的な供給側から基準オブジェクトのセットを受信する。期間は加入者コミュニティネットワークと接続されているデバイスのクロック同期に関連させてもよい。各基準オブジェクトはその期間内にメディアファイルの個々のコピーにおいて現われる基準フレームに対応する。受信器は、基準オブジェクトの全てのセットに共通する共通の基準オブジェクトを識別するために、受信した基準オブジェクトのセットを比較し、共通の基準オブジェクトに対応する基準フレームとなるよう始点をセットする。ビデオファイルにおいては、各基準フレームはビデオフレームであり、また各基準オブジェクトはハッシュ値である。
【0034】
コンテンツのオン・デマンドの供給に関して、本発明の種々の実施形態は加入者コミュニティピア・ツー・ピアネットワークにおけるストリーミングデータをオン・デマンドで供給するためのシステムおよび方法を提供する。その種の実施形態はこのネットワークにおけるノードである受信器と、ストリーミングデータの複数のブロックの供給側のセットとを包含し、供給側のセットにおける各供給側もこのネットワークにおけるノードである。供給されるストリーミングデータの各ブロックに関して、その種のシステムにおける各供給側は、使用されるべきFECエンコーディング・オーバヘッド比を表す受信器からの信号、個別に割り当てられたデータ比、またFECエンコーディング・オーバヘッド比を使用したブロックのFECエンコーディングにより生じるFECエンコーディングされたブロックの個別に割り当てられた小部分を受信する。続いて各供給側はFECエンコーディングされたブロックの割り当てられた小部分の少なくとも一部を個別に割り当てられたデータレートで送信する。
【0035】
前記に付加的に、本発明の種々の実施形態はストリーミングビデオデータの早送り再生および巻き戻し再生をシミュレートするシステムおよび方法を含む。ストリーミングビデオデータの早送り再生または巻き戻し再生をシミュレートする方法の1つの実施形態は、ストリーミングビデオデータのストリーミングレートでの受信、受信したストリーミングビデオデータを後に通常速度に対応する再生レートで再生するためのバッファへの記憶、ストリーミングレートが再生レートよりも低いアンダーフロー状態に関するバッファの監視、および記憶されているストリーミングビデオデータ間におけるバッファへの所定のビデオクリップの挿入を含む。
【0036】
ストリーミングビデオデータの早送り再生および巻き戻し再生をシミュレートする方法の別の実施形態は、ストリーミングレートでのビデオファイルからのストリーミングビデオデータの受信、受信したストリーミングビデオデータを通常の視聴速度に対応する通常の再生レートで後に再生するためのバッファへの記憶を含む。この方法はさらに、スピードアップされた視聴速度に対応するスピードアップされた再生レートでの早送り再生または巻き戻し再生のための命令の受信、ビデオファイルにおけるジャンプポイントから始まるストリーミングビデオデータの受信、およびスピードアップされた再生レートでの再生をシミュレートするための、記憶されているストリーミングビデオデータのバッファからの通常の再生速度よりも速い再生レートでの再生を含む。その種の方法は、記憶されているストリーミングビデオデータ間における所定のビデオクリップのバッファへの挿入も含む。
【0037】
以下の記述では、本発明の複数の実施形態および本発明の実践形式が示されている添付の図面を参照する。他の実施形態を使用することもでき、また本発明の範囲を逸脱することなく構造的および機能的な変更も行えるものと解される。
【0038】
本発明の特定の実施形態を説明するためのコンテクストを提供するために、図1は慣例のビデオ・オン・デマンド(VoD)サービスを実現するシステムを示す。インフラストラクチャベースのメディアストリーミングまたは集中型のビデオ・オン・デマンド(VoD)ソリューションは一般的に1つまたは複数のメディアサーバ、また通常はセットトップボックス(STB)であるクライアントのセットを有する。メディアサーバはクライアントへのメディアのオン・デマンドストリーミングに対して責任を有する。場合によっては、VoDシステムはさらにキャッシングプロキシを有することができる。図1に示されているように、サービスプロバイダVoDシステム100は管理インフラストラクチャ110、メディアサーバ120およびコンテンツライブラリ130を有する。ここではセットトップボックス(STB)として示されているクライアントデバイス140はサービスプロバイダ100と通信するよう接続されており、またダウンロードまたはストリーミングされたコンテンツをビデオの一部としてコンテンツライブラリ130からオン・デマンドで受信する。管理インフラストラクチャ110はクライアントデバイス140からのリクエストのダウンロードおよびストリーミングを処理し、またサービスプロバイダ100とクライアントデバイス140との間の制御コネクションおよびデータコネクションを管理する。例えば、メディアサーバ120は要求されたメディアの管理インフラストラクチャ110を介したコンテンツライブラリ130からクライアントデバイス140へのオン・デマンドでのストリーミングを実施する。
【0039】
前述したように、図1に示されているような慣例のVoDソリューションは典型的には、映画タイトルの簡素なセレクションを提供し、期間限定で、例えば24時間の間、プレミアムコンテンツのみをキャッシュすることができる。しかしながら、VoDシステムの加入者がまさに視聴したいコンテンツを見たいときに視聴できる権限が与えられれば(すなわちオン・デマンド)、VoDアプローチはより頻繁に使用されることになるであろう。これにより顧客満足度は高まり、またサービスプロバイダに関しては収入が増え、チャーンが減る。
【0040】
セットトップボックス(STB)は、このSTBのパーソナルビデオレコーダ(PVR)機能を使用したTV番組の再生および記録のようなサービスに関してテレビ受像機がサービスプロバイダネットワークへのユーザインタフェースとなることを可能にするデバイスである。本発明の1つの実施形態によれば、全ての加入者のSTBはサービスプロバイダが管理するピア・ツー・ピア(p2p)ネットワークに接続され、したがってサービスプロバイダのネットワークのあらゆる加入者は、それらの加入者のSTBにダウンロードおよび/または記録されたビデオコンテンツを他の加入者のSTBにストリーミングすることができる。
【0041】
例えば、いずれの加入者もサービスプロバイダによって提供されるあらゆるTV番組または他のコンテンツを自身のSTBにダウンロードおよび/または記録することができる。他の加入者にコンテンツを利用できるようにするために、コンテンツを自動的にサービスプロバイダのp2pネットワークに自動的に通知または登録することができる。ネットワークのいずれの加入者もこのコンテンツを検索し、視聴することができる。V2Pと称されるそのようなシステムはSTBによって形成されるp2pネットワークに関するマルチソースビデオストリーミングシステムである。つまり、V2Pは複数のSTBからの高品質且つ復元力のあるビデオストリーミングを提供する。
【0042】
これに関して図2は、本発明の1つの実施形態によるコミュニティVoDシステムを構築するために、ピア・ツー・ピアネットワークによって提供される付加的なコンテンツを用いて慣例のビデオ・オン・デマンド(VoD)サービスを拡大するシステムを示す。図示されているように、サービスプロバイダVoDシステム200は管理インフラストラクチャ210、メディアサーバ220、コンテンツライブラリ230およびサービスプロバイダによって管理されるピア・ツー・ピア(p2p)ネットワーク250を有する。さらにp2pネットワーク250は、ここではセットトップボックス(STB)として示されているピアデバイス260a,260b,260c(以下ではピアデバイス260と称する)と拡張コンテンツライブラリ270aおよび270b(以下では拡張コンテンツライブラリ270と称する)を有する。拡張コンテンツライブラリ270はピアデバイス260に記憶されているダウンロードおよび/または記録されたコンテンツを有する。例えば、ピアデバイス260はコンテンツライブラリ230から管理インフラストラクチャ210を介してストリーミングされたメディアをダウンロードおよび/または記録および記憶することができる。p2pネットワーク250に接続されているあらゆる加入者によって記録された拡張コンテンツを用いるVoDシステムのコンテンツライブラリの拡張によりコンテンツの選択肢が増え、また共通のVoDシステムが構築される。
【0043】
特定の実施形態によれば、ここではセットトップボックス(STB)として示されているクライアントデバイス240はサービスプロバイダVoDシステム200と通信するよう接続されており、またダウンロードまたはストリーミングされたコンテンツをビデオの一部としてコンテンツライブラリ230から、または拡張コンテンツライブラリ270からオン・デマンドで受信する。管理インフラストラクチャ210はクライアントデバイス240からのリクエストのダウンロードおよびストリーミングを処理し、またサービスプロバイダVoDネットワーク200とクライアントデバイス240との間の制御コネクションおよびデータコネクションを管理する。例えば、メディアサーバ220は要求されたメディアの管理インフラストラクチャ210を介したコンテンツライブラリ230からクライアントデバイス240へのオン・デマンドでのストリーミングを実施する。またクライアントデバイス240は要求したメディアの拡張コンテンツライブラリ270からのオン・デマンドのストリーミングを要求することができる。p2pネットワーク250はこれらの要求を処理し、またp2pネットワーク250とクライアントデバイス240との間の制御コネクションおよびデータコネクションを管理し、要求されたメディアの拡張コンテンツライブラリ270からクライアントデバイス240へのオン・デマンドのストリーミングを実施する。
【0044】
V2Pソリューションは必ずしも図1に示されているような集中型のVoDソリューションに代わるものを意味していないが、図2に示されているように、そのようなソリューションについての補完的な分散型の拡張として使用することができる。VoDとV2Pは一緒に膨大な量のコンテンツを加入者にもたらすことができる。集中型のVoDは非常に人気のある大多数のコンテンツプログラムを提供し続けることができ、これに対しV2Pはいわゆる「ロングテール」市場を提供することに良く適している。
【0045】
図3は、ロングテールを表すグラフを示す。図3によれば、膨大な量になる余り人気のないアイテムの集合体を合計すれば組織に関して多額の利益になる可能性がある。多くのビジネスでは、少数のオーディエンスにのみ関心があるコンテンツアイテムを売ることによって利益を得ることができる。これらのあまり人気のないコンテンツアイテムはそのようなオンラインビジネスに関してロングテールを作り上げることができる。ロングテールからコンテンツアイテムを提供することにより、顧客は以前見つからなかったコンテンツを発見、購入、および照会することができる。同様にして、V2Pはビデオ・オン・デマンド市場に関するロングテール現象にレバレッジを導入することができ、これにより、それらのあまり人気のない番組の反復的な視聴から収入を得ているコンテンツ所有者およびサービスプロバイダの双方にとって強力なビジネスモデルが実現される。さらにV2PはこれらのSTBリソースを供給する加入者に報酬を与える。
【0046】
V2P技術は慣例のストリーミングソリューションでは取り組むことができなかった多くの技術的な要求(限定的なアップストリーム帯域幅や復元力が含まれる)に取り組んでいる。
【0047】
現在では、DSLおよびケーブルモデムは家庭での使用に関する2つの一般的なブロードバンド技術である。両方とも非対称的な帯域幅特性を有する。つまりダウンロード帯域幅はアップロード帯域幅よりも高い。各STBに対するアップロード帯域幅の制約を解消するために、V2Pはストリーミングソースとして複数のSTBを使用し、また受信側のSTBはこれらの複数の供給側からのストリーミングセッションを調整する。アップロード帯域幅もダウンロード帯域幅も増大したとしても、V2Pは対称的な帯域幅環境でも非対称的な帯域幅環境でも高品質且つ復元力のあるストリーミングを提供するために依然として使用することができる。
【0048】
ネットワークおよびデバイスはまだ完璧なものではなく、つまり復元メカニズムは逆の条件を考慮するために設計されなければならない。xDSLまたはケーブルモデムコネクションを介するV2Pストリームおよびネットワーク自体の信頼性が高くないので、不安定なネットワークを介する復元力のあるストリーミングがV2Pに関する1つの争点である。如何なる時点においてもSTBはスイッチオフされる可能性がある。もしくはコンテントがストリーミングセッション中に削除される可能性がある。継続的且つ円滑なストリーミングを提供するために、V2Pは非常に耐性の高いエラー回復メカニズムを要求する。特定の実施形態によれば、V2Pはリンクならびにデバイスの不信頼性に取り組み、また高品質のストリーミングを提供するために、インテリジェントなピア選択、フォワード・エラー・コレクション(FEC)、動的なレート分布、動的なバッファ管理、ネットワークトモグラフィを基礎とするコネクション監視のようなメカニズムの組合せを使用する。
【0049】
図4は、VoD・ツー・ピア(V2P)システムの実施形態を示す。図示されているように、V2Pシステム400は受信器410、送信器420a,420bおよび420c(以下では送信器と称する)、リソース管理フレームワーク(RMF)430ならびにインセンティブマネージャ440を有する。また図4にはサービスプロバイダ450およびコンテンツ所有者460も示されている。ここではセットトップボックス(STB)として示されている受信器410は受信側のピアであり、送信器420からストリーミングメディアを受信する。ここではセットトップボックス(STB)として示されている送信器420は送信側のピアであるか、ストリーミングメディアの供給側である。受信器410は時には送信側のピアとしても動作できることを言及しておく。同様に、送信器420のいずれかは時には受信側のピアとして動作することもできる。リソース管理フレームワーク(RMF)430はサービスプロバイダによって管理される管理インフラストラクチャである。サービスプロバイダは受信器410と送信器420との間の制御コネクションおよびデータコネクションを管理し、要求されたメディアのオン・デマンドのストリーミングを実施する。またRMF430により受信器410は送信器420にダウンロードおよび/または記録され記憶されたストリーミング可能なコンテンツ、例えばメディアファイルについてV2Pシステム400を検索することができる。またRMF430により受信器410はコンテンツ推薦を受信することができる。インセンティブマネージャ440はV2Pシステムを使用する会計状況を管理する。これには、ストリーミングメディアとして特定のコンテンツを受信した受信器への課金、ストリーミングメディアの供給側への報酬またコンテンツの各ストリーミングに対するサービスプロバイダ450およびコンテンツ所有者460への報酬が含まれる。
【0050】
図4に示されているV2Pシステムはマルチソースストリーミングシステムである。このことは、各ストリーミングセッションが1つの受信器と送信器または供給側のセットを含むことを意味している。1つの基本的な仮定は、各供給側が所定のコンテンツアイテムに対応するメディアファイルの同一のコピーを有しているということである。しかしながら、供給側のSTBが同期しておらず、またそれらSTBのメディアファイルのコピーが完全に同一でない場合には、特定の実施形態によるV2Pは複数の供給側からのストリーミングメディアを同期するメカニズムを提供する。以下ではこの同期メカニズムを詳細に説明する。V2Pはメディアファイルを(例えば1〜2秒の再生に適した)小さいデータブロックのセットに分割し、各ソースが同一のブロックの小部分を提供する。その結果、全ての供給側が1つのファイルの各ブロックに寄与することになる。
【0051】
例えば、特定の実施形態によれば、パケット損失を許容するためにメディアファイルの各ブロックをフォワード・エラー・コレクション(FEC)コードを用いて符号化することができる。FECエンコーディングスキーマは2つのパラメータ(n,k)で表され、データブロック毎にn個のパケットがk個のパケット(但しn>k)の代わりに送信される。n個のパケットの中からのいずれかのk個のパケットはブロックを再構築することができる。したがって、ストリーミングセッションはブロック毎に(n−k)個までのパケットの損失を許容することができる。FECエンコーディング・オーバヘッド比αは次式のように定義される。
【数1】
【0052】
FECエンコーディング・オーバヘッド比およびエンコーディングスキーマはストリーミングセッションに関するストリーミングレートおよびパケット損失許容度に対して多大な影響を及ぼす。したがってFECエンコーディング・オーバヘッド比をストリーミングセッションの特定のエンコーディングスキーマに関して確立することができる。1つの例において、FECエンコーディング・オーバヘッド比は供給側によって使用されるべきエンコーディングパラメータを確立するために使用され、また別の例において、FECエンコーディング・オーバヘッド比は特定のエンコーディングパラメータに適しているデータのFECエンコーディングされたブロックを選択するよう供給側にシグナリングするために使用することができる。一例として、図5は本発明の1つの実施形態によるV2Pシステムを使用してストリーミングセッションを実施するための方法のフローチャートを示す。ストリーミングセッションは、特定のメディアファイルのような特定のコンテンツに関するストリーミング要求を行う受信器によって開始される。
【0053】
ステップ510では、要求されたメディアファイルを供給することができる候補供給側のセットを取得する。候補供給側は、要求されたメディアファイルのコピーを有するピアである。例えば、受信器はV2Pシステムにおける特定のコンテンツを検索するために検索エンジンを使用して、コンテンツの候補供給側のセットを取得することができる。
【0054】
ステップ520では、受信器が候補供給側のセットから能動的な供給側のセットおよびバックアップ的な供給側のセットを選択する。能動的な供給側は、要求されたメディアファイルを受信器にストリーミングするためにストリーミングセッション中に協力的に動作するピアである。バックアップ的な供給側は、1つまたは複数の能動的な供給側がネットワークの不安定性、デバイス故障またはコンテンツの損傷または削除に遭遇した場合に、ストリーミングセッション中に支援することができるピアである。受信器は種々の判定基準、例えばピアの状態、利用可能なアプリンク帯域幅、処理能力、信頼性記録、パス待ち時間、パスパケット損失および公平性のメトリクスなどに基づきピアを選択することができる。
【0055】
ステップ530では、受信器が各能動的な供給側との制御コネクションを開始する。受信器は公知の多数の技術の中からいずれか1つを使用することができる。例えば、受信器は伝送制御プロトコル(TCP)を使用して制御パケットを送信することができる。
【0056】
ステップ540では、各能動的な供給側が受信器とのデータコネクションを開く。受信器は公知の多数の技術の中からいずれか1つを使用して、供給側からストリーミングデータを受信することができる。例えば、受信器はユーザデータグラムプロトコル(UDP)を基礎とするスキーマを使用してストリーミングデータを受信することができる。
【0057】
ステップ550では、受信器は各能動的な供給側にFECエンコーディングされたブロックの少なくとも1つの小部分を割り当てられたデータレートで送信するようシグナリングすることによって、供給側からのFECエンコーディングされたブロックの小部分を要求する。割り当てられたデータレートの合計は目標のストリーミングレートを表す。各能動的な供給側はFECエンコーディングされたブロックの一部を送信し、このブロックの一部は特定のFECエンコーディング・オーバヘッド比を有する特定のFECエンコーディングスキーマを使用してFECエンコーディングされている。各能動的な供給側は、FECエンコーディングされたブロックの少なくとも1つの小部分を送信するための信号を受信器から受信すると、特定のFECエンコーディング・オーバヘッド比αを使用して特定のブロックをFECエンコーディングすることができる。択一的に各供給側は、1つまたは複数のFECエンコーディング・オーバヘッド比を使用してブロックを事前エンコーディングすることができ、また受信器からの信号の受信に応答して、事前エンコーディングされたブロックの一部を選択することができる。
【0058】
ステップ560では、受信器がFECエンコーディングされたブロックの部分またはセグメントを受信する。ネットワークの不安定性、デバイス故障ならびにコンテンツの損傷または削除に起因して、受信器はFECエンコーディングされたブロックの要求した小部分を実際には全て受信できない可能性がある。受信器が受信する部分またはセグメントは、受信器がステップ550において要求したFECエンコーディングされたブロックの小部分に対応する。実際に受信した部分またはセグメントに基づき、受信器は実際の受信データレートを求めるために各能動的な供給側とのコネクションの性能を受動的に監視する。実際の受信データレートの合計は現在のストリーミングレートを表す。
【0059】
ステップ570では、受信器がエンコーディングされたブロックの受信した部分またはセグメントに基づきブロックをデコーディングし、デコーディングされたブロックをバッファに記憶する。ブロックのデコーディングには、受信した部分またはセグメントからのFECエンコーディングされたブロックの再構築、再構築されたFECエンコーディングされたブロックのFECデコーディング、また使用される特定のビデオエンコーディングスキーマ(例えばMPEG)に応じたFECデコーディングされたブロックのさらなるデコーディングが含まれることを言及しておく。受信器は目下の再生レートでのバッファからの再生のためにデータを消費する。
【0060】
ステップ580では、受信器がバッファの状態を検査する。目下のバッファサイズ、目下の再生レートおよび目下のストリーミングレートを監視することによりバッファの状態を評価することができる。これらのメトリクスに依存して、バッファは3つのゾーン、すなわち加速ゾーン、快適ゾーンまたは減速ゾーンの内の1つにおいて動作することができる。例えば、バッファが快適ゾーンにおいて動作している場合には、受信器はステップ582bに進み、ストリーミングセッションを継続する。バッファが加速ゾーンまたは減速ゾーンにおいて動作している場合には、受信器はステップ582aに進む。
【0061】
ステップ582aでは、受信器がバッファのオーバーフローまたはアンダーフローを回避するために1つまたは複数のストリーミングレート、能動的なセットにおける供給側およびエンコーディング・オーバヘッド比を必要に応じて調整する。いずれかの供給側が能動的な供給側のセットに加えられる場合には、ステップ530および540が実施される。
【0062】
ステップ582bでは、受信器がストリーミングセッションは終了したか否かを求める検査を実施する。ストリーミングセッションが終了している場合には、プロセスがステップ590において終了する。ストリーミングセッションが終了していない場合には、プロセスはステップ550に戻る。
【0063】
したがってV2Pにおけるストリーミングセッションの一例は以下のステップを含む:
1.先ず、受信器ピアP0はp2pネットワークの検索エンジンから候補供給側のセットを取得する。
【0064】
2.候補供給側のセットから、受信器ピアP0は能動的な供給側としてピアP1,P2〜PNのセットを選択し、またバックアップ的な供給側としてP1,P2〜PMのセットを選択する。
【0065】
3.受信器ピアP0は能動的なセットにおける各供給側との制御コネクションを開始することによりストリーミングセッションを始める。
【0066】
4.制御コネクションを受信した後に、各供給側Piは受信器ピアP0とのデータコネクションを開く。
【0067】
5.受信器ピアP0は各供給側に特定のエンコーディング・オーバヘッド比αでエンコーディングされた特定のブロックの小部分を送信するよう周期的にシグナリングする。
【0068】
6.各供給側Piはファイルブロックをエンコーディングし、特定のレートにしたがいファイルファイルの小部分を送信する。
【0069】
7.各ブロックに関して十分なデータを受信した後に、受信器ピアP0はブロック全体をデコーディングし、バッファに記憶する。受信器側における再生器はバッファからデータを使用する。
【0070】
受信器ピアP0は、再生器に供給するためにデータが常にバッファ内に存在すること、またバッファオーバーフローを回避するためにバッファは一杯でないことを保証するためにネットワーク変化およびデバイス故障に反応する。必要に応じて、受信器ピアP0は1つまたは複数のバックアップ的なピアを能動的な供給側のセットに付加し、また新たに付加された幾つかのピアに対してステップを3〜4回繰り返す。
【0071】
受信器ピアP0はセッションが終了するまでステップを5〜7回繰り返す。
【0072】
図6はV2Pシステムのブロック図を示し、またさらに本発明の1つの実施形態による受信器を示す。この実施形態において、V2Pシステム600は受信器610、送信器620、リソース管理フレームワーク(RMF)630およびインセンティブマネージャ640を有する。受信器610はストリーミングデータを受信するために送信器620と対話する。受信器610はユーザがp2pネットワークを検索できるようにするためにRMF630と対話する。受信器610はインセンティブマネージャ640と対話し、このインセンティブマネージャ640はユーザへの課金および適切なエンティティへの報酬の付与に対して責任を有する。
【0073】
図6によれば、受信器610はさらにピア選択モジュール6110、ストリーム管理モジュール6120、インタラクティビディ管理モジュール(この実施形態においては再生器モジュールと表記する)6130、品質適合モジュール6140、コンテンツ検索およびコンテンツ推薦モジュール6150、照会モジュール6160およびデータ管理モジュール6170を有する。
【0074】
一時的に、ピア選択モジュール6110は能動的なピアおよびバックアップ的なピアまたは特定のコンテンツのストリーミングデータの供給側を選択するためにピア選択プロセスを使用する。ストリーム管理モジュール6120は能動的な供給側との制御コネクションおよびデータコネクションを管理し、能動的な供給側からのストリーミングデータを受信し、またストリーミングデータをデコーディングしてバッファに記憶する。またこのストリーム管理モジュール6120はバッファを管理し、ストリーミングレートを各能動的な供給側に動的に分布させ、受信器と各能動的な供給側との間のコネクションを監視し、またユーザからのインタラクティブな再生要求を管理する。この実施形態においては再生器6130モジュールとして示されているインタラクティビディ管理モジュール6130はインタラクティブな再生制御を提供し、またストリーム管理モジュール6120と対話するので、ユーザはストリーミングセッション中の一時停止、早送りおよび巻き戻しを行うことができる。品質適合モジュール6140はストリーム管理モジュール6120およびピア選択モジュール6110と対話し、ネットワークの不安定性、能動的な供給側の障害およびコンテンツの損傷または削除が生じた場合には、復元力があり且つ高品質のストリーミングを提供する。場合によっては、品質適合モジュール6140はそのような状況に対処するためにストリーミングデータの再供給を能動的な供給側に要求することができる。
【0075】
コンテンツ検索およびコンテンツ推薦モジュール6150はRMF630と対話し、特定の実施形態によれば、これによりユーザは特定のコンテンツを検索することができ、またコンテンツ推薦をユーザに提供することができる。参照モジュール6160はRMFおよびピア選択モジュール6110と対話し、遠隔のピアに関する情報を取得する。データ管理モジュール6170は受信したストリーミングデータの受信器の局所的な記憶装置における記憶を管理する。以下ではこれらのモジュールをそれぞれ説明する。
【0076】
ピア選択モジュール6110は能動的なピアのセットおよびバックアップ的なピアのセットを求めるためにピア選択プロセスを使用する。能動的なピアはストリーミングセッションのコンテンツを提供する。バックアップ的なピアはいずれかのSTBの故障中、またその時点における能動的なピアが目標のストリーミングレートを提供することができないときにネットワークが不安定になっている間に活動状態になる。またバックアップ的なピアを、ストリーミングセッション中に1つまたは複数の能動的なピアがコンテンツを削除するか、コンテンツの損傷が生じると活動状態にすることができる。
【0077】
この実施形態においては、ピア選択が2つのステップで実施される。第1のステップにおいては、RMF630がストリーミングされるコンテンツを有する候補供給側のセットを戻す。典型的な候補供給側のセットの大きさは15〜20のピアである。メディアファイルの複数のコピーがネットワーク内で発見された場合、この選択プロセスは限定的なリソースを有するピアを排除する。RMF630から候補供給側のセットを取得した後に、ピア選択モジュール6110は種々の判定基準に基づき能動的なピアのセットおよびバックアップ的なピアのセットを求める。例えば、後続のピアの状態、帯域幅、デバイス特性、信頼性、待ち時間、損失比および公平性に関する判定基準を使用することができる。
【0078】
1.ピア状態(S)
ピアの状態をピア選択の間に考慮することができる。ピアがストリームを受信している場合には、アップリンクは使用することができない。しかしながら、受信側のピアが別のストリーミングセッションを提供することを決定し、アップリンクがこの提供のために完全に使用される場合には、受信するストリーミングの品質は劣化することになる。何故ならば、シグナリングプロトコルはアップリンクの小さい小部分を使用するからである。したがって、供給側としてアイドル状態のピアを使用することが望ましい。ピアのSERVING(提供)状態またはRECEIVING(受信)状態の間に、ピア選択モジュール6110はピアiに対してSi=aiを割り当て、ここでaは利用可能なリソースに基づき計算される。ピアがIDLE(アイドル状態)であり、且つ提供のためのリソースを有する場合には通常Si=1である。
【0079】
2.供給側の利用可能なアップリンク帯域幅(B)
ストリーミングセッションに関して過剰に多いピアまたは過剰に少ないピアを使用することは望ましくない。過剰に多いピアが使用される場合には、受信器は多数のコネクションを維持しなければならない。1つまたは2つの供給側が使用される場合には、1つの供給側の故障はストリーミング品質に非常に重大な影響を及ぼすことになる。ストリーミングレートがR0である場合、ピア選択モジュール6110は、ピアiが≧R0/3を提供できる場合にはBi=1を割り当て、ピアが≧R0/4を提供できる場合にはBi=0.75を割り当て、これ以降は同様のことが繰り返される。
【0080】
3.CPU、記憶スペース(C)
STBが適当なCPUおよび記憶スペースを有する場合には、ピア選択モジュールはピアを受け入れることができる。ピア選択モジュールは、ピア状態がSERVINGまたはRECEIVINGでないときに、ピアiがCPU400MHz以上を有し、且つRAMが128MB以上であればCi=1を割り当てる。STBがストリーミングセッションに関与するためには十分なリソースを有していない場合にはCi=0である。
【0081】
4.信頼性記録(H)
信頼性記録Hは如何なる時点においてもスイッチオフされる可能性のあるSTBの信頼性を表す。STBのコンテンツはストリーミングセッション中に削除される可能性がある。したがってSTBの信頼性記録は復元力のあるストリーミングの提供に対して著しい影響を及ぼす。ピア選択モジュールは信頼性メトリクスに0〜1の値を割り当てる。
【0082】
5.供給側から受信器までのパス待ち時間(D)
待ち時間または一方向遅延を、供給側が受信器からどれほど離れているかを決定するために使用することができる。供給側が非常に良好なリソースを有しているとしても、ピアが世界の反対側に位置している場合には、安定したレートでストリーミングを提供することはできない。供給側が受信器の同一のサブネット内に存在するか、受信器が存在している同一の地理的なロケーション内に供給側が存在する場合、通常の場合待ち時間は実際に低く、またこれらの供給側は受信器から遠く離れて存在している供給側を上回る性能を有する。ピア選択モジュールは、ピアiが50ms以下の往復遅延時間(以下ではRTTと称する)の距離にある場合にはDi=1を割り当て、ピアiが100ms以下のRTTの距離にある場合にはDi=0.5を割り当て、ピアiが200ms以上のRTTの距離にある場合にはDi=0を割り当てる。
【0083】
6.パスのパケット損失比(L)
パケット損失比はネットワークの信頼性を表す。損失比の範囲は0<L<1である。
【0084】
7.公平性(F)
ピア選択メカニズムにおける第一の重要性はストリーミングの品質であり、したがってこのメカニズムは受信器に適したストリーミングセッションに関する最善のピアのセットを選択する。しかしながら、(リソース、信頼性および他のピア選択判定基準に関して)同等の品質を有する複数のピアを利用できる場合には、他のピアに比べて選択される頻度が低いピアに優先権が与えられる。
【0085】
上記の判定基準に基づき、ピア選択モジュールは各ピアの順位を計算することができる。Riがピアiの順位を表す場合にはRiを以下のように表すことができる:
Ri=CiSi(BiDi)Hi(1−Li)
ピア選択プロセスはこの順位に基づき上位のN+M個のピアを選択する。種々のピアが(N+M)番目の順位を有する場合には、ピア選択プロセスは公平性インデクス(F)が低いピアを選択し、全ての加入者はコンテンツアイテムを提供する機会を得て、またシステムから報酬を得る。
【0086】
図7はピア選択順位方程式のグラフであり、また使用されるピア選択判定基準にしたがいピアの順位をどのように変更できるかを示す。例えば、図7には高帯域幅(例えば384Kbps以上のアップリンク帯域幅)のピアの順位および低帯域幅(例えば128Kbps以上のアップリンク帯域幅)のピアの順位が遅延および損失のメトリクスに関してプロットされている図示されているように、受信器から遠く離れて位置する高帯域幅のピアは受信器の近くに位置する低帯域幅のピアに比べて低い順位を有する可能性がある。
【0087】
ネットワーク内のコンテンツを検索している間に、リソース管理フレームワーク(RMF)630(図6を参照されたい)はコンテンツを有するピアの長いリストを戻すことができる。ピア選択アルゴリズムを検索結果の全体のリストに適用できない可能性がある。例えば、提供に従事しているピアまたはアップリンク容量が低いピアまたは地理的なロケーションにおいて遠く離れているピアを放棄することによって初期リストをフィルタリングすることはより効率的である。ピア選択アルゴリズムを実施するためにフィルタリングされたリストから例えば15〜20のピアのセットが使用され、また選択シーケンスはアップリンク容量および地理的なロケーションを基礎とする。ピア選択に必要とされる測定を初期バッファリング時間中に実際のメディアデータを用いて実施することができる。例えば、最初の10秒間に各ピアは供給側の品質を求めるためにメディアファイルの一部を提供することができる。
【表1】
【0088】
ストリーミングセッションに関してどれほど多くの能動的なピアが要求されているかを求めるために、ピア選択モジュールは次式を使用することができる。
【数2】
ここで、目標のストリーミングレート=R0
能動的なピアの数=N
ピアiによって提供されるレートi=R0i
ピアiからの初期ストリーミングレートRi=βR0i(但しβは容量利用度。0<β≦1であり、ピアiは100%の容量利用度以下で動作する)
FECオーバヘッド=α
FECによるパケット損失許容度=α/(1+α)
【0089】
一例として、ストリーミングレートが1.1Mbpsであり、α=0.20FECである場合、要求されるストリーミングレートは1.32Mbpsである。各ピアはアップリンクストリーミング帯域幅R0i=256Kbpsを有するようになる。β=0.8である場合にはRi=248である。したがってN=7であり、ピア選択モジュールは5〜7個の能動的なピアをそれらのピアの出力帯域幅に基づき選択することができる。
【0090】
図6を再び参照し、さらには図8を参照しながら、特定の実施形態によるストリーム管理モジュール6120を説明する。図8はV2P受信器のブロック図を示し、また本発明の1つの実施形態によるストリーム管理モジュールを示す。図8によれば、受信器810はストリーム管理モジュール8120および再生モジュール8130を有する。特定の実施形態によれば、ストリーム管理モジュール8120はストリームモジュール8121、受信データモジュール8122(この実施形態においては受信データ/FECデコードモジュール8122として示されている)、バッファ管理モジュール8123、コネクション監視モジュール8124および動的レート分布モジュール8125を有する。
【0091】
動作時に、ストリームモジュール8121は全ての能動的な供給側との制御コネクションおよびデータコネクションを開閉し、またデータブロックのどの部分をどのデータレートで送信するかを指示する制御パケットを能動的な供給側に送信する。この実施形態においては受信データ/FECデコードモジュール8122として示されている受信データモジュール8122は能動的な供給側からストリーミングデータを受信し、このストリーミングデータをデコーディングし、デコーディングされたストリーミングデータをバッファ管理モジュール8123に転送する。バッファ管理モジュール8123はデコーディングされたストリーミングデータを受信データモジュール8122から受信し、ユーザが一時停止、早送り、巻き戻しを行えるように再生モジュール8130と対話し、またバッファを管理し、さらにはバッファが一杯ではなく、且つ空でないことを保証するために動的レート分布モジュール8125と対話する。コネクション監視モジュール8124は、いずれかのコネクションに輻輳が生じていないか否か、またはいずれかの供給側が故障していないか否かを検出するために能動的な供給側と受信器との間のコネクションを監視し、またネットワークの不安定性およびデバイス故障が生じる場合には動的レート分布モジュール8125と対話する。動的レート分布モジュール8125はバッファ管理モジュール8123およびコネクション監視モジュール8124と対話し、またネットワークの不安定性およびデバイス故障に対処するためにストリーミングレートを能動的な供給側に動的に分布する。
【0092】
ストリームモジュール8121は全ての能動的な供給側との制御コネクションおよびデータコネクションを開閉する。ストリームモジュール8121は、各供給側との1つの制御コネクションを開くことによって能動的なセットにおける全ての供給ピアとの通信を確立し、また理想的には、制御コネクションは信頼性が高いものであることが期待される。例えば、伝送制御プロトコル(TCP)を使用することができる。またストリームモジュール8121は各供給側に受信器とのデータパスの確立に関する制御情報をシグナリングする。またストリームモジュール8121はデータブロックのどの部分がどのデータレートで送信されるかを指示する制御パケットを能動的な供給側に送信する。これは能動的な供給側間でのストリーミングレートの動的なレート分布をなす。制御パケットは送信すべきブロックの小部分およびデータレートを表す。レート分布は動的レート分布モジュール8125に由来する。
【0093】
この実施形態においては受信データ/FECデコードモジュール8122として示されている受信データモジュール8122は能動的な供給側からストリーミングデータを受信し、このストリーミングデータをデコーディングし、デコーディングされたストリーミングデータをバッファ管理モジュール8123に転送する。受信データモジュール8122はストリームモジュール8121によって全ての能動的な供給側からデータを受信することが指示され、また能動的な供給側はこのモジュールとのデータパスを確立する。特定の実施形態によれば、V2Pはデータストリーミングに関してユーザデータグラムプロトコル(UDP)のようなプロトコルを使用することができる。択一的に別の実施形態においては、V2PはUDPを基礎とするあらゆる輻輳制御プロトコル、例えばデータグラム輻輳制御プロトコル(DCCP)などを使用することができる。ストリーミングデータの受信に基づき、受信データモジュール8122はこのストリーミングデータをバッファ管理モジュール8123に引き渡す前にデコーディングを行う。ブロックのデコーディングには、受信した部分またはセグメントからのFECエンコーディングされたブロックの再構築、再構築されたFECエンコーディングされたブロックのFECデコーディング、また使用される特定のビデオエンコーディングスキーマ(例えばMPEG)に応じたFECデコーディングされたブロックのさらなるデコーディングが含まれることを言及しておく。
【0094】
バッファ管理モジュール8123はデコーディングされたストリーミングデータを受信データモジュール8122から受信し、ユーザが一時停止、早送りおよび巻き戻しを行えるよう再生モジュール8130と対話する。バッファ管理モジュール8123はバッファを管理し、またこのバッファが一杯ではなく、且つ空でないことを保証するために動的レート分布モジュール8125と対話する。例えば、ユーザがストリーミングセッションを一時停止するためにボタンを押すと、バッファ管理モジュール8123はストリーミングレートを調整するために動的レート分布モジュール8125と対話する。またバッファ管理モジュールはメディアデータを再生するためにバッファには常にデータが存在することを保証する。例えば、再生は初期バッファリング時間(例えば10秒)または短い宣伝の直後に開始することができる。その後、バッファ管理モジュール8123は目下の再生レートおよびストリーミングレートにより近い将来バッファは空にならないか、またはオーバーフローしないかを周期的に評価する。必要に応じて、動的レート分布モジュール8125によりストリーミングレートを相応に調整することができる。
【0095】
図9は、本発明の1つの実施形態により、動的バッファ管理技術がバッファオーバーフローまたはアンダーフローをどのようにして回避することができるかを表すグラフを示す。このグラフにおいて、B(t)は時間tにおいてバッファに記憶することができる最大累積データを表し、P(t)は時間tにおいて再生器によって消費される累積データを表す。このグラフから見て取れるように、固定ビットレート(CBR)のストリーミングレートはバッファオーバーフローまたはバッファアンダーフローを容易に引き起こす可能性がある。動的バッファ管理アルゴリズムはストリーミングレートを周期的に調整することによってこれらのシナリオを回避する。
【0096】
例えば、固定ビットレート(CBR)のストリーミングレートは、バッファが将来オーバーフローしないこと、もしくは空にならないことを保証することができない。何故ならばネットワーク状態は変化し、またピアがあらゆる時点において故障する可能性があるからである。したがって、複数のパラメータに基づきストリーミングレートを調整する動的バッファ管理技術を使用することができる。このパラメータの例として以下のものが挙げられる:
a)目下のバッファサイズ
b)目下の再生レート
c)目下のストリーミングレート
【0097】
図10は、本発明の1つの実施形態によるバッファ管理スキーマを表すグラフを示す。図示されているように、バッファは3つの部分、すなわち加速ゾーン(0<バッファサイズ<Bmin)、快適ゾーン(Bmin<バッファサイズ<Bmax)、減速ゾーン(バッファサイズ>Bmax)に分割されている。BminおよびBmaxの値はシステムにおける許容バッファサイズに依存する。例えば、システムが30秒のバッファリングを有することができる場合には、Bmin=10秒およびBmax=20秒を選択することができる。ストリーミングレートは目下のバッファサイズならびに、目下のストリーミングレートおよび再生レートを使用して計算されるバッファの変化に基づき調整される。目下のバッファサイズがBmin以下であり、且つバッファサイズの変化が負である場合には、ストリーミングレートが高められる。ストリーミングレートは快適ゾーンにおいては変化しない。バッファサイズがBmaxを上回る場合には、ストリーミングレートが低められる。
【0098】
レートを計算して目下のストリーミングレートを調整するために、バッファ管理モジュール8120はその時点におけるストリーミングレートの指数加重移動平均(EWMA)を使用する。一般的にEWMAは次式のように表される:
Ravg(t)=wR(t)+(1−w)Ravg(t−1)
ここで、0<w<1は目下のその時点におけるサンプルまたは最近の記録を重み付けするための定数である。
【0099】
例えば、バッファ管理モジュールはバッファサイズの各ゾーンに関してwを規定する。バッファが加速ゾーンにおいて動作している場合には、ストリーミングレートを調整するために、その時点におけるストリーミングレートが強調されなければならない。したがってこのゾーンにおいてはwに比較的高い重みが与えられている。バッファが快適ゾーンにおいて動作している場合には、平滑なストリーミングレートを計算するためにwには比較的低い重みが与えられており、これは減速ゾーンにおいてストリーミングレートを調整するために使用することができる。減速ゾーンにおいては、ストリーミングレートをより積極的に減速するためにαに高い重みが与えられている。
【0100】
図8を再び参照すると、コネクション監視モジュール8124は、いずれかのコネクションに輻輳が生じていないか否か、またはいずれかの供給側が故障していないか否かを検出するために能動的な供給側と受信器との間のコネクションを監視し、またネットワークの不安定性およびデバイス故障が生じる場合には動的レート分布モジュール8125と対話する。コネクション監視は、供給側から受信器へのいずれかのデータパスに輻輳が生じていないか否か、またはいずれかのピアが故障していないか否かを検出するための有用なメカニズムである。例えば、受信器が特定の時間枠の間に所定のピアから何のデータも受信しない場合には、ピアがもはや生きていないことが想定される。
【0101】
ネットワーク輻輳の個所を厳密に特定することは比較的困難である。ネットワーク輻輳の個所が既知である場合には、品質適合モジュール(図6の項目6140)は供給側と受信器との間の各コネクションをどのように処理するかを決定することができる。例えば、1つのコネクションしかネットワーク輻輳の影響を受けない場合には、他のコネクションはこの輻輳を克服するためにより高いレートでデータを提供することができる。しかしながら、コネクションの大部分に同時に輻輳が発生している場合には、バックアップ的なピアのセットからピアを付加し、それらのピアからの付加的なストリーミングにより輻輳の効果を緩和させることが必要となる。
【0102】
コネクション監視モジュール8124は輻輳が生じているパスセグメントを識別するためにネットワークトモグラフィ技術を使用することができる。ネットワークトモグラフィの基本的な思想にはパケット「ストライプ」(すなわちバック・ツー・バック検査パケット)の使用が含まれ、このパケット「ストライプ」は目的地におけるストライプ内のパケット損失の相関を計算することによってリンク損失が推測される。損失を推測するために、ストライプと称される一連の検査パケットが1つのノードから0伝送遅延を有する他の2つのノードに送信される。パケットがいずれかの受信器に到達すると、このパケットが分岐点に到達していなければならないことを推測することができる。エンドホストに到達したパケットの数に基づき、全ての内部リンクに関する伝送成功確率を計算することができる。
【0103】
コネクション監視モジュール8124はコネクションを受動的に監視する。すなわち、ストリーミング中に能動的な検査は行われない。コネクション監視モジュール8124はストリーミングデータを使用する。複数の供給側から1つの受信器へのデータが生じるのではなく、むしろ幾つかのネットワークトモグラフィ技術においては1つのソースから複数の受信器へのデータが生じる。
【0104】
受信器が共有パスならびに固有のパスにおけるパケット損失の相関を取得できるようにするために、必要に応じて、適切なストライプのサイズを評価し、また供給側間においてパケットをどのように分割するかについての実験が実施される。供給側から受信器へのパスの特性を評価することもできる。図11は、2つの供給側S1およびS2から1つの受信器Rへの単純なバイナリツリーを示す。供給側はブロックのパケットを送信するために時間と同期されているので、S1およびS2からのパケットが共有パスセグメントk→Rにおいて同様の輻輳を経験する確率が高い。D(D=<D1,D2>)個のパケットのストライプを使用することができ、ここではS1がD1個のパケットを送信し、またS2がD2個のパケットを送信する。RがS1からのストライプの全てのパケットを取得すると、S2→kにおいてパケットが損失しない限り、RはS2からのD2個のパケットを受信する確率が高い。
【0105】
図8を再び参照すると、動的レート分布モジュール8125はバッファ管理モジュール8123およびコネクション監視モジュール8124と対話し、また輻輳およびデバイス故障に起因するネットワークの不安定性に対処するためにストリーミングレートを能動的な供給側に動的に分布する。
【0106】
動的レート分布モジュール8125は目下のストリーミングレートを何時でも変更することができる。ストリームモジュール8121は、新たなレートを規定するために制御信号を各時間枠に各能動的な供給側へ送信するコネクション監視モジュール8124はどのコネクションに輻輳が生じているかを検出し、バッファ管理モジュール8123は目下のストリーミングレートはどのようであるべきかを検出し、また動的レート分布モジュール8125は時間tにおいて各供給側がストリーミングを行うべきレートを検出する。続いて、ストリームモジュール8121は各供給側に制御パケットを送信し、新たなレートおよびファイルセグメントの新たなインデクスで供給側は次の時間枠において送信を行うべきことを通知する。
【0107】
図8を参照しながら、ここでは再生モジュール8130として示されているインタラクティビディ管理モジュールを特定の実施形態にしたがい説明する。再生モジュール8130はインタラクティビティを提供するので、ユーザはストリーミングセッションを一時停止、早送り(FF)および巻き戻し(RW)することができる。以下において詳細に説明するこれらの各イベント中に、再生モジュール6130はこのイベントに基づき適切な動作を実施するバッファ管理モジュール8123に情報を通知する。
【0108】
先ず一時停止に関する制御を説明する。ユーザがストリーミングセッションを一時停止するためにボタンを押すと、バッファ管理モジュール8123は動的レート分布モジュール8125に新たなストリーミングレート、例えば0Kbpsを分布することをシグナリングする。動的レート分布モジュール8125はストリームモジュール8121にストリーミングセッションを一時停止することをシグナリングする。ストリームモジュール8121は制御信号を各能動的な供給側に送信し、ストリーミングセッションが再開されるまで、または一時停止時間が経過するまで、ストリーミングセッションは一時停止される。ストリーミングセッションが一時停止されている間、受信器は能動的な供給側からのいかなる付加的なストリーミングデータも要求しない。ストリーミングセッションが再開されると、ストリームモジュール8121はストリーミングセッションを再開するために制御信号を各能動的な供給側に送信する。一時停止時間が経過すると、ストリーミングセッションは閉じられる。
【0109】
次に早送り(FF)および巻き戻し(RW)に関する制御を説明する。受信器が局所的な記憶装置、例えばハードディスクを有している場合には、RW動作は既に記憶されているコンテンツに基づき実施される。そうでない場合には、RWおよびFFを同様のやり方で実施することができる。複数のアプローチをFF動作に関連付けることができる。1つ目のアプローチはVCRのような平滑なインタラクティビディを提供するために別個のインタラクティブストリームを使用する。しかしながら、各メディアファイルに対して別個のインタラクティブストリームが要求されることになる。2つ目のアプローチは、付加的なストリームを使用せずに探索メカニズムを用いて早送りまたは巻き戻しを達成するソリューションである。
【0110】
殊に、インタラクティブストリームを使用する場合には、FF動作は別個のストリーム(すなわちインタラクティブストリーム)および別個のバッファ(すなわちインタラクティブバッファ)を要求する。巻き戻し動作に関して、インタラクティブストリームは再生ストリームとは逆の順番で形成される。早送りおよび巻き戻しの間に供給側はストリームの1つのサブセットしか送信できず、オリジナルのストリームを送信しないので、別個のインタラクティブストリームが要求される。別個のインタラクティブストリームが使用されなければ、供給側はストリームをデコーディングし、関心のある適切なフレームを送信しなければならなくなる。それらをリアルタイムで達成することは不可能であろう。したがって、この技術は目標のFF速度またはRW速度を達成することができるフレームを有する別個のストリームを使用する。例えば、Xの加速係数を達成するために、再生器はXフレーム以外の1つを要求する。しかしながらMPEG技術においては、Iフレームおよび/またはPフレーム無しではBフレームをデコーディングすることができず、また先行のIフレームまたはPフレーム無しではPフレームをデコーディングすることができない。したがって、Xフレーム以外の1つを送信しても早送りイベントにとっては十分ではない。
【0111】
図12は、ストリーミングセッションの一連のMPEGフレームを示す。加速係数5を得るためには、供給側はI,(P,B,B,P),(I,B,B,P)〜を送信する必要がある。何故ならば、Bフレームはデコーディングのために自身に隣接するフレームを両方とも必要とし、またPフレームは先行のIフレームまたはPフレームを必要とするからである。したがって、ストリームを5倍加速させるためには、フレームの1/5以上が供給側によって送信されなければならない。その結果このプロセスによりFFおよびRW中のストリーミングデータレートは高まる。ところが、DSLベースのネットワークにおけるストリーミングデータレートを高められない可能性がある。このDSLベースのネットワークではダウンリンク速度が通常のストリーミングレートに対してのみ有効であることが多い。
【0112】
FFおよびRW中の比較的低いデータレートを維持するために、特定の実施形態によればインタラクティブストリームを使用することができる。インタラクティブストリームを以下のように生成することができる。オリジナルのビデオマテリアルは圧縮の前にサブサンプリングされなければならない。X倍の早送り速度に関して、各X番目のビデオフレームはMPEGエンコーディングの前に適切なデバイスに記憶されなければならない。例えば4倍の早送り速度を達成するためには、各4番目のビデオフレームが使用される。このコンテンツは通常のやり方でMPEGエンコーディングされ、別個のファイルに記憶される。この方法により動きが非常に滑らかな非常に高品質のFFの視聴が実現されるが、サブサンプリングされた非圧縮のビデオの中間的な記憶が要求される。
【0113】
サブサンプリング前処理および中間的な記憶という付加的な作業を回避するために、特定の実施形態によればMPEG圧縮領域においてFFを達成することができる。各送信器はFF中の要求を処理するために動的にIフレームをトランスコーディングし、Iフレームを1つだけ有するGOP(Group of Pictures)を生成するために、このトランスコーディングされたIフレームをシーケンスヘッダに含ませる。そのようなスキーマを実施するために、各送信器はIフレームをオン・デマンドでトランスコーディングできなければならない。
【0114】
図8を再び参照すると、インタラクティビディを提供するためにバッファ管理モジュール8123は2つのバッファ、すなわち標準的なストリーム用のバッファおよびインタラクティブストリーム用のバッファを維持する必要がある。標準的な再生が行われている間はユーザがFFまたはRWを選択できるようにバッファ管理モジュール8123はIフレームのみをインタラクティブバッファに置き、再生モジュール8130はインタラクティブバッファからデータを即座に受信する。バッファ管理モジュール8123は、ユーザが通常の再生モードに戻るまで再生器にインタラクティブバッファからデータを供給する。ストリームモジュール8121は、この期間中にインタラクティブストリームからのデータを送信するよう各供給側に制御信号を送信するN個のIフレームが既にインタラクティブバッファに存在するので、各供給側は1つのIフレームを送信する。ユーザは1つのIフレームから次のIフレームに早送りすることができる。インタラクティブバッファにデータが存在しない場合には、再生モジュール8130はユーザによるFF/RWを許可せず、通常の再生を再開する。ユーザが通常の再生を再開すると、バッファ管理モジュール8123は標準バッファから再生モジュール8130にデータを供給する。標準バッファが通常の再生のために十分なデータを有していない場合には、標準バッファがフルレートでの再生のために十分なデータを有するまで数秒にわたりサブサンプリングされたデータを再生することができる。
【0115】
特定の実施形態によれば、FF動作およびRW動作をシミュレートするための択一的なアプローチにおいて、特定のインタラクティブストリームを有するという要求を回避するためにファイル探索が使用される。殊に、ユーザがFFまたはRWボタンを押すと、再生モジュール8130はX秒のビデオデータを再生し、次いで加速を達成するためにファイル内の適切な位置へとY秒ジャンプする。全ての供給側はX秒に対応するビデオデータを提供し、次のビデオデータを取り出すためにファイル内をY秒探索する。
【0116】
特定の実施形態によれば、XおよびYの値を設定することによって可変の加速を達成することができ、また加速係数を次式に従い計算することができる:
【数3】
例えば、X=2秒且つY=6秒であれば、加速係数は4である。
【0117】
再生モジュール8130が通常の速度でビデオデータを再生すると、ストリーミングデータ内の一時的な位置がジャンプに起因して前進するが、ユーザは加速係数を認識しない。したがって再生モジュール8130は通常の速度よりも速い速度でビデオデータを再生する。例えばDSLネットワークにおいては加速を行えない可能性があるので、供給側が標準ストリーミングレートでストリーミングデータを送信し続けると、バッファはより高速な再生レートに起因して空になる可能性がある。この問題を解決するために、再生モジュール8130は受信器に局所的に記憶されている短いビデオクリップを再生することができる。短いビデオクリップをストリーミングデータのブロック間のバッファに挿入することができる。例えば、挿入されたビデオクリップはFFまたはRWイベントに基づいた動画化された「>>」または「<<」でよい。そのような短い動画化されたビデオクリップは、システムが幾つかの処理を実行していることを視聴者に知らせることができる。そのようなビデオクリップをストリーミングする必要がないように、ビデオクリップを受信器側において予め生成して記憶することもできる。
【0118】
図13は、一連のビデオデータおよび挿入されたビデオクリップを示す。図示されているように、再生モジュール8130は挿入されたビデオクリップが続く4秒のビデオクリップを再生し、12秒ジャンプし、挿入されたビデオクリップが続く4秒のビデオクリップを再生し、さらに12秒ジャンプし、また4秒のビデオクリップを再生する。再生モジュール8130は通常の速度の2倍の速度でビデオデータおよびビデオクリップを再生する。この実施例において、X=4,Y=12且つ挿入されたビデオクリップの長さがX=4である場合には、加速係数は次式により与えられる。
【数4】
【0119】
上述したようなブロードバンドデータの受信に関してデータストリーミングの品質を改善するために使用される本発明の1つの態様は品質適合を含む(図6に示されているような品質適合モジュール6140を使用し、また図8に示されているようなストリーム管理モジュール8120を参照する)。品質適合は、復元力があり且つ高品質のストリーミングの提供にとって重要な要素である。ストリーミング品質はネットワークの不安定性およびデバイス故障が生じている間に劣化する。両方の問題に対処するために、V2Pは以下のようなメカニズムを使用する:
a)インテリジェントなバッファ管理
b)コネクション監視
c)動的なレート分布
d)動的なFECエンコーディング/デコーディング
e)能動的なピアの選択(N個の能動的なピア)
f)バックアップ的なピアの選択(M個のバックアップ的なピア)
【0120】
最初の2つのメカニズムはエラー状態を検出し、輻輳の現在の箇所を識別するために使用される。残りの4つのメカニズムはネットワークの不安定性およびデバイス故障に対処するために使用される。これらの2つのシナリオを説明する。場合によっては、品質適合モジュール6140はそのような状況に対処するためにストリーミングデータの再供給を能動的な供給側に要求することができる。
【0121】
ネットワークの不安定性に対処するための品質適合プロセスを特定の実施形態にしたがい説明する。インターネットはベストエフォートサービスであり、いずれかのエンド・ツー・エンドパスの待ち時間、損失およびジッタのようなネットワークレイヤメトリクスは時間毎に変化する可能性がある。コネクション監視メカニズムはネットワークの輻輳の現在の箇所を識別することができる。例えば、K個のコネクションには何時でも品質的な劣化が生じるものとする。先ず、品質適合モジュール6140はストリーミングレートの合計が目標のストリーミングレートにまだ達していないか否かを検査する。このような条件が満たされていない場合には、良好なネットワーク状態を有する能動的な供給側が他の能動的な供給側によっては供給されないレートを調整するためにより一層供給するために、ストリーミングレートは再分布される。そのような動的なレート再分布は、能動的な供給側がその完全な容量よりも低いレートでストリーミングを行うように能動的なピアの選択が行われるので可能である。残りの超過容量を、各能動的な供給側からのストリーミングレートの動的な再分布に使用することができる。能動的な供給側が目標のストリーミングレートを提供できない場合、品質適合モジュール6140はピア選択モジュール6110に1つまたは複数のバックアップ的なピアを能動的なセットに付加することを指示することができる。全てのバックアップを付加した後に、能動的な供給側が高パケット損失のために依然として目標のストリーミングレートを提供できない場合は、品質適合モジュール6140はストリーム管理モジュール6120にFECエンコーディング・オーバヘッド比(α)を目下の損失率を基礎として高めることを指示する。例えば、α=0.20であり、且つ目下の損失率が35%である場合、αの新たな値は将来の変更に耐えるために損失比に適合するよう調整される。損失比が暫くして下がると、適合モジュールは相応にαの値を下げる。
【0122】
例として、品質適合モジュール6140は、ネットワークの不安定性に対処するためにストリーミングレートを調整し、バックアップ的なピアを付加し、またエンコーディング・オーバヘッド比αを調整するために使用することができるアルゴリズム(アルゴリズム1)を説明する。図示されているアルゴリズムは、目下のストリーミングレートが目標ターゲットレートR0よりも僅かに高いことを保証するためにδを使用し、さもなければ僅かなネットワーク不安定性を有し、ストリーミング品質は低下することになる。ラプタ符号(Raptor code)が使用される場合、δはラプタデコーディングのために必要とされる余剰データを表す。何故ならば、この符号はデコーディングのために本来のコンテンツよりも5%多いデータを要求するからである。
【0123】
【数5】
【0124】
特定の実施形態によるこのアルゴリズムにおいては、ステップ1において、ストリーム管理モジュール6120のコネクション監視モジュール(例えば図8のコネクション監視モジュール8124)はN個の能動的な供給側を有するN個のコネクションを監視し、また時点tにおいて輻輳が生じているK個のコネクションを識別する。ステップ2においては、目下の合計ストリーミングレート(すなわち全てのRiの和)が少なくともδだけ目標ストリーミングレートR0を上回る場合、すなわち
【数6】
である場合、目下のストリーミングレートは十分なものであるので、品質適合モジュール6140は何もしない。さもなければ、品質適合モジュール6140はステップ3において輻輳が生じていない能動的なセットにおける(N−K)個の「良好な」ピア間でのストリーミングレートの再分布を試みる。
【0125】
これらの(N−K)個の「良好な」ピアはそれらの完全な容量よりも低いレートで最初にストリーミングし、これらの(N−K)個の「良好な」ピアの残りの超過容量を目標のストリーミングレートR0を達成するために使用することができる。すなわち、(N−K)個の各「良好なピア」をその完全な容量R0iまでのレートでストリーミングすることができる。したがって、輻輳が生じているK個のピアに関する目下の合計ストリーミングレート(すなわち、これらのK個のピアに関する全てのRiの和)に(N−K)個の「良好なピア」の完全な容量(すなわち、これらの(N−K)個のピアに関する全てのR0iの和)を足した合計が少なくともδだけ目標のストリーミングレートR0を上回る場合、すなわち、
【数7】
の場合、品質適合モジュール6140はストリーム管理モジュール6120に(例えば、動的レート分布モジュールを介して)、目標ストリーミングレートを達成するために(N−K)個の良好なピアにストリーミングレートを再分布することを指示する。さもなければステップ4において、品質適合モジュールはピア選択モジュール6110に、能動的な供給側の更新された数Nが存在するために、能動的なピアのセットにバックアップ的なピアを付加することを指示する。
【0126】
アルゴリズムはステップ3に戻り、品質適合モジュール6140はストリーム管理モジュール6120に(例えば動的レート分布モジュールを介して)、目標ストリーミングレートを達成するために(N−K)個の良好なピアにストリーミングレートを再分布することを指示する。ステップ4において、利用できるバックアップ的なピアが存在しない場合には、品質適合モジュール6140はネットワークにおけるパケット損失を調整するためにエンコーディング・オーバヘッド比αを調整する。品質適合モジュール6140はまたピア選択モジュール6110に、バックアップ的なピアのセットに付加するための付加的なピアを選択することを指示する。
【0127】
別の態様はデバイス故障に対処するための品質適合プロセスである。殊に特定の実施形態によれば、ストリーミングセッションはN個の能動的なピアで始まり、各ピアはβの容量利用度を有する。V2Pは、ピアのうちの1つ(すなわちSTBのうちの1つ)が故障している場合には、ピアのアップロード容量限界を上回ることなく能動的なセット内の残りのピアにストリーミングレートを即座に再分布できるようにβを選択する。したがって、1つのピアがいずれかの時点に故障すると、ストリーミングレートが残りの能動的な供給側にわたり再分布され、合計ストリーミングレートは目標レートを下回らない。2つまたはそれ以上のピアが同時に故障すると、品質適合モジュールは能動的な供給側にバックアップ的なピアを付加することができる。
【0128】
例として、品質適合モジュールは、デバイス故障に対処するためにストリーミングレートを調整し、バックアップ的なピアを付加し、またエンコーディング・オーバヘッド比αを調整するために使用することができるアルゴリズム(アルゴリズム2)を特定の実施形態にしたがい説明する。K個のデバイス(すなわちSTB)が故障すると、品質適合モジュール6140はストリーム管理モジュール6120に(例えば動的レート分布モジュールを介して)、能動的なセットにおける残りの供給側間でストリーミングレートを再分布することを指示する。品質適合モジュール6140はまたピア選択モジュール6110に、次のデバイス故障に取り組むために能動的な供給側のセットにバックアップ的なピアを付加することを指示する。能動的なセット内の残りの供給側が目標のレートを提供できず、且つネットワークにおいて高い損失が発生していない場合は、品質適合モジュール6140はストリーム管理モジュール6120に、目下の損失率を調整するためにFECエンコーディング・オーバヘッド比αを下げることを指示する。より多くの供給側が必要とされる場合、品質適合モジュール6140はピア選択モジュール6110に、バックアップのセットに付加的な供給側を付加することを指示する。バッファ管理モジュールは典型的に、再生モジュールが利用できるデコーディングされた5〜10秒のデータを維持し、この場合、品質適合モジュール6140は目標ストリーミングレートを達成するために、能動的なセットにより多くのバックアップ的な供給側を付加することができる。
【数8】
【0129】
上述したように、ステップ1においてはコネクション監視モジュールがK個の故障したSTBを識別する。ステップ2においては、能動的なセットにおける残りの供給側の目下の合計ストリーミングレート(すなわち全てのRiの和)が少なくともδだけ目標ストリーミングレートR0を上回る場合、すなわち
【数9】
である場合、目下のストリーミングレートは十分なものであるので、品質適合モジュール6140は何もしない。さもなければ、品質適合モジュール6140はステップ3において故障していない能動的なセットにおける(N−K)個の「良好な」ピア間でのストリーミングレートの再分布を試みる。これらの(N−K)個の「良好な」ピアはそれらの完全な容量よりも低いレートで最初にストリーミングし、これらの(N−K)個の「良好な」ピアの残りの超過容量を目標のストリーミングレートR0を達成するために使用することができる。すなわち、(N−K)個の各「良好なピア」をその完全な容量R0iまでのレートでストリーミングすることができる。したがって、(N−K)個の「良好なピア」の完全な容量(すなわち、これらの(N−K)個のピアに関する全てのR0iの和)が少なくともδだけ目標のストリーミングレートR0を上回る場合、すなわち、
【数10】
の場合、品質適合モジュール6140はストリーム管理モジュール6120に(動的レート分布モジュールを介して)、目標ストリーミングレートを達成するために(N−K)個の良好なピアにストリーミングレートを再分布することを指示する。品質適合モジュール6140はピア選択モジュール6110に、能動的なセットにバックアップ的なピアを付加することを指示する。
【0130】
さもなければステップ4において、品質適合モジュール6140はピア選択モジュール6110に、能動的な供給側の更新された数Nが存在するために、能動的なピアのセットにバックアップ的なピアを付加することを指示する。ステップ4において、利用できるバックアップ的なピアが存在しない場合には、品質適合モジュール6140はネットワークにおけるパケット損失を調整するためにFECエンコーディング・オーバヘッド比αを調整することができる。品質適合モジュール6140はストリーム管理モジュール6120に(例えば動的レート分布モジュールを介して)、目標ストリーミングレートを達成するために能動的なセットにおける(N−K)個の良好なピアにストリーミングレートを再分布することを指示する。品質適合モジュール6140はまたピア選択モジュール6110に、バックアップ的なピアのセットに付加するための付加的なピアを選択することを指示する。
【0131】
図6を再び参照し、特定の実施形態によるコンテンツ検索およびコンテンツ推薦モジュール6150を説明する。コンテンツ検索およびコンテンツ推薦モジュールによりユーザは自身が関心を持つコンテンツを検索することができる。ユーザインタフェース(UI)によりユーザは以下のような電子番組表(EPG)データに基づきコンテンツを検索することができる:
a)タイトル、
b)俳優/女優
c)監督、
d)年、
e)国、
f)ジャンル、
g)賞、
h)スポーツ、TVドラマ、ニュース、コンサートなどのカテゴリ
i)物語における何らかのキーワード
【0132】
参照モジュール6160は、動作の以下の詳細を前提として、ピアに関する情報の取得を容易にする。参照モジュール6160は、STBのリソース情報、例えばCPU、メモリおよびアップストリーム帯域幅を参照するために遠隔のピアに試験を送信する。この試験は、例えばピアが目下アップロードまたはダウンロードを行っているか、もしくはアイドルモードであるかのような状態情報およびピアの信頼性記録の参照でよい。参照モジュール6160はピアのインセンティブ記録を戻すことができ、このインセンティブ記録をピア選択モジュール6110によるピア選択の間の公平性を調べるために使用することができる。
【0133】
データ管理に関して、データ管理モジュールはストリーミングされたデータをハードディスクのような局所的な記憶装置に記憶することができる。例えばUDPを使用して信頼性のないチャネルを介してストリーミングが行われると、セッション中に幾つかのパケットが失われる可能性がある。受信器はFFメカニズムの使用に基づき全てのパケットを有している必要はない。したがってデータ管理モジュール6170は、受信器が将来において供給側となるべく完全なファイルを有するために、ストリーミング後に能動的な供給側と接触し、それらの失われたセグメントをダウンロードすることができる。
【0134】
供給側がどのように動作するかを理解するために、図14はV2Pシステムのブロック図を示し、またさらに本発明の1つの実施形態による送信器(供給側)を示す。図14によれば、V2Pシステム1400は受信器1410、送信器1420、リソース管理フレームワーク(RMF)1430、インセンティブマネージャ1440および電子番組表(EPG)1450を有する。受信器1410はストリーミングデータを受信するために送信器1420と対話する。送信器1420はRMF1430と対話し、V2Pシステムにコンテンツを登録および通知する。送信器1420はインセンティブマネージャ1440と対話し、このインセンティブマネージャ1440はユーザへの課金および適切なエンティティへの報酬の付与に対して責任を有する。送信器1420は電子番組表(EPG)1450と対話し、これによりパーソナルビデオレコーダ(PVR)拡張を使用したコンテンツの記録が可能になる。
【0135】
図14によれば、送信器1420はさらに特定の実施形態にしたがい、登録モジュール14210、ストリーミング管理モジュール14220、FECエンコーディングモジュール14230、リソース監視モジュール14240およびPVR拡張モジュール14250を有する。登録モジュール14210はSTBのリソースおよび統計を登録し、またp2pネットワークにコンテンツを通知する。ストリーミング管理モジュール14220はデータを提供し、また制御信号を受諾するために受信器と通信する。FECエンコーディングモジュール14230はコンテンツアイテムに対応するメディアファイルにおけるブロックをFECエンコーディングする。リソース監視モジュール14240はSTBの目下の状態に基づき要求された新たなストリーミングを受諾または拒否する。またこのリソース監視モジュール14240はストリーミングセッションに寄与した後にインセンティブマネージャ1440に報告を行う。PVR拡張モジュール14250は電子番組表(EPG)1450と対話する。
【0136】
登録モジュール14210はRMF1430を介してp2pネットワークに自身のリソースおよび統計を登録する。またこの登録モジュール14210はp2pネットワークに新たなメディアコンテンツを登録、通知または宣伝する。
【0137】
ストリーミング管理モジュール14220はデータを提供し、また制御信号を受諾するために受信器と通信する。送信器が新たなストリーミング要求を受諾した後に、ストリーミング管理モジュール14220は受信器からの制御コネクションを受諾する。制御コネクションにしたがいストリーミング管理モジュール14220は受信器とのデータコネクションを確立し、例えばハードディスクのような局所的な記憶装置からデータを読み出し、またデータコネクションを介してデータを送信する。データが事前エンコーディングされており、且つ目下のエンコーディングされたコンテンツのFECエンコーディング・オーバヘッド比αが受信器から要求されたαと一致する場合には、ストリーミング管理モジュール14220は単にデータを読み出し、そのデータを受信器に送信する。新たなαを用いてデータをエンコーディングすることが必要である場合には、ストリーミング管理モジュール14220はFECエンコーディングモジュール14230と通信し、FECエンコーディングが実施される。
【0138】
FECエンコーディングモジュール14230はコンテンツアイテムに対応するメディアファイルのブロックをストリーミングのためにFECエンコーディングする。特定の実施形態によれば、V2Pが特定のFECエンコーディング・オーバヘッド比αを用いてメディアデータをエンコーディングするために使用することができる2つの例示的なFEC符号は広く公知のリード・ソロモン(Reed-Solomon)符号およびラプタ符号である。また別の実施形態においては、限定的なフィールドにわたるコーシー行列(Cauchy matrices)を基礎とし、また算術演算の代わりにXORを使用するリード・ソロモン消去符号(Reed-Solomon erasure code)は、慣例のリード・ソロモン符号を上回る高速なエンコーディングおよびデコーディングを達成するために使用することができる。
【0139】
表2は、特定の実施形態による、変更されたリード・ソロモン消去符号を使用する例示なエンコーディング時間およびデコーディング時間を示す。例えば、映画ファイルを1.1Mbpsで1秒のブロックまたは0.5秒のブロックに分割し、20%のパケット損失が許容されるようエンコーディングされる。エンコーディング時間およびデコーディング時間には典型的に、2GBメモリを備えた2.4GHzのLinuxマシンにおいてリード・ソロモン消去符号が実行されている。
【0140】
表2に示されているように、エンコーディングはデコーディングよりも時間を要する。さらには、エンコーディング時間およびデコーディング時間はブロックの長さに関して線形ではない。ブロックサイズが過度に大きい場合、受信器はブロックをデコーディングする前にブロックの全てのパケットを受信するために長時間待機しなければならない。ブロックサイズが過度に小さい場合、1つのコネクションにおける突発的なパケット損失により大量のパケットが落ち、他のコネクションからの残りのパケットはブロックを回復するのに十分なデータを有さなくなる。1Mbpsでのストリーミングに関しては、1秒のブロックサイズが典型的である。400MHz以上で実行するプロセッサおよび128MB以上のメモリを有するSTBは、ネットワークの不安定性およびデバイス故障を調整するためにリード・ソロモン符号を使用するオン・デマンドエンコーディングを支援することができる。
【表2】
【0141】
図14を参照すると、リソース監視モジュール14240は新たなストリーミング要求を受諾または拒否するかを決定するためにSTBの局所的なリソースおよび状態を監視する。また、PVR拡張モジュール14250は電子番組表(EPG)1450と対話し、イベントの記録の管理を調整する。
【0142】
図15は、V2Pシステムの性能を評価するための例示的なセットアップを示す。図15によれば、V2Pシステム1500は受信器1510、送信器1520、インターネットサービスプロバイダ(ISP)1580aおよび1580b(以下ではISP1580と称する)およびインターネット1590を包含する。受信器1510および送信器1520はそれぞれ受信器モジュールと送信器モジュールの両方を有するようにコンフィギュレーションすることができるので、これらは送信器としても受信器としても動作することができる。ここではパーソナルコンピュータとして示されている各受信器1510および送信器1520を2つの異なるISP1580を介してインターネット1590に接続することができる。送信器のセットを両方のISP1580から選択することができるので、ストリーミングデータはインターネット1590を介して流れ、また受信器1510はネットワークの不安定性を経験する。ストリーミングセッション中に、デバイス故障をシミュレートするために送信器1520のうちの1つまたは複数の電源を落とすことができる。
【0143】
特定の実施形態によれば、V2Pシステムを非対称ディジタル加入者線(ADSL)アクセスネットワークにおいて使用することができ、このネットワークにおいては各送信器が制限的なアップリンク容量を有し、またマルチ送信器ソリューションは送信器のセットからの全体のストリーミングレートを合計するために必要とされる。V2Pをより高い帯域幅のアクセスネットワーク、例えば20Mbps〜100Mbpsの範囲のアップリンク帯域幅を有するFTTxネットワークおよびxDSLネットワークにおいて使用するために実施することができる。特定の実施形態によれば、その種の環境においてV2Pは1.5Mbpsのストリーミング(MPEG−4品質のビデオストリームに相当)、それどころか3〜5Mbpsのストリーミング(MPEG−2品質のビデオストリームに相当)を送信するために複数の送信器を必要としない。1つの送信器が全体のストリーミングレートを容易に提供することができる。それにもかかわらず、特定の実施形態によれば、ネットワークの不安定性およびピアの故障が発生している場合には、復元力のあるストリーミングを提供するために、各ストリーミングセッションに関してバックアップ的なピアを使用することができる。このシナリオにおいては、V2Pの(N+M)個のストリーミングモデルが(1+M)になり、ストリーミングセッションは1つの能動的な供給側およびM個のバックアップ的な供給側を使用する。各ピアが高い利用可能なアップリンク帯域幅を有するので、ストリーミングセッションはN個の能動的な供給側をもはや要求しない。それにもかかわらず、復元力のあるストリーミングを提供するためにM個のバックアップが必要とされる可能性はある。各送信器は複数のストリーミングセッションを提供するために十分な容量を有しているので、1つのセッションに割り当てられたバックアップ的な供給側を容易に他のセッションの能動的な供給側にすることができる。
【0144】
図16に示されている特定の実施形態によれば、1つ以上のストリームを同時に提供するために送信器は十分なアップリンク帯域幅を有しているので、V2Pは複数のビデオストリームを並行して提供することができる。1つの送信器は複数のストリーミングセッションに複数のビデオを提供することができる。送信器はまた複数のストリーミングセッションにビデオの同一のコピーを提供することができる。このことは希少なビデオが多くの視聴者によって要求される場合には有効である。1つの供給側によって支援することができる並行したビデオストリームの数はV2Pによっては制限されないが、その代わりにSTBのハードウェアI/O処理能力および利用可能なアップストリーム帯域幅によって制限される。高い帯域幅の環境でのV2Pの実施は以下のような幾つかの利点を有する:
a)1つの能動的な供給側および2つのバックアップがストリーミングセッションに必要とされる;したがってより多くのストリーミングセッションを支援することができる;
b)コミュニティが利用できる特定のビデオのコピーの数は1つの供給側から提供することができる並行したストリームの数だけ増加される。このことは、多数の加入者によって記録されなかったビデオにとって殊に有効である;
c)複数のビデオストリームが提供される場合であっても、同一の復元力能力をV2Pによって保証することができる。
【0145】
したがって、V2Pは種々の同種のネットワークおよび異種のネットワークの環境において有用であることが分かった。
【0146】
図16は、本発明の1つの実施形態による、高帯域幅の環境において実施されているVoD・ツー・ピア(V2P)システムを示す。図16によれば、V2Pシステム1600は受信器1610a,1610bおよび1610c(以下では受信器1610と称する)、送信器1620a,1620bおよび1620c(以下では送信器1620と称する)およびリソース管理フレームワーク(RMF)1630を有する。ここではSTBとして示されている受信器1610は送信器1620aからのストリーミングメディアを受信するピアを受領している。ここではSTBとして示されている送信器1620は送信側のピアであるか、ストリーミングメディアの供給側である。受信器1610のいずれか1つは時には送信側のピアとしても動作できることを言及しておく。同様に、送信器1620のいずれかは時には受信側のピアとして動作することもできる。リソース管理フレームワーク(RMF)1630はサービスプロバイダによって管理される管理インフラストラクチャである。サービスプロバイダは受信器1610と送信器1620との間の制御コネクションおよびデータコネクションを管理し、要求されたメディアのオン・デマンドのストリーミングを実施する。またRMF1630により受信器1610は、ブロードキャストから記録した、または送信器から記録した、または送信器1620にダウンロードおよび記録されたストリーミング可能なコンテンツ、例えばメディアファイルについてV2Pシステム1600を検索することができる。またRMF1630により受信器1610はコンテンツ推薦を受信することができる。
【0147】
高帯域幅ネットワーク環境におけるストリーミングセッションによって要求される完全なストリーミングレートを提供するためには1つの送信器で十分であったとしても、(N+M)個の能動的な供給側およびバックアップ的な供給側を基礎とするストリーミングモデルは、(1+M)個の能動的な供給側およびバックアップ的な供給側に比べて全体のシステム利用度を高めることができる。(N+M)個のストリーミングモデルを使用することにより、各供給側は全てのストリーミングレートを提供できる場合であってもその一部を提供する。以下にはシステム利用度の評価を説明する。
【0148】
例えば:
コミュニティサイズ(ピアの数)=C
乗算係数(各ピアが供給できるストリームの数)=γ
各ストリーミングセッションに関する能動的な送信器の数=N
各ストリーミングセッションに関するバックアップの数=M
ストリーミングレート=R
各ピアのアップリンク容量=c
と仮定し、考えられる並行したストリーミングセッションの数をUとすると以下の関係が得られる。
【数11】
(1+M)モデルにおいて:
C=1200,N=1,M=2,R=2Mbps,γ=5とすると、
U=5(1200/(1+2))=2000
【0149】
(N+M)モデルにおいて:
C=1200,N=4,M=2,R=2,γ=20(各ピアがストリームの1/4を供給するので、γ=4*5=20)とすると、
U=20(1200/(4+2))=4000
【0150】
分析的なモデリングは(N+M)モデルが高帯域幅環境における(1+M)モデルよりも良好なリソース利用度を有することを表している。(N+M)または(1+M)のような静的なソリューションを使用する代わりに、適合的なメカニズムを使用することができる。例えば、V2Pが特定のリソースの十分なコピー(すなわち特定のビデオ)を有する場合には、良好なシステム利用度に関して(N+M)個ストリーミングモデルを有利に使用することができる。他方では、V2Pシステムが特定のリソースのコピーを僅かしか有していない場合には、(1+M)モデルを使用するストリーミングセッションを提供することができる。
【0151】
システムの最大利用度を以下のように推定することができる。バックアップはネットワークの不安定性が生じている間、またはピア故障中に供給側を移行している間にのみデータの小部分を提供するので、各ピアはバックアップセッションのために自身の容量を確保する代わりに、能動的なセッションのために自身の容量を使用することができる。したがって、最大利用度Uは以下の関係によって表される:
【数12】
上記の例に関して、(1+M)モデルまたは(N+M)モデルの両方にとっての最大システム利用度Uは6000である。
【0152】
V2Pシステムは低帯域幅ネットワーク環境および高帯域幅ネットワーク環境の同種のコミュニティにおいてより一般的に実施することができる。特定の実施形態によれば、送信器が複数のストリーミングセッションに寄与するための十分なリソースを有している場合にのみ、V2Pは所定の送信器を一度以上使用することができる。さもなければ、各送信器はいずれの所定の時点に1つのストリーミングセッションにおいてのみ使用される。図17は、拡張された送信器アーキテクチャを示し、このアーキテクチャでは特定の実施形態によれば、1つの送信器は複数の受信器にストリームを提供することができる。各ストリームに関して、送信器は1つのストリーム管理スレッドを開く。ストリーム管理モジュールの各インスタンスは受信器との通信に関して責任を有し、また受信器によって送信された制御信号に基づき動作する。ストリーム管理モジュールの各インスタンスはまた受信器へのストリーミングビデオの提供に関して責任を有する。したがって、V2Pは高帯域幅環境において複数のサーバ状ストリーミングセッションを支援することができる。一般化されたV2Pは、複数のソースを使用するp2pネットワーク環境の利点も、一人のユーザから複数のストリーミングセッションを供給することによるサーバ状環境の利点も引き継ぐ。
【0153】
この一般化されたマルチソース環境においては、送信器が自身の利用可能なリソースに基づき、可能な限り多くのストリーミングセッションに寄与することができる。並行するストリームV2Pの数を以下のような種々の因子に依存して支援することができる:
a)要求されたコンテンツアイテムを有するユーザの数
b)各ユーザのアップリンク帯域幅
c)所望のストリーミング品質
例えば、Cl低帯域幅ピアおよびCh高帯域幅ピアのコミュニティのためのV2Pシステムは、γCh/(N+M)+Cl/(N+M)までの高品質ストリーミングセッションを支援することができ、ここでγ≧1はどれほど多くのストリームに供給側が寄与することができるかを表す乗算係数である。低帯域幅環境においてはγ=1mであるが、高帯域幅環境においてはγ≒5以上である。
【0154】
図17はV2Pシステムの1つの実施形態のブロック図を示し、またさらに本発明の1つの実施形態による送信器を示す。図17によれば、V2Pシステム1700は受信器1710、送信器1720、リソース管理フレームワーク(RMF)1730、インセンティブマネージャ1740および電子番組表(EPG)1750を有する。受信器1710はストリーミングデータを受信するために送信器1720と対話する。送信器1720はRMF1730と対話し、V2Pシステムにコンテンツを登録および通知する。送信器1720はインセンティブマネージャ1740と対話し、このインセンティブマネージャ1740はユーザへの課金および適切なエンティティへの報酬の付与に対して責任を有する。送信器1720は電子番組表(EPG)1750と対話し、これによりパーソナルビデオレコーダ(PVR)拡張を使用したコンテンツの記録が可能になる。
【0155】
図17によれば、送信器1720はさらに登録モジュール17210、ストリーミング管理モジュール17220、FECエンコーディングモジュール17230、リソース監視モジュール17240およびPVR拡張モジュール17250を有する。登録モジュール17210はSTBのリソースおよび統計を登録し、またp2pネットワークにコンテンツを通知する。ストリーミング管理モジュール17220の各々はデータを提供し、また制御信号を受諾するために受信器と通信する。FECエンコーディングモジュール17230はコンテンツアイテムに対応するメディアファイルにおけるブロックをエンコーディングする。リソース監視モジュール17240はSTBの目下の状態に基づき要求された新たなストリーミングを受諾または拒否する。またこのリソース監視モジュール17240はストリーミングセッションに寄与した後にンティブマネージャ1740に報告を行う。また、PVR拡張モジュール17250は電子番組表(EPG)1750と対話し、イベントの記録の管理を調整する。
【0156】
図18は、ロングテールを表すグラフを示す。広範な視聴行動を予測するために統計的なサンプリングを使用することができる。例えば、図18はブロードキャスト番組の人気からどのようにロングテールが観測されるかを示す。
【0157】
V2P配置の範囲をモデリングおよび理解するために考慮する変数が多数存在する。例えば、多くの番組を記録できるような範囲を決定するために所定のコミュニティサイズによってどれほど多くの番組が記録されるか、各送信器によってどれほど多くのストリームを供給することができるか、どれほど多くの並行するストリームを供給することができるか、どれほど多くの累積ストリームをネットワークにおいて供給することができるか、どれほど昔までV2Pシステムはコンテンツをアーカイブすることができるか、またどれほどの大きいディスクを各STBは有しているべきかを評価する必要がある。例えば1つの評価として、加入者が視聴しようとするブロードキャストコンテンツの25%を記録することが考えられる。例えばTV番組のニールセン視聴率のような他のデータを、特定の番組を試聴する所定のコミュニティサイズにおける人気のパーセンテージを識別するために使用することができる。例えば、上位500のTV番組のための有効範囲を提供するV2Pシステムを以下のようにモデリングすることができる:
コミュニティのサイズ=C(各ユーザはPVRを有する);
番組iの人気=pi;且つ
番組を試聴するユーザが記録する確率=ri;
とすると、コミュニティにおいて番組iが記録される確率xi=piri
また、
コミュニティにおいて番組iに関して記録されるコピーの平均数=Cpiri
【0158】
以下のシナリオが考慮される:
1.DSLネットワークを介する標準画質(Standard Definition:SD)品質ストリーミング(N=3,M=2)
2.DSLネットワークを介する準DVD品質ストリーミング(N=5,M=2)
3.ファイバネットワークを介する準DVDまたはDVD品質ストリーミング(N=1,M=2)
【0159】
アップストリーム帯域幅が制限されており、且つ単一の受信器にストリーミグされるべきビデオの品質が正規の標準画質(SD)TVであるDSLネットワークに関して、能動的な送信器のセットは最大で3つ要求され、またバックアップ的な送信器のセットは最大で2つ要求される。
【0160】
図19Aは、3つの異なるコミュニティサイズに関して何らかの所定の番組を供給できる、並行するストリームの数を表すグラフを示す。例えば、50,000世帯のコミュニティにおいては、V2Pは上位にランキングされている番組の375の並行するストリームを支援することができる。
【0161】
図19Bは、所定のコミュニティサイズに関してV2Pによって供給することができるストリームの最大数または累積数を表すグラフを示す。例えば、V2Pは50,000のコミュニティサイズに関して24,000の並行するストリームを供給することができる。
【0162】
アップストリーム帯域幅が制限されており、且つ単一の受信器にストリーミグされるべきビデオの品質が準DVDであるDSLネットワークに関して、能動的な送信器のセットは最大で5つ要求され、またバックアップ的な送信器のセットは最大で2つ要求される。
【0163】
図20Aは、3つの異なるコミュニティサイズに関して何らかの所定の番組を供給できる、並行するストリームの数を表すグラフを示す。例えば、50,000世帯のコミュニティにおいては、V2Pは上位にランキングされている番組の200の並行するストリームを支援することができる。
【0164】
図20Bは、所定のコミュニティサイズに関してV2Pによって供給することができるストリームの最大数または累積数を表すグラフを示す。例えば、V2Pは50,000のコミュニティサイズに関して17,000の並行するストリームを供給することができる。
【0165】
アップストリーム帯域幅が100Mbpsであり、且つ5つの受信器にストリーミグされるべきビデオの品質が準DVDであるファイバネットワークに関して、能動的な送信器のセットは最大で1つ要求され、またバックアップ的な送信器のセットは最大で2つ要求される。
【0166】
図21Aは、特定の実施形態による、3つの異なるコミュニティサイズに関して何らかの所定の番組を供給できる、並行するストリームの数を表すグラフを示す。例えば、20,000世帯のコミュニティにおいては、V2Pは上位にランキングされている番組の925の並行するストリームを支援することができる。
【0167】
図21Bは、所定のコミュニティサイズに関してV2Pによって供給することができるストリームの最大数または累積数を表すグラフを示す。例えば、V2Pは20,000のコミュニティサイズに関して80,000の並行するストリームを供給することができる。
【0168】
図21Bに示されているように、V2Pはコミュニティのサイズを上回る総数の並行するストリームを供給することができ、これにより単一の世帯内の複数のTVへのストリーミングを支援することができる。またこのことは同種のネットワークを支援することができる。例えば、コミュニティはPVR機能を備えたSTBまたはPVR機能を備えていないSTBを含んでいる可能性がある。PVR機能を備えていないSTBはビデオストリームを受信することしかできず、ビデオストリームをネットワークに供給することはできない。また、コミュニティはFFTXまたはDSLアクセスを備えたSTBを含んでいる可能性がある。
【0169】
特定の実施形態によれば、V2Pによって提供された保存能力のスケールを検出するために多数のパラメータが要因として考慮されなければならない。特定の実施形態に関するこれらのパラメータのうちの幾つかのパラメータおよび基本的な仮定条件の概略を以下に述べる。STBディスクサイズ:
1Gb=MPEG2SDビデオで1時間まで
1/2Gb=MPEG4準DVDビデオで1時間まで
1/3Gb=MPEG4SDビデオで1時間まで
【0170】
1日当たりの使用頻度:
PVRを有する加入者は1日5時間までTVを見ており、そのうちの25%(1.25時間まで)が記録される。
【0171】
したがって、保存期間に関して要求されるSTBディスクサイズが以下の式を用いて近似的に求められる:
STBディスクサイズ=月×30×1.25
STBディスクサイズ=月×37.5
【0172】
よって3ヶ月の保存に関して要求されるディスクサイズは以下の通りである:
→STBディスクサイズ 〜120Gb(MPEG2SD)
→STBディスクサイズ 〜60Gb(MPEG4準DVD)
→STBディスクサイズ 〜40Gb(MPEG4SD)
図22は、特定の実施形態による、V2Pシステムの保存の側面を表すグラフを示す。例えば、図22によれば、V2PシステムはコミュニティサイズM(ただしM=2000)に関して最高でNのレートの番組の完全な有効範囲を有することができる。
【0173】
V2Pは複数ソースのビデオストリーミング技術を使用する。特定の実施形態によれば、本質的な前提条件は、ソースをその都度送信することによってストリーミングされるべきビデオファイルがエンコーディングされたフォーマット、ビットレートおよびビデオの開始フレームに関して正確に同一であるということである。
【0174】
V2Pの1つの考えられる実施形態はSTB/PVRデバイスのp2pネットワークの範囲内である。STB/PVRデバイスの所有者は、記録しようとする番組の選択に関して種々のメカニズムを有する。例えば、1つのメカニズムは電子番組表(EPG)を介するものである。
【0175】
STBのシステムクロックをサービスプロバイダのクロックに周期的に再同期させることができるので、このSTBのクロックは事前に定められた許容範囲、例えば数秒の範囲にとどまる。この同期により、STB/PVRデバイスはブロードキャスト番組を記録するために適切にスケジューリングされることが保証される。このクロック差の明白な結果は、種々のSTB/PVRデバイス全てが正確に同時刻にブロードキャスト番組の記録を開始できず、したがって同じ開始フレームから記録を開始できないということである。したがって、V2Pが複数のSTB/PVRデバイスから記録された番組をストリーミングすることができるようになる前には、メカニズムはビデオファイル内の共通の開始フレームを識別するために必要とされる。
【0176】
図23は、本発明の1つの実施形態による、共通のビデオフレームを識別するための方法を説明するフローチャートである。ストリーミングセッションからのストリーミングビデオデータの受信に先行して、ストリーミングビデオデータを供給することになる供給側のセットを受信器は取得することができる。各供給側は、特定のコンテンツアイテム、例えばブロードキャスト番組に対応するビデオファイルの個々のコピーからストリーミングビデオデータを供給する。
【0177】
このシーケンスにおいては、ステップ2310において受信器が時間窓を規定する。この時間窓は例えばブロードキャスト番組の開始時間を中心にして、事前に定められた同期許容範囲だけ時間的に前後に拡張された期間でよい。サービスプロバイダのネットワークに接続されているクライアントデバイス、例えばSTBに関するクロックを数秒で同期させることができるので、典型的な同期許容範囲は3〜5秒でよい。
【0178】
ステップ2320においては、受信器が各供給側から、関連する所定の時間窓におけるビデオファイル内に現われる基準ビデオフレームのセットに対応する基準オブジェクトのセットを受信する。例えば、MPEGコーディングされたビデオファイルのコンテクストにおいては、基準ビデオフレームの各セットは時間窓におけるビデオファイルの個々の各コピー内に現われる全てのIフレームに対応することができる。各基準オブジェクトは基準ビデオフレームのセット内の各ビデオフレームに含まれている情報の全てまたは一部を表すことができる。例えば各基準オブジェクトは、基準ビデオフレームのセット内の各ビデオフレームに含まれている情報の全てまたは一部を使用して、公知のハッシング技術を用いて計算されたハッシュ値でよい。ハッシュ値を、ストリーミングセッションの発生に先行して供給側によって、前もって計算することができる。
【0179】
ステップ2330においては、受信器が全ての供給側から受信した基準オブジェクトのセットを比較し、受信した基準オブジェクトの全てのセットに共通する共通の基準オブジェクトが識別される。ステップ2340においては、受信器がステップ2340において識別された共通の基準オブジェクトに対応するビデオフレームに開始フレームをセットする。
【0180】
例えば、受信器はサービスプロバイダのSTB間でのクロックの同期許容範囲に関連する時間窓を規定する。クロックは典型的には数秒の許容範囲、例えば3〜5秒の範囲と同期される。電子番組表(EPG)を用いて、供給側は番組の開始時間を発見し、共通の始点を発見するためにどれほど戻って、またどれほど進んでビデオファイル内を見るかを求めるために同期許容範囲を使用する。時間窓は例えばブロードキャストの開始時間を中心にして、期許容範囲だけ時間的に前後に拡張された期間でよい。供給側は、時間窓におけるビデオファイル内に現われる基準ビデオフレームのセットに対応する基準オブジェクトを生成する。例えば、MPEGコーディングされたビデオストリーム(MPEG2およびMPEG4を含む)のコンテクストにおいては、各GOP(Group of Picture)は他のGOPに依存しない。供給側は、Iフレームである各GOPの開始を識別することができる。時間窓におけるビデオファイルの各供給側のコピー内に現われるIフレームが比較のために必要とされる。送信器がIフレームを受信器に送信する場合、この量のデータを短時間で送信することは技術的に不可能である。各供給側はIフレームのハッシュ値を計算し、このハッシュ値を受信器に送信することができる。全てのIフレームのハッシュ値を計算する代わりに、各Iフレームからの部分的なデータを用いてこのアルゴリズムを継続することができる。さらには、受信器からの要求に基づきハッシュ値を提供できるようにするために、それらのハッシュ値をオフラインで計算することができる。受信器がハッシュ値のセットを受信すると、受信器はそれらのハッシュ値を容易に比較することができ、またこの供給側のセット間でビデオファイルの始点を表す共通のIフレームを発見することができる。
【0181】
図23に示されている方法は、番組の正確な開始フレームの選択を保証するものではない。しかしながら、この方法はSTBの同期許容範囲に相対的な番組の開始に近い開始フレームを選択する。特定の実施形態によれば、このアプローチの利点は分散型のソリューションであるということと、開始フレームを求めるためにビデオシーン分析が要求されないということである。
【0182】
本明細書においては、STBによって形成されるp2pネットワークのために設計されている、提案されたビデオストリーミングシステムV2Pの構成要素を種々の実施形態にしたがい説明した。特定の実施形態によれば、インテリジェントなピア選択、動的なバッファ管理、トモグラフィを基礎とするコネクション監視およびフォワード・エラー・コレクションコードなどの技術を使用して、V2Pはアップリンク帯域幅の制約を解消し、ネットワークの不安定性およびデバイス故障に対する復元力を達成することができる。特定の実施形態によれば、V2Pは多対一(many-to-one)のビデオストリーミングにおける一時停止、早送り、巻き戻しのようなインタラクティブな特徴をもたらす技術を提供する。V2Pはビデオストリーミングを光ファイバネットワークにおいて提供するよう拡張される。特定の実施形態によれば、光ファイバネットワークおよびDSLネットワークの両方におけるリソース供給に関する詳細な分析モデルも提供される。特定の実施形態によるアルゴリズムは異なるユーザによって記録された全てのビデオコンテンツを同期するためにも提供され、V2Pは多対一のストリーミングモデルを使用してストリーミングを行うことができる。
【0183】
要約すれば、種々の実施形態による本発明は、非対称的な帯域幅特性、また場合によっては信頼性が高くないコネクションを有する同種のピア・ツー・ピアネットワークにおいて、能動的な供給側およびバックアップ的な供給側を含む複数のソースを使用する高品質且つ復元力のあるビデオストリーミングを行う。種々の実施形態によれば、本発明は、インテリジェントなピア選択、ネットワークトモグラフィを基礎とするコネクション監視、動的なバッファ管理、動的なレート分布および動的なFECエンコーディングならびにデコーディングを含む複数のメカニズムを使用して、高品質且つ復元力のあるストリーミングを達成する。また本発明は一時停止、早送りおよび巻き戻しのようなインタラクティブな再生制御を効果的にシミュレートする。
【0184】
本発明を有利な実施形態に関連させて説明したが、当業者であれば本発明の精神および範囲を逸脱することなく多数の変更および修正を行えることは明らかであり、したがってそのような変更および修正が本発明の範囲に含まれるべきことを意図するために、本発明は上述の方法論および構成の正確な詳細に制限されるものではない。
【技術分野】
【0001】
本発明は、ストリーミングビデオデータの早送り再生または巻き戻し再生をシミュレートする方法に関する。
【0002】
著作権
本願明細書の開示内容の一部は著作権保護を目的とする資料を含む。著作権の所有者は、特許商標庁に申請または記録されている限りにおいて、特許明細書またはその開示のいずれかによるファクシミリの複製に対しては異議を申し立てない。しかしながらそれ以外に関しては全ての所有権は完全に保有される。
【0003】
関連出願の相互参照
本願は、いずれの発明の名称も"A Multi-Source and Resilient Video Streaming System for Peer-to-Peer Networks"であり、また本願と発明者が同一である、2005年8月12日付で出願されたUS仮出願60/708,020(整理番号2005P14442US)および2005年12月12日付で出願されたUS仮出願60/749,730(整理番号2005P22668US)の利益を主張するものであり、また参照によりそれらを本願の一部とする。
【背景技術】
【0004】
セットトップボックス(STB)は、テレビ受像機がTV番組の再生および記録のようなサービスに関してサービスプロバイダネットワークへのユーザインタフェースとなることを可能にするデバイスである。STBのパーソナルビデオレコーダ(PVR)機能を使用することにより、ユーザは放送されたコンテンツを後で視聴するために記録することができる。
【0005】
ビデオ・オン・デマンド(VoD)システムにより、ユーザは特定のTV番組または他のビデオコンテンツの再生、また場合によってはSTBを使用したそれらの記録を要求することができる。典型的なVoDシステムにおいては、ユーザはSTBを使用して集中型のサービスプロバイダのネットワークに接続することができ、またサービスプロバイダによって提供された利用可能なコンテンツのセレクションを検索するために電子番組表(EPG)を使用し、視聴のために番組を選択することができる。ビデオデータは典型的には、ストリーミングデータとしてサービスプロバイダのネットワークを介してユーザのSTBへと伝送される。
【0006】
また一般的に、ピア・ツー・ピアネットワークによりユーザは同一のネットワークプロトコルおよびソフトウェアを共有し、ユーザを相互に接続することができ、またユーザそれぞれのリソースに直接的にアクセスすることができる。例えば、サービスプロバイダはピア・ツー・ピアネットワークを提供し、コンピュータユーザは自身のコンピュータをそのネットワークに接続し、ユーザそれぞれのリソース、例えばディジタルコンテンツファイルに直接的にアクセスすることができる。サービスプロバイダはピア・ツー・ピアネットワークを提供し、他のデバイス、例えばSTBのユーザは自身のデバイスをそのネットワークに接続し、ビデオコンテンツおよびTV番組が記憶されているユーザそれぞれのリソースに直接的にアクセスすることができる。加入者コミュニティピア・ツー・ピアネットワークにより加入者のコミュニティは相互に直接的にリソースにアクセスすることができる。ユーザは1つまたは複数のピアからデータを典型的にはストリーミングデータとして受信することにより、データをダウンロードすることができる。
【0007】
サービスプロバイダのネットワークの恒常的に増加している帯域幅および復元力のある要求は1つの挑戦であるが、慣例のストリーミングソリューションではこれらの要求を維持ですることはできない。図1に示されているような現在のVoDソリューションは典型的には、映画タイトルの簡素なセレクションを提供し、期間限定で、例えば24時間の間、プレミアムコンテンツのみをキャッシュすることができる。しかしながら、VoDシステムの加入者が見たいコンテンツを選択することができ、またコンテンツを見たいときにそのコンテンツを選択できたならば(すなわちオン・デマンド)、VoDアプローチはより頻繁に使用されることになるであろう。これにより顧客満足度は高まり、またサービスプロバイダに関しては収入が増え、チャーンが減ることになる。
【発明の概要】
【発明が解決しようとする課題】
【0008】
本発明の課題は、顧客満足度を高めるための、ストリーミングビデオデータの早送り再生または巻き戻し再生をシミュレートする方法を提供することである。
【課題を解決するための手段】
【0009】
この課題は、ストリーミングビデオデータの早送り再生または巻き戻し再生をシミュレートする方法が、ストリーミングビデオデータをストリーミングレートで受信するステップを有し、受信したストリーミングビデオデータを後に通常速度に対応する再生レートで再生するためにバッファに記憶するステップを有し、記憶されているストリーミングビデオデータを通常速度よりも速い速度でバッファから再生するステップを有し、ストリーミングレートが再生レートよりも低いアンダーフロー状態についてバッファを監視するステップを有し、アンダーフロー状態の検出に基づき、記憶されているストリーミングビデオデータ間におけるバッファに所定のビデオクリップを挿入するステップを有することによって解決される。
【0010】
また、ストリーミングビデオデータの早送り再生または巻き戻し再生をシミュレートする方法が、ストリーミングレートでビデオファイルからストリーミングビデオデータを受信するステップを有し、通常の視聴速度に対応する通常の再生レートで後に再生するために、受信したストリーミングビデオデータをバッファに記憶するステップを有し、スピードアップされた視聴速度に対応するスピードアップされた再生レートでの早送り再生のための命令を受信するステップを有し、ビデオファイルにおけるジャンプポイントから始まるストリーミングビデオデータを受信し、スピードアップされた再生レートでの再生をシミュレートするために、記憶されているストリーミングビデオデータをバッファから通常の再生速度よりも速い再生レートで再生するステップを有することによって解決される。
【0011】
殊にVoDシステムを拡大するために、本発明はSTB間のピア・ツー・ピア(p2p)ネットワークに関する。各STBは特定の実施形態によればネットワークのノードである。さらには、本発明の特定の実施形態はVoD・ツー・ピア(V2P)と称されるマルチソースストリーミング技術に関し、このマルチソースストリーミング技術によりサービスプロバイダのネットワーク内のあらゆるピアSTBはネットワーク内の他のSTBからビデオコンテンツを取得し視聴することができる。したがって本発明によるその種のV2Pネットワークは事実上加入者コミュニティのためのVoDシステムとなり、このVoDシステムにおいてはいずれのメンバーも他のいずれかのメンバーによってダウンロードおよび/または記録されたコンテンツを取得し視聴することができる。
【0012】
典型的には、加入者コミュニティはSTBのセットを含んでいるので、V2PはSTBからのコンテンツのオン・デマンドの視聴を可能にするマルチソースビデオストリーミングシステムである。本発明の原理により設計されているV2Pシステムのアーキテクチャをこのアーキテクチャの各構成要素の説明も合わせて説明する。そのようなV2Pシステムは、復元力があり(resilient)且つ高品質のビデオストリーミングに対して責任を負う。
【0013】
特定の実施形態によれば、本発明はサービスプロバイダの加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを供給するシステムを提供する。システムは、ダウンロード可能および記録可能なコンテンツを供給するよう動作するサービスプロバイダを含み、このコンテンツはダウンロードまたは記録された後にストリーミングデータとして供給することができる。またシステムは、サービスプロバイダと関連し、且つテレビ受像機との接続に適したデバイスの加入者コミュニティピア・ツー・ピアネットワークを含む。さらにシステムは、サービスプロバイダの加入者コミュニティピア・ツー・ピアネットワークにおけるノードである受信器と、能動的な供給側およびバックアップ的な供給側を含む供給側のセットとを含む。各供給側はサービスプロバイダの加入者コミュニティピア・ツー・ピアネットワークにおけるノードであり、各供給側はサービスプロバイダもしくは1つまたは複数の他のノードからコンテンツをダウンロードおよび/または記録した後にオン・デマンドストリーミングデータを供給するよう機能する。受信器は、この受信器による要求に応じて供給側のセットにおける1つまたは複数の供給側からストリーミングされたデータを受信するよう機能する。
【0014】
別の特定の実施形態によれば、本発明はサービスプロバイダの加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを供給する方法を提供する。本方法は、加入者コミュニティピア・ツー・ピアネットワークをサービスプロバイダの加入者に提供するステップと、ダウンロードおよび/または記録され、続けてストリーミングデータとしてオン・デマンドで供給される、ダウンロード可能および記録可能なコンテンツを提供するステップと、加入者コミュニティピア・ツー・ピアネットワークと関連する検索エンジンを提供するステップとを有する。本方法は、加入者を加入者コミュニティピア・ツー・ピアネットワークに接続するステップと、加入者コミュニティピア・ツー・ピアネットワークに接続されている他の加入者によって先行してダウンロードまたは記録されたコンテンツを検索し、1つまたは複数の他の加入者からストリーミングデータとしてそのようなダウンロードおよび/または記録されたコンテンツをオン・デマンドで受信するために、各加入者に検索エンジンの使用を許可するステップとを有する。
【0015】
さらに別の特定の実施形態によれば、本発明は加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを受信するシステムを提供する。システムは加入者コミュニティピア・ツー・ピアネットワークと、この加入者コミュニティピア・ツー・ピアネットワークにおけるノードであるストリーミングデータの受信器と、ストリーミングデータの供給側のセットとを有する。供給側のセットは能動的な供給側のセットとバックアップ的な供給側のセットとを有し、供給側のセットにおける各供給側は加入者コミュニティピア・ツー・ピアネットワークにおけるノードである。ストリーミングデータは複数のブロックを含む。オン・デマンドで受信されるべきストリーミングデータの各ブロックに関して、受信器は、FECエンコーディング・オーバヘッド比を使用し、このFECエンコーディング・オーバヘッド比を用いてFECエンコーディングされたブロックの個別に割り当てられた少なくとも1つの小部分を個別に割り当てられたデータレートで送信することを各能動的な供給側にシグナリグし、FECエンコーディングされたブロックのセグメントを受信し、ここで各セグメントは個別に割り当てられた小部分の少なくとも一部を表し、FECエンコーディングされたブロックをセグメントの集合体に基づきデコーディングし、このデコーディングされたブロックをバッファに記憶し、各能動的な供給側とのネットワークコネクションの性能を監視し、結果としてオーバーフローまたはアンダーフローが生じることになる状態を検出するためにバッファを監視し、ネットワークコネクションの性能およびバッファの状態に基づいて、バッファがオーバーフローまたはアンダーフローに達することを回避するために品質適合を実施する。
【0016】
別の特定の実施形態によれば、本発明は加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを受信する方法を提供する。本方法は、加入者コミュニティピア・ツー・ピアネットワークにおける候補供給側のセットから能動的な供給側のセットとなるべき供給側のセットを選択し、候補供給側のセットからバックアップ的な供給側のセットとなるべき別の供給側のセットを選択するステップを有する。本方法は、受信されるべきストリーミングデータの各ブロックに関して、FECエンコーディング・オーバヘッド比を使用するステップを有し、このFECエンコーディング・オーバヘッド比を用いてFECエンコーディングされたブロックの個別に割り当てられた少なくとも1つの小部分を個別に割り当てられたデータレートで送信することを各能動的な供給側にシグナリグするステップを有し、FECエンコーディングされたブロックのセグメントを受信するステップを有し、ここで各セグメントは個別に割り当てられた小部分の少なくとも一部を表し、FECエンコーディングされたブロックをセグメントの集合体に基づきデコーディングし、このデコーディングされたブロックをバッファに記憶するステップを有し、各能動的な供給側とのネットワークコネクションの性能を監視するステップを有し、結果としてオーバーフローまたはアンダーフローが生じることになる状態を検出するためにバッファを監視するステップを有し、ネットワークコネクションの性能およびバッファの状態に基づいて、バッファがオーバーフローまたはアンダーフローに達することを回避するために品質適合を実施するステップを有する。
【0017】
別の特定の実施形態によれば、本発明は加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを供給するシステムを提供する。システムは加入者コミュニティピア・ツー・ピアネットワークにおけるノードである受信器と、ストリーミングデータを有する供給側のセットとを含み、供給側のセットにおける各供給側は加入者コミュニティピア・ツー・ピアネットワークにおけるノードである。ストリーミングデータは複数のブロックを含み、またストリーミングデータの各ブロックに関して、各供給側は、使用されるべきFECエンコーディング・オーバヘッド比を表す受信器からの信号、個別に割り当てられたデータレート、またFECエンコーディング・オーバヘッド比を使用したブロックのFECエンコーディングにより生じるFECエンコーディングされたブロックの個別に割り当てられた小部分を受信し、またFECエンコーディングされたブロックの割り当てられた小部分の少なくとも一部を個別に割り当てられたデータレートで送信するよう動作する。
【0018】
別の特定の実施形態によれば、本発明は加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを供給する方法を提供する。加入者コミュニティピア・ツー・ピアネットワークにおいて受信器によって受信されるべきストリーミングデータの各ブロックに関して、本方法は、使用されるべきFECエンコーディング・オーバヘッド比を表す受信器からの信号、個別に割り当てられたデータレート、またFECエンコーディング・オーバヘッド比を使用したブロックのFECエンコーディングにより生じるFECエンコーディングされたブロックの個別に割り当てられた小部分の受信、またFECエンコーディングされたブロックの割り当てられた小部分の少なくとも一部を個別に割り当てられたデータレートでの受信器への送信を含む。
【0019】
別の特定の実施形態によれば、本発明はストリーミングビデオデータの早送り再生または巻き戻し再生をシミュレートするための方法を提供する。本方法は、ストリーミングレートでストリーミングビデオデータを受信するステップと、通常の速度に対応する再生レートで後に再生するために受信したストリーミングビデオデータをバッファに記憶するステップと、通常の速度よりも速い速度でバッファから記憶されているストリーミングビデオデータを再生するステップとを有する。本方法はまた、アンダーフロー状態についてバッファを監視するステップを有し、ここでストリーミングレートは再生レートよりも低く、またアンダーフロー状態の検出に基づき、事前に求められたビデオクリップを記憶されているストリーミングビデオデータ間におけるバッファに挿入するステップを有する。
【0020】
さらに別の特定の実施形態によれば、本発明はストリーミングビデオデータの早送り再生または巻き戻し再生をシミュレートするための方法を提供する。本方法は、ストリーミングレートでビデオファイルからストリーミングビデオデータを受信するステップと、通常の視聴速度に対応する通常の再生レートで後に再生するために受信したストリーミングビデオデータをバッファに記憶するステップと、スピードアップされた視聴速度に対応するスピードアップされた再生レートでの早送り再生のための命令を受信するステップとを有する。本方法はまた、ビデオファイルにおけるジャンプポイントから始まるストリーミングビデオデータを受信するステップと、スピードアップされた再生レートでの再生をシミュレートするために、記憶されているストリーミングビデオデータをバッファから通常の再生速度よりも速い再生レートで再生するステップを含む。
【0021】
本発明のこれらの特定の実施形態および他の特定の実施形態を以下ではより詳細に説明する。
【0022】
本明細書に組み込まれ、また本明細書の一部をなす添付の図面は本発明の種々の実施形態を示し、また以下の説明と関連してそれらの実施形態の説明に使用される。便宜上、全ての図面を通して同一の構成要素または同様の構成要素には同一の参照番号が付されている。
【図面の簡単な説明】
【0023】
【図1】慣例のビデオ・オン・デマンド(VoD)サービスを実施するためのシステムを示す。
【図2】ピア・ツー・ピアネットワークによって提供される付加的なコンテンツを用いて、慣例のビデオ・オン・デマンド(VoD)サービスを拡大するためのシステムの実施形態を示す。
【図3】ロングテールを表すグラフを示す。
【図4】VoD・ツー・ピア(V2P)システムの実施形態を示す。
【図5】V2Pシステムを使用してストリーミングセッションを実施するための方法のフローチャートを示す。
【図6】V2Pシステムの1つの実施形態を表すブロック図を示す。
【図7】ピア選択順位方程式のグラフを示す。
【図8】ストリーム管理モジュールの詳細を含む、V2P受信器を表すブロック図を示す。
【図9】動的バッファ管理技術がバッファオーバーフローまたはアンダーフローをどのようにして回避することができるかを表すグラフを示す。
【図10】バッファ管理スキーマを表すグラフを示す。
【図11】コネクション監視に使用される単純なバイナリツリーを示す。
【図12】一連のMPEGフレームを示す。
【図13】早送り動作をシミュレートするためにビデオデータ間に挿入されたビデオクリップを示す。
【図14】V2Pシステムの1つの実施形態を表すブロック図を示す。
【図15】V2Pシステムを評価するための例示的なセットアップを示す。
【図16】高帯域幅環境において実施されているV2Pシステムを示す。
【図17】V2Pシステムの1つの実施形態を表すブロック図を示す。
【図18】TV視聴行動およびロングテールを表すグラフを示す。
【図19A】V2Pシステムが標準画質(SD)品質で供給することができる、並行するストリームの数を表すグラフを示す。
【図19B】V2PシステムがSD品質で供給することができる、ストリームの最大数または累積数を表すグラフを示す。
【図20A】V2Pシステムが準DVD品質で供給することができる、並行するストリームの数を表すグラフを示す。
【図20B】V2Pシステムが準DVD品質で供給することができる、並行するストリームの数を表すグラフを示す。
【図21A】V2Pシステムが準DVD品質で供給することができる、並行するストリームの数を表すグラフを示す。
【図21B】V2Pシステムが準DVD品質で供給することができる、並行するストリームの数を表すグラフを示す。
【図22】V2Pシステムの保存の側面を表すグラフを示す。
【図23】共通のビデオフレームを識別するための方法を説明するフローチャートである。
【発明を実施するための形態】
【0024】
上述したように、殊にVoDシステムを拡大するために、本発明はSTB間のピア・ツー・ピア(p2p)ネットワークに関する。各STBは特定の実施形態によればネットワークのノードである。さらには、本発明の特定の実施形態はVoD・ツー・ピア(V2P)と称されるマルチソースストリーミング技術に関し、このマルチソースストリーミング技術によりサービスプロバイダのネットワーク内のあらゆるピアSTBはネットワーク内の他のSTBからビデオコンテンツを取得し視聴することができる。したがって本発明によるその種のV2Pネットワークは事実上加入者コミュニティのためのVoDシステムとなり、このVoDシステムにおいてはいずれのメンバーも他のいずれかのメンバーによってダウンロードおよび/または記録されたコンテンツを取得し視聴することができる。
【0025】
典型的には、加入者コミュニティはSTBのセットを含んでいるので、V2PはSTBからのコンテンツのオン・デマンドの視聴を可能にするマルチソースビデオストリーミングシステムである。本発明の原理により設計されているV2Pシステムのアーキテクチャをこのアーキテクチャの各構成要素の説明も合わせて説明する。そのようなV2Pシステムは、復元力があり且つ高品質のビデオストリーミングに対して責任を負う。
【0026】
有利には、サービスプロバイダが提供するV2Pサービスにより、このサービスプロバイダによって管理されているp2pネットワーク全体への違法的なビデオ配布を阻止することができる。殊に、サービスプロバイダは加入者STBによって記録されるコンテンツをサービスプロバイダによって提供されるコンテンツに制限することができるので、新たなビデオコンテンツをSTBに導入するメカニズムは存在しない(すなわち加入者が関与している限りシステムは閉じられている)。ピアSTB間でのビデオコンテンツのそれ以降の共有は、サービスプロバイダの顧客(加入者)であるSTPピアの閉じられたコミュニティに制限されている。コンテンツの違法な共有が行われることなく、いずれかのパーソナルコンピュータ(PC)または他の適切なデバイスをp2pネットワークに接続できるようにこのp2pネットワークを拡張することができる。
【0027】
本発明によればサービスプロバイダに関しては、サービスプロバイダの加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを提供するシステムおよび方法の種々の実施形態が考えられる。サービスプロバイダの加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを提供するシステムの1つの実施形態は、テレビ受像機と接続されるよう適合されたデバイスの加入者コミュニティピア・ツー・ピアネットワークと、ダウンロードまたは記録された後にストリーミングデータとして供給できるダウンロード可能および記録可能なコンテンツを提供するサービスプロバイダとを含む。このシステムにおいてはコンテンツの受信器とコンテンツを提供するストリーミングデータの供給側のセットとが存在し、この供給側には能動的な供給側とバックアップ的な供給側が含まれる。各供給側は、サービスプロバイダもしくは1つまたは複数の他のノードからコンテンツをダウンロードまたは記録した後にオン・デマンドストリーミングデータを供給するよう機能する。その種のシステムにおける受信器は、この受信器による要求に応じて供給側のセットにおける1つまたは複数の供給側からストリーミングされたデータを受信するよう機能する。受信器および供給側はそれぞれ加入者コミュニティピア・ツー・ピアネットワークにおけるノードであり、また各ノードとしてセットトップボックス、またはテレビ受像機およびサービスプロバイダのネットワークに接続されるよう適合されている他のデバイスが考えられる。サービスプロバイダは加入者コミュニティにおけるノードによってダウンロードまたは記録可能なオーディオデータ、ビデオデータまたはその両方のようなコンテンツを供給し、またこのダウンロードまたは記録可能なコンテンツを供給側として動作するノードからストリーミングデータとして供給することができる。
【0028】
種々の実施形態によれば、そのようなシステムを検索エンジンによって向上させることができ、この検索エンジンによりユーザはコンテンツブラウザを使用してコンテンツを検索し、またコンテンツ推薦によって推薦されるコンテンツを受信することができる。別の実施形態によれば、このシステムをさらにインセンティブマネージャによって向上させることができ、このインセンティブマネージャはストリーミングセッションへの関与に関してコンテンツの所有者、サービスプロバイダおよび供給側に報酬を与える。別の実施形態によれば、このシステムを付加的にディジタル権利マネージャによって向上させることができ、このディジタル権利マネージャはコンテンツの違法な配布を阻止する。
【0029】
前述との関連において、特定の実施形態によれば、本発明はサービスプロバイダの加入者に対して加入者コミュニティピア・ツー・ピアネットワークを提供し、加入者をこのネットワークに接続した後に、サービスプロバイダの加入者コミュニティピア・ツー・ピアネットワークにおいてオン・デマンドストリーミングデータを提供する方法に関する。本方法は、ダウンロードおよび/または記録され、続けてストリーミングデータとしてオン・デマンドで供給することができる、ダウンロード可能および記録可能なコンテンツの提供を含む。また本方法は、加入者コミュニティピア・ツー・ピアネットワークと関連した検索エンジンの提供と、各加入者による検索エンジンの使用およびオン・デマンドで選択されたデータの受信の許可を含む。殊に、加入者は加入者コミュニティピア・ツー・ピアネットワークに接続されている他の加入者によって先行してダウンロードまたは記録されたコンテンツを検索するために検索エンジンを使用する。続いて、加入者はそのようなダウンロードおよび/または記録されたコンテンツをストリーミングデータとして1つまたは複数の他の加入者からオン・デマンドで受信する。
【0030】
コンテンツのオン・デマンドの受信に関して、本発明の種々の実施形態は加入者コミュニティピア・ツー・ピアネットワークにおける1つまたは複数の供給側からストリーミングデータをオン・デマンドで受信するためのシステムおよび方法を提供する。そのようなシステムは受信器として機能するノードと、ストリーミングデータの供給側として機能するノードのセットと包含し、このノードのセットには能動的な供給側およびバックアップ的な供給側が含まれる。換言すれば、受信器ならびに供給側のセットにおける各供給側は加入者コミュニティピア・ツー・ピアネットワークにおけるノードである。そのようなシステムにおける受信器はオーディオデータ、ビデオデータまたは両方を含むストリーミングデータを受信する。受信すべきストリーミングデータの各ブロックに関して、受信器はFECエンコーディング・オーバヘッド比を使用し、また各能動的な供給側に個別に割り当てられたデータレートで、FECエンコーディング・オーバヘッド比を使用してFECエンコーディングされたブロックの個別に割り当てられた小部分を送信することをシグナリングする。受信器はFECエンコーディングされたブロックのセグメントを受信し、セグメントの集合体に基づきFECエンコーディングされたブロックをデコーディングし、またデコーディングされたブロックをバッファに記憶する。ここで各セグメントは個別に割り当てられた小部分の一部を表す。受信器は能動的な供給側をそれぞれ有しているネットワークコネクションの性能を監視し、また結果としてオーバーフローまたはアンダーフローが生じる状態を検出するためにバッファを監視する。コネクションの性能およびバッファの状態に基づき、受信器はバッファのアンダーフローまたはオーバーフローへの到達を回避するために品質適合を実施する。監視によりストリーミングセッションの中間における供給側の障害またはコンテンツの削除が検出され、またこの供給側の障害およびコンテンツの削除を処理するために、能動的なセットに付加的なバックアップピア、能動的な供給側の間でのレートの再分布およびFECエンコーディング・オーバヘッド調整のような一連の技術が使用される。
【0031】
既述のように、各受信器および各供給側は加入者コミュニティピア・ツー・ピアネットワークにおけるノードであり、またその種の各デバイスをテレビ受像機およびサービスプロバイダのネットワークに接続されるよう適合させることができる。換言すれば、その種のデバイスは種々の実施形態に応じてセットトップボックス、パーソナルコンピュータまたはモバイル装置でよい。各デバイスは受信器、供給側またはその両方として機能することができる。供給側は1つまたは複数のメトリクスのあらゆる組み合わせに基づき選択される。このメトリクスには供給側の供給状態または受信状態、利用可能なアップリンク帯域幅、処理能力、信頼性記録(reliability history)、パス待ち時間、パケット損失および公平性が含まれる。供給側の信頼性記録は特定の実施形態に応じて、デバイス故障率、ネットワーク接続時間およびコンテンツアベイラビリティを基礎とする。公平性はロードバランシングおよび先行の選択記録を基礎とする。
【0032】
特定の実施形態によれば、その種のシステムにおける受信器は、各能動的な供給側とのネットワークコネクションの性能の監視に基づいてストリーミングセッションに適合されるよう機能する。このようなネットワークコネクションの性能には、供給側がネットワークの不安定性、デバイス故障、またはストリーミングデータとして供給すべきコンテンツの削除を経験したか否かの検出を含む。また受信器は他の供給側から実際に受信したストリーミングデータのメトリクスに基づいて各ネットワークコネクションの性能を受動的に監視するよう機能する。また受信器は、目下のバッファサイズ、目下の再生レートおよび目下のストリーミングレートを含むバッファの監視に基づいてストリーミングセッションを適合させる。必要に応じて受信器は能動的な供給側間のレート分布、供給側のセットまたはFECエンコーディングパラメータを動的に調整することができる。受信器は新たなデータレートを割り当てることによって、または新たなブロックの小部分を割り当てることによって、能動的な供給側間のレート分布を調整するよう機能する。受信器は種々の実施形態に応じて、能動的な供給側を付加または除去することによって、バックアップ的な供給側を能動的な供給側のセットに付加することによって、またはバックアップ的な供給側のセットに供給側を付加することによって能動的な供給側のセットを調整することができる。受信器は新たなFECエンコーディング・オーバヘッド比または新たなFECエンコーディングスキーマを使用することによって、FECエンコーディングパラメータを調整することができる。FECエンコーディング・オーバヘッド比を使用することによって、受信器は供給側によって使用されるべきFECエンコーディング・オーバヘッド比を1つのブロックの後続のFECエンコーディングにおいてセットすることができるか、単純に、FECエンコーディング・オーバヘッド比を使用してFECエンコーディングされている事前エンコーディングされたブロックを選択するよう供給側にシグナリングすることができる。
【0033】
その種のシステムにおける受信器は特定の実施形態に応じて、能動的な供給側のセット間でストリーミングデータのソースとして使用されるべきメディアファイルの複数の個々のコピーにおける共通の始点も求める。受信器は期間を規定し、また各能動的な供給側から基準オブジェクトのセットを受信する。期間は加入者コミュニティネットワークと接続されているデバイスのクロック同期に関連させてもよい。各基準オブジェクトはその期間内にメディアファイルの個々のコピーにおいて現われる基準フレームに対応する。受信器は、基準オブジェクトの全てのセットに共通する共通の基準オブジェクトを識別するために、受信した基準オブジェクトのセットを比較し、共通の基準オブジェクトに対応する基準フレームとなるよう始点をセットする。ビデオファイルにおいては、各基準フレームはビデオフレームであり、また各基準オブジェクトはハッシュ値である。
【0034】
コンテンツのオン・デマンドの供給に関して、本発明の種々の実施形態は加入者コミュニティピア・ツー・ピアネットワークにおけるストリーミングデータをオン・デマンドで供給するためのシステムおよび方法を提供する。その種の実施形態はこのネットワークにおけるノードである受信器と、ストリーミングデータの複数のブロックの供給側のセットとを包含し、供給側のセットにおける各供給側もこのネットワークにおけるノードである。供給されるストリーミングデータの各ブロックに関して、その種のシステムにおける各供給側は、使用されるべきFECエンコーディング・オーバヘッド比を表す受信器からの信号、個別に割り当てられたデータ比、またFECエンコーディング・オーバヘッド比を使用したブロックのFECエンコーディングにより生じるFECエンコーディングされたブロックの個別に割り当てられた小部分を受信する。続いて各供給側はFECエンコーディングされたブロックの割り当てられた小部分の少なくとも一部を個別に割り当てられたデータレートで送信する。
【0035】
前記に付加的に、本発明の種々の実施形態はストリーミングビデオデータの早送り再生および巻き戻し再生をシミュレートするシステムおよび方法を含む。ストリーミングビデオデータの早送り再生または巻き戻し再生をシミュレートする方法の1つの実施形態は、ストリーミングビデオデータのストリーミングレートでの受信、受信したストリーミングビデオデータを後に通常速度に対応する再生レートで再生するためのバッファへの記憶、ストリーミングレートが再生レートよりも低いアンダーフロー状態に関するバッファの監視、および記憶されているストリーミングビデオデータ間におけるバッファへの所定のビデオクリップの挿入を含む。
【0036】
ストリーミングビデオデータの早送り再生および巻き戻し再生をシミュレートする方法の別の実施形態は、ストリーミングレートでのビデオファイルからのストリーミングビデオデータの受信、受信したストリーミングビデオデータを通常の視聴速度に対応する通常の再生レートで後に再生するためのバッファへの記憶を含む。この方法はさらに、スピードアップされた視聴速度に対応するスピードアップされた再生レートでの早送り再生または巻き戻し再生のための命令の受信、ビデオファイルにおけるジャンプポイントから始まるストリーミングビデオデータの受信、およびスピードアップされた再生レートでの再生をシミュレートするための、記憶されているストリーミングビデオデータのバッファからの通常の再生速度よりも速い再生レートでの再生を含む。その種の方法は、記憶されているストリーミングビデオデータ間における所定のビデオクリップのバッファへの挿入も含む。
【0037】
以下の記述では、本発明の複数の実施形態および本発明の実践形式が示されている添付の図面を参照する。他の実施形態を使用することもでき、また本発明の範囲を逸脱することなく構造的および機能的な変更も行えるものと解される。
【0038】
本発明の特定の実施形態を説明するためのコンテクストを提供するために、図1は慣例のビデオ・オン・デマンド(VoD)サービスを実現するシステムを示す。インフラストラクチャベースのメディアストリーミングまたは集中型のビデオ・オン・デマンド(VoD)ソリューションは一般的に1つまたは複数のメディアサーバ、また通常はセットトップボックス(STB)であるクライアントのセットを有する。メディアサーバはクライアントへのメディアのオン・デマンドストリーミングに対して責任を有する。場合によっては、VoDシステムはさらにキャッシングプロキシを有することができる。図1に示されているように、サービスプロバイダVoDシステム100は管理インフラストラクチャ110、メディアサーバ120およびコンテンツライブラリ130を有する。ここではセットトップボックス(STB)として示されているクライアントデバイス140はサービスプロバイダ100と通信するよう接続されており、またダウンロードまたはストリーミングされたコンテンツをビデオの一部としてコンテンツライブラリ130からオン・デマンドで受信する。管理インフラストラクチャ110はクライアントデバイス140からのリクエストのダウンロードおよびストリーミングを処理し、またサービスプロバイダ100とクライアントデバイス140との間の制御コネクションおよびデータコネクションを管理する。例えば、メディアサーバ120は要求されたメディアの管理インフラストラクチャ110を介したコンテンツライブラリ130からクライアントデバイス140へのオン・デマンドでのストリーミングを実施する。
【0039】
前述したように、図1に示されているような慣例のVoDソリューションは典型的には、映画タイトルの簡素なセレクションを提供し、期間限定で、例えば24時間の間、プレミアムコンテンツのみをキャッシュすることができる。しかしながら、VoDシステムの加入者がまさに視聴したいコンテンツを見たいときに視聴できる権限が与えられれば(すなわちオン・デマンド)、VoDアプローチはより頻繁に使用されることになるであろう。これにより顧客満足度は高まり、またサービスプロバイダに関しては収入が増え、チャーンが減る。
【0040】
セットトップボックス(STB)は、このSTBのパーソナルビデオレコーダ(PVR)機能を使用したTV番組の再生および記録のようなサービスに関してテレビ受像機がサービスプロバイダネットワークへのユーザインタフェースとなることを可能にするデバイスである。本発明の1つの実施形態によれば、全ての加入者のSTBはサービスプロバイダが管理するピア・ツー・ピア(p2p)ネットワークに接続され、したがってサービスプロバイダのネットワークのあらゆる加入者は、それらの加入者のSTBにダウンロードおよび/または記録されたビデオコンテンツを他の加入者のSTBにストリーミングすることができる。
【0041】
例えば、いずれの加入者もサービスプロバイダによって提供されるあらゆるTV番組または他のコンテンツを自身のSTBにダウンロードおよび/または記録することができる。他の加入者にコンテンツを利用できるようにするために、コンテンツを自動的にサービスプロバイダのp2pネットワークに自動的に通知または登録することができる。ネットワークのいずれの加入者もこのコンテンツを検索し、視聴することができる。V2Pと称されるそのようなシステムはSTBによって形成されるp2pネットワークに関するマルチソースビデオストリーミングシステムである。つまり、V2Pは複数のSTBからの高品質且つ復元力のあるビデオストリーミングを提供する。
【0042】
これに関して図2は、本発明の1つの実施形態によるコミュニティVoDシステムを構築するために、ピア・ツー・ピアネットワークによって提供される付加的なコンテンツを用いて慣例のビデオ・オン・デマンド(VoD)サービスを拡大するシステムを示す。図示されているように、サービスプロバイダVoDシステム200は管理インフラストラクチャ210、メディアサーバ220、コンテンツライブラリ230およびサービスプロバイダによって管理されるピア・ツー・ピア(p2p)ネットワーク250を有する。さらにp2pネットワーク250は、ここではセットトップボックス(STB)として示されているピアデバイス260a,260b,260c(以下ではピアデバイス260と称する)と拡張コンテンツライブラリ270aおよび270b(以下では拡張コンテンツライブラリ270と称する)を有する。拡張コンテンツライブラリ270はピアデバイス260に記憶されているダウンロードおよび/または記録されたコンテンツを有する。例えば、ピアデバイス260はコンテンツライブラリ230から管理インフラストラクチャ210を介してストリーミングされたメディアをダウンロードおよび/または記録および記憶することができる。p2pネットワーク250に接続されているあらゆる加入者によって記録された拡張コンテンツを用いるVoDシステムのコンテンツライブラリの拡張によりコンテンツの選択肢が増え、また共通のVoDシステムが構築される。
【0043】
特定の実施形態によれば、ここではセットトップボックス(STB)として示されているクライアントデバイス240はサービスプロバイダVoDシステム200と通信するよう接続されており、またダウンロードまたはストリーミングされたコンテンツをビデオの一部としてコンテンツライブラリ230から、または拡張コンテンツライブラリ270からオン・デマンドで受信する。管理インフラストラクチャ210はクライアントデバイス240からのリクエストのダウンロードおよびストリーミングを処理し、またサービスプロバイダVoDネットワーク200とクライアントデバイス240との間の制御コネクションおよびデータコネクションを管理する。例えば、メディアサーバ220は要求されたメディアの管理インフラストラクチャ210を介したコンテンツライブラリ230からクライアントデバイス240へのオン・デマンドでのストリーミングを実施する。またクライアントデバイス240は要求したメディアの拡張コンテンツライブラリ270からのオン・デマンドのストリーミングを要求することができる。p2pネットワーク250はこれらの要求を処理し、またp2pネットワーク250とクライアントデバイス240との間の制御コネクションおよびデータコネクションを管理し、要求されたメディアの拡張コンテンツライブラリ270からクライアントデバイス240へのオン・デマンドのストリーミングを実施する。
【0044】
V2Pソリューションは必ずしも図1に示されているような集中型のVoDソリューションに代わるものを意味していないが、図2に示されているように、そのようなソリューションについての補完的な分散型の拡張として使用することができる。VoDとV2Pは一緒に膨大な量のコンテンツを加入者にもたらすことができる。集中型のVoDは非常に人気のある大多数のコンテンツプログラムを提供し続けることができ、これに対しV2Pはいわゆる「ロングテール」市場を提供することに良く適している。
【0045】
図3は、ロングテールを表すグラフを示す。図3によれば、膨大な量になる余り人気のないアイテムの集合体を合計すれば組織に関して多額の利益になる可能性がある。多くのビジネスでは、少数のオーディエンスにのみ関心があるコンテンツアイテムを売ることによって利益を得ることができる。これらのあまり人気のないコンテンツアイテムはそのようなオンラインビジネスに関してロングテールを作り上げることができる。ロングテールからコンテンツアイテムを提供することにより、顧客は以前見つからなかったコンテンツを発見、購入、および照会することができる。同様にして、V2Pはビデオ・オン・デマンド市場に関するロングテール現象にレバレッジを導入することができ、これにより、それらのあまり人気のない番組の反復的な視聴から収入を得ているコンテンツ所有者およびサービスプロバイダの双方にとって強力なビジネスモデルが実現される。さらにV2PはこれらのSTBリソースを供給する加入者に報酬を与える。
【0046】
V2P技術は慣例のストリーミングソリューションでは取り組むことができなかった多くの技術的な要求(限定的なアップストリーム帯域幅や復元力が含まれる)に取り組んでいる。
【0047】
現在では、DSLおよびケーブルモデムは家庭での使用に関する2つの一般的なブロードバンド技術である。両方とも非対称的な帯域幅特性を有する。つまりダウンロード帯域幅はアップロード帯域幅よりも高い。各STBに対するアップロード帯域幅の制約を解消するために、V2Pはストリーミングソースとして複数のSTBを使用し、また受信側のSTBはこれらの複数の供給側からのストリーミングセッションを調整する。アップロード帯域幅もダウンロード帯域幅も増大したとしても、V2Pは対称的な帯域幅環境でも非対称的な帯域幅環境でも高品質且つ復元力のあるストリーミングを提供するために依然として使用することができる。
【0048】
ネットワークおよびデバイスはまだ完璧なものではなく、つまり復元メカニズムは逆の条件を考慮するために設計されなければならない。xDSLまたはケーブルモデムコネクションを介するV2Pストリームおよびネットワーク自体の信頼性が高くないので、不安定なネットワークを介する復元力のあるストリーミングがV2Pに関する1つの争点である。如何なる時点においてもSTBはスイッチオフされる可能性がある。もしくはコンテントがストリーミングセッション中に削除される可能性がある。継続的且つ円滑なストリーミングを提供するために、V2Pは非常に耐性の高いエラー回復メカニズムを要求する。特定の実施形態によれば、V2Pはリンクならびにデバイスの不信頼性に取り組み、また高品質のストリーミングを提供するために、インテリジェントなピア選択、フォワード・エラー・コレクション(FEC)、動的なレート分布、動的なバッファ管理、ネットワークトモグラフィを基礎とするコネクション監視のようなメカニズムの組合せを使用する。
【0049】
図4は、VoD・ツー・ピア(V2P)システムの実施形態を示す。図示されているように、V2Pシステム400は受信器410、送信器420a,420bおよび420c(以下では送信器と称する)、リソース管理フレームワーク(RMF)430ならびにインセンティブマネージャ440を有する。また図4にはサービスプロバイダ450およびコンテンツ所有者460も示されている。ここではセットトップボックス(STB)として示されている受信器410は受信側のピアであり、送信器420からストリーミングメディアを受信する。ここではセットトップボックス(STB)として示されている送信器420は送信側のピアであるか、ストリーミングメディアの供給側である。受信器410は時には送信側のピアとしても動作できることを言及しておく。同様に、送信器420のいずれかは時には受信側のピアとして動作することもできる。リソース管理フレームワーク(RMF)430はサービスプロバイダによって管理される管理インフラストラクチャである。サービスプロバイダは受信器410と送信器420との間の制御コネクションおよびデータコネクションを管理し、要求されたメディアのオン・デマンドのストリーミングを実施する。またRMF430により受信器410は送信器420にダウンロードおよび/または記録され記憶されたストリーミング可能なコンテンツ、例えばメディアファイルについてV2Pシステム400を検索することができる。またRMF430により受信器410はコンテンツ推薦を受信することができる。インセンティブマネージャ440はV2Pシステムを使用する会計状況を管理する。これには、ストリーミングメディアとして特定のコンテンツを受信した受信器への課金、ストリーミングメディアの供給側への報酬またコンテンツの各ストリーミングに対するサービスプロバイダ450およびコンテンツ所有者460への報酬が含まれる。
【0050】
図4に示されているV2Pシステムはマルチソースストリーミングシステムである。このことは、各ストリーミングセッションが1つの受信器と送信器または供給側のセットを含むことを意味している。1つの基本的な仮定は、各供給側が所定のコンテンツアイテムに対応するメディアファイルの同一のコピーを有しているということである。しかしながら、供給側のSTBが同期しておらず、またそれらSTBのメディアファイルのコピーが完全に同一でない場合には、特定の実施形態によるV2Pは複数の供給側からのストリーミングメディアを同期するメカニズムを提供する。以下ではこの同期メカニズムを詳細に説明する。V2Pはメディアファイルを(例えば1〜2秒の再生に適した)小さいデータブロックのセットに分割し、各ソースが同一のブロックの小部分を提供する。その結果、全ての供給側が1つのファイルの各ブロックに寄与することになる。
【0051】
例えば、特定の実施形態によれば、パケット損失を許容するためにメディアファイルの各ブロックをフォワード・エラー・コレクション(FEC)コードを用いて符号化することができる。FECエンコーディングスキーマは2つのパラメータ(n,k)で表され、データブロック毎にn個のパケットがk個のパケット(但しn>k)の代わりに送信される。n個のパケットの中からのいずれかのk個のパケットはブロックを再構築することができる。したがって、ストリーミングセッションはブロック毎に(n−k)個までのパケットの損失を許容することができる。FECエンコーディング・オーバヘッド比αは次式のように定義される。
【数1】
【0052】
FECエンコーディング・オーバヘッド比およびエンコーディングスキーマはストリーミングセッションに関するストリーミングレートおよびパケット損失許容度に対して多大な影響を及ぼす。したがってFECエンコーディング・オーバヘッド比をストリーミングセッションの特定のエンコーディングスキーマに関して確立することができる。1つの例において、FECエンコーディング・オーバヘッド比は供給側によって使用されるべきエンコーディングパラメータを確立するために使用され、また別の例において、FECエンコーディング・オーバヘッド比は特定のエンコーディングパラメータに適しているデータのFECエンコーディングされたブロックを選択するよう供給側にシグナリングするために使用することができる。一例として、図5は本発明の1つの実施形態によるV2Pシステムを使用してストリーミングセッションを実施するための方法のフローチャートを示す。ストリーミングセッションは、特定のメディアファイルのような特定のコンテンツに関するストリーミング要求を行う受信器によって開始される。
【0053】
ステップ510では、要求されたメディアファイルを供給することができる候補供給側のセットを取得する。候補供給側は、要求されたメディアファイルのコピーを有するピアである。例えば、受信器はV2Pシステムにおける特定のコンテンツを検索するために検索エンジンを使用して、コンテンツの候補供給側のセットを取得することができる。
【0054】
ステップ520では、受信器が候補供給側のセットから能動的な供給側のセットおよびバックアップ的な供給側のセットを選択する。能動的な供給側は、要求されたメディアファイルを受信器にストリーミングするためにストリーミングセッション中に協力的に動作するピアである。バックアップ的な供給側は、1つまたは複数の能動的な供給側がネットワークの不安定性、デバイス故障またはコンテンツの損傷または削除に遭遇した場合に、ストリーミングセッション中に支援することができるピアである。受信器は種々の判定基準、例えばピアの状態、利用可能なアプリンク帯域幅、処理能力、信頼性記録、パス待ち時間、パスパケット損失および公平性のメトリクスなどに基づきピアを選択することができる。
【0055】
ステップ530では、受信器が各能動的な供給側との制御コネクションを開始する。受信器は公知の多数の技術の中からいずれか1つを使用することができる。例えば、受信器は伝送制御プロトコル(TCP)を使用して制御パケットを送信することができる。
【0056】
ステップ540では、各能動的な供給側が受信器とのデータコネクションを開く。受信器は公知の多数の技術の中からいずれか1つを使用して、供給側からストリーミングデータを受信することができる。例えば、受信器はユーザデータグラムプロトコル(UDP)を基礎とするスキーマを使用してストリーミングデータを受信することができる。
【0057】
ステップ550では、受信器は各能動的な供給側にFECエンコーディングされたブロックの少なくとも1つの小部分を割り当てられたデータレートで送信するようシグナリングすることによって、供給側からのFECエンコーディングされたブロックの小部分を要求する。割り当てられたデータレートの合計は目標のストリーミングレートを表す。各能動的な供給側はFECエンコーディングされたブロックの一部を送信し、このブロックの一部は特定のFECエンコーディング・オーバヘッド比を有する特定のFECエンコーディングスキーマを使用してFECエンコーディングされている。各能動的な供給側は、FECエンコーディングされたブロックの少なくとも1つの小部分を送信するための信号を受信器から受信すると、特定のFECエンコーディング・オーバヘッド比αを使用して特定のブロックをFECエンコーディングすることができる。択一的に各供給側は、1つまたは複数のFECエンコーディング・オーバヘッド比を使用してブロックを事前エンコーディングすることができ、また受信器からの信号の受信に応答して、事前エンコーディングされたブロックの一部を選択することができる。
【0058】
ステップ560では、受信器がFECエンコーディングされたブロックの部分またはセグメントを受信する。ネットワークの不安定性、デバイス故障ならびにコンテンツの損傷または削除に起因して、受信器はFECエンコーディングされたブロックの要求した小部分を実際には全て受信できない可能性がある。受信器が受信する部分またはセグメントは、受信器がステップ550において要求したFECエンコーディングされたブロックの小部分に対応する。実際に受信した部分またはセグメントに基づき、受信器は実際の受信データレートを求めるために各能動的な供給側とのコネクションの性能を受動的に監視する。実際の受信データレートの合計は現在のストリーミングレートを表す。
【0059】
ステップ570では、受信器がエンコーディングされたブロックの受信した部分またはセグメントに基づきブロックをデコーディングし、デコーディングされたブロックをバッファに記憶する。ブロックのデコーディングには、受信した部分またはセグメントからのFECエンコーディングされたブロックの再構築、再構築されたFECエンコーディングされたブロックのFECデコーディング、また使用される特定のビデオエンコーディングスキーマ(例えばMPEG)に応じたFECデコーディングされたブロックのさらなるデコーディングが含まれることを言及しておく。受信器は目下の再生レートでのバッファからの再生のためにデータを消費する。
【0060】
ステップ580では、受信器がバッファの状態を検査する。目下のバッファサイズ、目下の再生レートおよび目下のストリーミングレートを監視することによりバッファの状態を評価することができる。これらのメトリクスに依存して、バッファは3つのゾーン、すなわち加速ゾーン、快適ゾーンまたは減速ゾーンの内の1つにおいて動作することができる。例えば、バッファが快適ゾーンにおいて動作している場合には、受信器はステップ582bに進み、ストリーミングセッションを継続する。バッファが加速ゾーンまたは減速ゾーンにおいて動作している場合には、受信器はステップ582aに進む。
【0061】
ステップ582aでは、受信器がバッファのオーバーフローまたはアンダーフローを回避するために1つまたは複数のストリーミングレート、能動的なセットにおける供給側およびエンコーディング・オーバヘッド比を必要に応じて調整する。いずれかの供給側が能動的な供給側のセットに加えられる場合には、ステップ530および540が実施される。
【0062】
ステップ582bでは、受信器がストリーミングセッションは終了したか否かを求める検査を実施する。ストリーミングセッションが終了している場合には、プロセスがステップ590において終了する。ストリーミングセッションが終了していない場合には、プロセスはステップ550に戻る。
【0063】
したがってV2Pにおけるストリーミングセッションの一例は以下のステップを含む:
1.先ず、受信器ピアP0はp2pネットワークの検索エンジンから候補供給側のセットを取得する。
【0064】
2.候補供給側のセットから、受信器ピアP0は能動的な供給側としてピアP1,P2〜PNのセットを選択し、またバックアップ的な供給側としてP1,P2〜PMのセットを選択する。
【0065】
3.受信器ピアP0は能動的なセットにおける各供給側との制御コネクションを開始することによりストリーミングセッションを始める。
【0066】
4.制御コネクションを受信した後に、各供給側Piは受信器ピアP0とのデータコネクションを開く。
【0067】
5.受信器ピアP0は各供給側に特定のエンコーディング・オーバヘッド比αでエンコーディングされた特定のブロックの小部分を送信するよう周期的にシグナリングする。
【0068】
6.各供給側Piはファイルブロックをエンコーディングし、特定のレートにしたがいファイルファイルの小部分を送信する。
【0069】
7.各ブロックに関して十分なデータを受信した後に、受信器ピアP0はブロック全体をデコーディングし、バッファに記憶する。受信器側における再生器はバッファからデータを使用する。
【0070】
受信器ピアP0は、再生器に供給するためにデータが常にバッファ内に存在すること、またバッファオーバーフローを回避するためにバッファは一杯でないことを保証するためにネットワーク変化およびデバイス故障に反応する。必要に応じて、受信器ピアP0は1つまたは複数のバックアップ的なピアを能動的な供給側のセットに付加し、また新たに付加された幾つかのピアに対してステップを3〜4回繰り返す。
【0071】
受信器ピアP0はセッションが終了するまでステップを5〜7回繰り返す。
【0072】
図6はV2Pシステムのブロック図を示し、またさらに本発明の1つの実施形態による受信器を示す。この実施形態において、V2Pシステム600は受信器610、送信器620、リソース管理フレームワーク(RMF)630およびインセンティブマネージャ640を有する。受信器610はストリーミングデータを受信するために送信器620と対話する。受信器610はユーザがp2pネットワークを検索できるようにするためにRMF630と対話する。受信器610はインセンティブマネージャ640と対話し、このインセンティブマネージャ640はユーザへの課金および適切なエンティティへの報酬の付与に対して責任を有する。
【0073】
図6によれば、受信器610はさらにピア選択モジュール6110、ストリーム管理モジュール6120、インタラクティビディ管理モジュール(この実施形態においては再生器モジュールと表記する)6130、品質適合モジュール6140、コンテンツ検索およびコンテンツ推薦モジュール6150、照会モジュール6160およびデータ管理モジュール6170を有する。
【0074】
一時的に、ピア選択モジュール6110は能動的なピアおよびバックアップ的なピアまたは特定のコンテンツのストリーミングデータの供給側を選択するためにピア選択プロセスを使用する。ストリーム管理モジュール6120は能動的な供給側との制御コネクションおよびデータコネクションを管理し、能動的な供給側からのストリーミングデータを受信し、またストリーミングデータをデコーディングしてバッファに記憶する。またこのストリーム管理モジュール6120はバッファを管理し、ストリーミングレートを各能動的な供給側に動的に分布させ、受信器と各能動的な供給側との間のコネクションを監視し、またユーザからのインタラクティブな再生要求を管理する。この実施形態においては再生器6130モジュールとして示されているインタラクティビディ管理モジュール6130はインタラクティブな再生制御を提供し、またストリーム管理モジュール6120と対話するので、ユーザはストリーミングセッション中の一時停止、早送りおよび巻き戻しを行うことができる。品質適合モジュール6140はストリーム管理モジュール6120およびピア選択モジュール6110と対話し、ネットワークの不安定性、能動的な供給側の障害およびコンテンツの損傷または削除が生じた場合には、復元力があり且つ高品質のストリーミングを提供する。場合によっては、品質適合モジュール6140はそのような状況に対処するためにストリーミングデータの再供給を能動的な供給側に要求することができる。
【0075】
コンテンツ検索およびコンテンツ推薦モジュール6150はRMF630と対話し、特定の実施形態によれば、これによりユーザは特定のコンテンツを検索することができ、またコンテンツ推薦をユーザに提供することができる。参照モジュール6160はRMFおよびピア選択モジュール6110と対話し、遠隔のピアに関する情報を取得する。データ管理モジュール6170は受信したストリーミングデータの受信器の局所的な記憶装置における記憶を管理する。以下ではこれらのモジュールをそれぞれ説明する。
【0076】
ピア選択モジュール6110は能動的なピアのセットおよびバックアップ的なピアのセットを求めるためにピア選択プロセスを使用する。能動的なピアはストリーミングセッションのコンテンツを提供する。バックアップ的なピアはいずれかのSTBの故障中、またその時点における能動的なピアが目標のストリーミングレートを提供することができないときにネットワークが不安定になっている間に活動状態になる。またバックアップ的なピアを、ストリーミングセッション中に1つまたは複数の能動的なピアがコンテンツを削除するか、コンテンツの損傷が生じると活動状態にすることができる。
【0077】
この実施形態においては、ピア選択が2つのステップで実施される。第1のステップにおいては、RMF630がストリーミングされるコンテンツを有する候補供給側のセットを戻す。典型的な候補供給側のセットの大きさは15〜20のピアである。メディアファイルの複数のコピーがネットワーク内で発見された場合、この選択プロセスは限定的なリソースを有するピアを排除する。RMF630から候補供給側のセットを取得した後に、ピア選択モジュール6110は種々の判定基準に基づき能動的なピアのセットおよびバックアップ的なピアのセットを求める。例えば、後続のピアの状態、帯域幅、デバイス特性、信頼性、待ち時間、損失比および公平性に関する判定基準を使用することができる。
【0078】
1.ピア状態(S)
ピアの状態をピア選択の間に考慮することができる。ピアがストリームを受信している場合には、アップリンクは使用することができない。しかしながら、受信側のピアが別のストリーミングセッションを提供することを決定し、アップリンクがこの提供のために完全に使用される場合には、受信するストリーミングの品質は劣化することになる。何故ならば、シグナリングプロトコルはアップリンクの小さい小部分を使用するからである。したがって、供給側としてアイドル状態のピアを使用することが望ましい。ピアのSERVING(提供)状態またはRECEIVING(受信)状態の間に、ピア選択モジュール6110はピアiに対してSi=aiを割り当て、ここでaは利用可能なリソースに基づき計算される。ピアがIDLE(アイドル状態)であり、且つ提供のためのリソースを有する場合には通常Si=1である。
【0079】
2.供給側の利用可能なアップリンク帯域幅(B)
ストリーミングセッションに関して過剰に多いピアまたは過剰に少ないピアを使用することは望ましくない。過剰に多いピアが使用される場合には、受信器は多数のコネクションを維持しなければならない。1つまたは2つの供給側が使用される場合には、1つの供給側の故障はストリーミング品質に非常に重大な影響を及ぼすことになる。ストリーミングレートがR0である場合、ピア選択モジュール6110は、ピアiが≧R0/3を提供できる場合にはBi=1を割り当て、ピアが≧R0/4を提供できる場合にはBi=0.75を割り当て、これ以降は同様のことが繰り返される。
【0080】
3.CPU、記憶スペース(C)
STBが適当なCPUおよび記憶スペースを有する場合には、ピア選択モジュールはピアを受け入れることができる。ピア選択モジュールは、ピア状態がSERVINGまたはRECEIVINGでないときに、ピアiがCPU400MHz以上を有し、且つRAMが128MB以上であればCi=1を割り当てる。STBがストリーミングセッションに関与するためには十分なリソースを有していない場合にはCi=0である。
【0081】
4.信頼性記録(H)
信頼性記録Hは如何なる時点においてもスイッチオフされる可能性のあるSTBの信頼性を表す。STBのコンテンツはストリーミングセッション中に削除される可能性がある。したがってSTBの信頼性記録は復元力のあるストリーミングの提供に対して著しい影響を及ぼす。ピア選択モジュールは信頼性メトリクスに0〜1の値を割り当てる。
【0082】
5.供給側から受信器までのパス待ち時間(D)
待ち時間または一方向遅延を、供給側が受信器からどれほど離れているかを決定するために使用することができる。供給側が非常に良好なリソースを有しているとしても、ピアが世界の反対側に位置している場合には、安定したレートでストリーミングを提供することはできない。供給側が受信器の同一のサブネット内に存在するか、受信器が存在している同一の地理的なロケーション内に供給側が存在する場合、通常の場合待ち時間は実際に低く、またこれらの供給側は受信器から遠く離れて存在している供給側を上回る性能を有する。ピア選択モジュールは、ピアiが50ms以下の往復遅延時間(以下ではRTTと称する)の距離にある場合にはDi=1を割り当て、ピアiが100ms以下のRTTの距離にある場合にはDi=0.5を割り当て、ピアiが200ms以上のRTTの距離にある場合にはDi=0を割り当てる。
【0083】
6.パスのパケット損失比(L)
パケット損失比はネットワークの信頼性を表す。損失比の範囲は0<L<1である。
【0084】
7.公平性(F)
ピア選択メカニズムにおける第一の重要性はストリーミングの品質であり、したがってこのメカニズムは受信器に適したストリーミングセッションに関する最善のピアのセットを選択する。しかしながら、(リソース、信頼性および他のピア選択判定基準に関して)同等の品質を有する複数のピアを利用できる場合には、他のピアに比べて選択される頻度が低いピアに優先権が与えられる。
【0085】
上記の判定基準に基づき、ピア選択モジュールは各ピアの順位を計算することができる。Riがピアiの順位を表す場合にはRiを以下のように表すことができる:
Ri=CiSi(BiDi)Hi(1−Li)
ピア選択プロセスはこの順位に基づき上位のN+M個のピアを選択する。種々のピアが(N+M)番目の順位を有する場合には、ピア選択プロセスは公平性インデクス(F)が低いピアを選択し、全ての加入者はコンテンツアイテムを提供する機会を得て、またシステムから報酬を得る。
【0086】
図7はピア選択順位方程式のグラフであり、また使用されるピア選択判定基準にしたがいピアの順位をどのように変更できるかを示す。例えば、図7には高帯域幅(例えば384Kbps以上のアップリンク帯域幅)のピアの順位および低帯域幅(例えば128Kbps以上のアップリンク帯域幅)のピアの順位が遅延および損失のメトリクスに関してプロットされている図示されているように、受信器から遠く離れて位置する高帯域幅のピアは受信器の近くに位置する低帯域幅のピアに比べて低い順位を有する可能性がある。
【0087】
ネットワーク内のコンテンツを検索している間に、リソース管理フレームワーク(RMF)630(図6を参照されたい)はコンテンツを有するピアの長いリストを戻すことができる。ピア選択アルゴリズムを検索結果の全体のリストに適用できない可能性がある。例えば、提供に従事しているピアまたはアップリンク容量が低いピアまたは地理的なロケーションにおいて遠く離れているピアを放棄することによって初期リストをフィルタリングすることはより効率的である。ピア選択アルゴリズムを実施するためにフィルタリングされたリストから例えば15〜20のピアのセットが使用され、また選択シーケンスはアップリンク容量および地理的なロケーションを基礎とする。ピア選択に必要とされる測定を初期バッファリング時間中に実際のメディアデータを用いて実施することができる。例えば、最初の10秒間に各ピアは供給側の品質を求めるためにメディアファイルの一部を提供することができる。
【表1】
【0088】
ストリーミングセッションに関してどれほど多くの能動的なピアが要求されているかを求めるために、ピア選択モジュールは次式を使用することができる。
【数2】
ここで、目標のストリーミングレート=R0
能動的なピアの数=N
ピアiによって提供されるレートi=R0i
ピアiからの初期ストリーミングレートRi=βR0i(但しβは容量利用度。0<β≦1であり、ピアiは100%の容量利用度以下で動作する)
FECオーバヘッド=α
FECによるパケット損失許容度=α/(1+α)
【0089】
一例として、ストリーミングレートが1.1Mbpsであり、α=0.20FECである場合、要求されるストリーミングレートは1.32Mbpsである。各ピアはアップリンクストリーミング帯域幅R0i=256Kbpsを有するようになる。β=0.8である場合にはRi=248である。したがってN=7であり、ピア選択モジュールは5〜7個の能動的なピアをそれらのピアの出力帯域幅に基づき選択することができる。
【0090】
図6を再び参照し、さらには図8を参照しながら、特定の実施形態によるストリーム管理モジュール6120を説明する。図8はV2P受信器のブロック図を示し、また本発明の1つの実施形態によるストリーム管理モジュールを示す。図8によれば、受信器810はストリーム管理モジュール8120および再生モジュール8130を有する。特定の実施形態によれば、ストリーム管理モジュール8120はストリームモジュール8121、受信データモジュール8122(この実施形態においては受信データ/FECデコードモジュール8122として示されている)、バッファ管理モジュール8123、コネクション監視モジュール8124および動的レート分布モジュール8125を有する。
【0091】
動作時に、ストリームモジュール8121は全ての能動的な供給側との制御コネクションおよびデータコネクションを開閉し、またデータブロックのどの部分をどのデータレートで送信するかを指示する制御パケットを能動的な供給側に送信する。この実施形態においては受信データ/FECデコードモジュール8122として示されている受信データモジュール8122は能動的な供給側からストリーミングデータを受信し、このストリーミングデータをデコーディングし、デコーディングされたストリーミングデータをバッファ管理モジュール8123に転送する。バッファ管理モジュール8123はデコーディングされたストリーミングデータを受信データモジュール8122から受信し、ユーザが一時停止、早送り、巻き戻しを行えるように再生モジュール8130と対話し、またバッファを管理し、さらにはバッファが一杯ではなく、且つ空でないことを保証するために動的レート分布モジュール8125と対話する。コネクション監視モジュール8124は、いずれかのコネクションに輻輳が生じていないか否か、またはいずれかの供給側が故障していないか否かを検出するために能動的な供給側と受信器との間のコネクションを監視し、またネットワークの不安定性およびデバイス故障が生じる場合には動的レート分布モジュール8125と対話する。動的レート分布モジュール8125はバッファ管理モジュール8123およびコネクション監視モジュール8124と対話し、またネットワークの不安定性およびデバイス故障に対処するためにストリーミングレートを能動的な供給側に動的に分布する。
【0092】
ストリームモジュール8121は全ての能動的な供給側との制御コネクションおよびデータコネクションを開閉する。ストリームモジュール8121は、各供給側との1つの制御コネクションを開くことによって能動的なセットにおける全ての供給ピアとの通信を確立し、また理想的には、制御コネクションは信頼性が高いものであることが期待される。例えば、伝送制御プロトコル(TCP)を使用することができる。またストリームモジュール8121は各供給側に受信器とのデータパスの確立に関する制御情報をシグナリングする。またストリームモジュール8121はデータブロックのどの部分がどのデータレートで送信されるかを指示する制御パケットを能動的な供給側に送信する。これは能動的な供給側間でのストリーミングレートの動的なレート分布をなす。制御パケットは送信すべきブロックの小部分およびデータレートを表す。レート分布は動的レート分布モジュール8125に由来する。
【0093】
この実施形態においては受信データ/FECデコードモジュール8122として示されている受信データモジュール8122は能動的な供給側からストリーミングデータを受信し、このストリーミングデータをデコーディングし、デコーディングされたストリーミングデータをバッファ管理モジュール8123に転送する。受信データモジュール8122はストリームモジュール8121によって全ての能動的な供給側からデータを受信することが指示され、また能動的な供給側はこのモジュールとのデータパスを確立する。特定の実施形態によれば、V2Pはデータストリーミングに関してユーザデータグラムプロトコル(UDP)のようなプロトコルを使用することができる。択一的に別の実施形態においては、V2PはUDPを基礎とするあらゆる輻輳制御プロトコル、例えばデータグラム輻輳制御プロトコル(DCCP)などを使用することができる。ストリーミングデータの受信に基づき、受信データモジュール8122はこのストリーミングデータをバッファ管理モジュール8123に引き渡す前にデコーディングを行う。ブロックのデコーディングには、受信した部分またはセグメントからのFECエンコーディングされたブロックの再構築、再構築されたFECエンコーディングされたブロックのFECデコーディング、また使用される特定のビデオエンコーディングスキーマ(例えばMPEG)に応じたFECデコーディングされたブロックのさらなるデコーディングが含まれることを言及しておく。
【0094】
バッファ管理モジュール8123はデコーディングされたストリーミングデータを受信データモジュール8122から受信し、ユーザが一時停止、早送りおよび巻き戻しを行えるよう再生モジュール8130と対話する。バッファ管理モジュール8123はバッファを管理し、またこのバッファが一杯ではなく、且つ空でないことを保証するために動的レート分布モジュール8125と対話する。例えば、ユーザがストリーミングセッションを一時停止するためにボタンを押すと、バッファ管理モジュール8123はストリーミングレートを調整するために動的レート分布モジュール8125と対話する。またバッファ管理モジュールはメディアデータを再生するためにバッファには常にデータが存在することを保証する。例えば、再生は初期バッファリング時間(例えば10秒)または短い宣伝の直後に開始することができる。その後、バッファ管理モジュール8123は目下の再生レートおよびストリーミングレートにより近い将来バッファは空にならないか、またはオーバーフローしないかを周期的に評価する。必要に応じて、動的レート分布モジュール8125によりストリーミングレートを相応に調整することができる。
【0095】
図9は、本発明の1つの実施形態により、動的バッファ管理技術がバッファオーバーフローまたはアンダーフローをどのようにして回避することができるかを表すグラフを示す。このグラフにおいて、B(t)は時間tにおいてバッファに記憶することができる最大累積データを表し、P(t)は時間tにおいて再生器によって消費される累積データを表す。このグラフから見て取れるように、固定ビットレート(CBR)のストリーミングレートはバッファオーバーフローまたはバッファアンダーフローを容易に引き起こす可能性がある。動的バッファ管理アルゴリズムはストリーミングレートを周期的に調整することによってこれらのシナリオを回避する。
【0096】
例えば、固定ビットレート(CBR)のストリーミングレートは、バッファが将来オーバーフローしないこと、もしくは空にならないことを保証することができない。何故ならばネットワーク状態は変化し、またピアがあらゆる時点において故障する可能性があるからである。したがって、複数のパラメータに基づきストリーミングレートを調整する動的バッファ管理技術を使用することができる。このパラメータの例として以下のものが挙げられる:
a)目下のバッファサイズ
b)目下の再生レート
c)目下のストリーミングレート
【0097】
図10は、本発明の1つの実施形態によるバッファ管理スキーマを表すグラフを示す。図示されているように、バッファは3つの部分、すなわち加速ゾーン(0<バッファサイズ<Bmin)、快適ゾーン(Bmin<バッファサイズ<Bmax)、減速ゾーン(バッファサイズ>Bmax)に分割されている。BminおよびBmaxの値はシステムにおける許容バッファサイズに依存する。例えば、システムが30秒のバッファリングを有することができる場合には、Bmin=10秒およびBmax=20秒を選択することができる。ストリーミングレートは目下のバッファサイズならびに、目下のストリーミングレートおよび再生レートを使用して計算されるバッファの変化に基づき調整される。目下のバッファサイズがBmin以下であり、且つバッファサイズの変化が負である場合には、ストリーミングレートが高められる。ストリーミングレートは快適ゾーンにおいては変化しない。バッファサイズがBmaxを上回る場合には、ストリーミングレートが低められる。
【0098】
レートを計算して目下のストリーミングレートを調整するために、バッファ管理モジュール8120はその時点におけるストリーミングレートの指数加重移動平均(EWMA)を使用する。一般的にEWMAは次式のように表される:
Ravg(t)=wR(t)+(1−w)Ravg(t−1)
ここで、0<w<1は目下のその時点におけるサンプルまたは最近の記録を重み付けするための定数である。
【0099】
例えば、バッファ管理モジュールはバッファサイズの各ゾーンに関してwを規定する。バッファが加速ゾーンにおいて動作している場合には、ストリーミングレートを調整するために、その時点におけるストリーミングレートが強調されなければならない。したがってこのゾーンにおいてはwに比較的高い重みが与えられている。バッファが快適ゾーンにおいて動作している場合には、平滑なストリーミングレートを計算するためにwには比較的低い重みが与えられており、これは減速ゾーンにおいてストリーミングレートを調整するために使用することができる。減速ゾーンにおいては、ストリーミングレートをより積極的に減速するためにαに高い重みが与えられている。
【0100】
図8を再び参照すると、コネクション監視モジュール8124は、いずれかのコネクションに輻輳が生じていないか否か、またはいずれかの供給側が故障していないか否かを検出するために能動的な供給側と受信器との間のコネクションを監視し、またネットワークの不安定性およびデバイス故障が生じる場合には動的レート分布モジュール8125と対話する。コネクション監視は、供給側から受信器へのいずれかのデータパスに輻輳が生じていないか否か、またはいずれかのピアが故障していないか否かを検出するための有用なメカニズムである。例えば、受信器が特定の時間枠の間に所定のピアから何のデータも受信しない場合には、ピアがもはや生きていないことが想定される。
【0101】
ネットワーク輻輳の個所を厳密に特定することは比較的困難である。ネットワーク輻輳の個所が既知である場合には、品質適合モジュール(図6の項目6140)は供給側と受信器との間の各コネクションをどのように処理するかを決定することができる。例えば、1つのコネクションしかネットワーク輻輳の影響を受けない場合には、他のコネクションはこの輻輳を克服するためにより高いレートでデータを提供することができる。しかしながら、コネクションの大部分に同時に輻輳が発生している場合には、バックアップ的なピアのセットからピアを付加し、それらのピアからの付加的なストリーミングにより輻輳の効果を緩和させることが必要となる。
【0102】
コネクション監視モジュール8124は輻輳が生じているパスセグメントを識別するためにネットワークトモグラフィ技術を使用することができる。ネットワークトモグラフィの基本的な思想にはパケット「ストライプ」(すなわちバック・ツー・バック検査パケット)の使用が含まれ、このパケット「ストライプ」は目的地におけるストライプ内のパケット損失の相関を計算することによってリンク損失が推測される。損失を推測するために、ストライプと称される一連の検査パケットが1つのノードから0伝送遅延を有する他の2つのノードに送信される。パケットがいずれかの受信器に到達すると、このパケットが分岐点に到達していなければならないことを推測することができる。エンドホストに到達したパケットの数に基づき、全ての内部リンクに関する伝送成功確率を計算することができる。
【0103】
コネクション監視モジュール8124はコネクションを受動的に監視する。すなわち、ストリーミング中に能動的な検査は行われない。コネクション監視モジュール8124はストリーミングデータを使用する。複数の供給側から1つの受信器へのデータが生じるのではなく、むしろ幾つかのネットワークトモグラフィ技術においては1つのソースから複数の受信器へのデータが生じる。
【0104】
受信器が共有パスならびに固有のパスにおけるパケット損失の相関を取得できるようにするために、必要に応じて、適切なストライプのサイズを評価し、また供給側間においてパケットをどのように分割するかについての実験が実施される。供給側から受信器へのパスの特性を評価することもできる。図11は、2つの供給側S1およびS2から1つの受信器Rへの単純なバイナリツリーを示す。供給側はブロックのパケットを送信するために時間と同期されているので、S1およびS2からのパケットが共有パスセグメントk→Rにおいて同様の輻輳を経験する確率が高い。D(D=<D1,D2>)個のパケットのストライプを使用することができ、ここではS1がD1個のパケットを送信し、またS2がD2個のパケットを送信する。RがS1からのストライプの全てのパケットを取得すると、S2→kにおいてパケットが損失しない限り、RはS2からのD2個のパケットを受信する確率が高い。
【0105】
図8を再び参照すると、動的レート分布モジュール8125はバッファ管理モジュール8123およびコネクション監視モジュール8124と対話し、また輻輳およびデバイス故障に起因するネットワークの不安定性に対処するためにストリーミングレートを能動的な供給側に動的に分布する。
【0106】
動的レート分布モジュール8125は目下のストリーミングレートを何時でも変更することができる。ストリームモジュール8121は、新たなレートを規定するために制御信号を各時間枠に各能動的な供給側へ送信するコネクション監視モジュール8124はどのコネクションに輻輳が生じているかを検出し、バッファ管理モジュール8123は目下のストリーミングレートはどのようであるべきかを検出し、また動的レート分布モジュール8125は時間tにおいて各供給側がストリーミングを行うべきレートを検出する。続いて、ストリームモジュール8121は各供給側に制御パケットを送信し、新たなレートおよびファイルセグメントの新たなインデクスで供給側は次の時間枠において送信を行うべきことを通知する。
【0107】
図8を参照しながら、ここでは再生モジュール8130として示されているインタラクティビディ管理モジュールを特定の実施形態にしたがい説明する。再生モジュール8130はインタラクティビティを提供するので、ユーザはストリーミングセッションを一時停止、早送り(FF)および巻き戻し(RW)することができる。以下において詳細に説明するこれらの各イベント中に、再生モジュール6130はこのイベントに基づき適切な動作を実施するバッファ管理モジュール8123に情報を通知する。
【0108】
先ず一時停止に関する制御を説明する。ユーザがストリーミングセッションを一時停止するためにボタンを押すと、バッファ管理モジュール8123は動的レート分布モジュール8125に新たなストリーミングレート、例えば0Kbpsを分布することをシグナリングする。動的レート分布モジュール8125はストリームモジュール8121にストリーミングセッションを一時停止することをシグナリングする。ストリームモジュール8121は制御信号を各能動的な供給側に送信し、ストリーミングセッションが再開されるまで、または一時停止時間が経過するまで、ストリーミングセッションは一時停止される。ストリーミングセッションが一時停止されている間、受信器は能動的な供給側からのいかなる付加的なストリーミングデータも要求しない。ストリーミングセッションが再開されると、ストリームモジュール8121はストリーミングセッションを再開するために制御信号を各能動的な供給側に送信する。一時停止時間が経過すると、ストリーミングセッションは閉じられる。
【0109】
次に早送り(FF)および巻き戻し(RW)に関する制御を説明する。受信器が局所的な記憶装置、例えばハードディスクを有している場合には、RW動作は既に記憶されているコンテンツに基づき実施される。そうでない場合には、RWおよびFFを同様のやり方で実施することができる。複数のアプローチをFF動作に関連付けることができる。1つ目のアプローチはVCRのような平滑なインタラクティビディを提供するために別個のインタラクティブストリームを使用する。しかしながら、各メディアファイルに対して別個のインタラクティブストリームが要求されることになる。2つ目のアプローチは、付加的なストリームを使用せずに探索メカニズムを用いて早送りまたは巻き戻しを達成するソリューションである。
【0110】
殊に、インタラクティブストリームを使用する場合には、FF動作は別個のストリーム(すなわちインタラクティブストリーム)および別個のバッファ(すなわちインタラクティブバッファ)を要求する。巻き戻し動作に関して、インタラクティブストリームは再生ストリームとは逆の順番で形成される。早送りおよび巻き戻しの間に供給側はストリームの1つのサブセットしか送信できず、オリジナルのストリームを送信しないので、別個のインタラクティブストリームが要求される。別個のインタラクティブストリームが使用されなければ、供給側はストリームをデコーディングし、関心のある適切なフレームを送信しなければならなくなる。それらをリアルタイムで達成することは不可能であろう。したがって、この技術は目標のFF速度またはRW速度を達成することができるフレームを有する別個のストリームを使用する。例えば、Xの加速係数を達成するために、再生器はXフレーム以外の1つを要求する。しかしながらMPEG技術においては、Iフレームおよび/またはPフレーム無しではBフレームをデコーディングすることができず、また先行のIフレームまたはPフレーム無しではPフレームをデコーディングすることができない。したがって、Xフレーム以外の1つを送信しても早送りイベントにとっては十分ではない。
【0111】
図12は、ストリーミングセッションの一連のMPEGフレームを示す。加速係数5を得るためには、供給側はI,(P,B,B,P),(I,B,B,P)〜を送信する必要がある。何故ならば、Bフレームはデコーディングのために自身に隣接するフレームを両方とも必要とし、またPフレームは先行のIフレームまたはPフレームを必要とするからである。したがって、ストリームを5倍加速させるためには、フレームの1/5以上が供給側によって送信されなければならない。その結果このプロセスによりFFおよびRW中のストリーミングデータレートは高まる。ところが、DSLベースのネットワークにおけるストリーミングデータレートを高められない可能性がある。このDSLベースのネットワークではダウンリンク速度が通常のストリーミングレートに対してのみ有効であることが多い。
【0112】
FFおよびRW中の比較的低いデータレートを維持するために、特定の実施形態によればインタラクティブストリームを使用することができる。インタラクティブストリームを以下のように生成することができる。オリジナルのビデオマテリアルは圧縮の前にサブサンプリングされなければならない。X倍の早送り速度に関して、各X番目のビデオフレームはMPEGエンコーディングの前に適切なデバイスに記憶されなければならない。例えば4倍の早送り速度を達成するためには、各4番目のビデオフレームが使用される。このコンテンツは通常のやり方でMPEGエンコーディングされ、別個のファイルに記憶される。この方法により動きが非常に滑らかな非常に高品質のFFの視聴が実現されるが、サブサンプリングされた非圧縮のビデオの中間的な記憶が要求される。
【0113】
サブサンプリング前処理および中間的な記憶という付加的な作業を回避するために、特定の実施形態によればMPEG圧縮領域においてFFを達成することができる。各送信器はFF中の要求を処理するために動的にIフレームをトランスコーディングし、Iフレームを1つだけ有するGOP(Group of Pictures)を生成するために、このトランスコーディングされたIフレームをシーケンスヘッダに含ませる。そのようなスキーマを実施するために、各送信器はIフレームをオン・デマンドでトランスコーディングできなければならない。
【0114】
図8を再び参照すると、インタラクティビディを提供するためにバッファ管理モジュール8123は2つのバッファ、すなわち標準的なストリーム用のバッファおよびインタラクティブストリーム用のバッファを維持する必要がある。標準的な再生が行われている間はユーザがFFまたはRWを選択できるようにバッファ管理モジュール8123はIフレームのみをインタラクティブバッファに置き、再生モジュール8130はインタラクティブバッファからデータを即座に受信する。バッファ管理モジュール8123は、ユーザが通常の再生モードに戻るまで再生器にインタラクティブバッファからデータを供給する。ストリームモジュール8121は、この期間中にインタラクティブストリームからのデータを送信するよう各供給側に制御信号を送信するN個のIフレームが既にインタラクティブバッファに存在するので、各供給側は1つのIフレームを送信する。ユーザは1つのIフレームから次のIフレームに早送りすることができる。インタラクティブバッファにデータが存在しない場合には、再生モジュール8130はユーザによるFF/RWを許可せず、通常の再生を再開する。ユーザが通常の再生を再開すると、バッファ管理モジュール8123は標準バッファから再生モジュール8130にデータを供給する。標準バッファが通常の再生のために十分なデータを有していない場合には、標準バッファがフルレートでの再生のために十分なデータを有するまで数秒にわたりサブサンプリングされたデータを再生することができる。
【0115】
特定の実施形態によれば、FF動作およびRW動作をシミュレートするための択一的なアプローチにおいて、特定のインタラクティブストリームを有するという要求を回避するためにファイル探索が使用される。殊に、ユーザがFFまたはRWボタンを押すと、再生モジュール8130はX秒のビデオデータを再生し、次いで加速を達成するためにファイル内の適切な位置へとY秒ジャンプする。全ての供給側はX秒に対応するビデオデータを提供し、次のビデオデータを取り出すためにファイル内をY秒探索する。
【0116】
特定の実施形態によれば、XおよびYの値を設定することによって可変の加速を達成することができ、また加速係数を次式に従い計算することができる:
【数3】
例えば、X=2秒且つY=6秒であれば、加速係数は4である。
【0117】
再生モジュール8130が通常の速度でビデオデータを再生すると、ストリーミングデータ内の一時的な位置がジャンプに起因して前進するが、ユーザは加速係数を認識しない。したがって再生モジュール8130は通常の速度よりも速い速度でビデオデータを再生する。例えばDSLネットワークにおいては加速を行えない可能性があるので、供給側が標準ストリーミングレートでストリーミングデータを送信し続けると、バッファはより高速な再生レートに起因して空になる可能性がある。この問題を解決するために、再生モジュール8130は受信器に局所的に記憶されている短いビデオクリップを再生することができる。短いビデオクリップをストリーミングデータのブロック間のバッファに挿入することができる。例えば、挿入されたビデオクリップはFFまたはRWイベントに基づいた動画化された「>>」または「<<」でよい。そのような短い動画化されたビデオクリップは、システムが幾つかの処理を実行していることを視聴者に知らせることができる。そのようなビデオクリップをストリーミングする必要がないように、ビデオクリップを受信器側において予め生成して記憶することもできる。
【0118】
図13は、一連のビデオデータおよび挿入されたビデオクリップを示す。図示されているように、再生モジュール8130は挿入されたビデオクリップが続く4秒のビデオクリップを再生し、12秒ジャンプし、挿入されたビデオクリップが続く4秒のビデオクリップを再生し、さらに12秒ジャンプし、また4秒のビデオクリップを再生する。再生モジュール8130は通常の速度の2倍の速度でビデオデータおよびビデオクリップを再生する。この実施例において、X=4,Y=12且つ挿入されたビデオクリップの長さがX=4である場合には、加速係数は次式により与えられる。
【数4】
【0119】
上述したようなブロードバンドデータの受信に関してデータストリーミングの品質を改善するために使用される本発明の1つの態様は品質適合を含む(図6に示されているような品質適合モジュール6140を使用し、また図8に示されているようなストリーム管理モジュール8120を参照する)。品質適合は、復元力があり且つ高品質のストリーミングの提供にとって重要な要素である。ストリーミング品質はネットワークの不安定性およびデバイス故障が生じている間に劣化する。両方の問題に対処するために、V2Pは以下のようなメカニズムを使用する:
a)インテリジェントなバッファ管理
b)コネクション監視
c)動的なレート分布
d)動的なFECエンコーディング/デコーディング
e)能動的なピアの選択(N個の能動的なピア)
f)バックアップ的なピアの選択(M個のバックアップ的なピア)
【0120】
最初の2つのメカニズムはエラー状態を検出し、輻輳の現在の箇所を識別するために使用される。残りの4つのメカニズムはネットワークの不安定性およびデバイス故障に対処するために使用される。これらの2つのシナリオを説明する。場合によっては、品質適合モジュール6140はそのような状況に対処するためにストリーミングデータの再供給を能動的な供給側に要求することができる。
【0121】
ネットワークの不安定性に対処するための品質適合プロセスを特定の実施形態にしたがい説明する。インターネットはベストエフォートサービスであり、いずれかのエンド・ツー・エンドパスの待ち時間、損失およびジッタのようなネットワークレイヤメトリクスは時間毎に変化する可能性がある。コネクション監視メカニズムはネットワークの輻輳の現在の箇所を識別することができる。例えば、K個のコネクションには何時でも品質的な劣化が生じるものとする。先ず、品質適合モジュール6140はストリーミングレートの合計が目標のストリーミングレートにまだ達していないか否かを検査する。このような条件が満たされていない場合には、良好なネットワーク状態を有する能動的な供給側が他の能動的な供給側によっては供給されないレートを調整するためにより一層供給するために、ストリーミングレートは再分布される。そのような動的なレート再分布は、能動的な供給側がその完全な容量よりも低いレートでストリーミングを行うように能動的なピアの選択が行われるので可能である。残りの超過容量を、各能動的な供給側からのストリーミングレートの動的な再分布に使用することができる。能動的な供給側が目標のストリーミングレートを提供できない場合、品質適合モジュール6140はピア選択モジュール6110に1つまたは複数のバックアップ的なピアを能動的なセットに付加することを指示することができる。全てのバックアップを付加した後に、能動的な供給側が高パケット損失のために依然として目標のストリーミングレートを提供できない場合は、品質適合モジュール6140はストリーム管理モジュール6120にFECエンコーディング・オーバヘッド比(α)を目下の損失率を基礎として高めることを指示する。例えば、α=0.20であり、且つ目下の損失率が35%である場合、αの新たな値は将来の変更に耐えるために損失比に適合するよう調整される。損失比が暫くして下がると、適合モジュールは相応にαの値を下げる。
【0122】
例として、品質適合モジュール6140は、ネットワークの不安定性に対処するためにストリーミングレートを調整し、バックアップ的なピアを付加し、またエンコーディング・オーバヘッド比αを調整するために使用することができるアルゴリズム(アルゴリズム1)を説明する。図示されているアルゴリズムは、目下のストリーミングレートが目標ターゲットレートR0よりも僅かに高いことを保証するためにδを使用し、さもなければ僅かなネットワーク不安定性を有し、ストリーミング品質は低下することになる。ラプタ符号(Raptor code)が使用される場合、δはラプタデコーディングのために必要とされる余剰データを表す。何故ならば、この符号はデコーディングのために本来のコンテンツよりも5%多いデータを要求するからである。
【0123】
【数5】
【0124】
特定の実施形態によるこのアルゴリズムにおいては、ステップ1において、ストリーム管理モジュール6120のコネクション監視モジュール(例えば図8のコネクション監視モジュール8124)はN個の能動的な供給側を有するN個のコネクションを監視し、また時点tにおいて輻輳が生じているK個のコネクションを識別する。ステップ2においては、目下の合計ストリーミングレート(すなわち全てのRiの和)が少なくともδだけ目標ストリーミングレートR0を上回る場合、すなわち
【数6】
である場合、目下のストリーミングレートは十分なものであるので、品質適合モジュール6140は何もしない。さもなければ、品質適合モジュール6140はステップ3において輻輳が生じていない能動的なセットにおける(N−K)個の「良好な」ピア間でのストリーミングレートの再分布を試みる。
【0125】
これらの(N−K)個の「良好な」ピアはそれらの完全な容量よりも低いレートで最初にストリーミングし、これらの(N−K)個の「良好な」ピアの残りの超過容量を目標のストリーミングレートR0を達成するために使用することができる。すなわち、(N−K)個の各「良好なピア」をその完全な容量R0iまでのレートでストリーミングすることができる。したがって、輻輳が生じているK個のピアに関する目下の合計ストリーミングレート(すなわち、これらのK個のピアに関する全てのRiの和)に(N−K)個の「良好なピア」の完全な容量(すなわち、これらの(N−K)個のピアに関する全てのR0iの和)を足した合計が少なくともδだけ目標のストリーミングレートR0を上回る場合、すなわち、
【数7】
の場合、品質適合モジュール6140はストリーム管理モジュール6120に(例えば、動的レート分布モジュールを介して)、目標ストリーミングレートを達成するために(N−K)個の良好なピアにストリーミングレートを再分布することを指示する。さもなければステップ4において、品質適合モジュールはピア選択モジュール6110に、能動的な供給側の更新された数Nが存在するために、能動的なピアのセットにバックアップ的なピアを付加することを指示する。
【0126】
アルゴリズムはステップ3に戻り、品質適合モジュール6140はストリーム管理モジュール6120に(例えば動的レート分布モジュールを介して)、目標ストリーミングレートを達成するために(N−K)個の良好なピアにストリーミングレートを再分布することを指示する。ステップ4において、利用できるバックアップ的なピアが存在しない場合には、品質適合モジュール6140はネットワークにおけるパケット損失を調整するためにエンコーディング・オーバヘッド比αを調整する。品質適合モジュール6140はまたピア選択モジュール6110に、バックアップ的なピアのセットに付加するための付加的なピアを選択することを指示する。
【0127】
別の態様はデバイス故障に対処するための品質適合プロセスである。殊に特定の実施形態によれば、ストリーミングセッションはN個の能動的なピアで始まり、各ピアはβの容量利用度を有する。V2Pは、ピアのうちの1つ(すなわちSTBのうちの1つ)が故障している場合には、ピアのアップロード容量限界を上回ることなく能動的なセット内の残りのピアにストリーミングレートを即座に再分布できるようにβを選択する。したがって、1つのピアがいずれかの時点に故障すると、ストリーミングレートが残りの能動的な供給側にわたり再分布され、合計ストリーミングレートは目標レートを下回らない。2つまたはそれ以上のピアが同時に故障すると、品質適合モジュールは能動的な供給側にバックアップ的なピアを付加することができる。
【0128】
例として、品質適合モジュールは、デバイス故障に対処するためにストリーミングレートを調整し、バックアップ的なピアを付加し、またエンコーディング・オーバヘッド比αを調整するために使用することができるアルゴリズム(アルゴリズム2)を特定の実施形態にしたがい説明する。K個のデバイス(すなわちSTB)が故障すると、品質適合モジュール6140はストリーム管理モジュール6120に(例えば動的レート分布モジュールを介して)、能動的なセットにおける残りの供給側間でストリーミングレートを再分布することを指示する。品質適合モジュール6140はまたピア選択モジュール6110に、次のデバイス故障に取り組むために能動的な供給側のセットにバックアップ的なピアを付加することを指示する。能動的なセット内の残りの供給側が目標のレートを提供できず、且つネットワークにおいて高い損失が発生していない場合は、品質適合モジュール6140はストリーム管理モジュール6120に、目下の損失率を調整するためにFECエンコーディング・オーバヘッド比αを下げることを指示する。より多くの供給側が必要とされる場合、品質適合モジュール6140はピア選択モジュール6110に、バックアップのセットに付加的な供給側を付加することを指示する。バッファ管理モジュールは典型的に、再生モジュールが利用できるデコーディングされた5〜10秒のデータを維持し、この場合、品質適合モジュール6140は目標ストリーミングレートを達成するために、能動的なセットにより多くのバックアップ的な供給側を付加することができる。
【数8】
【0129】
上述したように、ステップ1においてはコネクション監視モジュールがK個の故障したSTBを識別する。ステップ2においては、能動的なセットにおける残りの供給側の目下の合計ストリーミングレート(すなわち全てのRiの和)が少なくともδだけ目標ストリーミングレートR0を上回る場合、すなわち
【数9】
である場合、目下のストリーミングレートは十分なものであるので、品質適合モジュール6140は何もしない。さもなければ、品質適合モジュール6140はステップ3において故障していない能動的なセットにおける(N−K)個の「良好な」ピア間でのストリーミングレートの再分布を試みる。これらの(N−K)個の「良好な」ピアはそれらの完全な容量よりも低いレートで最初にストリーミングし、これらの(N−K)個の「良好な」ピアの残りの超過容量を目標のストリーミングレートR0を達成するために使用することができる。すなわち、(N−K)個の各「良好なピア」をその完全な容量R0iまでのレートでストリーミングすることができる。したがって、(N−K)個の「良好なピア」の完全な容量(すなわち、これらの(N−K)個のピアに関する全てのR0iの和)が少なくともδだけ目標のストリーミングレートR0を上回る場合、すなわち、
【数10】
の場合、品質適合モジュール6140はストリーム管理モジュール6120に(動的レート分布モジュールを介して)、目標ストリーミングレートを達成するために(N−K)個の良好なピアにストリーミングレートを再分布することを指示する。品質適合モジュール6140はピア選択モジュール6110に、能動的なセットにバックアップ的なピアを付加することを指示する。
【0130】
さもなければステップ4において、品質適合モジュール6140はピア選択モジュール6110に、能動的な供給側の更新された数Nが存在するために、能動的なピアのセットにバックアップ的なピアを付加することを指示する。ステップ4において、利用できるバックアップ的なピアが存在しない場合には、品質適合モジュール6140はネットワークにおけるパケット損失を調整するためにFECエンコーディング・オーバヘッド比αを調整することができる。品質適合モジュール6140はストリーム管理モジュール6120に(例えば動的レート分布モジュールを介して)、目標ストリーミングレートを達成するために能動的なセットにおける(N−K)個の良好なピアにストリーミングレートを再分布することを指示する。品質適合モジュール6140はまたピア選択モジュール6110に、バックアップ的なピアのセットに付加するための付加的なピアを選択することを指示する。
【0131】
図6を再び参照し、特定の実施形態によるコンテンツ検索およびコンテンツ推薦モジュール6150を説明する。コンテンツ検索およびコンテンツ推薦モジュールによりユーザは自身が関心を持つコンテンツを検索することができる。ユーザインタフェース(UI)によりユーザは以下のような電子番組表(EPG)データに基づきコンテンツを検索することができる:
a)タイトル、
b)俳優/女優
c)監督、
d)年、
e)国、
f)ジャンル、
g)賞、
h)スポーツ、TVドラマ、ニュース、コンサートなどのカテゴリ
i)物語における何らかのキーワード
【0132】
参照モジュール6160は、動作の以下の詳細を前提として、ピアに関する情報の取得を容易にする。参照モジュール6160は、STBのリソース情報、例えばCPU、メモリおよびアップストリーム帯域幅を参照するために遠隔のピアに試験を送信する。この試験は、例えばピアが目下アップロードまたはダウンロードを行っているか、もしくはアイドルモードであるかのような状態情報およびピアの信頼性記録の参照でよい。参照モジュール6160はピアのインセンティブ記録を戻すことができ、このインセンティブ記録をピア選択モジュール6110によるピア選択の間の公平性を調べるために使用することができる。
【0133】
データ管理に関して、データ管理モジュールはストリーミングされたデータをハードディスクのような局所的な記憶装置に記憶することができる。例えばUDPを使用して信頼性のないチャネルを介してストリーミングが行われると、セッション中に幾つかのパケットが失われる可能性がある。受信器はFFメカニズムの使用に基づき全てのパケットを有している必要はない。したがってデータ管理モジュール6170は、受信器が将来において供給側となるべく完全なファイルを有するために、ストリーミング後に能動的な供給側と接触し、それらの失われたセグメントをダウンロードすることができる。
【0134】
供給側がどのように動作するかを理解するために、図14はV2Pシステムのブロック図を示し、またさらに本発明の1つの実施形態による送信器(供給側)を示す。図14によれば、V2Pシステム1400は受信器1410、送信器1420、リソース管理フレームワーク(RMF)1430、インセンティブマネージャ1440および電子番組表(EPG)1450を有する。受信器1410はストリーミングデータを受信するために送信器1420と対話する。送信器1420はRMF1430と対話し、V2Pシステムにコンテンツを登録および通知する。送信器1420はインセンティブマネージャ1440と対話し、このインセンティブマネージャ1440はユーザへの課金および適切なエンティティへの報酬の付与に対して責任を有する。送信器1420は電子番組表(EPG)1450と対話し、これによりパーソナルビデオレコーダ(PVR)拡張を使用したコンテンツの記録が可能になる。
【0135】
図14によれば、送信器1420はさらに特定の実施形態にしたがい、登録モジュール14210、ストリーミング管理モジュール14220、FECエンコーディングモジュール14230、リソース監視モジュール14240およびPVR拡張モジュール14250を有する。登録モジュール14210はSTBのリソースおよび統計を登録し、またp2pネットワークにコンテンツを通知する。ストリーミング管理モジュール14220はデータを提供し、また制御信号を受諾するために受信器と通信する。FECエンコーディングモジュール14230はコンテンツアイテムに対応するメディアファイルにおけるブロックをFECエンコーディングする。リソース監視モジュール14240はSTBの目下の状態に基づき要求された新たなストリーミングを受諾または拒否する。またこのリソース監視モジュール14240はストリーミングセッションに寄与した後にインセンティブマネージャ1440に報告を行う。PVR拡張モジュール14250は電子番組表(EPG)1450と対話する。
【0136】
登録モジュール14210はRMF1430を介してp2pネットワークに自身のリソースおよび統計を登録する。またこの登録モジュール14210はp2pネットワークに新たなメディアコンテンツを登録、通知または宣伝する。
【0137】
ストリーミング管理モジュール14220はデータを提供し、また制御信号を受諾するために受信器と通信する。送信器が新たなストリーミング要求を受諾した後に、ストリーミング管理モジュール14220は受信器からの制御コネクションを受諾する。制御コネクションにしたがいストリーミング管理モジュール14220は受信器とのデータコネクションを確立し、例えばハードディスクのような局所的な記憶装置からデータを読み出し、またデータコネクションを介してデータを送信する。データが事前エンコーディングされており、且つ目下のエンコーディングされたコンテンツのFECエンコーディング・オーバヘッド比αが受信器から要求されたαと一致する場合には、ストリーミング管理モジュール14220は単にデータを読み出し、そのデータを受信器に送信する。新たなαを用いてデータをエンコーディングすることが必要である場合には、ストリーミング管理モジュール14220はFECエンコーディングモジュール14230と通信し、FECエンコーディングが実施される。
【0138】
FECエンコーディングモジュール14230はコンテンツアイテムに対応するメディアファイルのブロックをストリーミングのためにFECエンコーディングする。特定の実施形態によれば、V2Pが特定のFECエンコーディング・オーバヘッド比αを用いてメディアデータをエンコーディングするために使用することができる2つの例示的なFEC符号は広く公知のリード・ソロモン(Reed-Solomon)符号およびラプタ符号である。また別の実施形態においては、限定的なフィールドにわたるコーシー行列(Cauchy matrices)を基礎とし、また算術演算の代わりにXORを使用するリード・ソロモン消去符号(Reed-Solomon erasure code)は、慣例のリード・ソロモン符号を上回る高速なエンコーディングおよびデコーディングを達成するために使用することができる。
【0139】
表2は、特定の実施形態による、変更されたリード・ソロモン消去符号を使用する例示なエンコーディング時間およびデコーディング時間を示す。例えば、映画ファイルを1.1Mbpsで1秒のブロックまたは0.5秒のブロックに分割し、20%のパケット損失が許容されるようエンコーディングされる。エンコーディング時間およびデコーディング時間には典型的に、2GBメモリを備えた2.4GHzのLinuxマシンにおいてリード・ソロモン消去符号が実行されている。
【0140】
表2に示されているように、エンコーディングはデコーディングよりも時間を要する。さらには、エンコーディング時間およびデコーディング時間はブロックの長さに関して線形ではない。ブロックサイズが過度に大きい場合、受信器はブロックをデコーディングする前にブロックの全てのパケットを受信するために長時間待機しなければならない。ブロックサイズが過度に小さい場合、1つのコネクションにおける突発的なパケット損失により大量のパケットが落ち、他のコネクションからの残りのパケットはブロックを回復するのに十分なデータを有さなくなる。1Mbpsでのストリーミングに関しては、1秒のブロックサイズが典型的である。400MHz以上で実行するプロセッサおよび128MB以上のメモリを有するSTBは、ネットワークの不安定性およびデバイス故障を調整するためにリード・ソロモン符号を使用するオン・デマンドエンコーディングを支援することができる。
【表2】
【0141】
図14を参照すると、リソース監視モジュール14240は新たなストリーミング要求を受諾または拒否するかを決定するためにSTBの局所的なリソースおよび状態を監視する。また、PVR拡張モジュール14250は電子番組表(EPG)1450と対話し、イベントの記録の管理を調整する。
【0142】
図15は、V2Pシステムの性能を評価するための例示的なセットアップを示す。図15によれば、V2Pシステム1500は受信器1510、送信器1520、インターネットサービスプロバイダ(ISP)1580aおよび1580b(以下ではISP1580と称する)およびインターネット1590を包含する。受信器1510および送信器1520はそれぞれ受信器モジュールと送信器モジュールの両方を有するようにコンフィギュレーションすることができるので、これらは送信器としても受信器としても動作することができる。ここではパーソナルコンピュータとして示されている各受信器1510および送信器1520を2つの異なるISP1580を介してインターネット1590に接続することができる。送信器のセットを両方のISP1580から選択することができるので、ストリーミングデータはインターネット1590を介して流れ、また受信器1510はネットワークの不安定性を経験する。ストリーミングセッション中に、デバイス故障をシミュレートするために送信器1520のうちの1つまたは複数の電源を落とすことができる。
【0143】
特定の実施形態によれば、V2Pシステムを非対称ディジタル加入者線(ADSL)アクセスネットワークにおいて使用することができ、このネットワークにおいては各送信器が制限的なアップリンク容量を有し、またマルチ送信器ソリューションは送信器のセットからの全体のストリーミングレートを合計するために必要とされる。V2Pをより高い帯域幅のアクセスネットワーク、例えば20Mbps〜100Mbpsの範囲のアップリンク帯域幅を有するFTTxネットワークおよびxDSLネットワークにおいて使用するために実施することができる。特定の実施形態によれば、その種の環境においてV2Pは1.5Mbpsのストリーミング(MPEG−4品質のビデオストリームに相当)、それどころか3〜5Mbpsのストリーミング(MPEG−2品質のビデオストリームに相当)を送信するために複数の送信器を必要としない。1つの送信器が全体のストリーミングレートを容易に提供することができる。それにもかかわらず、特定の実施形態によれば、ネットワークの不安定性およびピアの故障が発生している場合には、復元力のあるストリーミングを提供するために、各ストリーミングセッションに関してバックアップ的なピアを使用することができる。このシナリオにおいては、V2Pの(N+M)個のストリーミングモデルが(1+M)になり、ストリーミングセッションは1つの能動的な供給側およびM個のバックアップ的な供給側を使用する。各ピアが高い利用可能なアップリンク帯域幅を有するので、ストリーミングセッションはN個の能動的な供給側をもはや要求しない。それにもかかわらず、復元力のあるストリーミングを提供するためにM個のバックアップが必要とされる可能性はある。各送信器は複数のストリーミングセッションを提供するために十分な容量を有しているので、1つのセッションに割り当てられたバックアップ的な供給側を容易に他のセッションの能動的な供給側にすることができる。
【0144】
図16に示されている特定の実施形態によれば、1つ以上のストリームを同時に提供するために送信器は十分なアップリンク帯域幅を有しているので、V2Pは複数のビデオストリームを並行して提供することができる。1つの送信器は複数のストリーミングセッションに複数のビデオを提供することができる。送信器はまた複数のストリーミングセッションにビデオの同一のコピーを提供することができる。このことは希少なビデオが多くの視聴者によって要求される場合には有効である。1つの供給側によって支援することができる並行したビデオストリームの数はV2Pによっては制限されないが、その代わりにSTBのハードウェアI/O処理能力および利用可能なアップストリーム帯域幅によって制限される。高い帯域幅の環境でのV2Pの実施は以下のような幾つかの利点を有する:
a)1つの能動的な供給側および2つのバックアップがストリーミングセッションに必要とされる;したがってより多くのストリーミングセッションを支援することができる;
b)コミュニティが利用できる特定のビデオのコピーの数は1つの供給側から提供することができる並行したストリームの数だけ増加される。このことは、多数の加入者によって記録されなかったビデオにとって殊に有効である;
c)複数のビデオストリームが提供される場合であっても、同一の復元力能力をV2Pによって保証することができる。
【0145】
したがって、V2Pは種々の同種のネットワークおよび異種のネットワークの環境において有用であることが分かった。
【0146】
図16は、本発明の1つの実施形態による、高帯域幅の環境において実施されているVoD・ツー・ピア(V2P)システムを示す。図16によれば、V2Pシステム1600は受信器1610a,1610bおよび1610c(以下では受信器1610と称する)、送信器1620a,1620bおよび1620c(以下では送信器1620と称する)およびリソース管理フレームワーク(RMF)1630を有する。ここではSTBとして示されている受信器1610は送信器1620aからのストリーミングメディアを受信するピアを受領している。ここではSTBとして示されている送信器1620は送信側のピアであるか、ストリーミングメディアの供給側である。受信器1610のいずれか1つは時には送信側のピアとしても動作できることを言及しておく。同様に、送信器1620のいずれかは時には受信側のピアとして動作することもできる。リソース管理フレームワーク(RMF)1630はサービスプロバイダによって管理される管理インフラストラクチャである。サービスプロバイダは受信器1610と送信器1620との間の制御コネクションおよびデータコネクションを管理し、要求されたメディアのオン・デマンドのストリーミングを実施する。またRMF1630により受信器1610は、ブロードキャストから記録した、または送信器から記録した、または送信器1620にダウンロードおよび記録されたストリーミング可能なコンテンツ、例えばメディアファイルについてV2Pシステム1600を検索することができる。またRMF1630により受信器1610はコンテンツ推薦を受信することができる。
【0147】
高帯域幅ネットワーク環境におけるストリーミングセッションによって要求される完全なストリーミングレートを提供するためには1つの送信器で十分であったとしても、(N+M)個の能動的な供給側およびバックアップ的な供給側を基礎とするストリーミングモデルは、(1+M)個の能動的な供給側およびバックアップ的な供給側に比べて全体のシステム利用度を高めることができる。(N+M)個のストリーミングモデルを使用することにより、各供給側は全てのストリーミングレートを提供できる場合であってもその一部を提供する。以下にはシステム利用度の評価を説明する。
【0148】
例えば:
コミュニティサイズ(ピアの数)=C
乗算係数(各ピアが供給できるストリームの数)=γ
各ストリーミングセッションに関する能動的な送信器の数=N
各ストリーミングセッションに関するバックアップの数=M
ストリーミングレート=R
各ピアのアップリンク容量=c
と仮定し、考えられる並行したストリーミングセッションの数をUとすると以下の関係が得られる。
【数11】
(1+M)モデルにおいて:
C=1200,N=1,M=2,R=2Mbps,γ=5とすると、
U=5(1200/(1+2))=2000
【0149】
(N+M)モデルにおいて:
C=1200,N=4,M=2,R=2,γ=20(各ピアがストリームの1/4を供給するので、γ=4*5=20)とすると、
U=20(1200/(4+2))=4000
【0150】
分析的なモデリングは(N+M)モデルが高帯域幅環境における(1+M)モデルよりも良好なリソース利用度を有することを表している。(N+M)または(1+M)のような静的なソリューションを使用する代わりに、適合的なメカニズムを使用することができる。例えば、V2Pが特定のリソースの十分なコピー(すなわち特定のビデオ)を有する場合には、良好なシステム利用度に関して(N+M)個ストリーミングモデルを有利に使用することができる。他方では、V2Pシステムが特定のリソースのコピーを僅かしか有していない場合には、(1+M)モデルを使用するストリーミングセッションを提供することができる。
【0151】
システムの最大利用度を以下のように推定することができる。バックアップはネットワークの不安定性が生じている間、またはピア故障中に供給側を移行している間にのみデータの小部分を提供するので、各ピアはバックアップセッションのために自身の容量を確保する代わりに、能動的なセッションのために自身の容量を使用することができる。したがって、最大利用度Uは以下の関係によって表される:
【数12】
上記の例に関して、(1+M)モデルまたは(N+M)モデルの両方にとっての最大システム利用度Uは6000である。
【0152】
V2Pシステムは低帯域幅ネットワーク環境および高帯域幅ネットワーク環境の同種のコミュニティにおいてより一般的に実施することができる。特定の実施形態によれば、送信器が複数のストリーミングセッションに寄与するための十分なリソースを有している場合にのみ、V2Pは所定の送信器を一度以上使用することができる。さもなければ、各送信器はいずれの所定の時点に1つのストリーミングセッションにおいてのみ使用される。図17は、拡張された送信器アーキテクチャを示し、このアーキテクチャでは特定の実施形態によれば、1つの送信器は複数の受信器にストリームを提供することができる。各ストリームに関して、送信器は1つのストリーム管理スレッドを開く。ストリーム管理モジュールの各インスタンスは受信器との通信に関して責任を有し、また受信器によって送信された制御信号に基づき動作する。ストリーム管理モジュールの各インスタンスはまた受信器へのストリーミングビデオの提供に関して責任を有する。したがって、V2Pは高帯域幅環境において複数のサーバ状ストリーミングセッションを支援することができる。一般化されたV2Pは、複数のソースを使用するp2pネットワーク環境の利点も、一人のユーザから複数のストリーミングセッションを供給することによるサーバ状環境の利点も引き継ぐ。
【0153】
この一般化されたマルチソース環境においては、送信器が自身の利用可能なリソースに基づき、可能な限り多くのストリーミングセッションに寄与することができる。並行するストリームV2Pの数を以下のような種々の因子に依存して支援することができる:
a)要求されたコンテンツアイテムを有するユーザの数
b)各ユーザのアップリンク帯域幅
c)所望のストリーミング品質
例えば、Cl低帯域幅ピアおよびCh高帯域幅ピアのコミュニティのためのV2Pシステムは、γCh/(N+M)+Cl/(N+M)までの高品質ストリーミングセッションを支援することができ、ここでγ≧1はどれほど多くのストリームに供給側が寄与することができるかを表す乗算係数である。低帯域幅環境においてはγ=1mであるが、高帯域幅環境においてはγ≒5以上である。
【0154】
図17はV2Pシステムの1つの実施形態のブロック図を示し、またさらに本発明の1つの実施形態による送信器を示す。図17によれば、V2Pシステム1700は受信器1710、送信器1720、リソース管理フレームワーク(RMF)1730、インセンティブマネージャ1740および電子番組表(EPG)1750を有する。受信器1710はストリーミングデータを受信するために送信器1720と対話する。送信器1720はRMF1730と対話し、V2Pシステムにコンテンツを登録および通知する。送信器1720はインセンティブマネージャ1740と対話し、このインセンティブマネージャ1740はユーザへの課金および適切なエンティティへの報酬の付与に対して責任を有する。送信器1720は電子番組表(EPG)1750と対話し、これによりパーソナルビデオレコーダ(PVR)拡張を使用したコンテンツの記録が可能になる。
【0155】
図17によれば、送信器1720はさらに登録モジュール17210、ストリーミング管理モジュール17220、FECエンコーディングモジュール17230、リソース監視モジュール17240およびPVR拡張モジュール17250を有する。登録モジュール17210はSTBのリソースおよび統計を登録し、またp2pネットワークにコンテンツを通知する。ストリーミング管理モジュール17220の各々はデータを提供し、また制御信号を受諾するために受信器と通信する。FECエンコーディングモジュール17230はコンテンツアイテムに対応するメディアファイルにおけるブロックをエンコーディングする。リソース監視モジュール17240はSTBの目下の状態に基づき要求された新たなストリーミングを受諾または拒否する。またこのリソース監視モジュール17240はストリーミングセッションに寄与した後にンティブマネージャ1740に報告を行う。また、PVR拡張モジュール17250は電子番組表(EPG)1750と対話し、イベントの記録の管理を調整する。
【0156】
図18は、ロングテールを表すグラフを示す。広範な視聴行動を予測するために統計的なサンプリングを使用することができる。例えば、図18はブロードキャスト番組の人気からどのようにロングテールが観測されるかを示す。
【0157】
V2P配置の範囲をモデリングおよび理解するために考慮する変数が多数存在する。例えば、多くの番組を記録できるような範囲を決定するために所定のコミュニティサイズによってどれほど多くの番組が記録されるか、各送信器によってどれほど多くのストリームを供給することができるか、どれほど多くの並行するストリームを供給することができるか、どれほど多くの累積ストリームをネットワークにおいて供給することができるか、どれほど昔までV2Pシステムはコンテンツをアーカイブすることができるか、またどれほどの大きいディスクを各STBは有しているべきかを評価する必要がある。例えば1つの評価として、加入者が視聴しようとするブロードキャストコンテンツの25%を記録することが考えられる。例えばTV番組のニールセン視聴率のような他のデータを、特定の番組を試聴する所定のコミュニティサイズにおける人気のパーセンテージを識別するために使用することができる。例えば、上位500のTV番組のための有効範囲を提供するV2Pシステムを以下のようにモデリングすることができる:
コミュニティのサイズ=C(各ユーザはPVRを有する);
番組iの人気=pi;且つ
番組を試聴するユーザが記録する確率=ri;
とすると、コミュニティにおいて番組iが記録される確率xi=piri
また、
コミュニティにおいて番組iに関して記録されるコピーの平均数=Cpiri
【0158】
以下のシナリオが考慮される:
1.DSLネットワークを介する標準画質(Standard Definition:SD)品質ストリーミング(N=3,M=2)
2.DSLネットワークを介する準DVD品質ストリーミング(N=5,M=2)
3.ファイバネットワークを介する準DVDまたはDVD品質ストリーミング(N=1,M=2)
【0159】
アップストリーム帯域幅が制限されており、且つ単一の受信器にストリーミグされるべきビデオの品質が正規の標準画質(SD)TVであるDSLネットワークに関して、能動的な送信器のセットは最大で3つ要求され、またバックアップ的な送信器のセットは最大で2つ要求される。
【0160】
図19Aは、3つの異なるコミュニティサイズに関して何らかの所定の番組を供給できる、並行するストリームの数を表すグラフを示す。例えば、50,000世帯のコミュニティにおいては、V2Pは上位にランキングされている番組の375の並行するストリームを支援することができる。
【0161】
図19Bは、所定のコミュニティサイズに関してV2Pによって供給することができるストリームの最大数または累積数を表すグラフを示す。例えば、V2Pは50,000のコミュニティサイズに関して24,000の並行するストリームを供給することができる。
【0162】
アップストリーム帯域幅が制限されており、且つ単一の受信器にストリーミグされるべきビデオの品質が準DVDであるDSLネットワークに関して、能動的な送信器のセットは最大で5つ要求され、またバックアップ的な送信器のセットは最大で2つ要求される。
【0163】
図20Aは、3つの異なるコミュニティサイズに関して何らかの所定の番組を供給できる、並行するストリームの数を表すグラフを示す。例えば、50,000世帯のコミュニティにおいては、V2Pは上位にランキングされている番組の200の並行するストリームを支援することができる。
【0164】
図20Bは、所定のコミュニティサイズに関してV2Pによって供給することができるストリームの最大数または累積数を表すグラフを示す。例えば、V2Pは50,000のコミュニティサイズに関して17,000の並行するストリームを供給することができる。
【0165】
アップストリーム帯域幅が100Mbpsであり、且つ5つの受信器にストリーミグされるべきビデオの品質が準DVDであるファイバネットワークに関して、能動的な送信器のセットは最大で1つ要求され、またバックアップ的な送信器のセットは最大で2つ要求される。
【0166】
図21Aは、特定の実施形態による、3つの異なるコミュニティサイズに関して何らかの所定の番組を供給できる、並行するストリームの数を表すグラフを示す。例えば、20,000世帯のコミュニティにおいては、V2Pは上位にランキングされている番組の925の並行するストリームを支援することができる。
【0167】
図21Bは、所定のコミュニティサイズに関してV2Pによって供給することができるストリームの最大数または累積数を表すグラフを示す。例えば、V2Pは20,000のコミュニティサイズに関して80,000の並行するストリームを供給することができる。
【0168】
図21Bに示されているように、V2Pはコミュニティのサイズを上回る総数の並行するストリームを供給することができ、これにより単一の世帯内の複数のTVへのストリーミングを支援することができる。またこのことは同種のネットワークを支援することができる。例えば、コミュニティはPVR機能を備えたSTBまたはPVR機能を備えていないSTBを含んでいる可能性がある。PVR機能を備えていないSTBはビデオストリームを受信することしかできず、ビデオストリームをネットワークに供給することはできない。また、コミュニティはFFTXまたはDSLアクセスを備えたSTBを含んでいる可能性がある。
【0169】
特定の実施形態によれば、V2Pによって提供された保存能力のスケールを検出するために多数のパラメータが要因として考慮されなければならない。特定の実施形態に関するこれらのパラメータのうちの幾つかのパラメータおよび基本的な仮定条件の概略を以下に述べる。STBディスクサイズ:
1Gb=MPEG2SDビデオで1時間まで
1/2Gb=MPEG4準DVDビデオで1時間まで
1/3Gb=MPEG4SDビデオで1時間まで
【0170】
1日当たりの使用頻度:
PVRを有する加入者は1日5時間までTVを見ており、そのうちの25%(1.25時間まで)が記録される。
【0171】
したがって、保存期間に関して要求されるSTBディスクサイズが以下の式を用いて近似的に求められる:
STBディスクサイズ=月×30×1.25
STBディスクサイズ=月×37.5
【0172】
よって3ヶ月の保存に関して要求されるディスクサイズは以下の通りである:
→STBディスクサイズ 〜120Gb(MPEG2SD)
→STBディスクサイズ 〜60Gb(MPEG4準DVD)
→STBディスクサイズ 〜40Gb(MPEG4SD)
図22は、特定の実施形態による、V2Pシステムの保存の側面を表すグラフを示す。例えば、図22によれば、V2PシステムはコミュニティサイズM(ただしM=2000)に関して最高でNのレートの番組の完全な有効範囲を有することができる。
【0173】
V2Pは複数ソースのビデオストリーミング技術を使用する。特定の実施形態によれば、本質的な前提条件は、ソースをその都度送信することによってストリーミングされるべきビデオファイルがエンコーディングされたフォーマット、ビットレートおよびビデオの開始フレームに関して正確に同一であるということである。
【0174】
V2Pの1つの考えられる実施形態はSTB/PVRデバイスのp2pネットワークの範囲内である。STB/PVRデバイスの所有者は、記録しようとする番組の選択に関して種々のメカニズムを有する。例えば、1つのメカニズムは電子番組表(EPG)を介するものである。
【0175】
STBのシステムクロックをサービスプロバイダのクロックに周期的に再同期させることができるので、このSTBのクロックは事前に定められた許容範囲、例えば数秒の範囲にとどまる。この同期により、STB/PVRデバイスはブロードキャスト番組を記録するために適切にスケジューリングされることが保証される。このクロック差の明白な結果は、種々のSTB/PVRデバイス全てが正確に同時刻にブロードキャスト番組の記録を開始できず、したがって同じ開始フレームから記録を開始できないということである。したがって、V2Pが複数のSTB/PVRデバイスから記録された番組をストリーミングすることができるようになる前には、メカニズムはビデオファイル内の共通の開始フレームを識別するために必要とされる。
【0176】
図23は、本発明の1つの実施形態による、共通のビデオフレームを識別するための方法を説明するフローチャートである。ストリーミングセッションからのストリーミングビデオデータの受信に先行して、ストリーミングビデオデータを供給することになる供給側のセットを受信器は取得することができる。各供給側は、特定のコンテンツアイテム、例えばブロードキャスト番組に対応するビデオファイルの個々のコピーからストリーミングビデオデータを供給する。
【0177】
このシーケンスにおいては、ステップ2310において受信器が時間窓を規定する。この時間窓は例えばブロードキャスト番組の開始時間を中心にして、事前に定められた同期許容範囲だけ時間的に前後に拡張された期間でよい。サービスプロバイダのネットワークに接続されているクライアントデバイス、例えばSTBに関するクロックを数秒で同期させることができるので、典型的な同期許容範囲は3〜5秒でよい。
【0178】
ステップ2320においては、受信器が各供給側から、関連する所定の時間窓におけるビデオファイル内に現われる基準ビデオフレームのセットに対応する基準オブジェクトのセットを受信する。例えば、MPEGコーディングされたビデオファイルのコンテクストにおいては、基準ビデオフレームの各セットは時間窓におけるビデオファイルの個々の各コピー内に現われる全てのIフレームに対応することができる。各基準オブジェクトは基準ビデオフレームのセット内の各ビデオフレームに含まれている情報の全てまたは一部を表すことができる。例えば各基準オブジェクトは、基準ビデオフレームのセット内の各ビデオフレームに含まれている情報の全てまたは一部を使用して、公知のハッシング技術を用いて計算されたハッシュ値でよい。ハッシュ値を、ストリーミングセッションの発生に先行して供給側によって、前もって計算することができる。
【0179】
ステップ2330においては、受信器が全ての供給側から受信した基準オブジェクトのセットを比較し、受信した基準オブジェクトの全てのセットに共通する共通の基準オブジェクトが識別される。ステップ2340においては、受信器がステップ2340において識別された共通の基準オブジェクトに対応するビデオフレームに開始フレームをセットする。
【0180】
例えば、受信器はサービスプロバイダのSTB間でのクロックの同期許容範囲に関連する時間窓を規定する。クロックは典型的には数秒の許容範囲、例えば3〜5秒の範囲と同期される。電子番組表(EPG)を用いて、供給側は番組の開始時間を発見し、共通の始点を発見するためにどれほど戻って、またどれほど進んでビデオファイル内を見るかを求めるために同期許容範囲を使用する。時間窓は例えばブロードキャストの開始時間を中心にして、期許容範囲だけ時間的に前後に拡張された期間でよい。供給側は、時間窓におけるビデオファイル内に現われる基準ビデオフレームのセットに対応する基準オブジェクトを生成する。例えば、MPEGコーディングされたビデオストリーム(MPEG2およびMPEG4を含む)のコンテクストにおいては、各GOP(Group of Picture)は他のGOPに依存しない。供給側は、Iフレームである各GOPの開始を識別することができる。時間窓におけるビデオファイルの各供給側のコピー内に現われるIフレームが比較のために必要とされる。送信器がIフレームを受信器に送信する場合、この量のデータを短時間で送信することは技術的に不可能である。各供給側はIフレームのハッシュ値を計算し、このハッシュ値を受信器に送信することができる。全てのIフレームのハッシュ値を計算する代わりに、各Iフレームからの部分的なデータを用いてこのアルゴリズムを継続することができる。さらには、受信器からの要求に基づきハッシュ値を提供できるようにするために、それらのハッシュ値をオフラインで計算することができる。受信器がハッシュ値のセットを受信すると、受信器はそれらのハッシュ値を容易に比較することができ、またこの供給側のセット間でビデオファイルの始点を表す共通のIフレームを発見することができる。
【0181】
図23に示されている方法は、番組の正確な開始フレームの選択を保証するものではない。しかしながら、この方法はSTBの同期許容範囲に相対的な番組の開始に近い開始フレームを選択する。特定の実施形態によれば、このアプローチの利点は分散型のソリューションであるということと、開始フレームを求めるためにビデオシーン分析が要求されないということである。
【0182】
本明細書においては、STBによって形成されるp2pネットワークのために設計されている、提案されたビデオストリーミングシステムV2Pの構成要素を種々の実施形態にしたがい説明した。特定の実施形態によれば、インテリジェントなピア選択、動的なバッファ管理、トモグラフィを基礎とするコネクション監視およびフォワード・エラー・コレクションコードなどの技術を使用して、V2Pはアップリンク帯域幅の制約を解消し、ネットワークの不安定性およびデバイス故障に対する復元力を達成することができる。特定の実施形態によれば、V2Pは多対一(many-to-one)のビデオストリーミングにおける一時停止、早送り、巻き戻しのようなインタラクティブな特徴をもたらす技術を提供する。V2Pはビデオストリーミングを光ファイバネットワークにおいて提供するよう拡張される。特定の実施形態によれば、光ファイバネットワークおよびDSLネットワークの両方におけるリソース供給に関する詳細な分析モデルも提供される。特定の実施形態によるアルゴリズムは異なるユーザによって記録された全てのビデオコンテンツを同期するためにも提供され、V2Pは多対一のストリーミングモデルを使用してストリーミングを行うことができる。
【0183】
要約すれば、種々の実施形態による本発明は、非対称的な帯域幅特性、また場合によっては信頼性が高くないコネクションを有する同種のピア・ツー・ピアネットワークにおいて、能動的な供給側およびバックアップ的な供給側を含む複数のソースを使用する高品質且つ復元力のあるビデオストリーミングを行う。種々の実施形態によれば、本発明は、インテリジェントなピア選択、ネットワークトモグラフィを基礎とするコネクション監視、動的なバッファ管理、動的なレート分布および動的なFECエンコーディングならびにデコーディングを含む複数のメカニズムを使用して、高品質且つ復元力のあるストリーミングを達成する。また本発明は一時停止、早送りおよび巻き戻しのようなインタラクティブな再生制御を効果的にシミュレートする。
【0184】
本発明を有利な実施形態に関連させて説明したが、当業者であれば本発明の精神および範囲を逸脱することなく多数の変更および修正を行えることは明らかであり、したがってそのような変更および修正が本発明の範囲に含まれるべきことを意図するために、本発明は上述の方法論および構成の正確な詳細に制限されるものではない。
【特許請求の範囲】
【請求項1】
ストリーミングビデオデータの早送り再生または巻き戻し再生をシミュレートする方法において、
ストリーミングビデオデータをストリーミングレートで受信するステップを有し、
受信した前記ストリーミングビデオデータを後に通常速度に対応する再生レートで再生するためにバッファに記憶するステップを有し、
記憶されている前記ストリーミングビデオデータを前記通常速度よりも速い速度で前記バッファから再生するステップを有し、
前記ストリーミングレートが再生レートよりも低いアンダーフロー状態についてバッファを監視するステップを有し、
アンダーフロー状態の検出に基づき、記憶されているストリーミングビデオデータ間におけるバッファに所定のビデオクリップを挿入するステップを有することを特徴とする、方法。
【請求項2】
ストリーミングビデオデータの早送り再生または巻き戻し再生をシミュレートする方法において、
ストリーミングレートでビデオファイルからストリーミングビデオデータを受信するステップを有し、
通常の視聴速度に対応する通常の再生レートで後に再生するために、受信したストリーミングビデオデータをバッファに記憶するステップを有し、
スピードアップされた視聴速度に対応するスピードアップされた再生レートでの早送り再生のための命令を受信するステップを有し、
前記ビデオファイルにおけるジャンプポイントから始まるストリーミングビデオデータを受信し、スピードアップされた再生レートでの再生をシミュレートするために、記憶されているストリーミングビデオデータを前記バッファから通常の再生速度よりも速い再生レートで再生するステップを有することを特徴とする、方法。
【請求項3】
事前に求められたビデオクリップを記憶されているストリーミングビデオデータ間におけるバッファに挿入するステップをさらに有する、請求項2記載の方法。
【請求項1】
ストリーミングビデオデータの早送り再生または巻き戻し再生をシミュレートする方法において、
ストリーミングビデオデータをストリーミングレートで受信するステップを有し、
受信した前記ストリーミングビデオデータを後に通常速度に対応する再生レートで再生するためにバッファに記憶するステップを有し、
記憶されている前記ストリーミングビデオデータを前記通常速度よりも速い速度で前記バッファから再生するステップを有し、
前記ストリーミングレートが再生レートよりも低いアンダーフロー状態についてバッファを監視するステップを有し、
アンダーフロー状態の検出に基づき、記憶されているストリーミングビデオデータ間におけるバッファに所定のビデオクリップを挿入するステップを有することを特徴とする、方法。
【請求項2】
ストリーミングビデオデータの早送り再生または巻き戻し再生をシミュレートする方法において、
ストリーミングレートでビデオファイルからストリーミングビデオデータを受信するステップを有し、
通常の視聴速度に対応する通常の再生レートで後に再生するために、受信したストリーミングビデオデータをバッファに記憶するステップを有し、
スピードアップされた視聴速度に対応するスピードアップされた再生レートでの早送り再生のための命令を受信するステップを有し、
前記ビデオファイルにおけるジャンプポイントから始まるストリーミングビデオデータを受信し、スピードアップされた再生レートでの再生をシミュレートするために、記憶されているストリーミングビデオデータを前記バッファから通常の再生速度よりも速い再生レートで再生するステップを有することを特徴とする、方法。
【請求項3】
事前に求められたビデオクリップを記憶されているストリーミングビデオデータ間におけるバッファに挿入するステップをさらに有する、請求項2記載の方法。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19A】
【図19B】
【図20A】
【図20B】
【図21A】
【図21B】
【図22】
【図23】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19A】
【図19B】
【図20A】
【図20B】
【図21A】
【図21B】
【図22】
【図23】
【公開番号】特開2011−239440(P2011−239440A)
【公開日】平成23年11月24日(2011.11.24)
【国際特許分類】
【出願番号】特願2011−142675(P2011−142675)
【出願日】平成23年6月28日(2011.6.28)
【分割の表示】特願2008−526157(P2008−526157)の分割
【原出願日】平成18年8月9日(2006.8.9)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.Linux
【出願人】(507189219)ノキア シーメンス ネットワークス ゲゼルシャフト ミット ベシュレンクテル ハフツング ウント コンパニー コマンディトゲゼルシャフト (40)
【氏名又は名称原語表記】Nokia Siemens Networks GmbH & Co. KG
【住所又は居所原語表記】St. Martin Str. 76, D−81541 Muenchen, Germany
【Fターム(参考)】
【公開日】平成23年11月24日(2011.11.24)
【国際特許分類】
【出願日】平成23年6月28日(2011.6.28)
【分割の表示】特願2008−526157(P2008−526157)の分割
【原出願日】平成18年8月9日(2006.8.9)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.Linux
【出願人】(507189219)ノキア シーメンス ネットワークス ゲゼルシャフト ミット ベシュレンクテル ハフツング ウント コンパニー コマンディトゲゼルシャフト (40)
【氏名又は名称原語表記】Nokia Siemens Networks GmbH & Co. KG
【住所又は居所原語表記】St. Martin Str. 76, D−81541 Muenchen, Germany
【Fターム(参考)】
[ Back to top ]