JP2000228669A

JP2000228669A - ストリーム配送システムにおけるストリームデータ配送方法

Info

Publication number: JP2000228669A
Application number: JP2965799A
Authority: JP
Inventors: Shihoko Taguchi; しほ子田口; Masaaki Iwasaki; 正明岩嵜; Takahiro Nakano; 隆裕中野
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1999-02-08
Filing date: 1999-02-08
Publication date: 2000-08-15

Abstract

(57)【要約】【課題】再生開始遅延時間が短く、かつ、クライアント
において発生するバッファ・オーバーフローやバッファ
・アンダーフローを回避して長大ストリームデータの長
時間再生が可能なストリーム配送システムを実現する。【解決手段】ストリームデータを配送する少なくとも１
つのストリームサーバと、ストリームデータの受信と再
生が可能な少なくとも１つのクライアントを有するスト
リーム配送システムにおいて、ストリームサーバは、ス
トリームデータ固有の伝送レートであるビットレート
（固有ビットレート）に依存もしくは依存せずに、スト
リームデータの配送レートを配送前もしくは配送中の任
意の時刻において変更して配送することが可能であり、
クライアントは、ストリームサーバが配送するストリー
ムデータの受信レートと、固有ビットレートとの差違を
利用して、ストリームサーバに要求する最適な配送レー
トを決定し、決定した配送レートをストリームサーバに
通知する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ストリームデータ
を配送するストリームサーバと、ストリームデータの受
信と再生を実行するクライアントから構成するストリー
ム配送システムに関し、特に、ストリーム配送技術に関
する。

【０００２】

