JP2007036666A - コンテンツ配信システム、クライアント及びクライアントプログラム - Google Patents

Abstract

【課題】コンテンツの所定の位置で再生ビットレートの変更が可能なコンテンツ配信システムを提供する。
【解決手段】サーバ１０は、同じコンテンツに関し、互いに異なるビットレートを有し、複数のパートに分割されたストリームデータＳＴｉ（ｉ＝１〜３）を有する。クライアント２０は、サーバ１０から配信されたストリームデータＳＴｉを受信しながら再生する。このとき、クライアント２０は、各パートの再生を完了するごとに、次のパートのデータ量が既にバッファ領域２７Ａ及び２７Ｂに蓄積されているか否かを判断する。蓄積されている場合、次のパートの再生時間中にバッファ領域２７Ａ及び２７Ｂに蓄積可能なデータ量を算出し、その算出結果に基づいて、サーバ１０に要求するストリームデータＳＴｉを選択する。
【選択図】図１

Description

本発明は、コンテンツ配信システム、クライアント及びクライアントプログラムに関し、さらに詳しくは、サーバからクライアントにコンテンツをストリーム配信するコンテンツ配信システム、クライアント及びクライアントプログラムに関する。

ストリーミング型コンテンツ配信システムは、動画等のコンテンツに関する複数のストリームデータを有するサーバと、サーバからストリームデータの配信を受けながらコンテンツを再生するクライアントとを備える。

このようなストリーミング型のコンテンツ配信システムでは、ネットワークのトラフィック状態が変化しても、クライアントで再生が途切れないようにする必要がある。

この問題を解決すべく、特開２００４−２１５０７４号公報（特許文献１）では、サーバに予め異なるビットレートの複数のストリームデータを準備し、ネットワークのトラフィック状態に応じて、適切な再生ビットレートのストリームデータを配信できるマルチビットレート方式が開示されている。また、特開２００３−２５９３３３号公報（特許文献２）では、ネットワークの状況に応じてサーバがコンテンツの圧縮率やフレームレートを変更できるコンテンツ配信システムが開示されている。これらの方法によれば、ストリーム配信中にクライアントで再生が途切れるのを防止できるとしている。

しかしながら、これらの方法では、再生ビットレートや圧縮率、フレームレートの変更タイミング時に、クライアントが蓄積するデータが枯渇して再生が途切れる可能性がある。さらに、これらの方法では、再生中のコンテンツの内容に依存せずに、ネットワークの状況に依存してビットレートを変更する。つまり、再生中の動画がどのような場面であっても、ビットレートを変更して画質を変化させる。そのため、画質の変化が唐突に発生し、コンテンツを視聴する利用者に違和感を与えてしまう。
特開２００４−２１５０７４号公報 特開２００３−２５９３３３号公報

本発明の目的は、ストリーム配信中の再生の途切れを防止するコンテンツ配信システムを提供することである。
本発明の他の目的は、コンテンツの所定の位置で再生ビットレートの変更が可能なコンテンツ配信システムを提供することである。

課題を解決するための手段及び発明の効果

本発明によるコンテンツ配信システムは、サーバと、サーバに接続されたクライアントとを備える。サーバは、ストリームデータ蓄積手段と、配信手段とを備える。ストリームデータ蓄積手段は、複数のストリームデータを蓄積する。複数のストリームデータは、各々が、同一のコンテンツに関し、互いに異なる再生ビットレートを有し、連続して配列される複数のパートに分割される。配信手段は、クライアントの要求に対応してストリームデータのパートを配列順にストリーム配信する。クライアントは、バッファ手段と、再生手段と、判断手段と、データ量算出手段と、選択手段と、要求手段とを備える。バッファ手段は、ストリーム配信されたパートを順次蓄積する。再生手段は、バッファ手段に蓄積されたパートを順次再生する。判断手段は、パートの再生が完了したとき、未再生のパートがバッファ手段に蓄積されているか否かを判断する。データ量算出手段は、判断の結果、未再生のパートが蓄積されているとき、未再生のパートの再生時間でバッファ手段に蓄積可能なデータ量を算出する。選択手段は、算出結果に基づいて、サーバに要求するストリームデータ及び配信開始パートを選択する。要求手段は、選択されたストリームデータを、配信開始パートからストリーム配信するよう要求する。

このコンテンツ配信システムでは、クライアントは、予め未再生のパートを蓄積し、未再生のパートの再生時間に蓄積可能なデータ量に基づいてストリームデータを選択し、その未再生のパートを再生している間、選択したストリームデータを順次取得する。そのため、再生すべきデータが枯渇するのを防止でき、コンテンツの再生が途切れるのを防止できる。さらに、ストリームデータをパート単位で順次受信し、再生するため、再生ビットレートをパート単位で変更できる。つまり、再生ビットレートの変更位置を所定の位置（パートとパートとの区切りの位置）とすることができる。各パートを、画質や音質が変化しても視聴への影響が少ない再生位置、たとえば、動画の場合であれば、場面設定が変更する位置等で区切れば、再生ビットレートが変更しても、画質や音質の変化による違和感を抑えることができる。

好ましくは、データ量算出手段は、配信ビットレート特定手段を備える。配信ビットレート特定手段は、パートの再生が完了したとき、サーバから配信されるストリームデータの配信ビットレートを特定する。データ量算出手段は、特定した配信ビットレートと、未再生のパートの再生時間とに基づいて、データ量を算出する。

この場合、パートの再生が完了した時点の配信ビットレートを特定し、データ量を算出する。そのため、データ量算出手段により算出した値を実際に蓄積されるデータ量に近づけることができ、蓄積されるデータ量の予測精度を上げることができる。

好ましくは、クライアントは、ストリーム情報蓄積手段を備える。ストリーム情報蓄積手段は、ストリームデータの各パートのデータ量及び再生時間と、各パートに対応する他のストリームデータのパートとに関するストリーム情報を蓄積する。選択手段は、算出結果とストリーム情報とに基づいて、ストリームデータ及び配信開始パートを選択する。

この場合、ストリーム情報に基づいて、データ量算出手段により算出されたデータ量を
各パートのデータ量と比較し、ストリームデータ及び配信開始パートを選択できる。

