JP2000122951A - 動画配信システム - Google Patents

Abstract

(57)【要約】 【課題】 クライアントからの要求に対してサーバから
クライアントにビデオデータを配信し、クライアントで
ビデオデータを再生する際、クライアントとサーバの間
でビデオデータの再生に必要な情報を配受信することに
より、クライアントでのビデオデータの再生を途切れの
ない高品質なものにする。 【解決手段】 クライアントがクライアントの性能を記
した性能情報をサーバに配信し、サーバが配信された性
能情報に基づいて、ビデオデータとビデオデータの再生
に必要なビデオ再生情報をクライアントに配信し、クラ
イアントは配信されたビデオデータを再生すると共に、
ビデオ再生情報とビデオデータの配信状況に基づいて作
成した新たなビデオ再生情報の要求であるフィードバッ
ク要求をサーバに配信し、サーバはフィードバック要求
にに基づいて作成したフィードバック応答をクライアン
トに配信し、クライアントはフィードバック応答に基づ
いてビデオデータを新たな状態で再生し直すようにし
た。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はサーバからクライア
ントへの動画配信に関し、クライアントとサーバの間で
動画配信のための情報のやり取りを繰り返すことにより
動画の配信と動画の再生をする動画配信システムに関す
るものである。

【０００２】

【従来の技術】従来のHTTPビデオ配信システムの一例に
は、例えば図１３示すものがある。図１３は、サーバと
クライアントがそれぞれ別々のネットワークに接続さ
れ、それぞれのネットワークはプロキシサーバで分離さ
れているクライアント・サーバシステムであり、クライ
アントからのビデオデータの要求に対して、サーバがHT
TP応答としてビデオデータを配信するシステムについて
示したものである。

【０００３】図１３において、５１はHTTP要求に応じて
ビデオデータをHTTP応答として返すサーバ、５２はサー
バ５１にビデオデータの要求をHTTP要求として出し、ま
たサーバ５１からHTTP応答として送られてくるビデオデ
ータの再生を行うクライアント、５３はサーバ５１が接
続されているネットワーク、５４はクライアント５２が
接続されているネットワーク、５５はネットワーク５３
とネットワーク５４を分離し、ネットワーク５３に接続
されているサーバ５１とネットワーク５４に接続されて
いるクライアント５２の間のデータのやり取りをHTTPで
行うプロキシサーバである。なお、サーバ５１はクライ
アント５２からのHTTP要求によるビデオデータの要求
を、ただ単にHTTP応答としてビデオデータの配信を行な
い、クライアントではビデオデータを受け取り、再生を
行う。

【０００４】

【発明が解決しようとする課題】図１３のような構成の
システムでは、サーバはクライアントの性能やネットワ
ークの帯域とは関係なしにビデオデータを送ろうとする
ので、データ落ちやビデオデータの再生ができない等の
問題が発生することがある。本発明は以上のような問題
を解決するために、サーバは適切な転送レートでビデオ
データを配信し、クライアントではサーバから配信され
たビデオデータをサーバから配信された転送レートに従
って再生するとともに、さらに最適にビデオデータの配
信を受けるためのビデオ配信要求をサーバにフィードバ
ックし、サーバからの新たな転送レートでビデオデータ
の配信を受け、又この新たな転送レートでビデオデータ
の再生を行うことによって、クライアントでのビデオ再
生を途切れのない高品質なものにすることを目的とす
る。

【０００５】

【課題を解決するための手段】第１の発明は、クライア
ントと、上記クライアントにより要求されたデータを上
記クライアントに配信するサーバと、上記クライアント
と上記サーバの間の情報の配受信を行うプロキシサーバ
とを備え、上記クライアントは上記クライアントの性能
を記した性能情報を上記プロキシサーバを介して上記サ
ーバに配信し、上記サーバは上記クライアントにより配
信された上記性能情報に基づいて作成したビデオデータ
の再生に必要なビデオ再生情報を上記プロキシサーバを
介して上記クライアントに配信すると共に、上記性能情
報に基づいてビデオデータを上記プロキシサーバを介し
て上記クライアントに配信し、上記クライアントは上記
サーバにより配信された上記ビデオ再生情報と上記ビデ
オデータとに基づいて上記ビデオデータを上記クライア
ントの性能に適した再生状態で再生し、また配信された
上記ビデオ再生情報と上記ビデオデータの配信状況に基
づいて作成した新たなビデオ再生情報の要求であるフィ
ードバック要求を上記プロキシサーバを介して上記サー
バに配信し、上記サーバは上記クライアントにより配信
された上記フィードバック要求に基づいて作成した上記
ビデオデータの再生に反映される新たなビデオ再生情報
であるフィードバック応答を上記プロキシサーバを介し
て上記クライアントに配信し、上記クライアントは上記
サーバにより配信された上記フィードバック応答に基づ
いて、上記ビデオデータを新たな状態で再生し直すもの
である。

【０００６】第２の発明は、上記クライアントが接続さ
れているネットワークの帯域とＣＰＵ性能とメモリ容量
と現在の時間とからなる性能情報に基づいて上記ビデオ
データの転送レートを決定し、上記転送レートに基づい
てバッファサイズを決定するサーバ情報処理手段を有す
るサーバと、上記サーバ情報処理手段により決定された
上記転送レートとバッファサイズとからなるビデオ再生
情報を上記クライアントに配信し、又、上記転送レート
に従って上記ビデオデータを上記クライアントに配信す
るデータ配信手段とを備えたものである。