【従来の技術】クライアントとストリームサーバで構成
し、両者をネットワークを介して接続するストリーム配
送システムの一つに、ストリームサーバ上に格納するス
トリームデータを、クライアントからのアクセス要求に
応じて配送／再生するビデオ・オン・デマンドがある。
以下に、ビデオ・オン・デマンにおいて、ネットワーク
を介してストリームデータを送受信するための、クライ
アントでの受信および再生方法と、ストリームサーバで
のストリームデータの配送(以下、ストリーム配送と呼
ぶ）方法について説明する。

【０００３】クライアントでは、ストリームデータの受
信と再生を実行する場合にストリーミング技術を用い
る。ストリーミング技術は、ストリームサーバから連続
的に配送されるストリームデータをメモリ上のバッファ
に受信し、次々に到着するデータを受信しながら受信済
みストリームデータを再生する技術である。ストリーミ
ング技術では、ストリームサーバ上に格納されたストリ
ームデータを、ftpなどのファイル転送によってクライ
アント上に全てダウンロードしてから再生するのと違
い、受信したストリームデータをローカルファイルとし
て保存する必要がない。このため、クライアントに大容
量の保存用ハードディスク等が不要となり、また、クラ
イアントに保存することのできないような長大ストリー
ムデータの再生をも可能とする。

【０００４】さらに、ストリーミング技術は、ストリー
ムデータを受信しながら再生するため、ftpなどのファ
イル転送方式に比べ、ストリーム配送の開始を要求する
パケット（以下、ストリーム配送の開始を要求するパケ
ットをストリーム配送開始要求と呼ぶ）をストリームサ
ーバに送信してから再生開始までに要する応答時間（以
下、再生開始遅延時間と呼ぶ）を短縮できる。

【０００５】一方、ストリームサーバは、ネットワーク
の物理帯域幅の違いや、ストリームサーバの負荷状況に
応じて、ストリームデータ固有の伝送レートであるビッ
トレート（以下、固有ビットレート）を変化させて、あ
るいは、異なる固有ビットレートのストリームデータに
切り替えて配送することで、再生画像の品質低下を防い
でいる。

【０００６】例えば、ネットワークはその種類により物
理帯域幅が異なり、ストリームサーバとクライアント間
の途中経路のネットワークに、送信しようとするストリ
ームデータの固有ビットレートよりも狭い物理帯域幅の
ネットワークが存在する場合がある。その場合、経路の
途中でのパケットロストが避けられない。パケットロス
トが発生してストリームデータ中の重要なデータが損失
すると、再生時に顕著な画像品質劣化が生じてしまう。
例えば、MPEG1システム・ストリームデータにおいてデ
ータが損失すると、再生時の画像にブロック単位のひず
みが顕著に現れる。この問題を解決するために、ストリ
ームサーバは、途中経路にあるネットワークの物理帯域
幅に応じて固有ビットレートを配送可能レートまで下げ
て、あるいは、より低い固有ビットレートのストリーム
データに切り替えて配送することで、データ損失を回避
し、クライアントにおける顕著な再生画像品質の劣化を
低減する。

【０００７】また、ストリーム配送要求の集中などの原
因によりストリームサーバが過負荷となった場合、配送
レートを固有ビットレートと同じに維持することが困難
になる。配送レートの低下はクライアント上での受信レ
ートの低下となり、バッファ・アンダーフローの原因に
なる。バッファがアンダーフローすると、再生画像は途
切れ途切れとなり、やはり顕著な画像品質劣化が生じ
る。この問題を解決するためにストリームサーバは、よ
り低い固有ビットレートのストリームデータに切り替え
て、単位時間あたりのデータ処理量を低減することで、
配送レートを固有ビットレートと同じに維持し、再生時
の顕著な画像品質劣化を低減する。

【０００８】

【発明が解決しようとする課題】上述のように従来技術
では、ストリーミング技術を用いることにより、長大ス
トリームデータの再生を実現している。また、固有ビッ
トレートを配送可能レートまで低下させて、あるいは、
より低い固有ビットレートのストリームデータに切り替
えて配送することで、再生画像品質の顕著な劣化を防止
している。

【０００９】しかし、ストリームサーバの処理能力やネ
ットワークの帯域幅が十分であるにも関わらず、ストリ
ームサーバの配送レートとクライアントの再生レートの
わずかな誤差が原因となって、ストリームデータを受信
しているバッファのオーバーフローやアンダーフローが
発生してしまう問題が存在する。この問題は、わずかな
レートの差異が累積する長大ストリームデータを用いた
長時間再生で顕著となり、上述の従来技術では解決でき
ない。

【００１０】この配送レートと再生レートの不一致は、
ストリームサーバとクライアントがそれぞれ独立な水晶
発振子で駆動され、それらの水晶発振子のクロックを基
準にそれぞれのレートを決定しているために発生する。
周知のとおり、コンピュータは水晶発振子がつくりだす
クロックによってデジタル電子回路を駆動しており、こ
れはコンピュータ内部の時間の基準となるタイマ回路も
例外ではない。配送レートや再生レートは、それぞれの
コンピュータのタイマが示す時間を基準に、ソフトウェ
アが単位時間あたりのデータ量を算出している。タイマ
が示す時間には、各コンピュータごとのわずかな誤差が
存在しており、これを基準に算出した配送レートや再生
レートにもタイマ誤差に比例した誤差が含まれる。この
ため、数分間以上の画像を再生する場合、ストリームサ
ーバの配送レートとクライアントの再生レートとの誤差
が累積し、これがバッファのオーバーフローやアンダー
フローを引き起こす。

【００１１】このバッファのオーバーフローやアンダー
フローの問題は、従来技術では本質的に回避できない。
なぜなら、それぞれのコンピュータがそれぞれのタイマ
を基準にして、独立に配送レートと再生レートを決定す
る限り、両レートの間にはタイマ誤差に比例する誤差が
含まれてしまうからである。

【００１２】また別の問題として、ストリーミング技術
を用いることにより、前述のようにftp（ファイル転
送）に比べて再生開始遅延を低減できるが、ストリーム
データを受信し始めて、直ちに再生を開始すると、後続
データの到着が少しでも遅れた場合、すぐにバッファが
アンダーフローしてしまう問題がある。このバッファの
アンダーフローを避けるためには、アンダーフロー対策
用に十分な量のストリームデータをバッファに溜めてか
ら再生を開始しなければならない。このバッファリング
に要する時間はftpに要する時間に比べて小さいとは言
え、やはり再生開始遅延の原因となる。

【００１３】本発明の目的は、再生開始遅延時間が短
く、かつ、クライアントにおいて発生するバッファ・オ
ーバーフローやバッファ・アンダーフローを回避して長
大ストリームデータの長時間再生が可能なストリーム配
送システムを実現することにある。

【００１４】

【課題を解決するための手段】上記課題を解決するため
に、本発明は、ストリームデータを配送する少なくとも
１つのストリームサーバと、ストリームデータの受信と
再生が可能な少なくとも１つのクライアントを有し、前
記ストリームサーバは、前記ストリームデータ固有の伝
送レートであるビットレート（固有ビットレート）に依
存もしくは依存せずに、当該ストリームデータの配送レ
ートを配送前もしくは配送中の任意の時刻において変更
して配送することが可能なレート変更配送手段を備え、
前記クライアントは、前記ストリームサーバが配送する
ストリームデータの受信レートと、前記固有ビットレー
トとの差違を利用して、前記ストリームサーバに要求す
る最適な配送レートを決定する要求レート決定手段と、
前記要求レート決定手段において決定した配送レートを
前記ストリームサーバに通知する要求レート通知手段を
備えることを特徴とする。

【００１５】本発明によれば、ストリームサーバからの
配送レートが、クライアントでの受信レートと一致しな
い場合、クライアントは受信レートと固有ビットレート
に差違の生じないように調整した新たな配送レート（以
下、整合レートと呼ぶ）をストリームサーバに通知し、
ストリームサーバ側の配送レートをこの整合レートに一
致させることができる。したがって、ストリームサーバ
からの配送レートと、クライアントでの受信レートを厳
密に一致させることが可能となり、各コンピュータのタ
イマの誤差に起因するバッファ・オーバーフローやバッ
ファ・アンダーフローを回避することができる。

【００１６】また、本発明によれば、ストリーム配送開
始時にストリームデータの固有ビットレートを上回る高
い伝送レート（以下、バッファリングデータ確保用レー
トと呼ぶ）で配送を開始し、クライアントにおいてバッ
ファがある程度満たされた時点で、整合レートを決定し
てストリームサーバに通知し、ストリームサーバ側の配
送レートをこの整合レートに一致させることができる。
したがって、再生開始遅延時間を最小限にしながら、バ
ッファ・アンダーフローを回避することができる。

【００１７】

【発明の実施の形態】以下§1.から§3.に図1から図８
を用いて本発明の一実施形態を、§4.に図９および図１
０を用いて本発明の一実施形態の変形例を説明する。

【００１８】§1. 構成図１は、本発明の一実施形態が適用されたストリーム配
送システムとその動作概略図である。

【００１９】図示するように、ストリームサーバ100
は、イーサネット（登録商標）などのネットワーク300
を介してクライアント200と接続する。ストリームサー
バ100には、ストリームデータとしてMPEG1システム・ス
トリームを格納するディスク120が接続され、ストリー
ムデータの読み出しと配送を実行する配送サーバ110が
起動する。ディスク120は、ハードディスクに限らず、C
D-ROM、DVD-ROMなどの可搬性のある記憶媒体でも構わな
い。また、ストリームデータは、MPEG1システム・スト
リームに限定せず、非圧縮のビデオデータ、音声などで
あってもよい。

【００２０】クライアント200には、ストリームデータ
の受信と再生を実行する再生アプリケーション210が起
動し、画像を出力するディスプレイ220、および、音声
を出力するスピーカ230が接続されている。ストリーム
データがMPEG1システム・ストリームの場合、再生とは
デコードおよびデコード済みデータの出力を示す。デコ
ードは、再生アプリケーション210内で実行するソフト
ウエアデコードであっても、クライアント200に接続し
ているハードウエアによるハードウエアデコードであっ
ても良い。図1では、ストリームサーバとクライアント
は1台ずつであるが、複数のストリームサーバと複数の
クライアントが接続されていてもよい。また、デコード
済みデータの出力先は、ディスプレイ220およびスピー
カ230だけでなく、クライアントに接続されたディスク
（図示せず）であっても良い。

【００２１】上記構成のストリーム配送システムにおけ
る、動作概略を説明する。

【００２２】クライアント200上の再生アプリケーショ
ン210は、ストリームサーバ100上の配送サーバ110に、
ネットワーク300を介して、MPEG1システム・ストリーム
のストリーム配送開始要求を送信する(400)。ストリー
ム配送開始要求を受信した配送サーバ110は、MPEG1シス
テム・ストリームをディスク120から順次読み出し(41
0)、再生アプリケーション220に順次配送する(420)。再
生アプリケーション210は、MPEG1システム・ストリーム
を受信し、受信したストリームデータから順次ディスプ
レイ220およびスピーカ230に再生する(430)。以下MPEG1
システム・ストリームをMPEGデータと呼ぶ。

【００２３】次に、配送サーバ110と、再生アプリケー
ション210のソフトウエア構成について説明する。

【００２４】図２は、配送サーバ110のソフトウエア構
成図である。

【００２５】配送サーバ110は、メイン制御部130、バッ
ファ140、ディスク入出力制御部150、パケット送受信制
御部160、および、時刻制御部170で構成する。メイン制
御130は、配送サーバ内の全ての制御部およびバッファ1
70を制御する。バッファ140は、メモリ上に取得した領
域であり、ディスク120から読み出したMPEGデータ格納
用に使用する。ディスク入出力制御部150は、時刻制御
部170の指示に従いディスクからバッファ140にMPEGデー
タの読み出し処理(410)を行う。パケット送受信制御部1
60は、時刻制御部170の指示に従いバッファ140上のMPEG
データからネットワーク送信用のパケットを作成して、
配送処理を行う。時刻制御部170は、ディスク入出力制
御部150およびパケット送受信制御部160が、メイン制御
部130より指示されたレートで稼動するように制御す
る。

【００２６】図３は、再生アプリケーション210のソフ
トウエア構成図である。

【００２７】再生アプリケーション210は、メイン制御
部240、バッファ250、パケット送受信制御部260、受信
レート監視部270、再生処理部280で構成する。メイン制
御部240は、各構成要素間とバッファ250の制御を行う。
バッファ250は、メモリ上に取得した領域であり、MPEG
データ格納用に使用する。パケット送受信制御部260で
は、ネットワーク300を介して受信したパケット内デー
タをバッファ250に受信し、MPEGデータの全受信量を計
測する。受信レート監視部270は、パケット送受信制御
部260で計測した全受信量から受信レートを算出し、固
有ビットレートに対する受信レートの割合を算出する。
固有ビットレートとは、受信したMPEGデータ固有の伝送
レートを示す。受信レート監視部270では、固有ビット
レートに対する受信レートの割合を確認し、割合が一定
値以上もしくは一定値以下の場合、両レートから整合レ
ートを算出する。整合レート算出処理については、図６
に説明する。再生処理部280は、バッファ250内のMPEGデ
ータを取得し、ディスプレイ220およびスピーカ230に再
生する。

【００２８】§2．配送サーバ送信処理図４は、配送サーバ110から再生アプリケーション210へ
MPEGデータを配送する場合の配送サーバ110の動作を説
明するためのフロー図である。

【００２９】まず、パケット送受信制御部160は再生ア
プリケーション210からストリーム配送開始要求を受信
する(ステップ1000)。次に、ディスク入出力制御部150
は、ステップ1000において再生アプリケーション210か
ら指定されたMPEGデータの固有ビットレート(BitRate)
をディスク120から読み込む(ステップ1001)。読み込ん
だ固有ビットレート(BitRate)を時刻制御部170の配送レ
ート(SendRate)に設定する(ステップ1002)。

【００３０】次に、ディスク入出力制御部150は、ディ
スク120からMPEGデータをバッファ140に読み出し、読み
出したMPEGデータを時刻制御部170が示す配送レート(Se
ndRate)の速度で、パケット送受信制御部160がネットワ
ーク300への配送を繰り返す(ステップ1003)。ディスク1
20からの読み出し速度は、配送レート(SendRate)ではな
く、一括して読み出しを終了しても良い。ステップ1003
においてバッファ140内のMPEGデータを全て配送する
と、配送中のコンテンツにおいて、未配送のMPEGデータ
がディスク120内に残っているか確認する(ステップ100
4)。MPEGデータの配送が終了していなければ、再送アプ
リケーション210からの要求があるか確認し(ステップ10
05)、なければステップ1003に戻り、ストリーム配送を
続行する。ステップ1006において、再生アプリケーショ
ン210からの要求があり、要求が配送レート変更要求で
あれば(ステップ1006)、再生クライアントから送信され
た整合レート(AdjustRate)を時刻制御部170の配送レー
ト(SendRate)に設定して(ステップ1007)、MPEGデータの
配送を続行する(ステップ1003)。整合レート(AdjustRat
e)については、図６で説明する。ステップ1006におい
て、再生アプリケーション210からの要求が配送レート
変更要求でなく、ストリーム配送停止要求でもない場合
(ステップ1008)、要求された処理を実行し(ステップ100
9)、ストリーム配送処理を続行する(ステップ1003)。ス
テップ1004において、配送中のコンテンツのMPEGデータ
を全て配送し終わった場合と、ステップ1008において再
生アプリケーション210からの要求がストリーム配送停
止要求であった場合、MPEGデータの読み出し処理および
配送処理を終了する(ステップ1010)。

【００３１】なお、ステップ1000においてストリーム配
送開始要求を受信した際に、MPEGデータ指定のない場合
は、ステップ1001においてメイン制御部130においてMPE
Gデータを選択し、選択したMPEGデータの固有ビットレ
ート(BitRate)を読み込んでもよい。

【００３２】§3.再生アプリケーション受信／再生処理図５、図６、図７、図８を用いて、再生アプリケーショ
ン220の受信および再生処理について説明する。

【００３３】図５は、配送サーバ110からMPEGデータを
受信して再生する場合の再生アプリケーション210の動
作を説明するためのフロー図である。

【００３４】まず、メイン制御240において利用者から
のストリーム再生開始要求を確認すると、パケット送受
信制御部260より配送サーバ110にストリーム配送開始要
求を送信する(ステップ2000)。そして、MPEGデータの到
着を待つ間に、利用者からのストリーム再生停止要求が
ないか確認する(ステップ2001)。ストリーム再生停止要
求がなく、かつ、MPEGデータを含むパケットを受信しバ
ッファ250に格納した場合、パケット送受信制御部260に
おいて全受信量を記述するAllRecvSizeに受信量(RecvSi
ze)を追加し(ステップ2002)、ストリーム配送開始要求
を送信してから初めてMPEGデータを受信したか確認する
(ステップ2003)。もし、最初のMPEGデータ受信である場
合、受信レートを監視するためのタイマを作成し(ステ
ップ2004)、再生処理用のスレッドである再生スレッド
を作成し(ステップ2005)、ステップ2001に戻る。ステッ
プ2004では、タイマ作成時にタイマ起動後の実行スレッ
ドである受信レート監視スレッドを作成する。受信レー
ト測定部270は受信レート監視スレッドにより実行す
る。受信レート監視処理は図６で説明する。再生処理部
280は、ステップ2005で作成した再生スレッドにより実
行する。再生処理は図７で説明する。受信を繰り返す途
中にステップ2001で利用者からのストリーム再生停止要
求を確認すると、受信レート監視スレッドに監視停止を
(ステップ2006)、再生スレッドに再生停止を(ステップ2
007)を要求した後、配送サーバ110にストリーム配送停
止要求を送信する(ステップ2008)。

【００３５】図６は、受信レート監視部270の受信レー
ト監視処理を説明するためのフロー図である。

【００３６】受信レート監視部270では、受信レート監
視スレッド作成と同時にシステム時刻を取得し、現シス
テム時刻(CurSysTime)および前システム時刻(LastSysTi
me)に代入し、全受信量(AllRecvSize)を現全受信量(Cur
AllRecvSize)および前前受信量(LastAllRecvSize)に代
入する(ステップ3000)。受信レート監視スレッドは、タ
イマ起動メッセージを受信すると(ステップ3001)受信レ
ート(RecvRate)を算出し(ステップ3002)、固有ビットレ
ート(BitRate)に対する受信レート(RecvRate)の割合を
算出する(ステップ3003)。受信レート(RecvRate)算出処
理(ステップ3002)については、図８において説明する。
固有ビットレート(BitRate)に対する受信レート(RecvRa
te)の割合がストリーム配送システムで決定した基準値
の範囲内であれば(ステップ3004)、ステップ3001に戻っ
て次のメッセージを待つ。ステップ3004において基準値
の範囲外であれば、固有ビットレート(BitRate)と受信
レート(RecvRate)から整合レート(AdjustRate)を算出す
る(ステップ3005)。整合レートとは、再生アプリケーシ
ョン210上で固有ビットレートと受信レートに差違の生
じない送信レートを示す。整合レート(AdjustRate)は、
(BitRate)2×(RecvRate)により求める。次に、算出した
整合レート(AdjustRate)を配送サーバ110に通知し(ステ
ップ3006)、ステップ3001に戻って次のメッセージを待
つ。

【００３７】ステップ3001で受信したメッセージがタイ
マ起動メッセージではなく、タイマ停止メッセージでも
ない場合(ステップ3007)、メッセージの要求する処理を
実行して(ステップ3008)ステップ3001に戻る。ステップ
3007において、メッセージがタイマ停止メッセージであ
る場合、タイマを停止して受信レート監視スレッドを終
了する(ステップ3009)。

【００３８】図７は、再生処理部280の再生処理を説明
するためのフロー図である。

【００３９】再生処理部280は、再生スレッド作成と同
時にストリーム再生停止要求があるか、もしくは、バッ
ファ250内に未再生のMPEGデータがなく再生終了である
か確認する(ステップ4000）。ステップ4000において、
どちらでもない場合は、バッファ250内のMPEGデータを
固有ビットレートに基づいてデコードして順次ディスプ
レイ220もしくはスピーカ230に出力し(ステップ4001)、
ステップ2005に戻って再生を繰り返す。ステップ4000に
おいて、ストリーム再生停止要求を確認するか、もしく
は250内に未再生のMPEGデータが無い場合、再生を終了
する(ステップ4002)。

【００４０】図８は、受信レート監視部270の受信レー
ト算出処理を説明するためのフロー図である。

【００４１】まず、前回のタイマ起動時もしくは受信レ
ート監視スレッド作成時に取得したCurSysTimeをLastSy
sTimeに代入して前システム時刻を取得する。同様に、C
urAllRecvSizeをLastAllRecvSizeに代入して前全受信量
を取得し(ステップ5001)、システム時刻を取得してCurS
ysTimeに代入し、AllRecvSizeをCurAllRecvSizeに代入
する(ステップ5002)。次に、ステップ5001とステップ50
02で取得した前システム時刻(LastSysTime)と現システ
ム時刻(CurSysTime)の差分から、前回タイマ起動時から
の経過時間(DiffTime)を取得する(ステップ5003)。同様
に、ステップ5001とステップ5002で取得した前全受信量
(LastAllRecvSize)と現受信量(CurAllRecvSize)の差分
から、前回タイマ起動時からの経過時間内受信量(DiffS
ize)を取得する(ステップ5004)。そして、DiffTimeとDi
ffSizeより受信レート(RecvRate)を取得する(ステップ5
005)。受信レート(RecvRate)は、(DiffSize/DiffTime)
により求める。

【００４２】以上、本発明の一実施形態について説明し
た。

【００４３】本実施形態によれば、ストリームサーバ10
0とクライアント200の各コンピュータのタイマ間にずれ
がある場合、ずれにより生じる固有ビットレートと受信
レートの差違を検知し、差違の生じない整合レートを作
成し、配送レートを整合レートに変更する。したがっ
て、再生アプリケーション210において、MPEGデータの
受信レートと固有ビットレートが等しく、バッファ250
のオーバーフローやアンダーフローを回避することがで
きる。すなわち、長大ストリームデータの長時間再生が
可能なストリーム配送システムを実現できる。

【００４４】なお、図４に示すフローでは、配送サーバ
110の動作をシングルスレッドで実行する場合について
説明しているが、ステップ1003に説明するMPEGデータの
読み出し処理とMPEGデータの配送処理を別スレッドに分
けて、並列処理するようにすることも可能である。

【００４５】逆に、図５に示すフローでは、受信レート
監視処理を受信レート算出スレッドが実行し、再生処理
を再生スレッドが実行する手順について説明している
が、全てもしくは一部を同一スレッド内で実行するよう
に修正することも可能である。

【００４６】また、本実施形態では、図６に説明するよ
うに、再生アプリケーションは固有ビットレートと異な
るレートである整合レートを作成し、配送サーバは配送
レートを整合レートに変更する方法について説明した。
しかし、本発明はこれに限定するものではない。配送サ
ーバにおいても、固有ビットレートと異なる配送レート
を作成するようにしても良い。

【００４７】図４のステップ1002において、固有ビット
レート(BitRate)を配送レート(SendRate)に設定してい
る処理を、固有ビットレート(BitRate)より大きなレー
トを配送レート(SendRate)に設定する処理に修正するこ
とも可能である。この場合の配送サーバと再生アプリケ
ーションの動作を、図９と図１０を用いて以下に説明す
る。

【００４８】§4.変形例図９は本発明の一実施形態の変形例における、配送サー
バ110から再生アプリケーション210へMPEGデータを配送
する場合の配送サーバ110の動作を説明するためのフロ
ー図である。

【００４９】まず、配送サーバ110は再生アプリケーシ
ョン210からストリーム配送開始要求を受信すると(ステ
ップ6000)、ディスク120からMPEGデータの固有ビットレ
ート(BitRate)を読み込む(ステップ6001)。配送サーバ1
10は固有ビットレート(BitRate)を上回る高い伝送レー
トであるバッファリングデータ確保用レート(Buffering
Rate)を作成し、配送レート(SendRate)に設定する(ステ
ップ6002)。次に、ディスク120からMPEGデータを読み出
し、ステップ6002で設定した配送レート(SendRate)で配
送する(ステップ6003)。配送後、ディスク120内に未配
送のMPEGデータがあるか確認する(ステップ6004)。未配
送MPEGデータがあれば、まず再生アプリケーション210
からの要求を確認する(ステップ6005)。再生アプリケー
ション210からの要求が配送レート変更要求であれば(ス
テップ6006)、再生アプリケーション210から受信した変
更倍率(CngMagnifct)を配送レート(SendRate)に乗算し
て、新たに配送レート(SendRate)として設定する(ステ
ップ(6007)。配送レート(SendRate)設定後は、ステップ
6003に戻る。変更倍率(CongManifct)は、再生アプリケ
ーション210が固有ビットレート(BitRate)と受信レート
(RecvRate)に応じて作成する値である。

【００５０】ステップ6005において、再生アプリケーシ
ョン210からの要求がない場合、ステップ6003に戻る。
また、ステップ6006において、再生アプリケーション21
0からの要求が配送レート変更要求でなく、さらにスト
リーム配送停止要求でもない場合(ステップ6008)も、再
生アプリケーション210からの要求を処理して(ステップ
6009)、ステップ6003に戻る。

【００５１】ステップ6004において、ディスク120内に
未配送のMPEGデータがない場合、および、ステップ6008
において、再生アプリケーション210からの要求がスト
リーム配送停止要求である場合は、MPEGデータの読み出
しと配送を終了する(ステップ6010)。

【００５２】図１０は、本発明の一実施形態の変形例に
おける、配送サーバ110からMPEGデータを受信した場合
の再生アプリケーション210の動作を説明するためのフ
ロー図である。

【００５３】まず、再生アプリケーション210は、配送
サーバ110にストリーム配送開始要求を送信する(ステッ
プ7000)。そして、MPEGデータの到着を待つ間に、利用
者からのストリーム再生停止要求がないか確認する(ス
テップ7001)。MPEGデータが到着するとバッファ250に受
信し、受信量(RecvSize)を全受信量(AllRecvSize)に追
加し、ストリーム配送開始要求を送信してから初めての
受信か判断する(ステップ7002)。初めての受信であれ
ば、MPEGデータ内から固有ビットレート(BitRate)を取
得し、LastSysTimeにシステム時刻を、LastAllRecvSize
にAllRecvSizeを代入して(ステップ7003)、ステップ700
1に戻る。ステップ7002において、既にMPEGデータを受
信している場合、取得した固有ビットレート(BitRate)
でバッファ250内データを再生する(ステップ7004)。再
生開始後、まだ配送サーバ110に配送レート変更要求を
送信していない場合(ステップ7005)、全受信量(AllRecv
Size)が既定値に達しているか確認し(ステップ7006)、
達していなければ、ステップ7001に戻る。また、ステッ
プ7005において、既に配送レート変更要求を配送サーバ
110に送信していればステップ7001に戻る。ステップ700
6において、全受信量(AllRecvSize)が既定値に達してい
れば、CurSysTimeの値にシステム時刻を代入し、CurAll
RecvSizeにAllRecvSizeを代入する(ステップ7007)。そ
して、LastSysTime、CurSysTime、LastAllRecvSize、Cu
rAllRecvSizeを用いて、図８のステップ5003からステッ
プ5005の手順と同様に受信レートを算出する。算出した
受信レート(RecvRate)と固有ビットレート(BitRate)か
ら配送レート(SendRate)の変更倍率(CngMagnifct=BitRa
te/RecvRate)を算出する(ステップ7008)。次に、算出し
た変更倍率(CngMagnifct)を配送サーバ110に通知し(ス
テップ7009)、ステップ7001に戻る。ステップ7001にお
いて、利用者からのストリーム再生停止要求を確認する
か、受信終了であれば、配送サーバ110にストリーム配
送停止要求を送信し、再生を終了する(ステップ6010)。

【００５４】上記変形例の場合、ストリーム配送開始時
に固有ビットレートを上回る高い伝送レートであるバッ
ファリングデータ確保用レート(BufferingRate)でスト
リーム配送を行うため、再生アプリケーションのバッフ
ァ内に急速にMPEGデータをバッファリングすることがで
き、再生開始遅延を低減しながら、アンダーフローを回
避することができる。

【００５５】

【発明の効果】以上説明したように、本発明によれば、
クライアント／サーバ間のタイマ誤差によるバッファの
オーバーフローやアンダーフローを回避することがで
き、再生開始遅延時間が短く、長大ストリームデータの
長時間再生が可能なストリーム配送システムを実現でき
る。

【図面の簡単な説明】

【図１】本発明の一実施形態が適用されたストリーム配
送システムとその動作概略図。

【図２】配送サーバ110のソフトウエア構成図。

【図３】再生アプリケーション210のソフトウエア構成
図。

【図４】配送サーバ110から再生アプリケーション210へ
MPEGデータを配送する場合の配送サーバ110の動作を説
明するためのフロー図。

【図５】配送サーバ110からMPEGデータを受信して再生
する場合の再生アプリケーション210の動作を説明する
ためのフロー図。

【図６】受信レート監視部270の受信レート監視処理を
説明するためのフロー図。

【図７】再生処理部280の再生処理を説明するためのフ
ロー図。

【図８】受信レート監視部270の受信レート算出処理を
説明するためのフロー図。

【図９】本発明の一実施形態の変形例における、配送サ
ーバ110から再生アプリケーション210へMPEGデータを配
送する場合の配送サーバ110の動作を説明するためのフ
ロー図。

【図１０】本発明の一実施形態の変形例における、配送
サーバ110からMPEGデータを受信した場合の再生アプリ
ケーション210の動作を説明するためのフロー図。

【符号の説明】

１００…ストリームサーバ、１１０…配送サーバ、１２
０…ストリームデータ、２００…クライアント。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号ＦＩテーマコート゛(参考）９Ａ００１ (72)発明者中野隆裕神奈川県川崎市麻生区王禅寺1099番地株式会社日立製作所システム開発研究所内Ｆターム(参考） 5C064 BA07 BB05 BC10 BC16 BC18 BC20 BC27 BD01 BD02 BD07 5K028 KK32 RR03 5K030 HA04 JT02 LC01 5K032 CC05 5K034 DD02 MM08 9A001 CC07 JJ20 JJ27 KK56 KZ62 LL02

Claims

【特許請求の範囲】

【請求項１】ストリームデータを配送する少なくとも１
つのストリームサーバと、ストリームデータの受信と再
生が可能な少なくとも１つのクライアントを有し、前記ストリームサーバは、前記ストリームデータ固有の
伝送レートであるビットレート（固有ビットレート）に
依存もしくは依存せずに、当該ストリームデータの配送
レートを配送前もしくは配送中の任意の時刻において変
更して配送することが可能なレート変更配送手段を備
え、前記クライアントは、前記ストリームサーバが配送する
ストリームデータの受信レートと、前記固有ビットレー
トとの差違を利用して、前記ストリームサーバに要求す
る最適な配送レートを決定する要求レート決定手段と、前記要求レート決定手段において決定した配送レートを
前記ストリームサーバに通知する要求レート通知手段を
備えることを特徴とするストリーム配送システム。