好ましくは、判断手段が判断した結果、未再生のパートがバッファ手段に蓄積されていないとき、選択手段は、複数のストリームデータのうち、再生ビットレートが最も低いストリームデータを選択する。

この場合、未再生のパートがバッファ手段に蓄積されていなくても、再生ビットレートが最も低いストリームデータを取得することにより、再生の途切れをある程度防止できる。

本発明によるクライアントプログラムは、各々が、同一のコンテンツに関し、互いに異なる再生ビットレートを有し、連続して配列される複数のパートに分割された複数のストリームデータを蓄積するサーバに接続可能なクライアントコンピュータに実行させるプログラムである。クライアントプログラムは、サーバからストリーム配信されたパートを順次蓄積するステップと、蓄積されたパートを順次再生するステップと、パートの再生が完了したとき、未再生のパートが蓄積されているか否かを判断するステップと、判断の結果、未再生のパートが蓄積されているとき、未再生のパートの再生時間で蓄積可能なデータ量を算出するステップと、算出結果に基づいて、サーバに要求するストリームデータ及び配信開始パートを選択するステップと、選択されたストリームデータを、配信開始パートからストリーム配信するよう要求するステップとをクライアントコンピュータに実行させる。

このクライアントプログラムは、予め未再生のパートを蓄積し、未再生のパートの再生時間に蓄積可能なデータ量に基づいてストリームデータを選択し、その未再生のパートを再生している間、選択したストリームデータを順次取得する。そのため、再生すべきデータが枯渇するのを防止でき、コンテンツの再生が途切れるのを防止できる。さらに、ストリームデータをパート単位で順次受信し、再生するため、再生ビットレートをパート単位で変更できる。つまり、再生ビットレートの変更位置を所定の位置（パートとパートとの区切りの位置）とすることができる。

以下、図面を参照し、本発明の実施の形態を詳しく説明する。図中同一又は相当部分には同一符号を付してその説明は繰り返さない。

１．構成
図１を参照して、コンテンツ配信システムは、サーバ（コンピュータ）１０と、複数のクライアント（コンピュータ）２０とを備える。サーバ１０とクライアント２０とは、インターネット３０経由で接続されるが、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、その他のコンピュータネットワークで接続されてもよい。

サーバ１０は、動画や音楽等のコンテンツに関する複数のストリームデータを蓄積し、クライアント２０からの要求に応答して、ストリームデータをストリーム配信する。要するに、このシステムは、ストリーミング型のコンテンツ配信システムである。

［サーバの構成］
図１を参照して、サーバ１０は、ハードディスクドライブ（ＨＤＤ）１１と、ＣＰＵ１２と、メモリ１３とを備える。これらは、バス１７で互いに接続される。

ＨＤＤ１１は、複数のストリームデータＳＴ１〜ＳＴ３を蓄積する。ストリームデータＳＴ１〜ＳＴ３は、同一コンテンツに関するストリームデータであり、互いに異なる再生ビットレートを有する。ストリームデータＳＴ１〜ＳＴ３の構造については後述する。ＨＤＤ１１は、ストリームデータＳＴ１〜ＳＴ３と異なるコンテンツに関する複数のストリームデータも蓄積する。

ＨＤＤ１１はさらに、ストリーム情報データベース１５とサーバアプリケーション（プログラム）１６とを記憶する。ストリーム情報データベース１５は、上述した複数のストリームデータに関する情報を登録する。ストリーム情報データベース１５については後述する。

サーバアプリケーション（プログラム）１６は、クライアント２０からの要求に対応したストリームデータをストリーミング配信する。ＣＰＵ１２は、サーバアプリケーション１６をメモリ１３に読み出して、上記のサーバアプリケーション１６の動作を実行する。

［ストリームデータの構造］
図２にストリームデータＳＴ１〜ＳＴ３のデータ構造を示す。横軸は再生時間を示す。また、各ストリームデータＳＴ１〜ＳＴ３の面積は、データ量を示す。

ストリームデータＳＴ１〜ＳＴ３は、互いに異なる再生ビットレートＢＲ１〜ＢＲ３を有する。ストリームデータＳＴ１の再生ビットレートＢＲ１が最も低く、ストリームデータＳＴ２の再生ビットレートＢＲ２は再生ビットレートＢＲ１よりも高く、ストリームデータＳＴ３の再生ビットレートＢＲ３が最も高い。したがって、ストリームデータＳＴ３のデータ量が最も多く、ストリームデータＳＴ１のデータ量が最も少ない。

ストリームデータＳＴ１〜ＳＴ３のデータ量は互いに異なるものの、その再生時間は同じである（時刻ｔ０〜時刻ｔ８）。同一のコンテンツに基づいて作成されているためである。

各ストリームデータＳＴ１〜ＳＴ３は、連続的に配列された複数のパート（Ｐ０〜Ｐ７）に分割される。このとき、各パートＰｊ（パート番号ｊ＝０〜７）は、画質や音質が変化しても視聴への影響が少ない再生位置（時刻ｔ１〜ｔ７）で区切られる。たとえば、動画の場合であれば、場面設定が変更される位置等で区切られる。そのため、各パートＰ０〜Ｐ７の再生時間（Ｄ０〜Ｄ７）は互いに異なる。

ストリームデータＳＴ１〜ＳＴ３は、同じ再生位置（ｔ１〜ｔ７）で分割されるため、各ストリームデータの同じパートＰｊは同じ再生時間Ｄｊを有する。たとえば、ストリームデータＳＴ１のパートＰ０と、ストリームデータＳＴ２のパートＰ０と、ストリームデータＳＴ３のパートＰ０とは、同じ再生時間Ｄ０を有する。

［ストリーム情報データベース］
図３を参照して、ストリーム情報データベース１５は、各ストリームデータＳＴｉ（レート番号ｉ＝１〜３）に関する情報が登録されるデータブロック１５１で構成される。

各データブロック１５１は、ストリームデータの識別子ＳＴｉ（たとえばＳＴ１）と、再生ビットレート情報ＢＲｉ（たとえばＢＲ１）とを有する。データブロック１５１はさらに、パートリストを有する。パートリストは、各ストリームデータＳＴｉのパートＰｊに関する情報を登録する。具体的には、パートリストは、そのストリームデータＳＴｉが有するパート数分のレコードを有する。各レコードは、パート識別子（たとえばＰ０、Ｐ１等）を登録するフィールドと、再生時間Ｄｊを登録するフィールドと、対応するパートＰｊのデータ量ＳＺ（ｉ，ｊ）を登録するフィールドとを有する。