【０００７】第３の発明は、上記クライアントは、上記
データ配信手段により配信された上記転送レートに従っ
て上記ビデオデータの再生を行うビデオ再生手段を有す
るクライアントを備えたものである。

【０００８】第４の発明は、上記クライアントは、上記
データ配信手段により配信された上記バッファサイズに
基づいて上記ビデオデータのバッファ管理を行うバッフ
ァ管理手段を有するクライアントを備えたものである。

【０００９】第５の発明は、上記性能情報の配信時間と
上記ビデオ再生情報の配信時間とに基づいて求めたネッ
トワーク状況と、上記ビデオデータの配信間隔に基づい
て求めたネットワーク混雑状況と、上記ビデオ再生情報
の配信時間と、上記サーバから配信された上記ビデオデ
ータの実際の転送レートとからなるフィードバック要求
に基づいて上記ビデオデータの新たな転送レートを決定
し、上記新たな転送レートに基づいて新たなバッファサ
イズを決定するサーバ情報処理手段と上記新たな転送レ
ートと新たなバッファサイズとからなるフィードバック
応答を上記ビデオデータ再生中の上記クライアントに配
信し、又、上記新たな転送レートに従って上記ビデオデ
ータを上記ビデオデータ再生中の上記クライアントに配
信するデータ配信手段とを備えたものである。

【００１０】第６の発明は、上記データ配信手段により
配信された上記新たな転送レートに従って上記ビデオデ
ータの再生途中から上記ビデオデータの再生を行うビデ
オ再生手段を有するクライアントを備えたものである。

【００１１】第７の発明は、上記データ配信手段により
配信された上記新たなバッファサイズに基づいて、上記
新たな転送レートに従って配信される上記ビデオデータ
のバッファ管理を上記ビデオデータ再生中に行うバッフ
ァ管理手段を有するクライアントを備えたものである。

【００１２】第８の発明は、上記サーバにより配信され
た上記ビデオ再生情報と上記ビデオデータの配信状況に
基づいて上記フィードバック要求を作成するクライアン
ト情報処理手段を有するクライアントを備たものであ
る。

【００１３】第９の発明は、上記性能情報の配信時間と
上記ビデオ再生情報の配信時間とに基づいて求めたネッ
トワーク状況と、上記ビデオデータの配信間隔に基づい
て求めたネットワーク混雑状況とに基づき、上記フィー
ドバック要求を配信するタイミングを決定するクライア
ント情報処理手段を備たものである。

【００１４】

【発明の実施の形態】実施の形態１ 以下、実施の形態１を図面を参照して説明する。図１
は、実施の形態１のHTTP動画配信システムの構成図であ
る。図１において、１はHTTP要求元から送られるHTTP要
求に応じてビデオデータとビデオデータの再生に必要な
ビデオ再生情報をHTTP応答としてHTTP要求元に返送する
HTTPビデオサーバ、２はHTTP要求を受信する要求受信モ
ジュール、３はHTTP応答とビデオデータの配信を行うデ
ータ配信モジュール、４は配信するビデオのビットレー
トやHTTP要求元で使用するバッファサイズの決定などを
行うサーバ情報処理モジュールである。

【００１５】また、５はHTTP要求をHTTPビデオサーバに
配信し、HTTPビデオサーバ１から返送されるビデオデー
タの再生を行うHTTP要求元であるクライアント、６はHT
TP要求の配信を行う要求配信モジュール、７はHTTP応答
とビデオデータを受信するデータ受信モジュール、８は
ネットワーク状況やビデオの受信状況を計算するクライ
アント情報処理モジュール、９はビデオデータを蓄積す
るバッファ、１０はHTTPビデオサーバ１から配信される
HTTP応答中のバッファサイズに従って、バッファ９を管
理するバッファ管理モジュール、１１はビデオデータの
再生を行うビデオ再生モジュールである。

【００１６】さらに、１２はHTTPビデオサーバ１が接続
されているインターネット、１３はクライアント５に接
続されているイントラネット、１４はインターネット１
２とイントラネット１３を分離し、インターネット１２
に接続されているHTTPビデオサーバ１とイントラネット
１３に接続されているクライアント５の間のビデオ再生
に必要な情報のやり取りを行うプロキシサーバ、１５は
HTTPプロキシを実際に行うHTTPプロキシである。

【００１７】また、１６はクライアント５がHTTPビデオ
サーバ１にビデオの開始を要求するために送るHTTP要求
であるビデオ配信開始要求、１７はHTTPビデオサーバ１
がクライアント５に返信するビデオ配信開始要求１６に
対応したHTTP応答であるビデオ配信開始応答、１８はHT
TPビデオサーバ１から配信されるビデオデータに対し、
さらにビデオデータの再生に必要な新たなビデオ再生情
報を要求するHTTP要求であるフィードバック要求、１９
はフィードバック要求１８に対して送られるHTTP応答で
あるフィードバック応答、２０はビデオ配信開始要求１
６に従って配信されるビデオデータである。

【００１８】図２は、HTTPビデオサーバ１での処理の流
れを示すフローチャートである。図３は、クライアント
５での処理の流れを示すフローチャートである。

