以下、本発明の最良の実施形態を図面に基づいて説明する。なお、以下に説明する各実施形態は、コンテンツ配信システムに対して本発明を適用した場合の実施形態である。
(I)第1実施形態
先ず、本発明の第1実施形態におけるコンテンツ配信システムについて説明する。
始めに、図1乃至図3を参照して、第1実施形態におけるコンテンツ配信システムの構成及び機能について説明する。
図1は、第1実施形態におけるコンテンツ配信システムの概要構成例を示す図であり、図2は、配信サーバの概要構成例を示すブロック図であり、図3は、端末装置の概要構成例を示すブロック図である。
図1に示すように、配信システムとしてのコンテンツ配信システムは、配信されるべき配信情報としてのコンテンツ(例えば映画や楽曲等のコンテンツ)データを配信する配信元装置としての配信サーバ1と、当該コンテンツデータの配信を受ける配信先装置としての端末装置(クライアント)2と、を備えて構成されており、配信サーバ1と端末装置2には、夫々IP(Internet Protocol)アドレスが割り当てられており、これらはインターネット等のネットワーク3を介して相互に接続されている。
配信サーバ1は、図2に示すように、各種データ及びプログラム,更にはコンテンツデータ等を記憶(格納)するHDD(Hard Disc Drive)等から構成された記憶部11と、当該コンテンツデータに含まれる映像情報(ビデオデータ)及び音声情報(オーディオデータ)等をエンコード(データ圧縮や暗号化等)するエンコーダ部12と、ネットワーク3を通じて端末装置2との間の通信制御を行うための通信部13と、CPU(Central Processing Unit) ,作業用RAM(Random-Access Memory),各種データ及びプログラムを記憶するROM(Read-Only Memory)等から構成された制御部14と、を備えて構成され、これらの各構成要素はバス15を介して相互に接続されている。
制御部14は、CPUが記憶部11等に記憶されたプログラムを読み出して実行することにより、配信サーバ1全体を統括制御し、端末装置2からの要求に応じて、コンテンツデータの配信制御を行う。具体的には、制御部14は、エンコーダ部12によりエンコードされたコンテンツデータを、所定のデータ量に分割して連続する複数のデータパケットを生成し、これをデータストリームとして、端末装置2から要求された配信速度(以下、「転送速度」という)で通信部13等を通じて端末装置2に配信(ストリーミング配信)するようになっている。なお、各データパケットには、そのコンテンツの先頭から連続するパケット番号が付与されている。
端末装置2は、図3に示すように、各種データ及びプログラム等を記憶するHDD等から構成された記憶部21と、配信サーバ1からのコンテンツデータを一時的に蓄積(記憶)する蓄積手段としてのバッファメモリ22と、バッファメモリ22からのコンテンツデータに含まれる映像情報及び音声情報等をデコード(データ伸張や復号化等)して再生するデコーダ部23と、当該再生された映像情報等に対して所定の描画処理を施し映像信号として出力する映像処理部24と、当該映像処理部24から出力された映像信号に基づき映像表示するCRT,液晶ディスプレイ等の表示部25と、上記再生された音声情報をアナログ音声信号にD(Digital)/A(Analog)変換した後これをアンプにより増幅して出力する音声処理部26と、当該音声処理部26から出力された音声信号を音波として出力するスピーカ27と、ネットワーク3を通じて配信サーバ1との間の通信制御を行うための通信部28と、演算機能を有するCPU,作業用RAM,各種データ及びプログラムを記憶するROM等から構成された制御部29と、ユーザ(視聴者)からの指示(例えば、再生出力指示、設定指示等)を入力し制御部29に対してその指示信号を与える入力部(例えば、マウス、キーボード、操作パネル、或いはリモコン等)30を備えて構成され、記憶部21、バッファメモリ22、デコーダ部23、通信部28、制御部29、及び入力部30はバス31を介して相互に接続されている。なお、端末装置2としては、例えば、STB(Set Top Box)やパーソナルコンピュータが適用可能である。
バッファメモリ22は、制御部29の制御下、例えばFIFO(First In First Out)形式のリングバッファメモリから構成されており、受信ポインタにより示される記憶領域に通信部28を通じて受信されたコンテンツデータを一時的に蓄積し、再生ポインタにより示される記憶領域に格納されているコンテンツデータをバス31を介してデコーダ部23に出力するようになっている。
制御部29は、CPUが記憶部21等に記憶されたプログラム(本発明の配信速度制御用プログラムを含む)を読み出して実行することにより、端末装置2全体を統括制御し、かつ、再生制御手段及び速度制御手段等として機能する。なお、配信速度制御用プログラムは、例えば、ネットワーク3上の所定のサーバからダウンロードされるようにしてもよいし、例えば、CD−ROM等の記録媒体に記録されて当該記録媒体のドライブを介して読み込まれるようにしてもよい。
再生制御手段としての制御部29は、バッファメモリ22におけるコンテンツデータの再生出力(つまり、デコーダ部23、映像処理部24、及び音声処理部26等による再生出力)を制御するようになっており、バッファメモリ22におけるコンテンツデータの蓄積量(以下、「バッファ量」という)が、当該コンテンツデータの再生出力を開始することが可能となる最小のバッファ量である再生可能バッファ量(本発明における第1蓄積量に対応)53(例えば、例えば音声情報の場合、例えば1オーディオフレーム分のデータ量、映像情報の場合、例えば1フレーム(ピクチャ)分のデータ量、言い変えれば、デコーダ部23が必要とする最小のデータ量)となったとき、当該コンテンツデータの再生出力を開始させる。
また、速度制御手段としての制御部29は、配信サーバ1と協働(連携)して、バッファメモリ22におけるコンテンツデータのバッファ量に基づき配信サーバ1から端末装置2へのコンテンツデータの転送速度を制御するようになっており、当該コンテンツデータのバッファ量に基づく転送速度を変更するタイミングで、上記コンテンツデータの再生出力速度以上の範囲において、上記転送速度を変更する制御を行う。
ここで、図4を参照して、制御部29におけるコンテンツデータの転送速度制御について詳しく説明する。
図4は、コンテンツデータの転送速度が変更(この例では、2段階の変更)される様子を示す概念図である。なお、図4の例において、縦軸がデータ量(kbyte)を、横軸が時間(t)を夫々示しており、また、線51の傾きが転送速度(第1〜第3転送速度)を、線52の傾きが再生出力速度を示している。また、任意の時間tにおける線51と線52との間のデータ量がバッファ量(つまり、バッファメモリ22に蓄積されているコンテンツデータの蓄積量)を示している。
図4の例では、制御部29は、コンテンツデータのバッファ量が再生可能バッファ量53より少ない場合、転送速度が再生出力速度より速い第1転送速度(最も速い速度(フルスピード))になるように(図4の“A”の期間)制御し、バッファ量が再生可能バッファ量53以上であり、かつ、当該再生可能バッファ量より多いで予め設定された設定バッファ量(本発明における第2蓄積量に対応)54より少ない場合、転送速度が上記第1転送速度より遅く、かつ、再生出力速度より速い第2転送速度になるように(図4の“B”の期間)制御し、更に、バッファ量が設定バッファ量54以上の場合、転送速度が再生出力速度に追従する第3転送速度(言い換えれば、デコーダ部23のデータ消費速度)になるように(図4の“C”の期間)制御している。つまり、制御部29は、バッファメモリ22におけるバッファ量に応じて、配信速度を、コンテンツデータの再生出力速度より速い第1配信速度と、第1配信速度より遅く、且つ、再生出力速度より速い第2配信速度と、再生出力速度に追従する第3配信速度と、に切り換えるように制御するようになっている。
ここで、転送速度は、配信サーバ1側の処理能力、端末装置2側の処理能力、及びネットワーク3経路の帯域幅(バンド幅)の3つの要素で決まるものであるため、第1転送速度(最も速い速度(フルスピード))とは、これらの3つの要素が考慮された上で可能な限り速い(つまり、これらの3つの要素のうちでボトルネックとなる箇所の速度で頭打ちとならない範囲で制御可能)ということを意味する。
また、設定バッファ量54は、例えばネットワーク3のジッタ(つまり、配信サーバ1と端末装置2とを接続する通信回線における転送速度(伝送速度)の変動、言い換えれば、データパケットの到着時間のずれ(変位))が考慮されて設定されるものであり、コンテンツデータの再生出力が当該ジッタに影響されない(つまり、当該変動により再生出力が途切れない)バッファ量である。図4の“C”の期間では、転送速度が第3転送速度となって再生出力速度に追従することにより、設定バッファ量54が維持されている。また、バッファメモリ22におけるバッファ量が設定バッファ量54に到達するまでの図4の“B”の期間では、転送速度は再生出力速度よりも速い第2配信速度になっているが、この第2転送速度は、上記ネットワークのジッタ(転送速度の変動)を相殺するように設定されるものであり、再生出力速度(言い換えれば、データ消費速度)+調整速度“a”(この値は、ネットワークのジッタに応じて決定される)の転送速度となる。
次に、図5乃至図8等を参照して、第1実施形態におけるコンテンツ配信システムの動作について説明する。
図5乃至図8は、第1実施形態のコンテンツデータ配信の際における端末装置2の制御部29の処理を示すフローチャートである。
図5に示す処理は、例えばユーザから入力部30を介して所望のコンテンツの要求指示があった場合に開始され、先ず、制御部29は、配信サーバ1に対して接続要求(つまり、配信サーバ1に対して接続要求を示す情報を送信)を行う(ステップS1)。当該接続要求に対して、配信サーバ1は、所定の認証処理を実行し、良好である場合には、接続了解を示す情報を端末装置2に対して返信する。
接続が了解された場合、制御部29は、配信サーバ1との間の接続確立処理を行い(ステップS2)、次いで、コンテンツデータの配信要求を行う(ステップS3)。当該配信要求に対して、配信サーバ1では、要求されたコンテンツデータの配信準備を行うことになる。
次いで、制御部29は、バッファメモリ22における現在のバッファ量を確認し(ステップS4)、再生可能バッファ量53未満である場合には(ステップS4:L)、ステップS5に示す第1転送速度での要求処理(図6)に移行し、再生可能バッファ量53以上設定バッファ量54未満である場合には(ステップS4:M)、ステップS6に示す第2転送速度での要求処理(図7)に移行し、設定バッファ量54以上である場合には(ステップS4:H)、ステップS7に示す第3転送速度での要求処理(図8)に移行する。なお、ユーザが初めてコンテンツの要求指示を行った場合等、未だバッファメモリ22にデータが蓄積されていない初期の段階では、第1転送速度での要求処理に移行されることになる。
第1転送速度での要求処理においては、図6に示すように、制御部29は、先ず、配信サーバ1に対して第1転送速度(例えば、400kbps(bit per second)程度)での要求(つまり、配信サーバ1に対して第1転送速度でコンテンツデータに係るデータパケットを配信する要求を示す情報を送信)を行う(ステップS11)。当該要求に対して、配信サーバ1は、転送速度を第1転送速度に設定し、当該第1転送速度でデータパケットを端末装置2に配信する(なお、配信サーバ1は、端末装置2から次の要求が来るまで当該第1転送速度で複数のデータパケットを順次送り続ける)ことになり、当該データパケットは、端末装置2の通信部28を通じて受信され、バッファメモリ22に蓄積されることになる。
次いで、制御部29は、配信サーバ1から最後のデータパケットを受信したか否かを判別し(ステップS12)、受信した場合には(ステップS12:Y)、当該配信サーバ1との接続を切り(ステップS19)、バッファメモリ22に未再生のコンテンツデータが蓄積されているか否かを判別し(ステップS20)、蓄積されている場合(ステップS20:Y)には、バッファメモリ22における残りのコンテンツデータを再生出力させ(ステップS21)、当該処理を終了する。
一方、最後のデータパケットを受信していない場合には(ステップS12:N)、制御部29は、受信されたデータパケットに基づいてネットワーク8のジッタを計測する(ステップS13)。
次いで、制御部29は、バッファメモリ22におけるバッファ量が再生可能バッファ量53以上になったか(言い換えれば、到達したか)否かを判別し(ステップS14)、再生可能バッファ量53以上になっていない場合には(ステップS14:N)、ステップS12に戻り、上記と同様の処理を行う。
こうして、ネットワーク8のジッタは、例えば、再生可能バッファ量53に到達するまでの間の所定時間における各データパケットの到着時間差の平均値、或いは標準偏差によって求められる。
そして、バッファメモリ22におけるバッファ量が再生可能バッファ量53以上になった場合には(ステップS14:Y)、制御部29は、デコーダ部23等に対して再生開始指令を与える(ステップS15)。これにより、バッファメモリ22に蓄積されたコンテンツデータの再生出力が開始される。
次いで、制御部29は、上記ステップS13における計測によって求められたジッタが所定値(例えば、通常許容できるジッタの最大値)よりも大きいか否かを判別し(ステップS16)、当該所定値よりも大きくない場合には(ステップS16:N)、設定バッファ量54を規定バッファ量に設定し、かつ、調整速度“a”を規定速度に設定し(ステップS18)、図5に示すステップS4の処理に戻る。一方、ジッタが所定値よりも大きい場合には(ステップS16:Y)、制御部29は、設定バッファ量54を規定バッファ量より大きいバッファ量(例えば、ジッタの大きさに比例した値)に設定し、かつ、調整速度“a”を規定速度より大きい速度(例えば、ジッタの大きさに比例した値、つまり、ジッタが大きければバッファ量を増やす)に設定し(ステップS17)、図5に示すステップS4の処理に戻る。
次に、第2転送速度での要求処理においては、図7に示すように、制御部29は、上記配信サーバ1に対して第2転送速度(再生出力速度+上記設定された調整速度“a”。例えば、ジッタが所定値よりも大きくない場合、150kbps程度、ジッタが所定値よりも大きい場合、200kbps程度)での要求(転送速度を変更するタイミング)を行う(ステップS23)。当該要求に対して、配信サーバ1は、転送速度を第2転送速度に変更設定し、当該第2転送速度でコンテンツデータに係るデータパケットを端末装置2に配信することになる。
次いで、制御部29は、配信サーバ1から最後のデータパケットを受信したか否かを判別し(ステップS24)、受信した場合には(ステップS24:Y)、当該配信サーバ1との接続を切り(ステップS26)、バッファメモリ22に未再生のコンテンツデータが蓄積されている場合(ステップS27:Y)には、バッファメモリ22における残りのコンテンツデータを再生出力させ(ステップS28)、当該処理を終了する。
一方、最後のデータパケットを受信していない場合には(ステップS24:N)、制御部29は、バッファメモリ22におけるバッファ量が再生可能バッファ量53未満又は設定バッファ量54以上(つまり、再生可能バッファ量53以上設定バッファ量54以下の範囲外になった)になったか否かを判別し(ステップS25)、再生可能バッファ量53未満又は設定バッファ量54以上になっていない場合には(ステップS25:N)、ステップS24に戻り、上記と同様の処理を行う。
一方、再生可能バッファ量53未満又は設定バッファ量54以上になった場合には(ステップS25:Y)、図5に示すステップS4の処理に戻る。
なお、データパケットが正常に配信され、バッファメモリ22に蓄積されていけば、バッファ量が設定バッファ量54に到達することになるが、例えば、配信サーバ1側、或いは、ネットワーク3経路上における何らかの原因によりデータパケットの配信が滞ることが生じれば、再生可能バッファ量53未満になる場合もありうる。このような場合にも、当該処理は適切に対応することができる。
次に、第3転送速度での要求処理においては、図8に示すように、制御部29は、上記配信サーバ1に対して第3転送速度(再生出力速度に追従する速度。例えば、100kbps程度)での要求(転送速度を変更するタイミング)を行う(ステップS31)。当該要求に対して、配信サーバ1は、転送速度を第3転送速度に変更設定し、当該第3転送速度でコンテンツデータに係るデータパケットを端末装置2に配信することになる。
次いで、制御部29は、配信サーバ1から最後のデータパケットを受信したか否かを判別し(ステップS32)、受信した場合には(ステップS32:Y)、当該配信サーバ1との接続を切り(ステップS34)、バッファメモリ22に未再生のコンテンツデータが蓄積されている場合(ステップS35:Y)には、バッファメモリ22における残りのコンテンツデータを再生出力させ(ステップS36)、当該処理を終了する。
一方、最後のデータパケットを受信していない場合には(ステップS32:N)、制御部29は、バッファメモリ22におけるバッファ量が設定バッファ量54未満になったか否かを判別し(ステップS33)、設定バッファ量54未満になっていない場合には(ステップS33:N)、ステップS32に戻り、上記と同様の処理を行う。
一方、設定バッファ量54未満になった場合には(ステップS33:Y)、図5に示すステップS4の処理に戻る。
以上説明したように上記第1実施形態によれば、バッファメモリ22に蓄積されるバッファ量が再生可能バッファ量になるまで第1転送速度(フルスピード)でコンテンツデータを配信し(図4の“A”の期間)、その後、上記バッファ量がネットワーク3のジッタが考慮された設定バッファ量になるまで第2転送速度(再生出力速度+調整速度“a”)でコンテンツデータを配信し(図4の“B”の期間)、その後、第3転送速度(再生出力速度に追従する速度)でコンテンツデータを配信する(図4の“C”の期間)というように、上記コンテンツデータの再生出力速度以上の範囲において、バッファ量に応じて上記転送速度を段階的に変更するようにしたので、ネットワーク3のジッタの影響を受けることなく、配信されたコンテンツデータの再生までの時間を短縮することができる。また、図4の“A”の期間において、配信サーバ1がフルスピードでデータパケットを転送(配信)する時間を短くできるので、配信サーバ1への負担を小さくすることができる。
特に、ストリーミングのチャンネルが多くある場合、ユーザは最初にいろいろなチャンネルを視聴してから一つのチャンネルに落ち着く場合が想定されるが、このような場合に、毎回十分なバッファ量までバッファリングするという無駄を省き、迅速に再生開始できるので、ユーザにとっての利便性を向上させることができる。
なお、上記実施形態においては、コンテンツデータの再生出力速度以上の範囲において、上記転送速度を2段階に変更(減速)する例を示したが、これに限定されるものではなく2段階より多く段階的に変更するように構成しても良い。例えば、図4の“B”の期間において、第2配信速度を複数段階で変化させたり、2次曲線的に変化させるように構成しても良い。
(II)第2実施形態
次に、第2実施形態におけるコンテンツ配信システムについて説明する。
上記第1実施形態においては、第1〜第3転送速度は、端末装置2からの要求に応じて配信サーバ1によって設定されるサーバ主導型の形態について説明したが、第2実施形態では、第1〜第3転送速度が端末装置2の要求タイミングで決まるクライアント主導型の形態について、図9乃至図13等を参照して説明する。なお、第2実施形態における配信サーバ1及び端末装置2の構成及び機能は第1実施形態と基本的には同様であるので、重複した説明は省略する。
図9乃至図12は、第2実施形態のコンテンツデータ配信の際における端末装置2の制御部29の処理を示すフローチャートであり、図13は、端末装置2から配信サーバ1へのデータブロックの要求タイミングの一例を示す図である。
図9に示す処理は、第1実施形態と同様、例えばユーザから入力部30を介して所望のコンテンツの要求指示があった場合に開始される。なお、図9に示すステップS41〜ステップS43までの処理は、図5に示すステップS1〜ステップS3までの処理と同様であるので重複する説明を省略する。
次に、図9のステップS44では、制御部29は、コンテンツデータを構成するデータブロックの番号iの初期値として“0”を設定(i=0に設定)する。
ここで、データブロックとは、配信サーバ1側でコンテンツデータがブロック単位(任意のデータ量(例えば数kbyte〜数Mbyte))に分割されたものであり、夫々のデータブロックに対して例えば連続する固有の番号が付与される。端末装置2は、このデータブロックの番号を指定して配信サーバ1に配信要求することになる。なお、このデータブロックは、更に、複数のデータパケットに分割されて配信される。
次いで、制御部29は、第1実施形態と同様、バッファメモリ22における現在のバッファ量を確認し(ステップS45)、再生可能バッファ量53未満である場合には(ステップS45:L)、ステップS46に示す第1待ち時間での要求処理(図10)に移行し、再生可能バッファ量53以上設定バッファ量54未満である場合には(ステップS45:M)、ステップS47に示す第2待ち時間での要求処理(図11)に移行し、設定バッファ量54以上である場合には(ステップS45:H)、ステップS48に示す第3待ち時間での要求処理(図12)に移行する。
第1待ち時間での要求処理においては、図10に示すように、制御部29は、先ず、配信サーバ1に対してi番目のデータブロックを要求(つまり、配信サーバ1に対してi番目のデータブロックを配信する要求を示す情報を送信)する(ステップS51)。当該要求に対して、配信サーバ1は、所定の転送速度でデータブロックに係るデータパケットを端末装置2に配信することになり、当該データパケットは、端末装置2の通信部28を通じて受信され、バッファメモリ22に蓄積されることになる。
次いで、制御部29は、データブロックの番号iを“1”インクリメントし(ステップS52)、続いて、配信サーバ1から最後のデータパケットを受信したか否かを判別する(ステップS53)。最後のデータパケットを受信していない場合には(ステップS53:N)、制御部29は、第1実施形態と同様、受信されたデータパケットに基づいてネットワーク8のジッタを計測し(ステップS54)、バッファメモリ22におけるバッファ量が再生可能バッファ量53以上になったか否かを判別する(ステップS55)。
そして、再生可能バッファ量53以上になっていない場合には(ステップS55:N)、制御部29は、第1待ち時間が経過した後(ステップS56)、ステップS51に戻り、次のデータブロック(ステップS52でインクリメントされたi番目のデータブロック)を配信サーバ1に対して要求する。
ここで、「待ち時間」は、前回のデータブロックを要求したタイミングからの経過時間を規定するものであり、上記ステップS56では、制御部29が時計を監視して次の要求タイミングの時刻になるのを待つことになる。これにより、端末装置2のデータブロックの要求タイミングが決まり、複数の要求タイミングの時間間隔によって転送速度が定まることになる。
そして、第2実施形態においては、コンテンツデータのバッファ量が再生可能バッファ量53より少ない場合、この待ち時間を「第1待ち時間」(例えば、フルスピードで端末装置2がデータブロックを配信サーバ1から引き出す場合、“0”(ゼロ)時間となる。つまり、端末装置2が要求を出せる最大の速度(CPUの動作速度に依存))として上記第1転送速度になるように制御し、バッファ量が再生可能バッファ量53以上であり、かつ、当該再生可能バッファ量より多い予め設定された設定バッファ量54未満の場合、当該待ち時間を「第2待ち時間」(第1待ち時間より長い)として上記第2転送速度になるように制御し、バッファ量が設定バッファ量54以上の場合、当該待ち時間を「第3待ち時間」(第2待ち時間より長い)として上記第3転送速度になるように制御するようになっている。
例えば、図13の例には、配信サーバへの要求タイミングを示しているが、“A”の期間では、第1待ち時間により定まる時間間隔“T1”で配信サーバへのデータブロックの要求がなされており、“B”の期間では、第2待ち時間により定まる時間間隔“T2”で配信サーバへのデータブロックの要求がなされており、“C”の期間では、第3待ち時間により定まる時間間隔“T3”で配信サーバへのデータブロックの要求がなされている。このように、要求タイミングの時間間隔を変えることによってバッファメモリ22に蓄積される速さを調整することができる。
なお、図10に示すステップS57〜ステップS63までの処理は、図6に示すステップS15〜ステップS21までの処理と同様であるので重複する説明を省略する。
次に、第2待ち時間での要求処理においては、図11に示すように、制御部29は、先ず、配信サーバ1に対してi番目のデータブロックを要求し(ステップS65)、続いて、データブロックの番号iを“1”インクリメントし(ステップS66)、続いて、配信サーバ1から最後のデータパケットを受信したか否かを判別する(ステップS67)。最後のデータパケットを受信していない場合には(ステップS67:N)、制御部29は、第1実施形態と同様、バッファメモリ22におけるバッファ量が再生可能バッファ量53未満又は設定バッファ量54以上になったか否かを判別し(ステップS68)、再生可能バッファ量53未満又は設定バッファ量54以上になっていない場合には(ステップS68:N)、上述した第2待ち時間が経過した後(ステップS69)、ステップS65に戻り、次のデータブロックを配信サーバ1に対して要求する。
なお、図11に示すステップS70〜ステップS72までの処理は、図7に示すステップS26〜ステップS28までの処理と同様であるので重複する説明を省略する。
次に、第3待ち時間での要求処理においては、図12に示すように、制御部29は、先ず、配信サーバ1に対してi番目のデータブロックを要求し(ステップS75)、続いて、データブロックの番号iを“1”インクリメントし(ステップS76)、続いて、配信サーバ1から最後のデータパケットを受信したか否かを判別する(ステップS77)。最後のデータパケットを受信していない場合には(ステップS77:N)、制御部29は、第1実施形態と同様、バッファメモリ22におけるバッファ量が設定バッファ量54未満になったか否かを判別し(ステップS78)、設定バッファ量54未満になっていない場合には(ステップS78:N)、上述した第3待ち時間が経過した後(ステップS79)、ステップS75に戻り、次のデータブロックを配信サーバ1に対して要求する。
なお、図12に示すステップS80〜ステップS82までの処理は、図8に示すステップS34〜ステップS36までの処理と同様であるので重複する説明を省略する。
以上説明したように上記第2実施形態によっても、第1実施形態と同様の効果を有することができることに加え、例えば、配信サーバと端末装置の性能が大きく違う場合に、端末装置からの要求が配信サーバに到達してからデータを転送してもらうので、端末装置側でのデータの取りこぼしがなくなるという効果がある(つまり、端末装置の性能に合わせたデータ転送が可能)。
なお、上記第2実施形態においては、データブロックのサイズ(データ量)を固定とし、要求タイミングの時間間隔を可変としたが、別の例として、要求タイミングの時間間隔を固定とし、データブロックのサイズ(データ量)を可変として制御するように構成しても良い。
(III)第3実施形態
次に、第3実施形態におけるコンテンツ配信システムについて説明する。
図14は、第3実施形態、後述する第4及び第5実施形態におけるコンテンツ配信システムの概要構成例を示す図である。
上記第1及び第2実施形態においては、1つの配信サーバ1からコンテンツデータが端末装置2に配信される形態について説明したが、第3実施形態では、図14に示すように、複数(ここでは、3つ)の配信サーバ1A,1B,1Cの夫々から一のコンテンツデータが分割されたデータブロックが端末装置2に配信(分散ストリーミング配信)される形態について説明する。なお、第3実施形態における配信サーバ1A,1B,1C、及び端末装置2の構成及び機能は第1実施形態における配信サーバ1及び端末装置2と基本的には同様であるので、重複した説明は省略する。
配信サーバ1A,1B,1Cは、夫々、コンテンツデータ(データパケット)の転送速度が相互に異なっており、この3つの配信サーバの中で、転送速度は、配信サーバ1Aが1番速く、配信サーバ1Bは配信サーバ1Aよりは遅いが配信サーバ1Cよりは速く、配信サーバ1Cは1番遅くなっている。また、これらの配信サーバ1A,1B,1Cは、同一のコンテンツデータを有している。
一方、端末装置2における速度制御手段としての制御部29は、コンテンツデータのバッファ量に基づく転送速度を変更するタイミングで、接続する配信サーバの数を変えるように当該各配信サーバ1A,1B,1Cとの接続を制御する。つまり、制御すべき転送速度となるように、配信サーバ1A〜1Cの接続数が変えられる。
この転送速度制御について図4を用いて説明すると、例えば、“A”の期間では、3つの配信サーバ1A,1B及び1Cから夫々最も速い転送速度(例えば、端末装置2から見た全体の転送速度が第1転送速度になる)でデータパケットが配信されるように制御され、“B”の期間では、コンテンツデータの転送速度が端末装置2から見て第2転送速度になるように2つの配信サーバ1B及び1Cから夫々、データパケットが配信されるように制御され、“C”の期間では、コンテンツデータの転送速度が第3転送速度になるように1つの配信サーバ1Cからデータパケットが配信されるように制御される。
次に、図15乃至図20等を参照して、第3実施形態におけるコンテンツ配信システムの動作について説明する。
図15乃至図19は、第3実施形態のコンテンツデータ配信の際における端末装置2の制御部29の処理を示すフローチャートであり、図20は、端末装置2から配信サーバ1A乃至1Cへのデータブロックの要求タイミングの一例を示す図である。
図15に示す処理は、第1実施形態と同様、例えばユーザから入力部30を介して所望のコンテンツの要求指示があった場合に開始され、先ず、制御部29は、複数の配信サーバ、例えば3つの配信サーバ1A,1B及び1Cの夫々に対して接続要求を行う(ステップS101)。当該接続要求に対して、配信サーバ1A,1B及び1Cは、夫々、所定の認証処理を実行し、良好である場合には、接続了解を示す情報を端末装置2に対して返信する。
接続が了解された場合、制御部29は、配信サーバ1A,1B及び1Cとの間の接続確立処理を行い(ステップS102)、次いで、夫々の配信サーバに対してコンテンツデータの配信要求を行う(ステップS103)。当該配信要求に対して、配信サーバ1A,1B及び1Cでは、要求されたコンテンツデータの配信準備を行うことになる。
次いで、制御部29は、コンテンツデータを構成するデータブロックの番号iの初期値として“0”を設定(i=0に設定)する(ステップS104)。
次いで、制御部29は、第2実施形態と同様、バッファメモリ22における現在のバッファ量を確認し(ステップS105)、再生可能バッファ量53未満である場合には(ステップS105:L)、ステップS106に示す第1待ち時間での要求処理(図16)に移行し、再生可能バッファ量53以上設定バッファ量54未満である場合には(ステップS105:M)、ステップS107に示す第2待ち時間での要求処理(図17)に移行し、設定バッファ量54以上である場合には(ステップS105:H)、ステップS108に示す第3待ち時間での要求処理(図18)に移行する。
第1待ち時間での要求処理においては、図16に示すように、制御部29は、配信サーバ1Aの接続処理を行う(ステップS111)。当該配信サーバ1Aの接続処理においては、図19(A)に示すように、制御部29は、配信サーバ1Aは既に接続済であるか否か判別し(ステップS155)、接続済である(例えば、図15に示す処理の開始直後は接続済となっている)場合には(ステップS155:Y)、図16の処理に戻る。一方、接続済でない場合(ステップS155:N)には、制御部29は、複数の配信サーバ1Aに対して接続要求を行い(ステップS156)、続いて、配信サーバ1Aとの間の接続確立処理を行い(ステップS157)、続いて、配信サーバ1Aに対してコンテンツデータの配信要求を行い(ステップS158)、図16の処理に戻る。
次いで、図16に示すステップS112では、制御部29は、配信サーバ1Bの接続処理(図19(B))を行う。当該配信サーバ1Bの接続処理は、配信サーバ1Aの接続処理と同様であるので、説明を省略する。
次いで、制御部29は、アイドル中の配信サーバ(つまり、配信サーバ1A乃至1Cのうち、データブロックの配信準備が完了している配信サーバ)に対してi番目のデータブロックを要求し(ステップS113)、続いて、データブロックの番号iを“1”インクリメントする(ステップS114)。アイドル中の配信サーバが複数ある場合には、アイドル時間が長い配信サーバへ要求を出す方法や、転送速度の速い配信サーバへi番目のデータブロックを要求を出す方法が考えられる。また、アイドル中の配信サーバが存在しない場合は、接続している配信サーバのいずれかがアイドル状態になるまで待つこととなる。
次いで、制御部29は、何れかの配信サーバから最後のデータパケットを受信したか否かを判別し(ステップS115)、最後のデータパケットを受信していない場合には(ステップS115:N)、第2実施形態と同様、受信されたデータパケットに基づいてネットワーク8のジッタを計測する(ステップS116)。
次いで、制御部29は、バッファメモリ22におけるバッファ量が再生可能バッファ量53以上になったか否かを判別し(ステップS117)、再生可能バッファ量53以上になっていない場合には(ステップS117:N)、第2実施形態と同様、第1待ち時間が経過した後(ステップS118)、ステップS113に戻り、次のデータブロックをアイドル中の配信サーバに対して要求する。
こうして、再生可能バッファ量53以上になるまで、データブロックの要求処理は繰り返されるが、このとき、制御部29は、例えば、図20に示すように、処理能力が高い順(つまり、配信サーバ1C、配信サーバ1B、配信サーバ1Aの順に高くなる)にデータブロックの要求間隔を短くするように制御する(なお、図20中の逆三角印内の番号は、データブロックの要求の順序を示している)。
図20の例では、第1待ち時間で転送する時間において、第1待ち時間をゼロとしており、ステップS113からループして戻ってくるまでの時間分だけ遅延がある。つまり、データブロックの配信(転送)が終わった配信サーバへすぐに次のデータブロックの要求が行われる。再生可能バッファ量以上になると第2待ち時間の処理へ移り、第2待ち時間の間隔で配信サーバへ要求がなされる。なお、第3待ち時間の場合も同様である。
なお、図16に示すステップS119〜ステップS122までの処理は、図6に示すステップS15〜ステップS21までの処理と同様であるので重複する説明を省略する。
次いで、ステップS121の処理後、制御部29は、配信サーバ1Aとの接続を切り(ステップS123)、図15の処理に戻る。
また、制御部29が最後のデータパケットを受信した場合には(ステップS115:Y)、制御部29は、接続している全ての配信サーバとの接続を切り(ステップS124)、ステップS125等を経て、当該処理を終了する。
第2待ち時間での要求処理においては、図17に示すように、制御部29は、ステップS112と同様、配信サーバ1Bの接続処理を行う(ステップS131)。
次いで、制御部29は、アイドル中の配信サーバ(つまり、配信サーバ1A及び1Bのうち、データブロックの配信準備が完了している配信サーバ)に対してi番目のデータブロックを要求し(ステップS132)、続いて、データブロックの番号iを“1”インクリメントする(ステップS133)。
次いで、制御部29は、最後のデータパケットを受信したか否かを判別し(ステップS134)、最後のデータパケットを受信していない場合には(ステップS134:N)、バッファメモリ22におけるバッファ量が再生可能バッファ量53未満又は設定バッファ量54以上になったか否かを判別し(ステップS135)、再生可能バッファ量53未満又は設定バッファ量54以上になっていない場合には(ステップS135:N)、第2実施形態と同様、上述した第2待ち時間が経過した後(ステップS136)、ステップS132に戻り、次のデータブロックをアイドル中の配信サーバに対して要求する。
また、制御部29が最後のデータパケットを受信した場合には(ステップS134:Y)、制御部29は、接続している全ての配信サーバとの接続を切り(ステップS138)、ステップS125等を経て、当該処理を終了する。
なお、図18に示す第3待ち時間での要求処理は、図12に示す第3待ち時間での要求処理と同様であるので、重複した説明を省略する。
以上説明したように上記第3実施形態によれば、第2実施形態と同様の効果を有することに加え、例えば他の配信サーバに比べ転送速度の速い配信サーバを多くの端末装置で効率良く利用することができる。また、第3実施形態のように、配信サーバの接続数を次第に減らしていく方法は、同じコンテンツデータを持つ配信サーバが少ない場合に有効である。
なお、上記第3実施形態においては、転送速度が相互に異なる複数の配信サーバを例にとって説明したがこれに限定されるものではなく、例えば、コンテンツ配信システムが、相互に同一の転送速度を有する複数の配信サーバからなる配信サーバ群であって、当該転送速度が相互に異なる複数の配信サーバ群を備え、複数の配信サーバ群から一のコンテンツデータが分割されて夫々端末装置2に配信されるようにし、端末装置2の制御部29が、上記転送速度を変更するタイミングで、接続する配信サーバ群の数を変えるように各配信サーバ群との接続を制御するようにしても良い。
図21は、転送速度が相互に異なる3つの配信サーバ群を備えるコンテンツ配信システムの概要構成例を示す図である。図21の例では、転送速度が最も速い配信サーバ群1Dと、転送速度が普通の配信サーバ群1Eと、転送速度が最も遅い配信サーバ群1Fと、が示されており、夫々の配信サーバ群1D〜1Fは、相互に同一の転送速度を有する3つの配信サーバを備えている。このような構成において、制御すべき転送速度となるように、例えば図15乃至図19の処理によって、配信サーバ群1D〜1Fの接続数が変えられる(例えば、図15乃至図19の処理において、配信サーバ1Aが配信サーバ群1Dに、配信サーバ1Bが配信サーバ群1Eに、配信サーバ1Cが配信サーバ群1Fに、夫々対応する)。このように構成すれば、配信サーバ群のうちの1つの配信サーバが機能停止(ダウン)したときでも、その影響を受けることなくコンテンツデータを再生出力することができる。
(IV)第4実施形態
次に、第4実施形態におけるコンテンツ配信システムについて説明する。
第4実施形態では、図14に示す複数(ここでは、3つ)の配信サーバ1A,1B,1Cとの接続が順次切り換えられ、コンテンツデータが端末装置2に配信される形態について説明する。
なお、第4実施形態における配信サーバ1A,1B,1C、及び端末装置2の構成及び機能は第1実施形態における配信サーバ1及び端末装置2と基本的には同様であるので、重複した説明は省略する。
また、第4実施形態においても、第3実施形態と同様、配信サーバ1A,1B,1Cは、夫々、コンテンツデータ(データパケット)の転送速度が相互に異なっており、この3つの配信サーバの中で、転送速度は、配信サーバ1Aが1番速く、配信サーバ1Bは配信サーバ1Aよりは遅いが配信サーバ1Cよりは速く、配信サーバ1Cは1番遅くなっている。これらの配信サーバ1A,1B,1Cは、同一のコンテンツデータを有している。
一方、端末装置2における速度制御手段としての制御部29は、コンテンツデータのバッファ量に基づく転送速度を変更するタイミングで、配信サーバの接続を切り換えるように制御する。
この転送速度制御について図4を用いて説明すると、例えば、“A”の期間では、転送速度の最も速い配信サーバ1Aから第1転送速度(配信サーバ1Aにおいて最も速い速度(フルスピード))でデータパケットが配信されるように制御され、“A”の期間と“B”の期間との境界で配信サーバ1Aから配信サーバ1Bに切り換えられ、“B”の期間では、転送速度が普通の配信サーバ1Bから第2転送速度でデータパケットが配信されるように制御され、“B”の期間と“C”の期間との境界で配信サーバ1Bから配信サーバ1Cに切り換えられ、“C”の期間では、転送速度の最も遅い配信サーバ1Cから第3転送速度でデータパケットが配信されるように制御される。
次に、図22乃至図26等を参照して、第4実施形態におけるコンテンツ配信システムの動作について説明する。
図22乃至図26は、第4実施形態のコンテンツデータ配信の際における端末装置2の制御部29の処理を示すフローチャートである。
図22に示す処理は、第1実施形態と同様、例えばユーザから入力部30を介して所望のコンテンツの要求指示があった場合に開始され、先ず、制御部29は、バッファメモリ22における現在のバッファ量を確認し(ステップS171)、再生可能バッファ量53未満である場合には(ステップS171:L)、ステップS172に示す第1転送速度での要求処理(図23)に移行し、再生可能バッファ量53以上設定バッファ量54未満である場合には(ステップS171:M)、ステップS173に示す第2転送速度での要求処理(図24)に移行し、設定バッファ量54以上である場合には(ステップS171:H)、ステップS174に示す第3転送速度での要求処理(図25)に移行する。
第1転送速度での要求処理においては、図23に示すように、制御部29は、配信サーバ1Aの接続処理を行う(ステップS181)。当該配信サーバ1Aの接続処理においては、図26(A)に示すように、制御部29は、転送速度の最も速い配信サーバ1Aに対して接続要求を行い(ステップS215)、続いて、配信サーバ1Aとの間の接続確立処理を行い(ステップS216)、続いて、配信サーバ1Aに対してコンテンツデータの配信要求を行う(ステップS217)。
次いで、制御部29は、配信サーバ1A以外の接続している配信サーバが有るか否かを判別し(ステップS218)、有る場合には(ステップS218:Y)、配信サーバ1A以外の配信サーバとの接続を切り(ステップS219)、図23の処理に戻る。
なお、図23に示すステップS182〜ステップS192までの処理は、図6に示すステップS11〜ステップS21までの処理と同様であるので重複する説明を省略する。
次に、第2転送速度での要求処理においては、図24に示すように、制御部29は、配信サーバ1Bの接続処理を行う(ステップS195)。当該配信サーバ1Bの接続処理においては、図26(B)に示すように、制御部29は、配信サーバを切り換えるべく、転送速度の最も速い配信サーバ1Bに対して接続要求を行い(ステップS221)、続いて、配信サーバ1Bとの間の接続確立処理を行い(ステップS222)、続いて、配信サーバ1Bに対してコンテンツデータの配信要求を行い(ステップS223)、配信サーバ1B以外の配信サーバとの接続を切り(ステップS224)、図24の処理に戻る。
なお、図24に示すステップS196〜ステップS201までの処理は、図7に示すステップS23〜ステップS28までの処理と同様であるので重複する説明を省略する。
次に、第3転送速度での要求処理においては、図25に示すように、制御部29は、配信サーバ1Cの接続処理を行う(ステップS205)。当該配信サーバ1Cの接続処理においては、図26(C)に示すように、制御部29は、配信サーバを切り換えるべく、転送速度の最も速い配信サーバ1Cに対して接続要求を行い(ステップS226)、続いて、配信サーバ1Cとの間の接続確立処理を行い(ステップS227)、続いて、配信サーバ1Cに対してコンテンツデータの配信要求を行い(ステップS228)、配信サーバ1C以外の配信サーバとの接続を切り(ステップS22))、図25の処理に戻る。
なお、図25に示すステップS206〜ステップS211までの処理は、図8に示すステップS31〜ステップS36までの処理と同様であるので重複する説明を省略する。
以上説明したように上記第4実施形態によれば、第1実施形態と同様の効果を有することに加え、例えば他の配信サーバに比べ転送速度の速い配信サーバを多くの端末装置で効率良く利用することができる。
なお、上記第4実施形態においては、転送速度が相互に異なる複数の配信サーバを例にとって説明したがこれに限定されるものではなく、第3実施形態と同様、例えば、コンテンツ配信システムが、相互に同一の転送速度を有する複数の配信サーバからなる配信サーバ群であって、転送速度が相互に異なる複数の配信サーバ群(例えば、図21に示すように)を備えるようにし、端末装置2の制御部29が、上記転送速度を変更するタイミングで、当該転送速度が異なる配信サーバ群に接続を切り換える(例えば、図22乃至図26の処理において、配信サーバ群1D→配信サーバ群1E→配信サーバ群1Fの順に切り換えられる)。このように構成すれば、配信サーバ群のうちの1つの配信サーバが機能停止(ダウン)したときでも、その影響を受けることなくコンテンツデータを再生出力することができる。
(V)第5実施形態
次に、第5実施形態におけるコンテンツ配信システムについて説明する。
第5実施形態では、第4実施形態と同様、図14に示す複数(ここでは、3つ)の配信サーバ1A,1B,1Cとの接続が順次切り換えられ、コンテンツデータが端末装置2に配信される形態であるが、第5実施形態では、第1〜第3転送速度が端末装置2の要求タイミングで決まるクライアント主導型の形態(第2実施形態と同様)について、図26乃至図30等を参照して説明する。なお、第5実施形態における配信サーバ1A,1B,1C、及び端末装置2の構成及び機能は第1実施形態における配信サーバ1及び端末装置2と基本的には同様であるので、重複した説明は省略する。
図27乃至図30は、第5実施形態のコンテンツデータ配信の際における端末装置2の制御部29の処理を示すフローチャートである。
図27に示す処理は、第1実施形態と同様、例えばユーザから入力部30を介して所望のコンテンツの要求指示があった場合に開始され、先ず、制御部29は、コンテンツデータを構成するデータブロックの番号iの初期値として“0”を設定(i=0に設定)する(ステップS231)。
次いで、制御部29は、第2実施形態と同様、バッファメモリ22における現在のバッファ量を確認し(ステップS232)、再生可能バッファ量53未満である場合には(ステップS232:L)、ステップS233に示す第1待ち時間での要求処理(図28)に移行し、再生可能バッファ量53以上設定バッファ量54未満である場合には(ステップS232:M)、ステップS234に示す第2待ち時間での要求処理(図29)に移行し、設定バッファ量54以上である場合には(ステップS232:H)、ステップS235に示す第3待ち時間での要求処理(図30)に移行する。
第1待ち時間での要求処理においては、図28に示すように、制御部29は、配信サーバ1Aの接続処理(第4実施形態と同様、図26(A)の処理)を行う(ステップS241)。
なお、図28に示すステップS242〜ステップS254までの処理は、図10に示すステップS51〜ステップS63までの処理と同様であるので重複する説明を省略する。
次に、第2転送速度での要求処理においては、図29に示すように、制御部29は、配信サーバ1Bの接続処理(第4実施形態と同様、図26(B)の処理)を行う(ステップS256)。
なお、図29に示すステップS257〜ステップS264までの処理は、図11に示すステップS65〜ステップS72までの処理と同様であるので重複する説明を省略する。
次に、第3転送速度での要求処理においては、図30に示すように、制御部29は、配信サーバ1Cの接続処理(第4実施形態と同様、図26(C)の処理)を行う(ステップS271)。
なお、図30に示すステップS272〜ステップS279までの処理は、図12に示すステップS75〜ステップS82までの処理と同様であるので重複する説明を省略する。
以上説明したように上記第5実施形態によっても、第4実施形態と同様の効果を有することができる。
なお、上記第1乃至第5実施形態においては、本発明を、サーバ−クライアント型のコンテンツ配信システムに対して適用したが、これに限定されるものではなく、ピアツーピア(Peer to Peer(P2P))型のコンテンツ配信システムに対して適用しても良い。ピアツーピア型のコンテンツ配信システムでは、各ピア(ノード)が上述した配信サーバと端末装置としての機能を有することになる。このようなピアツーピア型のコンテンツ配信システムでは、各ノードの配信速度(転送速度)等の能力に差があるので、本発明を適用し、上述したように転送速度を段階的に変更するように制御することは特に有効である。
また、配信サーバを最上位として複数のノードが複数の階層を形成しつつ通信回線を介してツリー状に接続されたツリー構造ネットワークを有し、配信サーバにより配信されたコンテンツデータが上位階層のノードから下位階層のノードに順次転送されていくようなツリー型コンテンツ配信システムに対しても本発明を適用可能である。この場合、コンテンツデータの配信が開始される際ばかりでなく、コンテンツデータを自ノードに対して転送する直近の上位階層のノードが当該ツリー構造ネットワークから脱退(例えば、電源断等による)したことによって、当該自ノードが他の上位階層のノードに再接続してコンテンツデータの転送を受ける際にも、本発明を適用し、コンテンツデータの再生出力速度以上の範囲において、バッファ量に応じて上記転送速度を段階的に変更(減速)するようにすれば、有効である。
なお、上記実施形態では、再生可能バッファ量53未満のとき第1転送速度、再生可能バッファ量53以上設定バッファ量54未満のとき第2転送速度、設定バッファ量54以上のとき第3転送速度にしていたが、再生可能バッファ量53以下のとき第1転送速度、再生可能バッファ量53より多くかつ設定バッファ量54以下のとき第2転送速度、設定バッファ量54より多いとき第3転送速度にしてもよい。また、再生可能バッファ量53未満のとき第1転送速度、再生可能バッファ量53以上かつ設定バッファ量54以下のとき第2転送速度、設定バッファ量54より多いとき第3転送速度にしてもよい。また、再生可能バッファ量53以下のとき第1転送速度、再生可能バッファ量53より多くかつ設定バッファ量54未満のとき第2転送速度、設定バッファ量54以上のとき第3転送速度にしてもよい。なお、本発明における速度制御手段は、バッファメモリにおけるバッファ量に応じて、コンテンツデータの転送速度(配信速度)を、再生出力速度より速い第1転送速度と、第1転送速度より遅く、且つ、再生出力速度より速い第2転送速度と、再生出力速度に追従する第3転送速度と、に切り換えるように制御するものであって、どのバッファ量になったときに転送速度を切り換えるのかに特に限定されるものではない。