ストリームデータＳＴ１〜ＳＴ３のデータブロック１５１を参照して、各データブロック１５１の同じ番号のパート識別子は互いに対応する。たとえば、ストリームデータＳＴ１のパートＰ１はストリームデータＳＴ２及びＳＴ３のパートＰ１に対応する。上述したとおり、各パート識別子の再生時間は同じであるが、データ量は異なる。

このように、ストリーム情報データベース１５は、ストリームデータに関する情報と、各ストリームデータ内の各パートの再生時間、データ量に関する情報と、各ストリームデータのパートに対応する他のストリームデータのパートに関する情報とを含む。

［クライアントの構成］
再び図１を参照して、クライアント２０は、ＨＤＤ２１と、ＣＰＵ２２と、メモリ２３と、ディスプレイ２４とを備える。これらはバス２６で相互に接続される。

ＨＤＤ２１は、クライアントアプリケーション（プログラム）２５を記憶する。クライアントアプリケーション２５は、サーバ１０にストリームデータＳＴｉを要求したり、受信したストリームデータＳＴｉのパートＰｊに基づくコンテンツを再生したりする。クライアントアプリケーション２５はさらに、再生中にサーバ１０に要求するストリームデータＳＴｉを選択する。詳細は後述する。

ＨＤＤ２１はさらに、内部にバッファ領域２７Ａ、２７Ｂ（これらをまとめてバッファ領域２７とも称する）を含む。バッファ領域２７は、サーバ１０からストリーム配信されたストリームデータＳＴｉを順次蓄積する。バッファ領域２７Ａ及び２７Ｂは、互いに異なる再生ビットレートＢＲｉのストリームデータＳＴｉを蓄積する。
なお、ＨＤＤ２１はサーバ１０から送信されたストリーム情報データベース１５を記憶する。

ＣＰＵ２２は、クライアントアプリケーション２５をメモリ２３に読み出して、以下に説明するクライアント２０の動作を実行する。

２．動作
２．１．概要
本実施の形態によるコンテンツ配信システムでは、クライアント２０が、サーバ１０から配信されたストリームデータＳＴｉを受信しながら再生する。このとき、クライアント２０は、各パートＰｊの再生を完了するごとに、次のパートＰｊ＋１のデータ量ＳＺ（ｉ，ｊ＋１）が既にバッファ領域２７に蓄積されているか否かを判断する。蓄積されている場合、次のパートＰｊ＋１の再生時間中にバッファ領域２７に蓄積可能なデータ量を算出し、その算出結果に基づいて、サーバに要求するストリームデータＳＴｉを選択する。

図４は、クライアント２０がサーバ１０からストリームデータＳＴｉを受信しながら再生しているときの、配信ビットレートＢＲｃｕｒの変動と、時刻ｔにバッファ領域２７に蓄積されるデータ量ＤＬ（ｔ）とを示すグラフである。配信ビットレートＢＲｃｕｒとは、サーバ１０からクライアント２０にストリーム配信されるデータの配信時のビットレート（ｂｉｔ／ｓｅｃ）である。図４中の上部グラフが配信ビットレートＢＲｃｕｒの変動を示し、縦軸はビットレート（ｂｉｔ／ｓｅｃ）である。図４中の下部のグラフは、バッファ領域２７に蓄積されるデータ量ＤＬ（ｔ）を示し、縦軸はデータ量（ｂｙｔｅｓ）である。グラフ中のＤ_ＳＴ１〜Ｄ_ＳＴ３は、各ストリームデータＳＴ１〜ＳＴ３の再生に必要なデータ量を示す。なお、いずれのグラフも、横軸は時間（ｓｅｃ）である。

図４を参照して、クライアント２０は、初めにストリームデータＳＴｉ（たとえばＳＴ３）をサーバ１０に要求する。クライアント２０は、サーバ１０からストリームデータＳＴ３を受け、バッファ領域２７に蓄積する。蓄積したデータ量が所定のデータ量ＤＬ（ｔ０）となったとき、クライアント２０は再生を開始する。時刻ｔ０〜時刻ｔ２において、配信ビットレートＢＲｃｕｒは、再生ビットレートＢＲ３よりも高い。そのため、再生するデータ量よりも受信するデータ量の方が多くなる。つまり、図４中のＤＬ（ｔ）の傾きの方が、Ｄ_ＳＴ３の傾きよりも大きくなる。そのため、バッファ領域２７にデータが順次蓄積される。

クライアント２０は、パートＰ０の再生が終了した時刻ｔ１において、サーバに要求するストリームデータＳＴｉを選択する（データ要求処理：図６）。データ要求処理では、次のパート（パートＰ１）の全データ量ＳＺ（３，１）が既にバッファ領域２７に蓄積されているか判断し、既に蓄積されている場合、パートＰ１の再生時間Ｄ１中にバッファ領域２７に蓄積可能なデータ量に基づいて、再生ビットレートＢＲ３（ストリームデータＳＴ３）を変更するか否かを判断する。時刻ｔ１では、データ量ＳＺ（３，１）が既にバッファ領域２７に蓄積されており、かつ、再生ビットレートＢＲ３のまま維持すると判断し、そのまま再生を継続する。

時刻ｔ２１で配信ビットレートＢＲｃｕｒは低下し、再生ビットレートＢＲ３よりも低くなる。そのため、時刻ｔ２１以降、バッファ領域２７に蓄積されているデータ量ＤＬ（ｔ）は減少する。つまり、図４中のＤＬ（ｔ）の傾きの方が、Ｄ_ＳＴ３の傾きよりも小さくなる。
クライアント２０は、時刻ｔ３でデータ要求処理を実施し、次のパートＰ３のデータ量ＳＺ（３，３）は既に蓄積しているものの、このまま再生を続けると、パートＰ４の再生中に蓄積したデータが枯渇する（図４中のＤＬ（ｔ）がＤ_ＳＴ３よりも低くなる）と判断する。このとき、クライアント２０は、再生するデータをストリームデータＳＴ２（ビットレートＢＲ２）に切り替えればパートＰ４以降も再生が途切れないと判断し、サーバ１０にストリームデータＳＴ２をパートＰ４から配信するよう要求する。この動作により、クライアント２０は時刻ｔ４（パートＰ４）以降ストリームデータＳＴ２を再生する。