【００１９】次に、図２、図３のフローチャートに従っ
て、HTTPビデオサーバ１、クライアント５での処理動作
について説明する。まず、HTTPビデオサーバ１は、要求
受信モジュール２がクライアント５からのビデオ配信開
始要求１６を待つ（ステップＳ１）。クライアント５で
は、要求配信モジュール６がHTTPビデオサーバ１にビデ
オ配信開始要求１６を送るために、プロキシサーバ１４
に対して、ビデオ配信開始要求１６を配信する（ステッ
プＳ２１）。

【００２０】図４はビデオ配信開始要求１６を示す説明
図であり、図５はクライアント情報を示す説明図であ
る。ビデオ配信開始要求１６にはHTTPのDateヘッダに現
在の時間が設定され、またEntity Bodyにはクライアン
ト情報２１、即ちクライアント５が接続されているネッ
トワークの帯域２２、CPU性能２３、メモリ容量２４が
設定されている。

【００２１】プロキシサーバ１４では、このビデオ配信
開始要求１６をHTTPビデオサーバ１に配信する。ここ
で、プロキシサーバ１４のHTTPプロキシ１５で行われる
一般的な処理例を図６に示すフローチャートに従って説
明する。なお、HTTPプロキシ１５での処理は、ビデオ配
信開始要求１６とビデオ配信開始応答１７のやり取り
（配信及び受信）、またフィードバック要求１８とフィ
ードバック応答１９のやり取りとも同様の処理手順によ
り処理が実行される。

【００２２】まず、HTTPプロキシ１５はHTTPプロキシ用
HTTPポート（例えば8080）でクライアント５からの接続
を待つ（ステップＳ４１）。クライアント５から接続要
求が来ると（ステップＳ４２）、クライアント５からデ
ータを受信する（ステップＳ４３）。ここで、データの
受信が成功したか否か確認して（ステップＳ４４）、デ
ータの受信が成功しない場合にはクライアント５との接
続を切断して（ステップＳ６０）、処理を終了し、デー
タの受信が成功した場合にはデータがHTTP要求か否か確
認する（ステップＳ４５）。

【００２３】データがHTTP要求でなかった場合にはクラ
イアント５との接続を切断して（ステップＳ６０）、処
理を終了する。データがHTTP要求であった場合にはHTTP
要求に記述されているURIからHTTPビデオサーバ１のIP
アドレスを調査する（ステップＳ４６）。ここで、アド
レスの調査が成功したか否か確認して（ステップＳ４
７）、アドレスの調査に成功しない場合にはクライアン
ト５に異常終了を配信し（ステップＳ５９）、クライア
ント５との接続を切断して（ステップＳ６０）、処理を
終了する。また、アドレスの調査に成功した場合にはHT
TPビデオサーバ１に対して接続要求を出す（ステップＳ
４８）。

【００２４】次に、接続に成功したか否か確認して（ス
テップＳ４９）、HTTPビデオサーバ１との接続が成功し
ない場合にはクライアント５に異常終了を配信し（ステ
ップＳ５９）、クライアント５との接続を切断して（ス
テップＳ６０）、処理を終了し、接続に成功した場合に
はHTTP要求をHTTPビデオサーバ１に配信する（ステップ
Ｓ５０）。ここで、配信に成功したか否か確認して（ス
テップＳ５１）、配信が成功しなかった場合にはサーバ
との接続を切断し（ステップＳ５８）、クライアント５
に異常終了を配信し（ステップＳ５９）、クライアント
５との接続を切断して（ステップＳ６０）、処理を終了
する。一方、配信が成功した場合にはプロキシサーバ１
４はHTTPビデオサーバ１からのデータを待つ（ステップ
Ｓ５２）。

【００２５】プロキシサーバ１４はHTTPビデオサーバ１
からデータが来るまで待ち、データが来た場合には（ス
テップＳ５３）、データがHTTP応答か否か調べ（ステッ
プＳ５４）、HTTP応答でない場合にはクライアント５に
異常終了を配信し（ステップＳ５９）、クライアント５
との接続を切断して（ステップＳ６０）、処理を終了
し、HTTP応答である場合にはクライアント５にHTTP応答
を配信する（ステップＳ５５）。ここで、配信に成功し
たか否か確認して（ステップＳ５６）、配信が成功しな
かった場合にはクライアント５との接続を切断し（ステ
ップＳ６０）、処理を終了し、配信が成功した場合には
サーバとの接続が切断されていないかを調査する（ステ
ップＳ５７）。サーバとの接続が切断されている場合に
はクライアント５との接続を切断して処理を終了し（ス
テップＳ６０）、サーバとの接続が切断されていない場
合にはプロキシサーバ１４はHTTPビデオサーバ１から、
さらにデータの受信を行ない、これをクライアント５に
送る処理を続ける。

【００２６】以後、プロキシサーバ１４では同様にクラ
イアント５からのHTTP要求を受け取った場合には、HTTP
ビデオサーバ１へ、この要求を配信し、またHTTPビデオ
サーバ１からこのHTTP要求に対するHTTP応答を受け取っ
た場合には、このHTTP応答をクライアント５に配信する
という処理を続ける。