時刻ｔ５１で配信ビットレートＢＲｃｕｒは再び上昇し、再生ビットレートＢＲ３よりも高くなる。クライアント２０は、時刻ｔ６で、ストリームデータＳＴ２のパートＰ６のデータＳＺ（２，６）を既に蓄積していると判断し、さらに、パートＰ６の再生時間Ｄ６中にストリームデータＳＴ３（再生ビットレートＢＲ３）のパートＰ７のデータＳＺ（３，７）を蓄積できると判断する。その結果、時刻ｔ６でクライアント２０は、サーバ１０にストリームデータＳＴ３をパートＰ７から配信するよう要求する。クライアント２０は、再生時間Ｄ６中にストリームデータＳＴ３のパートＰ７のデータＳＺ（３，７）を取得し、時刻ｔ７以降にそのデータを再生する。

以上のとおり、クライアント２０は、パートＰｊの再生を完了したとき、原則として、次に再生すべきパートＰｊ＋１を蓄積する。さらに、パートＰｊ＋１の再生時間Ｄｊ＋１中に蓄積可能なデータ量に基づいて、次のパートＰｊ＋２のデータをどの再生ビットレートＢＲｉ（ストリームデータＳＴｉ）にするか選択し、選択したストリームデータＳＴｉのパートＰｊ＋２を取得する。そのため、コンテンツの再生が途切れるのを防止できる。
さらに、再生ビットレートＢＲｉを切り替える場合、クライアント２０は、パートＰｊ単位で切り替える。各パートＰｊは、画質や音質が変更しても違和感が少ない位置で予め区切られているため、画質や音質が変化することによる視聴への影響を極力抑えることができる。また、再生ビットレートＢＲｉ（ストリームデータＳＴｉ）の変更をクライアント２０で判断するため、サーバの負荷が軽減される。以下、フロー図を用いてコンテンツ配信システムの動作を詳述する。

２．２．全体動作
図５を参照して、まず、クライアント２０は、所望のコンテンツのストリーム情報データベース１５を要求する（Ｓ１）。サーバ１０は、クライアント２０からの要求を監視し（Ｓ２）、要求を受けたとき（Ｓ２でＹＥＳ）、対応するストリーム情報データベース１５を送信する（Ｓ３）。

クライアント２０はストリーム情報データベース１５を受け、各ストリームデータＳＴ１〜ＳＴ３の再生ビットレートＢＲ１〜ＢＲ３に関する情報をディスプレイ２４に表示する。クライアント２０のユーザは、ディスプレイ２４を参照し、再生ビットレート（たとえばＢＲ３）を選択する。クライアント２０は、ユーザ操作に基づいて、選択された再生ビットレートＢＲ３のストリームデータＳＴ３をパートＰ０から配信するようサーバ１０に要求する（Ｓ４）。具体的には、クライアント２０は、ストリーム情報データベース１５を参照し、ビットレート情報ＢＲ３に対応したストリームデータ識別子＝ＳＴ３と、パート識別子＝Ｐ０とを含む配信要求コマンドをサーバ１０に送信する。

サーバ１０は、クライアント２０からの配信要求を監視し（Ｓ５）、配信要求コマンドを受けたとき（Ｓ５でＹＥＳ）、配信要求コマンドに基づいてストリームデータＳＴ３をパートＰ０からストリーム配信する（Ｓ６）。

クライアント２０は、サーバ１０からデータを受信したか否かを監視し（Ｓ７）、データを受信したとき（ステップＳ７でＹＥＳ）、受信したデータをバッファ領域２７に順次蓄積する（Ｓ８）。このとき、クライアント２０は、バッファ領域２７Ａ、２７Ｂのいずれか（たとえば２７Ａ）を受信バッファに指定し、受信バッファに指定されたバッファ領域２７Ａにデータを蓄積する。以降、受信バッファに指定されたバッファ領域２７を単に受信バッファとも称する。

クライアント２０は、受信バッファに蓄積されたデータ量ＤＬ（ｔ）がパートＰ０のデータ量ＳＺ（３，０）を超えたか否かを判断し（Ｓ９）、超えたとき（Ｓ９でＹＥＳ）、パートＰ０の再生を開始する（Ｓ１０）。このとき、クライアント２０はデータ量ＤＬ（ｔ）を有するバッファ領域２７Ａを再生バッファに指定し、指定された再生バッファからデータを読み出し、パートＰ０の再生を開始する。この場合、１つのバッファ領域２７Ａが受信バッファ及び再生バッファとして機能する。以降、再生バッファに指定されたバッファ領域１７を単に再生バッファとも称する。

再生後、クライアント２０は、各パートＰｊの再生を完了するごとに、サーバ１０に要求するストリームデータＳＴｉを選択し、選択したストリームデータＳＴｉの配信を要求する（Ｓ１１：データ要求処理）。サーバ１０は、クライアント２０の要求に応答して、ストリームデータＳＴｉを配信する（Ｓ１２）。サーバ１０は、ストリームデータＳＴｉの最後のパートＰ７の配信を完了したとき（Ｓ１４でＹＥＳ）、動作を終了する。

クライアント２０は、サーバ１０から受信したストリームデータＳＴｉの再生を継続し（Ｓ１３：再生処理）、ストリームデータＳＴｉを全て再生したときに動作を終了する。

ステップＳ１１のデータ要求処理と、ステップＳ１３の再生処理とは、各パートＰｊの再生が完了するごとに実施される。以下、データ要求処理及び再生処理について説明する。

２．３．データ要求処理
データ要求処理は、各パートＰｊの再生が完了するごとに実行される。データ要求処理は、まず、要求するストリームデータＳＴｉ及び配信を開始するパート（配信開始パート）Ｐｊを選択する（図６：ストリームデータ選択処理）。続いて、選択したストリームデータＳＴｉを配信開始パートＰｊから配信するよう要求する（図７：要求処理）。