【００２７】次に、図２、３に戻ってHTTPビデオサー
バ、クライアント５での処理動作の説明を行う。ステッ
プＳ１で、HTTPビデオサーバ１がクライアント５からの
ビデオ配信開始要求１６を待っているところに、ビデオ
配信開始要求１６が来ると、まずHTTPビデオサーバ１の
要求受信モジュール２にビデオ配信開始要求１６が入
る。ビデオ配信開始要求１６を受信した要求受信モジュ
ール２は、この要求をサーバ情報処理モジュール４に送
る。サーバ情報処理モジュール４ではビデオ配信開始要
求１６から各情報を取り出し、クライアント５に配信す
べきビデオデータ２０のビットレート（転送レート）の
決定（ステップＳ２）とクライアント５で使用するバッ
ファサイズの決定（ステップＳ３）を行う。

【００２８】まず、ビットレートは以下のもののなかか
ら一番小さいビットレートを選定する。 （１）クライアント情報２１のCPU性能２３とメモリ容
量２４から推測されるビットレート、（２）URIで指定
されたビデオのもともとのビットレート、（３）クライ
アント情報２１のネットワーク帯域２２で示されるビッ
トレート。ここで、（１）はクライアント情報２１中の
CPU性能２３とメモリ容量２４から計算で求めるもので
あり、CPUの性能２３が高く、メモリ容量２４が大きい
方が、ビットレートの値は高くなる。（２）はビデオの
もともとのビットレートで、これは通常ビデオデータの
ヘッダ等に記載されていてHTTPビデオサーバ１側で取り
出すことが可能なものである。（３）はクライアント情
報２１の中のクライアント５が接続しているネットワー
ク帯域２２をそのまま使用したものである。

【００２９】また、バッファサイズを決定するには、ま
ずビデオ配信開始要求１６のDataヘッダに設定されてい
る時間と現在の時間から、ビデオ配信開始要求１６がク
ライアント５からHTTPビデオサーバ１の間を転送される
のにどれくらいの時間がかかったかを計算する。さら
に、この時間を２倍した時間中に、先に決定したビット
レートでビデオデータ２０を配信した場合に配信される
ビデオデータ量を計算する。このビデオデータ量はクラ
イアント５に必要な最低限のバッファサイズを示すもの
であり、さらにこのビデオデータ量に余裕を持たせるた
め、このビデオデータ量の１．５倍〜２倍の値をバッフ
ァサイズとする。ここでクライアント５が最低限必要と
するバッファのサイズを計算する際に、ビデオ配信開始
要求１６のクライアント５からHTTPビデオサーバ１の間
の転送にかかった時間の２倍の値を使用したが、この理
由は、クライアント５がビデオ配信開始要求１６を行っ
てから、この要求がHTTPビデオサーバ１に届くまでの時
間と、HTTPビデオサーバ１がこの要求に対して応答した
ビデオ配信開始応答１７がクライアント５に届くまでの
時間を合わせると２倍の時間になることによる。

【００３０】次に、サーバ情報処理モジュール４は現在
のHTTPビデオサーバ１のCPU使用率を求める（ステップ
Ｓ４）。

【００３１】サーバ情報処理モジュール４は、ここまで
に求めたクライアント５に配信すべきビデオデータ２０
のビットレートと、クライアント５で使用するバッファ
サイズと、HTTPビデオサーバ１のCPU使用率と、ビデオ
配信開始要求１６がクライアント５からHTTPビデオサー
バ１の間の転送にかかった時間とをビデオ配信開始応答
１７としてデータ配信モジュール３に送る。

【００３２】次に、データ配信モジュール３は、ビデオ
配信開始要求１６の応答としてのビデオ配信開始応答１
７をクライアント５に配信する（ステップＳ５）。ここ
で、配信に成功したか否か確認して（ステップＳ６）、
ビデオ配信開始応答１７の配信が成功しなかった場合に
はクライアント５との接続を切断して（ステップＳ１
７）、処理が終了する。配信が成功した場合にはデータ
配信モジュール３は、ビデオ配信開始応答１７をクライ
アント５に配信し、さらにクライアント５に対して、先
ほど決定したビットレートに従ってビデオデータ２０の
配信を開始する（ステップＳ７）。ビデオデータ２０の
配信が開始されると、ビデオデータ２０の配信の終了が
確認されるまでビデオデータの配信が行われ（ステップ
Ｓ８、Ｓ９）、ビデオデータ２０の配信の終了が確認さ
れるとクライアント５との接続を切断して（ステップＳ
１７）、処理が終了する。

【００３３】図７は、ビデオ配信開始応答１７を示す説
明図であり、図８はサーバ情報を示す説明図である。ビ
デオ配信開始応答１７にはHTTPのDateヘッダに現在の時
間が設定され、またEntity Bodyにはサーバ情報２５、
即ちクライアント５で使用するバッファサイズ２６、HT
TPビデオサーバ１のCPU使用率７、ビデオ配信開始要求
１６のクライアント５からHTTPビデオサーバ１の間の転
送にかかった時間２８、ビットレート２９が設定されて
いる。ここで、ビットレート２９は、HTTPビデオサーバ
１がクライアント５に対してビデオを配信する時のビッ
トレートであり、又このビットレートに従ってビデオデ
ータ２０の再生が行われる。

【００３４】次に、HTTPビデオサーバ１からのビデオ配
信開始応答１７をクライアント５のデータ受信モジュー
ル７が受信すると（ステップＳ２３）、データ受信モジ
ュール７はビデオ配信開始応答１７をクライアント情報
処理モジュール８に送る。さらに、データ受信モジュー
ル７がビデオデータ２０を受信すると、データ受信モジ
ュール７はビデオデータ２０をバッファ９に送る。この
ように、クライアント情報処理モジュール８にビデオ配
信開始応答１７が送られ、ビデオデータ２０のバッファ
９中への受信が開始される（ステップＳ２４）。