２．３．１．ストリームデータ選択処理
クライアント２０は、パートＰｊの再生を完了したとき、次のパートＰｊの全データを既に蓄積しているか否かを判断する。蓄積している場合、次のパートＰｊの再生時間Ｄｊ中に受信バッファに蓄積可能な受信データ量に基づいて、再生ビットレートＢＲｉを変更するか否か判断し、要求するストリームデータＳＴｉを選択する。以下、詳細を説明する。

図６を参照して、パートＰｊ（たとえばｊ＝０）の再生が完了し（Ｓ２１でＹＥＳ）、かつ、パートＰｊが最終パートＰ７でない場合（Ｓ２２でＮＯ）、クライアント２０は、現在の配信ビットレートＢＲｃｕｒを特定する（Ｓ２３）。具体的には、以下の式（１）に基づいて、現在の配信ビットレートＢＲｃｕｒ（ｂｉｔ／ｓｅｃ）を算出する。

ＢＲｃｕｒ＝（ＤＬ（ｔｊ＋１）−ＤＬ（ｔｊ））×８／Ｄｊ （１）
ｊ＝０の場合、ＢＲｃｕｒ＝（ＤＬ（ｔ１）−ＤＬ（ｔ０）／Ｄ０となる。要するに、再生が完了したパートＰｊの再生時間Ｄｊ（ｓｅｃ）と、その再生時間中にバッファに蓄積された受信データ量ＤＬ（ｔｊ＋１）−ＤＬ（ｔｊ）（ｂｙｔｅｓ）とに基づいて、配信ビットレートＢＲｃｕｒを算出する。配信ビットレートＢＲｃｕｒは再生ビットレートを変更するか否かを判断するときに利用される。

次に、クライアント２０はパート番号ｊをインクリメントし、（Ｓ２４、ｊ＝１とする）、次に再生する予定のパートＰｊ（パートＰ１）がバッファ領域２７に蓄積されているか否かを判断する（Ｓ２５）。具体的には、クライアント２０は、以下の式（２）を満たすか否かを判断する。

ＤＬ_{ｕｎｕｓｅｄ}（ｔｊ）≧ＳＺ（ｉ，ｊ） （２）
ここで、ＤＬ_{ｕｎｕｓｅｄ}（ｔｊ）は、時刻ｔｊにバッファ領域２７に蓄積されたストリームデータＳＴｉの未再生データ量を示す。たとえば、時刻ｔ１におけるステップＳ２５の判断では、ＤＬ_{ｕｎｕｓｅｄ}（ｔ１）≧ＳＺ（ｉ，１）を満たすか否かを判断する。クライアント２０は、ストリーム情報データベース１５に基づいて各パートＰｊのデータ量ＳＺ（ｉ，ｊ）を特定する。

判断の結果、式（２）を満たさない場合（Ｓ２５でＮＯ）、クライアント２０は、次に再生する予定のパートＰｊの全データ量を蓄積しておらず、パートＰｊの一部のデータのみ蓄積している。そのため、クライアント２０は、受信バッファに蓄積されたパートＰｊの部分データを再生せず、代わりに再生するデータとして、最も低い再生ビットレートＢＲ１を有するストリームデータＳＴ１を選択し、配信開始パートをＰｊとする（Ｓ３５）。ストリームデータＳＴ１は、各パートＰｊのデータ量ＳＺ（１，ｊ）が最も少ないため、サーバ１０からデータを受信しながら再生しても、再生の途切れを可能な限り防止できるためである。

一方、ステップＳ２５での判断の結果、式（２）を満たす場合（Ｓ２５でＹＥＳ）、クライアント２０は、次に再生するパートＰｊのデータ量ＳＺ（ｉ，ｊ）を既に受信バッファに蓄積している。そのため、パートＰｊの再生時間Ｄｊ中に、次のパートＰｊ＋１のデータを順次蓄積することができる。そこで、クライアント２０は、ストリームデータＳＴ１〜ＳＴ３のうち、いずれのストリームデータＳＴｉのパートＰｊ＋１を要求するか検討する（Ｓ２０）。

まず、クライアント２０は、既に蓄積されたストリームデータＳＴｉのパートＰｊの再生が完了したときに、ストリームデータＳＴｉのパートＰｊ＋１の全データを蓄積できるか否かを判断する（Ｓ２６）。このとき、クライアント２０は、以下の式（３）を満たすか否かを判断する。

ＤＬ_{ｕｎｕｓｅｄ}（ｔｊ）＋（ＢＲｃｕｒ×Ｄｊ／８）≧ＳＺ（ｉ，ｊ）＋ＳＺ（ｉ，ｊ＋１） （３）
ここで、クライアント２０は、ストリーム情報データベース１５に基づいて、各パートＰｊの再生時間Ｄｊを特定する。
式（３）を満たさない場合（Ｓ２６でＮＯ）、クライアント２０は、パートＰｊの再生完了時に次のパートＰｊ＋１の全データを蓄積できない。そのため、クライアント２０は再生ビットレートＢＲｉを下げる検討を行う（Ｓ２７〜Ｓ２９）。一方、式（３）を満たす場合（Ｓ２６でＹＥＳ）、パートＰｊの再生完了時に、次のパートＰｊ＋１の全データを蓄積できる。つまり、少なくとも今の再生ビットレートＢＲｉで再生を継続できる。したがってこの場合、再生ビットレートＢＲｉをさらに上げることができるか否かを検討する（Ｓ３０〜Ｓ３３）。以下、再生ビットレートＢＲｉを下げる場合（Ｓ２７〜Ｓ２９）と、上げる場合（Ｓ３０〜Ｓ３３）とについて、具体例を挙げながら説明する。

［再生ビットレートを下げる検討（Ｓ２７〜Ｓ２９）］
ストリームデータＳＴ３を受信しながら再生を実行している場合であって、図４中の時刻ｔ３においてデータ要求処理を実行したとき、クライアント２０は、ステップＳ２６で式（３）を満たさないと判断する（Ｓ２６でＮＯ）。つまり、パートＰ３の再生終了時にパートＰ４の全データ量ＳＺ（３，４）を蓄積できないと判断する。
このとき、クライアント２０は再生ビットレートＢＲｉを下げる検討を行う。具体的には、再生時間Ｄ３中にパートＰ４のデータ量ＳＺ（ｉ，４）を取得できるストリームデータＳＴｉを選択する。