【００３５】ここで、データ受信モジュール７のこの後
の動作は、HTTPビデオサーバ１から送られてくるデータ
（ビデオデータ２０または後述するフードバック応答１
９）を受信し、フードバック応答１９であった場合には
クライアント情報処理モジュール８に渡し、ビデオデー
タ２０であった場合にはビデオデータ２０をバッファ９
に渡し、ビデオデータ２０を受信したことと実際に受信
したビデオデータ２０のデータサイズであるビットレー
トをクライアント情報処理モジュール８に知らせる。

【００３６】ステップＳ２４でビデオデータ２０の受信
が開始されると、ビデオデータ２０は最終ビデオデータ
になるまでバッファ９に格納される（ステップＳ２５、
Ｓ２６）。最終ビデオデータであることが確認されると
HTTPビデオサーバ１との接続を切断して（ステップＳ２
７）、処理が終了する。また、ビデオデータ２０の受信
が開始される一方で、ビデオ配信開始応答１７中に設定
されたビットレート２９に従ってビデオデータ２０の再
生が開始されるが（ステップＳ２８）、バッファ９にビ
デオデータ２０がある間は、ビデオデータ２０の再生が
行われる（ステップＳ２９、Ｓ３０）。バッファ９にビ
デオデータ２０ががなくなると、HTTPビデオサーバ１と
の接続を切断して（ステップＳ２７）、処理が終了す
る。

【００３７】一方、データ受信モジュール７からビデオ
配信開始応答１７を渡されたクライアント情報処理モジ
ュール８は、ビデオ配信開始応答１７から各情報を取り
出し、HTTPビデオサーバ１に対して送るフィードバック
要求１８（HTTP要求）の間隔を以下のように決定する
（ステップＳ３１）。まず、ビデオ配信開始応答１７の
Dataヘッダに設定されている時間と現在の時間とから、
ビデオ配信開始応答１７のHTTPビデオサーバ１からクラ
イアント５の間の転送にかかった時間を計算する。次
に、この計算した値と、サーバ情報２５に設定されてい
るクライアント５からHTTPビデオサーバ１の間の転送に
かかった時間２８との比較を行ない、ネットワークが込
んできたのか、空いてきたのかというネットワークの状
況を推測する。また、データ受信のそれぞれの間隔、即
ちビデオデータ２０が送られてくる間隔を求め、ネット
ワークの混雑状況を推測する。以上のように推測したネ
ットワーク状況とネットワークの混雑状況に基づき、HT
TPビデオサーバ１に対して送るフィードバック要求１８
の間隔（タイミング）を決定する。

【００３８】次に、クライアント情報処理モジュール８
は、ビデオ配信開始応答１７中のサーバ情報２５からク
ライアント５で使用するバッファサイズ２６を取り出
し、これをバッファ管理モジュール１０に送る。バッフ
ァ管理モジュール１０では、送られてきたバッファサイ
ズ２６により、ビデオデータ２０のバッファの管理を行
う（ステップＳ３２）。さらに、クライアント情報処理
モジュール８は、HTTPビデオサーバ１から送られてきた
実際のビデオデータ２０のビットレート（実際のビット
レート）を求め、ビデオデータ２０の配信状況を調査す
る（ステップＳ３３）。

【００３９】クライアント情報処理モジュール８は、以
上のように推測したネットワーク状況と、ネットワーク
の混雑状況と、HTTPビデオサーバ１からクライアント５
の間の転送にかかった時間と、実際のビットレートとを
フィードバック要求１８として要求配信モジュール６に
送る。要求配信モジュール６は、HTTPビデオサーバ１に
ビデオデータ２０の配信に対する再要求、即ち新たなビ
デオ再生情報を要求をするための情報であるフィードバ
ック情報を含んだフィードバック要求１８を配信する
（ステップＳ３４）。

【００４０】図９は、フィードバック要求１８を示す説
明図であり、図１０はクライアントフィードバック情報
を示す説明図である。フィードバック要求１８にはHTTP
のDataヘッダに現在の時間が設定され、またEntity Bod
yにはクライアントフィードバック情報３０、即ちネッ
トワーク状況３１、ネットワークの混雑状況３２、HTTP
ビデオサーバ１からクライアント５の間の転送にかかっ
た時間３３、実際のビットレート３４が設定されてい
る。

【００４１】次に、クライアント５の要求配信モジュー
ル６からのフィードバック要求１８をHTTPビデオサーバ
１の要求受信モジュール２が受信すると（ステップＳ１
０）、要求受信モジュール２はフィードバック要求１８
をサーバ情報処理モジュール４に送る。サーバ情報処理
モジュール４では、フィードバック要求１８から各情報
を取り出し、クライアント５に配信すべきビデオデータ
２０のビットレートとクライアント５で使用するバッフ
ァサイズを以下のように再決定する(ステップＳ１１、
Ｓ１２)。

【００４２】ビットレートを再決定するには、まずフィ
ードバック要求１８のDataヘッダに設定されている時間
と現在の時間から、クライアント５からHTTPビデオサー
バ１の間の転送にかかった時間を計算する。次に、この
計算した値と、クライアントフィードバック情報３０に
設定されているHTTPビデオサーバ１からクライアント５
の間の転送にかかった時間３３を比較し、最新のネット
ワークの状況を推測する。さらに、この推測したネット
ワークの状況と、現在配信されているビデオデータ２０
のビットレート即ちHTTPビデオサーバ１がクライアント
５に対してビデオを配信する時のビットレート２９と、
クライアントフィードバック情報３０に設定されている
ネットワークの混雑状況３２と、実際のビットレート３
４とに基づいて新しいビットレートを決定する。

【００４３】バッファサイズを再計算するには、先に計
算したクライアント５からHTTPビデオサーバ１の間の転
送にかかった時間と、クライアントフィードバック情報
３０に設定されているHTTPビデオサーバ１からクライア
ントの５間の転送にかかった時間３３と、先に推測した
最新のネットワークの状況とを使用し、クライアント５
からHTTPビデオサーバ１の転送にかかった時間とHTTPビ
デオサーバ１からクライアント５の間の転送にかかった
時間を推測し、これらの両者の時間を２倍した時間中
に、先に決定した新しいビットレートでビデオデータ２
０を配信した場合にのビデオデータ量を計算する。この
ビデオデータ量はクライアント５に必要な最低限のバッ
ファサイズを示すものであり、さらにこのビデオデータ
量に余裕を持たせるため、このビデオデータ量の１．５
〜２倍の値を新しいバッファサイズとする。

【００４４】次に、サーバ情報処理モジュール４は現在
のサーバのCPU使用率を求める（ステップＳ１３）。さ
らに、サーバ情報処理モジュール４はここまでに求め
た、クライアント５に配信すべきビデオデータ２０の新
しいビットレート、クライアント５で使用するバッファ
サイズ、サーバのCPU使用率、クライアント５−HTTPビ
デオサーバ１の間の転送にかかった時間をフィードバッ
ク応答１９としてデータ配信モジュール３に送る。

【００４５】データ配信モジュール３は、クライアント
５にフィードバック要求１８の応答としてのフィードバ
ック応答１９（HTTP応答）を配信する（ステップＳ１
４）。ここで、配信に成功したか否か確認して（ステッ
プＳ１５）、フィードバック応答１９の配信が成功しな
いとクライアント５との接続を切断して（ステップＳ１
７）、処理を終了する。また、フィードバック応答１９
の配信が成功するとデータ配信モジュール３は、フィー
ドバック応答１９をクライアント５に配信するととも
に、現在配信しているビデオのビットレートを先ほど決
定したビデオの新しいビットレートに変更（更新）して
（ステップＳ１６）、次のフィードバック要求１８を待
つ。

【００４６】図１１は、フィードバック応答１９を示す
説明図であり、図１２はサーバフィードバック情報を示
す説明図である。フィードバック応答１９にはHTTPのDa
taヘッダに現在の時間が設定され、またEntity Bodyに
はサーバフィードバック情報３５、即ちクライアント５
で使用する新しいバッファサイズ３６、HTTPビデオサー
バのCPU使用率３７、クライアント５からHTTPビデオサ
ーバ１の間の転送にかかった時間３８、新しいビットレ
ート３９が設定されている。

【００４７】次に、HTTPビデオサーバ１からのフィード
バック要求１８に対するフィードバック応答１９を受信
したクライアント５は、この新しいビットレート３９と
新しいバッファサイズ３６を反映させてビデオ再生を行
う。一方、フィードバック応答１９を受信しビデオ再生
を行なっているクライアント５は、再度フィードバック
要求１８をHTTPビデオサーバ１に送る場合は、先のステ
ップＳ３１〜Ｓ３４で記載のビデオ配信開始応答１７か
らフィードバック要求１８を配信する時と同様の処理を
行う。即ち、クライアント情報処理モジュール８でフィ
ードバック応答１９から各情報を取り出し、HTTPビデオ
サーバ１に対して再度送るフィードバック要求１８の間
隔を再決定し（ステップＳ３７）、フィードバック応答
１９に設定されている新しいバッファサイズ３６をバッ
ファ管理モジュール１０に送り、バッファサイズの変更
（先に管理されているバッファサイズの更新）し(ステ
ップＳ３８)、ビデオ配信状況の再調査（ステップＳ３
９）を行ない、再度フィードバック要求１８をHTTPビデ
オサーバ１に送る。以下このようにHTTPビデオサーバ１
とクライアント５の間でフィードバック情報のやり取り
を繰り返すことによりビデオデータ２０の再生を行って
いく。

【００４８】以上説明したように、本実施の形態によれ
ば、クライアント５、HTTPビデオサーバ１の両方でビデ
オデータ２０の配信及び再生に必要な情報がやり取りさ
れるので、ビデオデータ２０の配信及び再生に最適なビ
ットレートとバッファを使用することができ、安定した
ビデオデータ２０の再生が可能になる。

【００４９】即ち、HTTPビデオサーバ１側でクライアン
ト５の性能などのクライアント情報を把握できるので、
クライアント５に対して適切なビットレートのビデオデ
ータ２０を配信することができ、またHTTPビデオサーバ
１から配信されるビデオデータ２０のビットレートに最
適なバッファサイズがクライアント５で利用できるの
で、ビデオデータ２０がバッファに蓄積しきれずにクラ
イアント５でのビデオ再生時にビデオデータ２０の再生
が途切れるようなビデオデータ２０の再生ができないよ
うなことがない。