クライアント２０は、レート番号ｉ＝ｉ−１（つまりレート番号ｉ＝２）にデクリメントする（Ｓ２７）。デクリメントしたレート番号２は最小値＝１でないため（Ｓ２８でＮＯ）、クライアント２０は、ストリームデータＳＴ２のパートＰｊ＋１（つまりパート４）が、以下の式（４）を満たすか否かを判断する（Ｓ２９）。

ＢＲｃｕｒ×Ｄｊ／８≧ＳＺ（ｉ，ｊ＋１） （４）
ＢＲｃｕｒ×Ｄ３／８≧ＳＺ（２，４）となり、式（４）を満たす場合（Ｓ２９でＹＥＳ）、再生時間Ｄ３内にストリームデータＳＴ２のパートＰ４のデータ量ＳＺ（２，４）を取得できるため、サーバ１０に要求するストリームデータとしてストリームデータＳＴ２を選択し、配信開始パートをＰ４とする（Ｓ３４）。一方、式（４）を満たさない場合（Ｓ２９でＮＯ）、ステップＳ２７に戻り、レート番号ｉをさらにデクリメントしてステップＳ２８及びＳ２９の判断を実行し、要求するストリームデータＳＴｉを選択する（Ｓ３４）。なお、レート番号ｉをデクリメントした結果、ステップＳ２８でレート番号ｉ＝１と判断したとき（Ｓ２８でＹＥＳ）、クライアント２０は、ストリームデータＳＴ１を選択し、配信開始パートをＰ４とする（Ｓ３４）。

［再生ビットレートを上げる検討（Ｓ３０〜Ｓ３３）］
ストリームデータＳＴ２を受信しながら再生している場合であって、図４中の時刻ｔ６においてデータ要求処理を実行したとき、クライアント２０は、ステップＳ２６で式（３）を満たすと判断する（Ｓ２６でＹＥＳ）。つまり、パートＰ６の再生完了時である時刻ｔ７に、ストリームデータＳＴ２のパートＰ７の全データ量ＳＺ（２，７）を蓄積できると判断する。
このとき、クライアント２０は、現在よりも高いビットレートＢＲｉのストリームデータＳＴｉを要求できるか否かを検討する。

クライアント２０は、レート番号ｉ＝ｉ＋１（つまりレート番号ｉ＝３）にインクリメントする（Ｓ３０）。続いて、クライアント２０は、ストリームデータＳＴ３のパートＰｊ＋１（すなわちパートＰ７）が、式（４）を満たすか否かを判断する（Ｓ３１）。

ＢＲｃｕｒ×Ｄ６／８≧ＳＺ（３，７）となり、式（４）を満たすとき（Ｓ３１でＹＥＳ）、現在よりも高いビットレートのストリームデータＳＴ３を取得できる。ここで、レート番号ｉが最大（＝３）であるか否かを判断し（Ｓ３３）、レート番号ｉが最大であるため（Ｓ３３でＹＥＳ）、クライアント２０は、ストリームデータＳＴ３を選択し、配信開始パートをパートＰ７とする（Ｓ３４）。

なお、ステップＳ３３で判断した結果、レート番号ｉが最大でない場合（Ｓ３３でＮＯ）、さらに再生ビットレートＢＲｉを上げることができるか否かを検討するために、ステップＳ３０に戻り、ステップＳ３１〜Ｓ３３を実行する。ステップＳ３１で式（４）を満たさなくなったとき（Ｓ３１でＮＯ）、そのストリームデータＳＴｉのパートＰｊ＋１のデータ量ＳＺ（ｉ，ｊ＋１）を再生時間Ｄｊ中に蓄積できないため、レート番号ｉをデクリメントして１つ下のレート番号ｉに戻し（Ｓ３２）、戻したレート番号ｉのストリームデータＳＴｉを選択し、パートＰｊ＋１を配信開始パートにする（ステップＳ３４）。
以上のストリーム選択処理により、次に再生するパートＰｊの再生時間Ｄｊ中にパートＰｊ＋１の全データＳＺ（ｉ，ｊ＋１）を取得できるストリームデータＳＴｉ（再生ビットレートＢＲｉ）を選択する。そのため、再生すべきデータが途中で枯渇せず、再生の途切れを防止できる。

２．３．２．要求処理
図７を参照して、図６で示したストリームデータ選択処理を実行後（Ｓ１１１）、クライアント２０は、選択したストリームデータＳＴｉが、現在受信しているストリームデータＳＴｉと同じか否かを判断する（Ｓ５１）。同じである場合（Ｓ５１でＹＥＳ）、クライアント２０は既にそのストリームデータＳＴｉを受信し続けているため、そのまま受信を継続する。要するに、この場合はサーバ１０に配信要求コマンドを送信しない。

一方、選択したストリームデータＳＴｉ（たとえばＳＴ２）が現在受信しているストリームデータＳＴｉ（たとえばＳＴ３）と異なる場合（Ｓ５１でＮＯ）、クライアント２０は、サーバ１０に対して、選択されたストリームデータＳＴ２を、配信開始パートＰｊ＋１から配信するよう要求する（Ｓ５４）。具体的には、クライアント２０は、ストリーム情報データベース１５に基づいて、ストリームデータ識別子＝ＳＴ２と、パート識別子＝Ｐｊ＋１とを含む新たな配信要求コマンドを送信する。

なお、新たな配信要求を送信する前に、クライアント２０は、バッファ領域２７Ａ及び２７Ｂのうち、現在受信バッファに指定されているバッファ領域（たとえば２７Ａ）を切り替え（Ｓ５２）。バッファ領域２７Ｂを受信バッファとする。さらに、新たに受信バッファに指定されたバッファ領域２７Ｂに蓄積されているデータを消去しておく（Ｓ５３）。

サーバ１０は、新たな配信要求コマンドを受けたとき、今まで配信していたストリームデータＳＴ３の配信を停止し、選択されたストリームデータＳＴ２を、配信開始パートＰｊ＋１から配信する（Ｓ５５）。

クライアント２０はサーバ１０から配信されたストリームデータＳＴ２を受け、ステップＳ５２で指定した受信バッファ（バッファ領域２７Ｂ）に蓄積する。

以上に示したとおり、今まで受信していたストリームデータＳＴ３と異なる新たなストリームデータＳＴ２を受信する場合、ストリームデータＳＴ２をストリームデータＳＴ３を蓄積しているバッファ領域２７Ａと異なるバッファ領域２７Ｂに蓄積する。
異なるビットレートＢＲｉのストリームデータＳＴｉを同一のバッファ領域に蓄積すると、再生処理が煩雑になる。そこで、異なるビットレートＢＲｉのストリームデータＳＴｉを異なるバッファ領域２７Ａ及び２７Ｂに蓄積し、受信バッファを再生バッファと分けることにより再生処理を容易にする。以下、再生処理について説明する。

２．４．再生処理
再生処理は、各パートＰｊの再生が完了するごとに実施される。図８を参照して、クライアント２０は、再生中のストリームデータＳＴｉ（たとえばＳＴ３）のパートＰｊの再生が完了したか否かを判断する（Ｓ６１）。再生が完了したとき（Ｓ６１でＹＥＳ）、再生を完了したパートＰｊが最終のパートＰ７であるか否かを判断する（Ｓ６２）。パートＰ７である場合（Ｓ６２でＹＥＳ）、コンテンツは全て再生されたため、再生を停止し（Ｓ６８）、再生処理を終了する。

再生を完了したパートＰｊがパートＰ７でない場合（Ｓ６２でＮＯ）、再生は継続される。このとき、クライアント２０は、ストリームデータＳＴ３のパートＰｊの再生完了時に、受信バッファと再生バッファとが同一であるか否かを判断する（Ｓ６３）。つまり、１つのバッファ領域（２７Ａ又は２７Ｂ）が再生バッファ及び受信バッファとして機能していたか否かを判断する。

再生バッファと受信バッファが同一でない場合（Ｓ６３でＮＯ）、クライアント２０は、ストリームデータＳＴ３のパートＰｊの再生時間Ｄｊ中に、異なるストリームデーＳＴｉ（たとえばＳＴ２）のデータを取得している。そのため、次に再生するパートＰｊは、今までの再生バッファ（たとえばバッファ領域２７Ａ）と異なるバッファ領域（たとえば２７Ｂ）に蓄積されている。したがって、再生バッファを切り替え（Ｓ６５）、今までと異なるバッファ領域２７Ｂを再生バッファに指定する。さらに、次に再生するパートＰｊは、今までの再生ビットレートＢＲ３と異なる再生ビットレートＢＲ２であるため、再生ビットレートをＢＲ３からＢＲ２に変更し（Ｓ６６）、再生を開始する（Ｓ６７）。

一方、パートＰｊの再生完了時に、再生バッファと受信バッファとが同一である場合（Ｓ６３でＹＥＳ）、パート番号ｊをインクリメントし（Ｓ６９）、次に再生するストリームデータＳＴ３のパートＰｊのデータ量ＳＺ（３，ｊ）が蓄積されているか否かを判断する（Ｓ６４）。

ここで、データ量ＳＺ（３，ｊ）が蓄積されていない場合（Ｓ６４でＮＯ）とは、図６中のステップＳ２５で式（２）を満たさない場合に相当し、最も低いビットレートＢＲ１のストリームデータＳＴ１のパートＰｊを受信と同時に再生する場合である。この場合、受信と同時に再生を行うため、受信バッファと再生バッファとを同じバッファ領域２７にする必要がある。そのため、再生バッファを切り替え（Ｓ６５）、図７に示した要求処理中のステップＳ５２で切り替えられた受信バッファと再生バッファとを同じバッファ領域２７とする。続いて、再生ビットレートＢＲｉをＢＲ１として（Ｓ６６）、再生を開始する（Ｓ６７）。これにより、ストリームデータＳＴ１を受信と同時に再生できる。

ステップＳ６４の判断の結果、次に再生するパートＰｊ（ストリームデータＳＴ３）のデータ量ＳＺ（３，ｊ）が蓄積されている場合（Ｓ６４でＹＥＳ）、次に再生されるパートＰｊは、今まで再生してきたデータと同じ再生ビットレートＢＲ３であるため、今までと同じ再生ビットレートＢＲ３で再生を開始する（Ｓ６７）。
以上のとおり、受信バッファと再生バッファとが同一であるか否かの判断と、再生バッファ中に次に再生するパートＰｊが蓄積されているか否かの判断を実行すれば、次に再生するパートＰｊの再生ビットレートＢＲｉを判断できる。

上述したコンテンツ配信システムでは、式（１）に基づいて配信ビットレートＢＲｃｕｒを特定したが、他の方法により配信ビットレートＢＲｃｕｒを特定してもよい。たとえば、各再生時間Ｄｊ中の配信ビットレートの変動を測定し、その測定値に基づいて、次に再生するパートＰｊの再生中の配信ビットレートＢＲｃｕｒの変動を予測してビットレートＢＲｃｕｒを特定してもよい。

また、ストリームデータ選択処理（図６）において、ステップＳ３１の判断基準を厳しくしてもよい。たとえば、ステップＳ３１において、式（４）の代わりに以下の式（５）を用いてもよい。

ＢＲｃｕｒ×Ｄｊ／８≧ＳＺ（ｉ，ｊ＋１）＋ＳＺ（ｉ，ｊ＋２） （５）
この場合、再生ビットレートＢＲｉは上がりにくくなるが、ストリームデータＳＴｉの選択の変更頻度は低下するため、コンテンツの画質や音質の変更頻度を抑えることができる。

以上、本発明の実施の形態を説明したが、上述した実施の形態は本発明を実施するための例示に過ぎない。よって、本発明は上述した実施の形態に限定されることなく、その趣旨を逸脱しない範囲内で上述した実施の形態を適宜変形して実施することが可能である。