【００５０】さらに、クライアント５でHTTPビデオサー
バ１の負荷状態がわかるので、HTTPビデオサーバ１の負
荷状態に合わせてビデオデータ２０の配信に関する再要
求するフィードバック要求の間隔を決定することがで
き、HTTPビデオサーバ１へのフィードバック要求によっ
てHTTPビデオサーバ１の負荷が増大し、ビデオデータ２
０の配信に悪影響を与えることを防ぐことができる。

【００５１】また、HTTPビデオサーバ１から配信されて
いるビデオデータ２０に関してのクライアント５からの
フィードバック要求に対してHTTPビデオサーバ１からフ
ィードバック応答が得られるので、現在配信しているビ
デオデータ２０の転送レートをビデオデータ２０を再生
しながら変更でき、ビデオデータ２０のデータ落ちや再
生の途切れなどの問題が生じることがない。

【００５２】さらに、HTTPビデオサーバ１から配信され
るビデオデータ２０の再生中にビデオデータ２０の最適
なバッファサイズがクライアント５で把握でき、このバ
ッファサイズに基づいて、ビデオデータ２０の蓄積、再
生ができるので、ビデオデータ２０の再生が途切れるよ
うな問題を生じることがない。

【００５３】

【発明の効果】この発明は、以上説明したように構成さ
れているので、以下に示すような効果を奏する。

【００５４】第１の発明では、サーバにより配信された
ビデオデータとビデオデータの再生に必要なビデオ再生
情報に基づき、クライアントはビデオデータを再生する
と共に、ビデオデータの再生に必要な新たなビデオ再生
情報の要求をサーバに送り、サーバにより作成され配信
された新たなビデオ再生情報に基づいてビデオデータを
新たな状態で再生し直すので、クライアントはデオデー
タの再生が途切れることがなく安定したビデオデータの
再生ができる。

【００５５】第２の発明では、サーバがクライアントよ
り配信された性能情報に基づいて決定したビデオデータ
の転送レートとバッファサイズをクライアントに配信
し、又、転送レートに従ってビデオデータをクライアン
トに配信するので、サーバはクライアントに対してビデ
オデータの配信が途切れることがなく安定したビデオデ
ータの配信ができる。

【００５６】第３の発明では、データ配信手段により配
信された転送レートに従ってクライアントがビデオデー
タの再生を行うので、クライアントはデオデータの再生
が途切れることがなく安定したビデオデータの再生がで
きる。

【００５７】第４の発明では、データ配信手段により配
信された転送レートに基づいてクライアントがビデオデ
ータのバッファ管理を行うので、クライアントはビデオ
データをバッファに最適な状態で格納できる。

【００５８】第５の発明では、サーバ情報処理手段がク
ライアントからのフィードバック要求に基づいて決定し
た新たな転送レートと新たなバッファサイズをクライア
ントに配信し、又、新たな転送レートに従ってビデオデ
ータをビデオデータ再生中のクライアントに配信するの
で、サーバはクライアントに対してビデオデータの再生
中にビデオデータの配信が途切れることがなく安定した
ビデオデータの配信ができる。

【００５９】第６の発明では、データ配信手段により配
信された新たな転送レートに従ってビデオデータの再生
途中からビデオデータの再生を行うので、クライアント
はビデオデータの再生途中でデオデータの再生が途切れ
ることがなく安定したビデオデータの再生ができる。

【００６０】第７の発明では、データ配信手段により配
信された新たなバッファサイズに基づいてクライアント
がビデオ再生中にビデオデータのバッファ管理を行うの
で、クライアントはビデオ再生中にビデオデータをバッ
ファに最適な状態で格納できる。

【００６１】第８の発明では、サーバにより配信された
ビデオ再生情報とビデオデータの配信状況に基づいてフ
ィードバック要求を作成するので、クライアントはビデ
オデータの再生に必要な新しい要求を作成することがで
きる。

【００６２】第９の発明では、ネットワーク状況とネッ
トワーク混雑状況に基づいてサーバにフィードバック要
求を配信するので、サーバの負荷が増大してビデオデー
タの配信不良が生じることを防止できる。

【図面の簡単な説明】

【図１】 実施の形態１のHTTP動画配信システムの構成
図である。

【図２】 実施の形態１におけるHTTPビデオサーバの処
理の流れを示すフローチャーである。

【図３】 実施の形態１においてクライアントの処理の
流れを示すフローチャートである。

【図４】 実施の形態１におけるビデオ配信開始要求の
説明図である。

【図５】 実施の形態１におけるクライアント情報の説
明図である。

【図６】 実施の形態１におけるHTTPプロキシの処理の
流れを示すフローチャートである。

【図７】 実施の形態１におけるビデオ配信開始応答の
説明図である。

【図８】 実施の形態１におけるフィードバック要求の
説明図である。

【図９】 実施の形態１におけるフィードバック要求の
説明図である。

【図１０】 実施の形態１におけるクライアントフィー
ドバック情報の説明図である。

【図１１】 実施の形態１におけるフィードバック応答
の説明図である。

【図１２】 実施の形態１におけるサーバフィードバッ
ク情報である。

【図１３】 従来のHTTPビデオ配信システムの構成図で
ある。

【符号の説明】

１ HTTPビデオサーバ、２ 要求受信モジュール、３
データ配信モジュール、４ サーバ情報処理モジュー
ル、５ クライアント、６ 要求配信モジュール、７
データ受信モジュール、８ クライアント情報処理モジ
ュール、９ バッファ、１０ バッファ管理モジュー
ル、１１ ビデオ再生モジュール、１２ インターネッ
ト、１３ イントラネット、１４ プロキシサーバ、１
５ HTTPプロキシ、１６ ビデオ配信開始要求、１７
ビデオ配信開始応答、１８ フィードバック要求、１９
フィードバック応答、２０ ビデオデータ。

Claims (9)

【特許請求の範囲】
1. 【請求項１】 クライアントと、 上記クライアントにより要求されたデータを上記クライ
   アントに配信するサーバと、 上記クライアントと上記サーバの間の情報の配受信を行
   うプロキシサーバとを備え、 上記クライアントは上記クライアントの性能を記した性
   能情報を上記プロキシサーバを介して上記サーバに配信
   し、 上記サーバは上記クライアントにより配信された上記性
   能情報に基づいて作成したビデオデータの再生に必要な
   ビデオ再生情報を上記プロキシサーバを介して上記クラ
   イアントに配信すると共に、上記性能情報に基づいてビ
   デオデータを上記プロキシサーバを介して上記クライア
   ントに配信し、 上記クライアントは上記サーバにより配信された上記ビ
   デオ再生情報と上記ビデオデータとに基づいて上記ビデ
   オデータを上記クライアントの性能に適した再生状態で
   再生し、また配信された上記ビデオ再生情報と上記ビデ
   オデータの配信状況に基づいて作成した新たなビデオ再
   生情報の要求であるフィードバック要求を上記プロキシ
   サーバを介して上記サーバに配信し、 上記サーバは上記クライアントにより配信された上記フ
   ィードバック要求に基づいて作成した上記ビデオデータ
   の再生に反映される新たなビデオ再生情報であるフィー
   ドバック応答を上記プロキシサーバを介して上記クライ
   アントに配信し、 上記クライアントは上記サーバにより配信された上記フ
   ィードバック応答に基づいて、上記ビデオデータを新た
   な状態で再生し直すことを特徴とする動画配信システ
   ム。
2. 【請求項２】 上記サーバは、上記クライアントが接続
   されているネットワークの帯域とＣＰＵ性能とメモリ容
   量と現在の時間とからなる性能情報に基づいて上記ビデ
   オデータの転送レートを決定し、上記転送レートに基づ
   いてバッファサイズを決定するサーバ情報処理手段と、 上記サーバ情報処理手段により決定された上記転送レー
   トとバッファサイズとからなるビデオ再生情報を上記ク
   ライアントに配信し、又、上記転送レートに従って上記
   ビデオデータを上記クライアントに配信するデータ配信
   手段とを備えたことを特徴とする請求項１記載の動画配
   信システム。
3. 【請求項３】 上記クライアントは、上記データ配信手
   段により配信された上記転送レートに従って上記ビデオ
   データの再生を行うビデオ再生手段を備えたことを特徴
   とする請求項２記載の動画配信システム。
4. 【請求項４】 上記クライアントは、上記データ配信手
   段により配信された上記バッファサイズに基づいて上記
   ビデオデータのバッファ管理を行うバッファ管理手段を
   備えたことを特徴とする請求項２記載の動画配信システ
   ム。
5. 【請求項５】 上記サーバ情報処理手段は、上記性能情
   報の配信時間と上記ビデオ再生情報の配信時間とに基づ
   いて求めたネットワーク状況と、上記ビデオデータの配
   信間隔に基づいて求めたネットワーク混雑状況と、上記
   ビデオ再生情報の配信時間と、上記サーバから配信され
   た上記ビデオデータの実際の転送レートとからなるフィ
   ードバック要求に基づいて上記ビデオデータの新たな転
   送レートを決定し、上記新たな転送レートに基づいて新
   たなバッファサイズを決定し、 上記データ配信手段は、上記新たな転送レートと新たな
   バッファサイズとからなるフィードバック応答を上記ビ
   デオデータ再生中の上記クライアントに配信し、又、上
   記新たな転送レートに従って上記ビデオデータを上記ビ
   デオデータ再生中の上記クライアントに配信することを
   特徴とする請求項２記載の動画配信システム。
6. 【請求項６】 上記クライアントは、上記データ配信手
   段により配信された上記新たな転送レートに従って上記
   ビデオデータの再生途中から上記ビデオデータの再生を
   行うビデオ再生手段を備えたことを特徴とする請求項５
   記載の動画配信システム。
7. 【請求項７】 上記クライアントは、上記データ配信手
   段により配信された上記新たなバッファサイズに基づい
   て、上記新たな転送レートに従って配信される上記ビデ
   オデータのバッファ管理を上記ビデオデータ再生中に行
   うバッファ管理手段を備えたことを特徴とする請求項５
   記載の動画配信システム。
8. 【請求項８】 上記クライアントは、上記サーバにより
   配信された上記ビデオ再生情報と上記ビデオデータの配
   信状況に基づいて上記フィードバック要求を作成するク
   ライアント情報処理手段を備たことを特徴とする請求項
   ２記載の動画配信システム。
9. 【請求項９】 上記クライアント情報処理手段は、上記
   性能情報の配信時間と上記ビデオ再生情報の配信時間と
   に基づいて求めたネットワーク状況と、上記ビデオデー
   タの配信間隔に基づいて求めたネットワーク混雑状況と
   に基づき、上記フィードバック要求を配信するタイミン
   グを決定することを特徴とする請求項８記載の動画配信
   システム。