本発明の実施の形態によるコンテンツ配信システムの構成を示す機能ブロック図である。 図１に示したサーバに蓄積されるストリームデータの構造の詳細を示す図である。 図１に示したサーバ及びクライアントに蓄積されるストリーム情報データベースのデータ構造の詳細を示す図である。 図１に示したコンテンツ配信システムにおける配信ビットレートとクライアントに蓄積されるデータ量との関係を示す図である。 図１に示したコンテンツ配信システムの動作を示すフロー図である。 図５中のステップＳ１１の動作のうち、ストリームデータ選択処理の詳細を示すフロー図である。 図５中のステップＳ１１の動作のうち、図６のストリームデータ選択処理以降に実施される要求処理の動作を示すフロー図である。 図５中のステップＳ１３の動作を示すフロー図である。

符号の説明

１０ サーバ
１１、２１ ハードディスクドライブ
１５ ストリーム情報データベース
１６ サーバアプリケーション
２０ クライアント
２３ メモリ
２５ クライアントアプリケーション
２７、２７Ａ、２７Ｂ バッファ領域

Claims (9)

1. サーバと、前記サーバに接続されたクライアントとを備えたコンテンツ配信システムであって、
   前記サーバは、
   各々が、同一のコンテンツに関し、互いに異なる再生ビットレートを有し、連続して配列される複数のパートに分割された複数のストリームデータを蓄積するストリームデータ蓄積手段と、
   前記クライアントの要求に対応して前記ストリームデータのパートを配列順にストリーム配信する配信手段とを備え、
   前記クライアントは、
   前記ストリーム配信された前記パートを順次蓄積するバッファ手段と、
   前記バッファ手段に蓄積された前記パートを順次再生する再生手段と、
   前記パートの再生が完了したとき、未再生のパートが前記バッファ手段に蓄積されているか否かを判断する判断手段と、
   判断の結果、前記未再生のパートが蓄積されているとき、前記未再生のパートの再生時間で前記バッファ手段に蓄積可能なデータ量を算出するデータ量算出手段と、
   前記算出結果に基づいて、前記サーバに要求するストリームデータ及び配信開始パートを選択する選択手段と、
   前記選択されたストリームデータを、前記配信開始パートからストリーム配信するよう要求する要求手段とを備えることを特徴とするコンテンツ配信システム。
2. 請求項１に記載のコンテンツ配信システムであって、
   前記データ量算出手段は、
   前記パートの再生が完了したとき、前記サーバから配信される前記ストリームデータの配信ビットレートを特定する配信ビットレート特定手段を備え、
   前記特定した配信ビットレートと、前記未再生のパートの再生時間とに基づいて、前記データ量を算出することを特徴とするコンテンツ配信システム。
3. 請求項１又は請求項２に記載のコンテンツ配信システムであって、
   前記クライアントは、
   前記ストリームデータの各パートのデータ量及び再生時間と、前記各パートに対応した他のストリームデータのパートとに関するストリーム情報を蓄積するストリーム情報蓄積手段を備え、
   前記選択手段は、前記算出結果と前記ストリーム情報とに基づいて、前記ストリームデータ及び配信開始パートを選択することを特徴とするコンテンツ配信システム。
4. 請求項１〜請求項３のいずれか１項に記載のコンテンツ配信システムであって、
   前記判断の結果、前記未再生のパートが前記バッファ手段に蓄積されていないとき、前記選択手段は、前記複数のストリームデータのうち、前記再生ビットレートが最も低いストリームデータを選択することを特徴とするコンテンツ配信システム。
5. 各々が、同一のコンテンツに関し、互いに異なる再生ビットレートを有し、連続して配列される複数のパートに分割された複数のストリームデータを蓄積するサーバに接続可能なクライアントであって、
   前記サーバからストリーム配信された前記パートを順次蓄積するバッファ手段と、
   前記バッファ手段に蓄積された前記パートを順次再生する再生手段と、
   前記パートの再生が完了したとき、未再生のパートが前記バッファ手段に蓄積されているか否かを判断する判断手段と、
   判断の結果、前記未再生のパートが蓄積されているとき、前記未再生のパートの再生時間で前記バッファ手段に蓄積可能なデータ量を算出するデータ量算出手段と、
   前記算出結果に基づいて、前記サーバに要求するストリームデータ及び配信開始パートを選択する選択手段と、
   前記選択されたストリームデータを、前記配信開始パートからストリーム配信するよう要求する要求手段とを備えることを特徴とするクライアント。
6. 請求項５に記載のクライアントであって、
   前記データ量算出手段は、
   前記パートの再生が完了したとき、前記サーバから配信される前記ストリームデータの配信ビットレートを特定する配信ビットレート特定手段を備え、
   前記特定した配信ビットレートと、前記未再生のパートの再生時間とに基づいて、前記データ量を算出することを特徴とするクライアント。
7. 請求項５又は請求項６に記載のクライアントであって、
   前記ストリームデータの各パートのデータ量及び再生時間と、前記各パートに対応した他のストリームデータのパートとに関するストリーム情報を蓄積可能なストリーム情報蓄積手段を備え、
   前記選択手段は、前記算出結果と前記ストリーム情報とに基づいて、前記ストリームデータ及び配信開始パートを選択することを特徴とするクライアント。
8. 請求項５〜請求項７のいずれか１項に記載のクライアントであって、
   前記判断の結果、前記未再生のパートが前記バッファ手段に蓄積されていないとき、前記選択手段は、前記複数のストリームデータのうち、前記再生ビットレートが最も低いストリームデータを選択することを特徴とするクライアント。
9. 各々が、同一のコンテンツに関し、互いに異なる再生ビットレートを有し、連続して配列される複数のパートに分割された複数のストリームデータを蓄積するサーバに接続可能なクライアントコンピュータに実行させるクライアントプログラムであって、
   前記サーバからストリーム配信された前記パートを順次蓄積するステップと、
   前記蓄積された前記パートを順次再生するステップと、
   前記パートの再生が完了したとき、未再生のパートが蓄積されているか否かを判断するステップと、
   判断の結果、前記未再生のパートが蓄積されているとき、前記未再生のパートの再生時間で蓄積可能なデータ量を算出するステップと、
   前記算出結果に基づいて、前記サーバに要求するストリームデータ及び配信開始パートを選択するステップと、
   前記選択されたストリームデータを、前記配信開始パートからストリーム配信するよう要求するステップとをクライアントコンピュータに実行させるクライアントプログラム。
   

Images